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

[Ralf Corsepius]

On 03/07/2012 08:45 AM, Thomas Doerfler wrote:
> Ralf,
>
> Am 06.03.2012 09:39, schrieb Ralf Corsepius:
>>
>> 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.
>
> If these hidden problems have not been detected in the last months,
> going on with two parallel toolchain flavours will neither reveal nor
> fix them. So forcing a flavour change may seem a harsh step but will
> force all ARM users to use EABI and therefore detect/report problems.

Well, in RTEMS history there have been several situations, where staying 
with officially discontinued ABIs/features was the only option for some 
reasons

For instance,
* users could be using third party closed source libraries, which would 
be ABI incompatible to the "new ABI" and therefore prevent them from 
switching to a different ABI.

* an ABI change may introduce others side-effects which may render using 
a new ABI impossible in some cases. E.g. the coff->elf change many years 
ago had introduced increases in application sizes which rendered using 
elf-RTEMS impossible on certain boards and had forced people to stay 
with coff.

>> 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.
>
> I don't get your conclusion to "remove" _untested_ parts. If they are
> _unused_, they should be removed. If they are in use and are broken with
> EABI, they should be fixed.

My intention is to utilize this ABI change as an opportunity to separate 
dead code from code really being in use (esp. dead BSPs).

> It's the difference of preserving code (and keeping it alive as along as
> possible without touching it) or adapting it to evolving standards.
Well, that's a general problem with RTEMS. At some point, keeping dead 
code starts to backfire and only serves the purpose of keeping people 
busy with keeping code compilable, until years later somebody realizes 
something had not been in use for long times.

Ralf