This is the mail archive of the
mailing list for the GCC project.
Re: Add Android related compilation options and multilib options
On Tue, 16 Jun 2009, Chris Lattner wrote:
> > powerpc-linux is a good case in point of having too many triplets, with
> > variants such as powerpc64-*-linux*, powerpc-*-linux*spe*,
> > powerpc-*-linux*paired*, powerpc*-*-linux*altivec* that should just be
> > variants on the default options and multilibs for one target triplet.
> Why is "more targets bad"? Life seems simple if you have one set of libraries
> for each target triple, so you have a "many target triples to one set of
> libraries" mapping. This implies that the major ABI differences get different
> triples though.
If life seems simple you clearly haven't tried working at and beyond the
limits of what GCC's multilib configuration supports, with large numbers
of libraries and complicated mappings from the command line options used
to which runtime libraries to link with. There are options where you
don't have the one set of libraries per multilib either; consider how
ARM's linker can select objects based on build attributes rather than
based on options passed to the compiler, or the interest from S/390 people
in having separate hard-DFP versions of libgcc but not of libc, or the
STT_GNU_IFUNC approach to optimized functions. Configuration with large
numbers of libraries is essentially complicated and you should understand
the existing systems first before proclaiming (cf. Rob Landley's blog)
that some massively simpler system can solve all the problems in this
area; such claims suggest that only a much narrower range of
configurations has actually been thought about.
When you have multiple triplets for essentially the same configuration,
every case statement in configuration, and every testcase, that wishes to
test for the configuration, needs to match all the variants, and
everything that should be in common between the configurations needs to be
kept in sync - and in practice those powerpc*-linux* targets have got out
of sync in the past, and testcases have not been properly conditioned to
run for the correct targets and only the correct targets, and fixing up
incorrect testsuite presumptions in this area was a pain. There isn't
even a meaningful distinction between powerpc64-linux and powerpc-linux
given that the former is usually built to default to 32-bit with
--with-cpu=default32. If you want a compiler that supports both 64-bit
and SPE multilibs, having them in different targets is no good. The
benefits to maintainability of reducing the proliferation of triplets are
And there is an essentially infinite number of possible configurations
determined by particular options one might want to enable by default;
converting sets of options into the syntax of target triplets would lead
to a lot of very long and obscure triplets; configure options such as
--with-cpu work a lot better and there's no good reason for "default -m64"
to be handled differently with its own triplet. Target triplets are not
meant to encapsulate everything possible about how you might choose to
configure GCC; there's a reason there are lots of other configure options
and options that can be used when running GCC.
It has been very clear in the process of cleaning up support for unused
and obsolete targets that a proliferation of "canonical" target names
(names that are distinct after being passed through config.sub) is a bad
idea. Noncanonical aliases that imply different configuration choices are
rather less problematic.
Joseph S. Myers