[PATCH][SH] Multilib selection rework

Andrew Stubbs ams@codesourcery.com
Mon Apr 6 16:35:00 GMT 2009


On 04/04/09 02:40, Ian Lance Taylor wrote:
> Andrew Stubbs<ams@codesourcery.com>  writes:
>
>> This patch adds two new features:
>>
>>    --with-multilib-list=none
>>    The effect is that you get the default cpu in both endians.
>
> That doesn't really make sense to me.  If I typed
> --with-multilib-list=none, I would expect something akin to
> --disable-multilib.  I *think* this means something that might be better
> named --with-extra-multilibs.  Either way this should be documented in
> the installation instructions.

The name "--with-multilib-list" is already in the configure script and, 
no doubt, already in use, so I don't want to change that. I just want to 
add a missing feature.

The attached patch retains the new interface I created, but adds a new 
possibility: --without-multilib-list. This achieves the same thing, but 
hopefully in a more meaningful way?

The problem is that I don't know of a (non-bash) way for the config.gcc 
script to tell the difference between a variable that is undefined, and 
a variable that is set empty. It is important to retain the old 
behaviour when the option is not given.

This patch adds documentation for --with-multilib-list and --with-endian 
to the gccinstall manual.

>> 	* configure.ac: Add new AC_SUBST for TM_ENDIAN_CONFIG,
>> 	TM_MULTILIB_CONFIG and TM_MULTILIB_EXCEPTIONS_CONFIG.
>
> These are generic names but they are only implemented for SH.  I think I
> would like to see names including SH, or I would like to see some
> documentation somewhere on what these are supposed to mean.  It need
> only be some comments in config.gcc or configure.ac.

I did not use SH-specific names because there did not seem to be 
anything SH-specific about them. There's no reason why another target 
might not want to do the same thing, at some point in the future, and 
there seems to be no point in have a proliferation of target specific names.

I've added descriptions of these variables to config.gcc. I felt that 
configure.ac was not the right place to do it since hypothetical 
different targets might use different conventions for the content.

I believe I've also addressed Paolo's issues with bashisms.

OK?

Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc-multilibs.patch
Type: text/x-diff
Size: 20465 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20090406/c057ebe3/attachment.bin>


More information about the Gcc-patches mailing list