Re: [MiNT] Some comments on gcc 4.3.2

[Alan Hourihane <alanh@fairlite.co.uk>]

On Sat, 2008-10-04 at 23:23 +0200, Vincent Rivière wrote:
> > Hi everybody,
> 
> Hello, MiKRO !
> 
> > today I played with the newest gcc 4.3.2 with the aim to compile native 
> > m68kmint binary.
> 
> That means you built a native gcc 4.3.2 ?
> Wow, I've always wondered if it was possible !
> 
> > - for some strange reason I had to #define HAVE_GNU_LD to 0 in files 
> > gcc/gcc.c and gcc/collect2.c. When I compiled cross compiler, it was OK, 
> > it only appears when I compile native gcc using that cross compiler... 
> > When I used #ifdef HAVE_GNU_LD if it exists, it does!
> 
> Hummm... what was wrong ?
> 
> > - there's no need to use libm (libpml) anymore -- libmpfr takes care 
> > about every math operation. you even don't need libm anymore when 
> > compiling your binaries! (I used simple printf("%f", sin(M_PI)) using 
> > the cross compiler and the resulting binary compiled & executed in 
> > aranym with no problem)
> 
> Hehe... You have been fooled by the optimizer ;-)
> sin(M_PI) is a constant, so gcc computed the value at compile time 
> (using libmpfr, I suppose), so there is no call to sin() remaining in 
> the final executable, so libm.a is not required.
> 
> However, if you call sin() with a global variable for example, the call 
> to sin() will be generated, and a link with -lm will be required, as 
> usual. libm.a is still required for runtime maths.
> 
> Note that I originally used PML in my GCC port, because I didn't know 
> fdlibm :-( Of course, PML should be dropped, and fdlibm be used instead, 
> like in GCC 2.95. As an alternative, we may use the libm provided by 
> Newlib: it is derived from fdlibm, it works and it is still maintained. 
> Olivier Landemarre made tests with a FreeBSD libm, too.
> 
> > - t-mint file it seems is obsolete -- gcc now looks for multilib output 
> > of host compiler, so if m68k-atari-mint-gcc cross compiler was compiled 
> > with m68020-60 and m68060 support, no matter what I write into t-mint 
> > file, libgcc, libstdc++ etc are always in m68020-60 and m68060 versions, too
> 
> Nice. But I guess it will always be mandatory for a cross-compiler...
> 
> > - performance: I measured quake compilation on real CT60@70 MHz machine 
> > with -O3 -m68020-60:
> > 
> > gcc 2.95 (68000 version): 7:30 minutes
> > gcc 4.2.3 (68000 version): 21 minutes
> > gcc 4.3.2 (68000 version): 23:40 minutes
> > gcc 4.3.2 (68020-60 version): 22:20 minutes
> 
> Longer compilation times is a known problem of GCC 4.
> It is the same on other platforms.
> 
> > quake reported similar problem as with gcc 4.2.x some months ago
> 
> I really would be interested in a quick benchmark of Quake compiled with 
> GCC 2.95 and 4.3.2. However, the critical routines of Quake are written 
> in assembly, so a compiler change may not show significant performance 
> change...
> 
> Beware: I usually noticed *slower* performance with -O3 than with -O2... 
> Make your own tests !

Me too. Remember -O3 is turning on a lot of optimization paths which GCC
2.x may not have even supported.

> > All at all -- my feelings are quite mixed, 3 times slower compilation, I 
> > don't know if this is what I wants to see as default freemint 
> > compiler... and that generated code doesn't seems to be much faster anyway.
> 
> Having the latest GCC available on MiNT is cool. That means we can use 
> the latest C/C++ features on our favorite platform.
> However, making the latest GCC 4.X the *default* compiler for MiNT is 
> another story... I'm not sure if there is any benefit to do so.

I think some newer packages are requiring later versions of GCC than
2.x, now so it makes sense to have 4.x as the default so people don't
bump into issues with older 2.x compilation issues.

Alan.