[PATCH] D111778: [WIP][X86] Update CPU_SPECIFIC list.

[Freddy, Ye via Phabricator via cfe-commits]

FreddyYe added a subscriber: RKSimon.
FreddyYe added a comment.

As mentioned before:

In D108422#2957528 , @RKSimon wrote:

> There's nothing later than CannonLake here - does Intel need to at least 
> reference up to Tiger/Rocketlake?

I met some issues to discuss with you.

1. The feature list now I added is got from the output of -march=XXX. This 
version should work right with many cpus added above. But some of them 
don't(Functional issue).  I dig a little and found it's caused beyond this 
table. And the issue already exists in the old CPU added before. For example,  
"core_i7_sse4_2" and "goldmont" only has one feature differs: which is "movbe", 
but "movebe" is not included in the table of __cpu_features in libgcc (The 
table is the same as the one in compiler-rt, which is `enum 
ProcessorFeatures`), so these two CPU_SPECIFIC won't be classified on run time.
2. Naming convention issue. `-march=goldmont-plus` v.s 
`cpu_specific(goldmont_plus)`. From my test, CPU_SPECIFIC probably needs other 
changes to support "goldmont-plus".
3. We probably need to document somewhere for all the supported CPU names on 
this function multiversioning.
4. CPU_SPECIFIC_ALIAS() issue. For now, CPUs defined by CPU_SPECIFIC_ALIAS is 
not allowed to used together with original CPU(e.g. 
`__attribute__((cpu_specific(sandybridge)))` and 
`__attribute__((cpu_specific(core_2nd_gen_avx)))`), which introduces compile 
error. Not sure if it is expected.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111778

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

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

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay requested changes to this revision.
MyDeveloperDay added a comment.
This revision now requires changes to proceed.

To me you should be doing

  /*bitcode SDL=*/true

It looks like its still failing clang-format might I suggest making the changes 
to the comment, git adding the file then doing

  git clang-format

This will clang-format your staged files.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111545

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

[PATCH] D84375: [git-clang-format] Add --diffstat parameter

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

@roligugus I can land this for you, please rebase the review then please add 
your name and email here so we can ensure you get the credit.

https://llvm.org/docs/DeveloperPolicy.html#commit-messages


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84375

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

[PATCH] D109825: [AArch64]Enabling Cortex-A510 Support

[Dave Green via Phabricator via cfe-commits]

dmgreen added a comment.

In D109825#3060796 , @mubashar_ wrote:

> Added crypto and non-crypto related tests for mcpu in aarch64-cpus.c

Thanks, but did this change miss being updated in the review?




Comment at: clang/docs/ReleaseNotes.rst:86
 
+- Support has been added for the following processors (command-line 
identifiers in parentheses):
+  - Arm Cortex-A510 (cortex-a510)

dmgreen wrote:
> Can you add an Arm section below and move this to it.
This still needs doing. Also please add a line to the arm section saying "Added 
support for the Armv9-A, Armv9.1-A and Armv9.2-A architectures."

It looks like there are some llvm release notes in llvm/docs/ReleaseNotes.rst 
too, that could have a line added.



Comment at: llvm/include/llvm/Support/AArch64TargetParser.def:149
+ (AArch64::AEK_BF16 | AArch64::AEK_I8MM | 
AArch64::AEK_SVE2BITPERM |
+  AArch64::AEK_PAUTH | AArch64::AEK_PAUTH | AArch64::AEK_MTE |
+  AArch64::AEK_SSBS | AArch64::AEK_SB | AArch64::AEK_FP16FML))

AEK_PAUTH is twice here.


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

https://reviews.llvm.org/D109825

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

[PATCH] D111698: [clangd] IncludeCleaner: Handle macros coming from ScratchBuffer

[Kirill Bobyrev via Phabricator via cfe-commits]

kbobyrev updated this revision to Diff 379625.
kbobyrev marked 2 inline comments as done.
kbobyrev added a comment.

Stash


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111698

Files:
  clang-tools-extra/clangd/IncludeCleaner.cpp
  clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp


Index: clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
===
--- clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
+++ clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
@@ -167,6 +167,38 @@
   UnorderedElementsAre("\"unused.h\"", "\"dir/unused.h\""));
 }
 
+TEST(IncludeCleaner, ScratchBuffer) {
+  TestTU TU;
+  TU.Filename = "foo.cpp";
+  TU.Code = R"cpp(
+#include "macro_spelling_in_scratch_buffer.h"
+
+using flags::FLAGS_FOO;
+)cpp";
+  // The pasting operator in combination with DEFINE_FLAG will create
+  // ScratchBuffer with `flags::FLAGS_FOO` that will have FileID but not
+  // FileEntry.
+  TU.AdditionalFiles["macro_spelling_in_scratch_buffer.h"] = R"cpp(
+#define DEFINE_FLAG(X) \
+namespace flags { \
+int FLAGS_##X; \
+} \
+
+DEFINE_FLAG(FOO)
+)cpp";
+  ParsedAST AST = TU.build();
+  auto &SM = AST.getSourceManager();
+  auto &Includes = AST.getIncludeStructure();
+  auto ReferencedFiles = translateToHeaderIDs(
+  findReferencedFiles(findReferencedLocations(AST), SM), Includes, SM);
+  auto Entry = SM.getFileManager().getFile(
+  testPath("macro_spelling_in_scratch_buffer.h"));
+  ASSERT_TRUE(Entry);
+  auto HeaderID = Includes.getID(*Entry);
+  EXPECT_THAT(ReferencedFiles, UnorderedElementsAre(HeaderID));
+  EXPECT_THAT(getUnused(Includes, ReferencedFiles), ::testing::IsEmpty());
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/IncludeCleaner.cpp
===
--- clang-tools-extra/clangd/IncludeCleaner.cpp
+++ clang-tools-extra/clangd/IncludeCleaner.cpp
@@ -121,7 +121,11 @@
 if (!Macros.insert(FID).second)
   return;
 const auto &Exp = SM.getSLocEntry(FID).getExpansion();
-add(Exp.getSpellingLoc());
+// For token pasting operator in macros, the spelling location can be
+// within a temporary buffer that Clang creates (scratch space or
+// ScratchBuffer). That is not a real file we can include.
+if (!SM.isWrittenInScratchSpace(Exp.getSpellingLoc()))
+  add(Exp.getSpellingLoc());
 add(Exp.getExpansionLocStart());
 add(Exp.getExpansionLocEnd());
   }


Index: clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
===
--- clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
+++ clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
@@ -167,6 +167,38 @@
   UnorderedElementsAre("\"unused.h\"", "\"dir/unused.h\""));
 }
 
+TEST(IncludeCleaner, ScratchBuffer) {
+  TestTU TU;
+  TU.Filename = "foo.cpp";
+  TU.Code = R"cpp(
+#include "macro_spelling_in_scratch_buffer.h"
+
+using flags::FLAGS_FOO;
+)cpp";
+  // The pasting operator in combination with DEFINE_FLAG will create
+  // ScratchBuffer with `flags::FLAGS_FOO` that will have FileID but not
+  // FileEntry.
+  TU.AdditionalFiles["macro_spelling_in_scratch_buffer.h"] = R"cpp(
+#define DEFINE_FLAG(X) \
+namespace flags { \
+int FLAGS_##X; \
+} \
+
+DEFINE_FLAG(FOO)
+)cpp";
+  ParsedAST AST = TU.build();
+  auto &SM = AST.getSourceManager();
+  auto &Includes = AST.getIncludeStructure();
+  auto ReferencedFiles = translateToHeaderIDs(
+  findReferencedFiles(findReferencedLocations(AST), SM), Includes, SM);
+  auto Entry = SM.getFileManager().getFile(
+  testPath("macro_spelling_in_scratch_buffer.h"));
+  ASSERT_TRUE(Entry);
+  auto HeaderID = Includes.getID(*Entry);
+  EXPECT_THAT(ReferencedFiles, UnorderedElementsAre(HeaderID));
+  EXPECT_THAT(getUnused(Includes, ReferencedFiles), ::testing::IsEmpty());
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/IncludeCleaner.cpp
===
--- clang-tools-extra/clangd/IncludeCleaner.cpp
+++ clang-tools-extra/clangd/IncludeCleaner.cpp
@@ -121,7 +121,11 @@
 if (!Macros.insert(FID).second)
   return;
 const auto &Exp = SM.getSLocEntry(FID).getExpansion();
-add(Exp.getSpellingLoc());
+// For token pasting operator in macros, the spelling location can be
+// within a temporary buffer that Clang creates (scratch space or
+// ScratchBuffer). That is not a real file we can include.
+if (!SM.isWrittenInScratchSpace(Exp.getSpellingLoc()))
+  add(Exp.getSpellingLoc());
 add(Exp.getExpansionLocStart());
 add(Exp.getExpansionLocEnd());
   }

[PATCH] D71016: [SYCL] Implement OpenCL kernel function generation

[Thorsten via Phabricator via cfe-commits]

tschuett added a comment.

It feels like you are doing codegen(OpenCL kernel) in Sema. Are OpenCL kernels 
the only approach.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71016

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

[PATCH] D111786: [Driver][WebAssembly] Use ToolChain reference instead of getToolChain().

[Frederic Cambus via Phabricator via cfe-commits]

fcambus created this revision.
fcambus added reviewers: sbc100, aheejin.
Herald added subscribers: ecnelises, sunfish, jgravelle-google, dschuff.
fcambus requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D111786

Files:
  clang/lib/Driver/ToolChains/WebAssembly.cpp


Index: clang/lib/Driver/ToolChains/WebAssembly.cpp
===
--- clang/lib/Driver/ToolChains/WebAssembly.cpp
+++ clang/lib/Driver/ToolChains/WebAssembly.cpp
@@ -63,7 +63,7 @@
   ArgStringList CmdArgs;
 
   CmdArgs.push_back("-m");
-  if (getToolChain().getTriple().isArch64Bit())
+  if (ToolChain.getTriple().isArch64Bit())
 CmdArgs.push_back("wasm64");
   else
 CmdArgs.push_back("wasm32");
@@ -130,7 +130,7 @@
 
   // When optimizing, if wasm-opt is available, run it.
   if (Arg *A = Args.getLastArg(options::OPT_O_Group)) {
-auto WasmOptPath = getToolChain().GetProgramPath("wasm-opt");
+auto WasmOptPath = ToolChain.GetProgramPath("wasm-opt");
 if (WasmOptPath != "wasm-opt") {
   StringRef OOpt = "s";
   if (A->getOption().matches(options::OPT_O4) ||


Index: clang/lib/Driver/ToolChains/WebAssembly.cpp
===
--- clang/lib/Driver/ToolChains/WebAssembly.cpp
+++ clang/lib/Driver/ToolChains/WebAssembly.cpp
@@ -63,7 +63,7 @@
   ArgStringList CmdArgs;
 
   CmdArgs.push_back("-m");
-  if (getToolChain().getTriple().isArch64Bit())
+  if (ToolChain.getTriple().isArch64Bit())
 CmdArgs.push_back("wasm64");
   else
 CmdArgs.push_back("wasm32");
@@ -130,7 +130,7 @@
 
   // When optimizing, if wasm-opt is available, run it.
   if (Arg *A = Args.getLastArg(options::OPT_O_Group)) {
-auto WasmOptPath = getToolChain().GetProgramPath("wasm-opt");
+auto WasmOptPath = ToolChain.GetProgramPath("wasm-opt");
 if (WasmOptPath != "wasm-opt") {
   StringRef OOpt = "s";
   if (A->getOption().matches(options::OPT_O4) ||
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109557: Adds a BreakBeforeClosingParen option

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.



> The you quoted would, in my mind, be formatted like this:
>
>   void foo() {
>   if (
>   quitelongarg != (alsolongarg - 1)
>   ) { // ABC is a very long comment
>   return;
>   }
>   }
>
> This is because I don't allow breaking the closing paren without breaking 
> after the opening paren, but this might be only my own style.

Yes, this is not what you are going to get with this revision, we need to 
decide if that is what is expected


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109557

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

[PATCH] D111698: [clangd] IncludeCleaner: Handle macros coming from ScratchBuffer

[Kirill Bobyrev via Phabricator via cfe-commits]

kbobyrev updated this revision to Diff 379661.
kbobyrev marked 3 inline comments as done.
kbobyrev added a comment.

Resolve review comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111698

Files:
  clang-tools-extra/clangd/IncludeCleaner.cpp
  clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp


Index: clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
===
--- clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
+++ clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
@@ -167,6 +167,47 @@
   UnorderedElementsAre("\"unused.h\"", "\"dir/unused.h\""));
 }
 
+TEST(IncludeCleaner, ScratchBuffer) {
+  TestTU TU;
+  TU.Filename = "foo.cpp";
+  TU.Code = R"cpp(
+#include "macro_spelling_in_scratch_buffer.h"
+
+using flags::FLAGS_FOO;
+
+int concat(a, b) = 42;
+)cpp";
+  // The pasting operator in combination with DEFINE_FLAG will create
+  // ScratchBuffer with `flags::FLAGS_FOO` that will have FileID but not
+  // FileEntry.
+  TU.AdditionalFiles["macro_spelling_in_scratch_buffer.h"] = R"cpp(
+#define DEFINE_FLAG(X) \
+namespace flags { \
+int FLAGS_##X; \
+} \
+
+DEFINE_FLAG(FOO)
+
+#define ab x
+#define concat(x, y) x##y
+)cpp";
+  ParsedAST AST = TU.build();
+  auto &SM = AST.getSourceManager();
+  auto &Includes = AST.getIncludeStructure();
+  auto ReferencedFiles = findReferencedFiles(findReferencedLocations(AST), SM);
+  auto Entry = SM.getFileManager().getFile(
+  testPath("macro_spelling_in_scratch_buffer.h"));
+  ASSERT_TRUE(Entry);
+  auto FID = SM.translateFile(*Entry);
+  // No "" FID.
+  EXPECT_THAT(ReferencedFiles, UnorderedElementsAre(FID));
+  // Should not crash due to  "files" missing from include
+  // structure.
+  EXPECT_THAT(
+  getUnused(Includes, translateToHeaderIDs(ReferencedFiles, Includes, SM)),
+  ::testing::IsEmpty());
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/IncludeCleaner.cpp
===
--- clang-tools-extra/clangd/IncludeCleaner.cpp
+++ clang-tools-extra/clangd/IncludeCleaner.cpp
@@ -121,9 +121,15 @@
 if (!Macros.insert(FID).second)
   return;
 const auto &Exp = SM.getSLocEntry(FID).getExpansion();
-add(Exp.getSpellingLoc());
-add(Exp.getExpansionLocStart());
-add(Exp.getExpansionLocEnd());
+// For token pasting operator in macros, the spelling location can be
+// within a temporary buffer that Clang creates (scratch space or
+// ScratchBuffer). That is not a real file we can include.
+if (!SM.isWrittenInScratchSpace(Exp.getSpellingLoc()))
+  add(Exp.getSpellingLoc());
+if (!SM.isWrittenInScratchSpace(Exp.getExpansionLocStart()))
+  add(Exp.getExpansionLocStart());
+if (!SM.isWrittenInScratchSpace(Exp.getExpansionLocEnd()))
+  add(Exp.getExpansionLocEnd());
   }
 };
 


Index: clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
===
--- clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
+++ clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
@@ -167,6 +167,47 @@
   UnorderedElementsAre("\"unused.h\"", "\"dir/unused.h\""));
 }
 
+TEST(IncludeCleaner, ScratchBuffer) {
+  TestTU TU;
+  TU.Filename = "foo.cpp";
+  TU.Code = R"cpp(
+#include "macro_spelling_in_scratch_buffer.h"
+
+using flags::FLAGS_FOO;
+
+int concat(a, b) = 42;
+)cpp";
+  // The pasting operator in combination with DEFINE_FLAG will create
+  // ScratchBuffer with `flags::FLAGS_FOO` that will have FileID but not
+  // FileEntry.
+  TU.AdditionalFiles["macro_spelling_in_scratch_buffer.h"] = R"cpp(
+#define DEFINE_FLAG(X) \
+namespace flags { \
+int FLAGS_##X; \
+} \
+
+DEFINE_FLAG(FOO)
+
+#define ab x
+#define concat(x, y) x##y
+)cpp";
+  ParsedAST AST = TU.build();
+  auto &SM = AST.getSourceManager();
+  auto &Includes = AST.getIncludeStructure();
+  auto ReferencedFiles = findReferencedFiles(findReferencedLocations(AST), SM);
+  auto Entry = SM.getFileManager().getFile(
+  testPath("macro_spelling_in_scratch_buffer.h"));
+  ASSERT_TRUE(Entry);
+  auto FID = SM.translateFile(*Entry);
+  // No "" FID.
+  EXPECT_THAT(ReferencedFiles, UnorderedElementsAre(FID));
+  // Should not crash due to  "files" missing from include
+  // structure.
+  EXPECT_THAT(
+  getUnused(Includes, translateToHeaderIDs(ReferencedFiles, Includes, SM)),
+  ::testing::IsEmpty());
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/IncludeCleaner.cpp
===
--- clang-tools-extra/clangd/IncludeCleaner.cpp
+++ clang-tools-extra/clangd/IncludeCleaner.cpp
@@ -121,9 +

[PATCH] D111790: [AArch64][Driver][SVE] Allow -msve-vector-bits=+ syntax to mean no maximum vscale

[Bradley Smith via Phabricator via cfe-commits]

bsmith created this revision.
bsmith added reviewers: paulwalker-arm, peterwaller-arm, sdesmalen.
Herald added subscribers: ctetreau, dexonsmith, dang, psnobl, kristof.beyls, 
tschuett.
Herald added a reviewer: efriedma.
bsmith requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This patch splits the existing SveVectorBits LangOpt into VScaleMin and
VScaleMax LangOpts such that we can represent such an option. The cc1
option has also been split into -mvscale-{min,max}= options so that the
cc1 arguments better reflect the vscale_range IR attribute.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D111790

Files:
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/AST/ASTContext.cpp
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CodeGen/aarch64-sve-acle-__ARM_FEATURE_SVE_VECTOR_OPERATORS.c
  clang/test/CodeGen/aarch64-sve-acle-__ARM_FEATURE_SVE_VECTOR_OPERATORS.cpp
  clang/test/CodeGen/aarch64-sve-vector-bits-codegen.c
  clang/test/CodeGen/arm-sve-vector-bits-vscale-range.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-bitcast.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-call.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-cast.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-codegen.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-globals.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-types.c
  clang/test/CodeGenCXX/aarch64-mangle-sve-fixed-vectors.cpp
  clang/test/CodeGenCXX/aarch64-sve-fixedtypeinfo.cpp
  clang/test/Driver/aarch64-sve-vector-bits.c
  clang/test/Sema/aarch64-sve-explicit-casts-fixed-size.c
  clang/test/Sema/aarch64-sve-lax-vector-conversions.c
  clang/test/Sema/attr-arm-sve-vector-bits.c
  clang/test/SemaCXX/aarch64-sve-explicit-casts-fixed-size.cpp
  clang/test/SemaCXX/aarch64-sve-lax-vector-conversions.cpp
  clang/test/SemaCXX/attr-arm-sve-vector-bits.cpp

Index: clang/test/SemaCXX/attr-arm-sve-vector-bits.cpp
===
--- clang/test/SemaCXX/attr-arm-sve-vector-bits.cpp
+++ clang/test/SemaCXX/attr-arm-sve-vector-bits.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -target-feature +bf16 -ffreestanding -fsyntax-only -verify -std=c++11 -msve-vector-bits=512 -fallow-half-arguments-and-returns -Wconversion %s
+// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -target-feature +bf16 -ffreestanding -fsyntax-only -verify -std=c++11 -mvscale-min=4 -mvscale-max=4 -fallow-half-arguments-and-returns -Wconversion %s
 // expected-no-diagnostics
 
 #include 
Index: clang/test/SemaCXX/aarch64-sve-lax-vector-conversions.cpp
===
--- clang/test/SemaCXX/aarch64-sve-lax-vector-conversions.cpp
+++ clang/test/SemaCXX/aarch64-sve-lax-vector-conversions.cpp
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -msve-vector-bits=512 -flax-vector-conversions=none -fallow-half-arguments-and-returns -ffreestanding -fsyntax-only -verify=lax-vector-none %s
-// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -msve-vector-bits=512 -flax-vector-conversions=integer -fallow-half-arguments-and-returns -ffreestanding -fsyntax-only -verify=lax-vector-integer %s
-// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -msve-vector-bits=512 -flax-vector-conversions=all -fallow-half-arguments-and-returns -ffreestanding -fsyntax-only -verify=lax-vector-all %s
+// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -mvscale-min=4 -mvscale-max=4 -flax-vector-conversions=none -fallow-half-arguments-and-returns -ffreestanding -fsyntax-only -verify=lax-vector-none %s
+// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -mvscale-min=4 -mvscale-max=4 -flax-vector-conversions=integer -fallow-half-arguments-and-returns -ffreestanding -fsyntax-only -verify=lax-vector-integer %s
+// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -mvscale-min=4 -mvscale-max=4 -flax-vector-conversions=all -fallow-half-arguments-and-returns -ffreestanding -fsyntax-only -verify=lax-vector-all %s
 
 #include 
 
Index: clang/test/SemaCXX/aarch64-sve-explicit-casts-fixed-size.cpp
===
--- clang/test/SemaCXX/aarch64-sve-explicit-casts-fixed-size.cpp
+++ clang/test/SemaCXX/aarch64-sve-explicit-casts-fixed-size.cpp
@@ -1,8 +1,8 @@
-// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -msve-vector-bits=128 -flax-vector-conversions=none -fallow-half-arguments-and-returns -ffreestanding -fsyntax-only -verify %s
-// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -msve-vector-bits=256 -flax-vector-conversions=none -fallow-half-arguments-and-returns -ffreestanding -fsyntax-only 

[PATCH] D111698: [clangd] IncludeCleaner: Handle macros coming from ScratchBuffer

[Kirill Bobyrev via Phabricator via cfe-commits]

kbobyrev updated this revision to Diff 379663.
kbobyrev added a comment.

Fix comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111698

Files:
  clang-tools-extra/clangd/IncludeCleaner.cpp
  clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp


Index: clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
===
--- clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
+++ clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
@@ -167,6 +167,47 @@
   UnorderedElementsAre("\"unused.h\"", "\"dir/unused.h\""));
 }
 
+TEST(IncludeCleaner, ScratchBuffer) {
+  TestTU TU;
+  TU.Filename = "foo.cpp";
+  TU.Code = R"cpp(
+#include "macro_spelling_in_scratch_buffer.h"
+
+using flags::FLAGS_FOO;
+
+int concat(a, b) = 42;
+)cpp";
+  // The pasting operator in combination with DEFINE_FLAG will create
+  // ScratchBuffer with `flags::FLAGS_FOO` that will have FileID but not
+  // FileEntry.
+  TU.AdditionalFiles["macro_spelling_in_scratch_buffer.h"] = R"cpp(
+#define DEFINE_FLAG(X) \
+namespace flags { \
+int FLAGS_##X; \
+} \
+
+DEFINE_FLAG(FOO)
+
+#define ab x
+#define concat(x, y) x##y
+)cpp";
+  ParsedAST AST = TU.build();
+  auto &SM = AST.getSourceManager();
+  auto &Includes = AST.getIncludeStructure();
+  auto ReferencedFiles = findReferencedFiles(findReferencedLocations(AST), SM);
+  auto Entry = SM.getFileManager().getFile(
+  testPath("macro_spelling_in_scratch_buffer.h"));
+  ASSERT_TRUE(Entry);
+  auto FID = SM.translateFile(*Entry);
+  // No "" FID.
+  EXPECT_THAT(ReferencedFiles, UnorderedElementsAre(FID));
+  // Should not crash due to  "files" missing from include
+  // structure.
+  EXPECT_THAT(
+  getUnused(Includes, translateToHeaderIDs(ReferencedFiles, Includes, SM)),
+  ::testing::IsEmpty());
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/IncludeCleaner.cpp
===
--- clang-tools-extra/clangd/IncludeCleaner.cpp
+++ clang-tools-extra/clangd/IncludeCleaner.cpp
@@ -121,9 +121,15 @@
 if (!Macros.insert(FID).second)
   return;
 const auto &Exp = SM.getSLocEntry(FID).getExpansion();
-add(Exp.getSpellingLoc());
-add(Exp.getExpansionLocStart());
-add(Exp.getExpansionLocEnd());
+// For token pasting operator in macros, spelling and expansion locations
+// can be within a temporary buffer that Clang creates (scratch space or
+// ScratchBuffer). That is not a real file we can include.
+if (!SM.isWrittenInScratchSpace(Exp.getSpellingLoc()))
+  add(Exp.getSpellingLoc());
+if (!SM.isWrittenInScratchSpace(Exp.getExpansionLocStart()))
+  add(Exp.getExpansionLocStart());
+if (!SM.isWrittenInScratchSpace(Exp.getExpansionLocEnd()))
+  add(Exp.getExpansionLocEnd());
   }
 };
 


Index: clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
===
--- clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
+++ clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
@@ -167,6 +167,47 @@
   UnorderedElementsAre("\"unused.h\"", "\"dir/unused.h\""));
 }
 
+TEST(IncludeCleaner, ScratchBuffer) {
+  TestTU TU;
+  TU.Filename = "foo.cpp";
+  TU.Code = R"cpp(
+#include "macro_spelling_in_scratch_buffer.h"
+
+using flags::FLAGS_FOO;
+
+int concat(a, b) = 42;
+)cpp";
+  // The pasting operator in combination with DEFINE_FLAG will create
+  // ScratchBuffer with `flags::FLAGS_FOO` that will have FileID but not
+  // FileEntry.
+  TU.AdditionalFiles["macro_spelling_in_scratch_buffer.h"] = R"cpp(
+#define DEFINE_FLAG(X) \
+namespace flags { \
+int FLAGS_##X; \
+} \
+
+DEFINE_FLAG(FOO)
+
+#define ab x
+#define concat(x, y) x##y
+)cpp";
+  ParsedAST AST = TU.build();
+  auto &SM = AST.getSourceManager();
+  auto &Includes = AST.getIncludeStructure();
+  auto ReferencedFiles = findReferencedFiles(findReferencedLocations(AST), SM);
+  auto Entry = SM.getFileManager().getFile(
+  testPath("macro_spelling_in_scratch_buffer.h"));
+  ASSERT_TRUE(Entry);
+  auto FID = SM.translateFile(*Entry);
+  // No "" FID.
+  EXPECT_THAT(ReferencedFiles, UnorderedElementsAre(FID));
+  // Should not crash due to  "files" missing from include
+  // structure.
+  EXPECT_THAT(
+  getUnused(Includes, translateToHeaderIDs(ReferencedFiles, Includes, SM)),
+  ::testing::IsEmpty());
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/IncludeCleaner.cpp
===
--- clang-tools-extra/clangd/IncludeCleaner.cpp
+++ clang-tools-extra/clangd/IncludeCleaner.cpp
@@ -121,9 +121,15 @@
 if (!Macros.insert(FID).secon

[PATCH] D109557: Adds a BreakBeforeClosingParen option

[Cameron Mulhern via Phabricator via cfe-commits]

csmulhern added a comment.

In D109557#3063563 , @MyDeveloperDay 
wrote:

>> The you quoted would, in my mind, be formatted like this:
>>
>>   void foo() {
>>   if (
>>   quitelongarg != (alsolongarg - 1)
>>   ) { // ABC is a very long comment
>>   return;
>>   }
>>   }
>>
>> This is because I don't allow breaking the closing paren without breaking 
>> after the opening paren, but this might be only my own style.
>
> Yes, this is not what you are going to get with this revision, we need to 
> decide if that is what is expected

Sorry for the delay in responding. I have not had the free time recently to 
address this feedback, but hope to get to it soon. I appreciate this formatting 
case being called out, and agree with the formatting proposed here. I will 
update the revision accordingly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109557

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

[PATCH] D109557: Adds a BreakBeforeClosingParen option

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

Do you think this is going to need some other capability to put the break after 
the  opening paren? e.g. `BreakAfterOpeningParen`

  if (
  ^


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109557

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

[PATCH] D109557: Adds a BreakBeforeClosingParen option

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

Personally I'm not convinced there wouldn't be people who want this for 
function declarations and definitions

  Function(
  param1,
  param2,
  param3
  );

but don't want this

  if (
 foo()
  )
  


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109557

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

[PATCH] D111711: [clangd] IncludeCleaner: ReferencedLocationCrawler should handle FunctionDecls

[Kirill Bobyrev via Phabricator via cfe-commits]

kbobyrev updated this revision to Diff 379664.
kbobyrev added a comment.

Only get function redecls as used for definition.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111711

Files:
  clang-tools-extra/clangd/IncludeCleaner.cpp
  clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp


Index: clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
===
--- clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
+++ clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
@@ -79,6 +79,19 @@
   "struct ^X { ^X(int) {} int ^foo(); };",
   "auto x = X(42); auto y = x.foo();",
   },
+  // Function
+  {
+  "void ^foo();",
+  "void foo() {}",
+  },
+  {
+  "void foo() {}",
+  "void foo();",
+  },
+  {
+  "inline void ^foo() {}",
+  "void bar() { foo(); }",
+  },
   // Static function
   {
   "struct ^X { static bool ^foo(); }; bool X::^foo() {}",
Index: clang-tools-extra/clangd/IncludeCleaner.cpp
===
--- clang-tools-extra/clangd/IncludeCleaner.cpp
+++ clang-tools-extra/clangd/IncludeCleaner.cpp
@@ -39,6 +39,13 @@
 return true;
   }
 
+  bool VisitFunctionDecl(FunctionDecl *FD) {
+// Function definition will require redeclarations to be included.
+if (FD == FD->getDefinition())
+  add(FD);
+return true;
+  }
+
   bool VisitCXXConstructExpr(CXXConstructExpr *CCE) {
 add(CCE->getConstructor());
 return true;


Index: clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
===
--- clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
+++ clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
@@ -79,6 +79,19 @@
   "struct ^X { ^X(int) {} int ^foo(); };",
   "auto x = X(42); auto y = x.foo();",
   },
+  // Function
+  {
+  "void ^foo();",
+  "void foo() {}",
+  },
+  {
+  "void foo() {}",
+  "void foo();",
+  },
+  {
+  "inline void ^foo() {}",
+  "void bar() { foo(); }",
+  },
   // Static function
   {
   "struct ^X { static bool ^foo(); }; bool X::^foo() {}",
Index: clang-tools-extra/clangd/IncludeCleaner.cpp
===
--- clang-tools-extra/clangd/IncludeCleaner.cpp
+++ clang-tools-extra/clangd/IncludeCleaner.cpp
@@ -39,6 +39,13 @@
 return true;
   }
 
+  bool VisitFunctionDecl(FunctionDecl *FD) {
+// Function definition will require redeclarations to be included.
+if (FD == FD->getDefinition())
+  add(FD);
+return true;
+  }
+
   bool VisitCXXConstructExpr(CXXConstructExpr *CCE) {
 add(CCE->getConstructor());
 return true;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] 0ce3c71 - [clangd] IncludeCleaner: Handle macros coming from ScratchBuffer

[Kirill Bobyrev via cfe-commits]

Author: Kirill Bobyrev
Date: 2021-10-14T13:36:37+02:00
New Revision: 0ce3c7111e909faa0202358bcfd6a46e3ace58b5

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

LOG: [clangd] IncludeCleaner: Handle macros coming from ScratchBuffer

Reviewed By: sammccall

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

Added: 


Modified: 
clang-tools-extra/clangd/IncludeCleaner.cpp
clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/IncludeCleaner.cpp 
b/clang-tools-extra/clangd/IncludeCleaner.cpp
index 91db8bfb8bc3c..35027306287ff 100644
--- a/clang-tools-extra/clangd/IncludeCleaner.cpp
+++ b/clang-tools-extra/clangd/IncludeCleaner.cpp
@@ -121,9 +121,15 @@ struct ReferencedFiles {
 if (!Macros.insert(FID).second)
   return;
 const auto &Exp = SM.getSLocEntry(FID).getExpansion();
-add(Exp.getSpellingLoc());
-add(Exp.getExpansionLocStart());
-add(Exp.getExpansionLocEnd());
+// For token pasting operator in macros, spelling and expansion locations
+// can be within a temporary buffer that Clang creates (scratch space or
+// ScratchBuffer). That is not a real file we can include.
+if (!SM.isWrittenInScratchSpace(Exp.getSpellingLoc()))
+  add(Exp.getSpellingLoc());
+if (!SM.isWrittenInScratchSpace(Exp.getExpansionLocStart()))
+  add(Exp.getExpansionLocStart());
+if (!SM.isWrittenInScratchSpace(Exp.getExpansionLocEnd()))
+  add(Exp.getExpansionLocEnd());
   }
 };
 

