[PATCH] D103440: [WIP][analyzer] Introduce range-based reasoning for addition operator

[Manas Gupta via Phabricator via cfe-commits]

manas added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:1400
+  if (ResultType.isUnsigned()) {
+LHS.From().uadd_ov(RHS.From(), HasMinOverflowed);
+LHS.To().uadd_ov(RHS.To(), HasMaxOverflowed);

Using `uadd_ov` (and `sadd_ov`), we can get the added value as well as whether 
overflow occurred or not. A point is that these functions return `APInt` 
instead of `APSInt`.

But when I tried just using:
  Min = LHS.From().uadd_ov(RHS.From(), HasMinOverflowed);
  Max = LHS.To().uadd_ov(RHS.From(), HasMaxOverflowed);

instead of
  Min = LHS.From() + RHS.From();
  Max = LHS.To() + RHS.To();

just for the added value, then the following tests failed (//these tests and 
all other tests pass when I use the latter method to get Min/Max//):

  Clang :: Analysis/PR3991.m
  Clang :: Analysis/global-region-invalidation.c
  Clang :: Analysis/malloc-overflow2.c
  Clang :: Analysis/out-of-bounds-new.cpp
  Clang :: Analysis/taint-generic.c

I am working on fixing this part.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103440

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

[PATCH] D103440: [WIP][analyzer] Introduce range-based reasoning for addition operator

[Manas Gupta via Phabricator via cfe-commits]

manas updated this revision to Diff 354154.
manas added a comment.

Fix issues involving cases for unsigned type and add tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103440

Files:
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  clang/test/Analysis/constant-folding.c

Index: clang/test/Analysis/constant-folding.c
===
--- clang/test/Analysis/constant-folding.c
+++ clang/test/Analysis/constant-folding.c
@@ -251,3 +251,93 @@
 clang_analyzer_eval((b % a) < x + 10); // expected-warning{{TRUE}}
   }
 }
+
+void testAdditionRules(unsigned int a, unsigned int b, int c, int d) {
+  if (a == 0) {
+clang_analyzer_eval((a + 0) == 0); // expected-warning{{TRUE}}
+  }
+
+  // Checks for unsigned operands
+  clang_analyzer_eval((a + b) < 0); // expected-warning{{FALSE}}
+  clang_analyzer_eval((a + b) <= UINT_MAX); // expected-warning{{TRUE}}
+
+  if (a == UINT_MAX && b == UINT_MAX) {
+clang_analyzer_eval((a + b) == UINT_MAX - 1); // expected-warning{{TRUE}}
+  }
+
+  // Checks for inclusive ranges for unsigned integers
+  if (a <= 10 && b <= 20) {
+clang_analyzer_eval((a + b) >= 0); // expected-warning{{TRUE}}
+clang_analyzer_eval((a + b) > 30); // expected-warning{{FALSE}}
+  }
+
+  // Checks for negative signed integers
+  if (c < 0 && d < 0) {
+clang_analyzer_eval((c + d) != -1); // expected-warning{{TRUE}}
+  }
+
+  if (c < 0 && c != INT_MIN && d < 0) {
+clang_analyzer_eval((c + d) == -1); // expected-warning{{FALSE}}
+clang_analyzer_eval((c + d) == 0); // expected-warning{{FALSE}}
+clang_analyzer_eval((c + d) <= -2); // expected-warning{{UNKNOWN}}
+clang_analyzer_eval((c + d) >= 1); // expected-warning{{UNKNOWN}}
+  }
+
+  if (c == INT_MIN && d == INT_MIN) {
+clang_analyzer_eval((c + d) == 0); // expected-warning{{TRUE}}
+  }
+
+  if (c == INT_MIN && d < 0 && d != INT_MIN) {
+clang_analyzer_eval((c + d) > 0); // expected-warning{{TRUE}}
+  }
+
+  if (c < 0 && c >= -20 && d < 0 && d >= -40) {
+clang_analyzer_eval((c + d) < -1); // expected-warning{{TRUE}}
+clang_analyzer_eval((c + d) >= -60); // expected-warning{{TRUE}}
+  }
+
+  // Checks for integers with different sign bits
+  if (c < 0 && d > 0) {
+if (c >= -20 && d <= 10) {
+  clang_analyzer_eval((c + d) > -20); // expected-warning{{TRUE}}
+  clang_analyzer_eval((c + d) < 10); // expected-warning{{TRUE}}
+}
+  }
+
+  // Checks for overlapping signed integers ranges
+  if (c >= -20 && c <= 20 && d >= -10 && d <= 10) {
+clang_analyzer_eval((c + d) >= -30); // expected-warning{{TRUE}}
+clang_analyzer_eval((c + d) <= 30); // expected-warning{{TRUE}}
+  }
+
+  // Checks for positive signed integers
+  if (c > 0 && d > 0) {
+clang_analyzer_eval((c + d) == 1); // expected-warning{{FALSE}}
+clang_analyzer_eval((c + d) == 0); // expected-warning{{FALSE}}
+clang_analyzer_eval((c + d) == -1); // expected-warning{{FALSE}}
+  }
+
+  // Check when Max overflows from positive-side
+  if (c >= 10 && d >= 0 && d <= 10) {
+clang_analyzer_eval((c + d) == INT_MIN + 10); // expected-warning{{FALSE}}
+clang_analyzer_eval((c + d) == -1); // expected-warning{{FALSE}}
+  }
+
+  // Checks when Min overflows from negative side
+  if (c <= 10 && d >= -10 && d <= 0) {
+clang_analyzer_eval((c + d) == 11); // expected-warning{{FALSE}}
+clang_analyzer_eval((c + d) == INT_MAX - 10); // expected-warning{{FALSE}}
+  }
+
+  // Checks producing overflowing range with different signs
+  int HALF_INT_MAX = INT_MAX / 2;
+  if (c >= HALF_INT_MAX - 10 && c <= HALF_INT_MAX + 10 &&
+  d >= HALF_INT_MAX - 10 && d <= HALF_INT_MAX + 10) {
+// The resulting range for (c + d) will be:
+//   [INT_MIN, INT_MIN + 18] U [INT_MAX - 21, INT_MAX]
+clang_analyzer_eval((c + d) <= INT_MIN + 18); // expected-warning{{UNKNOWN}}
+clang_analyzer_eval((c + d) >= INT_MAX - 21); // expected-warning{{UNKNOWN}}
+clang_analyzer_eval((c + d) == INT_MIN + 19); // expected-warning{{FALSE}}
+clang_analyzer_eval((c + d) == INT_MAX - 22); // expected-warning{{FALSE}}
+  }
+}
Index: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -964,6 +964,8 @@
   return VisitBinaryOperator(LHS, RHS, T);
 case BO_Rem:
   return VisitBinaryOperator(LHS, RHS, T);
+case BO_Add:
+  return VisitBinaryOperator(LHS, RHS, T);
 default:
   return infer(T);
 }
@@ -1380,6 +1382,63 @@
   return {RangeFactory, ValueFactory.getValue(Min), ValueFactory.getValue(Max)};
 }
 
+template <>
+RangeSet SymbolicRangeInferrer::VisitBinaryOperator(Range LHS,
+Range RHS,
+   

[PATCH] D86671: [clang-tidy] Add new case type to check variables with Hungarian notation

[Grant Nossier via Phabricator via cfe-commits]

gnossier added a comment.

Is this ready to merge soon?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86671

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

[PATCH] D104837: [PowerPC] Add XL compat __compare_and_swap builtins

[Jinsong Ji via Phabricator via cfe-commits]

jsji created this revision.
jsji added reviewers: PowerPC, lkail, w2yehia.
Herald added subscribers: shchenz, jfb, kbarton, nemanjai.
jsji requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Prototype
int __compare_and_swap (volatile int* addr, int* old_val_addr, int
new_val);

int __compare_and_swaplp (volatile long* addr, long* old_val_addr, long
new_val);

Refer to
https://www.ibm.com/docs/en/xl-c-and-cpp-aix/16.1?topic=functions-compare-swap-compare-swaplp


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104837

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/Basic/Targets/PPC.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-ppc-xlcompat-cas-error.c
  clang/test/CodeGen/builtins-ppc-xlcompat-cas.c

Index: clang/test/CodeGen/builtins-ppc-xlcompat-cas.c
===
--- /dev/null
+++ clang/test/CodeGen/builtins-ppc-xlcompat-cas.c
@@ -0,0 +1,52 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// REQUIRES: powerpc-registered-target
+// RUN: %clang_cc1 -triple powerpc64-unknown-unknown \
+// RUN:-emit-llvm %s -o -  -target-cpu pwr8 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown \
+// RUN:   -emit-llvm %s -o -  -target-cpu pwr8 | FileCheck %s
+
+// CHECK-LABEL: @test_builtin_ppc_compare_and_swap(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[A:%.*]] = alloca i32, align 4
+// CHECK-NEXT:[[B:%.*]] = alloca i32, align 4
+// CHECK-NEXT:[[C:%.*]] = alloca i32, align 4
+// CHECK-NEXT:store volatile i32 0, i32* [[A]], align 4
+// CHECK-NEXT:store i32 0, i32* [[B]], align 4
+// CHECK-NEXT:store i32 0, i32* [[C]], align 4
+// CHECK-NEXT:[[TMP0:%.*]] = load i32, i32* [[C]], align 4
+// CHECK-NEXT:[[TMP1:%.*]] = load i32, i32* [[B]], align 4
+// CHECK-NEXT:[[TMP2:%.*]] = cmpxchg weak volatile i32* [[A]], i32 [[TMP1]], i32 [[TMP0]] monotonic monotonic, align 4
+// CHECK-NEXT:[[TMP3:%.*]] = extractvalue { i32, i1 } [[TMP2]], 0
+// CHECK-NEXT:[[TMP4:%.*]] = extractvalue { i32, i1 } [[TMP2]], 1
+// CHECK-NEXT:ret void
+//
+void test_builtin_ppc_compare_and_swap() {
+  volatile int a = 0;
+  int b = 0, c = 0;
+
+  __compare_and_swap(, , c);
+
+}
+
+// CHECK-LABEL: @test_builtin_ppc_compare_and_swaplp(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[A:%.*]] = alloca i64, align 8
+// CHECK-NEXT:[[B:%.*]] = alloca i64, align 8
+// CHECK-NEXT:[[C:%.*]] = alloca i64, align 8
+// CHECK-NEXT:store volatile i64 0, i64* [[A]], align 8
+// CHECK-NEXT:store i64 0, i64* [[B]], align 8
+// CHECK-NEXT:store i64 0, i64* [[C]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load i64, i64* [[C]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = load i64, i64* [[B]], align 8
+// CHECK-NEXT:[[TMP2:%.*]] = cmpxchg weak volatile i64* [[A]], i64 [[TMP1]], i64 [[TMP0]] monotonic monotonic, align 8
+// CHECK-NEXT:[[TMP3:%.*]] = extractvalue { i64, i1 } [[TMP2]], 0
+// CHECK-NEXT:[[TMP4:%.*]] = extractvalue { i64, i1 } [[TMP2]], 1
+// CHECK-NEXT:ret void
+//
+void test_builtin_ppc_compare_and_swaplp() {
+  volatile long a = 0;
+  long b = 0, c = 0;
+
+  __compare_and_swaplp(, , c);
+
+}
Index: clang/test/CodeGen/builtins-ppc-xlcompat-cas-error.c
===
--- /dev/null
+++ clang/test/CodeGen/builtins-ppc-xlcompat-cas-error.c
@@ -0,0 +1,19 @@
+// REQUIRES: powerpc-registered-target
+// RUN: %clang_cc1 -triple powerpc64-unknown-aix -target-cpu pwr8 \
+// RUN:   -verify %s
+
+void test_builtin_ppc_compare_and_swap() {
+  volatile int a = 0;
+  long b = 0, c = 0;
+
+  __compare_and_swap(, , c); // expected-warning {{incompatible pointer types passing 'long *' to parameter of type 'int *'}}
+
+}
+
+void test_builtin_ppc_compare_and_swaplp() {
+  volatile long a = 0;
+  int b = 0, c = 0;
+
+  __compare_and_swaplp(, , c);// expected-warning {{incompatible pointer types passing 'int *' to parameter of type 'long *'}}
+
+}
Index: clang/lib/CodeGen/CGBuiltin.cpp
===
--- clang/lib/CodeGen/CGBuiltin.cpp
+++ clang/lib/CodeGen/CGBuiltin.cpp
@@ -15427,6 +15427,18 @@
 Value *Call = Builder.CreateCall(F, CallOps);
 return Builder.CreateAlignedStore(Call, Ops[0], MaybeAlign(64));
   }
