This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: other/8947: Please add a Warning about "-malign-double" in docs


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]