public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
Subject: Re: other/8947: Please add a Warning about "-malign-double" in docs
Date: Fri, 03 Jan 2003 23:26:00 -0000	[thread overview]
Message-ID: <20030103232600.10987.qmail@sources.redhat.com> (raw)

The following reply was made to PR other/8947; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: Norbert Wolff <norbert_wolff@t-online.de>
Cc: glibc-bug-reports-2.3.1@gnu.org, <gcc-bugs@gcc.gnu.org>,
   <gcc-gnats@gcc.gnu.org>
Subject: Re: other/8947: Please add a Warning about "-malign-double" in docs
Date: Fri, 3 Jan 2003 17:23:17 -0600 (CST)

 Norbert,
 I fear I don't understand much of the issue, but do I understand it 
 correctly that glibc is using assumptions about gcc's behavior that are 
 only valid of -malign-double is _not_ used?
 
 Thinking more about your request, I believe that it is more appropriate to 
 document this in the glibc pages (or fix the behavior in glibc), since we 
 can impossibly list requirements like this on the gcc page (for which out 
 of the zillion projcets out there should we document them?).
 
 If you agree with this, I'd like to close the gcc report and ask you to 
 file a report against glibc about this.
 
 Thanks
   Wolfgang
 
 
 
 On Sun, 29 Dec 2002, Norbert Wolff wrote:
 
 > Subject:        stat-calls fail with certain gcc-switches
 > >Submitter-Id:  net
 > >Confidential:  no
 > >Synopsis:      Problems with stat-calls and "-malign-double"
 > >Severity:      critical
 > >Priority:      high
 > >Category:      libc
 > >Class:         sw-bug
 > >Release:       libc-2.3.1
 > >Environment:
 > 	System: linux-2.4.19
 > 	Arch:   i686
 > >Description:   please see below
 > 
 > >   Please add a note in your docs that is not possible to compile
 > >    the GNU-libc (i tried it with 2.3.1) with the options
 > >    "-malign-double" and/or "-m128bit-long-double".
 > >
 > >    The increased aligment of long doubles caused by this switches
 > >    crashes the calculations in glibc-2.3.1/io/fts.c,
 > >    so every call of one of the stat-functions will fail...
 > 
 > 
 >  On 21 Dec 2002 17:40:22 -0000
 >  bangerth@dealii.org wrote:
 > 
 > >     Can you give any indications as to what exactly goes wrong?
 > >     It is not very helpful just to document that some option
 > >     might not work in some circumstances. I think it would be
 > >     much better if we actually _fixed_ the problem that was
 > >     causing the problem.
 > 
 >  Hi Wolfgang,
 > 
 >  In the glibc-sources the alignment of long doubles is used
 >  to calculate the fts_statp component of the FTSENT
 > 
 >    ---------------------------- file: io/fts.c
 > 
 >    /* Largest alignment size needed, minus one.
 >      Usually long double is the worst case.  */
 >    #ifndef ALIGNBYTES
 >    #define ALIGNBYTES	(__alignof__ (long double) - 1)
 >    #endif
 >    /* Align P to that size.  */
 >    #ifndef ALIGN
 >    #define	ALIGN(p)	(((unsigned long int) (p) + ALIGNBYTES) & ~ALIGNBYTES)
 >    #endif
 > 
 >    ...
 > 
 >    static FTSENT *
 >    internal_function
 >    fts_alloc(sp, name, namelen)
 >  	FTS *sp;
 >  	const char *name;
 > 	register int namelen;
 >    {
 >  	register FTSENT *p;
 > 	size_t len;
 > 
 > 	len = sizeof(FTSENT) + namelen;
 > 	if (!ISSET(FTS_NOSTAT))
 > 		len += sizeof(struct stat) + ALIGNBYTES;
 > 	if ((p = malloc(len)) == NULL)
 > 		return (NULL);
 > 
 > 	memmove(p->fts_name, name, namelen);
 > 	p->fts_name[namelen] = '\0';
 > 
 > 	if (!ISSET(FTS_NOSTAT))
 > 		p->fts_statp = (struct stat *)ALIGN(p->fts_name + namelen + 2);
 > 
 >     ----------------------------
 > 
 >  I dont understand what long doubles have to do with stat-calls,
 >  but when you increase the alignment of them to 16 instead of 4, which is
 >  one consequence of the gcc-switches 
 >    "-malign-double" and/or "-m128bit-long-double"
 >  every stat-call will fail with errno set to EOVERFLOW.
 > 
 >  I agree with you that it would be better to _fix_ the problem, than
 >  adding a note in the docs, but that is a job for the glibc-people,
 >  as gcc creates correct code.
 >  
 >  I have send a copy of this mail to the glibc-buglist and hope for the
 >  best...
 > 
 >  Thanks,
 >    Norbert
 > 
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:           bangerth@ticam.utexas.edu
                                www: http://www.ticam.utexas.edu/~bangerth
 
 


             reply	other threads:[~2003-01-03 23:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-03 23:26 Wolfgang Bangerth [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-01-08  1:25 janis
2003-01-04  2:36 Daniel Jacobowitz
2003-01-03 23:56 Janis Johnson
2002-12-21  9:40 bangerth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030103232600.10987.qmail@sources.redhat.com \
    --to=bangerth@ticam.utexas.edu \
    --cc=gcc-prs@gcc.gnu.org \
    --cc=nobody@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).