Page MenuHomePhabricator

glaubitz (John Paul Adrian Glaubitz)
User

Projects

User does not belong to any projects.

User Details

User Since
Jan 30 2018, 2:05 AM (167 w, 1 d)

Recent Activity

Yesterday

glaubitz added a comment to D98537: [M68k] Implement AsmParser.

@myhsu when you get a moment, can you check that this is all OK now? :)

sorry I missed your last update. LGTM now

Tue, Apr 13, 1:05 AM · Restricted Project

Mon, Apr 12

glaubitz added a comment to D100148: [Driver] Fix compiler-rt lookup for x32.

Hi! Can we get this patch merged as-is or do we need anything else?

Sorry, miscommunication. I was thinking you could use this to update D99988 to actually build the relevant compiler-rt bits for x32, and then once both that and this are ready, both can be submitted at the same time. The reason for that is that this is not useful by itself, and if it turns out that D99988 actually requires some other clang change as well that we are not seeing yet, it will be easier to update this if it has not been pushed yet. Do you think it would be better to push this first?

Mon, Apr 12, 11:03 AM · Restricted Project
glaubitz added a comment to D100148: [Driver] Fix compiler-rt lookup for x32.

Hi! Can we get this patch merged as-is or do we need anything else?

Mon, Apr 12, 9:07 AM · Restricted Project

Fri, Apr 9

glaubitz added a comment to D100148: [Driver] Fix compiler-rt lookup for x32.

So, we only need D99988 and this one (D100148) now and the LLVM package will finally build on Debian without any additional tweaks.

Fri, Apr 9, 8:16 AM · Restricted Project
glaubitz reclaimed D99988: [compiler-rt] Add platform detection support for x32.
Fri, Apr 9, 5:24 AM · Restricted Project
glaubitz accepted D100148: [Driver] Fix compiler-rt lookup for x32.
Fri, Apr 9, 3:41 AM · Restricted Project
glaubitz added inline comments to D100148: [Driver] Fix compiler-rt lookup for x32.
Fri, Apr 9, 3:36 AM · Restricted Project
glaubitz added inline comments to D100148: [Driver] Fix compiler-rt lookup for x32.
Fri, Apr 9, 3:35 AM · Restricted Project
glaubitz added a comment to D100148: [Driver] Fix compiler-rt lookup for x32.

Thanks, this finally fixes the build for me. I wasn't aware that there was a getArchNameForCompilerRTLib() function in clang.

Fri, Apr 9, 3:33 AM · Restricted Project

Thu, Apr 8

glaubitz abandoned D99988: [compiler-rt] Add platform detection support for x32.
Thu, Apr 8, 10:02 AM · Restricted Project
glaubitz added a comment to D99988: [compiler-rt] Add platform detection support for x32.

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.

Thu, Apr 8, 9:25 AM · Restricted Project
glaubitz added a comment to D99988: [compiler-rt] Add platform detection support for x32.

Here is the error:

Thu, Apr 8, 9:18 AM · Restricted Project

Wed, Apr 7

glaubitz added a comment to D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs.

Ping.

Wed, Apr 7, 5:17 AM · Restricted Project

Tue, Apr 6

glaubitz updated subscribers of D99996: [Driver] Drop $DEFAULT_TRIPLE-$name as a fallback program name.
Tue, Apr 6, 4:10 PM · Restricted Project
glaubitz added a comment to D99988: [compiler-rt] Add platform detection support for x32.

I think x32 is not really supported by compiler-rt.

There's definitely support for x32 in libsanitizer, though I do not know how complete it is. libsanitizer is used by GCC as well and I am already using it with GCC on x32 myself.

Tue, Apr 6, 3:18 PM · Restricted Project
glaubitz added a comment to D99988: [compiler-rt] Add platform detection support for x32.

Does this change mean the various *_SUPPORTED_ARCH need updating to list x32 as supported too, or are those handled separately?

Tue, Apr 6, 2:57 PM · Restricted Project
glaubitz updated the diff for D99988: [compiler-rt] Add platform detection support for x32.
Tue, Apr 6, 1:30 PM · Restricted Project
glaubitz requested review of D99988: [compiler-rt] Add platform detection support for x32.
Tue, Apr 6, 1:21 PM · Restricted Project
glaubitz added a comment to D98884: [IR] Ignore bitcasts of function pointers which are only used as callees in callbase instruction.

