Optimization bug with floating-point?

[John Baldwin]

On 3/13/19 9:40 AM, Steve Kargl wrote:
> On Wed, Mar 13, 2019 at 09:32:57AM -0700, John Baldwin wrote:
>> On 3/13/19 8:16 AM, Steve Kargl wrote:
>>> On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote:
>>>>
>>>> gcc8 --version
>>>> gcc8 (FreeBSD Ports Collection) 8.3.0
>>>>
>>>> gcc8 -fno-builtin -o z a.c -lm && ./z
>>>> gcc8 -O -fno-builtin -o z a.c -lm && ./z
>>>> gcc8 -O2 -fno-builtin -o z a.c -lm && ./z
>>>> gcc8 -O3 -fno-builtin -o z a.c -lm && ./z
>>>>
>>>> Max ULP: 2.297073
>>>> Count: 0           (# of ULP that exceed 21)
>>>>
>>>
>>> clang agrees with gcc8 if one changes ...
>>>
>>>> int
>>>> main(void)
>>>> {
>>>>    double re, im, u, ur, ui;
>>>>    float complex f;
>>>>    float x, y;
>>>
>>> this line to "volatile float x, y".
>>
>> So it seems to be a regression in clang 7 vs clang 6?
>>
> 
> /usr/local/bin/clang60 has the same problem.  
> 
> % /usr/local/bin/clang60 -o z -O2 a.c -lm && ./z
>   Maximum ULP: 23.061242
> # of ULP > 21: 39
> 
> Adding volatile as in the above "fixes" the problem.
> 
> AFAICT, this a i386/387 code generation problem.  Perhaps,
> an alignment issue?

Oh, I misread your earlier e-mail to say that clang60 worked.

One issue I'm aware of is that clang does not have any support for the
special arrangement FreeBSD/i386 uses where it uses different precision
for registers vs in-memory for some of the floating point types (GCC has
a special hack that is only used on FreeBSD for this but isn't used on
any other OS's).  I wonder if that could be a factor?  Volatile probably
forces a round trip between memory which might explain why this is the
case.

I wonder what your test program does on i386 Linux with GCC?

-- 
John Baldwin