search for: gnux32

.../reviews.llvm.org/D20916, I stumbled across some code affecting ARM and X86_64 environments that looks like it might be unintentional. I thought I should ask about it here since that patch has a '[mips]' tag and therefore might not be noticed by someone who knows. I've noticed that the GNUX32 and GNUEABI/GNUEABIHF environments don't make use of the sincos libcall like the GNU environment does because the guarding condition for this is 'TT.getEnvironment() == Triple::GNU'. The comment in canCombineSinCosLibcall() in LegalizeDAG.cpp suggests that it's intending to use sinc...

...rrent work is based on: * what’s currently done in trunk (some changes required for x32 are already there) * Michael Liao work done ~2 years ago and available here: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120604/058450.html What’s currently in trunk: * Triplet x86_64-*-linux-gnux32 (command line support, EnvironmentType enum to differentiate x32 from x86_64 by getTriple().getEnvironment() == llvm::Triple::GNUX32) https://github.com/llvm-mirror/llvm/commit/9dd2a3b1f2c253e20262535bb89b1ab6cc680ece * ILP32/LP64 differentiation for TargetMachine https://github.com/llvm-mirror/llv...

...computeTargetTriple(StringRef DefaultTargetTriple, if (Target.getArch() == llvm::Triple::ppc) Target.setArch(llvm::Triple::ppc64); } + } else if (Args.getLastArg(options::OPT_mx32)) { + if (Target.getArch() == llvm::Triple::x86_64) + Target.setEnvironment(llvm::Triple::GNUX32); } return Target; --- ./tools/clang/lib/Basic/Targets.cpp.orig 2013-08-18 12:00:04.501402572 +0000 +++ ./tools/clang/lib/Basic/Targets.cpp 2013-08-18 12:08:11.086175660 +0000 @@ -2384,6 +2384,14 @@ Builder.defineMacro("__amd64"); Builder.defineMacro("__x86_64"...

...ges in trunk, and hacked together handling of x32 "ARCH" support for compiler-rt. (there must be a better way??) Unfortunately, although the build succeeds as far as beginning to build compiler-rt the resulting clang doesn't seem to respect the fact that the target is x86_64-pc-linux-gnux32, nor that the "-mx32" opt has been supplied. Something is clearly missing. Can somebody please take a look at the patches, and look to see what I'm missing/where I've gone wrong, or otherwise point me to a working patchset/repo if I'm duplicating effort. Patches to follow.....

...} @@ -3013,20 +3021,31 @@ class X86_64TargetInfo : public X86TargetInfo { public: X86_64TargetInfo(const llvm::Triple &Triple) : X86TargetInfo(Triple) { - LongWidth = LongAlign = PointerWidth = PointerAlign = 64; + const bool IsX32 = (getTriple().getEnvironment() == llvm::Triple::GNUX32); + LongWidth = LongAlign = PointerWidth = PointerAlign = IsX32 ? 32 : 64; LongDoubleWidth = 128; LongDoubleAlign = 128; LargeArrayMinWidth = 128; LargeArrayAlign = 128; SuitableAlign = 128; - IntMaxType = SignedLong; - UIntMaxType = UnsignedLong; - Int64Type =...

...try to get your patch for (b) submitted. > Let's move the > discussion to that thread, most likely you'll have to add tests and find a > reviewer for that patch. > Actually, I've just fixed a bug where when running on a x32 host the Environment part of the Triple is always GNUX32, I've now changed it so that it gets properly set to GNU. This *fixes* the -m64 case, since otherwise it *always* tries to compile to ILP32 except for some reason the object ends up as elf_x86_64, not sure why yet... (can anybody help here?) The -m32 case worked because then the Arch component...

...ef [ID=2] 0x30cc518: i32 = X86ISD::WrapperRIP 0x30ccab8 [ID=6] 0x30ccab8: i32 = TargetJumpTable<0> [ID=3] In function: __atomic_compare_exchange clang: error: clang frontend command failed with exit code 70 (use -v to see invocation) clang version 3.4 (trunk) Target: x86_64-pc-linux-gnux32 Thread model: posix This is what happens when compiling compiler-rt with -m64 or -mx32, exact same error without my patches (where -mx32 is supported). However, I know -mx32 isn't working since the objects always end up elf_x86_64, which is why I known this is a somewhat unrelated bug.

Ah, I've replied in a different thread already. What Dmitri says - If you're interesting in only building the Clang on x32 host, you may avoid checking out compiler-rt repo for now. On Thu, Aug 22, 2013 at 10:59 AM, Dmitri Gribenko <gribozavr at gmail.com>wrote: > On Wed, Aug 21, 2013 at 11:04 PM, Steven Newbury <steve at snewbury.org.uk> > wrote: > > I've

On Thu, Aug 22, 2013 at 11:56 AM, Steven Newbury <steve at snewbury.org.uk>wrote: > On Thu, 2013-08-22 at 11:50 +0400, Alexey Samsonov wrote: > > On Thu, Aug 22, 2013 at 11:39 AM, Steven Newbury <steve at snewbury.org.uk > >wrote: > > > > > On Thu, 2013-08-22 at 11:27 +0400, Alexey Samsonov wrote: > > > > Hi Steven, > > > > > >

...? Would that be sufficient? > > Sounds good to me. > Been chatting with jfb on irc. It seems Google NaCl has all the needed changes to get LLVM to work with x32, in addition to their other requirements, so I'm going to go through their changes and make relevant parts conditional on GNUX32. Then when their code lands which they hope won't be too long x32 will come for free.

On Thu, Aug 22, 2013 at 7:56 AM, Steven Newbury <steve at snewbury.org.uk> wrote: > If I'm going to submit the Clang patch, how should it be submitted? One > patch with what's required to get x32 host to work, then another > enabling x32 code generation once the required changes to llvm are > merged? Would that be sufficient? Sounds good to me. Dmitri --

On Thu, 2013-08-22 at 11:50 +0400, Alexey Samsonov wrote: > On Thu, Aug 22, 2013 at 11:39 AM, Steven Newbury <steve at snewbury.org.uk>wrote: > > > On Thu, 2013-08-22 at 11:27 +0400, Alexey Samsonov wrote: > > > Hi Steven, > > > > > > This looks interesting and raises a number of questions :) > > > > > > 1) Does applying this patch

