[PATCH] D97915: [Coroutines] Handle overaligned frame allocation

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added a comment.

In D97915#2835147 , @ychen wrote:

> In D97915#2832667 , @ChuanqiXu wrote:
>
>> In D97915#2832446 , @ychen wrote:
>>
>>> In D97915#2829581 , @ChuanqiXu 
>>> wrote:
>>>
 A remained question.

 - what's the semantics if user specified their allocation/deallocation 
 functions?

 Previously, we discussed for the ::operator new and ::operator delete. But 
 what would we do for user specified allocation/deallocation functions?
 It looks like we would treat them just like `::operator new`. And it makes 
 sense at the first glance. But the problem comes from that we judge whether
 or not to over allocate a frame by this condition:

   coro.align > align of new

 But if the user uses their new, it makes no sense to use the `align of 
 new` as the condition. On the other hand, if user specified their new 
 function and the 
 alignment requirement for their promise type, would it be better really 
 that the compiler do the extra transformation?

 May be we need to discuss with other guys who are more familiar with the 
 C++ standard to answer this.
>>>
>>> I think @rjmccall could answer these. My understanding is that 
>>> user-specified allocation/deallocation has the same semantics as their 
>>> standard library's counterparts. `align of new` (aka 
>>> __STDCPP_DEFAULT_NEW_ALIGNMENT__) should apply to both.
>>
>> Yeah, I just curious about the question and not sure about the answer yet. I 
>> agree with that it should be safe if we treat user-specified 
>> allocation/deallocation as ::operator new. Maybe I am a little bit of 
>> pedantry. I just not sure if the developer would be satisfied when they find 
>> we allocate padding space they didn't want when they offered a new/delete 
>> method. (Maybe I am too anxious).
>>
>> ---
>>
>> Another problem I find in this patch is that the introduction for `raw 
>> frame` makes the frame confusing. For example, the following codes is aim to 
>> calculate the size for the over allocated  frame:
>>
>>   %[[SIZE:.+]] = call i64 @llvm.coro.size.i64()
>>   %[[NEWSIZE:.+]] = add i64 %[[SIZE]], %[[PAD]]
>>   %[[MEM2:.+]] = call noalias nonnull i8* @_Znwm(i64 %[[NEWSIZE]])
>>
>> It makes sense only if `llvm.coro.size` stands for the size of 'true frame' 
>> (I am not sure what's the meaning for raw frame now. Let me use 'true frame' 
>> temporarily). But the document now says that '@llvm.coro.size' returns the 
>> size of the frame. It's confusing
>> I am not require to fix it by rename 'llvm.coro.size' or rephrase the 
>> document simply. I am thinking about the the semantics of coroutine 
>> intrinsics after we introduce the concept of 'raw frame'.
>
> These are great points. The semantics of some coroutine intrinsics needs a 
> little bit of tweaking otherwise they are confusing with the introduction of 
> `raw frame` (suggestions for alternative names are much appreciated) which I 
> defined in the updated patch (Coroutines.rst). Docs for `llvm.coro.size` 
> mentions `coroutine frame` which I've used verbatim in the docs for 
> `llvm.coro.raw.frame.ptr.*`.
> Using your diagram below: `raw frame` is  `| --- for align --- | --- true 
> frame --- |`. `Coroutine frame` is `| --- true frame --- |`. (BTW, 
> `llvm.coro.begin` docs are stale which I updated in the patch, please take a 
> look @ChuanqiXu @rjmccall @lxfind).

Thanks for clarifying. Let's solve the semantics problem first.
With the introduction about 'raw frame', I think it's necessary to introduce 
this concept in the section 'Switched-Resume Lowering' or even the section 
'Introduction' in the document. Add a section to tell the terminology is 
satisfied too.

Then why we defined both 'llvm.coro.raw.frame.ptr.offset' and 
'llvm.coro.raw.frame.ptr.addr' together? It looks like refer to the same value 
finally. It looks like 'llvm.coro.raw.frame.ptr.offset' are trying to solve the 
problem about memory leak. But I think we could use 
llvm.coro.raw.frame.ptr.addr directly instead of traversing the frame (Maybe we 
need to add an intrinsic `llvm.coro.raw.size`).  Then we can omit a field in 
the frame to save space.

Then I am a little confused for the design again, since we would treat the 
value for CoroBegin as the address of coroutine frame in the past and it looks 
like to be the raw frame now. Let me reconsider if it is OK.




Comment at: llvm/docs/Coroutines.rst:963
+
+The '``llvm.coro.align``' intrinsic returns the alignment of the coroutine 
frame
+in bytes.

> '``llvm.coro.align``'
`llvm.coro.align`



Comment at: llvm/docs/Coroutines.rst:1054
 
 The second argument is a pointer to a block of memory where coroutine frame
 will be stored if it is allocated dynamically.  This pointer is ignored

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

[Fraser Cormack via Phabricator via cfe-commits]

frasercrmck added a comment.

What's supposed to happen if the provided index is invalid? I'm suspecting we'd 
currently get a IR verification error on the insert/extract indices. I'm 
wondering if we can/should catch that earlier?


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] D69560: [clang-tidy] Add 'bugprone-easily-swappable-parameters' check

[Whisperity via Phabricator via cfe-commits]

whisperity updated this revision to Diff 354166.
whisperity added a comment.

Attempt to fix build failure on Windows buildbot (`operator new` was taking 
`unsigned long` instead of `size_t` in a test which resulted in hard error).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69560

Files:
  clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
  clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
  clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/docs/clang-tidy/checks/bugprone-easily-swappable-parameters.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-ignore.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len3.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters.c

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters.c
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters.c
@@ -0,0 +1,148 @@
+// RUN: %check_clang_tidy %s bugprone-easily-swappable-parameters %t \
+// RUN:   -config='{CheckOptions: [ \
+// RUN: {key: bugprone-easily-swappable-parameters.MinimumLength, value: 2}, \
+// RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterNames, value: ""}, \
+// RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterTypeSuffixes, value: "bool;MyBool;struct U;MAKE_LOGICAL_TYPE(int)"} \
+// RUN:  ]}' -- -x c
+
+#define bool _Bool
+#define true 1
+#define false 0
+
+typedef bool MyBool;
+
+#define TheLogicalType bool
+
+void declVoid(void); // NO-WARN: Declaration only.
+void decl(); // NO-WARN: Declaration only.
+void oneParam(int I) {}  // NO-WARN: 1 parameter.
+void variadic(int I, ...) {} // NO-WARN: 1 visible parameter.
+
+void trivial(int I, int J) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:14: warning: 2 adjacent parameters of 'trivial' of similar type ('int') are easily swapped by mistake [bugprone-easily-swappable-parameters]
+// CHECK-MESSAGES: :[[@LINE-2]]:18: note: the first parameter in the range is 'I'
+// CHECK-MESSAGES: :[[@LINE-3]]:25: note: the last parameter in the range is 'J'
+
+void qualifier(int I, const int CI) {} // NO-WARN: Distinct types.
+
+void restrictQualifier(char *restrict CPR1, char *restrict CPR2) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:24: warning: 2 adjacent parameters of 'restrictQualifier' of similar type ('char *restrict')
+// CHECK-MESSAGES: :[[@LINE-2]]:39: note: the first parameter in the range is 'CPR1'
+// CHECK-MESSAGES: :[[@LINE-3]]:60: note: the last parameter in the range is 'CPR2'
+
+void pointer1(int *IP1, int *IP2) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:15: warning: 2 adjacent parameters of 'pointer1' of similar type ('int *')
+// CHECK-MESSAGES: :[[@LINE-2]]:20: note: the first parameter in the range is 'IP1'
+// CHECK-MESSAGES: :[[@LINE-3]]:30: note: the last parameter in the range is 'IP2'
+
+void pointerConversion(int *IP, long *LP) {}
+// NO-WARN: Even though C can convert any T* to U* back and forth, compiler
+// warnings already exist for this.
+
+void testVariadicsCall() {
+  int IVal = 1;
+  decl(IVal); // NO-WARN: Particular calls to "variadics" are like template
+  // instantiations, and we do not model them.
+
+  variadic(IVal);  // NO-WARN.
+  variadic(IVal, 2, 3, 4); // NO-WARN.
+}
+
+struct S {};
+struct T {};
+
+void taggedTypes1(struct S SVar, struct T TVar) {} // NO-WARN: Distinct types.
+
+void taggedTypes2(struct S SVar1, struct S SVar2) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:19: warning: 2 adjacent parameters of 'taggedTypes2' of similar type ('struct S')
+// CHECK-MESSAGES: :[[@LINE-2]]:28: note: the first parameter in the range is 'SVar1'
+// CHECK-MESSAGES: :[[@LINE-3]]:44: note: the last parameter in the range is 'SVar2'
+
+void wrappers(struct { int I; } I1, struct { int I; } I2) {} // NO-WARN: Distinct anonymous types.
+
+void knr(I, J)
+  int I;
+  int J;
+{}
+// CHECK-MESSAGES: :[[@LINE-3]]:3: warning: 2 adjacent parameters of 'knr' of similar type ('int')
+// CHECK-MESSAGES: :[[@LINE-4]]:7: note: the first parameter in the range is 'I'
+// CHECK-MESSAGES: :[[@LINE-4]]:7: note: the last parameter in the range is 'J'
+
+void boolAsWritten(bool B1, bool B2) {} // NO-WARN: The type name is ignored.
+// Note that "bool" is a macro that expands to "_Bool" internally, but it is
+// only "bool" that is ignored from the two.
+
+void underscoreBoolAsWritten(_Bool B1, _Bool B2) {}
+// Even though it is "_Bool" that is written in the 

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

[Manas Gupta via Phabricator via cfe-commits]

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

Rebase


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,
+QualTyp

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

[Valeriy Savchenko via Phabricator via cfe-commits]

vsavchenko 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);

manas wrote:
> 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.
You can easily construct `APSInt` from `APInt` using `APSInt ::APSInt(APInt I, 
bool isUnsigned)` constructor.


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 marked an inline comment as not done.
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);

vsavchenko wrote:
> manas wrote:
> > 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.
> You can easily construct `APSInt` from `APInt` using `APSInt ::APSInt(APInt 
> I, bool isUnsigned)` constructor.
Okay. I will try with using `uadd_ov` only then. And check whether those tests 
pass or not.


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

[Valeriy Savchenko via Phabricator via cfe-commits]

vsavchenko 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);

manas wrote:
> vsavchenko wrote:
> > manas wrote:
> > > 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.
> > You can easily construct `APSInt` from `APInt` using `APSInt ::APSInt(APInt 
> > I, bool isUnsigned)` constructor.
> Okay. I will try with using `uadd_ov` only then. And check whether those 
> tests pass or not.
Hmm, why only `uadd_ov`?  What about those tests?  How do they fail?  Try to 
look at the reasons and not brute-force by trying different solutions blindly.
Those tests are your friends, it's much better to get failures right now then 
getting them later when you land the patch.


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

[clang] e76c008 - [analyzer] Added a test case for PR46264

[Denys Petrov via cfe-commits]

Author: Denys Petrov
Date: 2021-06-24T12:24:26+03:00
New Revision: e76c008c906af3dc093dd5c3ceaea577359b5432

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

LOG: [analyzer] Added a test case for PR46264

Summary: It's not able to reproduce the issue 
(https://bugs.llvm.org/show_bug.cgi?id=46264) for the latest sources. Add a 
reported test case to try to catch the problem if occur es.

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

Prevent: https://bugs.llvm.org/show_bug.cgi?id=46264

Added: 
clang/test/Analysis/diagnostics/PR46264.cpp

Modified: 


Removed: 




diff  --git a/clang/test/Analysis/diagnostics/PR46264.cpp 
b/clang/test/Analysis/diagnostics/PR46264.cpp
new file mode 100644
index 0..466dada694be9
--- /dev/null
+++ b/clang/test/Analysis/diagnostics/PR46264.cpp
@@ -0,0 +1,36 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core -analyzer-output=text 
-verify %s
+
+// PR46264
+// This case shall not crash with an assertion failure about void* 
dereferening.
+// The crash has been last seen on commit
+// `3ed8ebc2f6b8172bed48cc5986d3b7af4cfca1bc` from 24.05.2020.
+namespace ns1 {
+namespace a {
+class b {
+public:
+  typedef int b::*c;
+  operator c() { return d ? &b::d : 0; }
+  // expected-note@-1{{'?' condition is true}}
+  // expected-note@-2{{Assuming field 'd' is not equal to 0}}
+  // expected-note@-3{{Returning value, which participates in a condition 
later}}
+  int d;
+};
+} // namespace a
+using a::b;
+class e {
+  void f();
+  void g();
+  b h;
+};
+void e::f() {
+  e *i;
+  // expected-note@-1{{'i' declared without an initial value}}
+  if (h)
+// expected-note@-1{{Taking true branch}}
+// expected-note@-2{{'b::operator int ns1::a::b::*'}}
+// expected-note@-3{{Returning from 'b::operator int ns1::a::b::*'}}
+i->g();
+  // expected-note@-1{{Called C++ object pointer is uninitialized}}
+  // expected-warning@-2{{Called C++ object pointer is uninitialized}}
+}
+} // namespace ns1



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

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

[Denys Petrov 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 rGe76c008c906a: [analyzer] Added a test case for PR46264 
(authored by ASDenysPetrov).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104381

Files:
  clang/test/Analysis/diagnostics/PR46264.cpp


Index: clang/test/Analysis/diagnostics/PR46264.cpp
===
--- /dev/null
+++ clang/test/Analysis/diagnostics/PR46264.cpp
@@ -0,0 +1,36 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core -analyzer-output=text 
-verify %s
+
+// PR46264
+// This case shall not crash with an assertion failure about void* 
dereferening.
+// The crash has been last seen on commit
+// `3ed8ebc2f6b8172bed48cc5986d3b7af4cfca1bc` from 24.05.2020.
+namespace ns1 {
+namespace a {
+class b {
+public:
+  typedef int b::*c;
+  operator c() { return d ? &b::d : 0; }
+  // expected-note@-1{{'?' condition is true}}
+  // expected-note@-2{{Assuming field 'd' is not equal to 0}}
+  // expected-note@-3{{Returning value, which participates in a condition 
later}}
+  int d;
+};
+} // namespace a
+using a::b;
+class e {
+  void f();
+  void g();
+  b h;
+};
+void e::f() {
+  e *i;
+  // expected-note@-1{{'i' declared without an initial value}}
+  if (h)
+// expected-note@-1{{Taking true branch}}
+// expected-note@-2{{'b::operator int ns1::a::b::*'}}
+// expected-note@-3{{Returning from 'b::operator int ns1::a::b::*'}}
+i->g();
+  // expected-note@-1{{Called C++ object pointer is uninitialized}}
+  // expected-warning@-2{{Called C++ object pointer is uninitialized}}
+}
+} // namespace ns1


Index: clang/test/Analysis/diagnostics/PR46264.cpp
===
--- /dev/null
+++ clang/test/Analysis/diagnostics/PR46264.cpp
@@ -0,0 +1,36 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core -analyzer-output=text -verify %s
+
+// PR46264
+// This case shall not crash with an assertion failure about void* dereferening.
+// The crash has been last seen on commit
+// `3ed8ebc2f6b8172bed48cc5986d3b7af4cfca1bc` from 24.05.2020.
+namespace ns1 {
+namespace a {
+class b {
+public:
+  typedef int b::*c;
+  operator c() { return d ? &b::d : 0; }
+  // expected-note@-1{{'?' condition is true}}
+  // expected-note@-2{{Assuming field 'd' is not equal to 0}}
+  // expected-note@-3{{Returning value, which participates in a condition later}}
+  int d;
+};
+} // namespace a
+using a::b;
+class e {
+  void f();
+  void g();
+  b h;
+};
+void e::f() {
+  e *i;
+  // expected-note@-1{{'i' declared without an initial value}}
+  if (h)
+// expected-note@-1{{Taking true branch}}
+// expected-note@-2{{'b::operator int ns1::a::b::*'}}
+// expected-note@-3{{Returning from 'b::operator int ns1::a::b::*'}}
+i->g();
+  // expected-note@-1{{Called C++ object pointer is uninitialized}}
+  // expected-warning@-2{{Called C++ object pointer is uninitialized}}
+}
+} // namespace ns1
___
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 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);

vsavchenko wrote:
> manas wrote:
> > vsavchenko wrote:
> > > manas wrote:
> > > > 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.
> > > You can easily construct `APSInt` from `APInt` using `APSInt 
> > > ::APSInt(APInt I, bool isUnsigned)` constructor.
> > Okay. I will try with using `uadd_ov` only then. And check whether those 
> > tests pass or not.
> Hmm, why only `uadd_ov`?  What about those tests?  How do they fail?  Try to 
> look at the reasons and not brute-force by trying different solutions blindly.
> Those tests are your friends, it's much better to get failures right now then 
> getting them later when you land the patch.
I meant related functions as well.

Most of them were failing due to `Error evaluating statements`.  Although, I 
have rebased my tree so I will re-check again.


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] D103314: [Analyzer][solver] Simplify existing constraints when a new constraint is added

[Gabor Marton via Phabricator via cfe-commits]

martong added a comment.

In D103314#2837907 , @uabelho wrote:

> Hi,
>
> Another failed assertion that started appearing with this patch:
>
>   clang --analyze bbi-57589.c
>
> which results in:
>
>   clang: ../lib/Support/APInt.cpp:284: int llvm::APInt::compareSigned(const 
> llvm::APInt &) const: Assertion `BitWidth == RHS.BitWidth && "Bit widths must 
> be same for comparison"' failed.
>
> F17570813: bbi-57589.c 
> Maybe it's the same root problem, but please make sure you fix both.
> Thanks!

Thanks again Mikael for the report. I could find the root cause and I have a 
solution that solves the assertions (both test cases are fixed). I am going to 
upload the fix soon.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103314

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

[PATCH] D92024: [clang] Implement P0692R1 from C++20 (access checking on specializations and instantiations)

[Alex Orlov via Phabricator via cfe-commits]

aorlov added a comment.

Just a ping!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92024

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

[PATCH] D103314: [Analyzer][solver] Simplify existing constraints when a new constraint is added

[Valeriy Savchenko via Phabricator via cfe-commits]

vsavchenko added a comment.

In D103314#2838065 , @martong wrote:

> In D103314#2837907 , @uabelho wrote:
>
>> Hi,
>>
>> Another failed assertion that started appearing with this patch:
>>
>>   clang --analyze bbi-57589.c
>>
>> which results in:
>>
>>   clang: ../lib/Support/APInt.cpp:284: int llvm::APInt::compareSigned(const 
>> llvm::APInt &) const: Assertion `BitWidth == RHS.BitWidth && "Bit widths 
>> must be same for comparison"' failed.
>>
>> F17570813: bbi-57589.c 
>> Maybe it's the same root problem, but please make sure you fix both.
>> Thanks!
>
> Thanks again Mikael for the report. I could find the root cause and I have a 
> solution that solves the assertions (both test cases are fixed). I am going 
> to upload the fix soon.

Great!  Ping me when it's on review, I'll try to look into it ASAP!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103314

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

[PATCH] D104843: [clangd] Introduce a log-prefix flag to remote-index-server

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet created this revision.
kadircet added a reviewer: kbobyrev.
Herald added subscribers: usaxena95, arphaman.
kadircet requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang-tools-extra.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104843

Files:
  clang-tools-extra/clangd/index/remote/server/Server.cpp
  clang-tools-extra/clangd/test/remote-index/log-prefix.test

Index: clang-tools-extra/clangd/test/remote-index/log-prefix.test
===
--- /dev/null
+++ clang-tools-extra/clangd/test/remote-index/log-prefix.test
@@ -0,0 +1,18 @@
+# RUN: rm -rf %t
+# RUN: clangd-indexer %S/Inputs/Source.cpp > %t.idx
+# RUN: %python %S/pipeline_helper.py --input-file-name=%s --server-arg=--log=verbose --server-arg=-log-prefix=test-prefix --server-log=%t.log --project-root=%S --index-file=%t.idx > /dev/null
+# RUN: FileCheck %s < %t.log
+# REQUIRES: clangd-remote-index
+
+# CHECK: [test-prefix] Server listening on
+{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"processId":123,"rootPath":"clangd","capabilities":{},"trace":"off"}}
+---
+{"jsonrpc":"2.0","id":1,"method":"workspace/symbol","params":{"query":"gFoo"}}
+# CHECK: [test-prefix] <<< FuzzyFindRequest
+# CHECK: [test-prefix] >>> FuzzyFindReply
+# CHECK: [test-prefix] [public] request v1/FuzzyFind
+---
+{"jsonrpc":"2.0","id":4,"method":"shutdown"}
+---
+{"jsonrpc":"2.0","method":"exit"}
+
Index: clang-tools-extra/clangd/index/remote/server/Server.cpp
===
--- clang-tools-extra/clangd/index/remote/server/Server.cpp
+++ clang-tools-extra/clangd/index/remote/server/Server.cpp
@@ -37,7 +37,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 #if ENABLE_GRPC_REFLECTION
 #include 
@@ -74,6 +76,12 @@
 llvm::cl::init(false),
 };
 
+llvm::cl::opt LogPrefix{
+"log-prefix",
+llvm::cl::desc("A string that'll be prepended to all log statements. "
+   "Useful when running multiple instances on same host."),
+};
+
 llvm::cl::opt TraceFile(
 "trace-file",
 llvm::cl::desc("Path to the file where tracer logs will be stored"));
@@ -410,27 +418,48 @@
   ServerShutdownWatcher.join();
 }
 
-std::unique_ptr makeLogger(llvm::raw_ostream &OS) {
-  if (!LogPublic)
-return std::make_unique(OS, LogLevel);
-  // Redacted mode:
-  //  - messages outside the scope of a request: log fully
-  //  - messages tagged [public]: log fully
-  //  - errors: log the format string
-  //  - others: drop
-  class RedactedLogger : public StreamLogger {
+std::unique_ptr makeLogger(llvm::StringRef LogPrefix,
+   llvm::raw_ostream &OS) {
+  std::unique_ptr Base;
+  if (LogPublic) {
+// Redacted mode:
+//  - messages outside the scope of a request: log fully
+//  - messages tagged [public]: log fully
+//  - errors: log the format string
+//  - others: drop
+class RedactedLogger : public StreamLogger {
+public:
+  using StreamLogger::StreamLogger;
+  void log(Level L, const char *Fmt,
+   const llvm::formatv_object_base &Message) override {
+if (Context::current().get(CurrentRequest) == nullptr ||
+llvm::StringRef(Fmt).startswith("[public]"))
+  return StreamLogger::log(L, Fmt, Message);
+if (L >= Error)
+  return StreamLogger::log(L, Fmt,
+   llvm::formatv("[redacted] {0}", Fmt));
+  }
+};
+Base = std::make_unique(OS, LogLevel);
+  } else {
+Base = std::make_unique(OS, LogLevel);
+  }
+
+  if (LogPrefix.empty())
+return Base;
+  class PrefixedLogger : public Logger {
+std::string LogPrefix;
+std::unique_ptr Base;
+
   public:
-using StreamLogger::StreamLogger;
+PrefixedLogger(llvm::StringRef LogPrefix, std::unique_ptr Base)
+: LogPrefix(LogPrefix.str()), Base(std::move(Base)) {}
 void log(Level L, const char *Fmt,
  const llvm::formatv_object_base &Message) override {
-  if (Context::current().get(CurrentRequest) == nullptr ||
-  llvm::StringRef(Fmt).startswith("[public]"))
-return StreamLogger::log(L, Fmt, Message);
-  if (L >= Error)
-return StreamLogger::log(L, Fmt, llvm::formatv("[redacted] {0}", Fmt));
+  Base->log(L, Fmt, llvm::formatv("[{0}] {1}", LogPrefix, Message));
 }
   };
-  return std::make_unique(OS, LogLevel);
+  return std::make_unique(LogPrefix, std::move(Base));
 }
 
 } // namespace
@@ -454,7 +483,7 @@
   llvm::errs().SetBuffered();
   // Don't flush stdout when logging for thread safety.
   llvm::errs().tie(nullptr);
-  auto Logger = makeLogger(llvm::errs());
+  auto Logger = makeLogger(LogPrefix.getValue(), llvm::errs());
   clang::clangd::LoggingSession LoggingSession(*Logger);
 
   llvm::Optional TracerStream;
___

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

[Valeriy Savchenko via Phabricator via cfe-commits]

vsavchenko 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);

