Add little/big endian multilib variants to mips*-rtems*
Joel Sherrill
joel.sherrill@oarcorp.com
Fri Jun 9 13:48:00 GMT 2006
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
>
>
More information about the Gcc-patches
mailing list