On Thu, 2013-08-22 at 15:22 +0100, Steven Newbury wrote: > This patch is still not creating elf32_x86_64 objects. No idea > why. :( It does however, fix elf_x86_64 (-m64) code generation on x32 > hosts which is nice. :) I know why. I had assumed Michael Liao (the original patch author) had submitted all the _LLVM_ x32 support as separate patches, and it was just the

...ch I'm using is to encode the ABI information into the triple in the same way that ARM does for EABI and hardfloat, and the same way that X86 does for X32. These targets define variants of Triple::GNU for each of these ABI's in the form of the Triple::GNUEABI, Triple::GNUEABIHF, and Triple::GNUX32 values of the environment component of the triple and it's up to the frontend and/or API-user to pass the right thing to the backend. For MIPS, I'm defining Triple::GNUABI32, Triple::GNUABIN32, and Triple::GNUABI64. All three of these are supported by tools like binutils (by virtue of a wi...

...ch I'm using is to encode the ABI information into the triple in the same way that ARM does for EABI and hardfloat, and the same way that X86 does for X32. These targets define variants of Triple::GNU for each of these ABI's in the form of the Triple::GNUEABI, Triple::GNUEABIHF, and Triple::GNUX32 values of the environment component of the triple and it's up to the frontend and/or API-user to pass the right thing to the backend. For MIPS, I'm defining Triple::GNUABI32, Triple::GNUABIN32, and Triple::GNUABI64. All three of these are supported by tools like binutils (by virtue of a wi...

https://bugzilla.mindrot.org/show_bug.cgi?id=3085 Bug ID: 3085 Summary: seccomp issue after upgrading openssl Product: Portable OpenSSH Version: 8.1p1 Hardware: Other OS: Linux Status: NEW Severity: critical Priority: P5 Component: sshd Assignee: unassigned-bugs at mindrot.org

Hello, I'm trying to create a pure LLVM toolchain (that will not depend on GNU and produce GNU-free code too) on a musl based distribution. For now, I use gcc to bootstrap and build all LLVM components. I do it individually because I was running out of space and memory trying to build all using LLVM_ENABLE_PROJECTS. Also, I don't want to create a all-in-one package. Then, once

Hello LLVM Developers, Within Google, we have a growing range of needs that existing libc implementations don't quite address. This is pushing us to start working on a new libc implementation. Informal conversations with others within the LLVM community has told us that a libc in LLVM is actually a broader need, and we are increasingly consolidating our toolchains around LLVM. Hence, we