[clang] [WebAssembly] Enable multivalue and reference-types in generic CPU config (PR #80923)

2024-04-29 Thread Heejin Ahn via cfe-commits

https://github.com/aheejin edited 
https://github.com/llvm/llvm-project/pull/80923
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [CodeGen][i386] Move -mregparm storage earlier and fix Runtime calls (PR #89707)

2024-04-29 Thread Eli Friedman via cfe-commits

https://github.com/efriedma-quic approved this pull request.

LGTM

https://github.com/llvm/llvm-project/pull/89707
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang][Sema] Earlier type checking for builtin unary operators (PR #90500)

2024-04-29 Thread Shafik Yaghmour via cfe-commits

https://github.com/shafik commented:

So this seems to apply to member pointer types, pointer types, arrays and 
function types but I don't see coverage for the full set of paths in the tests. 
Can we please add more testing.

Erich also expressed some concern about breaking existing code due to eager 
instantiation. Can we make sure try to cover any change in behavior in the 
tests so reviewers can get a better idea of impact.

https://github.com/llvm/llvm-project/pull/90500
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [OpenMP][TR12] change property of map-type modifier. (PR #90499)

2024-04-29 Thread Alexey Bataev via cfe-commits


@@ -113,7 +114,7 @@ struct SA {
 #pragma omp target map(b[true:true])
 {}
 
-#pragma omp target map(: c,f) // expected-error {{missing map type}}
+#pragma omp target map(: c,f) // lt60-error {{missing map type}}

alexey-bataev wrote:

Hm,, I see in 4.2 Clause Format that it is not allowed

https://github.com/llvm/llvm-project/pull/90499
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang] Address post commit feedbacks in #89906 (PR #90495)

2024-04-29 Thread Adrian Vogelsgesang via cfe-commits


@@ -187,7 +187,7 @@ C++2c implementation status
  
   Trivial infinite loops are not Undefined Behavior
   https://wg21.link/P2809R3;>P2809R3 (DR)
-  Clang 19
+  No

vogelsgesang wrote:

unreleased -> none

https://github.com/llvm/llvm-project/pull/90495
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang] Address post commit feedbacks in #89906 (PR #90495)

2024-04-29 Thread Adrian Vogelsgesang via cfe-commits


@@ -177,7 +177,7 @@ C++2c implementation status
  
   Attributes for Structured Bindings
   https://wg21.link/P0609R3;>P0609R3
-  No
+  Clang 19

vogelsgesang wrote:

none -> unreleased

But maybe just fix this together when landing #90066...

https://github.com/llvm/llvm-project/pull/90495
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] [clang-tidy] Enable plugin tests with LLVM_INSTALL_TOOLCHAIN_ONLY (PR #90370)

2024-04-29 Thread Fangrui Song via cfe-commits

https://github.com/MaskRay approved this pull request.


https://github.com/llvm/llvm-project/pull/90370
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] [clang-tidy] Enable plugin tests with LLVM_INSTALL_TOOLCHAIN_ONLY (PR #90370)

2024-04-29 Thread Fangrui Song via cfe-commits

MaskRay wrote:

This simplification seems desired. https://reviews.llvm.org/D00#3302749 had 
a `LLVM_INSTALL_TOOLCHAIN_ONLY` condition, which seems unneeded.

https://github.com/llvm/llvm-project/pull/90370
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 6f390ea - [Lex] Fix clang -Wparentheses after #89923

2024-04-29 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2024-04-29T13:47:09-07:00
New Revision: 6f390ea60d987f6e1e027d1c72982c2eb7896005

URL: 
https://github.com/llvm/llvm-project/commit/6f390ea60d987f6e1e027d1c72982c2eb7896005
DIFF: 
https://github.com/llvm/llvm-project/commit/6f390ea60d987f6e1e027d1c72982c2eb7896005.diff

LOG: [Lex] Fix clang -Wparentheses after #89923

Added: 


Modified: 
clang/lib/Lex/Pragma.cpp

Removed: 




diff  --git a/clang/lib/Lex/Pragma.cpp b/clang/lib/Lex/Pragma.cpp
index ced407355e0015..10f0ab7180e62d 100644
--- a/clang/lib/Lex/Pragma.cpp
+++ b/clang/lib/Lex/Pragma.cpp
@@ -1444,7 +1444,8 @@ struct PragmaWarningHandler : public PragmaHandler {
  .Case("once", PPCallbacks::PWS_Once)
  .Case("suppress", PPCallbacks::PWS_Suppress)
  .Default(-1);
-  if (SpecifierValid = (SpecifierInt != -1))
+  SpecifierValid = SpecifierInt != -1;
+  if (SpecifierValid)
 Specifier =
 static_cast(SpecifierInt);
 



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 347a02b - [clang][NFC] Repair tests for __builtin_convertvector on big-endian

2024-04-29 Thread Seth Pellegrino via cfe-commits

Author: Seth Pellegrino
Date: 2024-04-29T13:45:00-07:00
New Revision: 347a02b408567ba15fdc68646129c1f5de97ab7e

URL: 
https://github.com/llvm/llvm-project/commit/347a02b408567ba15fdc68646129c1f5de97ab7e
DIFF: 
https://github.com/llvm/llvm-project/commit/347a02b408567ba15fdc68646129c1f5de97ab7e.diff

LOG: [clang][NFC] Repair tests for __builtin_convertvector on big-endian

Previously, the macro expansion to be explicit for the test cases had
unintentionally forced the tests to always run in little-endian mode.

This change restores the tests' endianness switch, and ensures that
the tests always run on both a little- and big-endian platform.

Added: 


Modified: 
clang/test/Sema/constant_builtins_vector.cpp

Removed: 




diff  --git a/clang/test/Sema/constant_builtins_vector.cpp 
b/clang/test/Sema/constant_builtins_vector.cpp
index 68620d436fc43e..ddb78696ce624d 100644
--- a/clang/test/Sema/constant_builtins_vector.cpp
+++ b/clang/test/Sema/constant_builtins_vector.cpp
@@ -1,4 +1,6 @@
 // RUN: %clang_cc1 -verify -std=c++2a -fsyntax-only -Wno-bit-int-extension %s
+// RUN: %clang_cc1 -verify -std=c++2a -fsyntax-only -Wno-bit-int-extension 
-triple ppc64-unknown-linux %s
+// RUN: %clang_cc1 -verify -std=c++2a -fsyntax-only -Wno-bit-int-extension 
-triple ppc64le-unknown-linux %s
 
 #if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
 #define LITTLE_END 1
@@ -102,13 +104,13 @@ static_assert(__builtin_bit_cast(
   
__builtin_shufflevector(from_vector4double_to_vector4char_var,
   
from_vector4double_to_vector4char_var,
   0, 1, 2, 3)) ==
-  (1 ? 0x03020100 : 0x00010203));
+  (LITTLE_END ? 0x03020100 : 0x00010203));
 static_assert(__builtin_bit_cast(unsigned long long,
  __builtin_shufflevector(
  from_vector4double_to_vector4short_var,
  from_vector4double_to_vector4short_var, 0,
  1, 2, 3)) ==
-  (1 ? 0x000300020001 : 0x000100020003));
+  (LITTLE_END ? 0x000300020001 : 0x000100020003));
 constexpr vector4double from_vector4float_to_vector4double_var =
 __builtin_convertvector((vector4float){0, 1, 2, 3}, vector4double);
 constexpr vector4float from_vector4float_to_vector4float_var =
@@ -131,13 +133,13 @@ static_assert(__builtin_bit_cast(unsigned,
  __builtin_shufflevector(
  from_vector4float_to_vector4char_var,
  from_vector4float_to_vector4char_var, 0, 
1,
- 2, 3)) == (1 ? 0x03020100 : 0x00010203));
+ 2, 3)) == (LITTLE_END ? 0x03020100 : 
0x00010203));
 static_assert(__builtin_bit_cast(
   unsigned long long,
   
__builtin_shufflevector(from_vector4float_to_vector4short_var,
   
from_vector4float_to_vector4short_var,
   0, 1, 2, 3)) ==
-  (1 ? 0x000300020001 : 0x000100020003));
+  (LITTLE_END ? 0x000300020001 : 0x000100020003));
 constexpr vector4double from_vector4long_to_vector4double_var =
 __builtin_convertvector((vector4long){0, 1, 2, 3}, vector4double);
 constexpr vector4float from_vector4long_to_vector4float_var =
@@ -160,13 +162,13 @@ static_assert(__builtin_bit_cast(unsigned,
  __builtin_shufflevector(
  from_vector4long_to_vector4char_var,
  from_vector4long_to_vector4char_var, 0, 1,
- 2, 3)) == (1 ? 0x03020100 : 0x00010203));
+ 2, 3)) == (LITTLE_END ? 0x03020100 : 
0x00010203));
 static_assert(__builtin_bit_cast(
   unsigned long long,
   __builtin_shufflevector(from_vector4long_to_vector4short_var,
   from_vector4long_to_vector4short_var,
   0, 1, 2, 3)) ==
-  (1 ? 0x000300020001 : 0x000100020003));
+  (LITTLE_END ? 0x000300020001 : 0x000100020003));
 constexpr vector4double from_vector4int_to_vector4double_var =
 __builtin_convertvector((vector4int){0, 1, 2, 3}, vector4double);
 constexpr vector4float from_vector4int_to_vector4float_var =
