[PATCH] D40903: [Sanitizers] Basic Solaris sanitizer support (PR 33274)

ro added inline comments. Comment at: lib/Driver/ToolChains/CommonArgs.cpp:684 if (AddExportDynamic) -CmdArgs.push_back("-export-dynamic"); +CmdArgs.push_back("--export-dynamic"); alekseyshl wrote: > If it does not exist on Solaris, why change it the

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

ro created this revision. ro added reviewers: glaubitz, MaskRay. Herald added subscribers: StephenFan, fedor.sergeev, jyknight. Herald added a project: All. ro requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. I've been using this hack to wor

[PATCH] D133407: [Driver] Support non-canonical triples with new runtime lib layout

ro created this revision. ro added a reviewer: MaskRay. ro added a project: clang. Herald added subscribers: StephenFan, abidh, jrtc27, fedor.sergeev, kristof.beyls, jyknight. Herald added a project: All. ro requested review of this revision. This is the companion patch to D133406

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

ro added a comment. In D133405#3776096 , @MaskRay wrote: > It's not a compiler's job to define this workaround... Yes and no: GCC successfully does it via its `fixincludes` mechanism. Unfortunately, LLVM doesn't provide something similar and doesn't ev

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

ro added a comment. In D133405#3779190 , @MaskRay wrote: > So, sparc64 gcc does seem to define the macro by default. (I am using Debian > testing and can't tell whether it's distro setting or upstream default) > ¯\_(ツ)_/¯ > > % sparc64-linux-gnu-gcc -

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

ro updated this revision to Diff 459017. ro added a comment. Add comment, tests. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D133405/new/ https://reviews.llvm.org/D133405 Files: clang/lib/Basic/Targets/OSTargets.h clang/test/Preprocessor/init

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

This revision was automatically updated to reflect the committed changes. Closed by commit rG1e56821bac02: [Linux] Hack around Linux/sparc (authored by ro). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D133405/new/ https://review

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

ro created this revision. ro added reviewers: glaubitz, MaskRay. ro added a project: clang. Herald added subscribers: jsji, StephenFan, pengfei, fedor.sergeev, jyknight. Herald added a project: All. ro requested review of this revision. During a build on Debian 11/sparc64, several binaries fail to

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

ro created this revision. ro added reviewers: glaubitz, jrtc27, MaskRay, efriedma. ro added a project: clang. Herald added subscribers: StephenFan, fedor.sergeev, jyknight. Herald added a project: All. ro requested review of this revision. This is the Linux/sparc64 equivalent to D118021

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

ro added a comment. In D130566#3679480 , @glaubitz wrote: > 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? Sure: many programs fail to link during `ninj

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

ro added a comment. In D130566#3681129 , @dblaikie wrote: >> During a build on Debian 11/sparc64, several binaries fail to link with >> >> /usr/bin/ld: /usr/bin/ld: DWARF error: invalid or unhandled FORM value: >> 0x23 > > What's the linker doing parsi

[PATCH] D130569: [Driver] Use libatomic for 32-bit SPARC atomics support on Linux

ro marked 2 inline comments as done. ro added inline comments. Comment at: clang/lib/Driver/ToolChains/Gnu.cpp:634 + // LLVM support for atomics on 32-bit SPARC V8+ is incomplete, so + // forcibly link with libatomic as a workaround. MaskRay wrote: >

[PATCH] D130569: [Driver] Use libatomic for 32-bit SPARC atomics support on Linux

ro updated this revision to Diff 448253. ro marked 2 inline comments as done. ro added a comment. - Switch to `--push-state`/`--pop-state`. - Add testcase. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D130569/new/ https://reviews.llvm.org/D130569

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

ro created this revision. ro added reviewers: glaubitz, MaskRay, jrtc27. ro added a project: clang. Herald added subscribers: StephenFan, pengfei, fedor.sergeev, jyknight. Herald added a project: All. ro requested review of this revision. This is the Debian/sparc64 equivalent of D86621

[PATCH] D130273: [clang][Driver] Handle SPARC -mcpu=native etc.

ro updated this revision to Diff 448290. ro marked 3 inline comments as done. ro edited the summary of this revision. ro added a comment. - Incorporate review comments. - Add testcases. - Reject `-march`, matching GCC. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://re

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

