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 (269 w, 4 d)

Recent Activity

Thu, Mar 23

glaubitz added a comment to D143315: [m68k] Implement BSR Instruction.

Could someone with permissions land this? Thanks!

I believe @0x59616e 's plan is to land the entire patch series at once

Thu, Mar 23, 9:23 AM · Restricted Project, Restricted Project
glaubitz added a comment to D143315: [m68k] Implement BSR Instruction.

Could someone with permissions land this? Thanks!

Thu, Mar 23, 12:57 AM · Restricted Project, Restricted Project
glaubitz added a comment to D143316: [m68k] Implement absolution long addressing mode for ADDA instruction.

Could someone with permissions land this? Thanks!

Thu, Mar 23, 12:56 AM · Restricted Project, Restricted Project

Wed, Mar 22

glaubitz accepted D146532: [m68k] Change compiler-rt settings.

Fine with me.

Wed, Mar 22, 9:48 AM · Restricted Project

Feb 5 2023

glaubitz added a reviewer for D143317: [m68k] Add TLS support: jrtc27.
Feb 5 2023, 2:21 AM · Restricted Project, Restricted Project
glaubitz added a comment to D143317: [m68k] Add TLS support.

Doesn't seem to build at the moment:

Feb 5 2023, 2:20 AM · Restricted Project, Restricted Project

Jan 3 2023

glaubitz added a comment to D140750: [TargetLowering] Teach BuildUDIV to take advantage of leading zeros in the dividend..

This change broke the test divide-by-constant.ll in the M68k backend, the test may have to be updated.

Jan 3 2023, 11:55 AM · Restricted Project, Restricted Project

Dec 29 2022

glaubitz added a comment to D140695: [M68k] Define __GCC_HAVE_SYNC_COMPARE_AND_SWAP macros.

How come the Clang M68k backend defaults to 68000? GCC defaults to 68020 for all targets.

Dec 29 2022, 12:34 AM · Restricted Project, Restricted Project

Dec 27 2022

glaubitz accepted D140695: [M68k] Define __GCC_HAVE_SYNC_COMPARE_AND_SWAP macros.

Tested and works as expected. Thanks a lot for catching this!

Dec 27 2022, 12:04 PM · Restricted Project, Restricted Project

Sep 10 2022

glaubitz added a comment to D133405: [Linux] Hack around Linux/sparc <bits/stdio-ldbl.h>.

I've been using this hack to work around the Linux/sparc64 compile failure described in Issue #47994, especially since the underlying glibc PR build/27558 doesn't seem to be making progress and some fix is required to have LLVM build on sparc64-unknown-linux-gnu at all, as evidenced on the buildbot.

Didn't this already get fixed by https://github.com/bminor/glibc/commit/d0fa09a7701956036ff36f8ca188e9fff81553d8 upstream? There was also a later fix for the wchar.h header.

Seems it has only been fixed for some headers, see: https://sourceware.org/bugzilla/show_bug.cgi?id=27087

The other issue has also already been fixed in https://github.com/bminor/glibc/commit/c7509d49c4e8fa494120c5ead21338559dad16f5 (and these fixes have been backported to glibc 2.34+).

Are you still seeing any issues with a current glibc?

Sep 10 2022, 3:13 AM · Restricted Project, Restricted Project
glaubitz added a comment to D133405: [Linux] Hack around Linux/sparc <bits/stdio-ldbl.h>.

I've been using this hack to work around the Linux/sparc64 compile failure described in Issue #47994, especially since the underlying glibc PR build/27558 doesn't seem to be making progress and some fix is required to have LLVM build on sparc64-unknown-linux-gnu at all, as evidenced on the buildbot.

Didn't this already get fixed by https://github.com/bminor/glibc/commit/d0fa09a7701956036ff36f8ca188e9fff81553d8 upstream? There was also a later fix for the wchar.h header.

Sep 10 2022, 2:49 AM · Restricted Project, Restricted Project

Sep 9 2022

