Re: Clang as default compiler November 4th

[Roman Divacky]

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 
> 
> ___
> freebsd-toolchain@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
> To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Mehmet Erol Sanliturk]

On Tue, Sep 18, 2012 at 7:23 AM, Tijl Coosemans  wrote:

> On 15-09-2012 17:39, Mehmet Erol Sanliturk wrote:
> > On Sat, Sep 15, 2012 at 7:30 AM, 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.
> >
> > 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 
> > #include 
> > #include 
> >
> > 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 
> > #include 
> > #include 
> >
> > 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-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Tijl Coosemans]

On 15-09-2012 17:39, Mehmet Erol Sanliturk wrote:
> On Sat, Sep 15, 2012 at 7:30 AM, 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. 
> 
> 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 
> #include 
> #include 
> 
> 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 
> #include 
> #include 
> 
> 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

[Steve Kargl]

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 .

Thanks.

-- 
Steve
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Dimitry Andric]

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 .

___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Warner Losh]

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-curr...@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> ___
> freebsd-toolchain@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
> To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Mehmet Erol Sanliturk]

On Sat, Sep 15, 2012 at 7:30 AM, 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.
>
>



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 
#include 
#include 

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 
#include 
#include 

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 
#include 
#include 

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-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Mehmet Erol Sanliturk]

On Sat, Sep 15, 2012 at 7:30 AM, 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.
>
>


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-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Tijl Coosemans]

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

[Roman Divacky]

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 
> #include 
> #include 
> 
> int
> main( int argc, char **argv ) {
>   double d = strtod( argv[ 1 ], NULL );
> 
>   printf( "%e\n", ( double ) cos( d ));
>   printf( "%e\n", ( double ) cosf( d ));
>   printf( "%e\n", ( double ) cosl( d ));
>   return( 0 );
> }
> 
> 
> This is the current output of clang:
> 
> % clang -o cos cos.c -lm
> % ./cos 1.23456789e20
> 6.031937e-01
> 1.234568e+20
> 2.814722e-01
> 
> The second number (cosf) is wrong. It should be a value between -1 and 1.
> 


___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Tijl Coosemans]

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 
#include 
#include 

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

[Roman Divacky]

Fwiw, this seems to have been fixed as of a few minutes ago.

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120910/150720.html

Steve, can you please test llvm/clang from (their) svn and report
back? We can import a newer snapshot if all is ok.

Thank you.

On Fri, Sep 14, 2012 at 06:06:00PM -0700, Steve Kargl wrote:
> On Fri, Sep 14, 2012 at 05:18:08PM -0700, Steve Kargl wrote:
> > 
> > A third class of failure appears to be that clang emits
> > i387 fpu instructions for at least sinf and cosf instead 
> > of calls to the library routines.  AFAIK, the library
> > routines are faster and more accurate.
> > 
> 
> Yep. Clang has problems with at least sinf on i386 FreeBSD.
> 
> % pwd
> /usr/home/kargl/trunk/math/sine
> 
> % make clean && make CC=cc testf
> cc -o testf -O2 -pipe -static -I/usr/local/include -I../mp testf.c \
>  -L/usr/local/lib -L../mp -lsgk -lmpfr -lgmp -lm
> 
> % ./testf -m 0 -M 1e20 -r
>  ULP Range |
> ---+-
>  [0.0:0.6] | 1006424(100.00%)
>  (0.6:0.7] | 0  ( 0.00%)
>  (0.7:0.8] | 0  ( 0.00%)
>  (0.8:0.9] | 0  ( 0.00%)
>  (0.9:1.0] | 0  ( 0.00%)
>  (1.0:2.0] | 0  ( 0.00%)
>  (2.0:3.0] | 0  ( 0.00%)
>  3.0 < ULP | 0  ( 0.00%)
> ---+-
>Count   | 1006424
>Max ULP | 0.50084
>  Max ULP x | 53462490661259313152.00 0x1.72f876p+65
> 
> % make clean && make CC=clang testf
> clang -o testf -O2 -pipe -static -I/usr/local/include -I../mp testf.c \
>  -L/usr/local/lib -L../mp -lsgk -lmpfr -lgmp -lm
> 
> % ./testf -m 0 -M 1e20 -r
>  ULP Range |
> ---+-
>  [0.0:0.6] | 1  ( 0.00%)
>  (0.6:0.7] | 0  ( 0.00%)
>  (0.7:0.8] | 0  ( 0.00%)
>  (0.8:0.9] | 0  ( 0.00%)
>  (0.9:1.0] | 0  ( 0.00%)
>  (1.0:2.0] | 0  ( 0.00%)
>  (2.0:3.0] | 0  ( 0.00%)
>  3.0 < ULP | 98 (100.00%)
> ---+-
>Count   | 99
>Max ULP | 1328505256679420125050194353979392.0
>  Max ULP x | 75516780764213542912.00 0x1.06006p+66
> 
> -- 
> Steve
> ___
> freebsd-curr...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Tijl Coosemans]

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

[Roman Divacky]

LLVM by default turns these:

case LibFunc::copysign:  case LibFunc::copysignf:  case LibFunc::copysignl:
case LibFunc::fabs:  case LibFunc::fabsf:  case LibFunc::fabsl:
case LibFunc::sin:   case LibFunc::sinf:   case LibFunc::sinl:
case LibFunc::cos:   case LibFunc::cosf:   case LibFunc::cosl:
case LibFunc::sqrt:  case LibFunc::sqrtf:  case LibFunc::sqrtl:
case LibFunc::floor: case LibFunc::floorf: case LibFunc::floorl:
case LibFunc::nearbyint: case LibFunc::nearbyintf: case LibFunc::nearbyintl:
case LibFunc::ceil:  case LibFunc::ceilf:  case LibFunc::ceill:
case LibFunc::rint:  case LibFunc::rintf:  case LibFunc::rintl:
case LibFunc::trunc: case LibFunc::truncf: case LibFunc::truncl:
case LibFunc::log2:  case LibFunc::log2f:  case LibFunc::log2l:
case LibFunc::exp2:  case LibFunc::exp2f:  case LibFunc::exp2l:

from lib calls to direct code (ie. instruction or sequence of). This is not a 
"bug"
but feature ;)

I am not sure what the rules for the transformation should be. Allow it only 
with
-ffast-math ? Disallow it on i386? Really, no idea.

Steve, you tested on i386? Can you test on amd64?

Do you guys have any opinion what to do here?

On Fri, Sep 14, 2012 at 06:06:00PM -0700, Steve Kargl wrote:
> On Fri, Sep 14, 2012 at 05:18:08PM -0700, Steve Kargl wrote:
> > 
> > A third class of failure appears to be that clang emits
> > i387 fpu instructions for at least sinf and cosf instead 
> > of calls to the library routines.  AFAIK, the library
> > routines are faster and more accurate.
> > 
> 
> Yep. Clang has problems with at least sinf on i386 FreeBSD.
> 
> % pwd
> /usr/home/kargl/trunk/math/sine
> 
> % make clean && make CC=cc testf
> cc -o testf -O2 -pipe -static -I/usr/local/include -I../mp testf.c \
>  -L/usr/local/lib -L../mp -lsgk -lmpfr -lgmp -lm
> 
> % ./testf -m 0 -M 1e20 -r
>  ULP Range |
> ---+-
>  [0.0:0.6] | 1006424(100.00%)
>  (0.6:0.7] | 0  ( 0.00%)
>  (0.7:0.8] | 0  ( 0.00%)
>  (0.8:0.9] | 0  ( 0.00%)
>  (0.9:1.0] | 0  ( 0.00%)
>  (1.0:2.0] | 0  ( 0.00%)
>  (2.0:3.0] | 0  ( 0.00%)
>  3.0 < ULP | 0  ( 0.00%)
> ---+-
>Count   | 1006424
>Max ULP | 0.50084
>  Max ULP x | 53462490661259313152.00 0x1.72f876p+65
> 
> % make clean && make CC=clang testf
> clang -o testf -O2 -pipe -static -I/usr/local/include -I../mp testf.c \
>  -L/usr/local/lib -L../mp -lsgk -lmpfr -lgmp -lm
> 
> % ./testf -m 0 -M 1e20 -r
>  ULP Range |
> ---+-
>  [0.0:0.6] | 1  ( 0.00%)
>  (0.6:0.7] | 0  ( 0.00%)
>  (0.7:0.8] | 0  ( 0.00%)
>  (0.8:0.9] | 0  ( 0.00%)
>  (0.9:1.0] | 0  ( 0.00%)
>  (1.0:2.0] | 0  ( 0.00%)
>  (2.0:3.0] | 0  ( 0.00%)
>  3.0 < ULP | 98 (100.00%)
> ---+-
>Count   | 99
>Max ULP | 1328505256679420125050194353979392.0
>  Max ULP x | 75516780764213542912.00 0x1.06006p+66
> 
> -- 
> Steve
> ___
> freebsd-curr...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Steve Kargl]

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

Yep. Clang has problems with at least sinf on i386 FreeBSD.

% pwd
/usr/home/kargl/trunk/math/sine