@glaubitz Now that there's a repro - please could you revert this so @madhur13490 can investigate it offline?

Tue, Apr 6, 7:17 AM · Restricted Project
glaubitz added a comment to D98884: [IR] Ignore bitcasts of function pointers which are only used as callees in callbase instruction.

Filed x32-related bug as: https://bugs.llvm.org/show_bug.cgi?id=49861

Tue, Apr 6, 7:14 AM · Restricted Project
glaubitz added a comment to D98884: [IR] Ignore bitcasts of function pointers which are only used as callees in callbase instruction.

This change broke the native build on x32 (x86_64 with 32-bit pointers) for me:

Tue, Apr 6, 7:03 AM · Restricted Project

Mon, Apr 5

glaubitz added a comment to D99869: [M68k] Mark public functions with the LLVM_EXTERNAL_VISIBILITY macro.

LGTM. Thanks
I don't think we need a second LGTM since this is a minor change

Mon, Apr 5, 12:14 AM · Restricted Project

Sun, Apr 4

glaubitz requested review of D99869: [M68k] Mark public functions with the LLVM_EXTERNAL_VISIBILITY macro.
Sun, Apr 4, 4:06 PM · Restricted Project
glaubitz added inline comments to D98537: [M68k] Implement AsmParser.
Sun, Apr 4, 1:49 PM · Restricted Project

Thu, Apr 1

glaubitz added a comment to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

I think, however, we should bump the rest of the paths to 10.2.0 if possible.

I updated all the Linux trees that were on 4.6.0. The only remaining 4.6.0 trees are for Hurd, which seems to me like it was just a coincidence that it was on the same version. There are other Linux trees used for tests as well, but they were already on different versions of GCC so we do not introduce any new inconsistencies by leaving those as they are.

I noticed that I left out one of the 4.6.0 directories by mistake in what I put up for review, that did not affect test results. I included that as obvious in what I pushed.

Thu, Apr 1, 2:01 AM · Restricted Project
glaubitz added a reviewer for D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs: MaskRay.
Thu, Apr 1, 1:39 AM · Restricted Project
glaubitz added a comment to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

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.

Thu, Apr 1, 1:38 AM · Restricted Project

Wed, Mar 31

glaubitz added inline comments to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.
Wed, Mar 31, 3:19 PM · Restricted Project
glaubitz added a comment to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

Mostly looks good.

clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/x32/crtbegin.o

Worth bumping the version. 4.6 is quite old and as a host compiler llvm-project has stopped supporting it. The distributions having 4.6 are all end-of-life.
Using a new version (matching your reality) can give impression that the user who contributed the original code may still need it for a while (say 5 years).

Sure, there should be no harm in renaming 4.6.0 to the current version, 10.2.0, will do that and re-test.

Wed, Mar 31, 3:15 PM · Restricted Project

Tue, Mar 30

glaubitz added a comment to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

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.

Tue, Mar 30, 4:54 PM · Restricted Project
glaubitz added a comment to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

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.

Tue, Mar 30, 1:34 PM · Restricted Project
glaubitz added a comment to D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs.

The NetBSD part looks ok, but also lacks proper testing. I'm not sure anyone but Linux cares at all otherwise as they lack 32bit SPARC support.

Tue, Mar 30, 2:36 AM · Restricted Project
glaubitz added a comment to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

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?

Tue, Mar 30, 2:31 AM · Restricted Project
glaubitz updated the diff for D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

Updated version which unfortunately still fails.

Tue, Mar 30, 1:32 AM · Restricted Project
glaubitz added inline comments to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.
Tue, Mar 30, 1:28 AM · Restricted Project

Sun, Mar 28

glaubitz added a comment to D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs.

Gentle ping.

Sun, Mar 28, 12:26 AM · Restricted Project

Thu, Mar 25

glaubitz added inline comments to D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs.
Thu, Mar 25, 3:21 AM · Restricted Project
glaubitz added inline comments to D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs.
Thu, Mar 25, 3:20 AM · Restricted Project

Tue, Mar 23

glaubitz added a comment to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

Hmm, there recently were quite some changes in the MultiArch and GCC search path functionality in the Driver and I can unfortunately no longer get it to work on x32.

