This is the mail archive of the ecos-devel@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Gnutools: consideration for upgrade to GCC 4.6


On 14.01.2012 11:22, John Dallaway wrote:
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?

If it could be some measure, the compilation of eCos library for the /default/ template (target K60N512) raises 11 warnings, all seem to be the same type:
warning: variable ‘<varname>’ set but not used [-Wunused-but-set-variable]
Some cases are unused variables indeed, but of some the usage is "hidden" (within asm() or macro).



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.

I have implemented them in my build (for ARM only). They seem to fit with the new code but regarding relevancy it probably requires more analysis and better knowledge of GCC intrinsics than mine.


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.

This is a good approach. During the "test period" we can fix the warnings, etc.


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.

This probably shall not be a (big) problem. GCC 4.6 (be it minor 0, 1 or 2) doesn't seem to require any changes other than elimination of warnings. From my experience, everything that works with GCC 4.3.2 also works with GCC 4.6. Of course some backward compatibility break is inevitable. The build options for new architectures are not supported by older versions (example -mcpu=cortex-m4). But that's why we're looking for the upgrade in the first place :) .


Ilija Kocho


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]