% make clean && make CC=cc testf
cc -o testf -O2 -pipe -static -I/usr/local/include -I../mp testf.c \
 -L/usr/local/lib -L../mp -lsgk -lmpfr -lgmp -lm

% ./testf -m 0 -M 1e20 -r
 ULP Range |
---+-
 [0.0:0.6] | 1006424(100.00%)
 (0.6:0.7] | 0  ( 0.00%)
 (0.7:0.8] | 0  ( 0.00%)
 (0.8:0.9] | 0  ( 0.00%)
 (0.9:1.0] | 0  ( 0.00%)
 (1.0:2.0] | 0  ( 0.00%)
 (2.0:3.0] | 0  ( 0.00%)
 3.0 < ULP | 0  ( 0.00%)
---+-
   Count   | 1006424
   Max ULP | 0.50084
 Max ULP x | 53462490661259313152.00 0x1.72f876p+65

% make clean && make CC=clang testf
clang -o testf -O2 -pipe -static -I/usr/local/include -I../mp testf.c \
 -L/usr/local/lib -L../mp -lsgk -lmpfr -lgmp -lm

% ./testf -m 0 -M 1e20 -r
 ULP Range |
---+-
 [0.0:0.6] | 1  ( 0.00%)
 (0.6:0.7] | 0  ( 0.00%)
 (0.7:0.8] | 0  ( 0.00%)
 (0.8:0.9] | 0  ( 0.00%)
 (0.9:1.0] | 0  ( 0.00%)
 (1.0:2.0] | 0  ( 0.00%)
 (2.0:3.0] | 0  ( 0.00%)
 3.0 < ULP | 98 (100.00%)
---+-
   Count   | 99
   Max ULP | 1328505256679420125050194353979392.0
 Max ULP x | 75516780764213542912.00 0x1.06006p+66

-- 
Steve
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Steve Kargl]

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 
float
foo(float x) {
   float a;
   a = sinf(x) * cosf(x);
   return (a);
}

% clang -S -O a.c

foo:# @foo
# BB#0: # %entry
flds4(%esp)
fld %st(0)
fcos
fxch
fsin
fmulp
ret

% cc -S -O a.c

foo:
pushl   %ebp
movl%esp, %ebp
pushl   %ebx
subl$20, %esp
movl8(%ebp), %ebx
movl%ebx, (%esp)
callsinf
fstps   -8(%ebp)
movl%ebx, (%esp)
callcosf
fmuls   -8(%ebp)
addl$20, %esp
popl%ebx
popl%ebp
ret

% clang -S -O -fno-builtin a.c
foo:# @foo
# BB#0: # %entry
pushl   %ebp
movl%esp, %ebp
subl$24, %esp
flds8(%ebp)
fsts-16(%ebp)   # 4-byte Folded Spill
fstps   (%esp)
calll   sinf
fstpt   -12(%ebp)   # 10-byte Folded Spill
flds-16(%ebp)   # 4-byte Folded Reload
fstps   (%esp)
calll   cosf
fldt-12(%ebp)   # 10-byte Folded Reload
fmulp
addl$24, %esp
popl%ebp
ret

Using -fno-builtin would seem to be a non-starter in that it
disables all builtin functions.

-- 
Steve
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Brooks Davis]

On Thu, Sep 13, 2012 at 09:10:24AM -0700, Steve Kargl wrote:
> On Thu, Sep 13, 2012 at 09:32:12AM -0600, Ian Lepore wrote:
> > On Wed, 2012-09-12 at 19:08 -0700, Steve Kargl wrote:
> > > In regards to my initial post in this thread, I was just trying
> > > to assess whether any benchmarks have been performed on FreeBSD
> > > for floating point generated by clang.  Other than the limited
> > > testing that I've done, it appears that the answer is 'no'.
> > > 
> > 
> > We have src/tools/tests/testfloat and src/tools/regression/lib/msun.  I
> > know nothing about the former (just noticed it for the first time).  The
> > latter I think is a set of correctness tests rather than performance
> > tests.
> 
> It's quite clear that the clang proponent have not tried
> to run src/tools/regression/lib/msun.
> 
> % setenv CC clang
> % make  |& grep warning | wc -l
> 1354
> % make clean
> % make |& tee make.log
> % head -20 make.log
> clang -O2 -pipe -march=opteron -O0 -lm  test-cexp.c  -o test-cexp
> test-cexp.c:49:14: warning: pragma STDC FENV_ACCESS ON is not supported, 
> ignoring pragma [-Wunknown-pragmas]
> #pragma STDC FENV_ACCESSON
>  ^
> test-cexp.c:183:2: warning: expression result unused [-Wunused-value]
> testall(0.0, 1.0, ALL_STD_EXCEPT, 0, 1);
> ^~~
> test-cexp.c:98:7: note: expanded from macro 'testall'
> test(cexp, x, result, exceptmask, excepts, checksign);  \
>  ^
> test-cexp.c:87:11: note: expanded from macro 'test'
> assert(((func), fetestexcept(exceptmask) == (excepts)));\
>  ^
> /usr/include/assert.h:54:21: note: expanded from macro 'assert'
> #define assert(e)   ((e) ? (void)0 : __assert(__func__, __FILE__, \
>   ^
> test-cexp.c:183:2: warning: expression result unused [-Wunused-value]
> testall(0.0, 1.0, ALL_STD_EXCEPT, 0, 1);
> ^~~
> test-cexp.c:99:7: note: expanded from macro 'testall'
> 
> % tail -20 make.log
> test-trig.c:69:11: note: expanded from macro 'test'
> assert(((func), fetestexcept(exceptmask) == (excepts)));\
>  ^
> /usr/include/assert.h:54:21: note: expanded from macro 'assert'
> #define assert(e)   ((e) ? (void)0 : __assert(__func__, __FILE__, \
>   ^
> 74 warnings generated.
> clang -O2 -pipe -march=opteron -O0 -lm  test-fenv.c  -o test-fenv
> test-fenv.c:82:14: warning: pragma STDC FENV_ACCESS ON is not supported, 
> ignoring pragma [-Wunknown-pragmas]
> #pragma STDC FENV_ACCESS ON
>  ^
> 1 warning generated.
> for p in test-cexp test-conj test-csqrt test-ctrig  test-exponential test-fma 
>  test-fmaxmin test-ilogb test-invtrig test-logarithm test-lrint  test-lround 
> test-nan test-nearbyint test-next test-rem test-trig  test-fenv; do 
> /usr/src/tools/regression/lib/msun/$p; done
> Assertion failed: (((cexp), fetestexcept((0x04 | 0x20 | 0x01 | 0x08 | 0x10)) 
> == (0))), function test_nan, file test-cexp.c, line 211.
> 1..7
> ok 1 - cexp zero
> Abort trap (core dumped)
> *** [tests] Error code 134
> 
> Stop in /usr/src/tools/regression/lib/msun.

Prompted by this post, I did a bit of testing and it looks like we have
two classes of failures that need to be investigated.  First, some tests
are failing with a gcc compiled world and clang compiled test code.
They seem to mostly be unexpected fp exception state when testing with
NaNs.  I suspect that someone more knowledgeable in this area could come
up with a reduced test case and explication of what clang is doing wrong
pretty quickly.

The second class is tests that fail when libm is compiled using clang.
I've not investigate those at all.  I'd tend to guess that we have a
wider range of issues there.

This is clearly an area we need more focus on before a switch to clang.
To a point I would be OK with it delaying the switch to work these
issues, but as with C99 long double support we can't let the quest for
perfection delay us indefinitely.

-- Brooks


pgpZPRfhJu5W1.pgp
Description: PGP signature

Re: Clang as default compiler November 4th

[Steve Kargl]

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-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Stefan Farfeleder]

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-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Steve Kargl]

On Thu, Sep 13, 2012 at 09:32:12AM -0600, Ian Lepore wrote:
> On Wed, 2012-09-12 at 19:08 -0700, Steve Kargl wrote:
> > In regards to my initial post in this thread, I was just trying
> > to assess whether any benchmarks have been performed on FreeBSD
> > for floating point generated by clang.  Other than the limited
> > testing that I've done, it appears that the answer is 'no'.
> > 
> 
> We have src/tools/tests/testfloat and src/tools/regression/lib/msun.  I
> know nothing about the former (just noticed it for the first time).  The
> latter I think is a set of correctness tests rather than performance
> tests.

It's quite clear that the clang proponent have not tried
to run src/tools/regression/lib/msun.

% setenv CC clang
% make  |& grep warning | wc -l
1354
% make clean
% make |& tee make.log
% head -20 make.log
clang -O2 -pipe -march=opteron -O0 -lm  test-cexp.c  -o test-cexp
test-cexp.c:49:14: warning: pragma STDC FENV_ACCESS ON is not supported, 
ignoring pragma [-Wunknown-pragmas]
#pragma STDC FENV_ACCESSON
 ^
test-cexp.c:183:2: warning: expression result unused [-Wunused-value]
testall(0.0, 1.0, ALL_STD_EXCEPT, 0, 1);
^~~
test-cexp.c:98:7: note: expanded from macro 'testall'
test(cexp, x, result, exceptmask, excepts, checksign);  \
 ^
