https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/125045
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/DavidSpickett commented:
Just a drive by style comment.
https://github.com/llvm/llvm-project/pull/125045
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,65 @@
+#include "clang/Sema/Common.h"
+
+namespace clang {
DavidSpickett wrote:
https://llvm.org/docs/CodingStandards.html#use-namespace-qualifiers-to-implement-previously-declared-functions
For example clang::CheckArgTypeIsCorrect instead of opening
https://github.com/DavidSpickett approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/122881
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1071,6 +1071,10 @@ Arm and AArch64 Support
- Implementation of SVE2.1 and SME2.1 in accordance with the Arm C Language
Extensions (ACLE) is now available.
+- For ARM baremetal targets, the frame pointer (FP) is now turned off by
+ default. To turn on frame pointers for
@@ -1076,6 +1076,8 @@ Arm and AArch64 Support
in leaf functions after enabling ``-fno-omit-frame-pointer``, you can do so
by adding
the ``-momit-leaf-frame-pointer`` option.
+- For ARM baremetal targets, the frame pointer (FP) is now turned off by
default.
--
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/122881
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
DavidSpickett wrote:
Yeah, my first impression from the commit message was that you removed the
check entirely.
https://github.com/llvm/llvm-project/pull/122969
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mai
@@ -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) {
https://github.com/DavidSpickett approved this pull request.
My understanding is that:
* This PR does not conflict with what the Debian patch does.
* It in fact will fix a bug in the Debian build.
* This does not change the behaviour of an unmodified Clang from a user's
perspective, therefore we
https://github.com/DavidSpickett edited
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
DavidSpickett wrote:
Make sure to update the *PR Description* as this becomes the commit message
when the squash and merge happens.
(yes, this is confusing but that's how llvm is set up)
But what I read makes sense thank you for rephrasing the commit message.
https://github.com/llvm/llvm-proj
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/134366
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -463,6 +466,7 @@ X86 Support
Arm and AArch64 Support
^^^
+- For ARM targets, cc1as now considers the FPU's features for the selected CPU
or Arch.
DavidSpickett wrote:
Arch -> architecture
https://github.com/llvm/llvm-project/pull/1346
https://github.com/DavidSpickett approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/134612
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/130589
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -679,20 +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) {
@@ -0,0 +1,32 @@
+// REQUIRES: arm-registered-target
+// Ensures that when targeting an ARM target with an Asm file, clang
DavidSpickett wrote:
I have often been asked to use `///` for comments that were actually comments.
I think it is marginally easier to read
@@ -0,0 +1,32 @@
+// REQUIRES: arm-registered-target
+// 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 V
@@ -0,0 +1,32 @@
+// REQUIRES: arm-registered-target
+// 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 V
DavidSpickett wrote:
I've
[disabled](https://github.com/llvm/llvm-project/commit/f7fdc8d0cf7cd5caa7d463e1e80e0d5a08c71bb2)
the test when threads are disabled.
I don't think it needs to be limited to Apple Silicon actually, because a new
OS thread should pass the test (and apparently does). Bu
DavidSpickett wrote:
That build sets `-DLLVM_ENABLE_THREADS=OFF`. `LLVM_HAS_SPLIT_STACKS_AARCH64`
and `LLVM_HAS_SPLIT_STACKS` are false, which means we use:
```
void llvm::runOnNewStack(unsigned StackSize, function_ref Fn) {
llvm::thread Thread(
StackSize == 0 ? std::nullopt : std::optio
DavidSpickett wrote:
Same sort of thing on our Armv8 32-bit build:
https://lab.llvm.org/buildbot/#/builders/122/builds/1478
```
../llvm/llvm/unittests/Support/ProgramStackTest.cpp:32
Expected: (StackDistance) > (llvm::sys::Process::getPageSizeEstimate()),
actual: 8 vs 4096
```
https://github.
https://github.com/DavidSpickett created
https://github.com/llvm/llvm-project/pull/130589
https://github.com/llvm/llvm-project/pull/129952 /
42d49a77241df73a17cb442973702fc460e7fb90 added this test which is failing on
32-bit ARM because the alignment chosen is 4 not 8. Which would make sense i
DavidSpickett wrote:
The failure above is real, ABI or 32-bitness issue I think. Looking at it now.
https://github.com/llvm/llvm-project/pull/129952
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/130589
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
DavidSpickett wrote:
https://github.com/llvm/llvm-project/pull/130589
https://github.com/llvm/llvm-project/pull/129952
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
DavidSpickett wrote:
> used to emable or disable
enable
https://github.com/llvm/llvm-project/pull/130623
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
DavidSpickett wrote:
Can someone from @llvm/reviewers-libcxx help with the FreeBSD failure? Seems
unrelated.
https://github.com/llvm/llvm-project/pull/103473
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailma
https://github.com/DavidSpickett commented:
I see that this would be breaking for code unintentionally relying on the
features being omitted, but it makes sense to fix it nevertheless. I would have
expected us to add the features all along.
What does gcc/binutils do in this scenario? I don't t
@@ -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
@@ -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) {
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/141921
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/DavidSpickett created
https://github.com/llvm/llvm-project/pull/141921
This was added by 8eb34700c2b1847ec6dfb8f92b305b65278d2ec0 which added an opt
into the new ignore list behaviour.
Then 81d1df2a39f0616be4b530cbf86b3f575442a347 flipped it so you had to opt into
the old b
Timm =?utf-8?q?Bäder?= ,
Timm =?utf-8?q?Bäder?=
Message-ID:
In-Reply-To:
DavidSpickett wrote:
This only reproduces if we build it with clang (19.1.7, but might not be
version specific). I added a debug trap in place of the assert and got a better
traceback:
```
-- Testing: 1 tests, 1 workers
Timm =?utf-8?q?Bäder?= ,
Timm =?utf-8?q?Bäder?=
Message-ID:
In-Reply-To:
DavidSpickett wrote:
So after the fixup this failed again:
https://lab.llvm.org/buildbot/#/builders/154/builds/17588
```
TEST 'Clang :: AST/ByteCode/intap.cpp' FAILED
Exit Code:
Timm =?utf-8?q?Bäder?= ,
Timm =?utf-8?q?Bäder?=
Message-ID:
In-Reply-To:
DavidSpickett wrote:
Short of cross-compiling, a debug build isn't happening.
I know so far is that the last thing it attempts to do is construct an APInt
with:
```
Bitwidth: 2, val: 0xffe64100
```
We need to fi
Timm =?utf-8?q?Bäder?= ,
Timm =?utf-8?q?Bäder?=
Message-ID:
In-Reply-To:
DavidSpickett wrote:
When applied to 7c15edb306932e41c159f3d69c161ed0d89d47b7, this fixes the
problem and passes check-clang.
Reland in whatever way you prefer (no need for extra review), as you know, the
bot will rapi
Timm =?utf-8?q?Bäder?= ,
Timm =?utf-8?q?Bäder?=
Message-ID:
In-Reply-To:
DavidSpickett wrote:
I see you reverted due to
https://lab.llvm.org/buildbot/#/builders/154/builds/17549. In case you don't
know, that builder is Armv8 32-bit.
Unless you get reports from our other, 64-bit builders, it
Author: David Spickett
Date: 2025-06-10T15:13:34Z
New Revision: beffd1509af7b12eeab0d5ae85b2f8322e039287
URL:
https://github.com/llvm/llvm-project/commit/beffd1509af7b12eeab0d5ae85b2f8322e039287
DIFF:
https://github.com/llvm/llvm-project/commit/beffd1509af7b12eeab0d5ae85b2f8322e039287.diff
LOG
DavidSpickett wrote:
I've disabled the failing `RUN` line on Windows and opened
https://github.com/llvm/llvm-project/issues/143547 with details of what's
happening.
Let me know if anything stands out to you. Also would be useful if I can see
the code produced at the different optimisation lev
DavidSpickett wrote:
After this change the test labda.cpp is failing on Linaro's Windows on Arm
clang bots. They were stuck for other reasons and only just got back up to
date, so here's a new build showing the failure:
https://lab.llvm.org/buildbot/#/builders/161/builds/6473
```
cat
C:\Users\
DavidSpickett wrote:
Thanks for confirming, yes, your patch is working as expected but something
about Windows' output is tripping up FileCheck I think.
Linux does not print the `clang-repl>` (maybe because it can tell it's
outputting to a non-interactive pipe):
```
$ cat ../llvm-project/clang
DavidSpickett wrote:
Also failing on Windows x64, but this time the error is better:
https://lab.llvm.org/buildbot/#/builders/63/builds/7023
And now I see the actual problem, all I had to do was scroll up :)
```
# .---command stderr
# | In file included from <<< inputs >>>:1:
# | inp
Author: David Spickett
Date: 2025-07-03T13:36:30Z
New Revision: d805707ee435fbe83440ceaf0eb515bf1d536f01
URL:
https://github.com/llvm/llvm-project/commit/d805707ee435fbe83440ceaf0eb515bf1d536f01
DIFF:
https://github.com/llvm/llvm-project/commit/d805707ee435fbe83440ceaf0eb515bf1d536f01.diff
LOG
DavidSpickett wrote:
The actual error is the same as seen elsewhere:
```
$ /home/david.spickett/build-llvm-aarch64/bin/flang
--target=aarch64-pc-windows-msvc -Werror
../llvm-project/flang/test/Semantics/windows.f90
flang-21: warning: unable to find a Visual Studio installation; try running
Cla
DavidSpickett wrote:
The warning:
```
RUN: at line 1 has no command after substitutions
```
Is because the test looks for the wrong target to be enabled, this will be
fixed by: https://github.com/llvm/llvm-project/pull/146869
It's not the cause of the failure.
https://github.com/llvm/llvm-proj
https://github.com/DavidSpickett created
https://github.com/llvm/llvm-project/pull/146836
Reverts llvm/llvm-project#146582
Due to failures on many of Linaro's Linux flang bots:
https://lab.llvm.org/buildbot/#/builders/17/builds/9292
```
TEST 'Flang :: Semantics/windows.f9
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/146836
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
DavidSpickett wrote:
I've reverted this due to a test failure on our Linux bots:
https://lab.llvm.org/buildbot/#/builders/17/builds/9292
And if I understand correctly, flang needs another patch before it can build
properly on Windows:
```
FAILED: include/flang/__fortran_builtins.mod
C:/Users/
DavidSpickett wrote:
I also got a report of a downstream failure:
```
09:53:25 FAIL: Clang :: Sema/deep_recursion.c (18481 of 84779)
09:53:25 TEST 'Clang :: Sema/deep_recursion.c' FAILED
09:53:25 Exit Code: 139
09:53:25
09:53:25 Command Output (std
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/149235
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/149235
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -158,12 +158,12 @@ TEST_F(InterpreterTest, UndoCommand) {
// Fail to undo.
auto Err1 = Interp->Undo();
- EXPECT_EQ("Operation failed. Too many undos",
+ EXPECT_EQ("Operation failed. No input left to undo",
llvm::toString(std::move(Err1)));
auto Err2 =
@@ -158,12 +158,12 @@ TEST_F(InterpreterTest, UndoCommand) {
// Fail to undo.
auto Err1 = Interp->Undo();
- EXPECT_EQ("Operation failed. Too many undos",
+ EXPECT_EQ("Operation failed. No input left to undo",
llvm::toString(std::move(Err1)));
auto Err2 =
DavidSpickett wrote:
https://github.com/llvm/llvm-project/pull/149396#issuecomment-3088555387 is one
of our automated checks, please follow its guidance. The reason we do this is
so we can attribute changes for reasons around the licensing of contributions,
there's more info in those links. It
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/149396
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/149396
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -158,12 +158,12 @@ TEST_F(InterpreterTest, UndoCommand) {
// Fail to undo.
auto Err1 = Interp->Undo();
- EXPECT_EQ("Operation failed. Too many undos",
+ EXPECT_EQ("Operation failed. No input left to undo",
llvm::toString(std::move(Err1)));
auto Err2 =
DavidSpickett wrote:
FYI
https://discourse.llvm.org/t/rfc-rename-source-files-in-clang-lib-codegen-targetbuiltins/87462
https://github.com/llvm/llvm-project/pull/132252
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi
https://github.com/DavidSpickett approved this pull request.
LGTM
@aadanen you won't be able to merge this yourself but I can once you've fixed
the formatting.
https://github.com/llvm/llvm-project/pull/149396
___
cfe-commits mailing list
cfe-commits@
DavidSpickett wrote:
You have formatting to fix, I suggest you just copy and paste the diff in this
one time.
Folks will have different ways to setup clang-format, I use the script
https://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting and
manually run it (because I am too
DavidSpickett wrote:
> I am able to build clang, compile the project, and I am currently running the
> "ninja check-clang-unit" tests. Although it does take an incredibly long time
> ( 45 minutes to an hour) but that's off topic
llvm/clang is not a light build at the best of times, but there a
DavidSpickett wrote:
Looks great! CI should confirm the test is correct, and I added the clang-repl
maintainer on review in case they have anything to say.
https://github.com/llvm/llvm-project/pull/149396
___
cfe-commits mailing list
cfe-commits@lists
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/149396
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/DavidSpickett edited
https://github.com/llvm/llvm-project/pull/149396
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
DavidSpickett wrote:
I don't have an opinion either way but there are more users of `GlobPattern` so
you should check the impact on them.
https://github.com/llvm/llvm-project/pull/149886
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://
601 - 668 of 668 matches
Mail list logo
