[llvm-exegesis][unittests] Also disable SubprocessMemoryTest on SPARC

[rorth]

Three llvm-exegesis tests

  LLVM-Unit :: tools/llvm-exegesis/./LLVMExegesisTests/SubprocessMemoryTest/DefinitionFillsCompletely
  LLVM-Unit :: tools/llvm-exegesis/./LLVMExegesisTests/SubprocessMemoryTest/MultipleDefinitions
  LLVM-Unit :: tools/llvm-exegesis/./LLVMExegesisTests/SubprocessMemoryTest/OneDefinition

FAIL on Linux/sparc64 like

llvm/unittests/tools/llvm-exegesis/X86/SubprocessMemoryTest.cpp:68: Failure
Expected equality of these values:
  SharedMemoryMapping[I]
    Which is: '\0'
  ExpectedValue[I]
    Which is: '\xAA' (170)

It seems like this test only works on little-endian hosts: three sub-tests are already disabled on powerpc and s390x (both big-endian), and the fourth is additionally guarded against big-endian hosts (making the other guards unnecessary).

However, since it's not been analyzed if this is really an endianess issue, this patch disables the whole test on powerpc and s390x as before adding sparc to the mix.

Tested on sparc64-unknown-linux-gnu and x86_64-pc-linux-gnu.

[llvmbot]

@llvm/pr-subscribers-tools-llvm-exegesis

Author: Rainer Orth (rorth)

Changes

… hosts

Three llvm-exegesis tests

  LLVM-Unit :: tools/llvm-exegesis/./LLVMExegesisTests/SubprocessMemoryTest/DefinitionFillsCompletely
  LLVM-Unit :: tools/llvm-exegesis/./LLVMExegesisTests/SubprocessMemoryTest/MultipleDefinitions
  LLVM-Unit :: tools/llvm-exegesis/./LLVMExegesisTests/SubprocessMemoryTest/OneDefinition

FAIL on Linux/sparc64 like

llvm/unittests/tools/llvm-exegesis/X86/SubprocessMemoryTest.cpp:68: Failure
Expected equality of these values:
  SharedMemoryMapping[I]
    Which is: '\0'
  ExpectedValue[I]
    Which is: '\xAA' (170)

It seems like this test only works on little-endian hosts: three sub-tests are already disabled on powerpc and s390x (both big-endian), and the fourth is additionally guarded against big-endian hosts (making the other guards unnecessary).

Rather than add big-endian hosts (like sparc) one by one to every sub-test, it seems better to disable the whole test on big-endian.

Tested on sparc64-unknown-linux-gnu and x86_64-pc-linux-gnu.

---

Full diff: https://github.com/llvm/llvm-project/pull/102755.diff

1 Files Affected:

• (modified) llvm/unittests/tools/llvm-exegesis/X86/SubprocessMemoryTest.cpp (+5-19)

