Re: Clang as default compiler November 4th
LLVM by default turns these: case LibFunc::copysign: case LibFunc::copysignf: case LibFunc::copysignl: case LibFunc::fabs: case LibFunc::fabsf: case LibFunc::fabsl: case LibFunc::sin: case LibFunc::sinf: case LibFunc::sinl: case LibFunc::cos: case LibFunc::cosf: case LibFunc::cosl: case LibFunc::sqrt: case LibFunc::sqrtf: case LibFunc::sqrtl: case LibFunc::floor: case LibFunc::floorf: case LibFunc::floorl: case LibFunc::nearbyint: case LibFunc::nearbyintf: case LibFunc::nearbyintl: case LibFunc::ceil: case LibFunc::ceilf: case LibFunc::ceill: case LibFunc::rint: case LibFunc::rintf: case LibFunc::rintl: case LibFunc::trunc: case LibFunc::truncf: case LibFunc::truncl: case LibFunc::log2: case LibFunc::log2f: case LibFunc::log2l: case LibFunc::exp2: case LibFunc::exp2f: case LibFunc::exp2l: from lib calls to direct code (ie. instruction or sequence of). This is not a bug but feature ;) I am not sure what the rules for the transformation should be. Allow it only with -ffast-math ? Disallow it on i386? Really, no idea. Steve, you tested on i386? Can you test on amd64? Do you guys have any opinion what to do here? On Fri, Sep 14, 2012 at 06:06:00PM -0700, Steve Kargl wrote: 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 problems with at least sinf on i386 FreeBSD. % pwd /usr/home/kargl/trunk/math/sine % make clean make CC=cc testf cc -o testf -O2 -pipe -static -I/usr/local/include -I../mp testf.c \ -L/usr/local/lib -L../mp -lsgk -lmpfr -lgmp -lm % ./testf -m 0 -M 1e20 -r ULP Range | ---+- [0.0:0.6] | 1006424(100.00%) (0.6:0.7] | 0 ( 0.00%) (0.7:0.8] | 0 ( 0.00%) (0.8:0.9] | 0 ( 0.00%) (0.9:1.0] | 0 ( 0.00%) (1.0:2.0] | 0 ( 0.00%) (2.0:3.0] | 0 ( 0.00%) 3.0 ULP | 0 ( 0.00%) ---+- Count | 1006424 Max ULP | 0.50084 Max ULP x | 53462490661259313152.00 0x1.72f876p+65 % make clean make CC=clang testf clang -o testf -O2 -pipe -static -I/usr/local/include -I../mp testf.c \ -L/usr/local/lib -L../mp -lsgk -lmpfr -lgmp -lm % ./testf -m 0 -M 1e20 -r ULP Range | ---+- [0.0:0.6] | 1 ( 0.00%) (0.6:0.7] | 0 ( 0.00%) (0.7:0.8] | 0 ( 0.00%) (0.8:0.9] | 0 ( 0.00%) (0.9:1.0] | 0 ( 0.00%) (1.0:2.0] | 0 ( 0.00%) (2.0:3.0] | 0 ( 0.00%) 3.0 ULP | 98 (100.00%) ---+- Count | 99 Max ULP | 1328505256679420125050194353979392.0 Max ULP x | 75516780764213542912.00 0x1.06006p+66 -- Steve ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On 15-09-2012 03:06, Steve Kargl wrote: 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 problems with at least sinf on i386 FreeBSD. % pwd /usr/home/kargl/trunk/math/sine % make clean make CC=cc testf cc -o testf -O2 -pipe -static -I/usr/local/include -I../mp testf.c \ -L/usr/local/lib -L../mp -lsgk -lmpfr -lgmp -lm % ./testf -m 0 -M 1e20 -r ULP Range | ---+- [0.0:0.6] | 1006424(100.00%) (0.6:0.7] | 0 ( 0.00%) (0.7:0.8] | 0 ( 0.00%) (0.8:0.9] | 0 ( 0.00%) (0.9:1.0] | 0 ( 0.00%) (1.0:2.0] | 0 ( 0.00%) (2.0:3.0] | 0 ( 0.00%) 3.0 ULP | 0 ( 0.00%) ---+- Count | 1006424 Max ULP | 0.50084 Max ULP x | 53462490661259313152.00 0x1.72f876p+65 % make clean make CC=clang testf clang -o testf -O2 -pipe -static -I/usr/local/include -I../mp testf.c \ -L/usr/local/lib -L../mp -lsgk -lmpfr -lgmp -lm % ./testf -m 0 -M 1e20 -r ULP Range | ---+- [0.0:0.6] | 1 ( 0.00%) (0.6:0.7] | 0 ( 0.00%) (0.7:0.8] | 0 ( 0.00%) (0.8:0.9] | 0 ( 0.00%) (0.9:1.0] | 0 ( 0.00%) (1.0:2.0] | 0 ( 0.00%) (2.0:3.0] | 0 ( 0.00%) 3.0 ULP | 98 (100.00%) ---+- Count | 99 Max ULP | 1328505256679420125050194353979392.0 Max ULP x | 75516780764213542912.00 0x1.06006p+66 A ULP this big can't be because of using a built-in instead of a library call, right? Something must be wrong with clang's implementation of the built-in. The fcos/fsin instructions have a limited domain and return a value unchanged if it's outside that domain. Maybe clang doesn't check this. This error probably also explains the precision loss in j0, because it calls cos/sin. signature.asc Description: OpenPGP digital signature
Re: Clang as default compiler November 4th
Fwiw, this seems to have been fixed as of a few minutes ago. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120910/150720.html Steve, can you please test llvm/clang from (their) svn and report back? We can import a newer snapshot if all is ok. Thank you. On Fri, Sep 14, 2012 at 06:06:00PM -0700, Steve Kargl wrote: 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 problems with at least sinf on i386 FreeBSD. % pwd /usr/home/kargl/trunk/math/sine % make clean make CC=cc testf cc -o testf -O2 -pipe -static -I/usr/local/include -I../mp testf.c \ -L/usr/local/lib -L../mp -lsgk -lmpfr -lgmp -lm % ./testf -m 0 -M 1e20 -r ULP Range | ---+- [0.0:0.6] | 1006424(100.00%) (0.6:0.7] | 0 ( 0.00%) (0.7:0.8] | 0 ( 0.00%) (0.8:0.9] | 0 ( 0.00%) (0.9:1.0] | 0 ( 0.00%) (1.0:2.0] | 0 ( 0.00%) (2.0:3.0] | 0 ( 0.00%) 3.0 ULP | 0 ( 0.00%) ---+- Count | 1006424 Max ULP | 0.50084 Max ULP x | 53462490661259313152.00 0x1.72f876p+65 % make clean make CC=clang testf clang -o testf -O2 -pipe -static -I/usr/local/include -I../mp testf.c \ -L/usr/local/lib -L../mp -lsgk -lmpfr -lgmp -lm % ./testf -m 0 -M 1e20 -r ULP Range | ---+- [0.0:0.6] | 1 ( 0.00%) (0.6:0.7] | 0 ( 0.00%) (0.7:0.8] | 0 ( 0.00%) (0.8:0.9] | 0 ( 0.00%) (0.9:1.0] | 0 ( 0.00%) (1.0:2.0] | 0 ( 0.00%) (2.0:3.0] | 0 ( 0.00%) 3.0 ULP | 98 (100.00%) ---+- Count | 99 Max ULP | 1328505256679420125050194353979392.0 Max ULP x | 75516780764213542912.00 0x1.06006p+66 -- Steve ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On 15-09-2012 14:48, Roman Divacky wrote: Fwiw, this seems to have been fixed as of a few minutes ago. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120910/150720.html Steve, can you please test llvm/clang from (their) svn and report back? We can import a newer snapshot if all is ok. Here's a small test program. You're probably better equipped to test clang svn. #include math.h #include stdio.h #include stdlib.h int main( int argc, char **argv ) { double d = strtod( argv[ 1 ], NULL ); printf( %e\n, ( double ) cos( d )); printf( %e\n, ( double ) cosf( d )); printf( %e\n, ( double ) cosl( d )); return( 0 ); } This is the current output of clang: % clang -o cos cos.c -lm % ./cos 1.23456789e20 6.031937e-01 1.234568e+20 2.814722e-01 The second number (cosf) is wrong. It should be a value between -1 and 1. signature.asc Description: OpenPGP digital signature
Re: Clang as default compiler November 4th
Is this correct? lev ~$ ./cos 1.23456789e20 6.031937e-01 -9.629173e-02 2.814722e-01 If so I believe the issue is fixed. On Sat, Sep 15, 2012 at 03:48:38PM +0200, Tijl Coosemans wrote: On 15-09-2012 14:48, Roman Divacky wrote: Fwiw, this seems to have been fixed as of a few minutes ago. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120910/150720.html Steve, can you please test llvm/clang from (their) svn and report back? We can import a newer snapshot if all is ok. Here's a small test program. You're probably better equipped to test clang svn. #include math.h #include stdio.h #include stdlib.h int main( int argc, char **argv ) { double d = strtod( argv[ 1 ], NULL ); printf( %e\n, ( double ) cos( d )); printf( %e\n, ( double ) cosf( d )); printf( %e\n, ( double ) cosl( d )); return( 0 ); } This is the current output of clang: % clang -o cos cos.c -lm % ./cos 1.23456789e20 6.031937e-01 1.234568e+20 2.814722e-01 The second number (cosf) is wrong. It should be a value between -1 and 1. ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On Thu, Sep 13, 2012 at 09:10:24AM -0700, Steve Kargl wrote: 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 than the limited testing that I've done, it appears that the answer is 'no'. We have src/tools/tests/testfloat and src/tools/regression/lib/msun. I know nothing about the former (just noticed it for the first time). The latter I think is a set of correctness tests rather than performance tests. It's quite clear that the clang proponent have not tried to run src/tools/regression/lib/msun. % setenv CC clang % make | grep warning | wc -l 1354 % make clean % make | tee make.log % head -20 make.log clang -O2 -pipe -march=opteron -O0 -lm test-cexp.c -o test-cexp test-cexp.c:49:14: warning: pragma STDC FENV_ACCESS ON is not supported, ignoring pragma [-Wunknown-pragmas] #pragma STDC FENV_ACCESSON ^ test-cexp.c:183:2: warning: expression result unused [-Wunused-value] testall(0.0, 1.0, ALL_STD_EXCEPT, 0, 1); ^~~ test-cexp.c:98:7: note: expanded from macro 'testall' test(cexp, x, result, exceptmask, excepts, checksign); \ ^ test-cexp.c:87:11: note: expanded from macro 'test' assert(((func), fetestexcept(exceptmask) == (excepts)));\ ^ /usr/include/assert.h:54:21: note: expanded from macro 'assert' #define assert(e) ((e) ? (void)0 : __assert(__func__, __FILE__, \ ^ test-cexp.c:183:2: warning: expression result unused [-Wunused-value] testall(0.0, 1.0, ALL_STD_EXCEPT, 0, 1); ^~~ test-cexp.c:99:7: note: expanded from macro 'testall' % tail -20 make.log test-trig.c:69:11: note: expanded from macro 'test' assert(((func), fetestexcept(exceptmask) == (excepts)));\ ^ /usr/include/assert.h:54:21: note: expanded from macro 'assert' #define assert(e) ((e) ? (void)0 : __assert(__func__, __FILE__, \ ^ 74 warnings generated. clang -O2 -pipe -march=opteron -O0 -lm test-fenv.c -o test-fenv test-fenv.c:82:14: warning: pragma STDC FENV_ACCESS ON is not supported, ignoring pragma [-Wunknown-pragmas] #pragma STDC FENV_ACCESS ON ^ 1 warning generated. for p in test-cexp test-conj test-csqrt test-ctrig test-exponential test-fma test-fmaxmin test-ilogb test-invtrig test-logarithm test-lrint test-lround test-nan test-nearbyint test-next test-rem test-trig test-fenv; do /usr/src/tools/regression/lib/msun/$p; done Assertion failed: (((cexp), fetestexcept((0x04 | 0x20 | 0x01 | 0x08 | 0x10)) == (0))), function test_nan, file test-cexp.c, line 211. 1..7 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 and it looks like we have two classes of failures that need to be investigated. First, some tests are failing with a gcc compiled world and clang compiled test code. They seem to mostly be unexpected fp exception state when testing with NaNs. I suspect that someone more knowledgeable in this area could come up with a reduced test case and explication of what clang is doing wrong pretty quickly. The second class is tests that fail when libm is compiled using clang. I've not investigate those at all. I'd tend to guess that we have a wider range of issues there. This is clearly an area we need more focus on before a switch to clang. To a point I would be OK with it delaying the switch to work these issues, but as with C99 long double support we can't let the quest for perfection delay us indefinitely. -- Brooks pgpZPRfhJu5W1.pgp Description: PGP signature
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 and it looks like we have two classes of failures that need to be investigated. First, some tests are failing with a gcc compiled world and clang compiled test code. They seem to mostly be unexpected fp exception state when testing with NaNs. I suspect that someone more knowledgeable in this area could come up with a reduced test case and explication of what clang is doing wrong pretty quickly. The second class is tests that fail when libm is compiled using clang. I've not investigate those at all. I'd tend to guess that we have a wider range of issues there. 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. % cat a.c #include math.h float foo(float x) { float a; a = sinf(x) * cosf(x); return (a); } % clang -S -O a.c foo:# @foo # BB#0: # %entry flds4(%esp) fld %st(0) fcos fxch fsin fmulp ret % cc -S -O a.c foo: pushl %ebp movl%esp, %ebp pushl %ebx subl$20, %esp movl8(%ebp), %ebx movl%ebx, (%esp) callsinf fstps -8(%ebp) movl%ebx, (%esp) callcosf fmuls -8(%ebp) addl$20, %esp popl%ebx popl%ebp ret % clang -S -O -fno-builtin a.c foo:# @foo # BB#0: # %entry pushl %ebp movl%esp, %ebp subl$24, %esp flds8(%ebp) fsts-16(%ebp) # 4-byte Folded Spill fstps (%esp) calll sinf fstpt -12(%ebp) # 10-byte Folded Spill flds-16(%ebp) # 4-byte Folded Reload fstps (%esp) calll cosf fldt-12(%ebp) # 10-byte Folded Reload fmulp addl$24, %esp popl%ebp ret Using -fno-builtin would seem to be a non-starter in that it disables all builtin functions. -- Steve ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
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 problems with at least sinf on i386 FreeBSD. % pwd /usr/home/kargl/trunk/math/sine % make clean make CC=cc testf cc -o testf -O2 -pipe -static -I/usr/local/include -I../mp testf.c \ -L/usr/local/lib -L../mp -lsgk -lmpfr -lgmp -lm % ./testf -m 0 -M 1e20 -r ULP Range | ---+- [0.0:0.6] | 1006424(100.00%) (0.6:0.7] | 0 ( 0.00%) (0.7:0.8] | 0 ( 0.00%) (0.8:0.9] | 0 ( 0.00%) (0.9:1.0] | 0 ( 0.00%) (1.0:2.0] | 0 ( 0.00%) (2.0:3.0] | 0 ( 0.00%) 3.0 ULP | 0 ( 0.00%) ---+- Count | 1006424 Max ULP | 0.50084 Max ULP x | 53462490661259313152.00 0x1.72f876p+65 % make clean make CC=clang testf clang -o testf -O2 -pipe -static -I/usr/local/include -I../mp testf.c \ -L/usr/local/lib -L../mp -lsgk -lmpfr -lgmp -lm % ./testf -m 0 -M 1e20 -r ULP Range | ---+- [0.0:0.6] | 1 ( 0.00%) (0.6:0.7] | 0 ( 0.00%) (0.7:0.8] | 0 ( 0.00%) (0.8:0.9] | 0 ( 0.00%) (0.9:1.0] | 0 ( 0.00%) (1.0:2.0] | 0 ( 0.00%) (2.0:3.0] | 0 ( 0.00%) 3.0 ULP | 98 (100.00%) ---+- Count | 99 Max ULP | 1328505256679420125050194353979392.0 Max ULP x | 75516780764213542912.00 0x1.06006p+66 -- Steve ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On Thu, Sep 13, 2012 at 08:21:31AM +0200, Pietro Cerutti wrote: On 2012-Sep-11, 23:29, Doug Barton wrote: What we need to do is what I and others have been asking to do for years. We need to designate a modern version of gcc (no less than 4.6) as the official default ports compiler, and rework whatever is needed to support this. Fortunately, that goal is much more easily achieved than fixing ports to build and run with clang. (It's harder than it sounds because there are certain key libs that define some paths depending on what compiler they were built with, but still easier than dealing with clang in the short term.) I like the idea very much. My only concern is that gcc is heavy to build. Gerald has been advocating this for a while as well. In fact, he's just made a commit that makes the lang/gcc42 compiler much easier to bootstrap itself. There's a set of interlocking changes that we need to make to the infrastructure to modernize our compiler choices. I've been talking to Gerald about some of the aspects of it and hope to have something to propose fairly soon. But IMHO it's a little bit trickier than it appears at first glance. mcl ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
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 than the limited testing that I've done, it appears that the answer is 'no'. We have src/tools/tests/testfloat and src/tools/regression/lib/msun. I know nothing about the former (just noticed it for the first time). The latter I think is a set of correctness tests rather than performance tests. -- Ian ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
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 than the limited testing that I've done, it appears that the answer is 'no'. We have src/tools/tests/testfloat and src/tools/regression/lib/msun. I know nothing about the former (just noticed it for the first time). The latter I think is a set of correctness tests rather than performance tests. It's quite clear that the clang proponent have not tried to run src/tools/regression/lib/msun. % setenv CC clang % make | grep warning | wc -l 1354 % make clean % make | tee make.log % head -20 make.log clang -O2 -pipe -march=opteron -O0 -lm test-cexp.c -o test-cexp test-cexp.c:49:14: warning: pragma STDC FENV_ACCESS ON is not supported, ignoring pragma [-Wunknown-pragmas] #pragma STDC FENV_ACCESSON ^ test-cexp.c:183:2: warning: expression result unused [-Wunused-value] testall(0.0, 1.0, ALL_STD_EXCEPT, 0, 1); ^~~ test-cexp.c:98:7: note: expanded from macro 'testall' test(cexp, x, result, exceptmask, excepts, checksign); \ ^ test-cexp.c:87:11: note: expanded from macro 'test' assert(((func), fetestexcept(exceptmask) == (excepts)));\ ^ /usr/include/assert.h:54:21: note: expanded from macro 'assert' #define assert(e) ((e) ? (void)0 : __assert(__func__, __FILE__, \ ^ test-cexp.c:183:2: warning: expression result unused [-Wunused-value] testall(0.0, 1.0, ALL_STD_EXCEPT, 0, 1); ^~~ test-cexp.c:99:7: note: expanded from macro 'testall' % tail -20 make.log test-trig.c:69:11: note: expanded from macro 'test' assert(((func), fetestexcept(exceptmask) == (excepts)));\ ^ /usr/include/assert.h:54:21: note: expanded from macro 'assert' #define assert(e) ((e) ? (void)0 : __assert(__func__, __FILE__, \ ^ 74 warnings generated. clang -O2 -pipe -march=opteron -O0 -lm test-fenv.c -o test-fenv test-fenv.c:82:14: warning: pragma STDC FENV_ACCESS ON is not supported, ignoring pragma [-Wunknown-pragmas] #pragma STDC FENV_ACCESS ON ^ 1 warning generated. for p in test-cexp test-conj test-csqrt test-ctrig test-exponential test-fma test-fmaxmin test-ilogb test-invtrig test-logarithm test-lrint test-lround test-nan test-nearbyint test-next test-rem test-trig test-fenv; do /usr/src/tools/regression/lib/msun/$p; done Assertion failed: (((cexp), fetestexcept((0x04 | 0x20 | 0x01 | 0x08 | 0x10)) == (0))), function test_nan, file test-cexp.c, line 211. 1..7 ok 1 - cexp zero Abort trap (core dumped) *** [tests] Error code 134 Stop in /usr/src/tools/regression/lib/msun. So, clang does not support #pragma STDC FENV_ACCESS ON. That (IMHO) is a show stopper for clang as the default compiler, because at least msun/src/e_sqrtl.c uses this pragma. -- Steve ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On Tue, Sep 11, 2012 at 11:27:50AM +0200, Lars Engels wrote: At the moment the ports maintainers don't give much about if their ports build with CLANG or not because they're not forced to. I think this is a mis-representation. Adding the requirement your ports must work on clang is adding an ex-post-facto requirement. This creates the following matrix of what we are implicitly asking maintainers to do: (FreeBSD 7|8|9|10) * (amd64|arm|i386|powerpc|sparc64) * (base gcc|base clang) It is completely insane to expect anyone to be able to test in all of those environments, or even a tiny subset of them. This isn't what most people sign up for when they sign up to maintain ports. Those who don't run CURRENT won't notice, but those who do will have to get their butts up and fix the ports I think it's foolish to assume that maintainres don't have their butts in gear as it is. Please note, we have nearly 1300 PRs, hundreds of ports with build errors and/or PRs, and hundreds that fail on -current only. I try to advertise all these things the best I know how. Adding the hundreds that fail on -clang only and then blaming the maintainers is simply going to be counter-productive. mcl ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On 09/11/2012 02:52 AM, Erik Cederstrand wrote: So can we do a sweep on the ports tree and mark the 2232 ports with USE_GCC=4.2 until they can actually build with clang? Unfortunately it isn't that simple. We already have a statistically significant number of ports that don't even compile with gcc 4.2.1. How many compilers do we expect the users to install? :) What we need to do is what I and others have been asking to do for years. We need to designate a modern version of gcc (no less than 4.6) as the official default ports compiler, and rework whatever is needed to support this. Fortunately, that goal is much more easily achieved than fixing ports to build and run with clang. (It's harder than it sounds because there are certain key libs that define some paths depending on what compiler they were built with, but still easier than dealing with clang in the short term.) Once that is done, the compiler in the base is an afterthought, and we can do away with gcc in the base altogether much more easily. Users who want to help support building ports with clang can continue to do so. Doug ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On 09/11/2012 11:15 PM, Mark Linimon wrote: On Tue, Sep 11, 2012 at 11:27:50AM +0200, Lars Engels wrote: At the moment the ports maintainers don't give much about if their ports build with CLANG or not because they're not forced to. I think this is a mis-representation. Adding the requirement your ports must work on clang is adding an ex-post-facto requirement. This creates the following matrix of what we are implicitly asking maintainers to do: (FreeBSD 7|8|9|10) * (amd64|arm|i386|powerpc|sparc64) * (base gcc|base clang) It is completely insane to expect anyone to be able to test in all of those environments, or even a tiny subset of them. This isn't what most people sign up for when they sign up to maintain ports. Those who don't run CURRENT won't notice, but those who do will have to get their butts up and fix the ports I think it's foolish to assume that maintainres don't have their butts in gear as it is. Please note, we have nearly 1300 PRs, hundreds of ports with build errors and/or PRs, and hundreds that fail on -current only. I try to advertise all these things the best I know how. Adding the hundreds that fail on -clang only and then blaming the maintainers is simply going to be counter-productive. Write the day on your calendars folks, I completely agree with what Mark said above. :) This is a big part of what I meant with some of my more colorful comments in my original post on this topic. Doug ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
Den 12/09/2012 kl. 11.29 skrev Doug Barton do...@freebsd.org: On 09/11/2012 02:52 AM, Erik Cederstrand wrote: So can we do a sweep on the ports tree and mark the 2232 ports with USE_GCC=4.2 until they can actually build with clang? Unfortunately it isn't that simple. We already have a statistically significant number of ports that don't even compile with gcc 4.2.1. How many compilers do we expect the users to install? :) If a port doesn't compile with the default compiler in base, I expect that port to add a build dependency on the compiler that it actually does compiles with. Of course, I hope to not have 6 different compilers installed on my system, but the list of build or runtime dependencies are at the discretion of the port (maintainer). As you (I think) said, we can't force port maintainers to patch their ports to support clang. So even today, we have a significant number of ports that don't compile with the default compiler (GCC 4.2.1). Aren't they broken already, in the sense that they fail to tell me, the user, which compiler I should use? Thanks, Erik___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On 12 Sep 2012, at 10:09, Doug Barton wrote: Also, users who actually are helping with testing clang for ports continue to report runtime problems, even with things that build fine. I hope that you are encouraging maintainers of ports that don't work as expected with clang to submit bug reports upstream. We can't fix bugs if we aren't made aware of them. David Current hat: LLVM / Clang developer.___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On Tue, 11 Sep 2012, Erik Cederstrand wrote: So can we do a sweep on the ports tree and mark the 2232 ports with USE_GCC=4.2 until they can actually build with clang? This could allow the clang switch to proceed. Hopefully, waiting for GCC to compile just to install some tiny port will be enough of a nuisance for people to eventually fix the remaining ports. To make it less painful, I just adjusted lang/gcc42 to not boostrap any more, rather just build. This allows for a full build in ten or less minutes on an old quad core I used for testing. Gerald ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
I'd add one more thing that needs fixing: Clang should default to c89 mode when invoked as cc. I had a patch to do this, but I seem to have misplaced it. I'll try to find or rewrite it in the next couple of days. A lot of the ports failures I saw were due to ports using cc as the default C compiler (autoconf seems to select it) and then using GNU89 inlining rules, so that they died with linker failures. Given that POSIX deprecated cc in 1997, I'm quite tempted to say that we should just remove it entirely and just have c89, c99 and c11 (which the spec for cc says you should use instead), forcing people to explicitly select their language dialect, but that's a bikeshed for another day. David On 10 Sep 2012, at 22:12, Brooks Davis wrote: [Please confine your replies to toolch...@freebsd.org to keep the thread on the most relevant list.] For the past several years we've been working towards migrating from GCC to Clang/LLVM as our default compiler. We intend to ship FreeBSD 10.0 with Clang as the default compiler on i386 and amd64 platforms. To this end, we will make WITH_CLANG_IS_CC the default on i386 and amd64 platforms on November 4th. What does the mean to you? * When you build world after the default is changed /usr/bin/cc, cpp, and c++ will be links to clang. * This means the initial phase of buildworld and old style kernel compilation will use clang instead of gcc. This is known to work. * It also means that ports will build with clang by default. A major of ports work, but a significant number are broken or blocked by broken ports. For more information see: http://wiki.freebsd.org/PortsAndClang What issues remain? * The gcc-clang transition currently requires setting CC, CXX, and CPP in addition to WITH_CLANG_IS_CC. I will post a patch to toolchain@ to address this shortly. * Ports compiler selection infrastructure is still under development. * Some ports could build with clang with appropriate tweaks. What can you do to help? * Switch (some of) your systems. Early adoption can help us find bugs. * Fix ports to build with clang. If you don't have a clang system, you can use the CLANG/amd64 or CLANG/i386 build environments on redports.org. tl;dr: Clang will become the default compiler for x86 architectures on 2012-11-04 -- Brooks ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On 11 Sep 2012, at 09:18, Dimitry Andric wrote: So I am a bit reluctant to change clang's default standard to c89, unless clang upstream agrees with this. In the interest of prodding people to update their software, I would rather have the default stay c99, personally. :) I'm not proposing changing the default when invoked as clang. When invoked as clang or clang++, the default remains the same: the latest version of the standard (which will be C11 and C++11 in clang 3.2). I am proposing changing the default to be C89 when invoked as cc or c89. Clang upstream is happy with this (I asked on the mailing list at BSDCan, I just never got around to committing the change) and it also fixes another bug: clang is always in C99 mode, even when invoked as c89 or c11. Given that POSIX deprecated cc in 1997, I'm quite tempted to say that we should just remove it entirely and just have c89, c99 and c11 (which the spec for cc says you should use instead), forcing people to explicitly select their language dialect, but that's a bikeshed for another day. I think that is a little bit overkill. People who don't care about standards anyway, will not go through the trouble of setting CC carefully to 'c89', 'c99' or 'c11'. Most of their software simply hardcodes gcc, and must be fixed manually after all. There is some logic in the clang driver already for knowing when it is invoked as gcc. I'd be quite tempted to make gcc a symlink to clang and make clang default to gnu89 when invoked in that way. David___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On Mon, Sep 10, 2012 at 10:54:04PM -0700, Doug Barton wrote: As of last week, 4,680 ports out of 23,857 failed to build with clang on 9-amd64. That's almost a 20% failure rate. Until we have better support for either building ports with clang, or have better support for the idea of a ports compiler, this change is premature. The ports are an important part of the FreeBSD Operating _System_, and pulling the trigger on the default compiler before the ports problems are addressed robustly seems like a big fat FU. That said, I agree that this issue needs to be addressed. In fact, 9 months before the release of 9.0 I said on the internal committers list that there was no point in making a new release until we had thoroughly addressed both the default compiler for the base, and resolving the ports compiler issue. While there has been some movement on the former, there has been nothing done on the latter for years now, even though everyone agrees that it is an important issue. I'd like to request that rather than moving the default compiler prematurely that you call for volunteers to address the problems with the ports. Both the issues of fixing more ports to build correctly with clang, and the issue of defining a ports compiler version of gcc (and appropriate infrastructure) for those that can't. Once those issues are resolved there would not be any further obstacles to moving the default. Until they are, the change is premature. Doug Doug, as you can already use CLANG instead of GCC now, you will be able to use GCC instead of CLANG after November 4th. At the moment the ports maintainers don't give much about if their ports build with CLANG or not because they're not forced to. Those who don't run CURRENT won't notice, but those who do will have to get their butts up and fix the ports, so 10.0 can have 99% of all ports build with CLANG and even 8.x and 9.x can already profit from having the broken ports fixed now. pgpJylqaSN0pf.pgp Description: PGP signature
Re: Clang as default compiler November 4th
On 09/11/2012 02:27 AM, Lars Engels wrote: On Mon, Sep 10, 2012 at 10:54:04PM -0700, Doug Barton wrote: As of last week, 4,680 ports out of 23,857 failed to build with clang on 9-amd64. That's almost a 20% failure rate. Until we have better support for either building ports with clang, or have better support for the idea of a ports compiler, this change is premature. The ports are an important part of the FreeBSD Operating _System_, and pulling the trigger on the default compiler before the ports problems are addressed robustly seems like a big fat FU. That said, I agree that this issue needs to be addressed. In fact, 9 months before the release of 9.0 I said on the internal committers list that there was no point in making a new release until we had thoroughly addressed both the default compiler for the base, and resolving the ports compiler issue. While there has been some movement on the former, there has been nothing done on the latter for years now, even though everyone agrees that it is an important issue. I'd like to request that rather than moving the default compiler prematurely that you call for volunteers to address the problems with the ports. Both the issues of fixing more ports to build correctly with clang, and the issue of defining a ports compiler version of gcc (and appropriate infrastructure) for those that can't. Once those issues are resolved there would not be any further obstacles to moving the default. Until they are, the change is premature. Doug Doug, as you can already use CLANG instead of GCC now, you will be able to use GCC instead of CLANG after November 4th. There's lots of things I _can_ do, what we're discussing is what the defaults should be. At the moment the ports maintainers don't give much about if their ports build with CLANG or not Do you follow ports development? At all? There have been extensive efforts over the last several years to get more ports compiling with clang. The problem is that things like the c89 issue don't percolate down, and we don't have a concerted effort from all of the relevant parties to improve the issue. Fixing the problem of getting the right eyeballs on the things that need fixing won't be improved by switching the default before they are fixed. In fact, it's likely to make the people who are src-centric now even less likely to help because their work will be done. Those who don't run CURRENT won't notice, but those who do will have to get their butts up and fix the ports, so 10.0 can have 99% of all ports build with CLANG and even 8.x and 9.x can already profit from having the broken ports fixed now. Yeah, and I'm going to get a pony out of this deal, right? :) You completely misunderstand the nature of the problem, therefore your proposed solution isn't going to solve it. Doug ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On Mon, Sep 10, 2012 at 04:12:07PM -0500, Brooks Davis wrote: [Please confine your replies to toolch...@freebsd.org to keep the thread on the most relevant list.] I do not see how removing current@ can be done, toolchain@ is not relevant for this discussion. Proposed is not a local change in the toolchain itself, but a far reaching and IMO premature change. For the past several years we've been working towards migrating from GCC to Clang/LLVM as our default compiler. We intend to ship FreeBSD 10.0 with Clang as the default compiler on i386 and amd64 platforms. To this end, we will make WITH_CLANG_IS_CC the default on i386 and amd64 platforms on November 4th. What does the mean to you? * When you build world after the default is changed /usr/bin/cc, cpp, and c++ will be links to clang. * This means the initial phase of buildworld and old style kernel compilation will use clang instead of gcc. This is known to work. * It also means that ports will build with clang by default. A major of ports work, but a significant number are broken or blocked by broken ports. For more information see: http://wiki.freebsd.org/PortsAndClang What issues remain? * The gcc-clang transition currently requires setting CC, CXX, and CPP in addition to WITH_CLANG_IS_CC. I will post a patch to toolchain@ to address this shortly. * Ports compiler selection infrastructure is still under development. * Some ports could build with clang with appropriate tweaks. What can you do to help? * Switch (some of) your systems. Early adoption can help us find bugs. * Fix ports to build with clang. If you don't have a clang system, you can use the CLANG/amd64 or CLANG/i386 build environments on redports.org. tl;dr: Clang will become the default compiler for x86 architectures on 2012-11-04 There was a chorus of voices talking about ports already. My POV is that suggesting to 'fix remaining ports to work with clang' is just a nonsense. You are proposing to fork the development of all the programs which do not compile with clang. Often, upstream developers do not care about clang at all since it not being default compiler in Debian/Fedora/Whatever Linux. The project simply do not have resources to maintain the fork of 20K programs. Looking from less amiable angle, you propose to knowingly break significant and important piece of the project work. My belief is that switch cannot be done before ports switch to the port-provided compiler. Another issue with the switch, which seems to be not only not addressed, but even not talked about, is the performance impact of the change. I do not remember any measurements, whatever silly they could be, of the performance change by the compiler switch. We often have serious and argumented push-back for kernel changes that give as low as 2-3% of the speed hit. What are the numbers for clang change, any numbers ? And, some small but annoying things left with clang, like ABI change requiring 16-byte stack alignment on i386, but lets ignore this until two big issues are resolved. pgpNKrF89TmKL.pgp Description: PGP signature
Re: Clang as default compiler November 4th
tl;dr: Clang will become the default compiler for x86 architectures on 2012-11-04 There was a chorus of voices talking about ports already. My POV is that suggesting to 'fix remaining ports to work with clang' is just a nonsense. You are proposing to fork the development of all the programs which do not compile with clang. Often, upstream developers do not care about clang at all since it not being default compiler in Debian/Fedora/Whatever Linux. The project simply do not have resources to maintain the fork of 20K programs. We currently dont compile 4680 ports (out of 23857). Top 10 ports that prevent the most other ports from compiling together prevent ports from compilation. So if we fixed those 10 ports we could be at around 2500 ports not compiling. Thats quite far from your claim of forking 20k programs. Looking from less amiable angle, you propose to knowingly break significant and important piece of the project work. My belief is that switch cannot be done before ports switch to the port-provided compiler. I believe majority of the broken ports is broken because their maintainer never saw them being broken with clang just because it's not the default compiler. Thus by making it the default majority of the problems would just go away. Note that the work needed to make ports compiling with clang is largely shared with the work to make them compiliable with newer GCCs (as they are stricter etc.) Another issue with the switch, which seems to be not only not addressed, but even not talked about, is the performance impact of the change. I do not remember any measurements, whatever silly they could be, of the performance change by the compiler switch. We often have serious and argumented push-back for kernel changes that give as low as 2-3% of the speed hit. What are the numbers for clang change, any numbers ? Agreed. We should provide numbers. At least how buildworld times change with clang compiled kernel/workd and gcc compiler kernel/world. And, some small but annoying things left with clang, like ABI change requiring 16-byte stack alignment on i386, but lets ignore this until two big issues are resolved. Thank you for pointing this out. This is, in my opinion, one of the strongest reasons to switch to clang. We can go, fix issues or report we find upstream and then import newer clang. Unlike with gcc. Thank you, Roman ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On Tue, Sep 11, 2012 at 03:21:22PM +0300, Konstantin Belousov wrote: On Tue, Sep 11, 2012 at 02:06:49PM +0200, Roman Divacky wrote: tl;dr: Clang will become the default compiler for x86 architectures on 2012-11-04 There was a chorus of voices talking about ports already. My POV is that suggesting to 'fix remaining ports to work with clang' is just a nonsense. You are proposing to fork the development of all the programs which do not compile with clang. Often, upstream developers do not care about clang at all since it not being default compiler in Debian/Fedora/Whatever Linux. The project simply do not have resources to maintain the fork of 20K programs. We currently dont compile 4680 ports (out of 23857). Top 10 ports that prevent the most other ports from compiling together prevent ports from compilation. So if we fixed those 10 ports we could be at around 2500 ports not compiling. Thats quite far from your claim of forking 20k programs. Sorry, I cannot buy the argument. How many patches there are already in the ports tree to cope with clang incompatibility with gcc ? You may declare that all of them are application bugs, but it completely misses the point. Looking from less amiable angle, you propose to knowingly break significant and important piece of the project work. My belief is that switch cannot be done before ports switch to the port-provided compiler. I believe majority of the broken ports is broken because their maintainer never saw them being broken with clang just because it's not the default compiler. Thus by making it the default majority of the problems would just go away. Can you, please, read what I wrote ? Fixing _ports_ to compile with clang is plain wrong. Upstream developers use gcc almost always for development and testing. Establishing another constant cost on the porting work puts burden on the ports submitters, maintainers and even ports users. Upstream developers almost never use gcc4.2.1 as we do. So right now the ports maintainer must check whats wrong in the case the (upgraded) port doesnt compile with our in-tree gcc. It can be trivial USE_GCC=4.something but the burden is exactly the same as with clang. I do strongly oppose the attempt to drain the freebsd resources by forcing porters to port third-party code to other compiler. We dont force anyone. Any port maintainer can decide to USE_GCC=4.2. We are not advocating removing gcc but making clang default. The possibility of fallback to gcc is still there. And, some small but annoying things left with clang, like ABI change requiring 16-byte stack alignment on i386, but lets ignore this until two big issues are resolved. Thank you for pointing this out. This is, in my opinion, one of the strongest reasons to switch to clang. We can go, fix issues or report we find upstream and then import newer clang. Unlike with gcc. We do not want to hunt for the compiler bugs at all, goal of FreeBSD is to develop the OS and not a compiler. By the nature of developing the OS we are forced to use compilers and toolchains. Recently I saw you submitting/committing patches with .byte sequences because our default assembler cant handle the instructions. I saw jhb@ updating binutils to support invept/invvpid. In my eyes, switching to clang by default lowers the compiler/toolchain maintenance burden we have. Thank you, Roman. ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
Roman, Den 11/09/2012 kl. 14.38 skrev Roman Divacky rdiva...@freebsd.org: Upstream developers almost never use gcc4.2.1 as we do. So right now the ports maintainer must check whats wrong in the case the (upgraded) port doesnt compile with our in-tree gcc. It can be trivial USE_GCC=4.something but the burden is exactly the same as with clang. So can we do a sweep on the ports tree and mark the 2232 ports with USE_GCC=4.2 until they can actually build with clang? This could allow the clang switch to proceed. Hopefully, waiting for GCC to compile just to install some tiny port will be enough of a nuisance for people to eventually fix the remaining ports. By the nature of developing the OS we are forced to use compilers and toolchains. Recently I saw you submitting/committing patches with .byte sequences because our default assembler cant handle the instructions. I saw jhb@ updating binutils to support invept/invvpid. In my eyes, switching to clang by default lowers the compiler/toolchain maintenance burden we have. I agree. Switching away from abandonware to a compiler that is actively maintained is a good thing. Regarding performance, I could do some benchmarking in my spare time, but it does seem like an unforgiving task. Anyone posting any benchmark numbers on these lists is going to be tarred, feathered, forced to print out the full GCC 4.2.1 source code, read it out loud on the town square, and spend the next month addressing concerns from people not willing to do the work themselves :-) Erik___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On Tue, Sep 11, 2012 at 01:45:18PM +0300, Konstantin Belousov wrote: On Mon, Sep 10, 2012 at 04:12:07PM -0500, Brooks Davis wrote: For the past several years we've been working towards migrating from GCC to Clang/LLVM as our default compiler. We intend to ship FreeBSD 10.0 with Clang as the default compiler on i386 and amd64 platforms. To this end, we will make WITH_CLANG_IS_CC the default on i386 and amd64 platforms on November 4th. What does the mean to you? * When you build world after the default is changed /usr/bin/cc, cpp, and c++ will be links to clang. * This means the initial phase of buildworld and old style kernel compilation will use clang instead of gcc. This is known to work. * It also means that ports will build with clang by default. A major of ports work, but a significant number are broken or blocked by broken ports. For more information see: http://wiki.freebsd.org/PortsAndClang What issues remain? * The gcc-clang transition currently requires setting CC, CXX, and CPP in addition to WITH_CLANG_IS_CC. I will post a patch to toolchain@ to address this shortly. * Ports compiler selection infrastructure is still under development. * Some ports could build with clang with appropriate tweaks. What can you do to help? * Switch (some of) your systems. Early adoption can help us find bugs. * Fix ports to build with clang. If you don't have a clang system, you can use the CLANG/amd64 or CLANG/i386 build environments on redports.org. tl;dr: Clang will become the default compiler for x86 architectures on 2012-11-04 There was a chorus of voices talking about ports already. My POV is that suggesting to 'fix remaining ports to work with clang' is just a nonsense. You are proposing to fork the development of all the programs which do not compile with clang. Often, upstream developers do not care about clang at all since it not being default compiler in Debian/Fedora/Whatever Linux. The project simply do not have resources to maintain the fork of 20K programs. I may have phrased the above poorly, but in most cases I'd be happy with using USE_GCC as a solution, but to the extent that port maintainers can fix their ports to build with clang, that's a good thing. Having a deadline will help focus efforts towards finding the right fix for the most important ports in a timely manner. If we near the deadline and find that we need a few more weeks, nothing prevents us from slipping the date a bit. Another issue with the switch, which seems to be not only not addressed, but even not talked about, is the performance impact of the change. I do not remember any measurements, whatever silly they could be, of the performance change by the compiler switch. We often have serious and argumented push-back for kernel changes that give as low as 2-3% of the speed hit. What are the numbers for clang change, any numbers ? Florian Smeets (flo) did one round of benchmarks back in June with sysbench/mysql. There is a small but measurable slowdown both with world compiled with clang and with mysql compiled with clang. You can see the results on the last page of this document: http://people.freebsd.org/~flo/perf.pdf The total impacts are on the order of 1-2%. That's more than I'd like and I expect some pushback, but I feel it is in the range of acceptable code debt to take on to accomplish a multi-year project goal. -- Brooks pgpX5cC5yNg9i.pgp Description: PGP signature
Re: Clang as default compiler November 4th
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 software out there. If certain software performs significantly better with gcc, and using newer versions of the GPL is no problem, then it is obviously the better choice. However, I think the majority of users can get by just fine using clang, right now. Doug Barton even confirmed in this thread that 80% of our ports already work with it! What is important is whether software built with clang functions correctly. See for example, http://math-atlas.sourceforge.net/errata.html#WhatComp Yes, maths support, specifically precision, is admittedly still one of clang's (really llvm's) weaker points. It is currently not really a high priority item for upstream. This is obviously something that a certain part of our userbase will care a lot about, while most of the time they won't care so much about licensing or politics. So those people are probably better off using gcc for the time being. Has anyone run Spec CPU2006 on i386 and amd64 FreeBSD? I am not aware of it, but is that test available publicly? I might take a shot, if I can get my hands on it. ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/11/12 09:44, Christer Solskogen wrote: On Tue, Sep 11, 2012 at 3:32 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: Interest twist of history. GCC is not abandonware. Correct, but GCC 4.2.1 is. While this may be true, I'm not inclined to move any of my gear to a platform which is built on a tool-chain which is described in terms such as .. In particular, clang/LLVM presently fails to produce correct code for some operations, and is not performance competitive with gcc for any. - From the link (http://math-atlas.sourceforge.net/errata.html#WhatComp) that Steve Kargl referenced (dated July 2012). While I appreciate the desire and need to move away from a legally encumbering environment, stability and maturity are both critical considerations. This is not to say that GCC 4.2.1 is either bug-free or sufficiently featureful as more modern versions but its idiosyncrasies are better known and understood, imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlBPRlAACgkQQv9rrgRC1JLRUACeOGb8PryPla1yyhLeWzuVT4jM +JEAoIbn1IEed5oXR5+e9SCIfmfQ4V5R =ahHY -END PGP SIGNATURE- ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
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#WhatComp Yes, maths support, specifically precision, is admittedly still one of clang's (really llvm's) weaker points. It is currently not really a high priority item for upstream. This is obviously something that a certain part of our userbase will care a lot about, while most of the time they won't care so much about licensing or politics. So those people are probably better off using gcc for the time being. Does it affect the accuracy of libm functions? signature.asc Description: OpenPGP digital signature
Re: Clang as default compiler November 4th
On 11 Sep 2012 13:22, Konstantin Belousov kostik...@gmail.com wrote: On Tue, Sep 11, 2012 at 02:06:49PM +0200, Roman Divacky wrote: tl;dr: Clang will become the default compiler for x86 architectures on 2012-11-04 There was a chorus of voices talking about ports already. My POV is that suggesting to 'fix remaining ports to work with clang' is just a nonsense. You are proposing to fork the development of all the programs which do not compile with clang. Often, upstream developers do not care about clang at all since it not being default compiler in Debian/Fedora/Whatever Linux. The project simply do not have resources to maintain the fork of 20K programs. We currently dont compile 4680 ports (out of 23857). Top 10 ports that prevent the most other ports from compiling together prevent ports from compilation. So if we fixed those 10 ports we could be at around 2500 ports not compiling. Thats quite far from your claim of forking 20k programs. Sorry, I cannot buy the argument. How many patches there are already in the ports tree to cope with clang incompatibility with gcc ? You may declare that all of them are application bugs, but it completely misses the point. Looking from less amiable angle, you propose to knowingly break significant and important piece of the project work. My belief is that switch cannot be done before ports switch to the port-provided compiler. I believe majority of the broken ports is broken because their maintainer never saw them being broken with clang just because it's not the default compiler. Thus by making it the default majority of the problems would just go away. Can you, please, read what I wrote ? Fixing _ports_ to compile with clang is plain wrong. Upstream developers use gcc almost always for development and testing. Establishing another constant cost on the porting work puts burden on the ports submitters, maintainers and even ports users. I do strongly oppose the attempt to drain the freebsd resources by forcing porters to port third-party code to other compiler. I definitely see your point, but upstream should also be writing correct/portable code. Whenever a patch to fix a port is made, it is actually mandatory to report it to upstream, and nag them to hell until it's committed! Most are very happy for this to happen; we've been removing GNUisms from build scripts etc for years now (and I could link to a Thank you email for all the build fixes I've sent upstream). Sometimes, like the common bashism if [ a == b ] we bite the bullet and add the extensions ourselves; sometimes upstream has an education on writing portable code! If we were all the same, would there be much point in being different? Chris ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On 2012-09-11 16:27, Tijl Coosemans wrote: On 11-09-2012 16:10, Dimitry Andric wrote: ... Yes, maths support, specifically precision, is admittedly still one of clang's (really llvm's) weaker points. It is currently not really a high priority item for upstream. This is obviously something that a certain part of our userbase will care a lot about, while most of the time they won't care so much about licensing or politics. So those people are probably better off using gcc for the time being. Does it affect the accuracy of libm functions? It seems to, at least in specific cases; Steve posted about this in an earlier thread on -current: http://docs.freebsd.org/cgi/mid.cgi?20120905221310.GA97847 ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On Tue, Sep 11, 2012 at 7:21 AM, Konstantin Belousov kostik...@gmail.com wrote: snip Can you, please, read what I wrote ? Fixing _ports_ to compile with clang is plain wrong. Upstream developers use gcc almost always for development and testing. Establishing another constant cost on the porting work puts burden on the ports submitters, maintainers and even ports users. I do strongly oppose the attempt to drain the freebsd resources by forcing porters to port third-party code to other compiler. I agree with this pretty much. I haven't done fix any of port build with clang as I simply ignore clang (sorry). When user report to me and I tell them to stick with GCC as I don't support it. Cheers, Mezz -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@freebsd.org ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
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 software out there. If /usr/bin/cc becomes clang, then the proposal is about more than the FreeBSD system. This affects any port that uses cc. If certain software performs significantly better with gcc, and using newer versions of the GPL is no problem, then it is obviously the better choice. However, I think the majority of users can get by just fine using clang, right now. Doug Barton even confirmed in this thread that 80% of our ports already work with it! He stated that 80% build with clang. I doubt that he actually tested the functionality of some 17000 ports. What is important is whether software built with clang functions correctly. See for example, http://math-atlas.sourceforge.net/errata.html#WhatComp Yes, maths support, specifically precision, is admittedly still one of clang's (really llvm's) weaker points. It is currently not really a high priority item for upstream. This is obviously something that a certain part of our userbase will care a lot about, while most of the time they won't care so much about licensing or politics. So those people are probably better off using gcc for the time being. Which gets back to Doug's original point. Until the ports system has worked out its infrastructure for choosing a compiler, a switch to clang as the default compiler would seem to be premature. Has anyone run Spec CPU2006 on i386 and amd64 FreeBSD? I am not aware of it, but is that test available publicly? I might take a shot, if I can get my hands on it. Unfortunately, it has a cost associated with it. http://www.spec.org/order.html. Perhaps, the FreeBSD Foundation can make it available. -- Steve ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
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#WhatComp Yes, maths support, specifically precision, is admittedly still one of clang's (really llvm's) weaker points. It is currently not really a high priority item for upstream. This is obviously something that a certain part of our userbase will care a lot about, while most of the time they won't care so much about licensing or politics. So those people are probably better off using gcc for the time being. Does it affect the accuracy of libm functions? I'm not sure if anyone has done any extensive testing. I've started to run some of my test codes to compare certain functions in a clang-compiled libm, gcc-compiled libm, and reference solutions generated from math/mpfr. For a locally patched j0f, I found that clang gave much worse accuracy. If I revert the local patch, clang and gcc are to give the same results. Unfortnately, an unpatched j0f gives 50 ULP errors. -- Steve ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On Tue, 11 Sep 2012, Konstantin Belousov wrote: On Tue, Sep 11, 2012 at 02:06:49PM +0200, Roman Divacky wrote: We currently dont compile 4680 ports (out of 23857). Top 10 ports that prevent the most other ports from compiling together prevent ports from compilation. So if we fixed those 10 ports we could be at around 2500 ports not compiling. Thats quite far from your claim of forking 20k programs. Sorry, I cannot buy the argument. How many patches there are already in the ports tree to cope with clang incompatibility with gcc ? You may declare that all of them are application bugs, but it completely misses the point. [ snip ] I believe majority of the broken ports is broken because their maintainer never saw them being broken with clang just because it's not the default compiler. Thus by making it the default majority of the problems would just go away. Can you, please, read what I wrote ? Fixing _ports_ to compile with clang is plain wrong. Upstream developers use gcc almost always for development and testing. Establishing another constant cost on the porting work puts burden on the ports submitters, maintainers and even ports users. This is a good point! -- DE ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On Tue, Sep 11, 2012 at 08:12:30AM -0700, Steve Kargl wrote: 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#WhatComp Yes, maths support, specifically precision, is admittedly still one of clang's (really llvm's) weaker points. It is currently not really a high priority item for upstream. This is obviously something that a certain part of our userbase will care a lot about, while most of the time they won't care so much about licensing or politics. So those people are probably better off using gcc for the time being. Does it affect the accuracy of libm functions? I'm not sure if anyone has done any extensive testing. I've started to run some of my test codes to compare certain functions in a clang-compiled libm, gcc-compiled libm, and reference solutions generated from math/mpfr. For a locally patched j0f, I found that clang gave much worse accuracy. If I revert the local patch, clang and gcc are to give the same results. Unfortnately, an unpatched j0f gives 50 ULP errors. Steve, Can you please provide a small self contained test case that shows that clang is doing worse on accuracy than gcc? So that we can analyze it and decide if it's a bug in the code or in the compiler. So far we know absolutely nothing. Thank you, Roman ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
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 application it would be stupid to use clang if this is the case. I see no problem with it being the default compiler though. If Atlas is in ports ther maintainer can just force it to use the latest GCC. Last time I checked the code in src/lib/msun was built by the default compiler into a library named libm. If clang can't produce valid floating point code, are you suggesting that the base should have two compilers one (ie gcc) for libm and any other application that may use floating point and one (ie clang) for everything else? I'm not sure why Clang being default is somehow a problem for you? For one, I'm the guy that has been fixing and implementing missing functions in libm. I've already shown that clang generates worse code than base gcc for a single function in libm. http://lists.freebsd.org/pipermail/freebsd-current/2012-September/036410.html Granted j0f() in my libm had a local patch, but that local patch actual improves j0f() accuracy over the range tested! It can take hours (for a quick test) or days (for more exhaustive testing) to test a simple patch, because I do testing on i385, amd64, and sparc64 machines. So, now, I have to do the testing with 2 compilers. You'll find that I'm the person that showed that clang can't do complex arithmetic correctly. http://llvm.org/bugs/show_bug.cgi?id=8532 That bug was reported almost 2 years ago. Finally, I'll note that I never stated that having clang as the default would be a problem for me. I know enough about compilers and floating pointing to test a new compiler. It the naive users (and I can assure you there are many more naive users than you may believe) that is of concern. -- Steve ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Clang as default compiler November 4th
[Please confine your replies to toolch...@freebsd.org to keep the thread on the most relevant list.] For the past several years we've been working towards migrating from GCC to Clang/LLVM as our default compiler. We intend to ship FreeBSD 10.0 with Clang as the default compiler on i386 and amd64 platforms. To this end, we will make WITH_CLANG_IS_CC the default on i386 and amd64 platforms on November 4th. What does the mean to you? * When you build world after the default is changed /usr/bin/cc, cpp, and c++ will be links to clang. * This means the initial phase of buildworld and old style kernel compilation will use clang instead of gcc. This is known to work. * It also means that ports will build with clang by default. A major of ports work, but a significant number are broken or blocked by broken ports. For more information see: http://wiki.freebsd.org/PortsAndClang What issues remain? * The gcc-clang transition currently requires setting CC, CXX, and CPP in addition to WITH_CLANG_IS_CC. I will post a patch to toolchain@ to address this shortly. * Ports compiler selection infrastructure is still under development. * Some ports could build with clang with appropriate tweaks. What can you do to help? * Switch (some of) your systems. Early adoption can help us find bugs. * Fix ports to build with clang. If you don't have a clang system, you can use the CLANG/amd64 or CLANG/i386 build environments on redports.org. tl;dr: Clang will become the default compiler for x86 architectures on 2012-11-04 -- Brooks pgp7CmiVQcCNl.pgp Description: PGP signature
Re: Clang as default compiler November 4th
On Mon, 10 Sep 2012, Brooks Davis wrote: [Please confine your replies to toolch...@freebsd.org to keep the thread on the most relevant list.] For the past several years we've been working towards migrating from GCC to Clang/LLVM as our default compiler. We intend to ship FreeBSD 10.0 with Clang as the default compiler on i386 and amd64 platforms. To this end, we will make WITH_CLANG_IS_CC the default on i386 and amd64 platforms on November 4th. What does the mean to you? * When you build world after the default is changed /usr/bin/cc, cpp, and c++ will be links to clang. * This means the initial phase of buildworld and old style kernel compilation will use clang instead of gcc. This is known to work. * It also means that ports will build with clang by default. A major of ports work, but a significant number are broken or blocked by broken ports. For more information see: http://wiki.freebsd.org/PortsAndClang What issues remain? * The gcc-clang transition currently requires setting CC, CXX, and CPP in addition to WITH_CLANG_IS_CC. I will post a patch to toolchain@ to address this shortly. I assume this will be done, tested and committed before 2012-11-04 (or whenever the switchover date is). * Ports compiler selection infrastructure is still under development. This should be a prerequisite before making the switch, given that ports will be broken without a work-around for building them with gcc. -- DE ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On Mon, Sep 10, 2012 at 5:01 PM, Brooks Davis bro...@freebsd.org wrote: On Mon, Sep 10, 2012 at 05:22:37PM -0400, Daniel Eischen wrote: On Mon, 10 Sep 2012, Brooks Davis wrote: [Please confine your replies to toolch...@freebsd.org to keep the thread on the most relevant list.] For the past several years we've been working towards migrating from GCC to Clang/LLVM as our default compiler. We intend to ship FreeBSD 10.0 with Clang as the default compiler on i386 and amd64 platforms. To this end, we will make WITH_CLANG_IS_CC the default on i386 and amd64 platforms on November 4th. What does the mean to you? * When you build world after the default is changed /usr/bin/cc, cpp, and c++ will be links to clang. * This means the initial phase of buildworld and old style kernel compilation will use clang instead of gcc. This is known to work. * It also means that ports will build with clang by default. A major of ports work, but a significant number are broken or blocked by broken ports. For more information see: http://wiki.freebsd.org/PortsAndClang What issues remain? * The gcc-clang transition currently requires setting CC, CXX, and CPP in addition to WITH_CLANG_IS_CC. I will post a patch to toolchain@ to address this shortly. I assume this will be done, tested and committed before 2012-11-04 (or whenever the switchover date is). Pending review it will be done this week. * Ports compiler selection infrastructure is still under development. This should be a prerequisite before making the switch, given that ports will be broken without a work-around for building them with gcc. We've defacto done that for more than a year. Some progress has resulted, but not enough. I will be helping fix ports and I hope others do as well. It's worth noting that a switchable compiler isn't a magic bullet. Many ports will need to be patched to support a compiler other than /usr/bin/cc or /usr/bin/gcc. -- Brooks This is actually a pretty good thing. Because -before- it's the default compiler, some ports maintainers (and even more upstreams) have the attitude of My port works fine until it no longer does.. bringing this change will make a few of these people realize that we are -serious- about switching to clang. For those worrying about zomg, my system wont work?! Remember.. This is a -current thing. If you're running bleeding edge, you have to expect to get cut every now and then. -- Chuck Burns brea...@gmail.com ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On 09/10/12 14:22, Daniel Eischen wrote: On Mon, 10 Sep 2012, Brooks Davis wrote: [Please confine your replies to toolch...@freebsd.org to keep the thread on the most relevant list.] For the past several years we've been working towards migrating from GCC to Clang/LLVM as our default compiler. We intend to ship FreeBSD 10.0 with Clang as the default compiler on i386 and amd64 platforms. To this end, we will make WITH_CLANG_IS_CC the default on i386 and amd64 platforms on November 4th. What does the mean to you? * When you build world after the default is changed /usr/bin/cc, cpp, and c++ will be links to clang. * This means the initial phase of buildworld and old style kernel compilation will use clang instead of gcc. This is known to work. * It also means that ports will build with clang by default. A major of ports work, but a significant number are broken or blocked by broken ports. For more information see: http://wiki.freebsd.org/PortsAndClang What issues remain? * The gcc-clang transition currently requires setting CC, CXX, and CPP in addition to WITH_CLANG_IS_CC. I will post a patch to toolchain@ to address this shortly. I assume this will be done, tested and committed before 2012-11-04 (or whenever the switchover date is). * Ports compiler selection infrastructure is still under development. This should be a prerequisite before making the switch, given that ports will be broken without a work-around for building them with gcc. I've been using a somewhat dirty method of doing this by checking the presence of a file in the port's main directory, e.g. if basegcc is present, build with that, if clang is present use it, otherwise default to gcc47. Obviously that configuration is system specific, but the fundamental idea is look for a file in the ports directory that dictates the compiler. Perhaps even add a make ccconfig. It works quite nicely because you can resume a portmaster spree without having to suspend and change CC manually, or build all clang ports first etc. Further csup doesn't touch files it doesn't no about, so updating the tree (without wiping it out) preserves the fact you'd prefer or need to build a given port with something else. There are definitely some ports that have been ignoring libmap.conf, which tends to require me to build some of their dependencies with base gcc, but otherwise I've been running this system for a few months and it works quite well...portmaster can upgrade without user intervention, and it's quite easy to add cflags logic. Granted this works for me and is probably not the ideal solution...also hacked on it to post, so probably typos :) Something like this in make.conf (with fstack-protector-all for all ports which works great) .if !empty(.CURDIR:M/usr/ports/*) CFLAGS+= -fstack-protector-all .endif .if empty(.CURDIR:M/usr/ports/*) exists(/usr/local/bin/gcc47) !exists(basegcc) !exists(clang) # this was occasionally necessary #LDFLAGS+=-lintl # custom cflags if desired #CFLAGS+=-custom cflags for gcc47 #custom cputype if desired CPUTYPE=amdfam10 CC=gcc47 CPP=cpp47 CXX=g++47 .endif .if empty(.CURDIR:M/usr/ports/*) exists(/usr/bin/clang) exists(clang) .if !defined(CC) || ${CC} == cc CC=clang .endif .if !defined(CXX) || ${CXX} == c++ CXX=clang++ .endif .if !defined(CPP) || ${CPP} == cpp CPP=clang-cpp .endif NO_WERROR= WERROR= .endif Usage is as simple as touch basegcc in the port dir or touch clang etc. to select appropriate compiler Matt ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org