ro added a comment. In D130566#3682923 , @dblaikie wrote: >> This is all extremely weird, but until the error shows up again, I'll put >> this patch on hold (not yet abandoning since there seems to be no way to >> unabandon if necessary). > > You can ab

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

ro 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"; glaubitz wrote: > Can we do it "IsLinu

[PATCH] D130569: [Driver] Use libatomic for 32-bit SPARC atomics support on Linux

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG9b1897bbd0e3: [Driver] Use libatomic for 32-bit SPARC atomics support on Linux (authored by ro). Repository: rG LLVM Github Monorepo CHANGES SINC

[PATCH] D130273: [clang][Driver] Handle SPARC -mcpu=native etc.

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGbf3714884ae4: [clang][Driver] Handle SPARC -mcpu=native etc. (authored by ro). Changed prior to commit: https://reviews.llvm.org/D130273?vs=448290

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

ro added a comment. In D130688#3686512 , @MaskRay wrote: > Making the behavior different for different Linux distributions is not great, > but if it matches the practice, I think it is fine. It's the best we can do in `clang`, I fear, due to the compile

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

ro abandoned this revision. ro added a comment. Nick Clifton just commited a fix both to the binutils 2.39 branch and master. So the workaround certainly isn't necessary. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D130566/new/ https://reviews.l

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

ro added a comment. Ping^2. It would be great if this could be reviewed/commited soon: it fixes hundreds of testsuite failures, so I'd like to get it into LLVM 14. Thanks. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D118021/new/ https://reviews

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

ro added a comment. In D118021#3307079 , @MaskRay wrote: > This needs some tests, otherwise there is a risk that others may break your > changes when refactoring driver code. I thought it would be enough that any breakage there would cause a large numbe

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

ro updated this revision to Diff 407120. ro added a comment. Add tests in `solaris-ld.c`. Spot-checked by running the single test with `llvm-lit` on `sparcv9-sun-solaris2.11`, `amd64-solaris2.11`, and `x86_64-pc-linux-gnu`. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION htt

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

ro marked an inline comment as done. ro added inline comments. Comment at: clang/test/Driver/solaris-ld.c:20 // CHECK-LD-SPARC32-SAME: "-L[[SYSROOT]]/usr/lib" +// CHECK-LD-SPARC32-SAME: "-zignore" +// CHECK-LD-SPARC32-SAME: "-latomic" MaskRay wrote: > If they ar

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

ro updated this revision to Diff 407455. ro marked an inline comment as done. ro added a comment. Simplify test. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D118021/new/ https://reviews.llvm.org/D118021 Files: clang/lib/Driver/ToolChains/Common

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

ro added inline comments. Comment at: clang/test/Driver/solaris-ld.c:46 // CHECK-LD-SPARC64-SAME: "-L[[SYSROOT]]/usr/lib/sparcv9" +// CHECK-LD-SPARC64-NOT: "-zignore" +// CHECK-LD-SPARC64-NOT: "-latomic" ro wrote: > MaskRay wrote: > > Such NOT patterns are usu

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

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGa6afa9e6b0d9: [Driver] Use libatomic for 32-bit SPARC atomics support (authored by ro). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST AC

[PATCH] D91605: [sanitizers] Implement GetTls on Solaris