diff --git a/llvm/unittests/tools/llvm-exegesis/X86/SubprocessMemoryTest.cpp b/llvm/unittests/tools/llvm-exegesis/X86/SubprocessMemoryTest.cpp
index 7c23e7b7e9c5a5..b6dfca2da6c625 100644
--- a/llvm/unittests/tools/llvm-exegesis/X86/SubprocessMemoryTest.cpp
+++ b/llvm/unittests/tools/llvm-exegesis/X86/SubprocessMemoryTest.cpp
@@ -24,7 +24,9 @@
 namespace llvm {
 namespace exegesis {
 
-#if defined(__linux__) && !defined(__ANDROID__)
+// The tests are only supported on little endian systems.
+#if defined(__linux__) && !defined(__ANDROID__) &&                             \
+    __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
 
 // This needs to be updated anytime a test is added or removed from the test
 // suite.
@@ -77,20 +79,12 @@ class SubprocessMemoryTest : public X86TestBase {
 // memory calls not working in some cases, so they have been disabled.
 // TODO(boomanaiden154): Investigate and fix this issue on PPC.
 
-#if defined(__powerpc__) || defined(__s390x__)
-TEST_F(SubprocessMemoryTest, DISABLED_OneDefinition) {
-#else
 TEST_F(SubprocessMemoryTest, OneDefinition) {
-#endif
   testCommon({{"test1", {APInt(8, 0xff), 4096, 0}}}, 0);
   checkSharedMemoryDefinition(getSharedMemoryName(0, 0), 4096, {0xff});
 }
 
-#if defined(__powerpc__) || defined(__s390x__)
-TEST_F(SubprocessMemoryTest, DISABLED_MultipleDefinitions) {
-#else
 TEST_F(SubprocessMemoryTest, MultipleDefinitions) {
-#endif
   testCommon({{"test1", {APInt(8, 0xaa), 4096, 0}},
               {"test2", {APInt(8, 0xbb), 4096, 1}},
               {"test3", {APInt(8, 0xcc), 4096, 2}}},
@@ -100,11 +94,7 @@ TEST_F(SubprocessMemoryTest, MultipleDefinitions) {
   checkSharedMemoryDefinition(getSharedMemoryName(1, 2), 4096, {0xcc});
 }
 
-#if defined(__powerpc__) || defined(__s390x__)
-TEST_F(SubprocessMemoryTest, DISABLED_DefinitionFillsCompletely) {
-#else
 TEST_F(SubprocessMemoryTest, DefinitionFillsCompletely) {
-#endif
   testCommon({{"test1", {APInt(8, 0xaa), 4096, 0}},
               {"test2", {APInt(16, 0xbbbb), 4096, 1}},
               {"test3", {APInt(24, 0xcccccc), 4096, 2}}},
@@ -117,12 +107,7 @@ TEST_F(SubprocessMemoryTest, DefinitionFillsCompletely) {
   checkSharedMemoryDefinition(getSharedMemoryName(2, 2), 4096, Test3Expected);
 }
 
-// The following test is only supported on little endian systems.
-#if defined(__powerpc__) || defined(__s390x__) || __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
-TEST_F(SubprocessMemoryTest, DISABLED_DefinitionEndTruncation) {
-#else
 TEST_F(SubprocessMemoryTest, DefinitionEndTruncation) {
-#endif
   testCommon({{"test1", {APInt(48, 0xaabbccddeeff), 4096, 0}}}, 3);
   std::vector<uint8_t> Test1Expected(512, 0);
   // order is reversed since we're assuming a little endian system.
@@ -150,7 +135,8 @@ TEST_F(SubprocessMemoryTest, DefinitionEndTruncation) {
   checkSharedMemoryDefinition(getSharedMemoryName(3, 0), 4096, Test1Expected);
 }
 
-#endif // defined(__linux__) && !defined(__ANDROID__)
+#endif // defined(__linux__) && !defined(__ANDROID__) && __BYTE_ORDER__ ==
+       // __ORDER_LITTLE_ENDIAN__
 
 } // namespace exegesis
 } // namespace llvm

[boomanaiden154]

There is only one test here that should actually be dependent on endianness (the one marked explicitly).

I've never run this test on a big-endian system myself to debug, so I can't say for sure, but I would suspect that there is a different issue (the zero value is really suspicious from your test failures)

Ultimately though, this test is for functionality that is only enabled on x86_64. I'd rather not carve out x86_64 specifically to prevent people missing this on bringup though.

I'm not opposed to this patch, but I'd probably prefer a carve out specific to Sparc pending more investigation.

[rorth]

There is only one test here that should actually be dependent on endianness (the one marked explicitly).

I've never run this test on a big-endian system myself to debug, so I can't say for sure, but I would suspect that there is a different issue (the zero value is really suspicious from your test failures)

I see. I'd rather not try this myself since I've just spent 3 days digging through a large and completely unfamilier part of the code base to fix two failing tests.

Ultimately though, this test is for functionality that is only enabled on x86_64. I'd rather not carve out x86_64 specifically to prevent people missing this on bringup though.

I'm not opposed to this patch, but I'd probably prefer a carve out specific to Sparc pending more investigation.

So would it be ok to move the !(powerpc || s390x || sparc) check up as in the revised patch?

[boomanaiden154]

LGTM.

[rorth]

/cherry-pick a417083

[llvmbot]

/pull-request #102771

[llvm-ci]

LLVM Buildbot has detected a new failure on builder openmp-s390x-linux running on systemz-1 while building llvm at step 6 "test-openmp".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/88/builds/1656

Here is the relevant piece of the build log for the reference:

Step 6 (test-openmp) failure: test (failure)
******************** TEST 'libomp :: tasking/issue-94260-2.c' FAILED ********************
Exit Code: -11

Command Output (stdout):
--
# RUN: at line 1
/home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/./bin/clang -fopenmp   -I /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/runtimes/runtimes-bins/openmp/runtime/src -I /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.src/openmp/runtime/test -L /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/runtimes/runtimes-bins/openmp/runtime/src  -fno-omit-frame-pointer -mbackchain -I /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.src/openmp/runtime/test/ompt /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.src/openmp/runtime/test/tasking/issue-94260-2.c -o /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/runtimes/runtimes-bins/openmp/runtime/test/tasking/Output/issue-94260-2.c.tmp -lm -latomic && /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/runtimes/runtimes-bins/openmp/runtime/test/tasking/Output/issue-94260-2.c.tmp
# executed command: /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/./bin/clang -fopenmp -I /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/runtimes/runtimes-bins/openmp/runtime/src -I /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.src/openmp/runtime/test -L /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/runtimes/runtimes-bins/openmp/runtime/src -fno-omit-frame-pointer -mbackchain -I /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.src/openmp/runtime/test/ompt /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.src/openmp/runtime/test/tasking/issue-94260-2.c -o /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/runtimes/runtimes-bins/openmp/runtime/test/tasking/Output/issue-94260-2.c.tmp -lm -latomic
# executed command: /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/runtimes/runtimes-bins/openmp/runtime/test/tasking/Output/issue-94260-2.c.tmp
# note: command had no output on stdout or stderr
# error: command failed with exit status: -11

--

********************