[PATCH] D139395: Add support for integer types normalization

2022-12-05 Thread Ramon de C Valle via Phabricator via cfe-commits
rcvalle updated this revision to Diff 480349.
rcvalle retitled this revision from "Add support for integer types 
notmalization" to "Add support for integer types normalization".
rcvalle added a comment.

Fixed typo in commit message


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139395

Files:
  clang/include/clang/AST/Mangle.h
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/include/clang/Driver/SanitizerArgs.h
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/MicrosoftMangle.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/Driver/SanitizerArgs.cpp
  clang/test/CodeGen/cfi-icall-normalize.c

Index: clang/test/CodeGen/cfi-icall-normalize.c
===
--- /dev/null
+++ clang/test/CodeGen/cfi-icall-normalize.c
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-linux -fsanitize=cfi-icall -fsanitize-trap=cfi-icall -fsanitize-cfi-icall-normalize-integers -emit-llvm -o - %s | FileCheck %s
+
+// Test that integer types are normalized for cross-language CFI support with
+// other languages that can't represent and encode C/C++ integer types.
+
+// CHECK: define{{.*}}foo{{.*}}!type ![[TYPE1:[0-9]+]]{{.*}}!type ![[TYPE2:[0-9]+]]
+int foo(char arg1, short arg2) {
+  return 0;
+}
+
+void bar(int (*fn)(char arg1, short arg2)) {
+  // CHECK: call i1 @llvm.type.test(ptr {{.*}}, metadata !"_ZTSFu3i32u2i8u3i16E")
+  fn(0, 0);
+}
+
+// CHECK: ![[TYPE1]] = !{i64 0, !"_ZTSFu3i32u2i8u3i16E"}
+// CHECK: ![[TYPE2]] = !{i64 0, !"_ZTSFu3i32u2i8u3i16E.generalized"}
Index: clang/lib/Driver/SanitizerArgs.cpp
===
--- clang/lib/Driver/SanitizerArgs.cpp
+++ clang/lib/Driver/SanitizerArgs.cpp
@@ -715,6 +715,9 @@
 CfiICallGeneralizePointers =
 Args.hasArg(options::OPT_fsanitize_cfi_icall_generalize_pointers);
 
+CfiICallNormalizeIntegers =
+Args.hasArg(options::OPT_fsanitize_cfi_icall_normalize_integers);
+
 if (CfiCrossDso && CfiICallGeneralizePointers && DiagnoseErrors)
   D.Diag(diag::err_drv_argument_not_allowed_with)
   << "-fsanitize-cfi-cross-dso"
@@ -1218,6 +1221,9 @@
   if (CfiICallGeneralizePointers)
 CmdArgs.push_back("-fsanitize-cfi-icall-generalize-pointers");
 
+  if (CfiICallNormalizeIntegers)
+CmdArgs.push_back("-fsanitize-cfi-icall-normalize-integers");
+
   if (CfiCanonicalJumpTables)
 CmdArgs.push_back("-fsanitize-cfi-canonical-jump-tables");
 
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -6873,7 +6873,8 @@
   if (isExternallyVisible(T->getLinkage())) {
 std::string OutName;
 llvm::raw_string_ostream Out(OutName);
-getCXXABI().getMangleContext().mangleTypeName(T, Out);
+getCXXABI().getMangleContext().mangleTypeName(
+T, Out, !!getCodeGenOpts().SanitizeCfiICallNormalizeIntegers);
 Out << Suffix;
 
 InternalId = llvm::MDString::get(getLLVMContext(), Out.str());
Index: clang/lib/AST/MicrosoftMangle.cpp
===
--- clang/lib/AST/MicrosoftMangle.cpp
+++ clang/lib/AST/MicrosoftMangle.cpp
@@ -179,7 +179,8 @@
   int32_t VBPtrOffset, uint32_t VBIndex,
   raw_ostream &Out) override;
   void mangleCXXRTTI(QualType T, raw_ostream &Out) override;
-  void mangleCXXRTTIName(QualType T, raw_ostream &Out) override;
+  void mangleCXXRTTIName(QualType T, raw_ostream &Out,
+ bool NormalizeIntegers) override;
   void mangleCXXRTTIBaseClassDescriptor(const CXXRecordDecl *Derived,
 uint32_t NVOffset, int32_t VBPtrOffset,
 uint32_t VBTableOffset, uint32_t Flags,
@@ -192,7 +193,8 @@
   mangleCXXRTTICompleteObjectLocator(const CXXRecordDecl *Derived,
  ArrayRef BasePath,
  raw_ostream &Out) override;
-  void mangleTypeName(QualType T, raw_ostream &) override;
+  void mangleTypeName(QualType T, raw_ostream &,
+  bool NormalizeIntegers) override;
   void mangleReferenceTemporary(const VarDecl *, unsigned ManglingNumber,
 raw_ostream &) override;
   void mangleStaticGuardVariable(const VarDecl *D, raw_ostream &Out) override;
@@ -3585,8 +3587,8 @@
   Mangler.getStream() << "@8";
 }
 
