@@ -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
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/137949
This is needed for forced unwind, for some testcases in libunwind/libcxxabi.
This adds an aarch64 case for extracting the LanguageHandler and HandlerData
fields from unwind info, in UnwindCursor::getInfoFromSE
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`
requires finding
mstorsjo wrote:
I guess another way about it, is to require me to copy in all dependent DLLs
into the built `bin` directory next to `clang.exe` etc. But that's an extra
step that hasn't been needed so far...
https://github.com/llvm/llvm-project/pull/135876
_
mstorsjo wrote:
> > Then secondly, LLVM only allows "squash and merge" merging of PRs - so all
> > these nicely split changes (with individual explanations soon, I'd hope!)
> > would end up all mushed together. So unfortunately, to preserve the info
> > about each of them, they'd need to be fi
mstorsjo wrote:
These changes mostly look good to me, but it all feels a bit unclear to me
still. So I'd appreciate e.g. one or a few sentences in the commit message on
each of these commits, to explain a bit about the why/how and how things work
in other preexisting environments. Is this for
mstorsjo wrote:
> FYI @mstorsjo I reverted the breaking change
> [here](https://github.com/llvm/llvm-project/commit/b60ee399787cb2a5f50d21932db3492cc4ff0d34),
> and I'll reapply it fixing the regression when I have a fix for it, sorry
> for the trouble.
No problem, thanks for reverting to a b
mstorsjo wrote:
This change makes Clang produce warnings when building Clang itself; warnings
looking like this:
```
/home/martin/code/llvm-project/clang/include/clang/Basic/LangOptions.def:352:1:
warning: bit-field 'FPEvalMethod' is not wide enough to store all enumerators
of preferred type '
https://github.com/mstorsjo edited
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:
I think we should revert https://github.com/llvm/llvm-project/pull/128222 if we
can't move forward with this one soon. Unfortunately I'm not sure if I'm
qualified to review it.
https://github.com/llvm/llvm-project/pull/136742
___
cfe-
@@ -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 commented:
I think the test looks good, thanks!
I'd still want @MaskRay to ack this change before approving it though, as
adding a new toolchain driver is a notable change.
https://github.com/llvm/llvm-project/pull/135691
mstorsjo wrote:
> I'm fighting the tests on Windows - the hurd test I started from had `//
> UNSUPPORTED: system-windows` at the top, probably because they weren't
> interested in messing around with backslashes and .exe extensions. I don't
> know if the cross test will work right for the path
https://github.com/mstorsjo closed
https://github.com/llvm/llvm-project/pull/135701
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
> To me, the general theory is that Cygwin is more UNIXy than Windowsy, so I
> based this off of actually the Hurd.h/cpp (as it had pretty limited amounts
> of special cases).
Sounds like a reasonable guess. In practice it's probably somewhere inbetween,
and which side ends up
https://github.com/mstorsjo approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/135701
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -7230,7 +7230,9 @@ void Clang::ConstructJob(Compilation &C, const JobAction
&JA,
// -fuse-cxa-atexit is default.
if (!Args.hasFlag(
options::OPT_fuse_cxa_atexit, options::OPT_fno_use_cxa_atexit,
- !RawTriple.isOSAIX() && !RawTriple.isOSWindows() &&
+
mstorsjo wrote:
Oh, also, what's the tradeoff between having this extend the `Generic_GCC`
driver, vs doing a plain from-scratch implementation that extents the
`ToolChain` base class like the `MinGW` driver does? I guess that it's a
smaller step to just tweak `Generic_GCC`, not requiring all
mstorsjo wrote:
Adding @MaskRay as the Clang Driver maintainer.
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 edited
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
@@ -180,35 +170,14 @@ bool InitHeaderSearch::AddUnmappedPath(const Twine &Path,
IncludeDirGroup Group,
return false;
}
-void InitHeaderSearch::AddMinGWCPlusPlusIncludePaths(StringRef Base,
- StringRef Arch,
-
https://github.com/mstorsjo commented:
What test coverage do we have for targeting cygwin with clang right now? Do we
have enough tests to make sure that this is a refactoring, so things work
mostly like before, but with better structured code? If not, we should probably
add some sort of minim
mstorsjo wrote:
This breaks real-world code with MSVC headers.
Testcase:
```c
#include
#include
void func(void) { _InstructionSynchronizationBarrier(); }
```
```
$ bin/clang-cl --target=aarch64-windows-msvc -c isb.c
isb.c(3,19): error: call to undeclared library function '__isb' with type 'vo
mstorsjo wrote:
With https://martin.st/temp/abs-preproc.cpp as input, I run `clang -target
i686-w64-mingw32 abs-preproc.cpp -fsanitize=signed-integer-overflow -w -O3 -S
-emit-llvm -o abs-out.ll`, and I get the following diff of the output IR after
this change:
```diff
--- abs-good.ll 2025-04-2
mstorsjo wrote:
This change broke a couple of ubsan tests on i686 on Windows (i.e. a 32 bit
environment):
https://github.com/mstorsjo/llvm-mingw/actions/runs/14527591706/job/40770945907
The failing tests are
https://github.com/llvm/llvm-project/blob/llvmorg-20.1.3/compiler-rt/test/ubsan/TestC
mstorsjo wrote:
I can't really comment much on the implementation here, I would mostly leave
that up to people more familiar with those bits in Clang.
A little nitpickery wrt the text; it'd be clearer if it'd talk about "MSVC and
mingw". Both MSVC mode and mingw mode are equally much "win32" o
mstorsjo wrote:
> I'm still not sure about the Win/Darwin part, but otherwise LGTM.
We could fix it by adding a case for armv7 on Darwin in
`ARM::getARMCPUForArch`, which would allow getting rid of that special case
here. But as we currently have the special cases for Windows/Darwin here, I
w
@@ -679,21 +679,17 @@ 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) {
@@ -679,21 +679,17 @@ 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 compiling with `-DLLVM_LINK_LLVM_DYLIB=ON`, as seen in the
buildbot log above. Will revert later today if we don't have a fix.
https://github.com/llvm/llvm-project/pull/134298
___
cfe-commits mailing list
cfe-commits@
@@ -38,6 +38,9 @@ Potentially Breaking Changes
- Fix missing diagnostics for uses of declarations when performing typename
access,
such as when performing member access on a '[[deprecated]]' type alias.
(#GH58547)
+- For ARM targets, when using cc1as, the features included
@@ -0,0 +1,8 @@
+// Ensure that we can assemble NEON by just specifying an armv7
+// Apple or Windows target.
+
+// REQUIRES: arm-registered-target
+// RUN: %clang -c -target armv7-apple-darwin -o /dev/null %s
+// RUN: %clang -c -target armv7-windows -o /dev/null %s
--
@@ -0,0 +1,8 @@
+// Ensure that we can assemble NEON by just specifying an armv7
+// Apple or Windows target.
+
+// REQUIRES: arm-registered-target
+// RUN: %clang -c -target armv7-apple-darwin -o /dev/null %s
+// RUN: %clang -c -target armv7-windows -o /dev/null %s
--
https://github.com/mstorsjo approved this pull request.
Looks ok to me.
I don't know about whether this really works as expected with
`corecrt_malloc.h` or not, but I would expect you to have tested it.
We could look into adding `corecrt_malloc.h` in mingw-w64 as well, and then we
could simpl
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
1 - 100 of 638 matches
Mail list logo
