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 fr

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%

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

clang miscompiles OpenLibm on i686-*-freebsd

TL;DR summary: clang is broken for numerical on i686 FreeBSD. % uname -a FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r361834M: Fri Jun 5 08:49:26 PDT 2020 obj/usr/src/i386.i386/sys/MOBILE i386 % which clang /usr/bin/clang % clang --version FreeBSD clang version 10.0.1

Re: Optimization bug with floating-point?

On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote: > All, > > There seems to an optimization bug with clang on > > % uname -a > FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT r344653 MOBILE i386 > > IOW, if you do numerica work on i386, you may want

Re: Optimization bug with floating-point?

On Fri, Mar 15, 2019 at 05:50:37AM +1100, Peter Jeremy wrote: > On 2019-Mar-13 23:30:07 -0700, Steve Kargl > wrote: > >AFAICT, all libm float routines need to be modified to conditional > >include ieeefp.h and call fpsetprec(FP_PD). This will work around > >issues is FP

Re: Optimization bug with floating-point?

On Wed, Mar 13, 2019 at 11:30:07PM -0700, Steve Kargl wrote: > > Spent a couple hours wandering in contrib/llvm. Have no idea > how to fix clang to actually work on i386/387. Any ideas > would be welcomed. > > AFAICT, all libm float routines need to be modified to con

Re: Optimization bug with floating-point?

On Wed, Mar 13, 2019 at 02:24:55PM -0700, Steve Kargl wrote: > On Wed, Mar 13, 2019 at 10:16:12AM -0700, John Baldwin wrote: > > On 3/13/19 9:40 AM, Steve Kargl wrote: > > > On Wed, Mar 13, 2019 at 09:32:57AM -0700, John Baldwin wrote: > > >> On 3/13/19 8:16 AM, Ste

Re: Optimization bug with floating-point?

On Wed, Mar 13, 2019 at 10:16:12AM -0700, John Baldwin wrote: > On 3/13/19 9:40 AM, Steve Kargl wrote: > > On Wed, Mar 13, 2019 at 09:32:57AM -0700, John Baldwin wrote: > >> On 3/13/19 8:16 AM, Steve Kargl wrote: > >>> On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve K

Re: Optimization bug with floating-point?

On Wed, Mar 13, 2019 at 09:32:57AM -0700, John Baldwin wrote: > On 3/13/19 8:16 AM, Steve Kargl wrote: > > On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote: > >> > >> gcc8 --version > >> gcc8 (FreeBSD Ports Collection) 8.3.0 > >> > >&

Re: Optimization bug with floating-point?

On Wed, Mar 13, 2019 at 04:56:26PM +0100, Hans Petter Selasky wrote: > On 3/13/19 4:50 PM, Steve Kargl wrote: > > Using sin() and cos() directly as in > > > > /* Double precision csinh() without using C's double complex.s */ > > void > > dp_csinh(double x,

Re: Optimization bug with floating-point?

On Wed, Mar 13, 2019 at 04:41:51PM +0100, Hans Petter Selasky wrote: > On 3/13/19 4:16 PM, Steve Kargl wrote: > > On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote: > >> > >> gcc8 --version > >> gcc8 (FreeBSD Ports Collection) 8.3.0 > >&g

Re: Optimization bug with floating-point?

On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote: > All, > > There seems to an optimization bug with clang on > > % uname -a > FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT r344653 MOBILE i386 > > IOW, if you do numerica work on i386, you may want

Optimization bug with floating-point?

All, There seems to an optimization bug with clang on % uname -a FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT r344653 MOBILE i386 IOW, if you do numerica work on i386, you may want to check your results. The program demonstrating the issue is at the end of this email. gcc8 --version gcc8

Re: clang broken on current?

Having set CFLAGS+=-march=native -mtune=native and trying to force qt5-gui configure with -sse2 option, I have a config.summary that contains (my in-line comments ***) Build type: freebsd-clang (i386, CPU features: ) *** What? *** Compiler: clang 7.0.1 Configuration: compile_examples

Re: clang broken on current?

On Sun, Feb 10, 2019 at 11:13:09AM -0800, Mark Millard wrote: > > On 2019-Feb-10, at 10:46, Steve Kargl > wrote: > > > > On Sun, Feb 10, 2019 at 12:03:55PM +0100, Dimitry Andric wrote: > >> On 10 Feb 2019, at 06:00, Steve Kargl >> troutmask.apl.washingto

Re: clang broken on current?

On Sun, Feb 10, 2019 at 12:03:55PM +0100, Dimitry Andric wrote: > On 10 Feb 2019, at 06:00, Steve Kargl > wrote: > > How did you arrive at the conclusion that this has anything to do with > the specific compiler? From these errors, I think it is more likely >

Re: clang broken on current?

On Sun, Feb 10, 2019 at 12:03:55PM +0100, Dimitry Andric wrote: > On 10 Feb 2019, at 06:00, Steve Kargl > wrote: > > > > If I add 'CFLAGS+=-march=native -mtune=native', I can build > > world and kernel without a problem. If I try to build > > x11-t

Re: clang broken on current?

On Sun, Feb 10, 2019 at 12:03:55PM +0100, Dimitry Andric wrote: > On 10 Feb 2019, at 06:00, Steve Kargl > wrote: > > > > If I add 'CFLAGS+=-march=native -mtune=native', I can build > > world and kernel without a problem. If I try to build > > x11-t

Re: clang broken on current?

On Sun, Feb 10, 2019 at 12:03:55PM +0100, Dimitry Andric wrote: > On 10 Feb 2019, at 06:00, Steve Kargl > wrote: > > > > I have > > > > % uname -a > > FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT r343477 MOBILE i386 > > > > % dmesg | mo

clang broken on current?

I have % uname -a FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT r343477 MOBILE i386 % dmesg | more ... FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM 7.0.1) VT(vga): resolution 640x480 CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.05-MHz 686-class

