Deprecating config-ml.in multilib selection options

Deprecating config-ml.in multilib selection options

[Joseph S. Myers]

The toplevel config-ml.in configure fragment has some code for a few 
targets that allows modifying the set of multilibs built, based on 
configure options, to be different from that given by $CC -print-multi-lib.
The options in question are described in GCC's install.texi (but the 
lists there may not be accurate):

  Some targets provide finer-grained control over which multilibs are built
  (e.g., @option{--disable-softfloat}):
  @table @code
  @item arm-*-*
  fpu, 26bit, underscore, interwork, biendian, nofmult.

  @item m68*-*-*
  softfloat, m68881, m68000, m68020.

  @item mips*-*-*
  single-float, biendian, softfloat.

  @item powerpc*-*-*, rs6000*-*-*
  aix64, pthread, softfloat, powercpu, powerpccpu, powerpcos, biendian,
  sysv, aix.

  @end table

(The option handling for arc-*-elf* is to be removed for GCC 4.7 as part 
of the ARC target removal.)

I'd like to deprecate these options - or more specifically, their 
implementations in config-ml.in.  I don't think this script is a sensible 
place to hardcode multilib selections for a few particular targets, and I 
think the preferred way of doing such configuration is by options that 
actually take effect on GCC when it is configured so that -print-multi-lib 
gives the desired set of multilibs.  The options could in principle be 
used when building target libraries other than GCC's (in particular, 
newlib), but if you want to build a set of newlib multilibs different from 
GCC multilibs I still don't think such target-specific config-ml.in 
options are the right way to do it (though a generic system to specify 
multilibs to build / add / remove might be).

Comments?  What I am proposing is a release-notes-only deprecation - that 
is, state in gcc-4.6/changes.html that these options are deprecated, 
without any change to the code, with a view to removing them later in the 
GCC 4.7 development cycle (to give time for maintainers to reimplement any 
options they still want, in config.gcc or elsewhere in the gcc/ directory) 
rather than immediately.  If we can't deprecate all of them, deprecating 
some would still be good.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Deprecating config-ml.in multilib selection options

[Richard Earnshaw]

On Mon, 2011-03-21 at 14:36 +0000, Joseph S. Myers wrote:
>   Some targets provide finer-grained control over which multilibs are
> built
>   (e.g., @option{--disable-softfloat}):
>   @table @code
>   @item arm-*-*
>   fpu, 26bit, underscore, interwork, biendian, nofmult.

I'd expect that code to be very bit-rotten for ARM.  The evidence of
this is that 26-bit mode hasn't been supported by gcc for about 5 years
now, but nobody has cleaned up this bit of code...

R.

Re: Deprecating config-ml.in multilib selection options

[Andreas Schwab]

Richard Earnshaw <rearnsha@arm.com> writes:

> On Mon, 2011-03-21 at 14:36 +0000, Joseph S. Myers wrote:
>>   Some targets provide finer-grained control over which multilibs are
>> built
>>   (e.g., @option{--disable-softfloat}):
>>   @table @code
>>   @item arm-*-*
>>   fpu, 26bit, underscore, interwork, biendian, nofmult.
>
> I'd expect that code to be very bit-rotten for ARM.  The evidence of
> this is that 26-bit mode hasn't been supported by gcc for about 5 years
> now, but nobody has cleaned up this bit of code...

Probably because that part just turned into a no-op without creating any
problems.

Andreas.

-- 
Andreas Schwab, schwab@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."

Re: Deprecating config-ml.in multilib selection options

[Richard Sandiford]

"Joseph S. Myers" <joseph@codesourcery.com> writes:
>   @item mips*-*-*
>   single-float, biendian, softfloat.

FWIW, I've no objection from a MIPS point of view.  Like Richard was
saying for ARM, single-float has long since stopped working for MIPS,
because no target has single-float multilibs.

Richard