diff  --git a/clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp 
b/clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
index c6e8167319618..f206d87cce162 100644
--- a/clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
+++ b/clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
@@ -167,6 +167,47 @@ TEST(IncludeCleaner, GetUnusedHeaders) {
   UnorderedElementsAre("\"unused.h\"", "\"dir/unused.h\""));
 }
 
+TEST(IncludeCleaner, ScratchBuffer) {
+  TestTU TU;
+  TU.Filename = "foo.cpp";
+  TU.Code = R"cpp(
+#include "macro_spelling_in_scratch_buffer.h"
+
+using flags::FLAGS_FOO;
+
+int concat(a, b) = 42;
+)cpp";
+  // The pasting operator in combination with DEFINE_FLAG will create
+  // ScratchBuffer with `flags::FLAGS_FOO` that will have FileID but not
+  // FileEntry.
+  TU.AdditionalFiles["macro_spelling_in_scratch_buffer.h"] = R"cpp(
+#define DEFINE_FLAG(X) \
+namespace flags { \
+int FLAGS_##X; \
+} \
+
+DEFINE_FLAG(FOO)
+
+#define ab x
+#define concat(x, y) x##y
+)cpp";
+  ParsedAST AST = TU.build();
+  auto &SM = AST.getSourceManager();
+  auto &Includes = AST.getIncludeStructure();
+  auto ReferencedFiles = findReferencedFiles(findReferencedLocations(AST), SM);
+  auto Entry = SM.getFileManager().getFile(
+  testPath("macro_spelling_in_scratch_buffer.h"));
+  ASSERT_TRUE(Entry);
+  auto FID = SM.translateFile(*Entry);
+  // No "" FID.
+  EXPECT_THAT(ReferencedFiles, UnorderedElementsAre(FID));
+  // Should not crash due to  "files" missing from include
+  // structure.
+  EXPECT_THAT(
+  getUnused(Includes, translateToHeaderIDs(ReferencedFiles, Includes, SM)),
+  ::testing::IsEmpty());
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang



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

[PATCH] D111698: [clangd] IncludeCleaner: Handle macros coming from ScratchBuffer

[Kirill Bobyrev 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 rG0ce3c7111e90: [clangd] IncludeCleaner: Handle macros coming 
from ScratchBuffer (authored by kbobyrev).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111698

Files:
  clang-tools-extra/clangd/IncludeCleaner.cpp
  clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp


Index: clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
===
--- clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
+++ clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
@@ -167,6 +167,47 @@
   UnorderedElementsAre("\"unused.h\"", "\"dir/unused.h\""));
 }
 
+TEST(IncludeCleaner, ScratchBuffer) {
+  TestTU TU;
+  TU.Filename = "foo.cpp";
+  TU.Code = R"cpp(
+#include "macro_spelling_in_scratch_buffer.h"
+
+using flags::FLAGS_FOO;
+
+int concat(a, b) = 42;
+)cpp";
+  // The pasting operator in combination with DEFINE_FLAG will create
+  // ScratchBuffer with `flags::FLAGS_FOO` that will have FileID but not
+  // FileEntry.
+  TU.AdditionalFiles["macro_spelling_in_scratch_buffer.h"] = R"cpp(
+#define DEFINE_FLAG(X) \
+namespace flags { \
+int FLAGS_##X; \
+} \
+
+DEFINE_FLAG(FOO)
+
+#define ab x
+#define concat(x, y) x##y
+)cpp";
+  ParsedAST AST = TU.build();
+  auto &SM = AST.getSourceManager();
+  auto &Includes = AST.getIncludeStructure();
+  auto ReferencedFiles = findReferencedFiles(findReferencedLocations(AST), SM);
+  auto Entry = SM.getFileManager().getFile(
+  testPath("macro_spelling_in_scratch_buffer.h"));
+  ASSERT_TRUE(Entry);
+  auto FID = SM.translateFile(*Entry);
+  // No "" FID.
+  EXPECT_THAT(ReferencedFiles, UnorderedElementsAre(FID));
+  // Should not crash due to  "files" missing from include
+  // structure.
+  EXPECT_THAT(
+  getUnused(Includes, translateToHeaderIDs(ReferencedFiles, Includes, SM)),
+  ::testing::IsEmpty());
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/IncludeCleaner.cpp
===
--- clang-tools-extra/clangd/IncludeCleaner.cpp
+++ clang-tools-extra/clangd/IncludeCleaner.cpp
@@ -121,9 +121,15 @@
 if (!Macros.insert(FID).second)
   return;
 const auto &Exp = SM.getSLocEntry(FID).getExpansion();
-add(Exp.getSpellingLoc());
-add(Exp.getExpansionLocStart());
-add(Exp.getExpansionLocEnd());
+// For token pasting operator in macros, spelling and expansion locations
+// can be within a temporary buffer that Clang creates (scratch space or
+// ScratchBuffer). That is not a real file we can include.
+if (!SM.isWrittenInScratchSpace(Exp.getSpellingLoc()))
+  add(Exp.getSpellingLoc());
+if (!SM.isWrittenInScratchSpace(Exp.getExpansionLocStart()))
+  add(Exp.getExpansionLocStart());
+if (!SM.isWrittenInScratchSpace(Exp.getExpansionLocEnd()))
+  add(Exp.getExpansionLocEnd());
   }
 };
 


Index: clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
===
--- clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
+++ clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
@@ -167,6 +167,47 @@
   UnorderedElementsAre("\"unused.h\"", "\"dir/unused.h\""));
 }
 
+TEST(IncludeCleaner, ScratchBuffer) {
+  TestTU TU;
+  TU.Filename = "foo.cpp";
+  TU.Code = R"cpp(
+#include "macro_spelling_in_scratch_buffer.h"
+
+using flags::FLAGS_FOO;
+
+int concat(a, b) = 42;
+)cpp";
+  // The pasting operator in combination with DEFINE_FLAG will create
+  // ScratchBuffer with `flags::FLAGS_FOO` that will have FileID but not
+  // FileEntry.
+  TU.AdditionalFiles["macro_spelling_in_scratch_buffer.h"] = R"cpp(
+#define DEFINE_FLAG(X) \
+namespace flags { \
+int FLAGS_##X; \
+} \
+
+DEFINE_FLAG(FOO)
+
+#define ab x
+#define concat(x, y) x##y
+)cpp";
+  ParsedAST AST = TU.build();
+  auto &SM = AST.getSourceManager();
+  auto &Includes = AST.getIncludeStructure();
+  auto ReferencedFiles = findReferencedFiles(findReferencedLocations(AST), SM);
+  auto Entry = SM.getFileManager().getFile(
+  testPath("macro_spelling_in_scratch_buffer.h"));
+  ASSERT_TRUE(Entry);
+  auto FID = SM.translateFile(*Entry);
+  // No "" FID.
+  EXPECT_THAT(ReferencedFiles, UnorderedElementsAre(FID));
+  // Should not crash due to  "files" missing from include
+  // structure.
+  EXPECT_THAT(
+  getUnused(Includes, translateToHeaderIDs(ReferencedFiles, Includes, SM)),
+  ::testing::IsEmpty());
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/IncludeCleaner.cpp
==

[PATCH] D109707: [HIP] [AlwaysInliner] Disable AlwaysInliner to eliminate undefined symbols

[Anshil Gandhi via Phabricator via cfe-commits]

gandhi21299 updated this revision to Diff 379530.
gandhi21299 added a comment.

add a restrictions to what architecture AlwaysInliner should run on, updated 
the inline-calls.ll test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109707

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGenCUDA/amdgpu-alias-undef-symbols.cu
  llvm/lib/Target/AMDGPU/AMDGPUAlwaysInlinePass.cpp
  llvm/lib/Target/AMDGPU/AMDGPUResourceUsageAnalysis.cpp
  llvm/test/CodeGen/AMDGPU/inline-calls.ll

Index: llvm/test/CodeGen/AMDGPU/inline-calls.ll
===
--- llvm/test/CodeGen/AMDGPU/inline-calls.ll
+++ llvm/test/CodeGen/AMDGPU/inline-calls.ll
@@ -1,6 +1,6 @@
-; RUN: llc -march=amdgcn -mcpu=tahiti -verify-machineinstrs < %s | FileCheck  %s
-; RUN: llc -march=amdgcn -mcpu=tonga -verify-machineinstrs < %s | FileCheck  %s
-; RUN: llc -march=r600 -mcpu=redwood -verify-machineinstrs < %s | FileCheck %s
+; RUN: llc -mtriple amdgcn-unknown-linux-gnu -mcpu=tahiti -verify-machineinstrs < %s | FileCheck  %s
+; RUN: llc -mtriple amdgcn-unknown-linux-gnu -mcpu=tonga -verify-machineinstrs < %s | FileCheck  %s
+; RUN: llc -mtriple r600-unknown-linux-gnu -mcpu=redwood -verify-machineinstrs < %s | FileCheck %s --check-prefix=R600
 
 ; ALL-NOT: {{^}}func:
 define internal i32 @func(i32 %a) {
@@ -9,7 +9,7 @@
   ret i32 %tmp0
 }
 
-; ALL: {{^}}kernel:
+; CHECK: {{^}}kernel:
 ; GCN-NOT: s_swappc_b64
 define amdgpu_kernel void @kernel(i32 addrspace(1)* %out) {
 entry:
@@ -18,12 +18,13 @@
   ret void
 }
 
-; CHECK-NOT: func_alias
-; ALL-NOT: func_alias
+; CHECK: func_alias
+; R600-NOT: func_alias
 @func_alias = alias i32 (i32), i32 (i32)* @func
 
-; ALL: {{^}}kernel3:
+; CHECK-NOT: {{^}}kernel3:
 ; GCN-NOT: s_swappc_b64
+; R600: {{^}}kernel3:
 define amdgpu_kernel void @kernel3(i32 addrspace(1)* %out) {
 entry:
   %tmp0 = call i32 @func_alias(i32 1)
Index: llvm/lib/Target/AMDGPU/AMDGPUResourceUsageAnalysis.cpp
===
--- llvm/lib/Target/AMDGPU/AMDGPUResourceUsageAnalysis.cpp
+++ llvm/lib/Target/AMDGPU/AMDGPUResourceUsageAnalysis.cpp
@@ -29,6 +29,8 @@
 #include "SIMachineFunctionInfo.h"
 #include "llvm/Analysis/CallGraph.h"
 #include "llvm/CodeGen/TargetPassConfig.h"
+#include "llvm/IR/GlobalAlias.h"
+#include "llvm/IR/GlobalValue.h"
 #include "llvm/Target/TargetMachine.h"
 
 using namespace llvm;
@@ -61,7 +63,8 @@
 assert(Op.getImm() == 0);
 return nullptr;
   }
-
+  if (auto *GA = dyn_cast(Op.getGlobal()))
+return cast(GA->getOperand(0));
   return cast(Op.getGlobal());
 }
 
Index: llvm/lib/Target/AMDGPU/AMDGPUAlwaysInlinePass.cpp
===
--- llvm/lib/Target/AMDGPU/AMDGPUAlwaysInlinePass.cpp
+++ llvm/lib/Target/AMDGPU/AMDGPUAlwaysInlinePass.cpp
@@ -15,6 +15,7 @@
 #include "AMDGPU.h"
 #include "AMDGPUTargetMachine.h"
 #include "Utils/AMDGPUBaseInfo.h"
+#include "llvm/CodeGen/CommandFlags.h"
 #include "llvm/IR/Module.h"
 #include "llvm/Pass.h"
 #include "llvm/Support/CommandLine.h"
@@ -90,9 +91,13 @@
 
   SmallPtrSet FuncsToAlwaysInline;
   SmallPtrSet FuncsToNoInline;
+  Triple TT(M.getTargetTriple());
 
   for (GlobalAlias &A : M.aliases()) {
 if (Function* F = dyn_cast(A.getAliasee())) {
+  if (TT.getArch() == Triple::amdgcn &&
+  A.getLinkage() != GlobalValue::InternalLinkage)
+continue;
   A.replaceAllUsesWith(F);
   AliasesToRemove.push_back(&A);
 }
Index: clang/test/CodeGenCUDA/amdgpu-alias-undef-symbols.cu
===
--- /dev/null
+++ clang/test/CodeGenCUDA/amdgpu-alias-undef-symbols.cu
@@ -0,0 +1,17 @@
+// REQUIRES: amdgpu-registered-target, clang-driver
+
+// RUN: %clang --offload-arch=gfx906 --cuda-device-only -nogpulib -nogpuinc -x hip -emit-llvm -S -o - %s \
+// RUN:   -fgpu-rdc -O3 -mllvm -amdgpu-early-inline-all=true -mllvm -amdgpu-function-calls=false | \
+// RUN:   FileCheck %s
+
+#include "Inputs/cuda.h"
+
+// CHECK: %struct.B = type { i8 }
+struct B {
+
+  // CHECK: @_ZN1BC1Ei = hidden unnamed_addr alias void (%struct.B*, i32), void (%struct.B*, i32)* @_ZN1BC2Ei
+  __device__ B(int x);
+};
+
+__device__ B::B(int x) {
+}
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -5109,9 +5109,9 @@
   }
 
   // Enable -mconstructor-aliases except on darwin, where we have to work around
-  // a linker bug (see ), and CUDA/AMDGPU device code,
-  // where aliases aren't supported.
-  if (!RawTriple.isOSDarwin() && !RawTriple.isNVPTX() && !RawTriple.isAMDGPU())
+  // a linker bug (see ), and CUDA device code, where
+  // aliases aren't supported.
+  if (!RawTriple.isOSDarwin() && !RawTriple.isNVPTX())
 CmdArgs.push_back

[PATCH] D109707: [HIP] [AlwaysInliner] Disable AlwaysInliner to eliminate undefined symbols

[Anshil Gandhi via Phabricator via cfe-commits]

gandhi21299 added a comment.

Passed ePSDB


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109707

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

[PATCH] D33029: [clang-format] add option for dangling parenthesis

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a subscriber: csmulhern.
MyDeveloperDay added a comment.

