Re: Clang as default compiler November 4th
On 15-09-2012 17:39, Mehmet Erol Sanliturk wrote:
On Sat, Sep 15, 2012 at 7:30 AM, Tijl Coosemans t...@coosemans.org wrote:
On 15-09-2012 16:09, Roman Divacky wrote:
Is this correct?
lev ~$ ./cos 1.23456789e20
6.031937e-01
-9.629173e-02
2.814722e-01
Yes, that's what the libm call returns.
Linux z 3.5.3-1.fc17.x86_64 #1 SMP Wed Aug 29 18:46:34 UTC 2012 x86_64
x86_64 x86_64 GNU/Linux
clang version 3.0 (tags/RELEASE_30/final)
Target: x86_64-redhat-linux-gnu
Thread model: posix
Output of the initial program is the following :
#include math.h
#include stdio.h
#include stdlib.h
int
main( int argc, char **argv ) {
double d = strtod( argv[ 1 ], NULL );
printf( cos : %e\n, ( double ) cos( d ));
printf( cosf : %e\n, ( double ) cosf( d ));
printf( cosl : %e\n, ( double ) cosl( d ));
return( 0 );
}
cos : 2.814722e-01
cosf : -9.629173e-02
cosl : 7.738403e-01
This is probably because SSE instructions are used on amd64.
Output of the following program is different :
The reason is that...
#include math.h
#include stdio.h
#include stdlib.h
int
main( int argc, char **argv ) {
double d ;
double two_pi ;
double f ;
double v ;
two_pi = 2 * 3.14159265358979323846 ;
d = strtod( argv[ 1 ], NULL );
f = floor ( d / two_pi ) ;
v = d - f * two_pi ;
...this is a poor way to compute a remainder. Try to use fmod() or
remainder() instead.
printf( given : %e\n, ( double ) d );
printf( multiplier : %e\n, ( double ) f );
printf( reduced : %e\n, ( double ) v );
printf( cos ( %e ) : %e\n, d , ( double ) cos( d ));
printf( cosf ( %e ) : %e\n, d , ( double ) cosf( d ));
printf( cosl ( %e ) : %e\n, d , ( double ) cosl( d ));
printf( cos ( %e ) : %e\n, v , ( double ) cos( v ));
printf( cosf ( %e ) : %e\n, v , ( double ) cosf( v ));
printf( cosl ( %e ) : %e\n, v , ( double ) cosl( v ));
return( 0 );
}
given : 1.234568e+20
multiplier : 1.964876e+19
reduced : 1.638400e+04
cos ( 1.234568e+20 ) : 2.814722e-01
cosf ( 1.234568e+20 ) : -9.629173e-02
cosl ( 1.234568e+20 ) : 7.738403e-01
cos ( 1.638400e+04 ) : -8.285342e-01
cosf ( 1.638400e+04 ) : -8.285342e-01
cosl ( 1.638400e+04 ) : -8.285342e-01
signature.asc
Description: OpenPGP digital signature
Re: Clang as default compiler November 4th
On Tue, Sep 18, 2012 at 7:23 AM, Tijl Coosemans t...@coosemans.org wrote:
On 15-09-2012 17:39, Mehmet Erol Sanliturk wrote:
On Sat, Sep 15, 2012 at 7:30 AM, Tijl Coosemans t...@coosemans.org
wrote:
On 15-09-2012 16:09, Roman Divacky wrote:
Is this correct?
lev ~$ ./cos 1.23456789e20
6.031937e-01
-9.629173e-02
2.814722e-01
Yes, that's what the libm call returns.
Linux z 3.5.3-1.fc17.x86_64 #1 SMP Wed Aug 29 18:46:34 UTC 2012 x86_64
x86_64 x86_64 GNU/Linux
clang version 3.0 (tags/RELEASE_30/final)
Target: x86_64-redhat-linux-gnu
Thread model: posix
Output of the initial program is the following :
#include math.h
#include stdio.h
#include stdlib.h
int
main( int argc, char **argv ) {
double d = strtod( argv[ 1 ], NULL );
printf( cos : %e\n, ( double ) cos( d ));
printf( cosf : %e\n, ( double ) cosf( d ));
printf( cosl : %e\n, ( double ) cosl( d ));
return( 0 );
}
cos : 2.814722e-01
cosf : -9.629173e-02
cosl : 7.738403e-01
This is probably because SSE instructions are used on amd64.
Output of the following program is different :
The reason is that...
#include math.h
#include stdio.h
#include stdlib.h
int
main( int argc, char **argv ) {
double d ;
double two_pi ;
double f ;
double v ;
two_pi = 2 * 3.14159265358979323846 ;
d = strtod( argv[ 1 ], NULL );
f = floor ( d / two_pi ) ;
v = d - f * two_pi ;
...this is a poor way to compute a remainder. Try to use fmod() or
remainder() instead.
My C knowledge is NOT very well . Thanks .
printf( given : %e\n, ( double ) d );
printf( multiplier : %e\n, ( double ) f );
printf( reduced : %e\n, ( double ) v );
printf( cos ( %e ) : %e\n, d , ( double ) cos( d ));
printf( cosf ( %e ) : %e\n, d , ( double ) cosf( d ));
printf( cosl ( %e ) : %e\n, d , ( double ) cosl( d ));
printf( cos ( %e ) : %e\n, v , ( double ) cos( v ));
printf( cosf ( %e ) : %e\n, v , ( double ) cosf( v ));
printf( cosl ( %e ) : %e\n, v , ( double ) cosl( v ));
return( 0 );
}
given : 1.234568e+20
multiplier : 1.964876e+19
reduced : 1.638400e+04
cos ( 1.234568e+20 ) : 2.814722e-01
cosf ( 1.234568e+20 ) : -9.629173e-02
cosl ( 1.234568e+20 ) : 7.738403e-01
cos ( 1.638400e+04 ) : -8.285342e-01
cosf ( 1.638400e+04 ) : -8.285342e-01
cosl ( 1.638400e+04 ) : -8.285342e-01
My intention was to check whether there is a difference between Clang
compiled programs in different operating systems .
The GCC output is as follows :
Linux z 3.5.3-1.fc17.x86_64 #1 SMP Wed Aug 29 18:46:34 UTC 2012 x86_64
x86_64 x86_64 GNU/Linux
cc (GCC) 4.7.0 20120507 (Red Hat 4.7.0-5)
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
given : 1.234568e+20
cos ( 1.234568e+20 ) : 2.814722e-01
cosf ( 1.234568e+20 ) : -9.629173e-02
cosl ( 1.234568e+20 ) : 7.738403e-01
multiplier : 1.964876e+19
reduced : 1.638400e+04
cos ( 1.638400e+04 ) : -8.285342e-01
cosf ( 1.638400e+04 ) : -8.285342e-01
cosl ( 1.638400e+04 ) : -8.285342e-01
multiplier : 2.607000e+03
reduced : 3.735904e+00
cos ( 3.735904e+00 ) : -8.285342e-01
cosf ( 3.735904e+00 ) : -8.285342e-01
cosl ( 3.735904e+00 ) : -8.285342e-01
This shows that GCC is NOT better than Clang .
Thank you very much .
Mehmet Erol Sanliturk
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
Fwiw, I commited the dont use long nops on amd geode thing into llvm a few minutes ago. So this issue doesnt exist anymore. On Wed, Sep 12, 2012 at 07:19:07PM +0400, Lev Serebryakov wrote: Hello, Patrick. You wrote 12 2012 ?., 1:22:44: PL Well, I will not be able to run FreeBSD from scratch on my soekris :-) Thank you for warning, I've missed this. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-toolch...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On 15-09-2012 16:09, Roman Divacky wrote: Is this correct? lev ~$ ./cos 1.23456789e20 6.031937e-01 -9.629173e-02 2.814722e-01 Yes, that's what the libm call returns. signature.asc Description: OpenPGP digital signature
Re: Clang as default compiler November 4th
On Sat, Sep 15, 2012 at 7:30 AM, Tijl Coosemans t...@coosemans.org wrote: On 15-09-2012 16:09, Roman Divacky wrote: Is this correct? lev ~$ ./cos 1.23456789e20 6.031937e-01 -9.629173e-02 2.814722e-01 Yes, that's what the libm call returns. The following is a result in Fedora 17 x86_64 : Linux z 3.5.3-1.fc17.x86_64 #1 SMP Wed Aug 29 18:46:34 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux clang version 3.0 (tags/RELEASE_30/final) Target: x86_64-redhat-linux-gnu Thread model: posix cos : 2.814722e-01 cosf : -9.629173e-02 cosl : 7.738403e-01 Thank you very much . Mehmet Erol Sanliurk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On Sat, Sep 15, 2012 at 7:30 AM, Tijl Coosemans t...@coosemans.org wrote:
On 15-09-2012 16:09, Roman Divacky wrote:
Is this correct?
lev ~$ ./cos 1.23456789e20
6.031937e-01
-9.629173e-02
2.814722e-01
Yes, that's what the libm call returns.
Linux z 3.5.3-1.fc17.x86_64 #1 SMP Wed Aug 29 18:46:34 UTC 2012 x86_64
x86_64 x86_64 GNU/Linux
clang version 3.0 (tags/RELEASE_30/final)
Target: x86_64-redhat-linux-gnu
Thread model: posix
Output of the initial program is the following :
#include math.h
#include stdio.h
#include stdlib.h
int
main( int argc, char **argv ) {
double d = strtod( argv[ 1 ], NULL );
printf( cos : %e\n, ( double ) cos( d ));
printf( cosf : %e\n, ( double ) cosf( d ));
printf( cosl : %e\n, ( double ) cosl( d ));
return( 0 );
}
cos : 2.814722e-01
cosf : -9.629173e-02
cosl : 7.738403e-01
...
Output of the following program is different :
#include math.h
#include stdio.h
#include stdlib.h
int
main( int argc, char **argv ) {
double d ;
double two_pi ;
double f ;
double v ;
two_pi = 2 * 3.14159265358979323846 ;
d = strtod( argv[ 1 ], NULL );
f = floor ( d / two_pi ) ;
v = d - f * two_pi ;
printf( given : %e\n, ( double ) d );
printf( multiplier : %e\n, ( double ) f );
printf( reduced : %e\n, ( double ) v );
printf( cos ( %e ) : %e\n, d , ( double ) cos( d ));
printf( cosf ( %e ) : %e\n, d , ( double ) cosf( d ));
printf( cosl ( %e ) : %e\n, d , ( double ) cosl( d ));
printf( cos ( %e ) : %e\n, v , ( double ) cos( v ));
printf( cosf ( %e ) : %e\n, v , ( double ) cosf( v ));
printf( cosl ( %e ) : %e\n, v , ( double ) cosl( v ));
return( 0 );
}
given : 1.234568e+20
multiplier : 1.964876e+19
reduced : 1.638400e+04
cos ( 1.234568e+20 ) : 2.814722e-01
cosf ( 1.234568e+20 ) : -9.629173e-02
cosl ( 1.234568e+20 ) : 7.738403e-01
cos ( 1.638400e+04 ) : -8.285342e-01
cosf ( 1.638400e+04 ) : -8.285342e-01
cosl ( 1.638400e+04 ) : -8.285342e-01
...
Reduction of argument once more did NOT change results :
#include math.h
#include stdio.h
#include stdlib.h
int
main( int argc, char **argv ) {
double d ;
double two_pi ;
double f ;
double v ;
double g ;
double w ;
two_pi = 2 * 3.14159265358979323846 ;
d = strtod( argv[ 1 ], NULL );
printf( given : %e\n, ( double ) d );
printf( cos ( %e ) : %e\n, d , ( double ) cos( d ));
printf( cosf ( %e ) : %e\n, d , ( double ) cosf( d ));
printf( cosl ( %e ) : %e\n, d , ( double ) cosl( d ));
f = floor ( d / two_pi ) ;
v = d - f * two_pi ;
printf( multiplier : %e\n, ( double ) f );
printf(reduced : %e\n, ( double ) v );
printf( cos ( %e ) : %e\n, v , ( double ) cos( v ));
printf( cosf ( %e ) : %e\n, v , ( double ) cosf( v ));
printf( cosl ( %e ) : %e\n, v , ( double ) cosl( v ));
g = floor ( v / two_pi ) ;
w = v - g * two_pi ;
printf( multiplier : %e\n, ( double ) g );
printf(reduced : %e\n, ( double ) w );
printf( cos ( %e ) : %e\n, w , ( double ) cos( w ));
printf( cosf ( %e ) : %e\n, w , ( double ) cosf( w ));
printf( cosl ( %e ) : %e\n, w , ( double ) cosl( w ));
return( 0 );
}
given : 1.234568e+20
cos ( 1.234568e+20 ) : 2.814722e-01
cosf ( 1.234568e+20 ) : -9.629173e-02
cosl ( 1.234568e+20 ) : 7.738403e-01
multiplier : 1.964876e+19
reduced : 1.638400e+04
cos ( 1.638400e+04 ) : -8.285342e-01
cosf ( 1.638400e+04 ) : -8.285342e-01
cosl ( 1.638400e+04 ) : -8.285342e-01
multiplier : 2.607000e+03
reduced : 3.735904e+00
cos ( 3.735904e+00 ) : -8.285342e-01
cosf ( 3.735904e+00 ) : -8.285342e-01
cosl ( 3.735904e+00 ) : -8.285342e-01
...
Thank you very much .
Mehmet Erol Sanliturk
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On Sep 15, 2012, at 3:14 AM, Roman Divacky wrote: 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. In the past, gcc has only done this with -ffast-math, but my 'in the past' is a long time ago... 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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-toolch...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On 2012-09-15 16:30, Tijl Coosemans wrote: On 15-09-2012 16:09, Roman Divacky wrote: Is this correct? lev ~$ ./cos 1.23456789e20 6.031937e-01 -9.629173e-02 2.814722e-01 Yes, that's what the libm call returns. Fix committed in http://svn.freebsd.org/changeset/base/240531. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On Sat, Sep 15, 2012 at 07:18:28PM +0200, Dimitry Andric wrote: On 2012-09-15 16:30, Tijl Coosemans wrote: On 15-09-2012 16:09, Roman Divacky wrote: Is this correct? lev ~$ ./cos 1.23456789e20 6.031937e-01 -9.629173e-02 2.814722e-01 Yes, that's what the libm call returns. Fix committed in http://svn.freebsd.org/changeset/base/240531. Thanks. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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 pgpc1m8WiM4ir.pgp Description: PGP signature
Re: Clang as default compiler November 4th
On Fri, 14 Sep 2012 15:23:19 -0500 Brooks Davis bro...@freebsd.org wrote: 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 Also, you probably want to be sure you are running these tests against clang 3.2, not the clang that is in base, since -that- is the version that will be going live, right? -- Chuck Burns brea...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
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. I can't imagine booting into a freshly installed production machine and having to install gcc just to build the couple of ports that I need there. Unless we provide a fast shortcut way to have make depends install gcc via pkg when needed, or some similar mechanism.. -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp pgpnuCIUIWf4L.pgp Description: PGP signature
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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On Thu, Sep 13, 2012 at 09:10:24AM -0700, Steve Kargl wrote: 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 [...] 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. Neither does gcc, AFAIK (http://gcc.gnu.org/c99status.html). It just silently ignores the pragma. Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On Thu, Sep 13, 2012 at 06:25:37PM +0200, Stefan Farfeleder wrote: On Thu, Sep 13, 2012 at 09:10:24AM -0700, Steve Kargl wrote: 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 [...] 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. Neither does gcc, AFAIK (http://gcc.gnu.org/c99status.html). It just silently ignores the pragma. Hmmm, indeed, you are correct. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 I seems to have mis-remembered a patch that went into newer gcc. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On 12 Sep 2012, at 10:15, Mark Linimon lini...@lonesome.com 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. I'd also guess that FreeBSD ports is probably the biggest exposure clang has ever seen to 3rd party code. I can't think of any other project except maybe macports who try to run clang over some much 3rd party code and so FreeBSD ports is hitting all the bumps in the road that most people get to ignore. - Mark ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
Fwiw, I plan to fix this issue, but even if I didnt. This isnt a problem in clang rather than in llvm asm. So it can be easily worked around by CFLAGS+=-no-integrated-as. Roman On Tue, Sep 11, 2012 at 11:22:44PM +0200, Patrick Lamaiziere wrote: Le Mon, 10 Sep 2012 16:12:07 -0500, Brooks Davis bro...@freebsd.org a ?crit : Hello, 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. Last time I've checked on 9.X [mid August, FreeBSD clang version 3.1 (branches/release_31 156863) 20120523], Clang still produces invalid code (some nopl (%eax)) for the AMD Geode LX (i586 CPU found on some ALIX board or Soekris NET5501). I don't know if this is also a concern with older CPU (Pentium 2/1) ? http://llvm.org/bugs/show_bug.cgi?id=11212 http://lists.freebsd.org/pipermail/freebsd-current/2011-October/028588.html http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/168253 What does the mean to you? Well, I will not be able to run FreeBSD from scratch on my soekris :-) Best regards. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On 09/11/2012 05:03 AM, Steve Kargl wrote: On Tue, Sep 11, 2012 at 04:10:13PM +0200, Dimitry Andric wrote: 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. Correct. Also, users who actually are helping with testing clang for ports continue to report runtime problems, even with things that build fine. Doug ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On Wed, Sep 12, 2012 at 04:15:20AM -0500, 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. No, I didn't mean it that way. I only meant that the people / maintainers running CURRENT will actually see that their ports don't work and if they want to keep on using them on CURRENT they need to fix them. e.g. two of the ports I maintain don't build with CLANG, yet. I just checked that on the wiki page [1]. I had to look that up manually, but would have experienced that if I my CURRENT box was building with CLANG by default. :) It's clear that we cannot expect our maintainers to check all possible combinations of FreeBSD, architecture and compiler. 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. [1] http://wiki.freebsd.org/PortsAndClang pgpYzIi4erNuX.pgp Description: PGP signature
Re: Clang as default compiler November 4th
On Wed, Sep 12, 2012 at 03:03:43PM +0200, Lars Engels wrote: two of the ports I maintain don't build with CLANG, yet. I just checked that on the wiki page [1]. To repeat myself, the ports I've listed on that page are the big problems. People need to look at the errorlogs URLs up at the top to see the complete list. mcl ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
Hello, Patrick. You wrote 12 сентября 2012 г., 1:22:44: PL Well, I will not be able to run FreeBSD from scratch on my soekris :-) Thank you for warning, I've missed this. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On 9/12/2012 12:40 AM, Erik Cederstrand wrote: 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. Yes, they do this now. The problem is that the set is growing, and the rate of growth is increasing. 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. Those are unrelated issues. Please re-read the bits of my post that you snipped. The overwhelming majority of problems we have with compiling ports now would be fixed by having a modern version of gcc as the official (i.e., supported) ports compiler. The clang efforts would be a parallel track. Doug ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On 9/12/2012 1:49 AM, David Chisnall wrote: 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. I personally am not directly involved in this effort (other than for my own ports), but from what I've seen the classical emphasis on pushing bug reports upstream has been applied in this area as well. hth, Doug ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On 09/11/12 09:56, Dimitry Andric wrote: 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 ___ If true, this is a serious problem, especially for those of us who use FreeBSD in a scientific computing environment. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On Wed, Sep 12, 2012 at 04:42:27PM -0500, Nathan Whitehorn wrote: On 09/11/12 09:56, Dimitry Andric wrote: 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 ___ If true, this is a serious problem, especially for those of us who use FreeBSD in a scientific computing environment. Just to clarify. I do not oppose switching the default compiler to clang as long as the proponents for the switch have shown adequate testing. Neither clang successfully building world nor clang building a working kernel are adequate testing (IMHO). Neither of those benchmarks use floating point, and AFAIK the libm built by clang during a buildworld is not (extensively?) exercised. As far as the URL above, I've been fixing accuracy issues in the j0f() function, and so, I have a program that allows me to exhaustively test all possible input values in the range reported. For my locally patched j0f(), I saw the issue as reported in the URL, but in doing additional development on j0f() I accidentally deletely/lost that specific version of the code. I hope to regenerate the code from my notes this weekend, and redo the tests. 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'. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
Doug Barton do...@freebsd.org writes:
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.)
To that effect ports also need to respect CC/CXX. There were a few -exp
runs without /usr/bin/{cc,gcc,etc} to find out non-conforming ones as
part of ports/159117. However, the issue was quickly shoved under the
carpet in order to focus on the more important, clang as default.
# last try, assumes_gcc are ports ignoring CC/CXX, many are fixed
http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110723205754/index-reason.html
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
--
Ignoring for the moment clang -exp runs are *still* done with clang 3.0
while we're discussing here clang 3.2 becoming default.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On 2012-09-11 09:58, David Chisnall wrote: 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. Yes, this happens a lot, even with relatively new software. Though I don't see why we couldn't just add -std=gnu89 by default in bsd.port.mk, if no CSTD= setting is specified. This should work for any version of clang, or any other compilers that don't default to gnu89. 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. :) 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. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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. pgpUPRRZ1NomD.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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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. pgpXDPuDfGdBI.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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
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. 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. For this 'silly' benchmark, I would suggest to benchmark the identical buildworlds with only different kernels, compiled with in-tree gcc and clang. 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. pgpBgClmZh3yt.pgp Description: PGP signature
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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
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 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. How fast clang builds world in comparison to gcc is irrelevant. What is important is whether software built with clang functions correctly. See for example, http://math-atlas.sourceforge.net/errata.html#WhatComp Has anyone run Spec CPU2006 on i386 and amd64 FreeBSD? -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On Tue, Sep 11, 2012 at 02:52:20PM +0200, Erik Cederstrand wrote: Den 11/09/2012 kl. 14.38 skrev Roman Divacky rdiva...@freebsd.org: 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. Interest twist of history. GCC is not abandonware. I can assure you GCC development is very much alive. The abandonment of GCC was a FreeBSD developers/community decision. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
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. -- chs, ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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 pgpsRhzbLs6RP.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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On 9/11/12, Brooks Davis bro...@freebsd.org wrote: 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. 1-2% on SMP workload can just be part of the variance due to memory layout changes. What I would like to see is benchmarks in UP configurations, like machine booting with only one process and doing make buildworld (no -j at all). This could give a good measurement if the compiler changed anything or not. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On Sep 11, 2012, at 8:35 AM, Daniel Eischen wrote: 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! Alternate compilers are being used on other OS distributions, like Arch Linux, Gentoo Linux, etc, so encouraging external developers to correct/simplify their Makefiles and build infrastructures is a good thing (and plus, it makes switching to other compilers like icc, pcc, etc easier). You're going to run into almost the same problem when trying to get stuff to cross-compile for multiple targets, so there's no reason why FreeBSD/Linux should not strive to get others to hardcode less. I wouldn't consider ports to be a stopgap for the clang switchover as much as correctness/performance. Broken third-party software can be fixed, but if the underlying foundation doesn't deliver sane code or severely regresses performance (runtime is more important than building IMO because I'd rather have code take a little while longer to compile if the end-result runs faster, and ultimately runtime performance affects build performance), then there's no point in trying to switch over yet. Thanks, -Garrett___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On Tue, Sep 11, 2012 at 4:56 PM, Garrett Cooper yaneg...@gmail.com wrote: On Sep 11, 2012, at 8:35 AM, Daniel Eischen wrote: 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! Alternate compilers are being used on other OS distributions, like Arch Linux, Gentoo Linux, etc, so encouraging external developers to correct/simplify their Makefiles and build infrastructures is a good thing (and plus, it makes switching to other compilers like icc, pcc, etc easier). You're going to run into almost the same problem when trying to get stuff to cross-compile for multiple targets, so there's no reason why FreeBSD/Linux should not strive to get others to hardcode less. I wouldn't consider ports to be a stopgap for the clang switchover as much as correctness/performance. Broken third-party software can be fixed, but if the underlying foundation doesn't deliver sane code or severely regresses performance (runtime is more important than building IMO because I'd rather have code take a little while longer to compile if the end-result runs faster, and ultimately runtime performance affects build performance), then there's no point in trying to switch over yet. While this is generally true I think we need to make a distinction. To me speaking about not compiling ports doesn't mean anything. What are the bugs that actually prevents the vast majority of ports from compiling? (speaking of which anyone has testing their actual functionality too?) Because I really don't expect the bugs to be always the same repeated over and over, there will be some bugs depending by brain-o in the ports code and other depending by clang bugs. As kib@ rightly points out fixing indiscriminately ports is not the solution, but fixing ports when *the bug is actually in the port itself* is the right solution, otherwise fix the compiler for the other class of bugs. Did the people pushing for default clang make an assessment on the type of ports bug present? (and I see there is a lot of people aiming for it, so if the ports are splitted among several people we can get a good handle on it). Could such bugs be characterized and classified? Making such a huge change is also a matter of loosing much time on problems which don't seem directly related to it, but which infact prevent the system from working correctly. Switching to default CLANG with the current situation (20% of port not even compiling, ports compiler selection broken, libm loss of precision, performance barely analyzed in simplified scheme, etc.) is not an option in my head and people should really reconsider it, unless all these points gets properly addressed. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
Hello; Just my $0.02. - Original Message - ... 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 can only speak for Apache OpenOffice but since Apple did the switch already we are feeling a growing pressure to port OpenOffice to clang. For the time being we need gcc but we would really prefer something more up to date than gcc 4.2.1 + fixes. In other words, yes making clang the default may sound drastic but I am OK with killing base gcc and if clang is what is left I can live with it. Pedro. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
--On September 11, 2012 2:44:03 AM -0700 Doug Barton do...@freebsd.org wrote: 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. Perhaps a port maintainer's input would help? I'd never even heard of clang until recently. I'm not a programmer. If I can't get my ports to compile with clang without a knowledge of programming, I'll abandon them. I'm too old and too tired to try learning a brand new system. I doubt I'm alone. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead. Thomas Jefferson There are some ideas so wrong that only a very intelligent person could believe in them. George Orwell ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On Tue, 11 Sep 2012 09:10:24 -0500, Michael Butler i...@protected-networks.net wrote: - From the link (http://math-atlas.sourceforge.net/errata.html#WhatComp) that Steve Kargl referenced (dated July 2012). I don't know where this guy is getting his info, but CLANG is /more/ standards compliant and doesn't have an issue producing correct code. Though it might not be the fastest (yet). And if Apple (probably one of the largest commercial CLANG users) doesn't have an issue with it producing incorrect code why should we believe this guy? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On Tue, Sep 11, 2012 at 09:27:07AM -0700, Pedro Giffuni wrote: Hello; Just my $0.02. - Original Message - ... 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 can only speak for Apache OpenOffice but since Apple did the switch already we are feeling a growing pressure to port OpenOffice to clang. For the time being we need gcc but we would really prefer something more up to date than gcc 4.2.1 + fixes. In other words, yes making clang the default may sound drastic but I am OK with killing base gcc and if clang is what is left I can live with it. But allowing ports to select the compiler is the main point of my response, at least in the port part of it. I mean global configuration, and not referenced the existing per-port knobs (USE_GCC/WANT_GCC whatever). I would expect the portmgr to select some gcc (or clang or pcc or anything they find suitable) version and use it for a moment for ports. I do not claim that portmgr would consider 4.2.1 as the base for the switch but this is probably the least intrusive road right now. I do expect that selection shall be based on some measurement of the most supported compiler, and my gut feeling is that it ends as a version of gcc. Definitely, FreeBSD project is not a suitable place to make an efforts to port all existing OSS to clang, despite the opposite claims of the clang proponents. pgpJMvbi6kmYS.pgp Description: PGP signature
Re: Clang as default compiler November 4th
On Tue, Sep 11, 2012 at 11:42:53AM -0500, Mark Felder wrote: On Tue, 11 Sep 2012 09:10:24 -0500, Michael Butler i...@protected-networks.net wrote: - From the link (http://math-atlas.sourceforge.net/errata.html#WhatComp) that Steve Kargl referenced (dated July 2012). I don't know where this guy is getting his info, but CLANG is /more/ standards compliant and doesn't have an issue producing correct code. Though it might not be the fastest (yet). And if Apple (probably one of the largest commercial CLANG users) doesn't have an issue with it producing incorrect code why should we believe this guy? Who does 'this guy' refer to? If it is me, then I get my information from the developer of ATLAS. The issue isn't conformance to a standard. The issue is whether clang generates correct code when floating point is concerned. From the ATLAS installation guide date 10 Jul 2012: In most cases, switching these compilers will get you worse performance and accuracy, even when you are absolutely sure it is a better compiler and flag combination! In particular, our timings indicated that clang was always slower on all platforms that gcc, and that it very often produced incorrect code. If 'this guy' refers to the author of ATLAS, then 'this guy' is R. Clint Whaley. It is fairly easy to find his home page and thus his credentials. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
Clang produces incorrect code vs Clang's floating point has issues are two different arguments. 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 the maintainer can just force it to use the latest GCC. I'm not sure why Clang being default is somehow a problem for you? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On Tue, Sep 11, 2012 at 12:19 PM, Roman Divacky rdiva...@freebsd.orgwrote: 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. Not to speak for Steve, but he provided this information in another thread: http://lists.freebsd.org/pipermail/freebsd-current/2012-September/036410.html -- Adam Vande More ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On Tue, Sep 11, 2012 at 07:19:48PM +0200, Roman Divacky wrote: On Tue, Sep 11, 2012 at 08:12:30AM -0700, Steve Kargl wrote: 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 Unfortunately, supplying a test is going to be problematic. I thought I had a diff in one of my development trees, so I reverted the working copy of msun/e_j0f.c to stock source. gcc and clang give consistent results with stock e_j0f.c. When I went to re-apply my local changes, I discovered that I no longer had a diff. I think I can recreate the problematic code, but it will need to wait until the weekend. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
Thank you for taking time to explain the situation. I don't follow as closely as many on the current list do (and not subbed to toolchain). I'm sure the libm situation is on many people's radar now. Hopefully this can be resolved. My apologies for being so daft :-) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On Tue, Sep 11, 2012 at 10:07:04AM +0100, David Chisnall wrote: 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. And how then does a port say I don't compile with clang no matter how it is invoked? mcl ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
Le Mon, 10 Sep 2012 16:12:07 -0500, Brooks Davis bro...@freebsd.org a écrit : Hello, 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. Last time I've checked on 9.X [mid August, FreeBSD clang version 3.1 (branches/release_31 156863) 20120523], Clang still produces invalid code (some nopl (%eax)) for the AMD Geode LX (i586 CPU found on some ALIX board or Soekris NET5501). I don't know if this is also a concern with older CPU (Pentium 2/1) ? http://llvm.org/bugs/show_bug.cgi?id=11212 http://lists.freebsd.org/pipermail/freebsd-current/2011-October/028588.html http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/168253 What does the mean to you? Well, I will not be able to run FreeBSD from scratch on my soekris :-) Best regards. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On Tue, Sep 11, 2012 at 1:44 PM, Mark Linimon lini...@lonesome.com wrote:
On Tue, Sep 11, 2012 at 10:07:04AM +0100, David Chisnall wrote:
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.
And how then does a port say I don't compile with clang no matter how
it is invoked?
Here's one way:
$ clang -dumpspecs
clang: error: unsupported option '-dumpspecs'
clang: error: no input files
$ gcc -dumpspecs | grep -q gcc echo gotcha
gotcha
$
Also,
$ cat Makefile
.if !empty(CC:M*clang*) || !empty(CXX:M*clang*)
IGNORE= does not compile with clang
.warning ${IGNORE}
.endif
all:
$ make CXX=clang++
Makefile, line 3: warning: does not compile with clang
$ make CXX=g++
$
But I figured that's probably done elsewhere I bit more sanely.
Thanks,
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
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 pgphhVw0hzHmw.pgp Description: PGP signature
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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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 On 09/10/2012 14: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 - -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQTtH8AAoJEFzGhvEaGryEU3gIAJ3X2EHDCVnkC/CYTMOkceho KS6qVcQK4OCbbG+8TKkjrHNdiBO7ZuJKxfvr/TZC1zNKc8wYBlWo3s07wCHmu8Nj OP8UwTMKumnljnYlRanQiLO9iAZKwGfI2gdxJTb5YABN2StRMXnD17Yyic6pw090 7l+cQw3iJAI8vbO4su33HJOhru0o4XLodbazHXFc6RjabAfXfuk1W6V0PfAodVC9 ZUGbF4WA7F0sJOEVuohmSk8ICHQRzTWofpdvCTlhHc1XYTaQ9u/dLGUp1C8g/BUG CJQua7wsBdf4VgsvlYBxTAOEpURqot0Ild7zQL+9vZtf7cGCsfalpwBWzQ9J/Wk= =gRkN -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