Tue, Mar 23, 6:14 AM · Restricted Project
glaubitz added a comment to D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs.

Updated as I previously forgot to account for FreeBSD as well.

Tue, Mar 23, 1:59 AM · Restricted Project
glaubitz updated the diff for D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs.
Tue, Mar 23, 1:58 AM · Restricted Project

Mon, Mar 22

glaubitz updated the diff for D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs.
Mon, Mar 22, 11:52 AM · Restricted Project
glaubitz added a comment to D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs.

I have updated the patch now with the result that clang should behave as GCC now on Linux, NetBSD and OpenBSD.

Mon, Mar 22, 9:52 AM · Restricted Project
glaubitz updated the diff for D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs.
Mon, Mar 22, 9:51 AM · Restricted Project
glaubitz added a comment to D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs.

For reference, here is what GCC defines on Linux with regards to SPARC:

Mon, Mar 22, 9:22 AM · Restricted Project
glaubitz updated the diff for D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs.
Mon, Mar 22, 9:16 AM · Restricted Project
glaubitz updated the diff for D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs.
Mon, Mar 22, 9:06 AM · Restricted Project

Thu, Mar 18

glaubitz added a comment to D98575: [compiler-rt] Fix build on 32-bit Linux SPARC.

FWIW, the reason I needed `-mcpu=v9``` was this bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27558

Thu, Mar 18, 1:48 AM · Restricted Project

Wed, Mar 17

glaubitz added a comment to D98575: [compiler-rt] Fix build on 32-bit Linux SPARC.
In D98575#2632875, @ro wrote:

Sorry to chime in so late, but I believe this patch has several problems:

  • For one, it's at best a partial solution to the problem of atomics on 32-bit SPARC: those are bound to also occur outside of the LLVM tree and this patch does nothing to handle that.
Wed, Mar 17, 2:11 PM · Restricted Project
glaubitz added a comment to D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs.

I do not immediately see why the other tests are failing, but at a bare minimum the following test from clang/test/Preprocessor/predefined-arch-macros.c will have to be updated..

// RUN: %clang -mcpu=v9 -E -dM %s -o - 2>&1 \
// RUN:     -target sparc-unknown-linux \
// RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_SPARC-V9
// CHECK_SPARC-V9-NOT: #define __sparcv8 1
// CHECK_SPARC-V9-NOT: #define __sparcv8__ 1
// CHECK_SPARC-V9: #define __sparc_v9__ 1
// CHECK_SPARC-V9: #define __sparcv9 1
// CHECK_SPARC-V9: #define __sparcv9__ 1
Wed, Mar 17, 2:59 AM · Restricted Project
glaubitz added inline comments to D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs.
Wed, Mar 17, 2:59 AM · Restricted Project

Mar 13 2021

glaubitz requested review of D98575: [compiler-rt] Fix build on 32-bit Linux SPARC.
Mar 13 2021, 1:14 AM · Restricted Project
glaubitz requested review of D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs.
Mar 13 2021, 12:52 AM · Restricted Project

Mar 12 2021

glaubitz abandoned D98544: [asan] Ensure SHADOW_OFFSET is kSPARC64_ShadowOffset64 on sparc64 only.
Mar 12 2021, 12:08 PM · Restricted Project
glaubitz added a comment to D98544: [asan] Ensure SHADOW_OFFSET is kSPARC64_ShadowOffset64 on sparc64 only.

I just realized this change isn't necessary and it also doesn't fix my build problem.

Mar 12 2021, 12:06 PM · Restricted Project
glaubitz requested review of D98544: [asan] Ensure SHADOW_OFFSET is kSPARC64_ShadowOffset64 on sparc64 only.
Mar 12 2021, 11:43 AM · Restricted Project

Mar 8 2021

glaubitz added a comment to D91031: Add new worker debian-akiko-m68k for Linux 32-bit M68k.

M68k backend has now landed in LLVM. I just rebased this patch and will start the worker in a minute.

Mar 8 2021, 1:15 PM
glaubitz updated the diff for D91031: Add new worker debian-akiko-m68k for Linux 32-bit M68k.
Mar 8 2021, 1:14 PM

Mar 7 2021

glaubitz added a comment to D88391: [M68k] (Patch 5/8) Target lowering.