I understand the frustration (I'm not convinced that its Phabricators fault to 
be honest, that's our process and plenty of people follow it without issues) , 
Our incredible original code owners have moved on to do I assume other things 
(rightly so as their contribution was already massive) and we are trying to 
hold the fort. But waiting for them to comment might mean you are waiting a 
long time.

We are tracking this work  via D109557: Adds a BreakBeforeClosingParen option 
 which was an attempt to resuscitate this 
request. Honestly I'm crateful to @csmulhern for taking it on.

As this current review D33029  is 3 years 
since the last diff its hideously out of date and won't merge cleanly, It also 
is completely lacking in unit tests and that was always a massive "no-no"

I recommend we put our efforts into getting D109557 
 over the line? given that they have 
addressed those issues (I have given it an "Accept")

I'm was not a massive fan of  the term `DanglingParenthesis` as a technical 
directive, and think `BreakBeforeClosingParen` from D109557 
 is a better name.

I have some reservations about the `)` moving too much in my view on an if 
etc.. but as long as we can get a consensus as to what you all (I say all as 
this has 87 subscribers!) expect it to do I'm ok (as I won't be using this 
personally, I don't feel my opinion matters that much other than from a 
maintenance perspective! but I need those of you that will to comment if you 
don't like what its trying to do)

A good set of unit tests really helps to flesh this out.

  void foo() {
if (quitelongarg != (alsolongarg - 1)
) { // ABC is a very long comment
  return;
}
  }

Its definitely not about about LLVM leaving good will on the table, its about 
having people being persistent enough to push it over the line (which believe 
me I recognize is difficult because lots of us have other jobs and do this in 
free time)

Contributors need to remain at the table long enough to finish the meal. There 
is a support burden that has to be considered especially 6 months down the line 
when the feature gets branched out and exposed to the masses,

But to be honest its not fair on those of us trying to look after it to just 
rock up every 6 months and ask why we've not pushed your feature over the line 
for you. You contribution is appreciated, but I would rather people hung out 
here a little longer.

My 2c worth.


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

https://reviews.llvm.org/D33029

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

[PATCH] D111790: [AArch64][Driver][SVE] Allow -msve-vector-bits=+ syntax to mean no maximum vscale

[Paul Walker via Phabricator via cfe-commits]

paulwalker-arm added a comment.

Are the references to "128-bit chunks" for the vscale flags necessary?  That's 
really a nuisance of SVE that LLVM IR should not need to worry about.  Can we 
speak exclusively in terms of vscale or is the "multiples of 128" required 
somewhere?  Perhaps we're missing a target specific convert function from 
vscale+elt to byes or something.  Also there's nothing stoping vscale from 
being 3 (essentially any positive number) but you look to be restricting it to 
a power of two.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111790

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

[PATCH] D107882: BPF: Enable frontend constant folding for VLA size

[Paul Chaignon via Phabricator via cfe-commits]

pchaigno added a comment.

@efriedma @rsmith Did you get a chance to take a look? This regression is still 
affecting LLVM, including the recently released v13.0.0.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107882

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

[clang] b577126 - [clang][sema] instantiateOMPDeclareVariantAttr - merge repeated VariantFuncRef.get() calls. NFCI.

[Simon Pilgrim via cfe-commits]

Author: Simon Pilgrim
Date: 2021-10-14T12:51:34+01:00
New Revision: b577126d626855fabc11a203e7a7e0187d48c227

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

LOG: [clang][sema] instantiateOMPDeclareVariantAttr - merge repeated 
VariantFuncRef.get() calls. NFCI.

Fixes scan-build warning about dead initialization

Added: 


Modified: 
clang/lib/Sema/SemaTemplateInstantiateDecl.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp 
b/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
index 70c42a19978c..5ddac3c98c25 100644
--- a/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ b/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -436,11 +436,11 @@ static void instantiateOMPDeclareVariantAttr(
 return;
 
   Expr *E = VariantFuncRef.get();
+
   // Check function/variant ref for `omp declare variant` but not for `omp
   // begin declare variant` (which use implicit attributes).
   Optional> DeclVarData =
-  S.checkOpenMPDeclareVariantFunction(S.ConvertDeclToDeclGroup(New),
-  VariantFuncRef.get(), TI,
+  S.checkOpenMPDeclareVariantFunction(S.ConvertDeclToDeclGroup(New), E, TI,
   Attr.getRange());
 
   if (!DeclVarData)



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

[PATCH] D71016: [SYCL] Implement OpenCL kernel function generation

[Alexey Bader via Phabricator via cfe-commits]

bader added a comment.

In D71016#3063457 , @tschuett wrote:

> It feels like you are doing codegen(OpenCL kernel) in Sema. Are OpenCL 
> kernels the only approach.

We need to update the description of the patch to clarify that it applies to 
other GPU programming models as well. When the patch was uploaded SYCL targeted 
OpenCL kernels only and today the downstream implementation can target CUDA, 
HIP and Intel oneAPI Level Zero kernels as well.
SYCL kernel is defined as C++ callable type, but typical GPU kernel interface 
is a C-like function. In addition to that there might be additional 
restrictions on passing data from the host system (e.g. image types can be 
passed as a member of C++ class, etc.). The solution here is emit a wrapper 
function, which initializes and invokes SYCL callable object.

Does it answer your question or you would like to see changes in addition to 
the description update?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71016

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

[PATCH] D111792: [ObjC-GNUstep] Fix ivars for dll{im,ex}ported classes.

[David Chisnall via Phabricator via cfe-commits]

theraven created this revision.
theraven requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

If a class is dllexported or imported then the ivar offset variables
must be as well.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D111792

Files:
  clang/lib/CodeGen/CGObjCGNU.cpp
  clang/test/CodeGenObjC/gnustep2-dllexport-ivar.m

Index: clang/test/CodeGenObjC/gnustep2-dllexport-ivar.m
===
--- /dev/null
+++ clang/test/CodeGenObjC/gnustep2-dllexport-ivar.m
@@ -0,0 +1,46 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-windows-msvc -S -emit-llvm -fobjc-runtime=gnustep-2.0 -o - %s | FileCheck %s
+
+__attribute__((dllexport))
+@interface Cls
+{
+  int implicit_prot;
+  @public
+  int pub;
+  @protected
+  int prot;
+  @private
+  int priv;
+  @package
+  int pkg;
+}
+@end
+@implementation Cls @end
+
+// CHECK: @__objc_ivar_offset_Cls.implicit_prot.i = dllexport global i32 0
+// CHECK: @__objc_ivar_offset_Cls.pub.i = dllexport global i32 4
+// CHECK: @__objc_ivar_offset_Cls.prot.i = dllexport global i32 8
+// CHECK: @__objc_ivar_offset_Cls.priv.i = hidden global i32 12
+// CHECK: @__objc_ivar_offset_Cls.pkg.i = hidden global i32 16
+
+__attribute__((dllimport))
+@interface ClsImport
+{
+  int implicit_prot;
+  @public
+  int pub;
+  @protected
+  int prot;
+}
+@end
+
+@interface Sub : ClsImport @end
+
+@implementation Sub
+- (id)init
+{
+  implicit_prot = 0;
+  pub = 1;
+  prot = 2;
+  return self;
+}
+@end
Index: clang/lib/CodeGen/CGObjCGNU.cpp
===
--- clang/lib/CodeGen/CGObjCGNU.cpp
+++ clang/lib/CodeGen/CGObjCGNU.cpp
@@ -1657,7 +1657,7 @@
 if (global) {
   llvm::GlobalVariable *GV = lateInit.second.first;
   b.CreateAlignedStore(
-  global,
+  llvm::ConstantExpr::getBitCast(global, PtrTy),
   b.CreateStructGEP(GV->getValueType(), GV, lateInit.second.second),
   CGM.getPointerAlign().getAsAlign());
 }
@@ -1686,14 +1686,33 @@
   + '.' + Ivar->getNameAsString() + '.' + TypeEncoding;
 return Name;
   }
-  llvm::Value *EmitIvarOffset(CodeGenFunction &CGF,
+
+  llvm::GlobalVariable *EmitIvarOffsetVariable(
   const ObjCInterfaceDecl *Interface,
-  const ObjCIvarDecl *Ivar) override {
+  const ObjCIvarDecl *Ivar) {
 const std::string Name = GetIVarOffsetVariableName(Ivar->getContainingInterface(), Ivar);
 llvm::GlobalVariable *IvarOffsetPointer = TheModule.getNamedGlobal(Name);
-if (!IvarOffsetPointer)
+if (!IvarOffsetPointer) {
   IvarOffsetPointer = new llvm::GlobalVariable(TheModule, IntTy, false,
   llvm::GlobalValue::ExternalLinkage, nullptr, Name);
+  if (CGM.getTriple().isOSBinFormatCOFF()) {
+if (Interface->hasAttr() &&
+(Ivar->getCanonicalAccessControl() != ObjCIvarDecl::Private) &&
+(Ivar->getCanonicalAccessControl() != ObjCIvarDecl::Package))
+  IvarOffsetPointer->setDLLStorageClass(
+llvm::GlobalValue::DLLExportStorageClass);
+else if (Interface->hasAttr())
+  IvarOffsetPointer->setDLLStorageClass(
+llvm::GlobalValue::DLLImportStorageClass);
+  }
+}
+return IvarOffsetPointer;
+  }
+
+  llvm::Value *EmitIvarOffset(CodeGenFunction &CGF,
+  const ObjCInterfaceDecl *Interface,
+  const ObjCIvarDecl *Ivar) override {
+llvm::GlobalVariable *IvarOffsetPointer = EmitIvarOffsetVariable(Interface, Ivar);
 CharUnits Align = CGM.getIntAlign();
 llvm::Value *Offset =
 CGF.Builder.CreateAlignedLoad(IntTy, IvarOffsetPointer, Align);
@@ -1851,14 +1870,8 @@
 uint64_t BaseOffset = ComputeIvarBaseOffset(CGM, OID, IVD);
 uint64_t Offset = BaseOffset - superInstanceSize;
 llvm::Constant *OffsetValue = llvm::ConstantInt::get(IntTy, Offset);
-std::string OffsetName = GetIVarOffsetVariableName(classDecl, IVD);
-llvm::GlobalVariable *OffsetVar = TheModule.getGlobalVariable(OffsetName);
-if (OffsetVar)
-  OffsetVar->setInitializer(OffsetValue);
-else
-  OffsetVar = new llvm::GlobalVariable(TheModule, IntTy,
-false, llvm::GlobalValue::ExternalLinkage,
-OffsetValue, OffsetName);
+llvm::GlobalVariable *OffsetVar = EmitIvarOffsetVariable(classDecl, IVD);
+OffsetVar->setInitializer(OffsetValue);
 auto ivarVisibility =
 (IVD->getAccessControl() == ObjCIvarDecl::Private ||
  IVD->getAccessControl() == ObjCIvarDecl::Package ||
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D111793: [Driver][Darwin] Use T reference instead of getToolChain().getTriple().

[Frederic Cambus via Phabricator via cfe-commits]

fcambus created this revision.
fcambus added reviewers: arphaman, vsk, ahatanak, thakis.
fcambus requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D111793

Files:
  clang/lib/Driver/ToolChains/Darwin.cpp


Index: clang/lib/Driver/ToolChains/Darwin.cpp
===
--- clang/lib/Driver/ToolChains/Darwin.cpp
+++ clang/lib/Driver/ToolChains/Darwin.cpp
@@ -94,6 +94,8 @@
  const InputInfoList &Inputs,
  const ArgList &Args,
  const char *LinkingOutput) const {
+  const llvm::Triple &T(getToolChain().getTriple());
+
   ArgStringList CmdArgs;
 
   assert(Inputs.size() == 1 && "Unexpected number of inputs.");
@@ -112,7 +114,6 @@
   // FIXME: at run-time detect assembler capabilities or rely on version
   // information forwarded by -target-assembler-version.
   if (Args.hasArg(options::OPT_fno_integrated_as)) {
-const llvm::Triple &T(getToolChain().getTriple());
 if (!(T.isMacOSX() && T.isMacOSXVersionLT(10, 7)))
   CmdArgs.push_back("-Q");
   }
@@ -130,8 +131,7 @@
   AddMachOArch(Args, CmdArgs);
 
   // Use -force_cpusubtype_ALL on x86 by default.
-  if (getToolChain().getTriple().isX86() ||
-  Args.hasArg(options::OPT_force__cpusubtype__ALL))
+  if (T.isX86() || Args.hasArg(options::OPT_force__cpusubtype__ALL))
 CmdArgs.push_back("-force_cpusubtype_ALL");
 
   if (getToolChain().getArch() != llvm::Triple::x86_64 &&


Index: clang/lib/Driver/ToolChains/Darwin.cpp
===
--- clang/lib/Driver/ToolChains/Darwin.cpp
+++ clang/lib/Driver/ToolChains/Darwin.cpp
@@ -94,6 +94,8 @@
  const InputInfoList &Inputs,
  const ArgList &Args,
  const char *LinkingOutput) const {
+  const llvm::Triple &T(getToolChain().getTriple());
+
   ArgStringList CmdArgs;
 
   assert(Inputs.size() == 1 && "Unexpected number of inputs.");
@@ -112,7 +114,6 @@
   // FIXME: at run-time detect assembler capabilities or rely on version
   // information forwarded by -target-assembler-version.
   if (Args.hasArg(options::OPT_fno_integrated_as)) {
-const llvm::Triple &T(getToolChain().getTriple());
 if (!(T.isMacOSX() && T.isMacOSXVersionLT(10, 7)))
   CmdArgs.push_back("-Q");
   }
@@ -130,8 +131,7 @@
   AddMachOArch(Args, CmdArgs);
 
   // Use -force_cpusubtype_ALL on x86 by default.
-  if (getToolChain().getTriple().isX86() ||
-  Args.hasArg(options::OPT_force__cpusubtype__ALL))
+  if (T.isX86() || Args.hasArg(options::OPT_force__cpusubtype__ALL))
 CmdArgs.push_back("-force_cpusubtype_ALL");
 
   if (getToolChain().getArch() != llvm::Triple::x86_64 &&
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D71016: [SYCL] Implement OpenCL kernel function generation

[Thorsten via Phabricator via cfe-commits]

tschuett added a comment.

In D71016#3063706 , @bader wrote:

> In D71016#3063457 , @tschuett wrote:
>
>> It feels like you are doing codegen(OpenCL kernel) in Sema. Are OpenCL 
>> kernels the only approach.
>
> We need to update the description of the patch to clarify that it applies to 
> other GPU programming models as well. When the patch was uploaded SYCL 
> targeted OpenCL kernels only and today the downstream implementation can 
> target CUDA, HIP and Intel oneAPI Level Zero kernels as well.
> SYCL kernel is defined as C++ callable type, but typical GPU kernel interface 
> is a C-like function. In addition to that there might be additional 
> restrictions on passing data from the host system (e.g. image types can be 
> passed as a member of C++ class, etc.). The solution here is emit a wrapper 
> function, which initializes and invokes SYCL callable object.
>
> Does it answer your question or you would like to see changes in addition to 
> the description update?

Would a codegenSYCL directory help you to separate Sema from code generation?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71016

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

[PATCH] D71016: [SYCL] Implement OpenCL kernel function generation

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a reviewer: rsmith.
lebedev.ri added a comment.

Doesn't this make AST non-representable of the reality,
shouldn't the lowering happen in codegen, not in sema?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71016

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

[PATCH] D111790: [AArch64][Driver][SVE] Allow -msve-vector-bits=+ syntax to mean no maximum vscale

[Bradley Smith via Phabricator via cfe-commits]

bsmith added a comment.

In D111790#3063698 , @paulwalker-arm 
wrote:

> Are the references to "128-bit chunks" for the vscale flags necessary?  
> That's really a nuisance of SVE that LLVM IR should not need to worry about.  
> Can we speak exclusively in terms of vscale or is the "multiples of 128" 
> required somewhere?  Perhaps we're missing a target specific convert function 
> from vscale+elt to bytes or something.  Also there's nothing stoping vscale 
> from being 3 (essentially any positive number) but you look to be restricting 
> it to a power of two.

It does feel like we should have something somewhere that specifies the vscale 
chunk as I've had to hardcode 128 in a lot of places (thought they are SVE 
specific places, so I'll remove mention of it from the helptext). As for vscale 
values allowed, if we don't validate the values used in the option itself, 
where would we do it? I guess we could just blindly propagate the value down to 
the IR attribute and let the backends figure out what they want. The issue then 
is providing a nice error, though perhaps we don't need one given they are cc1 
options?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111790

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

[PATCH] D110669: [RISCV] Update Zba, Zbb, Zbc, and Zbs version from 0.93 to 1.0.

[Luís Marques via Phabricator via cfe-commits]

luismarques accepted this revision.
luismarques 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/D110669/new/

https://reviews.llvm.org/D110669

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

[PATCH] D71016: [SYCL] Implement OpenCL kernel function generation

[Alexey Bader via Phabricator via cfe-commits]

bader added a comment.

In D71016#3063762 , @tschuett wrote:

> Would a codegenSYCL directory help you to separate Sema from code generation?

Moving wrapper kernel function generation to CodeGen library make sense to me.

> Doesn't this make AST non-representable of the reality,
> shouldn't the lowering happen in codegen, not in sema?

I'm not sure I understand what does "make AST non-representable of the reality" 
mean, but it seems to be the same suggestion as @tschuett proposed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71016

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

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

[Dave Green via Phabricator via cfe-commits]

dmgreen added a comment.

In D110258#3057380 , @david-arm wrote:

> In D110258#3055488 , @dmgreen wrote:
>
>> If D111551  was folded into this patch, 
>> would it be possible to add tests for -tune-cpu enabling/disabling features 
>> at the correct times?
>
> Similar to the comment I left on D110259 , 
> I don't want D111551  to hold up the cost 
> model changes, which are critical.

They are not. The changes in the cost model in D110259 
 are independent of whether -mcpu or -mtune 
work a particular way and could probably be committed now if it was rebased 
away from the mtune patches :)

> I'd prefer them to be independent.

That's fine. They seem like two patches doing two halves of one change to me, 
but having them separate sounds perfectly fine so long as we have the tests we 
need. I see tests that the clang -mcpu and -mtune set llvm flags as expected, 
but not that those target-cpu and tune-cpu options then set the correct 
features at the correct times.




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

david-arm wrote:
> dmgreen wrote:
> > My understanding is that -mcpu=cpu is the same as -march=something + 
> > -mtune=cpu. Why would this case not add a -tune-cpu too? Is it because that 
> > gets handled in llvm?
> I thought this was pretty standard behaviour? We're already adding 
> -target-cpu, which implies the arch + tuning, so isn't adding -tune-cpu 
> redundant? Not sure what value "-target-cpu=thunderx -tune-cpu=thunderx" adds 
> really.
It could work either way with adding both attributes or letting the target-cpu 
act as both if it is the only one present. So long as we are happy with it 
working this way it sounds good to me.


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

https://reviews.llvm.org/D110258

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

[PATCH] D111797: [clang][scan-build] Use uname -s to detect the operating system.

[Frederic Cambus via Phabricator via cfe-commits]

fcambus created this revision.
fcambus added a reviewer: brad.
fcambus requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D111797

Files:
  clang/tools/scan-build/libexec/ccc-analyzer


Index: clang/tools/scan-build/libexec/ccc-analyzer
===
--- clang/tools/scan-build/libexec/ccc-analyzer
+++ clang/tools/scan-build/libexec/ccc-analyzer
@@ -72,7 +72,7 @@
 # If on OSX, use xcrun to determine the SDK root.
 my $UseXCRUN = 0;
 
-if (`uname -a` =~ m/Darwin/) {
+if (`uname -s` =~ m/Darwin/) {
   $DefaultCCompiler = 'clang';
   $DefaultCXXCompiler = 'clang++';
   # Older versions of OSX do not have xcrun to
@@ -80,7 +80,7 @@
   if (-x "/usr/bin/xcrun") {
 $UseXCRUN = 1;
   }
-} elsif (`uname -a` =~ m/OpenBSD/) {
+} elsif (`uname -s` =~ m/OpenBSD/) {
   $DefaultCCompiler = 'cc';
   $DefaultCXXCompiler = 'c++';
 } else {


Index: clang/tools/scan-build/libexec/ccc-analyzer
===
--- clang/tools/scan-build/libexec/ccc-analyzer
+++ clang/tools/scan-build/libexec/ccc-analyzer
@@ -72,7 +72,7 @@
 # If on OSX, use xcrun to determine the SDK root.
 my $UseXCRUN = 0;
 
-if (`uname -a` =~ m/Darwin/) {
+if (`uname -s` =~ m/Darwin/) {
   $DefaultCCompiler = 'clang';
   $DefaultCXXCompiler = 'clang++';
   # Older versions of OSX do not have xcrun to
@@ -80,7 +80,7 @@
   if (-x "/usr/bin/xcrun") {
 $UseXCRUN = 1;
   }
-} elsif (`uname -a` =~ m/OpenBSD/) {
+} elsif (`uname -s` =~ m/OpenBSD/) {
   $DefaultCCompiler = 'cc';
   $DefaultCXXCompiler = 'c++';
 } else {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109144: [SPIR-V] Add SPIR-V triple architecture and clang target info

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

In D109144#3063255 , @linjamaki wrote:

>> Can you explain what does this mean
>
> It was trying to clarify a potential misunderstanding of how programs are 
> compiled when HIPSPV is targeted:  For HIPSPV, the SPIR-V code generation is 
> done by the clang driver. When we compile HIP programs for HIPCL or the HIPLZ 
> runtime, we issue a single clang command such as this:
>
>   clang++ --offload=spirv64 foo.hip -l -o foo
>
> With this, the clang driver compiles the device side code to a SPIR-V binary 
> and then compiles host side code, and embeds the SPIR-V binary to the host 
> (fat) binary.
>
>> ? In the tests I can see the following `--offload=spirv64` which does feel 
>> like it is specified explicitly that the target is SPIR-V...
>
> For HIPSPV the `--offload` option is used to specify the device code target 
> but the end result is a host binary (e.g. x86_64) with device code (SPIR-V 
> binary) embedded in it. We need a way to specify the device code target to be 
> other than the currently fixed `amdgcn-amd-amdhsa` and using the `--offload` 
> switch is a solution we are suggesting here.

Thanks for the clarifications. So it seems that you are not expecting that the 
device target triple is being explicitly passed anywhere then and that means 
you pass the device triple implicitly? Although your `--offload` option does 
seem conceptually like a device target triple, so I wonder if better naming for 
it would be `--offload-target`? Would it work for you if we introduce SPIR-V 
triple explicitly and you use it as a device offload triple? It would probably 
makes sense to use the same triple to targeting SPIR-V generation by everyone? 
However I appreciate that OpenCL flow would be somewhat different since it 
doesn't have a split into host and device but only contains device compilation 
phase...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109144

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

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

[Mahesha S via Phabricator via cfe-commits]

hsmhsm updated this revision to Diff 379682.
hsmhsm added a comment.

Fix review comments by @rjmccall.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110257

Files:
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/CodeGenCUDA/builtins-amdgcn.cu
  clang/test/CodeGenCXX/amdgcn-automatic-variable.cpp
  clang/test/CodeGenCXX/amdgcn-func-arg.cpp
  clang/test/CodeGenCXX/builtin-amdgcn-atomic-inc-dec.cpp
  clang/test/CodeGenCXX/vla.cpp
  clang/test/CodeGenSYCL/address-space-deduction.cpp
  clang/test/OpenMP/amdgcn_target_init_temp_alloca.cpp

Index: clang/test/OpenMP/amdgcn_target_init_temp_alloca.cpp
===
--- clang/test/OpenMP/amdgcn_target_init_temp_alloca.cpp
+++ clang/test/OpenMP/amdgcn_target_init_temp_alloca.cpp
@@ -12,7 +12,9 @@
   int arr[N];
 
   // CHECK:  [[VAR_ADDR:%.+]] = alloca [100 x i32]*, align 8, addrspace(5)
+  // CHECK-NEXT: [[VAR2_ADDR:%.+]] = alloca i32, align 4, addrspace(5)
   // CHECK-NEXT: [[VAR_ADDR_CAST:%.+]] = addrspacecast [100 x i32]* addrspace(5)* [[VAR_ADDR]] to [100 x i32]**
+  // CHECK-NEXT: [[VAR2_ADDR_CAST:%.+]] = addrspacecast i32 addrspace(5)* [[VAR2_ADDR]] to i32*
   // CHECK:  store [100 x i32]* [[VAR:%.+]], [100 x i32]** [[VAR_ADDR_CAST]], align 8
 
 #pragma omp target
Index: clang/test/CodeGenSYCL/address-space-deduction.cpp
===
--- clang/test/CodeGenSYCL/address-space-deduction.cpp
+++ clang/test/CodeGenSYCL/address-space-deduction.cpp
@@ -1,34 +1,33 @@
 // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
 // RUN: %clang_cc1 -triple spir64 -fsycl-is-device -disable-llvm-passes -emit-llvm %s -o - | FileCheck %s
 
-
 // CHECK-LABEL: @_Z4testv(
 // CHECK-NEXT:  entry:
 // CHECK-NEXT:[[I:%.*]] = alloca i32, align 4
-// CHECK-NEXT:[[I_ASCAST:%.*]] = addrspacecast i32* [[I]] to i32 addrspace(4)*
 // CHECK-NEXT:[[PPTR:%.*]] = alloca i32 addrspace(4)*, align 8
-// CHECK-NEXT:[[PPTR_ASCAST:%.*]] = addrspacecast i32 addrspace(4)** [[PPTR]] to i32 addrspace(4)* addrspace(4)*
 // CHECK-NEXT:[[IS_I_PTR:%.*]] = alloca i8, align 1
-// CHECK-NEXT:[[IS_I_PTR_ASCAST:%.*]] = addrspacecast i8* [[IS_I_PTR]] to i8 addrspace(4)*
 // CHECK-NEXT:[[VAR23:%.*]] = alloca i32, align 4
-// CHECK-NEXT:[[VAR23_ASCAST:%.*]] = addrspacecast i32* [[VAR23]] to i32 addrspace(4)*
 // CHECK-NEXT:[[CP:%.*]] = alloca i8 addrspace(4)*, align 8
-// CHECK-NEXT:[[CP_ASCAST:%.*]] = addrspacecast i8 addrspace(4)** [[CP]] to i8 addrspace(4)* addrspace(4)*
 // CHECK-NEXT:[[ARR:%.*]] = alloca [42 x i32], align 4
-// CHECK-NEXT:[[ARR_ASCAST:%.*]] = addrspacecast [42 x i32]* [[ARR]] to [42 x i32] addrspace(4)*
 // CHECK-NEXT:[[CPP:%.*]] = alloca i8 addrspace(4)*, align 8
-// CHECK-NEXT:[[CPP_ASCAST:%.*]] = addrspacecast i8 addrspace(4)** [[CPP]] to i8 addrspace(4)* addrspace(4)*
 // CHECK-NEXT:[[APTR:%.*]] = alloca i32 addrspace(4)*, align 8
-// CHECK-NEXT:[[APTR_ASCAST:%.*]] = addrspacecast i32 addrspace(4)** [[APTR]] to i32 addrspace(4)* addrspace(4)*
 // CHECK-NEXT:[[STR:%.*]] = alloca i8 addrspace(4)*, align 8
-// CHECK-NEXT:[[STR_ASCAST:%.*]] = addrspacecast i8 addrspace(4)** [[STR]] to i8 addrspace(4)* addrspace(4)*
 // CHECK-NEXT:[[PHI_STR:%.*]] = alloca i8 addrspace(4)*, align 8
-// CHECK-NEXT:[[PHI_STR_ASCAST:%.*]] = addrspacecast i8 addrspace(4)** [[PHI_STR]] to i8 addrspace(4)* addrspace(4)*
 // CHECK-NEXT:[[SELECT_NULL:%.*]] = alloca i8 addrspace(4)*, align 8
-// CHECK-NEXT:[[SELECT_NULL_ASCAST:%.*]] = addrspacecast i8 addrspace(4)** [[SELECT_NULL]] to i8 addrspace(4)* addrspace(4)*
 // CHECK-NEXT:[[SELECT_STR_TRIVIAL1:%.*]] = alloca i8 addrspace(4)*, align 8
-// CHECK-NEXT:[[SELECT_STR_TRIVIAL1_ASCAST:%.*]] = addrspacecast i8 addrspace(4)** [[SELECT_STR_TRIVIAL1]] to i8 addrspace(4)* addrspace(4)*
 // CHECK-NEXT:[[SELECT_STR_TRIVIAL2:%.*]] = alloca i8 addrspace(4)*, align 8
+// CHECK-NEXT:[[I_ASCAST:%.*]] = addrspacecast i32* [[I]] to i32 addrspace(4)*
+// CHECK-NEXT:[[PPTR_ASCAST:%.*]] = addrspacecast i32 addrspace(4)** [[PPTR]] to i32 addrspace(4)* addrspace(4)*
+// CHECK-NEXT:[[IS_I_PTR_ASCAST:%.*]] = addrspacecast i8* [[IS_I_PTR]] to i8 addrspace(4)*
+// CHECK-NEXT:[[VAR23_ASCAST:%.*]] = addrspacecast i32* [[VAR23]] to i32 addrspace(4)*
+// CHECK-NEXT:[[CP_ASCAST:%.*]] = addrspacecast i8 addrspace(4)** [[CP]] to i8 addrspace(4)* addrspace(4)*
+// CHECK-NEXT:[[ARR_ASCAST:%.*]] = addrspacecast [42 x i32]* [[ARR]] to [42 x i32] addrspace(4)*
+// CHECK-NEXT:[[CPP_ASCAST:%.*]] = addrspacecast i8 addrspace(4)** [[CPP]] to i8 addrspace(4)* addrspace(4)*
+// CHECK-NEXT:[[APTR_ASCAST:%.*]] = addrspacecast i32 addrspace(4)** [[APTR]] to i32 addrspace(4)* addrspace(4)*
+// 

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

[Mahesha S via Phabricator via cfe-commits]

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



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

arichardson wrote:
> Shouldn't this use `cast` instead?
You are right. But, in the updated patch, this code does not exist anymore.



Comment at: clang/lib/CodeGen/CodeGenFunction.h:392
+  /// order immediately after all static allocas.
+  llvm::BasicBlock::iterator AllocaAddrSpaceInsertPt;
+

rjmccall wrote:
> Please call this something like `PostAllocaInsertPt`.  Instead of eagerly 
> creating it, please create it lazily: add an accessor like 
> `getPostAllocaInsertPoint()` which creates (and saves here) an instruction 
> that immediately follows `AllocaInsertPt` if this is currently null.  I think 
> you should make your own instruction so that we don't mess up any code that 
> might rely on temporarily creating and then removing dead instructions.
> 
> Please use an `llvm::AssertingVH`.  I think that can 
> handle holding a null value.
> 
> The comment here should be more general, like "a place in the prologue where 
> code can be inserted that will be dominated by all the static allocas."  You 
> don't need to talk about  `addrspacecast`s specifically; that's just one 
> possible use case for this.
> 
> Also, it's either "`addrspacecast`" (using the IR name of the operation) or 
> "address space cast" (writing out the operation in normal English words); 
> don't run together `addressspace` as if it were a keyword when it isn't.
Thanks. Fixed the above review comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110257

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

[PATCH] D111778: [WIP][X86] Update CPU_SPECIFIC list.

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

Supporting these types requires changes to the library so that we can check 
these, right?  Do you have the library changes for these as well?  The 
constants used to check for these features/etc needs to be present in the glibc 
library.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111778

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

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

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

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

I love this! The coverage is great and looks good.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110913

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

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

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

steakhal added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:2126-2130
+  // Initiate the reorganization of the equality information. E.g., if we
+  // have `c + 1 == 0` then we'd like to express that `c == -1`. It makes
+  // sense to do this only with `SymIntExpr`s.
+  // TODO Handle `IntSymExpr` as well, once computeAdjustment can handle
+  // them.

Can the simplification of a `SymSymExpr` result in `IntSymExpr`? If it can 
happen, then we could see such instances and we should do the right thing with 
them as well.
WDYT?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111642

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

[PATCH] D111790: [AArch64][Driver][SVE] Allow -msve-vector-bits=+ syntax to mean no maximum vscale

[Bradley Smith via Phabricator via cfe-commits]

bsmith updated this revision to Diff 379701.
bsmith added a comment.

- Remove mention of 128-bit chunks from help texts
- Allow any positive integer value for -mvscale-{min,max}, not just powers of 2


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111790

Files:
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/AST/ASTContext.cpp
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CodeGen/aarch64-sve-acle-__ARM_FEATURE_SVE_VECTOR_OPERATORS.c
  clang/test/CodeGen/aarch64-sve-acle-__ARM_FEATURE_SVE_VECTOR_OPERATORS.cpp
  clang/test/CodeGen/aarch64-sve-vector-bits-codegen.c
  clang/test/CodeGen/arm-sve-vector-bits-vscale-range.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-bitcast.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-call.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-cast.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-codegen.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-globals.c
  clang/test/CodeGen/attr-arm-sve-vector-bits-types.c
  clang/test/CodeGenCXX/aarch64-mangle-sve-fixed-vectors.cpp
  clang/test/CodeGenCXX/aarch64-sve-fixedtypeinfo.cpp
  clang/test/Driver/aarch64-sve-vector-bits.c
  clang/test/Sema/aarch64-sve-explicit-casts-fixed-size.c
  clang/test/Sema/aarch64-sve-lax-vector-conversions.c
  clang/test/Sema/attr-arm-sve-vector-bits.c
  clang/test/SemaCXX/aarch64-sve-explicit-casts-fixed-size.cpp
  clang/test/SemaCXX/aarch64-sve-lax-vector-conversions.cpp
  clang/test/SemaCXX/attr-arm-sve-vector-bits.cpp

Index: clang/test/SemaCXX/attr-arm-sve-vector-bits.cpp
===
--- clang/test/SemaCXX/attr-arm-sve-vector-bits.cpp
+++ clang/test/SemaCXX/attr-arm-sve-vector-bits.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -target-feature +bf16 -ffreestanding -fsyntax-only -verify -std=c++11 -msve-vector-bits=512 -fallow-half-arguments-and-returns -Wconversion %s
+// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -target-feature +bf16 -ffreestanding -fsyntax-only -verify -std=c++11 -mvscale-min=4 -mvscale-max=4 -fallow-half-arguments-and-returns -Wconversion %s
 // expected-no-diagnostics
 
 #include 
Index: clang/test/SemaCXX/aarch64-sve-lax-vector-conversions.cpp
===
--- clang/test/SemaCXX/aarch64-sve-lax-vector-conversions.cpp
+++ clang/test/SemaCXX/aarch64-sve-lax-vector-conversions.cpp
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -msve-vector-bits=512 -flax-vector-conversions=none -fallow-half-arguments-and-returns -ffreestanding -fsyntax-only -verify=lax-vector-none %s
-// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -msve-vector-bits=512 -flax-vector-conversions=integer -fallow-half-arguments-and-returns -ffreestanding -fsyntax-only -verify=lax-vector-integer %s
-// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -msve-vector-bits=512 -flax-vector-conversions=all -fallow-half-arguments-and-returns -ffreestanding -fsyntax-only -verify=lax-vector-all %s
+// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -mvscale-min=4 -mvscale-max=4 -flax-vector-conversions=none -fallow-half-arguments-and-returns -ffreestanding -fsyntax-only -verify=lax-vector-none %s
+// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -mvscale-min=4 -mvscale-max=4 -flax-vector-conversions=integer -fallow-half-arguments-and-returns -ffreestanding -fsyntax-only -verify=lax-vector-integer %s
+// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -mvscale-min=4 -mvscale-max=4 -flax-vector-conversions=all -fallow-half-arguments-and-returns -ffreestanding -fsyntax-only -verify=lax-vector-all %s
 
 #include 
 
Index: clang/test/SemaCXX/aarch64-sve-explicit-casts-fixed-size.cpp
===
--- clang/test/SemaCXX/aarch64-sve-explicit-casts-fixed-size.cpp
+++ clang/test/SemaCXX/aarch64-sve-explicit-casts-fixed-size.cpp
@@ -1,8 +1,8 @@
-// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -msve-vector-bits=128 -flax-vector-conversions=none -fallow-half-arguments-and-returns -ffreestanding -fsyntax-only -verify %s
-// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -msve-vector-bits=256 -flax-vector-conversions=none -fallow-half-arguments-and-returns -ffreestanding -fsyntax-only -verify %s
-// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -msve-vector-bits=512 -flax-vector-conversions=none -fallow-half-arguments-and-returns -ffreestanding -fsyntax-only -verify %s
-// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -msve-vector-bits=1024 -flax-vector-conversions=none -fallo

[PATCH] D111805: [Driver][NetBSD] Use T reference instead of getToolChain().getTriple().

[Frederic Cambus via Phabricator via cfe-commits]

fcambus created this revision.
fcambus added reviewers: krytarowski, mgorny.
Herald added a subscriber: fedor.sergeev.
fcambus requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D111805

Files:
  clang/lib/Driver/ToolChains/NetBSD.cpp


Index: clang/lib/Driver/ToolChains/NetBSD.cpp
===
--- clang/lib/Driver/ToolChains/NetBSD.cpp
+++ clang/lib/Driver/ToolChains/NetBSD.cpp
@@ -32,6 +32,7 @@
   const toolchains::NetBSD &ToolChain =
 static_cast(getToolChain());
   const Driver &D = ToolChain.getDriver();
+  const llvm::Triple &T = ToolChain.getTriple();
 
   claimNoWarnArgs(Args);
   ArgStringList CmdArgs;
@@ -49,7 +50,7 @@
 StringRef MArch, MCPU;
 arm::getARMArchCPUFromArgs(Args, MArch, MCPU, /*FromAs*/ true);
 std::string Arch =
-arm::getARMTargetCPU(MCPU, MArch, ToolChain.getTriple());
+arm::getARMTargetCPU(MCPU, MArch, T);
 CmdArgs.push_back(Args.MakeArgString("-mcpu=" + Arch));
 break;
   }
@@ -60,7 +61,7 @@
   case llvm::Triple::mips64el: {
 StringRef CPUName;
 StringRef ABIName;
-mips::getMipsCPUAndABI(Args, ToolChain.getTriple(), CPUName, ABIName);
+mips::getMipsCPUAndABI(Args, T, CPUName, ABIName);
 
 CmdArgs.push_back("-march");
 CmdArgs.push_back(CPUName.data());
@@ -68,7 +69,7 @@
 CmdArgs.push_back("-mabi");
 CmdArgs.push_back(mips::getGnuCompatibleMipsABIName(ABIName).data());
 
-if (ToolChain.getTriple().isLittleEndian())
+if (T.isLittleEndian())
   CmdArgs.push_back("-EL");
 else
   CmdArgs.push_back("-EB");
@@ -80,18 +81,16 @@
   case llvm::Triple::sparc:
   case llvm::Triple::sparcel: {
 CmdArgs.push_back("-32");
-std::string CPU = getCPUName(D, Args, ToolChain.getTriple());
-CmdArgs.push_back(
-sparc::getSparcAsmModeForCPU(CPU, ToolChain.getTriple()));
+std::string CPU = getCPUName(D, Args, T);
+CmdArgs.push_back(sparc::getSparcAsmModeForCPU(CPU, T));
 AddAssemblerKPIC(ToolChain, Args, CmdArgs);
 break;
   }
 
   case llvm::Triple::sparcv9: {
 CmdArgs.push_back("-64");
-std::string CPU = getCPUName(D, Args, ToolChain.getTriple());
-CmdArgs.push_back(
-sparc::getSparcAsmModeForCPU(CPU, ToolChain.getTriple()));
+std::string CPU = getCPUName(D, Args, T);
+CmdArgs.push_back(sparc::getSparcAsmModeForCPU(CPU, T));
 AddAssemblerKPIC(ToolChain, Args, CmdArgs);
 break;
   }
@@ -122,6 +121,8 @@
   const toolchains::NetBSD &ToolChain =
 static_cast(getToolChain());
   const Driver &D = ToolChain.getDriver();
+  const llvm::Triple &T = ToolChain.getTriple();
+
   ArgStringList CmdArgs;
 
   if (!D.SysRoot.empty())
@@ -156,7 +157,7 @@
   case llvm::Triple::arm:
   case llvm::Triple::thumb:
 CmdArgs.push_back("-m");
-switch (ToolChain.getTriple().getEnvironment()) {
+switch (T.getEnvironment()) {
 case llvm::Triple::EABI:
 case llvm::Triple::GNUEABI:
   CmdArgs.push_back("armelf_nbsd_eabi");
@@ -174,7 +175,7 @@
   case llvm::Triple::thumbeb:
 arm::appendBE8LinkFlag(Args, CmdArgs, ToolChain.getEffectiveTriple());
 CmdArgs.push_back("-m");
-switch (ToolChain.getTriple().getEnvironment()) {
+switch (T.getEnvironment()) {
 case llvm::Triple::EABI:
 case llvm::Triple::GNUEABI:
   CmdArgs.push_back("armelfb_nbsd_eabi");
@@ -271,7 +272,7 @@
   }
 
   unsigned Major, Minor, Micro;
-  ToolChain.getTriple().getOSVersion(Major, Minor, Micro);
+  T.getOSVersion(Major, Minor, Micro);
   bool useLibgcc = true;
   if (Major >= 7 || Major == 0) {
 switch (ToolChain.getArch()) {


Index: clang/lib/Driver/ToolChains/NetBSD.cpp
===
--- clang/lib/Driver/ToolChains/NetBSD.cpp
+++ clang/lib/Driver/ToolChains/NetBSD.cpp
@@ -32,6 +32,7 @@
   const toolchains::NetBSD &ToolChain =
 static_cast(getToolChain());
   const Driver &D = ToolChain.getDriver();
+  const llvm::Triple &T = ToolChain.getTriple();
 
   claimNoWarnArgs(Args);
   ArgStringList CmdArgs;
@@ -49,7 +50,7 @@
 StringRef MArch, MCPU;
 arm::getARMArchCPUFromArgs(Args, MArch, MCPU, /*FromAs*/ true);
 std::string Arch =
-arm::getARMTargetCPU(MCPU, MArch, ToolChain.getTriple());
+arm::getARMTargetCPU(MCPU, MArch, T);
 CmdArgs.push_back(Args.MakeArgString("-mcpu=" + Arch));
 break;
   }
@@ -60,7 +61,7 @@
   case llvm::Triple::mips64el: {
 StringRef CPUName;
 StringRef ABIName;
-mips::getMipsCPUAndABI(Args, ToolChain.getTriple(), CPUName, ABIName);
+mips::getMipsCPUAndABI(Args, T, CPUName, ABIName);
 
 CmdArgs.push_back("-march");
 CmdArgs.push_back(CPUName.data());
@@ -68,7 +69,7 @@
 CmdArgs.push_back("-mabi");
 CmdArgs.push_back(mips::getGnuCompatibleMipsABIName(ABIName).data());
 
-if (ToolChain.getTriple().isLittleEndian())
+if (

[PATCH] D111443: [Driver] Fix ToolChain::getSanitizerArgs

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

In D111443#3062139 , @eugenis wrote:

> Right, but a cache for SanitizerArgs is not enough to avoid repeated 
> diagnostics, is it? Ex. if I request a non-existing sanitizer, I think I 
> would get errors from host arg parsing, as well as from each of device1 and 
> device2, because each device will have a unique ArgList.
>
> Is it even possible for the driver to introduce new diagnostics in offload 
> SanitizerArgs parsing? Is it possible to catch those cases ahead of time, 
> when parsing SanitizerArgs for the first time, by looking at a target triple 
> or something? That would be the most user friendly approach.

I think it makes sense to assume offloading toolchain will not introduce extra 
diagnostics inside SanitizerArgs than the default toolchain, therefore it 
should be OK to let the default toolchain check sanitizer args for once. I will 
try make that change.


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

https://reviews.llvm.org/D111443

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

[PATCH] D107769: [OpenCL] Make generic addrspace optional for -fdeclare-opencl-builtins

[Sven van Haastregt via Phabricator via cfe-commits]

svenvh added a comment.

In D107769#2967565 , @Anastasia wrote:

> In D107769#2960441 , @svenvh wrote:
>
>> I have done an alternative spin of this patch: instead of introducing 
>> `RequireDisabledExtension`, simply always make the `private`, `global`, and 
>> `local` overloads available.  This makes tablegen diverge from `opencl-c.h` 
>> though.  Perhaps we should also always add make the `private`, `global`, and 
>> `local` overloads available in `opencl-c.h`?
>
> Yes, we could do this indeed as a clang extension. I don't think this will 
> impact the user code. However, this means vendors will have to add 
> definitions for extra overloads in OpenCL 2.0 mode?

I wonder if making the `private`, `global`, and `local` overloads always 
available would even be considered an extension.  Unless I overlooked 
something, I cannot find anything in the spec saying that the `private`, 
`global`, and `local` overloads should **not** be available when a `generic` 
overload is available (even though this is what Clang has always done)?

Making all overloads always available in e.g. CL2.0 mode will indeed affect the 
generated calls, which means the definitions should be available when consuming 
the generated IR.


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

https://reviews.llvm.org/D107769

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

[PATCH] D109825: [AArch64]Enabling Cortex-A510 Support

[Mubashar Ahmad via Phabricator via cfe-commits]

mubashar_ updated this revision to Diff 379713.
mubashar_ marked 2 inline comments as done.
mubashar_ added a comment.

Added crypto and no-crypto tests for -mcpu and added new section for Arm and 
AArch64 support in release notes.


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

https://reviews.llvm.org/D109825

Files:
  clang/docs/ReleaseNotes.rst
  clang/test/Driver/aarch64-cpus.c
  llvm/include/llvm/Support/AArch64TargetParser.def
  llvm/lib/Target/AArch64/AArch64.td
  llvm/lib/Target/AArch64/AArch64Subtarget.cpp
  llvm/lib/Target/AArch64/AArch64Subtarget.h
  llvm/unittests/Support/TargetParserTest.cpp

Index: llvm/unittests/Support/TargetParserTest.cpp
===
--- llvm/unittests/Support/TargetParserTest.cpp
+++ llvm/unittests/Support/TargetParserTest.cpp
@@ -898,6 +898,17 @@
  AArch64::AEK_RDM | AArch64::AEK_FP16 |
  AArch64::AEK_DOTPROD | AArch64::AEK_RCPC,
  "8.2-A"),
+ARMCPUTestParams("cortex-a510", "armv9-a", "neon-fp-armv8",
+ AArch64::AEK_CRC | AArch64::AEK_FP |
+ AArch64::AEK_SIMD | AArch64::AEK_RAS |
+ AArch64::AEK_LSE | AArch64::AEK_RDM |
+ AArch64::AEK_RCPC | AArch64::AEK_DOTPROD |
+ AArch64::AEK_SVE2 | AArch64::AEK_BF16 |
+ AArch64::AEK_I8MM | AArch64::AEK_SVE2BITPERM |
+ AArch64::AEK_PAUTH | AArch64::AEK_MTE |
+ AArch64::AEK_SSBS | AArch64::AEK_FP16FML |
+ AArch64::AEK_SB,
+ "9-A"),
 ARMCPUTestParams("cortex-a57", "armv8-a", "crypto-neon-fp-armv8",
  AArch64::AEK_CRC | AArch64::AEK_CRYPTO |
  AArch64::AEK_FP | AArch64::AEK_SIMD,
@@ -1178,7 +1189,7 @@
  AArch64::AEK_LSE | AArch64::AEK_RDM,
  "8.2-A")));
 
-static constexpr unsigned NumAArch64CPUArchs = 48;
+static constexpr unsigned NumAArch64CPUArchs = 49;
 
 TEST(TargetParserTest, testAArch64CPUArchList) {
   SmallVector List;
Index: llvm/lib/Target/AArch64/AArch64Subtarget.h
===
--- llvm/lib/Target/AArch64/AArch64Subtarget.h
+++ llvm/lib/Target/AArch64/AArch64Subtarget.h
@@ -50,6 +50,7 @@
 CortexA35,
 CortexA53,
 CortexA55,
+CortexA510,
 CortexA57,
 CortexA65,
 CortexA72,
Index: llvm/lib/Target/AArch64/AArch64Subtarget.cpp
===
--- llvm/lib/Target/AArch64/AArch64Subtarget.cpp
+++ llvm/lib/Target/AArch64/AArch64Subtarget.cpp
@@ -78,6 +78,7 @@
 break;
   case CortexA53:
   case CortexA55:
+  case CortexA510:
 PrefFunctionLogAlignment = 4;
 break;
   case CortexA57:
Index: llvm/lib/Target/AArch64/AArch64.td
===
--- llvm/lib/Target/AArch64/AArch64.td
+++ llvm/lib/Target/AArch64/AArch64.td
@@ -630,6 +630,22 @@
FeatureFuseAddress,
]>;
 
+def ProcA510: SubtargetFeature<"a510", "ARMProcFamily", "CortexA510",
+   "Cortex-A510 ARM processors", [
+   HasV9_0aOps,
+   FeatureNEON,
+   FeaturePerfMon,
+   FeatureMatMulInt8,
+   FeatureBF16,
+   FeatureAM,
+   FeatureMTE,
+   FeatureETE,
+   FeatureSVE2BitPerm,
+   FeatureFP16FML,
+   FeatureFuseAES,
+   FeaturePostRAScheduler
+   ]>;
+
 def ProcA57 : SubtargetFeature<"a57", "ARMProcFamily", "CortexA57",
"Cortex-A57 ARM processors", [
FeatureBalanceFPOps,
@@ -1186,6 +1202,7 @@
 def : ProcessorModel<"cortex-a34", CortexA53Model, [ProcA35]>;
 def : ProcessorModel<"cortex-a53", CortexA53Model, [ProcA53]>;
 def : ProcessorModel<"cortex-a55", CortexA55Model, [ProcA55]>;
+def : ProcessorModel<"cortex-a510", CortexA55Model, [ProcA510]>;
 def : ProcessorModel<"cortex-a57", CortexA57Model, [ProcA57]>;
 def : ProcessorModel<"cortex-a65", CortexA53Model, [ProcA65]>;
 def : ProcessorModel<"cortex-a65ae", CortexA53Model, [ProcA65]>;
Index: llvm/include/llvm/Support/AArch64TargetParser.def
===
--- llvm/include/llvm/Support/AArch64TargetParser.def
+++ llvm/include/llvm/Support/AArch64TargetParser.

[PATCH] D110641: Implement P0857R0 -Part B: requires clause for template-template params

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

Ping!  Does anyone have any feedback on this?  I'd really like to start getting 
us caught up on standards implementation, and this seems like it might be an 
easy win (unless someone on the list knows why it is just plain wrong/more 
complicated than I think!).


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

https://reviews.llvm.org/D110641

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

[PATCH] D109825: [AArch64]Enabling Cortex-A510 Support

[Mubashar Ahmad via Phabricator via cfe-commits]

mubashar_ updated this revision to Diff 379717.
mubashar_ marked an inline comment as done.
mubashar_ added a comment.

Corrected PAUTH duplication mistake.


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

https://reviews.llvm.org/D109825

Files:
  clang/docs/ReleaseNotes.rst
  clang/test/Driver/aarch64-cpus.c
  llvm/include/llvm/Support/AArch64TargetParser.def
  llvm/lib/Target/AArch64/AArch64.td
  llvm/lib/Target/AArch64/AArch64Subtarget.cpp
  llvm/lib/Target/AArch64/AArch64Subtarget.h
  llvm/unittests/Support/TargetParserTest.cpp

Index: llvm/unittests/Support/TargetParserTest.cpp
===
--- llvm/unittests/Support/TargetParserTest.cpp
+++ llvm/unittests/Support/TargetParserTest.cpp
@@ -898,6 +898,17 @@
  AArch64::AEK_RDM | AArch64::AEK_FP16 |
  AArch64::AEK_DOTPROD | AArch64::AEK_RCPC,
  "8.2-A"),
+ARMCPUTestParams("cortex-a510", "armv9-a", "neon-fp-armv8",
+ AArch64::AEK_CRC | AArch64::AEK_FP |
+ AArch64::AEK_SIMD | AArch64::AEK_RAS |
+ AArch64::AEK_LSE | AArch64::AEK_RDM |
+ AArch64::AEK_RCPC | AArch64::AEK_DOTPROD |
+ AArch64::AEK_SVE2 | AArch64::AEK_BF16 |
+ AArch64::AEK_I8MM | AArch64::AEK_SVE2BITPERM |
+ AArch64::AEK_PAUTH | AArch64::AEK_MTE |
+ AArch64::AEK_SSBS | AArch64::AEK_FP16FML |
+ AArch64::AEK_SB,
+ "9-A"),
 ARMCPUTestParams("cortex-a57", "armv8-a", "crypto-neon-fp-armv8",
  AArch64::AEK_CRC | AArch64::AEK_CRYPTO |
  AArch64::AEK_FP | AArch64::AEK_SIMD,
@@ -1178,7 +1189,7 @@
  AArch64::AEK_LSE | AArch64::AEK_RDM,
  "8.2-A")));
 
-static constexpr unsigned NumAArch64CPUArchs = 48;
+static constexpr unsigned NumAArch64CPUArchs = 49;
 
 TEST(TargetParserTest, testAArch64CPUArchList) {
   SmallVector List;
Index: llvm/lib/Target/AArch64/AArch64Subtarget.h
===
--- llvm/lib/Target/AArch64/AArch64Subtarget.h
+++ llvm/lib/Target/AArch64/AArch64Subtarget.h
@@ -50,6 +50,7 @@
 CortexA35,
 CortexA53,
 CortexA55,
+CortexA510,
 CortexA57,
 CortexA65,
 CortexA72,
Index: llvm/lib/Target/AArch64/AArch64Subtarget.cpp
===
--- llvm/lib/Target/AArch64/AArch64Subtarget.cpp
+++ llvm/lib/Target/AArch64/AArch64Subtarget.cpp
@@ -78,6 +78,7 @@
 break;
   case CortexA53:
   case CortexA55:
+  case CortexA510:
 PrefFunctionLogAlignment = 4;
 break;
   case CortexA57:
Index: llvm/lib/Target/AArch64/AArch64.td
===
--- llvm/lib/Target/AArch64/AArch64.td
+++ llvm/lib/Target/AArch64/AArch64.td
@@ -630,6 +630,22 @@
FeatureFuseAddress,
]>;
 
+def ProcA510: SubtargetFeature<"a510", "ARMProcFamily", "CortexA510",
+   "Cortex-A510 ARM processors", [
+   HasV9_0aOps,
+   FeatureNEON,
+   FeaturePerfMon,
+   FeatureMatMulInt8,
+   FeatureBF16,
+   FeatureAM,
+   FeatureMTE,
+   FeatureETE,
+   FeatureSVE2BitPerm,
+   FeatureFP16FML,
+   FeatureFuseAES,
+   FeaturePostRAScheduler
+   ]>;
+
 def ProcA57 : SubtargetFeature<"a57", "ARMProcFamily", "CortexA57",
"Cortex-A57 ARM processors", [
FeatureBalanceFPOps,
@@ -1186,6 +1202,7 @@
 def : ProcessorModel<"cortex-a34", CortexA53Model, [ProcA35]>;
 def : ProcessorModel<"cortex-a53", CortexA53Model, [ProcA53]>;
 def : ProcessorModel<"cortex-a55", CortexA55Model, [ProcA55]>;
+def : ProcessorModel<"cortex-a510", CortexA55Model, [ProcA510]>;
 def : ProcessorModel<"cortex-a57", CortexA57Model, [ProcA57]>;
 def : ProcessorModel<"cortex-a65", CortexA53Model, [ProcA65]>;
 def : ProcessorModel<"cortex-a65ae", CortexA53Model, [ProcA65]>;
Index: llvm/include/llvm/Support/AArch64TargetParser.def
===
--- llvm/include/llvm/Support/AArch64TargetParser.def
+++ llvm/include/llvm/Support/AArch64TargetParser.def
@@ -144,6 +144,10 @@
  (AArch64::AEK_CRC))
 AARCH64_CPU

[PATCH] D109825: [AArch64]Enabling Cortex-A510 Support

[Mubashar Ahmad via Phabricator via cfe-commits]

mubashar_ marked an inline comment as done.
mubashar_ added inline comments.



Comment at: clang/docs/ReleaseNotes.rst:86
 
+- Support has been added for the following processors (command-line 
identifiers in parentheses):
+  - Arm Cortex-A510 (cortex-a510)

dmgreen wrote:
> dmgreen wrote:
> > Can you add an Arm section below and move this to it.
> This still needs doing. Also please add a line to the arm section saying 
> "Added support for the Armv9-A, Armv9.1-A and Armv9.2-A architectures."
> 
> It looks like there are some llvm release notes in llvm/docs/ReleaseNotes.rst 
> too, that could have a line added.
I didn't add support for these architectures. This may already be in its own 
commit.


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

https://reviews.llvm.org/D109825

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

[PATCH] D109825: [AArch64]Enabling Cortex-A510 Support

[Dave Green via Phabricator via cfe-commits]

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

Thanks for the changes. Nice working pulling this into shape.

LGTM




Comment at: llvm/include/llvm/Support/AArch64TargetParser.def:149
+ (AArch64::AEK_BF16 | AArch64::AEK_I8MM | 
AArch64::AEK_SVE2BITPERM |
+  AArch64::AEK_PAUTH | AArch64::AEK_PAUTH | AArch64::AEK_MTE |
+  AArch64::AEK_SSBS | AArch64::AEK_SB | AArch64::AEK_FP16FML))

dmgreen wrote:
> AEK_PAUTH is twice here.
Can you make sure you remove the second PAUTH here before committing.


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

https://reviews.llvm.org/D109825

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

[PATCH] D90121: clang-format: Add a consumer to diagnostics engine

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

@thakis , At the back of my mind is those people who always say "Measure, 
Measure, Measure"...

This issue still plagues us, we constantly get bugs reported that come back to 
this.  
(https://bugs.llvm.org/show_bug.cgi?id=52021,https://bugs.llvm.org/show_bug.cgi?id=42014)

So I decided I should look into the concerns with us fixing this issue.

I decided to do 3 tests:

- a) Build current tip of main
- b) Apply this FrontEnd fix
- c) Move TextDiagnosticPrinter (and dependencies) into lib/Basic

I took a look and in its simplest form moving TextDiagnosticPrinter.cpp to 
lib/Basic but also requires DiagnosticRender.cpp and TextDiagnostic.cpp to also 
move to lib/Basic too,

But DiagnosticRender.cpp has a dependency on lib/Edit so clang-format now needs 
that as a dependency, is that better/worse than having a dependency on 
lib/FrontEnd? (not sure why I don't have to provide "Edit" as a dependency when 
including FrontEnd!)

For each test, I want to check

- a) size of the executable produced (debug/release)
- b) number of build dependencies (from ninja after ninja clean)

The size of the executable I assume is a concern as this impacts the runtime of 
clang-format as the system loads the module,
The number of build dependencies comes down to how quickly developers working 
on clang-format can rebuild.

I'm not concerning myself with the final "link" time of clang-format, as its 
relatively trivial on a modern machine, and nothing in comparison to building 
from clean.

Firstly I think we should recognize that this "crash" against a read-only file 
IS a problem that most of us will see from time to time and at best
its annoying. So I think there is enough momentum for us to have a solution of 
one sort of another.

**Build speeds**

Build speeds are important if you are a LLVM developer as you don't really want 
to have to keep rebuilding, I personally use ninja on Windows
having given up using vs projects generated by cmake years ago as being way too 
slow in the first place.

Ninja will give me the number of "targets" needed to compile, rather than 
timing it, I'll simply work on the assumption that "less is best"

  $ ninja clang-format
  [698/1298] Building CXX object 
lib\Object\CMakeFiles\LLVMObject.dir\SymbolicFile.cpp.obj

Before building each of the targets I perform a "ninja clean" so that hopefully 
the build that follows shows me how many targets I needed

1. Using the current tip of master, the number of targets to build clang-format 
sits at 608
2. If I apply this FrontEnd patch D90121: clang-format: Add a consumer to 
diagnostics engine  it rises to `1352`

3 )If I apply a patch that moves just 
`TextDiagnosticPrinter/TextDiagnostic/DiagnosticRender` into `lib/Basic` then 
the number is `1298`

**Executable Size**

For Completeness I built both Debug and Release (mainly because I live in Debug 
as I work on clang-format, but the releases are Release (i assume))

**Debug (clang-format)**

For Debug there seems no benefit for moving the code out of FrontEnd into Basic

  -rwxr-xr-x 1  17425920 Oct 14 14:48 clang-format-frontend.exe   (Debug)
  -rwxr-xr-x 1  17425920 Oct 14 14:40 clang-format.basic.exe (Debug)
  -rwxr-xr-x 1  17171968 Oct 14 14:44 clang-format.original.exe (Debug)

The modified debug binaries are only 1.5% larger.

**Release (clang-format)**

For Release the Basic version was actually larger.

  -rwxr-xr-x 1   2601472 Oct 14 15:17 clang-format-release.basic.exe   (Release)
  -rwxr-xr-x 1   2600960 Oct 14 15:12 clang-format-release-frontend.exe 
(Release)
  -rwxr-xr-x 1   2041344 Oct 14 15:14 clang-format-release.orginal.exe (Release)

With both Basic and FrontEnd release binaries being `~27%` larger.

**Conclusion**

This bug is annoying.

1. I just don't think an approach that moves the files into Basic is the 
solution.



- a) It requires multiple CMakeFile changes
- b) We have to leave header stubs lying around (or fix all the other tools 
that might include them and that is ugly)
- c) The binary is actually larger (go figure!)
- d) The number of files to be build is 213% as many as not having this fix, 
even if its ~10% less than the frontend fix (thats not worth the difference)



2. Frontend fix is the simplest solution (and has been sent for review at least 
3 times that I can find)



- a) Its slightly annoying because I keep having to defend why we don't want to 
fix it!
- b) Its 222% more files during the build cycle (however we don't build clean 
every time when building clang-format) so for a clang-format developer the 
impact is likely minimal
- c) The binaries are larger, less than the basic but still ~27% larger (which 
one could see as causing a slowdown on startup, although I have not measured 
that)

