Re: GCC withdraw
g the > WITH_GCCflag > > - On platforms where clang is not cc, leave gcc as the default system > compiler > > - On platforms where clang is not cc, leave libstdc++ as the default > system STL, but encourage ports to start depending explicitly on > ports-libstdc++ so that they don't suffer from ABI mismatch issues. > > If your workflow depends on gcc on a clang-is-cc platform, then you are > free to install it. > If your workflow depends on libstdc++ on a clang-is-cc platform, then you > are free to install it, clang will still use it if you specify > -stdlib=libstdc++. > If your workflow depends on gcc or libstdc++ on any other platform, you > will see no difference. > If you need to test whether building the base system or kernel with gcc > fixes things that are broken, then you are free to build > WITHOUT_CLANG_IS_CC and WITH_GCC and test it (or set WITH_GCC, install, and > then use XCC to use the installed gcc for testing. Or install one of the > lang/gcc ports and use XCC for testing). In the medium term, this should > continue to work until there is some compelling reason for it to be broken > (which is the topic of a future discussion, where I would expect very > compelling reasons to be required). > > I am not proposing: > > - To delete gcc from the tree > > - To delete libstdc++ from the tree > > - To deprecate any architectures > > - To break any architectures > > - To commit loads of C++11 / C11 code to the base system and break the > build with gcc > > - To rely on any clang-specific extensions in base-system code > > - To remove anything from cdefs.h that allows stuff to work with gcc > > - To set fire to your cat > > David > > To be able to compile a source tree with different compilers is an important "Code Review Process" with the assumption that the source code is written exactly to adhere a standard and not using any extension of the used compilers ( if there are absolute necessity to use extensions such as "date" , "time" , etc . , these are collected into common routines ) . It is obvious that no any "human" expert can review a source tree like a "compiler" expert . A compiler may be considered an "expert" because expertise of programmers are transferred into it as much as possible . For this process , it is not important which compiler is selected for "production" release . This depends on goals of releases . For development and testing , many compilers may be used and their outputs may be compared . I am doing this for Fortran and Pascal . With respect to my experiences , to rely on a single compiler for any source tree is really a very UNRELIABLE programming practice . Sometimes , some compilers are producing very erroneous code . These cases are requiring special attention : By using also theoretical programming "human" expertise , these may be results of the following : Some parts of the source are not conforming to standards . There are some bugs which they are not recognized by other compilers . Messages during compilations are not sufficiently produced to inform about possible erroneous points . Some compilers are generating code which is not tracking run time exceptions . Some compilers at some special source statement combinations are producing erroneous code . Using different compilers are detecting such problems much easier than human programmers . Now , I am not able to think to write a program without using different compilers to test its outputs . By based on such experiences , my strong suggestion is that "Use as many compilers as possible ( even commercially available compilers if there exist some ) for the FreeBSD source tree after selecting a standard during development and testing ." This is the cheapest and most reliable "Code Review Process" . "Use a suitable compiler for the FreeBSD Project during releases ." 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
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
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
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: PathDB (non GPL/GNU debugger) ported to FreeBSD !
2011/5/18 Pedro F. Giffuni > Hello... > > I caught this email on another list but it's directly > relevant to to us and as I've seen so many complaints > about the (lame) state of our GNU debugger, I am sure > there is sufficient interest. > > Please test and submit feedback to cbergstrom@ as > requested in his email. > > (FWIW, I suggested that Dtrace support would be > awesome). > > From: Christopher Bergström > > PathDB (debugger) has been ported to FreeBSD. > > Summary: x86/x86_64 debugger with the goal to drop-in replace gdb. > We recently finished some heavy refactoring and now focusing on > improving performance, *robustness*, scalability (clusters/multicore > systems), DWARF4, OS portability and supported targets. PathDB has a > library based design with a cli interface doing direct function calls. > Using C-bindings it should be fairly trivial to extend or add a new > front-end in python or other scripting language. > > Source > git clone git://github.com/path64/debugger.git > > Current status (heavy development - expect bugs) > GDB test suite results as of today (A lot of timeouts and at > a glance it seems like a lot of trivial CLI stuff) > FAIL: 747 > PASS: 477 > > Log : https://gist.github.com/b44f708cc2242091bc20 > --- > Man page - http://www.pathscale.com/docs/pathdb.html > User guide (Needs to be updated) - > http://www.pathscale.com/docs/PathDB_UserGuide.pdf > > We'd love feedback and more testers. > > Bug reports can be sent to me (cbergstrom) directly or > feel free to say hi on irc > > #pathscale - irc.freenode.net > > ___ > > Source GIT link is the following : https://github.com/path64/debugger The given link above is giving 404 error . 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"