test-cexp.c:87:11: note: expanded from macro 'test'
assert(((func), fetestexcept(exceptmask) == (excepts)));\
 ^
/usr/include/assert.h:54:21: note: expanded from macro 'assert'
#define assert(e)   ((e) ? (void)0 : __assert(__func__, __FILE__, \
  ^
test-cexp.c:183:2: warning: expression result unused [-Wunused-value]
testall(0.0, 1.0, ALL_STD_EXCEPT, 0, 1);
^~~
test-cexp.c:99:7: note: expanded from macro 'testall'

% tail -20 make.log
test-trig.c:69:11: note: expanded from macro 'test'
assert(((func), fetestexcept(exceptmask) == (excepts)));\
 ^
/usr/include/assert.h:54:21: note: expanded from macro 'assert'
#define assert(e)   ((e) ? (void)0 : __assert(__func__, __FILE__, \
  ^
74 warnings generated.
clang -O2 -pipe -march=opteron -O0 -lm  test-fenv.c  -o test-fenv
test-fenv.c:82:14: warning: pragma STDC FENV_ACCESS ON is not supported, 
ignoring pragma [-Wunknown-pragmas]
#pragma STDC FENV_ACCESS ON
 ^
1 warning generated.
for p in test-cexp test-conj test-csqrt test-ctrig  test-exponential test-fma  
test-fmaxmin test-ilogb test-invtrig test-logarithm test-lrint  test-lround 
test-nan test-nearbyint test-next test-rem test-trig  test-fenv; do 
/usr/src/tools/regression/lib/msun/$p; done
Assertion failed: (((cexp), fetestexcept((0x04 | 0x20 | 0x01 | 0x08 | 0x10)) == 
(0))), function test_nan, file test-cexp.c, line 211.
1..7
ok 1 - cexp zero
Abort trap (core dumped)
*** [tests] Error code 134

Stop in /usr/src/tools/regression/lib/msun.


So, clang does not support "#pragma STDC FENV_ACCESS ON".
That (IMHO) is a show stopper for clang as the default compiler,
because at least msun/src/e_sqrtl.c uses this pragma.

-- 
Steve
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Ian Lepore]

On Wed, 2012-09-12 at 19:08 -0700, Steve Kargl wrote:
> In regards to my initial post in this thread, I was just trying
> to assess whether any benchmarks have been performed on FreeBSD
> for floating point generated by clang.  Other than the limited
> testing that I've done, it appears that the answer is 'no'.
> 

We have src/tools/tests/testfloat and src/tools/regression/lib/msun.  I
know nothing about the former (just noticed it for the first time).  The
latter I think is a set of correctness tests rather than performance
tests.

-- Ian

___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Mark Linimon]

On Thu, Sep 13, 2012 at 08:21:31AM +0200, Pietro Cerutti wrote:
> On 2012-Sep-11, 23:29, Doug Barton wrote:
> > What we need to do is what I and others have been asking to do for
> > years. We need to designate a modern version of gcc (no less than 4.6)
> > as the official default ports compiler, and rework whatever is needed to
> > support this. Fortunately, that goal is much more easily achieved than
> > fixing ports to build and run with clang. (It's harder than it sounds
> > because there are certain key libs that define some paths depending on
> > what compiler they were built with, but still easier than dealing with
> > clang in the short term.)
> 
> I like the idea very much. My only concern is that gcc is heavy to
> build.

Gerald has been advocating this for a while as well.  In fact, he's
just made a commit that makes the lang/gcc42 compiler much easier to
bootstrap itself.

There's a set of interlocking changes that we need to make to the
infrastructure to modernize our compiler choices.  I've been talking
to Gerald about some of the aspects of it and hope to have something
to propose fairly soon.

But IMHO it's a little bit trickier than it appears at first glance.

mcl
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Pietro Cerutti]

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


pgpvUa618L1uo.pgp
Description: PGP signature

Re: Clang as default compiler November 4th

[Jan Beich]

Doug Barton  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-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Steve Kargl]

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-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Gerald Pfeifer]

On Tue, 11 Sep 2012, Erik Cederstrand wrote:
> So can we do a sweep on the ports tree and mark the 2232 ports with 
> USE_GCC=4.2 until they can actually build with clang? This could allow 
> the clang switch to proceed. Hopefully, waiting for GCC to compile just 
> to install some tiny port will be enough of a nuisance for people to 
> eventually fix the remaining ports.

To make it less painful, I just adjusted lang/gcc42 to not boostrap
any more, rather just build.  This allows for a full build in ten or
less minutes on an old quad core I used for testing.

Gerald
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Nathan Whitehorn]

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-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Doug Barton]

On 9/12/2012 12:40 AM, Erik Cederstrand wrote:
> Den 12/09/2012 kl. 11.29 skrev Doug Barton :
> 
>> 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-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Doug Barton]

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-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Lev Serebryakov]

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 

___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Mark Linimon]

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-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Brooks Davis]

On Tue, Sep 11, 2012 at 06:29:00PM -0700, Darren Pilgrim wrote:
> On 2012-09-10 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.
> 
> Just to be clear, this change will only apply to 10-current, 10.0-R and 
> higher-numbered releases and branches, correct?  That is, it won't apply 
> to RELENG_9 and earlier?

Yes.  We have no current plans to change the default on older branches.

I do plan to merge changes that make it easier for users to choose clang
as their base system compiler on 9-STABLE, but changing the compiler
would be a terrible idea.

-- Brooks


pgpOyKJ8LwQzO.pgp
Description: PGP signature

Re: Clang as default compiler November 4th

[Dominic Fandrey]

On 11/09/2012 00:35, Chuck Burns wrote:

On Mon, Sep 10, 2012 at 5:01 PM, Brooks Davis  wrote:
...

For those worrying about "zomg, my system wont work?!" Remember..
This is a -current thing. If you're running bleeding edge, you have to
expect to get cut every now and then.


This is the perfect summary of what I think about this!

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Lars Engels]

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


pgpJEPGfwlCHs.pgp
Description: PGP signature

Re: Clang as default compiler November 4th

[David Chisnall]

On 12 Sep 2012, at 10:09, Doug Barton wrote:

> Also, users who actually are helping with testing clang for ports
> continue to report runtime problems, even with things that build fine.

I hope that you are encouraging maintainers of ports that don't work as 
expected with clang to submit bug reports upstream.  We can't fix bugs if we 
aren't made aware of them.

David
Current hat: LLVM / Clang 
developer.___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Erik Cederstrand]

Den 12/09/2012 kl. 11.29 skrev Doug Barton :

> On 09/11/2012 02:52 AM, Erik Cederstrand wrote:
>> So can we do a sweep on the ports tree and mark the 2232 ports with 
>> USE_GCC=4.2 until they can actually build with clang?
> 
> Unfortunately it isn't that simple. We already have a statistically
> significant number of ports that don't even compile with gcc 4.2.1. How
> many compilers do we expect the users to install? :)

If a port doesn't compile with the default compiler in base, I expect that port 
to add a build dependency on the compiler that it actually does compiles with. 
Of course, I hope to not have 6 different compilers installed on my system, but 
the list of build or runtime dependencies are at the discretion of the port 
(maintainer). As you (I think) said, we can't force port maintainers to patch 
their ports to support clang.

So even today, we have a significant number of ports that don't compile with 
the default compiler (GCC 4.2.1). Aren't they broken already, in the sense that 
they fail to tell me, the user, which compiler I should use?

Thanks,
Erik___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Roman Divacky]

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  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-curr...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Doug Barton]

On 09/11/2012 11:15 PM, Mark Linimon wrote:
> On Tue, Sep 11, 2012 at 11:27:50AM +0200, Lars Engels wrote:
>> At the moment the ports maintainers don't give much about if their ports
>> build with CLANG or not because they're not forced to.
> 
> I think this is a mis-representation.
> 
> Adding the requirement "your ports must work on clang" is adding an
> ex-post-facto requirement.  This creates the following matrix of what
> we are implicitly asking maintainers to do:
> 
> (FreeBSD 7|8|9|10) * (amd64|arm|i386|powerpc|sparc64) * (base gcc|base clang)
> 
> It is completely insane to expect anyone to be able to test in all of those
> environments, or even a tiny subset of them.  This isn't what most people
> sign up for when they sign up to maintain ports.
> 
>> Those who don't run CURRENT won't notice, but those who do will have to
>> get their butts up and fix the ports
> 
> I think it's foolish to assume that maintainres don't have their butts in
> gear as it is.  Please note, we have nearly 1300 PRs, hundreds of ports with
> build errors and/or PRs, and hundreds that fail on -current only.  I try to
> advertise all these things the best I know how.  Adding the hundreds that
> fail on -clang only and then blaming the maintainers is simply going to be
> counter-productive.

Write the day on your calendars folks, I completely agree with what Mark
said above. :) This is a big part of what I meant with some of my more
colorful comments in my original post on this topic.

Doug

___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Doug Barton]

