GCC Version Questions

[Thomas Doerfler]

Hi,

Am 28.04.2012 05:57, schrieb Ralf Corsepius:
> On 04/27/2012 04:00 PM, Sebastian Huber wrote:
>> I would rather use GCC 4.6.X for the RTEMS 4.11 release on ARM since I
>> had a lot of trouble with earlier version of GCC 4.6. I worked with GCC
>> 4.6 during the whole 4.11 development cycle and I am really at unease to
>> use an untested GCC 4.7 for this release.
> 
> Sebastian,
> 
> a) rtems4.11 is the unstable, rolling development branch, which may eat
> the hair of your head and may eat your family and children.
> It's _you_ (The developers) who are testing and are supposed to find,
> report and occasionally fix the bugs.

Sebastian, maybe it makes sense to give gcc-4.7 a try. we have not yet
branched off towards a 4.11 release, so Ralfs view seems reasonable to me.
> 
> Devs are working on trunk, introducing "new stuff", breaking APIs and
> ABIs ad-lib, but do not care about RTEMS-4.10. It's unfortunate and sad,
> but it's the natural way.

Surely trunk is the main line we developers think off. Anyway, relevant
bug fixes are regularly ported back the the previous version(s) in
RTEMS. This may even be intensified with the availability of extra
manpower or funding ;-)
> 
>> So progress breaks older versions sometimes.
> 
> Sure. ... this is an inevitable consequense, which generally applies
> everywhere.

Here I need some clarification, how can "progress (break) older versions
sometimes"?

In general, a given release (e.g. RTEMS4.10) should be functional and
should not _break_ during its lifetime (but it may contain unfixed
bugs). The RTEMS4.10 code basis is only touched rarely and these changes
are (should) be made very carefully.

Another reason to "break" an existing RTEMS release is a toolset change.
So I guess it would make sense to _not_ upgrade a toolset for a RTEMS
release unless it is carefully tested afterwards!!!

The consequence is, that a new toolset needs functional testing before
it is qualified to support a certain RTEMS release.

My ignorant questions concernign RELEASE toolsets:
- how is this done up to now=
- who is doing the testing?
- how should we do this in the future? IMHO We should define a
qualification process!

>> In general we should consider to select a certain GCC version for an
>> upcoming RTEMS release and stick with this GCC version for this RTEMS
>> release. Thus we continuously work with a particular GCC release during
>> development and can address all compiler issues in this phase.
When do we have to select the GCC release? I would guess the branching
point should define a possible GCC (and binutlis) version freeze.
> 
> Well, this is naive wishful dreamery.
> 
> C.f. the arm situation:
> - People want arm-eabi
>   ... arm-eabi in 4.6 was "imature".
> - People want support for arm-architecture-variant xyz,
>   ... xyz did not exist in 4.6.
> - People want to exploit GCC/language-feature "abc",
>   ... feature "abc" did not exist in gcc-4.6.
> ...

These decisions should IMHO be discussed on the development list,
because they have many aspects.
> 
> To sum up, IMO,
> - it is impossible to "freeze" on one GCC version, instead, we cannot
> avoid to find individual compromises per target/architecture for
> production releases.

For production releases, a freeze seems vital for me, unless we have an
easy to use, automated qualification process.

wkr,

Thomas.

-- 
--------------------------------------------
Embedded Brains GmbH
Thomas Doerfler           Obere Lagerstr. 30
D-82178 Puchheim          Germany
email: Thomas.Doerfler at embedded-brains.de
Phone: +49-89-18908079-2
Fax:   +49-89-18908079-9