manas wrote:
> vsavchenko wrote:
> > manas wrote:
> > > vsavchenko wrote:
> > > > manas wrote:
> > > > > 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.
> > > > You can easily construct `APSInt` from `APInt` using `APSInt 
> > > > ::APSInt(APInt I, bool isUnsigned)` constructor.
> > > Okay. I will try with using `uadd_ov` only then. And check whether those 
> > > tests pass or not.
> > Hmm, why only `uadd_ov`?  What about those tests?  How do they fail?  Try 
> > to look at the reasons and not brute-force by trying different solutions 
> > blindly.
> > Those tests are your friends, it's much better to get failures right now 
> > then getting them later when you land the patch.
> I meant related functions as well.
> 
> Most of them were failing due to `Error evaluating statements`.  Although, I 
> have rebased my tree so I will re-check again.
`Error evaluating statements` just tells you when we crashed (for the context 
and fast insight).
Below this message is usually the real reason (and the last time I checked, it 
was assertion `From > To` failure).


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] D75041: [clang-tidy] Extend 'bugprone-easily-swappable-parameters' with mixability because of implicit conversions

[Whisperity via Phabricator via cfe-commits]

whisperity updated this revision to Diff 354180.
whisperity added a comment.

(Uploaded the prerequisite, wrong patch here by accident.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75041

Files:
  clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.h
  
clang-tools-extra/docs/clang-tidy/checks/bugprone-easily-swappable-parameters.rst
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-ignore.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-implicit-qualifiers.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-implicits.c
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-implicits.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len3.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-qualifiermixing.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters.c

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters.c
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters.c
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters.c
@@ -3,7 +3,8 @@
 // RUN: {key: bugprone-easily-swappable-parameters.MinimumLength, value: 2}, \
 // RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterNames, value: ""}, \
 // RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterTypeSuffixes, value: "bool;MyBool;struct U;MAKE_LOGICAL_TYPE(int)"}, \
-// RUN: {key: bugprone-easily-swappable-parameters.QualifiersMix, value: 0} \
+// RUN: {key: bugprone-easily-swappable-parameters.QualifiersMix, value: 0}, \
+// RUN: {key: bugprone-easily-swappable-parameters.ModelImplicitConversions, value: 0} \
 // RUN:  ]}' -- -x c
 
 #define bool _Bool
Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-qualifiermixing.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-qualifiermixing.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-qualifiermixing.cpp
@@ -3,7 +3,8 @@
 // RUN: {key: bugprone-easily-swappable-parameters.MinimumLength, value: 2}, \
 // RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterNames, value: ""}, \
 // RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterTypeSuffixes, value: ""}, \
-// RUN: {key: bugprone-easily-swappable-parameters.QualifiersMix, value: 1} \
+// RUN: {key: bugprone-easily-swappable-parameters.QualifiersMix, value: 1}, \
+// RUN: {key: bugprone-easily-swappable-parameters.ModelImplicitConversions, value: 0} \
 // RUN:  ]}' --
 
 typedef int MyInt1;
Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len3.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len3.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len3.cpp
@@ -3,7 +3,8 @@
 // RUN: {key: bugprone-easily-swappable-parameters.MinimumLength, value: 3}, \
 // RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterNames, value: ""}, \
 // RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterTypeSuffixes, value: ""}, \
-// RUN: {key: bugprone-easily-swappable-parameters.QualifiersMix, value: 0} \
+// RUN: {key: bugprone-easily-swappable-parameters.QualifiersMix, value: 0}, \
+// RUN: {key: bugprone-easily-swappable-parameters.ModelImplicitConversions, value: 0} \
 // RUN:  ]}' --
 
 int add(int Left, int Right) { return Left + Right; } // NO-WARN: Only 2 parameters.
Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp
@@ -3,7 +3,8 @@
 // RUN: {key: bugprone-easily-swappable-parameters.MinimumLength, value: 2}, \
 // RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterNames, value: ""}, \
 // RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterTypeSuffixes, value: ""}, \
-// RUN: {key: bugprone-easily-swappable-parameters.QualifiersMix, value: 0} \
+// RUN: {key: bugprone-easily

[PATCH] D95736: [clang-tidy] Extend 'bugprone-easily-swappable-parameters' with `typedef` and `const &` diagnostics

[Whisperity via Phabricator via cfe-commits]

whisperity updated this revision to Diff 354183.
whisperity added a comment.

**NFC** Fix lint.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95736

Files:
  clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp
  
clang-tools-extra/docs/clang-tidy/checks/bugprone-easily-swappable-parameters.rst
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp
@@ -115,20 +115,38 @@
 // CHECK-MESSAGES: :[[@LINE-2]]:32: note: the first parameter in the range is 'I1'
 // CHECK-MESSAGES: :[[@LINE-3]]:43: note: the last parameter in the range is 'I2'
 
-void throughTypedef(int I, MyInt1 J) {}
-// CHECK-MESSAGES: :[[@LINE-1]]:21: warning: 2 adjacent parameters of 'throughTypedef' of similar type ('int')
-// CHECK-MESSAGES: :[[@LINE-2]]:25: note: the first parameter in the range is 'I'
-// CHECK-MESSAGES: :[[@LINE-3]]:35: note: the last parameter in the range is 'J'
+void typedefMultiple(MyInt1 I1, MyInt2 I2x, MyInt2 I2y) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:22: warning: 3 adjacent parameters of 'typedefMultiple' of similar type are
+// CHECK-MESSAGES: :[[@LINE-2]]:29: note: the first parameter in the range is 'I1'
+// CHECK-MESSAGES: :[[@LINE-3]]:52: note: the last parameter in the range is 'I2y'
+// CHECK-MESSAGES: :[[@LINE-4]]:22: note: after resolving type aliases, the common type of 'MyInt1' and 'MyInt2' is 'int'
+
+void throughTypedef1(int I, MyInt1 J) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:22: warning: 2 adjacent parameters of 'throughTypedef1' of similar type are
+// CHECK-MESSAGES: :[[@LINE-2]]:26: note: the first parameter in the range is 'I'
+// CHECK-MESSAGES: :[[@LINE-3]]:36: note: the last parameter in the range is 'J'
+// CHECK-MESSAGES: :[[@LINE-4]]:22: note: after resolving type aliases, 'int' and 'MyInt1' are the same
+
+void betweenTypedef2(MyInt1 I, MyInt2 J) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:22: warning: 2 adjacent parameters of 'betweenTypedef2' of similar type are
+// CHECK-MESSAGES: :[[@LINE-2]]:29: note: the first parameter in the range is 'I'
+// CHECK-MESSAGES: :[[@LINE-3]]:39: note: the last parameter in the range is 'J'
+// CHECK-MESSAGES: :[[@LINE-4]]:22: note: after resolving type aliases, the common type of 'MyInt1' and 'MyInt2' is 'int'
+
+typedef MyInt2 MyInt2b;
 
-void betweenTypedef(MyInt1 I, MyInt2 J) {}
-// CHECK-MESSAGES: :[[@LINE-1]]:21: warning: 2 adjacent parameters of 'betweenTypedef' of similar type ('MyInt1')
-// CHECK-MESSAGES: :[[@LINE-2]]:28: note: the first parameter in the range is 'I'
-// CHECK-MESSAGES: :[[@LINE-3]]:38: note: the last parameter in the range is 'J'
+void typedefChain(int I, MyInt1 MI1, MyInt2 MI2, MyInt2b MI2b) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:19: warning: 4 adjacent parameters of 'typedefChain' of similar type are
+// CHECK-MESSAGES: :[[@LINE-2]]:23: note: the first parameter in the range is 'I'
+// CHECK-MESSAGES: :[[@LINE-3]]:58: note: the last parameter in the range is 'MI2b'
+// CHECK-MESSAGES: :[[@LINE-4]]:19: note: after resolving type aliases, 'int' and 'MyInt1' are the same
+// CHECK-MESSAGES: :[[@LINE-5]]:19: note: after resolving type aliases, 'int' and 'MyInt2' are the same
+// CHECK-MESSAGES: :[[@LINE-6]]:19: note: after resolving type aliases, 'int' and 'MyInt2b' are the same
 
 typedef long MyLong1;
 using MyLong2 = long;
 
-void throughTypedefToOtherType(MyInt1 I, MyLong1 J) {} // NO-WARN: Not the same type.
+void throughTypedefToOtherType(MyInt1 I, MyLong1 J) {} // NO-WARN: int and long.
 
 void qualified1(int I, const int CI) {} // NO-WARN: Not the same type.
 
@@ -142,18 +160,73 @@
 
 void qualifiedThroughTypedef1(int I, CInt CI) {} // NO-WARN: Not the same type.
 
-void qualifiedThroughTypedef2(CInt CI1, const int CI2) {} // NO-WARN: Not the same type.
-// CHECK-MESSAGES: :[[@LINE-1]]:31: warning: 2 adjacent parameters of 'qualifiedThroughTypedef2' of similar type ('CInt')
+void qualifiedThroughTypedef2(CInt CI1, const int CI2) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:31: warning: 2 adjacent parameters of 'qualifiedThroughTypedef2' of similar type are
 // CHECK-MESSAGES: :[[@LINE-2]]:36: note: the first parameter in the range is 'CI1'
 // CHECK-MESSAGES: :[[@LINE-3]]:51: note: the last parameter in the range is 'CI2'
-
-void reference1(int I, int &IR) {} // NO-WARN: Not the same type.
-
-void reference2(int I, const int &CIR) {} // NO-WARN: Not the same type.
-
-void reference3(int I, int &&IRR) {} // NO-WARN: Not the same type.
-
-void reference4(int I, const int &&CIRR) {} // NO-WARN: Not the same type.
+// CHECK-MESSAGES: :[[@LINE-4]]:31: note: after res

[PATCH] D104844: [Analyzer][solver] Fix crashes during symbol simplification

[Gabor Marton via Phabricator via cfe-commits]

martong created this revision.
martong added reviewers: vsavchenko, steakhal.
Herald added subscribers: manas, ASDenysPetrov, gamesh411, dkrupp, donat.nagy, 
Szelethus, mikhail.ramalho, a.sidorin, rnkovacs, szepet, baloghadamsoftware, 
xazax.hun, whisperity.
Herald added a reviewer: Szelethus.
martong requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Consider the code

  void f(int a0, int b0, int c)
  {
  int a1 = a0 - b0;
  int b1 = (unsigned)a1 + c;
  if (c == 0) {
  int d = 7L / b1;
  }
  }

At the point of divisiion by `b1` that is considered to be non-zero,
which results in a new constraint for `$a0 - $b0 + $c`. The type
of this sym is unsigned, however, the simplified sym is `$a0 -
$b0` and its type is signed. This is probably the result of the
inherent improper handling of casts. Anyway, Range assignment
for constraints use this type information. Therefore, we must
make sure that first we simplify the symbol and only then we
assign the range.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104844

Files:
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  clang/test/Analysis/solver-sym-simplification-no-crash.c
  clang/test/Analysis/solver-sym-simplification-with-proper-range-type.c

Index: clang/test/Analysis/solver-sym-simplification-with-proper-range-type.c
===
--- /dev/null
+++ clang/test/Analysis/solver-sym-simplification-with-proper-range-type.c
@@ -0,0 +1,29 @@
+// RUN: %clang_analyze_cc1 %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=debug.ExprInspection \
+// RUN:   -verify
+
+// Here we test that the range based solver equivalency tracking mechanism
+// assigns a properly typed range to the simplified symbol.
+
+void clang_analyzer_printState();
+void clang_analyzer_eval(int);
+
+void f(int a0, int b0, int c)
+{
+int a1 = a0 - b0;
+int b1 = (unsigned)a1 + c;
+if (c == 0) {
+
+int d = 7L / b1; // ...
+// At this point b1 is considered non-zero, which results in a new
+// constraint for $a0 - $b0 + $c. The type of this sym is unsigned,
+// however, the simplified sym is $a0 - $b0 and its type is signed.
+// This is probably the result of the inherent improper handling of
+// casts. Anyway, Range assignment for constraints use this type
+// information. Therefore, we must make sure that first we simplify the
+// symbol and only then we assign the range.
+
+clang_analyzer_eval(a0 - b0 != 0); // expected-warning{{TRUE}}
+}
+}
Index: clang/test/Analysis/solver-sym-simplification-no-crash.c
===
--- /dev/null
+++ clang/test/Analysis/solver-sym-simplification-no-crash.c
@@ -0,0 +1,26 @@
+// RUN: %clang_analyze_cc1 %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=debug.ExprInspection \
+// RUN:   -verify
+
+// Here, we test that symbol simplification in the solver does not produce any
+// crashes.
+
+// expected-no-diagnostics
+
+static int a, b;
+static long c;
+
+static void f(int i, int j)
+{
+(void)(j <= 0 && i ? i : j);
+}
+
+static void g(void)
+{
+int d = a - b | (c < 0);
+for (;;)
+{
+f(d ^ c, c);
+}
+}
Index: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -1519,9 +1519,6 @@
   // This is an infeasible assumption.
   return nullptr;
 
-if (SymbolRef SimplifiedSym = simplify(State, Sym))
-  Sym = SimplifiedSym;
-
 if (ProgramStateRef NewState = setConstraint(State, Sym, NewConstraint)) {
   if (auto Equality = EqualityInfo::extract(Sym, Int, Adjustment)) {
 // If the original assumption is not Sym + Adjustment !=/ Int,
@@ -2314,6 +2311,9 @@
 
   llvm::APSInt Point = AdjustmentType.convert(Int) - Adjustment;
 
+  if (SymbolRef SimplifiedSym = simplify(St, Sym))
+Sym = SimplifiedSym;
+
   RangeSet New = getRange(St, Sym);
   New = F.deletePoint(New, Point);
 
@@ -2331,6 +2331,10 @@
 
   // [Int-Adjustment, Int-Adjustment]
   llvm::APSInt AdjInt = AdjustmentType.convert(Int) - Adjustment;
+
+  if (SymbolRef SimplifiedSym = simplify(St, Sym))
+Sym = SimplifiedSym;
+
   RangeSet New = getRange(St, Sym);
   New = F.intersect(New, AdjInt);
 
@@ -2370,6 +2374,8 @@
 RangeConstraintManager::assumeSymLT(ProgramStateRef St, SymbolRef Sym,
 const llvm::APSInt &Int,
 const llvm::APSInt &Adjustment) {
+  if (SymbolRef SimplifiedSym = simplify(St, Sym))
+Sym = SimplifiedSym;
   RangeSet New = getSymLTRange(St, Sym, Int, Adjustment);
   return trackNE(New, St, Sym, Int, Adjustment);
 }
@@ -2407,6 +2413,8 @

[PATCH] D103314: [Analyzer][solver] Simplify existing constraints when a new constraint is added

[Gabor Marton via Phabricator via cfe-commits]

martong added a comment.

In D103314#2838065 , @martong wrote:

> In D103314#2837907 , @uabelho wrote:
>
>> Hi,
>>
>> Another failed assertion that started appearing with this patch:
>>
>>   clang --analyze bbi-57589.c
>>
>> which results in:
>>
>>   clang: ../lib/Support/APInt.cpp:284: int llvm::APInt::compareSigned(const 
>> llvm::APInt &) const: Assertion `BitWidth == RHS.BitWidth && "Bit widths 
>> must be same for comparison"' failed.
>>
>> F17570813: bbi-57589.c 
>> Maybe it's the same root problem, but please make sure you fix both.
>> Thanks!
>
> Thanks again Mikael for the report. I could find the root cause and I have a 
> solution that solves the assertions (both test cases are fixed). I am going 
> to upload the fix soon.

Here it is: https://reviews.llvm.org/D104844


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103314

___
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 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);

vsavchenko wrote:
> manas wrote:
> > vsavchenko wrote:
> > > manas wrote:
> > > > vsavchenko wrote:
> > > > > manas wrote:
> > > > > > 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.
> > > > > You can easily construct `APSInt` from `APInt` using `APSInt 
> > > > > ::APSInt(APInt I, bool isUnsigned)` constructor.
> > > > Okay. I will try with using `uadd_ov` only then. And check whether 
> > > > those tests pass or not.
> > > Hmm, why only `uadd_ov`?  What about those tests?  How do they fail?  Try 
> > > to look at the reasons and not brute-force by trying different solutions 
> > > blindly.
> > > Those tests are your friends, it's much better to get failures right now 
> > > then getting them later when you land the patch.
> > I meant related functions as well.
> > 
> > Most of them were failing due to `Error evaluating statements`.  Although, 
> > I have rebased my tree so I will re-check again.
> `Error evaluating statements` just tells you when we crashed (for the context 
> and fast insight).
> Below this message is usually the real reason (and the last time I checked, 
> it was assertion `From > To` failure).
My bad. I took a look and found, it was signed mismatch!


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] D89649: Fix __has_unique_object_representations with no_unique_address

[Whisperity via Phabricator via cfe-commits]

whisperity added a comment.

//Gentle boop.// Bugzilla is offline for me right now (and rumour has it that 
it will be completely shut down in the near future), so it would be good to 
know what is the status of this patch and how it related to the mentioned (and 
//right now// unavailable) bug report, as it is also blocking a Clang-Tidy 
check.


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

https://reviews.llvm.org/D89649

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

[PATCH] D96355: [clang-tidy] Extend 'bugprone-easily-swappable-parameters' with optionally considering differently qualified types mixable

[Whisperity via Phabricator via cfe-commits]

whisperity updated this revision to Diff 354192.
whisperity added a comment.

**NC!** Recreate diff to try and get the buildbots running...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96355

Files:
  clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.h
  
clang-tools-extra/docs/clang-tidy/checks/bugprone-easily-swappable-parameters.rst
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-ignore.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len3.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-qualifiermixing.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters.c

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters.c
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters.c
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters.c
@@ -2,7 +2,8 @@
 // RUN:   -config='{CheckOptions: [ \
 // RUN: {key: bugprone-easily-swappable-parameters.MinimumLength, value: 2}, \
 // RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterNames, value: ""}, \
-// RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterTypeSuffixes, value: "bool;MyBool;struct U;MAKE_LOGICAL_TYPE(int)"} \
+// RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterTypeSuffixes, value: "bool;MyBool;struct U;MAKE_LOGICAL_TYPE(int)"}, \
+// RUN: {key: bugprone-easily-swappable-parameters.QualifiersMix, value: 0} \
 // RUN:  ]}' -- -x c
 
 #define bool _Bool
Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-qualifiermixing.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-qualifiermixing.cpp
@@ -0,0 +1,112 @@
+// RUN: %check_clang_tidy %s bugprone-easily-swappable-parameters %t \
+// RUN:   -config='{CheckOptions: [ \
+// RUN: {key: bugprone-easily-swappable-parameters.MinimumLength, value: 2}, \
+// RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterNames, value: ""}, \
+// RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterTypeSuffixes, value: ""}, \
+// RUN: {key: bugprone-easily-swappable-parameters.QualifiersMix, value: 1} \
+// RUN:  ]}' --
+
+typedef int MyInt1;
+typedef int MyInt2;
+using CInt = const int;
+using CMyInt1 = const MyInt1;
+using CMyInt2 = const MyInt2;
+
+void qualified1(int I, const int CI) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:17: warning: 2 adjacent parameters of 'qualified1' of similar type are easily swapped by mistake [bugprone-easily-swappable-parameters]
+// CHECK-MESSAGES: :[[@LINE-2]]:21: note: the first parameter in the range is 'I'
+// CHECK-MESSAGES: :[[@LINE-3]]:34: note: the last parameter in the range is 'CI'
+// CHECK-MESSAGES: :[[@LINE-4]]:24: note: 'int' and 'const int' parameters accept and bind the same kind of values
+
+void qualified2(int I, volatile int VI) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:17: warning: 2 adjacent parameters of 'qualified2' of similar type are
+// CHECK-MESSAGES: :[[@LINE-2]]:21: note: the first parameter in the range is 'I'
+// CHECK-MESSAGES: :[[@LINE-3]]:37: note: the last parameter in the range is 'VI'
+// CHECK-MESSAGES: :[[@LINE-4]]:24: note: 'int' and 'volatile int' parameters accept and bind the same kind of values
+
+void qualified3(int I, const volatile int CVI) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:17: warning: 2 adjacent parameters of 'qualified3' of similar type are
+// CHECK-MESSAGES: :[[@LINE-2]]:21: note: the first parameter in the range is 'I'
+// CHECK-MESSAGES: :[[@LINE-3]]:43: note: the last parameter in the range is 'CVI'
+// CHECK-MESSAGES: :[[@LINE-4]]:24: note: 'int' and 'const volatile int' parameters accept and bind the same kind of values
+
+void qualified4(int *IP, const int *CIP) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:17: warning: 2 adjacent parameters of 'qualified4' of similar type are
+// CHECK-MESSAGES: :[[@LINE-2]]:22: note: the first parameter in the range is 'IP'
+// CHECK-MESSAGES: :[[@LINE-3]]:37: note: the last parameter in the range is 'CIP'
+// CHECK-MESSAGES: :[[@LINE-4]]:26: note: 'int *' and 'const int *' parameters accept and bind the same kind of values
+
+void qualified5(const int CI, const long CL) {} // NO-WARN: Not the same type
+
+void qualifiedPtr1(int *IP, int *const IPC) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:20: warning: 2 adjacent parameters of 'qualifiedPtr1' of similar type are
+// CHECK-MESSAGES: :[[@LINE-2]]:25: note: the first p

[PATCH] D92024: [clang] Implement P0692R1 from C++20 (access checking on specializations and instantiations)

[Alex Orlov via Phabricator via cfe-commits]

aorlov updated this revision to Diff 354193.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92024

Files:
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Parse/ParseTemplate.cpp
  clang/test/CXX/class.access/class.friend/p1.cpp
  clang/test/CXX/drs/dr1xx.cpp
  clang/test/CXX/temp/temp.spec/func.spec.cpp
  clang/test/CXX/temp/temp.spec/part.spec.cpp
  clang/test/CXX/temp/temp.spec/temp.explicit/p11.cpp
  clang/test/CXX/temp/temp.spec/temp.explicit/p12.cpp

Index: clang/test/CXX/temp/temp.spec/temp.explicit/p12.cpp
===
--- clang/test/CXX/temp/temp.spec/temp.explicit/p12.cpp
+++ clang/test/CXX/temp/temp.spec/temp.explicit/p12.cpp
@@ -43,7 +43,14 @@
 Temp(int x) {}
   };
 
-  template <> class Temp Temp::make() { // expected-error {{'Private' is a private member of 'test2::A'}}
+  template <> class Temp Temp::make() {
 return Temp(0);
   }
+
+  template <>
+  class Temp {
+static Temp make() { // expected-error {{is a private member}}
+  return Temp(0);
+}
+  };
 }
Index: clang/test/CXX/temp/temp.spec/temp.explicit/p11.cpp
===
--- clang/test/CXX/temp/temp.spec/temp.explicit/p11.cpp
+++ /dev/null
@@ -1,19 +0,0 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s
-// expected-no-diagnostics
-
-class X {
-  template  class Y {};
-};
-
-class A {
-  class B {};
-  class C {};
-};
-
-// C++0x [temp.explicit] 14.7.2/11:
-//   The usual access checking rules do not apply to names used to specify
-//   explicit instantiations.
-template class X::Y;
-
-// As an extension, this rule is applied to explicit specializations as well.
-template <> class X::Y {};
Index: clang/test/CXX/temp/temp.spec/part.spec.cpp
===
--- /dev/null
+++ clang/test/CXX/temp/temp.spec/part.spec.cpp
@@ -0,0 +1,481 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+// C++20 [temp.class.spec] 13.7.5/10
+//   The usual access checking rules do not apply to non-dependent names
+//   used to specify template arguments of the simple-template-id of the
+//   partial specialization.
+//
+// C++20 [temp.spec] 13.9/6:
+//   The usual access checking rules do not apply to names in a declaration
+//   of an explicit instantiation or explicit specialization...
+
+// TODO: add test cases for `enum`
+
+// class for tests
+class TestClass {
+public:
+  class PublicClass {};
+  template  class TemplatePublicClass {};
+
+  using AliasPublicClass = unsigned char;
+
+  void publicFunc();
+  void publicFuncOverloaded();
+  void publicFuncOverloaded(int);
+
+  static void publicStaticFunc();
+  static void publicStaticFuncOverloaded();
+  static void publicStaticFuncOverloaded(int);
+
+  static constexpr int publicStaticInt = 42;
+
+protected:
+  // expected-note@+1 8{{declared protected here}}
+  class ProtectedClass {};
+  template  class TemplateProtectedClass {};
+
+  // expected-note@+1 2{{declared protected here}}
+  using AliasProtectedClass = const char;
+
+  // expected-note@+1 3{{declared protected here}}
+  void protectedFunc();
+  void protectedFuncOverloaded();
+  void protectedFuncOverloaded(int);
+
+  // expected-note@+1 2{{declared protected here}}
+  static void protectedStaticFunc();
+  // expected-note@+1 2{{declared protected here}}
+  static void protectedStaticFuncOverloaded();
+  static void protectedStaticFuncOverloaded(int);
+
+  // expected-note@+1 2{{declared protected here}}
+  static constexpr int protectedStaticInt = 43;
+
+private:
+  // expected-note@+1 10{{declared private here}}
+  class PrivateClass {};
+  // expected-note@+1 {{declared private here}}
+  template  class TemplatePrivateClass {};
+
+  using AliasPrivateClass = char *;
+
+  void privateFunc();
+  void privateFuncOverloaded();
+  void privateFuncOverloaded(int);
+
+  static void privateStaticFunc();
+  static void privateStaticFuncOverloaded();
+  static void privateStaticFuncOverloaded(int);
+
+  static constexpr int privateStaticInt = 44;
+};
+
+void globalFunction() {}
+
+//--//
+
+// template declarations for explicit instantiations
+template  class IT1 {};
+template  class IT2 {};
+template  class IT3 {};
+template  class IT4 {};
+template  class IT5 {};
+template  class IT6 {
+  template  class NIT1 {};
+};
+template  class IT7 {};
+template  class IT8 {};
+template  class IT9 {};
+
+// explicit instantiations
+
+// public
+template class IT1;
+template struct IT1>;
+template class IT1;
+template struct IT2;
+template class IT3;
+template struct IT4<&TestClass::publicFunc>;
+template class IT4<&TestClass::publicFuncOverloaded>;
+template class IT5<&TestClass::publicStaticFunc>;
+template class IT5<&TestClass::publicStaticFuncOverloaded>;
+template class IT5<&globalFunction>;
+template class IT6

[clang] c5028f3 - [Clang] XFAIL sanitize-coverage-old-pm.c on 32bit Armv8l

[Muhammad Omair Javaid via cfe-commits]

Author: Muhammad Omair Javaid
Date: 2021-06-24T15:48:13+05:00
New Revision: c5028f3473ed50a7433fe278984cd1a755b338b9

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

LOG: [Clang] XFAIL sanitize-coverage-old-pm.c on 32bit Armv8l

sanitize-coverage-old-pm.c started failing on arm 32 bit where
underlying architecture reported is armv8l fore 32bit arm.
This patch XFAILS sanitize-coverage-old-pm.c on armv8l similar
to armv7 and thumbv7.

Added: 


Modified: 
clang/test/CodeGen/sanitize-coverage-old-pm.c

Removed: 




diff  --git a/clang/test/CodeGen/sanitize-coverage-old-pm.c 
b/clang/test/CodeGen/sanitize-coverage-old-pm.c
index 610dd651587f..fc764954cce8 100644
--- a/clang/test/CodeGen/sanitize-coverage-old-pm.c
+++ b/clang/test/CodeGen/sanitize-coverage-old-pm.c
@@ -6,7 +6,7 @@
 // RUN: %clang %s -target x86_64-unknown-linux-gnu -emit-llvm -S 
-fsanitize=undefined  -fsanitize-coverage=trace-pc,trace-cmp -o - 
-flegacy-pass-manager | FileCheck %s --check-prefixes=CHECK,UBSAN
 //
 // Host armv7 is currently unsupported: 
https://bugs.llvm.org/show_bug.cgi?id=46117
-// XFAIL: armv7, thumbv7
+// XFAIL: armv7, thumbv7, armv8l
 // The same issue also occurs on a riscv32 host.
 // XFAIL: riscv32
 



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

[PATCH] D93525: [clang-offload-bundler] Add unbundling of archives containing bundled object files into device specific archives

[Saiyedul Islam via Phabricator via cfe-commits]

saiislam updated this revision to Diff 354197.
saiislam added a comment.

Generalized padding of Triple fields of Bundle Entry ID while generating 
command for clang-offload-bundler.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93525

Files:
  clang/docs/ClangOffloadBundler.rst
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/clang-offload-bundler.c
  clang/test/Driver/hip-rdc-device-only.hip
  clang/test/Driver/hip-toolchain-rdc-separate.hip
  clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp

Index: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
===
--- clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
+++ clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
@@ -22,14 +22,18 @@
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/ADT/Triple.h"
+#include "llvm/Object/Archive.h"
+#include "llvm/Object/ArchiveWriter.h"
 #include "llvm/Object/Binary.h"
 #include "llvm/Object/ObjectFile.h"
 #include "llvm/Support/Casting.h"
 #include "llvm/Support/CommandLine.h"
+#include "llvm/Support/Debug.h"
 #include "llvm/Support/Errc.h"
 #include "llvm/Support/Error.h"
 #include "llvm/Support/ErrorOr.h"
 #include "llvm/Support/FileSystem.h"
+#include "llvm/Support/Host.h"
 #include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/Program.h"
@@ -82,6 +86,7 @@
"  bc  - llvm-bc\n"
"  s   - assembler\n"
"  o   - object\n"
+   "  a   - archive of objects\n"
"  gch - precompiled-header\n"
"  ast - clang AST file"),
   cl::cat(ClangOffloadBundlerCategory));
@@ -123,20 +128,49 @@
 /// Path to the current binary.
 static std::string BundlerExecutable;
 
-/// Obtain the offload kind and real machine triple out of the target
-/// information specified by the user.
-static void getOffloadKindAndTriple(StringRef Target, StringRef &OffloadKind,
-StringRef &Triple) {
-  auto KindTriplePair = Target.split('-');
-  OffloadKind = KindTriplePair.first;
-  Triple = KindTriplePair.second;
-}
-static bool hasHostKind(StringRef Target) {
+/// Obtain the offload kind, real machine triple, and an optional GPUArch
+/// out of the target information specified by the user.
+/// Bundle Entry ID (or, Offload Target String) has following components:
+///  * Offload Kind - Host, OpenMP, or HIP
+///  * Triple - Standard LLVM Triple
+///  * GPUArch (Optional) - Processor name, like gfx906 or sm_30
+/// In presence of Proc, the Triple should contain separator "-" for all
+/// standard four components, even if they are empty.
+struct OffloadTargetInfo {
   StringRef OffloadKind;
-  StringRef Triple;
-  getOffloadKindAndTriple(Target, OffloadKind, Triple);
-  return OffloadKind == "host";
-}
+  llvm::Triple Triple;
+  StringRef GPUArch;
+
+  OffloadTargetInfo(const StringRef Target) {
+SmallVector Components;
+Target.split(Components, '-', 5);
+Components.resize(6);
+this->OffloadKind = Components[0];
+this->Triple = llvm::Triple(Components[1], Components[2], Components[3],
+Components[4]);
+this->GPUArch = Components[5];
+  }
+
+  bool hasHostKind() const { return this->OffloadKind == "host"; }
+
+  bool isOffloadKindValid() const {
+return OffloadKind == "host" || OffloadKind == "openmp" ||
+   OffloadKind == "hip" || OffloadKind == "hipv4";
+  }
+
+  bool isTripleValid() const {
+return !Triple.str().empty() && Triple.getArch() != Triple::UnknownArch;
+  }
+
+  bool operator==(const OffloadTargetInfo &Target) const {
+return OffloadKind == Target.OffloadKind &&
+   Triple.isCompatibleWith(Target.Triple) && GPUArch == Target.GPUArch;
+  }
+
+  std::string str() {
+return Twine(OffloadKind + "-" + Triple.str() + "-" + GPUArch).str();
+  }
+};
 
 /// Generic file handler interface.
 class FileHandler {
@@ -163,7 +197,7 @@
   virtual Error ReadBundleEnd(MemoryBuffer &Input) = 0;
 
   /// Read the current bundle and write the result into the stream \a OS.
-  virtual Error ReadBundle(raw_fd_ostream &OS, MemoryBuffer &Input) = 0;
+  virtual Error ReadBundle(raw_ostream &OS, MemoryBuffer &Input) = 0;
 
   /// Write the header of the bundled file to \a OS based on the information
   /// gathered from \a Inputs.
@@ -378,7 +412,7 @@
 return Error::success();
   }
 
-  Error ReadBundle(raw_fd_ostream &OS, MemoryBuffer &Input) final {
+  Error ReadBundle(raw_ostream &OS, MemoryBuffer &Input) final {
 assert(CurBundleInfo != BundlesInfo.end() && "Invalid reader info!");
 StringRef FC = Input.getBuffer();
 OS.write(FC.data() + CurBundleInfo->second.Offset,
@@ -541,7 +575,7 @@
 
   Error ReadBundleEnd(MemoryBuffer &Input) f

[PATCH] D104096: [Clang-Format] Add ReferenceAlignment directive

[Seraphime Kirkovski (VMware) via Phabricator via cfe-commits]

skirkovski added a comment.

ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104096

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

[PATCH] D90399: [clang-tidy] non-portable-integer-constant check

[Whisperity via Phabricator via cfe-commits]

whisperity added inline comments.
Herald added a subscriber: cfe-commits.



Comment at: clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp:38
 #include "NoEscapeCheck.h"
+#include "NonportableintegerconstantCheck.h"
 #include "NotNullTerminatedResultCheck.h"

aaron.ballman wrote:
> Please use PascalCase for this -- `NonPortableIntegerConstantCheck.h`  (be 
> sure to change the actual case of the files being added in addition to the 
> include directives)
> Please use PascalCase for this -- `NonPortableIntegerConstantCheck.h`  (be 
> sure to change the actual case of the files being added in addition to the 
> include directives)





Comment at: clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp:124
 "bugprone-multiple-statement-macro");
+CheckFactories.registerCheck(
+"bugprone-non-portable-integer-constant");

> Please use PascalCase for this -- `NonPortableIntegerConstantCheck.h`  (be 
> sure to change the actual case of the files being added in addition to the 
> include directives)

Not just for the filename, but for the class's name as well, everywhere.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/NonportableintegerconstantCheck.cpp:21-23
+/// The mask is problematic if:
+/// - The highest bit is set and everything else are zeroes, for example: 
`0x8000`.
+/// - All the bits are set to one, for example: `0x`.





Comment at: 
clang-tools-extra/clang-tidy/bugprone/NonportableintegerconstantCheck.cpp:24-38
+bool isProblematicMask(StringRef HexNumber) {
+
+ // Check whether only the highest bit is set.
+  if (HexNumber[0] == '8' && HexNumber[1] == '0') {
+// Consume the first non-zero.
+HexNumber = HexNumber.drop_front();
+// Consume all the left zeroes.

C++17 introduced binary literals, i.e. `0b1100`, which could also be used 
for masking operations. I suggest creating two functions `isUnsafeHexMask()` 
and `isUnsafeBinMask()` and a wrapper function that calls both(?), and 
supporting finding literals like `0b1000` and `0b`.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/NonportableintegerconstantCheck.cpp:30
+HexNumber = HexNumber.drop_front();
+// Consume all the left zeroes.
+HexNumber = HexNumber.drop_while([](char C) { return C == '0'; });





Comment at: 
clang-tools-extra/clang-tidy/bugprone/NonportableintegerconstantCheck.cpp:41
+void NonportableintegerconstantCheck::registerMatchers(MatchFinder *Finder) {
+  Finder->addMatcher(integerLiteral().bind("integer"), this);
+}

aaron.ballman wrote:
> I'm a bit worried about the performance of this check given that it's going 
> to make a function call on every single integer literal anywhere in the 
> program. I'd be curious to know how this check performs compared to other 
> checks in the bugprone module.
I did a quick skim and it seems there is plenty of `integerLiteral(` matches 
used here and there, but most of them seem to either do an `equal(0)` or 
`equal(1)` sub-matching first. If performance is a concern, I think we could do 
an `unless(equal(0))`-like construct, given that no pattern that we try to 
check may match a literal 0.

(Although if we dig deeper into the maths, maybe we can come up with a better 
lower bound?)



Comment at: 
clang-tools-extra/clang-tidy/bugprone/NonportableintegerconstantCheck.cpp:63-64
+
+diag(MatchedInt->getBeginLoc(),
+ "integer is being used in a non-portable manner ");
+  }

This message is misleading. It should emphasise that it looks like a bit mask, 
and given that the CERT rule suggests portable ways (`-1` instead of `0x` 
and `~(MAX >> 1)` instead of `0x8000`), this check should be able to produce 
//FixIt//s based off of that.



Comment at: clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp:106-108
+// INT
+CheckFactories.registerCheck(
+"cert-int17-c");

This is a C-specific check, or does it apply to C++ too? If only applies to C, 
it should be disabled in C++ mode, if it applies to C++, is there a 
C++-specific CERT rule/tag/number/ID for that version?



Comment at: clang-tools-extra/docs/ReleaseNotes.rst:115-117
+  ` check.   
+  
+  Finds masks that are being used in a non-portable manner.

The name of the check versus the one-liner summary doesn't really match up.


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

https://reviews.llvm.org/D90399

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

[PATCH] D96355: [clang-tidy] Extend 'bugprone-easily-swappable-parameters' with optionally considering differently qualified types mixable

[Whisperity via Phabricator via cfe-commits]

whisperity updated this revision to Diff 354203.
whisperity added a comment.

**NC** Fix lint mishap that occurred during previous rebase.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96355

Files:
  clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.h
  
clang-tools-extra/docs/clang-tidy/checks/bugprone-easily-swappable-parameters.rst
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-ignore.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len3.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-qualifiermixing.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters.c

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters.c
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters.c
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters.c
@@ -2,7 +2,8 @@
 // RUN:   -config='{CheckOptions: [ \
 // RUN: {key: bugprone-easily-swappable-parameters.MinimumLength, value: 2}, \
 // RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterNames, value: ""}, \
-// RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterTypeSuffixes, value: "bool;MyBool;struct U;MAKE_LOGICAL_TYPE(int)"} \
+// RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterTypeSuffixes, value: "bool;MyBool;struct U;MAKE_LOGICAL_TYPE(int)"}, \
+// RUN: {key: bugprone-easily-swappable-parameters.QualifiersMix, value: 0} \
 // RUN:  ]}' -- -x c
 
 #define bool _Bool
Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-qualifiermixing.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-qualifiermixing.cpp
@@ -0,0 +1,112 @@
+// RUN: %check_clang_tidy %s bugprone-easily-swappable-parameters %t \
+// RUN:   -config='{CheckOptions: [ \
+// RUN: {key: bugprone-easily-swappable-parameters.MinimumLength, value: 2}, \
+// RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterNames, value: ""}, \
+// RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterTypeSuffixes, value: ""}, \
+// RUN: {key: bugprone-easily-swappable-parameters.QualifiersMix, value: 1} \
+// RUN:  ]}' --
+
+typedef int MyInt1;
+typedef int MyInt2;
+using CInt = const int;
+using CMyInt1 = const MyInt1;
+using CMyInt2 = const MyInt2;
+
+void qualified1(int I, const int CI) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:17: warning: 2 adjacent parameters of 'qualified1' of similar type are easily swapped by mistake [bugprone-easily-swappable-parameters]
+// CHECK-MESSAGES: :[[@LINE-2]]:21: note: the first parameter in the range is 'I'
+// CHECK-MESSAGES: :[[@LINE-3]]:34: note: the last parameter in the range is 'CI'
+// CHECK-MESSAGES: :[[@LINE-4]]:24: note: 'int' and 'const int' parameters accept and bind the same kind of values
+
+void qualified2(int I, volatile int VI) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:17: warning: 2 adjacent parameters of 'qualified2' of similar type are
+// CHECK-MESSAGES: :[[@LINE-2]]:21: note: the first parameter in the range is 'I'
+// CHECK-MESSAGES: :[[@LINE-3]]:37: note: the last parameter in the range is 'VI'
+// CHECK-MESSAGES: :[[@LINE-4]]:24: note: 'int' and 'volatile int' parameters accept and bind the same kind of values
+
+void qualified3(int I, const volatile int CVI) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:17: warning: 2 adjacent parameters of 'qualified3' of similar type are
+// CHECK-MESSAGES: :[[@LINE-2]]:21: note: the first parameter in the range is 'I'
+// CHECK-MESSAGES: :[[@LINE-3]]:43: note: the last parameter in the range is 'CVI'
+// CHECK-MESSAGES: :[[@LINE-4]]:24: note: 'int' and 'const volatile int' parameters accept and bind the same kind of values
+
+void qualified4(int *IP, const int *CIP) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:17: warning: 2 adjacent parameters of 'qualified4' of similar type are
+// CHECK-MESSAGES: :[[@LINE-2]]:22: note: the first parameter in the range is 'IP'
+// CHECK-MESSAGES: :[[@LINE-3]]:37: note: the last parameter in the range is 'CIP'
+// CHECK-MESSAGES: :[[@LINE-4]]:26: note: 'int *' and 'const int *' parameters accept and bind the same kind of values
+
+void qualified5(const int CI, const long CL) {} // NO-WARN: Not the same type
+
+void qualifiedPtr1(int *IP, int *const IPC) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:20: warning: 2 adjacent parameters of 'qualifiedPtr1' of similar type are
+// CHECK-MESSAGES: :[[@LINE-2]]:25: note: the first pa

[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#2837794 , @dblaikie wrote:

> 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?

To me, this is the key bit:

> 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?

because it **does** affect the callers, the programmer introducing the API 
should be aware of that. Making this case an error helps them to understand 
that this attribute is actually a part of their API and not an implementation 
detail, and silently applying the attribute may cause hard-to-debug problems 
for them after deployment of their API.


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] D104819: [ADT] Rename StringRef case insensitive methods for clarity

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith added a comment.

Given how large this is, would it be reasonable to split this up a bit more?

What I might do if this were my patch: get a review of the API change + the 
manual changes in one patch (assuming there aren't many manual changes), then 
land the remaining mechanical changes in chunks, perhaps vaguely by component, 
likely using post-commit review. The benefit of committing by chunks is that if 
there is some problem that comes up (even mechanical changes fail) there's more 
granularity for bisection (and less churn on revert). WDYT?

Also: is there a reference to this API in the ProgrammersManual? (I honestly 
don't know, but if there is, please be sure to update it as well.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104819

___
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#2837136 , @mstorsjo wrote:

> In D104556#2837104 , @rnk wrote:
>
>> 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.

Yes, consistency among binary formats. A 64-bit label difference `.quad A-B` is 
directly expressable on Mach-O and RISC-V (`R_RISCV_SUB*`) and can be converted 
to PC-relative on ELF.

For example, mips64 supports 64-bit PC-relative since D80390 
 (GNU as still doesn't allow it) => this 
allowed an XRay clean-up D87977 .


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] D104819: [ADT] Rename StringRef case insensitive methods for clarity

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added inline comments.



Comment at: llvm/include/llvm/ADT/StringRef.h:192
 
-/// equals_lower - Check for string equality, ignoring case.
+/// equals_insensitive - Check for string equality, ignoring case.
 LLVM_NODISCARD

https://llvm.org/docs/CodingStandards.html#doxygen-use-in-documentation-comments

"Don’t duplicate function or class name at the beginning of the comment."


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104819

___
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

[Jay Foad via Phabricator via cfe-commits]

foad added inline comments.



Comment at: clang/test/Driver/amdgpu-mcpu.cl:138
 // GFX1034:   "-target-cpu" "gfx1034"
+// GFX1034:   "-target-cpu" "gfx1035"

Typo in check prefix. Why didn't this make the test fail?



Comment at: llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp:177
   case GK_GFX1034: return ELF::EF_AMDGPU_MACH_AMDGCN_GFX1034;
   case GK_NONE:return ELF::EF_AMDGPU_MACH_NONE;
   }

Please update this switch too.



Comment at: llvm/test/CodeGen/AMDGPU/directive-amdgcn-target.ll:91
 ; RUN: llc -mtriple=amdgcn-amd-amdhsa --amdhsa-code-object-version=3 
-mcpu=gfx1034 < %s | FileCheck --check-prefixes=V3-GFX1034 %s
+; RUN: llc -mtriple=amdgcn-amd-amdhsa --amdhsa-code-object-version=3 
-mcpu=gfx1035 < %s | FileCheck --check-prefixes=V3-GFX1035 %s
 

You've added a RUN line here but no checks that use the new prefix. (Doesn't 
that make llvm-lit complain?)



Comment at: llvm/test/CodeGen/AMDGPU/directive-amdgcn-target.ll:183
 ; RUN: llc -mtriple=amdgcn-amd-amdhsa -mcpu=gfx1034 < %s | FileCheck 
--check-prefixes=GFX1034 %s
 
 ; V3-GFX600: .amdgcn_target "amdgcn-amd-amdhsa--gfx600"

Add a RUN line here?


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] D104819: [ADT] Rename StringRef case insensitive methods for clarity

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo added a comment.

In D104819#2837421 , @dexonsmith 
wrote:

> Given how large this is, would it be reasonable to split this up a bit more?
>
> What I might do if this were my patch: get a review of the API change + the 
> manual changes in one patch (assuming there aren't many manual changes), then 
> land the remaining mechanical changes in chunks, perhaps vaguely by 
> component, likely using post-commit review. The benefit of committing by 
> chunks is that if there is some problem that comes up (even mechanical 
> changes fail) there's more granularity for bisection (and less churn on 
> revert). WDYT?

That sounds like a good plan to me, thanks for the suggestion!

> Also: is there a reference to this API in the ProgrammersManual? (I honestly 
> don't know, but if there is, please be sure to update it as well.)

I don't think so, at least grepping for `_lower` didn't hit anything in 
llvm/docs (and manually browsing it now, the section on StringRef doesn't 
mention those methods).




Comment at: llvm/include/llvm/ADT/StringRef.h:192
 
-/// equals_lower - Check for string equality, ignoring case.
+/// equals_insensitive - Check for string equality, ignoring case.
 LLVM_NODISCARD

MaskRay wrote:
> https://llvm.org/docs/CodingStandards.html#doxygen-use-in-documentation-comments
> 
> "Don’t duplicate function or class name at the beginning of the comment."
Thanks, I'll fix those for the methods I'm renaming here, but I'll refrain from 
touching the other methods in this patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104819

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

[PATCH] D104819: [ADT] Rename StringRef case insensitive methods for clarity

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo updated this revision to Diff 354178.
mstorsjo added a comment.

Reduced this patch only to updating of the StringRef class itself and its unit 
test, removing the mechanical changes. Removed superfluous method name 
duplication in doxygen comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104819

Files:
  llvm/include/llvm/ADT/StringRef.h
  llvm/lib/Support/StringRef.cpp
  llvm/unittests/ADT/StringRefTest.cpp

Index: llvm/unittests/ADT/StringRefTest.cpp
===
--- llvm/unittests/ADT/StringRefTest.cpp
+++ llvm/unittests/ADT/StringRefTest.cpp
@@ -98,15 +98,15 @@
   EXPECT_EQ( 1, StringRef("aab").compare("aa"));
   EXPECT_EQ( 1, StringRef("\xFF").compare("\1"));
 
-  EXPECT_EQ(-1, StringRef("AaB").compare_lower("aAd"));
-  EXPECT_EQ( 0, StringRef("AaB").compare_lower("aab"));
-  EXPECT_EQ( 1, StringRef("AaB").compare_lower("AAA"));
-  EXPECT_EQ(-1, StringRef("AaB").compare_lower("aaBb"));
-  EXPECT_EQ(-1, StringRef("AaB").compare_lower("bb"));
-  EXPECT_EQ( 1, StringRef("aaBb").compare_lower("AaB"));
-  EXPECT_EQ( 1, StringRef("bb").compare_lower("AaB"));
-  EXPECT_EQ( 1, StringRef("AaB").compare_lower("aA"));
-  EXPECT_EQ( 1, StringRef("\xFF").compare_lower("\1"));
+  EXPECT_EQ(-1, StringRef("AaB").compare_insensitive("aAd"));
+  EXPECT_EQ( 0, StringRef("AaB").compare_insensitive("aab"));
+  EXPECT_EQ( 1, StringRef("AaB").compare_insensitive("AAA"));
+  EXPECT_EQ(-1, StringRef("AaB").compare_insensitive("aaBb"));
+  EXPECT_EQ(-1, StringRef("AaB").compare_insensitive("bb"));
+  EXPECT_EQ( 1, StringRef("aaBb").compare_insensitive("AaB"));
+  EXPECT_EQ( 1, StringRef("bb").compare_insensitive("AaB"));
+  EXPECT_EQ( 1, StringRef("AaB").compare_insensitive("aA"));
+  EXPECT_EQ( 1, StringRef("\xFF").compare_insensitive("\1"));
 
   EXPECT_EQ(-1, StringRef("aab").compare_numeric("aad"));
   EXPECT_EQ( 0, StringRef("aab").compare_numeric("aab"));
@@ -366,14 +366,14 @@
   EXPECT_FALSE(Str.startswith("hi"));
 }
 
-TEST(StringRefTest, StartsWithLower) {
+TEST(StringRefTest, StartsWithInsensitive) {
   StringRef Str("heLLo");
-  EXPECT_TRUE(Str.startswith_lower(""));
-  EXPECT_TRUE(Str.startswith_lower("he"));
-  EXPECT_TRUE(Str.startswith_lower("hell"));
-  EXPECT_TRUE(Str.startswith_lower("HELlo"));
-  EXPECT_FALSE(Str.startswith_lower("helloworld"));
-  EXPECT_FALSE(Str.startswith_lower("hi"));
+  EXPECT_TRUE(Str.startswith_insensitive(""));
+  EXPECT_TRUE(Str.startswith_insensitive("he"));
+  EXPECT_TRUE(Str.startswith_insensitive("hell"));
+  EXPECT_TRUE(Str.startswith_insensitive("HELlo"));
+  EXPECT_FALSE(Str.startswith_insensitive("helloworld"));
+  EXPECT_FALSE(Str.startswith_insensitive("hi"));
 }
 
 TEST(StringRefTest, ConsumeFront) {
@@ -392,22 +392,22 @@
   EXPECT_TRUE(Str.consume_front(""));
 }
 
-TEST(StringRefTest, ConsumeFrontLower) {
+TEST(StringRefTest, ConsumeFrontInsensitive) {
   StringRef Str("heLLo");
-  EXPECT_TRUE(Str.consume_front_lower(""));
+  EXPECT_TRUE(Str.consume_front_insensitive(""));
   EXPECT_EQ("heLLo", Str);
   EXPECT_FALSE(Str.consume_front("HEl"));
   EXPECT_EQ("heLLo", Str);
-  EXPECT_TRUE(Str.consume_front_lower("HEl"));
+  EXPECT_TRUE(Str.consume_front_insensitive("HEl"));
   EXPECT_EQ("Lo", Str);
-  EXPECT_FALSE(Str.consume_front_lower("loworld"));
+  EXPECT_FALSE(Str.consume_front_insensitive("loworld"));
   EXPECT_EQ("Lo", Str);
-  EXPECT_FALSE(Str.consume_front_lower("ol"));
+  EXPECT_FALSE(Str.consume_front_insensitive("ol"));
   EXPECT_EQ("Lo", Str);
-  EXPECT_TRUE(Str.consume_front_lower("lo"));
+  EXPECT_TRUE(Str.consume_front_insensitive("lo"));
   EXPECT_EQ("", Str);
-  EXPECT_FALSE(Str.consume_front_lower("o"));
-  EXPECT_TRUE(Str.consume_front_lower(""));
+  EXPECT_FALSE(Str.consume_front_insensitive("o"));
+  EXPECT_TRUE(Str.consume_front_insensitive(""));
 }
 
 TEST(StringRefTest, EndsWith) {
@@ -419,14 +419,14 @@
   EXPECT_FALSE(Str.endswith("so"));
 }
 
-TEST(StringRefTest, EndsWithLower) {
+TEST(StringRefTest, EndsWithInsensitive) {
   StringRef Str("heLLo");
-  EXPECT_TRUE(Str.endswith_lower(""));
-  EXPECT_TRUE(Str.endswith_lower("lo"));
-  EXPECT_TRUE(Str.endswith_lower("LO"));
-  EXPECT_TRUE(Str.endswith_lower("ELlo"));
-  EXPECT_FALSE(Str.endswith_lower("helloworld"));
-  EXPECT_FALSE(Str.endswith_lower("hi"));
+  EXPECT_TRUE(Str.endswith_insensitive(""));
+  EXPECT_TRUE(Str.endswith_insensitive("lo"));
+  EXPECT_TRUE(Str.endswith_insensitive("LO"));
+  EXPECT_TRUE(Str.endswith_insensitive("ELlo"));
+  EXPECT_FALSE(Str.endswith_insensitive("helloworld"));
+  EXPECT_FALSE(Str.endswith_insensitive("hi"));
 }
 
 TEST(StringRefTest, ConsumeBack) {
@@ -445,22 +445,22 @@
   EXPECT_TRUE(Str.consume_back(""));
 }
 
-TEST(StringRefTest, ConsumeBackLower) {
+TEST(StringRefTest, ConsumeBackInsensitive) {
   StringRef Str("heLLo");
-  EXPECT_TRUE(Str.consume_back_lower(""));
+  EXPECT_TRUE(Str.consume_back_

[PATCH] D104844: [Analyzer][solver] Fix crashes during symbol simplification

[Valeriy Savchenko via Phabricator via cfe-commits]

vsavchenko added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:2314-2315
 
+  if (SymbolRef SimplifiedSym = simplify(St, Sym))
+Sym = SimplifiedSym;
+

I don't like the idea of duplicating it into every `assume` method.  This way 
we drastically increase our chances to forget it (like you did with 
`assumeSymGE` and `assumeSymLE`).
I think the better place for it is in `RangedConstraintManager::assumeSymRel` 
and neighboring methods, though still not perfect.
I don't really get why we get not simplified symbol to begin with.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104844

___
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 updated this revision to Diff 354205.
MyDeveloperDay added a comment.

Fix `parseBracedList()` to do what `parseStructuralElement()` does (with regard 
to breaking `AfterFunction`, I'm not completely convinced `AfterFunction` 
should have been reused for that but might be too late to change.

This fixes the somewhat random indentation but also ensue the `{` is on a 
newline in Microsoft style like the other lambda in the unit tests, add tests 
to show that the indentation is being handled by the IndentWidth and that 
GoogleStyle handles the `{` positioning correctly.


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

https://reviews.llvm.org/D104388

Files:
  clang/lib/Format/UnwrappedLineParser.cpp
  clang/unittests/Format/FormatTestCSharp.cpp

Index: clang/unittests/Format/FormatTestCSharp.cpp
===
--- clang/unittests/Format/FormatTestCSharp.cpp
+++ clang/unittests/Format/FormatTestCSharp.cpp
@@ -640,6 +640,122 @@
 };
 })",
MicrosoftStyle);
+
+  verifyFormat("void bar()\n"
+   "{\n"
+   "Function(Val, (Action)(() =>\n"
+   "   {\n"
+   "   lock (mylock)\n"
+   "   {\n"
+   "   if (true)\n"
+   "   {\n"
+   "   A.Remove(item);\n"
+   "   }\n"
+   "   }\n"
+   "   }));\n"
+   "}",
+   MicrosoftStyle);
+
+  verifyFormat("void baz()\n"
+   "{\n"
+   "Function(Val, (Action)(() =>\n"
+   "   {\n"
+   "   using (var a = new Lock())\n"
+   "   {\n"
+   "   if (true)\n"
+   "   {\n"
+   "   A.Remove(item);\n"
+   "   }\n"
+   "   }\n"
+   "   }));\n"
+   "}",
+   MicrosoftStyle);
+
+  verifyFormat("void baz()\n"
+   "{\n"
+   "Function(Val, (Action)(() =>\n"
+   "   {\n"
+   "   if (true)\n"
+   "   {\n"
+   "   A.Remove(item);\n"
+   "   }\n"
+   "   }));\n"
+   "}",
+   MicrosoftStyle);
+
+  verifyFormat("void baz()\n"
+   "{\n"
+   "Function(Val, (Action)(() =>\n"
+   "   {\n"
+   "   do\n"
+   "   {\n"
+   "   A.Remove(item);\n"
+   "   } while (true)\n"
+   "   }));\n"
+   "}",
+   MicrosoftStyle);
+
+  verifyFormat("void baz()\n"
+   "{\n"
+   "Function(Val, (Action)(() =>\n"
+   "   { A.Remove(item); }));\n"
+   "}",
+   MicrosoftStyle);
+
+  verifyFormat("void bar()\n"
+   "{\n"
+   "Function(Val, (() =>\n"
+   "   {\n"
+   "   lock (mylock)\n"
+   "   {\n"
+   "   if (true)\n"
+   "   {\n"
+   "   A.Remove(item);\n"
+   "   }\n"
+   "   }\n"
+   "   }));\n"
+   "}",
+   MicrosoftStyle);
+  verifyFormat("void bar()\n"
+   "{\n"
+   "Function((() =>\n"
+   "  {\n"
+   "  lock (mylock)\n"
+   "  {\n"
+   "  if (true)\n"
+   "  {\n"
+   "  A.Remove(item);\n"
+   "  }\n"
+   "  }\n"
+   "  }));\n"
+   "}",
+   MicrosoftStyle);
+
+  MicrosoftStyle.IndentWidth = 2;
+  verifyFormat("void bar()\n"
+   "{\n"
+   "  Function((() =>\n"
+

[PATCH] D104847: [Clang][NVPTX] Add NVPTX intrinsics and builtins for CUDA PTX 6.5 and 7.0 WMMA and MMA instructions

[Steffen Larsen via Phabricator via cfe-commits]

steffenlarsen created this revision.
steffenlarsen added a reviewer: tra.
Herald added subscribers: hiraditya, yaxunl, jholewinski.
steffenlarsen requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, jdoerfert.
Herald added projects: clang, LLVM.

Adds NVPTX builtins and intrinsics for the CUDA PTX `wmma.load`, `wmma.store`, 
`wmma.mma`, and `mma` instructions added in PTX 6.5 and 7.0.

PTX ISA description of

- `wmma.load`: 
https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#warp-level-matrix-instructions-wmma-ld
- `wmma.store`: 
https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#warp-level-matrix-instructions-wmma-st
- `wmma.mma`: 
https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#warp-level-matrix-instructions-wmma-mma
- `mma`: 
https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#warp-level-matrix-instructions-mma

Overview of `wmma.mma` and `mma` matrix shape/type combinations added with 
specific PTX versions: 
https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#warp-level-matrix-shape

Authored-by: Steffen Larsen 
Co-Authored-by: Stuart Adams 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104847

Files:
  clang/include/clang/Basic/BuiltinsNVPTX.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-nvptx-mma.cu
  clang/test/CodeGen/builtins-nvptx-mma.py
  llvm/include/llvm/IR/IntrinsicsNVVM.td
  llvm/lib/Target/NVPTX/NVPTXISelLowering.cpp
  llvm/lib/Target/NVPTX/NVPTXInstrInfo.td
  llvm/lib/Target/NVPTX/NVPTXIntrinsics.td
  llvm/test/CodeGen/NVPTX/lit.local.cfg
  llvm/test/CodeGen/NVPTX/wmma.py

Index: llvm/test/CodeGen/NVPTX/wmma.py
===
--- llvm/test/CodeGen/NVPTX/wmma.py
+++ llvm/test/CodeGen/NVPTX/wmma.py
@@ -6,7 +6,7 @@
 # RUN: FileCheck %t-ptx60-sm_70.ll < %t-ptx60-sm_70.ll \
 # RUN:   --check-prefixes=INTRINSICS,M16N16
 # RUN: FileCheck %t-ptx60-sm_70.ll < %t-ptx60-sm_70.ll \
-# RUN:   --check-prefixes=INTRINSICS,NOEXTGEOM,NOINT,NOSUBINT,NOMMA
+# RUN:   --check-prefixes=INTRINSICS,NOEXTGEOM,NOINT,NOSUBINT,NOMMA,NODOUBLE,NOALTFLOAT
 # RUN: llc < %t-ptx60-sm_70.ll -march=nvptx64 -mcpu=sm_70 -mattr=+ptx60 \
 # RUN:   | FileCheck %t-ptx60-sm_70.ll
 
@@ -15,7 +15,7 @@
 # RUN: FileCheck %t-ptx61-sm_70.ll < %t-ptx61-sm_70.ll \
 # RUN:   --check-prefixes=INTRINSICS,M16N16,EXTGEOM
 # RUN: FileCheck %t-ptx61-sm_70.ll < %t-ptx61-sm_70.ll \
-# RUN:   --check-prefixes=INTRINSICS,NOINT,NOSUBINT,NOMMA
+# RUN:   --check-prefixes=INTRINSICS,NOINT,NOSUBINT,NOMMA,NODOUBLE,NOALTFLOAT
 # RUN: llc < %t-ptx61-sm_70.ll -march=nvptx64 -mcpu=sm_70 -mattr=+ptx61 \
 # RUN:   | FileCheck %t-ptx61-sm_70.ll
 
@@ -24,7 +24,7 @@
 # RUN: FileCheck %t-ptx63-sm_72.ll < %t-ptx63-sm_72.ll \
 # RUN:   --check-prefixes=INTRINSICS,M16N16,EXTGEOM,INT
 # RUN: FileCheck %t-ptx63-sm_72.ll < %t-ptx63-sm_72.ll \
-# RUN:   --check-prefixes=INTRINSICS,NOSUBINT,NOMMA
+# RUN:   --check-prefixes=INTRINSICS,NOSUBINT,NOMMA,NODOUBLE,NOALTFLOAT
 # RUN: llc < %t-ptx63-sm_72.ll -march=nvptx64 -mcpu=sm_72 -mattr=+ptx63 \
 # RUN:   | FileCheck %t-ptx63-sm_72.ll
 
@@ -33,7 +33,7 @@
 # RUN: FileCheck %t-ptx63-sm_75.ll < %t-ptx63-sm_75.ll \
 # RUN:   --check-prefixes=INTRINSICS,M16N16,EXTGEOM,INT,SUBINT
 # RUN: FileCheck %t-ptx63-sm_75.ll < %t-ptx63-sm_75.ll \
-# RUN:   --check-prefixes=INTRINSICS,NOMMA
+# RUN:   --check-prefixes=INTRINSICS,NOMMA,NODOUBLE,NOALTFLOAT
 # RUN: llc < %t-ptx63-sm_75.ll -march=nvptx64 -mcpu=sm_75 -mattr=+ptx63 \
 # RUN:   | FileCheck %t-ptx63-sm_75.ll
 
@@ -42,10 +42,28 @@
 # RUN: FileCheck %t-ptx64-sm_70.ll < %t-ptx64-sm_70.ll \
 # RUN:   --check-prefixes=INTRINSICS,M16N16,EXTGEOM,MMA
 # RUN: FileCheck %t-ptx64-sm_70.ll < %t-ptx64-sm_70.ll \
-# RUN:   --check-prefixes=INTRINSICS,NOINT,NOSUBINT
+# RUN:   --check-prefixes=INTRINSICS,NOINT,NOSUBINT,NODOUBLE,NOALTFLOAT
 # RUN: llc < %t-ptx64-sm_70.ll -march=nvptx64 -mcpu=sm_70 -mattr=+ptx64 \
 # RUN:   | FileCheck %t-ptx64-sm_70.ll
 
+# Check all variants of instructions supported by PTX65 on SM75+
+# RUN: python %s --ptx=65 --gpu-arch=75 > %t-ptx65-sm_75.ll
+# RUN: FileCheck %t-ptx65-sm_75.ll < %t-ptx65-sm_75.ll \
+# RUN:   --check-prefixes=INTRINSICS,M16N16,EXTGEOM,INT,SUBINT,MMA,PTX65MMA
+# RUN: FileCheck %t-ptx65-sm_75.ll < %t-ptx65-sm_75.ll \
+# RUN:   --check-prefixes=INTRINSICS
+# RUN: llc < %t-ptx65-sm_75.ll -march=nvptx64 -mcpu=sm_75 -mattr=+ptx65 \
+# RUN:   | FileCheck %t-ptx65-sm_75.ll
+
+# Check all variants of instructions supported by PTX70 on SM80+
+# RUN: python %s --ptx=70 --gpu-arch=80 > %t-ptx70-sm_80.ll
+# RUN: FileCheck %t-ptx70-sm_80.ll < %t-ptx70-sm_80.ll \
+# RUN:   --check-prefixes=INTRINSICS,M16N16,EXTGEOM,INT,SUBINT,MMA,ALTFLOAT,DOUBLE,PTX65MMA,PTX70MMA
+# RUN: Fi

[PATCH] D75041: [clang-tidy] Extend 'bugprone-easily-swappable-parameters' with mixability because of implicit conversions

[Whisperity via Phabricator via cfe-commits]

whisperity updated this revision to Diff 354210.
whisperity added a comment.

**NC** Rebase, buildbots, etc.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75041

Files:
  clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.h
  
clang-tools-extra/docs/clang-tidy/checks/bugprone-easily-swappable-parameters.rst
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-ignore.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-implicit-qualifiers.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-implicits.c
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-implicits.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len3.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-qualifiermixing.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters.c

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters.c
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters.c
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters.c
@@ -3,7 +3,8 @@
 // RUN: {key: bugprone-easily-swappable-parameters.MinimumLength, value: 2}, \
 // RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterNames, value: ""}, \
 // RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterTypeSuffixes, value: "bool;MyBool;struct U;MAKE_LOGICAL_TYPE(int)"}, \
-// RUN: {key: bugprone-easily-swappable-parameters.QualifiersMix, value: 0} \
+// RUN: {key: bugprone-easily-swappable-parameters.QualifiersMix, value: 0}, \
+// RUN: {key: bugprone-easily-swappable-parameters.ModelImplicitConversions, value: 0} \
 // RUN:  ]}' -- -x c
 
 #define bool _Bool
Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-qualifiermixing.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-qualifiermixing.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-qualifiermixing.cpp
@@ -3,7 +3,8 @@
 // RUN: {key: bugprone-easily-swappable-parameters.MinimumLength, value: 2}, \
 // RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterNames, value: ""}, \
 // RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterTypeSuffixes, value: ""}, \
-// RUN: {key: bugprone-easily-swappable-parameters.QualifiersMix, value: 1} \
+// RUN: {key: bugprone-easily-swappable-parameters.QualifiersMix, value: 1}, \
+// RUN: {key: bugprone-easily-swappable-parameters.ModelImplicitConversions, value: 0} \
 // RUN:  ]}' --
 
 typedef int MyInt1;
Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len3.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len3.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len3.cpp
@@ -3,7 +3,8 @@
 // RUN: {key: bugprone-easily-swappable-parameters.MinimumLength, value: 3}, \
 // RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterNames, value: ""}, \
 // RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterTypeSuffixes, value: ""}, \
-// RUN: {key: bugprone-easily-swappable-parameters.QualifiersMix, value: 0} \
+// RUN: {key: bugprone-easily-swappable-parameters.QualifiersMix, value: 0}, \
+// RUN: {key: bugprone-easily-swappable-parameters.ModelImplicitConversions, value: 0} \
 // RUN:  ]}' --
 
 int add(int Left, int Right) { return Left + Right; } // NO-WARN: Only 2 parameters.
Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp
@@ -3,7 +3,8 @@
 // RUN: {key: bugprone-easily-swappable-parameters.MinimumLength, value: 2}, \
 // RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterNames, value: ""}, \
 // RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterTypeSuffixes, value: ""}, \
-// RUN: {key: bugprone-easily-swappable-parameters.QualifiersMix, value: 0} \
+// RUN: {key: bugprone-easily-swappable-parameters.Qualif

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

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

@HazardyKnusperkek Its probably my "bad" I should said "LGTM but maybe wait for 
the others to comment", but I'm fundamentally ok I think with the change. 
(we'll just revert if it breaks stuff! ;-))

We are free to add review comments after the fact, @owenpan  has been providing 
us with fixes and contributions to clang-format for a some time (years) so I 
pretty much trust them. I'm less sceptical in the review of those that 
contribute either on a regular basis (like yourself) or those who have done 
multiple features (like @owenpan).  I did actually download the patch, apply it 
and run all the unit tests too, (because I was slightly questioning in my mind 
the use of "Previous" and if it could be null), but it all seemed to check out 
(and I tried some combinations to try and break it))

I don't think we need to wait multiple accepts (although between us I think we 
do this from time to time), I think the LLVM rules specify that if you have an 
accept then its ok, But I do feel its perfectly acceptable to review after the 
fact and expect the author to change it again.

I was the one that added you and @curdeius as reviewers (as I normally do out 
of respect for your efforts), but perhaps only we know that we are the ones 
doing the lion share of clang-format reviewing (others might not know that).


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] D78652: [clang-tidy] Suppress reports to similarly used parameters in 'bugprone-easily-swappable-parameters'

[Whisperity via Phabricator via cfe-commits]

whisperity updated this revision to Diff 354218.
whisperity added a comment.

**NC** Rebase & more buildbot shenanigans so we can get a pass!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78652

Files:
  clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.h
  
clang-tools-extra/docs/clang-tidy/checks/bugprone-easily-swappable-parameters.rst
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-ignore.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-implicit-qualifiers.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-implicits.c
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-implicits.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len3.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-qualifiermixing.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-relatedness.c
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-relatedness.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters.c

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters.c
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters.c
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters.c
@@ -4,7 +4,8 @@
 // RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterNames, value: ""}, \
 // RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterTypeSuffixes, value: "bool;MyBool;struct U;MAKE_LOGICAL_TYPE(int)"}, \
 // RUN: {key: bugprone-easily-swappable-parameters.QualifiersMix, value: 0}, \
-// RUN: {key: bugprone-easily-swappable-parameters.ModelImplicitConversions, value: 0} \
+// RUN: {key: bugprone-easily-swappable-parameters.ModelImplicitConversions, value: 0}, \
+// RUN: {key: bugprone-easily-swappable-parameters.SuppressParametersUsedTogether, value: 0} \
 // RUN:  ]}' -- -x c
 
 #define bool _Bool
Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-relatedness.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-relatedness.cpp
@@ -0,0 +1,231 @@
+// RUN: %check_clang_tidy %s bugprone-easily-swappable-parameters %t \
+// RUN:   -config='{CheckOptions: [ \
+// RUN: {key: bugprone-easily-swappable-parameters.MinimumLength, value: 2}, \
+// RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterNames, value: ""}, \
+// RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterTypeSuffixes, value: ""}, \
+// RUN: {key: bugprone-easily-swappable-parameters.QualifiersMix, value: 0}, \
+// RUN: {key: bugprone-easily-swappable-parameters.ModelImplicitConversions, value: 0}, \
+// RUN: {key: bugprone-easily-swappable-parameters.SuppressParametersUsedTogether, value: 1} \
+// RUN:  ]}' --
+
+namespace std {
+template 
+T max(const T &A, const T &B);
+} // namespace std
+
+bool coin();
+void f(int);
+void g(int);
+void h(int, int);
+void i(int, bool);
+void i(int, char);
+
+struct Tmp {
+  int f(int);
+  int g(int, int);
+};
+
+struct Int {
+  int I;
+};
+
+void compare(int Left, int Right) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:14: warning: 2 adjacent parameters of 'compare' of similar type ('int')
+// CHECK-MESSAGES: :[[@LINE-2]]:18: note: the first parameter in the range is 'Left'
+// CHECK-MESSAGES: :[[@LINE-3]]:28: note: the last parameter in the range is 'Right'
+
+int decideSequence(int A, int B) {
+  if (A)
+return 1;
+  if (B)
+return 2;
+  return 3;
+}
+// CHECK-MESSAGES: :[[@LINE-7]]:20: warning: 2 adjacent parameters of 'decideSequence' of similar type ('int')
+// CHECK-MESSAGES: :[[@LINE-8]]:24: note: the first parameter in the range is 'A'
+// CHECK-MESSAGES: :[[@LINE-9]]:31: note: the last parameter in the range is 'B'
+
+int myMax(int A, int B) { // NO-WARN: Appears in same expression.
+  return A < B ? A : B;
+}
+
+int myMax2(int A, int B) { // NO-WARN: Appears in same expression.
+  if (A < B)
+return A;
+  return B;
+}
+
+int myMax3(int A, int B) { // NO-WARN: Appears in same expression.
+  return std::max(A, B);
+}
+
+int binaryToUnary(int A, int) {
+  return A;
+}
+// CHECK-MESSAGES: :[[@LINE-3]]:19: warning: 2 adjacent parameters of 'binaryToUnary' of similar type ('int')
+// CHECK-MESSAGES: :[[@LINE-4]]:23: note: the first parameter in the range is 'A'
+// CH

[PATCH] D89649: Fix __has_unique_object_representations with no_unique_address

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman accepted this revision.
aaron.ballman added a comment.

LGTM!




Comment at: clang/lib/AST/ASTContext.cpp:2570-2571
+getSubobjectSizeInBits(const FieldDecl *Field, const ASTContext &Context) {
+  if (Field->getType()->isRecordType()) {
+const RecordDecl *RD = Field->getType()->getAsRecordDecl();
+if (!RD->isUnion())





Comment at: clang/test/SemaCXX/has_unique_object_reps_no_unique_addr.cpp:42
+} // namespace TailPaddingReuse
+static_assert(__has_unique_object_representations(TailPaddingReuse::B));

gbencze wrote:
> steakhal wrote:
> > Why is this outside of the namespace declaration?
> Tbh I'm not sure. I can move it in the namespace if you think it'd be better 
> there. 
No reason not to.


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

https://reviews.llvm.org/D89649

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

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

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov updated this revision to Diff 354225.
ASDenysPetrov added a comment.

Added assertions. Added two helper functions for `castTo` method. Moved some 
distinct code to them. Fixed clang-tidy complaints.


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

https://reviews.llvm.org/D103094

Files:
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/APSIntType.h
  
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  clang/unittests/StaticAnalyzer/RangeSetTest.cpp

Index: clang/unittests/StaticAnalyzer/RangeSetTest.cpp
===
--- clang/unittests/StaticAnalyzer/RangeSetTest.cpp
+++ clang/unittests/StaticAnalyzer/RangeSetTest.cpp
@@ -40,12 +40,18 @@
   const Range &R) {
   return OS << toString(R);
 }
+LLVM_ATTRIBUTE_UNUSED static std::ostream &operator<<(std::ostream &OS,
+  APSIntType Ty) {
+  return OS << (Ty.isUnsigned() ? "u" : "s") << Ty.getBitWidth();
+}
 
 } // namespace ento
 } // namespace clang
 
 namespace {
 
+template  constexpr bool is_signed_v = std::is_signed::value;
+
 template  struct TestValues {
   static constexpr T MIN = std::numeric_limits::min();
   static constexpr T MAX = std::numeric_limits::max();
@@ -53,7 +59,7 @@
   // which unary minus does not affect on,
   // e.g. int8/int32(0), uint8(128), uint32(2147483648).
   static constexpr T MID =
-  std::is_signed::value ? 0 : ~(static_cast(-1) / static_cast(2));
+  is_signed_v ? 0 : ~(static_cast(-1) / static_cast(2));
   static constexpr T A = MID - (MAX - MID) / 3 * 2;
   static constexpr T B = MID - (MAX - MID) / 3;
   static constexpr T C = -B;
@@ -61,6 +67,34 @@
 
   static_assert(MIN < A && A < B && B < MID && MID < C && C < D && D < MAX,
 "Values shall be in an ascending order");
+  // Clear bits in low bytes by the given amount.
+  template 
+  static const T ClearLowBytes = static_cast(static_cast(Value)
+<< ((Bytes >= 8) ? 0 : Bytes) *
+   8);
+
+  template 
+  static constexpr T TruncZeroOf = ClearLowBytes;
+
+  // Random number with active bits in every byte. 0x'
+  static constexpr T XAAA = static_cast(
+  0b10101010'10101010'10101010'10101010'10101010'10101010'10101010'10101010);
+  template 
+  static constexpr T XAAATruncZeroOf = TruncZeroOf; // 0x'AB00
+
+  // Random number with active bits in every byte. 0x'
+  static constexpr T X555 = static_cast(
+  0b01010101'01010101'01010101'01010101'01010101'01010101'01010101'01010101);
+  template 
+  static constexpr T X555TruncZeroOf = TruncZeroOf; // 0x'5600
+
+  // Numbers for ranges with the same bits in the lowest byte.
+  // 0x'AA2A
+  static constexpr T FromA = ClearLowBytes + 42;
+  static constexpr T ToA = FromA + 2; // 0x'AA2C
+  // 0x'552A
+  static constexpr T FromB = ClearLowBytes + 42;
+  static constexpr T ToB = FromB + 2; // 0x'552C
 };
 
 template  class RangeSetTest : public testing::Test {
@@ -74,21 +108,27 @@
   // End init block
 
   using Self = RangeSetTest;
-  using RawRange = std::pair;
-  using RawRangeSet = std::initializer_list;
-
-  const llvm::APSInt &from(BaseType X) {
-static llvm::APSInt Base{sizeof(BaseType) * 8,
- std::is_unsigned::value};
-Base = X;
-return BVF.getValue(Base);
+  template  using RawRangeT = std::pair;
+  template 
+  using RawRangeSetT = std::initializer_list>;
+  using RawRange = RawRangeT;
+  using RawRangeSet = RawRangeSetT;
+  template 
+  static constexpr APSIntType APSIntTy = APSIntType(sizeof(T) * 8,
+!is_signed_v);
+
+  template  const llvm::APSInt &from(T X) {
+static llvm::APSInt Int = APSIntTy.getZeroValue();
+Int = X;
+return BVF.getValue(Int);
   }
 
-  Range from(const RawRange &Init) {
+  template  Range from(const RawRangeT &Init) {
 return Range(from(Init.first), from(Init.second));
   }
 
-  RangeSet from(const RawRangeSet &Init) {
+  template 
+  RangeSet from(RawRangeSetT Init, APSIntType Ty = APSIntTy) {
 RangeSet RangeSet = F.getEmptySet();
 for (const auto &Raw : Init) {
   RangeSet = F.add(RangeSet, from(Raw));
@@ -211,9 +251,20 @@
RawRangeSet RawExpected) {
 wrap(&Self::checkDeleteImpl, Point, RawFrom, RawExpected);
   }
-};
 
-} // namespace
+  void checkCastToImpl(RangeSet What, APSIntType Ty, RangeSet Expected) {
+RangeSet Result = F.castTo(What, Ty);
+EXPECT_EQ(Result, Expected)
+<< "while casting " << toString(What) << " to " << Ty;
+  }
+
+  template 
+  void checkCastTo(RawRangeSetT What, RawRangeSetT Expected) {
+static constexpr APSIntType FromTy = APSIntTy;
+static constexpr AP

[PATCH] D104198: [Matrix] Add documentation for compound assignment and type conversion of matrix types

[Florian Hahn via Phabricator via cfe-commits]

fhahn added a comment.

Thanks for the latest changes!




Comment at: clang/docs/LanguageExtensions.rst:526
 
+The matrix type extension also supports operations between a matrix and a 
scalar.
+

I'm not a native speaker, but I am not sure if `between` is the best choice 
here. To me, `on` would sound slightly better, but again, I'm no expert.



Comment at: clang/docs/LanguageExtensions.rst:533
+  m4x4_t f(m4x4_t a) {
+  return (a + 23) * 12;
+  }

nit: only indent 2 spaces, like the others.



Comment at: clang/docs/LanguageExtensions.rst:562
+
+The matrix type extension supports explicit casts. The casts we support are 
C-style casts in C and C++ and
+static casts. Implicit type conversion between matrix types is not allowed.

Maybe just say that explicit conversions are supported, without going into the 
specific types of casts?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104198

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

[PATCH] D97297: [clang-tidy] Suppress reports to patternedly named parameters in 'bugprone-easily-swappable-parameters'

[Whisperity via Phabricator via cfe-commits]

whisperity updated this revision to Diff 354229.
whisperity added a comment.

**NC** Rebase and buildbot trigger.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97297

Files:
  clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.h
  
clang-tools-extra/docs/clang-tidy/checks/bugprone-easily-swappable-parameters.rst
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-ignore.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-implicit-qualifiers.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-implicits.c
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-implicits.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len3.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-prefixsuffixname.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-qualifiermixing.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-relatedness.c
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-relatedness.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters.c

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters.c
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters.c
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters.c
@@ -5,7 +5,8 @@
 // RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterTypeSuffixes, value: "bool;MyBool;struct U;MAKE_LOGICAL_TYPE(int)"}, \
 // RUN: {key: bugprone-easily-swappable-parameters.QualifiersMix, value: 0}, \
 // RUN: {key: bugprone-easily-swappable-parameters.ModelImplicitConversions, value: 0}, \
-// RUN: {key: bugprone-easily-swappable-parameters.SuppressParametersUsedTogether, value: 0} \
+// RUN: {key: bugprone-easily-swappable-parameters.SuppressParametersUsedTogether, value: 0}, \
+// RUN: {key: bugprone-easily-swappable-parameters.NamePrefixSuffixSilenceDissimilarityTreshold, value: 0} \
 // RUN:  ]}' -- -x c
 
 #define bool _Bool
Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-relatedness.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-relatedness.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-relatedness.cpp
@@ -5,7 +5,8 @@
 // RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterTypeSuffixes, value: ""}, \
 // RUN: {key: bugprone-easily-swappable-parameters.QualifiersMix, value: 0}, \
 // RUN: {key: bugprone-easily-swappable-parameters.ModelImplicitConversions, value: 0}, \
-// RUN: {key: bugprone-easily-swappable-parameters.SuppressParametersUsedTogether, value: 1} \
+// RUN: {key: bugprone-easily-swappable-parameters.SuppressParametersUsedTogether, value: 1}, \
+// RUN: {key: bugprone-easily-swappable-parameters.NamePrefixSuffixSilenceDissimilarityTreshold, value: 0} \
 // RUN:  ]}' --
 
 namespace std {
Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-relatedness.c
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-relatedness.c
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-relatedness.c
@@ -5,7 +5,8 @@
 // RUN: {key: bugprone-easily-swappable-parameters.IgnoredParameterTypeSuffixes, value: ""}, \
 // RUN: {key: bugprone-easily-swappable-parameters.QualifiersMix, value: 0}, \
 // RUN: {key: bugprone-easily-swappable-parameters.ModelImplicitConversions, value: 0}, \
-// RUN: {key: bugprone-easily-swappable-parameters.SuppressParametersUsedTogether, value: 1} \
+// RUN: {key: bugprone-easily-swappable-parameters.SuppressParametersUsedTogether, value: 1}, \
+// RUN: {key: bugprone-easily-swappable-parameters.NamePrefixSuffixSilenceDissimilarityTreshold, value: 0} \
 // RUN:  ]}' -- -x c
 
 int myprint();
Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-qualifiermixing.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-qualifiermixing.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-qualifiermixing.cp

[PATCH] D104198: [Matrix] Add documentation for compound assignment and type conversion of matrix types

[Saurabh Jha via Phabricator via cfe-commits]

SaurabhJha added a comment.

Somehow the builds are failing even though this patch contains no code changes.




Comment at: clang/docs/LanguageExtensions.rst:526
 
+The matrix type extension also supports operations between a matrix and a 
scalar.
+

fhahn wrote:
> I'm not a native speaker, but I am not sure if `between` is the best choice 
> here. To me, `on` would sound slightly better, but again, I'm no expert.
I think you are right. Will change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104198

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

[PATCH] D104198: [Matrix] Add documentation for compound assignment and type conversion of matrix types

[Florian Hahn via Phabricator via cfe-commits]

fhahn added a comment.

In D104198#2838416 , @SaurabhJha 
wrote:

> Somehow the builds are failing even though this patch contains no code 
> changes.

There a few reasons as to why the tests may fail unrelated to the patch (flaky 
tests, infrastructure issues, test broken on main), so it is a good idea to 
check what is failing and why. In this case, it looks like a flaky test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104198

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

[PATCH] D104198: [Matrix] Add documentation for compound assignment and type conversion of matrix types

[Saurabh Jha via Phabricator via cfe-commits]

SaurabhJha updated this revision to Diff 354231.
SaurabhJha added a comment.

Address round 2 comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104198

Files:
  clang/docs/LanguageExtensions.rst


Index: clang/docs/LanguageExtensions.rst
===
--- clang/docs/LanguageExtensions.rst
+++ clang/docs/LanguageExtensions.rst
@@ -523,6 +523,63 @@
 return a + b * c;
   }
 
+The matrix type extension also supports operations on a matrix and a scalar.
+
+.. code-block:: c++
+
+  typedef float m4x4_t __attribute__((matrix_type(4, 4)));
+
+  m4x4_t f(m4x4_t a) {
+return (a + 23) * 12;
+  }
+
+The matrix type extension supports division on a matrix and a scalar but not 
on a matrix and a matrix.
+
+.. code-block:: c++
+  typedef float m4x4_t __attribute__((matrix_type(4, 4)));
+
+  m4x4_t f(m4x4_t a) {
+a = a / 3.0;
+return a;
+  }
+
+The matrix type extension supports compound assignments for addition, 
subtraction, and multiplication between matrices
+and between a matrix and a scalar, provided their types are consistent.
+
+.. code-block:: c++
+
+  typedef float m4x4_t __attribute__((matrix_type(4, 4)));
+
+  m4x4_t f(m4x4_t a, m4x4_t b) {
+a += b;
+a -= b;
+a *= b;
+a += 23;
+a -= 12;
+return a;
+  }
+
+The matrix type extension supports explicit casts. Implicit type conversion 
between matrix types is not allowed.
+
+.. code-block:: c++
+
+  typedef int ix5x5 __attribute__((matrix_type(5, 5)));
+  typedef float fx5x5 __attribute__((matrix_type(5, 5)));
+
+  fx5x5 f1(ix5x5 i, fx5x5 f) {
+return (fx5x5) i;
+  }
+
+
+  template 
+  using matrix_4_4 = X __attribute__((matrix_type(4, 4)));
+
+  void f2() {
+matrix_5_5 d;
+matrix_5_5 i;
+i = (matrix_5_5)d;
+i = static_cast>(d);
+  }
 
 Half-Precision Floating Point
 =


Index: clang/docs/LanguageExtensions.rst
===
--- clang/docs/LanguageExtensions.rst
+++ clang/docs/LanguageExtensions.rst
@@ -523,6 +523,63 @@
 return a + b * c;
   }
 
+The matrix type extension also supports operations on a matrix and a scalar.
+
+.. code-block:: c++
+
+  typedef float m4x4_t __attribute__((matrix_type(4, 4)));
+
+  m4x4_t f(m4x4_t a) {
+return (a + 23) * 12;
+  }
+
+The matrix type extension supports division on a matrix and a scalar but not on a matrix and a matrix.
+
+.. code-block:: c++
+  typedef float m4x4_t __attribute__((matrix_type(4, 4)));
+
+  m4x4_t f(m4x4_t a) {
+a = a / 3.0;
+return a;
+  }
+
+The matrix type extension supports compound assignments for addition, subtraction, and multiplication between matrices
+and between a matrix and a scalar, provided their types are consistent.
+
+.. code-block:: c++
+
+  typedef float m4x4_t __attribute__((matrix_type(4, 4)));
+
+  m4x4_t f(m4x4_t a, m4x4_t b) {
+a += b;
+a -= b;
+a *= b;
+a += 23;
+a -= 12;
+return a;
+  }
+
+The matrix type extension supports explicit casts. Implicit type conversion between matrix types is not allowed.
+
+.. code-block:: c++
+
+  typedef int ix5x5 __attribute__((matrix_type(5, 5)));
+  typedef float fx5x5 __attribute__((matrix_type(5, 5)));
+
+  fx5x5 f1(ix5x5 i, fx5x5 f) {
+return (fx5x5) i;
+  }
+
+
+  template 
+  using matrix_4_4 = X __attribute__((matrix_type(4, 4)));
+
+  void f2() {
+matrix_5_5 d;
+matrix_5_5 i;
+i = (matrix_5_5)d;
+i = static_cast>(d);
+  }
 
 Half-Precision Floating Point
 =
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D104198: [Matrix] Add documentation for compound assignment and type conversion of matrix types

[Saurabh Jha via Phabricator via cfe-commits]

SaurabhJha updated this revision to Diff 354232.
SaurabhJha added a comment.

Rebase with latest main


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104198

Files:
  clang/docs/LanguageExtensions.rst


Index: clang/docs/LanguageExtensions.rst
===
--- clang/docs/LanguageExtensions.rst
+++ clang/docs/LanguageExtensions.rst
@@ -523,6 +523,63 @@
 return a + b * c;
   }
 
+The matrix type extension also supports operations on a matrix and a scalar.
+
+.. code-block:: c++
+
+  typedef float m4x4_t __attribute__((matrix_type(4, 4)));
+
+  m4x4_t f(m4x4_t a) {
+return (a + 23) * 12;
+  }
+
+The matrix type extension supports division on a matrix and a scalar but not 
on a matrix and a matrix.
+
+.. code-block:: c++
+  typedef float m4x4_t __attribute__((matrix_type(4, 4)));
+
+  m4x4_t f(m4x4_t a) {
+a = a / 3.0;
+return a;
+  }
+
+The matrix type extension supports compound assignments for addition, 
subtraction, and multiplication between matrices
+and between a matrix and a scalar, provided their types are consistent.
+
+.. code-block:: c++
+
+  typedef float m4x4_t __attribute__((matrix_type(4, 4)));
+
+  m4x4_t f(m4x4_t a, m4x4_t b) {
+a += b;
+a -= b;
+a *= b;
+a += 23;
+a -= 12;
+return a;
+  }
+
+The matrix type extension supports explicit casts. Implicit type conversion 
between matrix types is not allowed.
+
+.. code-block:: c++
+
+  typedef int ix5x5 __attribute__((matrix_type(5, 5)));
+  typedef float fx5x5 __attribute__((matrix_type(5, 5)));
+
+  fx5x5 f1(ix5x5 i, fx5x5 f) {
+return (fx5x5) i;
+  }
+
+
+  template 
+  using matrix_4_4 = X __attribute__((matrix_type(4, 4)));
+
+  void f2() {
+matrix_5_5 d;
+matrix_5_5 i;
+i = (matrix_5_5)d;
+i = static_cast>(d);
+  }
 
 Half-Precision Floating Point
 =


Index: clang/docs/LanguageExtensions.rst
===
--- clang/docs/LanguageExtensions.rst
+++ clang/docs/LanguageExtensions.rst
@@ -523,6 +523,63 @@
 return a + b * c;
   }
 
+The matrix type extension also supports operations on a matrix and a scalar.
+
+.. code-block:: c++
+
+  typedef float m4x4_t __attribute__((matrix_type(4, 4)));
+
+  m4x4_t f(m4x4_t a) {
+return (a + 23) * 12;
+  }
+
+The matrix type extension supports division on a matrix and a scalar but not on a matrix and a matrix.
+
+.. code-block:: c++
+  typedef float m4x4_t __attribute__((matrix_type(4, 4)));
+
+  m4x4_t f(m4x4_t a) {
+a = a / 3.0;
+return a;
+  }
+
+The matrix type extension supports compound assignments for addition, subtraction, and multiplication between matrices
+and between a matrix and a scalar, provided their types are consistent.
+
+.. code-block:: c++
+
+  typedef float m4x4_t __attribute__((matrix_type(4, 4)));
+
+  m4x4_t f(m4x4_t a, m4x4_t b) {
+a += b;
+a -= b;
+a *= b;
+a += 23;
+a -= 12;
+return a;
+  }
+
+The matrix type extension supports explicit casts. Implicit type conversion between matrix types is not allowed.
+
+.. code-block:: c++
+
+  typedef int ix5x5 __attribute__((matrix_type(5, 5)));
+  typedef float fx5x5 __attribute__((matrix_type(5, 5)));
+
+  fx5x5 f1(ix5x5 i, fx5x5 f) {
+return (fx5x5) i;
+  }
+
+
+  template 
+  using matrix_4_4 = X __attribute__((matrix_type(4, 4)));
+
+  void f2() {
+matrix_5_5 d;
+matrix_5_5 i;
+i = (matrix_5_5)d;
+i = static_cast>(d);
+  }
 
 Half-Precision Floating Point
 =
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D104854: Introduce intrinsic llvm.isnan

[Serge Pavlov via Phabricator via cfe-commits]

sepavloff created this revision.
sepavloff added reviewers: efriedma, kpn, thopre, jonpa, cameron.mcinally, 
RKSimon, craig.topper.
Herald added subscribers: jdoerfert, pengfei, hiraditya.
sepavloff requested review of this revision.
Herald added projects: clang, LLVM.
Herald added a subscriber: cfe-commits.

Clang has builtin function '__builtin_isnan', which implements C
library function 'isnan'. This function now is implemented entirely in
clang codegen, which expands the function into set of IR operations.
There are three mechanisms by which the expansion can be made.

- The most common mechanism is using an unordered comparison made by 
instruction 'fcmp uno'. This simple solution is target-independent and works 
well in most cases. It however is not suitable if floating point exceptions are 
tracked. Corresponding IEEE 754 operation and C function must never raise FP 
exception, even if the argument is a signaling NaN. Compare instructions 
usually does not have such property, they raise 'invalid' exception in such 
case. So this mechanism is unsuitable when exception behavior is strict. In 
particular it could result in unexpected trapping if argument is SNaN.

- Another solution was implemented in https://reviews.llvm.org/D95948. It is 
used in the cases when raising FP exceptions by 'isnan' is not allowed. This 
solution implements 'isnan' using integer operations. It solves the problem of 
exceptions, but offers one solution for all targets, however some can do the 
check in more efficient way.

- Solution implemented by https://reviews.llvm.org/D96568 introduced a hook 
'clang::TargetCodeGenInfo::testFPKind', which injects target specific code into 
IR. Now only SystemZ implements this hook and it generates a call to target 
specific intrinsic function.

Although these mechanisms allow to implement 'isnan' with enough
efficiency, expanding 'isnan' in clang has drawbacks:

- The operation 'isnan' is hidden behind generic integer operations or 
target-specific intrinsics. It complicates analysis and can prevent some 
optimizations.

- IR can be created by tools other than clang, in this case treatment of 
'isnan' has to be duplicated in that tool.

Another issue with the current implementation of 'isnan' comes from the
use of options '-ffast-math' or '-fno-honor-nans'. If such option is
specified, 'fcmp uno' may be optimized to 'false'. It is valid
optimization in general, but it results in 'isnan' always returning
'false'. For example, in some libc++ implementations the following code
returns 'false':

  std::isnan(std::numeric_limits::quiet_NaN())

The options '-ffast-math' and '-fno-honor-nans' imply that FP operation
operands are never NaNs. This assumption however should not be applied
to the functions that check FP number properties, including 'isnan'. If
such function returns expected result instead of actually making
checks, it becomes useless in many cases. The option '-ffast-math' is
often used for performance critical code, as it can speed up execution
by the expense of manual treatment of corner cases. If 'isnan' returns
assumed result, a user cannot use it in the manual treatment of NaNs
and has to invent replacements, like making the check using integer
operations. There is a discussion in https://reviews.llvm.org/D18513#387418,
which also expresses the opinion, that limitations imposed by
'-ffast-math' should be applied only to 'math' functions but not to
'tests'.

To overcome these drawbacks, this change introduces a new IR intrinsic
function 'llvm.isnan', which realises the check as specified by IEEE-754
and C standards in target-agnostic way. During IR transformations it
does not undergo undesirable optimizations. It reaches instruction
selection, where is lowered in target-dependent way. The lowering can
vary depending on options like '-ffast-math' or '-ffp-model' so the
resulting code satisfies requested semantics.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104854

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/X86/strictfp_builtins.c
  clang/test/CodeGen/aarch64-strictfp-builtins.c
  clang/test/CodeGen/strictfp_builtins.c
  llvm/docs/LangRef.rst
  llvm/include/llvm/CodeGen/ISDOpcodes.h
  llvm/include/llvm/CodeGen/TargetLowering.h
  llvm/include/llvm/IR/Intrinsics.td
  llvm/lib/Analysis/ConstantFolding.cpp
  llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp
  llvm/lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp
  llvm/lib/CodeGen/SelectionDAG/LegalizeTypes.h
  llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp
  llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
  llvm/lib/CodeGen/SelectionDAG/SelectionDAGDumper.cpp
  llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp
  llvm/lib/CodeGen/TargetLoweringBase.cpp
  llvm/lib/Target/X86/X86ISelLowering.cpp
  llvm/test/CodeGen/AArch64/aarch64-fpclass.ll
  llvm/test/CodeGen/X86/x86-fpclass.ll
  llvm/test/Transforms/InstSimplify/ConstProp/fpclassify.ll

Index: llvm/test/Transforms/InstSimplify/Co

[PATCH] D97204: [RFC] Clang 64-bit source locations

[Simon Tatham via Phabricator via cfe-commits]

simon_tatham added a comment.

Hmmm. Two people have pointed out to me that my strategy of having a 32-bit 
`SourceLocations::LowBits` and an 0- or 32-bit 
`SourceLocations::OptionalHighBits` doesn't actually work, because an empty 
struct still takes at least 1 byte. So this version of the patch will still 
increase memory usage in the 32SL configuration, which is just what I was 
trying to avoid. Whoops.

@rsmith, do you have any thoughts on what would be an acceptable replacement 
strategy? You mentioned wanting to avoid actual #ifdefs all over the AST class 
hierarchy. Some possible alternatives:

We could define a family of macros: one for declaring a possible-SourceLocation 
in a branch of the Stmt bitfields union, one for declaring the same 
SourceLocation in a particular Stmt subclass, and a pair for the accessor 
functions that read and write whichever of those exists. Then there'd be 
slightly ugly macro calls all over Stmt.h and friends, but only one outright 
#ifdef, where the macros are defined.

(And then there are two options for how to define the macros in the 64SL case: 
either move the whole SourceLocation into the subclasses for speed, or keep 
half of it in the bitfields as now, for space. But that decision could be 
localized into the macro definitions, and easily changed.)

Alternatively, @miyuki suggests that my SourceLocation::OptionalHighBits could 
become an extra base class of some of the Stmt subclasses, so that empty base 
optimization //would// allow it to take up 0 bytes in the 32SL configuration.

The macro approach is the kind of thing I wouldn't mind doing in my own 
projects, but then, I have a strong stomach for macros :-) and I'd rather check 
before I do all the work to rewrite this patch in one of those styles, only to 
find out that you'd prefer another, or something I haven't even thought of.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97204

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

[PATCH] D104854: Introduce intrinsic llvm.isnan

[Thomas Preud'homme via Phabricator via cfe-commits]

thopre added a comment.

Are you planning to do this for the other FP test builtin (isinf, isfinite, 
isinf_sign, isnormal)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104854

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

[PATCH] D104616: [analyzer][WIP] Model comparision methods of std::unique_ptr

[Deep Majumder via Phabricator via cfe-commits]

RedDocMD added a comment.

In D104616#2835061 , @xazax.hun wrote:

> In D104616#2835030 , @RedDocMD 
> wrote:
>
>> Looks like I have wasted a good deal of effort. :(
>
> Sorry about that! :( If we learned anything new in the process it was not 
> wasted effort though.

I know what I learnt - if I am writing too much code, there is probably a 
function to that. :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104616

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

[PATCH] D104854: Introduce intrinsic llvm.isnan

[Serge Pavlov via Phabricator via cfe-commits]

sepavloff added a comment.

In D104854#2838468 , @thopre wrote:

> Are you planning to do this for the other FP test builtin (isinf, isfinite, 
> isinf_sign, isnormal)?

Yes, they have similar problems. 
If someone would like to implement them it would be nice.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104854

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

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

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia accepted this revision.
Anastasia added a comment.

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] D104198: [Matrix] Add documentation for compound assignment and type conversion of matrix types

[Florian Hahn via Phabricator via cfe-commits]

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

LGTM,thanks.




Comment at: clang/docs/LanguageExtensions.rst:546
+
+The matrix type extension supports compound assignments for addition, 
subtraction, and multiplication between matrices
+and between a matrix and a scalar, provided their types are consistent.

nit: also change to `on` instead of `between` for consistency?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104198

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

[PATCH] D93525: [clang-offload-bundler] Add unbundling of archives containing bundled object files into device specific archives

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl accepted this revision.
yaxunl added a comment.

LGTM. Thanks! Pls make sure it passes internal CI (ePSDB) before committing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93525

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

[PATCH] D93525: [clang-offload-bundler] Add unbundling of archives containing bundled object files into device specific archives

[Saiyedul Islam via Phabricator via cfe-commits]

saiislam added a comment.

In D93525#2838535 , @yaxunl wrote:

> LGTM. Thanks! Pls make sure it passes internal CI (ePSDB) before committing.

Sure, I will take care of it. Thanks!

Any comments @jdoerfert ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93525

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

[PATCH] D104198: [Matrix] Add documentation for compound assignment and type conversion of matrix types

[Saurabh Jha via Phabricator via cfe-commits]

SaurabhJha added a comment.

Thanks, the build is also passing now so I will land this in a bit.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104198

___
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.

In D104797#2837417 , @tlively wrote:

> 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.

Which 'ongoing project' is this and how can I obtain more information about it? 
Who's leading it?
Before the crashing, the only place we seem to touch the Wasm backend is in 
`WebAssemblyDAGToDAGISel::runOnMachineFunction`. Then this calls 
`SelectionDAGISel::runOnMachineFunction`, which visits each node in the 
Function and crashes when trying to call `getPtrExtOrTrunc` because it cannot 
create a `TRUNCATE` node for a zero sized type. So, if you prefer to have a 
`report_fatal_error` in the WebAssembly backend, we will need to visit the 
nodes in the function in `WebAssemblyDAGToDAGISel::runOnMachineFunction` before 
calling the generic `runOnMachineFunction`. I will look at how to proceed in 
this direction, but I am also interested in following this project on removing 
type information from pointers in LLVM, so any refs would be great. Thanks.


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

[clang] cd256c8 - Add documentation for compound assignment and type conversion of matrix types

[Saurabh Jha via cfe-commits]

Author: Saurabh Jha
Date: 2021-06-24T15:50:58+01:00
New Revision: cd256c8bcc9723f0ce7a32957f26600c966fa07c

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

LOG: Add documentation for compound assignment and type conversion of matrix 
types

Added: 


Modified: 
clang/docs/LanguageExtensions.rst

Removed: 




diff  --git a/clang/docs/LanguageExtensions.rst 
b/clang/docs/LanguageExtensions.rst
index c60b8b39e1c9e..f9e1208634b91 100644
--- a/clang/docs/LanguageExtensions.rst
+++ b/clang/docs/LanguageExtensions.rst
@@ -523,6 +523,63 @@ float matrices and add the result to a third 4x4 matrix.
 return a + b * c;
   }
 
+The matrix type extension also supports operations on a matrix and a scalar.
+
+.. code-block:: c++
+
+  typedef float m4x4_t __attribute__((matrix_type(4, 4)));
+
+  m4x4_t f(m4x4_t a) {
+return (a + 23) * 12;
+  }
+
+The matrix type extension supports division on a matrix and a scalar but not 
on a matrix and a matrix.
+
+.. code-block:: c++
+  typedef float m4x4_t __attribute__((matrix_type(4, 4)));
+
+  m4x4_t f(m4x4_t a) {
+a = a / 3.0;
+return a;
+  }
+
+The matrix type extension supports compound assignments for addition, 
subtraction, and multiplication between matrices
+and between a matrix and a scalar, provided their types are consistent.
+
+.. code-block:: c++
+
+  typedef float m4x4_t __attribute__((matrix_type(4, 4)));
+
+  m4x4_t f(m4x4_t a, m4x4_t b) {
+a += b;
+a -= b;
+a *= b;
+a += 23;
+a -= 12;
+return a;
+  }
+
+The matrix type extension supports explicit casts. Implicit type conversion 
between matrix types is not allowed.
+
+.. code-block:: c++
+
+  typedef int ix5x5 __attribute__((matrix_type(5, 5)));
+  typedef float fx5x5 __attribute__((matrix_type(5, 5)));
+
+  fx5x5 f1(ix5x5 i, fx5x5 f) {
+return (fx5x5) i;
+  }
+
+
+  template 
+  using matrix_4_4 = X __attribute__((matrix_type(4, 4)));
+
+  void f2() {
+matrix_5_5 d;
+matrix_5_5 i;
+i = (matrix_5_5)d;
+i = static_cast>(d);
+  }
 
 Half-Precision Floating Point
 =



___
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 subscriber: aeubanks.
tlively added a comment.

The opaque pointers project is documented here: 
https://llvm.org/docs/OpaquePointers.html. It's been making very slow progress 
for the past few years but has recently been picking up steam under the 
direction of @aeubanks. Search llvm-dev for "opaque pointers" and you will see 
a few recent threads about it.


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] D104198: [Matrix] Add documentation for compound assignment and type conversion of matrix types

[Saurabh Jha via Phabricator via cfe-commits]

SaurabhJha added a comment.

Sorry, I committed this without the `Differential Revision: 
https://reviews.llvm.org/D104198` line. Is there a way to change the commit 
message after it is in main? I could not push after `git commit --amend`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104198

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

[PATCH] D104854: Introduce intrinsic llvm.isnan

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a comment.

In D104854#2838495 , @sepavloff wrote:

> In D104854#2838468 , @thopre wrote:
>
>> Are you planning to do this for the other FP test builtin (isinf, isfinite, 
>> isinf_sign, isnormal)?
>
> Yes, they have similar problems. 
> If someone would like to implement them it would be nice.

From a user perspective, it seems sub-optimal to postpone the others "untile 
someone wants to implement them".
Once `isnan` behaves differently than the rest, I can see users being confused 
and rightfully so.
I don't have a strong opinion but I'd prefer we switch them over together.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104854

___
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.

In D104797#2838653 , @tlively wrote:

> The opaque pointers project is documented here: 
> https://llvm.org/docs/OpaquePointers.html. It's been making very slow 
> progress for the past few years but has recently been picking up steam under 
> the direction of @aeubanks. Search llvm-dev for "opaque pointers" and you 
> will see a few recent threads about it.

Thanks for this.


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] D104844: [Analyzer][solver] Fix crashes during symbol simplification

[Gabor Marton via Phabricator via cfe-commits]

martong added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:2314-2315
 
+  if (SymbolRef SimplifiedSym = simplify(St, Sym))
+Sym = SimplifiedSym;
+

vsavchenko wrote:
> I don't like the idea of duplicating it into every `assume` method.  This way 
> we drastically increase our chances to forget it (like you did with 
> `assumeSymGE` and `assumeSymLE`).
> I think the better place for it is in `RangedConstraintManager::assumeSymRel` 
> and neighboring methods, though still not perfect.
> I don't really get why we get not simplified symbol to begin with.
> 
`assumeSymRel` is not enough, because e.g. `assumeSymGE` is called also e.g. 
from `assumeSymUnsupported`. Perhaps we could change the signature of 
`assumeSymEQ/NE/GT/GE/LT/LE` to take an auxiliary `Simplifier` wrapper object 
instead of `SymbolRef`?

```
  ProgramStateRef assumeSymNE(ProgramStateRef State, Simplifier S,
  const llvm::APSInt &V,
  const llvm::APSInt &Adjustment);

```
And for the Simplifier something like:
```
struct Simplifier {
  SymbolRef SimplifiedSym = nullptr;
  Simplifier(SymbolRef Sym) : SimplifiedSym(simplify(Sym)) {}
  
};
```



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104844

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

[PATCH] D104198: [Matrix] Add documentation for compound assignment and type conversion of matrix types

[Florian Hahn via Phabricator via cfe-commits]

fhahn added a comment.

In D104198#2838658 , @SaurabhJha 
wrote:

> Sorry, I committed this without the `Differential Revision: 
> https://reviews.llvm.org/D104198` line. Is there a way to change the commit 
> message after it is in main? I could not push after `git commit --amend`

There's no way to adjust an already pushed commit (force pushes are blocked). 
You could either revert the change and re-commit with the updated wording or 
you could manually close the revision here. If the rest of the commit message 
is OK, I'd recommend just closing the revision manually and provide a link to 
the commit.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104198

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

[PATCH] D90399: [clang-tidy] non-portable-integer-constant check

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

steakhal added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/NonportableintegerconstantCheck.cpp:54
+
+MaskStr = StringRef(MaskStr.lower());
+if (!MaskStr.consume_front("0x"))

You are assigning a pointer to a temporal std::string. It will dangle.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/NonportableintegerconstantCheck.cpp:58
+
+MaskStr = MaskStr.take_while(llvm::isHexDigit);
+

There could be digit separator apostrophes. E.g.: `0x44'4'4`.


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

https://reviews.llvm.org/D90399

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

[PATCH] D104198: [Matrix] Add documentation for compound assignment and type conversion of matrix types

[Saurabh Jha via Phabricator via cfe-commits]

SaurabhJha added a comment.

In D104198#2838665 , @fhahn wrote:

> In D104198#2838658 , @SaurabhJha 
> wrote:
>
>> Sorry, I committed this without the `Differential Revision: 
>> https://reviews.llvm.org/D104198` line. Is there a way to change the commit 
>> message after it is in main? I could not push after `git commit --amend`
>
> There's no way to adjust an already pushed commit (force pushes are blocked). 
> You could either revert the change and re-commit with the updated wording or 
> you could manually close the revision here. If the rest of the commit message 
> is OK, I'd recommend just closing the revision manually and provide a link to 
> the commit.

Okay thanks, I will do the latter.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104198

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

[PATCH] D104198: [Matrix] Add documentation for compound assignment and type conversion of matrix types

[Saurabh Jha via Phabricator via cfe-commits]

SaurabhJha closed this revision.
SaurabhJha added a comment.

This is closed by this commit 
https://github.com/llvm/llvm-project/commit/cd256c8bcc9723f0ce7a32957f26600c966fa07c


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104198

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

[PATCH] D104844: [Analyzer][solver] Fix crashes during symbol simplification

[Gabor Marton via Phabricator via cfe-commits]

martong added a comment.

> I don't really get why we get not simplified symbol to begin with.

This is because of the Environment bindings. I.e.` b1` is bound to `$a0 - $b0 + 
$c` when we evaluate `int b1 = (unsigned)a1 + c;`. This binding is not 
changed/updated, so when we evaluate the division then we query the DeclRefExpr 
for `b1` from the Environment and that gives still `$a0 - $b0 + $c`. We either 
do the simplification in the ConstraintManager (as we do now with this and the 
parent patch) or perhaps we could try to simplify the Environment bindings as 
an alternative solution.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104844

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

[PATCH] D104844: [Analyzer][solver] Fix crashes during symbol simplification

[Valeriy Savchenko via Phabricator via cfe-commits]

vsavchenko added a comment.

In D104844#2838674 , @martong wrote:

>> I don't really get why we get not simplified symbol to begin with.
>
> This is because of the Environment bindings. I.e.` b1` is bound to `$a0 - $b0 
> + $c` when we evaluate `int b1 = (unsigned)a1 + c;`. This binding is not 
> changed/updated, so when we evaluate the division then we query the 
> DeclRefExpr for `b1` from the Environment and that gives still `$a0 - $b0 + 
> $c`. We either do the simplification in the ConstraintManager (as we do now 
> with this and the parent patch) or perhaps we could try to simplify the 
> Environment bindings as an alternative solution.

Yeah, I remember now, thanks!




Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:2314-2315
 
+  if (SymbolRef SimplifiedSym = simplify(St, Sym))
+Sym = SimplifiedSym;
+

martong wrote:
> vsavchenko wrote:
> > I don't like the idea of duplicating it into every `assume` method.  This 
> > way we drastically increase our chances to forget it (like you did with 
> > `assumeSymGE` and `assumeSymLE`).
> > I think the better place for it is in 
> > `RangedConstraintManager::assumeSymRel` and neighboring methods, though 
> > still not perfect.
> > I don't really get why we get not simplified symbol to begin with.
> > 
> `assumeSymRel` is not enough, because e.g. `assumeSymGE` is called also e.g. 
> from `assumeSymUnsupported`. Perhaps we could change the signature of 
> `assumeSymEQ/NE/GT/GE/LT/LE` to take an auxiliary `Simplifier` wrapper object 
> instead of `SymbolRef`?
> 
> ```
>   ProgramStateRef assumeSymNE(ProgramStateRef State, Simplifier S,
>   const llvm::APSInt &V,
>   const llvm::APSInt &Adjustment);
> 
> ```
> And for the Simplifier something like:
> ```
> struct Simplifier {
>   SymbolRef SimplifiedSym = nullptr;
>   Simplifier(SymbolRef Sym) : SimplifiedSym(simplify(Sym)) {}
>   
> };
> ```
> 
> assumeSymRel is not enough, because e.g. assumeSymGE is called also e.g. from 
> assumeSymUnsupported. 
Yep, that's why I suggested `assumeSymRel` and its neighbors.  I actually think 
that three top-level public methods from `RangedConstraintManager` will do: 
`assumeSym`, `assumeSymInclusiveRange`, and `assumeSymUnsupported`.


We can't really change the signatures of those methods because we'll be 
introducing this functionality into solvers that didn't sign up for this (and 
don't need it).

Also we can least put this `if` statement inside of `simplify`, so we can use 
it like this: `Sym = simplify(St, Sym);`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104844

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

[PATCH] D104854: Introduce intrinsic llvm.isnan

[Serge Pavlov via Phabricator via cfe-commits]

sepavloff added a comment.

In D104854#2838659 , @jdoerfert wrote:

> In D104854#2838495 , @sepavloff 
> wrote:
>
>> In D104854#2838468 , @thopre wrote:
>>
>>> Are you planning to do this for the other FP test builtin (isinf, isfinite, 
>>> isinf_sign, isnormal)?
>>
>> Yes, they have similar problems. 
>> If someone would like to implement them it would be nice.
>
> From a user perspective, it seems sub-optimal to postpone the others "untile 
> someone wants to implement them".
> Once `isnan` behaves differently than the rest, I can see users being 
> confused and rightfully so.
> I don't have a strong opinion but I'd prefer we switch them over together.

Sure. I Just want to say that if someone wants or has plans to implement these 
functions, I appreciate these efforts. This functionality is in my plans. 
Considering only one function in this patch must facilitatу the review process.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104854

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

[PATCH] D93525: [clang-offload-bundler] Add unbundling of archives containing bundled object files into device specific archives

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert accepted this revision.
jdoerfert added a comment.

Looks reasonable to me. We can always refine it as we go.




Comment at: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp:137
+///  * GPUArch (Optional) - Processor name, like gfx906 or sm_30
+/// In presence of Proc, the Triple should contain separator "-" for all
+/// standard four components, even if they are empty.





Comment at: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp:1263
+
+  assert(!ArchiveErr);
+

Add a message to asserts. also other places.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93525

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

[PATCH] D104854: Introduce intrinsic llvm.isnan

[Craig Topper via Phabricator via cfe-commits]

craig.topper added a comment.

Doesn't gcc also fold isnan to false under fast math? If we diverge here that 
means your code would only work correctly with clang.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104854

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

[PATCH] D102507: [HIP] Support in device code

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

In D102507#2833594 , @ldionne wrote:

> In D102507#2830688 , @yaxunl wrote:
>
>> In D102507#2792087 , @rsmith wrote:
>>
>>> @ldionne How should we go about establishing whether libc++ would be 
>>> prepared to officially support CUDA? Right now, Clang's CUDA support is 
>>> patching in attributes onto libc++ functions from the outside, which 
>>> doesn't seem like a sustainable model.
>>
>> ping
>
> If the current approach is to patch libc++ from the outside, then yeah, 
> that's most definitely not a great design IMO. It's going to be very brittle. 
> I think it *may* be reasonable to support this in libc++, but I'd like to see 
> some sort of basic explanation of what the changes would be so we can have a 
> discussion and make our mind up about whether we can support this, and what's 
> the best way of doing it.

Thanks Louis. Please allow me to have a brief explanation about our plan to 
support libc++ for HIP device compilation.

HIP functions can have `__device__`, `__host__`, or `__device__ __host__` 
attributes, indicating the target of a function. `__device__` function can only 
be executed on device (GPU). `__host__` functions can only be executed on host. 
`__device__ __host__` functions can be executed on both device and host. By 
default (without explicit device/host attributes) a non-constexpr function is a 
host function, a constexpr function is `__device__ __host__` function. This 
also applies to member functions of class. Clang is able to resolve overloaded 
functions differing only by device/function attributes.

Currently libc++ functions are host functions by default, except constexpr 
functions. As such the non-constexpr libc++ functions can only be called by 
host functions in HIP programs. This is similar to C++ programs.

By supporting libc++ in HIP device compilation we mean "allowing libc++ 
functions to be executed on device in HIP programs". To achieve this we can 
take 3 approaches:

1. Many libc++ functions are generic regarding device or host, i.e., their code 
is common for device and host. For such functions we can make them `__device__ 
__host__` functions.

2. Some libc++ functions are mostly common for device or host with minor 
differences. For such functions, we can make them `__device__ __host__` and use 
`#if __HIP_DEVICE_COMPILE__` (indicating device compilation) for the minor 
difference in the function body.

3. Some libc++ functions have different implementations for device and host. We 
can leave these host functions as they are and adding overloaded `__device__` 
functions.

There are two ways to mark libc++ functions as `__device__ __host__`:

1. Define a macro which expands to empty for non-HIP programs and expands to 
`__device__ __host__` for HIP and add it to each libc++ function which is to be 
marked as `__device__ __host__`.

2. Define macros which expand to empty for non-HIP programs and expand to 
`#pragma clang force_cuda_host_device begin/end` for HIP and put them at the 
beginning and end of a file where all the functions are to be marked as 
`__device__ __host__`.

We plan to implement libc++ support in HIP device compilation in a progressive 
approach, header by header, and document the supported libc++ headers. We will 
prioritize libc++ headers to support based on 1) user requests 2) whether it 
has already been supported through clang wrapper headers (patching) 4) 
usefulness for device execution 3) availability of lower level support with HIP 
runtime.


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

https://reviews.llvm.org/D102507

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

[PATCH] D104844: [Analyzer][solver] Fix crashes during symbol simplification

[Gabor Marton via Phabricator via cfe-commits]

martong updated this revision to Diff 354274.
martong added a comment.

- Use simplify from RangedConstraintManager


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104844

Files:
  
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  clang/lib/StaticAnalyzer/Core/RangedConstraintManager.cpp
  clang/test/Analysis/solver-sym-simplification-no-crash.c
  clang/test/Analysis/solver-sym-simplification-with-proper-range-type.c

Index: clang/test/Analysis/solver-sym-simplification-with-proper-range-type.c
===
--- /dev/null
+++ clang/test/Analysis/solver-sym-simplification-with-proper-range-type.c
@@ -0,0 +1,29 @@
+// RUN: %clang_analyze_cc1 %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=debug.ExprInspection \
+// RUN:   -verify
+
+// Here we test that the range based solver equivalency tracking mechanism
+// assigns a properly typed range to the simplified symbol.
+
+void clang_analyzer_printState();
+void clang_analyzer_eval(int);
+
+void f(int a0, int b0, int c)
+{
+int a1 = a0 - b0;
+int b1 = (unsigned)a1 + c;
+if (c == 0) {
+
+int d = 7L / b1; // ...
+// At this point b1 is considered non-zero, which results in a new
+// constraint for $a0 - $b0 + $c. The type of this sym is unsigned,
+// however, the simplified sym is $a0 - $b0 and its type is signed.
+// This is probably the result of the inherent improper handling of
+// casts. Anyway, Range assignment for constraints use this type
+// information. Therefore, we must make sure that first we simplify the
+// symbol and only then we assign the range.
+
+clang_analyzer_eval(a0 - b0 != 0); // expected-warning{{TRUE}}
+}
+}
Index: clang/test/Analysis/solver-sym-simplification-no-crash.c
===
--- /dev/null
+++ clang/test/Analysis/solver-sym-simplification-no-crash.c
@@ -0,0 +1,26 @@
+// RUN: %clang_analyze_cc1 %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=debug.ExprInspection \
+// RUN:   -verify
+
+// Here, we test that symbol simplification in the solver does not produce any
+// crashes.
+
+// expected-no-diagnostics
+
+static int a, b;
+static long c;
+
+static void f(int i, int j)
+{
+(void)(j <= 0 && i ? i : j);
+}
+
+static void g(void)
+{
+int d = a - b | (c < 0);
+for (;;)
+{
+f(d ^ c, c);
+}
+}
Index: clang/lib/StaticAnalyzer/Core/RangedConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangedConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangedConstraintManager.cpp
@@ -23,12 +23,14 @@
 ProgramStateRef RangedConstraintManager::assumeSym(ProgramStateRef State,
SymbolRef Sym,
bool Assumption) {
+  Sym = simplify(State, Sym);
+
   // Handle SymbolData.
-  if (isa(Sym)) {
+  if (isa(Sym))
 return assumeSymUnsupported(State, Sym, Assumption);
 
-// Handle symbolic expression.
-  } else if (const SymIntExpr *SIE = dyn_cast(Sym)) {
+  // Handle symbolic expression.
+  if (const SymIntExpr *SIE = dyn_cast(Sym)) {
 // We can only simplify expressions whose RHS is an integer.
 
 BinaryOperator::Opcode op = SIE->getOpcode();
@@ -93,6 +95,9 @@
 ProgramStateRef RangedConstraintManager::assumeSymInclusiveRange(
 ProgramStateRef State, SymbolRef Sym, const llvm::APSInt &From,
 const llvm::APSInt &To, bool InRange) {
+
+  Sym = simplify(State, Sym);
+
   // Get the type used for calculating wraparound.
   BasicValueFactory &BVF = getBasicVals();
   APSIntType WraparoundType = BVF.getAPSIntType(Sym->getType());
@@ -121,6 +126,8 @@
 ProgramStateRef
 RangedConstraintManager::assumeSymUnsupported(ProgramStateRef State,
   SymbolRef Sym, bool Assumption) {
+  Sym = simplify(State, Sym);
+
   BasicValueFactory &BVF = getBasicVals();
   QualType T = Sym->getType();
 
@@ -219,5 +226,13 @@
   }
 }
 
+SymbolRef simplify(ProgramStateRef State, SymbolRef Sym) {
+  SValBuilder &SVB = State->getStateManager().getSValBuilder();
+  SVal SimplifiedVal = SVB.simplifySVal(State, SVB.makeSymbolVal(Sym));
+  if (SymbolRef SimplifiedSym = SimplifiedVal.getAsSymbol())
+return SimplifiedSym;
+  return Sym;
+}
+
 } // end of namespace ento
 } // end of namespace clang
Index: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -1389,12 +1389,6 @@
 //  Constraint manager implem

[PATCH] D104844: [Analyzer][solver] Fix crashes during symbol simplification

[Gabor Marton via Phabricator via cfe-commits]

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



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:2314-2315
 
+  if (SymbolRef SimplifiedSym = simplify(St, Sym))
+Sym = SimplifiedSym;
+

vsavchenko wrote:
> martong wrote:
> > vsavchenko wrote:
> > > I don't like the idea of duplicating it into every `assume` method.  This 
> > > way we drastically increase our chances to forget it (like you did with 
> > > `assumeSymGE` and `assumeSymLE`).
> > > I think the better place for it is in 
> > > `RangedConstraintManager::assumeSymRel` and neighboring methods, though 
> > > still not perfect.
> > > I don't really get why we get not simplified symbol to begin with.
> > > 
> > `assumeSymRel` is not enough, because e.g. `assumeSymGE` is called also 
> > e.g. from `assumeSymUnsupported`. Perhaps we could change the signature of 
> > `assumeSymEQ/NE/GT/GE/LT/LE` to take an auxiliary `Simplifier` wrapper 
> > object instead of `SymbolRef`?
> > 
> > ```
> >   ProgramStateRef assumeSymNE(ProgramStateRef State, Simplifier S,
> >   const llvm::APSInt &V,
> >   const llvm::APSInt &Adjustment);
> > 
> > ```
> > And for the Simplifier something like:
> > ```
> > struct Simplifier {
> >   SymbolRef SimplifiedSym = nullptr;
> >   Simplifier(SymbolRef Sym) : SimplifiedSym(simplify(Sym)) {}
> >   
> > };
> > ```
> > 
> > assumeSymRel is not enough, because e.g. assumeSymGE is called also e.g. 
> > from assumeSymUnsupported. 
> Yep, that's why I suggested `assumeSymRel` and its neighbors.  I actually 
> think that three top-level public methods from `RangedConstraintManager` will 
> do: `assumeSym`, `assumeSymInclusiveRange`, and `assumeSymUnsupported`.
> 
> 
> We can't really change the signatures of those methods because we'll be 
> introducing this functionality into solvers that didn't sign up for this (and 
> don't need it).
> 
> Also we can least put this `if` statement inside of `simplify`, so we can use 
> it like this: `Sym = simplify(St, Sym);`.
Okay, I've updated like so.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104844

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

[PATCH] D104844: [Analyzer][solver] Fix crashes during symbol simplification

[Valeriy Savchenko via Phabricator via cfe-commits]

vsavchenko added a comment.

Awesome, thanks for swiftly addressing it!




Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:1981
   for (const SymbolRef &MemberSym : ClassMembers) {
-SymbolRef SimplifiedMemberSym = ::simplify(State, MemberSym);
+SymbolRef SimplifiedMemberSym = ::clang::ento::simplify(State, MemberSym);
 if (SimplifiedMemberSym && MemberSym != SimplifiedMemberSym) {

Oof, and there is no way to avoid all these namespaces?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104844

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

[PATCH] D104550: [analyzer] Implement getType for SVal

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov added a comment.

I'm in favor of this patch. It will help simplify `SValBuilder::evalCast`, 
which takes an optional parameter `OriginalTy` and acts differently based on 
whether it has been passed or has not.

Since `sizeof(SVal)` became bigger (x1.5). I'm wondering of how much this 
reflects on memory consumption.

Another thing is that we can garantee returning `QualType`. I mean, we can 
replace `Optional` with `QualType` itself. `QualType` has a default ctor and 
`isNull` predicate, which is //true// when defaultly constructed.




Comment at: clang/lib/StaticAnalyzer/Core/SVals.cpp:154
+  Optional VisitLocGotoLabel(loc::GotoLabel GL) {
+return QualType{Context.VoidPtrTy};
+  }

I'm not sure this is a correct type. I would expect here something like: `class 
LabelType : public Type`.



Comment at: clang/unittests/StaticAnalyzer/SValTest.cpp:181-182
+void foo(int a, int b) {
+  int x = a;
+  int y = a + b;
+})") {

Add a cast case.



Comment at: clang/unittests/StaticAnalyzer/SValTest.cpp:190-192
+  SVal Y = getByName("y");
+  ASSERT_TRUE(Y.getType(Context).hasValue());
+  EXPECT_EQ(Int, *Y.getType(Context));




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104550

___
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 added a comment.

In D104831#2837712 , @MaskRay wrote:

>> 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.

Explicitly specifying target or configure the default build target would work. 
But I thought  the triple vector being updated is designed for automatic 
searching and minimizing configure changes across platforms. Is it not like 
that?

In D104831#2837795 , @tstellar wrote:

> 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.

One of our platforms is CentOS 7.


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] D104550: [analyzer] Implement getType for SVal

[Valeriy Savchenko via Phabricator via cfe-commits]

vsavchenko added a comment.

In D104550#2838827 , @ASDenysPetrov 
wrote:

> I'm in favor of this patch. It will help simplify `SValBuilder::evalCast`, 
> which takes an optional parameter `OriginalTy` and acts differently based on 
> whether it has been passed or has not.

@NoQ mentioned it before that it is always better to use direct types from AST. 
 But the only participant who doesn't have AST is the Store, and when it calls 
`evalCast` it doesn't have a way to get that type.  So, in this case this 
function van be pretty useful.

> Since `sizeof(SVal)` became bigger (x1.5). I'm wondering of how much this 
> reflects on memory consumption.

I'm not sure what you mean here.  If it is about this particular patch, it 
simply adds a non-virtual method to `SVal`, it shouldn't affect `sizeof(SVal)` 
at all.

> Another thing is that we can garantee returning `QualType`. I mean, we can 
> replace `Optional` with `QualType` itself. `QualType` has a default ctor and 
> `isNull` predicate, which is //true// when defaultly constructed.

I wanted to be more explicit here and convey to the user that the lack of type 
is normal.  I can change that, it won't be a problem at all.  @NoQ, @Szelethus 
what do you think?




Comment at: clang/lib/StaticAnalyzer/Core/SVals.cpp:154
+  Optional VisitLocGotoLabel(loc::GotoLabel GL) {
+return QualType{Context.VoidPtrTy};
+  }

ASDenysPetrov wrote:
> I'm not sure this is a correct type. I would expect here something like: 
> `class LabelType : public Type`.
I don't think that I fully understood what you suggest here.  Do you suggest to 
add a new type to `Type.h`?



Comment at: clang/unittests/StaticAnalyzer/SValTest.cpp:181-182
+void foo(int a, int b) {
+  int x = a;
+  int y = a + b;
+})") {

ASDenysPetrov wrote:
> Add a cast case.
Sure!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104550

___
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.

In D104831#2838835 , @hoy wrote:

> In D104831#2837712 , @MaskRay wrote:
>
>>> 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.
>
> Explicitly specifying target or configure the default build target would 
> work. But I thought  the triple vector being updated is designed for 
> automatic searching and minimizing configure changes across platforms. Is it 
> not like that?

I am not sure about this guarantee. The list could be endless long if we 
supported every platform.

The right fix is to configure llvm-project with a correct 
`LLVM_DEFAULT_TARGET_TRIPLE`.

> In D104831#2837795 , @tstellar 
> wrote:
>
>> 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.
>
> One of our platforms is CentOS 7.




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] D104381: [analyzer] Added a test case for PR46264

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

I bisected. This bug was fixed intentionally by D85817 
, forgot to close I guess.


Repository:
  rG LLVM Github Monorepo

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] D104854: Introduce intrinsic llvm.isnan

[Serge Pavlov via Phabricator via cfe-commits]

sepavloff added a comment.

In D104854#2838754 , @craig.topper 
wrote:

> Doesn't gcc also fold isnan to false under fast math? If we diverge here that 
> means your code would only work correctly with clang.

GCC does the same transformation, ICC and MSVC do not: 
https://godbolt.org/z/ovboWqPeb. Both clang and GCC do this transformation only 
with optimization level > 0. With -O0 both produce code that does real check, 
so semantic of the produced code is different depending on optimization level, 
it looks more like a bug rather than feature.

There is a GCC ticket: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84949, 
which refers to the similar thing. It is created against to libstdc++ but the 
reason is in the compiler. In one on the comments there 
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84949#c8) an opinion is expressed:

  ... My conclusion: std::numeric_limits means "has NaN bitpattern" and "has 
IEC559 bit layout" not "has NaNs with NaN behavior" and "has IEC559 behavior".

So this behavior is considered as incorrect.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104854

___
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

[Aakanksha Patil via Phabricator via cfe-commits]

aakanksha555 updated this revision to Diff 354270.
aakanksha555 marked 4 inline comments as done.
aakanksha555 added a comment.

Addressed feedback; fixed typo and missing check lines.


Repository:
  rG LLVM Github Monorepo

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

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 --match-full-lines -DABI_VERSION=0 -DFILE=%t -DFLAG_0="EF_AMDGPU_FEATURE_XNACK_V3 (0x100)" -DFLAG_1="EF_AMDGPU_MACH_AMDGCN_GFX90A (0x3F)" -DFLAG_VALUE=0x13F
Index: llvm/test/tools/llvm-objdump/ELF/AMDGPU/subtarget.ll
==

[PATCH] D104804: [AMDGPU] Add gfx1035 target

[Jay Foad via Phabricator via cfe-commits]

foad added a comment.

Looks OK. Have you run check-llvm and check-clang?


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] D103612: [flang][driver] Add `-funparse-typed-exprs-as-fortran`

[Andrzej Warzynski via Phabricator via cfe-commits]

awarzynski updated this revision to Diff 354294.
awarzynski added a subscriber: PeteSteinfeld.
awarzynski added a comment.

Rename the new flag as `-fno-analyzed-objects-for-unparse`

Based on the discussion, I've renamed the flag to better reflect the intention. 
Does it make more sense now?

Note, the default behaviour of the drivers does not change with this patch 
(i.e. `{f18|flang-new} -fdebug-unparse` will generate identical results 
_before_ and _after_).

@klousler & @PeteSteinfeld, many thanks for all the feedback!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103612

Files:
  clang/include/clang/Driver/Options.td
  flang/include/flang/Frontend/CompilerInvocation.h
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/Frontend/FrontendActions.cpp
  flang/lib/Frontend/FrontendOptions.cpp
  flang/test/Driver/driver-help.f90
  flang/test/Driver/unparse-use-analyzed.f95
  flang/tools/f18/f18.cpp
  flang/tools/f18/flang

Index: flang/tools/f18/flang
===
--- flang/tools/f18/flang
+++ flang/tools/f18/flang
@@ -8,7 +8,7 @@
 #======#
 
 wd=$(cd $(dirname "$0")/.. && pwd)
-opts="-module-suffix .f18.mod "
+opts="-fno-analyzed-objects-for-unparse -module-suffix .f18.mod "
 if ! $wd/bin/f18 $opts "$@"
 then status=$?
  echo flang: in $PWD, f18 failed with exit status $status: $wd/bin/f18 $opts "$@" >&2
Index: flang/tools/f18/f18.cpp
===
--- flang/tools/f18/f18.cpp
+++ flang/tools/f18/f18.cpp
@@ -105,7 +105,7 @@
   bool debugModuleWriter{false};
   bool defaultReal8{false};
   bool measureTree{false};
-  bool unparseTypedExprsToF18_FC{false};
+  bool useAnalyzedObjectsForUnparse{true};
   std::vector F18_FCArgs;
   const char *prefix{nullptr};
   bool getDefinition{false};
@@ -322,7 +322,8 @@
 Unparse(llvm::outs(), parseTree, driver.encoding, true /*capitalize*/,
 options.features.IsEnabled(
 Fortran::common::LanguageFeature::BackslashEscapes),
-nullptr /* action before each statement */, &asFortran);
+nullptr /* action before each statement */,
+driver.useAnalyzedObjectsForUnparse ? &asFortran : nullptr);
 return {};
   }
   if (driver.dumpPreFirTree) {
@@ -353,7 +354,7 @@
 options.features.IsEnabled(
 Fortran::common::LanguageFeature::BackslashEscapes),
 nullptr /* action before each statement */,
-driver.unparseTypedExprsToF18_FC ? &asFortran : nullptr);
+driver.useAnalyzedObjectsForUnparse ? &asFortran : nullptr);
   }
 
   RunOtherCompiler(driver, tmpSourcePath.data(), relo.data());
@@ -578,8 +579,8 @@
 } else if (arg == "-funparse-with-symbols" ||
 arg == "-fdebug-unparse-with-symbols") {
   driver.dumpUnparseWithSymbols = true;
-} else if (arg == "-funparse-typed-exprs-to-f18-fc") {
-  driver.unparseTypedExprsToF18_FC = true;
+} else if (arg == "-fno-analyzed-objects-for-unparse") {
+  driver.useAnalyzedObjectsForUnparse = false;
 } else if (arg == "-fparse-only" || arg == "-fsyntax-only") {
   driver.syntaxOnly = true;
 } else if (arg == "-c") {
Index: flang/test/Driver/unparse-use-analyzed.f95
===
--- /dev/null
+++ flang/test/Driver/unparse-use-analyzed.f95
@@ -0,0 +1,31 @@
+! Tests `-fno-analyzed-exprs-as-fortran` frontend option
+
+!--
+! RUN lines
+!--
+! RUN: %flang_fc1 -fdebug-unparse  %s | FileCheck %s --check-prefix=DEFAULT
+! RUN: %flang_fc1 -fdebug-unparse -fno-analyzed-objects-for-unparse %s | FileCheck %s --check-prefix=DISABLED
+
+!
+! EXPECTED OUTPUT: default - use analyzed objects
+!
+! DEFAULT: PROGRAM test
+! DEFAULT-NEXT:  REAL, PARAMETER :: val = 3.43e2_4
+! DEFAULT-NEXT:  PRINT *, 3.47e2_4
+! DEFAULT-NEXT: END PROGRAM
+
+!---
+! EXPECTED OUTPUT: disabled - don't use the analyzed objects
+!---
+! DISABLED: PROGRAM test
+! DISABLED-NEXT:  REAL, PARAMETER :: val = 343.0
+! DISABLED-NEXT:  PRINT *, val+4
+! DISABLED-NEXT: END PROGRAM
+
+!--
+! INPUT
+!--
+program test
+  real, parameter :: val = 343.0
+  print *, val + 4
+end program
Index: flang/test/Driver/driver-help.f90
===
--- flang/test/Driver/driver-help.f90
+++ flang/test/Driver/driver-help.f90
@@ -101,6 +101,8 @@
 ! HELP-FC1-NEXT:Specify where to find the compiled intrinsic modules
 ! HELP-FC1-NEXT: -flarge-sizes  Use INTEGER(KIND=8) for the result

[PATCH] D104804: [AMDGPU] Add gfx1035 target

[Aakanksha Patil via Phabricator via cfe-commits]

aakanksha555 added a comment.

In D104804#2838883 , @foad wrote:

> Looks OK. Have you run check-llvm and check-clang?

I did, no other failing tests observed.


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] D102507: [HIP] Support in device code

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

The key difference between C++ and CUDA/HIP, as implemented in clang, is that 
`__host__` and `__device__` attributes are considered during function 
overloading in CUDA and HIP, so `__host__ void foo()`, `__device__ void foo()` 
and `__host__ __device__ void foo()` are three different functions and not 
redeclarations of the same function. Details of the original proposal are here: 
 https://goo.gl/EXnymm.

In D102507#2838776 , @yaxunl wrote:

> 2. Some libc++ functions are mostly common for device or host with minor 
> differences. For such functions, we can make them `__device__ __host__` and 
> use `#if __HIP_DEVICE_COMPILE__` (indicating device compilation) for the 
> minor difference in the function body.

I think we should rely on target overloading when possible, instead of the 
preprocessor. Minimizing the differences between the code seen by compiler 
during host and device side compilation will minimize potential issues.
Which approach we'll end up using is an implementation detail.

> 3. Some libc++ functions have different implementations for device and host. 
> We can leave these host functions as they are and adding overloaded 
> `__device__` functions.
>
> There are two ways to mark libc++ functions as `__device__ __host__`:
>
> 1. Define a macro which expands to empty for non-HIP programs and expands to 
> `__device__ __host__` for HIP and add it to each libc++ function which is to 
> be marked as `__device__ __host__`.

One caveat of the overloading based on target attributes is that we can't 
re-declare a function with `__device__ __host__` as compiler will see attempted 
redeclaration as a function overload of a function w/o attributes (implicitly 
`__host__`).

> 2. Define macros which expand to empty for non-HIP programs and expand to 
> `#pragma clang force_cuda_host_device begin/end` for HIP and put them at the 
> beginning and end of a file where all the functions are to be marked as 
> `__device__ __host__`.
>
> We plan to implement libc++ support in HIP device compilation in a 
> progressive approach, header by header, and document the supported libc++ 
> headers. We will prioritize libc++ headers to support based on 1) user 
> requests 2) whether it has already been supported through clang wrapper 
> headers (patching) 4) usefulness for device execution 3) availability of 
> lower level support with HIP runtime.