Woohoo, finally \o/. Min: Time to push, I guess :D :D :D.

Mar 7 2021, 11:49 AM · Restricted Project

Feb 28 2021

glaubitz added inline comments to D88392: [M68k] (Patch 6/8) IR Tests.
Feb 28 2021, 6:53 PM · Restricted Project

Feb 25 2021

glaubitz added inline comments to D88394: [Driver][M68k] (Patch 8/8) Add driver support for M68k.
Feb 25 2021, 2:38 PM · Restricted Project
glaubitz added inline comments to D88394: [Driver][M68k] (Patch 8/8) Add driver support for M68k.
Feb 25 2021, 2:31 PM · Restricted Project

Feb 22 2021

glaubitz added a comment to D88391: [M68k] (Patch 5/8) Target lowering.

@jrtc27 Do you have any more feedback before I accept this and we let the experimental backend be pushed to trunk?

Feb 22 2021, 10:06 AM · Restricted Project

Feb 20 2021

glaubitz added a comment to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

One other question then: do you know if Debian and/or Ubuntu still have the same support for running x32 programs on the regular x86-64 distribution?

I am not sure that I right understand reason of this question, but there is gentoo x32 profile that allow execute all arch x86, x32, x64.

Feb 20 2021, 8:26 AM · Restricted Project

Feb 16 2021

glaubitz added a comment to D88391: [M68k] (Patch 5/8) Target lowering.
  • Addressed feedbacks
Feb 16 2021, 2:32 AM · Restricted Project

Feb 14 2021

glaubitz added a comment to D88391: [M68k] (Patch 5/8) Target lowering.
  • [NFC] Addressed most of the feedbacks
Feb 14 2021, 2:58 AM · Restricted Project

Feb 7 2021

glaubitz added a comment to D88389: [M68k] (Patch 3/8) Basic infrastructures and target description files.

Still a number of outstanding style comments from earlier reviews

Feb 7 2021, 12:58 PM · Restricted Project
glaubitz added a comment to D88391: [M68k] (Patch 5/8) Target lowering.

Any more comments? I'm still seeing some style issues but nothing jumps out as critical.

I also want to make sure that everyone is OK as after this is accepted I see no reason why the whole patch series should not get committed.

Feb 7 2021, 12:21 PM · Restricted Project

Jan 30 2021

glaubitz added a comment to D88390: [M68k] (Patch 4/8) MC layer and object file support.

It's happening what I was hoping and also expecting - external people just coming by and sending such improvements because they love the retro architecture and enjoy working on LLVM.

Ideally, we should get them contributing to the upstream LLVM backend directly, but for that, we need the target in tree.

Jan 30 2021, 5:05 AM · Restricted Project

Jan 29 2021

glaubitz added a comment to D88390: [M68k] (Patch 4/8) MC layer and object file support.

It would be important, however, to know if the m86k community intends to upstream the assembler before moving to production or if the target requires use of third-party closed source tools to work. This will help guide this and other reviews after the first merge, into production.

Speaking of that. Few days ago there is a (draft) PR sent to our GitHub repo: https://github.com/M680x0/M680x0-mono-repo/pull/20
Author of that PR is working on the AsmParser and disassembler (that PR is just a placeholder to inform us in order to prevent overlapping works). I'm pretty excited and looking forward to seeing it appearing upstream before becoming an official backend.

Jan 29 2021, 11:11 AM · Restricted Project

Jan 27 2021

glaubitz added a comment to D88391: [M68k] (Patch 5/8) Target lowering.

True, but that was the odd-one-out and we have corrected to conform to the standard for all other back-ends. I explicitly named the m86k upstreaming as the golden rule as to what to do, both from the reviewers and from the authors.

Jan 27 2021, 12:45 PM · Restricted Project
glaubitz added a comment to D88391: [M68k] (Patch 5/8) Target lowering.

Well, it was quick for C-Sky as well which has several patches already landed: https://github.com/llvm/llvm-project/commits/main/llvm/lib/Target/CSKY

Jan 27 2021, 12:00 PM · Restricted Project
glaubitz added a comment to D88391: [M68k] (Patch 5/8) Target lowering.

This is the only patch in this series which has not been accepted yet.

Jan 27 2021, 11:54 AM · Restricted Project

Jan 14 2021