On 09/11/2012 02:52 AM, Erik Cederstrand wrote:
> So can we do a sweep on the ports tree and mark the 2232 ports with 
> USE_GCC=4.2 until they can actually build with clang?

Unfortunately it isn't that simple. We already have a statistically
significant number of ports that don't even compile with gcc 4.2.1. How
many compilers do we expect the users to install? :)

What we need to do is what I and others have been asking to do for
years. We need to designate a modern version of gcc (no less than 4.6)
as the official default ports compiler, and rework whatever is needed to
support this. Fortunately, that goal is much more easily achieved than
fixing ports to build and run with clang. (It's harder than it sounds
because there are certain key libs that define some paths depending on
what compiler they were built with, but still easier than dealing with
clang in the short term.)

Once that is done, the compiler in the base is an afterthought, and we
can do away with gcc in the base altogether much more easily. Users who
want to help support building ports with clang can continue to do so.

Doug
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Mark Blackman]

On 12 Sep 2012, at 10:15, 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.

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-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Mark Linimon]

On Tue, Sep 11, 2012 at 11:27:50AM +0200, Lars Engels wrote:
> At the moment the ports maintainers don't give much about if their ports
> build with CLANG or not because they're not forced to.

I think this is a mis-representation.

Adding the requirement "your ports must work on clang" is adding an
ex-post-facto requirement.  This creates the following matrix of what
we are implicitly asking maintainers to do:

(FreeBSD 7|8|9|10) * (amd64|arm|i386|powerpc|sparc64) * (base gcc|base clang)

It is completely insane to expect anyone to be able to test in all of those
environments, or even a tiny subset of them.  This isn't what most people
sign up for when they sign up to maintain ports.

> Those who don't run CURRENT won't notice, but those who do will have to
> get their butts up and fix the ports

I think it's foolish to assume that maintainres don't have their butts in
gear as it is.  Please note, we have nearly 1300 PRs, hundreds of ports with
build errors and/or PRs, and hundreds that fail on -current only.  I try to
advertise all these things the best I know how.  Adding the hundreds that
fail on -clang only and then blaming the maintainers is simply going to be
counter-productive.

mcl
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Doug Barton]

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-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Darren Pilgrim]

On 2012-09-10 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.


Just to be clear, this change will only apply to 10-current, 10.0-R and 
higher-numbered releases and branches, correct?  That is, it won't apply 
to RELENG_9 and earlier?

___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Garrett Cooper]

On Tue, Sep 11, 2012 at 1:44 PM, Mark Linimon  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-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Patrick Lamaiziere]

Le Mon, 10 Sep 2012 16:12:07 -0500,
Brooks Davis  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-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Mark Linimon]

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-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Mark Felder]

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-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Steve Kargl]

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-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Adam Vande More]

On Tue, Sep 11, 2012 at 12:19 PM, Roman Divacky wrote:
>
> 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-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Steve Kargl]

On Tue, Sep 11, 2012 at 12:14:09PM -0500, Mark Felder wrote:
> "Clang produces incorrect code" vs "Clang's floating point has
> issues" are two different arguments. 

Wow.  clang produces incorrect floating point code, and
that's somehow just an issue with floating point.

> For a mathematical application it would be stupid to use
> clang if this is the case.  I see no problem with it being
> the default compiler though.  If Atlas is in ports ther
> maintainer can just force it to use the latest GCC. 

Last time I checked the code in src/lib/msun was built
by the default compiler into a library named libm.  If
clang can't produce valid floating point code, are you
suggesting that the base should have two compilers one (ie gcc)
for libm and any other application that may use floating
point and one (ie clang) for everything else?

> I'm not sure why Clang being default is somehow a problem for you?

For one, I'm the guy that has been fixing and implementing
missing functions in libm.  I've already shown that clang
generates worse code than base gcc for a single function in libm.

http://lists.freebsd.org/pipermail/freebsd-current/2012-September/036410.html
 
Granted j0f() in my libm had a local patch, but that
local patch actual improves j0f() accuracy over the 
range tested!

It can take hours (for a quick test) or days (for more
exhaustive testing) to test a simple patch, because I do
testing on i385, amd64, and sparc64 machines.  So, now,
I have to do the testing with 2 compilers.

You'll find that I'm the person that showed that clang 
can't do complex arithmetic correctly.  

http://llvm.org/bugs/show_bug.cgi?id=8532

That bug was reported almost 2 years ago.  

Finally, I'll note that I never stated that having 
clang as the default would be a problem for me.  I know
enough about compilers and floating pointing to test
a new compiler.  It the naive users (and I can assure you 
there are many more naive users than you may believe)
that is of concern.

-- 
Steve
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Roman Divacky]

On Tue, Sep 11, 2012 at 08:12:30AM -0700, Steve Kargl wrote:
> On Tue, Sep 11, 2012 at 04:27:55PM +0200, Tijl Coosemans wrote:
> > On 11-09-2012 16:10, Dimitry Andric wrote:
> > > On 2012-09-11 15:24, Steve Kargl wrote:
> > >> What is important is whether software built with clang functions
> > >> correctly.  See for example,
> > >>
> > >> http://math-atlas.sourceforge.net/errata.html#WhatComp
> > > 
> > > Yes, maths support, specifically precision, is admittedly still one of
> > > clang's (really llvm's) weaker points.  It is currently not really a
> > > high priority item for upstream.
> > > 
> > > This is obviously something that a certain part of our userbase will
> > > care a lot about, while most of the time they won't care so much about
> > > licensing or politics.  So those people are probably better off using
> > > gcc for the time being.
> > 
> > Does it affect the accuracy of libm functions?
> > 
> 
> I'm not sure if anyone has done any extensive testing.
> I've started to run some of my test codes to compare
> certain functions in a clang-compiled libm, gcc-compiled
> libm, and reference solutions generated from math/mpfr.
> For a locally patched j0f, I found that clang gave
> much worse accuracy.  If I revert the local patch,
> clang and gcc are to give the same results.  Unfortnately,
> an unpatched j0f gives 50 ULP errors.

Steve,

Can you please provide a small self contained test case that shows
that clang is doing worse on accuracy than gcc?

So that we can analyze it and decide if it's a bug in the code or
in the compiler. So far we know absolutely nothing.

Thank you, Roman
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Mark Felder]

"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-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Steve Kargl]

On Tue, Sep 11, 2012 at 11:42:53AM -0500, Mark Felder wrote:
> On Tue, 11 Sep 2012 09:10:24 -0500, Michael Butler  
>  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-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[David Naylor]

On Monday, 10 September 2012 23:12:07 Brooks Davis wrote:
> [Please confine your replies to toolch...@freebsd.org to keep the thread
> on the most relevant list.]
> 
> 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.

Hi

I know of two ports (wine and libreoffice) that did not work for a clang built 
world (something in libc broke), thus even if those ports were built with gcc 
they would fail to run.  

Has this been fixed, is known to be a problem, or is currently unknown?  If 
the latter I would gladly check, in the case of wine...  

Regards


signature.asc
Description: This is a digitally signed message part.

Re: Clang as default compiler November 4th

[Konstantin Belousov]

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.


pgpsY89OtFlg3.pgp
Description: PGP signature

Re: Clang as default compiler November 4th

[Mark Felder]

On Tue, 11 Sep 2012 09:10:24 -0500, Michael Butler  
 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-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Pedro Giffuni]

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-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Attilio Rao]

On Tue, Sep 11, 2012 at 4:56 PM, Garrett Cooper  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-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Garrett Cooper]

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-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Daniel Eischen]

On Tue, 11 Sep 2012, Konstantin Belousov wrote:


On Tue, Sep 11, 2012 at 02:06:49PM +0200, Roman Divacky wrote:


We currently dont compile 4680 ports (out of 23857). Top 10 ports that prevent
the most other ports from compiling together prevent  ports from
compilation. So if we fixed those 10 ports we could be at around 2500 ports
not compiling. Thats quite far from your claim of forking 20k programs.


Sorry, I cannot buy the argument. How many patches there are already
in the ports tree to cope with clang incompatibility with gcc ? You may
declare that all of them are application bugs, but it completely misses
the point.


[ snip ]


I believe majority of the broken ports is broken because their maintainer
never saw them being broken with clang just because it's not the default
compiler. Thus by making it the default majority of the problems would just
go away.


Can you, please, read what I wrote ? Fixing _ports_ to compile with
clang is plain wrong. Upstream developers use gcc almost always for
development and testing. Establishing another constant cost on the
porting work puts burden on the ports submitters, maintainers and even
ports users.


This is a good point!

--
DE
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Steve Kargl]

On Tue, Sep 11, 2012 at 04:27:55PM +0200, Tijl Coosemans wrote:
> On 11-09-2012 16:10, Dimitry Andric wrote:
> > On 2012-09-11 15:24, Steve Kargl wrote:
> >> What is important is whether software built with clang functions
> >> correctly.  See for example,
> >>
> >> http://math-atlas.sourceforge.net/errata.html#WhatComp
> > 
> > Yes, maths support, specifically precision, is admittedly still one of
> > clang's (really llvm's) weaker points.  It is currently not really a
> > high priority item for upstream.
> > 
> > This is obviously something that a certain part of our userbase will
> > care a lot about, while most of the time they won't care so much about
> > licensing or politics.  So those people are probably better off using
> > gcc for the time being.
> 
> Does it affect the accuracy of libm functions?
> 

