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 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:
> 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
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:
I pushed a revert for this myself now after running tests, to see that it
didn't tie in to any other recent change.
https://github.com/llvm/llvm-project/pull/112241
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.
Author: Martin Storsjö
Date: 2025-01-30T12:05:56+02:00
New Revision: 5c24847e7dba01dde230e18b39a3074022279c89
URL:
https://github.com/llvm/llvm-project/commit/5c24847e7dba01dde230e18b39a3074022279c89
DIFF:
https://github.com/llvm/llvm-project/commit/5c24847e7dba01dde230e18b39a3074022279c89.diff
mstorsjo wrote:
This change breaks compiling Qt. To reproduce on e.g. Linux, clone
https://github.com/qt/qtbase, check out the tag `v6.8.1`, configure and build
it like this:
```
$ cmake .. \
-G Ninja \
-DCMAKE_C_COMPILER=clang \
-DCMAKE_CXX_COMPILER=clang++ \
-D
@@ -0,0 +1,9 @@
+// RUN: %clang -### -c --target=aarch64 -fno-plt -Werror %s 2>&1 | FileCheck %s
+// RUN: %clang -### -c --target=x86_64 -fno-plt -Werror %s 2>&1 | FileCheck %s
+// RUN: %clang -### -c --target=aarch64 -fno-plt -fplt -Werror %s 2>&1 |
FileCheck %s --check-prefix=N
https://github.com/mstorsjo edited
https://github.com/llvm/llvm-project/pull/124081
___
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! This seems to nicely fix the issue and make the situation clearer.
CC @Martchus.
https://github.com/llvm/llvm-project/pull/124081
___
cfe-commits mailing list
cfe-commits@lists.llvm
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/122095
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -659,13 +659,21 @@ llvm::ARM::FPUKind arm::getARMTargetFeatures(const Driver
&D,
CPUArgFPUKind != llvm::ARM::FK_INVALID ? CPUArgFPUKind :
ArchArgFPUKind;
(void)llvm::ARM::getFPUFeatures(FPUKind, Features);
} else {
+bool Generic = true;
if (!ForAS) {
mstorsjo wrote:
Ping - anyone want to give a proper review of this one? Both for the concept,
but I'm also open to suggestions for making the actual implementation slightly
less ugly.
https://github.com/llvm/llvm-project/pull/122095
___
cfe-commits m
@@ -659,13 +659,21 @@ llvm::ARM::FPUKind arm::getARMTargetFeatures(const Driver
&D,
CPUArgFPUKind != llvm::ARM::FK_INVALID ? CPUArgFPUKind :
ArchArgFPUKind;
(void)llvm::ARM::getFPUFeatures(FPUKind, Features);
} else {
+bool Generic = true;
if (!ForAS) {
mstorsjo wrote:
> Maybe this is a hidden bug, but I haven't investigated it too deeply,
> @mstorsjo may know better.
Sorry, no clue offhand here.
> If you build MinGW LTO libunwind without `-fno-exceptions` or with
> -`fexceptions`, libunwind references `__gcc_personality_seh0`, which results
mstorsjo wrote:
> Setting default features for a platform based on what we happened to choose
> (likely with a very thin justification) to be the default CPU sounds fragile
> to me, so I think this patch is a good step forward. Even if there weren't
> this downstream patch interacting with it,
mstorsjo wrote:
> Or is it that this change allows other downstreams to patch the Linux issue
> in a way that does not break Windows and iOS in the process?
Exactly - this makes it more explicit upstream, to make it easier to tweak for
downstreams for Linux targets, without breaking the other
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
mstorsjo wrote:
Admittedly, I'm not sure if this patch really is relevant for upstream or not,
as it doesn't really affect observable behaviour much at all. The main
observable difference on the clang driver level is that when compiling
assembly, `-target-feature` arguments are now passed on t
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/122095
Upstream LLVM implicitly enables NEON for any ARMv7 target.
Many platform ABIs with an ARMv7 baseline also include NEON in that, this is
the case on e.g. Windows and iOS. On Linux, however, things are not quit
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:
As background for other reviewers: GCC can be built with either the posix or
win32 thread model. This doesn't affect code generation much (at all?), but it
does affect libgcc and libstdc++ which are built in the same GCC build.
With the win32 thread model, libgcc/libstdc++ use
@@ -619,7 +619,13 @@ class ToolChain {
virtual bool SupportsEmbeddedBitcode() const { return false; }
/// getThreadModel() - Which thread model does this target use?
- virtual std::string getThreadModel() const { return "posix"; }
+ virtual std::string getThreadModel() c
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:
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 specific commit b
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:
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`
That's indeed a problem... Ho
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
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
@@ -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:
> > > 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
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
@@ -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
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
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
@@ -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
@@ -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:
As this test now does compilation for
@@ -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
@@ -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
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
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
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:
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
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:
> 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:
> > 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 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:
> 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 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:
> 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:
> > > 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:
> 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
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:
> > 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 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
@@ -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
@@ -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(
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
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
@@ -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
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:
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:
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:
@@ -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
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
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
@@ -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
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
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
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:
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
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 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
@@ -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
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
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
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
__
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:
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
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
_
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
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
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
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,
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:
> 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
1 - 100 of 517 matches
Mail list logo
