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*

Richard Sandiford wrote:

Ralf Corsepius <ralf.corsepius@rtems.org> writes:


On Fri, 2006-06-09 at 10:18 +0100, Richard Sandiford wrote:


Ralf Corsepius <ralf.corsepius@rtems.org> writes:


It adds little/big endian multilib variants to mips*-rtems* targets.
This patch has been in use for the official RTEMS toolchains for a while
and should not have any influence on any other targets.
[...]
-MULTILIB_OPTIONS = mips1/mips3/mips32 msoft-float/msingle-float
-MULTILIB_DIRNAMES = mips1 mips3 mips32 soft-float single
-MULTILIB_MATCHES = msingle-float=m4650
+# default is mips1 EB hard-float


What about mips*el-rtems? Is that not a support configuration?


Depends on what you mean.

Little "endian mips" is supported, but a separate mips*el-rtems target
tuple is not supported.



I meant the latter.  It's just that, whether supported or not, I think
the configuration _is_ accepted.  The *el handling is done separately
in config.gcc, for all MIPS targets.

If you're happy with mips*el-rtems silently doing something strange,
the patch is OK.



Does there need to be a special error catcher for mips*el-rtems so it can't be configured?

--joel

Richard



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