https://github.com/mstorsjo approved this pull request.
LGTM, thanks for adding the test!
https://github.com/llvm/llvm-project/pull/78912
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commit
https://github.com/mstorsjo commented:
Code wise, this seems good, but I think we'd like to have a testcase for it.
https://github.com/llvm/llvm-project/pull/78912
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/m
mstorsjo wrote:
> > I don't really know more about the issue that requires --long-plt at the
> > moment and why it's only needed for clang-repl
>
> clang-repl binary size is ~3.7G in debug mode and this seems to exceed the
> branch range of default ARM PLT slots. The instruction sequence that'
mstorsjo wrote:
> Oh, I usually don't do that, but it's certainly a valid point. Can you think
> of a better way to express the condition here? We need `-Wl,--long-plt` for
> ARM targets whenever the used linker supports it. Otherwise we have to assume
> that it emits such PLTs by default.
No
mstorsjo wrote:
> > When cross compiling LLVM, I never have set `CMAKE_SYSTEM_PROCESSOR` so
> > far, since we don't really have anything that uses it (before this), which
> > means that this expands to an empty string. I guess I should set it still
> > though.
>
> Yes, I am just getting used
Author: Martin Storsjö
Date: 2024-01-23T13:42:24+02:00
New Revision: e3d73ad58c41b945d9fc5d5fb16ea44850ccf652
URL:
https://github.com/llvm/llvm-project/commit/e3d73ad58c41b945d9fc5d5fb16ea44850ccf652
DIFF:
https://github.com/llvm/llvm-project/commit/e3d73ad58c41b945d9fc5d5fb16ea44850ccf652.diff
@@ -1462,10 +1462,12 @@ WindowsARM64TargetInfo::WindowsARM64TargetInfo(const
llvm::Triple &Triple,
}
void WindowsARM64TargetInfo::setDataLayout() {
- resetDataLayout(Triple.isOSBinFormatMachO()
- ? "e-m:o-i64:64-i128:128-n32:64-S128"
-
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/77536
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
> `bool isEABIHF` from clang/lib/CodeGen/Targets/ARM.cpp can probably be
> factored.
Yep - any suggestion on where we could move it? Up to the `Triple` class?
https://github.com/llvm/llvm-project/pull/77536
___
cfe-commits mailing lis
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/77534
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/77536
If using multiarch directories with musl, the multiarch directory still uses
*-linux-gnu triples - which may or may not be intentional, while it is somewhat
consistent at least.
However, for musl armhf targets
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/77534
This applies the same change as in
760261a3daf98882ccbd177e3133fb4a058f47ad (where they were applied to libcxxabi
and libcxx) to libunwind as well.
These options can reasonably be set either as an absolute or r
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/76949
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
> > Although, on a second thought, it might actually still be good to adjust it
> > in sync. If we're invoking Clang with `-m32` and deciding on whether to use
> > i386/i586/i686, and we end up using the install base as sysroot, without
> > inferring any triple from there, we s
https://github.com/mstorsjo updated
https://github.com/llvm/llvm-project/pull/76949
From ce2a49c1a052b30fb1df91f3a7293e89e0a8726d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Tue, 19 Dec 2023 15:53:21 +0200
Subject: [PATCH] [clang] [MinGW] Don't look for a GCC in path
mstorsjo wrote:
> > Looks mostly good to me, but I wonder if we should change testTriple as
> > well.
>
> I thought so too based on the comment, but reviewing the code it seems
> `testTriple` is trying to find evidence that a given triple (and more
> specifically arch for things like `i386` v
https://github.com/mstorsjo updated
https://github.com/llvm/llvm-project/pull/76949
From c67187043168b79e57c0e4f3261293d799852e90 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Tue, 19 Dec 2023 15:53:21 +0200
Subject: [PATCH] [clang] [MinGW] Don't look for a GCC in path
mstorsjo wrote:
CC @mati865 @jeremyd2019 @huangqinjin
https://github.com/llvm/llvm-project/pull/76949
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/76949
This fixes uses of the MSYS2 clang64 environment compilers, if another set of
GCC based compilers are available further back in PATH (which may be explicitly
added, or inherited unintentionally from other softw
Author: Martin Storsjö
Date: 2024-01-04T15:01:17+02:00
New Revision: 71b3ead870107e39e998f6480e545eb01d9d28be
URL:
https://github.com/llvm/llvm-project/commit/71b3ead870107e39e998f6480e545eb01d9d28be
DIFF:
https://github.com/llvm/llvm-project/commit/71b3ead870107e39e998f6480e545eb01d9d28be.diff
mstorsjo wrote:
> > BTW, when compiling the file I also get a bunch of warnings in this style:
>
> @mstorsjo maybe `unsigned long` is 32 bits on that platform... what's the
> target triple?
Ah, indeed - yes, Windows has 32 bit `long`s. The triples are
`aarch64-windows-gnu` or `aarch64-windows
mstorsjo wrote:
This commit broken building compiler-rt builtins for Windows on aarch64;
building now hits these errors:
```
llvm-project/compiler-rt/lib/builtins/cpu_model.c:1192:2: error: No support for
checking for lse atomics on this platfrom yet.
1192 | #error No support for checking for
mstorsjo wrote:
> > @carlo-bramini has spent some effort on using Clang in Cygwin environments
> > before, so as far as I know, it does work in general from before. So this
> > change, which adds an entirely new driver for Cygwin environments, would
> > need to be explained why it does that (I
mstorsjo wrote:
> > Also
>
> In Cygwin with binutils 2.41, --dynamicbase make a difference, so I thought
> MinGW also need it.
No, MinGW does not need it, as it has been enabled by default since binutils
2.36.
Apparently that change,
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdi
mstorsjo wrote:
> I have build scripts and patches at: https://github.com/xu-chiheng/Note
This does not answer the question. You need to explain what is broken, and why,
and how this fixes it. And address the concern that this actually breaks
functionality in some cases. I guess this partially
https://github.com/mstorsjo requested changes to this pull request.
No, you do not need to do this. There's no need to add `--dynamicbase` manually
in Clang. As I already posted, both ld.bfd and ld.lld default to
`--dynamicbase` enabled since 2020.
https://github.com/llvm/llvm-project/pull/749
mstorsjo wrote:
I don't know what issue/regression you're referring to. Please explain, in
detail, what the issue is and all the relevant aspects of your configuration.
Also explain what the suggested fix does, and how it handles the various cases
(I just tested building latest llvm-project ma
mstorsjo wrote:
@carlo-bramini has spent some effort on using Clang in Cygwin environments
before, so as far as I know, it does work in general from before. So this
change, which adds an entirely new driver for Cygwin environments, would need
to be explained why it does that (I don't disagree,
mstorsjo wrote:
This breaks bootstrapping llvm-mingw.
Not all mingw environments use or require pthreads; llvm-mingw is one such
environment, and the clang64 environment in msys2 is another one.
While llvm-mingw does contain winpthreads, it is built later in the build
process, and if this pat
https://github.com/mstorsjo requested changes to this pull request.
This is not necessary.
Since 514b4e191d5f46de8e142fe216e677a35fa9c4bb in binutils
(https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=514b4e191d5f46de8e142fe216e677a35fa9c4bb),
dynamicbase is enabled by default. Als
mstorsjo wrote:
> Right, I'd just like to make sure that we're not deepening a divergence here.
> It would be good to get agreement from the GCC devs that they think
> `ms_struct` probably ought to do something on e.g. ARM MinGW targets and that
> they consider this a bug (in a feature that th
mstorsjo wrote:
Could we please land this now?
https://github.com/llvm/llvm-project/pull/74580
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
> Okay, @mstorsjo @MaskRay, what is the way forward?
I'm totally not authoritative for these things, but...
> Am I right that, as for the user-facing changes, `[[gcc_struct]]` cancelling
> implicit `-mms-bitfilds` on MinGW is fine
Sounds quite fine for me
> and silently ignor
mstorsjo wrote:
> One more thing. Re binary compatibility concerns: `-mno-ms-bitfields` on
> MinGW is an equally-sized footgun as on MSVC. Without proper header
> annotation with `#pragma ms_struct on`, either of them will silently make an
> ABI mismatch. However, for some reason, supporting `
mstorsjo wrote:
> Microsoft bit-field layout didn't break an overly-specific regression test
> but rendered unusable double to string conversion. The culprit was the
> following snippet:
>
> ```c++
> union Extractor {
> double value;
> struct {
> bool sign : 1;
> u32 exponent : 11;
mstorsjo wrote:
> `-mms-bitfields` is a GCC x86 specific option (`aarch64-linux-gnu-gcc
> -mms-bitfields -xc /dev/null -E` => `error: unrecognized command-line option
> ‘-mms-bitfields’`).
While it is implemented as an x86 specific option in GCC right now, that
doesn't mean that it only is su
https://github.com/mstorsjo approved this pull request.
LGTM, thanks! (I have no idea how I botched that previous fix commit...)
https://github.com/llvm/llvm-project/pull/72314
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.
mstorsjo wrote:
> Hi Phoebe, starting seeing this error on rather old codes after this patch
> landed . is there a particular flag you recommend i should compile with to
> get previous behavior ?
>
> error: always_inline function '_mm_setzero_pd' requires target feature
> 'evex512', but would
mstorsjo wrote:
This is superseded by #71393 which was merged now.
https://github.com/llvm/llvm-project/pull/66881
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/71393
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/71168
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mstorsjo edited
https://github.com/llvm/llvm-project/pull/71168
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mstorsjo edited
https://github.com/llvm/llvm-project/pull/71168
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
Thanks, I wasn't aware of this issue (I don't routinely try building with
`-DBUILD_SHARED_LIBS=ON`, which I presume is what you've done to trigger this).
See 592e935e115ffb451eb9b782376711dab6558fe0 for earlier context on this issue;
therefore I'd prefer to fix this as I do in
mstorsjo wrote:
CC @brechtsanders, this is an alternative to #66881.
https://github.com/llvm/llvm-project/pull/71393
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/71393
A few symbols within libclangInterpreter have got explicit dllexport
attributes, in order to make them exported (and thus visible at runtime) in any
build, not only when they are part of e.g. a DLL libclang-cpp
mstorsjo wrote:
Posting for a second review instead of just relanding the patch as is; in order
to check the host triple, I had to add the `host=triple` string; it was
previously only available for tests under `llvm/test`, but let's move it to the
common llvm test configuration just like the `
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/71168
The const.cpp testcase fails when running in MSVC mode, while it does succeed
in MinGW mode.
In MSVC mode, there are more constructor invocations than expected, as the
printout looks like this:
A(1), this
Author: Martin Storsjö
Date: 2023-11-03T11:55:33+02:00
New Revision: 89a336add722f57f61c99b3eafab1c89f943db5e
URL:
https://github.com/llvm/llvm-project/commit/89a336add722f57f61c99b3eafab1c89f943db5e
DIFF:
https://github.com/llvm/llvm-project/commit/89a336add722f57f61c99b3eafab1c89f943db5e.diff
Author: Martin Storsjö
Date: 2023-11-03T11:30:08+02:00
New Revision: e9db60c05e2fb96ff40cbb1f78790abc5de9237e
URL:
https://github.com/llvm/llvm-project/commit/e9db60c05e2fb96ff40cbb1f78790abc5de9237e
DIFF:
https://github.com/llvm/llvm-project/commit/e9db60c05e2fb96ff40cbb1f78790abc5de9237e.diff
mstorsjo wrote:
> > > > If you still need help reproducing or debugging the issue on our bot,
> > > > please let me know.
> > >
> > >
> > > Thanks, much appreciated. Can you test if
> > > [mstorsjo@clang-repl-xfail](https://github.com/mstorsjo/llvm-project/commit/clang-repl-xfail)
> > > seem
mstorsjo wrote:
> If you still need help reproducing or debugging the issue on our bot, please
> let me know.
Thanks, much appreciated. Can you test if
https://github.com/mstorsjo/llvm-project/commit/clang-repl-xfail seems to run
correctly in this environment? Otherwise I'll try to push it to
mstorsjo wrote:
> FTR, the "Worker" tab on that buildbot page will point you to the maintainer.
Ah, there it is, I tried looking around, but overlooked that one...
> But tagging me is also fine in general.
Ok, thanks!
> I'm unable to repro the problem locally because my local build doesn't se
Author: Martin Storsjö
Date: 2023-11-02T10:49:55+02:00
New Revision: b73d7390732b48014983aa9569e68c139f61bfcb
URL:
https://github.com/llvm/llvm-project/commit/b73d7390732b48014983aa9569e68c139f61bfcb
DIFF:
https://github.com/llvm/llvm-project/commit/b73d7390732b48014983aa9569e68c139f61bfcb.diff
mstorsjo wrote:
This broke on PS5 bots, like
https://lab.llvm.org/buildbot/#/builders/216/builds/29677; those are configured
with a triple like `x86_64-sie-ps5`, which seems to use an MSVC like C++ ABI
behaviour, so I pushed a revert.
Not sure whom to CC to pull in Sony people to discuss this
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/70991
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
> Very interesting... See also #68092, now I understand even less what the
> problem is...
No idea actually, but I tested passing `-Xcc --target=x86_64-w64-mingw32` to an
MSVC-built clang-repl, and then it outputs the expected things.
Not sure at what level some JIT deduplicat
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/70991
The const.cpp testcase fails when running in MSVC mode, while it does succeed
in MinGW mode.
In MSVC mode, there are more constructor invocations than expected, as the
printout looks like this:
A(1), this
@@ -53,3 +53,26 @@ add_flang_library(FortranDecimal INSTALL_WITH_TOOLCHAIN
binary-to-decimal.cpp
decimal-to-binary.cpp
)
+
+if (DEFINED MSVC)
+ set(CMAKE_MSVC_RUNTIME_LIBRARY MultiThreaded)
mstorsjo wrote:
Instead of redefining `CMAKE_MSVC_RUNTIME_LIBRARY
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/69079
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mstorsjo updated
https://github.com/llvm/llvm-project/pull/69079
From df2dba040dadb5e3222b44b41ea92978d9ddafed Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Sat, 14 Oct 2023 00:55:18 +0300
Subject: [PATCH 1/4] [clang] [Gnu] Improve GCCVersion parsing
https://github.com/mstorsjo updated
https://github.com/llvm/llvm-project/pull/69079
From df2dba040dadb5e3222b44b41ea92978d9ddafed Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Sat, 14 Oct 2023 00:55:18 +0300
Subject: [PATCH 1/3] [clang] [Gnu] Improve GCCVersion parsing
@@ -2007,45 +2007,71 @@ Generic_GCC::GCCVersion
Generic_GCC::GCCVersion::Parse(StringRef VersionText) {
std::pair First = VersionText.split('.');
std::pair Second = First.second.split('.');
- GCCVersion GoodVersion = {VersionText.str(), -1, -1, -1, "", "", ""};
- if (Fi
https://github.com/mstorsjo updated
https://github.com/llvm/llvm-project/pull/69079
From df2dba040dadb5e3222b44b41ea92978d9ddafed Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Sat, 14 Oct 2023 00:55:18 +0300
Subject: [PATCH 1/2] [clang] [Gnu] Improve GCCVersion parsing
@@ -2007,45 +2007,71 @@ Generic_GCC::GCCVersion
Generic_GCC::GCCVersion::Parse(StringRef VersionText) {
std::pair First = VersionText.split('.');
std::pair Second = First.second.split('.');
- GCCVersion GoodVersion = {VersionText.str(), -1, -1, -1, "", "", ""};
- if (Fi
@@ -2007,45 +2007,71 @@ Generic_GCC::GCCVersion
Generic_GCC::GCCVersion::Parse(StringRef VersionText) {
std::pair First = VersionText.split('.');
std::pair Second = First.second.split('.');
- GCCVersion GoodVersion = {VersionText.str(), -1, -1, -1, "", "", ""};
- if (Fi
mstorsjo wrote:
Ping
https://github.com/llvm/llvm-project/pull/69079
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
> ```c
> #if !defined(LLVM_BUILD_SHARED_LIBS)
> ```
>
> is not great but is not too bad. `-DBUILD_SHARED_LIBS=on` modes are slow to
> execute tests and are not used often for Release builds.
I went ahead and relanded this now, in
538b7ba2aacd6e400ee63c4f9ff1c2543ae69a90, with
Author: Martin Storsjö
Date: 2023-10-20T23:34:28+03:00
New Revision: 538b7ba2aacd6e400ee63c4f9ff1c2543ae69a90
URL:
https://github.com/llvm/llvm-project/commit/538b7ba2aacd6e400ee63c4f9ff1c2543ae69a90
DIFF:
https://github.com/llvm/llvm-project/commit/538b7ba2aacd6e400ee63c4f9ff1c2543ae69a90.diff
mstorsjo wrote:
> I hope that we do not drop `LLVM_LIBRARY_VISIBILITY` arbitrarily from
> `clang::driver::toolchains::*` classes, just because some unittests need to
> reference the symbols in a shared object.
That’s a reasonable point.
> ```c
> #if !defined(LLVM_BUILD_SHARED_LIBS)
> ```
>
>
mstorsjo wrote:
> Perhaps this belongs in the ABI-breaking-checks build?
Hmm, ideally I think it should be included in any build - let’s hope we don’t
need to resort to that.
@tstellar @MaskRay Do either of you happen to know about this; would it be ok
ABI wise to remove `LLVM_LIBRARY_VISIBIL
Author: Martin Storsjö
Date: 2023-10-18T15:42:18+03:00
New Revision: 1072b94ed8e5a051100557185cb384364850635a
URL:
https://github.com/llvm/llvm-project/commit/1072b94ed8e5a051100557185cb384364850635a
DIFF:
https://github.com/llvm/llvm-project/commit/1072b94ed8e5a051100557185cb384364850635a.diff
mstorsjo wrote:
> @tbaederr Just came to report the same thing!
>
> @mstorsjo This broke builds that use `-DBUILD_SHARED_LIBS=True`.
Thanks! That was my guess as well, I was running a build with that enabled to
try to reproduce @tbaederr 's issue.
> The problem seems to be that the `Generic_G
mstorsjo wrote:
The prerequisite to this PR has been merged now.
https://github.com/llvm/llvm-project/pull/69079
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mstorsjo updated
https://github.com/llvm/llvm-project/pull/69079
From 468befbb3eeaa0a23b001141976108157608e11d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Sat, 14 Oct 2023 00:55:18 +0300
Subject: [PATCH] [clang] [Gnu] Improve GCCVersion parsing to m
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/69078
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
Thanks, I applied the suggested changes - will push in a little while.
https://github.com/llvm/llvm-project/pull/69078
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mstorsjo updated
https://github.com/llvm/llvm-project/pull/69078
From 1aac071988f66ccab67c7a6179841bb272b5684a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Sat, 14 Oct 2023 00:06:05 +0300
Subject: [PATCH] [clang] [unittest] Add a test for
Generic_GC
https://github.com/mstorsjo updated
https://github.com/llvm/llvm-project/pull/69079
From 2b127200dc7b7b7c60e3001c7acf49a33a22e2a5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Sat, 14 Oct 2023 00:06:05 +0300
Subject: [PATCH 1/2] [clang] [unittest] Add a test for
Generi
mstorsjo wrote:
This goes on top of #69078 - the first commit is reviewed there, thus within
this PR, only review the second commit on its own.
https://github.com/llvm/llvm-project/pull/69079
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
htt
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/69079
In earlier GCC versions, the Debian/Ubuntu provided mingw toolchains were
packaged in /usr/lib/gcc/ with version strings such as "5.3-win32",
which were matched and found since 6afcd64eb65fca233a7b173f88cffb2c2
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/69078
This adds actual test cases for all the cases that are listed in a code comment
in the implementation of this function; having such test coverage eases doing
further modifications to the function.
From 2b1272
@@ -642,18 +642,8 @@ get_sanitizer_flags(SANITIZER_FLAGS
"${LLVM_USE_SANITIZER}")
# Link system libraries ===
function(cxx_link_system_libraries target)
-
-# In order to remove just libc++ from the link step
-# we need to us
@@ -642,18 +642,8 @@ get_sanitizer_flags(SANITIZER_FLAGS
"${LLVM_USE_SANITIZER}")
# Link system libraries ===
function(cxx_link_system_libraries target)
-
-# In order to remove just libc++ from the link step
-# we need to us
@@ -642,18 +642,8 @@ get_sanitizer_flags(SANITIZER_FLAGS
"${LLVM_USE_SANITIZER}")
# Link system libraries ===
function(cxx_link_system_libraries target)
-
-# In order to remove just libc++ from the link step
-# we need to us
@@ -642,18 +642,8 @@ get_sanitizer_flags(SANITIZER_FLAGS
"${LLVM_USE_SANITIZER}")
# Link system libraries ===
function(cxx_link_system_libraries target)
-
-# In order to remove just libc++ from the link step
-# we need to us
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/68571
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
> Whatever we decide to do on the LLVM side, this seems fine for the clang side.
Yes, this bit should be fine in any case.
> It looks like clang uses the value of UseInitArray for some ObjC stuff, in
> addition to passing it to the backend, so we need the right value in clang i
mstorsjo wrote:
> Right, so adding an `enum DefaultableBool { Default, False, True }` and
> changing the field to that value?
With such a definition, I wonder how to interpret it for MSVC targets;
`UseInitArray` would be false, as MSVC uses the `.CRT` sections, neither
`.ctors` not `.init_ar
mstorsjo wrote:
> Doesn't UseInitArray default to false in LLVM?
The class `TargetOptions` itself initializes it to false indeed. But
`codegen::InitTargetOptionsFromCodeGenFlags` (which seems to be what e.g. `llc`
uses) explicitly sets it to `!getUseCtors()`, which only checks the state of
th
mstorsjo wrote:
> Hmm...
>
> Maybe the backend should have some notion of a default ctors section. So if
> the frontend doesn't explicitly specify anything, the backend tries to pick
> the right default.
Yep, this is kinda the same issue for lots of target specific options that are
set as bo
mstorsjo wrote:
> We could go with a clang fix, but also make the backend report_fatal_error if
> you try to use llvm.ctors with UseInitArray on mingw. That keeps everything
> consistent while also making sure non-clang frontends don't miscompile.
Hmm, interesting proposition... But wouldn't t
mstorsjo wrote:
This is an alternative to #68570. This has the upside that the `UseInitArray`
flag is set to the correct value throughout the chain, for any other potential
users of the field, in case it would affect code generation in other places.
The downside is that if we only go with this
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/68571
On MinGW targets, the .ctors section is always used for constructors.
Make sure that all layers of code generation is aware of this, wherever it
matters, by passing the -fno-use-init-array option, setting the T
mstorsjo wrote:
> > ... I understand this is only a bug on MacOS?
>
> I'm using clang only to compile my binary packages on macOS (the Linux
> binaries are compiled with gcc), so I got bitten by this bug only on macOS.
> The other platforms/targets may or may not be affected, I don't know; but
mstorsjo wrote:
> > it's quite possible that someone has ended up depending on the previous de
> > facto behaviour.
>
> Then we have to be super creative and find a better solution.
>
> How about changing the logic, and where `Driver.InstalledDir` is used, if the
> desired file/folder is not
mstorsjo wrote:
> Without any other reference, I checked the Apple clang, on my macOS:
>
> ```
> ilg@wksi ~ % /usr/bin/clang -v
> Apple clang version 14.0.0 (clang-1400.0.29.202)
> Target: x86_64-apple-darwin21.6.0
> Thread model: posix
> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
mstorsjo wrote:
> I'm convinced that such links were occasionally used before, just that the
> result was not necessarily an error, I would say that in most cases using the
> system libraries is functional, and this explains why such cases were not
> reported till now.
Not necessarily; this d
mstorsjo wrote:
> > it makes me wonder if someone actually is relying on the current behaviour
>
> To rephrase your question, you ask if someone is using a configuration with a
> folder where various custom libraries are and bin folder with a link to the
> actual clang, and expects for clang t
mstorsjo wrote:
> > I haven't checked closely
>
> Hi Martin, please check the #66704 bug report, the current behaviour is
> plainly wrong,
I would kind of agree with that in general - resolving this to the actual clang
binary would indeed seem like the right thing to do. But it makes me wonde
101 - 200 of 410 matches
Mail list logo
