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:
> 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,
@@ -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 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 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
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
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:
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.
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:
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) {
@@ -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:
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:
> 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
@@ -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:
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
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
mstorsjo wrote:
> > clang/lib/CodeGen/CGBuiltin.cpp is over 1MB long (>23k LoC), and can take
> > minutes to recompile (depending on compiler and host system) when modified,
> > and 5 seconds for clangd to update for every edit. Splitting this file was
> > discussed in this thread:
>
> It loo
@@ -13,7 +13,7 @@
#include
#ifdef _WIN32
-#include
+#include
mstorsjo wrote:
mingw-w64 doesn't have `corecrt_malloc.h` (yet), so unfortunately we can't go
this way in general. Perhaps we could for `!defined(__MINGW32__)` or
`defined(_MSC_VER)` though.
A
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
@@ -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
--
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
@@ -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
--
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:
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:
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
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:
> 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 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
@@ -180,35 +170,14 @@ bool InitHeaderSearch::AddUnmappedPath(const Twine &Path,
IncludeDirGroup Group,
return false;
}
-void InitHeaderSearch::AddMinGWCPlusPlusIncludePaths(StringRef Base,
- StringRef Arch,
-
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
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
@@ -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() &&
+
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
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:
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 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
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/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
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
@@ -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) {
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
@@ -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;
+/
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
@@ -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
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 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-
@@ -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
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/137949
___
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:
> 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
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
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/138119
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -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
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:
> 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:
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-
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
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
@@ -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
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:
> 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
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
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:
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
@@ -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/137949
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/137950
Rate limit · GitHub
body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe
UI,Helvetica,Arial,sans-
@@ -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 = (
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
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/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 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/138118
___
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/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:
This is quite a tricky area...
On Windows, EmulatedTLS _is_ disabled by default, both in MSVC targets and
MinGW targets. However, for interop with (GCC's) libstdc++ (which currently
exposes TLS symbols in the public ABI), users may need to enable emulated TLS
if linking agains
@@ -4769,31 +4769,32 @@ ExprResult Sema::CheckOSLogFormatStringArg(Expr *Arg) {
/// Check that the user is calling the appropriate va_start builtin for the
/// target and calling convention.
static bool checkVAStartABI(Sema &S, unsigned BuiltinID, Expr *Fn) {
- const llvm::Tri
mstorsjo wrote:
> Doesn't mingw target support it?
I'm pretty sure that profiling already works, both in mingw and MSVC
configurations. I'm not familiar with all the nuances in various forms of
profiling though, so it's unclear to me if this is some specific fringe
configuration which didn't
mstorsjo wrote:
Thanks for the very thorough explanation!
> Note if we miss a condition/configuration then it doesn't break the feature
> there, it just would
> [fail](https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/profile/InstrProfilingFile.c#L662)
> at runtime if you try ena
@@ -597,6 +597,9 @@ llvm::Error Interpreter::CreateExecutor() {
auto JTMB = createJITTargetMachineBuilder(TT);
if (!JTMB)
return JTMB.takeError();
+#if defined(_WIN32)
mstorsjo wrote:
I'm not sure what the common practice is for the JIT/interpret
mstorsjo wrote:
> > So I believe this should be generalized to all of Windows (and/or
> > generalized to check for a COFF object file format?) instead of singling
> > out specifically MSVC only.
>
> Thanks for checking. I can fix the condition but can you please let me know
> which of the two
mstorsjo wrote:
> @mstorsjo FYI:
> [9ef7287d425](https://github.com/llvm/llvm-project/commit/9ef7287d425)
Thank you!
https://github.com/llvm/llvm-project/pull/127858
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-b
@@ -0,0 +1,31 @@
+// Ensures that when targeting an ARM target with an Asm file, clang
+// collects the features from the FPU. This is critical in the
+// activation of NEON for supported targets. The Cortex-R52 will be
+// used and tested for VFP and NEON Support
+
+// RUN: %clan
mstorsjo wrote:
This is a smaller, self-isolated change split out from #130623 - in order to
fix a regression from 8fa0f0efce5fb81eb422e6d7eec74c66dafef4a3 as noted by
@anemet in
https://github.com/llvm/llvm-project/pull/122095#discussion_r2027399582; in a
form that hopefully can be considere
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/134366
Previously, FPU features were not collected when forming a list of features for
the Assembler.
This fixes a regression from 8fa0f0efce5fb81eb422e6d7eec74c66dafef4a3, which
caused VFPv4 to be unavailable if as
mstorsjo wrote:
> Maybe the test needs to be relaxed a bit because of stack layout differences
> in other OS targets? Although I'm not sure why they're different. See
> https://lab.llvm.org/buildbot/#/builders/186/builds/7896:
>
> ```
> TEST 'AddressSanitizer-arm-android :
501 - 600 of 673 matches
Mail list logo