I'm kind of the opinion that we should resolve the crash before worrying about 
binary size aspect. Like I said I primarily use debug builds of clang-format
even during my working day so that I am 

[PATCH] D111468: [clang] Capture Framework when HeaderSearch is resolved via headermap

[Cyndy Ishida via Phabricator via cfe-commits]

cishida updated this revision to Diff 379721.
cishida added a comment.

Fix windows build.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111468

Files:
  clang/lib/Lex/HeaderSearch.cpp
  clang/unittests/Lex/HeaderSearchTest.cpp

Index: clang/unittests/Lex/HeaderSearchTest.cpp
===
--- clang/unittests/Lex/HeaderSearchTest.cpp
+++ clang/unittests/Lex/HeaderSearchTest.cpp
@@ -18,6 +18,7 @@
 #include "clang/Lex/HeaderSearch.h"
 #include "clang/Lex/HeaderSearchOptions.h"
 #include "clang/Serialization/InMemoryModuleCache.h"
+#include "llvm/Support/MemoryBuffer.h"
 #include "gtest/gtest.h"
 
 namespace clang {
@@ -47,7 +48,8 @@
   }
 
   void addHeaderMap(llvm::StringRef Filename,
-std::unique_ptr Buf) {
+std::unique_ptr Buf,
+bool isAngled = false) {
 VFS->addFile(Filename, 0, std::move(Buf), /*User=*/None, /*Group=*/None,
  llvm::sys::fs::file_type::regular_file);
 auto FE = FileMgr.getFile(Filename, true);
@@ -58,7 +60,7 @@
 HMap = HeaderMap::Create(*FE, FileMgr);
 auto DL =
 DirectoryLookup(HMap.get(), SrcMgr::C_User, /*isFramework=*/false);
-Search.AddSearchPath(DL, /*isAngled=*/false);
+Search.AddSearchPath(DL, isAngled);
   }
 
   IntrusiveRefCntPtr VFS;
@@ -179,5 +181,48 @@
 "d.h");
 }
 
+TEST_F(HeaderSearchTest, HeaderMapFrameworkLookup) {
+  typedef NullTerminatedFile, char> FileTy;
+  FileTy File;
+  File.init();
+
+  std::string HeaderDirName = "/tmp/Sources/Foo/Headers/";
+  std::string HeaderName = "Foo.h";
+#ifdef _WIN32
+  // Force header path to be absolute on windows.
+  // As headermap content should represent absolute locations.
+  HeaderDirName = "C:" + HeaderDirName;
+#endif /*_WIN32*/
+
+  test::HMapFileMockMaker Maker(File);
+  auto a = Maker.addString("Foo/Foo.h");
+  auto b = Maker.addString(HeaderDirName);
+  auto c = Maker.addString(HeaderName);
+  Maker.addBucket("Foo/Foo.h", a, b, c);
+  addHeaderMap("product-headers.hmap", File.getBuffer(), /*isAngled=*/true);
+
+  VFS->addFile(
+  HeaderDirName + HeaderName, 0,
+  llvm::MemoryBuffer::getMemBufferCopy("", HeaderDirName + HeaderName),
+  /*User=*/None, /*Group=*/None, llvm::sys::fs::file_type::regular_file);
+
+  bool IsMapped = false;
+  const DirectoryLookup *CurDir = nullptr;
+  auto FoundFile = Search.LookupFile(
+  "Foo/Foo.h", SourceLocation(), /*isAngled=*/true, /*FromDir=*/nullptr,
+  CurDir, /*Includers=*/{}, /*SearchPath=*/nullptr,
+  /*RelativePath=*/nullptr, /*RequestingModule=*/nullptr,
+  /*SuggestedModule=*/nullptr, &IsMapped,
+  /*IsFrameworkFound=*/nullptr);
+
+  EXPECT_TRUE(FoundFile.hasValue());
+  EXPECT_TRUE(IsMapped);
+  auto &FE = FoundFile.getValue();
+  auto FI = Search.getExistingFileInfo(FE);
+  EXPECT_TRUE(FI);
+  EXPECT_TRUE(FI->IsValid);
+  EXPECT_EQ(FI->Framework.str(), "Foo");
+}
+
 } // namespace
 } // namespace clang
Index: clang/lib/Lex/HeaderSearch.cpp
===
--- clang/lib/Lex/HeaderSearch.cpp
+++ clang/lib/Lex/HeaderSearch.cpp
@@ -1005,13 +1005,13 @@
 
 // If this file is found in a header map and uses the framework style of
 // includes, then this header is part of a framework we're building.