All of the above applies to CUDA, modulo the macro names and some differences 
in the builtins and the the functions provided (or not) by runtime on the GPU 
side.


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

https://reviews.llvm.org/D102507

___
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 updated this revision to Diff 354297.
craig.topper added a comment.

Add constant argument range checking to SemaChecking


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104822

Files:
  clang/include/clang/Basic/riscv_vector.td
  clang/lib/Sema/SemaChecking.cpp
  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  @llvm.experimental.vector.insert.nxv32i16.nxv4i16( [[DEST:%.*]],  [[VAL:%.*]], i64 28)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint16m8_t test_vset_v_i16m1_i16m8(vint16m8_t dest, vint16m1_t val) {
+  return vset_v_i16m1_i16m8(dest, 7, val);
+}
+
+// CHECK-RV64-LABEL: @test_vset_v_i16m2_i16m8(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv32i16.nxv8i16( [[DEST:%.*]],  [[VAL:%.*]], i64 16)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint16m8_t test_vset_v_i16m2_i16m8(vint16m8_t dest, vint16m2_t val) {
+  return vset_v_i1

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

[Melanie Blower via Phabricator via cfe-commits]

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

Rebasing.  Hope this clears lit fails.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99675

Files:
  llvm/docs/LangRef.rst
  llvm/include/llvm/Analysis/TargetTransformInfoImpl.h
  llvm/include/llvm/CodeGen/BasicTTIImpl.h
  llvm/include/llvm/CodeGen/ISDOpcodes.h
  llvm/include/llvm/CodeGen/SelectionDAGISel.h
  llvm/include/llvm/IR/IRBuilder.h
  llvm/include/llvm/IR/Intrinsics.td
  llvm/include/llvm/Support/TargetOpcodes.def
  llvm/include/llvm/Target/Target.td
  llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
  llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp
  llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
  llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp
  llvm/test/CodeGen/X86/arithmetic_fence.ll
  llvm/test/CodeGen/X86/arithmetic_fence2.ll