glaubitz accepted D133405: [Linux] Hack around Linux/sparc <bits/stdio-ldbl.h>.
Sep 9 2022, 5:20 AM · Restricted Project, Restricted Project

Sep 7 2022

glaubitz added a comment to D133405: [Linux] Hack around Linux/sparc <bits/stdio-ldbl.h>.

Thanks, this is definitely very useful. I have pinged glibc upstream and asked them about the progress about this change. Let' see.

Sep 7 2022, 2:16 AM · Restricted Project, Restricted Project

Aug 18 2022

glaubitz added a comment to D130688: [Driver][Sparc] Default to -mcpu=v9 for SparcV8 on Linux.
In D130688#3731619, @ro wrote:

Yeah, someone from the LEON community should comment whether they would be OK to default to V9 on all Linux targets. I don't really want to omit Gentoo here which still support Linux on SPARC.

How could they? LEON is V8 (with extensions) only!

Aug 18 2022, 3:07 AM · Restricted Project, Restricted Project
glaubitz added a comment to D130688: [Driver][Sparc] Default to -mcpu=v9 for SparcV8 on Linux.
In D130688#3731577, @ro wrote:

It's almost three weeks since the last comments. Any suggestions on how to proceed with this patch? Given that the original issue (atomics not inlined with -m32) is now worked around by always linking with --as-needed -latomic --no-as-needed, the patch is no longer needed to fix build failures. However, it still would make a nice and cheap optimization on distros that require v9 CPUs, if we can figure out how to reliably identify them. Maybe someone from the LEON community could chime in?

Aug 18 2022, 2:47 AM · Restricted Project, Restricted Project

Aug 5 2022

glaubitz accepted D130988: Revert [compiler-rt][CMake] Enable TF intrinsics on powerpc32 Linux.
Aug 5 2022, 1:42 AM · Restricted Project, Restricted Project

Aug 2 2022

glaubitz updated subscribers of D121379: [compiler-rt][CMake] Enable TF intrinsics on powerpc32 Linux.

This break the build of compiler-rt with GCC. Even recent GCC fails with "error: unable to emulate 'TI'" for 32-bit powerpc targets. The fact that this even works on Clang seems like a bug, because replacing it with typedef __int128 ti_int results in an __int128 is not supported on this target error in both GCC and Clang.

Aug 2 2022, 3:05 AM · Restricted Project, Restricted Project

Jul 28 2022

glaubitz added inline comments to D130688: [Driver][Sparc] Default to -mcpu=v9 for SparcV8 on Linux.
Jul 28 2022, 7:41 AM · Restricted Project, Restricted Project

Jul 26 2022

glaubitz added a comment to D130272: [Support] Handle SPARC in sys::getHostCPUName.

The code style looks good to me, but I cannot verify the list. @glaubitz should have sparc machines and perform some verification.

Jul 26 2022, 1:08 PM · Restricted Project, Restricted Project
glaubitz accepted D130569: [Driver] Use libatomic for 32-bit SPARC atomics support on Linux.

This should address the current CI issues on sparc64 together with D130571.

Jul 26 2022, 7:54 AM · Restricted Project, Restricted Project
glaubitz accepted D130571: [compiler-rt][Sanitizer] Link sanitizer libs with -latomic on SPARC.

Great. I think that should fix the CI!

Jul 26 2022, 7:26 AM · Restricted Project, Restricted Project
glaubitz accepted D130566: [Driver] Default to DWARF 4 on Linux/sparc64.
Jul 26 2022, 7:06 AM · Restricted Project, Restricted Project
glaubitz added a comment to D130566: [Driver] Default to DWARF 4 on Linux/sparc64.

Interesting and thanks for catching this! How did you discover this issue? Is there any particular program that fails to build due to this issue?

Jul 26 2022, 7:01 AM · Restricted Project, Restricted Project

Jul 24 2022

