Hello
I think, because this is a unit-test, the compile will happen for the host 
(x86_64 in this case). So the binary will still be x86_64.


The compile that the test runs will pick up whatever the default target triple 
is (hexagon for the bot, aarch64 for us). I don't know a lot about these tests, 
but I presume that somewhere deep within testStructuralMatch or makeNamedDecls 
it will be picking this up and we can override it?


..


Looking at it now, I think the Args to buildASTFromCodeWithArgs will allow 
specific targets to be used. I'm not sure the best way to get that information 
through to there, but something like this would work:


diff --git a/unittests/AST/StructuralEquivalenceTest.cpp 
b/unittests/AST/StructuralEquivalenceTest.c
index e6c289a..52dba5e 100644
--- a/unittests/AST/StructuralEquivalenceTest.cpp
+++ b/unittests/AST/StructuralEquivalenceTest.cpp
@@ -28,6 +28,7 @@ struct StructuralEquivalenceTest : ::testing::Test {
     this->Code0 = SrcCode0;
     this->Code1 = SrcCode1;
     ArgVector Args = getBasicRunOptionsForLanguage(Lang);
+    Args.push_back("--target=x86_64-unknown-linux-gnu");

     const char *const InputFileName = "input.cc";


I wouldn't recommend that, exactly, it would needlessly reduce the testing on 
other targets. And I think for the hexagon target the x86 backend will not even 
be registered I believe. Perhaps just something like this from another 
ASTMatchesNode test, to try and capture the same intent as the ifdefs:


TEST_F(StructuralEquivalenceFunctionTest, FunctionsWithDifferentSavedRegsAttr) {

  if (llvm::Triple(llvm::sys::getDefaultTargetTriple()).getArch() != 
llvm::Triple::x86_64)
    return;
  ...


Dave



> Hi,
>
> Thank you for catching this. I thought that the macros like __x86_64__ are 
> defined for the target. I just don't understand: If they are defined for the 
> host, > that would mean we can't cross compile on the same host for different 
> targets, wouldn't it?
>
> I couldn't find out which macros to use to get the target arch, so I see 2 
> possible solutions :
> 1. Create a new test binary for these two small tests and specify explicitly 
> the target. This seems overwhelming.
> 2. Simply remove those two test cases. This seems to be the simplest solution.
>
> Gábor

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to