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;
rorth wrote:
The patch also broke the [Solaris/sparcv9
buildbot](https://lab.llvm.org/buildbot/#/builders/13/builds/1579).
https://github.com/llvm/llvm-project/pull/96240
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/c
rorth wrote:
FWIW, the hack even breaks when doing a `Debug` build: in that case the
unresolved reference returns despite the hack.
https://github.com/llvm/llvm-project/pull/100724
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.
@@ -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;
rorth wrote:
> Do we still need to fix this for 19.1.0-final?
I think so, yes. E.g. when building on LLVM without specifying
`LLVM_HOST_TRIPLE` explicitly (like when using `test-release.sh`), the
`config.guess` output is used which is `sparc64-unknown-linux-gnu`. However,
`compiler-rt` alwa
rorth wrote:
Both bots are working again: thanks for the quick fix.
https://github.com/llvm/llvm-project/pull/96171
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rorth wrote:
This patch broke the
[Solaris/amd64](https://lab.llvm.org/staging/#/builders/120/builds/485) and
[Solaris/sparcv9](https://lab.llvm.org/buildbot/#/builders/13/builds/1287)
buildbots.
https://github.com/llvm/llvm-project/pull/96171
___
c
@@ -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;
https://github.com/rorth milestoned
https://github.com/llvm/llvm-project/pull/100091
___
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/100724
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rorth wrote:
Right, as is it's just a ugly hack with the underlying problem like to rear its
ugly head again in the future.
https://github.com/llvm/llvm-project/pull/100724
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org
rorth wrote:
> > Whatever the case, we need at least a short-term solution now: the Solaris
> > buildbots have been broken for two days now.
>
> Agreed that we need something in the short term, I'm just trying to find the
> cleanest "something" under the assumption that this hack will live for
rorth wrote:
> Thank you for helping out with this odd edge case! I don't suppose there's a
> way we can shove this hack into CMake (basically, like a kind of linker
> script hack)? If so, can we apply it broadly enough so that any use of
> `time_put` in other TUs will also benefit?
This woul
https://github.com/rorth created
https://github.com/llvm/llvm-project/pull/100724
The introduction of `std::put_time` in
fad17b43dbc09ac7e0a95535459845f72c2b739a broke the Solaris build:
```
Undefined first referenced
symbol in file
_ZNKSt8time_
rorth wrote:
> > At least in the short term. ISTM that `clang++` may need to do something
> > along the lines of Bug 33767 (resp. the underlying GCC bug/patch),
> > otherwise users are in for a nasty surprise.
>
> Agreed; long-term we need a better solution. Hopefully someone maintaining
> So
rorth wrote:
At least in the short term. ISTM that `clang++` may need to do something along
the lines of Bug 33767 (resp. the underlying GCC bug/patch), otherwise users
are in for a nasty surprise.
https://github.com/llvm/llvm-project/pull/99075
___
rorth wrote:
> If you dump the symbols from the STL shared library on the system, is there
> one for `time_put` at all? If so, what is the mangled symbol it exports?
While the source requires
```
_ZNKSt8time_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE3putES3_RSt8ios_basecPKSt2tmPKcSB_
s
1 - 100 of 198 matches
Mail list logo