I'm not sure if anyone has done any extensive testing.
I've started to run some of my test codes to compare
certain functions in a clang-compiled libm, gcc-compiled
libm, and reference solutions generated from math/mpfr.
For a locally patched j0f, I found that clang gave
much worse accuracy.  If I revert the local patch,
clang and gcc are to give the same results.  Unfortnately,
an unpatched j0f gives 50 ULP errors.

-- 
Steve
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Steve Kargl]

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

If /usr/bin/cc becomes clang, then the proposal is about more
than the FreeBSD system.  This affects any port that uses cc.

> If certain software performs significantly better with gcc, and using
> newer versions of the GPL is no problem, then it is obviously the better
> choice.
>
> However, I think the majority of users can get by just fine using clang,
> right now.  Doug Barton even confirmed in this thread that 80% of our
> ports already work with it!

He stated that 80% build with clang.  I doubt that he actually
tested the functionality of some 17000 ports.

> >What is important is whether software built with clang functions
> >correctly.  See for example,
> >
> >http://math-atlas.sourceforge.net/errata.html#WhatComp
> 
> Yes, maths support, specifically precision, is admittedly still one of
> clang's (really llvm's) weaker points.  It is currently not really a
> high priority item for upstream.
>
> This is obviously something that a certain part of our userbase will
> care a lot about, while most of the time they won't care so much about
> licensing or politics.  So those people are probably better off using
> gcc for the time being.

Which gets back to Doug's original point.  Until the ports
system has worked out its infrastructure for choosing a
compiler, a switch to clang as the default compiler would
seem to be premature.

> >Has anyone run Spec CPU2006 on i386 and amd64 FreeBSD?
> 
> I am not aware of it, but is that test available publicly?  I might take
> a shot, if I can get my hands on it.

Unfortunately, it has a cost associated with it.
http://www.spec.org/order.html.
Perhaps, the FreeBSD Foundation can make it available.

-- 
Steve
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Jeremy Messenger]

On Tue, Sep 11, 2012 at 7:21 AM, Konstantin Belousov
 wrote:

> Can you, please, read what I wrote ? Fixing _ports_ to compile with
> clang is plain wrong. Upstream developers use gcc almost always for
> development and testing. Establishing another constant cost on the
> porting work puts burden on the ports submitters, maintainers and even
> ports users.
>
> I do strongly oppose the attempt to drain the freebsd resources by
> forcing porters to port third-party code to other compiler.

I agree with this pretty much.

I haven't done fix any of port build with clang as I simply ignore
clang (sorry). When user report to me and I tell them to stick with
GCC as I don't support it.

Cheers,
Mezz


-- 
mezz.free...@gmail.com - m...@freebsd.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gn...@freebsd.org
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Dimitry Andric]

On 2012-09-11 16:27, Tijl Coosemans wrote:> On 11-09-2012 16:10, Dimitry Andric 
wrote:
...

Yes, maths support, specifically precision, is admittedly still one of
clang's (really llvm's) weaker points.  It is currently not really a
high priority item for upstream.

This is obviously something that a certain part of our userbase will
care a lot about, while most of the time they won't care so much about
licensing or politics.  So those people are probably better off using
gcc for the time being.


Does it affect the accuracy of libm functions?


It seems to, at least in specific cases; Steve posted about this in an
earlier thread on -current:

  http://docs.freebsd.org/cgi/mid.cgi?20120905221310.GA97847
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Attilio Rao]

On 9/11/12, Brooks Davis  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-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Chris Rees]

On 11 Sep 2012 13:22, "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.
>
> I do strongly oppose the attempt to drain the freebsd resources by
> forcing porters to port third-party code to other compiler.

I definitely see your point, but upstream should also be writing
correct/portable code.  Whenever a patch to fix a port is made, it is
actually mandatory to report it to upstream, and nag them to hell until
it's committed!  Most are very happy for this to happen; we've been
removing GNUisms from build scripts etc for years now (and I could link to
a "Thank you" email for all the build fixes I've sent upstream).

Sometimes, like the common bashism if [ a == b ] we bite the bullet and add
the extensions ourselves; sometimes upstream has an education on writing
portable code!

If we were all the same, would there be much point in being different?

Chris
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Tijl Coosemans]

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

[Paul Schmehl]

--On September 11, 2012 2:44:03 AM -0700 Doug Barton  
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-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[koobs k]

On 12 September 2012 00:08, Brooks Davis  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.

On that note, just identified the issue with multimedia/x264 and have
submitted a PR for it (ports/171542)

It also highlighted a missing libprofile_rt.a in base clang that
theraven has pinged dim@ about

~448 less affected ports to worry about now :)

--Koobs
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Michael Butler]

-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
>  wrote:
>> Interest twist of history.  GCC is not abandonware.
> 
> Correct, but GCC 4.2.1 is.
> 

While this may be true, I'm not inclined to move any of my gear to a
platform which is built on a tool-chain which is described in terms such
as ..

"In particular, clang/LLVM presently fails to produce correct code for
some operations, and is not performance competitive with gcc for any."

- From the link (http://math-atlas.sourceforge.net/errata.html#WhatComp)
that Steve Kargl referenced (dated July 2012).

While I appreciate the desire and need to move away from a legally
encumbering environment, stability and maturity are both critical
considerations.

This is not to say that GCC 4.2.1 is either bug-free or sufficiently
featureful as more modern versions but its idiosyncrasies are better
known and understood,

imb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (FreeBSD)

iEYEARECAAYFAlBPRlAACgkQQv9rrgRC1JLRUACeOGb8PryPla1yyhLeWzuVT4jM
+JEAoIbn1IEed5oXR5+e9SCIfmfQ4V5R
=ahHY
-END PGP SIGNATURE-
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Dimitry Andric]

On 2012-09-11 15:24, Steve Kargl wrote:
...

How fast clang builds world in comparison to gcc is irrelevant.


Not at all irrelevant: this proposal is about changing the default
compiler for the FreeBSD system itself, not for all software out there.

If certain software performs significantly better with gcc, and using
newer versions of the GPL is no problem, then it is obviously the better
choice.

However, I think the majority of users can get by just fine using clang,
right now.  Doug Barton even confirmed in this thread that 80% of our
ports already work with it!



What is important is whether software built with clang functions
correctly.  See for example,

http://math-atlas.sourceforge.net/errata.html#WhatComp


Yes, maths support, specifically precision, is admittedly still one of
clang's (really llvm's) weaker points.  It is currently not really a
high priority item for upstream.

This is obviously something that a certain part of our userbase will
care a lot about, while most of the time they won't care so much about
licensing or politics.  So those people are probably better off using
gcc for the time being.



Has anyone run Spec CPU2006 on i386 and amd64 FreeBSD?


I am not aware of it, but is that test available publicly?  I might take
a shot, if I can get my hands on it.
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Brooks Davis]

On Tue, Sep 11, 2012 at 01:45:18PM +0300, Konstantin Belousov wrote:
> On Mon, Sep 10, 2012 at 04:12:07PM -0500, Brooks Davis wrote:
> > For the past several years we've been working towards migrating from
> > GCC to Clang/LLVM as our default compiler.  We intend to ship FreeBSD
> > 10.0 with Clang as the default compiler on i386 and amd64 platforms.  To
> > this end, we will make WITH_CLANG_IS_CC the default on i386 and amd64
> > platforms on November 4th.
> > 
> > What does the mean to you?
> > 
> >  * When you build world after the default is changed /usr/bin/cc, cpp, and
> >c++ will be links to clang.
> > 
> >  * This means the initial phase of buildworld and "old style" kernel
> >compilation will use clang instead of gcc.  This is known to work.
> > 
> >  * It also means that ports will build with clang by default.  A major
> >of ports work, but a significant number are broken or blocked by
> >broken ports. For more information see:
> >  http://wiki.freebsd.org/PortsAndClang
> > 
> > What issues remain?
> > 
> >  * The gcc->clang transition currently requires setting CC, CXX, and CPP
> >in addition to WITH_CLANG_IS_CC.  I will post a patch to toolchain@
> >to address this shortly.
> > 
> >  * Ports compiler selection infrastructure is still under development.
> > 
> >  * Some ports could build with clang with appropriate tweaks.
> > 
> > What can you do to help?
> > 
> >  * Switch (some of) your systems.  Early adoption can help us find bugs.
> > 
> >  * Fix ports to build with clang.  If you don't have a clang system, you
> >can use the CLANG/amd64 or CLANG/i386 build environments on
> >redports.org.
> > 
> > tl;dr: Clang will become the default compiler for x86 architectures on 
> > 2012-11-04
> 
> There was a chorus of voices talking about ports already. My POV
> is that suggesting to 'fix remaining ports to work with clang' is
> just a nonsense. You are proposing to fork the development of all the
> programs which do not compile with clang. Often, upstream developers
> do not care about clang at all since it not being default compiler in
> Debian/Fedora/Whatever Linux. The project simply do not have resources
> to maintain the fork of 20K programs.