glaubitz added a comment to D88385: [TableGen][M68K] (Patch 1/8) Utilities for complex instruction addressing modes: CodeBeads and logical operand helper functions.

FWIW I still think we're better off keeping (m68k only) CodeBeads rather than refactoring a lot of code that will affect mainstream targets. After m68k has been pushed, we can reinvestigate whether to keep CodeBeads (and whether other targets would benefit from using it), or moving m68k to a refactored TSFlag mechanism - we can make either a pre-requisite for it losing its experimental status if necessary.

Jan 14 2021, 10:58 AM · Restricted Project

Jan 6 2021

glaubitz added a comment to D88385: [TableGen][M68K] (Patch 1/8) Utilities for complex instruction addressing modes: CodeBeads and logical operand helper functions.

@RKSimon has a good question that I will leave to others to debate.

@craig.topper Actually, a pointer is a bad idea. Instead, if it is necessary to have a separate blob of data, simply use the TSFlags field as an index into a separate table of instances. It's already a uint64_t, which makes a fine index.

I presume the use of this field and the separate table would be triggered by something in a TableGen file, not just hardwired for the M86K target.

Jan 6 2021, 2:55 AM · Restricted Project

Jan 4 2021

glaubitz added a comment to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

However, that's not the same as whether we're on an x86_64 system or on an x32 system determines which GNU triplet to use and which include and library search paths are our primary ones.

But Triple.getEnvironment() will give you llvm::Triple::GNUX32 that you can check?

Jan 4 2021, 5:36 AM · Restricted Project

Dec 21 2020

glaubitz added a comment to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

What gets done currently for i386? That suffers potentially the same problem given both /usr/lib/gcc/x86_64-linux-gnu/$V/32 and /usr/lib/gcc/i386-linux-gnu/$V are possible locations for an i386 GCC toolchain.

Very good suggestion. I will look into that tomorrow. Thanks for the pointer!

Dec 21 2020, 1:45 PM · Restricted Project

Dec 20 2020

glaubitz added inline comments to D88389: [M68k] (Patch 3/8) Basic infrastructures and target description files.
Dec 20 2020, 10:51 AM · Restricted Project

Dec 8 2020

glaubitz added a comment to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

What gets done currently for i386? That suffers potentially the same problem given both /usr/lib/gcc/x86_64-linux-gnu/$V/32 and /usr/lib/gcc/i386-linux-gnu/$V are possible locations for an i386 GCC toolchain.

Dec 8 2020, 2:31 PM · Restricted Project
glaubitz added a comment to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

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).

Dec 8 2020, 2:18 PM · Restricted Project

Dec 2 2020

glaubitz added a comment to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

Hmm, I was pretty sure that autoconf can deal with x32 inside an x32 chroot.

Most autoconf-using software won't be dealing with a copy of config.guess that was last updated in 2011. Updating that to a more recent version should also work. :)

Dec 2 2020, 9:17 AM · Restricted Project
glaubitz added a comment to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

sys::getDefaultTargetTriple() defaults to LLVM_DEFAULT_TARGET_TRIPLE, which in turn defaults to LLVM_HOST_TRIPLE, which in turn defaults to LLVM_INFERRED_HOST_TRIPLE, which calls config.guess which never automatically detects X32. Sorry, forgot to mention that on my system, I also make sure to explicitly specify LLVM_HOST_TRIPLE to an X32 triple when building LLVM.

Dec 2 2020, 9:10 AM · Restricted Project
glaubitz added a comment to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

