[PATCH] D110258: [AArch64] Always add -tune-cpu argument to -cc1 driver

2021-10-12 Thread David Sherwood via Phabricator via cfe-commits
david-arm added a comment.

In D110258#3055488 , @dmgreen wrote:

> If D111551  was folded into this patch, 
> would it be possible to add tests for -tune-cpu enabling/disabling features 
> at the correct times?

Similar to the comment I left on D110259 , I 
don't want D111551  to hold up the cost model 
changes, which are critical. I'd prefer them to be independent. I expect 
D111551  to take longer to get approval, and 
even once approved/merged if for any reason D111551 
 causes issues after merging we only have to 
revert that one change to AArch64.td.




Comment at: clang/test/Driver/aarch64-mtune.c:3
+
+// There shouldn't be a default -mtune.
+// RUN: %clang -target aarch64-unknown-unknown -c -### %s 2>&1 \

dmgreen wrote:
> Why do we not want to add a default tune-cpu?
This was in response to an earlier review comment by @paulwalker-arm asking 
what benefit "-mtune=generic" provded and about restricting the patch to only 
add `tune-cpu` when the user has explicitly specified one.



Comment at: clang/test/Driver/aarch64-mtune.c:34
+
+// RUN: %clang -target aarch64-unknown-unknown -c -### %s -mcpu=thunderx 2>&1 \
+// RUN:   | FileCheck %s -check-prefix=mcputhunderx

dmgreen wrote:
> My understanding is that -mcpu=cpu is the same as -march=something + 
> -mtune=cpu. Why would this case not add a -tune-cpu too? Is it because that 
> gets handled in llvm?
I thought this was pretty standard behaviour? We're already adding -target-cpu, 
which implies the arch + tuning, so isn't adding -tune-cpu redundant? Not sure 
what value "-target-cpu=thunderx -tune-cpu=thunderx" adds really.


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

https://reviews.llvm.org/D110258

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


[clang] 638c673 - [clang][modules] NFC: Propagate import `SourceLocation` into `HeaderSearch::lookupModule`

2021-10-12 Thread Jan Svoboda via cfe-commits

Author: Jan Svoboda
Date: 2021-10-12T09:31:51+02:00
New Revision: 638c673a8c3e27b6532049ac17ac9bc96640fc45

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

LOG: [clang][modules] NFC: Propagate import `SourceLocation` into 
`HeaderSearch::lookupModule`

This patch propagates the import `SourceLocation` into 
`HeaderSearch::lookupModule`. This enables remarks on search path usage 
(implemented in D102923) to point to the source code that initiated header 
search.

Reviewed By: dexonsmith

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

Added: 


Modified: 
clang/include/clang/Lex/HeaderSearch.h
clang/lib/Frontend/CompilerInstance.cpp
clang/lib/Frontend/FrontendAction.cpp
clang/lib/Lex/HeaderSearch.cpp
clang/lib/Lex/PPDirectives.cpp
clang/lib/Lex/Pragma.cpp
clang/lib/Lex/Preprocessor.cpp
clang/lib/Serialization/ASTReader.cpp
clang/lib/Serialization/GeneratePCH.cpp

Removed: 




