[PATCH] D104640: [clang][Analyzer] Track null stream argument in alpha.unix.Stream .

2021-06-21 Thread Balázs Kéri via Phabricator via cfe-commits
balazske added a comment.

Thanks for the quick accept.
The goal is to make this checker non-alpha.




Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:838
+  auto R = std::make_unique(
+  BT_FileNull, "Stream pointer might be NULL.", N);
+  if (StreamE)

NoQ wrote:
> Stream pointer *is* null. There's no doubt about that.
> 
> Path notes should look like one big complete sentence: "//Assuming pointer 
> value is null// on line 83, ... //stream pointer ~~might be~~ is null// on 
> line 88".
> 
> This isn't part of this patch so I'm just spreading awareness^^
I do not like the messages in this checker but plan to improve it later. I 
observed that the last `.` character is removed from the messages, they can be 
like one sentence but multiple sentences.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104640

___
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

2021-06-21 Thread Manas Gupta via Phabricator via cfe-commits
manas added inline comments.



Comment at: clang/test/Analysis/constant-folding.c:280-281
+  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}}

manas wrote:
> vsavchenko wrote:
> > manas wrote:
> > > vsavchenko wrote:
> > > > manas wrote:
> > > > > When I pull these cases out to a separate function (say 
> > > > > testAdditionRules2) in constant-folding.c then algorithm is able to 
> > > > > reason about the range correctly, but inside testAdditionRules, it is 
> > > > > unable to figure stuff out. Does it have something to do with 
> > > > > constraints being propagated which we discussed below?
> > > > > 
> > > > > @vsavchenko wrote: 
> > > > > > I have one note here.  The fact that we don't have a testing 
> > > > > > framework and use this approach of inspecting the actual analysis 
> > > > > > has an interesting implication.
> > > > > > 
> > > > > > ```
> > > > > > if (a == 10) { // here we split path into 2 paths: one where a == 
> > > > > > 10, and one where a != 10;
> > > > > >// one goes inside of if, one doesn't
> > > > > >   . . .
> > > > > > }
> > > > > > if (a >= 5) { // here we split into 3 paths: a == 10, a < 5, and a 
> > > > > > in [5, 9] and [11, INT_MAX] (aka a >= 5 and a != 10).
> > > > > >   // 1 path was infeasible: a == 10 and a < 5
> > > > > >   // Two of these paths go inside of the if, one doesn't
> > > > > >   . . .
> > > > > >   clang_analyzer_eval(a == 10); // it will produce two results: 
> > > > > > TRUE and FALSE
> > > > > > }
> > > > > > clang_analyzer_eval(a == 10); // it will produce three results: 
> > > > > > TRUE, FALSE, and FALSE
> > > > > > ```
> > > > > > 
> > > > > > We don't want to test how path splitting works in these particular 
> > > > > > tests (they are about solver and constant folding after all), 
> > > > > > that's why we try to have only one path going through each 
> > > > > > `clang_analyzer_eval(...)`
> > > > > > 
> > > > > 
> > > > > 
> > > > It might be that or it might be something different.  Just by looking 
> > > > at this example, the previous `if` statement shouldn't add more paths 
> > > > that go inside of this `if`, so it shouldn't be the root cause.
> > > > Whenever you encounter problems and you want to tell other people, 
> > > > **please, provide more detail**.  Did you notice it when running the 
> > > > test case?  What was the output?  What did you try?  How did you 
> > > > extract it into a separate function?
> > > I put a new test function in `constant-folding.c` as:
> > > 
> > > ```
> > > void testAdditionRulesNew(int c, int d) {
> > >   if (c < 0 && c != INT_MIN && d < 0) {
> > > clang_analyzer_eval((c + d) == 0); // expected-warning{{FALSE}}
> > >   }
> > > }
> > > ```
> > > I tested this specific function as:
> > > 
> > >   ./build/bin/clang -cc1 -analyze 
> > > -analyzer-checker=core,debug.ExprInspection 
> > > -analyze-function=testAdditionRulesNew constant-folding.c
> > > 
> > > And I got the following output:
> > > 
> > >   ../clang/test/Analysis/constant-folding.c:338:5: warning: FALSE 
> > > [debug.ExprInspection]
> > > clang_analyzer_eval((c + d) == 0); // expected-warning{{FALSE}}
> > > 
> > > which is correct.
> > > 
> > > But when I ran the same test inside `testAdditionRules`, using:
> > > ./build/bin/clang -cc1 -analyze 
> > > -analyzer-checker=core,debug.ExprInspection 
> > > -analyze-function=testAdditionRules constant-folding.c
> > > then I got:
> > > 
> > >   ../clang/test/Analysis/constant-folding.c:281:5: warning: FALSE 
> > > [debug.ExprInspection]
> > > clang_analyzer_eval((c + d) == 0); // expected-warning{{FALSE}}   
> > >   
> > >
> > > ^ 
> > >  
> > >   ../clang/test/Analysis/constant-folding.c:281:5: warning: TRUE 
> > > [debug.ExprInspection]
> > > clang_analyzer_eval((c + d) == 0); // expected-warning{{FALSE}}   
> > >   
> > >
> > > ^  
> > > 
> > > Here, `c = [INT_MIN + 1, -1]` and `d = [INT_MIN, 0]`, so `c + d = 
> > > [INT_MIN, -2] U [1, INT_MAX]`. So `c + d == 0` should be false. But in 
> > > latter case, it is reasoning `c + d == 0` to be `UNKNOWN`.
> > > 
> > > Also, the error arises in `c + d == 0` case only and not in `c + d == -1` 
> > > case. I mistakenly highlighted that case while commenting.
> > Hmm, I don't know what can be the reason.
> > 
> > There are three reasonable approaches:
> > 1. Straightforward: use debugger.  Find a place when we ask the solver 
> > about this assumption and dig in.

[PATCH] D102107: [OpenMP] Codegen aggregate for outlined function captures

2021-06-21 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added a comment.

In D102107#2824581 , @ABataev wrote:

> In D102107#2823706 , @jdoerfert 
> wrote:
>
>> In D102107#2821976 , @ABataev 
>> wrote:
>>
>>> We used this kind of codegen initially but later found out that it causes a 
>>> large overhead when gathering pointers into a record. What about hybrid 
>>> scheme where the first args are passed as arguments and others (if any) are 
>>> gathered into a record?
>>
>> I'm confused, maybe I misunderstand the problem. The parallel function 
>> arguments need to go from the main thread to the workers somehow, I don't 
>> see how this is done w/o a record. This patch makes it explicit though.
>
> Pass it in a record for workers only? And use a hybrid scheme for all other 
> parallel regions.

I still do not follow. What does it mean for workers only? What is a hybrid 
scheme? And, probably most importantly, how would we not eventually put 
everything into a record anyway?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102107

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


[PATCH] D104677: [OpenMP][AMDGCN] Apply fix for isnan, isinf and isfinite for amdgcn.

2021-06-21 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert accepted this revision.
jdoerfert added a comment.
This revision is now accepted and ready to land.

LGTM, glad AMD GPUs are catching up on the math header support now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104677

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


LLVM build master will be restarted soon

2021-06-21 Thread Galina Kistanova via cfe-commits
 Hello,

LLVM build master will be restarted in the nearest hour.

Thanks

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


[PATCH] D93373: [Flang][Openmp] Upgrade TASKGROUP construct to 5.0.

2021-06-21 Thread Chirag Khandelwal via Phabricator via cfe-commits
AMDChirag updated this revision to Diff 353548.
AMDChirag added a comment.

Rebased to main


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93373

Files:
  clang/test/OpenMP/master_taskloop_simd_ast_print.cpp
  clang/test/OpenMP/parallel_master_taskloop_simd_ast_print.cpp
  clang/test/OpenMP/taskloop_simd_ast_print.cpp
  flang/lib/Semantics/resolve-directives.cpp
  flang/lib/Semantics/resolve-names.cpp
  flang/test/Semantics/omp-taskgroup01.f90
  llvm/include/llvm/Frontend/OpenMP/OMP.td

Index: llvm/include/llvm/Frontend/OpenMP/OMP.td
===
--- llvm/include/llvm/Frontend/OpenMP/OMP.td
+++ llvm/include/llvm/Frontend/OpenMP/OMP.td
@@ -473,8 +473,8 @@
 }
 def OMP_TaskGroup : Directive<"taskgroup"> {
   let allowedClauses = [
-VersionedClause,
-VersionedClause
+VersionedClause,
+VersionedClause
   ];
 }
 def OMP_Flush : Directive<"flush"> {
Index: flang/test/Semantics/omp-taskgroup01.f90
===
--- /dev/null
+++ flang/test/Semantics/omp-taskgroup01.f90
@@ -0,0 +1,47 @@
+! RUN: %S/test_errors.sh %s %t %flang -fopenmp
+use omp_lib
+  implicit none
+  integer :: xyz, abc
+  real :: reduction_var
+  !$omp parallel num_threads(4)
+!$omp single
+  print *, "The"
+!$omp taskgroup
+  !$omp task
+  print *, "almighty"
+  !$omp end task
+  !$omp task
+  print *, "sun"
+  !$omp end task
+!$omp end taskgroup
+!$omp end single
+  !$omp end parallel
+
+  !$omp parallel private(xyz)
+!$omp taskgroup allocate(xyz)
+  !$omp task
+print *, "The "
+!$omp taskgroup allocate(omp_large_cap_mem_space: abc)
+  !$omp task
+  print *, "almighty sun"
+  !$omp end task
+!$omp end taskgroup
+  !$omp end task
+!$omp end taskgroup
+  !$omp end parallel
+
+  !ERROR: PRIVATE clause is not allowed on the TASKGROUP directive
+  !$omp taskgroup private(abc)
+  !$omp end taskgroup
+
+  !$omp parallel
+!$omp task
+  !$omp taskgroup task_reduction(+ : reduction_var)
+print *, "The "
+!$omp taskgroup task_reduction(.or. : reduction_var) task_reduction(.and. : reduction_var)
+  print *, "almighty sun"
+!$omp end taskgroup
+  !$omp end taskgroup
+!$omp end task
+  !$omp end parallel
+end program
Index: flang/lib/Semantics/resolve-names.cpp
===
--- flang/lib/Semantics/resolve-names.cpp
+++ flang/lib/Semantics/resolve-names.cpp
@@ -1288,6 +1288,7 @@
   case llvm::omp::Directive::OMPD_target_data:
   case llvm::omp::Directive::OMPD_master:
   case llvm::omp::Directive::OMPD_ordered:
+  case llvm::omp::Directive::OMPD_taskgroup:
 return false;
   default:
 return true;
Index: flang/lib/Semantics/resolve-directives.cpp
===
--- flang/lib/Semantics/resolve-directives.cpp
+++ flang/lib/Semantics/resolve-directives.cpp
@@ -1069,12 +1069,12 @@
   case llvm::omp::Directive::OMPD_target:
   case llvm::omp::Directive::OMPD_target_data:
   case llvm::omp::Directive::OMPD_task:
+  case llvm::omp::Directive::OMPD_taskgroup:
   case llvm::omp::Directive::OMPD_teams:
   case llvm::omp::Directive::OMPD_workshare:
   case llvm::omp::Directive::OMPD_parallel_workshare:
   case llvm::omp::Directive::OMPD_target_teams:
   case llvm::omp::Directive::OMPD_target_parallel:
-  case llvm::omp::Directive::OMPD_taskgroup:
 PushContext(beginDir.source, beginDir.v);
 break;
   default:
@@ -1095,6 +1095,7 @@
   case llvm::omp::Directive::OMPD_single:
   case llvm::omp::Directive::OMPD_target:
   case llvm::omp::Directive::OMPD_task:
+  case llvm::omp::Directive::OMPD_taskgroup:
   case llvm::omp::Directive::OMPD_teams:
   case llvm::omp::Directive::OMPD_parallel_workshare:
   case llvm::omp::Directive::OMPD_target_teams:
Index: clang/test/OpenMP/taskloop_simd_ast_print.cpp
===
--- clang/test/OpenMP/taskloop_simd_ast_print.cpp
+++ clang/test/OpenMP/taskloop_simd_ast_print.cpp
@@ -1,13 +1,13 @@
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-version=45 -ast-print %s | FileCheck %s --check-prefix CHECK --check-prefix OMP45
-// RUN: %clang_cc1 -fopenmp -fopenmp-version=45 -x c++ -std=c++11 -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-version=45 -std=c++11 -include-pch %t -fsyntax-only -verify %s -ast-print | FileCheck %s --check-prefix CHECK --check-prefix OMP45
+// RUN: %clang_cc1 -verify -fopenmp -fopenmp-version=50 -DOMP5 -ast-print %s | FileCheck %s --check-prefix CHECK --check-prefix OMP50
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -DOMP5 -x c++ -std=c++11 -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -DOMP5 -std=c++11 -include-pch %t -fsyntax-only -verify %s -ast-prin

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

2021-06-21 Thread Manas Gupta via Phabricator via cfe-commits
manas added inline comments.



Comment at: clang/test/Analysis/constant-folding.c:280-281
+  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}}

vsavchenko wrote:
> manas wrote:
> > vsavchenko wrote:
> > > manas wrote:
> > > > When I pull these cases out to a separate function (say 
> > > > testAdditionRules2) in constant-folding.c then algorithm is able to 
> > > > reason about the range correctly, but inside testAdditionRules, it is 
> > > > unable to figure stuff out. Does it have something to do with 
> > > > constraints being propagated which we discussed below?
> > > > 
> > > > @vsavchenko wrote: 
> > > > > I have one note here.  The fact that we don't have a testing 
> > > > > framework and use this approach of inspecting the actual analysis has 
> > > > > an interesting implication.
> > > > > 
> > > > > ```
> > > > > if (a == 10) { // here we split path into 2 paths: one where a == 10, 
> > > > > and one where a != 10;
> > > > >// one goes inside of if, one doesn't
> > > > >   . . .
> > > > > }
> > > > > if (a >= 5) { // here we split into 3 paths: a == 10, a < 5, and a in 
> > > > > [5, 9] and [11, INT_MAX] (aka a >= 5 and a != 10).
> > > > >   // 1 path was infeasible: a == 10 and a < 5
> > > > >   // Two of these paths go inside of the if, one doesn't
> > > > >   . . .
> > > > >   clang_analyzer_eval(a == 10); // it will produce two results: TRUE 
> > > > > and FALSE
> > > > > }
> > > > > clang_analyzer_eval(a == 10); // it will produce three results: TRUE, 
> > > > > FALSE, and FALSE
> > > > > ```
> > > > > 
> > > > > We don't want to test how path splitting works in these particular 
> > > > > tests (they are about solver and constant folding after all), that's 
> > > > > why we try to have only one path going through each 
> > > > > `clang_analyzer_eval(...)`
> > > > > 
> > > > 
> > > > 
> > > It might be that or it might be something different.  Just by looking at 
> > > this example, the previous `if` statement shouldn't add more paths that 
> > > go inside of this `if`, so it shouldn't be the root cause.
> > > Whenever you encounter problems and you want to tell other people, 
> > > **please, provide more detail**.  Did you notice it when running the test 
> > > case?  What was the output?  What did you try?  How did you extract it 
> > > into a separate function?
> > I put a new test function in `constant-folding.c` as:
> > 
> > ```
> > void testAdditionRulesNew(int c, int d) {
> >   if (c < 0 && c != INT_MIN && d < 0) {
> > clang_analyzer_eval((c + d) == 0); // expected-warning{{FALSE}}
> >   }
> > }
> > ```
> > I tested this specific function as:
> > 
> >   ./build/bin/clang -cc1 -analyze 
> > -analyzer-checker=core,debug.ExprInspection 
> > -analyze-function=testAdditionRulesNew constant-folding.c
> > 
> > And I got the following output:
> > 
> >   ../clang/test/Analysis/constant-folding.c:338:5: warning: FALSE 
> > [debug.ExprInspection]
> > clang_analyzer_eval((c + d) == 0); // expected-warning{{FALSE}}
> > 
> > which is correct.
> > 
> > But when I ran the same test inside `testAdditionRules`, using:
> > ./build/bin/clang -cc1 -analyze 
> > -analyzer-checker=core,debug.ExprInspection 
> > -analyze-function=testAdditionRules constant-folding.c
> > then I got:
> > 
> >   ../clang/test/Analysis/constant-folding.c:281:5: warning: FALSE 
> > [debug.ExprInspection]
> > clang_analyzer_eval((c + d) == 0); // expected-warning{{FALSE}} 
> > 
> >
> > ^   
> >
> >   ../clang/test/Analysis/constant-folding.c:281:5: warning: TRUE 
> > [debug.ExprInspection]
> > clang_analyzer_eval((c + d) == 0); // expected-warning{{FALSE}} 
> > 
> >
> > ^  
> > 
> > Here, `c = [INT_MIN + 1, -1]` and `d = [INT_MIN, 0]`, so `c + d = [INT_MIN, 
> > -2] U [1, INT_MAX]`. So `c + d == 0` should be false. But in latter case, 
> > it is reasoning `c + d == 0` to be `UNKNOWN`.
> > 
> > Also, the error arises in `c + d == 0` case only and not in `c + d == -1` 
> > case. I mistakenly highlighted that case while commenting.
> Hmm, I don't know what can be the reason.
> 
> There are three reasonable approaches:
> 1. Straightforward: use debugger.  Find a place when we ask the solver about 
> this assumption and dig in.
> 2. Print-based: use `clang_analyzer_printState` inside of this if.  Among 
> other things it will print you all constraints that we know about, you can 
> check if they match your expectations.  Also, if it is in

[PATCH] D103943: [X86] Add -mgeneral-regs-only support.

2021-06-21 Thread Wang Tianqing via Phabricator via cfe-commits
tianqing marked an inline comment as done.
tianqing added inline comments.



Comment at: clang/include/clang/Driver/Options.td:3214
 
-def mgeneral_regs_only : Flag<["-"], "mgeneral-regs-only">, 
Group,
-  HelpText<"Generate code which only uses the general purpose registers 
(AArch64 only)">;
+def mgeneral_regs_only : Flag<["-"], "mgeneral-regs-only">, Group,
+  HelpText<"Generate code which only uses the general purpose registers 
(AArch64/x86 only)">;

pengfei wrote:
> Will this change affect AArch64 or other targets expect AArch64 and x86?
No, using this option on other targets gives "argument unused during 
compilation" warning.



Comment at: clang/lib/Basic/Targets/X86.cpp:120
 
