User Details
- User Since
- Aug 13 2019, 4:58 AM (87 w, 12 h)
Yesterday
Fri, Apr 9
Thu, Apr 8
Ah, that looks at first glance like not a compiler-rt problem but a clang problem, it will need to be taught the correct target name for x32 as well. If I'm right, that should be easy to fix, I can take a look later today or tomorrow.
Tue, Apr 6
I think x32 is not really supported by compiler-rt.
Does this change mean the various *_SUPPORTED_ARCH need updating to list x32 as supported too, or are those handled separately?
Thu, Apr 1
Wed, Mar 31
I have also updated the summary to provide a more complete explanation of the changes, and hope the revised summary will answer @MaskRay's questions.
Tests now updated differently, avoiding the need to explicitly list libx32 as an allowed libdir. In clang/test/Preprocessor/iwithprefix.c's case, for the purposes of the test, it is not necessary to look at what appears before /clang/. In the other tests, it is possible to capture the -resource-dir string and use that.
This updates the diff as described, plus includes test suite changes needed to make check-clang pass. The changes to clang/test/Driver/Inputs/basic_cross_linux_tree/usr are because we now correctly detect that a x86_64 GCC directory that does not include x32 files cannot be used to target x32.
Feel free to update the diff here with your suggested patch.
Tue, Mar 30
If that were the reason, why are we not using the last GPLv2 version of config.guess, rather than the one that we happened to use back when we had an autoconf build system?
I think the problem is actually the other thing covered before (don't provide un-normalised triples as cmake arguments), though the wrong detection of LLVM_HOST_TRIPLE will cause other issues too. If we would just update config.guess, the default configuration (not specifying either LLVM_HOST_TRIPLE or LLVM_DEFAULT_TARGET_TRIPLE) should work much better; I have created D99625 for that.
I am building with
I am testing the below, on top of c8e56f394af0b9e32c413d62a0e7aebbba3e6b70, both in a Debian chroot and in my non-Debian system. Initial testing in the Debian chroot suggests that this works for simple cases, clang has no problem finding /usr/lib/gcc/x86_64-linux-gnux32/10, and also picks up the right crt*.o files when using -m32 or -m64. Will do more extensive testing.
--- a/clang/lib/Driver/ToolChains/Gnu.cpp +++ b/clang/lib/Driver/ToolChains/Gnu.cpp @@ -2106,7 +2106,10 @@ void Generic_GCC::GCCInstallationDetector::AddDefaultGCCPrefixes( "x86_64-manbo-linux-gnu", "x86_64-linux-gnu", "x86_64-slackware-linux", "x86_64-unknown-linux", "x86_64-amazon-linux", "x86_64-linux-android"}; - static const char *const X32LibDirs[] = {"/libx32"}; + static const char *const X32Triples[] = { + "x86_64-linux-gnux32", "x86_64-unknown-linux-gnux32", + "x86_64-pc-linux-gnux32"}; + static const char *const X32LibDirs[] = {"/libx32", "/lib"}; static const char *const X86LibDirs[] = {"/lib32", "/lib"}; static const char *const X86Triples[] = { "i586-linux-gnu", "i686-linux-gnu", @@ -2337,17 +2340,19 @@ void Generic_GCC::GCCInstallationDetector::AddDefaultGCCPrefixes( TripleAliases.append(begin(AVRTriples), end(AVRTriples)); break; case llvm::Triple::x86_64: - LibDirs.append(begin(X86_64LibDirs), end(X86_64LibDirs)); - TripleAliases.append(begin(X86_64Triples), end(X86_64Triples)); - // x32 is always available when x86_64 is available, so adding it as - // secondary arch with x86_64 triples if (TargetTriple.getEnvironment() == llvm::Triple::GNUX32) { - BiarchLibDirs.append(begin(X32LibDirs), end(X32LibDirs)); + LibDirs.append(begin(X32LibDirs), end(X32LibDirs)); + TripleAliases.append(begin(X32Triples), end(X32Triples)); + BiarchLibDirs.append(begin(X86_64LibDirs), end(X86_64LibDirs)); BiarchTripleAliases.append(begin(X86_64Triples), end(X86_64Triples)); } else { - BiarchLibDirs.append(begin(X86LibDirs), end(X86LibDirs)); - BiarchTripleAliases.append(begin(X86Triples), end(X86Triples)); + LibDirs.append(begin(X86_64LibDirs), end(X86_64LibDirs)); + TripleAliases.append(begin(X86_64Triples), end(X86_64Triples)); + BiarchLibDirs.append(begin(X32LibDirs), end(X32LibDirs)); + BiarchTripleAliases.append(begin(X32Triples), end(X32Triples)); } + BiarchLibDirs.append(begin(X86LibDirs), end(X86LibDirs)); + BiarchTripleAliases.append(begin(X86Triples), end(X86Triples)); break; case llvm::Triple::x86: LibDirs.append(begin(X86LibDirs), end(X86LibDirs)); @@ -2357,6 +2362,8 @@ void Generic_GCC::GCCInstallationDetector::AddDefaultGCCPrefixes( TripleAliases.append(begin(X86Triples), end(X86Triples)); BiarchLibDirs.append(begin(X86_64LibDirs), end(X86_64LibDirs)); BiarchTripleAliases.append(begin(X86_64Triples), end(X86_64Triples)); + BiarchLibDirs.append(begin(X32LibDirs), end(X32LibDirs)); + BiarchTripleAliases.append(begin(X32Triples), end(X32Triples)); } break; case llvm::Triple::m68k:
I may be missing something, but I do not understand the problem. What systems, other than Debian multi-arch, are you looking to also add support for? My own native x32 system uses (/usr)/libx32 for x32 libraries. Debian uses (/usr)/lib/x86_64-linux-gnux32. I can understand if some people might use (/usr)/lib without any x32 suffix, though I am not aware of anyone doing this. Where does lib32 come from, though? What other systems are you trying to account for?
Jan 30 2021
Jan 27 2021
@rnk Taking it upon yourself to revert this without approval and without communication on all branches, especially given the earlier suggestion by @rsmith to only revert this on the LLVM 12 branch, is an abuse of your commit privileges as far as I am concerned. This is not a Google project. Google does not get to unilaterally dictate its direction. I do not intend to get into a revert-the-revert war and will not revert your revert myself. I do expect you to do so.
Jan 26 2021
Restoring the old behaviour for clang 12 may or may not help the Chrome/Chromium people: if they also regularly build with clang from git, they would need to handle this change anyway. However, if it does help, then it sounds like a good idea to me.
Jan 25 2021
Okay, GCC enables the standards-mandated behaviour with -std=c++17 -fms-extensions as well, but GCC doesn't have any -fms-compatibility option to compare. It makes sense to me for clang -std=c++17 -fms-compatibility to match MSVC, and MSVC supports this GCC extension even in those cases where it conflicts with the standard, so I'll try to submit a patch to restore this, conditional on -fms-compatibility, later today.
Jan 24 2021
Ping 2
Ping 4
Jan 11 2021
Ping
Ping 3
Dec 22 2020
Dec 21 2020
Ping 2
Dec 20 2020
Dec 18 2020
Merge ELF/got-relaxed-rex.s into X86/gotpcrelx.s, update lld/test/ELF/x86-64-gotpc-relax-nopic.s.
I accidentally pushed this with the original commit message as 2aae2136, causing a missing link to/from this review. Manually linking this here now.
Dec 16 2020
Be consistent in CHECK lines.
Rename parameter, split addl/leal check in two.
Dec 15 2020
Dec 14 2020
Dec 13 2020
Rebase again, taking the X64 changes out of the diff.
Dec 12 2020
Dec 8 2020
I've been able to check what Ubuntu 20.10 offers in terms of x32 support. Its kernel supports x32 binaries, it provides x32 versions of core system libraries in separate packages (e.g. libc6-x32, libx32stdc++6, libx32z1), and it provides a compiler that targets x32 by default (gcc-x86-64-linux-gnux32). These Ubuntu packages do not use the Debian/Ubuntu multiarch approach: the packages are completely independent of the corresponding x64 and i386 versions with separate names, and nothing in Ubuntu installs any libraries into any /lib/x86_64-linux-gnux32-like path. They are intended to allow x32 cross compilation on an Ubuntu system, not intended to act as a basis for running an x32 Ubuntu system. This appears to be very different from Debian's x32 support. That said, cross-compiled binaries do run on Ubuntu and it should be possible to build an x32-native LLVM with the Ubuntu-provided toolchain.
Dec 7 2020
Renamed is* parameters to Is*.
Dec 6 2020
Ping