HEADS-UP: gcc-4.2 import appears to miscompile libm.
sgk at troutmask.apl.washington.edu
Sun May 27 19:41:04 UTC 2007
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
>>>> 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;
>>>> + 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.
More information about the freebsd-current