Re: Is libc C99 compliant?

On Thu, Jan 31, 2019 at 09:32:11AM -0700, Warner Losh wrote: > On Wed, Jan 30, 2019 at 11:33 PM Steve Kargl < > s...@troutmask.apl.washington.edu> wrote: > > > Should/can TARGET_LIBC_HAS_FUNCTION be updated to at least > > default_libc_has_function? More importantly

Is libc C99 compliant?

When building gcc file gcc/config/freebsd.c contains #define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function In targhook.c, one finds /* By default we assume that c99 functions are present at the runtime, but sincos is not. */ bool default_libc_has_function (enum function_class fn_class)

Re: Head build unsafe for /etc today

On Thu, Nov 02, 2017 at 07:41:21PM -0700, Bryan Drewery wrote: > > Are you accusing me of lying? > Nope. I'm stating the obvious. If you are using META_MODE and you do "make buildwould" that is equivalent to "make -DNO_CLEAN buildworld", which means you did not rebuild the *world*. When I

Re: Head build unsafe for /etc today

On Thu, Nov 02, 2017 at 07:08:50PM -0700, Bryan Drewery wrote: > > > > On Nov 2, 2017, at 18:49, Steve Kargl <s...@troutmask.apl.washington.edu> > > wrote: > > > >> On Thu, Nov 02, 2017 at 06:25:24PM -0700, Bryan Drewery wrote: > >> > &g

Re: Head build unsafe for /etc today

On Thu, Nov 02, 2017 at 06:25:24PM -0700, Bryan Drewery wrote: > > On Nov 2, 2017, at 15:44, Mark Millard wrote: > > >> Author: bdrewery > >> Date: Thu Nov 2 22:23:00 2017 > >> New Revision: 325347 > >> URL: > >> https://svnweb.freebsd.org/changeset/base/325347 > >> > >>

Re: cpp behavior?

On Sat, May 20, 2017 at 11:39:14AM -0600, Ian Lepore wrote: > On Fri, 2017-05-19 at 17:07 -0700, Steve Kargl wrote: > > % which cpp > > /usr/bin/cpp > > troutmask:kargl[408] cpp --version > > FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on > &g

Re: Problems with out libgcc_s.so in base

On Thu, Aug 18, 2016 at 07:58:01PM -0400, Diane Bruce wrote: > On Thu, Aug 18, 2016 at 04:50:49PM -0700, Steve Kargl wrote: > > On Fri, Aug 19, 2016 at 01:14:32AM +0200, Tijl Coosemans wrote: > > > > > > > > For example, on one of my systems, I now have th

Re: Problems with out libgcc_s.so in base

On Fri, Aug 19, 2016 at 01:14:32AM +0200, Tijl Coosemans wrote: > > > > For example, on one of my systems, I now have these: > > > > /usr/local/lib/gcc47/libgcc_s.so.1 > > /usr/local/lib/gcc48/libgcc_s.so.1 > > /usr/local/lib/gcc49/libgcc_s.so.1 > > /usr/local/lib/gcc5/libgcc_s.so.1 > >