Index: llvm/test/CodeGen/X86/arithmetic_fence2.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/arithmetic_fence2.ll
@@ -0,0 +1,170 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc < %s -mtriple=i686-unknown-unknown -mattr=+sse2 | FileCheck %s --check-prefix=X86
+; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+sse2 | FileCheck %s --check-prefix=X64
+
+define double @f1(double %a) {
+; X86-LABEL: f1:
+; X86:   # %bb.0:
+; X86-NEXT:pushl %ebp
+; X86-NEXT:.cfi_def_cfa_offset 8
+; X86-NEXT:.cfi_offset %ebp, -8
+; X86-NEXT:movl %esp, %ebp
+; X86-NEXT:.cfi_def_cfa_register %ebp
+; X86-NEXT:andl $-8, %esp
+; X86-NEXT:subl $8, %esp
+; X86-NEXT:movsd {{.*#+}} xmm0 = mem[0],zero
+; X86-NEXT:mulsd {{\.?LCPI[0-9]+_[0-9]+}}, %xmm0
+; X86-NEXT:movsd %xmm0, (%esp)
+; X86-NEXT:fldl (%esp)
+; X86-NEXT:movl %ebp, %esp
+; X86-NEXT:popl %ebp
+; X86-NEXT:.cfi_def_cfa %esp, 4
+; X86-NEXT:retl
+;
+; X64-LABEL: f1:
+; X64:   # %bb.0:
+; X64-NEXT:mulsd {{\.?LCPI[0-9]+_[0-9]+}}(%rip), %xmm0
+; X64-NEXT:retq
+  %1 = fadd fast double %a, %a
+  %2 = fadd fast double %a, %a
+  %3 = fadd fast double %1, %2
+  ret double %3
+}
+
+define double @f2(double %a) {
+; X86-LABEL: f2:
+; X86:   # %bb.0:
+; X86-NEXT:pushl %ebp
+; X86-NEXT:.cfi_def_cfa_offset 8
+; X86-NEXT:.cfi_offset %ebp, -8
+; X86-NEXT:movl %esp, %ebp
+; X86-NEXT:.cfi_def_cfa_register %ebp
+; X86-NEXT:andl $-8, %esp
+; X86-NEXT:subl $8, %esp
+; X86-NEXT:movsd {{.*#+}} xmm0 = mem[0],zero
+; X86-NEXT:addsd %xmm0, %xmm0
+; X86-NEXT:movapd %xmm0, %xmm1
+; X86-NEXT:#ARITH_FENCE
+; X86-NEXT:addsd %xmm0, %xmm1
+; X86-NEXT:movsd %xmm1, (%esp)
+; X86-NEXT:fldl (%esp)
+; X86-NEXT:movl %ebp, %esp
+; X86-NEXT:popl %ebp
+; X86-NEXT:.cfi_def_cfa %esp, 4
+; X86-NEXT:retl
+;
+; X64-LABEL: f2:
+; X64:   # %bb.0:
+; X64-NEXT:addsd %xmm0, %xmm0
+; X64-NEXT:movapd %xmm0, %xmm1
+; X64-NEXT:#ARITH_FENCE
+; X64-NEXT:addsd %xmm0, %xmm1
+; X64-NEXT:movapd %xmm1, %xmm0
+; X64-NEXT:retq
+  %1 = fadd fast double %a, %a
+  %t = call double @llvm.arithmetic.fence.f64(double %1)
+  %2 = fadd fast double %a, %a
+  %3 = fadd fast double %t, %2
+  ret double %3
+}
+
+define <2 x float> @f3(<2 x float> %a) {
+; X86-LABEL: f3:
+; X86:   # %bb.0:
+; X86-NEXT:mulps {{\.?LCPI[0-9]+_[0-9]+}}, %xmm0
+; X86-NEXT:retl
+;
+; X64-LABEL: f3:
+; X64:   # %bb.0:
+; X64-NEXT:mulps {{\.?LCPI[0-9]+_[0-9]+}}(%rip), %xmm0
+; X64-NEXT:retq
+  %1 = fadd fast <2 x float> %a, %a
+  %2 = fadd fast <2 x float> %a, %a
+  %3 = fadd fast <2 x float> %1, %2
+  ret <2 x float> %3
+}
+
+define <2 x float> @f4(<2 x float> %a) {
+; X86-LABEL: f4:
+; X86:   # %bb.0:
+; X86-NEXT:addps %xmm0, %xmm0
+; X86-NEXT:movaps %xmm0, %xmm1
+; X86-NEXT:#ARITH_FENCE
+; X86-NEXT:addps %xmm0, %xmm1
+; X86-NEXT:movaps %xmm1, %xmm0
+; X86-NEXT:retl
+;
+; X64-LABEL: f4:
+; X64:   # %bb.0:
+; X64-NEXT:addps %xmm0, %xmm0
+; X64-NEXT:movaps %xmm0, %xmm1
+; X64-NEXT:#ARITH_FENCE
+; X64-NEXT:addps %xmm0, %xmm1
+; X64-NEXT:movaps %xmm1, %xmm0
+; X64-NEXT:retq
+  %1 = fadd fast <2 x float> %a, %a
+  %t = call <2 x float> @llvm.arithmetic.fence.v2f32(<2 x float> %1)
+  %2 = fadd fast <2 x float> %a, %a
+  %3 = fadd fast <2 x float> %t, %2
+  ret <2 x float> %3
+}
+
+define <8 x float> @f5(<8 x float> %a) {
+; X86-LABEL: f5:
+; X86:   # %bb.0:
+; X86-NEXT:movaps {{.*#+}} xmm2 = [4.0E+0,4.0E+0,4.0E+0,4.0E+0]
+; X86-NEXT:mulps %xmm2, %xmm0
+; X86-NEXT:mulps %xmm2, %xmm1
+; X86-NEXT:retl
+;
+; X64-LABEL: f5:
+; X64:   # %bb.0:
+; X64-NEXT:movaps {{.*#+}} xmm2 = [4.0E+0,4.0E+0,4.0E+0,4.0E+0]
+; X64-NEXT:mulps %xmm2, %xmm0
+; X64-NEXT:mulps %xmm2, %xmm1
+; X64-NEXT:retq
+  %1 = fadd fast <8 x float> %a, %a
+  %2 = fadd fast <8 x float> %a, %a
+  %3 = fadd fast <8 

[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 354301.
mibintc added a comment.

Rebase


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(&a);
+  // 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: -fno-builtin
Index: clang/test/CodeGen/arithmetic-fence-builtin.c
=

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

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

LGTM! Thanks

I agree we should have the same behavior for both options. Technically 
`-finclude-default-header` could be added in both steps but it is only 
effective in parsing the sources and does nothing otherwise. But it seems 
cleaner to align it with the header include option.


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] 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#2838211 , @aaron.ballman 
wrote:

> In D104777#2837794 , @dblaikie 
> wrote:
>
>> 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?
>
> To me, this is the key bit:
>
>> 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?
>
> because it **does** affect the callers, the programmer introducing the API 
> should be aware of that. Making this case an error helps them to understand 
> that this attribute is actually a part of their API and not an implementation 
> detail, and silently applying the attribute may cause hard-to-debug problems 
> for them after deployment of their API.

Yeah - the effect on callers is fairly minimal when it comes to DWARF. It 
changes whether DW_TAG_call_sites are emitted for the function - those call 
sites can help describe tail calls (which isn't nothing - in the absence of 
this info you can have missing stack frames, I think) but also mostly helps by 
describing "entry values" (if a caller stashes a value before calling a 
function, the call site can record where the extra copy was stored - then the 
callee might be able to describe the value of its parameters in terms of those 
entry values even if the callee's copy has been clobbered) - that these 
features would be dropped only in the translation unit that's compiling the 
implementation of the function, but not in every calling TU, is not a great 
loss - adding the attribute to the header would remove this extra information 
from everywhere (but at the expense of a longer build, having to rebuild all 
the dependencies).

Hmm - yeah, nodebug is more the sort of thing you put on a function because 
it's not an abstraction you want to debug - so I /think/ it makes sense to put 
it on the declaration in the header, rather than only on the implementation (I 
was going to say I thought it'd be the thing someone might do more 
iteratively/interactively - but that's "optnone" - where you'd want to put it 
on a function during a test/debug loop and wouldn't want to have to rebuild the 
whole project because it's more one-off, but "nodebug" isn't intended for that 
same sort of one-off use case)

Eh, I could see it going either way...


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

[clang] 3453f3d - [AMDGPU] Add gfx1035 target

[Aakanksha Patil via cfe-commits]

Author: Aakanksha Patil
Date: 2021-06-24T14:32:41-04:00
New Revision: 3453f3dd46f5214e028cb33818b10c5d995cd858

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

LOG: [AMDGPU] Add gfx1035 target

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

Added: 


Modified: 
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

Removed: 




diff  --git a/clang/include/clang/Basic/Cuda.h 
b/clang/include/clang/Basic/Cuda.h
index 13317f62c3c5a..aa12724cbf0c6 100644
--- a/clang/include/clang/Basic/Cuda.h
+++ b/clang/include/clang/Basic/Cuda.h
@@ -89,6 +89,7 @@ enum class CudaArch {
   GFX1032,
   GFX1033,
   GFX1034,
+  GFX1035,
   LAST,
 };
 

diff  --git a/clang/lib/Basic/Cuda.cpp b/clang/lib/Basic/Cuda.cpp
index fa7f78a25829f..766135bcb376f 100644
--- a/clang/lib/Basic/Cuda.cpp
+++ b/clang/lib/Basic/Cuda.cpp
@@ -111,6 +111,7 @@ static const CudaArchToStringMap arch_names[] = {
 GFX(1032), // gfx1032
 GFX(1033), // gfx1033
 GFX(1034), // gfx1034
+GFX(1035), // gfx1035
 // clang-format on
 };
 #undef SM

diff  --git a/clang/lib/Basic/Targets/AMDGPU.cpp 
b/clang/lib/Basic/Targets/AMDGPU.cpp
index 8a8165e9c895c..595132e2e70ba 100644
--- a/clang/lib/Basic/Targets/AMDGPU.cpp
+++ b/clang/lib/Basic/Targets/AMDGPU.cpp
@@ -184,6 +184,7 @@ bool AMDGPUTargetInfo::initFeatureMap(
   // XXX - What does the member GPU mean if device name string passed here?
   if (isAMDGCN(getTriple())) {
 switch (llvm::AMDGPU::parseArchAMDGCN(CPU)) {
+case GK_GFX1035:
 case GK_GFX1034:
 case GK_GFX1033:
 case GK_GFX1032:

diff  --git a/clang/lib/Basic/Targets/NVPTX.cpp 
b/clang/lib/Basic/Targets/NVPTX.cpp
index 885dac9ab79d7..56f8a179db3cc 100644
--- a/clang/lib/Basic/Targets/NVPTX.cpp
+++ b/clang/lib/Basic/Targets/NVPTX.cpp
@@ -213,6 +213,7 @@ void NVPTXTargetInfo::getTargetDefines(const LangOptions 
&Opts,
   case CudaArch::GFX1032:
   case CudaArch::GFX1033:
   case CudaArch::GFX1034:
+  case CudaArch::GFX1035:
   case CudaArch::LAST:
 break;
   case CudaArch::UNUSED:

diff  --git a/clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp 
b/clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
index 772717c496757..2e79e2978d3da 100644
--- a/clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
+++ b/clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
@@ -4194,6 +4194,7 @@ void CGOpenMPRuntimeGPU::processRequiresDirective(
   case CudaArch::GFX1032:
   case CudaArch::GFX1033:
   case CudaArch::GFX1034:
+  case CudaArch::GFX1035:
   case CudaArch::UNUSED:
   case CudaArch::UNKNOWN:
 break;

diff  --git a/clang/test/CodeGenOpenCL/amdgpu-features.cl 
b/clang/test/CodeGenOpenCL/amdgpu-features.cl
index b4b86d75c9ae7..a532da344df1a 100644
--- a/clang/test/CodeGenOpenCL/amdgpu-features.cl
+++ b/clang/test/CodeGenOpenCL/amdgpu-features.cl
@@ -34,6 +34,7 @@
 // RUN: %clang_cc1 -triple amdgcn -target-cpu gfx1032 -S -emit-llvm -o - %s | 
FileCheck --check-prefix=GFX1032 %s
 // RUN: %clang_cc1 -triple amdgcn -target-cpu gfx1033 -S -emit-llvm -o - %s | 
FileCheck --check-prefix=GFX1033 %s
 // RUN: %clang_cc1 -triple amdgcn -target-cpu gfx1034 -S -emit-llvm -o - %s | 
FileCheck --check-prefix=GFX1034 %s
+// RUN: %clang_cc1 -triple amdgcn -target-cpu gfx1035 -S -emit-llvm -o - %s | 
FileCheck --check-prefix=GFX1035 %s
 
 // GFX600: "target-features"="+s-memtime-inst"
 // GFX601: "target-features"="+s-memtime-inst"
@@ -66,5 +67,6 @@
 // GFX1032: 
"target-features"="+16-bit-insts,+ci-insts,+dl-insts,+dot1-insts,+dot2-insts,+dot5-i

[PATCH] D104804: [AMDGPU] Add gfx1035 target

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added inline comments.



Comment at: llvm/test/Object/AMDGPU/elf-header-flags-mach.yaml:189
 
+# RUN: sed -e 's//64/' -e 's//AMDGCN_GFX1035/' %s | yaml2obj -o 
%t.o.AMDGCN_GFX1035
+# RUN: llvm-readobj -S --file-headers %t.o.AMDGCN_GFX1035 | FileCheck 
--check-prefixes=ELF-AMDGCN-ALL,ELF-AMDGCN-GFX1035 %s

sed can be replaced by `FileCheck -D` (search examples in `test/tools/`).

The long list becomes unwieldy now. @jhenderson Suggestions on decreasing the 
number of RUN lines?


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] D104804: [AMDGPU] Add gfx1035 target

[Aakanksha Patil 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 rG3453f3dd46f5: [AMDGPU] Add gfx1035 target (authored by 
aakanksha555).

Repository:
  rG LLVM Github Monorepo

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

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
@@ -1493,6 +1493,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)
 };
@@ -1546,6 +1547,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 --match-full-lines -DABI_VERSION=0 -DFILE=%t -DFLAG_0="EF_AMDGPU_FEATURE_XNACK_V3 (0x100)" -DFLAG_1="EF_AMDGPU_MACH_AMDGCN_GFX90A (0x3F)" -DFLAG_VALUE=0x13F
Index: llvm/test/tools/llvm-objdump/ELF/AMDGPU/s

[PATCH] D104616: [analyzer][WIP] Model comparision methods of std::unique_ptr

[Deep Majumder via Phabricator via cfe-commits]

RedDocMD updated this revision to Diff 354323.
RedDocMD added a comment.

Removed re-invention, added tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104616

Files:
  clang/lib/StaticAnalyzer/Checkers/SmartPtr.h
  clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
  clang/test/Analysis/smart-ptr.cpp

Index: clang/test/Analysis/smart-ptr.cpp
===
--- clang/test/Analysis/smart-ptr.cpp
+++ clang/test/Analysis/smart-ptr.cpp
@@ -457,3 +457,19 @@
 P->foo(); // expected-warning {{Dereference of null smart pointer 'P' [alpha.cplusplus.SmartPtr]}}
   }
 }
+
+void uniquePtrComparision(std::unique_ptr unknownPtr) {
+  auto ptr = std::unique_ptr(new int(13));
+  auto nullPtr = std::unique_ptr();
+  auto otherPtr = std::unique_ptr(new int(29));
+
+  clang_analyzer_eval(ptr == ptr); // expected-warning{{TRUE}}
+  clang_analyzer_eval(ptr > ptr);  // expected-warning{{FALSE}}
+  clang_analyzer_eval(ptr <= ptr); // expected-warning{{TRUE}}
+
+  clang_analyzer_eval(nullPtr <= unknownPtr); // expected-warning{{TRUE}}
+  clang_analyzer_eval(unknownPtr >= nullPtr); // expected-warning{{TRUE}}
+
+  clang_analyzer_eval(ptr != otherPtr); // expected-warning{{TRUE}}
+  clang_analyzer_eval(ptr > nullPtr);   // expected-warning{{TRUE}}
+}
Index: clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
+++ clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
@@ -29,6 +29,7 @@
 #include "clang/StaticAnalyzer/Core/PathSensitive/SVals.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/SymExpr.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/SymbolManager.h"
+#include "llvm/Support/ErrorHandling.h"
 #include 
 
 using namespace clang;
@@ -68,6 +69,7 @@
   bool updateMovedSmartPointers(CheckerContext &C, const MemRegion *ThisRegion,
 const MemRegion *OtherSmartPtrRegion) const;
   void handleBoolConversion(const CallEvent &Call, CheckerContext &C) const;
+  bool handleComparisionOp(const CallEvent &Call, CheckerContext &C) const;
 
   using SmartPtrMethodHandlerFn =
   void (SmartPtrModeling::*)(const CallEvent &Call, CheckerContext &) const;
@@ -89,18 +91,24 @@
   const auto *MethodDecl = dyn_cast_or_null(Call.getDecl());
   if (!MethodDecl || !MethodDecl->getParent())
 return false;
+  return isStdSmartPtr(MethodDecl->getParent());
+}
 
-  const auto *RecordDecl = MethodDecl->getParent();
-  if (!RecordDecl || !RecordDecl->getDeclContext()->isStdNamespace())
+bool isStdSmartPtr(const CXXRecordDecl *RD) {
+  if (!RD || !RD->getDeclContext()->isStdNamespace())
 return false;
 
-  if (RecordDecl->getDeclName().isIdentifier()) {
-StringRef Name = RecordDecl->getName();
+  if (RD->getDeclName().isIdentifier()) {
+StringRef Name = RD->getName();
 return Name == "shared_ptr" || Name == "unique_ptr" || Name == "weak_ptr";
   }
   return false;
 }
 
+bool isStdSmartPtr(const Expr *E) {
+  return isStdSmartPtr(E->getType()->getAsCXXRecordDecl());
+}
+
 bool isNullSmartPtr(const ProgramStateRef State, const MemRegion *ThisRegion) {
   const auto *InnerPointVal = State->get(ThisRegion);
   return InnerPointVal &&
@@ -178,6 +186,15 @@
 bool SmartPtrModeling::evalCall(const CallEvent &Call,
 CheckerContext &C) const {
   ProgramStateRef State = C.getState();
+
+  // If any one of the arg is a unique_ptr, then
+  // we can try this function
+  if (Call.getNumArgs() == 2)
+if (smartptr::isStdSmartPtr(Call.getArgExpr(0)) ||
+smartptr::isStdSmartPtr(Call.getArgExpr(1)))
+  if (handleComparisionOp(Call, C))
+return true;
+
   if (!smartptr::isStdSmartPtrCall(Call))
 return false;
 
@@ -272,6 +289,123 @@
   return C.isDifferent();
 }
 
+bool SmartPtrModeling::handleComparisionOp(const CallEvent &Call,
+   CheckerContext &C) const {
+  const auto *FC = dyn_cast(&Call);
+  if (!FC)
+return false;
+  const FunctionDecl *FD = FC->getDecl();
+  if (!FD->isOverloadedOperator())
+return false;
+  const OverloadedOperatorKind OOK = FD->getOverloadedOperator();
+  if (!(OOK == OO_Equal || OOK == OO_ExclaimEqual || OOK == OO_Less ||
+OOK == OO_LessEqual || OOK == OO_Greater || OOK == OO_GreaterEqual ||
+OOK == OO_Spaceship))
+return false;
+
+  SVal First = Call.getArgSVal(0);
+  SVal Second = Call.getArgSVal(1);
+
+  // There are some special cases about which we can infer about
+  // the resulting answer.
+  // For reference, there is a discussion at https://reviews.llvm.org/D104616.
+  // Also, the cppreference page is good to look at
+  // https://en.cppreference.com/w/cpp/memory/unique_ptr/operator_cmp.
+
+  ProgramStateRef State = C.getState();
+  SVal RetVal = C.getSValBuilder().conjure

[PATCH] D104616: [analyzer][WIP] Model comparision methods of std::unique_ptr

[Deep Majumder via Phabricator via cfe-commits]

RedDocMD added a comment.

We have a failing test  here (test at line 473).
Which makes me wonder if the `handleComparision` function is at all called. 
This is something I need to check.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104616

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