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
@@ -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:
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
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
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
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:
/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 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
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 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:
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
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:
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
__
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:
> 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:
> @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:
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
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
@@ -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:
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
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:
> > 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:
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
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:
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
201 - 229 of 229 matches
Mail list logo
