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
@@ -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 -
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
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 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, 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
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
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:
> 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
__
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:
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
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
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
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 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
@@ -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
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
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
@@ -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
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
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
@@ -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 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
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:
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
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:
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
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()`
@@ -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 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:
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
___
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
_
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
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 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 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
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
@@ -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 (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
___
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
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
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:
> 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 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 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/137949
___
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/135691
___
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
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
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
@@ -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 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:
> 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
mstorsjo wrote:
> Seems like the cherry-pick only works if the branch of the PR still exists. 🤔
That's not my experience with it. It looks like the cherry-pick command
yesterday just hit an unrelated issue:
https://github.com/llvm/llvm-project/actions/runs/14837157160/job/41650945562
https://
mstorsjo wrote:
@MaskRay Can you give the necessary @reviewers-libunwind approval here, given
@cjacek's review?
https://github.com/llvm/llvm-project/pull/137951
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mai
mstorsjo wrote:
@MaskRay Can you give the necessary @reviewers-libunwind approval here, given
@cjacek's review?
https://github.com/llvm/llvm-project/pull/137950
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mai
mstorsjo wrote:
@MaskRay Can you give the necessary @reviewers-libunwind approval here, given
@cjacek's review?
https://github.com/llvm/llvm-project/pull/137949
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mai
@@ -212,6 +238,21 @@ __libunwind_seh_personality(int version, _Unwind_Action
state,
ms_exc.ExceptionInformation[2] = state;
DISPATCHER_CONTEXT *disp_ctx =
__unw_seh_get_disp_ctx((unw_cursor_t *)context);
+#if defined(__aarch64__)
+ LOCAL_DISPATCHER_CONTEXT_NONVOLREG
https://github.com/mstorsjo updated
https://github.com/llvm/llvm-project/pull/137951
Rate limit · GitHub
body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe
UI,Helvetica,Arial,sans-
mstorsjo wrote:
> > Surprisingly, it looks like Cygwin (@tyan0) is working around the export
> > limit on gcc by setting `-DCMAKE_SHARED_LINKER_FLAGS=-fvisibility=hidden`.
>
> This was my misunderstanding. Building successfully was due to
> `-DLLVM_TARGETS_TO_BUILD=X86` which restrict target a
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/138217
___
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/138343
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
Offhand, I don't quite know here. Which configurations is this about? For
mingw, the only cases I'm familiar with is building with
`LLVM_LINK_LLVM_DYLIB=ON`, which iirc implicitly enables a corresponding one
for Clang too. Not sure which of the local variables here that maps to
@@ -106,7 +106,8 @@ if (LLVM_EXPORTED_SYMBOL_FILE)
DEPENDS ${LIBCLANG_VERSION_SCRIPT_FILE})
endif()
-if(LLVM_ENABLE_PIC OR (WIN32 AND NOT LIBCLANG_BUILD_STATIC))
+if((NOT (WIN32 OR CYGWIN) AND LLVM_ENABLE_PIC) OR
+ ((WIN32 OR CYGWIN) AND NOT LIBCLANG_BUIL
@@ -212,6 +212,11 @@ __libunwind_seh_personality(int version, _Unwind_Action
state,
ms_exc.ExceptionInformation[2] = state;
DISPATCHER_CONTEXT *disp_ctx =
__unw_seh_get_disp_ctx((unw_cursor_t *)context);
+#if defined(__aarch64__)
+ disp_ctx->NonVolatileRegisters = (
https://github.com/mstorsjo updated
https://github.com/llvm/llvm-project/pull/137951
Rate limit · GitHub
body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe
UI,Helvetica,Arial,sans-
@@ -2064,6 +2077,51 @@ bool UnwindCursor::getInfoFromSEH(pint_t pc) {
}
}
}
+#elif defined(_LIBUNWIND_TARGET_ARM)
mstorsjo wrote:
Sounds like a good idea; I updated this PR to share/reuse the aarch64 code for
ARM too.
https://github.com/llvm/llvm
https://github.com/mstorsjo updated
https://github.com/llvm/llvm-project/pull/137950
From 4f5614e410d1dc5147e2dacbacf64d4bd4ce7e82 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Tue, 18 Apr 2023 15:02:54 +0300
Subject: [PATCH 1/2] [libunwind] [SEH] Implement parsing of a
https://github.com/mstorsjo approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/138217
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
> Okay, you were right. Keeping this in a single description hurts readability
> a lot.
>
> So I have opened a series of smaller PRs: #138117 #138118 #138119 #138120
>
> This branch is equal to the other ones (once they are merged together), so we
> can go either way. I think
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/138120
___
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.
I updated the PR description with the details I wanted to have included in the
commit message.
https://github.com/llvm/llvm-project/pull/138120
___
cfe-commits mailing list
cfe-commits@lists.llvm
https://github.com/mstorsjo edited
https://github.com/llvm/llvm-project/pull/138120
___
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/138119
___
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/138118
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -212,6 +212,11 @@ __libunwind_seh_personality(int version, _Unwind_Action
state,
ms_exc.ExceptionInformation[2] = state;
DISPATCHER_CONTEXT *disp_ctx =
__unw_seh_get_disp_ctx((unw_cursor_t *)context);
+#if defined(__aarch64__)
+ disp_ctx->NonVolatileRegisters = (
https://github.com/mstorsjo updated
https://github.com/llvm/llvm-project/pull/137950
Rate limit · GitHub
body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe
UI,Helvetica,Arial,sans-
https://github.com/mstorsjo updated
https://github.com/llvm/llvm-project/pull/137949
Rate limit · GitHub
body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe
UI,Helvetica,Arial,sans-
@@ -2018,6 +2018,52 @@ bool UnwindCursor::getInfoFromSEH(pint_t pc) {
_info.handler = 0;
}
}
+#elif defined(_LIBUNWIND_TARGET_AARCH64)
+ if (unwindEntry->Flag != 0) { // Packed unwind info
+_info.end_ip = _info.start_ip + unwindEntry->FunctionLength * 4;
+/
mstorsjo wrote:
> If I grep through `/usr` for `_aligned_malloc` there are no matches for GCC
> and Clang guards it based on `_WIN32`:
>
> ```
> $ grep -R _aligned_malloc /usr -C2
> /usr/lib/clang/20/include/mm_malloc.h- void *__mallocedMemory;
> /usr/lib/clang/20/include/mm_malloc.h-#if defin
mstorsjo wrote:
> The parsing itself looks fine. I don't have any context for how this code is
> supposed to work, though.
Thanks! Yeah the whole context isn't entirely clear to me as well, but roughly
I think the idea is that we normally run `RtlUnwindEx` for unwinding an
exception, but this
@@ -0,0 +1,77 @@
+// RUN: %clang -### %s --target=i686-pc-windows-cygnus
--sysroot=%S/Inputs/basic_cygwin_tree \
+// RUN: -resource-dir=%S/Inputs/resource_dir \
+// RUN: --stdlib=platform 2>&1 | FileCheck --check-prefix=CHECK %s
+// CHECK: "-cc1"
+// CHECK-SAME: "-resour
https://github.com/mstorsjo ready_for_review
https://github.com/llvm/llvm-project/pull/138119
___
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/138118
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mstorsjo ready_for_review
https://github.com/llvm/llvm-project/pull/138118
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
Together with #137949 and #137950, this makes `check-cxxabi` and `check-unwind`
pass on aarch64 and arm.
https://github.com/llvm/llvm-project/pull/137951
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cg
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/137951
The CRT __C_specific_handler function uses this for restoring registers before
calling the filter function.
This fixes the libunwind/libcxxabi forced unwind testcases on ARM and AArch64.
From 27b7d0e7946fd030
mstorsjo wrote:
This goes on top of #137949.
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
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/137950
This is generally very similar to the aarch64 case.
Contrary to aarch64, the public headers don't contain any definition of a
struct for interpreting this data, so we provide our own.
From 8a03c40961c30bc7a73
1 - 100 of 672 matches
Mail list logo
