Re: clang miscompiles OpenLibm on i686-*-freebsd

On Mon, Sep 07, 2020 at 07:55:13PM -0700, Steve Kargl wrote:
> On Mon, Sep 07, 2020 at 07:10:02PM -0700, Steve Kargl wrote:
> > 
> > Interval tested for exp2f: [1,8]
> >        ulp <= 0.5:  0.056%     14072 |   0.056%     14072
> > 0.5 <  ulp <  0.6:  0.000%         8 |   0.056%     14080
> > 3.0 <  ulp <  0.0: 99.944%  25151744 | 100.000%  25165824
> > Max ulp: 22729.386719 at 1.00195301e+00
> > 
> 
> Note, compiling s_exp2f.c with gcc9 gives the above
> result with -O3 -march=i686 -m32. So, gcc9 is not
> nearly as bad as clang, but both give bad results.
> Comparing OpenLibm's s_exp2f.c and FreeBSD's s_exp2f.c,
> one sees that the files are almost identical.
> 
> Note, FreeBSD's libm gives 
> 
> % ./tlibm_libm -DEfP exp2
> Interval tested for exp2f: [1,8]
>        ulp <= 0.5: 99.959%  25155610 |  99.959%  25155610
> 0.5 <  ulp <  0.6:  0.041%     10214 | 100.000%  25165824
> Max ulp: 0.500980 at 1.97115958e+00
> 
> which is good, but this is compiled with CPUTYPE ?= core2
> in /etc/make.conf.
> 

I think I've found the problem, and it appears to be
due to a change byt Openlibm developers to the file
math_private.h copied from FreeBSD.  Namely, one finds

//VBS
#define STRICT_ASSIGN(type, lval, rval) ((lval) = (rval))

/* VBS
#ifdef FLT_EVAL_METHOD
// Attempt to get strict C99 semantics for assignment with non-C99 compilers.
#if FLT_EVAL_METHOD == 0 || __GNUC__ == 0
#define STRICT_ASSIGN(type, lval, rval) ((lval) = (rval))
#else
#define STRICT_ASSIGN(type, lval, rval) do { \
 volatile type __lval;   \
      \
 if (sizeof(type) >= sizeof(double)) \
  (lval) = (rval);  \
 else {     \
  __lval = (rval);  \
  (lval) = __lval;  \
 }     \
} while (0)
#endif
#endif
*/

So, STRICT_ASSIGN is broken in Openlibm.  I'll be reporting
a bug upstream.  Apoogies for the noise.

-- 
Steve