Date: Sun, 27 May 2007 12:39:29 -0700 From: Steve Kargl <sgk@troutmask.apl.washington.edu> To: Kris Kennaway <kris@obsecurity.org> Cc: freebsd-current@freebsd.org, Ed Schouten <ed@fxq.nl>, Stefan Ehmann <shoesoft@gmx.net> Subject: Re: HEADS-UP: gcc-4.2 import appears to miscompile libm. Message-ID: <20070527193929.GA80582@troutmask.apl.washington.edu> In-Reply-To: <20070527192825.GA79242@rot13.obsecurity.org> References: <20070526193128.GB54875@troutmask.apl.washington.edu> <20070526190023.C98508@volatile.chemikals.org> <20070526233116.GA56054@troutmask.apl.washington.edu> <200705271053.10725.shoesoft@gmx.net> <20070527151840.GA73374@troutmask.apl.washington.edu> <20070527192825.GA79242@rot13.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >>>> @@ -39,6 +39,9 @@ >>>> } >>>> *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@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. -- Steve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070527193929.GA80582>