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

On Sat, 26 May 2007, Kris Kennaway wrote:

> On Sat, May 26, 2007 at 03:40:40PM -0700, Steve Kargl wrote:
>> On Sat, May 26, 2007 at 11:48:35PM +0200, Ed Schouten wrote:
>>> Hello Steve,
>>>
>>> * Steve Kargl <sgk_at_troutmask.apl.washington.edu> wrote:
>>>> mobile:kargl[234] cat a.c
>>>> #include <stdio.h>
>>>> #include <math.h>
>>>>
>>>> int main (void) {
>>>>    int n;
>>>>    float a;
>>>>    a = 1.f;
>>>>    printf("%f\n", frexpf(a,&n));
>>>>    return 0;
>>>> }
>>>> mobile:kargl[235] cc -o z a.c -lm
>>>> mobile:kargl[236] ./z
>>>> 1.000000
>>>> mobile:kargl[237] cc --version
>>>> cc (GCC) 4.2.0 20070514 [FreeBSD]
>>>> Copyright (C) 2007 Free Software Foundation, Inc.
>>>> This is free software; see the source for copying conditions.  There is NO
>>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>>>
>>>> frexpf() should return a value in [1/2,1).
>>>
>>> In a different thread (about snd_emu10k1) a user noticed that -ftree-vrp
>>> (part of -O2) may cause miscompilations. Could you try installing a libm
>>> (src/lib/msun) that is compiled with -O1?
>>>
>>
>> (cc'd -current list)
>>
>> Using -O instead of -O2 indeed appears to fix the problem.
>
> How about -O2 -fno-tree-vrp?
>

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.

-- 
This .signature sanitized for your protection