[clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

[ro]

Summary

As reported in Bug 42535, clang doesn't inline atomic ops on 32-bit Sparc, unlike gcc on
Solaris. In a 1-stage build with gcc, only two testcases are affected (currently XFAILed), while in a 2-stage build more than 100 tests FAIL due to this issue.

The reason for this gcc/clang difference is that gcc on 32-bitSolaris/SPARC defaults to -mpcu=v9 where atomic ops are supported, unlike with clang's default of -mcpu=v8. This patch changes clang to use -mcpu=v9 on 32-bit Solaris/SPARC, too.

Doing so uncovered two bugs:

clang -m32 -mcpu=v9 chokes with any Solaris system headers included:

/usr/include/sys/isa_defs.h:461:2: error: "Both _ILP32 and _LP64 are defined"
#error "Both _ILP32 and _LP64 are defined"

While clang currently defines __sparcv9 in a 32-bit -mcpu=v9 compilation, neither gcc nor Studio cc do. In fact, the Studio 12.6 cc(1) man page clearly states:

          These predefinitions are valid in all modes:
[...]
             __sparcv8 (SPARC)
             __sparcv9 (SPARC -m64)

At the same time, the patch defines __GCC_HAVE_SYNC_COMPARE_AND_SWAP_[1248] for a 32-bit Sparc compilation with any V9 cpu. I've also changed MaxAtomicInlineWidth for V9, matching what gcc does and the Oracle Developer Studio 12.6: C User's Guide documents (Ch. 3, Support for Atomic Types, 3.1 Size and Alignment of Atomic C Types).

The two testcases that had been XFAILed for Bug 42535 are un-XFAILed again. However, one of those and another testcase now FAIL due to Bug 42493 and are thus XFAILed.

Tested on sparcv9-sun-solaris2.11 and amd64-pc-solaris2.11.

While the fix proper is trivial: just two lines in lib/Driver/ToolChains/CommonArgs.cpp, finding the right place has been nightmarishly difficult: I'd have expected handling of a Solaris/SPARC CPU default in either of Solaris or SPARC specific files, but not deeply hidden in common code. I've come across issues like this over and over again: configuration information in LLVM is spread all over the place, difficult to find or just to know that it exists.

[ro]

While doing 2-stage builds, the 2 XFAILs due to Bug 42493 were required. However, I've since also done a 1-stage build with gcc 10, which shows

Unexpectedly Passed Tests (2):
  UBSan-Standalone-sparc :: TestCases/Float/cast-overflow.cpp
  UBSan-Standalone-sparc :: TestCases/Misc/log-path_test.cpp

which is no wonder since the underlying bug only exists in clang long double handling.

I'm a bit uncertain how to deal with this: since the Solaris/sparcv9 buildbot currently does 1-stage builds with gcc, the resulting XPASSes would turn the bot red. However, currently there's no clang-vs.-gcc feature in lit to distinguish the two builds, AFAICT. libcxx has something like this, but that might be overkill to extract.

Perhaps just remove the XFAILs for now?

[ro]

Ping? It's been a week.

[efriedma]

While the fix proper is trivial: just two lines in lib/Driver/ToolChains/CommonArgs.cpp, finding the right place has been nightmarishly difficult: I'd have expected handling of a Solaris/SPARC CPU default in either of Solaris or SPARC specific files, but not deeply hidden in common code. I've come across issues like this over and over again: configuration information in LLVM is spread all over the place, difficult to find or just to know that it exists.

The clang driver is messy, yes. Other places are pretty good about this, mostly.

For compiler-rt, the XFAILs should probably reflect whatever config the bot is running. (Alternatively, you could use UNSUPPORTED, but that doesn't seem warranted here.)

clang/lib/Basic/Targets/Sparc.cpp

224

This probably should be refactored so the target-independent code generates it based on MaxAtomicInlineWidth, instead of duplicating it for each target. But I guess you don't need to do that here.

From the other code, the getCPUGeneration(CPU) == CG_V9 check should only guard the definition of __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8?

clang/lib/Driver/ToolChains/CommonArgs.cpp

350

Do we want to make sparc and sparcel behave differently here?

[jrtc27]

GCC on Linux defines __sparc_v9__ even with -m32. I don't know what Solaris does but please don't break other operating systems just because Solaris has broken headers that conflate the CPU and the ABI.

[jrtc27]

And notably _doesn't_ define the V8 macros, which this patch then reintroduces.

[ro]

In D86621#2247786, @efriedma wrote:

For compiler-rt, the XFAILs should probably reflect whatever config the bot is running. (Alternatively, you could use UNSUPPORTED, but that doesn't seem warranted here.)

That's been my guess, too (with the goal of getting the bot green eventually in mind). Once the underlying clang bug is fixed, the tests will pass with both compilers, so I agree that UNSUPPORTED isn't warranted here.

clang/lib/Basic/Targets/Sparc.cpp

224

This probably should be refactored so the target-independent code generates it based on MaxAtomicInlineWidth, instead of duplicating it for each target. But I guess you don't need to do that here.

Good: one issue at a time ;-)

From the other code, the getCPUGeneration(CPU) == CG_V9 check should only guard the definition of __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8?

I don't think so: at least gcc defines none of the four with -m32 -mcpu=v8 and all with -m32 -mcpu=v9.

clang/lib/Driver/ToolChains/CommonArgs.cpp

350

The only thing about little-endian SPARC is that UltraSPARC CPUs can be run in little-endian mode, presumably to ease a Windows NT port that never materialized.

I could barely find any info on sparcel: the triplet isn't in config.guess, there's very little else about such CPUs and certainly no specification or even an ABI. That's why I tend to leave sparcel-specific code alone unless someone who knows these beasts tells me otherwise.

What I can say for certain that Solaris never ran on little-endian SPARC.

[ro]

In D86621#2247791, @jrtc27 wrote:

GCC on Linux defines __sparc_v9__ even with -m32. I don't know what Solaris does but please don't break other operating systems just because Solaris has broken headers that conflate the CPU and the ABI.

I'd have sworn that I checked gcc on Linux/sparc64: must have been dreaming.

I quoted the relevant snippet of the Studio cc(1) man page which shows that Solaris compilers predefine __sparcv8 for -m32 and __sparcv9 for -m64. I'd argue that the creators of the CPU, the OS, and the initial compiler can decide to do so as they please (after all, AFAICT that's not part of any ABI and I couldn't find an API document that mentioned those), nothing broken or conflated here.

I've now looked at the GCC sources and found:

• FreeBSD/sparc64 is 64-bit-only, no 32-bit support in sight
• while the NetBSD/sparc64 port still includes bi-arch support, it is disabled because the don't ship a 32-bit environment and even if they did, they only define __sparc_v9__ etc. for -m64.
• OpenBSD/sparc64 again is 64-bit only

I'll see how best to reconcile those.

[ro]

Define __sparcv8 only on 32-bit Solaris/SPARC.
Update testcase.
Remove XFAILs that only apply to clang/2-stage builds.

[jrtc27]

Actually, __sparcv8 is only for V8; if you have 32-bit V9 on Solaris it defines __sparcv8plus _instead_:

jrtc27@gcc-solaris11:~$ /opt/solarisstudio12.4/bin/cc -E - -xarch=v9 -m32 -xdumpmacros </dev/null 2>&1 | grep sparc
#define __sparcv8plus 1
#define __sparc 1
#define sparc 1

In fact, -xarch=v9 + -m32 is a bit weird because -xarch=v9 implies -m64 so the argument order matters, and the modern way to do it is (if you read the man page, -xarch=sparc means V9 and -xarch=v9 is an alias for -m64 -xarch=sparc...):

jrtc27@gcc-solaris11:~$ /opt/solarisstudio12.4/bin/cc -E - -m32 -xarch=sparc -xdumpmacros </dev/null 2>&1 | grep sparc
#define __sparcv8plus 1
#define __sparc 1
#define sparc 1

(gcc211 on the GCC compile farm; any open-source developer can register, it's not specific to GCC developers despite the name)

[ro]

In D86621#2249240, @jrtc27 wrote:

Actually, __sparcv8 is only for V8; if you have 32-bit V9 on Solaris it defines __sparcv8plus _instead_:

jrtc27@gcc-solaris11:~$ /opt/solarisstudio12.4/bin/cc -E - -xarch=v9 -m32 -xdumpmacros </dev/null 2>&1 | grep sparc
#define __sparcv8plus 1
#define __sparc 1
#define sparc 1

That's only true up to Studio 12.4: 12.5 and 12.6 define both __sparcv8 and __sparcv8plus, and strangely even the 12.4 and 12.3 cc(1) man pages only documents __sparcv8 while 12.2 only has __sparc. We could also define __sparcv8plus, but gcc doesn't do that, so it would only help people compiling with cc.

In fact, -xarch=v9 + -m32 is a bit weird because -xarch=v9 implies -m64 so the argument order matters, and the modern way to do it is (if you read the man page, -xarch=sparc means V9 and -xarch=v9 is an alias for -m64 -xarch=sparc...):

Right; 12.5 and 12.6 cc even warn

cc: Warning: -xarch=v9 is deprecated, use -m64 -xarch=sparc instead

jrtc27@gcc-solaris11:~$ /opt/solarisstudio12.4/bin/cc -E - -m32 -xarch=sparc -xdumpmacros </dev/null 2>&1 | grep sparc
#define __sparcv8plus 1
#define __sparc 1
#define sparc 1

(gcc211 on the GCC compile farm; any open-source developer can register, it's not specific to GCC developers despite the name)

I do have a cfarm account already. However, there's no need for that: I do have every version of Studio back to 11 installed locally.

[brad]

clang/lib/Driver/ToolChains/CommonArgs.cpp

350

"The Sparcle is an experimental 32-bit microprocessor chip developed in 1992 by a consortium of MIT, LSI Corporation, and Sun Microsystems. It was an evolution Sun's SPARC RISC architecture with features geared towards "large-scale multiprocessing".[1] The chip was manufactured by LSI."

https://people.eecs.berkeley.edu/~kubitron/cs252/handouts/papers/sparcle-micro-final.pdf

From what little I can find I believe this prototype CPU / system was based on Linux.

[efriedma]

clang/lib/Basic/Targets/Sparc.cpp

224

This code, the code that sets MaxAtomicInlineWidth, and the code inSPARCISelLowering.cpp that calls setMaxAtomicSizeInBitsSupported() all need to agree about the supported atomic operations.

I guess the current setting of MaxAtomicInlineWidth is wrong?

[ro]

clang/lib/Basic/Targets/Sparc.cpp

224

I'd say so, yes: gcc -m32 inlines ops on _Atomic long long while clang-11 -m32 -mcpu=v9 doesn't.

[ro]

clang/lib/Driver/ToolChains/CommonArgs.cpp

350

Ah, thanks. So this predates Solaris 2.0 (also released in 1992). But even if not, current Solaris 11 is SPARC V9-only.

However, if this is the only implementation, this bears the question why support for such an experimental CPU almost 30 years old still lives in LLVM. It comes with a cost, if only for reasoning what needs and needs not to be done to the V8el code.

[efriedma]

clang/lib/Basic/Targets/Sparc.cpp

224

Oh, hmm, it looks like the backend's support for 32-bit v9 is really limited; we basically generate v8 code, with a couple limited exceptions. Probably okay to make clang assume 64-bit atomics are actually supported, even if we don't inline the implementation at the moment; they should still behave correctly.

I was more wondering about what we do for v8: we set MaxAtomicInlineWidth to 32, but I don't think it supports atomic cmpxchg at all.

[efriedma]

clang/lib/Driver/ToolChains/CommonArgs.cpp

350

The sparcv9 manual says the CPU has a little-endian mode; I assume that means all sparcv9 chips support it. If nobody actually does that in practice, though, we should drop the sparcel target.

[ro]

clang/lib/Driver/ToolChains/CommonArgs.cpp

350

Right. However, that's a privileged operation AFAIU and non of the OSes I know about (Solaris, Linux, the BSDs) run in little-endian mode. Besides, it would be weird to restrict oneself to the sparcv8 insns if one were using that v9 facility. On top of all that, gcc doesn't support the little-endian mode at all.

[ro]

clang/lib/Driver/ToolChains/CommonArgs.cpp

350

Seems we missed something, though: https://ec.europa.eu/research/participants/documents/downloadPublic?documentIds=080166e5a6e0e311&appId=PPGMS states (p.18):

6.3.5. Endianness
The Leon processors are both working in little endian same as the SHAVE processors. No extra requirements are needed to ensure endianess consistency.

Judging from that, Myriad is the primary user of sparcel these days. So unless we can get rid of that, too, sparcel will have to stay.

The point of no available documentation remains, though.

[ro]

clang/lib/Basic/Targets/Sparc.cpp

224

I've now found The V8+ Technical Specification. I've not checked how far LLVM makes use of that, though (gcc seems to be pretty extensive, and it certainly makes use of casx for v8plus).

I'm not really clear on the semantics of MaxAtomicInlineWidth: TargetInfo.h's description of getMaxAtomicInlineWidth only states

/// Return the maximum width lock-free atomic operation which can be
/// inlined given the supported features of the given target.

which would be satisfied given that some 32-bit atomic ops are inlined for v8.

[efriedma]

clang/lib/Basic/Targets/Sparc.cpp

224

The definition of C atomic operations requires that we only expose lock-free atomic operations on targets that have a lock-free cmpxchg. This is necessary to allow the implementation in libatomic to work: even if an operation is "atomic", it wouldn't correctly honor the libatomic locks.

Note that the dynamic component of libatomic allows using lockfree operations in a "v8plus" environment. The libatomic implementation should dynamically check whether the CPU supports casx, and use lock-free operations if it does.

[ro]

clang/lib/Basic/Targets/Sparc.cpp

224

Honestly, I don't see this as my job, though: the issue is pre-existing, it doesn't affect any of my targets and I see that GCC's libatomic forces -mcpu=v9 for the 32-bit sparc library.

[efriedma]

clang/lib/Basic/Targets/Sparc.cpp

224

If you don't want to touch it, please leave a FIXME so the next person looking at this code has a reference.

[ro]

Add FIXME for SparcV8 MaxAtomicInlineWidth.

[ro]

Is there anything left to do to get approval? Thanks.

[ro]

Ping? It's been a week and AFAICT there's nothing left for me to do.

[efriedma]

LGTM

clang/lib/Basic/Targets/Sparc.h

default:
       break;
     case llvm::Triple::NetBSD:
     case llvm::Triple::OpenBSD:
       SizeType = UnsignedLong;
       IntPtrType = SignedLong;
       PtrDiffType = SignedLong;
       break;
     }
-    // Up to 32 bits are lock-free atomic, but we're willing to do atomic ops
-    // on up to 64 bits.
+    // Up to 32 bits (V8) or 64 bits (V9) are lock-free atomic, but we're
+    // willing to do atomic ops on up to 64 bits.
     MaxAtomicPromoteWidth = 64;
+    if (getCPUGeneration(CPU) == CG_V9)
+      MaxAtomicInlineWidth = 64;
+    else
       MaxAtomicInlineWidth = 32;
   }
 
   void getTargetDefines(const LangOptions &Opts,
                         MacroBuilder &Builder) const override;
 
   bool hasSjLjLowering() const override { return true; }
   bool hasExtIntType() const override { return true; }
 };

clang/lib/Basic/Targets/Sparc.cpp

void SparcTargetInfo::getTargetDefines(const LangOptions &Opts,
 
   if (SoftFloat)
     Builder.defineMacro("SOFT_FLOAT", "1");
 }
 
 void SparcV8TargetInfo::getTargetDefines(const LangOptions &Opts,
                                          MacroBuilder &Builder) const {
   SparcTargetInfo::getTargetDefines(Opts, Builder);
-  switch (getCPUGeneration(CPU)) {
-  case CG_V8:
-    Builder.defineMacro("__sparcv8");
-    if (getTriple().getOS() != llvm::Triple::Solaris)
-      Builder.defineMacro("__sparcv8__");
-    break;
-  case CG_V9:
-    Builder.defineMacro("__sparcv9");
-    if (getTriple().getOS() != llvm::Triple::Solaris) {
-      Builder.defineMacro("__sparcv9__");
-      Builder.defineMacro("__sparc_v9__");
-    }
-    break;
-  }
   if (getTriple().getVendor() == llvm::Triple::Myriad) {
     std::string MyriadArchValue, Myriad2Value;
     Builder.defineMacro("__sparc_v8__");
     Builder.defineMacro("__leon__");
     switch (CPU) {
     case CK_MYRIAD2100:
       MyriadArchValue = "__ma2100";
       Myriad2Value = "1";
if (Myriad2Value == "2") {
       Builder.defineMacro("__ma2x5x__", "1");
     } else if (Myriad2Value == "3") {
       Builder.defineMacro("__ma2x8x", "1");
       Builder.defineMacro("__ma2x8x__", "1");
     }
     Builder.defineMacro("__myriad2__", Myriad2Value);
     Builder.defineMacro("__myriad2", Myriad2Value);
   }
+  if (getCPUGeneration(CPU) == CG_V9) {
+    Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_1");
+    Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2");
+    Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4");
+    Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8");
+  }
 }
 
 void SparcV9TargetInfo::getTargetDefines(const LangOptions &Opts,
                                          MacroBuilder &Builder) const {
   SparcTargetInfo::getTargetDefines(Opts, Builder);
   Builder.defineMacro("__sparcv9");
   Builder.defineMacro("__arch64__");
   // Solaris doesn't need these variants, but the BSDs do.

clang/lib/Driver/ToolChains/CommonArgs.cpp

std::string tools::getCPUName(const ArgList &Args, const llvm::Triple &T,
 
   case llvm::Triple::bpfel:
   case llvm::Triple::bpfeb:
   case llvm::Triple::sparc:
   case llvm::Triple::sparcel:
   case llvm::Triple::sparcv9:
     if (const Arg *A = Args.getLastArg(options::OPT_mcpu_EQ))
       return A->getValue();
+    if (T.getArch() == llvm::Triple::sparc && T.isOSSolaris())
+      return "v9";
     return "";
 
   case llvm::Triple::x86:
   case llvm::Triple::x86_64:
     return x86::getX86TargetCPU(Args, T);
 
   case llvm::Triple::hexagon:
     return "hexagon" +

clang/test/Preprocessor/predefined-arch-macros.c

 // CHECK_SPARC-NOT: #define __sparcv9__ 1
 // CHECK_SPARC: #define __sparcv8 1
 // CHECK_SPARC-NOT: #define __sparcv9 1
 // CHECK_SPARC-NOT: #define __sparcv9__ 1
 
 // RUN: %clang -mcpu=v9 -E -dM %s -o - 2>&1 \
 // RUN:     -target sparc-unknown-linux \
 // RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_SPARC-V9
-// CHECK_SPARC-V9-NOT: #define __sparcv8 1
-// CHECK_SPARC-V9: #define __sparc_v9__ 1
-// CHECK_SPARC-V9: #define __sparcv9 1
-// CHECK_SPARC-V9-NOT: #define __sparcv8 1
+// CHECK_SPARC-V9: #define __sparcv8 1
+// CHECK_SPARC-V9: #define __sparcv8__ 1
+// CHECK_SPARC-V9-NOT: #define __sparc_v9__ 1
+// CHECK_SPARC-V9-NOT: #define __sparcv9 1
+
+// RUN: %clang -E -dM %s -o - 2>&1 \
+// RUN:     -target sparc-sun-solaris \
+// RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_SPARC_SOLARIS_GCC_ATOMICS
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1
+
+// RUN: %clang -mcpu=v8 -E -dM %s -o - 2>&1 \
+// RUN:     -target sparc-sun-solaris \
+// RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_SPARC_SOLARIS_GCC_ATOMICS-V8
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS-V8-NOT: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS-V8-NOT: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS-V8-NOT: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS-V8-NOT: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1
 
 // RUN: %clang -E -dM %s -o - 2>&1 \
 // RUN:     -target sparcel-unknown-linux \
 // RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_SPARCEL
 // RUN: %clang -E -dM %s -o - -target sparcel-myriad -mcpu=myriad2 2>&1 \
 // RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_MYRIAD2-2 \
 // RUN:     -check-prefix=CHECK_SPARCEL -check-prefix=CHECK_MYRIAD2
 // RUN: %clang -E -dM %s -o - -target sparcel-myriad -mcpu=myriad2.1 2>&1 \

compiler-rt/test/profile/Posix/instrprof-gcov-parallel.test

 RUN: mkdir -p %t.d
 RUN: cd %t.d
 
 RUN: %clang -o %t.driver %S/../Inputs/instrprof-gcov-parallel.driver.c
 RUN: %clang --coverage -o %t.target %S/../Inputs/instrprof-gcov-parallel.target.c
 RUN: test -f instrprof-gcov-parallel.target.gcno
 
 RUN: rm -f instrprof-gcov-parallel.target.gcda
 RUN: %run %t.driver %t.target
 RUN: llvm-cov gcov instrprof-gcov-parallel.target.gcda
 RUN: FileCheck --input-file instrprof-gcov-parallel.target.c.gcov %s
 
-# Bug 42535
-# XFAIL: sparc-target-arch
-
 # Test if the .gcda file is correctly created from one of child processes
 # and counters of all processes are recorded correctly.
 # 707 = CHILDREN * COUNT
 CHECK: 707: {{[0-9]+}}: aaa++;

compiler-rt/test/ubsan/TestCases/Float/cast-overflow.cpp

 // RUN: %clangxx -fsanitize=float-cast-overflow %s -o %t
 // RUN: %run %t _
 // RUN: %env_ubsan_opts=print_summary=1:report_error_type=1 %run %t 0 2>&1 | FileCheck %s --check-prefix=CHECK-0
 // RUN: %run %t 1 2>&1 | FileCheck %s --check-prefix=CHECK-1
 // RUN: %run %t 2 2>&1 | FileCheck %s --check-prefix=CHECK-2
 // RUN: %run %t 3 2>&1 | FileCheck %s --check-prefix=CHECK-3
 // RUN: %run %t 4 2>&1 | FileCheck %s --check-prefix=CHECK-4
 // RUN: %run %t 5 2>&1 | FileCheck %s --check-prefix=CHECK-5
 // RUN: %run %t 6 2>&1 | FileCheck %s --check-prefix=CHECK-6
 // FIXME: %run %t 7 2>&1 | FileCheck %s --check-prefix=CHECK-7
 // FIXME: not %run %t 8 2>&1 | FileCheck %s --check-prefix=CHECK-8
 // RUN: not %run %t 9 2>&1 | FileCheck %s --check-prefix=CHECK-9
 
-// Bug 42535
+// Bug 42493
 // XFAIL: sparc-target-arch
 
 // This test assumes float and double are IEEE-754 single- and double-precision.
 
 #if defined(__APPLE__)
 # include <machine/endian.h>
 # define BYTE_ORDER __DARWIN_BYTE_ORDER
 # define BIG_ENDIAN __DARWIN_BIG_ENDIAN

compiler-rt/test/ubsan/TestCases/Misc/log-path_test.cpp

 // RUN: rm -f %t.log.*
 // RUN: %device_rm -f '%t.log.*'
 // RUN: %env_ubsan_opts=log_path='"%t.log"'  %run %t 4
 // RUN: not cat %t.log.*
 
 // FIXME: log_path is not supported on Windows yet.
 // XFAIL: windows-msvc
 
+// Bug 42493
+// XFAIL: sparc-target-arch
+
 #include <stdio.h>
 #include <stdlib.h>
 int main(int argc, char *argv[]) {
   double a = atof(argv[1]);
   unsigned int ai = (unsigned int) a;
   printf("%f %u\n", a, ai);
   return 0;
 }
 
 // CHECK-ERROR: runtime error: -4 is outside the range of representable values of type 'unsigned int'