@@ -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:
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
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:
I strongly suspect that this patch badly broke the [Solaris/sparcv9
buildbot](https://lab.llvm.org/buildbot/#/builders/72/builds/4046): it
introduced more than 1000 failures.
Please fix or revert.
https://github.com/llvm/llvm-project/pull/86912
___
rorth wrote:
> I'll revert this. Due to I can't reproduce this. When the bot gets stable,
> please tell if it is the real problem.
You can reproduce this: the [GCC compile farm](https://portal.cfarm.net/) does
have a Solaris/sparcv9 system (`cfarm215`) which is perfectly equipped to run
LLVM
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
@@ -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
@@ -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
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
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
https://github.com/rorth created https://github.com/llvm/llvm-project/pull/98124
`clang` currently fails to find a GCC installation on Linux/sparc64 with
`-m32`. `strace` reveals that `clang` tries to access
`/usr/lib/gcc/sparcv9-linux-gnu` (which doesn't exist) instead of
`/usr/lib/gcc/sparc
https://github.com/rorth closed https://github.com/llvm/llvm-project/pull/98124
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rorth wrote:
> They look quite independent. Would be possible to split independent fixed
> into a separate patches?
With the exception of the `-u` reordering, they are all Solaris-only, so I kept
them together to avoid tons of micro-patches. I certainly could split them if
you prefer, someth
rorth wrote:
> > The problem is that -u __safestack_init was passed to the linker after the
> > corresponding version of libclang_rt.safestack-*.a. Since the Solaris
> > linker (like Unix linkers for decades) respect
>
> I agree this part should be extracted since it affects other systems. Oth
https://github.com/rorth created https://github.com/llvm/llvm-project/pull/98468
When re-enabling safestack testing on Solaris after the unexplained
b0260c5b1052f8e3ff1ec77dc42a11f42da762cc, all tests `FAIL`ed to link:
```
Undefined first referenced
symbol
rorth wrote:
This patch was already approved in [ [safestack] Various Solaris fixes #98001
](https://github.com/llvm/llvm-project/pull/98001), therefore I'll commit it
shortly.
https://github.com/llvm/llvm-project/pull/98468
___
cfe-commits mailing l
https://github.com/rorth closed https://github.com/llvm/llvm-project/pull/98468
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rorth wrote:
This is certainly a case of unaligned access. In a local build, I've run the
first failing `clang` invocation under `truss` (the Solaris syscall tracer).
For
```
/var/llvm/dist-sparcv9-release-stage2-A-flang-clang18/tools/clang/stage2-bins/bin/clang
-cc1 -internal-isystem
/var/
Author: Rainer Orth
Date: 2022-02-02T19:20:02+01:00
New Revision: efdd0a29b7eb6f3b6ca3fe9182a6c1085806c73a
URL:
https://github.com/llvm/llvm-project/commit/efdd0a29b7eb6f3b6ca3fe9182a6c1085806c73a
DIFF:
https://github.com/llvm/llvm-project/commit/efdd0a29b7eb6f3b6ca3fe9182a6c1085806c73a.diff
L
Author: Rainer Orth
Date: 2022-02-22T20:14:33+01:00
New Revision: b1fc966d2e4176e640cda52c7148f565e93bedd0
URL:
https://github.com/llvm/llvm-project/commit/b1fc966d2e4176e640cda52c7148f565e93bedd0
DIFF:
https://github.com/llvm/llvm-project/commit/b1fc966d2e4176e640cda52c7148f565e93bedd0.diff
L
@@ -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 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
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,
>
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
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
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
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:
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
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:
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
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:
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:
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:
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:
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
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
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:
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:
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:
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/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:
@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
@@ -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
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:
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
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:
> 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
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:
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:
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:
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:
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:
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
101 - 160 of 160 matches
Mail list logo
