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