I may have phrased the above poorly, but in most cases I'd be happy with
using USE_GCC as a solution, but to the extent that port maintainers
can fix their ports to build with clang, that's a good thing.  Having a
deadline will help focus efforts towards finding the right fix for the
most important ports in a timely manner.

If we near the deadline and find that we need a few more weeks, nothing
prevents us from slipping the date a bit.

> Another issue with the switch, which seems to be not only not addressed,
> but even not talked about, is the performance impact of the change. I
> do not remember any measurements, whatever silly they could be, of the
> performance change by the compiler switch. We often have serious and
> argumented push-back for kernel changes that give as low as 2-3% of
> the speed hit. What are the numbers for clang change, any numbers ?

Florian Smeets (flo) did one round of benchmarks back in June with
sysbench/mysql.  There is a small but measurable slowdown both with
world compiled with clang and with mysql compiled with clang.  You can
see the results on the last page of this document:

http://people.freebsd.org/~flo/perf.pdf

The total impacts are on the order of 1-2%.  That's more than I'd like
and I expect some pushback, but I feel it is in the range of acceptable
code debt to take on to accomplish a multi-year project goal.

-- Brooks


pgpX5cC5yNg9i.pgp
Description: PGP signature

Re: Clang as default compiler November 4th

[Christer Solskogen]

On Tue, Sep 11, 2012 at 3:32 PM, Steve Kargl
 wrote:
> Interest twist of history.  GCC is not abandonware.

Correct, but GCC 4.2.1 is.

-- 
chs,
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Steve Kargl]

On Tue, Sep 11, 2012 at 02:52:20PM +0200, Erik Cederstrand wrote:
> Den 11/09/2012 kl. 14.38 skrev Roman Divacky :
> > 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-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Steve Kargl]

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-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Erik Cederstrand]

Roman,

Den 11/09/2012 kl. 14.38 skrev Roman Divacky :
> 
> Upstream developers almost never use gcc4.2.1 as we do. So right now the
> ports maintainer must check whats wrong in the case the (upgraded) port
> doesnt compile with our in-tree gcc.
> 
> 
> It can be trivial USE_GCC=4.something but the burden is exactly the same
> as with clang.

So can we do a sweep on the ports tree and mark the 2232 ports with USE_GCC=4.2 
until they can actually build with clang? This could allow the clang switch to 
proceed. Hopefully, waiting for GCC to compile just to install some tiny port 
will be enough of a nuisance for people to eventually fix the remaining ports.

> By the nature of "developing the OS" we are forced to use compilers and
> toolchains. Recently I saw you submitting/committing patches with .byte
> sequences because our default assembler cant handle the instructions.
> I saw jhb@ updating binutils to support invept/invvpid.
> 
> In my eyes, switching to clang by default lowers the compiler/toolchain
> maintenance burden we have.

I agree. Switching away from abandonware to a compiler that is actively 
maintained is a good thing.

Regarding performance, I could do some benchmarking in my spare time, but it 
does seem like an unforgiving task. Anyone posting any benchmark numbers on 
these lists is going to be tarred, feathered, forced to print out the full GCC 
4.2.1 source code, read it out loud on the town square, and spend the next 
month addressing concerns from people not willing to do the work themselves :-)

Erik___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Roman Divacky]

On Tue, Sep 11, 2012 at 03:21:22PM +0300, Konstantin Belousov wrote:
> On Tue, Sep 11, 2012 at 02:06:49PM +0200, Roman Divacky wrote:
> > > > tl;dr: Clang will become the default compiler for x86 architectures on 
> > > > 2012-11-04
> > > 
> > > There was a chorus of voices talking about ports already. My POV
> > > is that suggesting to 'fix remaining ports to work with clang' is
> > > just a nonsense. You are proposing to fork the development of all the
> > > programs which do not compile with clang. Often, upstream developers
> > > do not care about clang at all since it not being default compiler in
> > > Debian/Fedora/Whatever Linux. The project simply do not have resources
> > > to maintain the fork of 20K programs.
> >  
> > We currently dont compile 4680 ports (out of 23857). Top 10 ports that 
> > prevent
> > the most other ports from compiling together prevent  ports from
> > compilation. So if we fixed those 10 ports we could be at around 2500 ports
> > not compiling. Thats quite far from your claim of forking 20k programs.
> Sorry, I cannot buy the argument. How many patches there are already
> in the ports tree to cope with clang incompatibility with gcc ? You may
> declare that all of them are application bugs, but it completely misses
> the point.
> 
> > 
> > > Looking from less amiable angle, you propose to knowingly break 
> > > significant
> > > and important piece of the project work. My belief is that switch cannot
> > > be done before ports switch to the port-provided compiler.
> >  
> > I believe majority of the broken ports is broken because their maintainer
> > never saw them being broken with clang just because it's not the default
> > compiler. Thus by making it the default majority of the problems would just
> > go away.
> Can you, please, read what I wrote ? Fixing _ports_ to compile with
> clang is plain wrong. Upstream developers use gcc almost always for
> development and testing. Establishing another constant cost on the
> porting work puts burden on the ports submitters, maintainers and even
> ports users.

Upstream developers almost never use gcc4.2.1 as we do. So right now the
ports maintainer must check whats wrong in the case the (upgraded) port
doesnt compile with our in-tree gcc.


It can be trivial USE_GCC=4.something but the burden is exactly the same
as with clang.

> I do strongly oppose the attempt to drain the freebsd resources by
> forcing porters to port third-party code to other compiler.

We dont force anyone. Any port maintainer can decide to USE_GCC=4.2. We are not
advocating removing gcc but making clang default. The possibility of fallback
to gcc is still there.

> > > And, some small but annoying things left with clang, like ABI change
> > > requiring 16-byte stack alignment on i386, but lets ignore this until
> > > two big issues are resolved.
> > 
> > Thank you for pointing this out. This is, in my opinion, one of the 
> > strongest
> > reasons to switch to clang. We can go, fix issues or report we find upstream
> > and then import newer clang. Unlike with gcc.
> 
> We do not want to hunt for the compiler bugs at all, goal of FreeBSD
> is to develop the OS and not a compiler.

By the nature of "developing the OS" we are forced to use compilers and
toolchains. Recently I saw you submitting/committing patches with .byte
sequences because our default assembler cant handle the instructions.
I saw jhb@ updating binutils to support invept/invvpid.

In my eyes, switching to clang by default lowers the compiler/toolchain
maintenance burden we have.

Thank you, Roman.
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Konstantin Belousov]

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.


pgpYw2YTW2pBD.pgp
Description: PGP signature

Re: Clang as default compiler November 4th

[Roman Divacky]

> > tl;dr: Clang will become the default compiler for x86 architectures on 
> > 2012-11-04
> 
> There was a chorus of voices talking about ports already. My POV
> is that suggesting to 'fix remaining ports to work with clang' is
> just a nonsense. You are proposing to fork the development of all the
> programs which do not compile with clang. Often, upstream developers
> do not care about clang at all since it not being default compiler in
> Debian/Fedora/Whatever Linux. The project simply do not have resources
> to maintain the fork of 20K programs.
 
We currently dont compile 4680 ports (out of 23857). Top 10 ports that prevent
the most other ports from compiling together prevent  ports from
compilation. So if we fixed those 10 ports we could be at around 2500 ports
not compiling. Thats quite far from your claim of forking 20k programs.

> Looking from less amiable angle, you propose to knowingly break significant
> and important piece of the project work. My belief is that switch cannot
> be done before ports switch to the port-provided compiler.
 
I believe majority of the broken ports is broken because their maintainer
never saw them being broken with clang just because it's not the default
compiler. Thus by making it the default majority of the problems would just
go away.

Note that the work needed to make ports compiling with clang is largely shared
with the work to make them compiliable with newer GCCs (as they are stricter
etc.)

> Another issue with the switch, which seems to be not only not addressed,
> but even not talked about, is the performance impact of the change. I
> do not remember any measurements, whatever silly they could be, of the
> performance change by the compiler switch. We often have serious and
> argumented push-back for kernel changes that give as low as 2-3% of
> the speed hit. What are the numbers for clang change, any numbers ?

Agreed. We should provide numbers. At least how buildworld times change
with clang compiled kernel/workd and gcc compiler kernel/world.

> And, some small but annoying things left with clang, like ABI change
> requiring 16-byte stack alignment on i386, but lets ignore this until
> two big issues are resolved.

Thank you for pointing this out. This is, in my opinion, one of the strongest
reasons to switch to clang. We can go, fix issues or report we find upstream
and then import newer clang. Unlike with gcc.

Thank you, Roman
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Konstantin Belousov]

On Mon, Sep 10, 2012 at 04:12:07PM -0500, Brooks Davis wrote:
> [Please confine your replies to toolch...@freebsd.org to keep the thread
> on the most relevant list.]
I do not see how removing current@ can be done, toolchain@ is not
relevant for this discussion. Proposed is not a local change in the
toolchain itself, but a far reaching and IMO premature change.

