[PATCH] D128056: [clang][dataflow] Singleton pointer values for null pointers.

2022-06-23 Thread Stanislav Gatev via Phabricator via cfe-commits
sgatev accepted this revision.
sgatev added inline comments.



Comment at: 
clang/include/clang/Analysis/FlowSensitive/DataflowAnalysisContext.h:164-166
+  /// Returns a pointer value that represents a null pointer. Calls
+  /// with `PointeeType` that are canonically equivalent will return the same
+  /// result.





Comment at: 
clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h:316-318
+  /// Returns a pointer value that represents a null pointer. Calls
+  /// with `PointeeType` that are canonically equivalent will return the same
+  /// result.





Comment at: clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h:319
+  /// result.
+  PointerValue &getOrCreateNullPointerValue(QualType PointeeType);
+

Let's move this below `getThisPointeeStorageLocation` so that it's closer to 
related members. Same for the cpp file.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128056

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


[PATCH] D128328: [C++20][Modules] Improve handing of Private Module Fragment diagnostics.

2022-06-23 Thread Iain Sandoe via Phabricator via cfe-commits
iains added a comment.

In D128328#3602646 , @iains wrote:

> In D128328#3601080 , @ChuanqiXu 
> wrote:
>
>> It looks like we need to handle inline variable as well to match the 
>> intention.
>
> can you construct a test-case, where this would apply and which is not 
> already diagnosed as incorrect?

Did you have some ideas here?

In D128328#3603781 , @vsapsai wrote:

> From the perspective of handling `err_export_inline_not_defined` error as a 
> developer what about the following option?
>
>   export inline void fn_e(); // note: function 'fn_e' exported as 'inline' 
> here
>   
>   // ...
>   module :private;
>   void fn_e() {}  // error: definition of function 'fn_e' can not be inlined 
> because it is private
>
> My suggestion isn't about specific wording but about emitting an error for 
> the definition and mention declaration in the note. Will it make easier to 
> explain the situation? Because I'm not a fan of "must be defined within the 
> module purview" and don't know how digestible it will be for others. Please 
> note that the suggestion is purely from user perspective, I haven't checked 
> how it might affect the implementation.

I agree my error message is kinda "implementor-speak" really, there's a tension 
between using something that will allow the user to find the source of the 
problem with a google search and and avoiding that.

We could implement what you suggest (pending a resolution of what we're 
actually supposed to be implementing) - I guess - but we'd need to defer the 
check until the end of the TU - i.e. after any potential PMF.  I think we can 
differentiate the case that @ChuanqiXu noted (definition local to the PMF) 
because that would not have an entry in the PendingInlineExports table.

As for transitive cases, I agree we need to defer consideration of that until 
we can discuss with core - otherwise this patch will become a rabbit hole ;)




Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:11155
+def err_export_inline_not_defined : Error<
+  "exported inline functions must be defined within the module purview"
+  " and before any private module fragment">;

ChuanqiXu wrote:
> iains wrote:
> > iains wrote:
> > > ChuanqiXu wrote:
> > > > From my reading, 'exported' is not emphasized.
> > > it is here:
> > > https://eel.is/c++draft/module#private.frag-2.1
> > > ( I agree it is somewhat confusing, but the export makes the linkage 
> > > external, which the example treats differently from the fn_m() case which 
> > > has module linkage).
> > > 
> > > It is possible that we might need to pull together several pieces of the 
> > > std and maybe ask core for clarification?
> > > it is here:
> > > https://eel.is/c++draft/module#private.frag-2.1
> > > ( I agree it is somewhat confusing, but the export makes the linkage 
> > > external, which the example treats differently from the fn_m() case which 
> > > has module linkage).
> > 
> > hmm... my linkage comment is wrong - however the distinction between 
> > exported and odr-used seems to be made here (fn_m() and fn_e()).
> > > 
> > > It is possible that we might need to pull together several pieces of the 
> > > std and maybe ask core for clarification?
> > 
> > 
> What I read is:
> > [dcl.inline]p7: https://eel.is/c++draft/dcl.inline#7
> > If an inline function or variable that is attached to a named module is 
> > declared in a definition domain, it shall be defined in that domain.
> 
> and the definition of `definition domain` is:
> > [basic.def.odr]p12: https://eel.is/c++draft/basic#def.odr-12
> >   A definition domain is a private-module-fragment or the portion of a 
> > translation unit excluding its private-module-fragment (if any).
> 
> The definition of "attached to a named module" is:
> > [module.unit]p7: https://eel.is/c++draft/module.unit#7
> >  A module is either a named module or the global module. A declaration 
> > is attached to a module as follows: ...
> 
> So it is clearly not consistency with [module.private.frag]p2.1. I would send 
> this to WG21.
Yes, that was what I found - maybe we are  missing something about the export 
that changes those rules.
.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128328

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


[PATCH] D128328: [C++20][Modules] Improve handing of Private Module Fragment diagnostics.

2022-06-23 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu added a comment.

In D128328#3603940 , @iains wrote:

> In D128328#3602646 , @iains wrote:
>
>> In D128328#3601080 , @ChuanqiXu 
>> wrote:
>>
>>> It looks like we need to handle inline variable as well to match the 
>>> intention.
>>
>> can you construct a test-case, where this would apply and which is not 
>> already diagnosed as incorrect?
>
> Did you have some ideas here?

The test may be something like:

  export module A;
  inline int a;
  module :private
  int a = 0; // expected-error 

But I feel like we couldn't  go on before we get response from WG21.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128328

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


[PATCH] D128328: [C++20][Modules] Improve handing of Private Module Fragment diagnostics.

2022-06-23 Thread Iain Sandoe via Phabricator via cfe-commits
iains added a comment.

In D128328#3603942 , @ChuanqiXu wrote:

> In D128328#3603940 , @iains wrote:
>
>> In D128328#3602646 , @iains wrote:
>>
>>> In D128328#3601080 , @ChuanqiXu 
>>> wrote:
>>>
 It looks like we need to handle inline variable as well to match the 
 intention.
>>>
>>> can you construct a test-case, where this would apply and which is not 
>>> already diagnosed as incorrect?
>>
>> Did you have some ideas here?
>
> The test may be something like:
>
>   export module A;
>   inline int a;
>   module :private
>   int a = 0; // expected-error 

but we reject this at the moment with "redefinition of 'a'" - so that implies 
we do not have fully correct C++17 handling here?

> But I feel like we couldn't  go on before we get response from WG21.

Agreed, and anyway I think we would want to add a new test case, not to amend 
the example from the std (otherwise that becomes confusing as well)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128328

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


[PATCH] D128097: [Clang] Fix compile time regression caused by D126061.

2022-06-23 Thread Martin Böhme via Phabricator via cfe-commits
mboehme added a comment.

Unfortunately, it looks as if this patch did not fix the compile-time 
regression entirely. It did so for the particular source file I tested above, 
but other source files are still slower to compile than before D126061 
.

For reference, here is the compile-time regression caused by D126061 
:

http://llvm-compile-time-tracker.com/compare.php?from=7acc88be0312c721bc082ed9934e381d297f4707&to=8c7b64b5ae2a09027c38db969a04fc9ddd0cd6bb&stat=instructions

This a 0.35% regression (geomean) on -O0 compiles.

Here is the improvement due to this patch (D128097 
):

http://llvm-compile-time-tracker.com/compare.php?from=1c2b756cd6f9f9408863fb0e91f55731f81b46d9&to=0d300da799b06931eb6b974198d683548a8c8392&stat=instructions

This is only a 0.18% improvement (geomean) on -O0 compiles.

Here’s the cumulative change from before D126061 
 landed until after this patch (D128097 
) landed:

http://llvm-compile-time-tracker.com/compare.php?from=7acc88be0312c721bc082ed9934e381d297f4707&to=0d300da799b06931eb6b974198d683548a8c8392&stat=instructions

This confirms that we’re still seeing an 0.22% regression (geomean) on -O0 
compiles.

I’ll do some more investigation to see what else is causing the slowdown. I’ll 
also try to run the whole test suite locally, though I had some trouble with 
this the first time I tried it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128097

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


[PATCH] D126061: [clang] Reject non-declaration C++11 attributes on declarations

2022-06-23 Thread Martin Böhme via Phabricator via cfe-commits
mboehme added a comment.

https://reviews.llvm.org/D128097 is now submitted. Unfortunately, it didn't fix 
the compile-time regression entirely (see detailed comments there).

I'll do some more investigation to see where the rest of the slowdown is coming 
from.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126061

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


[PATCH] D128328: [C++20][Modules] Improve handing of Private Module Fragment diagnostics.

2022-06-23 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu added a comment.

In D128328#3603945 , @iains wrote:

> In D128328#3603942 , @ChuanqiXu 
> wrote:
>
>> In D128328#3603940 , @iains wrote:
>>
>>> In D128328#3602646 , @iains wrote:
>>>
 In D128328#3601080 , @ChuanqiXu 
 wrote:

> It looks like we need to handle inline variable as well to match the 
> intention.

 can you construct a test-case, where this would apply and which is not 
 already diagnosed as incorrect?
>>>
>>> Did you have some ideas here?
>>
>> The test may be something like:
>>
>>   export module A;
>>   inline int a;
>>   module :private
>>   int a = 0; // expected-error 
>
> but we reject this at the moment with "redefinition of 'a'" - so that implies 
> we do not have fully correct C++17 handling here?

Sorry, my bad. The configuration of my godbolt was wrong (The input is LLVM 
IR). I feel like the following one should be the test case:

  export module A;
  [export] inline int a;

Here the inline variable 'a' is declared in the definition domain but not 
defined. This violates [dcl.inline]p7:

> If an inline function or variable that is attached to a named module is 
> declared in a definition domain, it shall be defined in that domain.

Also, **if** [module.private.frag]p2.1 is changed into:

> the point by which the definition of an [exported] inline function or 
> variable is required

The test above would test this too.

BTW, it shows we could lack test like:

  export module A;
  [export] inline void func(); // no definition in the definition domain

The meaning of [export] depends on the result of the feedback from WG21.

>> But I feel like we couldn't  go on before we get response from WG21.
>
> Agreed, and anyway I think we would want to add a new test case, not to amend 
> the example from the std (otherwise that becomes confusing as well)




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128328

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


[PATCH] D128328: [C++20][Modules] Improve handing of Private Module Fragment diagnostics.

2022-06-23 Thread Iain Sandoe via Phabricator via cfe-commits
iains added a comment.

In D128328#3603953 , @ChuanqiXu wrote:

> In D128328#3603945 , @iains wrote:
>
>> In D128328#3603942 , @ChuanqiXu 
>> wrote:
>>
>>> In D128328#3603940 , @iains wrote:
>>>
 In D128328#3602646 , @iains 
 wrote:

> In D128328#3601080 , @ChuanqiXu 
> wrote:
>
>> It looks like we need to handle inline variable as well to match the 
>> intention.
>
> can you construct a test-case, where this would apply and which is not 
> already diagnosed as incorrect?

 Did you have some ideas here?



> I feel like the following one should be the test case:
>
>   export module A;
>   [export] inline int a;
>
> Here the inline variable 'a' is declared in the definition domain but not 
> defined. This violates [dcl.inline]p7:
>
>> If an inline function or variable that is attached to a named module is 
>> declared in a definition domain, it shall be defined in that domain.

hmm ... isn't that implicitly initialised with 0?

> Also, **if** [module.private.frag]p2.1 is changed into:
>
>> the point by which the definition of an [exported] inline function or 
>> variable is required
>
> The test above would cover this too.
>
> BTW, it shows we could lack test like:
>
>   export module A;
>   [export] inline void func(); // no definition in the definition domain

I think the current impl. should catch that - the only difference would be 
that, in the case there's a definition in the PMF, there would be a note about 
the unreachable definition.

> The meaning of [export] depends on the result of the feedback from WG21.

yes, I saw your post to ext.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128328

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


[PATCH] D128328: [C++20][Modules] Improve handing of Private Module Fragment diagnostics.

2022-06-23 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu added a comment.

In D128328#3603967 , @iains wrote:

> In D128328#3603953 , @ChuanqiXu 
> wrote:
>
>> In D128328#3603945 , @iains wrote:
>>
>>> In D128328#3603942 , @ChuanqiXu 
>>> wrote:
>>>
 In D128328#3603940 , @iains 
 wrote:

> In D128328#3602646 , @iains 
> wrote:
>
>> In D128328#3601080 , 
>> @ChuanqiXu wrote:
>>
>>> It looks like we need to handle inline variable as well to match the 
>>> intention.
>>
>> can you construct a test-case, where this would apply and which is not 
>> already diagnosed as incorrect?
>
> Did you have some ideas here?
>
>
>
>> I feel like the following one should be the test case:
>>
>>   export module A;
>>   [export] inline int a;
>>
>> Here the inline variable 'a' is declared in the definition domain but not 
>> defined. This violates [dcl.inline]p7:
>>
>>> If an inline function or variable that is attached to a named module is 
>>> declared in a definition domain, it shall be defined in that domain.
>
> hmm ... isn't that implicitly initialised with 0?

Oh, I just realized every declaration is a definition too except some cases: 
https://eel.is/c++draft/basic.def#2

And I failed to give an example that a undefined inline variable declaration 
attached to the named modules. I wondered:

  export module A;
  extern "C++" inline int a;
  extern "C++" int a = 0;

But now 'a' is attached to global module instead of named modules. So I just 
failed to find a good example... very sorry for wasting the time

>> Also, **if** [module.private.frag]p2.1 is changed into:
>>
>>> the point by which the definition of an [exported] inline function or 
>>> variable is required
>>
>> The test above would cover this too.
>>
>> BTW, it shows we could lack test like:
>>
>>   export module A;
>>   [export] inline void func(); // no definition in the definition domain
>
> I think the current impl. should catch that - the only difference would be 
> that, in the case there's a definition in the PMF, there would be a note 
> about the unreachable definition.

It looks like the current impl doesn't catch this: 
https://godbolt.org/z/fh9Ehfdj5 . I think I don't make mistake this time since 
a function declaration without function body shouldn't be a definition.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128328

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


[PATCH] D128409: [clang-cl] Add -emit-ast to clang-cl driver

2022-06-23 Thread Tobias Hieta via Phabricator via cfe-commits
thieta created this revision.
thieta added reviewers: hans, mstorsjo.
Herald added a project: All.
thieta requested review of this revision.
Herald added a subscriber: MaskRay.
Herald added a project: clang.

Also make the output of -emit-ast end up where /Fo or /o points.
The same with .plist files from the static analyzer.

These are changes needed to make it possible to do CTU static
analysing work with clang-cl.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D128409

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/Driver.cpp


Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -5625,7 +5625,8 @@
   // Determine what the derived output name should be.
   const char *NamedOutput;
 
-  if ((JA.getType() == types::TY_Object || JA.getType() == types::TY_LTO_BC) &&
+  if ((JA.getType() == types::TY_Object || JA.getType() == types::TY_LTO_BC ||
+   JA.getType() == types::TY_AST || JA.getType() == types::TY_Plist) &&
   C.getArgs().hasArg(options::OPT__SLASH_Fo, options::OPT__SLASH_o)) {
 // The /Fo or /o flag decides the object filename.
 StringRef Val =
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -831,7 +831,7 @@
   HelpText<"Pass  to the linker">, MetaVarName<"">,
   Group;
 def Xoffload_linker : JoinedAndSeparate<["-"], "Xoffload-linker">,
-  HelpText<"Pass  to the offload linkers or the ones idenfied by 
-">, 
+  HelpText<"Pass  to the offload linkers or the ones idenfied by 
-">,
   MetaVarName<" ">, Group;
 def Xpreprocessor : Separate<["-"], "Xpreprocessor">, 
Group,
   HelpText<"Pass  to the preprocessor">, MetaVarName<"">;
@@ -1091,7 +1091,7 @@
 def dynamic : Flag<["-"], "dynamic">, Flags<[NoArgumentUnused]>;
 def d_Flag : Flag<["-"], "d">, Group;
 def d_Joined : Joined<["-"], "d">, Group;
-def emit_ast : Flag<["-"], "emit-ast">,
+def emit_ast : Flag<["-"], "emit-ast">, Flags<[CoreOption]>,
   HelpText<"Emit Clang AST files for source inputs">;
 def emit_llvm : Flag<["-"], "emit-llvm">, Flags<[CC1Option, FC1Option, 
FlangOption]>, Group,
   HelpText<"Use the LLVM representation for assembler and object files">;


Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -5625,7 +5625,8 @@
   // Determine what the derived output name should be.
   const char *NamedOutput;
 
-  if ((JA.getType() == types::TY_Object || JA.getType() == types::TY_LTO_BC) &&
+  if ((JA.getType() == types::TY_Object || JA.getType() == types::TY_LTO_BC ||
+   JA.getType() == types::TY_AST || JA.getType() == types::TY_Plist) &&
   C.getArgs().hasArg(options::OPT__SLASH_Fo, options::OPT__SLASH_o)) {
 // The /Fo or /o flag decides the object filename.
 StringRef Val =
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -831,7 +831,7 @@
   HelpText<"Pass  to the linker">, MetaVarName<"">,
   Group;
 def Xoffload_linker : JoinedAndSeparate<["-"], "Xoffload-linker">,
-  HelpText<"Pass  to the offload linkers or the ones idenfied by -">, 
+  HelpText<"Pass  to the offload linkers or the ones idenfied by -">,
   MetaVarName<" ">, Group;
 def Xpreprocessor : Separate<["-"], "Xpreprocessor">, Group,
   HelpText<"Pass  to the preprocessor">, MetaVarName<"">;
@@ -1091,7 +1091,7 @@
 def dynamic : Flag<["-"], "dynamic">, Flags<[NoArgumentUnused]>;
 def d_Flag : Flag<["-"], "d">, Group;
 def d_Joined : Joined<["-"], "d">, Group;
-def emit_ast : Flag<["-"], "emit-ast">,
+def emit_ast : Flag<["-"], "emit-ast">, Flags<[CoreOption]>,
   HelpText<"Emit Clang AST files for source inputs">;
 def emit_llvm : Flag<["-"], "emit-llvm">, Flags<[CC1Option, FC1Option, FlangOption]>, Group,
   HelpText<"Use the LLVM representation for assembler and object files">;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D128409: [clang-cl] Add -emit-ast to clang-cl driver

2022-06-23 Thread Tobias Hieta via Phabricator via cfe-commits
thieta added inline comments.



Comment at: clang/include/clang/Driver/Options.td:834
 def Xoffload_linker : JoinedAndSeparate<["-"], "Xoffload-linker">,
-  HelpText<"Pass  to the offload linkers or the ones idenfied by 
-">, 
+  HelpText<"Pass  to the offload linkers or the ones idenfied by 
-">,
   MetaVarName<" ">, Group;

Whops. My editor strikes again and removes a trailing space. Let me know if I 
should edit this out of this commit.



Comment at: clang/lib/Driver/Driver.cpp:5629
+  if ((JA.getType() == types::TY_Object || JA.getType() == types::TY_LTO_BC ||
+   JA.getType() == types::TY_AST || JA.getType() == types::TY_Plist) &&
   C.getArgs().hasArg(options::OPT__SLASH_Fo, options::OPT__SLASH_o)) {

I do wonder if this limitation here is really wanted. It makes clang-cl behave 
a bit different from clang/clang++. I can also split this part out in it's own 
commit if we feel like it's necessary.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128409

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


[PATCH] D128043: [flang][driver] Add support for `-O{0|1|2|3}`

2022-06-23 Thread Diana Picus via Phabricator via cfe-commits
rovka added a comment.

I just realized I haven't pestered you enough about testing :) Can you add a 
test that -O4 indeed warns and uses -O3? Also, the summary says this should 
work in both the compilation and the frontend driver, but you're only testing 
with %flang_fc1.




Comment at: flang/test/Driver/default-optimization-pipelines.f90:1
+! Verify that`-O{n}` is indeed taken into account when defining the LLVM 
optimization/middle-end pass pass pipeline.
+




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128043

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


[PATCH] D128059: [Clang] Add a warning on invalid UTF-8 in comments.

2022-06-23 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin updated this revision to Diff 439276.
cor3ntin added a comment.

- Remove explicit load instruction
- cleanup extra braces


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128059

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticLexKinds.td
  clang/lib/Lex/Lexer.cpp
  clang/test/Lexer/comment-invalid-utf8.c
  llvm/include/llvm/Support/ConvertUTF.h
  llvm/lib/Support/ConvertUTF.cpp

Index: llvm/lib/Support/ConvertUTF.cpp
===
--- llvm/lib/Support/ConvertUTF.cpp
+++ llvm/lib/Support/ConvertUTF.cpp
@@ -417,6 +417,16 @@
 return isLegalUTF8(source, length);
 }
 
+/*
+ * Exported function to return the size of the first utf-8 code unit sequence,
+ * Or 0 if the sequence is not valid;
+ */
+unsigned getUTF8SequenceSize(const UTF8 *source, const UTF8 *sourceEnd) {
+  int length = trailingBytesForUTF8[*source] + 1;
+  return (length > sourceEnd - source && isLegalUTF8(source, length)) ? length
+  : 0;
+}
+
 /* - */
 
 static unsigned
Index: llvm/include/llvm/Support/ConvertUTF.h
===
--- llvm/include/llvm/Support/ConvertUTF.h
+++ llvm/include/llvm/Support/ConvertUTF.h
@@ -181,6 +181,8 @@
 
 Boolean isLegalUTF8String(const UTF8 **source, const UTF8 *sourceEnd);
 
+unsigned getUTF8SequenceSize(const UTF8 *source, const UTF8 *sourceEnd);
+
 unsigned getNumBytesForUTF8(UTF8 firstByte);
 
 /*/
Index: clang/lib/Lex/Lexer.cpp
===
--- clang/lib/Lex/Lexer.cpp
+++ clang/lib/Lex/Lexer.cpp
@@ -2391,13 +2391,37 @@
   //
   // This loop terminates with CurPtr pointing at the newline (or end of buffer)
   // character that ends the line comment.
+
+  // C++23 [lex.phases] p1
+  // Diagnose invalid UTF-8 if the corresponding warning is enabled, emitting a
+  // diagnostic only once per entire ill-formed subsequence to avoid
+  // emiting to many diagnostics (see http://unicode.org/review/pr-121.html).
+  bool UnicodeDecodingAlreadyDiagnosed = false;
+
   char C;
   while (true) {
 C = *CurPtr;
 // Skip over characters in the fast loop.
-while (C != 0 &&// Potentially EOF.
-   C != '\n' && C != '\r')  // Newline or DOS-style newline.
+while (isASCII(C) && C != 0 &&   // Potentially EOF.
+   C != '\n' && C != '\r') { // Newline or DOS-style newline.
   C = *++CurPtr;
+  UnicodeDecodingAlreadyDiagnosed = false;
+}
+
+if (!isASCII(C)) {
+  unsigned Length = llvm::getUTF8SequenceSize(
+  (const llvm::UTF8 *)CurPtr, (const llvm::UTF8 *)BufferEnd);
+  if (Length == 0) {
+if (!UnicodeDecodingAlreadyDiagnosed && !isLexingRawMode())
+  Diag(CurPtr, diag::warn_invalid_utf8_in_comment);
+UnicodeDecodingAlreadyDiagnosed = true;
+++CurPtr;
+  } else {
+UnicodeDecodingAlreadyDiagnosed = false;
+CurPtr += Length;
+  }
+  continue;
+}
 
 const char *NextLine = CurPtr;
 if (C != 0) {
@@ -2664,6 +2688,12 @@
   if (C == '/')
 C = *CurPtr++;
 
+  // C++23 [lex.phases] p1
+  // Diagnose invalid UTF-8 if the corresponding warning is enabled, emitting a
+  // diagnostic only once per entire ill-formed subsequence to avoid
+  // emiting to many diagnostics (see http://unicode.org/review/pr-121.html).
+  bool UnicodeDecodingAlreadyDiagnosed = false;
+
   while (true) {
 // Skip over all non-interesting characters until we find end of buffer or a
 // (probably ending) '/' character.
@@ -2672,14 +2702,24 @@
 // doesn't check for '\0'.
 !(PP && PP->getCodeCompletionFileLoc() == FileLoc)) {
   // While not aligned to a 16-byte boundary.
-  while (C != '/' && ((intptr_t)CurPtr & 0x0F) != 0)
+  while (C != '/' && (intptr_t)CurPtr % 16 != 0) {
+if (!isASCII(C)) {
+  CurPtr--;
+  goto MultiByteUTF8;
+}
 C = *CurPtr++;
-
+  }
   if (C == '/') goto FoundSlash;
 
 #ifdef __SSE2__
   __m128i Slashes = _mm_set1_epi8('/');
-  while (CurPtr+16 <= BufferEnd) {
+  while (CurPtr + 16 < BufferEnd) {
+int Mask = _mm_movemask_epi8(*(const __m128i *)CurPtr);
+if (LLVM_UNLIKELY(Mask != 0)) {
+  CurPtr += llvm::countTrailingZeros(Mask);
+  goto MultiByteUTF8;
+}
+// look for slashes
 int cmp = _mm_movemask_epi8(_mm_cmpeq_epi8(*(const __m128i*)CurPtr,
 Slashes));
 if (cmp != 0) {
@@ -2692,21 +2732,41 @@
 CurPtr += 16;
   }
 #elif __ALTIVEC__
+  __vector unsigned char LongUTF = {0x80, 0x80, 0x80, 0x80, 0x80, 

[PATCH] D113107: Support of expression granularity for _Float16.

2022-06-23 Thread Phoebe Wang via Phabricator via cfe-commits
pengfei added a comment.

@zahiraam, community requires to enable the `_Float16` support in FE, see 
https://discourse.llvm.org/t/how-to-build-compiler-rt-for-new-x86-half-float-abi/63366
Is there any blocking issue to land it soon? Otherwise, we can split the 
changes in `X86.cpp`, `LanguageExtensions.rst`, `ReleaseNotes.rst` and some 
tests from this patch and land them first.


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

https://reviews.llvm.org/D113107

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


[PATCH] D126461: [RISCV] Extract and store new vl of vleff/vlsegff iff new_vl output pointer isn't null

2022-06-23 Thread Wang Pengcheng via Phabricator via cfe-commits
pcwang-thead abandoned this revision.
pcwang-thead added a comment.

After discussion, we decide to not change anything right now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126461

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


[PATCH] D128411: [syntax] Introduce a BaseToken class.

2022-06-23 Thread Haojian Wu via Phabricator via cfe-commits
hokein created this revision.
hokein added reviewers: sammccall, ilya-biryukov.
Herald added a project: All.
hokein requested review of this revision.
Herald added a project: clang.

This enables us to use a different underlying token implementation for the
syntax Leaf node -- in clang pseudoparser, we want to produce a
syntax-tree with its own pseudo::Token rather than syntax::Token.

Now Leaf node points to a BaseToken, which can be a different subclass
depending on token implementation.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D128411

Files:
  clang/include/clang/Tooling/Syntax/BaseToken.h
  clang/include/clang/Tooling/Syntax/Tokens.h
  clang/include/clang/Tooling/Syntax/Tree.h
  clang/lib/Tooling/Syntax/BuildTree.cpp
  clang/lib/Tooling/Syntax/ComputeReplacements.cpp
  clang/lib/Tooling/Syntax/Synthesis.cpp
  clang/lib/Tooling/Syntax/Tokens.cpp
  clang/lib/Tooling/Syntax/Tree.cpp
  clang/tools/clang-check/ClangCheck.cpp
  clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
  clang/unittests/Tooling/Syntax/SynthesisTest.cpp
  clang/unittests/Tooling/Syntax/TokensTest.cpp
  clang/unittests/Tooling/Syntax/TreeTest.cpp
  clang/unittests/Tooling/Syntax/TreeTestBase.cpp

Index: clang/unittests/Tooling/Syntax/TreeTestBase.cpp
===
--- clang/unittests/Tooling/Syntax/TreeTestBase.cpp
+++ clang/unittests/Tooling/Syntax/TreeTestBase.cpp
@@ -38,10 +38,10 @@
 ArrayRef tokens(syntax::Node *N) {
   assert(N->isOriginal() && "tokens of modified nodes are not well-defined");
   if (auto *L = dyn_cast(N))
-return llvm::makeArrayRef(L->getToken(), 1);
+return llvm::makeArrayRef(L->getTokenAs(), 1);
   auto *T = cast(N);
-  return llvm::makeArrayRef(T->findFirstLeaf()->getToken(),
-T->findLastLeaf()->getToken() + 1);
+  return llvm::makeArrayRef(T->findFirstLeaf()->getTokenAs(),
+T->findLastLeaf()->getTokenAs() + 1);
 }
 } // namespace
 
Index: clang/unittests/Tooling/Syntax/TreeTest.cpp
===
--- clang/unittests/Tooling/Syntax/TreeTest.cpp
+++ clang/unittests/Tooling/Syntax/TreeTest.cpp
@@ -180,7 +180,7 @@
 private:
   std::string dumpQuotedTokensOrNull(const Node *N) {
 return N ? "'" +
-   StringRef(N->dumpTokens(Arena->getSourceManager()))
+   StringRef(N->dumpTokens(&Arena->getSourceManager()))
.trim()
.str() +
"'"
Index: clang/unittests/Tooling/Syntax/TokensTest.cpp
===
--- clang/unittests/Tooling/Syntax/TokensTest.cpp
+++ clang/unittests/Tooling/Syntax/TokensTest.cpp
@@ -220,7 +220,7 @@
 }
 // An equality test for search.
 auto TextMatches = [this](llvm::StringRef Q, const syntax::Token &T) {
-  return Q == T.text(*SourceMgr);
+  return Q == T.text(&*SourceMgr);
 };
 // Find a match.
 auto Found =
@@ -906,7 +906,7 @@
 SourceLocation Loc = SourceMgr->getComposedLoc(SourceMgr->getMainFileID(),
Code.points()[Index]);
 const syntax::Token *Tok = spelledIdentifierTouching(Loc, Buffer);
-return Tok ? Tok->text(*SourceMgr) : "";
+return Tok ? Tok->text(&*SourceMgr) : "";
   };
 
   EXPECT_THAT(Touching(0), SameRange(findSpelled("int")));
Index: clang/unittests/Tooling/Syntax/SynthesisTest.cpp
===
--- clang/unittests/Tooling/Syntax/SynthesisTest.cpp
+++ clang/unittests/Tooling/Syntax/SynthesisTest.cpp
@@ -27,7 +27,8 @@
   return ::testing::AssertionFailure()
  << "Root was not built successfully.";
 
-auto Actual = StringRef(Root->dump(Arena->getSourceManager())).trim().str();
+auto Actual =
+StringRef(Root->dump(&Arena->getSourceManager())).trim().str();
 auto Expected = Dump.trim().str();
 // EXPECT_EQ shows the diff between the two strings if they are different.
 EXPECT_EQ(Expected, Actual);
@@ -175,7 +176,7 @@
 
   auto *Copy = deepCopyExpandingMacros(*Arena, StatementContinue);
   EXPECT_TRUE(
-  treeDumpEqual(Copy, StatementContinue->dump(Arena->getSourceManager(;
+  treeDumpEqual(Copy, StatementContinue->dump(&Arena->getSourceManager(;
   // FIXME: Test that copy is independent of original, once the Mutations API is
   // more developed.
 }
Index: clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
===
--- clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
+++ clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
@@ -26,7 +26,7 @@
 auto ErrorOK = errorOK(Code);
 if (!ErrorOK)
   return ErrorOK;
-auto Actual = StringRef(Root->dump(Arena->getSourceManager())).trim().str();
+auto Actual = StringRef(Root->dump(&Arena->getSourceManager())).trim().str();
  

[PATCH] D128328: [C++20][Modules] Improve handing of Private Module Fragment diagnostics.

2022-06-23 Thread Iain Sandoe via Phabricator via cfe-commits
iains added a comment.

In D128328#3603980 , @ChuanqiXu wrote:

> 



>>> Also, **if** [module.private.frag]p2.1 is changed into:
>>>
 the point by which the definition of an [exported] inline function or 
 variable is required
>>>
>>> The test above would cover this too.
>>>
>>> BTW, it shows we could lack test like:
>>>
>>>   export module A;
>>>   [export] inline void func(); // no definition in the definition domain
>>
>> I think the current impl. should catch that - the only difference would be 
>> that, in the case there's a definition in the PMF, there would be a note 
>> about the unreachable definition.
>
> It looks like the current impl doesn't catch this: 
> https://godbolt.org/z/fh9Ehfdj5 . I think I don't make mistake this time 
> since a function declaration without function body shouldn't be a definition.

Right, that should be an error - we do not have a test for it. 
ActOnEndOfTranslationUnitFragment should be called with "Kind 
=TUFragmentKind::Normal" whether there us a PMF or not.
https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/Sema.cpp#L1131
so - modulo the underlying question about 'export' we probably just need a 
section test-case
(we could still defer the processing to the end of the TU and implement the 
error messages as suggested by @vsapsai )


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128328

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


[PATCH] D128043: [flang][driver] Add support for `-O{0|1|2|3}`

2022-06-23 Thread Andrzej Warzynski via Phabricator via cfe-commits
awarzynski added a comment.

In D128043#3604037 , @rovka wrote:

> I just realized I haven't pestered you enough about testing :)

I did feel like I was missing something here, haha! Updates arriving shortly!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128043

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


[PATCH] D128043: [flang][driver] Add support for `-O{0|1|2|3}`

2022-06-23 Thread Andrzej Warzynski via Phabricator via cfe-commits
awarzynski updated this revision to Diff 439285.
awarzynski added a comment.

Add tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128043

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Flang.cpp
  flang/include/flang/Frontend/CodeGenOptions.def
  flang/include/flang/Frontend/CodeGenOptions.h
  flang/include/flang/Frontend/CompilerInvocation.h
  flang/include/flang/Frontend/FrontendActions.h
  flang/lib/Frontend/CMakeLists.txt
  flang/lib/Frontend/CodeGenOptions.cpp
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/Frontend/FrontendActions.cpp
  flang/test/Driver/default-optimization-pipelines.f90
  flang/test/Driver/driver-help.f90
  flang/test/Driver/flang_f_opts.f90

Index: flang/test/Driver/flang_f_opts.f90
===
--- /dev/null
+++ flang/test/Driver/flang_f_opts.f90
@@ -0,0 +1,14 @@
+! Test for warnings generated when parsing driver options. You can use this file for relatively small tests and to avoid creating
+! new test files.
+
+!---
+! RUN LINES
+!---
+! RUN: %flang -### -S -O4 %s 2>&1 | FileCheck %s
+
+!---
+! EXPECTED OUTPUT
+!---
+! CHECK: warning: -O4 is equivalent to -O3
+! CHECK-LABEL: "-fc1"
+! CHECK: -O3
Index: flang/test/Driver/driver-help.f90
===
--- flang/test/Driver/driver-help.f90
+++ flang/test/Driver/driver-help.f90
@@ -96,6 +96,7 @@
 ! HELP-FC1-NEXT: -fdebug-measure-parse-tree
 ! HELP-FC1-NEXT: Measure the parse tree
 ! HELP-FC1-NEXT: -fdebug-module-writer   Enable debug messages while writing module files
+! HELP-FC1-NEXT: -fdebug-pass-managerPrints debug information for the new pass manage
 ! HELP-FC1-NEXT: -fdebug-pre-fir-treeDump the pre-FIR tree
 ! HELP-FC1-NEXT: -fdebug-unparse-no-sema Unparse and stop (skips the semantic checks)
 ! HELP-FC1-NEXT: -fdebug-unparse-with-symbols
@@ -120,6 +121,7 @@
 ! HELP-FC1-NEXT: -fno-analyzed-objects-for-unparse
 ! HELP-FC1-NEXT:Do not use the analyzed objects when unparsing
 ! HELP-FC1-NEXT: -fno-automatic Implies the SAVE attribute for non-automatic local objects in subprograms unless RECURSIVE
+! HELP-FC1-NEXT: -fno-debug-pass-manager Disables debug printing for the new pass manager
 ! HELP-FC1-NEXT: -fno-reformat  Dump the cooked character stream in -E mode
 ! HELP-FC1-NEXT: -fopenacc  Enable OpenACC
 ! HELP-FC1-NEXT: -fopenmp   Parse OpenMP pragmas and generate parallel code.
Index: flang/test/Driver/default-optimization-pipelines.f90
===
--- /dev/null
+++ flang/test/Driver/default-optimization-pipelines.f90
@@ -0,0 +1,27 @@
+! Verify that`-O{n}` is indeed taken into account when defining the LLVM optimization/middle-end pass pipeline.
+
+!---
+! RUN LINES
+!---
+! RUN: %flang -S -O0 %s -Xflang -fdebug-pass-manager -o /dev/null 2>&1 | FileCheck %s --check-prefix=CHECK-O0
+! RUN: %flang_fc1 -S -O0 %s -fdebug-pass-manager -o /dev/null 2>&1 | FileCheck %s --check-prefix=CHECK-O0
+
+! RUN: %flang -S -O2 %s -Xflang -fdebug-pass-manager -o /dev/null 2>&1 | FileCheck %s --check-prefix=CHECK-O2
+! RUN: %flang_fc1 -S -O2 %s -fdebug-pass-manager -o /dev/null 2>&1 | FileCheck %s --check-prefix=CHECK-O2
+
+!---
+! EXPECTED OUTPUT
+!---
+! CHECK-O0-NOT: Running pass: SimplifyCFGPass on simple_loop_
+! CHECK-O0: Running analysis: TargetLibraryAnalysis on simple_loop_
+
+! CHECK-O2: Running pass: SimplifyCFGPass on simple_loop_
+
+!---
+! INPUT
+!---
+subroutine simple_loop
+  integer :: i
+  do i=1,5
+  end do
+end subroutine
Index: flang/lib/Frontend/FrontendActions.cpp
===
--- flang/lib/Frontend/FrontendActions.cpp
+++ flang/lib/Frontend/FrontendActions.cpp
@@ -46,6 +46,7 @@
 #include "llvm/IRReader/IRReader.h"
 #include "llvm/MC/TargetRegistry.h"
 #include "llvm/Passes/PassBuilder.h"
+#include "llvm/Passes/StandardInstrumentations.h"
 #include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/SourceMgr.h"
 #include "llvm/Target/TargetMachine.h"
@@ -538,7 +539,6 @@
   /*Features=*/"",
   llvm::TargetOptions(), llvm::None));
   assert(tm && "Failed to create TargetMachine");
-  llvmModule->setDataLayout(tm->createDataLayout());
 }
 
 static std::unique_ptr
@@ -610,23 +610,59 @@
   codeGenPasses.run(llvmModule);
 }
 
