Re: Gnutools: consideration for upgrade to GCC 4.6

[John Dallaway <john at dallaway dot org dot uk>]

Hi Ilija and all

Ilija Kocho wrote:

> Our GCC 4.3.2 is ageing and perhaps we should consider an upgrade.
> My motive is it's lacking of support for Cortex-M4 SIMD (aka DSP) and
> FPU instructions, but I think that other architectures shall gain from
> newer compiler too. I have made some signal processing tests with GCC
> 4.6.2 against current eCos compiler and they show performance gain even
> with Cortex-M3 setting, though moderate. Performance is considerable
> when Cortex-M4 setting is selected and is tremendous, as expected, when
> SIMD are used. Recently introduced Cortex-M products with FPU (Kinetis
> K70, K61, STM32F4) will further emphasise the benefit.
> 
> Another reason, maybe not so important, is that GCC 4.3 is not
> officially supported any more.
> 
> Regarding this, I state my wish that we move to the latest stable GCC
> release, that is at present rel. 4.6.2, accompanied with respective
> binutils. I have tested binutils 2.21 but in meantime 2.22 has been
> released. Of course, the list wouldn't be complete without the latest GDB.

Moving to a more recent GCC makes sense to me.

There are sure to be some new compiler warnings to deal with in the eCos
sources. Are you aware of the scale of this issue with eCos CVS and GCC
4.6.2?

There are a few patches that were applied to current toolchain sources:

  ftp://ecos.sourceware.org/pub/ecos/gnutools/src/

It would be useful to review these and determine which are still
relevant. Certainly we would need to adjust the multi-libbing for some
target architectures.

It would also be useful to test eCos with the new toolchain in an
automated manner. I wonder if one of the maintainers at eCosCentric
could set up testing in their test farm? In any case, I would advocate a
cautious approach to roll out, creating an initial "test release" for
use mostly by those interested in the new features. We could also
consider building the toolchain for arm-eabi targets only in the first
instance to reduce overall effort. Does anyone on this list have a
particular interest in building eCos with recent GCC for another target
architecture?

It would be important to retain eCos source compatibility with the
current toolchains based on GCC 4.3.2.

John Dallaway
eCos maintainer
http://www.dallaway.org.uk/john