Re: Gnutools: consideration for upgrade to GCC 4.6

[Ilija Kocho <ilijak@siva.com.mk>]

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