clang miscompiles OpenLibm on i686-*-freebsd

[Dimitry Andric]

On 8 Sep 2020, at 19:47, Steve Kargl <sgk at troutmask.apl.washington.edu> wrote:
> 
> 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.

Hi Steve,

I'm curious what their rationale was, as the commit that changed it is:

https://github.com/JuliaMath/openlibm/commit/f5fb92746715beb0441a60feca202ee16cb19fc9

with a description of just "Build with gcc"... Maybe they've assumed gcc
never needs the volatile approach?

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 223 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.freebsd.org/pipermail/freebsd-toolchain/attachments/20200908/2bf1856f/attachment.sig>