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
next 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: linkBe 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).