4.7 deprecated targets removal patch

[Ralf Wildenhues]

* Joseph S. Myers wrote on Fri, Mar 18, 2011 at 10:09:04PM CET:
> On Fri, 18 Mar 2011, Ralf Wildenhues wrote:
> > * Joseph S. Myers wrote on Fri, Mar 18, 2011 at 08:46:56PM CET:
> > > On Fri, 18 Mar 2011, Ralf Wildenhues wrote:
> > > > Why not also remove the line before and after this one?
> > > > Is that because crx is still supported in binutils or other
> > > > src projects?  If yes, the hunk is fine, but then I wonder
> > > > whether it is too early to drop the config-ml.in bits for src.
> > > 
> > > Yes, it is still supported in binutils
> > 
> > Then config-ml.in should not be changed yet, IIUC.
> 
> config-ml.in should have nothing to do with binutils here, since binutils 
> does not build target libraries.  The only potentially relevant target 
> code in the src tree would be newlib/libgloss - and I see no sign of an 
> arc port there.  So I believe the arc code in config-ml.in was only used 
> for building GCC's own target libraries, and so can safely be removed.

OK then.

> Actually I'd rather like to deprecate the entire set of configure options 
> that control multilib building in config-ml.in, on the basis that the 
> correct way to configure this is through options processed in config.gcc 
> that end up controlling the MULTILIB_* variables, like SH's multilib 
> configure options (and that if target maintainers actually care about 
> these obscure configure options, they should reimplement them in 
> config.gcc).  If we were to deprecate all those options in GCC, what would 
> you then think is required to be able to remove them from config-ml.in, 
> given the possibility of newlib using these options?

A quick look at other projects that use config-ml.in would be prudent.
I glanced at codesearch, there doesn't seem to be a problem outside GCC
IMVHO.  So yes, such a cleanup would seem good.

> > > - and the general reason for not 
> > > removing the empty cases is that there are plenty of such cases already 
> > > there, some for truly ancient targets.
> > 
> > I can understand keeping them when there are later case matches that
> > might match the pattern in question.  That doesn't apply to crx-*-*
> > however.
> 
> Well, it would match the *-*-* case (which is fairly harmless).  But just 
> the same would seem to apply to the i370-*-opened* case, for example - I 
> don't see anything else that would match other than *-*-*.

i370-ibm-opened* would.  I have no idea how relevant that is; it only
sets tentative_cc.

[...]
> The ones eliminated in GCC include at least:
> 
> strongarm*-*-*
> ep9312*-*-*
> xscale*-*-*
> (much longer ago) thumb-*-*
> parisc*-*-*
> m680[012]0-*-*
> i?86-*-pe
> 
> All of these appear in the toplevel configure.ac.  Of these, the only one 
> config.guess might sometimes produce is m680[012]0-*-*, so the others can 
> only ever appear as targets in cross-compilation.

Except for the PE one, all of these are only about CPU type aliases.
At least the gnulib and Libtool configury rarely looks at those, and
their matching would seem limited outside of tool-related projects.
I'd say a quick codesearch would allow to improve here with some
confidence.

Thanks,
Ralf