mstorsjo wrote:
> > The recent changes, #81037 and #87866, were (as far as I know) only
> > intended to change what is printed as error messages, when neither is
> > found, to help users correct their setup for the new style layout. But
> > those changes also seem to have unexpected effects
mstorsjo wrote:
> > I would suggest we revert this - and at least collect all the observed side
> > effects and declare them before considering relanding it.
>
> That sounds good to me. Do you have a list of PRs to revert?
Not sure if there are follow-up fixes, sorry, but the discussed PRs
mstorsjo wrote:
> Commit
> [b876596](https://github.com/llvm/llvm-project/commit/b876596a76cdc183439b36455d26883b67f8ee51)
> corrected default compiler-rt library names for many targets
Are you sure it's this change? There are reports of similar changes showing up
in
mstorsjo wrote:
> I now did build clang at
> [ccdebba](https://github.com/llvm/llvm-project/commit/ccdebbae4d77d3efc236af92c22941de5d437e01)
> and
> [ccdebba](https://github.com/llvm/llvm-project/commit/ccdebbae4d77d3efc236af92c22941de5d437e01)^.
>
>
mstorsjo wrote:
> This is a behavior change: In distributed build environments, neither lib
> file exists at compile time. Previously, this would result in the "old"
> style, now (together with #81037) it results in the "new" style (which we
> disable everywhere since it causes all kinds of
mstorsjo wrote:
> > Is it expected now that `clang --print-runtime-dir` will always have the
> > clang host triple appended even if `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` is
> > off? I guess I was expecting to see `lib/linux` instead of
> > `lib/x86_64-unknown-linux-gnu`.
>
>
mstorsjo wrote:
> @aeubanks The problem is that in your configure, the libclang_rt is placed in
> `/lib/clang/19/lib/linux/libclang_rt.builtins-arm-android.a`,
> instead of
> `/lib/clang/19/lib/arm-unknown-linux-android/libclang_rt.builtins.a`.
The point is that both locations were supposed
mstorsjo wrote:
> This seems to have had an unexpected effect. In a build where I don't use the
> new path style, I used to get the old path style returned like this:
>
> ```
> $ clang -target x86_64-w64-mingw32 -print-runtime-dir
> /home/martin/clang-nightly/lib/clang/19/lib/windows
> ```
>
mstorsjo wrote:
This seems to have had an unexpected effect. In a build where I don't use the
new path style, I used to get the old path style returned like this:
```
$ clang -target x86_64-w64-mingw32 -print-runtime-dir
/home/martin/clang-nightly/lib/clang/19/lib/windows
```
However after this
mstorsjo wrote:
> I'm sorry to hear that. Reading through
> https://libcxx.llvm.org/BuildingLibcxx.html now to see if I can make
> ENABLE_RUNTIMES behave itself under cross compilation. I'm familiar with this
> in the context of the "bootstrapping" build from the docs, the build clang
>
mstorsjo wrote:
This build configuration was explicitly made disallowed in
6f17768e11480063f4c2bcbeea559505fee3ea19, with an error message explaining the
situation. However that error message was later removed in
0a22dfcb11c05cbd4f654c8ef1868a4bc6085140.
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/84917
27ce26b06655cfece3d54b30e442ef93d3e78ac7 added the new option
`-fvisibility-global-new-delete=`, where
`-fvisibility-global-new-delete=force-hidden` is equivalent to the old option
@@ -2410,20 +2410,35 @@ usual build cycle when using sample profilers for
optimization:
1. Build the code with source line table information. You can use all the
usual build flags that you always build your application with. The only
- requirement is that you add
mstorsjo wrote:
FYI, see 4b8d9abca7d0280878fb12de331e688ee85d7cd8 for another existing case
where we already support both `rdm` and `rdma`. But I don't think that case can
share any of the aliasing logic from here.
https://github.com/llvm/llvm-project/pull/80540
https://github.com/mstorsjo approved this pull request.
If nobody else wants to chime in here, I guess I'll go ahead and approve it.
LGTM!
https://github.com/llvm/llvm-project/pull/80527
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/mstorsjo approved this pull request.
LGTM, thanks.
In principle, we're just trading surprises in one case into surprises in
another case, but I guess this case is the one with more non-obvious details
(and this can be argued is the future direction we should be heading
mstorsjo wrote:
> > Not to distract from the direction taken here (which I do agree seems
> > reasonable, even if I haven't had time to look closer at the PR yet) - but,
> > when using the static CRT in general, doesn't the same concern apply there
> > as well? I.e. when using the static CRT,
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/81849
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
> Done
Thanks, now this looks good to merge!
https://github.com/llvm/llvm-project/pull/81849
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
It looks like your github account is set to keep your email address private -
can you please turn that off, so we get a proper email address (when the commit
is rewritten, as we do merges with "squash and merge" here)? See the "keep my
email addresses private" setting at
mstorsjo wrote:
> The core reasoning is that asan is a "only one allowed per process" type
> thing (you can't have one copy of the asan runtime handling a malloc while a
> different one handles the corresponding free).
Not to distract from the direction taken here (which I do agree seems
mstorsjo wrote:
> This is superseded by https://github.com/llvm/llvm-project/pull/71393 which
> was merged now.
I'll close this one for now, as I believe the issue has been fixed differently.
https://github.com/llvm/llvm-project/pull/66881
___
https://github.com/mstorsjo closed
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
mstorsjo wrote:
From my point of view, I think this sounds fine - it looks like you've looked
through this and thought deeper about it than I have at least. I'm not deep
enough into this to comfortably press approved on this for now though, so
hopefully someone else can chime in as well.
mstorsjo wrote:
I would, generally, prefer to not hardcode `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR`
(which only affects how runtimes are installed) into Clang. Runtimes may or may
not be built at the same time as Clang, and one build of Clang can be used for
a multitude of targets with different
https://github.com/mstorsjo closed
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-commits
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://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
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
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.
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:
@@ -1462,10 +1462,12 @@ WindowsARM64TargetInfo::WindowsARM64TargetInfo(const
llvm::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
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
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
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
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`
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
Author: Martin Storsjö
Date: 2024-01-04T15:01:17+02:00
New Revision: 71b3ead870107e39e998f6480e545eb01d9d28be
URL:
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
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
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,
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
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.
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
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
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
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.
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
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
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 :
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
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
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
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
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),
Author: Martin Storsjö
Date: 2023-11-03T11:55:33+02:00
New Revision: 89a336add722f57f61c99b3eafab1c89f943db5e
URL:
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:
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)
> > >
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
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
Author: Martin Storsjö
Date: 2023-11-02T10:49:55+02:00
New Revision: b73d7390732b48014983aa9569e68c139f61bfcb
URL:
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
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
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),
@@ -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
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
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
@@ -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
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:
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
Author: Martin Storsjö
Date: 2023-10-18T15:42:18+03:00
New Revision: 1072b94ed8e5a051100557185cb384364850635a
URL:
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
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
1 - 100 of 336 matches
Mail list logo
