Re: clang miscompiles OpenLibm on i686-*-freebsd
On Tue, Sep 08, 2020 at 09:11:50PM +0200, Dimitry Andric wrote: > On 8 Sep 2020, at 19:47, Steve Kargl > wrote: > > > > 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? > I have no idea why OpenLibm would change math_private.h. I've reported the issue at https://github.com/JuliaMath/openlibm/issues/215 -- Steve ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang miscompiles OpenLibm on i686-*-freebsd
On 8 Sep 2020, at 19:47, Steve Kargl 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 signature.asc Description: Message signed with OpenPGP
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 ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang miscompiles OpenLibm on i686-*-freebsd
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. -- Steve ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"