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
rorth wrote:
> Aha!
>
> https://bugs.llvm.org/show_bug.cgi?id=33767
Ah, old sins (from the GCC side no less) keep haunting me.
> We have a mixture of both `std::tm` and `::tm` in here, try switching to
> using `::tm` and see if that helps.
Unfortunately not: I always get the undefined refere
rorth wrote:
This seems to have broken the
[Solaris/amd64](https://lab.llvm.org/staging/#/builders/120/builds/187) and
[Solaris/sparcv9](https://lab.llvm.org/buildbot/#/builders/13/builds/1030)
buildbots.
https://github.com/llvm/llvm-project/pull/99075
https://github.com/rorth created
https://github.com/llvm/llvm-project/pull/100091
As explained in [[Driver] Support non-canonical triples with new runtime lib
layout](https://reviews.llvm.org/D133407), there are massive problems if
`clang`'s and `compiler-rt`'s ideas of the target triple don't
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 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 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:
> > 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
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
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
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
rorth wrote:
> ⚠️ C/C++ code formatter, clang-format found issues in your code. ⚠️
> You can test this locally with the following command:
> View the diff from clang-format here.
>
> ```diff
> diff --git a/compiler-rt/lib/safestack/safestack_platform.h
> b/compiler-rt/lib/safestack/safestack_pl
rorth wrote:
The mentioned patch to switch safestack to use the `sanitizer_common` functions
instead of their own ones in `sanitizer_platform.h` has to wait until this one
is approved: AFAIT github doesn't support stacked pull requests.
https://github.com/llvm/llvm-project/pull/98001
_
https://github.com/rorth created https://github.com/llvm/llvm-project/pull/98001
At the end of the recent flurry of Illumos (and implicitly Solaris) safestack
patches, the tests were disabled in
b0260c5b1052f8e3ff1ec77dc42a11f42da762cc without explanation.
After re-enabling them, there were man
rorth wrote:
This patch broke the
[Solaris/amd64](https://lab.llvm.org/staging/#/builders/94/builds/4729)
buildbot.
For god's sake, can you please either test your Illumos patches on Solaris, too
(there are Solaris buildbots in the cfarm for exactly such a purpose) and
finally handle Issue #
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/
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
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:
The libcalls per se wouldn't be a problem since on 32-bit Solaris/sparc
`-latomic` is always linked due to that. However, the `__sync_*` libcalls
aren't defined in `libatomic.so`, thus the link failure.
https://github.com/llvm/llvm-project/pull/73176
_
rorth wrote:
Confirmed: reverting the patch locally restores the build.
https://github.com/llvm/llvm-project/pull/73176
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rorth wrote:
I'm pretty certain this patch broke the [Solaris/sparcv9
buildbot](https://lab.llvm.org/buildbot/#/builders/72/builds/2541).
https://github.com/llvm/llvm-project/pull/73176
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://l
rorth wrote:
> `embmedany` is already rejected by the driver at the moment:
>
> ```
> error: unsupported argument 'embmedany' to option '-mcmodel=' for target
> 'sparc64'
> ```
Seems sensible indeed.
> On the testing issue, however, would compiling LLVM with each of the code
> models + running
rorth wrote:
GCC also supports `-mcmodel=embmedany`. Maybe it would be good to reject that
with a clear message?
As for the generated code (not this PR, I'd say), it would certainly be good to
test that on some larger code base (like LLVM itself) and, preferably, also
test actual interoperab
rorth wrote:
This patch broke both the
[Solaris/sparcv9](https://lab.llvm.org/buildbot/#/builders/72/builds/2015) and
[Solaris/amd64](https://lab.llvm.org/staging/#/builders/94/builds/394)
buildbots.
If it really requires recent `lld`, this is guaranteed to not work: `lld`
hasn't even been p
rorth wrote:
I wonder what the current flurry of patdhes to support Illumos is about. I'd
originally filed Issue #53919 to make clear what's needed from the Illumos
project to keep it as an LLVM target, given that they haven't contributed
either bug reports, code or testing in a long time. W
rorth wrote:
However, the patch broke the [Solaris/sparcv9
buildbot](https://lab.llvm.org/buildbot/#/builders/72/builds/1834):
```
llc: error: unable to get target for 'x86_64-unknown-linux-gnu', see --version
and --triple.
```
The bot is configured to do a Sparc-only build.
https://github.com
rorth wrote:
Sure: I've just created one slightly changed from the attached patch: [[flang]
Handle missing LOGIN_NAME_MAX definition in
runtime](https://github.com/llvm/llvm-project/pull/5)
https://github.com/llvm/llvm-project/pull/74628
___
cfe-
rorth wrote:
This patch broke the Solaris build:
```
FAILED: tools/flang/runtime/CMakeFiles/obj.FortranRuntime.dir/extensions.cpp.o
[...]
/vol/llvm/src/llvm-project/dist/flang/runtime/extensions.cpp:60:24: error: use
of undeclared identifier 'LOGIN_NAME_MAX'
60 | const int nameMaxLen{LOGIN
rorth wrote:
This patch broke the [Solaris/sparcv9
buildbot](https://lab.llvm.org/buildbot/#/builders/72/builds/1709): the
new/changed tests `FAIL` with
```
File
/opt/llvm-buildbot/home/solaris11-sparcv9/clang-solaris11-sparcv9/llvm/clang/test/SemaCXX/format-strings-scanf.cpp
Line 25: _Floa
rorth wrote:
> I'll give such a patch a try...
That would be something like
```
int internal_fork(void) {
// Call syscall directly to avoid pthread_atfork handler processing.
//
// This is highly unportable on Solaris since syscalls are an implementation
// detail subject to change.
re
rorth wrote:
It took me a bit to notice this snippet in `sanitizer_solaris.cpp`:
```
DECLARE__REAL_AND_INTERNAL(int, fork, void) {
// TODO(glider): this may call user's pthread_atfork() handlers which is bad.
return _REAL(fork)();
}
```
which didn't show up in searches for `internal_fork`.
>
rorth wrote:
Since this patch, all asan tests loop on Solaris. This had been hidden for a
bit by an unrelated extended build breakage on the bots, but now every `ninja
check-all` on the Solaris/amd64 bot times out. I could trace this to this
patch.
E.g. when running
`projects/compiler-rt/t
rorth wrote:
This patch broke builders like
[Solaris/amd64](https://lab.llvm.org/staging/#/builders/8/builds/761) that
include `clang-tools-extra`.
https://github.com/llvm/llvm-project/pull/70543
___
cfe-commits mailing list
cfe-commits@lists.llvm.or
https://github.com/rorth closed https://github.com/llvm/llvm-project/pull/70322
___
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/70322
As discussed in [[Driver] Link Flang runtime on
Solaris](https://github.com/llvm/llvm-project/pull/65644), `clang -r`
incorrectly passes both `-Bdynamic` and `-e _start` to `ld` which lets the
linker choke.
This
rorth wrote:
This patch also broke the [Solaris/amd64
buildbot](https://lab.llvm.org/staging/#/builders/8/builds/484). I suspect
this happens because that one is configured with `-DLLVM_TARGETS_TO_BUILD=X86`,
thus lacking cuda support. In fact, when manually building with support for
all ta
https://github.com/rorth closed https://github.com/llvm/llvm-project/pull/65644
___
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/65644
>From 31bdd3477d9f54996b71584598bdd75f2cef31db Mon Sep 17 00:00:00 2001
From: Rainer Orth
Date: Thu, 7 Sep 2023 19:19:32 +0200
Subject: [PATCH 1/3] [Driver] Link Flang runtime on Solaris
I noticed that `flang-new`
@@ -21,12 +22,12 @@
! run on any other platform, such as Windows that use a .exe
! suffix. Clang's driver will try to resolve the path to the ld
! executable and may find the GNU linker from MinGW or Cygwin.
-! GNU-LABEL: "{{.*}}ld{{(\.exe)?}}"
-! GNU-SAME: "
1 - 100 of 160 matches
Mail list logo