> 
> For the past several years we've been working towards migrating from
> GCC to Clang/LLVM as our default compiler.  We intend to ship FreeBSD
> 10.0 with Clang as the default compiler on i386 and amd64 platforms.  To
> this end, we will make WITH_CLANG_IS_CC the default on i386 and amd64
> platforms on November 4th.
> 
> What does the mean to you?
> 
>  * When you build world after the default is changed /usr/bin/cc, cpp, and
>c++ will be links to clang.
> 
>  * This means the initial phase of buildworld and "old style" kernel
>compilation will use clang instead of gcc.  This is known to work.
> 
>  * It also means that ports will build with clang by default.  A major
>of ports work, but a significant number are broken or blocked by
>broken ports. For more information see:
>  http://wiki.freebsd.org/PortsAndClang
> 
> What issues remain?
> 
>  * The gcc->clang transition currently requires setting CC, CXX, and CPP
>in addition to WITH_CLANG_IS_CC.  I will post a patch to toolchain@
>to address this shortly.
> 
>  * Ports compiler selection infrastructure is still under development.
> 
>  * Some ports could build with clang with appropriate tweaks.
> 
> What can you do to help?
> 
>  * Switch (some of) your systems.  Early adoption can help us find bugs.
> 
>  * Fix ports to build with clang.  If you don't have a clang system, you
>can use the CLANG/amd64 or CLANG/i386 build environments on
>redports.org.
> 
> tl;dr: Clang will become the default compiler for x86 architectures on 
> 2012-11-04

There was a chorus of voices talking about ports already. My POV
is that suggesting to 'fix remaining ports to work with clang' is
just a nonsense. You are proposing to fork the development of all the
programs which do not compile with clang. Often, upstream developers
do not care about clang at all since it not being default compiler in
Debian/Fedora/Whatever Linux. The project simply do not have resources
to maintain the fork of 20K programs.

Looking from less amiable angle, you propose to knowingly break significant
and important piece of the project work. My belief is that switch cannot
be done before ports switch to the port-provided compiler.

Another issue with the switch, which seems to be not only not addressed,
but even not talked about, is the performance impact of the change. I
do not remember any measurements, whatever silly they could be, of the
performance change by the compiler switch. We often have serious and
argumented push-back for kernel changes that give as low as 2-3% of
the speed hit. What are the numbers for clang change, any numbers ?

And, some small but annoying things left with clang, like ABI change
requiring 16-byte stack alignment on i386, but lets ignore this until
two big issues are resolved.


pgpNKrF89TmKL.pgp
Description: PGP signature

Re: Clang as default compiler November 4th

[Doug Barton]

On 09/11/2012 02:27 AM, Lars Engels wrote:
> On Mon, Sep 10, 2012 at 10:54:04PM -0700, Doug Barton wrote:
>> As of last week, 4,680 ports out of 23,857 failed to build with clang on
>> 9-amd64. That's almost a 20% failure rate. Until we have better support
>> for either building ports with clang, or have better support for the
>> idea of a "ports compiler," this change is premature. The ports are an
>> important part of the FreeBSD Operating _System_, and pulling the
>> trigger on the default compiler before the ports problems are addressed
>> robustly seems like a big fat FU.
>>
>> That said, I agree that this issue needs to be addressed. In fact, 9
>> months before the release of 9.0 I said on the internal committers list
>> that there was no point in making a new release until we had thoroughly
>> addressed both the default compiler for the base, and resolving the
>> "ports compiler" issue. While there has been some movement on the
>> former, there has been nothing done on the latter for years now, even
>> though everyone agrees that it is an important issue.
>>
>> I'd like to request that rather than moving the default compiler
>> prematurely that you call for volunteers to address the problems with
>> the ports. Both the issues of fixing more ports to build correctly with
>> clang, and the issue of defining a "ports compiler" version of gcc (and
>> appropriate infrastructure) for those that can't. Once those issues are
>> resolved there would not be any further obstacles to moving the default.
>> Until they are, the change is premature.
>>
>> Doug
> 
> Doug, as you can already use CLANG instead of GCC now, you will be able
> to use GCC instead of CLANG after November 4th.

There's lots of things I _can_ do, what we're discussing is what the
defaults should be.

> At the moment the ports maintainers don't give much about if their ports
> build with CLANG or not

Do you follow ports development? At all? There have been extensive
efforts over the last several years to get more ports compiling with
clang. The problem is that things like the c89 issue don't percolate
down, and we don't have a concerted effort from all of the relevant
parties to improve the issue.

Fixing the problem of getting the right eyeballs on the things that need
fixing won't be improved by switching the default before they are fixed.
In fact, it's likely to make the people who are src-centric now even
less likely to help because their work will be "done."

> Those who don't run CURRENT won't notice, but those who do will have to
> get their butts up and fix the ports, so 10.0 can have 99% of all ports
> build with CLANG and even 8.x and 9.x can already profit from having the
> broken ports fixed now.

Yeah, and I'm going to get a pony out of this deal, right? :)

You completely misunderstand the nature of the problem, therefore your
proposed solution isn't going to solve it.

Doug

___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Lars Engels]

On Mon, Sep 10, 2012 at 10:54:04PM -0700, Doug Barton wrote:
> As of last week, 4,680 ports out of 23,857 failed to build with clang on
> 9-amd64. That's almost a 20% failure rate. Until we have better support
> for either building ports with clang, or have better support for the
> idea of a "ports compiler," this change is premature. The ports are an
> important part of the FreeBSD Operating _System_, and pulling the
> trigger on the default compiler before the ports problems are addressed
> robustly seems like a big fat FU.
> 
> That said, I agree that this issue needs to be addressed. In fact, 9
> months before the release of 9.0 I said on the internal committers list
> that there was no point in making a new release until we had thoroughly
> addressed both the default compiler for the base, and resolving the
> "ports compiler" issue. While there has been some movement on the
> former, there has been nothing done on the latter for years now, even
> though everyone agrees that it is an important issue.
> 
> I'd like to request that rather than moving the default compiler
> prematurely that you call for volunteers to address the problems with
> the ports. Both the issues of fixing more ports to build correctly with
> clang, and the issue of defining a "ports compiler" version of gcc (and
> appropriate infrastructure) for those that can't. Once those issues are
> resolved there would not be any further obstacles to moving the default.
> Until they are, the change is premature.
> 
> Doug

Doug, as you can already use CLANG instead of GCC now, you will be able
to use GCC instead of CLANG after November 4th.

At the moment the ports maintainers don't give much about if their ports
build with CLANG or not because they're not forced to.
Those who don't run CURRENT won't notice, but those who do will have to
get their butts up and fix the ports, so 10.0 can have 99% of all ports
build with CLANG and even 8.x and 9.x can already profit from having the
broken ports fixed now.


pgpJylqaSN0pf.pgp
Description: PGP signature

Re: Clang as default compiler November 4th

[David Chisnall]

On 11 Sep 2012, at 09:18, Dimitry Andric wrote:

> So I am a bit reluctant to change clang's default standard to c89,
> unless clang upstream agrees with this.  In the interest of prodding
> people to update their software, I would rather have the default stay
> c99, personally. :)

I'm not proposing changing the default when invoked as clang.  When invoked as 
clang or clang++, the default remains the same: the latest version of the 
standard (which will be C11 and C++11 in clang 3.2).  I am proposing changing 
the default to be C89 when invoked as cc or c89.

Clang upstream is happy with this (I asked on the mailing list at BSDCan, I 
just never got around to committing the change) and it also fixes another bug: 
clang is always in C99 mode, even when invoked as c89 or c11.

>> Given that POSIX deprecated cc in 1997, I'm quite tempted to say that we 
>> should just remove it entirely and just have c89, c99 and c11 (which the 
>> spec for cc says you should use instead), forcing people to explicitly 
>> select their language dialect, but that's a bikeshed for another day.
> 
> I think that is a little bit overkill.  People who don't care about
> standards anyway, will not go through the trouble of setting CC
> carefully to 'c89', 'c99' or 'c11'.  Most of their software simply
> hardcodes "gcc", and must be fixed manually after all.

There is some logic in the clang driver already for knowing when it is invoked 
as gcc.  I'd be quite tempted to make gcc a symlink to clang and make clang 
default to gnu89 when invoked in that way.

David___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Dimitry Andric]

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-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[David Chisnall]

I'd add one more thing that needs fixing:

Clang should default to c89 mode when invoked as cc.  I had a patch to do this, 
but I seem to have misplaced it.  I'll try to find or rewrite it in the next 
couple of days.  

A lot of the ports failures I saw were due to ports using cc as the default C 
compiler (autoconf seems to select it) and then using GNU89 inlining rules, so 
that they died with linker failures.  Given that POSIX deprecated cc in 1997, 
I'm quite tempted to say that we should just remove it entirely and just have 
c89, c99 and c11 (which the spec for cc says you should use instead), forcing 
people to explicitly select their language dialect, but that's a bikeshed for 
another day.

David

On 10 Sep 2012, at 22:12, Brooks Davis wrote:

