rorth wrote:
The new check is certainly better since it explicitly excludes anything but
macOS and Linux/**x86_64** which are the only ones that are supported right
now. However, the code still doesn't account for the two possible layouts of
the runtime dir. Rather than hardcoding those thin
rorth wrote:
(Some commenting the code directly didn't work for me ;-)
This check
```
!SystemTriple.isOSLinux()
```
isn't enough: it encompasses any version of Linux, not just Linux/x86_64.
Besides, as I said, `getOrcRuntimePath` currently hardcodes the `runtimes`
layout while one can still u
rorth wrote:
As I've explained, this is not a Solaris issue but one that will affect all
non-macOS non-Linux/x86_64 targets.
https://github.com/llvm/llvm-project/pull/152562
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.or
rorth wrote:
I've done a `Debug` build on `amd64-pc-solaris2.11` and found what's going on.
When the `InterpreterTestBase.SanityWithRemoteExecution` test calls
`getOrcRuntimePath`, it returns a value that is completely wrong:
`/var/llvm/local-amd64-debug-gcc15/lib/clang/22/lib/x86_64-unknown-
rorth wrote:
I've run a `sparc-sun-solaris2.11` 2-stage `Debug` build with this patch. The
build itself went well (with the exception of an unrelated failure to link
`libomp.so`), but test results are still terrible with 455 failures. But it's
still massive improvement compared to before.
H
rorth wrote:
I don't think this is right: the test `PASS`es on Solaris/sparcv9, so this
doesn't seem to be an OS issue.
https://github.com/llvm/llvm-project/pull/152562
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi
https://github.com/rorth closed https://github.com/llvm/llvm-project/pull/150176
___
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/150176
While investigating PR #149990, I noticed that while both the Oracle Studio
compilers and GCC default to `-mv8plus` on 32-bit Solaris/SPARC, Clang does not.
This patch fixes this by enabling the `v8plus` feature.
https://github.com/rorth closed https://github.com/llvm/llvm-project/pull/149990
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rorth wrote:
I've got a follow-up patch to similarly default to `v8plus` on 32-bit
Solaris/SPARC. I wonder if this one or both would be appropriate for the
`release/21.x` branch?
https://github.com/llvm/llvm-project/pull/149990
___
cfe-commits maili
https://github.com/rorth created
https://github.com/llvm/llvm-project/pull/149990
Prompted by PR #149652, this patch changes the Solaris/SPARC default to -mcpu,
matching both the Oracle Studio 12.6 compilers and GCC 16: [[PATCH] Default to
-mcpu=ultrasparc3 on
Solaris/SPARC](https://gcc.gnu.o
rorth wrote:
This needs to go to the `release/21.x` branch, too, to unbreak the
Linux/sparc64 `flang` build.
https://github.com/llvm/llvm-project/pull/149652
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailma
rorth wrote:
/cherry-pick 38fc453afdb6a4511b7c8e189f12a92559ecc396
https://github.com/llvm/llvm-project/pull/149652
___
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/149652
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rorth wrote:
I've now tested the (original version of) the patch on both
`sparc64-unknown-linux-gnu` and `sparcv9-sun-solaris2.11`. The Linux/sparc64
build failure is gone, no regressions on either target.
Btw., prompted by this I've discovered that GCC's `-mcpu=v9` default on
Solaris/SPARC
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
1 - 100 of 229 matches
Mail list logo
