Nikola reports failing to configure compiler-rt on 32-bit OpenSUSE and Fedora with CMake. On Fedora, gcc targets i686 so the first stage (building compiler-rt and clang) of a bootstrap build succeeds. But the second stage (building with the newly built clang) fails, because Clang does not define __i686__. clang --version says it targets i686-pc-linux-gnu, but it doesn't define __i686__. On my regular x86_64 workstation, it doesn't work either: $ bin/clang -target i686-pc-linux-gnu -v Prints "Target: i686-pc-linux-gnu" as expected, but: $ bin/clang -target i686-pc-linux-gnu -dM -E -c /tmp/a.c | grep i.*86 Only prints __i386__, __i386 and i386. Isn't Clang supposed to define __i686__ when targeting i686? Am I holding it wrong? Is compiler-rt checking the wrong thing? On OpenSUSE, even Phase1 fails, because the system gcc is targeting i586 instead of i686: gcc -v prints i586-suse-linux. It defines __i386__ and __i586__. I suppose that's a different kind of bug, but it also seems related. I have VMs for 32-bit OpenSUSE and Fedora set up. Let me know if I can help debugging.
Regarding OpenSUSE issue: could you check LLVM_DEFAULT_TARGET_TRIPLE in CMakeCache.txt in the build? Looks like it incorrectly states i686-linux-gnu, while the actual target arch should be i586. This is calculated by running autoconf/config.guess. What does it say on that machine? As for Fedora issue - it looks pretty weird that Clang says to target i686, but doesn't define corresponding macros. I can think of a possible workaround for this issue, though - we have a FATAL_ERROR diagnostic to report the fact that we can't target the triple specified in COMPILER_RT_TEST_TARGET_TRIPLE CMake cache variable. We may restrict this diagnostic only to the case when this variable was actually explicitly specified by the user (i.e. doesn't match inferred host triple). Let me know if you would like to proceed with it before fixing the i586/i686 issues.
(In reply to comment #1) > Regarding OpenSUSE issue: could you check LLVM_DEFAULT_TARGET_TRIPLE in > CMakeCache.txt in the build? Looks like it incorrectly states > i686-linux-gnu, while the actual target arch should be i586. This is > calculated by running autoconf/config.guess. What does it say on that > machine? Both LLVM_DEFAULT_TARGET_TRIPLE and config.guess say i686-pc-linux-gnu.
(In reply to comment #1) > I can think of a possible workaround for this issue, though - we have a > FATAL_ERROR diagnostic to report the fact that we can't target the triple > specified in COMPILER_RT_TEST_TARGET_TRIPLE CMake cache variable. We may > restrict this diagnostic only to the case when this variable was actually > explicitly specified by the user (i.e. doesn't match inferred host triple). > Let me know > if you would like to proceed with it before fixing the i586/i686 issues. I've submitted this workaround in r243170. This should at least fix build problems (by just excluding compiler-rt runtimes from the build, yes).
$ clang -target i686-pc-linux-gnu -march=i686 Does define __i686__. -march=native doesn't define it :-( It's strange that it doesn't choose i686 as the CPU type from the triple (this all happens in lib/Basic/Targets.cpp). Is that what gcc does? Maybe compiler-rt's build should pass -march=i686?
r243170 gets the build past the configure step, but it seems it's still trying to build tests for for i686. It failed with this link error: /usr/lib/gcc/i586-suse-linux/4.8/../../../../i586-suse-linux/bin/ld: cannot find /home/hans/branches_release_37/Phase3/Release/llvmCore-test-branches_release_37.obj/bin/../lib/clang/3.7.0/lib/linux/libclang_rt.asan-i686.a: No such file or directory /usr/lib/gcc/i586-suse-linux/4.8/../../../../i586-suse-linux/bin/ld: cannot find /home/hans/branches_release_37/Phase3/Release/llvmCore-test-branches_release_37.obj/bin/../lib/clang/3.7.0/lib/linux/libclang_rt.asan_cxx-i686.a: No such file or directory clang-3.7: error: linker command failed with exit code 1 (use -v to see invocation) projects/compiler-rt/lib/asan/tests/CMakeFiles/Asan-i386-with-calls-Test.dir/build.make:58: recipe for target 'projects/compiler-rt/lib/asan/tests/CMakeFiles/Asan-i386-with-calls-Test' failed
That's sad. What stage is this (i.e. what compiler is used as a host - GCC or just-built Clang)? I don't yet understand why this happens - ASAN_SUPPORTED_ARCH should define both the runtimes we build, and the tests we build. We shouldn't build the tests for i686, if no runtime for i686 was built.
That's stage 3, i.e. it's building with just-built clang (which in turn was built by clang). We don't run the tests at the other stages.
(In reply to comment #6) > That's sad. What stage is this (i.e. what compiler is used as a host - GCC > or just-built Clang)? I don't yet understand why this happens - > ASAN_SUPPORTED_ARCH should define both the runtimes we build, and the tests > we build. We shouldn't build the tests for i686, if no runtime for i686 was > built. I think what's happening is that we're building the tests for i386, but still just invoking clang with "clang -m32". And since the clang we built is targeting i686, it will try to link against the i686 version of the run-time. If I manually pass "-target i386-pc-linux-gnu" to Clang, it works. So when doing unit tests for i386 we should probably pass the full triple to make clang actually target i386, and not just -m32. The problem is we don't really know the full triple I think. But maybe we can fix the other problem, "clang not defining __i686__". If we just change test_target_arch(i686 __i686__ "-m32") to test_target_arch(i686 __i686__ "-m32 -march=i686") things might start working. I'll give that a try.
My fix didn't go so well :-( Seems it broke things mysteriously on both Mac and x86_64 Linux: https://llvm.org/bugs/show_bug.cgi?id=24312
This is not a regression from 3.6; it's just that we didn't use to build and run these tests as part of the release process before. IIRC, this bug now manifests as failures during testing, not a build failure. I won't consider this a blocker for 3.7.