[PATCH] D149867: [Clang][M68k] Add Clang support for the new M68k_RTD CC

glaubitz added a comment. Maybe these patches need to be reposted to Github as they seem to be ignored here now after the swtich from Phabricator. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D149867/new/ https://reviews.llvm.org/D149867

[PATCH] D149867: [Clang][M68k] Add Clang support for the new M68k_RTD CC

glaubitz added a comment. Any news on this? I guess it would be nice to get the remaining m68k patches merged before the Phrabricator shutdown. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D149867/new/ https://reviews.llvm.org/D149867 ___

[PATCH] D149867: [Clang][M68k] Add Clang support for the new M68k_RTD CC

glaubitz added a comment. In D149867#4612589 , @myhsu wrote: > In D149867#4603853 , @aaron.ballman > wrote: > >> In D149867#4544489 , @myhsu wrote: >> >>> Sorry I was

[PATCH] D149867: [Clang][M68k] Add Clang support for the new M68k_RTD CC

glaubitz added a comment. Any update on this? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D149867/new/ https://reviews.llvm.org/D149867 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D149867: [M68k] Add Clang support for the new M68k_RTD CC

glaubitz added a comment. In D149867#4386271 , @jrtc27 wrote: > I disagree. Being experimental doesn't mean you should do the wrong thing. > Reusing stdcall in the frontend is ugly, pollutes non-m68k code paths (doing > your own thing _avoids_ that and

[PATCH] D147481: [M68k] Add basic Clang supports for M68881/2

glaubitz added a comment. @myhsu Can you fix the typo in the commit message? s/supports/support/ CHANGES SINCE LAST ACTION https://reviews.llvm.org/D147481/new/ https://reviews.llvm.org/D147481 ___ cfe-commits mailing list

[PATCH] D140695: [M68k] Define __GCC_HAVE_SYNC_COMPARE_AND_SWAP macros

glaubitz added a comment. In D140695#4019189 , @brad wrote: > How come the Clang M68k backend defaults to 68000? GCC defaults to 68020 for > all targets. The Clang M68k is a complete rewrite from scratch, independent of GCC, so it's not surprising you

[PATCH] D140695: [M68k] Define __GCC_HAVE_SYNC_COMPARE_AND_SWAP macros

glaubitz accepted this revision. glaubitz added a comment. Tested and works as expected. Thanks a lot for catching this! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D140695/new/ https://reviews.llvm.org/D140695

[PATCH] D133405: [Linux] Hack around Linux/sparc

glaubitz added a comment. In D133405#3782137 , @nikic wrote: > In D133405#3782136 , @glaubitz > wrote: > >> In D133405#3782092 , @nikic wrote: >> I've been using

[PATCH] D133405: [Linux] Hack around Linux/sparc

glaubitz added a comment. In D133405#3782092 , @nikic wrote: >> 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

[PATCH] D133405: [Linux] Hack around Linux/sparc

glaubitz added a comment. Thanks, this is definitely very useful. I have pinged glibc upstream and asked them about the progress about this change. Let' see. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D133405/new/

[PATCH] D130688: [Driver][Sparc] Default to -mcpu=v9 for SparcV8 on Linux

glaubitz added a comment. In D130688#3731619 , @ro wrote: > In D130688#3731611 , @glaubitz > wrote: > >> > > > >> Yeah, someone from the LEON community should comment whether they would be >> OK to default to

[PATCH] D130688: [Driver][Sparc] Default to -mcpu=v9 for SparcV8 on Linux

glaubitz added a comment. 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

[PATCH] D130688: [Driver][Sparc] Default to -mcpu=v9 for SparcV8 on Linux

glaubitz added inline comments. Comment at: clang/lib/Driver/ToolChains/Arch/Sparc.cpp:139 + if (Triple.getArch() == llvm::Triple::sparc && + (Triple.isOSSolaris() || Distro(D.getVFS(), Triple).IsDebian())) return "v9"; Can we do it "IsLinux()"

[PATCH] D130569: [Driver] Use libatomic for 32-bit SPARC atomics support on Linux [clang-linux-sparc-libatomic.patch, submitted 2022-07-26]

