rorth wrote:
This patch also broke [the Solaris/sparcv9
bot](https://lab.llvm.org/buildbot/#/builders/13/builds/8151). At the very
least `llvm/test/Transforms/Coroutines/coro-split-dbg-labels.ll` needs to
require x86 support.
https://github.com/llvm/llvm-project/pull/141937
_
rorth wrote:
I'd already acknowledged the failure and provided a possible 1-line patch
(which I cannot test). Instead of doing that, you chose to revert.
I'm totally tired of that constant merge/revert/reland/revert/... churn that is
so typical of LLVM. I can fully understand reversal if a p
rorth wrote:
I'm tired of this constant churn: couldn't you have waited a bit longer? This
is just spare-time work, not a paid job.
https://github.com/llvm/llvm-project/pull/145855
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists
rorth wrote:
The `llvm-clang-x86_64-sie-ubuntu-fast` builder is an other cross setup:
```
LLVM host triple: x86_64-unknown-linux-gnu
LLVM default target triple: x86_64-scei-ps4
```
I strongly suspect we need `REQUIRES: native` rather than `XFAIl: !native`.
https://github.com/llvm/llv
rorth wrote:
> > the remaining failures seem all to be XPASSes on AArch64. I guess it's time
> > to just remove aarch64 from the XFAIL in bindings.sh then
>
> Sounds great! Two more things from my side:
>
> 1. Please resolve the conflict so CI can run.
Done now.
> 2. You removed the
rorth wrote:
With the exception of `llvm-clang-win-x-armv7l` (another cross build), the
remaining failures seem all to be `XPASS`es on AArch64. I guess it's time to
just remove `aarch64` from the `XFAIL` in `bindings.sh` then, something that
would never have been noticed with the old `RUN_PYT
@@ -0,0 +1,35 @@
+#!/bin/sh
+
+# UNSUPPORTED: !libclang-loadable
+
+# Tests fail on Windows, and need someone knowledgeable to fix.
+# It's not clear whether it's a test or a valid binding problem.
+# XFAIL: target={{.*windows.*}}
rorth wrote:
I suspected somethi
rorth wrote:
> I reverted this in #145774 since it causes build-failures. It seems that the
> substitution `` CLANG_LIBRARY_PATH=`llvm-config --libdir `` doesn't work in
> some cases
Thanks. When the failure reports began to trickle in, I started investigating,
but it got very late.
I'd bee
https://github.com/rorth closed https://github.com/llvm/llvm-project/pull/142948
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rorth edited https://github.com/llvm/llvm-project/pull/142948
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rorth wrote:
> You can fix the code formatting if you want to, but I can also do this
> separately... since it's completely unrelated to what you did.
I'd rather you do it separately: it feels strange to change code when the
source is merely moved around. Thanks.
https://github.com/llvm/llvm
rorth wrote:
Both the original patch and the redo break the [Solaris/amd64
buildbot](https://lab.llvm.org/staging/#/builders/120/builds/9897). I wonder
if somehow the fact that the source lives in `/opt/llvm-buildbot` somehow
interferes with Windows command line parsing?
https://github.com/l
@@ -33,7 +33,9 @@ jobs:
python-version: ["3.8", "3.13"]
uses: ./.github/workflows/llvm-project-tests.yml
with:
- build_target: check-clang-python
+ build_target: libclang
+ run: |
+llvm-lit -v tools/clang/test --filter=bindings.sh
rorth wrote:
I'll try. Hope not to make a total mess again like last time...
https://github.com/llvm/llvm-project/pull/142948
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rorth wrote:
> I still don't entirely understand how lit works exactly, but it seems to me
> that completely removing the cmake target for this is not necessary, no? So
> at least this wouldn't require the CI changes on top of the other changes.
> Happy to hear your thoughts on this though @ro
https://github.com/rorth updated
https://github.com/llvm/llvm-project/pull/142948
>From e57e53c7e5abdb4c390a04b4ce9084dec9e71dd5 Mon Sep 17 00:00:00 2001
From: Rainer Orth
Date: Thu, 5 Jun 2025 13:40:26 +0200
Subject: [PATCH 1/3] [clang][python][test] Move python binding tests to lit
framework
rorth wrote:
> > I wonder if there's a way to recover from my mess, like (in my local repo)
>
> What's preventing you from doing exactly that?
Worry that it might make things even worse. Fortunately, it worked just fine,
so you can finally see what my current PR is about.
> > The weird thing
https://github.com/rorth updated
https://github.com/llvm/llvm-project/pull/142948
>From e57e53c7e5abdb4c390a04b4ce9084dec9e71dd5 Mon Sep 17 00:00:00 2001
From: Rainer Orth
Date: Thu, 5 Jun 2025 13:40:26 +0200
Subject: [PATCH 1/2] [clang][python][test] Move python binding tests to lit
framework
rorth wrote:
> > am at a bit of a loss how to handle build_target now [...] Don't know
> > if/how I can test this myself.
>
> All the `check-clang-python` did is depend on the `libclang` target and then
> call unittest, so I think it should be enough to change the `build_target` to
> `libclan
rorth wrote:
Two issues are worth mentioning about the updated PR:
- Although I'd originally disabled the Clang Python tests on SPARC in [[python,
tests] Disable Clang Python tests on SPARC](https://reviews.llvm.org/D60046),
they now `PASS` on Solaris/sparcv9, while on Linux/sparc64 `python` `S
@@ -0,0 +1,22 @@
+def is_libclang_loadable():
+try:
+sys.path.append(os.path.join(config.clang_src_dir, "bindings/python"))
+from clang.cindex import Config
+conf = Config()
+Config.set_library_path(config.clang_lib_dir)
+conf.lib
+
https://github.com/rorth updated
https://github.com/llvm/llvm-project/pull/142948
>From e57e53c7e5abdb4c390a04b4ce9084dec9e71dd5 Mon Sep 17 00:00:00 2001
From: Rainer Orth
Date: Thu, 5 Jun 2025 13:40:26 +0200
Subject: [PATCH 1/2] [clang][python][test] Move python binding tests to lit
framework
https://github.com/rorth closed https://github.com/llvm/llvm-project/pull/142353
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rorth wrote:
Superceded by PR #142948.
https://github.com/llvm/llvm-project/pull/142353
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rorth wrote:
> @rorth have you tested that your `is_libclang_loadable` works as intended
> w.r.t the "Benign error modes"? Do correct me if I made a mistake here, but I
> just tried testing this by manually adding `raise Exception("wrong ELF class:
> ELFCLASS32")` at the start of `get_cindex_l
@@ -0,0 +1,22 @@
+def is_libclang_loadable():
+try:
+sys.path.append(os.path.join(config.clang_src_dir, "bindings/python"))
+from clang.cindex import Config
+conf = Config()
+Config.set_library_path(config.clang_lib_dir)
+conf.lib
+
rorth wrote:
> Thank you for the PR, imo this is a much better approach than the previous
> one.
Thanks. The previous approach was just a minimal fix (hack?) to avoid breaking
the build in a specific situation. This one (if completed) should handle all
known issues with Python bindings test
rorth wrote:
I've now created PR #142948 with an initial implementation of `lit` integration
of the `clang` Python bindings tests.
https://github.com/llvm/llvm-project/pull/142353
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.l
https://github.com/rorth created
https://github.com/llvm/llvm-project/pull/142948
As discussed in PR #142353, the current testsuite of the `clang` Python
bindings has several issues:
- It `libclang.so` cannot be loaded into `python` to run the testsuite, the
whole `ninja check-all` aborts.
-
rorth wrote:
FWIW I now have a prototype of the python tests within the `lit` framework.
The basics (`PASS` if `python` and `libclang.so` match, `FAIL` if not) work,
but there's more to be done:
- The test should be `UNSUPPORTED` when `libclang.so` cannot be loaded.
- The various ways `RUN_PYT
rorth wrote:
> @rorth Now that #142371 is merged, can you re-evaluate this PR and update the
> description?
This PR changed the output from completely silent to excessively verbose: I now
get
```
FAILED: tools/clang/bindings/python/tests/CMakeFiles/check-clang-python
/var/llvm/local-i386-rele
rorth wrote:
> and couldn't find much on it either, but that sounds like
>
> > Alternatively, as I suggested, one could wrap the actual python -m unittest
> > discover invocation with a check if libclang.so is loadable at all, only
> > then running the actual test.
Indeed: one should move the
rorth wrote:
> > trying to load a 32-bit libclang.so into a 64-bit python is always an
> > error, testsuite or no.
>
> That's why you shouldn't return an exit code of 0 when this error occurs.
> Moreover, this seems like a workaround for that one specific issue you
> encountered. To connect t
rorth wrote:
> Thank you for the PR. Several points:
>
> 1. What happens on Windows?
I have no idea, knowing nothing at all about Windows. I cannot even tell if a
similar situation can arise there, i.e. if you can execute 32-bit programs on a
64-bit Windows and, if you can, what the mess
https://github.com/rorth created
https://github.com/llvm/llvm-project/pull/142353
When building a 32-bit `clang` on a 64-bit system (like `i686-pc-linux-gnu` on
a Linux/x86_64 system), `ninja check-all` fails:
```
FAILED: tools/clang/bindings/python/tests/CMakeFiles/check-clang-python
tools/c
rorth wrote:
The Solaris/amd64 bot is green again, thanks.
I'd tried to reproduce the failure locally yesterday, but weirdly couldn't: no
idea what's the difference between the bot and
my local builds.
https://github.com/llvm/llvm-project/pull/140874
___
rorth wrote:
This patch broke the [Solaris/amd64
buildbot](https://lab.llvm.org/staging/#/builders/120/builds/8977). I suspect
the test should use `--target=i386-pc-windows` instead of just `i386`?
https://github.com/llvm/llvm-project/pull/140874
__
@@ -355,6 +349,9 @@ function(add_link_opts target_name)
set_property(TARGET ${target_name} APPEND_STRING PROPERTY
LINK_FLAGS " -Wl,-brtl")
endif()
+
+ check_linker_flag(CXX "-Wl,-Bsymbolic-functions"
rorth wrote:
**Please** don't go thi
rorth wrote:
/cherry-pick e71c8ea3cc73c8f7b0382468f355a254166d3a72
https://github.com/llvm/llvm-project/pull/137141
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rorth wrote:
Drats, I'd hoped the markup would inhibit the cherry pick directive from being
picked up.
I've now dropped the patch into local LLVM 20.1.5 builds on both
`amd64-pc-solaris2.11` and `sparcv9-sun-solaris2.11`. It applied cleanly and
introduced no regressions. I'll try a regular
rorth wrote:
> @rorth Can you please check this on Solaris?
I've now tested the patch on `amd64-pc-solaris2.11` with both the native linker
(which doesn't support` -Bsymbolic-functions`) and GNU `ld` (which does) as
well as `sparcv9-sun-solaris2.11` with `/bin/ld`: no regressions on either,
w
rorth wrote:
No. However, I got an
[error](https://github.com/llvm/llvm-project/actions/runs/14798017932) for the
`/cherry-pick` that looks like some weird internal error to me, not a failed
merge attempt or some such.
https://github.com/llvm/llvm-project/pull/137141
https://github.com/rorth closed https://github.com/llvm/llvm-project/pull/138466
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rorth wrote:
> It's not due to non-Unix hosts. It's likely due to these builds setting
> CLANG_DEFAULT_RTLIB and CLANG_DEFAULT_UNWINDLIB.
That occured to me shortly after I created the PR. I'll fix the description
accordingly.
https://github.com/llvm/llvm-project/pull/138466
rorth wrote:
I've just created PR #138466 which hopefully fixes those failures. Can anyone
affected please give this a try?
https://github.com/llvm/llvm-project/pull/137596
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.or
https://github.com/rorth created
https://github.com/llvm/llvm-project/pull/138466
`Clang :: Driver/solaris-ld.c` currently `FAIL`s on two non-Unix buildbots:
[fuchsia-x86_64-linux](https://lab.llvm.org/buildbot/#/builders/11/builds/14369)
and
[llvm-clang-win-x-aarch64](https://lab.llvm.org/bui
rorth wrote:
I suspect the `-static-libgcc` test needs `-rtlib=platform
--unwindlib=platform` to pass on non-UNIX platforms. However, I've no way of
verifying that. Can someone with access to either affected targets please try
this? Thanks.
https://github.com/llvm/llvm-project/pull/137596
https://github.com/rorth closed https://github.com/llvm/llvm-project/pull/137596
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rorth wrote:
This patch is required to build `flang` on Solaris/amd64. Until very recently,
a 2-stage build of `main` with `flang` included worked with `clang-20` as build
compiler since `flang` was only built in stage 2 and the freshly built
`clang-21` does include the patch.. However, now
rorth wrote:
/cherry-pick e71c8ea3cc73c8f7b0382468f355a254166d3a72
https://github.com/llvm/llvm-project/pull/137141
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rorth milestoned
https://github.com/llvm/llvm-project/pull/137141
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rorth created
https://github.com/llvm/llvm-project/pull/137596
When linking `libomp.so` on Solaris, I encountered
```
clang: warning: argument unused during compilation: '-static-libgcc'
[-Wunused-command-line-argument]
```
This happens because `Solaris.cpp` (`solaris::Linke
https://github.com/rorth closed https://github.com/llvm/llvm-project/pull/137141
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rorth created
https://github.com/llvm/llvm-project/pull/137141
Since commit 613a077b05b8352a48695be295037306f5fca151, `flang` doesn't build
any longer on Solaris/amd64:
```
flang/lib/Evaluate/intrinsics-library.cpp:225:26:
error: address of overloaded function 'acos' does not
rorth wrote:
Both Solaris bots are back green again. Thanks.
https://github.com/llvm/llvm-project/pull/119387
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rorth wrote:
The patch also breaks both the
[Solaris/sparcv9](https://lab.llvm.org/buildbot/#/builders/13/builds/6362) and
[Solaris/amd64](https://lab.llvm.org/staging/#/builders/120/builds/7512) bots.
https://github.com/llvm/llvm-project/pull/119387
___
rorth wrote:
Thanks for the reversal. I've meanwhile determined in a local
`sparcv9-sun-solaris2.11` all-targets build that the test still `FAIL`ed even
with the `X86` target configured.
https://github.com/llvm/llvm-project/pull/132723
___
cfe-commi
rorth wrote:
Usually the SPARC-only `clang` will reject any non-`sparc*` triple as
unsupported. However, there are cases where they still work; I never
understood when this works and when it doesn't.
https://github.com/llvm/llvm-project/pull/132723
rorth wrote:
I fear it won't, unfortunately: the Solaris builders (and no doubt others) are
configured to support only the native target (`sparc*` in the current case),
not necessarily x86.
https://github.com/llvm/llvm-project/pull/132723
___
cfe-com
rorth wrote:
This patch broke the [Solaris/sparcv9
bot](https://lab.llvm.org/buildbot/#/builders/13/builds/6151).
https://github.com/llvm/llvm-project/pull/132723
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/m
rorth wrote:
When comparing the `clang` invocations between Solaris/amd64 (test `PASS`es)
and Solaris/sparcv9 (test `FAIL`s), I find this crucial difference:
```
-"-funwind-tables=2"
-"-target-cpu"
-"x86-64"
-"-tune-cpu"
-"generic"
+"-mfloat-abi"
+"hard"
```
Looking closer, `-target-cpu` is only
rorth wrote:
This patch still breaks the [Solaris/sparcv9
buildbot](https://lab.llvm.org/buildbot/#/builders/13/builds/5233).
https://github.com/llvm/llvm-project/pull/125646
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm
rorth wrote:
This broke the [Solaris/sparcv9
bot](https://lab.llvm.org/buildbot/#/builders/13/builds/3268).
https://github.com/llvm/llvm-project/pull/114485
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman
https://github.com/rorth closed https://github.com/llvm/llvm-project/pull/106353
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rorth edited https://github.com/llvm/llvm-project/pull/106353
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rorth edited https://github.com/llvm/llvm-project/pull/106353
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rorth updated
https://github.com/llvm/llvm-project/pull/106353
>From 646c6ad032fe9c15faee03246496958f7592ea75 Mon Sep 17 00:00:00 2001
From: Rainer Orth
Date: Wed, 28 Aug 2024 11:24:29 +0200
Subject: [PATCH 1/3] [WIP][clang] Fix std::tm etc. mangling on Solaris
Recently, Sol
rorth wrote:
> > just leads to infinite recursion (obviously),
>
> Try casting the pointer to uintptr_t?
That just created a total mess, unfortunately, like duplicating args or
dropping the `*` from `char const *`.
> Might be simpler to mess with CXXNameMangler::mangleUnscopedName, though,
>
rorth wrote:
FWIW, the same failures exist on Linux/sparc64, too.
https://github.com/llvm/llvm-project/pull/106951
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rorth wrote:
In a local `sparcv9-sun-solaris2.11` build, I get (with `-silence-passes`
removed)
```
> /var/llvm/dist-sparcv9-release-stage2-A-flang-clang19/tools/clang/stage2-bins/bin/bugpoint
> -load
> /var/llvm/dist-sparcv9-release-stage2-A-flang-clang19/tools/clang/stage2-bins/lib/BugpointP
rorth wrote:
Incorporate review comments. However, I still have a mis-mangling of the code
that triggered this patch. I've now been able to create a reduced example:
```
namespace std {
extern "C" {
struct tm {
int tm_sec;
};
}
}
using std::tm;
void
func (std::tm tm, const
https://github.com/rorth updated
https://github.com/llvm/llvm-project/pull/106353
>From 646c6ad032fe9c15faee03246496958f7592ea75 Mon Sep 17 00:00:00 2001
From: Rainer Orth
Date: Wed, 28 Aug 2024 11:24:29 +0200
Subject: [PATCH 1/2] [WIP][clang] Fix std::tm etc. mangling on Solaris
Recently, Sol
https://github.com/rorth closed https://github.com/llvm/llvm-project/pull/107403
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rorth wrote:
> Curios, why Asan when there is Sparc ADI?
Various reasons:
- Because I can, and `gcc` already does ;-)
- Symmetry with other targets.
- ADI is 64-bit only, while ASan could support both 32 and 64-bit (currently
only the former, though).
- ADI toolchain support is quite mixed righ
https://github.com/rorth edited https://github.com/llvm/llvm-project/pull/107403
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rorth edited https://github.com/llvm/llvm-project/pull/107403
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rorth wrote:
Ping? ASan results on Solaris/sparcv9 are now one failure away from clean with
current PR #107223.
https://github.com/llvm/llvm-project/pull/107403
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/ma
rorth wrote:
Just for the record: in a 2-stage `sparc64-unknown-linux-gnu` build, the
failures occur, too. So nothing Solaris-specific in here. Maybe endianess?
https://github.com/llvm/llvm-project/pull/108949
___
cfe-commits mailing list
cfe-commit
rorth wrote:
This is weird: I'd initially tried both all-targets and sparc-only builds, and
in neither case did the failures occur. However, those were 2-stage builds (as
I usually use). When I switched to a 1-stage build with `clang-19` as build
compiler, I get the same failure as on the bo
rorth wrote:
I've now tested the patch on both `sparcv9-sun-solaris2.11` and
`amd64-pc-solaris2.11`: no failures.
https://github.com/llvm/llvm-project/pull/108570
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/m
rorth wrote:
Seems so, yes. Could also be an endianess thing. I know nothing about this
test, though.
https://github.com/llvm/llvm-project/pull/108949
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/lis
rorth wrote:
No, that doesn't exist. The failure will occur on any non-x86 build configure
with `-DLLVM_TARGETS_TO_BUILD=`.
AFAICS the tests just need
```
// REQUIRES: x86-registered-target
```
https://github.com/llvm/llvm-project/pull/108949
___
cf
https://github.com/rorth closed https://github.com/llvm/llvm-project/pull/109278
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rorth wrote:
Good, that considerably simplifies non-native testing:
- The original patch ignored the issue because I had no idea how to handle it.
- The first version of this one used the hack of checking `uname -v`. While
this works, it's still wrong since this checks the host distro, not the
rorth wrote:
This patch broke the [Solaris/sparcv9
buildbot](https://lab.llvm.org/buildbot/#/builders/13/builds/2437). The two
affected tests use `-triple x86_64-linux-gnu` without requiring x86 support.
https://github.com/llvm/llvm-project/pull/108949
rorth wrote:
Just to be certain: the revised version of the patch is ok to commit?
https://github.com/llvm/llvm-project/pull/109278
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rorth updated
https://github.com/llvm/llvm-project/pull/109278
>From 9123b7eae524418d0a671ac2114ddea2b2cf9695 Mon Sep 17 00:00:00 2001
From: Rainer Orth
Date: Thu, 19 Sep 2024 14:46:54 +0200
Subject: [PATCH 1/2] [Driver][Sparc] Default to -mcpu=v9 for 32-bit
Linux/sparc64
W
https://github.com/rorth updated
https://github.com/llvm/llvm-project/pull/109278
>From 9123b7eae524418d0a671ac2114ddea2b2cf9695 Mon Sep 17 00:00:00 2001
From: Rainer Orth
Date: Thu, 19 Sep 2024 14:46:54 +0200
Subject: [PATCH 1/2] [Driver][Sparc] Default to -mcpu=v9 for 32-bit
Linux/sparc64
W
rorth wrote:
> We try to restrict distribution differences to things like default linker
> options and library paths. Affecting `-mcpu=` seems very unintuitive. There
> are many Debian derivatives. It's weird that Debian uses -mcpu=v9 while
> others use -mcpu=v8. We should not increase `IsDebi
@@ -125,7 +126,9 @@ std::string sparc::getSparcTargetCPU(const Driver &D, const
ArgList &Args,
return std::string(CPUName);
}
- if (Triple.getArch() == llvm::Triple::sparc && Triple.isOSSolaris())
+ Distro Dist(D.getVFS(), Triple);
+ if (Triple.getArch() == llvm::Tri
rorth wrote:
@glaubitz
https://github.com/llvm/llvm-project/pull/109278
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rorth created
https://github.com/llvm/llvm-project/pull/109278
While working on supporting PR #109101 on Linux/sparc64, I was reminded that
`clang -m32` still defaults to generating V8 code, although the 64-bit kernel
requires a V9 CPU.
This patch corrects that on V9-only d
rorth wrote:
I can confirm that the patch fixes the error I'm seeing on the Solaris
buildbots. Thanks.
https://github.com/llvm/llvm-project/pull/109050
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/lis
https://github.com/rorth created
https://github.com/llvm/llvm-project/pull/107403
Once PR #107223 lands, ASan can be enabled on Solaris/SPARC. This patch does
just that. As on Solaris/x86, the dynamic ASan runtime lib needs to be linked
with `-z now` to avoid an `AsanInitInternal` cycle.
Te
rorth wrote:
> clang/docs/ReleaseNotes.rst
Ah, that. I was thinking of the GNU style `ChangeLog` files. Done locally;
will push once the remaining mangling error has been fleshed out.
https://github.com/llvm/llvm-project/pull/106353
___
cfe-commits
rorth wrote:
> Can you also add a changelog entry? Thanks!
I've never seen them used in LLVM. Has that changed recently?
https://github.com/llvm/llvm-project/pull/106353
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/c
@@ -6953,6 +6954,27 @@ bool CXXNameMangler::mangleStandardSubstitution(const
NamedDecl *ND) {
return false;
}
+ if (getASTContext().getTargetInfo().getTriple().isOSSolaris()) {
+if (const RecordDecl *RD = dyn_cast(ND)) {
+ if (!isStdNamespace(Context.getEffect
@@ -1604,10 +1604,12 @@ static bool isTargetVariantEnvironment(const TargetInfo
&TI,
return false;
}
-#if defined(__sun__) && defined(__svr4__)
+#if defined(__sun__) && defined(__svr4__) && defined(__clang__) &&
\
+__clang__ < 20
rorth wrot
https://github.com/rorth created
https://github.com/llvm/llvm-project/pull/106353
Recently, Solaris bootstrap got broken because Solaris uses a non-standard
mangling of `std::tm` and a few others. This was fixed with a hack in PR
Solaris ABI requirements, mangling `std::tm` as `tm` and simila
@@ -766,9 +766,19 @@ ToolChain::getTargetSubDirPath(StringRef BaseDir) const {
return {};
};
- if (auto Path = getPathForTriple(getTriple()))
+ llvm::Triple Triple = getTriple();
+
+ // Try triple as is.
+ if (auto Path = getPathForTriple(Triple))
return *Path;
1 - 100 of 214 matches
Mail list logo
