This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: 4.7 deprecated targets removal patch
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:
> >
> > > > @@ -744,7 +744,6 @@ case "${target}" in
> > > > libgloss_dir=cris
> > > > ;;
> > > > crx-*-*)
> > > > - noconfigdirs="$noconfigdirs target-libstdc++-v3 target-mudflap ${libgcj}"
> > > > ;;
> > >
> > > 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.
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?
> > - 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 *-*-*.
> > (There are also lots of cases for "canonical
> > aliases" that have been deprecated and removed from GCC - that is, names
> > that should be aliases but that config.sub treats as canonical and so
> > cause problems because of needing duplication in case statements etc.
> > everywhere. In those cases it probably makes sense to remove support for
> > the duplicate names in src, along maybe with making config.sub convert
> > them to canonical form. i?86-*-pe as an alias for Cygwin is an example in
> > the present patch; various such aliases were obsoleted in 4.3 as well, but
> > support for "thumb-*" targets was obsolete long before the other ARM
> > aliases obsoleted in 4.3.)
>
> That's yet another task that might be a good idea to do (by somebody who
> knows this in and out), but config.sub changes have the potential to
> break or at least require adjustment in lots of other software. Many
> packages look at those aliases, be that in their configury, or through
> Libtool or gnulib or other third-party macros. I can't judge this well
> without seeing a list of affected aliases (and even then it might be
> hard).
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.
--
Joseph S. Myers
joseph@codesourcery.com