-void MicrosoftMangleContextImpl::mangleCXXRTTIName(QualType T,
-   raw_ostream &Out) {
+void MicrosoftMangleContextImpl::mangleCXXRTTIName(
+QualType T, raw_ostream &Out, bool NormalizeIntegers = false) {
   MicrosoftCXXNameMangler Mangler(*this, Out);
   Mangler.getStream() << '.';
   Ma

[clang-tools-extra] 2402c46 - [clang-tools-extra] Use std::nullopt instead of llvm::None (NFC)

2022-12-05 Thread Kazu Hirata via cfe-commits

Author: Kazu Hirata
Date: 2022-12-05T23:55:23-08:00
New Revision: 2402c46b7155d04dc2a1ec618294fc6bb70f3e18

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

LOG: [clang-tools-extra] Use std::nullopt instead of llvm::None (NFC)

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

Added: 


Modified: 
clang-tools-extra/clang-tidy/utils/IncludeInserter.h
clang-tools-extra/clang-tidy/utils/NamespaceAliaser.h
clang-tools-extra/clang-tidy/utils/UsingInserter.h
clang-tools-extra/clangd/ConfigCompile.cpp
clang-tools-extra/clangd/DraftStore.h
clang-tools-extra/clangd/TUScheduler.cpp
clang-tools-extra/clangd/index/remote/server/Server.cpp

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/utils/IncludeInserter.h 
b/clang-tools-extra/clang-tidy/utils/IncludeInserter.h
index c5649177b2286..8e7c5f76ff80f 100644
--- a/clang-tools-extra/clang-tidy/utils/IncludeInserter.h
+++ b/clang-tools-extra/clang-tidy/utils/IncludeInserter.h
@@ -69,7 +69,7 @@ class IncludeInserter {
   /// Creates a \p Header inclusion directive fixit in the File \p FileID.
   /// When \p Header is enclosed in angle brackets, uses angle brackets in the
   /// inclusion directive, otherwise uses quotes.
-  /// Returns ``llvm::None`` on error or if the inclusion directive already
+  /// Returns ``std::nullopt`` on error or if the inclusion directive already
   /// exists.
   llvm::Optional createIncludeInsertion(FileID FileID,
llvm::StringRef Header);
@@ -77,7 +77,7 @@ class IncludeInserter {
   /// Creates a \p Header inclusion directive fixit in the main file.
   /// When \p Header is enclosed in angle brackets, uses angle brackets in the
   /// inclusion directive, otherwise uses quotes.
-  /// Returns ``llvm::None`` on error or if the inclusion directive already
+  /// Returns ``std::nullopt`` on error or if the inclusion directive already
   /// exists.
   llvm::Optional
   createMainFileIncludeInsertion(llvm::StringRef Header);

diff  --git a/clang-tools-extra/clang-tidy/utils/NamespaceAliaser.h 
b/clang-tools-extra/clang-tidy/utils/NamespaceAliaser.h
index ab1b9781c0d22..177b0980c7459 100644
--- a/clang-tools-extra/clang-tidy/utils/NamespaceAliaser.h
+++ b/clang-tools-extra/clang-tidy/utils/NamespaceAliaser.h
@@ -27,7 +27,7 @@ class NamespaceAliaser {
   explicit NamespaceAliaser(const SourceManager &SourceMgr);
   // Adds a namespace alias for \p Namespace valid near \p
   // Statement. Picks the first available name from \p Abbreviations.
-  // Returns ``llvm::None`` if an alias already exists or there is an error.
+  // Returns ``std::nullopt`` if an alias already exists or there is an error.
   llvm::Optional
   createAlias(ASTContext &Context, const Stmt &Statement,
   llvm::StringRef Namespace,

diff  --git a/clang-tools-extra/clang-tidy/utils/UsingInserter.h 
b/clang-tools-extra/clang-tidy/utils/UsingInserter.h
index 9d3c60ca59d07..dfdf5ed3488c9 100644
--- a/clang-tools-extra/clang-tidy/utils/UsingInserter.h
+++ b/clang-tools-extra/clang-tidy/utils/UsingInserter.h
@@ -26,7 +26,7 @@ class UsingInserter {
 public:
   UsingInserter(const SourceManager &SourceMgr);
 
-  // Creates a \p using declaration fixit. Returns ``llvm::None`` on error
+  // Creates a \p using declaration fixit. Returns ``std::nullopt`` on error
   // or if the using declaration already exists.
   llvm::Optional
   createUsingDeclaration(ASTContext &Context, const Stmt &Statement,

diff  --git a/clang-tools-extra/clangd/ConfigCompile.cpp 
b/clang-tools-extra/clangd/ConfigCompile.cpp
index a663e5a04f956..bdcafd1449421 100644
--- a/clang-tools-extra/clangd/ConfigCompile.cpp
+++ b/clang-tools-extra/clangd/ConfigCompile.cpp
@@ -171,7 +171,7 @@ struct FragmentCompiler {
   };
 
   // Attempt to parse a specified string into an enum.
-  // Yields llvm::None and produces a diagnostic on failure.
+  // Yields std::nullopt and produces a diagnostic on failure.
   //
   // Optional Value = compileEnum("Foo", Frag.Foo)
   //.map("Foo", Enum::Foo)

diff  --git a/clang-tools-extra/clangd/DraftStore.h 
b/clang-tools-extra/clangd/DraftStore.h
index 0bc860718fc73..9a46926214968 100644
--- a/clang-tools-extra/clangd/DraftStore.h
+++ b/clang-tools-extra/clangd/DraftStore.h
@@ -32,7 +32,7 @@ class DraftStore {
   };
 
   /// \return Contents of the stored document.
-  /// For untracked files, a llvm::None is returned.
+  /// For untracked files, a std::nullopt is returned.
   llvm::Optional getDraft(PathRef File) const;
 
   /// \return List of names of the drafts in this store.

diff  --git a/clang-tools-extra/clangd/TUScheduler.cpp 
b/clang-tools

[PATCH] D135247: [clang][analyzer] Add stream functions to StdLibraryFunctionsChecker.

2022-12-05 Thread Kristóf Umann via Phabricator via cfe-commits
Szelethus added a comment.

Do I understand correctly that for the time being, the strategy is to assume 
apiModeling to be enabled by default and not enforce it explicitly?

I suppose I have the ol' reliable question: did you evaluate this on any 
project yet?

In D135247#3839543 , @martong wrote:

>> The two checkers work together and 'apiModeling.StdCLibraryFunctions'
>> and its 'ModelPOSIX=true' option should be now a dependency of
>> checker 'alpha.unix.Stream'.
>
> Is there a way to stop the analysis with an error if "ModelPOSIX=true" is not 
> set but the  'alpha.unix.Stream' checker is enabled? @Szelethus, maybe you 
> have some insights with this?

The problem is, Dependencies and Weakdependencies both enforce a strict order 
of checker registration. What is discussed here is the following order:

1. StdCLibraryFunctionsChecker (modelling part)
2. StreamChecker
3. StdCLibraryFunctionArgsChecker (reporting part)

This falls apart because the modeling and reporting checkers are, in fact, the 
same checker in implementation. The "proper" solution would be to split up 
StdLibraryFunctions not in terms of a new checker entry in Checkers.td, but to 
split up the checker in implementation.




Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:786
   /// constraints (and different return value constraints).
-  const NoErrnoConstraint ErrnoIrrelevant{};
+  const NoErrnoConstraint ErrnoUnchanged{};
+  const ResetErrnoConstraint ErrnoIrrelevant{};

Hmm, do we need to specify this? Can't this be the default?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135247

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


[PATCH] D139395: Add support for integer types notmalization

2022-12-05 Thread Ramon de C Valle via Phabricator via cfe-commits
rcvalle created this revision.
Herald added a subscriber: JDevlieghere.
Herald added a project: All.
rcvalle requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.
Herald added a project: clang.

This commit adds support for normalizing integer types as vendor
extended types for cross-language LLVM CFI/KCFI support with other
languages that can't represent and encode C/C++ integer types.

This will help with providing cross-language CFI support with the Rust
compiler. For more information about LLVM CFI/KCFI and cross-language
LLVM CFI/KCFI support for the Rust compiler, see the design document in
the tracking issue rust-lang/rust#89653.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D139395

Files:
  clang/include/clang/AST/Mangle.h
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/include/clang/Driver/SanitizerArgs.h
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/MicrosoftMangle.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/Driver/SanitizerArgs.cpp
  clang/test/CodeGen/cfi-icall-normalize.c

Index: clang/test/CodeGen/cfi-icall-normalize.c
===
--- /dev/null
+++ clang/test/CodeGen/cfi-icall-normalize.c
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-linux -fsanitize=cfi-icall -fsanitize-trap=cfi-icall -fsanitize-cfi-icall-normalize-integers -emit-llvm -o - %s | FileCheck %s
+
+// Test that integer types are normalized for cross-language CFI support with
+// other languages that can't represent and encode C/C++ integer types.
+
+// CHECK: define{{.*}}foo{{.*}}!type ![[TYPE1:[0-9]+]]{{.*}}!type ![[TYPE2:[0-9]+]]
+int foo(char arg1, short arg2) {
+  return 0;
+}
+
+void bar(int (*fn)(char arg1, short arg2)) {
+  // CHECK: call i1 @llvm.type.test(ptr {{.*}}, metadata !"_ZTSFu3i32u2i8u3i16E")
+  fn(0, 0);
+}
+
+// CHECK: ![[TYPE1]] = !{i64 0, !"_ZTSFu3i32u2i8u3i16E"}
+// CHECK: ![[TYPE2]] = !{i64 0, !"_ZTSFu3i32u2i8u3i16E.generalized"}
Index: clang/lib/Driver/SanitizerArgs.cpp
===
--- clang/lib/Driver/SanitizerArgs.cpp
+++ clang/lib/Driver/SanitizerArgs.cpp
@@ -715,6 +715,9 @@
 CfiICallGeneralizePointers =
 Args.hasArg(options::OPT_fsanitize_cfi_icall_generalize_pointers);
 
+CfiICallNormalizeIntegers =
+Args.hasArg(options::OPT_fsanitize_cfi_icall_normalize_integers);
+
 if (CfiCrossDso && CfiICallGeneralizePointers && DiagnoseErrors)
   D.Diag(diag::err_drv_argument_not_allowed_with)
   << "-fsanitize-cfi-cross-dso"
@@ -1218,6 +1221,9 @@
   if (CfiICallGeneralizePointers)
 CmdArgs.push_back("-fsanitize-cfi-icall-generalize-pointers");
 
+  if (CfiICallNormalizeIntegers)
+CmdArgs.push_back("-fsanitize-cfi-icall-normalize-integers");
+
   if (CfiCanonicalJumpTables)
 CmdArgs.push_back("-fsanitize-cfi-canonical-jump-tables");
 
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -6873,7 +6873,8 @@
   if (isExternallyVisible(T->getLinkage())) {
 std::string OutName;
 llvm::raw_string_ostream Out(OutName);
-getCXXABI().getMangleContext().mangleTypeName(T, Out);
+getCXXABI().getMangleContext().mangleTypeName(
+T, Out, !!getCodeGenOpts().SanitizeCfiICallNormalizeIntegers);
 Out << Suffix;
 
 InternalId = llvm::MDString::get(getLLVMContext(), Out.str());
Index: clang/lib/AST/MicrosoftMangle.cpp
===
--- clang/lib/AST/MicrosoftMangle.cpp
+++ clang/lib/AST/MicrosoftMangle.cpp
@@ -179,7 +179,8 @@
   int32_t VBPtrOffset, uint32_t VBIndex,
   raw_ostream &Out) override;
   void mangleCXXRTTI(QualType T, raw_ostream &Out) override;
-  void mangleCXXRTTIName(QualType T, raw_ostream &Out) override;
+  void mangleCXXRTTIName(QualType T, raw_ostream &Out,
+ bool NormalizeIntegers) override;
   void mangleCXXRTTIBaseClassDescriptor(const CXXRecordDecl *Derived,
 uint32_t NVOffset, int32_t VBPtrOffset,
 uint32_t VBTableOffset, uint32_t Flags,
@@ -192,7 +193,8 @@
   mangleCXXRTTICompleteObjectLocator(const CXXRecordDecl *Derived,
  ArrayRef BasePath,
  raw_ostream &Out) override;
-  void mangleTypeName(QualType T, raw_ostream &) override;
+  void mangleTypeName(QualType T, raw_ostream &,
+  bool NormalizeIntegers) override;
   void mangleReferenceTemporary(const VarDecl *, unsigned ManglingNumber,
 raw_ostream &) override;
   void mangleStaticGuardVariable(const VarDecl *D, raw_ostream &Out) override;
@@ -3585,8 +3587,8 @@
   Man

[PATCH] D128677: [clang][Tooling] Add support for generating #import edits

2022-12-05 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added a comment.

thanks, mostly LG. some small changes.




Comment at: clang-tools-extra/clangd/IncludeFixer.cpp:261
 
   if (Symbol.empty())
+F.Message = llvm::formatv("{0} {1}",

nit: `llvm::StringLiteral DirectiveSpelling = Directive == 
tooling::IncludeDirective::Include ? "Include" : "Import";` and use that inside 
formatv calls



Comment at: clang-tools-extra/clangd/unittests/HeadersTests.cpp:340
+  Edit = insert("\"header.h\"", tooling::IncludeDirective::Import);
+  EXPECT_TRUE(Edit);
+  EXPECT_EQ(Edit->newText, "#import \"header.h\"\n");

nit: ASSERT_TRUE, here and above.



Comment at: clang/include/clang/Tooling/Inclusions/HeaderIncludes.h:47
 
+enum IncludeDirective { Include, Import };
+

this will leak enum values to the whole `clang::tooling` namespace. can you 
make this an `enum class IncludeDirective` instead (sorry for forgetting that 
in the initial comment)



Comment at: clang/include/clang/Tooling/Inclusions/HeaderIncludes.h:77
+  insert(llvm::StringRef Header, bool IsAngled,
+ IncludeDirective Directive = IncludeDirective::Include) const;
 

i don't think we have many callers here. can we just update them instead of 
defaulting to `Include` here?



Comment at: clang/include/clang/Tooling/Inclusions/HeaderIncludes.h:79
 
   /// Removes all existing #includes of \p Header quoted with <> if \p IsAngled
   /// is true or "" if \p IsAngled is false.

s/#includes/#includes and #imports/



Comment at: clang/lib/Tooling/Inclusions/HeaderIncludes.cpp:300
+  Offset, std::min(Line.size() + 1, Code.size() - Offset)),
+  Matches[1] == "include" ? tooling::IncludeDirective::Include
+  : tooling::IncludeDirective::Import),

i know this is not possible today, but just to be safe, can we actually check 
for `import` here and default to `include` ?



Comment at: clang/lib/Tooling/Inclusions/HeaderIncludes.cpp:354
   auto It = ExistingIncludes.find(IncludeName);
   if (It != ExistingIncludes.end())
 for (const auto &Inc : It->second)

nit: can you put some braces around the outermost `if`, as the statements 
inside are getting long.



Comment at: clang/lib/Tooling/Inclusions/HeaderIncludes.cpp:378
   assert(InsertOffset <= Code.size());
   std::string NewInclude =
+  Directive == IncludeDirective::Include

nit:
```
llvm::StringLiteral DirectiveSpelling = Directive == IncludeDirective::Include 
? "include" : "import";
std::string NewInclude = llvm::formatv("#{0} {1}\n", DirectiveSpelling, 
QuotedName); // this already has an implicit conversion operator to std::string
```



Comment at: clang/unittests/Tooling/HeaderIncludesTest.cpp:65
 
+TEST_F(HeaderIncludesTest, InsertImportWithSameInclude) {
+  std::string Code = "#include \"a.h\"\n";

can you also add a removal test?

i know we didn't change the implementation, but today there's nothing checking 
the behaviour. so explicitly encoding the expectation here, especially for the 
case where we have both #include and #import with same spelling is useful. btw 
is it likely that `#include "foo.h"` and `#import "foo.h"` can refer to 
different physical headers (e.g. due to framework handling and whatnot)?

we're not changing the behaviour today, but if there's a difference, this is 
likely a bug (that already exists), so we should leave a fixme (or address it 
here if you got time, by introducing a IncludeDirective parameter into remove. 
updating users is likely harder in this case, as everyone needs to 
propagate/store the directive during their analysis).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128677

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


[PATCH] D139302: [RISCV] Add Syntacore SCR1 CPU model

2022-12-05 Thread Dmitrii Petrov via Phabricator via cfe-commits
dnpetrov-sc added inline comments.



Comment at: llvm/lib/Target/RISCV/RISCV.td:637
+def : ProcessorModel<"scr1-min", SCR1Model,
+ [FeatureRV32E, FeatureStdExtC],
+ [TuneNoDefaultUnroll]>;

craig.topper wrote:
> Shouldn't this also need Feature32Bit?
Now, that's somewhat funny. Indeed, RISCVSubtarget has `HasRV32` field, but it 
is never queried. `IsRV32` predicate in RISCV.td is mapped to 
`!Subtarget->is64Bit()` in C++ code.

Code generation for RV32E is not implemented yet, though (and would error out 
in `RISCVTargetLowering`). I'll drop scr1-min for now.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139302

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


[PATCH] D137488: [clang][Interp] Array initialization via string literal

2022-12-05 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder added a comment.

@tahonermann Anything still missing here?


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

https://reviews.llvm.org/D137488

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


[PATCH] D134859: [clang][Interp] Implement basic support for floating point values

2022-12-05 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder added a comment.

Ping


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

https://reviews.llvm.org/D134859

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


[PATCH] D138200: [include-cleaner] Make use of locateSymbol in WalkUsed

2022-12-05 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added inline comments.



Comment at: clang-tools-extra/include-cleaner/lib/Analysis.cpp:44
+
+  // Cache for decl to header mappings, as the same decl might be referenced in
+  // multiple locations and finding providers for each location is expensive.

hokein wrote:
> I agree the place here might be on a performance-critical path, but I think 
> the idea of using cache probably needs some bits of design, the current 
> implementation seems half baked (there is also a FIXME in the findAllHeaders 
> saying we should implement another cache for it, so it is unclear to me 
> what's the whole picture).
> 
> Can we just leave out all cache in this patch with a FIXME? And having a 
> follow-up patch for that?
i agree that the cache for `findHeaders` is a bit more nuanced, as it'll need 
to have assumptions about a given `SymbolLocation`, no matter how/where it was 
acquired will return the same results.
but i am not sure what's complicated/unclear about the cache for decl to 
headers. The benefit is clear as explained in the comment around saving 
computations every time a `foo` is referenced inside the file.
Since both the benefit is clear and the assumption around "a `decl` having the 
same set of providers" sounds simple and sane enough, i'd actually keep this 
one in.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138200

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


[PATCH] D138200: [include-cleaner] Make use of locateSymbol in WalkUsed

2022-12-05 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet updated this revision to Diff 480340.
kadircet marked 3 inline comments as done.
kadircet added a comment.

- Address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138200

Files:
  clang-tools-extra/include-cleaner/lib/Analysis.cpp
  clang-tools-extra/include-cleaner/lib/HTMLReport.cpp
  clang-tools-extra/include-cleaner/test/Inputs/foo2.h
  clang-tools-extra/include-cleaner/test/html.cpp
  clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp

Index: clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp
===
--- clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp
+++ clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp
@@ -18,6 +18,7 @@
 #include "clang/Tooling/Inclusions/StandardLibrary.h"
 #include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/SmallVector.h"
+#include "llvm/Support/Error.h"
 #include "llvm/Testing/Support/Annotations.h"
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
@@ -25,6 +26,7 @@
 
 namespace clang::include_cleaner {
 namespace {
+using testing::Contains;
 using testing::Pair;
 using testing::UnorderedElementsAre;
 
@@ -32,8 +34,45 @@
   return "#pragma once\n" + Code.str();
 }
 
-TEST(WalkUsed, Basic) {
-  // FIXME: Have a fixture for setting up tests.
+class WalkUsedTest : public testing::Test {
+protected:
+  TestInputs Inputs;
+  PragmaIncludes PI;
+  WalkUsedTest() {
+Inputs.MakeAction = [this] {
+  struct Hook : public SyntaxOnlyAction {
+  public:
+Hook(PragmaIncludes *Out) : Out(Out) {}
+bool BeginSourceFileAction(clang::CompilerInstance &CI) override {
+  Out->record(CI);
+  return true;
+}
+
+PragmaIncludes *Out;
+  };
+  return std::make_unique(&PI);
+};
+  }
+
+  llvm::DenseMap>
+  offsetToProviders(TestAST &AST, SourceManager &SM,
+llvm::ArrayRef MacroRefs = {}) {
+llvm::SmallVector TopLevelDecls;
+for (Decl *D : AST.context().getTranslationUnitDecl()->decls())
+  TopLevelDecls.emplace_back(D);
+llvm::DenseMap> OffsetToProviders;
+walkUsed(TopLevelDecls, MacroRefs, &PI, SM,
+ [&](const SymbolReference &Ref, llvm::ArrayRef Providers) {
+   auto [FID, Offset] = SM.getDecomposedLoc(Ref.RefLocation);
+   if (FID != SM.getMainFileID())
+ ADD_FAILURE() << "Reference outside of the main file!";
+   OffsetToProviders.try_emplace(Offset, Providers.vec());
+ });
+return OffsetToProviders;
+  }
+};
+
+TEST_F(WalkUsedTest, Basic) {
   llvm::Annotations Code(R"cpp(
   #include "header.h"
   #include "private.h"
@@ -43,7 +82,7 @@
 std::$vector^vector $vconstructor^v;
   }
   )cpp");
-  TestInputs Inputs(Code.code());
+  Inputs.Code = Code.code();
   Inputs.ExtraFiles["header.h"] = guard(R"cpp(
   void foo();
   namespace std { class vector {}; }
@@ -53,87 +92,76 @@
 class Private {};
   )cpp");
 
-  PragmaIncludes PI;
-  Inputs.MakeAction = [&PI] {
-struct Hook : public SyntaxOnlyAction {
-public:
-  Hook(PragmaIncludes *Out) : Out(Out) {}
-  bool BeginSourceFileAction(clang::CompilerInstance &CI) override {
-Out->record(CI);
-return true;
-  }
-
-  PragmaIncludes *Out;
-};
-return std::make_unique(&PI);
-  };
   TestAST AST(Inputs);
-
-  llvm::SmallVector TopLevelDecls;
-  for (Decl *D : AST.context().getTranslationUnitDecl()->decls()) {
-TopLevelDecls.emplace_back(D);
-  }
-
   auto &SM = AST.sourceManager();
-  llvm::DenseMap> OffsetToProviders;
-  walkUsed(TopLevelDecls, /*MacroRefs=*/{}, &PI, SM,
-   [&](const SymbolReference &Ref, llvm::ArrayRef Providers) {
- auto [FID, Offset] = SM.getDecomposedLoc(Ref.RefLocation);
- EXPECT_EQ(FID, SM.getMainFileID());
- OffsetToProviders.try_emplace(Offset, Providers.vec());
-   });
-  auto &FM = AST.fileManager();
-  auto HeaderFile = Header(FM.getFile("header.h").get());
+  auto HeaderFile = Header(AST.fileManager().getFile("header.h").get());
+  auto PrivateFile = Header(AST.fileManager().getFile("private.h").get());
+  auto PublicFile = Header("\"path/public.h\"");
   auto MainFile = Header(SM.getFileEntryForID(SM.getMainFileID()));
   auto VectorSTL = Header(tooling::stdlib::Header::named("").value());
   EXPECT_THAT(
-  OffsetToProviders,
+  offsetToProviders(AST, SM),
   UnorderedElementsAre(
   Pair(Code.point("bar"), UnorderedElementsAre(MainFile)),
   Pair(Code.point("private"),
-   UnorderedElementsAre(Header("\"path/public.h\""),
-Header(FM.getFile("private.h").get(,
+   UnorderedElementsAre(PublicFile, PrivateFile)),
   Pair(Code.point("foo"), UnorderedElementsAre(HeaderFile)),
   Pair(Code.point("vector"), UnorderedElementsAr

[PATCH] D139296: [msan][CodeGen] Set noundef for C return value

2022-12-05 Thread Vitaly Buka via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
vitalybuka marked an inline comment as done.
Closed by commit rG166c8cccde01: [msan][CodeGen] Set noundef for C return value 
(authored by vitalybuka).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139296

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGen/cleanup-destslot-simple.c
  clang/test/CodeGen/msan-param-retval.c


Index: clang/test/CodeGen/msan-param-retval.c
===
--- clang/test/CodeGen/msan-param-retval.c
+++ clang/test/CodeGen/msan-param-retval.c
@@ -23,13 +23,20 @@
   return 1;
 }
 
-// CHECK: define dso_local i32 @foo() #0 {
-// CHECK:   @__msan_retval_tls
+// CLEAN:   define dso_local i32 @foo() #0 {
+// NOUNDEF: define dso_local noundef i32 @foo() #0 {
+// CLEAN:@__msan_retval_tls
+// NOUNDEF_ONLY: @__msan_retval_tls
+// EAGER-NOT:@__msan_retval_tls
 // CHECK: }
 
 int noret() {
 }
 
-// CHECK: define dso_local i32 @noret() #0 {
+// CLEAN:   define dso_local i32 @noret() #0 {   
+// NOUNDEF: define dso_local noundef i32 @noret() #0 {
 // CHECK:   %retval = alloca
-// CHECK: }
\ No newline at end of file
+// CLEAN:@__msan_retval_tls
+// NOUNDEF_ONLY: @__msan_retval_tls
+// EAGER-NOT:@__msan_retval_tls
+// CHECK: }
Index: clang/test/CodeGen/cleanup-destslot-simple.c
===
--- clang/test/CodeGen/cleanup-destslot-simple.c
+++ clang/test/CodeGen/cleanup-destslot-simple.c
@@ -64,7 +64,12 @@
 // CHECK-MSAN-NEXT:[[_MSLD1:%.*]] = load i32, ptr [[TMP11]], align 4, !dbg 
[[DBG20]]
 // CHECK-MSAN-NEXT:call void @llvm.lifetime.end.p0(i64 8, ptr nonnull 
[[P]]), !dbg [[DBG22:![0-9]+]]
 // CHECK-MSAN-NEXT:call void @llvm.lifetime.end.p0(i64 4, ptr nonnull 
[[X]]) #[[ATTR2]], !dbg [[DBG22]]
-// CHECK-MSAN-NEXT:store i32 [[_MSLD1]], ptr @__msan_retval_tls, align 8, 
!dbg [[DBG23:![0-9]+]]
+// CHECK-MSAN-NEXT:[[_MSCMP2_NOT:%.*]] = icmp eq i32 [[_MSLD1]], 0, !dbg 
[[DBG23:![0-9]+]]
+// CHECK-MSAN-NEXT:br i1 [[_MSCMP2_NOT]], label [[TMP13:%.*]], label 
[[TMP12:%.*]], !dbg [[DBG23]], !prof [[PROF21]]
+// CHECK-MSAN:   12:
+// CHECK-MSAN-NEXT:call void @__msan_warning_noreturn() #[[ATTR3]], !dbg 
[[DBG23]]
+// CHECK-MSAN-NEXT:unreachable, !dbg [[DBG23]]
+// CHECK-MSAN:   13:
 // CHECK-MSAN-NEXT:ret i32 [[TMP8]], !dbg [[DBG23]]
 //
 // CHECK-KMSAN-LABEL: @test(
Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -1798,6 +1798,13 @@
 
 static bool HasStrictReturn(const CodeGenModule &Module, QualType RetTy,
 const Decl *TargetDecl) {
+  // As-is msan can not tolerate noundef mismatch between caller and
+  // implementation. Mismatch is possible for e.g. indirect calls from C-caller
+  // into C++. Such mismatches lead to confusing false reports. To avoid
+  // expensive workaround on msan we enforce initialization event in uncommon
+  // cases where it's allowed.
+  if (Module.getLangOpts().Sanitize.has(SanitizerKind::Memory))
+return true;
   // C++ explicitly makes returning undefined values UB. C's rule only applies
   // to used values, so we never mark them noundef for now.
   if (!Module.getLangOpts().CPlusPlus)
@@ -1818,7 +1825,6 @@
   // Try to respect what the programmer intended.
   return Module.getCodeGenOpts().StrictReturn ||
  !Module.MayDropFunctionReturn(Module.getContext(), RetTy) ||
- Module.getLangOpts().Sanitize.has(SanitizerKind::Memory) ||
  Module.getLangOpts().Sanitize.has(SanitizerKind::Return);
 }
 


Index: clang/test/CodeGen/msan-param-retval.c
===
--- clang/test/CodeGen/msan-param-retval.c
+++ clang/test/CodeGen/msan-param-retval.c
@@ -23,13 +23,20 @@
   return 1;
 }
 
-// CHECK: define dso_local i32 @foo() #0 {
-// CHECK:   @__msan_retval_tls
+// CLEAN:   define dso_local i32 @foo() #0 {
+// NOUNDEF: define dso_local noundef i32 @foo() #0 {
+// CLEAN:@__msan_retval_tls
+// NOUNDEF_ONLY: @__msan_retval_tls
+// EAGER-NOT:@__msan_retval_tls
 // CHECK: }
 
 int noret() {
 }
 
-// CHECK: define dso_local i32 @noret() #0 {
+// CLEAN:   define dso_local i32 @noret() #0 {   
+// NOUNDEF: define dso_local noundef i32 @noret() #0 {
 // CHECK:   %retval = alloca
-// CHECK: }
\ No newline at end of file
+// CLEAN:@__msan_retval_tls
+// NOUNDEF_ONLY: @__msan_retval_tls
+// EAGER-NOT:@__msan_retval_tls
+// CHECK: }
Index: clang/test/CodeGen/cleanup-destslot-simple.c
===
--- clang/test/CodeGen/cleanup-destslot-simple.c
+++ clang/test/CodeGen/cleanup-destslot-simple.c

[clang] 166c8cc - [msan][CodeGen] Set noundef for C return value

2022-12-05 Thread Vitaly Buka via cfe-commits

Author: Vitaly Buka
Date: 2022-12-05T22:58:29-08:00
New Revision: 166c8cccde010ea01fdc20945a2a25fa1971cb73

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

LOG: [msan][CodeGen] Set noundef for C return value

Msan needs noundef consistency between interface and implementation. If
we call C++ from C we can have noundef on C++ side, and no noundef on
caller C side, noundef implementation will not set TLS for return value,
no noundef caller will expect it. Then we have false reports in msan.

The workaround could be set TLS to zero even for noundef return values.
However if we do that always it will increase binary size by about 10%.
If we do that selectively we need to handle "address is taken"
functions, any non local functions, and probably all function which have
musttail callers. Which is still a lot.

The existing implementation of HasStrictReturn refers to C standard as
the reason not enforcing noundef. I believe it applies only to the case
when return statement is omitted. Testing on Google codebase I never see
such cases, however I've see tens of cases where C code returns actual
uninitialized variables, but we ignore that it because of "omitted
return" case.

So this patch will:
1. fix false-positives with TLS missmatch.
2. detect bugs returning uninitialized variables for C as well.
3. report "omitted return" cases stricter than C, which is already a
   warning and very likely a bug in a code anyway.

Reviewed By: kda

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

Added: 


Modified: 
clang/lib/CodeGen/CGCall.cpp
clang/test/CodeGen/cleanup-destslot-simple.c
clang/test/CodeGen/msan-param-retval.c

Removed: 




diff  --git a/clang/lib/CodeGen/CGCall.cpp b/clang/lib/CodeGen/CGCall.cpp
index 07606877d843f..b94bf401d1949 100644
--- a/clang/lib/CodeGen/CGCall.cpp
+++ b/clang/lib/CodeGen/CGCall.cpp
@@ -1798,6 +1798,13 @@ bool CodeGenModule::MayDropFunctionReturn(const 
ASTContext &Context,
 
 static bool HasStrictReturn(const CodeGenModule &Module, QualType RetTy,
 const Decl *TargetDecl) {
+  // As-is msan can not tolerate noundef mismatch between caller and
+  // implementation. Mismatch is possible for e.g. indirect calls from C-caller
+  // into C++. Such mismatches lead to confusing false reports. To avoid
+  // expensive workaround on msan we enforce initialization event in uncommon
+  // cases where it's allowed.
+  if (Module.getLangOpts().Sanitize.has(SanitizerKind::Memory))
+return true;
   // C++ explicitly makes returning undefined values UB. C's rule only applies
   // to used values, so we never mark them noundef for now.
   if (!Module.getLangOpts().CPlusPlus)
@@ -1818,7 +1825,6 @@ static bool HasStrictReturn(const CodeGenModule &Module, 
QualType RetTy,
   // Try to respect what the programmer intended.
   return Module.getCodeGenOpts().StrictReturn ||
  !Module.MayDropFunctionReturn(Module.getContext(), RetTy) ||
- Module.getLangOpts().Sanitize.has(SanitizerKind::Memory) ||
  Module.getLangOpts().Sanitize.has(SanitizerKind::Return);
 }
 

diff  --git a/clang/test/CodeGen/cleanup-destslot-simple.c 
b/clang/test/CodeGen/cleanup-destslot-simple.c
index 2a0e682b0ab21..075afbba18cdb 100644
--- a/clang/test/CodeGen/cleanup-destslot-simple.c
+++ b/clang/test/CodeGen/cleanup-destslot-simple.c
@@ -64,7 +64,12 @@
 // CHECK-MSAN-NEXT:[[_MSLD1:%.*]] = load i32, ptr [[TMP11]], align 4, !dbg 
[[DBG20]]
 // CHECK-MSAN-NEXT:call void @llvm.lifetime.end.p0(i64 8, ptr nonnull 
[[P]]), !dbg [[DBG22:![0-9]+]]
 // CHECK-MSAN-NEXT:call void @llvm.lifetime.end.p0(i64 4, ptr nonnull 
[[X]]) #[[ATTR2]], !dbg [[DBG22]]
-// CHECK-MSAN-NEXT:store i32 [[_MSLD1]], ptr @__msan_retval_tls, align 8, 
!dbg [[DBG23:![0-9]+]]
+// CHECK-MSAN-NEXT:[[_MSCMP2_NOT:%.*]] = icmp eq i32 [[_MSLD1]], 0, !dbg 
[[DBG23:![0-9]+]]
+// CHECK-MSAN-NEXT:br i1 [[_MSCMP2_NOT]], label [[TMP13:%.*]], label 
[[TMP12:%.*]], !dbg [[DBG23]], !prof [[PROF21]]
+// CHECK-MSAN:   12:
+// CHECK-MSAN-NEXT:call void @__msan_warning_noreturn() #[[ATTR3]], !dbg 
[[DBG23]]
+// CHECK-MSAN-NEXT:unreachable, !dbg [[DBG23]]
+// CHECK-MSAN:   13:
 // CHECK-MSAN-NEXT:ret i32 [[TMP8]], !dbg [[DBG23]]
 //
 // CHECK-KMSAN-LABEL: @test(

diff  --git a/clang/test/CodeGen/msan-param-retval.c 
b/clang/test/CodeGen/msan-param-retval.c
index b003ae21ba82c..744d70620bdc4 100644
--- a/clang/test/CodeGen/msan-param-retval.c
+++ b/clang/test/CodeGen/msan-param-retval.c
@@ -23,13 +23,20 @@ int foo() {
   return 1;
 }
 
-// CHECK: define dso_local i32 @foo() #0 {
-// CHECK:   @__msan_retval_tls
+// CLEAN:   define dso_local i32 @foo() #0 {
+// NOUNDEF: define dso_local noundef i32 @foo() #0 {
+// CLEAN:@__msan_retval_tls
+/

[PATCH] D139296: [msan][CodeGen] Set noundef for C return value

2022-12-05 Thread Vitaly Buka via Phabricator via cfe-commits
vitalybuka marked an inline comment as done.
vitalybuka added inline comments.



Comment at: clang/lib/CodeGen/CGCall.cpp:1828
  !Module.MayDropFunctionReturn(Module.getContext(), RetTy) ||
  Module.getLangOpts().Sanitize.has(SanitizerKind::Memory) ||
  Module.getLangOpts().Sanitize.has(SanitizerKind::Return);

aeubanks wrote:
> should this be dropped? and maybe also move up `SanitizerKind::Return`?
Documentation for SanitizerKind::Return explicitly states that it's C++ check.
So I will leave it as is.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139296

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


[PATCH] D139296: [msan][CodeGen] Set noundef for C return value

2022-12-05 Thread Vitaly Buka via Phabricator via cfe-commits
vitalybuka updated this revision to Diff 480335.
vitalybuka added a comment.

remove redundant check


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139296

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGen/cleanup-destslot-simple.c
  clang/test/CodeGen/msan-param-retval.c


Index: clang/test/CodeGen/msan-param-retval.c
===
--- clang/test/CodeGen/msan-param-retval.c
+++ clang/test/CodeGen/msan-param-retval.c
@@ -23,13 +23,20 @@
   return 1;
 }
 
-// CHECK: define dso_local i32 @foo() #0 {
-// CHECK:   @__msan_retval_tls
+// CLEAN:   define dso_local i32 @foo() #0 {
+// NOUNDEF: define dso_local noundef i32 @foo() #0 {
+// CLEAN:@__msan_retval_tls
+// NOUNDEF_ONLY: @__msan_retval_tls
+// EAGER-NOT:@__msan_retval_tls
 // CHECK: }
 
 int noret() {
 }
 
-// CHECK: define dso_local i32 @noret() #0 {
+// CLEAN:   define dso_local i32 @noret() #0 {   
+// NOUNDEF: define dso_local noundef i32 @noret() #0 {
 // CHECK:   %retval = alloca
-// CHECK: }
\ No newline at end of file
+// CLEAN:@__msan_retval_tls
+// NOUNDEF_ONLY: @__msan_retval_tls
+// EAGER-NOT:@__msan_retval_tls
+// CHECK: }
Index: clang/test/CodeGen/cleanup-destslot-simple.c
===
--- clang/test/CodeGen/cleanup-destslot-simple.c
+++ clang/test/CodeGen/cleanup-destslot-simple.c
@@ -64,7 +64,12 @@
 // CHECK-MSAN-NEXT:[[_MSLD1:%.*]] = load i32, ptr [[TMP11]], align 4, !dbg 
[[DBG20]]
 // CHECK-MSAN-NEXT:call void @llvm.lifetime.end.p0(i64 8, ptr nonnull 
[[P]]), !dbg [[DBG22:![0-9]+]]
 // CHECK-MSAN-NEXT:call void @llvm.lifetime.end.p0(i64 4, ptr nonnull 
[[X]]) #[[ATTR2]], !dbg [[DBG22]]
-// CHECK-MSAN-NEXT:store i32 [[_MSLD1]], ptr @__msan_retval_tls, align 8, 
!dbg [[DBG23:![0-9]+]]
+// CHECK-MSAN-NEXT:[[_MSCMP2_NOT:%.*]] = icmp eq i32 [[_MSLD1]], 0, !dbg 
[[DBG23:![0-9]+]]
+// CHECK-MSAN-NEXT:br i1 [[_MSCMP2_NOT]], label [[TMP13:%.*]], label 
[[TMP12:%.*]], !dbg [[DBG23]], !prof [[PROF21]]
+// CHECK-MSAN:   12:
+// CHECK-MSAN-NEXT:call void @__msan_warning_noreturn() #[[ATTR3]], !dbg 
[[DBG23]]
+// CHECK-MSAN-NEXT:unreachable, !dbg [[DBG23]]
+// CHECK-MSAN:   13:
 // CHECK-MSAN-NEXT:ret i32 [[TMP8]], !dbg [[DBG23]]
 //
 // CHECK-KMSAN-LABEL: @test(
Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -1798,6 +1798,13 @@
 
 static bool HasStrictReturn(const CodeGenModule &Module, QualType RetTy,
 const Decl *TargetDecl) {
+  // As-is msan can not tolerate noundef mismatch between caller and
+  // implementation. Mismatch is possible for e.g. indirect calls from C-caller
+  // into C++. Such mismatches lead to confusing false reports. To avoid
+  // expensive workaround on msan we enforce initialization event in uncommon
+  // cases where it's allowed.
+  if (Module.getLangOpts().Sanitize.has(SanitizerKind::Memory))
+return true;
   // C++ explicitly makes returning undefined values UB. C's rule only applies
   // to used values, so we never mark them noundef for now.
   if (!Module.getLangOpts().CPlusPlus)
@@ -1818,7 +1825,6 @@
   // Try to respect what the programmer intended.
   return Module.getCodeGenOpts().StrictReturn ||
  !Module.MayDropFunctionReturn(Module.getContext(), RetTy) ||
- Module.getLangOpts().Sanitize.has(SanitizerKind::Memory) ||
  Module.getLangOpts().Sanitize.has(SanitizerKind::Return);
 }
 


Index: clang/test/CodeGen/msan-param-retval.c
===
--- clang/test/CodeGen/msan-param-retval.c
+++ clang/test/CodeGen/msan-param-retval.c
@@ -23,13 +23,20 @@
   return 1;
 }
 
-// CHECK: define dso_local i32 @foo() #0 {
-// CHECK:   @__msan_retval_tls
+// CLEAN:   define dso_local i32 @foo() #0 {
+// NOUNDEF: define dso_local noundef i32 @foo() #0 {
+// CLEAN:@__msan_retval_tls
+// NOUNDEF_ONLY: @__msan_retval_tls
+// EAGER-NOT:@__msan_retval_tls
 // CHECK: }
 
 int noret() {
 }
 
-// CHECK: define dso_local i32 @noret() #0 {
+// CLEAN:   define dso_local i32 @noret() #0 {   
+// NOUNDEF: define dso_local noundef i32 @noret() #0 {
 // CHECK:   %retval = alloca
-// CHECK: }
\ No newline at end of file
+// CLEAN:@__msan_retval_tls
+// NOUNDEF_ONLY: @__msan_retval_tls
+// EAGER-NOT:@__msan_retval_tls
+// CHECK: }
Index: clang/test/CodeGen/cleanup-destslot-simple.c
===
--- clang/test/CodeGen/cleanup-destslot-simple.c
+++ clang/test/CodeGen/cleanup-destslot-simple.c
@@ -64,7 +64,12 @@
 // CHECK-MSAN-NEXT:[[_MSLD1:%.*]] = load i32, ptr [[TMP11]], align 4, !dbg [[DBG20]]
 // CHECK-MSAN-NEXT:call void @llvm.lifetime.end.p0(i64 8, ptr non

[clang-tools-extra] 15ba27e - [clang-tools-extra] Use std::nullopt instead of llvm::None (NFC)

2022-12-05 Thread Kazu Hirata via cfe-commits

Author: Kazu Hirata
Date: 2022-12-05T22:37:22-08:00
New Revision: 15ba27ebd0cbf96659b729399f89eb9f11ae1d5e

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

LOG: [clang-tools-extra] Use std::nullopt instead of llvm::None (NFC)

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

Added: 


Modified: 
clang-tools-extra/unittests/clang-tidy/ReadabilityModuleTest.cpp

Removed: 




diff  --git a/clang-tools-extra/unittests/clang-tidy/ReadabilityModuleTest.cpp 
b/clang-tools-extra/unittests/clang-tidy/ReadabilityModuleTest.cpp
index f8e4268b0d97..ec53f52466af 100644
--- a/clang-tools-extra/unittests/clang-tidy/ReadabilityModuleTest.cpp
+++ b/clang-tools-extra/unittests/clang-tidy/ReadabilityModuleTest.cpp
@@ -484,7 +484,8 @@ TEST(BracesAroundStatementsCheckTest, Macros) {
 }
 
 #define EXPECT_NO_CHANGES_WITH_OPTS(Check, Opts, Code) 
\
-  EXPECT_EQ(Code, runCheckOnCode(Code, nullptr, "input.cc", None, Opts))
+  EXPECT_EQ(Code, runCheckOnCode(Code, nullptr, "input.cc", 
\
+std::nullopt, Opts))
 TEST(BracesAroundStatementsCheckTest, ImplicitCastInReturn) {
   ClangTidyOptions Opts;
   Opts.CheckOptions["test-check-0.ShortStatementLines"] = "1";



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


[clang-tools-extra] 649ef33 - [clang-tools-extra] Use std::nullopt instead of llvm::None (NFC)

2022-12-05 Thread Kazu Hirata via cfe-commits

Author: Kazu Hirata
Date: 2022-12-05T21:49:31-08:00
New Revision: 649ef3386b90363af3c807ebe82d0facc75fa381

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

LOG: [clang-tools-extra] Use std::nullopt instead of llvm::None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated.  The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

Added: 


Modified: 
clang-tools-extra/clangd/unittests/ClangdTests.cpp
clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
clang-tools-extra/clangd/unittests/ConfigCompileTests.cpp
clang-tools-extra/clangd/unittests/ConfigYAMLTests.cpp
clang-tools-extra/clangd/unittests/ExpectedTypeTest.cpp
clang-tools-extra/clangd/unittests/FuzzyMatchTests.cpp
clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp
clang-tools-extra/clangd/unittests/HeaderSourceSwitchTests.cpp
clang-tools-extra/clangd/unittests/HeadersTests.cpp
clang-tools-extra/clangd/unittests/HoverTests.cpp
clang-tools-extra/clangd/unittests/IndexTests.cpp
clang-tools-extra/clangd/unittests/InlayHintTests.cpp
clang-tools-extra/clangd/unittests/PreambleTests.cpp
clang-tools-extra/clangd/unittests/RenameTests.cpp
clang-tools-extra/clangd/unittests/SourceCodeTests.cpp
clang-tools-extra/clangd/unittests/StdLibTests.cpp
clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
clang-tools-extra/clangd/unittests/TestFS.cpp
clang-tools-extra/clangd/unittests/TestWorkspace.cpp
clang-tools-extra/clangd/unittests/XRefsTests.cpp
clang-tools-extra/pseudo/unittests/LRTableTest.cpp
clang-tools-extra/unittests/clang-tidy/ClangTidyTest.h
clang-tools-extra/unittests/clang-tidy/IncludeInserterTest.cpp
clang-tools-extra/unittests/clang-tidy/LLVMModuleTest.cpp
clang-tools-extra/unittests/clang-tidy/NamespaceAliaserTest.cpp
clang-tools-extra/unittests/clang-tidy/ReadabilityModuleTest.cpp
clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
clang-tools-extra/unittests/clang-tidy/UsingInserterTest.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/unittests/ClangdTests.cpp 
b/clang-tools-extra/clangd/unittests/ClangdTests.cpp
index d3399f4d98e0b..4ca9e104e56d4 100644
--- a/clang-tools-extra/clangd/unittests/ClangdTests.cpp
+++ b/clang-tools-extra/clangd/unittests/ClangdTests.cpp
@@ -943,7 +943,7 @@ void f() {}
   FS.Files[Path] = Code;
   runAddDocument(Server, Path, Code);
 
-  auto Replaces = runFormatFile(Server, Path, /*Rng=*/llvm::None);
+  auto Replaces = runFormatFile(Server, Path, /*Rng=*/std::nullopt);
   EXPECT_TRUE(static_cast(Replaces));
   auto Changed = tooling::applyAllReplacements(Code, *Replaces);
   EXPECT_TRUE(static_cast(Changed));

diff  --git a/clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp 
b/clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
index 42d2521491689..a7ae1112c533f 100644
--- a/clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ b/clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -3555,7 +3555,7 @@ TEST(CompletionTest, CompletionRange) {
   // heuristics as normal and reports a range. It'd be nice to be consistent.
   const char *NoCompletion = "/* foo [[]]^ */";
   Completions = completions(NoCompletion);
-  EXPECT_EQ(Completions.CompletionRange, llvm::None);
+  EXPECT_EQ(Completions.CompletionRange, std::nullopt);
   Completions = completionsNoCompile(NoCompletion);
   EXPECT_EQ(Completions.CompletionRange, Annotations(NoCompletion).range());
 }

diff  --git a/clang-tools-extra/clangd/unittests/ConfigCompileTests.cpp 
b/clang-tools-extra/clangd/unittests/ConfigCompileTests.cpp
index b3286e58efef1..e19777663f69e 100644
--- a/clang-tools-extra/clangd/unittests/ConfigCompileTests.cpp
+++ b/clang-tools-extra/clangd/unittests/ConfigCompileTests.cpp
@@ -471,7 +471,7 @@ TEST_F(ConfigCompileTests, ExternalBlockMountPoint) {
   EXPECT_THAT(Conf.Index.External.MountPoint, FooPath);
 
   // None defaults to ".".
-  Frag = GetFrag(FooPath, llvm::None);
+  Frag = GetFrag(FooPath, std::nullopt);
   compileAndApply();
   ASSERT_THAT(Diags.Diagnostics, IsEmpty());
   ASSERT_EQ(Conf.Index.External.Kind, Config::ExternalIndexSpec::File);

diff  --git a/clang-tools-extra/clangd/unittests/ConfigYAMLTests.cpp 
b/clang-tools-extra/clangd/unittests/ConfigYAMLTests.cpp
index 6af1e3bb74111..50b56fa9f15a9 100644
--- a/clang-tools-extra/clangd/unittests/ConfigYAMLTests.cpp
+++ b/clang-to

[PATCH] D139168: [C++20] [Modules] [ClangScanDeps] Enable to print make-style dependency file within P1689 format (4/4)

2022-12-05 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu added inline comments.



Comment at: clang/test/ClangScanDeps/P1689.cppm:155
 
+// CHECK-MAKE: [[PREFIX]]/impl_part.o:
+// CHECK-MAKE:   [[PREFIX]]/impl_part.cppm

ben.boeckel wrote:
> ben.boeckel wrote:
> > ChuanqiXu wrote:
> > > ben.boeckel wrote:
> > > > ChuanqiXu wrote:
> > > > > ben.boeckel wrote:
> > > > > > For scanning, this cannot be the object file. The output needs to 
> > > > > > be the P1689 output (or whatever the "main output" for the scanning 
> > > > > > rule is). This is the purpose behind the `-MT ` flag: to 
> > > > > > say what goes in this slot. I think it'll be necessary here (even 
> > > > > > if `clang-scan-deps` learns an `-o` flag because it is the build 
> > > > > > system that determines the "primary output").
> > > > > > 
> > > > > > I don't know if the `-MMD` and `-MD` differences are important or 
> > > > > > not; I don't think I particularly care which is default (I've used 
> > > > > > `-MD` FWIW), but it may matter for other situations.
> > > > > I am confused since the output `[[PREFIX]]/impl_part.o` is the same 
> > > > > with `P1689` output `[[PREFIX]]/impl_part.o` and the one in the 
> > > > > compilation database and the one specified in the command line option 
> > > > > `--p1689-targeted-output`. What's the expected output for you in this 
> > > > > case? (and the related command line input.)
> > > > P1689 is about specifying dependencies of *another* rule found by the 
> > > > dynamic content of some source. `-MF` is about *discovered* 
> > > > dependencies of *this* rule.
> > > hmmm sorry, I don't understand it a lot. May you explain your expectation 
> > > in the form of the input and the corresponding output?
> > *This* rule outputs `foo.ddi` (in CMake terms). We need to tell make or 
> > ninja what files, if they change, *this* rule needs rerun for. That is what 
> > `-MF` is for. What I need is spelled `-MT` "normally".
> > 
> > P1689, what this rule is *doing*, is writing dependencies for the *compile* 
> > rule, so it is hooked up by *its output*. Two rules cannot have the same 
> > output, so P1689 and `-MF` have completely different things to put for 
> > their "output".
> > 
> > You can see here: 
> > https://gitlab.kitware.com/cmake/cmake/-/blob/master/.gitlab/ci/cxx_modules_rules_gcc.cmake
> >  where `-MT` gets the `` which is the `-fdep-file=` argument. 
> > `-fdep-file=` tells GCC what rule the P1689 itself is for.
> > -fdep-output= tells GCC what rule the P1689 itself is for.
> 
> Fixed.
Oh, I guess I get your point. Now we can set the output name with `-MT 
[[outputname]] -MD` in the input after `--`. See the above changes for example. 
Is this what you want?


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

https://reviews.llvm.org/D139168

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


[PATCH] D139168: [C++20] [Modules] [ClangScanDeps] Enable to print make-style dependency file within P1689 format (4/4)

2022-12-05 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu updated this revision to Diff 480329.
ChuanqiXu added a comment.

Address comments.


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

https://reviews.llvm.org/D139168

Files:
  clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h
  clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
  clang/test/ClangScanDeps/P1689.cppm
  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
@@ -187,6 +187,13 @@
"dependencies are to be computed."),
 llvm::cl::cat(DependencyScannerCategory));
 
+llvm::cl::opt P1689MakeformatOutputpath(
+"p1689-makeformat-output", llvm::cl::Optional,
+llvm::cl::desc("Only supported for P1689. Print the make-style dependency "
+   "output to the specified output. This is a helper for build "
+   "systems to do duplicate scanning."),
+llvm::cl::cat(DependencyScannerCategory));
+
 llvm::cl::opt P1689TargettedCommand(
 llvm::cl::Positional, llvm::cl::ZeroOrMore,
 llvm::cl::desc("The command line flags for the target of which "
@@ -584,6 +591,19 @@
   return std::move(FixedCompilationDatabase);
 }
 
+static raw_ostream &getDependencyOS() {
+  if (!P1689MakeformatOutputpath.empty()) {
+std::error_code EC;
+static llvm::raw_fd_ostream OS(P1689MakeformatOutputpath, EC);
+if (EC)
+  llvm::errs() << "Failed to open P1689 make format output file \""
+   << P1689MakeformatOutputpath << "\" for " << EC.message()
+   << "\n";
+return OS;
+  }
+  return llvm::outs();
+}
+
 int main(int argc, const char **argv) {
   std::string ErrorMessage;
   std::unique_ptr Compilations =
@@ -662,7 +682,7 @@
 
   SharedStream Errs(llvm::errs());
   // Print out the dependency results to STDOUT by default.
-  SharedStream DependencyOS(llvm::outs());
+  SharedStream DependencyOS(getDependencyOS());
 
   DependencyScanningService Service(ScanMode, Format, OptimizeArgs,
 EagerLoadModules);
@@ -722,10 +742,20 @@
  Errs))
 HadErrors = true;
 } else if (Format == ScanningOutputFormat::P1689) {
+  llvm::Optional MakeformatOutput;
+  if (!P1689MakeformatOutputpath.empty())
+MakeformatOutput.emplace();
+
   auto MaybeRule = WorkerTools[I]->getP1689ModuleDependencyFile(
-  *Input, CWD, MaybeModuleName);
-  if (handleP1689DependencyToolResult(Filename, MaybeRule, PD, Errs))
-HadErrors = true;
+  *Input, CWD, MakeformatOutput, MaybeModuleName);
+  HadErrors =
+  handleP1689DependencyToolResult(Filename, MaybeRule, PD, Errs);
+
+  if (MakeformatOutput && !MakeformatOutput->empty() && !HadErrors) {
+llvm::Expected MaybeOutput(*MakeformatOutput);
+HadErrors = handleMakeDependencyToolResult(Filename, MaybeOutput,
+   DependencyOS, Errs);
+  }
 } else if (DeprecatedDriverCommand) {
   auto MaybeFullDeps =
   WorkerTools[I]->getFullDependenciesLegacyDriverCommand(
Index: clang/test/ClangScanDeps/P1689.cppm
===
--- clang/test/ClangScanDeps/P1689.cppm
+++ clang/test/ClangScanDeps/P1689.cppm
@@ -22,6 +22,11 @@
 // RUN: clang-scan-deps -format=p1689 --p1689-targeted-file-name=%t/User.cpp --p1689-targeted-output=%t/User.o \
 // RUN:   -- -std=c++20 -c \
 // RUN:   | FileCheck %t/User.cpp -DPREFIX=%/t
+//
+// Check we can generate the make-style dependencies as expected.
+// RUN: clang-scan-deps -format=p1689 --p1689-targeted-file-name=%t/impl_part.cppm --p1689-targeted-output=%t/impl_part.o \
+// RUN:   --p1689-makeformat-output=%t/impl_part.dep -- -std=c++20 -c -MT %t/impl_part.o.ddi -MD
+// RUN: cat %t/impl_part.dep | FileCheck %t/impl_part.cppm -DPREFIX=%/t --check-prefix=CHECK-MAKE
 
 //--- P1689.json.in
 [
@@ -57,7 +62,6 @@
 }
 ]
 
-
 //--- M.cppm
 export module M;
 export import :interface_part;
@@ -145,6 +149,10 @@
 // CHECK-NEXT:   "version": 1
 // CHECK-NEXT: }
 
+// CHECK-MAKE: [[PREFIX]]/impl_part.o.ddi:
+// CHECK-MAKE:   [[PREFIX]]/impl_part.cppm
+// CHECK-MAKE:   [[PREFIX]]/header.mock
+
 //--- interface_part.cppm
 export module M:interface_part;
 export void World();
Index: clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
===
--- clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
+++ clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
@@ -39,67 +39,69 @@
 llvm::IntrusiveRefCntPtr FS)
 : Worker(Service, std::move(FS)) {}
 
-llvm::Expected DependencySc

[PATCH] D137059: [Driver] [Modules] Introduce -fsave-std-c++-module-file= to specify the path of the module file (2/2)

2022-12-05 Thread Iain Sandoe via Phabricator via cfe-commits
iains added a comment.

In D137059#3973016 , @ben.boeckel 
wrote:

> In D137059#3934448 , @dblaikie 
> wrote:
>
>> I'm still curious what about the details of other compilers - I think from 
>> the sounds of it, @iains suggested GCC doesn't support this yet so we'll 
>> need to pick/name the flag ourselves & he's happy to implement whatever we 
>> pick? I guess Microsoft's flag naming is sufficiently differently styled as 
>> to offer no useful inspiration? Though wouldn't hurt to know what they name 
>> it.
>>
>> Any other examples you had in mind, Ben?
>
> GCC supports naming the output file by asking the "module mapper" where a 
> module with a given name lives (also used for finding imported modules).

This is using the "P1184 " interface for both 
tasks - which I think we should keep as a separate mechanism (at least 
mentally) since we can also use that with clang when we implement it.  What the 
interface returns for the name (via P1184 ) is 
decoupled from how the name is determined (potentially by a command line 
argument or from some other build system component).

Currently, GCC does not have a command line spelling for specifying the output 
module name, which is why I say it's still "up for grabs" (actually it would be 
polite to ask on g...@gcc.gnu.org for opinions on the spelling, since it would 
be crazy to have different on at least these two platforms).  The spelling of 
command line options is not IMO bike shedding, it affects day-to-day use of the 
tools.


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

https://reviews.llvm.org/D137059

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


[PATCH] D137762: [clang-format] avoid breaking )( with BlockIndent

2022-12-05 Thread Gedare Bloom via Phabricator via cfe-commits
gedare added a comment.

In D137762#3969770 , @owenpan wrote:

> @gedare do you need us to commit this patch on your behalf (using "Gedare 
> Bloom ")?

Yes, please. I don't have any llvm permissions, this is my first patch set for 
llvm actually. Anything else I need to do?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137762

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


[PATCH] D139387: [Clang] Support policy function for all vector segment load.

2022-12-05 Thread Brandon Wu via Phabricator via cfe-commits
4vtomat updated this revision to Diff 480321.
4vtomat added a comment.

Resolved Craig's comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139387

Files:
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vlseg.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlseg.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlseg_mask.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlsegff_mask.c

Index: clang/test/CodeGen/RISCV/rvv-intrinsics/vlsegff_mask.c
===
--- clang/test/CodeGen/RISCV/rvv-intrinsics/vlsegff_mask.c
+++ clang/test/CodeGen/RISCV/rvv-intrinsics/vlsegff_mask.c
@@ -8204,3 +8204,107 @@
 void test_vlseg2e16ff_v_f16m4_m (vfloat16m4_t *v0, vfloat16m4_t *v1, vbool4_t mask, vfloat16m4_t maskedoff0, vfloat16m4_t maskedoff1, const _Float16 *base, size_t *new_vl, size_t vl) {
   return vlseg2e16ff_v_f16m4_m(v0, v1, mask, maskedoff0, maskedoff1, base, new_vl, vl);
 }
+
+// CHECK-RV32-LABEL: @test_vlseg2e32ff_v_u32mf2_tuma(
+// CHECK-RV32-NEXT:  entry:
+// CHECK-RV32-NEXT:[[TMP0:%.*]] = call { , , i32 } @llvm.riscv.vlseg2ff.mask.nxv1i32.i32( [[MERGE0:%.*]],  [[MERGE1:%.*]], i32* [[BASE:%.*]],  [[MASK:%.*]], i32 [[VL:%.*]], i32 2)
+// CHECK-RV32-NEXT:[[TMP1:%.*]] = extractvalue { , , i32 } [[TMP0]], 0
+// CHECK-RV32-NEXT:store  [[TMP1]], * [[V0:%.*]], align 4
+// CHECK-RV32-NEXT:[[TMP2:%.*]] = extractvalue { , , i32 } [[TMP0]], 1
+// CHECK-RV32-NEXT:store  [[TMP2]], * [[V1:%.*]], align 4
+// CHECK-RV32-NEXT:[[TMP3:%.*]] = extractvalue { , , i32 } [[TMP0]], 2
+// CHECK-RV32-NEXT:store i32 [[TMP3]], i32* [[NEW_VL:%.*]], align 4
+// CHECK-RV32-NEXT:ret void
+//
+// CHECK-RV64-LABEL: @test_vlseg2e32ff_v_u32mf2_tuma(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call { , , i64 } @llvm.riscv.vlseg2ff.mask.nxv1i32.i64( [[MERGE0:%.*]],  [[MERGE1:%.*]], i32* [[BASE:%.*]],  [[MASK:%.*]], i64 [[VL:%.*]], i64 2)
+// CHECK-RV64-NEXT:[[TMP1:%.*]] = extractvalue { , , i64 } [[TMP0]], 0
+// CHECK-RV64-NEXT:store  [[TMP1]], * [[V0:%.*]], align 4
+// CHECK-RV64-NEXT:[[TMP2:%.*]] = extractvalue { , , i64 } [[TMP0]], 1
+// CHECK-RV64-NEXT:store  [[TMP2]], * [[V1:%.*]], align 4
+// CHECK-RV64-NEXT:[[TMP3:%.*]] = extractvalue { , , i64 } [[TMP0]], 2
+// CHECK-RV64-NEXT:store i64 [[TMP3]], i64* [[NEW_VL:%.*]], align 4
+// CHECK-RV64-NEXT:ret void
+//
+void test_vlseg2e32ff_v_u32mf2_tuma(vuint32mf2_t *v0, vuint32mf2_t *v1, vbool64_t mask, vuint32mf2_t merge0, vuint32mf2_t merge1, const uint32_t *base, size_t *new_vl, size_t vl) {
+  return vlseg2e32ff_v_u32mf2_tuma(v0, v1, mask, merge0, merge1, base, new_vl, vl);
+}
+
+// CHECK-RV32-LABEL: @test_vlseg2e32ff_v_u32mf2_tumu(
+// CHECK-RV32-NEXT:  entry:
+// CHECK-RV32-NEXT:[[TMP0:%.*]] = call { , , i32 } @llvm.riscv.vlseg2ff.mask.nxv1i32.i32( [[MERGE0:%.*]],  [[MERGE1:%.*]], i32* [[BASE:%.*]],  [[MASK:%.*]], i32 [[VL:%.*]], i32 0)
+// CHECK-RV32-NEXT:[[TMP1:%.*]] = extractvalue { , , i32 } [[TMP0]], 0
+// CHECK-RV32-NEXT:store  [[TMP1]], * [[V0:%.*]], align 4
+// CHECK-RV32-NEXT:[[TMP2:%.*]] = extractvalue { , , i32 } [[TMP0]], 1
+// CHECK-RV32-NEXT:store  [[TMP2]], * [[V1:%.*]], align 4
+// CHECK-RV32-NEXT:[[TMP3:%.*]] = extractvalue { , , i32 } [[TMP0]], 2
+// CHECK-RV32-NEXT:store i32 [[TMP3]], i32* [[NEW_VL:%.*]], align 4
+// CHECK-RV32-NEXT:ret void
+//
+// CHECK-RV64-LABEL: @test_vlseg2e32ff_v_u32mf2_tumu(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call { , , i64 } @llvm.riscv.vlseg2ff.mask.nxv1i32.i64( [[MERGE0:%.*]],  [[MERGE1:%.*]], i32* [[BASE:%.*]],  [[MASK:%.*]], i64 [[VL:%.*]], i64 0)
+// CHECK-RV64-NEXT:[[TMP1:%.*]] = extractvalue { , , i64 } [[TMP0]], 0
+// CHECK-RV64-NEXT:store  [[TMP1]], * [[V0:%.*]], align 4
+// CHECK-RV64-NEXT:[[TMP2:%.*]] = extractvalue { , , i64 } [[TMP0]], 1
+// CHECK-RV64-NEXT:store  [[TMP2]], * [[V1:%.*]], align 4
+// CHECK-RV64-NEXT:[[TMP3:%.*]] = extractvalue { , , i64 } [[TMP0]], 2
+// CHECK-RV64-NEXT:store i64 [[TMP3]], i64* [[NEW_VL:%.*]], align 4
+// CHECK-RV64-NEXT:ret void
+//
+void test_vlseg2e32ff_v_u32mf2_tumu(vuint32mf2_t *v0, vuint32mf2_t *v1, vbool64_t mask, vuint32mf2_t merge0, vuint32mf2_t merge1, const uint32_t *base, size_t *new_vl, size_t vl) {
+  return vlseg2e32ff_v_u32mf2_tumu(v0, v1, mask, merge0, merge1, base, new_vl, vl);
+}
+
+// CHECK-RV32-LABEL: @test_vlseg2e32ff_v_u32mf2_tama(
+// CHECK-RV32-NEXT:  entry:
+// CHECK-RV32-NEXT:[[TMP0:%.*]] = call { , , i32 } @llvm.riscv.vlseg2ff.mask.nxv1i32.i32( undef,  undef, i32* [[BASE:%.*]],  [[MASK:%.*]], i32 [[VL:%.*]], i32 3)
+// CHECK-RV32-NEXT:[[TMP1:%.*]] = extractvalue { , , i32 } [[TMP0]], 0
+// CHECK-RV32-NEXT:store  [[TMP1]], * [[V0:%.*]], align 4
+// CHECK-RV32-NEXT:[[TMP2:%.*]] = extractvalue { , , i32 } [[TMP0]], 1
+// CHECK-RV32-NEXT:store  [[T

[PATCH] D138807: [RISCV] Support vector crypto extension ISA string and assembly

2022-12-05 Thread Brandon Wu via Phabricator via cfe-commits
4vtomat updated this revision to Diff 480320.
4vtomat added a comment.

Resolved Craig's comment


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138807

Files:
  clang/test/Preprocessor/riscv-target-features.c
  llvm/docs/RISCVUsage.rst
  llvm/lib/Support/RISCVISAInfo.cpp
  llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
  llvm/lib/Target/RISCV/MCTargetDesc/RISCVBaseInfo.h
  llvm/lib/Target/RISCV/RISCV.td
  llvm/lib/Target/RISCV/RISCVInstrFormats.td
  llvm/lib/Target/RISCV/RISCVInstrInfo.td
  llvm/lib/Target/RISCV/RISCVInstrInfoV.td
  llvm/lib/Target/RISCV/RISCVInstrInfoZvk.td
  llvm/lib/Target/RISCV/RISCVSubtarget.h
  llvm/test/CodeGen/RISCV/attributes.ll
  llvm/test/MC/RISCV/attribute-arch.s
  llvm/test/MC/RISCV/rvv/rv64zvkb.s
  llvm/test/MC/RISCV/rvv/rv64zvkg.s
  llvm/test/MC/RISCV/rvv/rv64zvknha.s
  llvm/test/MC/RISCV/rvv/rv64zvknhb.s
  llvm/test/MC/RISCV/rvv/rv64zvkns.s
  llvm/test/MC/RISCV/rvv/rv64zvksed.s
  llvm/test/MC/RISCV/rvv/rv64zvksh.s

Index: llvm/test/MC/RISCV/rvv/rv64zvksh.s
===
--- /dev/null
+++ llvm/test/MC/RISCV/rvv/rv64zvksh.s
@@ -0,0 +1,21 @@
+# RUN: llvm-mc -triple=riscv64 -show-encoding --mattr=+experimental-zvksh %s \
+# RUN:| FileCheck %s --check-prefixes=CHECK-ENCODING,CHECK-INST
+# RUN: not llvm-mc -triple=riscv64 -show-encoding %s 2>&1 \
+# RUN:| FileCheck %s --check-prefix=CHECK-ERROR
+# RUN: llvm-mc -triple=riscv64 -filetype=obj --mattr=+experimental-zvksh %s \
+# RUN:| llvm-objdump -d --mattr=+experimental-zvksh  - \
+# RUN:| FileCheck %s --check-prefix=CHECK-INST
+# RUN: llvm-mc -triple=riscv64 -filetype=obj --mattr=+experimental-zvksh %s \
+# RUN:| llvm-objdump -d - | FileCheck %s --check-prefix=CHECK-UNKNOWN
+
+vsm3c.vi v10, v9, 7
+# CHECK-INST: vsm3c.vi v10, v9, 7
+# CHECK-ENCODING: [0x77,0xa5,0x93,0xae]
+# CHECK-ERROR: instruction requires the following: 'Zvksh'
+# CHECK-UNKNOWN: 77 a5 93 ae   
+
+vsm3me.vv v10, v9, v8
+# CHECK-INST: vsm3me.vv v10, v9, v8
+# CHECK-ENCODING: [0x77,0x25,0x94,0x82]
+# CHECK-ERROR: instruction requires the following: 'Zvksh'
+# CHECK-UNKNOWN: 77 25 94 82   
Index: llvm/test/MC/RISCV/rvv/rv64zvksed.s
===
--- /dev/null
+++ llvm/test/MC/RISCV/rvv/rv64zvksed.s
@@ -0,0 +1,21 @@
+# RUN: llvm-mc -triple=riscv64 -show-encoding --mattr=+experimental-zvksed %s \
+# RUN:| FileCheck %s --check-prefixes=CHECK-ENCODING,CHECK-INST
+# RUN: not llvm-mc -triple=riscv64 -show-encoding %s 2>&1 \
+# RUN:| FileCheck %s --check-prefix=CHECK-ERROR
+# RUN: llvm-mc -triple=riscv64 -filetype=obj --mattr=+experimental-zvksed %s \
+# RUN:| llvm-objdump -d --mattr=+experimental-zvksed  - \
+# RUN:| FileCheck %s --check-prefix=CHECK-INST
+# RUN: llvm-mc -triple=riscv64 -filetype=obj --mattr=+experimental-zvksed %s \
+# RUN:| llvm-objdump -d - | FileCheck %s --check-prefix=CHECK-UNKNOWN
+
+vsm4k.vi v10, v9, 7
+# CHECK-INST: vsm4k.vi v10, v9, 7
+# CHECK-ENCODING: [0x77,0xa5,0x93,0x86]
+# CHECK-ERROR: instruction requires the following: 'Zvksed'
+# CHECK-UNKNOWN: 77 a5 93 86   
+
+vsm4r.vv v10, v9
+# CHECK-INST: vsm4r.vv v10, v9
+# CHECK-ENCODING: [0x77,0x25,0x98,0xa2]
+# CHECK-ERROR: instruction requires the following: 'Zvksed'
+# CHECK-UNKNOWN: 77 25 98 a2   
Index: llvm/test/MC/RISCV/rvv/rv64zvkns.s
===
--- /dev/null
+++ llvm/test/MC/RISCV/rvv/rv64zvkns.s
@@ -0,0 +1,75 @@
+# RUN: llvm-mc -triple=riscv64 -show-encoding --mattr=+experimental-zvkns %s \
+# RUN:| FileCheck %s --check-prefixes=CHECK-ENCODING,CHECK-INST
+# RUN: not llvm-mc -triple=riscv64 -show-encoding %s 2>&1 \
+# RUN:| FileCheck %s --check-prefix=CHECK-ERROR
+# RUN: llvm-mc -triple=riscv64 -filetype=obj --mattr=+experimental-zvkns %s \
+# RUN:| llvm-objdump -d --mattr=+experimental-zvkns  - \
+# RUN:| FileCheck %s --check-prefix=CHECK-INST
+# RUN: llvm-mc -triple=riscv64 -filetype=obj --mattr=+experimental-zvkns %s \
+# RUN:| llvm-objdump -d - | FileCheck %s --check-prefix=CHECK-UNKNOWN
+
+vaesdf.vv v10, v9
+# CHECK-INST: vaesdf.vv v10, v9
+# CHECK-ENCODING: [0x77,0xa5,0x90,0xa2]
+# CHECK-ERROR: instruction requires the following: 'Zvkns'
+# CHECK-UNKNOWN: 77 a5 90 a2   
+
+vaesdf.vs v10, v9
+# CHECK-INST: vaesdf.vs v10, v9
+# CHECK-ENCODING: [0x77,0xa5,0x90,0xa6]
+# CHECK-ERROR: instruction requires the following: 'Zvkns'
+# CHECK-UNKNOWN: 77 a5 90 a6   
+
+vaesef.vv v10, v9
+# CHECK-INST: vaesef.vv v10, v9
+# CHECK-ENCODING: [0x77,0xa5,0x91,0xa2]
+# CHECK-ERROR: instruction requires the following: 'Zvkns'
+# CHECK-UNKNOWN: 77 a5 91 a2   
+   
+vaesef.vs v10, v9
+# CHECK-INST: vaesef.vs v10, v9
+# CHECK-ENCODING: [0x77,0xa5,0x91,0xa6]
+# CHECK-ERROR: instruction requires the following: 'Zvkns'

[PATCH] D139387: [Clang] Support policy function for all vector segment load.

2022-12-05 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added a comment.

Title is not clear this is NFC and only adding tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139387

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


[PATCH] D139387: [Clang] Support policy function for all vector segment load.

2022-12-05 Thread Brandon Wu via Phabricator via cfe-commits
4vtomat created this revision.
Herald added subscribers: frasercrmck, luismarques, apazos, sameer.abuasal, 
s.egerton, Jim, jocewei, PkmX, the_o, brucehoult, MartinMosbeck, rogfer01, 
edward-jones, zzheng, jrtc27, niosHD, sabuasal, simoncook, johnrusso, rbar, asb.
Herald added a project: All.
4vtomat requested review of this revision.
Herald added subscribers: cfe-commits, pcwang-thead, MaskRay.
Herald added a project: clang.

This patch fixed the missing test cases from: 
010f329803c84e43ec15ffaff7b6e26b032cbcc6 



Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D139387

Files:
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vlseg.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlseg.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlseg_mask.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vlsegff_mask.c

Index: clang/test/CodeGen/RISCV/rvv-intrinsics/vlsegff_mask.c
===
--- clang/test/CodeGen/RISCV/rvv-intrinsics/vlsegff_mask.c
+++ clang/test/CodeGen/RISCV/rvv-intrinsics/vlsegff_mask.c
@@ -8204,3 +8204,107 @@
 void test_vlseg2e16ff_v_f16m4_m (vfloat16m4_t *v0, vfloat16m4_t *v1, vbool4_t mask, vfloat16m4_t maskedoff0, vfloat16m4_t maskedoff1, const _Float16 *base, size_t *new_vl, size_t vl) {
   return vlseg2e16ff_v_f16m4_m(v0, v1, mask, maskedoff0, maskedoff1, base, new_vl, vl);
 }
+
+// CHECK-RV32-LABEL: @test_vlseg2e32ff_v_u32mf2_tuma(
+// CHECK-RV32-NEXT:  entry:
+// CHECK-RV32-NEXT:[[TMP0:%.*]] = call { , , i32 } @llvm.riscv.vlseg2ff.mask.nxv1i32.i32( [[MERGE0:%.*]],  [[MERGE1:%.*]], i32* [[BASE:%.*]],  [[MASK:%.*]], i32 [[VL:%.*]], i32 2)
+// CHECK-RV32-NEXT:[[TMP1:%.*]] = extractvalue { , , i32 } [[TMP0]], 0
+// CHECK-RV32-NEXT:store  [[TMP1]], * [[V0:%.*]], align 4
+// CHECK-RV32-NEXT:[[TMP2:%.*]] = extractvalue { , , i32 } [[TMP0]], 1
+// CHECK-RV32-NEXT:store  [[TMP2]], * [[V1:%.*]], align 4
+// CHECK-RV32-NEXT:[[TMP3:%.*]] = extractvalue { , , i32 } [[TMP0]], 2
+// CHECK-RV32-NEXT:store i32 [[TMP3]], i32* [[NEW_VL:%.*]], align 4
+// CHECK-RV32-NEXT:ret void
+//
+// CHECK-RV64-LABEL: @test_vlseg2e32ff_v_u32mf2_tuma(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call { , , i64 } @llvm.riscv.vlseg2ff.mask.nxv1i32.i64( [[MERGE0:%.*]],  [[MERGE1:%.*]], i32* [[BASE:%.*]],  [[MASK:%.*]], i64 [[VL:%.*]], i64 2)
+// CHECK-RV64-NEXT:[[TMP1:%.*]] = extractvalue { , , i64 } [[TMP0]], 0
+// CHECK-RV64-NEXT:store  [[TMP1]], * [[V0:%.*]], align 4
+// CHECK-RV64-NEXT:[[TMP2:%.*]] = extractvalue { , , i64 } [[TMP0]], 1
+// CHECK-RV64-NEXT:store  [[TMP2]], * [[V1:%.*]], align 4
+// CHECK-RV64-NEXT:[[TMP3:%.*]] = extractvalue { , , i64 } [[TMP0]], 2
+// CHECK-RV64-NEXT:store i64 [[TMP3]], i64* [[NEW_VL:%.*]], align 4
+// CHECK-RV64-NEXT:ret void
+//
+void test_vlseg2e32ff_v_u32mf2_tuma(vuint32mf2_t *v0, vuint32mf2_t *v1, vbool64_t mask, vuint32mf2_t merge0, vuint32mf2_t merge1, const uint32_t *base, size_t *new_vl, size_t vl) {
+  return vlseg2e32ff_v_u32mf2_tuma(v0, v1, mask, merge0, merge1, base, new_vl, vl);
+}
+
+// CHECK-RV32-LABEL: @test_vlseg2e32ff_v_u32mf2_tumu(
+// CHECK-RV32-NEXT:  entry:
+// CHECK-RV32-NEXT:[[TMP0:%.*]] = call { , , i32 } @llvm.riscv.vlseg2ff.mask.nxv1i32.i32( [[MERGE0:%.*]],  [[MERGE1:%.*]], i32* [[BASE:%.*]],  [[MASK:%.*]], i32 [[VL:%.*]], i32 0)
+// CHECK-RV32-NEXT:[[TMP1:%.*]] = extractvalue { , , i32 } [[TMP0]], 0
+// CHECK-RV32-NEXT:store  [[TMP1]], * [[V0:%.*]], align 4
+// CHECK-RV32-NEXT:[[TMP2:%.*]] = extractvalue { , , i32 } [[TMP0]], 1
+// CHECK-RV32-NEXT:store  [[TMP2]], * [[V1:%.*]], align 4
+// CHECK-RV32-NEXT:[[TMP3:%.*]] = extractvalue { , , i32 } [[TMP0]], 2
+// CHECK-RV32-NEXT:store i32 [[TMP3]], i32* [[NEW_VL:%.*]], align 4
+// CHECK-RV32-NEXT:ret void
+//
+// CHECK-RV64-LABEL: @test_vlseg2e32ff_v_u32mf2_tumu(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call { , , i64 } @llvm.riscv.vlseg2ff.mask.nxv1i32.i64( [[MERGE0:%.*]],  [[MERGE1:%.*]], i32* [[BASE:%.*]],  [[MASK:%.*]], i64 [[VL:%.*]], i64 0)
+// CHECK-RV64-NEXT:[[TMP1:%.*]] = extractvalue { , , i64 } [[TMP0]], 0
+// CHECK-RV64-NEXT:store  [[TMP1]], * [[V0:%.*]], align 4
+// CHECK-RV64-NEXT:[[TMP2:%.*]] = extractvalue { , , i64 } [[TMP0]], 1
+// CHECK-RV64-NEXT:store  [[TMP2]], * [[V1:%.*]], align 4
+// CHECK-RV64-NEXT:[[TMP3:%.*]] = extractvalue { , , i64 } [[TMP0]], 2
+// CHECK-RV64-NEXT:store i64 [[TMP3]], i64* [[NEW_VL:%.*]], align 4
+// CHECK-RV64-NEXT:ret void
+//
+void test_vlseg2e32ff_v_u32mf2_tumu(vuint32mf2_t *v0, vuint32mf2_t *v1, vbool64_t mask, vuint32mf2_t merge0, vuint32mf2_t merge1, const uint32_t *base, size_t *new_vl, size_t vl) {
+  return vlseg2e32ff_v_u32mf2_tumu(v0, v1, mask, merge0, merge1, base, new_vl, vl);
+}
+
+// CHECK-RV32-LABEL: @test_vlseg2e32ff_v_u32mf2_tama(
+// CHECK-RV32-NEXT:

[PATCH] D137059: [Driver] [Modules] Introduce -fsave-std-c++-module-file= to specify the path of the module file (2/2)

2022-12-05 Thread Ben Boeckel via Phabricator via cfe-commits
ben.boeckel added a comment.

In D137059#3934448 , @dblaikie wrote:

> I'm still curious what about the details of other compilers - I think from 
> the sounds of it, @iains suggested GCC doesn't support this yet so we'll need 
> to pick/name the flag ourselves & he's happy to implement whatever we pick? I 
> guess Microsoft's flag naming is sufficiently differently styled as to offer 
> no useful inspiration? Though wouldn't hurt to know what they name it.
>
> Any other examples you had in mind, Ben?

GCC supports naming the output file by asking the "module mapper" where a 
module with a given name lives (also used for finding imported modules). MSVC 
uses the `-ifcOutput` flag to specify where to write any exported module data 
to. See this CMake code which handles the "module mapping" for the various 
compilers: 
https://gitlab.kitware.com/cmake/cmake/-/blob/master/Source/cmCxxModuleMapper.cxx


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

https://reviews.llvm.org/D137059

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


[PATCH] D138105: [PowerPC] Support test data class intrinsic of 128-bit float

2022-12-05 Thread ChenZheng via Phabricator via cfe-commits
shchenz accepted this revision as: shchenz.
shchenz added a comment.
This revision is now accepted and ready to land.

LGTM. Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138105

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


[PATCH] D139154: [clang-doc] Add template support

2022-12-05 Thread Paul Kirth via Phabricator via cfe-commits
paulkirth added a comment.

Can we also update the end-to-end tests with some relevant test cases? I think 
that's especially important, given that I'm not sure the unittests are running 
as part of the normal test suite.

Overall this is mostly LGTM with some minor comments/questions.




Comment at: clang-tools-extra/clang-doc/BitcodeReader.cpp:376
+TemplateSpecializationInfo *I) {
+  switch (ID) {
+  case TEMPLATE_SPECIALIZATION_OF:

Do you expect to add handling for more cases here? If so, a comment with FIXME 
or TODO is appropriate. If not, then I'm not sure a `switch` is a better choice 
than a branch ...



Comment at: clang-tools-extra/unittests/clang-doc/SerializeTest.cpp:631
 
+TEST(SerializeTests, emitFunctionTemplate) {
+  EmittedInfoList Infos;

I may have missed these cases in the test file, so if they exist just ignore me.

-  a template w/ no concrete types e.g., `template void GetFoo(T);` 
This seems like a very common case, so it would be good to have a test 
explicitly for it. 
- a nested template, both where the inner template type is known, and where it 
is not.



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

https://reviews.llvm.org/D139154

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


[PATCH] D137379: [-Wunsafe-buffer-usage] Add warnings for unsafe buffer accesses by array subscript operations

2022-12-05 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added inline comments.



Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:155-176
+class ArraySubscriptGadget : public UnsafeGadget {
+  const ArraySubscriptExpr *ASE;
+
+public:
+  ArraySubscriptGadget(const MatchFinder::MatchResult &Result)
+  : UnsafeGadget(Kind::ArraySubscript),
+ASE(Result.Nodes.getNodeAs("arraySubscr")) {}

Carryover from the nearby patch - let's make a named constant for "arraySubscr"!




Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:175
+
+  const Stmt *getBaseStmt() const override { return ASE; }
+};

Carryover from nearby patch - let's use covariant return types!


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

https://reviews.llvm.org/D137379

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


[clang] def7207 - [X86][clang] Lift _BitInt() supported max width.

2022-12-05 Thread Freddy Ye via cfe-commits

Author: Freddy Ye
Date: 2022-12-06T11:02:27+08:00
New Revision: def720726b73e0d7ab139376ab3ea955f25f4d89

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

LOG: [X86][clang] Lift _BitInt() supported max width.

Reviewed By: mgehre-amd

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

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/lib/Basic/Targets/X86.h
clang/test/CodeGen/ext-int-cc.c
clang/test/Lexer/bitint-constants.c
clang/test/Preprocessor/cuda-types.cu
clang/test/Sema/large-bit-int.c
clang/test/SemaCXX/ext-int.cpp

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index fe6435d7c8c45..adce36bb92363 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -763,6 +763,7 @@ X86 Support in Clang
   * Support intrinsic of ``_mm(256)_cvtneps_avx_pbh``.
 - ``-march=raptorlake`` and ``-march=meteorlake`` are now supported.
 - ``-march=sierraforest``, ``-march=graniterapids`` and ``-march=grandridge`` 
are now supported.
+- Lift _BitInt() supported max width from 128 to 8388608.
 
 WebAssembly Support in Clang
 

diff  --git a/clang/lib/Basic/Targets/X86.h b/clang/lib/Basic/Targets/X86.h
index 1fda9a53d9caf..0f0ca5d9a5f95 100644
--- a/clang/lib/Basic/Targets/X86.h
+++ b/clang/lib/Basic/Targets/X86.h
@@ -492,6 +492,9 @@ class LLVM_LIBRARY_VISIBILITY X86_32TargetInfo : public 
X86TargetInfo {
   ArrayRef getTargetBuiltins() const override;
 
   bool hasBitIntType() const override { return true; }
+  size_t getMaxBitIntWidth() const override {
+return llvm::IntegerType::MAX_INT_BITS;
+  }
 };
 
 class LLVM_LIBRARY_VISIBILITY NetBSDI386TargetInfo
@@ -799,6 +802,9 @@ class LLVM_LIBRARY_VISIBILITY X86_64TargetInfo : public 
X86TargetInfo {
   ArrayRef getTargetBuiltins() const override;
 
   bool hasBitIntType() const override { return true; }
+  size_t getMaxBitIntWidth() const override {
+return llvm::IntegerType::MAX_INT_BITS;
+  }
 };
 
 // x86-64 Windows target

diff  --git a/clang/test/CodeGen/ext-int-cc.c b/clang/test/CodeGen/ext-int-cc.c
index 5aac4db5f7aaa..bcf29fc1309de 100644
--- a/clang/test/CodeGen/ext-int-cc.c
+++ b/clang/test/CodeGen/ext-int-cc.c
@@ -131,10 +131,10 @@ void ParamPassing3(_BitInt(15) a, _BitInt(31) b) {}
 // are negated. This will give an error when a target does support larger
 // _BitInt widths to alert us to enable the test.
 void ParamPassing4(_BitInt(129) a) {}
-// LIN64-NOT: define{{.*}} void @ParamPassing4(ptr byval(i129) align 8 %{{.+}})
-// WIN64-NOT: define dso_local void @ParamPassing4(ptr %{{.+}})
-// LIN32-NOT: define{{.*}} void @ParamPassing4(ptr %{{.+}})
-// WIN32-NOT: define dso_local void @ParamPassing4(ptr %{{.+}})
+// LIN64: define{{.*}} void @ParamPassing4(ptr byval(i129) align 8 %{{.+}})
+// WIN64: define dso_local void @ParamPassing4(ptr %{{.+}})
+// LIN32: define{{.*}} void @ParamPassing4(ptr %{{.+}})
+// WIN32: define dso_local void @ParamPassing4(ptr %{{.+}})
 // NACL-NOT: define{{.*}} void @ParamPassing4(ptr byval(i129) align 8 %{{.+}})
 // NVPTX64-NOT: define{{.*}} void @ParamPassing4(ptr byval(i129) align 8 
%{{.+}})
 // NVPTX-NOT: define{{.*}} void @ParamPassing4(ptr byval(i129) align 8 %{{.+}})
@@ -290,10 +290,10 @@ _BitInt(128) ReturnPassing4(void){}
 
 #if __BITINT_MAXWIDTH__ > 128
 _BitInt(129) ReturnPassing5(void){}
-// LIN64-NOT: define{{.*}} void @ReturnPassing5(ptr noalias sret
-// WIN64-NOT: define dso_local void @ReturnPassing5(ptr noalias sret
-// LIN32-NOT: define{{.*}} void @ReturnPassing5(ptr noalias sret
-// WIN32-NOT: define dso_local void @ReturnPassing5(ptr noalias sret
+// LIN64: define{{.*}} void @ReturnPassing5(ptr noalias sret
+// WIN64: define dso_local void @ReturnPassing5(ptr noalias sret
+// LIN32: define{{.*}} void @ReturnPassing5(ptr noalias sret
+// WIN32: define dso_local void @ReturnPassing5(ptr noalias sret
 // NACL-NOT: define{{.*}} void @ReturnPassing5(ptr noalias sret
 // NVPTX64-NOT: define{{.*}} i129 @ReturnPassing5(
 // NVPTX-NOT: define{{.*}} i129 @ReturnPassing5(

diff  --git a/clang/test/Lexer/bitint-constants.c 
b/clang/test/Lexer/bitint-constants.c
index 2ff35e8207786..4932cf4e9ef40 100644
--- a/clang/test/Lexer/bitint-constants.c
+++ b/clang/test/Lexer/bitint-constants.c
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -std=c2x -fsyntax-only -verify -Wno-unused %s
+// RUN: %clang_cc1 -triple aarch64-unknown-unknown -std=c2x -fsyntax-only 
-verify -Wno-unused %s
 
 // Test that the preprocessor behavior makes sense.
 #if 1wb != 1

diff  --git a/clang/test/Preprocessor/cuda-types.cu 
b/clang/test/Preprocessor/cuda-types.cu
index 0ff0d057830dc..0e8aa2414778c 100644
--- a/clang/test/Preprocessor/cuda-types.cu
+++ b/clang/test/Preprocessor/cuda-types.cu
@@ -1,6 +1,6 @@
 // C

[PATCH] D139170: [X86][clang] Lift _BitInt() supported max width.

2022-12-05 Thread Freddy, Ye 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 rGdef720726b73: [X86][clang] Lift _BitInt() supported max 
width. (authored by FreddyYe).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139170

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Basic/Targets/X86.h
  clang/test/CodeGen/ext-int-cc.c
  clang/test/Lexer/bitint-constants.c
  clang/test/Preprocessor/cuda-types.cu
  clang/test/Sema/large-bit-int.c
  clang/test/SemaCXX/ext-int.cpp

Index: clang/test/SemaCXX/ext-int.cpp
===
--- clang/test/SemaCXX/ext-int.cpp
+++ clang/test/SemaCXX/ext-int.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s -Wimplicit-int-conversion -Wno-unused -Wunevaluated-expression -triple x86_64-gnu-linux
+// RUN: %clang_cc1 -fsyntax-only -verify %s -Wimplicit-int-conversion -Wno-unused -Wunevaluated-expression -triple aarch64-unknown-unknown
 
 template
 struct HasExtInt {
Index: clang/test/Sema/large-bit-int.c
===
--- clang/test/Sema/large-bit-int.c
+++ clang/test/Sema/large-bit-int.c
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fexperimental-max-bitint-width=1024 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple aarch64-unknown-unknown -fexperimental-max-bitint-width=1024 -fsyntax-only -verify %s
 
 void f() {
   _Static_assert(__BITINT_MAXWIDTH__ == 1024, "Macro value is unexpected.");
Index: clang/test/Preprocessor/cuda-types.cu
===
--- clang/test/Preprocessor/cuda-types.cu
+++ clang/test/Preprocessor/cuda-types.cu
@@ -1,6 +1,6 @@
 // Check that types, widths, __CLANG_ATOMIC* macros, etc. match on the host and
-// device sides of CUDA compilations.  Note that we filter out long double, as
-// this is intentionally different on host and device.
+// device sides of CUDA compilations. Note that we filter out long double and
+// maxwidth of _BitInt(), as this is intentionally different on host and device.
 //
 // Also ignore __CLANG_ATOMIC_LLONG_LOCK_FREE on i386. The default host CPU for
 // an i386 triple is typically at least an i586, which has cmpxchg8b (Clang
@@ -14,40 +14,40 @@
 
 // RUN: %clang --cuda-host-only -nocudainc -target i386-unknown-linux-gnu -x cuda -E -dM -o - /dev/null \
 // RUN:   | grep -E 'define __[^ ]*(TYPE|MAX|SIZEOF|WIDTH)|define __CLANG_ATOMIC' \
-// RUN:   | grep -Ev '__LDBL|_LONG_DOUBLE|_ATOMIC_LLONG_LOCK_FREE' > %t/i386-host-defines-filtered
+// RUN:   | grep -Ev '__LDBL|_LONG_DOUBLE|BITINT_MAXWIDTH|_ATOMIC_LLONG_LOCK_FREE' > %t/i386-host-defines-filtered
 // RUN: %clang --cuda-device-only -nocudainc -nocudalib -target i386-unknown-linux-gnu -x cuda -E -dM -o - /dev/null \
 // RUN:   | grep -E 'define __[^ ]*(TYPE|MAX|SIZEOF|WIDTH)|define __CLANG_ATOMIC' \
-// RUN:   | grep -Ev '__LDBL|_LONG_DOUBLE|_ATOMIC_LLONG_LOCK_FREE' > %t/i386-device-defines-filtered
+// RUN:   | grep -Ev '__LDBL|_LONG_DOUBLE|BITINT_MAXWIDTH|_ATOMIC_LLONG_LOCK_FREE' > %t/i386-device-defines-filtered
 // RUN: diff %t/i386-host-defines-filtered %t/i386-device-defines-filtered
 
 // RUN: %clang --cuda-host-only -nocudainc -target x86_64-unknown-linux-gnu -x cuda -E -dM -o - /dev/null \
 // RUN:   | grep -E 'define __[^ ]*(TYPE|MAX|SIZEOF|WIDTH)|define __CLANG_ATOMIC' \
-// RUN:   | grep -Ev '__LDBL|_LONG_DOUBLE' > %t/x86_64-host-defines-filtered
+// RUN:   | grep -Ev '__LDBL|_LONG_DOUBLE|BITINT_MAXWIDTH' > %t/x86_64-host-defines-filtered
 // RUN: %clang --cuda-device-only -nocudainc -nocudalib -target x86_64-unknown-linux-gnu -x cuda -E -dM -o - /dev/null \
 // RUN:   | grep -E 'define __[^ ]*(TYPE|MAX|SIZEOF|WIDTH)|define __CLANG_ATOMIC' \
-// RUN:   | grep -Ev '__LDBL|_LONG_DOUBLE' > %t/x86_64-device-defines-filtered
+// RUN:   | grep -Ev '__LDBL|_LONG_DOUBLE|BITINT_MAXWIDTH' > %t/x86_64-device-defines-filtered
 // RUN: diff %t/x86_64-host-defines-filtered %t/x86_64-device-defines-filtered
 
 // RUN: %clang --cuda-host-only -nocudainc -target powerpc64-unknown-linux-gnu -x cuda -E -dM -o - /dev/null \
 // RUN:   | grep -E 'define __[^ ]*(TYPE|MAX|SIZEOF|WIDTH)|define __CLANG_ATOMIC' \
-// RUN:   | grep -Ev '__LDBL|_LONG_DOUBLE' > %t/powerpc64-host-defines-filtered
+// RUN:   | grep -Ev '__LDBL|_LONG_DOUBLE|BITINT_MAXWIDTH' > %t/powerpc64-host-defines-filtered
 // RUN: %clang --cuda-device-only -nocudainc -nocudalib -target powerpc64-unknown-linux-gnu -x cuda -E -dM -o - /dev/null \
 // RUN:   | grep -E 'define __[^ ]*(TYPE|MAX|SIZEOF|WIDTH)|define __CLANG_ATOMIC' \
-// RUN:   | grep -Ev '__LDBL|_LONG_DOUBLE' > %t/powerpc64-device-defines-filtered
+// RUN:   | grep -Ev '__LDBL|_LONG_DOUBLE|BITINT_MAXWIDTH' > %t/powerpc64-device-defines-filtered
 // RUN: diff %t/powerpc64-host-defines-filtered %t/powerpc64-device-defines-filtered
 
 // RUN: %clang --cu

[PATCH] D137379: [-Wunsafe-buffer-usage] Add warnings for unsafe buffer accesses by array subscript operations

2022-12-05 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added inline comments.



Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:168-169
+  static Matcher matcher() {
+// FIXME: What if the index is integer literal 0? Should this be
+// a safe gadget in this case?
+return stmt(

xazax.hun wrote:
> NoQ wrote:
> > aaron.ballman wrote:
> > > xazax.hun wrote:
> > > > As per some of the discussions, in the future the compiler might be 
> > > > able to recognize certain safe patterns, e.g., when there is a simple 
> > > > for loop with known bounds, or when both the index and the array size 
> > > > is statically known.
> > > > 
> > > > I think here we need to make a very important design decision: Do we 
> > > > want the gadgets to have the right "safety" category when it is created 
> > > > (e.g., we have to be able to decide if a gadget is safe or not using 
> > > > matchers), or do we want some mechanisms to be able to promote an 
> > > > unsafe gadget to be a safe one? (E.g., do we want to be able to prove 
> > > > some unsafe gadgets safe using dataflow analysis in a later pass?)
> > > (FWIW, this is a great question and I really appreciate you asking it!)
> > My original design implies that safe gadgets are a separate hierarchy, so 
> > there will be a new gadget class for index zero, and this gadget will be 
> > changed to skip index zero. But I don't immediately see why such early 
> > separation is strictly necessary, other than for a bit of extra type safety 
> > (extra virtual methods of the `UnsafeGadget` class don't make sense on safe 
> > gadgets). We *do* have time to make this distinction later, before we get 
> > to emitting warnings.
> > 
> > So maybe eventually we'll end up replacing `isSafe()` with a pure virtual 
> > method and deprecate `SafeGadget` and `UnsafeGadget` base classes, if we 
> > see it cause too much duplication or it turns out that the extra analysis 
> > necessary to establish safety can't be nicely implemented in ASTMatchers. 
> > In this case I'll admit that I over-engineered it a bit.
> I'd strongly prefer `isSafe()` method over inheritance. While adding safe and 
> unsafe gadgets for zero indices is not too bad, if we plan to expand this to 
> more cases, like known array size + compile time constant index, it will get 
> harder and harder to keep all the gadgets in sync. We can end up missing 
> cases or detecting a code snippet both as safe and unsafe. The `isSafe` 
> method would basically get rid of a whole class of problems, where safe and 
> unsafe versions of the gadgets are overlapping. That being said, I am not 
> insisting doing this change in this PR, it is OK doing the change later in a 
> follow-up.
Ok so we've had an interesting conversation about this, it's actually harder 
than that and we'll probably have a much more divergence between unsafe gadgets 
and safe gadgets covering these operations. The problem is that most unsafe 
gadgets don't allow fixing code anyway, you typically need more context. For 
example, `ptr[i]` may represent unsafe code and `ptr[0]` may represent safe 
code, but that doesn't make `ptr[0]` a safe gadget, because it doesn't make it 
//fixable//. In particular, `&span[0]` crashes when `span` is empty, whereas 
`ptr[0]` doesn't crash when `ptr` points to one-past-end of the array, so 
blinding replacing `ptr[0]` with `span[0]` will break some code.

Of course even simple `ptr`, regardless of context, is always fixable to 
`span.data()`. But that's a low-quality fix that ruins libc++ runtime checks. 
So we'll do our best to avoid such fixes unless the extra context makes them 
inevitable.

So I suspect that we'll allow safe and unsafe gadgets to //partially overlap// 
and exclude unsafe gadgets from fixit machine entirely (i.e. move the 
`getFixits()` method to the `SafeGadget` class).

So, like I said in https://reviews.llvm.org/D137348?id=472990#inline-1345337, 
@malavikasamak is looking into this more deeply.


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

https://reviews.llvm.org/D137379

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


[PATCH] D137348: [-Wunsafe-buffer-usage] Introduce an abstraction for fixable code patterns.

2022-12-05 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ marked an inline comment as done.
NoQ added inline comments.



Comment at: clang/include/clang/Analysis/Analyses/UnsafeBufferUsageGadgets.def:1
+//=- UnsafeBufferUsageGadgets.def - List of ways to use a buffer --*- C++ 
-*-=//
+//

NoQ wrote:
> aaron.ballman wrote:
> > Is this file named properly if it is also going to handle `SAFE_GADGET`?
> UnsafeBufferUsage is the name of the analysis. It's somewhat valuable to keep 
> this file next to `UnsafeBufferUsage.h` so that it was obvious at a glance 
> that these two files work together.
> 
> I'm open to renaming the entire analysis though, a non-judgemental 
> "BufferUsage analysis" totally works for me, WDYT?
> 
> Or I can make a folder. But I don't expect more than 2 files in this folder.
I expect @malavikasamak to do some renaming in a follow-up patch in the near 
future as she seeks to introduce more precise distinction between unsafe and 
safe gadgets.



Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:40
+
+  /// Determine if a kind is a safe kind. Slower than calling isSafe().
+  static bool isSafeKind(Kind K) {

steakhal wrote:
> We could have a `GADGET_RANGE(UnsafeGadgets, Increment, Decrement)`, which 
> could expand to `BEGIN_##x = Increment, END_##x = Decrement,` when declaring 
> the `Kind` enum, similarly how `SymExpr::Kind::Begin_BINARYSYMEXPRS` is 
> defined.
> That way this code could look like:
> ```lang=C++
> return !(Kind::Begin_UnsafeGadgets <= K && K <= Kind::End_UnsafeGadgets);
> ```
Nuked this entire facility. It's always possible to simply call `isSafe()`.



Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:87
+  static bool classof(const Gadget *G) { return !isSafeKind(G->getKind()); }
+  bool isSafe() const override { return false; }
+};

steakhal wrote:
> 
I love that!



Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:107
+/// out of bounds.
+class IncrementGadget : public UnsafeGadget {
+  const UnaryOperator *Op;

NoQ wrote:
> xazax.hun wrote:
> > How deep will the `Gadget` Hierarchy be? Using inheritance only to classify 
> > safe and unsafe gadgets feels like a very heavy weight solution to a 
> > relatively simple problem.
> I'm expecting `UnsafeGadget` and `SafeGadget` to grow some common methods in 
> the future. But I'm already second-guessing this decision 
> (https://reviews.llvm.org/D137379?id=473092#inline-1340017) so I guess I'll 
> ungrow these intermediate classes if things become too tedious.
To answer the original question, `SafeGadget` and `UnsafeGadget` are most 
likely going to be the only intermediate class. So, it'll be 2 abstract classes 
deep.



Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:163
 
 void run(const MatchFinder::MatchResult &Result) override {
+  // Figure out which matcher we've found, and call the appropriate

NoQ wrote:
> steakhal wrote:
> > I wonder if we should assert that we only expect exactly one match (entry) 
> > inside `Result.Nodes`.
> You mean like, exactly one if-statement succeeds? That'd require us to run 
> the entire list every time (at least in debug mode) but it's probably not too 
> bad. I'll look for a clean solution^^
Ok I added this huge `#ifdef NDEBUG` thing. I agree that it's valuable but I'm 
also somewhat worried that it may diverge from the non-debug code.


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

https://reviews.llvm.org/D137348

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


[PATCH] D137348: [-Wunsafe-buffer-usage] Introduce an abstraction for fixable code patterns.

2022-12-05 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ updated this revision to Diff 480310.
NoQ marked 17 inline comments as done.
NoQ added a comment.

Address review comments.


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

https://reviews.llvm.org/D137348

Files:
  clang/include/clang/Analysis/Analyses/UnsafeBufferUsageGadgets.def
  clang/lib/Analysis/UnsafeBufferUsage.cpp

Index: clang/lib/Analysis/UnsafeBufferUsage.cpp
===
--- clang/lib/Analysis/UnsafeBufferUsage.cpp
+++ clang/lib/Analysis/UnsafeBufferUsage.cpp
@@ -13,11 +13,123 @@
 using namespace clang;
 using namespace ast_matchers;
 
-namespace {
-// TODO: Better abstractions over gadgets.
-using GadgetList = std::vector;
+// Because we're dealing with raw pointers, let's define what we mean by that.
+static auto hasPointerType() {
+  return anyOf(hasType(pointerType()),
+   hasType(autoType(hasDeducedType(
+   hasUnqualifiedDesugaredType(pointerType());
 }
 
+namespace {
+/// Gadget is an individual operation in the code that may be of interest to
+/// this analysis. Each (non-abstract) subclass corresponds to a specific
+/// rigid AST structure that constitutes an operation on a pointer-type object.
+/// Discovery of a gadget in the code corresponds to claiming that we understand
+/// what this part of code is doing well enough to potentially improve it.
+/// Gadgets can be unsafe (immediately deserving a warning) or safe (not
+/// deserving a warning per se, but affecting our decision-making process
+/// nonetheless).
+class Gadget {
+public:
+  enum class Kind {
+#define GADGET(x) x,
+#include "clang/Analysis/Analyses/UnsafeBufferUsageGadgets.def"
+  };
+
+  /// Common type of ASTMatchers used for discovering gadgets.
+  /// Useful for implementing the static matcher() methods
+  /// that are expected from all non-abstract subclasses.
+  using Matcher = decltype(stmt());
+
+  Gadget(Kind K) : K(K) {}
+
+  Kind getKind() const { return K; }
+
+  virtual bool isSafe() const = 0;
+  virtual const Stmt *getBaseStmt() const = 0;
+
+  virtual ~Gadget() = default;
+
+private:
+  Kind K;
+};
+
+using GadgetList = std::vector>;
+
+/// Unsafe gadgets correspond to unsafe code patterns that warrants
+/// an immediate warning.
+class UnsafeGadget : public Gadget {
+public:
+  UnsafeGadget(Kind K) : Gadget(K) {}
+
+  static bool classof(const Gadget *G) { return G->isSafe(); }
+  bool isSafe() const final { return false; }
+};
+
+/// Safe gadgets correspond to code patterns that aren't unsafe but need to be
+/// properly recognized in order to emit correct warnings and fixes over unsafe
+/// gadgets. For example, if a raw pointer-type variable is replaced by
+/// a safe C++ container, every use of such variable may need to be
+/// carefully considered and possibly updated.
+class SafeGadget : public Gadget {
+public:
+  SafeGadget(Kind K) : Gadget(K) {}
+
+  static bool classof(const Gadget *G) { return !G->isSafe(); }
+  bool isSafe() const final { return true; }
+};
+
+/// An increment of a pointer-type value is unsafe as it may run the pointer
+/// out of bounds.
+class IncrementGadget : public UnsafeGadget {
+  static constexpr const char *const OpTag = "op";
+  const UnaryOperator *Op;
+
+public:
+  IncrementGadget(const MatchFinder::MatchResult &Result)
+  : UnsafeGadget(Kind::Increment),
+Op(Result.Nodes.getNodeAs(OpTag)) {}
+
+  static bool classof(const Gadget *G) {
+return G->getKind() == Kind::Increment;
+  }
+
+  static Matcher matcher() {
+return stmt(unaryOperator(
+  hasOperatorName("++"),
+  hasUnaryOperand(ignoringParenImpCasts(hasPointerType()))
+).bind(OpTag));
+  }
+
+  const UnaryOperator *getBaseStmt() const override { return Op; }
+};
+
+/// A decrement of a pointer-type value is unsafe as it may run the pointer
+/// out of bounds.
+class DecrementGadget : public UnsafeGadget {
+  static constexpr const char *const OpTag = "op";
+  const UnaryOperator *Op;
+
+public:
+  DecrementGadget(const MatchFinder::MatchResult &Result)
+  : UnsafeGadget(Kind::Decrement),
+Op(Result.Nodes.getNodeAs(OpTag)) {}
+
+  static bool classof(const Gadget *G) {
+return G->getKind() == Kind::Decrement;
+  }
+
+  static Matcher matcher() {
+return stmt(unaryOperator(
+  hasOperatorName("--"),
+  hasUnaryOperand(ignoringParenImpCasts(hasPointerType()))
+).bind(OpTag));
+  }
+
+  const UnaryOperator *getBaseStmt() const override { return Op; }
+};
+} // namespace
+
 // Scan the function and return a list of gadgets found with provided kits.
 static GadgetList findGadgets(const Decl *D) {
 
@@ -28,40 +140,57 @@
 GadgetFinderCallback(GadgetList &Output) : Output(Output) {}
 
 void run(const MatchFinder::MatchResult &Result) override {
-  Output.push_back(Result.Nodes.getNodeAs("root_node"));
+  // Figure out which matcher we've found, and call the appropriate
+  // subclass constructor.
+  // FIXME: Can we d

[PATCH] D138807: [RISCV] Support vector crypto extension ISA string and assembly

2022-12-05 Thread Brandon Wu via Phabricator via cfe-commits
4vtomat added a comment.

In D138807#3972441 , @craig.topper 
wrote:

> In D138807#3962417 , @craig.topper 
> wrote:
>
>> Anything that uses OP-P needs to have a DecoderNamespace assigned and 
>> RISCVDisassembler::getInstruction will need to lookup that table when V/Zve 
>> is enabled. Otherwise we will have a conflict if the P extension is ever 
>> commited to LLVM.
>
> I think we can ignore the OP-P conflict until P is ratified and added to LLVM.

Sure, thanks for reminding!




Comment at: llvm/lib/Support/RISCVISAInfo.cpp:827
 {{"zvfh"}, {ImpliedExtsZvfh}},
+{{"zvkb"}, {ImpliedExtsV}},
+{{"zvkg"}, {ImpliedExtsV}},

craig.topper wrote:
> Does Crypto really require V or could it work with Zve?
I think Zve is enough to get it work, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138807

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


[PATCH] D139170: [X86][clang] Lift _BitInt() supported max width.

2022-12-05 Thread Freddy, Ye via Phabricator via cfe-commits
FreddyYe added a comment.

THX for review. I'll land!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139170

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


[PATCH] D139170: [X86][clang] Lift _BitInt() supported max width.

2022-12-05 Thread Freddy, Ye via Phabricator via cfe-commits
FreddyYe updated this revision to Diff 480305.
FreddyYe added a comment.

Rebase and add release note.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139170

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Basic/Targets/X86.h
  clang/test/CodeGen/ext-int-cc.c
  clang/test/Lexer/bitint-constants.c
  clang/test/Preprocessor/cuda-types.cu
  clang/test/Sema/large-bit-int.c
  clang/test/SemaCXX/ext-int.cpp

Index: clang/test/SemaCXX/ext-int.cpp
===
--- clang/test/SemaCXX/ext-int.cpp
+++ clang/test/SemaCXX/ext-int.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s -Wimplicit-int-conversion -Wno-unused -Wunevaluated-expression -triple x86_64-gnu-linux
+// RUN: %clang_cc1 -fsyntax-only -verify %s -Wimplicit-int-conversion -Wno-unused -Wunevaluated-expression -triple aarch64-unknown-unknown
 
 template
 struct HasExtInt {
Index: clang/test/Sema/large-bit-int.c
===
--- clang/test/Sema/large-bit-int.c
+++ clang/test/Sema/large-bit-int.c
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fexperimental-max-bitint-width=1024 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple aarch64-unknown-unknown -fexperimental-max-bitint-width=1024 -fsyntax-only -verify %s
 
 void f() {
   _Static_assert(__BITINT_MAXWIDTH__ == 1024, "Macro value is unexpected.");
Index: clang/test/Preprocessor/cuda-types.cu
===
--- clang/test/Preprocessor/cuda-types.cu
+++ clang/test/Preprocessor/cuda-types.cu
@@ -1,6 +1,6 @@
 // Check that types, widths, __CLANG_ATOMIC* macros, etc. match on the host and
-// device sides of CUDA compilations.  Note that we filter out long double, as
-// this is intentionally different on host and device.
+// device sides of CUDA compilations. Note that we filter out long double and
+// maxwidth of _BitInt(), as this is intentionally different on host and device.
 //
 // Also ignore __CLANG_ATOMIC_LLONG_LOCK_FREE on i386. The default host CPU for
 // an i386 triple is typically at least an i586, which has cmpxchg8b (Clang
@@ -14,40 +14,40 @@
 
 // RUN: %clang --cuda-host-only -nocudainc -target i386-unknown-linux-gnu -x cuda -E -dM -o - /dev/null \
 // RUN:   | grep -E 'define __[^ ]*(TYPE|MAX|SIZEOF|WIDTH)|define __CLANG_ATOMIC' \
-// RUN:   | grep -Ev '__LDBL|_LONG_DOUBLE|_ATOMIC_LLONG_LOCK_FREE' > %t/i386-host-defines-filtered
+// RUN:   | grep -Ev '__LDBL|_LONG_DOUBLE|BITINT_MAXWIDTH|_ATOMIC_LLONG_LOCK_FREE' > %t/i386-host-defines-filtered
 // RUN: %clang --cuda-device-only -nocudainc -nocudalib -target i386-unknown-linux-gnu -x cuda -E -dM -o - /dev/null \
 // RUN:   | grep -E 'define __[^ ]*(TYPE|MAX|SIZEOF|WIDTH)|define __CLANG_ATOMIC' \
-// RUN:   | grep -Ev '__LDBL|_LONG_DOUBLE|_ATOMIC_LLONG_LOCK_FREE' > %t/i386-device-defines-filtered
+// RUN:   | grep -Ev '__LDBL|_LONG_DOUBLE|BITINT_MAXWIDTH|_ATOMIC_LLONG_LOCK_FREE' > %t/i386-device-defines-filtered
 // RUN: diff %t/i386-host-defines-filtered %t/i386-device-defines-filtered
 
 // RUN: %clang --cuda-host-only -nocudainc -target x86_64-unknown-linux-gnu -x cuda -E -dM -o - /dev/null \
 // RUN:   | grep -E 'define __[^ ]*(TYPE|MAX|SIZEOF|WIDTH)|define __CLANG_ATOMIC' \
-// RUN:   | grep -Ev '__LDBL|_LONG_DOUBLE' > %t/x86_64-host-defines-filtered
+// RUN:   | grep -Ev '__LDBL|_LONG_DOUBLE|BITINT_MAXWIDTH' > %t/x86_64-host-defines-filtered
 // RUN: %clang --cuda-device-only -nocudainc -nocudalib -target x86_64-unknown-linux-gnu -x cuda -E -dM -o - /dev/null \
 // RUN:   | grep -E 'define __[^ ]*(TYPE|MAX|SIZEOF|WIDTH)|define __CLANG_ATOMIC' \
-// RUN:   | grep -Ev '__LDBL|_LONG_DOUBLE' > %t/x86_64-device-defines-filtered
+// RUN:   | grep -Ev '__LDBL|_LONG_DOUBLE|BITINT_MAXWIDTH' > %t/x86_64-device-defines-filtered
 // RUN: diff %t/x86_64-host-defines-filtered %t/x86_64-device-defines-filtered
 
 // RUN: %clang --cuda-host-only -nocudainc -target powerpc64-unknown-linux-gnu -x cuda -E -dM -o - /dev/null \
 // RUN:   | grep -E 'define __[^ ]*(TYPE|MAX|SIZEOF|WIDTH)|define __CLANG_ATOMIC' \
-// RUN:   | grep -Ev '__LDBL|_LONG_DOUBLE' > %t/powerpc64-host-defines-filtered
+// RUN:   | grep -Ev '__LDBL|_LONG_DOUBLE|BITINT_MAXWIDTH' > %t/powerpc64-host-defines-filtered
 // RUN: %clang --cuda-device-only -nocudainc -nocudalib -target powerpc64-unknown-linux-gnu -x cuda -E -dM -o - /dev/null \
 // RUN:   | grep -E 'define __[^ ]*(TYPE|MAX|SIZEOF|WIDTH)|define __CLANG_ATOMIC' \
-// RUN:   | grep -Ev '__LDBL|_LONG_DOUBLE' > %t/powerpc64-device-defines-filtered
+// RUN:   | grep -Ev '__LDBL|_LONG_DOUBLE|BITINT_MAXWIDTH' > %t/powerpc64-device-defines-filtered
 // RUN: diff %t/powerpc64-host-defines-filtered %t/powerpc64-device-defines-filtered
 
 // RUN: %clang --cuda-host-only -nocudainc -target i386-windows-msvc -x cuda -E -dM -o - /dev/null \
 // RUN:   | grep -E 'define __[^ ]*(TYPE|MAX|SIZEO

[PATCH] D139025: [NFC][RISCV] Extract utility to calculate value through MajorVersion and MinorVersion

2022-12-05 Thread Craig Topper via Phabricator via cfe-commits
craig.topper accepted this revision.
craig.topper added a comment.
This revision is now accepted and ready to land.
Herald added a subscriber: StephenFan.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139025

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


[PATCH] D138597: DebugInfo: Add/support new DW_LANG codes for recent C and C++ versions

2022-12-05 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added a comment.

In D138597#3966638 , @probinson wrote:

> One not-yet-asked question, does gcc produce the C++17/20 codes? If so, does 
> fstrict-dwarf affect that?

Looks like GCC uses C++17 for both 17 and 20: 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;f=gcc/testsuite/g%2B%2B.dg/debug/dwarf2/lang-cpp17.C;h=a90606ab979762ce4630777c2fce5c921d0a2b96
 (apparently it used to use just C_plus_plus for 20: 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;f=gcc/testsuite/g%2B%2B.dg/debug/dwarf2/lang-cpp17.C;h=a90606ab979762ce4630777c2fce5c921d0a2b96
 )

> The major consumers of this would be lldb (which we control) and gdb, so 
> following gcc's lead here would seem appropriate.  I can accept that listing 
> the codes on the website "counts" as in-spec for fstrict-dwarf purposes.

Yeah, I'm leaning towards just not implementing the v5 bonus codes - they're 
good for new languages, but for existing languages the risk of regression seems 
not worth the benefit.

I left the test cases in - easy to tweak them when we decide how to render this 
- and left some minor refactoring in that I could pull out/commit separately.

I still haven't heard from the internal user that seemed pretty adamant that 
expressing these newer versions was important... I can't really picture 
(relative to all the other debug info incompletenessess) why it would be 
especially important.




Comment at: llvm/lib/IR/DIBuilder.cpp:159
 
-  assert(((Lang <= dwarf::DW_LANG_Fortran08 && Lang >= dwarf::DW_LANG_C89) ||
+  assert(((Lang <= dwarf::DW_LANG_Ada2012 && Lang >= dwarf::DW_LANG_C89) ||
   (Lang <= dwarf::DW_LANG_hi_user && Lang >= dwarf::DW_LANG_lo_user)) 
&&

aprantl wrote:
> Should we define a DW_LANG_HI_DWARF in the .def file?
Maybe? I'm not sure - if it has to explicitly write the constant or another 
enum value in there, I think it's as liable to get missed when updating as this 
code, perhaps? Open to ideas.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138597

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


[PATCH] D138597: DebugInfo: Add/support new DW_LANG codes for recent C and C++ versions

2022-12-05 Thread David Blaikie via Phabricator via cfe-commits
dblaikie updated this revision to Diff 480296.
dblaikie added a comment.

Don't use the since-v5-published codes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138597

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/test/CodeGen/debug-info-programming-language.c
  clang/test/CodeGenCXX/debug-info-programming-language.cpp


Index: clang/test/CodeGenCXX/debug-info-programming-language.cpp
===
--- clang/test/CodeGenCXX/debug-info-programming-language.cpp
+++ clang/test/CodeGenCXX/debug-info-programming-language.cpp
@@ -4,6 +4,12 @@
 // RUN: %clang_cc1 -dwarf-version=3 -emit-llvm -triple %itanium_abi_triple %s 
-o - \
 // RUN:   -x c++ -std=c++14 -O0 -disable-llvm-passes -debug-info-kind=limited \
 // RUN:   | FileCheck --check-prefix=CHECK-CPP14 %s
+// RUN: %clang_cc1 -dwarf-version=3 -emit-llvm -triple %itanium_abi_triple %s 
-o - \
+// RUN:   -x c++ -std=c++17 -O0 -disable-llvm-passes -debug-info-kind=limited \
+// RUN:   | FileCheck --check-prefix=CHECK-CPP17 %s
+// RUN: %clang_cc1 -dwarf-version=3 -emit-llvm -triple %itanium_abi_triple %s 
-o - \
+// RUN:   -x c++ -std=c++20 -O0 -disable-llvm-passes -debug-info-kind=limited \
+// RUN:   | FileCheck --check-prefix=CHECK-CPP20 %s
 // RUN: %clang_cc1 -dwarf-version=3 -gstrict-dwarf -emit-llvm -triple 
%itanium_abi_triple %s -o - \
 // RUN:   -x c++ -std=c++14 -O0 -disable-llvm-passes -debug-info-kind=limited 
| FileCheck %s
 // RUN: %clang_cc1 -dwarf-version=5 -gstrict-dwarf -emit-llvm -triple 
%itanium_abi_triple %s -o - \
@@ -14,5 +20,15 @@
   return 0;
 }
 
+// Update these tests once support for DW_LANG_C_plus_plus_17/20 is added - 
it's
+// a complicated tradeoff. The language codes are already published/blessed by
+// the DWARF committee, but haven't been released in a published standard yet,
+// so consumers might not be ready for these codes & could regress 
functionality
+// (because they wouldn't be able to identify that the language was C++). The
+// DWARFv6 language encoding, separating language from language version, would
+// remove this problem/not require new codes for new language versions and make
+// it possible to identify the base language irrespective of the version.
 // CHECK-CPP14: distinct !DICompileUnit(language: DW_LANG_C_plus_plus_14,
+// CHECK-CPP17: distinct !DICompileUnit(language: DW_LANG_C_plus_plus_14,
+// CHECK-CPP20: distinct !DICompileUnit(language: DW_LANG_C_plus_plus_14,
 // CHECK: distinct !DICompileUnit(language: DW_LANG_C_plus_plus,
Index: clang/test/CodeGen/debug-info-programming-language.c
===
--- /dev/null
+++ clang/test/CodeGen/debug-info-programming-language.c
@@ -0,0 +1,15 @@
+// RUN: %clang_cc1 -dwarf-version=3 -emit-llvm -triple %itanium_abi_triple %s 
-o - \
+// RUN:   -x c -std=c11 -O0 -disable-llvm-passes -debug-info-kind=limited \
+// RUN:   | FileCheck --check-prefix=CHECK-C11 %s
+// RUN: %clang_cc1 -dwarf-version=3 -emit-llvm -triple %itanium_abi_triple %s 
-o - \
+// RUN:   -x c -std=c17 -O0 -disable-llvm-passes -debug-info-kind=limited \
+// RUN:   | FileCheck --check-prefix=CHECK-C17 %s
+
+// CHECK-C11: !DICompileUnit(language: DW_LANG_C11
+// Update this check once support for DW_LANG_C17 is broadly supported/known in
+// consumers. Maybe we'll skip this and go to the DWARFv6 language+version
+// encoding that avoids the risk of regression when describing a language
+// version newer than what the consumer is aware of.
+// CHECK-C17: !DICompileUnit(language: DW_LANG_C11
+
+void f1(void) { }
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -526,7 +526,8 @@
 
   // Get absolute path name.
   SourceManager &SM = CGM.getContext().getSourceManager();
-  std::string MainFileName = CGM.getCodeGenOpts().MainFileName;
+  auto &CGO = CGM.getCodeGenOpts();
+  std::string MainFileName = CGO.MainFileName;
   if (MainFileName.empty())
 MainFileName = "";
 
@@ -562,11 +563,11 @@
   if (LO.CPlusPlus) {
 if (LO.ObjC)
   LangTag = llvm::dwarf::DW_LANG_ObjC_plus_plus;
-else if (LO.CPlusPlus14 && (!CGM.getCodeGenOpts().DebugStrictDwarf ||
-CGM.getCodeGenOpts().DwarfVersion >= 5))
+else if (CGO.DebugStrictDwarf && CGO.DwarfVersion < 5)
+  LangTag = llvm::dwarf::DW_LANG_C_plus_plus;
+else if (LO.CPlusPlus14)
   LangTag = llvm::dwarf::DW_LANG_C_plus_plus_14;
-else if (LO.CPlusPlus11 && (!CGM.getCodeGenOpts().DebugStrictDwarf ||
-CGM.getCodeGenOpts().DwarfVersion >= 5))
+else if (LO.CPlusPlus11)
   LangTag = llvm::dwarf::DW_LANG_C_plus_plus_11;
 else
   LangTag = llvm::dwarf::DW_LANG_C_plus_plus;
@@ -577,6 +578,8 @@
 LangTag = llvm::dwarf::DW_LANG_OpenCL;

[PATCH] D139025: [NFC][RISCV] Extract utility to calculate value through MajorVersion and MinorVersion

2022-12-05 Thread Yueh-Ting (eop) Chen via Phabricator via cfe-commits
eopXD marked an inline comment as done.
eopXD added a comment.

Ping.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139025

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


[PATCH] D138597: DebugInfo: Add/support new DW_LANG codes for recent C and C++ versions

2022-12-05 Thread David Blaikie via Phabricator via cfe-commits
dblaikie updated this revision to Diff 480292.
dblaikie added a comment.

Rebase on top of committed LLVM changes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138597

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/test/CodeGen/debug-info-programming-language.c
  clang/test/CodeGenCXX/debug-info-programming-language.cpp


Index: clang/test/CodeGenCXX/debug-info-programming-language.cpp
===
--- clang/test/CodeGenCXX/debug-info-programming-language.cpp
+++ clang/test/CodeGenCXX/debug-info-programming-language.cpp
@@ -4,6 +4,12 @@
 // RUN: %clang_cc1 -dwarf-version=3 -emit-llvm -triple %itanium_abi_triple %s 
-o - \
 // RUN:   -x c++ -std=c++14 -O0 -disable-llvm-passes -debug-info-kind=limited \
 // RUN:   | FileCheck --check-prefix=CHECK-CPP14 %s
+// RUN: %clang_cc1 -dwarf-version=3 -emit-llvm -triple %itanium_abi_triple %s 
-o - \
+// RUN:   -x c++ -std=c++17 -O0 -disable-llvm-passes -debug-info-kind=limited \
+// RUN:   | FileCheck --check-prefix=CHECK-CPP17 %s
+// RUN: %clang_cc1 -dwarf-version=3 -emit-llvm -triple %itanium_abi_triple %s 
-o - \
+// RUN:   -x c++ -std=c++20 -O0 -disable-llvm-passes -debug-info-kind=limited \
+// RUN:   | FileCheck --check-prefix=CHECK-CPP20 %s
 // RUN: %clang_cc1 -dwarf-version=3 -gstrict-dwarf -emit-llvm -triple 
%itanium_abi_triple %s -o - \
 // RUN:   -x c++ -std=c++14 -O0 -disable-llvm-passes -debug-info-kind=limited 
| FileCheck %s
 // RUN: %clang_cc1 -dwarf-version=5 -gstrict-dwarf -emit-llvm -triple 
%itanium_abi_triple %s -o - \
@@ -15,4 +21,6 @@
 }
 
 // CHECK-CPP14: distinct !DICompileUnit(language: DW_LANG_C_plus_plus_14,
+// CHECK-CPP17: distinct !DICompileUnit(language: DW_LANG_C_plus_plus_17,
+// CHECK-CPP20: distinct !DICompileUnit(language: DW_LANG_C_plus_plus_20,
 // CHECK: distinct !DICompileUnit(language: DW_LANG_C_plus_plus,
Index: clang/test/CodeGen/debug-info-programming-language.c
===
--- /dev/null
+++ clang/test/CodeGen/debug-info-programming-language.c
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -dwarf-version=3 -emit-llvm -triple %itanium_abi_triple %s 
-o - \
+// RUN:   -x c -std=c11 -O0 -disable-llvm-passes -debug-info-kind=limited \
+// RUN:   | FileCheck --check-prefix=CHECK-C11 %s
+// RUN: %clang_cc1 -dwarf-version=3 -emit-llvm -triple %itanium_abi_triple %s 
-o - \
+// RUN:   -x c -std=c17 -O0 -disable-llvm-passes -debug-info-kind=limited \
+// RUN:   | FileCheck --check-prefix=CHECK-C17 %s
+
+// CHECK-C11: !DICompileUnit(language: DW_LANG_C11
+// CHECK-C17: !DICompileUnit(language: DW_LANG_C17
+
+void f1(void) { }
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -526,7 +526,8 @@
 
   // Get absolute path name.
   SourceManager &SM = CGM.getContext().getSourceManager();
-  std::string MainFileName = CGM.getCodeGenOpts().MainFileName;
+  auto &CGO = CGM.getCodeGenOpts();
+  std::string MainFileName = CGO.MainFileName;
   if (MainFileName.empty())
 MainFileName = "";
 
@@ -562,11 +563,15 @@
   if (LO.CPlusPlus) {
 if (LO.ObjC)
   LangTag = llvm::dwarf::DW_LANG_ObjC_plus_plus;
-else if (LO.CPlusPlus14 && (!CGM.getCodeGenOpts().DebugStrictDwarf ||
-CGM.getCodeGenOpts().DwarfVersion >= 5))
+else if (CGO.DebugStrictDwarf && CGO.DwarfVersion < 5)
+  LangTag = llvm::dwarf::DW_LANG_C_plus_plus;
+else if (LO.CPlusPlus20)
+  LangTag = llvm::dwarf::DW_LANG_C_plus_plus_20;
+else if (LO.CPlusPlus17)
+  LangTag = llvm::dwarf::DW_LANG_C_plus_plus_17;
+else if (LO.CPlusPlus14)
   LangTag = llvm::dwarf::DW_LANG_C_plus_plus_14;
-else if (LO.CPlusPlus11 && (!CGM.getCodeGenOpts().DebugStrictDwarf ||
-CGM.getCodeGenOpts().DwarfVersion >= 5))
+else if (LO.CPlusPlus11)
   LangTag = llvm::dwarf::DW_LANG_C_plus_plus_11;
 else
   LangTag = llvm::dwarf::DW_LANG_C_plus_plus;
@@ -577,6 +582,10 @@
 LangTag = llvm::dwarf::DW_LANG_OpenCL;
   } else if (LO.RenderScript) {
 LangTag = llvm::dwarf::DW_LANG_GOOGLE_RenderScript;
+  } else if (LO.C17) {
+LangTag = llvm::dwarf::DW_LANG_C17;
+  } else if (LO.C11) {
+LangTag = llvm::dwarf::DW_LANG_C11;
   } else if (LO.C99) {
 LangTag = llvm::dwarf::DW_LANG_C99;
   } else {


Index: clang/test/CodeGenCXX/debug-info-programming-language.cpp
===
--- clang/test/CodeGenCXX/debug-info-programming-language.cpp
+++ clang/test/CodeGenCXX/debug-info-programming-language.cpp
@@ -4,6 +4,12 @@
 // RUN: %clang_cc1 -dwarf-version=3 -emit-llvm -triple %itanium_abi_triple %s -o - \
 // RUN:   -x c++ -std=c++14 -O0 -disable-llvm-passes -debug-info-kind=limited \
 // RUN:   | FileCheck --check

[PATCH] D137275: [Driver][test] Fix test by creating empty archive instead of empty file

2022-12-05 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

This breaks check-clang: http://45.33.8.238/linux/93300/step_7.txt

Please take a look and revert for now if it takes a while to fix.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137275

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


[PATCH] D138326: [CodeView] Don't generate dummy unnamed strcut/class/union type.

2022-12-05 Thread Zequan Wu via Phabricator via cfe-commits
zequanwu added a comment.

Landed at: https://reviews.llvm.org/rGbb5bcddcdbc151119f449be2d1e0d90f2e9c4258. 
Forgot to add the "Revision" line.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138326

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


[clang] bb5bcdd - [CodeView] Don't generate dummy unnamed strcut/class/union type.

2022-12-05 Thread Zequan Wu via cfe-commits

Author: Zequan Wu
Date: 2022-12-06T08:29:55+08:00
New Revision: bb5bcddcdbc151119f449be2d1e0d90f2e9c4258

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

LOG: [CodeView] Don't generate dummy unnamed strcut/class/union type.

Added: 


Modified: 
clang/lib/CodeGen/CGDebugInfo.cpp
clang/test/CodeGenCXX/debug-info-codeview-nested-types.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGDebugInfo.cpp 
b/clang/lib/CodeGen/CGDebugInfo.cpp
index b0fe96d6b8a08..2a67f58d22ced 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -1653,10 +1653,15 @@ void CGDebugInfo::CollectRecordFields(
   } else if (CGM.getCodeGenOpts().EmitCodeView) {
 // Debug info for nested types is included in the member list only for
 // CodeView.
-if (const auto *nestedType = dyn_cast(I))
+if (const auto *nestedType = dyn_cast(I)) {
+  // MSVC doesn't generate nested type for anonymous struct/union.
+  if (isa(I) &&
+  cast(I)->isAnonymousStructOrUnion())
+continue;
   if (!nestedType->isImplicit() &&
   nestedType->getDeclContext() == record)
 CollectRecordNestedType(nestedType, elements);
+}
   }
   }
 }

diff  --git a/clang/test/CodeGenCXX/debug-info-codeview-nested-types.cpp 
b/clang/test/CodeGenCXX/debug-info-codeview-nested-types.cpp
index 7c8f78e7a0016..8caf177dab67e 100644
--- a/clang/test/CodeGenCXX/debug-info-codeview-nested-types.cpp
+++ b/clang/test/CodeGenCXX/debug-info-codeview-nested-types.cpp
@@ -5,6 +5,11 @@ struct HasNested {
   typedef int InnerTypedef;
   enum { InnerEnumerator = 2 };
   struct InnerStruct { };
+
+  union { int i1; };
+  union { int i2; } unnamed_union;
+  struct { int i3; };
+  struct { int i4; } unnamed_struct;
 };
 HasNested f;
 
@@ -12,7 +17,7 @@ HasNested f;
 // CHECK: ![[HASNESTED:[0-9]+]] = distinct !DICompositeType(tag: 
DW_TAG_structure_type, name: "HasNested",
 // CHECK-SAME: elements: ![[MEMBERS:[0-9]+]],
 //
-// CHECK: ![[MEMBERS]] = !{![[INNERENUM]], ![[INNERTYPEDEF:[0-9]+]], 
![[UNNAMEDENUM:[0-9]+]], ![[INNERSTRUCT:[0-9]+]]}
+// CHECK: ![[MEMBERS]] = !{![[INNERENUM]], ![[INNERTYPEDEF:[0-9]+]], 
![[UNNAMEDENUM:[0-9]+]], ![[INNERSTRUCT:[0-9]+]], ![[ANONYMOUS_UNION:[0-9]+]], 
![[UNNAMED_UNION_TYPE:[0-9]+]], ![[UNNAMED_UNION:[0-9]+]], 
![[ANONYMOUS_STRUCT:[0-9]+]], ![[UNNAMED_STRUCT_TYPE:[0-9]+]], 
![[UNNAMED_STRUCT:[0-9]+]]}
 //
 // CHECK: ![[INNERTYPEDEF]] = !DIDerivedType(tag: DW_TAG_typedef, name: 
"InnerTypedef", scope: ![[HASNESTED]]{{.*}})
 //
@@ -23,3 +28,31 @@ HasNested f;
 //
 // CHECK: ![[INNERSTRUCT]] = !DICompositeType(tag: DW_TAG_structure_type, 
name: "InnerStruct"
 // CHECK-SAME: flags: DIFlagFwdDecl
+
+// CHECK: ![[ANONYMOUS_UNION]] = !DIDerivedType(tag: DW_TAG_member, 
+// CHECK-SAME: baseType: ![[ANONYMOUS_UNION_TYPE:[0-9]+]]
+// CHECK: ![[ANONYMOUS_UNION_TYPE]] = distinct !DICompositeType(tag: 
DW_TAG_union_type,
+// CHECK-SAME: elements: ![[ANONYMOUS_UNION_MEMBERS:[0-9]+]], identifier: 
".?AT@HasNested@@")
+// CHECK: ![[ANONYMOUS_UNION_MEMBERS]] = !{![[ANONYMOUS_UNION_MEMBER:[0-9]+]]}
+// CHECK: ![[ANONYMOUS_UNION_MEMBER]] = !DIDerivedType(tag: DW_TAG_member, 
name: "i1"
+
+// CHECK: ![[UNNAMED_UNION_TYPE]] = distinct !DICompositeType(tag: 
DW_TAG_union_type, name: ""
+// CHECK-SAME: elements: ![[UNNAMED_UNION_MEMBERS:[0-9]+]], identifier: 
".?AT@HasNested@@")
+// CHECK: ![[UNNAMED_UNION_MEMBERS]] = !{![[UNNAMED_UNION_MEMBER:[0-9]+]]}
+// CHECK: ![[UNNAMED_UNION_MEMBER]] = !DIDerivedType(tag: DW_TAG_member, name: 
"i2"
+// CHECK: ![[UNNAMED_UNION]] = !DIDerivedType(tag: DW_TAG_member, name: 
"unnamed_union"
+// CHECK-SAME: baseType: ![[UNNAMED_UNION_TYPE]]
+
+// CHECK: ![[ANONYMOUS_STRUCT]] = !DIDerivedType(tag: DW_TAG_member
+// CHECK-SAME: baseType: ![[ANONYMOUS_STRUCT_TYPE:[0-9]+]]
+// CHECK: ![[ANONYMOUS_STRUCT_TYPE]] = distinct !DICompositeType(tag: 
DW_TAG_structure_type
+// CHECK-SAME: elements: ![[ANONYMOUS_STRUCT_MEMBERS:[0-9]+]], identifier: 
".?AU@HasNested@@")
+// CHECK: ![[ANONYMOUS_STRUCT_MEMBERS]] = 
!{![[ANONYMOUS_STRUCT_MEMBER:[0-9]+]]}
+// CHECK: ![[ANONYMOUS_STRUCT_MEMBER]] = !DIDerivedType(tag: DW_TAG_member, 
name: "i3"
+
+// CHECK: ![[UNNAMED_STRUCT_TYPE]] = distinct !DICompositeType(tag: 
DW_TAG_structure_type, name: ""
+// CHECK-SAME: elements: ![[UNNAMED_STRUCT_MEMBERS:[0-9]+]], identifier: 
".?AU@HasNested@@")
+// CHECK: ![[UNNAMED_STRUCT_MEMBERS]] = !{![[UNNAMED_STRUCT_MEMBER:[0-9]+]]}
+// CHECK: ![[UNNAMED_STRUCT_MEMBER]] = !DIDerivedType(tag: DW_TAG_member, 
name: "i4"
+// CHECK: ![[UNNAMED_STRUCT]] = !DIDerivedType(tag: DW_TAG_member, name: 
"unnamed_struct"
+// CHECK-SAME: baseType: ![[UNNAMED_STRUCT_TYPE]]




Re: [clang] a446827 - [NFC][Clang][Driver][AMDGPU] Avoid temporary copies of std::string by using Twine and StringRef

2022-12-05 Thread David Blaikie via cfe-commits
On Mon, Dec 5, 2022 at 5:27 AM Juan Manuel MARTINEZ CAAMAÑO via
cfe-commits  wrote:
>
>
> Author: Juan Manuel MARTINEZ CAAMAÑO
> Date: 2022-12-05T07:27:10-06:00
> New Revision: a446827249bdeb2f27e55a9f4942bd7425ecb0ff
>
> URL: 
> https://github.com/llvm/llvm-project/commit/a446827249bdeb2f27e55a9f4942bd7425ecb0ff
> DIFF: 
> https://github.com/llvm/llvm-project/commit/a446827249bdeb2f27e55a9f4942bd7425ecb0ff.diff
>
> LOG: [NFC][Clang][Driver][AMDGPU] Avoid temporary copies of std::string by 
> using Twine and StringRef
>
> Reviewed By: tra
>
> Differential Revision: https://reviews.llvm.org/D139023
>
> Added:
>
>
> Modified:
> clang/lib/Driver/ToolChains/AMDGPU.cpp
> clang/lib/Driver/ToolChains/HIPAMD.cpp
> clang/lib/Driver/ToolChains/ROCm.h
>
> Removed:
>
>
>
> 
> diff  --git a/clang/lib/Driver/ToolChains/AMDGPU.cpp 
> b/clang/lib/Driver/ToolChains/AMDGPU.cpp
> index f3ac7d2ab735..ff77969bbec5 100644
> --- a/clang/lib/Driver/ToolChains/AMDGPU.cpp
> +++ b/clang/lib/Driver/ToolChains/AMDGPU.cpp
> @@ -854,7 +854,7 @@ void ROCMToolChain::addClangTargetOptions(
>const StringRef GpuArch = getGPUArch(DriverArgs);
>auto Kind = llvm::AMDGPU::parseArchAMDGCN(GpuArch);
>const StringRef CanonArch = llvm::AMDGPU::getArchNameAMDGCN(Kind);
> -  std::string LibDeviceFile = RocmInstallation.getLibDeviceFile(CanonArch);
> +  StringRef LibDeviceFile = RocmInstallation.getLibDeviceFile(CanonArch);
>auto ABIVer = DeviceLibABIVersion::fromCodeObjectVersion(
>getAMDGPUCodeObjectVersion(getDriver(), DriverArgs));
>if (!RocmInstallation.checkCommonBitcodeLibs(CanonArch, LibDeviceFile,
> @@ -946,7 +946,7 @@ ROCMToolChain::getCommonDeviceLibNames(const 
> llvm::opt::ArgList &DriverArgs,
>auto Kind = llvm::AMDGPU::parseArchAMDGCN(GPUArch);
>const StringRef CanonArch = llvm::AMDGPU::getArchNameAMDGCN(Kind);
>
> -  std::string LibDeviceFile = RocmInstallation.getLibDeviceFile(CanonArch);
> +  StringRef LibDeviceFile = RocmInstallation.getLibDeviceFile(CanonArch);
>auto ABIVer = DeviceLibABIVersion::fromCodeObjectVersion(
>getAMDGPUCodeObjectVersion(getDriver(), DriverArgs));
>if (!RocmInstallation.checkCommonBitcodeLibs(CanonArch, LibDeviceFile,
>
> diff  --git a/clang/lib/Driver/ToolChains/HIPAMD.cpp 
> b/clang/lib/Driver/ToolChains/HIPAMD.cpp
> index c64421d259ce..a555fe5830e0 100644
> --- a/clang/lib/Driver/ToolChains/HIPAMD.cpp
> +++ b/clang/lib/Driver/ToolChains/HIPAMD.cpp
> @@ -237,7 +237,7 @@ void HIPAMDToolChain::addClangTargetOptions(
>DriverArgs.getLastArgValue(options::OPT_gpu_max_threads_per_block_EQ);
>if (!MaxThreadsPerBlock.empty()) {
>  std::string ArgStr =
> -std::string("--gpu-max-threads-per-block=") + 
> MaxThreadsPerBlock.str();
> +(Twine("--gpu-max-threads-per-block=") + MaxThreadsPerBlock).str();
>  CC1Args.push_back(DriverArgs.MakeArgStringRef(ArgStr));
>}
>
> @@ -344,7 +344,7 @@ HIPAMDToolChain::getDeviceLibs(const llvm::opt::ArgList 
> &DriverArgs) const {
>ArgStringList LibraryPaths;
>
>// Find in --hip-device-lib-path and HIP_LIBRARY_PATH.
> -  for (auto Path : RocmInstallation.getRocmDeviceLibPathArg())
> +  for (StringRef Path : RocmInstallation.getRocmDeviceLibPathArg())
>  LibraryPaths.push_back(DriverArgs.MakeArgString(Path));
>
>addDirectoryList(DriverArgs, LibraryPaths, "", "HIP_DEVICE_LIB_PATH");
> @@ -354,7 +354,7 @@ HIPAMDToolChain::getDeviceLibs(const llvm::opt::ArgList 
> &DriverArgs) const {
>if (!BCLibArgs.empty()) {
>  llvm::for_each(BCLibArgs, [&](StringRef BCName) {
>StringRef FullName;
> -  for (std::string LibraryPath : LibraryPaths) {
> +  for (StringRef LibraryPath : LibraryPaths) {
>  SmallString<128> Path(LibraryPath);
>  llvm::sys::path::append(Path, BCName);
>  FullName = Path;
> @@ -387,15 +387,15 @@ HIPAMDToolChain::getDeviceLibs(const llvm::opt::ArgList 
> &DriverArgs) const {
>  getDriver().Diag(DiagID);
>  return {};
>} else
> -BCLibs.push_back({AsanRTL.str(), /*ShouldInternalize=*/false});
> +BCLibs.emplace_back(AsanRTL, /*ShouldInternalize=*/false);
>  }
>
>  // Add the HIP specific bitcode library.
>  BCLibs.push_back(RocmInstallation.getHIPPath());
>
>  // Add common device libraries like ocml etc.
> -for (auto N : getCommonDeviceLibNames(DriverArgs, GpuArch.str()))
> -  BCLibs.push_back(StringRef(N));
> +for (StringRef N : getCommonDeviceLibNames(DriverArgs, GpuArch.str()))
> +  BCLibs.emplace_back(N);
>
>  // Add instrument lib.
>  auto InstLib =
>
> diff  --git a/clang/lib/Driver/ToolChains/ROCm.h 
> b/clang/lib/Driver/ToolChains/ROCm.h
> index b16deecdebec..600c8b39f4b3 100644
> --- a/clang/lib/Driver/ToolChains/ROCm.h
> +++ b/clang/lib/Driver/ToolChains/ROCm.h
> @@ -252,8 +252,11 @@ class RocmInstallationDetector {
>}
>
>/// Get libdevice f

[PATCH] D138983: [clang][CodeGen] Add noundef metadata to load instructions (preliminary 3 or 3)

2022-12-05 Thread John McIver via Phabricator via cfe-commits
jmciver updated this revision to Diff 480267.
jmciver added a comment.

Updating D138983 : [clang][CodeGen] Add 
noundef metadata to load instructions (preliminary 3 or 3)

The following tests have been updated:

- matrix-type-operators.c


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138983

Files:
  clang/lib/CodeGen/CGExpr.cpp
  clang/test/CodeGen/matrix-type-operators.c
  clang/test/CodeGen/vector-noundef.c
  clang/test/CodeGenCXX/vector-noundef.cpp

Index: clang/test/CodeGenCXX/vector-noundef.cpp
===
--- clang/test/CodeGenCXX/vector-noundef.cpp
+++ clang/test/CodeGenCXX/vector-noundef.cpp
@@ -6,6 +6,9 @@
 using VecOfThreeChars __attribute__((ext_vector_type(3))) = char;
 using VecOfThreeUChars __attribute__((ext_vector_type(3))) = unsigned char;
 
+using VecOfFourFloats __attribute__((ext_vector_type(4))) = float;
+using VecOfTwoFloats __attribute__((ext_vector_type(2))) = float;
+
 // CHECK-LABEL: @_Z15getElement4BoolRDv4_b(
 // CHECK-NEXT:  entry:
 // CHECK-NEXT:[[A_ADDR:%.*]] = alloca ptr, align 8
@@ -82,3 +85,33 @@
 {
   return a[0];
 }
+
+// CHECK-LABEL: @_Z16vectorSubsectionRDv2_fRDv4_f(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[VEC2_ADDR:%.*]] = alloca ptr, align 8
+// CHECK-NEXT:[[VEC4_ADDR:%.*]] = alloca ptr, align 8
+// CHECK-NEXT:store ptr [[VEC2:%.*]], ptr [[VEC2_ADDR]], align 8
+// CHECK-NEXT:store ptr [[VEC4:%.*]], ptr [[VEC4_ADDR]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load ptr, ptr [[VEC4_ADDR]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = load <4 x float>, ptr [[TMP0]], align 16, !noundef [[NOUNDEF2]]
+// CHECK-NEXT:[[TMP2:%.*]] = shufflevector <4 x float> [[TMP1]], <4 x float> poison, <2 x i32> 
+// CHECK-NEXT:[[TMP3:%.*]] = load ptr, ptr [[VEC2_ADDR]], align 8
+// CHECK-NEXT:store <2 x float> [[TMP2]], ptr [[TMP3]], align 8
+// CHECK-NEXT:ret void
+//
+// DISABLE-LABEL: @_Z16vectorSubsectionRDv2_fRDv4_f(
+// DISABLE-NEXT:  entry:
+// DISABLE-NEXT:[[VEC2_ADDR:%.*]] = alloca ptr, align 8
+// DISABLE-NEXT:[[VEC4_ADDR:%.*]] = alloca ptr, align 8
+// DISABLE-NEXT:store ptr [[VEC2:%.*]], ptr [[VEC2_ADDR]], align 8
+// DISABLE-NEXT:store ptr [[VEC4:%.*]], ptr [[VEC4_ADDR]], align 8
+// DISABLE-NEXT:[[TMP0:%.*]] = load ptr, ptr [[VEC4_ADDR]], align 8
+// DISABLE-NEXT:[[TMP1:%.*]] = load <4 x float>, ptr [[TMP0]], align 16
+// DISABLE-NEXT:[[TMP2:%.*]] = shufflevector <4 x float> [[TMP1]], <4 x float> poison, <2 x i32> 
+// DISABLE-NEXT:[[TMP3:%.*]] = load ptr, ptr [[VEC2_ADDR]], align 8
+// DISABLE-NEXT:store <2 x float> [[TMP2]], ptr [[TMP3]], align 8
+// DISABLE-NEXT:ret void
+//
+void vectorSubsection(VecOfTwoFloats& vec2, VecOfFourFloats& vec4) {
+vec2 = vec4.xy;
+}
Index: clang/test/CodeGen/vector-noundef.c
===
--- /dev/null
+++ clang/test/CodeGen/vector-noundef.c
@@ -0,0 +1,107 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang_cc1 -no-opaque-pointers -flax-vector-conversions=none -ffreestanding -triple x86_64-gnu-linux -target-feature +avx512f -O0 -enable-noundef-load-analysis -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -no-opaque-pointers -flax-vector-conversions=none -ffreestanding -triple x86_64-gnu-linux -target-feature +avx512f -O0 -no-enable-noundef-load-analysis -emit-llvm -o - %s | FileCheck %s --check-prefix=DISABLE
+
+#include 
+
+// CHECK-LABEL: @test_mm_mask_div_ss(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[__A_ADDR_I:%.*]] = alloca <4 x float>, align 16
+// CHECK-NEXT:[[__B_ADDR_I:%.*]] = alloca <4 x float>, align 16
+// CHECK-NEXT:[[__W_ADDR_I:%.*]] = alloca <4 x float>, align 16
+// CHECK-NEXT:[[__U_ADDR_I:%.*]] = alloca i8, align 1
+// CHECK-NEXT:[[__A_ADDR_I2:%.*]] = alloca <4 x float>, align 16
+// CHECK-NEXT:[[__B_ADDR_I2:%.*]] = alloca <4 x float>, align 16
+// CHECK-NEXT:[[__W_ADDR:%.*]] = alloca <4 x float>, align 16
+// CHECK-NEXT:[[__U_ADDR:%.*]] = alloca i8, align 1
+// CHECK-NEXT:[[__A_ADDR:%.*]] = alloca <4 x float>, align 16
+// CHECK-NEXT:[[__B_ADDR:%.*]] = alloca <4 x float>, align 16
+// CHECK-NEXT:store <4 x float> [[__W:%.*]], <4 x float>* [[__W_ADDR]], align 16
+// CHECK-NEXT:store i8 [[__U:%.*]], i8* [[__U_ADDR]], align 1
+// CHECK-NEXT:store <4 x float> [[__A:%.*]], <4 x float>* [[__A_ADDR]], align 16
+// CHECK-NEXT:store <4 x float> [[__B:%.*]], <4 x float>* [[__B_ADDR]], align 16
+// CHECK-NEXT:[[TMP0:%.*]] = load <4 x float>, <4 x float>* [[__W_ADDR]], align 16, !noundef [[NOUNDEF2:![0-9]+]]
+// CHECK-NEXT:[[TMP1:%.*]] = load i8, i8* [[__U_ADDR]], align 1
+// CHECK-NEXT:[[TMP2:%.*]] = load <4 x float>, <4 x float>* [[__A_ADDR]], align 16, !noundef [[NOUNDEF2]]
+// CHECK-NEXT:[[TMP3:%.*]] = load 

[PATCH] D138337: Add support for kcfi-seal optimization with LTO

2022-12-05 Thread Sami Tolvanen via Phabricator via cfe-commits
samitolvanen added a comment.

In D138337#3972493 , @pcc wrote:

> Isn't that just a bug in the optimization? It shouldn't be applying this to 
> symbols where `VisibleToRegularObj` is set.

The current patch simply replicates ibt-seal behavior, but sure, looking at 
symbol resolution should solve this problem. I'll take a look when have some 
more time.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138337

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


[PATCH] D139302: [RISCV] Add Syntacore SCR1 CPU model

2022-12-05 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added inline comments.



Comment at: llvm/lib/Target/RISCV/RISCVSchedSCR1.td:208
+}
\ No newline at end of file


Add new line


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139302

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


[PATCH] D139302: [RISCV] Add Syntacore SCR1 CPU model

2022-12-05 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added inline comments.



Comment at: llvm/lib/Target/RISCV/RISCV.td:637
+def : ProcessorModel<"scr1-min", SCR1Model,
+ [FeatureRV32E, FeatureStdExtC],
+ [TuneNoDefaultUnroll]>;

Shouldn't this also need Feature32Bit?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139302

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


[PATCH] D134410: [clang][CodeGen] Add noundef metadata to load instructions (preliminary 1 or 3)

2022-12-05 Thread John McIver via Phabricator via cfe-commits
jmciver updated this revision to Diff 480265.
jmciver added a comment.

Updating D134410 : [clang][CodeGen] Add 
noundef metadata to load instructions (preliminary 1 or 3)

The following tests have been updated:

- avx512f-builtins.c
- avx512fp16-builtins.c
- matrix-type-operators.c
- matrix-type-operators.cpp


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134410

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGExpr.cpp
  clang/test/CodeGen/X86/avx-builtins.c
  clang/test/CodeGen/X86/avx512bw-builtins.c
  clang/test/CodeGen/X86/avx512f-builtins.c
  clang/test/CodeGen/X86/avx512fp16-builtins.c
  clang/test/CodeGen/X86/avx512vl-builtins.c
  clang/test/CodeGen/X86/avx512vlbw-builtins.c
  clang/test/CodeGen/X86/sse-builtins.c
  clang/test/CodeGen/X86/sse2-builtins.c
  clang/test/CodeGen/aarch64-ls64-inline-asm.c
  clang/test/CodeGen/aarch64-ls64.c
  clang/test/CodeGen/aarch64-sve-acle-__ARM_FEATURE_SVE_VECTOR_OPERATORS.c
  clang/test/CodeGen/matrix-type-operators.c
  clang/test/CodeGen/memcpy-inline-builtin.c
  clang/test/CodeGen/tbaa-array.cpp
  clang/test/CodeGen/tbaa-base.cpp
  clang/test/CodeGen/tbaa.cpp
  clang/test/CodeGen/ubsan-pass-object-size.c
  clang/test/CodeGenCUDA/amdgpu-kernel-arg-pointer-type.cu
  clang/test/CodeGenCXX/attr-likelihood-if-branch-weights.cpp
  clang/test/CodeGenCXX/attr-likelihood-switch-branch-weights.cpp
  clang/test/CodeGenCXX/builtin-bit-cast-no-tbaa.cpp
  clang/test/CodeGenCXX/debug-info-line.cpp
  clang/test/CodeGenCXX/matrix-type-operators.cpp
  clang/test/CodeGenCXX/pr12251.cpp
  clang/test/CodeGenCXX/pragma-followup_inner.cpp
  clang/test/OpenMP/cancel_codegen.cpp
  clang/test/OpenMP/cancellation_point_codegen.cpp
  clang/test/OpenMP/distribute_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_reduction_task_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_private_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_proc_bind_codegen.cpp
  clang/test/OpenMP/distribute_simd_codegen.cpp
  clang/test/OpenMP/distribute_simd_private_codegen.cpp
  clang/test/OpenMP/distribute_simd_reduction_codegen.cpp
  clang/test/OpenMP/for_reduction_task_codegen.cpp
  clang/test/OpenMP/irbuilder_safelen.cpp
  clang/test/OpenMP/irbuilder_safelen_order_concurrent.cpp
  clang/test/OpenMP/irbuilder_simd_aligned.cpp
  clang/test/OpenMP/irbuilder_simdlen.cpp
  clang/test/OpenMP/irbuilder_simdlen_safelen.cpp
  clang/test/OpenMP/master_taskloop_in_reduction_codegen.cpp
  clang/test/OpenMP/master_taskloop_simd_in_reduction_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_reduction_codegen_tbaa_PR46146.cpp
  clang/test/OpenMP/ordered_codegen.cpp
  clang/test/OpenMP/parallel_for_reduction_task_codegen.cpp
  clang/test/OpenMP/parallel_for_simd_aligned_codegen.cpp
  clang/test/OpenMP/parallel_for_simd_codegen.cpp
  clang/test/OpenMP/parallel_master_reduction_task_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_lastprivate_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_simd_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_simd_lastprivate_codegen.cpp
  clang/test/OpenMP/parallel_reduction_task_codegen.cpp
  clang/test/OpenMP/parallel_sections_reduction_task_codegen.cpp
  clang/test/OpenMP/sections_reduction_task_codegen.cpp
  clang/test/OpenMP/target_defaultmap_codegen_01.cpp
  clang/test/OpenMP/target_in_reduction_codegen.cpp
  clang/test/OpenMP/target_is_device_ptr_codegen.cpp
  clang/test/OpenMP/target_map_codegen_00.cpp
  clang/test/OpenMP/target_map_codegen_01.cpp
  clang/test/OpenMP/target_map_codegen_02.cpp
  clang/test/OpenMP/target_map_codegen_04.cpp
  clang/test/OpenMP/target_map_codegen_05.cpp
  clang/test/OpenMP/target_map_codegen_07.cpp
  clang/test/OpenMP/target_map_codegen_11.cpp
  clang/test/OpenMP/target_map_codegen_13.cpp
  clang/test/OpenMP/target_map_codegen_14.cpp
  clang/test/OpenMP/target_map_codegen_15.cpp
  clang/test/OpenMP/target_map_codegen_17.cpp
  clang/test/OpenMP/target_map_codegen_26.cpp
  clang/test/OpenMP/target_map_codegen_27.cpp
  clang/test/OpenMP/target_map_codegen_29.cpp
  clang/test/OpenMP/target_parallel_codegen.cpp
  clang/test/OpenMP/target_parallel_for_codegen.cpp
  clang/test/OpenMP/target_parallel_for_reduction_task_codegen.cpp
  clang/test/OpenMP/target_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/target_parallel_reduction_task_codegen.cpp
  clang/test/OpenMP/target_teams_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_order_codegen.cpp
  
clang/test/OpenMP/target_teams_distribute_parallel_for_reduction_task_codegen.cpp
  
clang/test/OpenMP/target_teams_distribute_parallel_for_simd_collapse_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_simd_if_codegen.cpp

[PATCH] D137275: [Driver][test] Fix test by creating empty archive instead of empty file

2022-12-05 Thread Jacob Lambert 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 rG6b992bcce0c5: [Driver][test] Fix test by creating empty 
archive instead of empty file (authored by lamb-j).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137275

Files:
  clang/test/Driver/hip-link-bc-to-bc.hip


Index: clang/test/Driver/hip-link-bc-to-bc.hip
===
--- clang/test/Driver/hip-link-bc-to-bc.hip
+++ clang/test/Driver/hip-link-bc-to-bc.hip
@@ -1,6 +1,4 @@
 // REQUIRES: x86-registered-target, amdgpu-registered-target
-// See issue #58711
-// XFAIL: *
 
 // Check that clang unbundles the two bitcodes and links via llvm-link
 // RUN: rm -rf %t && mkdir %t
@@ -21,7 +19,7 @@
 // BITCODE: "{{.*}}llvm-link" "-o" "bundle1-hip-amdgcn-amd-amdhsa-gfx906.bc" 
"[[B1DEV2]]" "[[B2DEV2]]"
 
 // Check that clang unbundles the bitcode and archive and links via llvm-link
-// RUN: touch %t/libhipbundle.a
+// RUN: ar rc %t/libhipbundle.a
 // RUN: touch %t/bundle.bc
 
 // RUN: %clang -### --target=x86_64-unknown-linux-gnu --offload-arch=gfx906 
--hip-link \


Index: clang/test/Driver/hip-link-bc-to-bc.hip
===
--- clang/test/Driver/hip-link-bc-to-bc.hip
+++ clang/test/Driver/hip-link-bc-to-bc.hip
@@ -1,6 +1,4 @@
 // REQUIRES: x86-registered-target, amdgpu-registered-target
-// See issue #58711
-// XFAIL: *
 
 // Check that clang unbundles the two bitcodes and links via llvm-link
 // RUN: rm -rf %t && mkdir %t
@@ -21,7 +19,7 @@
 // BITCODE: "{{.*}}llvm-link" "-o" "bundle1-hip-amdgcn-amd-amdhsa-gfx906.bc" "[[B1DEV2]]" "[[B2DEV2]]"
 
 // Check that clang unbundles the bitcode and archive and links via llvm-link
-// RUN: touch %t/libhipbundle.a
+// RUN: ar rc %t/libhipbundle.a
 // RUN: touch %t/bundle.bc
 
 // RUN: %clang -### --target=x86_64-unknown-linux-gnu --offload-arch=gfx906 --hip-link \
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 6b992bc - [Driver][test] Fix test by creating empty archive instead of empty file

2022-12-05 Thread Jacob Lambert via cfe-commits

Author: Jacob Lambert
Date: 2022-12-05T15:39:09-08:00
New Revision: 6b992bcce0c5a86f57c83dd8d0ac9e63bcfc5521

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

LOG: [Driver][test] Fix test by creating empty archive instead of empty file

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

Added: 


Modified: 
clang/test/Driver/hip-link-bc-to-bc.hip

Removed: 




diff  --git a/clang/test/Driver/hip-link-bc-to-bc.hip 
b/clang/test/Driver/hip-link-bc-to-bc.hip
index 972822b5260c2..ac6dcf494224b 100644
--- a/clang/test/Driver/hip-link-bc-to-bc.hip
+++ b/clang/test/Driver/hip-link-bc-to-bc.hip
@@ -1,6 +1,4 @@
 // REQUIRES: x86-registered-target, amdgpu-registered-target
-// See issue #58711
-// XFAIL: *
 
 // Check that clang unbundles the two bitcodes and links via llvm-link
 // RUN: rm -rf %t && mkdir %t
@@ -21,7 +19,7 @@
 // BITCODE: "{{.*}}llvm-link" "-o" "bundle1-hip-amdgcn-amd-amdhsa-gfx906.bc" 
"[[B1DEV2]]" "[[B2DEV2]]"
 
 // Check that clang unbundles the bitcode and archive and links via llvm-link
-// RUN: touch %t/libhipbundle.a
+// RUN: ar rc %t/libhipbundle.a
 // RUN: touch %t/bundle.bc
 
 // RUN: %clang -### --target=x86_64-unknown-linux-gnu --offload-arch=gfx906 
--hip-link \



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


[clang] bc06177 - Revert "[-Wunsafe-buffer-usage] Initial commit - Transition away from raw buffers."

2022-12-05 Thread Artem Dergachev via cfe-commits

Author: Artem Dergachev
Date: 2022-12-05T15:38:52-08:00
New Revision: bc0617795f8bdcd5deab3e48b120107cc2833cdc

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

LOG: Revert "[-Wunsafe-buffer-usage] Initial commit - Transition away from raw 
buffers."

This reverts commit 27ec85f81122fd260a4e68308e54607ca37a.

Added: 


Modified: 
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/Analysis/CMakeLists.txt
clang/lib/Sema/AnalysisBasedWarnings.cpp

Removed: 
clang/include/clang/Analysis/Analyses/UnsafeBufferUsage.h
clang/lib/Analysis/UnsafeBufferUsage.cpp
clang/test/SemaCXX/warn-unsafe-buffer-usage.cpp



diff  --git a/clang/include/clang/Analysis/Analyses/UnsafeBufferUsage.h 
b/clang/include/clang/Analysis/Analyses/UnsafeBufferUsage.h
deleted file mode 100644
index 1ddbb92eb66f7..0
--- a/clang/include/clang/Analysis/Analyses/UnsafeBufferUsage.h
+++ /dev/null
@@ -1,38 +0,0 @@
-//===- UnsafeBufferUsage.h - Replace pointers with modern C++ ---*- C++ 
-*-===//
-//
-// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
-// See https://llvm.org/LICENSE.txt for license information.
-// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-//
-//===--===//
-//
-//  This file defines an analysis that aids replacing buffer accesses through
-//  raw pointers with safer C++ abstractions such as containers and 
views/spans.
-//
-//===--===//
-
-#ifndef LLVM_CLANG_ANALYSIS_ANALYSES_UNSAFEBUFFERUSAGE_H
-#define LLVM_CLANG_ANALYSIS_ANALYSES_UNSAFEBUFFERUSAGE_H
-
-#include "clang/ASTMatchers/ASTMatchFinder.h"
-
-namespace clang {
-
-/// The interface that lets the caller handle unsafe buffer usage analysis
-/// results by overriding this class's handle... methods.
-class UnsafeBufferUsageHandler {
-public:
-  UnsafeBufferUsageHandler() = default;
-  virtual ~UnsafeBufferUsageHandler() = default;
-
-  /// Invoked when an unsafe operation over raw pointers is found.
-  virtual void handleUnsafeOperation(const Stmt *Operation) = 0;
-};
-
-// This function invokes the analysis and allows the caller to react to it
-// through the handler class.
-void checkUnsafeBufferUsage(const Decl *D, UnsafeBufferUsageHandler &Handler);
-
-} // end namespace clang
-
-#endif /* LLVM_CLANG_ANALYSIS_ANALYSES_UNSAFEBUFFERUSAGE_H */

diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 6a831abebf694..15f85b778ccc6 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -11732,9 +11732,4 @@ def err_cast_from_randomized_struct : Error<
 // LoongArch-specific Diagnostics
 def err_loongarch_builtin_requires_la64 : Error<
   "this builtin requires target: loongarch64">;
-
-// Unsafe buffer usage diagnostics.
-def warn_unsafe_buffer_usage : Warning<
-  "unchecked operation on raw buffer in expression">,
-  InGroup>, DefaultIgnore;
 } // end of sema component.

diff  --git a/clang/lib/Analysis/CMakeLists.txt 
b/clang/lib/Analysis/CMakeLists.txt
index ea6cb59e8e199..16e3f474060cb 100644
--- a/clang/lib/Analysis/CMakeLists.txt
+++ b/clang/lib/Analysis/CMakeLists.txt
@@ -32,7 +32,6 @@ add_clang_library(clangAnalysis
   ThreadSafetyLogical.cpp
   ThreadSafetyTIL.cpp
   UninitializedValues.cpp
-  UnsafeBufferUsage.cpp
 
   LINK_LIBS
   clangAST

diff  --git a/clang/lib/Analysis/UnsafeBufferUsage.cpp 
b/clang/lib/Analysis/UnsafeBufferUsage.cpp
deleted file mode 100644
index 0f8fb68942116..0
--- a/clang/lib/Analysis/UnsafeBufferUsage.cpp
+++ /dev/null
@@ -1,79 +0,0 @@
-//===- UnsafeBufferUsage.cpp - Replace pointers with modern C++ 
---===//
-//
-// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
-// See https://llvm.org/LICENSE.txt for license information.
-// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-//
-//===--===//
-
-#include "clang/Analysis/Analyses/UnsafeBufferUsage.h"
-#include "llvm/ADT/SmallVector.h"
-
-using namespace llvm;
-using namespace clang;
-using namespace ast_matchers;
-
-namespace {
-// TODO: Better abstractions over gadgets.
-using GadgetList = std::vector;
-}
-
-// Scan the function and return a list of gadgets found with provided kits.
-static GadgetList findGadgets(const Decl *D) {
-
-  class GadgetFinderCallback : public MatchFinder::MatchCallback {
-GadgetList &Output;
-
-  public:
-GadgetFinderCallback(GadgetList &Output) : Output(Output) {}
-
-void run(const MatchFinder::MatchResult &Result) override {
-  Output.push_back(Resu

[PATCH] D138337: Add support for kcfi-seal optimization with LTO

2022-12-05 Thread Peter Collingbourne via Phabricator via cfe-commits
pcc added a comment.

In D138337#3972138 , @samitolvanen 
wrote:

> In D138337#3972009 , @pcc wrote:
>
>> Can't this be implicit if LTO is being used?
>
> I would prefer to keep this behind a flag (similarly to `-mibt-seal`), so we 
> can better control when and where the optimization enabled. For example, 
> enabling this implicitly would currently break LTO+KCFI kernel builds as the 
> kernel has global functions that are not address-taken in C code, but still 
> end up being indirectly called because their addresses were taken in assembly 
> code that wasn't visible to LTO (e.g. arm64's `alternative_cb` mechanism).

Isn't that just a bug in the optimization? It shouldn't be applying this to 
symbols where `VisibleToRegularObj` is set.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138337

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


[PATCH] D137107: Allow MS extension: support of constexpr with __declspec(dllimport).

2022-12-05 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added inline comments.



Comment at: clang/lib/CodeGen/CGDeclCXX.cpp:572
 PrioritizedCXXGlobalInits.push_back(std::make_pair(Key, Fn));
+  } else if (D->hasConstantInitialization() && !(D->hasAttr())) 
{
+OrderGlobalInitsOrStermFinalizers Key(201,

zahiraam wrote:
> efriedma wrote:
> > How is ConstInitAttr relevant here?
> This change made (without the !(D->hasAttr()) made the LIT 
> behavior of aix-static-init.cpp. The IR generated for 
> namespace test3 {
>   struct Test3 {
> constexpr Test3() {};
> ~Test3() {};
>   };
> 
>   constinit Test3 t;
> } // namespace test3
> 
> was different. I would have thought that the change we made for constexpr 
> wouldn't affter constinit? 
I think the significant bit there isn't the use of constinit; it's the 
non-trivial destructor.  I think the priority modification should only affect 
constructors, not destructors.  (Not sure how to make that work, at first 
glance.)


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

https://reviews.llvm.org/D137107

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


[PATCH] D137379: [-Wunsafe-buffer-usage] Add warnings for unsafe buffer accesses by array subscript operations

2022-12-05 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun added inline comments.



Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:168-169
+  static Matcher matcher() {
+// FIXME: What if the index is integer literal 0? Should this be
+// a safe gadget in this case?
+return stmt(

NoQ wrote:
> aaron.ballman wrote:
> > xazax.hun wrote:
> > > As per some of the discussions, in the future the compiler might be able 
> > > to recognize certain safe patterns, e.g., when there is a simple for loop 
> > > with known bounds, or when both the index and the array size is 
> > > statically known.
> > > 
> > > I think here we need to make a very important design decision: Do we want 
> > > the gadgets to have the right "safety" category when it is created (e.g., 
> > > we have to be able to decide if a gadget is safe or not using matchers), 
> > > or do we want some mechanisms to be able to promote an unsafe gadget to 
> > > be a safe one? (E.g., do we want to be able to prove some unsafe gadgets 
> > > safe using dataflow analysis in a later pass?)
> > (FWIW, this is a great question and I really appreciate you asking it!)
> My original design implies that safe gadgets are a separate hierarchy, so 
> there will be a new gadget class for index zero, and this gadget will be 
> changed to skip index zero. But I don't immediately see why such early 
> separation is strictly necessary, other than for a bit of extra type safety 
> (extra virtual methods of the `UnsafeGadget` class don't make sense on safe 
> gadgets). We *do* have time to make this distinction later, before we get to 
> emitting warnings.
> 
> So maybe eventually we'll end up replacing `isSafe()` with a pure virtual 
> method and deprecate `SafeGadget` and `UnsafeGadget` base classes, if we see 
> it cause too much duplication or it turns out that the extra analysis 
> necessary to establish safety can't be nicely implemented in ASTMatchers. In 
> this case I'll admit that I over-engineered it a bit.
I'd strongly prefer `isSafe()` method over inheritance. While adding safe and 
unsafe gadgets for zero indices is not too bad, if we plan to expand this to 
more cases, like known array size + compile time constant index, it will get 
harder and harder to keep all the gadgets in sync. We can end up missing cases 
or detecting a code snippet both as safe and unsafe. The `isSafe` method would 
basically get rid of a whole class of problems, where safe and unsafe versions 
of the gadgets are overlapping. That being said, I am not insisting doing this 
change in this PR, it is OK doing the change later in a follow-up.


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

https://reviews.llvm.org/D137379

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


[PATCH] D137346: [-Wunsafe-buffer-usage] Initial commit - Transition away from raw buffer accesses.

2022-12-05 Thread 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 rG27ec85f8: [-Wunsafe-buffer-usage] Initial commit - 
Transition away from raw buffers. (authored by Artem Dergachev 
).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137346

Files:
  clang/include/clang/Analysis/Analyses/UnsafeBufferUsage.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Analysis/CMakeLists.txt
  clang/lib/Analysis/UnsafeBufferUsage.cpp
  clang/lib/Sema/AnalysisBasedWarnings.cpp
  clang/test/SemaCXX/warn-unsafe-buffer-usage.cpp

Index: clang/test/SemaCXX/warn-unsafe-buffer-usage.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/warn-unsafe-buffer-usage.cpp
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -Wunsafe-buffer-usage -verify %s
+
+void testIncrement(char *p) {
+  ++p; // expected-warning{{unchecked operation on raw buffer in expression}}
+  p++; // expected-warning{{unchecked operation on raw buffer in expression}}
+  --p; // expected-warning{{unchecked operation on raw buffer in expression}}
+  p--; // expected-warning{{unchecked operation on raw buffer in expression}}
+}
Index: clang/lib/Sema/AnalysisBasedWarnings.cpp
===
--- clang/lib/Sema/AnalysisBasedWarnings.cpp
+++ clang/lib/Sema/AnalysisBasedWarnings.cpp
@@ -29,6 +29,7 @@
 #include "clang/Analysis/Analyses/ReachableCode.h"
 #include "clang/Analysis/Analyses/ThreadSafety.h"
 #include "clang/Analysis/Analyses/UninitializedValues.h"
+#include "clang/Analysis/Analyses/UnsafeBufferUsage.h"
 #include "clang/Analysis/AnalysisDeclContext.h"
 #include "clang/Analysis/CFG.h"
 #include "clang/Analysis/CFGStmtMap.h"
@@ -2138,6 +2139,23 @@
 } // namespace consumed
 } // namespace clang
 
+//===--===//
+// Unsafe buffer usage analysis.
+//===--===//
+
+class UnsafeBufferUsageReporter : public UnsafeBufferUsageHandler {
+  Sema &S;
+
+public:
+  UnsafeBufferUsageReporter(Sema &S) : S(S) {}
+
+  void handleUnsafeOperation(const Stmt *Operation) override {
+S.Diag(Operation->getBeginLoc(), diag::warn_unsafe_buffer_usage)
+<< Operation->getSourceRange();
+  }
+};
+
+
 //===--===//
 // AnalysisBasedWarnings - Worker object used by Sema to execute analysis-based
 //  warnings on a function, method, or block.
@@ -2430,6 +2448,12 @@
   if (S.getLangOpts().CPlusPlus && isNoexcept(FD))
 checkThrowInNonThrowingFunc(S, FD, AC);
 
+  // Emit unsafe buffer usage warnings and fixits.
+  if (!Diags.isIgnored(diag::warn_unsafe_buffer_usage, D->getBeginLoc())) {
+UnsafeBufferUsageReporter R(S);
+checkUnsafeBufferUsage(D, R);
+  }
+
   // If none of the previous checks caused a CFG build, trigger one here
   // for the logical error handler.
   if (LogicalErrorHandler::hasActiveDiagnostics(Diags, D->getBeginLoc())) {
Index: clang/lib/Analysis/UnsafeBufferUsage.cpp
===
--- /dev/null
+++ clang/lib/Analysis/UnsafeBufferUsage.cpp
@@ -0,0 +1,79 @@
+//===- UnsafeBufferUsage.cpp - Replace pointers with modern C++ ---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "clang/Analysis/Analyses/UnsafeBufferUsage.h"
+#include "llvm/ADT/SmallVector.h"
+
+using namespace llvm;
+using namespace clang;
+using namespace ast_matchers;
+
+namespace {
+// TODO: Better abstractions over gadgets.
+using GadgetList = std::vector;
+}
+
+// Scan the function and return a list of gadgets found with provided kits.
+static GadgetList findGadgets(const Decl *D) {
+
+  class GadgetFinderCallback : public MatchFinder::MatchCallback {
+GadgetList &Output;
+
+  public:
+GadgetFinderCallback(GadgetList &Output) : Output(Output) {}
+
+void run(const MatchFinder::MatchResult &Result) override {
+  Output.push_back(Result.Nodes.getNodeAs("root_node"));
+}
+  };
+
+  GadgetList G;
+  MatchFinder M;
+
+  auto IncrementMatcher = unaryOperator(
+hasOperatorName("++"),
+hasUnaryOperand(hasType(pointerType()))
+  );
+  auto DecrementMatcher = unaryOperator(
+hasOperatorName("--"),
+hasUnaryOperand(hasType(pointerType()))
+  );
+
+  GadgetFinderCallback CB(G);
+
+  M.addMatcher(
+  stmt(forEachDescendant(
+stmt(
+  anyOf(
+IncrementMatcher,
+DecrementMa

[clang] 200007e - [-Wunsafe-buffer-usage] Initial commit - Transition away from raw buffers.

2022-12-05 Thread Artem Dergachev via cfe-commits

Author: Artem Dergachev
Date: 2022-12-05T15:13:42-08:00
New Revision: 27ec85f81122fd260a4e68308e54607ca37a

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

LOG: [-Wunsafe-buffer-usage] Initial commit - Transition away from raw buffers.

This is the initial commit for -Wunsafe-buffer-usage, a warning that helps
codebases (especially modern C++ codebases) transition away from raw buffer
pointers.

The warning is implemented in libAnalysis as it's going to become a non-trivial
analysis, mostly the fixit part where we try to figure out if we understand
a variable's use pattern well enough to suggest a safe container/view
as a replacement. Some parts of this analsysis may eventually prove useful
for any similar fixit machine that tries to change types of variables.

The warning is disabled by default.

RFC/discussion in https://discourse.llvm.org/t/rfc-c-buffer-hardening/65734

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

Added: 
clang/include/clang/Analysis/Analyses/UnsafeBufferUsage.h
clang/lib/Analysis/UnsafeBufferUsage.cpp
clang/test/SemaCXX/warn-unsafe-buffer-usage.cpp

Modified: 
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/Analysis/CMakeLists.txt
clang/lib/Sema/AnalysisBasedWarnings.cpp

Removed: 




diff  --git a/clang/include/clang/Analysis/Analyses/UnsafeBufferUsage.h 
b/clang/include/clang/Analysis/Analyses/UnsafeBufferUsage.h
new file mode 100644
index 0..1ddbb92eb66f7
--- /dev/null
+++ b/clang/include/clang/Analysis/Analyses/UnsafeBufferUsage.h
@@ -0,0 +1,38 @@
+//===- UnsafeBufferUsage.h - Replace pointers with modern C++ ---*- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+//  This file defines an analysis that aids replacing buffer accesses through
+//  raw pointers with safer C++ abstractions such as containers and 
views/spans.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_ANALYSIS_ANALYSES_UNSAFEBUFFERUSAGE_H
+#define LLVM_CLANG_ANALYSIS_ANALYSES_UNSAFEBUFFERUSAGE_H
+
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+
+namespace clang {
+
+/// The interface that lets the caller handle unsafe buffer usage analysis
+/// results by overriding this class's handle... methods.
+class UnsafeBufferUsageHandler {
+public:
+  UnsafeBufferUsageHandler() = default;
+  virtual ~UnsafeBufferUsageHandler() = default;
+
+  /// Invoked when an unsafe operation over raw pointers is found.
+  virtual void handleUnsafeOperation(const Stmt *Operation) = 0;
+};
+
+// This function invokes the analysis and allows the caller to react to it
+// through the handler class.
+void checkUnsafeBufferUsage(const Decl *D, UnsafeBufferUsageHandler &Handler);
+
+} // end namespace clang
+
+#endif /* LLVM_CLANG_ANALYSIS_ANALYSES_UNSAFEBUFFERUSAGE_H */

diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 15f85b778ccc6..6a831abebf694 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -11732,4 +11732,9 @@ def err_cast_from_randomized_struct : Error<
 // LoongArch-specific Diagnostics
 def err_loongarch_builtin_requires_la64 : Error<
   "this builtin requires target: loongarch64">;
+
+// Unsafe buffer usage diagnostics.
+def warn_unsafe_buffer_usage : Warning<
+  "unchecked operation on raw buffer in expression">,
+  InGroup>, DefaultIgnore;
 } // end of sema component.

diff  --git a/clang/lib/Analysis/CMakeLists.txt 
b/clang/lib/Analysis/CMakeLists.txt
index 16e3f474060cb..ea6cb59e8e199 100644
--- a/clang/lib/Analysis/CMakeLists.txt
+++ b/clang/lib/Analysis/CMakeLists.txt
@@ -32,6 +32,7 @@ add_clang_library(clangAnalysis
   ThreadSafetyLogical.cpp
   ThreadSafetyTIL.cpp
   UninitializedValues.cpp
+  UnsafeBufferUsage.cpp
 
   LINK_LIBS
   clangAST

diff  --git a/clang/lib/Analysis/UnsafeBufferUsage.cpp 
b/clang/lib/Analysis/UnsafeBufferUsage.cpp
new file mode 100644
index 0..0f8fb68942116
--- /dev/null
+++ b/clang/lib/Analysis/UnsafeBufferUsage.cpp
@@ -0,0 +1,79 @@
+//===- UnsafeBufferUsage.cpp - Replace pointers with modern C++ 
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "clang/Analysis/Analyses/Un

[PATCH] D139296: [msan][CodeGen] Set noundef for C return value

2022-12-05 Thread Arthur Eubanks via Phabricator via cfe-commits
aeubanks added inline comments.



Comment at: clang/lib/CodeGen/CGCall.cpp:1828
  !Module.MayDropFunctionReturn(Module.getContext(), RetTy) ||
  Module.getLangOpts().Sanitize.has(SanitizerKind::Memory) ||
  Module.getLangOpts().Sanitize.has(SanitizerKind::Return);

should this be dropped? and maybe also move up `SanitizerKind::Return`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139296

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


[PATCH] D138868: AMDGPU/clang: Remove target features from address space test builtins

2022-12-05 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added a comment.

ping


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

https://reviews.llvm.org/D138868

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


[PATCH] D138807: [RISCV] Support vector crypto extension ISA string and assembly

2022-12-05 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added a comment.

In D138807#3962417 , @craig.topper 
wrote:

> Anything that uses OP-P needs to have a DecoderNamespace assigned and 
> RISCVDisassembler::getInstruction will need to lookup that table when V/Zve 
> is enabled. Otherwise we will have a conflict if the P extension is ever 
> commited to LLVM.

I think we can ignore the OP-P conflict until P is ratified and added to LLVM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138807

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


[PATCH] D139154: [clang-doc] Add template support

2022-12-05 Thread Brett Wilson via Phabricator via cfe-commits
brettw updated this revision to Diff 480251.
brettw added a reviewer: paulkirth.

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

https://reviews.llvm.org/D139154

Files:
  clang-tools-extra/clang-doc/BitcodeReader.cpp
  clang-tools-extra/clang-doc/BitcodeWriter.cpp
  clang-tools-extra/clang-doc/BitcodeWriter.h
  clang-tools-extra/clang-doc/Representation.cpp
  clang-tools-extra/clang-doc/Representation.h
  clang-tools-extra/clang-doc/Serialize.cpp
  clang-tools-extra/clang-doc/YAMLGenerator.cpp
  clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp
  clang-tools-extra/unittests/clang-doc/SerializeTest.cpp
  clang-tools-extra/unittests/clang-doc/YAMLGeneratorTest.cpp

Index: clang-tools-extra/unittests/clang-doc/YAMLGeneratorTest.cpp
===
--- clang-tools-extra/unittests/clang-doc/YAMLGeneratorTest.cpp
+++ clang-tools-extra/unittests/clang-doc/YAMLGeneratorTest.cpp
@@ -28,10 +28,11 @@
   I.Path = "path/to/A";
   I.Namespace.emplace_back(EmptySID, "A", InfoType::IT_namespace);
 
-  I.Children.Namespaces.emplace_back(EmptySID, "ChildNamespace",
- InfoType::IT_namespace,
- "path/to/A/Namespace");
+  I.Children.Namespaces.emplace_back(
+  EmptySID, "ChildNamespace", InfoType::IT_namespace,
+  "path::to::A::Namespace::ChildNamespace", "path/to/A/Namespace");
   I.Children.Records.emplace_back(EmptySID, "ChildStruct", InfoType::IT_record,
+  "path::to::A::Namespace::ChildStruct",
   "path/to/A/Namespace");
   I.Children.Functions.emplace_back();
   I.Children.Functions.back().Name = "OneFunction";
@@ -53,13 +54,16 @@
 Namespace:
   - Type:Namespace
 Name:'A'
+QualName:'A'
 ChildNamespaces:
   - Type:Namespace
 Name:'ChildNamespace'
+QualName:'path::to::A::Namespace::ChildNamespace'
 Path:'path/to/A/Namespace'
 ChildRecords:
   - Type:Record
 Name:'ChildStruct'
+QualName:'path::to::A::Namespace::ChildStruct'
 Path:'path/to/A/Namespace'
 ChildFunctions:
   - USR: ''
@@ -83,8 +87,7 @@
   I.DefLoc = Location(10, llvm::SmallString<16>{"test.cpp"});
   I.Loc.emplace_back(12, llvm::SmallString<16>{"test.cpp"});
 
-  I.Members.emplace_back(TypeInfo("int", "path/to/int"), "X",
- AccessSpecifier::AS_private);
+  I.Members.emplace_back(TypeInfo("int"), "X", AccessSpecifier::AS_private);
 
   // Member documentation.
   CommentInfo TopComment;
@@ -103,15 +106,15 @@
AccessSpecifier::AS_public, true);
   I.Bases.back().Children.Functions.emplace_back();
   I.Bases.back().Children.Functions.back().Name = "InheritedFunctionOne";
-  I.Bases.back().Members.emplace_back(TypeInfo("int", "path/to/int"), "N",
+  I.Bases.back().Members.emplace_back(TypeInfo("int"), "N",
   AccessSpecifier::AS_private);
   // F is in the global namespace
   I.Parents.emplace_back(EmptySID, "F", InfoType::IT_record, "");
   I.VirtualParents.emplace_back(EmptySID, "G", InfoType::IT_record,
-"path/to/G");
+"path::to::G::G", "path/to/G");
 
   I.Children.Records.emplace_back(EmptySID, "ChildStruct", InfoType::IT_record,
-  "path/to/A/r");
+  "path::to::A::r::ChildStruct", "path/to/A/r");
   I.Children.Functions.emplace_back();
   I.Children.Functions.back().Name = "OneFunction";
   I.Children.Enums.emplace_back();
@@ -131,6 +134,7 @@
 Namespace:
   - Type:Namespace
 Name:'A'
+QualName:'A'
 DefLocation:
   LineNumber:  10
   Filename:'test.cpp'
@@ -142,7 +146,7 @@
 Members:
   - Type:
   Name:'int'
-  Path:'path/to/int'
+  QualName:'int'
 Name:'X'
 Access:  Private
 Description:
@@ -161,7 +165,7 @@
 Members:
   - Type:
   Name:'int'
-  Path:'path/to/int'
+  QualName:'int'
 Name:'N'
 Access:  Private
 ChildFunctions:
@@ -178,10 +182,12 @@
 VirtualParents:
   - Type:Record
 Name:'G'
+QualName:'path::to::G::G'
 Path:'path/to/G'
 ChildRecords:
   - Type:Record
 Name:'ChildStruct'
+QualName:'path::to::A::r::ChildStruct'
 Path:'path/to/A/r'
 ChildFunctions:
   - USR: ''
@@ -206,10 +212,9 @@
 
   I.Access = AccessSpecifier::AS_none;
 
-  I.ReturnType = TypeInfo(
-  Reference(EmptySID, "void", InfoType::IT_default, "path/to/void"));
-  I

[PATCH] D137107: Allow MS extension: support of constexpr with __declspec(dllimport).

2022-12-05 Thread Zahira Ammarguellat via Phabricator via cfe-commits
zahiraam added inline comments.



Comment at: clang/lib/CodeGen/CGDeclCXX.cpp:572
 PrioritizedCXXGlobalInits.push_back(std::make_pair(Key, Fn));
+  } else if (D->hasConstantInitialization() && !(D->hasAttr())) 
{
+OrderGlobalInitsOrStermFinalizers Key(201,

efriedma wrote:
> How is ConstInitAttr relevant here?
This change made (without the !(D->hasAttr()) made the LIT 
behavior of aix-static-init.cpp. The IR generated for 
namespace test3 {
  struct Test3 {
constexpr Test3() {};
~Test3() {};
  };

  constinit Test3 t;
} // namespace test3

was different. I would have thought that the change we made for constexpr 
wouldn't affter constinit? 



Comment at: clang/test/Sema/dllimport.c:41
 // Address of variables can't be used for initialization in C language modes.
-int *VarForInit = &GlobalDecl; // expected-error{{initializer element is not a 
compile-time constant}}
+int *VarForInit = &GlobalDecl;
 

efriedma wrote:
> Like I mentioned before, we might want to restrict this feature to C++.
Sorry I forgot about that. I will change that so that the diag is generated 
only for C++.


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

https://reviews.llvm.org/D137107

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


[PATCH] D139137: add floor library function

2022-12-05 Thread Chris Bieneman via Phabricator via cfe-commits
beanz accepted this revision.
beanz added a comment.
This revision is now accepted and ready to land.

LGTM. @bob80905 if you haven't already, you should follow the steps here 
(https://www.llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access) to get 
commit access.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139137

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


[PATCH] D139296: [msan][CodeGen] Set noundef for C return value

2022-12-05 Thread Kevin Athey via Phabricator via cfe-commits
kda accepted this revision.
kda added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139296

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


[PATCH] D139148: Fix nullptr dereference found by Coverity static analysis tool

2022-12-05 Thread Tom Honermann via Phabricator via cfe-commits
tahonermann added a comment.

> I don't see any after this point.

You're right! I thought I had seen some, but upon checking, I agree. That is a 
good sign we're on the right path!


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

https://reviews.llvm.org/D139148

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


[PATCH] D139296: [msan][CodeGen] Set noundef for C return value

2022-12-05 Thread Vitaly Buka via Phabricator via cfe-commits
vitalybuka added a comment.

In D139296#3972142 , @kda wrote:

> Is there a risk of this being too strict for standard C?
>
> Should there be a test case for our specific problem?  (C calling C++)

Probably not. It's cross module mismatch. To reproduce we need two module and 
one of them will do about the same as the current msan-param-retval.c.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139296

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


[libunwind] 96d6399 - Revert "[CMake] Use LLVM_TARGET_TRIPLE in runtimes"

2022-12-05 Thread Leonard Chan via cfe-commits

Author: Leonard Chan
Date: 2022-12-05T22:20:51Z
New Revision: 96d63993dd3698bbf2d6a83c035cd05faed7317b

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

LOG: Revert "[CMake] Use LLVM_TARGET_TRIPLE in runtimes"

This reverts commit bec8a372fc0db95852748691c0f4933044026b25.

This causes many of these errors to appear when rebuilding runtimes part
of fuchsia's toolchain:

ld.lld: error:
/usr/local/google/home/paulkirth/llvm-upstream/build/lib/x86_64-unknown-linux-gnu/libunwind.a(libunwind.cpp.o)
is incompatible with elf64-x86-64

This can be reproduced by making a complete toolchain, saving any source
file with no changes, then rerunning ninja distribution.

Added: 


Modified: 
compiler-rt/cmake/config-ix.cmake
libc/lib/CMakeLists.txt
libcxx/CMakeLists.txt
libcxx/docs/BuildingLibcxx.rst
libcxx/lib/abi/CMakeLists.txt
libcxx/test/CMakeLists.txt
libcxxabi/CMakeLists.txt
libcxxabi/test/CMakeLists.txt
libunwind/CMakeLists.txt
libunwind/test/CMakeLists.txt
llvm/cmake/modules/LLVMExternalProjectUtils.cmake
llvm/runtimes/CMakeLists.txt
runtimes/CMakeLists.txt

Removed: 




diff  --git a/compiler-rt/cmake/config-ix.cmake 
b/compiler-rt/cmake/config-ix.cmake
index 9eb48b8f2ba5..fd7daa50bdd9 100644
--- a/compiler-rt/cmake/config-ix.cmake
+++ b/compiler-rt/cmake/config-ix.cmake
@@ -689,8 +689,8 @@ else()
   set(CAN_SYMBOLIZE 1)
 endif()
 
-find_program(GNU_LD_EXECUTABLE NAMES ${LLVM_TARGET_TRIPLE}-ld.bfd ld.bfd DOC 
"GNU ld")
-find_program(GOLD_EXECUTABLE NAMES ${LLVM_TARGET_TRIPLE}-ld.gold ld.gold DOC 
"GNU gold")
+find_program(GNU_LD_EXECUTABLE NAMES ${LLVM_DEFAULT_TARGET_TRIPLE}-ld.bfd 
ld.bfd DOC "GNU ld")
+find_program(GOLD_EXECUTABLE NAMES ${LLVM_DEFAULT_TARGET_TRIPLE}-ld.gold 
ld.gold DOC "GNU gold")
 
 if(COMPILER_RT_SUPPORTED_ARCH)
   list(REMOVE_DUPLICATES COMPILER_RT_SUPPORTED_ARCH)

diff  --git a/libc/lib/CMakeLists.txt b/libc/lib/CMakeLists.txt
index 1080fdf00931..b7eb0a133a17 100644
--- a/libc/lib/CMakeLists.txt
+++ b/libc/lib/CMakeLists.txt
@@ -10,7 +10,7 @@ set_target_properties(
 )
 
 if(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR)
-  set(LIBC_INSTALL_LIBRARY_DIR lib${LLVM_LIBDIR_SUFFIX}/${LLVM_TARGET_TRIPLE})
+  set(LIBC_INSTALL_LIBRARY_DIR 
lib${LLVM_LIBDIR_SUFFIX}/${LLVM_DEFAULT_TARGET_TRIPLE})
 else()
   set(LIBC_INSTALL_LIBRARY_DIR lib${LLVM_LIBDIR_SUFFIX})
 endif()

diff  --git a/libcxx/CMakeLists.txt b/libcxx/CMakeLists.txt
index 437c4b2f87a0..454caedcdf3f 100644
--- a/libcxx/CMakeLists.txt
+++ b/libcxx/CMakeLists.txt
@@ -413,12 +413,12 @@ set(LIBCXX_SHARED_OUTPUT_NAME "c++" CACHE STRING "Output 
name for the shared lib
 set(LIBCXX_STATIC_OUTPUT_NAME "c++" CACHE STRING "Output name for the static 
libc++ runtime library.")
 
 if(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND NOT APPLE)
-  set(LIBCXX_LIBRARY_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR}/${LLVM_TARGET_TRIPLE})
+  set(LIBCXX_LIBRARY_DIR 
${LLVM_LIBRARY_OUTPUT_INTDIR}/${LLVM_DEFAULT_TARGET_TRIPLE})
   set(LIBCXX_GENERATED_INCLUDE_DIR "${LLVM_BINARY_DIR}/include/c++/v1")
-  set(LIBCXX_GENERATED_INCLUDE_TARGET_DIR 
"${LLVM_BINARY_DIR}/include/${LLVM_TARGET_TRIPLE}/c++/v1")
-  set(LIBCXX_INSTALL_LIBRARY_DIR 
lib${LLVM_LIBDIR_SUFFIX}/${LLVM_TARGET_TRIPLE} CACHE PATH
+  set(LIBCXX_GENERATED_INCLUDE_TARGET_DIR 
"${LLVM_BINARY_DIR}/include/${LLVM_DEFAULT_TARGET_TRIPLE}/c++/v1")
+  set(LIBCXX_INSTALL_LIBRARY_DIR 
lib${LLVM_LIBDIR_SUFFIX}/${LLVM_DEFAULT_TARGET_TRIPLE} CACHE PATH
   "Path where built libc++ libraries should be installed.")
-  set(LIBCXX_INSTALL_INCLUDE_TARGET_DIR 
"${CMAKE_INSTALL_INCLUDEDIR}/${LLVM_TARGET_TRIPLE}/c++/v1" CACHE PATH
+  set(LIBCXX_INSTALL_INCLUDE_TARGET_DIR 
"${CMAKE_INSTALL_INCLUDEDIR}/${LLVM_DEFAULT_TARGET_TRIPLE}/c++/v1" CACHE PATH
   "Path where target-specific libc++ headers should be installed.")
   if(LIBCXX_LIBDIR_SUBDIR)
 string(APPEND LIBCXX_LIBRARY_DIR /${LIBCXX_LIBDIR_SUBDIR})

diff  --git a/libcxx/docs/BuildingLibcxx.rst b/libcxx/docs/BuildingLibcxx.rst
index 5d51088f71ad..59c695efe44e 100644
--- a/libcxx/docs/BuildingLibcxx.rst
+++ b/libcxx/docs/BuildingLibcxx.rst
@@ -281,7 +281,7 @@ libc++ specific options
 .. option:: LIBCXX_INSTALL_INCLUDE_TARGET_DIR:PATH
 
   **Default**: ``include/c++/v1`` or
-  ``include/${LLVM_TARGET_TRIPLE}/c++/v1``
+  ``include/${LLVM_DEFAULT_TARGET_TRIPLE}/c++/v1``
 
   Path where target-specific libc++ headers should be installed. If a relative
   path, relative to ``CMAKE_INSTALL_PREFIX``.

diff  --git a/libcxx/lib/abi/CMakeLists.txt b/libcxx/lib/abi/CMakeLists.txt
index a40794c54c3e..7c08bd06c50b 100644
--- a/libcxx/lib/abi/CMakeLists.txt
+++ b/libcxx/lib/abi/CMakeLists.txt
@@ -43,7 +43,7 @@ endfunction()
 if (CMAKE_CXX_COMPILER_TARGET)
   set(triple "${CMAKE_CXX_COMPILER_TARGET}")
 else()
-  set(triple "${L

[PATCH] D137107: Allow MS extension: support of constexpr with __declspec(dllimport).

2022-12-05 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added a comment.

(-Wglobal-constructors warning is still not implemented.)




Comment at: clang/lib/CodeGen/CGDeclCXX.cpp:572
 PrioritizedCXXGlobalInits.push_back(std::make_pair(Key, Fn));
+  } else if (D->hasConstantInitialization() && !(D->hasAttr())) 
{
+OrderGlobalInitsOrStermFinalizers Key(201,

How is ConstInitAttr relevant here?



Comment at: clang/test/Sema/dllimport.c:41
 // Address of variables can't be used for initialization in C language modes.
-int *VarForInit = &GlobalDecl; // expected-error{{initializer element is not a 
compile-time constant}}
+int *VarForInit = &GlobalDecl;
 

Like I mentioned before, we might want to restrict this feature to C++.


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

https://reviews.llvm.org/D137107

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


[PATCH] D137996: Add support for a backdoor driver option that enables emitting header usage information in JSON to a file

2022-12-05 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:5660
+"-header-include-filtering=" +
+std::string(D.CCPrintHeadersFiltering ? "on" : "off")));
   }

Let's change "on" to something that won't interfere with potential future 
filters. How about "no-transitive-system"? (or "only-direct-system" if that 
better fits the semantics)

Same for the command-line counterpart.



Comment at: clang/lib/Frontend/HeaderIncludeGen.cpp:161
+  case HIF_Textual: {
+assert(!DepOpts.HeaderIncludeFiltering &&
+   "header filtering is currently always disabled when output format 
is"

I don't think asserting on invalid user input is a good strategy. Let's emit a 
diagnostic and exit gracefully instead.



Comment at: clang/tools/driver/driver.cpp:278
+(TheDriver.CCPrintHeadersFormat == HIF_JSON && !Filtering)) {
+  llvm::errs()
+  << "error: unsupported configuration: "

This should probably be a proper diagnostic.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137996

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


[PATCH] D139296: [msan][CodeGen] Set noundef for C return value

2022-12-05 Thread Kevin Athey via Phabricator via cfe-commits
kda added a comment.

Is there a risk of this being too strict for standard C?

Should there be a test case for our specific problem?  (C calling C++)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139296

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


[PATCH] D138337: Add support for kcfi-seal optimization with LTO

2022-12-05 Thread Sami Tolvanen via Phabricator via cfe-commits
samitolvanen added a comment.

In D138337#3972009 , @pcc wrote:

> Can't this be implicit if LTO is being used?

I would prefer to keep this behind a flag (similarly to `-mibt-seal`), so we 
can better control when and where the optimization enabled. For example, 
enabling this implicitly would currently break LTO+KCFI kernel builds as the 
kernel has global functions that are not address-taken in C code, but still end 
up being indirect called because their addresses were taken in assembly code 
that wasn't visible to LTO (e.g. arm64's `alternative_cb` mechanism).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138337

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


[PATCH] D139148: Fix nullptr dereference found by Coverity static analysis tool

2022-12-05 Thread Sindhu Chittireddy via Phabricator via cfe-commits
schittir added a comment.

In D139148#3969383 , @tahonermann 
wrote:

> When committing changes to address Coverity reported issues, I think it would 
> be useful to include the Coverity analysis in the commit message. A textual 
> representation can be obtained using `cov-format-errors --emacs-style` from 
> the command line with access to the intermediate directory. I'm not sure if a 
> textual representation can be obtained through the Coverity UI though.

Couldn't find a way to do this via the UI, so I am trying the command line way.


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

https://reviews.llvm.org/D139148

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


[PATCH] D139148: Fix nullptr dereference found by Coverity static analysis tool

2022-12-05 Thread Sindhu Chittireddy via Phabricator via cfe-commits
schittir added a comment.



> Perhaps the` assert` should be added after line 5926 above.

Done.

> I think the checks for `Initializer` being non-null following the addition of 
> an `assert` should be removed.

I don't see any after this point.


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

https://reviews.llvm.org/D139148

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


[PATCH] D139137: add floor library function

2022-12-05 Thread Joshua Batista via Phabricator via cfe-commits
bob80905 updated this revision to Diff 480218.
bob80905 added a comment.

- update with clang format


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139137

Files:
  clang/lib/Headers/hlsl/hlsl_intrinsics.h
  clang/test/CodeGenHLSL/builtins/floor.hlsl

Index: clang/test/CodeGenHLSL/builtins/floor.hlsl
===
--- /dev/null
+++ clang/test/CodeGenHLSL/builtins/floor.hlsl
@@ -0,0 +1,79 @@
+// RUN: %clang_cc1 -std=hlsl2021 -finclude-default-header -x hlsl -triple \
+// RUN:   dxil-pc-shadermodel6.3-library %s -fnative-half-type \
+// RUN:   -emit-llvm -disable-llvm-passes -O3 -o - | FileCheck %s
+// RUN: %clang_cc1 -std=hlsl2021 -finclude-default-header -x hlsl -triple \
+// RUN:   dxil-pc-shadermodel6.3-library %s -emit-llvm -disable-llvm-passes \
+// RUN:   -D__HLSL_ENABLE_16_BIT -o - | FileCheck %s --check-prefix=NO_HALF
+
+using hlsl::floor;
+
+// CHECK: define noundef half @
+// CHECK: call half @llvm.floor.f16(
+// NO_HALF: define noundef float @"?test_floor_half@@YA$halff@$halff@@Z"(
+// NO_HALF: call float @llvm.floor.f32(float %0)
+half test_floor_half ( half p0 ) {
+  return floor ( p0 );
+}
+// CHECK: define noundef <2 x half> @
+// CHECK: call <2 x half> @llvm.floor.v2f16(
+// NO_HALF: define noundef <2 x float> @"?test_floor_half2@@YAT?$__vector@$halff@$01@__clang@@T12@@Z"(
+// NO_HALF: call <2 x float> @llvm.floor.v2f32(
+half2 test_floor_half2 ( half2 p0 ) {
+  return floor ( p0 );
+}
+// CHECK: define noundef <3 x half> @
+// CHECK: call <3 x half> @llvm.floor.v3f16(
+// NO_HALF: define noundef <3 x float> @"?test_floor_half3@@YAT?$__vector@$halff@$02@__clang@@T12@@Z"(
+// NO_HALF: call <3 x float> @llvm.floor.v3f32(
+half3 test_floor_half3 ( half3 p0 ) {
+  return floor ( p0 );
+}
+// CHECK: define noundef <4 x half> @
+// CHECK: call <4 x half> @llvm.floor.v4f16(
+// NO_HALF: define noundef <4 x float> @"?test_floor_half4@@YAT?$__vector@$halff@$03@__clang@@T12@@Z"(
+// NO_HALF: call <4 x float> @llvm.floor.v4f32(
+half4 test_floor_half4 ( half4 p0 ) {
+  return floor ( p0 );
+}
+
+// CHECK: define noundef float @
+// CHECK: call float @llvm.floor.f32(
+float test_floor_float ( float p0 ) {
+  return floor ( p0 );
+}
+// CHECK: define noundef <2 x float> @
+// CHECK: call <2 x float> @llvm.floor.v2f32(
+float2 test_floor_float2 ( float2 p0 ) {
+  return floor ( p0 );
+}
+// CHECK: define noundef <3 x float> @
+// CHECK: call <3 x float> @llvm.floor.v3f32(
+float3 test_floor_float3 ( float3 p0 ) {
+  return floor ( p0 );
+}
+// CHECK: define noundef <4 x float> @
+// CHECK: call <4 x float> @llvm.floor.v4f32(
+float4 test_floor_float4 ( float4 p0 ) {
+  return floor ( p0 );
+}
+
+// CHECK: define noundef double @
+// CHECK: call double @llvm.floor.f64(
+double test_floor_double ( double p0 ) {
+  return floor ( p0 );
+}
+// CHECK: define noundef <2 x double> @
+// CHECK: call <2 x double> @llvm.floor.v2f64(
+double2 test_floor_double2 ( double2 p0 ) {
+  return floor ( p0 );
+}
+// CHECK: define noundef <3 x double> @
+// CHECK: call <3 x double> @llvm.floor.v3f64(
+double3 test_floor_double3 ( double3 p0 ) {
+  return floor ( p0 );
+}
+// CHECK: define noundef <4 x double> @
+// CHECK: call <4 x double> @llvm.floor.v4f64(
+double4 test_floor_double4 ( double4 p0 ) {
+  return floor ( p0 );
+}
Index: clang/lib/Headers/hlsl/hlsl_intrinsics.h
===
--- clang/lib/Headers/hlsl/hlsl_intrinsics.h
+++ clang/lib/Headers/hlsl/hlsl_intrinsics.h
@@ -101,6 +101,36 @@
 __attribute__((clang_builtin_alias(__builtin_elementwise_ceil)))
 double4 ceil(double4);
 
+// floor builtins
+#ifdef __HLSL_ENABLE_16_BIT
+__attribute__((clang_builtin_alias(__builtin_elementwise_floor)))
+half floor(half);
+__attribute__((clang_builtin_alias(__builtin_elementwise_floor)))
+half2 floor(half2);
+__attribute__((clang_builtin_alias(__builtin_elementwise_floor)))
+half3 floor(half3);
+__attribute__((clang_builtin_alias(__builtin_elementwise_floor)))
+half4 floor(half4);
+#endif
+
+__attribute__((clang_builtin_alias(__builtin_elementwise_floor))) float
+floor(float);
+__attribute__((clang_builtin_alias(__builtin_elementwise_floor)))
+float2 floor(float2);
+__attribute__((clang_builtin_alias(__builtin_elementwise_floor)))
+float3 floor(float3);
+__attribute__((clang_builtin_alias(__builtin_elementwise_floor)))
+float4 floor(float4);
+
+__attribute__((clang_builtin_alias(__builtin_elementwise_floor))) double
+floor(double);
+__attribute__((clang_builtin_alias(__builtin_elementwise_floor)))
+double2 floor(double2);
+__attribute__((clang_builtin_alias(__builtin_elementwise_floor)))
+double3 floor(double3);
+__attribute__((clang_builtin_alias(__builtin_elementwise_floor)))
+double4 floor(double4);
+
 // cos builtins
 #ifdef __HLSL_ENABLE_16_BIT
 __attribute__((clang_builtin_alias(__builtin_elementwise_cos))) half cos(half);
__

[PATCH] D139360: [clang][dataflow] Support (in)equality operators in `optional` model.

2022-12-05 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun accepted this revision.
xazax.hun added a comment.
This revision is now accepted and ready to land.

LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139360

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


[PATCH] D139148: Fix nullptr dereference found by Coverity static analysis tool

2022-12-05 Thread Sindhu Chittireddy via Phabricator via cfe-commits
schittir updated this revision to Diff 480217.
schittir added a comment.

Move the assert to after the branches that handle the cases where Initializer 
may be null


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

https://reviews.llvm.org/D139148

Files:
  clang/lib/Sema/SemaInit.cpp


Index: clang/lib/Sema/SemaInit.cpp
===
--- clang/lib/Sema/SemaInit.cpp
+++ clang/lib/Sema/SemaInit.cpp
@@ -5925,6 +5925,8 @@
 return;
   }
 
+  assert(Initializer && "Intializer must be non-null");
+
   // Determine whether we should consider writeback conversions for
   // Objective-C ARC.
   bool allowObjCWritebackConversion = S.getLangOpts().ObjCAutoRefCount &&


Index: clang/lib/Sema/SemaInit.cpp
===
--- clang/lib/Sema/SemaInit.cpp
+++ clang/lib/Sema/SemaInit.cpp
@@ -5925,6 +5925,8 @@
 return;
   }
 
+  assert(Initializer && "Intializer must be non-null");
+
   // Determine whether we should consider writeback conversions for
   // Objective-C ARC.
   bool allowObjCWritebackConversion = S.getLangOpts().ObjCAutoRefCount &&
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 7d58c95 - [Clang] Don't consider default constructors ineligible if the more constrained constructor is a template

2022-12-05 Thread Roy Jacobson via cfe-commits

Author: Roy Jacobson
Date: 2022-12-05T23:02:37+02:00
New Revision: 7d58c95635cce63ce6acd43c953b57f10bf5c686

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

LOG: [Clang] Don't consider default constructors ineligible if the more 
constrained constructor is a template

Partially solves https://github.com/llvm/llvm-project/issues/59206:

We now mark trivial constructors as eligible even if there's a more constrained 
templated default constructor. Although technically non-conformant, this solves 
problems with pretty reasonable uses cases like
```
template
struct Foo {
constexpr Foo() = default;

template
Foo(Ts... vals) requires(sizeof...(Ts) == n) {}
};
```
where we currently consider the default constructor to be ineligible and 
therefor inheriting/containing classes have non trivial constructors. This is 
aligned with GCC: 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c75ebe76ae12ac4020f20a24f34606a594a40d15

This doesn't change `__is_trivial`. Although we're technically standard 
conformant in this regard, GCC/MSVC exhibit different behaviors that seem to 
make more sense. An issue has been filed to CWG and we await their response.

Reviewed By: erichkeane, #clang-language-wg

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

Added: 


Modified: 
clang/lib/AST/DeclCXX.cpp
clang/lib/Sema/SemaDecl.cpp
clang/test/SemaCXX/constrained-special-member-functions.cpp

Removed: 




diff  --git a/clang/lib/AST/DeclCXX.cpp b/clang/lib/AST/DeclCXX.cpp
index bc7589e418f2c..603075702a837 100644
--- a/clang/lib/AST/DeclCXX.cpp
+++ b/clang/lib/AST/DeclCXX.cpp
@@ -1378,7 +1378,11 @@ void 
CXXRecordDecl::addedSelectedDestructor(CXXDestructorDecl *DD) {
 }
 
 void CXXRecordDecl::addedEligibleSpecialMemberFunction(const CXXMethodDecl *MD,
-   unsigned SMKind) {
+   unsigned SMKind) {
+  // FIXME: We shouldn't change DeclaredNonTrivialSpecialMembers if `MD` is
+  // a function template, but this needs CWG attention before we break ABI.
+  // See https://github.com/llvm/llvm-project/issues/59206
+
   if (const auto *DD = dyn_cast(MD)) {
 if (DD->isUserProvided())
   data().HasIrrelevantDestructor = false;

diff  --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index 96ea3fb402e74..0b6e2e5564870 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -18193,8 +18193,11 @@ static bool 
AreSpecialMemberFunctionsSameKind(ASTContext &Context,
   CXXMethodDecl *M1,
   CXXMethodDecl *M2,
   Sema::CXXSpecialMember CSM) {
+  // We don't want to compare templates to non-templates: See
+  // https://github.com/llvm/llvm-project/issues/59206
   if (CSM == Sema::CXXDefaultConstructor)
-return true;
+return bool(M1->getDescribedFunctionTemplate()) ==
+   bool(M2->getDescribedFunctionTemplate());
   if (!Context.hasSameType(M1->getParamDecl(0)->getType(),
M2->getParamDecl(0)->getType()))
 return false;

diff  --git a/clang/test/SemaCXX/constrained-special-member-functions.cpp 
b/clang/test/SemaCXX/constrained-special-member-functions.cpp
index 33ed4050553b8..69d50eb04c572 100644
--- a/clang/test/SemaCXX/constrained-special-member-functions.cpp
+++ b/clang/test/SemaCXX/constrained-special-member-functions.cpp
@@ -225,3 +225,43 @@ void func() {
   S<2, 2> s2;
 }
 }
+
+namespace GH59206 {
+
+struct A {
+  A() = default; //eligible, second constructor unsatisfied
+  template
+  A(Args&&... args) requires (sizeof...(Args) > 0) {}
+};
+
+struct B {
+  B() = default; //ineligible, second constructor more constrained
+  template
+  B(Args&&... args) requires (sizeof...(Args) == 0) {}
+};
+
+struct C {
+  C() = default; //eligible, but
+  template //also eligible and non-trivial
+  C(Args&&... args) {}
+};
+
+struct D : B {};
+
+static_assert(__is_trivially_copyable(A), "");
+static_assert(__is_trivially_copyable(B), "");
+static_assert(__is_trivially_copyable(C), "");
+static_assert(__is_trivially_copyable(D), "");
+
+// FIXME: Update when https://github.com/llvm/llvm-project/issues/59206 is
+// resolved.
+static_assert(!__is_trivial(A), "");
+static_assert(!__is_trivial(B), "");
+static_assert(!__is_trivial(C), "");
+static_assert(__is_trivial(D), "");
+static_assert(__is_trivially_constructible(A), "");
+static_assert(__is_trivially_constructible(B), "");
+static_assert(__is_trivially_constructible(C), "");
+static_assert(__is_trivially_constructible(D), "");
+
+}



___
cfe-commits mailing list
cfe-commits@l

[PATCH] D139038: [Clang] Don't consider default constructors ineligible if the more constrained constructor is a template

2022-12-05 Thread Roy Jacobson 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 rG7d58c95635cc: [Clang] Don't consider default 
constructors ineligible if the more constrained… (authored by royjacobson).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139038

Files:
  clang/lib/AST/DeclCXX.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/test/SemaCXX/constrained-special-member-functions.cpp


Index: clang/test/SemaCXX/constrained-special-member-functions.cpp
===
--- clang/test/SemaCXX/constrained-special-member-functions.cpp
+++ clang/test/SemaCXX/constrained-special-member-functions.cpp
@@ -225,3 +225,43 @@
   S<2, 2> s2;
 }
 }
+
+namespace GH59206 {
+
+struct A {
+  A() = default; //eligible, second constructor unsatisfied
+  template
+  A(Args&&... args) requires (sizeof...(Args) > 0) {}
+};
+
+struct B {
+  B() = default; //ineligible, second constructor more constrained
+  template
+  B(Args&&... args) requires (sizeof...(Args) == 0) {}
+};
+
+struct C {
+  C() = default; //eligible, but
+  template //also eligible and non-trivial
+  C(Args&&... args) {}
+};
+
+struct D : B {};
+
+static_assert(__is_trivially_copyable(A), "");
+static_assert(__is_trivially_copyable(B), "");
+static_assert(__is_trivially_copyable(C), "");
+static_assert(__is_trivially_copyable(D), "");
+
+// FIXME: Update when https://github.com/llvm/llvm-project/issues/59206 is
+// resolved.
+static_assert(!__is_trivial(A), "");
+static_assert(!__is_trivial(B), "");
+static_assert(!__is_trivial(C), "");
+static_assert(__is_trivial(D), "");
+static_assert(__is_trivially_constructible(A), "");
+static_assert(__is_trivially_constructible(B), "");
+static_assert(__is_trivially_constructible(C), "");
+static_assert(__is_trivially_constructible(D), "");
+
+}
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -18193,8 +18193,11 @@
   CXXMethodDecl *M1,
   CXXMethodDecl *M2,
   Sema::CXXSpecialMember CSM) {
+  // We don't want to compare templates to non-templates: See
+  // https://github.com/llvm/llvm-project/issues/59206
   if (CSM == Sema::CXXDefaultConstructor)
-return true;
+return bool(M1->getDescribedFunctionTemplate()) ==
+   bool(M2->getDescribedFunctionTemplate());
   if (!Context.hasSameType(M1->getParamDecl(0)->getType(),
M2->getParamDecl(0)->getType()))
 return false;
Index: clang/lib/AST/DeclCXX.cpp
===
--- clang/lib/AST/DeclCXX.cpp
+++ clang/lib/AST/DeclCXX.cpp
@@ -1378,7 +1378,11 @@
 }
 
 void CXXRecordDecl::addedEligibleSpecialMemberFunction(const CXXMethodDecl *MD,
-   unsigned SMKind) {
+   unsigned SMKind) {
+  // FIXME: We shouldn't change DeclaredNonTrivialSpecialMembers if `MD` is
+  // a function template, but this needs CWG attention before we break ABI.
+  // See https://github.com/llvm/llvm-project/issues/59206
+
   if (const auto *DD = dyn_cast(MD)) {
 if (DD->isUserProvided())
   data().HasIrrelevantDestructor = false;


Index: clang/test/SemaCXX/constrained-special-member-functions.cpp
===
--- clang/test/SemaCXX/constrained-special-member-functions.cpp
+++ clang/test/SemaCXX/constrained-special-member-functions.cpp
@@ -225,3 +225,43 @@
   S<2, 2> s2;
 }
 }
+
+namespace GH59206 {
+
+struct A {
+  A() = default; //eligible, second constructor unsatisfied
+  template
+  A(Args&&... args) requires (sizeof...(Args) > 0) {}
+};
+
+struct B {
+  B() = default; //ineligible, second constructor more constrained
+  template
+  B(Args&&... args) requires (sizeof...(Args) == 0) {}
+};
+
+struct C {
+  C() = default; //eligible, but
+  template //also eligible and non-trivial
+  C(Args&&... args) {}
+};
+
+struct D : B {};
+
+static_assert(__is_trivially_copyable(A), "");
+static_assert(__is_trivially_copyable(B), "");
+static_assert(__is_trivially_copyable(C), "");
+static_assert(__is_trivially_copyable(D), "");
+
+// FIXME: Update when https://github.com/llvm/llvm-project/issues/59206 is
+// resolved.
+static_assert(!__is_trivial(A), "");
+static_assert(!__is_trivial(B), "");
+static_assert(!__is_trivial(C), "");
+static_assert(__is_trivial(D), "");
+static_assert(__is_trivially_constructible(A), "");
+static_assert(__is_trivially_constructible(B), "");
+static_assert(__is_trivially_constructible(C), "");
+static_assert(__is_trivially_constructible(D), "");
+
+}
Index: clang/lib/Sema/SemaDecl.cpp

[PATCH] D138337: Add support for kcfi-seal optimization with LTO

2022-12-05 Thread Peter Collingbourne via Phabricator via cfe-commits
pcc added a comment.

Can't this be implicit if LTO is being used?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138337

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


[PATCH] D139360: [clang][dataflow] Support (in)equality operators in `optional` model.

2022-12-05 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel created this revision.
ymandel added reviewers: xazax.hun, sgatev.
Herald added subscribers: martong, rnkovacs.
Herald added a reviewer: NoQ.
Herald added a project: All.
ymandel requested review of this revision.
Herald added a project: clang.

This patch adds interpretation of the overloaded equality and inequality
operators available for the optional types.

Fixes issue #57253.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D139360

Files:
  clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
  clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp
@@ -762,6 +762,29 @@
 constexpr optional make_optional(std::initializer_list il,
 Args&&... args);
 
+template 
+constexpr bool operator==(const optional &lhs, const optional &rhs);
+template 
+constexpr bool operator!=(const optional &lhs, const optional &rhs);
+
+template 
+constexpr bool operator==(const optional &opt, nullopt_t);
+template 
+constexpr bool operator==(nullopt_t, const optional &opt);
+template 
+constexpr bool operator!=(const optional &opt, nullopt_t);
+template 
+constexpr bool operator!=(nullopt_t, const optional &opt);
+
+template 
+constexpr bool operator==(const optional &opt, const U &value);
+template 
+constexpr bool operator==(const T &value, const optional &opt);
+template 
+constexpr bool operator!=(const optional &opt, const U &value);
+template 
+constexpr bool operator!=(const T &value, const optional &opt);
+
 } // namespace std
 )";
 
@@ -984,6 +1007,29 @@
 constexpr optional make_optional(std::initializer_list il,
 Args&&... args);
 
+template 
+constexpr bool operator==(const optional &lhs, const optional &rhs);
+template 
+constexpr bool operator!=(const optional &lhs, const optional &rhs);
+
+template 
+constexpr bool operator==(const optional &opt, nullopt_t);
+template 
+constexpr bool operator==(nullopt_t, const optional &opt);
+template 
+constexpr bool operator!=(const optional &opt, nullopt_t);
+template 
+constexpr bool operator!=(nullopt_t, const optional &opt);
+
+template 
+constexpr bool operator==(const optional &opt, const U &value);
+template 
+constexpr bool operator==(const T &value, const optional &opt);
+template 
+constexpr bool operator!=(const optional &opt, const U &value);
+template 
+constexpr bool operator!=(const T &value, const optional &opt);
+
 } // namespace absl
 )";
 
@@ -1177,6 +1223,29 @@
 constexpr Optional make_optional(std::initializer_list il,
 Args&&... args);
 
+template 
+constexpr bool operator==(const Optional &lhs, const Optional &rhs);
+template 
+constexpr bool operator!=(const Optional &lhs, const Optional &rhs);
+
+template 
+constexpr bool operator==(const Optional &opt, nullopt_t);
+template 
+constexpr bool operator==(nullopt_t, const Optional &opt);
+template 
+constexpr bool operator!=(const Optional &opt, nullopt_t);
+template 
+constexpr bool operator!=(nullopt_t, const Optional &opt);
+
+template 
+constexpr bool operator==(const Optional &opt, const U &value);
+template 
+constexpr bool operator==(const T &value, const Optional &opt);
+template 
+constexpr bool operator!=(const Optional &opt, const U &value);
+template 
+constexpr bool operator!=(const T &value, const Optional &opt);
+
 } // namespace base
 )";
 
@@ -2117,6 +2186,325 @@
   )");
 }
 
+
+TEST_P(UncheckedOptionalAccessTest, EqualityCheckLeftSet) {
+  ExpectDiagnosticsFor(
+  R"(
+#include "unchecked_optional_access_test.h"
+
+void target() {
+  $ns::$optional opt1 = 3;
+  $ns::$optional opt2 = Make<$ns::$optional>();
+
+  if (opt1 == opt2) {
+opt2.value();
+  } else {
+opt2.value(); // [[unsafe]]
+  }
+}
+  )");
+}
+
+TEST_P(UncheckedOptionalAccessTest, EqualityCheckRightSet) {
+  ExpectDiagnosticsFor(
+  R"(
+#include "unchecked_optional_access_test.h"
+
+void target() {
+  $ns::$optional opt1 = 3;
+  $ns::$optional opt2 = Make<$ns::$optional>();
+
+  if (opt2 == opt1) {
+opt2.value();
+  } else {
+opt2.value(); // [[unsafe]]
+  }
+}
+  )");
+}
+
+TEST_P(UncheckedOptionalAccessTest, EqualityCheckVerifySetAfterEq) {
+  ExpectDiagnosticsFor(
+  R"(
+#include "unchecked_optional_access_test.h"
+
+void target() {
+  $ns::$optional opt1 = Make<$ns::$optional>();
+  $ns::$optional opt2 = Make<$ns::$optional>();
+
+  if (opt1 == opt2) {
+if (opt1.has_value())
+  opt2.value();
+if (opt2.has_value())
+  opt1.value();
+  }
+}
+  )");
+}
+
+TEST_P(UncheckedOptional

[PATCH] D138511: [CodeGen][AArch64] Fix AArch64ABIInfo::EmitAAPCSVAArg crash with empty record type in variadic arg

2022-12-05 Thread John McCall via Phabricator via cfe-commits
rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.

Please don't ping every day.  We haven't lost track of your patch, we're just 
busy reviewing other things.

This seems reasonable to me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138511

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


[PATCH] D136176: Implement support for option 'fexcess-precision'.

2022-12-05 Thread Zahira Ammarguellat via Phabricator via cfe-commits
zahiraam updated this revision to Diff 480198.
zahiraam edited the summary of this revision.
Herald added subscribers: pcwang-thead, nlopes, abrachet, sstefan1, phosek, 
s.egerton, ormris, mstorsjo, simoncook, fedor.sergeev, aheejin, dschuff.
Herald added a reviewer: jdoerfert.
Herald added a reviewer: sscalpone.

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

https://reviews.llvm.org/D136176

Files:
  clang/docs/UsersManual.rst
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/FPOptions.def
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/LangOptions.h
  clang/include/clang/Basic/TargetInfo.h
  clang/include/clang/Driver/Options.td
  clang/lib/AST/Type.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGExprComplex.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/X86/fexcess-precision.c
  clang/test/Driver/clang_f_opts.c
  clang/test/Driver/fexcess-precision.c
  precision-12.5.patch

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


[PATCH] D137756: [z/OS][p][pg] Throw Error When Using -p or -pg on z/OS

2022-12-05 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

See `clang/lib/Driver/ToolChains/Clang.cpp:6191` `if (TC.SupportsProfiling()) 
{`. You can define `SupportsProfiling` as false for zos. It's a 
`-Wunused-command-line-argument` warning, not an error, but may be good enough. 
 `-p` has already been handled.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137756

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


[PATCH] D129531: [clang][C++20] P0960R3 and P1975R0: Allow initializing aggregates from a parenthesized list of values

2022-12-05 Thread Alan Zhao via Phabricator via cfe-commits
ayzhao updated this revision to Diff 480189.
ayzhao marked 2 inline comments as done.
ayzhao added a comment.

add missing EOF newline


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129531

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang-c/Index.h
  clang/include/clang/AST/ASTNodeTraverser.h
  clang/include/clang/AST/ComputeDependence.h
  clang/include/clang/AST/Decl.h
  clang/include/clang/AST/ExprCXX.h
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/StmtNodes.td
  clang/include/clang/Sema/Initialization.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/lib/AST/ComputeDependence.cpp
  clang/lib/AST/Expr.cpp
  clang/lib/AST/ExprCXX.cpp
  clang/lib/AST/ExprClassification.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/JSONNodeDumper.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/AST/StmtProfile.cpp
  clang/lib/AST/TextNodeDumper.cpp
  clang/lib/CodeGen/CGExprAgg.cpp
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExceptionSpec.cpp
  clang/lib/Sema/SemaInit.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReaderStmt.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/lib/Serialization/ASTWriterStmt.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
  clang/test/CXX/class/class.compare/class.spaceship/p1.cpp
  clang/test/CXX/drs/dr2xx.cpp
  clang/test/CXX/temp/temp.decls/temp.variadic/p4.cpp
  clang/test/CodeGen/paren-list-agg-init.cpp
  clang/test/Lexer/cxx-features.cpp
  clang/test/PCH/cxx_paren_init.cpp
  clang/test/PCH/cxx_paren_init.h
  clang/test/SemaCXX/cxx2a-explicit-bool.cpp
  clang/test/SemaCXX/paren-list-agg-init.cpp
  clang/tools/libclang/CIndex.cpp
  clang/tools/libclang/CXCursor.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -1156,7 +1156,7 @@
 
   Parenthesized initialization of aggregates
   https://wg21.link/p0960r3";>P0960R3
-  No
+  Clang 16
 

 https://wg21.link/p1975r0";>P1975R0
Index: clang/tools/libclang/CXCursor.cpp
===
--- clang/tools/libclang/CXCursor.cpp
+++ clang/tools/libclang/CXCursor.cpp
@@ -643,6 +643,10 @@
 K = CXCursor_RequiresExpr;
 break;
 
+  case Stmt::CXXParenListInitExprClass:
+K = CXCursor_CXXParenListInitExpr;
+break;
+
   case Stmt::MSDependentExistsStmtClass:
 K = CXCursor_UnexposedStmt;
 break;
Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -2139,6 +2139,7 @@
   void VisitLambdaExpr(const LambdaExpr *E);
   void VisitConceptSpecializationExpr(const ConceptSpecializationExpr *E);
   void VisitRequiresExpr(const RequiresExpr *E);
+  void VisitCXXParenListInitExpr(const CXXParenListInitExpr *E);
   void VisitOMPExecutableDirective(const OMPExecutableDirective *D);
   void VisitOMPLoopBasedDirective(const OMPLoopBasedDirective *D);
   void VisitOMPLoopDirective(const OMPLoopDirective *D);
@@ -3006,6 +3007,9 @@
   for (ParmVarDecl *VD : E->getLocalParameters())
 AddDecl(VD);
 }
+void EnqueueVisitor::VisitCXXParenListInitExpr(const CXXParenListInitExpr *E) {
+  EnqueueChildren(E);
+}
 void EnqueueVisitor::VisitPseudoObjectExpr(const PseudoObjectExpr *E) {
   // Treat the expression like its syntactic form.
   Visit(E->getSyntacticForm());
@@ -5587,6 +5591,8 @@
 return cxstring::createRef("ConceptSpecializationExpr");
   case CXCursor_RequiresExpr:
 return cxstring::createRef("RequiresExpr");
+  case CXCursor_CXXParenListInitExpr:
+return cxstring::createRef("CXXParenListInitExpr");
   case CXCursor_UnexposedStmt:
 return cxstring::createRef("UnexposedStmt");
   case CXCursor_DeclStmt:
Index: clang/test/SemaCXX/paren-list-agg-init.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/paren-list-agg-init.cpp
@@ -0,0 +1,172 @@
+// RUN: %clang_cc1 -verify -std=c++20 %s -fsyntax-only
+// RUN: %clang_cc1 -verify=expected,beforecxx20 -Wc++20-extensions -std=c++20 %s -fsyntax-only
+
+struct A { // expected-note 4{{candidate constructor}}
+  char i;
+  double j;
+};
+
+struct B {
+  A a;
+  int b[20];
+  int &&c; // expected-note {{reference member declared here}}
+};
+
+struct C { // expected-note 2{{candidate constructor}}
+  A a;
+  int b[20];
+};
+
+struct D : public C, public A {
+  int a;
+};
+
+struct E { // expected-note 3{{candidate constructor}}
+  struct F {
+F(int, int);
+  };
+  int a;
+  F f;
+};
+
+int getint(); // expected-note {{declared here}}
+
+struct F {
+  int a;
+  int b = getint(); // expec

[PATCH] D129531: [clang][C++20] P0960R3 and P1975R0: Allow initializing aggregates from a parenthesized list of values

2022-12-05 Thread Alan Zhao via Phabricator via cfe-commits
ayzhao added inline comments.



Comment at: clang/lib/CodeGen/CGExprAgg.cpp:581
+  Expr *filler = nullptr;
+  if (auto *ILE = dyn_cast(ExprToVisit))
+filler = ILE->getArrayFiller();

ayzhao wrote:
> ilya-biryukov wrote:
> > ilya-biryukov wrote:
> > > ayzhao wrote:
> > > > ilya-biryukov wrote:
> > > > > - Should we have a filler for `CXXParenInitListExpr` too?
> > > > >   It seems like an important optimization and could have large effect 
> > > > > on compile times if we don't 
> > > > > 
> > > > > - Same question for semantic and syntactic-form (similar to 
> > > > > `InitListExpr`): should we have it here?
> > > > >   I am not sure if it's semantically required (probably not?), but 
> > > > > that's definitely something that `clang-tidy` and other source tools 
> > > > > will rely on.
> > > > > 
> > > > > We should probably share the code there, I suggest moving it to a 
> > > > > shared base class and using it where appropriate instead of the 
> > > > > derived classes.
> > > > > Should we have a filler for CXXParenInitListExpr too? It seems like 
> > > > > an important optimization and could have large effect on compile 
> > > > > times if we don't
> > > > 
> > > > This feels like premature optimization - presumably, wouldn't this only 
> > > > be an issue with extraordinarily large (say, O(1000)) arrays?
> > > > 
> > > > > Same question for semantic and syntactic-form (similar to 
> > > > > InitListExpr): should we have it here? I am not sure if it's 
> > > > > semantically required (probably not?), but that's definitely 
> > > > > something that clang-tidy and other source tools will rely on
> > > > 
> > > > IIRC this doesn't apply to paren list aggregate expressions, as the 
> > > > syntatic form would be the enclosing `ParenListExpr`.
> > > > This feels like premature optimization - presumably, wouldn't this only 
> > > > be an issue with extraordinarily large (say, O(1000)) arrays?
> > > Yes, this should only happen with large arrays. Normally I would agree, 
> > > but it's surprising that changing `{}` to `()` in the compiler would lead 
> > > to performance degradation.
> > > In that sense, this premature optimization is already implemented, we are 
> > > rather degrading performance for a different syntax to do the same thing.
> > > 
> > > Although we could also land without it, but in that case could you open a 
> > > GH issue and add a FIXME to track the implementation of this particular 
> > > optimization?
> > > This should increase the chances of users finding the root cause of the 
> > > issue if they happen to hit it.
> > > 
> > > > IIRC this doesn't apply to paren list aggregate expressions, as the 
> > > > syntatic form would be the enclosing ParenListExpr.
> > > Do we even have the enclosing `ParenListExpr`? If I dump the AST with 
> > > `clang -fsyntax-only -Xclang=-ast-dump ...`  for the following code:
> > > ```
> > > struct pair { int a; int b = 2; };
> > > int main() {
> > >   pair(1); pair p(1);
> > >   pair b{1}; pair{1};
> > > }
> > > ```
> > > 
> > > I get 
> > > ```
> > > `-FunctionDecl 0x557d79717e98  line:2:5 main 'int ()'
> > >   `-CompoundStmt 0x557d797369d0 
> > > |-CXXFunctionalCastExpr 0x557d79718528  
> > > 'pair':'pair' functional cast to pair 
> > > | `-CXXParenListInitExpr 0x557d79718500  'pair':'pair'
> > > |   |-IntegerLiteral 0x557d79718010  'int' 1
> > > |   `-IntegerLiteral 0x557d79717e18  'int' 2
> > > |-DeclStmt 0x557d79718650 
> > > | `-VarDecl 0x557d79718568  col:17 p 'pair':'pair' 
> > > parenlistinit
> > > |   `-CXXParenListInitExpr 0x557d79718610  'pair':'pair'
> > > | |-IntegerLiteral 0x557d797185d0  'int' 1
> > > | `-IntegerLiteral 0x557d79717e18  'int' 2
> > > |-DeclStmt 0x557d797187d8 
> > > | `-VarDecl 0x557d79718680  col:8 b 'pair':'pair' 
> > > listinit
> > > |   `-InitListExpr 0x557d79718750  'pair':'pair'
> > > | |-IntegerLiteral 0x557d797186e8  'int' 1
> > > | `-CXXDefaultInitExpr 0x557d797187a0  'int'
> > > `-CXXFunctionalCastExpr 0x557d797369a8  'pair':'pair' 
> > > functional cast to pair 
> > >   `-InitListExpr 0x557d79718868  'pair':'pair'
> > > |-IntegerLiteral 0x557d79718800  'int' 1
> > > `-CXXDefaultInitExpr 0x557d797188b8  'int'
> > > ```
> > > It feels like the `ParentListExpr` is replaced during semantic analysis 
> > > and there is no way to get it back. I also tried running `clang-query` 
> > > and trying to `match parenListExpr()` and go 0 results. Is it just 
> > > missing in the AST dump and I run `clang-query` incorrectly or do we 
> > > actually not have the syntactic form of this expression after all?
> > Another important thing to address from the dump: notice how braced 
> > initialization creates `CXXDefaultInitExpr` and `CXXParenListInitExpr` 
> > copies the default argument expression directly. It's really important to 
> > use the former form, here's the example that currently breaks:
>

[PATCH] D139261: [Clang] Modify sanity check assert in AggExprEmitter::VisitInitListExpr to cover anonymous struct in a union GNU extension

2022-12-05 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 with a formatting nit fixed, but you should add a release note for the fix 
when landing.




Comment at: clang/lib/CodeGen/CGExprAgg.cpp:1688
   for (const auto *Field : record->fields())
-assert(Field->isUnnamedBitfield() && "Only unnamed bitfields allowed");
+assert((Field->isUnnamedBitfield() || 
Field->isAnonymousStructOrUnion()) && "Only unnamed bitfields or ananymous 
class allowed");
 #endif

Guessing at the way to solve the 80-col limit issue, but do whatever 
clang-format says.


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

https://reviews.llvm.org/D139261

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


[PATCH] D138958: [clang] Better UX for Clang’s unwind-affecting attributes

2022-12-05 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

(ping, maybe)

In D138958#3968118 , @lebedev.ri 
wrote:

> I've been thinking, and it seems to me that explicitly opting into
> `__attribute__((nounwind))`-provided semantics should override
> the `__attribute__((nothrow))`/`noexcept` semantics.
> So looks like i should look into exception specification handling.

I've looked, and unless told otherwise, it seems like we
shouldn't add new exception specification for this attribute,
but special-case the attribute where it matters,
but i may be wrong.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138958

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


[PATCH] D129531: [clang][C++20] P0960R3 and P1975R0: Allow initializing aggregates from a parenthesized list of values

2022-12-05 Thread Alan Zhao via Phabricator via cfe-commits
ayzhao updated this revision to Diff 480184.
ayzhao added a comment.

use NumUserSpecifiedExprs instead of syntatic/semantic forms, also address some 
comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129531

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang-c/Index.h
  clang/include/clang/AST/ASTNodeTraverser.h
  clang/include/clang/AST/ComputeDependence.h
  clang/include/clang/AST/Decl.h
  clang/include/clang/AST/ExprCXX.h
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/StmtNodes.td
  clang/include/clang/Sema/Initialization.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/lib/AST/ComputeDependence.cpp
  clang/lib/AST/Expr.cpp
  clang/lib/AST/ExprCXX.cpp
  clang/lib/AST/ExprClassification.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/JSONNodeDumper.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/AST/StmtProfile.cpp
  clang/lib/AST/TextNodeDumper.cpp
  clang/lib/CodeGen/CGExprAgg.cpp
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExceptionSpec.cpp
  clang/lib/Sema/SemaInit.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReaderStmt.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/lib/Serialization/ASTWriterStmt.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
  clang/test/CXX/class/class.compare/class.spaceship/p1.cpp
  clang/test/CXX/drs/dr2xx.cpp
  clang/test/CXX/temp/temp.decls/temp.variadic/p4.cpp
  clang/test/CodeGen/paren-list-agg-init.cpp
  clang/test/Lexer/cxx-features.cpp
  clang/test/PCH/cxx_paren_init.cpp
  clang/test/PCH/cxx_paren_init.h
  clang/test/SemaCXX/cxx2a-explicit-bool.cpp
  clang/test/SemaCXX/paren-list-agg-init.cpp
  clang/tools/libclang/CIndex.cpp
  clang/tools/libclang/CXCursor.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -1156,7 +1156,7 @@
 
   Parenthesized initialization of aggregates
   https://wg21.link/p0960r3";>P0960R3
-  No
+  Clang 16
 

 https://wg21.link/p1975r0";>P1975R0
Index: clang/tools/libclang/CXCursor.cpp
===
--- clang/tools/libclang/CXCursor.cpp
+++ clang/tools/libclang/CXCursor.cpp
@@ -643,6 +643,10 @@
 K = CXCursor_RequiresExpr;
 break;
 
+  case Stmt::CXXParenListInitExprClass:
+K = CXCursor_CXXParenListInitExpr;
+break;
+
   case Stmt::MSDependentExistsStmtClass:
 K = CXCursor_UnexposedStmt;
 break;
Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -2139,6 +2139,7 @@
   void VisitLambdaExpr(const LambdaExpr *E);
   void VisitConceptSpecializationExpr(const ConceptSpecializationExpr *E);
   void VisitRequiresExpr(const RequiresExpr *E);
+  void VisitCXXParenListInitExpr(const CXXParenListInitExpr *E);
   void VisitOMPExecutableDirective(const OMPExecutableDirective *D);
   void VisitOMPLoopBasedDirective(const OMPLoopBasedDirective *D);
   void VisitOMPLoopDirective(const OMPLoopDirective *D);
@@ -3006,6 +3007,9 @@
   for (ParmVarDecl *VD : E->getLocalParameters())
 AddDecl(VD);
 }
+void EnqueueVisitor::VisitCXXParenListInitExpr(const CXXParenListInitExpr *E) {
+  EnqueueChildren(E);
+}
 void EnqueueVisitor::VisitPseudoObjectExpr(const PseudoObjectExpr *E) {
   // Treat the expression like its syntactic form.
   Visit(E->getSyntacticForm());
@@ -5587,6 +5591,8 @@
 return cxstring::createRef("ConceptSpecializationExpr");
   case CXCursor_RequiresExpr:
 return cxstring::createRef("RequiresExpr");
+  case CXCursor_CXXParenListInitExpr:
+return cxstring::createRef("CXXParenListInitExpr");
   case CXCursor_UnexposedStmt:
 return cxstring::createRef("UnexposedStmt");
   case CXCursor_DeclStmt:
Index: clang/test/SemaCXX/paren-list-agg-init.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/paren-list-agg-init.cpp
@@ -0,0 +1,172 @@
+// RUN: %clang_cc1 -verify -std=c++20 %s -fsyntax-only
+// RUN: %clang_cc1 -verify=expected,beforecxx20 -Wc++20-extensions -std=c++20 %s -fsyntax-only
+
+struct A { // expected-note 4{{candidate constructor}}
+  char i;
+  double j;
+};
+
+struct B {
+  A a;
+  int b[20];
+  int &&c; // expected-note {{reference member declared here}}
+};
+
+struct C { // expected-note 2{{candidate constructor}}
+  A a;
+  int b[20];
+};
+
+struct D : public C, public A {
+  int a;
+};
+
+struct E { // expected-note 3{{candidate constructor}}
+  struct F {
+F(int, int);
+  };
+  int a;
+  F f;
+};
+
+int getint(); // expected-note {{declared here}}
+
+struct F {
+  int a;
+  i

[PATCH] D129531: [clang][C++20] P0960R3 and P1975R0: Allow initializing aggregates from a parenthesized list of values

2022-12-05 Thread Alan Zhao via Phabricator via cfe-commits
ayzhao marked 4 inline comments as done.
ayzhao added a comment.

In D129531#3971392 , @ilya-biryukov 
wrote:

> Thanks!
>
> I have two major comments and also inline NITs. Not sure if we should block 
> on those, just wanted to hear your opinions:
>
> - `InitListExpr` and `CXXParenInitListExpr` have some code in common. Code 
> duplication is substantial and I think sharing the common implementation is 
> warranted. E.g. if some code would want to change something with 
> `ArrayFiller` or make a use of it, the work will probably need to be 
> duplicated. To reiterate what I mentioned earlier, I believe deriving 
> `CXXParenInitListExpr` from `InitListExpr` is not a very good option, but we 
> might explore other possibilities: a base class or factoring out common code 
> in a separate struct. I believe this could be done with a follow-up change, 
> though, as the amount of changes required does not seem too big, I would be 
> happy with first landing this patch and then cleaning up with a follow-up 
> change.
> - Did we explore the possibility of modelling this differently and somehow 
> avoiding making `CXXParenInitListExpr` an expression. This seems to borrow 
> from `InitListExpr`, but maybe for the wrong reasons.  Braced initializers 
> can actually occur in expressions positions, e.g. `int a = {123}`. However, 
> `CXXParenInistListExpr` cannot occur in expression positions outside 
> initializations, e.g. having `CXXFunctionalCastExpr` for 
> `aggregate_struct(123)` feels somewhat wrong to me and seems to lead to 
> confusing error messages too. Maybe we should model it as a new expression 
> that contains both the type and the argument list? I.e. more similar to 
> `CXXConstructExpr`?

As discussed offline, let's keep the current implementation as is for now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129531

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


[PATCH] D137020: [clang][AST] Handle variable declaration with unknown typedef in C

2022-12-05 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/lib/Parse/ParseStmt.cpp:177-178
+  case tok::kw___attribute:
+  case tok::kw_const:
+  case tok::kw_volatile:
+  case tok::star:

urazoff wrote:
> aaron.ballman wrote:
> > What about other qualifiers? `_Nullable` and `restrict` and whatnot?
> I think `restrict` can not go just after type name.
It can when you consider typedefs, as in: https://godbolt.org/z/hjK9f3xEc


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

https://reviews.llvm.org/D137020

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


[PATCH] D137381: [clang][compiler-rt] Exception escape out of an non-unwinding function is an undefined behaviour

2022-12-05 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri marked 2 inline comments as done.
lebedev.ri added inline comments.



Comment at: clang/test/CodeGen/windows-seh-EHa-CppCondiTemps.cpp:3
 
+// FIXME: this check appears to be miscompiled?
+// XFAIL: *

efriedma wrote:
> lebedev.ri wrote:
> > tentzen wrote:
> > > lebedev.ri wrote:
> > > > This test broke once we always started adding (outermost) UB scope for 
> > > > nounwind functions.
> > > > I don't quite get what is going wrong. It could be a bug in SEH 
> > > > handling.
> > > > Can someone who has some idea about that code take a look and suggest a 
> > > > fix?
> > > > @tentzen ?
> > > By definition, non-unwind function I think is for Synchronous EH. So this 
> > > Sanitizer check should exclude Asynchronous EH functions, those with 
> > > option -fasync-exceptions.
> > >  
> > I do not understand.
> > If the function can unwind, then why is it marked `nounwind`?
> > This kind of thing is exactly what i was afraid of with those SEH patches.
> clang should not be marking functions "nounwind" in -fasync-exceptions mode; 
> if it is, I'd consider that a bug.  (I assume someone just forgot to add a 
> check to some code that adds nounwind.)
My thoughts precisely. @tentzen please fix :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137381

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


[PATCH] D139326: [clang] Add test for CWG952

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

LGTM, though I would appreciate another test (that I expect to pass).




Comment at: clang/test/CXX/drs/dr9xx.cpp:76
+namespace dr952 { // dr952: yes
+struct A {
+  typedef int I; // #dr952-typedef-decl

I wouldn't mind another test case:
```
struct A {
protected:
  static int x;
};
struct B : A {
  friend int get(B) { return x; }
};
```
this was something Richard had pointed out needs to still work as part of the 
reflector discussions of this issue.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139326

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


[PATCH] D139172: [clang] Mark CWG554 as N/A

2022-12-05 Thread Shafik Yaghmour via Phabricator via cfe-commits
shafik accepted this revision.
shafik added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139172

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


[PATCH] D139343: [Driver][PPC] Support -mtune=auto

2022-12-05 Thread Qiongsi Wu via Phabricator via cfe-commits
qiongsiwu1 abandoned this revision.
qiongsiwu1 added a comment.

It is decided that we no longer need this patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139343

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


[PATCH] D105584: [MLIR][OpenMP] Distribute Construct Operation

2022-12-05 Thread Abid via Phabricator via cfe-commits
abidmalikwaterloo updated this revision to Diff 480159.
abidmalikwaterloo marked 3 inline comments as done.
abidmalikwaterloo added a comment.

Update the patch based on the feedback and comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105584

Files:
  mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td
  mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
  mlir/test/Dialect/OpenMP/ops.mlir

Index: mlir/test/Dialect/OpenMP/ops.mlir
===
--- mlir/test/Dialect/OpenMP/ops.mlir
+++ mlir/test/Dialect/OpenMP/ops.mlir
@@ -133,6 +133,18 @@
   return
 }
 
+// CHECK-LABEL: omp_DistributeOp
+func.func @omp_DistributeOp(%lb : index, %ub : index, %step : index, %data_var : memref, %chunk_var : i32) -> () {
+// CHECK: for (%{{.*}}) : index = (%{{.*}}) to (%{{.*}}) step (%{{.*}})
+  "omp.distribute" (%lb, %ub, %step) ({
+^bb0(%iv: index):
+ omp.yield 
+  }) {operand_segment_sizes = array} :
+(index, index, index) -> ()
+ 
+ return
+ }
+
 // CHECK-LABEL: omp_wsloop
 func.func @omp_wsloop(%lb : index, %ub : index, %step : index, %data_var : memref, %linear_var : i32, %chunk_var : i32) -> () {
 
Index: mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
===
--- mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
+++ mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
@@ -281,6 +281,20 @@
   return success();
 }
 
+//===-===//
+// Verifier for Dristribute Op
+//===-===//
+
+LogicalResult DistributeOp::verify(){
+  if (this->getLowerBound().empty()) 
+return emitOpError() << "empty lowerbound for distribute loop operation";
+  
+  if (this->getUpperBound().empty()) 
+return emitOpError() << "empty upperbound for distribute loop operation";
+  
+  return success();	
+}
+
 /// schedule ::= `schedule` `(` sched-list `)`
 /// sched-list ::= sched-val | sched-val sched-list |
 ///sched-val `,` sched-modifier
@@ -590,7 +604,7 @@
 }
 
 //===--===//
-// WsLoopOp
+// LoopControl
 //===--===//
 
 /// loop-control ::= `(` ssa-id-list `)` `:` type `=`  loop-bounds
Index: mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td
===
--- mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td
+++ mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td
@@ -452,7 +452,7 @@
 def YieldOp : OpenMP_Op<"yield",
 [Pure, ReturnLike, Terminator,
  ParentOneOf<["WsLoopOp", "ReductionDeclareOp",
- "AtomicUpdateOp", "SimdLoopOp"]>]> {
+ "AtomicUpdateOp", "SimdLoopOp","DistributeOp"]>]> {
   let summary = "loop yield and termination operation";
   let description = [{
 "omp.yield" yields SSA values from the OpenMP dialect op region and
@@ -469,6 +469,65 @@
   let assemblyFormat = [{ ( `(` $results^ `:` type($results) `)` )? attr-dict}];
 }
 
+//===--===//
+// 2.9.4.1 distribute Construct
+//===--===//
+
+def DistributeOp : OpenMP_Op<"distribute", [AttrSizedOperandSegments,
+AllTypesMatch<["lowerBound", "upperBound", "step"]>]> {
+  let summary = "distribute loop construct";
+  let description = [{ 
+The distribute construct specifies that the iterations of one or more loop
+will be executed by the initial teams in the context of their implicit 
+tasks. The iterations are distributed across the initial threads of all 
+initial teams that execute the teams region to which the distribute region 
+binds.
+
+The distribute loop construct specifies that the iterations of the loop(s)
+will be executed in parallel by threads in the current context. These
+iterations are spread across threads that already exist in the enclosing
+region. The lower and upper bounds specify a half-open range: the
+range includes the lower bound but does not include the upper bound. If the
+`inclusive` attribute is specified then the upper bound is also included.
+
+// TODO: 	private_var, firstprivate_var and lastprivate_var variables 
+// will be defined later
+
+The `static_dist_schedule` attribute specifies the  schedule for this
+loop, determining how the loop is distributed across the parallel threads.
+The optional `schedule_chunk` associated with this determines further
+controls this distribution.
+
+// TODO: collapse
+  }];
+
+  let arguments = (ins Variadic:$lowerBound,
+ Variadic:$upperBound,
+ Variadic:$step,
+ UnitAttr:$static_dist_schedule,
+ Optional:

[PATCH] D137381: [clang][compiler-rt] Exception escape out of an non-unwinding function is an undefined behaviour

2022-12-05 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added inline comments.



Comment at: clang/test/CodeGen/windows-seh-EHa-CppCondiTemps.cpp:3
 
+// FIXME: this check appears to be miscompiled?
+// XFAIL: *

lebedev.ri wrote:
> tentzen wrote:
> > lebedev.ri wrote:
> > > This test broke once we always started adding (outermost) UB scope for 
> > > nounwind functions.
> > > I don't quite get what is going wrong. It could be a bug in SEH handling.
> > > Can someone who has some idea about that code take a look and suggest a 
> > > fix?
> > > @tentzen ?
> > By definition, non-unwind function I think is for Synchronous EH. So this 
> > Sanitizer check should exclude Asynchronous EH functions, those with option 
> > -fasync-exceptions.
> >  
> I do not understand.
> If the function can unwind, then why is it marked `nounwind`?
> This kind of thing is exactly what i was afraid of with those SEH patches.
clang should not be marking functions "nounwind" in -fasync-exceptions mode; if 
it is, I'd consider that a bug.  (I assume someone just forgot to add a check 
to some code that adds nounwind.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137381

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


[PATCH] D139343: [Driver][PPC] Support -mtune=auto

2022-12-05 Thread Qiongsi Wu via Phabricator via cfe-commits
qiongsiwu1 created this revision.
qiongsiwu1 added reviewers: w2yehia, nemanjai, MaskRay.
qiongsiwu1 added projects: clang, PowerPC.
Herald added subscribers: StephenFan, shchenz, kbarton.
Herald added a project: All.
qiongsiwu1 requested review of this revision.
Herald added a subscriber: cfe-commits.

This patch teaches `clang` to recognize the `auto` option for `-mtune`. The 
option is identical to the `mtune` option `native`.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D139343

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/ppc-cpus.c


Index: clang/test/Driver/ppc-cpus.c
===
--- clang/test/Driver/ppc-cpus.c
+++ clang/test/Driver/ppc-cpus.c
@@ -22,3 +22,5 @@
 
 // RUN: %clang -### -c --target=powerpc64 %s -mcpu=generic -mtune=pwr9 2>&1 | 
FileCheck %s --check-prefix=TUNE
 // TUNE: "-target-cpu" "ppc64" "-tune-cpu" "pwr9"
+// RUN: %clang -### -c --target=powerpc64 %s -mcpu=generic -mtune=auto 2>&1 | 
FileCheck %s --check-prefix=NO_AUTO
+// NO_AUTO-NOT: "-target-cpu" "ppc64" "-tune-cpu" "auto"
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -1990,7 +1990,8 @@
  ArgStringList &CmdArgs) const {
   if (const Arg *A = Args.getLastArg(options::OPT_mtune_EQ)) {
 CmdArgs.push_back("-tune-cpu");
-if (strcmp(A->getValue(), "native") == 0)
+if (strcmp(A->getValue(), "native") == 0 ||
+strcmp(A->getValue(), "auto") == 0)
   CmdArgs.push_back(Args.MakeArgString(llvm::sys::getHostCPUName()));
 else
   CmdArgs.push_back(A->getValue());


Index: clang/test/Driver/ppc-cpus.c
===
--- clang/test/Driver/ppc-cpus.c
+++ clang/test/Driver/ppc-cpus.c
@@ -22,3 +22,5 @@
 
 // RUN: %clang -### -c --target=powerpc64 %s -mcpu=generic -mtune=pwr9 2>&1 | FileCheck %s --check-prefix=TUNE
 // TUNE: "-target-cpu" "ppc64" "-tune-cpu" "pwr9"
+// RUN: %clang -### -c --target=powerpc64 %s -mcpu=generic -mtune=auto 2>&1 | FileCheck %s --check-prefix=NO_AUTO
+// NO_AUTO-NOT: "-target-cpu" "ppc64" "-tune-cpu" "auto"
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -1990,7 +1990,8 @@
  ArgStringList &CmdArgs) const {
   if (const Arg *A = Args.getLastArg(options::OPT_mtune_EQ)) {
 CmdArgs.push_back("-tune-cpu");
-if (strcmp(A->getValue(), "native") == 0)
+if (strcmp(A->getValue(), "native") == 0 ||
+strcmp(A->getValue(), "auto") == 0)
   CmdArgs.push_back(Args.MakeArgString(llvm::sys::getHostCPUName()));
 else
   CmdArgs.push_back(A->getValue());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D129531: [clang][C++20] P0960R3 and P1975R0: Allow initializing aggregates from a parenthesized list of values

2022-12-05 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov added a comment.

Thanks!

I have two major comments and also inline NITs. Not sure if we should block on 
those, just wanted to hear your opinions:

- `InitListExpr` and `CXXParenInitListExpr` have some code in common. Code 
duplication is substantial and I think sharing the common implementation is 
warranted. E.g. if some code would want to change something with `ArrayFiller` 
or make a use of it, the work will probably need to be duplicated. To reiterate 
what I mentioned earlier, I believe deriving `CXXParenInitListExpr` from 
`InitListExpr` is not a very good option, but we might explore other 
possibilities: a base class or factoring out common code in a separate struct. 
I believe this could be done with a follow-up change, though, as the amount of 
changes required does not seem too big, I would be happy with first landing 
this patch and then cleaning up with a follow-up change.
- Did we explore the possibility of modelling this differently and somehow 
avoiding making `CXXParenInitListExpr` an expression. This seems to borrow from 
`InitListExpr`, but maybe for the wrong reasons.  Braced initializers can 
actually occur in expressions positions, e.g. `int a = {123}`. However, 
`CXXParenInistListExpr` cannot occur in expression positions outside 
initializations, e.g. having `CXXFunctionalCastExpr` for 
`aggregate_struct(123)` feels somewhat wrong to me and seems to lead to 
confusing error messages too. Maybe we should model it as a new expression that 
contains both the type and the argument list? I.e. more similar to 
`CXXConstructExpr`?




Comment at: clang/lib/Sema/SemaInit.cpp:5455
+  // All of the initialized entities are explicitly initialized by
+  // expressionse in the CXXParenListInitExpr. The semantic form is the
+  // same as the syntatic form

NIT: s/expressionse/expressions



Comment at: clang/lib/Sema/SemaInit.cpp:9803
+TryOrBuildParenListInitialization(S, Entity, Kind, Args, *this,
+  /*VerifyOnly=*/false);
   }

NIT: add break 



Comment at: clang/lib/Sema/TreeTransform.h:14040
+  ArrayRef InitExprs = E->getInitExprs();
+  if (TransformExprs(reinterpret_cast(InitExprs.data()),
+ InitExprs.size(), true, TransformedInits))

`reinterpret_cast` seems redundant here or am I missing something?



Comment at: clang/lib/Serialization/ASTReaderStmt.cpp:2172
+  VisitExpr(E);
+  unsigned expectedNumExprs = Record.readInt();
+  assert(E->NumExprs == expectedNumExprs &&

NIT: `ExpectedNumExprs`




Comment at: clang/lib/Serialization/ASTReaderStmt.cpp:2181
+E->getTrailingObjects()[I] = Record.readSubExpr();
+  E->updateDependence();
+

NIT: maybe add a comment that dependence does not depend on filler or syntactic 
form. This might be non-obvious for someone who did not look into the 
implementation.

Alternatively, you could run this at the end of this function, it should not be 
confusing to anyone that certain properties get computed *after* the expression 
was fully deserialized. 



Comment at: clang/test/CXX/class/class.compare/class.spaceship/p1.cpp:106
   Cmp() <=> Cmp(), // expected-note-re {{in defaulted three-way 
comparison operator for '{{.*}}Cmp<{{.*}}G2>' first required here}}j
-  // expected-error@#cmp {{no matching conversion for static_cast from 
'void' to 'std::strong_ordering'}}
+  // expected-error@#cmp {{static_cast from 'void' to 
'std::strong_ordering' is not allowed}}
   Cmp() <=> Cmp(), // expected-note-re {{in defaulted three-way 
comparison operator for '{{.*}}Cmp<{{.*}}H>' first required here}}j

Do you have any idea why did this diagnostic change?



Comment at: clang/test/CXX/drs/dr2xx.cpp:161
+void test6(A::S as) { struct f {}; (void) f(as); } // pre20-error {{no 
matching conversion}} pre20-note +{{}}
+// post20-error@-1 {{functional-style cast from 'A::S' to 'f' is not 
allowed}}
   };

This might be related to other diagnostic change.
Why do we see the new behavior here? Do you think we should keep the old 
behavior maybe? 
I feel that both errors are communicating the same thing and probably keeping 
the current state is acceptable, just want to better understand how we got 
there.

It definitely has something to do with the initialization code, but I struggle 
to understand what exactly changed



Comment at: clang/test/CXX/temp/temp.decls/temp.variadic/p4.cpp:131
+// pre20-error@-2 {{no matching constructor for initialization of 'B'}}
+// post20-error@-3 {{excess elements in struct initializer}}
+// post20-error@-4 {{excess elements in struct initializer}}

Given how pervasive this error is right now, I feel that we want to add a name 
of the struct to this message.
This case is also a g

[PATCH] D138511: [CodeGen][AArch64] Fix AArch64ABIInfo::EmitAAPCSVAArg crash with empty record type in variadic arg

2022-12-05 Thread Yurong via Phabricator via cfe-commits
yronglin added a comment.

pin~


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138511

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


  1   2   >