Mips-rtems build of GCC 3.4.1 has changed mips3!

[Ralf Corsepius]

On Fri, 2004-08-13 at 07:47, Bruce Robinson wrote:
> Hello Joel and Greg,
> 
> I've been working on the RTEMS BSP for the Toshiba TX4925 and have run into
> some new issues. First I discovered GCC 3.2.3 doesn't generate proper code
> for the va_start function when using -mips3. So as a work around I tried to
> move to GCC 3.4.1. In that version of GCC the va_start function works, but I
> discovered that both -mips1 and -mips3 options now produce code that assumes
> all registers are 32 bits. In previous versions -mips3 produced code that
> assumed 64 bit registers. If you want to build RTEMS so that the MIPS
> processor uses 64 bit register, GCC and newlib will have to be built with
> the -mgp64, -mfp64, and -mabi=o64 options.
> 
> For my applications, having GCC defaulting to 32 bit registers for mips3 is
> preferred. Maybe GCC and RTEMS can add support for a "mips64-rtems" target
> that assumes 64 bit registers. In that case, the code in RTEMS that must
> change for 64 bit registers will test for the __mips64 flag.
> 
> Does this sound reasonable, or do you foresee changing GCC back to its'
> previous implementation of mips3?
Let me put it this way: The issues you are facing are well known ("mips3
support in RTEMS is plain broken" ;) ). Joel and me had discussed this
issue several times, but could not make up our minds to decide on
whether to support a mips64-rtems target, because there doesn't seem be
any active user using RTEMS on a mips64/mips3 target.

I for one would prefer to see a mips64 multilib variant instead of a
separate mips64-rtems target, because this would be much easier to
maintain than "another toolchain" and another target in rtems.
However, AFAIK, the mips-gcc developers have decided to separate mips32
from mips64 targets and not to keep them merged, so implementing a
mips64-toolchain might have become inevitable.

Ralf