[clang] 7cddf9c - [analyzer] Dump the environment entry kind as well

[Balazs Benics via cfe-commits]

Author: Balazs Benics
Date: 2022-09-13T09:04:27+02:00
New Revision: 7cddf9cad18a65217c8ba0661fefcf78d841a16b

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

LOG: [analyzer] Dump the environment entry kind as well

By this change the `exploded-graph-rewriter` will display the class kind
of the expression of the environment entry. It makes easier to decide if
the given entry corresponds to the lvalue or to the rvalue of some
expression.

It turns out the rewriter already had support for visualizing it, but
probably was never actually used?

Reviewed By: martong

Differential Revision: https://reviews.llvm.org/D132109

Added: 


Modified: 
clang/lib/StaticAnalyzer/Core/Environment.cpp
clang/test/Analysis/expr-inspection.c

Removed: 




diff  --git a/clang/lib/StaticAnalyzer/Core/Environment.cpp 
b/clang/lib/StaticAnalyzer/Core/Environment.cpp
index 719793fa224c..3d017b81762a 100644
--- a/clang/lib/StaticAnalyzer/Core/Environment.cpp
+++ b/clang/lib/StaticAnalyzer/Core/Environment.cpp
@@ -274,7 +274,8 @@ void Environment::printJson(raw_ostream &Out, const 
ASTContext &Ctx,
 
   const Stmt *S = I->first.getStmt();
   Indent(Out, InnerSpace, IsDot)
-  << "{ \"stmt_id\": " << S->getID(Ctx) << ", \"pretty\": ";
+  << "{ \"stmt_id\": " << S->getID(Ctx) << ", \"kind\": \""
+  << S->getStmtClassName() << "\", \"pretty\": ";
   S->printJson(Out, nullptr, PP, /*AddQuotes=*/true);
 
   Out << ", \"value\": ";

diff  --git a/clang/test/Analysis/expr-inspection.c 
b/clang/test/Analysis/expr-inspection.c
index 47ac0c251c1f..91c27f5b149f 100644
--- a/clang/test/Analysis/expr-inspection.c
+++ b/clang/test/Analysis/expr-inspection.c
@@ -36,7 +36,7 @@ void foo(int x) {
 // CHECK-NEXT:   ]},
 // CHECK-NEXT:   "environment": { "pointer": "{{0x[0-9a-f]+}}", "items": [
 // CHECK-NEXT: { "lctx_id": {{[0-9]+}}, "location_context": "#0 Call", 
"calling": "foo", "location": null, "items": [
-// CHECK-NEXT:   { "stmt_id": {{[0-9]+}}, "pretty": 
"clang_analyzer_printState", "value": "&code{clang_analyzer_printState}" }
+// CHECK-NEXT:   { "stmt_id": {{[0-9]+}}, "kind": "ImplicitCastExpr", 
"pretty": "clang_analyzer_printState", "value": 
"&code{clang_analyzer_printState}" }
 // CHECK-NEXT: ]}
 // CHECK-NEXT:   ]},
 // CHECK-NEXT:   "constraints": [



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

[PATCH] D132109: [analyzer] Dump the environment entry kind as well

[Balázs Benics via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG7cddf9cad18a: [analyzer] Dump the environment entry kind as 
well (authored by steakhal).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D132109/new/

https://reviews.llvm.org/D132109

Files:
  clang/lib/StaticAnalyzer/Core/Environment.cpp
  clang/test/Analysis/expr-inspection.c


Index: clang/test/Analysis/expr-inspection.c
===
--- clang/test/Analysis/expr-inspection.c
+++ clang/test/Analysis/expr-inspection.c
@@ -36,7 +36,7 @@
 // CHECK-NEXT:   ]},
 // CHECK-NEXT:   "environment": { "pointer": "{{0x[0-9a-f]+}}", "items": [
 // CHECK-NEXT: { "lctx_id": {{[0-9]+}}, "location_context": "#0 Call", 
"calling": "foo", "location": null, "items": [
-// CHECK-NEXT:   { "stmt_id": {{[0-9]+}}, "pretty": 
"clang_analyzer_printState", "value": "&code{clang_analyzer_printState}" }
+// CHECK-NEXT:   { "stmt_id": {{[0-9]+}}, "kind": "ImplicitCastExpr", 
"pretty": "clang_analyzer_printState", "value": 
"&code{clang_analyzer_printState}" }
 // CHECK-NEXT: ]}
 // CHECK-NEXT:   ]},
 // CHECK-NEXT:   "constraints": [
Index: clang/lib/StaticAnalyzer/Core/Environment.cpp
===
--- clang/lib/StaticAnalyzer/Core/Environment.cpp
+++ clang/lib/StaticAnalyzer/Core/Environment.cpp
@@ -274,7 +274,8 @@
 
   const Stmt *S = I->first.getStmt();
   Indent(Out, InnerSpace, IsDot)
-  << "{ \"stmt_id\": " << S->getID(Ctx) << ", \"pretty\": ";
+  << "{ \"stmt_id\": " << S->getID(Ctx) << ", \"kind\": \""
+  << S->getStmtClassName() << "\", \"pretty\": ";
   S->printJson(Out, nullptr, PP, /*AddQuotes=*/true);
 
   Out << ", \"value\": ";


Index: clang/test/Analysis/expr-inspection.c
===
--- clang/test/Analysis/expr-inspection.c
+++ clang/test/Analysis/expr-inspection.c
@@ -36,7 +36,7 @@
 // CHECK-NEXT:   ]},
 // CHECK-NEXT:   "environment": { "pointer": "{{0x[0-9a-f]+}}", "items": [
 // CHECK-NEXT: { "lctx_id": {{[0-9]+}}, "location_context": "#0 Call", "calling": "foo", "location": null, "items": [
-// CHECK-NEXT:   { "stmt_id": {{[0-9]+}}, "pretty": "clang_analyzer_printState", "value": "&code{clang_analyzer_printState}" }
+// CHECK-NEXT:   { "stmt_id": {{[0-9]+}}, "kind": "ImplicitCastExpr", "pretty": "clang_analyzer_printState", "value": "&code{clang_analyzer_printState}" }
 // CHECK-NEXT: ]}
 // CHECK-NEXT:   ]},
 // CHECK-NEXT:   "constraints": [
Index: clang/lib/StaticAnalyzer/Core/Environment.cpp
===
--- clang/lib/StaticAnalyzer/Core/Environment.cpp
+++ clang/lib/StaticAnalyzer/Core/Environment.cpp
@@ -274,7 +274,8 @@
 
   const Stmt *S = I->first.getStmt();
   Indent(Out, InnerSpace, IsDot)
-  << "{ \"stmt_id\": " << S->getID(Ctx) << ", \"pretty\": ";
+  << "{ \"stmt_id\": " << S->getID(Ctx) << ", \"kind\": \""
+  << S->getStmtClassName() << "\", \"pretty\": ";
   S->printJson(Out, nullptr, PP, /*AddQuotes=*/true);
 
   Out << ", \"value\": ";
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D132285: [Clang][LoongArch] Implement ABI lowering

[Lu Weining via Phabricator via cfe-commits]

SixWeining added a comment.

ping.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D132285/new/

https://reviews.llvm.org/D132285

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

[PATCH] D133753: [clang][Interp] WIP: Array fillers

[Timm Bäder via Phabricator via cfe-commits]

tbaeder created this revision.
tbaeder added reviewers: erichkeane, aaron.ballman, shafik, tahonermann.
Herald added a project: All.
tbaeder requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Uploading this now to get some early feedback on the approach and maybe find 
some better tests.

Pointers in the VM are implemented through the `Pointer` class. Each `Pointer` 
points to a `Block`, which represent memory. However, each `Block` also knows 
all the `Pointer`s pointing at it. I've used this to find simply replace a 
`Block` representing an array with a larger one and update all pointers 
pointing to said block (`Block::transferPointers()`). This is the core of it 
all, but it requires quite a few smaller changes that could be broken out of 
this patch of course. Like enabling pointer tracking for static `Block`s.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133753

Files:
  clang/lib/AST/Interp/Boolean.h
  clang/lib/AST/Interp/ByteCodeExprGen.cpp
  clang/lib/AST/Interp/Context.cpp
  clang/lib/AST/Interp/Descriptor.cpp
  clang/lib/AST/Interp/Descriptor.h
  clang/lib/AST/Interp/EvalEmitter.cpp
  clang/lib/AST/Interp/Integral.h
  clang/lib/AST/Interp/Interp.h
  clang/lib/AST/Interp/InterpBlock.cpp
  clang/lib/AST/Interp/InterpBlock.h
  clang/lib/AST/Interp/InterpFrame.cpp
  clang/lib/AST/Interp/InterpFrame.h
  clang/lib/AST/Interp/InterpStack.h
  clang/lib/AST/Interp/Pointer.cpp
  clang/lib/AST/Interp/Pointer.h
  clang/lib/AST/Interp/Program.cpp
  clang/lib/AST/Interp/Program.h
  clang/test/AST/Interp/arrays.cpp

Index: clang/test/AST/Interp/arrays.cpp
===
--- clang/test/AST/Interp/arrays.cpp
+++ clang/test/AST/Interp/arrays.cpp
@@ -98,3 +98,59 @@
 struct fred y [] = { [0] = { .s[0] = 'q' } };
 #endif
 #pragma clang diagnostic pop
+
+namespace indices {
+  constexpr int first[] = {1};
+  constexpr int firstValue = first[2]; // ref-error {{must be initialized by a constant expression}} \
+   // ref-note {{cannot refer to element 2 of array of 1}} \
+   // expected-error {{must be initialized by a constant expression}} \
+   // expected-note {{cannot refer to element 2 of array of 1}}
+
+  constexpr int second[10] = {17};
+  constexpr int secondValue = second[10];// ref-error {{must be initialized by a constant expression}} \
+ // ref-note {{read of dereferenced one-past-the-end pointer}} \
+ // expected-error {{must be initialized by a constant expression}} \
+ // expected-note {{cannot refer to element 10 of array of 10}}
+
+  constexpr int negative = second[-2]; // ref-error {{must be initialized by a constant expression}} \
+   // ref-note {{cannot refer to element -2 of array of 10}} \
+   // expected-error {{must be initialized by a constant expression}} \
+   // expected-note {{cannot refer to element -2 of array of 10}}
+};
+
+namespace fillers {
+  constexpr int k[3] = {1337};
+  constexpr int foo(int m) {
+return k[m];
+  }
+  static_assert(foo(0) == 1337, "");
+  static_assert(foo(1) == 0, "");
+  static_assert(foo(2) == 0, "");
+
+  constexpr int N = 12;
+  constexpr int local(unsigned i) {
+int arr[N] = {1,2,3};
+return arr[i];
+  }
+  static_assert(local(0) == 1, "");
+  static_assert(local(1) == 2, "");
+  static_assert(local(2) == 3, "");
+  static_assert(local(3) == 0, "");
+  static_assert(local(N - 1) == 0, "");
+
+  /// FIXME: Non-primitive array fillers are not handled properly currently,
+  ///   but nobody notices right now because all fillers are 0 anyway and
+  ///   that's also was we memset() the memory to.
+  constexpr int twodim[2][4] = {
+{1,2},
+{3,4}
+  };
+  static_assert(twodim[0][0] == 1, "");
+  static_assert(twodim[0][1] == 2, "");
+  static_assert(twodim[0][2] == 0, "");
+  static_assert(twodim[0][3] == 0, "");
+  static_assert(twodim[1][0] == 3, "");
+  static_assert(twodim[1][1] == 4, "");
+  static_assert(twodim[1][2] == 0, "");
+  static_assert(twodim[1][3] == 0, "");
+};
Index: clang/lib/AST/Interp/Program.h
===
--- clang/lib/AST/Interp/Program.h
+++ clang/lib/AST/Interp/Program.h
@@ -56,7 +56,12 @@
   /// Returns the value of a global.
   Block *getGlobal(unsigned Idx) {
 assert(Idx < Globals.size());
-return Globals[Idx]->block();
+return Globals[Idx].block();
+  }
+
+  /// Checks whether the given pointer points to a global variable.
+  bool isGlobalPointer(const Pointer &P) const {
+return false;
   }
 
   /// Finds a global's index.
@@ -69,7 +74,7 @@
   llvm::Optional getOrCreateDummy(const Par

[PATCH] D132030: [analyzer] Pass correct bldrCtx to computeObjectUnderConstruction

[Tomasz Kamiński via Phabricator via cfe-commits]

tomasz-kaminski-sonarsource updated this revision to Diff 459666.
tomasz-kaminski-sonarsource added a comment.

Ping and reformat.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D132030/new/

https://reviews.llvm.org/D132030

Files:
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/CoreEngine.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
  clang/lib/StaticAnalyzer/Core/CallEvent.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp
  clang/test/Analysis/copy-elision.cpp

Index: clang/test/Analysis/copy-elision.cpp
===
--- clang/test/Analysis/copy-elision.cpp
+++ clang/test/Analysis/copy-elision.cpp
@@ -20,6 +20,7 @@
 #endif
 
 void clang_analyzer_eval(bool);
+void clang_analyzer_dump(int);
 
 namespace variable_functional_cast_crash {
 
@@ -418,3 +419,31 @@
 }
 
 } // namespace address_vector_tests
+
+namespace arg_directly_from_return_in_loop {
+
+struct Result {
+  int value;
+};
+
+Result create() {
+  return Result{10};
+}
+
+int accessValue(Result r) {
+  return r.value;
+}
+
+void test() {
+  for (int i = 0; i < 3; ++i) {
+int v = accessValue(create());
+if (i == 0) {
+  clang_analyzer_dump(v); // expected-warning {{10 S32b}}
+} else {
+  clang_analyzer_dump(v); // expected-warning {{10 S32b}}
+  // was {{reg_${{[0-9]+}} }} for C++11
+}
+  }
+}
+
+} // namespace arg_directly_from_return_in_loop
Index: clang/lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp
===
--- clang/lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp
+++ clang/lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp
@@ -760,9 +760,9 @@
 SVal Target;
 assert(RTC->getStmt() == Call.getOriginExpr());
 EvalCallOptions CallOpts; // FIXME: We won't really need those.
-std::tie(State, Target) =
-handleConstructionContext(Call.getOriginExpr(), State, LCtx,
-  RTC->getConstructionContext(), CallOpts);
+std::tie(State, Target) = handleConstructionContext(
+Call.getOriginExpr(), State, currBldrCtx, LCtx,
+RTC->getConstructionContext(), CallOpts);
 const MemRegion *TargetR = Target.getAsRegion();
 assert(TargetR);
 // Invalidate the region so that it didn't look uninitialized. If this is
Index: clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
===
--- clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
+++ clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
@@ -111,9 +111,15 @@
   return LValue;
 }
 
+// In case when the prvalue is returned from the function (kind is one of
+// SimpleReturnedValueKind, CXX17ElidedCopyReturnedValueKind), then
+// it's materialization happens in context of the caller.
+// We pass BldrCtx explicitly, as currBldrCtx always refers to callee's context.
 SVal ExprEngine::computeObjectUnderConstruction(
-const Expr *E, ProgramStateRef State, const LocationContext *LCtx,
-const ConstructionContext *CC, EvalCallOptions &CallOpts, unsigned Idx) {
+const Expr *E, ProgramStateRef State, const NodeBuilderContext *BldrCtx,
+const LocationContext *LCtx, const ConstructionContext *CC,
+EvalCallOptions &CallOpts, unsigned Idx) {
+
   SValBuilder &SVB = getSValBuilder();
   MemRegionManager &MRMgr = SVB.getRegionManager();
   ASTContext &ACtx = SVB.getContext();
@@ -210,8 +216,11 @@
   CallerLCtx = CallerLCtx->getParent();
   assert(!isa(CallerLCtx));
 }