glaubitz accepted this revision. glaubitz added a comment. This revision is now accepted and ready to land. This should address the current CI issues on sparc64 together with D130571 . Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D130566: [Driver] Default to DWARF 4 on Linux/sparc64

glaubitz added a comment. 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? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D130566/new/

[PATCH] D118021: [Driver] Use libatomic for 32-bit SPARC atomics support

glaubitz added inline comments. Comment at: clang/lib/Driver/ToolChains/Solaris.cpp:135 } +// LLVM lacks atomics support on 32-bit SPARC, so forcibly link with +// libatomic as a workaround. glaubitz wrote: > ro wrote: > > ro wrote: > > > glaubitz

[PATCH] D118021: [Driver] Use libatomic for 32-bit SPARC atomics support

glaubitz added inline comments. Comment at: clang/lib/Driver/ToolChains/Solaris.cpp:135 } +// LLVM lacks atomics support on 32-bit SPARC, so forcibly link with +// libatomic as a workaround. ro wrote: > ro wrote: > > glaubitz wrote: > > > ro wrote:

[PATCH] D118021: [Driver] Use libatomic for 32-bit SPARC atomics support

glaubitz added inline comments. Comment at: clang/lib/Driver/ToolChains/Solaris.cpp:138-139 +if (getToolChain().getTriple().getArch() == llvm::Triple::sparc) { + CmdArgs.push_back(getAsNeededOption(getToolChain(), true)); + CmdArgs.push_back("-latomic"); +

[PATCH] D118021: [Driver] Use libatomic for 32-bit SPARC atomics support

glaubitz added inline comments. Comment at: clang/lib/Driver/ToolChains/Solaris.cpp:135 } +// LLVM lacks atomics support on 32-bit SPARC, so forcibly link with +// libatomic as a workaround. ro wrote: > glaubitz wrote: > > joerg wrote: > > > This

[PATCH] D118021: [Driver] Use libatomic for 32-bit SPARC atomics support

glaubitz added inline comments. Comment at: clang/lib/Driver/ToolChains/Solaris.cpp:135 } +// LLVM lacks atomics support on 32-bit SPARC, so forcibly link with +// libatomic as a workaround. joerg wrote: > This comment is misleading. It's not so

[PATCH] D118021: [Driver] Use libatomic for 32-bit SPARC atomics support