glaubitz accepted D121379: [compiler-rt][CMake] Enable TF intrinsics on powerpc32 Linux.
Jul 24 2022, 1:38 AM · Restricted Project, Restricted Project
glaubitz added a comment to D121379: [compiler-rt][CMake] Enable TF intrinsics on powerpc32 Linux.

@MaskRay Any chance you could commit this change?

Jul 24 2022, 1:37 AM · Restricted Project, Restricted Project

May 31 2022

Herald added a project to D116886: [M68k] Instruction selection to choose neg x when mul x -1 (Fix issue 48588): Restricted Project.

Any news on this?

May 31 2022, 7:43 AM · Restricted Project, Restricted Project

May 25 2022

glaubitz added a comment to D126391: MIPS: compiler-rt/scudo requires atomic.

I have created a new revision which works fine for me on mips64el, see: https://reviews.llvm.org/D126418

May 25 2022, 1:40 PM · Restricted Project, Restricted Project
glaubitz requested review of D126418: [scudo] Link against libatomic on all MIPS targets.
May 25 2022, 1:39 PM · Restricted Project, Restricted Project

May 19 2022

glaubitz added a comment to D125872: Add new worker debian-tritium-mips64el for Linux 64-bit MIPS LE.

Thanks, Adrian!

May 19 2022, 12:30 AM · Restricted Project

May 18 2022

glaubitz requested review of D125872: Add new worker debian-tritium-mips64el for Linux 64-bit MIPS LE.
May 18 2022, 3:52 AM · Restricted Project

May 16 2022

glaubitz added a comment to D125572: [sanitizer] Don't use newfstatat for Linux on SPARC.

LGTM

Seems fine to me, if fstatat64 is indeed the canonical syscall on sparc.

May 16 2022, 11:51 AM · Restricted Project, Restricted Project

May 15 2022

glaubitz added a comment to D125572: [sanitizer] Don't use newfstatat for Linux on SPARC.

Could someone land this for me? Thanks!

May 15 2022, 12:57 AM · Restricted Project, Restricted Project

May 14 2022

glaubitz added a comment to D124212: [sanitizer] Use canonical syscalls everywhere.

Maybe after you land the sparc fix.

May 14 2022, 2:31 AM · Restricted Project, Restricted Project

May 13 2022

glaubitz updated the diff for D125572: [sanitizer] Don't use newfstatat for Linux on SPARC.
May 13 2022, 11:00 AM · Restricted Project, Restricted Project
glaubitz requested review of D125572: [sanitizer] Don't use newfstatat for Linux on SPARC.
May 13 2022, 10:58 AM · Restricted Project, Restricted Project

May 12 2022

glaubitz added a comment to D124212: [sanitizer] Use canonical syscalls everywhere.

There's a lot of really quite wonky whitespace reformatting in this diff

May 12 2022, 12:24 PM · Restricted Project, Restricted Project
glaubitz added a comment to D124212: [sanitizer] Use canonical syscalls everywhere.

This change unfortunately broke the build on Linux/sparc64.

May 12 2022, 4:25 AM · Restricted Project, Restricted Project
glaubitz added a comment to D124968: [sanitizer] Use newfstatat for x32.
May 12 2022, 4:22 AM · Restricted Project, Restricted Project

Feb 11 2022

glaubitz added a comment to D111497: m68k: Support bit shifts on 64-bit integers.

@AnnikaCodes if you agree, I can update the diff so that we can land this ASAP.

Feb 11 2022, 12:48 AM · Restricted Project

Jan 31 2022

glaubitz added inline comments to D118021: [Driver] Use libatomic for 32-bit SPARC atomics support.
Jan 31 2022, 8:48 AM · Restricted Project, Restricted Project, Restricted Project
glaubitz added inline comments to D118021: [Driver] Use libatomic for 32-bit SPARC atomics support.
Jan 31 2022, 8:40 AM · Restricted Project, Restricted Project, Restricted Project
glaubitz abandoned D108197: [compiler-rt] Disable compiler-rt on 32-bit Linux SPARC.