+
+NodeBuilderContext CallerBldrCtx(getCoreEngine(),
+ SFC->getCallSiteBlock(), CallerLCtx);
 return computeObjectUnderConstruction(
-cast(SFC->getCallSite()), State, CallerLCtx,
+cast(SFC->getCallSite()), State, &CallerBldrCtx, CallerLCtx,
 RTC->getConstructionContext(), CallOpts);
   } else {
 // We are on the top frame of the analysis. We do not know where is the
@@ -251,7 +260,7 @@
   EvalCallOptions PreElideCallOpts = CallOpts;
 
   SVal V = computeObjectUnderConstruction(
-  TCC->getConstructorAfterElision(), State, LCtx,
+  TCC->getConstructorAfterElision(), State, BldrCtx, LCtx,
   TCC->getConstructionContextAfterElision(), CallOpts);
 
   // FIXME: This definition of "copy elision has not failed" is unreliable.
@@ -319,7 +328,7 @@
   CallEventManager &CEMgr = getStateManager().getCallEventManager();
   auto getArgLoc = [&](CallEventRef<> Caller) -> Optional {
 const LocationContext *FutureSFC =
-Caller->getCalleeStackFrame(currBldrCtx->blockCount());
+Caller->getCalleeStackFrame(BldrCtx->blockCount());
 // Return early if we are unable to reliably foresee
 // the future stack frame.
 

[clang] fbfe1db - [clang] Explicitly set the EmulatedTLS codegen option. NFC.

[Martin Storsjö via cfe-commits]

Author: Martin Storsjö
Date: 2022-09-13T10:40:54+03:00
New Revision: fbfe1db4a95a73ed6a0767db0ab7d449fc03405e

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

LOG: [clang] Explicitly set the EmulatedTLS codegen option. NFC.

Set the EmulatedTLS option based on `Triple::hasDefaultEmulatedTLS()`
if the user didn't specify it; set `ExplicitEmulatedTLS` to true
in `llvm::TargetOptions` and set `EmulatedTLS` to Clang's
opinion of what the default or preference is.

This avoids any risk of deviance between the two.

This affects one check of `getCodeGenOpts().EmulatedTLS` in
`shouldAssumeDSOLocal` in CodeGenModule, but as that check only
is done for `TT.isWindowsGNUEnvironment()`, and
`hasDefaultEmulatedTLS()` returns false for such environments
it doesn't make any current testable difference - thus NFC.

Some mingw distributions carry a downstream patch, that enables
emulated TLS by default for mingw targets in `hasDefaultEmulatedTLS()`
- and for such cases, this patch does make a difference and fixes the
detection of emulated TLS, if it is implicitly enabled.

Differential Revision: https://reviews.llvm.org/D132916

Added: 


Modified: 
clang/include/clang/Basic/CodeGenOptions.def
clang/lib/CodeGen/BackendUtil.cpp
clang/lib/Frontend/CompilerInvocation.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/CodeGenOptions.def 
b/clang/include/clang/Basic/CodeGenOptions.def
index ca2aa0d09aaf9..9c1a23cb17261 100644
--- a/clang/include/clang/Basic/CodeGenOptions.def
+++ b/clang/include/clang/Basic/CodeGenOptions.def
@@ -88,7 +88,6 @@ CODEGENOPT(EmitGcovArcs  , 1, 0) ///< Emit coverage data 
files, aka. GCDA.
 CODEGENOPT(EmitGcovNotes , 1, 0) ///< Emit coverage "notes" files, aka 
GCNO.
 CODEGENOPT(EmitOpenCLArgMetadata , 1, 0) ///< Emit OpenCL kernel arg metadata.
 CODEGENOPT(EmulatedTLS   , 1, 0) ///< Set by default or 
-f[no-]emulated-tls.
-CODEGENOPT(ExplicitEmulatedTLS , 1, 0) ///< Set if -f[no-]emulated-tls is used.
 /// Embed Bitcode mode (off/all/bitcode/marker).
 ENUM_CODEGENOPT(EmbedBitcode, EmbedBitcodeKind, 2, Embed_Off)
 /// Inline asm dialect, -masm=(att|intel)

diff  --git a/clang/lib/CodeGen/BackendUtil.cpp 
b/clang/lib/CodeGen/BackendUtil.cpp
index f4a4f1cd22ab9..aff277f59c054 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -440,7 +440,7 @@ static bool initTargetOptions(DiagnosticsEngine &Diags,
   CodeGenOpts.UniqueBasicBlockSectionNames;
   Options.TLSSize = CodeGenOpts.TLSSize;
   Options.EmulatedTLS = CodeGenOpts.EmulatedTLS;
-  Options.ExplicitEmulatedTLS = CodeGenOpts.ExplicitEmulatedTLS;
+  Options.ExplicitEmulatedTLS = true;
   Options.DebuggerTuning = CodeGenOpts.getDebuggerTuning();
   Options.EmitStackSizeSection = CodeGenOpts.StackSizeSection;
   Options.StackUsageOutput = CodeGenOpts.StackUsageOutput;

diff  --git a/clang/lib/Frontend/CompilerInvocation.cpp 
b/clang/lib/Frontend/CompilerInvocation.cpp
index 9ac522adfd9a9..201b9965bb0eb 100644
--- a/clang/lib/Frontend/CompilerInvocation.cpp
+++ b/clang/lib/Frontend/CompilerInvocation.cpp
@@ -1492,13 +1492,8 @@ void CompilerInvocation::GenerateCodeGenArgs(
 F.Filename, SA);
   }
 
-  // TODO: Consider removing marshalling annotations from f[no_]emulated_tls.
-  //  That would make it easy to generate the option only **once** if it was
-  //  explicitly set to non-default value.
-  if (Opts.ExplicitEmulatedTLS) {
-GenerateArg(
-Args, Opts.EmulatedTLS ? OPT_femulated_tls : OPT_fno_emulated_tls, SA);
-  }
+  GenerateArg(
+  Args, Opts.EmulatedTLS ? OPT_femulated_tls : OPT_fno_emulated_tls, SA);
 
   if (Opts.FPDenormalMode != llvm::DenormalMode::getIEEE())
 GenerateArg(Args, OPT_fdenormal_fp_math_EQ, Opts.FPDenormalMode.str(), SA);
@@ -1862,9 +1857,9 @@ bool CompilerInvocation::ParseCodeGenArgs(CodeGenOptions 
&Opts, ArgList &Args,
 Opts.LinkBitcodeFiles.push_back(F);
   }
 
-  if (Args.getLastArg(OPT_femulated_tls) ||
-  Args.getLastArg(OPT_fno_emulated_tls)) {
-Opts.ExplicitEmulatedTLS = true;
+  if (!Args.getLastArg(OPT_femulated_tls) &&
+  !Args.getLastArg(OPT_fno_emulated_tls)) {
+Opts.EmulatedTLS = T.hasDefaultEmulatedTLS();
   }
 
   if (Arg *A = Args.getLastArg(OPT_ftlsmodel_EQ)) {



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

[PATCH] D132916: [clang] Explicitly set the EmulatedTLS codegen option

[Martin Storsjö via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGfbfe1db4a95a: [clang] Explicitly set the EmulatedTLS codegen 
option. NFC. (authored by mstorsjo).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D132916/new/

https://reviews.llvm.org/D132916

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Frontend/CompilerInvocation.cpp


Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -1492,13 +1492,8 @@
 F.Filename, SA);
   }
 
-  // TODO: Consider removing marshalling annotations from f[no_]emulated_tls.
-  //  That would make it easy to generate the option only **once** if it was
-  //  explicitly set to non-default value.
-  if (Opts.ExplicitEmulatedTLS) {
-GenerateArg(
-Args, Opts.EmulatedTLS ? OPT_femulated_tls : OPT_fno_emulated_tls, SA);
-  }
+  GenerateArg(
+  Args, Opts.EmulatedTLS ? OPT_femulated_tls : OPT_fno_emulated_tls, SA);
 
   if (Opts.FPDenormalMode != llvm::DenormalMode::getIEEE())
 GenerateArg(Args, OPT_fdenormal_fp_math_EQ, Opts.FPDenormalMode.str(), SA);
@@ -1862,9 +1857,9 @@
 Opts.LinkBitcodeFiles.push_back(F);
   }
 
-  if (Args.getLastArg(OPT_femulated_tls) ||
-  Args.getLastArg(OPT_fno_emulated_tls)) {
-Opts.ExplicitEmulatedTLS = true;
+  if (!Args.getLastArg(OPT_femulated_tls) &&
+  !Args.getLastArg(OPT_fno_emulated_tls)) {
+Opts.EmulatedTLS = T.hasDefaultEmulatedTLS();
   }
 
   if (Arg *A = Args.getLastArg(OPT_ftlsmodel_EQ)) {
Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -440,7 +440,7 @@
   CodeGenOpts.UniqueBasicBlockSectionNames;
   Options.TLSSize = CodeGenOpts.TLSSize;
   Options.EmulatedTLS = CodeGenOpts.EmulatedTLS;
-  Options.ExplicitEmulatedTLS = CodeGenOpts.ExplicitEmulatedTLS;
+  Options.ExplicitEmulatedTLS = true;
   Options.DebuggerTuning = CodeGenOpts.getDebuggerTuning();
   Options.EmitStackSizeSection = CodeGenOpts.StackSizeSection;
   Options.StackUsageOutput = CodeGenOpts.StackUsageOutput;
Index: clang/include/clang/Basic/CodeGenOptions.def
===
--- clang/include/clang/Basic/CodeGenOptions.def
+++ clang/include/clang/Basic/CodeGenOptions.def
@@ -88,7 +88,6 @@
 CODEGENOPT(EmitGcovNotes , 1, 0) ///< Emit coverage "notes" files, aka 
GCNO.
 CODEGENOPT(EmitOpenCLArgMetadata , 1, 0) ///< Emit OpenCL kernel arg metadata.
 CODEGENOPT(EmulatedTLS   , 1, 0) ///< Set by default or 
-f[no-]emulated-tls.
-CODEGENOPT(ExplicitEmulatedTLS , 1, 0) ///< Set if -f[no-]emulated-tls is used.
 /// Embed Bitcode mode (off/all/bitcode/marker).
 ENUM_CODEGENOPT(EmbedBitcode, EmbedBitcodeKind, 2, Embed_Off)
 /// Inline asm dialect, -masm=(att|intel)


Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -1492,13 +1492,8 @@
 F.Filename, SA);
   }
 
-  // TODO: Consider removing marshalling annotations from f[no_]emulated_tls.
-  //  That would make it easy to generate the option only **once** if it was
-  //  explicitly set to non-default value.
-  if (Opts.ExplicitEmulatedTLS) {
-GenerateArg(
-Args, Opts.EmulatedTLS ? OPT_femulated_tls : OPT_fno_emulated_tls, SA);
-  }
+  GenerateArg(
+  Args, Opts.EmulatedTLS ? OPT_femulated_tls : OPT_fno_emulated_tls, SA);
 
   if (Opts.FPDenormalMode != llvm::DenormalMode::getIEEE())
 GenerateArg(Args, OPT_fdenormal_fp_math_EQ, Opts.FPDenormalMode.str(), SA);
@@ -1862,9 +1857,9 @@
 Opts.LinkBitcodeFiles.push_back(F);
   }
 
-  if (Args.getLastArg(OPT_femulated_tls) ||
-  Args.getLastArg(OPT_fno_emulated_tls)) {
-Opts.ExplicitEmulatedTLS = true;
+  if (!Args.getLastArg(OPT_femulated_tls) &&
+  !Args.getLastArg(OPT_fno_emulated_tls)) {
+Opts.EmulatedTLS = T.hasDefaultEmulatedTLS();
   }
 
   if (Arg *A = Args.getLastArg(OPT_ftlsmodel_EQ)) {
Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -440,7 +440,7 @@
   CodeGenOpts.UniqueBasicBlockSectionNames;
   Options.TLSSize = CodeGenOpts.TLSSize;
   Options.EmulatedTLS = CodeGenOpts.EmulatedTLS;
-  Options.ExplicitEmulatedTLS = CodeGenOpts.ExplicitEmulatedTLS;
+  Options.ExplicitEmulatedTLS = true;
   Options.DebuggerTuning = CodeGenOpts.getDebuggerTuning();
   Options.EmitStackSizeSection = CodeGenOpts.StackSizeSection;
   Options.StackUsageOu

[PATCH] D132848: [clang] Fix checking for emulated TLS in shouldAssumeDSOLocal in CodeGen

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo abandoned this revision.
mstorsjo added a comment.

Abandoned in favour of D132916 .


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D132848/new/

https://reviews.llvm.org/D132848

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

[PATCH] D111283: [clang] template / auto deduction deduces common sugar

[Alexander Kornienko via Phabricator via cfe-commits]

alexfh added a comment.

In D111283#3785259 , @alexfh wrote:

> In D111283#3785240 , @alexfh wrote:
>
>> In D111283#3783627 , @alexfh wrote:
>>
>>> Hi Matheus, an early heads up: this commit is causing clang crashes on some 
>>> of our code. I'll post more details a bit later.
>>
>> The stack trace of the failure looks like this:
>
> And the assertions-enabled build of clang prints this:
>
>   Unexpected sugar-free: TemplateTypeParm
>   UNREACHABLE executed at llvm-project/clang/lib/AST/ASTContext.cpp:12383!

Reduced test case:

  $ cat q.cc
  struct a {
int b;
  };
  template  using e = c d::*;
  struct f {
long b() const;
template  c g(e) const;
a h;
  };
  template 
  void j(e, const d *, i...);
  template  c j(e, const d *);
  template  c f::g(e k) const { return j(k, &h); }
  long f::b() const { return g(&a::b); }



  $ ./clang-after q.cc
  ...
  1.   parser at end of file
  2.  q.cc:13:28: instantiating function definition 'f::g'
  ...
  clang-after: error: unable to execute command: Trace/breakpoint trap
  clang-after: error: clang frontend command failed due to signal (use -v to 
see invocation)

Please fix or revert soon.

Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D111283/new/

https://reviews.llvm.org/D111283

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

[PATCH] D133756: [clangd] Introduce CompileCommandsAdjuster

[Nathan Ridge via Phabricator via cfe-commits]

nridge created this revision.
nridge added reviewers: kadircet, sammccall.
Herald added a subscriber: arphaman.
Herald added a project: All.
nridge requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang-tools-extra.

Use it instead of tooling::ArgumentsAdjuster as the interface between
CommandMangler and OverlayCDB.

This is a more expressive interface that gives CommandMangler access
to other fields of tooling::CompileCommand as well, e.g. Directory.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133756

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/CompileCommands.cpp
  clang-tools-extra/clangd/CompileCommands.h
  clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
  clang-tools-extra/clangd/GlobalCompilationDatabase.h
  clang-tools-extra/clangd/indexer/IndexerMain.cpp
  clang-tools-extra/clangd/tool/Check.cpp
  clang-tools-extra/clangd/unittests/BackgroundIndexTests.cpp
  clang-tools-extra/clangd/unittests/ClangdTests.cpp
  clang-tools-extra/clangd/unittests/CompileCommandsTests.cpp
  clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp
  clang-tools-extra/clangd/unittests/TestTU.cpp

Index: clang-tools-extra/clangd/unittests/TestTU.cpp
===
--- clang-tools-extra/clangd/unittests/TestTU.cpp
+++ clang-tools-extra/clangd/unittests/TestTU.cpp
@@ -59,7 +59,7 @@
   Argv.push_back(FullFilename);
 
   auto Mangler = CommandMangler::forTests();
-  Mangler.adjust(Inputs.CompileCommand.CommandLine, FullFilename);
+  Mangler->adjust(Inputs.CompileCommand, FullFilename);
   Inputs.CompileCommand.Filename = FullFilename;
   Inputs.CompileCommand.Directory = testRoot();
   Inputs.Contents = Code;
Index: clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp
===
--- clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp
+++ clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp
@@ -137,13 +137,14 @@
 }
 
 TEST_F(OverlayCDBTest, Adjustments) {
-  OverlayCDB CDB(Base.get(), {"-DFallback"},
- [](const std::vector &Cmd, llvm::StringRef File) {
-   auto Ret = Cmd;
-   Ret.push_back(
-   ("-DAdjust_" + llvm::sys::path::filename(File)).str());
-   return Ret;
- });
+  struct Adjuster : public CompileCommandsAdjuster {
+void adjust(tooling::CompileCommand &Cmd,
+llvm::StringRef File) const override {
+  Cmd.CommandLine.push_back(
+  ("-DAdjust_" + llvm::sys::path::filename(File)).str());
+}
+  };
+  OverlayCDB CDB(Base.get(), {"-DFallback"}, std::make_unique());
   // Command from underlying gets adjusted.
   auto Cmd = *CDB.getCompileCommand(testPath("foo.cc"));
   EXPECT_THAT(Cmd.CommandLine, ElementsAre("clang", "-DA=1", testPath("foo.cc"),
Index: clang-tools-extra/clangd/unittests/CompileCommandsTests.cpp
===
--- clang-tools-extra/clangd/unittests/CompileCommandsTests.cpp
+++ clang-tools-extra/clangd/unittests/CompileCommandsTests.cpp
@@ -42,66 +42,73 @@
 // Other tests just verify presence/absence of certain args.
 TEST(CommandMangler, Everything) {
   auto Mangler = CommandMangler::forTests();
-  Mangler.ClangPath = testPath("fake/clang");
-  Mangler.ResourceDir = testPath("fake/resources");
-  Mangler.Sysroot = testPath("fake/sysroot");
-  std::vector Cmd = {"clang++", "--", "foo.cc", "bar.cc"};
-  Mangler.adjust(Cmd, "foo.cc");
-  EXPECT_THAT(Cmd, ElementsAre(testPath("fake/clang++"),
-   "-resource-dir=" + testPath("fake/resources"),
-   "-isysroot", testPath("fake/sysroot"), "--",
-   "foo.cc"));
+  Mangler->ClangPath = testPath("fake/clang");
+  Mangler->ResourceDir = testPath("fake/resources");
+  Mangler->Sysroot = testPath("fake/sysroot");
+  tooling::CompileCommand Cmd;
+  Cmd.CommandLine = {"clang++", "--", "foo.cc", "bar.cc"};
+  Mangler->adjust(Cmd, "foo.cc");
+  EXPECT_THAT(Cmd.CommandLine,
+  ElementsAre(testPath("fake/clang++"),
+  "-resource-dir=" + testPath("fake/resources"),
+  "-isysroot", testPath("fake/sysroot"), "--",
+  "foo.cc"));
 }
 
 TEST(CommandMangler, FilenameMismatch) {
   auto Mangler = CommandMangler::forTests();
-  Mangler.ClangPath = testPath("clang");
+  Mangler->ClangPath = testPath("clang");
   // Our compile flags refer to foo.cc...
-  std::vector Cmd = {"clang", "foo.cc"};
+  tooling::CompileCommand Cmd;
+  Cmd.CommandLine = {"clang", "foo.cc"};
   // but we're applying it to foo.h...
-  Mangler.adjust(Cmd, "foo.h");
+  Mangler->adjust(Cmd, "foo.h");
   // so transferCompileCommand should add -x c++-header

[PATCH] D133757: [clangd] Turn QueryDriverDatabase into a CompileCommandsAdjuster

[Nathan Ridge via Phabricator via cfe-commits]

nridge created this revision.
nridge added reviewers: kadircet, sammccall.
Herald added a subscriber: arphaman.
Herald added a project: All.
nridge requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang-tools-extra.

This allows it to be run by CommandMangler in an appropriate place
relative to other adjustments.

Also rename it to SystemIncludeExtractor for improved clarity.

Fixes https://github.com/clangd/clangd/issues/1089
Fixes https://github.com/clangd/clangd/issues/1173
Fixes https://github.com/clangd/clangd/issues/1263


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133757

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdLSPServer.h
  clang-tools-extra/clangd/CompileCommands.cpp
  clang-tools-extra/clangd/CompileCommands.h
  clang-tools-extra/clangd/GlobalCompilationDatabase.h
  clang-tools-extra/clangd/QueryDriverDatabase.cpp
  clang-tools-extra/clangd/tool/Check.cpp
  clang-tools-extra/clangd/unittests/ClangdLSPServerTests.cpp

Index: clang-tools-extra/clangd/unittests/ClangdLSPServerTests.cpp
===
--- clang-tools-extra/clangd/unittests/ClangdLSPServerTests.cpp
+++ clang-tools-extra/clangd/unittests/ClangdLSPServerTests.cpp
@@ -71,6 +71,7 @@
   MockFS FS;
   ClangdLSPServer::Options Opts;
   FeatureModuleSet FeatureModules;
+  llvm::Optional Server;
 
 private:
   class Logger : public clang::clangd::Logger {
@@ -97,7 +98,6 @@
 
   Logger L;
   LoggingSession LogSession;
-  llvm::Optional Server;
   llvm::Optional ServerThread;
   LSPClient Client;
 };
@@ -229,6 +229,33 @@
   diagMessage("Use of undeclared identifier 'BAR'";
 }
 
+// Tests that clangd can run --query-driver on a compiler specified
+// via the Compiler key in the config file.
+TEST_F(LSPTest, QueryCompilerFromConfig) {
+  auto CfgProvider =
+  config::Provider::fromAncestorRelativeYAMLFiles(".clangd", FS);
+  Opts.ConfigProvider = CfgProvider.get();
+  Opts.QueryDriverGlobs = {"/**/*"};
+
+  FS.Files[".clangd"] = R"yaml(
+CompileFlags:
+  Compiler: gcc
+  )yaml";
+  // Just to ensure there's a CDB entry
+  FS.Files["compile_flags.txt"] = "-DSOME_FLAG";
+
+  auto &Client = start();
+  Client.sync(); // wait for onInitialize() to run
+
+  auto CompileCommand = Server->getCompileCommand(testPath("foo.cpp"));
+  ASSERT_TRUE(bool(CompileCommand));
+  EXPECT_GE(llvm::count_if(CompileCommand->CommandLine,
+   [](const std::string &Arg) {
+ return StringRef(Arg).contains("isystem");
+   }),
+1);
+}
+
 TEST_F(LSPTest, ModulesTest) {
   class MathModule final : public FeatureModule {
 OutgoingNotification Changed;
Index: clang-tools-extra/clangd/tool/Check.cpp
===
--- clang-tools-extra/clangd/tool/Check.cpp
+++ clang-tools-extra/clangd/tool/Check.cpp
@@ -100,9 +100,9 @@
 Config::current().CompileFlags.CDBSearch.FixedCDBPath;
 std::unique_ptr BaseCDB =
 std::make_unique(CDBOpts);
-BaseCDB = getQueryDriverDatabase(llvm::makeArrayRef(Opts.QueryDriverGlobs),
- std::move(BaseCDB));
-auto Mangler = CommandMangler::detect();
+std::unique_ptr Extractor =
+getSystemIncludeExtractor(llvm::makeArrayRef(Opts.QueryDriverGlobs));
+auto Mangler = CommandMangler::detect(std::move(Extractor));
 if (Opts.ResourceDir)
   Mangler->ResourceDir = *Opts.ResourceDir;
 auto CDB = std::make_unique(
Index: clang-tools-extra/clangd/QueryDriverDatabase.cpp
===
--- clang-tools-extra/clangd/QueryDriverDatabase.cpp
+++ clang-tools-extra/clangd/QueryDriverDatabase.cpp
@@ -315,24 +315,21 @@
 /// Extracts system includes from a trusted driver by parsing the output of
 /// include search path and appends them to the commands coming from underlying
 /// compilation database.
-class QueryDriverDatabase : public DelegatingCDB {
+class SystemIncludeExtractor : public CompileCommandsAdjuster {
 public:
-  QueryDriverDatabase(llvm::ArrayRef QueryDriverGlobs,
-  std::unique_ptr Base)
-  : DelegatingCDB(std::move(Base)),
-QueryDriverRegex(convertGlobsToRegex(QueryDriverGlobs)) {}
+  SystemIncludeExtractor(llvm::ArrayRef QueryDriverGlobs)
+  : QueryDriverRegex(convertGlobsToRegex(QueryDriverGlobs)) {}
 
-  llvm::Optional
-  getCompileCommand(PathRef File) const override {
-auto Cmd = DelegatingCDB::getCompileCommand(File);
-if (!Cmd || Cmd->CommandLine.empty())
-  return Cmd;
+  void adjust(tooling::CompileCommand &Cmd,
+  llvm::StringRef File) const override {
+if (Cmd.CommandLine.empty())
+  return;
 
 llvm::StringRef Lang;
-for (size_t I = 0, E = Cmd->CommandLine.size(); I < E; ++I) {
- 

[PATCH] D133756: [clangd] Introduce CompileCommandsAdjuster

[Nathan Ridge via Phabricator via cfe-commits]

nridge added a comment.
Herald added a subscriber: ormris.

This is a refactoring in preparation for D133757 
, please see that for motivation


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133756/new/

https://reviews.llvm.org/D133756

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

[PATCH] D133757: [clangd] Turn QueryDriverDatabase into a CompileCommandsAdjuster

[Nathan Ridge via Phabricator via cfe-commits]

nridge added a comment.

Depends on https://reviews.llvm.org/D133756


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133757/new/

https://reviews.llvm.org/D133757

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

[PATCH] D133757: [clangd] Turn QueryDriverDatabase into a CompileCommandsAdjuster

[Nathan Ridge via Phabricator via cfe-commits]

nridge added a comment.

So far I've only written a test for 
https://github.com/clangd/clangd/issues/1089.

I plan to add tests for the other two issues as well, but I thought I'd get the 
review ball rolling in the mean time to get feedback on the fix approach and 
test approach.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133757/new/

https://reviews.llvm.org/D133757

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

[PATCH] D133757: [clangd] Turn QueryDriverDatabase into a CompileCommandsAdjuster

[Nathan Ridge via Phabricator via cfe-commits]

nridge added inline comments.



Comment at: clang-tools-extra/clangd/unittests/ClangdLSPServerTests.cpp:242
+CompileFlags:
+  Compiler: gcc
+  )yaml";

To exercise `QueryDriverDatabase`, this test assumes that the machine running 
the test will have a `gcc` somewhere in its path, and that querying it for 
includes will result in at least one `-isystem` flag being added to the command 
line.

Is this a reasonable assumption for buildbots? Or do we need to introduce some 
kind of abstraction so that the test doesn't actually try to find and execute 
gcc?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133757/new/

https://reviews.llvm.org/D133757

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

[PATCH] D133647: [clang-format] Parse the else part of `#if 0`

[Owen Pan via Phabricator via cfe-commits]

owenpan accepted this revision.
owenpan added a comment.
This revision is now accepted and ready to land.

Thanks!




Comment at: clang/lib/Format/UnwrappedLineParser.cpp:1128
+// If the first branch is unreachable, set the BranchIndex to 1.  This way
+// the next branch it will be parsed if there is one.
+PPLevelBranchIndex.push_back(Unreachable ? 1 : 0);




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133647/new/

https://reviews.llvm.org/D133647

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

[clang] bf3efa8 - [clang][Interp] Handle DeclRefExpr of reference types

[Timm Bäder via cfe-commits]

Author: Timm Bäder
Date: 2022-09-13T10:40:51+02:00
New Revision: bf3efa8b1622080b29b2dc4ba57bdccd0ca1e889

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

LOG: [clang][Interp] Handle DeclRefExpr of reference types

References are implemented through pointers, so we need a second deref
when encountering a DeclRefExpr of a reference type.

Differential Revision: https://reviews.llvm.org/D132997

Added: 
clang/test/AST/Interp/references.cpp

Modified: 
clang/lib/AST/Interp/ByteCodeExprGen.cpp
clang/test/AST/Interp/arrays.cpp

Removed: 




diff  --git a/clang/lib/AST/Interp/ByteCodeExprGen.cpp 
b/clang/lib/AST/Interp/ByteCodeExprGen.cpp
index 790f58f67e68..0abd3ff73674 100644
--- a/clang/lib/AST/Interp/ByteCodeExprGen.cpp
+++ b/clang/lib/AST/Interp/ByteCodeExprGen.cpp
@@ -814,15 +814,38 @@ bool ByteCodeExprGen::VisitUnaryOperator(const 
UnaryOperator *E) {
 template 
 bool ByteCodeExprGen::VisitDeclRefExpr(const DeclRefExpr *E) {
   const auto *Decl = E->getDecl();
+  bool IsReference = Decl->getType()->isReferenceType();
+  bool FoundDecl = false;
 
   if (auto It = Locals.find(Decl); It != Locals.end()) {
 const unsigned Offset = It->second.Offset;
-return this->emitGetPtrLocal(Offset, E);
+if (!this->emitGetPtrLocal(Offset, E))
+  return false;
+
+FoundDecl = true;
   } else if (auto GlobalIndex = P.getGlobal(Decl)) {
-return this->emitGetPtrGlobal(*GlobalIndex, E);
+if (!this->emitGetPtrGlobal(*GlobalIndex, E))
+  return false;
+
+FoundDecl = true;
   } else if (const auto *PVD = dyn_cast(Decl)) {
-if (auto It = this->Params.find(PVD); It != this->Params.end())
-  return this->emitGetPtrParam(It->second, E);
+if (auto It = this->Params.find(PVD); It != this->Params.end()) {
+  if (!this->emitGetPtrParam(It->second, E))
+return false;
+
+  FoundDecl = true;
+}
+  }
+
+  // References are implemented using pointers, so when we get here,
+  // we have a pointer to a pointer, which we need to de-reference once.
+  if (FoundDecl) {
+if (IsReference) {
+  if (!this->emitLoadPopPtr(E))
+return false;
+}
+
+return true;
   }
 
   return false;

diff  --git a/clang/test/AST/Interp/arrays.cpp 
b/clang/test/AST/Interp/arrays.cpp
index 88bb0a8eadb5..302c8b2a86cc 100644
--- a/clang/test/AST/Interp/arrays.cpp
+++ b/clang/test/AST/Interp/arrays.cpp
@@ -45,6 +45,13 @@ constexpr T getElementOf(T* array, int i) {
 static_assert(getElementOf(foo[0], 1) == &m, "");
 
 
+template 
+constexpr T& getElementOfArray(T (&array)[N], int I) {
+  return array[I];
+}
+static_assert(getElementOfArray(foo[2], 3) == &m, "");
+
+
 constexpr int data[] = {5, 4, 3, 2, 1};
 static_assert(data[0] == 4, ""); // expected-error{{failed}} \
  // expected-note{{5 == 4}} \

diff  --git a/clang/test/AST/Interp/references.cpp 
b/clang/test/AST/Interp/references.cpp
new file mode 100644
index ..61d4d91e4224
--- /dev/null
+++ b/clang/test/AST/Interp/references.cpp
@@ -0,0 +1,91 @@
+// RUN: %clang_cc1 -fexperimental-new-constant-interpreter -verify %s
+// RUN: %clang_cc1 -verify=ref %s
+
+
+// ref-no-diagnostics
+
+constexpr int a = 10;
+constexpr const int &b = a;
+static_assert(a == b, "");
+
+constexpr int assignToReference() {
+  int a = 20;
+  int &b = a;
+
+  b = 100;
+  return a;
+}
+static_assert(assignToReference() == 100, "");
+
+
+constexpr void setValue(int &dest, int val) {
+  dest = val;
+}
+
+constexpr int checkSetValue() {
+  int l = 100;
+  setValue(l, 200);
+  return l;
+}
+static_assert(checkSetValue() == 200, "");
+
+constexpr int readLocalRef() {
+  int a = 20;
+  int &b = a;
+  return b;
+}
+static_assert(readLocalRef() == 20, "");
+
+constexpr int incRef() {
+  int a = 0;
+  int &b = a;
+
+  b = b + 1;
+
+  return a;
+}
+static_assert(incRef() == 1, "");
+
+
+template
+constexpr void Plus3(int &A) {
+  A = V + 3;
+}
+constexpr int foo = 4;
+
+constexpr int callTemplate() {
+  int a = 3;
+  Plus3(a);
+  return a;
+}
+static_assert(callTemplate() == 7, "");
+
+
+constexpr int& getValue(int *array, int index) {
+  return array[index];
+}
+constexpr int testGetValue() {
+  int values[] = {1, 2, 3, 4};
+  getValue(values, 2) = 30;
+  return values[2];
+}
+static_assert(testGetValue() == 30, "");
+
+// FIXME: ExprWithCleanups + MaterializeTemporaryExpr not implemented
+constexpr const int &MCE = 1; // expected-error{{must be initialized by a 
constant expression}}
+
+
+struct S {
+  int i, j;
+};
+
+constexpr int RefToMemberExpr() {
+  S s{1, 2};
+
+  int &j = s.i;
+  j += 10;
+
+  return j;
+}
+// FIXME: Should be accepted.
+static_assert(RefToMemberExpr() == 11, ""); // expected-error{{not an integral 
constant expression}}



_

[clang] 9b087a7 - [clang][Interp][NFC] Forward-declare Pointer in PrimType header

[Timm Bäder via cfe-commits]

Author: Timm Bäder
Date: 2022-09-13T10:40:52+02:00
New Revision: 9b087a70e66c785f64279634c536a848e78261ea

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

LOG: [clang][Interp][NFC] Forward-declare Pointer in PrimType header

No need to include the full Pointer.h here.

Added: 


Modified: 
clang/lib/AST/Interp/PrimType.cpp
clang/lib/AST/Interp/PrimType.h

Removed: 




diff  --git a/clang/lib/AST/Interp/PrimType.cpp 
b/clang/lib/AST/Interp/PrimType.cpp
index 082bfaf3c207..bd0f73df2ead 100644
--- a/clang/lib/AST/Interp/PrimType.cpp
+++ b/clang/lib/AST/Interp/PrimType.cpp
@@ -7,6 +7,7 @@
 
//===--===//
 
 #include "PrimType.h"
+#include "Pointer.h"
 
 using namespace clang;
 using namespace clang::interp;

diff  --git a/clang/lib/AST/Interp/PrimType.h b/clang/lib/AST/Interp/PrimType.h
index de4bf9bf802e..8490c1f6548a 100644
--- a/clang/lib/AST/Interp/PrimType.h
+++ b/clang/lib/AST/Interp/PrimType.h
@@ -18,11 +18,12 @@
 #include 
 #include "Boolean.h"
 #include "Integral.h"
-#include "Pointer.h"
 
 namespace clang {
 namespace interp {
 
+class Pointer;
+
 /// Enumeration of the primitive types of the VM.
 enum PrimType : unsigned {
   PT_Sint8,



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

[clang] f756ddb - [clang][Interp][NFC] InterpFrame: localBlock() can be const

[Timm Bäder via cfe-commits]

Author: Timm Bäder
Date: 2022-09-13T10:41:18+02:00
New Revision: f756ddba17c9f0f0ee49b45dd4b15b487aff9b67

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

LOG: [clang][Interp][NFC] InterpFrame: localBlock() can be const

Added: 


Modified: 
clang/lib/AST/Interp/InterpFrame.h

Removed: 




diff  --git a/clang/lib/AST/Interp/InterpFrame.h 
b/clang/lib/AST/Interp/InterpFrame.h
index 3769c9a5f5f1..ca9803d48dd1 100644
--- a/clang/lib/AST/Interp/InterpFrame.h
+++ b/clang/lib/AST/Interp/InterpFrame.h
@@ -123,7 +123,7 @@ class InterpFrame final : public Frame {
   }
 
   /// Returns a pointer to a local's block.
-  void *localBlock(unsigned Offset) {
+  void *localBlock(unsigned Offset) const {
 return Locals.get() + Offset - sizeof(Block);
   }
 



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

[clang] 5d24514 - [clang][Interp][NFC] InterpFrame::getLocal() can be const

[Timm Bäder via cfe-commits]

Author: Timm Bäder
Date: 2022-09-13T10:41:24+02:00
New Revision: 5d2451468c5f105bd7837f57c5e385fbbbdb65a4

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

LOG: [clang][Interp][NFC] InterpFrame::getLocal() can be const

Make localRef() const and use that.

Added: 


Modified: 
clang/lib/AST/Interp/InterpFrame.h

Removed: 




diff  --git a/clang/lib/AST/Interp/InterpFrame.h 
b/clang/lib/AST/Interp/InterpFrame.h
index ca9803d48dd1..88b4a5af8e5a 100644
--- a/clang/lib/AST/Interp/InterpFrame.h
+++ b/clang/lib/AST/Interp/InterpFrame.h
@@ -63,7 +63,7 @@ class InterpFrame final : public Frame {
   size_t getFrameOffset() const { return FrameOffset; }
 
   /// Returns the value of a local variable.
-  template  const T &getLocal(unsigned Offset) {
+  template  const T &getLocal(unsigned Offset) const {
 return localRef(Offset);
   }
 
@@ -118,7 +118,7 @@ class InterpFrame final : public Frame {
   }
 
   /// Returns an offset to a local.
-  template  T &localRef(unsigned Offset) {
+  template  T &localRef(unsigned Offset) const {
 return *reinterpret_cast(Locals.get() + Offset);
   }
 



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

[PATCH] D132997: [clang][Interp] Handle DeclRefExpr of reference types

[Timm Bäder via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGbf3efa8b1622: [clang][Interp] Handle DeclRefExpr of 
reference types (authored by tbaeder).

Changed prior to commit:
  https://reviews.llvm.org/D132997?vs=458662&id=459681#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D132997/new/

https://reviews.llvm.org/D132997

Files:
  clang/lib/AST/Interp/ByteCodeExprGen.cpp
  clang/test/AST/Interp/arrays.cpp
  clang/test/AST/Interp/references.cpp

Index: clang/test/AST/Interp/references.cpp
===
--- /dev/null
+++ clang/test/AST/Interp/references.cpp
@@ -0,0 +1,91 @@
+// RUN: %clang_cc1 -fexperimental-new-constant-interpreter -verify %s
+// RUN: %clang_cc1 -verify=ref %s
+
+
+// ref-no-diagnostics
+
+constexpr int a = 10;
+constexpr const int &b = a;
+static_assert(a == b, "");
+
+constexpr int assignToReference() {
+  int a = 20;
+  int &b = a;
+
+  b = 100;
+  return a;
+}
+static_assert(assignToReference() == 100, "");
+
+
+constexpr void setValue(int &dest, int val) {
+  dest = val;
+}
+
+constexpr int checkSetValue() {
+  int l = 100;
+  setValue(l, 200);
+  return l;
+}
+static_assert(checkSetValue() == 200, "");
+
+constexpr int readLocalRef() {
+  int a = 20;
+  int &b = a;
+  return b;
+}
+static_assert(readLocalRef() == 20, "");
+
+constexpr int incRef() {
+  int a = 0;
+  int &b = a;
+
+  b = b + 1;
+
+  return a;
+}
+static_assert(incRef() == 1, "");
+
+
+template
+constexpr void Plus3(int &A) {
+  A = V + 3;
+}
+constexpr int foo = 4;
+
+constexpr int callTemplate() {
+  int a = 3;
+  Plus3(a);
+  return a;
+}
+static_assert(callTemplate() == 7, "");
+
+
+constexpr int& getValue(int *array, int index) {
+  return array[index];
+}
+constexpr int testGetValue() {
+  int values[] = {1, 2, 3, 4};
+  getValue(values, 2) = 30;
+  return values[2];
+}
+static_assert(testGetValue() == 30, "");
+
+// FIXME: ExprWithCleanups + MaterializeTemporaryExpr not implemented
+constexpr const int &MCE = 1; // expected-error{{must be initialized by a constant expression}}
+
+
+struct S {
+  int i, j;
+};
+
+constexpr int RefToMemberExpr() {
+  S s{1, 2};
+
+  int &j = s.i;
+  j += 10;
+
+  return j;
+}
+// FIXME: Should be accepted.
+static_assert(RefToMemberExpr() == 11, ""); // expected-error{{not an integral constant expression}}
Index: clang/test/AST/Interp/arrays.cpp
===
--- clang/test/AST/Interp/arrays.cpp
+++ clang/test/AST/Interp/arrays.cpp
@@ -45,6 +45,13 @@
 static_assert(getElementOf(foo[0], 1) == &m, "");
 
 
+template 
+constexpr T& getElementOfArray(T (&array)[N], int I) {
+  return array[I];
+}
+static_assert(getElementOfArray(foo[2], 3) == &m, "");
+
+
 constexpr int data[] = {5, 4, 3, 2, 1};
 static_assert(data[0] == 4, ""); // expected-error{{failed}} \
  // expected-note{{5 == 4}} \
Index: clang/lib/AST/Interp/ByteCodeExprGen.cpp
===
--- clang/lib/AST/Interp/ByteCodeExprGen.cpp
+++ clang/lib/AST/Interp/ByteCodeExprGen.cpp
@@ -814,15 +814,38 @@
 template 
 bool ByteCodeExprGen::VisitDeclRefExpr(const DeclRefExpr *E) {
   const auto *Decl = E->getDecl();
+  bool IsReference = Decl->getType()->isReferenceType();
+  bool FoundDecl = false;
 
   if (auto It = Locals.find(Decl); It != Locals.end()) {
 const unsigned Offset = It->second.Offset;
-return this->emitGetPtrLocal(Offset, E);
+if (!this->emitGetPtrLocal(Offset, E))
+  return false;
+
+FoundDecl = true;
   } else if (auto GlobalIndex = P.getGlobal(Decl)) {
-return this->emitGetPtrGlobal(*GlobalIndex, E);
+if (!this->emitGetPtrGlobal(*GlobalIndex, E))
+  return false;
+
+FoundDecl = true;
   } else if (const auto *PVD = dyn_cast(Decl)) {
-if (auto It = this->Params.find(PVD); It != this->Params.end())
-  return this->emitGetPtrParam(It->second, E);
+if (auto It = this->Params.find(PVD); It != this->Params.end()) {
+  if (!this->emitGetPtrParam(It->second, E))
+return false;
+
+  FoundDecl = true;
+}
+  }
+
+  // References are implemented using pointers, so when we get here,
+  // we have a pointer to a pointer, which we need to de-reference once.
+  if (FoundDecl) {
+if (IsReference) {
+  if (!this->emitLoadPopPtr(E))
+return false;
+}
+
+return true;
   }
 
   return false;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 53d8687 - [clang][Interp][NFC] Use constexpr if in OffsetHelper

[Timm Bäder via cfe-commits]

Author: Timm Bäder
Date: 2022-09-13T10:41:34+02:00
New Revision: 53d8687a13e76b5a387e8df59ae231ab53ab9279

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

LOG: [clang][Interp][NFC] Use constexpr if in OffsetHelper

Add is a template parameter, so we can use constexpr if here.

Added: 


Modified: 
clang/lib/AST/Interp/Interp.h

Removed: 




diff  --git a/clang/lib/AST/Interp/Interp.h b/clang/lib/AST/Interp/Interp.h
index 0a5c8dc847c3..5c96cd8d2340 100644
--- a/clang/lib/AST/Interp/Interp.h
+++ b/clang/lib/AST/Interp/Interp.h
@@ -788,18 +788,24 @@ template  bool 
OffsetHelper(InterpState &S, CodePtr OpPC) {
 return false;
   };
 
-  // If the new offset would be negative, bail out.
-  if (Add && Offset.isNegative() && (Offset.isMin() || -Offset > Index))
-return InvalidOffset();
-  if (!Add && Offset.isPositive() && Index < Offset)
-return InvalidOffset();
-
-  // If the new offset would be out of bounds, bail out.
   unsigned MaxOffset = MaxIndex - Ptr.getIndex();
-  if (Add && Offset.isPositive() && Offset > MaxOffset)
-return InvalidOffset();
-  if (!Add && Offset.isNegative() && (Offset.isMin() || -Offset > MaxOffset))
-return InvalidOffset();
+  if constexpr (Add) {
+// If the new offset would be negative, bail out.
+if (Offset.isNegative() && (Offset.isMin() || -Offset > Index))
+  return InvalidOffset();
+
+// If the new offset would be out of bounds, bail out.
+if (Offset.isPositive() && Offset > MaxOffset)
+  return InvalidOffset();
+  } else {
+// If the new offset would be negative, bail out.
+if (Offset.isPositive() && Index < Offset)
+  return InvalidOffset();
+
+// If the new offset would be out of bounds, bail out.
+if (Offset.isNegative() && (Offset.isMin() || -Offset > MaxOffset))
+  return InvalidOffset();
+  }
 
   // Offset is valid - compute it on unsigned.
   int64_t WideIndex = static_cast(Index);



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

[clang] b02f689 - [clang][Interp][NFC] InterpFrame::getParam can be const

[Timm Bäder via cfe-commits]

Author: Timm Bäder
Date: 2022-09-13T10:41:28+02:00
New Revision: b02f6890f52a48de6fc3a1d977a6ae50bc8fa984

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

LOG: [clang][Interp][NFC] InterpFrame::getParam can be const

Make stackRef() const as well and use that.

Added: 


Modified: 
clang/lib/AST/Interp/InterpFrame.h

Removed: 




diff  --git a/clang/lib/AST/Interp/InterpFrame.h 
b/clang/lib/AST/Interp/InterpFrame.h
index 88b4a5af8e5a..16d073c8c3a0 100644
--- a/clang/lib/AST/Interp/InterpFrame.h
+++ b/clang/lib/AST/Interp/InterpFrame.h
@@ -76,7 +76,7 @@ class InterpFrame final : public Frame {
   Pointer getLocalPointer(unsigned Offset);
 
   /// Returns the value of an argument.
-  template  const T &getParam(unsigned Offset) {
+  template  const T &getParam(unsigned Offset) const {
 auto Pt = Params.find(Offset);
 if (Pt == Params.end()) {
   return stackRef(Offset);
@@ -112,7 +112,7 @@ class InterpFrame final : public Frame {
 
 private:
   /// Returns an original argument from the stack.
-  template  const T &stackRef(unsigned Offset) {
+  template  const T &stackRef(unsigned Offset) const {
 assert(Args);
 return *reinterpret_cast(Args - ArgSize + Offset);
   }



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

[clang] cd20a18 - Revert "[clang, llvm] Add __declspec(safebuffers), support it in CodeView"

[Sylvestre Ledru via cfe-commits]

Author: Sylvestre Ledru
Date: 2022-09-13T10:53:59+02:00
New Revision: cd20a1828605887699579789b5433111d5bc0319

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

LOG: Revert "[clang, llvm] Add __declspec(safebuffers), support it in CodeView"

Causing:
https://github.com/llvm/llvm-project/issues/57709

This reverts commit ab56719acd98778fb2e48fa425ac7c8d27bdea86.

Added: 


Modified: 
clang/include/clang/Basic/Attr.td
clang/include/clang/Basic/AttrDocs.td
clang/lib/CodeGen/CodeGenModule.cpp
clang/test/Parser/MicrosoftExtensions.c
llvm/include/llvm/BinaryFormat/COFF.h
llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
llvm/lib/Target/X86/X86AsmPrinter.cpp
llvm/test/DebugInfo/COFF/frameproc-flags.ll
llvm/test/DebugInfo/COFF/multifunction.ll
llvm/test/DebugInfo/COFF/simple.ll
llvm/test/DebugInfo/COFF/vframe-fpo.ll

Removed: 




diff  --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index af0e08654014..0ad59b2c153a 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -2080,19 +2080,12 @@ def NotTailCalled : InheritableAttr {
 def : MutualExclusions<[AlwaysInline, NotTailCalled]>;
 
 def NoStackProtector : InheritableAttr {
-  let Spellings = [Clang<"no_stack_protector">, Declspec<"safebuffers">];
+  let Spellings = [Clang<"no_stack_protector">];
   let Subjects = SubjectList<[Function]>;
   let Documentation = [NoStackProtectorDocs];
   let SimpleHandler = 1;
 }
 
-def StrictGuardStackCheck : InheritableAttr {
-  let Spellings = [Declspec<"strict_gs_check">];
-  let Subjects = SubjectList<[Function]>;
-  let Documentation = [StrictGuardStackCheckDocs];
-  let SimpleHandler = 1;
-}
-
 def NoThrow : InheritableAttr {
   let Spellings = [GCC<"nothrow">, Declspec<"nothrow">];
   let Subjects = SubjectList<[FunctionLike]>;

diff  --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index b6c15c92d581..68f1268ed7da 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -4453,8 +4453,7 @@ spelled "XYZ" in the `OpenMP 5.1 Standard`_).
 def NoStackProtectorDocs : Documentation {
   let Category = DocCatFunction;
   let Content = [{
-Clang supports the ``__attribute__((no_stack_protector))`` and Microsoft style
-``__declspec(safebuffers)`` attribute which disables
+Clang supports the ``__attribute__((no_stack_protector))`` attribute which 
disables
 the stack protector on the specified function. This attribute is useful for
 selectively disabling the stack protector on some functions when building with
 ``-fstack-protector`` compiler option.
@@ -4473,27 +4472,6 @@ option.
 }];
 }
 
-def StrictGuardStackCheckDocs : Documentation {
-  let Category = DocCatFunction;
-  let Content = [{
-Clang supports the Microsoft style ``__declspec((strict_gs_check))`` attribute
-which upgrades the stack protector check from ``-fstack-protector`` to
-``-fstack-protector-strong``.
-
-For example, it upgrades the stack protector for the function ``foo`` to
-``-fstack-protector-strong`` but function ``bar`` will still be built with the
-stack protector with the ``-fstack-protector`` option.
-
-.. code-block:: c
-
-__declspec((strict_gs_check))
-int foo(int x); // stack protection will be upgraded for foo.
-
-int bar(int y); // bar can be built with the standard stack protector 
checks.
-
-}];
-}
-
 def NotTailCalledDocs : Documentation {
   let Category = DocCatFunction;
   let Content = [{

diff  --git a/clang/lib/CodeGen/CodeGenModule.cpp 
b/clang/lib/CodeGen/CodeGenModule.cpp
index bbd42956a4b0..9edd618d359b 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -1970,17 +1970,14 @@ void 
CodeGenModule::SetLLVMFunctionAttributesForDefinition(const Decl *D,
   if (!hasUnwindExceptions(LangOpts))
 B.addAttribute(llvm::Attribute::NoUnwind);
 
-  if (D && D->hasAttr())
-; // Do nothing.
-  else if (D && D->hasAttr() &&
-   LangOpts.getStackProtector() == LangOptions::SSPOn)
-B.addAttribute(llvm::Attribute::StackProtectStrong);
-  else if (LangOpts.getStackProtector() == LangOptions::SSPOn)
-B.addAttribute(llvm::Attribute::StackProtect);
-  else if (LangOpts.getStackProtector() == LangOptions::SSPStrong)
-B.addAttribute(llvm::Attribute::StackProtectStrong);
-  else if (LangOpts.getStackProtector() == LangOptions::SSPReq)
-B.addAttribute(llvm::Attribute::StackProtectReq);
+  if (!D || !D->hasAttr()) {
+if (LangOpts.getStackProtector() == LangOptions::SSPOn)
+  B.addAttribute(llvm::Attribute::StackProtect);
+else if (LangOpts.getStackProtector() == LangOptions::SSPStrong)
+  B.addAttribu

[clang] 5a7764c - [OpenCL] Guard depth image builtins

[Sven van Haastregt via cfe-commits]

Author: Sven van Haastregt
Date: 2022-09-13T10:10:48+01:00
New Revision: 5a7764c9ff5db8c460b52bc2dec95d19df44d4c8

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

LOG: [OpenCL] Guard depth image builtins

Ensure any uses of `image2d_depth_t` and `image2d_array_depth_t` are
guarded behind the `cl_khr_depth_images` extension in
`OpenCLBuiltins.td`.

Fix a few missing guards in `opencl-c.h`.

Added: 


Modified: 
clang/lib/Headers/opencl-c.h
clang/lib/Sema/OpenCLBuiltins.td

Removed: 




diff  --git a/clang/lib/Headers/opencl-c.h b/clang/lib/Headers/opencl-c.h
index 8499ee0120da..2afe0231cd74 100644
--- a/clang/lib/Headers/opencl-c.h
+++ b/clang/lib/Headers/opencl-c.h
@@ -15257,13 +15257,17 @@ float4 __ovld __purefn read_imagef(read_only 
image2d_t, sampler_t, float2, float
 int4 __ovld __purefn read_imagei(read_only image2d_t, sampler_t, float2, 
float);
 uint4 __ovld __purefn read_imageui(read_only image2d_t, sampler_t, float2, 
float);
 
+#ifdef cl_khr_depth_images
 float __ovld __purefn read_imagef(read_only image2d_depth_t, sampler_t, 
float2, float);
+#endif // cl_khr_depth_images
 
 float4 __ovld __purefn read_imagef(read_only image2d_array_t, sampler_t, 
float4, float);
 int4 __ovld __purefn read_imagei(read_only image2d_array_t, sampler_t, float4, 
float);
 uint4 __ovld __purefn read_imageui(read_only image2d_array_t, sampler_t, 
float4, float);
 
+#ifdef cl_khr_depth_images
 float __ovld __purefn read_imagef(read_only image2d_array_depth_t, sampler_t, 
float4, float);
+#endif // cl_khr_depth_images
 
 float4 __ovld __purefn read_imagef(read_only image3d_t, sampler_t, float4, 
float);
 int4 __ovld __purefn read_imagei(read_only image3d_t, sampler_t, float4, 
float);
@@ -15281,13 +15285,17 @@ float4 __ovld __purefn read_imagef(read_only 
image2d_t, sampler_t, float2, float
 int4 __ovld __purefn read_imagei(read_only image2d_t, sampler_t, float2, 
float2, float2);
 uint4 __ovld __purefn read_imageui(read_only image2d_t, sampler_t, float2, 
float2, float2);
 
+#ifdef cl_khr_depth_images
 float __ovld __purefn read_imagef(read_only image2d_depth_t, sampler_t, 
float2, float2, float2);
+#endif // cl_khr_depth_images
 
 float4 __ovld __purefn read_imagef(read_only image2d_array_t, sampler_t, 
float4, float2, float2);
 int4 __ovld __purefn read_imagei(read_only image2d_array_t, sampler_t, float4, 
float2, float2);
 uint4 __ovld __purefn read_imageui(read_only image2d_array_t, sampler_t, 
float4, float2, float2);
 
+#ifdef cl_khr_depth_images
 float __ovld __purefn read_imagef(read_only image2d_array_depth_t, sampler_t, 
float4, float2, float2);
+#endif // cl_khr_depth_images
 
 float4 __ovld __purefn read_imagef(read_only image3d_t, sampler_t, float4, 
float4, float4);
 int4 __ovld __purefn read_imagei(read_only image3d_t, sampler_t, float4, 
float4, float4);
@@ -15829,19 +15837,25 @@ int __ovld get_image_num_mip_levels(read_write 
image3d_t);
 
 int __ovld get_image_num_mip_levels(read_only image1d_array_t);
 int __ovld get_image_num_mip_levels(read_only image2d_array_t);
+#ifdef cl_khr_depth_images
 int __ovld get_image_num_mip_levels(read_only image2d_array_depth_t);
 int __ovld get_image_num_mip_levels(read_only image2d_depth_t);
+#endif // cl_khr_depth_images
 
 int __ovld get_image_num_mip_levels(write_only image1d_array_t);
 int __ovld get_image_num_mip_levels(write_only image2d_array_t);
+#ifdef cl_khr_depth_images
 int __ovld get_image_num_mip_levels(write_only image2d_array_depth_t);
 int __ovld get_image_num_mip_levels(write_only image2d_depth_t);
+#endif // cl_khr_depth_images
 
 #if defined(__opencl_c_read_write_images)
 int __ovld get_image_num_mip_levels(read_write image1d_array_t);
 int __ovld get_image_num_mip_levels(read_write image2d_array_t);
+#ifdef cl_khr_depth_images
 int __ovld get_image_num_mip_levels(read_write image2d_array_depth_t);
 int __ovld get_image_num_mip_levels(read_write image2d_depth_t);
+#endif // cl_khr_depth_images
 #endif //defined(__opencl_c_read_write_images)
 
 #endif //cl_khr_mipmap_image

diff  --git a/clang/lib/Sema/OpenCLBuiltins.td 
b/clang/lib/Sema/OpenCLBuiltins.td
index dc158454556a..0cceba090bd8 100644
--- a/clang/lib/Sema/OpenCLBuiltins.td
+++ b/clang/lib/Sema/OpenCLBuiltins.td
@@ -246,6 +246,7 @@ class ImageType :
   let Extension = !cond(
   !and(!eq(_Ty.Name, "image3d_t"), !eq(_AccessQualifier, "WO")) : 
TypeExtension<"cl_khr_3d_image_writes">,
   !and(!eq(_Ty.Name, "image3d_t"), !eq(_AccessQualifier, "RW")) : 
TypeExtension<"cl_khr_3d_image_writes __opencl_c_read_write_images">,
+  !or(!eq(_Ty.Name, "image2d_depth_t"), !eq(_Ty.Name, 
"image2d_array_depth_t")) : TypeExtension<"cl_khr_depth_images">,
   !eq(_AccessQualifier, "RW") : 
TypeExtension<"__opencl_c_read_write_images">,
   true : _Ty.Ext

[PATCH] D102494: [Clang, Driver] Default to Darwin_libsystem_m veclib on iOS based targets.

[Florian Hahn via Phabricator via cfe-commits]

fhahn abandoned this revision.
fhahn added a comment.
Herald added a subscriber: MaskRay.
Herald added a project: All.

As of now, I don't think this is safe to do with the precision guarantees 
Darwin_libsystem_m provides unfortunately.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D102494/new/

https://reviews.llvm.org/D102494

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

[PATCH] D133737: [HLSL] [clang] Add vector version of abs for HLSL

[Florian Hahn via Phabricator via cfe-commits]

fhahn added a comment.

I'm not familiar with HLSL but I think making use of the existing vector 
builtins makes sense here!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133737/new/

https://reviews.llvm.org/D133737

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

[PATCH] D133764: Honor cgroup limitation when running in parallel

[Denis Silakov via Phabricator via cfe-commits]

dsilakov created this revision.
dsilakov added a reviewer: steakhal.
dsilakov added a project: clang.
Herald added a subscriber: whisperity.
Herald added a reviewer: NoQ.
Herald added a project: All.
dsilakov requested review of this revision.
Herald added a subscriber: cfe-commits.

cpu.cfs_quota_us and cpu.cfs_period_us limit CPU resources and used
by container management systems such as  Kubernetes to limit CPU
time consumed by containers.

In particular, for Docker one can set '--cpus' option to mimic limitation
of CPU cores. In practice, '--cpus' is the equivalent of setting corresponding
--cpu-period and --cpu-quota.

Python doesn't take such limitations into account when running inside
container. See https://bugs.python.org/issue36054 - os.cpu_count() still
returns number of host CPU cores. As a result, all routines that use this
function to get CPU count, ignore container limitations.

For us this means that number of processes created multiprocessing.Pool()
inside run_analyzer_parallel() is equal to the number of host CPU cores.
This can become a problem if we are running on a powerfull server with
many containers.

Since the fix for Python doesn' seem to come in the near future, we
calculate limitations by ourselves in this function and provide
necessary argument to the multiprocessing.Pool()

Besides cfs_quota_us, the process can be limited by sched_affinity.
In this path, we take this into account as well, and choose the minimal
of two limits if both are set.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133764

Files:
  clang/tools/scan-build-py/lib/libscanbuild/analyze.py


Index: clang/tools/scan-build-py/lib/libscanbuild/analyze.py
===
--- clang/tools/scan-build-py/lib/libscanbuild/analyze.py
+++ clang/tools/scan-build-py/lib/libscanbuild/analyze.py
@@ -24,6 +24,7 @@
 import shutil
 import glob
 from collections import defaultdict
+from pathlib import Path
 
 from libscanbuild import command_entry_point, compiler_wrapper, \
 wrapper_environment, run_build, run_command, CtuConfig
@@ -91,6 +92,74 @@
 return number_of_bugs if args.status_bugs else 0
 
 
+def _query_cpu():
+""" Honor cpu.cfs_quota_us when running under cgroups limitations
+
+cpu.cfs_quota_us and cpu.cfs_period_us limit CPU resources and used
+by container management systems such as  Kubernetes to limit CPU
+time consumed by containers.
+
+In particular, for Docker one can set '--cpus' option to mimic limitation
+of CPU cores. In practice, '--cpus' is the equivalent of setting 
corresponding
+--cpu-period and --cpu-quota.
+
+Python doesn't take such limitations into account when running inside
+container. See https://bugs.python.org/issue36054 - os.cpu_count() still
+returns number of host CPU cores. As a result, all routines that use this
+function to get CPU count, ignore container limitations.
+
+For us this means that number of processes created multiprocessing.Pool()
+inside run_analyzer_parallel() is equal to the number of host CPU cores.
+This can become a problem if we are running on a powerfull server with
+many containers.
+
+Since the fix for Python doesn' seem to come in the near future, we
+calculate limitations by ourselves in this function and provide
+necessary argument to the multiprocessing.Pool()
+"""
+cpu_quota, avail_cpu = None, None
+
+if Path("/sys/fs/cgroup/cpu/cpu.cfs_quota_us").is_file():
+with open("/sys/fs/cgroup/cpu/cpu.cfs_quota_us", encoding="utf-8") as 
file:
+cpu_quota = int(file.read().rstrip())
+
+if (
+cpu_quota
+and cpu_quota != -1
+and Path("/sys/fs/cgroup/cpu/cpu.cfs_period_us").is_file()
+):
+with open("/sys/fs/cgroup/cpu/cpu.cfs_period_us", encoding="utf-8") as 
file:
+cpu_period = int(file.read().rstrip())
+# Divide quota by period and you should get num of allotted CPU to the 
container, rounded down if fractional.
+avail_cpu = int(cpu_quota / cpu_period)
+# Calculated limit can become zero after rounding
+if avail_cpu == 0:
+avail_cpu = 1
+
+return avail_cpu
+
+
+def _cpu_count():
+"""Use sched_affinity if available for virtualized or containerized
+environments.
+"""
+cpu_share = _query_cpu()
+cpu_count = None
+sched_getaffinity = getattr(os, "sched_getaffinity", None)
+
+# pylint: disable=not-callable,using-constant-test,useless-suppression
+if sched_getaffinity:
+cpu_count = len(sched_getaffinity(0))
+elif multiprocessing:
+cpu_count = multiprocessing.cpu_count()
+else:
+cpu_count = 1
+
+if cpu_share is not None:
+return min(cpu_share, cpu_count)
+return cpu_count
+
+
 def need_analyzer(args):
 """ Check the intent of the build command.
 
@@ -235,7 +304,7 @@
  for cmd in json.load(hand

[PATCH] D133578: [OpenMP] Add generation of SIMD align assumptions to OMPIRBuilder

[Dominik Adamski via Phabricator via cfe-commits]

domada updated this revision to Diff 459697.
domada added a comment.

Applied review remarks. Scope of changes:

1. replaced ArrayRef AlignedVars, Value * Alignment arguments with 
DenseMap. It allows to generate different alignment assumption for different 
variables. OpenMP allows to specify multiple `aligned` clauses for single SIMD 
construct.
2. modified calculation of default alignment. Use pointer ABI alignment as the 
default one.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133578/new/

https://reviews.llvm.org/D133578

Files:
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
  llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
  llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
  mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp

Index: mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
===
--- mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
+++ mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
@@ -994,9 +994,9 @@
   llvm::ConstantInt *safelen = nullptr;
   if (llvm::Optional safelenVar = loop.safelen())
 safelen = builder.getInt64(safelenVar.value());
-
+  llvm::DenseMap AlignedVars;
   ompBuilder->applySimd(
-  loopInfo,
+  loopInfo, AlignedVars,
   loop.if_expr() ? moduleTranslation.lookupValue(loop.if_expr()) : nullptr,
   simdlen, safelen);
 
Index: llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
===
--- llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
+++ llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
@@ -1767,11 +1767,59 @@
 
 TEST_F(OpenMPIRBuilderTest, ApplySimd) {
   OpenMPIRBuilder OMPBuilder(*M);
+  DenseMap AlignedVars;
+  CanonicalLoopInfo *CLI = buildSingleLoopFunction(DL, OMPBuilder, 32);
+
+  // Simd-ize the loop.
+  OMPBuilder.applySimd(CLI, AlignedVars,
+   /* IfCond */ nullptr, /* Simdlen */ nullptr,
+   /* Safelen */ nullptr);
+
+  OMPBuilder.finalize();
+  EXPECT_FALSE(verifyModule(*M, &errs()));
+
+  PassBuilder PB;
+  FunctionAnalysisManager FAM;
+  PB.registerFunctionAnalyses(FAM);
+  LoopInfo &LI = FAM.getResult(*F);
+
+  const std::vector &TopLvl = LI.getTopLevelLoops();
+  EXPECT_EQ(TopLvl.size(), 1u);
+
+  Loop *L = TopLvl.front();
+  EXPECT_TRUE(findStringMetadataForLoop(L, "llvm.loop.parallel_accesses"));
+  EXPECT_TRUE(getBooleanLoopAttribute(L, "llvm.loop.vectorize.enable"));
+
+  // Check for llvm.access.group metadata attached to the printf
+  // function in the loop body.
+  BasicBlock *LoopBody = CLI->getBody();
+  EXPECT_TRUE(any_of(*LoopBody, [](Instruction &I) {
+return I.getMetadata("llvm.access.group") != nullptr;
+  }));
+}
+
+TEST_F(OpenMPIRBuilderTest, ApplySimdiDefaultAligned) {
+  OpenMPIRBuilder OMPBuilder(*M);
+  IRBuilder<> Builder(BB);
+  AllocaInst *Alloc1 =
+  Builder.CreateAlloca(Builder.getInt8PtrTy(), Builder.getInt64(1));
+  AllocaInst *Alloc2 = Builder.CreateAlloca(
+  ArrayType::get(Builder.getInt32Ty(), 10), Builder.getInt64(1));
+  DenseMap AlignedVars;
+  auto Int8Ty = Builder.getInt8Ty();
+  Instruction *MallocInstr = CallInst::CreateMalloc(
+  Alloc2, Builder.getInt64Ty(), Int8Ty, ConstantExpr::getSizeOf(Int8Ty),
+  Builder.getInt64(400), nullptr, "");
+  Builder.CreateStore(MallocInstr, Alloc1);
+
+  AlignedVars.insert({Alloc1, nullptr});
+  AlignedVars.insert({Alloc2, nullptr});
 
   CanonicalLoopInfo *CLI = buildSingleLoopFunction(DL, OMPBuilder, 32);
 
   // Simd-ize the loop.
-  OMPBuilder.applySimd(CLI, /* IfCond */ nullptr, /* Simdlen */ nullptr,
+  OMPBuilder.applySimd(CLI, AlignedVars,
+   /* IfCond */ nullptr, /* Simdlen */ nullptr,
/* Safelen */ nullptr);
 
   OMPBuilder.finalize();
@@ -1795,15 +1843,92 @@
   EXPECT_TRUE(any_of(*LoopBody, [](Instruction &I) {
 return I.getMetadata("llvm.access.group") != nullptr;
   }));
+
+  // Check if number of assumption instructions is equal to number of aligned
+  // variables
+  BasicBlock *LoopPreheader = CLI->getPreheader();
+  size_t NumAssummptionCallsInPreheader = count_if(
+  *LoopPreheader, [](Instruction &I) { return isa(I); });
+  EXPECT_EQ(NumAssummptionCallsInPreheader, AlignedVars.size());
 }
 
-TEST_F(OpenMPIRBuilderTest, ApplySimdlen) {
+TEST_F(OpenMPIRBuilderTest, ApplySimdiCustomAligned) {
   OpenMPIRBuilder OMPBuilder(*M);
+  IRBuilder<> Builder(BB);
+  const int AlignmentValue = 32;
+  AllocaInst *Alloc1 =
+  Builder.CreateAlloca(Builder.getInt8PtrTy(), Builder.getInt64(1));
+  AllocaInst *Alloc2 = Builder.CreateAlloca(
+  ArrayType::get(Builder.getInt32Ty(), 10), Builder.getInt64(1));
+  DenseMap AlignedVars;
+  auto Int8Ty = Builder.getInt8Ty();
+  Instruction *MallocInstr = CallInst::CreateMalloc(
+  Alloc2, Builder.getInt64Ty(), Int8Ty, ConstantExpr::getSizeOf(Int8Ty),
+  Builder.g

[clang-tools-extra] 637da9d - Revert "[clang] template / auto deduction deduces common sugar"

[Alexander Kornienko via cfe-commits]

Author: Alexander Kornienko
Date: 2022-09-13T12:18:07+02:00
New Revision: 637da9de4c6619c0e179c2c2f0dbfebd08ac2a0f

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

LOG: Revert "[clang] template / auto deduction deduces common sugar"

This reverts commit d200db38637884fd0b421802c6094b2a03ceb29e, which causes a
clang crash. See https://reviews.llvm.org/D111283#3785755

Test case for convenience:
```
template 
using P = int T::*;

template 
void j(P, T, A...);

template 
void j(P, T);

struct S {
  int b;
};
void g(P k, S s) { j(k, s); }
```

Added: 


Modified: 
clang-tools-extra/clangd/unittests/ASTTests.cpp
clang-tools-extra/clangd/unittests/HoverTests.cpp
clang/include/clang/AST/ASTContext.h
clang/include/clang/AST/Type.h
clang/include/clang/Sema/Sema.h
clang/lib/AST/ASTContext.cpp
clang/lib/Sema/SemaDecl.cpp
clang/lib/Sema/SemaDeclCXX.cpp
clang/lib/Sema/SemaExprCXX.cpp
clang/lib/Sema/SemaOverload.cpp
clang/lib/Sema/SemaStmt.cpp
clang/lib/Sema/SemaTemplate.cpp
clang/lib/Sema/SemaTemplateDeduction.cpp
clang/test/SemaCXX/cxx0x-initializer-stdinitializerlist.cpp
clang/test/SemaCXX/deduced-return-void.cpp
clang/test/SemaCXX/sugared-auto.cpp
clang/test/SemaTemplate/deduction.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/unittests/ASTTests.cpp 
b/clang-tools-extra/clangd/unittests/ASTTests.cpp
index 8f67136585308..4bb3e025b87a5 100644
--- a/clang-tools-extra/clangd/unittests/ASTTests.cpp
+++ b/clang-tools-extra/clangd/unittests/ASTTests.cpp
@@ -84,7 +84,7 @@ TEST(GetDeducedType, KwAutoKwDecltypeExpansion) {
 
   ^auto i = {1,2};
   )cpp",
-  "std::initializer_list",
+  "class std::initializer_list",
   },
   {
   R"cpp( // auto in function return type with trailing return type

diff  --git a/clang-tools-extra/clangd/unittests/HoverTests.cpp 
b/clang-tools-extra/clangd/unittests/HoverTests.cpp
index a09e19ce9ff7f..d4000f31a5f7e 100644
--- a/clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ b/clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -1940,7 +1940,7 @@ TEST(Hover, All) {
   [](HoverInfo &HI) {
 HI.Name = "auto";
 HI.Kind = index::SymbolKind::TypeAlias;
-HI.Definition = "std::initializer_list";
+HI.Definition = "class std::initializer_list";
   }},
   {
   R"cpp(// User defined conversion to auto

diff  --git a/clang/include/clang/AST/ASTContext.h 
b/clang/include/clang/AST/ASTContext.h
index 8ef7a32e6f09e..eb52bf5c736a0 100644
--- a/clang/include/clang/AST/ASTContext.h
+++ b/clang/include/clang/AST/ASTContext.h
@@ -2807,23 +2807,6 @@ class ASTContext : public RefCountedBase {
 return AddrSpaceMapMangling || isTargetAddressSpace(AS);
   }
 
-  // Merges two exception specifications, such that the resulting
-  // exception spec is the union of both. For example, if either
-  // of them can throw something, the result can throw it as well.
-  FunctionProtoType::ExceptionSpecInfo
-  mergeExceptionSpecs(FunctionProtoType::ExceptionSpecInfo ESI1,
-  FunctionProtoType::ExceptionSpecInfo ESI2,
-  SmallVectorImpl &ExceptionTypeStorage,
-  bool AcceptDependent);
-
-  // For two "same" types, return a type which has
-  // the common sugar between them. If Unqualified is true,
-  // both types need only be the same unqualified type.
-  // The result will drop the qualifiers which do not occur
-  // in both types.
-  QualType getCommonSugaredType(QualType X, QualType Y,
-bool Unqualified = false);
-
 private:
   // Helper for integer ordering
   unsigned getIntegerRank(const Type *T) const;

diff  --git a/clang/include/clang/AST/Type.h b/clang/include/clang/AST/Type.h
index 5897453280729..88e2fb338a328 100644
--- a/clang/include/clang/AST/Type.h
+++ b/clang/include/clang/AST/Type.h
@@ -4320,9 +4320,10 @@ class FunctionProtoType final
   }
 
   using param_type_iterator = const QualType *;
+  using param_type_range = llvm::iterator_range;
 
-  ArrayRef param_types() const {
-return llvm::makeArrayRef(param_type_begin(), param_type_end());
+  param_type_range param_types() const {
+return param_type_range(param_type_begin(), param_type_end());
   }
 
   param_type_iterator param_type_begin() const {

diff  --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 43476f63fb96e..459c1109b852e 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -8771,9 +8771,7 @@ class Sema final {
 /// Deduction failed; that's all we know.
 TDK_MiscellaneousDeductionFailure,
 /// CUDA Target attributes do not match.
-TDK_CUDATar

[PATCH] D111283: [clang] template / auto deduction deduces common sugar

[Alexander Kornienko via Phabricator via cfe-commits]

alexfh added a comment.

I've reverted d200db38637884fd0b421802c6094b2a03ceb29e 
 in 
637da9de4c6619c0e179c2c2f0dbfebd08ac2a0f 
.

And a bit more compact test case:

  template 
  using P = int T::*;
  
  template 
  void j(P, T, A...);
  
  template 
  void j(P, T);
  
  struct S {
int b;
  };
  void g(P k, S s) { j(k, s); }


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D111283/new/

https://reviews.llvm.org/D111283

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

[PATCH] D133578: [OpenMP] Add generation of SIMD align assumptions to OMPIRBuilder

[Dominik Adamski via Phabricator via cfe-commits]

domada marked an inline comment as done.
domada added inline comments.



Comment at: llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h:629
+ llvm::ArrayRef AlignedVars,
+ llvm::Value *Alignment, Value *IfCond, ConstantInt *Simdlen,
  ConstantInt *Safelen);

jdoerfert wrote:
> Aren't there different alignments possible, so X is aligned 32 and Y is 
> aligned 64? If so, should we tie the Value and Alignment together in the API?
You are right. It is possible to specify multiple align clauses for single omp 
clause (for example:  #pragma omp simd aligned(X:32) aligned(Y:64)



Comment at: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:2976
 
+  const int DefaultAlignment = 16;
+

jdoerfert wrote:
> This doesn't work. Use the data layout for any default values please.
I have used pointer ABI alignment as the default value. Is it ok?
Clang has separate method to calculate OpenMP default alignment defined in 
TargetInfo class ( [[ 
https://clang.llvm.org/doxygen/classclang_1_1TargetInfo.html#af0c75e3288adc13601732329c44db147
 |  link ]])
Unfortunately, there is no simple replacement of this function in OMPIRBuilder 
or in Flang driver. There are some requests to expose TargetInfo data in 
Clang-independent manner: [[ 
https://discourse.llvm.org/t/rfc-targetinfo-library/64342 | RFC1 ]], 
[[https://discourse.llvm.org/t/complex-to-libm-conversion-abi-issues/65131 
|RFC2]] , but this issue is not solved.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133578/new/

https://reviews.llvm.org/D133578

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

[PATCH] D111283: [clang] template / auto deduction deduces common sugar

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added a comment.

Even simpler:

  template  using P = T;
  
  template  void j(P, T, A...);
  template  void j(P, T);
  
  void g() { j(P{}, int{}); }


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D111283/new/

https://reviews.llvm.org/D111283

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

[PATCH] D133589: [clang-format] JSON formatting add new option for controlling newlines in json arrays

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay updated this revision to Diff 459712.
MyDeveloperDay marked 4 inline comments as done.
MyDeveloperDay added a comment.

put back removed braces
address other review comments


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133589/new/

https://reviews.llvm.org/D133589

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/Format.cpp
  clang/lib/Format/TokenAnnotator.cpp
  clang/unittests/Format/FormatTestJson.cpp

Index: clang/unittests/Format/FormatTestJson.cpp
===
--- clang/unittests/Format/FormatTestJson.cpp
+++ clang/unittests/Format/FormatTestJson.cpp
@@ -159,6 +159,27 @@
"]");
 }
 
+TEST_F(FormatTestJson, JsonArrayOneLine) {
+  FormatStyle Style = getLLVMStyle(FormatStyle::LK_Json);
+  Style.BreakArrays = false;
+  Style.SpacesInContainerLiterals = false;
+  verifyFormat("[]", Style);
+  verifyFormat("[1]", Style);
+  verifyFormat("[1, 2]", Style);
+  verifyFormat("[1, 2, 3]", Style);
+  verifyFormat("[1, 2, 3, 4]", Style);
+  verifyFormat("[1, 2, 3, 4, 5]", Style);
+
+  verifyFormat("[\n"
+   "  1,\n"
+   "  2,\n"
+   "  {\n"
+   "A: 1\n"
+   "  }\n"
+   "]",
+   Style);
+}
+
 TEST_F(FormatTestJson, JsonNoStringSplit) {
   FormatStyle Style = getLLVMStyle(FormatStyle::LK_Json);
   Style.IndentWidth = 4;
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -4399,18 +4399,22 @@
 // }
 if (Left.is(TT_DictLiteral) && Left.is(tok::l_brace))
   return true;
-// Always break after a JSON array opener.
-// [
-// ]
-if (Left.is(TT_ArrayInitializerLSquare) && Left.is(tok::l_square) &&
-!Right.is(tok::r_square)) {
-  return true;
+// Always break after a JSON array opener based on BreakArrays.
+if ((Left.is(TT_ArrayInitializerLSquare) && Left.is(tok::l_square) &&
+ Right.isNot(tok::r_square)) ||
+Left.is(tok::comma)) {
+  if (Right.is(tok::l_brace))
+return true;
+  // scan to the right if an we see an object or an array inside
+  // then break.
+  for (const auto *Tok = &Right; Tok; Tok = Tok->Next) {
+if (Tok->isOneOf(tok::l_brace, tok::l_square))
+  return true;
+if (Tok->isOneOf(tok::r_brace, tok::r_square))
+  break;
+  }
+  return Style.BreakArrays;
 }
-// Always break after successive entries.
-// 1,
-// 2
-if (Left.is(tok::comma))
-  return true;
   }
 
   // If the last token before a '}', ']', or ')' is a comma or a trailing
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -728,6 +728,7 @@
 
 IO.mapOptional("BreakAfterJavaFieldAnnotations",
Style.BreakAfterJavaFieldAnnotations);
+IO.mapOptional("BreakArrays", Style.BreakArrays);
 IO.mapOptional("BreakStringLiterals", Style.BreakStringLiterals);
 IO.mapOptional("ColumnLimit", Style.ColumnLimit);
 IO.mapOptional("CommentPragmas", Style.CommentPragmas);
@@ -1249,6 +1250,7 @@
   LLVMStyle.EmptyLineAfterAccessModifier = FormatStyle::ELAAMS_Never;
   LLVMStyle.EmptyLineBeforeAccessModifier = FormatStyle::ELBAMS_LogicalBlock;
   LLVMStyle.ExperimentalAutoDetectBinPacking = false;
+  LLVMStyle.BreakArrays = true;
   LLVMStyle.PackConstructorInitializers = FormatStyle::PCIS_BinPack;
   LLVMStyle.FixNamespaceComments = true;
   LLVMStyle.ForEachMacros.push_back("foreach");
Index: clang/include/clang/Format/Format.h
===
--- clang/include/clang/Format/Format.h
+++ clang/include/clang/Format/Format.h
@@ -872,6 +872,23 @@
   /// \version 3.7
   bool BinPackParameters;
 
+  /// If ``true``, clang-format will always break after a Json array `[`
+  /// otherwise it will scan until the closing `]` to determine if it should add
+  /// newlines between elements (prettier compatible).
+  ///
+  /// NOTE: This is currently only for formatting JSON.
+  /// \code
+  ///true:  false:
+  ///[  vs.  [1, 2, 3, 4]
+  ///  1,
+  ///  2,
+  ///  3,
+  ///  4
+  ///]
+  /// \endcode
+  /// \version 16
+  bool BreakArrays;
+
   /// The style of wrapping parameters on the same line (bin-packed) or
   /// on one line each.
   enum BinPackStyle : int8_t {
@@ -3878,6 +3895,7 @@
AttributeMacros == R.AttributeMacros &&
BinPackArguments == R.BinPackArguments &&
BinPackParameters == R.BinPackParameters &&
+   BreakArrays == R.BreakArrays &&
BreakBeforeBinaryOperators == R.BreakBeforeBinaryOperators &&
   

[PATCH] D133756: [clangd] Introduce CompileCommandsAdjuster

[Tom Praschan via Phabricator via cfe-commits]

tom-anders added inline comments.



Comment at: clang-tools-extra/clangd/indexer/IndexerMain.cpp:150-151
   clang::tooling::ArgumentsAdjuster(
-  clang::clangd::CommandMangler::detect()));
+  [Mangler = std::shared_ptr(
+   clang::clangd::CommandMangler::detect().release())](
+  const std::vector &Args, llvm::StringRef File) {

Just wondering, why do you need to convert to a shared_ptr here? Couldn't the 
lambda just take ownership of the unique_ptr?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133756/new/

https://reviews.llvm.org/D133756

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

[clang] 7f57b64 - [OpenMP] Extend lit test for parallel for simd construct

[Animesh Kumar via cfe-commits]

Author: Animesh Kumar
Date: 2022-09-13T17:07:11+05:30
New Revision: 7f57b646d1501fedb21cfe8e02d5ede243ac51b1

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

LOG: [OpenMP] Extend lit test for parallel for simd construct

This construct is being tested for atomic operation based upon
the test 5.0/parallel_for_simd/test_parallel_for_simd_atomic.c
from the SOLLVE repo: https://github.com/SOLLVE/sollve_vv

Differential Revision: https://reviews.llvm.org/D132643

Added: 


Modified: 
clang/test/OpenMP/parallel_for_simd_codegen.cpp

Removed: 




diff  --git a/clang/test/OpenMP/parallel_for_simd_codegen.cpp 
b/clang/test/OpenMP/parallel_for_simd_codegen.cpp
index 9e8fa026e76e0..cbe51d42db4e1 100644
--- a/clang/test/OpenMP/parallel_for_simd_codegen.cpp
+++ b/clang/test/OpenMP/parallel_for_simd_codegen.cpp
@@ -3,20 +3,20 @@
 // RUN: %clang_cc1 -no-opaque-pointers -fopenmp -fopenmp-version=45 -x c++ 
-triple x86_64-unknown-unknown -fexceptions -fcxx-exceptions 
-debug-info-kind=limited -std=c++11 -include-pch %t -verify %s -emit-llvm -o - 
| FileCheck %s
 // RUN: %clang_cc1 -no-opaque-pointers -verify -triple x86_64-apple-darwin10 
-fopenmp -fopenmp-version=45 -fexceptions -fcxx-exceptions 
-debug-info-kind=line-tables-only -x c++ -emit-llvm %s -o - | FileCheck %s 
--check-prefix=TERM_DEBUG
 
-// RUN: %clang_cc1 -no-opaque-pointers -verify -fopenmp -x c++ -triple 
x86_64-unknown-unknown -emit-llvm %s -fexceptions -fcxx-exceptions -o - | 
FileCheck %s --check-prefix=OMP50 --check-prefix=CHECK
-// RUN: %clang_cc1 -no-opaque-pointers -fopenmp -x c++ -std=c++11 -triple 
x86_64-unknown-unknown -fexceptions -fcxx-exceptions -emit-pch -o %t %s
-// RUN: %clang_cc1 -no-opaque-pointers -fopenmp -x c++ -triple 
x86_64-unknown-unknown -fexceptions -fcxx-exceptions -debug-info-kind=limited 
-std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s
-// RUN: %clang_cc1 -no-opaque-pointers -verify -triple x86_64-apple-darwin10 
-fopenmp -fexceptions -fcxx-exceptions -debug-info-kind=line-tables-only -x c++ 
-emit-llvm %s -o - | FileCheck %s --check-prefix=TERM_DEBUG
+// RUN: %clang_cc1 -no-opaque-pointers -verify -fopenmp -DOMP5 -x c++ -triple 
x86_64-unknown-unknown -emit-llvm %s -fexceptions -fcxx-exceptions -o - | 
FileCheck %s --check-prefix=OMP50 --check-prefix=CHECK
+// RUN: %clang_cc1 -no-opaque-pointers -fopenmp -DOMP5 -x c++ -std=c++11 
-triple x86_64-unknown-unknown -fexceptions -fcxx-exceptions -emit-pch -o %t %s
+// RUN: %clang_cc1 -no-opaque-pointers -fopenmp -DOMP5 -x c++ -triple 
x86_64-unknown-unknown -fexceptions -fcxx-exceptions -debug-info-kind=limited 
-std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s
+// RUN: %clang_cc1 -no-opaque-pointers -verify -triple x86_64-apple-darwin10 
-fopenmp -DOMP5 -fexceptions -fcxx-exceptions -debug-info-kind=line-tables-only 
-x c++ -emit-llvm %s -o - | FileCheck %s --check-prefix=TERM_DEBUG
 
 // RUN: %clang_cc1 -no-opaque-pointers -verify -fopenmp-simd 
-fopenmp-version=45 -x c++ -triple x86_64-unknown-unknown -emit-llvm %s 
-fexceptions -fcxx-exceptions -o - | FileCheck --check-prefix SIMD-ONLY0 %s
 // RUN: %clang_cc1 -no-opaque-pointers -fopenmp-simd -fopenmp-version=45 -x 
c++ -std=c++11 -triple x86_64-unknown-unknown -fexceptions -fcxx-exceptions 
-emit-pch -o %t %s
 // RUN: %clang_cc1 -no-opaque-pointers -fopenmp-simd -fopenmp-version=45 -x 
c++ -triple x86_64-unknown-unknown -fexceptions -fcxx-exceptions 
-debug-info-kind=limited -std=c++11 -include-pch %t -verify %s -emit-llvm -o - 
| FileCheck --check-prefix SIMD-ONLY0 %s
 // RUN: %clang_cc1 -no-opaque-pointers -verify -triple x86_64-apple-darwin10 
-fopenmp-simd -fopenmp-version=45 -fexceptions -fcxx-exceptions 
-debug-info-kind=line-tables-only -x c++ -emit-llvm %s -o - | FileCheck 
--check-prefix SIMD-ONLY0 %s
 
-// RUN: %clang_cc1 -no-opaque-pointers -verify -fopenmp-simd  -x c++ -triple 
x86_64-unknown-unknown -emit-llvm %s -fexceptions -fcxx-exceptions -o - | 
FileCheck --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -no-opaque-pointers -fopenmp-simd  -x c++ -std=c++11 
-triple x86_64-unknown-unknown -fexceptions -fcxx-exceptions -emit-pch -o %t %s
-// RUN: %clang_cc1 -no-opaque-pointers -fopenmp-simd  -x c++ -triple 
x86_64-unknown-unknown -fexceptions -fcxx-exceptions -debug-info-kind=limited 
-std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck 
--check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -no-opaque-pointers -verify -triple x86_64-apple-darwin10 
-fopenmp-simd  -fexceptions -fcxx-exceptions -debug-info-kind=line-tables-only 
-x c++ -emit-llvm %s -o - | FileCheck --check-prefix SIMD-ONLY0 %s
+// RUN: %clang_cc1 -no-opaque-pointers -verify -fopenmp-simd -DOMP5 -x c++ 
-triple x86_64-unknown-unknown -emit-llvm %s -fexceptions -fcxx-exc

[PATCH] D132643: [OpenMP] Extend lit test for parallel for simd construct

[Animesh Kumar via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG7f57b646d150: [OpenMP] Extend lit test for parallel for simd 
construct (authored by animeshk-amd).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D132643/new/

https://reviews.llvm.org/D132643

Files:
  clang/test/OpenMP/parallel_for_simd_codegen.cpp


Index: clang/test/OpenMP/parallel_for_simd_codegen.cpp
===
--- clang/test/OpenMP/parallel_for_simd_codegen.cpp
+++ clang/test/OpenMP/parallel_for_simd_codegen.cpp
@@ -3,20 +3,20 @@
 // RUN: %clang_cc1 -no-opaque-pointers -fopenmp -fopenmp-version=45 -x c++ 
-triple x86_64-unknown-unknown -fexceptions -fcxx-exceptions 
-debug-info-kind=limited -std=c++11 -include-pch %t -verify %s -emit-llvm -o - 
| FileCheck %s
 // RUN: %clang_cc1 -no-opaque-pointers -verify -triple x86_64-apple-darwin10 
-fopenmp -fopenmp-version=45 -fexceptions -fcxx-exceptions 
-debug-info-kind=line-tables-only -x c++ -emit-llvm %s -o - | FileCheck %s 
--check-prefix=TERM_DEBUG
 
-// RUN: %clang_cc1 -no-opaque-pointers -verify -fopenmp -x c++ -triple 
x86_64-unknown-unknown -emit-llvm %s -fexceptions -fcxx-exceptions -o - | 
FileCheck %s --check-prefix=OMP50 --check-prefix=CHECK
-// RUN: %clang_cc1 -no-opaque-pointers -fopenmp -x c++ -std=c++11 -triple 
x86_64-unknown-unknown -fexceptions -fcxx-exceptions -emit-pch -o %t %s
-// RUN: %clang_cc1 -no-opaque-pointers -fopenmp -x c++ -triple 
x86_64-unknown-unknown -fexceptions -fcxx-exceptions -debug-info-kind=limited 
-std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s
-// RUN: %clang_cc1 -no-opaque-pointers -verify -triple x86_64-apple-darwin10 
-fopenmp -fexceptions -fcxx-exceptions -debug-info-kind=line-tables-only -x c++ 
-emit-llvm %s -o - | FileCheck %s --check-prefix=TERM_DEBUG
+// RUN: %clang_cc1 -no-opaque-pointers -verify -fopenmp -DOMP5 -x c++ -triple 
x86_64-unknown-unknown -emit-llvm %s -fexceptions -fcxx-exceptions -o - | 
FileCheck %s --check-prefix=OMP50 --check-prefix=CHECK
+// RUN: %clang_cc1 -no-opaque-pointers -fopenmp -DOMP5 -x c++ -std=c++11 
-triple x86_64-unknown-unknown -fexceptions -fcxx-exceptions -emit-pch -o %t %s
+// RUN: %clang_cc1 -no-opaque-pointers -fopenmp -DOMP5 -x c++ -triple 
x86_64-unknown-unknown -fexceptions -fcxx-exceptions -debug-info-kind=limited 
-std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s
+// RUN: %clang_cc1 -no-opaque-pointers -verify -triple x86_64-apple-darwin10 
-fopenmp -DOMP5 -fexceptions -fcxx-exceptions -debug-info-kind=line-tables-only 
-x c++ -emit-llvm %s -o - | FileCheck %s --check-prefix=TERM_DEBUG
 
 // RUN: %clang_cc1 -no-opaque-pointers -verify -fopenmp-simd 
-fopenmp-version=45 -x c++ -triple x86_64-unknown-unknown -emit-llvm %s 
-fexceptions -fcxx-exceptions -o - | FileCheck --check-prefix SIMD-ONLY0 %s
 // RUN: %clang_cc1 -no-opaque-pointers -fopenmp-simd -fopenmp-version=45 -x 
c++ -std=c++11 -triple x86_64-unknown-unknown -fexceptions -fcxx-exceptions 
-emit-pch -o %t %s
 // RUN: %clang_cc1 -no-opaque-pointers -fopenmp-simd -fopenmp-version=45 -x 
c++ -triple x86_64-unknown-unknown -fexceptions -fcxx-exceptions 
-debug-info-kind=limited -std=c++11 -include-pch %t -verify %s -emit-llvm -o - 
| FileCheck --check-prefix SIMD-ONLY0 %s
 // RUN: %clang_cc1 -no-opaque-pointers -verify -triple x86_64-apple-darwin10 
-fopenmp-simd -fopenmp-version=45 -fexceptions -fcxx-exceptions 
-debug-info-kind=line-tables-only -x c++ -emit-llvm %s -o - | FileCheck 
--check-prefix SIMD-ONLY0 %s
 
-// RUN: %clang_cc1 -no-opaque-pointers -verify -fopenmp-simd  -x c++ -triple 
x86_64-unknown-unknown -emit-llvm %s -fexceptions -fcxx-exceptions -o - | 
FileCheck --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -no-opaque-pointers -fopenmp-simd  -x c++ -std=c++11 
-triple x86_64-unknown-unknown -fexceptions -fcxx-exceptions -emit-pch -o %t %s
-// RUN: %clang_cc1 -no-opaque-pointers -fopenmp-simd  -x c++ -triple 
x86_64-unknown-unknown -fexceptions -fcxx-exceptions -debug-info-kind=limited 
-std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck 
--check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -no-opaque-pointers -verify -triple x86_64-apple-darwin10 
-fopenmp-simd  -fexceptions -fcxx-exceptions -debug-info-kind=line-tables-only 
-x c++ -emit-llvm %s -o - | FileCheck --check-prefix SIMD-ONLY0 %s
+// RUN: %clang_cc1 -no-opaque-pointers -verify -fopenmp-simd -DOMP5 -x c++ 
-triple x86_64-unknown-unknown -emit-llvm %s -fexceptions -fcxx-exceptions -o - 
| FileCheck --check-prefix SIMD-ONLY0 %s
+// RUN: %clang_cc1 -no-opaque-pointers -fopenmp-simd -DOMP5 -x c++ -std=c++11 
-triple x86_64-unknown-unknown -fexceptions -fcxx-exceptions -emit-pch -o %t %s
+// RUN: %clang_cc1 -no-opaque-pointers -fopenmp-simd -DOMP5 -x c++ -triple 
x86_64-unknown-unknown -fexceptions -fcxx-exceptions -debug-info-kind=limited 
-std=c++11 -include-pch %t -verify %s -emit-llvm -o -

[PATCH] D133726: [OpenMP][AMDGPU] Link bitcode ROCm device libraries per-TU

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 updated this revision to Diff 459716.
jhuber6 added a comment.

Renaming virtual function to make it more generic.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133726/new/

https://reviews.llvm.org/D133726

Files:
  clang/include/clang/Driver/ToolChain.h
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/AMDGPU.cpp
  clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
  clang/lib/Driver/ToolChains/AMDGPUOpenMP.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/HIPAMD.cpp
  clang/lib/Driver/ToolChains/HIPAMD.h
  clang/lib/Driver/ToolChains/HIPSPV.cpp
  clang/lib/Driver/ToolChains/HIPSPV.h
  clang/test/Driver/amdgpu-openmp-toolchain.c

Index: clang/test/Driver/amdgpu-openmp-toolchain.c
===
--- clang/test/Driver/amdgpu-openmp-toolchain.c
+++ clang/test/Driver/amdgpu-openmp-toolchain.c
@@ -49,5 +49,7 @@
 // RUN:   %clang -### --target=x86_64-unknown-linux-gnu -emit-llvm -S -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx803 -nogpulib %s 2>&1 | FileCheck %s --check-prefix=CHECK-EMIT-LLVM-IR
 // CHECK-EMIT-LLVM-IR: "-cc1" "-triple" "amdgcn-amd-amdhsa"{{.*}}"-emit-llvm"
 
-// RUN: %clang -### -target x86_64-pc-linux-gnu -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx803 -lm --rocm-device-lib-path=%S/Inputs/rocm/amdgcn/bitcode %s 2>&1 | FileCheck %s --check-prefix=CHECK-LIB-DEVICE-NEW
-// CHECK-LIB-DEVICE-NEW: {{.*}}clang-linker-wrapper{{.*}}--bitcode-library=openmp-amdgcn-amd-amdhsa-gfx803={{.*}}ocml.bc"{{.*}}ockl.bc"{{.*}}oclc_daz_opt_on.bc"{{.*}}oclc_unsafe_math_off.bc"{{.*}}oclc_finite_only_off.bc"{{.*}}oclc_correctly_rounded_sqrt_on.bc"{{.*}}oclc_wavefrontsize64_on.bc"{{.*}}oclc_isa_version_803.bc"
+// RUN: %clang -### -target x86_64-pc-linux-gnu -fopenmp --offload-arch=gfx803 \
+// RUN:   --rocm-device-lib-path=%S/Inputs/rocm/amdgcn/bitcode -fopenmp-new-driver %s  2>&1 | \
+// RUN: FileCheck %s --check-prefix=CHECK-LIB-DEVICE-NEW
+// CHECK-LIB-DEVICE-NEW: "-cc1" {{.*}}ocml.bc"{{.*}}ockl.bc"{{.*}}oclc_daz_opt_on.bc"{{.*}}oclc_unsafe_math_off.bc"{{.*}}oclc_finite_only_off.bc"{{.*}}oclc_correctly_rounded_sqrt_on.bc"{{.*}}oclc_wavefrontsize64_on.bc"{{.*}}oclc_isa_version_803.bc"
Index: clang/lib/Driver/ToolChains/HIPSPV.h
===
--- clang/lib/Driver/ToolChains/HIPSPV.h
+++ clang/lib/Driver/ToolChains/HIPSPV.h
@@ -69,7 +69,7 @@
   void AddHIPIncludeArgs(const llvm::opt::ArgList &DriverArgs,
  llvm::opt::ArgStringList &CC1Args) const override;
   llvm::SmallVector
-  getHIPDeviceLibs(const llvm::opt::ArgList &Args) const override;
+  getROCmDeviceLibs(const llvm::opt::ArgList &Args) const override;
 
   SanitizerMask getSupportedSanitizers() const override;
 
Index: clang/lib/Driver/ToolChains/HIPSPV.cpp
===
--- clang/lib/Driver/ToolChains/HIPSPV.cpp
+++ clang/lib/Driver/ToolChains/HIPSPV.cpp
@@ -154,7 +154,7 @@
 CC1Args.append(
 {"-fvisibility=hidden", "-fapply-global-visibility-to-externs"});
 
-  llvm::for_each(getHIPDeviceLibs(DriverArgs),
+  llvm::for_each(getROCmDeviceLibs(DriverArgs),
  [&](const BitCodeLibraryInfo &BCFile) {
CC1Args.append({"-mlink-builtin-bitcode",
DriverArgs.MakeArgString(BCFile.Path)});
@@ -206,7 +206,7 @@
 }
 
 llvm::SmallVector
-HIPSPVToolChain::getHIPDeviceLibs(const llvm::opt::ArgList &DriverArgs) const {
+HIPSPVToolChain::getROCmDeviceLibs(const llvm::opt::ArgList &DriverArgs) const {
   llvm::SmallVector BCLibs;
   if (DriverArgs.hasArg(options::OPT_nogpulib))
 return {};
Index: clang/lib/Driver/ToolChains/HIPAMD.h
===
--- clang/lib/Driver/ToolChains/HIPAMD.h
+++ clang/lib/Driver/ToolChains/HIPAMD.h
@@ -76,7 +76,7 @@
   void AddHIPIncludeArgs(const llvm::opt::ArgList &DriverArgs,
  llvm::opt::ArgStringList &CC1Args) const override;
   llvm::SmallVector
-  getHIPDeviceLibs(const llvm::opt::ArgList &Args) const override;
+  getROCmDeviceLibs(const llvm::opt::ArgList &Args) const override;
 
   SanitizerMask getSupportedSanitizers() const override;
 
Index: clang/lib/Driver/ToolChains/HIPAMD.cpp
===
--- clang/lib/Driver/ToolChains/HIPAMD.cpp
+++ clang/lib/Driver/ToolChains/HIPAMD.cpp
@@ -246,7 +246,7 @@
 CC1Args.push_back("-fapply-global-visibility-to-externs");
   }
 
-  for (auto BCFile : getHIPDeviceLibs(DriverArgs)) {
+  for (auto BCFile : getROCmDeviceLibs(DriverArgs)) {
 CC1Args.push_back(BCFile.ShouldInternalize ? "-mlink-builtin-bitcode"
: "-mlink-bitcode-file");
 CC1Args.push_back(DriverArgs.MakeArgString(BCFi

[clang] 1b19df1 - Correct the __has_c_attribute value for nodiscard

[Aaron Ballman via cfe-commits]

Author: Aaron Ballman
Date: 2022-09-13T08:13:01-04:00
New Revision: 1b19df12b84a7045f75e34009a3a7ff44f599375

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

LOG: Correct the __has_c_attribute value for nodiscard

The original proposal was adopted in Apr 2019 and so the previous value
was 201904L. However, a subsequent proposal (N2448) was adopted to add
an optional message argument to the attribute. We already support that
functionality, but had not bumped the feature test value.

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/include/clang/Basic/Attr.td
clang/test/Preprocessor/has_c_attribute.c
clang/test/Sema/c2x-nodiscard.c

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 30402411178d4..d0d44cbc5ebcd 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -183,6 +183,11 @@ Attribute Changes in Clang
 - Introduced a new function attribute ``__attribute__((nouwtable))`` to 
suppress
   LLVM IR ``uwtable`` function attribute.
 
+- Updated the value returned by ``__has_c_attribute(nodiscard)`` to ``202003L``
+  based on the final date specified by the C2x committee draft. We already
+  supported the ability to specify a message in the attribute, so there were no
+  changes to the attribute behavior.
+
 Windows Support
 ---
 - For the MinGW driver, added the options ``-mguard=none``, ``-mguard=cf`` and

diff  --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index 0ad59b2c153ae..6b9f0aab6c91d 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -2987,7 +2987,7 @@ def WarnUnused : InheritableAttr {
 
 def WarnUnusedResult : InheritableAttr {
   let Spellings = [CXX11<"", "nodiscard", 201907>,
-   C2x<"", "nodiscard", 201904>,
+   C2x<"", "nodiscard", 202003>,
CXX11<"clang", "warn_unused_result">,
GCC<"warn_unused_result">];
   let Subjects = SubjectList<[ObjCMethod, Enum, Record, FunctionLike, 
TypedefName]>;

diff  --git a/clang/test/Preprocessor/has_c_attribute.c 
b/clang/test/Preprocessor/has_c_attribute.c
index 36dd1c80e7802..972bb0fe04e4f 100644
--- a/clang/test/Preprocessor/has_c_attribute.c
+++ b/clang/test/Preprocessor/has_c_attribute.c
@@ -6,7 +6,7 @@
 // CHECK: fallthrough: 201904L
 C2x(fallthrough)
 
-// CHECK: __nodiscard__: 201904L
+// CHECK: __nodiscard__: 202003L
 C2x(__nodiscard__)
 
 // CHECK: selectany: 0
@@ -27,10 +27,10 @@ C2x(deprecated)
 // CHECK: maybe_unused: 201904L
 C2x(maybe_unused)
 
-// CHECK: __gnu__::warn_unused_result: 201904L
+// CHECK: __gnu__::warn_unused_result: 202003L
 C2x(__gnu__::warn_unused_result)
 
-// CHECK: gnu::__warn_unused_result__: 201904L
+// CHECK: gnu::__warn_unused_result__: 202003L
 C2x(gnu::__warn_unused_result__)
 
 // Test that macro expansion of the builtin argument works.

diff  --git a/clang/test/Sema/c2x-nodiscard.c b/clang/test/Sema/c2x-nodiscard.c
index 77b81a523833c..cb33c0c242e7d 100644
--- a/clang/test/Sema/c2x-nodiscard.c
+++ b/clang/test/Sema/c2x-nodiscard.c
@@ -1,12 +1,15 @@
 // RUN: %clang_cc1 -fsyntax-only -std=c2x -verify %s
 
+// This is the latest version of nodiscard that we support.
+_Static_assert(__has_c_attribute(nodiscard) == 202003L);
+
 struct [[nodiscard]] S1 { // ok
   int i;
 };
 struct [[nodiscard, nodiscard]] S2 { // ok
   int i;
 };
-struct [[nodiscard("Wrong")]] S3 { // FIXME: may need an extension warning.
+struct [[nodiscard("Wrong")]] S3 {
   int i;
 };
 



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

[PATCH] D133771: Add a "Potentially Breaking Changes" section to the Clang release notes

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman created this revision.
aaron.ballman added reviewers: tstellar, mgorny, jyknight.
Herald added a project: All.
aaron.ballman requested review of this revision.
Herald added a project: clang.

Sometimes we make changes to the compiler that we expect may cause disruption 
for users. For example, we may strengthen a warning to default to be an error, 
or fix an accepts-invalid bug that's been around for a long time, etc which may 
cause previously accepted code to now be rejected. Rather than hope users 
discover that information by reading all of the release notes, it's better that 
we call these out in one location at the top of the release notes.

Based on feedback collected in the discussion at:
https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werror-implicit-function-declaration/65213/


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133771

Files:
  clang/docs/ReleaseNotes.rst


Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -36,6 +36,26 @@
 the current one. To see the release notes for a specific release, please
 see the `releases page `_.
 
+Potentially Breaking Changes
+
+These changes are ones which we think may surprise users when upgrading to
+Clang |release| because of the opportunity they pose for disruption to existing
+code bases.
+
+- Clang will now correctly diagnose as ill-formed a constant expression where 
an
+  enum without a fixed underlying type is set to a value outside the range of
+  the enumeration's values. Due to the extended period of time this bug was
+  present in major C++ implementations (including Clang), this error has the
+  ability to be downgraded into a warning (via: 
-Wno-error=enum-constexpr-conversion)
+  to provide a transition period for users. This diagnostic is expected to turn
+  into an error-only diagnostic in the next Clang release. Fixes
+  `Issue 50055: `_.
+- ``-Wincompatible-function-pointer-types`` now defaults to an error in all C
+  language modes. It may be downgraded to a warning with
+  ``-Wno-error=incompatible-function-pointer-types`` or disabled entirely with
+  ``-Wno-implicit-function-pointer-types``.
+
+
 What's New in Clang |release|?
 ==
 
@@ -99,14 +119,6 @@
 
 Improvements to Clang's diagnostics
 ^^^
-- Clang will now correctly diagnose as ill-formed a constant expression where 
an
-  enum without a fixed underlying type is set to a value outside the range of
-  the enumeration's values. Due to the extended period of time this bug was
-  present in major C++ implementations (including Clang), this error has the
-  ability to be downgraded into a warning (via: 
-Wno-error=enum-constexpr-conversion)
-  to provide a transition period for users. This diagnostic is expected to turn
-  into an error-only diagnostic in the next Clang release. Fixes
-  `Issue 50055: `_.
 - Clang will now check compile-time determinable string literals as format 
strings.
   Fixes `Issue 55805: `_.
 - ``-Wformat`` now recognizes ``%b`` for the ``printf``/``scanf`` family of
@@ -119,10 +131,6 @@
   potential false positives, this diagnostic will not diagnose use of the
   ``true`` macro (from ``>`) in C language mode despite the macro
   being defined to expand to ``1``.
-- ``-Wincompatible-function-pointer-types`` now defaults to an error in all C
-  language modes. It may be downgraded to a warning with
-  ``-Wno-error=incompatible-function-pointer-types`` or disabled entirely with
-  ``-Wno-implicit-function-pointer-types``.
 - Clang will now print more information about failed static assertions. In
   particular, simple static assertion expressions are evaluated to their
   compile-time value and printed out if the assertion fails.


Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -36,6 +36,26 @@
 the current one. To see the release notes for a specific release, please
 see the `releases page `_.
 
+Potentially Breaking Changes
+
+These changes are ones which we think may surprise users when upgrading to
+Clang |release| because of the opportunity they pose for disruption to existing
+code bases.
+
+- Clang will now correctly diagnose as ill-formed a constant expression where an
+  enum without a fixed underlying type is set to a value outside the range of
+  the enumeration's values. Due to the extended period of time this bug was
+  present in major C++ implementations (including Clang), this error has the
+  ability to be downgraded into a warning (

[PATCH] D133771: Add a "Potentially Breaking Changes" section to the Clang release notes

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a subscriber: thieta.
aaron.ballman added a comment.

@tstellar or @thieta -- will this cause any problems for your release scripts? 
(Note I used `Clang |release|` in the new wording; I can pull the `|release|` 
bit out if that's a problem.) Also, do you suppose there's a way we can flag 
specific release notes as being "critical" so that the script automatically 
adds information to a more public download page such as: 
https://github.com/llvm/llvm-project/releases/tag/llvmorg-15.0.0 ?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133771/new/

https://reviews.llvm.org/D133771

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

[PATCH] D133726: [OpenMP][AMDGPU] Link bitcode ROCm device libraries per-TU

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 updated this revision to Diff 459721.
jhuber6 added a comment.

Adding a test for using `-nogpulib`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133726/new/

https://reviews.llvm.org/D133726

Files:
  clang/include/clang/Driver/ToolChain.h
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/AMDGPU.cpp
  clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
  clang/lib/Driver/ToolChains/AMDGPUOpenMP.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/HIPAMD.cpp
  clang/lib/Driver/ToolChains/HIPAMD.h
  clang/lib/Driver/ToolChains/HIPSPV.cpp
  clang/lib/Driver/ToolChains/HIPSPV.h
  clang/test/Driver/amdgpu-openmp-toolchain.c

Index: clang/test/Driver/amdgpu-openmp-toolchain.c
===
--- clang/test/Driver/amdgpu-openmp-toolchain.c
+++ clang/test/Driver/amdgpu-openmp-toolchain.c
@@ -49,5 +49,12 @@
 // RUN:   %clang -### --target=x86_64-unknown-linux-gnu -emit-llvm -S -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx803 -nogpulib %s 2>&1 | FileCheck %s --check-prefix=CHECK-EMIT-LLVM-IR
 // CHECK-EMIT-LLVM-IR: "-cc1" "-triple" "amdgcn-amd-amdhsa"{{.*}}"-emit-llvm"
 
-// RUN: %clang -### -target x86_64-pc-linux-gnu -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx803 -lm --rocm-device-lib-path=%S/Inputs/rocm/amdgcn/bitcode %s 2>&1 | FileCheck %s --check-prefix=CHECK-LIB-DEVICE-NEW
-// CHECK-LIB-DEVICE-NEW: {{.*}}clang-linker-wrapper{{.*}}--bitcode-library=openmp-amdgcn-amd-amdhsa-gfx803={{.*}}ocml.bc"{{.*}}ockl.bc"{{.*}}oclc_daz_opt_on.bc"{{.*}}oclc_unsafe_math_off.bc"{{.*}}oclc_finite_only_off.bc"{{.*}}oclc_correctly_rounded_sqrt_on.bc"{{.*}}oclc_wavefrontsize64_on.bc"{{.*}}oclc_isa_version_803.bc"
+// RUN: %clang -### -target x86_64-pc-linux-gnu -fopenmp --offload-arch=gfx803 \
+// RUN:   --rocm-device-lib-path=%S/Inputs/rocm/amdgcn/bitcode -fopenmp-new-driver %s  2>&1 | \
+// RUN: FileCheck %s --check-prefix=CHECK-LIB-DEVICE
+// CHECK-LIB-DEVICE: "-cc1" {{.*}}ocml.bc"{{.*}}ockl.bc"{{.*}}oclc_daz_opt_on.bc"{{.*}}oclc_unsafe_math_off.bc"{{.*}}oclc_finite_only_off.bc"{{.*}}oclc_correctly_rounded_sqrt_on.bc"{{.*}}oclc_wavefrontsize64_on.bc"{{.*}}oclc_isa_version_803.bc"
+
+// RUN: %clang -### -target x86_64-pc-linux-gnu -fopenmp --offload-arch=gfx803 -nogpulib \
+// RUN:   --rocm-device-lib-path=%S/Inputs/rocm/amdgcn/bitcode -fopenmp-new-driver %s  2>&1 | \
+// RUN: FileCheck %s --check-prefix=CHECK-LIB-DEVICE-NOGPULIB
+// CHECK-LIB-DEVICE-NOGPULIB-NOT: "-cc1" {{.*}}ocml.bc"{{.*}}ockl.bc"{{.*}}oclc_daz_opt_on.bc"{{.*}}oclc_unsafe_math_off.bc"{{.*}}oclc_finite_only_off.bc"{{.*}}oclc_correctly_rounded_sqrt_on.bc"{{.*}}oclc_wavefrontsize64_on.bc"{{.*}}oclc_isa_version_803.bc"
Index: clang/lib/Driver/ToolChains/HIPSPV.h
===
--- clang/lib/Driver/ToolChains/HIPSPV.h
+++ clang/lib/Driver/ToolChains/HIPSPV.h
@@ -69,7 +69,7 @@
   void AddHIPIncludeArgs(const llvm::opt::ArgList &DriverArgs,
  llvm::opt::ArgStringList &CC1Args) const override;
   llvm::SmallVector
-  getHIPDeviceLibs(const llvm::opt::ArgList &Args) const override;
+  getROCmDeviceLibs(const llvm::opt::ArgList &Args) const override;
 
   SanitizerMask getSupportedSanitizers() const override;
 
Index: clang/lib/Driver/ToolChains/HIPSPV.cpp
===
--- clang/lib/Driver/ToolChains/HIPSPV.cpp
+++ clang/lib/Driver/ToolChains/HIPSPV.cpp
@@ -154,7 +154,7 @@
 CC1Args.append(
 {"-fvisibility=hidden", "-fapply-global-visibility-to-externs"});
 
-  llvm::for_each(getHIPDeviceLibs(DriverArgs),
+  llvm::for_each(getROCmDeviceLibs(DriverArgs),
  [&](const BitCodeLibraryInfo &BCFile) {
CC1Args.append({"-mlink-builtin-bitcode",
DriverArgs.MakeArgString(BCFile.Path)});
@@ -206,7 +206,7 @@
 }
 
 llvm::SmallVector
-HIPSPVToolChain::getHIPDeviceLibs(const llvm::opt::ArgList &DriverArgs) const {
+HIPSPVToolChain::getROCmDeviceLibs(const llvm::opt::ArgList &DriverArgs) const {
   llvm::SmallVector BCLibs;
   if (DriverArgs.hasArg(options::OPT_nogpulib))
 return {};
Index: clang/lib/Driver/ToolChains/HIPAMD.h
===
--- clang/lib/Driver/ToolChains/HIPAMD.h
+++ clang/lib/Driver/ToolChains/HIPAMD.h
@@ -76,7 +76,7 @@
   void AddHIPIncludeArgs(const llvm::opt::ArgList &DriverArgs,
  llvm::opt::ArgStringList &CC1Args) const override;
   llvm::SmallVector
-  getHIPDeviceLibs(const llvm::opt::ArgList &Args) const override;
+  getROCmDeviceLibs(const llvm::opt::ArgList &Args) const override;
 
   SanitizerMask getSupportedSanitizers() const override;
 
Index: clang/lib/Driver/ToolChains/HIPAMD.cpp
===

[PATCH] D111283: [clang] template / auto deduction deduces common sugar

[David Rector via Phabricator via cfe-commits]

davrec added inline comments.



Comment at: clang/lib/AST/ASTContext.cpp:12367
+  case Type::Class:
\
+llvm_unreachable("Unexpected " Kind ": " #Class);
+

Could we just return `X` here? Would that just default to the old behavior 
instead of crashing whenever unforeseen cases arise?  


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D111283/new/

https://reviews.llvm.org/D111283

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

[PATCH] D111283: [clang] template / auto deduction deduces common sugar

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added inline comments.



Comment at: clang/lib/AST/ASTContext.cpp:12367
+  case Type::Class:
\
+llvm_unreachable("Unexpected " Kind ": " #Class);
+

davrec wrote:
> Could we just return `X` here? Would that just default to the old behavior 
> instead of crashing whenever unforeseen cases arise?  
No, I think we should enforce the invariants and make sure we are handling 
everything that can be handled.

Classing `TemplateTypeParm`  as sugar-free was what was wrong and we missed 
this on the review.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D111283/new/

https://reviews.llvm.org/D111283

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

[PATCH] D111283: [clang] template / auto deduction deduces common sugar

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov edited the summary of this revision.
mizvekov updated this revision to Diff 459725.
Herald added subscribers: mstorsjo, arichardson.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D111283/new/

https://reviews.llvm.org/D111283

Files:
  clang-tools-extra/clangd/unittests/ASTTests.cpp
  clang-tools-extra/clangd/unittests/HoverTests.cpp
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/Type.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaTemplateDeduction.cpp
  clang/test/SemaCXX/cxx0x-initializer-stdinitializerlist.cpp
  clang/test/SemaCXX/deduced-return-void.cpp
  clang/test/SemaCXX/sugared-auto.cpp
  clang/test/SemaTemplate/deduction.cpp
  libcxx/utils/ci/buildkite-pipeline.yml

Index: libcxx/utils/ci/buildkite-pipeline.yml
===
--- libcxx/utils/ci/buildkite-pipeline.yml
+++ libcxx/utils/ci/buildkite-pipeline.yml
@@ -59,19 +59,6 @@
   limit: 2
 timeout_in_minutes: 120
 
-  - label: "Documentation"
-command: "libcxx/utils/ci/run-buildbot documentation"
-artifact_paths:
-  - "**/test-results.xml"
-agents:
-  queue: "libcxx-builders"
-  os: "linux"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-timeout_in_minutes: 120
-
   #
   # General testing with the default configuration, under all the supported
   # Standard modes, with Clang and GCC. This catches most issues upfront.
@@ -79,273 +66,6 @@
   #
   - wait
 
-  - label: "C++2b"
-command: "libcxx/utils/ci/run-buildbot generic-cxx2b"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-env:
-CC: "clang-${LLVM_HEAD_VERSION}"
-CXX: "clang++-${LLVM_HEAD_VERSION}"
-agents:
-  queue: "libcxx-builders"
-  os: "linux"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-timeout_in_minutes: 120
-
-  - label: "C++11"
-command: "libcxx/utils/ci/run-buildbot generic-cxx11"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-env:
-CC: "clang-${LLVM_HEAD_VERSION}"
-CXX: "clang++-${LLVM_HEAD_VERSION}"
-agents:
-  queue: "libcxx-builders"
-  os: "linux"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-timeout_in_minutes: 120
-
-  - label: "C++03"
-command: "libcxx/utils/ci/run-buildbot generic-cxx03"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-env:
-CC: "clang-${LLVM_HEAD_VERSION}"
-CXX: "clang++-${LLVM_HEAD_VERSION}"
-agents:
-  queue: "libcxx-builders"
-  os: "linux"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-timeout_in_minutes: 120
-
-  - label: "Modular build"
-command: "libcxx/utils/ci/run-buildbot generic-modules"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-env:
-CC: "clang-${LLVM_HEAD_VERSION}"
-CXX: "clang++-${LLVM_HEAD_VERSION}"
-agents:
-  queue: "libcxx-builders"
-  os: "linux"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-timeout_in_minutes: 120
-
-  - label: "GCC ${GCC_STABLE_VERSION} / C++latest"
-command: "libcxx/utils/ci/run-buildbot generic-gcc"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-env:
-CC: "gcc-${GCC_STABLE_VERSION}"
-CXX: "g++-${GCC_STABLE_VERSION}"
-agents:
-  queue: "libcxx-builders"
-  os: "linux"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-timeout_in_minutes: 120
-
-  #
-  # All other supported configurations of libc++.
-  #
-  - wait
-
-  - label: "C++20"
-command: "libcxx/utils/ci/run-buildbot generic-cxx20"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-env:
-CC: "clang-${LLVM_HEAD_VERSION}"
-CXX: "clang++-${LLVM_HEAD_VERSION}"
-agents:
-  queue: "libcxx-builders"
-  os: "linux"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-timeout_in_minutes: 120
-
-  - label: "C++17"
-command: "libcxx/utils/ci/run-buildbot generic-cxx17"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-env:
-# TODO (mordante) use head
-#CC: "clang-${LLVM_HEAD_VERSION}"
-#CXX: "clang++-${LLVM_HEAD_VERSION}"
-CC: "clang-15"
-CXX: "clang++-15"
-agents:
-  queue: "libcxx-builders"
-  os: "linux"
-retry:
-  automatic:
-- exit_s

[PATCH] D111283: [clang] template / auto deduction deduces common sugar

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov updated this revision to Diff 459726.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D111283/new/

https://reviews.llvm.org/D111283

Files:
  clang-tools-extra/clangd/unittests/ASTTests.cpp
  clang-tools-extra/clangd/unittests/HoverTests.cpp
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/Type.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaTemplateDeduction.cpp
  clang/test/SemaCXX/cxx0x-initializer-stdinitializerlist.cpp
  clang/test/SemaCXX/deduced-return-void.cpp
  clang/test/SemaCXX/sugared-auto.cpp
  clang/test/SemaTemplate/deduction.cpp
  libcxx/utils/ci/buildkite-pipeline.yml

Index: libcxx/utils/ci/buildkite-pipeline.yml
===
--- libcxx/utils/ci/buildkite-pipeline.yml
+++ libcxx/utils/ci/buildkite-pipeline.yml
@@ -59,19 +59,6 @@
   limit: 2
 timeout_in_minutes: 120
 
-  - label: "Documentation"
-command: "libcxx/utils/ci/run-buildbot documentation"
-artifact_paths:
-  - "**/test-results.xml"
-agents:
-  queue: "libcxx-builders"
-  os: "linux"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-timeout_in_minutes: 120
-
   #
   # General testing with the default configuration, under all the supported
   # Standard modes, with Clang and GCC. This catches most issues upfront.
@@ -79,273 +66,6 @@
   #
   - wait
 
-  - label: "C++2b"
-command: "libcxx/utils/ci/run-buildbot generic-cxx2b"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-env:
-CC: "clang-${LLVM_HEAD_VERSION}"
-CXX: "clang++-${LLVM_HEAD_VERSION}"
-agents:
-  queue: "libcxx-builders"
-  os: "linux"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-timeout_in_minutes: 120
-
-  - label: "C++11"
-command: "libcxx/utils/ci/run-buildbot generic-cxx11"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-env:
-CC: "clang-${LLVM_HEAD_VERSION}"
-CXX: "clang++-${LLVM_HEAD_VERSION}"
-agents:
-  queue: "libcxx-builders"
-  os: "linux"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-timeout_in_minutes: 120
-
-  - label: "C++03"
-command: "libcxx/utils/ci/run-buildbot generic-cxx03"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-env:
-CC: "clang-${LLVM_HEAD_VERSION}"
-CXX: "clang++-${LLVM_HEAD_VERSION}"
-agents:
-  queue: "libcxx-builders"
-  os: "linux"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-timeout_in_minutes: 120
-
-  - label: "Modular build"
-command: "libcxx/utils/ci/run-buildbot generic-modules"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-env:
-CC: "clang-${LLVM_HEAD_VERSION}"
-CXX: "clang++-${LLVM_HEAD_VERSION}"
-agents:
-  queue: "libcxx-builders"
-  os: "linux"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-timeout_in_minutes: 120
-
-  - label: "GCC ${GCC_STABLE_VERSION} / C++latest"
-command: "libcxx/utils/ci/run-buildbot generic-gcc"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-env:
-CC: "gcc-${GCC_STABLE_VERSION}"
-CXX: "g++-${GCC_STABLE_VERSION}"
-agents:
-  queue: "libcxx-builders"
-  os: "linux"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-timeout_in_minutes: 120
-
-  #
-  # All other supported configurations of libc++.
-  #
-  - wait
-
-  - label: "C++20"
-command: "libcxx/utils/ci/run-buildbot generic-cxx20"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-env:
-CC: "clang-${LLVM_HEAD_VERSION}"
-CXX: "clang++-${LLVM_HEAD_VERSION}"
-agents:
-  queue: "libcxx-builders"
-  os: "linux"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-timeout_in_minutes: 120
-
-  - label: "C++17"
-command: "libcxx/utils/ci/run-buildbot generic-cxx17"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-env:
-# TODO (mordante) use head
-#CC: "clang-${LLVM_HEAD_VERSION}"
-#CXX: "clang++-${LLVM_HEAD_VERSION}"
-CC: "clang-15"
-CXX: "clang++-15"
-agents:
-  queue: "libcxx-builders"
-  os: "linux"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-timeout_in_minutes: 120
-
-  - label: "C++

[PATCH] D111283: [clang] template / auto deduction deduces common sugar

[David Rector via Phabricator via cfe-commits]

davrec added inline comments.



Comment at: clang/lib/AST/ASTContext.cpp:12367
+  case Type::Class:
\
+llvm_unreachable("Unexpected " Kind ": " #Class);
+

mizvekov wrote:
> davrec wrote:
> > Could we just return `X` here? Would that just default to the old behavior 
> > instead of crashing whenever unforeseen cases arise?  
> No, I think we should enforce the invariants and make sure we are handling 
> everything that can be handled.
> 
> Classing `TemplateTypeParm`  as sugar-free was what was wrong and we missed 
> this on the review.
There might always going to be a few rare corner cases vulnerable to this 
though, particularly as more types are added and the people adding them don't 
pay strict attention to how to incorporate them here, and don't write the 
requisite tests (which seem very difficult to foresee and produce).  When those 
cases arise we will be crashing even though we could produce a perfectly good 
program with the intended semantics; the only thing that would suffer for most 
users is slightly less clear diagnostic messages for those rare cases.  I think 
it would be better to let those cases gradually percolate to our attention via 
bug reports concerning those diagnostics, rather than inconveniencing the user 
and demanding immediate attention via crashes.  Or am I missing something?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D111283/new/

https://reviews.llvm.org/D111283

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

[PATCH] D133757: [clangd] Turn QueryDriverDatabase into a CompileCommandsAdjuster

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added a comment.

thanks, i agree that we should make query driver work coherently with 
`CompileFlags.Compiler`, but I am not sure if we really need to complexity for 
handling this adjustment logic before resolving the driver. I've got some 
comments right next to the change but to summarize to possible interactions i 
can think of:

- User has an absolute path either through compile commands.json or config, 
which means resolve logic is going to be no-op (well apart form symlink 
resolution, which I believe is tricky/rare enough that we shouldn't try to 
special case things for the sake of it).
- We've got just the driver name, and it's generic like `gcc`, I don't think we 
should do anything custom here (I didn't go through all the bugs you've linked, 
so PLMK if there are common counter examples to this) because default clang 
heuristics and gcc heuristics we would get out of a system-installed gcc should 
be pretty much the same. and if the user has a custom system installed gcc, 
they can either modify their compile commands.json or update clangd config to 
provide the absolute path of the compiler. I am saying this is rare, because 
usually those custom toolchains have the target in the binary name.
- We've got a custom driver name, e.g. `arm-none-eabi-gcc`. I think what we 
today is again the desired behaviour, we might try to look for it inside the 
directory mentioned in the compile commands though, when it isn't found inside 
$PATH.

Another question is actually about performing the driver resolution 
before/after we apply the user-supplied edits. in theory we might end up 
overriding a user provided `CompileFlags.Compiler` and I don't really have a 
good sense of what would be desired here.




Comment at: clang-tools-extra/clangd/CompileCommands.cpp:310
+  //that needs to be invoked may come from the CompileFlags->Compiler key
+  //  - BEFORE resolveDriver() because that can mess up the driver path,
+  //e.g. changing gcc to /path/to/clang/bin/gcc

why is this necessary? i.e. are there cases where heuristics in clang-driver 
today cannot identify the same set of includes we would extract from a system 
installed `gcc` ?

because if we were to get rid of this requirement, we can just run this as an 
extra arg adjuster after running command mangler, without changing the logic in 
CommandMangler at all (and also rendering the underlying patch unnecessary (i 
am still not sure if it's needed, but need to take a closer look there)).



Comment at: clang-tools-extra/clangd/unittests/ClangdLSPServerTests.cpp:242
+CompileFlags:
+  Compiler: gcc
+  )yaml";

nridge wrote:
> To exercise `QueryDriverDatabase`, this test assumes that the machine running 
> the test will have a `gcc` somewhere in its path, and that querying it for 
> includes will result in at least one `-isystem` flag being added to the 
> command line.
> 
> Is this a reasonable assumption for buildbots? Or do we need to introduce 
> some kind of abstraction so that the test doesn't actually try to find and 
> execute gcc?
i think it's better to have this as a lit test rather than a unittest. that way 
we can set up the temp env in the lit test with appropriate paths and check for 
the output of `clangd --check=foo.cc`. (we should also have a mock shell script 
called gcc that'll print out expected lines, we already have this in 
`clang-tools-extra/clangd/test/system-include-extractor.test`

because this doesn't only rely on existence of `gcc` on buildbots, but also 
anyone that wants to run clangd-check locally (and might interact weirdly 
depending on where/which gcc is installed).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133757/new/

https://reviews.llvm.org/D133757

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

[PATCH] D131469: [Clang] change default storing path of `-ftime-trace`

[dongjunduo via Phabricator via cfe-commits]

dongjunduo added a comment.

@MaskRay ping


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D131469/new/

https://reviews.llvm.org/D131469

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

[PATCH] D133338: [clang][PowerPC] PPC64 VAArg use coerced integer type for direct aggregate fits in register

[Ulrich Weigand via Phabricator via cfe-commits]

uweigand added a comment.

This LGTM now, but maybe some of the PowerPC reviewers would like to comment as 
well.  @nemanjai ?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D18/new/

https://reviews.llvm.org/D18

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

[PATCH] D111283: [clang] template / auto deduction deduces common sugar

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added inline comments.



Comment at: clang/lib/AST/ASTContext.cpp:12367
+  case Type::Class:
\
+llvm_unreachable("Unexpected " Kind ": " #Class);
+

davrec wrote:
> mizvekov wrote:
> > davrec wrote:
> > > Could we just return `X` here? Would that just default to the old 
> > > behavior instead of crashing whenever unforeseen cases arise?  
> > No, I think we should enforce the invariants and make sure we are handling 
> > everything that can be handled.
> > 
> > Classing `TemplateTypeParm`  as sugar-free was what was wrong and we missed 
> > this on the review.
> There might always going to be a few rare corner cases vulnerable to this 
> though, particularly as more types are added and the people adding them don't 
> pay strict attention to how to incorporate them here, and don't write the 
> requisite tests (which seem very difficult to foresee and produce).  When 
> those cases arise we will be crashing even though we could produce a 
> perfectly good program with the intended semantics; the only thing that would 
> suffer for most users is slightly less clear diagnostic messages for those 
> rare cases.  I think it would be better to let those cases gradually 
> percolate to our attention via bug reports concerning those diagnostics, 
> rather than inconveniencing the user and demanding immediate attention via 
> crashes.  Or am I missing something?
I could on the same argument remove all asserts here and just let the program 
not crash on unforeseen circumstances.

On the other hand, having these asserts here helps us catch bugs not only here, 
but in other parts of the code. For example uniquing / canonicalization bugs.

If someone changes the properties of a type so that the assumptions here are 
not valid anymore, it's helpful to have that pointed out soon.

Going for as an example this specific bug, if there werent those asserts / 
unreachables in place and we had weakened the validation here, it would take a 
very long time for us to figure out we were making the wrong assumption with 
regards to TemplateTypeParmType.

I'd rather figure that out sooner on CI / internal testing rather than have a 
bug created by a user two years from now.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D111283/new/

https://reviews.llvm.org/D111283

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

[PATCH] D133773: [clang] fix linker executable path in test

[Ashay Rane via Phabricator via cfe-commits]

ashay-github created this revision.
ashay-github added reviewers: alvinhochun, rnk, mstorsjo, stella.stamenova.
Herald added a project: All.
ashay-github requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

A previous patch (https://reviews.llvm.org/D132810) introduced a test
that fails on systems where the linker executable (`ld`) has a `.exe`
extension.  This patch updates the regex in the test so that lit can
look for both `ld` as well as `ld.exe`.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133773

Files:
  clang/test/Driver/mingw-cfguard.c


Index: clang/test/Driver/mingw-cfguard.c
===
--- clang/test/Driver/mingw-cfguard.c
+++ clang/test/Driver/mingw-cfguard.c
@@ -3,7 +3,7 @@
 // NO_CF: "-cc1"
 // NO_CF-NOT: "-cfguard"
 // NO_CF-NOT: "-cfguard-no-checks"
-// NO_CF-NEXT: ld"
+// NO_CF-NEXT: ld{{(.exe)?}}"
 // NO_CF-NOT: "--guard-cf"
 // DEFAULT-NOT: "--no-guard-cf"
 // GUARD_NONE-SAME: "--no-guard-cf"
@@ -11,7 +11,7 @@
 // RUN: %clang --target=x86_64-w64-windows-gnu -### %s -mguard=cf 2>&1 | 
FileCheck -check-prefix=GUARD_CF %s
 // GUARD_CF: "-cc1"
 // GUARD_CF-SAME: "-cfguard"
-// GUARD_CF-NEXT: ld"
+// GUARD_CF-NEXT: ld{{(.exe)?}}"
 // GUARD_CF-SAME: "--guard-cf"
 // GUARD_CF-NOT: "--no-guard-cf"
 
@@ -20,7 +20,7 @@
 // GUARD_NOCHECKS-NOT: "-cfguard"
 // GUARD_NOCHECKS-SAME: "-cfguard-no-checks"
 // GUARD_NOCHECKS-NOT: "-cfguard"
-// GUARD_NOCHECKS-NEXT: ld"
+// GUARD_NOCHECKS-NEXT: ld{{(.exe)?}}"
 // GUARD_NOCHECKS-SAME: "--guard-cf"
 // GUARD_NOCHECKS-NOT: "--no-guard-cf"
 


Index: clang/test/Driver/mingw-cfguard.c
===
--- clang/test/Driver/mingw-cfguard.c
+++ clang/test/Driver/mingw-cfguard.c
@@ -3,7 +3,7 @@
 // NO_CF: "-cc1"
 // NO_CF-NOT: "-cfguard"
 // NO_CF-NOT: "-cfguard-no-checks"
-// NO_CF-NEXT: ld"
+// NO_CF-NEXT: ld{{(.exe)?}}"
 // NO_CF-NOT: "--guard-cf"
 // DEFAULT-NOT: "--no-guard-cf"
 // GUARD_NONE-SAME: "--no-guard-cf"
@@ -11,7 +11,7 @@
 // RUN: %clang --target=x86_64-w64-windows-gnu -### %s -mguard=cf 2>&1 | FileCheck -check-prefix=GUARD_CF %s
 // GUARD_CF: "-cc1"
 // GUARD_CF-SAME: "-cfguard"
-// GUARD_CF-NEXT: ld"
+// GUARD_CF-NEXT: ld{{(.exe)?}}"
 // GUARD_CF-SAME: "--guard-cf"
 // GUARD_CF-NOT: "--no-guard-cf"
 
@@ -20,7 +20,7 @@
 // GUARD_NOCHECKS-NOT: "-cfguard"
 // GUARD_NOCHECKS-SAME: "-cfguard-no-checks"
 // GUARD_NOCHECKS-NOT: "-cfguard"
-// GUARD_NOCHECKS-NEXT: ld"
+// GUARD_NOCHECKS-NEXT: ld{{(.exe)?}}"
 // GUARD_NOCHECKS-SAME: "--guard-cf"
 // GUARD_NOCHECKS-NOT: "--no-guard-cf"
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 0f28cf4 - Correct the __has_c_attribute value for maybe_unused

[Aaron Ballman via cfe-commits]

Author: Aaron Ballman
Date: 2022-09-13T09:33:20-04:00
New Revision: 0f28cf416d00a0fa0cb6cf572dd7ebbc19529190

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

LOG: Correct the __has_c_attribute value for maybe_unused

The original proposal was adopted in Apr 2019, but was subsequently
updated by WG14 N2662 in June 2021. We already supported the attribute
on a label and it behaved as expected, but we had not bumped the
feature test value.

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/include/clang/Basic/Attr.td
clang/test/Preprocessor/has_c_attribute.c
clang/test/Sema/c2x-maybe_unused.c
clang/www/c_status.html

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index d0d44cbc5ebcd..9bc96f4dc1e96 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -210,6 +210,9 @@ C Language Changes in Clang
 
 C2x Feature Support
 ---
+- Implemented `WG14 N2662 
`_,
+  so the [[maybe_unused]] attribute may be applied to a label to silence an
+  ``-Wunused-label`` warning.
 
 C++ Language Changes in Clang
 -

diff  --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index 6b9f0aab6c91d..48c7791ebe330 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -2893,7 +2893,7 @@ def ObjCRequiresPropertyDefs : InheritableAttr {
 
 def Unused : InheritableAttr {
   let Spellings = [CXX11<"", "maybe_unused", 201603>, GCC<"unused">,
-   C2x<"", "maybe_unused", 201904>];
+   C2x<"", "maybe_unused", 202106>];
   let Subjects = SubjectList<[Var, ObjCIvar, Type, Enum, EnumConstant, Label,
   Field, ObjCMethod, FunctionLike]>;
   let Documentation = [WarnMaybeUnusedDocs];

diff  --git a/clang/test/Preprocessor/has_c_attribute.c 
b/clang/test/Preprocessor/has_c_attribute.c
index 972bb0fe04e4f..401daa72b85b1 100644
--- a/clang/test/Preprocessor/has_c_attribute.c
+++ b/clang/test/Preprocessor/has_c_attribute.c
@@ -24,7 +24,7 @@ C2x(clang::annotate)
 // CHECK: deprecated: 201904L
 C2x(deprecated)
 
-// CHECK: maybe_unused: 201904L
+// CHECK: maybe_unused: 202106L
 C2x(maybe_unused)
 
 // CHECK: __gnu__::warn_unused_result: 202003L

diff  --git a/clang/test/Sema/c2x-maybe_unused.c 
b/clang/test/Sema/c2x-maybe_unused.c
index 82b9634fc9f39..f531521227d7f 100644
--- a/clang/test/Sema/c2x-maybe_unused.c
+++ b/clang/test/Sema/c2x-maybe_unused.c
@@ -1,5 +1,8 @@
 // RUN: %clang_cc1 -fsyntax-only -Wunused -std=c2x -verify %s
 
+// This is the latest version of maybe_unused that we support.
+_Static_assert(__has_c_attribute(maybe_unused) == 202106L);
+
 struct [[maybe_unused]] S1 { // ok
   int a [[maybe_unused]];
 };
@@ -33,3 +36,10 @@ void f2(void);
 void f2(void) {
 }
 
+void label(void) {
+  [[maybe_unused]] label:
+  ;
+
+  other_label: // expected-warning {{unused label 'other_label'}}
+  ;
+}

diff  --git a/clang/www/c_status.html b/clang/www/c_status.html
index 7d97a6bc1f13f..381a05d07eda6 100644
--- a/clang/www/c_status.html
+++ b/clang/www/c_status.html
@@ -851,7 +851,7 @@ C2x implementation status
 
   [[maybe_unused]] for labels
   https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2662.pdf";>N2662
-  No
+  Clang 16
 
 
   Zeros compare equal



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

[clang] 843d074 - Update the C Status page for the Clang 15 release

[Aaron Ballman via cfe-commits]

Author: Aaron Ballman
Date: 2022-09-13T09:36:54-04:00
New Revision: 843d074400fe9868329e870d6423728333cc7e1a

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

LOG: Update the C Status page for the Clang 15 release

Now that Clang 15 is out, we can swap all the unreleased entries over.

Added: 


Modified: 
clang/www/c_status.html

Removed: 




diff  --git a/clang/www/c_status.html b/clang/www/c_status.html
index 381a05d07eda..c9d33b4e94b4 100644
--- a/clang/www/c_status.html
+++ b/clang/www/c_status.html
@@ -720,12 +720,12 @@ C2x implementation status
 
   Adding the u8 character prefix
   https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2418.pdf";>N2418
-  Clang 15
+  Clang 15
 
 
   Remove support for function definitions with identifier lists
   https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2432.pdf";>N2432
-  Clang 15
+  Clang 15
 
 
 
@@ -873,11 +873,11 @@ C2x implementation status
 

 https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2763.pdf";>N2763
-Clang 15
+Clang 15
   

 https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2775.pdf";>N2775
-Clang 15
+Clang 15
   

 https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2969.htm";>N2969
@@ -1008,7 +1008,7 @@ C2x implementation status
 
   The noreturn attribute
   https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2764.pdf";>N2764
-  Clang 15
+  Clang 15
 
 
   *_HAS_SUBNORM==0 implies what?
@@ -1038,12 +1038,12 @@ C2x implementation status
 
   Identifier Syntax using Unicode Standard Annex 31
   https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2836.pdf";>N2836
-  Clang 15
+  Clang 15
 
 
   No function declarators without prototypes
   https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2841.htm";>N2841
-  Clang 15
+  Clang 15
 
 
   Remove default argument promotions for _FloatN types
@@ -,7 +,7 @@ C2x implementation status
 
   Make false and true first-class language features v8
   https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2935.pdf";>N2935
-  Clang 15
+  Clang 15
 
 
   Properly define blocks as part of the grammar v3



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

[PATCH] D111283: [clang] template / auto deduction deduces common sugar

[David Rector via Phabricator via cfe-commits]

davrec added inline comments.



Comment at: clang/lib/AST/ASTContext.cpp:12367
+  case Type::Class:
\
+llvm_unreachable("Unexpected " Kind ": " #Class);
+

mizvekov wrote:
> davrec wrote:
> > mizvekov wrote:
> > > davrec wrote:
> > > > Could we just return `X` here? Would that just default to the old 
> > > > behavior instead of crashing whenever unforeseen cases arise?  
> > > No, I think we should enforce the invariants and make sure we are 
> > > handling everything that can be handled.
> > > 
> > > Classing `TemplateTypeParm`  as sugar-free was what was wrong and we 
> > > missed this on the review.
> > There might always going to be a few rare corner cases vulnerable to this 
> > though, particularly as more types are added and the people adding them 
> > don't pay strict attention to how to incorporate them here, and don't write 
> > the requisite tests (which seem very difficult to foresee and produce).  
> > When those cases arise we will be crashing even though we could produce a 
> > perfectly good program with the intended semantics; the only thing that 
> > would suffer for most users is slightly less clear diagnostic messages for 
> > those rare cases.  I think it would be better to let those cases gradually 
> > percolate to our attention via bug reports concerning those diagnostics, 
> > rather than inconveniencing the user and demanding immediate attention via 
> > crashes.  Or am I missing something?
> I could on the same argument remove all asserts here and just let the program 
> not crash on unforeseen circumstances.
> 
> On the other hand, having these asserts here helps us catch bugs not only 
> here, but in other parts of the code. For example uniquing / canonicalization 
> bugs.
> 
> If someone changes the properties of a type so that the assumptions here are 
> not valid anymore, it's helpful to have that pointed out soon.
> 
> Going for as an example this specific bug, if there werent those asserts / 
> unreachables in place and we had weakened the validation here, it would take 
> a very long time for us to figure out we were making the wrong assumption 
> with regards to TemplateTypeParmType.
> 
> I'd rather figure that out sooner on CI / internal testing rather than have a 
> bug created by a user two years from now.
Yes its nicer to developers to get stack traces and reproductions whenever 
something goes wrong, and crashing is a good way to get those, but users 
probably won't be so thrilled about it.  Especially given that the main selling 
point of this patch is that it makes diagnostics nicer for users: isn't it a 
bit absurd to crash whenever we can't guarantee our diagnostics will be perfect?

And again the real problem is future types not being properly incorporated here 
and properly tested: i.e. the worry is that this will be a continuing source of 
crashes, even if we handle all the present types properly.

How about we leave it as an unreachable for now, to help ensure all the present 
types are handled, but if months or years from now there continue to be crashes 
due to this, then just return X (while maybe write something to llvm::errs() to 
encourage users to report it), so we don't make the perfect the enemy of the 
good.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D111283/new/

https://reviews.llvm.org/D111283

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

[PATCH] D111509: [clang] use getCommonSugar in an assortment of places

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov marked an inline comment as not done.
mizvekov added a subscriber: davrec.
mizvekov added inline comments.



Comment at: clang/lib/Sema/SemaExpr.cpp:1091-1150
+QualType fpTy = ComplexTy->castAs()->getElementType();
 IntExpr = S.ImpCastExprToType(IntExpr.get(), fpTy, CK_IntegralToFloating);
 IntExpr = S.ImpCastExprToType(IntExpr.get(), ComplexTy,
   CK_FloatingRealToComplex);
   } else {
 assert(IntTy->isComplexIntegerType());
 IntExpr = S.ImpCastExprToType(IntExpr.get(), ComplexTy,

mizvekov wrote:
> @shafik let's continue revision of D133522 in this patch, since that one was 
> a quick fix that I attempted in order to avoid reverting it. But now that it 
> was reverted, I will abandon the other one.
> 
> I have highlighted with this comment the areas affected by D133522 so we can 
> continue here.
> 
> But now I have refactored the whole thing to be simpler / more readable.
Also @davrec if you can please take a look at this, this is the only part of 
the patch that changed, in order to fix the reason why it was reverted.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D111509/new/

https://reviews.llvm.org/D111509

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

[PATCH] D133664: [clangd] Fix hover on symbol introduced by using declaration

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added inline comments.



Comment at: clang-tools-extra/clangd/Hover.cpp:1091
+// better, which in this example would be the actual declaration of 
foo.
+auto *DeclToUse = Decls.begin();
+while (llvm::isa(*DeclToUse) &&

we actually want to show the using decl in certain cases, e.g:
```
namespace ns {
void foo(int); void foo(char);
}
using ns::foo;
template  void bar() { fo^o(T{}); }
```

so rather than this, can we have some logic that looks like:
```
- If we have more than two candidates, and there's exactly one `BaseUsingDecl`, 
prefer that.
- If we have two candidates, prefer the non-`BaseUsingDecl` one.
- Prefer the first. (we hit this case when there's a single candidate or there 
are `multiple or no` using decls. i think multiple using decls is not possible, 
but at least we preserve the existing behaviour in such cases).  
```

can you also export this logic to a helper function, probably called 
`pickDeclToUse`?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133664/new/

https://reviews.llvm.org/D133664

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

[PATCH] D133771: Add a "Potentially Breaking Changes" section to the Clang release notes

[Michał Górny via Phabricator via cfe-commits]

mgorny accepted this revision.
mgorny added a comment.
This revision is now accepted and ready to land.

I think this is a good idea — thanks for doing this.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133771/new/

https://reviews.llvm.org/D133771

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

[PATCH] D133338: [clang][PowerPC] PPC64 VAArg use coerced integer type for direct aggregate fits in register

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

I am not crazy about adding the Boolean parameter here or about the name. Seems 
somewhat unclear when a caller wants to pass `true` there.

What I think would be a more robust solution would be to use the same logic 
that decides whether to coerce the struct argument to an integer type. It seems 
that any big endian ABI that does this would want to ensure the access is on 
the right side.

Ultimately what I am getting at here is that we consider how the caller passes 
the value and how the callee accesses it separately - which is what leads to 
problems like this. Can we decide using the same function for the caller and 
the callee?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D18/new/

https://reviews.llvm.org/D18

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

[PATCH] D133771: Add a "Potentially Breaking Changes" section to the Clang release notes

[Sam James via Phabricator via cfe-commits]

thesamesam accepted this revision.
thesamesam added a comment.

Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133771/new/

https://reviews.llvm.org/D133771

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

[PATCH] D132913: [HLSL] Preserve vec3 for HLSL.

[Alex Gatea via Phabricator via cfe-commits]

alexgatea reopened this revision.
alexgatea added a comment.
This revision is now accepted and ready to land.

This test fails because the actual output has <3 x float>* rather than ptr. 
Could you please fix this test case?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D132913/new/

https://reviews.llvm.org/D132913

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

[PATCH] D133771: Add a "Potentially Breaking Changes" section to the Clang release notes

[Thorsten via Phabricator via cfe-commits]

tschuett added a comment.

The LLD release notes always refer to the Diff where the change was introduced. 
It is kind of sad that we loose all the discussions when we move to GitHub PRs.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133771/new/

https://reviews.llvm.org/D133771

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

[PATCH] D133641: [Clang] [Sema] Ignore invalid multiversion function redeclarations

[Tom Honermann via Phabricator via cfe-commits]

tahonermann accepted this revision.
tahonermann added a comment.
This revision is now accepted and ready to land.

Thank you, this looks good to me!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133641/new/

https://reviews.llvm.org/D133641

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

[PATCH] D133773: [clang] fix linker executable path in test

[Alvin Wong via Phabricator via cfe-commits]

alvinhochun added a comment.

Ah sorry about that, I didn't realize the command includes `.exe` on Windows. 
(For the record, `ld"` matches both `ld` and `ld.lld`.)




Comment at: clang/test/Driver/mingw-cfguard.c:6
 // NO_CF-NOT: "-cfguard-no-checks"
-// NO_CF-NEXT: ld"
+// NO_CF-NEXT: ld{{(.exe)?}}"
 // NO_CF-NOT: "--guard-cf"

Literal dot needs to be escaped as `\.` in regex.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133773/new/

https://reviews.llvm.org/D133773

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

[PATCH] D133726: [OpenMP][AMDGPU] Link bitcode ROCm device libraries per-TU

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added inline comments.



Comment at: clang/lib/Driver/ToolChains/AMDGPU.cpp:717
 AMDGPUToolChain::getGPUArch(const llvm::opt::ArgList &DriverArgs) const {
-  return getProcessorFromTargetID(
-  getTriple(), DriverArgs.getLastArgValue(options::OPT_mcpu_EQ));
+  if (DriverArgs.hasArg(options::OPT_mcpu_EQ))
+return getProcessorFromTargetID(

can we emit an error if both -march and -mcpu are specified and the values are 
different? This is a potential source of error.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133726/new/

https://reviews.llvm.org/D133726

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

[PATCH] D111509: [clang] use getCommonSugar in an assortment of places

[David Rector via Phabricator via cfe-commits]

davrec added a comment.

The lines you changed (clang/lib/Sema/SemaExpr.cpp:1091-1150) look good (IIUC 
you just change cast to cast_as and dyn_cast to getAs, and reorganize for 
clarity).  I suggested some renaming and a few more comments to further clarify.




Comment at: clang/lib/Sema/SemaExpr.cpp:1113-1114
+// "double _Complex" is promoted to "long double _Complex".
+static QualType handleComplexFloatConversion(Sema &S, ExprResult &LHS,
+ QualType LHSType, QualType 
RHSType,
+ bool PromotePrecision) {

Rename params for clarity, e.g.
LHS->Longer
LHSType->LongerType
RHSType->ShorterType




Comment at: clang/lib/Sema/SemaExpr.cpp:1143
 return RHSType;
 
   int Order = S.Context.getFloatingTypeOrder(LHSType, RHSType);

```
// Compute the rank of the two types, regardless of whether they are complex.
```



Comment at: clang/lib/Sema/SemaExpr.cpp:1145
   int Order = S.Context.getFloatingTypeOrder(LHSType, RHSType);
-
-  auto *LHSComplexType = dyn_cast(LHSType);
-  auto *RHSComplexType = dyn_cast(RHSType);
-  QualType LHSElementType =
-  LHSComplexType ? LHSComplexType->getElementType() : LHSType;
-  QualType RHSElementType =
-  RHSComplexType ? RHSComplexType->getElementType() : RHSType;
-
-  QualType ResultType = S.Context.getComplexType(LHSElementType);
-  if (Order < 0) {
-// Promote the precision of the LHS if not an assignment.
-ResultType = S.Context.getComplexType(RHSElementType);
-if (!IsCompAssign) {
-  if (LHSComplexType)
-LHS =
-S.ImpCastExprToType(LHS.get(), ResultType, CK_FloatingComplexCast);
-  else
-LHS = S.ImpCastExprToType(LHS.get(), RHSElementType, CK_FloatingCast);
-}
-  } else if (Order > 0) {
-// Promote the precision of the RHS.
-if (RHSComplexType)
-  RHS = S.ImpCastExprToType(RHS.get(), ResultType, CK_FloatingComplexCast);
-else
-  RHS = S.ImpCastExprToType(RHS.get(), LHSElementType, CK_FloatingCast);
-  }
-  return ResultType;
+  if (Order < 0)
+return handleComplexFloatConversion(S, LHS, LHSType, RHSType,

```
// Promote the precision of the LHS if not an assignment.
```



Comment at: clang/lib/Sema/SemaExpr.cpp:1147
+return handleComplexFloatConversion(S, LHS, LHSType, RHSType,
+/*PromotePrecision=*/!IsCompAssign);
+  return handleComplexFloatConversion(S, RHS, RHSType, LHSType,

```
// Promote the precision of the RHS unless it is already the same as the LHS.
```


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D111509/new/

https://reviews.llvm.org/D111509

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

[PATCH] D111509: [clang] use getCommonSugar in an assortment of places

[David Rector via Phabricator via cfe-commits]

davrec added inline comments.



Comment at: clang/lib/Sema/SemaExpr.cpp:1113-1114
+// "double _Complex" is promoted to "long double _Complex".
+static QualType handleComplexFloatConversion(Sema &S, ExprResult &LHS,
+ QualType LHSType, QualType 
RHSType,
+ bool PromotePrecision) {

davrec wrote:
> Rename params for clarity, e.g.
> LHS->Longer
> LHSType->LongerType
> RHSType->ShorterType
> 
Actually I probably have that backwards, I think LHS is the Shorter 
expression...in any case you see why renaming would be helpful


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D111509/new/

https://reviews.llvm.org/D111509

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

[clang] b8266f5 - Correct the __has_c_attribute value for fallthrough

[Aaron Ballman via cfe-commits]

Author: Aaron Ballman
Date: 2022-09-13T11:08:58-04:00
New Revision: b8266f512a6218e8319379b65a637fa82b3900f6

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

LOG: Correct the __has_c_attribute value for fallthrough

The original proposal was seen in Apr 2019 and we accidentally used
that date (201904L) as the feature testing value. However, WG14 N2408
was adopted at the Oct 2019 meeting and so that's the correct date for
the feature testing macro. The committee draft for C2x shows 201910L
for this value, so this changes brings us in line with the standard.

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/include/clang/Basic/Attr.td
clang/test/Preprocessor/has_c_attribute.c
clang/test/Sema/c2x-fallthrough.c

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 9bc96f4dc1e9..dcc2eaf4b202 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -188,6 +188,11 @@ Attribute Changes in Clang
   supported the ability to specify a message in the attribute, so there were no
   changes to the attribute behavior.
 
+- Updated the value returned by ``__has_c_attribute(fallthrough)`` to 
``201910L``
+  based on the final date specified by the C2x committee draft. We previously
+  used ``201904L`` (the date the proposal was seen by the committee) by 
mistake.
+  There were no other changes to the attribute behavior.
+
 Windows Support
 ---
 - For the MinGW driver, added the options ``-mguard=none``, ``-mguard=cf`` and

diff  --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index 48c7791ebe33..2e3297b72a8c 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -1412,7 +1412,7 @@ def ExtVectorType : Attr {
 
 def FallThrough : StmtAttr {
   let Spellings = [CXX11<"", "fallthrough", 201603>,
-   C2x<"", "fallthrough", 201904>,
+   C2x<"", "fallthrough", 201910>,
CXX11<"clang", "fallthrough">, GCC<"fallthrough">];
   // The attribute only applies to a NullStmt, but we have special fix-it
   // behavior if applied to a case label.

diff  --git a/clang/test/Preprocessor/has_c_attribute.c 
b/clang/test/Preprocessor/has_c_attribute.c
index 401daa72b85b..1da4d0541e6e 100644
--- a/clang/test/Preprocessor/has_c_attribute.c
+++ b/clang/test/Preprocessor/has_c_attribute.c
@@ -3,7 +3,7 @@
 
 #define C2x(x) x: __has_c_attribute(x)
 
-// CHECK: fallthrough: 201904L
+// CHECK: fallthrough: 201910L
 C2x(fallthrough)
 
 // CHECK: __nodiscard__: 202003L

diff  --git a/clang/test/Sema/c2x-fallthrough.c 
b/clang/test/Sema/c2x-fallthrough.c
index baa62aa8f140..092d5285f80b 100644
--- a/clang/test/Sema/c2x-fallthrough.c
+++ b/clang/test/Sema/c2x-fallthrough.c
@@ -1,4 +1,7 @@
-// RUN: %clang_cc1 -fsyntax-only -fdouble-square-bracket-attributes -verify %s
+// RUN: %clang_cc1 -fsyntax-only -std=c2x -verify %s
+
+// This is the latest version of fallthrough that we support.
+_Static_assert(__has_c_attribute(fallthrough) == 201910L);
 
 void f(int n) {
   switch (n) {



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

[PATCH] D133726: [OpenMP][AMDGPU] Link bitcode ROCm device libraries per-TU

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added inline comments.



Comment at: clang/lib/Driver/ToolChains/AMDGPU.cpp:717
 AMDGPUToolChain::getGPUArch(const llvm::opt::ArgList &DriverArgs) const {
-  return getProcessorFromTargetID(
-  getTriple(), DriverArgs.getLastArgValue(options::OPT_mcpu_EQ));
+  if (DriverArgs.hasArg(options::OPT_mcpu_EQ))
+return getProcessorFromTargetID(

yaxunl wrote:
> can we emit an error if both -march and -mcpu are specified and the values 
> are different? This is a potential source of error.
I'm not exactly sure about the semantics for this, maybe someone else can help. 
AFAIK `-mcpu` is sometimes treated as an alias of `-mtune` which is generally 
implied by `-march`. But having `-march` and `-mtune` state different things 
isn't technically disallowed. `-march` seems to imply that we generate code 
that can run on a certain architecture. Since these are in some respects 
equivalent it would probably be fine to just take the last one specified.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133726/new/

https://reviews.llvm.org/D133726

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

[PATCH] D133771: Add a "Potentially Breaking Changes" section to the Clang release notes

[Sylvestre Ledru via Phabricator via cfe-commits]

sylvestre.ledru added inline comments.



Comment at: clang/docs/ReleaseNotes.rst:49
+  present in major C++ implementations (including Clang), this error has the
+  ability to be downgraded into a warning (via: 
-Wno-error=enum-constexpr-conversion)
+  to provide a transition period for users. This diagnostic is expected to turn




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133771/new/

https://reviews.llvm.org/D133771

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

[PATCH] D133773: [clang] fix linker executable path in test

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo added a comment.

In D133773#3786484 , @alvinhochun 
wrote:

> Ah sorry about that, I didn't realize the command includes `.exe` on Windows. 
> (For the record, `ld"` matches both `ld` and `ld.lld`.)

No, iirc these quotes are checked as literal part of the matched string here; 
otherwise the pattern `ld"` would match `ld.exe"` too. So to match any linker 
name, I'd write `ld{{.*}}"` or maybe something like `ld{{[\.a-z]*}}"`, modulo 
regex syntax.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133773/new/

https://reviews.llvm.org/D133773

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

[PATCH] D133726: [OpenMP][AMDGPU] Link bitcode ROCm device libraries per-TU

[Matt Arsenault via Phabricator via cfe-commits]

arsenm added a comment.

Does this fix the weird behavior where you needed to use -lm to use anything in 
the device libraries? I don't see that being removed


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133726/new/

https://reviews.llvm.org/D133726

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

[PATCH] D111283: [clang] template / auto deduction deduces common sugar

[Victor Campos via Phabricator via cfe-commits]

vhscampos added a comment.

For reference, another small reproducer of the crash, but with a different 
stack trace than the first example posted here:

  // Must compile with -std=c++03 to crash
  #include 
  
  int main(int, char**)
  {
int i[3] = {1, 2, 3};
int j[3] = {4, 5, 6};
std::swap(i, j);
  
return 0;
  }

Compile with -std=c++03 to reproduce the assertion failure.
We found it by running the libcxx tests.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D111283/new/

https://reviews.llvm.org/D111283

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

[PATCH] D133773: [clang] fix linker executable path in test

[Alvin Wong via Phabricator via cfe-commits]

alvinhochun added a comment.

In D133773#3786602 , @mstorsjo wrote:

> In D133773#3786484 , @alvinhochun 
> wrote:
>
>> Ah sorry about that, I didn't realize the command includes `.exe` on 
>> Windows. (For the record, `ld"` matches both `ld` and `ld.lld`.)
>
> No, iirc these quotes are checked as literal part of the matched string here; 
> otherwise the pattern `ld"` would match `ld.exe"` too. So to match any linker 
> name, I'd write `ld{{.*}}"` or maybe something like `ld{{[\.a-z]*}}"`, modulo 
> regex syntax.

Oops, I meant `ld"` and `ld.lld"`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133773/new/

https://reviews.llvm.org/D133773

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

[PATCH] D133726: [OpenMP][AMDGPU] Link bitcode ROCm device libraries per-TU

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added a comment.

In D133726#3786607 , @arsenm wrote:

> Does this fix the weird behavior where you needed to use -lm to use anything 
> in the device libraries? I don't see that being removed

That was removed earlier when these files were just sent directly to the link 
job, you can see that removed from this patch.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133726/new/

https://reviews.llvm.org/D133726

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

[PATCH] D133726: [OpenMP][AMDGPU] Link bitcode ROCm device libraries per-TU

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added inline comments.



Comment at: clang/lib/Driver/ToolChains/AMDGPU.cpp:717
 AMDGPUToolChain::getGPUArch(const llvm::opt::ArgList &DriverArgs) const {
-  return getProcessorFromTargetID(
-  getTriple(), DriverArgs.getLastArgValue(options::OPT_mcpu_EQ));
+  if (DriverArgs.hasArg(options::OPT_mcpu_EQ))
+return getProcessorFromTargetID(

jhuber6 wrote:
> yaxunl wrote:
> > can we emit an error if both -march and -mcpu are specified and the values 
> > are different? This is a potential source of error.
> I'm not exactly sure about the semantics for this, maybe someone else can 
> help. AFAIK `-mcpu` is sometimes treated as an alias of `-mtune` which is 
> generally implied by `-march`. But having `-march` and `-mtune` state 
> different things isn't technically disallowed. `-march` seems to imply that 
> we generate code that can run on a certain architecture. Since these are in 
> some respects equivalent it would probably be fine to just take the last one 
> specified.
Some toolchains use -march to specify the target processor, some toolchains use 
-mcpu to specify the target processor. For AMDGPU toolchain, it uses -mcpu to 
specify the target processor in the beginning for OpenCL. Then we add HIP 
support and let HIPAMD toolchain adopt using -mcpu to specify the target 
processor. It is better to have a consistent way for specifying target 
processor for AMDGPU toolchains.

HIPAMD toolchain does this by 
https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/HIPAMD.cpp#L275
 .

Probably AMDGPUOpenMP toolchain can make a similar change? Then we have a 
consistent way to specify target processor for AMDGPU toolchains.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133726/new/

https://reviews.llvm.org/D133726

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

[PATCH] D133773: [clang] fix linker executable path in test

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo added a comment.

In D133773#3786611 , @alvinhochun 
wrote:

> In D133773#3786602 , @mstorsjo 
> wrote:
>
>> In D133773#3786484 , @alvinhochun 
>> wrote:
>>
>>> Ah sorry about that, I didn't realize the command includes `.exe` on 
>>> Windows. (For the record, `ld"` matches both `ld` and `ld.lld`.)
>>
>> No, iirc these quotes are checked as literal part of the matched string 
>> here; otherwise the pattern `ld"` would match `ld.exe"` too. So to match any 
>> linker name, I'd write `ld{{.*}}"` or maybe something like 
>> `ld{{[\.a-z]*}}"`, modulo regex syntax.
>
> Oops, I meant `ld"` and `ld.lld"`, because both ends in `ld"`.

Oh, I see - that's very sneaky!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133773/new/

https://reviews.llvm.org/D133773

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

[PATCH] D133726: [OpenMP][AMDGPU] Link bitcode ROCm device libraries per-TU

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added inline comments.



Comment at: clang/lib/Driver/ToolChains/AMDGPU.cpp:717
 AMDGPUToolChain::getGPUArch(const llvm::opt::ArgList &DriverArgs) const {
-  return getProcessorFromTargetID(
-  getTriple(), DriverArgs.getLastArgValue(options::OPT_mcpu_EQ));
+  if (DriverArgs.hasArg(options::OPT_mcpu_EQ))
+return getProcessorFromTargetID(

yaxunl wrote:
> jhuber6 wrote:
> > yaxunl wrote:
> > > can we emit an error if both -march and -mcpu are specified and the 
> > > values are different? This is a potential source of error.
> > I'm not exactly sure about the semantics for this, maybe someone else can 
> > help. AFAIK `-mcpu` is sometimes treated as an alias of `-mtune` which is 
> > generally implied by `-march`. But having `-march` and `-mtune` state 
> > different things isn't technically disallowed. `-march` seems to imply that 
> > we generate code that can run on a certain architecture. Since these are in 
> > some respects equivalent it would probably be fine to just take the last 
> > one specified.
> Some toolchains use -march to specify the target processor, some toolchains 
> use -mcpu to specify the target processor. For AMDGPU toolchain, it uses 
> -mcpu to specify the target processor in the beginning for OpenCL. Then we 
> add HIP support and let HIPAMD toolchain adopt using -mcpu to specify the 
> target processor. It is better to have a consistent way for specifying target 
> processor for AMDGPU toolchains.
> 
> HIPAMD toolchain does this by 
> https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/HIPAMD.cpp#L275
>  .
> 
> Probably AMDGPUOpenMP toolchain can make a similar change? Then we have a 
> consistent way to specify target processor for AMDGPU toolchains.
The rest of the OpenMP toolchain uses `-march` so I don't see a compelling 
reason to change it. If this is a stopper I'll just remove the changes to this 
function and check `-march` directly in the new `getROCmDeviceLibs` function 
for the OpenMP toolchain.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133726/new/

https://reviews.llvm.org/D133726

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

[PATCH] D132913: [HLSL] Preserve vec3 for HLSL.

[Xiang Li via Phabricator via cfe-commits]

python3kgae added a comment.

In D132913#3786432 , @alexgatea wrote:

> This test fails because the actual output has <3 x float>* rather than ptr. 
> Could you please fix this test case?

Thanks for reporting the issue.
But I cannot repro the fail.
Do you mind sharing your cmake command?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D132913/new/

https://reviews.llvm.org/D132913

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

[PATCH] D111283: [clang] template / auto deduction deduces common sugar

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added inline comments.



Comment at: clang/lib/AST/ASTContext.cpp:12367
+  case Type::Class:
\
+llvm_unreachable("Unexpected " Kind ": " #Class);
+

davrec wrote:
> mizvekov wrote:
> > davrec wrote:
> > > mizvekov wrote:
> > > > davrec wrote:
> > > > > Could we just return `X` here? Would that just default to the old 
> > > > > behavior instead of crashing whenever unforeseen cases arise?  
> > > > No, I think we should enforce the invariants and make sure we are 
> > > > handling everything that can be handled.
> > > > 
> > > > Classing `TemplateTypeParm`  as sugar-free was what was wrong and we 
> > > > missed this on the review.
> > > There might always going to be a few rare corner cases vulnerable to this 
> > > though, particularly as more types are added and the people adding them 
> > > don't pay strict attention to how to incorporate them here, and don't 
> > > write the requisite tests (which seem very difficult to foresee and 
> > > produce).  When those cases arise we will be crashing even though we 
> > > could produce a perfectly good program with the intended semantics; the 
> > > only thing that would suffer for most users is slightly less clear 
> > > diagnostic messages for those rare cases.  I think it would be better to 
> > > let those cases gradually percolate to our attention via bug reports 
> > > concerning those diagnostics, rather than inconveniencing the user and 
> > > demanding immediate attention via crashes.  Or am I missing something?
> > I could on the same argument remove all asserts here and just let the 
> > program not crash on unforeseen circumstances.
> > 
> > On the other hand, having these asserts here helps us catch bugs not only 
> > here, but in other parts of the code. For example uniquing / 
> > canonicalization bugs.
> > 
> > If someone changes the properties of a type so that the assumptions here 
> > are not valid anymore, it's helpful to have that pointed out soon.
> > 
> > Going for as an example this specific bug, if there werent those asserts / 
> > unreachables in place and we had weakened the validation here, it would 
> > take a very long time for us to figure out we were making the wrong 
> > assumption with regards to TemplateTypeParmType.
> > 
> > I'd rather figure that out sooner on CI / internal testing rather than have 
> > a bug created by a user two years from now.
> Yes its nicer to developers to get stack traces and reproductions whenever 
> something goes wrong, and crashing is a good way to get those, but users 
> probably won't be so thrilled about it.  Especially given that the main 
> selling point of this patch is that it makes diagnostics nicer for users: 
> isn't it a bit absurd to crash whenever we can't guarantee our diagnostics 
> will be perfect?
> 
> And again the real problem is future types not being properly incorporated 
> here and properly tested: i.e. the worry is that this will be a continuing 
> source of crashes, even if we handle all the present types properly.
> 
> How about we leave it as an unreachable for now, to help ensure all the 
> present types are handled, but if months or years from now there continue to 
> be crashes due to this, then just return X (while maybe write something to 
> llvm::errs() to encourage users to report it), so we don't make the perfect 
> the enemy of the good.
It's not about crashing when it won't be perfect. We already do these kinds of 
things, see the FIXMEs around the TemplateArgument and NestedNameSpecifier, 
where we just return something worse than we wish to, just because we don't 
have time to implement it now.

These unreachables and asserts here are about testing / documenting our 
knowledge of the system and making it easier to find problems. These should be 
impossible to happen in correct code, and if they do happen because of 
mistakes, fixing them sooner is just going to save us resources.

`llvm::errs` suggestion I perceive as out of line with current practice in 
LLVM, we don't and have a system for producing diagnostics for results possibly 
affected by FIXME and TODO situations and the like, as far as I know, and I am 
not aware of any discussions in that direction. I expect a lot of complexity 
and noise if we went this way.
And I think this would have even less chance of working out if we started to 
incorporate the reporting of violation of invariants into that.

I think even just using raw `llvm::errs` on clang would be incorrect per 
design, and could likely break users that parse our output.

I think if months and years from now, if someone stumbled upon an assert firing 
here and, instead of understanding what is happening and then fixing the code, 
just removed / weakened the assert, that would simply not be good and I hope a 
reviewer would stop that from happening :)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews

[PATCH] D111283: [clang] template / auto deduction deduces common sugar

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added a comment.

@alexfh This new revision that I just pushed should be good.

Do you want to give it a look / test, or should we go ahead and merge it?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D111283/new/

https://reviews.llvm.org/D111283

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

[PATCH] D132913: [HLSL] Preserve vec3 for HLSL.

[Alex Gatea via Phabricator via cfe-commits]

alexgatea added a comment.

> Thanks for reporting the issue.
> But I cannot repro the fail.
> Do you mind sharing your cmake command?

Hmm, I'm just running the command in the test case:
clang --driver-mode=dxc -Tlib_6_7 -fcgl  -Fo - 
clang/test/CodeGenHLSL/float3.hlsl | FileCheck 
clang/test/CodeGenHLSL/float3.hlsl


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D132913/new/

https://reviews.llvm.org/D132913

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

[PATCH] D133773: [clang] fix linker executable path in test

[Ashay Rane via Phabricator via cfe-commits]

ashay-github updated this revision to Diff 459771.
ashay-github added a comment.

Thanks!  I updated the regex to be `ld{{.*}}"`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133773/new/

https://reviews.llvm.org/D133773

Files:
  clang/test/Driver/mingw-cfguard.c


Index: clang/test/Driver/mingw-cfguard.c
===
--- clang/test/Driver/mingw-cfguard.c
+++ clang/test/Driver/mingw-cfguard.c
@@ -3,7 +3,7 @@
 // NO_CF: "-cc1"
 // NO_CF-NOT: "-cfguard"
 // NO_CF-NOT: "-cfguard-no-checks"
-// NO_CF-NEXT: ld"
+// NO_CF-NEXT: ld{{.*}}"
 // NO_CF-NOT: "--guard-cf"
 // DEFAULT-NOT: "--no-guard-cf"
 // GUARD_NONE-SAME: "--no-guard-cf"
@@ -11,7 +11,7 @@
 // RUN: %clang --target=x86_64-w64-windows-gnu -### %s -mguard=cf 2>&1 | 
FileCheck -check-prefix=GUARD_CF %s
 // GUARD_CF: "-cc1"
 // GUARD_CF-SAME: "-cfguard"
-// GUARD_CF-NEXT: ld"
+// GUARD_CF-NEXT: ld{{.*}}"
 // GUARD_CF-SAME: "--guard-cf"
 // GUARD_CF-NOT: "--no-guard-cf"
 
@@ -20,7 +20,7 @@
 // GUARD_NOCHECKS-NOT: "-cfguard"
 // GUARD_NOCHECKS-SAME: "-cfguard-no-checks"
 // GUARD_NOCHECKS-NOT: "-cfguard"
-// GUARD_NOCHECKS-NEXT: ld"
+// GUARD_NOCHECKS-NEXT: ld{{.*}}"
 // GUARD_NOCHECKS-SAME: "--guard-cf"
 // GUARD_NOCHECKS-NOT: "--no-guard-cf"
 


Index: clang/test/Driver/mingw-cfguard.c
===
--- clang/test/Driver/mingw-cfguard.c
+++ clang/test/Driver/mingw-cfguard.c
@@ -3,7 +3,7 @@
 // NO_CF: "-cc1"
 // NO_CF-NOT: "-cfguard"
 // NO_CF-NOT: "-cfguard-no-checks"
-// NO_CF-NEXT: ld"
+// NO_CF-NEXT: ld{{.*}}"
 // NO_CF-NOT: "--guard-cf"
 // DEFAULT-NOT: "--no-guard-cf"
 // GUARD_NONE-SAME: "--no-guard-cf"
@@ -11,7 +11,7 @@
 // RUN: %clang --target=x86_64-w64-windows-gnu -### %s -mguard=cf 2>&1 | FileCheck -check-prefix=GUARD_CF %s
 // GUARD_CF: "-cc1"
 // GUARD_CF-SAME: "-cfguard"
-// GUARD_CF-NEXT: ld"
+// GUARD_CF-NEXT: ld{{.*}}"
 // GUARD_CF-SAME: "--guard-cf"
 // GUARD_CF-NOT: "--no-guard-cf"
 
@@ -20,7 +20,7 @@
 // GUARD_NOCHECKS-NOT: "-cfguard"
 // GUARD_NOCHECKS-SAME: "-cfguard-no-checks"
 // GUARD_NOCHECKS-NOT: "-cfguard"
-// GUARD_NOCHECKS-NEXT: ld"
+// GUARD_NOCHECKS-NEXT: ld{{.*}}"
 // GUARD_NOCHECKS-SAME: "--guard-cf"
 // GUARD_NOCHECKS-NOT: "--no-guard-cf"
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D111283: [clang] template / auto deduction deduces common sugar

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added a comment.

In D111283#3786610 , @vhscampos wrote:

> For reference, another small reproducer of the crash, but with a different 
> stack trace than the first example posted here:
>
>   // Must compile with -std=c++03 to crash
>   #include 
>   
>   int main(int, char**)
>   {
> int i[3] = {1, 2, 3};
> int j[3] = {4, 5, 6};
> std::swap(i, j);
>   
> return 0;
>   }
>
> Compile with -std=c++03 to reproduce the assertion failure.
> We found it by running the libcxx tests.

Thanks. Is this a different crash, or is It the same unreachable firing as the 
one @alexfh reported?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D111283/new/

https://reviews.llvm.org/D111283

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

[PATCH] D132913: [HLSL] Preserve vec3 for HLSL.

[Xiang Li via Phabricator via cfe-commits]

python3kgae added a comment.

In D132913#3786679 , @alexgatea wrote:

>> Thanks for reporting the issue.
>> But I cannot repro the fail.
>> Do you mind sharing your cmake command?
>
> Hmm, I'm just running the command in the test case:
> clang --driver-mode=dxc -Tlib_6_7 -fcgl  -Fo - 
> clang/test/CodeGenHLSL/float3.hlsl | FileCheck 
> clang/test/CodeGenHLSL/float3.hlsl

This is the output I got with  clang --driver-mode=dxc -Tlib_6_7 -fcgl  -Fo - 
clang/test/CodeGenHLSL/float3.hlsl

  target datalayout = 
"e-m:e-p:32:32-i1:32-i8:8-i16:16-i32:32-i64:64-f16:16-f32:32-f64:64-n8:16:32:64"
  target triple = "dxil-unknown-shadermodel6.7-library"
  
  ; Function Attrs: noinline nounwind optnone
  define noundef <3 x float> @"?foo@@YAT?$__vector@M$02@__clang@@T12@@Z"(<3 x 
float> noundef %a) #0 {
  entry:
%a.addr = alloca <3 x float>, align 16
store <3 x float> %a, ptr %a.addr, align 16
%0 = load <3 x float>, ptr %a.addr, align 16
ret <3 x float> %0
  }
  
  attributes #0 = { noinline nounwind optnone "frame-pointer"="all" 
"min-legal-vector-width"="96" "no-trapping-math"="true" 
"stack-protector-buffer-size"="8" }
  
  !llvm.module.flags = !{!0, !1}
  !dx.valver = !{!2}
  !llvm.ident = !{!3}
  
  !0 = !{i32 1, !"wchar_size", i32 4}
  !1 = !{i32 7, !"frame-pointer", i32 2}
  !2 = !{i32 1, i32 7}
  !3 = !{!"clang version 16.0.0 (https://github.com/llvm/llvm-project 
c9d2b6b92d6c29d00f6adc0527cf2331dbaae31a)"}

Maybe you build clang with a different setting? What are the CMake options 
you're using?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D132913/new/

https://reviews.llvm.org/D132913

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

[PATCH] D133711: [Sema] Reject array element types whose alignments are larger than their sizes

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

Usually the solution is to round up the size to the alignment. Can you provide 
godbolt examples of what GCC and MSVC do?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133711/new/

https://reviews.llvm.org/D133711

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

[PATCH] D128750: [C++20] Implement P2113R0: Changes to the Partial Ordering of Constrained Functions

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added inline comments.



Comment at: clang/include/clang/Sema/SemaConcept.h:54-68
+  if (ArgA.getKind() == TemplateArgument::Type &&
+  ArgB.getKind() == TemplateArgument::Type)
+if (const auto *SubstA =
+ArgA.getAsType()->getAs())
+  if (const auto *SubstB =
+  ArgB.getAsType()->getAs()) {
+QualType ReplacementA = SubstA->getReplacementType();

mizvekov wrote:
> ychen wrote:
> > mizvekov wrote:
> > > It's a bit odd to find `SubstTemplateTypeParmType` necessary to implement 
> > > the semantics of this change.
> > > 
> > > This is just type sugar we leave behind in the template instantiator to 
> > > mark where type replacement happened.
> > > 
> > > There are several potential issues here:
> > > 1) This could be marking a substitution that happened at any template 
> > > depth. Ie this could be marking a substitution from an outer template. 
> > > Does the level not matter here at all? 
> > > 2) If the level does matter, you won't be able to reconstitute that 
> > > easily without further improvements. See 
> > > https://github.com/llvm/llvm-project/issues/55886 for example.
> > > 3) A substitution can replace a dependent type for another one, and when 
> > > that other gets replaced, we lose track of that because 
> > > `SubstTemplateTypeParmType` only holds a canonical underlying type.
> > > 
> > > 
> > > 
> > > Leaving that aside, I get the impression you are trying to work around 
> > > the fact that when an expression appears in a canonical type, presumably 
> > > because that expression is dependent on an NTTP, we can't rely on 
> > > uniquing anymore to compare if they are the same type, as we lack in 
> > > Clang the equivalent concept of canonicalization for expressions.
> > > 
> > > But this however is a bit hard to implement. Are we sure the standard 
> > > requires this, or can we simply consider these types always different?
> > > It's a bit odd to find SubstTemplateTypeParmType necessary to implement 
> > > the semantics of this change.
> > 
> > Odd indeed. 
> > 
> > > Leaving that aside, I get the impression you are trying to work around 
> > > the fact that when an expression appears in a canonical type, presumably 
> > > because that expression is dependent on an NTTP, we can't rely on 
> > > uniquing anymore to compare if they are the same type, as we lack in 
> > > Clang the equivalent concept of canonicalization for expressions.
> > 
> > Yeah, sort of . This workaround is to deal with the fact that 
> > `DecltypeType` is not uniqued. However, the injected template argument for 
> > `t` of `template` is `decltype(t)` (which on a side note, might be 
> > wrong since `auto` means using template arg deduct rules; `decltype(auto)` 
> > means using `decltype(expr)` type, let's keep it this way now since this 
> > code path is still needed when Clang starts to support `decltype(auto)` as 
> > NTTP type) and concepts partial ordering rules need to compare these 
> > concept template arguments (https://eel.is/c++draft/temp.constr#atomic-1). 
> > 
> > Looking at the motivation why `DecltypeType` is not uniqued 
> > (https://github.com/llvm/llvm-project/blob/main/clang/lib/AST/ASTContext.cpp#L5637-L5640),
> >  I think maybe we should unique decltype on the expr to deal with concepts 
> > cleanly. Thoughts?
> I see, there should be no problem with a change to unique a DecltypeType, but 
> it might not help you, because expressions typically have source location 
> information embedded in them.
By the way, I just became aware of something I missed, and this could totally 
work here.

We don't have 'canonical expressions', but we do have profiling based on the 
canonical form of an expression, eg see the `Expr::Profile` method, it has a 
`Canonical` argument to ask for this.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D128750/new/

https://reviews.llvm.org/D128750

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

[PATCH] D133711: [Sema] Reject array element types whose alignments are larger than their sizes

[Eli Friedman via Phabricator via cfe-commits]

efriedma added a comment.

> Usually the solution is to round up the size to the alignment. Can you 
> provide godbolt examples of what GCC and MSVC do?

gcc prints a similar error, MSVC doesn't support an equivalent alignment 
attribute.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133711/new/

https://reviews.llvm.org/D133711

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

[PATCH] D133726: [OpenMP][AMDGPU] Link bitcode ROCm device libraries per-TU

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added inline comments.



Comment at: clang/lib/Driver/ToolChains/AMDGPU.cpp:717
 AMDGPUToolChain::getGPUArch(const llvm::opt::ArgList &DriverArgs) const {
-  return getProcessorFromTargetID(
-  getTriple(), DriverArgs.getLastArgValue(options::OPT_mcpu_EQ));
+  if (DriverArgs.hasArg(options::OPT_mcpu_EQ))
+return getProcessorFromTargetID(

jhuber6 wrote:
> yaxunl wrote:
> > jhuber6 wrote:
> > > yaxunl wrote:
> > > > can we emit an error if both -march and -mcpu are specified and the 
> > > > values are different? This is a potential source of error.
> > > I'm not exactly sure about the semantics for this, maybe someone else can 
> > > help. AFAIK `-mcpu` is sometimes treated as an alias of `-mtune` which is 
> > > generally implied by `-march`. But having `-march` and `-mtune` state 
> > > different things isn't technically disallowed. `-march` seems to imply 
> > > that we generate code that can run on a certain architecture. Since these 
> > > are in some respects equivalent it would probably be fine to just take 
> > > the last one specified.
> > Some toolchains use -march to specify the target processor, some toolchains 
> > use -mcpu to specify the target processor. For AMDGPU toolchain, it uses 
> > -mcpu to specify the target processor in the beginning for OpenCL. Then we 
> > add HIP support and let HIPAMD toolchain adopt using -mcpu to specify the 
> > target processor. It is better to have a consistent way for specifying 
> > target processor for AMDGPU toolchains.
> > 
> > HIPAMD toolchain does this by 
> > https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/HIPAMD.cpp#L275
> >  .
> > 
> > Probably AMDGPUOpenMP toolchain can make a similar change? Then we have a 
> > consistent way to specify target processor for AMDGPU toolchains.
> The rest of the OpenMP toolchain uses `-march` so I don't see a compelling 
> reason to change it. If this is a stopper I'll just remove the changes to 
> this function and check `-march` directly in the new `getROCmDeviceLibs` 
> function for the OpenMP toolchain.
There are a bunch of places in AMDGPU and HIPAMD toolchains that check the 
`-mcpu` option. If we allow -march as an alternative way to specify the target 
processor for the AMDGPU toolchain, it will introduce inconsistency and 
probably incur more changes.

Probably leaving this code in AMDGPUOpenMP toolchain is a better choice for now.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133726/new/

https://reviews.llvm.org/D133726

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

[PATCH] D133726: [OpenMP][AMDGPU] Link bitcode ROCm device libraries per-TU

[Jon Chesterfield via Phabricator via cfe-commits]

JonChesterfield added a comment.

march for openmp, mcpu for hip seems ok. Notably llc needs to be told this as 
well, using mcpu, which may be an issue for save-temps


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133726/new/

https://reviews.llvm.org/D133726

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

[PATCH] D133108: [clang] Rework IsTailPaddedMemberArray into isFlexibleArrayMemberExpr

[Martin Sebor via Phabricator via cfe-commits]

msebor added inline comments.



Comment at: clang/lib/Sema/SemaChecking.cpp:15969
+  if (const MemberExpr *ME = dyn_cast(BaseExpr))
+ND = ME->getMemberDecl();
+

I'm not familiar with this code but I'm guessing that at most one of the `if` 
conditionals is true, and if it's the first one then the second `dyn_cast` will 
fail.  Should the `if` guarding this assignment then be an `else if`?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133108/new/

https://reviews.llvm.org/D133108

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

[PATCH] D133726: [OpenMP][AMDGPU] Link bitcode ROCm device libraries per-TU

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 updated this revision to Diff 459786.
jhuber6 added a comment.

Removing use of `getGPUArch` and just using `-march` directly for OpenMP


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133726/new/

https://reviews.llvm.org/D133726

Files:
  clang/include/clang/Driver/ToolChain.h
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/AMDGPU.cpp
  clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
  clang/lib/Driver/ToolChains/AMDGPUOpenMP.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/HIPAMD.cpp
  clang/lib/Driver/ToolChains/HIPAMD.h
  clang/lib/Driver/ToolChains/HIPSPV.cpp
  clang/lib/Driver/ToolChains/HIPSPV.h
  clang/test/Driver/amdgpu-openmp-toolchain.c

Index: clang/test/Driver/amdgpu-openmp-toolchain.c
===
--- clang/test/Driver/amdgpu-openmp-toolchain.c
+++ clang/test/Driver/amdgpu-openmp-toolchain.c
@@ -49,5 +49,12 @@
 // RUN:   %clang -### --target=x86_64-unknown-linux-gnu -emit-llvm -S -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx803 -nogpulib %s 2>&1 | FileCheck %s --check-prefix=CHECK-EMIT-LLVM-IR
 // CHECK-EMIT-LLVM-IR: "-cc1" "-triple" "amdgcn-amd-amdhsa"{{.*}}"-emit-llvm"
 
-// RUN: %clang -### -target x86_64-pc-linux-gnu -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx803 -lm --rocm-device-lib-path=%S/Inputs/rocm/amdgcn/bitcode %s 2>&1 | FileCheck %s --check-prefix=CHECK-LIB-DEVICE-NEW
-// CHECK-LIB-DEVICE-NEW: {{.*}}clang-linker-wrapper{{.*}}--bitcode-library=openmp-amdgcn-amd-amdhsa-gfx803={{.*}}ocml.bc"{{.*}}ockl.bc"{{.*}}oclc_daz_opt_on.bc"{{.*}}oclc_unsafe_math_off.bc"{{.*}}oclc_finite_only_off.bc"{{.*}}oclc_correctly_rounded_sqrt_on.bc"{{.*}}oclc_wavefrontsize64_on.bc"{{.*}}oclc_isa_version_803.bc"
+// RUN: %clang -### -target x86_64-pc-linux-gnu -fopenmp --offload-arch=gfx803 \
+// RUN:   --rocm-device-lib-path=%S/Inputs/rocm/amdgcn/bitcode -fopenmp-new-driver %s  2>&1 | \
+// RUN: FileCheck %s --check-prefix=CHECK-LIB-DEVICE
+// CHECK-LIB-DEVICE: "-cc1" {{.*}}ocml.bc"{{.*}}ockl.bc"{{.*}}oclc_daz_opt_on.bc"{{.*}}oclc_unsafe_math_off.bc"{{.*}}oclc_finite_only_off.bc"{{.*}}oclc_correctly_rounded_sqrt_on.bc"{{.*}}oclc_wavefrontsize64_on.bc"{{.*}}oclc_isa_version_803.bc"
+
+// RUN: %clang -### -target x86_64-pc-linux-gnu -fopenmp --offload-arch=gfx803 -nogpulib \
+// RUN:   --rocm-device-lib-path=%S/Inputs/rocm/amdgcn/bitcode -fopenmp-new-driver %s  2>&1 | \
+// RUN: FileCheck %s --check-prefix=CHECK-LIB-DEVICE-NOGPULIB
+// CHECK-LIB-DEVICE-NOGPULIB-NOT: "-cc1" {{.*}}ocml.bc"{{.*}}ockl.bc"{{.*}}oclc_daz_opt_on.bc"{{.*}}oclc_unsafe_math_off.bc"{{.*}}oclc_finite_only_off.bc"{{.*}}oclc_correctly_rounded_sqrt_on.bc"{{.*}}oclc_wavefrontsize64_on.bc"{{.*}}oclc_isa_version_803.bc"
Index: clang/lib/Driver/ToolChains/HIPSPV.h
===
--- clang/lib/Driver/ToolChains/HIPSPV.h
+++ clang/lib/Driver/ToolChains/HIPSPV.h
@@ -69,7 +69,7 @@
   void AddHIPIncludeArgs(const llvm::opt::ArgList &DriverArgs,
  llvm::opt::ArgStringList &CC1Args) const override;
   llvm::SmallVector
-  getHIPDeviceLibs(const llvm::opt::ArgList &Args) const override;
+  getROCmDeviceLibs(const llvm::opt::ArgList &Args) const override;
 
   SanitizerMask getSupportedSanitizers() const override;
 
Index: clang/lib/Driver/ToolChains/HIPSPV.cpp
===
--- clang/lib/Driver/ToolChains/HIPSPV.cpp
+++ clang/lib/Driver/ToolChains/HIPSPV.cpp
@@ -154,7 +154,7 @@
 CC1Args.append(
 {"-fvisibility=hidden", "-fapply-global-visibility-to-externs"});
 
-  llvm::for_each(getHIPDeviceLibs(DriverArgs),
+  llvm::for_each(getROCmDeviceLibs(DriverArgs),
  [&](const BitCodeLibraryInfo &BCFile) {
CC1Args.append({"-mlink-builtin-bitcode",
DriverArgs.MakeArgString(BCFile.Path)});
@@ -206,7 +206,7 @@
 }
 
 llvm::SmallVector
-HIPSPVToolChain::getHIPDeviceLibs(const llvm::opt::ArgList &DriverArgs) const {
+HIPSPVToolChain::getROCmDeviceLibs(const llvm::opt::ArgList &DriverArgs) const {
   llvm::SmallVector BCLibs;
   if (DriverArgs.hasArg(options::OPT_nogpulib))
 return {};
Index: clang/lib/Driver/ToolChains/HIPAMD.h
===
--- clang/lib/Driver/ToolChains/HIPAMD.h
+++ clang/lib/Driver/ToolChains/HIPAMD.h
@@ -76,7 +76,7 @@
   void AddHIPIncludeArgs(const llvm::opt::ArgList &DriverArgs,
  llvm::opt::ArgStringList &CC1Args) const override;
   llvm::SmallVector
-  getHIPDeviceLibs(const llvm::opt::ArgList &Args) const override;
+  getROCmDeviceLibs(const llvm::opt::ArgList &Args) const override;
 
   SanitizerMask getSupportedSanitizers() const override;
 
Index: clang/lib/Driver/ToolChains/HIPAMD.cpp
===

[PATCH] D133249: [libc++] Documents details of the pre-commit CI.

[Louis Dionne via Phabricator via cfe-commits]

ldionne accepted this revision.
ldionne added a comment.
This revision is now accepted and ready to land.

LGTM w/ comments. Thanks a lot for writing this!




Comment at: clang/www/hacking.html:279
+
+  Some changes in Clang affect https://libcxx.llvm.org";>libc++,
+  for example:

This follows my previous comment, but we really don't want to encourage Clang 
folks to start using a `.DELETE_ME` file for testing Clang changes. Indeed, 
roughly 54/55 of our CI jobs don't use the just-built Clang. The only relevant 
CI job for a Clang change is the Bootstrapping build. As a result, using a 
`.DELETE_ME` file is extremely wasteful of  libc++ CI, since almost all the CI 
jobs are completely irrelevant to the change being tested. Furthermore, it will 
also provide a false sense of security for Clang folks, who will think "hey but 
I ran the CI under all configurations", not understanding the details.

So I think we need to set up libc++ testing for Clang changes, but we should 
discourage folks from running the libc++ CI itself as a poor proxy for testing 
Clang changes. Most of the jobs are just not useful at all from the perspective 
of testing a Clang change.

So I'd rather not add this part of the documentation at all, to avoid creating 
a problem for ourselves.



Comment at: libcxx/docs/Contributing.rst:91-92
+
+.. comments The new part got longer than expected, would it make sense to move
+   it to its own page?
+

I think this is fine in this file for now. We can reorganize the docs if needed 
with a fresh holistic view if needed.



Comment at: libcxx/docs/Contributing.rst:103-104
+CI is hosted on `Buildkite `__ 
and
+the build results are visible in the review on Phabricator. Before committing a
+patch please make sure the CI is green.
+





Comment at: libcxx/docs/Contributing.rst:125-126
+
+.. note:: Updating the Clang nightly builds in the Docker image is a manual
+   process and is done at an irregular interval. When you need to have the
+   latest nightly build to test recent Clang changes best ask at the





Comment at: libcxx/docs/Contributing.rst:127-129
+   latest nightly build to test recent Clang changes best ask at the
+   ``#libcxx`` channel on
+   `LLVM's Discord server `__.





Comment at: libcxx/docs/Contributing.rst:131-133
+.. comments ``irregular`` is used on purpose. Committing to a schedule seems
+   unwanted; people might be unavailable to update the image, the nightly
+   builds fail and are not uploaded for multiple days (this is not uncommon).

This can be removed.



Comment at: libcxx/docs/Contributing.rst:157-158
+  uses that Clang version to build and test libc++. This validates the current
+  Clang and lib++ are compatible. When making changes in Clang that affect
+  libc++ this is the build to validate all is well.
+





Comment at: libcxx/docs/Contributing.rst:182-183
+Note that quite a bit of this infrastructure is heavily Linux focused. This is
+the platform used by most of libc++'s Buildkite runners and developers. Patches
+for other platforms are welcome.
+

IMO this would have its place in the part of the documentation where we list 
all the platforms that we support. We *are* interested in patches for adding 
support to new platforms. However, I'm not sure what patches for porting our CI 
infra to other platforms would mean, since e.g. the Docker image is running 
Linux by definition. Same for the macOS bits of our CI infra -- it wouldn't 
make sense to try to port that to other platforms.



Comment at: libcxx/docs/Contributing.rst:196-198
+.. [#] Currently it contains hard-coded versions using symlinks. They will be
+   removed after LLVM 16 has branched. Removing them before that time risks
+   breaking the CI of the release branch.

I would remove this comment, since it's going to become irrelevant quite soon, 
and I think we're likely to forget to update it. There are already comments in 
our Dockerfile to that effect.



Comment at: libcxx/docs/Contributing.rst:204
+Helper script that pulls and runs the Docker image. This image mounts the LLVM
+monorepository at ``/llvm``. This can be used to test with compilers not
+available on your system.




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133249/new/

https://reviews.llvm.org/D133249

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

[PATCH] D133773: [clang] fix linker executable path in test

[Ashay Rane via Phabricator via cfe-commits]

ashay-github updated this revision to Diff 459791.
ashay-github added a comment.

Updated the regex to `ld{{(.lld)?}}{{(.exe)?}}"`, so that it matches the
following sequences: `ld`, `ld.lld`, `ld.exe`, `ld.lld.exe`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133773/new/

https://reviews.llvm.org/D133773

Files:
  clang/test/Driver/mingw-cfguard.c


Index: clang/test/Driver/mingw-cfguard.c
===
--- clang/test/Driver/mingw-cfguard.c
+++ clang/test/Driver/mingw-cfguard.c
@@ -3,7 +3,7 @@
 // NO_CF: "-cc1"
 // NO_CF-NOT: "-cfguard"
 // NO_CF-NOT: "-cfguard-no-checks"
-// NO_CF-NEXT: ld"
+// NO_CF-NEXT: ld{{(.lld)?}}{{(.exe)?}}"
 // NO_CF-NOT: "--guard-cf"
 // DEFAULT-NOT: "--no-guard-cf"
 // GUARD_NONE-SAME: "--no-guard-cf"
@@ -11,7 +11,7 @@
 // RUN: %clang --target=x86_64-w64-windows-gnu -### %s -mguard=cf 2>&1 | 
FileCheck -check-prefix=GUARD_CF %s
 // GUARD_CF: "-cc1"
 // GUARD_CF-SAME: "-cfguard"
-// GUARD_CF-NEXT: ld"
+// GUARD_CF-NEXT: ld{{(.lld)?}}{{(.exe)?}}"
 // GUARD_CF-SAME: "--guard-cf"
 // GUARD_CF-NOT: "--no-guard-cf"
 
@@ -20,7 +20,7 @@
 // GUARD_NOCHECKS-NOT: "-cfguard"
 // GUARD_NOCHECKS-SAME: "-cfguard-no-checks"
 // GUARD_NOCHECKS-NOT: "-cfguard"
-// GUARD_NOCHECKS-NEXT: ld"
+// GUARD_NOCHECKS-NEXT: ld{{(.lld)?}}{{(.exe)?}}"
 // GUARD_NOCHECKS-SAME: "--guard-cf"
 // GUARD_NOCHECKS-NOT: "--no-guard-cf"
 


Index: clang/test/Driver/mingw-cfguard.c
===
--- clang/test/Driver/mingw-cfguard.c
+++ clang/test/Driver/mingw-cfguard.c
@@ -3,7 +3,7 @@
 // NO_CF: "-cc1"
 // NO_CF-NOT: "-cfguard"
 // NO_CF-NOT: "-cfguard-no-checks"
-// NO_CF-NEXT: ld"
+// NO_CF-NEXT: ld{{(.lld)?}}{{(.exe)?}}"
 // NO_CF-NOT: "--guard-cf"
 // DEFAULT-NOT: "--no-guard-cf"
 // GUARD_NONE-SAME: "--no-guard-cf"
@@ -11,7 +11,7 @@
 // RUN: %clang --target=x86_64-w64-windows-gnu -### %s -mguard=cf 2>&1 | FileCheck -check-prefix=GUARD_CF %s
 // GUARD_CF: "-cc1"
 // GUARD_CF-SAME: "-cfguard"
-// GUARD_CF-NEXT: ld"
+// GUARD_CF-NEXT: ld{{(.lld)?}}{{(.exe)?}}"
 // GUARD_CF-SAME: "--guard-cf"
 // GUARD_CF-NOT: "--no-guard-cf"
 
@@ -20,7 +20,7 @@
 // GUARD_NOCHECKS-NOT: "-cfguard"
 // GUARD_NOCHECKS-SAME: "-cfguard-no-checks"
 // GUARD_NOCHECKS-NOT: "-cfguard"
-// GUARD_NOCHECKS-NEXT: ld"
+// GUARD_NOCHECKS-NEXT: ld{{(.lld)?}}{{(.exe)?}}"
 // GUARD_NOCHECKS-SAME: "--guard-cf"
 // GUARD_NOCHECKS-NOT: "--no-guard-cf"
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D131939: [clang-tidy] Add performance-expensive-flat-container-operation check

[Nicolas van Kempen via Phabricator via cfe-commits]

nicovank added a comment.

Mid-CppCon ping.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D131939/new/

https://reviews.llvm.org/D131939

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

[PATCH] D133771: Add a "Potentially Breaking Changes" section to the Clang release notes

[Fangrui Song via Phabricator via cfe-commits]

MaskRay accepted this revision.
MaskRay added inline comments.
Herald added a subscriber: StephenFan.



Comment at: clang/docs/ReleaseNotes.rst:49
+  present in major C++ implementations (including Clang), this error has the
+  ability to be downgraded into a warning (via: 
-Wno-error=enum-constexpr-conversion)
+  to provide a transition period for users. This diagnostic is expected to turn

sylvestre.ledru wrote:
> 
Two backsticks for rst :)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133771/new/

https://reviews.llvm.org/D133771

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

[PATCH] D133737: [HLSL] [clang] Add vector version of abs for HLSL

[Chris Bieneman via Phabricator via cfe-commits]

beanz added a comment.

In D133737#3785987 , @fhahn wrote:

> I'm not familiar with HLSL but I think making use of the existing vector 
> builtins makes sense here!

Does it make sense to be using the vector builtin for non-vectors?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133737/new/

https://reviews.llvm.org/D133737

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

[PATCH] D127910: [Clang][AArch64] Add SME C intrinsics for load and store

[Sagar Kulkarni via Phabricator via cfe-commits]

sagarkulkarni19 updated this revision to Diff 459803.
sagarkulkarni19 added a comment.

- Support Opaque pointers
- Correct predicate types for the intrinsics.
- Decorate intrinsics with SME attributes.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127910/new/

https://reviews.llvm.org/D127910

Files:
  clang/include/clang/Basic/TargetBuiltins.h
  clang/include/clang/Basic/arm_sve.td
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/Headers/CMakeLists.txt
  clang/test/CodeGen/aarch64-sme-intrinsics/acle_sme_ld1.c
  clang/test/CodeGen/aarch64-sme-intrinsics/acle_sme_ld1_vnum.c
  clang/test/CodeGen/aarch64-sme-intrinsics/acle_sme_st1.c
  clang/test/CodeGen/aarch64-sme-intrinsics/acle_sme_st1_vnum.c
  clang/utils/TableGen/SveEmitter.cpp
  clang/utils/TableGen/TableGen.cpp
  clang/utils/TableGen/TableGenBackends.h

Index: clang/utils/TableGen/TableGenBackends.h
===
--- clang/utils/TableGen/TableGenBackends.h
+++ clang/utils/TableGen/TableGenBackends.h
@@ -101,6 +101,8 @@
 void EmitSveTypeFlags(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 void EmitSveRangeChecks(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 
+void EmitSmeHeader(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
+
 void EmitMveHeader(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 void EmitMveBuiltinDef(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 void EmitMveBuiltinSema(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
Index: clang/utils/TableGen/TableGen.cpp
===
--- clang/utils/TableGen/TableGen.cpp
+++ clang/utils/TableGen/TableGen.cpp
@@ -81,6 +81,7 @@
   GenArmSveBuiltinCG,
   GenArmSveTypeFlags,
   GenArmSveRangeChecks,
+  GenArmSmeHeader,
   GenArmCdeHeader,
   GenArmCdeBuiltinDef,
   GenArmCdeBuiltinSema,
@@ -219,6 +220,8 @@
"Generate arm_sve_typeflags.inc for clang"),
 clEnumValN(GenArmSveRangeChecks, "gen-arm-sve-sema-rangechecks",
"Generate arm_sve_sema_rangechecks.inc for clang"),
+clEnumValN(GenArmSmeHeader, "gen-arm-sme-header",
+   "Generate arm_sme.h for clang"),
 clEnumValN(GenArmMveHeader, "gen-arm-mve-header",
"Generate arm_mve.h for clang"),
 clEnumValN(GenArmMveBuiltinDef, "gen-arm-mve-builtin-def",
@@ -438,6 +441,9 @@
   case GenArmSveRangeChecks:
 EmitSveRangeChecks(Records, OS);
 break;
+  case GenArmSmeHeader:
+EmitSmeHeader(Records, OS);
+break;
   case GenArmCdeHeader:
 EmitCdeHeader(Records, OS);
 break;
Index: clang/utils/TableGen/SveEmitter.cpp
===
--- clang/utils/TableGen/SveEmitter.cpp
+++ clang/utils/TableGen/SveEmitter.cpp
@@ -169,6 +169,11 @@
 
   SmallVector ImmChecks;
 
+  /// True if this is an SME intrinsic.
+  bool IsSMEIntrinsic;
+  /// Attributes for SME intrinsics.
+  std::string SMEAttributes;
+
 public:
   Intrinsic(StringRef Name, StringRef Proto, uint64_t MergeTy,
 StringRef MergeSuffix, uint64_t MemoryElementTy, StringRef LLVMName,
@@ -194,6 +199,10 @@
   uint64_t getFlags() const { return Flags; }
   bool isFlagSet(uint64_t Flag) const { return Flags & Flag;}
 
+  bool isSMEIntrinsic() const { return IsSMEIntrinsic; }
+  // Return a comma seperated string of SME attributes.
+  std::string getSMEAttributes() const { return SMEAttributes; }
+
   ArrayRef getImmChecks() const { return ImmChecks; }
 
   /// Return the type string for a BUILTIN() macro in Builtins.def.
@@ -334,6 +343,9 @@
   /// Emit arm_sve.h.
   void createHeader(raw_ostream &o);
 
+  /// Emit arm_sme.h.
+  void createSMEHeader(raw_ostream &o);
+
   /// Emit all the __builtin prototypes and code needed by Sema.
   void createBuiltins(raw_ostream &o);
 
@@ -347,7 +359,9 @@
   void createTypeFlags(raw_ostream &o);
 
   /// Create intrinsic and add it to \p Out
-  void createIntrinsic(Record *R, SmallVectorImpl> &Out);
+  void createIntrinsic(Record *R,
+   SmallVectorImpl> &Out,
+   bool IsSME = false);
 };
 
 } // end anonymous namespace
@@ -757,6 +771,11 @@
 NumVectors = 0;
 Signed = true;
 break;
+  case '%':
+Pointer = true;
+Void = true;
+NumVectors = 0;
+break;
   case 'A':
 Pointer = true;
 ElementBitwidth = Bitwidth = 8;
@@ -840,6 +859,16 @@
   this->Flags |= Emitter.encodeMergeType(MergeTy);
   if (hasSplat())
 this->Flags |= Emitter.encodeSplatOperand(getSplatIdx());
+
+  // Set attributes for SME intrinsics.
+  if (this->Flags & Emitter.getEnumValueForFlag("IsSME")) {
+this->IsSMEIntrinsic = true;
+if (this->Flags & Emitter.getEnumValueForFlag("IsSMELd1"))
+  this->SMEAttributes = "arm_streaming, arm_shared_za";
+else if (this->Flags & Emitter.getEnumValueForFlag("IsSMESt1"))
+  

[PATCH] D133737: [HLSL] [clang] Add vector version of abs for HLSL

[Simon Pilgrim via Phabricator via cfe-commits]

RKSimon added a comment.

The elementwise builtins should work for scalars as well (and IIRC we do test 
this as well).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133737/new/

https://reviews.llvm.org/D133737

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

[PATCH] D128845: [HLSL]Add -O and -Od option for dxc mode.

[Chris Bieneman via Phabricator via cfe-commits]

beanz added inline comments.



Comment at: clang/include/clang/Basic/TargetOptions.h:120
+  /// Keep the information about disable optimization for ShaderFlags.
+  bool DxcOptDisable = false;
 };

If `Od` and `O0` are the same you shouldn't need to track this, or have the 
extra command line option to set the flag, you should imply the shader flag 
from the optimization level.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D128845/new/

https://reviews.llvm.org/D128845

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