Author: Martin Storsjö
Date: 2021-10-13T22:55:00+03:00
New Revision: b541845ea082d1dfca53074b4353e1ee0c22dd76
URL:
https://github.com/llvm/llvm-project/commit/b541845ea082d1dfca53074b4353e1ee0c22dd76
DIFF:
https://github.com/llvm/llvm-project/commit/b541845ea082d1dfca53074b4353e1ee0c22dd76.diff
Author: Jeremy Drake
Date: 2021-10-13T22:55:14+03:00
New Revision: d9b9a7f4287019ad7fb5ae35523e81dee36c1b40
URL:
https://github.com/llvm/llvm-project/commit/d9b9a7f4287019ad7fb5ae35523e81dee36c1b40
DIFF:
https://github.com/llvm/llvm-project/commit/d9b9a7f4287019ad7fb5ae35523e81dee36c1b40.diff
mstorsjo wrote:
> @mstorsjo I think you put the finger on something I don't really understand
> at the moment. What is the relationship between `armv7` and `thumbv7` as a
> target triple? Is there any documentation on what an "effective triple" is in
> comparison to a "non-effective triple"?
mstorsjo wrote:
In addition to the issue noted on buildbots, this also caused failed tests on
i386:
https://github.com/mstorsjo/llvm-mingw/actions/runs/9606458336/job/26504129718#step:8:1501
There seem to be a couple of different errors there:
```
bit-int.c:72:19: runtime error: implicit conver
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/96062
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
> Do you already know in which Clang versions this will be fixed? Also thx for
> fixing this 👍
The fix will be in the upcoming 19.x which is going to release candidates in
August and might be released in September/October. (Although, downstreams may
pick it up and backport the
mstorsjo wrote:
> @mstorsjo It seems your compiler build does not have int128_t enabled.
Indeed, Clang doesn't provide int128_t for 32 bit targets, AFAIK.
> Could you please test #96240 in your environment to verify it has no such
> problem?
That PR does seem to work fine, in such an environm
mstorsjo wrote:
> > Indeed, Clang doesn't provide int128_t for 32 bit targets, AFAIK.
>
> It looks like a little bit more complex. I checked with Standalone-i386 and
> AddressSanitizer-i386 targets. They do have int128_t for 32 bit targets as
> soon as clang itself built as 64-bit binary.
Tha
mstorsjo wrote:
> So I've been trying to follow down the rabbit hole of the failing flag
> checks, and it seems the combination of `CXX_SUPPORTS_UNWINDLIB_EQ_NONE_FLAG`
> plus https://gitlab.kitware.com/cmake/cmake/-/issues/23454 has a wider blast
> radius than anticipated.
>
> I'm not claimi
mstorsjo wrote:
This PR seems to have broken ASAN in mingw configurations. The symptoms seem to
be that the ASAN DLL just locks up, hard, when the process is loaded. (Or more
precisely, has entered some infinite loop.)
I tried attaching to such a hung process with windbg, and it's showing this
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/108357
While these flags semantically are relevant only for C++, we do add them to
CMAKE_REQUIRED_FLAGS if they are detected. All flags in that variable are used
both when testing compilation of C and C++ (and for de
@@ -38,9 +38,13 @@ check_cxx_compiler_flag(-nolibc CXX_SUPPORTS_NOLIBC_FLAG)
# required during compilation (which has the -nostdlib++ or -nodefaultlibs).
libc is
# required for the link to go through. We remove sanitizers from the
# configuration checks to avoid spurious link
mstorsjo wrote:
Thanks! How do you feel about potentially backporting this to 19.x after a
while? It’s not an urgent fix for a regression or something like that, but it’s
kinda trivial enough. (In any case, it’d be after the first 19.1.0 is cut.)
https://github.com/llvm/llvm-project/pull/10818
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/108189
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Martin Storsjö
Date: 2024-09-12T23:12:54+03:00
New Revision: aa3465793a250faa5426ac626989375465256658
URL:
https://github.com/llvm/llvm-project/commit/aa3465793a250faa5426ac626989375465256658
DIFF:
https://github.com/llvm/llvm-project/commit/aa3465793a250faa5426ac626989375465256658.diff
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/108539
This allows the clang driver to know which tool is meant to be executed, which
allows the clang driver to load the right clang config files, and allows clang
to find colocated sysroots.
This makes sure that d
Author: Martin Storsjö
Date: 2024-09-13T15:55:03+03:00
New Revision: 90a2e0bb423629b7e70f4b91adb44851199dd5ea
URL:
https://github.com/llvm/llvm-project/commit/90a2e0bb423629b7e70f4b91adb44851199dd5ea
DIFF:
https://github.com/llvm/llvm-project/commit/90a2e0bb423629b7e70f4b91adb44851199dd5ea.diff
mstorsjo wrote:
> Can you explain why exactly is this necessary/beneficial? If the compilation
> database got created with just the tool name, I'd expect the rest of the
> build to be able to use just the tool name when the scanner spits it out
> again, no? If this is about the scanner finding
mstorsjo wrote:
And practically - in the cases I've seen where CMake generates calls to
`clang-scan-deps`, it always invokes `clang-scan-deps ... --
/absolute/path/to/compiler` (CMake in general is very keen on absolute paths to
tools).
But in separate testing of these tools, I ran into this
mstorsjo wrote:
> Ok, thanks for the explanation. This LGTM, but the checks are failing on
> Windows due to `.exe` extension that's not accounted for. I don't think any
> of the tests you touched really care about the executable path, so I'd be
> fine with just removing those check lines.
Ah,
https://github.com/mstorsjo updated
https://github.com/llvm/llvm-project/pull/108539
From 4119204e2da13d00bd6ac5d23e05a4f269b2b75c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Fri, 13 Sep 2024 13:57:49 +0300
Subject: [PATCH 1/2] [clang-scan-deps] Infer the tool locatio
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/108539
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Martin Storsjö
Date: 2024-09-15T00:02:39+03:00
New Revision: 7d11f5249c8068851270e94ac02c180e7b83590d
URL:
https://github.com/llvm/llvm-project/commit/7d11f5249c8068851270e94ac02c180e7b83590d
DIFF:
https://github.com/llvm/llvm-project/commit/7d11f5249c8068851270e94ac02c180e7b83590d.diff
mstorsjo wrote:
I've bisected breakage, on mingw x86 platforms relating to double vs long
double routines, down to this commit.
I'll follow up with more details when I manage to pinpoint what changes and
where, due to this change.
https://github.com/llvm/llvm-project/pull/108575
_
mstorsjo wrote:
I managed to reduce the breakage to the following snippet:
```c
long double powl(long double a, long double b);
long double a() { return powl(2.0L, 2.0L); }
```
Compiled like this:
```
$ clang -target x86_64-w64-mingw32 -S -O2 -o out.s repro.c
```
The output between before and aft
Author: Martin Storsjö
Date: 2024-09-16T13:51:16+03:00
New Revision: f71061258484390cb74752e9d7e486264aa4db0a
URL:
https://github.com/llvm/llvm-project/commit/f71061258484390cb74752e9d7e486264aa4db0a
DIFF:
https://github.com/llvm/llvm-project/commit/f71061258484390cb74752e9d7e486264aa4db0a.diff
mstorsjo wrote:
Thanks for the fix! Unfortunately I'm way out of my depth when it comes to
actually reviewing this change, so hopefully you can find someone else to
check/review it - but I appreciate you finding the root cause so quickly!
https://github.com/llvm/llvm-project/pull/108853
__
mstorsjo wrote:
I think it's backport worthy. It's very small and has a near zero regression
risk, and is a quite obvious fix. It might be a bit late for 19.1.2 which
should be cut tomorrow, but should probably make it for 19.1.3.
Just add this PR to the right 19.x milestone and type a `/cherr
@@ -1505,6 +1505,10 @@ class TargetInfo : public TransferrableTargetInfo,
bool supportsIFunc() const {
if (getTriple().isOSBinFormatMachO())
return true;
+if (getTriple().isOSWindows() && getTriple().isAArch64())
+ return true;
+if (getTriple().getArch(
https://github.com/mstorsjo approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/112066
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
Can we land a fix, or can we get a revert pushed?
https://github.com/llvm/llvm-project/pull/73
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
Ah, I never got around to pushing the reverts earlier. Do you think you'll have
a fix within a couple of hours, or should we just go ahead with the revert and
do a clean reland later, once this issue is sorted out (and you've checked that
Qt actually does compile still - there
mstorsjo wrote:
This no longer reverts cleanly - 4336f00f2156970cc0af2816331387a0a4039317
(#110387) interferes; can someone more involved in this take it upon themselves
to sort this out (revert back to green again)? I can of course revert both too.
https://github.com/llvm/llvm-project/pull/11
mstorsjo wrote:
This still breaks building Qt, in the same source file as before, but with a
different error.
Standalone reproducible with https://martin.st/temp/qwindowsystem-preproc.cpp:
```
$ clang -target i686-w64-mingw32 -c qwindowsystem-preproc.cpp -w
qwindowsystem-preproc.cpp:150631:73:
@@ -5800,8 +5800,10 @@ Not all targets support this attribute. ELF target
support depends on both the
linker and runtime linker, and is available in at least lld 4.0 and later,
binutils 2.20.1 and later, glibc v2.11.1 and later, and FreeBSD 9.1 and later.
Mach-O targets suppor
@@ -38,9 +38,13 @@ check_cxx_compiler_flag(-nolibc CXX_SUPPORTS_NOLIBC_FLAG)
# required during compilation (which has the -nostdlib++ or -nodefaultlibs).
libc is
# required for the link to go through. We remove sanitizers from the
# configuration checks to avoid spurious link
mstorsjo wrote:
> I also bisected errors on Windows, down to this commit.
>
> The errors show up when running the compiler-rt testsuite, like this:
> https://github.com/mstorsjo/llvm-mingw/actions/runs/1135672/job/31598676534
> A number of tests fail, where `llvm-cov` errors out with `prof
mstorsjo wrote:
I also bisected errors on Windows, down to this commit.
The errors show up when running the compiler-rt testsuite, like this:
https://github.com/mstorsjo/llvm-mingw/actions/runs/1135672/job/31598676534
A number of tests fail, where `llvm-cov` errors out with `profile uses zl
mstorsjo wrote:
This breaks a number of tests on Windows.
Previously, to have tests working on Windows, one would do `git config --global
core.autocrlf false` or similar, before checking out llvm-project - a number of
test input files _need_ to be in LF form to work. This was brought up earlie
mstorsjo wrote:
> > a number of test input files need to be in LF form to work
>
> Which ones?
A whole bunch of them. @AaronBallman's link to
https://buildkite.com/llvm-project/github-pull-requests/builds/65#0192a01b-d3ac-44ad-abff-e53ac4a206ab
shows mostly what I saw. If including `clang
mstorsjo wrote:
> This seems to have broken precommit CI on Windows:
> https://buildkite.com/llvm-project/github-pull-requests/builds/65#0192a01b-d3ac-44ad-abff-e53ac4a206ab
> all of the failures look related to line endings, and I noticed that I got a
> ton of command line messages of the
mstorsjo wrote:
> Hi. this change caused chromium windows pgo build to fail:
> https://issues.chromium.org/issues/373478548 and we see the profile runtime
> error message:
>
> ```
> LLVM Profile Error: Invalid profile data to merge
> LLVM Profile Error: Profile Merging of file
> default_16487
@@ -38,9 +38,13 @@ check_cxx_compiler_flag(-nolibc CXX_SUPPORTS_NOLIBC_FLAG)
# required during compilation (which has the -nostdlib++ or -nodefaultlibs).
libc is
# required for the link to go through. We remove sanitizers from the
# configuration checks to avoid spurious link
mstorsjo wrote:
Thanks @sdkrystian for pushing the revert - now my nightly tests this night
were back to green :-)
https://github.com/llvm/llvm-project/pull/73
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/
mstorsjo wrote:
> @mstorsjo Tested this patch with QT and it builds without issue.
Nice, thanks!
https://github.com/llvm/llvm-project/pull/111852
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/c
mstorsjo wrote:
> The amount of churn is already pretty high -- please make sure the original
> commit, fixes, and reverts get added to
> https://github.com/llvm/llvm-project/blob/main/.git-blame-ignore-revs. At the
> end of the day, we have a number of tests and files which are sensitive to
mstorsjo wrote:
> > > It's my understanding that text=auto does not override core.autocrlf. As
> > > far as I can tell from the documentation it honours the user's
> > > configuration for core.eol in combination with core.autocrlf - from git
> > > config --help:
>
> > This doesn't match my ex
mstorsjo wrote:
> So if I've read that correctly, `core.autocrlf=false` is a red herring and
> you should really set `core.eol=lf` if you want git to use `lf` on windows.
That perhaps may be the case, but all common docs and all common practices
around this revolve around setting `core.autocrl
mstorsjo wrote:
> This patch is about respecting local config, which is the exact opposite of
> that suggestion. It would be a way to solve the line-ending issue by fiat,
> not by co-operation, so I'm against it on principle. To be clear I very much
> don't like CRLF, but I also very much don'
mstorsjo wrote:
> I think this is due to a subtly of config. Setting `core.autocrlf` to `false`
> doesn't actually do anything since it's the default.
In Git for Windows, the default actually is `core.autocrlf` set to `true`. When
manually installing, the installer wizard used to ask the user
mstorsjo wrote:
> > if all tests would have been cleaned up before this
>
> That was most certainly my intention, and I saw green before merging, so I
> must've looked in the wrong place
Ah, right - as we've seen that the CI runner normally only updates an existing
checkout, where changes to
mstorsjo wrote:
> I must have missed this PR originally. I oppose letting Git change any line
> endings. It always ends like this.
Also just for context - the Clang precommit CI is allegedly still broken,
because those buildbots happened to be restarted when we had these
gitattributes in plac
mstorsjo wrote:
Sure, if this is the one that is breaking things. Thanks for looking into it,
and sorry for the breakage!
https://github.com/llvm/llvm-project/pull/113653
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/c
mstorsjo wrote:
> Actually this PR is the case of
> https://lab.llvm.org/buildbot/#/builders/164/builds/3908, not #113491
Sorry about that.
Are you able to dig up any of the cmake configure logs from these builds, so
that we can figure out how this ends up breaking things? Because as in most
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/113653
___
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/108357
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
FWIW, I'd like to backport this to 19.x if possible. But I'll wait for a little
while to see whether this turns up any issues, before filing the backport
request.
https://github.com/llvm/llvm-project/pull/108357
___
cfe-commits mailin
@@ -0,0 +1,13 @@
+// This test checks if Window PE file compiled with -flto option contains a
magic
+// string "LTCG" to indicate LTO compilation.
+
+// REQUIRES: system-windows
+
+// RUN: %clang --target=x86_64-pc-windows-msvc -flto -fuse-ld=lld %s -o %t.exe
ms
mstorsjo wrote:
> > Actually this PR is the case of
> > https://lab.llvm.org/buildbot/#/builders/164/builds/3908, not #113491
>
> Sorry about that.
>
> Are you able to dig up any of the cmake configure logs from these builds, so
> that we can figure out how this ends up breaking things? Becau
@@ -0,0 +1,13 @@
+// This test checks if Window PE file compiled with -flto option contains a
magic
+// string "LTCG" to indicate LTO compilation.
+
+// REQUIRES: system-windows
+
+// RUN: %clang --target=x86_64-pc-windows-msvc -flto -fuse-ld=lld %s -o %t.exe
ms
mstorsjo wrote:
> > For the Mips backend itself, I would ask the Mips backend code
> > maintainer... but we don't have a maintainer for Mips. And we don't have
> > any buildbots. I'm really not sure about adding complexity to a backend
> > which is already suffering from a lack of anyone that
mstorsjo wrote:
This change broke building Qt.
A small standalone reproducer: https://martin.st/temp/qtgui-preproc2.cpp
To inspect:
```
$ clang -target armv7-w64-mingw32 -w -c qtgui-preproc2.cpp -o out.o -std=gnu++17
$ llvm-nm out.o | grep
_ZN19QWindowSystemHelperIN22QWindowSystemInterface20Asy
Author: Martin Storsjö
Date: 2024-09-21T23:24:49+03:00
New Revision: 1818ca5c4ae87ed222a18177caa7c8dde6c67efa
URL:
https://github.com/llvm/llvm-project/commit/1818ca5c4ae87ed222a18177caa7c8dde6c67efa
DIFF:
https://github.com/llvm/llvm-project/commit/1818ca5c4ae87ed222a18177caa7c8dde6c67efa.diff
mstorsjo wrote:
I managed to reduce this case further. Not entirely sure if it really managed
to pinpoint the same thing or if it diverged into something else, but this
snippet produces a different set of defined/undefined symbols before and after
this change.
```c++
namespace a {
typedef int
@@ -7209,6 +7209,9 @@ def fuse_ctor_homing: Flag<["-"], "fuse-ctor-homing">,
def as_secure_log_file : Separate<["-"], "as-secure-log-file">,
HelpText<"Emit .secure_log_unique directives to this filename.">,
MarshallingInfoString>;
+def output_asm_variant : Joined<["--"], "o
@@ -7209,6 +7209,9 @@ def fuse_ctor_homing: Flag<["-"], "fuse-ctor-homing">,
def as_secure_log_file : Separate<["-"], "as-secure-log-file">,
HelpText<"Emit .secure_log_unique directives to this filename.">,
MarshallingInfoString>;
+def output_asm_variant : Joined<["--"], "o
mstorsjo wrote:
> > > For the Mips backend itself, I would ask the Mips backend code
> > > maintainer... but we don't have a maintainer for Mips. And we don't have
> > > any buildbots. I'm really not sure about adding complexity to a backend
> > > which is already suffering from a lack of anyo
Author: Martin Storsjö
Date: 2024-10-01T11:14:11+03:00
New Revision: 0cf4cb4bde440586c310554d93dc09e47cb9bb79
URL:
https://github.com/llvm/llvm-project/commit/0cf4cb4bde440586c310554d93dc09e47cb9bb79
DIFF:
https://github.com/llvm/llvm-project/commit/0cf4cb4bde440586c310554d93dc09e47cb9bb79.diff
@@ -839,9 +839,11 @@ int clang_scan_deps_main(int argc, char **argv, const
llvm::ToolContext &) {
auto R = std::make_reverse_iterator(FlagsEnd);
for (auto I = R, E = Args.rend(); I != E; ++I) {
StringRef Arg = *I;
+if ((I + 1) == E)
https://github.com/mstorsjo updated
https://github.com/llvm/llvm-project/pull/109050
From 73dbd692945899708e2c127ba9972c20e5fcd30f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Wed, 18 Sep 2024 00:03:00 +0300
Subject: [PATCH] [clang-scan-deps] Don't inspect Args[0] as a
https://github.com/mstorsjo updated
https://github.com/llvm/llvm-project/pull/109050
From d7f46152baa1cffea16805bf7b522a237a54918f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Wed, 18 Sep 2024 00:03:00 +0300
Subject: [PATCH] [clang-scan-deps] Don't inspect Args[0] as a
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/109050
___
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.
Aside for the option ergonomics, this looks reasonable to me.
https://github.com/llvm/llvm-project/pull/109360
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bi
@@ -7209,6 +7209,9 @@ def fuse_ctor_homing: Flag<["-"], "fuse-ctor-homing">,
def as_secure_log_file : Separate<["-"], "as-secure-log-file">,
HelpText<"Emit .secure_log_unique directives to this filename.">,
MarshallingInfoString>;
+def output_asm_variant : Joined<["--"], "o
@@ -0,0 +1,26 @@
+// This test checks if COFF file compiled with
+// -fprofile-generate has magic section ".pgi" to indicate so.
+
+// RUN: %clang --target=x86_64-pc-windows -fprofile-generate %s -c -o %t_x86
mstorsjo wrote:
As this test now does compilation for
@@ -0,0 +1,16 @@
+// This test checks if lld puts magic string "PGI" when an object files
contains
+// .pgi section.
+
+// RUN: llvm-mc -filetype=obj -triple=x86_64-pc-windows %s -o %t.main_x86.obj
+// RUN: llvm-mc -filetype=obj -triple=aarch64-pc-windows %s -o
%t.main_aarch.obj
@@ -0,0 +1,26 @@
+// This test checks if COFF file compiled with
+// -fprofile-generate has magic section ".pgi" to indicate so.
+
+// RUN: %clang --target=x86_64-pc-windows -fprofile-generate %s -c -o %t_x86
mstorsjo wrote:
Yes - I'm not saying that this should
mstorsjo wrote:
FWIW, no further objections from me on this one, but others may want to have
another look (potentially also CC @MaskRay for the clang tests).
https://github.com/llvm/llvm-project/pull/114260
___
cfe-commits mailing list
cfe-commits@lis
mstorsjo wrote:
Thanks for the revert - FWIW, I also ran into issues with this change when
building Qt.
Building the https://github.com/qt/qtbase repo fails with an error like this:
```
[790/790] Linking CXX shared library lib/libQt6Gui.so.6.8.0
FAILED: lib/libQt6Gui.so.6.8.0
/usr/bin/ld: src/
mstorsjo wrote:
This change broke building Wine, which bundles the lcms2 library. The case
there, which broke, seems to be somewhat different than what the paper talks
about though. The paper talks about rejecting `int func(register void);`, but
the case in lcms2 is `int func(register void *pt
https://github.com/mstorsjo approved this pull request.
LGTM, thanks!
https://github.com/llvm/llvm-project/pull/116704
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
> > > Actually this PR is the case of
> > > https://lab.llvm.org/buildbot/#/builders/164/builds/3908, not #113491
> >
> >
> > Sorry about that.
> > Are you able to dig up any of the cmake configure logs from these builds,
> > so that we can figure out how this ends up breaking
@@ -1616,7 +1616,7 @@ bool Interpret(InterpState &S, APValue &Result) {
}
}
// https://github.com/llvm/llvm-project/issues/102513
-#if defined(_WIN32) && !defined(__clang__) && !defined(NDEBUG)
+#if defined(_MSC_VER) && !defined(__clang__) && !defined(NDEBUG)
#pragma optimiz
https://github.com/mstorsjo approved this pull request.
This looks reasonable.
Is this something that GCC doesn't have? IIRC they do have some support for
hotpatchability in some way - can you briefly summarize what they have and what
we have in common and what differs?
https://github.com/llv
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/109050
Since a26ec542371652e1d774696e90016fd5b0b1c191, we expand the executable name
to an absolute path, if it isn't already one, if found in path.
This broke a couple tests in some environments; when the clang work
@@ -6418,6 +6418,12 @@ def warn_signed_bitfield_enum_conversion : Warning<
InGroup, DefaultIgnore;
def note_change_bitfield_sign : Note<
"consider making the bitfield type %select{unsigned|signed}0">;
+def warn_ms_bitfield_mismatched_storage_packing : Warning<
+ "bit-field
mstorsjo wrote:
I'd invoke @AaronBallman for feedback/guidance here, before deciding the
direction on this one.
https://github.com/llvm/llvm-project/pull/121442
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mai
mstorsjo wrote:
> This change broke compiler-rt tests on mingw/i686 - have a look:
> https://github.com/mstorsjo/llvm-mingw/actions/runs/12487763901/job/34855514237
>
> I haven't had time to dig in to understand what's really happening here, but
> I have pinpointed the failures to this specifi
mstorsjo wrote:
I’m not in a position where I can test the patch properly right now, but if the
whole qtbase can be built (not only the reduced testcase or the specific source
file that triggered the issue before), I’m good with it - thanks!
https://github.com/llvm/llvm-project/pull/125266
___
mstorsjo wrote:
> The build is still broken (e.g.
> https://lab.llvm.org/buildbot/#/builders/63/builds/3861). I'll back it out.
Thanks, I was just about to report the same issue as well; this seems to
conflict with winnt.h, at least in older versions of WinSDK (10.0.18362.0 in my
case too). I
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/126139
This test does succeed in MinGW configurations.
From 30a0f8b46a55965a0ebbab066cf62b77f6ab9e5c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Thu, 6 Feb 2025 23:18:07 +0200
Subject: [PAT
mstorsjo wrote:
CC @DKLoehr
https://github.com/llvm/llvm-project/pull/126139
___
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/126139
___
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!
https://github.com/llvm/llvm-project/pull/119370
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
Ok, so with https://github.com/llvm/llvm-project/pull/120370 landed, I guess we
could consider trying to reland this.
By doing that, we would however break doing msan+libcxx builds unless using the
very latest Clang (while libcxx in general supports building with the last two
mstorsjo wrote:
Ok, now I tried this myself (and indeed, it wasn't very hard to set up - sorry
for not trying it earlier).
Here's the effect on the configure run, caused by this patch:
```diff
--- log-good-truncated 2024-12-18 13:59:16.334711800 +0200
+++ log-bad 2024-12-18 13:58:07.287917
mstorsjo wrote:
> #120370 was reverted, because libc++ tests expose major problem:
> Tests and likely many users can have `-nostdlib++ -lc++`.
> The if we remove c++ sanitizer runtimes from linking it will break them and
> force to add `-fsanitize-link-c++-runtime`
That's indeed a problem... Ho
mstorsjo wrote:
This was reverted, because
https://github.com/llvm/llvm-project/blob/main/libcxx/test/libcxx/language.support/support.dynamic/libcpp_deallocate.sh.cpp
in libc++ started passing unexpectedly.
I'm not entirely sure about why that is though - previously, it used to fail
like this
mstorsjo wrote:
> > > #120370 was reverted, because libc++ tests expose major problem:
> > > Tests and likely many users can have `-nostdlib++ -lc++`.
> > > The if we remove c++ sanitizer runtimes from linking it will break them
> > > and force to add `-fsanitize-link-c++-runtime`
> >
> >
> >
mstorsjo wrote:
> > In practice, when compiling C for Windows/ARMv7, NEON actually still is
> > available, but not when compiling assembly files.
>
> So the "bug" if we're going to call it that, is that C code can produce Neon
> but assembly files compiled in the same way cannot use Neon instr
401 - 500 of 673 matches
Mail list logo