ro updated this revision to Diff 408389. ro added a subscriber: nikic. ro added a comment. Since the build-time check for the `ld -z relax=transtls` option was met with massive resistance and was only necessary for Illumos anyway, this revision just uses it unconditionally. Tested on `amd64-pc-

[PATCH] D91605: [sanitizers] Implement GetTls on Solaris

ro added a comment. @vitalybuka , @MaskRay could I persuade you to review the revision version which should be much less controversial and completely Solaris-specific? Thanks. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D91605/new/ https://revi

[PATCH] D91605: [sanitizers] Implement GetTls on Solaris

ro added a comment. In D91605#3321554 , @MaskRay wrote: > `GetTls` is about the static TLS block size. It consists of the main > executable's TLS, and initially loaded shared objects' TLS, `struct pthread`, > and padding. > Solaris should be able to just

[PATCH] D119829: [Driver] Support Solaris/amd64 GetTls

ro created this revision. ro added a reviewer: MaskRay. ro added a project: clang. Herald added subscribers: fedor.sergeev, jyknight. ro requested review of this revision. This is the driver part of D91605 , a workaround to allow direct calls to `__tls_get_addr` o

[PATCH] D91605: [sanitizers] Implement GetTls on Solaris

ro added a comment. In D91605#3321556 , @MaskRay wrote: > The Clang driver change should be in a separate patch with clang/test/Driver > tests. Done now: D119829 . Repository: rG LLVM Github Monorepo CHANGES SINCE L

[PATCH] D91605: [sanitizers] Implement GetTls on Solaris

ro added a comment. In D91605#3322312 , @ro wrote: > In D91605#3321554 , @MaskRay wrote: > >> `GetTls` is about the static TLS block size. It consists of the main >> executable's TLS, and initially loaded shared ob

[PATCH] D91605: [sanitizers] Implement GetTls on Solaris

ro added a comment. In D91605#3329375 , @ro wrote: > > As an experiment, I've tried to use `GetStaticTlsBoundary` instead. It does > indeed work on recent Solaris 11.4 and the resulting patch is at D120048 > . I'm

[PATCH] D130273: [clang][Driver] Handle SPARC -mcpu=native etc.

ro created this revision. ro added reviewers: MaskRay, glaubitz, jrtc27. ro added a project: clang. Herald added subscribers: StephenFan, fedor.sergeev, jyknight. Herald added a project: All. ro requested review of this revision. To make use of SPARC support in `getHostCPUName` as implemented by D

[PATCH] D130273: [clang][Driver] Handle SPARC -mcpu=native etc.

ro added a comment. In D130273#3670623 , @MaskRay wrote: > I notice that in gcc, -march/-mtune/-mcpu are handled in gcc/config/* and > every port may have somewhat different behaviors. E.g. x86 and aarch64 are > different (and I suspect x86 has the weir

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

ro added a comment. Ping? It's been a week and AFAICT there's nothing left for me to do. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86621/new/ https://reviews.llvm.org/D86621 ___ cfe-commits mailing

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

This revision was not accepted when it landed; it landed in state "Needs Review". This revision was automatically updated to reflect the committed changes. Closed by commit rG76e85ae268f8: [clang][Sparc] Default to -mcpu=v9 for Sparc V8 on Solaris (authored by ro). Repository: rG LLVM Github M

[PATCH] D87615: [clang][Driver] Force stack realignment on 32-bit Solaris/x86

ro created this revision. ro added reviewers: MaskRay, rahmanl, efriedma, RKSimon. ro added a project: clang. Herald added a subscriber: fedor.sergeev. ro requested review of this revision. On Solaris/x86, several hundred 32-bit tests `FAIL`, all in the same way: env ASAN_OPTIONS=halt_on_error=

[PATCH] D87615: [clang][Driver] Force stack realignment on 32-bit Solaris/x86

ro added a comment. In D87615#2271268 , @RKSimon wrote: > Would it be possible to add some tests? Probably not reliably: the tests that usually fail bye the hundreds happen to `PASS` once in a while when the stack pointer is 16-byte aligned by accident.

[PATCH] D87615: [clang][Driver] Force stack realignment on 32-bit Solaris/x86

ro added a comment. In D87615#2271646 , @efriedma wrote: > > X86Subtarget::initSubtargetFeatures claims that that stack is 16-byte aligned > on Solaris; if that's wrong, we should fix it, not force stack realignment. I missed that (my usual issue of

[PATCH] D87615: [clang][Driver] Force stack realignment on 32-bit Solaris/x86

ro added a comment. That claim of 16-byte alignment on Solaris is half-wrong: it's definitely wrong on Solaris, but seems to be true on Illumos. However, there's currently no way to distinguish the two other than checking `uname -v` at runtime in a native compiler. The configure triples contin

[PATCH] D87615: [X86] Fix stack alignment on 32-bit Solaris/x86

ro updated this revision to Diff 291831. ro retitled this revision from "[clang][Driver] Force stack realignment on 32-bit Solaris/x86" to "[X86] Fix stack alignment on 32-bit Solaris/x86". ro added a comment. Herald added subscribers: llvm-commits, hiraditya. Herald added a project: LLVM. Set `s