+
+  case PPC::BI__builtin_ppc_compare_and_swap:
+  case PPC::BI__builtin_ppc_compare_and_swaplp:
+Address Addr = EmitPointerWithAlignment(E->getArg(0));
+Address OldValAddr = EmitPointerWithAlignment(E->getArg(1));
+Value *OldVal = Builder.CreateLoad(OldValAddr);
+QualType AtomicTy = E->getArg(0)->getType()->getPointeeType();
+LValue LV = MakeAddrLValue(Addr, AtomicTy);
+auto Pair = EmitAtomicCompareExchange(
+LV, RValue::get(OldVal), RValue::get(Ops[2]), E->getExprLoc(),
+llvm::AtomicOrdering::Monotonic, 

[PATCH] D94355: [Passes] Add relative lookup table converter pass

[Peter Collingbourne via Phabricator via cfe-commits]

pcc added inline comments.
Herald added a subscriber: ormris.



Comment at: llvm/lib/Transforms/Utils/RelLookupTableConverter.cpp:73
+  return false;
+
+// If an operand in the lookup table is not dso_local,

In the version of the patch that you committed, you have this check here:
```
// If operand is mutable, do not generate a relative lookup table.
auto *GlovalVarOp = dyn_cast(GVOp);
if (!GlovalVarOp || !GlovalVarOp->isConstant())
  return false;
```
1. Nit: Gloval -> Global
2. Why is it important whether the referenced global is mutable? The pointer 
itself is constant.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94355

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

[PATCH] D104831: [clang] Add x86_64-redhat-linux-gnu as a platform triplet

[Tom Stellard via Phabricator via cfe-commits]

tstellar added a comment.

I'm curious, what kind of system are you running on where you need to use 
--gcc-toolchain x86_64-redhat-linux-gnu is required.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104831

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

[PATCH] D104777: PR50767: clear non-distinct debuginfo for function with nodebug definition after undecorated declaration

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

In D104777#2837347 , @brunodefraine 
wrote:

> In D104777#2836669 , @dblaikie 
> wrote:
>
>> Yeah, all that sounds reasonable to me - @brunodefraine could you look into 
>> supporting nodebug in a similar way as @aaron.ballman has described here?
>
> Since the debuginfo for `use()` is slightly affected by the `nodebug` version 
> of `t1()` that follows it, I can see how this back propagation is perhaps 
> dangerous. Checking that `nodebug` is the same on all declarations of a 
> function is a way to prevent this.
>
> But when discussing the PR, @probinson wrote "I'm inclined to think we want 
> this to work" and I can see what he means from the use case where I observed 
> the bug. If you don't want debuginfo for the implementation of `t1()`, it 
> should be fine to annotate just the function definition in an implementation 
> file, not the declaration in a header, since the debuginfo of the 
> implementation is not of the caller's concern. But `nodebug` as it exists 
> **does** affect the debuginfo of callers as well, so I cannot really express 
> that I don't want debuginfo for the implementation of a function and leave 
> its callers unaffected?

I can see the convenience there, to be sure, being able to put the attribute 
directly on the function you want to debug - but consistency in how attributes 
are handled (admitedly this isn't a strong consistency - some are handled this 
way, some aren't) & consistently seeing the same state for an attribute for a 
given function seems useful.

@probinson - thoughts?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104777

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

[PATCH] D104822: [RISCV] Add vget/vset intrinsics for inserting and extracting between different lmuls.

[Hsiangkai Wang via Phabricator via cfe-commits]

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

LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104822

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

[PATCH] D104505: [HIP] Defer operator overloading errors

[Yaxun Liu via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
yaxunl marked an inline comment as done.
Closed by commit rG82e03e494f98: [HIP] Defer operator overloading errors 
(authored by yaxunl).
Herald added a project: clang.

Changed prior to commit:
  https://reviews.llvm.org/D104505?vs=352862=354146#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104505

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Overload.h
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/test/SemaCUDA/deferred-oeverload.cu

Index: clang/test/SemaCUDA/deferred-oeverload.cu
===
--- clang/test/SemaCUDA/deferred-oeverload.cu
+++ clang/test/SemaCUDA/deferred-oeverload.cu
@@ -5,6 +5,11 @@
 // RUN: %clang_cc1 -fopenmp -fsyntax-only -verify=host,com %s \
 // RUN:   -std=c++11 -fgpu-defer-diag
 
+// With -fgpu-defer-diag, clang defers overloading resolution induced
+// diagnostics when the full candidates set include host device
+// functions or wrong-sided candidates. This roughly matches nvcc's
+// behavior.
+
 #include "Inputs/cuda.h"
 
 // When callee is called by a host function with integer arguments, there is an error for ambiguity.
@@ -31,12 +36,20 @@
 __host__ void callee5(float); // com-note {{candidate function}}
 __host__ void callee5(double); // com-note {{candidate function}}
 
+// When '<<` operator is called by a device function, there is error for 'invalid operands'.
+// It should be deferred since it involves wrong-sided candidates.
+struct S {
+  __host__ S  <<(int i); // dev-note {{candidate function not viable}}
+};
+
 __host__ void hf() {
  callee(1); // host-error {{call to 'callee' is ambiguous}}
  callee2();
  callee3();
  callee4(); // com-error {{no matching function for call to 'callee4'}}
  callee5(1); // com-error {{call to 'callee5' is ambiguous}}
+ S s;
+ s << 1;
  undeclared_func(); // com-error {{use of undeclared identifier 'undeclared_func'}}
 }
 
@@ -45,6 +58,8 @@
  callee2(); // dev-error {{no matching function for call to 'callee2'}}
  callee3(); // dev-error {{no matching function for call to 'callee3'}}
  callee4(); // com-error {{no matching function for call to 'callee4'}}
+ S s;
+ s << 1;// dev-error {{invalid operands to binary expression}}
 }
 
 struct A { int x; typedef int isA; };
Index: clang/lib/Sema/SemaOverload.cpp
===
--- clang/lib/Sema/SemaOverload.cpp
+++ clang/lib/Sema/SemaOverload.cpp
@@ -11641,7 +11641,8 @@
 CompleteCandidates(S, OCD_AllCandidates, Args, OpLoc, [](auto ) {
   return (Cand.Viable == false &&
   Cand.FailureKind == ovl_fail_bad_target) ||
- (Cand.Function->template hasAttr() &&
+ (Cand.Function &&
+  Cand.Function->template hasAttr() &&
   Cand.Function->template hasAttr());
 });
 DeferHint = !WrongSidedCands.empty();
@@ -13820,6 +13821,8 @@
   StringRef OpcStr = BinaryOperator::getOpcodeStr(Opc);
   auto Cands = CandidateSet.CompleteCandidates(*this, OCD_AllCandidates,
Args, OpLoc);
+  DeferDiagsRAII DDR(*this,
+ CandidateSet.shouldDeferDiags(*this, Args, OpLoc));
   if (Args[0]->getType()->isRecordType() &&
   Opc >= BO_Assign && Opc <= BO_OrAssign) {
 Diag(OpLoc,  diag::err_ovl_no_viable_oper)
Index: clang/lib/Sema/Sema.cpp
===
--- clang/lib/Sema/Sema.cpp
+++ clang/lib/Sema/Sema.cpp
@@ -1790,7 +1790,7 @@
   bool IsError = Diags.getDiagnosticIDs()->isDefaultMappingAsError(DiagID);
   bool ShouldDefer = getLangOpts().CUDA && LangOpts.GPUDeferDiag &&
  DiagnosticIDs::isDeferrable(DiagID) &&
- (DeferHint || !IsError);
+ (DeferHint || DeferDiags || !IsError);
   auto SetIsLastErrorImmediate = [&](bool Flag) {
 if (IsError)
   IsLastErrorImmediate = Flag;
Index: clang/include/clang/Sema/Sema.h
===
--- clang/include/clang/Sema/Sema.h
+++ clang/include/clang/Sema/Sema.h
@@ -1769,6 +1769,22 @@
   /// Build a partial diagnostic.
   PartialDiagnostic PDiag(unsigned DiagID = 0); // in SemaInternal.h
 
+  /// Whether deferrable diagnostics should be deferred.
+  bool DeferDiags = false;
+
+  /// RAII class to control scope of DeferDiags.
+  class DeferDiagsRAII {
+Sema 
+bool SavedDeferDiags = false;
+
+  public:
+DeferDiagsRAII(Sema &_S, bool DeferDiags)
+: S(_S), SavedDeferDiags(S.DeferDiags) {
+  S.DeferDiags = DeferDiags;
+}
+~DeferDiagsRAII() { S.DeferDiags = 

[clang] 82e03e4 - [HIP] Defer operator overloading errors

[Yaxun Liu via cfe-commits]

Author: Yaxun (Sam) Liu
Date: 2021-06-23T23:39:59-04:00
New Revision: 82e03e494f9884e03b1ab4dfd3b55e6aa2161ade

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

LOG: [HIP] Defer operator overloading errors

Although clang is able to defer overloading resolution
diagnostics for common functions. It does not defer
overloading resolution caused diagnostics for overloaded
operators.

This patch extends the existing deferred
diagnostic mechanism and defers a diagnostic caused
by overloaded operator.

Reviewed by: Artem Belevich

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

Added: 


Modified: 
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/include/clang/Sema/Overload.h
clang/include/clang/Sema/Sema.h
clang/lib/Sema/Sema.cpp
clang/lib/Sema/SemaOverload.cpp
clang/test/SemaCUDA/deferred-oeverload.cu

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 33aa5d0483e9c..b114cdff1d94a 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -6771,7 +6771,7 @@ def warn_param_mismatched_alignment : Warning<
 def err_objc_object_assignment : Error<
   "cannot assign to class object (%0 invalid)">;
 def err_typecheck_invalid_operands : Error<
-  "invalid operands to binary expression (%0 and %1)">;
+  "invalid operands to binary expression (%0 and %1)">, Deferrable;
 def note_typecheck_invalid_operands_converted : Note<
   "%select{first|second}0 operand was implicitly converted to type %1">;
 def err_typecheck_logical_vector_expr_gnu_cpp_restrict : Error<

diff  --git a/clang/include/clang/Sema/Overload.h 
b/clang/include/clang/Sema/Overload.h
index 699c3e8088726..82661cb3d12ac 100644
--- a/clang/include/clang/Sema/Overload.h
+++ b/clang/include/clang/Sema/Overload.h
@@ -1048,9 +1048,6 @@ class Sema;
 
 void destroyCandidates();
 
-/// Whether diagnostics should be deferred.
-bool shouldDeferDiags(Sema , ArrayRef Args, SourceLocation 
OpLoc);
-
   public:
 OverloadCandidateSet(SourceLocation Loc, CandidateSetKind CSK,
  OperatorRewriteInfo RewriteInfo = {})
@@ -1063,6 +1060,9 @@ class Sema;
 CandidateSetKind getKind() const { return Kind; }
 OperatorRewriteInfo getRewriteInfo() const { return RewriteInfo; }
 
+/// Whether diagnostics should be deferred.
+bool shouldDeferDiags(Sema , ArrayRef Args, SourceLocation 
OpLoc);
+
 /// Determine when this overload candidate will be new to the
 /// overload set.
 bool isNewCandidate(Decl *F, OverloadCandidateParamOrder PO =

diff  --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 5a9ed8519e765..d50d2dd83530e 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -1769,6 +1769,22 @@ class Sema final {
   /// Build a partial diagnostic.
   PartialDiagnostic PDiag(unsigned DiagID = 0); // in SemaInternal.h
 
+  /// Whether deferrable diagnostics should be deferred.
+  bool DeferDiags = false;
+
+  /// RAII class to control scope of DeferDiags.
+  class DeferDiagsRAII {
+Sema 
+bool SavedDeferDiags = false;
+
+  public:
+DeferDiagsRAII(Sema &_S, bool DeferDiags)
+: S(_S), SavedDeferDiags(S.DeferDiags) {
+  S.DeferDiags = DeferDiags;
+}
+~DeferDiagsRAII() { S.DeferDiags = SavedDeferDiags; }
+  };
+
   /// Whether uncompilable error has occurred. This includes error happens
   /// in deferred diagnostics.
   bool hasUncompilableErrorOccurred() const;

diff  --git a/clang/lib/Sema/Sema.cpp b/clang/lib/Sema/Sema.cpp
index b450216dcc8b7..e2d46e3bf9383 100644
--- a/clang/lib/Sema/Sema.cpp
+++ b/clang/lib/Sema/Sema.cpp
@@ -1790,7 +1790,7 @@ Sema::SemaDiagnosticBuilder Sema::Diag(SourceLocation 
Loc, unsigned DiagID,
   bool IsError = Diags.getDiagnosticIDs()->isDefaultMappingAsError(DiagID);
   bool ShouldDefer = getLangOpts().CUDA && LangOpts.GPUDeferDiag &&
  DiagnosticIDs::isDeferrable(DiagID) &&
- (DeferHint || !IsError);
+ (DeferHint || DeferDiags || !IsError);
   auto SetIsLastErrorImmediate = [&](bool Flag) {
 if (IsError)
   IsLastErrorImmediate = Flag;

diff  --git a/clang/lib/Sema/SemaOverload.cpp b/clang/lib/Sema/SemaOverload.cpp
index 2801c3cff8afc..606cc56989867 100644
--- a/clang/lib/Sema/SemaOverload.cpp
+++ b/clang/lib/Sema/SemaOverload.cpp
@@ -11641,7 +11641,8 @@ bool OverloadCandidateSet::shouldDeferDiags(Sema , 
ArrayRef Args,
 CompleteCandidates(S, OCD_AllCandidates, Args, OpLoc, [](auto ) {
   return (Cand.Viable == false &&
   Cand.FailureKind == ovl_fail_bad_target) ||
- 

[PATCH] D104058: ThinLTO: Fix inline assembly references to static functions with CFI

[Sami Tolvanen via Phabricator via cfe-commits]

samitolvanen added a comment.

Thanks for the revert, I'll take a look.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104058

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

[PATCH] D99487: [CodeGen] Port basic block sections from ELF to COFF

[TaoPan via Phabricator via cfe-commits]

TaoPan added a comment.

In D99487#2832079 , @modimo wrote:

> In D99487#2821343 , @TaoPan wrote:
>
>> I checked the microsoft SEH tests with
>>
>> 1. cl.exe
>>
>>   a. x4ptcu.c: build error
>> 2. clang-cl.exe + lld linker
>>
>>   a. x4ptcu.c: build error
>>
>>   b. seh0015.c, seh0017.c: build crash
>>
>>   c. seh0034.c, seh0036.c, seh0041~0043.c, seh0048~0050.c, another build 
>> crash
>>
>>   d. seh0020.c, seh0025, seh0026: build error
>>
>>   e. sehframes.cpp: build pass, run dead loop
>
> Please file bugs for these and if you can bucket the failures that would be 
> even better. Thanks!

I'll file these bugs and try to bucket the failures in parallel.




Comment at: llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp:1712
+  COFF::IMAGE_SCN_MEM_READ | COFF::IMAGE_SCN_LNK_COMDAT,
+  SectionKind::getText(), COMDATSymName,
+  COFF::IMAGE_COMDAT_SELECT_NODUPLICATES, UniqueID);

TaoPan wrote:
> mstorsjo wrote:
> > rnk wrote:
> > > mstorsjo wrote:
> > > > TaoPan wrote:
> > > > > rnk wrote:
> > > > > > tmsriram wrote:
> > > > > > > MaskRay wrote:
> > > > > > > > TaoPan wrote:
> > > > > > > > > tmsriram wrote:
> > > > > > > > > > COMDATSymName can be folded to be equal to 
> > > > > > > > > > MBB.getSymbol()->getName() here?  Plus, you are not 
> > > > > > > > > > preserving the .text.hot prefix that the original function 
> > > > > > > > > > might get here.  Is this future work?  If the original 
> > > > > > > > > > function is named .text.hot.foo, the basic block will still 
> > > > > > > > > > be named .text.foo.__part.1 which is not right.
> > > > > > > > > > 
> > > > > > > > > > Plus, what about exception handling sections like ".eh.*"?
> > > > > > > > > Thanks! I'll redesign section name and comdat symbol name.
> > > > > > > > > The text section with prefix "hot" and "unlikely" won't be 
> > > > > > > > > constructed here, I added COFF text section prefix "hot" and 
> > > > > > > > > "unlikely" in D92073. In ELF override function, also not 
> > > > > > > > > handling text section with prefix "hot" and "unlikely".
> > > > > > > > > The text section with prefix "split" will be constructed 
> > > > > > > > > here, I plan to add related code in MFS COFF patch.
> > > > > > > > > Also, exception handling section is future work that support 
> > > > > > > > > basic block sections Windows COFF exception handling.
> > > > > > > > This is complex. PE-COFF has multiple COMDAT seletion kinds. I 
> > > > > > > > want to see a holistic plan how every component is going to be 
> > > > > > > > implemented.
> > > > > > > The basic block should just mimic the COMDAT type of its 
> > > > > > > containing function, is there a reason to do anything more with 
> > > > > > > it here?
> > > > > > After thinking about it a bit, I think the entry block should use 
> > > > > > the regular selection kind, and all of the auxilliary MBB sections 
> > > > > > should use IMAGE_COMDAT_SELECT_ASSOCIATIVE. They should be 
> > > > > > associated with the main function symbol, unless the function 
> > > > > > itself is associated with something else, in which case the BBs use 
> > > > > > that symbol.
> > > > > > 
> > > > > > This will ensure that if the main function section prevails, they 
> > > > > > are included, and if it does not prevail, they are discarded. Does 
> > > > > > that make sense?
> > > > > Thanks! I think set entry block sections as regular 
> > > > > IMAGE_COMDAT_SELECT_NODUPLICATES and set the auxilliary MBB sections 
> > > > > as IMAGE_COMDAT_SELECT_ASSOCIATIVE is fine. I changed.
> > > > @rnk - I'm not quite familiar with the concrete implications of this 
> > > > work here, but would this need to be mapped to the GNU style comdats, 
> > > > for compatibility with ld.bfd for mingw targets? (LLD itself works fine 
> > > > with proper associative comdats though.)
> > > I think basic block sections are kind of in the same category as LTO: 
> > > it's a very sophisticated optimization feature, and it's probably OK if 
> > > it's LLD-only. I think it also requires special linker support that might 
> > > make it LLD-only, but I've forgotten the details.
> > > 
> > > It also has potentially very high object file size overhead, and it will 
> > > be important to do everything possible to minimize that object file size 
> > > overhead. Long gnu-style section names for every basic block section are 
> > > likely to make the feature unusably slow, so maybe it's worth removing 
> > > these "if mingw" conditionals. We can leave behind a comment by the use 
> > > of IMAGE_COMDAT_SELECT_ASSOCIATIVE indicating that gnu-style section 
> > > names are not needed because the feature is only designed to work with 
> > > LLD.
> > Thanks for the clarification! Leaving the feature as LLD-only (or in other 
> > terms, requiring a conforming COMDAT implementation) sounds good to me.
> Thanks for discussion between 

[PATCH] D104058: ThinLTO: Fix inline assembly references to static functions with CFI

[Zequan Wu via Phabricator via cfe-commits]

zequanwu added a comment.

Hi, this caused compiler crash: "Assertion `materialized_use_empty() && "Uses 
remain when a value is destroyed!"'" on chromium build 
https://ci.chromium.org/ui/p/chromium/builders/try/linux-official/151/overview.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104058

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

[PATCH] D104831: [clang] Add x86_64-redhat-linux-gnu as a platform triplet

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

> Adding the platform tripplet x86_64-redhat-linux-gnu the while list of 
> supported x86_64 triplets so that it can be used with the --gcc-toolchain 
> option to bypass this process and force-pick a given gcc install.

Did you set `--target=x86_64-redhat-linux-gnu`? With that I don't think you 
need another entry in `X86_64Triples`.

`X86_64Triples` and its friends are quite clumsy and many entries are not 
actually needed. We should shrink the lists.

For https://bugzilla.redhat.com/show_bug.cgi?id=1824365 I think the right fix 
is to configure clang with x86_64-redhat-linux-gnu as the default triple.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104831

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

[PATCH] D104830: AST: Create __va_list in the std namespace even in C.

[Peter Collingbourne via Phabricator via cfe-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGe655e74a318e: AST: Create __va_list in the std namespace 
even in C. (authored by pcc).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104830

Files:
  clang/lib/AST/ASTContext.cpp
  clang/test/CodeGen/aarch64-varargs.c
  clang/test/CodeGen/arm64-be-hfa-vararg.c
  clang/test/CodeGen/cfi-icall-va-list.c
  clang/test/Headers/stdarg.cpp

Index: clang/test/Headers/stdarg.cpp
===
--- clang/test/Headers/stdarg.cpp
+++ clang/test/Headers/stdarg.cpp
@@ -15,7 +15,7 @@
 
 #include 
 
-// AARCH64-C: define {{.*}} @f(i32 %n, %struct.__va_list* %list)
+// AARCH64-C: define {{.*}} @f(i32 %n, %"struct.std::__va_list"* %list)
 // AARCH64-CXX: define {{.*}} @_Z1fiSt9__va_list(i32 %n, %"struct.std::__va_list"* %list)
 // X86_64-C: define {{.*}} @f(i32 %n, %struct.__va_list_tag* %list)
 // X86_64-CXX: define {{.*}} @_Z1fiP13__va_list_tag(i32 %n, %struct.__va_list_tag* %list)
Index: clang/test/CodeGen/cfi-icall-va-list.c
===
--- /dev/null
+++ clang/test/CodeGen/cfi-icall-va-list.c
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -triple aarch64-unknown-linux -fsanitize=cfi-icall -fsanitize-trap=cfi-icall -emit-llvm -o - %s | FileCheck %s
+
+// CHECK: define dso_local void @f({{.*}} !type [[TYPE:![0-9]+]] !type [[TYPE_GENERALIZED:![0-9]+]]
+void f(__builtin_va_list l) {}
+
+// CHECK-DAG: [[TYPE]] = !{i64 0, !"_ZTSFvSt9__va_listE"}
+// CHECK-DAG: [[TYPE_GENERALIZED]] = !{i64 0, !"_ZTSFvSt9__va_listE.generalized"}
Index: clang/test/CodeGen/arm64-be-hfa-vararg.c
===
--- clang/test/CodeGen/arm64-be-hfa-vararg.c
+++ clang/test/CodeGen/arm64-be-hfa-vararg.c
@@ -4,12 +4,12 @@
 
 // A single member HFA must be aligned just like a non-HFA register argument.
 double callee(int a, ...) {
-// CHECK: [[REGPP:%.*]] = getelementptr inbounds %struct.__va_list, %struct.__va_list* [[VA:%.*]], i32 0, i32 2
+// CHECK: [[REGPP:%.*]] = getelementptr inbounds %"struct.std::__va_list", %"struct.std::__va_list"* [[VA:%.*]], i32 0, i32 2
 // CHECK: [[REGP:%.*]] = load i8*, i8** [[REGPP]], align 8
 // CHECK: [[OFFSET0:%.*]] = getelementptr inbounds i8, i8* [[REGP]], i32 {{.*}}
 // CHECK: [[OFFSET1:%.*]] = getelementptr inbounds i8, i8* [[OFFSET0]], i64 8
 
-// CHECK: [[MEMPP:%.*]] = getelementptr inbounds %struct.__va_list, %struct.__va_list* [[VA:%.*]], i32 0, i32 0
+// CHECK: [[MEMPP:%.*]] = getelementptr inbounds %"struct.std::__va_list", %"struct.std::__va_list"* [[VA:%.*]], i32 0, i32 0
 // CHECK: [[MEMP:%.*]] = load i8*, i8** [[MEMPP]], align 8
 // CHECK: [[NEXTP:%.*]] = getelementptr inbounds i8, i8* [[MEMP]], i64 8
 // CHECK: store i8* [[NEXTP]], i8** [[MEMPP]], align 8
Index: clang/test/CodeGen/aarch64-varargs.c
===
--- clang/test/CodeGen/aarch64-varargs.c
+++ clang/test/CodeGen/aarch64-varargs.c
@@ -11,18 +11,18 @@
 int simple_int(void) {
 // CHECK-LABEL: define{{.*}} i32 @simple_int
   return va_arg(the_list, int);
-// CHECK: [[GR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
+// CHECK: [[GR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds (%"struct.std::__va_list", %"struct.std::__va_list"* @the_list, i32 0, i32 3)
 // CHECK: [[EARLY_ONSTACK:%[a-z_0-9]+]] = icmp sge i32 [[GR_OFFS]], 0
 // CHECK: br i1 [[EARLY_ONSTACK]], label %[[VAARG_ON_STACK:[a-z_.0-9]+]], label %[[VAARG_MAYBE_REG:[a-z_.0-9]+]]
 
 // CHECK: [[VAARG_MAYBE_REG]]
 // CHECK: [[NEW_REG_OFFS:%[a-z_0-9]+]] = add i32 [[GR_OFFS]], 8
-// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
+// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds (%"struct.std::__va_list", %"struct.std::__va_list"* @the_list, i32 0, i32 3)
 // CHECK: [[INREG:%[a-z_0-9]+]] = icmp sle i32 [[NEW_REG_OFFS]], 0
 // CHECK: br i1 [[INREG]], label %[[VAARG_IN_REG:[a-z_.0-9]+]], label %[[VAARG_ON_STACK]]
 
 // CHECK: [[VAARG_IN_REG]]
-// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 1)
+// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%"struct.std::__va_list", %"struct.std::__va_list"* @the_list, i32 0, i32 1)
 // CHECK: [[REG_ADDR:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[REG_TOP]], i32 [[GR_OFFS]]
 // CHECK-BE: [[REG_ADDR_ALIGNED:%[0-9]+]] = getelementptr inbounds i8, i8* [[REG_ADDR]], i64 4
 // CHECK-BE: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast i8* [[REG_ADDR_ALIGNED]] to 

[clang] e655e74 - AST: Create __va_list in the std namespace even in C.

[Peter Collingbourne via cfe-commits]

Author: Peter Collingbourne
Date: 2021-06-23T18:59:10-07:00
New Revision: e655e74a318e0b4140391ae18725300c7f0629f6

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

LOG: AST: Create __va_list in the std namespace even in C.

This ensures that the mangled type names match between C and C++,
which is significant when using -fsanitize=cfi-icall. Ideally we
wouldn't have created this namespace at all, but it's now part of
the ABI (e.g. in mangled names), so we can't change it.

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

Added: 
clang/test/CodeGen/cfi-icall-va-list.c

Modified: 
clang/lib/AST/ASTContext.cpp
clang/test/CodeGen/aarch64-varargs.c
clang/test/CodeGen/arm64-be-hfa-vararg.c
clang/test/Headers/stdarg.cpp

Removed: 




diff  --git a/clang/lib/AST/ASTContext.cpp b/clang/lib/AST/ASTContext.cpp
index a1f3baf997046..47f30f5ff9a41 100644
--- a/clang/lib/AST/ASTContext.cpp
+++ b/clang/lib/AST/ASTContext.cpp
@@ -7998,19 +7998,21 @@ static TypedefDecl 
*CreateVoidPtrBuiltinVaListDecl(const ASTContext *Context) {
 
 static TypedefDecl *
 CreateAArch64ABIBuiltinVaListDecl(const ASTContext *Context) {
-  // struct __va_list
   RecordDecl *VaListTagDecl = Context->buildImplicitRecord("__va_list");
-  if (Context->getLangOpts().CPlusPlus) {
-// namespace std { struct __va_list {
-NamespaceDecl *NS;
-NS = NamespaceDecl::Create(const_cast(*Context),
-   Context->getTranslationUnitDecl(),
-   /*Inline*/ false, SourceLocation(),
-   SourceLocation(), >Idents.get("std"),
-   /*PrevDecl*/ nullptr);
-NS->setImplicit();
-VaListTagDecl->setDeclContext(NS);
-  }
+  // namespace std { struct __va_list {
+  // Note that we create the namespace even in C. This is intentional so that
+  // the type is consistent between C and C++, which is important in cases 
where
+  // the types need to match between translation units (e.g. with
+  // -fsanitize=cfi-icall). Ideally we wouldn't have created this namespace at
+  // all, but it's now part of the ABI (e.g. in mangled names), so we can't
+  // change it.
+  auto *NS = NamespaceDecl::Create(
+  const_cast(*Context), Context->getTranslationUnitDecl(),
+  /*Inline*/ false, SourceLocation(), SourceLocation(),
+  >Idents.get("std"),
+  /*PrevDecl*/ nullptr);
+  NS->setImplicit();
+  VaListTagDecl->setDeclContext(NS);
 
   VaListTagDecl->startDefinition();
 

diff  --git a/clang/test/CodeGen/aarch64-varargs.c 
b/clang/test/CodeGen/aarch64-varargs.c
index 908fb4ae5d10e..397d61616b916 100644
--- a/clang/test/CodeGen/aarch64-varargs.c
+++ b/clang/test/CodeGen/aarch64-varargs.c
@@ -11,18 +11,18 @@ va_list the_list;
 int simple_int(void) {
 // CHECK-LABEL: define{{.*}} i32 @simple_int
   return va_arg(the_list, int);
-// CHECK: [[GR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds 
(%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
+// CHECK: [[GR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds 
(%"struct.std::__va_list", %"struct.std::__va_list"* @the_list, i32 0, i32 3)
 // CHECK: [[EARLY_ONSTACK:%[a-z_0-9]+]] = icmp sge i32 [[GR_OFFS]], 0
 // CHECK: br i1 [[EARLY_ONSTACK]], label %[[VAARG_ON_STACK:[a-z_.0-9]+]], 
label %[[VAARG_MAYBE_REG:[a-z_.0-9]+]]
 
 // CHECK: [[VAARG_MAYBE_REG]]
 // CHECK: [[NEW_REG_OFFS:%[a-z_0-9]+]] = add i32 [[GR_OFFS]], 8
-// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds 
(%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
+// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds 
(%"struct.std::__va_list", %"struct.std::__va_list"* @the_list, i32 0, i32 3)
 // CHECK: [[INREG:%[a-z_0-9]+]] = icmp sle i32 [[NEW_REG_OFFS]], 0
 // CHECK: br i1 [[INREG]], label %[[VAARG_IN_REG:[a-z_.0-9]+]], label 
%[[VAARG_ON_STACK]]
 
 // CHECK: [[VAARG_IN_REG]]
-// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds 
(%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 1)
+// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds 
(%"struct.std::__va_list", %"struct.std::__va_list"* @the_list, i32 0, i32 1)
 // CHECK: [[REG_ADDR:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* 
[[REG_TOP]], i32 [[GR_OFFS]]
 // CHECK-BE: [[REG_ADDR_ALIGNED:%[0-9]+]] = getelementptr inbounds i8, i8* 
[[REG_ADDR]], i64 4
 // CHECK-BE: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast i8* [[REG_ADDR_ALIGNED]] 
to i32*
@@ -30,9 +30,9 @@ int simple_int(void) {
 // CHECK: br label %[[VAARG_END:[a-z._0-9]+]]
 
 // CHECK: [[VAARG_ON_STACK]]
-// CHECK: [[STACK:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds 
(%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
+// CHECK: 

[PATCH] D104831: [clang] Add x86_64-redhat-linux-gnu as a platform triplet

[Hongtao Yu via Phabricator via cfe-commits]

hoy updated this revision to Diff 354135.
hoy added a comment.

Updating D104831 : [clang] Add 
x86_64-redhat-linux-gnu as a platform triplet


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104831

Files:
  clang/lib/Driver/ToolChains/Gnu.cpp


Index: clang/lib/Driver/ToolChains/Gnu.cpp
===
--- clang/lib/Driver/ToolChains/Gnu.cpp
+++ clang/lib/Driver/ToolChains/Gnu.cpp
@@ -2100,12 +2100,13 @@
 
   static const char *const X86_64LibDirs[] = {"/lib64", "/lib"};
   static const char *const X86_64Triples[] = {
-  "x86_64-linux-gnu",   "x86_64-unknown-linux-gnu",
-  "x86_64-pc-linux-gnu","x86_64-redhat-linux6E",
-  "x86_64-redhat-linux","x86_64-suse-linux",
-  "x86_64-manbo-linux-gnu", "x86_64-linux-gnu",
-  "x86_64-slackware-linux", "x86_64-unknown-linux",
-  "x86_64-amazon-linux","x86_64-linux-android"};
+  "x86_64-linux-gnu", "x86_64-unknown-linux-gnu",
+  "x86_64-pc-linux-gnu",  "x86_64-redhat-linux6E",
+  "x86_64-redhat-linux",  "x86_64-redhat-linux-gnu",
+  "x86_64-suse-linux","x86_64-manbo-linux-gnu",
+  "x86_64-linux-gnu", "x86_64-slackware-linux",
+  "x86_64-unknown-linux", "x86_64-amazon-linux",
+  "x86_64-linux-android"};
   static const char *const X32Triples[] = {"x86_64-linux-gnux32",
"x86_64-pc-linux-gnux32"};
   static const char *const X32LibDirs[] = {"/libx32", "/lib"};


Index: clang/lib/Driver/ToolChains/Gnu.cpp
===
--- clang/lib/Driver/ToolChains/Gnu.cpp
+++ clang/lib/Driver/ToolChains/Gnu.cpp
@@ -2100,12 +2100,13 @@
 
   static const char *const X86_64LibDirs[] = {"/lib64", "/lib"};
   static const char *const X86_64Triples[] = {
-  "x86_64-linux-gnu",   "x86_64-unknown-linux-gnu",
-  "x86_64-pc-linux-gnu","x86_64-redhat-linux6E",
-  "x86_64-redhat-linux","x86_64-suse-linux",
-  "x86_64-manbo-linux-gnu", "x86_64-linux-gnu",
-  "x86_64-slackware-linux", "x86_64-unknown-linux",
-  "x86_64-amazon-linux","x86_64-linux-android"};
+  "x86_64-linux-gnu", "x86_64-unknown-linux-gnu",
+  "x86_64-pc-linux-gnu",  "x86_64-redhat-linux6E",
+  "x86_64-redhat-linux",  "x86_64-redhat-linux-gnu",
+  "x86_64-suse-linux","x86_64-manbo-linux-gnu",
+  "x86_64-linux-gnu", "x86_64-slackware-linux",
+  "x86_64-unknown-linux", "x86_64-amazon-linux",
+  "x86_64-linux-android"};
   static const char *const X32Triples[] = {"x86_64-linux-gnux32",
"x86_64-pc-linux-gnux32"};
   static const char *const X32LibDirs[] = {"/libx32", "/lib"};
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D104831: [clang] Add x86_64-redhat-linux-gnu as a platform triplet

[Hongtao Yu via Phabricator via cfe-commits]

hoy created this revision.
Herald added subscribers: modimo, wenlei, pengfei.
hoy requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Clang requires a valid/compatible installation of gcc from which it includes 
some internal headers. Typically clang automatically detects the correct 
installation of gcc from the set of  gcc's installed on the system at standard 
locations. Adding the platform tripplet `x86_64-redhat-linux-gnu`the while list 
of supported x86_64 triplets so that it can be used with the `--gcc-toolchain` 
option to bypass this process and force-pick a given gcc install.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104831

Files:
  clang/lib/Driver/ToolChains/Gnu.cpp


Index: clang/lib/Driver/ToolChains/Gnu.cpp
===
--- clang/lib/Driver/ToolChains/Gnu.cpp
+++ clang/lib/Driver/ToolChains/Gnu.cpp
@@ -2100,12 +2100,13 @@
 
   static const char *const X86_64LibDirs[] = {"/lib64", "/lib"};
   static const char *const X86_64Triples[] = {
-  "x86_64-linux-gnu",   "x86_64-unknown-linux-gnu",
-  "x86_64-pc-linux-gnu","x86_64-redhat-linux6E",
-  "x86_64-redhat-linux","x86_64-suse-linux",
-  "x86_64-manbo-linux-gnu", "x86_64-linux-gnu",
-  "x86_64-slackware-linux", "x86_64-unknown-linux",
-  "x86_64-amazon-linux","x86_64-linux-android"};
+  "x86_64-linux-gnu","x86_64-unknown-linux-gnu",
+  "x86_64-pc-linux-gnu", "x86_64-redhat-linux6E",
+  "x86_64-redhat-linux-gnu", "x86_64-redhat-linux",
+  "x86_64-suse-linux",   "x86_64-manbo-linux-gnu",
+  "x86_64-linux-gnu","x86_64-slackware-linux",
+  "x86_64-unknown-linux","x86_64-amazon-linux",
+  "x86_64-linux-android"};
   static const char *const X32Triples[] = {"x86_64-linux-gnux32",
"x86_64-pc-linux-gnux32"};
   static const char *const X32LibDirs[] = {"/libx32", "/lib"};


Index: clang/lib/Driver/ToolChains/Gnu.cpp
===
--- clang/lib/Driver/ToolChains/Gnu.cpp
+++ clang/lib/Driver/ToolChains/Gnu.cpp
@@ -2100,12 +2100,13 @@
 
   static const char *const X86_64LibDirs[] = {"/lib64", "/lib"};
   static const char *const X86_64Triples[] = {
-  "x86_64-linux-gnu",   "x86_64-unknown-linux-gnu",
-  "x86_64-pc-linux-gnu","x86_64-redhat-linux6E",
-  "x86_64-redhat-linux","x86_64-suse-linux",
-  "x86_64-manbo-linux-gnu", "x86_64-linux-gnu",
-  "x86_64-slackware-linux", "x86_64-unknown-linux",
-  "x86_64-amazon-linux","x86_64-linux-android"};
+  "x86_64-linux-gnu","x86_64-unknown-linux-gnu",
+  "x86_64-pc-linux-gnu", "x86_64-redhat-linux6E",
+  "x86_64-redhat-linux-gnu", "x86_64-redhat-linux",
+  "x86_64-suse-linux",   "x86_64-manbo-linux-gnu",
+  "x86_64-linux-gnu","x86_64-slackware-linux",
+  "x86_64-unknown-linux","x86_64-amazon-linux",
+  "x86_64-linux-android"};
   static const char *const X32Triples[] = {"x86_64-linux-gnux32",
"x86_64-pc-linux-gnux32"};
   static const char *const X32LibDirs[] = {"/libx32", "/lib"};
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D104822: [RISCV] Add vget/vset intrinsics for inserting and extracting between different lmuls.

[Jiejie Rong via Phabricator via cfe-commits]

JojoR added a comment.

Thanks for your commit :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104822

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

[PATCH] D104830: AST: Create __va_list in the std namespace even in C.

[Evgenii Stepanov via Phabricator via cfe-commits]

eugenis added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104830

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

[PATCH] D104830: AST: Create __va_list in the std namespace even in C.

[Peter Collingbourne via Phabricator via cfe-commits]

pcc updated this revision to Diff 354130.
pcc added a comment.

Add test


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104830

Files:
  clang/lib/AST/ASTContext.cpp
  clang/test/CodeGen/aarch64-varargs.c
  clang/test/CodeGen/arm64-be-hfa-vararg.c
  clang/test/CodeGen/cfi-icall-va-list.c
  clang/test/Headers/stdarg.cpp

Index: clang/test/Headers/stdarg.cpp
===
--- clang/test/Headers/stdarg.cpp
+++ clang/test/Headers/stdarg.cpp
@@ -15,7 +15,7 @@
 
 #include 
 
-// AARCH64-C: define {{.*}} @f(i32 %n, %struct.__va_list* %list)
+// AARCH64-C: define {{.*}} @f(i32 %n, %"struct.std::__va_list"* %list)
 // AARCH64-CXX: define {{.*}} @_Z1fiSt9__va_list(i32 %n, %"struct.std::__va_list"* %list)
 // X86_64-C: define {{.*}} @f(i32 %n, %struct.__va_list_tag* %list)
 // X86_64-CXX: define {{.*}} @_Z1fiP13__va_list_tag(i32 %n, %struct.__va_list_tag* %list)
Index: clang/test/CodeGen/cfi-icall-va-list.c
===
--- /dev/null
+++ clang/test/CodeGen/cfi-icall-va-list.c
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -triple aarch64-unknown-linux -fsanitize=cfi-icall -fsanitize-trap=cfi-icall -emit-llvm -o - %s | FileCheck %s
+
+// CHECK: define dso_local void @f({{.*}} !type [[TYPE:![0-9]+]] !type [[TYPE_GENERALIZED:![0-9]+]]
+void f(__builtin_va_list l) {}
+
+// CHECK-DAG: [[TYPE]] = !{i64 0, !"_ZTSFvSt9__va_listE"}
+// CHECK-DAG: [[TYPE_GENERALIZED]] = !{i64 0, !"_ZTSFvSt9__va_listE.generalized"}
Index: clang/test/CodeGen/arm64-be-hfa-vararg.c
===
--- clang/test/CodeGen/arm64-be-hfa-vararg.c
+++ clang/test/CodeGen/arm64-be-hfa-vararg.c
@@ -4,12 +4,12 @@
 
 // A single member HFA must be aligned just like a non-HFA register argument.
 double callee(int a, ...) {
-// CHECK: [[REGPP:%.*]] = getelementptr inbounds %struct.__va_list, %struct.__va_list* [[VA:%.*]], i32 0, i32 2
+// CHECK: [[REGPP:%.*]] = getelementptr inbounds %"struct.std::__va_list", %"struct.std::__va_list"* [[VA:%.*]], i32 0, i32 2
 // CHECK: [[REGP:%.*]] = load i8*, i8** [[REGPP]], align 8
 // CHECK: [[OFFSET0:%.*]] = getelementptr inbounds i8, i8* [[REGP]], i32 {{.*}}
 // CHECK: [[OFFSET1:%.*]] = getelementptr inbounds i8, i8* [[OFFSET0]], i64 8
 
-// CHECK: [[MEMPP:%.*]] = getelementptr inbounds %struct.__va_list, %struct.__va_list* [[VA:%.*]], i32 0, i32 0
+// CHECK: [[MEMPP:%.*]] = getelementptr inbounds %"struct.std::__va_list", %"struct.std::__va_list"* [[VA:%.*]], i32 0, i32 0
 // CHECK: [[MEMP:%.*]] = load i8*, i8** [[MEMPP]], align 8
 // CHECK: [[NEXTP:%.*]] = getelementptr inbounds i8, i8* [[MEMP]], i64 8
 // CHECK: store i8* [[NEXTP]], i8** [[MEMPP]], align 8
Index: clang/test/CodeGen/aarch64-varargs.c
===
--- clang/test/CodeGen/aarch64-varargs.c
+++ clang/test/CodeGen/aarch64-varargs.c
@@ -11,18 +11,18 @@
 int simple_int(void) {
 // CHECK-LABEL: define{{.*}} i32 @simple_int
   return va_arg(the_list, int);
-// CHECK: [[GR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
+// CHECK: [[GR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds (%"struct.std::__va_list", %"struct.std::__va_list"* @the_list, i32 0, i32 3)
 // CHECK: [[EARLY_ONSTACK:%[a-z_0-9]+]] = icmp sge i32 [[GR_OFFS]], 0
 // CHECK: br i1 [[EARLY_ONSTACK]], label %[[VAARG_ON_STACK:[a-z_.0-9]+]], label %[[VAARG_MAYBE_REG:[a-z_.0-9]+]]
 
 // CHECK: [[VAARG_MAYBE_REG]]
 // CHECK: [[NEW_REG_OFFS:%[a-z_0-9]+]] = add i32 [[GR_OFFS]], 8
-// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
+// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds (%"struct.std::__va_list", %"struct.std::__va_list"* @the_list, i32 0, i32 3)
 // CHECK: [[INREG:%[a-z_0-9]+]] = icmp sle i32 [[NEW_REG_OFFS]], 0
 // CHECK: br i1 [[INREG]], label %[[VAARG_IN_REG:[a-z_.0-9]+]], label %[[VAARG_ON_STACK]]
 
 // CHECK: [[VAARG_IN_REG]]
-// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 1)
+// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%"struct.std::__va_list", %"struct.std::__va_list"* @the_list, i32 0, i32 1)
 // CHECK: [[REG_ADDR:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[REG_TOP]], i32 [[GR_OFFS]]
 // CHECK-BE: [[REG_ADDR_ALIGNED:%[0-9]+]] = getelementptr inbounds i8, i8* [[REG_ADDR]], i64 4
 // CHECK-BE: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast i8* [[REG_ADDR_ALIGNED]] to i32*
@@ -30,9 +30,9 @@
 // CHECK: br label %[[VAARG_END:[a-z._0-9]+]]
 
 // CHECK: [[VAARG_ON_STACK]]
-// CHECK: [[STACK:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
+// 

[PATCH] D104830: AST: Create __va_list in the std namespace even in C.

[Peter Collingbourne via Phabricator via cfe-commits]

pcc created this revision.
pcc added reviewers: rsmith, eugenis.
pcc requested review of this revision.
Herald added a project: clang.

This ensures that the mangled type names match between C and C++,
which is significant when using -fsanitize=cfi-icall. Ideally we
wouldn't have created this namespace at all, but it's now part of
the ABI (e.g. in mangled names), so we can't change it.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104830

Files:
  clang/lib/AST/ASTContext.cpp
  clang/test/CodeGen/aarch64-varargs.c
  clang/test/CodeGen/arm64-be-hfa-vararg.c
  clang/test/Headers/stdarg.cpp

Index: clang/test/Headers/stdarg.cpp
===
--- clang/test/Headers/stdarg.cpp
+++ clang/test/Headers/stdarg.cpp
@@ -15,7 +15,7 @@
 
 #include 
 
-// AARCH64-C: define {{.*}} @f(i32 %n, %struct.__va_list* %list)
+// AARCH64-C: define {{.*}} @f(i32 %n, %"struct.std::__va_list"* %list)
 // AARCH64-CXX: define {{.*}} @_Z1fiSt9__va_list(i32 %n, %"struct.std::__va_list"* %list)
 // X86_64-C: define {{.*}} @f(i32 %n, %struct.__va_list_tag* %list)
 // X86_64-CXX: define {{.*}} @_Z1fiP13__va_list_tag(i32 %n, %struct.__va_list_tag* %list)
Index: clang/test/CodeGen/arm64-be-hfa-vararg.c
===
--- clang/test/CodeGen/arm64-be-hfa-vararg.c
+++ clang/test/CodeGen/arm64-be-hfa-vararg.c
@@ -4,12 +4,12 @@
 
 // A single member HFA must be aligned just like a non-HFA register argument.
 double callee(int a, ...) {
-// CHECK: [[REGPP:%.*]] = getelementptr inbounds %struct.__va_list, %struct.__va_list* [[VA:%.*]], i32 0, i32 2
+// CHECK: [[REGPP:%.*]] = getelementptr inbounds %"struct.std::__va_list", %"struct.std::__va_list"* [[VA:%.*]], i32 0, i32 2
 // CHECK: [[REGP:%.*]] = load i8*, i8** [[REGPP]], align 8
 // CHECK: [[OFFSET0:%.*]] = getelementptr inbounds i8, i8* [[REGP]], i32 {{.*}}
 // CHECK: [[OFFSET1:%.*]] = getelementptr inbounds i8, i8* [[OFFSET0]], i64 8
 
-// CHECK: [[MEMPP:%.*]] = getelementptr inbounds %struct.__va_list, %struct.__va_list* [[VA:%.*]], i32 0, i32 0
+// CHECK: [[MEMPP:%.*]] = getelementptr inbounds %"struct.std::__va_list", %"struct.std::__va_list"* [[VA:%.*]], i32 0, i32 0
 // CHECK: [[MEMP:%.*]] = load i8*, i8** [[MEMPP]], align 8
 // CHECK: [[NEXTP:%.*]] = getelementptr inbounds i8, i8* [[MEMP]], i64 8
 // CHECK: store i8* [[NEXTP]], i8** [[MEMPP]], align 8
Index: clang/test/CodeGen/aarch64-varargs.c
===
--- clang/test/CodeGen/aarch64-varargs.c
+++ clang/test/CodeGen/aarch64-varargs.c
@@ -11,18 +11,18 @@
 int simple_int(void) {
 // CHECK-LABEL: define{{.*}} i32 @simple_int
   return va_arg(the_list, int);
-// CHECK: [[GR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
+// CHECK: [[GR_OFFS:%[a-z_0-9]+]] = load i32, i32* getelementptr inbounds (%"struct.std::__va_list", %"struct.std::__va_list"* @the_list, i32 0, i32 3)
 // CHECK: [[EARLY_ONSTACK:%[a-z_0-9]+]] = icmp sge i32 [[GR_OFFS]], 0
 // CHECK: br i1 [[EARLY_ONSTACK]], label %[[VAARG_ON_STACK:[a-z_.0-9]+]], label %[[VAARG_MAYBE_REG:[a-z_.0-9]+]]
 
 // CHECK: [[VAARG_MAYBE_REG]]
 // CHECK: [[NEW_REG_OFFS:%[a-z_0-9]+]] = add i32 [[GR_OFFS]], 8
-// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 3)
+// CHECK: store i32 [[NEW_REG_OFFS]], i32* getelementptr inbounds (%"struct.std::__va_list", %"struct.std::__va_list"* @the_list, i32 0, i32 3)
 // CHECK: [[INREG:%[a-z_0-9]+]] = icmp sle i32 [[NEW_REG_OFFS]], 0
 // CHECK: br i1 [[INREG]], label %[[VAARG_IN_REG:[a-z_.0-9]+]], label %[[VAARG_ON_STACK]]
 
 // CHECK: [[VAARG_IN_REG]]
-// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 1)
+// CHECK: [[REG_TOP:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%"struct.std::__va_list", %"struct.std::__va_list"* @the_list, i32 0, i32 1)
 // CHECK: [[REG_ADDR:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[REG_TOP]], i32 [[GR_OFFS]]
 // CHECK-BE: [[REG_ADDR_ALIGNED:%[0-9]+]] = getelementptr inbounds i8, i8* [[REG_ADDR]], i64 4
 // CHECK-BE: [[FROMREG_ADDR:%[a-z_0-9]+]] = bitcast i8* [[REG_ADDR_ALIGNED]] to i32*
@@ -30,9 +30,9 @@
 // CHECK: br label %[[VAARG_END:[a-z._0-9]+]]
 
 // CHECK: [[VAARG_ON_STACK]]
-// CHECK: [[STACK:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
+// CHECK: [[STACK:%[a-z_0-9]+]] = load i8*, i8** getelementptr inbounds (%"struct.std::__va_list", %"struct.std::__va_list"* @the_list, i32 0, i32 0)
 // CHECK: [[NEW_STACK:%[a-z_0-9]+]] = getelementptr inbounds i8, i8* [[STACK]], i64 8
-// CHECK: store i8* [[NEW_STACK]], i8** getelementptr inbounds (%struct.__va_list, %struct.__va_list* @the_list, i32 0, i32 0)
+// CHECK: store i8* 

[PATCH] D104118: [OpenCL] Use DW_LANG_OpenCL language tag for OpenCL C

[ChenZheng via Phabricator via cfe-commits]

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

LGTM. Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104118

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

[PATCH] D104803: [AIX] Emitting diagnostics error for profile options

[Whitney Tsang via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGab244db1fa0b: [AIX] Emitting diagnostics error for profile 
options (authored by Whitney).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104803

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/unsupported-option.c


Index: clang/test/Driver/unsupported-option.c
===
--- clang/test/Driver/unsupported-option.c
+++ clang/test/Driver/unsupported-option.c
@@ -1,7 +1,23 @@
 // RUN: not %clang %s --hedonism -### 2>&1 | \
 // RUN: FileCheck %s
+// CHECK: error: unsupported option '--hedonism'
+
 // RUN: not %clang %s --hell -### 2>&1 | \
 // RUN: FileCheck %s --check-prefix=DID-YOU-MEAN
-
-// CHECK: error: unsupported option '--hedonism'
 // DID-YOU-MEAN: error: unsupported option '--hell'; did you mean '--help'?
+
+// RUN: not %clang -fprofile-instr-generate --target=powerpc-ibm-aix %s 2>&1 | 
\
+// RUN: FileCheck %s --check-prefix=INVALID-AIX-PROFILE
+// INVALID-AIX-PROFILE: error: unsupported option '-fprofile-instr-generate' 
for target
+
+// RUN: not %clang -fprofile-sample-use=code.prof --target=powerpc-ibm-aix %s 
2>&1 | \
+// RUN: FileCheck %s --check-prefix=AIX-PROFILE-SAMPLE
+// AIX-PROFILE-SAMPLE: error: unsupported option '-fprofile-sample-use=' for 
target
+
+// RUN: not %clang -fprofile-generate --target=powerpc-ibm-aix %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=AIX-PROFILE-LTO
+// AIX-PROFILE-LTO: error: invalid argument '-fprofile-generate' only allowed 
with '-flto'
+
+// RUN: not %clang -fprofile-generate -flto=thin --target=powerpc64-ibm-aix %s 
2>&1 | \
+// RUN: FileCheck %s --check-prefix=AIX-PROFILE-THINLTO
+// AIX-PROFILE-THINLTO: error: invalid argument '-fprofile-generate' only 
allowed with '-flto'
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -801,6 +801,20 @@
 PGOGenerateArg = nullptr;
   }
 
+  if (TC.getTriple().isOSAIX()) {
+if (PGOGenerateArg)
+  if (!D.isUsingLTO(false /*IsDeviceOffloadAction */) ||
+  D.getLTOMode() != LTOK_Full)
+D.Diag(clang::diag::err_drv_argument_only_allowed_with)
+<< PGOGenerateArg->getSpelling() << "-flto";
+if (ProfileGenerateArg)
+  D.Diag(diag::err_drv_unsupported_opt_for_target)
+  << ProfileGenerateArg->getSpelling() << TC.getTriple().str();
+if (Arg *ProfileSampleUseArg = getLastProfileSampleUseArg(Args))
+  D.Diag(diag::err_drv_unsupported_opt_for_target)
+  << ProfileSampleUseArg->getSpelling() << TC.getTriple().str();
+  }
+
   if (ProfileGenerateArg) {
 if (ProfileGenerateArg->getOption().matches(
 options::OPT_fprofile_instr_generate_EQ))


Index: clang/test/Driver/unsupported-option.c
===
--- clang/test/Driver/unsupported-option.c
+++ clang/test/Driver/unsupported-option.c
@@ -1,7 +1,23 @@
 // RUN: not %clang %s --hedonism -### 2>&1 | \
 // RUN: FileCheck %s
+// CHECK: error: unsupported option '--hedonism'
+
 // RUN: not %clang %s --hell -### 2>&1 | \
 // RUN: FileCheck %s --check-prefix=DID-YOU-MEAN
-
-// CHECK: error: unsupported option '--hedonism'
 // DID-YOU-MEAN: error: unsupported option '--hell'; did you mean '--help'?
+
+// RUN: not %clang -fprofile-instr-generate --target=powerpc-ibm-aix %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=INVALID-AIX-PROFILE
+// INVALID-AIX-PROFILE: error: unsupported option '-fprofile-instr-generate' for target
+
+// RUN: not %clang -fprofile-sample-use=code.prof --target=powerpc-ibm-aix %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=AIX-PROFILE-SAMPLE
+// AIX-PROFILE-SAMPLE: error: unsupported option '-fprofile-sample-use=' for target
+
+// RUN: not %clang -fprofile-generate --target=powerpc-ibm-aix %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=AIX-PROFILE-LTO
+// AIX-PROFILE-LTO: error: invalid argument '-fprofile-generate' only allowed with '-flto'
+
+// RUN: not %clang -fprofile-generate -flto=thin --target=powerpc64-ibm-aix %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=AIX-PROFILE-THINLTO
+// AIX-PROFILE-THINLTO: error: invalid argument '-fprofile-generate' only allowed with '-flto'
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -801,6 +801,20 @@
 PGOGenerateArg = nullptr;
   }
 
+  if (TC.getTriple().isOSAIX()) {
+if (PGOGenerateArg)
+  if (!D.isUsingLTO(false /*IsDeviceOffloadAction */) ||
+  D.getLTOMode() != LTOK_Full)
+D.Diag(clang::diag::err_drv_argument_only_allowed_with)
+<< PGOGenerateArg->getSpelling() << "-flto";
+if 

[clang] ab244db - [AIX] Emitting diagnostics error for profile options

[Whitney Tsang via cfe-commits]

Author: Whitney Tsang
Date: 2021-06-24T00:23:28Z
New Revision: ab244db1fa0b72f3c0ac928158569fdcc6db0236

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

LOG: [AIX] Emitting diagnostics error for profile options

Only LLVM-based instrumentation profile is supported on AIX.
And it currently must be used with full LTO.

Reviewed By: hubert.reinterpretcast

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/Clang.cpp
clang/test/Driver/unsupported-option.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 0d1fce3c06aea..29b15b516b9e5 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -801,6 +801,20 @@ static void addPGOAndCoverageFlags(const ToolChain , 
Compilation ,
 PGOGenerateArg = nullptr;
   }
 
+  if (TC.getTriple().isOSAIX()) {
+if (PGOGenerateArg)
+  if (!D.isUsingLTO(false /*IsDeviceOffloadAction */) ||
+  D.getLTOMode() != LTOK_Full)
+D.Diag(clang::diag::err_drv_argument_only_allowed_with)
+<< PGOGenerateArg->getSpelling() << "-flto";
+if (ProfileGenerateArg)
+  D.Diag(diag::err_drv_unsupported_opt_for_target)
+  << ProfileGenerateArg->getSpelling() << TC.getTriple().str();
+if (Arg *ProfileSampleUseArg = getLastProfileSampleUseArg(Args))
+  D.Diag(diag::err_drv_unsupported_opt_for_target)
+  << ProfileSampleUseArg->getSpelling() << TC.getTriple().str();
+  }
+
   if (ProfileGenerateArg) {
 if (ProfileGenerateArg->getOption().matches(
 options::OPT_fprofile_instr_generate_EQ))

diff  --git a/clang/test/Driver/unsupported-option.c 
b/clang/test/Driver/unsupported-option.c
index d0611977a99e1..975440352259d 100644
--- a/clang/test/Driver/unsupported-option.c
+++ b/clang/test/Driver/unsupported-option.c
@@ -1,7 +1,23 @@
 // RUN: not %clang %s --hedonism -### 2>&1 | \
 // RUN: FileCheck %s
+// CHECK: error: unsupported option '--hedonism'
+
 // RUN: not %clang %s --hell -### 2>&1 | \
 // RUN: FileCheck %s --check-prefix=DID-YOU-MEAN
-
-// CHECK: error: unsupported option '--hedonism'
 // DID-YOU-MEAN: error: unsupported option '--hell'; did you mean '--help'?
+
+// RUN: not %clang -fprofile-instr-generate --target=powerpc-ibm-aix %s 2>&1 | 
\
+// RUN: FileCheck %s --check-prefix=INVALID-AIX-PROFILE
+// INVALID-AIX-PROFILE: error: unsupported option '-fprofile-instr-generate' 
for target
+
+// RUN: not %clang -fprofile-sample-use=code.prof --target=powerpc-ibm-aix %s 
2>&1 | \
+// RUN: FileCheck %s --check-prefix=AIX-PROFILE-SAMPLE
+// AIX-PROFILE-SAMPLE: error: unsupported option '-fprofile-sample-use=' for 
target
+
+// RUN: not %clang -fprofile-generate --target=powerpc-ibm-aix %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=AIX-PROFILE-LTO
+// AIX-PROFILE-LTO: error: invalid argument '-fprofile-generate' only allowed 
with '-flto'
+
+// RUN: not %clang -fprofile-generate -flto=thin --target=powerpc64-ibm-aix %s 
2>&1 | \
+// RUN: FileCheck %s --check-prefix=AIX-PROFILE-THINLTO
+// AIX-PROFILE-THINLTO: error: invalid argument '-fprofile-generate' only 
allowed with '-flto'



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

[PATCH] D103527: [Clang][RISCV] Implement vlseg and vlsegff.

[Hsiangkai Wang via Phabricator via cfe-commits]

HsiangKai updated this revision to Diff 354117.
HsiangKai added a comment.

Split vlseg and vlseg_ff tests in two different files.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103527

Files:
  clang/include/clang/Basic/IdentifierTable.h
  clang/include/clang/Basic/riscv_vector.td
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vlseg.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vlsegff.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlseg.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlsegff.c
  clang/utils/TableGen/RISCVVEmitter.cpp

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

[PATCH] D102820: [Clang] Check for returns_nonnull when deciding to add allocation null checks

[Di Mo via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG42b99e094c4f: [Clang] Check for returns_nonnull when 
deciding to add allocation null checks (authored by modimo).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102820

Files:
  clang/lib/AST/ExprCXX.cpp
  clang/test/CodeGenCXX/new.cpp


Index: clang/test/CodeGenCXX/new.cpp
===
--- clang/test/CodeGenCXX/new.cpp
+++ clang/test/CodeGenCXX/new.cpp
@@ -176,6 +176,7 @@
 struct Alloc{
   int x;
   void* operator new[](size_t size);
+  __attribute__((returns_nonnull)) void *operator new[](size_t size, const 
std::nothrow_t &) throw();
   void operator delete[](void* p);
   ~Alloc();
 };
@@ -186,6 +187,10 @@
   // CHECK: call void @_ZN5AllocD1Ev(
   // CHECK: call void @_ZN5AllocdaEPv(i8*
   delete[] new Alloc[10][20];
+  // CHECK: [[P:%.*]] = call nonnull i8* @_ZN5AllocnaEmRKSt9nothrow_t(i64 808, 
{{.*}}) [[ATTR_NOUNWIND:#[^ ]*]]
+  // CHECK-NOT: icmp eq i8* [[P]], null
+  // CHECK: store i64 200
+  delete[] new (nothrow) Alloc[10][20];
   // CHECK: call noalias nonnull i8* @_Znwm
   // CHECK: call void @_ZdlPv(i8*
   delete new bool;
@@ -328,7 +333,7 @@
 // CHECK: call void @_ZdaPv({{.*}}) [[ATTR_BUILTIN_DELETE]]
 delete[] p; // expected-warning {{'delete[]' applied to a pointer that was 
allocated with 'new'; did you mean 'delete'?}}
 
-// CHECK: call noalias i8* @_ZnamRKSt9nothrow_t(i64 3, {{.*}}) 
[[ATTR_BUILTIN_NOTHROW_NEW:#[^ ]*]]
+// CHECK: call noalias i8* @_ZnamRKSt9nothrow_t(i64 3, {{.*}}) 
[[ATTR_NOBUILTIN_NOUNWIND_ALLOCSIZE:#[^ ]*]]
 (void) new (nothrow) S[3];
 
 // CHECK: call i8* @_Znwm15MyPlacementType(i64 4){{$}}
Index: clang/lib/AST/ExprCXX.cpp
===
--- clang/lib/AST/ExprCXX.cpp
+++ clang/lib/AST/ExprCXX.cpp
@@ -275,7 +275,8 @@
 }
 
 bool CXXNewExpr::shouldNullCheckAllocation() const {
-  return getOperatorNew()
+  return !getOperatorNew()->hasAttr() &&
+ getOperatorNew()
  ->getType()
  ->castAs()
  ->isNothrow() &&


Index: clang/test/CodeGenCXX/new.cpp
===
--- clang/test/CodeGenCXX/new.cpp
+++ clang/test/CodeGenCXX/new.cpp
@@ -176,6 +176,7 @@
 struct Alloc{
   int x;
   void* operator new[](size_t size);
+  __attribute__((returns_nonnull)) void *operator new[](size_t size, const std::nothrow_t &) throw();
   void operator delete[](void* p);
   ~Alloc();
 };
@@ -186,6 +187,10 @@
   // CHECK: call void @_ZN5AllocD1Ev(
   // CHECK: call void @_ZN5AllocdaEPv(i8*
   delete[] new Alloc[10][20];
+  // CHECK: [[P:%.*]] = call nonnull i8* @_ZN5AllocnaEmRKSt9nothrow_t(i64 808, {{.*}}) [[ATTR_NOUNWIND:#[^ ]*]]
+  // CHECK-NOT: icmp eq i8* [[P]], null
+  // CHECK: store i64 200
+  delete[] new (nothrow) Alloc[10][20];
   // CHECK: call noalias nonnull i8* @_Znwm
   // CHECK: call void @_ZdlPv(i8*
   delete new bool;
@@ -328,7 +333,7 @@
 // CHECK: call void @_ZdaPv({{.*}}) [[ATTR_BUILTIN_DELETE]]
 delete[] p; // expected-warning {{'delete[]' applied to a pointer that was allocated with 'new'; did you mean 'delete'?}}
 
-// CHECK: call noalias i8* @_ZnamRKSt9nothrow_t(i64 3, {{.*}}) [[ATTR_BUILTIN_NOTHROW_NEW:#[^ ]*]]
+// CHECK: call noalias i8* @_ZnamRKSt9nothrow_t(i64 3, {{.*}}) [[ATTR_NOBUILTIN_NOUNWIND_ALLOCSIZE:#[^ ]*]]
 (void) new (nothrow) S[3];
 
 // CHECK: call i8* @_Znwm15MyPlacementType(i64 4){{$}}
Index: clang/lib/AST/ExprCXX.cpp
===
--- clang/lib/AST/ExprCXX.cpp
+++ clang/lib/AST/ExprCXX.cpp
@@ -275,7 +275,8 @@
 }
 
 bool CXXNewExpr::shouldNullCheckAllocation() const {
-  return getOperatorNew()
+  return !getOperatorNew()->hasAttr() &&
+ getOperatorNew()
  ->getType()
  ->castAs()
  ->isNothrow() &&
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 42b99e0 - [Clang] Check for returns_nonnull when deciding to add allocation null checks

[via cfe-commits]

Author: modimo
Date: 2021-06-23T17:15:12-07:00
New Revision: 42b99e094c4f57b52807c56641c0a545b4a9a600

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

LOG: [Clang] Check for returns_nonnull when deciding to add allocation null 
checks

Non-throwing allocators currently will always get null-check code. However, if 
the non-throwing allocator is explicitly annotated with returns_nonnull the 
null check should be elided.

Testing:
ninja check-all
added test case correctly elides

Reviewed By: bruno

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

Added: 


Modified: 
clang/lib/AST/ExprCXX.cpp
clang/test/CodeGenCXX/new.cpp

Removed: 




diff  --git a/clang/lib/AST/ExprCXX.cpp b/clang/lib/AST/ExprCXX.cpp
index b5ccfe34cce1b..26844f412f366 100644
--- a/clang/lib/AST/ExprCXX.cpp
+++ b/clang/lib/AST/ExprCXX.cpp
@@ -275,7 +275,8 @@ CXXNewExpr *CXXNewExpr::CreateEmpty(const ASTContext , 
bool IsArray,
 }
 
 bool CXXNewExpr::shouldNullCheckAllocation() const {
-  return getOperatorNew()
+  return !getOperatorNew()->hasAttr() &&
+ getOperatorNew()
  ->getType()
  ->castAs()
  ->isNothrow() &&

diff  --git a/clang/test/CodeGenCXX/new.cpp b/clang/test/CodeGenCXX/new.cpp
index 2181534a6beb4..3142dba4bf683 100644
--- a/clang/test/CodeGenCXX/new.cpp
+++ b/clang/test/CodeGenCXX/new.cpp
@@ -176,6 +176,7 @@ void t13(int n) {
 struct Alloc{
   int x;
   void* operator new[](size_t size);
+  __attribute__((returns_nonnull)) void *operator new[](size_t size, const 
std::nothrow_t &) throw();
   void operator delete[](void* p);
   ~Alloc();
 };
@@ -186,6 +187,10 @@ void f() {
   // CHECK: call void @_ZN5AllocD1Ev(
   // CHECK: call void @_ZN5AllocdaEPv(i8*
   delete[] new Alloc[10][20];
+  // CHECK: [[P:%.*]] = call nonnull i8* @_ZN5AllocnaEmRKSt9nothrow_t(i64 808, 
{{.*}}) [[ATTR_NOUNWIND:#[^ ]*]]
+  // CHECK-NOT: icmp eq i8* [[P]], null
+  // CHECK: store i64 200
+  delete[] new (nothrow) Alloc[10][20];
   // CHECK: call noalias nonnull i8* @_Znwm
   // CHECK: call void @_ZdlPv(i8*
   delete new bool;
@@ -328,7 +333,7 @@ namespace N3664 {
 // CHECK: call void @_ZdaPv({{.*}}) [[ATTR_BUILTIN_DELETE]]
 delete[] p; // expected-warning {{'delete[]' applied to a pointer that was 
allocated with 'new'; did you mean 'delete'?}}
 
-// CHECK: call noalias i8* @_ZnamRKSt9nothrow_t(i64 3, {{.*}}) 
[[ATTR_BUILTIN_NOTHROW_NEW:#[^ ]*]]
+// CHECK: call noalias i8* @_ZnamRKSt9nothrow_t(i64 3, {{.*}}) 
[[ATTR_NOBUILTIN_NOUNWIND_ALLOCSIZE:#[^ ]*]]
 (void) new (nothrow) S[3];
 
 // CHECK: call i8* @_Znwm15MyPlacementType(i64 4){{$}}



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

[PATCH] D99675: [llvm][clang] Create new intrinsic llvm.arithmetic.fence to control FP optimization at expression level

[LuoYuanke via Phabricator via cfe-commits]

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

LGTM, but pls wait for 1 or 2 days to see if there is any more comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99675

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

[PATCH] D103930: [clang][HeaderSearch] Fix implicit module when using header maps

[Andrew Gallagher via Phabricator via cfe-commits]

andrewjcg added a comment.

Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103930

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

[PATCH] D103501: [clang][AIX] Enable inlined quadword atomic operations

[Hubert Tong via Phabricator via cfe-commits]

hubert.reinterpretcast added inline comments.



Comment at: clang/test/CodeGen/ppc64-quadword-atomics.c:10
+
+// CHECK-NOT: call void @__atomic_exchange
+// CHECK: +quadword-atomics

lkail wrote:
> hubert.reinterpretcast wrote:
> > Can you add a link to something that demonstrates that the implementation 
> > of `__atomic_exchange` is also lock-free when running on `pwr8` and up?
> https://reviews.llvm.org/D103614#C2646926NL5 All related lock-free codegen is 
> in the parent revision.
That change is for the compiler. I am looking for something that makes the 
libatomic implementation correspondingly lock-free for this type (even if 
libatomic needs to be deployable on `pwr7`).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103501

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

[PATCH] D104803: [AIX] Emitting diagnostics error for profile options

[Hubert Tong via Phabricator via cfe-commits]

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

LGTM; thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104803

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

[PATCH] D104803: [AIX] Emitting diagnostics error for profile options

[Whitney Tsang via Phabricator via cfe-commits]

Whitney updated this revision to Diff 354108.
Whitney added a comment.

move code later


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104803

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/unsupported-option.c


Index: clang/test/Driver/unsupported-option.c
===
--- clang/test/Driver/unsupported-option.c
+++ clang/test/Driver/unsupported-option.c
@@ -1,7 +1,23 @@
 // RUN: not %clang %s --hedonism -### 2>&1 | \
 // RUN: FileCheck %s
+// CHECK: error: unsupported option '--hedonism'
+
 // RUN: not %clang %s --hell -### 2>&1 | \
 // RUN: FileCheck %s --check-prefix=DID-YOU-MEAN
-
-// CHECK: error: unsupported option '--hedonism'
 // DID-YOU-MEAN: error: unsupported option '--hell'; did you mean '--help'?
+
+// RUN: not %clang -fprofile-instr-generate --target=powerpc-ibm-aix %s 2>&1 | 
\
+// RUN: FileCheck %s --check-prefix=INVALID-AIX-PROFILE
+// INVALID-AIX-PROFILE: error: unsupported option '-fprofile-instr-generate' 
for target
+
+// RUN: not %clang -fprofile-sample-use=code.prof --target=powerpc-ibm-aix %s 
2>&1 | \
+// RUN: FileCheck %s --check-prefix=AIX-PROFILE-SAMPLE
+// AIX-PROFILE-SAMPLE: error: unsupported option '-fprofile-sample-use=' for 
target
+
+// RUN: not %clang -fprofile-generate --target=powerpc-ibm-aix %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=AIX-PROFILE-LTO
+// AIX-PROFILE-LTO: error: invalid argument '-fprofile-generate' only allowed 
with '-flto'
+
+// RUN: not %clang -fprofile-generate -flto=thin --target=powerpc64-ibm-aix %s 
2>&1 | \
+// RUN: FileCheck %s --check-prefix=AIX-PROFILE-THINLTO
+// AIX-PROFILE-THINLTO: error: invalid argument '-fprofile-generate' only 
allowed with '-flto'
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -801,6 +801,20 @@
 PGOGenerateArg = nullptr;
   }
 
+  if (TC.getTriple().isOSAIX()) {
+if (PGOGenerateArg)
+  if (!D.isUsingLTO(false /*IsDeviceOffloadAction */) ||
+  D.getLTOMode() != LTOK_Full)
+D.Diag(clang::diag::err_drv_argument_only_allowed_with)
+<< PGOGenerateArg->getSpelling() << "-flto";
+if (ProfileGenerateArg)
+  D.Diag(diag::err_drv_unsupported_opt_for_target)
+  << ProfileGenerateArg->getSpelling() << TC.getTriple().str();
+if (Arg *ProfileSampleUseArg = getLastProfileSampleUseArg(Args))
+  D.Diag(diag::err_drv_unsupported_opt_for_target)
+  << ProfileSampleUseArg->getSpelling() << TC.getTriple().str();
+  }
+
   if (ProfileGenerateArg) {
 if (ProfileGenerateArg->getOption().matches(
 options::OPT_fprofile_instr_generate_EQ))


Index: clang/test/Driver/unsupported-option.c
===
--- clang/test/Driver/unsupported-option.c
+++ clang/test/Driver/unsupported-option.c
@@ -1,7 +1,23 @@
 // RUN: not %clang %s --hedonism -### 2>&1 | \
 // RUN: FileCheck %s
+// CHECK: error: unsupported option '--hedonism'
+
 // RUN: not %clang %s --hell -### 2>&1 | \
 // RUN: FileCheck %s --check-prefix=DID-YOU-MEAN
-
-// CHECK: error: unsupported option '--hedonism'
 // DID-YOU-MEAN: error: unsupported option '--hell'; did you mean '--help'?
+
+// RUN: not %clang -fprofile-instr-generate --target=powerpc-ibm-aix %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=INVALID-AIX-PROFILE
+// INVALID-AIX-PROFILE: error: unsupported option '-fprofile-instr-generate' for target
+
+// RUN: not %clang -fprofile-sample-use=code.prof --target=powerpc-ibm-aix %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=AIX-PROFILE-SAMPLE
+// AIX-PROFILE-SAMPLE: error: unsupported option '-fprofile-sample-use=' for target
+
+// RUN: not %clang -fprofile-generate --target=powerpc-ibm-aix %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=AIX-PROFILE-LTO
+// AIX-PROFILE-LTO: error: invalid argument '-fprofile-generate' only allowed with '-flto'
+
+// RUN: not %clang -fprofile-generate -flto=thin --target=powerpc64-ibm-aix %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=AIX-PROFILE-THINLTO
+// AIX-PROFILE-THINLTO: error: invalid argument '-fprofile-generate' only allowed with '-flto'
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -801,6 +801,20 @@
 PGOGenerateArg = nullptr;
   }
 
+  if (TC.getTriple().isOSAIX()) {
+if (PGOGenerateArg)
+  if (!D.isUsingLTO(false /*IsDeviceOffloadAction */) ||
+  D.getLTOMode() != LTOK_Full)
+D.Diag(clang::diag::err_drv_argument_only_allowed_with)
+<< PGOGenerateArg->getSpelling() << "-flto";
+if (ProfileGenerateArg)
+  D.Diag(diag::err_drv_unsupported_opt_for_target)
+  << 

[PATCH] D104803: [AIX] Emitting diagnostics error for profile options

[Hubert Tong via Phabricator via cfe-commits]

hubert.reinterpretcast added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:786
+<< PGOGenerateArg->getSpelling() << "-flto";
+if (ProfileGenerateArg)
+  D.Diag(diag::err_drv_unsupported_opt_for_target)

Isn't this block of code a bit too early? The adjustment to consider the "no" 
form as equivalent to not having any `ProfileGenerateArg` is later in the 
function. I think it makes sense to move this to after the group of blocks that 
deal with more "fundamental" option conflicts.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104803

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

[PATCH] D104797: [WebAssembly] Implementation of global.get/set for reftypes in LLVM IR

[Thomas Lively via Phabricator via cfe-commits]

tlively added a comment.

Unfortunately I don't think

In D104797#2836475 , @pmatos wrote:

> @tlively Do you think it would be ok to re-add the code removed in `ac81cb7e` 
> but only error if the pointer is to an **opaque** non-integral type?

Unfortunately that wouldn't be future-proof given the ongoing project to remove 
type information from pointers. I think the best we can do right now is call 
`report_fatal_error` from the backend whenever a reference type is the operand 
or result of ptrtoint or inttoptr.




Comment at: llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.h:69
+if (AS == WasmAddressSpace::EXTERNREF)
+  return MVT::externref;
+else if (AS == WasmAddressSpace::FUNCREF)

It might be worth a comment explaining why the memtype is also externref and 
funcref. Is this just for lack of a more meaningful type to return?



Comment at: llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp:130
 TT.isArch64Bit()
-? "e-m:e-p:64:64-i64:64-n32:64-S128-ni:1"
-: "e-m:e-p:32:32-i64:64-n32:64-S128-ni:1",
+? (hasReferenceTypes(FS)
+   ? 
"e-m:e-p:64:64-i64:64-n32:64-S128-ni:1:10:20"

`hasReferenceTypes` should also be taking the CPU into account, not just the 
feature string. Normally this would be done via `getSubtargetImpl`, but I guess 
we probably can't call that this early in the construction of the 
`WebAssemblyTargetMachine`. Would anything break if we just unconditionally 
added the reference types address spaces to the data layout string?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104797

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

[PATCH] D104085: [compiler-rt][hwasan] Setup hwasan thread handling on Fuchsia

[Leonard Chan via Phabricator via cfe-commits]

leonardchan planned changes to this revision.
leonardchan added inline comments.



Comment at: compiler-rt/lib/hwasan/hwasan_fuchsia.cpp:41
+void InitThreads() {
+  uptr alloc_size = UINT64_C(1) << kShadowBaseAlignment;
+  uptr thread_start = reinterpret_cast(

mcgrathr wrote:
> What depends on this alignment?  I'm not aware of anything that does in the 
> compiler ABI we're using on Fuchsia.
> If it's needed, it should have comments.
> 
Added.



Comment at: compiler-rt/lib/hwasan/hwasan_fuchsia.cpp:137
+// __hwasan_tls can be referenced.
+static void FinishThreadInitialization(Thread *thread) {
+  CHECK_NE(thread, nullptr);

mcgrathr wrote:
> Most of what's happening in this function is common with the Linux code.
> I think a shared function can be factored out and put into hwasan_thread.cpp.
> 
Updated such that this just calls `InitStackRingBuffer` which handles the stack 
ring buffer initialization.



Comment at: compiler-rt/lib/hwasan/hwasan_thread.cpp:42-45
-  static u64 unique_id;
-  unique_id_ = unique_id++;
-  if (auto sz = flags()->heap_history_size)
-heap_allocations_ = HeapAllocationsRingBuffer::New(sz);

mcgrathr wrote:
> This is stuff that could be done either in the before-create hook or in the 
> on-start hook.  But it's probably not especially worthwhile to move it to 
> before-create as long as we have on-start doing any allocation at all.  So to 
> avoid a whole lot more refactoring to move the ringbuffer setup and such, 
> might as well just leave this in on-start too.
With the refactoring from D104248, this bit will be done in the before-create 
hook without any changes to this code.



Comment at: compiler-rt/lib/hwasan/hwasan_thread.cpp:58-63
-  uptr tls_size;
-  uptr stack_size;
-  GetThreadStackAndTls(IsMainThread(), _bottom_, _size, 
_begin_,
-   _size);
-  stack_top_ = stack_bottom_ + stack_size;
-  tls_end_ = tls_begin_ + tls_size;

mcgrathr wrote:
> This is probably the only part that actually needs to be different between 
> Linux and Fuchsia.
> So this code could just move into an InitStackAndTls(options) that looks like 
> this on Linux and on Fuchsia is just copying values out of options. 
> 
This is done in D104248.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104085

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

[PATCH] D104085: [compiler-rt][hwasan] Setup hwasan thread handling on Fuchsia

[Leonard Chan via Phabricator via cfe-commits]

leonardchan updated this revision to Diff 354098.
leonardchan marked 7 inline comments as done.
leonardchan edited the summary of this revision.
leonardchan added a comment.

Rebased against recent refactoring commits and addressed some comments.

I think I can omit some functions like `GetCurrentThread` or 
`GetRingBufferSize` which are small enough to merit their own changes .


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104085

Files:
  compiler-rt/lib/hwasan/CMakeLists.txt
  compiler-rt/lib/hwasan/hwasan_fuchsia.cpp
  compiler-rt/lib/hwasan/hwasan_thread.cpp
  compiler-rt/lib/hwasan/hwasan_thread_list.h

Index: compiler-rt/lib/hwasan/hwasan_thread_list.h
===
--- compiler-rt/lib/hwasan/hwasan_thread_list.h
+++ compiler-rt/lib/hwasan/hwasan_thread_list.h
@@ -171,6 +171,9 @@
 return stats_;
   }
 
+  // Reuse this value so external users don't need to call RingBufferSize().
+  uptr GetRingBufferSize() const { return ring_buffer_size_; }
+
  private:
   Thread *AllocThread() {
 SpinMutexLock l(_space_mutex_);
Index: compiler-rt/lib/hwasan/hwasan_thread.cpp
===
--- compiler-rt/lib/hwasan/hwasan_thread.cpp
+++ compiler-rt/lib/hwasan/hwasan_thread.cpp
@@ -46,7 +46,12 @@
 heap_allocations_ = HeapAllocationsRingBuffer::New(sz);
 
   InitStackAndTls(state);
+#if !SANITIZER_FUCHSIA
+  // Do not initialize the stack ring buffer just yet on Fuchsia. Threads will
+  // be initialized before we enter the thread itself, so we will instead call
+  // this later.
   InitStackRingBuffer(stack_buffer_start, stack_buffer_size);
+#endif
 }
 
 void Thread::InitStackRingBuffer(uptr stack_buffer_start,
Index: compiler-rt/lib/hwasan/hwasan_fuchsia.cpp
===
--- /dev/null
+++ compiler-rt/lib/hwasan/hwasan_fuchsia.cpp
@@ -0,0 +1,167 @@
+//===-- hwasan_fuchsia.cpp --*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+///
+/// \file
+/// This file is a part of HWAddressSanitizer and contains Fuchsia-specific
+/// code.
+///
+//===--===//
+
+#include "sanitizer_common/sanitizer_fuchsia.h"
+#if SANITIZER_FUCHSIA
+
+#include "hwasan.h"
+#include "hwasan_interface_internal.h"
+#include "hwasan_report.h"
+#include "hwasan_thread.h"
+#include "hwasan_thread_list.h"
+
+// This TLS variable contains the location of the stack ring buffer and can be
+// used to always find the hwasan thread object associated with the current
+// running thread.
+SANITIZER_INTERFACE_ATTRIBUTE
+[[gnu::tls_model("initial-exec")]] THREADLOCAL uptr __hwasan_tls;
+
+namespace __hwasan {
+
+// These are known parameters passed to the hwasan runtime on thread creation.
+struct Thread::InitState {
+  uptr stack_bottom, stack_top;
+};
+
+static void FinishThreadInitialization(Thread *thread);
+
+void InitThreads() {
+  // This is the minimal alignment needed for the storage where hwasan threads
+  // and their stack ring buffers are placed. This alignment is necessary so the
+  // stack ring buffer can perform a simple calculation to get the next element
+  // in the RB. The instructions for this calculation are emitted by the
+  // compiler. (Full explanation in hwasan_thread_list.h.)
+  uptr alloc_size = UINT64_C(1) << kShadowBaseAlignment;
+  uptr thread_start = reinterpret_cast(
+  MmapAlignedOrDieOnFatalError(alloc_size, alloc_size, __func__));
+
+  InitThreadList(thread_start, alloc_size);
+
+  // Create the hwasan thread object for the current (main) thread. Stack info
+  // for this thread is known from information passed via
+  // __sanitizer_startup_hook.
+  const Thread::InitState state = {
+  .stack_bottom = __sanitizer::MainThreadStackBase,
+  .stack_top =
+  __sanitizer::MainThreadStackBase + __sanitizer::MainThreadStackSize,
+  };
+  FinishThreadInitialization(hwasanThreadList().CreateCurrentThread());
+}
+
+uptr *GetCurrentThreadLongPtr() { return &__hwasan_tls; }
+
+Thread *GetCurrentThread() {
+  uptr *ThreadLongPtr = GetCurrentThreadLongPtr();
+  if (UNLIKELY(*ThreadLongPtr == 0))
+return nullptr;
+  auto *R = (StackAllocationsRingBuffer *)ThreadLongPtr;
+  return hwasanThreadList().GetThreadByBufferAddress((uptr)R->Next());
+}
+
+// This is called from the parent thread before the new thread is created. Here
+// we can propagate known info like the stack bounds to Thread::Init before
+// jumping into the thread. We cannot initialize the stack ring buffer yet since
+// we have not 

[PATCH] D104803: [AIX] Emitting diagnostics error for profile options

[Whitney Tsang via Phabricator via cfe-commits]

Whitney updated this revision to Diff 354096.
Whitney marked an inline comment as done.
Whitney added a comment.

Updated one of the test cases to use `--target=powerpc64-ibm-aix`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104803

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/unsupported-option.c


Index: clang/test/Driver/unsupported-option.c
===
--- clang/test/Driver/unsupported-option.c
+++ clang/test/Driver/unsupported-option.c
@@ -1,7 +1,20 @@
 // RUN: not %clang %s --hedonism -### 2>&1 | \
 // RUN: FileCheck %s
+// CHECK: error: unsupported option '--hedonism'
+
 // RUN: not %clang %s --hell -### 2>&1 | \
 // RUN: FileCheck %s --check-prefix=DID-YOU-MEAN
-
-// CHECK: error: unsupported option '--hedonism'
 // DID-YOU-MEAN: error: unsupported option '--hell'; did you mean '--help'?
+
+// RUN: not %clang -fprofile-instr-generate -fprofile-sample-use=code.prof 
--target=powerpc-ibm-aix %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=INVALID-AIX-PROFILE
+// INVALID-AIX-PROFILE-DAG: error: unsupported option 
'-fprofile-instr-generate' for target
+// INVALID-AIX-PROFILE-DAG: error: unsupported option '-fprofile-sample-use=' 
for target
+
+// RUN: not %clang -fprofile-generate --target=powerpc-ibm-aix %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=AIX-PROFILE-LTO
+// AIX-PROFILE-LTO: error: invalid argument '-fprofile-generate' only allowed 
with '-flto'
+
+// RUN: not %clang -fprofile-generate -flto=thin --target=powerpc64-ibm-aix %s 
2>&1 | \
+// RUN: FileCheck %s --check-prefix=AIX-PROFILE-THINLTO
+// AIX-PROFILE-THINLTO: error: invalid argument '-fprofile-generate' only 
allowed with '-flto'
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -776,6 +776,21 @@
   options::OPT_fprofile_instr_generate,
   options::OPT_fprofile_instr_generate_EQ,
   options::OPT_fno_profile_instr_generate);
+
+  if (TC.getTriple().isOSAIX()) {
+if (PGOGenerateArg)
+  if (!D.isUsingLTO(false /*IsDeviceOffloadAction */) ||
+  D.getLTOMode() != LTOK_Full)
+D.Diag(clang::diag::err_drv_argument_only_allowed_with)
+<< PGOGenerateArg->getSpelling() << "-flto";
+if (ProfileGenerateArg)
+  D.Diag(diag::err_drv_unsupported_opt_for_target)
+  << ProfileGenerateArg->getSpelling() << TC.getTriple().str();
+if (Arg *ProfileSampleUseArg = getLastProfileSampleUseArg(Args))
+  D.Diag(diag::err_drv_unsupported_opt_for_target)
+  << ProfileSampleUseArg->getSpelling() << TC.getTriple().str();
+  } 
+
   if (ProfileGenerateArg &&
   ProfileGenerateArg->getOption().matches(
   options::OPT_fno_profile_instr_generate))


Index: clang/test/Driver/unsupported-option.c
===
--- clang/test/Driver/unsupported-option.c
+++ clang/test/Driver/unsupported-option.c
@@ -1,7 +1,20 @@
 // RUN: not %clang %s --hedonism -### 2>&1 | \
 // RUN: FileCheck %s
+// CHECK: error: unsupported option '--hedonism'
+
 // RUN: not %clang %s --hell -### 2>&1 | \
 // RUN: FileCheck %s --check-prefix=DID-YOU-MEAN
-
-// CHECK: error: unsupported option '--hedonism'
 // DID-YOU-MEAN: error: unsupported option '--hell'; did you mean '--help'?
+
+// RUN: not %clang -fprofile-instr-generate -fprofile-sample-use=code.prof --target=powerpc-ibm-aix %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=INVALID-AIX-PROFILE
+// INVALID-AIX-PROFILE-DAG: error: unsupported option '-fprofile-instr-generate' for target
+// INVALID-AIX-PROFILE-DAG: error: unsupported option '-fprofile-sample-use=' for target
+
+// RUN: not %clang -fprofile-generate --target=powerpc-ibm-aix %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=AIX-PROFILE-LTO
+// AIX-PROFILE-LTO: error: invalid argument '-fprofile-generate' only allowed with '-flto'
+
+// RUN: not %clang -fprofile-generate -flto=thin --target=powerpc64-ibm-aix %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=AIX-PROFILE-THINLTO
+// AIX-PROFILE-THINLTO: error: invalid argument '-fprofile-generate' only allowed with '-flto'
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -776,6 +776,21 @@
   options::OPT_fprofile_instr_generate,
   options::OPT_fprofile_instr_generate_EQ,
   options::OPT_fno_profile_instr_generate);
+
+  if (TC.getTriple().isOSAIX()) {
+if (PGOGenerateArg)
+  if (!D.isUsingLTO(false /*IsDeviceOffloadAction */) ||
+  D.getLTOMode() != LTOK_Full)
+D.Diag(clang::diag::err_drv_argument_only_allowed_with)
+<< PGOGenerateArg->getSpelling() << "-flto";
+if 

[PATCH] D104777: PR50767: clear non-distinct debuginfo for function with nodebug definition after undecorated declaration

[Bruno De Fraine via Phabricator via cfe-commits]

brunodefraine added a subscriber: probinson.
brunodefraine added a comment.

In D104777#2836669 , @dblaikie wrote:

> Yeah, all that sounds reasonable to me - @brunodefraine could you look into 
> supporting nodebug in a similar way as @aaron.ballman has described here?

Since the debuginfo for `use()` is slightly affected by the `nodebug` version 
of `t1()` that follows it, I can see how this back propagation is perhaps 
dangerous. Checking that `nodebug` is the same on all declarations of a 
function is a way to prevent this.

But when discussing the PR, @probinson wrote "I'm inclined to think we want 
this to work" and I can see what he means from the use case where I observed 
the bug. If you don't want debuginfo for the implementation of `t1()`, it 
should be fine to annotate just the function definition in an implementation 
file, not the declaration in a header, since the debuginfo of the 
implementation is not of the caller's concern. But `nodebug` as it exists 
**does** affect the debuginfo of callers as well, so I cannot really express 
that I don't want debuginfo for the implementation of a function and leave its 
callers unaffected?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104777

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

[PATCH] D104822: [RISCV] Add vget/vset intrinsics for inserting and extracting between different lmuls.

[Craig Topper via Phabricator via cfe-commits]

craig.topper created this revision.
craig.topper added reviewers: frasercrmck, rogfer01, kito-cheng, khchen, 
arcbbb, HsiangKai, evandro.
Herald added subscribers: StephenFan, vkmr, dexonsmith, luismarques, apazos, 
sameer.abuasal, s.egerton, Jim, benna, psnobl, jocewei, PkmX, the_o, 
brucehoult, MartinMosbeck, edward-jones, zzheng, jrtc27, shiva0217, niosHD, 
sabuasal, simoncook, johnrusso, rbar, asb.
craig.topper requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.
Herald added a project: clang.

These allow getting a whole register from a larger lmul. Or
inserting a whole register into a larger lmul register. Fractional
lmuls are not supported as they would require a vslide.

Based on this update to the intrinsic doc
https://github.com/riscv/rvv-intrinsic-doc/pull/99


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104822

Files:
  clang/include/clang/Basic/riscv_vector.td
  clang/test/CodeGen/RISCV/rvv-intrinsics/vget.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vset.c

Index: clang/test/CodeGen/RISCV/rvv-intrinsics/vset.c
===
--- /dev/null
+++ clang/test/CodeGen/RISCV/rvv-intrinsics/vset.c
@@ -0,0 +1,546 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// REQUIRES: riscv-registered-target
+// RUN: %clang_cc1 -triple riscv64 -target-feature +f -target-feature +d -target-feature +experimental-v \
+// RUN:   -disable-O0-optnone -emit-llvm %s -o - | opt -S -mem2reg | FileCheck --check-prefix=CHECK-RV64 %s
+
+#include 
+
+// CHECK-RV64-LABEL: @test_vset_v_i8m1_i8m2(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv16i8.nxv8i8( [[DEST:%.*]],  [[VAL:%.*]], i64 8)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint8m2_t test_vset_v_i8m1_i8m2(vint8m2_t dest, vint8m1_t val) {
+  return vset_v_i8m1_i8m2(dest, 1, val);
+}
+
+// CHECK-RV64-LABEL: @test_vset_v_i8m1_i8m4(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv32i8.nxv8i8( [[DEST:%.*]],  [[VAL:%.*]], i64 24)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint8m4_t test_vset_v_i8m1_i8m4(vint8m4_t dest, vint8m1_t val) {
+  return vset_v_i8m1_i8m4(dest, 3, val);
+}
+
+// CHECK-RV64-LABEL: @test_vset_v_i8m2_i8m4(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv32i8.nxv16i8( [[DEST:%.*]],  [[VAL:%.*]], i64 16)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint8m4_t test_vset_v_i8m2_i8m4(vint8m4_t dest, vint8m2_t val) {
+  return vset_v_i8m2_i8m4(dest, 1, val);
+}
+
+// CHECK-RV64-LABEL: @test_vset_v_i8m1_i8m8(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv64i8.nxv8i8( [[DEST:%.*]],  [[VAL:%.*]], i64 56)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint8m8_t test_vset_v_i8m1_i8m8(vint8m8_t dest, vint8m1_t val) {
+  return vset_v_i8m1_i8m8(dest, 7, val);
+}
+
+// CHECK-RV64-LABEL: @test_vset_v_i8m2_i8m8(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv64i8.nxv16i8( [[DEST:%.*]],  [[VAL:%.*]], i64 32)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint8m8_t test_vset_v_i8m2_i8m8(vint8m8_t dest, vint8m2_t val) {
+  return vset_v_i8m2_i8m8(dest, 2, val);
+}
+
+// CHECK-RV64-LABEL: @test_vset_v_i8m4_i8m8(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv64i8.nxv32i8( [[DEST:%.*]],  [[VAL:%.*]], i64 32)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint8m8_t test_vset_v_i8m4_i8m8(vint8m8_t dest, vint8m4_t val) {
+  return vset_v_i8m4_i8m8(dest, 1, val);
+}
+
+// CHECK-RV64-LABEL: @test_vset_v_i16m1_i16m2(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv8i16.nxv4i16( [[DEST:%.*]],  [[VAL:%.*]], i64 4)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint16m2_t test_vset_v_i16m1_i16m2(vint16m2_t dest, vint16m1_t val) {
+  return vset_v_i16m1_i16m2(dest, 1, val);
+}
+
+// CHECK-RV64-LABEL: @test_vset_v_i16m1_i16m4(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv16i16.nxv4i16( [[DEST:%.*]],  [[VAL:%.*]], i64 12)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint16m4_t test_vset_v_i16m1_i16m4(vint16m4_t dest, vint16m1_t val) {
+  return vset_v_i16m1_i16m4(dest, 3, val);
+}
+
+// CHECK-RV64-LABEL: @test_vset_v_i16m2_i16m4(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv16i16.nxv8i16( [[DEST:%.*]],  [[VAL:%.*]], i64 8)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint16m4_t test_vset_v_i16m2_i16m4(vint16m4_t dest, vint16m2_t val) {
+  return vset_v_i16m2_i16m4(dest, 1, val);
+}
+
+// CHECK-RV64-LABEL: @test_vset_v_i16m1_i16m8(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  

[PATCH] D104803: [AIX] Emitting diagnostics error for profile options

[Hubert Tong via Phabricator via cfe-commits]

hubert.reinterpretcast added inline comments.



Comment at: clang/test/Driver/unsupported-option.c:14
+
+// RUN: not %clang -fprofile-generate --target=powerpc-ibm-aix %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=AIX-PROFILE-LTO

Worthwhile to use the 64-bit triple for one of the cases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104803

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

[PATCH] D104744: [PowerPC] Add PowerPC rotate related builtins and emit target independent code for XL compatibility

[Victor Huang via Phabricator via cfe-commits]

NeHuang updated this revision to Diff 354082.
NeHuang added a comment.

- Rebased the patch with ToT and the patch https://reviews.llvm.org/D102875
- Create the patch with all contexts. (Thanks @qiucf)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104744

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Basic/Targets/PPC.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/builtins-ppc-xlcompat-error.c
  clang/test/CodeGen/builtins-ppc-xlcompat-rotate.c

Index: clang/test/CodeGen/builtins-ppc-xlcompat-rotate.c
===
--- /dev/null
+++ clang/test/CodeGen/builtins-ppc-xlcompat-rotate.c
@@ -0,0 +1,56 @@
+// RUN: %clang_cc1 -triple powerpc64-unknown-unknown \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr8 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc-unknown-aix \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64-unknown-aix \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | FileCheck %s
+
+extern unsigned int ui;
+extern unsigned long long ull;
+
+void test_builtin_ppc_rldimi() {
+  // CHECK-LABEL: test_builtin_ppc_rldimi
+  // CHECK:   %res = alloca i64, align 8
+  // CHECK-NEXT:  [[RA:%[0-9]+]] = load i64, i64* @ull, align 8
+  // CHECK-NEXT:  [[RB:%[0-9]+]] = load i64, i64* @ull, align 8
+  // CHECK-NEXT:  [[RC:%[0-9]+]] = call i64 @llvm.fshl.i64(i64 [[RA]], i64 [[RA]], i64 63)
+  // CHECK-NEXT:  [[RD:%[0-9]+]] = and i64 [[RC]], 72057593769492480
+  // CHECK-NEXT:  [[RE:%[0-9]+]] = and i64 [[RB]], -72057593769492481
+  // CHECK-NEXT:  [[RF:%[0-9]+]] = or i64 [[RD]], [[RE]]
+  // CHECK-NEXT:  store i64 [[RF]], i64* %res, align 8
+  // CHECK-NEXT:  ret void
+
+  /*shift = 63, mask = 0x00FFF000 = 72057593769492480, ~mask = 0xFF000FFF = -72057593769492481*/
+  unsigned long long res = __builtin_ppc_rldimi(ull, ull, 63, 0x00FFF000);
+}
+
+void test_builtin_ppc_rlwimi() {
+  // CHECK-LABEL: test_builtin_ppc_rlwimi
+  // CHECK:   %res = alloca i32, align 4
+  // CHECK-NEXT:  [[RA:%[0-9]+]] = load i32, i32* @ui, align 4
+  // CHECK-NEXT:  [[RB:%[0-9]+]] = load i32, i32* @ui, align 4
+  // CHECK-NEXT:  [[RC:%[0-9]+]] = call i32 @llvm.fshl.i32(i32 [[RA]], i32 [[RA]], i32 31)
+  // CHECK-NEXT:  [[RD:%[0-9]+]] = and i32 [[RC]], 16776960
+  // CHECK-NEXT:  [[RE:%[0-9]+]] = and i32 [[RB]], -16776961
+  // CHECK-NEXT:  [[RF:%[0-9]+]] = or i32 [[RD]], [[RE]]
+  // CHECK-NEXT:  store i32 [[RF]], i32* %res, align 4
+  // CHECK-NEXT:  ret void
+
+  /*shift = 31, mask = 0x00 = 16776960, ~mask = 0xFFFF = -16776961*/
+  unsigned int res = __builtin_ppc_rlwimi(ui, ui, 31, 0x00);
+}
+
+void test_builtin_ppc_rlwnm() {
+  // CHECK-LABEL: test_builtin_ppc_rlwnm
+  // CHECK:   %res = alloca i32, align 4
+  // CHECK-NEXT:  [[RA:%[0-9]+]] = load i32, i32* @ui, align 4
+  // CHECK-NEXT:  [[RB:%[0-9]+]] = call i32 @llvm.fshl.i32(i32 [[RA]], i32 [[RA]], i32 31)
+  // CHECK-NEXT:  [[RC:%[0-9]+]] = and i32 [[RB]], 511
+  // CHECK-NEXT:  store i32 [[RC]], i32* %res, align 4
+  // CHECK-NEXT:  ret void
+
+  /*shift = 31, mask = 0x1FF = 511*/
+  unsigned int res = __builtin_ppc_rlwnm(ui, 31, 0x1FF);
+}
Index: clang/test/CodeGen/builtins-ppc-xlcompat-error.c
===
--- /dev/null
+++ clang/test/CodeGen/builtins-ppc-xlcompat-error.c
@@ -0,0 +1,37 @@
+// REQUIRES: powerpc-registered-target
+
+// RUN: %clang_cc1 -triple powerpc64-unknown-unknown -fsyntax-only \
+// RUN:   -Wall -Werror -verify %s
+// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -fsyntax-only \
+// RUN:   -Wall -Werror -verify %s
+// RUN: %clang_cc1 -triple powerpc64-unknown-aix -fsyntax-only \
+// RUN:   -Wall -Werror -verify %s
+// RUN: %clang_cc1 -triple powerpc-unknown-aix -fsyntax-only \
+// RUN:   -Wall -Werror -verify %s
+
+extern unsigned int ui;
+extern unsigned long long ull;
+
+void test_builtin_ppc_rldimi() {
+  unsigned int shift;
+  unsigned long long mask;
+  unsigned long long res = __builtin_ppc_rldimi(ull, ull, shift, 7); // expected-error {{argument to '__builtin_ppc_rldimi' must be a constant integer}}
+  res = __builtin_ppc_rldimi(ull, ull, 63, mask);// expected-error {{argument to '__builtin_ppc_rldimi' must be a constant integer}}
+  res = __builtin_ppc_rldimi(ull, ull, 63, 0x0F00);  // expected-error {{argument 3 value should represent a contiguous bit field}}
+}
+
+void test_builtin_ppc_rlwimi() {
+  unsigned int shift;
+  unsigned int mask;
+  unsigned int res = __builtin_ppc_rlwimi(ui, ui, shift, 7); // expected-error {{argument to 

[PATCH] D102875: [PowerPC] Add PowerPC compare and multiply related builtins and instrinsics for XL compatibility

[Victor Huang via Phabricator via cfe-commits]

NeHuang updated this revision to Diff 354081.
NeHuang added a comment.

- Added Sema check for the pwr9 only builtins and updated the test cases.
- Rebased the patch with ToT.
- Cleaned up the test cases and address review comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102875

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Basic/Targets/PPC.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/builtins-ppc-xlcompat-multiply-64bit-only.c
  clang/test/CodeGen/builtins-ppc-xlcompat-multiply.c
  clang/test/CodeGen/builtins-ppc-xlcompat-pwr9-64bit.c
  clang/test/CodeGen/builtins-ppc-xlcompat-pwr9-error.c
  clang/test/CodeGen/builtins-ppc-xlcompat-pwr9.c
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPCInstr64Bit.td
  llvm/lib/Target/PowerPC/PPCInstrInfo.td
  llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-compare-64bit-only.ll
  llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-compare.ll
  llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-multiply-64bit-only.ll
  llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-multiply.ll

Index: llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-multiply.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-multiply.ll
@@ -0,0 +1,52 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s --check-prefix=CHECK-64
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s --check-prefix=CHECK-64
+; RUN: llc -verify-machineinstrs -mtriple=powerpc-unknown-aix \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s --check-prefix=CHECK-32
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-aix \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s --check-prefix=CHECK-64
+
+; Function Attrs: noinline nounwind optnone
+define dso_local signext i32 @test_builtin_ppc_mulhw(i32 %a, i32%b) #0 {
+; CHECK-32-LABEL: test_builtin_ppc_mulhw:
+; CHECK-32:   # %bb.0: # %entry
+; CHECK-32-NEXT:mulhw 3, 3, 4
+; CHECK-32-NEXT:blr
+;
+; CHECK-64-LABEL: test_builtin_ppc_mulhw:
+; CHECK-64:   # %bb.0: # %entry
+; CHECK-64-NEXT:mulhw 3, 3, 4
+; CHECK-64-NEXT:extsw 3, 3
+; CHECK-64-NEXT:blr
+entry:
+  %0 = call i32 @llvm.ppc.mulhw(i32 %a, i32 %b)
+  ret i32 %0
+}
+
+; Function Attrs: nounwind readnone
+declare i32 @llvm.ppc.mulhw(i32, i32) #1
+
+; Function Attrs: noinline nounwind optnone
+define dso_local zeroext i32 @test_builtin_ppc_mulhwu(i32 %a, i32%b) #0 {
+; CHECK-32-LABEL: test_builtin_ppc_mulhwu:
+; CHECK-32:   # %bb.0: # %entry
+; CHECK-32-NEXT:mulhwu 3, 3, 4
+; CHECK-32-NEXT:blr
+;
+; CHECK-64-LABEL: test_builtin_ppc_mulhwu:
+; CHECK-64:   # %bb.0: # %entry
+; CHECK-64-NEXT:mulhwu 3, 3, 4
+; CHECK-64-NEXT:clrldi 3, 3, 32
+; CHECK-64-NEXT:blr
+entry:
+  %0 = call i32 @llvm.ppc.mulhwu(i32 %a, i32 %b)
+  ret i32 %0
+}
+
+; Function Attrs: nounwind readnone
+declare i32 @llvm.ppc.mulhwu(i32, i32) #1
+
+attributes #0 = { noinline nounwind optnone "frame-pointer"="none" "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="pwr9" "target-features"="+altivec,+bpermd,+crypto,+direct-move,+extdiv,+htm,+power8-vector,+power9-vector,+vsx,-privileged,-rop-protect,-spe" }
+attributes #1 = { nounwind readnone }
Index: llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-multiply-64bit-only.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-multiply-64bit-only.ll
@@ -0,0 +1,82 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-aix \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s
+
+; Function Attrs: noinline nounwind optnone
+define dso_local i64 @test_builtin_ppc_mulhd(i64 %a, i64 %b) #0 {
+; CHECK-LABEL: test_builtin_ppc_mulhd:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:mulhd 3, 3, 4
+; CHECK-NEXT:blr
+entry:
+  %0 = call i64 @llvm.ppc.mulhd(i64 %a, i64 %b)
+  ret i64 %0
+}
+
+; Function Attrs: nounwind readnone
+declare i64 @llvm.ppc.mulhd(i64, i64) #1
+
+; Function Attrs: noinline nounwind optnone
+define dso_local i64 @test_builtin_ppc_mulhdu(i64 %a, i64 %b) #0 {
+; CHECK-LABEL: test_builtin_ppc_mulhdu:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:mulhdu 3, 3, 4
+; CHECK-NEXT:blr
+entry:
+  %0 = call i64 @llvm.ppc.mulhdu(i64 %a, i64 %b)
+  ret 

[PATCH] D104556: [InstrProfiling] Make CountersPtr in __profd_ relative

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo added a comment.

In D104556#2837104 , @rnk wrote:

> In D104556#2837006 , @MaskRay wrote:
>
>> Is it possible to ask MSVC to add the 64-bit `IMAGE_REL_AMD64_REL64` and 
>> `IMAGE_REL_ARM64_REL64`?
>> Newer compiler metadata techniques can benefit from using the same mechanism 
>> for all three major binary formats (PE-COFF/ELF/Mach-O).
>
> Swift wanted the same thing, so I think the answer is yes, we should ask.

What would the benefit of that be, as the difference itself can only ever be 32 
bit? Is it only for consistency with other binary formats? I guess getting the 
value sign extended to a 64 bit value is a bit useful too.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104556

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

[PATCH] D95984: [CodeGen] Fix codegen for __attribute__((swiftasynccall)).

[Varun Gandhi via Phabricator via cfe-commits]

varungandhi-apple abandoned this revision.
varungandhi-apple added a comment.
Herald added a subscriber: ormris.

Combined changes into D95561 .


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95984

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

[PATCH] D95561: [Clang] Introduce Swift async calling convention.

[Varun Gandhi via Phabricator via cfe-commits]

varungandhi-apple updated this revision to Diff 354073.
varungandhi-apple added a comment.
Herald added a subscriber: ormris.

Combined D95984  into this patch since all 
necessary LLVM patches have landed, so having the patches separated out is not 
helpful.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95561

Files:
  clang/include/clang-c/Index.h
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/Features.def
  clang/include/clang/Basic/Specifiers.h
  clang/include/clang/CodeGen/SwiftCallingConv.h
  clang/lib/AST/ExprCXX.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/MicrosoftMangle.cpp
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Basic/Targets/ARM.cpp
  clang/lib/Basic/Targets/PPC.h
  clang/lib/Basic/Targets/SystemZ.h
  clang/lib/Basic/Targets/WebAssembly.h
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CodeGen/64bit-swiftcall.c
  clang/test/CodeGen/arm-swiftcall.c
  clang/test/CodeGen/debug-info-cc.c
  clang/test/CodeGen/swift-async-call-conv.c
  clang/test/CodeGen/swift-call-conv.c
  clang/test/Sema/attr-c2x.c
  clang/test/Sema/attr-swiftcall.c
  clang/test/Sema/no_callconv.cpp
  clang/test/SemaCXX/attr-swiftcall.cpp
  clang/tools/libclang/CXType.cpp
  llvm/include/llvm/Demangle/MicrosoftDemangleNodes.h
  llvm/lib/Demangle/MicrosoftDemangle.cpp
  llvm/lib/Demangle/MicrosoftDemangleNodes.cpp
  llvm/lib/Transforms/IPO/MergeFunctions.cpp
  llvm/test/Demangle/ms-mangle.test

Index: llvm/test/Demangle/ms-mangle.test
===
--- llvm/test/Demangle/ms-mangle.test
+++ llvm/test/Demangle/ms-mangle.test
@@ -341,6 +341,9 @@
 ?swift_func@@YSXXZ
 ; CHECK: void __attribute__((__swiftcall__)) swift_func(void)
 
+?swift_async_func@@YTXXZ
+; CHECK: void __attribute__((__swiftasynccall__)) swift_async_func(void)
+
 ??$fn_tmpl@$1?extern_c_func@@YAXXZ@@YAXXZ
 ; CHECK: void __cdecl fn_tmpl< __cdecl extern_c_func(void)>(void)
 
Index: llvm/lib/Transforms/IPO/MergeFunctions.cpp
===
--- llvm/lib/Transforms/IPO/MergeFunctions.cpp
+++ llvm/lib/Transforms/IPO/MergeFunctions.cpp
@@ -709,7 +709,10 @@
 
   CallInst *CI = Builder.CreateCall(F, Args);
   ReturnInst *RI = nullptr;
-  CI->setTailCall();
+  bool isSwiftTailCall = F->getCallingConv() == CallingConv::SwiftTail &&
+ G->getCallingConv() == CallingConv::SwiftTail;
+  CI->setTailCallKind(isSwiftTailCall ? llvm::CallInst::TCK_MustTail
+  : llvm::CallInst::TCK_Tail);
   CI->setCallingConv(F->getCallingConv());
   CI->setAttributes(F->getAttributes());
   if (H->getReturnType()->isVoidTy()) {
Index: llvm/lib/Demangle/MicrosoftDemangleNodes.cpp
===
--- llvm/lib/Demangle/MicrosoftDemangleNodes.cpp
+++ llvm/lib/Demangle/MicrosoftDemangleNodes.cpp
@@ -110,6 +110,9 @@
   case CallingConv::Swift:
 OS << "__attribute__((__swiftcall__)) ";
 break;
+  case CallingConv::SwiftAsync:
+OS << "__attribute__((__swiftasynccall__)) ";
+break;
   default:
 break;
   }
Index: llvm/lib/Demangle/MicrosoftDemangle.cpp
===
--- llvm/lib/Demangle/MicrosoftDemangle.cpp
+++ llvm/lib/Demangle/MicrosoftDemangle.cpp
@@ -1713,6 +1713,8 @@
 return CallingConv::Vectorcall;
   case 'S':
 return CallingConv::Swift;
+  case 'T':
+return CallingConv::SwiftAsync;
   }
 
   return CallingConv::None;
Index: llvm/include/llvm/Demangle/MicrosoftDemangleNodes.h
===
--- llvm/include/llvm/Demangle/MicrosoftDemangleNodes.h
+++ llvm/include/llvm/Demangle/MicrosoftDemangleNodes.h
@@ -67,7 +67,8 @@
   Eabi,
   Vectorcall,
   Regcall,
-  Swift, // Clang-only
+  Swift,  // Clang-only
+  SwiftAsync, // Clang-only
 };
 
 enum class ReferenceKind : uint8_t { None, LValueRef, RValueRef };
Index: clang/tools/libclang/CXType.cpp
===
--- clang/tools/libclang/CXType.cpp
+++ clang/tools/libclang/CXType.cpp
@@ -664,6 +664,7 @@
   TCALLINGCONV(AAPCS_VFP);
   TCALLINGCONV(IntelOclBicc);
   TCALLINGCONV(Swift);
+  TCALLINGCONV(SwiftAsync);
   TCALLINGCONV(PreserveMost);
   TCALLINGCONV(PreserveAll);
 case CC_SpirFunction: return CXCallingConv_Unexposed;
Index: clang/test/SemaCXX/attr-swiftcall.cpp
===
--- 

[PATCH] D104381: [analyzer] Added a test case for PR46264

[Artem Dergachev via Phabricator via cfe-commits]

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

Cool, thanks!




Comment at: clang/test/Analysis/diagnostics/PR46264.cpp:7-8
+// `3ed8ebc2f6b8172bed48cc5986d3b7af4cfca1bc` from 24.05.2020.
+namespace ns1 {
+namespace a {
+class b {

I'm pretty sure the namespaces can be dropped.


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

https://reviews.llvm.org/D104381

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

[PATCH] D104556: [InstrProfiling] Make CountersPtr in __profd_ relative

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

In D104556#2837006 , @MaskRay wrote:

> Is it possible to ask MSVC to add the 64-bit `IMAGE_REL_AMD64_REL64` and 
> `IMAGE_REL_ARM64_REL64`?
> Newer compiler metadata techniques can benefit from using the same mechanism 
> for all three major binary formats (PE-COFF/ELF/Mach-O).

Swift wanted the same thing, so I think the answer is yes, we should ask.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104556

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

[PATCH] D104808: [clang][emscripten] Reduce alignof long double from 16 to 8 bytes

[Sam Clegg via Phabricator via cfe-commits]

sbc100 added a comment.

In D104808#2836991 , @kripken wrote:

> In D104808#2836942 , @sunfish wrote:
>
>> Do we still intend to unify Emscripten's ABI with wasm32-unknown-unknown or 
>> wasm32-wasi eventually? This is talking a step away from that.
>
> I definitely think we should unify them as much as possible. Ideally we would 
> all make this change.
>
> The motivation for the change is that right now we are losing either some 
> correctness or some performance. Either is a burden, and a possible future 
> float128 in wasm doesn't seem strong enough of a justification to me - should 
> wasm add float128, we can consider a new ABI at that point. Does that sound 
> reasonable?
>
>> One of the assumptions behind this is that it would be ok for malloc to be 
>> 16-byte aligned anyway, because SIMD use cases benefit from being able to 
>> call `malloc` and get a buffer aligned for SIMD. Do we have more information 
>> on how much this matters in practice?
>
> I think the discussions converged on it being ok with the spec, but perhaps a 
> problem in practice, but portable SIMD code seems smart enough to avoid the 
> issue. I don't think I've seen a bug report mentioning SIMD, but I may have 
> missed one.

Indeed, we have had reports of issues with the under-alignment of values 
returns from malloc, but I don't think any of them have been related to SIMD,   
only the expectation that malloc honors `max_align_t`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104808

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

[PATCH] D103930: [clang][HeaderSearch] Fix implicit module when using header maps

[Alex Lorenz via Phabricator via cfe-commits]

arphaman added a comment.

I've started testing this change. I'll let you know how it looks in a few days.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103930

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

[PATCH] D104556: [InstrProfiling] Make CountersPtr in __profd_ relative

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

In D104556#2836900 , @rnk wrote:

> In D104556#2831787 , @MaskRay wrote:
>
>> Hmm, IMGREL (`IMAGE_REL_AMD64_ADDR32NB`) looks useful and is an alternative 
>> solution to PC-relative relocations in ELF / relocation subtraction in 
>> Mach-O.
>> But leveraging it seems to need more code in the runtime and will make COFF 
>> vs non-COFF different in IR, runtime, and llvm-profdata
>
> We can go forward with what we have, but the `signextIfWin64` helper is 
> pretty subtle. In some ways, I think adding `__ImageBase` is clearer:
>
>   #ifdef _WIN32
>   extern "C" char __ImageBase;
>   #endif
>   uintptr_t rebaseRelativePtr(void *D, void *P) {
>   #ifdef _WIN32
> return (uintptr_t)&__ImageBase + (uintptr_t)P;
>   #else
> return (uintptr_t)D + (uintptr_t)P;
>   #endif
>   }
>
> It's not quite this easy, and the instrumentation side changes have to 
> basically copy or refactor this code:
> https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/MicrosoftCXXABI.cpp#L548
>
> We aren't worried about profraw format compatibility on Windows, so I think 
> we can change this later at any time if we like.

I think you mean that `INSTR_PROF_RAW_HEADER(uint64_t, CountersDelta, 
(uintptr_t)CountersBegin - (uintptr_t)DataBegin)` (in InstrProfiling.cpp, so 
used by both -fprofile-generate and -fprofile-instr-generate) needs to adopt 
the scheme in 
https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/MicrosoftCXXABI.cpp#L548
Yes, seems quite a bit of complexity.

Is it possible to ask MSVC to add the 64-bit `IMAGE_REL_AMD64_REL64` and 
`IMAGE_REL_ARM64_REL64`?
Newer compiler metadata techniques can benefit from using the same mechanism 
for all three major binary formats (PE-COFF/ELF/Mach-O).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104556

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

[PATCH] D100118: [clang] Add support for new builtin __arithmetic_fence to control floating point optimization, and new clang option fprotect-parens

[Melanie Blower via Phabricator via cfe-commits]

mibintc marked 11 inline comments as done.
mibintc added a comment.

some inline replies.  I think this is all set now.




Comment at: clang/lib/Sema/SemaExpr.cpp:4026
+  !E->isLValue() &&
+  (ExprTy->isFloatingType() || (ExprTy->isComplexType( {
+return BuildBuiltinCallExpr(R, Builtin::BI__arithmetic_fence, E);

mibintc wrote:
> aaron.ballman wrote:
> > Do you have to worry about vector types here as well?
> Oh yes, i didn't get this one. 
Yes thanks, i also added a little test case for this


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100118

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

[PATCH] D100118: [clang] Add support for new builtin __arithmetic_fence to control floating point optimization, and new clang option fprotect-parens

[Melanie Blower via Phabricator via cfe-commits]

mibintc updated this revision to Diff 354061.
mibintc marked 2 inline comments as done.
mibintc added a comment.

Respond to @aaron.ballman 's review


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100118

Files:
  clang/docs/UsersManual.rst
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/TargetInfo.h
  clang/include/clang/Driver/Options.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ExprConstant.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaCoroutine.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/AST/arithmetic-fence-builtin.c
  clang/test/CodeGen/arithmetic-fence-builtin.c
  clang/test/Driver/clang_f_opts.c
  clang/test/Sema/arithmetic-fence-builtin.c

Index: clang/test/Sema/arithmetic-fence-builtin.c
===
--- /dev/null
+++ clang/test/Sema/arithmetic-fence-builtin.c
@@ -0,0 +1,48 @@
+// RUN: %clang_cc1 -triple i386-pc-linux-gnu -emit-llvm -o - -verify -x c++ %s
+// RUN: %clang_cc1 -triple ppc64le -DPPC -emit-llvm -o - -verify -x c++ %s
+// RUN: not %clang_cc1 -triple ppc64le -DPPC -emit-llvm -o - -x c++ %s \
+// RUN:-fprotect-parens 2>&1 | FileCheck -check-prefix=PPC %s
+#ifndef PPC
+int v;
+template  T addT(T a, T b) {
+  T *q = __arithmetic_fence();
+  // expected-error@-1 {{invalid operand of type 'float *' where floating, complex or a vector of such types is required}}
+  // expected-error@-2 {{invalid operand of type 'int *' where floating, complex or a vector of such types is required}}
+  return __arithmetic_fence(a + b);
+  // expected-error@-1 {{invalid operand of type 'int' where floating, complex or a vector of such types is required}}
+}
+int addit(int a, int b) {
+  float x, y;
+  typedef struct {
+int a, b;
+  } stype;
+  stype s;
+  s = __arithmetic_fence(s);// expected-error {{invalid operand of type 'stype' where floating, complex or a vector of such types is required}}
+  x = __arithmetic_fence(); // expected-error {{too few arguments to function call, expected 1, have 0}}
+  x = __arithmetic_fence(x, y); // expected-error {{too many arguments to function call, expected 1, have 2}}
+  // Complex is supported.
+  _Complex double cd, cd1;
+  cd = __arithmetic_fence(cd1);
+  // Vector is supported.
+  typedef float __v4hi __attribute__((__vector_size__(8)));
+  __v4hi vec1, vec2;
+  vec1 = __arithmetic_fence(vec2);
+
+  v = __arithmetic_fence(a + b); // expected-error {{invalid operand of type 'int' where floating, complex or a vector of such types is required}}
+  float f = addT(a, b);   // expected-note {{in instantiation of function template specialization 'addT' requested here}}
+  int i = addT(1, 2);   // expected-note {{in instantiation of function template specialization 'addT' requested here}}
+  constexpr float d = 1.0 + 2.0;
+  constexpr float c = __arithmetic_fence(1.0 + 2.0);
+  constexpr float e = __arithmetic_fence(d);
+  return 0;
+}
+bool func(float f1, float f2, float f3) {
+  return (f1 == f2 && f1 == f3) || f2 == f3; // Should not warn here
+}
+static_assert( __arithmetic_fence(1.0 + 2.0), "message" );
+#else
+float addit(float a, float b) {
+  return __arithmetic_fence(a+b); // expected-error {{builtin is not supported on this target}}
+}
+#endif
+//PPC: error: option '-fprotect-parens' cannot be specified on this target
Index: clang/test/Driver/clang_f_opts.c
===
--- clang/test/Driver/clang_f_opts.c
+++ clang/test/Driver/clang_f_opts.c
@@ -1,13 +1,14 @@
 // REQUIRES: clang-driver
 
 // RUN: %clang -### -S -fasm -fblocks -fbuiltin -fno-math-errno -fcommon -fpascal-strings -fno-blocks -fno-builtin -fmath-errno -fno-common -fno-pascal-strings -fblocks -fbuiltin -fmath-errno -fcommon -fpascal-strings -fsplit-stack %s 2>&1 | FileCheck -check-prefix=CHECK-OPTIONS1 %s
-// RUN: %clang -### -S -fasm -fblocks -fbuiltin -fno-math-errno -fcommon -fpascal-strings -fno-asm -fno-blocks -fno-builtin -fmath-errno -fno-common -fno-pascal-strings -fno-show-source-location -fshort-enums %s 2>&1 | FileCheck -check-prefix=CHECK-OPTIONS2 %s
+// RUN: %clang -### -S -fasm -fblocks -fbuiltin -fno-math-errno -fcommon -fpascal-strings -fno-asm -fno-blocks -fno-builtin -fmath-errno -fno-common -fno-pascal-strings -fno-show-source-location -fshort-enums -fprotect-parens %s 2>&1 | FileCheck -check-prefix=CHECK-OPTIONS2 %s
 
 // CHECK-OPTIONS1: -fsplit-stack
 // CHECK-OPTIONS1: -fgnu-keywords
 // CHECK-OPTIONS1: -fblocks
 // CHECK-OPTIONS1: -fpascal-strings
 
+// CHECK-OPTIONS2: -fprotect-parens
 // CHECK-OPTIONS2: -fmath-errno
 // CHECK-OPTIONS2: -fno-gnu-keywords
 // CHECK-OPTIONS2: 

[PATCH] D104808: [clang][emscripten] Reduce alignof long double from 16 to 8 bytes

[Alon Zakai via Phabricator via cfe-commits]

kripken added a comment.

In D104808#2836942 , @sunfish wrote:

> Do we still intend to unify Emscripten's ABI with wasm32-unknown-unknown or 
> wasm32-wasi eventually? This is talking a step away from that.

I definitely think we should unify them as much as possible. Ideally we would 
all make this change.

The motivation for the change is that right now we are losing either some 
correctness or some performance. Either is a burden, and a possible future 
float128 in wasm doesn't seem strong enough of a justification to me - should 
wasm add float128, we can consider a new ABI at that point. Does that sound 
reasonable?

> One of the assumptions behind this is that it would be ok for malloc to be 
> 16-byte aligned anyway, because SIMD use cases benefit from being able to 
> call `malloc` and get a buffer aligned for SIMD. Do we have more information 
> on how much this matters in practice?

I think the discussions converged on it being ok with the spec, but perhaps a 
problem in practice, but portable SIMD code seems smart enough to avoid the 
issue. I don't think I've seen a bug report mentioning SIMD, but I may have 
missed one.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104808

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

[PATCH] D104808: [clang][emscripten] Reduce alignof long double from 16 to 8 bytes

[Dan Gohman via Phabricator via cfe-commits]

sunfish added a comment.

Do we still intend to unify Emscripten's ABI with wasm32-unknown-unknown or 
wasm32-wasi eventually? This is talking a step away from that.

One of the assumptions behind this is that it would be ok for malloc to be 
16-byte aligned anyway, because SIMD use cases benefit from being able to call 
`malloc` and get a buffer aligned for SIMD. Do we have more information on how 
much this matters in practice?

Another observation is that part of the reason for long double being 128-bit is 
to leave room for the possibility of 128-bit floats being added to wasm some 
day, and on x86-64, aarch64, and powerpc which all have 128-bit long double on 
Linux, the alignment is 16 bytes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104808

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

[PATCH] D104388: [clang-format] PR50727 C# Invoke Lamda Expression indentation incorrect

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

`lock` and `using` will be considered identifiers where as if and while will be 
seens as if/while

M=0 C=1 T=Unknown S=1 F=0 B=0 BK=0 P=99 Name=identifier L=66 PPK=2 FakeLParens= 
FakeRParens=0 II=0x1fdc7a0 Text='lock'

From what I can tell they will be handled by the parsing parseIfElse etc.. what 
this tends to do is to jump from `{` to matching `}` which means it doesn't 
have to parse whats inside

This is why by detecting the => then parsing the `{` -> `}` of the lamdba as 
just and ordinary block.

I'm not 100% sure of the indentiation, I was assuming clang-format was just 
doing its thing...to be honest in its current form clang-format is devastating 
the files I'm looking at.. any level of indentation is better than what I'm 
getting

Ultimately we probably need to see how it interacts with D102706: 
[clang-format] Add new LambdaBodyIndentation option 



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

https://reviews.llvm.org/D104388

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

[PATCH] D104505: [HIP] Defer operator overloading errors

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl marked 2 inline comments as done.
yaxunl added inline comments.



Comment at: clang/test/SemaCUDA/deferred-oeverload.cu:55
  callee3(); // dev-error {{no matching function for call to 'callee3'}}
  callee4(); // com-error {{no matching function for call to 'callee4'}}
+ S s;

tra wrote:
> yaxunl wrote:
> > tra wrote:
> > > If we're allowing to postpone an invalid call of a host function, 
> > > shouldn't we also allow postponing other errors? 
> > > E.g. should we postpone the error on an attempt to call `callee4()` ?
> > > Similarly, if we were to call a `undeclared_func()` here, should the 
> > > error also be postponed?
> > > 
> > > TBH, I don't quite understand now how to tell what is and isn't supposed 
> > > to be deferred with `-fgpu-defer-diags`.
> > > Is there a clear criteria what should and should not be deferred?
> > > 
> > We discussed about what diagnostics to be deferred before. We do not want 
> > to defer all diagnostics since nvcc apparently only ignores host/device 
> > related diagnostics. Our previous conclusion is to defer overloading 
> > resolution related diagnostics when the full candidates set include host 
> > device functions or wrong-sided candidates. This roughly matches nvcc's 
> > behavior.
> Please bear with me. I don't have all the relevant context in my head. Nor 
> would anyone else looking at the patch.
> 
> > Our previous conclusion is to defer overloading resolution related 
> > diagnostics when the full candidates set include host device functions or 
> > wrong-sided candidates. This roughly matches nvcc's behavior.
> 
> Thank you. This should probably be added somewhere at the top of this test 
> file. 
will do when committing


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

https://reviews.llvm.org/D104505

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

[PATCH] D97224: Use Address for CGBuilder's CreateAtomicRMW and CreateAtomicCmpXchg.

[John McCall via Phabricator via cfe-commits]

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

Alright, well, this does look cleaner.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97224

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

[PATCH] D104808: [clang][emscripten] Reduce alignof long double from 16 to 8 bytes

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added inline comments.



Comment at: clang/lib/Basic/Targets/OSTargets.h:954-956
+// Keeping the alignment of long double to 8 bytes even though its size is
+// 16 bytes alows emscripten to have an 8-byte-aligned max_align_t which
+// in turn gives is a 8-byte aligned malloc.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104808

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

[PATCH] D104556: [InstrProfiling] Make CountersPtr in __profd_ relative

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

In D104556#2831787 , @MaskRay wrote:

> Hmm, IMGREL (`IMAGE_REL_AMD64_ADDR32NB`) looks useful and is an alternative 
> solution to PC-relative relocations in ELF / relocation subtraction in Mach-O.
> But leveraging it seems to need more code in the runtime and will make COFF 
> vs non-COFF different in IR, runtime, and llvm-profdata

We can go forward with what we have, but the `signextIfWin64` helper is pretty 
subtle. In some ways, I think adding `__ImageBase` is clearer:

  #ifdef _WIN32
  extern "C" char __ImageBase;
  #endif
  uintptr_t rebaseRelativePtr(void *D, void *P) {
  #ifdef _WIN32
return (uintptr_t)&__ImageBase + (uintptr_t)P;
  #else
return (uintptr_t)D + (uintptr_t)P;
  #endif
  }

It's not quite this easy, and the instrumentation side changes have to 
basically copy or refactor this code:
https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/MicrosoftCXXABI.cpp#L548

We aren't worried about profraw format compatibility on Windows, so I think we 
can change this later at any time if we like.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104556

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

[PATCH] D104804: [AMDGPU] Add gfx1035 target

[Stanislav Mekhanoshin via Phabricator via cfe-commits]

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

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104804

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

[PATCH] D103131: support debug info for alias variable

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

Do you have any interest in seeing if gdb could/would be fixed to handle the 
imported declaration style? Might be worth knowing if that's feasible, if they 
have some ideas about if/why that would be a bad idea, etc.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103131

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

[PATCH] D104808: [clang][emscripten] Reduce alignof long double from 16 to 8 bytes

[Sam Clegg via Phabricator via cfe-commits]

sbc100 added a comment.

@sunfish what do you think about doing this for all WebAssembly targets?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104808

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

[PATCH] D104808: [clang][emscripten] Reduce alignof long double from 16 to 8 bytes

[Sam Clegg via Phabricator via cfe-commits]

sbc100 created this revision.
Herald added subscribers: wingo, dschuff.
sbc100 requested review of this revision.
Herald added subscribers: cfe-commits, aheejin.
Herald added a project: clang.

This means `max_align_t` is 8 bytes which also sets the alignment
malloc.  Since this is technically and ABI breaking change we have
limited to just the emscripten OS target.  It is also relatively low
import breakage since it will only effect the alignement of struct that
contai `long double`s (extremerly rare I imagine).

Emscripten's malloc implementation already use 8 byte alignement
(dlmalloc uses and alignement of 2*sizeof(void*) == 8 rather than
checking max_align_t) so will not be effected by this change.  By
bringing the ABI in line with the current malloc code this will fix
several issue we have seen in the wild.

See: https://github.com/emscripten-core/emscripten/pull/14456


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104808

Files:
  clang/lib/Basic/Targets/OSTargets.h


Index: clang/lib/Basic/Targets/OSTargets.h
===
--- clang/lib/Basic/Targets/OSTargets.h
+++ clang/lib/Basic/Targets/OSTargets.h
@@ -948,8 +948,14 @@
   }
 
 public:
-  explicit EmscriptenTargetInfo(const llvm::Triple , const 
TargetOptions )
-  : WebAssemblyOSTargetInfo(Triple, Opts) {}
+  explicit EmscriptenTargetInfo(const llvm::Triple ,
+const TargetOptions )
+  : WebAssemblyOSTargetInfo(Triple, Opts) {
+// Keeping the alignment of long double to 8 bytes even though its size is
+// 16 bytes alows emscripten to have an 8-byte-aligned max_align_t which
+// in turn gives is a 8-byte aligned malloc.
+this->LongDoubleAlign = 64;
+  }
 };
 
 } // namespace targets


Index: clang/lib/Basic/Targets/OSTargets.h
===
--- clang/lib/Basic/Targets/OSTargets.h
+++ clang/lib/Basic/Targets/OSTargets.h
@@ -948,8 +948,14 @@
   }
 
 public:
-  explicit EmscriptenTargetInfo(const llvm::Triple , const TargetOptions )
-  : WebAssemblyOSTargetInfo(Triple, Opts) {}
+  explicit EmscriptenTargetInfo(const llvm::Triple ,
+const TargetOptions )
+  : WebAssemblyOSTargetInfo(Triple, Opts) {
+// Keeping the alignment of long double to 8 bytes even though its size is
+// 16 bytes alows emscripten to have an 8-byte-aligned max_align_t which
+// in turn gives is a 8-byte aligned malloc.
+this->LongDoubleAlign = 64;
+  }
 };
 
 } // namespace targets
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D103184: Reland "[AArch64] handle -Wa,-march="

[Jian Cai via Phabricator via cfe-commits]

jcai19 added a comment.

In D103184#2831542 , @nickdesaulniers 
wrote:

> Thanks for following up on a fix!

Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103184

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

[PATCH] D103184: Reland "[AArch64] handle -Wa,-march="

[Jian Cai via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG0eac975b51cc: Reland [AArch64] handle 
-Wa,-march= (authored by jcai19).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103184

Files:
  clang/lib/Driver/ToolChains/Arch/AArch64.cpp
  clang/lib/Driver/ToolChains/Arch/AArch64.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/aarch64-target-as-march.s

Index: clang/test/Driver/aarch64-target-as-march.s
===
--- /dev/null
+++ clang/test/Driver/aarch64-target-as-march.s
@@ -0,0 +1,46 @@
+/// These tests make sure that options passed to the assembler
+/// via -Wa or -Xassembler are applied correctly to assembler inputs.
+
+/// Does not apply to non assembly files
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=armv8.1-a \
+// RUN: %S/Inputs/wildcard1.c 2>&1 | FileCheck --check-prefix=TARGET-FEATURE-1 %s
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Xassembler -march=armv8.1-a \
+// RUN: %S/Inputs/wildcard1.c 2>&1 | FileCheck --check-prefix=TARGET-FEATURE-1 %s
+
+// TARGET-FEATURE-1-NOT: "-target-feature" "+v8.1a"
+
+/// Does apply to assembler input
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=armv8.2-a %s 2>&1 | \
+// RUN: FileCheck --check-prefix=TARGET-FEATURE-2 %s
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Xassembler -march=armv8.2-a %s 2>&1 | \
+// RUN: FileCheck --check-prefix=TARGET-FEATURE-2 %s
+
+// TARGET-FEATURE-2: "-target-feature" "+v8.2a"
+
+/// No unused argument warnings when there are multiple values
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=armv8.1-a -Wa,-march=armv8.2-a %s 2>&1 | \
+// RUN: FileCheck --check-prefix=UNUSED-WARNING %s
+
+// UNUSED-WARNING-NOT: warning: argument unused during compilation
+
+/// Last march to assembler wins
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=armv8.2-a -Wa,-march=armv8.1-a %s 2>&1 | \
+// RUN: FileCheck --check-prefix=MULTIPLE-VALUES %s
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=armv8.2-a,-march=armv8.1-a %s 2>&1 | \
+// RUN: FileCheck --check-prefix=MULTIPLE-VALUES %s
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Xassembler -march=armv8.2-a -Xassembler \
+// RUN: -march=armv8.1-a %s 2>&1 | FileCheck --check-prefix=MULTIPLE-VALUES %s
+
+// MULTIPLE-VALUES: "-target-feature" "+v8.1a
+// MULTIPLE-VALUES-NOT: "-target-feature" "+v8.2a
+
+/// march to compiler and assembler, we choose the one suited to the input file type
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=armv8.3-a -march=armv8.4-a %s 2>&1 | \
+// RUN: FileCheck --check-prefix=TARGET-FEATURE-3 %s
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=armv8.3-a -march=armv8.4-a \
+// RUN: %S/Inputs/wildcard1.c 2>&1 | FileCheck --check-prefix=TARGET-FEATURE-4 %s
+
+// TARGET-FEATURE-3: "-target-feature" "+v8.3a"
+// TARGET-FEATURE-3-NOT: "-target-feature" "+v8.4a"
+// TARGET-FEATURE-4: "-target-feature" "+v8.4a"
+// TARGET-FEATURE-4-NOT: "-target-feature" "+v8.3a"
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -344,7 +344,7 @@
   case llvm::Triple::aarch64:
   case llvm::Triple::aarch64_32:
   case llvm::Triple::aarch64_be:
-aarch64::getAArch64TargetFeatures(D, Triple, Args, Features);
+aarch64::getAArch64TargetFeatures(D, Triple, Args, Features, ForAS);
 break;
   case llvm::Triple::x86:
   case llvm::Triple::x86_64:
Index: clang/lib/Driver/ToolChains/Arch/AArch64.h
===
--- clang/lib/Driver/ToolChains/Arch/AArch64.h
+++ clang/lib/Driver/ToolChains/Arch/AArch64.h
@@ -22,7 +22,8 @@
 
 void getAArch64TargetFeatures(const Driver , const llvm::Triple ,
   const llvm::opt::ArgList ,
-  std::vector );
+  std::vector ,
+  bool ForAS);
 
 std::string getAArch64TargetCPU(const llvm::opt::ArgList ,
 const llvm::Triple , llvm::opt::Arg *);
Index: clang/lib/Driver/ToolChains/Arch/AArch64.cpp
===
--- clang/lib/Driver/ToolChains/Arch/AArch64.cpp
+++ clang/lib/Driver/ToolChains/Arch/AArch64.cpp
@@ -185,12 +185,25 @@
 void aarch64::getAArch64TargetFeatures(const Driver ,
const llvm::Triple ,
const ArgList ,
-   std::vector ) {
+   std::vector ,
+   bool ForAS) {
   Arg *A;
   bool success = true;
   // Enable NEON by default.
   

[clang] 0eac975 - Reland "[AArch64] handle -Wa,-march="

[Jian Cai via cfe-commits]

Author: Jian Cai
Date: 2021-06-23T12:01:57-07:00
New Revision: 0eac975b51cca5b54a1f516d05a233c215375eda

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

LOG: Reland "[AArch64] handle -Wa,-march="

This reverts commit fd11a26d368c5a909fb88548fef2cee7a6c2c931, which was
reverted by 9145a3d4ab7eb05d9fb113b5392e8961df629b88 due to a test
failure on aarch64 backend, e.g.
https://lab.llvm.org/buildbot/#/builders/43/builds/7031. This patch
fixed the test failure.

Reviewed By: DavidSpickett, nickdesaulniers

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

Added: 
clang/test/Driver/aarch64-target-as-march.s

Modified: 
clang/lib/Driver/ToolChains/Arch/AArch64.cpp
clang/lib/Driver/ToolChains/Arch/AArch64.h
clang/lib/Driver/ToolChains/Clang.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Arch/AArch64.cpp 
b/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
index 503685ab533a0..ed8c7e94b0134 100644
--- a/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
+++ b/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
@@ -185,12 +185,25 @@ getAArch64MicroArchFeaturesFromMcpu(const Driver , 
StringRef Mcpu,
 void aarch64::getAArch64TargetFeatures(const Driver ,
const llvm::Triple ,
const ArgList ,
-   std::vector ) {
+   std::vector ,
+   bool ForAS) {
   Arg *A;
   bool success = true;
   // Enable NEON by default.
   Features.push_back("+neon");
-  if ((A = Args.getLastArg(options::OPT_march_EQ)))
+  llvm::StringRef WaMArch = "";
+  if (ForAS)
+for (const auto *A :
+ Args.filtered(options::OPT_Wa_COMMA, options::OPT_Xassembler))
+  for (StringRef Value : A->getValues())
+if (Value.startswith("-march="))
+  WaMArch = Value.substr(7);
+  // Call getAArch64ArchFeaturesFromMarch only if "-Wa,-march=" or
+  // "-Xassembler -march" is detected. Otherwise it may return false
+  // and causes Clang to error out.
+  if (WaMArch.size())
+success = getAArch64ArchFeaturesFromMarch(D, WaMArch, Args, Features);
+  else if ((A = Args.getLastArg(options::OPT_march_EQ)))
 success = getAArch64ArchFeaturesFromMarch(D, A->getValue(), Args, 
Features);
   else if ((A = Args.getLastArg(options::OPT_mcpu_EQ)))
 success = getAArch64ArchFeaturesFromMcpu(D, A->getValue(), Args, Features);

diff  --git a/clang/lib/Driver/ToolChains/Arch/AArch64.h 
b/clang/lib/Driver/ToolChains/Arch/AArch64.h
index 713af870d69fb..d47c402d4a42d 100644
--- a/clang/lib/Driver/ToolChains/Arch/AArch64.h
+++ b/clang/lib/Driver/ToolChains/Arch/AArch64.h
@@ -22,7 +22,8 @@ namespace aarch64 {
 
 void getAArch64TargetFeatures(const Driver , const llvm::Triple ,
   const llvm::opt::ArgList ,
-  std::vector );
+  std::vector ,
+  bool ForAS);
 
 std::string getAArch64TargetCPU(const llvm::opt::ArgList ,
 const llvm::Triple , llvm::opt::Arg 
*);

diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index b358813a1a017..0d1fce3c06aea 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -344,7 +344,7 @@ static void getTargetFeatures(const Driver , const 
llvm::Triple ,
   case llvm::Triple::aarch64:
   case llvm::Triple::aarch64_32:
   case llvm::Triple::aarch64_be:
-aarch64::getAArch64TargetFeatures(D, Triple, Args, Features);
+aarch64::getAArch64TargetFeatures(D, Triple, Args, Features, ForAS);
 break;
   case llvm::Triple::x86:
   case llvm::Triple::x86_64:

diff  --git a/clang/test/Driver/aarch64-target-as-march.s 
b/clang/test/Driver/aarch64-target-as-march.s
new file mode 100644
index 0..a9301ade43351
--- /dev/null
+++ b/clang/test/Driver/aarch64-target-as-march.s
@@ -0,0 +1,46 @@
+/// These tests make sure that options passed to the assembler
+/// via -Wa or -Xassembler are applied correctly to assembler inputs.
+
+/// Does not apply to non assembly files
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=armv8.1-a \
+// RUN: %S/Inputs/wildcard1.c 2>&1 | FileCheck --check-prefix=TARGET-FEATURE-1 
%s
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Xassembler 
-march=armv8.1-a \
+// RUN: %S/Inputs/wildcard1.c 2>&1 | FileCheck --check-prefix=TARGET-FEATURE-1 
%s
+
+// TARGET-FEATURE-1-NOT: "-target-feature" "+v8.1a"
+
+/// Does apply to assembler input
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=armv8.2-a %s 
2>&1 | \
+// RUN: FileCheck --check-prefix=TARGET-FEATURE-2 %s
+// RUN: %clang 

[PATCH] D104804: [AMDGPU] Add gfx1035 target

[Aakanksha Patil via Phabricator via cfe-commits]

aakanksha555 created this revision.
aakanksha555 added reviewers: kzhuravl, msearles, rampitec.
Herald added subscribers: foad, dexonsmith, kerbowa, rupprecht, hiraditya, 
t-tye, tpr, dstuttard, yaxunl, nhaehnle, jvesely, emaste, arsenm, jholewinski.
Herald added a reviewer: jhenderson.
Herald added a reviewer: MaskRay.
aakanksha555 requested review of this revision.
Herald added subscribers: llvm-commits, openmp-commits, cfe-commits, wdng.
Herald added projects: clang, OpenMP, LLVM.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104804

Files:
  clang/include/clang/Basic/Cuda.h
  clang/lib/Basic/Cuda.cpp
  clang/lib/Basic/Targets/AMDGPU.cpp
  clang/lib/Basic/Targets/NVPTX.cpp
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/test/CodeGenOpenCL/amdgpu-features.cl
  clang/test/Driver/amdgpu-macros.cl
  clang/test/Driver/amdgpu-mcpu.cl
  clang/test/Misc/target-invalid-cpu-note.c
  llvm/docs/AMDGPUUsage.rst
  llvm/include/llvm/BinaryFormat/ELF.h
  llvm/include/llvm/Support/TargetParser.h
  llvm/lib/Object/ELFObjectFile.cpp
  llvm/lib/ObjectYAML/ELFYAML.cpp
  llvm/lib/Support/TargetParser.cpp
  llvm/lib/Target/AMDGPU/GCNProcessors.td
  llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp
  llvm/test/CodeGen/AMDGPU/directive-amdgcn-target.ll
  llvm/test/CodeGen/AMDGPU/elf-header-flags-mach.ll
  llvm/test/MC/AMDGPU/gfx1011_dlops.s
  llvm/test/MC/AMDGPU/gfx1030_err.s
  llvm/test/MC/AMDGPU/gfx1030_new.s
  llvm/test/MC/Disassembler/AMDGPU/gfx1011_dasm_dlops.txt
  llvm/test/MC/Disassembler/AMDGPU/gfx1030_dasm_new.txt
  llvm/test/Object/AMDGPU/elf-header-flags-mach.yaml
  llvm/test/tools/llvm-objdump/ELF/AMDGPU/subtarget.ll
  llvm/test/tools/llvm-readobj/ELF/amdgpu-elf-headers.test
  llvm/tools/llvm-readobj/ELFDumper.cpp
  openmp/libomptarget/plugins/amdgpu/impl/get_elf_mach_gfx_name.cpp

Index: openmp/libomptarget/plugins/amdgpu/impl/get_elf_mach_gfx_name.cpp
===
--- openmp/libomptarget/plugins/amdgpu/impl/get_elf_mach_gfx_name.cpp
+++ openmp/libomptarget/plugins/amdgpu/impl/get_elf_mach_gfx_name.cpp
@@ -51,6 +51,8 @@
 return "gfx1033";
   case EF_AMDGPU_MACH_AMDGCN_GFX1034:
 return "gfx1034";
+  case EF_AMDGPU_MACH_AMDGCN_GFX1035:
+return "gfx1035";
   default:
 return "--unknown gfx";
   }
Index: llvm/tools/llvm-readobj/ELFDumper.cpp
===
--- llvm/tools/llvm-readobj/ELFDumper.cpp
+++ llvm/tools/llvm-readobj/ELFDumper.cpp
@@ -1488,6 +1488,7 @@
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1032),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1033),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1034),
+  LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1035),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_FEATURE_XNACK_V3),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_FEATURE_SRAMECC_V3)
 };
@@ -1541,6 +1542,7 @@
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1032),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1033),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1034),
+  LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1035),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_FEATURE_XNACK_ANY_V4),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_FEATURE_XNACK_OFF_V4),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_FEATURE_XNACK_ON_V4),
Index: llvm/test/tools/llvm-readobj/ELF/amdgpu-elf-headers.test
===
--- llvm/test/tools/llvm-readobj/ELF/amdgpu-elf-headers.test
+++ llvm/test/tools/llvm-readobj/ELF/amdgpu-elf-headers.test
@@ -277,6 +277,14 @@
 # RUN: yaml2obj %s -o %t -DABI_VERSION=2 -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_GFX1034
 # RUN: llvm-readobj -h %t | FileCheck %s --check-prefixes=ALL,KNOWN-ABI-VERSION,SINGLE-FLAG --match-full-lines -DABI_VERSION=2 -DFILE=%t -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_GFX1034 -DFLAG_VALUE=0x3E
 
+# RUN: yaml2obj %s -o %t -DABI_VERSION=0 -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_GFX1035
+# RUN: llvm-readobj -h %t | FileCheck %s --check-prefixes=ALL,KNOWN-ABI-VERSION,SINGLE-FLAG --match-full-lines -DABI_VERSION=0 -DFILE=%t -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_GFX1035 -DFLAG_VALUE=0x3D
+#
+# RUN: yaml2obj %s -o %t -DABI_VERSION=1 -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_GFX1035
+# RUN: llvm-readobj -h %t | FileCheck %s --check-prefixes=ALL,KNOWN-ABI-VERSION,SINGLE-FLAG --match-full-lines -DABI_VERSION=1 -DFILE=%t -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_GFX1035 -DFLAG_VALUE=0x3D
+#
+# RUN: yaml2obj %s -o %t -DABI_VERSION=2 -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_GFX1035
+# RUN: llvm-readobj -h %t | FileCheck %s --check-prefixes=ALL,KNOWN-ABI-VERSION,SINGLE-FLAG --match-full-lines -DABI_VERSION=2 -DFILE=%t -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_GFX1035 -DFLAG_VALUE=0x3D
 
 # RUN: yaml2obj %s -o %t -DABI_VERSION=0 -DFLAG_NAME="EF_AMDGPU_MACH_AMDGCN_GFX90A, EF_AMDGPU_FEATURE_XNACK_V3"
 # RUN: llvm-readobj -h %t | FileCheck %s --check-prefixes=ALL,KNOWN-ABI-VERSION,DOUBLE-FLAG 

[PATCH] D104388: [clang-format] PR50727 C# Invoke Lamda Expression indentation incorrect

[Eliza Velasquez via Phabricator via cfe-commits]

exv requested changes to this revision.
exv added a comment.
This revision now requires changes to proceed.

Oops, didn't mean to accept, see my other comment.


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

https://reviews.llvm.org/D104388

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

[PATCH] D104388: [clang-format] PR50727 C# Invoke Lamda Expression indentation incorrect

[Eliza Velasquez via Phabricator via cfe-commits]

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

I have a few concerns about this implementation:

- If the incorrect formatting is due to `lock` and `using` not being recognized 
correctly, shouldn't we instead fix how those keywords are parsed?
- In the examples of Microsoft style that I've seen, statement lambdas always 
place the brace on a new line from the arrow. If used as a function argument 
like this, does that rule no longer apply? I'm having difficulty finding an 
example of that specific usage in Microsoft's docs.


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

https://reviews.llvm.org/D104388

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

[PATCH] D104505: [HIP] Defer operator overloading errors

[Artem Belevich via Phabricator via cfe-commits]

tra accepted this revision.
tra added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/test/SemaCUDA/deferred-oeverload.cu:55
  callee3(); // dev-error {{no matching function for call to 'callee3'}}
  callee4(); // com-error {{no matching function for call to 'callee4'}}
+ S s;

yaxunl wrote:
> tra wrote:
> > If we're allowing to postpone an invalid call of a host function, shouldn't 
> > we also allow postponing other errors? 
> > E.g. should we postpone the error on an attempt to call `callee4()` ?
> > Similarly, if we were to call a `undeclared_func()` here, should the error 
> > also be postponed?
> > 
> > TBH, I don't quite understand now how to tell what is and isn't supposed to 
> > be deferred with `-fgpu-defer-diags`.
> > Is there a clear criteria what should and should not be deferred?
> > 
> We discussed about what diagnostics to be deferred before. We do not want to 
> defer all diagnostics since nvcc apparently only ignores host/device related 
> diagnostics. Our previous conclusion is to defer overloading resolution 
> related diagnostics when the full candidates set include host device 
> functions or wrong-sided candidates. This roughly matches nvcc's behavior.
Please bear with me. I don't have all the relevant context in my head. Nor 
would anyone else looking at the patch.

> Our previous conclusion is to defer overloading resolution related 
> diagnostics when the full candidates set include host device functions or 
> wrong-sided candidates. This roughly matches nvcc's behavior.

Thank you. This should probably be added somewhere at the top of this test 
file. 


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

https://reviews.llvm.org/D104505

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

[PATCH] D104553: [compiler-rt][hwasan] Add InitState options to thread initialization

[Leonard Chan via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGb06fbdeae752: [compiler-rt][hwasan] Add InitState options to 
thread initialization (authored by leonardchan).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104553

Files:
  compiler-rt/lib/hwasan/hwasan_linux.cpp
  compiler-rt/lib/hwasan/hwasan_thread.cpp
  compiler-rt/lib/hwasan/hwasan_thread.h
  compiler-rt/lib/hwasan/hwasan_thread_list.h


Index: compiler-rt/lib/hwasan/hwasan_thread_list.h
===
--- compiler-rt/lib/hwasan/hwasan_thread_list.h
+++ compiler-rt/lib/hwasan/hwasan_thread_list.h
@@ -85,7 +85,7 @@
 RoundUpTo(ring_buffer_size_ + sizeof(Thread), ring_buffer_size_ * 2);
   }
 
-  Thread *CreateCurrentThread() {
+  Thread *CreateCurrentThread(const Thread::InitState *state = nullptr) {
 Thread *t = nullptr;
 {
   SpinMutexLock l(_list_mutex_);
@@ -104,7 +104,7 @@
   SpinMutexLock l(_list_mutex_);
   live_list_.push_back(t);
 }
-t->Init((uptr)t - ring_buffer_size_, ring_buffer_size_);
+t->Init((uptr)t - ring_buffer_size_, ring_buffer_size_, state);
 AddThreadStats(t);
 return t;
   }
Index: compiler-rt/lib/hwasan/hwasan_thread.h
===
--- compiler-rt/lib/hwasan/hwasan_thread.h
+++ compiler-rt/lib/hwasan/hwasan_thread.h
@@ -23,9 +23,13 @@
 
 class Thread {
  public:
-  void Init(uptr stack_buffer_start, uptr stack_buffer_size);
+  // These are optional parameters that can be passed to Init.
+  struct InitState;
+
+  void Init(uptr stack_buffer_start, uptr stack_buffer_size,
+const InitState *state = nullptr);
   void InitRandomState();
-  void InitStackAndTls();
+  void InitStackAndTls(const InitState *state = nullptr);
 
   // Must be called from the thread itself.
   void InitStackRingBuffer(uptr stack_buffer_start, uptr stack_buffer_size);
Index: compiler-rt/lib/hwasan/hwasan_thread.cpp
===
--- compiler-rt/lib/hwasan/hwasan_thread.cpp
+++ compiler-rt/lib/hwasan/hwasan_thread.cpp
@@ -34,7 +34,8 @@
 stack_allocations_->push(0);
 }
 
-void Thread::Init(uptr stack_buffer_start, uptr stack_buffer_size) {
+void Thread::Init(uptr stack_buffer_start, uptr stack_buffer_size,
+  const InitState *state) {
   CHECK_EQ(0, unique_id_);  // try to catch bad stack reuse
   CHECK_EQ(0, stack_top_);
   CHECK_EQ(0, stack_bottom_);
@@ -44,7 +45,7 @@
   if (auto sz = flags()->heap_history_size)
 heap_allocations_ = HeapAllocationsRingBuffer::New(sz);
 
-  InitStackAndTls();
+  InitStackAndTls(state);
   InitStackRingBuffer(stack_buffer_start, stack_buffer_size);
 }
 
Index: compiler-rt/lib/hwasan/hwasan_linux.cpp
===
--- compiler-rt/lib/hwasan/hwasan_linux.cpp
+++ compiler-rt/lib/hwasan/hwasan_linux.cpp
@@ -428,7 +428,7 @@
   HandleDeadlySignal(info, context, GetTid(), , nullptr);
 }
 
-void Thread::InitStackAndTls() {
+void Thread::InitStackAndTls(const InitState *) {
   uptr tls_size;
   uptr stack_size;
   GetThreadStackAndTls(IsMainThread(), _bottom_, _size, 
_begin_,


Index: compiler-rt/lib/hwasan/hwasan_thread_list.h
===
--- compiler-rt/lib/hwasan/hwasan_thread_list.h
+++ compiler-rt/lib/hwasan/hwasan_thread_list.h
@@ -85,7 +85,7 @@
 RoundUpTo(ring_buffer_size_ + sizeof(Thread), ring_buffer_size_ * 2);
   }
 
-  Thread *CreateCurrentThread() {
+  Thread *CreateCurrentThread(const Thread::InitState *state = nullptr) {
 Thread *t = nullptr;
 {
   SpinMutexLock l(_list_mutex_);
@@ -104,7 +104,7 @@
   SpinMutexLock l(_list_mutex_);
   live_list_.push_back(t);
 }
-t->Init((uptr)t - ring_buffer_size_, ring_buffer_size_);
+t->Init((uptr)t - ring_buffer_size_, ring_buffer_size_, state);
 AddThreadStats(t);
 return t;
   }
Index: compiler-rt/lib/hwasan/hwasan_thread.h
===
--- compiler-rt/lib/hwasan/hwasan_thread.h
+++ compiler-rt/lib/hwasan/hwasan_thread.h
@@ -23,9 +23,13 @@
 
 class Thread {
  public:
-  void Init(uptr stack_buffer_start, uptr stack_buffer_size);
+  // These are optional parameters that can be passed to Init.
+  struct InitState;
+
+  void Init(uptr stack_buffer_start, uptr stack_buffer_size,
+const InitState *state = nullptr);
   void InitRandomState();
-  void InitStackAndTls();
+  void InitStackAndTls(const InitState *state = nullptr);
 
   // Must be called from the thread itself.
   void InitStackRingBuffer(uptr stack_buffer_start, uptr stack_buffer_size);
Index: compiler-rt/lib/hwasan/hwasan_thread.cpp
===
--- 

[PATCH] D104388: [clang-format] PR50727 C# Invoke Lamda Expression indentation incorrect

[Björn Schäpers via Phabricator via cfe-commits]

HazardyKnusperkeks added a comment.

I have basically no idea about C#, thus not much to say. I think if the old 
tests pass and the new are as expected it is good.




Comment at: clang/unittests/Format/FormatTestCSharp.cpp:647
+   "Function(Val, (Action)(() => {\n"
+   " lock (mylock)\n"
+   " {\n"

How is that indention calculated? Is this position fix? Or is it always one 
column less than the (presumably) start of the lambda?

Maybe add a test not with `Val`, but something else as first argument. Or is 
this not valid?

As said, basically no idea about C#.


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

https://reviews.llvm.org/D104388

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

[PATCH] D104774: [clang-format] Fix a bug that indents else-comment-if incorrectly

[Björn Schäpers via Phabricator via cfe-commits]

HazardyKnusperkeks added a comment.

That was fast. I personally like it better to give others a chance to look at. 
;)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104774

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

[PATCH] D104803: [AIX] Emitting diagnostics error for profile options

[Whitney Tsang via Phabricator via cfe-commits]

Whitney created this revision.
Whitney added reviewers: hubert.reinterpretcast, etiotto, bmahjour, kbarton, 
daltenty.
Whitney added a project: LLVM.
Whitney requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Only LLVM-based instrumentation profile is supported on AIX.
And it currently must be used with full LTO.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104803

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/unsupported-option.c


Index: clang/test/Driver/unsupported-option.c
===
--- clang/test/Driver/unsupported-option.c
+++ clang/test/Driver/unsupported-option.c
@@ -1,7 +1,20 @@
 // RUN: not %clang %s --hedonism -### 2>&1 | \
 // RUN: FileCheck %s
+// CHECK: error: unsupported option '--hedonism'
+
 // RUN: not %clang %s --hell -### 2>&1 | \
 // RUN: FileCheck %s --check-prefix=DID-YOU-MEAN
-
-// CHECK: error: unsupported option '--hedonism'
 // DID-YOU-MEAN: error: unsupported option '--hell'; did you mean '--help'?
+
+// RUN: not %clang -fprofile-instr-generate -fprofile-sample-use=code.prof 
--target=powerpc-ibm-aix %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=INVALID-AIX-PROFILE
+// INVALID-AIX-PROFILE-DAG: error: unsupported option 
'-fprofile-instr-generate' for target
+// INVALID-AIX-PROFILE-DAG: error: unsupported option '-fprofile-sample-use=' 
for target
+
+// RUN: not %clang -fprofile-generate --target=powerpc-ibm-aix %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=AIX-PROFILE-LTO
+// AIX-PROFILE-LTO: error: invalid argument '-fprofile-generate' only allowed 
with '-flto'
+
+// RUN: not %clang -fprofile-generate -flto=thin --target=powerpc-ibm-aix %s 
2>&1 | \
+// RUN: FileCheck %s --check-prefix=AIX-PROFILE-THINLTO
+// AIX-PROFILE-THINLTO: error: invalid argument '-fprofile-generate' only 
allowed with '-flto'
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -776,6 +776,21 @@
   options::OPT_fprofile_instr_generate,
   options::OPT_fprofile_instr_generate_EQ,
   options::OPT_fno_profile_instr_generate);
+
+  if (TC.getTriple().isOSAIX()) {
+if (PGOGenerateArg)
+  if (!D.isUsingLTO(false /*IsDeviceOffloadAction */) ||
+  D.getLTOMode() != LTOK_Full)
+D.Diag(clang::diag::err_drv_argument_only_allowed_with)
+<< PGOGenerateArg->getSpelling() << "-flto";
+if (ProfileGenerateArg)
+  D.Diag(diag::err_drv_unsupported_opt_for_target)
+  << ProfileGenerateArg->getSpelling() << TC.getTriple().str();
+if (Arg *ProfileSampleUseArg = getLastProfileSampleUseArg(Args))
+  D.Diag(diag::err_drv_unsupported_opt_for_target)
+  << ProfileSampleUseArg->getSpelling() << TC.getTriple().str();
+  } 
+
   if (ProfileGenerateArg &&
   ProfileGenerateArg->getOption().matches(
   options::OPT_fno_profile_instr_generate))


Index: clang/test/Driver/unsupported-option.c
===
--- clang/test/Driver/unsupported-option.c
+++ clang/test/Driver/unsupported-option.c
@@ -1,7 +1,20 @@
 // RUN: not %clang %s --hedonism -### 2>&1 | \
 // RUN: FileCheck %s
+// CHECK: error: unsupported option '--hedonism'
+
 // RUN: not %clang %s --hell -### 2>&1 | \
 // RUN: FileCheck %s --check-prefix=DID-YOU-MEAN
-
-// CHECK: error: unsupported option '--hedonism'
 // DID-YOU-MEAN: error: unsupported option '--hell'; did you mean '--help'?
+
+// RUN: not %clang -fprofile-instr-generate -fprofile-sample-use=code.prof --target=powerpc-ibm-aix %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=INVALID-AIX-PROFILE
+// INVALID-AIX-PROFILE-DAG: error: unsupported option '-fprofile-instr-generate' for target
+// INVALID-AIX-PROFILE-DAG: error: unsupported option '-fprofile-sample-use=' for target
+
+// RUN: not %clang -fprofile-generate --target=powerpc-ibm-aix %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=AIX-PROFILE-LTO
+// AIX-PROFILE-LTO: error: invalid argument '-fprofile-generate' only allowed with '-flto'
+
+// RUN: not %clang -fprofile-generate -flto=thin --target=powerpc-ibm-aix %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=AIX-PROFILE-THINLTO
+// AIX-PROFILE-THINLTO: error: invalid argument '-fprofile-generate' only allowed with '-flto'
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -776,6 +776,21 @@
   options::OPT_fprofile_instr_generate,
   options::OPT_fprofile_instr_generate_EQ,
   options::OPT_fno_profile_instr_generate);
+
+  if (TC.getTriple().isOSAIX()) {
+if (PGOGenerateArg)
+  if (!D.isUsingLTO(false /*IsDeviceOffloadAction */) ||
+  D.getLTOMode() != LTOK_Full)
+

[PATCH] D104790: [x86] fix mm*_undefined* intrinsics to use arbitrary frozen bit pattern

[Craig Topper via Phabricator via cfe-commits]

craig.topper added a comment.

We may want to update the code in X86ISelLowering getAVX2GatherNode and 
getGatherNode to replace freeze+poison on Src with a zero vector. We already do 
this when the Src is undef.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104790

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

[PATCH] D104800: [OpenCL] Do not include default header for preprocessor output as input

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

In D104800#2836594 , @yaxunl wrote:

> I am not quite sure about whether "-fdeclare-opencl-builtins" should be kept 
> when input is preprocessor output. Suggestions? Thanks.

The question is that whether those builtins declared through 
"-fdeclare-opencl-builtins" will be in preprocessor expansion output. It seems 
not. If so, we still need "-fdeclare-opencl-builtins" when input type is 
preprocessor expansion output.


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

https://reviews.llvm.org/D104800

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

[PATCH] D104082: [CodeGen] Don't create a fake FunctionDecl when generating block/block_byref copy/dispose helper functions

[Zequan Wu via Phabricator via cfe-commits]

zequanwu added a comment.

In D104082#2835496 , @fhahn wrote:

> In D104082#2835080 , @zequanwu 
> wrote:
>
>> Hi, this caused compiler crash with error "Assertion 
>> `cast(Scope)->describes(>getFunction())' failed." on iOS 
>> platforms.  So, I reverted it.
>> I'm working on a reduced repro.
>
> FYI this also caused a failure on GreenDragon, with `-verify-machineinstrs`: 
> https://green.lab.llvm.org/green/job/test-suite-verify-machineinstrs-aarch64-O0-g/9663/consoleFull#-134330334249ba4694-19c4-4d7e-bec5-911270d8a58c
>
> The failure should be re-producible by building the following C++ file from 
> llvm-test-suite:
>
>   bin/clang++  -DNDEBUG  -B 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
> -Wno-unused-command-line-argument -mllvm -verify-machineinstrs -O0 -g 
> -arch arm64 -isysroot 
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.5.sdk
>-w -Werror=date-time -MD -MT 
> SingleSource/UnitTests/CMakeFiles/block-byref-cxxobj-test.dir/block-byref-cxxobj-test.cpp.o
>  -MF 
> SingleSource/UnitTests/CMakeFiles/block-byref-cxxobj-test.dir/block-byref-cxxobj-test.cpp.o.d
>  -o 
> SingleSource/UnitTests/CMakeFiles/block-byref-cxxobj-test.dir/block-byref-cxxobj-test.cpp.o
>  -c 
> /Users/buildslave/jenkins/workspace/test-suite-verify-machineinstrs-aarch64-O0-g/test-suite/SingleSource/UnitTests/block-byref-cxxobj-test.cpp

Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104082

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

[PATCH] D104777: PR50767: clear non-distinct debuginfo for function with nodebug definition after undecorated declaration

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

In D104777#2836327 , @aaron.ballman 
wrote:

> In D104777#2835965 , @dblaikie 
> wrote:
>
>> @aaron.ballman Do we have attributes/infrastructure for attributes that have 
>> to be the same from their first declaration or at least from their first 
>> call? I'm wondering if it might be simpler/better to require nodebug to be 
>> provided earlier, rather than fixing it up after the fact like this.
>>
>> (for instance, requiring it to be attributed on the declaration would ensure 
>> we don't create call_site descriptions for calls to nodebug functions - 
>> which would save some debug info size)
>
> We don't have any attributes that have to be the same "from their first call" 
> that I'm aware of. But we do have attributes that need to be the same on all 
> declarations. IIRC, the `section` and `code_seg` attributes both have to be 
> specified on the initial declaration in some circumstances, and 
> `[[noreturn]]` needs to be on the first declaration we see. We don't have any 
> tablegen machinery to enforce this, the logic needs to be manually written. I 
> think it'd live somewhere around `Sema::mergeDeclAttributes()` or 
> `Sema::MergeFunctionDecl()` most likely.

Yeah, all that sounds reasonable to me - @brunodefraine could you look into 
supporting nodebug in a similar way as @aaron.ballman has described here?

> Fixing up after the fact would be a bit strange though. A declaration is 
> typically considered marked by an attribute from the point of declaration 
> including the attribute onward, not backwards. e.g., 
> https://godbolt.org/z/4E1Ya764n I won't say we *never* do this back 
> propagation, but I would say it's a sign that the attribute is venturing into 
> novel, perhaps dangerous territory. For example with this patch, an AST 
> matcher won't see the `nodebug` attribute on the initial declaration of 
> `t1()` and so it won't react to it the same way that codegen is being changed.

Yeah, fair concerns for sure - thanks for the tips!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104777

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

[PATCH] D104505: [HIP] Defer operator overloading errors

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added inline comments.



Comment at: clang/test/SemaCUDA/deferred-oeverload.cu:55
  callee3(); // dev-error {{no matching function for call to 'callee3'}}
  callee4(); // com-error {{no matching function for call to 'callee4'}}
+ S s;

tra wrote:
> If we're allowing to postpone an invalid call of a host function, shouldn't 
> we also allow postponing other errors? 
> E.g. should we postpone the error on an attempt to call `callee4()` ?
> Similarly, if we were to call a `undeclared_func()` here, should the error 
> also be postponed?
> 
> TBH, I don't quite understand now how to tell what is and isn't supposed to 
> be deferred with `-fgpu-defer-diags`.
> Is there a clear criteria what should and should not be deferred?
> 
We discussed about what diagnostics to be deferred before. We do not want to 
defer all diagnostics since nvcc apparently only ignores host/device related 
diagnostics. Our previous conclusion is to defer overloading resolution related 
diagnostics when the full candidates set include host device functions or 
wrong-sided candidates. This roughly matches nvcc's behavior.


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

https://reviews.llvm.org/D104505

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

[clang] 4a14206 - [AIX] Emitting diagnostics error for profile options

[Whitney Tsang via cfe-commits]

Author: Whitney Tsang
Date: 2021-06-23T18:17:40Z
New Revision: 4a14206522384f5868227145a6598f41710e6c91

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

LOG: [AIX] Emitting diagnostics error for profile options

Added: 


Modified: 
clang/lib/Driver/ToolChains/Clang.cpp
clang/test/Driver/unsupported-option.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index b358813a1a017..aae56c8e87e3b 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -776,6 +776,21 @@ static void addPGOAndCoverageFlags(const ToolChain , 
Compilation ,
   options::OPT_fprofile_instr_generate,
   options::OPT_fprofile_instr_generate_EQ,
   options::OPT_fno_profile_instr_generate);
+
+  if (TC.getTriple().isOSAIX()) {
+if (PGOGenerateArg)
+  if (!D.isUsingLTO(false /*IsDeviceOffloadAction */) ||
+  D.getLTOMode() != LTOK_Full)
+D.Diag(clang::diag::err_drv_argument_only_allowed_with)
+<< PGOGenerateArg->getSpelling() << "-flto";
+if (ProfileGenerateArg)
+  D.Diag(diag::err_drv_unsupported_opt_for_target)
+  << ProfileGenerateArg->getSpelling() << TC.getTriple().str();
+if (Arg *ProfileSampleUseArg = getLastProfileSampleUseArg(Args))
+  D.Diag(diag::err_drv_unsupported_opt_for_target)
+  << ProfileSampleUseArg->getSpelling() << TC.getTriple().str();
+  } 
+
   if (ProfileGenerateArg &&
   ProfileGenerateArg->getOption().matches(
   options::OPT_fno_profile_instr_generate))

diff  --git a/clang/test/Driver/unsupported-option.c 
b/clang/test/Driver/unsupported-option.c
index d0611977a99e1..91b6b585a36e7 100644
--- a/clang/test/Driver/unsupported-option.c
+++ b/clang/test/Driver/unsupported-option.c
@@ -1,7 +1,20 @@
 // RUN: not %clang %s --hedonism -### 2>&1 | \
 // RUN: FileCheck %s
+// CHECK: error: unsupported option '--hedonism'
+
 // RUN: not %clang %s --hell -### 2>&1 | \
 // RUN: FileCheck %s --check-prefix=DID-YOU-MEAN
-
-// CHECK: error: unsupported option '--hedonism'
 // DID-YOU-MEAN: error: unsupported option '--hell'; did you mean '--help'?
+
+// RUN: not %clang -fprofile-instr-generate -fprofile-sample-use=code.prof 
--target=powerpc-ibm-aix %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=INVALID-AIX-PROFILE
+// INVALID-AIX-PROFILE-DAG: error: unsupported option 
'-fprofile-instr-generate' for target
+// INVALID-AIX-PROFILE-DAG: error: unsupported option '-fprofile-sample-use=' 
for target
+
+// RUN: not %clang -fprofile-generate --target=powerpc-ibm-aix %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=AIX-PROFILE-LTO
+// AIX-PROFILE-LTO: error: invalid argument '-fprofile-generate' only allowed 
with '-flto'
+
+// RUN: not %clang -fprofile-generate -flto=thin --target=powerpc-ibm-aix %s 
2>&1 | \
+// RUN: FileCheck %s --check-prefix=AIX-PROFILE-THINLTO
+// AIX-PROFILE-THINLTO: error: invalid argument '-fprofile-generate' only 
allowed with '-flto'



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

[PATCH] D104058: ThinLTO: Fix inline assembly references to static functions with CFI

[Sami Tolvanen 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 rGe3d24b45b8f8: ThinLTO: Fix inline assembly references to 
static functions with CFI (authored by samitolvanen).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104058

Files:
  llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp
  llvm/test/Transforms/ThinLTOBitcodeWriter/cfi-icall-static-inline-asm.ll


Index: llvm/test/Transforms/ThinLTOBitcodeWriter/cfi-icall-static-inline-asm.ll
===
--- /dev/null
+++ llvm/test/Transforms/ThinLTOBitcodeWriter/cfi-icall-static-inline-asm.ll
@@ -0,0 +1,19 @@
+; RUN: opt -thinlto-bc -thinlto-split-lto-unit -o - %s | llvm-modextract -b -n 
0 -o - | llvm-dis | FileCheck %s
+
+; CHECK: @a = internal alias {{.*}}@a.[[HASH:[0-9a-f]+]]
+
+define void @b() {
+  %f = alloca void ()*, align 8
+  ; CHECK: store{{.*}} @a.[[HASH]],{{.*}} %f
+  store void ()* @a, void ()** %f, align 8
+  ; CHECK: %1 = call void ()* asm sideeffect "leaq a(%rip)
+  %1 = call void ()* asm sideeffect "leaq a(%rip), $0\0A\09", 
"=r,~{dirflag},~{fpsr},~{flags}"()
+  ret void
+}
+
+; CHECK: define{{.*}} @a.[[HASH]](){{.*}} !type
+define internal void @a() !type !0 {
+  ret void
+}
+
+!0 = !{i64 0, !"typeid1"}
Index: llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp
===
--- llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp
+++ llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp
@@ -55,6 +55,7 @@
   }
 }
 
+std::string OldName = Name.str();
 std::string NewName = (Name + ModuleId).str();
 
 if (const auto *C = ExportGV.getComdat())
@@ -69,6 +70,15 @@
   ImportGV->setName(NewName);
   ImportGV->setVisibility(GlobalValue::HiddenVisibility);
 }
+
+if (Function *F = dyn_cast()) {
+  // Create a local alias with the original name to avoid breaking
+  // references from inline assembly.
+  GlobalAlias *A = GlobalAlias::create(
+  F->getValueType(), F->getAddressSpace(), 
GlobalValue::InternalLinkage,
+  OldName, F, );
+  appendToCompilerUsed(ExportM, A);
+}
   }
 
   if (!RenamedComdats.empty())


Index: llvm/test/Transforms/ThinLTOBitcodeWriter/cfi-icall-static-inline-asm.ll
===
--- /dev/null
+++ llvm/test/Transforms/ThinLTOBitcodeWriter/cfi-icall-static-inline-asm.ll
@@ -0,0 +1,19 @@
+; RUN: opt -thinlto-bc -thinlto-split-lto-unit -o - %s | llvm-modextract -b -n 0 -o - | llvm-dis | FileCheck %s
+
+; CHECK: @a = internal alias {{.*}}@a.[[HASH:[0-9a-f]+]]
+
+define void @b() {
+  %f = alloca void ()*, align 8
+  ; CHECK: store{{.*}} @a.[[HASH]],{{.*}} %f
+  store void ()* @a, void ()** %f, align 8
+  ; CHECK: %1 = call void ()* asm sideeffect "leaq a(%rip)
+  %1 = call void ()* asm sideeffect "leaq a(%rip), $0\0A\09", "=r,~{dirflag},~{fpsr},~{flags}"()
+  ret void
+}
+
+; CHECK: define{{.*}} @a.[[HASH]](){{.*}} !type
+define internal void @a() !type !0 {
+  ret void
+}
+
+!0 = !{i64 0, !"typeid1"}
Index: llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp
===
--- llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp
+++ llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp
@@ -55,6 +55,7 @@
   }
 }
 
+std::string OldName = Name.str();
 std::string NewName = (Name + ModuleId).str();
 
 if (const auto *C = ExportGV.getComdat())
@@ -69,6 +70,15 @@
   ImportGV->setName(NewName);
   ImportGV->setVisibility(GlobalValue::HiddenVisibility);
 }
+
+if (Function *F = dyn_cast()) {
+  // Create a local alias with the original name to avoid breaking
+  // references from inline assembly.
+  GlobalAlias *A = GlobalAlias::create(
+  F->getValueType(), F->getAddressSpace(), GlobalValue::InternalLinkage,
+  OldName, F, );
+  appendToCompilerUsed(ExportM, A);
+}
   }
 
   if (!RenamedComdats.empty())
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D100118: [clang] Add support for new builtin __arithmetic_fence to control floating point optimization, and new clang option fprotect-parens

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/test/AST/arithmetic-fence-builtin.c:34
+
+  v = (a + b);
+

aaron.ballman wrote:
> Does the `(a + b)` still have an AST node for the `ParenExpr`?
Nevermind, it won't, it'll have the `CallExpr` node.

I think this may be somewhat surprising to folks who use AST matchers or 
`-ast-print`, but I'm not certain that there's a better way to implement this 
that would keep the `ParenExpr` in the AST for full source fidelity, so I think 
this is reasonable enough.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100118

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

[PATCH] D104800: [OpenCL] Do not include default header for preprocessor output as input

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

I am not quite sure about whether "-fdeclare-opencl-builtins" should be kept 
when input is preprocessor output. Suggestions? Thanks.


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

https://reviews.llvm.org/D104800

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

[PATCH] D104800: [OpenCL] Do not include default header for preprocessor output as input

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl created this revision.
yaxunl added a reviewer: Anastasia.
Herald added subscribers: kerbowa, nhaehnle, jvesely.
yaxunl requested review of this revision.

When clang driver is used with -save-temps to compile OpenCL program,
clang driver first launches clang -cc1 -E to generate preprocessor expansion 
output,
then launches clang -cc1 with the generated preprocessor expansion output as 
input
to generate LLVM IR.

Currently clang by default passes "-finclude-default-header" 
"-fdeclare-opencl-builtins"
in both steps, which causes default header included again in the second step, 
which
causes error.

This patch let clang not to include default header when input type is 
preprocessor expansion
output, which fixes the issue.


https://reviews.llvm.org/D104800

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/amdgpu-toolchain-opencl.cl


Index: clang/test/Driver/amdgpu-toolchain-opencl.cl
===
--- clang/test/Driver/amdgpu-toolchain-opencl.cl
+++ clang/test/Driver/amdgpu-toolchain-opencl.cl
@@ -7,6 +7,12 @@
 // RUN: %clang -### -target amdgcn-amd-amdhsa-opencl -x cl -c -emit-llvm 
-mcpu=fiji -Og %s 2>&1 | FileCheck -check-prefix=CHECK_Og %s
 // RUN: %clang -### -target amdgcn-amd-amdhsa-opencl -x cl -c -emit-llvm 
-mcpu=fiji -Ofast %s 2>&1 | FileCheck -check-prefix=CHECK_Ofast %s
 // RUN: %clang -### -target amdgcn-amd-amdhsa-opencl -x cl -c -emit-llvm 
-mcpu=fiji %s 2>&1 | FileCheck -check-prefix=CHECK_O_DEFAULT %s
+
+// Check default include file is not included for preprocessor output.
+
+// RUN: %clang -### -target amdgcn-amd-amdhsa-opencl -x cl -c -emit-llvm 
-mcpu=fiji %s 2>&1 | FileCheck -check-prefix=CHK-INC %s
+// RUN: %clang -### -target amdgcn-amd-amdhsa-opencl -x cl -c -emit-llvm 
-mcpu=fiji -save-temps %s 2>&1 | FileCheck -check-prefix=CHK-INC %s
+
 // CHECK_O0: clang{{.*}} "-O0"
 // CHECK_O1: clang{{.*}} "-O1"
 // CHECK_O2: clang{{.*}} "-O2"
@@ -17,3 +23,5 @@
 // CHECK_Ofast: {{.*}}clang{{.*}} "-Ofast"
 // CHECK_O_DEFAULT: clang{{.*}} "-O3"
 
+// CHK-INC: clang{{.*}} "-cc1" {{.*}}"-finclude-default-header" 
"-fdeclare-opencl-builtins" {{.*}}"-x" "cl"
+// CHK-INC-NOT: clang{{.*}} "-cc1" {{.*}}"-finclude-default-header" 
"-fdeclare-opencl-builtins" {{.*}}"-x" "cpp-output"
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -3272,7 +3272,8 @@
   CmdArgs.push_back(Args.MakeArgString(A->getOption().getPrefixedName()));
 
   // Only add the default headers if we are compiling OpenCL sources.
-  if ((types::isOpenCL(InputType) || Args.hasArg(options::OPT_cl_std_EQ)) &&
+  if ((types::isOpenCL(InputType) ||
+   (Args.hasArg(options::OPT_cl_std_EQ) && types::isSrcFile(InputType))) &&
   !Args.hasArg(options::OPT_cl_no_stdinc)) {
 CmdArgs.push_back("-finclude-default-header");
 CmdArgs.push_back("-fdeclare-opencl-builtins");


Index: clang/test/Driver/amdgpu-toolchain-opencl.cl
===
--- clang/test/Driver/amdgpu-toolchain-opencl.cl
+++ clang/test/Driver/amdgpu-toolchain-opencl.cl
@@ -7,6 +7,12 @@
 // RUN: %clang -### -target amdgcn-amd-amdhsa-opencl -x cl -c -emit-llvm -mcpu=fiji -Og %s 2>&1 | FileCheck -check-prefix=CHECK_Og %s
 // RUN: %clang -### -target amdgcn-amd-amdhsa-opencl -x cl -c -emit-llvm -mcpu=fiji -Ofast %s 2>&1 | FileCheck -check-prefix=CHECK_Ofast %s
 // RUN: %clang -### -target amdgcn-amd-amdhsa-opencl -x cl -c -emit-llvm -mcpu=fiji %s 2>&1 | FileCheck -check-prefix=CHECK_O_DEFAULT %s
+
+// Check default include file is not included for preprocessor output.
+
+// RUN: %clang -### -target amdgcn-amd-amdhsa-opencl -x cl -c -emit-llvm -mcpu=fiji %s 2>&1 | FileCheck -check-prefix=CHK-INC %s
+// RUN: %clang -### -target amdgcn-amd-amdhsa-opencl -x cl -c -emit-llvm -mcpu=fiji -save-temps %s 2>&1 | FileCheck -check-prefix=CHK-INC %s
+
 // CHECK_O0: clang{{.*}} "-O0"
 // CHECK_O1: clang{{.*}} "-O1"
 // CHECK_O2: clang{{.*}} "-O2"
@@ -17,3 +23,5 @@
 // CHECK_Ofast: {{.*}}clang{{.*}} "-Ofast"
 // CHECK_O_DEFAULT: clang{{.*}} "-O3"
 
+// CHK-INC: clang{{.*}} "-cc1" {{.*}}"-finclude-default-header" "-fdeclare-opencl-builtins" {{.*}}"-x" "cl"
+// CHK-INC-NOT: clang{{.*}} "-cc1" {{.*}}"-finclude-default-header" "-fdeclare-opencl-builtins" {{.*}}"-x" "cpp-output"
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -3272,7 +3272,8 @@
   CmdArgs.push_back(Args.MakeArgString(A->getOption().getPrefixedName()));
 
   // Only add the default headers if we are compiling OpenCL sources.
-  if ((types::isOpenCL(InputType) || Args.hasArg(options::OPT_cl_std_EQ)) &&
+  if ((types::isOpenCL(InputType) ||
+   (Args.hasArg(options::OPT_cl_std_EQ) && 

[PATCH] D100118: [clang] Add support for new builtin __arithmetic_fence to control floating point optimization, and new clang option fprotect-parens

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/include/clang/Driver/Options.td:1757
+  LangOpts<"ProtectParens">, DefaultFalse,
+  PosFlag aaron.ballman wrote:
> > Should this option also be exposed to clang-cl (should it be a 
> > `CoreOption`)?
> I don't know the answer to this, do you have a recommendation? 
I think this would be useful for clang-cl users, so I'd recommend adding it to 
`CoreOption` unless there's a reason not to.



Comment at: clang/lib/AST/ExprConstant.cpp:9329-9331
+  case Builtin::BI__arithmetic_fence:
+return false;
+

Under what circumstances could we get here? (Given that this is within 
`PointerExprEvaluator`, I would have assumed this would be unreachable code.)



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:2841
+llvm::FastMathFlags FMF = Builder.getFastMathFlags();
+bool isArithmeticFenceEnabled = FMF.allowReassoc() &&
+  getContext().getTargetInfo().checkArithmeticFenceSupported();

May as well fix this clang-format issue.



Comment at: clang/lib/Sema/SemaExpr.cpp:6568
+Expr *Sema::BuildBuiltinCallExpr(SourceLocation Loc, Builtin::ID Id,
+  MultiExprArg CallArgs) {
+  StringRef Name = Context.BuiltinInfo.getName(Id);

Might as well hit this clang-format warning too.



Comment at: clang/test/AST/arithmetic-fence-builtin.c:34
+
+  v = (a + b);
+

Does the `(a + b)` still have an AST node for the `ParenExpr`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100118

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

[PATCH] D104388: [clang-format] PR50727 C# Invoke Lamda Expression indentation incorrect

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

ping


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

https://reviews.llvm.org/D104388

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

[PATCH] D104797: [WebAssembly] Implementation of global.get/set for reftypes in LLVM IR

[Paulo Matos via Phabricator via cfe-commits]

pmatos added a subscriber: reames.
pmatos added a comment.

Adding @reames to subscribers since he's the author of 
https://github.com/llvm/llvm-project/commit/ac81cb7e6dde9b0890ee1780eae94ab96743569b
 and might have something to add to the discussion.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104797

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

[PATCH] D104797: [WebAssembly] Implementation of global.get/set for reftypes in LLVM IR

[Paulo Matos via Phabricator via cfe-commits]

pmatos added a comment.

This patch would have fixed the problems with AArch64 caused by D95425 
. However, since that was landed and reverted, 
this landed: 
https://github.com/llvm/llvm-project/commit/ac81cb7e6dde9b0890ee1780eae94ab96743569b

This breaks the test `llvm/test/CodeGen/WebAssembly/externref-ptrtoint.ll` 
which was expected to fail. I still think that a `ptrtoint` on an `externref` 
value should fail, and yet since `ac81cb7e` allows `ptrtoint` on non-integral 
pointer types, the verifier is letting this test to go through and it crashes 
LLVM later on during some DAG node analysis.

@tlively Do you think it would be ok to re-add the code removed in `ac81cb7e` 
but only error if the pointer is to an **opaque** non-integral type?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104797

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

[PATCH] D103938: Diagnose -Wunused-value in constant evaluation context

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

I've given this some more thought, and I think it's only the "constant 
evaluated" check that we want to bypass in this case. It's common to use 
`sizeof` or `decltype` with a comma operator in order to put an expression in a 
SFINAE context, and I don't think we should warn on those cases. So I think we 
should still do the context check for `DiagIfReachable`, but only bail out for 
unevaluated contexts, not for constant-evaluated contexts. Does that seem 
reasonable?




Comment at: clang/test/SemaCXX/warn-unused-value.cpp:147
+  new double[false ? (1, 2) : 3]
+[false ? (1, 2) : 3]; // expected-warning {{expression result 
unused}}
+}

Please add a FIXME saying that we shouldn't diagnose the unreachable constant 
expression here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103938

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

[PATCH] D104790: [x86] fix mm*_undefined* intrinsics to use arbitrary frozen bit pattern

[Craig Topper via Phabricator via cfe-commits]

craig.topper added a comment.

In D104790#2836253 , @aqjune wrote:

> I couldn't find end-to-end tests for checking assembly generation.
> To check whether this is working ok, which tests should I write and how would 
> it look like?

There are tests like test/CodeGen/X86/avx-intrinsics-fast-isel.ll that are 
supposed to contain the IR the frontend generates. They mostly contain 
optimized IR, but then run fast-isel in the backend. I don't think all 
intrinsics are tested this way.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104790

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

[PATCH] D104797: [WebAssembly] Implementation of global.get/set for reftypes in LLVM IR

[Paulo Matos via Phabricator via cfe-commits]

pmatos created this revision.
pmatos added a reviewer: tlively.
Herald added subscribers: ecnelises, sunfish, hiraditya, jgravelle-google, 
sbc100, dschuff.
pmatos requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, aheejin.
Herald added projects: clang, LLVM.

Reland of 31859f896 
.

This change implements new DAG notes GLOBAL_GET/GLOBAL_SET, and
lowering methods for load and stores of reference types from IR
globals. Once the lowering creates the new nodes, tablegen pattern
matches those and converts them to Wasm global.get/set.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104797

Files:
  clang/lib/Basic/Targets/WebAssembly.cpp
  llvm/include/llvm/CodeGen/TargetLowering.h
  llvm/include/llvm/CodeGen/ValueTypes.h
  llvm/lib/CodeGen/CodeGenPrepare.cpp
  llvm/lib/CodeGen/MachineOperand.cpp
  llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
  llvm/lib/CodeGen/TargetLoweringBase.cpp
  llvm/lib/CodeGen/ValueTypes.cpp
  llvm/lib/Target/WebAssembly/Utils/WebAssemblyUtilities.cpp
  llvm/lib/Target/WebAssembly/Utils/WebAssemblyUtilities.h
  llvm/lib/Target/WebAssembly/WebAssemblyFastISel.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyISD.def
  llvm/lib/Target/WebAssembly/WebAssemblyISelDAGToDAG.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.h
  llvm/lib/Target/WebAssembly/WebAssemblyInstrTable.td
  llvm/lib/Target/WebAssembly/WebAssemblyMCInstLower.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp
  llvm/test/CodeGen/WebAssembly/externref-globalget.ll
  llvm/test/CodeGen/WebAssembly/externref-globalset.ll
  llvm/test/CodeGen/WebAssembly/externref-inttoptr.ll
  llvm/test/CodeGen/WebAssembly/externref-ptrtoint.ll
  llvm/test/CodeGen/WebAssembly/externref-ptrtoint.s
  llvm/test/CodeGen/WebAssembly/externref-undef.ll
  llvm/test/CodeGen/WebAssembly/externref-unsized-load.ll
  llvm/test/CodeGen/WebAssembly/externref-unsized-store.ll
  llvm/test/CodeGen/WebAssembly/funcref-call.ll
  llvm/test/CodeGen/WebAssembly/funcref-globalget.ll
  llvm/test/CodeGen/WebAssembly/funcref-globalset.ll

Index: llvm/test/CodeGen/WebAssembly/funcref-globalset.ll
===
--- /dev/null
+++ llvm/test/CodeGen/WebAssembly/funcref-globalset.ll
@@ -0,0 +1,20 @@
+; RUN: llc < %s --mtriple=wasm32-unknown-unknown -asm-verbose=false -mattr=+reference-types | FileCheck %s
+
+%func = type opaque
+%funcref = type %func addrspace(20)* ;; addrspace 20 is nonintegral
+
+@funcref_global = local_unnamed_addr addrspace(1) global %funcref undef
+
+define void @set_funcref_global(%funcref %g) {
+  ;; this generates a global.set of @funcref_global
+  store %funcref %g, %funcref addrspace(1)* @funcref_global
+  ret void
+}
+
+; CHECK-LABEL: set_funcref_global:
+; CHECK-NEXT: functype   set_funcref_global (funcref) -> ()
+; CHECK-NEXT: local.get  0
+; CHECK-NEXT: global.set funcref_global
+; CHECK-NEXT: end_function
+
+; CHECK: .globl funcref_global
Index: llvm/test/CodeGen/WebAssembly/funcref-globalget.ll
===
--- /dev/null
+++ llvm/test/CodeGen/WebAssembly/funcref-globalget.ll
@@ -0,0 +1,19 @@
+; RUN: llc < %s --mtriple=wasm32-unknown-unknown -asm-verbose=false -mattr=+reference-types | FileCheck %s
+
+%func = type opaque
+%funcref = type %func addrspace(20)* ;; addrspace 20 is nonintegral
+
+@funcref_global = local_unnamed_addr addrspace(1) global %funcref undef
+
+define %funcref @return_funcref_global() {
+  ;; this generates a global.get of @funcref_global
+  %ref = load %funcref, %funcref addrspace(1)* @funcref_global
+  ret %funcref %ref
+}
+
+; CHECK-LABEL: return_funcref_global:
+; CHECK-NEXT: .functype   return_funcref_global () -> (funcref)
+; CHECK-NEXT: global.get funcref_global
+; CHECK-NEXT: end_function
+
+; CHECK: .globl funcref_global
Index: llvm/test/CodeGen/WebAssembly/funcref-call.ll
===
--- /dev/null
+++ llvm/test/CodeGen/WebAssembly/funcref-call.ll
@@ -0,0 +1,23 @@
+; RUN: llc < %s --mtriple=wasm32-unknown-unknown -asm-verbose=false -mattr=+reference-types | FileCheck %s
+
+%func = type void ()
+%funcref = type %func addrspace(20)* ;; addrspace 20 is nonintegral
+
+define void @call_funcref(%funcref %ref) {
+  call addrspace(20) void %ref() 
+  ret void
+}
+
+; CHECK-LABEL: call_funcref:
+; CHECK-NEXT: functype   call_funcref (funcref) -> ()
+; CHECK-NEXT: i32.const 0
+; CHECK-NEXT: local.get 0
+; CHECK-NEXT: table.set __funcref_call_table
+; CHECK-NEXT: local.get 0
+; CHECK-NEXT: call_indirect __funcref_call_table, () -> ()
+; CHECK-NEXT: i32.const 0
+; CHECK-NEXT: ref.null func
+; CHECK-NEXT: table.set __funcref_call_table
+; CHECK-NEXT: end_function
+
+; CHECK: .tabletype __funcref_call_table, funcref
Index: 

[PATCH] D100118: [clang] Add support for new builtin __arithmetic_fence to control floating point optimization, and new clang option fprotect-parens

[Melanie Blower via Phabricator via cfe-commits]

mibintc marked 9 inline comments as done.
mibintc added a comment.

A couple inline replies to go along with the updated patch




Comment at: clang/include/clang/Driver/Options.td:1757
+  LangOpts<"ProtectParens">, DefaultFalse,
+  PosFlag Should this option also be exposed to clang-cl (should it be a `CoreOption`)?
I don't know the answer to this, do you have a recommendation? 



Comment at: clang/lib/Sema/SemaChecking.cpp:6427-6430
+if (const VectorType *VT = dyn_cast(ArgTy.getCanonicalType()))
+  return VT->getElementType().getTypePtr()->isFloatingType();
+if (const ComplexType *CT = 
dyn_cast(ArgTy.getCanonicalType()))
+  return CT->getElementType().getTypePtr()->isFloatingType();

aaron.ballman wrote:
> 
I found there was a boolean function, so i got rid of the lambda. 



Comment at: clang/lib/Sema/SemaCoroutine.cpp:294
 
-static Expr *buildBuiltinCall(Sema , SourceLocation Loc, Builtin::ID Id,
-  MultiExprArg CallArgs) {

I moved this function to public because another file is also using the same 
logic



Comment at: clang/lib/Sema/SemaExpr.cpp:4026
+  !E->isLValue() &&
+  (ExprTy->isFloatingType() || (ExprTy->isComplexType( {
+return BuildBuiltinCallExpr(R, Builtin::BI__arithmetic_fence, E);

aaron.ballman wrote:
> Do you have to worry about vector types here as well?
Oh yes, i didn't get this one. 



Comment at: clang/lib/Sema/SemaExpr.cpp:4027
+  (ExprTy->isFloatingType() || (ExprTy->isComplexType( {
+return BuildBuiltinCallExpr(R, Builtin::BI__arithmetic_fence, E);
+  }

aaron.ballman wrote:
> One worry I have about this is that the AST will be a bit mysterious for 
> people writing AST matchers. The source code will have parens in it, but the 
> AST will have a `ParenExpr` node or not only depending on the language 
> options. This may also cause problems for other parts of the code that are 
> checking for properly-parenthesized expressions (like && and || within the 
> same expression), so we should probably have a test case like:
> ```
> bool func(float f1, float f2, float f3) {
>   return (f1 == f2 && f1 == f3) || f2 == f3; // Should not warn here
> }
> ```
I added an AST test case 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100118

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

[PATCH] D103938: Diagnose -Wunused-value in constant evaluation context

[Yuanfang Chen via Phabricator via cfe-commits]

ychen added a comment.

ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103938

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

[PATCH] D100118: [clang] Add support for new builtin __arithmetic_fence to control floating point optimization, and new clang option fprotect-parens

[Melanie Blower via Phabricator via cfe-commits]

mibintc updated this revision to Diff 354009.
mibintc added a comment.

The patch I uploaded for review yesterday wasn't correct, not sure what 
happened.  This one looks better.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100118

Files:
  clang/docs/UsersManual.rst
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/TargetInfo.h
  clang/include/clang/Driver/Options.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ExprConstant.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaCoroutine.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/AST/arithmetic-fence-builtin.c
  clang/test/CodeGen/arithmetic-fence-builtin.c
  clang/test/Driver/clang_f_opts.c
  clang/test/Sema/arithmetic-fence-builtin.c

Index: clang/test/Sema/arithmetic-fence-builtin.c
===
--- /dev/null
+++ clang/test/Sema/arithmetic-fence-builtin.c
@@ -0,0 +1,48 @@
+// RUN: %clang_cc1 -triple i386-pc-linux-gnu -emit-llvm -o - -verify -x c++ %s
+// RUN: %clang_cc1 -triple ppc64le -DPPC -emit-llvm -o - -verify -x c++ %s
+// RUN: not %clang_cc1 -triple ppc64le -DPPC -emit-llvm -o - -x c++ %s \
+// RUN:-fprotect-parens 2>&1 | FileCheck -check-prefix=PPC %s
+#ifndef PPC
+int v;
+template  T addT(T a, T b) {
+  T *q = __arithmetic_fence();
+  // expected-error@-1 {{invalid operand of type 'float *' where floating, complex or a vector of such types is required}}
+  // expected-error@-2 {{invalid operand of type 'int *' where floating, complex or a vector of such types is required}}
+  return __arithmetic_fence(a + b);
+  // expected-error@-1 {{invalid operand of type 'int' where floating, complex or a vector of such types is required}}
+}
+int addit(int a, int b) {
+  float x, y;
+  typedef struct {
+int a, b;
+  } stype;
+  stype s;
+  s = __arithmetic_fence(s);// expected-error {{invalid operand of type 'stype' where floating, complex or a vector of such types is required}}
+  x = __arithmetic_fence(); // expected-error {{too few arguments to function call, expected 1, have 0}}
+  x = __arithmetic_fence(x, y); // expected-error {{too many arguments to function call, expected 1, have 2}}
+  // Complex is supported.
+  _Complex double cd, cd1;
+  cd = __arithmetic_fence(cd1);
+  // Vector is supported.
+  typedef float __v4hi __attribute__((__vector_size__(8)));
+  __v4hi vec1, vec2;
+  vec1 = __arithmetic_fence(vec2);
+
+  v = __arithmetic_fence(a + b); // expected-error {{invalid operand of type 'int' where floating, complex or a vector of such types is required}}
+  float f = addT(a, b);   // expected-note {{in instantiation of function template specialization 'addT' requested here}}
+  int i = addT(1, 2);   // expected-note {{in instantiation of function template specialization 'addT' requested here}}
+  constexpr float d = 1.0 + 2.0;
+  constexpr float c = __arithmetic_fence(1.0 + 2.0);
+  constexpr float e = __arithmetic_fence(d);
+  return 0;
+}
+bool func(float f1, float f2, float f3) {
+  return (f1 == f2 && f1 == f3) || f2 == f3; // Should not warn here
+}
+static_assert( __arithmetic_fence(1.0 + 2.0), "message" );
+#else
+float addit(float a, float b) {
+  return __arithmetic_fence(a+b); // expected-error {{builtin is not supported on this target}}
+}
+#endif
+//PPC: error: option '-fprotect-parens' cannot be specified on this target
Index: clang/test/Driver/clang_f_opts.c
===
--- clang/test/Driver/clang_f_opts.c
+++ clang/test/Driver/clang_f_opts.c
@@ -1,13 +1,14 @@
 // REQUIRES: clang-driver
 
 // RUN: %clang -### -S -fasm -fblocks -fbuiltin -fno-math-errno -fcommon -fpascal-strings -fno-blocks -fno-builtin -fmath-errno -fno-common -fno-pascal-strings -fblocks -fbuiltin -fmath-errno -fcommon -fpascal-strings -fsplit-stack %s 2>&1 | FileCheck -check-prefix=CHECK-OPTIONS1 %s
-// RUN: %clang -### -S -fasm -fblocks -fbuiltin -fno-math-errno -fcommon -fpascal-strings -fno-asm -fno-blocks -fno-builtin -fmath-errno -fno-common -fno-pascal-strings -fno-show-source-location -fshort-enums %s 2>&1 | FileCheck -check-prefix=CHECK-OPTIONS2 %s
+// RUN: %clang -### -S -fasm -fblocks -fbuiltin -fno-math-errno -fcommon -fpascal-strings -fno-asm -fno-blocks -fno-builtin -fmath-errno -fno-common -fno-pascal-strings -fno-show-source-location -fshort-enums -fprotect-parens %s 2>&1 | FileCheck -check-prefix=CHECK-OPTIONS2 %s
 
 // CHECK-OPTIONS1: -fsplit-stack
 // CHECK-OPTIONS1: -fgnu-keywords
 // CHECK-OPTIONS1: -fblocks
 // CHECK-OPTIONS1: -fpascal-strings
 
+// CHECK-OPTIONS2: -fprotect-parens
 // CHECK-OPTIONS2: -fmath-errno
 // CHECK-OPTIONS2: 

[PATCH] D103094: [analyzer] Implemented RangeSet::Factory::castTo function to perform promotions, truncations and conversions.

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov added a comment.

I'll update tommorow.




Comment at: clang/unittests/StaticAnalyzer/RangeSetTest.cpp:120
+
+  template  const llvm::APSInt (T X) {
+static llvm::APSInt Int = APSIntTy.getZeroValue();

vsavchenko wrote:
> Default to `BaseType`?
It's implicitly deduced. I think it is not necessary.



Comment at: clang/unittests/StaticAnalyzer/RangeSetTest.cpp:131
+  template 
+  RangeSet from(RawRangeSetT Init, APSIntType Ty = APSIntTy) {
 RangeSet RangeSet = F.getEmptySet();

vsavchenko wrote:
> Unused parameter?
Oh... :-)



Comment at: clang/unittests/StaticAnalyzer/RangeSetTest.cpp:721-799
+TYPED_TEST(RangeSetCastToNoopTest, RangeSetCastToNoopTest) {
+  // Just to reduce the verbosity.
+  using F = typename TypeParam::FromType; // From
+  using T = typename TypeParam::ToType;   // To
+
+  using TV = TestValues;
+  constexpr auto MIN = TV::MIN;

vsavchenko wrote:
> If loop and promotion share the same test case, why should we split them into 
> two groups?
Yes, the tests are identical but they use different `testing::Types` in the 
suites. Also I don't want to mix them to make problem localizing easier if 
occurs. But still  I haven't strong preferences on that.


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

https://reviews.llvm.org/D103094

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

[PATCH] D104777: PR50767: clear non-distinct debuginfo for function with nodebug definition after undecorated declaration

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D104777#2835965 , @dblaikie wrote:

> @aaron.ballman Do we have attributes/infrastructure for attributes that have 
> to be the same from their first declaration or at least from their first 
> call? I'm wondering if it might be simpler/better to require nodebug to be 
> provided earlier, rather than fixing it up after the fact like this.
>
> (for instance, requiring it to be attributed on the declaration would ensure 
> we don't create call_site descriptions for calls to nodebug functions - which 
> would save some debug info size)

We don't have any attributes that have to be the same "from their first call" 
that I'm aware of. But we do have attributes that need to be the same on all 
declarations. IIRC, the `section` and `code_seg` attributes both have to be 
specified on the initial declaration in some circumstances, and `[[noreturn]]` 
needs to be on the first declaration we see. We don't have any tablegen 
machinery to enforce this, the logic needs to be manually written. I think it'd 
live somewhere around `Sema::mergeDeclAttributes()` or 
`Sema::MergeFunctionDecl()` most likely.

Fixing up after the fact would be a bit strange though. A declaration is 
typically considered marked by an attribute from the point of declaration 
including the attribute onward, not backwards. e.g., 
https://godbolt.org/z/4E1Ya764n I won't say we *never* do this back 
propagation, but I would say it's a sign that the attribute is venturing into 
novel, perhaps dangerous territory. For example with this patch, an AST matcher 
won't see the `nodebug` attribute on the initial declaration of `t1()` and so 
it won't react to it the same way that codegen is being changed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104777

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

[PATCH] D104556: [InstrProfiling] Make CountersPtr in __profd_ relative

[Vedant Kumar via Phabricator via cfe-commits]

vsk added a comment.

A one-time exception to the .profraw compatibility policy sounds reasonable to 
me.

A little more context: llvm has historically rev'd the .profraw format with 
abandon to deliver performance/size improvements (as David & co. did with name 
compression) and new functionality (value profiling, continuous sync mode, 
...). That will keep happening. The freedom to rev the raw format comes from 
keeping it private between the profile reader library and the runtime. Some 
alternatives to hardcoding details of a particular version of the .profraw 
format were mentioned earlier in the thread: if the Linux PGO support can 
pursue one of these (or find some other solution), I think it will it prevent 
headaches down the road.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104556

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

[PATCH] D100118: [clang] Add support for new builtin __arithmetic_fence to control floating point optimization, and new clang option fprotect-parens

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D100118#2833864 , @mibintc wrote:

> This patch addresses almost all the review comments, not yet sure about 
> @aaron.ballman 's question about CoreOptions

FWIW, I'm fine addressing that comment in a follow-up. Also, it looks like the 
Clang changes didn't make it into the latest updated patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100118

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

[PATCH] D104729: [clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to allow diagnostics on target-unsupported options

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM, but you should land this only after we accept D100118 
 because it's only needed for that 
functionality.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104729

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