[clang] 66ab856 - [Driver] Fix compiler-rt lookup for x32
Author: Harald van Dijk
Date: 2021-07-15T20:52:25+01:00
New Revision: 66ab8568c485c4dd7461f1acf0e55cd4a7a3b4a0
URL:
https://github.com/llvm/llvm-project/commit/66ab8568c485c4dd7461f1acf0e55cd4a7a3b4a0
DIFF:
https://github.com/llvm/llvm-project/commit/66ab8568c485c4dd7461f1acf0e55cd4a7a3b4a0.diff
LOG: [Driver] Fix compiler-rt lookup for x32
x86_64-linux-gnu and x86_64-linux-gnux32 use different ABIs and objects
built for one cannot be used for the other. In order to build and use
compiler-rt for x32, we need to treat x32 as a new arch there. This
updates the driver to search using the new arch name.
Reviewed By: glaubitz
Differential Revision: https://reviews.llvm.org/D100148
Added:
Modified:
clang/lib/Driver/ToolChain.cpp
clang/test/Driver/sanitizer-ld.c
Removed:
diff --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index 5791805a6711b..63ddd2acbec15 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -383,6 +383,9 @@ static StringRef getArchNameForCompilerRTLib(const
ToolChain &TC,
if (TC.getArch() == llvm::Triple::x86 && Triple.isAndroid())
return "i686";
+ if (TC.getArch() == llvm::Triple::x86_64 && Triple.isX32())
+return "x32";
+
return llvm::Triple::getArchTypeName(TC.getArch());
}
diff --git a/clang/test/Driver/sanitizer-ld.c
b/clang/test/Driver/sanitizer-ld.c
index 46f8729e18676..5e89552345f67 100644
--- a/clang/test/Driver/sanitizer-ld.c
+++ b/clang/test/Driver/sanitizer-ld.c
@@ -284,28 +284,28 @@
// CHECK-MSAN-NO-LINK-RUNTIME-LINUX-NOT: libclang_rt.msan
// RUN: %clang -fsanitize=undefined %s -### -o %t.o 2>&1 \
-// RUN: -target i386-unknown-linux -fuse-ld=ld \
+// RUN: -target x86_64-unknown-linux-gnux32 -fuse-ld=ld \
// RUN: -resource-dir=%S/Inputs/resource_dir \
-// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN: --sysroot=%S/Inputs/multilib_64bit_linux_tree \
// RUN: | FileCheck --check-prefix=CHECK-UBSAN-LINUX %s
// RUN: %clang -fsanitize=float-divide-by-zero %s -### -o %t.o 2>&1 \
-// RUN: -target i386-unknown-linux -fuse-ld=ld \
+// RUN: -target x86_64-unknown-linux-gnux32 -fuse-ld=ld \
// RUN: -resource-dir=%S/Inputs/resource_dir \
-// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN: --sysroot=%S/Inputs/multilib_64bit_linux_tree \
// RUN: | FileCheck --check-prefix=CHECK-UBSAN-LINUX %s
// RUN: %clang -fsanitize=undefined %s -### -o %t.o 2>&1 \
-// RUN: -target i386-unknown-linux -fuse-ld=ld \
+// RUN: -target x86_64-unknown-linux-gnux32 -fuse-ld=ld \
// RUN: -resource-dir=%S/Inputs/resource_dir \
-// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN: --sysroot=%S/Inputs/multilib_64bit_linux_tree \
// RUN: -static-libsan \
// RUN: | FileCheck --check-prefix=CHECK-UBSAN-LINUX %s
// CHECK-UBSAN-LINUX: "{{.*}}ld{{(.exe)?}}"
// CHECK-UBSAN-LINUX-NOT: libclang_rt.asan
// CHECK-UBSAN-LINUX-NOT: libclang_rt.ubsan_standalone_cxx
-// CHECK-UBSAN-LINUX: "--whole-archive"
"{{.*}}libclang_rt.ubsan_standalone-i386.a" "--no-whole-archive"
+// CHECK-UBSAN-LINUX: "--whole-archive"
"{{.*}}libclang_rt.ubsan_standalone-x32.a" "--no-whole-archive"
// CHECK-UBSAN-LINUX-NOT: libclang_rt.asan
// CHECK-UBSAN-LINUX-NOT: libclang_rt.ubsan_standalone_cxx
// CHECK-UBSAN-LINUX-NOT: "-lstdc++"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] fed7be0 - Mark identifier prefixes as substitutable
Author: Harald van Dijk
Date: 2022-05-02T18:07:47+01:00
New Revision: fed7be096f8ed5d70029acd712ac19ffc61e04e5
URL:
https://github.com/llvm/llvm-project/commit/fed7be096f8ed5d70029acd712ac19ffc61e04e5
DIFF:
https://github.com/llvm/llvm-project/commit/fed7be096f8ed5d70029acd712ac19ffc61e04e5.diff
LOG: Mark identifier prefixes as substitutable
The Itanium C++ ABI says prefixes are substitutable. For most prefixes
we already handle this: the manglePrefix(const DeclContext *, bool) and
manglePrefix(QualType) overloads explicitly handles substitutions or
defer to functions that handle substitutions on their behalf. The
manglePrefix(NestedNameSpecifier *) overload, however, is different and
handles some cases implicitly, but not all. The Identifier case was not
handled; this change adds handling for it, as well as a test case.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D122663
Added:
Modified:
clang/docs/ReleaseNotes.rst
clang/include/clang/Basic/LangOptions.h
clang/lib/AST/ItaniumMangle.cpp
clang/lib/Frontend/CompilerInvocation.cpp
clang/test/CodeGenCXX/clang-abi-compat.cpp
clang/test/CodeGenCXX/mangle.cpp
Removed:
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 839a7035a94fd..855d1a6c41468 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -265,6 +265,10 @@ C++ Language Changes in Clang
``std::move_if_noexcept``, ``std::addressof``, and ``std::as_const``. These
are now treated as compiler builtins and implemented directly, rather than
instantiating the definition from the standard library.
+- Fixed mangling of nested dependent names such as ``T::a::b``, where ``T`` is
a
+ template parameter, to conform to the Itanium C++ ABI and be compatible with
+ GCC. This breaks binary compatibility with code compiled with earlier
versions
+ of clang; use the ``-fclang-abi-compat=14`` option to get the old mangling.
C++20 Feature Support
^
diff --git a/clang/include/clang/Basic/LangOptions.h
b/clang/include/clang/Basic/LangOptions.h
index eb4c7c4c7d93e..83b8c062aa65c 100644
--- a/clang/include/clang/Basic/LangOptions.h
+++ b/clang/include/clang/Basic/LangOptions.h
@@ -218,6 +218,10 @@ class LangOptions : public LangOptionsBase {
/// This causes clang to not pack non-POD members of packed structs.
Ver13,
+/// Attempt to be ABI-compatible with code generated by Clang 14.0.x.
+/// This causes clang to mangle dependent nested names incorrectly.
+Ver14,
+
/// Conform to the underlying platform's C and C++ ABIs as closely
/// as we can.
Latest
diff --git a/clang/lib/AST/ItaniumMangle.cpp b/clang/lib/AST/ItaniumMangle.cpp
index 75f072168858b..f72789da526c1 100644
--- a/clang/lib/AST/ItaniumMangle.cpp
+++ b/clang/lib/AST/ItaniumMangle.cpp
@@ -443,6 +443,7 @@ class CXXNameMangler {
private:
bool mangleSubstitution(const NamedDecl *ND);
+ bool mangleSubstitution(NestedNameSpecifier *NNS);
bool mangleSubstitution(QualType T);
bool mangleSubstitution(TemplateName Template);
bool mangleSubstitution(uintptr_t Ptr);
@@ -456,6 +457,11 @@ class CXXNameMangler {
addSubstitution(reinterpret_cast(ND));
}
+ void addSubstitution(NestedNameSpecifier *NNS) {
+NNS = Context.getASTContext().getCanonicalNestedNameSpecifier(NNS);
+
+addSubstitution(reinterpret_cast(NNS));
+ }
void addSubstitution(QualType T);
void addSubstitution(TemplateName Template);
void addSubstitution(uintptr_t Ptr);
@@ -2036,12 +2042,21 @@ void CXXNameMangler::manglePrefix(NestedNameSpecifier
*qualifier) {
return;
case NestedNameSpecifier::Identifier:
+// Clang 14 and before did not consider this substitutable.
+bool Clang14Compat = getASTContext().getLangOpts().getClangABICompat() <=
+ LangOptions::ClangABI::Ver14;
+if (!Clang14Compat && mangleSubstitution(qualifier))
+ return;
+
// Member expressions can have these without prefixes, but that
// should end up in mangleUnresolvedPrefix instead.
assert(qualifier->getPrefix());
manglePrefix(qualifier->getPrefix());
mangleSourceName(qualifier->getAsIdentifier());
+
+if (!Clang14Compat)
+ addSubstitution(qualifier);
return;
}
@@ -6009,6 +6024,14 @@ bool CXXNameMangler::mangleSubstitution(const NamedDecl
*ND) {
return mangleSubstitution(reinterpret_cast(ND));
}
+bool CXXNameMangler::mangleSubstitution(NestedNameSpecifier *NNS) {
+ assert(NNS->getKind() == NestedNameSpecifier::Identifier &&
+ "mangleSubstitution(NestedNameSpecifier *) is only used for "
+ "identifier nested name specifiers.");
+ NNS = Context.getASTContext().getCanonicalNestedNameSpecifier(NNS);
+ return mangleSubstitution(reinterpret_cast(NNS));
+}
+
/// Determine whether the given type has any qualifiers
[clang] [Clang][Sema]: Allow flexible arrays in unions and alone in structs (PR #84428)
@@ -1,13 +1,58 @@
-// RUN: %clang_cc1 %s -verify=c -fsyntax-only
+// RUN: %clang_cc1 %s -verify -fsyntax-only
// RUN: %clang_cc1 %s -verify -fsyntax-only -x c++
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility
// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility -x c++
+// RUN: %clang_cc1 %s -verify=gnu -fsyntax-only
-Wgnu-flexible-array-union-member -Wgnu-empty-struct
+// RUN: %clang_cc1 %s -verify=microsoft -fsyntax-only -fms-compatibility
-Wmicrosoft
// The test checks that an attempt to initialize union with flexible array
// member with an initializer list doesn't crash clang.
-union { char x[]; } r = {0}; // c-error {{flexible array member 'x' in a union
is not allowed}}
+union { char x[]; } r = {0}; /* gnu-warning {{flexible array member 'x' in a
union is a GNU extension}}
+microsoft-warning {{flexible array member 'x'
in a union is a Microsoft extension}}
+ */
hvdijk wrote:
If this is no longer an error, and the primary use case of this is for unions
that are members of other structures, what are the semantics for initialization
of flexible array members in unions in other structures? Is this covered
sufficiently by existing tests?
https://github.com/llvm/llvm-project/pull/84428
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][Sema]: Allow flexible arrays in unions and alone in structs (PR #84428)
@@ -1,13 +1,58 @@
-// RUN: %clang_cc1 %s -verify=c -fsyntax-only
+// RUN: %clang_cc1 %s -verify -fsyntax-only
// RUN: %clang_cc1 %s -verify -fsyntax-only -x c++
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility
// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility -x c++
+// RUN: %clang_cc1 %s -verify=gnu -fsyntax-only
-Wgnu-flexible-array-union-member -Wgnu-empty-struct
+// RUN: %clang_cc1 %s -verify=microsoft -fsyntax-only -fms-compatibility
-Wmicrosoft
// The test checks that an attempt to initialize union with flexible array
// member with an initializer list doesn't crash clang.
-union { char x[]; } r = {0}; // c-error {{flexible array member 'x' in a union
is not allowed}}
+union { char x[]; } r = {0}; /* gnu-warning {{flexible array member 'x' in a
union is a GNU extension}}
+microsoft-warning {{flexible array member 'x'
in a union is a Microsoft extension}}
+ */
hvdijk wrote:
I do not see any obvious cases where the code does the wrong thing, sure, I
agree with you on that, but as far as I can find, we do not have *any* test for
"initialization of flexible array member is not allowed" being correctly
emitted for nested unions containing flexible array members, either currently
or after this PR. `flexible-array-init.c` contains tests for this for nested
structs containing flexible array members, but not for unions. Previously,
these would have implicitly been handled by flexible array members being
disallowed in unions in the first place, at least for C, but as you are
enabling them now, that no longer applies.
https://github.com/llvm/llvm-project/pull/84428
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][Sema]: Allow flexible arrays in unions and alone in structs (PR #84428)
@@ -1,13 +1,158 @@
-// RUN: %clang_cc1 %s -verify=c -fsyntax-only
-// RUN: %clang_cc1 %s -verify -fsyntax-only -x c++
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility -x c++
+// RUN: %clang_cc1 %s -verify=stock,c -fsyntax-only
+// RUN: %clang_cc1 %s -verify=stock,cpp -fsyntax-only -x c++
+// RUN: %clang_cc1 %s -verify=stock,cpp -fsyntax-only -fms-compatibility -x c++
+// RUN: %clang_cc1 %s -verify=stock,c,gnu -fsyntax-only
-Wgnu-flexible-array-union-member -Wgnu-empty-struct
+// RUN: %clang_cc1 %s -verify=stock,c,microsoft -fsyntax-only
-fms-compatibility -Wmicrosoft
// The test checks that an attempt to initialize union with flexible array
// member with an initializer list doesn't crash clang.
-union { char x[]; } r = {0}; // c-error {{flexible array member 'x' in a union
is not allowed}}
+union { char x[]; } r = {0}; /* gnu-warning {{flexible array member 'x' in a
union is a GNU extension}}
+microsoft-warning {{flexible array member 'x'
in a union is a Microsoft extension}}
+ */
+struct _name1 {
+ int a;
+ union {
+int b;
+char x[]; /* gnu-warning {{flexible array member 'x' in a union is a GNU
extension}}
+ microsoft-warning {{flexible array member 'x' in a union is a
Microsoft extension}}
+ */
+ };
+} name1 = {
+ 10,
+ 42,/* initializes "b" */
+};
-// expected-no-diagnostics
+struct _name1i {
+ int a;
+ union {
+int b;
+char x[]; /* gnu-warning {{flexible array member 'x' in a union is a GNU
extension}}
+ microsoft-warning {{flexible array member 'x' in a union is a
Microsoft extension}}
+ */
+ };
+} name1i = {
+ .a = 10,
+ .b = 42,
+};
+
+/* Initialization of flexible array in a union is never allowed. */
+struct _name2 {
+ int a;
+ union {
+int b;
+char x[]; /* gnu-warning {{flexible array member 'x' in a union is a GNU
extension}}
+ microsoft-warning {{flexible array member 'x' in a union is a
Microsoft extension}}
+ stock-note {{initialized flexible array member 'x' is here}}
+ */
+ };
+} name2 = {
+ 12,
+ 13,
+ { 'c' }, /* stock-error {{initialization of flexible array member is not
allowed}} */
hvdijk wrote:
I think this is more than just a confusing error message. Consider `struct S {
int a; union { int b; char x[]; }; int c; } s = {1, 2, 3};`. If `x` is given
type `char[0]`, or `char[1]`, or `char[2]`, the `3` initializer applies to
`s.c`. Yet inexplicably, if `x` has type `char[]`, the `3` initializer applies
to `s.x` and any initializer is an error? That looks like a bug. We can even
turn this into wrong-code: `struct S { int a; union { int b; char x[]; }; int
c; int d; } s = {1, 2, {}, 3};`. This should initialise `a`, `b`, `c`, `d`, to
`1`, `2`, `0`, `3`, but instead initialises them to `1`, `2`, `3`, `0`.
https://github.com/llvm/llvm-project/pull/84428
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][Sema]: Allow flexible arrays in unions and alone in structs (PR #84428)
hvdijk wrote:
The problem with `union { char x[]; } x = {0};` is in
`ConstStructBuilder::Build` ( `clang/lib/CodeGen/CGExprConstant.cpp`). It does:
```diff
// If this is a union, skip all the fields that aren't being initialized.
if (RD->isUnion() &&
!declaresSameEntity(ILE->getInitializedFieldInUnion(), Field))
continue;
```
But `ILE->getInitializedFieldInUnion()` returns `nullptr` so this skips all
fields. `nullptr` is returned because `InitListChecker::CheckStructUnionTypes`
never calls `StructuredList->setInitializedFieldInUnion`. If that gets called,
then things work.
I think things can be simplified a bit further: if we do
```diff
diff --git a/clang/lib/Sema/SemaInit.cpp b/clang/lib/Sema/SemaInit.cpp
index 79cf2eed46fe..3fcdf9118468 100644
--- a/clang/lib/Sema/SemaInit.cpp
+++ b/clang/lib/Sema/SemaInit.cpp
@@ -2332,7 +2332,7 @@ void InitListChecker::CheckStructUnionTypes(
// We've already initialized a member of a union. We're done.
if (InitializedSomething && RD->isUnion())
- break;
+ return;
// If we've hit the flexible array member at the end, we're done.
if (Field->getType()->isIncompleteArrayType())
```
Then the tests still pass and we can remove or simplify some of the later
checks for unions.
https://github.com/llvm/llvm-project/pull/84428
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][Sema]: Allow flexible arrays in unions and alone in structs (PR #84428)
hvdijk wrote: Flexible array initialization is, roughly, implemented as building a different type in which the flexible array member is replaced by an array of the right size, initializing that, and then pretending it was the original type. It does not surprise me too much that this does not work in constant expressions, that generally does not play well with any form of type punning, even otherwise well-defined type punning. https://github.com/llvm/llvm-project/pull/84428 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][Sema] Allow flexible arrays in unions and alone in structs (PR #84428)
@@ -21,10 +27,76 @@ struct __attribute((packed, aligned(4))) { char a; int x;
char z[]; } e = { 1, 2
struct { int x; char y[]; } f = { 1, { 13, 15 } };
// CHECK: @f ={{.*}} global <{ i32, [2 x i8] }> <{ i32 1, [2 x i8] c"\0D\0F" }>
-union {
- struct {
-int a;
-char b[];
- } x;
-} in_union = {};
-// CHECK: @in_union ={{.*}} global %union.anon zeroinitializer
+struct __attribute((packed)) { short a; char z[]; } g = { 2, { 11, 13, 15 } };
+// CHECK: @g ={{.*}} <{ i16, [3 x i8] }> <{ i16 2, [3 x i8] c"\0B\0D\0F" }>,
+
+// Last member is the potential flexible array, unnamed initializer skips it.
+struct { int a; union { int b; short x; }; int c; int d; } h = {1, 2, {}, 3};
+// CHECK: @h = global %struct.anon{{.*}} { i32 1, %union.anon{{.*}} { i32 2 },
i32 0, i32 3 }
+struct { int a; union { int b; short x[0]; }; int c; int d; } h0 = {1, 2, {},
3};
+// CHECK: @h0 = global %struct.anon{{.*}} { i32 1, %union.anon{{.*}} { i32 2
}, i32 0, i32 3 }
+struct { int a; union { int b; short x[1]; }; int c; int d; } h1 = {1, 2, {},
3};
+// CHECK: @h1 = global %struct.anon{{.*}} { i32 1, %union.anon{{.*}} { i32 2
}, i32 0, i32 3 }
+struct {
+ int a;
+ union {
+int b;
+struct {
+ struct { } __ununsed;
+ short x[];
+};
+ };
+ int c;
+ int d;
+} hiding = {1, 2, {}, 3};
+// CHECK: @hiding = global %struct.anon{{.*}} { i32 1, %union.anon{{.*}} { i32
2 }, i32 0, i32 3 }
+struct { int a; union { int b; short x[]; }; int c; int d; } hf = {1, 2, {},
3};
+// CHECK: @hf = global %struct.anon{{.*}} { i32 1, %union.anon{{.*}} { i32 2
}, i32 0, i32 3 }
+
+// First member is the potential flexible array, initialization requires
braces.
+struct { int a; union { short x; int b; }; int c; int d; } i = {1, 2, {}, 3};
+// CHECK: @i = global { i32, { i16, [2 x i8] }, i32, i32 } { i32 1, { i16, [2
x i8] } { i16 2, [2 x i8] undef }, i32 0, i32 3 }
+struct { int a; union { short x[0]; int b; }; int c; int d; } i0 = {1, {}, 2,
3};
+// CHECK: @i0 = global { i32, { [0 x i16], [4 x i8] }, i32, i32 } { i32 1, {
[0 x i16], [4 x i8] } { [0 x i16] zeroinitializer, [4 x i8] undef }, i32 2, i32
3 }
+struct { int a; union { short x[1]; int b; }; int c; int d; } i1 = {1, {2},
{}, 3};
+// CHECK: @i1 = global { i32, { [1 x i16], [2 x i8] }, i32, i32 } { i32 1, {
[1 x i16], [2 x i8] } { [1 x i16] [i16 2], [2 x i8] undef }, i32 0, i32 3 }
+struct { int a; union { short x[]; int b; }; int c; int d; } i_f = {4, {}, {},
6};
+// CHECK: @i_f = global { i32, { [0 x i16], [4 x i8] }, i32, i32 } { i32 4, {
[0 x i16], [4 x i8] } { [0 x i16] zeroinitializer, [4 x i8] undef }, i32 0, i32
6 }
+
+// Named initializers; order doesn't matter.
+struct { int a; union { int b; short x; }; int c; int d; } hn = {.a = 1, .x =
2, .c = 3};
+// CHECK: @hn = global { i32, { i16, [2 x i8] }, i32, i32 } { i32 1, { i16, [2
x i8] } { i16 2, [2 x i8] undef }, i32 3, i32 0 }
+struct { int a; union { int b; short x[0]; }; int c; int d; } hn0 = {.a = 1,
.x = {2}, .c = 3};
+// CHECK: @hn0 = global { i32, { [0 x i16], [4 x i8] }, i32, i32 } { i32 1, {
[0 x i16], [4 x i8] } { [0 x i16] zeroinitializer, [4 x i8] undef }, i32 3, i32
0 }
+struct { int a; union { int b; short x[1]; }; int c; int d; } hn1 = {.a = 1,
.x = {2}, .c = 3};
+// CHECK: @hn1 = global { i32, { [1 x i16], [2 x i8] }, i32, i32 } { i32 1, {
[1 x i16], [2 x i8] } { [1 x i16] [i16 2], [2 x i8] undef }, i32 3, i32 0 }
+
+struct { char a[]; } empty_struct = {};
+// CHECK: @empty_struct ={{.*}} global %struct.anon{{.*}} zeroinitializer,
align 1
+
+struct { char a[]; } empty_struct0 = {0};
+// CHECK: @empty_struct0 = global { [1 x i8] } zeroinitializer, align 1
+
+union { struct { int a; char b[]; }; } struct_in_union = {};
+// CHECK: @struct_in_union = global %union.anon{{.*}} zeroinitializer, align 4
+
+union { struct { int a; char b[]; }; } struct_in_union0 = {0};
+// CHECK: @struct_in_union0 = global %union.anon{{.*}} zeroinitializer, align 4
+
+union { int a; char b[]; } trailing_in_union = {};
+// CHECK: @trailing_in_union = global %union.anon{{.*}} zeroinitializer, align
4
+
+union { int a; char b[]; } trailing_in_union0 = {0};
+// CHECK: @trailing_in_union0 = global %union.anon{{.*}} zeroinitializer,
align 4
+
+union { char a[]; } only_in_union = {};
+// CHECK: @only_in_union = global %union.anon{{.*}} zeroinitializer, align 1
+
+union { char a[]; } only_in_union0 = {0};
+// CHECK: @only_in_union0 = global { [1 x i8] } zeroinitializer, align 1
+
+union { char a[]; int b; } first_in_union = {};
+// CHECK: @first_in_union = global { [0 x i8], [4 x i8] } { [0 x i8]
zeroinitializer, [4 x i8] undef }, align 4
+
+union { char a[]; int b; } first_in_union0 = {};
+// CHECK: @first_in_union0 = global { [0 x i8], [4 x i8] } { [0 x i8]
zeroinitializer, [4 x i8] undef }, align 4
hvdijk wrote:
This is identical to the `first_in_union` test, I think you want
```suggestion
union { char a[]; int b; } first_in_union0 = {0};
// CHECK: @first
[clang] [Clang][Sema] Allow flexible arrays in unions and alone in structs (PR #84428)
https://github.com/hvdijk approved this pull request. Looks good to me, thanks, aside from one typo in the release notes. Let me pre-emptively mark this as approved. Just to confirm, the warnings are also enabled by `-pedantic`? Is that worth mentioning in the release notes too? I'm fine if you want to leave that though. https://github.com/llvm/llvm-project/pull/84428 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][Sema] Allow flexible arrays in unions and alone in structs (PR #84428)
@@ -271,6 +271,9 @@ Improvements to Clang's diagnostics - Clang now correctly diagnoses no arguments to a variadic macro parameter as a C23/C++20 extension. Fixes #GH84495. +- ``-Wmicrosoft`` or ``-Wgnu`` is now required to diagnose C99 flexible + array members in a union or alone in a struct. Fixes #GB84565. hvdijk wrote: Should be #GH rather than #GB. https://github.com/llvm/llvm-project/pull/84428 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Revert "[X86][clang] Lift _BitInt() supported max width." (PR #81175)
https://github.com/hvdijk created
https://github.com/llvm/llvm-project/pull/81175
This reverts commit def720726b73e0d7ab139376ab3ea955f25f4d89.
As noted in #60925 and in D86310, with the current implementation of `_BitInt`
in Clang, we can have either a correct `__int128` implementation, or a correct
`_BitInt(128)` implementation, but not both: having a correct `__int128`
implementation results in a mostly-working `_BitInt(65-128)` type, but internal
compiler errors and seriously wrong code for `_BitInt(129+)`. The currently
specified ABI is not implementable on top of LLVM's integer types, and attempts
to get the ABI changed to something we can implement have resulted in nothing,
so I think the safest thing to do at this time is to make sure Clang reports
this as an error in exactly the same way that it does for all other
architectures. I think it was simply too soon to lift that restriction.
cc @FreddyLeaf
>From 7b8f198b3bb00ca0624e7de061a977e1d3b87c00 Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Thu, 8 Feb 2024 19:06:14 +
Subject: [PATCH] Revert "[X86][clang] Lift _BitInt() supported max width."
This reverts commit def720726b73e0d7ab139376ab3ea955f25f4d89.
---
clang/docs/ReleaseNotes.rst | 2 ++
clang/lib/Basic/Targets/X86.h | 6 --
clang/test/Analysis/bitint-no-crash.c | 5 ++---
clang/test/CodeGen/ext-int-cc.c | 16
4 files changed, 12 insertions(+), 17 deletions(-)
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 32440ee64e3eb..a52e0c0112ba2 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -239,6 +239,8 @@ AMDGPU Support
X86 Support
^^^
+- Revert _BitInt() supported max width increase, which does not work properly.
+
Arm and AArch64 Support
^^^
diff --git a/clang/lib/Basic/Targets/X86.h b/clang/lib/Basic/Targets/X86.h
index d2232c7d5275a..7010c1fbb5a4e 100644
--- a/clang/lib/Basic/Targets/X86.h
+++ b/clang/lib/Basic/Targets/X86.h
@@ -507,9 +507,6 @@ class LLVM_LIBRARY_VISIBILITY X86_32TargetInfo : public
X86TargetInfo {
ArrayRef getTargetBuiltins() const override;
bool hasBitIntType() const override { return true; }
- size_t getMaxBitIntWidth() const override {
-return llvm::IntegerType::MAX_INT_BITS;
- }
};
class LLVM_LIBRARY_VISIBILITY NetBSDI386TargetInfo
@@ -820,9 +817,6 @@ class LLVM_LIBRARY_VISIBILITY X86_64TargetInfo : public
X86TargetInfo {
ArrayRef getTargetBuiltins() const override;
bool hasBitIntType() const override { return true; }
- size_t getMaxBitIntWidth() const override {
-return llvm::IntegerType::MAX_INT_BITS;
- }
};
// x86-64 Windows target
diff --git a/clang/test/Analysis/bitint-no-crash.c
b/clang/test/Analysis/bitint-no-crash.c
index 0a367fa930dc9..aa9bd61e7e421 100644
--- a/clang/test/Analysis/bitint-no-crash.c
+++ b/clang/test/Analysis/bitint-no-crash.c
@@ -1,10 +1,9 @@
// RUN: %clang_analyze_cc1 -analyzer-checker=core \
// RUN: -analyzer-checker=debug.ExprInspection \
- // RUN: -triple x86_64-pc-linux-gnu \
+ // RUN: -fexperimental-max-bitint-width=256 \
// RUN: -verify %s
-// Don't crash when using _BitInt(). Pin to the x86_64 triple for now,
-// since not all architectures support _BitInt()
+// Don't crash when using _BitInt().
// expected-no-diagnostics
_BitInt(256) a;
_BitInt(129) b;
diff --git a/clang/test/CodeGen/ext-int-cc.c b/clang/test/CodeGen/ext-int-cc.c
index 001e866d34b45..b233285ea36da 100644
--- a/clang/test/CodeGen/ext-int-cc.c
+++ b/clang/test/CodeGen/ext-int-cc.c
@@ -131,10 +131,10 @@ void ParamPassing3(_BitInt(15) a, _BitInt(31) b) {}
// are negated. This will give an error when a target does support larger
// _BitInt widths to alert us to enable the test.
void ParamPassing4(_BitInt(129) a) {}
-// LIN64: define{{.*}} void @ParamPassing4(ptr byval(i129) align 8 %{{.+}})
-// WIN64: define dso_local void @ParamPassing4(ptr %{{.+}})
-// LIN32: define{{.*}} void @ParamPassing4(ptr %{{.+}})
-// WIN32: define dso_local void @ParamPassing4(ptr %{{.+}})
+// LIN64-NOT: define{{.*}} void @ParamPassing4(ptr byval(i129) align 8 %{{.+}})
+// WIN64-NOT: define dso_local void @ParamPassing4(ptr %{{.+}})
+// LIN32-NOT: define{{.*}} void @ParamPassing4(ptr %{{.+}})
+// WIN32-NOT: define dso_local void @ParamPassing4(ptr %{{.+}})
// NACL-NOT: define{{.*}} void @ParamPassing4(ptr byval(i129) align 8 %{{.+}})
// NVPTX64-NOT: define{{.*}} void @ParamPassing4(ptr byval(i129) align 8
%{{.+}})
// NVPTX-NOT: define{{.*}} void @ParamPassing4(ptr byval(i129) align 8 %{{.+}})
@@ -290,10 +290,10 @@ _BitInt(128) ReturnPassing4(void){}
#if __BITINT_MAXWIDTH__ > 128
_BitInt(129) ReturnPassing5(void){}
-// LIN64: define{{.*}} void @ReturnPassing5(ptr dead_on_unwind noalias
writable sret
-// WIN64: define dso_local void @ReturnPassing5(ptr dead_on_unwind noalias
writable sret
-// LIN32: define{{.*}} void @ReturnPassing5(ptr dead_on_unwind noalias
wri
[clang] Revert "[X86][clang] Lift _BitInt() supported max width." (PR #81175)
hvdijk wrote: > I would really like to avoid Clang 18 being released in this broken state, if > possible, and I see no way short of a revert to realistically achieve that. It's too late for that now, it's out there, and it's now everybody else's problem regardless of what Clang does in the future. Because of that, this PR no longer serves its purpose. I cannot imagine that even a single user will be happy with this, but this is what you decided. So be it. https://github.com/llvm/llvm-project/pull/81175 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Revert "[X86][clang] Lift _BitInt() supported max width." (PR #81175)
https://github.com/hvdijk closed https://github.com/llvm/llvm-project/pull/81175 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] f453793 - Suppress non-conforming GNU paste extension in all standard-conforming modes
Author: Harald van Dijk Date: 2021-01-25T00:56:45Z New Revision: f4537935dcdbf390c863591cf556e76c3abab9c1 URL: https://github.com/llvm/llvm-project/commit/f4537935dcdbf390c863591cf556e76c3abab9c1 DIFF: https://github.com/llvm/llvm-project/commit/f4537935dcdbf390c863591cf556e76c3abab9c1.diff LOG: Suppress non-conforming GNU paste extension in all standard-conforming modes The GNU token paste extension that removes the comma in , ## __VA_ARGS__ conflicts with C99/C++11's requirements when a variadic macro has no named parameters: according to the standard, an invocation as FOO() gives it a single empty argument, and concatenation of anything with an empty argument is well-defined. For this reason, the GNU extension was already disabled in C99 standard-conforming mode. It was not yet disabled in C++11 standard-conforming mode. The associated comment suggested that GCC keeps this extension enabled in C90/C++03 standard-conforming mode, but it actually does not, so rather than adding a check for C++ language version, this change simply removes the check for C language version. Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D91913 Added: Modified: clang/lib/Lex/TokenLexer.cpp clang/test/Preprocessor/macro_fn_comma_swallow2.c Removed: diff --git a/clang/lib/Lex/TokenLexer.cpp b/clang/lib/Lex/TokenLexer.cpp index da5681aaf478..6e962dfa2c34 100644 --- a/clang/lib/Lex/TokenLexer.cpp +++ b/clang/lib/Lex/TokenLexer.cpp @@ -148,12 +148,11 @@ bool TokenLexer::MaybeRemoveCommaBeforeVaArgs( return false; // GCC removes the comma in the expansion of " ... , ## __VA_ARGS__ " if - // __VA_ARGS__ is empty, but not in strict C99 mode where there are no - // named arguments, where it remains. In all other modes, including C99 - // with GNU extensions, it is removed regardless of named arguments. + // __VA_ARGS__ is empty, but not in strict mode where there are no + // named arguments, where it remains. With GNU extensions, it is removed + // regardless of named arguments. // Microsoft also appears to support this extension, unofficially. - if (PP.getLangOpts().C99 && !PP.getLangOpts().GNUMode -&& Macro->getNumParams() < 2) + if (!PP.getLangOpts().GNUMode && Macro->getNumParams() < 2) return false; // Is a comma available to be removed? diff --git a/clang/test/Preprocessor/macro_fn_comma_swallow2.c b/clang/test/Preprocessor/macro_fn_comma_swallow2.c index 93ab2b83664a..89ef8c0579c4 100644 --- a/clang/test/Preprocessor/macro_fn_comma_swallow2.c +++ b/clang/test/Preprocessor/macro_fn_comma_swallow2.c @@ -1,9 +1,12 @@ // Test the __VA_ARGS__ comma swallowing extensions of various compiler dialects. // RUN: %clang_cc1 -E %s | FileCheck -check-prefix=GCC -strict-whitespace %s +// RUN: %clang_cc1 -E -std=c90 %s | FileCheck -check-prefix=C99 -strict-whitespace %s // RUN: %clang_cc1 -E -std=c99 %s | FileCheck -check-prefix=C99 -strict-whitespace %s // RUN: %clang_cc1 -E -std=c11 %s | FileCheck -check-prefix=C99 -strict-whitespace %s // RUN: %clang_cc1 -E -x c++ %s | FileCheck -check-prefix=GCC -strict-whitespace %s +// RUN: %clang_cc1 -E -x c++ -std=c++03 %s | FileCheck -check-prefix=C99 -strict-whitespace %s +// RUN: %clang_cc1 -E -x c++ -std=c++11 %s | FileCheck -check-prefix=C99 -strict-whitespace %s // RUN: %clang_cc1 -E -std=gnu99 %s | FileCheck -check-prefix=GCC -strict-whitespace %s // RUN: %clang_cc1 -E -fms-compatibility %s | FileCheck -check-prefix=MS -strict-whitespace %s // RUN: %clang_cc1 -E -DNAMED %s | FileCheck -check-prefix=GCC -strict-whitespace %s ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 75521bd - [X32] Add Triple::isX32(), use it.
Author: Harald van Dijk
Date: 2021-06-07T20:48:39+01:00
New Revision: 75521bd9d8d1e39b1a765a14d95c49291d2adde5
URL:
https://github.com/llvm/llvm-project/commit/75521bd9d8d1e39b1a765a14d95c49291d2adde5
DIFF:
https://github.com/llvm/llvm-project/commit/75521bd9d8d1e39b1a765a14d95c49291d2adde5.diff
LOG: [X32] Add Triple::isX32(), use it.
So far, support for x86_64-linux-gnux32 has been handled by explicit
comparisons of Triple.getEnvironment() to GNUX32. This worked as long as
x86_64-linux-gnux32 was the only X32 environment to worry about, but we
now have x86_64-linux-muslx32 as well. To support this, this change adds
an isX32() function and uses it. It replaces all checks for GNUX32 or
MuslX32 by isX32(), except for the following:
- Triple::isGNUEnvironment() and Triple::isMusl() are supposed to treat
GNUX32 and MuslX32 differently.
- computeTargetTriple() needs to be able to transform triples to add or
remove X32 from the environment and needs to map GNU to GNUX32, and
Musl to MuslX32.
- getMultiarchTriple() completely lacks any Musl support and retains the
explicit check for GNUX32 as it can only return x86_64-linux-gnux32.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D103777
Added:
Modified:
clang/lib/Basic/Targets/X86.h
clang/lib/Driver/Driver.cpp
clang/lib/Driver/ToolChains/Gnu.cpp
clang/lib/Driver/ToolChains/Linux.cpp
clang/test/Driver/linux-cross.cpp
llvm/include/llvm/ADT/Triple.h
llvm/lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp
llvm/lib/Target/X86/MCTargetDesc/X86MCAsmInfo.cpp
llvm/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp
llvm/lib/Target/X86/X86AsmPrinter.cpp
llvm/lib/Target/X86/X86RegisterInfo.cpp
llvm/lib/Target/X86/X86Subtarget.h
llvm/lib/Target/X86/X86TargetMachine.cpp
llvm/test/CodeGen/X86/x32-lea-1.ll
Removed:
diff --git a/clang/lib/Basic/Targets/X86.h b/clang/lib/Basic/Targets/X86.h
index 0ba2fd6ba024..7639ea835ebc 100644
--- a/clang/lib/Basic/Targets/X86.h
+++ b/clang/lib/Basic/Targets/X86.h
@@ -661,7 +661,7 @@ class LLVM_LIBRARY_VISIBILITY X86_64TargetInfo : public
X86TargetInfo {
public:
X86_64TargetInfo(const llvm::Triple &Triple, const TargetOptions &Opts)
: X86TargetInfo(Triple, Opts) {
-const bool IsX32 = getTriple().getEnvironment() == llvm::Triple::GNUX32;
+const bool IsX32 = getTriple().isX32();
bool IsWinCOFF =
getTriple().isOSWindows() && getTriple().isOSBinFormatCOFF();
LongWidth = LongAlign = PointerWidth = PointerAlign = IsX32 ? 32 : 64;
diff --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 287b21864154..cd2c8c9b1916 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -519,14 +519,21 @@ static llvm::Triple computeTargetTriple(const Driver &D,
AT = Target.get64BitArchVariant().getArch();
if (Target.getEnvironment() == llvm::Triple::GNUX32)
Target.setEnvironment(llvm::Triple::GNU);
+ else if (Target.getEnvironment() == llvm::Triple::MuslX32)
+Target.setEnvironment(llvm::Triple::Musl);
} else if (A->getOption().matches(options::OPT_mx32) &&
Target.get64BitArchVariant().getArch() == llvm::Triple::x86_64)
{
AT = llvm::Triple::x86_64;
- Target.setEnvironment(llvm::Triple::GNUX32);
+ if (Target.getEnvironment() == llvm::Triple::Musl)
+Target.setEnvironment(llvm::Triple::MuslX32);
+ else
+Target.setEnvironment(llvm::Triple::GNUX32);
} else if (A->getOption().matches(options::OPT_m32)) {
AT = Target.get32BitArchVariant().getArch();
if (Target.getEnvironment() == llvm::Triple::GNUX32)
Target.setEnvironment(llvm::Triple::GNU);
+ else if (Target.getEnvironment() == llvm::Triple::MuslX32)
+Target.setEnvironment(llvm::Triple::Musl);
} else if (A->getOption().matches(options::OPT_m16) &&
Target.get32BitArchVariant().getArch() == llvm::Triple::x86) {
AT = llvm::Triple::x86;
diff --git a/clang/lib/Driver/ToolChains/Gnu.cpp
b/clang/lib/Driver/ToolChains/Gnu.cpp
index a27841dc5985..517ba60e0b77 100644
--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -294,7 +294,7 @@ static const char *getLDMOption(const llvm::Triple &T,
const ArgList &Args) {
case llvm::Triple::systemz:
return "elf64_s390";
case llvm::Triple::x86_64:
-if (T.getEnvironment() == llvm::Triple::GNUX32)
+if (T.isX32())
return "elf32_x86_64";
return "elf_x86_64";
case llvm::Triple::ve:
@@ -725,7 +725,7 @@ void tools::gnutools::Assembler::ConstructJob(Compilation
&C,
CmdArgs.push_back("--32");
break;
case llvm::Triple::x86_64:
-if (getToolChain().getTriple().getEnvironment() == llvm::Triple::GNUX32)
+if (getToolChain().getTriple().isX32())
CmdArgs.push_back("--x32");
else
[clang] 6b86813 - [SYCL] Always set NoUnwind attribute for SYCL.
Author: Harald van Dijk
Date: 2023-03-30T02:18:52+01:00
New Revision: 6b868139458d258c1ed4c0279e8f4374556c1c1e
URL:
https://github.com/llvm/llvm-project/commit/6b868139458d258c1ed4c0279e8f4374556c1c1e
DIFF:
https://github.com/llvm/llvm-project/commit/6b868139458d258c1ed4c0279e8f4374556c1c1e.diff
LOG: [SYCL] Always set NoUnwind attribute for SYCL.
Like CUDA and OpenCL, the SYCL specification says that throwing and
catching exceptions in device functions is not supported, so this change
extends the logic for adding the NoUnwind attribute to SYCL.
The existing convergent.cpp test, which tests that the convergent
attribute is added to functions by default, is renamed and reused to
test that the nounwind attribute is added by default. This test now has
-fexceptions added to it, which the driver adds by default as well.
The obvious question here is why not simply change the driver to remove
-fexceptions. This change follows the direction given by the TODO
comment because removing -fexceptions would also disable the
__EXCEPTIONS macro, which should reflect whether exceptions are enabled
on the host, rather than on the device, to avoid conflicts in types
shared between host and device.
Reviewed By: bader
Differential Revision: https://reviews.llvm.org/D147097
Added:
clang/test/CodeGenSYCL/function-attrs.cpp
Modified:
clang/lib/CodeGen/CGCall.cpp
Removed:
clang/test/CodeGenSYCL/convergent.cpp
diff --git a/clang/lib/CodeGen/CGCall.cpp b/clang/lib/CodeGen/CGCall.cpp
index aaa5d4e70d7db..63296aeec5b9f 100644
--- a/clang/lib/CodeGen/CGCall.cpp
+++ b/clang/lib/CodeGen/CGCall.cpp
@@ -1971,10 +1971,9 @@ void
CodeGenModule::getDefaultFunctionAttributes(StringRef Name,
}
// TODO: NoUnwind attribute should be added for other GPU modes HIP,
- // SYCL, OpenMP offload. AFAIK, none of them support exceptions in device
- // code.
+ // OpenMP offload. AFAIK, neither of them support exceptions in device code.
if ((getLangOpts().CUDA && getLangOpts().CUDAIsDevice) ||
- getLangOpts().OpenCL) {
+ getLangOpts().OpenCL || getLangOpts().SYCLIsDevice) {
FuncAttrs.addAttribute(llvm::Attribute::NoUnwind);
}
diff --git a/clang/test/CodeGenSYCL/convergent.cpp
b/clang/test/CodeGenSYCL/convergent.cpp
deleted file mode 100644
index 779f1592da0e0..0
--- a/clang/test/CodeGenSYCL/convergent.cpp
+++ /dev/null
@@ -1,19 +0,0 @@
-// RUN: %clang_cc1 -fsycl-is-device -emit-llvm -disable-llvm-passes \
-// RUN: -triple spir64 -emit-llvm %s -o - | FileCheck %s
-
-// CHECK-DAG: Function Attrs:
-// CHECK-DAG-SAME: convergent
-// CHECK-DAG-NEXT: define void @_Z3foov
-void foo() {
- int a = 1;
-}
-
-template
-__attribute__((sycl_kernel)) void kernel_single_task(const Func &kernelFunc) {
- kernelFunc();
-}
-
-int main() {
- kernel_single_task([] { foo(); });
- return 0;
-}
diff --git a/clang/test/CodeGenSYCL/function-attrs.cpp
b/clang/test/CodeGenSYCL/function-attrs.cpp
new file mode 100644
index 0..8f5c0ea5c512c
--- /dev/null
+++ b/clang/test/CodeGenSYCL/function-attrs.cpp
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -fsycl-is-device -emit-llvm -disable-llvm-passes \
+// RUN: -triple spir64 -fexceptions -emit-llvm %s -o - | FileCheck %s
+
+int foo();
+
+// CHECK: define dso_local spir_func void @_Z3barv() [[BAR:#[0-9]+]]
+// CHECK: attributes [[BAR]] =
+// CHECK-SAME: convergent
+// CHECK-SAME: nounwind
+void bar() {
+ int a = foo();
+}
+
+int foo() {
+ return 1;
+}
+
+template
+__attribute__((sycl_kernel)) void kernel_single_task(const Func &kernelFunc) {
+ kernelFunc();
+}
+
+int main() {
+ kernel_single_task([] { bar(); });
+ return 0;
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Revert "[X86][clang] Lift _BitInt() supported max width." (PR #81175)
hvdijk wrote:
> I find your PR description very vague. Please be more specific about which
> ICEs and miscompilations you are concerned about (godbolt please). Is this
> _just_ about the open alignment question, or also something else?
I linked to where one major example had already been provided, but let me put
it in here as well.
https://godbolt.org/z/4jTrW4fcP
```
clang++: /root/llvm-project/clang/lib/CodeGen/CGRecordLayoutBuilder.cpp:759:
void {anonymous}::CGRecordLowering::clipTailPadding(): Assertion
`Prior->FD->hasAttr() && "should not have reused this
field's tail padding"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and
include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments:
/opt/compiler-explorer/clang-assertions-trunk/bin/clang++ -gdwarf-4 -g -o
/app/output.s -mllvm --x86-asm-syntax=intel -S
--gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics
-fno-crash-diagnostics
1. parser at end of file
2. :9:3: LLVM IR generation of declaration 'g'
3. :9:3: Generating code for declaration 'g'
#0 0x0389ed98 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x389ed98)
#1 0x0389ca7c llvm::sys::CleanupOnSignal(unsigned long)
(/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x389ca7c)
#2 0x037e4f58 CrashRecoverySignalHandler(int)
CrashRecoveryContext.cpp:0:0
#3 0x7f7cec242520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x7f7cec2969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x7f7cec242476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x7f7cec2287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x7f7cec22871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x7f7cec239e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x03baa784 (anonymous
namespace)::CGRecordLowering::clipTailPadding() CGRecordLayoutBuilder.cpp:0:0
#10 0x03bb0253 (anonymous namespace)::CGRecordLowering::lower(bool)
CGRecordLayoutBuilder.cpp:0:0
```
Here's another:
https://godbolt.org/z/eKahY86Yd
```
_BitInt(129) *f(_BitInt(129) *p) {
return p + 1;
}
char *f(char *p) {
return p + sizeof(_BitInt(129));
}
```
These should obviously produce identical code, but it results in
```
f(_BitInt(129)*):# @f(_BitInt(129)*)
lea rax, [rdi + 32]
ret
f(char*): # @f(char*)
lea rax, [rdi + 24]
ret
```
The codegen is just completely broken, and the fact that it passes Clang's
testing is simply due to the fact that we have close to zero tests that it
works in any capacity.
Note that this revert doesn't remove the support entirely, it only moves it
back behind the same `-fexperimental-max-bitint-width=` option that was already
there before.
https://github.com/llvm/llvm-project/pull/81175
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Revert "[X86][clang] Lift _BitInt() supported max width." (PR #81175)
hvdijk wrote: > It should be technically possible for Clang to give _BitInt(N) an alignment > that is independent from LLVM's alignment I'm not sure it's even technically possible: if loading a `_BitInt(129)` from memory should load 3 bytes, but it is translated to an LLVM IR load of `i129` that loads 4 bytes, then even if the last byte is ignored, simply attempting to load it may access memory out of bounds and crash the program. Storing `i129`, it would clobber the next byte of memory. https://github.com/llvm/llvm-project/pull/81175 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Revert "[X86][clang] Lift _BitInt() supported max width." (PR #81175)
hvdijk wrote: > At least that shouldn't be a problem: LLVM has separate concepts of "store > size" and "alloc size" where only the latter rounds up to alignment. So `load > i129` is specified to access only 9 bytes, not 16 bytes. Sure, but when it appears inside a struct, the memory reserved is based on the alloc size, not the store size, see `StructLayout`. That applies even for a packed struct. https://github.com/llvm/llvm-project/pull/81175 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Revert "[X86][clang] Lift _BitInt() supported max width." (PR #81175)
hvdijk wrote: That would be nice, but that will take time, and I did wait months already before creating this PR. Leaving Clang in its current state until someone steps up to fix it, in my opinion, does a massive disservice to users. If code is written to use `_BitInt`, and it correctly uses configure or CMake checks to try to detect compiler support, and fall back to some other implementation if `_BitInt` is unavailable, such code would, with Clang, use the non-working implementation. In which case the configure or CMake check would end up amended to "and if Clang, don't bother". From experience, such checks remain for far too long after the original problem is fixed; leaving Clang in its current state, I suspect, ensures that once Clang behaves correctly, still `_BitInt` will not be used. I'm happy if someone is willing to step up to fix the implementation, but I am not able to do it, and I would really like to avoid Clang 18 being released in this broken state, if possible, and I see no way short of a revert to realistically achieve that. https://github.com/llvm/llvm-project/pull/81175 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Fix cross in-tree builds (PR #97392)
https://github.com/hvdijk created
https://github.com/llvm/llvm-project/pull/97392
When performing cross in-tree builds, we need native versions of various tools,
we cannot assume the cross builds that are part of the current build are
executable. LLVM provides the setup_host_tool function to handle this, either
picking up versions of tools from LLVM_NATIVE_TOOL_DIR, or implicitly building
native versions as needed. Use it for libclc too.
LLVM's setup_host_tool function assumes the project is LLVM, so this also needs
libclc's project() to be conditional on it being built standalone. Luckily, the
only change this needs is using CMAKE_CURRENT_SOURCE_DIR instead of
PROJECT_SOURCE_DIR.
>From 273d5c86afd1418565d563825f38d6ec340ee00f Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Fri, 28 Jun 2024 13:41:16 +0100
Subject: [PATCH 1/2] [libclc][NFC] Do not set project in in-tree builds.
This is NFC at the moment because nothing relies on ${PROJECT_*} being
set to the LLVM values.
---
libclc/CMakeLists.txt | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/libclc/CMakeLists.txt b/libclc/CMakeLists.txt
index ef8d21b167623..42a1fe46ea9ac 100644
--- a/libclc/CMakeLists.txt
+++ b/libclc/CMakeLists.txt
@@ -1,11 +1,13 @@
cmake_minimum_required(VERSION 3.20.0)
-project( libclc VERSION 0.2.0 LANGUAGES CXX C)
+if(CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
+ project(libclc VERSION 0.2.0 LANGUAGES CXX C)
+endif()
set(CMAKE_CXX_STANDARD 17)
# Add path for custom modules
-list( INSERT CMAKE_MODULE_PATH 0 "${PROJECT_SOURCE_DIR}/cmake/modules" )
+list( INSERT CMAKE_MODULE_PATH 0 "${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules" )
set( LIBCLC_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR} )
set( LIBCLC_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR} )
@@ -211,7 +213,7 @@ if( ENABLE_RUNTIME_SUBNORMAL )
foreach( file IN ITEMS subnormal_use_default subnormal_disable )
link_bc(
TARGET ${file}
- INPUTS ${PROJECT_SOURCE_DIR}/generic/lib/${file}.ll
+ INPUTS ${CMAKE_CURRENT_SOURCE_DIR}/generic/lib/${file}.ll
)
install( FILES $ ARCHIVE
DESTINATION "${CMAKE_INSTALL_DATADIR}/clc" )
@@ -219,7 +221,7 @@ if( ENABLE_RUNTIME_SUBNORMAL )
endif()
find_package( Python3 REQUIRED COMPONENTS Interpreter )
-file( TO_CMAKE_PATH ${PROJECT_SOURCE_DIR}/generic/lib/gen_convert.py
script_loc )
+file( TO_CMAKE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/generic/lib/gen_convert.py
script_loc )
add_custom_command(
OUTPUT convert.cl
COMMAND ${Python3_EXECUTABLE} ${script_loc} > convert.cl
@@ -264,7 +266,7 @@ foreach( t ${LIBCLC_TARGETS_TO_BUILD} )
foreach( l ${dirs} ${DARCH} ${DARCH}-${OS} ${DARCH}-${VENDOR}-${OS} )
foreach( s "SOURCES" "SOURCES_${LLVM_MAJOR}.${LLVM_MINOR}" )
file( TO_CMAKE_PATH ${l}/lib/${s} file_loc )
- file( TO_CMAKE_PATH ${PROJECT_SOURCE_DIR}/${file_loc} loc )
+ file( TO_CMAKE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/${file_loc} loc )
# Prepend the location to give higher priority to
# specialized implementation
if( EXISTS ${loc} )
@@ -339,7 +341,7 @@ foreach( t ${LIBCLC_TARGETS_TO_BUILD} )
list( APPEND build_flags
-D__CLC_INTERNAL
-D${CLC_TARGET_DEFINE}
- -I${PROJECT_SOURCE_DIR}/generic/include
+ -I${CMAKE_CURRENT_SOURCE_DIR}/generic/include
# FIXME: Fix libclc to not require disabling this noisy warning
-Wno-bitwise-conditional-parentheses
)
@@ -360,9 +362,9 @@ foreach( t ${LIBCLC_TARGETS_TO_BUILD} )
# the path (e.g., ironing out any ".."), then make it relative to the
# root directory again, and use that relative path component for the
# binary path.
-get_filename_component( abs_path ${file} ABSOLUTE BASE_DIR
${PROJECT_SOURCE_DIR} )
-file( RELATIVE_PATH root_rel_path ${PROJECT_SOURCE_DIR} ${abs_path} )
-set( input_file ${PROJECT_SOURCE_DIR}/${file} )
+get_filename_component( abs_path ${file} ABSOLUTE BASE_DIR
${CMAKE_CURRENT_SOURCE_DIR} )
+file( RELATIVE_PATH root_rel_path ${CMAKE_CURRENT_SOURCE_DIR}
${abs_path} )
+set( input_file ${CMAKE_CURRENT_SOURCE_DIR}/${file} )
set( output_file "${LIBCLC_ARCH_OBJFILE_DIR}/${root_rel_path}.bc" )
endif()
@@ -373,7 +375,7 @@ foreach( t ${LIBCLC_TARGETS_TO_BUILD} )
INPUT ${input_file}
OUTPUT ${output_file}
EXTRA_OPTS "${mcpu}" -fno-builtin -nostdlib
- "${build_flags}" -I${PROJECT_SOURCE_DIR}/${file_dir}
+ "${build_flags}" -I${CMAKE_CURRENT_SOURCE_DIR}/${file_dir}
DEPENDENCIES generate_convert.cl clspv-generate_convert.cl
)
list( APPEND bytecode_files ${output_file} )
@@ -431,7 +433,7 @@ foreach( t ${LIBCLC_TARGETS_TO_BUILD} )
if( NOT clang_triple MATCHES ".*ptx.*--$" )
add_test( NAME external-calls-${obj_suffix}
COMMAND ./check_external_calls.sh
${CMAKE_CURRENT_BINARY_DIR}/${obj_suffix} ${LLVM_TOOLS_BINARY
[libclc] [libclc] Fix cross in-tree builds (PR #97392)
https://github.com/hvdijk closed https://github.com/llvm/llvm-project/pull/97392 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [libclc] [llvm] [libclc] More cross compilation fixes (PR #97811)
https://github.com/hvdijk created
https://github.com/llvm/llvm-project/pull/97811
* Move the setup_host_tool calls to the directories of their tool. Although it
works to call it in libclc, it can only appear in a single location so it fails
the "what if everyone did this?" test and causes problems for downstream code
that also wants to use native versions of these tools from other projects.
* Correct the TARGET "${${tool}_target}" check. "${${tool}_target}" may be set
to the path to the executable, which works in dependencies but cannot be tested
using if(TARGET). For lack of a better alternative, just check that
"${${tool}_target}" is non-empty and trust that if it is, it is set to a
meaningful value. If somehow it turns out to be a valid target, its value will
still show up in error messages anyway.
* Account for llvm-spirv possibly being provided in-tree. Per
https://github.com/KhronosGroup/SPIRV-LLVM-Translator?tab=readme-ov-file#llvm-in-tree-build
it is possible to drop llvm-spirv into LLVM and have it built as part of
LLVM's build. In this configuration, cross builds of LLVM require a native
version of llvm-spirv to be built. Note: having this work in cross builds also
requires a change to SPIRV-LLVM-Translator.
>From 8c16c7d759cc9113e2c045c8b7a76cc61c19064a Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Fri, 5 Jul 2024 11:24:45 +0100
Subject: [PATCH] [libclc] More cross compilation fixes
* Move the setup_host_tool calls to the directories of their tool.
Although it works to call it in libclc, it can only appear in a single
location so it fails the "what if everyone did this?" test and causes
problems for downstream code that also wants to use native versions of
these tools from other projects.
* Correct the TARGET "${${tool}_target}" check. "${${tool}_target}" may
be set to the path to the executable, which works in dependencies but
cannot be tested using if(TARGET). For lack of a better alternative,
just check that "${${tool}_target}" is non-empty and trust that if it
is, it is set to a meaningful value. If somehow it turns out to be a
valid target, its value will still show up in error messages anyway.
* Account for llvm-spirv possibly being provided in-tree. Per
https://github.com/KhronosGroup/SPIRV-LLVM-Translator?tab=readme-ov-file#llvm-in-tree-build
it is possible to drop llvm-spirv into LLVM and have it built as part
of LLVM's build. In this configuration, cross builds of LLVM require a
native version of llvm-spirv to be built. Note: having this work in
cross builds also requires a change to SPIRV-LLVM-Translator.
---
clang/tools/driver/CMakeLists.txt | 2 ++
libclc/CMakeLists.txt | 30 +++--
llvm/tools/llvm-as/CMakeLists.txt | 2 ++
llvm/tools/llvm-link/CMakeLists.txt | 2 ++
llvm/tools/opt/CMakeLists.txt | 2 ++
5 files changed, 24 insertions(+), 14 deletions(-)
diff --git a/clang/tools/driver/CMakeLists.txt
b/clang/tools/driver/CMakeLists.txt
index 290bf2a42536d..f9e71223f47c4 100644
--- a/clang/tools/driver/CMakeLists.txt
+++ b/clang/tools/driver/CMakeLists.txt
@@ -38,6 +38,8 @@ add_clang_tool(clang
GENERATE_DRIVER
)
+setup_host_tool(clang CLANG clang_exe clang_target)
+
clang_target_link_libraries(clang
PRIVATE
clangBasic
diff --git a/libclc/CMakeLists.txt b/libclc/CMakeLists.txt
index 4f5625ff94916..35136648d3591 100644
--- a/libclc/CMakeLists.txt
+++ b/libclc/CMakeLists.txt
@@ -73,10 +73,10 @@ else()
endif()
if( NOT EXISTS ${LIBCLC_CUSTOM_LLVM_TOOLS_BINARY_DIR} )
-setup_host_tool( clang CLANG clang_exe clang_target )
-setup_host_tool( llvm-as LLVM_AS llvm-as_exe llvm-as_target )
-setup_host_tool( llvm-link LLVM_LINK llvm-link_exe llvm-link_target )
-setup_host_tool( opt OPT opt_exe opt_target )
+get_host_tool_path( clang CLANG clang_exe clang_target )
+get_host_tool_path( llvm-as LLVM_AS llvm-as_exe llvm-as_target )
+get_host_tool_path( llvm-link LLVM_LINK llvm-link_exe llvm-link_target )
+get_host_tool_path( opt OPT opt_exe opt_target )
endif()
endif()
@@ -97,17 +97,19 @@ if( EXISTS ${LIBCLC_CUSTOM_LLVM_TOOLS_BINARY_DIR} )
endif()
foreach( tool IN ITEMS clang opt llvm-as llvm-link )
- if( NOT EXISTS "${${tool}_exe}" AND NOT TARGET "${${tool}_target}" )
+ if( NOT EXISTS "${${tool}_exe}" AND "${tool}_target" STREQUAL "" )
message( FATAL_ERROR "libclc toolchain incomplete - missing tool ${tool}!"
)
endif()
endforeach()
# llvm-spirv is an optional dependency, used to build spirv-* targets.
-find_program( LLVM_SPIRV llvm-spirv PATHS ${LLVM_TOOLS_BINARY_DIR}
NO_DEFAULT_PATH )
-
-if( LLVM_SPIRV )
- add_executable( libclc::llvm-spirv IMPORTED GLOBAL )
- set_target_properties( libclc::llvm-spirv PROPERTIES IMPORTED_LOCATION
${LLVM_SPIRV} )
+# It may be provided in-tree or externally.
+if( TARGET llvm-spirv )
+ get_host_tool_path( llvm-spirv LLVM_SPIRV llvm-spirv_exe llvm-spirv_target )
+else()
+ find_p
[clang] [libclc] [llvm] [libclc] More cross compilation fixes (PR #97811)
https://github.com/hvdijk edited https://github.com/llvm/llvm-project/pull/97811 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [libclc] [llvm] [libclc] More cross compilation fixes (PR #97811)
hvdijk wrote: The SPIRV-LLVM-Translator change that this depended on has been merged, so this PR no longer depends on external changes. https://github.com/llvm/llvm-project/pull/97811 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [libclc] [llvm] [libclc] More cross compilation fixes (PR #97811)
hvdijk wrote: Both buildbot failures appear to be unrelated to this PR: neither fails in libclc, the first has resolved itself and passes in later attempts, the second looks like the builder has just run out of disk space. If I am wrong and there is something I should look into please let me know, otherwise I will leave it. https://github.com/llvm/llvm-project/pull/97811 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Introduce `SemaSYCL` (PR #88086)
@@ -0,0 +1,66 @@
+//===- SemaOpenACC.h 000- Semantic Analysis for SYCL constructs
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+/// \file
+/// This file declares semantic analysis for SYCL constructs.
+///
+//===--===//
+
+#ifndef LLVM_CLANG_SEMA_SEMASYCL_H
+#define LLVM_CLANG_SEMA_SEMASYCL_H
+
+#include "clang/AST/Decl.h"
+#include "clang/AST/Type.h"
+#include "clang/Basic/SourceLocation.h"
+#include "clang/Sema/Ownership.h"
+#include "clang/Sema/SemaBase.h"
+#include "llvm/ADT/DenseSet.h"
+
+namespace clang {
+
+class SemaSYCL : public SemaBase {
+public:
+ SemaSYCL(Sema &S);
+
+ /// Creates a SemaDiagnosticBuilder that emits the diagnostic if the current
+ /// context is "used as device code".
+ ///
+ /// - If CurLexicalContext is a kernel function or it is known that the
+ /// function will be emitted for the device, emits the diagnostics
+ /// immediately.
+ /// - If CurLexicalContext is a function and we are compiling
+ /// for the device, but we don't know that this function will be codegen'ed
+ /// for devive yet, creates a diagnostic which is emitted if and when we
hvdijk wrote:
This took me a moment longer to parse than it should. I realise you only moved
it, this is not newly written by you, but maybe good to update at the same time
by moving the "yet" to the front to make it clear and unambiguous that it
applies to the "know", not to the "emitted":
```suggestion
/// for the device, but we don't know yet that this function will be
codegen'ed
/// for the device, creates a diagnostic which is emitted if and when we
```
https://github.com/llvm/llvm-project/pull/88086
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [AArch64] Extend SVE diagnostics. (PR #94976)
https://github.com/hvdijk created
https://github.com/llvm/llvm-project/pull/94976
The SVE diagnostics were guarded by a FD->hasBody() check that prevented the
diagnostic from being emitted for code that still triggered the backend crashes
that the errors were meant to avoid, because FD->hasBody() returns false for a
function that Clang is currently processing. This is not done for the
equivalent RISC-V code, and is not needed for AArch64 either, so remove it.
Errors were also emitted in the wrong location, errors were emitted at the
called function's location, rather than at the caller's, which meant that just
removing the FD->hasBody() check resulted in incomprehensible errors. Change
this as well.
The aarch64-mangle-sve-vectors.cpp test was using -target-feature wrong which
was exposed as a result of these changes. Different target features need to be
passed in as different -target-feature options.
aarch64-targetattr-arch.c has a test_errors() function that needs to be split
in two. Now that svundef_s8() is diagnosed for its use of svint8_t, the "needs
target feature sve" diagnostic is no longer emitted, but this affects all calls
in the same function. To ensure we still check this for its __crc32cd call,
move that into a separate function.
Fixes #94766.
>From 9bd0b577a3a70abb6e27b389c3bc7cc1e0191cc3 Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Mon, 10 Jun 2024 14:14:46 +0100
Subject: [PATCH] [AArch64] Extend SVE diagnostics.
The SVE diagnostics were guarded by a FD->hasBody() check that prevented
the diagnostic from being emitted for code that still triggered the
backend crashes that the errors were meant to avoid, because
FD->hasBody() returns false for a function that Clang is currently
processing. This is not done for the equivalent RISC-V code, and is not
needed for AArch64 either, so remove it.
Errors were also emitted in the wrong location, errors were emitted at
the called function's location, rather than at the caller's, which meant
that just removing the FD->hasBody() check resulted in incomprehensible
errors. Change this as well.
The aarch64-mangle-sve-vectors.cpp test was using -target-feature wrong
which was exposed as a result of these changes. Different target
features need to be passed in as different -target-feature options.
aarch64-targetattr-arch.c has a test_errors() function that needs to be
split in two. Now that svundef_s8() is diagnosed for its use of
svint8_t, the "needs target feature sve" diagnostic is no longer
emitted, but this affects all calls in the same function. To ensure we
still check this for its __crc32cd call, move that into a separate
function.
Fixes #94766.
---
clang/lib/Sema/Sema.cpp | 7 ++---
clang/test/CodeGen/aarch64-targetattr-arch.c | 8 --
.../target.c | 28 ---
.../CodeGenCXX/aarch64-mangle-sve-vectors.cpp | 4 +--
.../Sema/aarch64-sme2-sve2p1-diagnostics.c| 3 ++
clang/test/Sema/arm-sve-target.cpp| 2 +-
6 files changed, 33 insertions(+), 19 deletions(-)
diff --git a/clang/lib/Sema/Sema.cpp b/clang/lib/Sema/Sema.cpp
index a612dcd4b4d03..907a05a5d1b49 100644
--- a/clang/lib/Sema/Sema.cpp
+++ b/clang/lib/Sema/Sema.cpp
@@ -2093,16 +2093,15 @@ void Sema::checkTypeSupport(QualType Ty, SourceLocation
Loc, ValueDecl *D) {
}
// Don't allow SVE types in functions without a SVE target.
-if (Ty->isSVESizelessBuiltinType() && FD && FD->hasBody()) {
+if (Ty->isSVESizelessBuiltinType() && FD) {
llvm::StringMap CallerFeatureMap;
Context.getFunctionFeatureMap(CallerFeatureMap, FD);
if (!Builtin::evaluateRequiredTargetFeatures("sve", CallerFeatureMap)) {
if (!Builtin::evaluateRequiredTargetFeatures("sme", CallerFeatureMap))
- Diag(D->getLocation(), diag::err_sve_vector_in_non_sve_target) << Ty;
+ Diag(Loc, diag::err_sve_vector_in_non_sve_target) << Ty;
else if (!IsArmStreamingFunction(FD,
/*IncludeLocallyStreaming=*/true)) {
- Diag(D->getLocation(),
diag::err_sve_vector_in_non_streaming_function)
- << Ty;
+ Diag(Loc, diag::err_sve_vector_in_non_streaming_function) << Ty;
}
}
}
diff --git a/clang/test/CodeGen/aarch64-targetattr-arch.c
b/clang/test/CodeGen/aarch64-targetattr-arch.c
index ed731d0378625..5de73d6027845 100644
--- a/clang/test/CodeGen/aarch64-targetattr-arch.c
+++ b/clang/test/CodeGen/aarch64-targetattr-arch.c
@@ -29,14 +29,18 @@ float16_t test_fp16_on_v9(float16_t x, float16_t y)
return vabdh_f16(x, y);
}
-void test_errors()
+void test_error1()
{
#ifdef HAS8
// expected-error@+2{{always_inline function '__crc32cd' requires target
feature 'crc'}}
#endif
__crc32cd(1, 1);
+}
+
+void test_error2()
+{
#if defined(HAS8) || defined(HAS81)
-// expected-error@+2{{'svundef_s8' needs target feature sve}}
+// expected-error@+2{{SVE vector type 'svint8_t'
[clang] [AArch64] Extend SVE diagnostics. (PR #94976)
https://github.com/hvdijk closed https://github.com/llvm/llvm-project/pull/94976 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [SYCL] Allow neon attributes for ARM host (PR #94229)
https://github.com/hvdijk created
https://github.com/llvm/llvm-project/pull/94229
We permit neon attributes in CUDA device code, but this permission was only for
CUDA device code. The same permission makes sense for SYCL device code as well,
especially now that neon attributes are used in glibc headers.
>From 13fb2b9d867d353ec67aab96159b8eea690e87d0 Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Mon, 3 Jun 2024 14:47:15 +0100
Subject: [PATCH] [SYCL] Allow neon attributes for ARM host
We permit neon attributes in CUDA device code, but this permission was
only for CUDA device code. The same permission makes sense for SYCL
device code as well, especially now that neon attributes are used in
glibc headers.
---
clang/lib/Sema/SemaType.cpp| 12 ++--
clang/test/SemaSYCL/neon-attrs.cpp | 16
2 files changed, 22 insertions(+), 6 deletions(-)
create mode 100644 clang/test/SemaSYCL/neon-attrs.cpp
diff --git a/clang/lib/Sema/SemaType.cpp b/clang/lib/Sema/SemaType.cpp
index 7cec82c701028..a8a1463522d03 100644
--- a/clang/lib/Sema/SemaType.cpp
+++ b/clang/lib/Sema/SemaType.cpp
@@ -8077,10 +8077,10 @@ static bool verifyValidIntegerConstantExpr(Sema &S,
const ParsedAttr &Attr,
/// match one of the standard Neon vector types.
static void HandleNeonVectorTypeAttr(QualType &CurType, const ParsedAttr &Attr,
Sema &S, VectorKind VecKind) {
- bool IsTargetCUDAAndHostARM = false;
- if (S.getLangOpts().CUDAIsDevice) {
+ bool IsTargetDeviceAndHostARM = false;
+ if (S.getLangOpts().CUDAIsDevice || S.getLangOpts().SYCLIsDevice) {
const TargetInfo *AuxTI = S.getASTContext().getAuxTargetInfo();
-IsTargetCUDAAndHostARM =
+IsTargetDeviceAndHostARM =
AuxTI && (AuxTI->getTriple().isAArch64() ||
AuxTI->getTriple().isARM());
}
@@ -8090,7 +8090,7 @@ static void HandleNeonVectorTypeAttr(QualType &CurType,
const ParsedAttr &Attr,
S.Context.getTargetInfo().hasFeature("mve") ||
S.Context.getTargetInfo().hasFeature("sve") ||
S.Context.getTargetInfo().hasFeature("sme") ||
-IsTargetCUDAAndHostARM) &&
+IsTargetDeviceAndHostARM) &&
VecKind == VectorKind::Neon) {
S.Diag(Attr.getLoc(), diag::err_attribute_unsupported)
<< Attr << "'neon', 'mve', 'sve' or 'sme'";
@@ -8099,7 +8099,7 @@ static void HandleNeonVectorTypeAttr(QualType &CurType,
const ParsedAttr &Attr,
}
if (!(S.Context.getTargetInfo().hasFeature("neon") ||
S.Context.getTargetInfo().hasFeature("mve") ||
-IsTargetCUDAAndHostARM) &&
+IsTargetDeviceAndHostARM) &&
VecKind == VectorKind::NeonPoly) {
S.Diag(Attr.getLoc(), diag::err_attribute_unsupported)
<< Attr << "'neon' or 'mve'";
@@ -8121,7 +8121,7 @@ static void HandleNeonVectorTypeAttr(QualType &CurType,
const ParsedAttr &Attr,
// Only certain element types are supported for Neon vectors.
if (!isPermittedNeonBaseType(CurType, VecKind, S) &&
- !IsTargetCUDAAndHostARM) {
+ !IsTargetDeviceAndHostARM) {
S.Diag(Attr.getLoc(), diag::err_attribute_invalid_vector_type) << CurType;
Attr.setInvalid();
return;
diff --git a/clang/test/SemaSYCL/neon-attrs.cpp
b/clang/test/SemaSYCL/neon-attrs.cpp
new file mode 100644
index 0..ec79fa5033308
--- /dev/null
+++ b/clang/test/SemaSYCL/neon-attrs.cpp
@@ -0,0 +1,16 @@
+// Host compilation on ARM with neon enabled (no errors expected).
+// RUN: %clang_cc1 -triple aarch64-linux-gnu -target-feature +neon
-fsyntax-only -verify=quiet %s
+
+// Host compilation on ARM with neon disabled.
+// RUN: %clang_cc1 -triple aarch64-linux-gnu -target-feature -neon
-fsyntax-only -verify %s
+
+// Device compilation on ARM (no errors expected).
+// RUN: %clang_cc1 -triple spirv64 -aux-triple aarch64-linux-gnu
-fsycl-is-device -fsyntax-only -verify=quiet %s
+
+// quiet-no-diagnostics
+typedef __attribute__((neon_vector_type(4))) float float32x4_t;
+// expected-error@-1 {{'neon_vector_type' attribute is not supported on
targets missing 'neon', 'mve', 'sve' or 'sme'}}
+// expect
+typedef unsigned char poly8_t;
+typedef __attribute__((neon_polyvector_type(8))) poly8_t poly8x8_t;
+// expected-error@-1 {{'neon_polyvector_type' attribute is not supported on
targets missing 'neon' or 'mve'}}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [SYCL] Allow neon attributes for ARM host (PR #94229)
https://github.com/hvdijk updated
https://github.com/llvm/llvm-project/pull/94229
>From 895f71d5f890a3988014e0d779586b9f142be90f Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Mon, 3 Jun 2024 15:03:17 +0100
Subject: [PATCH] [SYCL] Allow neon attributes for ARM host
We permit neon attributes in CUDA device code, but this permission was
only for CUDA device code. The same permission makes sense for SYCL
device code as well, especially now that neon attributes are used in
glibc headers.
---
clang/lib/Sema/SemaType.cpp| 12 ++--
clang/test/SemaSYCL/neon-attrs.cpp | 15 +++
2 files changed, 21 insertions(+), 6 deletions(-)
create mode 100644 clang/test/SemaSYCL/neon-attrs.cpp
diff --git a/clang/lib/Sema/SemaType.cpp b/clang/lib/Sema/SemaType.cpp
index 7cec82c701028..a8a1463522d03 100644
--- a/clang/lib/Sema/SemaType.cpp
+++ b/clang/lib/Sema/SemaType.cpp
@@ -8077,10 +8077,10 @@ static bool verifyValidIntegerConstantExpr(Sema &S,
const ParsedAttr &Attr,
/// match one of the standard Neon vector types.
static void HandleNeonVectorTypeAttr(QualType &CurType, const ParsedAttr &Attr,
Sema &S, VectorKind VecKind) {
- bool IsTargetCUDAAndHostARM = false;
- if (S.getLangOpts().CUDAIsDevice) {
+ bool IsTargetDeviceAndHostARM = false;
+ if (S.getLangOpts().CUDAIsDevice || S.getLangOpts().SYCLIsDevice) {
const TargetInfo *AuxTI = S.getASTContext().getAuxTargetInfo();
-IsTargetCUDAAndHostARM =
+IsTargetDeviceAndHostARM =
AuxTI && (AuxTI->getTriple().isAArch64() ||
AuxTI->getTriple().isARM());
}
@@ -8090,7 +8090,7 @@ static void HandleNeonVectorTypeAttr(QualType &CurType,
const ParsedAttr &Attr,
S.Context.getTargetInfo().hasFeature("mve") ||
S.Context.getTargetInfo().hasFeature("sve") ||
S.Context.getTargetInfo().hasFeature("sme") ||
-IsTargetCUDAAndHostARM) &&
+IsTargetDeviceAndHostARM) &&
VecKind == VectorKind::Neon) {
S.Diag(Attr.getLoc(), diag::err_attribute_unsupported)
<< Attr << "'neon', 'mve', 'sve' or 'sme'";
@@ -8099,7 +8099,7 @@ static void HandleNeonVectorTypeAttr(QualType &CurType,
const ParsedAttr &Attr,
}
if (!(S.Context.getTargetInfo().hasFeature("neon") ||
S.Context.getTargetInfo().hasFeature("mve") ||
-IsTargetCUDAAndHostARM) &&
+IsTargetDeviceAndHostARM) &&
VecKind == VectorKind::NeonPoly) {
S.Diag(Attr.getLoc(), diag::err_attribute_unsupported)
<< Attr << "'neon' or 'mve'";
@@ -8121,7 +8121,7 @@ static void HandleNeonVectorTypeAttr(QualType &CurType,
const ParsedAttr &Attr,
// Only certain element types are supported for Neon vectors.
if (!isPermittedNeonBaseType(CurType, VecKind, S) &&
- !IsTargetCUDAAndHostARM) {
+ !IsTargetDeviceAndHostARM) {
S.Diag(Attr.getLoc(), diag::err_attribute_invalid_vector_type) << CurType;
Attr.setInvalid();
return;
diff --git a/clang/test/SemaSYCL/neon-attrs.cpp
b/clang/test/SemaSYCL/neon-attrs.cpp
new file mode 100644
index 0..b1fd947d4a888
--- /dev/null
+++ b/clang/test/SemaSYCL/neon-attrs.cpp
@@ -0,0 +1,15 @@
+// Host compilation on ARM with neon enabled (no errors expected).
+// RUN: %clang_cc1 -triple aarch64-linux-gnu -target-feature +neon
-fsyntax-only -verify=quiet %s
+
+// Host compilation on ARM with neon disabled.
+// RUN: %clang_cc1 -triple aarch64-linux-gnu -target-feature -neon
-fsyntax-only -verify %s
+
+// Device compilation on ARM (no errors expected).
+// RUN: %clang_cc1 -triple spirv64 -aux-triple aarch64-linux-gnu
-fsycl-is-device -fsyntax-only -verify=quiet %s
+
+// quiet-no-diagnostics
+typedef __attribute__((neon_vector_type(4))) float float32x4_t;
+// expected-error@-1 {{'neon_vector_type' attribute is not supported on
targets missing 'neon', 'mve', 'sve' or 'sme'}}
+typedef unsigned char poly8_t;
+typedef __attribute__((neon_polyvector_type(8))) poly8_t poly8x8_t;
+// expected-error@-1 {{'neon_polyvector_type' attribute is not supported on
targets missing 'neon' or 'mve'}}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [ValueTracking] Convert `isKnownNonZero` to use SimplifyQuery (PR #85863)
@@ -645,7 +645,7 @@ LazyValueInfoImpl::solveBlockValueImpl(Value *Val,
BasicBlock *BB) {
// instruction is placed, even if it could legally be hoisted much higher.
// That is unfortunate.
PointerType *PT = dyn_cast(BBI->getType());
- if (PT && isKnownNonZero(BBI, DL))
+ if (PT && isKnownNonZero(BBI, /*Depth=*/0, DL))
hvdijk wrote:
The fact that this PR changes it so that `isKnownNonZero(BBI, DL)` is valid in
LLVM 18, used to be valid in LLVM 19, is currently an error in LLVM 19, but
will become valid in LLVM 19 again is unfortunate and difficult to account for
in downstream projects. @goldsteinn If you are going to change that, do you
think it is worth updating downstream code to support the current API, or is
that change going to go in fast enough that we can just wait?
https://github.com/llvm/llvm-project/pull/85863
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [ValueTracking] Convert `isKnownNonZero` to use SimplifyQuery (PR #85863)
@@ -645,7 +645,7 @@ LazyValueInfoImpl::solveBlockValueImpl(Value *Val,
BasicBlock *BB) {
// instruction is placed, even if it could legally be hoisted much higher.
// That is unfortunate.
PointerType *PT = dyn_cast(BBI->getType());
- if (PT && isKnownNonZero(BBI, DL))
+ if (PT && isKnownNonZero(BBI, /*Depth=*/0, DL))
hvdijk wrote:
Thanks, I had been slightly optimistic that this was just going to be a few
days, but it sounds like it's going to be longer. In that case I will check
what is easiest for us (which might be to submit that LLVM change ourselves).
https://github.com/llvm/llvm-project/pull/85863
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [ValueTracking] Restore isKnownNonZero parameter order. (PR #88873)
https://github.com/hvdijk created
https://github.com/llvm/llvm-project/pull/88873
Prior to #85863, the required parameters of llvm::isKnownNonZero were Value and
DataLayout. After, they are Value, Depth, and SimplifyQuery, where
SimplifyQuery is implicitly constructible from DataLayout. The change to move
Depth before SimplifyQuery needed callers to be updated unnecessarily, and as
commented in #85863, we actually want Depth to be after SimplifyQuery anyway so
that it can be defaulted and the caller does not need to specify it.
>From 6763d8cce44be02e9065c9c640736ac85ffcf8a2 Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Tue, 16 Apr 2024 12:06:31 +0100
Subject: [PATCH] [ValueTracking] Restore isKnownNonZero parameter order.
Prior to #85863, the required parameters of llvm::isKnownNonZero were
Value and DataLayout. After, they are Value, Depth, and SimplifyQuery,
where SimplifyQuery is implicitly constructible from DataLayout. The
change to move Depth before SimplifyQuery needed callers to be updated
unnecessarily, and as commented in #85863, we actually want Depth to be
after SimplifyQuery anyway so that it can be defaulted and the caller
does not need to specify it.
---
clang/lib/CodeGen/CGCall.cpp | 3 +-
llvm/include/llvm/Analysis/ValueTracking.h| 2 +-
llvm/lib/Analysis/BasicAliasAnalysis.cpp | 3 +-
llvm/lib/Analysis/InstructionSimplify.cpp | 25 ++---
llvm/lib/Analysis/LazyValueInfo.cpp | 5 +-
llvm/lib/Analysis/Loads.cpp | 4 +-
llvm/lib/Analysis/ScalarEvolution.cpp | 2 +-
llvm/lib/Analysis/ValueTracking.cpp | 106 +-
llvm/lib/CodeGen/CodeGenPrepare.cpp | 2 +-
.../Transforms/IPO/AttributorAttributes.cpp | 2 +-
llvm/lib/Transforms/IPO/FunctionAttrs.cpp | 2 +-
.../InstCombine/InstCombineAddSub.cpp | 2 +-
.../InstCombine/InstCombineAndOrXor.cpp | 4 +-
.../InstCombine/InstCombineCalls.cpp | 11 +-
.../InstCombine/InstCombineCompares.cpp | 18 +--
.../Transforms/InstCombine/InstCombinePHI.cpp | 3 +-
.../InstCombine/InstructionCombining.cpp | 2 +-
.../Instrumentation/MemorySanitizer.cpp | 4 +-
.../Utils/PromoteMemoryToRegister.cpp | 2 +-
.../lib/Transforms/Utils/SimplifyLibCalls.cpp | 20 ++--
.../Transforms/Vectorize/VectorCombine.cpp| 2 +-
llvm/unittests/Analysis/ValueTrackingTest.cpp | 13 +--
22 files changed, 113 insertions(+), 124 deletions(-)
diff --git a/clang/lib/CodeGen/CGCall.cpp b/clang/lib/CodeGen/CGCall.cpp
index 7a0bc6fa77b889..3f5463a9a70e9d 100644
--- a/clang/lib/CodeGen/CGCall.cpp
+++ b/clang/lib/CodeGen/CGCall.cpp
@@ -4124,8 +4124,7 @@ static bool isProvablyNull(llvm::Value *addr) {
}
static bool isProvablyNonNull(Address Addr, CodeGenFunction &CGF) {
- return llvm::isKnownNonZero(Addr.getBasePointer(), /*Depth=*/0,
- CGF.CGM.getDataLayout());
+ return llvm::isKnownNonZero(Addr.getBasePointer(), CGF.CGM.getDataLayout());
}
/// Emit the actual writing-back of a writeback.
diff --git a/llvm/include/llvm/Analysis/ValueTracking.h
b/llvm/include/llvm/Analysis/ValueTracking.h
index 9db0894162afca..e1c41b3b55ccfb 100644
--- a/llvm/include/llvm/Analysis/ValueTracking.h
+++ b/llvm/include/llvm/Analysis/ValueTracking.h
@@ -124,7 +124,7 @@ bool isOnlyUsedInZeroEqualityComparison(const Instruction
*CxtI);
/// specified, perform context-sensitive analysis and return true if the
/// pointer couldn't possibly be null at the specified instruction.
/// Supports values with integer or pointer type and vectors of integers.
-bool isKnownNonZero(const Value *V, unsigned Depth, const SimplifyQuery &Q);
+bool isKnownNonZero(const Value *V, const SimplifyQuery &Q, unsigned Depth =
0);
/// Return true if the two given values are negation.
/// Currently can recoginze Value pair:
diff --git a/llvm/lib/Analysis/BasicAliasAnalysis.cpp
b/llvm/lib/Analysis/BasicAliasAnalysis.cpp
index b082dfe8fbd217..16ee2ca49d0ece 100644
--- a/llvm/lib/Analysis/BasicAliasAnalysis.cpp
+++ b/llvm/lib/Analysis/BasicAliasAnalysis.cpp
@@ -1283,8 +1283,7 @@ AliasResult BasicAAResult::aliasGEP(
// VarIndex = Scale*V.
const VariableGEPIndex &Var = DecompGEP1.VarIndices[0];
if (Var.Val.TruncBits == 0 &&
-isKnownNonZero(Var.Val.V, /*Depth=*/0,
- SimplifyQuery(DL, DT, &AC, Var.CxtI))) {
+isKnownNonZero(Var.Val.V, SimplifyQuery(DL, DT, &AC, Var.CxtI))) {
// Check if abs(V*Scale) >= abs(Scale) holds in the presence of
// potentially wrapping math.
auto MultiplyByScaleNoWrap = [](const VariableGEPIndex &Var) {
diff --git a/llvm/lib/Analysis/InstructionSimplify.cpp
b/llvm/lib/Analysis/InstructionSimplify.cpp
index 4e6e666922671d..8955de6375dec4 100644
--- a/llvm/lib/Analysis/InstructionSimplify.cpp
+++ b/llvm/lib/Analysis/InstructionSimplify.cpp
@@ -1586,10 +1586,10 @@ static Value *simplifyUnsignedRang
[clang] [llvm] [ValueTracking] Convert `isKnownNonZero` to use SimplifyQuery (PR #85863)
@@ -645,7 +645,7 @@ LazyValueInfoImpl::solveBlockValueImpl(Value *Val,
BasicBlock *BB) {
// instruction is placed, even if it could legally be hoisted much higher.
// That is unfortunate.
PointerType *PT = dyn_cast(BBI->getType());
- if (PT && isKnownNonZero(BBI, DL))
+ if (PT && isKnownNonZero(BBI, /*Depth=*/0, DL))
hvdijk wrote:
Created #88873 for it.
https://github.com/llvm/llvm-project/pull/85863
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [ValueTracking] Restore isKnownNonZero parameter order. (PR #88873)
https://github.com/hvdijk closed https://github.com/llvm/llvm-project/pull/88873 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [libclc] [llvm] [libclc] More cross compilation fixes (PR #97811)
hvdijk wrote: ping https://github.com/llvm/llvm-project/pull/97811 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [libclc] [llvm] [libclc] More cross compilation fixes (PR #97811)
https://github.com/hvdijk closed https://github.com/llvm/llvm-project/pull/97811 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)
@@ -1989,6 +1989,14 @@ llvm::Value *CodeGenFunction::EmitLoadOfScalar(Address
Addr, bool Volatile,
return EmitAtomicLoad(AtomicLValue, Loc).getScalarVal();
}
+ if (const auto *BIT = Ty->getAs()) {
+if (BIT->getNumBits() > 128) {
hvdijk wrote:
For a number of bits >64, <=128, LLVM's `iN` type will have identical
representation to Clang `_BitInt(N)` but different alignment. I think this is
fine, I think nothing needs their alignment to match Clang's, but could you
double-check to make sure you agree?
https://github.com/llvm/llvm-project/pull/91364
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)
hvdijk wrote: Thanks for doing this, it's unfortunate that Clang is in a rather broken state with these types right now and it will be good to see improvement. I think the approach you're taking here is the only approach that will work. https://github.com/llvm/llvm-project/pull/91364 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] 7907c46 - Make clangd CompletionModel not depend on directory layout.
Author: Harald van Dijk
Date: 2021-05-05T19:25:34+01:00
New Revision: 7907c46fe6195728fafd843b8c0fb19a3e68e9ad
URL:
https://github.com/llvm/llvm-project/commit/7907c46fe6195728fafd843b8c0fb19a3e68e9ad
DIFF:
https://github.com/llvm/llvm-project/commit/7907c46fe6195728fafd843b8c0fb19a3e68e9ad.diff
LOG: Make clangd CompletionModel not depend on directory layout.
The current code accounts for two possible layouts, but there is at
least a third supported layout: clang-tools-extra may also be checked
out as clang/tools/extra with the releases, which was not yet handled.
Rather than treating that as a special case, use the location of
CompletionModel.cmake to handle all three cases. This should address the
problems that prompted D96787 and the problems that prompted the
proposed revert D100625.
Reviewed By: usaxena95
Differential Revision: https://reviews.llvm.org/D101851
Added:
Modified:
clang-tools-extra/clangd/quality/CompletionModel.cmake
Removed:
diff --git a/clang-tools-extra/clangd/quality/CompletionModel.cmake
b/clang-tools-extra/clangd/quality/CompletionModel.cmake
index 41bc2ed1890b0..dc0c0cde4dabb 100644
--- a/clang-tools-extra/clangd/quality/CompletionModel.cmake
+++ b/clang-tools-extra/clangd/quality/CompletionModel.cmake
@@ -4,8 +4,9 @@
# ${CMAKE_CURRENT_BINARY_DIR}. The generated header
# will define a C++ class called ${cpp_class} - which may be a
# namespace-qualified class name.
+set(CLANGD_COMPLETION_MODEL_COMPILER
${CMAKE_CURRENT_LIST_DIR}/CompletionModelCodegen.py)
function(gen_decision_forest model filename cpp_class)
- set(model_compiler
${LLVM_EXTERNAL_CLANG_TOOLS_EXTRA_SOURCE_DIR}/clangd/quality/CompletionModelCodegen.py)
+ set(model_compiler ${CLANGD_COMPLETION_MODEL_COMPILER})
set(output_dir ${CMAKE_CURRENT_BINARY_DIR})
set(header_file ${output_dir}/${filename}.h)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 1d463c2 - [Driver] Fix architecture triplets and search paths for Linux x32
Author: Harald van Dijk Date: 2021-04-01T09:47:56+01:00 New Revision: 1d463c2a386099597a8e2d26b9b964bc8fda8042 URL: https://github.com/llvm/llvm-project/commit/1d463c2a386099597a8e2d26b9b964bc8fda8042 DIFF: https://github.com/llvm/llvm-project/commit/1d463c2a386099597a8e2d26b9b964bc8fda8042.diff LOG: [Driver] Fix architecture triplets and search paths for Linux x32 Currently, support for the x32 ABI is handled as a multilib to the x86_64 target only. However, full self-hosting x32 systems treating it as a separate architecture with its own architecture triplets as well as search paths exist as well, in Debian's x32 port and elsewhere. This adds the missing architecture triplets and search paths so that clang can work as a native compiler on x32, and updates the tests so that they pass when using an x32 libdir suffix. Additionally, we would previously also assume that objects from any x86_64-linux-gnu GCC installation could be used to target x32. This changes the logic so that only GCC installations that include x32 support are used when targetting x32, meaning x86_64-linux-gnux32 GCC installations, and x86_64-linux-gnu and i686-linux-gnu GCC installations that include x32 multilib support. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D52050 Added: clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/i386-unknown-linux-gnu/10.2.0/crtbegin.o clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/10.2.0/crtbegin.o clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/10.2.0/crtbeginT.o clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/10.2.0/crtfastmath.o clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/10.2.0/x32/crtbegin.o clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/10.2.0/x32/crtbeginT.o clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/10.2.0/x32/crtfastmath.o clang/test/Driver/Inputs/basic_linux_tree/usr/lib/gcc/i386-unknown-linux/10.2.0/crtbegin.o clang/test/Driver/Inputs/basic_linux_tree/usr/lib/gcc/i686-unknown-linux/10.2.0/crtbegin.o clang/test/Driver/Inputs/basic_linux_tree/usr/lib/gcc/x86_64-unknown-linux/10.2.0/crtbegin.o clang/test/Driver/Inputs/basic_linux_tree/usr/lib/gcc/x86_64-unknown-linux/10.2.0/crtbeginT.o clang/test/Driver/Inputs/basic_linux_tree/usr/lib/gcc/x86_64-unknown-linux/10.2.0/crtfastmath.o clang/test/Driver/Inputs/multilib_32bit_linux_tree/usr/lib/gcc/i386-unknown-linux/10.2.0/64/crtbegin.o clang/test/Driver/Inputs/multilib_32bit_linux_tree/usr/lib/gcc/i386-unknown-linux/10.2.0/crtbegin.o clang/test/Driver/Inputs/multilib_64bit_linux_tree/usr/lib/gcc/x86_64-unknown-linux/10.2.0/32/crtbegin.o clang/test/Driver/Inputs/multilib_64bit_linux_tree/usr/lib/gcc/x86_64-unknown-linux/10.2.0/crtbegin.o clang/test/Driver/Inputs/multilib_64bit_linux_tree/usr/lib/gcc/x86_64-unknown-linux/10.2.0/x32/crtbegin.o clang/test/Driver/Inputs/multilib_64bit_linux_tree/usr/libx32/gcc/x86_64-unknown-gnu/10.2.0/32/crtbegin.o clang/test/Driver/Inputs/multilib_64bit_linux_tree/usr/libx32/gcc/x86_64-unknown-gnu/10.2.0/crtbegin.o clang/test/Driver/Inputs/multilib_64bit_linux_tree/usr/libx32/gcc/x86_64-unknown-gnu/10.2.0/x32/crtbegin.o Modified: clang/lib/Driver/ToolChains/Gnu.cpp clang/test/Driver/baremetal.cpp clang/test/Driver/cl-options.c clang/test/Driver/cross-linux.c clang/test/Driver/env.c clang/test/Driver/linux-ld.c clang/test/Preprocessor/iwithprefix.c Removed: clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/i386-unknown-linux-gnu/4.6.0/crtbegin.o clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/crtbegin.o clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/crtbeginT.o clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/crtfastmath.o clang/test/Driver/Inputs/basic_linux_tree/usr/lib/gcc/i386-unknown-linux/4.6.0/crtbegin.o clang/test/Driver/Inputs/basic_linux_tree/usr/lib/gcc/i686-unknown-linux/4.6.0/crtbegin.o clang/test/Driver/Inputs/basic_linux_tree/usr/lib/gcc/x86_64-unknown-linux/4.6.0/crtbegin.o clang/test/Driver/Inputs/basic_linux_tree/usr/lib/gcc/x86_64-unknown-linux/4.6.0/crtbeginT.o clang/test/Driver/Inputs/basic_linux_tree/usr/lib/gcc/x86_64-unknown-linux/4.6.0/crtfastmath.o clang/test/Driver/Inputs/multilib_32bit_linux_tree/usr/lib/gcc/i386-unknown-linux/4.6.0/64/crtbegin.o clang/test/Driver/Inputs/multilib_32bit_linux_tree/usr/lib/gcc/i386-unknown-linux/4.6.0/crtbegin.o clang/test/Driver/Inputs/multilib_64bit_linux_tree/usr/lib/gcc/x86_64-unknown-linux/4.6.0/32/crtbegin.o clang/test/Driver/Inputs/multilib_64bit_linux_
[clang] [clang-tools-extra] [RecursiveASTVisitor] Skip implicit instantiations. (PR #110899)
https://github.com/hvdijk created
https://github.com/llvm/llvm-project/pull/110899
In DEF_TRAVERSE_TMPL_SPEC_DECL, we attempted to skip implicit instantiations by
detecting that D->getTemplateArgsAsWritten() returns nullptr, but as this test
shows, it is possible for that to return a non-null pointer even for implicit
instantiations. Explicitly check for this case instead.
Fixes #110502
cc @sdkrystian, this fixes an issue introduced by
12028373020739b388eb2b8141742509f1764e3c, does this look okay or do you feel
there should be another way of doing it?
>From 5e0633679b88b2b22ab75cadd4ad447621656ae8 Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Wed, 2 Oct 2024 18:14:38 +0100
Subject: [PATCH] [RecursiveASTVisitor] Skip implicit instantiations.
In DEF_TRAVERSE_TMPL_SPEC_DECL, we attempted to skip implicit
instantiations by detecting that D->getTemplateArgsAsWritten() returns
nullptr, but as this test shows, it is possible for that to return a
non-null pointer even for implicit instantiations. Explicitly check for
this case instead.
Fixes #110502
---
.../checkers/modernize/type-traits.cpp| 21 +++
clang/include/clang/AST/RecursiveASTVisitor.h | 16 +++---
2 files changed, 30 insertions(+), 7 deletions(-)
diff --git
a/clang-tools-extra/test/clang-tidy/checkers/modernize/type-traits.cpp
b/clang-tools-extra/test/clang-tidy/checkers/modernize/type-traits.cpp
index 72241846384bcf..854ffa7928635c 100644
--- a/clang-tools-extra/test/clang-tidy/checkers/modernize/type-traits.cpp
+++ b/clang-tools-extra/test/clang-tidy/checkers/modernize/type-traits.cpp
@@ -14,11 +14,22 @@ namespace std {
static constexpr bool value = true;
};
+ template
+ static constexpr bool is_same_v = is_same::value; // NOLINT
+
template
struct enable_if {
using type = T;
};
+ template
+ using enable_if_t = typename enable_if::type; // NOLINT
+
+ template
+ struct remove_reference {
+using type = T;
+ };
+
inline namespace __std_lib_version1 {
template
struct add_const {
@@ -117,3 +128,13 @@ namespace my_std = std;
using Alias = my_std::add_const::type;
// CHECK-MESSAGES: :[[@LINE-1]]:15: warning: use c++14 style type templates
// CHECK-FIXES: using Alias = my_std::add_const_t;
+
+template
+struct ImplicitlyInstantiatedConstructor {
+ template >>
+ ImplicitlyInstantiatedConstructor(U) {}
+};
+
+const ImplicitlyInstantiatedConstructor
ImplicitInstantiation(std::remove_reference::type(123));
+// CHECK-MESSAGES: :[[@LINE-1]]:68: warning: use c++14 style type templates
+// CHECK-FIXES: const ImplicitlyInstantiatedConstructor
ImplicitInstantiation(std::remove_reference_t(123));
diff --git a/clang/include/clang/AST/RecursiveASTVisitor.h
b/clang/include/clang/AST/RecursiveASTVisitor.h
index cd9947f7ab9805..b563b89875f08b 100644
--- a/clang/include/clang/AST/RecursiveASTVisitor.h
+++ b/clang/include/clang/AST/RecursiveASTVisitor.h
@@ -2069,22 +2069,24 @@ bool
RecursiveASTVisitor::TraverseTemplateArgumentLocsHelper(
#define DEF_TRAVERSE_TMPL_SPEC_DECL(TMPLDECLKIND, DECLKIND)
\
DEF_TRAVERSE_DECL(TMPLDECLKIND##TemplateSpecializationDecl, {
\
+auto TSK = D->getTemplateSpecializationKind();
\
/* For implicit instantiations ("set x;"), we don't want to
\
recurse at all, since the instatiated template isn't written in
\
the source code anywhere. (Note the instatiated *type* --
\
set -- is written, and will still get a callback of
\
TemplateSpecializationType). For explicit instantiations
\
("template set;"), we do need a callback, since this
\
- is the only callback that's made for this instantiation.
\
- We use getTemplateArgsAsWritten() to distinguish. */
\
-if (const auto *ArgsWritten = D->getTemplateArgsAsWritten()) {
\
- /* The args that remains unspecialized. */
\
- TRY_TO(TraverseTemplateArgumentLocsHelper(
\
- ArgsWritten->getTemplateArgs(), ArgsWritten->NumTemplateArgs));
\
+ is the only callback that's made for this instantiation. */
\
+if (TSK != TSK_ImplicitInstantiation) {
\
+ if (const auto *ArgsWritten = D->getTemplateArgsAsWritten()) {
\
+/* The args that remains unspecialized. */
\
+TRY_TO(TraverseTemplateArgumentLocsHelper(
\
+ArgsWritten->getTemplateArgs(), ArgsWritten->NumTemplateArgs));
\
+ }
\
}
\
[libclc] [libclc] use default paths with find_program when possible (PR #105969)
hvdijk wrote: Apologies, but I'm having a bit of trouble understanding the scenario that this PR addresses. It looks like it's meant to handle the case where `LLVM_TOOLS_BINARY_DIR` does not contain the LLVM binaries, is that right? In that case, why can `LLVM_TOOLS_BINARY_DIR` not instead be set to a path that does contain the LLVM binaries? https://github.com/llvm/llvm-project/pull/105969 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] use default paths with find_program when possible (PR #105969)
@@ -55,7 +55,7 @@ if( LIBCLC_STANDALONE_BUILD OR CMAKE_SOURCE_DIR STREQUAL
CMAKE_CURRENT_SOURCE_DI
# Import required tools
if( NOT EXISTS ${LIBCLC_CUSTOM_LLVM_TOOLS_BINARY_DIR} )
foreach( tool IN ITEMS clang llvm-as llvm-link opt )
- find_program( LLVM_TOOL_${tool} ${tool} PATHS ${LLVM_TOOLS_BINARY_DIR}
NO_DEFAULT_PATH )
+find_program( LLVM_TOOL_${tool} ${tool} PATHS ${LLVM_TOOLS_BINARY_DIR} )
hvdijk wrote:
At
https://github.com/RossComputerGuy/llvm-project/blob/056e0f9b7c7b788ad0d85a1479000fd1af4f98ce/libclc/CMakeLists.txt#L100-L104
there is a check for missing tools. This check would not work if using the
imported targets if LLVM CMake files are installed, but the binaries are
missing, which because of the way LLVM is split in distros is something that
can easily happen.
https://github.com/llvm/llvm-project/pull/105969
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] use default paths with find_program when possible (PR #105969)
hvdijk wrote: > > Apologies, but I'm having a bit of trouble understanding the scenario that > > this PR addresses. > > Nixpkgs adds the tools being used to `$PATH` so find program needs to use > path. This PR enables inadvertent errors on non-Nix systems though. When a specific LLVM path is used, and a binary is missing there, but a different binary with the same name is available in `$PATH`, we don't normally want that other binary to be used, it is quite possibly from a wrong version of LLVM. Right now, this is detected early at CMake time, and with this PR, it would no longer be. If standalone builds continue to be used, could this be avoided by changing the Nixpkgs build to install symlinks to all needed tools in a single directory (possibly a temporary directory populated during the libclc build), and making that directory available as `LLVM_TOOLS_BINARY_DIR`? https://github.com/llvm/llvm-project/pull/105969 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [RecursiveASTVisitor] Skip implicit instantiations. (PR #110899)
@@ -2069,22 +2069,24 @@ bool
RecursiveASTVisitor::TraverseTemplateArgumentLocsHelper(
#define DEF_TRAVERSE_TMPL_SPEC_DECL(TMPLDECLKIND, DECLKIND)
\
DEF_TRAVERSE_DECL(TMPLDECLKIND##TemplateSpecializationDecl, {
\
+auto TSK = D->getTemplateSpecializationKind();
\
/* For implicit instantiations ("set x;"), we don't want to
\
recurse at all, since the instatiated template isn't written in
\
the source code anywhere. (Note the instatiated *type* --
\
set -- is written, and will still get a callback of
\
TemplateSpecializationType). For explicit instantiations
\
("template set;"), we do need a callback, since this
\
- is the only callback that's made for this instantiation.
\
- We use getTemplateArgsAsWritten() to distinguish. */
\
-if (const auto *ArgsWritten = D->getTemplateArgsAsWritten()) {
\
- /* The args that remains unspecialized. */
\
- TRY_TO(TraverseTemplateArgumentLocsHelper(
\
- ArgsWritten->getTemplateArgs(), ArgsWritten->NumTemplateArgs));
\
+ is the only callback that's made for this instantiation. */
\
+if (TSK != TSK_ImplicitInstantiation) {
\
hvdijk wrote:
Thanks. It doesn't seem like the same situation as `TraverseFunctionHelper` to
me: there, the logic is that if it's an implicit instantiation, that
instantiation isn't written in the source code anywhere, so should be skipped
by AST traversal. But the check in `TraverseFunctionHelper` assumes we possibly
did end up in an implicit instantiation anyway, and then it needs to be handled
in some appropriate way. Still, I think you're probably right that this should
check `TSK_Undeclared` as well. I don't think that can be covered by this
clang-tidy check, but I can at least check that it doesn't break any other
tests.
https://github.com/llvm/llvm-project/pull/110899
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [RecursiveASTVisitor] Skip implicit instantiations. (PR #110899)
@@ -2069,22 +2069,24 @@ bool
RecursiveASTVisitor::TraverseTemplateArgumentLocsHelper(
#define DEF_TRAVERSE_TMPL_SPEC_DECL(TMPLDECLKIND, DECLKIND)
\
DEF_TRAVERSE_DECL(TMPLDECLKIND##TemplateSpecializationDecl, {
\
+auto TSK = D->getTemplateSpecializationKind();
\
/* For implicit instantiations ("set x;"), we don't want to
\
recurse at all, since the instatiated template isn't written in
\
the source code anywhere. (Note the instatiated *type* --
\
set -- is written, and will still get a callback of
\
TemplateSpecializationType). For explicit instantiations
\
("template set;"), we do need a callback, since this
\
- is the only callback that's made for this instantiation.
\
- We use getTemplateArgsAsWritten() to distinguish. */
\
-if (const auto *ArgsWritten = D->getTemplateArgsAsWritten()) {
\
- /* The args that remains unspecialized. */
\
- TRY_TO(TraverseTemplateArgumentLocsHelper(
\
- ArgsWritten->getTemplateArgs(), ArgsWritten->NumTemplateArgs));
\
+ is the only callback that's made for this instantiation. */
\
+if (TSK != TSK_ImplicitInstantiation) {
\
hvdijk wrote:
Actually, we are in a loop going over the children of a
`*TemplateSpecializationDecl`, is it possible to encounter `TSK_Undeclared`
there in the first place? It's the process of instantiation that leads to a
child of `*TemplateSpecializationDecl`, is it not? For `TSK_Undeclared`, I
think that should not happen.
https://github.com/llvm/llvm-project/pull/110899
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [RecursiveASTVisitor] Skip implicit instantiations. (PR #110899)
@@ -2069,22 +2069,24 @@ bool
RecursiveASTVisitor::TraverseTemplateArgumentLocsHelper(
#define DEF_TRAVERSE_TMPL_SPEC_DECL(TMPLDECLKIND, DECLKIND)
\
DEF_TRAVERSE_DECL(TMPLDECLKIND##TemplateSpecializationDecl, {
\
+auto TSK = D->getTemplateSpecializationKind();
\
/* For implicit instantiations ("set x;"), we don't want to
\
recurse at all, since the instatiated template isn't written in
\
the source code anywhere. (Note the instatiated *type* --
\
set -- is written, and will still get a callback of
\
TemplateSpecializationType). For explicit instantiations
\
("template set;"), we do need a callback, since this
\
- is the only callback that's made for this instantiation.
\
- We use getTemplateArgsAsWritten() to distinguish. */
\
-if (const auto *ArgsWritten = D->getTemplateArgsAsWritten()) {
\
- /* The args that remains unspecialized. */
\
- TRY_TO(TraverseTemplateArgumentLocsHelper(
\
- ArgsWritten->getTemplateArgs(), ArgsWritten->NumTemplateArgs));
\
+ is the only callback that's made for this instantiation. */
\
+if (TSK != TSK_ImplicitInstantiation) {
\
hvdijk wrote:
But running with some extra debug checks clearly shows that that does happen,
and therefore that my understanding is wrong. Okay then. However, no
`TSK_Undeclared` has any `TemplateArgsAsWritten` in the testing that I ran, so
all `TSK_Undeclared` were already implicitly skipped. I'm happy to explicitly
skip them instead.
https://github.com/llvm/llvm-project/pull/110899
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [RecursiveASTVisitor] Skip implicit instantiations. (PR #110899)
https://github.com/hvdijk updated
https://github.com/llvm/llvm-project/pull/110899
>From a334eb150b2d47e7e7cf13123f01c4513832e848 Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Wed, 2 Oct 2024 18:14:38 +0100
Subject: [PATCH] [RecursiveASTVisitor] Skip implicit instantiations.
In DEF_TRAVERSE_TMPL_SPEC_DECL, we attempted to skip implicit
instantiations by detecting that D->getTemplateArgsAsWritten() returns
nullptr, but as this test shows, it is possible for that to return a
non-null pointer even for implicit instantiations. Explicitly check for
this case instead.
Fixes #110502
---
.../checkers/modernize/type-traits.cpp| 21 +++
clang/include/clang/AST/RecursiveASTVisitor.h | 16 +++---
2 files changed, 30 insertions(+), 7 deletions(-)
diff --git
a/clang-tools-extra/test/clang-tidy/checkers/modernize/type-traits.cpp
b/clang-tools-extra/test/clang-tidy/checkers/modernize/type-traits.cpp
index 72241846384bcf..854ffa7928635c 100644
--- a/clang-tools-extra/test/clang-tidy/checkers/modernize/type-traits.cpp
+++ b/clang-tools-extra/test/clang-tidy/checkers/modernize/type-traits.cpp
@@ -14,11 +14,22 @@ namespace std {
static constexpr bool value = true;
};
+ template
+ static constexpr bool is_same_v = is_same::value; // NOLINT
+
template
struct enable_if {
using type = T;
};
+ template
+ using enable_if_t = typename enable_if::type; // NOLINT
+
+ template
+ struct remove_reference {
+using type = T;
+ };
+
inline namespace __std_lib_version1 {
template
struct add_const {
@@ -117,3 +128,13 @@ namespace my_std = std;
using Alias = my_std::add_const::type;
// CHECK-MESSAGES: :[[@LINE-1]]:15: warning: use c++14 style type templates
// CHECK-FIXES: using Alias = my_std::add_const_t;
+
+template
+struct ImplicitlyInstantiatedConstructor {
+ template >>
+ ImplicitlyInstantiatedConstructor(U) {}
+};
+
+const ImplicitlyInstantiatedConstructor
ImplicitInstantiation(std::remove_reference::type(123));
+// CHECK-MESSAGES: :[[@LINE-1]]:68: warning: use c++14 style type templates
+// CHECK-FIXES: const ImplicitlyInstantiatedConstructor
ImplicitInstantiation(std::remove_reference_t(123));
diff --git a/clang/include/clang/AST/RecursiveASTVisitor.h
b/clang/include/clang/AST/RecursiveASTVisitor.h
index cd9947f7ab9805..7e843d9f365b75 100644
--- a/clang/include/clang/AST/RecursiveASTVisitor.h
+++ b/clang/include/clang/AST/RecursiveASTVisitor.h
@@ -2069,22 +2069,24 @@ bool
RecursiveASTVisitor::TraverseTemplateArgumentLocsHelper(
#define DEF_TRAVERSE_TMPL_SPEC_DECL(TMPLDECLKIND, DECLKIND)
\
DEF_TRAVERSE_DECL(TMPLDECLKIND##TemplateSpecializationDecl, {
\
+auto TSK = D->getTemplateSpecializationKind();
\
/* For implicit instantiations ("set x;"), we don't want to
\
recurse at all, since the instatiated template isn't written in
\
the source code anywhere. (Note the instatiated *type* --
\
set -- is written, and will still get a callback of
\
TemplateSpecializationType). For explicit instantiations
\
("template set;"), we do need a callback, since this
\
- is the only callback that's made for this instantiation.
\
- We use getTemplateArgsAsWritten() to distinguish. */
\
-if (const auto *ArgsWritten = D->getTemplateArgsAsWritten()) {
\
- /* The args that remains unspecialized. */
\
- TRY_TO(TraverseTemplateArgumentLocsHelper(
\
- ArgsWritten->getTemplateArgs(), ArgsWritten->NumTemplateArgs));
\
+ is the only callback that's made for this instantiation. */
\
+if (TSK != TSK_Undeclared && TSK != TSK_ImplicitInstantiation) {
\
+ if (const auto *ArgsWritten = D->getTemplateArgsAsWritten()) {
\
+/* The args that remains unspecialized. */
\
+TRY_TO(TraverseTemplateArgumentLocsHelper(
\
+ArgsWritten->getTemplateArgs(), ArgsWritten->NumTemplateArgs));
\
+ }
\
}
\
\
if (getDerived().shouldVisitTemplateInstantiations() ||
\
-D->getTemplateSpecializationKind() == TSK_ExplicitSpecialization) {
\
+TSK == TSK_ExplicitSpecialization) {
\
/* Traverse base definition for explicit specializations */
\
TRY_TO(Traverse##DECLKIND##Helper(D));
\
} else {
[clang] [llvm] Call setup_host_tools for more tools. (PR #118635)
hvdijk wrote: > I don't know what others would think about this, but without the subsequent > changes that make use of this, I don't think this should be landed in LLVM. > After all, plans might change, the community might refuse the subsequent PRs > etc, resulting in dead code lying around. I'm not going to argue strongly -- after all, in the upstream PR, I did say I considered submitting this, decided against it, and was asked to submit this anyway -- but if plans change, if DPC++ either never submits its libsycl or LLVM rejects it, LLVM will still have to come up with some other SYCL runtime and that will still need this PR. https://github.com/llvm/llvm-project/pull/118635 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] Call setup_host_tools for more tools. (PR #118635)
https://github.com/hvdijk created
https://github.com/llvm/llvm-project/pull/118635
This change allows external projects to call for host versions of
clang-offload-bundler, clang-offload-packager, and llvm-ar.
This has no effect in LLVM itself, which does not make use of this, but is
going to be used in DPC++'s libsycl. That is meant to be upstreamed at some
point, so it probably makes sense to get this into LLVM already and avoid
future conflicts.
>From a378734bf0600b06338c9d294a1da6d1315be7ac Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Wed, 4 Dec 2024 13:40:58 +
Subject: [PATCH] Call setup_host_tools for more tools.
This change allows external projects to call for host versions of
clang-offload-bundler, clang-offload-packager, and llvm-ar.
This has no effect in LLVM itself, which does not make use of this, but
is going to be used in DPC++'s libsycl. That is meant to be upstreamed
at some point, so it probably makes sense to get this into LLVM already
and avoid future conflicts.
---
clang/tools/clang-offload-bundler/CMakeLists.txt | 3 +++
clang/tools/clang-offload-packager/CMakeLists.txt | 3 +++
llvm/tools/llvm-ar/CMakeLists.txt | 2 ++
3 files changed, 8 insertions(+)
diff --git a/clang/tools/clang-offload-bundler/CMakeLists.txt
b/clang/tools/clang-offload-bundler/CMakeLists.txt
index dec2881589a538..5b26951b96f5db 100644
--- a/clang/tools/clang-offload-bundler/CMakeLists.txt
+++ b/clang/tools/clang-offload-bundler/CMakeLists.txt
@@ -12,6 +12,9 @@ add_clang_tool(clang-offload-bundler
intrinsics_gen
)
+setup_host_tool(clang-offload-bundler CLANG_OFFLOAD_BUNDLER
+ clang-offload-bundler_exe clang-offload-bundler_target)
+
set(CLANG_OFFLOAD_BUNDLER_LIB_DEPS
clangBasic
clangDriver
diff --git a/clang/tools/clang-offload-packager/CMakeLists.txt
b/clang/tools/clang-offload-packager/CMakeLists.txt
index 1c29e376452c12..ba446e18bd326b 100644
--- a/clang/tools/clang-offload-packager/CMakeLists.txt
+++ b/clang/tools/clang-offload-packager/CMakeLists.txt
@@ -11,6 +11,9 @@ add_clang_tool(clang-offload-packager
${tablegen_deps}
)
+setup_host_tool(clang-offload-packager CLANG_OFFLOAD_PACKAGER_EXE
+ clang-offload-packager_exe clang-offload-packager_target)
+
clang_target_link_libraries(clang-offload-packager
PRIVATE
clangBasic
diff --git a/llvm/tools/llvm-ar/CMakeLists.txt
b/llvm/tools/llvm-ar/CMakeLists.txt
index 4d0718f8cefe62..30e2507c6e6f25 100644
--- a/llvm/tools/llvm-ar/CMakeLists.txt
+++ b/llvm/tools/llvm-ar/CMakeLists.txt
@@ -19,6 +19,8 @@ add_llvm_tool(llvm-ar
GENERATE_DRIVER
)
+setup_host_tool(llvm-ar LLVM_AR llvm_ar_exe llvm_ar_target)
+
add_llvm_tool_symlink(llvm-ranlib llvm-ar)
add_llvm_tool_symlink(llvm-lib llvm-ar)
add_llvm_tool_symlink(llvm-dlltool llvm-ar)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [DebugInfo] Update DIBuilder insertion to take InsertPosition (PR #126059)
https://github.com/hvdijk updated
https://github.com/llvm/llvm-project/pull/126059
>From 6929e0ab55c0b5ed9904ec93ae6f7c284b46081b Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Fri, 7 Feb 2025 17:39:18 +
Subject: [PATCH] [DebugInfo] Update DIBuilder insertion to take InsertPosition
After #124287 updated several functions to return iterators rather than
Instruction *, it was no longer straightforward to pass their result to
DIBuilder. This commit updates DIBuilder methods to accept an
InsertPosition instead, so that they can be called with an iterator
(preferred), or with a deprecation warning an Instruction *, or a
BasicBlock *. This commit also updates the existing calls to the
DIBuilder methods to pass in iterators.
---
clang/lib/CodeGen/CGDebugInfo.cpp | 17 +--
llvm/include/llvm/IR/DIBuilder.h | 62 ++
llvm/lib/IR/DIBuilder.cpp | 116 +-
llvm/lib/IR/DebugInfo.cpp | 41 ---
llvm/lib/Transforms/Coroutines/CoroFrame.cpp | 4 +-
llvm/lib/Transforms/Scalar/SROA.cpp | 2 +-
llvm/lib/Transforms/Utils/Debugify.cpp| 14 ++-
llvm/lib/Transforms/Utils/Local.cpp | 23 +---
.../Utils/PromoteMemoryToRegister.cpp | 3 +-
llvm/unittests/IR/IRBuilderTest.cpp | 12 +-
.../Transforms/Utils/CloningTest.cpp | 5 +-
11 files changed, 99 insertions(+), 200 deletions(-)
diff --git a/clang/lib/CodeGen/CGDebugInfo.cpp
b/clang/lib/CodeGen/CGDebugInfo.cpp
index db595796c067e98..c80bc866e31edf8 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -4897,7 +4897,7 @@ llvm::DILocalVariable *CGDebugInfo::EmitDeclare(const
VarDecl *VD,
llvm::DILocation::get(CGM.getLLVMContext(),
Line,
Column, Scope,
CurInlinedAt),
- Builder.GetInsertBlock());
+ Builder.GetInsertBlock()->end());
}
}
}
@@ -4965,7 +4965,7 @@ llvm::DILocalVariable *CGDebugInfo::EmitDeclare(const
VarDecl *VD,
DBuilder.insertDeclare(Storage, D, DBuilder.createExpression(Expr),
llvm::DILocation::get(CGM.getLLVMContext(), Line,
Column, Scope, CurInlinedAt),
- Builder.GetInsertBlock());
+ Builder.GetInsertBlock()->end());
return D;
}
@@ -5071,7 +5071,7 @@ llvm::DILocalVariable *CGDebugInfo::EmitDeclare(const
BindingDecl *BD,
DBuilder.insertDeclare(Storage, D, DBuilder.createExpression(Expr),
llvm::DILocation::get(CGM.getLLVMContext(), Line,
Column, Scope, CurInlinedAt),
- Builder.GetInsertBlock());
+ Builder.GetInsertBlock()->end());
return D;
}
@@ -5118,7 +5118,7 @@ void CGDebugInfo::EmitLabel(const LabelDecl *D,
CGBuilderTy &Builder) {
DBuilder.insertLabel(L,
llvm::DILocation::get(CGM.getLLVMContext(), Line,
Column,
Scope, CurInlinedAt),
- Builder.GetInsertBlock());
+ Builder.GetInsertBlock()->end());
}
llvm::DIType *CGDebugInfo::CreateSelfType(const QualType &QualTy,
@@ -5196,9 +5196,10 @@ void CGDebugInfo::EmitDeclareOfBlockDeclRefVariable(
LexicalBlockStack.back(), CurInlinedAt);
auto *Expr = DBuilder.createExpression(addr);
if (InsertPoint)
-DBuilder.insertDeclare(Storage, D, Expr, DL, InsertPoint);
+DBuilder.insertDeclare(Storage, D, Expr, DL, InsertPoint->getIterator());
else
-DBuilder.insertDeclare(Storage, D, Expr, DL, Builder.GetInsertBlock());
+DBuilder.insertDeclare(Storage, D, Expr, DL,
+ Builder.GetInsertBlock()->end());
}
llvm::DILocalVariable *
@@ -5381,7 +5382,7 @@ void
CGDebugInfo::EmitDeclareOfBlockLiteralArgVariable(const CGBlockInfo &block,
DBuilder.insertDeclare(Alloca, debugVar, DBuilder.createExpression(),
llvm::DILocation::get(CGM.getLLVMContext(), line,
column, scope, CurInlinedAt),
- Builder.GetInsertBlock());
+ Builder.GetInsertBlock()->end());
}
llvm::DIDerivedType *
@@ -5861,7 +5862,7 @@ void CGDebugInfo::EmitPseudoVariable(CGBuilderTy &Builder,
if (auto InsertPoint = Value->getInsertionPointAfterDef()) {
DBuilder.insertDbgValueIntrinsic(Value, D, DBuilder.createExpression(),
DIL,
- &**InsertPoint);
+ *InsertPoint);
}
}
diff --git a/llvm/include/llvm/IR/DIBuilder.h b/llvm/include/llvm/IR/DIBuilder.h
index 6c479415b9ed274..71455a9337b1fa9
[clang] [llvm] [DebugInfo] Update DIBuilder insertion to take InsertPosition (PR #126059)
https://github.com/hvdijk created
https://github.com/llvm/llvm-project/pull/126059
After #124287 updated several functions to return iterators rather than
Instruction *, it was no longer straightforward to pass their result to
DIBuilder. This commit updates DIBuilder methods to accept an InsertPosition
instead, so that they can be called with an iterator (preferred), or with a
deprecation warning an Instruction *, or a BasicBlock *. This commit also
updates the existing calls to the DIBuilder methods to pass in iterators.
>From a815481931e6b1970d61228ff49fde82b9fda2c8 Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Thu, 6 Feb 2025 12:57:09 +
Subject: [PATCH] [DebugInfo] Update DIBuilder insertion to take InsertPosition
After #124287 updated several functions to return iterators rather than
Instruction *, it was no longer straightforward to pass their result to
DIBuilder. This commit updates DIBuilder methods to accept an
InsertPosition instead, so that they can be called with an iterator
(preferred), or with a deprecation warning an Instruction *, or a
BasicBlock *. This commit also updates the existing calls to the
DIBuilder methods to pass in iterators.
---
clang/lib/CodeGen/CGDebugInfo.cpp | 17 +--
llvm/include/llvm/IR/DIBuilder.h | 62 ++
llvm/lib/IR/DIBuilder.cpp | 116 +-
llvm/lib/IR/DebugInfo.cpp | 41 ---
llvm/lib/Transforms/Coroutines/CoroFrame.cpp | 4 +-
llvm/lib/Transforms/Scalar/SROA.cpp | 2 +-
llvm/lib/Transforms/Utils/Debugify.cpp| 14 ++-
llvm/lib/Transforms/Utils/Local.cpp | 22 +---
.../Utils/PromoteMemoryToRegister.cpp | 3 +-
llvm/unittests/IR/IRBuilderTest.cpp | 12 +-
.../Transforms/Utils/CloningTest.cpp | 5 +-
11 files changed, 98 insertions(+), 200 deletions(-)
diff --git a/clang/lib/CodeGen/CGDebugInfo.cpp
b/clang/lib/CodeGen/CGDebugInfo.cpp
index db595796c067e98..c80bc866e31edf8 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -4897,7 +4897,7 @@ llvm::DILocalVariable *CGDebugInfo::EmitDeclare(const
VarDecl *VD,
llvm::DILocation::get(CGM.getLLVMContext(),
Line,
Column, Scope,
CurInlinedAt),
- Builder.GetInsertBlock());
+ Builder.GetInsertBlock()->end());
}
}
}
@@ -4965,7 +4965,7 @@ llvm::DILocalVariable *CGDebugInfo::EmitDeclare(const
VarDecl *VD,
DBuilder.insertDeclare(Storage, D, DBuilder.createExpression(Expr),
llvm::DILocation::get(CGM.getLLVMContext(), Line,
Column, Scope, CurInlinedAt),
- Builder.GetInsertBlock());
+ Builder.GetInsertBlock()->end());
return D;
}
@@ -5071,7 +5071,7 @@ llvm::DILocalVariable *CGDebugInfo::EmitDeclare(const
BindingDecl *BD,
DBuilder.insertDeclare(Storage, D, DBuilder.createExpression(Expr),
llvm::DILocation::get(CGM.getLLVMContext(), Line,
Column, Scope, CurInlinedAt),
- Builder.GetInsertBlock());
+ Builder.GetInsertBlock()->end());
return D;
}
@@ -5118,7 +5118,7 @@ void CGDebugInfo::EmitLabel(const LabelDecl *D,
CGBuilderTy &Builder) {
DBuilder.insertLabel(L,
llvm::DILocation::get(CGM.getLLVMContext(), Line,
Column,
Scope, CurInlinedAt),
- Builder.GetInsertBlock());
+ Builder.GetInsertBlock()->end());
}
llvm::DIType *CGDebugInfo::CreateSelfType(const QualType &QualTy,
@@ -5196,9 +5196,10 @@ void CGDebugInfo::EmitDeclareOfBlockDeclRefVariable(
LexicalBlockStack.back(), CurInlinedAt);
auto *Expr = DBuilder.createExpression(addr);
if (InsertPoint)
-DBuilder.insertDeclare(Storage, D, Expr, DL, InsertPoint);
+DBuilder.insertDeclare(Storage, D, Expr, DL, InsertPoint->getIterator());
else
-DBuilder.insertDeclare(Storage, D, Expr, DL, Builder.GetInsertBlock());
+DBuilder.insertDeclare(Storage, D, Expr, DL,
+ Builder.GetInsertBlock()->end());
}
llvm::DILocalVariable *
@@ -5381,7 +5382,7 @@ void
CGDebugInfo::EmitDeclareOfBlockLiteralArgVariable(const CGBlockInfo &block,
DBuilder.insertDeclare(Alloca, debugVar, DBuilder.createExpression(),
llvm::DILocation::get(CGM.getLLVMContext(), line,
column, scope, CurInlinedAt),
- Builder.GetInsertBlock());
+ Builder.GetInsertBlock()->end());
}
llvm::DIDerivedType *
@@ -5861,7 +5862,
[clang] [llvm] [DebugInfo] Update DIBuilder insertion to take InsertPosition (PR #126059)
@@ -1708,19 +1706,9 @@ static void insertDbgValueOrDbgVariableRecord(DIBuilder
&Builder, Value *DV,
static void insertDbgValueOrDbgVariableRecordAfter(
DIBuilder &Builder, Value *DV, DILocalVariable *DIVar, DIExpression
*DIExpr,
-const DebugLoc &NewLoc, BasicBlock::iterator Instr) {
- if (!UseNewDbgInfoFormat) {
-auto DbgVal = Builder.insertDbgValueIntrinsic(DV, DIVar, DIExpr, NewLoc,
- (Instruction *)nullptr);
-cast(DbgVal)->insertAfter(Instr);
- } else {
-// RemoveDIs: if we're using the new debug-info format, allocate a
-// DbgVariableRecord directly instead of a dbg.value intrinsic.
-ValueAsMetadata *DVAM = ValueAsMetadata::get(DV);
-DbgVariableRecord *DV =
-new DbgVariableRecord(DVAM, DIVar, DIExpr, NewLoc.get());
-Instr->getParent()->insertDbgRecordAfter(DV, &*Instr);
- }
+const DebugLoc &NewLoc, Instruction *Instr) {
+ insertDbgValueOrDbgVariableRecord(Builder, DV, DIVar, DIExpr, NewLoc,
+std::next(Instr->getIterator()));
hvdijk wrote:
I think you're right, thanks, will update and re-test.
https://github.com/llvm/llvm-project/pull/126059
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [DebugInfo] Update DIBuilder insertion to take InsertPosition (PR #126059)
hvdijk wrote: > Is this intended to be cherry-picked into the release branch or not? Yes, I was hoping that we were still early enough to be able to cherry-pick it without issues, especially as the aim is to restore a certain level of compatibility with previous LLVM releases. If that is not the case though, then at least it will be helpful to know that only LLVM 20 will require workarounds. https://github.com/llvm/llvm-project/pull/126059 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [DebugInfo] Update DIBuilder insertion to take InsertPosition (PR #126059)
@@ -1686,7 +1686,8 @@ LLVMDbgRecordRef LLVMDIBuilderInsertDeclareRecordBefore( DbgInstPtr DbgInst = unwrap(Builder)->insertDeclare( unwrap(Storage), unwrap(VarInfo), unwrap(Expr), unwrap(DL), - unwrap(Instr)); + Instr ? InsertPosition(unwrap(Instr)->getIterator()) +: nullptr); hvdijk wrote: You're right. Previously, a call with `!Instr` would result in a call to `insertDeclare(..., /*InsertBefore=*/nullptr)` which results in `insertDeclare(..., /*InsertBB=*/nullptr->getParent(), /*InsertBefore=*/nullptr)`, so it would (on typical systems) result in a crash already. At the same time, previously, `insertLabel(..., /*InsertBefore=*/nullptr)` would result in `insertLabel(..., /*InsertBB=*/nullptr, /*InsertBefore=*/nullptr)` which specifically does not insert anything. And `insertDbgValueIntrinsic(..., /*InsertBefore=*/nullptr)` is special-cased to call `insertDbgValueIntrinsic(..., /*InsertBB=*/nullptr, /*InsertBefore=*/nullptr)` the same way, *but* the latter calls `insertDbgVariableRecord` unconditionally and hits the existing `assert(InsertBefore || InsertBB);` assert. This is a messy situation and in this PR I tried to just keep that exactly the same. What previously worked should still work. What previously didn't work should still not work. https://github.com/llvm/llvm-project/pull/126059 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [SYCL] Allow neon attributes for ARM host (PR #94229)
https://github.com/hvdijk updated
https://github.com/llvm/llvm-project/pull/94229
>From 481f6c53379abb4b7240f25b55fb90b54b9454c1 Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Mon, 3 Jun 2024 15:03:17 +0100
Subject: [PATCH] [SYCL] Allow neon attributes for ARM host
We permit neon attributes in CUDA device code, but this permission was
only for CUDA device code. The same permission makes sense for SYCL
device code as well, especially now that neon attributes are used in
glibc headers.
---
clang/lib/Sema/SemaType.cpp| 8
clang/test/SemaSYCL/neon-attrs.cpp | 15 +++
2 files changed, 19 insertions(+), 4 deletions(-)
create mode 100644 clang/test/SemaSYCL/neon-attrs.cpp
diff --git a/clang/lib/Sema/SemaType.cpp b/clang/lib/Sema/SemaType.cpp
index 83464c50b4b238..266f047b1a6836 100644
--- a/clang/lib/Sema/SemaType.cpp
+++ b/clang/lib/Sema/SemaType.cpp
@@ -8287,10 +8287,10 @@ static bool verifyValidIntegerConstantExpr(Sema &S,
const ParsedAttr &Attr,
/// match one of the standard Neon vector types.
static void HandleNeonVectorTypeAttr(QualType &CurType, const ParsedAttr &Attr,
Sema &S, VectorKind VecKind) {
- bool IsTargetCUDAAndHostARM = false;
- if (S.getLangOpts().CUDAIsDevice) {
+ bool IsTargetDeviceAndHostARM = false;
+ if (S.getLangOpts().CUDAIsDevice || S.getLangOpts().SYCLIsDevice) {
const TargetInfo *AuxTI = S.getASTContext().getAuxTargetInfo();
-IsTargetCUDAAndHostARM =
+IsTargetDeviceAndHostARM =
AuxTI && (AuxTI->getTriple().isAArch64() ||
AuxTI->getTriple().isARM());
}
@@ -8327,7 +8327,7 @@ static void HandleNeonVectorTypeAttr(QualType &CurType,
const ParsedAttr &Attr,
// Only certain element types are supported for Neon vectors.
if (!isPermittedNeonBaseType(CurType, VecKind, S) &&
- !IsTargetCUDAAndHostARM) {
+ !IsTargetDeviceAndHostARM) {
S.Diag(Attr.getLoc(), diag::err_attribute_invalid_vector_type) << CurType;
Attr.setInvalid();
return;
diff --git a/clang/test/SemaSYCL/neon-attrs.cpp
b/clang/test/SemaSYCL/neon-attrs.cpp
new file mode 100644
index 00..b1fd947d4a8883
--- /dev/null
+++ b/clang/test/SemaSYCL/neon-attrs.cpp
@@ -0,0 +1,15 @@
+// Host compilation on ARM with neon enabled (no errors expected).
+// RUN: %clang_cc1 -triple aarch64-linux-gnu -target-feature +neon
-fsyntax-only -verify=quiet %s
+
+// Host compilation on ARM with neon disabled.
+// RUN: %clang_cc1 -triple aarch64-linux-gnu -target-feature -neon
-fsyntax-only -verify %s
+
+// Device compilation on ARM (no errors expected).
+// RUN: %clang_cc1 -triple spirv64 -aux-triple aarch64-linux-gnu
-fsycl-is-device -fsyntax-only -verify=quiet %s
+
+// quiet-no-diagnostics
+typedef __attribute__((neon_vector_type(4))) float float32x4_t;
+// expected-error@-1 {{'neon_vector_type' attribute is not supported on
targets missing 'neon', 'mve', 'sve' or 'sme'}}
+typedef unsigned char poly8_t;
+typedef __attribute__((neon_polyvector_type(8))) poly8_t poly8x8_t;
+// expected-error@-1 {{'neon_polyvector_type' attribute is not supported on
targets missing 'neon' or 'mve'}}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [SYCL] Allow neon attributes for ARM host (PR #94229)
hvdijk wrote: Rebased to address a conflict with changes that have gone in since I first submitted this, the PR remains otherwise identical and waiting to be reviewed. https://github.com/llvm/llvm-project/pull/94229 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [SYCL] Allow neon attributes for ARM host (PR #94229)
https://github.com/hvdijk updated
https://github.com/llvm/llvm-project/pull/94229
>From b1a53997e9378954da353ea1f0d8f03a8f19736f Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Mon, 23 Dec 2024 13:19:56 +
Subject: [PATCH] [SYCL] Allow neon attributes for ARM host
We permit neon attributes in CUDA device code, but this permission was
only for CUDA device code. The same permission makes sense for SYCL
device code as well, especially now that neon attributes are used in
glibc headers.
---
clang/lib/Sema/SemaType.cpp| 8
clang/test/SemaSYCL/neon-attrs.cpp | 10 ++
2 files changed, 14 insertions(+), 4 deletions(-)
create mode 100644 clang/test/SemaSYCL/neon-attrs.cpp
diff --git a/clang/lib/Sema/SemaType.cpp b/clang/lib/Sema/SemaType.cpp
index 83464c50b4b238..266f047b1a6836 100644
--- a/clang/lib/Sema/SemaType.cpp
+++ b/clang/lib/Sema/SemaType.cpp
@@ -8287,10 +8287,10 @@ static bool verifyValidIntegerConstantExpr(Sema &S,
const ParsedAttr &Attr,
/// match one of the standard Neon vector types.
static void HandleNeonVectorTypeAttr(QualType &CurType, const ParsedAttr &Attr,
Sema &S, VectorKind VecKind) {
- bool IsTargetCUDAAndHostARM = false;
- if (S.getLangOpts().CUDAIsDevice) {
+ bool IsTargetDeviceAndHostARM = false;
+ if (S.getLangOpts().CUDAIsDevice || S.getLangOpts().SYCLIsDevice) {
const TargetInfo *AuxTI = S.getASTContext().getAuxTargetInfo();
-IsTargetCUDAAndHostARM =
+IsTargetDeviceAndHostARM =
AuxTI && (AuxTI->getTriple().isAArch64() ||
AuxTI->getTriple().isARM());
}
@@ -8327,7 +8327,7 @@ static void HandleNeonVectorTypeAttr(QualType &CurType,
const ParsedAttr &Attr,
// Only certain element types are supported for Neon vectors.
if (!isPermittedNeonBaseType(CurType, VecKind, S) &&
- !IsTargetCUDAAndHostARM) {
+ !IsTargetDeviceAndHostARM) {
S.Diag(Attr.getLoc(), diag::err_attribute_invalid_vector_type) << CurType;
Attr.setInvalid();
return;
diff --git a/clang/test/SemaSYCL/neon-attrs.cpp
b/clang/test/SemaSYCL/neon-attrs.cpp
new file mode 100644
index 00..fa9282e08947cf
--- /dev/null
+++ b/clang/test/SemaSYCL/neon-attrs.cpp
@@ -0,0 +1,10 @@
+// Host compilation on ARM with neon enabled (no errors expected).
+// RUN: %clang_cc1 -triple aarch64-linux-gnu -target-feature +neon
-fsyntax-only -verify=quiet %s
+
+// Device compilation on ARM (no errors expected).
+// RUN: %clang_cc1 -triple spirv64 -aux-triple aarch64-linux-gnu
-fsycl-is-device -fsyntax-only -verify=quiet %s
+
+// quiet-no-diagnostics
+typedef __attribute__((neon_vector_type(4))) float float32x4_t;
+typedef unsigned char poly8_t;
+typedef __attribute__((neon_polyvector_type(8))) poly8_t poly8x8_t;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [SYCL] Allow neon attributes for ARM host (PR #94229)
hvdijk wrote: The rebase apparently conflicted with #95224. In the test I added, I checked that I preserved the existing behaviour with `-target-feature -neon`, but that behaviour has since changed. Updated to remove that bit of the test. https://github.com/llvm/llvm-project/pull/94229 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [RecursiveASTVisitor] Skip implicit instantiations. (PR #110899)
hvdijk wrote:
ping @sdkrystian
FWIW, `getTemplateArgsAsWritten()` is implemented as
```c++
/// Retrieve the template argument list as written in the sources,
/// if any.
const ASTTemplateArgumentListInfo *getTemplateArgsAsWritten() const {
if (auto *Info = ExplicitInfo.dyn_cast())
return Info->TemplateArgsAsWritten;
return cast(ExplicitInfo);
}
```
and `ExplicitInfo` is defined as
```
/// Further info for explicit template specialization/instantiation.
/// Does not apply to implicit specializations.
SpecializationOrInstantiationInfo ExplicitInfo = nullptr;
```
which does not say that this is guaranteed to be `nullptr` for implicit
specializations, and suggests to me that for implicit instantiations, ignoring
it like I do in this PR is the right thing to do. However, maybe instead it
would be better so that implicit specializations never have any `ExplicitInfo`?
https://github.com/llvm/llvm-project/pull/110899
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 23209eb - Revert "[DebugInfo] Update DIBuilder insertion to take InsertPosition (#126059)"
Author: Harald van Dijk
Date: 2025-02-12T17:50:39Z
New Revision: 23209eb1d9df57ca3419f5abc6b2edcdc0d1dead
URL:
https://github.com/llvm/llvm-project/commit/23209eb1d9df57ca3419f5abc6b2edcdc0d1dead
DIFF:
https://github.com/llvm/llvm-project/commit/23209eb1d9df57ca3419f5abc6b2edcdc0d1dead.diff
LOG: Revert "[DebugInfo] Update DIBuilder insertion to take InsertPosition
(#126059)"
This reverts commit 3ec9f7494b31f2fe51d5ed0e07adcf4b7199def6.
Added:
Modified:
clang/lib/CodeGen/CGDebugInfo.cpp
llvm/include/llvm/IR/DIBuilder.h
llvm/lib/IR/DIBuilder.cpp
llvm/lib/IR/DebugInfo.cpp
llvm/lib/Transforms/Coroutines/CoroFrame.cpp
llvm/lib/Transforms/Scalar/SROA.cpp
llvm/lib/Transforms/Utils/Debugify.cpp
llvm/lib/Transforms/Utils/Local.cpp
llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp
llvm/unittests/IR/IRBuilderTest.cpp
llvm/unittests/Transforms/Utils/CloningTest.cpp
Removed:
diff --git a/clang/lib/CodeGen/CGDebugInfo.cpp
b/clang/lib/CodeGen/CGDebugInfo.cpp
index b679cdddc975b..d5b584ec0f2e9 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -4901,7 +4901,7 @@ llvm::DILocalVariable *CGDebugInfo::EmitDeclare(const
VarDecl *VD,
llvm::DILocation::get(CGM.getLLVMContext(),
Line,
Column, Scope,
CurInlinedAt),
- Builder.GetInsertBlock()->end());
+ Builder.GetInsertBlock());
}
}
}
@@ -4969,7 +4969,7 @@ llvm::DILocalVariable *CGDebugInfo::EmitDeclare(const
VarDecl *VD,
DBuilder.insertDeclare(Storage, D, DBuilder.createExpression(Expr),
llvm::DILocation::get(CGM.getLLVMContext(), Line,
Column, Scope, CurInlinedAt),
- Builder.GetInsertBlock()->end());
+ Builder.GetInsertBlock());
return D;
}
@@ -5075,7 +5075,7 @@ llvm::DILocalVariable *CGDebugInfo::EmitDeclare(const
BindingDecl *BD,
DBuilder.insertDeclare(Storage, D, DBuilder.createExpression(Expr),
llvm::DILocation::get(CGM.getLLVMContext(), Line,
Column, Scope, CurInlinedAt),
- Builder.GetInsertBlock()->end());
+ Builder.GetInsertBlock());
return D;
}
@@ -5122,7 +5122,7 @@ void CGDebugInfo::EmitLabel(const LabelDecl *D,
CGBuilderTy &Builder) {
DBuilder.insertLabel(L,
llvm::DILocation::get(CGM.getLLVMContext(), Line,
Column,
Scope, CurInlinedAt),
- Builder.GetInsertBlock()->end());
+ Builder.GetInsertBlock());
}
llvm::DIType *CGDebugInfo::CreateSelfType(const QualType &QualTy,
@@ -5200,10 +5200,9 @@ void CGDebugInfo::EmitDeclareOfBlockDeclRefVariable(
LexicalBlockStack.back(), CurInlinedAt);
auto *Expr = DBuilder.createExpression(addr);
if (InsertPoint)
-DBuilder.insertDeclare(Storage, D, Expr, DL, InsertPoint->getIterator());
+DBuilder.insertDeclare(Storage, D, Expr, DL, InsertPoint);
else
-DBuilder.insertDeclare(Storage, D, Expr, DL,
- Builder.GetInsertBlock()->end());
+DBuilder.insertDeclare(Storage, D, Expr, DL, Builder.GetInsertBlock());
}
llvm::DILocalVariable *
@@ -5386,7 +5385,7 @@ void
CGDebugInfo::EmitDeclareOfBlockLiteralArgVariable(const CGBlockInfo &block,
DBuilder.insertDeclare(Alloca, debugVar, DBuilder.createExpression(),
llvm::DILocation::get(CGM.getLLVMContext(), line,
column, scope, CurInlinedAt),
- Builder.GetInsertBlock()->end());
+ Builder.GetInsertBlock());
}
llvm::DIDerivedType *
@@ -5866,7 +5865,7 @@ void CGDebugInfo::EmitPseudoVariable(CGBuilderTy &Builder,
if (auto InsertPoint = Value->getInsertionPointAfterDef()) {
DBuilder.insertDbgValueIntrinsic(Value, D, DBuilder.createExpression(),
DIL,
- *InsertPoint);
+ &**InsertPoint);
}
}
diff --git a/llvm/include/llvm/IR/DIBuilder.h
b/llvm/include/llvm/IR/DIBuilder.h
index 9b729eccda8ee..8bee9f4703dd9 100644
--- a/llvm/include/llvm/IR/DIBuilder.h
+++ b/llvm/include/llvm/IR/DIBuilder.h
@@ -92,15 +92,33 @@ namespace llvm {
/// Create an \a temporary node and track it in \a UnresolvedNodes.
void trackIfUnresolved(MDNode *N);
+/// Internal helper for insertDeclare.
+DbgInstPtr insertDeclare(llvm::Value *Storage, DILocalVariable *VarInfo,
+ DIExpression *Expr, const DILocation
[clang] [llvm] [reland][DebugInfo] Update DIBuilder insertion to take InsertPosition (PR #126967)
hvdijk wrote: This is a reland of #126059 with `insertDeclare`'s overload taking `BasicBlock *` restored, and the changes to calls to that overload reverted. We previously had nothing that relied on its peculiar behavior, therefore the change in its behavior passed testing, but it crossed paths with #118314 which added a call that does rely in inserting not at the end of a block, but before the block's terminator. https://github.com/llvm/llvm-project/pull/126967 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [reland][DebugInfo] Update DIBuilder insertion to take InsertPosition (PR #126967)
https://github.com/hvdijk created
https://github.com/llvm/llvm-project/pull/126967
After #124287 updated several functions to return iterators rather than
Instruction *, it was no longer straightforward to pass their result to
DIBuilder. This commit updates DIBuilder methods to accept an InsertPosition
instead, so that they can be called with an iterator (preferred), or with a
deprecation warning an Instruction *, or a BasicBlock *. This commit also
updates the existing calls to the DIBuilder methods to pass in iterators.
As a special exception, DIBuilder::insertDeclare() keeps a separate overload
accepting a BasicBlock *InsertAtEnd. This is because despite the name, this
method does not insert at the end of the block, therefore this cannot be
handled implicitly by using InsertPosition.
>From 2c13c63f33ef6bf8b3a66cc03f6ac905a47d09de Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Wed, 12 Feb 2025 20:38:30 +
Subject: [PATCH] [reland][DebugInfo] Update DIBuilder insertion to take
InsertPosition
After #124287 updated several functions to return iterators rather than
Instruction *, it was no longer straightforward to pass their result to
DIBuilder. This commit updates DIBuilder methods to accept an
InsertPosition instead, so that they can be called with an iterator
(preferred), or with a deprecation warning an Instruction *, or a
BasicBlock *. This commit also updates the existing calls to the
DIBuilder methods to pass in iterators.
As a special exception, DIBuilder::insertDeclare() keeps a separate
overload accepting a BasicBlock *InsertAtEnd. This is because despite
the name, this method does not insert at the end of the block, therefore
this cannot be handled implicitly by using InsertPosition.
---
clang/lib/CodeGen/CGDebugInfo.cpp | 6 +-
llvm/include/llvm/IR/DIBuilder.h | 52 ++--
llvm/lib/IR/DIBuilder.cpp | 111 +-
llvm/lib/IR/DebugInfo.cpp | 47 +---
llvm/lib/Transforms/Coroutines/CoroFrame.cpp | 4 +-
llvm/lib/Transforms/Scalar/SROA.cpp | 2 +-
llvm/lib/Transforms/Utils/Debugify.cpp| 14 ++-
llvm/lib/Transforms/Utils/Local.cpp | 23 +---
.../Utils/PromoteMemoryToRegister.cpp | 3 +-
llvm/unittests/IR/IRBuilderTest.cpp | 10 +-
.../Transforms/Utils/CloningTest.cpp | 5 +-
11 files changed, 98 insertions(+), 179 deletions(-)
diff --git a/clang/lib/CodeGen/CGDebugInfo.cpp
b/clang/lib/CodeGen/CGDebugInfo.cpp
index d5b584ec0f2e9..46ad11e64c4d5 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -5122,7 +5122,7 @@ void CGDebugInfo::EmitLabel(const LabelDecl *D,
CGBuilderTy &Builder) {
DBuilder.insertLabel(L,
llvm::DILocation::get(CGM.getLLVMContext(), Line,
Column,
Scope, CurInlinedAt),
- Builder.GetInsertBlock());
+ Builder.GetInsertBlock()->end());
}
llvm::DIType *CGDebugInfo::CreateSelfType(const QualType &QualTy,
@@ -5200,7 +5200,7 @@ void CGDebugInfo::EmitDeclareOfBlockDeclRefVariable(
LexicalBlockStack.back(), CurInlinedAt);
auto *Expr = DBuilder.createExpression(addr);
if (InsertPoint)
-DBuilder.insertDeclare(Storage, D, Expr, DL, InsertPoint);
+DBuilder.insertDeclare(Storage, D, Expr, DL, InsertPoint->getIterator());
else
DBuilder.insertDeclare(Storage, D, Expr, DL, Builder.GetInsertBlock());
}
@@ -5865,7 +5865,7 @@ void CGDebugInfo::EmitPseudoVariable(CGBuilderTy &Builder,
if (auto InsertPoint = Value->getInsertionPointAfterDef()) {
DBuilder.insertDbgValueIntrinsic(Value, D, DBuilder.createExpression(),
DIL,
- &**InsertPoint);
+ *InsertPoint);
}
}
diff --git a/llvm/include/llvm/IR/DIBuilder.h b/llvm/include/llvm/IR/DIBuilder.h
index 8bee9f4703dd9..f6520fd855988 100644
--- a/llvm/include/llvm/IR/DIBuilder.h
+++ b/llvm/include/llvm/IR/DIBuilder.h
@@ -92,33 +92,15 @@ namespace llvm {
/// Create an \a temporary node and track it in \a UnresolvedNodes.
void trackIfUnresolved(MDNode *N);
-/// Internal helper for insertDeclare.
-DbgInstPtr insertDeclare(llvm::Value *Storage, DILocalVariable *VarInfo,
- DIExpression *Expr, const DILocation *DL,
- BasicBlock *InsertBB, Instruction *InsertBefore);
-
-/// Internal helper for insertLabel.
-DbgInstPtr insertLabel(DILabel *LabelInfo, const DILocation *DL,
- BasicBlock *InsertBB, Instruction *InsertBefore);
-
/// Internal helper. Track metadata if untracked and insert \p DVR.
-void insertDbgVariableRecord(DbgVariableRecord *DVR, BasicBlock *InsertBB,
- Instruction *InsertBefore,
- bool InsertAtHea
[clang] [llvm] [DebugInfo] Update DIBuilder insertion to take InsertPosition (PR #126059)
https://github.com/hvdijk closed https://github.com/llvm/llvm-project/pull/126059 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [DebugInfo] Update DIBuilder insertion to take InsertPosition (PR #126059)
@@ -1686,7 +1686,8 @@ LLVMDbgRecordRef LLVMDIBuilderInsertDeclareRecordBefore( DbgInstPtr DbgInst = unwrap(Builder)->insertDeclare( unwrap(Storage), unwrap(VarInfo), unwrap(Expr), unwrap(DL), - unwrap(Instr)); + Instr ? InsertPosition(unwrap(Instr)->getIterator()) +: nullptr); hvdijk wrote: Thanks! I think for consistency, it would be nice to update these functions so that they all treat `nullptr` consistently, as a request to create whatever the function says to create but not insert it anywhere. When I have some extra time I'll see if that's easy to do. https://github.com/llvm/llvm-project/pull/126059 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [reland][DebugInfo] Update DIBuilder insertion to take InsertPosition (PR #126967)
https://github.com/hvdijk closed https://github.com/llvm/llvm-project/pull/126967 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [DebugInfo] Update DIBuilder insertion to take InsertPosition (PR #126059)
hvdijk wrote: The buildbot failures look like something conflicted with changes that have since gone in on LLVM. I have reverted the change for now and will check what is going on and update. https://github.com/llvm/llvm-project/pull/126059 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang] [llvm] [clang][flang][Triple][llvm] Add isOffload function to LangOpts and isGPU function to Triple (PR #126956)
hvdijk wrote: > Seems reasonable so long as we know that `SPIR-V` is always a GPU. I'll defer > to SPIR people. It's not. SPIR-V is mostly-device-agnostic and implementations may run it on GPU, on CPU, or on any other device. I'm looking at this while trying to update 94229, I think `isGPU()` should return `false` for SPIR-V, and instead there should be checks for SYCL rather than for SPIR-V as non-SPIR-V SYCL targets need the same handling, does that sound reasonable to you? https://github.com/llvm/llvm-project/pull/126956 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang] [llvm] [clang][flang][Triple][llvm] Add isOffload function to LangOpts and isGPU function to Triple (PR #126956)
hvdijk wrote: It's not a bikeshedding problem that it doesn't handle other SYCL targets consistently though. In some places there are checks for SYCL, in other places there are checks for SPIR-V. https://github.com/llvm/llvm-project/pull/126956 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang] [llvm] [clang][flang][Triple][llvm] Add isOffload function to LangOpts and isGPU function to Triple (PR #126956)
hvdijk wrote: I did include "as non-SPIR-V SYCL targets need the same handling" already in my first comment, so not sure why it gets that strong immediate reaction that ignores that part of it. https://github.com/llvm/llvm-project/pull/126956 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][CodeGen][X86] don't coerce int128 into `{i64,i64}` for SysV-like ABIs (PR #135230)
hvdijk wrote: Both agreed with @nikic that this PR is a good idea and with @efriedma-quic that this does not solve the problem in general. I don't think the latter should stop this from being merged but it would be nice to find something that addresses all cases. > Another fix may be to generate `DW_OP_LLVM_fragment` expressions when > removing the `or` Maybe a bad suggestion, I have not looked into the implementation, but at the point where the `i128` gets split into two `i64`s, could we already update the `#dbg_value` there to use fragments? At that point we have all the required information, and it sounds like it would avoid the problem since there is then no longer any larger-than-`i64` debug info to cause `poison`? https://github.com/llvm/llvm-project/pull/135230 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [ARM, AArch64] Fix passing of structures with aligned base classes (PR #135564)
https://github.com/hvdijk created
https://github.com/llvm/llvm-project/pull/135564
RecordLayout::UnadjustedAlignment was documented as "Maximum of the alignments
of the record members in characters", but
RecordLayout::getUnadjustedAlignment(), which just returns UnadjustedAlignment,
was documented as getting "the record alignment in characters, before alignment
adjustement." These are not the same thing: the former excludes alignment of
base classes, the latter takes it into account.
ItaniumRecordLayoutBuilder::LayoutBase was setting it according to the former,
but the AAPCS calling convention handling, currently the only user, relies on
it being set according to the latter.
Fixes #135551.
>From 9580d5bcea1089c3d28899aaba9b9475869501dd Mon Sep 17 00:00:00 2001
From: Harald van Dijk
Date: Sun, 13 Apr 2025 21:47:54 +0100
Subject: [PATCH] [ARM, AArch64] Fix passing of structures with aligned base
classes
RecordLayout::UnadjustedAlignment was documented as "Maximum of the
alignments of the record members in characters", but
RecordLayout::getUnadjustedAlignment(), which just returns
UnadjustedAlignment, was documented as getting "the record alignment in
characters, before alignment adjustement." These are not the same thing:
the former excludes alignment of base classes, the latter takes it into
account. ItaniumRecordLayoutBuilder::LayoutBase was setting it according
to the former, but the AAPCS calling convention handling, currently the
only user, relies on it being set according to the latter.
Fixes #135551.
---
clang/include/clang/AST/RecordLayout.h | 7 +--
clang/lib/AST/RecordLayoutBuilder.cpp | 1 +
clang/test/CodeGen/aapcs64-align.cpp| 57 +
clang/test/CodeGen/arm-vfp16-arguments2.cpp | 2 +-
4 files changed, 42 insertions(+), 25 deletions(-)
diff --git a/clang/include/clang/AST/RecordLayout.h
b/clang/include/clang/AST/RecordLayout.h
index dd18f9c49f84f..6cf08e76396e2 100644
--- a/clang/include/clang/AST/RecordLayout.h
+++ b/clang/include/clang/AST/RecordLayout.h
@@ -75,8 +75,9 @@ class ASTRecordLayout {
// performance or backwards compatibility preserving (e.g. AIX-ABI).
CharUnits PreferredAlignment;
- // UnadjustedAlignment - Maximum of the alignments of the record members in
- // characters.
+ // UnadjustedAlignment - Alignment of record in characters before alignment
+ // adjustments. Maximum of the alignments of the record members and base
+ // classes in characters.
CharUnits UnadjustedAlignment;
/// RequiredAlignment - The required alignment of the object. In the MS-ABI
@@ -186,7 +187,7 @@ class ASTRecordLayout {
CharUnits getPreferredAlignment() const { return PreferredAlignment; }
/// getUnadjustedAlignment - Get the record alignment in characters, before
- /// alignment adjustement.
+ /// alignment adjustment.
CharUnits getUnadjustedAlignment() const { return UnadjustedAlignment; }
/// getSize - Get the record size in characters.
diff --git a/clang/lib/AST/RecordLayoutBuilder.cpp
b/clang/lib/AST/RecordLayoutBuilder.cpp
index 3e756ab9b9bfe..b49bcd0e3ba42 100644
--- a/clang/lib/AST/RecordLayoutBuilder.cpp
+++ b/clang/lib/AST/RecordLayoutBuilder.cpp
@@ -1302,6 +1302,7 @@ ItaniumRecordLayoutBuilder::LayoutBase(const
BaseSubobjectInfo *Base) {
setSize(std::max(getSize(), Offset + Layout.getSize()));
// Remember max struct/class alignment.
+ UnadjustedAlignment = std::max(UnadjustedAlignment, PreferredBaseAlign);
UpdateAlignment(BaseAlign, UnpackedAlignTo, PreferredBaseAlign);
return Offset;
diff --git a/clang/test/CodeGen/aapcs64-align.cpp
b/clang/test/CodeGen/aapcs64-align.cpp
index e69faf231936c..f9be94b8ec58e 100644
--- a/clang/test/CodeGen/aapcs64-align.cpp
+++ b/clang/test/CodeGen/aapcs64-align.cpp
@@ -67,6 +67,21 @@ void g3() {
// CHECK: declare void @f3(i64 noundef, i128)
// CHECK: declare void @f3m(i64 noundef, i64 noundef, i64 noundef, i64
noundef, i64 noundef, i128)
+// Increased natural alignment through a base class.
+struct SB16 : S16 {};
+
+void f4(long, SB16);
+void f4m(long, long, long, long, long, SB16);
+void g4() {
+ SB16 s = {6, 7};
+ f4(1, s);
+ f4m(1, 2, 3, 4, 5, s);
+}
+// CHECK: define{{.*}} void @g4
+// CHECK: call void @f4(i64 noundef 1, i128 129127208515966861318)
+// CHECK: call void @f4m(i64 noundef 1, i64 noundef 2, i64 noundef 3, i64
noundef 4, i64 noundef 5, i128 129127208515966861318)
+// CHECK: declare void @f4(i64 noundef, i128)
+// CHECK: declare void @f4m(i64 noundef, i64 noundef, i64 noundef, i64
noundef, i64 noundef, i128)
// Packed structure.
struct __attribute__((packed)) P {
@@ -74,18 +89,18 @@ struct __attribute__((packed)) P {
long u;
};
-void f4(int, P);
-void f4m(int, int, int, int, int, P);
-void g4() {
+void f5(int, P);
+void f5m(int, int, int, int, int, P);
+void g5() {
P s = {6, 7};
- f4(1, s);
- f4m(1, 2, 3, 4, 5, s);
+ f5(1, s);
+ f5m(1, 2, 3, 4, 5, s);
}
-// CHECK: define{{.*}} void @g4()
-// CHE
[clang] [ARM, AArch64] Fix passing of structures with aligned base classes (PR #135564)
hvdijk wrote: Not entirely sure who to ask for reviews, adding @rjmccall for the Itanium C++ ABI aspect as it interacts with the AAPCS ABIs, and @efriedma-quic who approved https://reviews.llvm.org/D46013 originally. https://github.com/llvm/llvm-project/pull/135564 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
