[compiler-rt] [SPARC][builtins] Add sparcv9 arch name for 32-bit SPARC (PR #170133)

[Rainer Orth via llvm-commits]

rorth wrote:

I fear this is just a hack at best:

- I've run a 2-stage build on `main` without this patch: only two tests `FAIL` there:
  ```
   Builtins-sparc-sunos :: divtc3_test.c
   Builtins-sparc-sunos :: multc3_test.c
  ```
- However, in a 1-stage build with `clang-21`, there are way more, as seen in the Solaris/sparcv9 buildbot:
  ```
  AddressSanitizer-sparc-sunos :: TestCases/frexpl_interceptor.cpp
  AddressSanitizer-sparc-sunos-dynamic :: TestCases/frexpl_interceptor.cpp
  Builtins-sparc-sunos :: addtf3_test.c
  Builtins-sparc-sunos :: divtc3_test.c
  Builtins-sparc-sunos :: divtf3_test.c
  Builtins-sparc-sunos :: extenddftf2_test.c
  Builtins-sparc-sunos :: extendsftf2_test.c
  Builtins-sparc-sunos :: fixtfdi_test.c
  Builtins-sparc-sunos :: fixtfsi_test.c
  Builtins-sparc-sunos :: fixtfti_test.c
  Builtins-sparc-sunos :: fixunstfdi_test.c
  Builtins-sparc-sunos :: fixunstfsi_test.c
  Builtins-sparc-sunos :: fixunstfti_test.c
  Builtins-sparc-sunos :: floatditf_test.c
  Builtins-sparc-sunos :: floatsitf_test.c
  Builtins-sparc-sunos :: floattitf_test.c
  Builtins-sparc-sunos :: floatunditf_test.c
  Builtins-sparc-sunos :: floatunsitf_test.c
  Builtins-sparc-sunos :: floatuntitf_test.c
  Builtins-sparc-sunos :: multc3_test.c
  Builtins-sparc-sunos :: multf3_test.c
  Builtins-sparc-sunos :: powitf2_test.c
  Builtins-sparc-sunos :: subtf3_test.c
  Builtins-sparc-sunos :: trunctfdf2_test.c
  Builtins-sparc-sunos :: trunctfsf2_test.c
  Flang :: Driver/gcc-triple.f90
  UBSan-AddressSanitizer-sparc :: TestCases/Float/cast-overflow.cpp
  UBSan-AddressSanitizer-sparc :: TestCases/Misc/log-path_test.cpp
  UBSan-Standalone-sparc :: TestCases/Float/cast-overflow.cpp
  UBSan-Standalone-sparc :: TestCases/Misc/log-path_test.cpp
  ```
The buildbot cannot run full two-stage builds for performance reasons: to address this, one would have to use a fixed `main` `clang` instead of the current `clang-21` or backport the patch to the `release/21.x` branch.

Even for the 2-stage build, the two `FAIL`ing tests die with `SIGILL`:
```
Thread 2 received signal SIGILL, Illegal instruction.
[Switching to Thread 1 (LWP 1)]
0x00011500 in test.divtc3 ()
    at /vol/llvm/src/llvm-project/local/compiler-rt/test/builtins/Unit/divtc3_test.c:47
47	  Qcomplex r = __divtc3(a, b, c, d);
1: x/i $pc
=> 0x11500 <test__divtc3+432>:	illtrap  0x20
(gdb) bt
#0  0x00011500 in test.divtc3 ()
    at /vol/llvm/src/llvm-project/local/compiler-rt/test/builtins/Unit/divtc3_test.c:47
#1  0x000111a8 in main ()
    at /vol/llvm/src/llvm-project/local/compiler-rt/test/builtins/Unit/divtc3_test.c:356
```
I'm pretty certain that this patch is wrong at least for the 2-stage case (though I'm currently testing it).  Besides, only the 32-bit tests `FAIL` in both cases, the 64-bit ones (`sparcv9`) work just fine.

Besides, the 32-bit `libclang_rt.builtins-sparc.a` is a total mess: e.g. up to LLVM-17 it **did** contain  a definition of `__multc3`, which afterwards was lost.  `libgcc_s.so.1` has it two, as it should.  The same is true for several of the other functions that cause the link failures in the 1-stage build:
```
__divtc3
__fixtfdi
__fixunstfdi
__floatditf
__floatunditf
__multc3
__powitf2
```
However, `builtins` has been badly been messed with in recent times, e.g. by the `s390x` port which is reponsible for some of this.  Combine this with the lack of testing in the default `runtimes` builds and the breakage wasn't even noticed.  I've meanwhile lost both time and patience to deal with issue since I don't believe it will ever be fixed (even the loss of builtins testing has been completely ignored so far).

https://github.com/llvm/llvm-project/pull/170133