[PATCH] D87615: [X86] Fix stack alignment on 32-bit Solaris/x86

ro added a subscriber: vitalybuka. ro added a comment. In D87615#2273427 , @ro wrote: > > Tested on `amd64-pc-solaris2.11`. However, compared to the `-mstackrealign` > version > there's one regression that I still need to investigate: > > UBSan-Sta

[PATCH] D87615: [X86] Fix stack alignment on 32-bit Solaris/x86

ro updated this revision to Diff 291837. ro added a reviewer: vitalybuka. ro added a comment. Herald added a project: Sanitizers. Herald added a subscriber: Sanitizers. Allow for whitespace differences in `vptr.cpp`. Tested on `amd64-pc-solaris2.11` with the previous `-mstackrealign` patch and w

[PATCH] D87615: [X86] Fix stack alignment on 32-bit Solaris/x86

ro updated this revision to Diff 292153. ro added a comment. - Rely on `stackAlignment` default for 32-bit Solaris/x86 - Handle Solaris in `llvm/test/CodeGen/X86/stack-align2.ll` Tested on `amd64-pc-solaris2.11` and `x86_64-pc-linux-gnu`. Repository: rG LLVM Github Monorepo CHANGES SINCE LAS

[PATCH] D87615: [X86] Fix stack alignment on 32-bit Solaris/x86

ro added a comment. In D87615#2275045 , @efriedma wrote: > Also, it would be nice to have some regression test coverage; add a Solaris > RUN line to llvm/test/CodeGen/X86/stack-align2.ll ? Sure, done in the updated patch. I'd checked that if `FAIL`s wit

[PATCH] D87615: [X86] Fix stack alignment on 32-bit Solaris/x86

ro added a comment. In D87615#2278002 , @joerg wrote: > I'm still curious about the source of the vptr diff, but that's a minor > question, otherwise. LGTM Thanks. I think I've found what's going on here: the memory ranges are ultimately printed by `co

[PATCH] D87615: [X86] Fix stack alignment on 32-bit Solaris/x86

ro added a comment. In D87615#2278436 , @MaskRay wrote: >> This patch avoid the issue by defaulting to -mstackrealign, just like gcc. > > This sentence from the description should be removed. Sure: I usually review and eventually update the description on

[PATCH] D87615: [X86] Fix stack alignment on 32-bit Solaris/x86

This revision was automatically updated to reflect the committed changes. Closed by commit rGa9cbe5cf30e3: [X86] Fix stack alignment on 32-bit Solaris/x86 (authored by ro). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D87615/new/ https://reviews.llv

[PATCH] D87825: [ASTMatchers] Define clang::ast_matchers::decompositionDecl

ro created this revision. ro added reviewers: JonasToth, aaron.ballman. ro added a project: clang. Herald added subscribers: usaxena95, kadircet, fedor.sergeev, jyknight. ro requested review of this revision. Herald added a subscriber: ilya-biryukov. D87588 broke

[PATCH] D87588: [ASTMatchers] extract public matchers from const-analysis into own patch

ro added a comment. As described in D87825 , this patch broke `Debug` builds on `sparcv9-sun-solaris2.11` and `amd64-pc-solaris2.11`. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D87588/new/ https://reviews.llvm.or

[PATCH] D87825: [ASTMatchers] Define clang::ast_matchers::decompositionDecl

ro abandoned this revision. ro added a comment. Just found this had already been fixed in commit f0546173fa4bdde03ecb21a174fcaa8a6490adbd . Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.ll

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

ro created this revision. ro added reviewers: brad, jyknight. ro added a project: clang. Herald added subscribers: Sanitizers, jfb, jrtc27, fedor.sergeev. Herald added a reviewer: jfb. Herald added a project: Sanitizers. ro requested review of this revision. Herald added a subscriber: dexonsmith.

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

