This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Add Android related compilation options and multilib options

On Wed, 17 Jun 2009, Chris Lattner wrote:

> > 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.
> I'm also not familiar with Rob Landley's blog.

He makes various wide-ranging claims about most of the path searching 
logic in GCC being unnecessary.  It may not be needed in his environment, 
but all the different cases do have their own purpose (even if the results 
of adding features for successive use cases seem uglier than a design for 
all use cases produced at one go might).  Path searching and multilibs are 
heavily interwoven, and the same issues apply to both.

> Ah interesting.  I certainly wasn't considering how the GCC testsuite works
> and what its requirements are.  Basing the testsuite on the *input* triple to
> the compiler seems to have many complexities.

It (DejaGnu) uses the *canonical* triplets as output by config.sub, but 
the difficulties arise where config.sub's ideas of what should be 
distinguished are at variance with what is actually of use for GCC to 
distinguish.  And where config.sub distinguishes more than necessary, the 
multiple ways to get the same effect (i686-* versus i386-* 
--with-cpu=i686) cause trouble and confusion.  For a from-scratch design I 
would have eliminated many of these variants and replaced them by 
appropriate configure options, and the way to have a multi-target compiler 
whose targets have the same canonical triplet after such unification (e.g. 
Power SPE and 64-bit) would be to build different multilibs for that 
target rather than building them as different targets; the multi-target 
compiler should not need to use different target structures for them.  A 
compiler might naturally be configured to support

target i386-linux-gnu
  multilib -m32
  multilib -m64
target powerpc-linux-gnu
  multilib -m32
  multilib -m32 -mcpu=8540
  multilib -m64

and I think having two targets with multiple sets of libraries each is a 
better way of describing this than

target i386-linux-gnu
target x86_64-linux-gnu
target powerpc-linux-gnu
target powerpc-linux-gnuspe
target powerpc64-linux-gnu

which would be how you'd do it with one target triplet = one set of 
libraries (I've removed the "company" part from the triplets here as 
always useless except when misused).

Joseph S. Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]