@@ -189,13 +191,13 @@ static_assert(__builtin_bit_cast(unsigned,
  __builtin_shufflevector(
  from_vector4int_to_vector4char_var,
  from_vector4int_to_vector4char_var, 0, 1,
- 2, 3)) == (1 

[clang] [Clang][Parse] Delay parsing of noexcept-specifiers in friend function declarations (PR #90517)

2024-04-29 Thread Erich Keane via cfe-commits

https://github.com/erichkeane commented:

Missing test + release note.

In the future, please use 'draft pull request' when your patch is not ready for 
review/to be committed.

https://github.com/llvm/llvm-project/pull/90517
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [OpenCL] Put constant initializer globals into constant addrspace (PR #90048)

2024-04-29 Thread Eli Friedman via cfe-commits


@@ -535,20 +535,24 @@ void AggExprEmitter::EmitArrayInit(Address DestPtr, 
llvm::ArrayType *AType,
   elementType.isTriviallyCopyableType(CGF.getContext())) {
 CodeGen::CodeGenModule  = CGF.CGM;
 ConstantEmitter Emitter(CGF);
-LangAS AS = ArrayQTy.getAddressSpace();
+QualType GVArrayQTy = ArrayQTy;
+if (!GVArrayQTy.hasAddressSpace())
+  GVArrayQTy = CGM.getContext().getAddrSpaceQualType(

efriedma-quic wrote:

I think you just just want `GVArrayQTy = 
CGM.getContext().getAddrSpaceQualType(CGM.getContext().removeAddrSpaceQualType(GVArrayQTy),
 CGM.GetGlobalConstantAddressSpace());`, without the "if": you want to change 
the address-space even if the address-space of the destination is explicitly 
specified.

https://github.com/llvm/llvm-project/pull/90048
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [coro] Lower `llvm.coro.await.suspend.handle` to resume with tail call (PR #89751)

2024-04-29 Thread Mircea Trofin via cfe-commits


@@ -1056,6 +1083,25 @@ void CoroCloner::create() {
   // Set up the new entry block.
   replaceEntryBlock();
 
+  // Turn symmetric transfers into musttail calls.
+  for (CallInst *ResumeCall : Shape.SymmetricTransfers) {
+ResumeCall = cast(VMap[ResumeCall]);
+ResumeCall->setCallingConv(NewF->getCallingConv());
+if (TTI.supportsTailCallFor(ResumeCall)) {
+  // FIXME: Could we support symmetric transfer effectively without
+  // musttail?
+  ResumeCall->setTailCallKind(CallInst::TCK_MustTail);
+}
+
+// Put a 'ret void' after the call, and split any remaining instructions to

mtrofin wrote:

Sorry for insisting on this, it's maybe because I got "bitten" before (with the 
suspend), but what other examples do we have where, silently, instructions 
don't get executed after a call?

Also, maybe this would become moot if we address 
https://discourse.llvm.org/t/coro-pre-split-handling-of-the-suspend-edge/75043 
like @jyknight suggested (i.e. not even have the misleading edge)?

https://github.com/llvm/llvm-project/pull/89751
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [OpenACC] Private Clause on Compute Constructs (PR #90521)

2024-04-29 Thread via cfe-commits

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Erich Keane (erichkeane)


Changes

The private clause is the first that takes a 'var-list', thus this has a lot of 
additional work to enable the var-list type.  A 'var' is a traditional variable 
reference, subscript, member-expression, or array-section, so checking of these 
is pretty minor.

Note: This ran into some issues with array-sections (aka sub-arrays) that will 
be fixed in a follow-up patch.

---

Patch is 73.67 KiB, truncated to 20.00 KiB below, full version: 
https://github.com/llvm/llvm-project/pull/90521.diff


21 Files Affected:

- (modified) clang/include/clang/AST/OpenACCClause.h (+59-26) 
- (modified) clang/include/clang/Basic/DiagnosticSemaKinds.td (+3) 
- (modified) clang/include/clang/Basic/OpenACCClauses.def (+1) 
- (modified) clang/include/clang/Parse/Parser.h (+5-4) 
- (modified) clang/include/clang/Sema/SemaOpenACC.h (+34-2) 
- (modified) clang/include/clang/Serialization/ASTRecordReader.h (+3) 
- (modified) clang/include/clang/Serialization/ASTRecordWriter.h (+3) 
- (modified) clang/lib/AST/OpenACCClause.cpp (+24) 
- (modified) clang/lib/AST/StmtProfile.cpp (+6) 
- (modified) clang/lib/AST/TextNodeDumper.cpp (+1) 
- (modified) clang/lib/Parse/ParseOpenACC.cpp (+56-62) 
- (modified) clang/lib/Sema/SemaOpenACC.cpp (+73) 
- (modified) clang/lib/Sema/TreeTransform.h (+30-2) 
- (modified) clang/lib/Serialization/ASTReader.cpp (+14-1) 
- (modified) clang/lib/Serialization/ASTWriter.cpp (+12-1) 
- (modified) clang/test/ParserOpenACC/parse-cache-construct.c (+2) 
- (modified) clang/test/ParserOpenACC/parse-clauses.c (+40-20) 
- (added) clang/test/SemaOpenACC/compute-construct-private-clause.c (+138) 
- (added) clang/test/SemaOpenACC/compute-construct-private-clause.cpp (+161) 
- (added) clang/test/SemaOpenACC/compute-construct-varlist-ast.cpp (+552) 
- (modified) clang/tools/libclang/CIndex.cpp (+9) 


``diff
diff --git a/clang/include/clang/AST/OpenACCClause.h 
b/clang/include/clang/AST/OpenACCClause.h
index 277a351c49fcb8..dafcad4179a37e 100644
--- a/clang/include/clang/AST/OpenACCClause.h
+++ b/clang/include/clang/AST/OpenACCClause.h
@@ -156,51 +156,50 @@ class OpenACCSelfClause : public 
OpenACCClauseWithCondition {
Expr *ConditionExpr, SourceLocation EndLoc);
 };
 
-/// Represents a clause that has one or more IntExprs.  It does not own the
-/// IntExprs, but provides 'children' and other accessors.
-class OpenACCClauseWithIntExprs : public OpenACCClauseWithParams {
-  MutableArrayRef IntExprs;
+/// Represents a clause that has one or more expressions associated with it.
+class OpenACCClauseWithExprs : public OpenACCClauseWithParams {
+  MutableArrayRef Exprs;
 
 protected:
-  OpenACCClauseWithIntExprs(OpenACCClauseKind K, SourceLocation BeginLoc,
-SourceLocation LParenLoc, SourceLocation EndLoc)
+  OpenACCClauseWithExprs(OpenACCClauseKind K, SourceLocation BeginLoc,
+ SourceLocation LParenLoc, SourceLocation EndLoc)
   : OpenACCClauseWithParams(K, BeginLoc, LParenLoc, EndLoc) {}
 
   /// Used only for initialization, the leaf class can initialize this to
   /// trailing storage.
-  void setIntExprs(MutableArrayRef NewIntExprs) {
-assert(IntExprs.empty() && "Cannot change IntExprs list");
-IntExprs = NewIntExprs;
+  void setExprs(MutableArrayRef NewExprs) {
+assert(Exprs.empty() && "Cannot change Exprs list");
+Exprs = NewExprs;
   }
 
-  /// Gets the entire list of integer expressions, but leave it to the
+  /// Gets the entire list of expressions, but leave it to the
   /// individual clauses to expose this how they'd like.
-  llvm::ArrayRef getIntExprs() const { return IntExprs; }
+  llvm::ArrayRef getExprs() const { return Exprs; }
 
 public:
   child_range children() {
-return child_range(reinterpret_cast(IntExprs.begin()),
-   reinterpret_cast(IntExprs.end()));
+return child_range(reinterpret_cast(Exprs.begin()),
+   reinterpret_cast(Exprs.end()));
   }
 
   const_child_range children() const {
 child_range Children =
-const_cast(this)->children();
+const_cast(this)->children();
 return const_child_range(Children.begin(), Children.end());
   }
 };
 
 class OpenACCNumGangsClause final
-: public OpenACCClauseWithIntExprs,
+: public OpenACCClauseWithExprs,
   public llvm::TrailingObjects {
 
   OpenACCNumGangsClause(SourceLocation BeginLoc, SourceLocation LParenLoc,
 ArrayRef IntExprs, SourceLocation EndLoc)
-  : OpenACCClauseWithIntExprs(OpenACCClauseKind::NumGangs, BeginLoc,
-  LParenLoc, EndLoc) {
+  : OpenACCClauseWithExprs(OpenACCClauseKind::NumGangs, BeginLoc, 
LParenLoc,
+   EndLoc) {
 std::uninitialized_copy(IntExprs.begin(), IntExprs.end(),
 getTrailingObjects());
-

[clang] [OpenACC] Private Clause on Compute Constructs (PR #90521)

2024-04-29 Thread Erich Keane via cfe-commits

https://github.com/erichkeane created 
https://github.com/llvm/llvm-project/pull/90521

The private clause is the first that takes a 'var-list', thus this has a lot of 
additional work to enable the var-list type.  A 'var' is a traditional variable 
reference, subscript, member-expression, or array-section, so checking of these 
is pretty minor.

Note: This ran into some issues with array-sections (aka sub-arrays) that will 
be fixed in a follow-up patch.

>From 54ba7d0b7d71d751cf268c3bdfb89bc5ca628a6b Mon Sep 17 00:00:00 2001
From: erichkeane 
Date: Mon, 22 Apr 2024 13:31:52 -0700
Subject: [PATCH] [OpenACC] Private Clause on Compute Constructs

The private clause is the first that takes a 'var-list', thus this has a
lot of additional work to enable the var-list type.  A 'var' is a
traditional variable reference, subscript, member-expression, or array-section,
so checking of these is pretty minor.

Note: This ran into some issues with array-sections (aka sub-arrays)
that will be fixed in a follow-up patch.
---
 clang/include/clang/AST/OpenACCClause.h   |  85 ++-
 .../clang/Basic/DiagnosticSemaKinds.td|   3 +
 clang/include/clang/Basic/OpenACCClauses.def  |   1 +
 clang/include/clang/Parse/Parser.h|   9 +-
 clang/include/clang/Sema/SemaOpenACC.h|  36 +-
 .../clang/Serialization/ASTRecordReader.h |   3 +
 .../clang/Serialization/ASTRecordWriter.h |   3 +
 clang/lib/AST/OpenACCClause.cpp   |  24 +
 clang/lib/AST/StmtProfile.cpp |   6 +
 clang/lib/AST/TextNodeDumper.cpp  |   1 +
 clang/lib/Parse/ParseOpenACC.cpp  | 118 ++--
 clang/lib/Sema/SemaOpenACC.cpp|  73 +++
 clang/lib/Sema/TreeTransform.h|  32 +-
 clang/lib/Serialization/ASTReader.cpp |  15 +-
 clang/lib/Serialization/ASTWriter.cpp |  13 +-
 .../ParserOpenACC/parse-cache-construct.c |   2 +
 clang/test/ParserOpenACC/parse-clauses.c  |  60 +-
 .../compute-construct-private-clause.c| 138 +
 .../compute-construct-private-clause.cpp  | 161 +
 .../compute-construct-varlist-ast.cpp | 552 ++
 clang/tools/libclang/CIndex.cpp   |   9 +
 21 files changed, 1226 insertions(+), 118 deletions(-)
 create mode 100644 clang/test/SemaOpenACC/compute-construct-private-clause.c
 create mode 100644 clang/test/SemaOpenACC/compute-construct-private-clause.cpp
 create mode 100644 clang/test/SemaOpenACC/compute-construct-varlist-ast.cpp

diff --git a/clang/include/clang/AST/OpenACCClause.h 
b/clang/include/clang/AST/OpenACCClause.h
index 277a351c49fcb8..dafcad4179a37e 100644
--- a/clang/include/clang/AST/OpenACCClause.h
+++ b/clang/include/clang/AST/OpenACCClause.h
@@ -156,51 +156,50 @@ class OpenACCSelfClause : public 
OpenACCClauseWithCondition {
Expr *ConditionExpr, SourceLocation EndLoc);
 };
 
-/// Represents a clause that has one or more IntExprs.  It does not own the
-/// IntExprs, but provides 'children' and other accessors.
-class OpenACCClauseWithIntExprs : public OpenACCClauseWithParams {
-  MutableArrayRef IntExprs;
+/// Represents a clause that has one or more expressions associated with it.
+class OpenACCClauseWithExprs : public OpenACCClauseWithParams {
+  MutableArrayRef Exprs;
 
 protected:
-  OpenACCClauseWithIntExprs(OpenACCClauseKind K, SourceLocation BeginLoc,
-SourceLocation LParenLoc, SourceLocation EndLoc)
+  OpenACCClauseWithExprs(OpenACCClauseKind K, SourceLocation BeginLoc,
+ SourceLocation LParenLoc, SourceLocation EndLoc)
   : OpenACCClauseWithParams(K, BeginLoc, LParenLoc, EndLoc) {}
 
   /// Used only for initialization, the leaf class can initialize this to
   /// trailing storage.
-  void setIntExprs(MutableArrayRef NewIntExprs) {
-assert(IntExprs.empty() && "Cannot change IntExprs list");
-IntExprs = NewIntExprs;
+  void setExprs(MutableArrayRef NewExprs) {
+assert(Exprs.empty() && "Cannot change Exprs list");
+Exprs = NewExprs;
   }
 
-  /// Gets the entire list of integer expressions, but leave it to the
+  /// Gets the entire list of expressions, but leave it to the
   /// individual clauses to expose this how they'd like.
-  llvm::ArrayRef getIntExprs() const { return IntExprs; }
+  llvm::ArrayRef getExprs() const { return Exprs; }
 
 public:
   child_range children() {
-return child_range(reinterpret_cast(IntExprs.begin()),
-   reinterpret_cast(IntExprs.end()));
+return child_range(reinterpret_cast(Exprs.begin()),
+   reinterpret_cast(Exprs.end()));
   }
 
   const_child_range children() const {
 child_range Children =
-const_cast(this)->children();
+const_cast(this)->children();
 return const_child_range(Children.begin(), Children.end());
   }
 };
 
 class OpenACCNumGangsClause final
-: public OpenACCClauseWithIntExprs,
+: public 

[clang] [Clang][HLSL] Add environment parameter to availability attribute (PR #89809)

2024-04-29 Thread Helena Kotas via cfe-commits

https://github.com/hekota updated 
https://github.com/llvm/llvm-project/pull/89809

>From 22b67d30ca087d6a912183039c87fd1790eedfe4 Mon Sep 17 00:00:00 2001
From: Helena Kotas 
Date: Tue, 23 Apr 2024 00:49:28 -0700
Subject: [PATCH 1/3] Add environment parameter to clang availability attribute

---
 clang/include/clang/Basic/Attr.td |  33 +-
 clang/include/clang/Basic/AttrDocs.td |   2 +
 .../clang/Basic/DiagnosticParseKinds.td   |   2 +
 .../clang/Basic/DiagnosticSemaKinds.td|   5 +-
 clang/include/clang/Parse/Parser.h|   3 +
 clang/include/clang/Sema/ParsedAttr.h |  40 ---
 clang/include/clang/Sema/Sema.h   |   5 +-
 clang/lib/AST/DeclBase.cpp|  27 -
 clang/lib/Headers/hlsl/hlsl_intrinsics.h  |  13 ++-
 clang/lib/Index/CommentToXML.cpp  |   3 +
 clang/lib/Parse/ParseDecl.cpp |  20 +++-
 clang/lib/Sema/SemaAPINotes.cpp   |   3 +-
 clang/lib/Sema/SemaAvailability.cpp   | 109 +-
 clang/lib/Sema/SemaDecl.cpp   |   2 +-
 clang/lib/Sema/SemaDeclAttr.cpp   |  34 --
 15 files changed, 232 insertions(+), 69 deletions(-)

diff --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index dc87a8c6f022dc..1b07f4eb408093 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -956,7 +956,7 @@ def Availability : InheritableAttr {
   VersionArgument<"deprecated">, VersionArgument<"obsoleted">,
   BoolArgument<"unavailable">, StringArgument<"message">,
   BoolArgument<"strict">, StringArgument<"replacement">,
-  IntArgument<"priority">];
+  IntArgument<"priority">, IdentifierArgument<"environment">];
   let AdditionalMembers =
 [{static llvm::StringRef getPrettyPlatformName(llvm::StringRef Platform) {
 return llvm::StringSwitch(Platform)
@@ -976,7 +976,7 @@ def Availability : InheritableAttr {
  .Case("xros", "visionOS")
  .Case("xros_app_extension", "visionOS (App Extension)")
  .Case("swift", "Swift")
- .Case("shadermodel", "HLSL ShaderModel")
+ .Case("shadermodel", "HLSL Shader Model")
  .Case("ohos", "OpenHarmony OS")
  .Default(llvm::StringRef());
 }
@@ -1016,7 +1016,34 @@ static llvm::StringRef 
canonicalizePlatformName(llvm::StringRef Platform) {
  .Case("visionos_app_extension", "xros_app_extension")
  .Case("ShaderModel", "shadermodel")
  .Default(Platform);
-} }];
+}
+static llvm::StringRef getPrettyEnviromentName(llvm::StringRef Environment) {
+return llvm::StringSwitch(Environment)
+ .Case("pixel", "pixel shader")
+ .Case("vertex", "vertex shader")
+ .Case("geometry", "geometry shader")
+ .Case("hull", "hull shader")
+ .Case("domain", "domain shader")
+ .Case("compute", "compute shader")
+ .Case("mesh", "mesh shader")
+ .Case("amplification", "amplification shader")
+ .Case("library", "shader library")
+ .Default(Environment);
+}
+static llvm::Triple::EnvironmentType getEnvironmentType(llvm::StringRef 
Environment) {
+return llvm::StringSwitch(Environment)
+ .Case("pixel", llvm::Triple::Pixel)
+ .Case("vertex", llvm::Triple::Vertex)
+ .Case("geometry", llvm::Triple::Geometry)
+ .Case("hull", llvm::Triple::Hull)
+ .Case("domain", llvm::Triple::Domain)
+ .Case("compute", llvm::Triple::Compute)
+ .Case("mesh", llvm::Triple::Mesh)
+ .Case("amplification", llvm::Triple::Amplification)
+ .Case("library", llvm::Triple::Library)
+ .Default(llvm::Triple::UnknownEnvironment);
+}
+}];
   let HasCustomParsing = 1;
   let InheritEvenIfAlreadyPresent = 1;
   let Subjects = SubjectList<[Named]>;
diff --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index a0bbe5861c5722..a81163df35ca8b 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -1593,6 +1593,8 @@ replacement=\ *string-literal*
   a warning about use of a deprecated declaration. The Fix-It will replace
   the deprecated declaration with the new declaration specified.
 
+// HEKOTA TODO add docs here
+
 Multiple availability attributes can be placed on a declaration, which may
 correspond to different platforms. For most platforms, the availability
 attribute with the platform corresponding to the target platform will be used;
diff --git a/clang/include/clang/Basic/DiagnosticParseKinds.td 
b/clang/include/clang/Basic/DiagnosticParseKinds.td
index 66405095d51de8..631dc8880fcfc8 100644
--- a/clang/include/clang/Basic/DiagnosticParseKinds.td
+++ b/clang/include/clang/Basic/DiagnosticParseKinds.td
@@ -1103,6 +1103,8 

[clang] [X86_64] Fix empty field error in vaarg of C++. (PR #90389)

2024-04-29 Thread Eli Friedman via cfe-commits


@@ -3123,8 +3123,22 @@ Address X86_64ABIInfo::EmitVAArg(CodeGenFunction , 
Address VAListAddr,
 
 RegAddr = Tmp.withElementType(LTy);
   } else if (neededInt) {
-RegAddr = Address(CGF.Builder.CreateGEP(CGF.Int8Ty, RegSaveArea, 
gp_offset),
-  LTy, CharUnits::fromQuantity(8));
+if (AI.isDirect() && AI.getDirectOffset() == 8) {
+  Address Tmp = CGF.CreateMemTemp(Ty);
+  llvm::StructType *ST = cast(LTy);
+  Tmp = Tmp.withElementType(ST);
+  llvm::Type *TyHi = ST->getElementType(1);

efriedma-quic wrote:

The computation of TyHi is wrong.  Use `AI.getCoerceToType()`.  (Try something 
like `typedef struct { struct Z {} z[8]; float x, y; } X;`.)

Can we unify this code with the "Copy into a temporary if the type is more 
aligned" code below, so we only call CreateMemTemp() once?

Can we reuse this code for the neededSSE == 1 case?

https://github.com/llvm/llvm-project/pull/90389
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Driver] Clean up denormal handling with fast-math-related options (PR #89477)

2024-04-29 Thread Andy Kaylor via cfe-commits

https://github.com/andykaylor closed 
https://github.com/llvm/llvm-project/pull/89477
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 8ba880b - [Driver] Clean up denormal handling with fast-math-related options (#89477)

2024-04-29 Thread via cfe-commits

Author: Andy Kaylor
Date: 2024-04-29T13:22:08-07:00
New Revision: 8ba880b587074ad6c8624ed45ea2b289f653667f

URL: 
https://github.com/llvm/llvm-project/commit/8ba880b587074ad6c8624ed45ea2b289f653667f
DIFF: 
https://github.com/llvm/llvm-project/commit/8ba880b587074ad6c8624ed45ea2b289f653667f.diff

LOG: [Driver] Clean up denormal handling with fast-math-related options (#89477)

This change cleans up the clang driver handling of umbrella options like
-ffast-math, -funsafe-math-optimizations, and -ffp-model, and aligns the
behavior of -ffp-model=fast with -ffast-math with regard to the linking
of crtfastmath.o.

We agreed in a previous review that the fast-math options should not
attempt to change the -fdenormal-fp-math option, which is inherently
target-specific.

The clang user's manual claims that -ffp-model=fast "behaves identically
to specifying both -ffast-math and -ffp-contract=fast." Since
-ffast-math causes crtfastmath.o to be linked if it is available, that should
also happen with -ffp-model=fast.

I am going to be proposing further changes to -ffp-model=fast,
decoupling it from -ffast-math and introducing a new
-ffp-model=aggressive that matches the current behavior, but I wanted
to solidfy the current behavior before I do that.

Added: 


Modified: 
clang/docs/UsersManual.rst
clang/lib/Driver/ToolChain.cpp
clang/lib/Driver/ToolChains/Clang.cpp
clang/test/Driver/fp-model.c
clang/test/Driver/linux-ld.c
clang/test/Driver/solaris-ld.c

Removed: 




diff  --git a/clang/docs/UsersManual.rst b/clang/docs/UsersManual.rst
index a7fc7ec87a161f..6ba0a531fedf9b 100644
--- a/clang/docs/UsersManual.rst
+++ b/clang/docs/UsersManual.rst
@@ -1452,8 +1452,6 @@ floating point semantic models: precise (the default), 
strict, and fast.
   "fenv_access", "off", "on", "off"
   "rounding_mode", "tonearest", "dynamic", "tonearest"
   "contract", "on", "off", "fast"
-  "denormal_fp_math", "IEEE", "IEEE", "IEEE"
-  "denormal_fp32_math", "IEEE","IEEE", "IEEE"
   "support_math_errno", "on", "on", "off"
   "no_honor_nans", "off", "off", "on"
   "no_honor_infinities", "off", "off", "on"
@@ -1462,6 +1460,14 @@ floating point semantic models: precise (the default), 
strict, and fast.
   "allow_approximate_fns", "off", "off", "on"
   "allow_reassociation", "off", "off", "on"
 
+The ``-ffp-model`` option does not modify the ``fdenormal-fp-math``
+setting, but it does have an impact on whether ``crtfastmath.o`` is
+linked. Because linking ``crtfastmath.o`` has a global effect on the
+program, and because the global denormal handling can be changed in
+other ways, the state of ``fdenormal-fp-math`` handling cannot
+be assumed in any function based on fp-model. See :ref:`crtfastmath.o`
+for more details.
+
 .. option:: -ffast-math
 
Enable fast-math mode.  This option lets the
@@ -1537,7 +1543,6 @@ floating point semantic models: precise (the default), 
strict, and fast.
Also, this option resets following options to their target-dependent 
defaults.
 
* ``-f[no-]math-errno``
-   * ``-fdenormal-fp-math=``
 
There is ambiguity about how ``-ffp-contract``, ``-ffast-math``,
and ``-fno-fast-math`` behave when combined. To keep the value of
@@ -1560,8 +1565,7 @@ floating point semantic models: precise (the default), 
strict, and fast.
  ``-ffp-contract`` setting is determined by the default value of
  ``-ffp-contract``.
 
-   Note: ``-fno-fast-math`` implies ``-fdenormal-fp-math=ieee``.
-   ``-fno-fast-math`` causes ``crtfastmath.o`` to not be linked with code
+   Note: ``-fno-fast-math`` causes ``crtfastmath.o`` to not be linked with code
unless ``-mdaz-ftz`` is present.
 
 .. option:: -fdenormal-fp-math=
@@ -1694,7 +1698,6 @@ floating point semantic models: precise (the default), 
strict, and fast.
* ``-fsigned-zeros``
* ``-ftrapping-math``
* ``-ffp-contract=on``
-   * ``-fdenormal-fp-math=ieee``
 
There is ambiguity about how ``-ffp-contract``,
``-funsafe-math-optimizations``, and ``-fno-unsafe-math-optimizations``

diff  --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index 341d6202a9ca3c..0e86bc07e0ea2c 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -1316,14 +1316,19 @@ bool ToolChain::isFastMathRuntimeAvailable(const 
ArgList ,
   // (to keep the linker options consistent with gcc and clang itself).
   if (Default && !isOptimizationLevelFast(Args)) {
 // Check if -ffast-math or -funsafe-math.
-Arg *A =
-  Args.getLastArg(options::OPT_ffast_math, options::OPT_fno_fast_math,
-  options::OPT_funsafe_math_optimizations,
-  options::OPT_fno_unsafe_math_optimizations);
+Arg *A = Args.getLastArg(
+options::OPT_ffast_math, options::OPT_fno_fast_math,
+options::OPT_funsafe_math_optimizations,
+options::OPT_fno_unsafe_math_optimizations, 

[clang] [Clang] Implement P2809: Trivial infinite loops are not Undefined Behavior (PR #90066)

2024-04-29 Thread via cfe-commits


@@ -908,6 +908,74 @@ void CodeGenFunction::EmitIfStmt(const IfStmt ) {
 incrementProfileCounter();
 }
 
+bool CodeGenFunction::checkIfLoopMustProgress(const Expr 
*ControllingExpression,
+  bool IsTrivialCXXLoop) {
+  if (CGM.getCodeGenOpts().getFiniteLoops() ==
+  CodeGenOptions::FiniteLoopsKind::Always)
+return true;
+  if (CGM.getCodeGenOpts().getFiniteLoops() ==
+  CodeGenOptions::FiniteLoopsKind::Never)
+return false;
+
+  // Now apply rules for plain C (see  6.8.5.6 in C11).
+  // Loops with constant conditions do not have to make progress in any C
+  // version.
+  // As an extension, we consisider loops whose constant expression
+  // can be constant-folded.
+  Expr::EvalResult Result;
+  bool CondIsConstInt =
+  !ControllingExpression ||
+  (ControllingExpression->EvaluateAsInt(Result, getContext()) &&
+   Result.Val.isInt());
+
+  bool CondIsTrue = CondIsConstInt &&
+(!ControllingExpression || Result.Val.getInt().getBoolValue());
+
+  if (getLangOpts().C99 && CondIsConstInt)
+return false;
+
+  // Loops with non-constant conditions must make progress in C11 and later.
+  if (getLangOpts().C11)
+return true;
+
+  // [C++26][intro.progress] (DR)
+  // The implementation may assume that any thread will eventually do one of 
the
+  // following:
+  // [...]
+  // - continue execution of a trivial infinite loop ([stmt.iter.general]).
+  if (getLangOpts().CPlusPlus11) {
+if (IsTrivialCXXLoop && CondIsTrue) {
+  CurFn->removeFnAttr(llvm::Attribute::MustProgress);
+  return false;
+}
+return true;
+  }
+
+  return false;
+}
+
+// [C++26][stmt.iter.general] (DR)
+// A trivially empty iteration statement is an iteration statement matching one
+// of the following forms:
+//  - while ( expression ) ;
+//  - while ( expression ) { }
+//  - do ; while ( expression ) ;
+//  - do { } while ( expression ) ;
+//  - for ( init-statement expression(opt); ) ;
+//  - for ( init-statement expression(opt); ) { }
+template  static bool hasEmptyLoopBody(const LoopStmt ) {
+  if constexpr (std::is_same_v) {
+if (S.getInc())
+  return false;
+  }
+  const Stmt *Body = S.getBody();
+  if (!Body || isa(Body))
+return true;
+  if (const CompoundStmt *Compound = dyn_cast(Body))

cor3ntin wrote:

I added some tests (and test for false conditions, which are not trivial in c++)

https://github.com/llvm/llvm-project/pull/90066
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [clang][hlsl] Add tan intrinsic part 1 (PR #90276)

2024-04-29 Thread Farzon Lotfi via cfe-commits

farzonl wrote:

> Are you intentionally skipping implementing changes to __builtin_tan()?

Yes but, maybe my reasoning isn't good enough to exclude. Let me know. I didn't 
add it for two reasons.

First sine and cosine define builtins like so:
```
def SinF16F128 : Builtin, F16F128MathTemplate {
  let Spellings = ["__builtin_sin"];
  let Attributes = [FunctionWithBuiltinPrefix, NoThrow,
ConstIgnoringErrnoAndExceptions];
  let Prototype = "T(T)";

  def CosF16F128 : Builtin, F16F128MathTemplate {
let Spellings = ["__builtin_cos"];
let Attributes = [FunctionWithBuiltinPrefix, NoThrow, 
ConstIgnoringErrnoAndExceptions];
let Prototype = "T(T)";
  }
```
There is no equivalent in `clang/include/clang/Basic/Builtins.td` for Tan 
however tan builins are already defined in 
`/tools/clang/include/clang/Basic/Builtins.inc` Like So:

```
BUILTIN(__builtin_tanf, "ff", "Fne")
LIBBUILTIN(tanf, "ff", "fne", MATH_H, ALL_LANGUAGES)
BUILTIN(__builtin_tan, "dd", "Fne")
LIBBUILTIN(tan, "dd", "fne", MATH_H, ALL_LANGUAGES)
BUILTIN(__builtin_tanl, "LdLd", "Fne")
LIBBUILTIN(tanl, "LdLd", "fne", MATH_H, ALL_LANGUAGES)
BUILTIN(__builtin_tanf128, "LLdLLd", "Fne")
BUILTIN(__builtin_tanhf, "ff", "Fne")
LIBBUILTIN(tanhf, "ff", "fne", MATH_H, ALL_LANGUAGES)
BUILTIN(__builtin_tanh, "dd", "Fne")
LIBBUILTIN(tanh, "dd", "fne", MATH_H, ALL_LANGUAGES)
BUILTIN(__builtin_tanhl, "LdLd", "Fne")
LIBBUILTIN(tanhl, "LdLd", "fne", MATH_H, ALL_LANGUAGES)
BUILTIN(__builtin_tanhf128, "LLdLLd", "Fne")
LIBBUILTIN(__tanpif, "ff", "fne", MATH_H, ALL_LANGUAGES)
LIBBUILTIN(__tanpi, "dd", "fne", MATH_H, ALL_LANGUAGES)
```
Adding the builtin didn't seem right as it would conflict.

Since they already exist maybe I can just use them?  That leads me to reason 2.

Reason 2 to exclude for now the scalar cos\sin calls all have constrained fp  
usages as part of code gen in `clang/lib/CodeGen/CGBuiltin.cpp`. This would 
increase the testing burden for this change. getting a 
`experimental_constrained_tan` working seems to be  beyond the scope of what I 
wanted to accomplish with this pr.

examples:
```cpp
  case Builtin::BI__builtin_cos:
  case Builtin::BI__builtin_cosf:
  case Builtin::BI__builtin_cosf16:
  case Builtin::BI__builtin_cosl:
  case Builtin::BI__builtin_cosf128:
return RValue::get(emitUnaryMaybeConstrainedFPBuiltin(*this, E,
 Intrinsic::cos,
 Intrinsic::experimental_constrained_cos));
  
  case Builtin::BI__builtin_sin:
  case Builtin::BI__builtin_sinf:
  case Builtin::BI__builtin_sinf16:
  case Builtin::BI__builtin_sinl:
  case Builtin::BI__builtin_sinf128:
return RValue::get(emitUnaryMaybeConstrainedFPBuiltin(*this, E,
 Intrinsic::sin,
 Intrinsic::experimental_constrained_sin));

```

https://github.com/llvm/llvm-project/pull/90276
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [flang] [Flang] RFC: Add support for -w option (PR #90420)

2024-04-29 Thread Peter Klausler via cfe-commits

klausler wrote:

See https://github.com/llvm/llvm-project/pull/90518, which I think would 
greatly ease implementation of `-w`.

https://github.com/llvm/llvm-project/pull/90420
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [OpenMP][TR12] change property of map-type modifier. (PR #90499)

2024-04-29 Thread via cfe-commits


@@ -113,7 +114,7 @@ struct SA {
 #pragma omp target map(b[true:true])
 {}
 
-#pragma omp target map(: c,f) // expected-error {{missing map type}}
+#pragma omp target map(: c,f) // lt60-error {{missing map type}}

jyu2-git wrote:

Yes.


https://github.com/llvm/llvm-project/pull/90499
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [OpenMP][TR12] change property of map-type modifier. (PR #90499)

2024-04-29 Thread via cfe-commits

https://github.com/jyu2-git updated 
https://github.com/llvm/llvm-project/pull/90499

>From 20904df466de953880ca6af4afd72d7dfae33224 Mon Sep 17 00:00:00 2001
From: Jennifer Yu 
Date: Mon, 29 Apr 2024 10:01:12 -0700
Subject: [PATCH 1/2] [OpenMP][TR12] change proerty of map-type modifer.

map-type change to "default" instead "ultimate" from [OpenMP5.2]

The change is allowed map-type to be placed any locations within map
modifiers, besides the last location in the modifiers-list, also
map-type can be omitted afterward.
---
 .../clang/Basic/DiagnosticParseKinds.td   |   3 +
 clang/lib/Parse/ParseOpenMP.cpp   |  35 +-
 clang/test/OpenMP/target_ast_print.cpp|  58 ++
 clang/test/OpenMP/target_map_messages.cpp | 105 ++
 4 files changed, 153 insertions(+), 48 deletions(-)

diff --git a/clang/include/clang/Basic/DiagnosticParseKinds.td 
b/clang/include/clang/Basic/DiagnosticParseKinds.td
index fdffb35ea0d955..c3b50d59da6e36 100644
--- a/clang/include/clang/Basic/DiagnosticParseKinds.td
+++ b/clang/include/clang/Basic/DiagnosticParseKinds.td
@@ -1438,6 +1438,9 @@ def err_omp_decl_in_declare_simd_variant : Error<
 def err_omp_sink_and_source_iteration_not_allowd: Error<" '%0 
%select{sink:|source:}1' must be with '%select{omp_cur_iteration - 
1|omp_cur_iteration}1'">;
 def err_omp_unknown_map_type : Error<
   "incorrect map type, expected one of 'to', 'from', 'tofrom', 'alloc', 
'release', or 'delete'">;
+def err_omp_more_one_map_type : Error<"map type is already specified">;
+def note_previous_map_type_specified_here
+: Note<"map type '%0' is previous specified here">;
 def err_omp_unknown_map_type_modifier : Error<
   "incorrect map type modifier, expected one of: 'always', 'close', 'mapper'"
   "%select{|, 'present'|, 'present', 'iterator'}0%select{|, 'ompx_hold'}1">;
diff --git a/clang/lib/Parse/ParseOpenMP.cpp b/clang/lib/Parse/ParseOpenMP.cpp
index 480201bc06f613..ad1cda161eaf06 100644
--- a/clang/lib/Parse/ParseOpenMP.cpp
+++ b/clang/lib/Parse/ParseOpenMP.cpp
@@ -4228,13 +4228,19 @@ bool 
Parser::parseMapperModifier(SemaOpenMP::OpenMPVarListDataTy ) {
   return T.consumeClose();
 }
 
+static OpenMPMapClauseKind isMapType(Parser );
+
 /// Parse map-type-modifiers in map clause.
 /// map([ [map-type-modifier[,] [map-type-modifier[,] ...] map-type : ] list)
 /// where, map-type-modifier ::= always | close | mapper(mapper-identifier) |
 /// present
 bool Parser::parseMapTypeModifiers(SemaOpenMP::OpenMPVarListDataTy ) {
+  bool HasMapType = false;
+  SourceLocation PreMapLoc = Tok.getLocation();
+  StringRef PreMapName = "";
   while (getCurToken().isNot(tok::colon)) {
 OpenMPMapModifierKind TypeModifier = isMapModifier(*this);
+OpenMPMapClauseKind MapKind = isMapType(*this);
 if (TypeModifier == OMPC_MAP_MODIFIER_always ||
 TypeModifier == OMPC_MAP_MODIFIER_close ||
 TypeModifier == OMPC_MAP_MODIFIER_present ||
@@ -4257,6 +4263,19 @@ bool 
Parser::parseMapTypeModifiers(SemaOpenMP::OpenMPVarListDataTy ) {
 Diag(Data.MapTypeModifiersLoc.back(), diag::err_omp_missing_comma)
 << "map type modifier";
 
+} else if (getLangOpts().OpenMP >= 60 && MapKind != OMPC_MAP_unknown) {
+  if (!HasMapType) {
+HasMapType = true;
+Data.ExtraModifier = MapKind;
+MapKind = OMPC_MAP_unknown;
+PreMapLoc = Tok.getLocation();
+PreMapName = Tok.getIdentifierInfo()->getName();
+  } else {
+Diag(Tok, diag::err_omp_more_one_map_type);
+Diag(PreMapLoc, diag::note_previous_map_type_specified_here)
+<< PreMapName;
+  }
+  ConsumeToken();
 } else {
   // For the case of unknown map-type-modifier or a map-type.
   // Map-type is followed by a colon; the function returns when it
@@ -4268,7 +4287,11 @@ bool 
Parser::parseMapTypeModifiers(SemaOpenMP::OpenMPVarListDataTy ) {
   }
   // Potential map-type token as it is followed by a colon.
   if (PP.LookAhead(0).is(tok::colon))
-return false;
+if (getLangOpts().OpenMP >= 60)
+  break;
+else
+  return false;
+
   Diag(Tok, diag::err_omp_unknown_map_type_modifier)
   << (getLangOpts().OpenMP >= 51 ? (getLangOpts().OpenMP >= 52 ? 2 : 1)
  : 0)
@@ -4278,6 +4301,14 @@ bool 
Parser::parseMapTypeModifiers(SemaOpenMP::OpenMPVarListDataTy ) {
 if (getCurToken().is(tok::comma))
   ConsumeToken();
   }
+  if (getLangOpts().OpenMP >= 60 && !HasMapType) {
+if (!Tok.is(tok::colon)) {
+  Diag(Tok, diag::err_omp_unknown_map_type);
+  ConsumeToken();
+} else {
+  Data.ExtraModifier = OMPC_MAP_unknown;
+}
+  }
   return false;
 }
 
@@ -4676,7 +4707,7 @@ bool Parser::ParseOpenMPVarList(OpenMPDirectiveKind DKind,
 // the map clause.
 if (ColonPresent) {
   IsInvalidMapperModifier = parseMapTypeModifiers(Data);
-  if (!IsInvalidMapperModifier)
+  if 

[clang] [NFC] Fix hasQualifier comment (PR #90485)

2024-04-29 Thread via cfe-commits

https://github.com/cor3ntin closed 
https://github.com/llvm/llvm-project/pull/90485
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] e5907c8 - [NFC] Fix hasQualifier comment (#90485)

2024-04-29 Thread via cfe-commits

Author: Jorge Pinto Sousa
Date: 2024-04-29T22:14:53+02:00
New Revision: e5907c88594133e45b8d1d4e29702b96d7f45c77

URL: 
https://github.com/llvm/llvm-project/commit/e5907c88594133e45b8d1d4e29702b96d7f45c77
DIFF: 
https://github.com/llvm/llvm-project/commit/e5907c88594133e45b8d1d4e29702b96d7f45c77.diff

LOG: [NFC] Fix hasQualifier comment (#90485)

operator bool from NestedNameSpecifierLoc and
member function hasQualifier both do the same thing, returning true if
the private data member Qualifier is not nullptr, so clearly one of the
comments is wrong, and in this case it is the second one.

fixes https://github.com/llvm/llvm-project/issues/90472

Added: 


Modified: 
clang/include/clang/AST/NestedNameSpecifier.h

Removed: 




diff  --git a/clang/include/clang/AST/NestedNameSpecifier.h 
b/clang/include/clang/AST/NestedNameSpecifier.h
index 7b0c21b9e7cfb1..a1d9e30e660d14 100644
--- a/clang/include/clang/AST/NestedNameSpecifier.h
+++ b/clang/include/clang/AST/NestedNameSpecifier.h
@@ -266,7 +266,7 @@ class NestedNameSpecifierLoc {
   explicit operator bool() const { return Qualifier; }
 
   /// Evaluates true when this nested-name-specifier location is
-  /// empty.
+  /// non-empty.
   bool hasQualifier() const { return Qualifier; }
 
   /// Retrieve the nested-name-specifier to which this instance



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang] Address post commit feedbacks in #89906 (PR #90495)

2024-04-29 Thread via cfe-commits

cor3ntin wrote:

This compiles locally. CI is really slow...

https://github.com/llvm/llvm-project/pull/90495
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang] Address post commit feedbacks in #89906 (PR #90495)

2024-04-29 Thread via cfe-commits

https://github.com/cor3ntin closed 
https://github.com/llvm/llvm-project/pull/90495
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 326657f - [Clang] Address post commit feedbacks in #89906 (#90495)

2024-04-29 Thread via cfe-commits

Author: cor3ntin
Date: 2024-04-29T22:11:09+02:00
New Revision: 326657f5679889e3374354ba3243e27bda2080f4

URL: 
https://github.com/llvm/llvm-project/commit/326657f5679889e3374354ba3243e27bda2080f4
DIFF: 
https://github.com/llvm/llvm-project/commit/326657f5679889e3374354ba3243e27bda2080f4.diff

LOG: [Clang] Address post commit feedbacks in #89906 (#90495)

* Fix a leak
* Fix a maybe unused warning
* Fix incorrect cxx_status entry

Added: 


Modified: 
clang/include/clang/Sema/DeclSpec.h
clang/lib/AST/DeclBase.cpp
clang/www/cxx_status.html

Removed: 




diff  --git a/clang/include/clang/Sema/DeclSpec.h 
b/clang/include/clang/Sema/DeclSpec.h
index 760c7980be52bd..23bc780e04979d 100644
--- a/clang/include/clang/Sema/DeclSpec.h
+++ b/clang/include/clang/Sema/DeclSpec.h
@@ -1811,15 +1811,15 @@ class DecompositionDeclarator {
   : Bindings(nullptr), NumBindings(0), DeleteBindings(false) {}
   DecompositionDeclarator(const DecompositionDeclarator ) = delete;
   DecompositionDeclarator =(const DecompositionDeclarator ) = 
delete;
-  ~DecompositionDeclarator() {
-if (DeleteBindings)
-  delete[] Bindings;
-  }
+  ~DecompositionDeclarator() { clear(); }
 
   void clear() {
 LSquareLoc = RSquareLoc = SourceLocation();
 if (DeleteBindings)
   delete[] Bindings;
+else
+  llvm::for_each(llvm::MutableArrayRef(Bindings, NumBindings),
+ [](Binding ) { B.Attrs.reset(); });
 Bindings = nullptr;
 NumBindings = 0;
 DeleteBindings = false;

diff  --git a/clang/lib/AST/DeclBase.cpp b/clang/lib/AST/DeclBase.cpp
index f341c74cf86e37..03e1055251c24f 100644
--- a/clang/lib/AST/DeclBase.cpp
+++ b/clang/lib/AST/DeclBase.cpp
@@ -1115,7 +1115,7 @@ int64_t Decl::getID() const {
 
 const FunctionType *Decl::getFunctionType(bool BlocksToo) const {
   QualType Ty;
-  if (const auto *D = dyn_cast(this))
+  if (isa(this))
 return nullptr;
   else if (const auto *D = dyn_cast(this))
 Ty = D->getType();

diff  --git a/clang/www/cxx_status.html b/clang/www/cxx_status.html
index d58c35b72c22bb..0996abc2405857 100755
--- a/clang/www/cxx_status.html
+++ b/clang/www/cxx_status.html
@@ -177,7 +177,7 @@ C++2c implementation status
  
   Attributes for Structured Bindings
   https://wg21.link/P0609R3;>P0609R3
-  No
+  Clang 19
  
  
   Module Declarations Shouldn’t be Macros
@@ -187,7 +187,7 @@ C++2c implementation status
  
   Trivial infinite loops are not Undefined Behavior
   https://wg21.link/P2809R3;>P2809R3 (DR)
-  Clang 19
+  No
  
  
   Erroneous behaviour for uninitialized reads



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang][Parse] Delay parsing of noexcept-specifiers in friend function declarations (PR #90517)

2024-04-29 Thread Krystian Stasiowski via cfe-commits

sdkrystian wrote:

This actually requires a little more work... (the delayed exception 
specification parsing code seems to only expect `CXXMethodDecl`s). I'll take 
care of that tomorrow. 

https://github.com/llvm/llvm-project/pull/90517
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang-scan-deps] Expand response files before the argument adjuster (PR #89950)

2024-04-29 Thread Alexandre Ganea via cfe-commits

https://github.com/aganea edited https://github.com/llvm/llvm-project/pull/89950
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang-scan-deps] Expand response files before the argument adjuster (PR #89950)

2024-04-29 Thread Alexandre Ganea via cfe-commits


@@ -792,10 +792,15 @@ int clang_scan_deps_main(int argc, char **argv, const 
llvm::ToolContext &) {
 
   llvm::cl::PrintOptionValues();
 
+  // Expand response files in advance, so that we can "see" all the arguments
+  // when adjusting below.
+  auto ResponseExpander = expandResponseFiles(std::move(Compilations),

aganea wrote:

As suggested.

https://github.com/llvm/llvm-project/pull/89950
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang-scan-deps] Expand response files before the argument adjuster (PR #89950)

2024-04-29 Thread Alexandre Ganea via cfe-commits


@@ -0,0 +1,36 @@
+// Check that the scanner can adjust arguments by reading .rsp files in 
advance.
+
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: sed -e "s|DIR|%/t|g" %t/cdb.json.template > %t/cdb.json
+// RUN: echo /Fo%t/tu.obj >> %t/args_nested.rsp

aganea wrote:

Can you elaborate please on "I tried playing around with response files and 
they don't play well with newlines"?
Things we working on my end (empty lines in .rsp files). Also, Unreal Engine 
generates .rsp files with each argument on a new line, so if you're seeing any 
issues there we shall fix them.

https://github.com/llvm/llvm-project/pull/89950
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang-scan-deps] Expand response files before the argument adjuster (PR #89950)

2024-04-29 Thread Alexandre Ganea via cfe-commits


@@ -0,0 +1,36 @@
+// Check that the scanner can adjust arguments by reading .rsp files in 
advance.
+
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: sed -e "s|DIR|%/t|g" %t/cdb.json.template > %t/cdb.json

aganea wrote:

As suggested. We're taking a different codepath when using the immediate mode 
(using `InplaceCompilationDatabase`) and that expands the response files in 
`OptTable::parseArgs()` so I wasn't really covering all the changes in the 
patch. I've added tests for both cases. The immediate mode allowed me to 
uncover a bug in `ParseArgs()`: `Saver` and `Alloc` were local to the function 
but we were using their contents to populate `CommandLine`. I fixed that too.

https://github.com/llvm/llvm-project/pull/89950
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang-scan-deps] Expand response files before the argument adjuster (PR #89950)

2024-04-29 Thread Alexandre Ganea via cfe-commits


@@ -1069,7 +1069,7 @@ void Clang::AddPreprocessingOptions(Compilation , const 
JobAction ,
 
   // If user provided -o, that is the dependency target, except
   // when we are only generating a dependency file.
-  Arg *OutputOpt = Args.getLastArg(options::OPT_o);
+  Arg *OutputOpt = Args.getLastArg(options::OPT_o, options::OPT__SLASH_Fo);

aganea wrote:

Added a test.

https://github.com/llvm/llvm-project/pull/89950
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang-scan-deps] Expand response files before the argument adjuster (PR #89950)

2024-04-29 Thread Alexandre Ganea via cfe-commits

https://github.com/aganea updated 
https://github.com/llvm/llvm-project/pull/89950

>From f2340c98c95e0d72516fc240ff268fead9f15391 Mon Sep 17 00:00:00 2001
From: Alexandre Ganea 
Date: Wed, 17 Apr 2024 16:28:21 -0400
Subject: [PATCH 1/5] [clang-scan-deps] Expand response files before the
 argument ajuster

Previously, since response (.rsp) files weren't expanded, we only parsed
the command-line as provided in the Clang CDB file. Unfortunately, when
using Unreal Engine, arguments are always generated in a .rsp file.

After this patch, /Fo can be parsed and added to the final command-line.
Without this option, the make targets that are emitted are made up from the
input file name alone. We have some cases where the same input in the project
generates several output files, so we end up with duplicate make targets
in the scan-deps emitted dependency file.
---
 clang/tools/clang-scan-deps/ClangScanDeps.cpp | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/clang/tools/clang-scan-deps/ClangScanDeps.cpp 
b/clang/tools/clang-scan-deps/ClangScanDeps.cpp
index f42af7e330e17a..7b7f10c4be7421 100644
--- a/clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ b/clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -792,10 +792,15 @@ int clang_scan_deps_main(int argc, char **argv, const 
llvm::ToolContext &) {
 
   llvm::cl::PrintOptionValues();
 
+  // Expand response files in advance, so that we can "see" all the arguments
+  // when adjusting below.
+  auto ResponseExpander = expandResponseFiles(std::move(Compilations),
+  llvm::vfs::getRealFileSystem());
+
   // The command options are rewritten to run Clang in preprocessor only mode.
   auto AdjustingCompilations =
   std::make_unique(
-  std::move(Compilations));
+  std::move(ResponseExpander));
   ResourceDirectoryCache ResourceDirCache;
 
   AdjustingCompilations->appendArgumentsAdjuster(

>From 09e0595fa9f3c9795d6f40a7308d8a912254b1df Mon Sep 17 00:00:00 2001
From: Alexandre Ganea 
Date: Wed, 24 Apr 2024 13:52:55 -0400
Subject: [PATCH 2/5] Add test

---
 .../ClangScanDeps/response-file-clang-cl.c| 32 +++
 1 file changed, 32 insertions(+)
 create mode 100644 clang/test/ClangScanDeps/response-file-clang-cl.c

diff --git a/clang/test/ClangScanDeps/response-file-clang-cl.c 
b/clang/test/ClangScanDeps/response-file-clang-cl.c
new file mode 100644
index 00..78e3d15deb1678
--- /dev/null
+++ b/clang/test/ClangScanDeps/response-file-clang-cl.c
@@ -0,0 +1,32 @@
+// Check that the scanner can adjust arguments by reading .rsp files in 
advance.
+
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: sed -e "s|DIR|%/t|g" %t/cdb.json.template > %t/cdb.json
+// RUN: echo /Fo%t/tu.obj >> %t/args_nested.rsp
+
+// RUN: clang-scan-deps -compilation-database %t/cdb.json > %t/deps.json
+
+// RUN: cat %t/deps.json | sed 's:\?:/:g' | FileCheck -DPREFIX=%/t %s
+
+// Here we ensure that we got a qualified .obj with its full path, since 
that's what we're passing with /Fo
+// CHECK: [[PREFIX]]/tu.obj:
+
+//--- cdb.json.template
+[{
+  "file": "DIR/t.cpp",
+  "directory": "DIR",
+  "command": "clang-cl @DIR/args.rsp"
+}]
+
+//--- args.rsp
+@args_nested.rsp
+/c tu.cpp
+
+//--- args_nested.rsp
+/I include
+
+//--- include/header.h
+
+//--- tu.cpp
+#include "header.h"

>From 812a14f882995b832599222f0a747761378d31b8 Mon Sep 17 00:00:00 2001
From: Alexandre Ganea 
Date: Wed, 24 Apr 2024 17:02:17 -0400
Subject: [PATCH 3/5] Handle /Fo in the Clang driver as well.

---
 clang/lib/Driver/ToolChains/Clang.cpp | 2 +-
 clang/test/ClangScanDeps/response-file-clang-cl.c | 6 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 5f5d720cf759f4..69f888fcf323a4 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -1069,7 +1069,7 @@ void Clang::AddPreprocessingOptions(Compilation , const 
JobAction ,
 
   // If user provided -o, that is the dependency target, except
   // when we are only generating a dependency file.
-  Arg *OutputOpt = Args.getLastArg(options::OPT_o);
+  Arg *OutputOpt = Args.getLastArg(options::OPT_o, options::OPT__SLASH_Fo);
   if (OutputOpt && Output.getType() != types::TY_Dependencies) {
 DepTarget = OutputOpt->getValue();
   } else {
diff --git a/clang/test/ClangScanDeps/response-file-clang-cl.c 
b/clang/test/ClangScanDeps/response-file-clang-cl.c
index 78e3d15deb1678..77cecfff0b9ca8 100644
--- a/clang/test/ClangScanDeps/response-file-clang-cl.c
+++ b/clang/test/ClangScanDeps/response-file-clang-cl.c
@@ -5,8 +5,12 @@
 // RUN: sed -e "s|DIR|%/t|g" %t/cdb.json.template > %t/cdb.json
 // RUN: echo /Fo%t/tu.obj >> %t/args_nested.rsp
 
+// RUN: echo /c >> %t/args_nested.rsp
 // RUN: clang-scan-deps -compilation-database %t/cdb.json > %t/deps.json
+// RUN: cat %t/deps.json | sed 

[clang] [Clang][Parse] Delay parsing of noexcept-specifiers in friend function declarations (PR #90517)

2024-04-29 Thread Krystian Stasiowski via cfe-commits

sdkrystian wrote:

Note: This still needs a release note + test updates

https://github.com/llvm/llvm-project/pull/90517
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang][Parse] Delay parsing of noexcept-specifiers in friend function declarations (PR #90517)

2024-04-29 Thread via cfe-commits

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Krystian Stasiowski (sdkrystian)


Changes

According to [[class.mem.general] 
p8](http://eel.is/c++draft/class.mem.general#8):
 A complete-class context of a class (template) is a
 - function body,
 - default argument,
 - default template argument,
 - _noexcept-specifier_, or
 - default member initializer

 within the member-specification of the class or class template.

When testing #90152, it came to my attention that we do _not_ consider 
the _noexcept-specifier_ of a friend function declaration to be a 
complete-class context (something which the Microsoft standard library depends 
on). Although a comment states that this is "consistent with what other 
implementations do", the only other implementation that exhibits this behavior 
is GCC (MSVC and EDG both late-parse the _noexcept-specifier_). 

This patch changes _noexcept-specifiers_ of friend function declarations to be 
late parsed, which is in agreement with the standard  majority of 
implementations. Pre-#90152, our existing implementation falls "in 
between" the implementation consensus: within non-template classes, we would 
not find latter declared members (qualified and unqualified), while within 
class templates we would not find latter declared member when named with a 
unqualified name, we would find members named with a qualified name (even when 
lookup context is the current instantiation). Therefore, this _shouldn't_ be a 
breaking change -- any code that didn't compile will continue to not compile 
(since a _noexcept-specifier_ is not part of the [deduction substitution 
loci](http://eel.is/c++draft/temp.deduct.general#7)), and any code 
which did compile should continue to do so.

---
Full diff: https://github.com/llvm/llvm-project/pull/90517.diff


1 Files Affected:

- (modified) clang/lib/Parse/ParseDecl.cpp (+14-6) 


``diff
diff --git a/clang/lib/Parse/ParseDecl.cpp b/clang/lib/Parse/ParseDecl.cpp
index a7846e102a43c7..93950e27a08f35 100644
--- a/clang/lib/Parse/ParseDecl.cpp
+++ b/clang/lib/Parse/ParseDecl.cpp
@@ -7388,12 +7388,20 @@ void Parser::ParseFunctionDeclarator(Declarator ,
   std::optional ThisScope;
   InitCXXThisScopeForDeclaratorIfRelevant(D, DS, ThisScope);
 
-  // Parse exception-specification[opt].
-  // FIXME: Per [class.mem]p6, all exception-specifications at class scope
-  // should be delayed, including those for non-members (eg, friend
-  // declarations). But only applying this to member declarations is
-  // consistent with what other implementations do.
-  bool Delayed = D.isFirstDeclarationOfMember() &&
+  // C++ [class.mem.general]p8:
+  //   A complete-class context of a class (template) is a
+  // - function body,
+  // - default argument,
+  // - default template argument,
+  // - noexcept-specifier, or
+  // - default member initializer
+  //   within the member-specification of the class or class template.
+  //
+  // Parse exception-specification[opt]. If we are in the
+  // member-specification of a class or class template, this is a
+  // complete-class context and parsing of the noexcept-specifier should be
+  // delayed (even if this is a friend declaration).
+  bool Delayed = D.getContext() == DeclaratorContext::Member &&
  D.isFunctionDeclaratorAFunctionDeclaration();
   if (Delayed && Actions.isLibstdcxxEagerExceptionSpecHack(D) &&
   GetLookAheadToken(0).is(tok::kw_noexcept) &&

``




https://github.com/llvm/llvm-project/pull/90517
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang][Parse] Delay parsing of noexcept-specifiers in friend function declarations (PR #90517)

2024-04-29 Thread Krystian Stasiowski via cfe-commits

https://github.com/sdkrystian created 
https://github.com/llvm/llvm-project/pull/90517

According to [[class.mem.general] 
p8](http://eel.is/c++draft/class.mem.general#8):
> A complete-class context of a class (template) is a
> - function body,
> - default argument,
> - default template argument,
> - _noexcept-specifier_, or
> - default member initializer
>
> within the member-specification of the class or class template.

When testing #90152, it came to my attention that we do _not_ consider the 
_noexcept-specifier_ of a friend function declaration to be a complete-class 
context (something which the Microsoft standard library depends on). Although a 
comment states that this is "consistent with what other implementations do", 
the only other implementation that exhibits this behavior is GCC (MSVC and EDG 
both late-parse the _noexcept-specifier_). 

This patch changes _noexcept-specifiers_ of friend function declarations to be 
late parsed, which is in agreement with the standard & majority of 
implementations. Pre-#90152, our existing implementation falls "in between" the 
implementation consensus: within non-template classes, we would not find latter 
declared members (qualified and unqualified), while within class templates we 
would not find latter declared member when named with a unqualified name, we 
would find members named with a qualified name (even when lookup context is the 
current instantiation). Therefore, this _shouldn't_ be a breaking change -- any 
code that didn't compile will continue to not compile (since a 
_noexcept-specifier_ is not part of the [deduction substitution 
loci](http://eel.is/c++draft/temp.deduct.general#7)), and any code which did 
compile should continue to do so.

>From 3f5feb2b17c06f6e001e9324e90eef07fd720539 Mon Sep 17 00:00:00 2001
From: Krystian Stasiowski 
Date: Mon, 29 Apr 2024 15:34:40 -0400
Subject: [PATCH] [Clang][Parse] Delay parsing of noexcept-specifiers in friend
 function declarations

---
 clang/lib/Parse/ParseDecl.cpp | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/clang/lib/Parse/ParseDecl.cpp b/clang/lib/Parse/ParseDecl.cpp
index a7846e102a43c7..93950e27a08f35 100644
--- a/clang/lib/Parse/ParseDecl.cpp
+++ b/clang/lib/Parse/ParseDecl.cpp
@@ -7388,12 +7388,20 @@ void Parser::ParseFunctionDeclarator(Declarator ,
   std::optional ThisScope;
   InitCXXThisScopeForDeclaratorIfRelevant(D, DS, ThisScope);
 
-  // Parse exception-specification[opt].
-  // FIXME: Per [class.mem]p6, all exception-specifications at class scope
-  // should be delayed, including those for non-members (eg, friend
-  // declarations). But only applying this to member declarations is
-  // consistent with what other implementations do.
-  bool Delayed = D.isFirstDeclarationOfMember() &&
+  // C++ [class.mem.general]p8:
+  //   A complete-class context of a class (template) is a
+  // - function body,
+  // - default argument,
+  // - default template argument,
+  // - noexcept-specifier, or
+  // - default member initializer
+  //   within the member-specification of the class or class template.
+  //
+  // Parse exception-specification[opt]. If we are in the
+  // member-specification of a class or class template, this is a
+  // complete-class context and parsing of the noexcept-specifier should be
+  // delayed (even if this is a friend declaration).
+  bool Delayed = D.getContext() == DeclaratorContext::Member &&
  D.isFunctionDeclaratorAFunctionDeclaration();
   if (Delayed && Actions.isLibstdcxxEagerExceptionSpecHack(D) &&
   GetLookAheadToken(0).is(tok::kw_noexcept) &&

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [CIR] Add options to emit ClangIR and enable the ClangIR pipeline (PR #89030)

2024-04-29 Thread Nathan Lanza via cfe-commits

https://github.com/lanza closed https://github.com/llvm/llvm-project/pull/89030
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 359ab3a - [CIR] Add options to emit ClangIR and enable the ClangIR pipeline

2024-04-29 Thread via cfe-commits

Author: Nathan Lanza
Date: 2024-04-29T15:46:18-04:00
New Revision: 359ab3aebba302fb4c37373b9907bc8880be7363

URL: 
https://github.com/llvm/llvm-project/commit/359ab3aebba302fb4c37373b9907bc8880be7363
DIFF: 
https://github.com/llvm/llvm-project/commit/359ab3aebba302fb4c37373b9907bc8880be7363.diff

LOG: [CIR] Add options to emit ClangIR and enable the ClangIR pipeline

Introduce just the option definitions and support for their existance at
a few different points in the frontend. This will be followed soon by
functionality that uses it.

Reviewers: bcardosolopes, jansvoboda11, AaronBallman, erichkeane, MaskRay

Reviewed By: erichkeane

Pull Request: https://github.com/llvm/llvm-project/pull/89030

Added: 


Modified: 
clang/include/clang/Driver/Options.td
clang/include/clang/Frontend/FrontendOptions.h
clang/lib/Driver/Driver.cpp
clang/lib/Frontend/CompilerInvocation.cpp
clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 263d1edf141a0b..25f479dccc3c80 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -2886,6 +2886,17 @@ def flax_vector_conversions : Flag<["-"], 
"flax-vector-conversions">, Group, Group,
   HelpText<"Force linking the clang builtins runtime library">;
+
+/// ClangIR-specific options - BEGIN
+defm clangir : BoolFOption<"clangir",
+  FrontendOpts<"UseClangIRPipeline">, DefaultFalse,
+  PosFlag,
+  NegFlag LLVM 
pipeline to compile">,
+  BothFlags<[], [ClangOption, CC1Option], "">>;
+def emit_cir : Flag<["-"], "emit-cir">, Visibility<[CC1Option]>,
+  Group, HelpText<"Build ASTs and then lower to ClangIR">;
+/// ClangIR-specific options - END
+
 def flto_EQ : Joined<["-"], "flto=">,
   Visibility<[ClangOption, CLOption, CC1Option, FC1Option, FlangOption]>,
   Group,

diff  --git a/clang/include/clang/Frontend/FrontendOptions.h 
b/clang/include/clang/Frontend/FrontendOptions.h
index a738c1f3757682..bd4981ca0ac08c 100644
--- a/clang/include/clang/Frontend/FrontendOptions.h
+++ b/clang/include/clang/Frontend/FrontendOptions.h
@@ -65,6 +65,9 @@ enum ActionKind {
   /// Translate input source into HTML.
   EmitHTML,
 
+  /// Emit a .cir file
+  EmitCIR,
+
   /// Emit a .ll file.
   EmitLLVM,
 
@@ -408,6 +411,10 @@ class FrontendOptions {
   LLVM_PREFERRED_TYPE(bool)
   unsigned GenReducedBMI : 1;
 
+  /// Use Clang IR pipeline to emit code
+  LLVM_PREFERRED_TYPE(bool)
+  unsigned UseClangIRPipeline : 1;
+
   CodeCompleteOptions CodeCompleteOpts;
 
   /// Specifies the output format of the AST.
@@ -590,7 +597,7 @@ class FrontendOptions {
 EmitSymbolGraph(false), EmitExtensionSymbolGraphs(false),
 EmitSymbolGraphSymbolLabelsForTesting(false),
 EmitPrettySymbolGraphs(false), GenReducedBMI(false),
-TimeTraceGranularity(500) {}
+UseClangIRPipeline(false), TimeTraceGranularity(500) {}
 
   /// getInputKindForExtension - Return the appropriate input kind for a file
   /// extension. For example, "c" would return Language::C.

diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 76b7b9fdfb4f9b..114320f5d31468 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -361,6 +361,7 @@ phases::ID Driver::getFinalPhase(const DerivedArgList ,
  (PhaseArg = DAL.getLastArg(options::OPT_rewrite_legacy_objc)) ||
  (PhaseArg = DAL.getLastArg(options::OPT__migrate)) ||
  (PhaseArg = DAL.getLastArg(options::OPT__analyze)) ||
+ (PhaseArg = DAL.getLastArg(options::OPT_emit_cir)) ||
  (PhaseArg = DAL.getLastArg(options::OPT_emit_ast))) {
 FinalPhase = phases::Compile;
 
@@ -4799,6 +4800,8 @@ Action *Driver::ConstructPhaseAction(
   return C.MakeAction(Input, types::TY_Remap);
 if (Args.hasArg(options::OPT_emit_ast))
   return C.MakeAction(Input, types::TY_AST);
+if (Args.hasArg(options::OPT_emit_cir))
+  return C.MakeAction(Input, types::TY_CIR);
 if (Args.hasArg(options::OPT_module_file_info))
   return C.MakeAction(Input, types::TY_ModuleFile);
 if (Args.hasArg(options::OPT_verify_pch))

diff  --git a/clang/lib/Frontend/CompilerInvocation.cpp 
b/clang/lib/Frontend/CompilerInvocation.cpp
index 8236051e30c4a5..8312abc3603953 100644
--- a/clang/lib/Frontend/CompilerInvocation.cpp
+++ b/clang/lib/Frontend/CompilerInvocation.cpp
@@ -2549,6 +2549,7 @@ static const auto () {
   {frontend::DumpTokens, OPT_dump_tokens},
   {frontend::EmitAssembly, OPT_S},
   {frontend::EmitBC, OPT_emit_llvm_bc},
+  {frontend::EmitCIR, OPT_emit_cir},
   {frontend::EmitHTML, OPT_emit_html},
   {frontend::EmitLLVM, OPT_emit_llvm},
   {frontend::EmitLLVMOnly, OPT_emit_llvm_only},
@@ -2891,6 +2892,8 @@ static bool ParseFrontendArgs(FrontendOptions , 
ArgList ,
   if 

[clang] [CIR] Add options to emit ClangIR and enable the ClangIR pipeline (PR #89030)

2024-04-29 Thread Nathan Lanza via cfe-commits

https://github.com/lanza edited https://github.com/llvm/llvm-project/pull/89030
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [x86] Add tan intrinsic part 4 (PR #90503)

2024-04-29 Thread Thorsten Schütt via cfe-commits


@@ -674,6 +674,9 @@
 # DEBUG-NEXT: .. opcode {{[0-9]+}} is aliased to {{[0-9]+}}
 # DEBUG-NEXT: .. the first uncovered type index: 1, OK
 # DEBUG-NEXT: .. the first uncovered imm index: 0, OK
+# DEBUG-NEXT: G_FTAN (opcode {{[0-9]+}}): 1 type index, 0 imm indices

tschuett wrote:

It means that the AArch64 GlobalIsel legalizer does not say anything about 
G_FTAN.

https://github.com/llvm/llvm-project/pull/90503
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][NFC] Reformat suspicious condition (PR #89923)

2024-04-29 Thread via cfe-commits

https://github.com/cor3ntin closed 
https://github.com/llvm/llvm-project/pull/89923
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 99ce84c - [clang][NFC] Reformat suspicious condition (#89923)

2024-04-29 Thread via cfe-commits

Author: Troy Butler
Date: 2024-04-29T21:24:29+02:00
New Revision: 99ce84cef0185fe9eaec51e40ea80f69f06981f0

URL: 
https://github.com/llvm/llvm-project/commit/99ce84cef0185fe9eaec51e40ea80f69f06981f0
DIFF: 
https://github.com/llvm/llvm-project/commit/99ce84cef0185fe9eaec51e40ea80f69f06981f0.diff

LOG: [clang][NFC] Reformat suspicious condition (#89923)

Addresses issue #89805.
Assignment + comparison performed in conditional statement. Resolved by
parenthesizing comparison operation.

Fixes #89805.

-

Signed-off-by: Troy-Butler 

Added: 


Modified: 
clang/lib/Lex/Pragma.cpp

Removed: 




diff  --git a/clang/lib/Lex/Pragma.cpp b/clang/lib/Lex/Pragma.cpp
index 499813f8ab7df0..ced407355e0015 100644
--- a/clang/lib/Lex/Pragma.cpp
+++ b/clang/lib/Lex/Pragma.cpp
@@ -1444,7 +1444,7 @@ struct PragmaWarningHandler : public PragmaHandler {
  .Case("once", PPCallbacks::PWS_Once)
  .Case("suppress", PPCallbacks::PWS_Suppress)
  .Default(-1);
-  if ((SpecifierValid = SpecifierInt != -1))
+  if (SpecifierValid = (SpecifierInt != -1))
 Specifier =
 static_cast(SpecifierInt);
 



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][NFC] Reformat suspicious condition (PR #89923)

2024-04-29 Thread via cfe-commits

cor3ntin wrote:

I think CI is having some difficulties. No need to wait for it for this.
Thanks a lot for your first contribution!
We have some good first issues if you want to have a go at some more 
contributions
https://github.com/llvm/llvm-project/issues?q=is%3Aissue+is%3Aopen+good+first+issues+label%3A%22good+first+issue%22
 

https://github.com/llvm/llvm-project/pull/89923
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][NFC] Reformat suspicious condition (PR #89923)

2024-04-29 Thread Shafik Yaghmour via cfe-commits

shafik wrote:

The `amdgpu-toolchain.c` test failure looks unrelated. I think we need another 
empty commit to kick off the build again unfortunately.

https://github.com/llvm/llvm-project/pull/89923
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [NFC] Fix hasQualifier comment (PR #90485)

2024-04-29 Thread Shafik Yaghmour via cfe-commits

https://github.com/shafik approved this pull request.

LGTM, thank you for the documentation fix.

https://github.com/llvm/llvm-project/pull/90485
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [x86] Add tan intrinsic part 4 (PR #90503)

2024-04-29 Thread Thorsten Schütt via cfe-commits

tschuett wrote:

Firstly, it is a nit. The IRTranslator translates LLVM-IR into GMIR for 
GlobalIsel. Testing the IRTranslator is independent of any SDAG changes.

https://github.com/llvm/llvm-project/pull/90503
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] Handle trivial_abi attribute for Microsoft ABI. (PR #88857)

2024-04-29 Thread Tobias Hieta via cfe-commits


@@ -1105,6 +1105,11 @@ bool MicrosoftCXXABI::hasMostDerivedReturn(GlobalDecl 
GD) const {
 
 static bool isTrivialForMSVC(const CXXRecordDecl *RD, QualType Ty,
  CodeGenModule ) {
+  // If the record is marked with the trivial_abi attribute, we don't
+  // have to conform to the standard MSVC ABI.
+  if (RD->hasAttr())

tru wrote:

Happy to add this. Can you point me to an example where we search recursively 
or give some pseudo code example and I should be able to take it from there 
pretty soon. 

https://github.com/llvm/llvm-project/pull/88857
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Modules] Detect ODR mismatches for enums in non-C++ like in C++. (PR #90298)

2024-04-29 Thread David Blaikie via cfe-commits

dwblaikie wrote:

> > C doesn't have an odr, does it?
> 
> For non-C++ "ODR" has a meaning more like "ODR-inspired checks". But there is 
> no language rule that would require enforcement and there is no impact on 
> linkage (at least during deserialization).

Not sure I'm following the response here - but I guess what I'm trying to say, 
with more words, is that my understanding was that C doesn't have an ODR, and 
you can have different definitions of a type, with the same name, in C and 
that's OK.

And it sounds like this change makes that not OK in some way? (either by 
diagnosing/erroring on such divergent types, or assuming they won't diverge and 
carrying on silently)

https://github.com/llvm/llvm-project/pull/90298
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [x86] Add tan intrinsic part 4 (PR #90503)

2024-04-29 Thread Farzon Lotfi via cfe-commits

farzonl wrote:

> Nit: the `declare` is not necessary anymore. You touched the IRTranslator 
> without a test at, e.g., 
> https://github.com/llvm/llvm-project/blob/main/llvm/test/CodeGen/AArch64/GlobalISel/arm64-irtranslator.ll

The aarch64 backend tag is a misnomer because adding `G_FTAN` caused the 
legalizer to complain in this arm64 test case: 
llvm/test/CodeGen/AArch64/GlobalISel/legalizer-info-validation.mir

I could add
```
declare float @llvm.tan.f32(float)
define float @test_tan_f32(float %x) {
  ; CHECK-LABEL: name:test_tan_f32
  ; CHECK: %{{[0-9]+}}:_(s32) = G_FTAN %{{[0-9]+}}
  %y = call float @llvm.tan.f32(float %x)
  ret float %y
}
```
But I feel like this should be added when a tan intrinsic lowering is done for 
arm64 in llvm/lib/Target/AArch64/AArch64ISelLowering.cpp

https://github.com/llvm/llvm-project/pull/90503
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [AST] Dump explicit template arguments for UnreslovedLookupExpr. (PR #90466)

2024-04-29 Thread Haojian Wu via cfe-commits

https://github.com/hokein edited https://github.com/llvm/llvm-project/pull/90466
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang codegen] Fix MS ABI detection of user-provided constructors. (PR #90151)

2024-04-29 Thread Eli Friedman via cfe-commits

https://github.com/efriedma-quic closed 
https://github.com/llvm/llvm-project/pull/90151
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 3ab4ae9 - [clang codegen] Fix MS ABI detection of user-provided constructors. (#90151)

2024-04-29 Thread via cfe-commits

Author: Eli Friedman
Date: 2024-04-29T12:00:12-07:00
New Revision: 3ab4ae9e58c09dfd8203547ba8916f3458a0a481

URL: 
https://github.com/llvm/llvm-project/commit/3ab4ae9e58c09dfd8203547ba8916f3458a0a481
DIFF: 
https://github.com/llvm/llvm-project/commit/3ab4ae9e58c09dfd8203547ba8916f3458a0a481.diff

LOG: [clang codegen] Fix MS ABI detection of user-provided constructors. 
(#90151)

In the context of determining whether a class counts as an "aggregate",
a constructor template counts as a user-provided constructor.

Fixes #86384

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/lib/CodeGen/MicrosoftCXXABI.cpp
clang/test/CodeGen/arm64-microsoft-arguments.cpp

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 2d0e663d93e46f..55e1670b7e2fa0 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -63,6 +63,12 @@ ABI Changes in This Version
   MSVC uses a 
diff erent mangling for these objects, compatibility is not affected.
   (#GH85423).
 
+- Fixed Microsoft calling convention for returning certain classes with a
+  templated constructor. If a class has a templated constructor, it should
+  be returned indirectly even if it meets all the other requirements for
+  returning a class in a register. This affects some uses of std::pair.
+  (#GH86384).
+
 AST Dumping Potentially Breaking Changes
 
 

diff  --git a/clang/lib/CodeGen/MicrosoftCXXABI.cpp 
b/clang/lib/CodeGen/MicrosoftCXXABI.cpp
index d38a26940a3cb6..d47927745759e1 100644
--- a/clang/lib/CodeGen/MicrosoftCXXABI.cpp
+++ b/clang/lib/CodeGen/MicrosoftCXXABI.cpp
@@ -1131,9 +1131,15 @@ static bool isTrivialForMSVC(const CXXRecordDecl *RD, 
QualType Ty,
 return false;
   if (RD->hasNonTrivialCopyAssignment())
 return false;
-  for (const CXXConstructorDecl *Ctor : RD->ctors())
-if (Ctor->isUserProvided())
-  return false;
+  for (const Decl *D : RD->decls()) {
+if (auto *Ctor = dyn_cast(D)) {
+  if (Ctor->isUserProvided())
+return false;
+} else if (auto *Template = dyn_cast(D)) {
+  if (isa(Template->getTemplatedDecl()))
+return false;
+}
+  }
   if (RD->hasNonTrivialDestructor())
 return false;
   return true;

diff  --git a/clang/test/CodeGen/arm64-microsoft-arguments.cpp 
b/clang/test/CodeGen/arm64-microsoft-arguments.cpp
index e8309888dcfe21..85472645acb3b3 100644
--- a/clang/test/CodeGen/arm64-microsoft-arguments.cpp
+++ b/clang/test/CodeGen/arm64-microsoft-arguments.cpp
@@ -201,3 +201,18 @@ S11 f11() {
   S11 x;
   return func11(x);
 }
+
+// GH86384
+// Pass and return object with template constructor (pass directly,
+// return indirectly).
+// CHECK: define dso_local void @"?f12@@YA?AUS12@@XZ"(ptr dead_on_unwind inreg 
noalias writable sret(%struct.S12) align 4 {{.*}})
+// CHECK: call void @"?func12@@YA?AUS12@@U1@@Z"(ptr dead_on_unwind inreg 
writable sret(%struct.S12) align 4 {{.*}}, i64 {{.*}})
+struct S12 {
+  template S12(T*) {}
+  int x;
+};
+S12 func12(S12 x);
+S12 f12() {
+  S12 x((int*)0);
+  return func12(x);
+}



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [clang][hlsl] Add tan intrinsic part 1 (PR #90276)

2024-04-29 Thread Eli Friedman via cfe-commits

efriedma-quic wrote:

Are you intentionally skipping implementing changes to __builtin_tan()?

https://github.com/llvm/llvm-project/pull/90276
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [NFC] Fix hasQualifier comment (PR #90485)

2024-04-29 Thread Jorge Pinto Sousa via cfe-commits

https://github.com/sousajo-cc edited 
https://github.com/llvm/llvm-project/pull/90485
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [compiler-rt] [libc] [libclc] [libcxxabi] [lld] [lldb] [llvm] [mlir] llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp:3804: lacking () for c… (PR #90391)

2024-04-29 Thread via cfe-commits

lntue wrote:

> #85868

You can update the title of the PR to reflect the changes, and add `Fixes 
https://github.com/llvm/llvm-project/issues/85868` to relating the PR to the 
issue.

OTOH, the libc changes look good to me.

https://github.com/llvm/llvm-project/pull/90391
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang] Implement P2809: Trivial infinite loops are not Undefined Behavior (PR #90066)

2024-04-29 Thread Shafik Yaghmour via cfe-commits


@@ -908,6 +908,74 @@ void CodeGenFunction::EmitIfStmt(const IfStmt ) {
 incrementProfileCounter();
 }
 
+bool CodeGenFunction::checkIfLoopMustProgress(const Expr 
*ControllingExpression,
+  bool IsTrivialCXXLoop) {
+  if (CGM.getCodeGenOpts().getFiniteLoops() ==
+  CodeGenOptions::FiniteLoopsKind::Always)
+return true;
+  if (CGM.getCodeGenOpts().getFiniteLoops() ==
+  CodeGenOptions::FiniteLoopsKind::Never)
+return false;
+
+  // Now apply rules for plain C (see  6.8.5.6 in C11).
+  // Loops with constant conditions do not have to make progress in any C
+  // version.
+  // As an extension, we consisider loops whose constant expression
+  // can be constant-folded.
+  Expr::EvalResult Result;
+  bool CondIsConstInt =
+  !ControllingExpression ||
+  (ControllingExpression->EvaluateAsInt(Result, getContext()) &&
+   Result.Val.isInt());
+
+  bool CondIsTrue = CondIsConstInt &&
+(!ControllingExpression || Result.Val.getInt().getBoolValue());
+
+  if (getLangOpts().C99 && CondIsConstInt)
+return false;
+
+  // Loops with non-constant conditions must make progress in C11 and later.
+  if (getLangOpts().C11)
+return true;
+
+  // [C++26][intro.progress] (DR)
+  // The implementation may assume that any thread will eventually do one of 
the
+  // following:
+  // [...]
+  // - continue execution of a trivial infinite loop ([stmt.iter.general]).
+  if (getLangOpts().CPlusPlus11) {
+if (IsTrivialCXXLoop && CondIsTrue) {
+  CurFn->removeFnAttr(llvm::Attribute::MustProgress);
+  return false;
+}
+return true;
+  }
+
+  return false;
+}
+
+// [C++26][stmt.iter.general] (DR)
+// A trivially empty iteration statement is an iteration statement matching one
+// of the following forms:
+//  - while ( expression ) ;
+//  - while ( expression ) { }
+//  - do ; while ( expression ) ;
+//  - do { } while ( expression ) ;
+//  - for ( init-statement expression(opt); ) ;
+//  - for ( init-statement expression(opt); ) { }
+template  static bool hasEmptyLoopBody(const LoopStmt ) {
+  if constexpr (std::is_same_v) {
+if (S.getInc())
+  return false;
+  }
+  const Stmt *Body = S.getBody();
+  if (!Body || isa(Body))
+return true;
+  if (const CompoundStmt *Compound = dyn_cast(Body))

shafik wrote:

It does not look like the test cover the `CompoundStmt` case.

https://github.com/llvm/llvm-project/pull/90066
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang] Implement P2809: Trivial infinite loops are not Undefined Behavior (PR #90066)

2024-04-29 Thread Shafik Yaghmour via cfe-commits


@@ -1465,6 +1465,7 @@ void CodeGenFunction::GenerateCode(GlobalDecl GD, 
llvm::Function *Fn,
 
   // Ensure that the function adheres to the forward progress guarantee, which
   // is required by certain optimizations.
+  // The attribute will be removed if the body contains a trivial empty loop.

shafik wrote:

```suggestion
  // In C++11 and forward, the attribute will be removed if the body contains a 
trivial empty loop.
```

https://github.com/llvm/llvm-project/pull/90066
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [coro] Lower `llvm.coro.await.suspend.handle` to resume with tail call (PR #89751)

2024-04-29 Thread via cfe-commits


@@ -1056,6 +1083,25 @@ void CoroCloner::create() {
   // Set up the new entry block.
   replaceEntryBlock();
 
+  // Turn symmetric transfers into musttail calls.
+  for (CallInst *ResumeCall : Shape.SymmetricTransfers) {
+ResumeCall = cast(VMap[ResumeCall]);
+ResumeCall->setCallingConv(NewF->getCallingConv());
+if (TTI.supportsTailCallFor(ResumeCall)) {
+  // FIXME: Could we support symmetric transfer effectively without
+  // musttail?
+  ResumeCall->setTailCallKind(CallInst::TCK_MustTail);
+}
+
+// Put a 'ret void' after the call, and split any remaining instructions to

zmodem wrote:

I want the semantics to be well specified. Either the doc for this intrinsic 
should say that instructions between it and `llvm.coro.suspend` are not allowed 
(possibly with a list of exceptions) and we enforce it with an assert or the 
verifier; or it allows such instructions but says that they become unreachable 
as in the current version.

I'm in favor of the latter because it makes the IR more regular. We generally 
don't impose restrictions about what instructions are allowed between intrinsic 
calls. Instructions after a call not getting executed is not new, so I think 
what the current version of the patch does fits in well with the IR.

https://github.com/llvm/llvm-project/pull/89751
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][CodeGen] Propagate pragma set fast-math flags to floating point builtins (PR #90377)

2024-04-29 Thread Zahira Ammarguellat via cfe-commits


@@ -0,0 +1,28 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py 
UTC_ARGS: --version 4
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -O3 -emit-llvm -o - %s \
+// RUN: | FileCheck -check-prefix=CHECK %s
+
+// Reproducer for issue #87758
+// The testcase below verifies that the "fast" flag are set on the calls.
+
+float sqrtf(float x);
+float powf(float x, float y);
+float fmaf(float x, float y, float z);
+
+#pragma float_control(push)
+#pragma float_control(precise, off)
+// CHECK-LABEL: define dso_local float @fp_precise_libm_calls(
+// CHECK-SAME: float noundef [[A:%.*]], float noundef [[B:%.*]], float noundef 
[[C:%.*]]) local_unnamed_addr #[[ATTR0:[0-9]+]] {
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[TMP0:%.*]] = tail call fast float @llvm.sqrt.f32(float 
[[A]])
+// CHECK-NEXT:[[TMP1:%.*]] = tail call fast float @llvm.pow.f32(float 
[[TMP0]], float [[B]])
+// CHECK-NEXT:[[TMP2:%.*]] = tail call fast float @llvm.fma.f32(float 
[[TMP1]], float [[B]], float [[C]])
+// CHECK-NEXT:ret float [[TMP2]]
+//
+float fp_precise_libm_calls(float a, float b, float c) {
+  a = sqrtf(a);
+  a = powf(a,b);
+  a = fmaf(a,b,c);
+  return a;
+}
+#pragma float_control(pop)

zahiraam wrote:

You could also use the same test with `#pragma float_control(precise,on)` and 
confirm that the fast flags are not set. 

https://github.com/llvm/llvm-project/pull/90377
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][CodeGen] Propagate pragma set fast-math flags to floating point builtins (PR #90377)

2024-04-29 Thread Zahira Ammarguellat via cfe-commits


@@ -0,0 +1,28 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py 
UTC_ARGS: --version 4
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -O3 -emit-llvm -o - %s \
+// RUN: | FileCheck -check-prefix=CHECK %s
+

zahiraam wrote:

How about adding a run line with `ffast-math` option?

https://github.com/llvm/llvm-project/pull/90377
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][CodeGen] Propagate pragma set fast-math flags to floating point builtins (PR #90377)

2024-04-29 Thread Zahira Ammarguellat via cfe-commits


@@ -0,0 +1,28 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py 
UTC_ARGS: --version 4
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -O3 -emit-llvm -o - %s \

zahiraam wrote:

There is no need to use -O3 here to prove what you want, I think.

https://github.com/llvm/llvm-project/pull/90377
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Driver] Clean up denormal handling with fast-math-related options (PR #89477)

2024-04-29 Thread Andy Kaylor via cfe-commits

https://github.com/andykaylor edited 
https://github.com/llvm/llvm-project/pull/89477
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Clean up denormal handling with -ffp-model, -ffast-math, etc. (PR #89477)

2024-04-29 Thread Andy Kaylor via cfe-commits

https://github.com/andykaylor updated 
https://github.com/llvm/llvm-project/pull/89477

>From 8ab931c4506f08685758a58f4cf7974c5254c3fa Mon Sep 17 00:00:00 2001
From: Andy Kaylor 
Date: Fri, 19 Apr 2024 17:53:52 -0700
Subject: [PATCH 1/8] Clean up denormal handling with -ffp-model, -ffast-math,
 etc.

This change cleans up the clang driver handling of umbrella options like
-ffast-math, -funsafe-math-optimizations, and -ffp-model, and aligns the
behavior of -ffp-model=fast with -ffast-math with regard to the linking of
crtfastmath.o.

We agreed in a previous review that the fast-math options should not
attempt to change the -fdenormal-fp-math option, which is inherently
target-specific.

The clang user's manual claims that -ffp-model=fast "behaves identically
to specifying both -ffast-math and -ffp-contract=fast." Since -ffast-math
causes crtfastmath.o to be linked if it is available, that should also
happen with -ffp-model=fast.

I am going to be proposing further changes to -ffp-model=fast,
decoupling it from -ffast-math and introducing a new
-ffp-model=aggressive that matches the current behavior, but I wanted
to solidfy the current behavior before I do that.
---
 clang/docs/UsersManual.rst| 4 ++--
 clang/lib/Driver/ToolChain.cpp| 8 +++-
 clang/lib/Driver/ToolChains/Clang.cpp | 4 
 clang/test/Driver/linux-ld.c  | 3 +++
 clang/test/Driver/solaris-ld.c| 3 +++
 5 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/clang/docs/UsersManual.rst b/clang/docs/UsersManual.rst
index d0326f01d251e0..bd6b6966ef409f 100644
--- a/clang/docs/UsersManual.rst
+++ b/clang/docs/UsersManual.rst
@@ -1452,8 +1452,8 @@ floating point semantic models: precise (the default), 
strict, and fast.
   "fenv_access", "off", "on", "off"
   "rounding_mode", "tonearest", "dynamic", "tonearest"
   "contract", "on", "off", "fast"
-  "denormal_fp_math", "IEEE", "IEEE", "IEEE"
-  "denormal_fp32_math", "IEEE","IEEE", "IEEE"
+  "denormal_fp_math", "IEEE", "IEEE", "target-dependent"
+  "denormal_fp32_math", "IEEE","IEEE", "target-dependent"
   "support_math_errno", "on", "on", "off"
   "no_honor_nans", "off", "off", "on"
   "no_honor_infinities", "off", "off", "on"
diff --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index 341d6202a9ca3c..0476ba87d07b66 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -1319,11 +1319,17 @@ bool ToolChain::isFastMathRuntimeAvailable(const 
ArgList ,
 Arg *A =
   Args.getLastArg(options::OPT_ffast_math, options::OPT_fno_fast_math,
   options::OPT_funsafe_math_optimizations,
-  options::OPT_fno_unsafe_math_optimizations);
+  options::OPT_fno_unsafe_math_optimizations,
+  options::OPT_ffp_model_EQ);
 
 if (!A || A->getOption().getID() == options::OPT_fno_fast_math ||
 A->getOption().getID() == options::OPT_fno_unsafe_math_optimizations)
   Default = false;
+if (A && A->getOption().getID() == options::OPT_ffp_model_EQ) {
+  StringRef Model = A->getValue();
+  if (Model != "fast")
+Default = false;
+}
   }
 
   // Whatever decision came as a result of the above implicit settings, either
diff --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 651a2b5aac368b..1b1b8d6ee74801 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -2924,6 +2924,10 @@ static void RenderFloatingPointOptions(const ToolChain 
, const Driver ,
   if (Val.equals("fast")) {
 FPModel = Val;
 applyFastMath();
+// The target-specific getDefaultDenormalModeForType handler should
+// account for -ffp-model=fast and choose its behavior
+DenormalFPMath = DefaultDenormalFPMath;
+DenormalFP32Math = DefaultDenormalFP32Math;
   } else if (Val.equals("precise")) {
 optID = options::OPT_ffp_contract;
 FPModel = Val;
diff --git a/clang/test/Driver/linux-ld.c b/clang/test/Driver/linux-ld.c
index 958e682b6c3c11..db4abbbf874eae 100644
--- a/clang/test/Driver/linux-ld.c
+++ b/clang/test/Driver/linux-ld.c
@@ -1417,6 +1417,9 @@
 // RUN: %clang --target=x86_64-unknown-linux -no-pie -### %s 
-funsafe-math-optimizations\
 // RUN:--sysroot=%S/Inputs/basic_linux_tree 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-CRTFASTMATH %s
+// RUN: %clang --target=x86_64-unknown-linux -no-pie -### %s -ffp-model=fast \
+// RUN:--sysroot=%S/Inputs/basic_linux_tree 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-CRTFASTMATH %s
 // RUN: %clang --target=x86_64-unknown-linux -no-pie -### %s -Ofast\
 // RUN:--sysroot=%S/Inputs/basic_linux_tree 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-CRTFASTMATH %s
diff --git a/clang/test/Driver/solaris-ld.c b/clang/test/Driver/solaris-ld.c
index 6d74389e89222c..ce0728d392bf23 100644
--- a/clang/test/Driver/solaris-ld.c
+++ 

[clang] [clang][CodeGen] Omit pre-opt link when post-opt is link requested (PR #85672)

2024-04-29 Thread Jacob Lambert via cfe-commits


@@ -28,12 +28,8 @@ PreservedAnalyses LinkInModulesPass::run(Module , 
ModuleAnalysisManager ) {
   if (!BC)
 return PreservedAnalyses::all();
 
-  // Re-load bitcode modules from files
-  if (BC->ReloadModules())
-report_fatal_error("Bitcode module re-loading failed, aborted!");
-
   if (BC->LinkInModules(, ShouldLinkFiles))
-report_fatal_error("Bitcode module re-linking failed, aborted!");
+report_fatal_error("Bitcode module postopt linking failed, aborted!");
 
-  return PreservedAnalyses::all();

lamb-j wrote:

This should fix the issue:

LLVM ERROR: Function @_Z6sincosfPU3AS5f changed by LinkInModulesPass without 
invalidating analyses

https://github.com/llvm/llvm-project/pull/85672
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [OpenMP][TR12] change property of map-type modifier. (PR #90499)

2024-04-29 Thread Alexey Bataev via cfe-commits

https://github.com/alexey-bataev edited 
https://github.com/llvm/llvm-project/pull/90499
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [OpenMP][TR12] change property of map-type modifier. (PR #90499)

2024-04-29 Thread Alexey Bataev via cfe-commits


@@ -113,7 +114,7 @@ struct SA {
 #pragma omp target map(b[true:true])
 {}
 
-#pragma omp target map(: c,f) // expected-error {{missing map type}}
+#pragma omp target map(: c,f) // lt60-error {{missing map type}}

alexey-bataev wrote:

So, does hanging `:` is allowed?

https://github.com/llvm/llvm-project/pull/90499
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [x86] Add tan intrinsic part 4 (PR #90503)

2024-04-29 Thread Thorsten Schütt via cfe-commits

tschuett wrote:

Nit: the `declare` is not necessary anymore. You touched the IRTranslator 
without a test at, e.g., 
https://github.com/llvm/llvm-project/blob/main/llvm/test/CodeGen/AArch64/GlobalISel/arm64-irtranslator.ll

https://github.com/llvm/llvm-project/pull/90503
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [OpenMP][TR12] change property of map-type modifier. (PR #90499)

2024-04-29 Thread via cfe-commits


@@ -113,7 +114,7 @@ struct SA {
 #pragma omp target map(b[true:true])
 {}
 
-#pragma omp target map(: c,f) // expected-error {{missing map type}}
+#pragma omp target map(: c,f) // lt60-error {{missing map type}}

jyu2-git wrote:

In OMP60, the map-type can be omitted.  Will be default tofrom.

https://github.com/llvm/llvm-project/pull/90499
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [compiler-rt] [libc] [libclc] [libcxxabi] [lld] [lldb] [llvm] [mlir] llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp:3804: lacking () for c… (PR #90391)

2024-04-29 Thread Louis Dionne via cfe-commits

https://github.com/ldionne approved this pull request.

The libc++abi changes look fine to me.

https://github.com/llvm/llvm-project/pull/90391
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Attributes] Support Attributes being declared as supporting an experimental late parsing mode "extension" (PR #88596)

2024-04-29 Thread Erich Keane via cfe-commits

https://github.com/erichkeane approved this pull request.

This looks fine enough to me. Aaron is away this week, so you can either let 
him review this when he gets back, or just merge this and let him make comments 
on followups/on the commit when he gets back.

https://github.com/llvm/llvm-project/pull/88596
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Attributes] Support Attributes being declared as supporting an experimental late parsing mode "extension" (PR #88596)

2024-04-29 Thread Dan Liew via cfe-commits

delcypher wrote:

@AaronBallman @erichkeane Ping. Is this ready to land?

https://github.com/llvm/llvm-project/pull/88596
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [DXIL] Add tan intrinsic part 2 (PR #90277)

2024-04-29 Thread Helena Kotas via cfe-commits

https://github.com/hekota approved this pull request.

LGTM!

https://github.com/llvm/llvm-project/pull/90277
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [clang][hlsl] Add tan intrinsic part 1 (PR #90276)

2024-04-29 Thread Helena Kotas via cfe-commits

https://github.com/hekota approved this pull request.

LGTM!

https://github.com/llvm/llvm-project/pull/90276
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang][Sema] Earlier type checking for builtin unary operators (PR #90500)

2024-04-29 Thread Erich Keane via cfe-commits

https://github.com/erichkeane approved this pull request.

This needs a release note, likely in the 'potentially breaking changes'.  
Projects are filled with code that is not ever instantiated, and Clang's 
aggressive instantiation can be a problem.

Else, LGTM.

https://github.com/llvm/llvm-project/pull/90500
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang] Fall back to DW_TAG_typedef for instantiation dependent template aliases (PR #90032)

2024-04-29 Thread David Blaikie via cfe-commits

dwblaikie wrote:

Comment in the code should probably mention this as a FIXME and include a 
reference to the issue?

Also, there's another bug here - the DW_TAG_typedef is in the CU scope, instead 
of the struct scope. But if the struct is a non-template, the typedef is in the 
struct scope as it should be, not the CU scope... 

https://github.com/llvm/llvm-project/pull/90032
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] Implement resource binding type prefix mismatch errors (PR #87578)

2024-04-29 Thread Justin Bogner via cfe-commits


@@ -7334,6 +7334,92 @@ static void handleHLSLShaderAttr(Sema , Decl *D, const 
ParsedAttr ) {
 D->addAttr(NewAttr);
 }
 
+static void DiagnoseHLSLResourceRegType(Sema , SourceLocation ,
+Decl *D, StringRef ) {
+  // Samplers, UAVs, and SRVs are VarDecl types
+  VarDecl *SamplerUAVOrSRV = dyn_cast(D);
+  // Cbuffers and Tbuffers are HLSLBufferDecl types
+  HLSLBufferDecl *CBufferOrTBuffer = dyn_cast(D);
+  if (!SamplerUAVOrSRV && !CBufferOrTBuffer)
+return;
+
+  llvm::hlsl::ResourceClass DeclResourceClass;
+  StringRef VarTy = "";
+  if (SamplerUAVOrSRV) {
+const Type *Ty = 
SamplerUAVOrSRV->getType()->getPointeeOrArrayElementType();
+if (!Ty)
+  llvm_unreachable("Resource class must have an element type.");
+
+if (const BuiltinType *BTy = dyn_cast(Ty)) {
+  QualType QT = SamplerUAVOrSRV->getType();
+  PrintingPolicy PP = S.getPrintingPolicy();
+  std::string typestr = QualType::getAsString(QT.split(), PP);
+
+  if (Slot[0] != 't')
+S.Diag(ArgLoc,
+   diag::err_hlsl_mismatching_register_builtin_type_and_name)
+<< Slot.substr(0, 1) << typestr << "'t'";
+  return;
+}
+
+const CXXRecordDecl *TheRecordDecl = Ty->getAsCXXRecordDecl();
+if (!TheRecordDecl)
+  llvm_unreachable(
+  "Resource class should have a resource type declaration.");
+
+if (auto TDecl = dyn_cast(TheRecordDecl))
+  TheRecordDecl = TDecl->getSpecializedTemplate()->getTemplatedDecl();
+TheRecordDecl = TheRecordDecl->getCanonicalDecl();
+const auto *Attr = TheRecordDecl->getAttr();
+if (!Attr)
+  llvm_unreachable("Resource class should have a resource attribute.");
+
+DeclResourceClass = Attr->getResourceClass();
+VarTy = TheRecordDecl->getName();
+  } else {
+DeclResourceClass = llvm::hlsl::ResourceClass::CBuffer;
+  }
+  switch (DeclResourceClass) {
+  case llvm::hlsl::ResourceClass::SRV: {
+if (Slot[0] == 't')
+  return;
+break;
+  }
+  case llvm::hlsl::ResourceClass::UAV: {
+if (Slot[0] == 'u')
+  return;
+break;
+  }
+  case llvm::hlsl::ResourceClass::CBuffer: {
+// could be CBuffer or TBuffer
+if (CBufferOrTBuffer->isCBuffer()) {
+  VarTy = "cbuffer";
+  if (Slot[0] == 'b')
+return;

bogner wrote:

This will likely crash once we add the 
[ConstantBuffer](https://learn.microsoft.com/en-us/windows/win32/direct3d12/resource-binding-in-hlsl#constant-buffers)
 template syntax, since we'll be able to have:
```hlsl
struct S {
  float4 g_MaxThreadIter;
  float4 g_Window;
};
ConstantBuffer cb0 : register(b0);
```

We should at the very least put a TODO here, but maybe if we can drive 
cbuffer/tbuffer from attributes we could just do the right thing already?

https://github.com/llvm/llvm-project/pull/87578
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] Implement resource binding type prefix mismatch errors (PR #87578)

2024-04-29 Thread Justin Bogner via cfe-commits


@@ -7334,6 +7334,92 @@ static void handleHLSLShaderAttr(Sema , Decl *D, const 
ParsedAttr ) {
 D->addAttr(NewAttr);
 }
 
+static void DiagnoseHLSLResourceRegType(Sema , SourceLocation ,
+Decl *D, StringRef ) {
+  // Samplers, UAVs, and SRVs are VarDecl types
+  VarDecl *SamplerUAVOrSRV = dyn_cast(D);
+  // Cbuffers and Tbuffers are HLSLBufferDecl types
+  HLSLBufferDecl *CBufferOrTBuffer = dyn_cast(D);
+  if (!SamplerUAVOrSRV && !CBufferOrTBuffer)
+return;
+
+  llvm::hlsl::ResourceClass DeclResourceClass;
+  StringRef VarTy = "";
+  if (SamplerUAVOrSRV) {
+const Type *Ty = 
SamplerUAVOrSRV->getType()->getPointeeOrArrayElementType();
+if (!Ty)
+  llvm_unreachable("Resource class must have an element type.");
+
+if (const BuiltinType *BTy = dyn_cast(Ty)) {
+  QualType QT = SamplerUAVOrSRV->getType();
+  PrintingPolicy PP = S.getPrintingPolicy();
+  std::string typestr = QualType::getAsString(QT.split(), PP);
+
+  if (Slot[0] != 't')
+S.Diag(ArgLoc,
+   diag::err_hlsl_mismatching_register_builtin_type_and_name)
+<< Slot.substr(0, 1) << typestr << "'t'";
+  return;
+}
+
+const CXXRecordDecl *TheRecordDecl = Ty->getAsCXXRecordDecl();
+if (!TheRecordDecl)
+  llvm_unreachable(
+  "Resource class should have a resource type declaration.");
+
+if (auto TDecl = dyn_cast(TheRecordDecl))
+  TheRecordDecl = TDecl->getSpecializedTemplate()->getTemplatedDecl();
+TheRecordDecl = TheRecordDecl->getCanonicalDecl();
+const auto *Attr = TheRecordDecl->getAttr();
+if (!Attr)
+  llvm_unreachable("Resource class should have a resource attribute.");
+
+DeclResourceClass = Attr->getResourceClass();
+VarTy = TheRecordDecl->getName();
+  } else {
+DeclResourceClass = llvm::hlsl::ResourceClass::CBuffer;
+  }
+  switch (DeclResourceClass) {
+  case llvm::hlsl::ResourceClass::SRV: {
+if (Slot[0] == 't')
+  return;
+break;
+  }
+  case llvm::hlsl::ResourceClass::UAV: {
+if (Slot[0] == 'u')
+  return;
+break;
+  }
+  case llvm::hlsl::ResourceClass::CBuffer: {
+// could be CBuffer or TBuffer
+if (CBufferOrTBuffer->isCBuffer()) {
+  VarTy = "cbuffer";
+  if (Slot[0] == 'b')
+return;
+} else {
+  VarTy = "tbuffer";
+  // This isn't an SRV, but we need the diagnostic to emit
+  // the same binding prefix that would be expected on an SRV.
+  DeclResourceClass = llvm::hlsl::ResourceClass::SRV;

bogner wrote:

This comment isn't exactly correct. A `tbuffer` *is* an SRV, we simply don't 
have a `ClassDecl` with the annotation to get that information from. I wonder 
if it would be better to put attributes on `HLSLBufferDecl` (perhaps in 
`SemaHLSL::ActOnStartBuffer`) so that we can drive the two ways of getting here 
in the same way.

https://github.com/llvm/llvm-project/pull/87578
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [x86] Add tan intrinsic part 4 (PR #90503)

2024-04-29 Thread via cfe-commits

llvmbot wrote:



@llvm/pr-subscribers-llvm-globalisel

@llvm/pr-subscribers-llvm-analysis

Author: Farzon Lotfi (farzonl)


Changes

This change is an implementation of #87367's investigation on 
supporting IEEE math operations as intrinsics.
Which was discussed in this RFC:
https://discourse.llvm.org/t/rfc-all-the-math-intrinsics/78294

If you want an overarching view of how this will all connect see:
https://github.com/llvm/llvm-project/pull/90088

Much of this change was following how G_FSIN and G_FCOS were used.

The X86 Lowering and test cases of this pr should be credited to 
https://github.com/junaire
https://reviews.llvm.org/D146905

Changes:
-  `llvm/docs/GlobalISel/GenericOpcode.rst` - Document the `G_FTAN` opcode 
-  `llvm/docs/LangRef.rst` - Document the tan intrinsic
-  `llvm/include/llvm/Analysis/VecFuncs.def` - Associate the tan intrinsic as a 
vector function similar to the tanf libcall.
-  `llvm/include/llvm/CodeGen/BasicTTIImpl.h` - Map the tan intrinsic to 
`ISD::FTAN`
-  `llvm/include/llvm/CodeGen/ISDOpcodes.h` - Define ISD opcodes for `FTAN` and 
`STRICT_FTAN`
-  `llvm/include/llvm/IR/Intrinsics.td` - Create the tan intrinsic
-  `llvm/include/llvm/IR/RuntimeLibcalls.def` - Define tan libcall mappings
-  `llvm/include/llvm/Target/GenericOpcodes.td` - Define the `G_FTAN` Opcode
-  `llvm/include/llvm/Support/TargetOpcodes.def` - Create a `G_FTAN` Opcode 
handler
-  `llvm/include/llvm/Target/GlobalISel/SelectionDAGCompat.td`  - Map `G_FTAN` 
to `ftan`
-  `llvm/include/llvm/Target/TargetSelectionDAG.td` - Define `ftan`, 
`strict_ftan`,  and `any_ftan` and map them to the ISD opcodes for `FTAN` and 
`STRICT_FTAN`
-  `llvm/lib/Analysis/VectorUtils.cpp` - Associate the tan intrinsic as a 
vector intrinsic
-  `llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp` Map the tan intrinsic to  
`G_FTAN` Opcode
-  `llvm/lib/CodeGen/GlobalISel/LegalizerHelper.cpp` - Add `G_FTAN` to the list 
of  floating point math operations also associate `G_FTAN` with the `TAN_F` 
runtime lib.
- `llvm/lib/CodeGen/GlobalISel/Utils.cpp` - More floating point math operation 
common behaviors.
-  llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp - List the function expansion 
operations for `FTAN` and `STRICT_FTAN`. Also define both opcodes in 
`PromoteNode`.
- `llvm/lib/CodeGen/SelectionDAG/LegalizeFloatTypes.cpp` - More `FTAN` and 
`STRICT_FTAN` handling in the legalizer
-  `llvm/lib/CodeGen/SelectionDAG/LegalizeTypes.h` - Define 
`SoftenFloatRes_FTAN` and `ExpandFloatRes_FTAN`.
- `llvm/lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp` - Define `FTAN` as a 
legal vector operation.
-  `llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp` - Define `FTAN` as a 
legal vector operation.
-  `llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp` - define tan as an 
intrinsic that doesn't return NaN.
-  `llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp` Map `LibFunc_tan`, 
`LibFunc_tanf`, and `LibFunc_tanl` to `ISD::FTAN`. Map `Intrinsic::tan` to 
`ISD::FTAN` and add selection dag handling for `Intrinsic::tan`.
-  `llvm/lib/CodeGen/SelectionDAG/SelectionDAGDumper.cpp` - Define  `ftan` and 
`strict_ftan` names for the equivalent ISD  opcodes.
- `llvm/lib/CodeGen/TargetLoweringBase.cpp` -Define a Tan128 libcall and 
ISD::FTAN as a target lowering action.
-  `llvm/lib/Target/X86/X86ISelLowering.cpp` - Add x86_64 lowering for tan 
intrinsic


---

Patch is 40.09 KiB, truncated to 20.00 KiB below, full version: 
https://github.com/llvm/llvm-project/pull/90503.diff


28 Files Affected:

- (modified) llvm/docs/GlobalISel/GenericOpcode.rst (+2-2) 
- (modified) llvm/docs/LangRef.rst (+37) 
- (modified) llvm/include/llvm/Analysis/VecFuncs.def (+1) 
- (modified) llvm/include/llvm/CodeGen/BasicTTIImpl.h (+3) 
- (modified) llvm/include/llvm/CodeGen/ISDOpcodes.h (+2) 
- (modified) llvm/include/llvm/IR/Intrinsics.td (+1) 
- (modified) llvm/include/llvm/IR/RuntimeLibcalls.def (+5) 
- (modified) llvm/include/llvm/Support/TargetOpcodes.def (+3) 
- (modified) llvm/include/llvm/Target/GenericOpcodes.td (+7) 
- (modified) llvm/include/llvm/Target/GlobalISel/SelectionDAGCompat.td (+1) 
- (modified) llvm/include/llvm/Target/TargetSelectionDAG.td (+6) 
- (modified) llvm/lib/Analysis/VectorUtils.cpp (+1) 
- (modified) llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp (+2) 
- (modified) llvm/lib/CodeGen/GlobalISel/LegalizerHelper.cpp (+5) 
- (modified) llvm/lib/CodeGen/GlobalISel/Utils.cpp (+2) 
- (modified) llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp (+7) 
- (modified) llvm/lib/CodeGen/SelectionDAG/LegalizeFloatTypes.cpp (+23) 
- (modified) llvm/lib/CodeGen/SelectionDAG/LegalizeTypes.h (+2) 
- (modified) llvm/lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp (+1) 
- (modified) llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp (+3) 
- (modified) llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp (+1) 
- (modified) llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp (+10) 
- (modified) llvm/lib/CodeGen/SelectionDAG/SelectionDAGDumper.cpp (+2) 
- (modified) 

[clang] [llvm] [x86] Add tan intrinsic part 4 (PR #90503)

2024-04-29 Thread Farzon Lotfi via cfe-commits

https://github.com/farzonl ready_for_review 
https://github.com/llvm/llvm-project/pull/90503
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [HLSL] Shore up floating point conversions (PR #90222)

2024-04-29 Thread Chris B via cfe-commits

https://github.com/llvm-beanz updated 
https://github.com/llvm/llvm-project/pull/90222

>From a173605b6043739e69f89d3a559a4f6a68d5fc0a Mon Sep 17 00:00:00 2001
From: Chris Bieneman 
Date: Thu, 25 Apr 2024 15:47:22 -0500
Subject: [PATCH] [HLSL] Shore up floating point conversions

This PR fixes bugs in HLSL floating conversions. HLSL always has
`half`, `float` and `double` types, which promote in the order:

`half`->`float`->`double`

and convert in the order:

`double`->`float`->`half`

As with other conversions in C++, promotions are preferred over
conversions.

We do have floating conversions documented in the draft language
specification (https://microsoft.github.io/hlsl-specs/specs/hlsl.pdf
[Conv.rank.float]) although the exact language is still in flux
(https://github.com/microsoft/hlsl-specs/pull/206).

Resolves #81047
---
 clang/lib/Sema/SemaOverload.cpp   |  43 +++-
 .../SemaHLSL/ScalarOverloadResolution.hlsl| 229 ++
 .../VectorElementOverloadResolution.hlsl  | 228 +
 3 files changed, 499 insertions(+), 1 deletion(-)
 create mode 100644 clang/test/SemaHLSL/ScalarOverloadResolution.hlsl
 create mode 100644 clang/test/SemaHLSL/VectorElementOverloadResolution.hlsl

diff --git a/clang/lib/Sema/SemaOverload.cpp b/clang/lib/Sema/SemaOverload.cpp
index 04cd9e78739d20..a416df2e97c439 100644
--- a/clang/lib/Sema/SemaOverload.cpp
+++ b/clang/lib/Sema/SemaOverload.cpp
@@ -2587,7 +2587,8 @@ bool Sema::IsIntegralPromotion(Expr *From, QualType 
FromType, QualType ToType) {
 
   // In HLSL an rvalue of integral type can be promoted to an rvalue of a 
larger
   // integral type.
-  if (Context.getLangOpts().HLSL)
+  if (Context.getLangOpts().HLSL && FromType->isIntegerType() &&
+  ToType->isIntegerType())
 return Context.getTypeSize(FromType) < Context.getTypeSize(ToType);
 
   return false;
@@ -2616,6 +2617,13 @@ bool Sema::IsFloatingPointPromotion(QualType FromType, 
QualType ToType) {
ToBuiltin->getKind() == BuiltinType::Ibm128))
 return true;
 
+  // In HLSL, `half` promotes to `float` or `double`, regardless of whether
+  // or not native half types are enabled.
+  if (getLangOpts().HLSL && FromBuiltin->getKind() == BuiltinType::Half &&
+  (ToBuiltin->getKind() == BuiltinType::Float ||
+   ToBuiltin->getKind() == BuiltinType::Double))
+return true;
+
   // Half can be promoted to float.
   if (!getLangOpts().NativeHalfType &&
FromBuiltin->getKind() == BuiltinType::Half &&
@@ -4393,6 +4401,24 @@ getFixedEnumPromtion(Sema , const 
StandardConversionSequence ) {
   return FixedEnumPromotion::ToPromotedUnderlyingType;
 }
 
+static ImplicitConversionSequence::CompareKind
+HLSLCompareFloatingRank(QualType LHS, QualType RHS) {
+  assert(LHS->isVectorType() == RHS->isVectorType() &&
+ "Either both elements should be vectors or neither should.");
+  if (const auto *VT = LHS->getAs())
+LHS = VT->getElementType();
+
+  if (const auto *VT = RHS->getAs())
+RHS = VT->getElementType();
+
+  const auto L = LHS->getAs()->getKind();
+  const auto R = RHS->getAs()->getKind();
+  if (L == R)
+return ImplicitConversionSequence::Indistinguishable;
+  return L < R ? ImplicitConversionSequence::Better
+   : ImplicitConversionSequence::Worse;
+}
+
 /// CompareStandardConversionSequences - Compare two standard
 /// conversion sequences to determine whether one is better than the
 /// other or if they are indistinguishable (C++ 13.3.3.2p3).
@@ -4634,6 +4660,21 @@ CompareStandardConversionSequences(Sema , 
SourceLocation Loc,
  : ImplicitConversionSequence::Worse;
   }
 
+  if (S.getLangOpts().HLSL) {
+// On a promotion we prefer the lower rank to disambiguate.
+if ((SCS1.Second == ICK_Floating_Promotion &&
+ SCS2.Second == ICK_Floating_Promotion) ||
+(SCS1.Element == ICK_Floating_Promotion &&
+ SCS2.Element == ICK_Floating_Promotion))
+  return HLSLCompareFloatingRank(SCS1.getToType(2), SCS2.getToType(2));
+// On a conversion we prefer the higher rank to disambiguate.
+if ((SCS1.Second == ICK_Floating_Conversion &&
+ SCS2.Second == ICK_Floating_Conversion) ||
+(SCS1.Element == ICK_Floating_Conversion &&
+ SCS2.Element == ICK_Floating_Conversion))
+  return HLSLCompareFloatingRank(SCS2.getToType(2), SCS1.getToType(2));
+  }
+
   return ImplicitConversionSequence::Indistinguishable;
 }
 
diff --git a/clang/test/SemaHLSL/ScalarOverloadResolution.hlsl 
b/clang/test/SemaHLSL/ScalarOverloadResolution.hlsl
new file mode 100644
index 00..13758995ec6a1e
--- /dev/null
+++ b/clang/test/SemaHLSL/ScalarOverloadResolution.hlsl
@@ -0,0 +1,229 @@
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.3-library -fnative-half-type 
-finclude-default-header -Wconversion -verify -o - %s
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.3-library -fnative-half-type 
-finclude-default-header 

[clang] [llvm] [SPIRV] Add tan intrinsic part 3 (PR #90278)

2024-04-29 Thread via cfe-commits

llvmbot wrote:



@llvm/pr-subscribers-backend-aarch64

@llvm/pr-subscribers-backend-spir-v

Author: Farzon Lotfi (farzonl)


Changes

This change is an implementation of #87367's investigation on 
supporting IEEE math operations as intrinsics.
Which was discussed in this RFC:
https://discourse.llvm.org/t/rfc-all-the-math-intrinsics/78294

If you want an overarching view of how this will all connect see:
https://github.com/llvm/llvm-project/pull/90088
Changes:
-  `llvm/docs/GlobalISel/GenericOpcode.rst` - Document the `G_FTAN` opcode 
-  `llvm/include/llvm/IR/Intrinsics.td` - Create the tan intrinsic
-  `llvm/include/llvm/Support/TargetOpcodes.def` - Create a `G_FTAN` Opcode 
handler
-  `llvm/include/llvm/Target/GenericOpcodes.td` - Define the `G_FTAN` Opcode
-  `llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp` Map the tan intrinsic to  
`G_FTAN` Opcode
- `llvm/lib/Target/SPIRV/SPIRVInstructionSelector.cpp` - Map the `G_FTAN`  
opcode to the  GLSL 4.5 and openCL tan instructions.
-  `llvm/lib/Target/SPIRV/SPIRVLegalizerInfo.cpp` - Define `G_FTAN` as a legal 
spirv  target opcode.

---
Full diff: https://github.com/llvm/llvm-project/pull/90278.diff


9 Files Affected:

- (modified) llvm/docs/GlobalISel/GenericOpcode.rst (+2-2) 
- (modified) llvm/include/llvm/IR/Intrinsics.td (+1) 
- (modified) llvm/include/llvm/Support/TargetOpcodes.def (+3) 
- (modified) llvm/include/llvm/Target/GenericOpcodes.td (+7) 
- (modified) llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp (+2) 
- (modified) llvm/lib/Target/SPIRV/SPIRVInstructionSelector.cpp (+2) 
- (modified) llvm/lib/Target/SPIRV/SPIRVLegalizerInfo.cpp (+1) 
- (modified) llvm/test/CodeGen/AArch64/GlobalISel/legalizer-info-validation.mir 
(+3) 
- (added) llvm/test/CodeGen/SPIRV/hlsl-intrinsics/tan.ll (+45) 


``diff
diff --git a/llvm/docs/GlobalISel/GenericOpcode.rst 
b/llvm/docs/GlobalISel/GenericOpcode.rst
index 492d30280f4776..52dc039df7779e 100644
--- a/llvm/docs/GlobalISel/GenericOpcode.rst
+++ b/llvm/docs/GlobalISel/GenericOpcode.rst
@@ -592,8 +592,8 @@ G_FLOG, G_FLOG2, G_FLOG10
 
 Calculate the base-e, base-2, or base-10 respectively.
 
-G_FCEIL, G_FCOS, G_FSIN, G_FSQRT, G_FFLOOR, G_FRINT, G_FNEARBYINT
-^
+G_FCEIL, G_FCOS, G_FSIN, G_FTAN, G_FSQRT, G_FFLOOR, G_FRINT, G_FNEARBYINT
+^
 
 These correspond to the standard C functions of the same name.
 
diff --git a/llvm/include/llvm/IR/Intrinsics.td 
b/llvm/include/llvm/IR/Intrinsics.td
index a14e9dedef8c9e..bf0ca1687a34d4 100644
--- a/llvm/include/llvm/IR/Intrinsics.td
+++ b/llvm/include/llvm/IR/Intrinsics.td
@@ -1025,6 +1025,7 @@ let IntrProperties = [IntrNoMem, IntrSpeculatable, 
IntrWillReturn] in {
   def int_powi : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>, 
llvm_anyint_ty]>;
   def int_sin  : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>]>;
   def int_cos  : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>]>;
+  def int_tan  : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>]>;
   def int_pow  : DefaultAttrsIntrinsic<[llvm_anyfloat_ty],
[LLVMMatchType<0>, LLVMMatchType<0>]>;
   def int_log  : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>]>;
diff --git a/llvm/include/llvm/Support/TargetOpcodes.def 
b/llvm/include/llvm/Support/TargetOpcodes.def
index cb98f96af522f7..559a588c251482 100644
--- a/llvm/include/llvm/Support/TargetOpcodes.def
+++ b/llvm/include/llvm/Support/TargetOpcodes.def
@@ -781,6 +781,9 @@ HANDLE_TARGET_OPCODE(G_FCOS)
 /// Floating point sine.
 HANDLE_TARGET_OPCODE(G_FSIN)
 
+/// Floating point Tangent.
+HANDLE_TARGET_OPCODE(G_FTAN)
+
 /// Floating point square root.
 HANDLE_TARGET_OPCODE(G_FSQRT)
 
diff --git a/llvm/include/llvm/Target/GenericOpcodes.td 
b/llvm/include/llvm/Target/GenericOpcodes.td
index 8380d2738d164b..c40498e5542154 100644
--- a/llvm/include/llvm/Target/GenericOpcodes.td
+++ b/llvm/include/llvm/Target/GenericOpcodes.td
@@ -988,6 +988,13 @@ def G_FSIN : GenericInstruction {
   let hasSideEffects = false;
 }
 
+// Floating point tangent of a value.
+def G_FTAN : GenericInstruction {
+  let OutOperandList = (outs type0:$dst);
+  let InOperandList = (ins type0:$src1);
+  let hasSideEffects = false;
+}
+
 // Floating point square root of a value.
 // This returns NaN for negative nonzero values.
 // NOTE: Unlike libm sqrt(), this never sets errno. In all other respects it's
diff --git a/llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp 
b/llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp
index d7b0c9aa166735..3dadab8501c900 100644
--- a/llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp
+++ b/llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp
@@ -1945,6 +1945,8 @@ unsigned 
IRTranslator::getSimpleIntrinsicOpcode(Intrinsic::ID ID) {
   return TargetOpcode::G_FSIN;
 case Intrinsic::sqrt:
   return TargetOpcode::G_FSQRT;
+case Intrinsic::tan:
+  

[clang] [llvm] [DXIL] Add tan intrinsic part 2 (PR #90277)

2024-04-29 Thread via cfe-commits

llvmbot wrote:




@llvm/pr-subscribers-llvm-ir

Author: Farzon Lotfi (farzonl)


Changes

This change is an implementation of #87367's investigation on 
supporting IEEE math operations as intrinsics.
Which was discussed in this RFC:
https://discourse.llvm.org/t/rfc-all-the-math-intrinsics/78294

If you want an overarching view of how this will all connect see:
https://github.com/llvm/llvm-project/pull/90088

Changes:
-  `llvm/include/llvm/IR/Intrinsics.td` - Create the tan intrinsic
- `llvm/lib/Target/DirectX/DXIL.td`  - Map `int_tan` (the tan intrinsic) to the 
equivalent DXIL Op.

---
Full diff: https://github.com/llvm/llvm-project/pull/90277.diff


4 Files Affected:

- (modified) llvm/include/llvm/IR/Intrinsics.td (+1) 
- (modified) llvm/lib/Target/DirectX/DXIL.td (+3) 
- (added) llvm/test/CodeGen/DirectX/tan.ll (+20) 
- (added) llvm/test/CodeGen/DirectX/tan_error.ll (+10) 


``diff
diff --git a/llvm/include/llvm/IR/Intrinsics.td 
b/llvm/include/llvm/IR/Intrinsics.td
index a14e9dedef8c9e..bf0ca1687a34d4 100644
--- a/llvm/include/llvm/IR/Intrinsics.td
+++ b/llvm/include/llvm/IR/Intrinsics.td
@@ -1025,6 +1025,7 @@ let IntrProperties = [IntrNoMem, IntrSpeculatable, 
IntrWillReturn] in {
   def int_powi : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>, 
llvm_anyint_ty]>;
   def int_sin  : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>]>;
   def int_cos  : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>]>;
+  def int_tan  : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>]>;
   def int_pow  : DefaultAttrsIntrinsic<[llvm_anyfloat_ty],
[LLVMMatchType<0>, LLVMMatchType<0>]>;
   def int_log  : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>]>;
diff --git a/llvm/lib/Target/DirectX/DXIL.td b/llvm/lib/Target/DirectX/DXIL.td
index cd388ed3e3191b..24a0c8524230c5 100644
--- a/llvm/lib/Target/DirectX/DXIL.td
+++ b/llvm/lib/Target/DirectX/DXIL.td
@@ -266,6 +266,9 @@ def Cos  : DXILOpMapping<12, unary, int_cos,
 def Sin  : DXILOpMapping<13, unary, int_sin,
  "Returns sine(theta) for theta in radians.",
  [llvm_halforfloat_ty, LLVMMatchType<0>]>;
+def Tan  : DXILOpMapping<14, unary, int_tan,
+ "Returns tangent(theta) for theta in radians.",
+ [llvm_halforfloat_ty, LLVMMatchType<0>]>;
 def Exp2 : DXILOpMapping<21, unary, int_exp2,
  "Returns the base 2 exponential, or 2**x, of the 
specified value."
  "exp2(x) = 2**x.",
diff --git a/llvm/test/CodeGen/DirectX/tan.ll b/llvm/test/CodeGen/DirectX/tan.ll
new file mode 100644
index 00..567ab02d40f918
--- /dev/null
+++ b/llvm/test/CodeGen/DirectX/tan.ll
@@ -0,0 +1,20 @@
+; RUN: opt -S -dxil-op-lower < %s | FileCheck %s
+
+; Make sure dxil operation function calls for tan are generated for float and 
half.
+
+define noundef float @tan_float(float noundef %a) #0 {
+entry:
+; CHECK:call float @dx.op.unary.f32(i32 14, float %{{.*}})
+  %elt.tan = call float @llvm.tan.f32(float %a)
+  ret float %elt.tan
+}
+
+define noundef half @tan_half(half noundef %a) #0 {
+entry:
+; CHECK:call half @dx.op.unary.f16(i32 14, half %{{.*}})
+  %elt.tan = call half @llvm.tan.f16(half %a)
+  ret half %elt.tan
+}
+
+declare half @llvm.tan.f16(half)
+declare float @llvm.tan.f32(float)
diff --git a/llvm/test/CodeGen/DirectX/tan_error.ll 
b/llvm/test/CodeGen/DirectX/tan_error.ll
new file mode 100644
index 00..c870c36f54925d
--- /dev/null
+++ b/llvm/test/CodeGen/DirectX/tan_error.ll
@@ -0,0 +1,10 @@
+; RUN: not opt -S -dxil-op-lower %s 2>&1 | FileCheck %s
+
+; DXIL operation tan does not support double overload type
+; CHECK: LLVM ERROR: Invalid Overload
+
+define noundef double @tan_double(double noundef %a) #0 {
+entry:
+  %1 = call double @llvm.tan.f64(double %a)
+  ret double %1
+}

``




https://github.com/llvm/llvm-project/pull/90277
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [SPIRV] Add tan intrinsic part 3 (PR #90278)

2024-04-29 Thread Farzon Lotfi via cfe-commits

https://github.com/farzonl ready_for_review 
https://github.com/llvm/llvm-project/pull/90278
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [clang][hlsl] Add tan intrinsic part 1 (PR #90276)

2024-04-29 Thread via cfe-commits

llvmbot wrote:




@llvm/pr-subscribers-backend-risc-v

Author: Farzon Lotfi (farzonl)


Changes

This change is an implementation of #87367's investigation on 
supporting IEEE math operations as intrinsics.
Which was discussed in this RFC:
https://discourse.llvm.org/t/rfc-all-the-math-intrinsics/78294

If you want an overarching view of how this will all connect see:
https://github.com/llvm/llvm-project/pull/90088

Changes:
- `clang/docs/LanguageExtensions.rst` - Document the new elementwise tan 
builtin.
-  `clang/include/clang/Basic/Builtins.td` - Implement the tan builtin.
-  `clang/lib/CodeGen/CGBuiltin.cpp` - invoke the tan intrinsic on uses of the 
builtin
-  `clang/lib/Headers/hlsl/hlsl_intrinsics.h` - Associate the tan builtin with 
the equivalent hlsl apis
-  `clang/lib/Sema/SemaChecking.cpp` - Add generic sema checks as well as HLSL 
specifc sema checks to the tan builtin
-  `llvm/include/llvm/IR/Intrinsics.td` - Create the tan intrinsic
-  `llvm/docs/LangRef.rst` - Document the tan intrinsic

---
Full diff: https://github.com/llvm/llvm-project/pull/90276.diff


15 Files Affected:

- (modified) clang/docs/LanguageExtensions.rst (+1) 
- (modified) clang/include/clang/Basic/Builtins.td (+6) 
- (modified) clang/lib/CodeGen/CGBuiltin.cpp (+3-1) 
- (modified) clang/lib/Headers/hlsl/hlsl_intrinsics.h (+23) 
- (modified) clang/lib/Sema/SemaChecking.cpp (+2) 
- (modified) clang/test/CodeGen/builtins-elementwise-math.c (+16) 
- (modified) clang/test/CodeGen/strictfp-elementwise-bulitins.cpp (+10) 
- (added) clang/test/CodeGenHLSL/builtins/tan.hlsl (+59) 
- (modified) clang/test/Sema/aarch64-sve-vector-trig-ops.c (+6) 
- (modified) clang/test/Sema/builtins-elementwise-math.c (+21) 
- (modified) clang/test/Sema/riscv-rvv-vector-trig-ops.c (+6) 
- (modified) clang/test/SemaCXX/builtins-elementwise-math.cpp (+7) 
- (modified) clang/test/SemaHLSL/BuiltIns/half-float-only-errors.hlsl (+1) 
- (modified) llvm/docs/LangRef.rst (+37) 
- (modified) llvm/include/llvm/IR/Intrinsics.td (+1) 


``diff
diff --git a/clang/docs/LanguageExtensions.rst 
b/clang/docs/LanguageExtensions.rst
index f18b946efd4bfa..aa61e239d6984c 100644
--- a/clang/docs/LanguageExtensions.rst
+++ b/clang/docs/LanguageExtensions.rst
@@ -656,6 +656,7 @@ Unless specified otherwise operation(±0) = ±0 and 
operation(±infinity) = ±in
  T __builtin_elementwise_ceil(T x)   return the smallest integral 
value greater than or equal to xfloating point types
  T __builtin_elementwise_sin(T x)return the sine of x interpreted 
as an angle in radians  floating point types
  T __builtin_elementwise_cos(T x)return the cosine of x 
interpreted as an angle in radiansfloating point types
+ T __builtin_elementwise_tan(T x)return the tangent of x 
interpreted as an angle in radians   floating point types
  T __builtin_elementwise_floor(T x)  return the largest integral value 
less than or equal to xfloating point types
  T __builtin_elementwise_log(T x)return the natural logarithm of x 
   floating point types
  T __builtin_elementwise_log2(T x)   return the base 2 logarithm of x  
   floating point types
diff --git a/clang/include/clang/Basic/Builtins.td 
b/clang/include/clang/Basic/Builtins.td
index de721a87b3341d..11982af3fa609b 100644
--- a/clang/include/clang/Basic/Builtins.td
+++ b/clang/include/clang/Basic/Builtins.td
@@ -1326,6 +1326,12 @@ def ElementwiseSqrt : Builtin {
   let Prototype = "void(...)";
 }
 
+def ElementwiseTan : Builtin {
+  let Spellings = ["__builtin_elementwise_tan"];
+  let Attributes = [NoThrow, Const, CustomTypeChecking];
+  let Prototype = "void(...)";
+}
+
 def ElementwiseTrunc : Builtin {
   let Spellings = ["__builtin_elementwise_trunc"];
   let Attributes = [NoThrow, Const, CustomTypeChecking];
diff --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index d08ab539148914..f941e93b0ced2b 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -3821,7 +3821,9 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl 
GD, unsigned BuiltinID,
   case Builtin::BI__builtin_elementwise_sin:
 return RValue::get(
 emitUnaryBuiltin(*this, E, llvm::Intrinsic::sin, "elt.sin"));
-
+  case Builtin::BI__builtin_elementwise_tan:
+return RValue::get(
+emitUnaryBuiltin(*this, E, llvm::Intrinsic::tan, "elt.tan"));
   case Builtin::BI__builtin_elementwise_trunc:
 return RValue::get(
 emitUnaryBuiltin(*this, E, llvm::Intrinsic::trunc, "elt.trunc"));
diff --git a/clang/lib/Headers/hlsl/hlsl_intrinsics.h 
b/clang/lib/Headers/hlsl/hlsl_intrinsics.h
index 06409c6fc77417..3390f0962f67d0 100644
--- a/clang/lib/Headers/hlsl/hlsl_intrinsics.h
+++ b/clang/lib/Headers/hlsl/hlsl_intrinsics.h
@@ -1441,6 +1441,29 @@ float3 sqrt(float3);
 _HLSL_BUILTIN_ALIAS(__builtin_elementwise_sqrt)
 float4 sqrt(float4);
 

[clang] [llvm] [clang][hlsl] Add tan intrinsic part 1 (PR #90276)

2024-04-29 Thread via cfe-commits

llvmbot wrote:



@llvm/pr-subscribers-llvm-ir

@llvm/pr-subscribers-backend-x86

Author: Farzon Lotfi (farzonl)


Changes

This change is an implementation of #87367's investigation on 
supporting IEEE math operations as intrinsics.
Which was discussed in this RFC:
https://discourse.llvm.org/t/rfc-all-the-math-intrinsics/78294

If you want an overarching view of how this will all connect see:
https://github.com/llvm/llvm-project/pull/90088

Changes:
- `clang/docs/LanguageExtensions.rst` - Document the new elementwise tan 
builtin.
-  `clang/include/clang/Basic/Builtins.td` - Implement the tan builtin.
-  `clang/lib/CodeGen/CGBuiltin.cpp` - invoke the tan intrinsic on uses of the 
builtin
-  `clang/lib/Headers/hlsl/hlsl_intrinsics.h` - Associate the tan builtin with 
the equivalent hlsl apis
-  `clang/lib/Sema/SemaChecking.cpp` - Add generic sema checks as well as HLSL 
specifc sema checks to the tan builtin
-  `llvm/include/llvm/IR/Intrinsics.td` - Create the tan intrinsic
-  `llvm/docs/LangRef.rst` - Document the tan intrinsic

---
Full diff: https://github.com/llvm/llvm-project/pull/90276.diff


15 Files Affected:

- (modified) clang/docs/LanguageExtensions.rst (+1) 
- (modified) clang/include/clang/Basic/Builtins.td (+6) 
- (modified) clang/lib/CodeGen/CGBuiltin.cpp (+3-1) 
- (modified) clang/lib/Headers/hlsl/hlsl_intrinsics.h (+23) 
- (modified) clang/lib/Sema/SemaChecking.cpp (+2) 
- (modified) clang/test/CodeGen/builtins-elementwise-math.c (+16) 
- (modified) clang/test/CodeGen/strictfp-elementwise-bulitins.cpp (+10) 
- (added) clang/test/CodeGenHLSL/builtins/tan.hlsl (+59) 
- (modified) clang/test/Sema/aarch64-sve-vector-trig-ops.c (+6) 
- (modified) clang/test/Sema/builtins-elementwise-math.c (+21) 
- (modified) clang/test/Sema/riscv-rvv-vector-trig-ops.c (+6) 
- (modified) clang/test/SemaCXX/builtins-elementwise-math.cpp (+7) 
- (modified) clang/test/SemaHLSL/BuiltIns/half-float-only-errors.hlsl (+1) 
- (modified) llvm/docs/LangRef.rst (+37) 
- (modified) llvm/include/llvm/IR/Intrinsics.td (+1) 


``diff
diff --git a/clang/docs/LanguageExtensions.rst 
b/clang/docs/LanguageExtensions.rst
index f18b946efd4bfa..aa61e239d6984c 100644
--- a/clang/docs/LanguageExtensions.rst
+++ b/clang/docs/LanguageExtensions.rst
@@ -656,6 +656,7 @@ Unless specified otherwise operation(±0) = ±0 and 
operation(±infinity) = ±in
  T __builtin_elementwise_ceil(T x)   return the smallest integral 
value greater than or equal to xfloating point types
  T __builtin_elementwise_sin(T x)return the sine of x interpreted 
as an angle in radians  floating point types
  T __builtin_elementwise_cos(T x)return the cosine of x 
interpreted as an angle in radiansfloating point types
+ T __builtin_elementwise_tan(T x)return the tangent of x 
interpreted as an angle in radians   floating point types
  T __builtin_elementwise_floor(T x)  return the largest integral value 
less than or equal to xfloating point types
  T __builtin_elementwise_log(T x)return the natural logarithm of x 
   floating point types
  T __builtin_elementwise_log2(T x)   return the base 2 logarithm of x  
   floating point types
diff --git a/clang/include/clang/Basic/Builtins.td 
b/clang/include/clang/Basic/Builtins.td
index de721a87b3341d..11982af3fa609b 100644
--- a/clang/include/clang/Basic/Builtins.td
+++ b/clang/include/clang/Basic/Builtins.td
@@ -1326,6 +1326,12 @@ def ElementwiseSqrt : Builtin {
   let Prototype = "void(...)";
 }
 
+def ElementwiseTan : Builtin {
+  let Spellings = ["__builtin_elementwise_tan"];
+  let Attributes = [NoThrow, Const, CustomTypeChecking];
+  let Prototype = "void(...)";
+}
+
 def ElementwiseTrunc : Builtin {
   let Spellings = ["__builtin_elementwise_trunc"];
   let Attributes = [NoThrow, Const, CustomTypeChecking];
diff --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index d08ab539148914..f941e93b0ced2b 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -3821,7 +3821,9 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl 
GD, unsigned BuiltinID,
   case Builtin::BI__builtin_elementwise_sin:
 return RValue::get(
 emitUnaryBuiltin(*this, E, llvm::Intrinsic::sin, "elt.sin"));
-
+  case Builtin::BI__builtin_elementwise_tan:
+return RValue::get(
+emitUnaryBuiltin(*this, E, llvm::Intrinsic::tan, "elt.tan"));
   case Builtin::BI__builtin_elementwise_trunc:
 return RValue::get(
 emitUnaryBuiltin(*this, E, llvm::Intrinsic::trunc, "elt.trunc"));
diff --git a/clang/lib/Headers/hlsl/hlsl_intrinsics.h 
b/clang/lib/Headers/hlsl/hlsl_intrinsics.h
index 06409c6fc77417..3390f0962f67d0 100644
--- a/clang/lib/Headers/hlsl/hlsl_intrinsics.h
+++ b/clang/lib/Headers/hlsl/hlsl_intrinsics.h
@@ -1441,6 +1441,29 @@ float3 sqrt(float3);
 _HLSL_BUILTIN_ALIAS(__builtin_elementwise_sqrt)

[clang] [llvm] [DXIL] Add tan intrinsic part 2 (PR #90277)

2024-04-29 Thread Farzon Lotfi via cfe-commits

https://github.com/farzonl ready_for_review 
https://github.com/llvm/llvm-project/pull/90277
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [clang][hlsl] Add tan intrinsic part 1 (PR #90276)

2024-04-29 Thread Farzon Lotfi via cfe-commits

https://github.com/farzonl ready_for_review 
https://github.com/llvm/llvm-project/pull/90276
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] Implement resource binding type prefix mismatch errors (PR #87578)

2024-04-29 Thread Xiang Li via cfe-commits


@@ -44,7 +44,7 @@ void foo2() {
   // expected-warning@+1 {{'register' attribute only applies to 
cbuffer/tbuffer and external global variables}}
   extern RWBuffer U2 : register(u5);
 }
-// FIXME: expect-error once fix 
https://github.com/llvm/llvm-project/issues/57886.
+// expected-error@+1 {{invalid register name prefix 'u' for 'float' (expected 
't')}}

python3kgae wrote:

Why a float expected 't'?

https://github.com/llvm/llvm-project/pull/87578
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [DXIL] Add tan intrinsic part 2 (PR #90277)

2024-04-29 Thread Farzon Lotfi via cfe-commits

https://github.com/farzonl edited 
https://github.com/llvm/llvm-project/pull/90277
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [clang][hlsl][dxil][spirv][x86] Add tan intrinsic (PR #90088)

2024-04-29 Thread Farzon Lotfi via cfe-commits

https://github.com/farzonl edited 
https://github.com/llvm/llvm-project/pull/90088
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang] Address post commit feedbacks in #89906 (PR #90495)

2024-04-29 Thread via cfe-commits

https://github.com/cor3ntin updated 
https://github.com/llvm/llvm-project/pull/90495

>From bc23126800d3977665f0e1393b65acfff742c028 Mon Sep 17 00:00:00 2001
From: Corentin Jabot 
Date: Mon, 29 Apr 2024 18:34:49 +0200
Subject: [PATCH] [Clang] Address post commit feedback in #89906

* Fix a leak
* Fix a maybe unused warning
* Fix incorrect cxx_status entry
---
 clang/include/clang/Sema/DeclSpec.h | 8 
 clang/lib/AST/DeclBase.cpp  | 2 +-
 clang/www/cxx_status.html   | 4 ++--
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/clang/include/clang/Sema/DeclSpec.h 
b/clang/include/clang/Sema/DeclSpec.h
index 760c7980be52bd..23bc780e04979d 100644
--- a/clang/include/clang/Sema/DeclSpec.h
+++ b/clang/include/clang/Sema/DeclSpec.h
@@ -1811,15 +1811,15 @@ class DecompositionDeclarator {
   : Bindings(nullptr), NumBindings(0), DeleteBindings(false) {}
   DecompositionDeclarator(const DecompositionDeclarator ) = delete;
   DecompositionDeclarator =(const DecompositionDeclarator ) = 
delete;
-  ~DecompositionDeclarator() {
-if (DeleteBindings)
-  delete[] Bindings;
-  }
+  ~DecompositionDeclarator() { clear(); }
 
   void clear() {
 LSquareLoc = RSquareLoc = SourceLocation();
 if (DeleteBindings)
   delete[] Bindings;
+else
+  llvm::for_each(llvm::MutableArrayRef(Bindings, NumBindings),
+ [](Binding ) { B.Attrs.reset(); });
 Bindings = nullptr;
 NumBindings = 0;
 DeleteBindings = false;
diff --git a/clang/lib/AST/DeclBase.cpp b/clang/lib/AST/DeclBase.cpp
index f341c74cf86e37..03e1055251c24f 100644
--- a/clang/lib/AST/DeclBase.cpp
+++ b/clang/lib/AST/DeclBase.cpp
@@ -1115,7 +1115,7 @@ int64_t Decl::getID() const {
 
 const FunctionType *Decl::getFunctionType(bool BlocksToo) const {
   QualType Ty;
-  if (const auto *D = dyn_cast(this))
+  if (isa(this))
 return nullptr;
   else if (const auto *D = dyn_cast(this))
 Ty = D->getType();
diff --git a/clang/www/cxx_status.html b/clang/www/cxx_status.html
index d58c35b72c22bb..0996abc2405857 100755
--- a/clang/www/cxx_status.html
+++ b/clang/www/cxx_status.html
@@ -177,7 +177,7 @@ C++2c implementation status
  
   Attributes for Structured Bindings
   https://wg21.link/P0609R3;>P0609R3
-  No
+  Clang 19
  
  
   Module Declarations Shouldn’t be Macros
@@ -187,7 +187,7 @@ C++2c implementation status
  
   Trivial infinite loops are not Undefined Behavior
   https://wg21.link/P2809R3;>P2809R3 (DR)
-  Clang 19
+  No
  
  
   Erroneous behaviour for uninitialized reads

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [compiler-rt] [libc] [libclc] [libcxxabi] [lld] [lldb] [llvm] [mlir] llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp:3804: lacking () for c… (PR #90391)

2024-04-29 Thread Alex Langford via cfe-commits

bulbazord wrote:

> > Please update the PR subject as its a lot more than just X86AsmParser.cpp
> 
> Hi @RKSimon
> 
> All the issues mentioned are fixed. The title of the PR is misleading. The 
> title is the same as the issue (#85868) it corresponds to. Got a look to 
> other PR's and I thought that this is the usual naming convention. Please 
> refer to the 
> [commit](https://github.com/llvm/llvm-project/pull/90391/commits/54c6c6b7d71f5ff293412f5f91e9f880480284f8)
>  and you will see all the modified files.

Commit titles should accurately reflect a change. Your change modifies more 
than just X86AsmParser.cpp, so reading the commit title alone might lead one to 
believe that's all that changed. But it's not, you changed many things across 
the code base (even if the changes are all of the same kind). A more accurate 
title might be something like: `Add clarifying parenthesis around non-trivial 
conditions in ternary expressions`.

https://github.com/llvm/llvm-project/pull/90391
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [x86] Add tan intrinsic part 4 (PR #90503)

2024-04-29 Thread Farzon Lotfi via cfe-commits

https://github.com/farzonl created 
https://github.com/llvm/llvm-project/pull/90503

This change is an implementation of #87367's investigation on supporting IEEE 
math operations as intrinsics.
Which was discussed in this RFC:
https://discourse.llvm.org/t/rfc-all-the-math-intrinsics/78294

If you want an overarching view of how this will all connect see:
https://github.com/llvm/llvm-project/pull/90088

Much of this change was following how G_FSIN and G_FCOS were used.

The X86 Lowering and test cases of this pr should be credited to 
https://github.com/junaire
https://reviews.llvm.org/D146905

Changes:
-  `llvm/docs/GlobalISel/GenericOpcode.rst` - Document the `G_FTAN` opcode 
-  `llvm/docs/LangRef.rst` - Document the tan intrinsic
-  `llvm/include/llvm/Analysis/VecFuncs.def` - Associate the tan intrinsic as a 
vector function similar to the tanf libcall.
-  `llvm/include/llvm/CodeGen/BasicTTIImpl.h` - Map the tan intrinsic to 
`ISD::FTAN`
-  `llvm/include/llvm/CodeGen/ISDOpcodes.h` - Define ISD opcodes for `FTAN` and 
`STRICT_FTAN`
-  `llvm/include/llvm/IR/Intrinsics.td` - Create the tan intrinsic
-  `llvm/include/llvm/IR/RuntimeLibcalls.def` - Define tan libcall mappings
-  `llvm/include/llvm/Target/GenericOpcodes.td` - Define the `G_FTAN` Opcode
-  `llvm/include/llvm/Support/TargetOpcodes.def` - Create a `G_FTAN` Opcode 
handler
-  `llvm/include/llvm/Target/GlobalISel/SelectionDAGCompat.td`  - Map `G_FTAN` 
to `ftan`
-  `llvm/include/llvm/Target/TargetSelectionDAG.td` - Define `ftan`, 
`strict_ftan`,  and `any_ftan` and map them to the ISD opcodes for `FTAN` and 
`STRICT_FTAN`
-  `llvm/lib/Analysis/VectorUtils.cpp` - Associate the tan intrinsic as a 
vector intrinsic
-  `llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp` Map the tan intrinsic to  
`G_FTAN` Opcode
-  `llvm/lib/CodeGen/GlobalISel/LegalizerHelper.cpp` - Add `G_FTAN` to the list 
of  floating point math operations also associate `G_FTAN` with the `TAN_F` 
runtime lib.
- `llvm/lib/CodeGen/GlobalISel/Utils.cpp` - More floating point math operation 
common behaviors.
-  llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp - List the function expansion 
operations for `FTAN` and `STRICT_FTAN`. Also define both opcodes in 
`PromoteNode`.
- `llvm/lib/CodeGen/SelectionDAG/LegalizeFloatTypes.cpp` - More `FTAN` and 
`STRICT_FTAN` handling in the legalizer
-  `llvm/lib/CodeGen/SelectionDAG/LegalizeTypes.h` - Define 
`SoftenFloatRes_FTAN` and `ExpandFloatRes_FTAN`.
- `llvm/lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp` - Define `FTAN` as a 
legal vector operation.
-  `llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp` - Define `FTAN` as a 
legal vector operation.
-  `llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp` - define tan as an 
intrinsic that doesn't return NaN.
-  `llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp` Map `LibFunc_tan`, 
`LibFunc_tanf`, and `LibFunc_tanl` to `ISD::FTAN`. Map `Intrinsic::tan` to 
`ISD::FTAN` and add selection dag handling for `Intrinsic::tan`.
-  `llvm/lib/CodeGen/SelectionDAG/SelectionDAGDumper.cpp` - Define  `ftan` and 
`strict_ftan` names for the equivalent ISD  opcodes.
- `llvm/lib/CodeGen/TargetLoweringBase.cpp` -Define a Tan128 libcall and 
ISD::FTAN as a target lowering action.
-  `llvm/lib/Target/X86/X86ISelLowering.cpp` - Add x86_64 lowering for tan 
intrinsic


>From cff8b8b373338c94a5faa5d48804daf98da33db0 Mon Sep 17 00:00:00 2001
From: Farzon Lotfi 
Date: Wed, 24 Apr 2024 17:34:04 -0400
Subject: [PATCH 1/7] start of tan intrinsic

---
 clang/docs/LanguageExtensions.rst |  3 +-
 clang/include/clang/Basic/Builtins.td |  6 ++
 clang/lib/CodeGen/CGBuiltin.cpp   |  4 +-
 clang/lib/Headers/hlsl/hlsl_intrinsics.h  | 23 
 clang/lib/Sema/SemaChecking.cpp   |  2 +
 .../test/CodeGen/builtins-elementwise-math.c  | 16 ++
 .../CodeGen/strictfp-elementwise-bulitins.cpp | 10 
 clang/test/CodeGenHLSL/builtins/tan.hlsl  | 56 +++
 clang/test/Sema/aarch64-sve-vector-trig-ops.c |  6 ++
 clang/test/Sema/builtins-elementwise-math.c   | 21 +++
 clang/test/Sema/riscv-rvv-vector-trig-ops.c   |  6 ++
 .../SemaCXX/builtins-elementwise-math.cpp |  7 +++
 llvm/docs/GlobalISel/GenericOpcode.rst|  2 +-
 llvm/docs/LangRef.rst | 37 
 llvm/include/llvm/Analysis/VecFuncs.def   |  1 +
 llvm/include/llvm/CodeGen/BasicTTIImpl.h  |  3 +
 llvm/include/llvm/CodeGen/ISDOpcodes.h|  2 +
 llvm/include/llvm/IR/Intrinsics.td|  1 +
 llvm/include/llvm/IR/RuntimeLibcalls.def  |  5 ++
 llvm/include/llvm/Support/TargetOpcodes.def   |  3 +
 llvm/include/llvm/Target/GenericOpcodes.td|  7 +++
 .../Target/GlobalISel/SelectionDAGCompat.td   |  1 +
 .../include/llvm/Target/TargetSelectionDAG.td |  6 ++
 llvm/lib/Analysis/VectorUtils.cpp |  1 +
 llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp  |  2 +
 .../CodeGen/GlobalISel/LegalizerHelper.cpp|  5 ++
 

[clang] [OpenMP][TR12] change property of map-type modifier. (PR #90499)

2024-04-29 Thread Alexey Bataev via cfe-commits


@@ -113,7 +114,7 @@ struct SA {
 #pragma omp target map(b[true:true])
 {}
 
-#pragma omp target map(: c,f) // expected-error {{missing map type}}
+#pragma omp target map(: c,f) // lt60-error {{missing map type}}

alexey-bataev wrote:

I assume this also must be reported as an error for 6.0, no?

https://github.com/llvm/llvm-project/pull/90499
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [OpenMP][TR12] change property of map-type modifier. (PR #90499)

2024-04-29 Thread Alexey Bataev via cfe-commits


@@ -4268,7 +4287,11 @@ bool 
Parser::parseMapTypeModifiers(SemaOpenMP::OpenMPVarListDataTy ) {
   }
   // Potential map-type token as it is followed by a colon.
   if (PP.LookAhead(0).is(tok::colon))
-return false;
+if (getLangOpts().OpenMP >= 60)
+  break;
+else
+  return false;
+

alexey-bataev wrote:

Need extra braces here to correctly handle else

https://github.com/llvm/llvm-project/pull/90499
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang][Sema] Earlier type checking for builtin unary operators (PR #90500)

2024-04-29 Thread Krystian Stasiowski via cfe-commits

https://github.com/sdkrystian updated 
https://github.com/llvm/llvm-project/pull/90500

>From 6a2d3719508fbd765a97e81688ae06996e7daf21 Mon Sep 17 00:00:00 2001
From: Krystian Stasiowski 
Date: Thu, 25 Apr 2024 08:17:21 -0400
Subject: [PATCH] [Clang][Sema] Earlier type checking for builtin unary
 operators

---
 clang/include/clang/AST/Type.h|  5 -
 clang/lib/Sema/SemaExpr.cpp   | 21 ---
 clang/test/AST/ast-dump-expr-json.cpp |  4 ++--
 clang/test/AST/ast-dump-expr.cpp  |  2 +-
 clang/test/AST/ast-dump-lambda.cpp|  2 +-
 clang/test/CXX/over/over.built/ast.cpp|  8 ---
 clang/test/Frontend/noderef_templates.cpp |  4 ++--
 clang/test/SemaCXX/cxx2b-deducing-this.cpp|  6 ++
 .../test/SemaTemplate/class-template-spec.cpp | 12 +--
 9 files changed, 36 insertions(+), 28 deletions(-)

diff --git a/clang/include/clang/AST/Type.h b/clang/include/clang/AST/Type.h
index dff02d4861b3db..fae4730130ae50 100644
--- a/clang/include/clang/AST/Type.h
+++ b/clang/include/clang/AST/Type.h
@@ -8040,7 +8040,10 @@ inline bool Type::isUndeducedType() const {
 /// Determines whether this is a type for which one can define
 /// an overloaded operator.
 inline bool Type::isOverloadableType() const {
-  return isDependentType() || isRecordType() || isEnumeralType();
+  if (!CanonicalType->isDependentType())
+return isRecordType() || isEnumeralType();
+  return !isArrayType() && !isFunctionType() && !isAnyPointerType() &&
+ !isMemberPointerType();
 }
 
 /// Determines whether this type is written as a typedef-name.
diff --git a/clang/lib/Sema/SemaExpr.cpp b/clang/lib/Sema/SemaExpr.cpp
index 50f92c496a539a..9284ccb3eb7715 100644
--- a/clang/lib/Sema/SemaExpr.cpp
+++ b/clang/lib/Sema/SemaExpr.cpp
@@ -671,11 +671,12 @@ ExprResult Sema::DefaultLvalueConversion(Expr *E) {
 
   // We don't want to throw lvalue-to-rvalue casts on top of
   // expressions of certain types in C++.
-  if (getLangOpts().CPlusPlus &&
-  (E->getType() == Context.OverloadTy ||
-   T->isDependentType() ||
-   T->isRecordType()))
-return E;
+  if (getLangOpts().CPlusPlus) {
+if (T == Context.OverloadTy || T->isRecordType() ||
+(T->isDependentType() && !T->isAnyPointerType() &&
+ !T->isMemberPointerType()))
+  return E;
+  }
 
   // The C standard is actually really unclear on this point, and
   // DR106 tells us what the result should be but not why.  It's
@@ -6,7 +7,7 @@ static bool checkArithmeticIncompletePointerType(Sema 
, SourceLocation Loc,
   if (const AtomicType *ResAtomicType = ResType->getAs())
 ResType = ResAtomicType->getValueType();
 
-  assert(ResType->isAnyPointerType() && !ResType->isDependentType());
+  assert(ResType->isAnyPointerType());
   QualType PointeeTy = ResType->getPointeeType();
   return S.RequireCompleteSizedType(
   Loc, PointeeTy,
@@ -14287,7 +14288,9 @@ static QualType CheckIncrementDecrementOperand(Sema , 
Expr *Op,
ExprObjectKind ,
SourceLocation OpLoc,
bool IsInc, bool IsPrefix) {
-  if (Op->isTypeDependent())
+  if (Op->isTypeDependent() &&
+  (Op->hasPlaceholderType() ||
+   Op->getType()->isSpecificBuiltinType(BuiltinType::Dependent)))
 return S.Context.DependentTy;
 
   QualType ResType = Op->getType();
@@ -14725,7 +14728,9 @@ static void RecordModifiableNonNullParam(Sema , const 
Expr *Exp) {
 static QualType CheckIndirectionOperand(Sema , Expr *Op, ExprValueKind ,
 SourceLocation OpLoc,
 bool IsAfterAmp = false) {
-  if (Op->isTypeDependent())
+  if (Op->isTypeDependent() &&
+  (Op->hasPlaceholderType() ||
+   Op->getType()->isSpecificBuiltinType(BuiltinType::Dependent)))
 return S.Context.DependentTy;
 
   ExprResult ConvResult = S.UsualUnaryConversions(Op);
diff --git a/clang/test/AST/ast-dump-expr-json.cpp 
b/clang/test/AST/ast-dump-expr-json.cpp
index 0fb07b0b434cc3..4b7365e554cb7c 100644
--- a/clang/test/AST/ast-dump-expr-json.cpp
+++ b/clang/test/AST/ast-dump-expr-json.cpp
@@ -4261,9 +4261,9 @@ void TestNonADLCall3() {
 // CHECK-NEXT: }
 // CHECK-NEXT:},
 // CHECK-NEXT:"type": {
-// CHECK-NEXT: "qualType": ""
+// CHECK-NEXT: "qualType": "V"
 // CHECK-NEXT:},
-// CHECK-NEXT:"valueCategory": "prvalue",
+// CHECK-NEXT:"valueCategory": "lvalue",
 // CHECK-NEXT:"isPostfix": false,
 // CHECK-NEXT:"opcode": "*",
 // CHECK-NEXT:"canOverflow": false,
diff --git a/clang/test/AST/ast-dump-expr.cpp b/clang/test/AST/ast-dump-expr.cpp
index 69e65e22d61d0d..4df5ba4276abd2 100644
--- 

[clang] [C++23] [CLANG] Adding C++23 constexpr math functions: fmin and frexp. (PR #88978)

2024-04-29 Thread A. Jiang via cfe-commits


@@ -0,0 +1,57 @@
+// RUN: %clang_cc1 -DWIN -verify -std=c++23 -fsyntax-only  %s
+// RUN: %clang_cc1 -verify -std=c++23 -fsyntax-only  %s
+
+// expected-no-diagnostics
+
+
+#ifdef WIN
+#define INFINITY ((float)(1e+300 * 1e+300))
+#define NAN  (-(float)(INFINITY * 0.0F))
+#else
+#define NAN (__builtin_nanf(""))
+#define INFINITY (__builtin_inff())
+#endif
+
+extern "C" void abort() noexcept;
+extern "C" int write(int, const void*, unsigned long);
+
+#define assert(condition) \
+  do { \
+if (!(condition)) {\
+  write(2, "Assertion failed: ", 18);  \
+  write(2, #condition, sizeof(#condition) - 1);\
+  write(2, "\n", 1);   \
+  abort(); \
+}  \
+  } while (false)
+
+int main() {
+int i;
+
+// fmin
+static_assert(__builtin_fmin(15.24, 1.3) == 1.3, "");
+static_assert(__builtin_fmin(-0.0, +0.0) == -0.0, "");
+static_assert(__builtin_fmin(+0.0, -0.0) == -0.0, "");
+assert(__builtin_isnan(__builtin_fminf(NAN,NAN)));
+assert(__builtin_isnan(__builtin_fminf(NAN, -1)));
+assert(__builtin_isnan(__builtin_fminf(-INFINITY, 0)));
+assert(__builtin_iszero(__builtin_fminf(+INFINITY, 0)));
+
+// frexp
+static_assert(__builtin_frexp(123.45, ) == 0.9644531250002);

frederick-vs-ja wrote:

It seems that we should write something like
```C++
struct { double num_; int expo_; } result;
result.num_ = frexp(x, _);
return result;
```

https://github.com/llvm/llvm-project/pull/88978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


<    1   2   3   4   5   >