Fwd: GCC 4.7.0 Release Candidate available from gcc.gnu.org

[Ralf Corsepius]

On 03/06/2012 07:55 AM, Sebastian Huber wrote:
> On 03/05/2012 07:00 PM, Ralf Corsepius wrote:
>> On 03/05/2012 05:11 PM, Sebastian Huber wrote:
>>> On 03/05/2012 04:39 PM, Ralf Corsepius wrote:
>>>> On 03/05/2012 12:14 PM, Sebastian Huber wrote:
>>>>> On 03/05/2012 12:03 PM, Ralf Corsepius wrote:
>>>>>> arm-rtems* fails with this:
>>>>>> ...
>>>>>> *** Configuration arm-unknown-rtems4.11 is obsolete.
>>>>>> *** Specify --enable-obsolete to build it anyway.
>>>>>> *** Support will be REMOVED in the next major release of GCC,
>>>>>> *** unless a maintainer comes forward.
>>>>>> ...
>>>>>>
>>>>>> ... I am speechless about this jerkery :(
>>>>>
>>>>> This configuration is in fact obsolete. Anyone using it should
>>>>> switch to
>>>>> the EABI configuration as soon as possible.
>>>>
>>>> Keyword: _should_ ... compare this to your "short enums" issues.
>>>
>>> Everything has two sides.
>>>
>>>>
>>>> I read this as "wishful thinking outrules reason and practice".
>>>
>>> You should read this as "it is past time to abandon an obsolete and
>>> unmaintained configuration". The EABI for ARM is available in GCC since
>>> 2004.
>>
>> AFAICT, GCC's EABI had been ignored by many people, because it was in
>> poor
>> shape for a long time and the only usable EABI compilers had been
>> commercial.
>
> I don't know the history, but the current situation is that the non-EABI
> configuration is dead.

Yes, because the GCC-deities say so and because they don't care otherwise.

>>> http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00692.html
>>
>> If we adhere to GCC's decision, we need to remove the arm-rtems4.11
>> toolchains
>> and the arm target from RTEMS-4.11 right on the spot.
>
> I would have simply changed arm-rtems4.11 to use the EABI configuration,
> but it was decided otherwise and now we have two ARM tool chains.

Not quite.

We decided to continue to support arm-rtems as non-EABI to allow users a 
gradual transision to eabi, because RTEMS did not support EABI and 
because RTEMS did not have any expericences with EABI.

This step allowed the RTEMS users to compare non-EABI with EABI and to 
gradually adapt RTEMS to EABI. This step had been useful, because 
incompatiblities between EABI and RTEMS arm support had been found.


Now, GCC has decided to kill "arm*-*-*" and to mandate "arm*-*-*eabi*".
I.e. if we had not chosen to use 'arm*-*-*eabi*", arm-rtems now would be 
confronted with a sudden death and nobody would be able to compare 
non-eabi vs. eabi.

Anyway, that said, I would not be surprized  if some parts of RTEMS 
(esp. BSPs) still carry implict dependencies on non-eabi and have never 
ever seen any real world testing with EABI.

In other words, in case we can not avoid to abandon non-EABI arm, we 
need to identify these eabi un-tested parts in RTEMS and to remove them 
from rtems-4.11. My guess would be this is half of the arm BSPs.

Ralf