This is about c-compiler gcc. Discussion have started on other threads off-topic, it might be better to have one dedicated.

Release dates:
GCC 4.2.1 release (2007-06-18)
GCC 4.2.4 release (2008-05-19)
GCC 4.4.6 release (2011-04-16)
GCC 4.6.2 release (2011-08-26)

Maemo5 has gcc-4.2.1. We have already encountered programs, which need newer compiler. And there are some bug fixed on ARM-version of gcc-4.4 (atomic types are in 4.2 but actually not working on ARM until 4.4). Third reason is 4.6 has and will have more optimization on ARM (by e.g. Linaro, http://www.linaro.org)

Some developers are already using Tom Tanner's gcc-4.4 (
http://n900.tannerlab.com/pool/free/g/gcc-4.4/ ), but it is not in extras (-devel).

--
I have started to push new compiler to the extras-devel. There are needed libraries and newer tools (e.g. bison-2.4 and make-3.81) on repository (and autobuilder can use them). Seems to me that 4.2 can compile 4.6, so we can skip 4.4.

Some random thoughts:
*On i386-target multilib should not be used.
*Virtualized/emulated environments lacks RAM/SWAP, so -j1 might be the only way (I think issue is generated insn-attrtab.c)
*It might be must to use --disable-bootstrap (bootstrap="compiler test can it compile itself during process" (seems to be memory issue))
*I had some problems to not compile java

---
When program is compiled with newer gcc, it needs also newer libstdc++ (Is this true with only c++ applications?) .Do old programs work with new libstdc++ or should there be both then installed on device? (until we can recompile every program)
---
Should this be packages gcc-4.6 (building) and libstdc++6-4.6 (runtime)? Or could this overwrite gcc and libstdc++6?
---
This is Work In Progress, join discussion if you have something to contribute.

----------------
Edit:
Reason's for newer compiler:
*There are more and more applications which can't be built with old compiler, due bugs in old compiler or new features on new compiler. This is proven to be true. (But we can still claim that those new applications are not needed, or we can port them to use old compiler)
*Possible better optimization: E.g. Linaro is making gcc 'better' for ARM speaking code size and execution speed. It is not (yet) proved that this happens on N900.
*THUMB2
http://www.cnx-software.com/2011/04/...e-performance/
(I have not seen tests for N900)
*NEON (whatever this means...)

Can it be assumed that...
- there are a number of bug fixes i.e. code compiled with 4.6 is more likely to behave as expected compared with code compiled with 4.2?
- there are some optimisations so code compiled with 4.6 should run faster than that compiled with 4.2?

These might seem unnecessary questions but I'd be interested to have clear answers all the same:
- can maemo make full use of software compiled with gcc/g++ 4.6?
- are additional/alternative libraries needed to run software compiled with 4.6 compared with 4.2? (seen note re: libc - anything else?)
- what happens when linking in other, existing libraries, frameworks or dependencies?
- if multiple library versions are required, will they fit on the device?

I have scratchbox (armel target) with gcc 4.6.2 and latest binuils which I used for compiling thumb2 binaries (Qt, gtk, ...). Newer libstdc++ should be copied to n900, but it seems there are no problems caused by that.

EDIT:

I compiled gcc and binutils outside scratchbox (statically linked) and setup a new target using /scratchbox/compilers/(gcc462_dir)

And so far the only new library needed is libstdc++

Any chances for CSSU interest in this? I may be wrong, but it seems like perfect candidate for CSSU, even more than any Qt thing.

/Estel

i have a new libstdc++ from debian repo
and it's working fine
i need it for launching online game servers

but do we need to compile a new one ?

gcc is only a compiler, so whether you use 4.2 or 4.6 should be irrelevant for the program you're compiling, so it will work equally good or bad

The only issue is with libraries that are internal to gcc (such as libstdc++).

The problem would be if you now wanted to upgrade to a newer glibc, but that's another story...

Incorrect, gcc 4.2.1 for ARM has bugs which are resolved in newer versions. Look at the case with CSSU, Qt 4.7.4 and raster engine - it ended that it is -O3 flag that breaks it. And newer gcc and binutils have workarounds for ARM erratas, better vectoriser (for NEON), produce more optimized code, etc...

So far never had problems with programs compiled with Tanner's 4.4 (also no reports of programs failing due to libstdc++ incompatibility, but sample size is unreliable at best). It does seem that bugs from 4.2 are quite common and workarounds for those are non-trivial (in some cases -Ox does impact succesfull compilation still).

@Estel: unlikely this would get full attention from CSSU team, as binutils (and rest of compilation packages) is not part of standard system setup. Currently it is even required to add 'risky' SDK repos to get 4.2 running.

Still, what I wrote is strictly correct. A compiler is only a compiler

If a new version of a compiler provides better optimization, etc. then a new recompilation of a program will perhaps work faster, but not differently. If a new version of a compiler generates code that is *not* compatible with other programs compiled with other versions of the compiler or even with other compilers (who says everything has to be gcc?), then something's fckd up with the compiler.

Obviously, I know you're talking about thumb2 and neon. But these are just optimization options which should work regardless of the underlying system (as long as the processor supports those instruction sets).

Using aggresive optimization options is something that has to be done VERY carefully. Of course a compiler should alwayws produce correct code, but in the real world this is not the case.

I think -O3 enables the -fstrict-aliasing option (or at least it used to do that), and enabling that option implies that *you* (developer) make *damn* sure that your program is OK with that.

I can bet a year's a salary (OK, make it a month) that the combination of CSSU, QT 4.7.4 and whatever raster engine you were compiler DOES NOT fulfill that (very strict) restriction, meaning that using strict aliasing is an unsafe option.

Wait, why should we use -O3 by default? Many if not all distros frown upon this, as the extra flags break some programs (explained on the Gentoo wiki iirc).

Anyways, GCC 4.6 is a stable release, by all means yes, we should push for this and packages to be recompiled with this (plus NEON, afaik THUMB is broken on the N900's SoC, and the workaround's overhead > benefit of THUMB)

While we're on the subject, why not upgrade other open components from upstream?