[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[MiNT] Some comments on gcc 4.3.2

Hi everybody,

today I played with the newest gcc 4.3.2 with the aim to compile native m68kmint binary. It went quite OK (thanks to Vincent's work and work of gcc team), except the following:

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

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

- 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

- libgcc has really strange support for multilib -- it takes cflags from CFLAGS instead of LIBCFLAGS so there's no easy way how to compile native gcc with let's say -m68020-60 because I set CFLAGS as '-O2 -m68020-60' and that libgcc script takes -m68020-60 as default and then adds -m68060 to it. I'm not sure how this worked before but now it "converts" mentioned flags into "m68040-m68060" and fails. It can be faked by compiling everything with normal CFLAGS, installing, then make clean-gcc and then make CFLAGS='..' and again install (this will overwrite 68000 binaries with 68020-60 ones).

- 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

As you can see, there's deep difference between 2.x and 4.x range... even 68000 vs 68020 isn't anything important, all of them are damn slow... practically, on anything other than cross compiler I really wouldn't want to see my daily development under 4.x gcc...

About the functionality, I tried some simple stuff with success, however quake reported similar problem as with gcc 4.2.x some months ago -- I think it's another floor/ceil/round problem somewhere since new math lib (gcc's internal one) is used.

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.

If anybody interested, I can public the binaries somewhere.

MiKRO / Mystic Bytes