mstorsjo wrote:
> You're right, I don't think there is a reason to check the stack location in
> this test, just how it was serialized. I'll push a change and hopefully
> this'll be fixed. Thanks for the notes!
Thanks for the fix in 4da5e9dd320e9d48be0fa05ba1a8faf50fb53834, that does seem
to
@@ -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) {
@@ -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) {
@@ -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) {
@@ -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:
This change broke building Qt (tested with 6.8), ending up with errors like
this:
```
qtbase/src/corelib/kernel/qcoreapplication.cpp:2946:78: error: 'this' cannot be
used in a static member function declaration
2946 | : slotObject(std::move(slotObject)), context(co
mstorsjo wrote:
> Thanks, for the report, will be fixed by #132551
Thanks for the quick fix, I can confirm that Qt builds fine for me again!
https://github.com/llvm/llvm-project/pull/132401
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https
mstorsjo wrote:
Regardless of whether this is backportable or not (it probably isn't), it's
probably nicer for future digging into the history to land this as a separate
split out part from the rest of #130623 (which currently changes quite a lot of
different things), as this is mostly an inde
@@ -1181,7 +1228,9 @@ DEFINE_LIBUNWIND_FUNCTION(__unw_getcontext)
#endif
+#ifndef __arm64ec__
mstorsjo wrote:
Can you explain why this has to be ifdeffed out here?
https://github.com/llvm/llvm-project/pull/138583
https://github.com/mstorsjo approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/138783
___
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/138783
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1181,7 +1228,9 @@ DEFINE_LIBUNWIND_FUNCTION(__unw_getcontext)
#endif
+#ifndef __arm64ec__
mstorsjo wrote:
Thanks, that's indeed cleaner when one clearly see which bits are the arm64ec
version of that line.
https://github.com/llvm/llvm-project/pull/1385
mstorsjo wrote:
> Would backporting this be worthwhile?
I guess it could be considered. However in practice I'm not aware of any
external cases that actually use the "force unwinding" functionality, outside
of the libunwind/libcxxabi testsuite. My main motivation is having the
`check-unwind`
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/137951
___
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/137950
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
Thanks, the changes look good to me. However, as this is already neatly split
into three separate commits, it would be nice to retain that separation after
merging. The llvm github repo is configured to only do "squash and merge", so
to retain the separation, it would have to b
https://github.com/mstorsjo approved this pull request.
LGTM, thanks!
https://github.com/llvm/llvm-project/pull/135691
___
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/137949
___
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/137950
From fb51e2b9f4965df52940c7cc672de863f34a1773 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Tue, 18 Apr 2023 23:28:20 +0300
Subject: [PATCH] [libunwind] [SEH] Implement parsing of ARM p
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/135691
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
> If this is right, it should probably be done to other standalone-capable
> projects' CMakeLists.txt also (LLD in particular, for my interests).
> Actually, it seems there's nothing in LLD that requires _GNU_SOURCE on
> Cygwin...
Yep, indeed.
I guess the main question is who
https://github.com/mstorsjo edited
https://github.com/llvm/llvm-project/pull/138583
___
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. Quite amazing if this is the only change needed, if the existing `#ifdef
__x86_64__` work as needed here (except for the force unwinding tests).
https://github.com/llvm/llvm-project/pull/138583
___
mstorsjo wrote:
> These tests that run `env PATH="" %clang_dxc ...` are problematic for my
> setup for running tests on Windows.
>
> In my builds, I'm building with a dynamically linked `libc++.dll` provided by
> my toolchain, which is available in `$PATH`, so the built `bin/clang.exe`
> requ
mstorsjo wrote:
FYI, note that even if you include clang changes here, those won't be used by
the libcxx CI build; the CI uses a prebuilt build of llvm-mingw - see
`.github/workflows/libcxx-build-and-test.yaml`.
https://github.com/llvm/llvm-project/pull/140169
_
https://github.com/mstorsjo approved this pull request.
LGTM (will merge later today, to give some grace time for others to comment,
even if it is unlikely that there's anything to object to here).
https://github.com/llvm/llvm-project/pull/139797
___
@@ -2,6 +2,8 @@
// RUN: %clang_cc1 -triple x86_64-windows-msvc -fms-extensions -emit-llvm
-std=c11 -O0 -o - %s | FileCheck %s
// RUN: %clang_cc1 -triple i686-windows-gnu-fms-extensions -emit-llvm
-std=c11 -O0 -o - %s | FileCheck %s
// RUN: %clang_cc1 -triple x86_64-window
https://github.com/mstorsjo edited
https://github.com/llvm/llvm-project/pull/139797
___
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
https://github.com/llvm/llvm-project/pull/139798
___
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/139797
___
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/139799
___
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/139798
___
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
https://github.com/llvm/llvm-project/pull/139799
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
No objections from me. (I haven’t had time to look at it in detail, but it
doesn’t seem like an area I’m familiar with anyway, and it sounds like @aganea
has given it a thorough check.)
https://github.com/llvm/llvm-project/pull/138972
___
https://github.com/mstorsjo approved this pull request.
LGTM
IIRC @petrhosek had commented on this before, and was generally in favour of
it, but I'd still leave it open for a couple days if he wants to comment
further on it.
https://github.com/llvm/llvm-project/pull/138587
__
mstorsjo wrote:
> I rebased this on top of #138783 and adjusted the title and description. Now
> it should be in a good state to push cmake changes for other projects.
The changes look good, but it looks like the changes from #138783 still show up
when viewing the changes; can you check that y
@@ -882,6 +882,11 @@ if (LLVM_ENABLE_WARNINGS AND
(LLVM_COMPILER_IS_GCC_COMPATIBLE OR CLANG_CL))
# The LLVM libraries have no stable C++ API, so -Wnoexcept-type is not
useful.
append("-Wno-noexcept-type" CMAKE_CXX_FLAGS)
+ # LLVM has a policy of including virtual "ancho
@@ -882,6 +882,11 @@ if (LLVM_ENABLE_WARNINGS AND
(LLVM_COMPILER_IS_GCC_COMPATIBLE OR CLANG_CL))
# The LLVM libraries have no stable C++ API, so -Wnoexcept-type is not
useful.
append("-Wno-noexcept-type" CMAKE_CXX_FLAGS)
+ # LLVM has a policy of including virtual "ancho
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/142373
On Windows, we hit the "no such file or directory" case, not the "Not a
directory" one.
MS STL produces the "no such file or directory" message for
`std::error_code(ENOENT, std::generic_category()).message()`
mstorsjo wrote:
CC @snarang181
https://github.com/llvm/llvm-project/pull/142373
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
> I too had trouble understanding this change based on the description. Could
> you give a concrete example of how mingw and msvc disagree on where to put
> the attribute, and explain how this pr changes things?
>
> Taking a step back, how will this simplify libc++'s visibility
@@ -9,7 +9,6 @@ define i32 @foobar() gc "statepoint-example" personality ptr
@__gxx_personality_
; CHECK-NEXT:.seh_endprologue
; CHECK-NEXT:callq bar
; CHECK-NEXT: .Ltmp0:
-; CHECK-NEXT:nop
mstorsjo wrote:
The Windows GNU target does use SEH for
@@ -0,0 +1,37 @@
+// RUN: %clang_cc1 -triple x86_64-windows-gnu -emit-llvm < %s | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-pc-cygwin -emit-llvm < %s | FileCheck %s
+
+// copy ms_abi block only from ../ms_abi.c
mstorsjo wrote:
Not sure how relevant the comm
https://github.com/mstorsjo approved this pull request.
LGTM, with one minor comment.
https://github.com/llvm/llvm-project/pull/143115
___
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/143115
___
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
https://github.com/llvm/llvm-project/pull/143117
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,37 @@
+// RUN: %clang_cc1 -triple x86_64-windows-gnu -emit-llvm < %s | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-pc-cygwin -emit-llvm < %s | FileCheck %s
+
+// copy ms_abi block only from ../ms_abi.c
mstorsjo wrote:
Yes, exactly
https://github.c
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/143117
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
> I'm not seeing an obvious place for a target-specific va_list test, can you
> suggest where this would go?
No idea offhand; I tried breaking the existing `getBuiltinVaListKind` for
`WindowsX86_64TargetInfo` and running `check-clang`, which caused failures in
the following te
mstorsjo wrote:
> I wasn't sure whether to enable this for UEFI targets as well, so I didn't. I
> enabled it for MinGW targets too, since I saw no reason to treat them
> differently.
Hmm, so a "regular" mingw object file would end up having both DWARF (if
building with `-g`) and codeview (for
mstorsjo wrote:
The change looks good, but can we have a test for it in some form?
https://github.com/llvm/llvm-project/pull/143166
___
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/143115
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
> AFAIK the dllexport annotations have been added using some automated tools,
> so it may be good to find the person who added the other annotations, so it
> can be looked into why this was missing here, if the annotations otherwise
> were seemingly complete enough.
Sorry, not
mstorsjo wrote:
AFAIK the dllexport annotations have been added using some automated tools, so
it may be good to find the person who added the other annotations, so it can be
looked into why this was missing here, if the annotations otherwise were
seemingly complete enough.
https://github.com
mstorsjo wrote:
> Before merge this, requires #147108
Can you elaborate on why this is needed - what happens without it - wouldn't
that issue be happening already now in regular win32 builds so far?
https://github.com/llvm/llvm-project/pull/147122
__
https://github.com/mstorsjo approved this pull request.
Thanks, this looks good to me! I'd still wait a little bit in case a Clang
maintainer has an opinion on it, but it seems to fix the issue for me.
https://github.com/llvm/llvm-project/pull/146643
mstorsjo wrote:
> > This broke building C++ modules for mingw targets. Repro:
> > `empty.cppm`:
> > ```c++
> > export module empty;
> > ```
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ```
> > $ clang -target x86_64-windows-gnu -x c++-module empty.cppm
mstorsjo wrote:
This broke building C++ modules for mingw targets. Repro:
`empty.cppm`:
```c++
export module empty;
```
```console
$ clang -target x86_64-windows-gnu -x c++-module empty.cppm -c -o
empty.cppm.obj -std=gnu++23
error: invalid value 'seh' in '-exception-model=seh'
```
https://git
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/148064
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
I'll go ahead and land this now to unbreak my builds.
https://github.com/llvm/llvm-project/pull/146643
___
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/146643
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Martin Storsjö
Date: 2025-07-02T23:58:22+03:00
New Revision: 551d6ddaa3810749ecae33f65759870b78b9a86a
URL:
https://github.com/llvm/llvm-project/commit/551d6ddaa3810749ecae33f65759870b78b9a86a
DIFF:
https://github.com/llvm/llvm-project/commit/551d6ddaa3810749ecae33f65759870b78b9a86a.diff
mstorsjo wrote:
I pushed a fix to add `REQUIRES: x86-registered-target` in
551d6ddaa3810749ecae33f65759870b78b9a86a.
https://github.com/llvm/llvm-project/pull/146643
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bi
mstorsjo wrote:
> > > Before merge this, requires #147108
> >
> >
> > Can you elaborate on why this is needed - what happens without it -
> > wouldn't that issue be happening already now in regular win32 builds so far?
>
> The linker reports undefined reference to
> clang_install_aborting_ll
mstorsjo wrote:
> > > Still it may be good to figure out why this hasn't been an issue so far,
> > > for whoever otherwise were using these dllexport annotations.
> >
> >
> > I suspect it relates to module definition file (*.def). On MinGW, the
> > symbol is properly exported without annotati
https://github.com/mstorsjo approved this pull request.
LGTM, thanks.
But we should wait for https://github.com/llvm/llvm-project/pull/147108 to land
first before merging this.
https://github.com/llvm/llvm-project/pull/147122
___
cfe-commits mailing
https://github.com/mstorsjo approved this pull request.
LGTM, but can you amend the PR description with the extra info you gathered,
about why this hasn't been an issue in other existing configurations?
https://github.com/llvm/llvm-project/pull/147108
___
https://github.com/mstorsjo approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/147278
___
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/147108
___
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/147122
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -107,3 +110,282 @@ void Cygwin::AddClangSystemIncludeArgs(const ArgList
&DriverArgs,
addExternCSystemInclude(DriverArgs, CC1Args, SysRoot + "/usr/include");
addExternCSystemInclude(DriverArgs, CC1Args, SysRoot +
"/usr/include/w32api");
}
+
+static bool getStaticPIE(con
@@ -1504,6 +1506,7 @@ void ToolChain::AddCXXStdlibLibArgs(const ArgList &Args,
switch (Type) {
case ToolChain::CST_Libcxx:
CmdArgs.push_back("-lc++");
+CmdArgs.push_back("-lc++abi");
mstorsjo wrote:
libc++abi and libc++ have circular dependencies -
601 - 672 of 672 matches
Mail list logo