ro added a comment. While doing 2-stage builds, the 2 `XFAIL`s due to Bug 42493 were required. However, I've since also done a 1-stage build with gcc 10, which shows Unexpectedly Passed Tests (2): UBSan-Standalone-sparc :: TestCases/Float/cast-overflow.cpp UBSan-Standalone-sparc :: Te

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

ro added reviewers: venkatra, efriedma. ro added a comment. Herald added a subscriber: danielkiss. Ping? It's been a week. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86621/new/ https://reviews.llvm.org/D86621 ___

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

ro added a comment. In D86621#2247786 , @efriedma wrote: > > For compiler-rt, the XFAILs should probably reflect whatever config the bot > is running. (Alternatively, you could use UNSUPPORTED, but that doesn't seem > warranted here.) That's been m

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

ro added a comment. In D86621#2247791 , @jrtc27 wrote: > GCC on Linux defines `__sparc_v9__` even with `-m32`. I don't know what > Solaris does but please don't break other operating systems just because > Solaris has broken headers that conflate the CPU

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

ro updated this revision to Diff 289128. ro added a comment. Define `__sparcv8` only on 32-bit Solaris/SPARC. Update testcase. Remove `XFAIL`s that only apply to `clang`/2-stage builds. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86621/new/ https

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

ro added a comment. In D86621#2249240 , @jrtc27 wrote: > Actually, `__sparcv8` is only for V8; if you have 32-bit V9 on Solaris it > defines `__sparcv8plus` _instead_: > > jrtc27@gcc-solaris11:~$ /opt/solarisstudio12.4/bin/cc -E - -xarch=v9 -m32 > -xdu

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

ro added inline comments. Comment at: clang/lib/Basic/Targets/Sparc.cpp:224 +Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8"); + } } efriedma wrote: > ro wrote: > > efriedma wrote: > > > This probably should be refactored so the target-independent

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

ro added inline comments. Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:350 return A->getValue(); +if (T.getArch() == llvm::Triple::sparc && T.isOSSolaris()) + return "v9"; brad wrote: > ro wrote: > > efriedma wrote: > > > Do we want to m

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

ro added inline comments. Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:350 return A->getValue(); +if (T.getArch() == llvm::Triple::sparc && T.isOSSolaris()) + return "v9"; efriedma wrote: > ro wrote: > > brad wrote: > > > ro wrote: > > >

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

ro added inline comments. Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:350 return A->getValue(); +if (T.getArch() == llvm::Triple::sparc && T.isOSSolaris()) + return "v9"; ro wrote: > efriedma wrote: > > ro wrote: > > > brad wrote: > > >

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

ro added inline comments. Comment at: clang/lib/Basic/Targets/Sparc.cpp:224 +Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8"); + } } efriedma wrote: > ro wrote: > > efriedma wrote: > > > ro wrote: > > > > efriedma wrote: > > > > > This probably sho

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

ro added inline comments. Comment at: clang/lib/Basic/Targets/Sparc.cpp:224 +Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8"); + } } efriedma wrote: > ro wrote: > > efriedma wrote: > > > ro wrote: > > > > efriedma wrote: > > > > > ro wrote: > > > >

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

ro updated this revision to Diff 289658. ro added a comment. Add FIXME for SparcV8 `MaxAtomicInlineWidth`. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86621/new/ https://reviews.llvm.org/D86621 Files: clang/lib/Basic/Targets/Sparc.cpp clang/

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

ro added a comment. Is there anything left to do to get approval? Thanks. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86621/new/ https://reviews.llvm.org/D86621 ___ cfe-commits mailing list cfe-commit

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

ro added a comment. 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 . A couple of questions/caveats: - I wouldn't call this patch a workaround, as you do

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

ro added a comment. As I'd mentioned in D90524 , I believe both patches should be merged into one. Otherwise, no matter in which order you commit them, the buildbots might show failures otherwise. Another point I'm not certain about is wether the checks for the

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

ro added a comment. 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 the proper term though. Quite the contrary: the comment you cited // FIXME: This

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

ro added a comment. 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 sparc64 Linux worker. Please be a little more patient: one ping a week is considered appro

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

ro resigned from this revision. ro added a comment. In D90524#2393353 , @glaubitz wrote: > In D90524#2393319 , @ro wrote: > >> In D90524#2388214 , @glaubitz wrote: >> >>> I t

