Date: Tue, 8 Sep 2020 21:11:50 +0200 From: Dimitry Andric <dim@FreeBSD.org> To: Steve Kargl <sgk@troutmask.apl.washington.edu> Cc: freebsd-toolchain@freebsd.org, freebsd-current@freebsd.org Subject: Re: clang miscompiles OpenLibm on i686-*-freebsd Message-ID: <66AE2F5B-F150-4D52-BF43-8F453217FC33@FreeBSD.org> In-Reply-To: <20200908174721.GA81469@troutmask.apl.washington.edu> References: <20200908021002.GA76325@troutmask.apl.washington.edu> <20200908025513.GA76566@troutmask.apl.washington.edu> <20200908174721.GA81469@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_FDCF2DD6-2925-4559-98AC-0088A490BB1A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On 8 Sep 2020, at 19:47, Steve Kargl <sgk@troutmask.apl.washington.edu> =
wrote:
>=20
> 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:
>>>=20
>>> Interval tested for exp2f: [1,8]
>>> ulp <=3D 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
>>>=20
>>=20
>> Note, compiling s_exp2f.c with gcc9 gives the above
>> result with -O3 -march=3Di686 -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.
>>=20
>> Note, FreeBSD's libm gives
>>=20
>> % ./tlibm_libm -DEfP exp2
>> Interval tested for exp2f: [1,8]
>> ulp <=3D 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
>>=20
>> which is good, but this is compiled with CPUTYPE ?=3D core2
>> in /etc/make.conf.
>>=20
>=20
> 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
>=20
> //VBS
> #define STRICT_ASSIGN(type, lval, rval) ((lval) =3D (rval))
>=20
> /* VBS
> #ifdef FLT_EVAL_METHOD
> // Attempt to get strict C99 semantics for assignment with non-C99 =
compilers.
> #if FLT_EVAL_METHOD =3D=3D 0 || __GNUC__ =3D=3D 0
> #define STRICT_ASSIGN(type, lval, rval) ((lval) =3D (rval))
> #else
> #define STRICT_ASSIGN(type, lval, rval) do { \
> volatile type __lval; \
> \
> if (sizeof(type) >=3D sizeof(double)) \
> (lval) =3D (rval); \
> else { \
> __lval =3D (rval); \
> (lval) =3D __lval; \
> } \
> } while (0)
> #endif
> #endif
> */
>=20
> 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/f5fb92746715beb0441a60feca202=
ee16cb19fc9
with a description of just "Build with gcc"... Maybe they've assumed gcc
never needs the volatile approach?
-Dimitry
--Apple-Mail=_FDCF2DD6-2925-4559-98AC-0088A490BB1A
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.2
iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCX1fXdgAKCRCwXqMKLiCW
o6Z1AJ9iVMo9dPDbDN+OqHdtmVyTH0hXIgCffjTrI+NigtgyIaO1m6gQBYPwnCw=
=bsQX
-----END PGP SIGNATURE-----
--Apple-Mail=_FDCF2DD6-2925-4559-98AC-0088A490BB1A--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?66AE2F5B-F150-4D52-BF43-8F453217FC33>