Re: canonical triple of SPARC/Solaris changed

[Rainer Orth]

Hi Bruno,

>> as you can see in config.sub, there are a couple of
>> valid and canonical forms of the cpu part for sparc:
>> 
>>                      | sparc | sparc64 | sparc64b | sparc64v | sparc86x
>>                      | | sparclet \
>>                      | sparclite \
>>                      | sparcv8 | sparcv9 | sparcv9b | sparcv9v | sv1 | sx* \
>> 
>> If you change the macro above to accept not only the sparc and sparc64
>> forms you chose to support (for whatever reason), but either that whole
>> set or even simpler, sparc*, your problem goes away.
>
> Sorry, but I cannot use this approach in GNU libffcall:
>
>   * Some of the CPU name variants don't have the same instruction sets as
>     the main variant. For example, 'powerpc' code will not run on a 
> 'powerpcspe'
>     machines. And 'mips64' code will not run correctly on 'mips64le' machines.
>     Maybe the same is true for some 'sparc' variants; I don't know.
>     If I were to follow your advice, people would see that libffcall compiles
>     fine on their machine and then be disappointed that the code crashes.
>     With the approach I've chosen, people see a build-fails situation and
>     report it on the bug tracker, _without_ getting the impression that the
>     package is unreliable.

I've never suggested to replace the use of wildcards instead of a
specific set of patterns in host-cpu-c-abi.m4 in general, just to
replace "sparc | sparc64" with "sparc*".  This is pretty much guaranteed
to work by SPARC International and their standardized ABIs (V7 and V9).
Besides, you already test for __sparc__ vs. __sparc64__ to determine the
ABI: what config.guess calls it doesn't matter.

>   * Therefore I'm using the approach that I test on specific platforms, and
>     refrain from pretending to support anything that I cannot test. (I believe
>     GCC uses the same approach.)

You almost never will have all theoretical variations of a CPU at your
disposal to test.  However, in the SPARC case it's practically
guaranteed that they support either or both of the standardized ABIs.

> So far, all SPARC-based platforms I tested (Linux/sparc, Solaris/sparc,
> NetBSD/sparc) all return 'sparc' or 'sparc64' as the $host_cpu. None returns
> 'sparcv9', 'sparclite', 'sparc86x', or similar.

True, but users could already do so for reasons of their own (and
actually *do* this).

> When a new platform arises that has a new cpu, maybe 'sparct6' or so, and
> someone has tested that libffcall builds and runs fine with it, I add this
> cpu to the various conditionals.

There are two possible cases here:

* Either such a sparct6 cpu supports neither the SPARC V7 nor the SPARC
  V9 ABIs.  In such a case, you'd have quite a bit of coding before you
  and the triplet would be the least of your problems.  A compiler
  wouldn't then define either __sparc__ or __sparc64__ and the test
  would fail, irrespective of cpu part of the triplet.  Besides, such a
  beast wouldn't be allowed to be called sparc in the first place, SPARC
  International having a say in the use of the name.

* If on the other hands sparct6 does support either or both of the SPARC
  v7 or V9 ABIs, but the makers decided sparct6 describes it better than
  sparc or sparc64, you would just be set with the sparc* wildcard.

> The way I work with these configure triplets just breaks down when the
> triplet of an existing platform changes. If you had picked 'sparc64'
> instead of 'sparc', libffcall would not have had problems, because
> 'sparc64' is the $host_cpu on Linux/sparc64. But other packages (maybe
> GMP) still might have had problems.

But sparc64 is a name only used in the Linux world and completely
foreign to Solaris.  Remember that Sun invented SPARC, so they should be
allowed to decide how the call the cpu/ABI on their own systems.
Besides, the sparcv9 moniker is way older than sparc64 ;-)

>> Besides, I'm not changing the triplet in general, just making more use
>> of a form of the Solaris/SPARC triplet
>
> The patch changed the triplet of an existing platform.

... in very specific circumstances to be consistent with 64-bit
Solaris/x86 and avoid very hard to debug problems in the toolchain.

> The config.{guess,sub} combination and its documentation does not formally
> define a range of triplets (e.g. "sparc*-*-solaris*") per platform. Even if
> such a formal specification existed, I doubt that it would make sense to
> use it in GNU libffcall, because I don't know about all the possible variants
> of sparc CPUs, thus this would contradict my "support only what you have
> tested" approach.

I can't say how widespread libffcall or users of host-cpu-c-abi.m4 are,
but that appproach seems overly cautious to me, especially in the sparc
case where your test and the ABI standardization already guard against
mishap.

>> >    there is
>> >    no good reason to change the triple of ANY platform after it is in
>> >    production for more than 1 year.
>> 
>> if you'd read the patch submission, you'd know that there is indeed.
>
> https://lists.gnu.org/archive/html/config-patches/2019-01/msg00000.html
> mentions GCC as motivation. By the arguments in my previous mail it is clear
> that the proper place for this code
>
>        if [ "$CC_FOR_BUILD" != no_compiler_found ]; then
>            if (echo '#ifdef __sparcv9'; echo IS_64BIT_ARCH; echo '#endif') | \
>                (CCOPTS="" $CC_FOR_BUILD -E - 2>/dev/null) | \
>                grep IS_64BIT_ARCH >/dev/null
>            then
>                SUN_ARCH=sparcv9
>            fi
>        fi
>
> is the configure.ac script of GCC or some .m4 file or helper script used by
> this configure.ac script.

No, config.guess on Solaris/x86 has already used almost the same snippet
for years.  It's quite confusing to users that config.guess on x86
produces a configure triplet depending on the compiler while no such
thing happens on sparc.

        Rainer

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