[RFC] Fix Clang test case failure on ARM

Clang Frontend
1

Hi all,

  I am a LLVM 3.1 tester and running tests on ARM. A few clang test failures
can be avoided by adding target-specific triple, but I am not sure if this is
the correct solution.

1. Use "-triple x86_64-none-linux-gnu" makes failures below disappered. If no
   one against this solution, I'll prepare a patch.

  Clang :: CodeGenCXX/compound-literals.cpp
  Clang :: CodeGenCXX/copy-constructor-elim-2.cpp
  Clang :: CodeGenCXX/cxx0x-initializer-references.cpp
  Clang :: CodeGenCXX/cxx0x-initializer-stdinitializerlist-startend.cpp
  Clang :: CodeGenCXX/virt-call-offsets.cpp
  Clang :: CodeGenCXX/x86-64-abi-sret-vs-2word-struct-param.cpp
  Clang :: CodeGenCXX/cxx0x-initializer-stdinitializerlist.cpp

2. Use "-triple x86_64-none-linux-gnu" makes failure below disappered, too.
   But Chandler think tests under CXX/ should be platform independent. We
   either move p15-inclass.cpp to CodeGenCXX/ , or make "linkonce_odr"
   ptional in FileCheck so it's not platform dependent.

  Clang :: CXX/special/class.copy/p15-inclass.cpp

3. Although "-fshort-wchar" makes the error below disappered, Chandler think
   the test itslef is NOT fulfill the C++ standard, so this could be a bug
   in the test not in clang.

  Clang :: CXX/conv/conv.prom/p2.cpp

4. James suggust me to raise a PR for the test case below. How this test case
   is ran and what the error message is can be found in [1].

  Sema/arm-neon-types.c

  Any comments or sugguestions? Thanks! :slight_smile:

Regards,
chenwj

[1] http://people.cs.nctu.edu.tw/~chenwj/tmp/phase3-regression-test.txt

2

Hi all,

I am a LLVM 3.1 tester and running tests on ARM. A few clang test failures
can be avoided by adding target-specific triple, but I am not sure if this is
the correct solution.

1. Use "-triple x86_64-none-linux-gnu" makes failures below disappered. If no
one against this solution, I'll prepare a patch.

Clang :: CodeGenCXX/compound-literals.cpp
Clang :: CodeGenCXX/copy-constructor-elim-2.cpp
Clang :: CodeGenCXX/cxx0x-initializer-references.cpp
Clang :: CodeGenCXX/cxx0x-initializer-stdinitializerlist-startend.cpp
Clang :: CodeGenCXX/virt-call-offsets.cpp
Clang :: CodeGenCXX/x86-64-abi-sret-vs-2word-struct-param.cpp
Clang :: CodeGenCXX/cxx0x-initializer-stdinitializerlist.cpp

Often for C++, FileCheck tests over IR fail to match because of the
slightly different C++ ABI rules (among other things, constructors
have a slightly different signature). Often it's easy to fix the
tests to work on all platforms; if it's straightforward, please do,
otherwise specifying a triple is fine.

2. Use "-triple x86_64-none-linux-gnu" makes failure below disappered, too.
But Chandler think tests under CXX/ should be platform independent. We
either move p15-inclass.cpp to CodeGenCXX/ , or make "linkonce_odr"
ptional in FileCheck so it's not platform dependent.

Err, is that why it isn't matching? I would have assumed that the
'void' isn't matching rather than the linkonce_odr.

Moving the test to CodeGenCXX is independent of that, but that would
be okay, I guess.

Clang :: CXX/special/class.copy/p15-inclass.cpp

3. Although "-fshort-wchar" makes the error below disappered, Chandler think
the test itslef is NOT fulfill the C++ standard, so this could be a bug
in the test not in clang.

Yes... that's just a bug in the test; I didn't realize some platforms
define wchar_t as 'long'. Probably just specifying a triple is the
right thing to do here.

Clang :: CXX/conv/conv.prom/p2.cpp

4. James suggust me to raise a PR for the test case below. How this test case
is ran and what the error message is can be found in [1].

Sema/arm-neon-types.c

Yes, please file; that's a bit mysterious.

-Eli

3

Hi Eli,

> Clang :: CodeGenCXX/virt-call-offsets.cpp

  Below is the difference of x86 and arm output.

x86:
  @x = global { i64, i64 } { i64 1, i64 0 }" align 8

arm:
  @x = global { i32, i32 } { i32 0, i32 1 }, align 4

According to TNorthover on IRC, this could be x86 and ARM C++ ABI difference on
member function pointers (Sec. 3.2.1 in [1]), so both of them are correct. I am
not sure how to write the correct pattern for x86 and arm. The pattern below is
O.K. for x86 and arm, but I think this pattern doesn't guarantee the order (1, 0)
and (0, 1) for x86 and arm respectively, which means "{ i32 0, i32 0 }" pass, too.

// CHECK: @x = global { i{{[0-9]+}}, i{{[0-9]+}} } { i{{[0-9]+}} {{0|1}}, i{{[0-9]+}} {{1|0}} }

Any idea on how to make the pattern better? Thanks.

Regards,
chenwj

[1]

4

// CHECK: @x = global { i{{[0-9]+}}, i{{[0-9]+}} } { i{{[0-9]+}} {{0|1}}, i{{[0-9]+}} {{1|0}} }

Any idea on how to make the pattern better? Thanks.

As I recall the file is nice and small. I'd go for two separate RUN
lines: one specifying an x86 triple and looking for its form and one
specifying an ARM triple and looking for the other one.

Sorry, I probably should have thought a bit more and said that on IRC.

Tim.

5

Hi,

Personally, I'd create a new RUN line, and have one run as x86 and the
other as ARM.

That would mean you could be strict in the pattern match still and not
relax it and deal with the fallout of false positives.

Cheers,

James