This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Add little/big endian multilib variants to mips*-rtems*

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.

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"?

Ralf
Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]