Re: Problems with out libgcc_s.so in base

On Thu, Aug 18, 2016 at 02:48:28PM +0200, Dimitry Andric wrote: > On 18 Aug 2016, at 11:15, Tijl Coosemans <t...@freebsd.org> wrote: > > > > On Wed, 17 Aug 2016 14:17:10 -0700 Steve Kargl > > <s...@troutmask.apl.washington.edu> wrote: > ... > >> % ld

Re: Problems with out libgcc_s.so in base

On Wed, Aug 17, 2016 at 06:12:51PM -0400, Diane Bruce wrote: > On Wed, Aug 17, 2016 at 02:17:10PM -0700, Steve Kargl wrote: > > On Sun, Aug 14, 2016 at 07:34:30PM -0400, Diane Bruce wrote: > > > On Sun, Aug 14, 2016 at 04:03:51PM -0700, Steve Kargl wrote: > > > > &g

Re: Problems with out libgcc_s.so in base

On Sun, Aug 14, 2016 at 07:34:30PM -0400, Diane Bruce wrote: > On Sun, Aug 14, 2016 at 04:03:51PM -0700, Steve Kargl wrote: > > > > Freebsd-ports could also use a wrapper: > > % cat ~/bin/gfc7 > > #! /bin/sh > > DIR=`id -P sgk | sed 's/\:/\ /g' |

Re: clang gets numerical underflow wrong, please fix.

On Mon, Mar 14, 2016 at 08:23:33PM +0100, Dimitry Andric wrote: > > Maybe this is a usable workaround for libm. > Thanks for looking into this. I just read the audit trail at llvm.org. Searching the clang user manual turns up The support for standard C in clang is feature-complete

Re: clang gets numerical underflow wrong, please fix.

On Mon, Mar 14, 2016 at 01:02:20AM +0100, Dimitry Andric wrote: > > $ gcc -O overflow-iter.c -o overflow-iter-gcc -lm > $ ./overflow-iter-gcc > FE_OVERFLOW: x = inf after 1024 iterations > $ gcc -O2 overflow-iter.c -o overflow-iter-gcc -lm > $ ./overflow-iter-gcc > FE_OVERFLOW: x = inf after

Re: clang gets numerical underflow wrong, please fix.

On Mon, Mar 14, 2016 at 01:02:20AM +0100, Dimitry Andric wrote: > On 13 Mar 2016, at 21:10, Steve Kargl <s...@troutmask.apl.washington.edu> > wrote: > > Thanks for the quick reply. But, it must be using an 80-bit > > extended double instead of a double for

Re: clang gets numerical underflow wrong, please fix.

On Sun, Mar 13, 2016 at 09:03:57PM +0100, Dimitry Andric wrote: > On 13 Mar 2016, at 19:25, Steve Kargl <s...@troutmask.apl.washington.edu> > wrote: > > > > Consider this small piece of code: > > > > #include > > #include > > > > float &g

clang gets numerical underflow wrong, please fix.

Consider this small piece of code: #include #include float foo() { static const volatile float tiny = 1.e-30f; return (tiny * tiny); } int main(void) { float x; feclearexcept(FE_ALL_EXCEPT); x = foo(); if (fetestexcept(FE_UNDERFLOW)) printf("FE_UNDERFLOW: ");

confusing messages from clang

If anyone is interesting fixing FreeBSD's C compiler, it would be appreciated. % cat foo.c #include #include void foo(int i) { if (i < 0) goto whoops; if (i == 0) printf("foo\n"); if (i > 0) goto corrupt; return; whoops: printf("whoops\n"); return

Re: Is this a compiler bug?

On Mon, Sep 22, 2014 at 08:46:07AM +0300, Andriy Gapon wrote: On 22/09/2014 05:20, Rui Paulo wrote: On Sep 21, 2014, at 18:48, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sun, Sep 21, 2014 at 06:38:48PM -0700, Rui Paulo wrote: On Sep 21, 2014, at 18:19, Steve Kargl s

Is this a compiler bug?

#include stdio.h #include stdint.h int main(void) { uint16_t i; i = 0x3ff0+63; printf(%x\n, i); i = 0x3ff1+63; printf(%x\n, i); i = 0x3ff2+63; printf(%x\n, i); i = 0x3ff3+63; printf(%x\n, i); i = 0x3ff4+63; printf(%x\n, i); i = 0x3ff4+63;

Re: Is this a compiler bug?