The problem seems to be that LLVM_HOST_TRIPLE:STRING is set to x86_64-unknown-linux-gnu instead of `x86_64-unknown-linux-gnux32.

Dec 2 2020, 9:05 AM · Restricted Project
glaubitz added a comment to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

I have not found the place yet in clang where to adjust that.

Dec 2 2020, 8:55 AM · Restricted Project
glaubitz added a comment to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

That sounds like it's one thing in https://lists.llvm.org/pipermail/llvm-dev/2020-October/146049.html I haven't extracted into a separate patch for submission yet: LLVM does not call Triple::normalize everywhere it should, and misinterprets x86_64-linux-gnux32 as x86_64-somethingelse when it's set as the default target because of it. For testing this change, it may be easiest to just explicitly specify the triple or -mx32.

Dec 2 2020, 8:53 AM · Restricted Project
glaubitz added a comment to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

I stumbled over one problem with my patch which is that when I run an x32 version of clang in a x32 environment, it will still default to "-m64" instead of "-mx32".

Dec 2 2020, 7:45 AM · Restricted Project
glaubitz added a comment to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

Just as a heads-up, I haven't forgotten about this. Freeing up the server just takes a little longer as I need to backup files through a DSL line. Should be ready by tomorrow.

Dec 2 2020, 6:22 AM · Restricted Project

Nov 30 2020

glaubitz added a comment to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

Were you able to compare against GCC and also determine debian/ubuntu's x86_64 current support for x32 executables?

Nov 30 2020, 9:47 AM · Restricted Project

Nov 27 2020

glaubitz added a comment to D88712: [CGBuiltin] Respect asm labels and redefine_extname for builtins with specialized emitting.

Not sure if this is related, but on SPARC, stage2 builds recently started to fail with:

Nov 27 2020, 8:36 AM · Restricted Project

Nov 25 2020

glaubitz added a comment to D52050: [Driver] Fix architecture triplets and search paths for Linux x32.

Yeah, @hvdijk has made multiple other improvements which should finally allow the backend to be usable.

Nov 25 2020, 1:48 AM · Restricted Project

Nov 23 2020

glaubitz added a comment to D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux.

Thanks so much! Would you mind pushing that change for me? I don't have commit access at the moment.

Nov 23 2020, 4:24 PM · Restricted Project
glaubitz added a comment to D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux.

I changed it to 4.5 to be consisted with the other Multi-Arch tests for x86, MIPS and PowerPC. That's all.

Nov 23 2020, 3:04 PM · Restricted Project

Nov 20 2020

glaubitz added reviewers for D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux: danalbert, maskray0.
Nov 20 2020, 4:06 AM · Restricted Project

Nov 17 2020

glaubitz added a comment to D91618: [sanitizer_common][test] Disable FastUnwindTest.* on SPARC.

Thanks a lot Rainer for taking of all of these issues on SPARC!

Nov 17 2020, 4:53 AM · Restricted Project

Nov 13 2020

glaubitz added a comment to D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux.
In D90524#2393746, @ro wrote:

Please feel free to reach out to the corresponding debian-$ARCH mailing list for such questions. Debian-specific layouts are not
necessarily obvious at first glance to people not very familiar with the distribution.

I could have. However, my only interest in Linux/SPARC was to have a comparison point for my Solaris/SPARC work to determine which test failures occur on all SPARC targets and which ones are Solaris-specific. I simply don't have to time to dig deeper into Linux issues.

Nov 13 2020, 5:44 AM · Restricted Project
glaubitz added a comment to D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux.

! In D90524#2393635, @ro wrote:

I had an extremely hard time researching the history of directory layouts for my patch D85582. Do as you like, I'm out of this.

Nov 13 2020, 4:44 AM · Restricted Project
glaubitz edited reviewers for D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux, added: echristo, MaskRay, phosek; removed: nemanjai, chandlerc, rengolin, dschuff, ro, jyknight.
Nov 13 2020, 4:42 AM · Restricted Project
glaubitz added a comment to D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux.
In D90524#2393320, @ro wrote:

Ping. It would be nice to get this finally merged so that the testsuite noise finally goes down on the sparc64 Linux worker.

Please be a little more patient: one ping a week is considered appropriate, but after only two days is a bit over the top.

Nov 13 2020, 2:23 AM · Restricted Project
glaubitz added a comment to D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux.
In D90524#2393319, @ro wrote:

I think it should be good for merging now. I addressed all remarks. I'm still convinced that "workaround" is the proper term though.

Quite the contrary: the comment you cited

// FIXME: This is a bit of a hack. We should really unify this code for
// reasoning about oslibdir spellings with the lib dir spellings in the
// GCCInstallationDetector, but that is a more significant refactoring.

pretty clearly is about how/where support for that layout is implemented in the clang Driver code, not about the layout itself.

Nov 13 2020, 2:21 AM · Restricted Project
glaubitz added a comment to D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux.

Ping. It would be nice to get this finally merged so that the testsuite noise finally goes down on the sparc64 Linux worker.

Nov 13 2020, 1:43 AM · Restricted Project