-  if (!TargetInfo::initFeatureMap(Features, Diags, CPU, FeaturesVec))
+  std::vector UpdatedFeaturesVec;
+  for (const auto& Feature : FeaturesVec) {

pengfei wrote:
> Why do we need to expand it again after we handling in driver?
The driver handles command line options, and this handles "target" attributes.
Just adding "+general-regs-only" in the driver also works. But it's not in 
OPT_m_x86_Features_Group, and current handleTargetFeaturesGroup will ignore it 
so we still have to copy its code, not much of a difference.

(Note AArch64 only supports options)



Comment at: clang/lib/Basic/Targets/X86.cpp:136-158
   // Can't do this earlier because we need to be able to explicitly enable
   // or disable these features and the things that they depend upon.
 
   // Enable popcnt if sse4.2 is enabled and popcnt is not explicitly disabled.
   auto I = Features.find("sse4.2");
   if (I != Features.end() && I->getValue() &&
+  llvm::find(UpdatedFeaturesVec, "-popcnt") == UpdatedFeaturesVec.end())

pengfei wrote:
> Shouldn't this be simply skipped under "general-regs-only"?
It's still about order of options. Seeing a "general-regs-only" doesn't mean 
the function is really GPR only, we have to apply all options in order and 
check the result.



Comment at: clang/lib/Driver/ToolChains/Arch/X86.cpp:216-235
+  for (const Arg *A : Args.filtered(options::OPT_m_x86_Features_Group,
+options::OPT_mgeneral_regs_only)) {
+StringRef Name = A->getOption().getName();
+A->claim();
+
+// Skip over "-m".
+assert(Name.startswith("m") && "Invalid feature name.");

pengfei wrote:
> Why we need copy the code here? Can it be simply use:
> ```
> if (Args.getLastArg(options::OPT_mgeneral_regs_only))
>   Features.insert(Features.end(), {"-x87", "-mmx", "-sse"});
> handleTargetFeaturesGroup(Args, Features, options::OPT_m_x86_Features_Group);
> ```
To make sure later options override earlier ones. This is how GCC behaves.

This is demonstrated in the "GPR" and "AVX2" check lines of the new tests.



Comment at: clang/test/CodeGen/attr-target-general-regs-only-x86.c:14
+// CHECK: attributes [[GPR_ATTRS]] = { {{.*}} 
"target-features"="{{.*}}-avx{{.*}}-avx2{{.*}}-avx512f{{.*}}-sse{{.*}}-sse2{{.*}}-ssse3{{.*}}-x87{{.*}}"
+// CHECK: attributes [[AVX2_ATTRS]] = { {{.*}} 
"target-features"="{{.*}}+avx{{.*}}+avx2{{.*}}+sse{{.*}}+sse2{{.*}}+ssse3{{.*}}-avx512f{{.*}}-x87{{.*}}"

pengfei wrote:
> Why we have a `-avx512f` when enabling `avx2`?
See llvm::X86::updateImpliedFeatures(), enabling a feature will enable all 
features it depends on, disabling a feature also disables all features 
depending on it. This is "target feature inheritance" mentioned in Simon's 
comment.


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

https://reviews.llvm.org/D103943

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


[PATCH] D103943: [X86] Add -mgeneral-regs-only support.

2021-06-21 Thread Wang Tianqing via Phabricator via cfe-commits
tianqing updated this revision to Diff 353536.
tianqing added a comment.

Fix lint comment.


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

https://reviews.llvm.org/D103943

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Driver/ToolChains/Arch/X86.cpp
  clang/test/CodeGen/attr-target-general-regs-only-x86.c
  clang/test/Driver/x86-mgeneral-regs-only.c

Index: clang/test/Driver/x86-mgeneral-regs-only.c
===
--- /dev/null
+++ clang/test/Driver/x86-mgeneral-regs-only.c
@@ -0,0 +1,26 @@
+// Test the -mgeneral-regs-only option on x86
+
+// RUN: %clang -target i386-unknown-linux-gnu -mgeneral-regs-only %s -### 2>&1 | FileCheck --check-prefix=CMD %s
+// RUN: %clang -target x86_64-unknown-linux-gnu -mgeneral-regs-only %s -### 2>&1 | FileCheck --check-prefix=CMD %s
+// RUN: %clang -target i386-unknown-linux-gnu -mavx2 -mgeneral-regs-only %s -### 2>&1 | FileCheck --check-prefixes=CMD,CMD-BEFORE %s
+// RUN: %clang -target x86_64-unknown-linux-gnu -mavx2 -mgeneral-regs-only %s -### 2>&1 | FileCheck --check-prefixes=CMD,CMD-BEFORE %s
+// RUN: %clang -target i386-unknown-linux-gnu -mgeneral-regs-only -mavx2 %s -### 2>&1 | FileCheck --check-prefixes=CMD,CMD-AFTER %s
+// RUN: %clang -target x86_64-unknown-linux-gnu -mgeneral-regs-only -mavx2 %s -### 2>&1 | FileCheck --check-prefixes=CMD,CMD-AFTER %s
+
+// RUN: %clang -target i386-unknown-linux-gnu -mgeneral-regs-only -S -emit-llvm %s -o - 2>&1 | FileCheck --check-prefix=IR-GPR %s
+// RUN: %clang -target x86_64-unknown-linux-gnu -mgeneral-regs-only -S -emit-llvm %s -o - 2>&1 | FileCheck --check-prefix=IR-GPR %s
+// RUN: %clang -target i386-unknown-linux-gnu -mavx2 -mgeneral-regs-only -S -emit-llvm %s -o - 2>&1 | FileCheck --check-prefix=IR-GPR %s
+// RUN: %clang -target x86_64-unknown-linux-gnu -mavx2 -mgeneral-regs-only -S -emit-llvm %s -o - 2>&1 | FileCheck --check-prefix=IR-GPR %s
+// RUN: %clang -target i386-unknown-linux-gnu -mgeneral-regs-only -mavx2 -S -emit-llvm %s -o - 2>&1 | FileCheck --check-prefix=IR-AVX2 %s
+// RUN: %clang -target x86_64-unknown-linux-gnu -mgeneral-regs-only -mavx2 -S -emit-llvm %s -o - 2>&1 | FileCheck --check-prefix=IR-AVX2 %s
+
+// CMD-BEFORE: "-target-feature" "+avx2"
+// CMD: "-target-feature" "-x87"
+// CMD: "-target-feature" "-mmx"
+// CMD: "-target-feature" "-sse"
+// CMD-AFTER: "-target-feature" "+avx2"
+
+void foo() { }
+
+// IR-GPR: attributes {{.*}} = { {{.*}} "target-features"="{{.*}}-avx{{.*}}-avx2{{.*}}-avx512f{{.*}}-sse{{.*}}-sse2{{.*}}-ssse3{{.*}}-x87{{.*}}"
+// IR-AVX2: attributes {{.*}} = { {{.*}} "target-features"="{{.*}}+avx{{.*}}+avx2{{.*}}+sse{{.*}}+sse2{{.*}}+ssse3{{.*}}-avx512f{{.*}}-x87{{.*}}"
Index: clang/test/CodeGen/attr-target-general-regs-only-x86.c
===
--- /dev/null
+++ clang/test/CodeGen/attr-target-general-regs-only-x86.c
@@ -0,0 +1,14 @@
+// Test general-regs-only target attribute on x86
+
+// RUN: %clang_cc1 -triple i386-unknown-linux-gnu -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm %s -o - | FileCheck %s
+
+// CHECK: define{{.*}} void @f() [[GPR_ATTRS:#[0-9]+]]
+void __attribute__((target("general-regs-only"))) f() { }
+// CHECK: define{{.*}} void @f_before() [[GPR_ATTRS:#[0-9]+]]
+void __attribute__((target("avx2,general-regs-only"))) f_before() { }
+// CHECK: define{{.*}} void @f_after() [[AVX2_ATTRS:#[0-9]+]]
+void __attribute__((target("general-regs-only,avx2"))) f_after() { }
+
+// CHECK: attributes [[GPR_ATTRS]] = { {{.*}} "target-features"="{{.*}}-avx{{.*}}-avx2{{.*}}-avx512f{{.*}}-sse{{.*}}-sse2{{.*}}-ssse3{{.*}}-x87{{.*}}"
+// CHECK: attributes [[AVX2_ATTRS]] = { {{.*}} "target-features"="{{.*}}+avx{{.*}}+avx2{{.*}}+sse{{.*}}+sse2{{.*}}+ssse3{{.*}}-avx512f{{.*}}-x87{{.*}}"
Index: clang/lib/Driver/ToolChains/Arch/X86.cpp
===
--- clang/lib/Driver/ToolChains/Arch/X86.cpp
+++ clang/lib/Driver/ToolChains/Arch/X86.cpp
@@ -213,5 +213,24 @@
 
   // Now add any that the user explicitly requested on the command line,
   // which may override the defaults.
-  handleTargetFeaturesGroup(Args, Features, options::OPT_m_x86_Features_Group);
+  for (const Arg *A : Args.filtered(options::OPT_m_x86_Features_Group,
+options::OPT_mgeneral_regs_only)) {
+StringRef Name = A->getOption().getName();
+A->claim();
+
+// Skip over "-m".
+assert(Name.startswith("m") && "Invalid feature name.");
+Name = Name.substr(1);
+
+// Replace -mgeneral-regs-only with -x87, -mmx, -sse
+if (A->getOption().getID() == options::OPT_mgeneral_regs_only) {
+  Features.insert(Features.end(), {"-x87", "-mmx", "-sse"});
+  continue;
+}
+
+bool IsNegative = Name.startswith("no-");
+if (IsNegative)
+  Name = Name.substr(3);
+Features.push_back(Args.MakeAr

[PATCH] D104680: [clang] Eliminate relational function pointer comparisons in all C++ modes

2021-06-21 Thread Matheus Izvekov via Phabricator via cfe-commits
mizvekov created this revision.
mizvekov requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Word on the grapevine is that the committee recently had an unanimous
vote on eliminating relational function pointer comparisons.
There isn't any wording on it or anything, yet, but we must jump the gun here
and just do away with it pronto.

Signed-off-by: Matheus Izvekov 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104680

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/test/CXX/class/class.compare/class.spaceship/p2.cpp
  clang/test/CXX/drs/dr15xx.cpp
  clang/test/CXX/drs/dr3xx.cpp
  clang/test/CXX/expr/expr.const/p2-0x.cpp
  clang/test/SemaCXX/compare-cxx2a.cpp
  clang/test/SemaCXX/compare-function-pointer.cpp

Index: clang/test/SemaCXX/compare-function-pointer.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/compare-function-pointer.cpp
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c++20 -verify %s
+
+using fp_t = void (*)();
+extern fp_t a, b;
+
+bool eq = a == b;
+bool ne = a != b;
+bool lt = a < b;   // expected-error {{ordered comparison of function pointers ('fp_t' (aka 'void (*)()') and 'fp_t')}}
+bool le = a <= b;  // expected-error {{ordered comparison of function pointers}}
+bool gt = a > b;   // expected-error {{ordered comparison of function pointers}}
+bool ge = a >= b;  // expected-error {{ordered comparison of function pointers}}
+bool tw = a <=> b; // expected-error {{ordered comparison of function pointers}}
Index: clang/test/SemaCXX/compare-cxx2a.cpp
===
--- clang/test/SemaCXX/compare-cxx2a.cpp
+++ clang/test/SemaCXX/compare-cxx2a.cpp
@@ -212,8 +212,6 @@
 struct ClassB : Class {};
 struct Class2 {};
 using FnTy = void(int);
-using FnTy2 = long(int);
-using FnTy3 = void(int) noexcept;
 using MemFnTy = void (Class::*)() const;
 using MemDataTy = long(Class::*);
 
@@ -232,11 +230,6 @@
   (void)(md <=> md); // expected-error {{invalid operands}} expected-warning {{self-comparison}}
 }
 
-void test_compatible_pointer(FnTy *f1, FnTy2 *f2, FnTy3 *f3) {
-  (void)(f1 <=> f2); // expected-error {{distinct pointer types}}
-  (void)(f1 <=> f3); // expected-error {{invalid operands}}
-}
-
 // Test that variable narrowing is deferred for value dependent expressions
 template 
 auto test_template_overflow() {
Index: clang/test/CXX/expr/expr.const/p2-0x.cpp
===
--- clang/test/CXX/expr/expr.const/p2-0x.cpp
+++ clang/test/CXX/expr/expr.const/p2-0x.cpp
@@ -514,8 +514,7 @@
   void f(), g();
 
   constexpr void (*pf)() = &f, (*pg)() = &g;
-  constexpr bool u13 = pf < pg; // expected-error {{constant expression}} expected-note {{comparison has unspecified value}}
-  constexpr bool u14 = pf == pg;
+  constexpr bool u13 = pf == pg;
 
   // If two pointers point to non-static data members of the same object with
   // different access control, the result is unspecified.
Index: clang/test/CXX/drs/dr3xx.cpp
===
--- clang/test/CXX/drs/dr3xx.cpp
+++ clang/test/CXX/drs/dr3xx.cpp
@@ -18,9 +18,9 @@
   void operator-(S, S);
 
   void f() {
-bool a = (void(*)(S, S))operator+ <
+bool a = (void(*)(S, S))operator+ < // expected-error {{ordered comparison of function pointers}}
  (void(*)(S, S))operator+;
-bool b = (void(*)(S, S))operator- < // cxx20_2b-note {{to match this '<'}}
+bool b = (void(*)(S, S))operator- < // cxx20_2b-note {{to match this '<'}} cxx98_17-error {{ordered comparison of function pointers}}
  (void(*)(S, S))operator-; // cxx20_2b-error {{expected '>'}}
 bool c = (void(*)(S, S))operator+ < // expected-note {{to match this '<'}}
  (void(*)(S, S))operator-; // expected-error {{expected '>'}}
Index: clang/test/CXX/drs/dr15xx.cpp
===
--- clang/test/CXX/drs/dr15xx.cpp
+++ clang/test/CXX/drs/dr15xx.cpp
@@ -79,8 +79,8 @@
 no_composite_pointer_type();
 
 #if __cplusplus > 201402
-composite_pointer_type_is_ord();
-composite_pointer_type_is_ord();
+composite_pointer_type_is_unord();
+composite_pointer_type_is_unord();
 composite_pointer_type_is_unord();
 composite_pointer_type_is_unord();
 // FIXME: This looks like a standard defect; these should probably all have type 'int (B::*)()'.
Index: clang/test/CXX/class/class.compare/class.spaceship/p2.cpp
===
--- clang/test/CXX/class/class.compare/class.spaceship/p2.cpp
+++ clang/test/CXX/class/class.compare/class.spaceship/p2.cpp
@@ -159,7 +159,7 @@
 namespace PR48856 {
   struct A {
 auto operator<=>(const A &) c

[PATCH] D104677: [OpenMP] Apply fix for isnan, isinf and isinfinite for amdgcn.

2021-06-21 Thread Ethan Stewart via Phabricator via cfe-commits
estewart08 updated this revision to Diff 353527.
estewart08 added a comment.

Attempt to use clang-format.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104677

Files:
  clang/lib/Headers/__clang_hip_cmath.h
  clang/test/Headers/openmp_device_math_isnan.cpp

Index: clang/test/Headers/openmp_device_math_isnan.cpp
===
--- clang/test/Headers/openmp_device_math_isnan.cpp
+++ clang/test/Headers/openmp_device_math_isnan.cpp
@@ -1,11 +1,19 @@
 // RUN: %clang_cc1 -x c++ -internal-isystem %S/Inputs/include -fopenmp -triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm-bc %s -o %t-ppc-host.bc
+// RUN: %clang_cc1 -x c++ -internal-isystem %S/Inputs/include -fopenmp -triple powerpc64le-unknown-unknown -fopenmp-targets=amdgcn-amd-amdhsa -emit-llvm-bc %s -o %t-ppc-host.bc
 // RUN: %clang_cc1 -x c++ -include __clang_openmp_device_functions.h -internal-isystem %S/../../lib/Headers/openmp_wrappers -internal-isystem %S/Inputs/include -fopenmp -triple nvptx64-nvidia-cuda -aux-triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck %s --check-prefix=BOOL_RETURN
+// RUN: %clang_cc1 -x c++ -include __clang_openmp_device_functions.h -internal-isystem %S/../../lib/Headers/openmp_wrappers -internal-isystem %S/Inputs/include -fopenmp -triple amdgcn-amd-amdhsa -aux-triple powerpc64le-unknown-unknown -fopenmp-targets=amdgcn-amd-amdhsa -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck %s --check-prefix=AMD_BOOL_RETURN
 // RUN: %clang_cc1 -x c++ -internal-isystem %S/Inputs/include -fopenmp -triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm-bc %s -o %t-ppc-host.bc -ffast-math -ffp-contract=fast
+// RUN: %clang_cc1 -x c++ -internal-isystem %S/Inputs/include -fopenmp -triple powerpc64le-unknown-unknown -fopenmp-targets=amdgcn-amd-amdhsa -emit-llvm-bc %s -o %t-ppc-host.bc -ffast-math -ffp-contract=fast
 // RUN: %clang_cc1 -x c++ -include __clang_openmp_device_functions.h -internal-isystem %S/../../lib/Headers/openmp_wrappers -internal-isystem %S/Inputs/include -fopenmp -triple nvptx64-nvidia-cuda -aux-triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - -ffast-math -ffp-contract=fast | FileCheck %s --check-prefix=BOOL_RETURN
+// RUN: %clang_cc1 -x c++ -include __clang_openmp_device_functions.h -internal-isystem %S/../../lib/Headers/openmp_wrappers -internal-isystem %S/Inputs/include -fopenmp -triple amdgcn-amd-amdhsa -aux-triple powerpc64le-unknown-unknown -fopenmp-targets=amdgcn-amd-amdhsa -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - -ffast-math -ffp-contract=fast | FileCheck %s --check-prefix=AMD_BOOL_RETURN
 // RUN: %clang_cc1 -x c++ -internal-isystem %S/Inputs/include -fopenmp -triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm-bc %s -o %t-ppc-host.bc -DUSE_ISNAN_WITH_INT_RETURN
+// RUN: %clang_cc1 -x c++ -internal-isystem %S/Inputs/include -fopenmp -triple powerpc64le-unknown-unknown -fopenmp-targets=amdgcn-amd-amdhsa -emit-llvm-bc %s -o %t-ppc-host.bc -DUSE_ISNAN_WITH_INT_RETURN
 // RUN: %clang_cc1 -x c++ -include __clang_openmp_device_functions.h -internal-isystem %S/../../lib/Headers/openmp_wrappers -internal-isystem %S/Inputs/include -fopenmp -triple nvptx64-nvidia-cuda -aux-triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - -DUSE_ISNAN_WITH_INT_RETURN | FileCheck %s --check-prefix=INT_RETURN
+// RUN: %clang_cc1 -x c++ -include __clang_openmp_device_functions.h -internal-isystem %S/../../lib/Headers/openmp_wrappers -internal-isystem %S/Inputs/include -fopenmp -triple amdgcn-amd-amdhsa -aux-triple powerpc64le-unknown-unknown -fopenmp-targets=amdgcn-amd-amdhsa -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - -DUSE_ISNAN_WITH_INT_RETURN | FileCheck %s --check-prefix=AMD_INT_RETURN
 // RUN: %clang_cc1 -x c++ -internal-isystem %S/Inputs/include -fopenmp -triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm-bc %s -o %t-ppc-host.bc -ffast-math -ffp-contract=fast -DUSE_ISNAN_WITH_INT_RETURN
+// RUN: %clang_cc1 -x c++ -internal-isystem %S/Inputs/include -fopenmp -triple powerpc64le-unknown-unknown -fopenmp-targets=amdgcn-amd-amdhsa -emit-llvm-bc %s -o %t-ppc-host.bc -ffast-math -ffp-contract=fast -DUSE_ISNAN_WITH_INT_RETURN
 // RUN: %clang_cc1 -x c++ -include __clang_openmp_device_functions.h -internal-isystem %S/../../lib/Headers/openmp_wrappers -internal-isystem %S/Inputs/include -fopenmp -triple nvptx64-nvidia-cuda -aux-triple powerpc64le-unknown-unknown -fo

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

2021-06-21 Thread Manas Gupta via Phabricator via cfe-commits
manas added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:1395
+
+  if (Min > Max) {
+// This implies that an overflow has occured as either boundary would have

vsavchenko wrote:
> I commented on this part previously, you shouldn't get fixated on `Min > Max` 
> because `Max >= Min` doesn't imply that overflow didn't happen (less 
> important) and that the range `[Min, Max]` is correct (more important).  
> Recall one of the examples that I had in that email.
> 
> There is an interesting pattern about results that we can use:
> * no overflows happened -> `[Min, Max]` (should be always true)
> * 1 overflow happened -> we need to invert the range, but there are two 
> different cases:
> * `Min > Max`, perfect, that's what we expected -> `[Tmin, Max] ∪ [Min, 
> Tmax]`
> * `Max >= Min`, we overflowed and wrapped the whole range -> `[Tmin, 
> Tmax]`
> * 2 overflows happened on one side -> `[Min, Max]`
> * 2 overflows happened on both sides -> `[Tmin, Tmax]`
> 
> You need to think of this problem in terms of what really happens and not in 
> terms of combating with assertions.
I think I agree with you. This pattern (and the code following this pattern) 
makes much more sense, and easier to follow. I think I will refactor the patch 
accordingly. 


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

2021-06-21 Thread Manas Gupta via Phabricator via cfe-commits
manas added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:1411
+if ((LHS.From() < 0 && RHS.From() < 0)) {
+  llvm::APSInt CrucialPoint = Tmin - LHS.From();
+  if (RHS.Includes(CrucialPoint)) {

vsavchenko wrote:
> What if `LHS.From()` is `Tmin` for signed `T`?
> What if `T` is unsigned?  Does `Tmin - LHS.From()` (aka `0 - LHS.From()`) 
> make sense?
Even if `LHS.From()` is `Tmin` for signed `T` the reasoning would be correct. 
As, CrucialPoint will be `Zero` and hence RHS will be divided into two parts: 
BeforeZero (`[RHS.From, Zero]`) and AfterAndIncludingZero (`[Zero, RHS.To]`).

And if the BeforeZero subrange (which will be responsible for overflowing, 
contains `Tmin + Tmax` then we can ensure that the final range will be `[Tmin, 
Tmax]`. And if it does not, (and assuming there is no overflow on the right 
side), then `1432:1434` will reason the range to be `[Tmin, Max] U [Min, Tmax]`.

For unsigned types, actually we are asking the wrong question because an 
addition of unsigned integers can never overflow from the left side. So in that 
case, the code deducing the overflows from left-side will not be applicable. 
And therefore, `0 - LHS.From()` will never give us anything. I was thinking to 
checked T before applying these rules.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:1448-1451
+  if ((LHS.From() > 0 && RHS.From() > 0 && Min < 0) ||
+  (LHS.From() < 0 && RHS.From() < 0 && Min > 0) ||
+  (LHS.To() > 0 && RHS.To() > 0 && Max < 0) ||
+  (LHS.To() < 0 && RHS.To() < 0 && Max > 0)) {

vsavchenko wrote:
> Speaking of unsigned `T`, does it work for unsigned overflows?  Do we have 
> tests for that?
This was not going to make into the patch as it does not solve the case 
mentioned in FIXME(:1437).

An idea which I had in the previous post was this:

> 1. If one of Min/Max overflows while the other doesn't then the resulting 
> range should be [Tmin, Tmax] as Min <= Max even after overflowing.
> 2. If both of them overflows, then: a. If both overflows on the same side, 
> that is, both wrapped around Tmax, or both wrapped around Tmin, then the 
> range should be [Min, Max] only. b. But if both overflowed in different 
> sides, supposedly Min overflowed on left and Max on right, or vice versa, 
> then the range will be [Tmin, Tmax].



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] D104677: [OpenMP] Apply fix for isnan, isinf and isinfinite for amdgcn.

2021-06-21 Thread Ethan Stewart via Phabricator via cfe-commits
estewart08 created this revision.
Herald added subscribers: guansong, yaxunl.
estewart08 requested review of this revision.
Herald added a reviewer: jdoerfert.
Herald added subscribers: cfe-commits, sstefan1.
Herald added a project: clang.

This fixes issues with various return types(bool/int) and was already
in place for nvptx headers, adjusted to work for amdgcn.
Similar to D85879 .


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104677

Files:
  clang/lib/Headers/__clang_hip_cmath.h
  clang/test/Headers/openmp_device_math_isnan.cpp

Index: clang/test/Headers/openmp_device_math_isnan.cpp
===
--- clang/test/Headers/openmp_device_math_isnan.cpp
+++ clang/test/Headers/openmp_device_math_isnan.cpp
@@ -1,11 +1,19 @@
 // RUN: %clang_cc1 -x c++ -internal-isystem %S/Inputs/include -fopenmp -triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm-bc %s -o %t-ppc-host.bc
+// RUN: %clang_cc1 -x c++ -internal-isystem %S/Inputs/include -fopenmp -triple powerpc64le-unknown-unknown -fopenmp-targets=amdgcn-amd-amdhsa -emit-llvm-bc %s -o %t-ppc-host.bc
 // RUN: %clang_cc1 -x c++ -include __clang_openmp_device_functions.h -internal-isystem %S/../../lib/Headers/openmp_wrappers -internal-isystem %S/Inputs/include -fopenmp -triple nvptx64-nvidia-cuda -aux-triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck %s --check-prefix=BOOL_RETURN
+// RUN: %clang_cc1 -x c++ -include __clang_openmp_device_functions.h -internal-isystem %S/../../lib/Headers/openmp_wrappers -internal-isystem %S/Inputs/include -fopenmp -triple amdgcn-amd-amdhsa -aux-triple powerpc64le-unknown-unknown -fopenmp-targets=amdgcn-amd-amdhsa -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck %s --check-prefix=AMD_BOOL_RETURN
 // RUN: %clang_cc1 -x c++ -internal-isystem %S/Inputs/include -fopenmp -triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm-bc %s -o %t-ppc-host.bc -ffast-math -ffp-contract=fast
+// RUN: %clang_cc1 -x c++ -internal-isystem %S/Inputs/include -fopenmp -triple powerpc64le-unknown-unknown -fopenmp-targets=amdgcn-amd-amdhsa -emit-llvm-bc %s -o %t-ppc-host.bc -ffast-math -ffp-contract=fast
 // RUN: %clang_cc1 -x c++ -include __clang_openmp_device_functions.h -internal-isystem %S/../../lib/Headers/openmp_wrappers -internal-isystem %S/Inputs/include -fopenmp -triple nvptx64-nvidia-cuda -aux-triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - -ffast-math -ffp-contract=fast | FileCheck %s --check-prefix=BOOL_RETURN
+// RUN: %clang_cc1 -x c++ -include __clang_openmp_device_functions.h -internal-isystem %S/../../lib/Headers/openmp_wrappers -internal-isystem %S/Inputs/include -fopenmp -triple amdgcn-amd-amdhsa -aux-triple powerpc64le-unknown-unknown -fopenmp-targets=amdgcn-amd-amdhsa -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - -ffast-math -ffp-contract=fast | FileCheck %s --check-prefix=AMD_BOOL_RETURN
 // RUN: %clang_cc1 -x c++ -internal-isystem %S/Inputs/include -fopenmp -triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm-bc %s -o %t-ppc-host.bc -DUSE_ISNAN_WITH_INT_RETURN
+// RUN: %clang_cc1 -x c++ -internal-isystem %S/Inputs/include -fopenmp -triple powerpc64le-unknown-unknown -fopenmp-targets=amdgcn-amd-amdhsa -emit-llvm-bc %s -o %t-ppc-host.bc -DUSE_ISNAN_WITH_INT_RETURN
 // RUN: %clang_cc1 -x c++ -include __clang_openmp_device_functions.h -internal-isystem %S/../../lib/Headers/openmp_wrappers -internal-isystem %S/Inputs/include -fopenmp -triple nvptx64-nvidia-cuda -aux-triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - -DUSE_ISNAN_WITH_INT_RETURN | FileCheck %s --check-prefix=INT_RETURN
+// RUN: %clang_cc1 -x c++ -include __clang_openmp_device_functions.h -internal-isystem %S/../../lib/Headers/openmp_wrappers -internal-isystem %S/Inputs/include -fopenmp -triple amdgcn-amd-amdhsa -aux-triple powerpc64le-unknown-unknown -fopenmp-targets=amdgcn-amd-amdhsa -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - -DUSE_ISNAN_WITH_INT_RETURN | FileCheck %s --check-prefix=AMD_INT_RETURN
 // RUN: %clang_cc1 -x c++ -internal-isystem %S/Inputs/include -fopenmp -triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm-bc %s -o %t-ppc-host.bc -ffast-math -ffp-contract=fast -DUSE_ISNAN_WITH_INT_RETURN
+// RUN: %clang_cc1 -x c++ -internal-isystem %S/Inputs/include -fopenmp -triple powerpc64le-unknown-unknown -fopenmp-targets=amdgcn-amd-amdhsa -emit-llvm-bc %s -o %t-ppc-host.bc -ffast-math -ffp-contract=fast -DUSE_ISNAN_WITH_INT_R

[PATCH] D104619: [clang] [WIP] Respect PrintingPolicy::FullyQualifiedName when printing a template-id

2021-06-21 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added a comment.

In D104619#2831956 , @nridge wrote:

> Thanks for having a look!
>
> In D104619#2831953 , @dblaikie 
> wrote:
>
>> This'll need a test case
>
> Definitely. Do you have a suggestion for what test suite that should go into? 
> I had a quick look but couldn't find anything that obviously exercised 
> `TypePrinter`.

One way you could find some places this might be tested would be to introduce a 
deliberate break in the code somehow - like changing this parameter to be 
"true" instead of false - and then running the tests to see what fails. But I 
think the problem is likely that the tests all want the existing behavior/never 
tweak the Policy in this context.

So likely what you'd need would be a unit test of some kind (check around in 
clang/unittests to see if there are other AST pretty printer tests, for 
instance).

>> & does the change pass all existing tests?
>
> I mainly pushed the patch to Phabricator in this WIP form because I was 
> hoping that would trigger some sort of CI run that would tell me that :) (I 
> tried running `ninja check-clang` locally, but that was looking to take a 
> very long time (like 2+ hours) to run locally.)

Hmm - what sort of machine config do you have? What build configuration were 
you building/running with?

> It's not clear to me if that actually happened? I see something about 
> "pre-merge checks" in the revision metadata (and they're green), but it's not 
> clear to me what test suites it actually ran.

Yeah, it looks like some tests ran: 
https://buildkite.com/llvm-project/premerge-checks/builds/44109 (if you follow 
from the "Build 157317: pre-merge checks" under the patch description, then 
copy/paste the URL from somewhere in there you'll get to that build info


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104619

___
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

2021-06-21 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay updated this revision to Diff 353519.
MaskRay edited the summary of this revision.
MaskRay added a comment.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Mention the one-time exception for .profraw compatibility


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104556

Files:
  clang/test/Profile/c-linkage-available_externally.c
  compiler-rt/include/profile/InstrProfData.inc
  compiler-rt/lib/profile/InstrProfilingMerge.c
  compiler-rt/lib/profile/InstrProfilingWriter.c
  llvm/include/llvm/ProfileData/InstrProfData.inc
  llvm/include/llvm/ProfileData/InstrProfReader.h
  llvm/lib/ProfileData/InstrProfReader.cpp
  llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp
  llvm/test/Instrumentation/InstrProfiling/icall.ll
  llvm/test/Instrumentation/InstrProfiling/profiling.ll
  llvm/test/Transforms/PGOProfile/comdat_internal.ll
  llvm/test/Transforms/PGOProfile/indirect_call_profile.ll
  llvm/test/Transforms/PGOProfile/memcpy.ll
  llvm/test/tools/llvm-profdata/Inputs/c-general.profraw
  llvm/test/tools/llvm-profdata/c-general.test
  llvm/test/tools/llvm-profdata/malformed-ptr-to-counter-array.test
  llvm/test/tools/llvm-profdata/raw-32-bits-be.test
  llvm/test/tools/llvm-profdata/raw-32-bits-le.test
  llvm/test/tools/llvm-profdata/raw-64-bits-be.test
  llvm/test/tools/llvm-profdata/raw-64-bits-le-v5.test
  llvm/test/tools/llvm-profdata/raw-64-bits-le.test
  llvm/test/tools/llvm-profdata/raw-two-profiles.test

Index: llvm/test/tools/llvm-profdata/raw-two-profiles.test
===
--- llvm/test/tools/llvm-profdata/raw-two-profiles.test
+++ llvm/test/tools/llvm-profdata/raw-two-profiles.test
@@ -1,5 +1,5 @@
 RUN: printf '\201rforpl\377' > %t-foo.profraw
-RUN: printf '\5\0\0\0\0\0\0\0' >> %t-foo.profraw
+RUN: printf '\6\0\0\0\0\0\0\0' >> %t-foo.profraw
 RUN: printf '\1\0\0\0\0\0\0\0' >> %t-foo.profraw
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t-foo.profraw
 RUN: printf '\1\0\0\0\0\0\0\0' >> %t-foo.profraw
@@ -20,7 +20,7 @@
 RUN: printf '\3\0foo\0\0\0' >> %t-foo.profraw
 
 RUN: printf '\201rforpl\377' > %t-bar.profraw
-RUN: printf '\5\0\0\0\0\0\0\0' >> %t-bar.profraw
+RUN: printf '\6\0\0\0\0\0\0\0' >> %t-bar.profraw
 RUN: printf '\1\0\0\0\0\0\0\0' >> %t-bar.profraw
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t-bar.profraw
 RUN: printf '\2\0\0\0\0\0\0\0' >> %t-bar.profraw
Index: llvm/test/tools/llvm-profdata/raw-64-bits-le.test
===
--- llvm/test/tools/llvm-profdata/raw-64-bits-le.test
+++ llvm/test/tools/llvm-profdata/raw-64-bits-le.test
@@ -1,5 +1,5 @@
 RUN: printf '\201rforpl\377' > %t
-RUN: printf '\5\0\0\0\0\0\0\0' >> %t
+RUN: printf '\6\0\0\0\0\0\0\0' >> %t
 RUN: printf '\2\0\0\0\0\0\0\0' >> %t
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t
 RUN: printf '\3\0\0\0\0\0\0\0' >> %t
@@ -18,7 +18,7 @@
 
 RUN: printf '\067\265\035\031\112\165\023\344' >> %t
 RUN: printf '\02\0\0\0\0\0\0\0' >> %t
-RUN: printf '\10\0\4\0\1\0\0\0' >> %t
+RUN: printf '\xd8\xff\3\0\1\0\0\0' >> %t
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t
 RUN: printf '\02\0\0\0\0\0\0\0' >> %t
Index: llvm/test/tools/llvm-profdata/raw-64-bits-le-v5.test
===
--- llvm/test/tools/llvm-profdata/raw-64-bits-le-v5.test
+++ llvm/test/tools/llvm-profdata/raw-64-bits-le-v5.test
@@ -1,3 +1,6 @@
+Test we can read the 64-bit version 5 raw profile format.
+TODO Drop the support after 13.0.0 is branched.
+
 RUN: printf '\201rforpl\377' > %t
 RUN: printf '\5\0\0\0\0\0\0\0' >> %t
 RUN: printf '\2\0\0\0\0\0\0\0' >> %t
Index: llvm/test/tools/llvm-profdata/raw-64-bits-be.test
===
--- llvm/test/tools/llvm-profdata/raw-64-bits-be.test
+++ llvm/test/tools/llvm-profdata/raw-64-bits-be.test
@@ -1,5 +1,5 @@
 RUN: printf '\377lprofr\201' > %t
-RUN: printf '\0\0\0\0\0\0\0\5' >> %t
+RUN: printf '\0\0\0\0\0\0\0\6' >> %t
 RUN: printf '\0\0\0\0\0\0\0\2' >> %t
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t
 RUN: printf '\0\0\0\0\0\0\0\3' >> %t
@@ -18,7 +18,7 @@
 
 RUN: printf '\344\023\165\112\031\035\265\067' >> %t
 RUN: printf '\0\0\0\0\0\0\0\02' >> %t
-RUN: printf '\0\0\0\1\0\4\0\10' >> %t
+RUN: printf '\0\0\0\1\0\3\xff\xd8' >> %t
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t
 RUN: printf '\0\0\0\02\0\0\0\0' >> %t
Index: llvm/test/tools/llvm-profdata/raw-32-bits-le.test
===
--- llvm/test/tools/llvm-profdata/raw-32-bits-le.test
+++ llvm/test/tools/llvm-profdata/raw-32-bits-le.test
@@ -1,5 +1,5 @@
 RUN: printf '\201Rforpl\377' > %t
-RUN: printf '\5\0\0\0\0\0\0\0' >> %t
+RUN: printf '\6\0\0\0\0\0\0\0' >> %t
 RUN: printf '\2\0\0\0\0\0\0\0' >> %t
 RUN: printf '\0\0\0\0\0\0\0\0' >> %t
 RUN: printf '\3\0\0\0\0\0\0\0' >> %t
@@ -19,7 +19,7 @

[PATCH] D104619: [clang] [WIP] Fix for https://bugs.llvm.org/show_bug.cgi?id=50774

2021-06-21 Thread Nathan Ridge via Phabricator via cfe-commits
nridge added a comment.

Thanks for having a look!

In D104619#2831953 , @dblaikie wrote:

> This'll need a test case

Definitely. Do you have a suggestion for what test suite that should go into? I 
had a quick look but couldn't find anything that obviously exercised 
`TypePrinter`.

> & does the change pass all existing tests?

I mainly pushed the patch to Phabricator in this WIP form because I was hoping 
that would trigger some sort of CI run that would tell me that :) (I tried 
running `ninja check-clang` locally, but that was looking to take a very long 
time (like 2+ hours) to run locally.)

It's not clear to me if that actually happened? I see something about 
"pre-merge checks" in the revision metadata, but it's not clear to me what test 
suites it actually ran.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104619

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


[PATCH] D104619: [clang] [WIP] Fix for https://bugs.llvm.org/show_bug.cgi?id=50774

2021-06-21 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added a comment.

This'll need a test case & does the change pass all existing tests?
Also, the patch description could use more detail - it can refer to the bug for 
more context, but there should be enough detail in the patch title/description 
to understand the general purpose, etc. (and you can shorten the bug reference 
to "PR50774" rather than the whole bugs.llvm.org URL)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104619

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


[PATCH] D104601: [Preprocessor] Implement -fnormalize-whitespace.

2021-06-21 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added a comment.

One of the concerns I'd have, for instance (have you done some broad testing of 
these patches on sizable code bases?) is that it wouldn't surprise me if clang 
had some scalability bugs/issues with very long source lines - so it might be 
necessary to introduce some (arbitrary?) newlines to break up the code. Though 
I'm not sure - no need to do that pre-emptively, but might be good to have some 
data that indicates whether this might be a problem or not.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104601

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


[PATCH] D104601: [Preprocessor] Implement -fnormalize-whitespace.

2021-06-21 Thread Michael Kruse via Phabricator via cfe-commits
Meinersbur added a comment.

Some bikeshedding: Calls to `AvoidConcat` could be avoided by always inserting 
a space between tokens at the cost of making the output larger. In the current 
form, the flag could also be named `-fminimize-whitespace`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104601

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


[PATCH] D104601: [Preprocessor] Implement -fnormalize-whitespace.

2021-06-21 Thread Michael Kruse via Phabricator via cfe-commits
Meinersbur added a comment.

In D104601#2831746 , @dblaikie wrote:

> This is probably more @aaron.ballman 's wheelhouse, but for my money this 
> seems pretty problematic - will make quoted text in compiler diagnostics 
> weird/difficult to read, etc.

It is not meant for human readability but automatic processing. The linked 
ccache patch either re-runs the compiler with on the original source file if 
there is any diagnostic output (run_second_cpp=false) or(inclusive) uses the 
preprocessor output only to determine whether there was a significant change in 
the first place (run_second_cpp=true, default).

To discourage use by humans, we could make the flag available only behind 
`-Xclang`, but I'd expect people to only use the flag if they have a need for 
it anyway. Compiler diagnostics invoked on `-E -P` output is already not very 
useful; `-fnormalize-whitespace` would potentially cause the entire source be 
on a single line. If this is a show-stopper, I could try making the 
diagnostic's quoted text print only an excerpt of a line if it becomes too long.

> Do you have a particular use case that has exceptionally frequent 
> whitespace-only changes?

Every edit of a (multi-line) comment and running of clang-format. The former 
makes me hesitant to improve comments in central header files because I know it 
means that I have to rebuild the entire code base; it should not be a reason to 
not improve documentation. The latter is best-practice before any commit. 
Again, if it includes a central header file, it means rebuilding significant 
portions.

ccache uses preprocessor mode by default while it also supports strict binary 
comparison ("direct mode") and I assume there is a reason for this. However, 
every non-intra-line change causes the preprocessor output to change due to the 
line number in the #line directive changing, making the preprocessor mode much 
less effective than it could be. Very few NF changes take place within a single 
line only.

Unlike gcc, clang's `-E -P` output still includes empty lines (unless there are 
more than 8 consecutive empty lines). That is, there is hardly a benefit to use 
`-P` output in ccache with clang.

> Or is this something you think would be generally applicable? How applicable, 
> do you think? Do you have some data showing a % of rebuilds that would be 
> avoided in practice/based on real code bases, etc?

If it supports my case, I can work with builds using ccache for a while: one 
configured using -fnormalize-whitespace, the other without, and compare ccache 
statistics. I have used it already, but never comparatively over the same time 
frame. However, I think the above argument is already pretty good.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104601

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


[PATCH] D104664: [PowerPC][NFC] Clean up builtin sema checks

2021-06-21 Thread Lei Huang via Phabricator via cfe-commits
lei updated this revision to Diff 353515.
lei added a comment.

remove extra ";"


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104664

Files:
  clang/lib/Sema/SemaChecking.cpp


Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -3255,34 +3255,33 @@
   }
 }
 
+static bool isPPC_64Builtin(unsigned BuiltinID) {
+  // These builtins only work on PPC 64bit targets.
+  switch (BuiltinID) {
+  case PPC::BI__builtin_divde:
+  case PPC::BI__builtin_divdeu:
+  case PPC::BI__builtin_bpermd:
+return true;
+  }
+  return false;
+}
+
+static bool SemaFeatureCheck(Sema &S, CallExpr *TheCall,
+ StringRef FeatureToCheck, unsigned DiagID) {
+  if (!S.Context.getTargetInfo().hasFeature(FeatureToCheck))
+return S.Diag(TheCall->getBeginLoc(), DiagID) << TheCall->getSourceRange();
+  return false;
+}
+
 bool Sema::CheckPPCBuiltinFunctionCall(const TargetInfo &TI, unsigned 
BuiltinID,
CallExpr *TheCall) {
   unsigned i = 0, l = 0, u = 0;
-  bool Is64BitBltin = BuiltinID == PPC::BI__builtin_divde ||
-  BuiltinID == PPC::BI__builtin_divdeu ||
-  BuiltinID == PPC::BI__builtin_bpermd;
   bool IsTarget64Bit = TI.getTypeWidth(TI.getIntPtrType()) == 64;
-  bool IsBltinExtDiv = BuiltinID == PPC::BI__builtin_divwe ||
-   BuiltinID == PPC::BI__builtin_divweu ||
-   BuiltinID == PPC::BI__builtin_divde ||
-   BuiltinID == PPC::BI__builtin_divdeu;
 
-  if (Is64BitBltin && !IsTarget64Bit)
+  if (isPPC_64Builtin(BuiltinID) && !IsTarget64Bit)
 return Diag(TheCall->getBeginLoc(), diag::err_64_bit_builtin_32_bit_tgt)
<< TheCall->getSourceRange();
 
-  if ((IsBltinExtDiv && !TI.hasFeature("extdiv")) ||
-  (BuiltinID == PPC::BI__builtin_bpermd && !TI.hasFeature("bpermd")))
-return Diag(TheCall->getBeginLoc(), diag::err_ppc_builtin_only_on_pwr7)
-   << TheCall->getSourceRange();
-
-  auto SemaVSXCheck = [&](CallExpr *TheCall) -> bool {
-if (!TI.hasFeature("vsx"))
-  return Diag(TheCall->getBeginLoc(), diag::err_ppc_builtin_only_on_pwr7)
- << TheCall->getSourceRange();
-return false;
-  };
-
   switch (BuiltinID) {
   default: return false;
   case PPC::BI__builtin_altivec_crypto_vshasigmaw:
@@ -3308,11 +3307,22 @@
   case PPC::BI__builtin_vsx_xxpermdi:
   case PPC::BI__builtin_vsx_xxsldwi:
 return SemaBuiltinVSX(TheCall);
+  case PPC::BI__builtin_divwe:
+  case PPC::BI__builtin_divweu:
+  case PPC::BI__builtin_divde:
+  case PPC::BI__builtin_divdeu:
+return SemaFeatureCheck(*this, TheCall, "extdiv",
+diag::err_ppc_builtin_only_on_pwr7);
+  case PPC::BI__builtin_bpermd:
+return SemaFeatureCheck(*this, TheCall, "bpermd",
+diag::err_ppc_builtin_only_on_pwr7);
   case PPC::BI__builtin_unpack_vector_int128:
-return SemaVSXCheck(TheCall) ||
+return SemaFeatureCheck(*this, TheCall, "vsx",
+diag::err_ppc_builtin_only_on_pwr7) ||
SemaBuiltinConstantArgRange(TheCall, 1, 0, 1);
   case PPC::BI__builtin_pack_vector_int128:
-return SemaVSXCheck(TheCall);
+return SemaFeatureCheck(*this, TheCall, "vsx",
+diag::err_ppc_builtin_only_on_pwr7);
   case PPC::BI__builtin_altivec_vgnb:
  return SemaBuiltinConstantArgRange(TheCall, 1, 2, 7);
   case PPC::BI__builtin_altivec_vec_replace_elt:


Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -3255,34 +3255,33 @@
   }
 }
 
+static bool isPPC_64Builtin(unsigned BuiltinID) {
+  // These builtins only work on PPC 64bit targets.
+  switch (BuiltinID) {
+  case PPC::BI__builtin_divde:
+  case PPC::BI__builtin_divdeu:
+  case PPC::BI__builtin_bpermd:
+return true;
+  }
+  return false;
+}
+
+static bool SemaFeatureCheck(Sema &S, CallExpr *TheCall,
+ StringRef FeatureToCheck, unsigned DiagID) {
+  if (!S.Context.getTargetInfo().hasFeature(FeatureToCheck))
+return S.Diag(TheCall->getBeginLoc(), DiagID) << TheCall->getSourceRange();
+  return false;
+}
+
 bool Sema::CheckPPCBuiltinFunctionCall(const TargetInfo &TI, unsigned BuiltinID,
CallExpr *TheCall) {
   unsigned i = 0, l = 0, u = 0;
-  bool Is64BitBltin = BuiltinID == PPC::BI__builtin_divde ||
-  BuiltinID == PPC::BI__builtin_divdeu ||
-  BuiltinID == PPC::BI__builtin_bpermd;
   bool IsTarget64Bit = TI.getTypeWidth(TI.getIntPtrType()) == 64;
-  bool IsBltinExtDiv = BuiltinID == PPC::BI__builtin_divwe ||
-   BuiltinID 

[PATCH] D104667: Improve the diagnostic of DiagnosticInfoResourceLimit (and warn-stack-size in particular)

2021-06-21 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay updated this revision to Diff 353510.
MaskRay added a comment.

rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104667

Files:
  clang/test/Misc/backend-resource-limit-diagnostics.cl
  clang/test/Misc/backend-stack-frame-diagnostics-fallback.cpp
  llvm/include/llvm/IR/DiagnosticInfo.h
  llvm/lib/CodeGen/PrologEpilogInserter.cpp
  llvm/lib/IR/DiagnosticInfo.cpp
  llvm/test/CodeGen/AMDGPU/exceed-max-sgprs.ll
  llvm/test/CodeGen/AMDGPU/stack-size-overflow.ll
  llvm/test/CodeGen/ARM/warn-stack.ll
  llvm/test/CodeGen/X86/warn-stack.ll

Index: llvm/test/CodeGen/X86/warn-stack.ll
===
--- llvm/test/CodeGen/X86/warn-stack.ll
+++ llvm/test/CodeGen/X86/warn-stack.ll
@@ -1,5 +1,5 @@
 ; RUN: llc -mtriple x86_64-apple-macosx10.8.0 < %s 2>&1 >/dev/null | FileCheck %s
-; Check the internal option that warns when the stack size exceeds the
+; Check the internal option that warns when the stack frame size exceeds the
 ; given amount.
 ; 
 
@@ -12,7 +12,7 @@
   ret void
 }
 
-; CHECK: warning: stack size limit exceeded (88) in warn
+; CHECK: warning: stack frame size (88) exceeds limit (80) in function 'warn'
 define void @warn() nounwind ssp "warn-stack-size"="80" {
 entry:
   %buffer = alloca [80 x i8], align 1
Index: llvm/test/CodeGen/ARM/warn-stack.ll
===
--- llvm/test/CodeGen/ARM/warn-stack.ll
+++ llvm/test/CodeGen/ARM/warn-stack.ll
@@ -1,5 +1,5 @@
 ; RUN: llc -mtriple thumbv7-apple-ios3.0.0 < %s 2>&1 >/dev/null | FileCheck %s
-; Check the internal option that warns when the stack size exceeds the
+; Check the internal option that warns when the stack frame size exceeds the
 ; given amount.
 ; 
 
@@ -12,7 +12,7 @@
   ret void
 }
 
-; CHECK: warning: stack size limit exceeded (92) in warn
+; CHECK: warning: stack frame size (92) exceeds limit (80) in function 'warn'
 define void @warn() nounwind ssp "frame-pointer"="all" "warn-stack-size"="80" {
 entry:
   %buffer = alloca [80 x i8], align 1
Index: llvm/test/CodeGen/AMDGPU/stack-size-overflow.ll
===
--- llvm/test/CodeGen/AMDGPU/stack-size-overflow.ll
+++ llvm/test/CodeGen/AMDGPU/stack-size-overflow.ll
@@ -3,7 +3,7 @@
 
 declare void @llvm.memset.p5i8.i32(i8 addrspace(5)* nocapture, i8, i32, i32, i1) #1
 
-; ERROR: error: stack size limit exceeded (131061) in stack_size_limit_wave64
+; ERROR: error: stack frame size (131061) exceeds limit in function 'stack_size_limit_wave64'
 ; GCN: ; ScratchSize: 131061
 define amdgpu_kernel void @stack_size_limit_wave64() #0 {
 entry:
@@ -13,7 +13,7 @@
   ret void
 }
 
-; ERROR: error: stack size limit exceeded (262117) in stack_size_limit_wave32
+; ERROR: error: stack frame size (262117) exceeds limit in function 'stack_size_limit_wave32'
 ; GCN: ; ScratchSize: 262117
 define amdgpu_kernel void @stack_size_limit_wave32() #1 {
 entry:
Index: llvm/test/CodeGen/AMDGPU/exceed-max-sgprs.ll
===
--- llvm/test/CodeGen/AMDGPU/exceed-max-sgprs.ll
+++ llvm/test/CodeGen/AMDGPU/exceed-max-sgprs.ll
@@ -1,6 +1,6 @@
 ; RUN: not llc -march=amdgcn -verify-machineinstrs < %s 2>&1 | FileCheck -check-prefix=ERROR %s
 
-; ERROR: error: scalar registers limit of 104 exceeded (106) in use_too_many_sgprs_tahiti
+; ERROR: error: scalar registers (106) exceeds limit (104) in function 'use_too_many_sgprs_tahiti'
 define amdgpu_kernel void @use_too_many_sgprs_tahiti() #0 {
   call void asm sideeffect "", "~{s[0:7]}" ()
   call void asm sideeffect "", "~{s[8:15]}" ()
@@ -19,7 +19,7 @@
   ret void
 }
 
-; ERROR: error: scalar registers limit of 104 exceeded (106) in use_too_many_sgprs_bonaire
+; ERROR: error: scalar registers (106) exceeds limit (104) in function 'use_too_many_sgprs_bonaire'
 define amdgpu_kernel void @use_too_many_sgprs_bonaire() #1 {
   call void asm sideeffect "", "~{s[0:7]}" ()
   call void asm sideeffect "", "~{s[8:15]}" ()
@@ -38,7 +38,7 @@
   ret void
 }
 
-; ERROR: error: scalar registers limit of 104 exceeded (108) in use_too_many_sgprs_bonaire_flat_scr
+; ERROR: error: scalar registers (108) exceeds limit (104) in function 'use_too_many_sgprs_bonaire_flat_scr'
 define amdgpu_kernel void @use_too_many_sgprs_bonaire_flat_scr() #1 {
   call void asm sideeffect "", "~{s[0:7]}" ()
   call void asm sideeffect "", "~{s[8:15]}" ()
@@ -58,7 +58,7 @@
   ret void
 }
 
-; ERROR: error: scalar registers limit of 96 exceeded (98) in use_too_many_sgprs_iceland
+; ERROR: error: scalar registers (98) exceeds limit (96) in function 'use_too_many_sgprs_iceland'
 define amdgpu_kernel void @use_too_many_sgprs_iceland() #2 {
   call void asm sideeffect "", "~{vcc}" ()
   call void asm sideeffect "", "~{s[0:7]}" ()
@@ -76,7 +76,7 @@
   ret void
 }
 
-; ERROR: error: addressable scalar registers limit of 102 exc

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

2021-06-21 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

In D104505#2831644 , @yaxunl wrote:

> However, this does cause source level incompatibilities, i.e. CUDA code that 
> passes nvcc does not pass clang. This patch somehow addresses that without 
> compromising clang's more sophisticated `__host__/__device__` overloading 
> resolution capabilities.

Yes. This will not be the first time where clang does diagnose invalid code 
while NVCC does not.
In general, some amount of source code porting between nvcc and clang is 
expected. In practice the amount of work required to make CUDA code portable 
has been relatively minor.

My general rule of thumb is that if both host and device compilation have 
enough information to diagnose a problem, both should do it.
In this case, there's no ambiguity that the code is invalid. The sooner we 
diagnose it, the better.

Is there particular use case where this patch would be necessary?


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

https://reviews.llvm.org/D104505

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


[PATCH] D100139: [ifs][elfabi] Merge llvm-ifs/elfabi tools

2021-06-21 Thread Haowei Wu via Phabricator via cfe-commits
haowei updated this revision to Diff 353507.
haowei marked 3 inline comments as done.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100139

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake
  clang/lib/Driver/ToolChains/InterfaceStubs.cpp
  clang/test/InterfaceStubs/driver-test.c
  llvm/include/llvm/InterfaceStub/ELFObjHandler.h
  llvm/include/llvm/InterfaceStub/IFSHandler.h
  llvm/include/llvm/InterfaceStub/IFSStub.h
  llvm/lib/InterfaceStub/ELFObjHandler.cpp
  llvm/lib/InterfaceStub/IFSHandler.cpp
  llvm/lib/InterfaceStub/IFSStub.cpp
  llvm/test/CMakeLists.txt
  llvm/test/tools/llvm-ifs/binary-read-add-soname.test
  llvm/test/tools/llvm-ifs/binary-read-arch.test
  llvm/test/tools/llvm-ifs/binary-read-bad-soname.test
  llvm/test/tools/llvm-ifs/binary-read-bad-vaddr.test
  llvm/test/tools/llvm-ifs/binary-read-neededlibs-bad-offset.test
  llvm/test/tools/llvm-ifs/binary-read-neededlibs.test
  llvm/test/tools/llvm-ifs/binary-read-no-dt-strsz.test
  llvm/test/tools/llvm-ifs/binary-read-no-dt-strtab.test
  llvm/test/tools/llvm-ifs/binary-read-no-dynamic.test
  llvm/test/tools/llvm-ifs/binary-read-replace-soname.test
  llvm/test/tools/llvm-ifs/binary-read-soname-no-null.test
  llvm/test/tools/llvm-ifs/binary-read-soname.test
  llvm/test/tools/llvm-ifs/binary-read-syms-gnu-hash.test
  llvm/test/tools/llvm-ifs/binary-read-syms-sysv-hash.test
  llvm/test/tools/llvm-ifs/conflict-header-triple.ifs
  llvm/test/tools/llvm-ifs/conflict-header-version.ifs
  llvm/test/tools/llvm-ifs/conflict-size.ifs
  llvm/test/tools/llvm-ifs/conflict-type.ifs
  llvm/test/tools/llvm-ifs/conflict-weak.ifs
  llvm/test/tools/llvm-ifs/default-empty.ifs
  llvm/test/tools/llvm-ifs/empty1.ifs
  llvm/test/tools/llvm-ifs/empty2.ifs
  llvm/test/tools/llvm-ifs/fail-file-open.test
  llvm/test/tools/llvm-ifs/fail-file-write-windows.test
  llvm/test/tools/llvm-ifs/fail-file-write.test
  llvm/test/tools/llvm-ifs/func.ifs
  llvm/test/tools/llvm-ifs/ifs-emits-current-version.test
  llvm/test/tools/llvm-ifs/ifs-read-basic.test
  llvm/test/tools/llvm-ifs/ios-tbd.ifs
  llvm/test/tools/llvm-ifs/macos-tbd.ifs
  llvm/test/tools/llvm-ifs/object-function-size-weak-combo.ifs
  llvm/test/tools/llvm-ifs/object.ifs
  llvm/test/tools/llvm-ifs/output-target-error.test
  llvm/test/tools/llvm-ifs/preserve-dates-ifs.test
  llvm/test/tools/llvm-ifs/preserve-dates-stub.test
  llvm/test/tools/llvm-ifs/read-elf-dynsym.test
  llvm/test/tools/llvm-ifs/read-ifs-as-elf.test
  llvm/test/tools/llvm-ifs/read-ifs-as-ifs.test
  llvm/test/tools/llvm-ifs/read-ifs-with-bad-bitwidth.test
  llvm/test/tools/llvm-ifs/read-ifs-with-bad-endianness.test
  llvm/test/tools/llvm-ifs/read-unsupported-file.test
  llvm/test/tools/llvm-ifs/strip-target.test
  llvm/test/tools/llvm-ifs/strong.ifs
  llvm/test/tools/llvm-ifs/tvos-tbd.ifs
  llvm/test/tools/llvm-ifs/version-ok.ifs
  llvm/test/tools/llvm-ifs/watchos-tbd.ifs
  llvm/test/tools/llvm-ifs/weak-mismatch.ifs
  llvm/test/tools/llvm-ifs/weak.ifs
  llvm/test/tools/llvm-ifs/write-stub-no-nonlocal-symbol.test
  llvm/test/tools/llvm-ifs/write-stub.test
  llvm/tools/llvm-elfabi/CMakeLists.txt
  llvm/tools/llvm-elfabi/ErrorCollector.cpp
  llvm/tools/llvm-elfabi/ErrorCollector.h
  llvm/tools/llvm-elfabi/llvm-elfabi.cpp
  llvm/tools/llvm-ifs/CMakeLists.txt
  llvm/tools/llvm-ifs/ErrorCollector.cpp
  llvm/tools/llvm-ifs/ErrorCollector.h
  llvm/tools/llvm-ifs/llvm-ifs.cpp
  llvm/unittests/InterfaceStub/ELFYAMLTest.cpp
  llvm/utils/gn/secondary/llvm/test/BUILD.gn
  llvm/utils/gn/secondary/llvm/tools/llvm-elfabi/BUILD.gn

Index: llvm/utils/gn/secondary/llvm/tools/llvm-elfabi/BUILD.gn
===
--- llvm/utils/gn/secondary/llvm/tools/llvm-elfabi/BUILD.gn
+++ /dev/null
@@ -1,12 +0,0 @@
-executable("llvm-elfabi") {
-  deps = [
-"//llvm/lib/InterfaceStub",
-"//llvm/lib/Object",
-"//llvm/lib/Support",
-"//llvm/lib/TextAPI",
-  ]
-  sources = [
-"ErrorCollector.cpp",
-"llvm-elfabi.cpp",
-  ]
-}
Index: llvm/utils/gn/secondary/llvm/test/BUILD.gn
===
--- llvm/utils/gn/secondary/llvm/test/BUILD.gn
+++ llvm/utils/gn/secondary/llvm/test/BUILD.gn
@@ -239,7 +239,6 @@
 "//llvm/tools/llvm-dis",
 "//llvm/tools/llvm-dwarfdump",
 "//llvm/tools/llvm-dwp",
-"//llvm/tools/llvm-elfabi",
 "//llvm/tools/llvm-exegesis",
 "//llvm/tools/llvm-extract",
 "//llvm/tools/llvm-gsymutil:llvm-gsymutil",
Index: llvm/unittests/InterfaceStub/ELFYAMLTest.cpp
===
--- llvm/unittests/InterfaceStub/ELFYAMLTest.cpp
+++ llvm/unittests/InterfaceStub/ELFYAMLTest.cpp
@@ -17,7 +17,7 @@
 
 using namespace llvm;
 using namespace llvm::ELF;
-using namespace llvm::elfabi;
+using namespace llvm::ifs;
 
 void compareByLine(StringRef LHS, StringRef RHS) {
   StringRef Line1;
Index: llvm/tools/llvm-if

[PATCH] D104667: Improve the diagnostic of DiagnosticInfoResourceLimit (and warn-stack-size in particular)

2021-06-21 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added inline comments.



Comment at: clang/test/Misc/backend-resource-limit-diagnostics.cl:4
 
-// CHECK: error: local memory limit exceeded (48) in use_huge_lds
+// CHECK: error: local memory (48) exceeds limit in function 'use_huge_lds'
 kernel void use_huge_lds()

nickdesaulniers wrote:
> The value of the limit is still not printed though.
> 
> Oh, we don't print `(0)` if the limit is `0`? Perhaps add a `--check-prefix` 
> and additional `RUN` line that exercises a non-zero limit from the frontend?
0 means the diagnostic does not convey the limit information. It needs more 
refactoring to make this happen... and probably should not be the job of this 
patch...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104667

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


[PATCH] D104601: [Preprocessor] Implement -fnormalize-whitespace.

2021-06-21 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added a comment.

This is probably more @aaron.ballman 's wheelhouse, but for my money this seems 
pretty problematic - will make quoted text in compiler diagnostics 
weird/difficult to read, etc.

Do you have a particular use case that has exceptionally frequent 
whitespace-only changes?
Or is this something you think would be generally applicable? How applicable, 
do you think? Do you have some data showing a % of rebuilds that would be 
avoided in practice/based on real code bases, etc?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104601

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


[clang] 8ace121 - [IR] convert warn-stack-size from module flag to fn attr

2021-06-21 Thread Nick Desaulniers via cfe-commits

Author: Nick Desaulniers
Date: 2021-06-21T15:09:25-07:00
New Revision: 8ace12130526f450c822ca232d1f865b247d7434

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

LOG: [IR] convert warn-stack-size from module flag to fn attr

Otherwise, this causes issues when building with LTO for object files
that use different values.

Link: https://github.com/ClangBuiltLinux/linux/issues/1395

Reviewed By: dblaikie, MaskRay

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

Added: 
clang/test/Frontend/fwarn-stack-size.c
llvm/test/Verifier/invalid-warn-stack-size.ll

Modified: 
clang/lib/CodeGen/CodeGenFunction.cpp
clang/lib/CodeGen/CodeGenModule.cpp
llvm/docs/LangRef.rst
llvm/include/llvm/IR/Module.h
llvm/lib/CodeGen/PrologEpilogInserter.cpp
llvm/lib/IR/Module.cpp
llvm/lib/IR/Verifier.cpp
llvm/test/CodeGen/ARM/warn-stack.ll
llvm/test/CodeGen/X86/warn-stack.ll

Removed: 
llvm/test/Linker/warn-stack-frame.ll



diff  --git a/clang/lib/CodeGen/CodeGenFunction.cpp 
b/clang/lib/CodeGen/CodeGenFunction.cpp
index 97288d01686e..0ca94657e815 100644
--- a/clang/lib/CodeGen/CodeGenFunction.cpp
+++ b/clang/lib/CodeGen/CodeGenFunction.cpp
@@ -1053,6 +1053,10 @@ void CodeGenFunction::StartFunction(GlobalDecl GD, 
QualType RetTy,
 Fn->addFnAttr("packed-stack");
   }
 
+  if (CGM.getCodeGenOpts().WarnStackSize != UINT_MAX)
+Fn->addFnAttr("warn-stack-size",
+  std::to_string(CGM.getCodeGenOpts().WarnStackSize));
+
   if (RetTy->isVoidType()) {
 // Void type; nothing to return.
 ReturnValue = Address::invalid();

diff  --git a/clang/lib/CodeGen/CodeGenModule.cpp 
b/clang/lib/CodeGen/CodeGenModule.cpp
index 369c4b6ccef9..943ed5da6ede 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -787,8 +787,6 @@ void CodeGenModule::Release() {
 getCodeGenOpts().StackProtectorGuardOffset);
   if (getCodeGenOpts().StackAlignment)
 getModule().setOverrideStackAlignment(getCodeGenOpts().StackAlignment);
-  if (getCodeGenOpts().WarnStackSize != UINT_MAX)
-getModule().setWarnStackSize(getCodeGenOpts().WarnStackSize);
 
   getTargetCodeGenInfo().emitTargetMetadata(*this, MangledDeclNames);
 

diff  --git a/clang/test/Frontend/fwarn-stack-size.c 
b/clang/test/Frontend/fwarn-stack-size.c
new file mode 100644
index ..7bffbbd5b0b3
--- /dev/null
+++ b/clang/test/Frontend/fwarn-stack-size.c
@@ -0,0 +1,4 @@
+// RUN: %clang_cc1 -fwarn-stack-size=42 -emit-llvm -o - %s | FileCheck %s
+void foo(void) {}
+// CHECK: define {{.*}} @foo() [[ATTR:#[0-9]+]] {
+// CHECK: attributes [[ATTR]] = {{.*}} "warn-stack-size"="42"

diff  --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 3f1492e67a3d..6c4163f2479f 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -2048,6 +2048,11 @@ example:
 function does not satisfy this contract, the behavior is undefined.  This
 attribute does not apply transitively to callees, but does apply to call
 sites within the function. Note that `willreturn` implies `mustprogress`.
+``"warn-stack-size"=""``
+This attribute sets a threshold to emit diagnostics once the frame size is
+known should the frame size exceed the specified value.  It takes one
+required integer value, which should be a non-negative integer, and less
+than `UINT_MAX`.
 ``vscale_range([, ])``
 This attribute indicates the minimum and maximum vscale value for the given
 function. A value of 0 means unbounded. If the optional max value is 
omitted

diff  --git a/llvm/include/llvm/IR/Module.h b/llvm/include/llvm/IR/Module.h
index 024abe0623f6..81e29d9b86e8 100644
--- a/llvm/include/llvm/IR/Module.h
+++ b/llvm/include/llvm/IR/Module.h
@@ -913,10 +913,6 @@ class Module {
   unsigned getOverrideStackAlignment() const;
   void setOverrideStackAlignment(unsigned Align);
 
-  /// Get/set the stack frame size threshold to warn on.
-  unsigned getWarnStackSize() const;
-  void setWarnStackSize(unsigned Threshold);
-
   /// @name Utility functions for querying and setting the build SDK version
   /// @{
 

diff  --git a/llvm/lib/CodeGen/PrologEpilogInserter.cpp 
b/llvm/lib/CodeGen/PrologEpilogInserter.cpp
index e09face17c79..e745f561a896 100644
--- a/llvm/lib/CodeGen/PrologEpilogInserter.cpp
+++ b/llvm/lib/CodeGen/PrologEpilogInserter.cpp
@@ -274,7 +274,16 @@ bool PEI::runOnMachineFunction(MachineFunction &MF) {
   MachineFrameInfo &MFI = MF.getFrameInfo();
   uint64_t StackSize = MFI.getStackSize();
 
-  unsigned Threshold = MF.getFunction().getParent()->getWarnStackSize();
+  unsigned Threshold = UINT_MAX;
+  if (MF.getFunction().hasFnAttribute("warn-stack-size")) {
+bool Failed = MF.getFunction()
+  .getFnAttribute("warn-stack-size")
+

[PATCH] D104342: [IR] convert warn-stack-size from module flag to fn attr

2021-06-21 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added a comment.

In D104342#2831733 , @nickdesaulniers 
wrote:

> In D104342#2831717 , @dblaikie 
> wrote:
>
>> I don't know that there's a good answer (in more extreme cases - like 
>> different optimization levels or CPU features, at least at Google our answer 
>> has ended up being "compile the whole program with the right CPU features, 
>> because there's no great way to support good optimizations while respecting 
>> CPU features on a per-function basis"), basically - so this was more a 
>> "heads up, this is going to be possibly unavoidably messy/unreliable on the 
>> edges".
>>
>> Probably worth at least writing up the risk/instability in the docs for the 
>> warning (in clang) and attribute (in llvm). (don't mind if that's in this 
>> patch or a follow-up).
>
> Sure.  Let me land this, since we (Google & ClangBuiltLinux) have some tests 
> and builds failing due to https://reviews.llvm.org/D103928. I will then send 
> a follow up for us to iterate on in regards to documenting this more.
>
>> (why I think there's no solution to this: any rule (highest wins, lowest 
>> wins, mismatch fails to compile) will create surprising/problematic effects, 
>> eg: you have one TU with the function in it and some value for the attribute 
>> - a new TU could introduce a copy of the function with a higher or lower 
>> value - and whichever choice of policy would then cause problems for one 
>> case or the other case. (either enforcing a stronger warning level on code 
>> that didn't ask for it, or slackening the warning level for code that 
>> thought it was protected by the warning))
>
> I agree.  I don't think even having a function attribute in C for 
> `-Wframe-larger-than` would resolve such policy issues either.

At least then we could probably say it's an ODR violation (the two function 
definitions would be not the same if the user wrote the attribute differently 
for two definitions of the inline function in two different translation units) 
to have the function declared with different values for the attribute within 
the same program (so you could still compile two different files (that include 
a common header with a common function with the attribute specified there) with 
different values for the command line flag - because the function would get a 
consistent attribute value for the warning) - and then the linker could 
actually reject it on mismatch. But with the attribute currently coming from 
the command line, that's not feasible.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104342

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


[PATCH] D104342: [IR] convert warn-stack-size from module flag to fn attr

2021-06-21 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers updated this revision to Diff 353499.
nickdesaulniers marked 2 inline comments as done.
nickdesaulniers edited the summary of this revision.
nickdesaulniers added a comment.

- fix langref, delete inline and linker tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104342

Files:
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/Frontend/fwarn-stack-size.c
  llvm/docs/LangRef.rst
  llvm/include/llvm/IR/Module.h
  llvm/lib/CodeGen/PrologEpilogInserter.cpp
  llvm/lib/IR/Module.cpp
  llvm/lib/IR/Verifier.cpp
  llvm/test/CodeGen/ARM/warn-stack.ll
  llvm/test/CodeGen/X86/warn-stack.ll
  llvm/test/Linker/warn-stack-frame.ll
  llvm/test/Verifier/invalid-warn-stack-size.ll

Index: llvm/test/Verifier/invalid-warn-stack-size.ll
===
--- /dev/null
+++ llvm/test/Verifier/invalid-warn-stack-size.ll
@@ -0,0 +1,10 @@
+; RUN: not opt -passes=verify %s -disable-output 2>&1 | FileCheck %s
+define void @foo() "warn-stack-size"="42" { ret void }
+define void @bar() "warn-stack-size"="-1" { ret void }
+define void @baz() "warn-stack-size"="9" { ret void }
+define void @qux() "warn-stack-size"="a lot lol" { ret void }
+
+; CHECK-NOT: "warn-stack-size" takes an unsigned integer: 42
+; CHECK: "warn-stack-size" takes an unsigned integer: -1
+; CHECK: "warn-stack-size" takes an unsigned integer: 9
+; CHECK: "warn-stack-size" takes an unsigned integer: a lot lol
Index: llvm/test/Linker/warn-stack-frame.ll
===
--- llvm/test/Linker/warn-stack-frame.ll
+++ /dev/null
@@ -1,16 +0,0 @@
-; RUN: split-file %s %t
-; RUN: llvm-link %t/main.ll %t/match.ll
-; RUN: not llvm-link %t/main.ll %t/mismatch.ll 2>&1 | \
-; RUN:   FileCheck --check-prefix=CHECK-MISMATCH %s
-
-; CHECK-MISMATCH: error: linking module flags 'warn-stack-size': IDs have conflicting values
-
-;--- main.ll
-!llvm.module.flags = !{!0}
-!0 = !{i32 1, !"warn-stack-size", i32 80}
-;--- match.ll
-!llvm.module.flags = !{!0}
-!0 = !{i32 1, !"warn-stack-size", i32 80}
-;--- mismatch.ll
-!llvm.module.flags = !{!0}
-!0 = !{i32 1, !"warn-stack-size", i32 81}
Index: llvm/test/CodeGen/X86/warn-stack.ll
===
--- llvm/test/CodeGen/X86/warn-stack.ll
+++ llvm/test/CodeGen/X86/warn-stack.ll
@@ -4,7 +4,7 @@
 ; 
 
 ; CHECK-NOT: nowarn
-define void @nowarn() nounwind ssp {
+define void @nowarn() nounwind ssp "warn-stack-size"="80" {
 entry:
   %buffer = alloca [12 x i8], align 1
   %arraydecay = getelementptr inbounds [12 x i8], [12 x i8]* %buffer, i64 0, i64 0
@@ -13,7 +13,7 @@
 }
 
 ; CHECK: warning: stack size limit exceeded (88) in warn
-define void @warn() nounwind ssp {
+define void @warn() nounwind ssp "warn-stack-size"="80" {
 entry:
   %buffer = alloca [80 x i8], align 1
   %arraydecay = getelementptr inbounds [80 x i8], [80 x i8]* %buffer, i64 0, i64 0
@@ -22,6 +22,3 @@
 }
 
 declare void @doit(i8*)
-
-!llvm.module.flags = !{!0}
-!0 = !{i32 1, !"warn-stack-size", i32 80}
Index: llvm/test/CodeGen/ARM/warn-stack.ll
===
--- llvm/test/CodeGen/ARM/warn-stack.ll
+++ llvm/test/CodeGen/ARM/warn-stack.ll
@@ -4,7 +4,7 @@
 ; 
 
 ; CHECK-NOT: nowarn
-define void @nowarn() nounwind ssp "frame-pointer"="all" {
+define void @nowarn() nounwind ssp "frame-pointer"="all" "warn-stack-size"="80" {
 entry:
   %buffer = alloca [12 x i8], align 1
   %arraydecay = getelementptr inbounds [12 x i8], [12 x i8]* %buffer, i64 0, i64 0
@@ -13,7 +13,7 @@
 }
 
 ; CHECK: warning: stack size limit exceeded (92) in warn
-define void @warn() nounwind ssp "frame-pointer"="all" {
+define void @warn() nounwind ssp "frame-pointer"="all" "warn-stack-size"="80" {
 entry:
   %buffer = alloca [80 x i8], align 1
   %arraydecay = getelementptr inbounds [80 x i8], [80 x i8]* %buffer, i64 0, i64 0
@@ -22,6 +22,3 @@
 }
 
 declare void @doit(i8*)
-
-!llvm.module.flags = !{!0}
-!0 = !{i32 1, !"warn-stack-size", i32 80}
Index: llvm/lib/IR/Verifier.cpp
===
--- llvm/lib/IR/Verifier.cpp
+++ llvm/lib/IR/Verifier.cpp
@@ -543,6 +543,8 @@
   void verifyAttributeTypes(AttributeSet Attrs, bool IsFunction,
 const Value *V);
   void verifyParameterAttrs(AttributeSet Attrs, Type *Ty, const Value *V);
+  void checkUnsignedBaseTenFuncAttr(AttributeList Attrs, StringRef Attr,
+const Value *V);
   void verifyFunctionAttrs(FunctionType *FT, AttributeList Attrs,
const Value *V, bool IsIntrinsic);
   void verifyFunctionMetadata(ArrayRef> MDs);
@@ -1899,6 +1901,17 @@
   }
 }
 
+void Verifier::checkUnsignedBaseTenFuncAttr(AttributeList Attrs, StringRef Attr,
+   

[PATCH] D104667: Improve the diagnostic of DiagnosticInfoResourceLimit (and warn-stack-size in particular)

2021-06-21 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay updated this revision to Diff 353497.
MaskRay added a comment.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

stack size -> stack frame size

The former is ambiguous (it could mean the full stack size).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104667

Files:
  clang/test/Misc/backend-resource-limit-diagnostics.cl
  clang/test/Misc/backend-stack-frame-diagnostics-fallback.cpp
  llvm/include/llvm/IR/DiagnosticInfo.h
  llvm/lib/CodeGen/PrologEpilogInserter.cpp
  llvm/lib/IR/DiagnosticInfo.cpp
  llvm/test/CodeGen/AMDGPU/exceed-max-sgprs.ll
  llvm/test/CodeGen/AMDGPU/stack-size-overflow.ll
  llvm/test/CodeGen/ARM/warn-stack.ll
  llvm/test/CodeGen/X86/warn-stack.ll

Index: llvm/test/CodeGen/X86/warn-stack.ll
===
--- llvm/test/CodeGen/X86/warn-stack.ll
+++ llvm/test/CodeGen/X86/warn-stack.ll
@@ -1,5 +1,5 @@
 ; RUN: llc -mtriple x86_64-apple-macosx10.8.0 < %s 2>&1 >/dev/null | FileCheck %s
-; Check the internal option that warns when the stack size exceeds the
+; Check the internal option that warns when the stack frame size exceeds the
 ; given amount.
 ; 
 
@@ -12,7 +12,7 @@
   ret void
 }
 
-; CHECK: warning: stack size limit exceeded (88) in warn
+; CHECK: warning: stack frame size (88) exceeds limit (80) in function 'warn'
 define void @warn() nounwind ssp {
 entry:
   %buffer = alloca [80 x i8], align 1
Index: llvm/test/CodeGen/ARM/warn-stack.ll
===
--- llvm/test/CodeGen/ARM/warn-stack.ll
+++ llvm/test/CodeGen/ARM/warn-stack.ll
@@ -1,5 +1,5 @@
 ; RUN: llc -mtriple thumbv7-apple-ios3.0.0 < %s 2>&1 >/dev/null | FileCheck %s
-; Check the internal option that warns when the stack size exceeds the
+; Check the internal option that warns when the stack frame size exceeds the
 ; given amount.
 ; 
 
@@ -12,7 +12,7 @@
   ret void
 }
 
-; CHECK: warning: stack size limit exceeded (92) in warn
+; CHECK: warning: stack frame size (92) exceeds limit (80) in function 'warn'
 define void @warn() nounwind ssp "frame-pointer"="all" {
 entry:
   %buffer = alloca [80 x i8], align 1
Index: llvm/test/CodeGen/AMDGPU/stack-size-overflow.ll
===
--- llvm/test/CodeGen/AMDGPU/stack-size-overflow.ll
+++ llvm/test/CodeGen/AMDGPU/stack-size-overflow.ll
@@ -3,7 +3,7 @@
 
 declare void @llvm.memset.p5i8.i32(i8 addrspace(5)* nocapture, i8, i32, i32, i1) #1
 
-; ERROR: error: stack size limit exceeded (131061) in stack_size_limit_wave64
+; ERROR: error: stack frame size (131061) exceeds limit in function 'stack_size_limit_wave64'
 ; GCN: ; ScratchSize: 131061
 define amdgpu_kernel void @stack_size_limit_wave64() #0 {
 entry:
@@ -13,7 +13,7 @@
   ret void
 }
 
-; ERROR: error: stack size limit exceeded (262117) in stack_size_limit_wave32
+; ERROR: error: stack frame size (262117) exceeds limit in function 'stack_size_limit_wave32'
 ; GCN: ; ScratchSize: 262117
 define amdgpu_kernel void @stack_size_limit_wave32() #1 {
 entry:
Index: llvm/test/CodeGen/AMDGPU/exceed-max-sgprs.ll
===
--- llvm/test/CodeGen/AMDGPU/exceed-max-sgprs.ll
+++ llvm/test/CodeGen/AMDGPU/exceed-max-sgprs.ll
@@ -1,6 +1,6 @@
 ; RUN: not llc -march=amdgcn -verify-machineinstrs < %s 2>&1 | FileCheck -check-prefix=ERROR %s
 
-; ERROR: error: scalar registers limit of 104 exceeded (106) in use_too_many_sgprs_tahiti
+; ERROR: error: scalar registers (106) exceeds limit (104) in function 'use_too_many_sgprs_tahiti'
 define amdgpu_kernel void @use_too_many_sgprs_tahiti() #0 {
   call void asm sideeffect "", "~{s[0:7]}" ()
   call void asm sideeffect "", "~{s[8:15]}" ()
@@ -19,7 +19,7 @@
   ret void
 }
 
-; ERROR: error: scalar registers limit of 104 exceeded (106) in use_too_many_sgprs_bonaire
+; ERROR: error: scalar registers (106) exceeds limit (104) in function 'use_too_many_sgprs_bonaire'
 define amdgpu_kernel void @use_too_many_sgprs_bonaire() #1 {
   call void asm sideeffect "", "~{s[0:7]}" ()
   call void asm sideeffect "", "~{s[8:15]}" ()
@@ -38,7 +38,7 @@
   ret void
 }
 
-; ERROR: error: scalar registers limit of 104 exceeded (108) in use_too_many_sgprs_bonaire_flat_scr
+; ERROR: error: scalar registers (108) exceeds limit (104) in function 'use_too_many_sgprs_bonaire_flat_scr'
 define amdgpu_kernel void @use_too_many_sgprs_bonaire_flat_scr() #1 {
   call void asm sideeffect "", "~{s[0:7]}" ()
   call void asm sideeffect "", "~{s[8:15]}" ()
@@ -58,7 +58,7 @@
   ret void
 }
 
-; ERROR: error: scalar registers limit of 96 exceeded (98) in use_too_many_sgprs_iceland
+; ERROR: error: scalar registers (98) exceeds limit (96) in function 'use_too_many_sgprs_iceland'
 define amdgpu_kernel void @use_too_many_sgprs_iceland() #2 {
   call void asm sideeffect "", "~{vcc}" ()
   call void asm sideeffect "", "

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

2021-06-21 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/SVals.cpp:151
+  Optional VisitNonLocLazyCompoundVal(nonloc::LazyCompoundVal LCV) {
+return Visit(LCV.getRegion());
+  }

vsavchenko wrote:
> NoQ wrote:
> > This is correct except you need to get the value type, not the pointer type.
> > 
> > `LazyCompoundVal` is a `prvalue` and its parent region is the location in 
> > which this `prvalue` resided some time in the past. So the parent region is 
> > of the right type and it's always typed but you need the pointee type.
> OK then, can you maybe hint how can I write a test where this is going to be 
> a pointer type (or maybe then `getType` for regions works incorrectly).
Regions have `getLocationType()` (the pointer type) and `getValueType()` (the 
pointee type). I think you need to call the latter directly in this case, 
bypassing recursion.

In order to obtain a live `LazyCompoundVal` specimen for testing purposes, you 
need to load an entire compound object (not necessarily represented by a 
`CompoundVal`) from Region Store.

Eg.,
```lang=c
  struct MyStruct a;
  // ...
  struct MyStruct b = a; // Avoid C++ though, constructors are a different 
beast.
```

Or you could construct one directly. But that, of course, wouldn't give you any 
hints about the appropriate type.

> maybe then `getType` for regions works incorrectly

Hmm that's actually a good separate question. How do you know if a region 
represents a prvalue of pointer type or a glvalue of pointee type (including, 
but not limited to, references)? This can't be figured out without more context 
just by looking at the `SVal`.


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] D104505: [HIP] Defer operator overloading errors

2021-06-21 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

In D104505#2831555 , @tra wrote:

> In NVCC's compilation only device-side compilation is aware of "semantics' of 
> `__host__`/`__device__` attributes. HOST-side compilation is not aware of GPU 
> existence.  `cudafe++` massages the input source to create that fiction for 
> the host compilation, but AFAICT, it does not care about semantics of what 
> can be called from where but just strips deive-side code from the sources 
> passed to the host compilation. Essentially, its diagnostics is limited to 
> syntax errors. AFAICT, semantics is only checked by `cicc` during device-side 
> compilation.
>
> So, in the end it may look that nvcc decided to ignore errors in device code, 
> but in reality, host-side compilation is a regular GPU-unaware C++ 
> compilation that does not see the code with the error.

That explains why nvcc does not allow overloaded functions differing only by 
`__host__` or `__device__` attributes, since they all become host functions in 
host compilations.

However, this does cause source level incompatibilities, i.e. CUDA code that 
passes nvcc does not pass clang. This patch somehow addresses that without 
compromising clang's more sophisticated `__host__/__device__` overloading 
resolution capabilities.


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

https://reviews.llvm.org/D104505

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


[PATCH] D104566: [UpdateCCTestChecks] Fix --replace-value-regex across RUN lines

2021-06-21 Thread Joel E. Denny 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 rG2bfe0536e514: [UpdateCCTestChecks] Fix --replace-value-regex 
across RUN lines (authored by jdenny).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104566

Files:
  
clang/test/utils/update_cc_test_checks/Inputs/replace-value-regex-across-runs.c
  
clang/test/utils/update_cc_test_checks/Inputs/replace-value-regex-across-runs.c.expected
  clang/test/utils/update_cc_test_checks/replace-value-regex-across-runs.test
  llvm/utils/UpdateTestChecks/common.py

Index: llvm/utils/UpdateTestChecks/common.py
===
--- llvm/utils/UpdateTestChecks/common.py
+++ llvm/utils/UpdateTestChecks/common.py
@@ -351,27 +351,6 @@
 for l in scrubbed_body.splitlines():
   print('  ' + l, file=sys.stderr)
   for prefix in prefixes:
-if func in self._func_dict[prefix]:
-  if (self._func_dict[prefix][func] is None or
-  str(self._func_dict[prefix][func]) != scrubbed_body or
-  self._func_dict[prefix][func].args_and_sig != args_and_sig or
-  self._func_dict[prefix][func].attrs != attrs):
-if (self._func_dict[prefix][func] is not None and
-self._func_dict[prefix][func].is_same_except_arg_names(
-scrubbed_extra,
-args_and_sig,
-attrs)):
-  self._func_dict[prefix][func].scrub = scrubbed_extra
-  self._func_dict[prefix][func].args_and_sig = args_and_sig
-  continue
-else:
-  # This means a previous RUN line produced a body for this function
-  # that is different from the one produced by this current RUN line,
-  # so the body can't be common accross RUN lines. We use None to
-  # indicate that.
-  self._func_dict[prefix][func] = None
-  continue
-
 # Replace function names matching the regex.
 for regex in self._replace_value_regex:
   # Pattern that matches capture groups in the regex in leftmost order.
@@ -394,7 +373,29 @@
 func_repl = group_regex.sub(re.escape(g), func_repl, count=1)
 # Substitute function call names that match the regex with the same
 # capture groups set.
-scrubbed_body = re.sub(func_repl, '{{' + func_repl + '}}', scrubbed_body)
+scrubbed_body = re.sub(func_repl, '{{' + func_repl + '}}',
+   scrubbed_body)
+
+if func in self._func_dict[prefix]:
+  if (self._func_dict[prefix][func] is None or
+  str(self._func_dict[prefix][func]) != scrubbed_body or
+  self._func_dict[prefix][func].args_and_sig != args_and_sig or
+  self._func_dict[prefix][func].attrs != attrs):
+if (self._func_dict[prefix][func] is not None and
+self._func_dict[prefix][func].is_same_except_arg_names(
+scrubbed_extra,
+args_and_sig,
+attrs)):
+  self._func_dict[prefix][func].scrub = scrubbed_extra
+  self._func_dict[prefix][func].args_and_sig = args_and_sig
+  continue
+else:
+  # This means a previous RUN line produced a body for this function
+  # that is different from the one produced by this current RUN line,
+  # so the body can't be common accross RUN lines. We use None to
+  # indicate that.
+  self._func_dict[prefix][func] = None
+  continue
 
 self._func_dict[prefix][func] = function_body(
 scrubbed_body, scrubbed_extra, args_and_sig, attrs)
Index: clang/test/utils/update_cc_test_checks/replace-value-regex-across-runs.test
===
--- /dev/null
+++ clang/test/utils/update_cc_test_checks/replace-value-regex-across-runs.test
@@ -0,0 +1,7 @@
+# Test that --replace-value-regex is applied correctly when multiple RUN lines
+# use the same FileCheck prefix and have the same output.
+
+RUN: cp %S/Inputs/replace-value-regex-across-runs.c %t.c
+RUN: %update_cc_test_checks %t.c \
+RUN: --replace-value-regex '__omp_offloading_[0-9a-z]+_[0-9a-z]+'
+RUN: diff -u %S/Inputs/replace-value-regex-across-runs.c.expected %t.c
Index: clang/test/utils/update_cc_test_checks/Inputs/replace-value-regex-across-runs.c.expected
===
--- /dev/null
+++ clang/test/utils/update_cc_test_checks/Inputs/replace-value-regex-across-runs.c.expected
@@ -0,0 +1,15 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py UTC_ARGS: --replace-value-regex "__omp_offloading_[0-9a-z]+_[0-9a-z]+"
+/

[clang] 2bfe053 - [UpdateCCTestChecks] Fix --replace-value-regex across RUN lines

2021-06-21 Thread Joel E. Denny via cfe-commits

Author: Joel E. Denny
Date: 2021-06-21T17:01:17-04:00
New Revision: 2bfe0536e5143caad80f7a9691fa775cf451317b

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

LOG: [UpdateCCTestChecks] Fix --replace-value-regex across RUN lines

Without this patch, llvm/utils/update_cc_test_checks.py fails to
perform `--replace-value-regex` replacements when two RUN lines
produce the same output and use the same single FileCheck prefix.  The
problem is that replacements in a RUN line's output are not performed
until after comparing against previous RUN lines' output, where
replacements have already been performed.  This patch fixes that.

Reviewed By: MaskRay

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

Added: 

clang/test/utils/update_cc_test_checks/Inputs/replace-value-regex-across-runs.c

clang/test/utils/update_cc_test_checks/Inputs/replace-value-regex-across-runs.c.expected
clang/test/utils/update_cc_test_checks/replace-value-regex-across-runs.test

Modified: 
llvm/utils/UpdateTestChecks/common.py

Removed: 




diff  --git 
a/clang/test/utils/update_cc_test_checks/Inputs/replace-value-regex-across-runs.c
 
b/clang/test/utils/update_cc_test_checks/Inputs/replace-value-regex-across-runs.c
new file mode 100644
index ..8914a2195371
--- /dev/null
+++ 
b/clang/test/utils/update_cc_test_checks/Inputs/replace-value-regex-across-runs.c
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -triple x86_64-pc-linux-gnu -fopenmp -emit-llvm -o - %s | \
+// RUN: FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-pc-linux-gnu -fopenmp -emit-llvm -o - %s | \
+// RUN: FileCheck %s
+
+void foo(void) {
+  #pragma omp target
+  ;
+}

diff  --git 
a/clang/test/utils/update_cc_test_checks/Inputs/replace-value-regex-across-runs.c.expected
 
b/clang/test/utils/update_cc_test_checks/Inputs/replace-value-regex-across-runs.c.expected
new file mode 100644
index ..ea3cc9480f6d
--- /dev/null
+++ 
b/clang/test/utils/update_cc_test_checks/Inputs/replace-value-regex-across-runs.c.expected
@@ -0,0 +1,15 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py 
UTC_ARGS: --replace-value-regex "__omp_offloading_[0-9a-z]+_[0-9a-z]+"
+// RUN: %clang_cc1 -triple x86_64-pc-linux-gnu -fopenmp -emit-llvm -o - %s | \
+// RUN: FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-pc-linux-gnu -fopenmp -emit-llvm -o - %s | \
+// RUN: FileCheck %s
+
+// CHECK-LABEL: @foo(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:call void @{{__omp_offloading_[0-9a-z]+_[0-9a-z]+}}_foo_l7() 
#[[ATTR2:[0-9]+]]
+// CHECK-NEXT:ret void
+//
+void foo(void) {
+  #pragma omp target
+  ;
+}

diff  --git 
a/clang/test/utils/update_cc_test_checks/replace-value-regex-across-runs.test 
b/clang/test/utils/update_cc_test_checks/replace-value-regex-across-runs.test
new file mode 100644
index ..c2fdf6113fc2
--- /dev/null
+++ 
b/clang/test/utils/update_cc_test_checks/replace-value-regex-across-runs.test
@@ -0,0 +1,7 @@
+# Test that --replace-value-regex is applied correctly when multiple RUN lines
+# use the same FileCheck prefix and have the same output.
+
+RUN: cp %S/Inputs/replace-value-regex-across-runs.c %t.c
+RUN: %update_cc_test_checks %t.c \
+RUN: --replace-value-regex '__omp_offloading_[0-9a-z]+_[0-9a-z]+'
+RUN: 
diff  -u %S/Inputs/replace-value-regex-across-runs.c.expected %t.c

diff  --git a/llvm/utils/UpdateTestChecks/common.py 
b/llvm/utils/UpdateTestChecks/common.py
index 80b0c847080c..3f3682c5b9de 100644
--- a/llvm/utils/UpdateTestChecks/common.py
+++ b/llvm/utils/UpdateTestChecks/common.py
@@ -351,27 +351,6 @@ def process_run_line(self, function_re, scrubber, 
raw_tool_output, prefixes):
 for l in scrubbed_body.splitlines():
   print('  ' + l, file=sys.stderr)
   for prefix in prefixes:
-if func in self._func_dict[prefix]:
-  if (self._func_dict[prefix][func] is None or
-  str(self._func_dict[prefix][func]) != scrubbed_body or
-  self._func_dict[prefix][func].args_and_sig != args_and_sig or
-  self._func_dict[prefix][func].attrs != attrs):
-if (self._func_dict[prefix][func] is not None and
-self._func_dict[prefix][func].is_same_except_arg_names(
-scrubbed_extra,
-args_and_sig,
-attrs)):
-  self._func_dict[prefix][func].scrub = scrubbed_extra
-  self._func_dict[prefix][func].args_and_sig = args_and_sig
-  continue
-else:
-  # This means a previous RUN line produced a body for this 
function
-  # that is 
diff erent from the one produced by this current RUN line,
-  # so the body can't be common accross RUN lines. We use None to
-  

[PATCH] D103986: [PowerPC] Floating Point Builtins for XL Compat.

2021-06-21 Thread Quinn Pham via Phabricator via cfe-commits
quinnp updated this revision to Diff 353475.
quinnp added a comment.

Addressing comments and updating tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103986

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/Basic/Targets/PPC.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-ppc-xlcompat-fp.c
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPCISelDAGToDAG.cpp
  llvm/lib/Target/PowerPC/PPCInstrInfo.td
  llvm/lib/Target/PowerPC/PPCInstrVSX.td
  llvm/test/CodeGen/builtins-ppc-xlcompat-fp.ll

Index: llvm/test/CodeGen/builtins-ppc-xlcompat-fp.ll
===
--- /dev/null
+++ llvm/test/CodeGen/builtins-ppc-xlcompat-fp.ll
@@ -0,0 +1,60 @@
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-unknown \
+; RUN: -mcpu=pwr7 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-unknown \
+; RUN: -mcpu=pwr8 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-aix \
+; RUN: -mcpu=pwr7 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc-unknown-aix \
+; RUN: -mcpu=pwr8 < %s | FileCheck %s
+
+define dso_local double @test_fsel(double %a, double %b, double %c) local_unnamed_addr #0 {
+; CHECK-LABEL: test_fsel 
+
+entry:
+  %0 = tail call double @llvm.ppc.fsel(double %a, double %b, double %c)
+; CHECK: fsel 1, 1, 2, 3
+
+  ret double %0
+; CHECK: blr
+}
+
+declare double @llvm.ppc.fsel(double, double, double) #2
+
+define dso_local float @test_fsels(float %a, float %b, float %c) local_unnamed_addr #0 {
+; CHECK-LABEL: test_fsels
+
+entry:
+  %0 = tail call float @llvm.ppc.fsels(float %a, float %b, float %c)
+; CHECK: fsel 1, 1, 2, 3
+
+  ret float %0
+; CHECK: blr
+}
+
+declare float @llvm.ppc.fsels(float, float, float) #2
+
+define dso_local double @test_frsqrte(double %a) local_unnamed_addr #0 {
+; CHECK-LABEL: test_frsqrte
+
+entry:
+  %0 = tail call double @llvm.ppc.frsqrte(double %a)
+; CHECK: xsrsqrtedp 1, 1
+
+  ret double %0
+; CHECK: blr
+}
+
+declare double @llvm.ppc.frsqrte(double) #2
+
+define dso_local float @test_frsqrtes(float %a) local_unnamed_addr #0 {
+; CHECK-LABEL: test_frsqrtes
+
+entry:
+  %0 = tail call float @llvm.ppc.frsqrtes(float %a)
+; CHECK: xsrsqrtesp 1, 1
+ 
+  ret float %0
+; CHECK: blr
+}
+
+declare float @llvm.ppc.frsqrtes(float) #2
Index: llvm/lib/Target/PowerPC/PPCInstrVSX.td
===
--- llvm/lib/Target/PowerPC/PPCInstrVSX.td
+++ llvm/lib/Target/PowerPC/PPCInstrVSX.td
@@ -4954,6 +4954,9 @@
 } // HasVSX, IsISA3_0, HasDirectMove, IsLittleEndian
 } // AddedComplexity = 400
 
+def : Pat<(int_ppc_frsqrte vsfrc:$XB), (XSRSQRTEDP $XB)>;
+def : Pat<(int_ppc_frsqrtes vssrc:$XB), (XSRSQRTESP $XB)>;
+
 // Instruction aliases ---//
 def : InstAlias<"xvmovdp $XT, $XB",
 (XVCPSGNDP vsrc:$XT, vsrc:$XB, vsrc:$XB)>;
Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td
===
--- llvm/lib/Target/PowerPC/PPCInstrInfo.td
+++ llvm/lib/Target/PowerPC/PPCInstrInfo.td
@@ -3318,6 +3318,8 @@
   }
 }
 
+def : Pat<(int_ppc_fsel f8rc:$FRA, f8rc:$FRC, f8rc:$FRB), (FSELD $FRA, $FRC, $FRB)>;
+
 let hasSideEffects = 0 in {
 let PPC970_Unit = 1 in {  // FXU Operations.
   let isSelect = 1 in
Index: llvm/lib/Target/PowerPC/PPCISelDAGToDAG.cpp
===
--- llvm/lib/Target/PowerPC/PPCISelDAGToDAG.cpp
+++ llvm/lib/Target/PowerPC/PPCISelDAGToDAG.cpp
@@ -4987,6 +4987,13 @@
 break;
 
   case ISD::INTRINSIC_WO_CHAIN: {
+
+if (N->getConstantOperandVal(0) == Intrinsic::ppc_fsels) {
+  SDValue ops[] = {N->getOperand(1), N->getOperand(2), N->getOperand(3)};
+  CurDAG->SelectNodeTo(N, PPC::FSELS, MVT::f32, ops);
+  return;
+}
+
 if (!Subtarget->isISA3_1())
   break;
 unsigned Opcode = 0;
Index: llvm/include/llvm/IR/IntrinsicsPowerPC.td
===
--- llvm/include/llvm/IR/IntrinsicsPowerPC.td
+++ llvm/include/llvm/IR/IntrinsicsPowerPC.td
@@ -1523,5 +1523,16 @@
   Intrinsic<[],[],[]>;
   def int_ppc_iospace_eieio : GCCBuiltin<"__builtin_ppc_iospace_eieio">,
   Intrinsic<[],[],[]>;
+
+  def int_ppc_fsel : GCCBuiltin<"__builtin_ppc_fsel">,
+ Intrinsic<[llvm_double_ty], [llvm_double_ty, 
+ llvm_double_ty, llvm_double_ty], [IntrNoMem]>;
+  def int_ppc_fsels : GCCBuiltin<"__builtin_ppc_fsels">,
+  Intrinsic<[llvm_float_ty], [llvm_float_ty, llvm_float_ty,
+  llvm_float_ty], [IntrNoMem]>;
+  def int_ppc_frsqrte : GCCBuiltin<"__builtin_ppc_frsqrte">,
+Intrinsic<[llvm_double_ty], [llvm_doub

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

2021-06-21 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers accepted this revision.
nickdesaulniers added a comment.
This revision is now accepted and ready to land.

Thanks for following up on a fix!




Comment at: clang/lib/Driver/ToolChains/Arch/AArch64.cpp:201-205
+  // Call getAArch64ArchFeaturesFromMarch only if "-Wa,-march=" or
+  // "-Xassembler -march" is detected. Otherwise it may return false
+  // and causes Clang to error out.
+  if (WaMArch.size())
+success = getAArch64ArchFeaturesFromMarch(D, WaMArch, Args, Features);

nickdesaulniers wrote:
> If this surprised us before, it's likely to surprise us (or someone else) 
> again. In that case, I'd recommend permitting 
> `getAArch64ArchFeaturesFromMarch` to accept an empty second parameter, and 
> simply `return true` early. Then callers don't need such a check and comment.
@jcai19 points out this is how it's done for arm32 as well:
https://reviews.llvm.org/D95872


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103184

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


[PATCH] D102094: [AIX][PowerPC] Remove error when specifying mabi=vec-default on AIX

2021-06-21 Thread Jinsong Ji via Phabricator via cfe-commits
jsji added a comment.

> The default Altivec ABI was implemented

Please include the patches or commits that implement the default ABI.




Comment at: clang/lib/Driver/ToolChains/Clang.cpp:4779
   CmdArgs.push_back("-mabi=vec-extabi");
+else if (A->getOption().getID() == options::OPT_mabi_EQ_vec_default)
+  CmdArgs.push_back("-mabi=vec-default");

Why we need to check this if the default is to set it to `-mabi=vec-default` in 
below else?



Comment at: clang/test/Driver/aix-vec-extabi.c:11
+// DFLTABI-SAME: "-mabi=vec-default"
+// DFLTABI-NOT:  "-mabi=vec-default"

Why we need to explicitly `DFLTABI-NOT:  "-mabi=vec-default"`


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

https://reviews.llvm.org/D102094

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


[clang] b3634d3 - Revert "[SYCL][NFC] Ensure SYCL kernel for unique-stable-name is unqualified."

2021-06-21 Thread Erich Keane via cfe-commits

Author: Erich Keane
Date: 2021-06-21T13:23:52-07:00
New Revision: b3634d3e88b7f26534a5057bff182b7dced584fc

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

LOG: Revert "[SYCL][NFC] Ensure SYCL kernel for unique-stable-name is 
unqualified."

This reverts commit 5013131875402539a249dca47c58cca7c359baf8.

This patch didn't end up being the solution to the problem.  It "fixed"
our issue but the actual correct solution is something else.  Reverting
as this ends up being unnecessary/extra noise.

Added: 


Modified: 
clang/lib/Sema/SemaSYCL.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaSYCL.cpp b/clang/lib/Sema/SemaSYCL.cpp
index 7ae78b1d1943..3b48a53efc0d 100644
--- a/clang/lib/Sema/SemaSYCL.cpp
+++ b/clang/lib/Sema/SemaSYCL.cpp
@@ -54,14 +54,14 @@ bool Sema::checkSYCLDeviceFunction(SourceLocation Loc, 
FunctionDecl *Callee) {
 // this was passed by value, and in SYCL2020, it is passed by reference.
 static QualType GetSYCLKernelObjectType(const FunctionDecl *KernelCaller) {
   assert(KernelCaller->getNumParams() > 0 && "Insufficient kernel parameters");
-  // SYCL 1.2.1
   QualType KernelParamTy = KernelCaller->getParamDecl(0)->getType();
 
   // SYCL 2020 kernels are passed by reference.
   if (KernelParamTy->isReferenceType())
-KernelParamTy = KernelParamTy->getPointeeType();
+return KernelParamTy->getPointeeType();
 
-  return KernelParamTy.getUnqualifiedType();
+  // SYCL 1.2.1
+  return KernelParamTy;
 }
 
 void Sema::AddSYCLKernelLambda(const FunctionDecl *FD) {



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


[PATCH] D102094: [AIX][PowerPC] Remove error when specifying mabi=vec-default on AIX

2021-06-21 Thread Bardia Mahjour via Phabricator via cfe-commits
bmahjour added a comment.

LGTM...I'll approve this change unless there are any objections by EOD tomorrow.


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

https://reviews.llvm.org/D102094

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


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

2021-06-21 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers added inline comments.



Comment at: clang/lib/Driver/ToolChains/Arch/AArch64.cpp:201-205
+  // Call getAArch64ArchFeaturesFromMarch only if "-Wa,-march=" or
+  // "-Xassembler -march" is detected. Otherwise it may return false
+  // and causes Clang to error out.
+  if (WaMArch.size())
+success = getAArch64ArchFeaturesFromMarch(D, WaMArch, Args, Features);

If this surprised us before, it's likely to surprise us (or someone else) 
again. In that case, I'd recommend permitting `getAArch64ArchFeaturesFromMarch` 
to accept an empty second parameter, and simply `return true` early. Then 
callers don't need such a check and comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103184

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


[PATCH] D104138: Create install targets for scan-build-py.

2021-06-21 Thread Marco Vanotti 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 rGd9cf8291e7ef: Create install targets for scan-build-py. 
(authored by Daniel Hwang , committed by charco).

Changed prior to commit:
  https://reviews.llvm.org/D104138?vs=352199&id=353471#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104138

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake
  clang/tools/CMakeLists.txt
  clang/tools/scan-build-py/CMakeLists.txt
  clang/tools/scan-build-py/bin/analyze-build
  clang/tools/scan-build-py/bin/analyze-c++
  clang/tools/scan-build-py/bin/analyze-cc
  clang/tools/scan-build-py/bin/intercept-build
  clang/tools/scan-build-py/bin/intercept-c++
  clang/tools/scan-build-py/bin/intercept-cc
  clang/tools/scan-build-py/bin/scan-build
  clang/tools/scan-build-py/lib/libear/__init__.py
  clang/tools/scan-build-py/lib/libear/config.h.in
  clang/tools/scan-build-py/lib/libear/ear.c
  clang/tools/scan-build-py/lib/libscanbuild/__init__.py
  clang/tools/scan-build-py/lib/libscanbuild/analyze.py
  clang/tools/scan-build-py/lib/libscanbuild/arguments.py
  clang/tools/scan-build-py/lib/libscanbuild/clang.py
  clang/tools/scan-build-py/lib/libscanbuild/compilation.py
  clang/tools/scan-build-py/lib/libscanbuild/intercept.py
  clang/tools/scan-build-py/lib/libscanbuild/report.py
  clang/tools/scan-build-py/lib/libscanbuild/resources/scanview.css
  clang/tools/scan-build-py/lib/libscanbuild/resources/selectable.js
  clang/tools/scan-build-py/lib/libscanbuild/resources/sorttable.js
  clang/tools/scan-build-py/lib/libscanbuild/shell.py
  clang/tools/scan-build-py/libear/__init__.py
  clang/tools/scan-build-py/libear/config.h.in
  clang/tools/scan-build-py/libear/ear.c
  clang/tools/scan-build-py/libexec/analyze-c++
  clang/tools/scan-build-py/libexec/analyze-cc
  clang/tools/scan-build-py/libexec/intercept-c++
  clang/tools/scan-build-py/libexec/intercept-cc
  clang/tools/scan-build-py/libscanbuild/__init__.py
  clang/tools/scan-build-py/libscanbuild/analyze.py
  clang/tools/scan-build-py/libscanbuild/arguments.py
  clang/tools/scan-build-py/libscanbuild/clang.py
  clang/tools/scan-build-py/libscanbuild/compilation.py
  clang/tools/scan-build-py/libscanbuild/intercept.py
  clang/tools/scan-build-py/libscanbuild/report.py
  clang/tools/scan-build-py/libscanbuild/resources/scanview.css
  clang/tools/scan-build-py/libscanbuild/resources/selectable.js
  clang/tools/scan-build-py/libscanbuild/shell.py
  clang/tools/scan-build-py/tests/__init__.py
  clang/tools/scan-build-py/tests/functional/cases/__init__.py
  clang/tools/scan-build-py/tests/functional/cases/test_exec_anatomy.py
  clang/tools/scan-build-py/tests/functional/cases/test_from_cdb.py
  clang/tools/scan-build-py/tests/functional/cases/test_from_cmd.py
  clang/tools/scan-build-py/tests/unit/test_analyze.py

Index: clang/tools/scan-build-py/tests/unit/test_analyze.py
===
--- clang/tools/scan-build-py/tests/unit/test_analyze.py
+++ clang/tools/scan-build-py/tests/unit/test_analyze.py
@@ -18,9 +18,9 @@
 # scan-build can be easily matched up to compare results.
 def test_directory_name_comparison(self):
 with libear.TemporaryDirectory() as tmpdir, \
- sut.report_directory(tmpdir, False) as report_dir1, \
- sut.report_directory(tmpdir, False) as report_dir2, \
- sut.report_directory(tmpdir, False) as report_dir3:
+ sut.report_directory(tmpdir, False, 'html') as report_dir1, \
+ sut.report_directory(tmpdir, False, 'html') as report_dir2, \
+ sut.report_directory(tmpdir, False, 'html') as report_dir3:
 self.assertLess(report_dir1, report_dir2)
 self.assertLess(report_dir2, report_dir3)
 
Index: clang/tools/scan-build-py/tests/functional/cases/test_from_cmd.py
===
--- clang/tools/scan-build-py/tests/functional/cases/test_from_cmd.py
+++ clang/tools/scan-build-py/tests/functional/cases/test_from_cmd.py
@@ -17,7 +17,7 @@
 @staticmethod
 def run_analyzer(outdir, args, cmd):
 return check_call_and_report(
-['scan-build', '--intercept-first', '-o', outdir] + args,
+['scan-build-py', '--intercept-first', '-o', outdir] + args,
 cmd)
 
 def test_regular_keeps_report_dir(self):
@@ -49,7 +49,7 @@
 with libear.TemporaryDirectory() as tmpdir:
 make = make_args(tmpdir) + ['build_regular']
 outdir = check_call_and_report(
-['scan-build', '--plist', '-o', tmpdir, '--override-compiler'],
+['scan-build-py', '--plist', '-o', tmpdir, '--override-compiler'],
 make)
 
 self.assertTrue(os.path.isdir(outdir))
@@ -59,7 +59,7 @@

[clang] d9cf829 - Create install targets for scan-build-py.

2021-06-21 Thread Marco Vanotti via cfe-commits

Author: Daniel Hwang
Date: 2021-06-21T13:08:34-07:00
New Revision: d9cf8291e7ef26317c13ed9a4e9bd88855166d5d

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

LOG: Create install targets for scan-build-py.

A new revision identical to https://reviews.llvm.org/D101139
The parent revision of aforementioned revision seems to cause pre-merge checks 
to fail opaquely. Seeing if creating a new revision will work.

Reviewed By: phosek

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

Added: 
clang/tools/scan-build-py/CMakeLists.txt
clang/tools/scan-build-py/lib/libear/__init__.py
clang/tools/scan-build-py/lib/libear/config.h.in
clang/tools/scan-build-py/lib/libear/ear.c
clang/tools/scan-build-py/lib/libscanbuild/__init__.py
clang/tools/scan-build-py/lib/libscanbuild/analyze.py
clang/tools/scan-build-py/lib/libscanbuild/arguments.py
clang/tools/scan-build-py/lib/libscanbuild/clang.py
clang/tools/scan-build-py/lib/libscanbuild/compilation.py
clang/tools/scan-build-py/lib/libscanbuild/intercept.py
clang/tools/scan-build-py/lib/libscanbuild/report.py
clang/tools/scan-build-py/lib/libscanbuild/resources/scanview.css
clang/tools/scan-build-py/lib/libscanbuild/resources/selectable.js
clang/tools/scan-build-py/lib/libscanbuild/resources/sorttable.js
clang/tools/scan-build-py/lib/libscanbuild/shell.py
clang/tools/scan-build-py/libexec/analyze-c++
clang/tools/scan-build-py/libexec/analyze-cc
clang/tools/scan-build-py/libexec/intercept-c++
clang/tools/scan-build-py/libexec/intercept-cc

Modified: 
clang/cmake/caches/Fuchsia-stage2.cmake
clang/tools/CMakeLists.txt
clang/tools/scan-build-py/bin/analyze-build
clang/tools/scan-build-py/bin/intercept-build
clang/tools/scan-build-py/bin/scan-build
clang/tools/scan-build-py/tests/__init__.py
clang/tools/scan-build-py/tests/functional/cases/__init__.py
clang/tools/scan-build-py/tests/functional/cases/test_exec_anatomy.py
clang/tools/scan-build-py/tests/functional/cases/test_from_cdb.py
clang/tools/scan-build-py/tests/functional/cases/test_from_cmd.py
clang/tools/scan-build-py/tests/unit/test_analyze.py

Removed: 
clang/tools/scan-build-py/bin/analyze-c++
clang/tools/scan-build-py/bin/analyze-cc
clang/tools/scan-build-py/bin/intercept-c++
clang/tools/scan-build-py/bin/intercept-cc
clang/tools/scan-build-py/libear/__init__.py
clang/tools/scan-build-py/libear/config.h.in
clang/tools/scan-build-py/libear/ear.c
clang/tools/scan-build-py/libscanbuild/__init__.py
clang/tools/scan-build-py/libscanbuild/analyze.py
clang/tools/scan-build-py/libscanbuild/arguments.py
clang/tools/scan-build-py/libscanbuild/clang.py
clang/tools/scan-build-py/libscanbuild/compilation.py
clang/tools/scan-build-py/libscanbuild/intercept.py
clang/tools/scan-build-py/libscanbuild/report.py
clang/tools/scan-build-py/libscanbuild/resources/scanview.css
clang/tools/scan-build-py/libscanbuild/resources/selectable.js
clang/tools/scan-build-py/libscanbuild/shell.py



diff  --git a/clang/cmake/caches/Fuchsia-stage2.cmake 
b/clang/cmake/caches/Fuchsia-stage2.cmake
index 85d96bc52d529..eb001ef6579ce 100644
--- a/clang/cmake/caches/Fuchsia-stage2.cmake
+++ b/clang/cmake/caches/Fuchsia-stage2.cmake
@@ -291,6 +291,7 @@ set(LLVM_TOOLCHAIN_TOOLS
   llvm-symbolizer
   llvm-xray
   sancov
+  scan-build-py
   CACHE STRING "")
 
 set(LLVM_DISTRIBUTION_COMPONENTS

diff  --git a/clang/tools/CMakeLists.txt b/clang/tools/CMakeLists.txt
index 63fe79eccf732..c929f6e665e2c 100644
--- a/clang/tools/CMakeLists.txt
+++ b/clang/tools/CMakeLists.txt
@@ -32,6 +32,7 @@ if(CLANG_ENABLE_STATIC_ANALYZER)
   add_clang_subdirectory(clang-check)
   add_clang_subdirectory(clang-extdef-mapping)
   add_clang_subdirectory(scan-build)
+  add_clang_subdirectory(scan-build-py)
   add_clang_subdirectory(scan-view)
 endif()
 

diff  --git a/clang/tools/scan-build-py/CMakeLists.txt 
b/clang/tools/scan-build-py/CMakeLists.txt
new file mode 100644
index 0..c9f1cb7d6b2a7
--- /dev/null
+++ b/clang/tools/scan-build-py/CMakeLists.txt
@@ -0,0 +1,132 @@
+set (BinFiles
+ "analyze-build"
+ "intercept-build"
+ "scan-build")
+
+set (LibExecs
+ "analyze-c++"
+ "analyze-cc"
+ "intercept-c++"
+ "intercept-cc")
+
+set (LibScanbuild
+ "__init__.py"
+ "analyze.py"
+ "arguments.py"
+ "clang.py"
+ "compilation.py"
+ "intercept.py"
+ "report.py"
+ "shell.py")
+
+set (LibScanbuildResources
+ "scanview.css"
+ "selectable.js"
+ "sorttable.js")
+
+# libear is compiled dynamically in build_libear using the specified cc
+# compiler.
+set (LibEar
+ "__init__.py"
+ "config.h.in"
+ "ear.c"

[PATCH] D103426: Clang: Extend format string checking to wprintf/wscanf

2021-06-21 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/lib/AST/OSLog.cpp:212
+  } else if (Lit->isUTF16()) {
+std::wstring_convert, char16_t> Convert;
+std::u16string U16 = Lit->getStringAsChar16();

cor3ntin wrote:
> I'm not sure I have a better suggestion but `codecvt_utf8_utf16` is 
> deprecated in C++17
Good point -- this likely should be lifted into a common interface (as it 
appears several times in the patch) and make use of the existing LLVM UTF 
conversion functionality: 
https://github.com/intel/llvm/blob/sycl/llvm/include/llvm/Support/ConvertUTF.h


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103426

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


[clang] 5013131 - [SYCL][NFC] Ensure SYCL kernel for unique-stable-name is unqualified.

2021-06-21 Thread Erich Keane via cfe-commits

Author: Erich Keane
Date: 2021-06-21T12:51:23-07:00
New Revision: 5013131875402539a249dca47c58cca7c359baf8

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

LOG: [SYCL][NFC] Ensure SYCL kernel for unique-stable-name is unqualified.

Discovered in our downstream, this function that is used to get the type
of the kernel parameter type needs to be unqualified, otherwise when our
downstream uses this function in a slightly different way, the kernel
types no longer match.

Added: 


Modified: 
clang/lib/Sema/SemaSYCL.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaSYCL.cpp b/clang/lib/Sema/SemaSYCL.cpp
index 3b48a53efc0d..7ae78b1d1943 100644
--- a/clang/lib/Sema/SemaSYCL.cpp
+++ b/clang/lib/Sema/SemaSYCL.cpp
@@ -54,14 +54,14 @@ bool Sema::checkSYCLDeviceFunction(SourceLocation Loc, 
FunctionDecl *Callee) {
 // this was passed by value, and in SYCL2020, it is passed by reference.
 static QualType GetSYCLKernelObjectType(const FunctionDecl *KernelCaller) {
   assert(KernelCaller->getNumParams() > 0 && "Insufficient kernel parameters");
+  // SYCL 1.2.1
   QualType KernelParamTy = KernelCaller->getParamDecl(0)->getType();
 
   // SYCL 2020 kernels are passed by reference.
   if (KernelParamTy->isReferenceType())
-return KernelParamTy->getPointeeType();
+KernelParamTy = KernelParamTy->getPointeeType();
 
-  // SYCL 1.2.1
-  return KernelParamTy;
+  return KernelParamTy.getUnqualifiedType();
 }
 
 void Sema::AddSYCLKernelLambda(const FunctionDecl *FD) {



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


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

2021-06-21 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

In D104505#2830996 , @tra wrote:

> I don't think we want to do this.
>
>   struct S {
>   S& operator <<(int x);
>   };
>   
>   __device__ void foo() {
>   S s;
>   s<<1;
>   }
>   
>   :7:6: error: invalid operands to binary expression ('S' and 'int')
>   s<<1;
>   ~^ ~
>   :2:8: note: candidate function not viable: call to __host__ 
> function from __device__ function
>   S& operator <<(int x);
>
> https://godbolt.org/z/Maa6Ed94W
> I believe diagnostic issued by clang is completely valid here.
>
> This is the case where clang and NVCC fundamentally differ in their 
> compilation approach. NVCC effectively does not see device-side code during 
> host compilation. Clang does. The code above is wrong regardless of whether 
> we're compiling for the host of for the device and therefore, I believe, the 
> diagnostic is appropriate.
>
> If the operator is intended to be used on GPU, it should have appropriate 
> attributes. If it's not, then it's an error. NVCC not diagnosing it is a 
> deficiency in NVCC, IMO. This particular problem should be fixed in the 
> source code.

nvcc does see and parse the device functions in host compilation, e.g.

  # cat a.cu
  struct S {
  S& operator <<(int x);
  };
  
  #if !__CUDA_ARCH__
  __device__ void foo() {
  S s;
  s<<1;
  s<<;
  }
  #endif
  
  # nvcc a.cu
  a.cu(9): error: expected an expression

If nvcc simply skips all device functions, it will not diagnose the syntax 
error in the above code. It just chooses not to diagnose overloading resolution 
related errors.

P.S. To reproduce the above diagnostics you need to execute nvcc directly 
instead of on goldbolt.org, since glodbolt.org only does device compilation for 
CUDA.


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

https://reviews.llvm.org/D104505

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


[PATCH] D103426: Clang: Extend format string checking to wprintf/wscanf

2021-06-21 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin added inline comments.



Comment at: clang/lib/AST/OSLog.cpp:214
+std::u16string U16 = Lit->getStringAsChar16();
+String = Convert.to_bytes(U16); // u"char16_t String"
+  } else if (Lit->isUTF32()) {

If `getStringAsChar16` contains the string after `\x` escape replacement, it 
might contain invalid code units or lone surrogate, in which case `to_bytes` 
might throw if `Convert` is not initialized with an error string


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103426

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


[PATCH] D103426: Clang: Extend format string checking to wprintf/wscanf

2021-06-21 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added subscribers: cor3ntin, tahonermann.
aaron.ballman added a comment.

Adding some subscribers from WG21 SG16 who know far more about character 
encodings and their APIs than I do, as they may have feedback on the design 
aspects of this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103426

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


[PATCH] D103426: Clang: Extend format string checking to wprintf/wscanf

2021-06-21 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

I had some time to look into this a bit more today. My review still isn't 
complete, but there's enough here to warrant some discussion.




Comment at: clang/include/clang/AST/Expr.h:1846-1871
+  std::string getStringAsChar() const {
+assert(getCharByteWidth() == 1 &&
+   "This function is used in places that assume strings use char");
+return std::string(getTrailingObjects(), getTrailingObjects() 
+ getByteLength());
+  }
+  
+  std::u16string getStringAsChar16() const {

One potential issue to this is that in C++, these types are defined to be 
UTF-16 and UTF-32, whereas in C, that isn't always the case. Currently, Clang 
defines `__STDC_UTF_16__` and `__STDC_UTF_32__` on all targets, but we may need 
to add some sanity checks to catch if a target overrides that behavior. 
Currently, all the targets in Clang are keeping that promise, but I have no 
idea what shenanigans downstream users get up to and whether their targets 
remove the macro definition or define it to `0` instead of `1`.



Comment at: clang/include/clang/AST/FormatString.h:83
 AsMAllocate,  // for '%ms', GNU extension to scanf
+AsUTF16,  // for '%l16(c|s)', soon to be standardized
+AsUTF32,  // for '%l32(c|s)', soon to be standardized

May want to drop the "soon to be standardized" given that the proposal hasn't 
been seen by WG14 yet. I think it's fine to say "Clang extension", though. More 
on the format specifier itself, below.



Comment at: clang/include/clang/AST/Type.h:1975
   bool isBooleanType() const;
+  bool isType(const std::string TypeName) const;
   bool isCharType() const;

It's not clear from the header file what this function actually *does*. 
Presumably, everything that can be represented by a `Type` is a type, so I'd 
assume this returns `true` always. Or should this be a static function?



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:6961
+def err_format_invalid_type : Error<
+  "format strings type is invalid">;
 def err_unexpected_interface : Error<

There are no tests for this diagnostic. Also, should the diagnostic specify 
which format string type is invalid (given that format strings can contain 
multiple type markings)?

Also, this replaces an existing diagnostic that's a warning, but is now 
upgraded to an error. Why is an error appropriate when it was warning before? 
Did you consider leaving this as a warning but marking it as defaulting to an 
error, so users can still disable the diagnostic and allow their code to 
compile?



Comment at: clang/lib/AST/Expr.cpp:1197
  unsigned *StartTokenByteOffset) const {
-  assert((getKind() == StringLiteral::Ascii ||
-  getKind() == StringLiteral::UTF8) &&

I don't see changes that make this assertion valid to remove -- have I missed 
something?



Comment at: clang/lib/AST/FormatString.cpp:235-240
+  if (LO.C2x && I + 1 != E && I[0] == '1' && I[1] == '6') {
+++I;
+++I;
+lmKind = LengthModifier::AsUTF16;
+break;
+  } else if (LO.C2x && I + 1 != E && I[0] == '3' && I[1] == '2') {

I don't think this is a conforming extension to C -- lowercase length modifiers 
and conversion specifiers are reserved for the standard, and uppercase length 
modifiers and conversion specifiers are reserved for the implementation. `l16` 
starts with a lowercase letter, so it's reserved for the standard.

Note: WG14 has been considering extensions in a closely-related space (integer 
types rather than string or character types) that you may be interested in, if 
you're not already aware of it: 
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2511.pdf. This proposal was 
not adopted, but did have strong sentiment for something along these lines.



Comment at: clang/lib/AST/OSLog.cpp:225
+  
+  StringRef Data(String);
+  

Is this actually needed, or can you use a `std::string` iterator when calling 
`ParsePrintfString()`?



Comment at: clang/lib/AST/PrintfFormatString.cpp:254-257
+  if (ParseLengthModifier(FS, I, E, LO) && I == E) { // THIS IS WHERE IT 
FREAKS OUT
 // No more characters left?
 if (Warn)
+  printf("ParsePrintfSpecifier: Incomplete Specifier 8\n");

Surprising comment and what looks to be some debugging code?



Comment at: clang/lib/AST/PrintfFormatString.cpp:635
   }
-  if (LM.getKind() == LengthModifier::AsWide)
-return ArgType(ArgType::WCStrTy, "wchar_t *");

It looks like this coverage got lost?



Comment at: clang/lib/AST/PrintfFormatString.cpp:844
   case BuiltinType::SChar:
+  case BuiltinType::Char8:
 LM.setKind(LengthModifier::AsChar);
--

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

2021-06-21 Thread Jian Cai via Phabricator via cfe-commits
jcai19 updated this revision to Diff 353440.
jcai19 added a comment.

After chatting with @nickdesaulniers, we have decided to abondoned D104656 
 in favor of keeping all the updates to this 
differential review for consistency. Appologies for any inconvenience caused.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103184

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

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

[clang] a63d4f6 - [Clang][Codegen] rename no_profile fn attr no_profile_instrument_function

2021-06-21 Thread Nick Desaulniers via cfe-commits

Author: Nick Desaulniers
Date: 2021-06-21T11:42:06-07:00
New Revision: a63d4f6cbab133b0f1ce9afb562546fcc5bb2680

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

LOG: [Clang][Codegen] rename no_profile fn attr no_profile_instrument_function

GCC has had this function attribute since GCC 7.1 for this purpose. I
added "no_profile" last week in D104475; rename this to
"no_profile_instrument_function" to improve compatibility with GCC.

Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223#c11

Reviewed By: MaskRay, aaron.ballman

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

Added: 
clang/test/Sema/no_profile_instrument_function-attribute.c

Modified: 
clang/include/clang/Basic/Attr.td
clang/include/clang/Basic/AttrDocs.td
clang/test/CodeGen/no_profile.c

Removed: 
clang/test/Sema/no_profile-attribute.c



diff  --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index 8829b4b6d560b..bfcf5f798d8fe 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -1971,9 +1971,9 @@ def NoInstrumentFunction : InheritableAttr {
 }
 
 def NoProfileFunction : InheritableAttr {
-  let Spellings = [Clang<"no_profile">];
+  let Spellings = [GCC<"no_profile_instrument_function">];
   let Subjects = SubjectList<[Function]>;
-  let Documentation = [NoProfileDocs];
+  let Documentation = [NoProfileInstrumentFunctionDocs];
   let SimpleHandler = 1;
 }
 

diff  --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index 6173c8cd90af0..bf51b05acaaa2 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -2559,12 +2559,12 @@ This attribute accepts a single parameter that must be 
one of the following:
   }];
 }
 
-def NoProfileDocs : Documentation {
+def NoProfileInstrumentFunctionDocs : Documentation {
   let Category = DocCatFunction;
   let Content = [{
-Use the ``no_profile`` attribute on a function declaration to denote that the
-compiler should not instrument the function with profile-related
-instrumentation, such as via the
+Use the ``no_profile_instrument_function`` attribute on a function declaration
+to denote that the compiler should not instrument the function with
+profile-related instrumentation, such as via the
 ``-fprofile-generate`` / ``-fprofile-instr-generate`` /
 ``-fcs-profile-generate`` / ``-fprofile-arcs`` flags.
 }];

diff  --git a/clang/test/CodeGen/no_profile.c b/clang/test/CodeGen/no_profile.c
index 50ca71f4fa0ed..9c9524338fe59 100644
--- a/clang/test/CodeGen/no_profile.c
+++ b/clang/test/CodeGen/no_profile.c
@@ -8,7 +8,7 @@
 // RUN:   -emit-llvm -o - %s | FileCheck %s
 int g(int);
 
-void __attribute__((no_profile)) no_instr() {
+void __attribute__((no_profile_instrument_function)) no_instr() {
 // CHECK: define {{.*}}void @no_instr() [[ATTR:#[0-9]+]]
 }
 

diff  --git a/clang/test/Sema/no_profile-attribute.c 
b/clang/test/Sema/no_profile-attribute.c
deleted file mode 100644
index b3c073f130ac3..0
--- a/clang/test/Sema/no_profile-attribute.c
+++ /dev/null
@@ -1,13 +0,0 @@
-// RUN: %clang_cc1 %s -fsyntax-only -verify
-__attribute__((no_profile))
-void no_profile0(void);
-#if !__has_attribute(no_profile)
-#error "Where did the no_profile function attribute go?"
-#endif
-
-void no_profile1(__attribute__((no_profile)) int param); // expected-warning 
{{'no_profile' attribute only applies to functions}}
-__attribute__((no_profile(""))) // expected-error {{'no_profile' attribute 
takes no arguments}}
-void no_profile2(void);
-void no_profile3(void) {
-  __attribute__((no_profile)); // expected-error {{'no_profile' attribute 
cannot be applied to a statement}}
-}

diff  --git a/clang/test/Sema/no_profile_instrument_function-attribute.c 
b/clang/test/Sema/no_profile_instrument_function-attribute.c
new file mode 100644
index 0..4ede13c741077
--- /dev/null
+++ b/clang/test/Sema/no_profile_instrument_function-attribute.c
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 %s -fsyntax-only -verify
+__attribute__((no_profile_instrument_function))
+void no_profile0(void);
+#if !__has_attribute(no_profile_instrument_function)
+#error "Where did the no_profile_instrument_function function attribute go?"
+#endif
+
+void no_profile1(__attribute__((no_profile_instrument_function)) int param); 
// expected-warning {{'no_profile_instrument_function' attribute only applies 
to functions}}
+__attribute__((no_profile_instrument_function(""))) // expected-error 
{{'no_profile_instrument_function' attribute takes no arguments}}
+void no_profile2(void);
+void no_profile3(void) {
+  __attribute__((no_profile_instrument_function)); // expected-error 
{{'no_profile_instrument_function' attribute cannot be applied to a statement}}
+}


   

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

2021-06-21 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers requested changes to this revision.
nickdesaulniers added a comment.
This revision now requires changes to proceed.

removing LGTM until the reland is posted for review here so we can use the 
history tab to observe the changes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103184

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


[PATCH] D104658: [Clang][Codegen] rename no_profile fn attr no_profile_instrument_function

2021-06-21 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay accepted this revision.
MaskRay added a comment.

(This was why I suggested we waited a bit on GCC's response...)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104658

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


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

2021-06-21 Thread Jian Cai via Phabricator via cfe-commits
jcai19 added a comment.

In D104656#2831034 , @nickdesaulniers 
wrote:

>> This reverts commit fd11a26d368c5a909fb88548fef2cee7a6c2c931 
>> 
>
> Shouldn't that be `This relands commit 
> fd11a26d368c5a909fb88548fef2cee7a6c2c931`?

Done. Thanks for noticing the typo.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104656

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


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

2021-06-21 Thread Jian Cai via Phabricator via cfe-commits
jcai19 updated this revision to Diff 353431.
jcai19 added a comment.

Add comments explaning the difference with D103184 
. The implementation in D103184 
 unconditionally calls 
getAArch64ArchFeaturesFromMarch, which returns false when an irrelevant -Wa 
value is detected and parsed (e.g. -Wa,--version) and causes Clang to bail out.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104656

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

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

[PATCH] D104658: [Clang][Codegen] rename no_profile fn attr no_profile_instrument_function

2021-06-21 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104658

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


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

2021-06-21 Thread Jian Cai via Phabricator via cfe-commits
jcai19 updated this revision to Diff 353427.
jcai19 added a comment.

Use the original flawed code for future reference.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103184

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

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

[PATCH] D104475: [Clang][Codegen] Add GNU function attribute 'no_profile' and lower it to noprofile

2021-06-21 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers added a comment.

It looks like GCC has had `no_profile_instrument_function` since GCC 7.1 for 
this purpose.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223#c11

Follow up: https://reviews.llvm.org/D104658.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104475

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


[PATCH] D104658: [Clang][Codegen] rename no_profile fn attr no_profile_instrument_function

2021-06-21 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers created this revision.
nickdesaulniers added reviewers: MaskRay, void, phosek, aaron.ballman.
nickdesaulniers requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

GCC has had this function attribute since GCC 7.1 for this purpose. I
add "no_profile" last week in D104475 ; 
rename this to
"no_profile_instrument_function" to improve compatibility with GCC.

Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223#c11


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104658

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/test/CodeGen/no_profile.c
  clang/test/Sema/no_profile-attribute.c
  clang/test/Sema/no_profile_instrument_function-attribute.c


Index: clang/test/Sema/no_profile_instrument_function-attribute.c
===
--- /dev/null
+++ clang/test/Sema/no_profile_instrument_function-attribute.c
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 %s -fsyntax-only -verify
+__attribute__((no_profile_instrument_function))
+void no_profile0(void);
+#if !__has_attribute(no_profile_instrument_function)
+#error "Where did the no_profile_instrument_function function attribute go?"
+#endif
+
+void no_profile1(__attribute__((no_profile_instrument_function)) int param); 
// expected-warning {{'no_profile_instrument_function' attribute only applies 
to functions}}
+__attribute__((no_profile_instrument_function(""))) // expected-error 
{{'no_profile_instrument_function' attribute takes no arguments}}
+void no_profile2(void);
+void no_profile3(void) {
+  __attribute__((no_profile_instrument_function)); // expected-error 
{{'no_profile_instrument_function' attribute cannot be applied to a statement}}
+}
Index: clang/test/Sema/no_profile-attribute.c
===
--- clang/test/Sema/no_profile-attribute.c
+++ /dev/null
@@ -1,13 +0,0 @@
-// RUN: %clang_cc1 %s -fsyntax-only -verify
-__attribute__((no_profile))
-void no_profile0(void);
-#if !__has_attribute(no_profile)
-#error "Where did the no_profile function attribute go?"
-#endif
-
-void no_profile1(__attribute__((no_profile)) int param); // expected-warning 
{{'no_profile' attribute only applies to functions}}
-__attribute__((no_profile(""))) // expected-error {{'no_profile' attribute 
takes no arguments}}
-void no_profile2(void);
-void no_profile3(void) {
-  __attribute__((no_profile)); // expected-error {{'no_profile' attribute 
cannot be applied to a statement}}
-}
Index: clang/test/CodeGen/no_profile.c
===
--- clang/test/CodeGen/no_profile.c
+++ clang/test/CodeGen/no_profile.c
@@ -8,7 +8,7 @@
 // RUN:   -emit-llvm -o - %s | FileCheck %s
 int g(int);
 
-void __attribute__((no_profile)) no_instr() {
+void __attribute__((no_profile_instrument_function)) no_instr() {
 // CHECK: define {{.*}}void @no_instr() [[ATTR:#[0-9]+]]
 }
 
Index: clang/include/clang/Basic/AttrDocs.td
===
--- clang/include/clang/Basic/AttrDocs.td
+++ clang/include/clang/Basic/AttrDocs.td
@@ -2559,12 +2559,12 @@
   }];
 }
 
-def NoProfileDocs : Documentation {
+def NoProfileInstrumentFunctionDocs : Documentation {
   let Category = DocCatFunction;
   let Content = [{
-Use the ``no_profile`` attribute on a function declaration to denote that the
-compiler should not instrument the function with profile-related
-instrumentation, such as via the
+Use the ``no_profile_instrument_function`` attribute on a function declaration
+to denote that the compiler should not instrument the function with
+profile-related instrumentation, such as via the
 ``-fprofile-generate`` / ``-fprofile-instr-generate`` /
 ``-fcs-profile-generate`` / ``-fprofile-arcs`` flags.
 }];
Index: clang/include/clang/Basic/Attr.td
===
--- clang/include/clang/Basic/Attr.td
+++ clang/include/clang/Basic/Attr.td
@@ -1971,9 +1971,9 @@
 }
 
 def NoProfileFunction : InheritableAttr {
-  let Spellings = [Clang<"no_profile">];
+  let Spellings = [GCC<"no_profile_instrument_function">];
   let Subjects = SubjectList<[Function]>;
-  let Documentation = [NoProfileDocs];
+  let Documentation = [NoProfileInstrumentFunctionDocs];
   let SimpleHandler = 1;
 }
 


Index: clang/test/Sema/no_profile_instrument_function-attribute.c
===
--- /dev/null
+++ clang/test/Sema/no_profile_instrument_function-attribute.c
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 %s -fsyntax-only -verify
+__attribute__((no_profile_instrument_function))
+void no_profile0(void);
+#if !__has_attribute(no_profile_instrument_function)
+#error "Where did the no_profile_instrument_function function attribute go?"
+#endif
+
+void no_profile1(__attribute__((no_profile_instrument_function))

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

2021-06-21 Thread Leonard Chan via Phabricator via cfe-commits
leonardchan updated this revision to Diff 353421.
leonardchan marked an inline comment as done.
leonardchan added a comment.

Updated and rebased.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104553

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


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


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

[PATCH] D95588: [RISCV] Implement the MC layer support of P extension

2021-06-21 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added inline comments.



Comment at: llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp:950
+  assert(Reg >= RISCV::X0 && Reg <= RISCV::X31 && "Invalid register");
+  if ((Reg - RISCV::X0) % 2 || Reg == RISCV::X0)
+return false;

I think this can just be

```
return ((Reg - RISCV::X0) % 2) == 0 && Reg != RISCV::X0
```

Though the spec talks about what happens when X0_X1 is used as a source or 
dest, so should we really be forbidding X0?



Comment at: llvm/lib/Target/RISCV/Disassembler/RISCVDisassembler.cpp:443
+if (STI.getFeatureBits()[RISCV::FeatureExtZpsfoperand]) {
+  if (!STI.getFeatureBits()[RISCV::Feature64Bit]) {
+LLVM_DEBUG(

Fold the 64-bit check into the if above with && to reduce nesting.



Comment at: llvm/lib/Target/RISCV/RISCVInstrFormats.td:130
 def OPC_OP_FP : RISCVOpcode<0b1010011>;
+def OPC_OP_P  : RISCVOpcode<0b1110111>;
 def OPC_OP_V  : RISCVOpcode<0b1010111>;

I think these opcodes are in numerical order, so please put this at the end to 
maintain that.



Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoP.td:131
+   opcodestr, "$rd, $rs1, $rs2, $rs3"> {
+  let Inst{31-30} = funct2;
+  let Inst{29-25} = rs3;

Are the positions correct? They don't match the 0.9.5-draft-20210617 pdf. 
Change log suggests it was modified in 0.5.3?



Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoP.td:950
+
+let EmitPriority = 2, Predicates = [HasStdExtZpn] in {
+def : InstAlias<"rdov $rd", (CSRRS  GPR:$rd, 0x009, X0)>;

Why do these need EmitPriority = 2?



Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoP.td:951
+let EmitPriority = 2, Predicates = [HasStdExtZpn] in {
+def : InstAlias<"rdov $rd", (CSRRS  GPR:$rd, 0x009, X0)>;
+def : InstAlias<"clrov",(CSRRCI  X0, 0x009,  1)>;

Can we give "def : SysReg<"vxsat", 0x009>;" a name in RISCVSystemOperands.td so 
we can reference it's encoding directly here like we do for these aliases

```
def : InstAlias<"rdinstret $rd", (CSRRS GPR:$rd, INSTRET.Encoding, X0)>;



def : InstAlias<"rdcycle $rd",   (CSRRS GPR:$rd, CYCLE.Encoding, X0)>;  



def : InstAlias<"rdtime $rd",(CSRRS GPR:$rd, TIME.Encoding, X0)>;  
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95588

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


[PATCH] D103615: [Clang] Add option for vector compare compatibility.

2021-06-21 Thread Nemanja Ivanovic via Phabricator via cfe-commits
nemanjai added a comment.

I haven't had time to review this yet, but I just wanted to chime in on the 
option spelling and description. I think we should go with:

  -faltivec-src-compat={xl|gcc|mixed}
Source-level compatibility for Altivec vectors (for PowerPC targets). This
includes results of vector comparison (scalar for 'xl', vector for 'gcc')
as well as behavior when initializing with a scalar (splatting for 'xl',
element zero only for 'gcc'). For 'mixed', the compatibility is as 'gcc' for
'vector bool/vector pixel' and as 'xl' for other types. Current default is
'mixed'.

The name makes it clear that this has to do with source compatibility for 
Altivec vector types. The description is rather verbose - much more so than 
most options, but I think that is useful for an option such as this - that has 
a complex set of implications.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103615

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


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

2021-06-21 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers added a comment.

> This reverts commit fd11a26d368c5a909fb88548fef2cee7a6c2c931 
> 

Shouldn't that be `This relands commit 
fd11a26d368c5a909fb88548fef2cee7a6c2c931`?

It's pretty hard to see what's different in this new version since the 
original, can you comment on how you fixed the issue?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104656

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


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

2021-06-21 Thread Jian Cai via Phabricator via cfe-commits
jcai19 closed this revision.
jcai19 added a comment.

Sorry it's probably clearer to use a new differential review for relanding. 
I've created https://reviews.llvm.org/D104656. Sorry for the noises.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103184

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


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

2021-06-21 Thread Jian Cai via Phabricator via cfe-commits
jcai19 created this revision.
Herald added subscribers: danielkiss, kristof.beyls.
jcai19 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

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


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104656

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

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

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

2021-06-21 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

I don't think we want to do this.

  struct S {
  S& operator <<(int x);
  };
  
  __device__ void foo() {
  S s;
  s<<1;
  }
  
  :7:6: error: invalid operands to binary expression ('S' and 'int')
  s<<1;
  ~^ ~
  :2:8: note: candidate function not viable: call to __host__ function 
from __device__ function
  S& operator <<(int x);

https://godbolt.org/z/Maa6Ed94W
I believe diagnostic issued by clang is completely valid here.

This is the case where clang and NVCC fundamentally differ in their compilation 
approach. NVCC effectively does not see device-side code during host 
compilation. Clang does. The code above is wrong regardless of whether we're 
compiling for the host of for the device and therefore, I believe, the 
diagnostic is appropriate.

If the operator is intended to be used on GPU, it should have appropriate 
attributes. If it's not, then it's an error. NVCC not diagnosing it is a 
deficiency in NVCC, IMO. This particular problem should be fixed in the source 
code.


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

https://reviews.llvm.org/D104505

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


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

2021-06-21 Thread Jian Cai via Phabricator via cfe-commits
jcai19 updated this revision to Diff 353410.
jcai19 edited the summary of this revision.
jcai19 added a comment.

The original implementation was indeed flawed. The failed test does not specify 
target triple so on X86 machines the issue won't happen unless I explicitly 
specify "-target aarch64".
This fixes the problem.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103184

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

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

[PATCH] D103615: [Clang] Add option for vector compare compatibility.

2021-06-21 Thread Bardia Mahjour via Phabricator via cfe-commits
bmahjour added a comment.

Sorry I didn't mention this in my earlier comment about the option name, but I 
think that all inconsistencies in handling vector bool/pixel types should be 
controlled by a single compatibility option. For example the current special 
handling of initialization (splat vs non-splat) for these types should also be 
option controlled. For that reason we should design and name the option in a 
more generic way. The same consideration should go into the wording of the 
deprecation warning.
Some suggestions:

rename `-vector-compare-compat` to `-altivec-compatibility` or 
`-altivec-compat` or  '-altivec-bool-pixel-compat` or 
`-vector-bool-pixel-compat`. (I prefer the last two)
reword the message to:
"Current handling of vector bool and vector pixel types in this context are 
deprecated. The default behaviour will soon change to that implied by the 
'-altivec-compat=xl' option"

Please also update the description section of this review.




Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:7442
+  "pixel. Comparisons between vector bool/pixel types will soon return "
+  "a scalar value instead of a vector value by default">;
+

We need to add a new grouping (see `InGroup<...>`) for this, otherwise users 
won't be able to turn this warning off individually. There is also a clang LIT 
test that would fail if a warning message is added without a grouping 
specified. Please make sure check-all passes.



Comment at: clang/include/clang/Basic/LangOptions.def:130
+ENUM_LANGOPT(VectorCompareCompat, VectorCompareCompatKind, 2,
+ VectorCompareCompatKind::Mixed, "vector compare compatibility")
 LANGOPT(ConvergentFunctions, 1, 1, "Assume convergent functions")

`VectorCompareCompatKind::Mixed` -> `VectorCompareCompatKind::Default`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103615

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


[PATCH] D103849: Fix undeduced type when instanciating template member

2021-06-21 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

This LGTM as far as the fix seems like an improvement, though I'm not 100% 
certain that the fix is in the right place. Please give a few more days for 
@rsmith to consider the changes before landing, but if we don't hear from him 
by Fri (6/25), go ahead and land.


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

https://reviews.llvm.org/D103849

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


[PATCH] D103380: [C++20] Support for lambdas in unevaluated context

2021-06-21 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.

I think this is incremental progress that LGTM, but let's wait a few days in 
case @rsmith has concerns before landing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103380

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

2021-06-21 Thread Peter Klausler via Phabricator via cfe-commits
klausler added a comment.

In D103612#2830111 , @awarzynski 
wrote:

> In D103612#2827468 , @klausler 
> wrote:
>
>> Kind suffixes are described in subclause 7.4.3 of Fortran 2018, e.g. R708 on 
>> p. 58.
>
> Many thanks for this reference.
>
> So when calling `Unparse,` one specifes `AnalyzedObjectsAsFortran` (i.e. the 
> optional last argument) to get more semantic context in the dump, right?

It's for better code coverage when testing.  When the internal representations 
of expressions & variables are dumped by unparsing rather than the original 
parse trees, it allows semantic analysis (esp. folding) to be exercised.  If an 
unparsed program compiles and runs fine when unparsed into gfortran without 
this flag, but fails when the flag is present, there's a bug.  This feature 
allows much of the frontend to undergo some testing and debugging in the 
absence of a code generator.

It's also useful for self-testing via a "parse/unparse/reparse/unparse" mode, 
in which we recompile unparsed Fortran and check that it unparses to the same 
output.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103612

___
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

2021-06-21 Thread Gabor Marton via Phabricator via cfe-commits
martong added a comment.

In D103314#2829806 , @uabelho wrote:

> Hi,
>
> I'm seeing a failed assertion with this patch.
> Reproduce with
>
>   clang --analyze bbi-57338.c
>
> Result:
>
>   clang: /repo/uabelho/master-github/llvm/include/llvm/ADT/APSInt.h:148: bool 
> llvm::APSInt::operator<(const llvm::APSInt &) const: Assertion `IsUnsigned == 
> RHS.IsUnsigned && "Signedness mismatch!"' failed.
>
> F17516582: bbi-57338.c 

Thanks Mikael for the reproducer, I am going to debug tomorrow.


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

2021-06-21 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko marked an inline comment as done.
vsavchenko added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/SVals.cpp:151
+  Optional VisitNonLocLazyCompoundVal(nonloc::LazyCompoundVal LCV) {
+return Visit(LCV.getRegion());
+  }

NoQ wrote:
> This is correct except you need to get the value type, not the pointer type.
> 
> `LazyCompoundVal` is a `prvalue` and its parent region is the location in 
> which this `prvalue` resided some time in the past. So the parent region is 
> of the right type and it's always typed but you need the pointee type.
OK then, can you maybe hint how can I write a test where this is going to be a 
pointer type (or maybe then `getType` for regions works incorrectly).



Comment at: clang/lib/StaticAnalyzer/Core/SVals.cpp:162
+  }
+  Optional VisitSymExpr(const SymExpr *SE) { return SE->getType(); }
+};

NoQ wrote:
> The biggest disappointment here is that this case is technically incorrect 
> for the very basic case of integral types.
> 
> Because we drop casts, a symbol of an integral type may technically represent 
> a value of a completely different integral type, the same symbol may 
> represent multiple different values of different integral types, and so on.
> 
> This is what ruins the dream of modeling Region Store binding extents as 
> value widths: for the single most important case we'd be getting incorrect 
> answers.
I hope that the introduction of symbolic casts is around the corner.



Comment at: clang/unittests/StaticAnalyzer/SValTest.cpp:144
+  SVal X = getByName("x");
+  // TODO: Find a way how to get type of nonloc::ConcreteInt
+  EXPECT_FALSE(X.getType().hasValue());

NoQ wrote:
> `nonloc::ConcreteInt` is basically an `APSInt`. You can extract bit width and 
> signedness and feed it to `ASTContext::getIntTypeForBitwidth()`.
> 
> `loc::ConcreteInt` is always of the pointer type. Unless, of course, you have 
> a target architecture with pointers of different widths, then whelp we aren't 
> quite there yet. But when we get there, I guess it's still `APSInt` under the 
> hood so a similar trick could be used.
OK, I guess having `ASTContext` as a parameter is the best choice we can have 
here and not such a high price to pay.


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] D104392: [HIP] Add support functions for C++ polymorphic types

2021-06-21 Thread Yaxun Liu via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG186f2ac612ad: [HIP] Add support functions for C++ 
polymorphic types (authored by yaxunl).

Changed prior to commit:
  https://reviews.llvm.org/D104392?vs=353041&id=353388#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104392

Files:
  clang/lib/Headers/__clang_hip_runtime_wrapper.h
  clang/test/Headers/hip-header.hip


Index: clang/test/Headers/hip-header.hip
===
--- clang/test/Headers/hip-header.hip
+++ clang/test/Headers/hip-header.hip
@@ -14,6 +14,29 @@
 
 // expected-no-diagnostics
 
+// Check support for pure and deleted virtual functions
+struct base {
+  __host__
+  __device__
+  virtual void pv() = 0;
+  __host__
+  __device__
+  virtual void dv() = delete;
+};
+struct derived:base {
+  __host__
+  __device__
+  virtual void pv() override {};
+};
+__device__ void test_vf() {
+derived d;
+}
+// CHECK: @_ZTV7derived = linkonce_odr unnamed_addr addrspace(1) constant { [4 
x i8*] } { [4 x i8*] [i8* null, i8* null, i8* bitcast (void (%struct.derived*)* 
@_ZN7derived2pvEv to i8*), i8* bitcast (void ()* @__cxa_deleted_virtual to 
i8*)] }, comdat, align 8
+// CHECK: @_ZTV4base = linkonce_odr unnamed_addr addrspace(1) constant { [4 x 
i8*] } { [4 x i8*] [i8* null, i8* null, i8* bitcast (void ()* 
@__cxa_pure_virtual to i8*), i8* bitcast (void ()* @__cxa_deleted_virtual to 
i8*)] }, comdat, align 8
+
+// CHECK: define{{.*}}void @__cxa_pure_virtual()
+// CHECK: define{{.*}}void @__cxa_deleted_virtual()
+
 struct Number {
   __device__ Number(float _x) : x(_x) {}
   float x;
Index: clang/lib/Headers/__clang_hip_runtime_wrapper.h
===
--- clang/lib/Headers/__clang_hip_runtime_wrapper.h
+++ clang/lib/Headers/__clang_hip_runtime_wrapper.h
@@ -51,6 +51,23 @@
   #define nullptr NULL;
 #endif
 
+#ifdef __cplusplus
+extern "C" {
+  __attribute__((__visibility__("default")))
+  __attribute__((weak))
+  __attribute__((noreturn))
+  __device__ void __cxa_pure_virtual(void) {
+__builtin_trap();
+  }
+  __attribute__((__visibility__("default")))
+  __attribute__((weak))
+  __attribute__((noreturn))
+  __device__ void __cxa_deleted_virtual(void) {
+__builtin_trap();
+  }
+}
+#endif //__cplusplus
+
 #if __HIP_ENABLE_DEVICE_MALLOC__
 extern "C" __device__ void *__hip_malloc(size_t __size);
 extern "C" __device__ void *__hip_free(void *__ptr);


Index: clang/test/Headers/hip-header.hip
===
--- clang/test/Headers/hip-header.hip
+++ clang/test/Headers/hip-header.hip
@@ -14,6 +14,29 @@
 
 // expected-no-diagnostics
 
+// Check support for pure and deleted virtual functions
+struct base {
+  __host__
+  __device__
+  virtual void pv() = 0;
+  __host__
+  __device__
+  virtual void dv() = delete;
+};
+struct derived:base {
+  __host__
+  __device__
+  virtual void pv() override {};
+};
+__device__ void test_vf() {
+derived d;
+}
+// CHECK: @_ZTV7derived = linkonce_odr unnamed_addr addrspace(1) constant { [4 x i8*] } { [4 x i8*] [i8* null, i8* null, i8* bitcast (void (%struct.derived*)* @_ZN7derived2pvEv to i8*), i8* bitcast (void ()* @__cxa_deleted_virtual to i8*)] }, comdat, align 8
+// CHECK: @_ZTV4base = linkonce_odr unnamed_addr addrspace(1) constant { [4 x i8*] } { [4 x i8*] [i8* null, i8* null, i8* bitcast (void ()* @__cxa_pure_virtual to i8*), i8* bitcast (void ()* @__cxa_deleted_virtual to i8*)] }, comdat, align 8
+
+// CHECK: define{{.*}}void @__cxa_pure_virtual()
+// CHECK: define{{.*}}void @__cxa_deleted_virtual()
+
 struct Number {
   __device__ Number(float _x) : x(_x) {}
   float x;
Index: clang/lib/Headers/__clang_hip_runtime_wrapper.h
===
--- clang/lib/Headers/__clang_hip_runtime_wrapper.h
+++ clang/lib/Headers/__clang_hip_runtime_wrapper.h
@@ -51,6 +51,23 @@
   #define nullptr NULL;
 #endif
 
+#ifdef __cplusplus
+extern "C" {
+  __attribute__((__visibility__("default")))
+  __attribute__((weak))
+  __attribute__((noreturn))
+  __device__ void __cxa_pure_virtual(void) {
+__builtin_trap();
+  }
+  __attribute__((__visibility__("default")))
+  __attribute__((weak))
+  __attribute__((noreturn))
+  __device__ void __cxa_deleted_virtual(void) {
+__builtin_trap();
+  }
+}
+#endif //__cplusplus
+
 #if __HIP_ENABLE_DEVICE_MALLOC__
 extern "C" __device__ void *__hip_malloc(size_t __size);
 extern "C" __device__ void *__hip_free(void *__ptr);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 186f2ac - [HIP] Add support functions for C++ polymorphic types

2021-06-21 Thread Yaxun Liu via cfe-commits

Author: Yaxun (Sam) Liu
Date: 2021-06-21T11:41:07-04:00
New Revision: 186f2ac612ad3cd551dee649e3097f4284774ba0

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

LOG: [HIP] Add support functions for C++ polymorphic types

Add runtime functions to detect invalid calls to pure or deleted virtual
functions.

Patch by: Siu Chi Chan

Reviewed by: Yaxun Liu

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

Added: 


Modified: 
clang/lib/Headers/__clang_hip_runtime_wrapper.h
clang/test/Headers/hip-header.hip

Removed: 




diff  --git a/clang/lib/Headers/__clang_hip_runtime_wrapper.h 
b/clang/lib/Headers/__clang_hip_runtime_wrapper.h
index 58f148f9a2680..c557796c8fa0a 100644
--- a/clang/lib/Headers/__clang_hip_runtime_wrapper.h
+++ b/clang/lib/Headers/__clang_hip_runtime_wrapper.h
@@ -51,6 +51,23 @@ typedef __SIZE_TYPE__ size_t;
   #define nullptr NULL;
 #endif
 
+#ifdef __cplusplus
+extern "C" {
+  __attribute__((__visibility__("default")))
+  __attribute__((weak))
+  __attribute__((noreturn))
+  __device__ void __cxa_pure_virtual(void) {
+__builtin_trap();
+  }
+  __attribute__((__visibility__("default")))
+  __attribute__((weak))
+  __attribute__((noreturn))
+  __device__ void __cxa_deleted_virtual(void) {
+__builtin_trap();
+  }
+}
+#endif //__cplusplus
+
 #if __HIP_ENABLE_DEVICE_MALLOC__
 extern "C" __device__ void *__hip_malloc(size_t __size);
 extern "C" __device__ void *__hip_free(void *__ptr);

diff  --git a/clang/test/Headers/hip-header.hip 
b/clang/test/Headers/hip-header.hip
index 323138613055f..5bba1de2ce6c4 100644
--- a/clang/test/Headers/hip-header.hip
+++ b/clang/test/Headers/hip-header.hip
@@ -14,6 +14,29 @@
 
 // expected-no-diagnostics
 
+// Check support for pure and deleted virtual functions
+struct base {
+  __host__
+  __device__
+  virtual void pv() = 0;
+  __host__
+  __device__
+  virtual void dv() = delete;
+};
+struct derived:base {
+  __host__
+  __device__
+  virtual void pv() override {};
+};
+__device__ void test_vf() {
+derived d;
+}
+// CHECK: @_ZTV7derived = linkonce_odr unnamed_addr addrspace(1) constant { [4 
x i8*] } { [4 x i8*] [i8* null, i8* null, i8* bitcast (void (%struct.derived*)* 
@_ZN7derived2pvEv to i8*), i8* bitcast (void ()* @__cxa_deleted_virtual to 
i8*)] }, comdat, align 8
+// CHECK: @_ZTV4base = linkonce_odr unnamed_addr addrspace(1) constant { [4 x 
i8*] } { [4 x i8*] [i8* null, i8* null, i8* bitcast (void ()* 
@__cxa_pure_virtual to i8*), i8* bitcast (void ()* @__cxa_deleted_virtual to 
i8*)] }, comdat, align 8
+
+// CHECK: define{{.*}}void @__cxa_pure_virtual()
+// CHECK: define{{.*}}void @__cxa_deleted_virtual()
+
 struct Number {
   __device__ Number(float _x) : x(_x) {}
   float x;



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


[PATCH] D103702: [AArch64][SVE] Wire up vscale_range attribute to SVE min/max vector queries

2021-06-21 Thread Matt D. via Phabricator via cfe-commits
Matt added inline comments.



Comment at: llvm/lib/Target/AArch64/AArch64TargetMachine.cpp:161
 EnableBranchTargets("aarch64-enable-branch-targets", cl::Hidden,
 cl::desc("Enable the AAcrh64 branch target pass"),
 cl::init(true));

Just noticed a small typo: s/AAcrh64/AArch64/


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103702

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


[PATCH] D103911: [OpenCL] Add support of __opencl_c_images feature macro

2021-06-21 Thread Anton Zabaznov via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGa42739055835: [OpenCL] Add support of __opencl_c_images 
feature macro (authored by azabaznov).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103911

Files:
  clang/lib/Sema/SemaType.cpp
  clang/test/SemaOpenCL/unsupported-image.cl

Index: clang/test/SemaOpenCL/unsupported-image.cl
===
--- /dev/null
+++ clang/test/SemaOpenCL/unsupported-image.cl
@@ -0,0 +1,61 @@
+// RUN: %clang_cc1 -triple spir-unknown-unknown -verify -cl-std=CL3.0 -cl-ext=-__opencl_c_images %s
+// RUN: %clang_cc1 -triple spir-unknown-unknown -verify -cl-std=CL3.0 -cl-ext=+__opencl_c_images %s
+
+#ifdef __opencl_c_images
+//expected-no-diagnostics
+#endif
+
+void test1(image1d_t i) {}
+#if !defined(__opencl_c_images)
+// expected-error@-2{{use of type '__read_only image1d_t' requires __opencl_c_images support}}
+#endif
+
+void test2(image2d_t i) {}
+#if !defined(__opencl_c_images)
+// expected-error@-2{{use of type '__read_only image2d_t' requires __opencl_c_images support}}
+#endif
+
+void test3(image1d_array_t i) {}
+#if !defined(__opencl_c_images)
+// expected-error@-2{{use of type '__read_only image1d_array_t' requires __opencl_c_images support}}
+#endif
+
+void test4(image2d_array_t i) {}
+#if !defined(__opencl_c_images)
+// expected-error@-2{{use of type '__read_only image2d_array_t' requires __opencl_c_images support}}
+#endif
+
+void test5(image2d_depth_t i) {}
+#if !defined(__opencl_c_images)
+// expected-error@-2{{use of type '__read_only image2d_depth_t' requires __opencl_c_images support}}
+#endif
+
+void test6(image1d_buffer_t i) {}
+#if !defined(__opencl_c_images)
+// expected-error@-2{{use of type '__read_only image1d_buffer_t' requires __opencl_c_images support}}
+#endif
+
+void test7(image2d_msaa_t i) {}
+#if !defined(__opencl_c_images)
+// expected-error@-2{{use of type '__read_only image2d_msaa_t' requires __opencl_c_images support}}
+#endif
+
+void test8(image2d_array_msaa_t i) {}
+#if !defined(__opencl_c_images)
+// expected-error@-2{{use of type '__read_only image2d_array_msaa_t' requires __opencl_c_images support}}
+#endif
+
+void test9(image2d_msaa_depth_t i) {}
+#if !defined(__opencl_c_images)
+// expected-error@-2{{use of type '__read_only image2d_msaa_depth_t' requires __opencl_c_images support}}
+#endif
+
+void test10(image2d_array_msaa_depth_t i) {}
+#if !defined(__opencl_c_images)
+// expected-error@-2{{use of type '__read_only image2d_array_msaa_depth_t' requires __opencl_c_images support}}
+#endif
+
+void test11(sampler_t s) {}
+#if !defined(__opencl_c_images)
+// expected-error@-2{{use of type 'sampler_t' requires __opencl_c_images support}}
+#endif
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -1721,11 +1721,25 @@
   if (Result->containsErrors())
 declarator.setInvalidType();
 
-  if (S.getLangOpts().OpenCL && Result->isOCLImage3dWOType() &&
-  !S.getOpenCLOptions().isSupported("cl_khr_3d_image_writes", S.getLangOpts())) {
-S.Diag(DS.getTypeSpecTypeLoc(), diag::err_opencl_requires_extension)
-<< 0 << Result << "cl_khr_3d_image_writes";
-declarator.setInvalidType();
+  if (S.getLangOpts().OpenCL) {
+const auto &OpenCLOptions = S.getOpenCLOptions();
+StringRef OptName;
+// OpenCL C v3.0 s6.3.3 - OpenCL image types require __opencl_c_images
+// support
+if ((Result->isImageType() || Result->isSamplerT()) &&
+(S.getLangOpts().OpenCLVersion >= 300 &&
+ !OpenCLOptions.isSupported("__opencl_c_images", S.getLangOpts(
+  OptName = "__opencl_c_images";
+else if (Result->isOCLImage3dWOType() &&
+ !OpenCLOptions.isSupported("cl_khr_3d_image_writes",
+S.getLangOpts()))
+  OptName = "cl_khr_3d_image_writes";
+
+if (!OptName.empty()) {
+  S.Diag(DS.getTypeSpecTypeLoc(), diag::err_opencl_requires_extension)
+  << 0 << Result << OptName;
+  declarator.setInvalidType();
+}
   }
 
   bool IsFixedPointType = DS.getTypeSpecType() == DeclSpec::TST_accum ||
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] a427390 - [OpenCL] Add support of __opencl_c_images feature macro

2021-06-21 Thread Anton Zabaznov via cfe-commits

Author: Anton Zabaznov
Date: 2021-06-21T18:24:07+03:00
New Revision: a4273905583559b613e1f23336978007af5849be

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

LOG: [OpenCL] Add support of __opencl_c_images feature macro

Reviewed By: svenvh

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

Added: 
clang/test/SemaOpenCL/unsupported-image.cl

Modified: 
clang/lib/Sema/SemaType.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaType.cpp b/clang/lib/Sema/SemaType.cpp
index b0ed636665012..2434554ba4652 100644
--- a/clang/lib/Sema/SemaType.cpp
+++ b/clang/lib/Sema/SemaType.cpp
@@ -1721,11 +1721,25 @@ static QualType 
ConvertDeclSpecToType(TypeProcessingState &state) {
   if (Result->containsErrors())
 declarator.setInvalidType();
 
-  if (S.getLangOpts().OpenCL && Result->isOCLImage3dWOType() &&
-  !S.getOpenCLOptions().isSupported("cl_khr_3d_image_writes", 
S.getLangOpts())) {
-S.Diag(DS.getTypeSpecTypeLoc(), diag::err_opencl_requires_extension)
-<< 0 << Result << "cl_khr_3d_image_writes";
-declarator.setInvalidType();
+  if (S.getLangOpts().OpenCL) {
+const auto &OpenCLOptions = S.getOpenCLOptions();
+StringRef OptName;
+// OpenCL C v3.0 s6.3.3 - OpenCL image types require __opencl_c_images
+// support
+if ((Result->isImageType() || Result->isSamplerT()) &&
+(S.getLangOpts().OpenCLVersion >= 300 &&
+ !OpenCLOptions.isSupported("__opencl_c_images", S.getLangOpts(
+  OptName = "__opencl_c_images";
+else if (Result->isOCLImage3dWOType() &&
+ !OpenCLOptions.isSupported("cl_khr_3d_image_writes",
+S.getLangOpts()))
+  OptName = "cl_khr_3d_image_writes";
+
+if (!OptName.empty()) {
+  S.Diag(DS.getTypeSpecTypeLoc(), diag::err_opencl_requires_extension)
+  << 0 << Result << OptName;
+  declarator.setInvalidType();
+}
   }
 
   bool IsFixedPointType = DS.getTypeSpecType() == DeclSpec::TST_accum ||

diff  --git a/clang/test/SemaOpenCL/unsupported-image.cl 
b/clang/test/SemaOpenCL/unsupported-image.cl
new file mode 100644
index 0..3aed9c1f13199
--- /dev/null
+++ b/clang/test/SemaOpenCL/unsupported-image.cl
@@ -0,0 +1,61 @@
+// RUN: %clang_cc1 -triple spir-unknown-unknown -verify -cl-std=CL3.0 
-cl-ext=-__opencl_c_images %s
+// RUN: %clang_cc1 -triple spir-unknown-unknown -verify -cl-std=CL3.0 
-cl-ext=+__opencl_c_images %s
+
+#ifdef __opencl_c_images
+//expected-no-diagnostics
+#endif
+
+void test1(image1d_t i) {}
+#if !defined(__opencl_c_images)
+// expected-error@-2{{use of type '__read_only image1d_t' requires 
__opencl_c_images support}}
+#endif
+
+void test2(image2d_t i) {}
+#if !defined(__opencl_c_images)
+// expected-error@-2{{use of type '__read_only image2d_t' requires 
__opencl_c_images support}}
+#endif
+
+void test3(image1d_array_t i) {}
+#if !defined(__opencl_c_images)
+// expected-error@-2{{use of type '__read_only image1d_array_t' requires 
__opencl_c_images support}}
+#endif
+
+void test4(image2d_array_t i) {}
+#if !defined(__opencl_c_images)
+// expected-error@-2{{use of type '__read_only image2d_array_t' requires 
__opencl_c_images support}}
+#endif
+
+void test5(image2d_depth_t i) {}
+#if !defined(__opencl_c_images)
+// expected-error@-2{{use of type '__read_only image2d_depth_t' requires 
__opencl_c_images support}}
+#endif
+
+void test6(image1d_buffer_t i) {}
+#if !defined(__opencl_c_images)
+// expected-error@-2{{use of type '__read_only image1d_buffer_t' requires 
__opencl_c_images support}}
+#endif
+
+void test7(image2d_msaa_t i) {}
+#if !defined(__opencl_c_images)
+// expected-error@-2{{use of type '__read_only image2d_msaa_t' requires 
__opencl_c_images support}}
+#endif
+
+void test8(image2d_array_msaa_t i) {}
+#if !defined(__opencl_c_images)
+// expected-error@-2{{use of type '__read_only image2d_array_msaa_t' requires 
__opencl_c_images support}}
+#endif
+
+void test9(image2d_msaa_depth_t i) {}
+#if !defined(__opencl_c_images)
+// expected-error@-2{{use of type '__read_only image2d_msaa_depth_t' requires 
__opencl_c_images support}}
+#endif
+
+void test10(image2d_array_msaa_depth_t i) {}
+#if !defined(__opencl_c_images)
+// expected-error@-2{{use of type '__read_only image2d_array_msaa_depth_t' 
requires __opencl_c_images support}}
+#endif
+
+void test11(sampler_t s) {}
+#if !defined(__opencl_c_images)
+// expected-error@-2{{use of type 'sampler_t' requires __opencl_c_images 
support}}
+#endif



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


[clang] 5958dc7 - Try to fix clang/test/Driver/cl-include.c failure

2021-06-21 Thread Hans Wennborg via cfe-commits

Author: Hans Wennborg
Date: 2021-06-21T17:19:00+02:00
New Revision: 5958dc75ced482228ae4489df1eb5e255e04e5eb

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

LOG: Try to fix clang/test/Driver/cl-include.c failure

Somewhat speculative. Example failures:
https://lab.llvm.org/buildbot/#/builders/5/builds/8857/steps/9/logs/stdio
https://lab.llvm.org/buildbot/#/builders/123/builds/4621/steps/8/logs/stdio

Added: 


Modified: 
clang/lib/Driver/ToolChains/MSVC.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/MSVC.cpp 
b/clang/lib/Driver/ToolChains/MSVC.cpp
index 18543f313b2f..98cf0fff49b2 100644
--- a/clang/lib/Driver/ToolChains/MSVC.cpp
+++ b/clang/lib/Driver/ToolChains/MSVC.cpp
@@ -1244,8 +1244,8 @@ void MSVCToolChain::AddClangSystemIncludeArgs(const 
ArgList &DriverArgs,
 addSystemInclude(DriverArgs, CC1Args, Path);
 
   auto AddSystemIncludesFromEnv = [&](StringRef Var) -> bool {
-SmallVector Dirs;
 if (auto Val = llvm::sys::Process::GetEnv(Var)) {
+  SmallVector Dirs;
   StringRef(*Val).split(Dirs, ";", /*MaxSplit=*/-1, /*KeepEmpty=*/false);
   if (!Dirs.empty()) {
 addSystemIncludes(DriverArgs, CC1Args, Dirs);
@@ -1268,8 +1268,9 @@ void MSVCToolChain::AddClangSystemIncludeArgs(const 
ArgList &DriverArgs,
   // paths set by vcvarsall.bat. Skip if the user expressly set a vctoolsdir.
   if (!DriverArgs.getLastArg(options::OPT__SLASH_vctoolsdir,
  options::OPT__SLASH_winsysroot)) {
-if (AddSystemIncludesFromEnv("INCLUDE") |
-AddSystemIncludesFromEnv("EXTERNAL_INCLUDE"))
+bool Found = AddSystemIncludesFromEnv("INCLUDE");
+Found |= AddSystemIncludesFromEnv("EXTERNAL_INCLUDE");
+if (Found)
   return;
   }
 
@@ -1292,7 +1293,7 @@ void MSVCToolChain::AddClangSystemIncludeArgs(const 
ArgList &DriverArgs,
 }
 
 std::string WindowsSDKDir;
-int major;
+int major = 0;
 std::string windowsSDKIncludeVersion;
 std::string windowsSDKLibVersion;
 if (getWindowsSDKDir(getVFS(), DriverArgs, WindowsSDKDir, major,



___
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

2021-06-21 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

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


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] D104261: Thread safety analysis: Always warn when dropping locks on back edges

2021-06-21 Thread Aaron Puchert via Phabricator via cfe-commits
aaronpuchert added inline comments.



Comment at: clang/lib/Analysis/ThreadSafety.cpp:2227-2228
 /// \param LEK2 The error message to report if a mutex is missing from Lset2
 void ThreadSafetyAnalyzer::intersectAndWarn(FactSet &FSet1,
 const FactSet &FSet2,
 SourceLocation JoinLoc,

aaronpuchert wrote:
> Presumably we should call these `EntrySet` and `ExitSet` instead? The second 
> parameter is always the exit set of an existing block, the first parameter 
> the entry set of a (sometimes new) block.
Did this in a separate change D104649, because it would obfuscate the changes 
here. Nevertheless, it's probably a good idea to look at both changes together.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104261

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


[PATCH] D104649: Thread safety analysis: Rename parameters of ThreadSafetyAnalyzer::intersectAndWarn (NFC)

2021-06-21 Thread Aaron Puchert via Phabricator via cfe-commits
aaronpuchert created this revision.
aaronpuchert added reviewers: aaron.ballman, delesley.
Herald added subscribers: manas, steakhal, ASDenysPetrov, dkrupp, donat.nagy, 
Szelethus, a.sidorin, baloghadamsoftware.
aaronpuchert requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

In D104261  we made the parameters' meaning 
slightly more specific, this
changes their names accordingly. In all uses we're building a new lock
set by intersecting existing locksets. The first (modifiable) argument
is the new lock set being built, the second (non-modifiable) argument is
the exit set of a preceding block.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104649

Files:
  clang/lib/Analysis/ThreadSafety.cpp


Index: clang/lib/Analysis/ThreadSafety.cpp
===
--- clang/lib/Analysis/ThreadSafety.cpp
+++ clang/lib/Analysis/ThreadSafety.cpp
@@ -1052,13 +1052,13 @@
 
   bool join(const FactEntry &a, const FactEntry &b);
 
-  void intersectAndWarn(FactSet &FSet1, const FactSet &FSet2,
-SourceLocation JoinLoc, LockErrorKind LEK1,
-LockErrorKind LEK2);
+  void intersectAndWarn(FactSet &EntrySet, const FactSet &ExitSet,
+SourceLocation JoinLoc, LockErrorKind EntryLEK,
+LockErrorKind ExitLEK);
 
-  void intersectAndWarn(FactSet &FSet1, const FactSet &FSet2,
-SourceLocation JoinLoc, LockErrorKind LEK1) {
-intersectAndWarn(FSet1, FSet2, JoinLoc, LEK1, LEK1);
+  void intersectAndWarn(FactSet &EntrySet, const FactSet &ExitSet,
+SourceLocation JoinLoc, LockErrorKind LEK) {
+intersectAndWarn(EntrySet, ExitSet, JoinLoc, LEK, LEK);
   }
 
   void runAnalysis(AnalysisDeclContext &AC);
@@ -2219,43 +2219,44 @@
 /// are the same. In the event of a difference, we use the intersection of 
these
 /// two locksets at the start of D.
 ///
-/// \param FSet1 The first lockset.
-/// \param FSet2 The second lockset.
+/// \param EntrySet A lockset for entry into a (possibly new) block.
+/// \param ExitSet The lockset on exiting a preceding block.
 /// \param JoinLoc The location of the join point for error reporting
-/// \param LEK1 The error message to report if a mutex is missing from LSet1
-/// \param LEK2 The error message to report if a mutex is missing from Lset2
-void ThreadSafetyAnalyzer::intersectAndWarn(FactSet &FSet1,
-const FactSet &FSet2,
+/// \param EntryLEK The warning if a mutex is missing from \p EntrySet.
+/// \param ExitLEK The warning if a mutex is missing from \p ExitSet.
+void ThreadSafetyAnalyzer::intersectAndWarn(FactSet &EntrySet,
+const FactSet &ExitSet,
 SourceLocation JoinLoc,
-LockErrorKind LEK1,
-LockErrorKind LEK2) {
-  FactSet FSet1Orig = FSet1;
-
-  // Find locks in FSet2 that conflict or are not in FSet1, and warn.
-  for (const auto &Fact : FSet2) {
-const FactEntry &LDat2 = FactMan[Fact];
-
-FactSet::iterator Iter1 = FSet1.findLockIter(FactMan, LDat2);
-if (Iter1 != FSet1.end()) {
-  if (join(FactMan[*Iter1], LDat2) && LEK1 == LEK_LockedSomePredecessors)
-*Iter1 = Fact;
-} else if (!LDat2.managed()) {
-  LDat2.handleRemovalFromIntersection(FSet2, FactMan, JoinLoc, LEK1,
-  Handler);
+LockErrorKind EntryLEK,
+LockErrorKind ExitLEK) {
+  FactSet EntrySetOrig = EntrySet;
+
+  // Find locks in ExitSet that conflict or are not in EntrySet, and warn.
+  for (const auto &Fact : ExitSet) {
+const FactEntry &ExitFact = FactMan[Fact];
+
+FactSet::iterator EntryIt = EntrySet.findLockIter(FactMan, ExitFact);
+if (EntryIt != EntrySet.end()) {
+  if (join(FactMan[*EntryIt], ExitFact) &&
+  EntryLEK == LEK_LockedSomePredecessors)
+*EntryIt = Fact;
+} else if (!ExitFact.managed()) {
+  ExitFact.handleRemovalFromIntersection(ExitSet, FactMan, JoinLoc,
+ EntryLEK, Handler);
 }
   }
 
-  // Find locks in FSet1 that are not in FSet2, and remove them.
-  for (const auto &Fact : FSet1Orig) {
-const FactEntry *LDat1 = &FactMan[Fact];
-const FactEntry *LDat2 = FSet2.findLock(FactMan, *LDat1);
+  // Find locks in EntrySet that are not in ExitSet, and remove them.
+  for (const auto &Fact : EntrySetOrig) {
+const FactEntry *EntryFact = &FactMan[Fact];
+const FactEntry *ExitFact = ExitSet.findLock(FactMan, *EntryFact);
 
-if (!LDat2) {
-  if (!LDat1->managed() || LEK1 == LEK_LockedSomeLoopIterations)
-LDat1->handleRemovalFromIntersection(

[PATCH] D93373: [Flang][Openmp] Upgrade TASKGROUP construct to 5.0.

2021-06-21 Thread Chirag Khandelwal via Phabricator via cfe-commits
AMDChirag updated this revision to Diff 353379.
AMDChirag added a comment.
Herald added a reviewer: sscalpone.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Fixes the clang test cases


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93373

Files:
  clang/test/OpenMP/master_taskloop_simd_ast_print.cpp
  clang/test/OpenMP/parallel_master_taskloop_simd_ast_print.cpp
  clang/test/OpenMP/taskloop_simd_ast_print.cpp
  flang/lib/Semantics/resolve-directives.cpp
  flang/lib/Semantics/resolve-names.cpp
  flang/test/Semantics/omp-taskgroup01.f90
  llvm/include/llvm/Frontend/OpenMP/OMP.td

Index: llvm/include/llvm/Frontend/OpenMP/OMP.td
===
--- llvm/include/llvm/Frontend/OpenMP/OMP.td
+++ llvm/include/llvm/Frontend/OpenMP/OMP.td
@@ -473,8 +473,8 @@
 }
 def OMP_TaskGroup : Directive<"taskgroup"> {
   let allowedClauses = [
-VersionedClause,
-VersionedClause
+VersionedClause,
+VersionedClause
   ];
 }
 def OMP_Flush : Directive<"flush"> {
Index: flang/test/Semantics/omp-taskgroup01.f90
===
--- /dev/null
+++ flang/test/Semantics/omp-taskgroup01.f90
@@ -0,0 +1,47 @@
+! RUN: %S/test_errors.sh %s %t %flang -fopenmp
+use omp_lib
+  implicit none
+  integer :: xyz, abc
+  real :: reduction_var
+  !$omp parallel num_threads(4)
+!$omp single
+  print *, "The"
+!$omp taskgroup
+  !$omp task
+  print *, "almighty"
+  !$omp end task
+  !$omp task
+  print *, "sun"
+  !$omp end task
+!$omp end taskgroup
+!$omp end single
+  !$omp end parallel
+
+  !$omp parallel private(xyz)
+!$omp taskgroup allocate(xyz)
+  !$omp task
+print *, "The "
+!$omp taskgroup allocate(omp_large_cap_mem_space: abc)
+  !$omp task
+  print *, "almighty sun"
+  !$omp end task
+!$omp end taskgroup
+  !$omp end task
+!$omp end taskgroup
+  !$omp end parallel
+
+  !ERROR: PRIVATE clause is not allowed on the TASKGROUP directive
+  !$omp taskgroup private(abc)
+  !$omp end taskgroup
+
+  !$omp parallel
+!$omp task
+  !$omp taskgroup task_reduction(+ : reduction_var)
+print *, "The "
+!$omp taskgroup task_reduction(.or. : reduction_var) task_reduction(.and. : reduction_var)
+  print *, "almighty sun"
+!$omp end taskgroup
+  !$omp end taskgroup
+!$omp end task
+  !$omp end parallel
+end program
Index: flang/lib/Semantics/resolve-names.cpp
===
--- flang/lib/Semantics/resolve-names.cpp
+++ flang/lib/Semantics/resolve-names.cpp
@@ -1288,6 +1288,7 @@
   case llvm::omp::Directive::OMPD_target_data:
   case llvm::omp::Directive::OMPD_master:
   case llvm::omp::Directive::OMPD_ordered:
+  case llvm::omp::Directive::OMPD_taskgroup:
 return false;
   default:
 return true;
Index: flang/lib/Semantics/resolve-directives.cpp
===
--- flang/lib/Semantics/resolve-directives.cpp
+++ flang/lib/Semantics/resolve-directives.cpp
@@ -1069,12 +1069,12 @@
   case llvm::omp::Directive::OMPD_target:
   case llvm::omp::Directive::OMPD_target_data:
   case llvm::omp::Directive::OMPD_task:
+  case llvm::omp::Directive::OMPD_taskgroup:
   case llvm::omp::Directive::OMPD_teams:
   case llvm::omp::Directive::OMPD_workshare:
   case llvm::omp::Directive::OMPD_parallel_workshare:
   case llvm::omp::Directive::OMPD_target_teams:
   case llvm::omp::Directive::OMPD_target_parallel:
-  case llvm::omp::Directive::OMPD_taskgroup:
 PushContext(beginDir.source, beginDir.v);
 break;
   default:
@@ -1095,6 +1095,7 @@
   case llvm::omp::Directive::OMPD_single:
   case llvm::omp::Directive::OMPD_target:
   case llvm::omp::Directive::OMPD_task:
+  case llvm::omp::Directive::OMPD_taskgroup:
   case llvm::omp::Directive::OMPD_teams:
   case llvm::omp::Directive::OMPD_parallel_workshare:
   case llvm::omp::Directive::OMPD_target_teams:
Index: clang/test/OpenMP/taskloop_simd_ast_print.cpp
===
--- clang/test/OpenMP/taskloop_simd_ast_print.cpp
+++ clang/test/OpenMP/taskloop_simd_ast_print.cpp
@@ -1,13 +1,13 @@
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-version=45 -ast-print %s | FileCheck %s --check-prefix CHECK --check-prefix OMP45
-// RUN: %clang_cc1 -fopenmp -fopenmp-version=45 -x c++ -std=c++11 -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-version=45 -std=c++11 -include-pch %t -fsyntax-only -verify %s -ast-print | FileCheck %s --check-prefix CHECK --check-prefix OMP45
+// RUN: %clang_cc1 -verify -fopenmp -fopenmp-version=50 -DOMP5 -ast-print %s | FileCheck %s --check-prefix CHECK --check-prefix OMP50
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -DOMP5 -x c++ -std=c++11 -emit-pch -o %t %s

[PATCH] D104647: [analyzer] Support SVal::getType for pointer-to-member values

2021-06-21 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko added a comment.

This one is a bit more invasive, so I decided to put it into a separate patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104647

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


[PATCH] D104647: [analyzer] Support SVal::getType for pointer-to-member values

2021-06-21 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko created this revision.
vsavchenko added reviewers: NoQ, xazax.hun, martong, steakhal, Szelethus, 
ASDenysPetrov, manas, RedDocMD.
Herald added subscribers: dkrupp, donat.nagy, mikhail.ramalho, a.sidorin, 
rnkovacs, szepet, baloghadamsoftware.
vsavchenko requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104647

Files:
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/BasicValueFactory.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/SValBuilder.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/SVals.h
  clang/lib/StaticAnalyzer/Core/BasicValueFactory.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
  clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
  clang/lib/StaticAnalyzer/Core/SVals.cpp
  clang/unittests/StaticAnalyzer/SValTest.cpp

Index: clang/unittests/StaticAnalyzer/SValTest.cpp
===
--- clang/unittests/StaticAnalyzer/SValTest.cpp
+++ clang/unittests/StaticAnalyzer/SValTest.cpp
@@ -346,6 +346,41 @@
   EXPECT_EQ(Context.VoidPtrTy, *B.getType(Context));
 }
 
+SVAL_TEST(GetMemberPtrType, R"(
+struct A {
+  int a;
+  struct {
+int b;
+  };
+};
+void foo(int A::*x) {
+  int A::*a = &A::a;
+  int A::*b = &A::b;
+  int A::*c = x;
+}
+)") {
+  SVal A = getByName("a");
+  ASSERT_TRUE(A.getType(Context).hasValue());
+  const auto *AMemberPtrTy = dyn_cast(*A.getType(Context));
+  ASSERT_NE(AMemberPtrTy, nullptr);
+  EXPECT_EQ(Context.IntTy, AMemberPtrTy->getPointeeType());
+  const auto *ARecordType = dyn_cast(AMemberPtrTy->getClass());
+  ASSERT_NE(ARecordType, nullptr);
+  EXPECT_EQ("A", ARecordType->getDecl()->getName());
+
+  SVal B = getByName("b");
+  ASSERT_TRUE(B.getType(Context).hasValue());
+  const auto *BMemberPtrTy = dyn_cast(*B.getType(Context));
+  ASSERT_NE(BMemberPtrTy, nullptr);
+  EXPECT_EQ(Context.IntTy, BMemberPtrTy->getPointeeType());
+  const auto *BRecordType = dyn_cast(BMemberPtrTy->getClass());
+  ASSERT_NE(BRecordType, nullptr);
+  EXPECT_EQ("A", BRecordType->getDecl()->getName());
+
+  SVal C = getByName("c");
+  EXPECT_TRUE(C.isUnknown());
+}
+
 } // namespace
 } // namespace ento
 } // namespace clang
Index: clang/lib/StaticAnalyzer/Core/SVals.cpp
===
--- clang/lib/StaticAnalyzer/Core/SVals.cpp
+++ clang/lib/StaticAnalyzer/Core/SVals.cpp
@@ -180,6 +180,14 @@
   Optional VisitNonLocSymbolVal(nonloc::SymbolVal SV) {
 return Visit(SV.getSymbol());
   }
+  Optional VisitNonLocPointerToMember(nonloc::PointerToMember PTM) {
+QualType T = PTM.getType();
+
+if (T.isNull())
+  return None;
+
+return T;
+  }
   Optional VisitSymbolicRegion(const SymbolicRegion *SR) {
 return Visit(SR->getSymbol());
   }
@@ -209,21 +217,21 @@
 }
 
 bool nonloc::PointerToMember::isNullMemberPointer() const {
-  return getPTMData().isNull();
+  return getPTMData() == nullptr;
 }
 
 const NamedDecl *nonloc::PointerToMember::getDecl() const {
-  const auto PTMD = this->getPTMData();
-  if (PTMD.isNull())
+  if (!getPTMData())
 return nullptr;
 
-  const NamedDecl *ND = nullptr;
-  if (PTMD.is())
-ND = PTMD.get();
-  else
-ND = PTMD.get()->getDeclaratorDecl();
+  return getPTMData()->getDeclaratorDecl();
+}
+
+QualType nonloc::PointerToMember::getType() const {
+  if (!getPTMData())
+return {};
 
-  return ND;
+  return getPTMData()->getType();
 }
 
 //===--===//
@@ -239,17 +247,11 @@
 }
 
 nonloc::PointerToMember::iterator nonloc::PointerToMember::begin() const {
-  const PTMDataType PTMD = getPTMData();
-  if (PTMD.is())
-return {};
-  return PTMD.get()->begin();
+  return getPTMData()->begin();
 }
 
 nonloc::PointerToMember::iterator nonloc::PointerToMember::end() const {
-  const PTMDataType PTMD = getPTMData();
-  if (PTMD.is())
-return {};
-  return PTMD.get()->end();
+  return getPTMData()->end();
 }
 
 //===--===//
Index: clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
===
--- clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
+++ clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
@@ -236,7 +236,7 @@
   return nonloc::SymbolVal(sym);
 }
 
-DefinedSVal SValBuilder::getMemberPointer(const NamedDecl *ND) {
+DefinedSVal SValBuilder::getMemberPointer(const NamedDecl *ND, QualType T) {
   assert(!ND || isa(ND) || isa(ND) ||
  isa(ND));
 
@@ -250,7 +250,8 @@
   return getFunctionPointer(MD);
   }
 
-  return nonloc::PointerToMember(ND);
+  return nonloc::PointerToMember(
+  getBasicValueFactory().getPointerToMemberData(ND, T));
 }
 
 DefinedSVal SValBuilder::getFunctionPointer(const FunctionDecl *func) {
Index: clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp

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

2021-06-21 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko updated this revision to Diff 353371.
vsavchenko added a comment.

Support ConcreteInt, LocAsInteger, and GotoLabel


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104550

Files:
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/BasicValueFactory.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/SVals.h
  clang/lib/StaticAnalyzer/Core/SVals.cpp
  clang/unittests/StaticAnalyzer/CMakeLists.txt
  clang/unittests/StaticAnalyzer/SValTest.cpp

Index: clang/unittests/StaticAnalyzer/SValTest.cpp
===
--- /dev/null
+++ clang/unittests/StaticAnalyzer/SValTest.cpp
@@ -0,0 +1,351 @@
+//===- unittests/StaticAnalyzer/SvalTest.cpp --===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "CheckerRegistration.h"
+
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/Decl.h"
+#include "clang/AST/DeclGroup.h"
+#include "clang/AST/RecursiveASTVisitor.h"
+#include "clang/AST/Stmt.h"
+#include "clang/AST/Type.h"
+#include "clang/StaticAnalyzer/Core/Checker.h"
+#include "clang/StaticAnalyzer/Core/CheckerManager.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h"
+#include "clang/StaticAnalyzer/Frontend/AnalysisConsumer.h"
+#include "clang/StaticAnalyzer/Frontend/CheckerRegistry.h"
+#include "clang/Tooling/Tooling.h"
+#include "llvm/ADT/STLExtras.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/Casting.h"
+#include "llvm/Support/raw_ostream.h"
+#include "gtest/gtest.h"
+
+namespace clang {
+
+// getType() tests include whole bunch of type comparisons,
+// so when something is wrong, it's good to have gtest telling us
+// what are those types.
+LLVM_ATTRIBUTE_UNUSED std::ostream &operator<<(std::ostream &OS,
+   const QualType &T) {
+  return OS << T.getAsString();
+}
+
+LLVM_ATTRIBUTE_UNUSED std::ostream &operator<<(std::ostream &OS,
+   const CanQualType &T) {
+  return OS << QualType{T};
+}
+
+namespace ento {
+namespace {
+
+//===--===//
+//   Testing framework implementation
+//===--===//
+
+/// A simple map from variable names to symbolic values used to init them.
+using SVals = llvm::StringMap;
+
+/// SValCollector is the barebone of all tests.
+///
+/// It is implemented as a checker and reacts to binds, so we find
+/// symbolic values of interest, and to end analysis, where we actually
+/// can test whatever we gathered.
+class SValCollector : public Checker {
+public:
+  void checkBind(SVal Loc, SVal Val, const Stmt *S, CheckerContext &C) const {
+// Skip instantly if we finished testing.
+// Also, we care only for binds happening in variable initializations.
+if (Tested || !isa(S))
+  return;
+
+if (const auto *VR = llvm::dyn_cast_or_null(Loc.getAsRegion())) {
+  CollectedSVals[VR->getDescriptiveName(false)] = Val;
+}
+  }
+
+  void checkEndAnalysis(ExplodedGraph &G, BugReporter &B,
+ExprEngine &Engine) const {
+if (!Tested) {
+  test(Engine, Engine.getContext());
+  Tested = true;
+  CollectedSVals.clear();
+}
+  }
+
+  /// Helper function for tests to access bound symbolic values.
+  SVal getByName(StringRef Name) const { return CollectedSVals[Name]; }
+
+private:
+  /// Entry point for tests.
+  virtual void test(ExprEngine &Engine, const ASTContext &Context) const = 0;
+
+  mutable bool Tested = false;
+  mutable SVals CollectedSVals;
+};
+
+// SVAL_TEST is a combined way of providing a short code snippet and
+// to test some programmatic predicates on symbolic values produced by the
+// engine for the actual code.
+//
+// Each test has a NAME.  One can think of it as a name for normal gtests.
+//
+// Each test should provide a CODE snippet.  Code snippets might contain any
+// valid C/C++, but have ONLY ONE defined function.  There are no requirements
+// about function's name or parameters.  It can even be a class method.  The
+// body of the function must contain a set of variable declarations.  Each
+// variable declaration gets bound to a symbolic value, so for the following
+// example:
+//
+// int x = ;
+//
+// `x` will be bound to whatever symbolic value the engine produced for .
+// LIVENESS and REASSIGNMENTS don't affect this binding.
+//
+// During the test the actual values can be accessed via `getByName` function,
+// and, for the `x`-bound value,

[PATCH] D103702: [AArch64][SVE] Wire up vscale_range attribute to SVE min/max vector queries

2021-06-21 Thread Bradley Smith via Phabricator via cfe-commits
bsmith added a comment.

Yup, just committed a fix in ed31ff9c7a9e538ead1fa4feecf09987998621b4 
, sorry 
for the noise.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103702

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


[PATCH] D103702: [AArch64][SVE] Wire up vscale_range attribute to SVE min/max vector queries

2021-06-21 Thread Phil Camp via Phabricator via cfe-commits
FlameTop added a comment.

This commit is failing the test on non-arm targets (e.g. 
https://lab.llvm.org/buildbot/#/builders/139/builds/5932). I think the test 
needs a 'requires' line for aarch64.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103702

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


[PATCH] D104643: [AArch64][SVE] Add missing target require to test

2021-06-21 Thread Bradley Smith 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 rGed31ff9c7a9e: [AArch64][SVE] Add missing target require to 
test (authored by bsmith).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104643

Files:
  clang/test/CodeGen/aarch64-sve-vector-bits-codegen.c


Index: clang/test/CodeGen/aarch64-sve-vector-bits-codegen.c
===
--- clang/test/CodeGen/aarch64-sve-vector-bits-codegen.c
+++ clang/test/CodeGen/aarch64-sve-vector-bits-codegen.c
@@ -2,6 +2,7 @@
 // RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve 
-fallow-half-arguments-and-returns -O2 -S -o - %s -msve-vector-bits=512  | 
FileCheck %s --check-prefixes=CHECK,CHECK512
 // RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve 
-fallow-half-arguments-and-returns -O2 -S -o - %s -msve-vector-bits=1024 | 
FileCheck %s --check-prefixes=CHECK,CHECK1024
 // RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve 
-fallow-half-arguments-and-returns -O2 -S -o - %s -msve-vector-bits=2048 | 
FileCheck %s --check-prefixes=CHECK,CHECK2048
+// REQUIRES: aarch64-registered-target
 
 #include 
 


Index: clang/test/CodeGen/aarch64-sve-vector-bits-codegen.c
===
--- clang/test/CodeGen/aarch64-sve-vector-bits-codegen.c
+++ clang/test/CodeGen/aarch64-sve-vector-bits-codegen.c
@@ -2,6 +2,7 @@
 // RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -O2 -S -o - %s -msve-vector-bits=512  | FileCheck %s --check-prefixes=CHECK,CHECK512
 // RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -O2 -S -o - %s -msve-vector-bits=1024 | FileCheck %s --check-prefixes=CHECK,CHECK1024
 // RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -O2 -S -o - %s -msve-vector-bits=2048 | FileCheck %s --check-prefixes=CHECK,CHECK2048
+// REQUIRES: aarch64-registered-target
 
 #include 
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] ed31ff9 - [AArch64][SVE] Add missing target require to test

2021-06-21 Thread Bradley Smith via cfe-commits

Author: Bradley Smith
Date: 2021-06-21T15:36:44+01:00
New Revision: ed31ff9c7a9e538ead1fa4feecf09987998621b4

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

LOG: [AArch64][SVE] Add missing target require to test

Differential revision: https://reviews.llvm.org/D104643

Added: 


Modified: 
clang/test/CodeGen/aarch64-sve-vector-bits-codegen.c

Removed: 




diff  --git a/clang/test/CodeGen/aarch64-sve-vector-bits-codegen.c 
b/clang/test/CodeGen/aarch64-sve-vector-bits-codegen.c
index fbae8c261703..2ef8698d3dda 100644
--- a/clang/test/CodeGen/aarch64-sve-vector-bits-codegen.c
+++ b/clang/test/CodeGen/aarch64-sve-vector-bits-codegen.c
@@ -2,6 +2,7 @@
 // RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve 
-fallow-half-arguments-and-returns -O2 -S -o - %s -msve-vector-bits=512  | 
FileCheck %s --check-prefixes=CHECK,CHECK512
 // RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve 
-fallow-half-arguments-and-returns -O2 -S -o - %s -msve-vector-bits=1024 | 
FileCheck %s --check-prefixes=CHECK,CHECK1024
 // RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve 
-fallow-half-arguments-and-returns -O2 -S -o - %s -msve-vector-bits=2048 | 
FileCheck %s --check-prefixes=CHECK,CHECK2048
+// REQUIRES: aarch64-registered-target
 
 #include 
 



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


[PATCH] D104643: [AArch64][SVE] Add missing target require to test

2021-06-21 Thread Bradley Smith via Phabricator via cfe-commits
bsmith created this revision.
bsmith added a reviewer: peterwaller-arm.
Herald added subscribers: psnobl, kristof.beyls, tschuett.
Herald added a reviewer: efriedma.
bsmith requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104643

Files:
  clang/test/CodeGen/aarch64-sve-vector-bits-codegen.c


Index: clang/test/CodeGen/aarch64-sve-vector-bits-codegen.c
===
--- clang/test/CodeGen/aarch64-sve-vector-bits-codegen.c
+++ clang/test/CodeGen/aarch64-sve-vector-bits-codegen.c
@@ -2,6 +2,7 @@
 // RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve 
-fallow-half-arguments-and-returns -O2 -S -o - %s -msve-vector-bits=512  | 
FileCheck %s --check-prefixes=CHECK,CHECK512
 // RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve 
-fallow-half-arguments-and-returns -O2 -S -o - %s -msve-vector-bits=1024 | 
FileCheck %s --check-prefixes=CHECK,CHECK1024
 // RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve 
-fallow-half-arguments-and-returns -O2 -S -o - %s -msve-vector-bits=2048 | 
FileCheck %s --check-prefixes=CHECK,CHECK2048
+// REQUIRES: aarch64-registered-target
 
 #include 
 


Index: clang/test/CodeGen/aarch64-sve-vector-bits-codegen.c
===
--- clang/test/CodeGen/aarch64-sve-vector-bits-codegen.c
+++ clang/test/CodeGen/aarch64-sve-vector-bits-codegen.c
@@ -2,6 +2,7 @@
 // RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -O2 -S -o - %s -msve-vector-bits=512  | FileCheck %s --check-prefixes=CHECK,CHECK512
 // RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -O2 -S -o - %s -msve-vector-bits=1024 | FileCheck %s --check-prefixes=CHECK,CHECK1024
 // RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -O2 -S -o - %s -msve-vector-bits=2048 | FileCheck %s --check-prefixes=CHECK,CHECK2048
+// REQUIRES: aarch64-registered-target
 
 #include 
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D104044: [clang-format] Fix the issue that empty lines being removed at the beginning of namespace

2021-06-21 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay accepted this revision.
MyDeveloperDay added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104044

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


[PATCH] D104640: [clang][Analyzer] Track null stream argument in alpha.unix.Stream .

2021-06-21 Thread Balázs Kéri via Phabricator via cfe-commits
balazske created this revision.
Herald added subscribers: manas, steakhal, ASDenysPetrov, martong, gamesh411, 
dkrupp, donat.nagy, Szelethus, mikhail.ramalho, a.sidorin, szepet, 
baloghadamsoftware, xazax.hun, whisperity.
Herald added a reviewer: Szelethus.
balazske requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

The checker contains check for passing a NULL stream argument.
This change should make more easy to identify where the passed pointer
becomes NULL.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104640

Files:
  clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
  clang/test/Analysis/stream-note.c

Index: clang/test/Analysis/stream-note.c
===
--- clang/test/Analysis/stream-note.c
+++ clang/test/Analysis/stream-note.c
@@ -77,3 +77,14 @@
   fclose(F1);
   fclose(F2);
 }
+
+void check_track_null() {
+  FILE *F;
+  F = fopen("foo1.c", "r"); // expected-note {{Value assigned to 'F'}} expected-note {{Assuming pointer value is null}}
+  if (F != NULL) {  // expected-note {{Taking false branch}} expected-note {{'F' is equal to NULL}}
+fclose(F);
+return;
+  }
+  fclose(F); // expected-warning {{Stream pointer might be NULL}}
+  // expected-note@-1 {{Stream pointer might be NULL}}
+}
Index: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
@@ -306,7 +306,8 @@
   /// If it can only be NULL a fatal error is emitted and nullptr returned.
   /// Otherwise the return value is a new state where the stream is constrained
   /// to be non-null.
-  ProgramStateRef ensureStreamNonNull(SVal StreamVal, CheckerContext &C,
+  ProgramStateRef ensureStreamNonNull(SVal StreamVal, const Expr *StreamE,
+  CheckerContext &C,
   ProgramStateRef State) const;
 
   /// Check that the stream is the opened state.
@@ -472,7 +473,8 @@
CheckerContext &C) const {
   // Do not allow NULL as passed stream pointer but allow a closed stream.
   ProgramStateRef State = C.getState();
-  State = ensureStreamNonNull(getStreamArg(Desc, Call), C, State);
+  State = ensureStreamNonNull(getStreamArg(Desc, Call),
+  Call.getArgExpr(Desc->StreamArgNo), C, State);
   if (!State)
 return;
 
@@ -549,7 +551,8 @@
  CheckerContext &C) const {
   ProgramStateRef State = C.getState();
   SVal StreamVal = getStreamArg(Desc, Call);
-  State = ensureStreamNonNull(StreamVal, C, State);
+  State = ensureStreamNonNull(StreamVal, Call.getArgExpr(Desc->StreamArgNo), C,
+  State);
   if (!State)
 return;
   State = ensureStreamOpened(StreamVal, C, State);
@@ -573,7 +576,8 @@
   CheckerContext &C) const {
   ProgramStateRef State = C.getState();
   SVal StreamVal = getStreamArg(Desc, Call);
-  State = ensureStreamNonNull(StreamVal, C, State);
+  State = ensureStreamNonNull(StreamVal, Call.getArgExpr(Desc->StreamArgNo), C,
+  State);
   if (!State)
 return;
   State = ensureStreamOpened(StreamVal, C, State);
@@ -671,7 +675,8 @@
  CheckerContext &C) const {
   ProgramStateRef State = C.getState();
   SVal StreamVal = getStreamArg(Desc, Call);
-  State = ensureStreamNonNull(StreamVal, C, State);
+  State = ensureStreamNonNull(StreamVal, Call.getArgExpr(Desc->StreamArgNo), C,
+  State);
   if (!State)
 return;
   State = ensureStreamOpened(StreamVal, C, State);
@@ -790,7 +795,8 @@
CheckerContext &C) const {
   ProgramStateRef State = C.getState();
   SVal StreamVal = getStreamArg(Desc, Call);
-  State = ensureStreamNonNull(StreamVal, C, State);
+  State = ensureStreamNonNull(StreamVal, Call.getArgExpr(Desc->StreamArgNo), C,
+  State);
   if (!State)
 return;
   State = ensureStreamOpened(StreamVal, C, State);
@@ -814,7 +820,8 @@
 }
 
 ProgramStateRef
-StreamChecker::ensureStreamNonNull(SVal StreamVal, CheckerContext &C,
+StreamChecker::ensureStreamNonNull(SVal StreamVal, const Expr *StreamE,
+   CheckerContext &C,
ProgramStateRef State) const {
   auto Stream = StreamVal.getAs();
   if (!Stream)
@@ -827,8 +834,11 @@
 
   if (!StateNotNull && StateNull) {
 if (ExplodedNode *N = C.generateErrorNode(StateNull)) {
-  C.emitReport(std::make_unique(
-  BT_FileNull, "Stream pointer might be NULL.", N));
+  auto R = std::make_unique(
+  BT_FileNull, "Stream pointer might be NULL.", N);
+  if (StreamE)
+bugreporter::trackExpressionValue(N, StreamE, *R);
+  C.em

[PATCH] D104387: [clang-cl] Implement /external:I, /external:env, and EXTERNAL_INCLUDE support (PR36003)

2021-06-21 Thread Hans Wennborg via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG3063a5472266: [clang-cl] Implement /external:I, 
/external:env, and EXTERNAL_INCLUDE support… (authored by hans).

Changed prior to commit:
  https://reviews.llvm.org/D104387?vs=352695&id=353354#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104387

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/MSVC.cpp
  clang/test/Driver/cl-include.c
  clang/test/Driver/cl-options.c

Index: clang/test/Driver/cl-options.c
===
--- clang/test/Driver/cl-options.c
+++ clang/test/Driver/cl-options.c
@@ -38,6 +38,10 @@
 // EP: "-P"
 // EP: "-o" "-"
 
+// RUN: %clang_cl /external:Ipath  -### -- %s 2>&1 | FileCheck -check-prefix=EXTERNAL_I %s
+// RUN: %clang_cl /external:I path -### -- %s 2>&1 | FileCheck -check-prefix=EXTERNAL_I %s
+// EXTERNAL_I: "-isystem" "path"
+
 // RUN: %clang_cl /fp:fast /fp:except -### -- %s 2>&1 | FileCheck -check-prefix=fpexcept %s
 // fpexcept-NOT: -menable-unsafe-fp-math
 
@@ -434,8 +438,6 @@
 // RUN: /experimental:preprocessor \
 // RUN: /exportHeader /headerName:foo \
 // RUN: /external:anglebrackets \
-// RUN: /external:Ipath \
-// RUN: /external:I path \
 // RUN: /external:env:var \
 // RUN: /external:W0 \
 // RUN: /external:W1 \
Index: clang/test/Driver/cl-include.c
===
--- clang/test/Driver/cl-include.c
+++ clang/test/Driver/cl-include.c
@@ -7,19 +7,37 @@
 // RUN: %clang_cl -nobuiltininc -### -- %s 2>&1 | FileCheck %s --check-prefix=NOBUILTIN
 // NOBUILTIN-NOT: "-internal-isystem" "{{.*lib.*clang.*include}}"
 
-// RUN: env INCLUDE=/my/system/inc %clang_cl -### -- %s 2>&1 | FileCheck %s --check-prefix=STDINC
+// RUN: env INCLUDE=/my/system/inc env EXTERNAL_INCLUDE=/my/system/inc2 %clang_cl -### -- %s 2>&1 | FileCheck %s --check-prefix=STDINC
 // STDINC: "-internal-isystem" "/my/system/inc"
+// STDINC: "-internal-isystem" "/my/system/inc2"
 
 // -nostdinc suppresses all of %INCLUDE%, clang resource dirs, and -imsvc dirs.
-// RUN: env INCLUDE=/my/system/inc %clang_cl -nostdinc -imsvc /my/other/inc -### -- %s 2>&1 | FileCheck %s --check-prefix=NOSTDINC
+// RUN: env INCLUDE=/my/system/inc env EXTERNAL_INCLUDE=/my/system/inc2 %clang_cl -nostdinc -imsvc /my/other/inc -### -- %s 2>&1 | FileCheck %s --check-prefix=NOSTDINC
 // NOSTDINC: argument unused{{.*}}-imsvc
 // NOSTDINC-NOT: "-internal-isystem" "/my/system/inc"
+// NOSTDINC-NOT: "-internal-isystem" "/my/system/inc2"
 // NOSTDINC-NOT: "-internal-isystem" "{{.*lib.*clang.*include}}"
 // NOSTDINC-NOT: "-internal-isystem" "/my/other/inc"
 
-// /X suppresses %INCLUDE% but not clang resource dirs or -imsvc dirs.
-// RUN: env INCLUDE=/my/system/inc %clang_cl /X -imsvc /my/other/inc -### -- %s 2>&1 | FileCheck %s --check-prefix=SLASHX
+// /X suppresses %INCLUDE% and %EXTERNAL_INCLUDE% but not clang resource dirs, -imsvc dirs, or /external: flags.
+// RUN: env INCLUDE=/my/system/inc env EXTERNAL_INCLUDE=/my/system/inc2 env FOO=/my/other/inc2 %clang_cl /X -imsvc /my/other/inc /external:env:FOO -### -- %s 2>&1 | FileCheck %s --check-prefix=SLASHX
 // SLASHX-NOT: "argument unused{{.*}}-imsvc"
 // SLASHX-NOT: "-internal-isystem" "/my/system/inc"
+// SLASHX-NOT: "-internal-isystem" "/my/system/inc2"
 // SLASHX: "-internal-isystem" "{{.*lib.*clang.*include}}"
 // SLASHX: "-internal-isystem" "/my/other/inc"
+// SLASHX: "-internal-isystem" "/my/other/inc2"
+
+// /winsysroot suppresses %EXTERNAL_INCLUDE% but not -imsvc dirs or /external: flags.
+// RUN: env env EXTERNAL_INCLUDE=/my/system/inc env FOO=/my/other/inc2 %clang_cl /winsysroot /foo -imsvc /my/other/inc /external:env:FOO -### -- %s 2>&1 | FileCheck %s --check-prefix=SYSROOT
+// SYSROOT-NOT: "argument unused{{.*}}-imsvc"
+// SYSROOT-NOT: "argument unused{{.*}}/external:"
+// SYSROOT-NOT: "/my/system/inc"
+// SYSROOT: "-internal-isystem" "/my/other/inc"
+// SYSROOT: "-internal-isystem" "/my/other/inc2"
+// SYSROOT: "-internal-isystem" "/foo{{.*}}"
+
+// RUN: env "FOO=/dir1;/dir2" env "BAR=/dir3" %clang_cl /external:env:FOO /external:env:BAR -### -- %s 2>&1 | FileCheck %s --check-prefix=EXTERNAL_ENV
+// EXTERNAL_ENV: "-internal-isystem" "/dir1"
+// EXTERNAL_ENV: "-internal-isystem" "/dir2"
+// EXTERNAL_ENV: "-internal-isystem" "/dir3"
Index: clang/lib/Driver/ToolChains/MSVC.cpp
===
--- clang/lib/Driver/ToolChains/MSVC.cpp
+++ clang/lib/Driver/ToolChains/MSVC.cpp
@@ -1243,23 +1243,34 @@
   for (const auto &Path : DriverArgs.getAllArgValues(options::OPT__SLASH_imsvc))
 addSystemInclude(DriverArgs, CC1Args, Path);
 
+  auto AddSystemIncludesFromEnv = [&](StringRef Var) -> bool {
+SmallVector Dirs;
+if (auto Val = llvm::sys::Process::GetEnv(Var)) {
+  StringRef(*Val)

[clang] 3063a54 - [clang-cl] Implement /external:I, /external:env, and EXTERNAL_INCLUDE support (PR36003)

2021-06-21 Thread Hans Wennborg via cfe-commits

Author: Hans Wennborg
Date: 2021-06-21T15:36:14+02:00
New Revision: 3063a5472266f05add4e5b85f34141ba2e66fa2e

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

LOG: [clang-cl] Implement /external:I, /external:env, and EXTERNAL_INCLUDE 
support (PR36003)

This patch does three things:

- Map the /external:I flag to -isystem

- Add support for the /external:env: flag which reads system
  include paths from the  environment variable

- Pick up system include dirs EXTERNAL_INCLUDE in addition to the old
  INCLUDE environment variable.

Differential revision: https://reviews.llvm.org/D104387

Added: 


Modified: 
clang/include/clang/Driver/Options.td
clang/lib/Driver/ToolChains/MSVC.cpp
clang/test/Driver/cl-include.c
clang/test/Driver/cl-options.c

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 0ccf5ef891990..ede7405964ff3 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -5868,6 +5868,9 @@ def _SLASH_diagnostics_classic : 
CLFlag<"diagnostics:classic">,
 def _SLASH_D : CLJoinedOrSeparate<"D">, HelpText<"Define macro">,
   MetaVarName<"">, Alias;
 def _SLASH_E : CLFlag<"E">, HelpText<"Preprocess to stdout">, Alias;
+def _SLASH_external_COLON_I : CLJoinedOrSeparate<"external:I">, Alias,
+  HelpText<"Add directory to include search path with warnings suppressed">,
+  MetaVarName<"">;
 def _SLASH_fp_except : CLFlag<"fp:except">, HelpText<"">, 
Alias;
 def _SLASH_fp_except_ : CLFlag<"fp:except-">,
   HelpText<"">, Alias;
@@ -6076,6 +6079,9 @@ def _SLASH_volatile_Group : OptionGroup<"">,
 def _SLASH_EH : CLJoined<"EH">, HelpText<"Set exception handling model">;
 def _SLASH_EP : CLFlag<"EP">,
   HelpText<"Disable linemarker output and preprocess to stdout">;
+def _SLASH_external_env : CLJoined<"external:env:">,
+  HelpText<"Add dirs in env var  to include search path with warnings 
suppressed">,
+  MetaVarName<"">;
 def _SLASH_FA : CLFlag<"FA">,
   HelpText<"Output assembly code file during compilation">;
 def _SLASH_Fa : CLJoined<"Fa">,
@@ -6239,7 +6245,6 @@ def _SLASH_doc : CLJoined<"doc">;
 def _SLASH_experimental : CLJoined<"experimental:">;
 def _SLASH_exportHeader : CLFlag<"exportHeader">;
 def _SLASH_external : CLJoined<"external:">;
-def _SLASH_external_COLON_I : CLJoinedOrSeparate<"external:I">;
 def _SLASH_FA_joined : CLJoined<"FA">;
 def _SLASH_favor : CLJoined<"favor">;
 def _SLASH_fsanitize_address_use_after_return : 
CLJoined<"fsanitize-address-use-after-return">;

diff  --git a/clang/lib/Driver/ToolChains/MSVC.cpp 
b/clang/lib/Driver/ToolChains/MSVC.cpp
index cf08c42965c8f..18543f313b2f6 100644
--- a/clang/lib/Driver/ToolChains/MSVC.cpp
+++ b/clang/lib/Driver/ToolChains/MSVC.cpp
@@ -1243,23 +1243,34 @@ void MSVCToolChain::AddClangSystemIncludeArgs(const 
ArgList &DriverArgs,
   for (const auto &Path : 
DriverArgs.getAllArgValues(options::OPT__SLASH_imsvc))
 addSystemInclude(DriverArgs, CC1Args, Path);
 
+  auto AddSystemIncludesFromEnv = [&](StringRef Var) -> bool {
+SmallVector Dirs;
+if (auto Val = llvm::sys::Process::GetEnv(Var)) {
+  StringRef(*Val).split(Dirs, ";", /*MaxSplit=*/-1, /*KeepEmpty=*/false);
+  if (!Dirs.empty()) {
+addSystemIncludes(DriverArgs, CC1Args, Dirs);
+return true;
+  }
+}
+return false;
+  };
+
+  // Add %INCLUDE%-like dirs via /external:env: flags.
+  for (const auto &Var :
+   DriverArgs.getAllArgValues(options::OPT__SLASH_external_env)) {
+AddSystemIncludesFromEnv(Var);
+  }
+
   if (DriverArgs.hasArg(options::OPT_nostdlibinc))
 return;
 
-  // Honor %INCLUDE%. It should know essential search paths with vcvarsall.bat.
-  // Skip if the user expressly set a vctoolsdir
+  // Honor %INCLUDE% and %EXTERNAL_INCLUDE%. It should have essential search
+  // paths set by vcvarsall.bat. Skip if the user expressly set a vctoolsdir.
   if (!DriverArgs.getLastArg(options::OPT__SLASH_vctoolsdir,
  options::OPT__SLASH_winsysroot)) {
-if (llvm::Optional cl_include_dir =
-llvm::sys::Process::GetEnv("INCLUDE")) {
-  SmallVector Dirs;
-  StringRef(*cl_include_dir)
-  .split(Dirs, ";", /*MaxSplit=*/-1, /*KeepEmpty=*/false);
-  for (StringRef Dir : Dirs)
-addSystemInclude(DriverArgs, CC1Args, Dir);
-  if (!Dirs.empty())
-return;
-}
+if (AddSystemIncludesFromEnv("INCLUDE") |
+AddSystemIncludesFromEnv("EXTERNAL_INCLUDE"))
+  return;
   }
 
   // When built with access to the proper Windows APIs, try to actually find

diff  --git a/clang/test/Driver/cl-include.c b/clang/test/Driver/cl-include.c
index a69265deed02c..ca9e7db1e6f07 100644
--- a/clang/test/Driver/cl-include.c
+++ b/clang

[PATCH] D104299: Handle interactions between reserved identifier and user-defined suffixes

2021-06-21 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

> Does that look good to you?

That fix-it looks correct to me.


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

https://reviews.llvm.org/D104299

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


[PATCH] D104387: [clang-cl] Implement /external:I, /external:env, and EXTERNAL_INCLUDE support (PR36003)

2021-06-21 Thread Hans Wennborg via Phabricator via cfe-commits
hans added inline comments.



Comment at: clang/lib/Driver/ToolChains/MSVC.cpp:1273
+
+if (include_var) {
+  StringRef(*include_var)

thakis wrote:
> Why not keep the definition of include_var in the if condition like it was on 
> the rhs? (And do it for ext_include_var too)? They're only used in the 
> respective if body, right? i.e. like so:
> 
> ```
> if (llvm::Optional include_var =
> llvm::sys::Process::GetEnv("INCLUDE")) {
>   StringRef(*include_var)
>   .split(Dirs, ";", /*MaxSplit=*/-1, /*KeepEmpty=*/false);
> }
> if (llvm::Optional ext_include_var =
> llvm::sys::Process::GetEnv("EXTERNAL_INCLUDE")) {
>   StringRef(*ext_include_var)
>   .split(Dirs, ";", /*MaxSplit=*/-1, /*KeepEmpty=*/false);
> }
> ```
> 
> (Might even do `for (auto s : {"INCLUDE", "EXTERNAL_INCLUDE"}) ...` but that 
> makes the FIXME harder to do later, so maybe don't do that part :) )
It's because split() creates StringRefs into include_var and ext_include_var, 
so they need to stay in scope until we're done with the Dirs object.

But that's pretty subtle, and the code doesn't look very nice. We're doing the 
same "get env var and split" dance three times now, so I'll move it to a helper 
lambda.


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

https://reviews.llvm.org/D104387

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


[PATCH] D104299: Handle interactions between reserved identifier and user-defined suffixes

2021-06-21 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/lib/Parse/ParseExprCXX.cpp:2639
 // or a ud-suffix from the string literal.
+const bool isUDSuffix = !Literal.getUDSuffix().empty();
 IdentifierInfo *II = nullptr;

Minor style nits



Comment at: clang/lib/Sema/SemaExprCXX.cpp:487
 bool Sema::checkLiteralOperatorId(const CXXScopeSpec &SS,
-  const UnqualifiedId &Name) {
+  const UnqualifiedId &Name, bool isUDSuffix) {
   assert(Name.getKind() == UnqualifiedIdKind::IK_LiteralOperatorId);





Comment at: clang/lib/Sema/SemaExprCXX.cpp:491-493
+// double operator""_Bq(long double);  // OK: does not use
+// the reserved identifier _­Bq ([lex.name]) double operator"" _Bq(long
+// double); // ill-formed, no diagnostic required:

The flow of the previous comments was basically unreadable. I think this is 
more readable, but at the expense of being slightly different from the 
standard's example comments.



Comment at: clang/lib/Sema/SemaExprCXX.cpp:495-496
+IdentifierInfo *II = Name.Identifier;
+auto Status = II->isReserved(PP.getLangOpts());
+auto Loc = Name.getEndLoc();
+if (Status != ReservedIdentifierStatus::NotReserved &&

Please don't use `auto` without the type being spelled out in the 
initialization.



Comment at: clang/lib/Sema/SemaExprCXX.cpp:499
+!PP.getSourceManager().isInSystemHeader(Loc)) {
+  Diag(Loc, diag::warn_reserved_extern_symbol)
+  << II << static_cast(Status)

Because this situation is IFNDR, do we want to upgrade this from a warning to 
an error (that's controlled by the warning flag)?



Comment at: clang/test/Sema/reserved-identifier.cpp:79-84
+long double operator"" _BarbeBleue(long double) // expected-warning 
{{identifier '_BarbeBleue' is reserved because it starts with '_' followed by a 
capital letter}}
+{
+  return 0.;
+}
+
+long double operator""_SacreBleue(long double) // no-warning

Can you add test cases that use the suffix as well? Richard had an especially 
interesting example:
```
int operator""_Foo();
int k2 = operator"" _Foo(); // should warn here, regardless of whether the 
previous line is in a system header
```


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

https://reviews.llvm.org/D104299

___
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

2021-06-21 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun added a comment.

In D104616#2829705 , @RedDocMD wrote:

> If `(ptr1 == ptr2)` is false, we can't say anything really.

Well, I think it depends. If one of the pointers is null, for some platforms, 
we can. E.g. null < non-null is probably true on most architectures, and 
similarly non-null < null is false. Also null <= anyptr is probably true on the 
platforms we care about.

> If they are not the same, the only way == can return true if the two smart 
> pointers were initialized from the same raw pointer. This is of course a 
> fatal bug in itself.

Is it? E.g. two default constructed unique_ptrs both should have null as the 
underlying pointer, they should be considered equal, are not the same object, 
and this is not a fatal bug.


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] D104044: [clang-format] Fix the issue that empty lines being removed at the beginning of namespace

2021-06-21 Thread Darwin Xu via Phabricator via cfe-commits
darwin marked 2 inline comments as done.
darwin added inline comments.



Comment at: clang/unittests/Format/FormatTest.cpp:280
+   "}",
+   CustomStyle));
+  EXPECT_EQ("/* something */ namespace N\n"

MyDeveloperDay wrote:
> I'm not sure I understand this.. why is this not
> 
> ```
> namespace N
> {
> int i;
> }
> ```
Because a namespace is different than a class or struct.

Please try this with chang-format:
```
darwin@Darwins-iMac Desktop % cat a.cpp 
namespace N {


int i;


}
darwin@Darwins-iMac Desktop % clang-format a.cpp -style="{BasedOnStyle: google}"
namespace N {

int i;

}
```
As you can see, clang-format removes the extra lines but still keeps one line 
at the beginning and the end of the namespace. This is the original behavior, I 
think it is very reasonable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104044

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


  1   2   >