-/// Generate LLVM byte code file from the input LLVM module.
-///
-/// \param [in] tm Target machine to aid the code-gen pipeline set-up
-/// \param [in] llvmModule LLVM module to lower to assembly/machine-code
-/// \param [out] os Output stream to emit the generated c

[clang] 7dc81c6 - [clang][analyzer] Fix StdLibraryFunctionsChecker 'mkdir' return value.

2022-06-23 Thread Balázs Kéri via cfe-commits

Author: Balázs Kéri
Date: 2022-06-23T11:27:26+02:00
New Revision: 7dc81c624433627e6811801b5a7e53d77c216616

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

LOG: [clang][analyzer] Fix StdLibraryFunctionsChecker 'mkdir' return value.

The functions 'mkdir', 'mknod', 'mkdirat', 'mknodat' return 0 on success
and -1 on failure. The checker modeled these functions with a >= 0
return value on success which is changed to 0 only. This fix makes
ErrnoChecker work better for these functions.

Reviewed By: steakhal

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

Added: 


Modified: 
clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp

Removed: 




diff  --git a/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp 
b/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
index 5142cf76653ac..ef673ae41a3dc 100644
--- a/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
@@ -1904,44 +1904,40 @@ void StdLibraryFunctionsChecker::initFunctionSummaries(
 ArgumentCondition(1, WithinRange, Range(0, SizeMax;
 
 // int mkdir(const char *pathname, mode_t mode);
-// FIXME: returns 0 on success, ReturnsValidFileDescriptor is incorrect
 addToFunctionSummaryMap(
 "mkdir", Signature(ArgTypes{ConstCharPtrTy, Mode_tTy}, RetType{IntTy}),
 Summary(NoEvalCall)
-.Case(ReturnsValidFileDescriptor, ErrnoMustNotBeChecked)
+.Case(ReturnsZero, ErrnoMustNotBeChecked)
 .Case(ReturnsMinusOne, ErrnoNEZeroIrrelevant)
 .ArgConstraint(NotNull(ArgNo(0;
 
 // int mkdirat(int dirfd, const char *pathname, mode_t mode);
-// FIXME: returns 0 on success, ReturnsValidFileDescriptor is incorrect
 addToFunctionSummaryMap(
 "mkdirat",
 Signature(ArgTypes{IntTy, ConstCharPtrTy, Mode_tTy}, RetType{IntTy}),
 Summary(NoEvalCall)
-.Case(ReturnsValidFileDescriptor, ErrnoMustNotBeChecked)
+.Case(ReturnsZero, ErrnoMustNotBeChecked)
 .Case(ReturnsMinusOne, ErrnoNEZeroIrrelevant)
 .ArgConstraint(NotNull(ArgNo(1;
 
 Optional Dev_tTy = lookupTy("dev_t");
 
 // int mknod(const char *pathname, mode_t mode, dev_t dev);
-// FIXME: returns 0 on success, ReturnsValidFileDescriptor is incorrect
 addToFunctionSummaryMap(
 "mknod",
 Signature(ArgTypes{ConstCharPtrTy, Mode_tTy, Dev_tTy}, RetType{IntTy}),
 Summary(NoEvalCall)
-.Case(ReturnsValidFileDescriptor, ErrnoMustNotBeChecked)
+.Case(ReturnsZero, ErrnoMustNotBeChecked)
 .Case(ReturnsMinusOne, ErrnoNEZeroIrrelevant)
 .ArgConstraint(NotNull(ArgNo(0;
 
 // int mknodat(int dirfd, const char *pathname, mode_t mode, dev_t dev);
-// FIXME: returns 0 on success, ReturnsValidFileDescriptor is incorrect
 addToFunctionSummaryMap(
 "mknodat",
 Signature(ArgTypes{IntTy, ConstCharPtrTy, Mode_tTy, Dev_tTy},
   RetType{IntTy}),
 Summary(NoEvalCall)
-.Case(ReturnsValidFileDescriptor, ErrnoMustNotBeChecked)
+.Case(ReturnsZero, ErrnoMustNotBeChecked)
 .Case(ReturnsMinusOne, ErrnoNEZeroIrrelevant)
 .ArgConstraint(NotNull(ArgNo(1;
 



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


[PATCH] D127277: [clang][analyzer] Fix StdLibraryFunctionsChecker 'mkdir' return value.

2022-06-23 Thread Balázs Kéri 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 rG7dc81c624433: [clang][analyzer] Fix 
StdLibraryFunctionsChecker 'mkdir' return value. (authored by 
balazske).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127277

Files:
  clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp


Index: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
@@ -1904,44 +1904,40 @@
 ArgumentCondition(1, WithinRange, Range(0, SizeMax;
 
 // int mkdir(const char *pathname, mode_t mode);
-// FIXME: returns 0 on success, ReturnsValidFileDescriptor is incorrect
 addToFunctionSummaryMap(
 "mkdir", Signature(ArgTypes{ConstCharPtrTy, Mode_tTy}, RetType{IntTy}),
 Summary(NoEvalCall)
-.Case(ReturnsValidFileDescriptor, ErrnoMustNotBeChecked)
+.Case(ReturnsZero, ErrnoMustNotBeChecked)
 .Case(ReturnsMinusOne, ErrnoNEZeroIrrelevant)
 .ArgConstraint(NotNull(ArgNo(0;
 
 // int mkdirat(int dirfd, const char *pathname, mode_t mode);
-// FIXME: returns 0 on success, ReturnsValidFileDescriptor is incorrect
 addToFunctionSummaryMap(
 "mkdirat",
 Signature(ArgTypes{IntTy, ConstCharPtrTy, Mode_tTy}, RetType{IntTy}),
 Summary(NoEvalCall)
-.Case(ReturnsValidFileDescriptor, ErrnoMustNotBeChecked)
+.Case(ReturnsZero, ErrnoMustNotBeChecked)
 .Case(ReturnsMinusOne, ErrnoNEZeroIrrelevant)
 .ArgConstraint(NotNull(ArgNo(1;
 
 Optional Dev_tTy = lookupTy("dev_t");
 
 // int mknod(const char *pathname, mode_t mode, dev_t dev);
-// FIXME: returns 0 on success, ReturnsValidFileDescriptor is incorrect
 addToFunctionSummaryMap(
 "mknod",
 Signature(ArgTypes{ConstCharPtrTy, Mode_tTy, Dev_tTy}, RetType{IntTy}),
 Summary(NoEvalCall)
-.Case(ReturnsValidFileDescriptor, ErrnoMustNotBeChecked)
+.Case(ReturnsZero, ErrnoMustNotBeChecked)
 .Case(ReturnsMinusOne, ErrnoNEZeroIrrelevant)
 .ArgConstraint(NotNull(ArgNo(0;
 
 // int mknodat(int dirfd, const char *pathname, mode_t mode, dev_t dev);
-// FIXME: returns 0 on success, ReturnsValidFileDescriptor is incorrect
 addToFunctionSummaryMap(
 "mknodat",
 Signature(ArgTypes{IntTy, ConstCharPtrTy, Mode_tTy, Dev_tTy},
   RetType{IntTy}),
 Summary(NoEvalCall)
-.Case(ReturnsValidFileDescriptor, ErrnoMustNotBeChecked)
+.Case(ReturnsZero, ErrnoMustNotBeChecked)
 .Case(ReturnsMinusOne, ErrnoNEZeroIrrelevant)
 .ArgConstraint(NotNull(ArgNo(1;
 


Index: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
@@ -1904,44 +1904,40 @@
 ArgumentCondition(1, WithinRange, Range(0, SizeMax;
 
 // int mkdir(const char *pathname, mode_t mode);
-// FIXME: returns 0 on success, ReturnsValidFileDescriptor is incorrect
 addToFunctionSummaryMap(
 "mkdir", Signature(ArgTypes{ConstCharPtrTy, Mode_tTy}, RetType{IntTy}),
 Summary(NoEvalCall)
-.Case(ReturnsValidFileDescriptor, ErrnoMustNotBeChecked)
+.Case(ReturnsZero, ErrnoMustNotBeChecked)
 .Case(ReturnsMinusOne, ErrnoNEZeroIrrelevant)
 .ArgConstraint(NotNull(ArgNo(0;
 
 // int mkdirat(int dirfd, const char *pathname, mode_t mode);
-// FIXME: returns 0 on success, ReturnsValidFileDescriptor is incorrect
 addToFunctionSummaryMap(
 "mkdirat",
 Signature(ArgTypes{IntTy, ConstCharPtrTy, Mode_tTy}, RetType{IntTy}),
 Summary(NoEvalCall)
-.Case(ReturnsValidFileDescriptor, ErrnoMustNotBeChecked)
+.Case(ReturnsZero, ErrnoMustNotBeChecked)
 .Case(ReturnsMinusOne, ErrnoNEZeroIrrelevant)
 .ArgConstraint(NotNull(ArgNo(1;
 
 Optional Dev_tTy = lookupTy("dev_t");
 
 // int mknod(const char *pathname, mode_t mode, dev_t dev);
-// FIXME: returns 0 on success, ReturnsValidFileDescriptor is incorrect
 addToFunctionSummaryMap(
 "mknod",
 Signature(ArgTypes{ConstCharPtrTy, Mode_tTy, Dev_tTy}, RetType{IntTy}),
 Summary(NoEvalCall)
-.Case(ReturnsValidFileDescriptor, ErrnoMustNotBeChecked)
+.Case(ReturnsZero, ErrnoMustNotBeChecked)
 .Case(ReturnsMinusOne, ErrnoNEZeroIrrelev

[PATCH] D128415: [ARM] Add Support for Cortex-M85 r=MarkMurrayARM,dmgreen,tmatheson

2022-06-23 Thread Sam Elliott via Phabricator via cfe-commits
lenary created this revision.
lenary added reviewers: MarkMurrayARM, dmgreen, tmatheson.
Herald added subscribers: jdoerfert, hiraditya, kristof.beyls.
Herald added a project: All.
lenary requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

This patch adds support for Arm's Cortex-M85 CPU. The Cortex-M85 CPU is
an Arm v8.1m Mainline CPU, with optional support for MVE and PACBTI. MVE
is enabled by default, but PACBTI is not.

Parts have been coauthored by by Mark Murray, Alexandros Lamprineas and
David Green.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D128415

Files:
  clang/docs/ReleaseNotes.rst
  clang/test/CodeGen/arm-target-features.c
  clang/test/Driver/arm-cortex-cpus-2.c
  clang/test/Driver/arm-nofp-disabled-features.c
  clang/test/Misc/target-invalid-cpu-note.c
  llvm/docs/ReleaseNotes.rst
  llvm/include/llvm/Support/ARMTargetParser.def
  llvm/lib/Target/ARM/ARM.td
  llvm/test/CodeGen/ARM/build-attributes.ll
  llvm/unittests/Support/TargetParserTest.cpp

Index: llvm/unittests/Support/TargetParserTest.cpp
===
--- llvm/unittests/Support/TargetParserTest.cpp
+++ llvm/unittests/Support/TargetParserTest.cpp
@@ -395,13 +395,18 @@
  ARM::AEK_FP | ARM::AEK_RAS | ARM::AEK_LOB |
  ARM::AEK_FP16,
  "8.1-M.Mainline"),
+ARMCPUTestParams("cortex-m85", "armv8.1-m.main", "fp-armv8-fullfp16-d16",
+ ARM::AEK_HWDIVTHUMB | ARM::AEK_DSP | ARM::AEK_SIMD |
+ ARM::AEK_FP | ARM::AEK_RAS | ARM::AEK_LOB |
+ ARM::AEK_FP16,
+ "8.1-M.Mainline"),
 ARMCPUTestParams("iwmmxt", "iwmmxt", "none", ARM::AEK_NONE, "iwmmxt"),
 ARMCPUTestParams("xscale", "xscale", "none", ARM::AEK_NONE, "xscale"),
 ARMCPUTestParams("swift", "armv7s", "neon-vfpv4",
  ARM::AEK_HWDIVARM | ARM::AEK_HWDIVTHUMB | ARM::AEK_DSP,
  "7-S")));
 
-static constexpr unsigned NumARMCPUArchs = 88;
+static constexpr unsigned NumARMCPUArchs = 89;
 
 TEST(TargetParserTest, testARMCPUArchList) {
   SmallVector List;
Index: llvm/test/CodeGen/ARM/build-attributes.ll
===
--- llvm/test/CodeGen/ARM/build-attributes.ll
+++ llvm/test/CodeGen/ARM/build-attributes.ll
@@ -235,6 +235,7 @@
 ; RUN: llc < %s -mtriple=thumbv8.1m.main-none-none-eabi -mattr=+mve.fp | FileCheck %s --check-prefix=ARMv81M-MAIN-MVEFP
 ; RUN: llc < %s -mtriple=thumbv8.1m.main-none-none-eabi -mattr=+pacbti | FileCheck %s --check-prefix=ARMv81M-MAIN-PACBTI
 ; RUN: llc < %s -mtriple=arm-none-none-eabi -mcpu=cortex-m55 | FileCheck %s --check-prefix=CORTEX-M55
+; RUN: llc < %s -mtriple=arm-none-none-eabi -mcpu=cortex-m85 | FileCheck %s --check-prefix=CORTEX-M85
 
 ; CPU-SUPPORTED-NOT: is not a recognized processor for this target
 
@@ -1748,6 +1749,19 @@
 ; CORTEX-M55: .eabi_attribute 38, 1
 ; CORTEX-M55: .eabi_attribute 14, 0
 
+; CORTEX-M85: .cpu cortex-m85
+; CORTEX-M85: .eabi_attribute 6, 21   @ Tag_CPU_arch
+; CORTEX-M85: .eabi_attribute 7, 77   @ Tag_CPU_arch_profile
+; CORTEX-M85: .eabi_attribute 8, 0@ Tag_ARM_ISA_use
+; CORTEX-M85: .eabi_attribute 9, 3@ Tag_THUMB_ISA_use
+; CORTEX-M85: .fpufpv5-d16
+; CORTEX-M85: .eabi_attribute 36, 1   @ Tag_FP_HP_extension
+; CORTEX-M85: .eabi_attribute 48, 2   @ Tag_MVE_arch
+; CORTEX-M85: .eabi_attribute 46, 1   @ Tag_DSP_extension
+; CORTEX-M85: .eabi_attribute 34, 1   @ Tag_CPU_unaligned_access
+; CORTEX-M85-NOT: .eabi_attribute 50
+; CORTEX-M85-NOT: .eabi_attribute 52
+
 define i32 @f(i64 %z) {
 ret i32 0
 }
Index: llvm/lib/Target/ARM/ARM.td
===
--- llvm/lib/Target/ARM/ARM.td
+++ llvm/lib/Target/ARM/ARM.td
@@ -1440,6 +1440,12 @@
  HasMVEFloatOps,
  FeatureFixCMSE_CVE_2021_35465]>;
 
+def : ProcessorModel<"cortex-m85", CortexM4Model,   [ARMv81mMainline,
+ FeatureDSP,
+ FeatureFPARMv8_D16,
+ FeatureUseMISched,
+ HasMVEFloatOps]>;
+
 def : ProcNoItin<"cortex-a32",   [ARMv8a,
  FeatureHWDivThumb,
  FeatureHWDivARM,
Index: llvm/include/llvm/Support/ARMTargetParser.def
===
--- llvm/include/llvm/Support/ARMTargetParser.def
+++ llvm/include/llvm/Support/ARMTargetParser.def
@@ -303,6 +303,8 @@

[clang] 8ef6280 - [analyzer] Structured binding to arrays

2022-06-23 Thread via cfe-commits

Author: isuckatcs
Date: 2022-06-23T11:38:21+02:00
New Revision: 8ef628088b54aebd4a8317ce3a0029e3283b3aa0

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

LOG: [analyzer] Structured binding to arrays

Introducing structured binding to data members and more.
To handle binding to arrays, ArrayInitLoopExpr is also
evaluated, which enables the analyzer to store information
in two more cases. These are:
  - when a lambda-expression captures an array by value
  - in the implicit copy/move constructor for a class
with an array member

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

Added: 
clang/test/Analysis/array-init-loop.cpp
clang/test/Analysis/uninit-structured-binding-array.cpp

Modified: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
clang/lib/StaticAnalyzer/Core/ExprEngine.cpp

Removed: 




diff  --git 
a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h 
b/clang/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
index 3787f8f01b34e..415fa05586edf 100644
--- a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
+++ b/clang/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
@@ -444,6 +444,10 @@ class ExprEngine {
   ///  other functions that handle specific kinds of statements.
   void Visit(const Stmt *S, ExplodedNode *Pred, ExplodedNodeSet &Dst);
 
+  /// VisitArrayInitLoopExpr - Transfer function for array init loop.
+  void VisitArrayInitLoopExpr(const ArrayInitLoopExpr *Ex, ExplodedNode *Pred,
+  ExplodedNodeSet &Dst);
+
   /// VisitArraySubscriptExpr - Transfer function for array accesses.
   void VisitArraySubscriptExpr(const ArraySubscriptExpr *Ex,
ExplodedNode *Pred,

diff  --git a/clang/lib/StaticAnalyzer/Core/ExprEngine.cpp 
b/clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
index 6ba19d52488c7..b4837cb95e183 100644
--- a/clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
+++ b/clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
@@ -1363,10 +1363,14 @@ void ExprEngine::Visit(const Stmt *S, ExplodedNode 
*Pred,
   break;
 }
 
+case Stmt::ArrayInitLoopExprClass:
+  Bldr.takeNodes(Pred);
+  VisitArrayInitLoopExpr(cast(S), Pred, Dst);
+  Bldr.addNodes(Dst);
+  break;
 // Cases not handled yet; but will handle some day.
 case Stmt::DesignatedInitExprClass:
 case Stmt::DesignatedInitUpdateExprClass:
-case Stmt::ArrayInitLoopExprClass:
 case Stmt::ArrayInitIndexExprClass:
 case Stmt::ExtVectorElementExprClass:
 case Stmt::ImaginaryLiteralClass:
@@ -2594,18 +2598,38 @@ void ExprEngine::VisitCommonDeclRefExpr(const Expr *Ex, 
const NamedDecl *D,
   if (const auto *BD = dyn_cast(D)) {
 const auto *DD = cast(BD->getDecomposedDecl());
 
+SVal Base = state->getLValue(DD, LCtx);
+if (DD->getType()->isReferenceType()) {
+  Base = state->getSVal(Base.getAsRegion());
+}
+
+SVal V = UnknownVal();
+
+// Handle binding to data members
 if (const auto *ME = dyn_cast(BD->getBinding())) {
   const auto *Field = cast(ME->getMemberDecl());
+  V = state->getLValue(Field, Base);
+}
+// Handle binding to arrays
+else if (const auto *ASE = dyn_cast(BD->getBinding())) 
{
+  SVal Idx = state->getSVal(ASE->getIdx(), LCtx);
 
-  SVal Base = state->getLValue(DD, LCtx);
-  if (DD->getType()->isReferenceType()) {
-Base = state->getSVal(Base.getAsRegion());
-  }
-
-  SVal V = state->getLValue(Field, Base);
+  // Note: the index of an element in a structured binding is automatically
+  // created and it is a unique identifier of the specific element. Thus it
+  // cannot be a value that varies at runtime.
+  assert(Idx.isConstant() && "BindingDecl array index is not a constant!");
 
-  Bldr.generateNode(Ex, Pred, state->BindExpr(Ex, LCtx, V));
+  V = state->getLValue(BD->getType(), Idx, Base);
 }
+// Handle binding to tuple-like strcutures
+else if (BD->getHoldingVar()) {
+  // FIXME: handle tuples
+  return;
+} else
+  llvm_unreachable("An unknown case of structured binding encountered!");
+
+Bldr.generateNode(Ex, Pred, state->BindExpr(Ex, LCtx, V), nullptr,
+  ProgramPoint::PostLValueKind);
 
 return;
   }
@@ -2613,6 +2637,99 @@ void ExprEngine::VisitCommonDeclRefExpr(const Expr *Ex, 
const NamedDecl *D,
   llvm_unreachable("Support for this Decl not implemented.");
 }
 
+/// VisitArrayInitLoopExpr - Transfer function for array init loop.
+void ExprEngine::VisitArrayInitLoopExpr(const ArrayInitLoopExpr *Ex,
+ExplodedNode *Pred,
+ExplodedNodeSet &Dst) {
+  ExplodedNodeSet Check

[PATCH] D126613: [Static Analyzer] Structured binding to arrays

2022-06-23 Thread Domján Dániel via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG8ef628088b54: [analyzer] Structured binding to arrays 
(authored by isuckatcs).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126613

Files:
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
  clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
  clang/test/Analysis/array-init-loop.cpp
  clang/test/Analysis/uninit-structured-binding-array.cpp

Index: clang/test/Analysis/uninit-structured-binding-array.cpp
===
--- /dev/null
+++ clang/test/Analysis/uninit-structured-binding-array.cpp
@@ -0,0 +1,294 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection -std=c++17 -verify %s
+
+void clang_analyzer_eval(bool);
+
+void array_value_a(void) {
+  int arr[2];
+  auto [a, b] = arr;
+  arr[0] = 0;
+
+  int x = a; // expected-warning{{Assigned value is garbage or undefined}}
+}
+
+void array_value_b(void) {
+  int arr[] = {1, 2};
+  auto [a, b] = arr;
+
+  clang_analyzer_eval(a == 1); // expected-warning{{TRUE}}
+  clang_analyzer_eval(b == 2); // expected-warning{{TRUE}}
+
+  int x = a; // no-warning
+}
+
+void array_value_c(void) {
+  int arr[3];
+
+  arr[1] = 1;
+
+  auto [a, b, c] = arr;
+
+  clang_analyzer_eval(b == arr[1]); // expected-warning{{TRUE}}
+
+  int y = b; // no-warning
+  int x = a; // expected-warning{{Assigned value is garbage or undefined}}
+}
+
+void array_value_d(void) {
+  int arr[3];
+
+  arr[1] = 1;
+
+  auto [a, b, c] = arr;
+
+  clang_analyzer_eval(b == arr[1]); // expected-warning{{TRUE}}
+
+  int y = b; // no-warning
+  int x = c; // expected-warning{{Assigned value is garbage or undefined}}
+}
+
+void array_value_e(void) {
+  int uninit[2];
+  int init[2] = {0};
+
+  uninit[0] = init[0];
+
+  auto [i, j] = init;
+
+  clang_analyzer_eval(i == 0); // expected-warning{{TRUE}}
+  clang_analyzer_eval(j == 0); // expected-warning{{TRUE}}
+
+  int a = i; // no-warning
+  int b = j; // no-warning
+}
+
+void array_value_f(void) {
+  int uninit[2];
+  int init[2] = {0};
+
+  uninit[0] = init[0];
+
+  auto [i, j] = uninit;
+
+  clang_analyzer_eval(i == 0); // expected-warning{{TRUE}}
+
+  int a = i; // no-warning
+  int b = j; // expected-warning{{Assigned value is garbage or undefined}}
+}
+
+void array_lref_a(void) {
+  int arr[2];
+  auto &[a, b] = arr;
+  int x = a; // expected-warning{{Assigned value is garbage or undefined}}
+}
+
+void array_lref_b(void) {
+  int arr[] = {1, 2};
+  auto &[a, b] = arr;
+
+  clang_analyzer_eval(a == 1); // expected-warning{{TRUE}}
+  clang_analyzer_eval(b == 2); // expected-warning{{TRUE}}
+
+  int x = a; // no-warning
+}
+
+void array_lref_c(void) {
+  int arr[2];
+  auto &[a, b] = arr;
+
+  arr[0] = 1;
+
+  clang_analyzer_eval(a == 1); // expected-warning{{TRUE}}
+
+  int x = a; // no-warning
+  int y = b; // expected-warning{{Assigned value is garbage or undefined}}
+}
+
+void array_lref_d(void) {
+  int arr[3];
+
+  arr[1] = 1;
+
+  auto &[a, b, c] = arr;
+
+  clang_analyzer_eval(b == 1); // expected-warning{{TRUE}}
+
+  int y = b; // no-warning
+  int x = a; // expected-warning{{Assigned value is garbage or undefined}}
+}
+
+void array_lref_e(void) {
+  int arr[3];
+
+  arr[1] = 1;
+
+  auto &[a, b, c] = arr;
+
+  clang_analyzer_eval(b == 1); // expected-warning{{TRUE}}
+
+  int y = b; // no-warning
+  int x = c; // expected-warning{{Assigned value is garbage or undefined}}
+}
+
+void array_lref_f(void) {
+  int uninit[2];
+  int init[2] = {0};
+
+  uninit[0] = init[0];
+
+  auto &[i, j] = init;
+
+  clang_analyzer_eval(i == 0); // expected-warning{{TRUE}}
+  clang_analyzer_eval(j == 0); // expected-warning{{TRUE}}
+
+  int a = i; // no-warning
+  int b = j; // no-warning
+}
+
+void array_lref_g(void) {
+  int uninit[2];
+  int init[2] = {0};
+
+  uninit[0] = init[0];
+
+  auto &[i, j] = uninit;
+
+  clang_analyzer_eval(i == 0); // expected-warning{{TRUE}}
+
+  int a = i; // no-warning
+  int b = j; // expected-warning{{Assigned value is garbage or undefined}}
+}
+
+void array_rref_a(void) {
+  int arr[2];
+  auto &&[a, b] = arr;
+  int x = a; // expected-warning{{Assigned value is garbage or undefined}}
+}
+
+void array_rref_b(void) {
+  int arr[] = {1, 2};
+  auto &&[a, b] = arr;
+
+  clang_analyzer_eval(a == 1); // expected-warning{{TRUE}}
+  clang_analyzer_eval(b == 2); // expected-warning{{TRUE}}
+
+  int x = a; // no-warning
+}
+
+void array_rref_c(void) {
+  int arr[2];
+  auto &&[a, b] = arr;
+
+  arr[0] = 1;
+
+  clang_analyzer_eval(a == 1); // expected-warning{{TRUE}}
+
+  int x = a; // no-warning
+  int y = b; // expected-warning{{Assigned value is garbage or undefined}}
+}
+
+void array_rref_d(void) {
+  int arr[3];
+
+  arr[1] = 1;
+
+  auto &&[a, b, c] = arr;
+
+  clang_analyzer_eval(b == 1); // expecte

[PATCH] D128157: [clang-tidy] cppcoreguidelines-virtual-class-destructor: Fix crash when "virtual" keyword is expanded from a macro

2022-06-23 Thread Joachim Priesner via Phabricator via cfe-commits
jspam updated this revision to Diff 439300.
jspam added a comment.

Rebased


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128157

Files:
  clang-tools-extra/clang-tidy/cppcoreguidelines/VirtualClassDestructorCheck.cpp
  
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/virtual-class-destructor.cpp


Index: 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/virtual-class-destructor.cpp
===
--- 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/virtual-class-destructor.cpp
+++ 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/virtual-class-destructor.cpp
@@ -272,6 +272,7 @@
 } // namespace Bugzilla_51912
 
 namespace macro_tests {
+#define MY_VIRTUAL virtual
 #define CONCAT(x, y) x##y
 
 // CHECK-MESSAGES: :[[@LINE+2]]:7: warning: destructor of 'FooBar1' is 
protected and virtual [cppcoreguidelines-virtual-class-destructor]
@@ -317,8 +318,17 @@
 protected:
   XMACRO(CONCAT(vir, tual), ~CONCAT(Foo, Bar5());) // no-crash, no-fixit
 };
+
+// CHECK-MESSAGES: :[[@LINE+2]]:7: warning: destructor of 'FooBar6' is 
protected and virtual [cppcoreguidelines-virtual-class-destructor]
+// CHECK-MESSAGES: :[[@LINE+1]]:7: note: make it protected and non-virtual
+class FooBar6 {
+protected:
+  MY_VIRTUAL ~FooBar6(); // FIXME: We should have a fixit for this.
+};
+
 #undef XMACRO
 #undef CONCAT
+#undef MY_VIRTUAL
 } // namespace macro_tests
 
 namespace FinalClassCannotBeBaseClass {
Index: 
clang-tools-extra/clang-tidy/cppcoreguidelines/VirtualClassDestructorCheck.cpp
===
--- 
clang-tools-extra/clang-tidy/cppcoreguidelines/VirtualClassDestructorCheck.cpp
+++ 
clang-tools-extra/clang-tidy/cppcoreguidelines/VirtualClassDestructorCheck.cpp
@@ -54,13 +54,17 @@
 return None;
 
   SourceLocation VirtualBeginLoc = Destructor.getBeginLoc();
-  SourceLocation VirtualEndLoc = VirtualBeginLoc.getLocWithOffset(
-  Lexer::MeasureTokenLength(VirtualBeginLoc, SM, LangOpts));
+  SourceLocation VirtualBeginSpellingLoc =
+  SM.getSpellingLoc(Destructor.getBeginLoc());
+  SourceLocation VirtualEndLoc = VirtualBeginSpellingLoc.getLocWithOffset(
+  Lexer::MeasureTokenLength(VirtualBeginSpellingLoc, SM, LangOpts));
 
   /// Range ends with \c StartOfNextToken so that any whitespace after \c
   /// virtual is included.
-  SourceLocation StartOfNextToken =
-  Lexer::findNextToken(VirtualEndLoc, SM, LangOpts)->getLocation();
+  Optional NextToken = Lexer::findNextToken(VirtualEndLoc, SM, 
LangOpts);
+  if (!NextToken)
+return None;
+  SourceLocation StartOfNextToken = NextToken->getLocation();
 
   return CharSourceRange::getCharRange(VirtualBeginLoc, StartOfNextToken);
 }


Index: clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/virtual-class-destructor.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/virtual-class-destructor.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/virtual-class-destructor.cpp
@@ -272,6 +272,7 @@
 } // namespace Bugzilla_51912
 
 namespace macro_tests {
+#define MY_VIRTUAL virtual
 #define CONCAT(x, y) x##y
 
 // CHECK-MESSAGES: :[[@LINE+2]]:7: warning: destructor of 'FooBar1' is protected and virtual [cppcoreguidelines-virtual-class-destructor]
@@ -317,8 +318,17 @@
 protected:
   XMACRO(CONCAT(vir, tual), ~CONCAT(Foo, Bar5());) // no-crash, no-fixit
 };
+
+// CHECK-MESSAGES: :[[@LINE+2]]:7: warning: destructor of 'FooBar6' is protected and virtual [cppcoreguidelines-virtual-class-destructor]
+// CHECK-MESSAGES: :[[@LINE+1]]:7: note: make it protected and non-virtual
+class FooBar6 {
+protected:
+  MY_VIRTUAL ~FooBar6(); // FIXME: We should have a fixit for this.
+};
+
 #undef XMACRO
 #undef CONCAT
+#undef MY_VIRTUAL
 } // namespace macro_tests
 
 namespace FinalClassCannotBeBaseClass {
Index: clang-tools-extra/clang-tidy/cppcoreguidelines/VirtualClassDestructorCheck.cpp
===
--- clang-tools-extra/clang-tidy/cppcoreguidelines/VirtualClassDestructorCheck.cpp
+++ clang-tools-extra/clang-tidy/cppcoreguidelines/VirtualClassDestructorCheck.cpp
@@ -54,13 +54,17 @@
 return None;
 
   SourceLocation VirtualBeginLoc = Destructor.getBeginLoc();
-  SourceLocation VirtualEndLoc = VirtualBeginLoc.getLocWithOffset(
-  Lexer::MeasureTokenLength(VirtualBeginLoc, SM, LangOpts));
+  SourceLocation VirtualBeginSpellingLoc =
+  SM.getSpellingLoc(Destructor.getBeginLoc());
+  SourceLocation VirtualEndLoc = VirtualBeginSpellingLoc.getLocWithOffset(
+  Lexer::MeasureTokenLength(VirtualBeginSpellingLoc, SM, LangOpts));
 
   /// Range ends with \c StartOfNextToken so that any whitespace after \c
   /// virtual is included.
-  SourceLocation StartOfNextToken =
-  Lexer

[PATCH] D128328: [C++20][Modules] Improve handing of Private Module Fragment diagnostics.

2022-06-23 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu added a comment.

In D128328#3604110 , @iains wrote:

> In D128328#3603980 , @ChuanqiXu 
> wrote:
>
>> 
>
>
>
 Also, **if** [module.private.frag]p2.1 is changed into:

> the point by which the definition of an [exported] inline function or 
> variable is required

 The test above would cover this too.

 BTW, it shows we could lack test like:

   export module A;
   [export] inline void func(); // no definition in the definition domain
>>>
>>> I think the current impl. should catch that - the only difference would be 
>>> that, in the case there's a definition in the PMF, there would be a note 
>>> about the unreachable definition.
>>
>> It looks like the current impl doesn't catch this: 
>> https://godbolt.org/z/fh9Ehfdj5 . I think I don't make mistake this time 
>> since a function declaration without function body shouldn't be a definition.
>
> Right, that should be an error - we do not have a test for it. 
> ActOnEndOfTranslationUnitFragment should be called with "Kind 
> =TUFragmentKind::Normal" whether there us a PMF or not.
> https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/Sema.cpp#L1131

I don't understand the intention of the suggestion. I feel like the current one 
looks right.

> so - modulo the underlying question about 'export' we probably just need a 
> second test-case

Agreed.

> (we could still defer the processing to the end of the TU and implement the 
> error messages as suggested by @vsapsai )

Oh, the intention of your suggestion is to implement the suggestion by 
@vsapsai, right? If it is, I would like to suggest to move the processing of 
PendingInlineExports  to ActOnEndOfTranslationUnit instead of change the 
argument of ActOnEndOfTranslationUnitFragment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128328

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


[PATCH] D128097: [Clang] Fix compile time regression caused by D126061.

2022-06-23 Thread Dawid Jurczak via Phabricator via cfe-commits
yurai007 added a comment.

Disclaimer: I'm not front-end guy.

After running 7zip benchmark under perf and comparing origin (7acc88be031 
) with fix 
(0d300da799b0 
) 
following diff can be seen:

Instructions change  |  Symbol
+0.12% | clang::Preprocessor::getMacroDefinition 
+0.07% | GetDeclSpecTypeForDeclarator 
+0.04% | clang::Parser::ParseDirectDeclarator 
+0.03% | clang::Sema::ActOnFunctionDeclarator 
+0.03% | clang::Sema::ProcessDeclAttributes

In 8c7b64b5ae2a 
 commit 
those 2 code changes catch my eyes as (maybe) relevant to above perf diff:

1. Change in Parser::ParseDeclGroup. That function looks quite heavy and it's 
caller of ParseDirectDeclarator/ActOnFunctionDeclarator (and even 
getMacroDefinition?)
2. Change in GetDeclSpecTypeForDeclarator. After 8c7b64b5ae2a 
 
distributeTypeAttrsFromDeclarator is called unconditionally which maybe matters.

Hope it helps a bit in finding proper solution for slowdown.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128097

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


[PATCH] D125669: Adding support for target in_reduction

2022-06-23 Thread Ritanya via Phabricator via cfe-commits
RitanyaB marked an inline comment as done.
RitanyaB added a comment.

In D125669#3599134 , @ABataev wrote:

> What about the description? Shall we still emit ` if(0)`?

Can you please elaborate for more clarity?




Comment at: clang/lib/CodeGen/CGStmtOpenMP.cpp:5035-5039
+llvm::APInt TrueOrFalse(32,
+S.hasClausesOfKind() ? 0 : 
1);
+IntegerLiteral IfCond(getContext(), TrueOrFalse,
+  getContext().getIntTypeForBitwidth(32, /*Signed=*/0),
+  SourceLocation());

ABataev wrote:
> Why integer, not a boolean? Also, this is currently meaningless, since these 
> 2 vars are not visible outside of the if context.
Thank you for the suggestion. I have removed the if block. 


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

https://reviews.llvm.org/D125669

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


[clang] 6f258c0 - [Clang] Don't test register allocation

2022-06-23 Thread Nikita Popov via cfe-commits

Author: Nikita Popov
Date: 2022-06-23T12:46:00+02:00
New Revision: 6f258c0fd34cf4001ffa08c61f6e4e0f1254c50f

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

LOG: [Clang] Don't test register allocation

This test was broken by 719658d078c4093d1ee716fb65ae94673df7b22b.

How did an assembly test get into clang/test?

Added: 


Modified: 
clang/test/CodeGenCUDA/atomics-remarks-gfx90a.cu

Removed: 




diff  --git a/clang/test/CodeGenCUDA/atomics-remarks-gfx90a.cu 
b/clang/test/CodeGenCUDA/atomics-remarks-gfx90a.cu
index 96892286fd75e..946927d88a1ee 100644
--- a/clang/test/CodeGenCUDA/atomics-remarks-gfx90a.cu
+++ b/clang/test/CodeGenCUDA/atomics-remarks-gfx90a.cu
@@ -9,7 +9,7 @@
 
 // GFX90A-CAS: A compare and swap loop was generated for an atomic fadd 
operation at system memory scope
 // GFX90A-CAS-LABEL: _Z14atomic_add_casPf
-// GFX90A-CAS:  flat_atomic_cmpswap v0, v[2:3], v[4:5] glc
+// GFX90A-CAS:  flat_atomic_cmpswap
 // GFX90A-CAS:  s_cbranch_execnz
 __device__ float atomic_add_cas(float *p) {
   return __atomic_fetch_add(p, 1.0f, memory_order_relaxed);



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


[PATCH] D125669: Adding support for target in_reduction

2022-06-23 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

In D125669#3604302 , @RitanyaB wrote:

> In D125669#3599134 , @ABataev wrote:
>
>> What about the description? Shall we still emit ` if(0)`?
>
> Can you please elaborate for more clarity?

The description of the patch 
So, this

#pragma omp target in_reduction(+:res)

  for (int i=0; ihttps://reviews.llvm.org/D125669/new/

https://reviews.llvm.org/D125669

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


[PATCH] D128409: [clang-cl] Add -emit-ast to clang-cl driver

2022-06-23 Thread Hans Wennborg via Phabricator via cfe-commits
hans added a comment.

I'm unfamiliar with -emit-ast. Can you add some background on what this is for? 
What's CTU?

In any case this needs a test.




Comment at: clang/include/clang/Driver/Options.td:834
 def Xoffload_linker : JoinedAndSeparate<["-"], "Xoffload-linker">,
-  HelpText<"Pass  to the offload linkers or the ones idenfied by 
-">, 
+  HelpText<"Pass  to the offload linkers or the ones idenfied by 
-">,
   MetaVarName<" ">, Group;

thieta wrote:
> Whops. My editor strikes again and removes a trailing space. Let me know if I 
> should edit this out of this commit.
Yes please. (Or land it separately.)



Comment at: clang/lib/Driver/Driver.cpp:5629
+  if ((JA.getType() == types::TY_Object || JA.getType() == types::TY_LTO_BC ||
+   JA.getType() == types::TY_AST || JA.getType() == types::TY_Plist) &&
   C.getArgs().hasArg(options::OPT__SLASH_Fo, options::OPT__SLASH_o)) {

thieta wrote:
> I do wonder if this limitation here is really wanted. It makes clang-cl 
> behave a bit different from clang/clang++. I can also split this part out in 
> it's own commit if we feel like it's necessary.
What limitation are you referring to?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128409

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


[PATCH] D127803: Generate the capture for field when the field is used in openmp region with implicit default in the member function.

2022-06-23 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added inline comments.



Comment at: clang/lib/Sema/SemaExprMember.cpp:1873-1877
+if (auto *PrivateCopy =
+isOpenMPFDCaptureDecl(Field, Base.get(), IsArrow, OpLoc, &SS,
+  /*TemplateKWLoc=*/SourceLocation(), Field,
+  FoundDecl, /*HadMultipleCandidates=*/false,
+  MemberNameInfo, MemberType, VK, OK))

jyu2 wrote:
> ABataev wrote:
> > Why do we need this function? Implicit private rule should apply (if 
> > should) only to this-Юашдув kind of expressions, if something like 
> > parent.field expression is used, parent should be private, not 
> > private.field. Or I'm missing something?
> You are right for "parent.a" only privatize "parent".
> 
> But if 'a' is a field access in a member function then 'a' is privatized, not 
> "this".  It is same with firstprivate(a).  But for the explicit 
> firstprivate(a), the capture is build in ActOnOpenMPFirstprivateClause, so it 
> can be mapped to reference in the omp region.  For Implicit, I need to build 
> capture for the first reference in the omp region with defalut(first|private) 
> is used.  And used that to generate firstprivate clause at end when the call 
> to ActOnOpenMPFirstprivateClause when generating implicit clause.
> 
> Is this reasonable?
But you don't need all this info to build the capture. I think you can reuse 
existing isOpenMPCapturedDecl function without adding this extra 
isOpenMPFDCaptureDecl. Most probably, you don't need Base and all other stuff 
to build this->fd member expression.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127803

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


[PATCH] D128256: [Clang][AArch64] Limit arm_locally_streaming to function definitions only.

2022-06-23 Thread Sander de Smalen via Phabricator via cfe-commits
sdesmalen added inline comments.



Comment at: clang/lib/Sema/SemaDecl.cpp:9835-9839
+  if (D.isFunctionDefinition()) {
+NewFD->setWillHaveBody();
+ProcessDeclAttributes(S, NewFD, D);
+NewFD->setWillHaveBody(false);
+  } else

aaron.ballman wrote:
> This seems like a hack to work around what feels like a bug -- if the 
> declarator knows the function is a definition, then why does the 
> `FunctionDecl` AST node claim the function won't have a body? It seems 
> strange to me that we don't set that bit when acting on the function 
> declarator but instead wait until we're acting on the start of the function 
> definition to set it; does anything break if you start setting that flag 
> earlier?
> This seems like a hack to work around what feels like a bug -- if the 
> declarator knows the function is a definition, then why does the FunctionDecl 
> AST node claim the function won't have a body?
I agree it is a bit of a workaround, I wasn't sure if it was a bug or by 
design, but there are several places in the codebase that are invoked after 
this point that seem to depend on the fact that `willHaveBody` has not been set 
to determine if something is a redeclaration.

For example, setting NewFD->setWillHaveBody() to `true` if 
`D.isFunctionDefinition()`, causes the following test to fail:

```template 
struct pair {
  T1 first;
  T2 second;

  pair() : first(), second() {}
  pair(const T1 &a, const T2 &b) : first(a), second(b) {}

  template
  pair(const pair &other) : first(other.first),
second(other.second) {}
};
```

I did some digging to see if I could fix this some other way, but didn't spot 
any easy ways to do this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128256

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


[clang-tools-extra] e36535f - Fix sphinx build for clang-tools-extra

2022-06-23 Thread Aaron Ballman via cfe-commits

Author: Aaron Ballman
Date: 2022-06-23T07:22:00-04:00
New Revision: e36535f99cd4caa3773089a60eee26ad535a923d

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

LOG: Fix sphinx build for clang-tools-extra

I think it doesn't like the non-ASCII characters in the block, so using
a text block to disable syntax highlighting.

This should fix:
https://lab.llvm.org/buildbot/#/builders/115/builds/29888

Added: 


Modified: 
clang-tools-extra/docs/clang-tidy/checks/misc/confusable-identifiers.rst

Removed: 




diff  --git 
a/clang-tools-extra/docs/clang-tidy/checks/misc/confusable-identifiers.rst 
b/clang-tools-extra/docs/clang-tidy/checks/misc/confusable-identifiers.rst
index 5a89212ae9ab0..b6d3e9981acf9 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/misc/confusable-identifiers.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/misc/confusable-identifiers.rst
@@ -9,7 +9,7 @@ attack described in `CVE-2021-42574 


[PATCH] D127762: [Clang][AArch64] Add ACLE attributes for SME.

2022-06-23 Thread Sander de Smalen via Phabricator via cfe-commits
sdesmalen updated this revision to Diff 439330.
sdesmalen marked 7 inline comments as done.
sdesmalen added a comment.

- Limited attribute to GNU spelling __attribute__((...))
- Changed `arm_locally_streaming` attribute to be `DeclOrStmtAttr` because it 
does not apply to type (only the definition)
- Changed the other SME attributes to be `TypeAttr`.
- Added checks and new tests for conflicting attributes on redeclarations
- Added checks and new tests for conflicting attributes on virtual function 
overrides
- Added new tests for propagation of type attributes on other declarations 
using `decltype(otherty)`


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

https://reviews.llvm.org/D127762

Files:
  clang/include/clang/AST/Type.h
  clang/include/clang/AST/TypeProperties.td
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Basic/Targets/AArch64.h
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CodeGen/aarch64-sme-intrinsics/aarch64-sme-attrs.cpp
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  clang/test/Sema/aarch64-sme-attrs-no-sme.c
  clang/test/Sema/aarch64-sme-func-attrs.c

Index: clang/test/Sema/aarch64-sme-func-attrs.c
===
--- /dev/null
+++ clang/test/Sema/aarch64-sme-func-attrs.c
@@ -0,0 +1,251 @@
+// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sme -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sme -fsyntax-only -verify=expected-cpp -x c++ %s
+
+// Valid attributes
+
+__attribute__((arm_streaming)) void sme_arm_streaming(void);
+__attribute__((arm_streaming_compatible)) void sme_arm_streaming_compatible(void);
+
+__attribute__((arm_new_za)) void sme_arm_new_za(void);
+__attribute__((arm_shared_za)) void sme_arm_shared_za(void);
+__attribute__((arm_preserves_za)) void sme_arm_preserves_za(void);
+
+__attribute__((arm_streaming, arm_new_za)) void sme_arm_streaming_new_za(void);
+__attribute__((arm_streaming, arm_shared_za)) void sme_arm_streaming_shared_za(void);
+__attribute__((arm_streaming, arm_preserves_za)) void sme_arm_streaming_preserves_za(void);
+
+__attribute__((arm_streaming_compatible, arm_new_za)) void sme_arm_sc_new_za(void);
+__attribute__((arm_streaming_compatible, arm_shared_za)) void sme_arm_sc_shared_za(void);
+__attribute__((arm_streaming_compatible, arm_preserves_za)) void sme_arm_sc_preserves_za(void);
+
+__attribute__((arm_shared_za, arm_preserves_za)) void sme_arm_shared_preserves_za(void);
+
+__attribute__((arm_locally_streaming)) void sme_arm_locally_streaming(void) { }
+__attribute__((arm_locally_streaming, arm_streaming)) void sme_arm_streaming_and_locally_streaming(void) { }
+__attribute__((arm_locally_streaming, arm_streaming_compatible)) void sme_arm_streaming_and_streaming_compatible(void) { }
+
+__attribute__((arm_locally_streaming, arm_new_za)) void sme_arm_ls_new_za(void) { }
+__attribute__((arm_locally_streaming, arm_shared_za)) void sme_arm_ls_shared_za(void) { }
+__attribute__((arm_locally_streaming, arm_preserves_za)) void sme_arm_ls_preserves_za(void) { }
+
+// Valid attributes on function pointers
+
+void __attribute__((arm_streaming)) streaming_ptr(void);
+typedef __attribute__((arm_streaming)) void (*fptrty1) (void);
+fptrty1 call_streaming_func() { return streaming_ptr; }
+
+void __attribute__((arm_streaming_compatible)) streaming_compatible_ptr(void);
+typedef __attribute__((arm_streaming_compatible)) void (*fptrty2) (void);
+fptrty2 call_sc_func() { return streaming_compatible_ptr; }
+
+void __attribute__((arm_new_za)) new_za_ptr(void);
+typedef __attribute__((arm_new_za)) void (*fptrty3) (void);
+fptrty3 call_new_za_func() { return new_za_ptr; }
+
+void __attribute__((arm_shared_za)) shared_za_ptr(void);
+typedef __attribute__((arm_shared_za)) void (*fptrty4) (void);
+fptrty4 call_shared_za_func() { return shared_za_ptr; }
+
+void __attribute__((arm_preserves_za)) preserves_za_ptr(void);
+typedef __attribute__((arm_preserves_za)) void (*fptrty5) (void);
+fptrty5 call_preserve_za_func() { return preserves_za_ptr; }
+
+void __attribute__((arm_shared_za, arm_preserves_za)) shared_preserves_za_ptr(void);
+typedef __attribute__((arm_shared_za, arm_preserves_za)) void (*fptrty6) (void);
+fptrty6 call_shared_preserve_za_func() { return shared_preserves_za_ptr; }
+
+typedef void (*fptrty7) (void);
+fptrty7 cast_ls_func_to_normal() { return sme_arm_locally_streaming; }
+
+// FIXME: Add invalid function pointer assignments such as assigning:
+//   1. A streaming compatible function to a normal func

[PATCH] D127762: [Clang][AArch64] Add ACLE attributes for SME.

2022-06-23 Thread Sander de Smalen via Phabricator via cfe-commits
sdesmalen added inline comments.



Comment at: clang/include/clang/Basic/Attr.td:2322
 
+def ArmStreamingCompatible : DeclOrTypeAttr, TargetSpecificAttr 
{
+  let Spellings = [Clang<"arm_streaming_compatible">];

aaron.ballman wrote:
> sdesmalen wrote:
> > aaron.ballman wrote:
> > > `DeclOrTypeAttr` is only intended to be used for attributes which were 
> > > historically a declaration attribute but are semantically type attributes 
> > > (like calling conventions). It seems to me that each of these is purely a 
> > > type attribute and we shouldn't allow them to be written in the 
> > > declaration position. WDYT?
> > In this case, I believe the attribute is valid on both the type and the 
> > declaration, because the SME ACLE explicitly specifies that the attributes 
> > can be applied to both declarations and types.
> > 
> > The 
> > [[https://github.com/ARM-software/acle/pull/188/commits/ce878cf6c43fd824ffc634526e5dfec1ddc1839e#diff-516526d4a18101dc85300bc2033d0f86dc46c505b7510a7694baabea851aedfaR8283-R8294|specification]]
> >  says:
> > ```Some of the attributes described in this section apply to function types.
> > Their semantics are as follows:
> > 
> > *   If the attribute is attached to a function declaration or definition,
> > it applies to the type of the function.
> > 
> > *   If the attribute is attached to a function type, it applies to that 
> > type.
> > 
> > *   If the attribute is attached to a pointer to a function type, it applies
> > to that function type.
> > 
> > *   Otherwise, the attribute is [ill-formed](#ill-formed).```
> > In this case, I believe the attribute is valid on both the type and the 
> > declaration, because the SME ACLE explicitly specifies that the attributes 
> > can be applied to both declarations and types.
> 
> What are the chances that can change? Because there are problems here:
> 
> > If the attribute is attached to a function declaration or definition, it 
> > applies to the type of the function.
> 
> This is egregiously opposed to the design of `[[]]` attributes in both C and 
> C++. We came up with `DeclOrTypeAttr` for attributes that previously existed, 
> but that is different than introducing new attributes. It's par for the 
> course for `__attribute__` style attributes, so I don't worry so much there.
> 
> What's the rationale for this confusing of a design? (e.g., is there some 
> reason you basically have to do that, like historically accepting the 
> attributes in both positions?)
The attribute must always apply to the type of the function, because we can't 
have the streaming-property (or the properties on ZA) being lost between 
function overrides or function pointer assignments. It's perhaps similar to a 
calling convention, because the caller may have to set up streaming- or ZA 
state before the call, and restore state after the call.

I'm not too familiar with the different spellings/syntaxes and their 
implications, so I've now limited the attribute to `GNU` style attributes 
(`__attribute__((..))`) and to being a `TypeAttr`, with the exception of the 
`arm_locally_streaming` attribute, because that one can only be applied to 
function definitions and is not part of the type.

I've also added some new tests to ensure the properties are correctly 
propagated (using `decltype()`) and tests to ensure virtual function overloads 
require the same attributes.

Is this a step in the right direction? :)



Comment at: clang/lib/Sema/SemaType.cpp:7676
+  return false;
+}
+

aaron.ballman wrote:
> sdesmalen wrote:
> > aaron.ballman wrote:
> > > Unfortunately, type attributes do not yet have any of the automated 
> > > checking generated by tablegen, so there are no calls to 
> > > `Sema::checkCommonAttributeFeatures()`, which means you have to manually 
> > > check things like mutual exclusions, not accepting arguments, etc.
> > After some experimenting I found that:
> > * When I add the `MutualExclusions` to Attr.td and compile `typedef 
> > __attribute__((arm_streaming, arm_streaming_compatible)) void (*ptrty1) 
> > (void);`, I still get the diagnostic for conflicting attributes 'for free', 
> > even without any code being added here to check for conflicting attributes. 
> > However, when I then apply it to a declaration (e.g. `void 
> > __attribute__((arm_streaming, arm_streaming_compatible)) foo(void);`), I 
> > get the diagnostics twice.
> > * When I add some code here to mark the attribute as invalid, I get no 
> > diagnostic whatsoever unless I explicitly emit it here, rendering the use 
> > of `MutualExclusions` in Attr.td ineffective.
> > 
> > Based on the above observation, I've chosen to keep the code in 
> > SemaDeclAttr.cpp and not use the `MutualExclusions`, because it generates 
> > the best diagnostics (an error + a note) and only emits it once. Let me 
> > know what you think.
> Yeah, I can see why we'd hit that problem -- when we go to form the function 

[clang] cdc59e2 - [tbaa] Handle base classes in struct tbaa

2022-06-23 Thread Jeroen Dobbelaere via cfe-commits

Author: Bruno De Fraine
Date: 2022-06-23T13:39:49+02:00
New Revision: cdc59e2202c11a6a5dfd2ec83531523c58eaae45

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

LOG: [tbaa] Handle base classes in struct tbaa

This is a fix for the miscompilation reported in 
https://github.com/llvm/llvm-project/issues/55384

Not adding a new test case since existing test cases already cover base classes 
(including new-struct-path tbaa).

Reviewed By: jeroen.dobbelaere

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

Added: 


Modified: 
clang/lib/CodeGen/CodeGenTBAA.cpp
clang/test/CodeGen/tbaa-class.cpp
clang/unittests/CodeGen/TBAAMetadataTest.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CodeGenTBAA.cpp 
b/clang/lib/CodeGen/CodeGenTBAA.cpp
index 95763d8e18b70..2904bd5a244fe 100644
--- a/clang/lib/CodeGen/CodeGenTBAA.cpp
+++ b/clang/lib/CodeGen/CodeGenTBAA.cpp
@@ -336,6 +336,30 @@ llvm::MDNode *CodeGenTBAA::getBaseTypeInfoHelper(const 
Type *Ty) {
 const RecordDecl *RD = TTy->getDecl()->getDefinition();
 const ASTRecordLayout &Layout = Context.getASTRecordLayout(RD);
 SmallVector Fields;
+if (const CXXRecordDecl *CXXRD = dyn_cast(RD)) {
+  // Handle C++ base classes. Non-virtual bases can treated a a kind of
+  // field. Virtual bases are more complex and omitted, but avoid an
+  // incomplete view for NewStructPathTBAA.
+  if (CodeGenOpts.NewStructPathTBAA && CXXRD->getNumVBases() != 0)
+return BaseTypeMetadataCache[Ty] = nullptr;
+  for (const CXXBaseSpecifier &B : CXXRD->bases()) {
+if (B.isVirtual())
+  continue;
+QualType BaseQTy = B.getType();
+const CXXRecordDecl *BaseRD = BaseQTy->getAsCXXRecordDecl();
+if (BaseRD->isEmpty())
+  continue;
+llvm::MDNode *TypeNode = isValidBaseType(BaseQTy)
+ ? getBaseTypeInfo(BaseQTy)
+ : getTypeInfo(BaseQTy);
+if (!TypeNode)
+  return BaseTypeMetadataCache[Ty] = nullptr;
+uint64_t Offset = Layout.getBaseClassOffset(BaseRD).getQuantity();
+uint64_t Size = Context.getTypeSizeInChars(BaseQTy).getQuantity();
+Fields.push_back(
+llvm::MDBuilder::TBAAStructField(Offset, Size, TypeNode));
+  }
+}
 for (FieldDecl *Field : RD->fields()) {
   if (Field->isZeroSize(Context) || Field->isUnnamedBitfield())
 continue;

diff  --git a/clang/test/CodeGen/tbaa-class.cpp 
b/clang/test/CodeGen/tbaa-class.cpp
index 7f413a6f323c2..38558b0415a7a 100644
--- a/clang/test/CodeGen/tbaa-class.cpp
+++ b/clang/test/CodeGen/tbaa-class.cpp
@@ -222,7 +222,7 @@ uint32_t g12(StructC *C, StructD *D, uint64_t count) {
 // OLD-PATH: [[TYPE_S]] = !{!"_ZTS7StructS", [[TYPE_SHORT]], i64 0, 
[[TYPE_INT]], i64 4}
 // OLD-PATH: [[TAG_S_f16]] = !{[[TYPE_S]], [[TYPE_SHORT]], i64 0}
 // OLD-PATH: [[TAG_S2_f32_2]] = !{[[TYPE_S2:!.*]], [[TYPE_INT]], i64 12}
-// OLD-PATH: [[TYPE_S2]] = !{!"_ZTS8StructS2", [[TYPE_SHORT]], i64 8, 
[[TYPE_INT]], i64 12}
+// OLD-PATH: [[TYPE_S2]] = !{!"_ZTS8StructS2", [[TYPE_S]], i64 0, 
[[TYPE_SHORT]], i64 8, [[TYPE_INT]], i64 12}
 // OLD-PATH: [[TAG_C_b_a_f32]] = !{[[TYPE_C:!.*]], [[TYPE_INT]], i64 12}
 // OLD-PATH: [[TYPE_C]] = !{!"_ZTS7StructC", [[TYPE_SHORT]], i64 0, 
[[TYPE_B]], i64 4, [[TYPE_INT]], i64 28}
 // OLD-PATH: [[TAG_D_b_a_f32]] = !{[[TYPE_D:!.*]], [[TYPE_INT]], i64 12}
@@ -244,7 +244,7 @@ uint32_t g12(StructC *C, StructD *D, uint64_t count) {
 // NEW-PATH: [[TYPE_S]] = !{[[TYPE_CHAR]], i64 8, !"_ZTS7StructS", 
[[TYPE_SHORT]], i64 0, i64 2, [[TYPE_INT]], i64 4, i64 4}
 // NEW-PATH: [[TAG_S_f16]] = !{[[TYPE_S]], [[TYPE_SHORT]], i64 0, i64 2}
 // NEW-PATH: [[TAG_S2_f32_2]] = !{[[TYPE_S2:!.*]], [[TYPE_INT]], i64 12, i64 4}
-// NEW-PATH: [[TYPE_S2]] = !{[[TYPE_CHAR]], i64 16, !"_ZTS8StructS2", 
[[TYPE_SHORT]], i64 8, i64 2, [[TYPE_INT]], i64 12, i64 4}
+// NEW-PATH: [[TYPE_S2]] = !{[[TYPE_CHAR]], i64 16, !"_ZTS8StructS2", 
[[TYPE_S]], i64 0, i64 8, [[TYPE_SHORT]], i64 8, i64 2, [[TYPE_INT]], i64 12, 
i64 4}
 // NEW-PATH: [[TAG_C_b_a_f32]] = !{[[TYPE_C:!.*]], [[TYPE_INT]], i64 12, i64 4}
 // NEW-PATH: [[TYPE_C]] = !{[[TYPE_CHAR]], i64 32, !"_ZTS7StructC", 
[[TYPE_SHORT]], i64 0, i64 2, [[TYPE_B]], i64 4, i64 24, [[TYPE_INT]], i64 28, 
i64 4}
 // NEW-PATH: [[TAG_D_b_a_f32]] = !{[[TYPE_D:!.*]], [[TYPE_INT]], i64 12, i64 4}

diff  --git a/clang/unittests/CodeGen/TBAAMetadataTest.cpp 
b/clang/unittests/CodeGen/TBAAMetadataTest.cpp
index 149a8e074b692..2919a35c8cedf 100644
--- a/clang/unittests/CodeGen/TBAAMetadataTest.cpp
+++ b/clang/unittests/CodeGen/TBAAMetadataTest.cpp
@@ -968,13 +968,10 @@ TEST(TBAAMetadataTest, BaseClass) {
   MConstInt(0)),
 MConstInt(0));
 
-  auto ClassDerived = MMTup

[PATCH] D126956: [tbaa] Handle base classes in struct tbaa

2022-06-23 Thread Jeroen Dobbelaere via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGcdc59e2202c1: [tbaa] Handle base classes in struct tbaa 
(authored by brunodf, committed by jeroen.dobbelaere).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126956

Files:
  clang/lib/CodeGen/CodeGenTBAA.cpp
  clang/test/CodeGen/tbaa-class.cpp
  clang/unittests/CodeGen/TBAAMetadataTest.cpp


Index: clang/unittests/CodeGen/TBAAMetadataTest.cpp
===
--- clang/unittests/CodeGen/TBAAMetadataTest.cpp
+++ clang/unittests/CodeGen/TBAAMetadataTest.cpp
@@ -968,13 +968,10 @@
   MConstInt(0)),
 MConstInt(0));
 
-  auto ClassDerived = MMTuple(
-MMString("_ZTS7Derived"),
-MMTuple(
-  MMString("short"),
-  OmnipotentCharCXX,
-  MConstInt(0)),
-MConstInt(4));
+  auto ClassDerived =
+  MMTuple(MMString("_ZTS7Derived"), ClassBase, MConstInt(0),
+  MMTuple(MMString("short"), OmnipotentCharCXX, MConstInt(0)),
+  MConstInt(4));
 
   const Instruction *I = match(BB,
   MInstruction(Instruction::Store,
@@ -1047,13 +1044,10 @@
   MConstInt(0)),
 MConstInt(Compiler.PtrSize));
 
-  auto ClassDerived = MMTuple(
-MMString("_ZTS7Derived"),
-MMTuple(
-  MMString("short"),
-  OmnipotentCharCXX,
-  MConstInt(0)),
-MConstInt(Compiler.PtrSize + 4));
+  auto ClassDerived =
+  MMTuple(MMString("_ZTS7Derived"), ClassBase, MConstInt(0),
+  MMTuple(MMString("short"), OmnipotentCharCXX, MConstInt(0)),
+  MConstInt(Compiler.PtrSize + 4));
 
   const Instruction *I = match(BB,
   MInstruction(Instruction::Store,
Index: clang/test/CodeGen/tbaa-class.cpp
===
--- clang/test/CodeGen/tbaa-class.cpp
+++ clang/test/CodeGen/tbaa-class.cpp
@@ -222,7 +222,7 @@
 // OLD-PATH: [[TYPE_S]] = !{!"_ZTS7StructS", [[TYPE_SHORT]], i64 0, 
[[TYPE_INT]], i64 4}
 // OLD-PATH: [[TAG_S_f16]] = !{[[TYPE_S]], [[TYPE_SHORT]], i64 0}
 // OLD-PATH: [[TAG_S2_f32_2]] = !{[[TYPE_S2:!.*]], [[TYPE_INT]], i64 12}
-// OLD-PATH: [[TYPE_S2]] = !{!"_ZTS8StructS2", [[TYPE_SHORT]], i64 8, 
[[TYPE_INT]], i64 12}
+// OLD-PATH: [[TYPE_S2]] = !{!"_ZTS8StructS2", [[TYPE_S]], i64 0, 
[[TYPE_SHORT]], i64 8, [[TYPE_INT]], i64 12}
 // OLD-PATH: [[TAG_C_b_a_f32]] = !{[[TYPE_C:!.*]], [[TYPE_INT]], i64 12}
 // OLD-PATH: [[TYPE_C]] = !{!"_ZTS7StructC", [[TYPE_SHORT]], i64 0, 
[[TYPE_B]], i64 4, [[TYPE_INT]], i64 28}
 // OLD-PATH: [[TAG_D_b_a_f32]] = !{[[TYPE_D:!.*]], [[TYPE_INT]], i64 12}
@@ -244,7 +244,7 @@
 // NEW-PATH: [[TYPE_S]] = !{[[TYPE_CHAR]], i64 8, !"_ZTS7StructS", 
[[TYPE_SHORT]], i64 0, i64 2, [[TYPE_INT]], i64 4, i64 4}
 // NEW-PATH: [[TAG_S_f16]] = !{[[TYPE_S]], [[TYPE_SHORT]], i64 0, i64 2}
 // NEW-PATH: [[TAG_S2_f32_2]] = !{[[TYPE_S2:!.*]], [[TYPE_INT]], i64 12, i64 4}
-// NEW-PATH: [[TYPE_S2]] = !{[[TYPE_CHAR]], i64 16, !"_ZTS8StructS2", 
[[TYPE_SHORT]], i64 8, i64 2, [[TYPE_INT]], i64 12, i64 4}
+// NEW-PATH: [[TYPE_S2]] = !{[[TYPE_CHAR]], i64 16, !"_ZTS8StructS2", 
[[TYPE_S]], i64 0, i64 8, [[TYPE_SHORT]], i64 8, i64 2, [[TYPE_INT]], i64 12, 
i64 4}
 // NEW-PATH: [[TAG_C_b_a_f32]] = !{[[TYPE_C:!.*]], [[TYPE_INT]], i64 12, i64 4}
 // NEW-PATH: [[TYPE_C]] = !{[[TYPE_CHAR]], i64 32, !"_ZTS7StructC", 
[[TYPE_SHORT]], i64 0, i64 2, [[TYPE_B]], i64 4, i64 24, [[TYPE_INT]], i64 28, 
i64 4}
 // NEW-PATH: [[TAG_D_b_a_f32]] = !{[[TYPE_D:!.*]], [[TYPE_INT]], i64 12, i64 4}
Index: clang/lib/CodeGen/CodeGenTBAA.cpp
===
--- clang/lib/CodeGen/CodeGenTBAA.cpp
+++ clang/lib/CodeGen/CodeGenTBAA.cpp
@@ -336,6 +336,30 @@
 const RecordDecl *RD = TTy->getDecl()->getDefinition();
 const ASTRecordLayout &Layout = Context.getASTRecordLayout(RD);
 SmallVector Fields;
+if (const CXXRecordDecl *CXXRD = dyn_cast(RD)) {
+  // Handle C++ base classes. Non-virtual bases can treated a a kind of
+  // field. Virtual bases are more complex and omitted, but avoid an
+  // incomplete view for NewStructPathTBAA.
+  if (CodeGenOpts.NewStructPathTBAA && CXXRD->getNumVBases() != 0)
+return BaseTypeMetadataCache[Ty] = nullptr;
+  for (const CXXBaseSpecifier &B : CXXRD->bases()) {
+if (B.isVirtual())
+  continue;
+QualType BaseQTy = B.getType();
+const CXXRecordDecl *BaseRD = BaseQTy->getAsCXXRecordDecl();
+if (BaseRD->isEmpty())
+  continue;
+llvm::MDNode *TypeNode = isValidBaseType(BaseQTy)
+ ? getBaseTypeInfo(BaseQTy)
+ : getTypeInfo(BaseQTy);
+if (!TypeNode)
+  return BaseTypeMetadataCache[Ty] = nullptr;
+uint64_t Offset = Layout.getBaseClassOffset(BaseRD).getQuantity();
+uint64_t Size = Context.getTypeSizeInChars(BaseQTy).getQua

[PATCH] D128299: [pseudo] Add a fast-path to GLR reduce when both pop and push are trivial

2022-06-23 Thread Haojian Wu via Phabricator via cfe-commits
hokein added inline comments.



Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:268
+  // However in trivial cases (only pop that yields only one push) we can
+  // bypass all these fancy queues and pop+push directly. This is very common.
+  auto PopAndPushTrivial = [&]() -> bool {

Thinking more about this, this trivial case seems to be triggered more often if 
we use a more powerful LR parsing algorithm -- a more powerful LR parser means 
less dead heads, and more linear cases.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128299

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


[PATCH] D113107: Support of expression granularity for _Float16.

2022-06-23 Thread Zahira Ammarguellat via Phabricator via cfe-commits
zahiraam added a comment.

In D113107#3603761 , @pengfei wrote:

>> Supporting the lowering in the backend is sensible in order to support 
>> -fexcess-precision=16, because I agree that the most reasonable IR output in 
>> that configuration is to simply generate half operations. But under 
>> -fexcess-precision=32, I do not want the frontend to be in the business of 
>> recognizing cases where promoted emission is unnecessary, because that is 
>> just a lot of extra complexity for something that's already fairly 
>> special-case logic; among other things, it will tend to hide bugs.
>
> Fair enough. I agree we should choose the easy way to go. Thanks for the 
> explanation!
>
>> So I think we should hold off on adding this option until we know what 
>> behavior we actually want to expose via it.
>
> I don't have strong opinion on the specific `-fexcess-precision` option, but 
> we do need an option to stop the promotion in the FE. Some user requires the 
> emulation to gets the identical result as running on real HW. How about we 
> make `EmitFloat16WithExcessPrecision` an Clang option and set it true by 
> default and false for feature `avx512fp16`?

That's fine be me.


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

https://reviews.llvm.org/D113107

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


[PATCH] D113107: Support of expression granularity for _Float16.

2022-06-23 Thread Zahira Ammarguellat via Phabricator via cfe-commits
zahiraam added a comment.

In D113107#3604048 , @pengfei wrote:

> @zahiraam, community requires to enable the `_Float16` support in FE, see 
> https://discourse.llvm.org/t/how-to-build-compiler-rt-for-new-x86-half-float-abi/63366
> Is there any blocking issue to land it soon? Otherwise, we can split the 
> changes in `X86.cpp`, `LanguageExtensions.rst`, `ReleaseNotes.rst` and some 
> tests from this patch and land them first.

I will wait for @JohnMCall


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

https://reviews.llvm.org/D113107

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


[PATCH] D128409: [clang-cl] Add -emit-ast to clang-cl driver

2022-06-23 Thread Tobias Hieta via Phabricator via cfe-commits
thieta added a comment.

In D128409#3604460 , @hans wrote:

> I'm unfamiliar with -emit-ast. Can you add some background on what this is 
> for? What's CTU?

CTU is cross translation unit. In this case the clang-static-analyzer can do 
analysis over several files - see the official docs that recommend that you 
build the .ast files with -emit-ast: 
https://clang.llvm.org/docs/analyzer/user-docs/CrossTranslationUnit.html#manual-ctu-analysis

> In any case this needs a test.

I can definitely add tests. What do you think needs a test here? that -emit-ast 
works the same with clang and clang-cl? Do we generally test the same arguments 
for all drivers even if they are expected to do the same thing?




Comment at: clang/lib/Driver/Driver.cpp:5629
+  if ((JA.getType() == types::TY_Object || JA.getType() == types::TY_LTO_BC ||
+   JA.getType() == types::TY_AST || JA.getType() == types::TY_Plist) &&
   C.getArgs().hasArg(options::OPT__SLASH_Fo, options::OPT__SLASH_o)) {

hans wrote:
> thieta wrote:
> > I do wonder if this limitation here is really wanted. It makes clang-cl 
> > behave a bit different from clang/clang++. I can also split this part out 
> > in it's own commit if we feel like it's necessary.
> What limitation are you referring to?
For the clang-cl options `/Fo` and `/o` we limit the exactly what should be 
written out to that file with TY_Object, TY_LTO_BC etc. But for the `-o` option 
we just dump everything with a few exceptions: 
https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/Driver.cpp#L5534

I haven't analyzed this method that carefully - but it seems like for most 
users using `/o` should be more or less analogous to `-o`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128409

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


[PATCH] D127448: [wip][pseudo] Implement guard extension.

2022-06-23 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

The ParseLang + CLI library seem clearly separate from everything else, I think 
this patch should be split.

Comments on that part first...




Comment at: clang-tools-extra/pseudo/benchmarks/Benchmark.cpp:68
   for (auto _ : State)
-LRTable::buildSLR(*G);
+LRTable::buildSLR(cli::getLanguage().G);
 }

getLanguage() should not be inside the loop. This is happening in a few places

Maybe it should stay in setupGrammarAndSource?



Comment at: clang-tools-extra/pseudo/include/clang-pseudo/Language.h:35
+struct ParseLang {
+  const Grammar &G;
+  const LRTable &Table;

why are these all references with ParseLang (presumably) passed by value, 
instead of values with ParseLang passed by reference?



Comment at: clang-tools-extra/pseudo/include/clang-pseudo/cli/CLI.h:24
+struct ParseLang;
+namespace cli {
+// Returns the corresponding language from the '--grammar' command-line flag.

nit: I don't think a namespace is needed here, compared to just 
`getLanguageFromFlags()`



Comment at: clang-tools-extra/pseudo/include/clang-pseudo/cli/CLI.h:26
+// Returns the corresponding language from the '--grammar' command-line flag.
+const ParseLang &getLanguage();
+} // namespace cli

either "language" is a clear enough name or it isn't - given naming elsewhere 
this should be getParseLang I think



Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:298
   auto Pop = [&](const GSS::Node *Head, RuleID RID) {
-LLVM_DEBUG(llvm::dbgs() << "  Pop " << Params.G.dumpRule(RID) << "\n");
-const auto &Rule = Params.G.lookupRule(RID);
+LLVM_DEBUG(llvm::dbgs() << "  Pop " << Params.Lang.G.dumpRule(RID) << 
"\n");
+const auto &Rule = Params.Lang.G.lookupRule(RID);

I'm not sure exactly what the best thing to do about this is, but 
`Params.Lang.G` is hard to read - it's a long complicated name that doesn't 
even name the thing.

I think probably we should split ParseParams up instead of nesting ParseLang in 
it, e.g.

```
struct GLRStorage { ForestArena&, GSS }
glrReduce(vector, const ParseLang&, GLStorage&, NewHeadCallback)
```

Or even put a forest pointer in the GSS just for convenience.



Comment at: clang-tools-extra/pseudo/lib/cli/CLI.cpp:52
+llvm::errs() << Diag << "\n";
+  std::exit(1);
+}

huh? diagnostics aren't fatal (at least haven't been considered so before)



Comment at: clang-tools-extra/pseudo/lib/cli/CLI.cpp:53
+  std::exit(1);
+}
+

"missing guard function" is probably a grammar diagnostic, maybe we should add 
some logic to validate extensions?
Probably a FIXME for now



Comment at: clang-tools-extra/pseudo/lib/cli/CLI.cpp:57-58
+llvm::DenseMap *Guards =
+new llvm::DenseMap();
+for (ExtensionID ID = 1; ID < G->table().AttributeValues.size(); ++ID)
+  Guards->insert(std::make_pair(ID, alwaysAccept));

I don't think the CLI library should be in charge of knowing the fallback logic 
for each type of extension.
Could the parser handle a missing guard itself instead?



Comment at: clang-tools-extra/pseudo/tool/ClangPseudo.cpp:94
 
-  if (Grammar.getNumOccurrences()) {
-std::string Text = readOrDie(Grammar);
-std::vector Diags;
-auto G = Grammar::parseBNF(Text, Diags);
-
-if (!Diags.empty()) {
-  llvm::errs() << llvm::join(Diags, "\n");
-  return 2;
-}
-llvm::outs() << llvm::formatv("grammar file {0} is parsed successfully\n",
-  Grammar);
+  if (true) {
+const auto &Lang = clang::pseudo::cli::getLanguage();

drop if(true)?



Comment at: clang-tools-extra/pseudo/unittests/GLRTest.cpp:51
   }
-
+  // FIXME: move to TokenStream class.
+  TokenStream emptyTokenStream() {

either do it or don't - this is too small to check in a fixme IMO



Comment at: clang-tools-extra/pseudo/unittests/GLRTest.cpp:57
+  }
+  ParseLang getTestLang() {
+return {*G, Table, Guards};

can this just be a member?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127448

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


[clang] b6a33ce - [NFC] remove trailing whitespace

2022-06-23 Thread Tobias Hieta via cfe-commits

Author: Tobias Hieta
Date: 2022-06-23T14:04:23+02:00
New Revision: b6a33cec3830b6c9ea35faf35b4a5889c22c6ae9

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

LOG: [NFC] remove trailing whitespace

Added: 


Modified: 
clang/include/clang/Driver/Options.td

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 4c0f0ada36547..c79b748acbfc0 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -831,7 +831,7 @@ def Xlinker : Separate<["-"], "Xlinker">, 
Flags<[LinkerInput, RenderAsInput]>,
   HelpText<"Pass  to the linker">, MetaVarName<"">,
   Group;
 def Xoffload_linker : JoinedAndSeparate<["-"], "Xoffload-linker">,
-  HelpText<"Pass  to the offload linkers or the ones idenfied by 
-">, 
+  HelpText<"Pass  to the offload linkers or the ones idenfied by 
-">,
   MetaVarName<" ">, Group;
 def Xpreprocessor : Separate<["-"], "Xpreprocessor">, 
Group,
   HelpText<"Pass  to the preprocessor">, MetaVarName<"">;



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


[PATCH] D112579: Allow non-variadic functions to be attributed with `__attribute__((format))`

2022-06-23 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D112579#3603629 , @fcloutier wrote:

> Would it be better if I asked a colleague to finish the review?

Typically, you should try to get a LG from the reviewers who have been active 
on the review in the past (assuming they're still active in the community now). 
So no -- It just takes a while because there's a lot of review work to be done 
and only so many hours in the day; sorry for the delays!

I think there are some missing changes to AttrDocs.td for the new 
functionality, and this should have a release note as well.




Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:4126
+def warn_gcc_requires_variadic_function : Warning<
+  "GCC requires functions with the %0 attribute to be variadic">,
+  InGroup;

Slight tweaks: `GCC requires a function with the 'format' attribute to be 
variadic`



Comment at: clang/lib/AST/FormatString.cpp:327
+  // format consumer. Apply decay before type comparison.
+  if (C.getAsArrayType(argTy) || argTy->isFunctionType())
+argTy = C.getDecayedType(argTy);

I think this should be:
```
if (argTy->canDecayToPointerType())
  argTy = C.getDecayedType(argTy);
```



Comment at: clang/lib/Sema/SemaChecking.cpp:5434-5440
+  if (Format->getFirstArg() == 0) {
+FSI->ArgPassingKind = FAPK_VAList;
+  } else if (IsVariadic) {
+FSI->ArgPassingKind = FAPK_Variadic;
+  } else {
+FSI->ArgPassingKind = FAPK_Fixed;
+  }

Elide braces here (coding style rule).



Comment at: clang/lib/Sema/SemaChecking.cpp:8622-8623
+  //
+  if (const ParmVarDecl *PV = dyn_cast(VD)) {
+if (const Decl *D = dyn_cast(PV->getDeclContext())) {
+  for (const auto *PVFormat : D->specific_attrs()) {

Can use `const auto *` in these cases.



Comment at: clang/lib/Sema/SemaChecking.cpp:8626
+bool IsCXXMember = false;
+if (const CXXMethodDecl *MD = dyn_cast(D))
+  IsCXXMember = MD->isInstance();

Same here.



Comment at: clang/lib/Sema/SemaChecking.cpp:8630-8631
+bool IsVariadic = false;
+if (const FunctionType *FnTy = D->getFunctionType())
+  IsVariadic = cast(FnTy)->isVariadic();
+else if (const auto *BD = dyn_cast(D))

A better way to write this would be:
```
if (const auto *FnTy = D->getType()->getAs())
  IsVariadic = FnTy->isVariadic();
...
```



Comment at: clang/lib/Sema/SemaChecking.cpp:10027
+  // format consumer. Apply decay before type comparison.
+  if (S.Context.getAsArrayType(ExprTy) || ExprTy->isFunctionType())
+ExprTy = S.Context.getDecayedType(ExprTy);

Same suggestion here as above to use `canDecayToPointerType()` instead.



Comment at: clang/lib/Sema/SemaDeclAttr.cpp:3881-3885
 if (isFunctionOrMethodVariadic(D)) {
   ++NumArgs; // +1 for ...
 } else {
-  S.Diag(D->getLocation(), diag::err_format_attribute_requires_variadic);
-  return;
+  S.Diag(D->getLocation(), diag::warn_gcc_requires_variadic_function) << 
AL;
 }

There's some braces you can elide here now.


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

https://reviews.llvm.org/D112579

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


[PATCH] D128409: [clang-cl] Add -emit-ast to clang-cl driver

2022-06-23 Thread Tobias Hieta via Phabricator via cfe-commits
thieta updated this revision to Diff 439341.
thieta added a comment.

Removed unintentional whitespace removal and landed that as a NFC


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128409

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/Driver.cpp


Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -5625,7 +5625,8 @@
   // Determine what the derived output name should be.
   const char *NamedOutput;
 
-  if ((JA.getType() == types::TY_Object || JA.getType() == types::TY_LTO_BC) &&
+  if ((JA.getType() == types::TY_Object || JA.getType() == types::TY_LTO_BC ||
+   JA.getType() == types::TY_AST || JA.getType() == types::TY_Plist) &&
   C.getArgs().hasArg(options::OPT__SLASH_Fo, options::OPT__SLASH_o)) {
 // The /Fo or /o flag decides the object filename.
 StringRef Val =
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -1091,7 +1091,7 @@
 def dynamic : Flag<["-"], "dynamic">, Flags<[NoArgumentUnused]>;
 def d_Flag : Flag<["-"], "d">, Group;
 def d_Joined : Joined<["-"], "d">, Group;
-def emit_ast : Flag<["-"], "emit-ast">,
+def emit_ast : Flag<["-"], "emit-ast">, Flags<[CoreOption]>,
   HelpText<"Emit Clang AST files for source inputs">;
 def emit_llvm : Flag<["-"], "emit-llvm">, Flags<[CC1Option, FC1Option, 
FlangOption]>, Group,
   HelpText<"Use the LLVM representation for assembler and object files">;


Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -5625,7 +5625,8 @@
   // Determine what the derived output name should be.
   const char *NamedOutput;
 
-  if ((JA.getType() == types::TY_Object || JA.getType() == types::TY_LTO_BC) &&
+  if ((JA.getType() == types::TY_Object || JA.getType() == types::TY_LTO_BC ||
+   JA.getType() == types::TY_AST || JA.getType() == types::TY_Plist) &&
   C.getArgs().hasArg(options::OPT__SLASH_Fo, options::OPT__SLASH_o)) {
 // The /Fo or /o flag decides the object filename.
 StringRef Val =
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -1091,7 +1091,7 @@
 def dynamic : Flag<["-"], "dynamic">, Flags<[NoArgumentUnused]>;
 def d_Flag : Flag<["-"], "d">, Group;
 def d_Joined : Joined<["-"], "d">, Group;
-def emit_ast : Flag<["-"], "emit-ast">,
+def emit_ast : Flag<["-"], "emit-ast">, Flags<[CoreOption]>,
   HelpText<"Emit Clang AST files for source inputs">;
 def emit_llvm : Flag<["-"], "emit-llvm">, Flags<[CC1Option, FC1Option, FlangOption]>, Group,
   HelpText<"Use the LLVM representation for assembler and object files">;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D128282: [WebAssembly] Update test to run it in opaque pointers mode

2022-06-23 Thread Paulo Matos via Phabricator via cfe-commits
pmatos updated this revision to Diff 439345.
pmatos added a comment.

Remove extraneous whitespace.
Make equal CHECK lines use WEBASSEMBLY:


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128282

Files:
  clang/test/CodeGen/builtins-wasm.c


Index: clang/test/CodeGen/builtins-wasm.c
===
--- clang/test/CodeGen/builtins-wasm.c
+++ clang/test/CodeGen/builtins-wasm.c
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -no-opaque-pointers -triple wasm32-unknown-unknown 
-target-feature +simd128 -target-feature +relaxed-simd -target-feature 
+nontrapping-fptoint -target-feature +exception-handling -target-feature 
+bulk-memory -target-feature +atomics -flax-vector-conversions=none -O3 
-emit-llvm -o - %s | FileCheck %s -check-prefixes WEBASSEMBLY,WEBASSEMBLY32
-// RUN: %clang_cc1 -no-opaque-pointers -triple wasm64-unknown-unknown 
-target-feature +simd128 -target-feature +relaxed-simd -target-feature 
+nontrapping-fptoint -target-feature +exception-handling -target-feature 
+bulk-memory -target-feature +atomics -flax-vector-conversions=none -O3 
-emit-llvm -o - %s | FileCheck %s -check-prefixes WEBASSEMBLY,WEBASSEMBLY64
-// RUN: not %clang_cc1 -no-opaque-pointers -triple wasm64-unknown-unknown 
-target-feature +nontrapping-fptoint -target-feature +exception-handling 
-target-feature +bulk-memory -target-feature +atomics 
-flax-vector-conversions=none -O3 -emit-llvm -o - %s 2>&1 | FileCheck %s 
-check-prefixes MISSING-SIMD
+// RUN: %clang_cc1 -triple wasm32-unknown-unknown -target-feature +simd128 
-target-feature +relaxed-simd -target-feature +nontrapping-fptoint 
-target-feature +exception-handling -target-feature +bulk-memory 
-target-feature +atomics -flax-vector-conversions=none -O3 -emit-llvm -o - %s | 
FileCheck %s -check-prefixes WEBASSEMBLY,WEBASSEMBLY32
+// RUN: %clang_cc1 -triple wasm64-unknown-unknown -target-feature +simd128 
-target-feature +relaxed-simd -target-feature +nontrapping-fptoint 
-target-feature +exception-handling -target-feature +bulk-memory 
-target-feature +atomics -flax-vector-conversions=none -O3 -emit-llvm -o - %s | 
FileCheck %s -check-prefixes WEBASSEMBLY,WEBASSEMBLY64
+// RUN: not %clang_cc1 -triple wasm64-unknown-unknown -target-feature 
+nontrapping-fptoint -target-feature +exception-handling -target-feature 
+bulk-memory -target-feature +atomics -flax-vector-conversions=none -O3 
-emit-llvm -o - %s 2>&1 | FileCheck %s -check-prefixes MISSING-SIMD
 
 // SIMD convenience types
 typedef signed char i8x16 __attribute((vector_size(16)));
@@ -40,13 +40,12 @@
 
 void *tls_base(void) {
   return __builtin_wasm_tls_base();
-  // WEBASSEMBLY: call i8* @llvm.wasm.tls.base()
+  // WEBASSEMBLY: call ptr @llvm.wasm.tls.base()
 }
 
 void throw(void *obj) {
   return __builtin_wasm_throw(0, obj);
-  // WEBASSEMBLY32: call void @llvm.wasm.throw(i32 0, i8* %{{.*}})
-  // WEBASSEMBLY64: call void @llvm.wasm.throw(i32 0, i8* %{{.*}})
+  // WEBASSEMBLY: call void @llvm.wasm.throw(i32 0, ptr %{{.*}})
 }
 
 void rethrow(void) {
@@ -57,20 +56,17 @@
 
 int memory_atomic_wait32(int *addr, int expected, long long timeout) {
   return __builtin_wasm_memory_atomic_wait32(addr, expected, timeout);
-  // WEBASSEMBLY32: call i32 @llvm.wasm.memory.atomic.wait32(i32* %{{.*}}, i32 
%{{.*}}, i64 %{{.*}})
-  // WEBASSEMBLY64: call i32 @llvm.wasm.memory.atomic.wait32(i32* %{{.*}}, i32 
%{{.*}}, i64 %{{.*}})
+  // WEBASSEMBLY: call i32 @llvm.wasm.memory.atomic.wait32(ptr %{{.*}}, i32 
%{{.*}}, i64 %{{.*}})
 }
 
 int memory_atomic_wait64(long long *addr, long long expected, long long 
timeout) {
   return __builtin_wasm_memory_atomic_wait64(addr, expected, timeout);
-  // WEBASSEMBLY32: call i32 @llvm.wasm.memory.atomic.wait64(i64* %{{.*}}, i64 
%{{.*}}, i64 %{{.*}})
-  // WEBASSEMBLY64: call i32 @llvm.wasm.memory.atomic.wait64(i64* %{{.*}}, i64 
%{{.*}}, i64 %{{.*}})
+  // WEBASSEMBLY: call i32 @llvm.wasm.memory.atomic.wait64(ptr %{{.*}}, i64 
%{{.*}}, i64 %{{.*}})
 }
 
 unsigned int memory_atomic_notify(int *addr, unsigned int count) {
   return __builtin_wasm_memory_atomic_notify(addr, count);
-  // WEBASSEMBLY32: call i32 @llvm.wasm.memory.atomic.notify(i32* %{{.*}}, i32 
%{{.*}})
-  // WEBASSEMBLY64: call i32 @llvm.wasm.memory.atomic.notify(i32* %{{.*}}, i32 
%{{.*}})
+  // WEBASSEMBLY: call i32 @llvm.wasm.memory.atomic.notify(ptr %{{.*}}, i32 
%{{.*}})
 }
 
 int trunc_s_i32_f32(float f) {


Index: clang/test/CodeGen/builtins-wasm.c
===
--- clang/test/CodeGen/builtins-wasm.c
+++ clang/test/CodeGen/builtins-wasm.c
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -no-opaque-pointers -triple wasm32-unknown-unknown -target-feature +simd128 -target-feature +relaxed-simd -target-feature +nontrapping-fptoint -target-feature +exception-handling -target-feature +bulk-memory -target-feature +atomics -flax-vector-conversions=none -O3 -emi

[clang] 0fdfeb0 - [WebAssembly] Update test to run it in opaque pointers mode

2022-06-23 Thread Paulo Matos via cfe-commits

Author: Paulo Matos
Date: 2022-06-23T14:16:33+02:00
New Revision: 0fdfeb0847dfbce9d5734f61c9fc16ed6f7dc17e

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

LOG: [WebAssembly] Update test to run it in opaque pointers mode

When opaque pointers was enabled, -no-opaque-pointers were added to some tests 
in order not to change behaviour. We now revert this and fix the test.

Reviewed By: asb, tlively

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

Added: 


Modified: 
clang/test/CodeGen/builtins-wasm.c

Removed: 




diff  --git a/clang/test/CodeGen/builtins-wasm.c 
b/clang/test/CodeGen/builtins-wasm.c
index d9ea753ee86a..ea591a195cad 100644
--- a/clang/test/CodeGen/builtins-wasm.c
+++ b/clang/test/CodeGen/builtins-wasm.c
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -no-opaque-pointers -triple wasm32-unknown-unknown 
-target-feature +simd128 -target-feature +relaxed-simd -target-feature 
+nontrapping-fptoint -target-feature +exception-handling -target-feature 
+bulk-memory -target-feature +atomics -flax-vector-conversions=none -O3 
-emit-llvm -o - %s | FileCheck %s -check-prefixes WEBASSEMBLY,WEBASSEMBLY32
-// RUN: %clang_cc1 -no-opaque-pointers -triple wasm64-unknown-unknown 
-target-feature +simd128 -target-feature +relaxed-simd -target-feature 
+nontrapping-fptoint -target-feature +exception-handling -target-feature 
+bulk-memory -target-feature +atomics -flax-vector-conversions=none -O3 
-emit-llvm -o - %s | FileCheck %s -check-prefixes WEBASSEMBLY,WEBASSEMBLY64
-// RUN: not %clang_cc1 -no-opaque-pointers -triple wasm64-unknown-unknown 
-target-feature +nontrapping-fptoint -target-feature +exception-handling 
-target-feature +bulk-memory -target-feature +atomics 
-flax-vector-conversions=none -O3 -emit-llvm -o - %s 2>&1 | FileCheck %s 
-check-prefixes MISSING-SIMD
+// RUN: %clang_cc1 -triple wasm32-unknown-unknown -target-feature +simd128 
-target-feature +relaxed-simd -target-feature +nontrapping-fptoint 
-target-feature +exception-handling -target-feature +bulk-memory 
-target-feature +atomics -flax-vector-conversions=none -O3 -emit-llvm -o - %s | 
FileCheck %s -check-prefixes WEBASSEMBLY,WEBASSEMBLY32
+// RUN: %clang_cc1 -triple wasm64-unknown-unknown -target-feature +simd128 
-target-feature +relaxed-simd -target-feature +nontrapping-fptoint 
-target-feature +exception-handling -target-feature +bulk-memory 
-target-feature +atomics -flax-vector-conversions=none -O3 -emit-llvm -o - %s | 
FileCheck %s -check-prefixes WEBASSEMBLY,WEBASSEMBLY64
+// RUN: not %clang_cc1 -triple wasm64-unknown-unknown -target-feature 
+nontrapping-fptoint -target-feature +exception-handling -target-feature 
+bulk-memory -target-feature +atomics -flax-vector-conversions=none -O3 
-emit-llvm -o - %s 2>&1 | FileCheck %s -check-prefixes MISSING-SIMD
 
 // SIMD convenience types
 typedef signed char i8x16 __attribute((vector_size(16)));
@@ -40,13 +40,12 @@ __SIZE_TYPE__ tls_align(void) {
 
 void *tls_base(void) {
   return __builtin_wasm_tls_base();
-  // WEBASSEMBLY: call i8* @llvm.wasm.tls.base()
+  // WEBASSEMBLY: call ptr @llvm.wasm.tls.base()
 }
 
 void throw(void *obj) {
   return __builtin_wasm_throw(0, obj);
-  // WEBASSEMBLY32: call void @llvm.wasm.throw(i32 0, i8* %{{.*}})
-  // WEBASSEMBLY64: call void @llvm.wasm.throw(i32 0, i8* %{{.*}})
+  // WEBASSEMBLY: call void @llvm.wasm.throw(i32 0, ptr %{{.*}})
 }
 
 void rethrow(void) {
@@ -57,20 +56,17 @@ void rethrow(void) {
 
 int memory_atomic_wait32(int *addr, int expected, long long timeout) {
   return __builtin_wasm_memory_atomic_wait32(addr, expected, timeout);
-  // WEBASSEMBLY32: call i32 @llvm.wasm.memory.atomic.wait32(i32* %{{.*}}, i32 
%{{.*}}, i64 %{{.*}})
-  // WEBASSEMBLY64: call i32 @llvm.wasm.memory.atomic.wait32(i32* %{{.*}}, i32 
%{{.*}}, i64 %{{.*}})
+  // WEBASSEMBLY: call i32 @llvm.wasm.memory.atomic.wait32(ptr %{{.*}}, i32 
%{{.*}}, i64 %{{.*}})
 }
 
 int memory_atomic_wait64(long long *addr, long long expected, long long 
timeout) {
   return __builtin_wasm_memory_atomic_wait64(addr, expected, timeout);
-  // WEBASSEMBLY32: call i32 @llvm.wasm.memory.atomic.wait64(i64* %{{.*}}, i64 
%{{.*}}, i64 %{{.*}})
-  // WEBASSEMBLY64: call i32 @llvm.wasm.memory.atomic.wait64(i64* %{{.*}}, i64 
%{{.*}}, i64 %{{.*}})
+  // WEBASSEMBLY: call i32 @llvm.wasm.memory.atomic.wait64(ptr %{{.*}}, i64 
%{{.*}}, i64 %{{.*}})
 }
 
 unsigned int memory_atomic_notify(int *addr, unsigned int count) {
   return __builtin_wasm_memory_atomic_notify(addr, count);
-  // WEBASSEMBLY32: call i32 @llvm.wasm.memory.atomic.notify(i32* %{{.*}}, i32 
%{{.*}})
-  // WEBASSEMBLY64: call i32 @llvm.wasm.memory.atomic.notify(i32* %{{.*}}, i32 
%{{.*}})
+  // WEBASSEMBLY: call i32 @llvm.wasm.memory.atomic.notify(ptr %{{.*}}, i32 
%{{.*}})
 }
 
 int trunc_s_i32_f32

[PATCH] D128282: [WebAssembly] Update test to run it in opaque pointers mode

2022-06-23 Thread Paulo Matos 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 rG0fdfeb0847df: [WebAssembly] Update test to run it in opaque 
pointers mode (authored by pmatos).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128282

Files:
  clang/test/CodeGen/builtins-wasm.c


Index: clang/test/CodeGen/builtins-wasm.c
===
--- clang/test/CodeGen/builtins-wasm.c
+++ clang/test/CodeGen/builtins-wasm.c
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -no-opaque-pointers -triple wasm32-unknown-unknown 
-target-feature +simd128 -target-feature +relaxed-simd -target-feature 
+nontrapping-fptoint -target-feature +exception-handling -target-feature 
+bulk-memory -target-feature +atomics -flax-vector-conversions=none -O3 
-emit-llvm -o - %s | FileCheck %s -check-prefixes WEBASSEMBLY,WEBASSEMBLY32
-// RUN: %clang_cc1 -no-opaque-pointers -triple wasm64-unknown-unknown 
-target-feature +simd128 -target-feature +relaxed-simd -target-feature 
+nontrapping-fptoint -target-feature +exception-handling -target-feature 
+bulk-memory -target-feature +atomics -flax-vector-conversions=none -O3 
-emit-llvm -o - %s | FileCheck %s -check-prefixes WEBASSEMBLY,WEBASSEMBLY64
-// RUN: not %clang_cc1 -no-opaque-pointers -triple wasm64-unknown-unknown 
-target-feature +nontrapping-fptoint -target-feature +exception-handling 
-target-feature +bulk-memory -target-feature +atomics 
-flax-vector-conversions=none -O3 -emit-llvm -o - %s 2>&1 | FileCheck %s 
-check-prefixes MISSING-SIMD
+// RUN: %clang_cc1 -triple wasm32-unknown-unknown -target-feature +simd128 
-target-feature +relaxed-simd -target-feature +nontrapping-fptoint 
-target-feature +exception-handling -target-feature +bulk-memory 
-target-feature +atomics -flax-vector-conversions=none -O3 -emit-llvm -o - %s | 
FileCheck %s -check-prefixes WEBASSEMBLY,WEBASSEMBLY32
+// RUN: %clang_cc1 -triple wasm64-unknown-unknown -target-feature +simd128 
-target-feature +relaxed-simd -target-feature +nontrapping-fptoint 
-target-feature +exception-handling -target-feature +bulk-memory 
-target-feature +atomics -flax-vector-conversions=none -O3 -emit-llvm -o - %s | 
FileCheck %s -check-prefixes WEBASSEMBLY,WEBASSEMBLY64
+// RUN: not %clang_cc1 -triple wasm64-unknown-unknown -target-feature 
+nontrapping-fptoint -target-feature +exception-handling -target-feature 
+bulk-memory -target-feature +atomics -flax-vector-conversions=none -O3 
-emit-llvm -o - %s 2>&1 | FileCheck %s -check-prefixes MISSING-SIMD
 
 // SIMD convenience types
 typedef signed char i8x16 __attribute((vector_size(16)));
@@ -40,13 +40,12 @@
 
 void *tls_base(void) {
   return __builtin_wasm_tls_base();
-  // WEBASSEMBLY: call i8* @llvm.wasm.tls.base()
+  // WEBASSEMBLY: call ptr @llvm.wasm.tls.base()
 }
 
 void throw(void *obj) {
   return __builtin_wasm_throw(0, obj);
-  // WEBASSEMBLY32: call void @llvm.wasm.throw(i32 0, i8* %{{.*}})
-  // WEBASSEMBLY64: call void @llvm.wasm.throw(i32 0, i8* %{{.*}})
+  // WEBASSEMBLY: call void @llvm.wasm.throw(i32 0, ptr %{{.*}})
 }
 
 void rethrow(void) {
@@ -57,20 +56,17 @@
 
 int memory_atomic_wait32(int *addr, int expected, long long timeout) {
   return __builtin_wasm_memory_atomic_wait32(addr, expected, timeout);
-  // WEBASSEMBLY32: call i32 @llvm.wasm.memory.atomic.wait32(i32* %{{.*}}, i32 
%{{.*}}, i64 %{{.*}})
-  // WEBASSEMBLY64: call i32 @llvm.wasm.memory.atomic.wait32(i32* %{{.*}}, i32 
%{{.*}}, i64 %{{.*}})
+  // WEBASSEMBLY: call i32 @llvm.wasm.memory.atomic.wait32(ptr %{{.*}}, i32 
%{{.*}}, i64 %{{.*}})
 }
 
 int memory_atomic_wait64(long long *addr, long long expected, long long 
timeout) {
   return __builtin_wasm_memory_atomic_wait64(addr, expected, timeout);
-  // WEBASSEMBLY32: call i32 @llvm.wasm.memory.atomic.wait64(i64* %{{.*}}, i64 
%{{.*}}, i64 %{{.*}})
-  // WEBASSEMBLY64: call i32 @llvm.wasm.memory.atomic.wait64(i64* %{{.*}}, i64 
%{{.*}}, i64 %{{.*}})
+  // WEBASSEMBLY: call i32 @llvm.wasm.memory.atomic.wait64(ptr %{{.*}}, i64 
%{{.*}}, i64 %{{.*}})
 }
 
 unsigned int memory_atomic_notify(int *addr, unsigned int count) {
   return __builtin_wasm_memory_atomic_notify(addr, count);
-  // WEBASSEMBLY32: call i32 @llvm.wasm.memory.atomic.notify(i32* %{{.*}}, i32 
%{{.*}})
-  // WEBASSEMBLY64: call i32 @llvm.wasm.memory.atomic.notify(i32* %{{.*}}, i32 
%{{.*}})
+  // WEBASSEMBLY: call i32 @llvm.wasm.memory.atomic.notify(ptr %{{.*}}, i32 
%{{.*}})
 }
 
 int trunc_s_i32_f32(float f) {


Index: clang/test/CodeGen/builtins-wasm.c
===
--- clang/test/CodeGen/builtins-wasm.c
+++ clang/test/CodeGen/builtins-wasm.c
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -no-opaque-pointers -triple wasm32-unknown-unknown -target-feature +simd128 -target-feature +relaxed-simd -target-feature +nontrapping-fptoint -target-feature +except

[clang] 8999b74 - Revert "[tbaa] Handle base classes in struct tbaa"

2022-06-23 Thread Jeroen Dobbelaere via cfe-commits

Author: Jeroen Dobbelaere
Date: 2022-06-23T14:18:49+02:00
New Revision: 8999b745bc4ecae5ac74f5c4d06f40e317ddb12c

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

LOG: Revert "[tbaa] Handle base classes in struct tbaa"

This reverts commit cdc59e2202c11a6a5dfd2ec83531523c58eaae45.

The Verifier finds a problem in a stage2 build. Reverting so Bruno can 
investigate.

Added: 


Modified: 
clang/lib/CodeGen/CodeGenTBAA.cpp
clang/test/CodeGen/tbaa-class.cpp
clang/unittests/CodeGen/TBAAMetadataTest.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CodeGenTBAA.cpp 
b/clang/lib/CodeGen/CodeGenTBAA.cpp
index 2904bd5a244f..95763d8e18b7 100644
--- a/clang/lib/CodeGen/CodeGenTBAA.cpp
+++ b/clang/lib/CodeGen/CodeGenTBAA.cpp
@@ -336,30 +336,6 @@ llvm::MDNode *CodeGenTBAA::getBaseTypeInfoHelper(const 
Type *Ty) {
 const RecordDecl *RD = TTy->getDecl()->getDefinition();
 const ASTRecordLayout &Layout = Context.getASTRecordLayout(RD);
 SmallVector Fields;
-if (const CXXRecordDecl *CXXRD = dyn_cast(RD)) {
-  // Handle C++ base classes. Non-virtual bases can treated a a kind of
-  // field. Virtual bases are more complex and omitted, but avoid an
-  // incomplete view for NewStructPathTBAA.
-  if (CodeGenOpts.NewStructPathTBAA && CXXRD->getNumVBases() != 0)
-return BaseTypeMetadataCache[Ty] = nullptr;
-  for (const CXXBaseSpecifier &B : CXXRD->bases()) {
-if (B.isVirtual())
-  continue;
-QualType BaseQTy = B.getType();
-const CXXRecordDecl *BaseRD = BaseQTy->getAsCXXRecordDecl();
-if (BaseRD->isEmpty())
-  continue;
-llvm::MDNode *TypeNode = isValidBaseType(BaseQTy)
- ? getBaseTypeInfo(BaseQTy)
- : getTypeInfo(BaseQTy);
-if (!TypeNode)
-  return BaseTypeMetadataCache[Ty] = nullptr;
-uint64_t Offset = Layout.getBaseClassOffset(BaseRD).getQuantity();
-uint64_t Size = Context.getTypeSizeInChars(BaseQTy).getQuantity();
-Fields.push_back(
-llvm::MDBuilder::TBAAStructField(Offset, Size, TypeNode));
-  }
-}
 for (FieldDecl *Field : RD->fields()) {
   if (Field->isZeroSize(Context) || Field->isUnnamedBitfield())
 continue;

diff  --git a/clang/test/CodeGen/tbaa-class.cpp 
b/clang/test/CodeGen/tbaa-class.cpp
index 38558b0415a7..7f413a6f323c 100644
--- a/clang/test/CodeGen/tbaa-class.cpp
+++ b/clang/test/CodeGen/tbaa-class.cpp
@@ -222,7 +222,7 @@ uint32_t g12(StructC *C, StructD *D, uint64_t count) {
 // OLD-PATH: [[TYPE_S]] = !{!"_ZTS7StructS", [[TYPE_SHORT]], i64 0, 
[[TYPE_INT]], i64 4}
 // OLD-PATH: [[TAG_S_f16]] = !{[[TYPE_S]], [[TYPE_SHORT]], i64 0}
 // OLD-PATH: [[TAG_S2_f32_2]] = !{[[TYPE_S2:!.*]], [[TYPE_INT]], i64 12}
-// OLD-PATH: [[TYPE_S2]] = !{!"_ZTS8StructS2", [[TYPE_S]], i64 0, 
[[TYPE_SHORT]], i64 8, [[TYPE_INT]], i64 12}
+// OLD-PATH: [[TYPE_S2]] = !{!"_ZTS8StructS2", [[TYPE_SHORT]], i64 8, 
[[TYPE_INT]], i64 12}
 // OLD-PATH: [[TAG_C_b_a_f32]] = !{[[TYPE_C:!.*]], [[TYPE_INT]], i64 12}
 // OLD-PATH: [[TYPE_C]] = !{!"_ZTS7StructC", [[TYPE_SHORT]], i64 0, 
[[TYPE_B]], i64 4, [[TYPE_INT]], i64 28}
 // OLD-PATH: [[TAG_D_b_a_f32]] = !{[[TYPE_D:!.*]], [[TYPE_INT]], i64 12}
@@ -244,7 +244,7 @@ uint32_t g12(StructC *C, StructD *D, uint64_t count) {
 // NEW-PATH: [[TYPE_S]] = !{[[TYPE_CHAR]], i64 8, !"_ZTS7StructS", 
[[TYPE_SHORT]], i64 0, i64 2, [[TYPE_INT]], i64 4, i64 4}
 // NEW-PATH: [[TAG_S_f16]] = !{[[TYPE_S]], [[TYPE_SHORT]], i64 0, i64 2}
 // NEW-PATH: [[TAG_S2_f32_2]] = !{[[TYPE_S2:!.*]], [[TYPE_INT]], i64 12, i64 4}
-// NEW-PATH: [[TYPE_S2]] = !{[[TYPE_CHAR]], i64 16, !"_ZTS8StructS2", 
[[TYPE_S]], i64 0, i64 8, [[TYPE_SHORT]], i64 8, i64 2, [[TYPE_INT]], i64 12, 
i64 4}
+// NEW-PATH: [[TYPE_S2]] = !{[[TYPE_CHAR]], i64 16, !"_ZTS8StructS2", 
[[TYPE_SHORT]], i64 8, i64 2, [[TYPE_INT]], i64 12, i64 4}
 // NEW-PATH: [[TAG_C_b_a_f32]] = !{[[TYPE_C:!.*]], [[TYPE_INT]], i64 12, i64 4}
 // NEW-PATH: [[TYPE_C]] = !{[[TYPE_CHAR]], i64 32, !"_ZTS7StructC", 
[[TYPE_SHORT]], i64 0, i64 2, [[TYPE_B]], i64 4, i64 24, [[TYPE_INT]], i64 28, 
i64 4}
 // NEW-PATH: [[TAG_D_b_a_f32]] = !{[[TYPE_D:!.*]], [[TYPE_INT]], i64 12, i64 4}

diff  --git a/clang/unittests/CodeGen/TBAAMetadataTest.cpp 
b/clang/unittests/CodeGen/TBAAMetadataTest.cpp
index 2919a35c8ced..149a8e074b69 100644
--- a/clang/unittests/CodeGen/TBAAMetadataTest.cpp
+++ b/clang/unittests/CodeGen/TBAAMetadataTest.cpp
@@ -968,10 +968,13 @@ TEST(TBAAMetadataTest, BaseClass) {
   MConstInt(0)),
 MConstInt(0));
 
-  auto ClassDerived =
-  MMTuple(MMString("_ZTS7Derived"), ClassBase, MConstInt(0),
-  MMTuple(MMString("short"), OmnipotentCharCXX, MConstInt(0)),
-  

[PATCH] D128409: [clang-cl] Add -emit-ast to clang-cl driver

2022-06-23 Thread Hans Wennborg via Phabricator via cfe-commits
hans added a comment.

In D128409#3604570 , @thieta wrote:

> In D128409#3604460 , @hans wrote:
>
>> I'm unfamiliar with -emit-ast. Can you add some background on what this is 
>> for? What's CTU?
>
> CTU is cross translation unit. In this case the clang-static-analyzer can do 
> analysis over several files - see the official docs that recommend that you 
> build the .ast files with -emit-ast: 
> https://clang.llvm.org/docs/analyzer/user-docs/CrossTranslationUnit.html#manual-ctu-analysis

Thanks! I wasn't aware of this.

>> In any case this needs a test.
>
> I can definitely add tests. What do you think needs a test here? that 
> -emit-ast works the same with clang and clang-cl? Do we generally test the 
> same arguments for all drivers even if they are expected to do the same thing?

I think we should just check that clang-cl accepts the flag and passes the 
right thing to the -cc1 invocation (including that we get the output file name 
right).




Comment at: clang/lib/Driver/Driver.cpp:5629
+  if ((JA.getType() == types::TY_Object || JA.getType() == types::TY_LTO_BC ||
+   JA.getType() == types::TY_AST || JA.getType() == types::TY_Plist) &&
   C.getArgs().hasArg(options::OPT__SLASH_Fo, options::OPT__SLASH_o)) {

thieta wrote:
> hans wrote:
> > thieta wrote:
> > > I do wonder if this limitation here is really wanted. It makes clang-cl 
> > > behave a bit different from clang/clang++. I can also split this part out 
> > > in it's own commit if we feel like it's necessary.
> > What limitation are you referring to?
> For the clang-cl options `/Fo` and `/o` we limit the exactly what should be 
> written out to that file with TY_Object, TY_LTO_BC etc. But for the `-o` 
> option we just dump everything with a few exceptions: 
> https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/Driver.cpp#L5534
> 
> I haven't analyzed this method that carefully - but it seems like for most 
> users using `/o` should be more or less analogous to `-o`?
For /Fe, /Fo we need to match MSVC's behavior, so I think we do need these 
different cases. Note that we also allow /o for TY_Image in the if-else further 
down.

Perhaps TY_AST and Plist should have its own case?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128409

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


[PATCH] D125094: [ARM][Thumb] Command-line option to ensure AAPCS compliant Frame Records

2022-06-23 Thread Lucas Prates via Phabricator via cfe-commits
pratlucas updated this revision to Diff 439356.
pratlucas added a comment.

Fixing use-after-poison issue detected by ASAN buildbot.

When popping LR on thumb it's value is popped into PC and used as a return.
The original return instruction gets erased, invalidating the MachineInstr
iterator. This change makes sure we don't try to access the iterator in these
conditions.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125094

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Arch/ARM.cpp
  llvm/lib/Target/ARM/ARM.td
  llvm/lib/Target/ARM/ARMBaseRegisterInfo.cpp
  llvm/lib/Target/ARM/ARMCallingConv.td
  llvm/lib/Target/ARM/ARMFrameLowering.cpp
  llvm/lib/Target/ARM/ARMFrameLowering.h
  llvm/lib/Target/ARM/ARMMachineFunctionInfo.h
  llvm/lib/Target/ARM/ARMSubtarget.h
  llvm/lib/Target/ARM/Thumb1FrameLowering.cpp
  llvm/lib/Target/ARM/ThumbRegisterInfo.cpp
  llvm/test/CodeGen/ARM/frame-chain-reserved-fp.ll
  llvm/test/CodeGen/ARM/frame-chain.ll
  llvm/test/CodeGen/Thumb/frame-access.ll
  llvm/test/CodeGen/Thumb/frame-chain-reserved-fp.ll
  llvm/test/CodeGen/Thumb/frame-chain.ll

Index: llvm/test/CodeGen/Thumb/frame-chain.ll
===
--- /dev/null
+++ llvm/test/CodeGen/Thumb/frame-chain.ll
@@ -0,0 +1,274 @@
+; RUN: llc -mtriple thumbv6m-arm-none-eabi -filetype asm -o - %s -frame-pointer=all --verify-machineinstrs | FileCheck %s --check-prefixes=FP,LEAF-FP
+; RUN: llc -mtriple thumbv6m-arm-none-eabi -filetype asm -o - %s -frame-pointer=all -mattr=+aapcs-frame-chain --verify-machineinstrs | FileCheck %s --check-prefixes=FP-AAPCS,LEAF-FP
+; RUN: llc -mtriple thumbv6m-arm-none-eabi -filetype asm -o - %s -frame-pointer=all -mattr=+aapcs-frame-chain-leaf --verify-machineinstrs | FileCheck %s --check-prefixes=FP-AAPCS,LEAF-FP-AAPCS
+; RUN: llc -mtriple thumbv6m-arm-none-eabi -filetype asm -o - %s -frame-pointer=non-leaf --verify-machineinstrs | FileCheck %s --check-prefixes=FP,LEAF-NOFP
+; RUN: llc -mtriple thumbv6m-arm-none-eabi -filetype asm -o - %s -frame-pointer=non-leaf -mattr=+aapcs-frame-chain --verify-machineinstrs | FileCheck %s --check-prefixes=FP-AAPCS,LEAF-NOFP
+; RUN: llc -mtriple thumbv6m-arm-none-eabi -filetype asm -o - %s -frame-pointer=non-leaf -mattr=+aapcs-frame-chain-leaf --verify-machineinstrs | FileCheck %s --check-prefixes=FP-AAPCS,LEAF-NOFP-AAPCS
+; RUN: llc -mtriple thumbv6m-arm-none-eabi -filetype asm -o - %s -frame-pointer=none --verify-machineinstrs | FileCheck %s --check-prefixes=NOFP,LEAF-NOFP
+; RUN: llc -mtriple thumbv6m-arm-none-eabi -filetype asm -o - %s -frame-pointer=none -mattr=+aapcs-frame-chain --verify-machineinstrs | FileCheck %s --check-prefixes=NOFP-AAPCS,LEAF-NOFP
+; RUN: llc -mtriple thumbv6m-arm-none-eabi -filetype asm -o - %s -frame-pointer=none -mattr=+aapcs-frame-chain-leaf --verify-machineinstrs | FileCheck %s --check-prefixes=NOFP-AAPCS,LEAF-NOFP-AAPCS
+
+define dso_local noundef i32 @leaf(i32 noundef %0) {
+; LEAF-FP-LABEL: leaf:
+; LEAF-FP:   @ %bb.0:
+; LEAF-FP-NEXT:.pad #4
+; LEAF-FP-NEXT:sub sp, #4
+; LEAF-FP-NEXT:str r0, [sp]
+; LEAF-FP-NEXT:adds r0, r0, #4
+; LEAF-FP-NEXT:add sp, #4
+; LEAF-FP-NEXT:bx lr
+;
+; LEAF-FP-AAPCS-LABEL: leaf:
+; LEAF-FP-AAPCS:   @ %bb.0:
+; LEAF-FP-AAPCS-NEXT:.save {lr}
+; LEAF-FP-AAPCS-NEXT:push {lr}
+; LEAF-FP-AAPCS-NEXT:mov lr, r11
+; LEAF-FP-AAPCS-NEXT:.save {r11}
+; LEAF-FP-AAPCS-NEXT:push {lr}
+; LEAF-FP-AAPCS-NEXT:.setfp r11, sp
+; LEAF-FP-AAPCS-NEXT:mov r11, sp
+; LEAF-FP-AAPCS-NEXT:.pad #4
+; LEAF-FP-AAPCS-NEXT:sub sp, #4
+; LEAF-FP-AAPCS-NEXT:str r0, [sp]
+; LEAF-FP-AAPCS-NEXT:adds r0, r0, #4
+; LEAF-FP-AAPCS-NEXT:add sp, #4
+; LEAF-FP-AAPCS-NEXT:pop {r1}
+; LEAF-FP-AAPCS-NEXT:mov r11, r1
+; LEAF-FP-AAPCS-NEXT:pop {pc}
+;
+; LEAF-NOFP-LABEL: leaf:
+; LEAF-NOFP:   @ %bb.0:
+; LEAF-NOFP-NEXT:.pad #4
+; LEAF-NOFP-NEXT:sub sp, #4
+; LEAF-NOFP-NEXT:str r0, [sp]
+; LEAF-NOFP-NEXT:adds r0, r0, #4
+; LEAF-NOFP-NEXT:add sp, #4
+; LEAF-NOFP-NEXT:bx lr
+;
+; LEAF-NOFP-AAPCS-LABEL: leaf:
+; LEAF-NOFP-AAPCS:   @ %bb.0:
+; LEAF-NOFP-AAPCS-NEXT:.pad #4
+; LEAF-NOFP-AAPCS-NEXT:sub sp, #4
+; LEAF-NOFP-AAPCS-NEXT:str r0, [sp]
+; LEAF-NOFP-AAPCS-NEXT:adds r0, r0, #4
+; LEAF-NOFP-AAPCS-NEXT:add sp, #4
+; LEAF-NOFP-AAPCS-NEXT:bx lr
+  %2 = alloca i32, align 4
+  store i32 %0, i32* %2, align 4
+  %3 = load i32, i32* %2, align 4
+  %4 = add nsw i32 %3, 4
+  ret i32 %4
+}
+
+define dso_local noundef i32 @non_leaf(i32 noundef %0) {
+; FP-LABEL: non_leaf:
+; FP:   @ %bb.0:
+; FP-NEXT:.save {r7, lr}
+; FP-NEXT:push {r7, lr}
+; FP-NEXT:.setfp r7, sp
+; FP-NEXT:add r7, sp, #0
+; FP-NEXT:.pad #8
+; FP-NEXT:sub sp, #8
+; FP-NEXT:str r0, [sp, #4]
+; FP-NEXT:bl leaf
+; FP-NEXT:adds r0, r0, #1
+; FP-NE

[PATCH] D128434: [OpenCL] Remove half scalar vload/vstore builtins

2022-06-23 Thread Sven van Haastregt via Phabricator via cfe-commits
svenvh created this revision.
svenvh added reviewers: Anastasia, stuart, azabaznov.
svenvh added a project: clang.
Herald added subscribers: Naghasan, ldrumm, yaxunl.
Herald added a project: All.
svenvh requested review of this revision.
Herald added a subscriber: cfe-commits.

These are not mentioned in the OpenCL C Specification nor in the
OpenCL Extension Specification.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D128434

Files:
  clang/lib/Headers/opencl-c.h


Index: clang/lib/Headers/opencl-c.h
===
--- clang/lib/Headers/opencl-c.h
+++ clang/lib/Headers/opencl-c.h
@@ -11255,7 +11255,6 @@
 #endif //cl_khr_fp64
 
 #ifdef cl_khr_fp16
-half __ovld __purefn vload(size_t, const __constant half *);
 half2 __ovld __purefn vload2(size_t, const __constant half *);
 half3 __ovld __purefn vload3(size_t, const __constant half *);
 half4 __ovld __purefn vload4(size_t, const __constant half *);
@@ -11319,7 +11318,6 @@
 #endif //cl_khr_fp64
 
 #ifdef cl_khr_fp16
-half __ovld __purefn vload(size_t, const half *);
 half2 __ovld __purefn vload2(size_t, const half *);
 half3 __ovld __purefn vload3(size_t, const half *);
 half4 __ovld __purefn vload4(size_t, const half *);
@@ -11484,19 +11482,16 @@
 #endif //cl_khr_fp64
 
 #ifdef cl_khr_fp16
-half __ovld __purefn vload(size_t, const __global half *);
 half2 __ovld __purefn vload2(size_t, const __global half *);
 half3 __ovld __purefn vload3(size_t, const __global half *);
 half4 __ovld __purefn vload4(size_t, const __global half *);
 half8 __ovld __purefn vload8(size_t, const __global half *);
 half16 __ovld __purefn vload16(size_t, const __global half *);
-half __ovld __purefn vload(size_t, const __local half *);
 half2 __ovld __purefn vload2(size_t, const __local half *);
 half3 __ovld __purefn vload3(size_t, const __local half *);
 half4 __ovld __purefn vload4(size_t, const __local half *);
 half8 __ovld __purefn vload8(size_t, const __local half *);
 half16 __ovld __purefn vload16(size_t, const __local half *);
-half __ovld __purefn vload(size_t, const __private half *);
 half2 __ovld __purefn vload2(size_t, const __private half *);
 half3 __ovld __purefn vload3(size_t, const __private half *);
 half4 __ovld __purefn vload4(size_t, const __private half *);
@@ -11559,7 +11554,6 @@
 void __ovld vstore16(double16, size_t, double *);
 #endif //cl_khr_fp64
 #ifdef cl_khr_fp16
-void __ovld vstore(half, size_t, half *);
 void __ovld vstore2(half2, size_t, half *);
 void __ovld vstore3(half3, size_t, half *);
 void __ovld vstore4(half4, size_t, half *);
@@ -11722,19 +11716,16 @@
 void __ovld vstore16(double16, size_t, __private double *);
 #endif //cl_khr_fp64
 #ifdef cl_khr_fp16
-void __ovld vstore(half, size_t, __global half *);
 void __ovld vstore2(half2, size_t, __global half *);
 void __ovld vstore3(half3, size_t, __global half *);
 void __ovld vstore4(half4, size_t, __global half *);
 void __ovld vstore8(half8, size_t, __global half *);
 void __ovld vstore16(half16, size_t, __global half *);
-void __ovld vstore(half, size_t, __local half *);
 void __ovld vstore2(half2, size_t, __local half *);
 void __ovld vstore3(half3, size_t, __local half *);
 void __ovld vstore4(half4, size_t, __local half *);
 void __ovld vstore8(half8, size_t, __local half *);
 void __ovld vstore16(half16, size_t, __local half *);
-void __ovld vstore(half, size_t, __private half *);
 void __ovld vstore2(half2, size_t, __private half *);
 void __ovld vstore3(half3, size_t, __private half *);
 void __ovld vstore4(half4, size_t, __private half *);


Index: clang/lib/Headers/opencl-c.h
===
--- clang/lib/Headers/opencl-c.h
+++ clang/lib/Headers/opencl-c.h
@@ -11255,7 +11255,6 @@
 #endif //cl_khr_fp64
 
 #ifdef cl_khr_fp16
-half __ovld __purefn vload(size_t, const __constant half *);
 half2 __ovld __purefn vload2(size_t, const __constant half *);
 half3 __ovld __purefn vload3(size_t, const __constant half *);
 half4 __ovld __purefn vload4(size_t, const __constant half *);
@@ -11319,7 +11318,6 @@
 #endif //cl_khr_fp64
 
 #ifdef cl_khr_fp16
-half __ovld __purefn vload(size_t, const half *);
 half2 __ovld __purefn vload2(size_t, const half *);
 half3 __ovld __purefn vload3(size_t, const half *);
 half4 __ovld __purefn vload4(size_t, const half *);
@@ -11484,19 +11482,16 @@
 #endif //cl_khr_fp64
 
 #ifdef cl_khr_fp16
-half __ovld __purefn vload(size_t, const __global half *);
 half2 __ovld __purefn vload2(size_t, const __global half *);
 half3 __ovld __purefn vload3(size_t, const __global half *);
 half4 __ovld __purefn vload4(size_t, const __global half *);
 half8 __ovld __purefn vload8(size_t, const __global half *);
 half16 __ovld __purefn vload16(size_t, const __global half *);
-half __ovld __purefn vload(size_t, const __local half *);
 half2 __ovld __purefn vload2(size_t, const __local half *);
 half3 __ovld __purefn vload3(size_t, const __local half *);
 

[PATCH] D128436: [OpenCL] Remove fast_ half geometric builtins

2022-06-23 Thread Sven van Haastregt via Phabricator via cfe-commits
svenvh created this revision.
svenvh added reviewers: Anastasia, stuart, azabaznov.
svenvh added a project: clang.
Herald added subscribers: Naghasan, ldrumm, yaxunl.
Herald added a project: All.
svenvh requested review of this revision.
Herald added a subscriber: cfe-commits.

These are not mentioned in the OpenCL C Specification nor in the
OpenCL Extension Specification.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D128436

Files:
  clang/lib/Headers/opencl-c.h


Index: clang/lib/Headers/opencl-c.h
===
--- clang/lib/Headers/opencl-c.h
+++ clang/lib/Headers/opencl-c.h
@@ -10467,12 +10467,6 @@
 float __ovld __cnfn fast_distance(float2, float2);
 float __ovld __cnfn fast_distance(float3, float3);
 float __ovld __cnfn fast_distance(float4, float4);
-#ifdef cl_khr_fp16
-half __ovld __cnfn fast_distance(half, half);
-half __ovld __cnfn fast_distance(half2, half2);
-half __ovld __cnfn fast_distance(half3, half3);
-half __ovld __cnfn fast_distance(half4, half4);
-#endif //cl_khr_fp16
 
 /**
  * Returns the length of vector p computed as:
@@ -10482,12 +10476,6 @@
 float __ovld __cnfn fast_length(float2);
 float __ovld __cnfn fast_length(float3);
 float __ovld __cnfn fast_length(float4);
-#ifdef cl_khr_fp16
-half __ovld __cnfn fast_length(half);
-half __ovld __cnfn fast_length(half2);
-half __ovld __cnfn fast_length(half3);
-half __ovld __cnfn fast_length(half4);
-#endif //cl_khr_fp16
 
 /**
  * Returns a vector in the same direction as p but with a
@@ -10514,12 +10502,6 @@
 float2 __ovld __cnfn fast_normalize(float2);
 float3 __ovld __cnfn fast_normalize(float3);
 float4 __ovld __cnfn fast_normalize(float4);
-#ifdef cl_khr_fp16
-half __ovld __cnfn fast_normalize(half);
-half2 __ovld __cnfn fast_normalize(half2);
-half3 __ovld __cnfn fast_normalize(half3);
-half4 __ovld __cnfn fast_normalize(half4);
-#endif //cl_khr_fp16
 
 // OpenCL v1.1 s6.11.6, v1.2 s6.12.6, v2.0 s6.13.6 - Relational Functions
 


Index: clang/lib/Headers/opencl-c.h
===
--- clang/lib/Headers/opencl-c.h
+++ clang/lib/Headers/opencl-c.h
@@ -10467,12 +10467,6 @@
 float __ovld __cnfn fast_distance(float2, float2);
 float __ovld __cnfn fast_distance(float3, float3);
 float __ovld __cnfn fast_distance(float4, float4);
-#ifdef cl_khr_fp16
-half __ovld __cnfn fast_distance(half, half);
-half __ovld __cnfn fast_distance(half2, half2);
-half __ovld __cnfn fast_distance(half3, half3);
-half __ovld __cnfn fast_distance(half4, half4);
-#endif //cl_khr_fp16
 
 /**
  * Returns the length of vector p computed as:
@@ -10482,12 +10476,6 @@
 float __ovld __cnfn fast_length(float2);
 float __ovld __cnfn fast_length(float3);
 float __ovld __cnfn fast_length(float4);
-#ifdef cl_khr_fp16
-half __ovld __cnfn fast_length(half);
-half __ovld __cnfn fast_length(half2);
-half __ovld __cnfn fast_length(half3);
-half __ovld __cnfn fast_length(half4);
-#endif //cl_khr_fp16
 
 /**
  * Returns a vector in the same direction as p but with a
@@ -10514,12 +10502,6 @@
 float2 __ovld __cnfn fast_normalize(float2);
 float3 __ovld __cnfn fast_normalize(float3);
 float4 __ovld __cnfn fast_normalize(float4);
-#ifdef cl_khr_fp16
-half __ovld __cnfn fast_normalize(half);
-half2 __ovld __cnfn fast_normalize(half2);
-half3 __ovld __cnfn fast_normalize(half3);
-half4 __ovld __cnfn fast_normalize(half4);
-#endif //cl_khr_fp16
 
 // OpenCL v1.1 s6.11.6, v1.2 s6.12.6, v2.0 s6.13.6 - Relational Functions
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D128402: [clang-tidy] Don't treat invalid branches as identical

2022-06-23 Thread Ishaan Gandhi via Phabricator via cfe-commits
ishaangandhi added inline comments.



Comment at: clang-tools-extra/clang-tidy/bugprone/BranchCloneCheck.cpp:28
+const Expr *RHSExpr = llvm::dyn_cast(RHS);
+if (LHSExpr->containsErrors() && RHSExpr->containsErrors()) {
+  return false;

njames93 wrote:
> Surely we can bail if only one of the sides contains an errors.
Makes no difference, since when only one of the side has errors, the two 
profile hashes will be different.



Comment at: clang-tools-extra/docs/ReleaseNotes.rst:236
 
+- Fixed a false positive in :doc:`bugprone-branch-clone
+  ` when the branches

Eugene.Zelenko wrote:
> Documentation path was changed recently. Please also keep alphabetical order 
> inside section.
Hm? Its still at this path on mastesr: 
https://github.com/llvm/llvm-project/blob/main/clang-tools-extra/docs/ReleaseNotes.rst


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128402

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


[PATCH] D128402: [clang-tidy] Don't treat invalid branches as identical

2022-06-23 Thread Ishaan Gandhi via Phabricator via cfe-commits
ishaangandhi added inline comments.



Comment at: clang-tools-extra/docs/ReleaseNotes.rst:236
 
+- Fixed a false positive in :doc:`bugprone-branch-clone
+  ` when the branches

ishaangandhi wrote:
> Eugene.Zelenko wrote:
> > Documentation path was changed recently. Please also keep alphabetical 
> > order inside section.
> Hm? Its still at this path on mastesr: 
> https://github.com/llvm/llvm-project/blob/main/clang-tools-extra/docs/ReleaseNotes.rst
Also, it doesn't look alphabetized to me? Two points up is 
"performance-unnecessary-..." then its "bugprone-use-after...".


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128402

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


[PATCH] D128439: [Clang][WIP] Don't call distributeTypeAttrsFromDeclarator() on empty list.

2022-06-23 Thread Martin Böhme via Phabricator via cfe-commits
mboehme created this revision.
Herald added a project: All.
mboehme requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This check was present before https://reviews.llvm.org/D126061. I eliminated it
as part of that patch because it seemed superfluous; the check has no influence
on behavior. However, as @yurai007 points out in
https://reviews.llvm.org/D128097, this change may have had a negative impact on
compile time, so I'm adding the check back in.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D128439

Files:
  clang/lib/Sema/SemaType.cpp


Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -3430,7 +3430,8 @@
   // Note: We don't need to distribute declaration attributes (i.e.
   // D.getDeclarationAttributes()) because those are always C++11 attributes,
   // and those don't get distributed.
-  distributeTypeAttrsFromDeclarator(state, T);
+  if (!D.getAttributes().empty())
+distributeTypeAttrsFromDeclarator(state, T);
 
   // Find the deduced type in this type. Look in the trailing return type if we
   // have one, otherwise in the DeclSpec type.


Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -3430,7 +3430,8 @@
   // Note: We don't need to distribute declaration attributes (i.e.
   // D.getDeclarationAttributes()) because those are always C++11 attributes,
   // and those don't get distributed.
-  distributeTypeAttrsFromDeclarator(state, T);
+  if (!D.getAttributes().empty())
+distributeTypeAttrsFromDeclarator(state, T);
 
   // Find the deduced type in this type. Look in the trailing return type if we
   // have one, otherwise in the DeclSpec type.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D128402: [clang-tidy] Don't treat invalid branches as identical

2022-06-23 Thread Ishaan Gandhi via Phabricator via cfe-commits
ishaangandhi updated this revision to Diff 439369.
ishaangandhi added a comment.

Use `auto` instead of `Expr` and `llvm::cast` instead of `llvm::dyn_cast`.


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

https://reviews.llvm.org/D128402

Files:
  clang-tools-extra/clang-tidy/bugprone/BranchCloneCheck.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/test/clang-tidy/checkers/bugprone/branch-clone-unknown-expr.cpp


Index: 
clang-tools-extra/test/clang-tidy/checkers/bugprone/branch-clone-unknown-expr.cpp
===
--- /dev/null
+++ 
clang-tools-extra/test/clang-tidy/checkers/bugprone/branch-clone-unknown-expr.cpp
@@ -0,0 +1,9 @@
+// RUN: %check_clang_tidy -fix-errors %s bugprone-branch-clone %t
+
+int test_unknown_expression() {
+  if (unknown_expression_1) {// CHECK-MESSAGES: :[[@LINE]]:7: error: 
use of undeclared identifier 'unknown_expression_1' [clang-diagnostic-error]
+function1(unknown_expression_2); // CHECK-MESSAGES: :[[@LINE]]:15: error: 
use of undeclared identifier 'unknown_expression_2' [clang-diagnostic-error]
+  } else {
+function2(unknown_expression_3); // CHECK-MESSAGES: :[[@LINE]]:15: error: 
use of undeclared identifier 'unknown_expression_3' [clang-diagnostic-error]
+  }
+}
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -233,6 +233,10 @@
 
   - Don't emit an erroneous warning on self-moves.
 
+- Fixed a false positive in :doc:`bugprone-branch-clone
+  ` when the branches
+  involve unknown expressions.
+
 Removed checks
 ^^
 
Index: clang-tools-extra/clang-tidy/bugprone/BranchCloneCheck.cpp
===
--- clang-tools-extra/clang-tidy/bugprone/BranchCloneCheck.cpp
+++ clang-tools-extra/clang-tidy/bugprone/BranchCloneCheck.cpp
@@ -19,6 +19,17 @@
 /// Returns true when the statements are Type I clones of each other.
 static bool areStatementsIdentical(const Stmt *LHS, const Stmt *RHS,
const ASTContext &Context) {
+  if (isa(LHS) && isa(RHS)) {
+// If we have errors in expressions, we will be unable
+// to accurately profile and compute hashes for each
+// of the left and right statements.
+const auto *LHSExpr = llvm::cast(LHS);
+const auto *RHSExpr = llvm::cast(RHS);
+if (LHSExpr->containsErrors() && RHSExpr->containsErrors()) {
+  return false;
+}
+  }
+
   llvm::FoldingSetNodeID DataLHS, DataRHS;
   LHS->Profile(DataLHS, Context, false);
   RHS->Profile(DataRHS, Context, false);


Index: clang-tools-extra/test/clang-tidy/checkers/bugprone/branch-clone-unknown-expr.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone/branch-clone-unknown-expr.cpp
@@ -0,0 +1,9 @@
+// RUN: %check_clang_tidy -fix-errors %s bugprone-branch-clone %t
+
+int test_unknown_expression() {
+  if (unknown_expression_1) {// CHECK-MESSAGES: :[[@LINE]]:7: error: use of undeclared identifier 'unknown_expression_1' [clang-diagnostic-error]
+function1(unknown_expression_2); // CHECK-MESSAGES: :[[@LINE]]:15: error: use of undeclared identifier 'unknown_expression_2' [clang-diagnostic-error]
+  } else {
+function2(unknown_expression_3); // CHECK-MESSAGES: :[[@LINE]]:15: error: use of undeclared identifier 'unknown_expression_3' [clang-diagnostic-error]
+  }
+}
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -233,6 +233,10 @@
 
   - Don't emit an erroneous warning on self-moves.
 
+- Fixed a false positive in :doc:`bugprone-branch-clone
+  ` when the branches
+  involve unknown expressions.
+
 Removed checks
 ^^
 
Index: clang-tools-extra/clang-tidy/bugprone/BranchCloneCheck.cpp
===
--- clang-tools-extra/clang-tidy/bugprone/BranchCloneCheck.cpp
+++ clang-tools-extra/clang-tidy/bugprone/BranchCloneCheck.cpp
@@ -19,6 +19,17 @@
 /// Returns true when the statements are Type I clones of each other.
 static bool areStatementsIdentical(const Stmt *LHS, const Stmt *RHS,
const ASTContext &Context) {
+  if (isa(LHS) && isa(RHS)) {
+// If we have errors in expressions, we will be unable
+// to accurately profile and compute hashes for each
+// of the left and right statements.
+const auto *LHSExpr = llvm::cast(LHS);
+const auto *RHSExpr = llvm::cast(RHS);
+if (LHSExpr->containsErrors() && RHSExpr->containsErrors()) {
+  return false;
+}
+  }
+
   llvm::FoldingSetNodeID DataLHS, DataRHS;
   LHS->Profile(DataLHS, Context, false);
   RHS->P

[PATCH] D128356: [clang][dataflow] Use NoopLattice in optional model

2022-06-23 Thread Sam Estep via Phabricator via cfe-commits
samestep added a comment.

@xazax.hun After this patch, `SourceLocationsLattice` is still used by 
`clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp`. 
I'm currently working on a patch to change the way we write unit tests in that 
file, after which I'll make a followup patch to delete `SourceLocationsLattice`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128356

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


[PATCH] D128439: [Clang][WIP] Don't call distributeTypeAttrsFromDeclarator() on empty list.

2022-06-23 Thread Martin Böhme via Phabricator via cfe-commits
mboehme added a comment.

Marking as {WIP] for the time being because I'm uploading this change for 
discussion.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128439

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


[PATCH] D127898: [clang][dataflow] Add API to separate analysis from diagnosis

2022-06-23 Thread Sam Estep via Phabricator via cfe-commits
samestep updated this revision to Diff 439372.
samestep added a comment.

- Merge branch 'main' into diagnose-api
- Incorporate Gábor's suggestions


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127898

Files:
  clang/docs/tools/clang-formatted-files.txt
  clang/include/clang/Analysis/FlowSensitive/Diagnosis.h
  clang/include/clang/Analysis/FlowSensitive/MatchSwitch.h
  
clang/include/clang/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.h
  clang/include/clang/Analysis/FlowSensitive/SourceLocationsLattice.h
  clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
  clang/lib/Analysis/FlowSensitive/SourceLocationsLattice.cpp
  clang/unittests/Analysis/FlowSensitive/TestingSupport.h
  clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp
@@ -12,8 +12,10 @@
 #include "clang/AST/ASTContext.h"
 #include "clang/ASTMatchers/ASTMatchers.h"
 #include "clang/Analysis/FlowSensitive/SourceLocationsLattice.h"
+#include "clang/Basic/SourceLocation.h"
 #include "clang/Tooling/Tooling.h"
 #include "llvm/ADT/ArrayRef.h"
+#include "llvm/ADT/DenseSet.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/Support/Error.h"
 #include "gmock/gmock.h"
@@ -26,9 +28,6 @@
 using namespace dataflow;
 using namespace test;
 
-using ::testing::Pair;
-using ::testing::UnorderedElementsAre;
-
 // FIXME: Move header definitions in separate file(s).
 static constexpr char CSDtdDefHeader[] = R"(
 #ifndef CSTDDEF_H
@@ -1181,10 +1180,9 @@
 )";
 
 /// Converts `L` to string.
-static std::string ConvertToString(const SourceLocationsLattice &L,
+static std::string ConvertToString(const llvm::DenseSet &L,
const ASTContext &Ctx) {
-  return L.getSourceLocations().empty() ? "safe"
-: "unsafe: " + DebugString(L, Ctx);
+  return L.empty() ? "safe" : "unsafe: " + DebugString(L, Ctx);
 }
 
 /// Replaces all occurrences of `Pattern` in `S` with `Replacement`.
@@ -1245,29 +1243,30 @@
 )");
 const tooling::FileContentMappings FileContents(Headers.begin(),
 Headers.end());
-llvm::Error Error = checkDataflow(
-SourceCode, FuncMatcher,
-[](ASTContext &Ctx, Environment &) {
-  return UncheckedOptionalAccessModel(
-  Ctx, UncheckedOptionalAccessModelOptions{
-   /*IgnoreSmartPointerDereference=*/true});
-},
-[&MatchesLatticeChecks](
-llvm::ArrayRef>>
-CheckToLatticeMap,
-ASTContext &Ctx) {
-  // FIXME: Consider using a matcher instead of translating
-  // `CheckToLatticeMap` to `CheckToStringifiedLatticeMap`.
-  std::vector>
-  CheckToStringifiedLatticeMap;
-  for (const auto &E : CheckToLatticeMap) {
-CheckToStringifiedLatticeMap.emplace_back(
-E.first, ConvertToString(E.second.Lattice, Ctx));
-  }
-  EXPECT_THAT(CheckToStringifiedLatticeMap, MatchesLatticeChecks);
-},
-{"-fsyntax-only", "-std=c++17", "-Wno-undefined-inline"}, FileContents);
+UncheckedOptionalAccessModelOptions Options{
+/*IgnoreSmartPointerDereference=*/true};
+llvm::Error Error =
+checkDataflowDiagnosis(
+SourceCode, FuncMatcher,
+[Options](ASTContext &Ctx, Environment &) {
+  return UncheckedOptionalAccessModel(Ctx, Options);
+},
+[Options](ASTContext &Ctx) {
+  UncheckedOptionalAccessDiagnosis Diagnosis(Ctx, Options);
+  return [Diagnosis = std::move(Diagnosis)](
+ const Stmt *Stmt,
+ const UncheckedOptionalAccessModel::Lattice &,
+ const Environment &Env) mutable {
+return Diagnosis.diagnose(Stmt, Env);
+  };
+},
+[&MatchesLatticeChecks](llvm::DenseSet Locs,
+ASTContext &Ctx) {
+  std::string StringifiedDiags = ConvertToString(Locs, Ctx);
+  EXPECT_THAT(StringifiedDiags, MatchesLatticeChecks);
+},
+{"-fsyntax-only", "-std=c++17", "-Wno-undefined-inline"},
+FileContents);
 if (Error)
   FAIL() << llvm::toString(std::move(Error));
   }
@@ -1289,7 +1288,7 @@
   /*[[check]]*/
 }
   )",
- UnorderedElementsAre(Pair("check", "safe")));
+ "safe");
 }
 
 TEST_P(UncheckedOptionalAccessTest, UnwrapUsingValueNoCheck) {
@@ -

[PATCH] D128352: [clang][dataflow] Use diagnosis API in optional checker

2022-06-23 Thread Sam Estep via Phabricator via cfe-commits
samestep updated this revision to Diff 439373.
samestep added a comment.

- Merge branch 'diagnose-api' into optional-check-diagnose


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128352

Files:
  clang-tools-extra/clang-tidy/bugprone/UncheckedOptionalAccessCheck.cpp


Index: clang-tools-extra/clang-tidy/bugprone/UncheckedOptionalAccessCheck.cpp
===
--- clang-tools-extra/clang-tidy/bugprone/UncheckedOptionalAccessCheck.cpp
+++ clang-tools-extra/clang-tidy/bugprone/UncheckedOptionalAccessCheck.cpp
@@ -17,11 +17,12 @@
 #include "clang/Analysis/FlowSensitive/DataflowAnalysisContext.h"
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
 #include "clang/Analysis/FlowSensitive/DataflowLattice.h"
+#include "clang/Analysis/FlowSensitive/Diagnosis.h"
 #include "clang/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.h"
-#include "clang/Analysis/FlowSensitive/SourceLocationsLattice.h"
 #include "clang/Analysis/FlowSensitive/WatchedLiteralsSolver.h"
 #include "clang/Basic/SourceLocation.h"
 #include "llvm/ADT/Any.h"
+#include "llvm/ADT/DenseSet.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/Support/Error.h"
 #include 
@@ -31,16 +32,16 @@
 namespace tidy {
 namespace bugprone {
 using ast_matchers::MatchFinder;
-using dataflow::SourceLocationsLattice;
+using dataflow::UncheckedOptionalAccessDiagnosis;
 using dataflow::UncheckedOptionalAccessModel;
 using llvm::Optional;
 
 static constexpr llvm::StringLiteral FuncID("fun");
 
-static Optional
+static Optional>
 analyzeFunction(const FunctionDecl &FuncDecl, ASTContext &ASTCtx) {
   using dataflow::ControlFlowContext;
-  using dataflow::DataflowAnalysisState;
+  using dataflow::TypeErasedDataflowAnalysisState;
   using llvm::Expected;
 
   Expected Context =
@@ -52,23 +53,23 @@
   std::make_unique());
   dataflow::Environment Env(AnalysisContext, FuncDecl);
   UncheckedOptionalAccessModel Analysis(ASTCtx);
-  
Expected>>>
+  Expected>>
   BlockToOutputState =
-  dataflow::runDataflowAnalysis(*Context, Analysis, Env);
+  dataflow::runTypeErasedDataflowAnalysis(*Context, Analysis, Env);
   if (!BlockToOutputState)
 return llvm::None;
-  assert(Context->getCFG().getExit().getBlockID() < 
BlockToOutputState->size());
 
-  const Optional>
-  &ExitBlockState =
-  (*BlockToOutputState)[Context->getCFG().getExit().getBlockID()];
-  // `runDataflowAnalysis` doesn't guarantee that the exit block is visited;
-  // for example, when it is unreachable.
-  // FIXME: Diagnose violations even when the exit block is unreachable.
-  if (!ExitBlockState)
-return llvm::None;
+  UncheckedOptionalAccessDiagnosis Diagnosis(ASTCtx);
+  dataflow::Diagnosis>
+  Diagnose = [&Diagnosis](const Stmt *Stmt,
+  const UncheckedOptionalAccessModel::Lattice &,
+  const dataflow::Environment &Env) {
+return Diagnosis.diagnose(Stmt, Env);
+  };
 
-  return std::move(ExitBlockState->Lattice);
+  return dataflow::diagnoseCFG(*Context, *BlockToOutputState, Env, Analysis,
+   std::move(Diagnose));
 }
 
 void UncheckedOptionalAccessCheck::registerMatchers(MatchFinder *Finder) {
@@ -97,9 +98,9 @@
   if (FuncDecl->isTemplated())
 return;
 
-  if (Optional Errors =
+  if (Optional> Errors =
   analyzeFunction(*FuncDecl, *Result.Context))
-for (const SourceLocation &Loc : Errors->getSourceLocations())
+for (const SourceLocation &Loc : *Errors)
   diag(Loc, "unchecked access to optional value");
 }
 


Index: clang-tools-extra/clang-tidy/bugprone/UncheckedOptionalAccessCheck.cpp
===
--- clang-tools-extra/clang-tidy/bugprone/UncheckedOptionalAccessCheck.cpp
+++ clang-tools-extra/clang-tidy/bugprone/UncheckedOptionalAccessCheck.cpp
@@ -17,11 +17,12 @@
 #include "clang/Analysis/FlowSensitive/DataflowAnalysisContext.h"
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
 #include "clang/Analysis/FlowSensitive/DataflowLattice.h"
+#include "clang/Analysis/FlowSensitive/Diagnosis.h"
 #include "clang/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.h"
-#include "clang/Analysis/FlowSensitive/SourceLocationsLattice.h"
 #include "clang/Analysis/FlowSensitive/WatchedLiteralsSolver.h"
 #include "clang/Basic/SourceLocation.h"
 #include "llvm/ADT/Any.h"
+#include "llvm/ADT/DenseSet.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/Support/Error.h"
 #include 
@@ -31,16 +32,16 @@
 namespace tidy {
 namespace bugprone {
 using ast_matchers::MatchFinder;
-using dataflow::SourceLocationsLattice;
+using dataflow::UncheckedOptionalAccessDiagnosis;
 using dataflow::UncheckedOptionalAccessModel;
 using llvm::Optional;
 
 static constexpr llvm::StringLiteral FuncID("fun");
 
-static Optional
+static Optional>
 analyzeF

[PATCH] D128356: [clang][dataflow] Use NoopLattice in optional model

2022-06-23 Thread Sam Estep via Phabricator via cfe-commits
samestep updated this revision to Diff 439374.
samestep added a comment.

- Merge branch 'optional-check-diagnose' into optional-model-noop-lattice


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128356

Files:
  clang/docs/tools/clang-formatted-files.txt
  
clang/include/clang/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.h
  clang/include/clang/Analysis/FlowSensitive/NoopLattice.h
  clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
  clang/unittests/Analysis/FlowSensitive/NoopAnalysis.h

Index: clang/unittests/Analysis/FlowSensitive/NoopAnalysis.h
===
--- clang/unittests/Analysis/FlowSensitive/NoopAnalysis.h
+++ clang/unittests/Analysis/FlowSensitive/NoopAnalysis.h
@@ -18,25 +18,11 @@
 #include "clang/AST/Stmt.h"
 #include "clang/Analysis/FlowSensitive/DataflowAnalysis.h"
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
-#include "clang/Analysis/FlowSensitive/DataflowLattice.h"
-#include 
+#include "clang/Analysis/FlowSensitive/NoopLattice.h"
 
 namespace clang {
 namespace dataflow {
 
-class NoopLattice {
-public:
-  bool operator==(const NoopLattice &) const { return true; }
-
-  LatticeJoinEffect join(const NoopLattice &) {
-return LatticeJoinEffect::Unchanged;
-  }
-};
-
-inline std::ostream &operator<<(std::ostream &OS, const NoopLattice &) {
-  return OS << "noop";
-}
-
 class NoopAnalysis : public DataflowAnalysis {
 public:
   /// `ApplyBuiltinTransfer` controls whether to run the built-in transfer
Index: clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
===
--- clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
+++ clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
@@ -20,7 +20,7 @@
 #include "clang/ASTMatchers/ASTMatchers.h"
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
 #include "clang/Analysis/FlowSensitive/MatchSwitch.h"
-#include "clang/Analysis/FlowSensitive/SourceLocationsLattice.h"
+#include "clang/Analysis/FlowSensitive/NoopLattice.h"
 #include "clang/Analysis/FlowSensitive/Value.h"
 #include "clang/Basic/SourceLocation.h"
 #include "llvm/ADT/DenseSet.h"
@@ -35,7 +35,7 @@
 namespace {
 
 using namespace ::clang::ast_matchers;
-using LatticeTransferState = TransferState;
+using LatticeTransferState = TransferState;
 
 DeclarationMatcher optionalClass() {
   return classTemplateSpecializationDecl(
@@ -312,18 +312,7 @@
   if (auto *Loc = maybeInitializeOptionalValueMember(
   UnwrapExpr->getType(), *OptionalVal, State.Env))
 State.Env.setStorageLocation(*UnwrapExpr, *Loc);
-
-auto *Prop = OptionalVal->getProperty("has_value");
-if (auto *HasValueVal = cast_or_null(Prop)) {
-  if (State.Env.flowConditionImplies(*HasValueVal))
-return;
-}
   }
-
-  // Record that this unwrap is *not* provably safe.
-  // FIXME: include either the name of the optional (if applicable) or a source
-  // range of the access for easier interpretation of the result.
-  State.Lattice.getSourceLocations().insert(ObjectExpr->getBeginLoc());
 }
 
 void transferMakeOptionalCall(const CallExpr *E,
@@ -715,12 +704,10 @@
 
 UncheckedOptionalAccessModel::UncheckedOptionalAccessModel(
 ASTContext &Ctx, UncheckedOptionalAccessModelOptions Options)
-: DataflowAnalysis(
-  Ctx),
+: DataflowAnalysis(Ctx),
   TransferMatchSwitch(buildTransferMatchSwitch(Options)) {}
 
-void UncheckedOptionalAccessModel::transfer(const Stmt *S,
-SourceLocationsLattice &L,
+void UncheckedOptionalAccessModel::transfer(const Stmt *S, NoopLattice &L,
 Environment &Env) {
   LatticeTransferState State(L, Env);
   TransferMatchSwitch(*S, getASTContext(), State);
Index: clang/include/clang/Analysis/FlowSensitive/NoopLattice.h
===
--- /dev/null
+++ clang/include/clang/Analysis/FlowSensitive/NoopLattice.h
@@ -0,0 +1,41 @@
+//===-- NoopLattice.h ---*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+//  This file defines the lattice with exactly one element.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_NOOP_LATTICE_H
+#define LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_NOOP_LATTICE_H
+
+#include "clang/Analysis/FlowSensitive/DataflowLattice.h"
+#include 
+
+namespace clang {
+namespace dataflow {
+
+/// Trivial lattice

[PATCH] D128097: [Clang] Fix compile time regression caused by D126061.

2022-06-23 Thread Martin Böhme via Phabricator via cfe-commits
mboehme added a comment.

In D128097#3604295 , @yurai007 wrote:

> Disclaimer: I'm not front-end guy.
>
> After running 7zip benchmark under perf and comparing origin (7acc88be031 
> ) with 
> fix (0d300da799b0 
> ) 
> following diff can be seen:

Thanks a lot for helping me out here!

> Instructions change  |Symbol
> +0.12%   | clang::Preprocessor::getMacroDefinition

Hm, this surprises me. AFAICT, all of the relevant places that this gets called 
from are in the lexer… and I don’t think my patch should have affected what the 
parser does with the lexer. I almost suspect that this regression is due to 
some other change that happened between 7acc88be031 
 and 
0d300da799b0 
?

> +0.07%   | GetDeclSpecTypeForDeclarator

I think you may potentially have found the reason for this – see below.

> +0.04%   | clang::Parser::ParseDirectDeclarator 
> +0.03%   | clang::Sema::ActOnFunctionDeclarator 
> +0.03%   | clang::Sema::ProcessDeclAttributes

An increase here is expected as my patch did add new code to 
`ProcessDeclAttributes()` to handle the “sliding” logic; as such, this increase 
in time seems hard to avoid.

> In 8c7b64b5ae2a 
>  commit 
> those 2 code changes catch my eyes as (maybe) relevant to above perf diff:
>
> 1. Change in Parser::ParseDeclGroup. That function looks quite heavy and it's 
> caller of ParseDirectDeclarator/ActOnFunctionDeclarator (and even 
> getMacroDefinition?)

Here’s what changed in that function:

  -  ParsingDeclarator D(*this, DS, Context);
  +  // Consume all of the attributes from `Attrs` by moving them to our own 
local
  +  // list. This ensures that we will not attempt to interpret them as 
statement
  +  // attributes higher up the callchain.
  +  ParsedAttributes LocalAttrs(AttrFactory);
  +  LocalAttrs.takeAllFrom(Attrs);
  +  ParsingDeclarator D(*this, DS, LocalAttrs, Context);

(`Attrs` is a new parameter of `ParseDeclGroup()`.)

I’m not sure that this change per se had a significant impact on compile time 
though, as `ParseDeclGroup()` itself doesn’t show up in the diff above. The 
change also shouldn’t really affect how much time we spend in 
`ParseDirectDeclarator()` or `ActOnFunctionDeclarator()`.

I’m inclined to say that the extra time spent in `ParseDirectDeclarator()` and 
`ActOnFunctionDeclarator()` is due to some other change that happened in the 
meantime, even though I realize that this sounds like a cheap excuse…

> 2. Change in GetDeclSpecTypeForDeclarator. After 8c7b64b5ae2a 
>  
> distributeTypeAttrsFromDeclarator is called unconditionally which maybe 
> matters.

Thanks for pointing this out to me – this could be the explanation for the 
0.07% slowdown that you saw in `GetDeclSpecTypeForDeclarator()`, as this is the 
only change in that function. Of course, the other possibility is that 
GetDeclSpecTypeForDeclarator() is now getting called more often, but I don’t 
immediately see why that should be the case.

I had removed the if statement because it’s superfluous from a behavioral point 
of view, but it may well be important for performance. I’ve prepared 
https://reviews.llvm.org/D128439 to re-add that statement.

I unfortunately haven’t yet been able to get the test suite running. Since you 
do have a running setup, do you think you could test the compile time impact of 
that patch on 7zip? Please do this only if it’s not a big deal – otherwise, 
I’ll just submit the patch for review, as it seems that it should have at least 
a small positive influence on performance.

Again, thanks for your input here!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128097

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


[PATCH] D127448: [wip][pseudo] Implement guard extension.

2022-06-23 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

(comments for guard part)




Comment at: clang-tools-extra/pseudo/include/clang-pseudo/Language.h:22
+
+// Interface for implementing the grammar "guard" attribute.
+//

nit: I think the first sentence should try to describe what this *is* in as 
simple terms as possible, rather than how it interacts with the rest of the 
system.

```// A guard restricts when a grammar rule can be used```



Comment at: clang-tools-extra/pseudo/include/clang-pseudo/Language.h:25
+// It is used by the GLR parser to determine whether a reduction of a rule will
+// be conducted during the reduce time.
+//

I think it's worth including an example here. "e.g. a guard may allow 
virt-specifier := IDENTIFIER only if the identifier's text is 'override'".



Comment at: clang-tools-extra/pseudo/include/clang-pseudo/Language.h:27
+//
+// Returns false if the reduction is not conducted (this parsing branch in GLR
+// will die).

I think this sentence adds more confusion than it helps. (Not sure it's true 
depending on what you mean by "parsing branch" - the guard runs before the 
reduce not after, so the branch never exists)



Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:306
+  auto It = Params.Lang.Guards.find(Rule.Guard);
+  assert(It != Params.Lang.Guards.end() && "missing guard!");
+  if (!It->getSecond()(TempSequence, Tokens))

I think diagnosing missing guards but then treating them as always-passing is 
less surprising and more ergonomic while modifying a grammar


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127448

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


[PATCH] D128402: [clang-tidy] Don't treat invalid branches as identical

2022-06-23 Thread Eugene Zelenko via Phabricator via cfe-commits
Eugene.Zelenko added inline comments.



Comment at: clang-tools-extra/docs/ReleaseNotes.rst:236
 
+- Fixed a false positive in :doc:`bugprone-branch-clone
+  ` when the branches

ishaangandhi wrote:
> ishaangandhi wrote:
> > Eugene.Zelenko wrote:
> > > Documentation path was changed recently. Please also keep alphabetical 
> > > order inside section.
> > Hm? Its still at this path on mastesr: 
> > https://github.com/llvm/llvm-project/blob/main/clang-tools-extra/docs/ReleaseNotes.rst
> Also, it doesn't look alphabetized to me? Two points up is 
> "performance-unnecessary-..." then its "bugprone-use-after...".
Sorry, my mistake.



Comment at: clang-tools-extra/docs/ReleaseNotes.rst:236
 
+- Fixed a false positive in :doc:`bugprone-branch-clone
+  ` when the branches

Eugene.Zelenko wrote:
> ishaangandhi wrote:
> > ishaangandhi wrote:
> > > Eugene.Zelenko wrote:
> > > > Documentation path was changed recently. Please also keep alphabetical 
> > > > order inside section.
> > > Hm? Its still at this path on mastesr: 
> > > https://github.com/llvm/llvm-project/blob/main/clang-tools-extra/docs/ReleaseNotes.rst
> > Also, it doesn't look alphabetized to me? Two points up is 
> > "performance-unnecessary-..." then its "bugprone-use-after...".
> Sorry, my mistake.
It'll be good idea to fix order of other entries too.


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

https://reviews.llvm.org/D128402

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


[PATCH] D126956: [tbaa] Handle base classes in struct tbaa

2022-06-23 Thread Florian Hahn via Phabricator via cfe-commits
fhahn added a comment.

It looks like this commit is breaking bootstrap builds of LLVM/Clang, e.g. 
https://lab.llvm.org/buildbot/#/builders/37/builds/14224

  FAILED: lib/Bitcode/Reader/CMakeFiles/LLVMBitReader.dir/BitcodeReader.cpp.o 
  /b/sanitizer-x86_64-linux-autoconf/build/tsan_debug_build/bin/clang++  
-DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Bitcode/Reader 
-I/b/sanitizer-x86_64-linux-autoconf/build/llvm-project/llvm/lib/Bitcode/Reader 
-Iinclude -I/b/sanitizer-x86_64-linux-autoconf/build/llvm-project/llvm/include 
-fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time 
-Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic 
-Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough 
-Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor 
-Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wstring-conversion 
-Wmisleading-indentation -fdiagnostics-color -ffunction-sections 
-fdata-sections -O2 -g -DNDEBUG-fno-exceptions -fno-rtti -UNDEBUG 
-std=c++14 -MD -MT lib/Bitcode/Reader/CMakeFiles/LLVMBitReader.dir/BitcodeRea
   der.cpp.o -MF 
lib/Bitcode/Reader/CMakeFiles/LLVMBitReader.dir/BitcodeReader.cpp.o.d -o 
lib/Bitcode/Reader/CMakeFiles/LLVMBitReader.dir/BitcodeReader.cpp.o -c 
/b/sanitizer-x86_64-linux-autoconf/build/llvm-project/llvm/lib/Bitcode/Reader/BitcodeReader.cpp
  Offsets must be increasing!
%45 = load ptr, ptr %Context.i1113, align 8, !dbg !137343, !tbaa !97945, 
!noalias !137026
  !68773 = !{!"_ZTSN12_GLOBAL__N_113BitcodeReaderE", !68334, i64 8, !68774, i64 
0, !61585, i64 432, !61585, i64 440, !61620, i64 448, !61620, i64 456, !62256, 
i64 464, !61620, i64 472, !68775, i64 480, !68775, i64 504, !68778, i64 528, 
!68781, i64 552, !68783, i64 584, !68785, i64 616, !68561, i64 648, !68787, i64 
712, !68788, i64 728, !68791, i64 752, !68795, i64 784, !68800, i64 1312, 
!68803, i64 1336, !68806, i64 1360, !68809, i64 1384, !68812, i64 1408, !68817, 
i64 1456, !68820, i64 1480, !68823, i64 1504, !68823, i64 1536, !62256, i64 
1568, !68825, i64 1576, !68827, i64 1608, !68830, i64 1632, !68832, i64 1664, 
!68820, i64 1744, !62256, i64 1768, !62256, i64 1769, !62256, i64 1770, !68836, 
i64 1776, !68775, i64 1848, !68841, i64 1872, !68847, i64 1904}
  clang++: 
/b/sanitizer-x86_64-linux-autoconf/build/llvm-project/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:10631:
 bool llvm::LoopVectorizePass::processLoop(llvm::Loop*): Assertion 
`!verifyFunction(*L->getHeader()->getParent(), &dbgs())' failed.

Please take a look and revert the patch if the fix isn't trivial.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126956

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


[PATCH] D126956: [tbaa] Handle base classes in struct tbaa

2022-06-23 Thread Jeroen Dobbelaere via Phabricator via cfe-commits
jeroen.dobbelaere added a comment.

In D126956#3604978 , @fhahn wrote:

> Please take a look and revert the patch if the fix isn't trivial.

the patch has already been reverted so Bruno can investigate.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126956

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


[PATCH] D128411: [syntax] Introduce a BaseToken class.

2022-06-23 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

As discussed offline this has some problems:

- putting virtual methods on BaseToken gives it a vtable, which makes it (and 
syntax::Token) large
- being able to use ArrayRef but not ArrayRef is a 
bit weird
- unusual uses of inheritance can be hard to reason about

We suggested rather having Leaf store an opaque ID.
Callers who know what kind of tokens are in use can use this to associate with 
the original token.
For generic use (e.g dump()), we can have a TokenManager interface which 
provides the common operations (like getText()). This generalizes where 
SourceManager is needed today.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128411

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


[PATCH] D128440: [WebAssembly] Initial support for reference type funcref in clang

2022-06-23 Thread Paulo Matos via Phabricator via cfe-commits
pmatos created this revision.
pmatos added reviewers: asb, tlively.
Herald added subscribers: mattd, gchakrabarti, asavonic, StephenFan, wingo, 
ecnelises, sunfish, hiraditya, jgravelle-google, sbc100, dschuff.
Herald added a reviewer: aaron.ballman.
Herald added a project: All.
pmatos requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, aheejin, jholewinski.
Herald added projects: clang, LLVM.

This is the funcref counterpart to 104bad5a. We introduce a new attribute
that marks a function pointer as a funcref. It also implements builtin
__builtin_wasm_ref_null_func(), that returns a null funcref value.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D128440

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/AddressSpaces.h
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/BuiltinsWebAssembly.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Basic/Targets/DirectX.h
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Basic/Targets/SPIR.h
  clang/lib/Basic/Targets/TCE.h
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenTypes.cpp
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/CodeGen/TargetInfo.h
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CodeGen/WebAssembly/wasm-funcref.c
  llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp

Index: llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp
===
--- llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp
+++ llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp
@@ -404,11 +404,17 @@
 }
 
 //===--===//
-// The following functions are called from lib/CodeGen/Passes.cpp to modify
-// the CodeGen pass sequence.
+// The following functions are called from lib/CodeGen/TargetPassConfig.cpp
+// to modify the CodeGen pass sequence.
 //===--===//
 
 void WebAssemblyPassConfig::addIRPasses() {
+  // Run mem2reg to remove alloca references - needed for reference types
+  // FIXME: this should only be added when the subtarget has reference types 
+  // enabled but the subtarget is dependent on the function being compiled to 
+  // which we don't have access atm.
+  addPass(createPromoteMemoryToRegisterPass());
+
   // Add signatures to prototype-less function declarations
   addPass(createWebAssemblyAddMissingPrototypes());
 
Index: clang/test/CodeGen/WebAssembly/wasm-funcref.c
===
--- /dev/null
+++ clang/test/CodeGen/WebAssembly/wasm-funcref.c
@@ -0,0 +1,38 @@
+// RUN: %clang_cc1 -triple wasm32 -target-feature +reference-types -o - -emit-llvm %s | FileCheck %s
+
+typedef void (*funcref_t)() __attribute__((__funcref));
+
+funcref_t get_null() {
+// CHECK:  define i8 addrspace(20)* @get_null() #0 {
+// CHECK-NEXT: entry:
+// CHECK-NEXT:   %0 = call i8 addrspace(20)* @llvm.wasm.ref.null.func()
+// CHECK-NEXT:   ret i8 addrspace(20)* %0
+// CHECK-NEXT: }
+  return __builtin_wasm_ref_null_func();
+}
+
+void helper(funcref_t);
+
+void handle(funcref_t fn) {
+// CHECK:  define void @handle(i8 addrspace(20)* %fn) #0 {
+// CHECK-NEXT: entry:
+// CHECK-NEXT:   %fn.addr = alloca i8 addrspace(20)*, align 1
+// CHECK-NEXT:   store i8 addrspace(20)* %fn, i8 addrspace(20)** %fn.addr, align 1
+// CHECK-NEXT:   %0 = load i8 addrspace(20)*, i8 addrspace(20)** %fn.addr, align 1
+// CHECK-NEXT:   call void @helper(i8 addrspace(20)* %0)
+// CHECK-NEXT:   ret void
+// CHECK-NEXT: }
+  helper(fn);
+}
+
+typedef int (*fn_t)(int);
+typedef fn_t __attribute__((__funcref)) fn_funcref_t;
+
+// What happens when we move a function pointer into a funcref and then call it?
+fn_funcref_t get_ref(fn_t fnptr) {
+  return fnptr;
+}
+
+int call_fn(fn_funcref_t ref, int x) {
+  return ref(x);
+}
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -8106,6 +8106,27 @@
   CurType, CurType);
 }
 
+static void HandleWebAssemblyFuncrefAttr(TypeProcessingState &State,
+ QualType &CurType,
+ ParsedAttr &Attr) {
+  if (!CurType->isFunctionPointerType()) {
+State.getSema().Diag(Attr.getLoc(), 
+ diag::err_attribute_webassembly_funcref);
+Attr.setInvalid();
+return;
+  }
+
+  // Add attribute
+  CurType =
+  State.getAttributedType(createSimpleAttr(
+   

[PATCH] D128440: [WebAssembly] Initial support for reference type funcref in clang

2022-06-23 Thread Paulo Matos via Phabricator via cfe-commits
pmatos planned changes to this revision.
pmatos added a comment.

Draft patch as some tests still fail.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128440

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


[PATCH] D127400: [pseudo] Add xfail tests for a simple-declaration/function-definition ambiguity

2022-06-23 Thread Sam McCall via Phabricator via cfe-commits
sammccall marked 2 inline comments as done.
sammccall added inline comments.



Comment at: clang-tools-extra/pseudo/test/cxx/declarator-var.cpp:10
+void (*s)(){};
+// CHECK-NOT:  function-definition
+// CHECK:  init-declarator := declarator initializer

hokein wrote:
> why we need two lines for `function-definition`?
> because of the undeterministic order of the ambiguous results (we don't know 
> whether function-def comes first or the var-decl comes first)? 
Right, we want to forbid function-definition whether it's first or second.

In a more complicated example I might use -implicit-check-not but I think this 
is clearer: hiding assertions in the FileCheck invocation is non-obvious.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127400

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


[clang-tools-extra] 6b187fd - [pseudo] Add xfail tests for a simple-declaration/function-definition ambiguity

2022-06-23 Thread Sam McCall via cfe-commits

Author: Sam McCall
Date: 2022-06-23T15:52:22+02:00
New Revision: 6b187fdf3bb409061b6a235487517f478b09afed

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

LOG: [pseudo] Add xfail tests for a simple-declaration/function-definition 
ambiguity

I expect to eliminate this ambiguity at the grammar level by use of guards,
because it interferes with brace-based error recvoery.

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

Added: 
clang-tools-extra/pseudo/test/cxx/declarator-function.cpp
clang-tools-extra/pseudo/test/cxx/declarator-var.cpp

Modified: 


Removed: 




diff  --git a/clang-tools-extra/pseudo/test/cxx/declarator-function.cpp 
b/clang-tools-extra/pseudo/test/cxx/declarator-function.cpp
new file mode 100644
index 0..0de4ec14ffcd0
--- /dev/null
+++ b/clang-tools-extra/pseudo/test/cxx/declarator-function.cpp
@@ -0,0 +1,11 @@
+// The standard grammar allows an init-list with any declarator, including
+// a function declarator. This creates an ambiguity where a function-definition
+// is misparsed as a simple-declaration.
+// FIXME: eliminate this false parse.
+// XFAIL: *
+
+// RUN: clang-pseudo -grammar=%cxx-bnf-file -source=%s --print-forest | 
FileCheck %s
+void s(){};
+// CHECK-NOT:  simple-declaration
+// CHECK:  function-definition := decl-specifier-seq declarator
+// function-body CHECK-NOT:  simple-declaration

diff  --git a/clang-tools-extra/pseudo/test/cxx/declarator-var.cpp 
b/clang-tools-extra/pseudo/test/cxx/declarator-var.cpp
new file mode 100644
index 0..a5adb43dc3c5c
--- /dev/null
+++ b/clang-tools-extra/pseudo/test/cxx/declarator-var.cpp
@@ -0,0 +1,11 @@
+// The standard grammar allows an function-body to use any declarator, 
including
+// a non-function declarator. This creates an ambiguity where a
+// simple-declaration is misparsed as a function-definition.
+// FIXME: eliminate this false parse.
+// XFAIL: *
+
+// RUN: clang-pseudo -grammar=%cxx-bnf-file -source=%s --print-forest | 
FileCheck %s
+void (*s)(){};
+// CHECK-NOT:  function-definition
+// CHECK:  init-declarator := declarator initializer
+// CHECK-NOT:  function-definition



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


[PATCH] D127400: [pseudo] Add xfail tests for a simple-declaration/function-definition ambiguity

2022-06-23 Thread Sam McCall via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
sammccall marked an inline comment as done.
Closed by commit rG6b187fdf3bb4: [pseudo] Add xfail tests for a 
simple-declaration/function-definition ambiguity (authored by sammccall).

Changed prior to commit:
  https://reviews.llvm.org/D127400?vs=435510&id=439380#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127400

Files:
  clang-tools-extra/pseudo/test/cxx/declarator-function.cpp
  clang-tools-extra/pseudo/test/cxx/declarator-var.cpp


Index: clang-tools-extra/pseudo/test/cxx/declarator-var.cpp
===
--- /dev/null
+++ clang-tools-extra/pseudo/test/cxx/declarator-var.cpp
@@ -0,0 +1,11 @@
+// The standard grammar allows an function-body to use any declarator, 
including
+// a non-function declarator. This creates an ambiguity where a
+// simple-declaration is misparsed as a function-definition.
+// FIXME: eliminate this false parse.
+// XFAIL: *
+
+// RUN: clang-pseudo -grammar=%cxx-bnf-file -source=%s --print-forest | 
FileCheck %s
+void (*s)(){};
+// CHECK-NOT:  function-definition
+// CHECK:  init-declarator := declarator initializer
+// CHECK-NOT:  function-definition
Index: clang-tools-extra/pseudo/test/cxx/declarator-function.cpp
===
--- /dev/null
+++ clang-tools-extra/pseudo/test/cxx/declarator-function.cpp
@@ -0,0 +1,11 @@
+// The standard grammar allows an init-list with any declarator, including
+// a function declarator. This creates an ambiguity where a function-definition
+// is misparsed as a simple-declaration.
+// FIXME: eliminate this false parse.
+// XFAIL: *
+
+// RUN: clang-pseudo -grammar=%cxx-bnf-file -source=%s --print-forest | 
FileCheck %s
+void s(){};
+// CHECK-NOT:  simple-declaration
+// CHECK:  function-definition := decl-specifier-seq declarator
+// function-body CHECK-NOT:  simple-declaration


Index: clang-tools-extra/pseudo/test/cxx/declarator-var.cpp
===
--- /dev/null
+++ clang-tools-extra/pseudo/test/cxx/declarator-var.cpp
@@ -0,0 +1,11 @@
+// The standard grammar allows an function-body to use any declarator, including
+// a non-function declarator. This creates an ambiguity where a
+// simple-declaration is misparsed as a function-definition.
+// FIXME: eliminate this false parse.
+// XFAIL: *
+
+// RUN: clang-pseudo -grammar=%cxx-bnf-file -source=%s --print-forest | FileCheck %s
+void (*s)(){};
+// CHECK-NOT:  function-definition
+// CHECK:  init-declarator := declarator initializer
+// CHECK-NOT:  function-definition
Index: clang-tools-extra/pseudo/test/cxx/declarator-function.cpp
===
--- /dev/null
+++ clang-tools-extra/pseudo/test/cxx/declarator-function.cpp
@@ -0,0 +1,11 @@
+// The standard grammar allows an init-list with any declarator, including
+// a function declarator. This creates an ambiguity where a function-definition
+// is misparsed as a simple-declaration.
+// FIXME: eliminate this false parse.
+// XFAIL: *
+
+// RUN: clang-pseudo -grammar=%cxx-bnf-file -source=%s --print-forest | FileCheck %s
+void s(){};
+// CHECK-NOT:  simple-declaration
+// CHECK:  function-definition := decl-specifier-seq declarator
+// function-body CHECK-NOT:  simple-declaration
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D128379: [clangd] Change the url for clang-tidy check documentation

2022-06-23 Thread Sam McCall via Phabricator via cfe-commits
sammccall accepted this revision.
sammccall added a comment.
This revision is now accepted and ready to land.

Thanks!




Comment at: clang-tools-extra/clangd/Diagnostics.cpp:928
+std::tie(Module, Check) = Name.split('-');
+assert(!Module.empty() && !Check.empty());
+return {("https://clang.llvm.org/extra/clang-tidy/checks/"; + Module + "/" +

I don't think we should assert on this, how clang-tidy checks are named isn't 
something clangd can reasonably control.

Instead I'd suggest only returning a value if the condition is met.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128379

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


[PATCH] D128441: [CUDA] Do not embed a fatbinary when using the new driver

2022-06-23 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 created this revision.
jhuber6 added reviewers: jdoerfert, tra, yaxunl.
Herald added subscribers: mattd, carlosgalvezp.
Herald added a project: All.
jhuber6 requested review of this revision.
Herald added subscribers: cfe-commits, sstefan1, MaskRay.
Herald added a project: clang.

Previously, when using the new driver we created a fatbinary with the
PTX and Cubin output. This was mainly done in an attempt to create some
backwards compatibility with the existing CUDA support that embeds the
fatbinary in each TU. This will most likely be more work than necessary
to actually implement. The linker wrapper cannot do anything with these
embedded PTX files because we do not know how to link them, and if we
did want to include multiple files it should go through the
`clang-offload-packager` instead. Also this didn't repsect the setting
that disables embedding PTX (although it wasn't used anyway).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D128441

Files:
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Cuda.cpp
  clang/test/Driver/cuda-openmp-driver.cu
  clang/test/Driver/cuda-phases.cu

Index: clang/test/Driver/cuda-phases.cu
===
--- clang/test/Driver/cuda-phases.cu
+++ clang/test/Driver/cuda-phases.cu
@@ -232,20 +232,14 @@
 // NEW_DRIVER: 6: backend, {5}, assembler, (device-cuda, sm_52)
 // NEW_DRIVER: 7: assembler, {6}, object, (device-cuda, sm_52)
 // NEW_DRIVER: 8: offload, "device-cuda (nvptx64-nvidia-cuda:sm_52)" {7}, object
-// NEW_DRIVER: 9: offload, "device-cuda (nvptx64-nvidia-cuda:sm_52)" {6}, assembler
-// NEW_DRIVER: 10: linker, {8, 9}, cuda-fatbin, (device-cuda, sm_52)
-// NEW_DRIVER: 11: offload, "device-cuda (nvptx64-nvidia-cuda:sm_52)" {10}, cuda-fatbin
-// NEW_DRIVER: 12: input, "[[INPUT]]", cuda, (device-cuda, sm_70)
-// NEW_DRIVER: 13: preprocessor, {12}, cuda-cpp-output, (device-cuda, sm_70)
-// NEW_DRIVER: 14: compiler, {13}, ir, (device-cuda, sm_70)
-// NEW_DRIVER: 15: backend, {14}, assembler, (device-cuda, sm_70)
-// NEW_DRIVER: 16: assembler, {15}, object, (device-cuda, sm_70)
-// NEW_DRIVER: 17: offload, "device-cuda (nvptx64-nvidia-cuda:sm_70)" {16}, object
-// NEW_DRIVER: 18: offload, "device-cuda (nvptx64-nvidia-cuda:sm_70)" {15}, assembler
-// NEW_DRIVER: 19: linker, {17, 18}, cuda-fatbin, (device-cuda, sm_70)
-// NEW_DRIVER: 20: offload, "device-cuda (nvptx64-nvidia-cuda:sm_70)" {19}, cuda-fatbin
-// NEW_DRIVER: 21: clang-offload-packager, {11, 20}, image
-// NEW_DRIVER: 22: offload, " (powerpc64le-ibm-linux-gnu)" {2}, " (powerpc64le-ibm-linux-gnu)" {21}, ir
-// NEW_DRIVER: 23: backend, {22}, assembler, (host-cuda)
-// NEW_DRIVER: 24: assembler, {23}, object, (host-cuda)
-// NEW_DRIVER: 25: clang-linker-wrapper, {24}, image, (host-cuda)
+// NEW_DRIVER: 9: input, "[[INPUT]]", cuda, (device-cuda, sm_70)
+// NEW_DRIVER: 10: preprocessor, {9}, cuda-cpp-output, (device-cuda, sm_70)
+// NEW_DRIVER: 11: compiler, {10}, ir, (device-cuda, sm_70)
+// NEW_DRIVER: 12: backend, {11}, assembler, (device-cuda, sm_70)
+// NEW_DRIVER: 13: assembler, {12}, object, (device-cuda, sm_70)
+// NEW_DRIVER: 14: offload, "device-cuda (nvptx64-nvidia-cuda:sm_70)" {13}, object
+// NEW_DRIVER: 15: clang-offload-packager, {8, 14}, image
+// NEW_DRIVER: 16: offload, " (powerpc64le-ibm-linux-gnu)" {2}, " (powerpc64le-ibm-linux-gnu)" {15}, ir
+// NEW_DRIVER: 17: backend, {16}, assembler, (host-cuda)
+// NEW_DRIVER: 18: assembler, {17}, object, (host-cuda)
+// NEW_DRIVER: 19: clang-linker-wrapper, {18}, image, (host-cuda)
Index: clang/test/Driver/cuda-openmp-driver.cu
===
--- clang/test/Driver/cuda-openmp-driver.cu
+++ clang/test/Driver/cuda-openmp-driver.cu
@@ -5,13 +5,11 @@
 // RUN:--offload-new-driver --offload-arch=sm_35 --offload-arch=sm_70 %s 2>&1 \
 // RUN: | FileCheck -check-prefix BINDINGS %s
 
-// BINDINGS: "nvptx64-nvidia-cuda" - "clang", inputs: ["[[INPUT:.+]]"], output: "[[PTX_SM_35:.+]]"
+//  BINDINGS: "nvptx64-nvidia-cuda" - "clang", inputs: ["[[INPUT:.+]]"], output: "[[PTX_SM_35:.+]]"
 // BINDINGS-NEXT: "nvptx64-nvidia-cuda" - "NVPTX::Assembler", inputs: ["[[PTX_SM_35]]"], output: "[[CUBIN_SM_35:.+]]"
-// BINDINGS-NEXT: "nvptx64-nvidia-cuda" - "NVPTX::Linker", inputs: ["[[CUBIN_SM_35]]", "[[PTX_SM_35]]"], output: "[[FATBIN_SM_35:.+]]"
 // BINDINGS-NEXT: "nvptx64-nvidia-cuda" - "clang", inputs: ["[[INPUT]]"], output: "[[PTX_SM_70:.+]]"
 // BINDINGS-NEXT: "nvptx64-nvidia-cuda" - "NVPTX::Assembler", inputs: ["[[PTX_SM_70:.+]]"], output: "[[CUBIN_SM_70:.+]]"
-// BINDINGS-NEXT: "nvptx64-nvidia-cuda" - "NVPTX::Linker", inputs: ["[[CUBIN_SM_70]]", "[[PTX_SM_70:.+]]"], output: "[[FATBIN_SM_70:.+]]"
-// BINDINGS-NEXT: "x86_64-unknown-linux-gnu" - "Offload::Packager", inputs: ["[[FATBIN_SM_35]]", "[[FATBIN_SM_70]]"], output: "[[BINARY:.+]]"
+// BINDINGS-NEXT: "x86_64-unknown-linux-gnu" - "Offload::Packager", inputs: ["[[CUBIN_SM_3

[PATCH] D128440: [WebAssembly] Initial support for reference type funcref in clang

2022-06-23 Thread Paulo Matos via Phabricator via cfe-commits
pmatos updated this revision to Diff 439383.
pmatos added a comment.

Remove conflict marker


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128440

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/AddressSpaces.h
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/BuiltinsWebAssembly.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Basic/Targets/DirectX.h
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Basic/Targets/SPIR.h
  clang/lib/Basic/Targets/TCE.h
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenTypes.cpp
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/CodeGen/TargetInfo.h
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CodeGen/WebAssembly/wasm-funcref.c
  clang/test/CodeGen/builtins-wasm.c
  llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp

Index: llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp
===
--- llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp
+++ llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp
@@ -404,11 +404,17 @@
 }
 
 //===--===//
-// The following functions are called from lib/CodeGen/Passes.cpp to modify
-// the CodeGen pass sequence.
+// The following functions are called from lib/CodeGen/TargetPassConfig.cpp
+// to modify the CodeGen pass sequence.
 //===--===//
 
 void WebAssemblyPassConfig::addIRPasses() {
+  // Run mem2reg to remove alloca references - needed for reference types
+  // FIXME: this should only be added when the subtarget has reference types 
+  // enabled but the subtarget is dependent on the function being compiled to 
+  // which we don't have access atm.
+  addPass(createPromoteMemoryToRegisterPass());
+
   // Add signatures to prototype-less function declarations
   addPass(createWebAssemblyAddMissingPrototypes());
 
Index: clang/test/CodeGen/builtins-wasm.c
===
--- clang/test/CodeGen/builtins-wasm.c
+++ clang/test/CodeGen/builtins-wasm.c
@@ -1,16 +1,6 @@
-<<< HEAD
 // RUN: %clang_cc1 -triple wasm32-unknown-unknown -target-feature +simd128 -target-feature +relaxed-simd -target-feature +nontrapping-fptoint -target-feature +exception-handling -target-feature +bulk-memory -target-feature +atomics -flax-vector-conversions=none -O3 -emit-llvm -o - %s | FileCheck %s -check-prefixes WEBASSEMBLY,WEBASSEMBLY32
 // RUN: %clang_cc1 -triple wasm64-unknown-unknown -target-feature +simd128 -target-feature +relaxed-simd -target-feature +nontrapping-fptoint -target-feature +exception-handling -target-feature +bulk-memory -target-feature +atomics -flax-vector-conversions=none -O3 -emit-llvm -o - %s | FileCheck %s -check-prefixes WEBASSEMBLY,WEBASSEMBLY64
 // RUN: not %clang_cc1 -triple wasm64-unknown-unknown -target-feature +nontrapping-fptoint -target-feature +exception-handling -target-feature +bulk-memory -target-feature +atomics -flax-vector-conversions=none -O3 -emit-llvm -o - %s 2>&1 | FileCheck %s -check-prefixes MISSING-SIMD
-||| parent of 778dd08813f7 ([WebAssembly] Initial support for reference type externref in clang)
-// RUN: %clang_cc1 -no-opaque-pointers -triple wasm32-unknown-unknown -target-feature +simd128 -target-feature +relaxed-simd -target-feature +nontrapping-fptoint -target-feature +exception-handling -target-feature +bulk-memory -target-feature +atomics -flax-vector-conversions=none -O3 -emit-llvm -o - %s | FileCheck %s -check-prefixes WEBASSEMBLY,WEBASSEMBLY32
-// RUN: %clang_cc1 -no-opaque-pointers -triple wasm64-unknown-unknown -target-feature +simd128 -target-feature +relaxed-simd -target-feature +nontrapping-fptoint -target-feature +exception-handling -target-feature +bulk-memory -target-feature +atomics -flax-vector-conversions=none -O3 -emit-llvm -o - %s | FileCheck %s -check-prefixes WEBASSEMBLY,WEBASSEMBLY64
-// RUN: not %clang_cc1 -no-opaque-pointers -triple wasm64-unknown-unknown -target-feature +nontrapping-fptoint -target-feature +exception-handling -target-feature +bulk-memory -target-feature +atomics -flax-vector-conversions=none -O3 -emit-llvm -o - %s 2>&1 | FileCheck %s -check-prefixes MISSING-SIMD
-===
-// RUN: %clang_cc1 -no-opaque-pointers -triple wasm32-unknown-unknown -target-feature +reference-types -target-feature +simd128 -target-feature +relaxed-simd -target-feature +nontrapping-fptoint -target-feature +exception-handling -target-feature +bulk-memory -target-feature +atomics -flax-vector

[PATCH] D128441: [CUDA] Do not embed a fatbinary when using the new driver

2022-06-23 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 updated this revision to Diff 439384.
jhuber6 added a comment.

Remove comment that is no longer true now that `getInputFilename` always 
returns a `.cubin` variant for object types.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128441

Files:
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Cuda.cpp
  clang/test/Driver/cuda-openmp-driver.cu
  clang/test/Driver/cuda-phases.cu

Index: clang/test/Driver/cuda-phases.cu
===
--- clang/test/Driver/cuda-phases.cu
+++ clang/test/Driver/cuda-phases.cu
@@ -232,20 +232,14 @@
 // NEW_DRIVER: 6: backend, {5}, assembler, (device-cuda, sm_52)
 // NEW_DRIVER: 7: assembler, {6}, object, (device-cuda, sm_52)
 // NEW_DRIVER: 8: offload, "device-cuda (nvptx64-nvidia-cuda:sm_52)" {7}, object
-// NEW_DRIVER: 9: offload, "device-cuda (nvptx64-nvidia-cuda:sm_52)" {6}, assembler
-// NEW_DRIVER: 10: linker, {8, 9}, cuda-fatbin, (device-cuda, sm_52)
-// NEW_DRIVER: 11: offload, "device-cuda (nvptx64-nvidia-cuda:sm_52)" {10}, cuda-fatbin
-// NEW_DRIVER: 12: input, "[[INPUT]]", cuda, (device-cuda, sm_70)
-// NEW_DRIVER: 13: preprocessor, {12}, cuda-cpp-output, (device-cuda, sm_70)
-// NEW_DRIVER: 14: compiler, {13}, ir, (device-cuda, sm_70)
-// NEW_DRIVER: 15: backend, {14}, assembler, (device-cuda, sm_70)
-// NEW_DRIVER: 16: assembler, {15}, object, (device-cuda, sm_70)
-// NEW_DRIVER: 17: offload, "device-cuda (nvptx64-nvidia-cuda:sm_70)" {16}, object
-// NEW_DRIVER: 18: offload, "device-cuda (nvptx64-nvidia-cuda:sm_70)" {15}, assembler
-// NEW_DRIVER: 19: linker, {17, 18}, cuda-fatbin, (device-cuda, sm_70)
-// NEW_DRIVER: 20: offload, "device-cuda (nvptx64-nvidia-cuda:sm_70)" {19}, cuda-fatbin
-// NEW_DRIVER: 21: clang-offload-packager, {11, 20}, image
-// NEW_DRIVER: 22: offload, " (powerpc64le-ibm-linux-gnu)" {2}, " (powerpc64le-ibm-linux-gnu)" {21}, ir
-// NEW_DRIVER: 23: backend, {22}, assembler, (host-cuda)
-// NEW_DRIVER: 24: assembler, {23}, object, (host-cuda)
-// NEW_DRIVER: 25: clang-linker-wrapper, {24}, image, (host-cuda)
+// NEW_DRIVER: 9: input, "[[INPUT]]", cuda, (device-cuda, sm_70)
+// NEW_DRIVER: 10: preprocessor, {9}, cuda-cpp-output, (device-cuda, sm_70)
+// NEW_DRIVER: 11: compiler, {10}, ir, (device-cuda, sm_70)
+// NEW_DRIVER: 12: backend, {11}, assembler, (device-cuda, sm_70)
+// NEW_DRIVER: 13: assembler, {12}, object, (device-cuda, sm_70)
+// NEW_DRIVER: 14: offload, "device-cuda (nvptx64-nvidia-cuda:sm_70)" {13}, object
+// NEW_DRIVER: 15: clang-offload-packager, {8, 14}, image
+// NEW_DRIVER: 16: offload, " (powerpc64le-ibm-linux-gnu)" {2}, " (powerpc64le-ibm-linux-gnu)" {15}, ir
+// NEW_DRIVER: 17: backend, {16}, assembler, (host-cuda)
+// NEW_DRIVER: 18: assembler, {17}, object, (host-cuda)
+// NEW_DRIVER: 19: clang-linker-wrapper, {18}, image, (host-cuda)
Index: clang/test/Driver/cuda-openmp-driver.cu
===
--- clang/test/Driver/cuda-openmp-driver.cu
+++ clang/test/Driver/cuda-openmp-driver.cu
@@ -5,13 +5,11 @@
 // RUN:--offload-new-driver --offload-arch=sm_35 --offload-arch=sm_70 %s 2>&1 \
 // RUN: | FileCheck -check-prefix BINDINGS %s
 
-// BINDINGS: "nvptx64-nvidia-cuda" - "clang", inputs: ["[[INPUT:.+]]"], output: "[[PTX_SM_35:.+]]"
+//  BINDINGS: "nvptx64-nvidia-cuda" - "clang", inputs: ["[[INPUT:.+]]"], output: "[[PTX_SM_35:.+]]"
 // BINDINGS-NEXT: "nvptx64-nvidia-cuda" - "NVPTX::Assembler", inputs: ["[[PTX_SM_35]]"], output: "[[CUBIN_SM_35:.+]]"
-// BINDINGS-NEXT: "nvptx64-nvidia-cuda" - "NVPTX::Linker", inputs: ["[[CUBIN_SM_35]]", "[[PTX_SM_35]]"], output: "[[FATBIN_SM_35:.+]]"
 // BINDINGS-NEXT: "nvptx64-nvidia-cuda" - "clang", inputs: ["[[INPUT]]"], output: "[[PTX_SM_70:.+]]"
 // BINDINGS-NEXT: "nvptx64-nvidia-cuda" - "NVPTX::Assembler", inputs: ["[[PTX_SM_70:.+]]"], output: "[[CUBIN_SM_70:.+]]"
-// BINDINGS-NEXT: "nvptx64-nvidia-cuda" - "NVPTX::Linker", inputs: ["[[CUBIN_SM_70]]", "[[PTX_SM_70:.+]]"], output: "[[FATBIN_SM_70:.+]]"
-// BINDINGS-NEXT: "x86_64-unknown-linux-gnu" - "Offload::Packager", inputs: ["[[FATBIN_SM_35]]", "[[FATBIN_SM_70]]"], output: "[[BINARY:.+]]"
+// BINDINGS-NEXT: "x86_64-unknown-linux-gnu" - "Offload::Packager", inputs: ["[[CUBIN_SM_35]]", "[[CUBIN_SM_70]]"], output: "[[BINARY:.+]]"
 // BINDINGS-NEXT: "x86_64-unknown-linux-gnu" - "clang", inputs: ["[[INPUT]]", "[[BINARY]]"], output: "[[HOST_OBJ:.+]]"
 // BINDINGS-NEXT: "x86_64-unknown-linux-gnu" - "Offload::Linker", inputs: ["[[HOST_OBJ]]"], output: "a.out"
 
@@ -31,7 +29,6 @@
 
 // BINDINGS-DEVICE: # "nvptx64-nvidia-cuda" - "clang", inputs: ["[[INPUT:.+]]"], output: "[[PTX:.+]]"
 // BINDINGS-DEVICE: # "nvptx64-nvidia-cuda" - "NVPTX::Assembler", inputs: ["[[PTX]]"], output: "[[CUBIN:.+]]"
-// BINDINGS-DEVICE: # "nvptx64-nvidia-cuda" - "NVPTX::Linker", inputs: ["[[CUBIN]]", "[[PTX]]"], output: "{{.*}}.fatbin"
 
 // RUN: %cla

[PATCH] D128401: [Clang-tidy] Fixing a bug raising false alarms on static local variables in the Infinite Loop Checker

2022-06-23 Thread Eugene Zelenko via Phabricator via cfe-commits
Eugene.Zelenko added inline comments.



Comment at: clang-tools-extra/clang-tidy/bugprone/InfiniteLoopCheck.cpp:159
+llvm::SmallSet &Callees) {
+if (const CallExpr *Call = dyn_cast(StmtNode)) {
+const Decl *Callee = Call->getDirectCallee();

`auto` could be used, because type is spelled in same statement.



Comment at: clang-tools-extra/clang-tidy/bugprone/InfiniteLoopCheck.cpp:166
+}
+if (const ObjCMessageExpr *Call = dyn_cast(StmtNode)) {
+const ObjCMethodDecl *Callee = Call->getMethodDecl();

Ditto.



Comment at: clang-tools-extra/clang-tidy/bugprone/InfiniteLoopCheck.cpp:200
+static bool hasStaticLocalVariable(const Stmt *Cond) {
+  if (const DeclRefExpr *DRE = dyn_cast(Cond))
+if (const VarDecl *VD = dyn_cast(DRE->getDecl()))

Ditto.



Comment at: clang-tools-extra/clang-tidy/bugprone/InfiniteLoopCheck.cpp:201
+  if (const DeclRefExpr *DRE = dyn_cast(Cond))
+if (const VarDecl *VD = dyn_cast(DRE->getDecl()))
+  if (VD->isStaticLocal())

Ditto.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128401

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


[PATCH] D113107: Support of expression granularity for _Float16.

2022-06-23 Thread Zahira Ammarguellat via Phabricator via cfe-commits
zahiraam updated this revision to Diff 439385.

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

https://reviews.llvm.org/D113107

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGExprComplex.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/CodeGen/X86/Float16-arithmetic.c
  clang/test/CodeGen/X86/Float16-complex.c
  clang/test/CodeGen/X86/avx512fp16-complex.c
  clang/test/Sema/Float16.c
  clang/test/Sema/conversion-target-dep.c
  clang/test/SemaCXX/Float16.cpp

Index: clang/test/SemaCXX/Float16.cpp
===
--- clang/test/SemaCXX/Float16.cpp
+++ clang/test/SemaCXX/Float16.cpp
@@ -1,18 +1,10 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
-// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
 
-#ifdef HAVE
 // expected-no-diagnostics
-#endif // HAVE
 
-#ifndef HAVE
-// expected-error@+2{{_Float16 is not supported on this target}}
-#endif // !HAVE
 _Float16 f;
 
-#ifndef HAVE
-// expected-error@+2{{invalid suffix 'F16' on floating constant}}
-#endif // !HAVE
 const auto g = 1.1F16;
Index: clang/test/Sema/conversion-target-dep.c
===
--- clang/test/Sema/conversion-target-dep.c
+++ clang/test/Sema/conversion-target-dep.c
@@ -6,7 +6,7 @@
 
 long double ld;
 double d;
-_Float16 f16; // x86-error {{_Float16 is not supported on this target}}
+_Float16 f16;
 
 int main(void) {
   ld = d; // x86-warning {{implicit conversion increases floating-point precision: 'double' to 'long double'}}
Index: clang/test/Sema/Float16.c
===
--- clang/test/Sema/Float16.c
+++ clang/test/Sema/Float16.c
@@ -1,18 +1,12 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
-// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc -target-feature +avx512fp16 %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc -target-feature +avx512fp16 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
 
-#ifndef HAVE
-// expected-error@+2{{_Float16 is not supported on this target}}
-#endif // HAVE
-_Float16 f;
-
-#ifdef HAVE
 _Complex _Float16 a;
 void builtin_complex(void) {
   _Float16 a = 0;
   (void)__builtin_complex(a, a); // expected-error {{'_Complex _Float16' is invalid}}
 }
-#endif
+
Index: clang/test/CodeGen/X86/Float16-complex.c
===
--- clang/test/CodeGen/X86/Float16-complex.c
+++ clang/test/CodeGen/X86/Float16-complex.c
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -target-feature +avx512fp16 -o - | FileCheck %s --check-prefix=X86
+// RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -o - | FileCheck %s --check-prefixes=X86-PROM
 
 _Float16 _Complex add_half_rr(_Float16 a, _Float16 b) {
   // X86-LABEL: @add_half_rr(
@@ -85,7 +86,29 @@
   return a * b;
 }
 _Float16 _Complex mul_half_cc(_Float16 _Complex a, _Float16 _Complex b) {
-  // X86-LABEL: @mul_half_cc(
+  // CHECK: @mul_half_cc(
+
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: %[[AC:[^ ]+]] = fmul float
+  // X86-PROM: %[[BD:[^ ]+]] = fmul float
+  // X86-PROM: %[[AD:[^ ]+]] = fmul float
+  // X86-PROM: %[[BC:[^ ]+]] = fmul float
+  // X86-PROM: %[[RR:[^ ]+]] = fsub float
+  // X86-PROM: %[[RI:[^ ]+]] = fadd float
+  // X86-PROM: fcmp uno float %[[RR]]
+  // X86-PROM: fcmp uno float %[[RI]]
+  // X86-PROM: call <2 x float> @__mulsc3(
+  // X86-PROM: fptrunc float {{.*}} to half
+  // X86-PROM: fptrunc float {{.*}} to half
+  // X86-PROM: %[[RETR:[^ ]+]] = getelementptr inbounds { half, half }
+  // X86-PROM: %[[RETI:[^ ]+]] = getelementptr inbounds { half, half }
+  // X86-PROM: store half {{.*}}, ptr %[[RETR]]
+  // X86-PROM: store half {{.*}}, ptr %[[RETI]]
+  // X86-PROM: load <

[clang] 342e649 - [Sema] Fix assertion failure when instantiating requires expression

2022-06-23 Thread Ilya Biryukov via cfe-commits

Author: Ilya Biryukov
Date: 2022-06-23T16:20:30+02:00
New Revision: 342e64979afe0b3859462397c4a8abba6faa9de0

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

LOG: [Sema] Fix assertion failure when instantiating requires expression

Fixes #54629.
The crash is is caused by the double template instantiation.
See the added test. Here is what happens:
- Template arguments for the partial specialization get instantiated.
- This causes instantitation into the corrensponding requires
  expression.
- `TemplateInsantiator` correctly handles instantiation of parameters
  inside `RequiresExprBody` and instantiates the constraint expression
  inside the `NestedRequirement`.
- To build the substituted `NestedRequirement`, `TemplateInsantiator`
  calls `Sema::BuildNestedRequirement` calls
  `CheckConstraintSatisfaction`, which results in another template
  instantiation (with empty template arguments). This seem to be an
  implementation detail to handle constraint satisfaction and is not
  required by the standard.
- The recursive template instantiation tries to find the parameter
  inside `RequiresExprBody` and fails with the corresponding assertion.

Note that this only happens as both instantiations happen with the class
partial template specialization set as `Sema.CurContext`, which is
considered a dependent `DeclContext`.

To fix the assertion, avoid doing the recursive template instantiation
and instead evaluate resulting expressions in-place.

Reviewed By: erichkeane

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

Added: 
clang/test/SemaTemplate/concepts-PR54629.cpp

Modified: 
clang/lib/Sema/SemaConcept.cpp
clang/lib/Sema/SemaTemplateInstantiate.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaConcept.cpp b/clang/lib/Sema/SemaConcept.cpp
index c78b0df6ff488..239e5dc4394c3 100644
--- a/clang/lib/Sema/SemaConcept.cpp
+++ b/clang/lib/Sema/SemaConcept.cpp
@@ -348,8 +348,9 @@ bool Sema::CheckConstraintSatisfaction(const Expr 
*ConstraintExpr,
ConstraintSatisfaction &Satisfaction) {
   return calculateConstraintSatisfaction(
   *this, ConstraintExpr, Satisfaction,
-  [](const Expr *AtomicExpr) -> ExprResult {
-return ExprResult(const_cast(AtomicExpr));
+  [this](const Expr *AtomicExpr) -> ExprResult {
+// We only do this to immitate lvalue-to-rvalue conversion.
+return PerformContextuallyConvertToBool(const_cast(AtomicExpr));
   });
 }
 

diff  --git a/clang/lib/Sema/SemaTemplateInstantiate.cpp 
b/clang/lib/Sema/SemaTemplateInstantiate.cpp
index 8e59c449ae656..0187cb3d12dd8 100644
--- a/clang/lib/Sema/SemaTemplateInstantiate.cpp
+++ b/clang/lib/Sema/SemaTemplateInstantiate.cpp
@@ -10,12 +10,14 @@
 //===--===/
 
 #include "TreeTransform.h"
+#include "clang/AST/ASTConcept.h"
 #include "clang/AST/ASTConsumer.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/ASTLambda.h"
 #include "clang/AST/ASTMutationListener.h"
 #include "clang/AST/DeclTemplate.h"
 #include "clang/AST/Expr.h"
+#include "clang/AST/ExprConcepts.h"
 #include "clang/AST/PrettyDeclStackTrace.h"
 #include "clang/AST/TypeVisitor.h"
 #include "clang/Basic/LangOptions.h"
@@ -2022,6 +2024,7 @@ TemplateInstantiator::TransformNestedRequirement(
   Req->getConstraintExpr()->getSourceRange());
 
   ExprResult TransConstraint;
+  ConstraintSatisfaction Satisfaction;
   TemplateDeductionInfo Info(Req->getConstraintExpr()->getBeginLoc());
   {
 EnterExpressionEvaluationContext ContextRAII(
@@ -2033,6 +2036,25 @@ TemplateInstantiator::TransformNestedRequirement(
 if (ConstrInst.isInvalid())
   return nullptr;
 TransConstraint = TransformExpr(Req->getConstraintExpr());
+if (!TransConstraint.isInvalid()) {
+  bool CheckSucceeded =
+  SemaRef.CheckConstraintExpression(TransConstraint.get());
+  (void)CheckSucceeded;
+  assert(CheckSucceeded || Trap.hasErrorOccurred() &&
+   "CheckConstraintExpression failed, but "
+   "did not produce a SFINAE error");
+}
+// Use version of CheckConstraintSatisfaction that does no substitutions.
+if (!TransConstraint.isInvalid() &&
+!TransConstraint.get()->isInstantiationDependent() &&
+!Trap.hasErrorOccurred()) {
+  bool CheckFailed = SemaRef.CheckConstraintSatisfaction(
+  TransConstraint.get(), Satisfaction);
+  (void)CheckFailed;
+  assert(!CheckFailed || Trap.hasErrorOccurred() &&
+ "CheckConstraintSatisfaction failed, "
+ "but did not produce a SFINAE error");
+}
 if (TransConstraint.isInvalid() || Trap.hasErr

[PATCH] D127487: [Sema] Fix assertion failure when instantiating requires expression

2022-06-23 Thread Ilya Biryukov 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 rG342e64979afe: [Sema] Fix assertion failure when 
instantiating requires expression (authored by ilya-biryukov).

Changed prior to commit:
  https://reviews.llvm.org/D127487?vs=438977&id=439387#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127487

Files:
  clang/lib/Sema/SemaConcept.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/test/SemaTemplate/concepts-PR54629.cpp

Index: clang/test/SemaTemplate/concepts-PR54629.cpp
===
--- /dev/null
+++ clang/test/SemaTemplate/concepts-PR54629.cpp
@@ -0,0 +1,58 @@
+// RUN: %clang_cc1 -std=c++20 -verify %s
+
+template 
+struct A {
+  void primary();
+};
+
+template 
+  requires requires(T &t) { requires sizeof(t) > 4; }
+struct A {
+  void specialization1();
+};
+
+template 
+  requires requires(T &t) { requires sizeof(t) > 8; }
+struct A {
+  void specialization2();
+};
+
+int main() {
+  A().primary();
+  A().specialization1();
+  A(); // expected-error {{ambiguous partial specialization}}
+ // expected-note@10 {{partial specialization matches [with T = char[16]}}
+ // expected-note@16 {{partial specialization matches [with T = char[16]}}
+}
+
+// Check error messages when no overload with constraints matches.
+template 
+void foo()
+  requires requires(T &t) { requires sizeof(t) < 4; }
+{}
+
+template 
+void foo()
+  requires requires(T &t) { requires sizeof(t) > 4; }
+{}
+
+template 
+void foo()
+  requires requires(T &t) { requires sizeof(t) > 8; }
+{}
+
+void test() {
+  foo();
+  // expected-error@-1 {{no matching function for call to 'foo'}}
+  // expected-note@30 {{candidate template ignored: constraints not satisfied}}
+  // expected-note@31 {{because 'sizeof (t) < 4' (4 < 4) evaluated to false}}
+  // expected-note@35 {{candidate template ignored: constraints not satisfied}}
+  // expected-note@36 {{because 'sizeof (t) > 4' (4 > 4) evaluated to false}}
+  // expected-note@40 {{candidate template ignored: constraints not satisfied}}
+  // expected-note@41 {{because 'sizeof (t) > 8' (4 > 8) evaluated to false}}
+
+  foo();
+  // expected-error@-1 {{call to 'foo' is ambiguous}}
+  // expected-note@35 {{candidate function}}
+  // expected-note@40 {{candidate function}}
+}
Index: clang/lib/Sema/SemaTemplateInstantiate.cpp
===
--- clang/lib/Sema/SemaTemplateInstantiate.cpp
+++ clang/lib/Sema/SemaTemplateInstantiate.cpp
@@ -10,12 +10,14 @@
 //===--===/
 
 #include "TreeTransform.h"
+#include "clang/AST/ASTConcept.h"
 #include "clang/AST/ASTConsumer.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/ASTLambda.h"
 #include "clang/AST/ASTMutationListener.h"
 #include "clang/AST/DeclTemplate.h"
 #include "clang/AST/Expr.h"
+#include "clang/AST/ExprConcepts.h"
 #include "clang/AST/PrettyDeclStackTrace.h"
 #include "clang/AST/TypeVisitor.h"
 #include "clang/Basic/LangOptions.h"
@@ -2022,6 +2024,7 @@
   Req->getConstraintExpr()->getSourceRange());
 
   ExprResult TransConstraint;
+  ConstraintSatisfaction Satisfaction;
   TemplateDeductionInfo Info(Req->getConstraintExpr()->getBeginLoc());
   {
 EnterExpressionEvaluationContext ContextRAII(
@@ -2033,6 +2036,25 @@
 if (ConstrInst.isInvalid())
   return nullptr;
 TransConstraint = TransformExpr(Req->getConstraintExpr());
+if (!TransConstraint.isInvalid()) {
+  bool CheckSucceeded =
+  SemaRef.CheckConstraintExpression(TransConstraint.get());
+  (void)CheckSucceeded;
+  assert(CheckSucceeded || Trap.hasErrorOccurred() &&
+   "CheckConstraintExpression failed, but "
+   "did not produce a SFINAE error");
+}
+// Use version of CheckConstraintSatisfaction that does no substitutions.
+if (!TransConstraint.isInvalid() &&
+!TransConstraint.get()->isInstantiationDependent() &&
+!Trap.hasErrorOccurred()) {
+  bool CheckFailed = SemaRef.CheckConstraintSatisfaction(
+  TransConstraint.get(), Satisfaction);
+  (void)CheckFailed;
+  assert(!CheckFailed || Trap.hasErrorOccurred() &&
+ "CheckConstraintSatisfaction failed, "
+ "but did not produce a SFINAE error");
+}
 if (TransConstraint.isInvalid() || Trap.hasErrorOccurred())
   return RebuildNestedRequirement(createSubstDiag(SemaRef, Info,
   [&] (llvm::raw_ostream& OS) {
@@ -2040,7 +2062,11 @@
 SemaRef.getPrintingPolicy());
   }));
   }
-  return RebuildNestedRequirement(TransConstraint.get());
+  if (TransConstraint

[PATCH] D128048: Add a new clang option "-ftime-trace-path"

2022-06-23 Thread dongjunduo via Phabricator via cfe-commits
dongjunduo updated this revision to Diff 439389.
dongjunduo added a comment.

[Clang] change directory-store to path-store


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128048

Files:
  clang/include/clang/Driver/Options.td
  clang/include/clang/Frontend/FrontendOptions.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/check-time-trace-path.cpp
  clang/tools/driver/cc1_main.cpp


Index: clang/tools/driver/cc1_main.cpp
===
--- clang/tools/driver/cc1_main.cpp
+++ clang/tools/driver/cc1_main.cpp
@@ -255,7 +255,12 @@
 
   if (llvm::timeTraceProfilerEnabled()) {
 SmallString<128> Path(Clang->getFrontendOpts().OutputFile);
-llvm::sys::path::replace_extension(Path, "json");
+if (Clang->getFrontendOpts().TimeTracePath.empty()) {
+  // replace the suffix to '.json' directly
+  llvm::sys::path::replace_extension(Path, "json");
+} else {
+  Path.assign(Clang->getFrontendOpts().TimeTracePath);
+}
 if (auto profilerOutput = Clang->createOutputFile(
 Path.str(), /*Binary=*/false, /*RemoveFileOnSignal=*/false,
 /*useTemporary=*/false)) {
Index: clang/test/Driver/check-time-trace-path.cpp
===
--- /dev/null
+++ clang/test/Driver/check-time-trace-path.cpp
@@ -0,0 +1,29 @@
+// RUN: %clangxx -S -ftime-trace -ftime-trace-path=%T/new-name.json 
-ftime-trace-granularity=0 -o %T/check-time-trace %s
+// RUN: cat %T/new-name.json \
+// RUN:   | %python -c 'import json, sys; 
json.dump(json.loads(sys.stdin.read()), sys.stdout, sort_keys=True, indent=2)' \
+// RUN:   | FileCheck %s
+
+// CHECK:  "beginningOfTime": {{[0-9]{16},}}
+// CHECK-NEXT: "traceEvents": [
+// CHECK:  "args":
+// CHECK:  "detail":
+// CHECK:  "dur":
+// CHECK:  "name":
+// CHECK-NEXT: "ph":
+// CHECK-NEXT: "pid":
+// CHECK-NEXT: "tid":
+// CHECK-NEXT: "ts":
+// CHECK:  "name": "clang{{.*}}"
+// CHECK:  "name": "process_name"
+// CHECK:  "name": "thread_name"
+
+template 
+struct Struct {
+  T Num;
+};
+
+int main() {
+  Struct S;
+
+  return 0;
+}
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -6183,6 +6183,7 @@
   Args.AddLastArg(CmdArgs, options::OPT_ftime_report_EQ);
   Args.AddLastArg(CmdArgs, options::OPT_ftime_trace);
   Args.AddLastArg(CmdArgs, options::OPT_ftime_trace_granularity_EQ);
+  Args.AddLastArg(CmdArgs, options::OPT_ftime_trace_path);
   Args.AddLastArg(CmdArgs, options::OPT_ftrapv);
   Args.AddLastArg(CmdArgs, options::OPT_malign_double);
   Args.AddLastArg(CmdArgs, options::OPT_fno_temp_file);
Index: clang/include/clang/Frontend/FrontendOptions.h
===
--- clang/include/clang/Frontend/FrontendOptions.h
+++ clang/include/clang/Frontend/FrontendOptions.h
@@ -499,6 +499,9 @@
   /// Minimum time granularity (in microseconds) traced by time profiler.
   unsigned TimeTraceGranularity;
 
+  /// Path which stores the output files for -ftime-trace
+  std::string TimeTracePath;
+
 public:
   FrontendOptions()
   : DisableFree(false), RelocatablePCH(false), ShowHelp(false),
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -2828,6 +2828,10 @@
   HelpText<"Minimum time granularity (in microseconds) traced by time 
profiler">,
   Flags<[CC1Option, CoreOption]>,
   MarshallingInfoInt, "500u">;
+def ftime_trace_path : Joined<["-"], "ftime-trace-path=">, Group,
+  HelpText<"Path which stores the output files for -ftime-trace">,
+  Flags<[CC1Option, CoreOption]>,
+  MarshallingInfoString>;
 def fproc_stat_report : Joined<["-"], "fproc-stat-report">, Group,
   HelpText<"Print subprocess statistics">;
 def fproc_stat_report_EQ : Joined<["-"], "fproc-stat-report=">, Group,


Index: clang/tools/driver/cc1_main.cpp
===
--- clang/tools/driver/cc1_main.cpp
+++ clang/tools/driver/cc1_main.cpp
@@ -255,7 +255,12 @@
 
   if (llvm::timeTraceProfilerEnabled()) {
 SmallString<128> Path(Clang->getFrontendOpts().OutputFile);
-llvm::sys::path::replace_extension(Path, "json");
+if (Clang->getFrontendOpts().TimeTracePath.empty()) {
+  // replace the suffix to '.json' directly
+  llvm::sys::path::replace_extension(Path, "json");
+} else {
+  Path.assign(Clang->getFrontendOpts().TimeTracePath);
+}
 if (auto profilerOutput = Clang->createOutputFile(
 Path.str(), /*Binary=*/false, /*RemoveFileOnSignal=*/false,
 /*useTemporary=*/false)) {
Index: clang/test/Driver/check-time-trace-path.c

[PATCH] D128097: [Clang] Fix compile time regression caused by D126061.

2022-06-23 Thread Martin Böhme via Phabricator via cfe-commits
mboehme added a comment.

To add to the points that @yurai007 pointed out, I’ve done some more 
investigation of my own.

**Compile-time regression does not seem to reproduce locally**

Unfortunately, I still haven’t been able to get the test suite running locally. 
However, I’ve looked at some individual lencod input files which I’m able to 
compile and which still show a slowdown on 
http://llvm-compile-time-tracker.com/ even after 
https://reviews.llvm.org/D128097.

What is confusing to me is that I am not able to reproduce the slowdown. For 
comparison, here are the instruction counts from 
http://llvm-compile-time-tracker.com/ and the counts I am measuring locally.

At 7acc88be0312c721bc082ed9934e381d297f4707 
 (the 
commit directly before https://reviews.llvm.org/D126061):

| Input file | Tracker | Own measurement |
| lencod/mb_access.c | 139M| 162,006,571 |
| lencod/md_low.c| 227M| 264,179,977 |
|

At 0d300da799b06931eb6b974198d683548a8c8392 
 (the 
commit that landed https://reviews.llvm.org/D128097):

| Input file | Tracker   | Own measurement  |
| lencod/mb_access.c | 141M (+0.88%) | 161,322,974 (-0.42%) |
| lencod/md_low.c| 228M (+0.57%) | 263,455,713 (-0.27%) |
|

Note that not only the direction of change is different, but also the absolute 
magnitude of instruction counts.

I built Clang with `-DCMAKE_BUILD_TYPE=Release` and ran Clang with `-O0 -g -c 
-o /dev/null`. Maybe http://llvm-compile-time-tracker.com/ is doing something 
slightly different here? However, I suspect the more important factor for the 
direction of the change may be my local system headers, which are likely 
different to what http://llvm-compile-time-tracker.com/ is using. At any rate, 
this is frustrating because I’m not able to reproduce the issue. If it comes to 
it, would it be possible to obtain a preprocessed version of the input files 
(i.e. run with `-E`)?

**Overall, compile times have //improved// in terms of cycle count (though not 
instruction count)**

All of the above may be a moot point because I’ve noticed that the picture 
looks significantly different when looking at instructions versus cycle counts. 
The numbers I quoted in an earlier comment are for instruction counts (which is 
also the metric that @nikic used when originally raising this issue on 
https://reviews.llvm.org/D126061). Here are the same comparisons I showed 
earlier, with numbers taken from http://llvm-compile-time-tracker.com, but 
looking at cycle counts in addition to instruction counts (geomean for -O0 
compiles in each case, titles link to the compile time tracker):

Compile-time regression caused by D126061 

Instructions: +0.35%
Cycles: +0.30%

Improvement due to this patch (D128097) 

Instructions: -0.18%
Cycles: -1.54%

Cumulative change from before D126061 landed until after this patch (D128097) 
landed 

Instructions: +0.22%
Cycles: -1.09%

So in terms of cycle count, which is arguably the more important metric, the 
overall effect of the two changes is over 1% improvement in compile times. It 
would of course be great if we could reduce the regression on instruction 
counts too, but given that we have a marked improvement in cycle count, I think 
that may already be an acceptable result?

@nikic, I would appreciate your input here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128097

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


[PATCH] D128048: Add a new clang option "-ftime-trace-path"

2022-06-23 Thread dongjunduo via Phabricator via cfe-commits
dongjunduo added a comment.

Hi @jamieschmeiser @Whitney ,

I have changed the approach from directory-store to path-store, so that the 
user can specify the aim path to store the time trace json file.  
If "-ftime-trace-path" is not specified, it will follow the default behavior.

In addition, I add a test-case to test the new option.

PTAL : )


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128048

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


[PATCH] D127976: [IR] Move vector.insert/vector.extract out of experimental namespace

2022-06-23 Thread Paul Walker via Phabricator via cfe-commits
paulwalker-arm accepted this revision.
paulwalker-arm added inline comments.



Comment at: llvm/docs/LangRef.rst:17282
+  declare  @llvm.vector.insert.nxv4f32.v4f32( %vec, <4 x float> %subvec, i64 %idx)
+  declare  @llvm.vector.insert.nxv2f64.v2f64( %vec, <2 x double> %subvec, i64 %idx)
+

For this and the other instances, please remove the `%` as idx must be a 
literal (as documented below) but using `%idx` makes it look like an arbitrary 
variable can be used.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127976

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


[PATCH] D128401: [clang-tidy] Fixing a bug raising false alarms on static local variables in the Infinite Loop Checker

2022-06-23 Thread Dmitri Gribenko via Phabricator via cfe-commits
gribozavr2 accepted this revision.
gribozavr2 added inline comments.
This revision is now accepted and ready to land.



Comment at: clang-tools-extra/clang-tidy/bugprone/InfiniteLoopCheck.cpp:159
+llvm::SmallSet &Callees) {
+if (const CallExpr *Call = dyn_cast(StmtNode)) {
+const Decl *Callee = Call->getDirectCallee();

Eugene.Zelenko wrote:
> `auto` could be used, because type is spelled in same statement.
Please clang-format before submitting (it looks like this block is indented 4 
instead of 2).



Comment at: clang-tools-extra/clang-tidy/bugprone/InfiniteLoopCheck.cpp:184-185
+const Decl *Func) {
+  bool containsFunc = false;
+  bool overlap = false;
+





Comment at: clang-tools-extra/clang-tidy/bugprone/InfiniteLoopCheck.cpp:188-191
+const Decl *CanoDecl = GNode->getDecl()->getCanonicalDecl();
+
+containsFunc |= (CanoDecl == Func);
+overlap |= Callees.contains(CanoDecl);

Canonical => Can is the usual abbreviation, if you want to use one (e.g., see 
CanQualType)



Comment at: clang-tools-extra/clang-tidy/bugprone/InfiniteLoopCheck.cpp:198-199
+
+/// returns true iff `Cond` involves at least one static local variable.
+static bool hasStaticLocalVariable(const Stmt *Cond) {
+  if (const DeclRefExpr *DRE = dyn_cast(Cond))





Comment at: clang-tools-extra/clang-tidy/bugprone/InfiniteLoopCheck.cpp:210
+
+/// Tests if the loop `Cond` involves static local variables and
+/// the enclosing function `Func` is recursive.

`Cond` is not the loop itself.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128401

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


[PATCH] D128446: [clang][dataflow] Use annotations for optional diagnostic tests

2022-06-23 Thread Sam Estep via Phabricator via cfe-commits
samestep created this revision.
Herald added subscribers: martong, tschuett, xazax.hun.
Herald added a project: All.
samestep 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/D128446

Files:
  clang/unittests/Analysis/FlowSensitive/TestingSupport.h
  clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp
@@ -11,7 +11,6 @@
 #include "TestingSupport.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/ASTMatchers/ASTMatchers.h"
-#include "clang/Analysis/FlowSensitive/SourceLocationsLattice.h"
 #include "clang/Basic/SourceLocation.h"
 #include "clang/Tooling/Tooling.h"
 #include "llvm/ADT/ArrayRef.h"
@@ -28,6 +27,8 @@
 using namespace dataflow;
 using namespace test;
 
+using ::testing::ContainerEq;
+
 // FIXME: Move header definitions in separate file(s).
 static constexpr char CSDtdDefHeader[] = R"(
 #ifndef CSTDDEF_H
@@ -1179,12 +1180,6 @@
 } // namespace base
 )";
 
-/// Converts `L` to string.
-static std::string ConvertToString(const llvm::DenseSet &L,
-   const ASTContext &Ctx) {
-  return L.empty() ? "safe" : "unsafe: " + DebugString(L, Ctx);
-}
-
 /// Replaces all occurrences of `Pattern` in `S` with `Replacement`.
 static void ReplaceAllOccurrences(std::string &S, const std::string &Pattern,
   const std::string &Replacement) {
@@ -1205,18 +1200,14 @@
 class UncheckedOptionalAccessTest
 : public ::testing::TestWithParam {
 protected:
-  template 
-  void ExpectLatticeChecksFor(std::string SourceCode,
-  LatticeChecksMatcher MatchesLatticeChecks) {
-ExpectLatticeChecksFor(SourceCode, ast_matchers::hasName("target"),
-   MatchesLatticeChecks);
+  void ExpectDiagnosticsFor(std::string SourceCode) {
+ExpectDiagnosticsFor(SourceCode, ast_matchers::hasName("target"));
   }
 
 private:
-  template 
-  void ExpectLatticeChecksFor(std::string SourceCode,
-  FuncDeclMatcher FuncMatcher,
-  LatticeChecksMatcher MatchesLatticeChecks) {
+  template 
+  void ExpectDiagnosticsFor(std::string SourceCode,
+FuncDeclMatcher FuncMatcher) {
 ReplaceAllOccurrences(SourceCode, "$ns", GetParam().NamespaceName);
 ReplaceAllOccurrences(SourceCode, "$optional", GetParam().TypeName);
 
@@ -1260,10 +1251,30 @@
 return Diagnosis.diagnose(Stmt, Env);
   };
 },
-[&MatchesLatticeChecks](llvm::DenseSet Locs,
-ASTContext &Ctx) {
-  std::string StringifiedDiags = ConvertToString(Locs, Ctx);
-  EXPECT_THAT(StringifiedDiags, MatchesLatticeChecks);
+[](llvm::DenseMap &Annotations,
+   llvm::DenseSet &Locs, ASTContext &Ctx) {
+  auto &SrcMgr = Ctx.getSourceManager();
+
+  llvm::DenseSet AnnotationLines;
+  for (const auto &Pair : Annotations) {
+auto *Stmt = Pair.getFirst();
+AnnotationLines.insert(
+SrcMgr.getPresumedLineNumber(Stmt->getBeginLoc()));
+// We add both the begin and end locations, so that if the
+// statement spans multiple lines then the test will fail. Going
+// forward, we should change this to instead just get the single
+// line number from the annotation itself, rather than looking
+// at the statement it's attached to.
+AnnotationLines.insert(
+SrcMgr.getPresumedLineNumber(Stmt->getEndLoc()));
+  }
+
+  llvm::DenseSet DiagnosticLines;
+  for (SourceLocation &Loc : Locs) {
+DiagnosticLines.insert(SrcMgr.getPresumedLineNumber(Loc));
+  }
+
+  EXPECT_THAT(DiagnosticLines, ContainerEq(AnnotationLines));
 },
 {"-fsyntax-only", "-std=c++17", "-Wno-undefined-inline"},
 FileContents);
@@ -1282,65 +1293,55 @@
 });
 
 TEST_P(UncheckedOptionalAccessTest, EmptyFunctionBody) {
-  ExpectLatticeChecksFor(R"(
+  ExpectDiagnosticsFor(R"(
 void target() {
   (void)0;
-  /*[[check]]*/
 }
-  )",
- "safe");
+  )");
 }
 
 TEST_P(UncheckedOptionalAccessTest, UnwrapUsingValueNoCheck) {
-  ExpectLatticeChecksFor(
+  ExpectDiagnosticsFor(
   R"(
 #include "unchecked_optional_access_test.h"
 
 void target($ns::$optional opt) {
-  opt.value();
-  /*[[check]]*/
+  opt.val

[PATCH] D126857: [HLSL] Add WaveActiveCountBits as Langugage builtin function for HLSL

2022-06-23 Thread Chris Bieneman via Phabricator via cfe-commits
beanz added inline comments.



Comment at: clang/include/clang/Basic/Builtins.def:1697
+// HLSL
+LANGBUILTIN(WaveActiveCountBits, "Uib", "nc", HLSL_LANG)
+

python3kgae wrote:
> Anastasia wrote:
> > python3kgae wrote:
> > > Anastasia wrote:
> > > > FYI we most of time try to add a builtin name using a reserved 
> > > > identifier which is not part of the language standard (mostly prefixed 
> > > > by `__`). Then we add regular function that just calls the clang 
> > > > builtins. This way provides more flexibility to the implementers. 
> > > > However you might not need this... in which case using original name 
> > > > avoids an extra call.
> > > Yes. For this one, it is without prefix to avoid extra call.
> > > I'm following things like enqueue_kernel in opencl.
> > > For other things support overload which has to make extra call, I'll add 
> > > the prefix.
> > Ok, although `enqueue_kernel` was implemented as a builtin because it has a 
> > weird variadic prototype that can't be implemented using normal features of 
> > C/C++ languages. Hence it is a builtin with custom SemaChecking.
> I see.
> Since HLSL also has things cannot implemented using HLSL itself, we cannot
>put all HLSL intrinsic in one place anyway.
> So when it is possible to reduce an extra call, I just reduce it.
I don't think this was the right decision. It is trivial for the optimizer to 
remove a function that is more or less a tail-call of another function, and 
since HLSL has no call semantics anyways they will disappear.

It would be much better if this was a function that called the builtin, this 
could even be trivially implemented as a sub-header of hlsl.h as a wrapper 
function. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126857

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


[PATCH] D126864: [clang] Introduce -fstrict-flex-arrays= for stricter handling of flexible arrays

2022-06-23 Thread Kees Cook via Phabricator via cfe-commits
kees added a comment.

In D126864#3598257 , 
@serge-sans-paille wrote:

> @kees does the new version looks good to you?

Hi, yes, this is working as expected in my kernel builds. Yay! :)


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

https://reviews.llvm.org/D126864

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


[PATCH] D128448: [clang][dataflow] Delete SourceLocationsLattice

2022-06-23 Thread Sam Estep via Phabricator via cfe-commits
samestep created this revision.
Herald added subscribers: martong, tschuett, mgrang, xazax.hun, mgorny.
Herald added a project: All.
samestep requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D128448

Files:
  clang/docs/tools/clang-formatted-files.txt
  clang/include/clang/Analysis/FlowSensitive/SourceLocationsLattice.h
  clang/lib/Analysis/FlowSensitive/CMakeLists.txt
  clang/lib/Analysis/FlowSensitive/SourceLocationsLattice.cpp
  clang/unittests/Analysis/FlowSensitive/CMakeLists.txt
  clang/unittests/Analysis/FlowSensitive/SourceLocationsLatticeTest.cpp
  llvm/utils/gn/secondary/clang/lib/Analysis/FlowSensitive/BUILD.gn
  llvm/utils/gn/secondary/clang/unittests/Analysis/FlowSensitive/BUILD.gn

Index: llvm/utils/gn/secondary/clang/unittests/Analysis/FlowSensitive/BUILD.gn
===
--- llvm/utils/gn/secondary/clang/unittests/Analysis/FlowSensitive/BUILD.gn
+++ llvm/utils/gn/secondary/clang/unittests/Analysis/FlowSensitive/BUILD.gn
@@ -25,7 +25,6 @@
 "MultiVarConstantPropagationTest.cpp",
 "SingleVarConstantPropagationTest.cpp",
 "SolverTest.cpp",
-"SourceLocationsLatticeTest.cpp",
 "TestingSupport.cpp",
 "TestingSupportTest.cpp",
 "TransferTest.cpp",
Index: llvm/utils/gn/secondary/clang/lib/Analysis/FlowSensitive/BUILD.gn
===
--- llvm/utils/gn/secondary/clang/lib/Analysis/FlowSensitive/BUILD.gn
+++ llvm/utils/gn/secondary/clang/lib/Analysis/FlowSensitive/BUILD.gn
@@ -9,7 +9,6 @@
 "ControlFlowContext.cpp",
 "DataflowAnalysisContext.cpp",
 "DataflowEnvironment.cpp",
-"SourceLocationsLattice.cpp",
 "Transfer.cpp",
 "TypeErasedDataflowAnalysis.cpp",
 "WatchedLiteralsSolver.cpp",
Index: clang/unittests/Analysis/FlowSensitive/SourceLocationsLatticeTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/SourceLocationsLatticeTest.cpp
+++ /dev/null
@@ -1,68 +0,0 @@
-//===- unittests/Analysis/FlowSensitive/SourceLocationsLatticeTest.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 "clang/Analysis/FlowSensitive/SourceLocationsLattice.h"
-
-#include "clang/Analysis/FlowSensitive/DataflowLattice.h"
-#include "clang/Basic/SourceLocation.h"
-#include "gmock/gmock.h"
-#include "gtest/gtest.h"
-
-namespace clang {
-namespace dataflow {
-namespace {
-
-TEST(SourceLocationsLatticeTest, Comparison) {
-  const SourceLocationsLattice Bottom;
-  const SourceLocationsLattice NonBottom(
-  {SourceLocation::getFromRawEncoding(0)});
-
-  EXPECT_TRUE(Bottom == Bottom);
-  EXPECT_FALSE(Bottom == NonBottom);
-  EXPECT_FALSE(NonBottom == Bottom);
-  EXPECT_TRUE(NonBottom == NonBottom);
-
-  EXPECT_FALSE(Bottom != Bottom);
-  EXPECT_TRUE(Bottom != NonBottom);
-  EXPECT_TRUE(NonBottom != Bottom);
-  EXPECT_FALSE(NonBottom != NonBottom);
-}
-
-TEST(SourceLocationsLatticeTest, Join) {
-  const SourceLocationsLattice Bottom;
-  const SourceLocationsLattice NonBottom(
-  {SourceLocation::getFromRawEncoding(0)});
-  {
-SourceLocationsLattice LHS = Bottom;
-const SourceLocationsLattice RHS = Bottom;
-EXPECT_EQ(LHS.join(RHS), LatticeJoinEffect::Unchanged);
-EXPECT_EQ(LHS, Bottom);
-  }
-  {
-SourceLocationsLattice LHS = NonBottom;
-const SourceLocationsLattice RHS = Bottom;
-EXPECT_EQ(LHS.join(RHS), LatticeJoinEffect::Unchanged);
-EXPECT_EQ(LHS, NonBottom);
-  }
-  {
-SourceLocationsLattice LHS = Bottom;
-const SourceLocationsLattice RHS = NonBottom;
-EXPECT_EQ(LHS.join(RHS), LatticeJoinEffect::Changed);
-EXPECT_EQ(LHS, NonBottom);
-  }
-  {
-SourceLocationsLattice LHS = NonBottom;
-const SourceLocationsLattice RHS = NonBottom;
-EXPECT_EQ(LHS.join(RHS), LatticeJoinEffect::Unchanged);
-EXPECT_EQ(LHS, NonBottom);
-  }
-}
-
-} // namespace
-} // namespace dataflow
-} // namespace clang
Index: clang/unittests/Analysis/FlowSensitive/CMakeLists.txt
===
--- clang/unittests/Analysis/FlowSensitive/CMakeLists.txt
+++ clang/unittests/Analysis/FlowSensitive/CMakeLists.txt
@@ -11,7 +11,6 @@
   MatchSwitchTest.cpp
   MultiVarConstantPropagationTest.cpp
   SingleVarConstantPropagationTest.cpp
-  SourceLocationsLatticeTest.cpp
   TestingSupport.cpp
   TestingSupportTest.cpp
   TransferTest.cpp
Index: clang/lib/Analysis/FlowSensitive/SourceLocationsLattice.cpp
===
--- clang/lib/Analysis/FlowSensitive/SourceLocationsLattice.

[PATCH] D128415: [ARM] Add Support for Cortex-M85

2022-06-23 Thread Dave Green via Phabricator via cfe-commits
dmgreen added inline comments.



Comment at: llvm/lib/Target/ARM/ARM.td:1443
 
+def : ProcessorModel<"cortex-m85", CortexM4Model,   [ARMv81mMainline,
+ FeatureDSP,

Please use the CortexM7 schedule - it is closer in terms of capabilities.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128415

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


[PATCH] D124790: [HLSL] Enable half type for hlsl.

2022-06-23 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 aside from some minor changes.




Comment at: clang/lib/AST/ASTContext.cpp:1712
+  case BuiltinType::Half:
+// For HLSL, when not enable native half type, half will be treat as float.
+if (getLangOpts().HLSL)





Comment at: clang/lib/AST/ASTContext.cpp:1713-1719
+if (getLangOpts().HLSL)
+  if (getLangOpts().NativeHalfType)
+return Target->getHalfFormat();
+  else
+return Target->getFloatFormat();
+else
+  return Target->getHalfFormat();





Comment at: clang/lib/Basic/Targets/DirectX.h:60
 "32-f64:64-n8:16:32:64");
+// using the Microsoft ABI.
+TheCXXABI.set(TargetCXXABI::Microsoft);

Though I'd also be fine removing the comment as it doesn't really do much 
except restate the next line.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124790

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


[PATCH] D128439: [Clang][WIP] Don't call distributeTypeAttrsFromDeclarator() on empty list.

2022-06-23 Thread Nikita Popov via Phabricator via cfe-commits
nikic added a comment.

Not seeing a statistically significant impact from this change: 
http://llvm-compile-time-tracker.com/compare.php?from=8b6f69a4da5baaf3748798a84dd16a2481b7ca7f&to=797ba50f5fd88017925fe765427b1f5f136c3310&stat=instructions
 Maybe it's an improvement at the 0.05% level, but it may just as well be 
noise. As such, I probably wouldn't bother with the change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128439

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


[PATCH] D126061: [clang] Reject non-declaration C++11 attributes on declarations

2022-06-23 Thread Mikhail Maltsev via Phabricator via cfe-commits
miyuki added a comment.

Hi Martin,

I think this patch caused a regression. Clang used to warn about the following 
code:

  struct X {
  [[deprecated]] struct Y {};
  };



  $ clang -std=c++17 -Wall test.cpp
  :2:7: warning: attribute 'deprecated' is ignored, place it after 
"struct" to apply attribute to type declaration [-Wignored-attributes]
  [[deprecated]] struct Y {};
^

And now it doesn't. Could you please have a look into it?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126061

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


[PATCH] D128449: [clang] Introduce -Warray-parameter

2022-06-23 Thread serge via Phabricator via cfe-commits
serge-sans-paille created this revision.
serge-sans-paille added reviewers: RKSimon, aaron.ballman, tstellar.
Herald added a project: All.
serge-sans-paille requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This warning exist in GCC[0] and warns about re-declarations of functions
involving arguments of array or pointer types of inconsistent kinds or forms.

This is not the exact same implementation as GCC's : there's no warning level
and that flag has no effect on -Warray-bounds.

[0] 
https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Warning-Options.html#index-Wno-array-parameter


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D128449

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaDecl.cpp
  clang/test/Sema/array-parameter.c

Index: clang/test/Sema/array-parameter.c
===
--- /dev/null
+++ clang/test/Sema/array-parameter.c
@@ -0,0 +1,22 @@
+// RUN: %clang_cc1 -triple x86_64-pc-linux-gnu -fsyntax-only -Wno-unused -verify %s
+
+void f0(int a[]);
+void f0(int *a); // no warning
+
+void f1(int a[]);  // expected-note {{previously declared as int[] here}}
+void f1(int a[2]); // expected-warning {{argument 'a' of type 'int[2]' with mismatched bound}}
+
+void f2(int a[3]); // expected-note {{previously declared as int[3] here}}
+void f2(int a[2]); // expected-warning {{argument 'a' of type 'int[2]' with mismatched bound}}
+
+void f3(int a[const 2]); // expected-note {{previously declared as int[const 2] here}}
+void f3(int a[2]);   // expected-warning {{argument 'a' of type 'int[2]' with mismatched bound}}
+
+void f4(int a[static 2]); // expected-note {{previously declared as int[static 2] here}}
+void f4(int a[2]);// expected-warning {{argument 'a' of type 'int[2]' with mismatched bound}}
+
+void f5(int a[restrict 2]); // expected-note {{previously declared as int[__restrict 2] here}}
+void f5(int a[2]);  // expected-warning {{argument 'a' of type 'int[2]' with mismatched bound}}
+
+void f6(int a[*]); // expected-note {{previously declared as int[*] here}}
+void f6(int a[]);  // expected-warning {{argument 'a' of type 'int[]' with mismatched bound}}
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -46,6 +46,7 @@
 #include "clang/Sema/Template.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/ADT/Triple.h"
+#include "llvm/Support/raw_ostream.h"
 #include 
 #include 
 #include 
@@ -3209,6 +3210,19 @@
   if (!foundAny) newDecl->dropAttrs();
 }
 
+static bool EquivalentArrayTypes(QualType Old, QualType New) {
+  // type[] is equivalent to type *
+  if ((Old->isIncompleteArrayType() && New->isPointerType()) ||
+  (New->isIncompleteArrayType() && Old->isPointerType()))
+return true;
+
+  // Don't try to compare VLA sizes
+  if (Old->isVariableArrayType() && New->isVariableArrayType())
+return true;
+
+  return Old == New;
+}
+
 static void mergeParamDeclTypes(ParmVarDecl *NewParam,
 const ParmVarDecl *OldParam,
 Sema &S) {
@@ -3234,6 +3248,22 @@
   NewParam->setType(NewT);
 }
   }
+  const DecayedType *OldParamDT =
+  dyn_cast(OldParam->getType());
+  const DecayedType *NewParamDT =
+  dyn_cast(NewParam->getType());
+  if (OldParamDT && NewParamDT &&
+  OldParamDT->getPointeeType() == NewParamDT->getPointeeType()) {
+QualType OldParamOT = OldParamDT->getOriginalType();
+QualType NewParamOT = NewParamDT->getOriginalType();
+if (!EquivalentArrayTypes(OldParamOT, NewParamOT)) {
+  S.Diag(NewParam->getLocation(), diag::warn_inconsistent_array_form)
+  << NewParam->getName()
+  << NewParamOT->getCanonicalTypeInternal().getAsString();
+  S.Diag(OldParam->getLocation(), diag::note_previous_declaration_as)
+  << OldParamOT->getCanonicalTypeInternal().getAsString();
+}
+  }
 }
 
 namespace {
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -9393,6 +9393,12 @@
 def note_array_declared_here : Note<
   "array %0 declared here">;
 
+def warn_inconsistent_array_form : Warning<
+  "argument '%0' of type '%1' with mismatched bound">,
+  InGroup;
+def note_previous_declaration_as : Note<
+  "previously declared as %0 here">;
+
 def warn_printf_insufficient_data_args : Warning<
   "more '%%' conversions than data arguments">, InGroup;
 def warn_printf_data_arg_not_used : Warning<
Index: clang/include/clang/Basic/DiagnosticGroups.td
===
--- clang/include/clang/Basic/Dia

[clang] 9ec7e4d - [clang][driver] NFC, test: Make test output order-independent

2022-06-23 Thread Jan Svoboda via cfe-commits

Author: Jan Svoboda
Date: 2022-06-23T17:15:28+02:00
New Revision: 9ec7e4df57f3716018cc0ef60c5d37c8cf6a7cbc

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

LOG: [clang][driver] NFC, test: Make test output order-independent

Added: 


Modified: 
clang/test/Driver/compilation_database_multiarch.c

Removed: 




diff  --git a/clang/test/Driver/compilation_database_multiarch.c 
b/clang/test/Driver/compilation_database_multiarch.c
index 8ea3a457f11cc..1540a8d29ec5c 100644
--- a/clang/test/Driver/compilation_database_multiarch.c
+++ b/clang/test/Driver/compilation_database_multiarch.c
@@ -10,6 +10,6 @@
 
 // RUN: FileCheck --input-file=%t/compilation_database.json %s
 
-// CHECK:  { "directory": "{{.*}}", "file": "{{.*}}", "output": 
"[[OUTPUT_X86_64:.*]]", "arguments": [{{.*}}, "-o", "[[OUTPUT_X86_64]]", {{.*}} 
"--target=x86_64-apple-macosx12.0.0"]},
-// CHECK-NEXT: { "directory": "{{.*}}", "file": "{{.*}}", "output": 
"[[OUTPUT_ARM64:.*]]", "arguments": [{{.*}}, "-o", "[[OUTPUT_ARM64]]", {{.*}} 
"--target=arm64-apple-macosx12.0.0"]},
-// CHECK-NEXT: EOF
+// CHECK-DAG: { "directory": "{{.*}}", "file": "{{.*}}", "output": 
"[[OUTPUT_X86_64:.*]]", "arguments": [{{.*}}, "-o", "[[OUTPUT_X86_64]]", {{.*}} 
"--target=x86_64-apple-macosx12.0.0"]},
+// CHECK-DAG: { "directory": "{{.*}}", "file": "{{.*}}", "output": 
"[[OUTPUT_ARM64:.*]]", "arguments": [{{.*}}, "-o", "[[OUTPUT_ARM64]]", {{.*}} 
"--target=arm64-apple-macosx12.0.0"]},
+// CHECK: EOF



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


[PATCH] D128097: [Clang] Fix compile time regression caused by D126061.

2022-06-23 Thread Nikita Popov via Phabricator via cfe-commits
nikic added a comment.

@mboehme Cycle counts are very noisy, and it's pretty much impossible to 
determine whether they changed by looking at a single commit, unless the 
differences are huge (like 10%). In this case, the commit got "lucky" and the 
next commit goes back to the previous level. This is why I only look at 
instruction counts.

And yes, there may be environment differences, either due to system headers, or 
due to the used host compiler (which is GCC 9.3 for llvm-compile-time-tracker).

As this patch did mitigate half the regression, and the regression wasn't 
particularly large in the first place, I personally wouldn't bother spending 
too much time to investigate this further.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128097

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


[PATCH] D126061: [clang] Reject non-declaration C++11 attributes on declarations

2022-06-23 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D126061#3605276 , @miyuki wrote:

> Hi Martin,
>
> I think this patch caused a regression in diagnostics. Clang used to warn 
> about the following code:
>
>   struct X {
>   [[deprecated]] struct Y {};
>   };
>
>
>
>   $ clang -std=c++17 -Wall test.cpp
>   :2:7: warning: attribute 'deprecated' is ignored, place it after 
> "struct" to apply attribute to type declaration [-Wignored-attributes]
>   [[deprecated]] struct Y {};
> ^
>
> And now it doesn't. Could you please have a look into it?

Good catch, that does appear to be a regression:

  http://eel.is/c++draft/class#nt:member-declaration
  http://eel.is/c++draft/class#mem.general-14


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126061

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


[PATCH] D128297: [pseudo] Track heads as GSS nodes, rather than as "pending actions".

2022-06-23 Thread Sam McCall via Phabricator via cfe-commits
sammccall marked 6 inline comments as done.
sammccall added a comment.

As discussed offline, I'm going to land this patch as other approved 
optimizations are based on it, and there are no big objections.

Please feel free to keep discussing details here and I'll land followups.




Comment at: clang-tools-extra/pseudo/include/clang-pseudo/GLR.h:140
+  const ForestNode &NextTok, const ParseParams &Params,
+  std::vector &NewHeads);
+// Applies available reductions on Heads, appending resulting heads to the 
list.

hokein wrote:
> nit: change NewHeads to a pointer? it seems clearer that NewHeads is the 
> output of the function from the caller side `glrShift(OldHeads, ..., 
> &NewHeads)`.
> 
> I think it would be clearer if glrShift just returns NewHeads, but I 
> understand we want to avoid temporary object for performance reasons. 
I think that's only clearer if there's a convention that references are 
immutable and not used for output, and I don't think that convention exists in 
LLVM.
Maybe there's some association, but using a pointer can also communicate other 
things (like nullability) that we don't intend here.



Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:69
+std::swap(Heads, NextHeads);
+SymbolID Lookahead = I + 1 == Terminals.size() ? tokenSymbol(tok::eof)
+   : Terminals[I + 1].symbol();

hokein wrote:
> I'd probably leave a blank line deliberately after glrShift, because the 
> glrReduce work on the *next* I+1 token.
I think we have different mental models here.

With loop index I:
 - glrShift consumes token I
 - glrReduce consumes no tokens, just rearranges things

I think of glrReduce as:
 a) not operating on a token, at least in the sense that glrShift does
 b) being part of the work for token I, not token I+1 (it's consuming stack 
items corresponding to token I)

It happens to **look ahead** at token I+1, but I see that as mostly incidental: 
with LR(0) we wouldn't do that, with SLR(2) we'd look at both token I+1 and 
I+2. Token I+1 isn't fundamentally important.

(I'm happy to add the blank line, but wanted to clarify because this is one 
reason I see this formulation as simpler)



Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:111
+  const ForestNode &NewTok, const ParseParams &Params,
+  std::vector &NewHeads) {
   assert(NewTok.kind() == ForestNode::Terminal);

hokein wrote:
> nit: add a `NewHeads.empty` assertion? 
Why does this function care about that? It just appends to NewHeads.



Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:200
 // 0--5(pointer)   // 5 is goto(0, pointer)
-void glrReduce(std::vector &PendingReduce, const ParseParams 
&Params,
-   NewHeadCallback NewHeadCB) {
+void glrReduce(std::vector &Heads, SymbolID Lookahead,
+   const ParseParams &Params) {

hokein wrote:
> IIRC, in glrReduce, we only append newly-created GSS nodes in Heads, and 
> never to do deleting, so the Heads will end up with lots of unnecessary heads 
> (heads created for reduces), and we will call `getShiftState` on them. 
> 
> We know that after glrReduce, active heads are heads with available shift 
> actions, so we can optimize it further, we could just use a 
> vector which just contains active heads , this could be done in 
> the popPending. I think it will increase the performance by reducing the 
> number of unnecessary heads.
Thanks for the offline discussion - I understand this better now!

You're right that at the moment we're doing a lookup that happens to yield this 
information. This is because shift + reduce info is stored in the same table.
This would make glrShift cheaper, which could be worth up to 9% now and up to 
15% later (after glrReduce optimizations).

However D128318 splits these data structures apart to exploit different 
patterns in them (shift actions are sparser, reduces are denser but have 
patterns that allows them to be compressed).
I don't want to implement this now as that change is a bigger speedup (24%).

Fundamentally the idea is to avoid a single hashtable lookup. Storing one bit 
per (state, terminal) to see whether shift is possible is only 74kB, maybe a 
big std::bitset would work?

Added a FIXME to LRTable::getShiftState.



Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:264
+  // PoppedHeads is our position within it.
+  unsigned PoppedHeads = 0;
   // Pop walks up the parent chain(s) for a reduction from Head by to Rule.

hokein wrote:
> might be name it PoppedHeadIndex?
No, it points to the first head that *isn't* popped.
Renamed to NextPopHead



Comment at: clang-tools-extra/pseudo/lib/grammar/LRTable.cpp:78
+  assert(pseudo::isToken(Terminal) && "expected terminal symbol!");
+  for (const auto &Result : find(State, Terminal))
+ 

  1   2   3   >