New user self-registration is disabled due to spam. For an account please email bugs-admin@lists.llvm.org with your e-mail address and full name.

Bug 24222 - compiler-rt cmake configure fails on 32-bit systems
Summary: compiler-rt cmake configure fails on 32-bit systems
Status: NEW
Alias: None
Product: new-bugs
Classification: Unclassified
Component: new bugs (show other bugs)
Version: trunk
Hardware: PC Linux
: P normal
Assignee: Unassigned LLVM Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-22 16:10 PDT by Hans Wennborg
Modified: 2015-08-18 16:32 PDT (History)
3 users (show)

See Also:
Fixed By Commit(s):


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hans Wennborg 2015-07-22 16:10:35 PDT
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.
Comment 1 Alexey Samsonov 2015-07-23 22:55:15 PDT
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.
Comment 2 Hans Wennborg 2015-07-24 16:50:24 PDT
(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.
Comment 3 Alexey Samsonov 2015-07-24 17:01:55 PDT
(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).
Comment 4 Hans Wennborg 2015-07-24 18:07:05 PDT
$ 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?
Comment 5 Hans Wennborg 2015-07-28 19:13:13 PDT
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
Comment 6 Alexey Samsonov 2015-07-28 19:39:16 PDT
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.
Comment 7 Hans Wennborg 2015-07-28 19:53:41 PDT
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.
Comment 8 Hans Wennborg 2015-07-29 19:24:36 PDT
(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.
Comment 9 Hans Wennborg 2015-07-29 23:18:00 PDT
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
Comment 10 Hans Wennborg 2015-08-18 16:32:06 PDT
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.