Issue has been fixed in GCC, we can drop this change now.

Jan 31 2022, 2:14 AM · Restricted Project
glaubitz abandoned D98575: [compiler-rt] Force baseline on 32-bit SPARC to V8+ when using gcc.

GCC has now been updated to use the V8+ baselone on sparc64 in 32-bit mode, so we can drop this patch altogether.

Jan 31 2022, 2:14 AM · Restricted Project

Jan 28 2022

glaubitz added a comment to D111497: m68k: Support bit shifts on 64-bit integers.

Any news on this?

Jan 28 2022, 8:45 AM · Restricted Project

Jan 24 2022

glaubitz added a comment to D98575: [compiler-rt] Force baseline on 32-bit SPARC to V8+ when using gcc.

OK, so gcc is going to enable V8plus for 32-bit V9 as well. So we can just drop this patch ;-).

Jan 24 2022, 10:32 AM · Restricted Project
glaubitz added inline comments to D118021: [Driver] Use libatomic for 32-bit SPARC atomics support.
Jan 24 2022, 3:05 AM · Restricted Project, Restricted Project, Restricted Project
glaubitz added inline comments to D118021: [Driver] Use libatomic for 32-bit SPARC atomics support.
Jan 24 2022, 2:49 AM · Restricted Project, Restricted Project, Restricted Project
glaubitz added inline comments to D118021: [Driver] Use libatomic for 32-bit SPARC atomics support.
Jan 24 2022, 2:43 AM · Restricted Project, Restricted Project, Restricted Project
glaubitz added a reviewer for D118024: [sanitizer_common] Use atomic builtin in sanitizer_atomic_clang.h: jrtc27.

Thanks, that's actually a workaround I have also used in the past!

Jan 24 2022, 2:39 AM · Restricted Project, Restricted Project
glaubitz added inline comments to D118021: [Driver] Use libatomic for 32-bit SPARC atomics support.
Jan 24 2022, 2:16 AM · Restricted Project, Restricted Project, Restricted Project
glaubitz added a comment to D118021: [Driver] Use libatomic for 32-bit SPARC atomics support.

Ah, I actually ran into this very problem! Thanks for fixing this.

Jan 24 2022, 2:12 AM · Restricted Project, Restricted Project, Restricted Project

Jan 23 2022

glaubitz added a comment to D98575: [compiler-rt] Force baseline on 32-bit SPARC to V8+ when using gcc.

gcc might be fixed in the future to enable 64-bit atomic operations with -m32 -mcpu=v9, see [1].

Jan 23 2022, 4:08 AM · Restricted Project

Jan 22 2022

glaubitz added a comment to D98575: [compiler-rt] Force baseline on 32-bit SPARC to V8+ when using gcc.

FWIW, gcc actually behaves differently on Solaris:

Jan 22 2022, 4:46 PM · Restricted Project
glaubitz updated the diff for D98575: [compiler-rt] Force baseline on 32-bit SPARC to V8+ when using gcc.

Use "-mcpu=ultrasparc3" instead of "-mv8plus" as the latter will break the stage1 testsuite with clang.

Jan 22 2022, 12:28 PM · Restricted Project
glaubitz added a comment to D98575: [compiler-rt] Force baseline on 32-bit SPARC to V8+ when using gcc.

OK, it seems we can use -mcpu=ultrasparc3 instead which is also understood by clang:

Jan 22 2022, 9:50 AM · Restricted Project
glaubitz added a comment to D98575: [compiler-rt] Force baseline on 32-bit SPARC to V8+ when using gcc.

Hmm, it looks like the testsuite is stumbling over this change as it actually tries to run clang in g++-mode without understanding the -mv8plus flag:

Jan 22 2022, 9:42 AM · Restricted Project
glaubitz updated the diff for D98575: [compiler-rt] Force baseline on 32-bit SPARC to V8+ when using gcc.