diff  --git a/clang/include/clang/Lex/HeaderSearch.h 
b/clang/include/clang/Lex/HeaderSearch.h
index 7df1127f42735..7b19e0da87ec4 100644
--- a/clang/include/clang/Lex/HeaderSearch.h
+++ b/clang/include/clang/Lex/HeaderSearch.h
@@ -560,6 +560,8 @@ class HeaderSearch {
   ///
   /// \param ModuleName The name of the module we're looking for.
   ///
+  /// \param ImportLoc Location of the module include/import.
+  ///
   /// \param AllowSearch Whether we are allowed to search in the various
   /// search directories to produce a module definition. If not, this lookup
   /// will only return an already-known module.
@@ -568,7 +570,8 @@ class HeaderSearch {
   /// in subdirectories.
   ///
   /// \returns The module with the given name.
-  Module *lookupModule(StringRef ModuleName, bool AllowSearch = true,
+  Module *lookupModule(StringRef ModuleName, SourceLocation ImportLoc,
+   bool AllowSearch = true,
bool AllowExtraModuleMapSearch = false);
 
   /// Try to find a module map file in the given directory, returning
@@ -638,11 +641,14 @@ class HeaderSearch {
   /// but for compatibility with some buggy frameworks, additional attempts
   /// may be made to find the module under a related-but-
diff erent search-name.
   ///
+  /// \param ImportLoc Location of the module include/import.
+  ///
   /// \param AllowExtraModuleMapSearch Whether we allow to search modulemaps
   /// in subdirectories.
   ///
   /// \returns The module named ModuleName.
   Module *lookupModule(StringRef ModuleName, StringRef SearchName,
+   SourceLocation ImportLoc,
bool AllowExtraModuleMapSearch = false);
 
   /// Retrieve the name of the (to-be-)cached module file that should

diff  --git a/clang/lib/Frontend/CompilerInstance.cpp 
b/clang/lib/Frontend/CompilerInstance.cpp
index a9c7566163560..3e0a0f312c55c 100644
--- a/clang/lib/Frontend/CompilerInstance.cpp
+++ b/clang/lib/Frontend/CompilerInstance.cpp
@@ -1770,7 +1770,8 @@ ModuleLoadResult 
CompilerInstance::findOrCompileModuleAndReadAST(
 SourceLocation ModuleNameLoc, bool IsInclusionDirective) {
   // Search for a module with the given name.
   HeaderSearch &HS = PP->getHeaderSearchInfo();
-  Module *M = HS.lookupModule(ModuleName, true, !IsInclusionDirective);
+  Module *M =
+  HS.lookupModule(ModuleName, ImportLoc, true, !IsInclusionDirective);
 
   // Select the source and filename for loading the named module.
   std::string ModuleFilename;
@@ -1829,7 +1830,7 @@ ModuleLoadResult 
CompilerInstance::findOrCompileModuleAndReadAST(
 
 // A prebuilt module is indexed as a ModuleFile; the Module does not exist
 // until the first call to ReadAST.  Look it up now.
-M = HS.lookupModule(ModuleName, true, !IsInclusionDirective);
+M = HS.lookupModule(ModuleName, ImportLoc, true, !IsInclusionDirective);
 
 // Check whether M refers to the file in the prebuilt module path.
 if (M && M->getASTFile())
@@ -1952,7 +1953,7 @@ CompilerInstance::loadModule(SourceLocation ImportLoc,
   } else if (ModuleName == getLangOpts().CurrentModule) {
 // This is the module we're building.
 Module = PP->getHeaderSearchInfo().lookupModule(
-ModuleName, /*AllowSearch*/ true,
+ModuleName, ImportLoc, /*AllowSearch*/ true,
 /*AllowExtraModuleMapSearch*/ !IsInclusionDirective);
 /// FIXME: perhaps we should (a) look for a module using the module name
 //  to file map (PrebuiltModuleFiles) and (b) diagnose if still not found?
@@ -2001,8 +2002,8 @@ CompilerInstance::loadModule(SourceLocation ImportLoc,
 PrivateModule, PP->getIdentifierInfo(Module->Name)->getTokenID());
 PrivPath.push_back(std::make_pair(&II, Path[0].second));
 
-if (PP->getHeaderSearchInfo().lookupModule(PrivateModule, true

[PATCH] D111557: [clang][modules] NFC: Propagate import `SourceLocation` into `HeaderSearch::lookupModule`

2021-10-12 Thread Jan Svoboda 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 rG638c673a8c3e: [clang][modules] NFC: Propagate import 
`SourceLocation` into `HeaderSearch… (authored by jansvoboda11).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111557

Files:
  clang/include/clang/Lex/HeaderSearch.h
  clang/lib/Frontend/CompilerInstance.cpp
  clang/lib/Frontend/FrontendAction.cpp
  clang/lib/Lex/HeaderSearch.cpp
  clang/lib/Lex/PPDirectives.cpp
  clang/lib/Lex/Pragma.cpp
  clang/lib/Lex/Preprocessor.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/GeneratePCH.cpp

Index: clang/lib/Serialization/GeneratePCH.cpp
===
--- clang/lib/Serialization/GeneratePCH.cpp
+++ clang/lib/Serialization/GeneratePCH.cpp
@@ -50,7 +50,8 @@
   Module *Module = nullptr;
   if (PP.getLangOpts().isCompilingModule()) {
 Module = PP.getHeaderSearchInfo().lookupModule(
-PP.getLangOpts().CurrentModule, /*AllowSearch*/ false);
+PP.getLangOpts().CurrentModule, SourceLocation(),
+/*AllowSearch*/ false);
 if (!Module) {
   assert(hasErrors && "emitting module but current module doesn't exist");
   return;
Index: clang/lib/Serialization/ASTReader.cpp
===
--- clang/lib/Serialization/ASTReader.cpp
+++ clang/lib/Serialization/ASTReader.cpp
@@ -556,7 +556,8 @@
   StringRef ModuleName = TopImport->ModuleName;
   assert(!ModuleName.empty() && "diagnostic options read before module name");
 
-  Module *M = PP.getHeaderSearchInfo().lookupModule(ModuleName);
+  Module *M =
+  PP.getHeaderSearchInfo().lookupModule(ModuleName, TopImport->ImportLoc);
   assert(M && "missing module");
   return M;
 }
@@ -2923,7 +2924,7 @@
   // If we've already loaded a module map file covering this module, we may
   // have a better path for it (relative to the current build).
   Module *M = PP.getHeaderSearchInfo().lookupModule(
-  F.ModuleName, /*AllowSearch*/ true,
+  F.ModuleName, F.ImportLoc, /*AllowSearch*/ true,
   /*AllowExtraModuleMapSearch*/ true);
   if (M && M->Directory) {
 // If we're implicitly loading a module, the base directory can't
@@ -3909,7 +3910,8 @@
   if (F.Kind == MK_ImplicitModule && ModuleMgr.begin()->Kind != MK_MainFile) {
 // An implicitly-loaded module file should have its module listed in some
 // module map file that we've already loaded.
-Module *M = PP.getHeaderSearchInfo().lookupModule(F.ModuleName);
+Module *M =
+PP.getHeaderSearchInfo().lookupModule(F.ModuleName, F.ImportLoc);
 auto &Map = PP.getHeaderSearchInfo().getModuleMap();
 const FileEntry *ModMap = M ? Map.getModuleMapFileForUniquing(M) : nullptr;
 // Don't emit module relocation error if we have -fno-validate-pch
Index: clang/lib/Lex/Preprocessor.cpp
===
--- clang/lib/Lex/Preprocessor.cpp
+++ clang/lib/Lex/Preprocessor.cpp
@@ -518,7 +518,8 @@
   if (!getLangOpts().isCompilingModule())
 return nullptr;
 
-  return getHeaderSearchInfo().lookupModule(getLangOpts().CurrentModule);
+  return getHeaderSearchInfo().lookupModule(getLangOpts().CurrentModule,
+SourceLocation());
 }
 
 //===--===//
Index: clang/lib/Lex/Pragma.cpp
===
--- clang/lib/Lex/Pragma.cpp
+++ clang/lib/Lex/Pragma.cpp
@@ -1752,7 +1752,7 @@
 // Find the module we're entering. We require that a module map for it
 // be loaded or implicitly loadable.
 auto &HSI = PP.getHeaderSearchInfo();
-Module *M = HSI.lookupModule(Current);
+Module *M = HSI.lookupModule(Current, ModuleName.front().second);
 if (!M) {
   PP.Diag(ModuleName.front().second,
   diag::err_pp_module_begin_no_module_map) << Current;
Index: clang/lib/Lex/PPDirectives.cpp
===
--- clang/lib/Lex/PPDirectives.cpp
+++ clang/lib/Lex/PPDirectives.cpp
@@ -745,7 +745,7 @@
   // to the current module, if there is one.
   return getLangOpts().CurrentModule.empty()
  ? nullptr
- : HeaderInfo.lookupModule(getLangOpts().CurrentModule);
+ : HeaderInfo.lookupModule(getLangOpts().CurrentModule, Loc);
 }
 
 const FileEntry *
Index: clang/lib/Lex/HeaderSearch.cpp
===
--- clang/lib/Lex/HeaderSearch.cpp
+++ clang/lib/Lex/HeaderSearch.cpp
@@ -229,7 +229,8 @@
   return Result.str().str();
 }
 
-Module *HeaderSearch::lookupModule(StringRef ModuleName, bool AllowSearch,
+Module *HeaderSearch::lookupModule(String

[PATCH] D108643: Introduce _BitInt, deprecate _ExtInt

2021-10-12 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

In D108643#3055244 , @erichkeane 
wrote:

>>> ! In D108643#3054443 , @rjmccall 
>>> wrote:
>>>
 ! In D108643#3027473 , 
 @erichkeane wrote:

> ! In D108643#3026550 , 
> @rjmccall wrote:

 I think it would be better to provide a generic ABI specification that is 
 designed to "lower" `_BitInt` types into more basic concepts that ABIs 
 typically already have rules for.  It would be appropriate to note at the 
 top that this is only a generic specification and that the rules for any 
 particular platform should be codified in a platform-specific ABI.  But we 
 should make that easy so that platform owners who don't have strong 
 opinions about the ABI can just say "as described in version 1.4 of the 
 generic ABI at https://clang.llvm.org/...";

 Now, that is all independent of what we actually decide the ABI should be. 
  But I do think that if we're going to make this available on all targets, 
 we should strongly consider doing a "legalizing" lowering in the frontend: 
 at ABI-exposed points (call arguments/parameters and memory accesses), 
 `_BitInt` types should be translated into types that a naive backend can 
 be trusted to handle in a way that matches the documented ABI.  Individual 
 targets can then opt in to using the natural lowerings if they promise to 
 match the ABI, but that becomes a decision that they make to enable better 
 optimization and code generation, not something that's necessary for 
 correctness.
>>>
>>> Don't we already have that?  We work the same way a 'bool' does, that is, 
>>> we zero/sign extend for parameters and return values?  The backends then 
>>> reliably up-scale these to the power-of-two/multiple-of-pointer.
>>
>> There's two levels of a "legalizing" lowering.
>>
>> On the specification level, we'd be formally saying that the ABI matches the 
>> ABI of some other C construct.  For example, we might say that a `signed 
>> _BitInt(14)` argument is treated exactly as if the argument type was instead 
>> `signed short` (with whatever restriction we do or do not impose on the 
>> range).  This is very nice on this level because, first, it's a rule that 
>> works generically for all targets without needing to care about the details 
>> of how arguments are assigned to registers or stack slots or whatever; and 
>> second, it means you're never adding new cases to the ABI that e.g. libffi 
>> would need to care about; and third, you can reliably match the ABI with 
>> manually-lowered C code from a compiler that doesn't even support `_BitInt`s.
>>
>> On the implementation level, we'd have to actually emit IR which will turn 
>> into code which matches that ABI.  I think you are right that small integers 
>> already reliably work that way in LLVM, so that if you pass an `i11 sext` 
>> it'll get sign-extended to some width — what width exactly, I don't know, 
>> but probably the same width that `i16 sext` would be.  Larger integers, I'm 
>> not sure.  A legalizing lowering of big `_BitInt` argument would presumably 
>> say either that it's exactly the same as a struct containing all the chunks 
>> or that it's exactly the same as a series of arguments for each of the 
>> chunks.  Those are two very different rules!  Most ABIs won't "straddle" a 
>> single argument between registers and the stack, so e.g. if you'd need two 
>> registers and you only have one left then you exhaust the registers and go 
>> fully on the stack; but obviously you can get straddling if the lowering 
>> expands the sequence.  Similarly, some ABIs will go indirect if the struct 
>> gets big enough, but you won't get that if the lowering expands.  But on the 
>> other hand, if the rule is really that it's like a struct, well, some ABIs 
>> don't pass small structs in registers.  Anyway, my point is that what 
>> exactly LLVM targets do if you give them an `i117` might not match either of 
>> these possibilities reliably across targets.  In any case, since we 
>> currently have to count registers in the frontend for the register-passing 
>> ABIs, we'll need to actually know what the targets do.
>
> Hmm... now that I think I understand the concern, I'm not sure we're able to 
> take on this level of commitment. The Clang ABI code is a bit of a mess in 
> general, plus each target has its own code, right (In CodeGen/TargetInfo.cpp)?

Ideally we would have a generic handling of it that most ABI code would simply 
trigger.

> Additionally, that would require breaking the Microsoft ABI again, and I 
> thought we'd discussed trying not to make changes until Microsoft defined 
> that ABI, right?

I didn't realize we were matching any other compilers at the moment.  Or is 
that not what you mean?

I think we need to cons

[PATCH] D110241: [docs] List support for Armv9-A, Armv9.1-A and Armv9.2-A in LLVM and Clang

2021-10-12 Thread Victor Campos 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 rG3e7cf33a8376: [docs] List support for Armv9-A, Armv9.1-A and 
Armv9.2-A in LLVM and Clang (authored by vhscampos).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110241

Files:
  clang/docs/ReleaseNotes.rst
  llvm/docs/ReleaseNotes.rst


Index: llvm/docs/ReleaseNotes.rst
===
--- llvm/docs/ReleaseNotes.rst
+++ llvm/docs/ReleaseNotes.rst
@@ -73,12 +73,12 @@
 Changes to the AArch64 Backend
 --
 
-* ...
+* Added support for the Armv9-A, Armv9.1-A and Armv9.2-A architectures.
 
 Changes to the ARM Backend
 --
 
-During this release ...
+* Added support for the Armv9-A, Armv9.1-A and Armv9.2-A architectures.
 
 Changes to the MIPS Target
 --
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -83,6 +83,12 @@
   - RISC-V SiFive S54 (``sifive-s54``).
   - RISC-V SiFive S76 (``sifive-s76``).
 
+- Support has been added for the following architectures (``-march`` 
identifiers in parentheses):
+
+  - Armv9-A (``armv9-a``).
+  - Armv9.1-A (``armv9.1-a``).
+  - Armv9.2-A (``armv9.2-a``).
+
 Removed Compiler Flags
 -
 


Index: llvm/docs/ReleaseNotes.rst
===
--- llvm/docs/ReleaseNotes.rst
+++ llvm/docs/ReleaseNotes.rst
@@ -73,12 +73,12 @@
 Changes to the AArch64 Backend
 --
 
-* ...
+* Added support for the Armv9-A, Armv9.1-A and Armv9.2-A architectures.
 
 Changes to the ARM Backend
 --
 
-During this release ...
+* Added support for the Armv9-A, Armv9.1-A and Armv9.2-A architectures.
 
 Changes to the MIPS Target
 --
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -83,6 +83,12 @@
   - RISC-V SiFive S54 (``sifive-s54``).
   - RISC-V SiFive S76 (``sifive-s76``).
 
+- Support has been added for the following architectures (``-march`` identifiers in parentheses):
+
+  - Armv9-A (``armv9-a``).
+  - Armv9.1-A (``armv9.1-a``).
+  - Armv9.2-A (``armv9.2-a``).
+
 Removed Compiler Flags
 -
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 3e7cf33 - [docs] List support for Armv9-A, Armv9.1-A and Armv9.2-A in LLVM and Clang

2021-10-12 Thread Victor Campos via cfe-commits

Author: Victor Campos
Date: 2021-10-12T08:41:07+01:00
New Revision: 3e7cf33a83764514bd613dfb5b1a0bb36f13e69a

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

LOG: [docs] List support for Armv9-A, Armv9.1-A and Armv9.2-A in LLVM and Clang

Reviewed By: pratlucas

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

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
llvm/docs/ReleaseNotes.rst

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 0ebbf1eb63636..950e9fe726285 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -83,6 +83,12 @@ Modified Compiler Flags
   - RISC-V SiFive S54 (``sifive-s54``).
   - RISC-V SiFive S76 (``sifive-s76``).
 
+- Support has been added for the following architectures (``-march`` 
identifiers in parentheses):
+
+  - Armv9-A (``armv9-a``).
+  - Armv9.1-A (``armv9.1-a``).
+  - Armv9.2-A (``armv9.2-a``).
+
 Removed Compiler Flags
 -
 

diff  --git a/llvm/docs/ReleaseNotes.rst b/llvm/docs/ReleaseNotes.rst
index 46627c2000679..4bac29cb1cd1c 100644
--- a/llvm/docs/ReleaseNotes.rst
+++ b/llvm/docs/ReleaseNotes.rst
@@ -73,12 +73,12 @@ Changes to TableGen
 Changes to the AArch64 Backend
 --
 
-* ...
+* Added support for the Armv9-A, Armv9.1-A and Armv9.2-A architectures.
 
 Changes to the ARM Backend
 --
 
-During this release ...
+* Added support for the Armv9-A, Armv9.1-A and Armv9.2-A architectures.
 
 Changes to the MIPS Target
 --



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


[PATCH] D110257: [CFE][Codegen] Make sure to maintain the contiguity of all the static allocas

2021-10-12 Thread Alexander Richardson via Phabricator via cfe-commits
arichardson added inline comments.



Comment at: clang/lib/CodeGen/CGExpr.cpp:115
+if (AllocaInsertedAtAllocaInsertPt)
+  AllocaAddrSpaceInsertPt = dyn_cast(V)->getIterator();
   }

Shouldn't this use `cast` instead?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110257

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


[clang] 1341a2c - [clang][modules] Default `SourceLocation` parameter in `HeaderSearch::lookupModule`

2021-10-12 Thread Jan Svoboda via cfe-commits

Author: Jan Svoboda
Date: 2021-10-12T09:58:54+02:00
New Revision: 1341a2c19e54cec77ccb35e3b4ee3924870b2e6a

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

LOG: [clang][modules] Default `SourceLocation` parameter in 
`HeaderSearch::lookupModule`

This fixes an LLDB build failure where the `ImportLoc` argument is missing: 
https://lab.llvm.org/buildbot#builders/68/builds/19975

This change also makes it possible to drop `SourceLocation()` in 
`Preprocessor::getCurrentModule`.

Added: 


Modified: 
clang/include/clang/Lex/HeaderSearch.h
clang/lib/Lex/Preprocessor.cpp

Removed: 




diff  --git a/clang/include/clang/Lex/HeaderSearch.h 
b/clang/include/clang/Lex/HeaderSearch.h
index 7b19e0da87ec4..372589d75d965 100644
--- a/clang/include/clang/Lex/HeaderSearch.h
+++ b/clang/include/clang/Lex/HeaderSearch.h
@@ -570,7 +570,8 @@ class HeaderSearch {
   /// in subdirectories.
   ///
   /// \returns The module with the given name.
-  Module *lookupModule(StringRef ModuleName, SourceLocation ImportLoc,
+  Module *lookupModule(StringRef ModuleName,
+   SourceLocation ImportLoc = SourceLocation(),
bool AllowSearch = true,
bool AllowExtraModuleMapSearch = false);
 

diff  --git a/clang/lib/Lex/Preprocessor.cpp b/clang/lib/Lex/Preprocessor.cpp
index 5aa831aa4eda6..bf0b85e038f05 100644
--- a/clang/lib/Lex/Preprocessor.cpp
+++ b/clang/lib/Lex/Preprocessor.cpp
@@ -518,8 +518,7 @@ Module *Preprocessor::getCurrentModule() {
   if (!getLangOpts().isCompilingModule())
 return nullptr;
 
-  return getHeaderSearchInfo().lookupModule(getLangOpts().CurrentModule,
-SourceLocation());
+  return getHeaderSearchInfo().lookupModule(getLangOpts().CurrentModule);
 }
 
 
//===--===//



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


[PATCH] D111617: [RISCV] Lazily add RVV C intrinsics.

2021-10-12 Thread Hsiangkai Wang via Phabricator via cfe-commits
HsiangKai created this revision.
HsiangKai added reviewers: khchen, craig.topper, rogfer01, kito-cheng.
Herald added subscribers: achieveartificialintelligence, StephenFan, vkmr, 
frasercrmck, dexonsmith, evandro, luismarques, apazos, sameer.abuasal, 
s.egerton, Jim, benna, psnobl, jocewei, PkmX, the_o, brucehoult, MartinMosbeck, 
edward-jones, zzheng, jrtc27, shiva0217, niosHD, sabuasal, simoncook, 
johnrusso, rbar, asb, Anastasia, mgorny.
HsiangKai requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, MaskRay.
Herald added projects: clang, LLVM.

Leverage the method OpenCL uses that adds C intrinsics when the lookup
failed. There is no need to define C intrinsics in the header file any
more. It could help to avoid the large header file to speed up the
compilation of RVV source code. Besides that, only the C intrinsics used
by the users will be added into the declaration table.

This patch is based on https://reviews.llvm.org/D103228 and inspired by
OpenCL implementation.

Authored-by: Kito Cheng 
Co-Authored-by: Hsiangkai Wang 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D111617

Files:
  clang/include/clang/Basic/CMakeLists.txt
  clang/include/clang/Basic/TokenKinds.def
  clang/include/clang/Parse/Parser.h
  clang/lib/Parse/ParsePragma.cpp
  clang/lib/Sema/SemaLookup.cpp
  clang/utils/TableGen/RISCVVEmitter.cpp
  clang/utils/TableGen/TableGen.cpp
  clang/utils/TableGen/TableGenBackends.h
  llvm/docs/CommandGuide/tblgen.rst

Index: llvm/docs/CommandGuide/tblgen.rst
===
--- llvm/docs/CommandGuide/tblgen.rst
+++ llvm/docs/CommandGuide/tblgen.rst
@@ -348,6 +348,10 @@
 
   Generate ``riscv_vector_builtin_cg.inc`` for Clang.
 
+.. option:: -gen-riscv-vector-builtin-sema
+
+  Generate ``riscv_vector_builtin_sema.inc`` for Clang.
+
 .. option:: -gen-attr-docs
 
   Generate attribute documentation.
Index: clang/utils/TableGen/TableGenBackends.h
===
--- clang/utils/TableGen/TableGenBackends.h
+++ clang/utils/TableGen/TableGenBackends.h
@@ -110,6 +110,7 @@
 void EmitRVVHeader(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 void EmitRVVBuiltins(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 void EmitRVVBuiltinCG(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
+void EmitRVVBuiltinSema(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 
 void EmitCdeHeader(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 void EmitCdeBuiltinDef(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
Index: clang/utils/TableGen/TableGen.cpp
===
--- clang/utils/TableGen/TableGen.cpp
+++ clang/utils/TableGen/TableGen.cpp
@@ -88,6 +88,7 @@
   GenRISCVVectorHeader,
   GenRISCVVectorBuiltins,
   GenRISCVVectorBuiltinCG,
+  GenRISCVVectorBuiltinSema,
   GenAttrDocs,
   GenDiagDocs,
   GenOptDocs,
@@ -243,6 +244,8 @@
"Generate riscv_vector_builtins.inc for clang"),
 clEnumValN(GenRISCVVectorBuiltinCG, "gen-riscv-vector-builtin-codegen",
"Generate riscv_vector_builtin_cg.inc for clang"),
+clEnumValN(GenRISCVVectorBuiltinSema, "gen-riscv-vector-builtin-sema",
+   "Generate riscv_vector_builtin_sema.inc for clang"),
 clEnumValN(GenAttrDocs, "gen-attr-docs",
"Generate attribute documentation"),
 clEnumValN(GenDiagDocs, "gen-diag-docs",
@@ -458,6 +461,9 @@
   case GenRISCVVectorBuiltinCG:
 EmitRVVBuiltinCG(Records, OS);
 break;
+  case GenRISCVVectorBuiltinSema:
+EmitRVVBuiltinSema(Records, OS);
+break;
   case GenAttrDocs:
 EmitClangAttrDocs(Records, OS);
 break;
Index: clang/utils/TableGen/RISCVVEmitter.cpp
===
--- clang/utils/TableGen/RISCVVEmitter.cpp
+++ clang/utils/TableGen/RISCVVEmitter.cpp
@@ -203,12 +203,6 @@
   // Emit the code block for switch body in EmitRISCVBuiltinExpr, it should
   // init the RVVIntrinsic ID and IntrinsicTypes.
   void emitCodeGenSwitchBody(raw_ostream &o) const;
-
-  // Emit the macros for mapping C/C++ intrinsic function to builtin functions.
-  void emitIntrinsicMacro(raw_ostream &o) const;
-
-  // Emit the mangled function definition.
-  void emitMangledFuncDef(raw_ostream &o) const;
 };
 
 class RVVEmitter {
@@ -231,6 +225,9 @@
   /// Emit all the information needed to map builtin -> LLVM IR intrinsic.
   void createCodeGen(raw_ostream &o);
 
+  /// Emit all the information needed by SemaLookup.cpp.
+  void createSema(raw_ostream &o);
+
   std::string getSuffixStr(char Type, int Log2LMUL, StringRef Prototypes);
 
 private:
@@ -246,15 +243,6 @@
   ArrayRef PrototypeSeq);
   Optional computeType(BasicType BT, int Log2LMUL, StringRef Proto);
 
-  /// Emit Acrh predecessor definitions and body, assume the element of Defs are

[PATCH] D111517: [X86] Remove little support we had for MPX

2021-10-12 Thread Kan Shengchen via Phabricator via cfe-commits
skan accepted this revision.
skan added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111517

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


[PATCH] D110684: [RISCV] Define _m intrinsics as builtins, instead of macros.

2021-10-12 Thread Nikita Popov via Phabricator via cfe-commits
nikic added a comment.

I noticed this a few time in the past already, but this is the worst one yet:

Compile-time: 
https://llvm-compile-time-tracker.com/compare.php?from=6641d29b70993bce6dbd7e0e0f1040753d38842f&to=97f0c63783f52389bd8842df205379ceade7a89d&stat=instructions
Max-rss: 
https://llvm-compile-time-tracker.com/compare.php?from=6641d29b70993bce6dbd7e0e0f1040753d38842f&to=97f0c63783f52389bd8842df205379ceade7a89d&stat=max-rss
Plus a >1% increase in clang total binary size.

This happens every time a new slew of RISCV intrinsic permutations gets added, 
which seem to suffer from an extreme degree of redundancy. Is it possible to do 
something about this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110684

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


[PATCH] D111208: [clang-tidy] Support globbing in NOLINT* expressions

2021-10-12 Thread Carlos Galvez via Phabricator via cfe-commits
carlosgalvezp updated this revision to Diff 378913.
carlosgalvezp marked an inline comment as done.
carlosgalvezp added a comment.

Remove support for negative globs. Keep unit tests to ensure that negative 
globs are ignored. Update documentation.


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

https://reviews.llvm.org/D111208

Files:
  clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
  clang-tools-extra/clang-tidy/GlobList.cpp
  clang-tools-extra/clang-tidy/GlobList.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/index.rst
  clang-tools-extra/test/clang-tidy/infrastructure/nolint.cpp
  
clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend-begin-global-end-specific.cpp
  
clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend-begin-specific-end-global.cpp
  
clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend-mismatched-check-names.cpp
  clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend.cpp
  clang-tools-extra/test/clang-tidy/infrastructure/nolintnextline.cpp

Index: clang-tools-extra/test/clang-tidy/infrastructure/nolintnextline.cpp
===
--- clang-tools-extra/test/clang-tidy/infrastructure/nolintnextline.cpp
+++ clang-tools-extra/test/clang-tidy/infrastructure/nolintnextline.cpp
@@ -11,21 +11,25 @@
 class D { D(int i); };
 // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: single-argument constructors must be marked explicit
 
-// NOLINTNEXTLINE(*)
+// NOLINTNEXTLINE()
 class D1 { D1(int i); };
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: single-argument constructors must be marked explicit
 
-// NOLINTNEXTLINE(not-closed-bracket-is-treated-as-skip-all
+// NOLINTNEXTLINE(*)
 class D2 { D2(int i); };
 
-// NOLINTNEXTLINE(google-explicit-constructor)
+// NOLINTNEXTLINE(not-closed-bracket-is-treated-as-skip-all
 class D3 { D3(int i); };
 
-// NOLINTNEXTLINE(some-check, google-explicit-constructor)
+// NOLINTNEXTLINE(google-explicit-constructor)
 class D4 { D4(int i); };
 
-// NOLINTNEXTLINE without-brackets-skip-all, another-check
+// NOLINTNEXTLINE(some-check, google-explicit-constructor)
 class D5 { D5(int i); };
 
+// NOLINTNEXTLINE without-brackets-skip-all, another-check
+class D6 { D6(int i); };
+
 // NOLINTNEXTLINE
 
 class E { E(int i); };
@@ -46,6 +50,38 @@
 // NOLINTNEXTLINE
 MACRO_NOARG
 
-// CHECK-MESSAGES: Suppressed 9 warnings (9 NOLINT)
+// NOLINTNEXTLINE(google*)
+class I1 { I1(int i); };
+
+// NOLINTNEXTLINE(*explicit-constructor)
+class I2 { I2(int i); };
+
+// NOLINTNEXTLINE(*explicit*)
+class I3 { I3(int i); };
+
+// NOLINTNEXTLINE(-explicit-constructor)
+class I4 { I4(int x); };
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: single-argument constructors must be marked explicit
+
+// NOLINTNEXTLINE(google*,-google*)
+class I5 { I5(int x); };
+
+// NOLINTNEXTLINE(*,-google*)
+class I6 { I6(int x); };
+
+int array1[10];
+// CHECK-MESSAGES: :[[@LINE-1]]:1: warning: do not declare C-style arrays, use std::array<> instead [cppcoreguidelines-avoid-c-arrays,modernize-avoid-c-arrays]
+
+// NOLINTNEXTLINE(cppcoreguidelines-avoid-c-arrays)
+int array2[10];
+// CHECK-MESSAGES: :[[@LINE-1]]:1: warning: do not declare C-style arrays, use std::array<> instead [modernize-avoid-c-arrays]
+
+// NOLINTNEXTLINE(cppcoreguidelines-avoid-c-arrays,modernize-avoid-c-arrays)
+int array3[10];
+
+// NOLINTNEXTLINE(*-avoid-c-arrays)
+int array4[10];
+
+// CHECK-MESSAGES: Suppressed 19 warnings (19 NOLINT)
 
-// RUN: %check_clang_tidy %s google-explicit-constructor %t --
+// RUN: %check_clang_tidy %s google-explicit-constructor,clang-diagnostic-unused-variable,cppcoreguidelines-avoid-c-arrays,modernize-avoid-c-arrays %t -- -extra-arg=-Wunused-variable
Index: clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend.cpp
===
--- clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend.cpp
+++ clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend.cpp
@@ -1,4 +1,4 @@
-// RUN: %check_clang_tidy %s google-explicit-constructor %t
+// RUN: %check_clang_tidy %s google-explicit-constructor,clang-diagnostic-unused-variable,cppcoreguidelines-avoid-c-arrays,modernize-avoid-c-arrays %t -- -extra-arg=-Wunused-variable
 
 class A { A(int i); };
 // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: single-argument constructors must be marked explicit
@@ -34,60 +34,54 @@
 class C1 { C1(int i); };
 // NOLINTEND(google-explicit-constructor)
 
-// NOLINTBEGIN(*)
+// NOLINTBEGIN()
 class C2 { C2(int i); };
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: single-argument constructors must be marked explicit
+// NOLINTEND()
+
+// NOLINTBEGIN(*)
+class C3 { C3(int i); };
 // NOLINTEND(*)
 
 // NOLINTBEGIN(some-other-check)
-class C3 { C3(int i); };
+class C4 { C4(int i); };
 // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: single-argument constructors must be marked explicit
 // NOLINTEND(some-other-check

[PATCH] D111208: [clang-tidy] Support globbing in NOLINT* expressions

2021-10-12 Thread Carlos Galvez via Phabricator via cfe-commits
carlosgalvezp marked an inline comment as done.
carlosgalvezp added inline comments.



Comment at: clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp:349
+  // Allow specifying a few checks with a glob expression.
+  GlobList Globs(ChecksStr);
+  if (!Globs.contains(CheckName))

aaron.ballman wrote:
> carlosgalvezp wrote:
> > salman-javed-nz wrote:
> > > What happens when `CheckStr` is empty?
> > > How has Clang-Tidy treated `// NOLINT()` in the past? Does this patch 
> > > change the behaviour? What //should // be the "right" behaviour?
> > Very good question! Currently on master `// NOLINT()` will *not* suppress 
> > warnings. However `// NOLINT(` will. My patch shouldn't change existing 
> > behavior - an empty list of globs will return false when calling `contains`.
> > 
> > I'll add a unit test to cover this case!
> (All of this is a bit orthogonal to this patch, so no changes requested here.)
> 
> Naively, I would expect `NOLINT()` to be an error because it expects an 
> argument and none was given. (I'd expect `NOLINT(` to also be an error 
> because the syntax is malformed.)
Fully agree! If I find some time I can give it a try on a separate patch


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

https://reviews.llvm.org/D111208

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


[PATCH] D111208: [clang-tidy] Support globbing in NOLINT* expressions

2021-10-12 Thread Carlos Galvez via Phabricator via cfe-commits
carlosgalvezp added a comment.

> Just an FYI, but we usually only ping when there's been about a week of no 
> traffic on the review

Thanks, I'll keep it in mind for next time! Really appreciate your time 
reviewing :)

I have updated the patch based on your feedback.


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

https://reviews.llvm.org/D111208

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


[PATCH] D111041: [clang-tidy] Remove 'IgnoreDestructors = true' from cppcoreguidelines-explicit-virtual-functions

2021-10-12 Thread Carlos Galvez via Phabricator via cfe-commits
carlosgalvezp added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/modernize-use-override.cpp:56
   virtual ~SimpleCases();
-  // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: prefer using 'override' or 
(rarely) 'final' instead of 'virtual' [modernize-use-override]
+  // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: prefer using 'override' or 
(rarely) 'final' instead of 'virtual'
   // CHECK-FIXES: {{^}}  ~SimpleCases() override;

aaron.ballman wrote:
> This isn't quite what I was after; now it looks like we expect to always get 
> the diagnostic (in fact, I'm a bit worried that this test is passing). I'd 
> rather see:
> ```
> // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: prefer using 'override' or 
> (rarely) 'final' instead of 'virtual' [modernize-use-override]
> // CHECK-CPPCOREGUIDELINES-NOT: :[[@LINE-2]]:11: warning: prefer using 
> 'override' or (rarely) 'final' instead of 'virtual'
> ```
> So that we check explicitly we see the diagnostic for modernize and 
> explicitly that we don't see the diagnostic for C++ Core Guidelines.
> 
> You'll need to change the second RUN line to not use `check_clang_tidy` but 
> instead execute clang-tidy manually so you can pass 
> `-check-prefix=CHECK-CPPCOREGUIDELINES` to it (as done in 
> https://github.com/llvm/llvm-project/blob/main/clang-tools-extra/test/clang-tidy/checkers/cert-static-object-exception.cpp#L4).
Not sure I follow. What you propose is something that would make sense _before_ 
this patch, when the `cppcoreguidelines` check was _different_ than 
`modernize`. But now they are not, they are identical, so we expect to get 
identical diagnostics from them. Or am I missing something obvious?


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

https://reviews.llvm.org/D111041

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


[PATCH] D111597: [RISCV][Clang] Fix RISCV vector header comment.

2021-10-12 Thread Zakk Chen via Phabricator via cfe-commits
khchen accepted this revision.
khchen added a comment.
This revision is now accepted and ready to land.

LGTM. Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111597

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


[PATCH] D108643: Introduce _BitInt, deprecate _ExtInt

2021-10-12 Thread John McCall via Phabricator via cfe-commits
rjmccall added inline comments.



Comment at: clang/docs/BitIntABI.rst:90
+width. e.g., a ``signed _BitField(7)`` whose representation width is ``8`` bits
+cannot store values less than ``-64`` or greater than ``63``.
+

It might be worthwhile to pull these definitions into a common Definitions 
section, since I think they'll apply in most of the sections.  You should be 
explicit about the two parameters, like:

> This generic ABI is expressed in terms of two parameters which must be 
> determined by the platform ABI:
>
> - `MaxFundamentalWidth` is the bit-width...
>
> - `chunk_t` is the type of...
>
> For the convenience of the following specification, other quantities are 
> derived from these:

The paragraph about `RepWidth` could be clearer.  Maybe:

> ``RepWidth(N)`` is the *representation width* of a ``_BitInt`` of width 
> ``N``.  If ``N <= MaxFundamentalWidth``, then ``RepWidth(N)`` is the 
> bit-width of the lowest-rank fundamental integer type (excluding ``_Bool``) 
> with at least ``N`` bits.  Otherwise, ``RepWidth(N)`` is the least multiple 
> of the bit-width of ``chunk_t`` which is at least ``N``.  It is therefore 
> always true that ``N <= RepWidth(N)``.  When ``N < RepWidth(N)``, a 
> ``_BitInt(N)`` is represented exactly as if it were extended to a 
> ``_BitInt(RepWidth(N))`` of  the same signedness.  The value is held in the 
> least significant bits, and the excess (most significant) bits have 
> unspecified values.

The sentence about undefined behavior conflicts with the excess bits taking 
unspecified values.



Comment at: clang/docs/BitIntABI.rst:145
+assumption that it improves performance for a larger set of operations than
+sign or zero extension.

Hmm.  How about:

> Excess bits
> ---
> 
> When ``N < RepWidth(N)``, the ABI has three natural alternatives:
> - The value is kept in the least-significant bits, and the excess (most 
> significant) bits are unspecified.
> - The value is kept in the least-significant bits, and the excess (most 
> significant) bits are required to be a proper zero- or sign-extension of the 
> value (as appropriate for the signedness of the type).
> - The value is left-shifted into the most-significant bits, and the excess 
> (least significant) bits are required to be zero.
>
> Each of these has trade-offs.  Leaving the most-significant bits unspecified 
> allows addition, subtraction, multiplication, bitwise complement, left 
> shifts, and narrowing conversions to avoid adjusting these bits in their 
> results.  Forcing the most-significant bits to be properly extended allows 
> comparisons, division, right shifts, and widening conversions to avoid 
> adjusting these bits in their operands.  Keeping the value left-shifted is 
> good for both addition and comparison, but other operations (especially 
> conversions) become more complex, and the representation is less "natural", 
> which can complicate interacting with other systems.  Furthermore, having 
> unspecified bits means that bitwise equality can be false even when semantic 
> equality holds, but not having unspecified bits means that there are "trap 
> representations" which can lead to undefined behavior.
>
> This ABI leaves the most-significant bits unspecified out of a belief that 
> doing so should optimize the most common operations and avoid the most 
> complexity in practice.



Comment at: clang/docs/BitIntABI.rst:90
+``_BitInt`` should not be packed together with an adjacent bit-field of a non-
+``_BitInt`` type. ``_BitInt(N)`` and ``_BitInt(M)`` types should pack together
+when ``N != M``.

aaron.ballman wrote:
> rjmccall wrote:
> > BitInts not packing with non-BitInts is a surprising rule.
> > 
> > How does this packing work when allocation units differ in size?
> > BitInts not packing with non-BitInts is a surprising rule.
> 
> Hmmm, I thought I had tested and found that unused bits from an oversized 
> _BitInt would not pack together, but now I can't seem to get that behavior. 
> It looks like we *do* pack things into the unused bits. 
> https://godbolt.org/z/4Pavvbeqe
> 
> It seems to me that there's no reason to NOT pack into those unused bits, so 
> I think that's the behavior we'd like. I'll correct the docs.
> 
> > How does this packing work when allocation units differ in size?
> 
> Are you wondering about a case like?
> ```
> struct S {
>   unsigned _BitInt(33) i : 8; // 8 byte allocation unit
>   unsigned _BitInt(32) j : 8; // 4 byte allocation unit
> };
> ```
> or something else? I think the current behavior here is largely as a result 
> of code review feedback on the original implementation work. At least, this 
> patch isn't changing the behavior from whatever was deemed appropriate for 
> `_ExtInt` originally. But we should find those rules out and document them 
> here in the ABI doc.
Right, it's fine to start by just documenting what we've got.


CHANGES SINCE LAS

[PATCH] D102923: [clang][lex] Remark on search path usage

2021-10-12 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 updated this revision to Diff 378922.
jansvoboda11 added a comment.

Report matched header maps even when target file does not exist, add tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102923

Files:
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticLexKinds.td
  clang/include/clang/Lex/HeaderMap.h
  clang/include/clang/Lex/HeaderSearch.h
  clang/lib/Frontend/InitHeaderSearch.cpp
  clang/lib/Lex/HeaderMap.cpp
  clang/lib/Lex/HeaderSearch.cpp
  
clang/test/Preprocessor/Inputs/search-path-usage/FwA/FrameworkA.framework/Headers/FrameworkA.h
  
clang/test/Preprocessor/Inputs/search-path-usage/FwA/FrameworkA.framework/Modules/module.modulemap
  
clang/test/Preprocessor/Inputs/search-path-usage/FwB/FrameworkB.framework/Headers/FrameworkB.h
  
clang/test/Preprocessor/Inputs/search-path-usage/FwB/FrameworkB.framework/Modules/module.modulemap
  clang/test/Preprocessor/Inputs/search-path-usage/a/a.h
  clang/test/Preprocessor/Inputs/search-path-usage/a_next/a.h
  clang/test/Preprocessor/Inputs/search-path-usage/b.hmap.json.template
  clang/test/Preprocessor/Inputs/search-path-usage/b/b.h
  clang/test/Preprocessor/Inputs/search-path-usage/d/d.h
  
clang/test/Preprocessor/Inputs/search-path-usage/modulemap_abs/module.modulemap.template
  clang/test/Preprocessor/search-path-usage.m

Index: clang/test/Preprocessor/search-path-usage.m
===
--- /dev/null
+++ clang/test/Preprocessor/search-path-usage.m
@@ -0,0 +1,146 @@
+// RUN: rm -rf %t && mkdir %t
+
+// Check that search paths used by `#include` and `#include_next` are reported.
+//
+// RUN: %clang_cc1 -Eonly %s -Rsearch-path-usage   \
+// RUN:   -I%S/Inputs/search-path-usage/a  \
+// RUN:   -I%S/Inputs/search-path-usage/a_next \
+// RUN:   -I%S/Inputs/search-path-usage/b  \
+// RUN:   -I%S/Inputs/search-path-usage/c  \
+// RUN:   -I%S/Inputs/search-path-usage/d  \
+// RUN:   -DINCLUDE -verify
+#ifdef INCLUDE
+#include "a.h" // \
+// expected-remark-re {{search path used: '{{.*}}/search-path-usage/a'}} \
+// expected-remark-re@#a-include-next {{search path used: '{{.*}}/search-path-usage/a_next'}}
+#include "d.h" // \
+// expected-remark-re {{search path used: '{{.*}}/search-path-usage/d'}}
+#endif
+
+// Check that framework search paths are reported.
+//
+// RUN: %clang_cc1 -Eonly %s -Rsearch-path-usage \
+// RUN:   -F%S/Inputs/search-path-usage/FwA  \
+// RUN:   -F%S/Inputs/search-path-usage/FwB  \
+// RUN:   -DFRAMEWORK -verify
+#ifdef FRAMEWORK
+#include "FrameworkA/FrameworkA.h" // \
+// expected-remark-re {{search path used: '{{.*}}/search-path-usage/FwA'}}
+#endif
+
+// Check that system search paths are reported.
+//
+// RUN: %clang_cc1 -Eonly %s -Rsearch-path-usage \
+// RUN:   -isystem %S/Inputs/search-path-usage/b \
+// RUN:   -isystem %S/Inputs/search-path-usage/d \
+// RUN:   -DSYSTEM -verify
+#ifdef SYSTEM
+#include "b.h" // \
+// expected-remark-re {{search path used: '{{.*}}/search-path-usage/b'}}
+#endif
+
+// Check that sysroot-based search paths are reported.
+//
+// RUN: %clang_cc1 -Eonly %s -Rsearch-path-usage \
+// RUN:   -isysroot %S/Inputs/search-path-usage  \
+// RUN:   -iwithsysroot /b   \
+// RUN:   -iwithsysroot /d   \
+// RUN:   -DSYSROOT -verify
+#ifdef SYSROOT
+#include "d.h" // \
+// expected-remark {{search path used: '/d'}}
+#endif
+
+// Check that search paths used by `__has_include()` are reported.
+//
+// RUN: %clang_cc1 -Eonly %s -Rsearch-path-usage \
+// RUN:   -I%S/Inputs/search-path-usage/b\
+// RUN:   -I%S/Inputs/search-path-usage/d\
+// RUN:   -DHAS_INCLUDE -verify
+#ifdef HAS_INCLUDE
+#if __has_include("b.h") // \
+// expected-remark-re {{search path used: '{{.*}}/search-path-usage/b'}}
+#endif
+#if __has_include("x.h")
+#endif
+#endif
+
+// Check that search paths used by `#import` are reported.
+//
+// RUN: %clang_cc1 -Eonly %s -Rsearch-path-usage \
+// RUN:   -I%S/Inputs/search-path-usage/b\
+// RUN:   -I%S/Inputs/search-path-usage/d\
+// RUN:   -DIMPORT -verify
+#ifdef IMPORT
+#import "d.h" // \
+// expected-remark-re {{search path used: '{{.*}}/search-path-usage/d'}}
+#endif
+
+// Check that used header maps are reported when the target file exists.
+//
+// RUN: sed "s|DIR|%/S/Inputs/search-path-usage|g" \
+// RUN: %S/Inputs/search-path-usage/b.hmap.json.template > %t/b.hmap.json
+// RUN: %hmaptool write %t/b.hmap.json %t/b.hmap
+// RUN: %clang_cc1 -Eonly %s -Rsearch-path-usage \
+// RUN:   -I %t/b.hmap   \
+// RUN:   -I b   \
+// RUN:   -DHMAP -verify
+#ifdef HMAP
+#include "b.h" // \
+// expected-remark-re {{search path used: '{{.*}}/b.hmap'}}
+#endif
+
+// Check that unused header map are not reported.
+//
+// RUN: %clang_cc1 -Eonly %s -

[PATCH] D102923: [clang][lex] Remark on search path usage

2021-10-12 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 added a comment.

Thanks for the review, I handled the header map case and added tests. I'll 
commit once the CI passes.




Comment at: clang/lib/Lex/HeaderSearch.cpp:473
+  // The case where the target file **does not exist** is handled here:
+  HS.noteLookupUsage(*HS.searchDirIdx(*this), IncludeLoc);
   return None;

Note: Here's the header map special case for when a file matched but does not 
exist.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102923

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


[PATCH] D111617: [RISCV] Lazily add RVV C intrinsics.

2021-10-12 Thread Roger Ferrer Ibanez via Phabricator via cfe-commits
rogfer01 added inline comments.



Comment at: clang/lib/Sema/SemaLookup.cpp:923
+
+  const RVVIntrinsicInfo *Intrinsic = std::find_if(
+  std::begin(RVVIntrinsicInfos), std::end(RVVIntrinsicInfos),

Not for this patch: I think this table may be a bit large so all lookups 
(including those that will fail) will be slower after a `#pragma riscv 
intrinsic vector` is found.

Filtering them as fast as possible (looking at the spec shows that currently 
all RVV intrinsics start with `v`) or using some hash table (if too difficult 
to build at compile time we could build it the first time we get here?) might 
be something we want to do.



Comment at: clang/lib/Sema/SemaLookup.cpp:1011
 
+  if (PP.getPredefines() == "#define __riscv_pragma_vector_intrinsics") {
+const TargetInfo &TI = Context.getTargetInfo();

This seems a bit fragile if there are more predefines than just this one. I 
understand the intent is to avoid looking up the RVV builtin every time, only 
do that if we have found the pragma, right?

Several pragma handlers receive a reference to `Sema` (in an object called 
`Action` or `Actions`) and then they notify `Sema` (via a member function that 
would have to be added to it) about having parsed the pragma. That could be 
used to set some flag to true in `Sema` itself and also emit diagnostics if we 
want (e.g. what if the pragma is used twice? can it be used anywhere?).

Do you think this would be workable?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111617

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


[PATCH] D111623: [clang-tidy] Update documentation of check bugprone-unused-return-value [NFC].

2021-10-12 Thread Balázs Kéri via Phabricator via cfe-commits
balazske created this revision.
Herald added subscribers: steakhal, martong, gamesh411, Szelethus, dkrupp, 
xazax.hun, whisperity.
balazske requested review of this revision.
Herald added a project: clang-tools-extra.
Herald added a subscriber: cfe-commits.

The list of checked functions was incomplete in the description.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D111623

Files:
  clang-tools-extra/docs/clang-tidy/checks/bugprone-unused-return-value.rst


Index: clang-tools-extra/docs/clang-tidy/checks/bugprone-unused-return-value.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/bugprone-unused-return-value.rst
+++ clang-tools-extra/docs/clang-tidy/checks/bugprone-unused-return-value.rst
@@ -10,9 +10,25 @@
 
 .. option:: CheckedFunctions
 
-   Semicolon-separated list of functions to check. Defaults to
-   
``::std::async;::std::launder;::std::remove;::std::remove_if;::std::unique;::std::unique_ptr::release;::std::basic_string::empty;::std::vector::empty``.
-   This means that the calls to following functions are checked by default:
+   Semicolon-separated list of functions to check. The function is checked if
+   the name and scope matches, with any arguments.
+   By default the following functions are checked:
+   ``std::async, std::launder, std::remove, std::remove_if, std::unique,
+   std::unique_ptr::release, std::basic_string::empty, std::vector::empty,
+   std::back_inserter, std::distance, std::find, std::find_if, std::inserter,
+   std::lower_bound, std::make_pair, std::map::count, std::map::find,
+   std::map::lower_bound, std::multimap::equal_range,
+   std::multimap::upper_bound, std::set::count, std::set::find, std::setfill,
+   std::setprecision, std::setw, std::upper_bound, std::vector::at,
+   bsearch, ferror, feof, isalnum, isalpha, isblank, iscntrl, isdigit, isgraph,
+   islower, isprint, ispunct, isspace, isupper, iswalnum, iswprint, iswspace,
+   isxdigit, memchr, memcmp, strcmp, strcoll, strncmp, strpbrk, strrchr,
+   strspn, strstr, wcscmp, access, bind, connect, difftime, dlsym, fnmatch,
+   getaddrinfo, getopt, htonl, htons, iconv_open, inet_addr, isascii, isatty,
+   mmap, newlocale, openat, pathconf, pthread_equal, pthread_getspecific,
+   pthread_mutex_trylock, readdir, readlink, recvmsg, regexec, scandir,
+   semget, setjmp, shm_open, shmget, sigismember, strcasecmp, strsignal,
+   ttyname``
 
- ``std::async()``. Not using the return value makes the call synchronous.
- ``std::launder()``. Not using the return value usually means that the


Index: clang-tools-extra/docs/clang-tidy/checks/bugprone-unused-return-value.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/bugprone-unused-return-value.rst
+++ clang-tools-extra/docs/clang-tidy/checks/bugprone-unused-return-value.rst
@@ -10,9 +10,25 @@
 
 .. option:: CheckedFunctions
 
-   Semicolon-separated list of functions to check. Defaults to
-   ``::std::async;::std::launder;::std::remove;::std::remove_if;::std::unique;::std::unique_ptr::release;::std::basic_string::empty;::std::vector::empty``.
-   This means that the calls to following functions are checked by default:
+   Semicolon-separated list of functions to check. The function is checked if
+   the name and scope matches, with any arguments.
+   By default the following functions are checked:
+   ``std::async, std::launder, std::remove, std::remove_if, std::unique,
+   std::unique_ptr::release, std::basic_string::empty, std::vector::empty,
+   std::back_inserter, std::distance, std::find, std::find_if, std::inserter,
+   std::lower_bound, std::make_pair, std::map::count, std::map::find,
+   std::map::lower_bound, std::multimap::equal_range,
+   std::multimap::upper_bound, std::set::count, std::set::find, std::setfill,
+   std::setprecision, std::setw, std::upper_bound, std::vector::at,
+   bsearch, ferror, feof, isalnum, isalpha, isblank, iscntrl, isdigit, isgraph,
+   islower, isprint, ispunct, isspace, isupper, iswalnum, iswprint, iswspace,
+   isxdigit, memchr, memcmp, strcmp, strcoll, strncmp, strpbrk, strrchr,
+   strspn, strstr, wcscmp, access, bind, connect, difftime, dlsym, fnmatch,
+   getaddrinfo, getopt, htonl, htons, iconv_open, inet_addr, isascii, isatty,
+   mmap, newlocale, openat, pathconf, pthread_equal, pthread_getspecific,
+   pthread_mutex_trylock, readdir, readlink, recvmsg, regexec, scandir,
+   semget, setjmp, shm_open, shmget, sigismember, strcasecmp, strsignal,
+   ttyname``
 
- ``std::async()``. Not using the return value makes the call synchronous.
- ``std::launder()``. Not using the return value usually means that the
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D111617: [RISCV] Lazily add RVV C intrinsics.

2021-10-12 Thread Kito Cheng via Phabricator via cfe-commits
kito-cheng added inline comments.



Comment at: clang/lib/Sema/SemaLookup.cpp:923
+
+  const RVVIntrinsicInfo *Intrinsic = std::find_if(
+  std::begin(RVVIntrinsicInfos), std::end(RVVIntrinsicInfos),

rogfer01 wrote:
> Not for this patch: I think this table may be a bit large so all lookups 
> (including those that will fail) will be slower after a `#pragma riscv 
> intrinsic vector` is found.
> 
> Filtering them as fast as possible (looking at the spec shows that currently 
> all RVV intrinsics start with `v`) or using some hash table (if too difficult 
> to build at compile time we could build it the first time we get here?) might 
> be something we want to do.
OpenCL using a tablegen-based generator to generate a big swtich table to speed 
up the lookup rather than linear scan, here is generated file:

https://gist.github.com/kito-cheng/46616c82c0f25e5df31ff5eaa14914ba#file-openclbuiltins-inc-L8055

I think we could using same approach to prevent the slow down.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111617

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


[PATCH] D111228: [clang-tidy] Add options to bugprone-unused-return-value.

2021-10-12 Thread Balázs Kéri via Phabricator via cfe-commits
balazske abandoned this revision.
balazske added a comment.

Checker configuration can be solved in reusable way by introducing 
"configuration variables" and manipulation of these with set operations.

https://reviews.llvm.org/D111623 was created to update the checker 
documentation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111228

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


[PATCH] D111625: [clang-tidy] bugprone-argument-comment: SourceLocation valid judgment avoid emitting coredump in isInSystemHeader

2021-10-12 Thread gehry via Phabricator via cfe-commits
Sockke created this revision.
Sockke added reviewers: aaron.ballman, njames93, george.burgess.iv, hokein.
Herald added a subscriber: xazax.hun.
Sockke requested review of this revision.
Herald added a project: clang-tools-extra.
Herald added a subscriber: cfe-commits.

If the Node has an invalid location, it will trigger assert in 
isInSystemHeader(...).

  #include 
  /*
...
  */

invalid sloc like "__va_list_tag"
coredump with "Assertion `Loc.isValid() && "Can't get file characteristic of 
invalid loc!"' failed." in getFileCharacteristic(SourceLocation)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D111625

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


Index: clang-tools-extra/clang-tidy/bugprone/ArgumentCommentCheck.cpp
===
--- clang-tools-extra/clang-tidy/bugprone/ArgumentCommentCheck.cpp
+++ clang-tools-extra/clang-tidy/bugprone/ArgumentCommentCheck.cpp
@@ -24,6 +24,8 @@
   if (const auto *D = Node.getDeclContext()->getEnclosingNamespaceContext())
 if (D->isStdNamespace())
   return true;
+  if (Node.getLocation().isInvalid())
+return false;
   return Node.getASTContext().getSourceManager().isInSystemHeader(
   Node.getLocation());
 }


Index: clang-tools-extra/clang-tidy/bugprone/ArgumentCommentCheck.cpp
===
--- clang-tools-extra/clang-tidy/bugprone/ArgumentCommentCheck.cpp
+++ clang-tools-extra/clang-tidy/bugprone/ArgumentCommentCheck.cpp
@@ -24,6 +24,8 @@
   if (const auto *D = Node.getDeclContext()->getEnclosingNamespaceContext())
 if (D->isStdNamespace())
   return true;
+  if (Node.getLocation().isInvalid())
+return false;
   return Node.getASTContext().getSourceManager().isInSystemHeader(
   Node.getLocation());
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 544d89e - [OpenCL] Add atomic_half type builtins

2021-10-12 Thread Sven van Haastregt via cfe-commits

Author: Sven van Haastregt
Date: 2021-10-12T10:45:30+01:00
New Revision: 544d89e847d42ce8856296752b0fb279aa89aace

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

LOG: [OpenCL] Add atomic_half type builtins

Add atomic_half types and builtins operating on the types from the
cl_ext_float_atomics extension.

Patch by Haonan Yang.

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

Added: 


Modified: 
clang/lib/Headers/opencl-c.h
clang/lib/Sema/OpenCLBuiltins.td
clang/lib/Sema/Sema.cpp
clang/test/SemaOpenCL/atomic-ops.cl

Removed: 




diff  --git a/clang/lib/Headers/opencl-c.h b/clang/lib/Headers/opencl-c.h
index 705a3231b577..562e0551ffdc 100644
--- a/clang/lib/Headers/opencl-c.h
+++ b/clang/lib/Headers/opencl-c.h
@@ -13640,6 +13640,118 @@ uintptr_t __ovld atomic_fetch_sub_explicit(volatile 
__local atomic_uintptr_t *ob
 // The functionality added by cl_ext_float_atomics extension
 #if defined(cl_ext_float_atomics)
 
+#if defined(__opencl_c_ext_fp16_global_atomic_load_store)
+void __ovld atomic_store(volatile __global atomic_half *object, half operand);
+void __ovld atomic_store_explicit(volatile __global atomic_half *object,
+  half operand, memory_order order);
+void __ovld atomic_store_explicit(volatile __global atomic_half *object,
+  half operand, memory_order order,
+  memory_scope scope);
+half __ovld atomic_load(volatile __global atomic_half *object);
+half __ovld atomic_load_explicit(volatile __global atomic_half *object,
+ memory_order order);
+half __ovld atomic_load_explicit(volatile __global atomic_half *object,
+ memory_order order, memory_scope scope);
+half __ovld atomic_exchange(volatile __global atomic_half *object,
+half operand);
+half __ovld atomic_exchange_explicit(volatile __global atomic_half *object,
+ half operand, memory_order order);
+half __ovld atomic_exchange_explicit(volatile __global atomic_half *object,
+ half operand, memory_order order,
+ memory_scope scope);
+#endif // defined(__opencl_c_ext_fp16_global_atomic_load_store)
+
+#if defined(__opencl_c_ext_fp16_local_atomic_load_store)
+void __ovld atomic_store(volatile __local atomic_half *object, half operand);
+void __ovld atomic_store_explicit(volatile __local atomic_half *object,
+  half operand, memory_order order);
+void __ovld atomic_store_explicit(volatile __local atomic_half *object,
+  half operand, memory_order order,
+  memory_scope scope);
+half __ovld atomic_load(volatile __local atomic_half *object);
+half __ovld atomic_load_explicit(volatile __local atomic_half *object,
+ memory_order order);
+half __ovld atomic_load_explicit(volatile __local atomic_half *object,
+ memory_order order, memory_scope scope);
+half __ovld atomic_exchange(volatile __local atomic_half *object, half 
operand);
+half __ovld atomic_exchange_explicit(volatile __local atomic_half *object,
+ half operand, memory_order order);
+half __ovld atomic_exchange_explicit(volatile __local atomic_half *object,
+ half operand, memory_order order,
+ memory_scope scope);
+#endif // defined(__opencl_c_ext_fp16_local_atomic_load_store)
+
+#if defined(__opencl_c_ext_fp16_global_atomic_load_store) &&   
\
+defined(__opencl_c_ext_fp16_local_atomic_load_store)
+void __ovld atomic_store(volatile atomic_half *object, half operand);
+void __ovld atomic_store_explicit(volatile atomic_half *object, half operand,
+  memory_order order);
+void __ovld atomic_store_explicit(volatile atomic_half *object, half operand,
+  memory_order order, memory_scope scope);
+half __ovld atomic_load(volatile atomic_half *object);
+half __ovld atomic_load_explicit(volatile atomic_half *object,
+ memory_order order);
+half __ovld atomic_load_explicit(volatile atomic_half *object,
+ memory_order order, memory_scope scope);
+half __ovld atomic_exchange(volatile atomic_half *object, half operand);
+half __ovld atomic_exchange_explicit(volatile atomic_half *object, half 
operand,
+ memory_order order);
+half __ovld atomic_exchange_explicit(volatile atomic_half *object, half 
operand,
+   

[PATCH] D109740: [OpenCL] Add atomic_half type builtins

2021-10-12 Thread Sven van Haastregt via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG544d89e847d4: [OpenCL] Add atomic_half type builtins 
(authored by svenvh).

Changed prior to commit:
  https://reviews.llvm.org/D109740?vs=376467&id=378938#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109740

Files:
  clang/lib/Headers/opencl-c.h
  clang/lib/Sema/OpenCLBuiltins.td
  clang/lib/Sema/Sema.cpp
  clang/test/SemaOpenCL/atomic-ops.cl

Index: clang/test/SemaOpenCL/atomic-ops.cl
===
--- clang/test/SemaOpenCL/atomic-ops.cl
+++ clang/test/SemaOpenCL/atomic-ops.cl
@@ -19,7 +19,7 @@
 
 atomic_int gn;
 void f(atomic_int *i, const atomic_int *ci,
-   atomic_intptr_t *p, atomic_float *f, atomic_double *d, atomic_half *h, // expected-error {{unknown type name 'atomic_half'}}
+   atomic_intptr_t *p, atomic_float *f, atomic_double *d, atomic_half *h,
int *I, const int *CI,
intptr_t *P, float *D, struct S *s1, struct S *s2,
global atomic_int *i_g, local atomic_int *i_l, private atomic_int *i_p,
Index: clang/lib/Sema/Sema.cpp
===
--- clang/lib/Sema/Sema.cpp
+++ clang/lib/Sema/Sema.cpp
@@ -367,6 +367,11 @@
 AddPointerSizeDependentTypes();
   }
 
+  if (getOpenCLOptions().isSupported("cl_khr_fp16", getLangOpts())) {
+auto AtomicHalfT = Context.getAtomicType(Context.HalfTy);
+addImplicitTypedef("atomic_half", AtomicHalfT);
+  }
+
   std::vector Atomic64BitTypes;
   if (getOpenCLOptions().isSupported("cl_khr_int64_base_atomics",
  getLangOpts()) &&
Index: clang/lib/Sema/OpenCLBuiltins.td
===
--- clang/lib/Sema/OpenCLBuiltins.td
+++ clang/lib/Sema/OpenCLBuiltins.td
@@ -85,16 +85,25 @@
 
 def FuncExtOpenCLCPipes  : FunctionExtension<"__opencl_c_pipes">;
 def FuncExtOpenCLCWGCollectiveFunctions  : FunctionExtension<"__opencl_c_work_group_collective_functions">;
+def FuncExtFloatAtomicsFp16GlobalLoadStore  : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp16_global_atomic_load_store">;
+def FuncExtFloatAtomicsFp16LocalLoadStore   : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp16_local_atomic_load_store">;
+def FuncExtFloatAtomicsFp16GenericLoadStore : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp16_global_atomic_load_store __opencl_c_ext_fp16_local_atomic_load_store">;
+def FuncExtFloatAtomicsFp16GlobalAdd : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp16_global_atomic_add">;
 def FuncExtFloatAtomicsFp32GlobalAdd : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp32_global_atomic_add">;
 def FuncExtFloatAtomicsFp64GlobalAdd : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp64_global_atomic_add">;
+def FuncExtFloatAtomicsFp16LocalAdd  : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp16_local_atomic_add">;
 def FuncExtFloatAtomicsFp32LocalAdd  : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp32_local_atomic_add">;
 def FuncExtFloatAtomicsFp64LocalAdd  : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp64_local_atomic_add">;
+def FuncExtFloatAtomicsFp16GenericAdd: FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp16_local_atomic_add __opencl_c_ext_fp16_global_atomic_add">;
 def FuncExtFloatAtomicsFp32GenericAdd: FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp32_local_atomic_add __opencl_c_ext_fp32_global_atomic_add">;
 def FuncExtFloatAtomicsFp64GenericAdd: FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp64_local_atomic_add __opencl_c_ext_fp64_global_atomic_add">;
+def FuncExtFloatAtomicsFp16GlobalMinMax  : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp16_global_atomic_min_max">;
 def FuncExtFloatAtomicsFp32GlobalMinMax  : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp32_global_atomic_min_max">;
 def FuncExtFloatAtomicsFp64GlobalMinMax  : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp64_global_atomic_min_max">;
+def FuncExtFloatAtomicsFp16LocalMinMax   : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp16_local_atomic_min_max">;
 def FuncExtFloatAtomicsFp32LocalMinMax   : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp32_local_atomic_min_max">;
 def FuncExtFloatAtomicsFp64LocalMinMax   : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp64_local_atomic_min_max">;
+def FuncExtFloatAtomicsFp16GenericMinMax : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp16_local_atomic_min_max __opencl_c_ext_fp16_global_atomic_min_max">;
 def FuncExtFloatAtomicsFp32GenericMinMax : FunctionExtension<"cl_ext_float_atomics __opencl_c_ext_fp32_local_atomic_min_max __opencl_c_ext_fp32_global_atomic_min_max">;
 def FuncExtFloatA

[PATCH] D111623: [clang-tidy] Update documentation of check bugprone-unused-return-value [NFC].

2021-10-12 Thread Balázs Benics via Phabricator via cfe-commits
steakhal accepted this revision.
steakhal added a comment.
This revision is now accepted and ready to land.

I checked the list, now it's complete.
Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111623

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


[PATCH] D111560: [clang][modules] Cache loads of explicit modules imported by PCH

2021-10-12 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 updated this revision to Diff 378945.
jansvoboda11 added a comment.

Implemented alternative approach: attach the caching listener to PCH reading as 
well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111560

Files:
  clang/lib/Frontend/CompilerInstance.cpp
  clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
  clang/test/ClangScanDeps/modules-pch.c
  clang/test/Modules/Inputs/pch-shared-module/mod.h
  clang/test/Modules/Inputs/pch-shared-module/module.modulemap
  clang/test/Modules/Inputs/pch-shared-module/pch.h
  clang/test/Modules/pch-shared-module.c

Index: clang/test/Modules/pch-shared-module.c
===
--- /dev/null
+++ clang/test/Modules/pch-shared-module.c
@@ -0,0 +1,14 @@
+// rm -rf %t && mkdir %t
+
+// RUN: %clang_cc1 -fmodules -emit-module -fmodule-name=mod %S/Inputs/pch-shared-module/module.modulemap -o %t/mod.pcm
+
+// RUN: %clang_cc1 -fmodules -emit-pch %S/Inputs/pch-shared-module/pch.h -o %t/pch.h.gch \
+// RUN:   -fmodule-file=%t/mod.pcm -fmodule-map-file=%S/Inputs/pch-shared-module/module.modulemap
+
+// Check that `mod.pcm` is loaded correctly, even though it's imported by the PCH as well.
+// RUN: %clang_cc1 -fmodules -fsyntax-only %s -include-pch %t/pch.h.gch -I %S/Inputs/pch-shared-module \
+// RUN:   -fmodule-file=%t/mod.pcm -fmodule-map-file=%S/Inputs/pch-shared-module/module.modulemap -verify
+
+#include "mod.h"
+
+// expected-no-diagnostics
Index: clang/test/Modules/Inputs/pch-shared-module/pch.h
===
--- /dev/null
+++ clang/test/Modules/Inputs/pch-shared-module/pch.h
@@ -0,0 +1 @@
+#include "mod.h"
Index: clang/test/Modules/Inputs/pch-shared-module/module.modulemap
===
--- /dev/null
+++ clang/test/Modules/Inputs/pch-shared-module/module.modulemap
@@ -0,0 +1 @@
+module mod { header "mod.h" }
Index: clang/test/ClangScanDeps/modules-pch.c
===
--- clang/test/ClangScanDeps/modules-pch.c
+++ clang/test/ClangScanDeps/modules-pch.c
@@ -229,8 +229,7 @@
 // CHECK-TU-WITH-COMMON-NEXT:   "command-line": [
 // CHECK-TU-WITH-COMMON-NEXT: "-fno-implicit-modules",
 // CHECK-TU-WITH-COMMON-NEXT: "-fno-implicit-module-maps",
-// FIXME: Figure out why we need `=ModCommon2` here for Clang to pick up the PCM.
-// CHECK-TU-WITH-COMMON-NEXT: "-fmodule-file=ModCommon2=[[PREFIX]]/build/{{.*}}/ModCommon2-{{.*}}.pcm",
+// CHECK-TU-WITH-COMMON-NEXT: "-fmodule-file=[[PREFIX]]/build/{{.*}}/ModCommon2-{{.*}}.pcm",
 // CHECK-TU-WITH-COMMON-NEXT: "-fmodule-map-file=[[PREFIX]]/module.modulemap"
 // CHECK-TU-WITH-COMMON-NEXT: "-fmodule-file=[[PREFIX]]/build/[[HASH_MOD_TU_WITH_COMMON]]/ModTUWithCommon-{{.*}}.pcm",
 // CHECK-TU-WITH-COMMON-NEXT: "-fmodule-map-file=[[PREFIX]]/module.modulemap"
Index: clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
===
--- clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
+++ clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
@@ -38,7 +38,7 @@
   };
 
   for (const PrebuiltModuleDep &PMD : PrebuiltModuleDeps) {
-Args.push_back("-fmodule-file=" + PMD.ModuleName + "=" + PMD.PCMFile);
+Args.push_back("-fmodule-file=" + PMD.PCMFile);
 Args.push_back("-fmodule-map-file=" + PMD.ModuleMapFile);
   }
 
Index: clang/lib/Frontend/CompilerInstance.cpp
===
--- clang/lib/Frontend/CompilerInstance.cpp
+++ clang/lib/Frontend/CompilerInstance.cpp
@@ -441,6 +441,52 @@
   InitOpts.RemappedFilesKeepOriginalName);
 }
 
+namespace {
+// Helper to recursively read the module names for all modules we're adding.
+// We mark these as known and redirect any attempt to load that module to
+// the files we were handed.
+struct ReadModuleNames : ASTReaderListener {
+  Preprocessor &PP;
+  llvm::SmallVector LoadedModules;
+
+  ReadModuleNames(Preprocessor &PP) : PP(PP) {}
+
+  void ReadModuleName(StringRef ModuleName) override {
+LoadedModules.push_back(PP.getIdentifierInfo(ModuleName));
+  }
+
+  void registerAll() {
+ModuleMap &MM = PP.getHeaderSearchInfo().getModuleMap();
+for (auto *II : LoadedModules)
+  MM.cacheModuleLoad(*II, MM.findModule(II->getName()));
+LoadedModules.clear();
+  }
+
+  void markAllUnavailable() {
+for (auto *II : LoadedModules) {
+  if (Module *M = PP.getHeaderSearchInfo().getModuleMap().findModule(
+  II->getName())) {
+M->HasIncompatibleModuleFile = true;
+
+// Mark module as available if the only reason it was unavailable
+// was missing headers.
+SmallVector Stack;
+Stack.push_back(M);
+while (!St

[clang] 4445135 - [clang][lex] Remark on search path usage

2021-10-12 Thread Jan Svoboda via cfe-commits

Author: Jan Svoboda
Date: 2021-10-12T12:20:55+02:00
New Revision: 444513510999e4c1ea23253654196793834d53bf

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

LOG: [clang][lex] Remark on search path usage

For dependency scanning, it would be useful to collect header search paths 
(provided on command-line via `-I` and friends) that were actually used during 
preprocessing. This patch adds that feature to `HeaderSearch` along with a new 
remark that reports such paths as they get used.

Previous version of this patch tried to use the existing `LookupFileCache` to 
report used paths via `HitIdx`. That doesn't work for `ComputeUserEntryUsage` 
(which is intended to be called *after* preprocessing), because it indexes used 
search paths by the file name. This means the values get overwritten when the 
code contains `#include_next`.

Note that `HeaderSearch` doesn't use `HeaderSearchOptions::UserEntries` 
directly. Instead, `InitHeaderSearch` pre-processes them (adds 
platform-specific paths, removes duplicates, removes paths that don't exist) 
and creates `DirectoryLookup` instances. This means we need a mechanism for 
translating between those two. It's not possible to go from `DirectoryLookup` 
back to the original `HeaderSearch`, so `InitHeaderSearch` now tracks the 
relationships explicitly.

Depends on D111557.

Reviewed By: dexonsmith

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

Added: 

clang/test/Preprocessor/Inputs/search-path-usage/FwA/FrameworkA.framework/Headers/FrameworkA.h

clang/test/Preprocessor/Inputs/search-path-usage/FwA/FrameworkA.framework/Modules/module.modulemap

clang/test/Preprocessor/Inputs/search-path-usage/FwB/FrameworkB.framework/Headers/FrameworkB.h

clang/test/Preprocessor/Inputs/search-path-usage/FwB/FrameworkB.framework/Modules/module.modulemap
clang/test/Preprocessor/Inputs/search-path-usage/a/a.h
clang/test/Preprocessor/Inputs/search-path-usage/a_next/a.h
clang/test/Preprocessor/Inputs/search-path-usage/b.hmap.json.template
clang/test/Preprocessor/Inputs/search-path-usage/b/b.h
clang/test/Preprocessor/Inputs/search-path-usage/d/d.h

clang/test/Preprocessor/Inputs/search-path-usage/modulemap_abs/module.modulemap.template
clang/test/Preprocessor/search-path-usage.m

Modified: 
clang/include/clang/Basic/DiagnosticGroups.td
clang/include/clang/Basic/DiagnosticLexKinds.td
clang/include/clang/Lex/HeaderMap.h
clang/include/clang/Lex/HeaderSearch.h
clang/lib/Frontend/InitHeaderSearch.cpp
clang/lib/Lex/HeaderMap.cpp
clang/lib/Lex/HeaderSearch.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticGroups.td 
b/clang/include/clang/Basic/DiagnosticGroups.td
index d9db3482dbda7..0d8c2cb5b67d4 100644
--- a/clang/include/clang/Basic/DiagnosticGroups.td
+++ b/clang/include/clang/Basic/DiagnosticGroups.td
@@ -751,6 +751,7 @@ def UnusedLocalTypedef : DiagGroup<"unused-local-typedef">;
 def UnusedPropertyIvar :  DiagGroup<"unused-property-ivar">;
 def UnusedGetterReturnValue : DiagGroup<"unused-getter-return-value">;
 def UsedButMarkedUnused : DiagGroup<"used-but-marked-unused">;
+def UsedSearchPath : DiagGroup<"search-path-usage">;
 def UserDefinedLiterals : DiagGroup<"user-defined-literals">;
 def UserDefinedWarnings : DiagGroup<"user-defined-warnings">;
 def ReorderCtor : DiagGroup<"reorder-ctor">;

diff  --git a/clang/include/clang/Basic/DiagnosticLexKinds.td 
b/clang/include/clang/Basic/DiagnosticLexKinds.td
index 7fbf19ed6cb3f..92c6b0bbffc30 100644
--- a/clang/include/clang/Basic/DiagnosticLexKinds.td
+++ b/clang/include/clang/Basic/DiagnosticLexKinds.td
@@ -446,6 +446,9 @@ def warn_pp_hdrstop_filename_ignored : Warning<
   "#pragma hdrstop filename not supported, "
   "/Fp can be used to specify precompiled header filename">,
   InGroup;
+def remark_pp_search_path_usage : Remark<
+  "search path used: '%0'">,
+  InGroup;
 def err_pp_file_not_found_angled_include_not_fatal : Error<
   "'%0' file not found with  %select{include|import}1; "
   "use \"quotes\" instead">;

diff  --git a/clang/include/clang/Lex/HeaderMap.h 
b/clang/include/clang/Lex/HeaderMap.h
index 53108b00bd16d..ca6a49bae3bfe 100644
--- a/clang/include/clang/Lex/HeaderMap.h
+++ b/clang/include/clang/Lex/HeaderMap.h
@@ -77,13 +77,6 @@ class HeaderMap : private HeaderMapImpl {
   static std::unique_ptr Create(const FileEntry *FE,
FileManager &FM);
 
-  /// Check to see if the specified relative filename is located in this
-  /// HeaderMap.  If so, open it and return its FileEntry.  If RawPath is not
-  /// NULL and the file is found, RawPath will be set to the raw path at which
-  /// the file was found in the file system. For example, for a search path
-  /// ".." 

[PATCH] D102923: [clang][lex] Remark on search path usage

2021-10-12 Thread Jan Svoboda via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG444513510999: [clang][lex] Remark on search path usage 
(authored by jansvoboda11).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102923

Files:
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticLexKinds.td
  clang/include/clang/Lex/HeaderMap.h
  clang/include/clang/Lex/HeaderSearch.h
  clang/lib/Frontend/InitHeaderSearch.cpp
  clang/lib/Lex/HeaderMap.cpp
  clang/lib/Lex/HeaderSearch.cpp
  
clang/test/Preprocessor/Inputs/search-path-usage/FwA/FrameworkA.framework/Headers/FrameworkA.h
  
clang/test/Preprocessor/Inputs/search-path-usage/FwA/FrameworkA.framework/Modules/module.modulemap
  
clang/test/Preprocessor/Inputs/search-path-usage/FwB/FrameworkB.framework/Headers/FrameworkB.h
  
clang/test/Preprocessor/Inputs/search-path-usage/FwB/FrameworkB.framework/Modules/module.modulemap
  clang/test/Preprocessor/Inputs/search-path-usage/a/a.h
  clang/test/Preprocessor/Inputs/search-path-usage/a_next/a.h
  clang/test/Preprocessor/Inputs/search-path-usage/b.hmap.json.template
  clang/test/Preprocessor/Inputs/search-path-usage/b/b.h
  clang/test/Preprocessor/Inputs/search-path-usage/d/d.h
  
clang/test/Preprocessor/Inputs/search-path-usage/modulemap_abs/module.modulemap.template
  clang/test/Preprocessor/search-path-usage.m

Index: clang/test/Preprocessor/search-path-usage.m
===
--- /dev/null
+++ clang/test/Preprocessor/search-path-usage.m
@@ -0,0 +1,146 @@
+// RUN: rm -rf %t && mkdir %t
+
+// Check that search paths used by `#include` and `#include_next` are reported.
+//
+// RUN: %clang_cc1 -Eonly %s -Rsearch-path-usage   \
+// RUN:   -I%S/Inputs/search-path-usage/a  \
+// RUN:   -I%S/Inputs/search-path-usage/a_next \
+// RUN:   -I%S/Inputs/search-path-usage/b  \
+// RUN:   -I%S/Inputs/search-path-usage/c  \
+// RUN:   -I%S/Inputs/search-path-usage/d  \
+// RUN:   -DINCLUDE -verify
+#ifdef INCLUDE
+#include "a.h" // \
+// expected-remark-re {{search path used: '{{.*}}/search-path-usage/a'}} \
+// expected-remark-re@#a-include-next {{search path used: '{{.*}}/search-path-usage/a_next'}}
+#include "d.h" // \
+// expected-remark-re {{search path used: '{{.*}}/search-path-usage/d'}}
+#endif
+
+// Check that framework search paths are reported.
+//
+// RUN: %clang_cc1 -Eonly %s -Rsearch-path-usage \
+// RUN:   -F%S/Inputs/search-path-usage/FwA  \
+// RUN:   -F%S/Inputs/search-path-usage/FwB  \
+// RUN:   -DFRAMEWORK -verify
+#ifdef FRAMEWORK
+#include "FrameworkA/FrameworkA.h" // \
+// expected-remark-re {{search path used: '{{.*}}/search-path-usage/FwA'}}
+#endif
+
+// Check that system search paths are reported.
+//
+// RUN: %clang_cc1 -Eonly %s -Rsearch-path-usage \
+// RUN:   -isystem %S/Inputs/search-path-usage/b \
+// RUN:   -isystem %S/Inputs/search-path-usage/d \
+// RUN:   -DSYSTEM -verify
+#ifdef SYSTEM
+#include "b.h" // \
+// expected-remark-re {{search path used: '{{.*}}/search-path-usage/b'}}
+#endif
+
+// Check that sysroot-based search paths are reported.
+//
+// RUN: %clang_cc1 -Eonly %s -Rsearch-path-usage \
+// RUN:   -isysroot %S/Inputs/search-path-usage  \
+// RUN:   -iwithsysroot /b   \
+// RUN:   -iwithsysroot /d   \
+// RUN:   -DSYSROOT -verify
+#ifdef SYSROOT
+#include "d.h" // \
+// expected-remark {{search path used: '/d'}}
+#endif
+
+// Check that search paths used by `__has_include()` are reported.
+//
+// RUN: %clang_cc1 -Eonly %s -Rsearch-path-usage \
+// RUN:   -I%S/Inputs/search-path-usage/b\
+// RUN:   -I%S/Inputs/search-path-usage/d\
+// RUN:   -DHAS_INCLUDE -verify
+#ifdef HAS_INCLUDE
+#if __has_include("b.h") // \
+// expected-remark-re {{search path used: '{{.*}}/search-path-usage/b'}}
+#endif
+#if __has_include("x.h")
+#endif
+#endif
+
+// Check that search paths used by `#import` are reported.
+//
+// RUN: %clang_cc1 -Eonly %s -Rsearch-path-usage \
+// RUN:   -I%S/Inputs/search-path-usage/b\
+// RUN:   -I%S/Inputs/search-path-usage/d\
+// RUN:   -DIMPORT -verify
+#ifdef IMPORT
+#import "d.h" // \
+// expected-remark-re {{search path used: '{{.*}}/search-path-usage/d'}}
+#endif
+
+// Check that used header maps are reported when the target file exists.
+//
+// RUN: sed "s|DIR|%/S/Inputs/search-path-usage|g" \
+// RUN: %S/Inputs/search-path-usage/b.hmap.json.template > %t/b.hmap.json
+// RUN: %hmaptool write %t/b.hmap.json %t/b.hmap
+// RUN: %clang_cc1 -Eonly %s -Rsearch-path-usage \
+// RUN:   -I %t/b.hmap   \
+// RUN:   -I b   \
+// RUN:   -DHMAP -verify
+#ifdef HMAP
+#include "b.h" // \
+// expected-remark-re {{search path used: '{{.*}}/b.hmap'}}
+#endif
+
+// Check that unused header map are not reported.
+//
+// RUN: %cla

[clang] 477f5f4 - [RISCV][Clang] Fix RISCV vector header comment.

2021-10-12 Thread Ben Shi via cfe-commits

Author: jacquesguan
Date: 2021-10-12T10:26:25Z
New Revision: 477f5f4fca2b1d994045a0cb821ffb3873519243

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

LOG: [RISCV][Clang] Fix RISCV vector header comment.

Reviewed By: khchen

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

Added: 


Modified: 
clang/utils/TableGen/RISCVVEmitter.cpp

Removed: 




diff  --git a/clang/utils/TableGen/RISCVVEmitter.cpp 
b/clang/utils/TableGen/RISCVVEmitter.cpp
index 1f52c452e6e10..3611df145442a 100644
--- a/clang/utils/TableGen/RISCVVEmitter.cpp
+++ b/clang/utils/TableGen/RISCVVEmitter.cpp
@@ -1019,7 +1019,7 @@ void RVVEmitter::createHeader(raw_ostream &OS) {
 
   OS << "\n#ifdef __cplusplus\n";
   OS << "}\n";
-  OS << "#endif // __riscv_vector\n";
+  OS << "#endif // __cplusplus\n";
   OS << "#endif // __RISCV_VECTOR_H\n";
 }
 



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


[PATCH] D111597: [RISCV][Clang] Fix RISCV vector header comment.

2021-10-12 Thread Ben Shi 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 rG477f5f4fca2b: [RISCV][Clang] Fix RISCV vector header 
comment. (authored by jacquesguan, committed by benshi001).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111597

Files:
  clang/utils/TableGen/RISCVVEmitter.cpp


Index: clang/utils/TableGen/RISCVVEmitter.cpp
===
--- clang/utils/TableGen/RISCVVEmitter.cpp
+++ clang/utils/TableGen/RISCVVEmitter.cpp
@@ -1019,7 +1019,7 @@
 
   OS << "\n#ifdef __cplusplus\n";
   OS << "}\n";
-  OS << "#endif // __riscv_vector\n";
+  OS << "#endif // __cplusplus\n";
   OS << "#endif // __RISCV_VECTOR_H\n";
 }
 


Index: clang/utils/TableGen/RISCVVEmitter.cpp
===
--- clang/utils/TableGen/RISCVVEmitter.cpp
+++ clang/utils/TableGen/RISCVVEmitter.cpp
@@ -1019,7 +1019,7 @@
 
   OS << "\n#ifdef __cplusplus\n";
   OS << "}\n";
-  OS << "#endif // __riscv_vector\n";
+  OS << "#endif // __cplusplus\n";
   OS << "#endif // __RISCV_VECTOR_H\n";
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D111560: [clang][modules] Cache loads of modules imported by PCH

2021-10-12 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 added a comment.

I implemented the alternative approach, which now seems more straightforward 
than going through the `ModuleManager` and working with 
`serialization::ModuleFile`.
WDYT @dexonsmith?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111560

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


[PATCH] D102488: [clang][deps] Prune unused header search paths

2021-10-12 Thread Jan Svoboda via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG6a1f50b84ae8: [clang][deps] Prune unused header search paths 
(authored by jansvoboda11).

Changed prior to commit:
  https://reviews.llvm.org/D102488?vs=378285&id=378953#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102488

Files:
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/include/clang/Serialization/ModuleFile.h
  clang/include/clang/Tooling/DependencyScanning/DependencyScanningService.h
  clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
  clang/include/clang/Tooling/DependencyScanning/ModuleDepCollector.h
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/lib/Tooling/DependencyScanning/DependencyScanningService.cpp
  clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
  clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
  clang/test/ClangScanDeps/Inputs/header-search-pruning/a/a.h
  clang/test/ClangScanDeps/Inputs/header-search-pruning/b/b.h
  clang/test/ClangScanDeps/Inputs/header-search-pruning/begin/begin.h
  clang/test/ClangScanDeps/Inputs/header-search-pruning/cdb.json
  clang/test/ClangScanDeps/Inputs/header-search-pruning/end/end.h
  clang/test/ClangScanDeps/Inputs/header-search-pruning/mod.h
  clang/test/ClangScanDeps/Inputs/header-search-pruning/module.modulemap
  clang/test/ClangScanDeps/header-search-pruning.cpp
  clang/tools/clang-scan-deps/ClangScanDeps.cpp

Index: clang/tools/clang-scan-deps/ClangScanDeps.cpp
===
--- clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -170,6 +170,11 @@
"specified directory instead the module cache directory."),
 llvm::cl::cat(DependencyScannerCategory));
 
+static llvm::cl::opt OptimizeArgs(
+"optimize-args",
+llvm::cl::desc("Whether to optimize command-line arguments of modules."),
+llvm::cl::init(false), llvm::cl::cat(DependencyScannerCategory));
+
 llvm::cl::opt
 NumThreads("j", llvm::cl::Optional,
llvm::cl::desc("Number of worker threads to use (default: use "
@@ -507,7 +512,7 @@
   SharedStream DependencyOS(llvm::outs());
 
   DependencyScanningService Service(ScanMode, Format, ReuseFileManager,
-SkipExcludedPPRanges);
+SkipExcludedPPRanges, OptimizeArgs);
   llvm::ThreadPool Pool(llvm::hardware_concurrency(NumThreads));
   std::vector> WorkerTools;
   for (unsigned I = 0; I < Pool.getThreadCount(); ++I)
Index: clang/test/ClangScanDeps/header-search-pruning.cpp
===
--- /dev/null
+++ clang/test/ClangScanDeps/header-search-pruning.cpp
@@ -0,0 +1,85 @@
+// RUN: rm -rf %t && mkdir -p %t
+// RUN: cp -r %S/Inputs/header-search-pruning/* %t
+// RUN: cp %S/header-search-pruning.cpp %t/header-search-pruning.cpp
+// RUN: sed -e "s|DIR|%/t|g" -e "s|DEFINES|-DINCLUDE_A|g" %S/Inputs/header-search-pruning/cdb.json > %t/cdb_a.json
+// RUN: sed -e "s|DIR|%/t|g" -e "s|DEFINES|-DINCLUDE_B|g" %S/Inputs/header-search-pruning/cdb.json > %t/cdb_b.json
+// RUN: sed -e "s|DIR|%/t|g" -e "s|DEFINES|-DINCLUDE_A -DINCLUDE_B|g" %S/Inputs/header-search-pruning/cdb.json > %t/cdb_ab.json
+//
+// RUN: clang-scan-deps -compilation-database %t/cdb_a.json -format experimental-full -optimize-args >> %t/result_a.json
+// RUN: cat %t/result_a.json | sed 's/\\/\//g' | FileCheck --check-prefixes=CHECK_A %s
+//
+// RUN: clang-scan-deps -compilation-database %t/cdb_b.json -format experimental-full -optimize-args >> %t/result_b.json
+// RUN: cat %t/result_b.json | sed 's/\\/\//g' | FileCheck --check-prefixes=CHECK_B %s
+//
+// RUN: clang-scan-deps -compilation-database %t/cdb_ab.json -format experimental-full -optimize-args >> %t/result_ab.json
+// RUN: cat %t/result_ab.json | sed 's/\\/\//g' | FileCheck --check-prefixes=CHECK_AB %s
+
+#include "mod.h"
+
+// CHECK_A:{
+// CHECK_A-NEXT: "modules": [
+// CHECK_A-NEXT:   {
+// CHECK_A-NEXT: "clang-module-deps": [],
+// CHECK_A-NEXT: "clang-modulemap-file": "{{.*}}",
+// CHECK_A-NEXT: "command-line": [
+// CHECK_A-NEXT:   "-cc1"
+// CHECK_A:"-I",
+// CHECK_A-NEXT:   "begin",
+// CHECK_A-NEXT:   "-I",
+// CHECK_A-NEXT:   "a",
+// CHECK_A-NEXT:   "-I",
+// CHECK_A-NEXT:   "end"
+// CHECK_A:  ],
+// CHECK_A-NEXT: "context-hash": "{{.*}}",
+// CHECK_A-NEXT: "file-deps": [
+// CHECK_A:  ],
+// CHECK_A-NEXT: "name": "mod"
+// CHECK_A-NEXT:   }
+// CHECK_A-NEXT: ]
+// CHECK_A:}
+
+// CHECK_B:{
+// CHECK_B-NEXT: "modules": [
+// CHECK_B-NEXT:   {
+// CHECK_B-NEXT: "cla

[clang] 6a1f50b - [clang][deps] Prune unused header search paths

2021-10-12 Thread Jan Svoboda via cfe-commits

Author: Jan Svoboda
Date: 2021-10-12T12:39:23+02:00
New Revision: 6a1f50b84ae8f8a8087fcdbe5f27dae8c76878f1

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

LOG: [clang][deps] Prune unused header search paths

To reduce the number of explicit builds of a single module, we can try to 
squash multiple occurrences of the module with different command-lines (and 
context hashes) by removing benign command-line options. The greatest 
contributors to benign differences between command-lines are the header search 
paths.

In this patch, the lookup cache in `HeaderSearch` is used to identify paths 
that were actually used when implicitly building the module during scanning. 
This information is serialized into the unhashed control block of the 
implicitly-built PCM. The dependency scanner then loads this and may use it to 
prune the header search paths before computing the context hash of the module 
and generating the command-line.

We could also prune the header search paths when serializing 
`HeaderSearchOptions` into the PCM. That way, we could do it only once instead 
of every load of the PCM file by dependency scanner. However, that would result 
in a PCM file whose contents don't produce the same context hash as the 
original build, which is probably highly surprising.

There is an alternative approach to storing extra information into the PCM: 
wire up preprocessor callbacks to capture the used header search paths 
on-the-fly during preprocessing of modularized headers (similar to what we 
currently do for the main source file and textual headers). Right now, that's 
not compatible with the fact that we do an actual implicit build producing PCM 
files during dependency scanning. The second run of dependency scanner loads 
the PCM from the first run, skipping the preprocessing altogether, which would 
result in different results between runs. We can revisit this approach when we 
stop building implicitly during dependency scanning.

Depends on D102923.

Reviewed By: dexonsmith

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

Added: 
clang/test/ClangScanDeps/Inputs/header-search-pruning/a/a.h
clang/test/ClangScanDeps/Inputs/header-search-pruning/b/b.h
clang/test/ClangScanDeps/Inputs/header-search-pruning/begin/begin.h
clang/test/ClangScanDeps/Inputs/header-search-pruning/cdb.json
clang/test/ClangScanDeps/Inputs/header-search-pruning/end/end.h
clang/test/ClangScanDeps/Inputs/header-search-pruning/mod.h
clang/test/ClangScanDeps/Inputs/header-search-pruning/module.modulemap
clang/test/ClangScanDeps/header-search-pruning.cpp

Modified: 
clang/include/clang/Serialization/ASTBitCodes.h
clang/include/clang/Serialization/ModuleFile.h
clang/include/clang/Tooling/DependencyScanning/DependencyScanningService.h
clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
clang/include/clang/Tooling/DependencyScanning/ModuleDepCollector.h
clang/lib/Serialization/ASTReader.cpp
clang/lib/Serialization/ASTWriter.cpp
clang/lib/Tooling/DependencyScanning/DependencyScanningService.cpp
clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
clang/tools/clang-scan-deps/ClangScanDeps.cpp

Removed: 




diff  --git a/clang/include/clang/Serialization/ASTBitCodes.h 
b/clang/include/clang/Serialization/ASTBitCodes.h
index e771aa3d07aa5..68520cd9b3e36 100644
--- a/clang/include/clang/Serialization/ASTBitCodes.h
+++ b/clang/include/clang/Serialization/ASTBitCodes.h
@@ -402,6 +402,9 @@ enum UnhashedControlBlockRecordTypes {
 
   /// Record code for \#pragma diagnostic mappings.
   DIAG_PRAGMA_MAPPINGS,
+
+  /// Record code for the indices of used header search entries.
+  HEADER_SEARCH_ENTRY_USAGE,
 };
 
 /// Record code for extension blocks.

diff  --git a/clang/include/clang/Serialization/ModuleFile.h 
b/clang/include/clang/Serialization/ModuleFile.h
index b1c8a8c8e72b6..b275f8b8db5d3 100644
--- a/clang/include/clang/Serialization/ModuleFile.h
+++ b/clang/include/clang/Serialization/ModuleFile.h
@@ -20,6 +20,7 @@
 #include "clang/Serialization/ASTBitCodes.h"
 #include "clang/Serialization/ContinuousRangeMap.h"
 #include "clang/Serialization/ModuleFileExtension.h"
+#include "llvm/ADT/BitVector.h"
 #include "llvm/ADT/DenseMap.h"
 #include "llvm/ADT/PointerIntPair.h"
 #include "llvm/ADT/SetVector.h"
@@ -173,6 +174,9 @@ class ModuleFile {
   /// unique module files based on AST contents.
   ASTFileSignature ASTBlockHash;
 
+  /// The bit vector denoting usage of each header search entry (true = used).
+  llvm::BitVector SearchPathUsage;
+
   /// Whether this module has been directly imported by the
   /// user.
   bool DirectlyImported = false;

diff  

[PATCH] D111545: [Clang][NFC] Fix multiline comment prefixes in function headers

2021-10-12 Thread Saiyedul Islam via Phabricator via cfe-commits
saiislam updated this revision to Diff 378957.
saiislam added a comment.

Used comment style for named parameters.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111545

Files:
  clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
  clang/lib/Driver/ToolChains/Cuda.cpp


Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -744,8 +744,8 @@
 
 addOpenMPDeviceRTL(getDriver(), DriverArgs, CC1Args, BitcodeSuffix,
getTriple());
-AddStaticDeviceLibsPostLinking(getDriver(), DriverArgs, CC1Args, "nvptx", 
GpuArch,
-/* bitcode SDL?*/ true, /* PostClang Link? */ true);
+AddStaticDeviceLibsPostLinking(getDriver(), DriverArgs, CC1Args, "nvptx",
+GpuArch, /* bitcode SDL?*/true, /* PostClang Link? */true);
   }
 }
 
Index: clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
===
--- clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
+++ clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
@@ -115,9 +115,7 @@
   }
 
   AddStaticDeviceLibsLinking(C, *this, JA, Inputs, Args, CmdArgs, "amdgcn",
-  SubArchName,
-  /* bitcode SDL?*/ true,
-  /* PostClang Link? */ false);
+  SubArchName, /* bitcode SDL?*/true, /* PostClang Link? */false);
   // Add an intermediate output file.
   CmdArgs.push_back("-o");
   const char *OutputFileName =


Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -744,8 +744,8 @@
 
 addOpenMPDeviceRTL(getDriver(), DriverArgs, CC1Args, BitcodeSuffix,
getTriple());
-AddStaticDeviceLibsPostLinking(getDriver(), DriverArgs, CC1Args, "nvptx", GpuArch,
-/* bitcode SDL?*/ true, /* PostClang Link? */ true);
+AddStaticDeviceLibsPostLinking(getDriver(), DriverArgs, CC1Args, "nvptx",
+GpuArch, /* bitcode SDL?*/true, /* PostClang Link? */true);
   }
 }
 
Index: clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
===
--- clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
+++ clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
@@ -115,9 +115,7 @@
   }
 
   AddStaticDeviceLibsLinking(C, *this, JA, Inputs, Args, CmdArgs, "amdgcn",
-  SubArchName,
-  /* bitcode SDL?*/ true,
-  /* PostClang Link? */ false);
+  SubArchName, /* bitcode SDL?*/true, /* PostClang Link? */false);
   // Add an intermediate output file.
   CmdArgs.push_back("-o");
   const char *OutputFileName =
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D111208: [clang-tidy] Support globbing in NOLINT* expressions

2021-10-12 Thread Salman Javed via Phabricator via cfe-commits
salman-javed-nz added inline comments.



Comment at: clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp:349
+  // Allow specifying a few checks with a glob expression.
+  GlobList Globs(ChecksStr);
+  if (!Globs.contains(CheckName))

carlosgalvezp wrote:
> aaron.ballman wrote:
> > carlosgalvezp wrote:
> > > salman-javed-nz wrote:
> > > > What happens when `CheckStr` is empty?
> > > > How has Clang-Tidy treated `// NOLINT()` in the past? Does this patch 
> > > > change the behaviour? What //should // be the "right" behaviour?
> > > Very good question! Currently on master `// NOLINT()` will *not* suppress 
> > > warnings. However `// NOLINT(` will. My patch shouldn't change existing 
> > > behavior - an empty list of globs will return false when calling 
> > > `contains`.
> > > 
> > > I'll add a unit test to cover this case!
> > (All of this is a bit orthogonal to this patch, so no changes requested 
> > here.)
> > 
> > Naively, I would expect `NOLINT()` to be an error because it expects an 
> > argument and none was given. (I'd expect `NOLINT(` to also be an error 
> > because the syntax is malformed.)
> Fully agree! If I find some time I can give it a try on a separate patch
The NOLINT syntax was borrowed from Google's cpplint.py. cpplint uses a regex 
search to find NOLINT expressions, but it's pretty naive, leading to quirks 
like `NOLINT(` being accepted as a valid expression. Clang-Tidy has inherited 
the same quirks by being interoperable with cpplint's syntax.

How important it is to maintain compatibility with the more funky aspects of 
cpplint's `NOLINT` behaviour, I'm not sure. The two programs' syntaxes aren't 
fully compatible nowadays anyway. To give an example, cpplint doesn't support 
multiple checks separated by commas on the same line. This glob feature will be 
another divergence. 

Just something to think about for next time.


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

https://reviews.llvm.org/D111208

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


[PATCH] D111208: [clang-tidy] Support globbing in NOLINT* expressions

2021-10-12 Thread Salman Javed via Phabricator via cfe-commits
salman-javed-nz added inline comments.



Comment at: clang-tools-extra/docs/clang-tidy/index.rst:314
+are ignored here, as they would effectively re-activate the warning, causing
+confusion to the users.
 

There's something about this "causing confusion to the users" that my mind 
latches on to. I'm not sure what my problem with it is. Perhaps the sentence 
will read better if you just remove the 2nd half? 


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

https://reviews.llvm.org/D111208

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


[PATCH] D111570: [clang/CFG] Don't explicitly add AttributedStmtClass to AlwaysAddList

2021-10-12 Thread Hans Wennborg via Phabricator via cfe-commits
hans added a comment.

I guess I don't have enough context here. Why is AttributedStmtClass special 
here? Is it because it's a statement and the others are expressions, and so 
wouldn't go through CFGBlock::addStmt()?


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

https://reviews.llvm.org/D111570

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


[PATCH] D111542: [analyzer] Retrieve incomplete array extent from its redeclaration.

2021-10-12 Thread Denys Petrov via Phabricator via cfe-commits
ASDenysPetrov added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/RegionStore.cpp:1663
 // We can trust a const value or a value of a global initializer in main().
-const VarDecl *VD = VR->getDecl();
+const VarDecl *VD = VR->getDecl()->getMostRecentDecl();
 if (VD->getType().isConstQualified() ||

NoQ wrote:
> ASDenysPetrov wrote:
> > steakhal wrote:
> > > I think you supposed to use the `getCanonicalDecl()` instead.
> > Using `getCanonicalDecl` does not fix the issue. I've checked.
> Aha ok, can you try iterating over `redecls()`?
> 
> Separately, I suspect that this should be performed before the `VarRegion` is 
> constructed in the first place. Maybe in its constructor we should 
> `assert(VD->isThisDeclarationADefinition())` or something like that.
> Aha ok, can you try iterating over redecls()?
Do you assume that in a list `{redecl1, redecl2, redecl3}` **redecl2** may be 
our guy but **1** and **3** may not?
> Separately, I suspect that this should be performed before the VarRegion is 
> constructed in the first place. 
I'm not sure I got what you mean, but as I undestood that it is not be a part 
of this fix, right?



Comment at: clang/test/Analysis/initialization.c:102
+const int glob_arr3[];  // Incomplete array declaration
+const int glob_arr3[4] = {1, 2, 3}; // Incomplete Array redeclaration
+void foo() {

balazske wrote:
> It is possible to add a line `const int glob_arr3[];` again and then it may 
> not work?
Yes. I tryed. It works. Thanks! But I'll add a test case.


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

https://reviews.llvm.org/D111542

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


[PATCH] D111568: [clang] Omit most AttributedStatements from the CFG

2021-10-12 Thread Hans Wennborg via Phabricator via cfe-commits
hans added inline comments.



Comment at: clang/lib/Analysis/CFG.cpp:545
   CFGBlock *VisitAddrLabelExpr(AddrLabelExpr *A, AddStmtChoice asc);
+  CFGBlock *VisitAttributedStmt(AttributedStmt *C, AddStmtChoice asc);
   CFGBlock *VisitBinaryOperator(BinaryOperator *B, AddStmtChoice asc);

Change param name C -> A as in the function definition?



Comment at: clang/lib/Analysis/CFG.cpp:2407
+  return hasSpecificAttr(A->getAttrs()) &&
+ isa(A->getSubStmt());
+}

Can fallthrough statements ever have children? If not, should it be an assert 
instead of a check here?


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

https://reviews.llvm.org/D111568

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


[PATCH] D111623: [clang-tidy] Update documentation of check bugprone-unused-return-value [NFC].

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

LGTM, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111623

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


[PATCH] D111488: [Clang][clang-nvlink-wrapper] Pass nvlink path to the wrapper

2021-10-12 Thread Saiyedul Islam via Phabricator via cfe-commits
saiislam updated this revision to Diff 378978.
saiislam marked 5 inline comments as done.
saiislam added a comment.

Thanks, Michael and Artem!

1. Changed nvlink-command to nvlink-path.
2. Answered queries and done refactoring as suggested.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111488

Files:
  clang/lib/Driver/ToolChains/Cuda.cpp
  clang/tools/clang-nvlink-wrapper/ClangNvlinkWrapper.cpp

Index: clang/tools/clang-nvlink-wrapper/ClangNvlinkWrapper.cpp
===
--- clang/tools/clang-nvlink-wrapper/ClangNvlinkWrapper.cpp
+++ clang/tools/clang-nvlink-wrapper/ClangNvlinkWrapper.cpp
@@ -25,6 +25,7 @@
 /// 2. nvlink -o a.out-openmp-nvptx64 /tmp/a.cubin /tmp/b.cubin
 //===-===//
 
+#include "clang/Basic/Version.h"
 #include "llvm/Object/Archive.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/Errc.h"
@@ -41,6 +42,19 @@
 
 static cl::opt Help("h", cl::desc("Alias for -help"), cl::Hidden);
 
+// Mark all our options with this category, everything else (except for -help)
+// will be hidden.
+static cl::OptionCategory
+ClangNvlinkWrapperCategory("clang-nvlink-wrapper options");
+
+static cl::opt NvlinkUserPath("nvlink-path",
+   cl::desc("Path of nvlink binary"),
+   cl::cat(ClangNvlinkWrapperCategory));
+
+// Do not parse nvlink options
+static cl::list
+NVArgs(cl::Sink, cl::desc("..."));
+
 static Error runNVLink(std::string NVLinkPath,
SmallVectorImpl &Args) {
   std::vector NVLArgs;
@@ -119,8 +133,20 @@
   return Error::success();
 }
 
+static void PrintVersion(raw_ostream &OS) {
+  OS << clang::getClangToolFullVersion("clang-nvlink-wrapper") << '\n';
+}
+
 int main(int argc, const char **argv) {
   sys::PrintStackTraceOnErrorSignal(argv[0]);
+  cl::SetVersionPrinter(PrintVersion);
+  cl::HideUnrelatedOptions(ClangNvlinkWrapperCategory);
+  cl::ParseCommandLineOptions(
+  argc, argv,
+  "A wrapper tool over nvlink program. It transparently passes every \n"
+  "input option and objects to nvlink except archive files and path of \n"
+  "nvlink binary. It reads each input archive file to extract archived \n"
+  "cubin files as temporary files.\n");
 
   if (Help) {
 cl::PrintHelpMessage();
@@ -132,12 +158,7 @@
 exit(1);
   };
 
-  ErrorOr NvlinkPath = sys::findProgramByName("nvlink");
-  if (!NvlinkPath) {
-reportError(createStringError(NvlinkPath.getError(),
-  "unable to find 'nvlink' in path"));
-  }
-
+  std::string NvlinkPath;
   SmallVector Argv(argv, argv + argc);
   SmallVector ArgvSubst;
   SmallVector TmpFiles;
@@ -145,8 +166,7 @@
   StringSaver Saver(Alloc);
   cl::ExpandResponseFiles(Saver, cl::TokenizeGNUCommandLine, Argv);
 
-  for (size_t i = 1; i < Argv.size(); ++i) {
-std::string Arg = Argv[i];
+  for (const std::string &Arg : NVArgs) {
 if (sys::path::extension(Arg) == ".a") {
   if (Error Err = extractArchiveFiles(Arg, ArgvSubst, TmpFiles))
 reportError(std::move(Err));
@@ -155,7 +175,19 @@
 }
   }
 
-  if (Error Err = runNVLink(NvlinkPath.get(), ArgvSubst))
+  NvlinkPath = NvlinkUserPath;
+
+  // If user hasn't specified nvlink binary then search it in PATH
+  if (NvlinkPath.empty()) {
+ErrorOr NvlinkPathErr = sys::findProgramByName("nvlink");
+if (!NvlinkPathErr) {
+  reportError(createStringError(NvlinkPathErr.getError(),
+"unable to find 'nvlink' in path"));
+}
+NvlinkPath = NvlinkPathErr.get();
+  }
+
+  if (Error Err = runNVLink(NvlinkPath, ArgvSubst))
 reportError(std::move(Err));
   if (Error Err = cleanupTmpFiles(TmpFiles))
 reportError(std::move(Err));
Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -613,6 +613,10 @@
   AddStaticDeviceLibsLinking(C, *this, JA, Inputs, Args, CmdArgs, "nvptx", GPUArch,
   false, false);
 
+  // Find nvlink and pass it as "--nvlink-path=" argument of
+  // clang-nvlink-wrapper.
+  CmdArgs.push_back(Args.MakeArgString(Twine("--nvlink-path=" + getToolChain().GetProgramPath("nvlink";
+
   const char *Exec =
   Args.MakeArgString(getToolChain().GetProgramPath("clang-nvlink-wrapper"));
   C.addCommand(std::make_unique(
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D111488: [Clang][clang-nvlink-wrapper] Pass nvlink path to the wrapper

2021-10-12 Thread Saiyedul Islam via Phabricator via cfe-commits
saiislam updated this revision to Diff 378979.
saiislam added a comment.

clang-format(ed).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111488

Files:
  clang/lib/Driver/ToolChains/Cuda.cpp
  clang/tools/clang-nvlink-wrapper/ClangNvlinkWrapper.cpp

Index: clang/tools/clang-nvlink-wrapper/ClangNvlinkWrapper.cpp
===
--- clang/tools/clang-nvlink-wrapper/ClangNvlinkWrapper.cpp
+++ clang/tools/clang-nvlink-wrapper/ClangNvlinkWrapper.cpp
@@ -25,6 +25,7 @@
 /// 2. nvlink -o a.out-openmp-nvptx64 /tmp/a.cubin /tmp/b.cubin
 //===-===//
 
+#include "clang/Basic/Version.h"
 #include "llvm/Object/Archive.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/Errc.h"
@@ -41,6 +42,19 @@
 
 static cl::opt Help("h", cl::desc("Alias for -help"), cl::Hidden);
 
+// Mark all our options with this category, everything else (except for -help)
+// will be hidden.
+static cl::OptionCategory
+ClangNvlinkWrapperCategory("clang-nvlink-wrapper options");
+
+static cl::opt NvlinkUserPath("nvlink-path",
+   cl::desc("Path of nvlink binary"),
+   cl::cat(ClangNvlinkWrapperCategory));
+
+// Do not parse nvlink options
+static cl::list
+NVArgs(cl::Sink, cl::desc("..."));
+
 static Error runNVLink(std::string NVLinkPath,
SmallVectorImpl &Args) {
   std::vector NVLArgs;
@@ -119,8 +133,20 @@
   return Error::success();
 }
 
+static void PrintVersion(raw_ostream &OS) {
+  OS << clang::getClangToolFullVersion("clang-nvlink-wrapper") << '\n';
+}
+
 int main(int argc, const char **argv) {
   sys::PrintStackTraceOnErrorSignal(argv[0]);
+  cl::SetVersionPrinter(PrintVersion);
+  cl::HideUnrelatedOptions(ClangNvlinkWrapperCategory);
+  cl::ParseCommandLineOptions(
+  argc, argv,
+  "A wrapper tool over nvlink program. It transparently passes every \n"
+  "input option and objects to nvlink except archive files and path of \n"
+  "nvlink binary. It reads each input archive file to extract archived \n"
+  "cubin files as temporary files.\n");
 
   if (Help) {
 cl::PrintHelpMessage();
@@ -132,12 +158,7 @@
 exit(1);
   };
 
-  ErrorOr NvlinkPath = sys::findProgramByName("nvlink");
-  if (!NvlinkPath) {
-reportError(createStringError(NvlinkPath.getError(),
-  "unable to find 'nvlink' in path"));
-  }
-
+  std::string NvlinkPath;
   SmallVector Argv(argv, argv + argc);
   SmallVector ArgvSubst;
   SmallVector TmpFiles;
@@ -145,8 +166,7 @@
   StringSaver Saver(Alloc);
   cl::ExpandResponseFiles(Saver, cl::TokenizeGNUCommandLine, Argv);
 
-  for (size_t i = 1; i < Argv.size(); ++i) {
-std::string Arg = Argv[i];
+  for (const std::string &Arg : NVArgs) {
 if (sys::path::extension(Arg) == ".a") {
   if (Error Err = extractArchiveFiles(Arg, ArgvSubst, TmpFiles))
 reportError(std::move(Err));
@@ -155,7 +175,19 @@
 }
   }
 
-  if (Error Err = runNVLink(NvlinkPath.get(), ArgvSubst))
+  NvlinkPath = NvlinkUserPath;
+
+  // If user hasn't specified nvlink binary then search it in PATH
+  if (NvlinkPath.empty()) {
+ErrorOr NvlinkPathErr = sys::findProgramByName("nvlink");
+if (!NvlinkPathErr) {
+  reportError(createStringError(NvlinkPathErr.getError(),
+"unable to find 'nvlink' in path"));
+}
+NvlinkPath = NvlinkPathErr.get();
+  }
+
+  if (Error Err = runNVLink(NvlinkPath, ArgvSubst))
 reportError(std::move(Err));
   if (Error Err = cleanupTmpFiles(TmpFiles))
 reportError(std::move(Err));
Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -613,6 +613,11 @@
   AddStaticDeviceLibsLinking(C, *this, JA, Inputs, Args, CmdArgs, "nvptx", GPUArch,
   false, false);
 
+  // Find nvlink and pass it as "--nvlink-path=" argument of
+  // clang-nvlink-wrapper.
+  CmdArgs.push_back(Args.MakeArgString(
+  Twine("--nvlink-path=" + getToolChain().GetProgramPath("nvlink";
+
   const char *Exec =
   Args.MakeArgString(getToolChain().GetProgramPath("clang-nvlink-wrapper"));
   C.addCommand(std::make_unique(
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D111543: [clang][modules] Stop creating `IdentifierInfo` for names of explicit modules

2021-10-12 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 updated this revision to Diff 378980.
jansvoboda11 added a comment.

Leave existing cache, create new cache indexed by module names.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111543

Files:
  clang/include/clang/Lex/ModuleMap.h
  clang/lib/Frontend/CompilerInstance.cpp
  clang/test/Modules/Inputs/module-name-used-by-objc-bridge/Interface.h
  clang/test/Modules/Inputs/module-name-used-by-objc-bridge/InterfaceBridge.h
  clang/test/Modules/Inputs/module-name-used-by-objc-bridge/module.modulemap
  clang/test/Modules/module-name-used-by-objc-bridge.m

Index: clang/test/Modules/module-name-used-by-objc-bridge.m
===
--- /dev/null
+++ clang/test/Modules/module-name-used-by-objc-bridge.m
@@ -0,0 +1,25 @@
+// RUN: rm -rf %t && mkdir %t
+
+// RUN: %clang_cc1 -fmodules -x objective-c -emit-module -fmodule-name=InterfaceBridge \
+// RUN:   %S/Inputs/module-name-used-by-objc-bridge/module.modulemap -o %t/InterfaceBridge.pcm
+
+// RUN: %clang_cc1 -fmodules -x objective-c -emit-module -fmodule-name=Interface \
+// RUN:   %S/Inputs/module-name-used-by-objc-bridge/module.modulemap -o %t/Interface.pcm
+
+// Check that the `-fmodule-file==` form succeeds:
+// RUN: %clang_cc1 -fmodules -fsyntax-only %s -I %S/Inputs/module-name-used-by-objc-bridge \
+// RUN:   -fmodule-file=InterfaceBridge=%t/InterfaceBridge.pcm -fmodule-file=Interface=%t/Interface.pcm \
+// RUN:   -fmodule-map-file=%S/Inputs/module-name-used-by-objc-bridge/module.modulemap -verify
+
+// Check that the `-fmodule-file=` form succeeds:
+// RUN: %clang_cc1 -fmodules -fsyntax-only %s -I %S/Inputs/module-name-used-by-objc-bridge \
+// RUN:   -fmodule-file=%t/InterfaceBridge.pcm -fmodule-file=%t/Interface.pcm \
+// RUN:   -fmodule-map-file=%S/Inputs/module-name-used-by-objc-bridge/module.modulemap -verify
+
+#import "InterfaceBridge.h"
+#import "Interface.h"
+
+@interface Interface (User)
+@end
+
+// expected-no-diagnostics
Index: clang/test/Modules/Inputs/module-name-used-by-objc-bridge/module.modulemap
===
--- /dev/null
+++ clang/test/Modules/Inputs/module-name-used-by-objc-bridge/module.modulemap
@@ -0,0 +1,7 @@
+module InterfaceBridge {
+  header "InterfaceBridge.h"
+}
+
+module Interface {
+  header "Interface.h"
+}
Index: clang/test/Modules/Inputs/module-name-used-by-objc-bridge/InterfaceBridge.h
===
--- /dev/null
+++ clang/test/Modules/Inputs/module-name-used-by-objc-bridge/InterfaceBridge.h
@@ -0,0 +1 @@
+typedef struct __attribute__((objc_bridge(Interface))) Foo *Bar;
Index: clang/test/Modules/Inputs/module-name-used-by-objc-bridge/Interface.h
===
--- /dev/null
+++ clang/test/Modules/Inputs/module-name-used-by-objc-bridge/Interface.h
@@ -0,0 +1,2 @@
+@interface Interface
+@end
Index: clang/lib/Frontend/CompilerInstance.cpp
===
--- clang/lib/Frontend/CompilerInstance.cpp
+++ clang/lib/Frontend/CompilerInstance.cpp
@@ -1639,28 +1639,27 @@
   // the files we were handed.
   struct ReadModuleNames : ASTReaderListener {
 CompilerInstance &CI;
-llvm::SmallVector LoadedModules;
+llvm::SmallVector LoadedModules;
 
 ReadModuleNames(CompilerInstance &CI) : CI(CI) {}
 
 void ReadModuleName(StringRef ModuleName) override {
-  LoadedModules.push_back(
-  CI.getPreprocessor().getIdentifierInfo(ModuleName));
+  LoadedModules.push_back(ModuleName);
 }
 
 void registerAll() {
   ModuleMap &MM = CI.getPreprocessor().getHeaderSearchInfo().getModuleMap();
-  for (auto *II : LoadedModules)
-MM.cacheModuleLoad(*II, MM.findModule(II->getName()));
+  for (StringRef LoadedModule : LoadedModules)
+MM.cacheTopLevelModuleLoad(LoadedModule, MM.findModule(LoadedModule));
   LoadedModules.clear();
 }
 
 void markAllUnavailable() {
-  for (auto *II : LoadedModules) {
+  for (StringRef LoadedModule : LoadedModules) {
 if (Module *M = CI.getPreprocessor()
 .getHeaderSearchInfo()
 .getModuleMap()
-.findModule(II->getName())) {
+.findModule(LoadedModule)) {
   M->HasIncompatibleModuleFile = true;
 
   // Mark module as available if the only reason it was unavailable
Index: clang/include/clang/Lex/ModuleMap.h
===
--- clang/include/clang/Lex/ModuleMap.h
+++ clang/include/clang/Lex/ModuleMap.h
@@ -101,6 +101,10 @@
   /// The top-level modules that are known.
   llvm::StringMap Modules;
 
+  /// Top-module loading cache, indexed by module names.
+  /// nullptr is stored for modules that are kno

[PATCH] D111570: [clang/CFG] Don't explicitly add AttributedStmtClass to AlwaysAddList

2021-10-12 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

Yes, that's my understanding. (I'm not super familiar with this code either.)

The line was added in the change that added -Wimplicit-fallthrough 
(84837d5b5aa0d), and all the -Wimplicit-fallthrough tests still pass with this. 
Chances are it was unnecessary back then too.

(`addStmt` is from ea9fcffe035d, way older.)


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

https://reviews.llvm.org/D111570

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


[PATCH] D111625: [clang-tidy] bugprone-argument-comment: SourceLocation valid judgment avoid emitting coredump in isInSystemHeader

2021-10-12 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

Can you add a test case that shows we've fixed the issue? (Note, you cannot 
include iostream directly in a test because that will use the platform STL and 
we want our tests to have consistent behavior regardless of platform.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111625

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


[PATCH] D111570: [clang/CFG] Don't explicitly add AttributedStmtClass to AlwaysAddList

2021-10-12 Thread Hans Wennborg via Phabricator via cfe-commits
hans accepted this revision.
hans added a comment.
This revision is now accepted and ready to land.

Sounds good to me :)


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

https://reviews.llvm.org/D111570

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


[PATCH] D111568: [clang] Omit most AttributedStatements from the CFG

2021-10-12 Thread Nico Weber via Phabricator via cfe-commits
thakis marked an inline comment as done.
thakis added inline comments.



Comment at: clang/lib/Analysis/CFG.cpp:2407
+  return hasSpecificAttr(A->getAttrs()) &&
+ isa(A->getSubStmt());
+}

hans wrote:
> Can fallthrough statements ever have children? If not, should it be an assert 
> instead of a check here?
Good question. Attr.td says:

```
  // The attribute only applies to a NullStmt, but we have special fix-it
  // behavior if applied to a case label.
  let Subjects = SubjectList<[NullStmt, SwitchCase], ErrorDiag,
 "empty statements">;
```

Which I suppose triggers for this:

```
  switch (argc) {
[[fallthrough]] case 4:
  break;
  }
```

```
foo.cc:6:7: error: 'fallthrough' attribute is only allowed on empty statements
[[fallthrough]] case 4:
  ^ 
foo.cc:6:20: note: did you forget ';'?
[[fallthrough]] case 4:
```

But that doesn't seem to make it into the AST, according to -dump-ast. So I 
suppose it could be an assert as well. Want me to change this?




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

https://reviews.llvm.org/D111568

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


[PATCH] D111529: Specify Clang vector builtins.

2021-10-12 Thread Florian Hahn via Phabricator via cfe-commits
fhahn updated this revision to Diff 378992.
fhahn added a comment.

Try to be more precise about how the reduction steps are performed and replace 
_round and _rint by roundeven.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111529

Files:
  clang/docs/LanguageExtensions.rst


Index: clang/docs/LanguageExtensions.rst
===
--- clang/docs/LanguageExtensions.rst
+++ clang/docs/LanguageExtensions.rst
@@ -506,6 +506,71 @@
   If it's an extension (OpenCL) vector, it's only available in C and OpenCL C.
   And it selects base on signedness of the condition operands (OpenCL v1.1 
s6.3.9).
 
+Vector Builtins
+---
+
+In addition to the operators mentioned above, Clang provides a set of builtins
+to perform additional operations on certain scalar and vector types.
+
+Let ``T`` be one of the following types:
+
+* an integer type (as in C2x 6.2.5p19), but excluding enumerated types and 
_Bool
+* the standard floating types float or double
+* a half-precision floating point type, if one is supported on the target
+* a vector type.
+
+For scalar types, consider the operation applied to a vector with a single 
element.
+
+*Elementwise Builtins*
+
+Each builtin returns a vector equivalent to applying the specified operation
+elementwise to the input.
+
+Unless specified otherwise operation(±0) = ±0 and operation(±infinity) = 
±infinity
+
+= 
 
==
+ Name  Operation   
 Supported element types
+= 
 
==
+ T __builtin_elementwise_abs(T x)  return the absolute value of a 
number x   integer and floating point types
+ T __builtin_elementwise_ceil(T x) return the smallest integral value 
greater than or equal to x floating point types
+ T __builtin_elementwise_floor(T x)return the largest integral value 
less than or equal to x floating point types
+ T __builtin_elementwise_roundeven(T x)round x to the nearest integer 
value in floating point format,floating point types
+   rounding halfway cases to even 
(that is, to the nearest value
+   that is an even integer), 
regardless of the current rounding
+   direction.
+ T__builtin_elementwise_trunc(T x) return the integral value nearest 
to but no larger in floating point types
+   magnitude than x
+ T __builtin_elementwise_max(T x, T y) return x or y, whichever is larger  
  integer and floating point types
+ T __builtin_elementwise_min(T x, T y) return x or y, whichever is smaller 
  integer and floating point types
+= 
 
==
+
+
+*Reduction Builtins*
+
+Each builtin returns a scalar equivalent to applying the specified
+operation(x, y) as pairwise tree reduction to the input. In each reduction 
step,
+the vector elements of the first vector are concatenated after the elements of
+the second vector. The result vector is created by reading pairs of adjacent
+elements from the concatenated vector, applying the operation to the pair and
+placing the result in the result vector.
+
+Let ``VT`` be a vector type and ``ET`` the element type of ``VT``.
+
+=== 
 
==
+ NameOperation 
   Supported element types
+=== 
 
==
+ ET __builtin_reduce_max(VT a)   return x or y, whichever is larger; 
If exactly one argument is   integer and floating point types
+ a NaN, return the other argument. If 
both arguments are NaNs,
+ fmax() return a NaN.
+ ET __builtin_reduce_min(VT a)   return x or y, whichever is smaller; 
If exactly one argument integer and floating point types
+ is a NaN, return the other argument. 
If both arguments are
+ NaNs, fmax() return a NaN.
+ ET __builtin_reduce_add(VT a)   \+   

[PATCH] D110913: [analyzer][solver] Handle simplification to ConcreteInt

2021-10-12 Thread Gabor Marton via Phabricator via cfe-commits
martong marked 2 inline comments as done.
martong added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:2104
+  const llvm::APSInt &SV = CI->getValue();
+  const RangeSet *ClassConstraint = getConstraint(State, Class);
+  // We have found a contradiction.

ASDenysPetrov wrote:
> We usually use `R` or `RS`. It gets readability better IMO.
There are many other cases in this file where we spell out ClassConstraint, 
e.g. in `mergeImpl` we have `NewClassConstraint`. Also, I think the name 
`ClassConstraint` is telling way more than `RS`, so I'd like to keep this name.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:2107-2109
+return nullptr;
+} else {
+  SimplifiedMemberSym = SimplifiedMemberVal.getAsSymbol();

ASDenysPetrov wrote:
> What prevents you to not put this stuff inside `ento::simplify`. I think it 
> should perfectly fit in there.
`ento::simplify` is at a different abstraction level, it works on a `SymbolRef` 
and the `SVal` associated to it; and it uses the `SValBuilder` to achieve the 
desired constant folding. We have absolutely no knowledge about the equivalence 
classes there.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110913

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


[PATCH] D110913: [analyzer][solver] Handle simplification to ConcreteInt

2021-10-12 Thread Gabor Marton via Phabricator via cfe-commits
martong updated this revision to Diff 378994.
martong marked an inline comment as done.
martong added a comment.

- Make the test case way simpler (and independent from other solver patches)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110913

Files:
  
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  clang/lib/StaticAnalyzer/Core/RangedConstraintManager.cpp
  clang/test/Analysis/solver-sym-simplification-concreteint.c


Index: clang/test/Analysis/solver-sym-simplification-concreteint.c
===
--- /dev/null
+++ clang/test/Analysis/solver-sym-simplification-concreteint.c
@@ -0,0 +1,22 @@
+// RUN: %clang_analyze_cc1 %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=debug.ExprInspection \
+// RUN:   -analyzer-config eagerly-assume=false \
+// RUN:   -verify
+
+void clang_analyzer_warnIfReached();
+void clang_analyzer_eval();
+
+void test_simplification_to_concrete_int(int b, int c) {
+  if (c + b != 0) // c + b == 0
+return;
+  if (b != 1) // b == 1  --> c + 1 == 0
+return;
+  if (c != 1) // c == 1  --> 1 + 1 == 0 contradiction
+return;
+  clang_analyzer_warnIfReached(); // expected-no-diagnostics
+
+  // Keep the symbols and the constraints! alive.
+  (void)(b * c);
+  return;
+}
Index: clang/lib/StaticAnalyzer/Core/RangedConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangedConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangedConstraintManager.cpp
@@ -226,9 +226,13 @@
   }
 }
 
-SymbolRef simplify(ProgramStateRef State, SymbolRef Sym) {
+SVal simplifyToSVal(ProgramStateRef State, SymbolRef Sym) {
   SValBuilder &SVB = State->getStateManager().getSValBuilder();
-  SVal SimplifiedVal = SVB.simplifySVal(State, SVB.makeSymbolVal(Sym));
+  return SVB.simplifySVal(State, SVB.makeSymbolVal(Sym));
+}
+
+SymbolRef simplify(ProgramStateRef State, SymbolRef Sym) {
+  SVal SimplifiedVal = simplifyToSVal(State, Sym);
   if (SymbolRef SimplifiedSym = SimplifiedVal.getAsSymbol())
 return SimplifiedSym;
   return Sym;
Index: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -2106,7 +2106,19 @@
ProgramStateRef State, EquivalenceClass Class) {
   SymbolSet ClassMembers = Class.getClassMembers(State);
   for (const SymbolRef &MemberSym : ClassMembers) {
-SymbolRef SimplifiedMemberSym = ento::simplify(State, MemberSym);
+
+SymbolRef SimplifiedMemberSym = nullptr;
+SVal SimplifiedMemberVal = simplifyToSVal(State, MemberSym);
+if (const auto CI = SimplifiedMemberVal.getAs()) {
+  const llvm::APSInt &SV = CI->getValue();
+  const RangeSet *ClassConstraint = getConstraint(State, Class);
+  // We have found a contradiction.
+  if (ClassConstraint && !ClassConstraint->contains(SV))
+return nullptr;
+} else {
+  SimplifiedMemberSym = SimplifiedMemberVal.getAsSymbol();
+}
+
 if (SimplifiedMemberSym && MemberSym != SimplifiedMemberSym) {
   // The simplified symbol should be the member of the original Class,
   // however, it might be in another existing class at the moment. We
Index: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h
===
--- 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h
+++ 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h
@@ -389,11 +389,19 @@
   static void computeAdjustment(SymbolRef &Sym, llvm::APSInt &Adjustment);
 };
 
-/// Try to simplify a given symbolic expression's associated value based on the
-/// constraints in State. This is needed because the Environment bindings are
-/// not getting updated when a new constraint is added to the State.
+/// Try to simplify a given symbolic expression based on the constraints in
+/// State. This is needed because the Environment bindings are not getting
+/// updated when a new constraint is added to the State. If the symbol is
+/// simplified to a non-symbol (e.g. to a constant) then the original symbol
+/// is returned.
 SymbolRef simplify(ProgramStateRef State, SymbolRef Sym);
 
+/// Try to simplify a given symbolic expression's associated `SVal` based on 
the
+/// constraints in State. This is very similar to `simplify`, but this function
+/// always returns the simplified SVal. The simplified SVal might be a single
+/// constant (i.e. `ConcreteInt`).
+SVal simplifyToSVal(ProgramStateRef State, SymbolRef Sym);
+
 } // namespace ento
 } // namespace 

[PATCH] D111568: [clang] Omit most AttributedStatements from the CFG

2021-10-12 Thread Hans Wennborg via Phabricator via cfe-commits
hans accepted this revision.
hans added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/lib/Analysis/CFG.cpp:2407
+  return hasSpecificAttr(A->getAttrs()) &&
+ isa(A->getSubStmt());
+}

thakis wrote:
> hans wrote:
> > Can fallthrough statements ever have children? If not, should it be an 
> > assert instead of a check here?
> Good question. Attr.td says:
> 
> ```
>   // The attribute only applies to a NullStmt, but we have special fix-it
>   // behavior if applied to a case label.
>   let Subjects = SubjectList<[NullStmt, SwitchCase], ErrorDiag,
>  "empty statements">;
> ```
> 
> Which I suppose triggers for this:
> 
> ```
>   switch (argc) {
> [[fallthrough]] case 4:
>   break;
>   }
> ```
> 
> ```
> foo.cc:6:7: error: 'fallthrough' attribute is only allowed on empty statements
> [[fallthrough]] case 4:
>   ^ 
> foo.cc:6:20: note: did you forget ';'?
> [[fallthrough]] case 4:
> ```
> 
> But that doesn't seem to make it into the AST, according to -dump-ast. So I 
> suppose it could be an assert as well. Want me to change this?
> 
> 
Yes, I think an assert would make sense, otherwise the reader has to think 
about what would the code be doing for an AttributedStmt with non-null substmt.


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

https://reviews.llvm.org/D111568

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


[PATCH] D110913: [analyzer][solver] Handle simplification to ConcreteInt

2021-10-12 Thread Gabor Marton via Phabricator via cfe-commits
martong added inline comments.



Comment at: clang/test/Analysis/solver-sym-simplification-concreteint.c:22
+  // c == 0 --> 0 + 1 == 0 contradiction
+  clang_analyzer_eval(c == 0);// expected-warning{{FALSE}}
+

martong wrote:
> steakhal wrote:
> > Could we have an `eval(c == -1) // TRUE`?
> > Also, please disable eager bifurcation to prevent state-splits in the eval 
> > arguments.
> Actually,  it is `eval(c == -1) // FALSE` that holds. 
> 
> This is because after the simplification with `b==1` we have a constraint 
> `c+1==0` but we do not reorder this equality to `c==-1`. Besides we have 
> another constraint that we inherited from a previous State, this is `c: [0, 
> 1]`. Now, when you query `c==-1` then the latter constraint is found, thus 
> resulting in an infeasible state, so you'll receive `FALSE` in the warning. 
> Actually, these are the constraints after line 19:
> ```
>   "constraints": [
> { "symbol": "(reg_$1) + (reg_$0)", "range": "{ [0, 0] }" },
> { "symbol": "(reg_$1) + 1", "range": "{ [0, 0] }" },
> { "symbol": "reg_$0", "range": "{ [1, 1] }" },
> { "symbol": "reg_$1", "range": "{ [0, 1] }" }
>   ],
> ```
> 
> I am considering to create a follow-up patch, where the reordering of 
> `c+1==0` to `c==-1` is done (perhaps by reusing 
> `RangedConstraintManager::assumeSymRel`).
I've just updated the test case to be way more direct and simple.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110913

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


[PATCH] D111568: [clang] Omit most AttributedStatements from the CFG

2021-10-12 Thread Nico Weber via Phabricator via cfe-commits
thakis updated this revision to Diff 378996.
thakis added a comment.

rename param; assert isa


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

https://reviews.llvm.org/D111568

Files:
  clang/lib/Analysis/CFG.cpp
  clang/test/SemaCXX/switch-implicit-fallthrough.cpp
  clang/test/SemaCXX/unreachable-code.cpp

Index: clang/test/SemaCXX/unreachable-code.cpp
===
--- clang/test/SemaCXX/unreachable-code.cpp
+++ clang/test/SemaCXX/unreachable-code.cpp
@@ -77,3 +77,25 @@
 return;
   bar(); // no-warning
 }
+
+namespace pr52103 {
+
+void g(int a);
+
+void f(int a) {
+  if (a > 4) [[ likely ]] { // no-warning
+return;
+  }
+
+  if (a > 4) [[ unlikely ]] { // no-warning
+return;
+
+return; // expected-warning {{will never be executed}}
+  }
+
+  [[clang::musttail]] return g(a); // no-warning
+
+  [[clang::musttail]] return g(a); // expected-warning {{will never be executed}}
+}
+
+}
Index: clang/test/SemaCXX/switch-implicit-fallthrough.cpp
===
--- clang/test/SemaCXX/switch-implicit-fallthrough.cpp
+++ clang/test/SemaCXX/switch-implicit-fallthrough.cpp
@@ -50,6 +50,8 @@
   break;
   }
   switch (n / 20) {
+[[likely]] case 6:
+  [[clang::fallthrough]];
 case 7:
   n += 400;
   [[clang::fallthrough]];
@@ -73,6 +75,8 @@
   n += 800;
   }
   switch (n / 30) {
+case 6:
+  [[unlikely, clang::fallthrough]];
 case 11:
 case 12:  // no warning here, intended fall-through, no statement between labels
   n += 1600;
Index: clang/lib/Analysis/CFG.cpp
===
--- clang/lib/Analysis/CFG.cpp
+++ clang/lib/Analysis/CFG.cpp
@@ -542,6 +542,7 @@
   // Visitors to walk an AST and construct the CFG.
   CFGBlock *VisitInitListExpr(InitListExpr *ILE, AddStmtChoice asc);
   CFGBlock *VisitAddrLabelExpr(AddrLabelExpr *A, AddStmtChoice asc);
+  CFGBlock *VisitAttributedStmt(AttributedStmt *A, AddStmtChoice asc);
   CFGBlock *VisitBinaryOperator(BinaryOperator *B, AddStmtChoice asc);
   CFGBlock *VisitBreakStmt(BreakStmt *B);
   CFGBlock *VisitCallExpr(CallExpr *C, AddStmtChoice asc);
@@ -2149,6 +2150,9 @@
 case Stmt::InitListExprClass:
   return VisitInitListExpr(cast(S), asc);
 
+case Stmt::AttributedStmtClass:
+  return VisitAttributedStmt(cast(S), asc);
+
 case Stmt::AddrLabelExprClass:
   return VisitAddrLabelExpr(cast(S), asc);
 
@@ -2398,8 +2402,32 @@
   return Block;
 }
 
-CFGBlock *CFGBuilder::VisitUnaryOperator(UnaryOperator *U,
-   AddStmtChoice asc) {
+static bool isFallthroughStatement(const AttributedStmt *A) {
+  bool isFallthrough = hasSpecificAttr(A->getAttrs());
+  assert((!isFallthrough || isa(A->getSubStmt())) &&
+ "expected fallthrough not to have children");
+  return isFallthrough;
+}
+
+CFGBlock *CFGBuilder::VisitAttributedStmt(AttributedStmt *A,
+  AddStmtChoice asc) {
+  // AttributedStmts for [[likely]] can have arbitrary statements as children,
+  // and the current visitation order here would add the AttributedStmts
+  // for [[likely]] after the child nodes, which is undesirable: For example,
+  // if the child contains an unconditional return, the [[likely]] would be
+  // considered unreachable.
+  // So only add the AttributedStmt for FallThrough, which has CFG effects and
+  // also no children, and omit the others. None of the other current StmtAttrs
+  // have semantic meaning for the CFG.
+  if (isFallthroughStatement(A) && asc.alwaysAdd(*this, A)) {
+autoCreateBlock();
+appendStmt(Block, A);
+  }
+
+  return VisitChildren(A);
+}
+
+CFGBlock *CFGBuilder::VisitUnaryOperator(UnaryOperator *U, AddStmtChoice asc) {
   if (asc.alwaysAdd(*this, U)) {
 autoCreateBlock();
 appendStmt(Block, U);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D111529: Specify Clang vector builtins.

2021-10-12 Thread Florian Hahn via Phabricator via cfe-commits
fhahn marked 4 inline comments as done.
fhahn added inline comments.



Comment at: clang/docs/LanguageExtensions.rst:538
+ T __builtin_elementwise_rint(T x)  return the integral value nearest to x 
(according to the  floating point types
+prevailing rounding mode) in 
floating-point format
+ T __builtin_elementwise_round(T x) return the integral value nearest to x 
rounding half-way casesfloating point types

scanon wrote:
> "Prevailing rounding mode" is not super-useful, other than as a spelling for 
> round-to-nearest-ties-to-even (IEEE 754 default rounding). Outside of a 
> `FENV_ACCESS ON` context, there's not even really a notion of "prevailing 
> rounding mode" to appeal to. I assume the intent is for this to lower to e.g. 
> x86 ROUND* with the dynamic rounding-mode immediate.
> 
> I would recommend adding `__builtin_elementwise_roundeven(T x)` instead, 
> which would statically bind IEEE default rounding (following TS 18661-1 
> naming) without having to appeal to prevailing rounding mode, and can still 
> lower to ROUND* on x86 outside of FENV_ACCESS ON contexts, which is the norm 
> for vector code  (and FRINTN unconditionally on armv8). I think we can punt 
> on rint/nearbyint for now, and add them in the future if there's a need.
I removed `rint` and `round` for now and add` _roundeven` with the wording from 
TS 18661-1



Comment at: clang/docs/LanguageExtensions.rst:552
+operation(x, y) as pairwise tree reduction to the input. The pairs are formed
+by concatenating both inputs and pairing adjacent elements.
+

craig.topper wrote:
> I'm not sure I understand what is being concatenated here.
I tried to spell it out more clearly. I'm still not sure if that spells it out 
as clearly as possibly and I'd appreciate any suggestions on how to improve the 
wording.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111529

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


[clang] c74ab84 - [clang] Omit most AttributedStatements from the CFG

2021-10-12 Thread Nico Weber via cfe-commits

Author: Nico Weber
Date: 2021-10-12T09:15:45-04:00
New Revision: c74ab84ea23f497ac83501473220cd9cfefe81e8

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

LOG: [clang] Omit most AttributedStatements from the CFG

`[[clang::fallthrough]]` has meaning for the CFG, but all other
StmtAttrs we currently have don't. So omit them, as AttributedStatements
with children cause several issues and there's no benefit in including
them.

Fixes PR52103 and PR49454. See PR52103 for details.

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

Added: 


Modified: 
clang/lib/Analysis/CFG.cpp
clang/test/SemaCXX/switch-implicit-fallthrough.cpp
clang/test/SemaCXX/unreachable-code.cpp

Removed: 




diff  --git a/clang/lib/Analysis/CFG.cpp b/clang/lib/Analysis/CFG.cpp
index 50adc8c75bb5a..69b745c8b4518 100644
--- a/clang/lib/Analysis/CFG.cpp
+++ b/clang/lib/Analysis/CFG.cpp
@@ -542,6 +542,7 @@ class CFGBuilder {
   // Visitors to walk an AST and construct the CFG.
   CFGBlock *VisitInitListExpr(InitListExpr *ILE, AddStmtChoice asc);
   CFGBlock *VisitAddrLabelExpr(AddrLabelExpr *A, AddStmtChoice asc);
+  CFGBlock *VisitAttributedStmt(AttributedStmt *A, AddStmtChoice asc);
   CFGBlock *VisitBinaryOperator(BinaryOperator *B, AddStmtChoice asc);
   CFGBlock *VisitBreakStmt(BreakStmt *B);
   CFGBlock *VisitCallExpr(CallExpr *C, AddStmtChoice asc);
@@ -2149,6 +2150,9 @@ CFGBlock *CFGBuilder::Visit(Stmt * S, AddStmtChoice asc,
 case Stmt::InitListExprClass:
   return VisitInitListExpr(cast(S), asc);
 
+case Stmt::AttributedStmtClass:
+  return VisitAttributedStmt(cast(S), asc);
+
 case Stmt::AddrLabelExprClass:
   return VisitAddrLabelExpr(cast(S), asc);
 
@@ -2398,8 +2402,32 @@ CFGBlock *CFGBuilder::VisitAddrLabelExpr(AddrLabelExpr 
*A,
   return Block;
 }
 
-CFGBlock *CFGBuilder::VisitUnaryOperator(UnaryOperator *U,
-   AddStmtChoice asc) {
+static bool isFallthroughStatement(const AttributedStmt *A) {
+  bool isFallthrough = hasSpecificAttr(A->getAttrs());
+  assert((!isFallthrough || isa(A->getSubStmt())) &&
+ "expected fallthrough not to have children");
+  return isFallthrough;
+}
+
+CFGBlock *CFGBuilder::VisitAttributedStmt(AttributedStmt *A,
+  AddStmtChoice asc) {
+  // AttributedStmts for [[likely]] can have arbitrary statements as children,
+  // and the current visitation order here would add the AttributedStmts
+  // for [[likely]] after the child nodes, which is undesirable: For example,
+  // if the child contains an unconditional return, the [[likely]] would be
+  // considered unreachable.
+  // So only add the AttributedStmt for FallThrough, which has CFG effects and
+  // also no children, and omit the others. None of the other current StmtAttrs
+  // have semantic meaning for the CFG.
+  if (isFallthroughStatement(A) && asc.alwaysAdd(*this, A)) {
+autoCreateBlock();
+appendStmt(Block, A);
+  }
+
+  return VisitChildren(A);
+}
+
+CFGBlock *CFGBuilder::VisitUnaryOperator(UnaryOperator *U, AddStmtChoice asc) {
   if (asc.alwaysAdd(*this, U)) {
 autoCreateBlock();
 appendStmt(Block, U);

diff  --git a/clang/test/SemaCXX/switch-implicit-fallthrough.cpp 
b/clang/test/SemaCXX/switch-implicit-fallthrough.cpp
index 0b790813506c3..bb39d6349a179 100644
--- a/clang/test/SemaCXX/switch-implicit-fallthrough.cpp
+++ b/clang/test/SemaCXX/switch-implicit-fallthrough.cpp
@@ -50,6 +50,8 @@ int fallthrough(int n) {
   break;
   }
   switch (n / 20) {
+[[likely]] case 6:
+  [[clang::fallthrough]];
 case 7:
   n += 400;
   [[clang::fallthrough]];
@@ -73,6 +75,8 @@ int fallthrough(int n) {
   n += 800;
   }
   switch (n / 30) {
+case 6:
+  [[unlikely, clang::fallthrough]];
 case 11:
 case 12:  // no warning here, intended fall-through, no statement between 
labels
   n += 1600;

diff  --git a/clang/test/SemaCXX/unreachable-code.cpp 
b/clang/test/SemaCXX/unreachable-code.cpp
index 0dfc3d5744fb3..6a95f767bef02 100644
--- a/clang/test/SemaCXX/unreachable-code.cpp
+++ b/clang/test/SemaCXX/unreachable-code.cpp
@@ -77,3 +77,25 @@ void weak_redecl() {
 return;
   bar(); // no-warning
 }
+
+namespace pr52103 {
+
+void g(int a);
+
+void f(int a) {
+  if (a > 4) [[ likely ]] { // no-warning
+return;
+  }
+
+  if (a > 4) [[ unlikely ]] { // no-warning
+return;
+
+return; // expected-warning {{will never be executed}}
+  }
+
+  [[clang::musttail]] return g(a); // no-warning
+
+  [[clang::musttail]] return g(a); // expected-warning {{will never be 
executed}}
+}
+
+}



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


[PATCH] D111568: [clang] Omit most AttributedStatements from the CFG

2021-10-12 Thread Nico Weber 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 rGc74ab84ea23f: [clang] Omit most AttributedStatements from 
the CFG (authored by thakis).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111568

Files:
  clang/lib/Analysis/CFG.cpp
  clang/test/SemaCXX/switch-implicit-fallthrough.cpp
  clang/test/SemaCXX/unreachable-code.cpp

Index: clang/test/SemaCXX/unreachable-code.cpp
===
--- clang/test/SemaCXX/unreachable-code.cpp
+++ clang/test/SemaCXX/unreachable-code.cpp
@@ -77,3 +77,25 @@
 return;
   bar(); // no-warning
 }
+
+namespace pr52103 {
+
+void g(int a);
+
+void f(int a) {
+  if (a > 4) [[ likely ]] { // no-warning
+return;
+  }
+
+  if (a > 4) [[ unlikely ]] { // no-warning
+return;
+
+return; // expected-warning {{will never be executed}}
+  }
+
+  [[clang::musttail]] return g(a); // no-warning
+
+  [[clang::musttail]] return g(a); // expected-warning {{will never be executed}}
+}
+
+}
Index: clang/test/SemaCXX/switch-implicit-fallthrough.cpp
===
--- clang/test/SemaCXX/switch-implicit-fallthrough.cpp
+++ clang/test/SemaCXX/switch-implicit-fallthrough.cpp
@@ -50,6 +50,8 @@
   break;
   }
   switch (n / 20) {
+[[likely]] case 6:
+  [[clang::fallthrough]];
 case 7:
   n += 400;
   [[clang::fallthrough]];
@@ -73,6 +75,8 @@
   n += 800;
   }
   switch (n / 30) {
+case 6:
+  [[unlikely, clang::fallthrough]];
 case 11:
 case 12:  // no warning here, intended fall-through, no statement between labels
   n += 1600;
Index: clang/lib/Analysis/CFG.cpp
===
--- clang/lib/Analysis/CFG.cpp
+++ clang/lib/Analysis/CFG.cpp
@@ -542,6 +542,7 @@
   // Visitors to walk an AST and construct the CFG.
   CFGBlock *VisitInitListExpr(InitListExpr *ILE, AddStmtChoice asc);
   CFGBlock *VisitAddrLabelExpr(AddrLabelExpr *A, AddStmtChoice asc);
+  CFGBlock *VisitAttributedStmt(AttributedStmt *A, AddStmtChoice asc);
   CFGBlock *VisitBinaryOperator(BinaryOperator *B, AddStmtChoice asc);
   CFGBlock *VisitBreakStmt(BreakStmt *B);
   CFGBlock *VisitCallExpr(CallExpr *C, AddStmtChoice asc);
@@ -2149,6 +2150,9 @@
 case Stmt::InitListExprClass:
   return VisitInitListExpr(cast(S), asc);
 
+case Stmt::AttributedStmtClass:
+  return VisitAttributedStmt(cast(S), asc);
+
 case Stmt::AddrLabelExprClass:
   return VisitAddrLabelExpr(cast(S), asc);
 
@@ -2398,8 +2402,32 @@
   return Block;
 }
 
-CFGBlock *CFGBuilder::VisitUnaryOperator(UnaryOperator *U,
-   AddStmtChoice asc) {
+static bool isFallthroughStatement(const AttributedStmt *A) {
+  bool isFallthrough = hasSpecificAttr(A->getAttrs());
+  assert((!isFallthrough || isa(A->getSubStmt())) &&
+ "expected fallthrough not to have children");
+  return isFallthrough;
+}
+
+CFGBlock *CFGBuilder::VisitAttributedStmt(AttributedStmt *A,
+  AddStmtChoice asc) {
+  // AttributedStmts for [[likely]] can have arbitrary statements as children,
+  // and the current visitation order here would add the AttributedStmts
+  // for [[likely]] after the child nodes, which is undesirable: For example,
+  // if the child contains an unconditional return, the [[likely]] would be
+  // considered unreachable.
+  // So only add the AttributedStmt for FallThrough, which has CFG effects and
+  // also no children, and omit the others. None of the other current StmtAttrs
+  // have semantic meaning for the CFG.
+  if (isFallthroughStatement(A) && asc.alwaysAdd(*this, A)) {
+autoCreateBlock();
+appendStmt(Block, A);
+  }
+
+  return VisitChildren(A);
+}
+
+CFGBlock *CFGBuilder::VisitUnaryOperator(UnaryOperator *U, AddStmtChoice asc) {
   if (asc.alwaysAdd(*this, U)) {
 autoCreateBlock();
 appendStmt(Block, U);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D111568: [clang] Omit most AttributedStatements from the CFG

2021-10-12 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

LGTM, thank you @thakis!




Comment at: clang/lib/Analysis/CFG.cpp:2407
+  return hasSpecificAttr(A->getAttrs()) &&
+ isa(A->getSubStmt());
+}

hans wrote:
> thakis wrote:
> > hans wrote:
> > > Can fallthrough statements ever have children? If not, should it be an 
> > > assert instead of a check here?
> > Good question. Attr.td says:
> > 
> > ```
> >   // The attribute only applies to a NullStmt, but we have special fix-it
> >   // behavior if applied to a case label.
> >   let Subjects = SubjectList<[NullStmt, SwitchCase], ErrorDiag,
> >  "empty statements">;
> > ```
> > 
> > Which I suppose triggers for this:
> > 
> > ```
> >   switch (argc) {
> > [[fallthrough]] case 4:
> >   break;
> >   }
> > ```
> > 
> > ```
> > foo.cc:6:7: error: 'fallthrough' attribute is only allowed on empty 
> > statements
> > [[fallthrough]] case 4:
> >   ^ 
> > foo.cc:6:20: note: did you forget ';'?
> > [[fallthrough]] case 4:
> > ```
> > 
> > But that doesn't seem to make it into the AST, according to -dump-ast. So I 
> > suppose it could be an assert as well. Want me to change this?
> > 
> > 
> Yes, I think an assert would make sense, otherwise the reader has to think 
> about what would the code be doing for an AttributedStmt with non-null 
> substmt.
I think it's fine to assert because we're required to reject fallthrough 
statements applying to something other than a null statement: 
https://eel.is/c++draft/dcl.attr.fallthrough#1.sentence-1



Comment at: clang/lib/Analysis/CFG.cpp:2418-2420
+  // also no children, and omit the others. None of the other current StmtAttrs
+  // have semantic meaning for the CFG.
+  if (isFallthroughStatement(A) && asc.alwaysAdd(*this, A)) {

thakis wrote:
> aaron.ballman wrote:
> > What about `OpenCLUnrollHintAttr`, `NoMergeAttr`, and `MustTailAttr`? These 
> > all have some semantic effect as statement attributes in terms of changing 
> > codegen, but perhaps they don't need modelling in the CFG?
> > 
> > (I'm trying to decide whether we may want to tablegen this functionality 
> > and so we might want something more general than 
> > `isFallthroughStatement()`.)
> Right, I think they all have no interesting effect on the CFG.
> 
> It's hard to predict the future, so I'd say let's wait and see until there 
> are more StmtAttrs :)
SGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111568

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


[PATCH] D111543: [clang][modules] Stop creating `IdentifierInfo` for names of explicit modules

2021-10-12 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 added a comment.

In D111543#3056115 , @dexonsmith 
wrote:

> Are you sure this is only for Objective-C interfaces? Doesn't also happen if 
> you name a module after a C++ class or something, and reference it from an 
> attribute?

From my experiments, I don't think this is specific to Objective-C 
//interfaces//. I can reproduce this with:

  // Interface.h
  struct Interface;
  
  // module-name-used-by-objc-bridge.m
  void fn(struct Interface*);
  
  // without this patch:
  warning: declaration of 'struct Interface' will not be visible outside of 
this function
  
  // with this patch: success, no diagnostics

However, this seems to be specific to `objc_bridge` and friends 
(`objc_bridge_mutable`, `objc_bridge_related`). I'm not super familiar with 
attributes, but these seem to be the only ones that can accept an undefined 
type identifier.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111543

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


[PATCH] D111543: [clang][modules] Stop creating `IdentifierInfo` for names of explicit modules

2021-10-12 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 updated this revision to Diff 379003.
jansvoboda11 added a comment.

Run clang-format.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111543

Files:
  clang/include/clang/Lex/ModuleMap.h
  clang/lib/Frontend/CompilerInstance.cpp
  clang/test/Modules/Inputs/module-name-used-by-objc-bridge/Interface.h
  clang/test/Modules/Inputs/module-name-used-by-objc-bridge/InterfaceBridge.h
  clang/test/Modules/Inputs/module-name-used-by-objc-bridge/module.modulemap
  clang/test/Modules/module-name-used-by-objc-bridge.m

Index: clang/test/Modules/module-name-used-by-objc-bridge.m
===
--- /dev/null
+++ clang/test/Modules/module-name-used-by-objc-bridge.m
@@ -0,0 +1,25 @@
+// RUN: rm -rf %t && mkdir %t
+
+// RUN: %clang_cc1 -fmodules -x objective-c -emit-module -fmodule-name=InterfaceBridge \
+// RUN:   %S/Inputs/module-name-used-by-objc-bridge/module.modulemap -o %t/InterfaceBridge.pcm
+
+// RUN: %clang_cc1 -fmodules -x objective-c -emit-module -fmodule-name=Interface \
+// RUN:   %S/Inputs/module-name-used-by-objc-bridge/module.modulemap -o %t/Interface.pcm
+
+// Check that the `-fmodule-file==` form succeeds:
+// RUN: %clang_cc1 -fmodules -fsyntax-only %s -I %S/Inputs/module-name-used-by-objc-bridge \
+// RUN:   -fmodule-file=InterfaceBridge=%t/InterfaceBridge.pcm -fmodule-file=Interface=%t/Interface.pcm \
+// RUN:   -fmodule-map-file=%S/Inputs/module-name-used-by-objc-bridge/module.modulemap -verify
+
+// Check that the `-fmodule-file=` form succeeds:
+// RUN: %clang_cc1 -fmodules -fsyntax-only %s -I %S/Inputs/module-name-used-by-objc-bridge \
+// RUN:   -fmodule-file=%t/InterfaceBridge.pcm -fmodule-file=%t/Interface.pcm \
+// RUN:   -fmodule-map-file=%S/Inputs/module-name-used-by-objc-bridge/module.modulemap -verify
+
+#import "InterfaceBridge.h"
+#import "Interface.h"
+
+@interface Interface (User)
+@end
+
+// expected-no-diagnostics
Index: clang/test/Modules/Inputs/module-name-used-by-objc-bridge/module.modulemap
===
--- /dev/null
+++ clang/test/Modules/Inputs/module-name-used-by-objc-bridge/module.modulemap
@@ -0,0 +1,7 @@
+module InterfaceBridge {
+  header "InterfaceBridge.h"
+}
+
+module Interface {
+  header "Interface.h"
+}
Index: clang/test/Modules/Inputs/module-name-used-by-objc-bridge/InterfaceBridge.h
===
--- /dev/null
+++ clang/test/Modules/Inputs/module-name-used-by-objc-bridge/InterfaceBridge.h
@@ -0,0 +1 @@
+typedef struct __attribute__((objc_bridge(Interface))) Foo *Bar;
Index: clang/test/Modules/Inputs/module-name-used-by-objc-bridge/Interface.h
===
--- /dev/null
+++ clang/test/Modules/Inputs/module-name-used-by-objc-bridge/Interface.h
@@ -0,0 +1,2 @@
+@interface Interface
+@end
Index: clang/lib/Frontend/CompilerInstance.cpp
===
--- clang/lib/Frontend/CompilerInstance.cpp
+++ clang/lib/Frontend/CompilerInstance.cpp
@@ -1639,28 +1639,27 @@
   // the files we were handed.
   struct ReadModuleNames : ASTReaderListener {
 CompilerInstance &CI;
-llvm::SmallVector LoadedModules;
+llvm::SmallVector LoadedModules;
 
 ReadModuleNames(CompilerInstance &CI) : CI(CI) {}
 
 void ReadModuleName(StringRef ModuleName) override {
-  LoadedModules.push_back(
-  CI.getPreprocessor().getIdentifierInfo(ModuleName));
+  LoadedModules.push_back(ModuleName);
 }
 
 void registerAll() {
   ModuleMap &MM = CI.getPreprocessor().getHeaderSearchInfo().getModuleMap();
-  for (auto *II : LoadedModules)
-MM.cacheModuleLoad(*II, MM.findModule(II->getName()));
+  for (StringRef LoadedModule : LoadedModules)
+MM.cacheTopLevelModuleLoad(LoadedModule, MM.findModule(LoadedModule));
   LoadedModules.clear();
 }
 
 void markAllUnavailable() {
-  for (auto *II : LoadedModules) {
+  for (StringRef LoadedModule : LoadedModules) {
 if (Module *M = CI.getPreprocessor()
 .getHeaderSearchInfo()
 .getModuleMap()
-.findModule(II->getName())) {
+.findModule(LoadedModule)) {
   M->HasIncompatibleModuleFile = true;
 
   // Mark module as available if the only reason it was unavailable
Index: clang/include/clang/Lex/ModuleMap.h
===
--- clang/include/clang/Lex/ModuleMap.h
+++ clang/include/clang/Lex/ModuleMap.h
@@ -101,6 +101,10 @@
   /// The top-level modules that are known.
   llvm::StringMap Modules;
 
+  /// Top-module loading cache, indexed by module names.
+  /// nullptr is stored for modules that are known to fail to load.
+  llvm::StringMap CachedT

[PATCH] D111639: [PR51855] check PseudoObject when rebuilding CXXOperatorCallExpr in template instantiation

2021-10-12 Thread Bruno De Fraine via Phabricator via cfe-commits
brunodf created this revision.
brunodf added a reviewer: jeroen.dobbelaere.
brunodf added a project: clang.
brunodf requested review of this revision.
Herald added a subscriber: cfe-commits.

The invocation of a unary or binary operator for type-dependent expressions is 
represented as a CXXOperatorCallExpr. Upon template instantiation, 
TreeTransform::RebuildCXXOperatorCallExpr checks for the case of an overloaded 
operator, but not for a PseudoObject, and will directly create a UnaryOperator 
or BinaryOperator.

By invoking BuildUnaryOp or BuildBinaryOp instead, we also cover the case of 
PseudoObjects.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D111639

Files:
  clang/lib/Sema/TreeTransform.h
  clang/test/SemaCXX/PR51855.cpp

Index: clang/test/SemaCXX/PR51855.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/PR51855.cpp
@@ -0,0 +1,73 @@
+// RUN: %clang_cc1 -S -triple %itanium_abi_triple -fms-extensions -emit-llvm %s -o - | FileCheck %s
+
+struct F { };
+
+F operator*=(F& lhs, int rhs);
+
+F operator++(F& lhs);
+
+struct S {
+  short _m;
+  S(short _m): _m(_m) { }
+
+  void putM(short rhs) { _m = rhs; }
+  short getM() { return _m; }
+
+  __declspec(property(get=getM, put=putM)) short theData;
+};
+
+int test1a(int i) {
+  S tmp(i);
+  tmp.theData *= 2;
+  return tmp.theData;
+}
+
+// CHECK-LABEL: define {{.*}} i32 @_Z6test1ai(i32 %i)
+// CHECK: call void @_ZN1SC1Es
+// CHECK: call signext i16 @_ZN1S4getMEv
+// CHECK: call void @_ZN1S4putMEs
+// CHECK: call signext i16 @_ZN1S4getMEv
+
+
+template 
+int test1b(int i) {
+  T tmp(i);
+  tmp.theData *= 2;
+  return tmp.theData;
+}
+
+template int test1b(int);
+
+// CHECK-LABEL: define {{.*}} i32 @_Z6test1bI1SEii(i32 %i)
+// CHECK: call void @_ZN1SC1Es
+// CHECK: call signext i16 @_ZN1S4getMEv
+// CHECK: call void @_ZN1S4putMEs
+// CHECK: call signext i16 @_ZN1S4getMEv
+
+int test2a(int i) {
+  S tmp(i);
+  ++tmp.theData;
+  return tmp.theData;
+}
+
+// CHECK-LABEL: define {{.*}} i32 @_Z6test2ai(i32 %i)
+// CHECK: call void @_ZN1SC1Es
+// CHECK: call signext i16 @_ZN1S4getMEv
+// CHECK: call void @_ZN1S4putMEs
+// CHECK: call signext i16 @_ZN1S4getMEv
+
+template 
+int test2b(int i) {
+  T tmp(i);
+  ++tmp.theData;
+  return tmp.theData;
+}
+
+template int test2b(int);
+
+// CHECK-LABEL: define {{.*}} i32 @_Z6test2bI1SEii(i32 %i)
+// CHECK: call void @_ZN1SC1Es
+// CHECK: call signext i16 @_ZN1S4getMEv
+// CHECK: call void @_ZN1S4putMEs
+// CHECK: call signext i16 @_ZN1S4getMEv
+
Index: clang/lib/Sema/TreeTransform.h
===
--- clang/lib/Sema/TreeTransform.h
+++ clang/lib/Sema/TreeTransform.h
@@ -14605,7 +14605,8 @@
   UnaryOperatorKind Opc
 = UnaryOperator::getOverloadedOpcode(Op, isPostIncDec);
 
-  return getSema().CreateBuiltinUnaryOp(OpLoc, Opc, First);
+  // Invoke BuildUnaryOp to check for PseudoObject inc/dec
+  return getSema().BuildUnaryOp(/*Scope=*/nullptr, OpLoc, Opc, First);
 }
   } else {
 if (!First->getType()->isOverloadableType() &&
@@ -14613,8 +14614,9 @@
   // Neither of the arguments is an overloadable type, so try to
   // create a built-in binary operation.
   BinaryOperatorKind Opc = BinaryOperator::getOverloadedOpcode(Op);
+  // Invoke BuildBinOp to check for PseudoObject assignment
   ExprResult Result
-= SemaRef.CreateBuiltinBinOp(OpLoc, Opc, First, Second);
+= SemaRef.BuildBinOp(/*Scope=*/nullptr, OpLoc, Opc, First, Second);
   if (Result.isInvalid())
 return ExprError();
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D111640: [Analyzer][NFC] Add RangedConstraintManager to ConstraintAssignor

2021-10-12 Thread Gabor Marton via Phabricator via cfe-commits
martong created this revision.
martong added reviewers: steakhal, ASDenysPetrov, NoQ.
Herald added subscribers: manas, gamesh411, dkrupp, donat.nagy, Szelethus, 
mikhail.ramalho, a.sidorin, rnkovacs, szepet, baloghadamsoftware, xazax.hun, 
whisperity.
Herald added a reviewer: Szelethus.
martong requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

In this patch we store a reference to `RangedConstraintManager` in the
`ConstraintAssignor`. This way it is possible to call back and reuse some
functions of it. This patch is exclusively needed for its child patches,
it is not intended to be a standalone patch.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D111640

Files:
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp


Index: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -1600,12 +1600,13 @@
 public:
   template 
   LLVM_NODISCARD static ProgramStateRef
-  assign(ProgramStateRef State, SValBuilder &Builder, RangeSet::Factory &F,
- ClassOrSymbol CoS, RangeSet NewConstraint) {
+  assign(ProgramStateRef State, RangeConstraintManager &RCM,
+ SValBuilder &Builder, RangeSet::Factory &F, ClassOrSymbol CoS,
+ RangeSet NewConstraint) {
 if (!State || NewConstraint.isEmpty())
   return nullptr;
 
-ConstraintAssignor Assignor{State, Builder, F};
+ConstraintAssignor Assignor{State, RCM, Builder, F};
 return Assignor.assign(CoS, NewConstraint);
   }
 
@@ -1614,9 +1615,9 @@
  RangeSet Constraint);
 
 private:
-  ConstraintAssignor(ProgramStateRef State, SValBuilder &Builder,
- RangeSet::Factory &F)
-  : State(State), Builder(Builder), RangeFactory(F) {}
+  ConstraintAssignor(ProgramStateRef State, RangeConstraintManager &RCM,
+ SValBuilder &Builder, RangeSet::Factory &F)
+  : State(State), RCM(RCM), Builder(Builder), RangeFactory(F) {}
   using Base = ConstraintAssignorBase;
 
   /// Base method for handling new constraints for symbols.
@@ -1696,6 +1697,7 @@
   }
 
   ProgramStateRef State;
+  RangeConstraintManager &RCM;
   SValBuilder &Builder;
   RangeSet::Factory &RangeFactory;
 };
@@ -2407,7 +2409,8 @@
 ProgramStateRef RangeConstraintManager::setRange(ProgramStateRef State,
  SymbolRef Sym,
  RangeSet Range) {
-  return ConstraintAssignor::assign(State, getSValBuilder(), F, Sym, Range);
+  return ConstraintAssignor::assign(State, *this, getSValBuilder(), F, Sym,
+Range);
 }
 
 
//======


Index: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -1600,12 +1600,13 @@
 public:
   template 
   LLVM_NODISCARD static ProgramStateRef
-  assign(ProgramStateRef State, SValBuilder &Builder, RangeSet::Factory &F,
- ClassOrSymbol CoS, RangeSet NewConstraint) {
+  assign(ProgramStateRef State, RangeConstraintManager &RCM,
+ SValBuilder &Builder, RangeSet::Factory &F, ClassOrSymbol CoS,
+ RangeSet NewConstraint) {
 if (!State || NewConstraint.isEmpty())
   return nullptr;
 
-ConstraintAssignor Assignor{State, Builder, F};
+ConstraintAssignor Assignor{State, RCM, Builder, F};
 return Assignor.assign(CoS, NewConstraint);
   }
 
@@ -1614,9 +1615,9 @@
  RangeSet Constraint);
 
 private:
-  ConstraintAssignor(ProgramStateRef State, SValBuilder &Builder,
- RangeSet::Factory &F)
-  : State(State), Builder(Builder), RangeFactory(F) {}
+  ConstraintAssignor(ProgramStateRef State, RangeConstraintManager &RCM,
+ SValBuilder &Builder, RangeSet::Factory &F)
+  : State(State), RCM(RCM), Builder(Builder), RangeFactory(F) {}
   using Base = ConstraintAssignorBase;
 
   /// Base method for handling new constraints for symbols.
@@ -1696,6 +1697,7 @@
   }
 
   ProgramStateRef State;
+  RangeConstraintManager &RCM;
   SValBuilder &Builder;
   RangeSet::Factory &RangeFactory;
 };
@@ -2407,7 +2409,8 @@
 ProgramStateRef RangeConstraintManager::setRange(ProgramStateRef State,
  SymbolRef Sym,
  RangeSet Range) {
-  return ConstraintAssignor::assign(State, getSValBuilder(), F, Sym, Range);
+  return ConstraintAssignor::assign(State, *this, getSValBuilder(), F, Sym,
+Range);
 }
 
 //===-

[PATCH] D111642: [Analyzer][solver] Simplification: reorganize equalities with adjustment

2021-10-12 Thread Gabor Marton via Phabricator via cfe-commits
martong created this revision.
martong added reviewers: steakhal, ASDenysPetrov, NoQ.
Herald added subscribers: manas, gamesh411, dkrupp, donat.nagy, Szelethus, 
mikhail.ramalho, a.sidorin, rnkovacs, szepet, baloghadamsoftware, xazax.hun, 
whisperity.
Herald added a reviewer: Szelethus.
martong requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Initiate the reorganization of the equality information during symbol
simplification. E.g., if we bump into `c + 1 == 0` during simplification
then we'd like to express that `c == -1`. It makes sense to do this only
with `SymIntExpr`s.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D111642

Files:
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  clang/test/Analysis/solver-sym-simplification-adjustment.c

Index: clang/test/Analysis/solver-sym-simplification-adjustment.c
===
--- /dev/null
+++ clang/test/Analysis/solver-sym-simplification-adjustment.c
@@ -0,0 +1,78 @@
+// RUN: %clang_analyze_cc1 %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=debug.ExprInspection \
+// RUN:   -analyzer-config eagerly-assume=false \
+// RUN:   -verify
+
+void clang_analyzer_warnIfReached();
+void clang_analyzer_eval();
+
+void test_simplification_adjustment_concrete_int(int b, int c) {
+  if (b < 0 || b > 1)  // b: [0,1]
+return;
+  if (c < -1 || c > 1) // c: [-1,1]
+return;
+  if (c + b != 0)  // c + b == 0
+return;
+  clang_analyzer_warnIfReached(); // expected-warning{{REACHABLE}}
+  if (b != 1)  // b == 1  --> c + 1 == 0 --> c == -1
+return;
+  clang_analyzer_warnIfReached(); // expected-warning{{REACHABLE}}
+  clang_analyzer_eval(c == -1);   // expected-warning{{TRUE}}
+
+  // Keep the symbols and the constraints! alive.
+  (void)(b * c);
+  return;
+}
+
+void test_simplification_adjustment_range(int b, int c) {
+  if (b < 0 || b > 1)  // b: [0,1]
+return;
+  if (c < -1 || c > 1) // c: [-1,1]
+return;
+  if (c + b < -1 || c + b > 0) // c + b: [-1,0]
+return;
+  clang_analyzer_warnIfReached();  // expected-warning{{REACHABLE}}
+  if (b != 1)  // b == 1  --> c + 1: [-1,0] --> c: [-2,-1]
+return;
+  clang_analyzer_warnIfReached();  // expected-warning{{REACHABLE}}
+  clang_analyzer_eval(c == -1);// expected-warning{{TRUE}}
+
+  // Keep the symbols and the constraints! alive.
+  (void)(b * c);
+  return;
+}
+
+void test_simplification_adjustment_to_infeasible_concrete_int(int b, int c) {
+  if (b < 0 || b > 1) // b: [0,1]
+return;
+  if (c < 0 || c > 1) // c: [0,1]
+return;
+  if (c + b != 0) // c + b == 0
+return;
+  clang_analyzer_warnIfReached(); // expected-warning{{REACHABLE}}
+  if (b != 1) // b == 1  --> c + 1 == 0 --> c == -1 contradiction
+return;
+  clang_analyzer_warnIfReached(); // no warning
+
+  // Keep the symbols and the constraints! alive.
+  (void)(b * c);
+  return;
+}
+
+void test_simplification_adjustment_to_infeassible_range(int b, int c) {
+  if (b < 0 || b > 1)  // b: [0,1]
+return;
+  if (c < 0 || c > 1)  // c: [0,1]
+return;
+  if (c + b < -1 || c + b > 0) // c + b: [-1,0]
+return;
+  clang_analyzer_warnIfReached();  // expected-warning{{REACHABLE}}
+  if (b != 1)  // b == 1  --> c + 1: [-1,0] --> c: [-2,-1] contradiction
+return;
+  clang_analyzer_warnIfReached();  // no warning
+
+  // Keep the symbols and the constraints! alive.
+  (void)(b * c);
+  return;
+}
Index: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -602,10 +602,9 @@
   areEqual(ProgramStateRef State, SymbolRef First, SymbolRef Second);
 
   /// Iterate over all symbols and try to simplify them.
-  LLVM_NODISCARD static inline ProgramStateRef simplify(SValBuilder &SVB,
-RangeSet::Factory &F,
-ProgramStateRef State,
-EquivalenceClass Class);
+  LLVM_NODISCARD static inline ProgramStateRef
+  simplify(SValBuilder &SVB, RangeSet::Factory &F, RangedConstraintManager &RCM,
+   ProgramStateRef State, EquivalenceClass Class);
 
   void dumpToStream(ProgramStateRef State, raw_ostream &os) const;
   LLVM_DUMP_METHOD void dump(ProgramStateRef State) const {
@@ -1710,7 +1709,8 @@
   ClassMembersTy Members = State->get();
   for (std::pair ClassToSymbolSet : Members) {
 EquivalenceClass Class = ClassToSymbolSet.first;
-State = EquivalenceClass::simplify(Builder, RangeFactory, State, Class);
+State =
+EquivalenceClass::simplify(Builder, RangeFactory, RCM, State

[PATCH] D111041: [clang-tidy] Remove 'IgnoreDestructors = true' from cppcoreguidelines-explicit-virtual-functions

2021-10-12 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!




Comment at: 
clang-tools-extra/test/clang-tidy/checkers/modernize-use-override.cpp:56
   virtual ~SimpleCases();
-  // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: prefer using 'override' or 
(rarely) 'final' instead of 'virtual' [modernize-use-override]
+  // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: prefer using 'override' or 
(rarely) 'final' instead of 'virtual'
   // CHECK-FIXES: {{^}}  ~SimpleCases() override;

carlosgalvezp wrote:
> aaron.ballman wrote:
> > This isn't quite what I was after; now it looks like we expect to always 
> > get the diagnostic (in fact, I'm a bit worried that this test is passing). 
> > I'd rather see:
> > ```
> > // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: prefer using 'override' or 
> > (rarely) 'final' instead of 'virtual' [modernize-use-override]
> > // CHECK-CPPCOREGUIDELINES-NOT: :[[@LINE-2]]:11: warning: prefer using 
> > 'override' or (rarely) 'final' instead of 'virtual'
> > ```
> > So that we check explicitly we see the diagnostic for modernize and 
> > explicitly that we don't see the diagnostic for C++ Core Guidelines.
> > 
> > You'll need to change the second RUN line to not use `check_clang_tidy` but 
> > instead execute clang-tidy manually so you can pass 
> > `-check-prefix=CHECK-CPPCOREGUIDELINES` to it (as done in 
> > https://github.com/llvm/llvm-project/blob/main/clang-tools-extra/test/clang-tidy/checkers/cert-static-object-exception.cpp#L4).
> Not sure I follow. What you propose is something that would make sense 
> _before_ this patch, when the `cppcoreguidelines` check was _different_ than 
> `modernize`. But now they are not, they are identical, so we expect to get 
> identical diagnostics from them. Or am I missing something obvious?
> Or am I missing something obvious?

No, you just caught me having a major think-o. Again. Because this is the 
second time I've gotten the changes exactly backwards in my mind. :-D Sorry for 
the confusion!


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

https://reviews.llvm.org/D111041

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


[PATCH] D108301: [MSP430][Clang] Update hard-coded MCU data

2021-10-12 Thread Jozef Lawrynowicz via Phabricator via cfe-commits
jozefl updated this revision to Diff 379011.
jozefl added a comment.

Rebase onto new base revision to fix pre-merge tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108301

Files:
  clang/include/clang/Basic/MSP430Target.def
  clang/lib/Driver/ToolChains/MSP430.cpp
  clang/test/Driver/msp430-hwmult.c
  clang/test/Driver/msp430-mmcu.c
  clang/test/Driver/msp430-toolchain.c

Index: clang/test/Driver/msp430-toolchain.c
===
--- clang/test/Driver/msp430-toolchain.c
+++ clang/test/Driver/msp430-toolchain.c
@@ -253,6 +253,10 @@
 // RUN:   | FileCheck -check-prefix=HWMult-32BIT %s
 // HWMult-32BIT: "--start-group" "-lmul_32"
 
+// RUN: %clang %s -### -no-canonical-prefixes -target msp430 -mmcu=msp430fr5969 --sysroot="" 2>&1 \
+// RUN:   | FileCheck -check-prefix=HWMult-F5 %s
+// RUN: %clang %s -### -no-canonical-prefixes -target msp430 -mmcu=msp430fr5969 -mhwmult=auto --sysroot="" 2>&1 \
+// RUN:   | FileCheck -check-prefix=HWMult-F5 %s
 // RUN: %clang %s -### -no-canonical-prefixes -target msp430 -mhwmult=f5series --sysroot="" 2>&1 \
 // RUN:   | FileCheck -check-prefix=HWMult-F5 %s
 // HWMult-F5: "--start-group" "-lmul_f5"
Index: clang/test/Driver/msp430-mmcu.c
===
--- clang/test/Driver/msp430-mmcu.c
+++ clang/test/Driver/msp430-mmcu.c
@@ -1,15 +1,62 @@
+// This file tests that various different values passed to -mmcu= select the
+// correct target features and linker scripts, and create MCU-specific defines.
+
+// Test the lexicographic ordering of MCUs in MSP430Target.def.
+//
+// The MCU "msp430f110" should appear before "msp430f1101" when the data has
+// been sorted lexicographically. Some sorts will put "msp430f110" *after*
+// "msp430f1101", so when this happens, Clang will not be able to find this MCU.
+
+// RUN: %clang %s -### -no-canonical-prefixes -target msp430 -mmcu=msp430f110 2>&1 \
+// RUN:   | FileCheck %s
+
+// RUN: %clang %s -### -no-canonical-prefixes -target msp430 -mmcu=msp430f1101 2>&1 \
+// RUN:   | FileCheck %s
+
+// RUN: %clang %s -### -no-canonical-prefixes -target msp430 -mmcu=msp430f1101a 2>&1 \
+// RUN:   | FileCheck %s
+
+// CHECK-NOT: error: the clang compiler does not support
+
+// Test the symbol definitions, linker scripts and hardware multiply features
+// selected for different MCUs.
+
 // RUN: %clang %s -### -no-canonical-prefixes -target msp430 -mmcu=msp430c111 2>&1 \
 // RUN:   | FileCheck -check-prefix=MSP430-C111 %s
 
 // MSP430-C111: clang{{.*}} "-cc1" {{.*}} "-D__MSP430C111__"
+// MSP430-C111-NOT: "-target-feature" "+hwmult16"
+// MSP430-C111-NOT: "-target-feature" "+hwmult32"
+// MSP430-C111-NOT: "-target-feature" "+hwmultf5"
 // MSP430-C111: msp430-elf-ld{{.*}} "-Tmsp430c111.ld"
 
 // RUN: %clang %s -### -no-canonical-prefixes -target msp430 -mmcu=msp430i2020 2>&1 \
 // RUN:   | FileCheck -check-prefix=MSP430-I2020 %s
 
 // MSP430-I2020: clang{{.*}} "-cc1" {{.*}} "-D__MSP430i2020__"
+// MSP430-I2020: "-target-feature" "+hwmult16"
 // MSP430-I2020: msp430-elf-ld{{.*}} "-Tmsp430i2020.ld"
 
+// RUN: %clang %s -### -no-canonical-prefixes -target msp430 -mmcu=msp430f47126 2>&1 \
+// RUN:   | FileCheck -check-prefix=MSP430-F47126 %s
+
+// MSP430-F47126: clang{{.*}} "-cc1" {{.*}} "-D__MSP430F47126__"
+// MSP430-F47126: "-target-feature" "+hwmult32"
+// MSP430-F47126: msp430-elf-ld{{.*}} "-Tmsp430f47126.ld"
+
+// RAN: %clang %s -### -no-canonical-prefixes -target msp430 -mmcu=msp430fr5969 2>&1 \
+// RAN:   | FileCheck -check-prefix=MSP430-FR5969 %s
+
+// MSP430-FR5969: clang{{.*}} "-cc1" {{.*}} "-D__MSP430FR5969__"
+// MSP430-FR5969: "-target-feature" "+hwmultf5"
+// MSP430-FR5969: msp430-elf-ld{{.*}} "-Tmsp430fr5969.ld"
+
+// Test for the error message emitted when an invalid MCU is selected.
+//
+// Note that if this test is ever modified because the expected error message is
+// changed, the check prefixes at the top of this file, used to validate the
+// ordering of the hard-coded MCU data, also need to be updated.
+//
 // RUN: %clang %s -### -no-canonical-prefixes -target msp430 -mmcu=not-a-mcu 2>&1 \
 // RUN:   | FileCheck -check-prefix=MSP430-UNSUP %s
 
Index: clang/test/Driver/msp430-hwmult.c
===
--- clang/test/Driver/msp430-hwmult.c
+++ clang/test/Driver/msp430-hwmult.c
@@ -3,17 +3,13 @@
 
 // RUN: %clang -### -target msp430 %s 2>&1 | FileCheck %s
 // RUN: %clang -### -target msp430 %s -mhwmult=auto 2>&1 | FileCheck %s
+// RUN: %clang -### -target msp430 %s -mhwmult=none 2>&1 | FileCheck %s
+// RUN: %clang -### -target msp430 %s -mhwmult=none -mmcu=msp430f147 2>&1 | FileCheck %s
+// RUN: %clang -### -target msp430 %s -mhwmult=none -mmcu=msp430f4783 2>&1 | FileCheck %s
 // CHECK-NOT: "-target-feature" "+hwmult16"
 // CHECK-NOT: "-target-feature" "+hwmult32"
 // CHECK-NOT: "-target-feature

[PATCH] D108643: Introduce _BitInt, deprecate _ExtInt

2021-10-12 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

In D108643#3057417 , @rjmccall wrote:

> In D108643#3055244 , @erichkeane 
> wrote:
>
 ! In D108643#3054443 , @rjmccall 
 wrote:

> ! In D108643#3027473 , 
> @erichkeane wrote:
>
>> ! In D108643#3026550 , 
>> @rjmccall wrote:
>
> I think it would be better to provide a generic ABI specification that is 
> designed to "lower" `_BitInt` types into more basic concepts that ABIs 
> typically already have rules for.  It would be appropriate to note at the 
> top that this is only a generic specification and that the rules for any 
> particular platform should be codified in a platform-specific ABI.  But 
> we should make that easy so that platform owners who don't have strong 
> opinions about the ABI can just say "as described in version 1.4 of the 
> generic ABI at https://clang.llvm.org/...";
>
> Now, that is all independent of what we actually decide the ABI should 
> be.  But I do think that if we're going to make this available on all 
> targets, we should strongly consider doing a "legalizing" lowering in the 
> frontend: at ABI-exposed points (call arguments/parameters and memory 
> accesses), `_BitInt` types should be translated into types that a naive 
> backend can be trusted to handle in a way that matches the documented 
> ABI.  Individual targets can then opt in to using the natural lowerings 
> if they promise to match the ABI, but that becomes a decision that they 
> make to enable better optimization and code generation, not something 
> that's necessary for correctness.

 Don't we already have that?  We work the same way a 'bool' does, that is, 
 we zero/sign extend for parameters and return values?  The backends then 
 reliably up-scale these to the power-of-two/multiple-of-pointer.
>>>
>>> There's two levels of a "legalizing" lowering.
>>>
>>> On the specification level, we'd be formally saying that the ABI matches 
>>> the ABI of some other C construct.  For example, we might say that a 
>>> `signed _BitInt(14)` argument is treated exactly as if the argument type 
>>> was instead `signed short` (with whatever restriction we do or do not 
>>> impose on the range).  This is very nice on this level because, first, it's 
>>> a rule that works generically for all targets without needing to care about 
>>> the details of how arguments are assigned to registers or stack slots or 
>>> whatever; and second, it means you're never adding new cases to the ABI 
>>> that e.g. libffi would need to care about; and third, you can reliably 
>>> match the ABI with manually-lowered C code from a compiler that doesn't 
>>> even support `_BitInt`s.
>>>
>>> On the implementation level, we'd have to actually emit IR which will turn 
>>> into code which matches that ABI.  I think you are right that small 
>>> integers already reliably work that way in LLVM, so that if you pass an 
>>> `i11 sext` it'll get sign-extended to some width — what width exactly, I 
>>> don't know, but probably the same width that `i16 sext` would be.  Larger 
>>> integers, I'm not sure.  A legalizing lowering of big `_BitInt` argument 
>>> would presumably say either that it's exactly the same as a struct 
>>> containing all the chunks or that it's exactly the same as a series of 
>>> arguments for each of the chunks.  Those are two very different rules!  
>>> Most ABIs won't "straddle" a single argument between registers and the 
>>> stack, so e.g. if you'd need two registers and you only have one left then 
>>> you exhaust the registers and go fully on the stack; but obviously you can 
>>> get straddling if the lowering expands the sequence.  Similarly, some ABIs 
>>> will go indirect if the struct gets big enough, but you won't get that if 
>>> the lowering expands.  But on the other hand, if the rule is really that 
>>> it's like a struct, well, some ABIs don't pass small structs in registers.  
>>> Anyway, my point is that what exactly LLVM targets do if you give them an 
>>> `i117` might not match either of these possibilities reliably across 
>>> targets.  In any case, since we currently have to count registers in the 
>>> frontend for the register-passing ABIs, we'll need to actually know what 
>>> the targets do.
>>
>> Hmm... now that I think I understand the concern, I'm not sure we're able to 
>> take on this level of commitment. The Clang ABI code is a bit of a mess in 
>> general, plus each target has its own code, right (In 
>> CodeGen/TargetInfo.cpp)?
>
> Ideally we would have a generic handling of it that most ABI code would 
> simply trigger.
>
>> Additionally, that would require breaking the Microsoft ABI again, and I 
>> thought we'd discussed trying not to mak

[PATCH] D111041: [clang-tidy] Remove 'IgnoreDestructors = true' from cppcoreguidelines-explicit-virtual-functions

2021-10-12 Thread Carlos Galvez via Phabricator via cfe-commits
carlosgalvezp added a comment.

I realized I can speed up the test by removing the extra `RUN` line and simply 
add the new check to the list of checks, let me fix that before merge :)




Comment at: 
clang-tools-extra/test/clang-tidy/checkers/modernize-use-override.cpp:56
   virtual ~SimpleCases();
-  // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: prefer using 'override' or 
(rarely) 'final' instead of 'virtual' [modernize-use-override]
+  // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: prefer using 'override' or 
(rarely) 'final' instead of 'virtual'
   // CHECK-FIXES: {{^}}  ~SimpleCases() override;

aaron.ballman wrote:
> carlosgalvezp wrote:
> > aaron.ballman wrote:
> > > This isn't quite what I was after; now it looks like we expect to always 
> > > get the diagnostic (in fact, I'm a bit worried that this test is 
> > > passing). I'd rather see:
> > > ```
> > > // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: prefer using 'override' or 
> > > (rarely) 'final' instead of 'virtual' [modernize-use-override]
> > > // CHECK-CPPCOREGUIDELINES-NOT: :[[@LINE-2]]:11: warning: prefer using 
> > > 'override' or (rarely) 'final' instead of 'virtual'
> > > ```
> > > So that we check explicitly we see the diagnostic for modernize and 
> > > explicitly that we don't see the diagnostic for C++ Core Guidelines.
> > > 
> > > You'll need to change the second RUN line to not use `check_clang_tidy` 
> > > but instead execute clang-tidy manually so you can pass 
> > > `-check-prefix=CHECK-CPPCOREGUIDELINES` to it (as done in 
> > > https://github.com/llvm/llvm-project/blob/main/clang-tools-extra/test/clang-tidy/checkers/cert-static-object-exception.cpp#L4).
> > Not sure I follow. What you propose is something that would make sense 
> > _before_ this patch, when the `cppcoreguidelines` check was _different_ 
> > than `modernize`. But now they are not, they are identical, so we expect to 
> > get identical diagnostics from them. Or am I missing something obvious?
> > Or am I missing something obvious?
> 
> No, you just caught me having a major think-o. Again. Because this is the 
> second time I've gotten the changes exactly backwards in my mind. :-D Sorry 
> for the confusion!
No worries! :) 


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

https://reviews.llvm.org/D111041

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


[PATCH] D111640: [Analyzer][NFC] Add RangedConstraintManager to ConstraintAssignor

2021-10-12 Thread Balázs Benics via Phabricator via cfe-commits
steakhal accepted this revision.
steakhal added a comment.
This revision is now accepted and ready to land.

It looks good.
Do you think we could remove the `RangedConstraintManager` abstraction?
It shouldn't be hard to get rid of it.

Regardless, it's good to go, but let's wait for the child revision.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111640

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


[PATCH] D110357: [Analyzer] Extend ConstraintAssignor to handle remainder op

2021-10-12 Thread Gabor Marton via Phabricator via cfe-commits
martong updated this revision to Diff 379017.
martong added a comment.

- Rebase on top of new Parent (Use &RCM)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110357

Files:
  
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  clang/test/Analysis/constraint-assignor.c

Index: clang/test/Analysis/constraint-assignor.c
===
--- /dev/null
+++ clang/test/Analysis/constraint-assignor.c
@@ -0,0 +1,30 @@
+// RUN: %clang_analyze_cc1 %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=debug.ExprInspection \
+// RUN:   -verify
+
+// expected-no-diagnostics
+
+void clang_analyzer_warnIfReached();
+
+void rem_constant_rhs(int x, int y) {
+  if (x % 3 == 0) // x % 3 != 0 -> x != 0
+return;
+  if (x * y != 0) // x * y == 0
+return;
+  if (y != 1) // y == 1 -> x == 0
+return;
+  clang_analyzer_warnIfReached(); // no-warning
+  (void)x; // keep the constraints alive.
+}
+
+void rem_symbolic_rhs(int x, int y, int z) {
+  if (x % z == 0) // x % 3 != 0 -> x != 0
+return;
+  if (x * y != 0) // x * y == 0
+return;
+  if (y != 1) // y == 1 -> x == 0
+return;
+  clang_analyzer_warnIfReached(); // no-warning
+  (void)x; // keep the constraints alive.
+}
Index: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -1610,7 +1610,27 @@
 return Assignor.assign(CoS, NewConstraint);
   }
 
+  template 
+  bool handleRem(const SymT *Sym, RangeSet Constraint) {
+// a % b != 0 implies that a != 0.
+if (Sym->getOpcode() != BO_Rem)
+  return true;
+if (!Constraint.containsZero()) {
+  const SymExpr *LHS = Sym->getLHS();
+  const llvm::APSInt &Zero =
+  Builder.getBasicValueFactory().getValue(0, LHS->getType());
+  State = RCM.assumeSymNE(State, LHS, Zero, Zero);
+  if (!State)
+return false;
+}
+return true;
+  }
+
   inline bool assignSymExprToConst(const SymExpr *Sym, Const Constraint);
+  inline bool assignSymIntExprToRangeSet(const SymIntExpr *Sym,
+ RangeSet Constraint) {
+return handleRem(Sym, Constraint);
+  }
   inline bool assignSymSymExprToRangeSet(const SymSymExpr *Sym,
  RangeSet Constraint);
 
@@ -1688,9 +1708,7 @@
 if (Constraint.getConcreteValue())
   return !Constraint.getConcreteValue()->isZero();
 
-APSIntType T{Constraint.getMinValue()};
-Const Zero = T.getZeroValue();
-if (!Constraint.contains(Zero))
+if (!Constraint.containsZero())
   return true;
 
 return llvm::None;
@@ -1734,6 +1752,9 @@
 
 bool ConstraintAssignor::assignSymSymExprToRangeSet(const SymSymExpr *Sym,
 RangeSet Constraint) {
+  if (!handleRem(Sym, Constraint))
+return false;
+
   Optional ConstraintAsBool = interpreteAsBool(Constraint);
 
   if (!ConstraintAsBool)
Index: clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h
===
--- clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h
+++ clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h
@@ -282,6 +282,11 @@
   /// where N = size(this)
   bool contains(llvm::APSInt Point) const { return containsImpl(Point); }
 
+  bool containsZero() const {
+APSIntType T{getMinValue()};
+return contains(T.getZeroValue());
+  }
+
   void dump(raw_ostream &OS) const;
   void dump() const;
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D108643: Introduce _BitInt, deprecate _ExtInt

2021-10-12 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D108643#3057417 , @rjmccall wrote:

> I think the immediate way forward is that we can continue to document this as 
> an experimental feature with an unstable ABI, just with a new name.  We do 
> not need to tie these things together as long as we agree that the feature is 
> experimental and the ABI might change.  Perhaps it should be enabled by an 
> experimental flag until the ABI is official?

We've already documented that the ABI is being actively developed in the 
release notes, in the ABI document, and in LanguagateExtensions.rst, so the ABI 
information is widely available. I'm fine documenting the *ABI* as being 
unstable, but I want to make sure we don't give the impression that the 
*feature* is experimental (it's in a standard that is starting to be finalized 
for publication), so I'd be opposed to putting a standard feature behind a 
feature flag (beyond -std).

This is spiraling into a pretty large set of ongoing changes when the original 
intent was "rename the thing we were already happy with to its new, standard 
name with the same semantics". Would it make sense to separate some concerns 
here, as this is starting to block further work? At a high-level, I'm thinking: 
this patch does the rename, adds the release notes/documentation to be clear 
that the ABI is not yet stable for the feature, and a second patch is added for 
the ABI documentation and eventual codegen changes needed for it? This would 
unblock us from doing additional follow-up work (like adding the 
`BITINT_MAXWIDTH` macro to limits.h, which would not make sense without having 
a type named `_BitInt`) while giving us the Clang 14 release time frame to 
clean up the ABI requirements. WDYT?


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

https://reviews.llvm.org/D108643

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


[clang] 564e082 - [PowerPC] Allow MMA built-ins to accept restrict and volatile qualified pointers

2021-10-12 Thread Ahsan Saghir via cfe-commits

Author: Ahsan Saghir
Date: 2021-10-12T08:51:50-05:00
New Revision: 564e082d0954e0beebfff994ac03471d926cd1d1

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

LOG: [PowerPC] Allow MMA built-ins to accept restrict and volatile qualified 
pointers

This patch allows MMA built-ins on PowerPC to accept restrict
and volatile qualified pointers.

Reviewed By: #powerpc, nemanjai

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

Added: 


Modified: 
clang/lib/Sema/SemaChecking.cpp
clang/test/Sema/ppc-pair-mma-types.c

Removed: 




diff  --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index 0ee05c9f09a52..4d84606290b4e 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -7527,13 +7527,23 @@ bool Sema::SemaBuiltinPPCMMACall(CallExpr *TheCall, 
unsigned BuiltinID,
 }
 
 Expr *Arg = TheCall->getArg(ArgNum);
-QualType ArgType = Arg->getType();
-
-if ((ExpectedType->isVoidPointerType() && !ArgType->isPointerType()) ||
-(!ExpectedType->isVoidPointerType() &&
-   ArgType.getCanonicalType() != ExpectedType))
-  return Diag(Arg->getBeginLoc(), diag::err_typecheck_convert_incompatible)
- << ArgType << ExpectedType << 1 << 0 << 0;
+QualType PassedType = Arg->getType();
+QualType StrippedRVType = PassedType.getCanonicalType();
+
+// Strip Restrict/Volatile qualifiers.
+if (StrippedRVType.isRestrictQualified() ||
+StrippedRVType.isVolatileQualified())
+  StrippedRVType = StrippedRVType.getCanonicalType().getUnqualifiedType();
+
+// The only case where the argument type and expected type are allowed to
+// mismatch is if the argument type is a non-void pointer and expected type
+// is a void pointer.
+if (StrippedRVType != ExpectedType)
+  if (!(ExpectedType->isVoidPointerType() &&
+StrippedRVType->isPointerType()))
+return Diag(Arg->getBeginLoc(),
+diag::err_typecheck_convert_incompatible)
+   << PassedType << ExpectedType << 1 << 0 << 0;
 
 // If the value of the Mask is not 0, we have a constraint in the size of
 // the integer argument so here we ensure the argument is a constant that

diff  --git a/clang/test/Sema/ppc-pair-mma-types.c 
b/clang/test/Sema/ppc-pair-mma-types.c
index 360d597dfaffd..5f259b9780ae2 100644
--- a/clang/test/Sema/ppc-pair-mma-types.c
+++ b/clang/test/Sema/ppc-pair-mma-types.c
@@ -336,3 +336,23 @@ void testBuiltinTypes3(vector int v, __vector_pair *vp2, 
signed long l, unsigned
   __vector_pair vp = __builtin_vsx_lxvp(l, v); // expected-error {{passing 
'__vector int' (vector of 4 'int' values) to parameter of incompatible type 
'const __vector_pair *'}}
   __builtin_vsx_stxvp(vp, l, s);   // expected-error {{passing 
'unsigned short' to parameter of incompatible type 'const __vector_pair *'}}
 }
+
+void testRestrictQualifiedPointer1(int *__restrict acc) {
+  vector float arr[4];
+  __builtin_mma_disassemble_acc((void *)arr, acc); // expected-error {{passing 
'int *restrict' to parameter of incompatible type '__vector_quad *'}}
+}
+
+void testRestrictQualifiedPointer2(__vector_quad *__restrict acc) {
+  vector float arr[4];
+  __builtin_mma_disassemble_acc((void *)arr, acc);
+}
+
+void testVolatileQualifiedPointer1(int *__volatile acc) {
+  vector float arr[4];
+  __builtin_mma_disassemble_acc((void *)arr, acc); // expected-error {{passing 
'int *volatile' to parameter of incompatible type '__vector_quad *'}}
+}
+
+void testVolatileQualifiedPointer2(__vector_quad *__volatile acc) {
+  vector float arr[4];
+  __builtin_mma_disassemble_acc((void *)arr, acc);
+}



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


[PATCH] D106550: [PowerPC] Allow MMA built-ins to accept restrict and volatile qualified pointers

2021-10-12 Thread Ahsan Saghir 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 rG564e082d0954: [PowerPC] Allow MMA built-ins to accept 
restrict and volatile qualified pointers (authored by saghir).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106550

Files:
  clang/lib/Sema/SemaChecking.cpp
  clang/test/Sema/ppc-pair-mma-types.c


Index: clang/test/Sema/ppc-pair-mma-types.c
===
--- clang/test/Sema/ppc-pair-mma-types.c
+++ clang/test/Sema/ppc-pair-mma-types.c
@@ -336,3 +336,23 @@
   __vector_pair vp = __builtin_vsx_lxvp(l, v); // expected-error {{passing 
'__vector int' (vector of 4 'int' values) to parameter of incompatible type 
'const __vector_pair *'}}
   __builtin_vsx_stxvp(vp, l, s);   // expected-error {{passing 
'unsigned short' to parameter of incompatible type 'const __vector_pair *'}}
 }
+
+void testRestrictQualifiedPointer1(int *__restrict acc) {
+  vector float arr[4];
+  __builtin_mma_disassemble_acc((void *)arr, acc); // expected-error {{passing 
'int *restrict' to parameter of incompatible type '__vector_quad *'}}
+}
+
+void testRestrictQualifiedPointer2(__vector_quad *__restrict acc) {
+  vector float arr[4];
+  __builtin_mma_disassemble_acc((void *)arr, acc);
+}
+
+void testVolatileQualifiedPointer1(int *__volatile acc) {
+  vector float arr[4];
+  __builtin_mma_disassemble_acc((void *)arr, acc); // expected-error {{passing 
'int *volatile' to parameter of incompatible type '__vector_quad *'}}
+}
+
+void testVolatileQualifiedPointer2(__vector_quad *__volatile acc) {
+  vector float arr[4];
+  __builtin_mma_disassemble_acc((void *)arr, acc);
+}
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -7527,13 +7527,23 @@
 }
 
 Expr *Arg = TheCall->getArg(ArgNum);
-QualType ArgType = Arg->getType();
-
-if ((ExpectedType->isVoidPointerType() && !ArgType->isPointerType()) ||
-(!ExpectedType->isVoidPointerType() &&
-   ArgType.getCanonicalType() != ExpectedType))
-  return Diag(Arg->getBeginLoc(), diag::err_typecheck_convert_incompatible)
- << ArgType << ExpectedType << 1 << 0 << 0;
+QualType PassedType = Arg->getType();
+QualType StrippedRVType = PassedType.getCanonicalType();
+
+// Strip Restrict/Volatile qualifiers.
+if (StrippedRVType.isRestrictQualified() ||
+StrippedRVType.isVolatileQualified())
+  StrippedRVType = StrippedRVType.getCanonicalType().getUnqualifiedType();
+
+// The only case where the argument type and expected type are allowed to
+// mismatch is if the argument type is a non-void pointer and expected type
+// is a void pointer.
+if (StrippedRVType != ExpectedType)
+  if (!(ExpectedType->isVoidPointerType() &&
+StrippedRVType->isPointerType()))
+return Diag(Arg->getBeginLoc(),
+diag::err_typecheck_convert_incompatible)
+   << PassedType << ExpectedType << 1 << 0 << 0;
 
 // If the value of the Mask is not 0, we have a constraint in the size of
 // the integer argument so here we ensure the argument is a constant that


Index: clang/test/Sema/ppc-pair-mma-types.c
===
--- clang/test/Sema/ppc-pair-mma-types.c
+++ clang/test/Sema/ppc-pair-mma-types.c
@@ -336,3 +336,23 @@
   __vector_pair vp = __builtin_vsx_lxvp(l, v); // expected-error {{passing '__vector int' (vector of 4 'int' values) to parameter of incompatible type 'const __vector_pair *'}}
   __builtin_vsx_stxvp(vp, l, s);   // expected-error {{passing 'unsigned short' to parameter of incompatible type 'const __vector_pair *'}}
 }
+
+void testRestrictQualifiedPointer1(int *__restrict acc) {
+  vector float arr[4];
+  __builtin_mma_disassemble_acc((void *)arr, acc); // expected-error {{passing 'int *restrict' to parameter of incompatible type '__vector_quad *'}}
+}
+
+void testRestrictQualifiedPointer2(__vector_quad *__restrict acc) {
+  vector float arr[4];
+  __builtin_mma_disassemble_acc((void *)arr, acc);
+}
+
+void testVolatileQualifiedPointer1(int *__volatile acc) {
+  vector float arr[4];
+  __builtin_mma_disassemble_acc((void *)arr, acc); // expected-error {{passing 'int *volatile' to parameter of incompatible type '__vector_quad *'}}
+}
+
+void testVolatileQualifiedPointer2(__vector_quad *__volatile acc) {
+  vector float arr[4];
+  __builtin_mma_disassemble_acc((void *)arr, acc);
+}
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -7527,13 +7527,23 @@
 }
 
 Expr *Arg = TheCall->getArg(ArgNum);
- 

[PATCH] D111078: [AIX] Enable int128 in 64 bit mode

2021-10-12 Thread Jinsong Ji via Phabricator via cfe-commits
jsji added a comment.

Ping @hubert.reinterpretcast Any further comments?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111078

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


[PATCH] D111041: [clang-tidy] Remove 'IgnoreDestructors = true' from cppcoreguidelines-explicit-virtual-functions

2021-10-12 Thread Carlos Galvez via Phabricator via cfe-commits
carlosgalvezp updated this revision to Diff 379023.
carlosgalvezp added a comment.

Removed `RUN` line and put the check in the existing one, to speed up the test.


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

https://reviews.llvm.org/D111041

Files:
  clang-tools-extra/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/test/clang-tidy/checkers/modernize-use-override.cpp


Index: clang-tools-extra/test/clang-tidy/checkers/modernize-use-override.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/modernize-use-override.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/modernize-use-override.cpp
@@ -1,4 +1,4 @@
-// RUN: %check_clang_tidy %s modernize-use-override %t -- -- -fexceptions
+// RUN: %check_clang_tidy %s 
modernize-use-override,cppcoreguidelines-explicit-virtual-functions %t -- -- 
-fexceptions
 
 #define ABSTRACT = 0
 
@@ -52,7 +52,7 @@
 struct SimpleCases : public Base {
 public:
   virtual ~SimpleCases();
-  // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: prefer using 'override' or 
(rarely) 'final' instead of 'virtual' [modernize-use-override]
+  // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: prefer using 'override' or 
(rarely) 'final' instead of 'virtual'
   // CHECK-FIXES: {{^}}  ~SimpleCases() override;
 
   void a();
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -113,6 +113,10 @@
 Changes in existing checks
 ^^
 
+- Removed default setting 
`cppcoreguidelines-explicit-virtual-functions.IgnoreDestructors = "true"`,
+  to match the current state of the C++ Core Guidelines.
+
+
 Removed checks
 ^^
 
Index: 
clang-tools-extra/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
===
--- 
clang-tools-extra/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
+++ 
clang-tools-extra/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
@@ -106,9 +106,6 @@
 Opts["cppcoreguidelines-non-private-member-variables-in-classes."
  "IgnoreClassesWithAllMemberVariablesBeingPublic"] = "true";
 
-Opts["cppcoreguidelines-explicit-virtual-functions."
- "IgnoreDestructors"] = "true";
-
 return Options;
   }
 };


Index: clang-tools-extra/test/clang-tidy/checkers/modernize-use-override.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/modernize-use-override.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/modernize-use-override.cpp
@@ -1,4 +1,4 @@
-// RUN: %check_clang_tidy %s modernize-use-override %t -- -- -fexceptions
+// RUN: %check_clang_tidy %s modernize-use-override,cppcoreguidelines-explicit-virtual-functions %t -- -- -fexceptions
 
 #define ABSTRACT = 0
 
@@ -52,7 +52,7 @@
 struct SimpleCases : public Base {
 public:
   virtual ~SimpleCases();
-  // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: prefer using 'override' or (rarely) 'final' instead of 'virtual' [modernize-use-override]
+  // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: prefer using 'override' or (rarely) 'final' instead of 'virtual'
   // CHECK-FIXES: {{^}}  ~SimpleCases() override;
 
   void a();
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -113,6 +113,10 @@
 Changes in existing checks
 ^^
 
+- Removed default setting `cppcoreguidelines-explicit-virtual-functions.IgnoreDestructors = "true"`,
+  to match the current state of the C++ Core Guidelines.
+
+
 Removed checks
 ^^
 
Index: clang-tools-extra/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
===
--- clang-tools-extra/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
+++ clang-tools-extra/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
@@ -106,9 +106,6 @@
 Opts["cppcoreguidelines-non-private-member-variables-in-classes."
  "IgnoreClassesWithAllMemberVariablesBeingPublic"] = "true";
 
-Opts["cppcoreguidelines-explicit-virtual-functions."
- "IgnoreDestructors"] = "true";
-
 return Options;
   }
 };
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D111566: [SYCL] Fix function pointer address space

2021-10-12 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

need a test


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

https://reviews.llvm.org/D111566

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


[clang-tools-extra] 40546cb - Remove 'IgnoreDestructors = true' from cppcoreguidelines-explicit-virtual-functions

2021-10-12 Thread Aaron Ballman via cfe-commits

Author: Carlos Galvez
Date: 2021-10-12T10:08:08-04:00
New Revision: 40546cb38189e438a81faa6400c103d159600f9e

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

LOG: Remove 'IgnoreDestructors = true' from 
cppcoreguidelines-explicit-virtual-functions

This requirement was introduced in the C++ Core guidelines in 2016:

https://github.com/isocpp/CppCoreGuidelines/commit/1894380d0abf4d7d49a983005647e0d41ecbf214

Then clang-tidy got updated to comply with the rule.

However in 2019 this decision was reverted:

https://github.com/isocpp/CppCoreGuidelines/commit/5fdfb20b760c5307bf86873798a146fcd7e912e6

Therefore we need to apply the correct configuration to
clang-tidy again.

This also makes this cppcoreguidelines check consistent
with the other 2 alias checks: hicpp-use-override and
modernize-use-override.

Additionally, add another RUN line to the unit test,
to make sure cppcoreguidelines-explicit-virtual-functions
is tested.

Added: 


Modified: 

clang-tools-extra/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
clang-tools-extra/docs/ReleaseNotes.rst
clang-tools-extra/test/clang-tidy/checkers/modernize-use-override.cpp

Removed: 




diff  --git 
a/clang-tools-extra/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
 
b/clang-tools-extra/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
index c7b73dd675792..1c468b5cf0481 100644
--- 
a/clang-tools-extra/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
+++ 
b/clang-tools-extra/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
@@ -106,9 +106,6 @@ class CppCoreGuidelinesModule : public ClangTidyModule {
 Opts["cppcoreguidelines-non-private-member-variables-in-classes."
  "IgnoreClassesWithAllMemberVariablesBeingPublic"] = "true";
 
-Opts["cppcoreguidelines-explicit-virtual-functions."
- "IgnoreDestructors"] = "true";
-
 return Options;
   }
 };

diff  --git a/clang-tools-extra/docs/ReleaseNotes.rst 
b/clang-tools-extra/docs/ReleaseNotes.rst
index 3257a3d187e6f..498c36e9beeb4 100644
--- a/clang-tools-extra/docs/ReleaseNotes.rst
+++ b/clang-tools-extra/docs/ReleaseNotes.rst
@@ -113,6 +113,10 @@ New check aliases
 Changes in existing checks
 ^^
 
+- Removed default setting 
`cppcoreguidelines-explicit-virtual-functions.IgnoreDestructors = "true"`,
+  to match the current state of the C++ Core Guidelines.
+
+
 Removed checks
 ^^
 

diff  --git 
a/clang-tools-extra/test/clang-tidy/checkers/modernize-use-override.cpp 
b/clang-tools-extra/test/clang-tidy/checkers/modernize-use-override.cpp
index 8e4e113e4f431..55f226be70869 100644
--- a/clang-tools-extra/test/clang-tidy/checkers/modernize-use-override.cpp
+++ b/clang-tools-extra/test/clang-tidy/checkers/modernize-use-override.cpp
@@ -1,4 +1,4 @@
-// RUN: %check_clang_tidy %s modernize-use-override %t -- -- -fexceptions
+// RUN: %check_clang_tidy %s 
modernize-use-override,cppcoreguidelines-explicit-virtual-functions %t -- -- 
-fexceptions
 
 #define ABSTRACT = 0
 
@@ -52,7 +52,7 @@ struct Base {
 struct SimpleCases : public Base {
 public:
   virtual ~SimpleCases();
-  // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: prefer using 'override' or 
(rarely) 'final' instead of 'virtual' [modernize-use-override]
+  // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: prefer using 'override' or 
(rarely) 'final' instead of 'virtual'
   // CHECK-FIXES: {{^}}  ~SimpleCases() override;
 
   void a();



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


[PATCH] D111041: [clang-tidy] Remove 'IgnoreDestructors = true' from cppcoreguidelines-explicit-virtual-functions

2021-10-12 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman closed this revision.
aaron.ballman added a comment.

Thank you for the fix! I've commit on your behalf in 
40546cb38189e438a81faa6400c103d159600f9e 
.


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

https://reviews.llvm.org/D111041

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


[PATCH] D111169: [AIX] Disable tests failing due to assert on DWARF object writing

2021-10-12 Thread Jake Egan via Phabricator via cfe-commits
Jake-Egan abandoned this revision.
Jake-Egan added a comment.

Abandoning this patch because D97184  is 
already committed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69

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


[PATCH] D110065: [AArch64] Add support for the 'R' architecture profile.

2021-10-12 Thread John Brawn via Phabricator via cfe-commits
john.brawn added a comment.

Looking at the behaviour of gcc it looks like there -march=armv8-r enables 
instructions that are present in 8-r but not 8-a, but doesn't disable any 
instructions. So e.g. it will accept the dcps3 instruction when compiling with 
-march=armv8-r whereas clang won't. That's probably a bug in gcc though.


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

https://reviews.llvm.org/D110065

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


[clang-tools-extra] a76cfc2 - [clang-tidy] Update documentation of check bugprone-unused-return-value [NFC].

2021-10-12 Thread Balázs Kéri via cfe-commits

Author: Balázs Kéri
Date: 2021-10-12T16:43:45+02:00
New Revision: a76cfc2e840ff373b80e3a5f84fc48c5f1f90d8a

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

LOG: [clang-tidy] Update documentation of check bugprone-unused-return-value 
[NFC].

The list of checked functions was incomplete in the description.

Reviewed By: aaron.ballman, steakhal

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

Added: 


Modified: 
clang-tools-extra/docs/clang-tidy/checks/bugprone-unused-return-value.rst

Removed: 




diff  --git 
a/clang-tools-extra/docs/clang-tidy/checks/bugprone-unused-return-value.rst 
b/clang-tools-extra/docs/clang-tidy/checks/bugprone-unused-return-value.rst
index 07ce13e07412e..4cc54ed02d16b 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/bugprone-unused-return-value.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/bugprone-unused-return-value.rst
@@ -10,9 +10,25 @@ Options
 
 .. option:: CheckedFunctions
 
-   Semicolon-separated list of functions to check. Defaults to
-   
``::std::async;::std::launder;::std::remove;::std::remove_if;::std::unique;::std::unique_ptr::release;::std::basic_string::empty;::std::vector::empty``.
-   This means that the calls to following functions are checked by default:
+   Semicolon-separated list of functions to check. The function is checked if
+   the name and scope matches, with any arguments.
+   By default the following functions are checked:
+   ``std::async, std::launder, std::remove, std::remove_if, std::unique,
+   std::unique_ptr::release, std::basic_string::empty, std::vector::empty,
+   std::back_inserter, std::distance, std::find, std::find_if, std::inserter,
+   std::lower_bound, std::make_pair, std::map::count, std::map::find,
+   std::map::lower_bound, std::multimap::equal_range,
+   std::multimap::upper_bound, std::set::count, std::set::find, std::setfill,
+   std::setprecision, std::setw, std::upper_bound, std::vector::at,
+   bsearch, ferror, feof, isalnum, isalpha, isblank, iscntrl, isdigit, isgraph,
+   islower, isprint, ispunct, isspace, isupper, iswalnum, iswprint, iswspace,
+   isxdigit, memchr, memcmp, strcmp, strcoll, strncmp, strpbrk, strrchr,
+   strspn, strstr, wcscmp, access, bind, connect, 
diff time, dlsym, fnmatch,
+   getaddrinfo, getopt, htonl, htons, iconv_open, inet_addr, isascii, isatty,
+   mmap, newlocale, openat, pathconf, pthread_equal, pthread_getspecific,
+   pthread_mutex_trylock, readdir, readlink, recvmsg, regexec, scandir,
+   semget, setjmp, shm_open, shmget, sigismember, strcasecmp, strsignal,
+   ttyname``
 
- ``std::async()``. Not using the return value makes the call synchronous.
- ``std::launder()``. Not using the return value usually means that the



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


[PATCH] D111623: [clang-tidy] Update documentation of check bugprone-unused-return-value [NFC].

2021-10-12 Thread Balázs Kéri via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGa76cfc2e840f: [clang-tidy] Update documentation of check 
bugprone-unused-return-value [NFC]. (authored by balazske).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111623

Files:
  clang-tools-extra/docs/clang-tidy/checks/bugprone-unused-return-value.rst


Index: clang-tools-extra/docs/clang-tidy/checks/bugprone-unused-return-value.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/bugprone-unused-return-value.rst
+++ clang-tools-extra/docs/clang-tidy/checks/bugprone-unused-return-value.rst
@@ -10,9 +10,25 @@
 
 .. option:: CheckedFunctions
 
-   Semicolon-separated list of functions to check. Defaults to
-   
``::std::async;::std::launder;::std::remove;::std::remove_if;::std::unique;::std::unique_ptr::release;::std::basic_string::empty;::std::vector::empty``.
-   This means that the calls to following functions are checked by default:
+   Semicolon-separated list of functions to check. The function is checked if
+   the name and scope matches, with any arguments.
+   By default the following functions are checked:
+   ``std::async, std::launder, std::remove, std::remove_if, std::unique,
+   std::unique_ptr::release, std::basic_string::empty, std::vector::empty,
+   std::back_inserter, std::distance, std::find, std::find_if, std::inserter,
+   std::lower_bound, std::make_pair, std::map::count, std::map::find,
+   std::map::lower_bound, std::multimap::equal_range,
+   std::multimap::upper_bound, std::set::count, std::set::find, std::setfill,
+   std::setprecision, std::setw, std::upper_bound, std::vector::at,
+   bsearch, ferror, feof, isalnum, isalpha, isblank, iscntrl, isdigit, isgraph,
+   islower, isprint, ispunct, isspace, isupper, iswalnum, iswprint, iswspace,
+   isxdigit, memchr, memcmp, strcmp, strcoll, strncmp, strpbrk, strrchr,
+   strspn, strstr, wcscmp, access, bind, connect, difftime, dlsym, fnmatch,
+   getaddrinfo, getopt, htonl, htons, iconv_open, inet_addr, isascii, isatty,
+   mmap, newlocale, openat, pathconf, pthread_equal, pthread_getspecific,
+   pthread_mutex_trylock, readdir, readlink, recvmsg, regexec, scandir,
+   semget, setjmp, shm_open, shmget, sigismember, strcasecmp, strsignal,
+   ttyname``
 
- ``std::async()``. Not using the return value makes the call synchronous.
- ``std::launder()``. Not using the return value usually means that the


Index: clang-tools-extra/docs/clang-tidy/checks/bugprone-unused-return-value.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/bugprone-unused-return-value.rst
+++ clang-tools-extra/docs/clang-tidy/checks/bugprone-unused-return-value.rst
@@ -10,9 +10,25 @@
 
 .. option:: CheckedFunctions
 
-   Semicolon-separated list of functions to check. Defaults to
-   ``::std::async;::std::launder;::std::remove;::std::remove_if;::std::unique;::std::unique_ptr::release;::std::basic_string::empty;::std::vector::empty``.
-   This means that the calls to following functions are checked by default:
+   Semicolon-separated list of functions to check. The function is checked if
+   the name and scope matches, with any arguments.
+   By default the following functions are checked:
+   ``std::async, std::launder, std::remove, std::remove_if, std::unique,
+   std::unique_ptr::release, std::basic_string::empty, std::vector::empty,
+   std::back_inserter, std::distance, std::find, std::find_if, std::inserter,
+   std::lower_bound, std::make_pair, std::map::count, std::map::find,
+   std::map::lower_bound, std::multimap::equal_range,
+   std::multimap::upper_bound, std::set::count, std::set::find, std::setfill,
+   std::setprecision, std::setw, std::upper_bound, std::vector::at,
+   bsearch, ferror, feof, isalnum, isalpha, isblank, iscntrl, isdigit, isgraph,
+   islower, isprint, ispunct, isspace, isupper, iswalnum, iswprint, iswspace,
+   isxdigit, memchr, memcmp, strcmp, strcoll, strncmp, strpbrk, strrchr,
+   strspn, strstr, wcscmp, access, bind, connect, difftime, dlsym, fnmatch,
+   getaddrinfo, getopt, htonl, htons, iconv_open, inet_addr, isascii, isatty,
+   mmap, newlocale, openat, pathconf, pthread_equal, pthread_getspecific,
+   pthread_mutex_trylock, readdir, readlink, recvmsg, regexec, scandir,
+   semget, setjmp, shm_open, shmget, sigismember, strcasecmp, strsignal,
+   ttyname``
 
- ``std::async()``. Not using the return value makes the call synchronous.
- ``std::launder()``. Not using the return value usually means that the
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D111623: [clang-tidy] Update documentation of check bugprone-unused-return-value [NFC].

2021-10-12 Thread Eugene Zelenko via Phabricator via cfe-commits
Eugene.Zelenko added inline comments.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/bugprone-unused-return-value.rst:16
+   By default the following functions are checked:
+   ``std::async, std::launder, std::remove, std::remove_if, std::unique,
+   std::unique_ptr::release, std::basic_string::empty, std::vector::empty,

I think will be good idea to maintain list style as later entries. Some 
comments may be added after name.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111623

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


[clang] dcd7471 - [clang] p0388 conversion to incomplete array

2021-10-12 Thread Nathan Sidwell via cfe-commits

Author: Nathan Sidwell
Date: 2021-10-12T07:35:20-07:00
New Revision: dcd74716f9d18444a17de852a760cc85bd16f825

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

LOG: [clang] p0388 conversion to incomplete array

This implements the new implicit conversion sequence to an incomplete
(unbounded) array type.  It is mostly Richard Smith's work, updated to
trunk, testcases added and a few bugs fixed found in such testing.

It is not a complete implementation of p0388.

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

Added: 
clang/test/CodeGenCXX/cxx20-p0388-unbound-ary.cpp
clang/test/SemaCXX/cxx20-p0388-unbound-ary.cpp

Modified: 
clang/include/clang/AST/ASTContext.h
clang/lib/AST/ASTContext.cpp
clang/lib/CodeGen/CGExpr.cpp
clang/lib/CodeGen/CGExprScalar.cpp
clang/lib/CodeGen/CGObjC.cpp
clang/lib/Sema/SemaCast.cpp
clang/lib/Sema/SemaExprCXX.cpp
clang/lib/Sema/SemaOverload.cpp
clang/test/CXX/drs/dr3xx.cpp

Removed: 




diff  --git a/clang/include/clang/AST/ASTContext.h 
b/clang/include/clang/AST/ASTContext.h
index 443df3790fc13..b21f9b83b9d86 100644
--- a/clang/include/clang/AST/ASTContext.h
+++ b/clang/include/clang/AST/ASTContext.h
@@ -2535,8 +2535,10 @@ class ASTContext : public RefCountedBase {
   bool ObjCMethodsAreEqual(const ObjCMethodDecl *MethodDecl,
const ObjCMethodDecl *MethodImp);
 
-  bool UnwrapSimilarTypes(QualType &T1, QualType &T2);
-  void UnwrapSimilarArrayTypes(QualType &T1, QualType &T2);
+  bool UnwrapSimilarTypes(QualType &T1, QualType &T2,
+  bool AllowPiMismatch = true);
+  void UnwrapSimilarArrayTypes(QualType &T1, QualType &T2,
+   bool AllowPiMismatch = true);
 
   /// Determine if two types are similar, according to the C++ rules. That is,
   /// determine if they are the same other than qualifiers on the initial

diff  --git a/clang/lib/AST/ASTContext.cpp b/clang/lib/AST/ASTContext.cpp
index f4239869e93db..da49084f518a3 100644
--- a/clang/lib/AST/ASTContext.cpp
+++ b/clang/lib/AST/ASTContext.cpp
@@ -5844,7 +5844,11 @@ QualType ASTContext::getUnqualifiedArrayType(QualType 
type,
 /// Attempt to unwrap two types that may both be array types with the same 
bound
 /// (or both be array types of unknown bound) for the purpose of comparing the
 /// cv-decomposition of two types per C++ [conv.qual].
-void ASTContext::UnwrapSimilarArrayTypes(QualType &T1, QualType &T2) {
+///
+/// \param AllowPiMismatch Allow the Pi1 and Pi2 to 
diff er as described in
+///C++20 [conv.qual], if permitted by the current language mode.
+void ASTContext::UnwrapSimilarArrayTypes(QualType &T1, QualType &T2,
+ bool AllowPiMismatch) {
   while (true) {
 auto *AT1 = getAsArrayType(T1);
 if (!AT1)
@@ -5856,12 +5860,21 @@ void ASTContext::UnwrapSimilarArrayTypes(QualType &T1, 
QualType &T2) {
 
 // If we don't have two array types with the same constant bound nor two
 // incomplete array types, we've unwrapped everything we can.
+// C++20 also permits one type to be a constant array type and the other
+// to be an incomplete array type.
+// FIXME: Consider also unwrapping array of unknown bound and VLA.
 if (auto *CAT1 = dyn_cast(AT1)) {
   auto *CAT2 = dyn_cast(AT2);
-  if (!CAT2 || CAT1->getSize() != CAT2->getSize())
+  if (!(CAT2 && CAT1->getSize() == CAT2->getSize()) &&
+  !(getLangOpts().CPlusPlus20 && AllowPiMismatch &&
+isa(AT2)))
+return;
+} else if (isa(AT1)) {
+  if (!isa(AT2) &&
+  !(getLangOpts().CPlusPlus20 && AllowPiMismatch &&
+isa(AT2)))
 return;
-} else if (!isa(AT1) ||
-   !isa(AT2)) {
+} else {
   return;
 }
 
@@ -5880,10 +5893,14 @@ void ASTContext::UnwrapSimilarArrayTypes(QualType &T1, 
QualType &T2) {
 /// "unwraps" pointer and pointer-to-member types to compare them at each
 /// level.
 ///
+/// \param AllowPiMismatch Allow the Pi1 and Pi2 to 
diff er as described in
+///C++20 [conv.qual], if permitted by the current language mode.
+///
 /// \return \c true if a pointer type was unwrapped, \c false if we reached a
 /// pair of types that can't be unwrapped further.
-bool ASTContext::UnwrapSimilarTypes(QualType &T1, QualType &T2) {
-  UnwrapSimilarArrayTypes(T1, T2);
+bool ASTContext::UnwrapSimilarTypes(QualType &T1, QualType &T2,
+bool AllowPiMismatch) {
+  UnwrapSimilarArrayTypes(T1, T2, AllowPiMismatch);
 
   const auto *T1PtrType = T1->getAs();
   const auto *T2PtrType = T2->getAs();
@@ -5944,7 +5961,7 @@ bool ASTContext::hasCvrSimilarType(QualType T1, QualType 
T2) {
 if (hasSameType(T1, T2))
   return true;

[clang] 444ec09 - [clang] p0388 array list initialization overloads

2021-10-12 Thread Nathan Sidwell via cfe-commits

Author: Nathan Sidwell
Date: 2021-10-12T07:35:21-07:00
New Revision: 444ec0957c58492ecce0569bb20b7d3ad59d37bb

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

LOG: [clang] p0388 array list initialization overloads

This is the second part of p0388, dealing with overloads of list
initialization to incomplete array types.  It extends the handling
added in D103088 to permit incomplete arrays.  We have to record that
the conversion involved an incomplete array, and so (re-add) a bit flag
into the standard conversion sequence object.  Comparing such
conversion sequences requires knowing (a) the number of array elements
initialized and (b) whether the initialization is of an incomplete array.

This also updates the web page to indicate p0388 is implemented (there
is no feature macro).

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

Added: 


Modified: 
clang/include/clang/Sema/Overload.h
clang/lib/AST/ASTContext.cpp
clang/lib/Sema/SemaOverload.cpp
clang/test/SemaCXX/cxx20-p0388-unbound-ary.cpp
clang/www/cxx_status.html

Removed: 




diff  --git a/clang/include/clang/Sema/Overload.h 
b/clang/include/clang/Sema/Overload.h
index f16595c3319cd..7898a58c27960 100644
--- a/clang/include/clang/Sema/Overload.h
+++ b/clang/include/clang/Sema/Overload.h
@@ -535,7 +535,10 @@ class Sema;
 };
 
 /// ConversionKind - The kind of implicit conversion sequence.
-unsigned ConversionKind;
+unsigned ConversionKind : 31;
+
+// Whether the initializer list was of an incomplete array.
+unsigned InitializerListOfIncompleteArray : 1;
 
 /// When initializing an array or std::initializer_list from an
 /// initializer-list, this is the array or std::initializer_list type being
@@ -573,12 +576,16 @@ class Sema;
 };
 
 ImplicitConversionSequence()
-: ConversionKind(Uninitialized), InitializerListContainerType() {
+: ConversionKind(Uninitialized),
+  InitializerListOfIncompleteArray(false),
+  InitializerListContainerType() {
   Standard.setAsIdentityConversion();
 }
 
 ImplicitConversionSequence(const ImplicitConversionSequence &Other)
 : ConversionKind(Other.ConversionKind),
+  InitializerListOfIncompleteArray(
+  Other.InitializerListOfIncompleteArray),
   InitializerListContainerType(Other.InitializerListContainerType) {
   switch (ConversionKind) {
   case Uninitialized: break;
@@ -680,8 +687,12 @@ class Sema;
 bool hasInitializerListContainerType() const {
   return !InitializerListContainerType.isNull();
 }
-void setInitializerListContainerType(QualType T) {
+void setInitializerListContainerType(QualType T, bool IA) {
   InitializerListContainerType = T;
+  InitializerListOfIncompleteArray = IA;
+}
+bool isInitializerListOfIncompleteArray() const {
+  return InitializerListOfIncompleteArray;
 }
 QualType getInitializerListContainerType() const {
   assert(hasInitializerListContainerType() &&

diff  --git a/clang/lib/AST/ASTContext.cpp b/clang/lib/AST/ASTContext.cpp
index da49084f518a3..a6b11465d4bcd 100644
--- a/clang/lib/AST/ASTContext.cpp
+++ b/clang/lib/AST/ASTContext.cpp
@@ -5865,14 +5865,14 @@ void ASTContext::UnwrapSimilarArrayTypes(QualType &T1, 
QualType &T2,
 // FIXME: Consider also unwrapping array of unknown bound and VLA.
 if (auto *CAT1 = dyn_cast(AT1)) {
   auto *CAT2 = dyn_cast(AT2);
-  if (!(CAT2 && CAT1->getSize() == CAT2->getSize()) &&
-  !(getLangOpts().CPlusPlus20 && AllowPiMismatch &&
-isa(AT2)))
+  if (!((CAT2 && CAT1->getSize() == CAT2->getSize()) ||
+(AllowPiMismatch && getLangOpts().CPlusPlus20 &&
+ isa(AT2
 return;
 } else if (isa(AT1)) {
-  if (!isa(AT2) &&
-  !(getLangOpts().CPlusPlus20 && AllowPiMismatch &&
-isa(AT2)))
+  if (!(isa(AT2) ||
+(AllowPiMismatch && getLangOpts().CPlusPlus20 &&
+ isa(AT2
 return;
 } else {
   return;

diff  --git a/clang/lib/Sema/SemaOverload.cpp b/clang/lib/Sema/SemaOverload.cpp
index 5c513a4326933..044e3c4b254ad 100644
--- a/clang/lib/Sema/SemaOverload.cpp
+++ b/clang/lib/Sema/SemaOverload.cpp
@@ -3820,8 +3820,8 @@ CompareImplicitConversionSequences(Sema &S, 
SourceLocation Loc,
   //   if not that,
   // — L1 and L2 convert to arrays of the same element type, and either the
   //   number of elements n_1 initialized by L1 is less than the number of
-  //   elements n_2 initialized by L2, or (unimplemented:C++20) n_1 = n_2 and 
L2
-  //   converts to an array of unknown bound and L1 does not,
+  //   elements n_2 initialized by L2, or (C++20) n_1 = n_2 and L2 converts to
+  //   an array of unkn

[PATCH] D102645: [clang] p0388 conversion to incomplete array

2021-10-12 Thread Nathan Sidwell via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGdcd74716f9d1: [clang] p0388 conversion to incomplete array 
(authored by urnathan).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D102645?vs=355943&id=379032#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102645

Files:
  clang/include/clang/AST/ASTContext.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/CodeGen/CGObjC.cpp
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/test/CXX/drs/dr3xx.cpp
  clang/test/CodeGenCXX/cxx20-p0388-unbound-ary.cpp
  clang/test/SemaCXX/cxx20-p0388-unbound-ary.cpp

Index: clang/test/SemaCXX/cxx20-p0388-unbound-ary.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/cxx20-p0388-unbound-ary.cpp
@@ -0,0 +1,79 @@
+// RUN: %clang_cc1 -std=c++20 -verify %s
+// RUN: %clang_cc1 -std=c++17 -verify %s
+
+// p0388 conversions to unbounded array
+// dcl.init.list/3
+
+namespace One {
+int ga[1];
+
+auto &frob1() {
+  int(&r1)[] = ga;
+#if __cplusplus < 202002
+  // expected-error@-2{{cannot bind to a value of unrelated type}}
+#endif
+
+  return r1;
+}
+
+auto &frob2(int (&arp)[1]) {
+  int(&r2)[] = arp;
+#if __cplusplus < 202002
+  // expected-error@-2{{cannot bind to a value of unrelated type}}
+#endif
+
+  return r2;
+}
+} // namespace One
+
+namespace Two {
+int ga[1];
+
+auto *frob1() {
+  int(*r1)[] = &ga;
+#if __cplusplus < 202002
+  // expected-error@-2{{with an rvalue of type}}
+#endif
+
+  return r1;
+}
+
+auto *frob2(int (*arp)[1]) {
+  int(*r2)[] = arp;
+#if __cplusplus < 202002
+  // expected-error@-2{{with an lvalue of type}}
+#endif
+
+  return r2;
+}
+} // namespace Two
+
+namespace Four {
+using Inc = int[2];
+using Mat = Inc[1];
+Mat *ga[2];
+
+auto *frob1() {
+  Inc(*const(*r1)[])[] = &ga;
+#if __cplusplus < 202002
+  // expected-error@-2{{with an rvalue of type}}
+#else
+  // missing a required 'const'
+  Inc(*(*r2)[])[] = &ga; // expected-error{{cannot initialize}}
+#endif
+
+  return r1;
+}
+
+auto *frob2(Mat *(*arp)[1]) {
+  Inc(*const(*r2)[])[] = arp;
+#if __cplusplus < 202002
+  // expected-error@-2{{with an lvalue of type}}
+#else
+  Inc(*(*r3)[])[] = arp; // expected-error{{cannot initialize}}
+#endif
+
+  return r2;
+}
+
+} // namespace Four
Index: clang/test/CodeGenCXX/cxx20-p0388-unbound-ary.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/cxx20-p0388-unbound-ary.cpp
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 %s -triple %itanium_abi_triple -std=c++20 -emit-llvm -O2 -o - | FileCheck %s
+
+// p0388 conversions to unbounded array
+// dcl.init.list/3
+
+namespace One {
+int ga[1];
+
+// CHECK-LABEL: @_ZN3One5frob1Ev
+// CHECK-NEXT: entry:
+// CHECK-NEXT: ret [0 x i32]* bitcast ([1 x i32]* @_ZN3One2gaE to [0 x i32]*)
+auto &frob1() {
+  int(&r1)[] = ga;
+
+  return r1;
+}
+
+// CHECK-LABEL: @_ZN3One5frob2ERA1_i
+// CHECK-NEXT: entry:
+// CHECK-NEXT: %0 = bitcast [1 x i32]* %arp to [0 x i32]*
+// CHECK-NEXT: ret [0 x i32]* %0
+auto &frob2(int (&arp)[1]) {
+  int(&r2)[] = arp;
+
+  return r2;
+}
+} // namespace One
Index: clang/test/CXX/drs/dr3xx.cpp
===
--- clang/test/CXX/drs/dr3xx.cpp
+++ clang/test/CXX/drs/dr3xx.cpp
@@ -373,10 +373,19 @@
 q = p; // ok
 q2 = p; // ok
 r = p; // expected-error {{incompatible}}
-s = p; // expected-error {{incompatible}} (for now)
+s = p;
+#if __cplusplus < 202002
+// expected-error@-2 {{incompatible}} (fixed by p0388)
+#endif
 t = p; // expected-error {{incompatible}}
-s = q; // expected-error {{incompatible}}
-s = q2; // expected-error {{incompatible}}
+s = q;
+#if __cplusplus < 202002
+// expected-error@-2 {{incompatible}} (fixed by p0388)
+#endif
+s = q2;
+#if __cplusplus < 202002
+// expected-error@-2 {{incompatible}} (fixed by p0388)
+#endif
 s = t; // ok, adding const
 t = s; // expected-error {{discards qualifiers}}
 (void) const_cast(q);
Index: clang/lib/Sema/SemaOverload.cpp
===
--- clang/lib/Sema/SemaOverload.cpp
+++ clang/lib/Sema/SemaOverload.cpp
@@ -3246,6 +3246,19 @@
   !PreviousToQualsIncludeConst)
 return false;
 
+  // The following wording is from C++20, where the result of the conversion
+  // is T3, not T2.
+  //   -- if [...] P1,i [...] is "array of unknown bound of", P3,i is
+  //  "array of unknown bound of"
+  if (FromType->isIncompleteArrayType() && !ToType->isIncompleteArrayType())
+return false;
+
+  //   -- if the resulting P3,i is different from P1,i [...], then const is
+  //  added to every cv 3_k for 0 < k < 

[PATCH] D103908: [clang] p0388 array list initialization overloads

2021-10-12 Thread Nathan Sidwell 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 rG444ec0957c58: [clang] p0388 array list initialization 
overloads (authored by urnathan).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103908

Files:
  clang/include/clang/Sema/Overload.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/test/SemaCXX/cxx20-p0388-unbound-ary.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -1238,7 +1238,7 @@
 
   Permit conversions to arrays of unknown bound
   https://wg21.link/p0388r4";>P0388R4
-  No
+  Clang 13
 
 
   constinit
Index: clang/test/SemaCXX/cxx20-p0388-unbound-ary.cpp
===
--- clang/test/SemaCXX/cxx20-p0388-unbound-ary.cpp
+++ clang/test/SemaCXX/cxx20-p0388-unbound-ary.cpp
@@ -77,3 +77,97 @@
 }
 
 } // namespace Four
+
+namespace Five {
+// from the paper
+char (&b(int(&&)[]))[1];   // #1
+char (&b(long(&&)[]))[2];  // #2
+char (&b(int(&&)[1]))[3];  // #3
+char (&b(long(&&)[1]))[4]; // #4
+char (&b(int(&&)[2]))[5];  // #5
+#if __cplusplus < 202002
+// expected-note@-6{{cannot convert initializer}}
+// expected-note@-6{{cannot convert initializer}}
+// expected-note@-6{{too many initializers}}
+// expected-note@-6{{too many initializers}}
+// expected-note@-6{{too many initializers}}
+#endif
+
+void f() {
+  static_assert(sizeof(b({1})) == 3);
+  static_assert(sizeof(b({1, 2})) == 5);
+  static_assert(sizeof(b({1, 2, 3})) == 1);
+#if __cplusplus < 202002
+  // expected-error@-2{{no matching function}}
+#endif
+}
+} // namespace Five
+
+#if __cplusplus >= 202002
+namespace Six {
+// from over.ics.rank 3.1
+char (&f(int(&&)[]))[1];// #1
+char (&f(double(&&)[]))[2]; // #2
+char (&f(int(&&)[2]))[3];   // #3
+
+void toto() {
+  // Calls #1: Better than #2 due to conversion, better than #3 due to bounds
+  static_assert(sizeof(f({1})) == 1);
+
+  // Calls #2: Identity conversion is better than floating-integral conversion
+  static_assert(sizeof(f({1.0})) == 2);
+
+  // Calls #2: Identity conversion is better than floating-integral conversion
+  static_assert(sizeof(f({1.0, 2.0})) == 2);
+
+  // Calls #3: Converting to array of known bound is better than to unknown
+  //   bound, and an identity conversion is better than
+  //   floating-integral conversion
+  static_assert(sizeof(f({1, 2})) == 3);
+}
+
+} // namespace Six
+
+namespace Seven {
+
+char (&f(int(&&)[]))[1]; // #1
+char (&f(double(&&)[1]))[2]; // #2
+
+void quux() {
+  // Calls #2, float-integral conversion rather than create zero-sized array
+  static_assert(sizeof(f({})) == 2);
+}
+
+} // namespace Seven
+
+namespace Eight {
+
+// brace-elision is not a thing here:
+struct A {
+  int x, y;
+};
+
+char (&f1(int(&&)[]))[1]; // #1
+char (&f1(A(&&)[]))[2];   // #2
+
+void g1() {
+  // pick #1, even though that is more elements than #2
+  // 6 ints, as opposed to 3 As
+  static_assert(sizeof(f1({1, 2, 3, 4, 5, 6})) == 1);
+}
+
+void f2(A(&&)[]); // expected-note{{candidate function not viable}}
+void g2() {
+  f2({1, 2, 3, 4, 5, 6}); // expected-error{{no matching function}}
+}
+
+void f3(A(&&)[]);
+void g3() {
+  auto &f = f3;
+
+  f({1, 2, 3, 4, 5, 6}); // OK! We're coercing to an already-selected function
+}
+
+} // namespace Eight
+
+#endif
Index: clang/lib/Sema/SemaOverload.cpp
===
--- clang/lib/Sema/SemaOverload.cpp
+++ clang/lib/Sema/SemaOverload.cpp
@@ -3820,8 +3820,8 @@
   //   if not that,
   // — L1 and L2 convert to arrays of the same element type, and either the
   //   number of elements n_1 initialized by L1 is less than the number of
-  //   elements n_2 initialized by L2, or (unimplemented:C++20) n_1 = n_2 and L2
-  //   converts to an array of unknown bound and L1 does not,
+  //   elements n_2 initialized by L2, or (C++20) n_1 = n_2 and L2 converts to
+  //   an array of unknown bound and L1 does not,
   // even if one of the other rules in this paragraph would otherwise apply.
   if (!ICS1.isBad()) {
 bool StdInit1 = false, StdInit2 = false;
@@ -3840,13 +3840,23 @@
   if (auto *CAT1 = S.Context.getAsConstantArrayType(
   ICS1.getInitializerListContainerType()))
 if (auto *CAT2 = S.Context.getAsConstantArrayType(
-ICS2.getInitializerListContainerType()))
+ICS2.getInitializerListContainerType())) {
   if (S.Context.hasSameUnqualifiedType(CAT1->getElementType(),
-   CAT2->getElementType()) &&
-  C

[PATCH] D109174: [MSP430][Clang] Infer CPU type from -mcpu= or -mmcu=

2021-10-12 Thread Jozef Lawrynowicz via Phabricator via cfe-commits
jozefl updated this revision to Diff 379034.
jozefl added a comment.

Rebase onto new base revision to fix pre-merge tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109174

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/lib/Basic/Targets/MSP430.cpp
  clang/lib/Basic/Targets/MSP430.h
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/lib/Driver/ToolChains/MSP430.cpp
  clang/lib/Driver/ToolChains/MSP430.h
  clang/test/Driver/msp430-cpu.c
  clang/test/Driver/msp430-mmcu.c
  clang/test/Driver/msp430-toolchain.c
  clang/test/Misc/target-invalid-cpu-note.c
  clang/test/Preprocessor/msp430-defs.c
  llvm/lib/Target/MSP430/MSP430.td
  llvm/lib/Target/MSP430/MSP430Subtarget.cpp
  llvm/lib/Target/MSP430/MSP430Subtarget.h
  llvm/test/CodeGen/MSP430/build-attrs.ll

Index: llvm/test/CodeGen/MSP430/build-attrs.ll
===
--- llvm/test/CodeGen/MSP430/build-attrs.ll
+++ llvm/test/CodeGen/MSP430/build-attrs.ll
@@ -8,6 +8,8 @@
 ; RUN:   | llvm-readelf -A - | FileCheck %s --check-prefixes COMMON,MSP430,SMALL
 ; RUN: llc -mtriple=msp430 -mcpu=msp430x -filetype=obj < %s \
 ; RUN:   | llvm-readelf -A - | FileCheck %s --check-prefixes COMMON,MSP430X,SMALL
+; RUN: llc -mtriple=msp430 -mcpu=msp430xv2 -filetype=obj < %s \
+; RUN:   | llvm-readelf -A - | FileCheck %s --check-prefixes COMMON,MSP430X,SMALL
 
 ; COMMON: BuildAttributes {
 ; COMMON: FormatVersion: 0x41
Index: llvm/lib/Target/MSP430/MSP430Subtarget.h
===
--- llvm/lib/Target/MSP430/MSP430Subtarget.h
+++ llvm/lib/Target/MSP430/MSP430Subtarget.h
@@ -36,7 +36,7 @@
 
 private:
   virtual void anchor();
-  bool ExtendedInsts = false;
+  bool MSP430X = false;
   HWMultEnum HWMultMode = NoHWMult;
   MSP430FrameLowering FrameLowering;
   MSP430InstrInfo InstrInfo;
@@ -60,6 +60,8 @@
   bool hasHWMult32() const { return HWMultMode == HWMult32; }
   bool hasHWMultF5() const { return HWMultMode == HWMultF5; }
 
+  bool hasMSP430X() const { return MSP430X; }
+
   const TargetFrameLowering *getFrameLowering() const override {
 return &FrameLowering;
   }
Index: llvm/lib/Target/MSP430/MSP430Subtarget.cpp
===
--- llvm/lib/Target/MSP430/MSP430Subtarget.cpp
+++ llvm/lib/Target/MSP430/MSP430Subtarget.cpp
@@ -40,9 +40,6 @@
 
 MSP430Subtarget &
 MSP430Subtarget::initializeSubtargetDependencies(StringRef CPU, StringRef FS) {
-  ExtendedInsts = false;
-  HWMultMode = NoHWMult;
-
   StringRef CPUName = CPU;
   if (CPUName.empty())
 CPUName = "msp430";
Index: llvm/lib/Target/MSP430/MSP430.td
===
--- llvm/lib/Target/MSP430/MSP430.td
+++ llvm/lib/Target/MSP430/MSP430.td
@@ -18,8 +18,8 @@
 // Subtarget Features. 
 //===--===//
 def FeatureX
- : SubtargetFeature<"ext", "ExtendedInsts", "true",
-"Enable MSP430-X extensions">;
+ : SubtargetFeature<"msp430x", "MSP430X", "true",
+"Enable MSP430X extensions">;
 
 def FeatureHWMult16
  : SubtargetFeature<"hwmult16", "HWMultMode", "HWMult16",
@@ -42,6 +42,7 @@
 def : Proc<"generic", []>;
 def : Proc<"msp430",  []>;
 def : Proc<"msp430x", [FeatureX]>;
+def : Proc<"msp430xv2",   [FeatureX]>;
 
 //===--===//
 // Register File Description
Index: clang/test/Preprocessor/msp430-defs.c
===
--- /dev/null
+++ clang/test/Preprocessor/msp430-defs.c
@@ -0,0 +1,20 @@
+// Check the correct macros are defined for each CPU.
+
+// RUN: %clang -target msp430 -x c -E -dM %s -o - | FileCheck  %s
+// RUN: %clang -target msp430 -mcpu=generic -x c -E -dM %s -o - | FileCheck %s
+// RUN: %clang -target msp430 -mcpu=msp430 -x c -E -dM %s -o - | FileCheck %s
+
+// CHECK: MSP430
+// CHECK: __ELF__
+// CHECK-NOT: __MSP430X__
+// CHECK: __MSP430__
+
+// RUN: %clang -target msp430 -mcpu=msp430x -x c -E -dM %s -o - \
+// RUN:   | FileCheck --check-prefix=MSP430X %s
+// RUN: %clang -target msp430 -mcpu=msp430xv2 -x c -E -dM %s -o - \
+// RUN:   | FileCheck --check-prefix=MSP430X %s
+
+// MSP430X: MSP430
+// MSP430X: __ELF__
+// MSP430X: __MSP430X__
+// MSP430X: __MSP430__
Index: clang/test/Misc/target-invalid-cpu-note.c
===
--- clang/test/Misc/target-invalid-cpu-note.c
+++ clang/test/Misc/target-invalid-cpu-note.c
@@ -94,3 +94,7 @@
 // RUN: not %clang_cc1 -triple riscv64 -tune-cpu not-a-cpu -fsyntax-only %s 2>&1 | FileCheck %s --check-prefix TUNE-RISCV64
 // TUNE-RISCV64: error: unknown target CPU 'not-a-cpu'
 // TUNE-RISCV64-NEXT: note: valid target CPU valu

[PATCH] D110357: [Analyzer] Extend ConstraintAssignor to handle remainder op

2021-10-12 Thread Gabor Marton via Phabricator via cfe-commits
martong updated this revision to Diff 379039.
martong marked 11 inline comments as done.
martong added a comment.

- Handle a % b == 0 implies that a == 0.
- Add more test cases


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110357

Files:
  
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  clang/test/Analysis/constraint-assignor.c

Index: clang/test/Analysis/constraint-assignor.c
===
--- /dev/null
+++ clang/test/Analysis/constraint-assignor.c
@@ -0,0 +1,57 @@
+// RUN: %clang_analyze_cc1 %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=debug.ExprInspection \
+// RUN:   -verify
+
+// expected-no-diagnostics
+
+void clang_analyzer_warnIfReached();
+
+void rem_constant_rhs_eq_zero(int x, int y) {
+  if (x % 3 != 0) // x % 3 == 0 -> x == 0
+return;
+  if (x * y == 0) // x * y != 0 -> contradiction
+return;
+  clang_analyzer_warnIfReached(); // no-warning
+  (void)x; // keep the constraints alive.
+}
+
+void rem_symbolic_rhs_eq_zero(int x, int y, int z) {
+  if (x % z != 0) // x % z == 0 -> x == 0
+return;
+  if (x * y == 0) // x * y != 0 -> contradiction
+return;
+  clang_analyzer_warnIfReached(); // no-warning
+  (void)x; // keep the constraints alive.
+}
+
+void rem_constant_rhs_ne_zero(int x, int y) {
+  if (x % 3 == 0) // x % 3 != 0 -> x != 0
+return;
+  if (x * y != 0) // x * y == 0
+return;
+  if (y != 1) // y == 1 -> x == 0
+return;
+  clang_analyzer_warnIfReached(); // no-warning
+  (void)x; // keep the constraints alive.
+}
+
+void rem_symbolic_rhs_ne_zero(int x, int y, int z) {
+  if (x % z == 0) // x % z != 0 -> x != 0
+return;
+  if (x * y != 0) // x * y == 0
+return;
+  if (y != 1) // y == 1 -> x == 0
+return;
+  clang_analyzer_warnIfReached(); // no-warning
+  (void)x; // keep the constraints alive.
+}
+
+void rem_symbolic_rhs_eq_zero_nested(int w, int x, int y, int z) {
+  if (w % x % z != 0) // w % x % z == 0 -> w % x == 0
+return;
+  if (w % x * y == 0) // w % x * y != 0 -> contradiction
+return;
+  clang_analyzer_warnIfReached(); // no-warning
+  (void)(w * x); // keep the constraints alive.
+}
Index: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -1610,7 +1610,29 @@
 return Assignor.assign(CoS, NewConstraint);
   }
 
+  /// Handle expressions like: a % b == 0.
+  /// E.g., a % b != 0 implies that a != 0.
+  template 
+  bool handleRemainderOp(const SymT *Sym, RangeSet Constraint) {
+if (Sym->getOpcode() != BO_Rem)
+  return true;
+const SymExpr *LHS = Sym->getLHS();
+const llvm::APSInt &Zero =
+Builder.getBasicValueFactory().getValue(0, LHS->getType());
+if (Constraint.containsZero())
+  State = RCM.assumeSymEQ(State, LHS, Zero, Zero);
+else
+  State = RCM.assumeSymNE(State, LHS, Zero, Zero);
+if (!State)
+  return false;
+return true;
+  }
+
   inline bool assignSymExprToConst(const SymExpr *Sym, Const Constraint);
+  inline bool assignSymIntExprToRangeSet(const SymIntExpr *Sym,
+ RangeSet Constraint) {
+return handleRemainderOp(Sym, Constraint);
+  }
   inline bool assignSymSymExprToRangeSet(const SymSymExpr *Sym,
  RangeSet Constraint);
 
@@ -1688,9 +1710,7 @@
 if (Constraint.getConcreteValue())
   return !Constraint.getConcreteValue()->isZero();
 
-APSIntType T{Constraint.getMinValue()};
-Const Zero = T.getZeroValue();
-if (!Constraint.contains(Zero))
+if (!Constraint.containsZero())
   return true;
 
 return llvm::None;
@@ -1734,6 +1754,9 @@
 
 bool ConstraintAssignor::assignSymSymExprToRangeSet(const SymSymExpr *Sym,
 RangeSet Constraint) {
+  if (!handleRemainderOp(Sym, Constraint))
+return false;
+
   Optional ConstraintAsBool = interpreteAsBool(Constraint);
 
   if (!ConstraintAsBool)
Index: clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h
===
--- clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h
+++ clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h
@@ -282,6 +282,11 @@
   /// where N = size(this)
   bool contains(llvm::APSInt Point) const { return containsImpl(Point); }
 
+  bool containsZero() const {
+APSIntType T{getMinValue()};
+return contains(T.getZeroValue());
+  }
+
   void dump(raw_ostream &OS) const;
   void dump() const;
 

[PATCH] D110357: [Analyzer] Extend ConstraintAssignor to handle remainder op

2021-10-12 Thread Gabor Marton via Phabricator via cfe-commits
martong added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:1603-1604
 
+  template 
+  bool handleRem(const SymT *Sym, RangeSet Constraint) {
+// a % b != 0 implies that a != 0.

ASDenysPetrov wrote:
> steakhal wrote:
> > Why is this not a `const` member function?
> IMO it's better to rename the function `handleRemainderOp`.
> 
> Add a function description in comments above. 
> E.g. Handle expressions like: `a % b == 0`. ... Returns `true` when 
> //bla-bla//, otherwise returns `false`.
> Why is this not a const member function?
Because `RCM.assumeSymNE` is not `const`.

> IMO it's better to rename the function handleRemainderOp.
I agree, changed it.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:1605
+  bool handleRem(const SymT *Sym, RangeSet Constraint) {
+// a % b != 0 implies that a != 0.
+if (Sym->getOpcode() != BO_Rem)

steakhal wrote:
> I think you should also implement `a % b == 0 implies that a == 0`.
Good point, I've just added that.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:1609-1612
+  const SymExpr *LHS = Sym->getLHS();
+  const llvm::APSInt &Zero =
+  Builder.getBasicValueFactory().getValue(0, LHS->getType());
+  State = RCM->assumeSymNE(State, LHS, Zero, Zero);

steakhal wrote:
> ASDenysPetrov wrote:
> > Maybe make some more complex assumptions to cover complex **LHS's**?
> Oh nice.
`State->assume` goes through many higher level abstractions and finally calls 
`assumeSymNE`, so I think calling that would be a pessimization in this case.



Comment at: clang/test/Analysis/constraint-assignor.c:30
+  (void)x; // keep the constraints alive.
+}

ASDenysPetrov wrote:
> Add some nested cases like `x % y % z == 0`.
Good point! I've added one such test case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110357

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


[PATCH] D111648: [clangd] TargetFinder: Fix assert-crash on TemplateExpansion args.

2021-10-12 Thread Adam Czachorowski via Phabricator via cfe-commits
adamcz created this revision.
adamcz added a reviewer: nridge.
Herald added subscribers: usaxena95, kadircet, arphaman.
adamcz requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang-tools-extra.

Previously we would call getAsTemplate() when kind == TemplateExpansion,
which triggers an assertion. The call is now replaced with
getAsTemplateOrTemplatePattern(), which is exactly the same as
getAsTemplate(), except it allows calls when kind == TemplateExpansion.

No change in behavior for no-assert builds.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D111648

Files:
  clang-tools-extra/clangd/FindTarget.cpp
  clang-tools-extra/clangd/unittests/FindTargetTests.cpp


Index: clang-tools-extra/clangd/unittests/FindTargetTests.cpp
===
--- clang-tools-extra/clangd/unittests/FindTargetTests.cpp
+++ clang-tools-extra/clangd/unittests/FindTargetTests.cpp
@@ -341,6 +341,15 @@
   EXPECT_DECLS("TemplateSpecializationTypeLoc", "template  class T");
   Flags.clear();
 
+  Code = R"cpp(
+  template class ...T>
+  class C {
+C<[[T...]]> foo;
+};
+  )cpp";
+  EXPECT_DECLS("TemplateArgumentLoc", {"template  class ...T"});
+  Flags.clear();
+
   Code = R"cpp(
 struct S{};
 S X;
Index: clang-tools-extra/clangd/FindTarget.cpp
===
--- clang-tools-extra/clangd/FindTarget.cpp
+++ clang-tools-extra/clangd/FindTarget.cpp
@@ -507,7 +507,8 @@
 // DeclRefExpr).
 if (Arg.getKind() == TemplateArgument::Template ||
 Arg.getKind() == TemplateArgument::TemplateExpansion) {
-  if (TemplateDecl *TD = Arg.getAsTemplate().getAsTemplateDecl()) {
+  if (TemplateDecl *TD =
+  Arg.getAsTemplateOrTemplatePattern().getAsTemplateDecl()) {
 report(TD, Flags);
   }
 }


Index: clang-tools-extra/clangd/unittests/FindTargetTests.cpp
===
--- clang-tools-extra/clangd/unittests/FindTargetTests.cpp
+++ clang-tools-extra/clangd/unittests/FindTargetTests.cpp
@@ -341,6 +341,15 @@
   EXPECT_DECLS("TemplateSpecializationTypeLoc", "template  class T");
   Flags.clear();
 
+  Code = R"cpp(
+  template class ...T>
+  class C {
+C<[[T...]]> foo;
+};
+  )cpp";
+  EXPECT_DECLS("TemplateArgumentLoc", {"template  class ...T"});
+  Flags.clear();
+
   Code = R"cpp(
 struct S{};
 S X;
Index: clang-tools-extra/clangd/FindTarget.cpp
===
--- clang-tools-extra/clangd/FindTarget.cpp
+++ clang-tools-extra/clangd/FindTarget.cpp
@@ -507,7 +507,8 @@
 // DeclRefExpr).
 if (Arg.getKind() == TemplateArgument::Template ||
 Arg.getKind() == TemplateArgument::TemplateExpansion) {
-  if (TemplateDecl *TD = Arg.getAsTemplate().getAsTemplateDecl()) {
+  if (TemplateDecl *TD =
+  Arg.getAsTemplateOrTemplatePattern().getAsTemplateDecl()) {
 report(TD, Flags);
   }
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D111648: [clangd] TargetFinder: Fix assert-crash on TemplateExpansion args.

2021-10-12 Thread Adam Czachorowski via Phabricator via cfe-commits
adamcz added a comment.

Hi Nathan

Would you mind reviewing this change? It's related to your 
https://reviews.llvm.org/D85503

Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111648

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


[PATCH] D111640: [Analyzer][NFC] Add RangedConstraintManager to ConstraintAssignor

2021-10-12 Thread Gabor Marton via Phabricator via cfe-commits
martong added a comment.

In D111640#3058304 , @steakhal wrote:

> It looks good.
> Do you think we could remove the `RangedConstraintManager` abstraction?

Definitely. What's more, we could split out cohesive implementation details 
like `RangeSet`, `EquivalenceClass` from `RangeConstraintManager.cpp` into 
their own implementation files.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111640

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


[PATCH] D111529: Specify Clang vector builtins.

2021-10-12 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added inline comments.



Comment at: clang/docs/LanguageExtensions.rst:552
+operation(x, y) as pairwise tree reduction to the input. The pairs are formed
+by concatenating both inputs and pairing adjacent elements.
+

fhahn wrote:
> craig.topper wrote:
> > I'm not sure I understand what is being concatenated here.
> I tried to spell it out more clearly. I'm still not sure if that spells it 
> out as clearly as possibly and I'd appreciate any suggestions on how to 
> improve the wording.
The input is a single vector. I'm not understanding where we get a second 
vector to concatenate.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111529

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


[PATCH] D110357: [Analyzer] Extend ConstraintAssignor to handle remainder op

2021-10-12 Thread Denys Petrov via Phabricator via cfe-commits
ASDenysPetrov added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:1609-1612
+  const SymExpr *LHS = Sym->getLHS();
+  const llvm::APSInt &Zero =
+  Builder.getBasicValueFactory().getValue(0, LHS->getType());
+  State = RCM->assumeSymNE(State, LHS, Zero, Zero);

martong wrote:
> steakhal wrote:
> > ASDenysPetrov wrote:
> > > Maybe make some more complex assumptions to cover complex **LHS's**?
> > Oh nice.
> `State->assume` goes through many higher level abstractions and finally calls 
> `assumeSymNE`, so I think calling that would be a pessimization in this case.
I agree, but then you lose an internal simplification of LHS symbol.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110357

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


[PATCH] D111640: [Analyzer][NFC] Add RangedConstraintManager to ConstraintAssignor

2021-10-12 Thread Denys Petrov via Phabricator via cfe-commits
ASDenysPetrov added a comment.

In D111640#3058622 , @martong wrote:

> In D111640#3058304 , @steakhal 
> wrote:
>
>> It looks good.
>> Do you think we could remove the `RangedConstraintManager` abstraction?
>
> Definitely. What's more, we could split out cohesive implementation details 
> like `RangeSet`, `EquivalenceClass` from `RangeConstraintManager.cpp` into 
> their own implementation files.

Sound thought! +1


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111640

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


[PATCH] D110065: [AArch64] Add support for the 'R' architecture profile.

2021-10-12 Thread John Brawn via Phabricator via cfe-commits
john.brawn added inline comments.



Comment at: llvm/lib/Target/AArch64/MCTargetDesc/AArch64InstPrinter.cpp:1548
+
+static const AArch64SysReg::SysReg *lookupSysReg(unsigned Val, bool Read,
+ const MCSubtargetInfo &STI) {

It would be better if we had a generic way to handle registers with overlapping 
encodings, instead of handling the two registers explicitly here. I'm not sure 
of the best way to do that, but looking at AArch64SystemOperands.td it looks 
like maybe a way to do it would to add an extra "AltName" field to give an 
alternate name for the same encoding, so e.g. TTBR0_EL2 would have AltName 
VSCTLR_EL2 and vice-versa. So you'd first lookup by encoding, then if that 
didn't work you'd lookup by name with AltName and check if that one is valid.



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

https://reviews.llvm.org/D110065

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


[PATCH] D110913: [analyzer][solver] Handle simplification to ConcreteInt

2021-10-12 Thread Balázs Benics via Phabricator via cfe-commits
steakhal added a comment.

Looks good to me. I very much like this.
Check my nits inline. Given those are fixed I'm gonna accept this.




Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h:392-397
+/// Try to simplify a given symbolic expression based on the constraints in
+/// State. This is needed because the Environment bindings are not getting
+/// updated when a new constraint is added to the State. If the symbol is
+/// simplified to a non-symbol (e.g. to a constant) then the original symbol
+/// is returned.
 SymbolRef simplify(ProgramStateRef State, SymbolRef Sym);

Okay, I like it!
However, it's still not entirely clear to me *when* to use which.
Could you clarify that aspect too?
Sorry for being picky but I'm not an expert on this part of the code and if 
it's not clear to me, it probably won't be clear to newcomers either.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:2110
+
+SymbolRef SimplifiedMemberSym = nullptr;
+SVal SimplifiedMemberVal = simplifyToSVal(State, MemberSym);

By initializing it here, it will be much cleaner:
1) It's not mutated, thus it can be `const`
2) We can spare the `else` branch.

Also consider marking the rest of the variables `const`, so that the lack of 
constness would actually suggest mutability.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:2112
+SVal SimplifiedMemberVal = simplifyToSVal(State, MemberSym);
+if (const auto CI = SimplifiedMemberVal.getAs()) {
+  const llvm::APSInt &SV = CI->getValue();

I think a comment would be appreciated describing that we only look for 
infeasibility here, nothing else.
Thus, the //fallthrough// in the feasible case is intentional.



Comment at: clang/test/Analysis/solver-sym-simplification-concreteint.c:17
+return;
+  clang_analyzer_warnIfReached(); // expected-no-diagnostics
+

Consider following the convention and using the `// no-warning` comment instead.
I'm also requesting an additional test case, exercising the fallthrough 
behavior I stated in an earlier comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110913

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


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

2021-10-12 Thread Matheus Izvekov via Phabricator via cfe-commits
mizvekov added a comment.

In D111283#3056748 , @rsmith wrote:

> Do you have examples showing what this does in practice for errors in 
> real-world code? I'm concerned that stripping back to the common type sugar 
> may produce an unintuitive result in some cases, although it certainly does 
> seem at least theoretically nice to use a commutative and associative 
> function to combine deductions like this. The kind of thing I'd be worried 
> about would be (eg) a container where the `iterator` and `const_iterator` are 
> the same, but where the common sugar of `T::iterator` and `T::const_iterator` 
> are some internal type that the user has never heard of. In general it seems 
> like this sugar stripping could result in types that are distant from the 
> user's code. As an extreme example, in the case where one of the types is 
> canonical and the other is not, it seems like stripping all the way back to 
> the canonical type would be worse than ignoring the canonical version of the 
> type and keeping the sugared version.

I don't have handy access to very large code bases where this could be deployed 
experimentally, but this is something I can try to look into.

> Perhaps we could treat canonical types as a special case (effectively 
> assuming they came from taking a type and canonicalizing it at some point, 
> rather than from a type the user wrote) and when combining two types, use the 
> non-canonical type if one of them is canonical, and otherwise use the common 
> sugar. That should still be commutative and associative and generally 
> well-behaved, but won't degrade badly when given a canonical type as input. I 
> think that still leaves the possibility of a surprising outcome when 
> combining types that both desugar to some internal type, though I'm not sure 
> what we can do about that other than make an arbitrary choice of which type 
> sugar we like more.

The thing I would be concerned with this special case is that it would also 
give surprising results, ie it could deduce that Socrates is a Dog.
I guess there are two use cases scenarios here, one where we have this 
transparent hierarchy, and this algorithm gives results that make intuitive 
sense,
and the other where we have some typedef which we want to be opaque in order to 
not expose internal details.

So exploring your example, suppose we try to deduce from an iterator and a 
const_iterator.
We have some options here:

- We deduce as either iterator or const_iterator. If there is an IS-A 
relationship between them, and we pick the right choice, then we pack up and go 
home, job well done. If there is no such relationship, neither answer seems 
right.
- We deduce the canonical type, which might be something like `struct 
vendor::detail::Foo *`. This exposes internal details, but at least it has some 
vocabulary information, so you know this is a pointer to an object of some 
internal class. It's not good from a user friendliness PoV, but it's good from 
a 'I want to debug this thing' perspective.
- We deduce to some type sugar which is meant to be internal, like 
`vendor::detail::iterator_t`. This is not very good, maybe it's worse from a 
user friendliness PoV than the bullet point above as we expose even more 
internal details. But maybe in some cases it's better as the vendor can also 
pick a name for the typedef which is more explanatory than the the canonical 
type, which will still be available in the 'aka', so from the debuggability 
perspective this also seems better.
- We create some new type sugar which wraps the information that some type was 
deduced from two other types. This might be too much information overload, and 
we still need to have an answer to the 'single step desugar' of it, so I am not 
exploring this much further for now ;)

The problem of hiding internal details in error messages is a general problem, 
that maybe this solution would make a bit worse in some cases,
but that also means that solutions to the general problem can also remedy the 
problems we cause here.
One such idea (not proposing formally, just giving an example) would be an 
attribute on typedefs which hides the underlying sugar,
making it AS-IF the typedef was written on the canonical type. But it would 
still not hide the canonical type which is also
implementation detail, so not a huge win.

Going back to the 'treat canonical types as not written' workaround, I think 
there are too many cases where we are doing the wrong thing here in clang.
Basically any type written bare without any name / keyword qualifiers will not 
be treated by some ElaboratedType like mechanism. I suppose that as we fix
those problems, the need for this workaround will sort of disappear. I am not 
too opposed to it, but I think it might be better to give less, but more 
correct information, than
to some times make wild guesses ;-P

> I've not yet done any detailed review of the common type sugar computation 
> mechanism.

[PATCH] D111062: [RISCV] Rename some assembler mnemonic and intrinsic functions for RVV 1.0.

2021-10-12 Thread Jessica Clarke via Phabricator via cfe-commits
jrtc27 added inline comments.



Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoV.td:1378
+def : InstAlias<"vmornot.mm $vd, $vs2, $vs1",
+(VMORN_MM VR:$vd, VR:$vs2, VR:$vs1), 0>;
+

Ugh, spec mandating aliases for the pre-ratified names... this is just going to 
encourage people who don't know any better to use the old names and you'll 
never be able to kill it off :(



Comment at: llvm/test/CodeGen/RISCV/rvv/fixed-vectors-mask-logic.ll:1
-; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
-; RUN: llc -mtriple=riscv32 -mattr=+experimental-v 
-riscv-v-vector-bits-min=128 -verify-machineinstrs < %s | FileCheck %s
-; RUN: llc -mtriple=riscv64 -mattr=+experimental-v 
-riscv-v-vector-bits-min=128 -verify-machineinstrs < %s | FileCheck %s
-; RUN: llc -mtriple=riscv32 -mattr=+experimental-v 
-riscv-v-vector-bits-min=128 -verify-machineinstrs < %s | FileCheck %s
+  ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+  ; RUN: llc -mtriple=riscv32 -mattr=+experimental-v 
-riscv-v-vector-bits-min=128 -verify-machineinstrs < %s | FileCheck %s

Revert

(how do you even manage that, the NOTE line is autogenerated...)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111062

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


  1   2   >