Optimization bug with floating-point?

[Steve Kargl]

On Wed, Mar 13, 2019 at 02:24:55PM -0700, Steve Kargl wrote:
> On Wed, Mar 13, 2019 at 10:16:12AM -0700, John Baldwin wrote:
> > 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 went looking for this special hack.  In gcc/gccx/config/i386,
> one finds 
> 
> /* FreeBSD sets the rounding precision of the FPU to 53 bits.  Let the
>    compiler get the contents of <float.h> and std::numeric_limits correct.  */
> #undef TARGET_96_ROUND_53_LONG_DOUBLE
> #define TARGET_96_ROUND_53_LONG_DOUBLE (!TARGET_64BIT)
> 
> So, taking this as a hunch, I added ieeefp.h to my test program
> and called 'fpsetprec(FP_PD)' as the first executable statement.
> This then results in
> 
> % cc -fno-builtin -m32 -O2 -o z b.o a.c -lm && ./z
> Max u: 2.297073
> Count: 0
> 
> So, is there a way to correctly build clang for i386/387
> to automatically set the precision correctly?
> 

Spent a couple hours wandering in contrib/llvm.  Have no idea
how to fix clang to actually work on i386/387.  Any ideas 
would be welcomed.

AFAICT, all libm float routines need to be modified to conditional
include ieeefp.h and call fpsetprec(FP_PD).  This will work around
issues is FP and libm.  FreeBSD needs to issue an erratum about 
the numerical issues with clang.

-- 
Steve