After more research, it turned out that the reason for the lack of 64-bit
atomic operations on 32-bit SPARC was that gcc does not enable these
on this target unless "-mvplus8" is passed in the compiler flags. Even
setting the CPU type to V9 will not enable 64-bit atomic operations by
default.

Jan 22 2022, 8:27 AM · Restricted Project

Jan 21 2022

glaubitz added a comment to D98574: [Sparc] Don't define __sparcv9 and __sparcv9__ when targeting V8+.

Could someone land this for me? Thanks!

Jan 21 2022, 9:39 AM · Restricted Project
glaubitz added a comment to D98575: [compiler-rt] Force baseline on 32-bit SPARC to V8+ when using gcc.

I made another discovery which explains why passing -m32 -mcpu=v9 doesn't help.

Jan 21 2022, 6:02 AM · Restricted Project
glaubitz retitled D98574: [Sparc] Don't define __sparcv9 and __sparcv9__ when targeting V8+ from [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs to [Sparc] Don't define __sparcv9 and __sparcv9__ when targeting V8+.
Jan 21 2022, 5:06 AM · Restricted Project
glaubitz updated the diff for D98574: [Sparc] Don't define __sparcv9 and __sparcv9__ when targeting V8+.

Minor improvement to the commit description.

Jan 21 2022, 5:05 AM · Restricted Project
glaubitz updated the diff for D98574: [Sparc] Don't define __sparcv9 and __sparcv9__ when targeting V8+.

Updated the patch as requested and dropped all changes except the removal of sparcv9 and sparcv9__.

Jan 21 2022, 5:03 AM · Restricted Project
glaubitz updated the diff for D98574: [Sparc] Don't define __sparcv9 and __sparcv9__ when targeting V8+.

Made changes according to review and dropped every change except removing sparcv9 and sparcv9__.

Jan 21 2022, 5:01 AM · Restricted Project
glaubitz added a comment to D98575: [compiler-rt] Force baseline on 32-bit SPARC to V8+ when using gcc.

Created a bug report for this now on Github: https://github.com/llvm/llvm-project/issues/53337

Jan 21 2022, 4:22 AM · Restricted Project
glaubitz added a comment to D98575: [compiler-rt] Force baseline on 32-bit SPARC to V8+ when using gcc.

This simple hack makes it build:

Jan 21 2022, 2:33 AM · Restricted Project

Jan 20 2022

glaubitz added a comment to D98575: [compiler-rt] Force baseline on 32-bit SPARC to V8+ when using gcc.

And looking at this particular GCC bug [1] again, the main problem seems that we are using __sync_val_compare_and_swap() which doesn't support 64-bit values.

Jan 20 2022, 10:14 AM · Restricted Project
glaubitz added a comment to D98575: [compiler-rt] Force baseline on 32-bit SPARC to V8+ when using gcc.

I found some time again to work on this.

Jan 20 2022, 10:08 AM · Restricted Project

Jan 14 2022

glaubitz updated subscribers of D116580: [M68k] Add addressing modes ARIPI and ARIPD support for BTST.
Jan 14 2022, 1:05 PM · Restricted Project

Nov 9 2021

glaubitz added a comment to D111497: m68k: Support bit shifts on 64-bit integers.

Hi! Any news on this?

Nov 9 2021, 11:05 AM · Restricted Project

Oct 28 2021

glaubitz added a comment to D111497: m68k: Support bit shifts on 64-bit integers.

I'm still getting test failures with this updated patch.

Oct 28 2021, 4:22 AM · Restricted Project

Oct 25 2021

glaubitz added a comment to D111497: m68k: Support bit shifts on 64-bit integers.

That's probably https://github.com/llvm/llvm-project/commit/26b675d65eb2d1f117a39eee965652f590373232. It's in unrelated code so you can ignore it, and the buildbot probably isn't even enabling the experimental M68k backend?

FWIW, the M68k backend is actually tested on a different buildbot: http://lab.llvm.org:8014/#/builders/180

