-
Notifications
You must be signed in to change notification settings - Fork 14.3k
[Clang] [Sema] Support matrix types in pseudo-destructor expressions #117483
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@llvm/pr-subscribers-clang Author: None (Sirraide) ChangesWe already support vector types, and since matrix element types have to be scalar types, there should be no problem w/ just enabling this. This now also allows matrix types to be stored in STL containers. Full diff: https://github.com/llvm/llvm-project/pull/117483.diff 3 Files Affected:
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 8bd06fadfdc984..ad3c0d3e67f031 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -371,6 +371,9 @@ Non-comprehensive list of changes in this release
- ``__builtin_reduce_and`` function can now be used in constant expressions.
- ``__builtin_reduce_or`` and ``__builtin_reduce_xor`` functions can now be used in constant expressions.
+- Matrix types (a Clang extension) can now be used in pseudo-destructor expressions,
+ which allows them to be stored in STL containers.
+
New Compiler Flags
------------------
diff --git a/clang/lib/Sema/SemaExprCXX.cpp b/clang/lib/Sema/SemaExprCXX.cpp
index d85819b21c8265..d440755ee70665 100644
--- a/clang/lib/Sema/SemaExprCXX.cpp
+++ b/clang/lib/Sema/SemaExprCXX.cpp
@@ -8189,7 +8189,7 @@ ExprResult Sema::BuildPseudoDestructorExpr(Expr *Base,
return ExprError();
if (!ObjectType->isDependentType() && !ObjectType->isScalarType() &&
- !ObjectType->isVectorType()) {
+ !ObjectType->isVectorType() && !ObjectType->isMatrixType()) {
if (getLangOpts().MSVCCompat && ObjectType->isVoidType())
Diag(OpLoc, diag::ext_pseudo_dtor_on_void) << Base->getSourceRange();
else {
diff --git a/clang/test/SemaCXX/matrix-types-pseudo-destructor.cpp b/clang/test/SemaCXX/matrix-types-pseudo-destructor.cpp
new file mode 100644
index 00000000000000..f0ee953ad2557c
--- /dev/null
+++ b/clang/test/SemaCXX/matrix-types-pseudo-destructor.cpp
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 -fsyntax-only -fenable-matrix -std=c++11 -verify %s
+// expected-no-diagnostics
+
+template <typename T>
+void f() {
+ T().~T();
+}
+
+using mat4 = float __attribute__((matrix_type(4, 4)));
+using mat4i = int __attribute__((matrix_type(4, 4)));
+
+template <typename T>
+using mat4_t = T __attribute__((matrix_type(4, 4)));
+
+void g() {
+ f<mat4>();
+ f<mat4i>();
+ f<mat4_t<double>>();
+}
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks reasonable.
Does it make sense to add a sanity test for codegen? I.e. so there is no crashes/assertions and no attempts to generate anything
Probably; good idea |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've got no problem with this, but I definitely agree with a need to test this/validate codegen to make sure the destruciton 'looks' reasonable.
Done. (And while adding the tests, I also discovered an unrelated bug: #118604) |
} | ||
|
||
template <typename T> | ||
void f1(T *f) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we have a constexpr
test to ensure that this noop works fine in a constant expression too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably a good idea
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, it turns out we currently don’t support matrix types in constant expressions, so, er, I’ll open a separate issue about that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We already support vector types, and since matrix element types have to be scalar types, there should be no problem w/ just enabling this.
This now also allows matrix types to be stored in STL containers.