This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Add little/big endian multilib variants to mips*-rtems*
Ralf Corsepius <ralf.corsepius@rtems.org> writes:
> On Fri, 2006-06-09 at 14:46 -0500, Joel Sherrill wrote:
>> Richard Sandiford wrote:
>>
>> >Joel Sherrill <joel.sherrill@oarcorp.com> writes:
>> >
>> >
>> >>Does there need to be a special error catcher for mips*el-rtems so it
>> >>can't be configured?
>> >>
>> >>
>> >
>> >If it has to be mips-rtems (not mipsFOO-rtems), then I suggest
>> >just removing the first "*" from "mips*-rtems*".
>> >
>> >
>> >
>> We do build a mips64-rtems so that won't work. Close though.
Ah. Won't Ralf's patch break that target too? We use the same makefile
fragments for all mips*-rtems* targets, and Ralf's patch hard-coded them
to assume a default of -EB -mips1. The MULTILIB_EXCEPTIONS won't work
for a default of -mips3.
> Fixing this would be trivial:
>
> --- config.gcc (revision 114538)
> +++ config.gcc (working copy)
> @@ -1560,7 +1560,7 @@
> tm_defines="MIPS_ISA_DEFAULT=3 MIPS_ABI_DEFAULT=ABI_O64"
> use_fixproto=yes
> ;;
> -mips*-*-rtems*)
> +mips64-*-rtems | mips-*-rtems*)
> tm_file="elfos.h ${tm_file} mips/elf.h mips/rtems.h rtems.h"
> tmake_file="mips/t-elf t-rtems mips/t-rtems"
> ;;
>
>
> Some fundamental questions, I can't answer, however would remain:
> * Is such a mips64-*rtems* target useful at all?
> * Has mips64-rtems* (before having added le/be multilib variants) ever
> been useful.
> * Can "mips64" be implemented as multilib variant of "mips"?
I think it already is. In configury terms, "mips64*-*-*" is
just MIPS 3, and the current version of mips/t-rtems has -mips1,
-mips3 and -mips32 multilibs. It's just that mips-rtems defaults
to -mips1 while mips64-rtems defaults to -mips3.
Richard