Sure, but that's all for post-commit checks, not pre-commit like the failure here.

Oct 25 2021, 7:14 AM · Restricted Project

Oct 24 2021

glaubitz added a comment to D111497: m68k: Support bit shifts on 64-bit integers.

That's probably https://github.com/llvm/llvm-project/commit/26b675d65eb2d1f117a39eee965652f590373232. It's in unrelated code so you can ignore it, and the buildbot probably isn't even enabling the experimental M68k backend?

Oct 24 2021, 2:41 PM · Restricted Project

Oct 21 2021

glaubitz added a comment to D111497: m68k: Support bit shifts on 64-bit integers.

Could someone land this?

Oct 21 2021, 4:04 AM · Restricted Project

Oct 17 2021

glaubitz added a comment to D102872: Fix lldb-server build failure on mips.

It seems we need this change on all architectures except arm, arm64, ppc64el, s390x and x86_64. Those are the only ones which implement NativeRegisterContextLinux_$ARCH.

Oct 17 2021, 12:54 AM · Restricted Project
glaubitz added a comment to D102872: Fix lldb-server build failure on mips.

This failure affects 32-bit PowerPC as well. Can we get this fixed?

Oct 17 2021, 12:48 AM · Restricted Project

Oct 1 2021

glaubitz added a comment to D98575: [compiler-rt] Force baseline on 32-bit SPARC to V8+ when using gcc.
In D98575#2954804, @ro wrote:

Please note that I'm on vacation for two weeks and thus unlikely to respond much if at all during that time.

Oct 1 2021, 6:10 AM · Restricted Project

Aug 27 2021

glaubitz added a comment to D108792: [M68k] Update pointer data layout.

@ricky26 Could you also get this fix backported in the LLVM fork of Rust?

Aug 27 2021, 12:52 AM · Restricted Project, Restricted Project

Aug 25 2021

glaubitz added a reviewer for D108723: [M68k][NFC] Rename M68kOperand::Kind to KindTy: jrtc27.

As suggested here [1] by @jrtc27, I think the better solution is to rename the enum Kind to KindTy.

Aug 25 2021, 12:58 PM · Restricted Project

Aug 19 2021

glaubitz added a comment to D98575: [compiler-rt] Force baseline on 32-bit SPARC to V8+ when using gcc.
Aug 19 2021, 8:59 AM · Restricted Project
glaubitz added a comment to D98575: [compiler-rt] Force baseline on 32-bit SPARC to V8+ when using gcc.

I tried adding -mcpu=v9 to the default build flags now:

Aug 19 2021, 8:58 AM · Restricted Project
glaubitz added a comment to D98575: [compiler-rt] Force baseline on 32-bit SPARC to V8+ when using gcc.

@ro Do you have a patch for your suggested baseline raise?

Aug 19 2021, 5:59 AM · Restricted Project
glaubitz reclaimed D98575: [compiler-rt] Force baseline on 32-bit SPARC to V8+ when using gcc.
Aug 19 2021, 5:58 AM · Restricted Project

Aug 17 2021

glaubitz updated the diff for D108197: [compiler-rt] Disable compiler-rt on 32-bit Linux SPARC.

I have updated the patch to disable compiler-rt on Linux only.

Aug 17 2021, 11:49 AM · Restricted Project
glaubitz added a comment to D98575: [compiler-rt] Force baseline on 32-bit SPARC to V8+ when using gcc.

Oh, another question on top: Does OpenMP work without issues on Solaris/SPARC?

Aug 17 2021, 8:50 AM · Restricted Project
glaubitz added a comment to D98575: [compiler-rt] Force baseline on 32-bit SPARC to V8+ when using gcc.
In D98575#2949331, @ro wrote:
  • Even so, it's unclear what CPUs are supposed to run the generated 32-bit code: if it's only supposed to run on SPARC V9 CPUs, why not use the same solution I did for Solaris/sparcv9 in D86621: always default to -mcpu=v9? If the code can also be run on V8 CPUs, the patch is wrong: if run there, the V9 insns will cause the resulting binaries to randomly crash with SIGILL: not exactly a good user experience. In that case, the driver should link with --as-needed -latomic --no-as-needed instead.
  • Besides, I don't see the point of linking with -latomic when you already pass -mcpu=v9. It shouldn't be necessary and is certainly wrong on Solaris/sparcv9 where it only adds an unnecessary dependency.