glaubitz added inline comments. Comment at: clang/lib/Driver/ToolChains/Solaris.cpp:138-139 +if (getToolChain().getTriple().getArch() == llvm::Triple::sparc) { + CmdArgs.push_back(getAsNeededOption(getToolChain(), true)); + CmdArgs.push_back("-latomic"); +

[PATCH] D118021: [Driver] Use libatomic for 32-bit SPARC atomics support

glaubitz added a comment. Ah, I actually ran into this very problem! Thanks for fixing this. Will test this today on Linux and report back! Could you maybe have a look at my updated revision here? https://reviews.llvm.org/D98575 I think this particular change should be save on Solaris as

[PATCH] D98574: [Sparc] Don't define __sparcv9 and __sparcv9__ when targeting V8+

glaubitz added a comment. Could someone land this for me? Thanks! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D98574/new/ https://reviews.llvm.org/D98574 ___ cfe-commits mailing list

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

glaubitz updated this revision to Diff 401953. glaubitz edited the summary of this revision. glaubitz added a comment. Minor improvement to the commit description. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D98574/new/

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

glaubitz updated this revision to Diff 401951. glaubitz edited the summary of this revision. glaubitz added a comment. Updated the patch as requested and dropped all changes except the removal of __sparcv9 and __sparcv9__. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

glaubitz updated this revision to Diff 401950. glaubitz added a comment. Made changes according to review and dropped every change except removing __sparcv9 and __sparcv9__. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D98574/new/

[PATCH] D108792: [M68k] Update pointer data layout

glaubitz added a comment. @ricky26 Could you also get this fix backported in the LLVM fork of Rust? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D108792/new/ https://reviews.llvm.org/D108792 ___

[PATCH] D100148: [Driver] Fix compiler-rt lookup for x32

glaubitz added a comment. In D100148#2881382 , @MaskRay wrote: > 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 >

[PATCH] D100148: [Driver] Fix compiler-rt lookup for x32

glaubitz added a comment. In D100148#2880499 , @hvdijk wrote: > 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

[PATCH] D105457: [clang] Refactor AST printing tests to share more infrastructure

glaubitz added a comment. In D105457#2874516 , @dblaikie wrote: > 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

[PATCH] D105457: [clang] Refactor AST printing tests to share more infrastructure

glaubitz added a comment. In D105457#2873294 , @dyung wrote: > 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

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

glaubitz added inline comments. Comment at: clang/lib/Basic/Targets/Sparc.cpp:246-256 + if (getTriple().getOS() == llvm::Triple::Linux) { Builder.defineMacro("__sparc_v9__"); -Builder.defineMacro("__sparcv9__"); + } else { +Builder.defineMacro("__sparcv9"); +

[PATCH] D100148: [Driver] Fix compiler-rt lookup for x32

glaubitz added a comment. @hvdijk I just noticed that the sanitizer defines `SANITIZER_X32` for x32, so I assume your patch itself is already correct. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D100148/new/ https://reviews.llvm.org/D100148

[PATCH] D100148: [Driver] Fix compiler-rt lookup for x32

glaubitz added a comment. In D100148#2683710 , @hvdijk wrote: > In D100148#2683325 , @glaubitz > wrote: > >> Hi! Can we get this patch merged as-is or do we need anything else? > > Sorry, miscommunication. I was

[PATCH] D100148: [Driver] Fix compiler-rt lookup for x32

glaubitz added a comment. Hi! Can we get this patch merged as-is or do we need anything else? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D100148/new/ https://reviews.llvm.org/D100148 ___ cfe-commits

[PATCH] D100148: [Driver] Fix compiler-rt lookup for x32

glaubitz added a comment. So, we only need D99988 and this one (D100148 ) now and the LLVM package will finally build on Debian without any additional tweaks. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D100148: [Driver] Fix compiler-rt lookup for x32

glaubitz accepted this revision. glaubitz added inline comments. This revision is now accepted and ready to land. Comment at: clang/test/Driver/sanitizer-ld.c:309 // CHECK-UBSAN-LINUX: "-lpthread" // RUN: %clang -fsanitize=undefined -fno-sanitize-link-runtime %s -### -o %t.o

[PATCH] D100148: [Driver] Fix compiler-rt lookup for x32

glaubitz added inline comments. Comment at: clang/test/Driver/sanitizer-ld.c:309 // CHECK-UBSAN-LINUX: "-lpthread" // RUN: %clang -fsanitize=undefined -fno-sanitize-link-runtime %s -### -o %t.o 2>&1 \ glaubitz wrote: > Do we need want to run the test for

[PATCH] D100148: [Driver] Fix compiler-rt lookup for x32

glaubitz added inline comments. Comment at: clang/test/Driver/sanitizer-ld.c:309 // CHECK-UBSAN-LINUX: "-lpthread" // RUN: %clang -fsanitize=undefined -fno-sanitize-link-runtime %s -### -o %t.o 2>&1 \ Do we need want to run the test for i386 anymore?

[PATCH] D100148: [Driver] Fix compiler-rt lookup for x32

glaubitz added a comment. Thanks, this finally fixes the build for me. I wasn't aware that there was a `getArchNameForCompilerRTLib()` function in clang. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D100148/new/ https://reviews.llvm.org/D100148

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

glaubitz added a comment. Ping. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D98574/new/ https://reviews.llvm.org/D98574 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

glaubitz added a comment. In D52050#2663247 , @hvdijk wrote: > In D52050#2663205 , @glaubitz wrote: > >> I think, however, we should bump the rest of the paths to 10.2.0 if possible. > > I updated all the Linux

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

glaubitz added a comment. In D52050#2662656 , @hvdijk wrote: > 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. In D52050#2662648

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

glaubitz added inline comments. Comment at: clang/lib/Driver/ToolChains/Gnu.cpp:2110 + static const char *const X32Triples[] = {"x86_64-linux-gnux32", + "x86_64-unknown-linux-gnux32", +

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

glaubitz added a comment. In D52050#2662440 , @hvdijk wrote: > In D52050#2662372 , @MaskRay wrote: > >> Mostly looks good. >> >>>

[PATCH] D52050: WIP: [Driver] Fix architecture triplets and search paths for Linux x32

glaubitz added a comment. In D52050#2660022 , @hvdijk wrote: > 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

[PATCH] D52050: WIP: [Driver] Fix architecture triplets and search paths for Linux x32

glaubitz added a comment. In D52050#2659654 , @hvdijk wrote: > I am testing the below, on top of c8e56f394af0b9e32c413d62a0e7aebbba3e6b70 > , both > in a Debian chroot and in my

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

glaubitz added a comment. In D98574#2654686 , @joerg wrote: > 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. Well, there were no tests for NetBSD before,

[PATCH] D52050: WIP: [Driver] Fix architecture triplets and search paths for Linux x32

glaubitz added a comment. In D52050#2657952 , @hvdijk wrote: > 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

[PATCH] D52050: WIP: [Driver] Fix architecture triplets and search paths for Linux x32

glaubitz updated this revision to Diff 334071. glaubitz retitled this revision from "[Driver] Fix architecture triplets and search paths for Linux x32" to "WIP: [Driver] Fix architecture triplets and search paths for Linux x32". glaubitz added a comment. Updated version which unfortunately

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

glaubitz added inline comments. Comment at: clang/lib/Driver/ToolChains/Linux.cpp:90 return "x86_64-linux-android"; -// We don't want this for x32, otherwise it will match x86_64 libs -if (TargetEnvironment != llvm::Triple::GNUX32 && -

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

glaubitz added a comment. Gentle ping. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D98574/new/ https://reviews.llvm.org/D98574 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

glaubitz marked an inline comment as done. glaubitz added inline comments. Comment at: clang/lib/Basic/Targets/Sparc.cpp:246-256 + if (getTriple().getOS() == llvm::Triple::Linux) { Builder.defineMacro("__sparc_v9__"); -Builder.defineMacro("__sparcv9__"); + } else { +

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

glaubitz marked an inline comment as done. glaubitz added inline comments. Comment at: clang/lib/Basic/Targets/Sparc.cpp:246-256 + if (getTriple().getOS() == llvm::Triple::Linux) { Builder.defineMacro("__sparc_v9__"); -Builder.defineMacro("__sparcv9__"); + } else { +

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

glaubitz added a comment. 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. I had a relatively simple approach but I cannot get it to add the path for the crt.o objects and so

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

glaubitz added a comment. Updated as I previously forgot to account for FreeBSD as well. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D98574/new/ https://reviews.llvm.org/D98574 ___ cfe-commits mailing

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

glaubitz updated this revision to Diff 332567. glaubitz edited the summary of this revision. Herald added subscribers: arichardson, emaste. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D98574/new/ https://reviews.llvm.org/D98574 Files:

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

glaubitz updated this revision to Diff 332380. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D98574/new/ https://reviews.llvm.org/D98574 Files: clang/lib/Basic/Targets/Sparc.cpp clang/test/Preprocessor/predefined-arch-macros.c Index:

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

glaubitz added a comment. I have updated the patch now with the result that clang should behave as GCC now on Linux, NetBSD and OpenBSD. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D98574/new/ https://reviews.llvm.org/D98574

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

glaubitz updated this revision to Diff 332339. glaubitz edited the summary of this revision. Herald added a subscriber: krytarowski. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D98574/new/ https://reviews.llvm.org/D98574 Files:

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

glaubitz added a comment. For reference, here is what GCC defines on Linux with regards to SPARC: glaubitz@gcc202:~$ echo | gcc -E -dM -mcpu=v9 -m32 - |grep arch glaubitz@gcc202:~$ echo | gcc -E -dM -mcpu=v9 -m32 - |grep LP glaubitz@gcc202:~$ echo | gcc -E -dM -mcpu=v9 -m32 - |grep v9

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

glaubitz updated this revision to Diff 332320. glaubitz edited the summary of this revision. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D98574/new/ https://reviews.llvm.org/D98574 Files: clang/lib/Basic/Targets/Sparc.cpp

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs

glaubitz updated this revision to Diff 332312. glaubitz retitled this revision from "[Sparc] Define the same macros for -mcpu=v9 as GCC on Linux" to "[Sparc] Define the same macros for -mcpu=v9 as GCC on Linux and the BSDs". glaubitz edited the summary of this revision. Repository: rG LLVM

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux

glaubitz added a comment. In D98574#2624558 , @brad wrote: > 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.. > > //

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux

glaubitz added inline comments. Comment at: clang/lib/Basic/Targets/Sparc.cpp:160-164 + // Linux doesn't need these variants, but the BSDs do. + if (getTriple().getOS() != llvm::Triple::Linux) { +Builder.defineMacro("__sparcv9"); +

[PATCH] D98574: [Sparc] Define the same macros for -mcpu=v9 as GCC on Linux

glaubitz created this revision. glaubitz added reviewers: jrtc27, ro, efriedma, brad, jfb, venkatra, jyknight. Herald added a subscriber: fedor.sergeev. glaubitz requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. When targeting SPARC V8+ or

[PATCH] D88394: [Driver][M68k] (Patch 8/8) Add driver support for M68k

glaubitz added inline comments. Comment at: clang/test/Driver/m68k-sub-archs.cpp:1 +// RUN: %clang -### -target m68k-unknown-linux -mcpu=68000 %s 2>&1 | FileCheck --check-prefix=CHECK-MX00 %s +// RUN: %clang -### -target m68k-unknown-linux -mcpu=m68000 %s 2>&1 | FileCheck

[PATCH] D88394: [Driver][M68k] (Patch 8/8) Add driver support for M68k

glaubitz added inline comments. Comment at: clang/test/Driver/m68k-sub-archs.cpp:1 +// RUN: %clang -### -target m68k-unknown-linux -mcpu=68000 %s 2>&1 | FileCheck --check-prefix=CHECK-MX00 %s +// RUN: %clang -### -target m68k-unknown-linux -mcpu=m68000 %s 2>&1 | FileCheck

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

glaubitz added a comment. In D52050#2576679 , @alsoijw wrote: > In D52050#2369838 , @dschuff wrote: > >> One other question then: do you know if Debian and/or Ubuntu still have the >> same support for running x32

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

glaubitz added a comment. In D52050#2468424 , @jrtc27 wrote: >> 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

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

glaubitz added a comment. In D52050#2441164 , @glaubitz wrote: > In D52050#2441141 , @jrtc27 wrote: > >> What gets done currently for i386? That suffers potentially the same problem >> given both

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

glaubitz added a comment. In D52050#2441141 , @jrtc27 wrote: > 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

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

glaubitz added a comment. In D52050#2441094 , @hvdijk wrote: > 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.

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

glaubitz added a comment. In D52050#2428743 , @hvdijk wrote: > In D52050#2428735 , @glaubitz wrote: > >> Hmm, I was pretty sure that autoconf can deal with x32 inside an x32 chroot. > > Most autoconf-using software

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

glaubitz added a comment. In D52050#2428709 , @hvdijk wrote: > `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

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

glaubitz added a comment. 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`. I haven't found the place to fix that yet. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

glaubitz added a comment. In D52050#2428685 , @glaubitz wrote: > I have not found the place yet in clang where to adjust that. Maybe `sys::getDefaultTargetTriple()` needs to be adjusted. I'll have a look. Repository: rG LLVM Github Monorepo CHANGES

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

glaubitz added a comment. In D52050#2428590 , @hvdijk wrote: > 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 >

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

glaubitz added a comment. 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". Thus: glaubitz@epyc:..llvm-project/build> ./bin/clang hello.c -o hello /usr/bin/ld: cannot find

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

glaubitz added a comment. 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. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

glaubitz added a comment. In D52050#2423144 , @RKSimon wrote: > Were you able to compare against GCC and also determine debian/ubuntu's > x86_64 current support for x32 executables? Not yet. Currently freeing up space on my VM host so I can perform a

[PATCH] D88712: [CGBuiltin] Respect asm labels and redefine_extname for builtins with specialized emitting

glaubitz added a comment. Not sure if this is related, but on SPARC, stage2 builds recently started to fail with: [379/5552] Building CXX object projects/compiler-rt/lib/ubsan/CMakeFiles/RTUbsan.sparc.dir/ubsan_diag.cpp.o FAILED:

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

glaubitz added a comment. Yeah, @hvdijk has made multiple other improvements which should finally allow the backend to be usable. We still disagree on the search paths for libraries and headers though if I remember correctly. My goal is to make LLVM and Rust work on an full Debian x32 system

[PATCH] D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux

glaubitz added a comment. Thanks so much! Would you mind pushing that change for me? I don't have commit access at the moment. Thanks! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D90524/new/ https://reviews.llvm.org/D90524

[PATCH] D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux

glaubitz added a comment. I changed it to 4.5 to be consisted with the other Multi-Arch tests for x86, MIPS and PowerPC. That's all. Debian Multi-Arch on sparc/sparc64 behaves the exact same way as it does on mips*, powerpc* and x86, so I think it makes sense to use the exact same path

[PATCH] D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux

glaubitz added a comment. In D90524#2393746 , @ro wrote: > In D90524#2393651 , @glaubitz wrote: > >> > > > >> Please feel free to reach out to the corresponding debian-$ARCH mailing list >> for such questions.

[PATCH] D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux

glaubitz added a comment. > ! 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. Please feel free to

[PATCH] D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux

glaubitz added a comment. In D90524#2393320 , @ro wrote: > In D90524#2393312 , @glaubitz wrote: > >> Ping. It would be nice to get this finally merged so that the testsuite >> noise finally goes down on the

[PATCH] D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux

glaubitz added a comment. In D90524#2393319 , @ro wrote: > In D90524#2388214 , @glaubitz wrote: > >> I think it should be good for merging now. I addressed all remarks. I'm >> still convinced that "workaround" is

[PATCH] D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux

glaubitz added a comment. Ping. It would be nice to get this finally merged so that the testsuite noise finally goes down on the sparc64 Linux worker. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D90524/new/ https://reviews.llvm.org/D90524

[PATCH] D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux

glaubitz added a comment. I think it should be good for merging now. I addressed all remarks. I'm still convinced that "workaround" is the proper term though. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D90524/new/

[PATCH] D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux

glaubitz updated this revision to Diff 303846. glaubitz edited the summary of this revision. glaubitz added a comment. Herald added subscribers: steven.zhang, jrtc27. Update as requested in previous review, also merge with D90549 . Repository: rG LLVM Github

[PATCH] D90549: [Driver] Switch CHECK-DEBIAN-SPARC tests to use debian_multiarch_tree

glaubitz added a comment. Merged into D90524 . Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D90549/new/ https://reviews.llvm.org/D90549 ___ cfe-commits mailing list

[PATCH] D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux

glaubitz added a comment. Hi Rainer! Thanks for your review. In D90524#2382555 , @ro wrote: > As it happens, I'd arrived at exactly the same patch when I tried a build on > a Debian/sparc64 system in the GCC compile farm (gcc202), submitted as D85582

[PATCH] D90549: [Driver] Switch CHECK-DEBIAN-SPARC tests to use debian_multiarch_tree

glaubitz added a comment. Ping. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D90549/new/ https://reviews.llvm.org/D90549 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux

glaubitz added a comment. Ping. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D90524/new/ https://reviews.llvm.org/D90524 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

glaubitz added a comment. In D52050#2369838 , @dschuff wrote: > 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? > (presumably yes, since you aren't

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

glaubitz updated this revision to Diff 302404. glaubitz added a comment. Regenerated with more context (using git format-patch -W). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D52050/new/ https://reviews.llvm.org/D52050 Files:

[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

glaubitz added a comment. In D52050#2369581 , @dschuff wrote: > Can you upload the diff with full context (e.g. use `diff -U ` or use > arcanist to upload)? > > I'm a bit confused; the commit message talks about X32 being a separate > architecture,

  1   2   >