Re: [MiNT] Some comments on gcc 4.3.2

[Vincent Rivière <vincent.riviere@freesbee.fr>]

> 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 !

> 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.

> If anybody interested, I can public the binaries somewhere.

You should publish your work on some website !
I will put a link on my one.

Anyway, congratulations for this native build !
I think you are the first to have compiled and run GCC 4.3.X natively :-)

--
Vincent Rivière