You've left this crucial question unanswered, but the whole direction of solving the issue depends on it. Reading Debian SPARC Port suggests that the 32-bit Linux/sparc kernel has been abandoned long ago, which means you can assume an UltraSPARC/SPARC V9 cpu. In that case, you can default clang -m32 to -mcpu=v9, just on Solaris/sparc, and be done with it because V9 dues support the insns necessary for atomics support even in 32-bit mode.

Aug 17 2021, 8:41 AM · Restricted Project
glaubitz added a comment to D108197: [compiler-rt] Disable compiler-rt on 32-bit Linux SPARC.
In D108197#2949312, @ro wrote:

I'm not seeing any comments from you in the previous patch unless I am missing something.

Huh? What about this one for example?

Aug 17 2021, 6:45 AM · Restricted Project
glaubitz added a comment to D108197: [compiler-rt] Disable compiler-rt on 32-bit Linux SPARC.
In D108197#2949283, @ro wrote:

So what? Just ping the patch like everyone else. Abandoning it and submitting effectively the same patch anew just makes work harder for the reviewers.

In my case, I just stopped responding at some point because I got the impression that my comments and questions were mostly evaded or ignored. Talking to a brick wall isn't my favourite pastime.

Aug 17 2021, 6:39 AM · Restricted Project
glaubitz added a comment to D108197: [compiler-rt] Disable compiler-rt on 32-bit Linux SPARC.
In D108197#2949186, @ro wrote:

Why on earth did you abandon the original patch D98575? This patch is very similar to the last version there. It makes it much harder to review and comment on the issues already raised there.

Aug 17 2021, 6:01 AM · Restricted Project
glaubitz abandoned D98575: [compiler-rt] Force baseline on 32-bit SPARC to V8+ when using gcc.

Replaced by https://reviews.llvm.org/D108197

Aug 17 2021, 3:24 AM · Restricted Project
glaubitz requested review of D108197: [compiler-rt] Disable compiler-rt on 32-bit Linux SPARC.
Aug 17 2021, 3:23 AM · Restricted Project

Aug 16 2021

glaubitz added a comment to D98575: [compiler-rt] Force baseline on 32-bit SPARC to V8+ when using gcc.

More research reveals that the __sync_ built-ins are actually legacy stuff:

Aug 16 2021, 3:34 PM · Restricted Project
glaubitz added a comment to D98575: [compiler-rt] Force baseline on 32-bit SPARC to V8+ when using gcc.

Reading through this bug report, it seems we might not be able to use __sync_val_compare_and_swap_8 on 32-bit PowerPC and SPARC:

Aug 16 2021, 3:03 PM · Restricted Project
glaubitz added a comment to D98575: [compiler-rt] Force baseline on 32-bit SPARC to V8+ when using gcc.

I just realized that compiler-rt doesn't actually test on 32-bit PowerPC which would explain why we don't see the issue there:

Aug 16 2021, 2:46 PM · Restricted Project
glaubitz added inline comments to D98575: [compiler-rt] Force baseline on 32-bit SPARC to V8+ when using gcc.
Aug 16 2021, 7:39 AM · Restricted Project
glaubitz added inline comments to D98575: [compiler-rt] Force baseline on 32-bit SPARC to V8+ when using gcc.
Aug 16 2021, 7:06 AM · Restricted Project

Jul 15 2021

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

Since @glaubitz is here:

I want to set LLVM_ENABLE_PER_TARGET_RUNTIME_DIR to on by default so that the libraries for x86-64 will be in lib/clang/13.0.0/lib/x86_64-unknown-linux-gnu/libclang_rt.profile.a instead of lib/clang/13.0.0/lib/linux/libclang_rt.profile-x86_64.a.
Clang driver supports both paths.

Jul 15 2021, 11:55 PM · Restricted Project
glaubitz added a comment to D100148: [Driver] Fix compiler-rt lookup for x32.

Updated to use Triple.isX32().

Should we perhaps just merge this as is, ahead of the update to compiler-rt to create x32 objects? For non-x32, this change is NFC, for x32, the change results in a better error message about compiler-rt objects not existing rather than being for the wrong architecture.

Jul 15 2021, 9:40 AM · Restricted Project

Jul 13 2021

glaubitz added a comment to D105457: [clang] Refactor AST printing tests to share more infrastructure.

Any ideas what version of the standard library these buildbots are using? This /looks/ a bit like a bug in the standard library in use, perhaps? (also because it's not showing up in lots of other buildbots/developers, I assume?)

Jul 13 2021, 12:08 PM · Restricted Project
glaubitz added a comment to D105457: [clang] Refactor AST printing tests to share more infrastructure.

This change I suspect is causing a build failure on a build bot.

https://lab.llvm.org/buildbot/#/builders/110/builds/4827

FAILED: /usr/bin/c++  -DCLANG_ROUND_TRIP_CC1_ARGS=ON -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/clang/unittests/AST -I/home/ssglocal/clang-cmake-x86_64-avx2-linux/clang-cmake-x86_64-avx2-linux/llvm/clang/unittests/AST -I/home/ssglocal/clang-cmake-x86_64-avx2-linux/clang-cmake-x86_64-avx2-linux/llvm/clang/include -Itools/clang/include -Iinclude -I/home/ssglocal/clang-cmake-x86_64-avx2-linux/clang-cmake-x86_64-avx2-linux/llvm/llvm/include -I/home/ssglocal/clang-cmake-x86_64-avx2-linux/clang-cmake-x86_64-avx2-linux/llvm/llvm/utils/unittest/googletest/include -I/home/ssglocal/clang-cmake-x86_64-avx2-linux/clang-cmake-x86_64-avx2-linux/llvm/llvm/utils/unittest/googlemock/include -march=broadwell -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color -ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual -fno-strict-aliasing -O3 -DNDEBUG    -Wno-variadic-macros -fno-exceptions -fno-rtti -UNDEBUG -Wno-suggest-override -std=c++14 -MD -MT tools/clang/unittests/AST/CMakeFiles/ASTTests.dir/StmtPrinterTest.cpp.o -MF tools/clang/unittests/AST/CMakeFiles/ASTTests.dir/StmtPrinterTest.cpp.o.d -o tools/clang/unittests/AST/CMakeFiles/ASTTests.dir/StmtPrinterTest.cpp.o -c /home/ssglocal/clang-cmake-x86_64-avx2-linux/clang-cmake-x86_64-avx2-linux/llvm/clang/unittests/AST/StmtPrinterTest.cpp
/tmp/cc8Ycpsn.s: Assembler messages:
/tmp/cc8Ycpsn.s:11414: Error: symbol `_ZNSt17_Function_handlerIFbPKN5clang4StmtEENS0_UlS3_E2_EE9_M_invokeERKSt9_Any_dataOS3_' is already defined
/tmp/cc8Ycpsn.s:11937: Error: symbol `_ZNSt14_Function_base13_Base_managerIN5clangUlPKNS1_4StmtEE2_EE10_M_managerERSt9_Any_dataRKS7_St18_Manager_operation' is already defined
ninja: build stopped: subcommand failed.

Can you take a look?

Jul 13 2021, 6:18 AM · Restricted Project

Jun 18 2021

glaubitz added a comment to D104467: [M68k] Add new worker suse-gary-m68k-cross for Linux 32-bit M68k.

Do you need a help with the commit?

Jun 18 2021, 12:03 AM