Missing the consideration of calling conversion in around 81 clang regression tests.

Dear All,

I would like to discuss clang regression tests that will fail on targets that set specific calling conventions.

For example, in Clang :: CodeGen/builtinshufflevector2.c:

Expected IR:

“define void @clang_shufflevector_v_v

IR generated with a default triple of armv7a_pc_linux:

“define arm_aapcs void @clang_shufflevector_v_v

The test could be changed to expect “define{{.*}} void
@clang_shufflevector_v_v”.

For ARM target with default triple armv7a_pc_linux, around 81 clang
regression tests failed due to the same reason. It includes CodeGen,
CodeGenCXX, CodeGenObjC, CodeGenObjCXX, CodeGenOpenCL, Modules, OpenMP,
PCH, Profile and Sema tests.

Would appreciate advice on whether I should generate a patch for this?

Many thanks,

Ying

Dear All,

I would like to discuss clang regression tests that will fail on targets
that set specific calling conventions.

For example, in Clang :: CodeGen/builtinshufflevector2.c:

Expected IR:

"define void @clang_shufflevector_v_v"

IR generated with a default triple of armv7a_pc_linux:

"define arm_aapcs void @clang_shufflevector_v_v"

The test could be changed to expect "define{{.*}} void
@clang_shufflevector_v_v".

For ARM target with default triple armv7a_pc_linux, around 81 clang
regression tests failed due to the same reason. It includes CodeGen,
CodeGenCXX, CodeGenObjC, CodeGenObjCXX, CodeGenOpenCL, Modules, OpenMP,
PCH, Profile and Sema tests.

Would appreciate advice on whether I should generate a patch for this?

I think that's a reasonable thing to change/fix. I believe the intent is
that the tests should pass when run on any supported (sort of by
definition) target.

Hello David,

Thanks for your advice. I will prepare a patch for this issue and send to cfe-commits for review.

Kind Regards,

Ying