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"
[Bug 230888] Missing 64 bit atomic functions for i386 (libatomic)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230888 --- Comment #32 from Dimitry Andric --- Reopen, as various stable builds with old gcc's broke due to base r365471, with lots of errors similar to: /usr/src/contrib/llvm-project/compiler-rt/lib/builtins/atomic.c:68: warning: implicit declaration of function '__c11_atomic_compare_exchange_weak' /usr/src/contrib/llvm-project/compiler-rt/lib/builtins/atomic.c:69: error: '__ATOMIC_ACQUIRE' undeclared (first use in this function) /usr/src/contrib/llvm-project/compiler-rt/lib/builtins/atomic.c:70: error: '__ATOMIC_RELAXED' undeclared (first use in this function) /usr/src/contrib/llvm-project/compiler-rt/lib/builtins/atomic.c: In function '__atomic_load_c': /usr/src/contrib/llvm-project/compiler-rt/lib/builtins/atomic.c:178: warning: implicit declaration of function '__c11_atomic_is_lock_free' /usr/src/contrib/llvm-project/compiler-rt/lib/builtins/atomic.c:178: warning: implicit declaration of function '__c11_atomic_load' I'll have to figure out what heavy bludgeon gcc needs to compile this. Any hints are appreciated. Failed builds: https://ci.freebsd.org/job/FreeBSD-stable-11-powerpc-build/2379/ https://ci.freebsd.org/job/FreeBSD-stable-11-powerpc-build/2379/ https://ci.freebsd.org/job/FreeBSD-stable-11-powerpc-build/2379/ https://ci.freebsd.org/job/FreeBSD-stable-11-sparc64-build/5136/ https://ci.freebsd.org/job/FreeBSD-stable-11-sparc64-build/5136/ https://ci.freebsd.org/job/FreeBSD-stable-12-mips-build/3235/ https://ci.freebsd.org/job/FreeBSD-stable-12-powerpc-build/3239/ https://ci.freebsd.org/job/FreeBSD-stable-12-powerpc64-build/3164/ https://ci.freebsd.org/job/FreeBSD-stable-12-sparc64-build/3300/ -- You are receiving this mail because: You are the assignee for the bug. ___ 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"
[Bug 230888] Missing 64 bit atomic functions for i386 (libatomic)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230888 --- Comment #31 from commit-h...@freebsd.org --- A commit references this bug: Author: dim Date: Tue Sep 8 20:28:40 UTC 2020 New revision: 365472 URL: https://svnweb.freebsd.org/changeset/base/365472 Log: Revert r365471 as it is breaking with old gcc on various arches: MFC r364753: Add atomic and bswap functions to libcompiler_rt There have been several mentions on our mailing lists about missing atomic functions in our system libraries (e.g. __atomic_load_8 and friends), and recently I saw __bswapdi2 and __bswapsi2 mentioned too. To address this, add implementations for the functions from compiler-rt to the system compiler support libraries, e.g. libcompiler_rt.a and and libgcc_s.so. This also needs a small fixup in compiler-rt's atomic.c, to ensure that 32-bit mips can build correctly. Bump __FreeBSD_version to make it easier for port maintainers to detect when these functions were added. PR: 230888 Differential Revision: https://reviews.freebsd.org/D26159 MFC r364782: After r364753, there should be no need to suppress -Watomic-alignment warnings anymore for compiler-rt's atomic.c. This occurred because the IS_LOCK_FREE_8 macro was not correctly defined to 0 for mips, and this caused the compiler to emit a runtime call to __atomic_is_lock_free(), and that triggers the warning. Changes: _U stable/11/ stable/11/contrib/llvm-project/compiler-rt/lib/builtins/atomic.c stable/11/lib/libcompiler_rt/Makefile.inc _U stable/12/ stable/12/contrib/llvm-project/compiler-rt/lib/builtins/atomic.c stable/12/lib/libcompiler_rt/Makefile.inc -- You are receiving this mail because: You are the assignee for the bug. ___ 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"
[Bug 230888] Missing 64 bit atomic functions for i386 (libatomic)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230888 Dimitry Andric changed: What|Removed |Added Resolution|--- |FIXED Status|In Progress |Closed -- You are receiving this mail because: You are the assignee for the bug. ___ 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"
[Bug 230888] Missing 64 bit atomic functions for i386 (libatomic)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230888 --- Comment #30 from commit-h...@freebsd.org --- A commit references this bug: Author: dim Date: Tue Sep 8 20:02:09 UTC 2020 New revision: 365471 URL: https://svnweb.freebsd.org/changeset/base/365471 Log: MFC r364753: Add atomic and bswap functions to libcompiler_rt There have been several mentions on our mailing lists about missing atomic functions in our system libraries (e.g. __atomic_load_8 and friends), and recently I saw __bswapdi2 and __bswapsi2 mentioned too. To address this, add implementations for the functions from compiler-rt to the system compiler support libraries, e.g. libcompiler_rt.a and and libgcc_s.so. This also needs a small fixup in compiler-rt's atomic.c, to ensure that 32-bit mips can build correctly. Bump __FreeBSD_version to make it easier for port maintainers to detect when these functions were added. PR: 230888 Differential Revision: https://reviews.freebsd.org/D26159 MFC r364782: After r364753, there should be no need to suppress -Watomic-alignment warnings anymore for compiler-rt's atomic.c. This occurred because the IS_LOCK_FREE_8 macro was not correctly defined to 0 for mips, and this caused the compiler to emit a runtime call to __atomic_is_lock_free(), and that triggers the warning. Changes: _U stable/11/ stable/11/contrib/llvm-project/compiler-rt/lib/builtins/atomic.c stable/11/lib/libcompiler_rt/Makefile.inc stable/11/sys/sys/param.h _U stable/12/ stable/12/contrib/llvm-project/compiler-rt/lib/builtins/atomic.c stable/12/lib/libcompiler_rt/Makefile.inc stable/12/sys/sys/param.h -- You are receiving this mail because: You are the assignee for the bug. ___ 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"
