Re: HEADS-UP: gcc-4.2 import appears to miscompile libm.

On Sun, 27 May 2007 12:39:29 -0700
Steve Kargl <sgk_at_troutmask.apl.washington.edu> wrote:

> On Sun, May 27, 2007 at 03:28:25PM -0400, Kris Kennaway wrote:
> > On Sun, May 27, 2007 at 08:18:40AM -0700, Steve Kargl wrote:
> >> On Sun, May 27, 2007 at 10:53:09AM +0200, Stefan Ehmann wrote:
> >>> On Sunday 27 May 2007 01:31:16 Steve Kargl wrote:
> >>>> On Sat, May 26, 2007 at 07:09:16PM -0400, Wes Morgan wrote:
> >>>>> Working from -O towards -O2 based on the info pages, I can
> >>>>> "reproduce" the problem with "-O -fstrict-aliasing -fgcse"...
> >>>>> However, -O2 with -fno-strict-aliasing by itself seems to work
> >>>>> around the issue. At first glance it looks like a possible
> >>>>> interaction between several optimizations.
> >>>>
> >>>> Ths patch fixes the problem.
> >>>>
> >>>> --- s_frexpf.c.orig     Sat May 26 16:26:50 2007
> >>>> +++ s_frexpf.c  Sat May 26 16:28:03 2007
> >>>> _at__at_ -39,6 +39,9 _at__at_
> >>>>         }
> >>>>         *eptr += (ix>>23)-126;
> >>>>         hx = (hx&0x807fffff)|0x3f000000;
> >>>> +#if 0
> >>>>         *(int*)&x = hx;
> >>>> +#endif
> >>>> +       SET_FLOAT_WORD(x,hx);
> >>>>         return x;
> >>>>  }
> >>> 
> >>> -fno-strict-aliasing is used by default for me (i386). Also, if
> >>> you use -Wall the compiler outputs a warning.
> >> 
> >> You apparently don't have CFLAGS set in /etc/make.conf.
> >> 
> >>> [root_at_something /usr/src/lib/msun/src]# cc -O2 -Wall -pipe  -c
> >>> s_frexpf.c s_frexpf.c: In function 'frexpf':
> >>> s_frexpf.c:42: warning: dereferencing type-punned pointer will
> >>> break strict-aliasing rules
> >> 
> >> Yes, I know.
> >> 
> >> OTOH, the above patch actually fixes the problem, and libm can then
> >> be compiled without -fno-strict-aliasing.
> > 
> > OK, so just to confirm, it's not a miscompilation as originally
> > suggested, but a code bug?
> > 
> 
> Yes, it is a code bug.  It is my understanding that C (C99?) 
> considers "*(int*)&x = hx;" to be undefined behavior.  From
> what I've gleaned from the gcc IRC channel, gcc-4.2 now does
> a "load and store" instead of a "store and load"  (or vice versa).
> 
> Of course, the patch touches libm so be prepared to be brucified.
> 
That is more or less classic example of broken strict aliasing
expectations. Thank you for finding it.

-- 
Alexander Kabaev