[clang] [clang-tools-extra] [flang] Reapply "[clang] Extend diagnose_if to accept more detailed warning information (#70976)" (PR #108453)
mikaelholmen wrote: Hello, I noticed that before this patch ```clang empty.c -fsanitize=undefined -ffine-grained-bitfield-accesses -c -Werror``` (on empty file empty.c) resulted in ```warning: option '-ffine-grained-bitfield-accesses' cannot be enabled together with a sanitizer; flag ignored``` but with the patch it results in ```error: option '-ffine-grained-bitfield-accesses' cannot be enabled together with a sanitizer; flag ignored [-Werror]``` Is this on purpose? https://github.com/llvm/llvm-project/pull/108453 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-format] Fix a bug in SpacesInParens InConditionalStatements (PR #108797)
https://github.com/owenca created
https://github.com/llvm/llvm-project/pull/108797
Fixes #64416.
>From 85e130d6e1fc1213f7daccf492aecc422c026c73 Mon Sep 17 00:00:00 2001
From: Owen Pan
Date: Mon, 16 Sep 2024 00:15:28 -0700
Subject: [PATCH] [clang-format] Fix a bug in SpacesInParens
InConditionalStatements
Fixes #64416.
---
clang/lib/Format/TokenAnnotator.cpp | 36 +--
clang/unittests/Format/FormatTest.cpp | 6 +
2 files changed, 23 insertions(+), 19 deletions(-)
diff --git a/clang/lib/Format/TokenAnnotator.cpp
b/clang/lib/Format/TokenAnnotator.cpp
index dfa703aed0d34d..9e36570bc6ff41 100644
--- a/clang/lib/Format/TokenAnnotator.cpp
+++ b/clang/lib/Format/TokenAnnotator.cpp
@@ -4418,31 +4418,29 @@ bool TokenAnnotator::spaceRequiredBetween(const
AnnotatedLine &Line,
Right.MatchingParen == &Left && Line.Children.empty()) {
return Style.SpaceInEmptyBlock;
}
- if ((Left.is(tok::l_paren) && Right.is(tok::r_paren)) ||
- (Left.is(tok::l_brace) && Left.isNot(BK_Block) &&
- Right.is(tok::r_brace) && Right.isNot(BK_Block))) {
-return Style.SpacesInParensOptions.InEmptyParentheses;
- }
- if (Style.SpacesInParens == FormatStyle::SIPO_Custom &&
- Style.SpacesInParensOptions.ExceptDoubleParentheses &&
- Left.is(tok::r_paren) && Right.is(tok::r_paren)) {
-auto *InnerLParen = Left.MatchingParen;
-if (InnerLParen && InnerLParen->Previous == Right.MatchingParen) {
- InnerLParen->SpacesRequiredBefore = 0;
- return false;
+ if (Style.SpacesInParens == FormatStyle::SIPO_Custom) {
+if ((Left.is(tok::l_paren) && Right.is(tok::r_paren)) ||
+(Left.is(tok::l_brace) && Left.isNot(BK_Block) &&
+ Right.is(tok::r_brace) && Right.isNot(BK_Block))) {
+ return Style.SpacesInParensOptions.InEmptyParentheses;
+}
+if (Style.SpacesInParensOptions.ExceptDoubleParentheses &&
+Left.is(tok::r_paren) && Right.is(tok::r_paren)) {
+ auto *InnerLParen = Left.MatchingParen;
+ if (InnerLParen && InnerLParen->Previous == Right.MatchingParen) {
+InnerLParen->SpacesRequiredBefore = 0;
+return false;
+ }
}
- }
- if (Style.SpacesInParensOptions.InConditionalStatements) {
const FormatToken *LeftParen = nullptr;
if (Left.is(tok::l_paren))
LeftParen = &Left;
else if (Right.is(tok::r_paren) && Right.MatchingParen)
LeftParen = Right.MatchingParen;
-if (LeftParen) {
- if (LeftParen->is(TT_ConditionLParen))
-return true;
- if (LeftParen->Previous && isKeywordWithCondition(*LeftParen->Previous))
-return true;
+if (LeftParen && (LeftParen->is(TT_ConditionLParen) ||
+ (LeftParen->Previous &&
+ isKeywordWithCondition(*LeftParen->Previous {
+ return Style.SpacesInParensOptions.InConditionalStatements;
}
}
diff --git a/clang/unittests/Format/FormatTest.cpp
b/clang/unittests/Format/FormatTest.cpp
index 5ebf0d7068dd6c..f9c6a6eca1d724 100644
--- a/clang/unittests/Format/FormatTest.cpp
+++ b/clang/unittests/Format/FormatTest.cpp
@@ -17282,6 +17282,12 @@ TEST_F(FormatTest, ConfigurableSpacesInParens) {
Spaces.SpacesInParens = FormatStyle::SIPO_Custom;
Spaces.SpacesInParensOptions = {};
Spaces.SpacesInParensOptions.Other = true;
+
+ EXPECT_FALSE(Spaces.SpacesInParensOptions.InConditionalStatements);
+ verifyFormat("if (a)\n"
+ " return;",
+ Spaces);
+
Spaces.SpacesInParensOptions.InConditionalStatements = true;
verifyFormat("do_something( ::globalVar );", Spaces);
verifyFormat("call( x, y, z );", Spaces);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-format] Fix a bug in SpacesInParens InConditionalStatements (PR #108797)
llvmbot wrote:
@llvm/pr-subscribers-clang-format
Author: Owen Pan (owenca)
Changes
Fixes #64416.
---
Full diff: https://github.com/llvm/llvm-project/pull/108797.diff
2 Files Affected:
- (modified) clang/lib/Format/TokenAnnotator.cpp (+17-19)
- (modified) clang/unittests/Format/FormatTest.cpp (+6)
``diff
diff --git a/clang/lib/Format/TokenAnnotator.cpp
b/clang/lib/Format/TokenAnnotator.cpp
index dfa703aed0d34d..9e36570bc6ff41 100644
--- a/clang/lib/Format/TokenAnnotator.cpp
+++ b/clang/lib/Format/TokenAnnotator.cpp
@@ -4418,31 +4418,29 @@ bool TokenAnnotator::spaceRequiredBetween(const
AnnotatedLine &Line,
Right.MatchingParen == &Left && Line.Children.empty()) {
return Style.SpaceInEmptyBlock;
}
- if ((Left.is(tok::l_paren) && Right.is(tok::r_paren)) ||
- (Left.is(tok::l_brace) && Left.isNot(BK_Block) &&
- Right.is(tok::r_brace) && Right.isNot(BK_Block))) {
-return Style.SpacesInParensOptions.InEmptyParentheses;
- }
- if (Style.SpacesInParens == FormatStyle::SIPO_Custom &&
- Style.SpacesInParensOptions.ExceptDoubleParentheses &&
- Left.is(tok::r_paren) && Right.is(tok::r_paren)) {
-auto *InnerLParen = Left.MatchingParen;
-if (InnerLParen && InnerLParen->Previous == Right.MatchingParen) {
- InnerLParen->SpacesRequiredBefore = 0;
- return false;
+ if (Style.SpacesInParens == FormatStyle::SIPO_Custom) {
+if ((Left.is(tok::l_paren) && Right.is(tok::r_paren)) ||
+(Left.is(tok::l_brace) && Left.isNot(BK_Block) &&
+ Right.is(tok::r_brace) && Right.isNot(BK_Block))) {
+ return Style.SpacesInParensOptions.InEmptyParentheses;
+}
+if (Style.SpacesInParensOptions.ExceptDoubleParentheses &&
+Left.is(tok::r_paren) && Right.is(tok::r_paren)) {
+ auto *InnerLParen = Left.MatchingParen;
+ if (InnerLParen && InnerLParen->Previous == Right.MatchingParen) {
+InnerLParen->SpacesRequiredBefore = 0;
+return false;
+ }
}
- }
- if (Style.SpacesInParensOptions.InConditionalStatements) {
const FormatToken *LeftParen = nullptr;
if (Left.is(tok::l_paren))
LeftParen = &Left;
else if (Right.is(tok::r_paren) && Right.MatchingParen)
LeftParen = Right.MatchingParen;
-if (LeftParen) {
- if (LeftParen->is(TT_ConditionLParen))
-return true;
- if (LeftParen->Previous && isKeywordWithCondition(*LeftParen->Previous))
-return true;
+if (LeftParen && (LeftParen->is(TT_ConditionLParen) ||
+ (LeftParen->Previous &&
+ isKeywordWithCondition(*LeftParen->Previous {
+ return Style.SpacesInParensOptions.InConditionalStatements;
}
}
diff --git a/clang/unittests/Format/FormatTest.cpp
b/clang/unittests/Format/FormatTest.cpp
index 5ebf0d7068dd6c..f9c6a6eca1d724 100644
--- a/clang/unittests/Format/FormatTest.cpp
+++ b/clang/unittests/Format/FormatTest.cpp
@@ -17282,6 +17282,12 @@ TEST_F(FormatTest, ConfigurableSpacesInParens) {
Spaces.SpacesInParens = FormatStyle::SIPO_Custom;
Spaces.SpacesInParensOptions = {};
Spaces.SpacesInParensOptions.Other = true;
+
+ EXPECT_FALSE(Spaces.SpacesInParensOptions.InConditionalStatements);
+ verifyFormat("if (a)\n"
+ " return;",
+ Spaces);
+
Spaces.SpacesInParensOptions.InConditionalStatements = true;
verifyFormat("do_something( ::globalVar );", Spaces);
verifyFormat("call( x, y, z );", Spaces);
``
https://github.com/llvm/llvm-project/pull/108797
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] handle invalid close location in static assert declaration (PR #108701)
cor3ntin wrote: > I'm not sure if this is acceptable for us. Yes, I don't think this uncommon failure mode requires doing more heroics than say we expect a parenthesis and don't crash https://github.com/llvm/llvm-project/pull/108701 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [llvm] [X86] AMD Zen 5 Initial enablement (PR #107964)
ganeshgit wrote: > @ganeshgit or @RKSimon can one of you put up a PR against release/19.x with > the abi compatible changes so that we have chance to look at it and approve > it before the release tomorrow. I will submit the changes shortly. Probably I will create a branch with a base commit which is prior to this commit to main for easy integration. https://github.com/llvm/llvm-project/pull/107964 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [analyzer][NFC] Add ArrayBoundV2 testcase to document bad cast modeling (PR #108799)
https://github.com/NagyDonat created
https://github.com/llvm/llvm-project/pull/108799
Add a FIXME testcase which documents less than ideal behavior of the analyzer
when a `const char *` is converted to `const unsigned char *`. This testcase is
motivated by an ArrayBoundV2 report produced on the source file `id3v2enc.c`
within the ffmpeg project.
From 728c3c9d8c0575acb144fb067736ab01873eb16e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?=
Date: Mon, 16 Sep 2024 09:20:25 +0200
Subject: [PATCH] [analyzer][NFC] Add a testcase documenting a borderline FP
report
Add a FIXME testcase which documents less than ideal behavior of the
analyzer when a `const char *` is converted to `const unsigned char *`.
This testcase is motivated by an ArrayBoundV2 report produced on the
source file `id3v2enc.c` within the ffmpeg project.
---
clang/test/Analysis/out-of-bounds.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/clang/test/Analysis/out-of-bounds.c
b/clang/test/Analysis/out-of-bounds.c
index 1f771c2b3bd138..9b9cc368af94dc 100644
--- a/clang/test/Analysis/out-of-bounds.c
+++ b/clang/test/Analysis/out-of-bounds.c
@@ -1,4 +1,4 @@
-// RUN: %clang_analyze_cc1 -Wno-array-bounds
-analyzer-checker=core,alpha.security.ArrayBoundV2,debug.ExprInspection -verify
%s
+// RUN: %clang_analyze_cc1 -Wno-array-bounds -Wno-pointer-sign
-analyzer-checker=core,alpha.security.ArrayBoundV2,debug.ExprInspection -verify
%s
void clang_analyzer_eval(int);
@@ -194,3 +194,19 @@ char test_comparison_with_extent_symbol(struct incomplete
*p) {
return ((char *)p)[-1]; // no-warning
}
+
+typedef unsigned char uint8_t;
+static int string_is_ascii(const uint8_t *str) {
+ while (*str && *str < 128) str++;
+ // expected-warning@-1 {{Out of bound access to memory}}
+ return !*str;
+}
+void test_charptr_ucharptr_conversion(void) {
+ const char *s = "";
+ // NOTE: This code passes a `const char *` to a `const unsigned char *`
+ // parameter, which is a bit dodgy (it would be reported by -Wpointer-sign),
+ // but works on platforms where `char` is unsigned.
+ // FIXME: The analyzer is confused by this conversion and cannot deduce that
+ // `*str` is immediately equal to zero within `string_is_ascii()`.
+ string_is_ascii(s);
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [analyzer][NFC] Add ArrayBoundV2 testcase to document bad cast modeling (PR #108799)
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Donát Nagy (NagyDonat)
Changes
Add a FIXME testcase which documents less than ideal behavior of the analyzer
when a `const char *` is converted to `const unsigned char *`. This testcase is
motivated by an ArrayBoundV2 report produced on the source file `id3v2enc.c`
within the ffmpeg project.
---
Full diff: https://github.com/llvm/llvm-project/pull/108799.diff
1 Files Affected:
- (modified) clang/test/Analysis/out-of-bounds.c (+17-1)
``diff
diff --git a/clang/test/Analysis/out-of-bounds.c
b/clang/test/Analysis/out-of-bounds.c
index 1f771c2b3bd138..9b9cc368af94dc 100644
--- a/clang/test/Analysis/out-of-bounds.c
+++ b/clang/test/Analysis/out-of-bounds.c
@@ -1,4 +1,4 @@
-// RUN: %clang_analyze_cc1 -Wno-array-bounds
-analyzer-checker=core,alpha.security.ArrayBoundV2,debug.ExprInspection -verify
%s
+// RUN: %clang_analyze_cc1 -Wno-array-bounds -Wno-pointer-sign
-analyzer-checker=core,alpha.security.ArrayBoundV2,debug.ExprInspection -verify
%s
void clang_analyzer_eval(int);
@@ -194,3 +194,19 @@ char test_comparison_with_extent_symbol(struct incomplete
*p) {
return ((char *)p)[-1]; // no-warning
}
+
+typedef unsigned char uint8_t;
+static int string_is_ascii(const uint8_t *str) {
+ while (*str && *str < 128) str++;
+ // expected-warning@-1 {{Out of bound access to memory}}
+ return !*str;
+}
+void test_charptr_ucharptr_conversion(void) {
+ const char *s = "";
+ // NOTE: This code passes a `const char *` to a `const unsigned char *`
+ // parameter, which is a bit dodgy (it would be reported by -Wpointer-sign),
+ // but works on platforms where `char` is unsigned.
+ // FIXME: The analyzer is confused by this conversion and cannot deduce that
+ // `*str` is immediately equal to zero within `string_is_ascii()`.
+ string_is_ascii(s);
+}
``
https://github.com/llvm/llvm-project/pull/108799
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Instrumentation] Move out to Utils (NFC) (PR #108532)
llvm-ci wrote: LLVM Buildbot has detected a new failure on builder `clang-s390x-linux` running on `systemz-1` while building `clang,llvm` at step 5 "ninja check 1". Full details are available at: https://lab.llvm.org/buildbot/#/builders/42/builds/1089 Here is the relevant piece of the build log for the reference ``` Step 5 (ninja check 1) failure: stage 1 checked (failure) TEST 'LLVMFuzzer-Unittest :: ./Fuzzer-s390x-Test/29/42' FAILED Script(shard): -- GTEST_OUTPUT=json:/home/uweigand/sandbox/buildbot/clang-s390x-linux/stage1/runtimes/runtimes-bins/compiler-rt/lib/fuzzer/tests/./Fuzzer-s390x-Test-LLVMFuzzer-Unittest-2693756-29-42.json GTEST_SHUFFLE=0 GTEST_TOTAL_SHARDS=42 GTEST_SHARD_INDEX=29 /home/uweigand/sandbox/buildbot/clang-s390x-linux/stage1/runtimes/runtimes-bins/compiler-rt/lib/fuzzer/tests/./Fuzzer-s390x-Test -- Note: This is test shard 30 of 42. [==] Running 1 test from 1 test suite. [--] Global test environment set-up. [--] 1 test from Corpus [ RUN ] Corpus.Distribution -- exit: -11 -- shard JSON output does not exist: /home/uweigand/sandbox/buildbot/clang-s390x-linux/stage1/runtimes/runtimes-bins/compiler-rt/lib/fuzzer/tests/./Fuzzer-s390x-Test-LLVMFuzzer-Unittest-2693756-29-42.json ``` https://github.com/llvm/llvm-project/pull/108532 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [analyzer][NFC] Add ArrayBoundV2 testcase to document bad cast modeling (PR #108799)
NagyDonat wrote: This PR is primarily a "note to self", but it *is* NFC and ready to be merged if we think that it'd be better to keep this reminder within the repository. https://github.com/llvm/llvm-project/pull/108799 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] cf2122c - [Clang][ARM] Make CRC and DSP intrinsics always available. (#107417)
Author: Daniel Kiss
Date: 2024-09-16T09:30:16+02:00
New Revision: cf2122cd0ad44ff578ebae54fe2f417895264587
URL:
https://github.com/llvm/llvm-project/commit/cf2122cd0ad44ff578ebae54fe2f417895264587
DIFF:
https://github.com/llvm/llvm-project/commit/cf2122cd0ad44ff578ebae54fe2f417895264587.diff
LOG: [Clang][ARM] Make CRC and DSP intrinsics always available. (#107417)
Both feature has target feature so can be checked if the usage is valid.
Added:
Modified:
clang/lib/Headers/arm_acle.h
clang/test/CodeGen/arm_acle.c
Removed:
diff --git a/clang/lib/Headers/arm_acle.h b/clang/lib/Headers/arm_acle.h
index 1518b0c4c8428f..b1dc90f84ad36f 100644
--- a/clang/lib/Headers/arm_acle.h
+++ b/clang/lib/Headers/arm_acle.h
@@ -264,28 +264,28 @@ __rbitl(unsigned long __t) {
}
/* 8.3 16-bit multiplications */
-#if defined(__ARM_FEATURE_DSP) && __ARM_FEATURE_DSP
-static __inline__ int32_t __attribute__((__always_inline__,__nodebug__))
+#if defined(__ARM_32BIT_STATE) && __ARM_32BIT_STATE
+static __inline__ int32_t __attribute__((__always_inline__,__nodebug__,
target("dsp")))
__smulbb(int32_t __a, int32_t __b) {
return __builtin_arm_smulbb(__a, __b);
}
-static __inline__ int32_t __attribute__((__always_inline__,__nodebug__))
+static __inline__ int32_t __attribute__((__always_inline__,__nodebug__,
target("dsp")))
__smulbt(int32_t __a, int32_t __b) {
return __builtin_arm_smulbt(__a, __b);
}
-static __inline__ int32_t __attribute__((__always_inline__,__nodebug__))
+static __inline__ int32_t __attribute__((__always_inline__,__nodebug__,
target("dsp")))
__smultb(int32_t __a, int32_t __b) {
return __builtin_arm_smultb(__a, __b);
}
-static __inline__ int32_t __attribute__((__always_inline__,__nodebug__))
+static __inline__ int32_t __attribute__((__always_inline__,__nodebug__,
target("dsp")))
__smultt(int32_t __a, int32_t __b) {
return __builtin_arm_smultt(__a, __b);
}
-static __inline__ int32_t __attribute__((__always_inline__,__nodebug__))
+static __inline__ int32_t __attribute__((__always_inline__,__nodebug__,
target("dsp")))
__smulwb(int32_t __a, int32_t __b) {
return __builtin_arm_smulwb(__a, __b);
}
-static __inline__ int32_t __attribute__((__always_inline__,__nodebug__))
+static __inline__ int32_t __attribute__((__always_inline__,__nodebug__,
target("dsp")))
__smulwt(int32_t __a, int32_t __b) {
return __builtin_arm_smulwt(__a, __b);
}
@@ -304,46 +304,46 @@ __smulwt(int32_t __a, int32_t __b) {
#endif
/* 8.4.2 Saturating addition and subtraction intrinsics */
-#if defined(__ARM_FEATURE_DSP) && __ARM_FEATURE_DSP
-static __inline__ int32_t __attribute__((__always_inline__, __nodebug__))
+#if defined(__ARM_32BIT_STATE) && __ARM_32BIT_STATE
+static __inline__ int32_t __attribute__((__always_inline__, __nodebug__,
target("dsp")))
__qadd(int32_t __t, int32_t __v) {
return __builtin_arm_qadd(__t, __v);
}
-static __inline__ int32_t __attribute__((__always_inline__, __nodebug__))
+static __inline__ int32_t __attribute__((__always_inline__, __nodebug__,
target("dsp")))
__qsub(int32_t __t, int32_t __v) {
return __builtin_arm_qsub(__t, __v);
}
-static __inline__ int32_t __attribute__((__always_inline__, __nodebug__))
+static __inline__ int32_t __attribute__((__always_inline__, __nodebug__,
target("dsp")))
__qdbl(int32_t __t) {
return __builtin_arm_qadd(__t, __t);
}
#endif
/* 8.4.3 Accumulating multiplications */
-#if defined(__ARM_FEATURE_DSP) && __ARM_FEATURE_DSP
-static __inline__ int32_t __attribute__((__always_inline__, __nodebug__))
+#if defined(__ARM_32BIT_STATE) && __ARM_32BIT_STATE
+static __inline__ int32_t __attribute__((__always_inline__, __nodebug__,
target("dsp")))
__smlabb(int32_t __a, int32_t __b, int32_t __c) {
return __builtin_arm_smlabb(__a, __b, __c);
}
-static __inline__ int32_t __attribute__((__always_inline__, __nodebug__))
+static __inline__ int32_t __attribute__((__always_inline__, __nodebug__,
target("dsp")))
__smlabt(int32_t __a, int32_t __b, int32_t __c) {
return __builtin_arm_smlabt(__a, __b, __c);
}
-static __inline__ int32_t __attribute__((__always_inline__, __nodebug__))
+static __inline__ int32_t __attribute__((__always_inline__, __nodebug__,
target("dsp")))
__smlatb(int32_t __a, int32_t __b, int32_t __c) {
return __builtin_arm_smlatb(__a, __b, __c);
}
-static __inline__ int32_t __attribute__((__always_inline__, __nodebug__))
+static __inline__ int32_t __attribute__((__always_inline__, __nodebug__,
target("dsp")))
__smlatt(int32_t __a, int32_t __b, int32_t __c) {
return __builtin_arm_smlatt(__a, __b, __c);
}
-static __inline__ int32_t __attribute__((__always_inline__, __nodebug__))
+static __inline__ int32_t __attribute__((__always_inline__, __nodebug__,
target("dsp")))
__smlawb(int32_t __a, int32_t __b, int32_t __c) {
return __builtin_arm_smlawb(__a, __b, __c);
}
-static __inline__ int32_t __attribute__(
[clang] [Clang][ARM] Make CRC and DSP intrinsics always available. (PR #107417)
https://github.com/DanielKristofKiss closed https://github.com/llvm/llvm-project/pull/107417 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Format] Dont treat LBrace after extends/implements as initializer list (PR #108524)
https://github.com/kadircet updated
https://github.com/llvm/llvm-project/pull/108524
From e63f2acd673183d15420b41ebe50a1c061de0905 Mon Sep 17 00:00:00 2001
From: Kadir Cetinkaya
Date: Fri, 13 Sep 2024 11:31:43 +0200
Subject: [PATCH] [Format] Dont treat LBrace after extends/implements as
initializer list
This extends the fix in https://github.com/llvm/llvm-project/pull/106242
for other derived class types.
---
clang/lib/Format/UnwrappedLineParser.cpp | 2 +-
clang/unittests/Format/FormatTestJS.cpp | 7 ++-
clang/unittests/Format/TokenAnnotatorTest.cpp | 8
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/clang/lib/Format/UnwrappedLineParser.cpp
b/clang/lib/Format/UnwrappedLineParser.cpp
index 1727ed93822b1b..40f77266fabdca 100644
--- a/clang/lib/Format/UnwrappedLineParser.cpp
+++ b/clang/lib/Format/UnwrappedLineParser.cpp
@@ -4042,7 +4042,7 @@ void UnwrappedLineParser::parseRecord(bool ParseAsExpr) {
}
auto IsListInitialization = [&] {
-if (!ClassName || IsDerived)
+if (!ClassName || IsDerived || JSPastExtendsOrImplements)
return false;
assert(FormatTok->is(tok::l_brace));
const auto *Prev = FormatTok->getPreviousNonComment();
diff --git a/clang/unittests/Format/FormatTestJS.cpp
b/clang/unittests/Format/FormatTestJS.cpp
index c25228a69a748f..57c021c76867f7 100644
--- a/clang/unittests/Format/FormatTestJS.cpp
+++ b/clang/unittests/Format/FormatTestJS.cpp
@@ -579,12 +579,17 @@ TEST_F(FormatTestJS, GoogScopes) {
"});");
}
-TEST_F(FormatTestJS, GoogAnonymousClass) {
+TEST_F(FormatTestJS, ClassExtends) {
verifyFormat("a = class extends goog.structs.a {\n"
" a() {\n"
"return 0;\n"
" }\n"
"};");
+ verifyFormat("a = class Foo extends goog.structs.a {\n"
+ " a() {\n"
+ "return 0;\n"
+ " }\n"
+ "};");
}
TEST_F(FormatTestJS, IIFEs) {
diff --git a/clang/unittests/Format/TokenAnnotatorTest.cpp
b/clang/unittests/Format/TokenAnnotatorTest.cpp
index 5c28e3a4ea5a1f..baa5ab0ac5e456 100644
--- a/clang/unittests/Format/TokenAnnotatorTest.cpp
+++ b/clang/unittests/Format/TokenAnnotatorTest.cpp
@@ -3277,6 +3277,14 @@ TEST_F(TokenAnnotatorTest, BraceKind) {
EXPECT_TOKEN(Tokens[8], tok::r_brace, TT_ClassRBrace);
EXPECT_BRACE_KIND(Tokens[8], BK_Block);
+ Tokens = annotate("a = class Foo extends goog.a {};",
+getGoogleStyle(FormatStyle::LK_JavaScript));
+ ASSERT_EQ(Tokens.size(), 12u) << Tokens;
+ EXPECT_TOKEN(Tokens[8], tok::l_brace, TT_ClassLBrace);
+ EXPECT_BRACE_KIND(Tokens[8], BK_Block);
+ EXPECT_TOKEN(Tokens[9], tok::r_brace, TT_ClassRBrace);
+ EXPECT_BRACE_KIND(Tokens[9], BK_Block);
+
Tokens = annotate("#define FOO(X) \\\n"
" struct X##_tag_ {};");
ASSERT_EQ(Tokens.size(), 14u) << Tokens;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Format] Dont treat LBrace after extends/implements as initializer list (PR #108524)
kadircet wrote: added, ptal https://github.com/llvm/llvm-project/pull/108524 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Propagate elide safe context through [[clang::coro_must_await]] (PR #108474)
@@ -880,14 +898,12 @@ ExprResult Sema::BuildUnresolvedCoawaitExpr(SourceLocation Loc, Expr *Operand, } auto *RD = Promise->getType()->getAsCXXRecordDecl(); - bool AwaitElidable = - isCoroAwaitElidableCall(Operand) && - isAttributedCoroAwaitElidable( - getCurFunctionDecl(/*AllowLambda=*/true)->getReturnType()); - - if (AwaitElidable) -if (auto *Call = dyn_cast(Operand->IgnoreImplicit())) - Call->setCoroElideSafe(); + + bool CurFnAwaitElidable = isAttributedCoroAwaitElidable( + getCurFunctionDecl(/*AllowLambda=*/true)->getReturnType()); vogelsgesang wrote: ah, I see. So after this patch, we could actually check `await_transform` and also `operator co_await` and thereby get rid of the `CurFnAwaitElidable` check? Such that a `ElideableTask` coawaited within a NonElidableTask (as discussed in the other thread) would become elideable? https://github.com/llvm/llvm-project/pull/108474 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Propagate elide safe context through [[clang::coro_must_await]] (PR #108474)
@@ -8261,12 +8261,19 @@ def CoroAwaitElidableDoc : Documentation {
The ``[[clang::coro_await_elidable]]`` is a class attribute which can be
applied
to a coroutine return type.
-When a coroutine function that returns such a type calls another coroutine
function,
-the compiler performs heap allocation elision when the call to the coroutine
function
-is immediately co_awaited as a prvalue. In this case, the coroutine frame for
the
-callee will be a local variable within the enclosing braces in the caller's
stack
-frame. And the local variable, like other variables in coroutines, may be
collected
-into the coroutine frame, which may be allocated on the heap.
+When a coroutine function returns such a type, a direct call expression therein
+that returns a prvalue of a type attributed ``[[clang::coro_await_elidable]]``
+is said to be under a safe elide context if one of the following is true:
vogelsgesang wrote:
Ah, right. I misread the code.
In general: Is checking if the callee coroutine is annotated actually
necessary? To my understanding from the other thread, so far it was necessary
because of `await_transform` and `operator co_await`. After we make this
checking more fine-granular, are there any other reasons why we would still
need to check if the callee coroutine is annotated?
https://github.com/llvm/llvm-project/pull/108474
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [lld] [llvm] [mlir] [IR] Introduce `T` to `DataLayout` to represent flat address space if a target supports it (PR #108786)
@@ -3050,6 +3050,19 @@ as follows: address space 0, this property only affects the default value to be used when creating globals without additional contextual information (e.g. in LLVM passes). +``T`` +Specifies the address space for a target's 'flat' address space. Note this +is not necessarily the same as addrspace 0, which LLVM sometimes refers to +as the generic address space. The flat address space is a generic address +space that can be used access multiple segments of memory with different +address spaces. Access of a memory location through a pointer with this +address space is expected to be legal but slower compared to the same memory +location accessed through a pointer with a different address space. This is +for targets with different pointer representations which can be converted +with the addrspacecast instruction. If a pointer is converted to this +address space, optimizations should attempt to replace the access with the +source address space. The absence of this specification indicates the target +does not have such a flat address space to optimize away. nikic wrote: >From this description, I don't really understand what flat address space means >in terms of operational semantics. To put it differently: If you had to >implement support for the flat address space concept in alive2, what would you >do? Some additional questions: Can there be more than one flat address space? If you specify a flat address space, does that mean that all other address spaces are not flat, and thus cannot alias with other address spaces? (If I understand the concept correctly at all.) https://github.com/llvm/llvm-project/pull/108786 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][ARM] Make CRC and DSP intrinsics always available. (PR #107417)
llvm-ci wrote: LLVM Buildbot has detected a new failure on builder `openmp-offload-libc-amdgpu-runtime` running on `omp-vega20-1` while building `clang` at step 10 "Add check check-offload". Full details are available at: https://lab.llvm.org/buildbot/#/builders/73/builds/5567 Here is the relevant piece of the build log for the reference ``` Step 10 (Add check check-offload) failure: test (failure) TEST 'libomptarget :: amdgcn-amd-amdhsa :: sanitizer/kernel_crash_async.c' FAILED Exit Code: 1 Command Output (stdout): -- # RUN: at line 2 /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.build/./bin/clang -fopenmp-I /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.src/offload/test -I /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/openmp/runtime/src -L /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/offload -L /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.build/./lib -L /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/openmp/runtime/src -nogpulib -Wl,-rpath,/home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/offload -Wl,-rpath,/home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/openmp/runtime/src -Wl,-rpath,/home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.build/./lib -fopenmp-targets=amdgcn-amd-amdhsa -O3 /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.src/offload/test/sanitizer/kernel_crash_async.c -o /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/offload/test/amdgcn-amd-amdhsa/sanitizer/Output/kernel_crash_async.c.tmp /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.build/./lib/libomptarget.devicertl.a # executed command: /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.build/./bin/clang -fopenmp -I /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.src/offload/test -I /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/openmp/runtime/src -L /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/offload -L /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.build/./lib -L /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/openmp/runtime/src -nogpulib -Wl,-rpath,/home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/offload -Wl,-rpath,/home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/openmp/runtime/src -Wl,-rpath,/home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.build/./lib -fopenmp-targets=amdgcn-amd-amdhsa -O3 /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.src/offload/test/sanitizer/kernel_crash_async.c -o /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/offload/test/amdgcn-amd-amdhsa/sanitizer/Output/kernel_crash_async.c.tmp /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.build/./lib/libomptarget.devicertl.a # RUN: at line 3 /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.build/./bin/not --crash env -u LLVM_DISABLE_SYMBOLIZATION OFFLOAD_TRACK_NUM_KERNEL_LAUNCH_TRACES=1 /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/offload/test/amdgcn-amd-amdhsa/sanitizer/Output/kernel_crash_async.c.tmp 2>&1 | /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.build/./bin/FileCheck /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.src/offload/test/sanitizer/kernel_crash_async.c --check-prefixes=TRACE # executed command: /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.build/./bin/not --crash env -u LLVM_DISABLE_SYMBOLIZATION OFFLOAD_TRACK_NUM_KERNEL_LAUNCH_TRACES=1 /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/offload/test/amdgcn-amd-amdhsa/sanitizer/Output/kernel_crash_async.c.tmp # executed command: /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.build/./bin/FileCheck /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.src/offload/test/sanitizer/kernel_crash_async.c --check-prefixes=TRACE # RUN: at line 4 /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.build/./bin/not --crash /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/offload/test/amdgcn-amd-amdhsa/sanitizer/Output/kernel_crash_async.c.tmp 2>&1 | /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.build/./bin/FileCheck /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.src/offload/test/sanitizer/kernel_crash_async.c --check-prefixes=CHECK # executed command: /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/l
[clang] 6d3f6c2 - [RecursiveASTVisitor] Do not inline TraverseStmt (NFC) (#107601)
Author: Nikita Popov
Date: 2024-09-16T09:49:21+02:00
New Revision: 6d3f6c2170dd60e86743c205e33ead2f455656b4
URL:
https://github.com/llvm/llvm-project/commit/6d3f6c2170dd60e86743c205e33ead2f455656b4
DIFF:
https://github.com/llvm/llvm-project/commit/6d3f6c2170dd60e86743c205e33ead2f455656b4.diff
LOG: [RecursiveASTVisitor] Do not inline TraverseStmt (NFC) (#107601)
As things are now, this reduces size of clang bootstrapped with ThinLTO
by 0.3% and reduces thin link time by 0.3%. More importantly, it avoids
a large regression once https://github.com/llvm/llvm-project/pull/107114
is merged. Without this change, there would be a 0.4% regression in code
size and 4% (!) regression in thin link time. There is no impact on
run-time performance.
Added:
Modified:
clang/include/clang/AST/RecursiveASTVisitor.h
Removed:
diff --git a/clang/include/clang/AST/RecursiveASTVisitor.h
b/clang/include/clang/AST/RecursiveASTVisitor.h
index 3389670a2ab9d9..cd9947f7ab9805 100644
--- a/clang/include/clang/AST/RecursiveASTVisitor.h
+++ b/clang/include/clang/AST/RecursiveASTVisitor.h
@@ -652,9 +652,11 @@ bool RecursiveASTVisitor::PostVisitStmt(Stmt *S) {
#undef DISPATCH_STMT
+// Inlining this method can lead to large code size and compile-time increases
+// without any benefit to runtime performance.
template
-bool RecursiveASTVisitor::TraverseStmt(Stmt *S,
-DataRecursionQueue *Queue) {
+LLVM_ATTRIBUTE_NOINLINE bool
+RecursiveASTVisitor::TraverseStmt(Stmt *S, DataRecursionQueue *Queue)
{
if (!S)
return true;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [RecursiveASTVisitor] Do not inline TraverseStmt (NFC) (PR #107601)
https://github.com/nikic closed https://github.com/llvm/llvm-project/pull/107601 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-format] Fix a bug in annotating angles containing FatArrow (PR #108671)
@@ -243,14 +244,16 @@ class AnnotatingParser {
// operator that was misinterpreted because we are parsing template
// parameters.
// FIXME: This is getting out of hand, write a decent parser.
- if (InExpr && !Line.startsWith(tok::kw_template) &&
+ if (InExpr && !SeenFatArrow && !Line.startsWith(tok::kw_template) &&
Prev.is(TT_BinaryOperator)) {
const auto Precedence = Prev.getPrecedence();
if (Precedence > prec::Conditional && Precedence < prec::Relational)
return false;
}
if (Prev.isOneOf(tok::question, tok::colon) && !Style.isProto())
SeenTernaryOperator = true;
+ else if (Prev.is(TT_FatArrow))
kadircet wrote:
i am not sure if the regression is specific to fat-arrow here (sorry for not
putting much effort into the reproducer). the original change seem to changed
behavior for handling of any bitwise operators. so I think something like:
```cpp
auto foo = new Bar();
```
would also be formatted differently
https://github.com/llvm/llvm-project/pull/108671
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-format] Fix a bug in annotating angles containing FatArrow (PR #108671)
https://github.com/kadircet requested changes to this pull request. https://github.com/llvm/llvm-project/pull/108671 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Format] Avoid repeated hash lookups (NFC) (PR #108794)
https://github.com/nikic approved this pull request. https://github.com/llvm/llvm-project/pull/108794 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [llvm] [X86] AMD Zen 5 Initial enablement (PR #107964)
tru wrote: Create a branch from `release/19.x` in your own fork, then cherry-pick over the changes from `main`, edit them to match the things we talked about above (and fix any merge problems). Then submit a PR that wants to merge `yourbranch` into `release/19.x`. And check the checkbox `maintainers can edit this branch` and it will help my integration! https://github.com/llvm/llvm-project/pull/107964 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Instrumentation] Move out to Utils (NFC) (PR #108532)
llvm-ci wrote: LLVM Buildbot has detected a new failure on builder `lld-x86_64-win` running on `as-worker-93` while building `clang,llvm` at step 7 "test-build-unified-tree-check-all". Full details are available at: https://lab.llvm.org/buildbot/#/builders/146/builds/1161 Here is the relevant piece of the build log for the reference ``` Step 7 (test-build-unified-tree-check-all) failure: test (failure) TEST 'LLVM-Unit :: Support/./SupportTests.exe/36/87' FAILED Script(shard): -- GTEST_OUTPUT=json:C:\a\lld-x86_64-win\build\unittests\Support\.\SupportTests.exe-LLVM-Unit-6048-36-87.json GTEST_SHUFFLE=0 GTEST_TOTAL_SHARDS=87 GTEST_SHARD_INDEX=36 C:\a\lld-x86_64-win\build\unittests\Support\.\SupportTests.exe -- Script: -- C:\a\lld-x86_64-win\build\unittests\Support\.\SupportTests.exe --gtest_filter=ProgramEnvTest.CreateProcessLongPath -- C:\a\lld-x86_64-win\llvm-project\llvm\unittests\Support\ProgramTest.cpp(160): error: Expected equality of these values: 0 RC Which is: -2 C:\a\lld-x86_64-win\llvm-project\llvm\unittests\Support\ProgramTest.cpp(163): error: fs::remove(Twine(LongPath)): did not return errc::success. error number: 13 error message: permission denied C:\a\lld-x86_64-win\llvm-project\llvm\unittests\Support\ProgramTest.cpp:160 Expected equality of these values: 0 RC Which is: -2 C:\a\lld-x86_64-win\llvm-project\llvm\unittests\Support\ProgramTest.cpp:163 fs::remove(Twine(LongPath)): did not return errc::success. error number: 13 error message: permission denied ``` https://github.com/llvm/llvm-project/pull/108532 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [llvm] [X86] AMD Zen 5 Initial enablement (PR #108801)
https://github.com/ganeshgit created
https://github.com/llvm/llvm-project/pull/108801
This patch enables the basic skeleton enablement of AMD next gen zen5 CPUs.
>From 688eeb285363bc2395aaac5fc2634f064c66a5b9 Mon Sep 17 00:00:00 2001
From: Ganesh Gopalasubramanian
Date: Mon, 16 Sep 2024 08:09:24 +
Subject: [PATCH] [X86] AMD Zen 5 Initial enablement
---
clang/lib/Basic/Targets/X86.cpp | 4 +
clang/test/CodeGen/target-builtin-noerror.c | 1 +
clang/test/Driver/x86-march.c | 4 +
clang/test/Frontend/x86-target-cpu.c | 1 +
clang/test/Misc/target-invalid-cpu-note/x86.c | 4 +
.../Preprocessor/predefined-arch-macros.c | 142 ++
compiler-rt/lib/builtins/cpu_model/x86.c | 20 +++
.../llvm/TargetParser/X86TargetParser.def | 3 +
.../llvm/TargetParser/X86TargetParser.h | 1 +
llvm/lib/Target/X86/X86.td| 15 ++
llvm/lib/Target/X86/X86PfmCounters.td | 1 +
llvm/lib/TargetParser/Host.cpp| 19 +++
llvm/lib/TargetParser/X86TargetParser.cpp | 5 +
.../CodeGen/X86/bypass-slow-division-64.ll| 1 +
llvm/test/CodeGen/X86/cmp16.ll| 1 +
llvm/test/CodeGen/X86/cpus-amd.ll | 1 +
llvm/test/CodeGen/X86/rdpru.ll| 1 +
llvm/test/CodeGen/X86/shuffle-as-shifts.ll| 1 +
llvm/test/CodeGen/X86/slow-unaligned-mem.ll | 1 +
llvm/test/CodeGen/X86/sqrt-fastmath-tune.ll | 1 +
.../X86/tuning-shuffle-permilpd-avx512.ll | 1 +
.../X86/tuning-shuffle-permilps-avx512.ll | 1 +
.../X86/tuning-shuffle-unpckpd-avx512.ll | 1 +
.../X86/tuning-shuffle-unpckps-avx512.ll | 1 +
.../X86/vector-shuffle-fast-per-lane.ll | 1 +
llvm/test/CodeGen/X86/vpdpwssd.ll | 1 +
.../CodeGen/X86/x86-64-double-shifts-var.ll | 1 +
llvm/test/MC/X86/x86_long_nop.s | 2 +
.../Transforms/LoopUnroll/X86/call-remark.ll | 1 +
.../Transforms/SLPVectorizer/X86/pr63668.ll | 1 +
30 files changed, 238 insertions(+)
diff --git a/clang/lib/Basic/Targets/X86.cpp b/clang/lib/Basic/Targets/X86.cpp
index 62c382b67ad14a..5448bd841959f4 100644
--- a/clang/lib/Basic/Targets/X86.cpp
+++ b/clang/lib/Basic/Targets/X86.cpp
@@ -728,6 +728,9 @@ void X86TargetInfo::getTargetDefines(const LangOptions
&Opts,
case CK_ZNVER4:
defineCPUMacros(Builder, "znver4");
break;
+ case CK_ZNVER5:
+defineCPUMacros(Builder, "znver5");
+break;
case CK_Geode:
defineCPUMacros(Builder, "geode");
break;
@@ -1626,6 +1629,7 @@ std::optional
X86TargetInfo::getCPUCacheLineSize() const {
case CK_ZNVER2:
case CK_ZNVER3:
case CK_ZNVER4:
+case CK_ZNVER5:
// Deprecated
case CK_x86_64:
case CK_x86_64_v2:
diff --git a/clang/test/CodeGen/target-builtin-noerror.c
b/clang/test/CodeGen/target-builtin-noerror.c
index 14024e3953182c..2a05074d7c2b68 100644
--- a/clang/test/CodeGen/target-builtin-noerror.c
+++ b/clang/test/CodeGen/target-builtin-noerror.c
@@ -207,4 +207,5 @@ void verifycpustrings(void) {
(void)__builtin_cpu_is("znver2");
(void)__builtin_cpu_is("znver3");
(void)__builtin_cpu_is("znver4");
+ (void)__builtin_cpu_is("znver5");
}
diff --git a/clang/test/Driver/x86-march.c b/clang/test/Driver/x86-march.c
index cc993b53937c17..3bc2a82ae778d6 100644
--- a/clang/test/Driver/x86-march.c
+++ b/clang/test/Driver/x86-march.c
@@ -242,6 +242,10 @@
// RUN: %clang -target x86_64-unknown-unknown -c -### %s -march=znver4 2>&1 \
// RUN: | FileCheck %s -check-prefix=znver4
// znver4: "-target-cpu" "znver4"
+//
+// RUN: %clang -target x86_64-unknown-unknown -c -### %s -march=znver5 2>&1 \
+// RUN: | FileCheck %s -check-prefix=znver5
+// znver5: "-target-cpu" "znver5"
// RUN: %clang -target x86_64 -c -### %s -march=x86-64 2>&1 | FileCheck %s
--check-prefix=x86-64
// x86-64: "-target-cpu" "x86-64"
diff --git a/clang/test/Frontend/x86-target-cpu.c
b/clang/test/Frontend/x86-target-cpu.c
index 6c8502ac2c21ee..f2885a040c3701 100644
--- a/clang/test/Frontend/x86-target-cpu.c
+++ b/clang/test/Frontend/x86-target-cpu.c
@@ -38,5 +38,6 @@
// RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu znver2 -verify %s
// RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu znver3 -verify %s
// RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu znver4 -verify %s
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu znver5 -verify %s
//
// expected-no-diagnostics
diff --git a/clang/test/Misc/target-invalid-cpu-note/x86.c
b/clang/test/Misc/target-invalid-cpu-note/x86.c
index 607192a5409ba8..7879676040af46 100644
--- a/clang/test/Misc/target-invalid-cpu-note/x86.c
+++ b/clang/test/Misc/target-invalid-cpu-note/x86.c
@@ -99,6 +99,7 @@
// X86-SAME: {{^}}, znver2
// X86-SAME: {{^}}, znver3
// X86-SAME: {{^}}, znver4
+// X86-SAME: {{^}}, znver5
// X86-SAME: {{^}}, x86-64
// X86-SAME: {{^}}, x86-64-v2
// X86-SAME: {{^}}, x86-64-v3
@@ -
[clang] [compiler-rt] [llvm] [X86] AMD Zen 5 Initial enablement (PR #108801)
llvmbot wrote:
@llvm/pr-subscribers-clang-driver
Author: Ganesh (ganeshgit)
Changes
This patch enables the basic skeleton enablement of AMD next gen zen5 CPUs.
---
Patch is 31.54 KiB, truncated to 20.00 KiB below, full version:
https://github.com/llvm/llvm-project/pull/108801.diff
30 Files Affected:
- (modified) clang/lib/Basic/Targets/X86.cpp (+4)
- (modified) clang/test/CodeGen/target-builtin-noerror.c (+1)
- (modified) clang/test/Driver/x86-march.c (+4)
- (modified) clang/test/Frontend/x86-target-cpu.c (+1)
- (modified) clang/test/Misc/target-invalid-cpu-note/x86.c (+4)
- (modified) clang/test/Preprocessor/predefined-arch-macros.c (+142)
- (modified) compiler-rt/lib/builtins/cpu_model/x86.c (+20)
- (modified) llvm/include/llvm/TargetParser/X86TargetParser.def (+3)
- (modified) llvm/include/llvm/TargetParser/X86TargetParser.h (+1)
- (modified) llvm/lib/Target/X86/X86.td (+15)
- (modified) llvm/lib/Target/X86/X86PfmCounters.td (+1)
- (modified) llvm/lib/TargetParser/Host.cpp (+19)
- (modified) llvm/lib/TargetParser/X86TargetParser.cpp (+5)
- (modified) llvm/test/CodeGen/X86/bypass-slow-division-64.ll (+1)
- (modified) llvm/test/CodeGen/X86/cmp16.ll (+1)
- (modified) llvm/test/CodeGen/X86/cpus-amd.ll (+1)
- (modified) llvm/test/CodeGen/X86/rdpru.ll (+1)
- (modified) llvm/test/CodeGen/X86/shuffle-as-shifts.ll (+1)
- (modified) llvm/test/CodeGen/X86/slow-unaligned-mem.ll (+1)
- (modified) llvm/test/CodeGen/X86/sqrt-fastmath-tune.ll (+1)
- (modified) llvm/test/CodeGen/X86/tuning-shuffle-permilpd-avx512.ll (+1)
- (modified) llvm/test/CodeGen/X86/tuning-shuffle-permilps-avx512.ll (+1)
- (modified) llvm/test/CodeGen/X86/tuning-shuffle-unpckpd-avx512.ll (+1)
- (modified) llvm/test/CodeGen/X86/tuning-shuffle-unpckps-avx512.ll (+1)
- (modified) llvm/test/CodeGen/X86/vector-shuffle-fast-per-lane.ll (+1)
- (modified) llvm/test/CodeGen/X86/vpdpwssd.ll (+1)
- (modified) llvm/test/CodeGen/X86/x86-64-double-shifts-var.ll (+1)
- (modified) llvm/test/MC/X86/x86_long_nop.s (+2)
- (modified) llvm/test/Transforms/LoopUnroll/X86/call-remark.ll (+1)
- (modified) llvm/test/Transforms/SLPVectorizer/X86/pr63668.ll (+1)
``diff
diff --git a/clang/lib/Basic/Targets/X86.cpp b/clang/lib/Basic/Targets/X86.cpp
index 62c382b67ad14a..5448bd841959f4 100644
--- a/clang/lib/Basic/Targets/X86.cpp
+++ b/clang/lib/Basic/Targets/X86.cpp
@@ -728,6 +728,9 @@ void X86TargetInfo::getTargetDefines(const LangOptions
&Opts,
case CK_ZNVER4:
defineCPUMacros(Builder, "znver4");
break;
+ case CK_ZNVER5:
+defineCPUMacros(Builder, "znver5");
+break;
case CK_Geode:
defineCPUMacros(Builder, "geode");
break;
@@ -1626,6 +1629,7 @@ std::optional
X86TargetInfo::getCPUCacheLineSize() const {
case CK_ZNVER2:
case CK_ZNVER3:
case CK_ZNVER4:
+case CK_ZNVER5:
// Deprecated
case CK_x86_64:
case CK_x86_64_v2:
diff --git a/clang/test/CodeGen/target-builtin-noerror.c
b/clang/test/CodeGen/target-builtin-noerror.c
index 14024e3953182c..2a05074d7c2b68 100644
--- a/clang/test/CodeGen/target-builtin-noerror.c
+++ b/clang/test/CodeGen/target-builtin-noerror.c
@@ -207,4 +207,5 @@ void verifycpustrings(void) {
(void)__builtin_cpu_is("znver2");
(void)__builtin_cpu_is("znver3");
(void)__builtin_cpu_is("znver4");
+ (void)__builtin_cpu_is("znver5");
}
diff --git a/clang/test/Driver/x86-march.c b/clang/test/Driver/x86-march.c
index cc993b53937c17..3bc2a82ae778d6 100644
--- a/clang/test/Driver/x86-march.c
+++ b/clang/test/Driver/x86-march.c
@@ -242,6 +242,10 @@
// RUN: %clang -target x86_64-unknown-unknown -c -### %s -march=znver4 2>&1 \
// RUN: | FileCheck %s -check-prefix=znver4
// znver4: "-target-cpu" "znver4"
+//
+// RUN: %clang -target x86_64-unknown-unknown -c -### %s -march=znver5 2>&1 \
+// RUN: | FileCheck %s -check-prefix=znver5
+// znver5: "-target-cpu" "znver5"
// RUN: %clang -target x86_64 -c -### %s -march=x86-64 2>&1 | FileCheck %s
--check-prefix=x86-64
// x86-64: "-target-cpu" "x86-64"
diff --git a/clang/test/Frontend/x86-target-cpu.c
b/clang/test/Frontend/x86-target-cpu.c
index 6c8502ac2c21ee..f2885a040c3701 100644
--- a/clang/test/Frontend/x86-target-cpu.c
+++ b/clang/test/Frontend/x86-target-cpu.c
@@ -38,5 +38,6 @@
// RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu znver2 -verify %s
// RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu znver3 -verify %s
// RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu znver4 -verify %s
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu znver5 -verify %s
//
// expected-no-diagnostics
diff --git a/clang/test/Misc/target-invalid-cpu-note/x86.c
b/clang/test/Misc/target-invalid-cpu-note/x86.c
index 607192a5409ba8..7879676040af46 100644
--- a/clang/test/Misc/target-invalid-cpu-note/x86.c
+++ b/clang/test/Misc/target-invalid-cpu-note/x86.c
@@ -99,6 +99,7 @@
// X86-SAME: {{^}}, znver2
// X86-SAME: {{^}}, znver3
// X86-SAME: {{^}}, znver4
+//
[clang] [compiler-rt] [llvm] [X86] AMD Zen 5 Initial enablement (PR #108801)
RKSimon wrote: @ganeshgit @tru This looks to be a PR into main and not release/19.x ? https://github.com/llvm/llvm-project/pull/108801 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [llvm] [X86] AMD Zen 5 Initial enablement (PR #108801)
tru wrote: Yeah it needs to be towards the 19.x release branch as I described in my comment here https://github.com/llvm/llvm-project/pull/107964#issuecomment-2352261158 https://github.com/llvm/llvm-project/pull/108801 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [llvm] [X86] AMD Zen 5 Initial enablement (PR #108801)
ganeshgit wrote: > Yeah it needs to be towards the 19.x release branch as I described in my > comment here [#107964 > (comment)](https://github.com/llvm/llvm-project/pull/107964#issuecomment-2352261158) Ignore this. I need to create a new fork with the target branch. My fork only has "main". I will submit another PR for release 9.x This got committed before I read your comment mentioned above. https://github.com/llvm/llvm-project/pull/108801 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [llvm] [X86] AMD Zen 5 Initial enablement (PR #108801)
https://github.com/ganeshgit closed https://github.com/llvm/llvm-project/pull/108801 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [llvm] [X86] AMD Zen 5 Initial enablement (PR #108801)
ganeshgit wrote: Will create new one for 19.x https://github.com/llvm/llvm-project/pull/108801 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [llvm][Triple] Add `Environment` members and parsing for glibc/musl parity. (PR #107664)
MaskRay wrote: Are these `musl*` environments blessed by upstream musl? @richfelker https://github.com/llvm/llvm-project/pull/107664 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][codegen] Fix possible crash when setting TBAA metadata on FP math libcalls (PR #108575)
mstorsjo wrote: I've bisected breakage, on mingw x86 platforms relating to double vs long double routines, down to this commit. I'll follow up with more details when I manage to pinpoint what changes and where, due to this change. https://github.com/llvm/llvm-project/pull/108575 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Format] Dont treat LBrace after extends/implements as initializer list (PR #108524)
https://github.com/owenca approved this pull request. https://github.com/llvm/llvm-project/pull/108524 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][codegen] Fix possible crash when setting TBAA metadata on FP math libcalls (PR #108575)
MacDue wrote: Thanks for letting me know, feel free to revert this change if it's a non-trivial breakage. https://github.com/llvm/llvm-project/pull/108575 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][driver] Don't warn when -S and -c are used together without -fsyntax-only (PR #104477)
https://github.com/MaskRay requested changes to this pull request. . https://github.com/llvm/llvm-project/pull/104477 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Increase VecLib bitfield size to 4 bits in CodeGenOptions.def #3 (PR #108804)
https://github.com/MainakSil created https://github.com/llvm/llvm-project/pull/108804 Summary: This PR fixes the issue where the VecLib bitfield in CodeGenOptions.def is too small to accommodate the increasing number of vector libraries. Specifically, the bitfield size was previously set to 3, but with the introduction of more vector libraries (currently 9), the bitfield needed to be expanded to avoid potential issues in vectorization. In this PR, I have increased the size of the VecLib bitfield from 3 to 4 to account for the additional libraries. This ensures that all 9 vector libraries are correctly encoded and available for use without errors. Changes Made: Modified: Increased the VecLib bitfield size from 3 to 4 in clang/include/clang/Basic/CodeGenOptions.def. Motivation: This change is necessary to ensure that all vector libraries are properly represented and selectable. The current limitation of the VecLib bitfield size was causing some vectorization opportunities to be lost when more than 3 bits were needed to represent the library options. Closes: Fixes https://github.com/llvm/llvm-project/issues/108704 >From 43e6c22f25f419b64678374dd247eaf8bc28fa57 Mon Sep 17 00:00:00 2001 From: Mainak Sil Date: Mon, 16 Sep 2024 09:50:33 +0530 Subject: [PATCH 1/3] [clang] Increase VecLib bitfield size to 4 bits in CodeGenOptions.def --- clang/include/clang/Basic/CodeGenOptions.def | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/clang/include/clang/Basic/CodeGenOptions.def b/clang/include/clang/Basic/CodeGenOptions.def index b600198998d85b..f2a96324936775 100644 --- a/clang/include/clang/Basic/CodeGenOptions.def +++ b/clang/include/clang/Basic/CodeGenOptions.def @@ -376,7 +376,7 @@ ENUM_CODEGENOPT(Inlining, InliningMethod, 2, NormalInlining) VALUE_CODEGENOPT(InlineMaxStackSize, 32, UINT_MAX) // Vector functions library to use. -ENUM_CODEGENOPT(VecLib, llvm::driver::VectorLibrary, 3, llvm::driver::VectorLibrary::NoLibrary) +ENUM_CODEGENOPT(VecLib, llvm::driver::VectorLibrary, 4, llvm::driver::VectorLibrary::NoLibrary) /// The default TLS model to use. ENUM_CODEGENOPT(DefaultTLSModel, TLSModel, 2, GeneralDynamicTLSModel) >From b30adc9c059d1af9b5874b5c0e258670d3190852 Mon Sep 17 00:00:00 2001 From: Mainak Sil Date: Mon, 16 Sep 2024 14:18:03 +0530 Subject: [PATCH 2/3] Update CodeGenOptions.def --- clang/include/clang/Basic/CodeGenOptions.def | 5 + 1 file changed, 5 insertions(+) diff --git a/clang/include/clang/Basic/CodeGenOptions.def b/clang/include/clang/Basic/CodeGenOptions.def index f2a96324936775..2d5bb84d1cc59c 100644 --- a/clang/include/clang/Basic/CodeGenOptions.def +++ b/clang/include/clang/Basic/CodeGenOptions.def @@ -375,6 +375,11 @@ ENUM_CODEGENOPT(Inlining, InliningMethod, 2, NormalInlining) /// The maximum stack size a function can have to be considered for inlining. VALUE_CODEGENOPT(InlineMaxStackSize, 32, UINT_MAX) +// Ensure the VecLib bitfield has enough space for future vector libraries. +// If new vector libraries are added beyond the current limit of 16, this static assertion will fail. +static_assert(static_cast(llvm::driver::VectorLibrary::NoLibrary) <= 16, + "The VecLib bitfield in CodeGenOptions needs to be expanded to support more vector libraries."); + // Vector functions library to use. ENUM_CODEGENOPT(VecLib, llvm::driver::VectorLibrary, 4, llvm::driver::VectorLibrary::NoLibrary) >From d96f69105c5be85acf3614258911fbdf74dbc60f Mon Sep 17 00:00:00 2001 From: Mainak Sil Date: Mon, 16 Sep 2024 14:32:26 +0530 Subject: [PATCH 3/3] Update CodeGenOptions.def ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Increase VecLib bitfield size to 4 bits in CodeGenOptions.def #3 (PR #108804)
llvmbot wrote: @llvm/pr-subscribers-clang Author: Mainak Sil (MainakSil) Changes Summary: This PR fixes the issue where the VecLib bitfield in CodeGenOptions.def is too small to accommodate the increasing number of vector libraries. Specifically, the bitfield size was previously set to 3, but with the introduction of more vector libraries (currently 9), the bitfield needed to be expanded to avoid potential issues in vectorization. In this PR, I have increased the size of the VecLib bitfield from 3 to 4 to account for the additional libraries. This ensures that all 9 vector libraries are correctly encoded and available for use without errors. Changes Made: Modified: Increased the VecLib bitfield size from 3 to 4 in clang/include/clang/Basic/CodeGenOptions.def. Motivation: This change is necessary to ensure that all vector libraries are properly represented and selectable. The current limitation of the VecLib bitfield size was causing some vectorization opportunities to be lost when more than 3 bits were needed to represent the library options. Closes: Fixes https://github.com/llvm/llvm-project/issues/108704 --- Full diff: https://github.com/llvm/llvm-project/pull/108804.diff 1 Files Affected: - (modified) clang/include/clang/Basic/CodeGenOptions.def (+6-1) ``diff diff --git a/clang/include/clang/Basic/CodeGenOptions.def b/clang/include/clang/Basic/CodeGenOptions.def index b600198998d85b..2d5bb84d1cc59c 100644 --- a/clang/include/clang/Basic/CodeGenOptions.def +++ b/clang/include/clang/Basic/CodeGenOptions.def @@ -375,8 +375,13 @@ ENUM_CODEGENOPT(Inlining, InliningMethod, 2, NormalInlining) /// The maximum stack size a function can have to be considered for inlining. VALUE_CODEGENOPT(InlineMaxStackSize, 32, UINT_MAX) +// Ensure the VecLib bitfield has enough space for future vector libraries. +// If new vector libraries are added beyond the current limit of 16, this static assertion will fail. +static_assert(static_cast(llvm::driver::VectorLibrary::NoLibrary) <= 16, + "The VecLib bitfield in CodeGenOptions needs to be expanded to support more vector libraries."); + // Vector functions library to use. -ENUM_CODEGENOPT(VecLib, llvm::driver::VectorLibrary, 3, llvm::driver::VectorLibrary::NoLibrary) +ENUM_CODEGENOPT(VecLib, llvm::driver::VectorLibrary, 4, llvm::driver::VectorLibrary::NoLibrary) /// The default TLS model to use. ENUM_CODEGENOPT(DefaultTLSModel, TLSModel, 2, GeneralDynamicTLSModel) `` https://github.com/llvm/llvm-project/pull/108804 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][Parser] Accept P2741R3 (static_assert with user-generated message) in C++11 as an extension (PR #102044)
yashssh wrote: Reigniting the discussion around `__cpp_static_assert`'s value set to `202306L` . We are seeing some failures in perennial c++20 tests who assume the value of macro to be `201411L` which is consistent with how GCC defines value of these macros (see https://godbolt.org/z/xE9bWsdKT) >From the discussions earlier I'm getting the impression that this has more to >do with c++ standard not properly defining the values of these macros for >older revisions. What can be the best way forward to fix this? Have it >consistent with GCC? https://github.com/llvm/llvm-project/pull/102044 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] [docs][clang-tidy] Correct StrictMode example in modernize-use-std-print (PR #108805)
https://github.com/MainakSil created
https://github.com/llvm/llvm-project/pull/108805
Updated the example in the `StrictMode` section of the clang-tidy check
`modernize-use-std-print`.
The previous example incorrectly swapped the cast of signed and unsigned
integers. Specifically:
- The signed integer `i` was being cast to `unsigned int`, and
- The unsigned integer `u` was being cast to `int`.
This correction ensures that the behavior of `std::print` with `StrictMode`
enabled matches that of `printf`, by reversing the casts to maintain the
correct signedness.
Issue Refference
It solves #101397
>From 20b262e9954ec1505b1be4ea3cc362b2a9955bb9 Mon Sep 17 00:00:00 2001
From: Mainak Sil
Date: Sun, 15 Sep 2024 22:03:43 +0530
Subject: [PATCH 1/2] [docs][clang-tidy] Correct StrictMode example in
modernize-use-std-print
---
.../docs/clang-tidy/checks/modernize/use-std-print.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/clang-tools-extra/docs/clang-tidy/checks/modernize/use-std-print.rst
b/clang-tools-extra/docs/clang-tidy/checks/modernize/use-std-print.rst
index 59bb722e2c24fc..a825cd7432a57d 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/modernize/use-std-print.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/modernize/use-std-print.rst
@@ -109,7 +109,7 @@ Options
.. code-block:: c++
-std::print("{} {}\n", static_cast(i), static_cast(u));
+std::print("{} {}\n", static_cast(u), static_cast(i));
to ensure that the output will continue to be the unsigned representation
of `-42` and the signed representation of `0x` (often
>From e64700266ecc08b23f88415036c45177a03c40c2 Mon Sep 17 00:00:00 2001
From: Mainak Sil
Date: Mon, 16 Sep 2024 14:41:49 +0530
Subject: [PATCH 2/2] [docs][clang-tidy] Correct StrictMode example in
modernize-use-std-print
Updated the example in the StrictMode section of the clang-tidy check
modernize-use-std-print.
The previous example incorrectly swapped the cast of signed and unsigned
integers. Specifically:
The signed integer i was being cast to unsigned int, and
The unsigned integer u was being cast to int.
This correction ensures that the behavior of std::print with StrictMode enabled
matches that of printf, by reversing the casts to maintain the correct
signedness.
Issue Refference
It solves #llvm#101397
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] [docs][clang-tidy] Correct StrictMode example in modernize-use-std-print (PR #108805)
llvmbot wrote:
@llvm/pr-subscribers-clang-tools-extra
Author: Mainak Sil (MainakSil)
Changes
Updated the example in the `StrictMode` section of the clang-tidy check
`modernize-use-std-print`.
The previous example incorrectly swapped the cast of signed and unsigned
integers. Specifically:
- The signed integer `i` was being cast to `unsigned int`, and
- The unsigned integer `u` was being cast to `int`.
This correction ensures that the behavior of `std::print` with `StrictMode`
enabled matches that of `printf`, by reversing the casts to maintain the
correct signedness.
Issue Refference
It solves #101397
---
Full diff: https://github.com/llvm/llvm-project/pull/108805.diff
1 Files Affected:
- (modified)
clang-tools-extra/docs/clang-tidy/checks/modernize/use-std-print.rst (+1-1)
``diff
diff --git
a/clang-tools-extra/docs/clang-tidy/checks/modernize/use-std-print.rst
b/clang-tools-extra/docs/clang-tidy/checks/modernize/use-std-print.rst
index 59bb722e2c24fc..a825cd7432a57d 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/modernize/use-std-print.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/modernize/use-std-print.rst
@@ -109,7 +109,7 @@ Options
.. code-block:: c++
-std::print("{} {}\n", static_cast(i), static_cast(u));
+std::print("{} {}\n", static_cast(u), static_cast(i));
to ensure that the output will continue to be the unsigned representation
of `-42` and the signed representation of `0x` (often
``
https://github.com/llvm/llvm-project/pull/108805
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] [docs][clang-tidy] Correct StrictMode example in modernize-use-std-print (PR #108805)
llvmbot wrote:
@llvm/pr-subscribers-clang-tidy
Author: Mainak Sil (MainakSil)
Changes
Updated the example in the `StrictMode` section of the clang-tidy check
`modernize-use-std-print`.
The previous example incorrectly swapped the cast of signed and unsigned
integers. Specifically:
- The signed integer `i` was being cast to `unsigned int`, and
- The unsigned integer `u` was being cast to `int`.
This correction ensures that the behavior of `std::print` with `StrictMode`
enabled matches that of `printf`, by reversing the casts to maintain the
correct signedness.
Issue Refference
It solves #101397
---
Full diff: https://github.com/llvm/llvm-project/pull/108805.diff
1 Files Affected:
- (modified)
clang-tools-extra/docs/clang-tidy/checks/modernize/use-std-print.rst (+1-1)
``diff
diff --git
a/clang-tools-extra/docs/clang-tidy/checks/modernize/use-std-print.rst
b/clang-tools-extra/docs/clang-tidy/checks/modernize/use-std-print.rst
index 59bb722e2c24fc..a825cd7432a57d 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/modernize/use-std-print.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/modernize/use-std-print.rst
@@ -109,7 +109,7 @@ Options
.. code-block:: c++
-std::print("{} {}\n", static_cast(i), static_cast(u));
+std::print("{} {}\n", static_cast(u), static_cast(i));
to ensure that the output will continue to be the unsigned representation
of `-42` and the signed representation of `0x` (often
``
https://github.com/llvm/llvm-project/pull/108805
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Increase VecLib bitfield size to 4 bits in CodeGenOptions.def (PR #108804)
https://github.com/MainakSil edited https://github.com/llvm/llvm-project/pull/108804 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AMDGPU] Change CF intrinsics lowering to reconverge on predecessors (PR #108596)
@@ -196,8 +208,10 @@ define amdgpu_kernel void @add_i32_constant(ptr addrspace(1) %out, ptr addrspace ; GFX11W32-NEXT:v_mbcnt_lo_u32_b32 v0, s1, 0 ; GFX11W32-NEXT:; implicit-def: $vgpr1 ; GFX11W32-NEXT:s_delay_alu instid0(VALU_DEP_1) -; GFX11W32-NEXT:v_cmpx_eq_u32_e32 0, v0 -; GFX11W32-NEXT:s_cbranch_execz .LBB0_2 +; GFX11W32-NEXT:v_cmp_eq_u32_e32 vcc_lo, 0, v0 jayfoad wrote: The codegen seems significantly worse for simple conditional branches like this, especially on GFX10.3+ where we try to use v_cmpx. Note that there is special hardware to handle v_cmpx followed by a VALU instruction without the kind of pipeline stall that you would normally get when you write to EXEC. To improve matters a bit, could we aim for codegen like this? ``` v_cmp_eq_u32_e32 vcc_lo, 0, v0 s_cbranch_vccz .LBB0_2 s_mov_b32 exec_lo, vcc_lo ``` This saves one instruction overall and moves the exec modification into the body of the "if". https://github.com/llvm/llvm-project/pull/108596 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][Parser] Accept P2741R3 (static_assert with user-generated message) in C++11 as an extension (PR #102044)
yashssh wrote: https://isocpp.org/files/papers/N4860.pdf according to this, cpp_static_assert should be 201411L for c++20 https://github.com/llvm/llvm-project/pull/102044 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Implement labelled type filtering for overflow/truncation sanitizers w/ SSCLs (PR #107332)
https://github.com/JustinStitt edited https://github.com/llvm/llvm-project/pull/107332 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][bytecode] Fix reinterpret_casts from pointer to non-pointers (PR #108811)
https://github.com/tbaederr created
https://github.com/llvm/llvm-project/pull/108811
We need to be a little more careful here with whether or nor we are able to do
the cast at all or not.
>From 462cd5016c72728ed120773a0da0aab1895649b1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Timm=20B=C3=A4der?=
Date: Sat, 14 Sep 2024 14:57:18 +0200
Subject: [PATCH] [clang][bytecode] Fix reinterpret_casts from pointer to
non-pointers
We need to be a little more careful here with whether or nor we
are able to do the cast at all or not.
---
clang/lib/AST/ByteCode/Compiler.cpp | 38 +
clang/test/AST/ByteCode/invalid.cpp | 3 +++
2 files changed, 36 insertions(+), 5 deletions(-)
diff --git a/clang/lib/AST/ByteCode/Compiler.cpp
b/clang/lib/AST/ByteCode/Compiler.cpp
index 265350e44d95b9..fe9da7801185e3 100644
--- a/clang/lib/AST/ByteCode/Compiler.cpp
+++ b/clang/lib/AST/ByteCode/Compiler.cpp
@@ -2613,18 +2613,46 @@ bool Compiler::VisitCXXReinterpretCastExpr(
const CXXReinterpretCastExpr *E) {
const Expr *SubExpr = E->getSubExpr();
- bool Fatal = false;
std::optional FromT = classify(SubExpr);
std::optional ToT = classify(E);
+
if (!FromT || !ToT)
-Fatal = true;
- else
-Fatal = (ToT != FromT);
+return this->emitInvalidCast(CastKind::Reinterpret, /*Fatal=*/true, E);
+
+ if (FromT == PT_Ptr || ToT == PT_Ptr) {
+// Both types could be PT_Ptr because their expressions are glvalues.
+std::optional PointeeFromT;
+if (SubExpr->getType()->isPointerOrReferenceType())
+ PointeeFromT = classify(SubExpr->getType()->getPointeeType());
+else
+ PointeeFromT = classify(SubExpr->getType());
+
+std::optional PointeeToT;
+if (E->getType()->isPointerOrReferenceType())
+ PointeeToT = classify(E->getType()->getPointeeType());
+else
+ PointeeToT = classify(E->getType());
+
+bool Fatal = true;
+if (PointeeToT && PointeeFromT) {
+ if (isIntegralType(*PointeeFromT) && isIntegralType(*PointeeToT))
+Fatal = false;
+}
+
+if (!this->emitInvalidCast(CastKind::Reinterpret, Fatal, E))
+ return false;
+
+if (E->getCastKind() == CK_LValueBitCast)
+ return this->delegate(SubExpr);
+return this->VisitCastExpr(E);
+ }
+ // Try to actually do the cast.
+ bool Fatal = (ToT != FromT);
if (!this->emitInvalidCast(CastKind::Reinterpret, Fatal, E))
return false;
- return this->delegate(SubExpr);
+ return this->VisitCastExpr(E);
}
template
diff --git a/clang/test/AST/ByteCode/invalid.cpp
b/clang/test/AST/ByteCode/invalid.cpp
index 13ba84bcad1040..2a6c2d13e84673 100644
--- a/clang/test/AST/ByteCode/invalid.cpp
+++ b/clang/test/AST/ByteCode/invalid.cpp
@@ -54,4 +54,7 @@ namespace Casts {
B b;
(void)*reinterpret_cast(&b); // both-error {{indirection not
permitted on operand of type 'void *'}}
}
+
+ /// Just make sure this doesn't crash.
+ float PR9558 = reinterpret_cast("asd");
}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][bytecode] Fix reinterpret_casts from pointer to non-pointers (PR #108811)
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Timm Baeder (tbaederr)
Changes
We need to be a little more careful here with whether or nor we are able to do
the cast at all or not.
---
Full diff: https://github.com/llvm/llvm-project/pull/108811.diff
2 Files Affected:
- (modified) clang/lib/AST/ByteCode/Compiler.cpp (+33-5)
- (modified) clang/test/AST/ByteCode/invalid.cpp (+3)
``diff
diff --git a/clang/lib/AST/ByteCode/Compiler.cpp
b/clang/lib/AST/ByteCode/Compiler.cpp
index 265350e44d95b9..fe9da7801185e3 100644
--- a/clang/lib/AST/ByteCode/Compiler.cpp
+++ b/clang/lib/AST/ByteCode/Compiler.cpp
@@ -2613,18 +2613,46 @@ bool Compiler::VisitCXXReinterpretCastExpr(
const CXXReinterpretCastExpr *E) {
const Expr *SubExpr = E->getSubExpr();
- bool Fatal = false;
std::optional FromT = classify(SubExpr);
std::optional ToT = classify(E);
+
if (!FromT || !ToT)
-Fatal = true;
- else
-Fatal = (ToT != FromT);
+return this->emitInvalidCast(CastKind::Reinterpret, /*Fatal=*/true, E);
+
+ if (FromT == PT_Ptr || ToT == PT_Ptr) {
+// Both types could be PT_Ptr because their expressions are glvalues.
+std::optional PointeeFromT;
+if (SubExpr->getType()->isPointerOrReferenceType())
+ PointeeFromT = classify(SubExpr->getType()->getPointeeType());
+else
+ PointeeFromT = classify(SubExpr->getType());
+
+std::optional PointeeToT;
+if (E->getType()->isPointerOrReferenceType())
+ PointeeToT = classify(E->getType()->getPointeeType());
+else
+ PointeeToT = classify(E->getType());
+
+bool Fatal = true;
+if (PointeeToT && PointeeFromT) {
+ if (isIntegralType(*PointeeFromT) && isIntegralType(*PointeeToT))
+Fatal = false;
+}
+
+if (!this->emitInvalidCast(CastKind::Reinterpret, Fatal, E))
+ return false;
+
+if (E->getCastKind() == CK_LValueBitCast)
+ return this->delegate(SubExpr);
+return this->VisitCastExpr(E);
+ }
+ // Try to actually do the cast.
+ bool Fatal = (ToT != FromT);
if (!this->emitInvalidCast(CastKind::Reinterpret, Fatal, E))
return false;
- return this->delegate(SubExpr);
+ return this->VisitCastExpr(E);
}
template
diff --git a/clang/test/AST/ByteCode/invalid.cpp
b/clang/test/AST/ByteCode/invalid.cpp
index 13ba84bcad1040..2a6c2d13e84673 100644
--- a/clang/test/AST/ByteCode/invalid.cpp
+++ b/clang/test/AST/ByteCode/invalid.cpp
@@ -54,4 +54,7 @@ namespace Casts {
B b;
(void)*reinterpret_cast(&b); // both-error {{indirection not
permitted on operand of type 'void *'}}
}
+
+ /// Just make sure this doesn't crash.
+ float PR9558 = reinterpret_cast("asd");
}
``
https://github.com/llvm/llvm-project/pull/108811
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] dbdf843 - [RISCV] Add Syntacore SCR7 processor definition (#108406)
Author: Anton Sidorenko
Date: 2024-09-16T13:09:37+03:00
New Revision: dbdf84388a825645850a47b035a1f7ab27b789b5
URL:
https://github.com/llvm/llvm-project/commit/dbdf84388a825645850a47b035a1f7ab27b789b5
DIFF:
https://github.com/llvm/llvm-project/commit/dbdf84388a825645850a47b035a1f7ab27b789b5.diff
LOG: [RISCV] Add Syntacore SCR7 processor definition (#108406)
Syntacore SCR7 is a high-performance Linux-capable RISC-V processor
core.
The core has rv64imafdcv_zba_zbb_zbc_zbs_zkn march.
Overview: https://syntacore.com/products/scr7
Scheduling model will be added in a subsequent PR.
-
Co-authored-by: Dmitrii Petrov
Co-authored-by: Anton Afanasyev
Co-authored-by: Elena Lepilkina
Added:
Modified:
clang/test/Driver/riscv-cpus.c
clang/test/Misc/target-invalid-cpu-note/riscv.c
llvm/docs/ReleaseNotes.rst
llvm/lib/Target/RISCV/RISCVProcessors.td
Removed:
diff --git a/clang/test/Driver/riscv-cpus.c b/clang/test/Driver/riscv-cpus.c
index 481eaae9153e86..d36639d16ad4cb 100644
--- a/clang/test/Driver/riscv-cpus.c
+++ b/clang/test/Driver/riscv-cpus.c
@@ -502,3 +502,29 @@
// RUN: %clang --target=riscv64 -### -c %s 2>&1 -mtune=syntacore-scr5-rv64 |
FileCheck -check-prefix=MTUNE-SYNTACORE-SCR5-RV64 %s
// MTUNE-SYNTACORE-SCR5-RV64: "-tune-cpu" "syntacore-scr5-rv64"
+
+// RUN: %clang --target=riscv64 -### -c %s 2>&1 -mcpu=syntacore-scr7 |
FileCheck -check-prefix=MCPU-SYNTACORE-SCR7 %s
+// MCPU-SYNTACORE-SCR7: "-target-cpu" "syntacore-scr7"
+// MCPU-SYNTACORE-SCR7-SAME: "-target-feature" "+m"
+// MCPU-SYNTACORE-SCR7-SAME: "-target-feature" "+a"
+// MCPU-SYNTACORE-SCR7-SAME: "-target-feature" "+f"
+// MCPU-SYNTACORE-SCR7-SAME: "-target-feature" "+d"
+// MCPU-SYNTACORE-SCR7-SAME: "-target-feature" "+c"
+// MCPU-SYNTACORE-SCR7-SAME: "-target-feature" "+v"
+// MCPU-SYNTACORE-SCR7-SAME: "-target-feature" "+zicsr"
+// MCPU-SYNTACORE-SCR7-SAME: "-target-feature" "+zifencei"
+// MCPU-SYNTACORE-SCR7-SAME: "-target-feature" "+zba"
+// MCPU-SYNTACORE-SCR7-SAME: "-target-feature" "+zbb"
+// MCPU-SYNTACORE-SCR7-SAME: "-target-feature" "+zbc"
+// MCPU-SYNTACORE-SCR7-SAME: "-target-feature" "+zbkb"
+// MCPU-SYNTACORE-SCR7-SAME: "-target-feature" "+zbkc"
+// MCPU-SYNTACORE-SCR7-SAME: "-target-feature" "+zbkx"
+// MCPU-SYNTACORE-SCR7-SAME: "-target-feature" "+zbs"
+// MCPU-SYNTACORE-SCR7-SAME: "-target-feature" "+zkn"
+// MCPU-SYNTACORE-SCR7-SAME: "-target-feature" "+zknd"
+// MCPU-SYNTACORE-SCR7-SAME: "-target-feature" "+zkne"
+// MCPU-SYNTACORE-SCR7-SAME: "-target-feature" "+zknh"
+// MCPU-SYNTACORE-SCR7-SAME: "-target-abi" "lp64d"
+
+// RUN: %clang --target=riscv64 -### -c %s 2>&1 -mtune=syntacore-scr7 |
FileCheck -check-prefix=MTUNE-SYNTACORE-SCR7 %s
+// MTUNE-SYNTACORE-SCR7: "-tune-cpu" "syntacore-scr7"
diff --git a/clang/test/Misc/target-invalid-cpu-note/riscv.c
b/clang/test/Misc/target-invalid-cpu-note/riscv.c
index 96d3cefd434d78..7bbf3574af3c35 100644
--- a/clang/test/Misc/target-invalid-cpu-note/riscv.c
+++ b/clang/test/Misc/target-invalid-cpu-note/riscv.c
@@ -40,6 +40,7 @@
// RISCV64-SAME: {{^}}, syntacore-scr3-rv64
// RISCV64-SAME: {{^}}, syntacore-scr4-rv64
// RISCV64-SAME: {{^}}, syntacore-scr5-rv64
+// RISCV64-SAME: {{^}}, syntacore-scr7
// RISCV64-SAME: {{^}}, veyron-v1
// RISCV64-SAME: {{^}}, xiangshan-nanhu
// RISCV64-SAME: {{$}}
@@ -85,6 +86,7 @@
// TUNE-RISCV64-SAME: {{^}}, syntacore-scr3-rv64
// TUNE-RISCV64-SAME: {{^}}, syntacore-scr4-rv64
// TUNE-RISCV64-SAME: {{^}}, syntacore-scr5-rv64
+// TUNE-RISCV64-SAME: {{^}}, syntacore-scr7
// TUNE-RISCV64-SAME: {{^}}, veyron-v1
// TUNE-RISCV64-SAME: {{^}}, xiangshan-nanhu
// TUNE-RISCV64-SAME: {{^}}, generic
diff --git a/llvm/docs/ReleaseNotes.rst b/llvm/docs/ReleaseNotes.rst
index 52456896f2fc6c..6df4c37b092432 100644
--- a/llvm/docs/ReleaseNotes.rst
+++ b/llvm/docs/ReleaseNotes.rst
@@ -123,6 +123,7 @@ Changes to the RISC-V Backend
largely untested.
* The ``Zvbc32e`` and ``Zvkgs`` extensions are now supported experimentally.
* Added ``Smctr`` and ``Ssctr`` extensions.
+* ``-mcpu=syntacore-scr7`` was added.
Changes to the WebAssembly Backend
--
diff --git a/llvm/lib/Target/RISCV/RISCVProcessors.td
b/llvm/lib/Target/RISCV/RISCVProcessors.td
index d4ec5ecc6489c1..c4e1a1457e8d30 100644
--- a/llvm/lib/Target/RISCV/RISCVProcessors.td
+++ b/llvm/lib/Target/RISCV/RISCVProcessors.td
@@ -383,6 +383,25 @@ def SYNTACORE_SCR5_RV64 :
RISCVProcessorModel<"syntacore-scr5-rv64",
FeatureStdExtC],
[TuneNoDefaultUnroll,
FeaturePostRAScheduler]>;
+def SYNTACORE_SCR7 : RISCVProcessorModel<"syntacore-scr7",
+ NoSchedModel,
+ [Feature64Bit,
+ FeatureStdExtI,
+
[clang] [llvm] [RISCV] Add Syntacore SCR7 processor definition (PR #108406)
https://github.com/asi-sc closed https://github.com/llvm/llvm-project/pull/108406 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] [clang-tidy] Create bugprone-incorrect-enable-shared-from-this check (PR #102299)
MichelleCDjunaidi wrote: Thanks for the feedback! Currently working on it. https://github.com/llvm/llvm-project/pull/102299 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Fix incorrect partial ordering context setting (PR #108491)
https://github.com/alexfh approved this pull request. Thanks! This fixes the issues we've found so far, and it seems to be a quite clear correctness fix. LGTM https://github.com/llvm/llvm-project/pull/108491 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Emit error for duplicate mangled names within a lambda (PR #107581)
@@ -4652,18 +4652,35 @@ llvm::Constant *CodeGenModule::GetOrCreateLLVMFunction(
// If there are two attempts to define the same mangled name, issue an
// error.
-if (IsForDefinition && !Entry->isDeclaration()) {
- GlobalDecl OtherGD;
- // Check that GD is not yet in DiagnosedConflictingDefinitions is
required
- // to make sure that we issue an error only once.
- if (lookupRepresentativeDecl(MangledName, OtherGD) &&
- (GD.getCanonicalDecl().getDecl() !=
- OtherGD.getCanonicalDecl().getDecl()) &&
- DiagnosedConflictingDefinitions.insert(GD).second) {
+GlobalDecl OtherGD;
+// Check that GD is not yet in DiagnosedConflictingDefinitions is required
+// to make sure that we issue an error only once.
+if (GD && lookupRepresentativeDecl(MangledName, OtherGD) &&
+(GD.getCanonicalDecl().getDecl() !=
+ OtherGD.getCanonicalDecl().getDecl()) &&
+DiagnosedConflictingDefinitions.insert(GD).second) {
+ if (IsForDefinition && !Entry->isDeclaration()) {
getDiags().Report(D->getLocation(), diag::err_duplicate_mangled_name)
<< MangledName;
getDiags().Report(OtherGD.getDecl()->getLocation(),
diag::note_previous_definition);
+ } else {
+// For lambdas, it's possible to create the same mangled name from
+// different function prototypes. For example, two FPTs may have
+// identical types but incompatible function attributes which we should
+// not allow.
+auto *MD = dyn_cast(D);
+if (MD && MD->getParent()->isLambda()) {
+ const FunctionDecl *OtherFD =
+ cast_or_null(OtherGD.getDecl());
+ if (FD && FD->hasPrototype() && OtherFD && OtherFD->hasPrototype()) {
+if (FD->getType()->getAs() !=
+OtherFD->getType()->getAs())
sdesmalen-arm wrote:
I don't understand why there's a need to check the `FunctionProtoType`s here,
because the check `GD.getCanonicalDecl().getDecl() !=
OtherGD.getCanonicalDecl().getDecl()` has already checked if the declarations
and types are the same.
Note that I tried a smaller change like this:
```
bool IsLambdaInstantiation =
D && isa(D) &&
cast(D)->getParent()->isLambda();
if (IsForDefinition && (!Entry->isDeclaration() || IsLambdaInstantiation)) {
```
And got the desired result. Would the above be sufficient or is there something
this is not covering?
https://github.com/llvm/llvm-project/pull/107581
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Emit error for duplicate mangled names within a lambda (PR #107581)
@@ -0,0 +1,30 @@
+// REQUIRES: aarch64-registered-target
+
+// RUN: %clang_cc1 -triple aarch64 -target-feature +sme -target-feature +sme2
-emit-llvm -o - %s -verify -DTEST1
+// RUN: %clang_cc1 -triple aarch64 -target-feature +sme -target-feature +sme2
-emit-llvm -o - %s -verify -DTEST2
+
+int normal_fn(int);
+int streaming_fn(int) __arm_streaming;
+int streaming_compatible_fn(int) __arm_streaming_compatible;
+
+#ifdef TEST1
+
+// expected-error@+3 {{definition with same mangled name
'_ZZ32function_params_normal_streamingvENK3$_0clIFiiEEEDaRT_' as another
definition}}
+// expected-note@+2 {{previous definition is here}}
+int function_params_normal_streaming() {
+ auto a = [](auto &fn) { return fn(42); };
+ return a(normal_fn) + a(streaming_fn);
+}
+
+#endif
+
+#ifdef TEST2
+
+// expected-error@+3 {{definition with same mangled name
'_ZZ36function_params_streaming_compatiblevENK3$_0clIFiiEEEDaRT_' as another
definition}}
+// expected-note@+2 {{previous definition is here}}
+int function_params_streaming_compatible() {
+ auto a = [](auto &fn) { return fn(42); };
+ return a(streaming_fn) + a(streaming_compatible_fn);
+}
+
+#endif
sdesmalen-arm wrote:
This test adds much value over the other test above, because the logic is no
different for streaming and streaming-compatible attributes, so I think you can
remove it.
https://github.com/llvm/llvm-project/pull/107581
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Emit error for duplicate mangled names within a lambda (PR #107581)
@@ -0,0 +1,30 @@
+// REQUIRES: aarch64-registered-target
+
+// RUN: %clang_cc1 -triple aarch64 -target-feature +sme -target-feature +sme2
-emit-llvm -o - %s -verify -DTEST1
+// RUN: %clang_cc1 -triple aarch64 -target-feature +sme -target-feature +sme2
-emit-llvm -o - %s -verify -DTEST2
+
+int normal_fn(int);
+int streaming_fn(int) __arm_streaming;
+int streaming_compatible_fn(int) __arm_streaming_compatible;
+
+#ifdef TEST1
+
+// expected-error@+3 {{definition with same mangled name
'_ZZ32function_params_normal_streamingvENK3$_0clIFiiEEEDaRT_' as another
definition}}
+// expected-note@+2 {{previous definition is here}}
+int function_params_normal_streaming() {
+ auto a = [](auto &fn) { return fn(42); };
+ return a(normal_fn) + a(streaming_fn);
+}
+
+#endif
+
+#ifdef TEST2
+
+// expected-error@+3 {{definition with same mangled name
'_ZZ36function_params_streaming_compatiblevENK3$_0clIFiiEEEDaRT_' as another
definition}}
+// expected-note@+2 {{previous definition is here}}
+int function_params_streaming_compatible() {
+ auto a = [](auto &fn) { return fn(42); };
+ return a(streaming_fn) + a(streaming_compatible_fn);
+}
+
+#endif
sdesmalen-arm wrote:
Can you add a separate test for a non-SME attribute that has a similar issue?
Type attributes for the calling convention are also not part of the type
mangling, e.g. https://godbolt.org/z/sEdsGr53K which would (without your
change) miscompile.
https://github.com/llvm/llvm-project/pull/107581
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Emit error for duplicate mangled names within a lambda (PR #107581)
@@ -4652,18 +4652,35 @@ llvm::Constant *CodeGenModule::GetOrCreateLLVMFunction(
// If there are two attempts to define the same mangled name, issue an
// error.
-if (IsForDefinition && !Entry->isDeclaration()) {
- GlobalDecl OtherGD;
- // Check that GD is not yet in DiagnosedConflictingDefinitions is
required
- // to make sure that we issue an error only once.
- if (lookupRepresentativeDecl(MangledName, OtherGD) &&
- (GD.getCanonicalDecl().getDecl() !=
- OtherGD.getCanonicalDecl().getDecl()) &&
- DiagnosedConflictingDefinitions.insert(GD).second) {
+GlobalDecl OtherGD;
+// Check that GD is not yet in DiagnosedConflictingDefinitions is required
+// to make sure that we issue an error only once.
+if (GD && lookupRepresentativeDecl(MangledName, OtherGD) &&
+(GD.getCanonicalDecl().getDecl() !=
+ OtherGD.getCanonicalDecl().getDecl()) &&
+DiagnosedConflictingDefinitions.insert(GD).second) {
+ if (IsForDefinition && !Entry->isDeclaration()) {
getDiags().Report(D->getLocation(), diag::err_duplicate_mangled_name)
<< MangledName;
getDiags().Report(OtherGD.getDecl()->getLocation(),
diag::note_previous_definition);
+ } else {
+// For lambdas, it's possible to create the same mangled name from
+// different function prototypes. For example, two FPTs may have
+// identical types but incompatible function attributes which we should
+// not allow.
+auto *MD = dyn_cast(D);
+if (MD && MD->getParent()->isLambda()) {
+ const FunctionDecl *OtherFD =
+ cast_or_null(OtherGD.getDecl());
+ if (FD && FD->hasPrototype() && OtherFD && OtherFD->hasPrototype()) {
+if (FD->getType()->getAs() !=
+OtherFD->getType()->getAs())
sdesmalen-arm wrote:
(I see you implemented the same suggestion, not sure why Github didn't publish
my comment)
https://github.com/llvm/llvm-project/pull/107581
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][codegen] Fix possible crash when setting TBAA metadata on FP math libcalls (PR #108575)
mstorsjo wrote:
I managed to reduce the breakage to the following snippet:
```c
long double powl(long double a, long double b);
long double a() { return powl(2.0L, 2.0L); }
```
Compiled like this:
```
$ clang -target x86_64-w64-mingw32 -S -O2 -o out.s repro.c
```
The output between before and after this change differs like this:
```diff
--- out-good.s 2024-09-16 13:45:09.505125890 +0300
+++ out-bad.s 2024-09-16 13:45:09.533125294 +0300
@@ -10,12 +10,7 @@
.scl2;
.type 32;
.endef
- .section.rdata,"dr"
- .p2align2, 0x0 # -- Begin function a
-.LCPI0_0:
- .long 0x4000 # float 2
- .text
- .globl a
+ .globl a # -- Begin function a
.p2align4, 0x90
a: # @a
.seh_proc a
@@ -26,16 +21,10 @@
.seh_stackalloc 80
.seh_endprologue
movq%rcx, %rsi
- flds.LCPI0_0(%rip)
- fld %st(0)
- fstpt 48(%rsp)
- fstpt 32(%rsp)
leaq64(%rsp), %rcx
leaq48(%rsp), %rdx
leaq32(%rsp), %r8
callq powl
- fldt64(%rsp)
- fstpt (%rsi)
movq%rsi, %rax
addq$80, %rsp
popq%rsi
```
I'll push a revert shortly.
https://github.com/llvm/llvm-project/pull/108575
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AST] Iterate redecls starting from the canonical one in getRawCommentsForAnyRedecl() (PR #108475)
zyn0217 wrote: > This is in turn because the [code that sets > this](https://searchfox.org/llvm/rev/3ae71d154e5dfb5e5a5d27b3699b27ce2b55f44d/clang/lib/AST/Comment.cpp#238-243) > is conditioned on FunctionDecl::getNumTemplateParameterLists() != 0. I was curious why it is relying on `getNumTemplateParameterLists()`. To my understanding, it should call `FD->getTemplateSpecializationInfo()`, shouldn't it? https://github.com/llvm/llvm-project/pull/108475 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [SPIRV][RFC] Rework / extend support for memory scopes (PR #106429)
@@ -33,7 +33,8 @@
#include "llvm/Support/Debug.h"
namespace {
VyacheslavLevytskyy wrote:
@AlexVlx Let's remove all references to `struct SyncScopeIDs` from the whole
`SPIRVInstructionSelector.cpp` module. We will insert
`getOrInsertSyncScopeID()` in the `getMemScope()` portion of code.
https://github.com/llvm/llvm-project/pull/106429
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][C23] Claim N3030 Enhancements to Enumerations supported (PR #107260)
https://github.com/Fznamznon updated
https://github.com/llvm/llvm-project/pull/107260
>From da76f2dfd3b0c8e2a03165ad1ac06b517c4af391 Mon Sep 17 00:00:00 2001
From: "Podchishchaeva, Mariya"
Date: Wed, 4 Sep 2024 07:45:27 -0700
Subject: [PATCH 1/2] [clang][C23] Claim N3030 Enhancements to Enumerations
supported
Clang already implemented functionality as an extension.
---
.../clang/Basic/DiagnosticParseKinds.td | 9 +-
clang/lib/Parse/ParseDecl.cpp | 8 +-
clang/test/C/C23/n3030.c | 95 +++
clang/test/Sema/fixed-enum.c | 25 +++--
clang/www/c_status.html | 2 +-
5 files changed, 124 insertions(+), 15 deletions(-)
create mode 100644 clang/test/C/C23/n3030.c
diff --git a/clang/include/clang/Basic/DiagnosticParseKinds.td
b/clang/include/clang/Basic/DiagnosticParseKinds.td
index 0b8ab4bf092509..a1070aceea7572 100644
--- a/clang/include/clang/Basic/DiagnosticParseKinds.td
+++ b/clang/include/clang/Basic/DiagnosticParseKinds.td
@@ -113,9 +113,12 @@ def ext_cxx11_enum_fixed_underlying_type : Extension<
def ext_ms_c_enum_fixed_underlying_type : Extension<
"enumeration types with a fixed underlying type are a Microsoft extension">,
InGroup;
-def ext_clang_c_enum_fixed_underlying_type : Extension<
- "enumeration types with a fixed underlying type are a Clang extension">,
- InGroup>;
+def ext_c23_enum_fixed_underlying_type : Extension<
+ "enumeration types with a fixed underlying type are a C23 extension">,
+ InGroup;
+def warn_c17_compat_enum_fixed_underlying_type : Warning<
+ "enumeration types with a fixed underlying type are incompatible with C
standards before C23">,
+ DefaultIgnore, InGroup;
def warn_cxx98_compat_enum_fixed_underlying_type : Warning<
"enumeration types with a fixed underlying type are incompatible with
C++98">,
InGroup, DefaultIgnore;
diff --git a/clang/lib/Parse/ParseDecl.cpp b/clang/lib/Parse/ParseDecl.cpp
index 78d729c5ef7d8a..b563f875c663c6 100644
--- a/clang/lib/Parse/ParseDecl.cpp
+++ b/clang/lib/Parse/ParseDecl.cpp
@@ -5413,18 +5413,20 @@ void Parser::ParseEnumSpecifier(SourceLocation
StartLoc, DeclSpec &DS,
BaseRange = SourceRange(ColonLoc,
DeclaratorInfo.getSourceRange().getEnd());
- if (!getLangOpts().ObjC && !getLangOpts().C23) {
+ if (!getLangOpts().ObjC) {
if (getLangOpts().CPlusPlus11)
Diag(ColonLoc, diag::warn_cxx98_compat_enum_fixed_underlying_type)
<< BaseRange;
else if (getLangOpts().CPlusPlus)
Diag(ColonLoc, diag::ext_cxx11_enum_fixed_underlying_type)
<< BaseRange;
-else if (getLangOpts().MicrosoftExt)
+else if (getLangOpts().MicrosoftExt && !getLangOpts().C23)
Diag(ColonLoc, diag::ext_ms_c_enum_fixed_underlying_type)
<< BaseRange;
else
- Diag(ColonLoc, diag::ext_clang_c_enum_fixed_underlying_type)
+ Diag(ColonLoc, (getLangOpts().C23)
+ ? diag::warn_c17_compat_enum_fixed_underlying_type
+ : diag::ext_c23_enum_fixed_underlying_type)
<< BaseRange;
}
}
diff --git a/clang/test/C/C23/n3030.c b/clang/test/C/C23/n3030.c
new file mode 100644
index 00..82e50484fd7ebc
--- /dev/null
+++ b/clang/test/C/C23/n3030.c
@@ -0,0 +1,95 @@
+// RUN: %clang_cc1 -verify -triple x86_64-unknown-linux-gnu -fsyntax-only
--embed-dir=%S/Inputs -std=c23 %s -pedantic -Wall
+
+#include
+
+enum us : unsigned short {
+ us_max = USHRT_MAX,
+ us_violation, // expected-error {{enumerator value 65536 is not
representable in the underlying type 'unsigned short'}}
+ // expected-warning@-1 {{overflow}}
+ us_violation_2 = us_max + 1, // expected-error {{enumerator value is not
representable in the underlying type 'unsigned short'}}
+ us_wrap_around_to_zero = (unsigned short)(USHRT_MAX + 1) /* Okay: conversion
+done in constant expression before conversion to
+underlying type: unsigned semantics okay. */
+};
+
+enum ui : unsigned int {
+ ui_max = UINT_MAX,
+ ui_violation, // expected-error {{enumerator value 4294967296 is not
representable in the underlying type 'unsigned int'}}
+ // expected-warning@-1 {{overflow}}
+ ui_no_violation = ui_max + 1,
+ ui_wrap_around_to_zero = (unsigned int)(UINT_MAX + 1)
+};
+
+enum E1 : short;
+enum E2 : short; // expected-note {{previous}}
+enum E3; // expected-warning {{ISO C forbids forward references to 'enum'
types}}
+enum E4 : unsigned long long;
+
+enum E1 : short { m11, m12 };
+enum E1 x = m11;
+
+enum E2 : long { // expected-error {{enumeration redeclared with different
underlying type 'long' (was 'short')}}
+ m21,
+ m22
+};
+
+enum E3 { // expected-note {{definition of 'enum E3' is not complete until the
closing '}'}}
+ // expected-note@-1 {{previous}}
+ m31,
+ m32,
+ m33 = sizeo
[clang] [clang][C23] Claim N3030 Enhancements to Enumerations supported (PR #107260)
@@ -0,0 +1,95 @@ +// RUN: %clang_cc1 -verify -triple x86_64-unknown-linux-gnu -fsyntax-only --embed-dir=%S/Inputs -std=c23 %s -pedantic -Wall Fznamznon wrote: Done, thanks for the catch! https://github.com/llvm/llvm-project/pull/107260 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][C23] Claim N3030 Enhancements to Enumerations supported (PR #107260)
@@ -5413,18 +5413,20 @@ void Parser::ParseEnumSpecifier(SourceLocation
StartLoc, DeclSpec &DS,
BaseRange = SourceRange(ColonLoc,
DeclaratorInfo.getSourceRange().getEnd());
- if (!getLangOpts().ObjC && !getLangOpts().C23) {
+ if (!getLangOpts().ObjC) {
if (getLangOpts().CPlusPlus11)
Diag(ColonLoc, diag::warn_cxx98_compat_enum_fixed_underlying_type)
<< BaseRange;
else if (getLangOpts().CPlusPlus)
Diag(ColonLoc, diag::ext_cxx11_enum_fixed_underlying_type)
<< BaseRange;
-else if (getLangOpts().MicrosoftExt)
+else if (getLangOpts().MicrosoftExt && !getLangOpts().C23)
Diag(ColonLoc, diag::ext_ms_c_enum_fixed_underlying_type)
<< BaseRange;
else
- Diag(ColonLoc, diag::ext_clang_c_enum_fixed_underlying_type)
+ Diag(ColonLoc, (getLangOpts().C23)
Fznamznon wrote:
Done.
https://github.com/llvm/llvm-project/pull/107260
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [SPIRV][RFC] Rework / extend support for memory scopes (PR #106429)
@@ -251,6 +251,24 @@ SPIRV::MemorySemantics::MemorySemantics
getMemSemantics(AtomicOrdering Ord) {
llvm_unreachable(nullptr);
}
+SPIRV::Scope::Scope getMemScope(const LLVMContext &Ctx, SyncScope::ID ID) {
VyacheslavLevytskyy wrote:
@AlexVlx If you don't mind, let's do this function as the following:
```
SPIRV::Scope::Scope getMemScope(LLVMContext &Context, SyncScope::ID Id) {
// Named by
// https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#_scope_id We
// don't need aliases for Invocation and CrossDevice, as we already have them
// covered by "singlethread" and "" strings respectively (see implementation
// of LLVMContext::LLVMContext()).
static llvm::SyncScope::ID SubGroupSSID =
Context.getOrInsertSyncScopeID("subgroup");
static llvm::SyncScope::ID WorkGroupSSID =
Context.getOrInsertSyncScopeID("workgroup");
static llvm::SyncScope::ID DeviceSSID =
Context.getOrInsertSyncScopeID("device");
if (Id == SyncScope::SingleThread)
return SPIRV::Scope::Invocation;
if (Id == SubGroupSSID)
return SPIRV::Scope::Subgroup;
if (Id == WorkGroupSSID)
return SPIRV::Scope::Workgroup;
if (Id == DeviceSSID)
return SPIRV::Scope::Device;
if (Id == SyncScope::System)
return SPIRV::Scope::CrossDevice;
// This function assumes that known memory sync scopes may appear to be the
// non-exhaustive list and allows to use the most conservative/safe choice as
// the default in case of an unknown SyncScope::ID value.
return SPIRV::Scope::CrossDevice;
}
```
https://github.com/llvm/llvm-project/pull/106429
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] f710612 - Revert "[clang][codegen] Fix possible crash when setting TBAA metadata on FP math libcalls (#108575)"
Author: Martin Storsjö
Date: 2024-09-16T13:51:16+03:00
New Revision: f71061258484390cb74752e9d7e486264aa4db0a
URL:
https://github.com/llvm/llvm-project/commit/f71061258484390cb74752e9d7e486264aa4db0a
DIFF:
https://github.com/llvm/llvm-project/commit/f71061258484390cb74752e9d7e486264aa4db0a.diff
LOG: Revert "[clang][codegen] Fix possible crash when setting TBAA metadata on
FP math libcalls (#108575)"
This reverts commit a56ca1a0fb248c6f38b5841323a74673748f43ea.
This commit broke code generation for x86 mingw targets, with regards
to long double math functions - see
https://github.com/llvm/llvm-project/pull/108575#issuecomment-2352574978
for details.
Added:
Modified:
clang/lib/CodeGen/CGBuiltin.cpp
Removed:
diff --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index a76cd5f9a6f47d..a52e880a764252 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -690,10 +690,8 @@ static RValue emitLibraryCall(CodeGenFunction &CGF, const
FunctionDecl *FD,
const CallExpr *E, llvm::Constant *calleeValue) {
CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, E);
CGCallee callee = CGCallee::forDirect(calleeValue, GlobalDecl(FD));
- llvm::CallBase *callOrInvoke = nullptr;
RValue Call =
- CGF.EmitCall(E->getCallee()->getType(), callee, E, ReturnValueSlot(),
- /*Chain=*/nullptr, &callOrInvoke);
+ CGF.EmitCall(E->getCallee()->getType(), callee, E, ReturnValueSlot());
if (unsigned BuiltinID = FD->getBuiltinID()) {
// Check whether a FP math builtin function, such as BI__builtin_expf
@@ -707,7 +705,8 @@ static RValue emitLibraryCall(CodeGenFunction &CGF, const
FunctionDecl *FD,
// Emit "int" TBAA metadata on FP math libcalls.
clang::QualType IntTy = Context.IntTy;
TBAAAccessInfo TBAAInfo = CGF.CGM.getTBAAAccessInfo(IntTy);
- CGF.CGM.DecorateInstructionWithTBAA(callOrInvoke, TBAAInfo);
+ Instruction *Inst = cast(Call.getScalarVal());
+ CGF.CGM.DecorateInstructionWithTBAA(Inst, TBAAInfo);
}
}
return Call;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [SPIRV][RFC] Rework / extend support for memory scopes (PR #106429)
@@ -251,6 +251,24 @@ SPIRV::MemorySemantics::MemorySemantics
getMemSemantics(AtomicOrdering Ord) {
llvm_unreachable(nullptr);
}
+SPIRV::Scope::Scope getMemScope(const LLVMContext &Ctx, SyncScope::ID ID) {
VyacheslavLevytskyy wrote:
I'd say that removal of SSIDs struct from
lib/Target/SPIRV/SPIRVInstructionSelector.cpp and this implementation of
`getMemScope()` may be enough. Here we may initialize and refer all scopes
concisely.
https://github.com/llvm/llvm-project/pull/106429
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [SPIRV][RFC] Rework / extend support for memory scopes (PR #106429)
@@ -75,6 +75,8 @@ getMemSemanticsForStorageClass(SPIRV::StorageClass::StorageClass SC); SPIRV::MemorySemantics::MemorySemantics getMemSemantics(AtomicOrdering Ord); +SPIRV::Scope::Scope getMemScope(const LLVMContext &Ctx, SyncScope::ID ID); VyacheslavLevytskyy wrote: `SPIRV::Scope::Scope getMemScope(LLVMContext &Context, SyncScope::ID Id);` https://github.com/llvm/llvm-project/pull/106429 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] Remove ^^ as a token in OpenCL (PR #108224)
AnastasiaStulova wrote: > Thanks! Making sure I follow along, basically you're saying this patch is > good because it keeps the ^^ token reserved, and if/when OpenCL supports C++, > it can then use this token for reflection in C++ (if that's chosen by WG21 > for the syntax) or use it for its own needs? Exactly! > One thing to make sure we're both on the same page for -- should the OpenCL > spec folks be alerted to the fact that ^^ as a single token conflicts with > blocks in C? (That suggests it's perhaps not a good token to use for a binary > operator and maybe they want to un-reserve it?) It may make sense to report this indeed. An issue can be submitted to this repo: https://github.com/KhronosGroup/OpenCL-Docs. CC: @svenvh https://github.com/llvm/llvm-project/pull/108224 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][C23] Claim N3030 Enhancements to Enumerations supported (PR #107260)
@@ -0,0 +1,95 @@
+// RUN: %clang_cc1 -verify -triple x86_64-unknown-linux-gnu -fsyntax-only
--embed-dir=%S/Inputs -std=c23 %s -pedantic -Wall
+
+#include
+
+enum us : unsigned short {
+ us_max = USHRT_MAX,
+ us_violation, // expected-error {{enumerator value 65536 is not
representable in the underlying type 'unsigned short'}}
+ // expected-warning@-1 {{overflow}}
+ us_violation_2 = us_max + 1, // expected-error {{enumerator value is not
representable in the underlying type 'unsigned short'}}
+ us_wrap_around_to_zero = (unsigned short)(USHRT_MAX + 1) /* Okay: conversion
+done in constant expression before conversion to
+underlying type: unsigned semantics okay. */
+};
+
+enum ui : unsigned int {
+ ui_max = UINT_MAX,
+ ui_violation, // expected-error {{enumerator value 4294967296 is not
representable in the underlying type 'unsigned int'}}
+ // expected-warning@-1 {{overflow}}
+ ui_no_violation = ui_max + 1,
+ ui_wrap_around_to_zero = (unsigned int)(UINT_MAX + 1)
+};
+
+enum E1 : short;
+enum E2 : short; // expected-note {{previous}}
+enum E3; // expected-warning {{ISO C forbids forward references to 'enum'
types}}
+enum E4 : unsigned long long;
+
+enum E1 : short { m11, m12 };
+enum E1 x = m11;
+
+enum E2 : long { // expected-error {{enumeration redeclared with different
underlying type 'long' (was 'short')}}
+ m21,
+ m22
+};
+
+enum E3 { // expected-note {{definition of 'enum E3' is not complete until the
closing '}'}}
+ // expected-note@-1 {{previous}}
+ m31,
+ m32,
+ m33 = sizeof(enum E3) // expected-error {{invalid application of 'sizeof' to
an incomplete type 'enum E3'}}
+};
+enum E3 : int; // expected-error {{enumeration previously declared with
nonfixed underlying type}}
+
+enum E4 : unsigned long long {
+ m40 = sizeof(enum E4),
+ m41 = ULLONG_MAX,
+ m42 // expected-error {{enumerator value 18446744073709551616 is not
representable in the underlying type 'unsigned long long'}}
+};
+
+enum E5 y; // expected-error {{tentative definition has type 'enum E5' that is
never completed}}
+ // expected-warning@-1 {{ISO C forbids forward references to 'enum'
types}}
+ // expected-note@-2 {{forward declaration of 'enum E5'}}
+enum E6 : long int z; // expected-error {{non-defining declaration of
enumeration with a fixed underlying type is only permitted as a standalone
declaration; missing list of enumerators?}}
+enum E7 : long int = 0; // expected-error {{non-defining declaration of
enumeration with a fixed underlying type is only permitted as a standalone
declaration; missing list of enumerators?}}
+ // expected-error@-1 {{expected identifier or '('}}
+
+enum underlying : unsigned char { b0 };
+
+constexpr int a = _Generic(b0, int: 2, unsigned char: 1, default: 0);
+constexpr int b = _Generic((enum underlying)b0, int: 2, unsigned char: 1,
default: 0);
+static_assert(a == 1);
+static_assert(b == 1);
+
+void f1(enum a : long b); // expected-error {{non-defining declaration of
enumeration with a fixed underlying type is only permitted as a standalone
declaration; missing list of enumerators?}}
+ // expected-warning@-1 {{declaration of 'enum a'
will not be visible outside of this function}}
+void f2(enum c : long{x} d); // expected-warning {{declaration of 'enum c'
will not be visible outside of this function}}
+enum e : int f3(); // expected-error {{non-defining declaration of enumeration
with a fixed underlying type is only permitted as a standalone declaration;
missing list of enumerators?}}
+
+typedef enum t u; // expected-warning {{ISO C forbids forward references to
'enum' types}}
+typedef enum v : short W; // expected-error {{non-defining declaration of
enumeration with a fixed underlying type is only permitted as a standalone
declaration; missing list of enumerators?}}
+typedef enum q : short { s } R;
+
+struct s1 {
+ int x;
+ enum e:int : 1; // expected-error {{non-defining declaration of enumeration
with a fixed underlying type is only permitted as a standalone declaration;
missing list of enumerators?}}
+ int y;
+};
+
+enum forward; // expected-warning {{ISO C forbids forward references to 'enum'
types}}
+extern enum forward fwd_val0; /* Constraint violation: incomplete type */
Fznamznon wrote:
@AaronBallman , after looking into this, I noticed that we emit this pedantic
warning only for a first met declaration. So if I do
```
extern enum forward fwd_val0;
extern enum forward *fwd_ptr0;
```
The warning appears. Demo https://godbolt.org/z/saPEcPKs8
We don't enter the code emitting the diagnostic if there was a previous
declaration.
It is emitted here:
https://github.com/llvm/llvm-project/blob/f71061258484390cb74752e9d7e486264aa4db0a/clang/lib/Sema/SemaDecl.cpp#L17797
I wonder if that is still a problem and we need to change anything?
https://githu
[clang] [llvm] [SPIRV][RFC] Rework / extend support for memory scopes (PR #106429)
VyacheslavLevytskyy wrote: @AlexVlx I don't see much objections against https://github.com/llvm/llvm-project/pull/108528 on a conceptual level, so what do you think about merging it into this PR in a way that I commented above, by changing getmemScope() and moving init into its static vars? https://github.com/llvm/llvm-project/pull/106429 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Emit error for duplicate mangled names within a lambda (PR #107581)
https://github.com/kmclaughlin-arm updated
https://github.com/llvm/llvm-project/pull/107581
>From 1e6f25c517d8d1adeeaf59f826141efdcad8f05a Mon Sep 17 00:00:00 2001
From: Kerry McLaughlin
Date: Fri, 6 Sep 2024 10:13:33 +
Subject: [PATCH 1/3] [Clang] Emit error for duplicate mangled names within a
lambda
When functions are passed as arguments to a lambda, it's possible for
the mangled names of these functions to be the same despite the prototypes
being different. For example:
int non_streaming_fn(int);
int streaming_fn(int) __arm_streaming;
auto lambda_fn = [](const auto &f) { return f(); };
return lambda_fn(non_streaming_fn) + lambda_fn(streaming_fn);
Only one function will be generated for the lambda above and the __arm_streaming
attribute from streaming_fn will be incorrectly applied to non_streaming_fn.
With this change, an error will be emitted when a duplicate mangled name is
found but the function prototypes do not match.
---
clang/lib/CodeGen/CodeGenModule.cpp | 35 ++-
.../aarch64-sme-lambda-attributes.cpp | 28 +++
2 files changed, 54 insertions(+), 9 deletions(-)
create mode 100644 clang/test/CodeGenCXX/aarch64-sme-lambda-attributes.cpp
diff --git a/clang/lib/CodeGen/CodeGenModule.cpp
b/clang/lib/CodeGen/CodeGenModule.cpp
index df4c13c9ad97aa..b07090e3de6dfd 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -4638,8 +4638,8 @@ llvm::Constant *CodeGenModule::GetOrCreateLLVMFunction(
// Lookup the entry, lazily creating it if necessary.
llvm::GlobalValue *Entry = GetGlobalValue(MangledName);
if (Entry) {
+const FunctionDecl *FD = cast_or_null(D);
if (WeakRefReferences.erase(Entry)) {
- const FunctionDecl *FD = cast_or_null(D);
if (FD && !FD->hasAttr())
Entry->setLinkage(llvm::Function::ExternalLinkage);
}
@@ -4652,18 +4652,35 @@ llvm::Constant *CodeGenModule::GetOrCreateLLVMFunction(
// If there are two attempts to define the same mangled name, issue an
// error.
-if (IsForDefinition && !Entry->isDeclaration()) {
- GlobalDecl OtherGD;
- // Check that GD is not yet in DiagnosedConflictingDefinitions is
required
- // to make sure that we issue an error only once.
- if (lookupRepresentativeDecl(MangledName, OtherGD) &&
- (GD.getCanonicalDecl().getDecl() !=
- OtherGD.getCanonicalDecl().getDecl()) &&
- DiagnosedConflictingDefinitions.insert(GD).second) {
+GlobalDecl OtherGD;
+// Check that GD is not yet in DiagnosedConflictingDefinitions is required
+// to make sure that we issue an error only once.
+if (GD && lookupRepresentativeDecl(MangledName, OtherGD) &&
+(GD.getCanonicalDecl().getDecl() !=
+ OtherGD.getCanonicalDecl().getDecl()) &&
+DiagnosedConflictingDefinitions.insert(GD).second) {
+ if (IsForDefinition && !Entry->isDeclaration()) {
getDiags().Report(D->getLocation(), diag::err_duplicate_mangled_name)
<< MangledName;
getDiags().Report(OtherGD.getDecl()->getLocation(),
diag::note_previous_definition);
+ } else {
+// For lambdas, it's possible to create the same mangled name from
+// different function prototypes. For example, two FPTs may have
+// identical types but incompatible function attributes which we should
+// not allow.
+auto *MD = dyn_cast(D);
+if (MD && MD->getParent()->isLambda()) {
+ const FunctionDecl *OtherFD =
+ cast_or_null(OtherGD.getDecl());
+ if (FD && FD->hasPrototype() && OtherFD && OtherFD->hasPrototype()) {
+if (FD->getType()->getAs() !=
+OtherFD->getType()->getAs())
+ getDiags().Report(D->getLocation(),
+diag::err_duplicate_mangled_name)
+ << MangledName;
+ }
+}
}
}
diff --git a/clang/test/CodeGenCXX/aarch64-sme-lambda-attributes.cpp
b/clang/test/CodeGenCXX/aarch64-sme-lambda-attributes.cpp
new file mode 100644
index 00..bce3e657001679
--- /dev/null
+++ b/clang/test/CodeGenCXX/aarch64-sme-lambda-attributes.cpp
@@ -0,0 +1,28 @@
+// REQUIRES: aarch64-registered-target
+
+// RUN: %clang_cc1 -triple aarch64 -target-feature +sme -target-feature +sme2
-emit-llvm -o - %s -verify -DTEST1
+// RUN: %clang_cc1 -triple aarch64 -target-feature +sme -target-feature +sme2
-emit-llvm -o - %s -verify -DTEST2
+
+int normal_fn(int);
+int streaming_fn(int) __arm_streaming;
+int streaming_compatible_fn(int) __arm_streaming_compatible;
+
+#ifdef TEST1
+
+// expected-error@+2 {{definition with same mangled name
'_ZZ32function_params_normal_streamingvENK3$_0clIFiiEEEDaRT_' as another
definition}}
+int function_params_normal_streaming() {
+ auto a = [](auto &fn) { return fn(42); };
+ return a(normal_fn) + a(streaming_fn);
+}
+
+#endif
+
+#ifdef TEST2
+
+//
[clang] [clang] Fix incorrect partial ordering context setting (PR #108491)
https://github.com/cor3ntin approved this pull request. https://github.com/llvm/llvm-project/pull/108491 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang/AST] Make it possible to use SwiftAttr in type context (PR #108631)
https://github.com/Xazax-hun approved this pull request. Overall looks good to me, I have one question and a couple nits inline. I think having access to Attr from AttributedType makes sense, I would not be surprised if this helped some other use cases like Lifetime annotations in Crubit. But please wait for a review from @erichkeane as well. https://github.com/llvm/llvm-project/pull/108631 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang/AST] Make it possible to use SwiftAttr in type context (PR #108631)
@@ -8732,6 +8786,11 @@ static void processTypeAttrs(TypeProcessingState &state,
QualType &type,
case ParsedAttr::AT_HLSLParamModifier: {
HandleHLSLParamModifierAttr(state, type, attr, state.getSema());
attr.setUsedAsTypeAttr();
+ break;
+ }
Xazax-hun wrote:
The formatting might be a bit off here.
https://github.com/llvm/llvm-project/pull/108631
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang/AST] Make it possible to use SwiftAttr in type context (PR #108631)
@@ -6037,13 +6038,24 @@ class AttributedType : public Type, public
llvm::FoldingSetNode {
private:
friend class ASTContext; // ASTContext creates these
+ const Attr *Attribute;
+
QualType ModifiedType;
QualType EquivalentType;
AttributedType(QualType canon, attr::Kind attrKind, QualType modified,
QualType equivalent)
+ : AttributedType(canon, attrKind, nullptr, modified, equivalent) {}
+
+ AttributedType(QualType canon, const Attr *attr, QualType modified,
+ QualType equivalent);
+
+private:
+ AttributedType(QualType canon, attr::Kind attrKind, const Attr *attr,
+ QualType modified, QualType equivalent)
: Type(Attributed, canon, equivalent->getDependence()),
-ModifiedType(modified), EquivalentType(equivalent) {
+Attribute(attr), ModifiedType(modified),
+EquivalentType(equivalent) {
AttributedTypeBits.AttrKind = attrKind;
Xazax-hun wrote:
Do we need both `attrKind` and `attr`? It removed an indirection, but wondering
if we should prefer that or memory. No strong feelings here. @erichkeane any
opinions?
https://github.com/llvm/llvm-project/pull/108631
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang/AST] Make it possible to use SwiftAttr in type context (PR #108631)
@@ -7147,6 +7147,60 @@ static bool
HandleWebAssemblyFuncrefAttr(TypeProcessingState &State,
return false;
}
+static void HandleSwiftAttr(TypeProcessingState &State, TypeAttrLocation TAL,
+QualType &QT, ParsedAttr &PAttr) {
+ if (TAL == TAL_DeclName)
+return;
+
+ Sema &S = State.getSema();
+ auto &D = State.getDeclarator();
+
+ // If the attribute appears in declaration specifiers
+ // it should be handled as a declaration attribute,
+ // unless it's associated with a type or a function
+ // prototype (i.e. appears on a parameter or result type).
+ if (State.isProcessingDeclSpec()) {
+if (!(D.isPrototypeContext() ||
+ D.getContext() == DeclaratorContext::TypeName))
+ return;
+
+if (auto *chunk = D.getInnermostNonParenChunk()) {
+ moveAttrFromListToList(PAttr, State.getCurrentAttributes(),
+ const_cast(chunk)->getAttrs());
+ return;
+}
+ }
+
+ StringRef Str;
+ if (!S.checkStringLiteralArgumentAttr(PAttr, 0, Str)) {
+PAttr.setInvalid();
+return;
+ }
+
+ // If the attribute as attached to a paren move it closer to
+ // the declarator. This can happen in block declarations when
+ // an attribute is placed before `^` i.e. `(__attribute__((...)) ^)`.
Xazax-hun wrote:
I don't see a test case covering this scenario, should we add one?
https://github.com/llvm/llvm-project/pull/108631
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang/AST] Make it possible to use SwiftAttr in type context (PR #108631)
@@ -7163,7 +7217,8 @@ static QualType rebuildAttributedTypeWithoutNullability(ASTContext &Ctx, Ctx, Attributed->getModifiedType()); assert(Modified.getTypePtr() != Attributed->getModifiedType().getTypePtr()); return Ctx.getAttributedType(Attributed->getAttrKind(), Modified, - Attributed->getEquivalentType()); + Attributed->getEquivalentType(), + Attributed->getAttr()); Xazax-hun wrote: The formatting looks off here. https://github.com/llvm/llvm-project/pull/108631 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang/AST] Make it possible to use SwiftAttr in type context (PR #108631)
https://github.com/Xazax-hun edited https://github.com/llvm/llvm-project/pull/108631 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [analyzer] [MallocChecker] suspect all release functions as candidate for suppression (PR #104599)
pskrgag wrote: sorry to bother, but seems like this pr is stalled for 2 weeks https://github.com/llvm/llvm-project/pull/104599 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [lld] [llvm] [mlir] [IR] Introduce `T` to `DataLayout` to represent flat address space if a target supports it (PR #108786)
gonzalobg wrote: Is there some github issue or discourse thread that provides context for this change? What problem does this PR solve? My understanding is that the default LLVM IR address space (*) is flat. Is that currently the case or is my understanding incorrect? Is this PR proposing that `addrspace(0)` should be allowed to no longer be flat, and that whether a target provides a flat address space shall be optional? What alternatives where considered? (e.g. why isn't sufficient for targets that cannot provide a flat address pace to just not implement support for `addrspace(0)`? i.e. why do we need to support a non-flat `addrspace(0)` and allow a target to provide a `flat` addresspace at a different identifier?) (*) The address space C++/Rust/... pointers map to, i.e., `addrspace(0)`. https://github.com/llvm/llvm-project/pull/108786 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Try to fix llvm/llvm-project#41441 (PR #96464)
https://github.com/AaronBallman commented: Thank you for catching this! Can you please add a release note to `clang/docs/ReleaseNotes.rst` so users know about the fix? I think these changes otherwise look good. https://github.com/llvm/llvm-project/pull/96464 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [llvm] [FMV][AArch64] Unify ls64, ls64_v and ls64_accdata. (PR #108024)
@@ -73,8 +73,6 @@ enum CPUFeatures {
FEAT_SSBS,
FEAT_SSBS2,
FEAT_BTI,
- FEAT_LS64,
- FEAT_LS64_V,
tmatheson-arm wrote:
@Wilco1 could you explain the scenario you are worried about in more detail?
What you posted above appears to be a snippet of a generated resolver,
suggesting that the problematic scenario is:
- You have an old object file which contains a resolver.
- The resolver refers to bit 36 and has references to
`__init_cpu_features_resolver` (defined in `compiler-rt`)
- You link against a new `compiler-rt`, which has changed the meaning of bit 36.
I don't think step 3 is allowed. The compiler and compiler-rt need to remain in
sync, afaik?
There are no references to specific bit numbers outside of the generated
resolvers and `__init_cpu_features_resolver`.
https://github.com/llvm/llvm-project/pull/108024
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] Remove ^^ as a token in OpenCL (PR #108224)
https://github.com/cor3ntin approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/108224 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] Remove ^^ as a token in OpenCL (PR #108224)
AaronBallman wrote: > > Thanks! Making sure I follow along, basically you're saying this patch is > > good because it keeps the ^^ token reserved, and if/when OpenCL supports > > C++, it can then use this token for reflection in C++ (if that's chosen by > > WG21 for the syntax) or use it for its own needs? > > Exactly! > > > One thing to make sure we're both on the same page for -- should the OpenCL > > spec folks be alerted to the fact that ^^ as a single token conflicts with > > blocks in C? (That suggests it's perhaps not a good token to use for a > > binary operator and maybe they want to un-reserve it?) > > It may make sense to report this indeed. An issue can be submitted to this > repo: https://github.com/KhronosGroup/OpenCL-Docs. > > CC: @svenvh Thank you, I filed https://github.com/KhronosGroup/OpenCL-Docs/issues/1264 https://github.com/llvm/llvm-project/pull/108224 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 1881f64 - Remove ^^ as a token in OpenCL (#108224)
Author: Aaron Ballman
Date: 2024-09-16T07:46:58-04:00
New Revision: 1881f648e28aa58aa0a4dca1422572f65dafa9a4
URL:
https://github.com/llvm/llvm-project/commit/1881f648e28aa58aa0a4dca1422572f65dafa9a4
DIFF:
https://github.com/llvm/llvm-project/commit/1881f648e28aa58aa0a4dca1422572f65dafa9a4.diff
LOG: Remove ^^ as a token in OpenCL (#108224)
OpenCL has a reserved operator (^^), the use of which was diagnosed as
an error (735c6cdebdcd4292928079cb18a90f0dd5cd65fb). However, OpenCL
also encourages working with the blocks language extension. This token
has a parsing ambiguity as a result. Consider:
unsigned x=0;
unsigned y=x^^{return 0;}();
This should result in y holding the value zero (0^0) through an
immediately invoked block call as the right-hand side of the xor
operator. However, it causes errors instead because of this reserved
token: https://godbolt.org/z/navf7jTv1
This token is still reserved in OpenCL 3.0, so we still wish to issue a
diagnostic for its use. However, we do not need to create a token for an
extension point that's been unused for about a decade. So this patch
moves the diagnostic from a parsing diagnostic to a lexing diagnostic
and no longer forms a single token. The diagnostic behavior is slightly
worse as a result, but still seems acceptable.
Part of the reason this is coming up is because WG21 is considering
using ^^ as a token for reflection, so this token may come back in the
future.
Added:
Modified:
clang-tools-extra/clang-tidy/readability/AvoidUnconditionalPreprocessorIfCheck.cpp
clang-tools-extra/pseudo/lib/cxx/cxx.bnf
clang/include/clang/Basic/DiagnosticLexKinds.td
clang/include/clang/Basic/DiagnosticParseKinds.td
clang/include/clang/Basic/TokenKinds.def
clang/lib/Basic/OperatorPrecedence.cpp
clang/lib/Lex/Lexer.cpp
clang/lib/Parse/ParseExpr.cpp
clang/lib/Sema/SemaCodeComplete.cpp
clang/test/SemaOpenCL/unsupported.cl
Removed:
diff --git
a/clang-tools-extra/clang-tidy/readability/AvoidUnconditionalPreprocessorIfCheck.cpp
b/clang-tools-extra/clang-tidy/readability/AvoidUnconditionalPreprocessorIfCheck.cpp
index d92d0e8f2dbf7a..ca5fc358ce290a 100644
---
a/clang-tools-extra/clang-tidy/readability/AvoidUnconditionalPreprocessorIfCheck.cpp
+++
b/clang-tools-extra/clang-tidy/readability/AvoidUnconditionalPreprocessorIfCheck.cpp
@@ -84,7 +84,8 @@ struct AvoidUnconditionalPreprocessorIfPPCallbacks : public
PPCallbacks {
return (Tok.getRawIdentifier() == "true" ||
Tok.getRawIdentifier() == "false");
default:
- return Tok.getKind() >= tok::l_square && Tok.getKind() <=
tok::caretcaret;
+ return Tok.getKind() >= tok::l_square &&
+ Tok.getKind() <= tok::greatergreatergreater;
}
}
diff --git a/clang-tools-extra/pseudo/lib/cxx/cxx.bnf
b/clang-tools-extra/pseudo/lib/cxx/cxx.bnf
index 36caf7b1e63379..fbd964d4abe861 100644
--- a/clang-tools-extra/pseudo/lib/cxx/cxx.bnf
+++ b/clang-tools-extra/pseudo/lib/cxx/cxx.bnf
@@ -639,7 +639,6 @@ operator-name := >
operator-name := <=
operator-name := >=
operator-name := <=>
-operator-name := ^^
operator-name := ||
operator-name := <<
operator-name := greatergreater
diff --git a/clang/include/clang/Basic/DiagnosticLexKinds.td
b/clang/include/clang/Basic/DiagnosticLexKinds.td
index fc14bb6aa21651..889370221f32f0 100644
--- a/clang/include/clang/Basic/DiagnosticLexKinds.td
+++ b/clang/include/clang/Basic/DiagnosticLexKinds.td
@@ -508,6 +508,8 @@ def note_macro_expansion_here : Note<"expansion of macro %0
requested here">;
def ext_pp_opencl_variadic_macros : Extension<
"variadic macros are a Clang extension in OpenCL">;
+def err_opencl_logical_exclusive_or : Error<
+ "^^ is a reserved operator in OpenCL">;
def ext_pp_gnu_line_directive : Extension<
"this style of line directive is a GNU extension">,
diff --git a/clang/include/clang/Basic/DiagnosticParseKinds.td
b/clang/include/clang/Basic/DiagnosticParseKinds.td
index fec2456d6f4497..1afadb3bff750d 100644
--- a/clang/include/clang/Basic/DiagnosticParseKinds.td
+++ b/clang/include/clang/Basic/DiagnosticParseKinds.td
@@ -1397,8 +1397,6 @@ def err_modifier_expected_colon : Error<"missing ':'
after %0 modifier">;
// OpenCL errors.
def err_opencl_taking_function_address_parser : Error<
"taking address of function is not allowed">;
-def err_opencl_logical_exclusive_or : Error<
- "^^ is a reserved operator in OpenCL">;
// C++ for OpenCL.
def err_openclcxx_virtual_function : Error<
diff --git a/clang/include/clang/Basic/TokenKinds.def
b/clang/include/clang/Basic/TokenKinds.def
index a82ff684b2ac7d..00e150dbd7a3a7 100644
--- a/clang/include/clang/Basic/TokenKinds.def
+++ b/clang/include/clang/Basic/TokenKinds.def
@@ -255,9 +255,6 @@ PUNCTUATOR(at, "@")
PUNCTUATOR(lesslessless, "<<<")
PUNCTUATOR(greatergreatergreater, ">>>")
-// CL sup
[clang] [clang-tools-extra] Remove ^^ as a token in OpenCL (PR #108224)
https://github.com/AaronBallman closed https://github.com/llvm/llvm-project/pull/108224 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] check deduction consistency when partial ordering function templates (PR #100692)
alexfh wrote: @mizvekov another distinct compilation error after this commit (and not fixed by https://github.com/llvm/llvm-project/pull/107972 and other follow-up commits): https://gcc.godbolt.org/z/zMG5nsda3 (reduced from https://github.com/hlslibs/ac_math/blob/20bbf040834c5815b01a9ed8e523e4b0dabecf23/tests/rtest_ac_matrixmul.cpp) We have a few more cases that still generate this compilation error (`call to X is ambiguous`). I'm trying to reduce those as well. https://github.com/llvm/llvm-project/pull/100692 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [analyzer] Explicitly register NoStoreFuncVisitor from alpha.unix.cst… (PR #108373)
@@ -263,6 +263,23 @@ bool SVal::isZeroConstant() const {
// Pretty-Printing.
//===--===//
+StringRef SVal::getKindStr() const {
+ switch (getKind()) {
+#define BASIC_SVAL(Id, Parent)
\
+ case Id##Kind:
\
+return #Id;
+#define LOC_SVAL(Id, Parent)
\
+ case Loc##Id##Kind:
\
+return #Id;
+#define NONLOC_SVAL(Id, Parent)
\
+ case NonLoc##Id##Kind:
\
+return #Id;
+#include "clang/StaticAnalyzer/Core/PathSensitive/SVals.def"
+#undef REGION
+ }
+ llvm_unreachable("Unkown kind!");
+}
Szelethus wrote:
Yep. I recall back in the day that I asked authors to separate this into
smaller patches, but yeah, I've grown old and lazy. I think this is tolerable :)
https://github.com/llvm/llvm-project/pull/108373
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] [clang-tidy] Create bugprone-bit-cast-pointers check (PR #108083)
carlosgalvezp wrote: Thanks for the clarifications, will address asap! It now comes to mind that we probably also want to check `memcpy(ptr, ptr)`, which is equivalent to `bit_cast`. In that case I wonder if the check name still holds or it should be named something else? https://github.com/llvm/llvm-project/pull/108083 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Reject "this void" (CWG2915) (PR #108817)
https://github.com/MitalAshok created
https://github.com/llvm/llvm-project/pull/108817
https://cplusplus.github.io/CWG/issues/2915.html
Previously, `struct A { void f(this void); };` was accepted with `A::f` being a
member function with no non-object arguments, but it was still a little wonky
because it was still considered an explicit object member function. Now, this
is rejected immediately.
This applies to any language mode with explicit object parameters as this is a
DR (C++23 and C++26)
>From f283645de806c71d93ec10bc7fcb933ccbfee156 Mon Sep 17 00:00:00 2001
From: Mital Ashok
Date: Mon, 16 Sep 2024 12:22:01 +0100
Subject: [PATCH] [Clang] Reject "this void" (CWG2915)
---
clang/docs/ReleaseNotes.rst | 3 +
.../clang/Basic/DiagnosticSemaKinds.td| 2 +
clang/lib/Sema/SemaType.cpp | 8 +++
clang/test/CXX/drs/cwg29xx.cpp| 8 +++
clang/www/cxx_dr_status.html | 68 +--
5 files changed, 84 insertions(+), 5 deletions(-)
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 485b75049927fe..9c87a0d002b4ac 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -170,6 +170,9 @@ Resolutions to C++ Defect Reports
in constant expressions. These comparisons always worked in non-constant
expressions.
(`CWG2749: Treatment of "pointer to void" for relational comparisons
`_).
+- Reject explicit object parameters with type ``void`` (``this void``).
+ (`CWG2915: Explicit object parameters of type void
`_).
+
C Language Changes
--
diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index d42558d2223aae..271f96e383e57d 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -4687,6 +4687,8 @@ def err_void_only_param : Error<
"'void' must be the first and only parameter if specified">;
def err_void_param_qualified : Error<
"'void' as parameter must not have type qualifiers">;
+def err_void_explicit_object_param : Error<
+ "explicit object parameter cannot have 'void' type">;
def err_ident_list_in_fn_declaration : Error<
"a parameter list without types is only allowed in a function definition">;
def ext_param_not_declared : ExtWarn<
diff --git a/clang/lib/Sema/SemaType.cpp b/clang/lib/Sema/SemaType.cpp
index e627fee51b66b8..7b99f5d13463fe 100644
--- a/clang/lib/Sema/SemaType.cpp
+++ b/clang/lib/Sema/SemaType.cpp
@@ -5166,6 +5166,14 @@ static TypeSourceInfo
*GetFullTypeForDeclarator(TypeProcessingState &state,
if (ParamTy.hasQualifiers())
S.Diag(DeclType.Loc, diag::err_void_param_qualified);
+ // Reject, but continue to parse 'float(this void)' as
+ // 'float(void)'.
+ if (Param->isExplicitObjectParameter()) {
+S.Diag(Param->getLocation(),
+ diag::err_void_explicit_object_param);
+Param->setExplicitObjectParameterLoc(SourceLocation());
+ }
+
// Do not add 'void' to the list.
break;
}
diff --git a/clang/test/CXX/drs/cwg29xx.cpp b/clang/test/CXX/drs/cwg29xx.cpp
index ca598bb39a6c31..e55e8e35e86f28 100644
--- a/clang/test/CXX/drs/cwg29xx.cpp
+++ b/clang/test/CXX/drs/cwg29xx.cpp
@@ -6,6 +6,14 @@
// RUN: %clang_cc1 -std=c++23 -pedantic-errors -verify=expected %s
// RUN: %clang_cc1 -std=c++2c -pedantic-errors -verify=expected %s
+namespace cwg2915 { // cwg2915: 20 tentatively ready 2024-08-16
+#if __cplusplus >= 202302L
+struct A {
+ void f(this void); // expected-error {{explicit object parameter cannot have
'void' type}}
+};
+#endif
+}
+
namespace cwg2917 { // cwg2917: 20 review 2024-07-30
template
class Foo;
diff --git a/clang/www/cxx_dr_status.html b/clang/www/cxx_dr_status.html
index f036fc5add2413..127bfe7e0e3724 100755
--- a/clang/www/cxx_dr_status.html
+++ b/clang/www/cxx_dr_status.html
@@ -11809,11 +11809,11 @@ C++ defect report implementation
status
Reference list-initialization ignores conversion functions
Not resolved
-
+
https://cplusplus.github.io/CWG/issues/1997.html";>1997
-drafting
+DRWP
Placement new and previous initialization
-Not resolved
+Unknown
https://cplusplus.github.io/CWG/issues/1998.html";>1998
@@ -17346,11 +17346,15 @@ C++ defect report implementation
status
https://cplusplus.github.io/CWG/issues/2915.html";>2915
tentatively ready
Explicit object parameters of type void
-Not resolved
+
+
+Not resolved
+Clang 20 implements 2024-08-16 resolution
+
https://cplusplus.github.io/CWG/issues/2916.html";>2916
-tentatively ready
+review
Variable template partial specializat
[clang] [analyzer] Explicitly register NoStoreFuncVisitor from alpha.unix.cst… (PR #108373)
https://github.com/Szelethus updated
https://github.com/llvm/llvm-project/pull/108373
From cc823218d5cbb0b8f183bbadc9a32380c8e328a7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Krist=C3=B3f=20Umann?=
Date: Tue, 16 Jul 2024 15:06:06 +0200
Subject: [PATCH 1/2] [analyzer] Explicitly register NoStoreFuncVisitor from
alpha.unix.cstring.UninitRead
This is a drastic simplification of #106982.
The patch was inspired by a pretty poor bug report on FFMpeg:
https://codechecker-demo.eastus.cloudapp.azure.com/Default/report-detail?is-unique=on&run=curl_curl-7_66_0_cstring_uninit_baseline&run=ffmpeg_n4.3.1_cstring_uninit_baseline&run=memcached_1.6.8_cstring_uninit_baseline&run=openssl_openssl-3.0.0-alpha7_cstring_uninit_baseline&run=sqlite_version-3.33.0_cstring_uninit_baseline&run=tmux_2.6_cstring_uninit_baseline&run=twin_v0.8.1_cstring_uninit_baseline&run=vim_v8.2.1920_cstring_uninit_baseline&newcheck=curl_curl-7_66_0_cstring_uninit_final&newcheck=ffmpeg_n4.3.1_cstring_uninit_final&newcheck=memcached_1.6.8_cstring_uninit_final&newcheck=openssl_openssl-3.0.0-alpha7_cstring_uninit_final&newcheck=sqlite_version-3.33.0_cstring_uninit_final&newcheck=tmux_2.6_cstring_uninit_final&newcheck=twin_v0.8.1_cstring_uninit_final&newcheck=vim_v8.2.1920_cstring_uninit_final&diff-type=Unresolved&items-per-page=100&checker-name=alpha.unix.cstring.UninitializedRead&report-id=5766433&report-hash=82c63868ba782bfa216ee3f2b5734d6b&report-filepath=%2atiertexseqv.c
In this bug report, block is uninitialized, hence the bug report that it
should not have been passed to memcpy. The confusing part is in line 93,
where block was passed as a non-const pointer to seq_unpack_rle_block,
which was obviously meant to initialize block. As developers, we know
that clang likely didn't skip this function and found a path of
execution on which this initialization failed, but NoStoreFuncVisitor
failed to attach the usual "returning without writing to block" message.
I fixed this by instead of tracking the entire array, I tracked the
actual element which was found to be uninitialized (Remember, we
heuristically only check if the first and last-to-access element is
initialized, not the entire array). This is how the bug report looks
now:
https://codechecker-demo.eastus.cloudapp.azure.com/Default/report-detail?is-unique=on&run=curl_curl-7_66_0_cstring_uninit_baseline&run=ffmpeg_n4.3.1_cstring_uninit_baseline&run=memcached_1.6.8_cstring_uninit_baseline&run=openssl_openssl-3.0.0-alpha7_cstring_uninit_baseline&run=sqlite_version-3.33.0_cstring_uninit_baseline&run=tmux_2.6_cstring_uninit_baseline&run=twin_v0.8.1_cstring_uninit_baseline&run=vim_v8.2.1920_cstring_uninit_baseline&newcheck=curl_curl-7_66_0_cstring_uninit_final&newcheck=ffmpeg_n4.3.1_cstring_uninit_final&newcheck=memcached_1.6.8_cstring_uninit_final&newcheck=openssl_openssl-3.0.0-alpha7_cstring_uninit_final&newcheck=sqlite_version-3.33.0_cstring_uninit_final&newcheck=tmux_2.6_cstring_uninit_final&newcheck=twin_v0.8.1_cstring_uninit_final&newcheck=vim_v8.2.1920_cstring_uninit_final&diff-type=Unresolved&items-per-page=100&checker-name=alpha.unix.cstring.UninitializedRead&report-id=5768860&report-hash=82c63868ba782bfa216ee3f2b5734d6b&report-filepath=%2atiertexseqv.c
Since NoStoreFuncVisitor was a TU-local class, I moved it back to
BugReporterVisitors.h, and registered it manually in CStringChecker.cpp.
This was done because we don't have a good trackRegionValue() function,
only a trackExpressionValue() function. We have an expression for the
array, but not for its first (or last-to-access) element, so I only had
a MemRegion on hand.
---
.../Core/BugReporter/BugReporterVisitors.h| 85 ++
.../Core/PathSensitive/CheckerContext.h | 1 +
.../StaticAnalyzer/Core/PathSensitive/SVals.h | 2 +
.../Checkers/CStringChecker.cpp | 13 ++-
.../Core/BugReporterVisitors.cpp | 89 ---
clang/lib/StaticAnalyzer/Core/SVals.cpp | 17
.../test/Analysis/cstring-uninitread-notes.c | 25 ++
7 files changed, 139 insertions(+), 93 deletions(-)
create mode 100644 clang/test/Analysis/cstring-uninitread-notes.c
diff --git
a/clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitors.h
b/clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitors.h
index f97514955a5913..305622d81dc3e7 100644
--- a/clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitors.h
+++ b/clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitors.h
@@ -718,6 +718,91 @@ class NoStateChangeFuncVisitor : public BugReporterVisitor
{
PathSensitiveBugReport &R) final;
};
+/// Put a diagnostic on return statement of all inlined functions
+/// for which the region of interest \p RegionOfInterest was passed into,
+/// but not written inside, and it has caused an undefined read or a null
+/// pointer dereference outside.
+class NoStoreFuncVisitor final : public NoStateChangeFuncVisitor
[clang] [Clang] Reject "this void" (CWG2915) (PR #108817)
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Mital Ashok (MitalAshok)
Changes
https://cplusplus.github.io/CWG/issues/2915.html
Previously, `struct A { void f(this void); };` was accepted with `A::f` being a
member function with no non-object arguments, but it was still a little wonky
because it was still considered an explicit object member function. Now, this
is rejected immediately.
This applies to any language mode with explicit object parameters as this is a
DR (C++23 and C++26)
---
Full diff: https://github.com/llvm/llvm-project/pull/108817.diff
5 Files Affected:
- (modified) clang/docs/ReleaseNotes.rst (+3)
- (modified) clang/include/clang/Basic/DiagnosticSemaKinds.td (+2)
- (modified) clang/lib/Sema/SemaType.cpp (+8)
- (modified) clang/test/CXX/drs/cwg29xx.cpp (+8)
- (modified) clang/www/cxx_dr_status.html (+63-5)
``diff
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 485b75049927fe..9c87a0d002b4ac 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -170,6 +170,9 @@ Resolutions to C++ Defect Reports
in constant expressions. These comparisons always worked in non-constant
expressions.
(`CWG2749: Treatment of "pointer to void" for relational comparisons
`_).
+- Reject explicit object parameters with type ``void`` (``this void``).
+ (`CWG2915: Explicit object parameters of type void
`_).
+
C Language Changes
--
diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index d42558d2223aae..271f96e383e57d 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -4687,6 +4687,8 @@ def err_void_only_param : Error<
"'void' must be the first and only parameter if specified">;
def err_void_param_qualified : Error<
"'void' as parameter must not have type qualifiers">;
+def err_void_explicit_object_param : Error<
+ "explicit object parameter cannot have 'void' type">;
def err_ident_list_in_fn_declaration : Error<
"a parameter list without types is only allowed in a function definition">;
def ext_param_not_declared : ExtWarn<
diff --git a/clang/lib/Sema/SemaType.cpp b/clang/lib/Sema/SemaType.cpp
index e627fee51b66b8..7b99f5d13463fe 100644
--- a/clang/lib/Sema/SemaType.cpp
+++ b/clang/lib/Sema/SemaType.cpp
@@ -5166,6 +5166,14 @@ static TypeSourceInfo
*GetFullTypeForDeclarator(TypeProcessingState &state,
if (ParamTy.hasQualifiers())
S.Diag(DeclType.Loc, diag::err_void_param_qualified);
+ // Reject, but continue to parse 'float(this void)' as
+ // 'float(void)'.
+ if (Param->isExplicitObjectParameter()) {
+S.Diag(Param->getLocation(),
+ diag::err_void_explicit_object_param);
+Param->setExplicitObjectParameterLoc(SourceLocation());
+ }
+
// Do not add 'void' to the list.
break;
}
diff --git a/clang/test/CXX/drs/cwg29xx.cpp b/clang/test/CXX/drs/cwg29xx.cpp
index ca598bb39a6c31..e55e8e35e86f28 100644
--- a/clang/test/CXX/drs/cwg29xx.cpp
+++ b/clang/test/CXX/drs/cwg29xx.cpp
@@ -6,6 +6,14 @@
// RUN: %clang_cc1 -std=c++23 -pedantic-errors -verify=expected %s
// RUN: %clang_cc1 -std=c++2c -pedantic-errors -verify=expected %s
+namespace cwg2915 { // cwg2915: 20 tentatively ready 2024-08-16
+#if __cplusplus >= 202302L
+struct A {
+ void f(this void); // expected-error {{explicit object parameter cannot have
'void' type}}
+};
+#endif
+}
+
namespace cwg2917 { // cwg2917: 20 review 2024-07-30
template
class Foo;
diff --git a/clang/www/cxx_dr_status.html b/clang/www/cxx_dr_status.html
index f036fc5add2413..127bfe7e0e3724 100755
--- a/clang/www/cxx_dr_status.html
+++ b/clang/www/cxx_dr_status.html
@@ -11809,11 +11809,11 @@ C++ defect report implementation
status
Reference list-initialization ignores conversion functions
Not resolved
-
+
https://cplusplus.github.io/CWG/issues/1997.html";>1997
-drafting
+DRWP
Placement new and previous initialization
-Not resolved
+Unknown
https://cplusplus.github.io/CWG/issues/1998.html";>1998
@@ -17346,11 +17346,15 @@ C++ defect report implementation
status
https://cplusplus.github.io/CWG/issues/2915.html";>2915
tentatively ready
Explicit object parameters of type void
-Not resolved
+
+
+Not resolved
+Clang 20 implements 2024-08-16 resolution
+
https://cplusplus.github.io/CWG/issues/2916.html";>2916
-tentatively ready
+review
Variable template partial specializations should not be declared
static
Not resolved
@@ -17427,6 +17431,60 @@ C++ defect report implementation
status
open
Unclear status of tra
[clang] [AST] Iterate redecls starting from the canonical one in getRawCommentsForAnyRedecl() (PR #108475)
zyn0217 wrote:
@HighCommander4
I extended your test case a little to validate the `TemplateDeclKind` we would
have.
```cpp
struct FoundComment {
std::string DeclName;
bool IsDefinition;
std::string Comment;
comments::DeclInfo::TemplateDeclKind TDK;
// ... comparators are snipped ...
};
```
```cpp
Action.Comments.push_back(FoundComment{
ND->getNameAsString(), IsDefinition(D),
RC ? RC->getRawText(Ctx.getSourceManager()).str() : "",
RC->parse(Ctx, &Action.getCompilerInstance().getPreprocessor(), D)
->getDeclInfo()
->getTemplateKind()});
```
So for the following test case,
```cpp
/// Aaa.
template
void foo(T aaa, U bbb);
/// Bbb.
template<>
void foo(int aaa, int bbb);
```
I didn't see the following failing
```cpp
EXPECT_THAT(
Comments,
testing::ElementsAre(
FoundComment{"foo", false, "/// Aaa.",
comments::DeclInfo::TemplateDeclKind::Template},
FoundComment{
"foo", false, "/// Bbb.",
comments::DeclInfo::TemplateDeclKind::TemplateSpecialization}));
```
Did I misread anything from your last comment?
https://github.com/llvm/llvm-project/pull/108475
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] Fix OOM in FormatDiagnostic (PR #108187)
https://github.com/AaronBallman approved this pull request. LGTM! Do you need someone to land these changes on your behalf? https://github.com/llvm/llvm-project/pull/108187 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Make PCH's respect any VFS specified. (PR #106577)
@@ -1115,13 +1115,13 @@ void ASTWriter::WriteBlockInfoBlock() {
}
/// Prepares a path for being written to an AST file by converting it
-/// to an absolute path and removing nested './'s.
+/// to an absolute path and removing nested './'s and '../'s.
///
/// \return \c true if the path was changed.
static bool cleanPathForOutput(FileManager &FileMgr,
SmallVectorImpl &Path) {
bool Changed = FileMgr.makeAbsolutePath(Path);
- return Changed | llvm::sys::path::remove_dots(Path);
+ return Changed | llvm::sys::path::remove_dots(Path, true);
sheredom wrote:
You are right. We must have done this before using the VFS and not revisited.
Lemme undo this .. addition!
https://github.com/llvm/llvm-project/pull/106577
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Reject `this void` explicit object parameters (CWG2915) (PR #108817)
https://github.com/MitalAshok edited https://github.com/llvm/llvm-project/pull/108817 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [SPIRV][RFC] Rework / extend support for memory scopes (PR #106429)
@@ -251,6 +251,24 @@ SPIRV::MemorySemantics::MemorySemantics
getMemSemantics(AtomicOrdering Ord) {
llvm_unreachable(nullptr);
}
+SPIRV::Scope::Scope getMemScope(const LLVMContext &Ctx, SyncScope::ID ID) {
+ SmallVector SSNs;
+ Ctx.getSyncScopeNames(SSNs);
+
+ StringRef MemScope = SSNs[ID];
+ if (MemScope.empty() || MemScope == "all_svm_devices")
AlexVlx wrote:
On consideration, I think I'm with @arsenm on this one, both `singlethread` and
the empty string (system) have a defined meaning in LLVM, with all else being
target specific. So, IMHO, for these we actually should think about LLVM's
default, and how the target implements those, whilst for everything else we
should defer to the target.
https://github.com/llvm/llvm-project/pull/106429
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [analyzer] [MallocChecker] suspect all release functions as candidate for suppression (PR #104599)
https://github.com/Szelethus approved this pull request. LGTM! Do you have commit access? https://github.com/llvm/llvm-project/pull/104599 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [SPIRV][RFC] Rework / extend support for memory scopes (PR #106429)
@@ -58,7 +58,35 @@ class SPIRVTargetCodeGenInfo : public
CommonSPIRTargetCodeGenInfo {
SPIRVTargetCodeGenInfo(CodeGen::CodeGenTypes &CGT)
: CommonSPIRTargetCodeGenInfo(std::make_unique(CGT)) {}
void setCUDAKernelCallingConvention(const FunctionType *&FT) const override;
+ llvm::SyncScope::ID getLLVMSyncScopeID(const LangOptions &LangOpts,
+ SyncScope Scope,
+ llvm::AtomicOrdering Ordering,
+ llvm::LLVMContext &Ctx) const
override;
};
+
+inline StringRef mapClangSyncScopeToLLVM(SyncScope Scope) {
+ switch (Scope) {
+ case SyncScope::HIPSingleThread:
+ case SyncScope::SingleScope:
+return "singlethread";
+ case SyncScope::HIPWavefront:
+ case SyncScope::OpenCLSubGroup:
+ case SyncScope::WavefrontScope:
+return "subgroup";
+ case SyncScope::HIPWorkgroup:
+ case SyncScope::OpenCLWorkGroup:
+ case SyncScope::WorkgroupScope:
+return "workgroup";
+ case SyncScope::HIPAgent:
+ case SyncScope::OpenCLDevice:
+ case SyncScope::DeviceScope:
+return "device";
+ case SyncScope::SystemScope:
+ case SyncScope::HIPSystem:
+ case SyncScope::OpenCLAllSVMDevices:
+return "all_svm_devices";
AlexVlx wrote:
> +1, we should align on the scope string names. Since we may have different
> languages with different naming for the scope it makes sense to take names
> from the common specification eg SPIR-V. So probably we should rename
> `sub_group` (or `subgroup`) to `Subgroup` etc; and `singlethread` should be
> aliased with `Invocation`.
I'd object to using CamelCase for the IR representation (re-using the SPIR-V
naming is fine, which is where `subgroup` vs `sub_group` originated) on the
grounds that we don't really use that style anywhere else in IR, and other
targets have already gone snake_case.
https://github.com/llvm/llvm-project/pull/106429
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] handle invalid close location in static assert declaration (PR #108701)
https://github.com/AaronBallman approved this pull request. LGTM! https://github.com/llvm/llvm-project/pull/108701 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [SPIRV][RFC] Rework / extend support for memory scopes (PR #106429)
AlexVlx wrote: > @AlexVlx I don't see much objections against #108528 on a conceptual level, > so what do you think about merging it into this PR in a way that I commented > above, by changing `getMemScope()` and moving `getOrInsertSyncScopeID()` into > its static vars initialization? At a glance it seems fine, thank you for working through this, but since I've been away for a couple of days let me page things back in first:) https://github.com/llvm/llvm-project/pull/106429 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
