Re: x86_64-solaris

[Rainer Orth]

Hi Earnie,

>>> SOLARIS contains both 32 and 64bit binaries
>>> and libraries it does not mean this is correct.
>>
>> What do you mean by `correct'?  It's perfectly correct to run 32-bit
>> binaries on a machine that is also capable of running 64-bit ones.  In
>> fact, you'd be surprised that even in unexpected cases the 32-bit
>> ones may perform better than the 64-bit binaries.
>>
>
> There is a lot of pro vs con on multi-lib systems and whether or not it is
> correct to have/use them.  I tend to lean toward Apostolos' opinion that
> such systems are just wrong.

you're certainly entitled to your opinion about multilibbed systems, but
they are a reality if you like that or not.  So please leave it to the
users and maintainers of such systems how to determine the triplets to
match their uses and the toolchain's needs and conventions.

To give some background, I'm forwarding a message from John Henning, who
originally reported the issue to me that led to the GCC bug report that
started this thread.  He's a long-term contributor to SPEC, btw.  He
didn't send it himself because it's extremely tedious to reply to
config-patches postings if you're not subscribed to the list, as I've
discovered myself.

---------------------------------------------------------------------------

Perhaps I am misunderstanding this statement:
> There is a lot of pro vs con on multi-lib systems and whether or not it
> is correct to have/use them. I tend to lean toward Apostolos' opinion that
> such systems are just wrong.
but as written it appears to be claiming that it is “wrong” for operating
systems that are 64-bit capable to have compilers that support both 32-bit
and 64-bit application binary interfaces.

If that is what it means, then it seems to ignore large segments of system
history.

Many systems have supported users having a choice of which ABI they want;
and in particular users have been allowed to make that choice based on
performance, if they so desire.

Examples of such choices go deep into history, and continue to the present
day.
Here is some history:
AIX, for example from 2001:
https://www.spec.org/osg/cpu2000/results/res2001q4/cpu2000-20011105-01108.html
(some benchmarks use q64, others don’t).
Irix, for example from 1996:
https://www.spec.org/osg/cpu95/results/res96q4/cpu95-961115-01482.html
(some benchmarks use -n32, some don’t)
Linux x86, for example from 2004:
https://www.spec.org/osg/cpu2000/results/res2004q3/cpu2000-20040628-03194.html
(some benchmarks use -m32, some don’t)
Linux Power, for example from 2004:
https://www.spec.org/osg/cpu2000/results/res2004q4/cpu2000-20041018-03450.html
(some benchmarks use -q64, some don’t)
Solaris x86, for example from 2006:
https://www.spec.org/cpu2006/results/res2010q1/cpu2006-20100115-09340.html
(some benchmarks use -m64,some don’t, and therefore default to -m32)
Solaris SPARC, for example from 2001:
https://www.spec.org/osg/cpu2000/results/res2001q3/cpu2000-20010827-00805.html
(some benchmarks use the 32-bit xarch=v8plus, some use 64-bit xarch=v9)

Each of the above are for systems that allow invocation of a single
compiler that is able to create binaries that are for the 32-bit or 64-bit
ABI.  Not included are compilers that are invoked via differing methods,
such as /path/to/64bit/icc and /path/to/32bit/icc.

---------------------------------------------------------------------------

To sum up, I've believe I've made my point and it's up to Ben to
decide.  For the moment, he's reverted Apostolos' patch, and I hope it
will remain this way in light of the evidence produced.  If so, I intend
to post a corresponding patch to treat Solaris/SPARC configure triplet
determination like it's currently done for Solaris/x86, i.e. return
sparcv9-sun-solaris2.* when using a 64-bit compiler and
sparc-sun-solaris2.* for the 32-it case.

        Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University