[PATCH] D85582: [clang][Driver] Search lib32 on Linux/sparc64 with -m32

ro abandoned this revision. ro added a comment. Herald added a subscriber: pengfei. Superceded by D90524 . Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D85582/new/ https://reviews.llvm.org/D85582 __

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

ro added a comment. In D90524#2393366 , @glaubitz wrote: > In D90524#2393320 , @ro wrote: > >> In D90524#2393312 , @glaubitz wrote: >> >>> Ping. It would be nice to get this

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

ro added a comment. In D90524#2393651 , @glaubitz 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 fa

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

ro added a comment. In D90524#2393747 , @glaubitz wrote: > > No worries. I'm glad someone is taking care of the Solaris parts and > appreciate fixes from other parties. My pleasure: hopefully our work will also be for the benefit of the other party.

[PATCH] D91605: [sanitizers] Implement GetTls on Solaris

ro created this revision. ro added reviewers: vitalybuka, MaskRay. ro added a project: Sanitizers. Herald added subscribers: Sanitizers, pengfei, fedor.sergeev, mgorny, jyknight. Herald added a project: clang. ro requested review of this revision. In the initial Solaris ASan port, `GetTls` was lef

[PATCH] D91607: [clang][Sparc] Fix __builtin_extract_return_addr etc.

