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