-if (CurDir->isIndexHeaderMap()) {
+if (CurDir->isHeaderMap() && isAngled) {
   size_t SlashPos = Filename.find('/');
-  if (SlashPos != StringRef::npos) {
+  if (SlashPos != StringRef::npos)
+HFI.Framework =
+getUniqueFrameworkName(StringRef(Filename.begin(), SlashPos));
+  if (CurDir->isIndexHeaderMap())
 HFI.IndexHeaderMapHeader = 1;
-HFI.Framework = getUniqueFrameworkName(StringRef(Filename.begin(),
- SlashPos));
-  }
 }
 
 if (checkMSVCHeaderSearch(Diags, MSFE ? &MSFE->getFileEntry() : nullptr,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D111734: [HIP] Relax conditions for address space cast in builtin args

[Anshil Gandhi via Phabricator via cfe-commits]

gandhi21299 added a comment.

Passed internal CI, still working on a Sema test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111734

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

[PATCH] D111778: [WIP][X86] Update CPU_SPECIFIC list.

[Freddy, Ye via Phabricator via cfe-commits]

FreddyYe added a comment.

In D111778#3063891 , @erichkeane 
wrote:

> Supporting these types requires changes to the library so that we can check 
> these, right?  Do you have the library changes for these as well?  The 
> constants used to check for these features/etc needs to be present in the 
> glibc library.

Yes. It's highly related to the `ProcessorFeatures` I mentioned above. Does the 
`library changes` refer to the compiler-rt/cpu_model.c? I think that change 
depends on libgcc. For now libgcc has no strong will to update that table.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111778

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

[PATCH] D111814: Fix consteval crash when transforming 'this' expressions

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman created this revision.
aaron.ballman added reviewers: rsmith, rjmccall, erichkeane.
aaron.ballman requested review of this revision.
Herald added a project: clang.

When reaching the end of a function body, we need to ensure that the 
`ExitFunctionBodyRAII` object is destroyed before we pop the declaration 
context for the function. Exiting the function body causes us to handle 
immediate invocations, which involves template transformations that need to 
know the correct type for `this`.

This addresses PR48235.

(Note, the diff in Phrabricator looks more awful than it is in reality -- the 
only change to the code was to add a new compound scope, but indenting the 
contents of that new scope seems to make for confusing-looking diffs.)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D111814

Files:
  clang/lib/Sema/SemaDecl.cpp
  clang/test/SemaCXX/cxx2a-consteval.cpp

Index: clang/test/SemaCXX/cxx2a-consteval.cpp
===
--- clang/test/SemaCXX/cxx2a-consteval.cpp
+++ clang/test/SemaCXX/cxx2a-consteval.cpp
@@ -612,3 +612,23 @@
 static_assert(is_same::value);
 
 } // namespace unevaluated
+
+namespace PR48235 {
+consteval int d() {
+  return 1;
+}
+
+struct A {
+  consteval int a() const { return 1; }
+
+  void b() {
+this->a() + d(); // expected-error {{call to consteval function 'PR48235::A::a' is not a constant expression}} \
+ // expected-note {{use of 'this' pointer is only allowed within the evaluation of a call to a 'constexpr' member function}}
+  }
+
+  void c() {
+a() + d(); // expected-error {{call to consteval function 'PR48235::A::a' is not a constant expression}} \
+   // expected-note {{use of 'this' pointer is only allowed within the evaluation of a call to a 'constexpr' member function}}
+  }
+};
+} // PR48235
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -14501,333 +14501,340 @@
   if (getLangOpts().Coroutines && FSI->isCoroutine())
 CheckCompletedCoroutineBody(FD, Body);
 
-  // Do not call PopExpressionEvaluationContext() if it is a lambda because one
-  // is already popped when finishing the lambda in BuildLambdaExpr(). This is
-  // meant to pop the context added in ActOnStartOfFunctionDef().
-  ExitFunctionBodyRAII ExitRAII(*this, isLambdaCallOperator(FD));
-
-  if (FD) {
-FD->setBody(Body);
-FD->setWillHaveBody(false);
-
-if (getLangOpts().CPlusPlus14) {
-  if (!FD->isInvalidDecl() && Body && !FD->isDependentContext() &&
-  FD->getReturnType()->isUndeducedType()) {
-// If the function has a deduced result type but contains no 'return'
-// statements, the result type as written must be exactly 'auto', and
-// the deduced result type is 'void'.
-if (!FD->getReturnType()->getAs()) {
-  Diag(dcl->getLocation(), diag::err_auto_fn_no_return_but_not_auto)
-  << FD->getReturnType();
-  FD->setInvalidDecl();
-} else {
-  // Substitute 'void' for the 'auto' in the type.
-  TypeLoc ResultType = getReturnTypeLoc(FD);
-  Context.adjustDeducedFunctionResultType(
-  FD, SubstAutoType(ResultType.getType(), Context.VoidTy));
+  {
+// Do not call PopExpressionEvaluationContext() if it is a lambda because
+// one is already popped when finishing the lambda in BuildLambdaExpr().
+// This is meant to pop the context added in ActOnStartOfFunctionDef().
+ExitFunctionBodyRAII ExitRAII(*this, isLambdaCallOperator(FD));
+
+if (FD) {
+  FD->setBody(Body);
+  FD->setWillHaveBody(false);
+
+  if (getLangOpts().CPlusPlus14) {
+if (!FD->isInvalidDecl() && Body && !FD->isDependentContext() &&
+FD->getReturnType()->isUndeducedType()) {
+  // If the function has a deduced result type but contains no 'return'
+  // statements, the result type as written must be exactly 'auto', and
+  // the deduced result type is 'void'.
+  if (!FD->getReturnType()->getAs()) {
+Diag(dcl->getLocation(), diag::err_auto_fn_no_return_but_not_auto)
+<< FD->getReturnType();
+FD->setInvalidDecl();
+  } else {
+// Substitute 'void' for the 'auto' in the type.
+TypeLoc ResultType = getReturnTypeLoc(FD);
+Context.adjustDeducedFunctionResultType(
+FD, SubstAutoType(ResultType.getType(), Context.VoidTy));
+  }
+}
+  } else if (getLangOpts().CPlusPlus11 && isLambdaCallOperator(FD)) {
+// In C++11, we don't use 'auto' deduction rules for lambda call
+// operators because we don't support return type deduction.
+auto *LSI = getCurLambda();
+if (LSI->HasImplicitReturnType) {
+  deduceClosureReturnType(*LSI);
+
+  // C++11 

[PATCH] D111815: [clang-format] [PR42014,PR52021] don't let clang-format assert/crash when file being formatted is read-only/locked

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay created this revision.
MyDeveloperDay added reviewers: thakis, curdeius, HazardyKnusperkeks.
MyDeveloperDay added projects: clang, clang-format.
MyDeveloperDay requested review of this revision.

This is a bug which gets reported from time to time and we've had multiple 
attempts to fix it, but don't want to fix it by adding frontEnd to the mix.

D68554: [clang-format] Proposal for clang-format to give compiler style 
warnings 
D90121: clang-format: Add a consumer to diagnostics engine 

D69854: [clang-format] [RELAND] Remove the dependency on frontend 


This patch aim to find a trivial, but not that sophisticated way of emitting 
the error without the additional impact of adding libFrontEnd to clang-format.

See D90121: clang-format: Add a consumer to diagnostics engine 
 for analysis of why we don't want those 
previous attempts

We can now see this:

  $ clang-format -i test1.cpp
  clang-format error:unable to rename temporary 'test1.cpp-4e5b1ac5' to output 
file 'test1.cpp': 'permission denied'

Rather than

  Assertion failed: getClient() && "DiagnosticClient not set!", file 
C:\llvm-project\clang\lib\Basic\Diagnostic.cpp, line 522
  PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash 
backtrace.
  Stack dump:
  0.  Program arguments: C:\\build_ninja\\bin\\clang-format.exe -i test1.cpp
   #0 0x7ff63cd7244c (C:\build_ninja\bin\clang-format.exe+0x12244c)
   #1 0x7fff3db28e05 (C:\WINDOWS\SYSTEM32\ucrtbased.dll+0xa8e05)
  ...
   #6 0x7fff3db3158f (C:\WINDOWS\SYSTEM32\ucrtbased.dll+0xb158f)
   #7 0x7ff63ce6d4ff (C:\build_ninja\bin\clang-format.exe+0x21d4ff)
   #8 0x7ff63ce7dcf6 (C:\build_ninja\bin\clang-format.exe+0x22dcf6)
  
  #17 0x7ff63d16457e (C:\build_ninja\bin\clang-format.exe+0x51457e)
  #18 0x7fff9b7f7034 (C:\WINDOWS\System32\KERNEL32.DLL+0x17034)
  #19 0x7fff9ce02651 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x52651)

Not sure how I can easily unit test this, as I had to use Excel to lock the 
file!


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D111815

Files:
  clang/tools/clang-format/ClangFormat.cpp


Index: clang/tools/clang-format/ClangFormat.cpp
===
--- clang/tools/clang-format/ClangFormat.cpp
+++ clang/tools/clang-format/ClangFormat.cpp
@@ -366,6 +366,18 @@
   outs() << "\n";
 }
 
+class ClangFormatDiagConsumer : public DiagnosticConsumer {
+  virtual void anchor() {}
+
+  void HandleDiagnostic(DiagnosticsEngine::Level DiagLevel,
+const Diagnostic &Info) override {
+
+SmallVector vec;
+Info.FormatDiagnostic(vec);
+errs() << "clang-format error:" << vec << "\n";
+  }
+};
+
 // Returns true on error.
 static bool format(StringRef FileName) {
   if (!OutputXML && Inplace && FileName == "-") {
@@ -477,9 +489,12 @@
 IntrusiveRefCntPtr InMemoryFileSystem(
 new llvm::vfs::InMemoryFileSystem);
 FileManager Files(FileSystemOptions(), InMemoryFileSystem);
+
+IntrusiveRefCntPtr DiagOpts(new DiagnosticOptions());
+ClangFormatDiagConsumer IgnoreDiagnostics;
 DiagnosticsEngine Diagnostics(
-IntrusiveRefCntPtr(new DiagnosticIDs),
-new DiagnosticOptions);
+IntrusiveRefCntPtr(new DiagnosticIDs), &*DiagOpts,
+&IgnoreDiagnostics, false);
 SourceManager Sources(Diagnostics, Files);
 FileID ID = createInMemoryFile(AssumedFileName, *Code, Sources, Files,
InMemoryFileSystem.get());


Index: clang/tools/clang-format/ClangFormat.cpp
===
--- clang/tools/clang-format/ClangFormat.cpp
+++ clang/tools/clang-format/ClangFormat.cpp
@@ -366,6 +366,18 @@
   outs() << "\n";
 }
 
+class ClangFormatDiagConsumer : public DiagnosticConsumer {
+  virtual void anchor() {}
+
+  void HandleDiagnostic(DiagnosticsEngine::Level DiagLevel,
+const Diagnostic &Info) override {
+
+SmallVector vec;
+Info.FormatDiagnostic(vec);
+errs() << "clang-format error:" << vec << "\n";
+  }
+};
+
 // Returns true on error.
 static bool format(StringRef FileName) {
   if (!OutputXML && Inplace && FileName == "-") {
@@ -477,9 +489,12 @@
 IntrusiveRefCntPtr InMemoryFileSystem(
 new llvm::vfs::InMemoryFileSystem);
 FileManager Files(FileSystemOptions(), InMemoryFileSystem);
+
+IntrusiveRefCntPtr DiagOpts(new DiagnosticOptions());
+ClangFormatDiagConsumer IgnoreDiagnostics;
 DiagnosticsEngine Diagnostics(
-IntrusiveRefCntPtr(new DiagnosticIDs),
-new DiagnosticOptions);
+IntrusiveRefCntPtr(new DiagnosticIDs), &*DiagOpts,
+&IgnoreDiagnostics, false);
 SourceManager Sources(Diagnostics, Files);
 FileID ID = createInMemoryFile(AssumedFileName, *Code, Sources, Files,

[clang] ac3edc5 - [analyzer][solver] Handle simplification to ConcreteInt

[Gabor Marton via cfe-commits]

Author: Gabor Marton
Date: 2021-10-14T17:53:29+02:00
New Revision: ac3edc5af09947210d8f8d25ddd7e42379ef6454

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

LOG: [analyzer][solver] Handle simplification to ConcreteInt

The solver's symbol simplification mechanism was not able to handle cases
when a symbol is simplified to a concrete integer. This patch adds the
capability.

E.g., in the attached lit test case, the original symbol is `c + 1` and
it has a `[0, 0]` range associated with it. Then, a new condition `c == 0`
is assumed, so a new range constraint `[0, 0]` comes in for `c` and
simplification kicks in. `c + 1` becomes `0 + 1`, but the associated
range is `[0, 0]`, so now we are able to realize the contradiction.

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

Added: 
clang/test/Analysis/solver-sym-simplification-concreteint.c

Modified: 

clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h
clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
clang/lib/StaticAnalyzer/Core/RangedConstraintManager.cpp

Removed: 




diff  --git 
a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h
 
b/clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h
index c1d2b4665f1d3..599e4ec812a1b 100644
--- 
a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h
+++ 
b/clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h
@@ -389,11 +389,22 @@ class RangedConstraintManager : public 
SimpleConstraintManager {
   static void computeAdjustment(SymbolRef &Sym, llvm::APSInt &Adjustment);
 };
 
-/// Try to simplify a given symbolic expression's associated value based on the
-/// constraints in State. This is needed because the Environment bindings are
-/// not getting updated when a new constraint is added to the State.
+/// Try to simplify a given symbolic expression based on the constraints in
+/// State. This is needed because the Environment bindings are not getting
+/// updated when a new constraint is added to the State. If the symbol is
+/// simplified to a non-symbol (e.g. to a constant) then the original symbol
+/// is returned. We use this function in the family of assumeSymNE/EQ/LT/../GE
+/// functions where we can work only with symbols. Use the other function
+/// (simplifyToSVal) if you are interested in a simplification that may yield
+/// a concrete constant value.
 SymbolRef simplify(ProgramStateRef State, SymbolRef Sym);
 
+/// Try to simplify a given symbolic expression's associated `SVal` based on 
the
+/// constraints in State. This is very similar to `simplify`, but this function
+/// always returns the simplified SVal. The simplified SVal might be a single
+/// constant (i.e. `ConcreteInt`).
+SVal simplifyToSVal(ProgramStateRef State, SymbolRef Sym);
+
 } // namespace ento
 } // namespace clang
 

diff  --git a/clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp 
b/clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
index 8299486938850..d1113569c59db 100644
--- a/clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ b/clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -2106,7 +2106,20 @@ EquivalenceClass::simplify(SValBuilder &SVB, 
RangeSet::Factory &F,
ProgramStateRef State, EquivalenceClass Class) {
   SymbolSet ClassMembers = Class.getClassMembers(State);
   for (const SymbolRef &MemberSym : ClassMembers) {
-SymbolRef SimplifiedMemberSym = ento::simplify(State, MemberSym);
+
+const SVal SimplifiedMemberVal = simplifyToSVal(State, MemberSym);
+const SymbolRef SimplifiedMemberSym = SimplifiedMemberVal.getAsSymbol();
+
+// The symbol is collapsed to a constant, check if the current State is
+// still feasible.
+if (const auto CI = SimplifiedMemberVal.getAs()) {
+  const llvm::APSInt &SV = CI->getValue();
+  const RangeSet *ClassConstraint = getConstraint(State, Class);
+  // We have found a contradiction.
+  if (ClassConstraint && !ClassConstraint->contains(SV))
+return nullptr;
+}
+
 if (SimplifiedMemberSym && MemberSym != SimplifiedMemberSym) {
   // The simplified symbol should be the member of the original Class,
   // however, it might be in another existing class at the moment. We

diff  --git a/clang/lib/StaticAnalyzer/Core/RangedConstraintManager.cpp 
b/clang/lib/StaticAnalyzer/Core/RangedConstraintManager.cpp
index d227c025fb203..80f3054a5a37f 100644
--- a/clang/lib/StaticAnalyzer/Core/RangedConstraintManager.cpp
+++ b/clang/lib/StaticAnalyzer/Core/RangedConstraintManager.cpp
@@ -226,9 +226,13 @@ void RangedConstraintManager::computeAdjustment(SymbolRef 
&Sym,
   }
 }
 
-SymbolRef simplify(ProgramSta

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

[Gabor Marton via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGac3edc5af099: [analyzer][solver] Handle simplification to 
ConcreteInt (authored by martong).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110913

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

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

[PATCH] D111778: [WIP][X86] Update CPU_SPECIFIC list.

[Craig Topper via Phabricator via cfe-commits]

craig.topper added a comment.

In D111778#3064287 , @FreddyYe wrote:

> In D111778#3063891 , @erichkeane 
> wrote:
>
>> Supporting these types requires changes to the library so that we can check 
>> these, right?  Do you have the library changes for these as well?  The 
>> constants used to check for these features/etc needs to be present in the 
>> glibc library.
>
> Yes. It's highly related to the `ProcessorFeatures` I mentioned above. Does 
> the `library changes` refer to the compiler-rt/cpu_model.c? I think that 
> change depends on libgcc. For now libgcc has no strong will to update that 
> table.

Every feature gcc knows about should be in libgcc. The unfortunate problem now 
is that cpu_features2 in libgcc is an array thats size may be different with 
every version of gcc. Clang can’t know how big that array is without reading 
the libgcc.a symbol table at compile time. Without knowing the size we can’t 
access any bits past the first 32 bits of cpu_features2.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111778

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

[PATCH] D111814: Fix consteval crash when transforming 'this' expressions

[Erich Keane via Phabricator via cfe-commits]

erichkeane added inline comments.



Comment at: clang/lib/Sema/SemaDecl.cpp:14839
 
   if (!IsInstantiation)
 PopDeclContext();

so the only real change here is that `ExitFunctionBodyRAII` ends here, instead 
of the end of the function?  

I guess this SEEMS pretty innocuous, I don't know particularly what 
`PopFunctionScopeInfo` does well enough to know if this is going to cause 
problems, but I DO know at least the 14850+ doesn't need to have the function 
body in scope (and PopDeclContext seems like it doesn't do much?)...

I would think that anything after `PopDeclContext` would have a problem being 
in the function body anyway (that is, being in a 'function body' with a 
mismatched DeclContext seems wrong), so I'm reasonably convinced this is at 
least non-breaking.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111814

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

[PATCH] D111805: [Driver][NetBSD] Use T reference instead of getToolChain().getTriple().

[Michał Górny via Phabricator via cfe-commits]

mgorny added inline comments.



Comment at: clang/lib/Driver/ToolChains/NetBSD.cpp:35
   const Driver &D = ToolChain.getDriver();
+  const llvm::Triple &T = ToolChain.getTriple();
 

Is there a specific reason to choose the name `T`? FWICS different drivers use 
different names but I think `Triple` is both more popular and more readable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111805

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

[PATCH] D105168: [RISCV] Unify the arch string parsing logic to RISCVISAInfo.

[Zakk Chen via Phabricator via cfe-commits]

khchen added inline comments.



Comment at: llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp:2089
 else
   return Error(ValueExprLoc, "bad arch string " + Arch);
   }

maybe we could have a NFC patch later to add 
```
// Emit the arch string if needed.
if (!IsIntegerValue)
  getTargetStreamer().emitTextAttribute(Tag, ISAInfo->toString());
```
here to reuse `ISAInfo`, and remove 2098~2117 code.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105168

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

[PATCH] D110669: [RISCV] Update Zba, Zbb, Zbc, and Zbs version from 0.93 to 1.0.

[Craig Topper via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGf7ba572483dd: [RISCV] Update Zba, Zbb, Zbc, and Zbs version 
from 0.93 to 1.0. (authored by craig.topper).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110669

Files:
  clang/lib/Basic/Targets/RISCV.cpp
  clang/lib/Driver/ToolChains/Arch/RISCV.cpp
  clang/test/Driver/riscv-arch.c
  clang/test/Preprocessor/riscv-target-features.c
  llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
  llvm/lib/Target/RISCV/MCTargetDesc/RISCVTargetStreamer.cpp
  llvm/lib/Target/RISCV/RISCVInstrInfoZb.td
  llvm/test/CodeGen/RISCV/attributes.ll
  llvm/test/MC/RISCV/attribute-arch.s

Index: llvm/test/MC/RISCV/attribute-arch.s
===
--- llvm/test/MC/RISCV/attribute-arch.s
+++ llvm/test/MC/RISCV/attribute-arch.s
@@ -40,13 +40,13 @@
 # CHECK: attribute  5, "rv32i2p0_v0p10"
 
 .attribute arch, "rv32izba"
-# CHECK: attribute  5, "rv32i2p0_zba0p93"
+# CHECK: attribute  5, "rv32i2p0_zba1p0"
 
 .attribute arch, "rv32izbb"
-# CHECK: attribute  5, "rv32i2p0_zbb0p93"
+# CHECK: attribute  5, "rv32i2p0_zbb1p0"
 
 .attribute arch, "rv32izbc"
-# CHECK: attribute  5, "rv32i2p0_zbc0p93"
+# CHECK: attribute  5, "rv32i2p0_zbc1p0"
 
 .attribute arch, "rv32izbe"
 # CHECK: attribute  5, "rv32i2p0_zbe0p93"
@@ -64,7 +64,7 @@
 # CHECK: attribute  5, "rv32i2p0_zbr0p93"
 
 .attribute arch, "rv32izbs"
-# CHECK: attribute  5, "rv32i2p0_zbs0p93"
+# CHECK: attribute  5, "rv32i2p0_zbs1p0"
 
 .attribute arch, "rv32izbt"
 # CHECK: attribute  5, "rv32i2p0_zbt0p93"
Index: llvm/test/CodeGen/RISCV/attributes.ll
===
--- llvm/test/CodeGen/RISCV/attributes.ll
+++ llvm/test/CodeGen/RISCV/attributes.ll
@@ -44,17 +44,17 @@
 ; RV32C: .attribute 5, "rv32i2p0_c2p0"
 ; RV32V: .attribute 5, "rv32i2p0_v0p10_zvamo0p10_zvlsseg0p10"
 ; RV32ZFH: .attribute 5, "rv32i2p0_f2p0_zfh0p1"
-; RV32ZBA: .attribute 5, "rv32i2p0_zba0p93"
-; RV32ZBB: .attribute 5, "rv32i2p0_zbb0p93"
-; RV32ZBC: .attribute 5, "rv32i2p0_zbc0p93"
+; RV32ZBA: .attribute 5, "rv32i2p0_zba1p0"
+; RV32ZBB: .attribute 5, "rv32i2p0_zbb1p0"
+; RV32ZBC: .attribute 5, "rv32i2p0_zbc1p0"
 ; RV32ZBE: .attribute 5, "rv32i2p0_zbe0p93"
 ; RV32ZBF: .attribute 5, "rv32i2p0_zbf0p93"
 ; RV32ZBM: .attribute 5, "rv32i2p0_zbm0p93"
 ; RV32ZBP: .attribute 5, "rv32i2p0_zbp0p93"
 ; RV32ZBR: .attribute 5, "rv32i2p0_zbr0p93"
-; RV32ZBS: .attribute 5, "rv32i2p0_zbs0p93"
+; RV32ZBS: .attribute 5, "rv32i2p0_zbs1p0"
 ; RV32ZBT: .attribute 5, "rv32i2p0_zbt0p93"
-; RV32COMBINED: .attribute 5, "rv32i2p0_f2p0_v0p10_zfh0p1_zbb0p93_zvamo0p10_zvlsseg0p10"
+; RV32COMBINED: .attribute 5, "rv32i2p0_f2p0_v0p10_zfh0p1_zbb1p0_zvamo0p10_zvlsseg0p10"
 
 ; RV64M: .attribute 5, "rv64i2p0_m2p0"
 ; RV64A: .attribute 5, "rv64i2p0_a2p0"
@@ -62,18 +62,18 @@
 ; RV64D: .attribute 5, "rv64i2p0_f2p0_d2p0"
 ; RV64C: .attribute 5, "rv64i2p0_c2p0"
 ; RV64ZFH: .attribute 5, "rv64i2p0_f2p0_zfh0p1"
-; RV64ZBA: .attribute 5, "rv64i2p0_zba0p93"
-; RV64ZBB: .attribute 5, "rv64i2p0_zbb0p93"
-; RV64ZBC: .attribute 5, "rv64i2p0_zbc0p93"
+; RV64ZBA: .attribute 5, "rv64i2p0_zba1p0"
+; RV64ZBB: .attribute 5, "rv64i2p0_zbb1p0"
+; RV64ZBC: .attribute 5, "rv64i2p0_zbc1p0"
 ; RV64ZBE: .attribute 5, "rv64i2p0_zbe0p93"
 ; RV64ZBF: .attribute 5, "rv64i2p0_zbf0p93"
 ; RV64ZBM: .attribute 5, "rv64i2p0_zbm0p93"
 ; RV64ZBP: .attribute 5, "rv64i2p0_zbp0p93"
 ; RV64ZBR: .attribute 5, "rv64i2p0_zbr0p93"
-; RV64ZBS: .attribute 5, "rv64i2p0_zbs0p93"
+; RV64ZBS: .attribute 5, "rv64i2p0_zbs1p0"
 ; RV64ZBT: .attribute 5, "rv64i2p0_zbt0p93"
 ; RV64V: .attribute 5, "rv64i2p0_v0p10_zvamo0p10_zvlsseg0p10"
-; RV64COMBINED: .attribute 5, "rv64i2p0_f2p0_v0p10_zfh0p1_zbb0p93_zvamo0p10_zvlsseg0p10"
+; RV64COMBINED: .attribute 5, "rv64i2p0_f2p0_v0p10_zfh0p1_zbb1p0_zvamo0p10_zvlsseg0p10"
 
 
 define i32 @addi(i32 %a) {
Index: llvm/lib/Target/RISCV/RISCVInstrInfoZb.td
===
--- llvm/lib/Target/RISCV/RISCVInstrInfoZb.td
+++ llvm/lib/Target/RISCV/RISCVInstrInfoZb.td
@@ -7,7 +7,17 @@
 //===--===//
 //
 // This file describes the RISC-V instructions from the standard Bitmanip
-// extensions, version 0.93.
+// extensions, versions:
+//   Zba - 1.0
+//   Zbb - 1.0
+//   Zbc - 1.0
+//   Zbs - 1.0
+//   Zbe - 0.93
+//   Zbf - 0.93
+//   Zbm - 0.93
+//   Zbp - 0.93
+//   Zbr - 0.93
+//   Zbt - 0.93
 // This version is still experimental as the Bitmanip extensions haven't been
 // ratified yet.
 //
@@ -485,15 +495,6 @@
 Sched<[WriteRotateReg32, ReadRotateReg32, ReadRotateReg32]>;
 } // Predicates = [HasStdExtZbbOrZbp, IsRV64]
 
-let Predicates = [HasStdExtZbs, IsRV64] in {
-// NOTE: These instructions have been removed from the 0.94 spec. 

[clang] f7ba572 - [RISCV] Update Zba, Zbb, Zbc, and Zbs version from 0.93 to 1.0.

[Craig Topper via cfe-commits]

Author: Craig Topper
Date: 2021-10-14T09:25:03-07:00
New Revision: f7ba572483dd424c6235901d1c6cb3650c46b477

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

LOG: [RISCV] Update Zba, Zbb, Zbc, and Zbs version from 0.93 to 1.0.

I've removed the Zbs W instructions that are not part of the frozen spec.

References to B as an extension name have been removed. Tests are updated or 
split accordingly.

Reviewed By: luismarques

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

Added: 


Modified: 
clang/lib/Basic/Targets/RISCV.cpp
clang/lib/Driver/ToolChains/Arch/RISCV.cpp
clang/test/Driver/riscv-arch.c
clang/test/Preprocessor/riscv-target-features.c
llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
llvm/lib/Target/RISCV/MCTargetDesc/RISCVTargetStreamer.cpp
llvm/lib/Target/RISCV/RISCVInstrInfoZb.td
llvm/test/CodeGen/RISCV/attributes.ll
llvm/test/MC/RISCV/attribute-arch.s

Removed: 




diff  --git a/clang/lib/Basic/Targets/RISCV.cpp 
b/clang/lib/Basic/Targets/RISCV.cpp
index fa56cddca2a2f..00da8cdaef0b5 100644
--- a/clang/lib/Basic/Targets/RISCV.cpp
+++ b/clang/lib/Basic/Targets/RISCV.cpp
@@ -182,13 +182,13 @@ void RISCVTargetInfo::getTargetDefines(const LangOptions 
&Opts,
   }
 
   if (HasZba)
-Builder.defineMacro("__riscv_zba", "93000");
+Builder.defineMacro("__riscv_zba", "100");
 
   if (HasZbb)
-Builder.defineMacro("__riscv_zbb", "93000");
+Builder.defineMacro("__riscv_zbb", "100");
 
   if (HasZbc)
-Builder.defineMacro("__riscv_zbc", "93000");
+Builder.defineMacro("__riscv_zbc", "100");
 
   if (HasZbe)
 Builder.defineMacro("__riscv_zbe", "93000");
@@ -206,7 +206,7 @@ void RISCVTargetInfo::getTargetDefines(const LangOptions 
&Opts,
 Builder.defineMacro("__riscv_zbr", "93000");
 
   if (HasZbs)
-Builder.defineMacro("__riscv_zbs", "93000");
+Builder.defineMacro("__riscv_zbs", "100");
 
   if (HasZbt)
 Builder.defineMacro("__riscv_zbt", "93000");

diff  --git a/clang/lib/Driver/ToolChains/Arch/RISCV.cpp 
b/clang/lib/Driver/ToolChains/Arch/RISCV.cpp
index aff96d80f765e..a05b8a93a37b0 100644
--- a/clang/lib/Driver/ToolChains/Arch/RISCV.cpp
+++ b/clang/lib/Driver/ToolChains/Arch/RISCV.cpp
@@ -58,9 +58,10 @@ static StringRef getExtensionType(StringRef Ext) {
 // extension that the compiler currently supports.
 static Optional
 isExperimentalExtension(StringRef Ext) {
-  if (Ext == "zba" || Ext == "zbb" || Ext == "zbc" || Ext == "zbe" ||
-  Ext == "zbf" || Ext == "zbm" || Ext == "zbp" || Ext == "zbr" ||
-  Ext == "zbs" || Ext == "zbt")
+  if (Ext == "zba" || Ext == "zbb" || Ext == "zbc" || Ext == "zbs")
+return RISCVExtensionVersion{"1", "0"};
+  if (Ext == "zbe" || Ext == "zbf" || Ext == "zbm" || Ext == "zbp" ||
+  Ext == "zbr" || Ext == "zbt")
 return RISCVExtensionVersion{"0", "93"};
   if (Ext == "v" || Ext == "zvamo" || Ext == "zvlsseg")
 return RISCVExtensionVersion{"0", "10"};

diff  --git a/clang/test/Driver/riscv-arch.c b/clang/test/Driver/riscv-arch.c
index 269df87c2603f..e0afaa9e5351e 100644
--- a/clang/test/Driver/riscv-arch.c
+++ b/clang/test/Driver/riscv-arch.c
@@ -387,20 +387,20 @@
 // RV32-EXPERIMENTAL-ZBB-NOFLAG: error: invalid arch name 'rv32izbb'
 // RV32-EXPERIMENTAL-ZBB-NOFLAG: requires '-menable-experimental-extensions'
 
-// RUN: %clang -target riscv32-unknown-elf -march=rv32izbb0p93 
-menable-experimental-extensions -### %s \
+// RUN: %clang -target riscv32-unknown-elf -march=rv32izbb1p0 
-menable-experimental-extensions -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-EXPERIMENTAL-ZBB %s
 // RV32-EXPERIMENTAL-ZBB: "-target-feature" "+experimental-zbb"
 
-// RUN: %clang -target riscv32-unknown-elf -march=rv32izbb0p93_zbp0p93 
-menable-experimental-extensions -### %s \
+// RUN: %clang -target riscv32-unknown-elf -march=rv32izbb1p0_zbp0p93 
-menable-experimental-extensions -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-EXPERIMENTAL-ZBB-ZBP 
%s
 // RV32-EXPERIMENTAL-ZBB-ZBP: "-target-feature" "+experimental-zbb"
 // RV32-EXPERIMENTAL-ZBB-ZBP: "-target-feature" "+experimental-zbp"
 
-// RUN: %clang -target riscv32-unknown-elf -march=rv32izbb0p93zbp0p93 
-menable-experimental-extensions -### %s \
+// RUN: %clang -target riscv32-unknown-elf -march=rv32izbb1p0zbp0p93 
-menable-experimental-extensions -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck 
-check-prefix=RV32-EXPERIMENTAL-ZBB-ZBP-UNDERSCORE %s
-// RV32-EXPERIMENTAL-ZBB-ZBP-UNDERSCORE: error: invalid arch name 
'rv32izbb0p93zbp0p93', multi-character extensions must be separated by 
underscores
+// RV32-EXPERIMENTAL-ZBB-ZBP-UNDERSCORE: error: invalid arch name 
'rv32izbb1p0zbp0p93', multi-character extensions must be separated by 
underscores
 
-

[PATCH] D110663: [Driver] Support Debian multiarch style lib/clang/14.0.0/x86_64-linux-gnu runtime path and include/x86_64-linux-gnu/c++/v1 libc++ path

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

🙄


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110663

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

[PATCH] D111817: Fix a rejects-valid with consteval on overloaded operators

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman created this revision.
aaron.ballman added reviewers: rsmith, rjmccall, erichkeane.
aaron.ballman requested review of this revision.
Herald added a project: clang.

It seems that Clang 11 regressed functionality that was working in Clang 10 
regarding calling a few overloaded operators in an immediate context. 
Specifically, we were not checking for immediate invocations of array 
subscripting and the arrow operators, but we properly handle the other 
overloaded operators.

This fixes the two problematic operators and adds some test coverage to show 
they're equivalent to calling the operator directly. This addresses PR50779.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D111817

Files:
  clang/lib/Sema/SemaOverload.cpp
  clang/test/SemaCXX/cxx2a-consteval.cpp


Index: clang/test/SemaCXX/cxx2a-consteval.cpp
===
--- clang/test/SemaCXX/cxx2a-consteval.cpp
+++ clang/test/SemaCXX/cxx2a-consteval.cpp
@@ -612,3 +612,27 @@
 static_assert(is_same::value);
 
 } // namespace unevaluated
+
+namespace PR50779 {
+struct derp {
+  int b = 0;
+};
+
+constexpr derp d;
+
+struct test {
+  consteval int operator[](int i) const { return {}; }
+  consteval const derp * operator->() const { return &d; }
+};
+
+constexpr test a;
+
+// We previously rejected both of these overloaded operators as taking the
+// address of a consteval function outside of an immediate context, but we
+// accepted direct calls to the overloaded operator. Now we show that we accept
+// both forms.
+constexpr int s = a.operator[](1);
+constexpr int t = a[1];
+constexpr int u = a.operator->()->b;
+constexpr int v = a->b;
+}
Index: clang/lib/Sema/SemaOverload.cpp
===
--- clang/lib/Sema/SemaOverload.cpp
+++ clang/lib/Sema/SemaOverload.cpp
@@ -14161,7 +14161,8 @@
   Method->getType()->castAs()))
   return ExprError();
 
-return MaybeBindToTemporary(TheCall);
+return CheckForImmediateInvocation(MaybeBindToTemporary(TheCall),
+   FnDecl);
   } else {
 // We matched a built-in operator. Convert the arguments, then
 // break out so that we will build the appropriate built-in
@@ -14916,7 +14917,7 @@
 Method->getType()->castAs()))
 return ExprError();
 
-  return MaybeBindToTemporary(TheCall);
+  return CheckForImmediateInvocation(MaybeBindToTemporary(TheCall), Method);
 }
 
 /// BuildLiteralOperatorCall - Build a UserDefinedLiteral by creating a call to


Index: clang/test/SemaCXX/cxx2a-consteval.cpp
===
--- clang/test/SemaCXX/cxx2a-consteval.cpp
+++ clang/test/SemaCXX/cxx2a-consteval.cpp
@@ -612,3 +612,27 @@
 static_assert(is_same::value);
 
 } // namespace unevaluated
+
+namespace PR50779 {
+struct derp {
+  int b = 0;
+};
+
+constexpr derp d;
+
+struct test {
+  consteval int operator[](int i) const { return {}; }
+  consteval const derp * operator->() const { return &d; }
+};
+
+constexpr test a;
+
+// We previously rejected both of these overloaded operators as taking the
+// address of a consteval function outside of an immediate context, but we
+// accepted direct calls to the overloaded operator. Now we show that we accept
+// both forms.
+constexpr int s = a.operator[](1);
+constexpr int t = a[1];
+constexpr int u = a.operator->()->b;
+constexpr int v = a->b;
+}
Index: clang/lib/Sema/SemaOverload.cpp
===
--- clang/lib/Sema/SemaOverload.cpp
+++ clang/lib/Sema/SemaOverload.cpp
@@ -14161,7 +14161,8 @@
   Method->getType()->castAs()))
   return ExprError();
 
-return MaybeBindToTemporary(TheCall);
+return CheckForImmediateInvocation(MaybeBindToTemporary(TheCall),
+   FnDecl);
   } else {
 // We matched a built-in operator. Convert the arguments, then
 // break out so that we will build the appropriate built-in
@@ -14916,7 +14917,7 @@
 Method->getType()->castAs()))
 return ExprError();
 
-  return MaybeBindToTemporary(TheCall);
+  return CheckForImmediateInvocation(MaybeBindToTemporary(TheCall), Method);
 }
 
 /// BuildLiteralOperatorCall - Build a UserDefinedLiteral by creating a call to
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] b6c218d - [libTooling] Add "switch"-like Stencil combinator

[Yitzhak Mandelbaum via cfe-commits]

Author: Yitzhak Mandelbaum
Date: 2021-10-14T16:45:37Z
New Revision: b6c218d4fdb74c0ee467e078721438c3396dc599

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

LOG: [libTooling] Add "switch"-like Stencil combinator

Adds `selectBound`, a `Stencil` combinator that allows the user to supply 
multiple alternative cases, discriminated by bound node IDs.

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

Added: 


Modified: 
clang/include/clang/Tooling/Transformer/Stencil.h
clang/lib/Tooling/Transformer/Stencil.cpp
clang/unittests/Tooling/StencilTest.cpp

Removed: 




diff  --git a/clang/include/clang/Tooling/Transformer/Stencil.h 
b/clang/include/clang/Tooling/Transformer/Stencil.h
index 1b7495eb02622..249f95b7391df 100644
--- a/clang/include/clang/Tooling/Transformer/Stencil.h
+++ b/clang/include/clang/Tooling/Transformer/Stencil.h
@@ -117,6 +117,38 @@ inline Stencil ifBound(llvm::StringRef Id, llvm::StringRef 
TrueText,
  detail::makeStencil(FalseText));
 }
 
+/// Chooses between multiple stencils, based on the presence of bound nodes. \p
+/// CaseStencils takes a vector of (ID, \c Stencil) pairs and checks each ID in
+/// order to see if it's bound to a node.  If so, the associated \c Stencil is
+/// run and all other cases are ignored.  An optional \p DefaultStencil can be
+/// provided to be run if all cases are exhausted beacause none of the provided
+/// IDs are bound.  If no default case is provided and all cases are exhausted,
+/// the stencil will fail with error `llvm::errc::result_out_of_range`.
+///
+/// For example, say one matches a statement's type with:
+/// anyOf(
+///   qualType(isInteger()).bind("int"),
+///   qualType(realFloatingPointType()).bind("float"),
+///   qualType(isAnyCharacter()).bind("char"),
+///   booleanType().bind("bool"))
+///
+/// Then, one can decide in a stencil how to construct a literal.
+/// cat("a = ",
+/// selectBound(
+/// {{"int", cat("0")},
+///  {"float", cat("0.0")},
+///  {"char", cat("'\\0'")},
+///  {"bool", cat("false")}}))
+///
+/// In addition, one could supply a default case for all other types:
+/// selectBound(
+/// {{"int", cat("0")},
+///  ...
+///  {"bool", cat("false")}},
+/// cat("{}"))
+Stencil selectBound(std::vector> CaseStencils,
+Stencil DefaultStencil = nullptr);
+
 /// Wraps a \c MatchConsumer in a \c Stencil, so that it can be used in a \c
 /// Stencil.  This supports user-defined extensions to the \c Stencil language.
 Stencil run(MatchConsumer C);

diff  --git a/clang/lib/Tooling/Transformer/Stencil.cpp 
b/clang/lib/Tooling/Transformer/Stencil.cpp
index 4dc3544bb06db..8b20ef34c3ff2 100644
--- a/clang/lib/Tooling/Transformer/Stencil.cpp
+++ b/clang/lib/Tooling/Transformer/Stencil.cpp
@@ -27,14 +27,15 @@
 using namespace clang;
 using namespace transformer;
 
+using ast_matchers::BoundNodes;
 using ast_matchers::MatchFinder;
 using llvm::errc;
 using llvm::Error;
 using llvm::Expected;
 using llvm::StringError;
 
-static llvm::Expected
-getNode(const ast_matchers::BoundNodes &Nodes, StringRef Id) {
+static llvm::Expected getNode(const BoundNodes &Nodes,
+StringRef Id) {
   auto &NodesMap = Nodes.getMap();
   auto It = NodesMap.find(Id);
   if (It == NodesMap.end())
@@ -366,6 +367,73 @@ class IfBoundStencil : public StencilInterface {
   }
 };
 
+class SelectBoundStencil : public clang::transformer::StencilInterface {
+  static bool containsNoNullStencils(
+  const std::vector> &Cases) {
+for (const auto &S : Cases)
+  if (S.second == nullptr)
+return false;
+return true;
+  }
+
+public:
+  SelectBoundStencil(std::vector> Cases,
+ Stencil Default)
+  : CaseStencils(std::move(Cases)), DefaultStencil(std::move(Default)) {
+assert(containsNoNullStencils(CaseStencils) &&
+   "cases of selectBound may not be null");
+  }
+  ~SelectBoundStencil() override{};
+
+  llvm::Error eval(const MatchFinder::MatchResult &match,
+   std::string *result) const override {
+const BoundNodes::IDToNodeMap &NodeMap = match.Nodes.getMap();
+for (const auto &S : CaseStencils) {
+  if (NodeMap.count(S.first) > 0) {
+return S.second->eval(match, result);
+  }
+}
+
+if (DefaultStencil != nullptr) {
+  return DefaultStencil->eval(match, result);
+}
+
+llvm::SmallVector CaseIDs;
+CaseIDs.reserve(CaseStencils.size());
+for (const auto &S : CaseStencils)
+  CaseIDs.emplace_back(S.first);
+
+return llvm::createStringError(
+errc::result_out_of_range,
+llvm::Twine("selectBound failed: no 

[PATCH] D111708: [libTooling] Add "switch"-like Stencil combinator

[Yitzhak Mandelbaum 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 rGb6c218d4fdb7: [libTooling] Add "switch"-like 
Stencil combinator (authored by ymandel).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111708

Files:
  clang/include/clang/Tooling/Transformer/Stencil.h
  clang/lib/Tooling/Transformer/Stencil.cpp
  clang/unittests/Tooling/StencilTest.cpp

Index: clang/unittests/Tooling/StencilTest.cpp
===
--- clang/unittests/Tooling/StencilTest.cpp
+++ clang/unittests/Tooling/StencilTest.cpp
@@ -201,6 +201,58 @@
   testExpr(Id, "3;", ifBound("other", cat("5"), cat("7")), "7");
 }
 
+static auto selectMatcher() {
+  // The `anything` matcher is not bound, to test for none of the cases
+  // matching.
+  return expr(anyOf(integerLiteral().bind("int"), cxxBoolLiteral().bind("bool"),
+floatLiteral().bind("float"), anything()));
+}
+
+static auto selectStencil() {
+  return selectBound({
+  {"int", cat("I")},
+  {"bool", cat("B")},
+  {"bool", cat("redundant")},
+  {"float", cat("F")},
+  });
+}
+
+TEST_F(StencilTest, SelectBoundChooseDetectedMatch) {
+  std::string Input = "3;";
+  auto StmtMatch = matchStmt(Input, selectMatcher());
+  ASSERT_TRUE(StmtMatch);
+  EXPECT_THAT_EXPECTED(selectStencil()->eval(StmtMatch->Result),
+   HasValue(std::string("I")));
+}
+
+TEST_F(StencilTest, SelectBoundChooseFirst) {
+  std::string Input = "true;";
+  auto StmtMatch = matchStmt(Input, selectMatcher());
+  ASSERT_TRUE(StmtMatch);
+  EXPECT_THAT_EXPECTED(selectStencil()->eval(StmtMatch->Result),
+   HasValue(std::string("B")));
+}
+
+TEST_F(StencilTest, SelectBoundDiesOnExhaustedCases) {
+  std::string Input = "\"string\";";
+  auto StmtMatch = matchStmt(Input, selectMatcher());
+  ASSERT_TRUE(StmtMatch);
+  EXPECT_THAT_EXPECTED(
+  selectStencil()->eval(StmtMatch->Result),
+  Failed(testing::Property(
+  &StringError::getMessage,
+  AllOf(HasSubstr("selectBound failed"), HasSubstr("no default");
+}
+
+TEST_F(StencilTest, SelectBoundSucceedsWithDefault) {
+  std::string Input = "\"string\";";
+  auto StmtMatch = matchStmt(Input, selectMatcher());
+  ASSERT_TRUE(StmtMatch);
+  auto Stencil = selectBound({{"int", cat("I")}}, cat("D"));
+  EXPECT_THAT_EXPECTED(Stencil->eval(StmtMatch->Result),
+   HasValue(std::string("D")));
+}
+
 TEST_F(StencilTest, ExpressionOpNoParens) {
   StringRef Id = "id";
   testExpr(Id, "3;", expression(Id), "3");
@@ -674,6 +726,28 @@
   EXPECT_EQ(S->toString(), Expected);
 }
 
+TEST(StencilToStringTest, SelectBoundOp) {
+  auto S = selectBound({
+  {"int", cat("I")},
+  {"float", cat("F")},
+  });
+  StringRef Expected = R"repr(selectBound({{"int", "I"}, {"float", "F"}}))repr";
+  EXPECT_EQ(S->toString(), Expected);
+}
+
+TEST(StencilToStringTest, SelectBoundOpWithOneCase) {
+  auto S = selectBound({{"int", cat("I")}});
+  StringRef Expected = R"repr(selectBound({{"int", "I"}}))repr";
+  EXPECT_EQ(S->toString(), Expected);
+}
+
+TEST(StencilToStringTest, SelectBoundOpWithDefault) {
+  auto S = selectBound({{"int", cat("I")}, {"float", cat("F")}}, cat("D"));
+  StringRef Expected =
+  R"cc(selectBound({{"int", "I"}, {"float", "F"}}, "D"))cc";
+  EXPECT_EQ(S->toString(), Expected);
+}
+
 TEST(StencilToStringTest, RunOp) {
   auto F1 = [](const MatchResult &R) { return "foo"; };
   auto S1 = run(F1);
Index: clang/lib/Tooling/Transformer/Stencil.cpp
===
--- clang/lib/Tooling/Transformer/Stencil.cpp
+++ clang/lib/Tooling/Transformer/Stencil.cpp
@@ -27,14 +27,15 @@
 using namespace clang;
 using namespace transformer;
 
+using ast_matchers::BoundNodes;
 using ast_matchers::MatchFinder;
 using llvm::errc;
 using llvm::Error;
 using llvm::Expected;
 using llvm::StringError;
 
-static llvm::Expected
-getNode(const ast_matchers::BoundNodes &Nodes, StringRef Id) {
+static llvm::Expected getNode(const BoundNodes &Nodes,
+StringRef Id) {
   auto &NodesMap = Nodes.getMap();
   auto It = NodesMap.find(Id);
   if (It == NodesMap.end())
@@ -366,6 +367,73 @@
   }
 };
 
+class SelectBoundStencil : public clang::transformer::StencilInterface {
+  static bool containsNoNullStencils(
+  const std::vector> &Cases) {
+for (const auto &S : Cases)
+  if (S.second == nullptr)
+return false;
+return true;
+  }
+
+public:
+  SelectBoundStencil(std::vector> Cases,
+ Stencil Default)
+  : CaseStencils(std::move(Cases)), DefaultStencil(std::move(Default)) {
+assert(containsNoNullStencils(CaseStencils) &&
+   "cases of selectBound may not be null");
+  }
+  ~SelectBoundStencil() override{};
+
+  llvm::Err

[PATCH] D111778: [WIP][X86] Update CPU_SPECIFIC list.

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

In D111778#3064439 , @craig.topper 
wrote:

> In D111778#3064287 , @FreddyYe 
> wrote:
>
>> In D111778#3063891 , @erichkeane 
>> wrote:
>>
>>> Supporting these types requires changes to the library so that we can check 
>>> these, right?  Do you have the library changes for these as well?  The 
>>> constants used to check for these features/etc needs to be present in the 
>>> glibc library.
>>
>> Yes. It's highly related to the `ProcessorFeatures` I mentioned above. Does 
>> the `library changes` refer to the compiler-rt/cpu_model.c? I think that 
>> change depends on libgcc. For now libgcc has no strong will to update that 
>> table.
>
> Every feature gcc knows about should be in libgcc. The unfortunate problem 
> now is that cpu_features2 in libgcc is an array thats size may be different 
> with every version of gcc. Clang can’t know how big that array is without 
> reading the libgcc.a symbol table at compile time. Without knowing the size 
> we can’t access any bits past the first 32 bits of cpu_features2.

libgcc entries are the ones I was concerned about.  We need to make sure this 
list matches that one (and we don't generate checks that it does not have).  
@craig.topper can better clarify what needs to happen with the library lookup, 
but I THINK we keep a version of this in compiler-rt instead of using libgcc?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111778

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

[PATCH] D111814: Fix consteval crash when transforming 'this' expressions

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/Sema/SemaDecl.cpp:14839
 
   if (!IsInstantiation)
 PopDeclContext();

erichkeane wrote:
> so the only real change here is that `ExitFunctionBodyRAII` ends here, 
> instead of the end of the function?  
> 
> I guess this SEEMS pretty innocuous, I don't know particularly what 
> `PopFunctionScopeInfo` does well enough to know if this is going to cause 
> problems, but I DO know at least the 14850+ doesn't need to have the function 
> body in scope (and PopDeclContext seems like it doesn't do much?)...
> 
> I would think that anything after `PopDeclContext` would have a problem being 
> in the function body anyway (that is, being in a 'function body' with a 
> mismatched DeclContext seems wrong), so I'm reasonably convinced this is at 
> least non-breaking.
> 
> so the only real change here is that ExitFunctionBodyRAII ends here, instead 
> of the end of the function?

That's correct. I added the opening curly brace before the comments on the 
declaration of `ExitRAII`, and the close curly brace is on the line with the 
new comments added to it. Git decided this was the best diff it could come up 
with for all that re-indentation. :-/

> I would think that anything after PopDeclContext would have a problem being 
> in the function body anyway (that is, being in a 'function body' with a 
> mismatched DeclContext seems wrong), so I'm reasonably convinced this is at 
> least non-breaking.

This matches my thinking -- just before we go to pop the declaration context or 
scope, *that* is when the function body has ended.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111814

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

[PATCH] D109632: [clang] de-duplicate methods from AST files

[Richard Howell via Phabricator via cfe-commits]

rmaz added a comment.

In D109632#3062608 , @vsapsai wrote:

> I can be wrong but I like writing less data as it can result in savings for 
> more projects. For example, if compile time is dominated by method 
> deserialization and not by `Sema::addMethodToGlobalList`, we still should see 
> an improvement. I can try to experiment on a bunch of other projects and 
> their heavy .m files and report the results, if you'd like.

I think that would be a useful comparison, yes. For our code I consistently 
measure this approach as 10-20% slower on average, with very few outliers where 
the set deduplication approach is slower.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109632

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

[PATCH] D111817: Fix a rejects-valid with consteval on overloaded operators

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

This seems like two places this was missed in: https://reviews.llvm.org/D63960 
however I see a another place grepping around we might have missed too?  Can 
you find a way to write tests for that?

Also, perhaps 1 more cleanup?




Comment at: clang/lib/Sema/SemaOverload.cpp:13800
 
 ExprResult R = MaybeBindToTemporary(TheCall);
 if (R.isInvalid())

Wonder if as a 'while we're here' we should make this the same as the others? 
Does `CheckForImmediateInvocation` handle an invalid result without the extra 
check like we have here?



Comment at: clang/lib/Sema/SemaOverload.cpp:14290
 
 return MaybeBindToTemporary(call);
   }

Was this one missed too?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111817

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

[PATCH] D111817: Fix a rejects-valid with consteval on overloaded operators

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/Sema/SemaOverload.cpp:13800
 
 ExprResult R = MaybeBindToTemporary(TheCall);
 if (R.isInvalid())

erichkeane wrote:
> Wonder if as a 'while we're here' we should make this the same as the others? 
> Does `CheckForImmediateInvocation` handle an invalid result without the extra 
> check like we have here?
`CheckForImmediateInvocation` handles invalid results (I checked), so we could 
remove the isInvalid() lines below if we wanted (that's really an NFC cleanup).



Comment at: clang/lib/Sema/SemaOverload.cpp:14290
 
 return MaybeBindToTemporary(call);
   }

erichkeane wrote:
> Was this one missed too?
I couldn't devise a test case that was failing with member function call 
expressions, so I left this one alone. We have a bunch of existing test 
coverage for calling a consteval member function, so I'm assuming this is 
correct, but if someone finds a test case that fails here, it's easy enough to 
fix.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111817

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

[PATCH] D111817: Fix a rejects-valid with consteval on overloaded operators

[Richard Smith - zygoloid via Phabricator via cfe-commits]

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

Looks good to me.




Comment at: clang/lib/Sema/SemaOverload.cpp:14290
 
 return MaybeBindToTemporary(call);
   }

aaron.ballman wrote:
> erichkeane wrote:
> > Was this one missed too?
> I couldn't devise a test case that was failing with member function call 
> expressions, so I left this one alone. We have a bunch of existing test 
> coverage for calling a consteval member function, so I'm assuming this is 
> correct, but if someone finds a test case that fails here, it's easy enough 
> to fix.
This code is only reachable for a call through a pointer-to-member. We don't 
need to worry about `consteval` member function pointers because they can't 
escape constant-evaluated contexts anyway. Eg, `(p->*&Class::consteval_fn)()` 
is ill-formed outside of a constant-evaluated context -- we should make sure we 
have a test for that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111817

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

[PATCH] D111817: Fix a rejects-valid with consteval on overloaded operators

[Erich Keane via Phabricator via cfe-commits]

erichkeane accepted this revision.
erichkeane added inline comments.



Comment at: clang/lib/Sema/SemaOverload.cpp:14290
 
 return MaybeBindToTemporary(call);
   }

rsmith wrote:
> aaron.ballman wrote:
> > erichkeane wrote:
> > > Was this one missed too?
> > I couldn't devise a test case that was failing with member function call 
> > expressions, so I left this one alone. We have a bunch of existing test 
> > coverage for calling a consteval member function, so I'm assuming this is 
> > correct, but if someone finds a test case that fails here, it's easy enough 
> > to fix.
> This code is only reachable for a call through a pointer-to-member. We don't 
> need to worry about `consteval` member function pointers because they can't 
> escape constant-evaluated contexts anyway. Eg, `(p->*&Class::consteval_fn)()` 
> is ill-formed outside of a constant-evaluated context -- we should make sure 
> we have a test for that.
I can't come up with one either, I think we're fine for now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111817

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

[PATCH] D111817: Fix a rejects-valid with consteval on overloaded operators

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/Sema/SemaOverload.cpp:14290
 
 return MaybeBindToTemporary(call);
   }

erichkeane wrote:
> rsmith wrote:
> > aaron.ballman wrote:
> > > erichkeane wrote:
> > > > Was this one missed too?
> > > I couldn't devise a test case that was failing with member function call 
> > > expressions, so I left this one alone. We have a bunch of existing test 
> > > coverage for calling a consteval member function, so I'm assuming this is 
> > > correct, but if someone finds a test case that fails here, it's easy 
> > > enough to fix.
> > This code is only reachable for a call through a pointer-to-member. We 
> > don't need to worry about `consteval` member function pointers because they 
> > can't escape constant-evaluated contexts anyway. Eg, 
> > `(p->*&Class::consteval_fn)()` is ill-formed outside of a 
> > constant-evaluated context -- we should make sure we have a test for that.
> I can't come up with one either, I think we're fine for now.
```
struct test {
  consteval int f() const { return 12; }
};

constexpr test t;
int main() {
  constexpr int i = (t.*&test::f)();
}
```
@rsmith -- would you expect us to accept or reject this? GCC accepts, MSVC 
rejects, Clang currently rejects. This is different from your test case 
(because this is in a constant evaluated context), which we do already reject 
with a decent message: https://godbolt.org/z/3nv4bco9M


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111817

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

[PATCH] D111793: [Driver][Darwin] Use T reference instead of getToolChain().getTriple().

[Vedant Kumar via Phabricator via cfe-commits]

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

Thanks, lgtm.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111793

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

[PATCH] D111786: [Driver][WebAssembly] Use ToolChain reference instead of getToolChain().

[Frederic Cambus 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 rGf7a3214306cb: [Driver][WebAssembly] Use ToolChain reference 
instead of getToolChain(). (authored by fcambus).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111786

Files:
  clang/lib/Driver/ToolChains/WebAssembly.cpp


Index: clang/lib/Driver/ToolChains/WebAssembly.cpp
===
--- clang/lib/Driver/ToolChains/WebAssembly.cpp
+++ clang/lib/Driver/ToolChains/WebAssembly.cpp
@@ -63,7 +63,7 @@
   ArgStringList CmdArgs;
 
   CmdArgs.push_back("-m");
-  if (getToolChain().getTriple().isArch64Bit())
+  if (ToolChain.getTriple().isArch64Bit())
 CmdArgs.push_back("wasm64");
   else
 CmdArgs.push_back("wasm32");
@@ -130,7 +130,7 @@
 
   // When optimizing, if wasm-opt is available, run it.
   if (Arg *A = Args.getLastArg(options::OPT_O_Group)) {
-auto WasmOptPath = getToolChain().GetProgramPath("wasm-opt");
+auto WasmOptPath = ToolChain.GetProgramPath("wasm-opt");
 if (WasmOptPath != "wasm-opt") {
   StringRef OOpt = "s";
   if (A->getOption().matches(options::OPT_O4) ||


Index: clang/lib/Driver/ToolChains/WebAssembly.cpp
===
--- clang/lib/Driver/ToolChains/WebAssembly.cpp
+++ clang/lib/Driver/ToolChains/WebAssembly.cpp
@@ -63,7 +63,7 @@
   ArgStringList CmdArgs;
 
   CmdArgs.push_back("-m");
-  if (getToolChain().getTriple().isArch64Bit())
+  if (ToolChain.getTriple().isArch64Bit())
 CmdArgs.push_back("wasm64");
   else
 CmdArgs.push_back("wasm32");
@@ -130,7 +130,7 @@
 
   // When optimizing, if wasm-opt is available, run it.
   if (Arg *A = Args.getLastArg(options::OPT_O_Group)) {
-auto WasmOptPath = getToolChain().GetProgramPath("wasm-opt");
+auto WasmOptPath = ToolChain.GetProgramPath("wasm-opt");
 if (WasmOptPath != "wasm-opt") {
   StringRef OOpt = "s";
   if (A->getOption().matches(options::OPT_O4) ||
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] f7a3214 - [Driver][WebAssembly] Use ToolChain reference instead of getToolChain().

[Frederic Cambus via cfe-commits]

Author: Frederic Cambus
Date: 2021-10-14T19:43:59+02:00
New Revision: f7a3214306cb83c350a89e2247f67983dbd792ea

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

LOG: [Driver][WebAssembly] Use ToolChain reference instead of getToolChain().

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

Added: 


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

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/WebAssembly.cpp 
b/clang/lib/Driver/ToolChains/WebAssembly.cpp
index 6ce4f4454487..b1a5e58d2980 100644
--- a/clang/lib/Driver/ToolChains/WebAssembly.cpp
+++ b/clang/lib/Driver/ToolChains/WebAssembly.cpp
@@ -63,7 +63,7 @@ void wasm::Linker::ConstructJob(Compilation &C, const 
JobAction &JA,
   ArgStringList CmdArgs;
 
   CmdArgs.push_back("-m");
-  if (getToolChain().getTriple().isArch64Bit())
+  if (ToolChain.getTriple().isArch64Bit())
 CmdArgs.push_back("wasm64");
   else
 CmdArgs.push_back("wasm32");
@@ -130,7 +130,7 @@ void wasm::Linker::ConstructJob(Compilation &C, const 
JobAction &JA,
 
   // When optimizing, if wasm-opt is available, run it.
   if (Arg *A = Args.getLastArg(options::OPT_O_Group)) {
-auto WasmOptPath = getToolChain().GetProgramPath("wasm-opt");
+auto WasmOptPath = ToolChain.GetProgramPath("wasm-opt");
 if (WasmOptPath != "wasm-opt") {
   StringRef OOpt = "s";
   if (A->getOption().matches(options::OPT_O4) ||



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

[PATCH] D111199: [Clang][LLVM][Attr] support btf_type_tag attribute

[Yonghong Song via Phabricator via cfe-commits]

yonghong-song updated this revision to Diff 379772.
yonghong-song retitled this revision from "[POC][BTF] support btf_type_tag 
attribute" to "[Clang][LLVM][Attr] support btf_type_tag attribute".
yonghong-song edited the summary of this revision.
yonghong-song added a comment.
Herald added subscribers: arphaman, martong.

- remove POC tag and now the implementation is complete
- in this patch, AttributedBTFType is created as a subclass of AttributedType. 
This makes quite some changes in the codebase for processing or handling 
AttributedBTFType. Alternatively, we could amend existing AttributedType to 
have a StringRef to store btf_tag. We can discuss which way is better.
- I may have missed some testing. Let me know what I have missed and I can add 
them.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/PropertiesBase.td
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/AST/Type.h
  clang/include/clang/AST/TypeLoc.h
  clang/include/clang/AST/TypeProperties.td
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/TypeNodes.td
  clang/include/clang/Serialization/ASTRecordWriter.h
  clang/include/clang/Serialization/TypeBitCodes.def
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTStructuralEquivalence.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/TypeLoc.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaType.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/CodeGen/attr-btf_type_tag-conv-var.c
  clang/test/CodeGen/attr-btf_type_tag-typedef-field.c
  clang/test/Sema/attr-btf_type_tag.c
  clang/tools/libclang/CIndex.cpp
  llvm/include/llvm/IR/DIBuilder.h
  llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
  llvm/lib/IR/DIBuilder.cpp
  llvm/test/DebugInfo/attr-btf_type_tag.ll

Index: llvm/test/DebugInfo/attr-btf_type_tag.ll
===
--- /dev/null
+++ llvm/test/DebugInfo/attr-btf_type_tag.ll
@@ -0,0 +1,62 @@
+; REQUIRES: x86-registered-target
+; RUN: llc -filetype=obj -o %t %s
+; RUN: llvm-dwarfdump -debug-info %t | FileCheck %s
+; Source:
+;   #define __tag1 __attribute__((btf_type_tag("tag1")))
+;   #define __tag2 __attribute__((btf_type_tag("tag2")))
+;
+;   int * __tag1 * __tag2 *g;
+; Compilation flag:
+;   clang -target x86_64 -g -S -emit-llvm t.c
+
+@g = dso_local global i32*** null, align 8, !dbg !0
+
+!llvm.dbg.cu = !{!2}
+!llvm.module.flags = !{!13, !14, !15, !16, !17}
+!llvm.ident = !{!18}
+
+!0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
+!1 = distinct !DIGlobalVariable(name: "g", scope: !2, file: !3, line: 4, type: !5, isLocal: false, isDefinition: true)
+!2 = distinct !DICompileUnit(language: DW_LANG_C99, file: !3, producer: "clang version 14.0.0 (https://github.com/llvm/llvm-project.git 2c240a5eefae1a945dfd36cdaa0c677eca90dd82)", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, globals: !4, splitDebugInlining: false, nameTableKind: None)
+!3 = !DIFile(filename: "t.c", directory: "/home/yhs/work/tests/llvm/btf_tag_type")
+!4 = !{!0}
+!5 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !6, size: 64, annotations: !11)
+!6 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !7, size: 64, annotations: !9)
+!7 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !8, size: 64)
+!8 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!9 = !{!10}
+!10 = !{!"btf_type_tag", !"tag1"}
+!11 = !{!12}
+!12 = !{!"btf_type_tag", !"tag2"}
+
+; CHECK:  DW_TAG_variable
+; CHECK-NEXT:   DW_AT_name  ("g")
+; CHECK-NEXT:   DW_AT_type  (0x[[T1:[0-9]+]] "int ***")
+
+; CHECK:  0x[[T1]]: DW_TAG_pointer_type
+; CHECK-NEXT:   DW_AT_type  (0x[[T2:[0-9]+]] "int **")
+
+; CHECK:DW_TAG_LLVM_annotation
+; CHECK-NEXT: DW_AT_name("btf_type_tag")
+; CHECK-NEXT: DW_AT_const_value ("tag2")
+
+; CHECK:NULL
+
+; CHECK:  0x[[T2]]: DW_TAG_pointer_type
+; CHECK-NEXT:   DW_AT_type  (0x[[T3:[0-9]+]] "int *")
+
+; CHECK:DW_TAG_LLVM_annotation
+; CHECK-NEXT: DW_AT_name("btf_type_tag")
+; CHECK-NEXT: DW_AT_const_value ("tag1")
+
+; CHECK:NULL
+
+; CHECK:  0x[[T3]]: DW_TAG_pointer_type
+; CHECK-NEXT:   DW_AT_type  (0x[[#]] "int")
+
+!13 = !{i32 7, !"Dwarf Version", i32 4}
+!14 = !{i32 2, !"Debug Info Version", i32 3}
+!15 = !{i32 1, !"wchar_size", i32 4}
+!16 = !{i32 7, !"uwtable", i32 1}
+!17 = !{i32 7, !"frame-pointer", i32 2}
+!18 = !{!"clang version 14.0.0 (https://github.com/llvm/llvm-project.git 2c240a5eefae1a945dfd36cdaa0c677eca90dd82)"}
Index: llvm/lib/IR/DIBuilder.cpp
===
--- llvm/lib/IR

[PATCH] D107882: BPF: Enable frontend constant folding for VLA size

[Eli Friedman via Phabricator via cfe-commits]

efriedma added a comment.

I don't think my opinion has changed here.  I'm against the solution proposed 
in this patch.  The other solutions discussed in the review seem fine.  (The 
simplest is just to make the bpf backend ignore stacksave/stackrestore calls.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107882

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

[PATCH] D110898: Pass template parameters when printing template argument lists for function templates

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

Ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110898

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

[PATCH] D111767: [clang] Support -clear-ast-before-backend without -disable-free

[Arthur Eubanks via Phabricator via cfe-commits]

aeubanks added inline comments.



Comment at: clang/lib/CodeGen/CodeGenAction.cpp:355-356
+  if (CodeGenOpts.ClearASTBeforeBackend) {
+// The ASTContext may be unusable after this.
+C.cleanup();
 C.getAllocator().Reset();

dblaikie wrote:
> Any chance of refactoring such that the ASTContext is scoped such that it is 
> destroyed here, rather than rendered unusable - to reduce the chance that 
> it'd be accidentally used after this point?
> 
> Like what happens if CompilerInstance::setASTContext(nullptr) is called? It 
> wouldn't null out everyone's ASTContext pointers, but would mean there's no 
> object there - perhaps crash harder/faster than a "cleaned up" ASTContext 
> being used?
I had tried this in the past and gave up for some reason. So I tried again 
(ASan was very helpful here) and ran into a couple of issues.

First, Sema depends on ASTContext, so we have to `setSema(nullptr)` before 
`setASTContext(nullptr)`, but Sema has to finalize some things after codegen, 
so we can't `CI->setSema(nullptr)` until much later.

Another unrelated thing is that the diagnostics end up calling into ASTContext. 
This might be fixable by moving some data structures out of ASTContext?

Another unrelated thing is a weird crash in 
`DiagStorageAllocator::~DiagStorageAllocator()` when calling 
`setASTContext(nullptr)` early.

These individually might be solvable, but it seems like a lot of unrelated 
issues.
Basically, we depend a lot on various parts of ASTContext that aren't the 
actual AST nodes themselves.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111767

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

[PATCH] D111371: [Support][ThinLTO] Move ThinLTO caching to LLVM Support library.

[Noah Shutty via Phabricator via cfe-commits]

noajshu updated this revision to Diff 379787.
noajshu added a comment.

rebase against main


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111371

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  lld/COFF/LTO.cpp
  lld/ELF/LTO.cpp
  lld/MachO/LTO.cpp
  lld/wasm/LTO.cpp
  llvm/include/llvm/LTO/Caching.h
  llvm/include/llvm/LTO/LTO.h
  llvm/include/llvm/LTO/legacy/LTOCodeGenerator.h
  llvm/include/llvm/Support/Caching.h
  llvm/lib/LTO/CMakeLists.txt
  llvm/lib/LTO/Caching.cpp
  llvm/lib/LTO/LTOCodeGenerator.cpp
  llvm/lib/Support/CMakeLists.txt
  llvm/lib/Support/Caching.cpp
  llvm/tools/gold/gold-plugin.cpp
  llvm/tools/llvm-lto/llvm-lto.cpp
  llvm/tools/llvm-lto2/llvm-lto2.cpp

Index: llvm/tools/llvm-lto2/llvm-lto2.cpp
===
--- llvm/tools/llvm-lto2/llvm-lto2.cpp
+++ llvm/tools/llvm-lto2/llvm-lto2.cpp
@@ -19,10 +19,10 @@
 #include "llvm/CodeGen/CommandFlags.h"
 #include "llvm/Config/llvm-config.h"
 #include "llvm/IR/DiagnosticPrinter.h"
-#include "llvm/LTO/Caching.h"
 #include "llvm/LTO/LTO.h"
 #include "llvm/Passes/PassPlugin.h"
 #include "llvm/Remarks/HotnessThresholdParser.h"
+#include "llvm/Support/Caching.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/InitLLVM.h"
@@ -362,14 +362,13 @@
   if (HasErrors)
 return 1;
 
-  auto AddStream =
-  [&](size_t Task) -> std::unique_ptr {
+  auto AddStream = [&](size_t Task) -> std::unique_ptr {
 std::string Path = OutputFilename + "." + utostr(Task);
 
 std::error_code EC;
 auto S = std::make_unique(Path, EC, sys::fs::OF_None);
 check(EC, Path);
-return std::make_unique(std::move(S));
+return std::make_unique(std::move(S));
   };
 
   auto AddBuffer = [&](size_t Task, std::unique_ptr MB) {
@@ -378,7 +377,8 @@
 
   NativeObjectCache Cache;
   if (!CacheDir.empty())
-Cache = check(localCache(CacheDir, AddBuffer), "failed to create cache");
+Cache = check(localCache("ThinLTO", "Thin", CacheDir, AddBuffer),
+  "failed to create cache");
 
   check(Lto.run(AddStream, Cache), "LTO::run failed");
   return 0;
Index: llvm/tools/llvm-lto/llvm-lto.cpp
===
--- llvm/tools/llvm-lto/llvm-lto.cpp
+++ llvm/tools/llvm-lto/llvm-lto.cpp
@@ -1097,8 +1097,7 @@
 error("writing merged module failed.");
 }
 
-auto AddStream =
-[&](size_t Task) -> std::unique_ptr {
+auto AddStream = [&](size_t Task) -> std::unique_ptr {
   std::string PartFilename = OutputFilename;
   if (Parallelism != 1)
 PartFilename += "." + utostr(Task);
@@ -1108,7 +1107,7 @@
   std::make_unique(PartFilename, EC, sys::fs::OF_None);
   if (EC)
 error("error opening the file '" + PartFilename + "': " + EC.message());
-  return std::make_unique(std::move(S));
+  return std::make_unique(std::move(S));
 };
 
 if (!CodeGen.compileOptimized(AddStream, Parallelism))
Index: llvm/tools/gold/gold-plugin.cpp
===
--- llvm/tools/gold/gold-plugin.cpp
+++ llvm/tools/gold/gold-plugin.cpp
@@ -1081,12 +1081,11 @@
   size_t MaxTasks = Lto->getMaxTasks();
   std::vector, bool>> Files(MaxTasks);
 
-  auto AddStream =
-  [&](size_t Task) -> std::unique_ptr {
+  auto AddStream = [&](size_t Task) -> std::unique_ptr {
 Files[Task].second = !SaveTemps;
 int FD = getOutputFileName(Filename, /* TempOutFile */ !SaveTemps,
Files[Task].first, Task);
-return std::make_unique(
+return std::make_unique(
 std::make_unique(FD, true));
   };
 
@@ -1096,7 +1095,7 @@
 
   NativeObjectCache Cache;
   if (!options::cache_dir.empty())
-Cache = check(localCache(options::cache_dir, AddBuffer));
+Cache = check(localCache("ThinLTO", "Thin", options::cache_dir, AddBuffer));
 
   check(Lto->run(AddStream, Cache));
 
Index: llvm/lib/Support/Caching.cpp
===
--- llvm/lib/Support/Caching.cpp
+++ llvm/lib/Support/Caching.cpp
@@ -1,4 +1,4 @@
-//===-Caching.cpp - LLVM Link Time Optimizer Cache Handling ---===//
+//===-Caching.cpp - LLVM File Cache Handling --===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
@@ -6,11 +6,11 @@
 //
 //===--===//
 //
-// This file implements the Caching for ThinLTO.
+// This file implements the Caching used by ThinLTO.
 //
 //===--===//
 
-#include "llvm/LTO/Caching.h"
+#include "llvm/Support/Caching.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/Support/Errc.h"
 #include "

[PATCH] D111767: [clang] Support -clear-ast-before-backend without -disable-free

[David Blaikie via Phabricator via cfe-commits]

dblaikie accepted this revision.
dblaikie added subscribers: aaron.ballman, rsmith.
dblaikie added a comment.
This revision is now accepted and ready to land.

Sounds OK, thanks!




Comment at: clang/lib/CodeGen/CodeGenAction.cpp:355-356
+  if (CodeGenOpts.ClearASTBeforeBackend) {
+// The ASTContext may be unusable after this.
+C.cleanup();
 C.getAllocator().Reset();

aeubanks wrote:
> dblaikie wrote:
> > Any chance of refactoring such that the ASTContext is scoped such that it 
> > is destroyed here, rather than rendered unusable - to reduce the chance 
> > that it'd be accidentally used after this point?
> > 
> > Like what happens if CompilerInstance::setASTContext(nullptr) is called? It 
> > wouldn't null out everyone's ASTContext pointers, but would mean there's no 
> > object there - perhaps crash harder/faster than a "cleaned up" ASTContext 
> > being used?
> I had tried this in the past and gave up for some reason. So I tried again 
> (ASan was very helpful here) and ran into a couple of issues.
> 
> First, Sema depends on ASTContext, so we have to `setSema(nullptr)` before 
> `setASTContext(nullptr)`, but Sema has to finalize some things after codegen, 
> so we can't `CI->setSema(nullptr)` until much later.
> 
> Another unrelated thing is that the diagnostics end up calling into 
> ASTContext. This might be fixable by moving some data structures out of 
> ASTContext?
> 
> Another unrelated thing is a weird crash in 
> `DiagStorageAllocator::~DiagStorageAllocator()` when calling 
> `setASTContext(nullptr)` early.
> 
> These individually might be solvable, but it seems like a lot of unrelated 
> issues.
> Basically, we depend a lot on various parts of ASTContext that aren't the 
> actual AST nodes themselves.
Fair enough - not sure, but might be worth noting this info somewhere in the 
source in case someone else comes along to do this refactoring in the future if 
they have another reason to weigh into the choice to address it.

@rsmith @aaron.ballman - wouldn't mind at least a quick thought on this stuff 
if you've both got a moment - for long term direction/broad design of this 
stuff.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111767

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

[PATCH] D111817: Fix a rejects-valid with consteval on overloaded operators

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/Sema/SemaOverload.cpp:14290
 
 return MaybeBindToTemporary(call);
   }

aaron.ballman wrote:
> erichkeane wrote:
> > rsmith wrote:
> > > aaron.ballman wrote:
> > > > erichkeane wrote:
> > > > > Was this one missed too?
> > > > I couldn't devise a test case that was failing with member function 
> > > > call expressions, so I left this one alone. We have a bunch of existing 
> > > > test coverage for calling a consteval member function, so I'm assuming 
> > > > this is correct, but if someone finds a test case that fails here, it's 
> > > > easy enough to fix.
> > > This code is only reachable for a call through a pointer-to-member. We 
> > > don't need to worry about `consteval` member function pointers because 
> > > they can't escape constant-evaluated contexts anyway. Eg, 
> > > `(p->*&Class::consteval_fn)()` is ill-formed outside of a 
> > > constant-evaluated context -- we should make sure we have a test for that.
> > I can't come up with one either, I think we're fine for now.
> ```
> struct test {
>   consteval int f() const { return 12; }
> };
> 
> constexpr test t;
> int main() {
>   constexpr int i = (t.*&test::f)();
> }
> ```
> @rsmith -- would you expect us to accept or reject this? GCC accepts, MSVC 
> rejects, Clang currently rejects. This is different from your test case 
> (because this is in a constant evaluated context), which we do already reject 
> with a decent message: https://godbolt.org/z/3nv4bco9M
Thinking about this a bit more, I think that code should be accepted.
```
struct test {
  consteval int f() const { return 12; }
};

constexpr test t;
int main() {
  constexpr int i = t.f(); // If this works
  constexpr int j = (t.*&test::f)(); // This should also work
}
```
However, when I make the obvious changes in this patch to support it, we stop 
getting the diagnostic outside of a constant evaluated context. So my plan is 
to land the small fixes we know are correct and are happy with, and we can 
debate this case more later.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111817

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

[PATCH] D111817: Fix a rejects-valid with consteval on overloaded operators

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman updated this revision to Diff 379795.
aaron.ballman added a comment.

Updated the patch to add new test cases.


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

https://reviews.llvm.org/D111817

Files:
  clang/lib/Sema/SemaOverload.cpp
  clang/test/SemaCXX/cxx2a-consteval.cpp


Index: clang/test/SemaCXX/cxx2a-consteval.cpp
===
--- clang/test/SemaCXX/cxx2a-consteval.cpp
+++ clang/test/SemaCXX/cxx2a-consteval.cpp
@@ -612,3 +612,34 @@
 static_assert(is_same::value);
 
 } // namespace unevaluated
+
+namespace PR50779 {
+struct derp {
+  int b = 0;
+};
+
+constexpr derp d;
+
+struct test {
+  consteval int operator[](int i) const { return {}; }
+  consteval const derp * operator->() const { return &d; }
+  consteval int f() const { return 12; } // expected-note 2{{declared here}}
+};
+
+constexpr test a;
+
+// We previously rejected both of these overloaded operators as taking the
+// address of a consteval function outside of an immediate context, but we
+// accepted direct calls to the overloaded operator. Now we show that we accept
+// both forms.
+constexpr int s = a.operator[](1);
+constexpr int t = a[1];
+constexpr int u = a.operator->()->b;
+constexpr int v = a->b;
+// FIXME: I believe this case should work, but we currently reject.
+constexpr int w = (a.*&test::f)(); // expected-error {{cannot take address of 
consteval function 'f' outside of an immediate invocation}}
+constexpr int x = a.f();
+
+// Show that we reject when not in an immediate context.
+int w2 = (a.*&test::f)(); // expected-error {{cannot take address of consteval 
function 'f' outside of an immediate invocation}}
+}
Index: clang/lib/Sema/SemaOverload.cpp
===
--- clang/lib/Sema/SemaOverload.cpp
+++ clang/lib/Sema/SemaOverload.cpp
@@ -14161,7 +14161,8 @@
   Method->getType()->castAs()))
   return ExprError();
 
-return MaybeBindToTemporary(TheCall);
+return CheckForImmediateInvocation(MaybeBindToTemporary(TheCall),
+   FnDecl);
   } else {
 // We matched a built-in operator. Convert the arguments, then
 // break out so that we will build the appropriate built-in
@@ -14916,7 +14917,7 @@
 Method->getType()->castAs()))
 return ExprError();
 
-  return MaybeBindToTemporary(TheCall);
+  return CheckForImmediateInvocation(MaybeBindToTemporary(TheCall), Method);
 }
 
 /// BuildLiteralOperatorCall - Build a UserDefinedLiteral by creating a call to


Index: clang/test/SemaCXX/cxx2a-consteval.cpp
===
--- clang/test/SemaCXX/cxx2a-consteval.cpp
+++ clang/test/SemaCXX/cxx2a-consteval.cpp
@@ -612,3 +612,34 @@
 static_assert(is_same::value);
 
 } // namespace unevaluated
+
+namespace PR50779 {
+struct derp {
+  int b = 0;
+};
+
+constexpr derp d;
+
+struct test {
+  consteval int operator[](int i) const { return {}; }
+  consteval const derp * operator->() const { return &d; }
+  consteval int f() const { return 12; } // expected-note 2{{declared here}}
+};
+
+constexpr test a;
+
+// We previously rejected both of these overloaded operators as taking the
+// address of a consteval function outside of an immediate context, but we
+// accepted direct calls to the overloaded operator. Now we show that we accept
+// both forms.
+constexpr int s = a.operator[](1);
+constexpr int t = a[1];
+constexpr int u = a.operator->()->b;
+constexpr int v = a->b;
+// FIXME: I believe this case should work, but we currently reject.
+constexpr int w = (a.*&test::f)(); // expected-error {{cannot take address of consteval function 'f' outside of an immediate invocation}}
+constexpr int x = a.f();
+
+// Show that we reject when not in an immediate context.
+int w2 = (a.*&test::f)(); // expected-error {{cannot take address of consteval function 'f' outside of an immediate invocation}}
+}
Index: clang/lib/Sema/SemaOverload.cpp
===
--- clang/lib/Sema/SemaOverload.cpp
+++ clang/lib/Sema/SemaOverload.cpp
@@ -14161,7 +14161,8 @@
   Method->getType()->castAs()))
   return ExprError();
 
-return MaybeBindToTemporary(TheCall);
+return CheckForImmediateInvocation(MaybeBindToTemporary(TheCall),
+   FnDecl);
   } else {
 // We matched a built-in operator. Convert the arguments, then
 // break out so that we will build the appropriate built-in
@@ -14916,7 +14917,7 @@
 Method->getType()->castAs()))
 return ExprError();
 
-  return MaybeBindToTemporary(TheCall);
+  return CheckForImmediateInvocation(MaybeBindToTemporary(TheCall), Method);
 }
 
 /// BuildLiteralOperatorCall - Build a UserDefinedLiteral by creating a call to
___

[clang] b9941de - Fix a rejects-valid with consteval on overloaded operators

[Aaron Ballman via cfe-commits]

Author: Aaron Ballman
Date: 2021-10-14T14:47:29-04:00
New Revision: b9941de0bfac4bad93e11dff26396e34a53e3891

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

LOG: Fix a rejects-valid with consteval on overloaded operators

It seems that Clang 11 regressed functionality that was working in
Clang 10 regarding calling a few overloaded operators in an immediate
context. Specifically, we were not checking for immediate invocations
of array subscripting and the arrow operators, but we properly handle
the other overloaded operators.

This fixes the two problematic operators and adds some test coverage to
show they're equivalent to calling the operator directly.

This addresses PR50779.

Added: 


Modified: 
clang/lib/Sema/SemaOverload.cpp
clang/test/SemaCXX/cxx2a-consteval.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaOverload.cpp b/clang/lib/Sema/SemaOverload.cpp
index 044e3c4b254ad..d93fd9df0093e 100644
--- a/clang/lib/Sema/SemaOverload.cpp
+++ b/clang/lib/Sema/SemaOverload.cpp
@@ -14161,7 +14161,8 @@ Sema::CreateOverloadedArraySubscriptExpr(SourceLocation 
LLoc,
   Method->getType()->castAs()))
   return ExprError();
 
-return MaybeBindToTemporary(TheCall);
+return CheckForImmediateInvocation(MaybeBindToTemporary(TheCall),
+   FnDecl);
   } else {
 // We matched a built-in operator. Convert the arguments, then
 // break out so that we will build the appropriate built-in
@@ -14916,7 +14917,7 @@ Sema::BuildOverloadedArrowExpr(Scope *S, Expr *Base, 
SourceLocation OpLoc,
 Method->getType()->castAs()))
 return ExprError();
 
-  return MaybeBindToTemporary(TheCall);
+  return CheckForImmediateInvocation(MaybeBindToTemporary(TheCall), Method);
 }
 
 /// BuildLiteralOperatorCall - Build a UserDefinedLiteral by creating a call to

diff  --git a/clang/test/SemaCXX/cxx2a-consteval.cpp 
b/clang/test/SemaCXX/cxx2a-consteval.cpp
index 04c8898aa5bad..c1e713a5b6b79 100644
--- a/clang/test/SemaCXX/cxx2a-consteval.cpp
+++ b/clang/test/SemaCXX/cxx2a-consteval.cpp
@@ -612,3 +612,34 @@ using T = decltype(g(f()));
 static_assert(is_same::value);
 
 } // namespace unevaluated
+
+namespace PR50779 {
+struct derp {
+  int b = 0;
+};
+
+constexpr derp d;
+
+struct test {
+  consteval int operator[](int i) const { return {}; }
+  consteval const derp * operator->() const { return &d; }
+  consteval int f() const { return 12; } // expected-note 2{{declared here}}
+};
+
+constexpr test a;
+
+// We previously rejected both of these overloaded operators as taking the
+// address of a consteval function outside of an immediate context, but we
+// accepted direct calls to the overloaded operator. Now we show that we accept
+// both forms.
+constexpr int s = a.operator[](1);
+constexpr int t = a[1];
+constexpr int u = a.operator->()->b;
+constexpr int v = a->b;
+// FIXME: I believe this case should work, but we currently reject.
+constexpr int w = (a.*&test::f)(); // expected-error {{cannot take address of 
consteval function 'f' outside of an immediate invocation}}
+constexpr int x = a.f();
+
+// Show that we reject when not in an immediate context.
+int w2 = (a.*&test::f)(); // expected-error {{cannot take address of consteval 
function 'f' outside of an immediate invocation}}
+}



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

[PATCH] D111817: Fix a rejects-valid with consteval on overloaded operators

[Aaron Ballman via Phabricator via cfe-commits]

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

I landed the non-pmf changes in b9941de0bfac4bad93e11dff26396e34a53e3891 



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

https://reviews.llvm.org/D111817

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

[PATCH] D111720: [clang][deps] Ensure reported context hash is strict

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 added inline comments.



Comment at: clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp:56-58
+  // Ensure the reported context hash is strict.
+  CI.getHeaderSearchOpts().ModulesStrictContextHash = true;
+

dexonsmith wrote:
> IIUC, explicit modules don't really have/need a context hash. Can related 
> options be stripped out when serializing to `-cc1` when `ImplicitModules` is 
> false?
> 
> Basically, I'm asking if `ModulesStrictContextHash` is a no-op when 
> `ImplicitModules` is false. If not, can we make it a no-op?
> (If we can, then maybe rename the field to `ImplicitModulesStrictContextHash` 
> and audit that no one reads it when `ImplicitModules` is off...)
Let me clarify this a bit. You're right that when building explicit modules, we 
don't care about context hash.

We do care about using **strict** context hash during the scan though - it's an 
implementation detail through which we prevent mixing incompatible modules/TUs. 
(This strict context hash is enabled elsewhere in the dependency scanner.)

At the end of the scan, we take discovered modules and modify/prune their 
`CompilerInvocation` (in this function). This can essentially "merge" multiple 
versions of the same module into one, which is very desirable. But we still 
want to do it according to the **strict** context hash. We don't want to merge 
versions with different search paths for example (non-strict context hash). 
That's what this change ensures.

Note that we don't **need** to report context hashes to scanner clients. Any 
other identifier derived from a strict context hash would work.



Comment at: clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp:56-58
+  // Ensure the reported context hash is strict.
+  CI.getHeaderSearchOpts().ModulesStrictContextHash = true;
+

jansvoboda11 wrote:
> dexonsmith wrote:
> > IIUC, explicit modules don't really have/need a context hash. Can related 
> > options be stripped out when serializing to `-cc1` when `ImplicitModules` 
> > is false?
> > 
> > Basically, I'm asking if `ModulesStrictContextHash` is a no-op when 
> > `ImplicitModules` is false. If not, can we make it a no-op?
> > (If we can, then maybe rename the field to 
> > `ImplicitModulesStrictContextHash` and audit that no one reads it when 
> > `ImplicitModules` is off...)
> Let me clarify this a bit. You're right that when building explicit modules, 
> we don't care about context hash.
> 
> We do care about using **strict** context hash during the scan though - it's 
> an implementation detail through which we prevent mixing incompatible 
> modules/TUs. (This strict context hash is enabled elsewhere in the dependency 
> scanner.)
> 
> At the end of the scan, we take discovered modules and modify/prune their 
> `CompilerInvocation` (in this function). This can essentially "merge" 
> multiple versions of the same module into one, which is very desirable. But 
> we still want to do it according to the **strict** context hash. We don't 
> want to merge versions with different search paths for example (non-strict 
> context hash). That's what this change ensures.
> 
> Note that we don't **need** to report context hashes to scanner clients. Any 
> other identifier derived from a strict context hash would work.
I think the rename you're suggesting is valid.

We //could// strip the `ModulesStrictContextHash` in the scanner: after we 
generate the strict context hash and before we generate the command-line. I 
think that can be done in a NFC follow-up.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111720

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

[clang] 8ecbcd0 - [Driver][Darwin] Use T reference instead of getToolChain().getTriple().

[Frederic Cambus via cfe-commits]

Author: Frederic Cambus
Date: 2021-10-14T21:30:39+02:00
New Revision: 8ecbcd058fbd552375fda614f36a1e01755c2620

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

LOG: [Driver][Darwin] Use T reference instead of getToolChain().getTriple().

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

Added: 


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

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Darwin.cpp 
b/clang/lib/Driver/ToolChains/Darwin.cpp
index 8f3b6336d59d..5062c33bb096 100644
--- a/clang/lib/Driver/ToolChains/Darwin.cpp
+++ b/clang/lib/Driver/ToolChains/Darwin.cpp
@@ -94,6 +94,8 @@ void darwin::Assembler::ConstructJob(Compilation &C, const 
JobAction &JA,
  const InputInfoList &Inputs,
  const ArgList &Args,
  const char *LinkingOutput) const {
+  const llvm::Triple &T(getToolChain().getTriple());
+
   ArgStringList CmdArgs;
 
   assert(Inputs.size() == 1 && "Unexpected number of inputs.");
@@ -112,7 +114,6 @@ void darwin::Assembler::ConstructJob(Compilation &C, const 
JobAction &JA,
   // FIXME: at run-time detect assembler capabilities or rely on version
   // information forwarded by -target-assembler-version.
   if (Args.hasArg(options::OPT_fno_integrated_as)) {
-const llvm::Triple &T(getToolChain().getTriple());
 if (!(T.isMacOSX() && T.isMacOSXVersionLT(10, 7)))
   CmdArgs.push_back("-Q");
   }
@@ -130,8 +131,7 @@ void darwin::Assembler::ConstructJob(Compilation &C, const 
JobAction &JA,
   AddMachOArch(Args, CmdArgs);
 
   // Use -force_cpusubtype_ALL on x86 by default.
-  if (getToolChain().getTriple().isX86() ||
-  Args.hasArg(options::OPT_force__cpusubtype__ALL))
+  if (T.isX86() || Args.hasArg(options::OPT_force__cpusubtype__ALL))
 CmdArgs.push_back("-force_cpusubtype_ALL");
 
   if (getToolChain().getArch() != llvm::Triple::x86_64 &&



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

[PATCH] D111793: [Driver][Darwin] Use T reference instead of getToolChain().getTriple().

[Frederic Cambus 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 rG8ecbcd058fbd: [Driver][Darwin] Use T reference instead of 
getToolChain().getTriple(). (authored by fcambus).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111793

Files:
  clang/lib/Driver/ToolChains/Darwin.cpp


Index: clang/lib/Driver/ToolChains/Darwin.cpp
===
--- clang/lib/Driver/ToolChains/Darwin.cpp
+++ clang/lib/Driver/ToolChains/Darwin.cpp
@@ -94,6 +94,8 @@
  const InputInfoList &Inputs,
  const ArgList &Args,
  const char *LinkingOutput) const {
+  const llvm::Triple &T(getToolChain().getTriple());
+
   ArgStringList CmdArgs;
 
   assert(Inputs.size() == 1 && "Unexpected number of inputs.");
@@ -112,7 +114,6 @@
   // FIXME: at run-time detect assembler capabilities or rely on version
   // information forwarded by -target-assembler-version.
   if (Args.hasArg(options::OPT_fno_integrated_as)) {
-const llvm::Triple &T(getToolChain().getTriple());
 if (!(T.isMacOSX() && T.isMacOSXVersionLT(10, 7)))
   CmdArgs.push_back("-Q");
   }
@@ -130,8 +131,7 @@
   AddMachOArch(Args, CmdArgs);
 
   // Use -force_cpusubtype_ALL on x86 by default.
-  if (getToolChain().getTriple().isX86() ||
-  Args.hasArg(options::OPT_force__cpusubtype__ALL))
+  if (T.isX86() || Args.hasArg(options::OPT_force__cpusubtype__ALL))
 CmdArgs.push_back("-force_cpusubtype_ALL");
 
   if (getToolChain().getArch() != llvm::Triple::x86_64 &&


Index: clang/lib/Driver/ToolChains/Darwin.cpp
===
--- clang/lib/Driver/ToolChains/Darwin.cpp
+++ clang/lib/Driver/ToolChains/Darwin.cpp
@@ -94,6 +94,8 @@
  const InputInfoList &Inputs,
  const ArgList &Args,
  const char *LinkingOutput) const {
+  const llvm::Triple &T(getToolChain().getTriple());
+
   ArgStringList CmdArgs;
 
   assert(Inputs.size() == 1 && "Unexpected number of inputs.");
@@ -112,7 +114,6 @@
   // FIXME: at run-time detect assembler capabilities or rely on version
   // information forwarded by -target-assembler-version.
   if (Args.hasArg(options::OPT_fno_integrated_as)) {
-const llvm::Triple &T(getToolChain().getTriple());
 if (!(T.isMacOSX() && T.isMacOSXVersionLT(10, 7)))
   CmdArgs.push_back("-Q");
   }
@@ -130,8 +131,7 @@
   AddMachOArch(Args, CmdArgs);
 
   // Use -force_cpusubtype_ALL on x86 by default.
-  if (getToolChain().getTriple().isX86() ||
-  Args.hasArg(options::OPT_force__cpusubtype__ALL))
+  if (T.isX86() || Args.hasArg(options::OPT_force__cpusubtype__ALL))
 CmdArgs.push_back("-force_cpusubtype_ALL");
 
   if (getToolChain().getArch() != llvm::Triple::x86_64 &&
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109128: [VFS] Use original path when falling back to external FS

[Jonas Devlieghere via Phabricator via cfe-commits]

JDevlieghere added inline comments.



Comment at: llvm/lib/Support/VirtualFileSystem.cpp:1179-1180
 
+  if (ExternalFS)
+ExternalFS->setCurrentWorkingDirectory(Path);
+

I'm pretty sure there was a reason we stopped doing this. There should be some 
discussion about that in my original patch. 



Comment at: llvm/lib/Support/VirtualFileSystem.cpp:2012
+  if (auto Result = ExternalFS->status(CanonicalPath)) {
+return Result.get().copyWithNewName(Result.get(), OriginalPath);
+  } else {

Can we abstract this in a function similar to `getRedirectedFileStatus`, 
something like `getOrginialFileStatus` or `getNonCanonicalizedFileStatus` and 
have a comment explaining what it does and why? 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109128

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

[PATCH] D111270: [clang] Pass -clear-ast-before-backend in Clang::ConstructJob()

[David Blaikie via Phabricator via cfe-commits]

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

In D111270#3062802 , @aeubanks wrote:

> In D111270#3060484 , @dblaikie 
> wrote:
>
>> Plan is still to address the "this only works with disable free" issue? 
>> (I've some preference that be addressed before this feature is turned on by 
>> default)
>
> https://reviews.llvm.org/D111767. Thanks for pushing back, this actually does 
> help a bit more with memory savings. I was worried that we'd be doing a bunch 
> of pointer chasing if we supported -clear-ast-before-backend without 
> -disable-free but couldn't measure any runtime regressions aside from some 
> nullifying tiny wins gained by this patch.

Great, thanks for that!

>> & is there a flag to pass to turn this off if someone had trouble with it? 
>> (doesn't necessarily have to be, but just checking)
>
> Just like `-disable-free` doesn't have a flag, I don't want one for this at 
> least for now. I'd rather just revert this change and fix any issues. If we 
> come across weird issues then we may have to add a flag.

Yep, sounds good to me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111270

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

[PATCH] D90121: clang-format: Add a consumer to diagnostics engine

[Kirill Dmitrenko via Phabricator via cfe-commits]

dmikis added a comment.

> I took a look and in its simplest form moving TextDiagnosticPrinter.cpp to 
> lib/Basic but also requires DiagnosticRender.cpp and TextDiagnostic.cpp to 
> also move to lib/Basic too,
>
> But DiagnosticRender.cpp has a dependency on lib/Edit so clang-format now 
> needs that as a dependency, is that better/worse than having a dependency on 
> lib/FrontEnd? (not sure why I don't have to provide "Edit" as a dependency 
> when including FrontEnd!)

I did make an attempt to move those classes to lib/Basic but ultimately 
dependency tree turned out to be too complex for me to tackle (IIRC, it 
basically ended up depending upon Lexer or something similar, that wasn't 
appropriate to move to lib/Basic). Since we used heavily patched version of 
clang-format (including this patch) that problem didn't bugged us and I kinda 
moved on to other things :/


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90121

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

[clang] 68157fe - Fix a crash on valid consteval code.

[Aaron Ballman via cfe-commits]

Author: Aaron Ballman
Date: 2021-10-14T15:48:10-04:00
New Revision: 68157fe15b238428d0fdbeb38c14afd5bda574da

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

LOG: Fix a crash on valid consteval code.

Not all constants are emitted within the context of a function, so use
the module's ASTContext instead because 1) that's the same as the
current function ASTContext, and 2) the module can never be null.

Fixes PR50787.

Added: 
clang/test/CodeGenCXX/cxx20-consteval-crash.cpp

Modified: 
clang/lib/CodeGen/CGExprConstant.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGExprConstant.cpp 
b/clang/lib/CodeGen/CGExprConstant.cpp
index 734024149bbbe..d9ecf57a9ab52 100644
--- a/clang/lib/CodeGen/CGExprConstant.cpp
+++ b/clang/lib/CodeGen/CGExprConstant.cpp
@@ -1369,7 +1369,7 @@ llvm::Constant 
*ConstantEmitter::tryEmitConstantExpr(const ConstantExpr *CE) {
   const Expr *Inner = CE->getSubExpr()->IgnoreImplicit();
   QualType RetType;
   if (auto *Call = dyn_cast(Inner))
-RetType = Call->getCallReturnType(CGF->getContext());
+RetType = Call->getCallReturnType(CGM.getContext());
   else if (auto *Ctor = dyn_cast(Inner))
 RetType = Ctor->getType();
   llvm::Constant *Res =

diff  --git a/clang/test/CodeGenCXX/cxx20-consteval-crash.cpp 
b/clang/test/CodeGenCXX/cxx20-consteval-crash.cpp
new file mode 100644
index 0..ef868fa85749f
--- /dev/null
+++ b/clang/test/CodeGenCXX/cxx20-consteval-crash.cpp
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -std=c++20 %s -emit-llvm 
-o - | FileCheck %s
+
+namespace PR50787 {
+// This code would previously cause a crash.
+extern int x_;
+consteval auto& X() { return x_; }
+constexpr auto& x1 = X();
+auto x2 = X();
+
+// CHECK: @_ZN7PR507872x_E = external global i32, align 4
+// CHECK-NEXT: @_ZN7PR507872x1E = constant i32* @_ZN7PR507872x_E, align 8
+// CHECK-NEXT: @_ZN7PR507872x2E = global i32* @_ZN7PR507872x_E, align 4
+}
+



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

[PATCH] D111199: [Clang][LLVM][Attr] support btf_type_tag attribute

[Yonghong Song via Phabricator via cfe-commits]

yonghong-song updated this revision to Diff 379807.
yonghong-song added a comment.

- fix clang-format issues.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/PropertiesBase.td
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/AST/Type.h
  clang/include/clang/AST/TypeLoc.h
  clang/include/clang/AST/TypeProperties.td
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/TypeNodes.td
  clang/include/clang/Serialization/ASTRecordWriter.h
  clang/include/clang/Serialization/TypeBitCodes.def
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTStructuralEquivalence.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/TypeLoc.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaType.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/CodeGen/attr-btf_type_tag-conv-var.c
  clang/test/CodeGen/attr-btf_type_tag-typedef-field.c
  clang/test/Sema/attr-btf_type_tag.c
  clang/tools/libclang/CIndex.cpp
  llvm/include/llvm/IR/DIBuilder.h
  llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
  llvm/lib/IR/DIBuilder.cpp
  llvm/test/DebugInfo/attr-btf_type_tag.ll

Index: llvm/test/DebugInfo/attr-btf_type_tag.ll
===
--- /dev/null
+++ llvm/test/DebugInfo/attr-btf_type_tag.ll
@@ -0,0 +1,62 @@
+; REQUIRES: x86-registered-target
+; RUN: llc -filetype=obj -o %t %s
+; RUN: llvm-dwarfdump -debug-info %t | FileCheck %s
+; Source:
+;   #define __tag1 __attribute__((btf_type_tag("tag1")))
+;   #define __tag2 __attribute__((btf_type_tag("tag2")))
+;
+;   int * __tag1 * __tag2 *g;
+; Compilation flag:
+;   clang -target x86_64 -g -S -emit-llvm t.c
+
+@g = dso_local global i32*** null, align 8, !dbg !0
+
+!llvm.dbg.cu = !{!2}
+!llvm.module.flags = !{!13, !14, !15, !16, !17}
+!llvm.ident = !{!18}
+
+!0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
+!1 = distinct !DIGlobalVariable(name: "g", scope: !2, file: !3, line: 4, type: !5, isLocal: false, isDefinition: true)
+!2 = distinct !DICompileUnit(language: DW_LANG_C99, file: !3, producer: "clang version 14.0.0 (https://github.com/llvm/llvm-project.git 2c240a5eefae1a945dfd36cdaa0c677eca90dd82)", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, globals: !4, splitDebugInlining: false, nameTableKind: None)
+!3 = !DIFile(filename: "t.c", directory: "/home/yhs/work/tests/llvm/btf_tag_type")
+!4 = !{!0}
+!5 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !6, size: 64, annotations: !11)
+!6 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !7, size: 64, annotations: !9)
+!7 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !8, size: 64)
+!8 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!9 = !{!10}
+!10 = !{!"btf_type_tag", !"tag1"}
+!11 = !{!12}
+!12 = !{!"btf_type_tag", !"tag2"}
+
+; CHECK:  DW_TAG_variable
+; CHECK-NEXT:   DW_AT_name  ("g")
+; CHECK-NEXT:   DW_AT_type  (0x[[T1:[0-9]+]] "int ***")
+
+; CHECK:  0x[[T1]]: DW_TAG_pointer_type
+; CHECK-NEXT:   DW_AT_type  (0x[[T2:[0-9]+]] "int **")
+
+; CHECK:DW_TAG_LLVM_annotation
+; CHECK-NEXT: DW_AT_name("btf_type_tag")
+; CHECK-NEXT: DW_AT_const_value ("tag2")
+
+; CHECK:NULL
+
+; CHECK:  0x[[T2]]: DW_TAG_pointer_type
+; CHECK-NEXT:   DW_AT_type  (0x[[T3:[0-9]+]] "int *")
+
+; CHECK:DW_TAG_LLVM_annotation
+; CHECK-NEXT: DW_AT_name("btf_type_tag")
+; CHECK-NEXT: DW_AT_const_value ("tag1")
+
+; CHECK:NULL
+
+; CHECK:  0x[[T3]]: DW_TAG_pointer_type
+; CHECK-NEXT:   DW_AT_type  (0x[[#]] "int")
+
+!13 = !{i32 7, !"Dwarf Version", i32 4}
+!14 = !{i32 2, !"Debug Info Version", i32 3}
+!15 = !{i32 1, !"wchar_size", i32 4}
+!16 = !{i32 7, !"uwtable", i32 1}
+!17 = !{i32 7, !"frame-pointer", i32 2}
+!18 = !{!"clang version 14.0.0 (https://github.com/llvm/llvm-project.git 2c240a5eefae1a945dfd36cdaa0c677eca90dd82)"}
Index: llvm/lib/IR/DIBuilder.cpp
===
--- llvm/lib/IR/DIBuilder.cpp
+++ llvm/lib/IR/DIBuilder.cpp
@@ -292,12 +292,13 @@
 uint64_t SizeInBits,
 uint32_t AlignInBits,
 Optional DWARFAddressSpace,
-StringRef Name) {
+StringRef Name,
+DINodeArray Annotations) {
   // FIXME: Why is there a name here?
   return DIDerivedType::get(VMContext, dwarf::DW_TAG_pointer_type, Name,
 nullptr, 0, nullptr, PointeeTy, SizeInBits,
 AlignInBits, 0, DWARFAddressSpace,
-DINode::FlagZero);
+DINode::FlagZero, nullptr, Annotations);
 }
 
 DIDerivedType *DIBuilder::createMemberPointerType(DITy

[PATCH] D111830: [clang] fix typo correction not looking for candidates in base classes.

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov created this revision.
mizvekov requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

RecordMemberExprValidator was not looking through ElaboratedType
nodes when looking for candidates which occur in base classes.

Signed-off-by: Matheus Izvekov 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D111830

Files:
  clang/lib/Sema/SemaExprMember.cpp
  clang/test/CXX/drs/dr1xx.cpp


Index: clang/test/CXX/drs/dr1xx.cpp
===
--- clang/test/CXX/drs/dr1xx.cpp
+++ clang/test/CXX/drs/dr1xx.cpp
@@ -477,7 +477,7 @@
 
 namespace dr141 { // dr141: yes
   template void f();
-  template struct S { int n; };
+  template struct S { int n; }; // expected-note 
{{'::dr141::S::n' declared here}}
   struct A : S {
 template void f();
 template struct S {};
Index: clang/lib/Sema/SemaExprMember.cpp
===
--- clang/lib/Sema/SemaExprMember.cpp
+++ clang/lib/Sema/SemaExprMember.cpp
@@ -611,11 +611,10 @@
 if (Record->containsDecl(ND))
   return true;
 
-if (const CXXRecordDecl *RD = dyn_cast(Record)) {
+if (const auto *RD = dyn_cast(Record)) {
   // Accept candidates that occur in any of the current class' base 
classes.
   for (const auto &BS : RD->bases()) {
-if (const RecordType *BSTy =
-dyn_cast_or_null(BS.getType().getTypePtrOrNull())) 
{
+if (const auto *BSTy = BS.getType()->getAs()) {
   if (BSTy->getDecl()->containsDecl(ND))
 return true;
 }


Index: clang/test/CXX/drs/dr1xx.cpp
===
--- clang/test/CXX/drs/dr1xx.cpp
+++ clang/test/CXX/drs/dr1xx.cpp
@@ -477,7 +477,7 @@
 
 namespace dr141 { // dr141: yes
   template void f();
-  template struct S { int n; };
+  template struct S { int n; }; // expected-note {{'::dr141::S::n' declared here}}
   struct A : S {
 template void f();
 template struct S {};
Index: clang/lib/Sema/SemaExprMember.cpp
===
--- clang/lib/Sema/SemaExprMember.cpp
+++ clang/lib/Sema/SemaExprMember.cpp
@@ -611,11 +611,10 @@
 if (Record->containsDecl(ND))
   return true;
 
-if (const CXXRecordDecl *RD = dyn_cast(Record)) {
+if (const auto *RD = dyn_cast(Record)) {
   // Accept candidates that occur in any of the current class' base classes.
   for (const auto &BS : RD->bases()) {
-if (const RecordType *BSTy =
-dyn_cast_or_null(BS.getType().getTypePtrOrNull())) {
+if (const auto *BSTy = BS.getType()->getAs()) {
   if (BSTy->getDecl()->containsDecl(ND))
 return true;
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D111443: [Driver] Fix ToolChain::getSanitizerArgs

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl updated this revision to Diff 379806.
yaxunl edited the summary of this revision.
yaxunl added a comment.

diagnose sanitizer args only once.


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

https://reviews.llvm.org/D111443

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/SanitizerArgs.h
  clang/include/clang/Driver/ToolChain.h
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/SanitizerArgs.cpp
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/AIX.h
  clang/lib/Driver/ToolChains/AMDGPU.h
  clang/lib/Driver/ToolChains/BareMetal.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/CloudABI.cpp
  clang/lib/Driver/ToolChains/CloudABI.h
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/CrossWindows.cpp
  clang/lib/Driver/ToolChains/CrossWindows.h
  clang/lib/Driver/ToolChains/Cuda.h
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/lib/Driver/ToolChains/Darwin.h
  clang/lib/Driver/ToolChains/FreeBSD.cpp
  clang/lib/Driver/ToolChains/FreeBSD.h
  clang/lib/Driver/ToolChains/Fuchsia.cpp
  clang/lib/Driver/ToolChains/Fuchsia.h
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/lib/Driver/ToolChains/Gnu.h
  clang/lib/Driver/ToolChains/HIP.cpp
  clang/lib/Driver/ToolChains/Haiku.h
  clang/lib/Driver/ToolChains/Linux.cpp
  clang/lib/Driver/ToolChains/Linux.h
  clang/lib/Driver/ToolChains/MSP430.h
  clang/lib/Driver/ToolChains/MSVC.cpp
  clang/lib/Driver/ToolChains/MSVC.h
  clang/lib/Driver/ToolChains/MinGW.cpp
  clang/lib/Driver/ToolChains/MinGW.h
  clang/lib/Driver/ToolChains/NetBSD.cpp
  clang/lib/Driver/ToolChains/OpenBSD.h
  clang/lib/Driver/ToolChains/PS4CPU.cpp
  clang/lib/Driver/ToolChains/PS4CPU.h
  clang/lib/Driver/ToolChains/TCE.cpp
  clang/lib/Driver/ToolChains/TCE.h
  clang/lib/Driver/ToolChains/VEToolchain.cpp
  clang/lib/Driver/ToolChains/VEToolchain.h
  clang/lib/Driver/ToolChains/WebAssembly.cpp
  clang/lib/Driver/ToolChains/WebAssembly.h
  clang/lib/Driver/ToolChains/XCore.cpp
  clang/lib/Driver/ToolChains/XCore.h
  clang/lib/Driver/ToolChains/ZOS.h
  clang/test/Driver/hip-sanitize-options.hip

Index: clang/test/Driver/hip-sanitize-options.hip
===
--- clang/test/Driver/hip-sanitize-options.hip
+++ clang/test/Driver/hip-sanitize-options.hip
@@ -1,47 +1,67 @@
 // REQUIRES: clang-driver, x86-registered-target, amdgpu-registered-target
 
-// RUN: %clang -### -target x86_64-unknown-linux-gnu --offload-arch=gfx900 \
+// RUN: %clang -### -target x86_64-unknown-linux-gnu --offload-arch=gfx900:xnack+ \
 // RUN:   -fsanitize=address \
 // RUN:   -nogpuinc --rocm-path=%S/Inputs/rocm \
-// RUN:   %s 2>&1 | FileCheck %s
+// RUN:   %s 2>&1 | FileCheck -check-prefixes=NORDC %s
 
-// RUN: %clang -### -target x86_64-unknown-linux-gnu --offload-arch=gfx900 \
+// RUN: %clang -### -target x86_64-unknown-linux-gnu --offload-arch=gfx900:xnack+ \
 // RUN:   -fsanitize=address -fno-gpu-sanitize \
 // RUN:   -nogpuinc --rocm-path=%S/Inputs/rocm \
 // RUN:   %s 2>&1 | FileCheck %s
 
-// RUN: %clang -### -target x86_64-unknown-linux-gnu --offload-arch=gfx900 \
+// RUN: %clang -### -target x86_64-unknown-linux-gnu --offload-arch=gfx900:xnack+ \
 // RUN:   -fsanitize=address -fgpu-sanitize \
 // RUN:   -nogpuinc --rocm-path=%S/Inputs/rocm \
 // RUN:   %s 2>&1 | FileCheck -check-prefixes=NORDC %s
 
-// RUN: %clang -### -target x86_64-unknown-linux-gnu --offload-arch=gfx900 \
+// RUN: %clang -### -target x86_64-unknown-linux-gnu --offload-arch=gfx900:xnack+ \
 // RUN:   -fsanitize=address -fgpu-sanitize -fgpu-rdc \
 // RUN:   -nogpuinc --rocm-path=%S/Inputs/rocm \
 // RUN:   %s 2>&1 | FileCheck -check-prefixes=RDC %s
 
-// RUN: %clang -### -target x86_64-unknown-linux-gnu --offload-arch=gfx900 \
+// RUN: %clang -### -target x86_64-unknown-linux-gnu --offload-arch=gfx900:xnack+ \
 // RUN:   -fsanitize=address -fgpu-sanitize \
 // RUN:   -nogpuinc --rocm-path=%S/Inputs/rocm-invalid \
 // RUN:   %s 2>&1 | FileCheck -check-prefixes=FAIL %s
 
 // RUN: %clang -### -target x86_64-unknown-linux-gnu --offload-arch=gfx900:xnack- \
-// RUN:   -fsanitize=address -fgpu-sanitize \
-// RUN:   -nogpuinc --rocm-path=%S/Inputs/rocm \
-// RUN:   %s 2>&1 | FileCheck -check-prefix=XNACK %s
+// RUN:   --offload-arch=gfx900:xnack+ --offload-arch=gfx906 -fsanitize=address -fgpu-sanitize \
+// RUN:   -fsanitize=leak -nogpuinc --rocm-path=%S/Inputs/rocm \
+// RUN:   %s 2>&1 | FileCheck -check-prefixes=XNACK %s
+
+// RUN: %clang -### -target x86_64-unknown-linux-gnu --offload-arch=gfx900:xnack- \
+// RUN:   --offload-arch=gfx900:xnack+ --offload-arch=gfx906 -fsanitize=address -fgpu-sanitize \
+// RUN:   -fsanitize=leak -nogpuinc --rocm-path=%S/Inputs/rocm \
+// RUN:   %s 2>&1 | FileCheck -check-prefixes=XNACKNEG %s
 
 // CHECK-NOT: {{"[^"]*clang[^"]*".* "-fcuda-is-device".* "-fsanitize=address"}}
+// CHECK-NOT: {{"[^"]*clang[^"]*".* "-fcuda-is-device".* "-mlink-bitcode-file" ".*a

[PATCH] D111830: [clang] fix typo correction not looking for candidates in base classes.

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov updated this revision to Diff 379810.
mizvekov added a comment.

.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111830

Files:
  clang/lib/Sema/SemaExprMember.cpp
  clang/test/CXX/drs/dr1xx.cpp


Index: clang/test/CXX/drs/dr1xx.cpp
===
--- clang/test/CXX/drs/dr1xx.cpp
+++ clang/test/CXX/drs/dr1xx.cpp
@@ -477,7 +477,7 @@
 
 namespace dr141 { // dr141: yes
   template void f();
-  template struct S { int n; };
+  template struct S { int n; }; // expected-note 
{{'::dr141::S::n' declared here}}
   struct A : S {
 template void f();
 template struct S {};
@@ -485,7 +485,7 @@
   struct B : S {} b;
   void g() {
 a.f();
-(void)a.S::n; // expected-error {{no member named 'n'}}
+(void)a.S::n; // expected-error {{no member named 'n' in 
'dr141::A::S'; did you mean '::dr141::S::n'?}}
 #if __cplusplus < 201103L
 // expected-error@-2 {{ambiguous}}
 // expected-note@-11 {{lookup from the current scope}}
Index: clang/lib/Sema/SemaExprMember.cpp
===
--- clang/lib/Sema/SemaExprMember.cpp
+++ clang/lib/Sema/SemaExprMember.cpp
@@ -611,11 +611,10 @@
 if (Record->containsDecl(ND))
   return true;
 
-if (const CXXRecordDecl *RD = dyn_cast(Record)) {
+if (const auto *RD = dyn_cast(Record)) {
   // Accept candidates that occur in any of the current class' base 
classes.
   for (const auto &BS : RD->bases()) {
-if (const RecordType *BSTy =
-dyn_cast_or_null(BS.getType().getTypePtrOrNull())) 
{
+if (const auto *BSTy = BS.getType()->getAs()) {
   if (BSTy->getDecl()->containsDecl(ND))
 return true;
 }


Index: clang/test/CXX/drs/dr1xx.cpp
===
--- clang/test/CXX/drs/dr1xx.cpp
+++ clang/test/CXX/drs/dr1xx.cpp
@@ -477,7 +477,7 @@
 
 namespace dr141 { // dr141: yes
   template void f();
-  template struct S { int n; };
+  template struct S { int n; }; // expected-note {{'::dr141::S::n' declared here}}
   struct A : S {
 template void f();
 template struct S {};
@@ -485,7 +485,7 @@
   struct B : S {} b;
   void g() {
 a.f();
-(void)a.S::n; // expected-error {{no member named 'n'}}
+(void)a.S::n; // expected-error {{no member named 'n' in 'dr141::A::S'; did you mean '::dr141::S::n'?}}
 #if __cplusplus < 201103L
 // expected-error@-2 {{ambiguous}}
 // expected-note@-11 {{lookup from the current scope}}
Index: clang/lib/Sema/SemaExprMember.cpp
===
--- clang/lib/Sema/SemaExprMember.cpp
+++ clang/lib/Sema/SemaExprMember.cpp
@@ -611,11 +611,10 @@
 if (Record->containsDecl(ND))
   return true;
 
-if (const CXXRecordDecl *RD = dyn_cast(Record)) {
+if (const auto *RD = dyn_cast(Record)) {
   // Accept candidates that occur in any of the current class' base classes.
   for (const auto &BS : RD->bases()) {
-if (const RecordType *BSTy =
-dyn_cast_or_null(BS.getType().getTypePtrOrNull())) {
+if (const auto *BSTy = BS.getType()->getAs()) {
   if (BSTy->getDecl()->containsDecl(ND))
 return true;
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D111100: enable plugins for clang-tidy

[Jameson Nash via Phabricator via cfe-commits]

vtjnash added a comment.

bump?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D00

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

[PATCH] D111833: [clang] Fortify warning for scanf calls with field width too big.

[Michael Benfield via Phabricator via cfe-commits]

mbenfield created this revision.
mbenfield added reviewers: enh, gbiv.
Herald added a reviewer: george.burgess.iv.
mbenfield requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D111833

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaChecking.cpp
  clang/test/Sema/warn-fortify-scanf.c

Index: clang/test/Sema/warn-fortify-scanf.c
===
--- /dev/null
+++ clang/test/Sema/warn-fortify-scanf.c
@@ -0,0 +1,45 @@
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.14.0 %s -verify
+
+typedef struct _FILE FILE;
+extern int scanf(const char *format, ...);
+extern int fscanf(FILE *f, const char *format, ...);
+extern int sscanf(const char *input, const char *format, ...);
+
+void call_scanf() {
+  char buf10[10];
+  char buf20[20];
+  char buf30[30];
+  scanf("%4s %5s %10s", buf20, buf30, buf10); // expected-warning {{'scanf' may overflow; destination buffer in argument 4 has size 10, but the corresponding field width plus null byte is 11}}
+  scanf("%4s %5s %11s", buf20, buf30, buf10); // expected-warning {{'scanf' may overflow; destination buffer in argument 4 has size 10, but the corresponding field width plus null byte is 12}}
+  scanf("%4s %5s %9s", buf20, buf30, buf10);
+  scanf("%20s %5s %9s", buf20, buf30, buf10); // expected-warning {{'scanf' may overflow; destination buffer in argument 2 has size 20, but the corresponding field width plus null byte is 21}}
+  scanf("%21s %5s %9s", buf20, buf30, buf10); // expected-warning {{'scanf' may overflow; destination buffer in argument 2 has size 20, but the corresponding field width plus null byte is 22}}
+  scanf("%19s %5s %9s", buf20, buf30, buf10);
+  scanf("%19s %29s %9s", buf20, buf30, buf10);
+}
+
+void call_sscanf() {
+  char buf10[10];
+  char buf20[20];
+  char buf30[30];
+  sscanf("a b c", "%4s %5s %10s", buf20, buf30, buf10); // expected-warning {{'sscanf' may overflow; destination buffer in argument 5 has size 10, but the corresponding field width plus null byte is 11}}
+  sscanf("a b c", "%4s %5s %11s", buf20, buf30, buf10); // expected-warning {{'sscanf' may overflow; destination buffer in argument 5 has size 10, but the corresponding field width plus null byte is 12}}
+  sscanf("a b c", "%4s %5s %9s", buf20, buf30, buf10);
+  sscanf("a b c", "%20s %5s %9s", buf20, buf30, buf10); // expected-warning {{'sscanf' may overflow; destination buffer in argument 3 has size 20, but the corresponding field width plus null byte is 21}}
+  sscanf("a b c", "%21s %5s %9s", buf20, buf30, buf10); // expected-warning {{'sscanf' may overflow; destination buffer in argument 3 has size 20, but the corresponding field width plus null byte is 22}}
+  sscanf("a b c", "%19s %5s %9s", buf20, buf30, buf10);
+  sscanf("a b c", "%19s %29s %9s", buf20, buf30, buf10);
+}
+
+void call_fscanf() {
+  char buf10[10];
+  char buf20[20];
+  char buf30[30];
+  fscanf(0, "%4s %5s %10s", buf20, buf30, buf10); // expected-warning {{'fscanf' may overflow; destination buffer in argument 5 has size 10, but the corresponding field width plus null byte is 11}}
+  fscanf(0, "%4s %5s %11s", buf20, buf30, buf10); // expected-warning {{'fscanf' may overflow; destination buffer in argument 5 has size 10, but the corresponding field width plus null byte is 12}}
+  fscanf(0, "%4s %5s %9s", buf20, buf30, buf10);
+  fscanf(0, "%20s %5s %9s", buf20, buf30, buf10); // expected-warning {{'fscanf' may overflow; destination buffer in argument 3 has size 20, but the corresponding field width plus null byte is 21}}
+  fscanf(0, "%21s %5s %9s", buf20, buf30, buf10); // expected-warning {{'fscanf' may overflow; destination buffer in argument 3 has size 20, but the corresponding field width plus null byte is 22}}
+  fscanf(0, "%19s %5s %9s", buf20, buf30, buf10);
+  fscanf(0, "%19s %29s %9s", buf20, buf30, buf10);
+}
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -408,6 +408,48 @@
 
 namespace {
 
+class ScanfDiagnosticFormatHandler
+: public analyze_format_string::FormatStringHandler {
+  // Accepts the argument index (relative to the first destination index) of the
+  // argument whose size we want.
+  using ComputeSizeFunction = std::function(unsigned)>;
+
+  // Accepts the argument index (relative to the first destination index), the
+  // destination size, and the source size).
+  using DiagnoseFunction = std::function;
+
+  ComputeSizeFunction ComputeSizeArgument;
+  DiagnoseFunction Diagnose;
+
+public:
+  ScanfDiagnosticFormatHandler(ComputeSizeFunction ComputeSizeArgument,
+   DiagnoseFunction Diagnose)
+  : ComputeSizeArgument(ComputeSizeArgument), Diagnose(Diagnose) {}
+
+  bool HandleScanfSpecifier(const analyze_scanf::ScanfSpecif