On Sun, Sep 21, 2014 at 06:38:48PM -0700, Rui Paulo wrote: On Sep 21, 2014, at 18:19, Steve Kargl s...@troutmask.apl.washington.edu wrote: #include stdio.h #include stdint.h int main(void) { uint16_t i; i = 0x3ff0+63; printf(%x\n, i); i = 0x3ff1+63; printf(%x\n

Re: status of clang on sparc64?

On Sat, Sep 13, 2014 at 10:23:22AM +0200, Roman Divacky wrote: On Thu, Sep 11, 2014 at 05:04:06PM -0700, Steve Kargl wrote: What's the current status for running clang on sparc64? Last time we played with this (february?) it was able to compile a seemingly working world. So I guess it's

Re: Lock annotations: enable them for libpthread, libstdthreads

On Sat, Aug 30, 2014 at 07:33:27AM +0200, Ed Schouten wrote: On 28 August 2014 19:34, Ed Schouten e...@80386.nl wrote: My gut feeling is that impact is minimal. Buildworlds seem to take approximately the same time, mainly because we don't have that many annotated

Re: GCC withdraw

On Fri, Aug 30, 2013 at 08:33:21AM +0100, David Chisnall wrote: On 29 Aug 2013, at 18:44, John Baldwin j...@freebsd.org wrote: default every time, that we're telling people not to use, won't help with that... This is your worst argument as clang is known to take far longer than GCC

Re: GCC withdraw

On Sun, Aug 25, 2013 at 11:08:57AM +0100, David Chisnall wrote: On 25 Aug 2013, at 00:06, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote: On 24 Aug 2013, at 23:42, Slawa Olhovchenkov s...@zxy.spb.ru wrote: And i

Re: GCC withdraw

On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote: On 24 Aug 2013, at 23:42, Slawa Olhovchenkov s...@zxy.spb.ru wrote: And i found PR about clang and mplayer: ports/176272 This PR contains log with build error log. Please file clang bugs at http://llvm.org/bugs/ As if

Re: [CFT] gcc: support for barcelona

On Tue, May 28, 2013 at 01:01:00PM -0700, Rui Paulo wrote: On 28 May 2013, at 12:54, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Tue, May 28, 2013 at 07:10:23PM +0100, David Chisnall wrote: On 28 May 2013, at 18:40, Warner Losh i...@bsdimp.com wrote: That's not going

Re: Clang as default compiler November 4th

On Fri, Sep 14, 2012 at 03:23:19PM -0500, Brooks Davis wrote: On Thu, Sep 13, 2012 at 09:10:24AM -0700, Steve Kargl wrote: ok 1 - cexp zero Abort trap (core dumped) *** [tests] Error code 134 Stop in /usr/src/tools/regression/lib/msun. Prompted by this post, I did a bit of testing

Re: Clang as default compiler November 4th

On Fri, Sep 14, 2012 at 05:18:08PM -0700, Steve Kargl wrote: A third class of failure appears to be that clang emits i387 fpu instructions for at least sinf and cosf instead of calls to the library routines. AFAIK, the library routines are faster and more accurate. Yep. Clang has

Re: Clang as default compiler November 4th

On Thu, Sep 13, 2012 at 09:32:12AM -0600, Ian Lepore wrote: On Wed, 2012-09-12 at 19:08 -0700, Steve Kargl wrote: In regards to my initial post in this thread, I was just trying to assess whether any benchmarks have been performed on FreeBSD for floating point generated by clang. Other

Re: Clang as default compiler November 4th

On Tue, Sep 11, 2012 at 04:10:13PM +0200, Dimitry Andric wrote: On 2012-09-11 15:24, Steve Kargl wrote: ... How fast clang builds world in comparison to gcc is irrelevant. Not at all irrelevant: this proposal is about changing the default compiler for the FreeBSD system itself, not for all

Re: Clang as default compiler November 4th

On Tue, Sep 11, 2012 at 04:27:55PM +0200, Tijl Coosemans wrote: On 11-09-2012 16:10, Dimitry Andric wrote: On 2012-09-11 15:24, Steve Kargl wrote: What is important is whether software built with clang functions correctly. See for example, http://math-atlas.sourceforge.net/errata.html

Re: Clang as default compiler November 4th

On Tue, Sep 11, 2012 at 12:14:09PM -0500, Mark Felder wrote: Clang produces incorrect code vs Clang's floating point has issues are two different arguments. Wow. clang produces incorrect floating point code, and that's somehow just an issue with floating point. For a mathematical