> [Please confine your replies to toolch...@freebsd.org to keep the thread
> on the most relevant list.]
> 
> For the past several years we've been working towards migrating from
> GCC to Clang/LLVM as our default compiler.  We intend to ship FreeBSD
> 10.0 with Clang as the default compiler on i386 and amd64 platforms.  To
> this end, we will make WITH_CLANG_IS_CC the default on i386 and amd64
> platforms on November 4th.
> 
> What does the mean to you?
> 
> * When you build world after the default is changed /usr/bin/cc, cpp, and
>   c++ will be links to clang.
> 
> * This means the initial phase of buildworld and "old style" kernel
>   compilation will use clang instead of gcc.  This is known to work.
> 
> * It also means that ports will build with clang by default.  A major
>   of ports work, but a significant number are broken or blocked by
>   broken ports. For more information see:
> http://wiki.freebsd.org/PortsAndClang
> 
> What issues remain?
> 
> * The gcc->clang transition currently requires setting CC, CXX, and CPP
>   in addition to WITH_CLANG_IS_CC.  I will post a patch to toolchain@
>   to address this shortly.
> 
> * Ports compiler selection infrastructure is still under development.
> 
> * Some ports could build with clang with appropriate tweaks.
> 
> What can you do to help?
> 
> * Switch (some of) your systems.  Early adoption can help us find bugs.
> 
> * Fix ports to build with clang.  If you don't have a clang system, you
>   can use the CLANG/amd64 or CLANG/i386 build environments on
>   redports.org.
> 
> tl;dr: Clang will become the default compiler for x86 architectures on 
> 2012-11-04
> 
> -- Brooks

___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Doug Barton]

-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-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[matt]

On 09/10/12 14:22, Daniel Eischen wrote:

On Mon, 10 Sep 2012, Brooks Davis wrote:


[Please confine your replies to toolch...@freebsd.org to keep the thread
on the most relevant list.]

For the past several years we've been working towards migrating from
GCC to Clang/LLVM as our default compiler.  We intend to ship FreeBSD
10.0 with Clang as the default compiler on i386 and amd64 platforms.  To
this end, we will make WITH_CLANG_IS_CC the default on i386 and amd64
platforms on November 4th.

What does the mean to you?

* When you build world after the default is changed /usr/bin/cc, cpp, 
and

  c++ will be links to clang.

* This means the initial phase of buildworld and "old style" kernel
  compilation will use clang instead of gcc.  This is known to work.

* It also means that ports will build with clang by default.  A major
  of ports work, but a significant number are broken or blocked by
  broken ports. For more information see:
http://wiki.freebsd.org/PortsAndClang

What issues remain?

* The gcc->clang transition currently requires setting CC, CXX, and CPP
  in addition to WITH_CLANG_IS_CC.  I will post a patch to toolchain@
  to address this shortly.


I assume this will be done, tested and committed before 2012-11-04
(or whenever the switchover date is).



* Ports compiler selection infrastructure is still under development.


This should be a prerequisite before making the switch, given
that ports will be broken without a work-around for building
them with gcc.

I've been using a somewhat dirty method of doing this by checking the 
presence of a file in the port's main directory, e.g. if "basegcc" is 
present, build with that, if "clang" is present use it, otherwise 
default to gcc47.  Obviously that configuration is system specific, but 
the fundamental idea is look for a file in the ports directory that 
dictates the compiler. Perhaps even add a make ccconfig. It works quite 
nicely because you can resume a portmaster spree without having to 
suspend and change CC manually, or build all clang ports first etc. 
Further csup doesn't touch files it doesn't no about, so updating the 
tree (without wiping it out) preserves the fact you'd prefer or need to 
build a given port with something else.


There are definitely some ports that have been ignoring libmap.conf, 
which tends to require me to build some of their dependencies with base 
gcc, but otherwise I've been running this system for a few months and it 
works quite well...portmaster can upgrade without user intervention, and 
it's quite easy to add cflags logic.


Granted this works for me and is probably not the ideal solution...also 
hacked on it to post, so probably typos :)
Something like this in make.conf (with fstack-protector-all for all 
ports which works great)


.if !empty(.CURDIR:M/usr/ports/*)
CFLAGS+= -fstack-protector-all
.endif

.if empty(.CURDIR:M/usr/ports/*) && exists(/usr/local/bin/gcc47) && 
!exists(basegcc) && !exists(clang)

# this was occasionally necessary
#LDFLAGS+=-lintl
# custom cflags if desired
#CFLAGS+=-custom cflags for gcc47
#custom cputype if desired
CPUTYPE=amdfam10
CC=gcc47
CPP=cpp47
CXX=g++47
.endif
.if empty(.CURDIR:M/usr/ports/*) && exists(/usr/bin/clang) && exists(clang)
.if !defined(CC) || ${CC} == "cc"
CC=clang
.endif
.if !defined(CXX) || ${CXX} == "c++"
CXX=clang++
.endif
.if !defined(CPP) || ${CPP} == "cpp"
CPP=clang-cpp
.endif
NO_WERROR=
WERROR=
.endif

Usage is as simple as "touch basegcc" in the port dir or "touch clang" 
etc. to select appropriate compiler


Matt
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Chuck Burns]

On Mon, Sep 10, 2012 at 5:01 PM, Brooks Davis  wrote:
> On Mon, Sep 10, 2012 at 05:22:37PM -0400, Daniel Eischen wrote:
>> On Mon, 10 Sep 2012, Brooks Davis wrote:
>>
>> > [Please confine your replies to toolch...@freebsd.org to keep the thread
>> > on the most relevant list.]
>> >
>> > For the past several years we've been working towards migrating from
>> > GCC to Clang/LLVM as our default compiler.  We intend to ship FreeBSD
>> > 10.0 with Clang as the default compiler on i386 and amd64 platforms.  To
>> > this end, we will make WITH_CLANG_IS_CC the default on i386 and amd64
>> > platforms on November 4th.
>> >
>> > What does the mean to you?
>> >
>> > * When you build world after the default is changed /usr/bin/cc, cpp, and
>> >   c++ will be links to clang.
>> >
>> > * This means the initial phase of buildworld and "old style" kernel
>> >   compilation will use clang instead of gcc.  This is known to work.
>> >
>> > * It also means that ports will build with clang by default.  A major
>> >   of ports work, but a significant number are broken or blocked by
>> >   broken ports. For more information see:
>> > http://wiki.freebsd.org/PortsAndClang
>> >
>> > What issues remain?
>> >
>> > * The gcc->clang transition currently requires setting CC, CXX, and CPP
>> >   in addition to WITH_CLANG_IS_CC.  I will post a patch to toolchain@
>> >   to address this shortly.
>>
>> I assume this will be done, tested and committed before 2012-11-04
>> (or whenever the switchover date is).
>
> Pending review it will be done this week.
>
>> > * Ports compiler selection infrastructure is still under development.
>>
>> This should be a prerequisite before making the switch, given
>> that ports will be broken without a work-around for building
>> them with gcc.
>
> We've defacto done that for more than a year.  Some progress has
> resulted, but not enough.  I will be helping fix ports and I hope others
> do as well.  It's worth noting that a switchable compiler isn't a magic
> bullet.  Many ports will need to be patched to support a compiler other
> than /usr/bin/cc or /usr/bin/gcc.
>
> -- Brooks

This is actually a pretty good thing.  Because -before- it's the
default compiler, some ports maintainers (and even more upstreams)
have the attitude of "My port works fine" until it no longer does..
bringing this change will make a few of these people realize that we
are -serious- about switching to clang.

For those worrying about "zomg, my system wont work?!" Remember..
This is a -current thing. If you're running bleeding edge, you have to
expect to get cut every now and then.
-- 
Chuck Burns 
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Clang as default compiler November 4th

[Brooks Davis]

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


pgpboAZPyAwWg.pgp
Description: PGP signature

Re: Clang as default compiler November 4th

[Daniel Eischen]

On Mon, 10 Sep 2012, Brooks Davis wrote:


[Please confine your replies to toolch...@freebsd.org to keep the thread
on the most relevant list.]

For the past several years we've been working towards migrating from
GCC to Clang/LLVM as our default compiler.  We intend to ship FreeBSD
10.0 with Clang as the default compiler on i386 and amd64 platforms.  To
this end, we will make WITH_CLANG_IS_CC the default on i386 and amd64
platforms on November 4th.

What does the mean to you?

* When you build world after the default is changed /usr/bin/cc, cpp, and
  c++ will be links to clang.

* This means the initial phase of buildworld and "old style" kernel
  compilation will use clang instead of gcc.  This is known to work.

* It also means that ports will build with clang by default.  A major
  of ports work, but a significant number are broken or blocked by
  broken ports. For more information see:
http://wiki.freebsd.org/PortsAndClang

What issues remain?

* The gcc->clang transition currently requires setting CC, CXX, and CPP
  in addition to WITH_CLANG_IS_CC.  I will post a patch to toolchain@
  to address this shortly.


I assume this will be done, tested and committed before 2012-11-04
(or whenever the switchover date is).



* Ports compiler selection infrastructure is still under development.


This should be a prerequisite before making the switch, given
that ports will be broken without a work-around for building
them with gcc.

--
DE
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"