ro created this revision. ro added reviewers: efriedma, brad. Herald added subscribers: atanasyan, fedor.sergeev, kristof.beyls, arichardson, sdardis, jyknight. Herald added a project: clang. ro requested review of this revision. While investigating the failures of `symbolize_pc.cpp` and `symbol

[PATCH] D91605: [sanitizers] Implement GetTls on Solaris

ro added inline comments. Comment at: compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp:455-520 +#if SANITIZER_SOLARIS +// dlpi_tls_modid is only available since Solaris 11.4 SRU 10. Use +// dlinfo(RTLD_DI_LINKMAP) instead which works on both Solaris 11.3 and Illumos

[PATCH] D91605: [sanitizers] Implement GetTls on Solaris

ro added inline comments. Comment at: clang/lib/Driver/ToolChains/Solaris.cpp:150 + const SanitizerArgs &SA = getToolChain().getSanitizerArgs(); + if (LINKER_SUPPORTS_Z_RELAX_TRANSTLS && + getToolChain().getTriple().getArch() == llvm::Triple::x86_64 &&

[PATCH] D91605: [sanitizers] Implement GetTls on Solaris

ro added inline comments. Comment at: clang/tools/driver/CMakeLists.txt:123 + +check_linker_flag("-Wl,-z,relax=transtls" LINKER_SUPPORTS_Z_RELAX_TRANSTLS) MaskRay wrote: > ro wrote: > > MaskRay wrote: > > > GNU ld reports a warning instead of an error when an unk

[PATCH] D88470: [clangd] Extract options struct for ClangdLSPServer. NFC

ro added a comment. This patch broke builds with `gcc`, e.g. Builder clang-solaris11-amd64 Build #6724 : [23/122] Building CXX object tools/clang/tools/extra/clangd/tool/CMakeFiles/clangd.dir/ClangdMain.cpp.o FAILED: tool

[PATCH] D89130: [WIP][Sparc] Fix long double on 32-bit Solaris/SPARC

ro created this revision. ro added reviewers: efriedma, brad. Herald added subscribers: Sanitizers, s.egerton, dexonsmith, jrtc27, simoncook, fedor.sergeev, hiraditya, mgorny, jyknight. Herald added projects: clang, Sanitizers, LLVM. ro requested review of this revision. The SysVr4 SPARC psABI pr

[PATCH] D91605: [sanitizers] Implement GetTls on Solaris

ro added inline comments. Comment at: clang/tools/driver/CMakeLists.txt:123 + +check_linker_flag("-Wl,-z,relax=transtls" LINKER_SUPPORTS_Z_RELAX_TRANSTLS) MaskRay wrote: > ro wrote: > > MaskRay wrote: > > > ro wrote: > > > > MaskRay wrote: > > > > > GNU ld report

[PATCH] D91605: [sanitizers] Implement GetTls on Solaris

ro updated this revision to Diff 307067. ro added a comment. Herald added a project: LLVM. - Move declarations to new `sanitizer_solaris.h`. - Augment `check_linker_flag` do reject unknown `-z` options that GNU ld noisily accepts. Tested on `amd64-pc-solaris2.11`, `sparcv9-sun-solaris2.11`, and

[PATCH] D91605: [sanitizers] Implement GetTls on Solaris

ro added inline comments. Comment at: clang/tools/driver/CMakeLists.txt:123 + +check_linker_flag("-Wl,-z,relax=transtls" LINKER_SUPPORTS_Z_RELAX_TRANSTLS) MaskRay wrote: > ro wrote: > > MaskRay wrote: > > > ro wrote: > > > > MaskRay wrote: > > > > > ro wrote: > >

[PATCH] D91605: [sanitizers] Implement GetTls on Solaris

ro added inline comments. Comment at: clang/tools/driver/CMakeLists.txt:123 + +check_linker_flag("-Wl,-z,relax=transtls" LINKER_SUPPORTS_Z_RELAX_TRANSTLS) MaskRay wrote: > MaskRay wrote: > > ro wrote: > > > MaskRay wrote: > > > > ro wrote: > > > > > MaskRay wrote

[PATCH] D107559: [clang] Fix libclang linking on Solaris

ro created this revision. ro added reviewers: clang, tstellar, MaskRay. ro added a project: clang. Herald added subscribers: fedor.sergeev, mgorny, jyknight. ro requested review of this revision. Herald added a subscriber: cfe-commits. Linking `libclang.so` is currently broken on Solaris: ld: f

[PATCH] D107559: [clang] Fix libclang linking on Solaris

ro added a comment. In D107559#2928851 , @tstellar wrote: > Is there any kind of comment that is supported by all linkers? Seems there isn't. In that case, we could either move the comments to a separate file (`libclang.README`?), strip the comments wh

[PATCH] D107559: [clang] Fix libclang linking on Solaris

ro added inline comments. Comment at: clang/tools/libclang/libclang.map:1 -/* If you add a symbol to this file, make sure to add it with the correct - * version. For example, if the LLVM main branch is LLVM 14.0.0, add new - * symbols with the version LLVM_14. - * On platforms w

[PATCH] D107559: [clang] Fix libclang linking on Solaris

ro added a comment. Ah, I forgot: I've meanwhile tested the patch on `x86-64-pc-linux-gnu` (Ubuntu 20.04) where `/usr/bin/ld` is from binutils 2.34: `libclang.so` was versioned just the same without and with the patch. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://

[PATCH] D107559: [clang] Fix libclang linking on Solaris

This revision was automatically updated to reflect the committed changes. Closed by commit rGa382a746275b: [clang] Fix libclang linking on Solaris (authored by ro). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D107559/new/ https://reviews.llvm.org/D

[PATCH] D104505: [HIP] Defer operator overloading errors

ro added a comment. This patch broke the Solaris/sparcv9 and Solaris/amd64 buildbots: /opt/llvm-buildbot/home/solaris11-amd64/clang-solaris11-amd64/llvm/clang/include/clang/Sema

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

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

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

ro added a comment. In D130688#3731611 , @glaubitz 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

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

ro added a comment. In D130688#3731653 , @glaubitz wrote: > In D130688#3731619 , @ro wrote: > >> In D130688#3731611 , @glaubitz >> wrote: >> >>> >> >> >> >>> Yeah, someo

[PATCH] D141596: [Driver] Add crtfastmath.o on Solaris if appropriate

ro created this revision. ro added a reviewer: MaskRay. ro added a project: clang. Herald added subscribers: jrtc27, fedor.sergeev, jyknight. Herald added a project: All. ro requested review of this revision. `Flang :: Driver/fast_math.f90` `FAIL`s on Solaris because `crtfastmath.o` is missing fr

[PATCH] D141596: [Driver] Add crtfastmath.o on Solaris if appropriate

This revision was automatically updated to reflect the committed changes. Closed by commit rG7c4a70f8f6f3: [Driver] Add crtfastmath.o on Solaris if appropriate (authored by ro). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D141596/new/ https://revie

<    1   2   3   >