[PATCH] D126132: [clang-format] Fix a crash on lambda trailing return type

[Björn Schäpers via Phabricator via cfe-commits]

HazardyKnusperkeks added a comment.

In D126132#3533033 , @owenpan wrote:

> @HazardyKnusperkeks I think you know this better than any of us as you added 
> the assertion to `setType()`. Does this look ok to you?

This looks good.
One should define what is the difference between `TT_LambdaArrow` and 
`TT_TrailingReturnArrow`. But if there is a difference, then the lambda arrows 
should stay `TT_LambdaArrow`, right?

In D126132#3531643 , @MyDeveloperDay 
wrote:

> LGTM  (sorry I've been slow on the reviews, my day job keeps getting in the 
> way ;-))

Same here, I'm just starting to catch up the last weeks. :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126132

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

[PATCH] D126672: [Driver] Add multiarch path for RISC-V

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

This needs a test.

Can Debian's riscv GCC be fixed to use a normalized triple for library and 
include paths?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126672

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

[PATCH] D126682: [WIP][Interpreter] Implement undo command

[Jun Zhang via Phabricator via cfe-commits]

junaire updated this revision to Diff 433029.
junaire added a comment.

- Support undo N times
- Add a comment


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126682

Files:
  clang/include/clang/Interpreter/Interpreter.h
  clang/lib/Interpreter/IncrementalExecutor.cpp
  clang/lib/Interpreter/IncrementalExecutor.h
  clang/lib/Interpreter/IncrementalParser.h
  clang/lib/Interpreter/Interpreter.cpp
  clang/tools/clang-repl/ClangRepl.cpp
  clang/unittests/Interpreter/InterpreterTest.cpp

Index: clang/unittests/Interpreter/InterpreterTest.cpp
===
--- clang/unittests/Interpreter/InterpreterTest.cpp
+++ clang/unittests/Interpreter/InterpreterTest.cpp
@@ -248,4 +248,23 @@
   EXPECT_EQ(42, fn(NewA));
 }
 
+TEST(InterpreterTest, UndoBasic) {
+  Args ExtraArgs = {"-Xclang", "-diagnostic-log-file", "-Xclang", "-"};
+
+  // Create the diagnostic engine with unowned consumer.
+  std::string DiagnosticOutput;
+  llvm::raw_string_ostream DiagnosticsOS(DiagnosticOutput);
+  auto DiagPrinter = std::make_unique(
+  DiagnosticsOS, new DiagnosticOptions());
+
+  auto Interp = createInterpreter(ExtraArgs, DiagPrinter.get());
+  auto R1 = Interp->Parse("int x = 42;");
+  EXPECT_TRUE(!!R1);
+
+  llvm::cantFail(Interp->Undo());
+
+  auto R2 = Interp->Parse("int x = 24;");
+  EXPECT_TRUE(!!R2);
+}
+
 } // end anonymous namespace
Index: clang/tools/clang-repl/ClangRepl.cpp
===
--- clang/tools/clang-repl/ClangRepl.cpp
+++ clang/tools/clang-repl/ClangRepl.cpp
@@ -95,6 +95,11 @@
 while (llvm::Optional Line = LE.readLine()) {
   if (*Line == "quit")
 break;
+  if (*Line == "undo") {
+llvm::cantFail(Interp->Undo());
+continue;
+  }
+
   if (auto Err = Interp->ParseAndExecute(*Line))
 llvm::logAllUnhandledErrors(std::move(Err), llvm::errs(), "error: ");
 }
Index: clang/lib/Interpreter/Interpreter.cpp
===
--- clang/lib/Interpreter/Interpreter.cpp
+++ clang/lib/Interpreter/Interpreter.cpp
@@ -218,8 +218,7 @@
 if (Err)
   return Err;
   }
-  // FIXME: Add a callback to retain the llvm::Module once the JIT is done.
-  if (auto Err = IncrExecutor->addModule(std::move(T.TheModule)))
+  if (auto Err = IncrExecutor->addModule(&T))
 return Err;
 
   if (auto Err = IncrExecutor->runCtors())
@@ -257,3 +256,13 @@
 
   return IncrExecutor->getSymbolAddress(Name, IncrementalExecutor::LinkerName);
 }
+
+llvm::Error Interpreter::Undo(unsigned N) {
+  for (unsigned I = 0; I < N; I++) {
+PartialTranslationUnit &PTU = IncrParser->getPTUs().back();
+if (llvm::Error Err = IncrExecutor->removeModule(&PTU))
+  return Err;
+IncrParser->getPTUs().pop_back();
+  }
+  return llvm::Error::success();
+}
Index: clang/lib/Interpreter/IncrementalParser.h
===
--- clang/lib/Interpreter/IncrementalParser.h
+++ clang/lib/Interpreter/IncrementalParser.h
@@ -72,6 +72,8 @@
   ///\returns the mangled name of a \c GD.
   llvm::StringRef GetMangledName(GlobalDecl GD) const;
 
+  std::list &getPTUs() { return PTUs; }
+
 private:
   llvm::Expected ParseOrWrapTopLevelDecl();
 };
Index: clang/lib/Interpreter/IncrementalExecutor.h
===
--- clang/lib/Interpreter/IncrementalExecutor.h
+++ clang/lib/Interpreter/IncrementalExecutor.h
@@ -13,6 +13,7 @@
 #ifndef LLVM_CLANG_LIB_INTERPRETER_INCREMENTALEXECUTOR_H
 #define LLVM_CLANG_LIB_INTERPRETER_INCREMENTALEXECUTOR_H
 
+#include "llvm/ADT/DenseMap.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/Triple.h"
 #include "llvm/ExecutionEngine/Orc/ExecutionUtils.h"
@@ -29,11 +30,17 @@
 } // namespace llvm
 
 namespace clang {
+
+struct PartialTranslationUnit;
+
 class IncrementalExecutor {
   using CtorDtorIterator = llvm::orc::CtorDtorIterator;
   std::unique_ptr Jit;
   llvm::orc::ThreadSafeContext &TSCtx;
 
+  llvm::DenseMap
+  ResourceTrackers;
+
 public:
   enum SymbolNameKind { IRName, LinkerName };
 
@@ -41,7 +48,8 @@
   const llvm::Triple &Triple);
   ~IncrementalExecutor();
 
-  llvm::Error addModule(std::unique_ptr M);
+  llvm::Error addModule(PartialTranslationUnit *PTU);
+  llvm::Error removeModule(PartialTranslationUnit *PTU);
   llvm::Error runCtors() const;
   llvm::Expected
   getSymbolAddress(llvm::StringRef Name, SymbolNameKind NameKind) const;
Index: clang/lib/Interpreter/IncrementalExecutor.cpp
===
--- clang/lib/Interpreter/IncrementalExecutor.cpp
+++ clang/lib/Interpreter/IncrementalExecutor.cpp
@@ -12,6 +12,7 @@
 
 #include "IncrementalExecutor.h"
 
+#include "clang/Interpreter/PartialTranslationUnit.h"
 #include "llvm/ExecutionEngine/ExecutionEngi

[PATCH] D126682: [WIP][Interpreter] Implement undo command

[Jun Zhang via Phabricator via cfe-commits]

junaire updated this revision to Diff 433030.
junaire added a comment.

Pass PTU by reference as it can't be NULL, this makes our code safer.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126682

Files:
  clang/include/clang/Interpreter/Interpreter.h
  clang/lib/Interpreter/IncrementalExecutor.cpp
  clang/lib/Interpreter/IncrementalExecutor.h
  clang/lib/Interpreter/IncrementalParser.h
  clang/lib/Interpreter/Interpreter.cpp
  clang/tools/clang-repl/ClangRepl.cpp
  clang/unittests/Interpreter/InterpreterTest.cpp

Index: clang/unittests/Interpreter/InterpreterTest.cpp
===
--- clang/unittests/Interpreter/InterpreterTest.cpp
+++ clang/unittests/Interpreter/InterpreterTest.cpp
@@ -248,4 +248,23 @@
   EXPECT_EQ(42, fn(NewA));
 }
 
+TEST(InterpreterTest, UndoBasic) {
+  Args ExtraArgs = {"-Xclang", "-diagnostic-log-file", "-Xclang", "-"};
+
+  // Create the diagnostic engine with unowned consumer.
+  std::string DiagnosticOutput;
+  llvm::raw_string_ostream DiagnosticsOS(DiagnosticOutput);
+  auto DiagPrinter = std::make_unique(
+  DiagnosticsOS, new DiagnosticOptions());
+
+  auto Interp = createInterpreter(ExtraArgs, DiagPrinter.get());
+  auto R1 = Interp->Parse("int x = 42;");
+  EXPECT_TRUE(!!R1);
+
+  llvm::cantFail(Interp->Undo());
+
+  auto R2 = Interp->Parse("int x = 24;");
+  EXPECT_TRUE(!!R2);
+}
+
 } // end anonymous namespace
Index: clang/tools/clang-repl/ClangRepl.cpp
===
--- clang/tools/clang-repl/ClangRepl.cpp
+++ clang/tools/clang-repl/ClangRepl.cpp
@@ -95,6 +95,11 @@
 while (llvm::Optional Line = LE.readLine()) {
   if (*Line == "quit")
 break;
+  if (*Line == "undo") {
+llvm::cantFail(Interp->Undo());
+continue;
+  }
+
   if (auto Err = Interp->ParseAndExecute(*Line))
 llvm::logAllUnhandledErrors(std::move(Err), llvm::errs(), "error: ");
 }
Index: clang/lib/Interpreter/Interpreter.cpp
===
--- clang/lib/Interpreter/Interpreter.cpp
+++ clang/lib/Interpreter/Interpreter.cpp
@@ -218,8 +218,7 @@
 if (Err)
   return Err;
   }
-  // FIXME: Add a callback to retain the llvm::Module once the JIT is done.
-  if (auto Err = IncrExecutor->addModule(std::move(T.TheModule)))
+  if (auto Err = IncrExecutor->addModule(&T))
 return Err;
 
   if (auto Err = IncrExecutor->runCtors())
@@ -257,3 +256,13 @@
 
   return IncrExecutor->getSymbolAddress(Name, IncrementalExecutor::LinkerName);
 }
+
+llvm::Error Interpreter::Undo(unsigned N) {
+  for (unsigned I = 0; I < N; I++) {
+PartialTranslationUnit &PTU = IncrParser->getPTUs().back();
+if (llvm::Error Err = IncrExecutor->removeModule(&PTU))
+  return Err;
+IncrParser->getPTUs().pop_back();
+  }
+  return llvm::Error::success();
+}
Index: clang/lib/Interpreter/IncrementalParser.h
===
--- clang/lib/Interpreter/IncrementalParser.h
+++ clang/lib/Interpreter/IncrementalParser.h
@@ -72,6 +72,8 @@
   ///\returns the mangled name of a \c GD.
   llvm::StringRef GetMangledName(GlobalDecl GD) const;
 
+  std::list &getPTUs() { return PTUs; }
+
 private:
   llvm::Expected ParseOrWrapTopLevelDecl();
 };
Index: clang/lib/Interpreter/IncrementalExecutor.h
===
--- clang/lib/Interpreter/IncrementalExecutor.h
+++ clang/lib/Interpreter/IncrementalExecutor.h
@@ -13,6 +13,7 @@
 #ifndef LLVM_CLANG_LIB_INTERPRETER_INCREMENTALEXECUTOR_H
 #define LLVM_CLANG_LIB_INTERPRETER_INCREMENTALEXECUTOR_H
 
+#include "llvm/ADT/DenseMap.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/Triple.h"
 #include "llvm/ExecutionEngine/Orc/ExecutionUtils.h"
@@ -29,11 +30,17 @@
 } // namespace llvm
 
 namespace clang {
+
+struct PartialTranslationUnit;
+
 class IncrementalExecutor {
   using CtorDtorIterator = llvm::orc::CtorDtorIterator;
   std::unique_ptr Jit;
   llvm::orc::ThreadSafeContext &TSCtx;
 
+  llvm::DenseMap
+  ResourceTrackers;
+
 public:
   enum SymbolNameKind { IRName, LinkerName };
 
@@ -41,7 +48,8 @@
   const llvm::Triple &Triple);
   ~IncrementalExecutor();
 
-  llvm::Error addModule(std::unique_ptr M);
+  llvm::Error addModule(PartialTranslationUnit &PTU);
+  llvm::Error removeModule(PartialTranslationUnit &PTU);
   llvm::Error runCtors() const;
   llvm::Expected
   getSymbolAddress(llvm::StringRef Name, SymbolNameKind NameKind) const;
Index: clang/lib/Interpreter/IncrementalExecutor.cpp
===
--- clang/lib/Interpreter/IncrementalExecutor.cpp
+++ clang/lib/Interpreter/IncrementalExecutor.cpp
@@ -12,6 +12,7 @@
 
 #include "IncrementalExecutor.h"
 
+#include "clang/Interpreter/PartialTranslationUnit.h"
 #include "llv

[PATCH] D126682: [WIP][Interpreter] Implement undo command

[Jun Zhang via Phabricator via cfe-commits]

junaire updated this revision to Diff 433031.
junaire added a comment.

Fix the build


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126682

Files:
  clang/include/clang/Interpreter/Interpreter.h
  clang/lib/Interpreter/IncrementalExecutor.cpp
  clang/lib/Interpreter/IncrementalExecutor.h
  clang/lib/Interpreter/IncrementalParser.h
  clang/lib/Interpreter/Interpreter.cpp
  clang/tools/clang-repl/ClangRepl.cpp
  clang/unittests/Interpreter/InterpreterTest.cpp

Index: clang/unittests/Interpreter/InterpreterTest.cpp
===
--- clang/unittests/Interpreter/InterpreterTest.cpp
+++ clang/unittests/Interpreter/InterpreterTest.cpp
@@ -248,4 +248,23 @@
   EXPECT_EQ(42, fn(NewA));
 }
 
+TEST(InterpreterTest, UndoBasic) {
+  Args ExtraArgs = {"-Xclang", "-diagnostic-log-file", "-Xclang", "-"};
+
+  // Create the diagnostic engine with unowned consumer.
+  std::string DiagnosticOutput;
+  llvm::raw_string_ostream DiagnosticsOS(DiagnosticOutput);
+  auto DiagPrinter = std::make_unique(
+  DiagnosticsOS, new DiagnosticOptions());
+
+  auto Interp = createInterpreter(ExtraArgs, DiagPrinter.get());
+  auto R1 = Interp->Parse("int x = 42;");
+  EXPECT_TRUE(!!R1);
+
+  llvm::cantFail(Interp->Undo());
+
+  auto R2 = Interp->Parse("int x = 24;");
+  EXPECT_TRUE(!!R2);
+}
+
 } // end anonymous namespace
Index: clang/tools/clang-repl/ClangRepl.cpp
===
--- clang/tools/clang-repl/ClangRepl.cpp
+++ clang/tools/clang-repl/ClangRepl.cpp
@@ -95,6 +95,11 @@
 while (llvm::Optional Line = LE.readLine()) {
   if (*Line == "quit")
 break;
+  if (*Line == "undo") {
+llvm::cantFail(Interp->Undo());
+continue;
+  }
+
   if (auto Err = Interp->ParseAndExecute(*Line))
 llvm::logAllUnhandledErrors(std::move(Err), llvm::errs(), "error: ");
 }
Index: clang/lib/Interpreter/Interpreter.cpp
===
--- clang/lib/Interpreter/Interpreter.cpp
+++ clang/lib/Interpreter/Interpreter.cpp
@@ -218,8 +218,7 @@
 if (Err)
   return Err;
   }
-  // FIXME: Add a callback to retain the llvm::Module once the JIT is done.
-  if (auto Err = IncrExecutor->addModule(std::move(T.TheModule)))
+  if (auto Err = IncrExecutor->addModule(T))
 return Err;
 
   if (auto Err = IncrExecutor->runCtors())
@@ -257,3 +256,13 @@
 
   return IncrExecutor->getSymbolAddress(Name, IncrementalExecutor::LinkerName);
 }
+
+llvm::Error Interpreter::Undo(unsigned N) {
+  for (unsigned I = 0; I < N; I++) {
+PartialTranslationUnit &PTU = IncrParser->getPTUs().back();
+if (llvm::Error Err = IncrExecutor->removeModule(PTU))
+  return Err;
+IncrParser->getPTUs().pop_back();
+  }
+  return llvm::Error::success();
+}
Index: clang/lib/Interpreter/IncrementalParser.h
===
--- clang/lib/Interpreter/IncrementalParser.h
+++ clang/lib/Interpreter/IncrementalParser.h
@@ -72,6 +72,8 @@
   ///\returns the mangled name of a \c GD.
   llvm::StringRef GetMangledName(GlobalDecl GD) const;
 
+  std::list &getPTUs() { return PTUs; }
+
 private:
   llvm::Expected ParseOrWrapTopLevelDecl();
 };
Index: clang/lib/Interpreter/IncrementalExecutor.h
===
--- clang/lib/Interpreter/IncrementalExecutor.h
+++ clang/lib/Interpreter/IncrementalExecutor.h
@@ -13,6 +13,7 @@
 #ifndef LLVM_CLANG_LIB_INTERPRETER_INCREMENTALEXECUTOR_H
 #define LLVM_CLANG_LIB_INTERPRETER_INCREMENTALEXECUTOR_H
 
+#include "llvm/ADT/DenseMap.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/Triple.h"
 #include "llvm/ExecutionEngine/Orc/ExecutionUtils.h"
@@ -29,11 +30,17 @@
 } // namespace llvm
 
 namespace clang {
+
+struct PartialTranslationUnit;
+
 class IncrementalExecutor {
   using CtorDtorIterator = llvm::orc::CtorDtorIterator;
   std::unique_ptr Jit;
   llvm::orc::ThreadSafeContext &TSCtx;
 
+  llvm::DenseMap
+  ResourceTrackers;
+
 public:
   enum SymbolNameKind { IRName, LinkerName };
 
@@ -41,7 +48,8 @@
   const llvm::Triple &Triple);
   ~IncrementalExecutor();
 
-  llvm::Error addModule(std::unique_ptr M);
+  llvm::Error addModule(PartialTranslationUnit &PTU);
+  llvm::Error removeModule(PartialTranslationUnit &PTU);
   llvm::Error runCtors() const;
   llvm::Expected
   getSymbolAddress(llvm::StringRef Name, SymbolNameKind NameKind) const;
Index: clang/lib/Interpreter/IncrementalExecutor.cpp
===
--- clang/lib/Interpreter/IncrementalExecutor.cpp
+++ clang/lib/Interpreter/IncrementalExecutor.cpp
@@ -12,6 +12,7 @@
 
 #include "IncrementalExecutor.h"
 
+#include "clang/Interpreter/PartialTranslationUnit.h"
 #include "llvm/ExecutionEngine/ExecutionEngine.h"
 #include "llvm/Execu

[PATCH] D126672: [Driver] Add multiarch path for RISC-V

[Jonas Hahnfeld via Phabricator via cfe-commits]

Hahnfeld added a comment.

In D126672#3546773 , @MaskRay wrote:

> This needs a test.

There are no tests for any of the other architectures.

> Can Debian's riscv GCC be fixed to use a normalized triple for library and 
> include paths?

This is not specific to RISC-V. As you can see by all the other `case`s, 
Clang's target triple is actually not normalized wrt to distro layout.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126672

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

[PATCH] D125095: [Clang][AIX] Add .ref in frontend for AIX XCOFF to support `-bcdtors:csect` linker option

[Ting Wang via Phabricator via cfe-commits]

tingwang added a comment.

Gentle ping.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125095

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

[PATCH] D123674: Clang-Repl Error Recovery Bug Fix

[Purva Chaudhari via Phabricator via cfe-commits]

Purva-Chaudhari added a comment.

In D123674#3546738 , @v.g.vassilev 
wrote:

> In D123674#3546722 , @uabelho wrote:
>
>> Hi,
>>
>> I noticed that the testcase Interpreter/execute.cpp starts failing with this 
>> patch when run/compiled with asan:
>>
>>   Failed Tests (1):
>> Clang :: Interpreter/execute.cpp
>>
>> Seen in the buildbot run
>>  https://lab.llvm.org/buildbot/#/builders/5/builds/24221
>>
>> The run on the commit before passed:
>>  https://lab.llvm.org/buildbot/#/builders/5/builds/24220
>
> Thanks a lot for the notice @uabelho! I have reverted the patch while we are 
> investigating.
>
> @Purva-Chaudhari, can you take look and reproduce the asan failure locally?

Trying to look on it


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123674

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

[PATCH] D126682: [WIP][Interpreter] Implement undo command

[Jun Zhang via Phabricator via cfe-commits]

junaire updated this revision to Diff 433038.
junaire added a comment.

- Add prefix for meta commands
- Add more tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126682

Files:
  clang/include/clang/Interpreter/Interpreter.h
  clang/lib/Interpreter/IncrementalExecutor.cpp
  clang/lib/Interpreter/IncrementalExecutor.h
  clang/lib/Interpreter/IncrementalParser.h
  clang/lib/Interpreter/Interpreter.cpp
  clang/tools/clang-repl/ClangRepl.cpp
  clang/unittests/Interpreter/InterpreterTest.cpp

Index: clang/unittests/Interpreter/InterpreterTest.cpp
===
--- clang/unittests/Interpreter/InterpreterTest.cpp
+++ clang/unittests/Interpreter/InterpreterTest.cpp
@@ -248,4 +248,38 @@
   EXPECT_EQ(42, fn(NewA));
 }
 
+TEST(InterpreterTest, UndoBasic) {
+  Args ExtraArgs = {"-Xclang", "-diagnostic-log-file", "-Xclang", "-"};
+
+  // Create the diagnostic engine with unowned consumer.
+  std::string DiagnosticOutput;
+  llvm::raw_string_ostream DiagnosticsOS(DiagnosticOutput);
+  auto DiagPrinter = std::make_unique(
+  DiagnosticsOS, new DiagnosticOptions());
+
+  auto Interp = createInterpreter(ExtraArgs, DiagPrinter.get());
+
+  auto R1 = Interp->Parse("int x = 42;");
+  EXPECT_TRUE(!!R1);
+
+  llvm::cantFail(Interp->Undo());
+
+  auto R2 = Interp->Parse("int x = 24;");
+  EXPECT_TRUE(!!R2);
+
+  auto R3 = Interp->Parse("int foo() { return 42;}");
+  EXPECT_TRUE(!!R3);
+
+  auto R4 = Interp->Parse("int bar = foo();");
+  EXPECT_TRUE(!!R4);
+
+  llvm::cantFail(Interp->Undo());
+
+  auto R5 = Interp->Parse("int x = 24;");
+  EXPECT_TRUE(!!R5);
+
+  auto R6 = Interp->Parse("int baz = foo();");
+  EXPECT_TRUE(!!R6);
+}
+
 } // end anonymous namespace
Index: clang/tools/clang-repl/ClangRepl.cpp
===
--- clang/tools/clang-repl/ClangRepl.cpp
+++ clang/tools/clang-repl/ClangRepl.cpp
@@ -93,8 +93,13 @@
 llvm::LineEditor LE("clang-repl");
 // FIXME: Add LE.setListCompleter
 while (llvm::Optional Line = LE.readLine()) {
-  if (*Line == "quit")
+  if (*Line == R"(%quit)")
 break;
+  if (*Line == R"(%undo)") {
+llvm::cantFail(Interp->Undo());
+continue;
+  }
+
   if (auto Err = Interp->ParseAndExecute(*Line))
 llvm::logAllUnhandledErrors(std::move(Err), llvm::errs(), "error: ");
 }
Index: clang/lib/Interpreter/Interpreter.cpp
===
--- clang/lib/Interpreter/Interpreter.cpp
+++ clang/lib/Interpreter/Interpreter.cpp
@@ -218,8 +218,7 @@
 if (Err)
   return Err;
   }
-  // FIXME: Add a callback to retain the llvm::Module once the JIT is done.
-  if (auto Err = IncrExecutor->addModule(std::move(T.TheModule)))
+  if (auto Err = IncrExecutor->addModule(T))
 return Err;
 
   if (auto Err = IncrExecutor->runCtors())
@@ -257,3 +256,13 @@
 
   return IncrExecutor->getSymbolAddress(Name, IncrementalExecutor::LinkerName);
 }
+
+llvm::Error Interpreter::Undo(unsigned N) {
+  for (unsigned I = 0; I < N; I++) {
+PartialTranslationUnit &PTU = IncrParser->getPTUs().back();
+if (llvm::Error Err = IncrExecutor->removeModule(PTU))
+  return Err;
+IncrParser->getPTUs().pop_back();
+  }
+  return llvm::Error::success();
+}
Index: clang/lib/Interpreter/IncrementalParser.h
===
--- clang/lib/Interpreter/IncrementalParser.h
+++ clang/lib/Interpreter/IncrementalParser.h
@@ -72,6 +72,8 @@
   ///\returns the mangled name of a \c GD.
   llvm::StringRef GetMangledName(GlobalDecl GD) const;
 
+  std::list &getPTUs() { return PTUs; }
+
 private:
   llvm::Expected ParseOrWrapTopLevelDecl();
 };
Index: clang/lib/Interpreter/IncrementalExecutor.h
===
--- clang/lib/Interpreter/IncrementalExecutor.h
+++ clang/lib/Interpreter/IncrementalExecutor.h
@@ -13,6 +13,7 @@
 #ifndef LLVM_CLANG_LIB_INTERPRETER_INCREMENTALEXECUTOR_H
 #define LLVM_CLANG_LIB_INTERPRETER_INCREMENTALEXECUTOR_H
 
+#include "llvm/ADT/DenseMap.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/Triple.h"
 #include "llvm/ExecutionEngine/Orc/ExecutionUtils.h"
@@ -29,11 +30,17 @@
 } // namespace llvm
 
 namespace clang {
+
+struct PartialTranslationUnit;
+
 class IncrementalExecutor {
   using CtorDtorIterator = llvm::orc::CtorDtorIterator;
   std::unique_ptr Jit;
   llvm::orc::ThreadSafeContext &TSCtx;
 
+  llvm::DenseMap
+  ResourceTrackers;
+
 public:
   enum SymbolNameKind { IRName, LinkerName };
 
@@ -41,7 +48,8 @@
   const llvm::Triple &Triple);
   ~IncrementalExecutor();
 
-  llvm::Error addModule(std::unique_ptr M);
+  llvm::Error addModule(PartialTranslationUnit &PTU);
+  llvm::Error removeModule(PartialTranslationUnit &PTU);
   llvm::Error runCtors() const;
   llvm::Expected

[PATCH] D126682: [Interpreter][ClangRepl] Implement undo command

[Jun Zhang via Phabricator via cfe-commits]

junaire added a comment.

this depends on https://reviews.llvm.org/D126684


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126682

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

[PATCH] D126158: [MLIR][GPU] Replace fdiv on fp16 with promoted (fp32) multiplication with reciprocal plus one (conditional) Newton iteration.

[Stephan Herhut via Phabricator via cfe-commits]

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

Separate pass works for me.




Comment at: mlir/include/mlir/Dialect/LLVMIR/Transforms/Passes.td:19
 
+def NVVMOptimize : Pass<"nvvm-optimize"> {
+  let summary = "Optimize NVVM IR";

Maybe `llvm-optimize-for-nvvm`? Or even `llvm-optimize-for-nvvm-target`? 

This does not really optimize `nvvm` but rewrites `llvm` ir. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126158

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

[PATCH] D125847: LTO: Decide upfront whether to use opaque/non-opaque pointer types

[Nikita Popov via Phabricator via cfe-commits]

nikic accepted this revision.
nikic added a comment.

LGTM




Comment at: clang/test/CodeGen/thinlto-inline-asm2.c:5
+// RUN: %clang_cc1 -opaque-pointers -triple x86_64-unknown-linux-gnu 
-flto=thin -emit-llvm-bc %t/a.c -o %t/a.bc
+// RUN: %clang_cc1 -opaque-pointers -triple x86_64-unknown-linux-gnu 
-flto=thin -emit-llvm-bc %t/b.c -o %t/b.bc
 // RUN: llvm-nm %t/a.bc | FileCheck %s --check-prefix=NM

I don't think this is needed for cc1 invocations (they should always default to 
opaque pointers).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125847

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

[PATCH] D122150: [clang][analyzer] Add checker for bad use of 'errno'.

[Balázs Kéri via Phabricator via cfe-commits]

balazske updated this revision to Diff 433046.
balazske added a comment.

rebase, fix of failing tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122150

Files:
  clang/include/clang/StaticAnalyzer/Checkers/Checkers.td
  clang/lib/StaticAnalyzer/Checkers/CMakeLists.txt
  clang/lib/StaticAnalyzer/Checkers/ErrnoChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/ErrnoModeling.cpp
  clang/lib/StaticAnalyzer/Checkers/ErrnoModeling.h
  clang/lib/StaticAnalyzer/Checkers/ErrnoTesterChecker.cpp
  clang/test/Analysis/analyzer-config.c
  clang/test/Analysis/errno-notes.c
  clang/test/Analysis/errno-options.c
  clang/test/Analysis/errno.c

Index: clang/test/Analysis/errno.c
===
--- clang/test/Analysis/errno.c
+++ clang/test/Analysis/errno.c
@@ -3,6 +3,7 @@
 // RUN:   -analyzer-checker=apiModeling.Errno \
 // RUN:   -analyzer-checker=debug.ExprInspection \
 // RUN:   -analyzer-checker=debug.ErrnoTest \
+// RUN:   -analyzer-checker=alpha.unix.Errno \
 // RUN:   -DERRNO_VAR
 
 // RUN: %clang_analyze_cc1 -verify %s \
@@ -10,8 +11,10 @@
 // RUN:   -analyzer-checker=apiModeling.Errno \
 // RUN:   -analyzer-checker=debug.ExprInspection \
 // RUN:   -analyzer-checker=debug.ErrnoTest \
+// RUN:   -analyzer-checker=alpha.unix.Errno \
 // RUN:   -DERRNO_FUNC
 
+#include "Inputs/system-header-simulator.h"
 #ifdef ERRNO_VAR
 #include "Inputs/errno_var.h"
 #endif
@@ -24,6 +27,7 @@
 int ErrnoTesterChecker_getErrno();
 int ErrnoTesterChecker_setErrnoIfError();
 int ErrnoTesterChecker_setErrnoIfErrorRange();
+int ErrnoTesterChecker_setErrnoCheckState();
 
 void something();
 
@@ -61,3 +65,154 @@
 clang_analyzer_eval(errno == 1); // expected-warning{{FALSE}} expected-warning{{TRUE}}
   }
 }
+
+void testErrnoCheck0() {
+  // If the function returns a success result code, value of 'errno'
+  // is unspecified and it is unsafe to make any decision with it.
+  // The function did not promise to not change 'errno' if no failure happens.
+  int X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 0) {
+if (errno) { // expected-warning{{An undefined value may be read from 'errno' [alpha.unix.Errno]}}
+}
+if (errno) { // no warning for second time (analysis stops at the first warning)
+}
+  }
+  X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 0) {
+if (errno) { // expected-warning{{An undefined value may be read from 'errno' [alpha.unix.Errno]}}
+}
+errno = 0;
+  }
+  X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 0) {
+errno = 0;
+if (errno) { // no warning after overwritten 'errno'
+}
+  }
+}
+
+void testErrnoCheck1() {
+  // If the function returns error result code that is out-of-band (not a valid
+  // non-error return value) the value of 'errno' can be checked but it is not
+  // required to do so.
+  int X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 1) {
+if (errno) { // no warning
+}
+  }
+  X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 1) {
+errno = 0; // no warning
+  }
+}
+
+void testErrnoCheck2() {
+  // If the function returns an in-band error result the value of 'errno' is
+  // required to be checked to verify if error happened.
+  // The same applies to other functions that can indicate failure only by
+  // change of 'errno'.
+  int X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 2) {
+if (errno) {
+}
+errno = 0; // no warning after 'errno' was read
+  }
+  X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 2) {
+errno = 0; // expected-warning{{Value of 'errno' was not checked and is overwritten here [alpha.unix.Errno]}}
+errno = 0;
+  }
+  X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 2) {
+errno = 0; // expected-warning{{Value of 'errno' was not checked and is overwritten here [alpha.unix.Errno]}}
+if (errno) {
+}
+  }
+}
+
+void testErrnoCheckUndefinedLoad() {
+  int X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 0) {
+if (errno) { // expected-warning{{An undefined value may be read from 'errno' [alpha.unix.Errno]}}
+}
+  }
+}
+
+void testErrnoNotCheckedAtSystemCall() {
+  int X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 2) {
+printf("%i", 1); // expected-warning{{Value of 'errno' was not checked and may be overwritten by function 'printf' [alpha.unix.Errno]}}
+printf("%i", 1); // no warning ('printf' does not change errno state)
+  }
+}
+
+void testErrnoCheckStateInvalidate() {
+  int X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 0) {
+something();
+if (errno) { // no warning after an invalidating function call
+}
+  }
+  X = ErrnoTesterChecker_setErrnoCheckState();
+  if (X == 0) {
+printf("%i", 1);
+if (errno) { // no warning after an invalidating standard function call
+}
+  }
+}
+
+void testErrnoCheckStateInvalidate1() {
+  int X = ErrnoTeste

[PATCH] D125400: [clang][Analyzer] Add errno state to standard functions modeling.

[Balázs Kéri via Phabricator via cfe-commits]

balazske updated this revision to Diff 433047.
balazske added a comment.

rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125400

Files:
  clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
  clang/test/Analysis/Inputs/system-header-simulator-for-errno.h
  clang/test/Analysis/errno-stdlibraryfunctions.c

Index: clang/test/Analysis/errno-stdlibraryfunctions.c
===
--- /dev/null
+++ clang/test/Analysis/errno-stdlibraryfunctions.c
@@ -0,0 +1,46 @@
+// RUN: %clang_analyze_cc1 -verify -analyzer-output text %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=debug.ExprInspection \
+// RUN:   -analyzer-checker=apiModeling.StdCLibraryFunctions \
+// RUN:   -analyzer-checker=apiModeling.Errno \
+// RUN:   -analyzer-checker=alpha.unix.Errno \
+// RUN:   -analyzer-config apiModeling.StdCLibraryFunctions:ModelPOSIX=true
+
+#include "Inputs/errno_var.h"
+#include "Inputs/system-header-simulator-for-errno.h"
+
+void clang_analyzer_warnIfReached();
+
+void test1() {
+  access("path", 0); // no note here
+  access("path", 0);
+  // expected-note@-1{{Assuming that function 'access' is successful, in this case the value 'errno' may be undefined after the call and should not be used}}
+  if (errno != 0) { }
+  // expected-warning@-1{{An undefined value may be read from 'errno'}}
+  // expected-note@-2{{An undefined value may be read from 'errno'}}
+}
+
+void test2() {
+  if (access("path", 0) == -1) {
+// expected-note@-1{{Taking true branch}}
+// Failure path.
+if (errno != 0) {
+  // expected-note@-1{{'errno' is not equal to 0}}
+  // expected-note@-2{{Taking true branch}}
+  clang_analyzer_warnIfReached(); // expected-note {{REACHABLE}} expected-warning {{REACHABLE}}
+} else {
+  clang_analyzer_warnIfReached(); // no-warning: We are on the failure path.
+}
+  }
+}
+
+void test3() {
+  if (access("path", 0) != -1) {
+// Success path.
+// expected-note@-2{{Assuming that function 'access' is successful, in this case the value 'errno' may be undefined after the call and should not be used}}
+// expected-note@-3{{Taking true branch}}
+if (errno != 0) { }
+// expected-warning@-1{{An undefined value may be read from 'errno'}}
+// expected-note@-2{{An undefined value may be read from 'errno'}}
+  }
+}
Index: clang/test/Analysis/Inputs/system-header-simulator-for-errno.h
===
--- /dev/null
+++ clang/test/Analysis/Inputs/system-header-simulator-for-errno.h
@@ -0,0 +1,6 @@
+#pragma clang system_header
+
+typedef __typeof(sizeof(int)) off_t;
+
+int access(const char *path, int amode);
+off_t lseek(int fildes, off_t offset, int whence);
Index: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
@@ -40,6 +40,7 @@
 //
 //===--===//
 
+#include "ErrnoModeling.h"
 #include "clang/StaticAnalyzer/Checkers/BuiltinCheckerRegistration.h"
 #include "clang/StaticAnalyzer/Core/BugReporter/BugType.h"
 #include "clang/StaticAnalyzer/Core/Checker.h"
@@ -56,6 +57,19 @@
 using namespace clang;
 using namespace clang::ento;
 
+static const char *describeErrnoCheckState(errno_modeling::ErrnoCheckState CS) {
+  switch (CS) {
+  case errno_modeling::Errno_Irrelevant:
+return "is not significant";
+  case errno_modeling::Errno_MustBeChecked:
+return "should be checked to verify if the call was successful";
+  case errno_modeling::Errno_MustNotBeChecked:
+return "may be undefined after the call and should not be used";
+  default:
+llvm_unreachable("unknown enum value");
+  };
+}
+
 namespace {
 class StdLibraryFunctionsChecker
 : public Checker {
@@ -377,6 +391,113 @@
   /// The complete list of constraints that defines a single branch.
   using ConstraintSet = std::vector;
 
+  /// Define how a function affects the system variable 'errno'.
+  /// This works together with the ErrnoModeling and ErrnoChecker classes.
+  class ErrnoConstraintBase {
+  public:
+/// Apply specific state changes related to the errno variable.
+virtual ProgramStateRef apply(ProgramStateRef State, const CallEvent &Call,
+  const Summary &Summary,
+  CheckerContext &C) const = 0;
+/// Get a description about what is applied to 'errno' and how is it allowed
+/// to be used. If ErrnoChecker generates a bug then this message is
+/// displayed as a note at the function call.
+/// It may return empty string if no note tag is to be added.
+virtual std::string describe(StringRef FunctionName)

Re: [PATCH] D125788: [flang][driver] Rename `flang-new` as `flang`

[Damian Rouson via cfe-commits]

On Mon, May 30, 2022 at 2:39 AM Andrzej Warzynski via Phabricator <
revi...@reviews.llvm.org> wrote:

>
> 1. Lets rename `flang` as `flang-to-external-fc` regardless of what's
> decided for `flang-new`. That would already be a huge step forward (and
> would reflect accurately what the bash wrapper script actually does).
>

I support this.  I think the proposed new name is better reflects what the
current flang script currently does and thereby reduces the likelihood of
surprise when a user sees an error message from an external compiler.


> 2. As for the NAG test suite, I hope that we can agree not to use it as
> the condition for renaming `flang-new`. If it's decided that that's a valid
> requirement, then I agree with @kiranchandramohan that we should find a way
> to openly track the progress towards the required pass rate (and how that's
> defined).
>

I agree.


> Perhaps we could discuss more in the call today?
>

Any news from the call?

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

[PATCH] D126189: [C++20][Modules] Build module static initializers per P1874R1.

[Iain Sandoe via Phabricator via cfe-commits]

iains updated this revision to Diff 433049.
iains marked 7 inline comments as done.
iains added a comment.

rebased, addressed review comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126189

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/Basic/Module.h
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CGDeclCXX.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenModule.h
  clang/lib/Parse/ParseAST.cpp
  clang/test/CodeGen/module-intializer-pmf.cpp
  clang/test/CodeGen/module-intializer.cpp

Index: clang/test/CodeGen/module-intializer.cpp
===
--- /dev/null
+++ clang/test/CodeGen/module-intializer.cpp
@@ -0,0 +1,172 @@
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: cd %t
+
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 N.cpp \
+// RUN:-emit-module-interface -o N.pcm
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 N.pcm -S -emit-llvm \
+// RUN:  -o - | FileCheck %s --check-prefix=CHECK-N
+
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 O.cpp \
+// RUN:-emit-module-interface -o O.pcm
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 O.pcm -S -emit-llvm \
+// RUN:  -o - | FileCheck %s --check-prefix=CHECK-O
+
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 M-part.cpp \
+// RUN:-emit-module-interface -o M-part.pcm
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 M-part.pcm -S \
+// RUN: -emit-llvm -o - | FileCheck %s --check-prefix=CHECK-P
+
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 M.cpp \
+// RUN: -fmodule-file=N.pcm -fmodule-file=O.pcm -fmodule-file=M-part.pcm \
+// RUN:-emit-module-interface -o M.pcm
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 M.pcm -S -emit-llvm \
+// RUN:  -o - | FileCheck %s --check-prefix=CHECK-M
+
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 useM.cpp \
+// RUN: -fmodule-file=M.pcm -S -emit-llvm  -o - \
+// RUN: | FileCheck %s --check-prefix=CHECK-USE
+
+//--- N-h.h
+
+struct Oink {
+  Oink(){};
+};
+
+Oink Hog;
+
+//--- N.cpp
+
+module;
+#include "N-h.h"
+
+export module N;
+
+export struct Quack {
+  Quack(){};
+};
+
+export Quack Duck;
+
+// CHECK-N: define internal void @__cxx_global_var_init
+// CHECK-N: call void @_ZN4OinkC1Ev
+// CHECK-N: define internal void @__cxx_global_var_init
+// CHECK-N: call void @_ZNW1N5QuackC1Ev
+// CHECK-N: define void @_ZGIW1N
+// CHECK-N: store i8 1, ptr @_ZGIW1N__in_chrg
+// CHECK-N: call void @__cxx_global_var_init
+// CHECK-N: call void @__cxx_global_var_init
+
+//--- O-h.h
+
+struct Meow {
+  Meow(){};
+};
+
+Meow Cat;
+
+//--- O.cpp
+
+module;
+#include "O-h.h"
+
+export module O;
+
+export struct Bark {
+  Bark(){};
+};
+
+export Bark Dog;
+
+// CHECK-O: define internal void @__cxx_global_var_init
+// CHECK-O: call void @_ZN4MeowC2Ev
+// CHECK-O: define internal void @__cxx_global_var_init
+// CHECK-O: call void @_ZNW1O4BarkC1Ev
+// CHECK-O: define void @_ZGIW1O
+// CHECK-O: store i8 1, ptr @_ZGIW1O__in_chrg
+// CHECK-O: call void @__cxx_global_var_init
+// CHECK-O: call void @__cxx_global_var_init
+
+//--- P-h.h
+
+struct Croak {
+  Croak(){};
+};
+
+Croak Frog;
+
+//--- M-part.cpp
+
+module;
+#include "P-h.h"
+
+module M:Part;
+
+struct Squawk {
+  Squawk(){};
+};
+
+Squawk parrot;
+
+// CHECK-P: define internal void @__cxx_global_var_init
+// CHECK-P: call void @_ZN5CroakC1Ev
+// CHECK-P: define internal void @__cxx_global_var_init
+// CHECK-P: call void @_ZNW1M6SquawkC1Ev
+// CHECK-P: define void @_ZGIW1MWP4Part
+// CHECK-P: store i8 1, ptr @_ZGIW1MWP4Part__in_chrg
+// CHECK-P: call void @__cxx_global_var_init
+// CHECK-P: call void @__cxx_global_var_init
+
+//--- M-h.h
+
+struct Moo {
+  Moo(){};
+};
+
+Moo Cow;
+
+//--- M.cpp
+
+module;
+#include "M-h.h"
+
+export module M;
+import N;
+export import O;
+import :Part;
+
+export struct Baa {
+  int x;
+  Baa(){};
+  Baa(int x) : x(x) {}
+  int getX() { return x; }
+};
+
+export Baa Sheep(10);
+
+// CHECK-M: define internal void @__cxx_global_var_init
+// CHECK-M: call void @_ZN3MooC1Ev
+// CHECK-M: define internal void @__cxx_global_var_init
+// CHECK-M: call void @_ZNW1M3BaaC1Ei
+// CHECK-M: declare void @_ZGIW1O()
+// CHECK-M: declare void @_ZGIW1N()
+// CHECK-M: declare void @_ZGIW1MWP4Part()
+// CHECK-M: define void @_ZGIW1M
+// CHECK-M: store i8 1, ptr @_ZGIW1M__in_chrg
+// CHECK-M: call void @_ZGIW1O()
+// CHECK-M: call void @_ZGIW1N()
+// CHECK-M: call void @_ZGIW1MWP4Part()
+// CHECK-M: call void @__cxx_global_var_init
+// CHECK-M: call void @__cxx_global_var_init
+
+//--- useM.cpp
+
+import M;
+
+int main() {
+  return Sheep.getX();
+}
+
+// CHECK-USE: declare void @_ZGIW1M
+// CHECK-USE: define internal void @_GLOBAL__sub_I_useM.cpp
+// CHECK-USE: call void @_ZGIW1M()
Index: clang/test/CodeGen/module-intializer-pmf.cpp
==

[PATCH] D126189: [C++20][Modules] Build module static initializers per P1874R1.

[Iain Sandoe via Phabricator via cfe-commits]

iains added inline comments.



Comment at: clang/lib/CodeGen/CGDeclCXX.cpp:645-646
+  llvm::raw_svector_ostream Out(FnName);
+  cast(getCXXABI().getMangleContext())
+  .mangleModuleInitializer(M, Out);
+}

ChuanqiXu wrote:
> iains wrote:
> > ChuanqiXu wrote:
> > > mangleModuleInitializer is virtual function and we don't need to cast it.
> > Actually, 'mangleModuleInitializer' is not a virtual function of the 
> > 'MangleContext' class, only of the 'ItaniumMangleContext'.
> > (see D122741).
> > 
> > This because we do not know the mangling for MS and, in principle, there 
> > might never be such a mangling (e.g. that implementation might deal with 
> > P1874 in some different way).
> > 
> > I did have a version of this where I amended the mangling to make the 
> > function virtual in the 'MangleContext' class, but then that means 
> > generating a dummy MS version that, as noted above, might never exist in 
> > reality.
> > 
> I was just afraid of people might blame us to bring ABI specific things to 
> CodeGen* things. I found there similar uses in CGVTables.cpp and CGVTT.cpp. 
> So this might be acceptable too.
yes, let us see - if there are any other opinions - personally, I prefer 
**not** to generate a dummy function in the MS code.



Comment at: clang/lib/CodeGen/CGDeclCXX.cpp:671
+ModuleInits.push_back(I->second);
+}
+PrioritizedCXXGlobalInits.clear();

ChuanqiXu wrote:
> iains wrote:
> > ChuanqiXu wrote:
> > > I find the process here for `PrioritizedCXXGlobalInits` is much simpler 
> > > than the one done in `CodeGenModule::EmitCXXGlobalInitFunc()`. It would 
> > > generate more global init function. Doesn't it matter?
> > In the general CXX initializer the prioritized inits are grouped into 
> > functions named in a way that allows them to be collated by other tools 
> > (e.g. the static linker) so that init priority can be honoured over 
> > multiple TUs. 
> > 
> > This is not feasible for module initializers, there is no way to fuze them 
> > across TUs (it would have no meaning).  So I think all we need to do here 
> > is to emit the calls in the correct order (in the end there are no more 
> > initializer functions, we just skip the intermediated grouping functions,
> > 
> > Of course, init priority is not mentioned in the standard, so that really 
> > what would matter is that compiler 'vendors' agree on a sensible approach 
> > to make sure code behaves in an expected manner for common toolchains.
> Yeah, the prioritized inits are really odd fashion to me..  I only saw such 
> things in assembly. So my understanding to this one is that:
> (1) If we have prioritized inits in modules' code , it is not guaranteed to 
> be initialized first. This is the vendors agreement.
> (2) If we link a static library (e.g., libgcc.a), the prioritized inits in 
> that would still be initialized first.
> 
> Do I understand right?
We should avoid side-tracking this patch with too much discussion of the 
problems of C++ global initialisers.  Behaviour of things like static libraries 
depends on the toolchain, binary container, platform 

1. prioritised initializers are not part of the standard
2. they are optional (some toolchains do not handle them at all - e.g. macOS)
3. where they are handled, usually the toolchain makes no guarantees about 
behaviour between TUs
4. (for a regular ELF-style C++ global init) there is a convention to group 
initializers for a specific priority into a function with a specific mangled 
name that allows (optionally) external tools - like the linker  -to group / 
order the inits _between_ TUs.

None of this is relevant to Module initializers, we just have to ensure that 
imported module inits are run before the current module's.




Comment at: clang/lib/CodeGen/CodeGenModule.cpp:3206-3208
+  bool MBEE = MayBeEmittedEagerly(Global);
+  if (MustBeEmitted(Global)) {
+if (MBEE) {

ChuanqiXu wrote:
> iains wrote:
> > ChuanqiXu wrote:
> > > Is this change needed? Could you elaborate more on this?
> > the test is quite heavy, and is used twice when the assertions are enabled 
> > (I do not mind to revert this part if that does not seem worthwhile).
> > 
> I prefer to do such changes in a standalone NFC patch.
OK .. fair enough, reverted for now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126189

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

[PATCH] D126291: [flang][Driver] Update link job on windows

[Diana Picus via Phabricator via cfe-commits]

rovka updated this revision to Diff 433054.
rovka added a comment.

Updated test to check for link.exe instead of lld-link.exe. This doesn't look 
great but it works for both lld-link.exe and the default link.exe. I tried to 
use --ld-path=various/paths instead, but it seems to be ignored on Windows (I 
even get a warning about "argument unused during compilation"). If anyone has 
any ideas about how to make the test more robust, please let me know.


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

https://reviews.llvm.org/D126291

Files:
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/CommonArgs.h
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/lib/Driver/ToolChains/MSVC.cpp
  flang/test/Driver/linker-flags-windows.f90

Index: flang/test/Driver/linker-flags-windows.f90
===
--- /dev/null
+++ flang/test/Driver/linker-flags-windows.f90
@@ -0,0 +1,24 @@
+! Verify that the Fortran runtime libraries are present in the linker
+! invocation. These libraries are added on top of other standard runtime
+! libraries that the Clang driver will include.
+
+! NOTE: The additional linker flags tested here are currently specified in
+! clang/lib/Driver/Toolchains/MSVC.cpp.
+! REQUIRES: system-windows
+
+! RUN: %flang -### %S/Inputs/hello.f90 2>&1 | FileCheck %s
+
+! Compiler invocation to generate the object file
+! CHECK-LABEL: {{.*}} "-emit-obj"
+! CHECK-SAME:  "-o" "[[object_file:.*]]" {{.*}}Inputs/hello.f90
+
+! Linker invocation to generate the executable
+! NOTE: This check should also match if the default linker is lld-link.exe
+! CHECK-LABEL: link.exe
+! CHECK-NOT: libcmt
+! CHECK-NOT: oldnames
+! CHECK-SAME: Fortran_main.lib
+! CHECK-SAME: FortranRuntime.lib
+! CHECK-SAME: FortranDecimal.lib
+! CHECK-SAME: "[[object_file]]"
+
Index: clang/lib/Driver/ToolChains/MSVC.cpp
===
--- clang/lib/Driver/ToolChains/MSVC.cpp
+++ clang/lib/Driver/ToolChains/MSVC.cpp
@@ -81,7 +81,7 @@
 Args.MakeArgString(std::string("-out:") + Output.getFilename()));
 
   if (!Args.hasArg(options::OPT_nostdlib, options::OPT_nostartfiles) &&
-  !C.getDriver().IsCLMode()) {
+  !C.getDriver().IsCLMode() && !C.getDriver().IsFlangMode()) {
 CmdArgs.push_back("-defaultlib:libcmt");
 CmdArgs.push_back("-defaultlib:oldnames");
   }
@@ -130,6 +130,11 @@
   Args.MakeArgString(std::string("-libpath:") + WindowsSdkLibPath));
   }
 
+  if (C.getDriver().IsFlangMode()) {
+tools::addFortranRuntimeLibraryPath(TC, Args, CmdArgs);
+tools::addFortranRuntimeLibs(TC, CmdArgs);
+  }
+
   // Add the compiler-rt library directories to libpath if they exist to help
   // the linker find the various sanitizer, builtin, and profiling runtimes.
   for (const auto &LibPath : TC.getLibraryPaths()) {
Index: clang/lib/Driver/ToolChains/Gnu.cpp
===
--- clang/lib/Driver/ToolChains/Gnu.cpp
+++ clang/lib/Driver/ToolChains/Gnu.cpp
@@ -599,7 +599,7 @@
   // TODO: Make this work unconditionally once Flang is mature enough.
   if (D.IsFlangMode() && Args.hasArg(options::OPT_flang_experimental_exec)) {
 addFortranRuntimeLibraryPath(ToolChain, Args, CmdArgs);
-addFortranRuntimeLibs(CmdArgs);
+addFortranRuntimeLibs(ToolChain, CmdArgs);
 CmdArgs.push_back("-lm");
   }
 
Index: clang/lib/Driver/ToolChains/Darwin.cpp
===
--- clang/lib/Driver/ToolChains/Darwin.cpp
+++ clang/lib/Driver/ToolChains/Darwin.cpp
@@ -644,7 +644,7 @@
   if (getToolChain().getDriver().IsFlangMode() &&
   Args.hasArg(options::OPT_flang_experimental_exec)) {
 addFortranRuntimeLibraryPath(getToolChain(), Args, CmdArgs);
-addFortranRuntimeLibs(CmdArgs);
+addFortranRuntimeLibs(getToolChain(), CmdArgs);
   }
 
   if (!Args.hasArg(options::OPT_nostdlib, options::OPT_nodefaultlibs))
Index: clang/lib/Driver/ToolChains/CommonArgs.h
===
--- clang/lib/Driver/ToolChains/CommonArgs.h
+++ clang/lib/Driver/ToolChains/CommonArgs.h
@@ -121,7 +121,8 @@
   bool IsOffloadingHost = false, bool GompNeedsRT = false);
 
 /// Adds Fortran runtime libraries to \p CmdArgs.
-void addFortranRuntimeLibs(llvm::opt::ArgStringList &CmdArgs);
+void addFortranRuntimeLibs(const ToolChain &TC,
+   llvm::opt::ArgStringList &CmdArgs);
 
 /// Adds the path for the Fortran runtime libraries to \p CmdArgs.
 void addFortranRuntimeLibraryPath(const ToolChain &TC,
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -748,10 +748,17 @@
   return true;
 }
 
-void tools::addFortranRuntimeLibs(

[PATCH] D126291: [flang][Driver] Update link job on windows

[Diana Picus via Phabricator via cfe-commits]

rovka added inline comments.



Comment at: flang/test/Driver/flang-linker-flags-windows.f90:16
+! Linker invocation to generate the executable
+! CHECK-LABEL:  lld-link.exe
+! CHECK-NOT: libcmt

Meinersbur wrote:
> This is failing for me. Instead of `lld-link.exe`, it is using `link.exe` 
> (the Microsoft linker).
> 
> Without the `-###` flag, the link command is failing:
> ```
> flang-new version 15.0.0 (C:/Users/meinersbur/src/llvm-project/clang 
> 09fdf5f6f5e70ecb7d95cdbb98442c998a55ce23)
> Target: x86_64-pc-windows-msvc
> Thread model: posix
> InstalledDir: c:\users\meinersbur\build\llvm-project\release\bin
>  "c:\\users\\meinersbur\\build\\llvm-project\\release\\bin\\flang-new" -fc1 
> -triple x86_64-pc-windows-msvc19.32.31329 -emit-obj -o 
> "C:\\Users\\MEINER~1\\AppData\\Local\\Temp\\hello-ae4145.o" 
> "C:\\Users\\meinersbur\\src\\llvm-project\\flang\\test\\Driver/Inputs/hello.f90"
>  "C:\\Program Files\\Microsoft Visual 
> Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.32.31326\\bin\\Hostx64\\x64\\link.exe"
>  -out:a.exe 
> "-libpath:c:\\users\\meinersbur\\build\\llvm-project\\release\\lib" 
> Fortran_main.lib FortranRuntime.lib FortranDecimal.lib -nologo 
> "C:\\Users\\MEINER~1\\AppData\\Local\\Temp\\hello-ae4145.o"
> LINK : fatal error LNK1561: entry point must be defined
> flang-new: error: linker command failed with exit code 1561 (use -v to see 
> invocation)
> ```
This might be because you're not passing any subsystem. Can you try with 
`-Xlinker -subsystem:console`?


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

https://reviews.llvm.org/D126291

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

[PATCH] D126397: [pseudo] Fix pseudo-gen usage when cross-compiling

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

Even after this, you still have to explicitly set `-DCMAKE_SYSTEM_NAME=Darwin` 
when building clang for mac/arm on mac/intel. Given that the host and target 
systems are both mac, that's a bit weird. llvm-tblgen doesn't need this, it 
just works as long as you set `LLVM_USE_HOST_TOOLS=ON`. Should pseudo-gen honor 
LLVM_USE_HOST_TOOLS too? It looks like it's basically the same situation.

(It's only the 2nd compiled binary in all of llvm that needs to run as part of 
the build (if you count the various tblgen binaries as a single binary). Maybe 
it'd make sense to make this a tblgen-based tool? Then this would've Just 
Worked.).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126397

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

[PATCH] D126691: ASTContext: Provide a query for module initializer contents.

[Iain Sandoe via Phabricator via cfe-commits]

iains created this revision.
Herald added a project: All.
iains added reviewers: urnathan, ChuanqiXu.
iains published this revision for review.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

When deciding if a global module fragement decl is unused, we have
to account for the case that it is emitted as part of the module
initializer.  In order to make this more efficient, modify the container
used to cache the module intializer decls.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D126691

Files:
  clang/include/clang/AST/ASTContext.h
  clang/lib/AST/ASTContext.cpp


Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -1148,7 +1148,7 @@
   LazyInitializers.clear();
 
   for (auto ID : LazyInits)
-Initializers.push_back(Source->GetExternalDecl(ID));
+Initializers.insert(Source->GetExternalDecl(ID));
 
   assert(LazyInitializers.empty() &&
  "GetExternalDecl for lazy module initializer added more inits");
@@ -1177,7 +1177,7 @@
   auto *&Inits = ModuleInitializers[M];
   if (!Inits)
 Inits = new (*this) PerModuleInitializers;
-  Inits->Initializers.push_back(D);
+  Inits->Initializers.insert(D);
 }
 
 void ASTContext::addLazyModuleInitializers(Module *M, ArrayRef IDs) {
@@ -1195,7 +1195,17 @@
 
   auto *Inits = It->second;
   Inits->resolve(*this);
-  return Inits->Initializers;
+  return Inits->Initializers.getArrayRef();
+}
+
+bool ASTContext::moduleInitializerContains(Module *M, const Decl *D) {
+  auto It = ModuleInitializers.find(M);
+  if (It == ModuleInitializers.end())
+return false;
+
+  auto *Inits = It->second;
+  Inits->resolve(*this);
+  return Inits->Initializers.contains(const_cast(D));
 }
 
 ExternCContextDecl *ASTContext::getExternCContextDecl() const {
Index: clang/include/clang/AST/ASTContext.h
===
--- clang/include/clang/AST/ASTContext.h
+++ clang/include/clang/AST/ASTContext.h
@@ -53,6 +53,7 @@
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/PointerIntPair.h"
 #include "llvm/ADT/PointerUnion.h"
+#include "llvm/ADT/SetVector.h"
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/ADT/StringMap.h"
 #include "llvm/ADT/StringRef.h"
@@ -465,7 +466,7 @@
   /// a non-constant initializer), or an ImportDecl (which recursively triggers
   /// initialization of another module).
   struct PerModuleInitializers {
-llvm::SmallVector Initializers;
+llvm::SmallSetVector Initializers;
 llvm::SmallVector LazyInitializers;
 
 void resolve(ASTContext &Ctx);
@@ -1078,6 +1079,9 @@
   /// Get the initializations to perform when importing a module, if any.
   ArrayRef getModuleInitializers(Module *M);
 
+  /// Does the module initializer array contain this decl.
+  bool moduleInitializerContains(Module *M, const Decl *D);
+
   /// Set the (C++20) module we are building.
   void setModuleForCodeGen(Module *M) { TopLevelModule = M; }
 


Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -1148,7 +1148,7 @@
   LazyInitializers.clear();
 
   for (auto ID : LazyInits)
-Initializers.push_back(Source->GetExternalDecl(ID));
+Initializers.insert(Source->GetExternalDecl(ID));
 
   assert(LazyInitializers.empty() &&
  "GetExternalDecl for lazy module initializer added more inits");
@@ -1177,7 +1177,7 @@
   auto *&Inits = ModuleInitializers[M];
   if (!Inits)
 Inits = new (*this) PerModuleInitializers;
-  Inits->Initializers.push_back(D);
+  Inits->Initializers.insert(D);
 }
 
 void ASTContext::addLazyModuleInitializers(Module *M, ArrayRef IDs) {
@@ -1195,7 +1195,17 @@
 
   auto *Inits = It->second;
   Inits->resolve(*this);
-  return Inits->Initializers;
+  return Inits->Initializers.getArrayRef();
+}
+
+bool ASTContext::moduleInitializerContains(Module *M, const Decl *D) {
+  auto It = ModuleInitializers.find(M);
+  if (It == ModuleInitializers.end())
+return false;
+
+  auto *Inits = It->second;
+  Inits->resolve(*this);
+  return Inits->Initializers.contains(const_cast(D));
 }
 
 ExternCContextDecl *ASTContext::getExternCContextDecl() const {
Index: clang/include/clang/AST/ASTContext.h
===
--- clang/include/clang/AST/ASTContext.h
+++ clang/include/clang/AST/ASTContext.h
@@ -53,6 +53,7 @@
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/PointerIntPair.h"
 #include "llvm/ADT/PointerUnion.h"
+#include "llvm/ADT/SetVector.h"
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/ADT/StringMap.h"
 #include "llvm/ADT/StringRef.h"
@@ -465,7 +466,7 @@
   /// a non-constant initializer), or an ImportDecl (which recursively triggers
   /// initialization of another module).
   struct PerModuleInitializers {
-llvm::SmallVector Initializers;
+llvm::Sma

[PATCH] D126694: [C++20][Modules] Initial implementation of GMF decl elision.

[Iain Sandoe via Phabricator via cfe-commits]

iains created this revision.
Herald added a project: All.
iains added reviewers: urnathan, ChuanqiXu.
iains added a subscriber: clang-modules.
iains published this revision for review.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

The basis for removal of GMF decls is that they have no use
in the module interface.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D126694

Files:
  clang/lib/Sema/Sema.cpp
  clang/test/CXX/basic/basic.scope/basic.scope.namespace/p2.cpp


Index: clang/test/CXX/basic/basic.scope/basic.scope.namespace/p2.cpp
===
--- clang/test/CXX/basic/basic.scope/basic.scope.namespace/p2.cpp
+++ clang/test/CXX/basic/basic.scope/basic.scope.namespace/p2.cpp
@@ -29,8 +29,7 @@
 #endif
 
 void test_early() {
-  in_header = 1; // expected-error {{missing '#include "foo.h"'; 'in_header' 
must be declared before it is used}}
-  // expected-note@*{{not visible}}
+  in_header = 1; // expected-error {{use of undeclared identifier 'in_header'}}
 
   global_module_fragment = 1; // expected-error {{missing '#include'; 
'global_module_fragment' must be declared before it is used}}
   // expected-n...@p2.cpp:16 {{not visible}}
@@ -54,8 +53,7 @@
 #endif
 
 void test_late() {
-  in_header = 1; // expected-error {{missing '#include "foo.h"'; 'in_header' 
must be declared before it is used}}
-  // expected-note@*{{not visible}}
+  in_header = 1; // expected-error {{use of undeclared identifier 'in_header'}}
 
   global_module_fragment = 1; // expected-error {{missing '#include'; 
'global_module_fragment' must be declared before it is used}}
   // expected-n...@p2.cpp:16 {{not visible}}
Index: clang/lib/Sema/Sema.cpp
===
--- clang/lib/Sema/Sema.cpp
+++ clang/lib/Sema/Sema.cpp
@@ -1128,6 +1128,33 @@
   if (TUKind != TU_Prefix) {
 DiagnoseUseOfUnimplementedSelectors();
 
+// For C++20 modules, we are permitted to elide decls in the Global
+// Module Fragment of a module interface if they are unused in the body
+// of the interface.
+if (!ModuleScopes.empty() && ModuleScopes.back().ModuleInterface &&
+getLangOpts().CPlusPlusModules) {
+  auto *DC = getASTContext().getTranslationUnitDecl();
+  SmallVector WorkList;
+  for (DeclContext::decl_iterator DI = DC->decls_begin(),
+  DEnd = DC->decls_end();
+   DI != DEnd; ++DI) {
+Decl *D = *DI;
+Module *M;
+if (D->isImplicit() || !isa(D))
+  continue;
+M = D->getOwningModule();
+if (!M || !D->getOwningModule()->isGlobalModule())
+  continue;
+if (getASTContext().moduleInitializerContains(M, D))
+  continue;
+if (!D->isUsed(false) && !D->isReferenced())
+  WorkList.push_back(D);
+  }
+
+  for (auto *D : WorkList)
+DC->removeDecl(D);
+}
+
 ActOnEndOfTranslationUnitFragment(
 !ModuleScopes.empty() && ModuleScopes.back().Module->Kind ==
  Module::PrivateModuleFragment


Index: clang/test/CXX/basic/basic.scope/basic.scope.namespace/p2.cpp
===
--- clang/test/CXX/basic/basic.scope/basic.scope.namespace/p2.cpp
+++ clang/test/CXX/basic/basic.scope/basic.scope.namespace/p2.cpp
@@ -29,8 +29,7 @@
 #endif
 
 void test_early() {
-  in_header = 1; // expected-error {{missing '#include "foo.h"'; 'in_header' must be declared before it is used}}
-  // expected-note@*{{not visible}}
+  in_header = 1; // expected-error {{use of undeclared identifier 'in_header'}}
 
   global_module_fragment = 1; // expected-error {{missing '#include'; 'global_module_fragment' must be declared before it is used}}
   // expected-n...@p2.cpp:16 {{not visible}}
@@ -54,8 +53,7 @@
 #endif
 
 void test_late() {
-  in_header = 1; // expected-error {{missing '#include "foo.h"'; 'in_header' must be declared before it is used}}
-  // expected-note@*{{not visible}}
+  in_header = 1; // expected-error {{use of undeclared identifier 'in_header'}}
 
   global_module_fragment = 1; // expected-error {{missing '#include'; 'global_module_fragment' must be declared before it is used}}
   // expected-n...@p2.cpp:16 {{not visible}}
Index: clang/lib/Sema/Sema.cpp
===
--- clang/lib/Sema/Sema.cpp
+++ clang/lib/Sema/Sema.cpp
@@ -1128,6 +1128,33 @@
   if (TUKind != TU_Prefix) {
 DiagnoseUseOfUnimplementedSelectors();
 
+// For C++20 modules, we are permitted to elide decls in the Global
+// Module Fragment of a module interface if they are unused in the body
+// of the interface.
+if (!ModuleScopes.empty() && ModuleScopes.back().ModuleInterface &&
+getLangOpts().CPlusPlusModules) {
+  auto *DC = getASTContext().getTranslationUnitDecl();
+  SmallVector WorkList;
+  for

[PATCH] D126608: [clangd] Remove a test with a duplicate of FileCacheTests

[Sam McCall via Phabricator via cfe-commits]

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

Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126608

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

[PATCH] D120484: More explicit message when failing to find a mandatory cfi ressource file

[serge via Phabricator via cfe-commits]

serge-sans-paille updated this revision to Diff 433063.
serge-sans-paille added a comment.
Herald added a subscriber: MaskRay.
Herald added a project: All.

Updating test case / sorry for the delay


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

https://reviews.llvm.org/D120484

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/lib/Driver/SanitizerArgs.cpp
  clang/test/Driver/fsanitize-ignorelist.c


Index: clang/test/Driver/fsanitize-ignorelist.c
===
--- clang/test/Driver/fsanitize-ignorelist.c
+++ clang/test/Driver/fsanitize-ignorelist.c
@@ -64,7 +64,7 @@
 
 // If cfi_ignorelist.txt cannot be found in the resource dir, driver should 
fail.
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=cfi -flto 
-fvisibility=default -resource-dir=/dev/null %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-MISSING-CFI-IGNORELIST
-// CHECK-MISSING-CFI-IGNORELIST: error: no such file or directory: 
'{{.*}}cfi_ignorelist.txt'
+// CHECK-MISSING-CFI-IGNORELIST: error: missing required sanitizer ignorelist: 
'{{.*}}cfi_ignorelist.txt'
 
 // -fno-sanitize-ignorelist disables checking for cfi_ignorelist.txt in the 
resource dir.
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=cfi -flto 
-fvisibility=default -fno-sanitize-ignorelist -resource-dir=/dev/null %s -### 
2>&1 | FileCheck %s --check-prefix=CHECK-MISSING-CFI-NO-IGNORELIST
Index: clang/lib/Driver/SanitizerArgs.cpp
===
--- clang/lib/Driver/SanitizerArgs.cpp
+++ clang/lib/Driver/SanitizerArgs.cpp
@@ -168,7 +168,7 @@
 else if (BL.Mask == SanitizerKind::CFI && DiagnoseErrors)
   // If cfi_ignorelist.txt cannot be found in the resource dir, driver
   // should fail.
-  D.Diag(clang::diag::err_drv_no_such_file) << Path;
+  D.Diag(clang::diag::err_drv_missing_sanitizer_ignorelist) << Path;
   }
   validateSpecialCaseListFormat(
   D, IgnorelistFiles, clang::diag::err_drv_malformed_sanitizer_ignorelist,
Index: clang/include/clang/Basic/DiagnosticDriverKinds.td
===
--- clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -212,6 +212,8 @@
   "invalid deployment target for -stdlib=libc++ (requires %0 or later)">;
 def err_drv_invalid_argument_to_option : Error<
   "invalid argument '%0' to -%1">;
+def err_drv_missing_sanitizer_ignorelist : Error<
+  "missing required sanitizer ignorelist: '%0'">;
 def err_drv_malformed_sanitizer_ignorelist : Error<
   "malformed sanitizer ignorelist: '%0'">;
 def err_drv_malformed_sanitizer_coverage_allowlist : Error<


Index: clang/test/Driver/fsanitize-ignorelist.c
===
--- clang/test/Driver/fsanitize-ignorelist.c
+++ clang/test/Driver/fsanitize-ignorelist.c
@@ -64,7 +64,7 @@
 
 // If cfi_ignorelist.txt cannot be found in the resource dir, driver should fail.
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=cfi -flto -fvisibility=default -resource-dir=/dev/null %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-MISSING-CFI-IGNORELIST
-// CHECK-MISSING-CFI-IGNORELIST: error: no such file or directory: '{{.*}}cfi_ignorelist.txt'
+// CHECK-MISSING-CFI-IGNORELIST: error: missing required sanitizer ignorelist: '{{.*}}cfi_ignorelist.txt'
 
 // -fno-sanitize-ignorelist disables checking for cfi_ignorelist.txt in the resource dir.
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=cfi -flto -fvisibility=default -fno-sanitize-ignorelist -resource-dir=/dev/null %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-MISSING-CFI-NO-IGNORELIST
Index: clang/lib/Driver/SanitizerArgs.cpp
===
--- clang/lib/Driver/SanitizerArgs.cpp
+++ clang/lib/Driver/SanitizerArgs.cpp
@@ -168,7 +168,7 @@
 else if (BL.Mask == SanitizerKind::CFI && DiagnoseErrors)
   // If cfi_ignorelist.txt cannot be found in the resource dir, driver
   // should fail.
-  D.Diag(clang::diag::err_drv_no_such_file) << Path;
+  D.Diag(clang::diag::err_drv_missing_sanitizer_ignorelist) << Path;
   }
   validateSpecialCaseListFormat(
   D, IgnorelistFiles, clang::diag::err_drv_malformed_sanitizer_ignorelist,
Index: clang/include/clang/Basic/DiagnosticDriverKinds.td
===
--- clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -212,6 +212,8 @@
   "invalid deployment target for -stdlib=libc++ (requires %0 or later)">;
 def err_drv_invalid_argument_to_option : Error<
   "invalid argument '%0' to -%1">;
+def err_drv_missing_sanitizer_ignorelist : Error<
+  "missing required sanitizer ignorelist: '%0'">;
 def err_drv_malformed_sanitizer_ignorelist : Error<
   "malformed sanitizer ignorelist: '%0'">;
 def err_drv_malformed_sanitizer_

[PATCH] D126291: [flang][Driver] Update link job on windows

[Andrzej Warzynski via Phabricator via cfe-commits]

awarzynski added a comment.

Thanks for adding this, Diana! :)

Overall, makes sense to me. I have a couple of questions/points.

In D126291#3547023 , @rovka wrote:

> With this patch in place, we still need to add `-Xlinker -subsystem:console' 
> in order to compile a simple 'Hello World' to run from the console.

Is this behavior consistent with "clang.exe"? Also, any clue why is this 
needed? Some documentation here 
.
 I've scanned it and am no wiser :/

> I tried to use --ld-path=various/paths instead, but it seems to be ignored on 
> Windows (I even get a warning about "argument unused during compilation"). If 
> anyone has any ideas about how to make the test more robust, please let me 
> know.

From what I can see, `--ld-path` is parsed inside ToolChain::GetLinkerPath 
.
 This method **is used** in  Gnu.cpp 
,
 but not in MSVC.cpp. This is consistent with what you've observed, i.e. that 
`--ld-path` is ignored on Windows. I'm not aware of an alternative.




Comment at: flang/test/Driver/linker-flags-windows.f90:5-6
+
+! NOTE: The additional linker flags tested here are currently specified in
+! clang/lib/Driver/Toolchains/MSVC.cpp.
+! REQUIRES: system-windows

[nit] Would you mind updating [[ 
https://github.com/llvm/llvm-project/blob/e601b2a1542710789395ab1121b1ccc7076e39d1/flang/test/Driver/linker-flags.f90#L5-L9
 | linker-flags.f90 ]] so that the comments in both files are more consistent? 
In particular, this patch makes the following comment redundant:
> If you are running this test on a yet another platform and it is failing for 
> you, please either update the following or (preferably) update the linker 
> invocation accordingly.
I added it there as a hint for people adding support for platforms inconsistent 
with Unix. Having a dedicated Unix and Windows tests is better :) 


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

https://reviews.llvm.org/D126291

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

[PATCH] D125622: [clang-tidy] Reject invalid enum initializers in C files

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM with a few comments that can be addressed when you commit.




Comment at: 
clang-tools-extra/clang-tidy/modernize/IntegralLiteralExpressionMatcher.cpp:87-89
+  if (Length <= 1) {
+  return LiteralSize::Int;
+  }





Comment at: 
clang-tools-extra/clang-tidy/modernize/IntegralLiteralExpressionMatcher.cpp:91-93
+  bool SeenUnsigned{};
+  bool SeenLong{};
+  bool SeenLongLong{};

I (personally) think this is a more clear form of initialization to most folks, 
but don't insist.



Comment at: clang-tools-extra/clang-tidy/modernize/MacroToEnumCheck.cpp:326
+  bool Matched = Matcher.match();
+  if (LangOpts.C99 &&
+  (Matcher.largestLiteralSize() != LiteralSize::Int &&

LegalizeAdulthood wrote:
> aaron.ballman wrote:
> > And C89?
> `C99` was the earliest dialect of C I could find in `LangOptions.def`.  If 
> you can show me an earlier version for C, I'm happy to switch it.
This keeps catching folks out, I may add a helper method to make this far more 
clear. `!LangOpts.CPlusPlus` means "in a C mode" for us currently.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/modernize-macro-to-enum.c:3-7
+// C requires enum values to fit into an int.
+#define TOO_BIG1 1L
+#define TOO_BIG2 1UL
+#define TOO_BIG3 1LL
+#define TOO_BIG4 1ULL

LegalizeAdulthood wrote:
> aaron.ballman wrote:
> > How do we want to handle the fact that Clang has an extension to allow 
> > this? Perhaps we want a config option for pedantic vs non-pedantic fixes?
> I was trying to find a way to make it fail on gcc/clang on compiler explorer 
> and I couldn't get it to fail in either compiler
> 
> Where is the extension documented?  It appears to be on by default in both 
> compilers.
I don't think we have any documentation for it (we basically don't bother to 
document our implementation-defined behavior, which drives me mildly nuts -- we 
fall back on "the source code is the definitive documentation", which is not 
user-friendly at all).

That's why I was wondering if we wanted a pedantic vs non-pedantic option here. 
Pedantically, the behavior you have today is correct. However, because this is 
a super common extension to compilers, we might want to allow it to be 
transformed despite being pedantically an extension.

We can handle that as a follow-up though.


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

https://reviews.llvm.org/D125622

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

[PATCH] D114834: [clang][PR52088]Fix assertion failure when passing bool as the type of next parameter

[zhaohui via Phabricator via cfe-commits]

Lucas abandoned this revision.
Lucas added a comment.
Herald added a subscriber: jsji.
Herald added a project: All.

This issue has already been fixed by https://reviews.llvm.org/D116272.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114834

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

[clang] 858e627 - [Clang] Always set opaque pointers mode

[Nikita Popov via cfe-commits]

Author: Nikita Popov
Date: 2022-05-31T15:43:05+02:00
New Revision: 858e6273d938cc4d08ee053ddff3fe7b19eb302a

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

LOG: [Clang] Always set opaque pointers mode

Always set the opaque pointers mode, to make sure that
-no-opaque-pointers continues working when the default on the LLVM
side is flipped.

Added: 


Modified: 
clang/lib/CodeGen/CodeGenAction.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CodeGenAction.cpp 
b/clang/lib/CodeGen/CodeGenAction.cpp
index af7a60c179a67..4ffbecdf27411 100644
--- a/clang/lib/CodeGen/CodeGenAction.cpp
+++ b/clang/lib/CodeGen/CodeGenAction.cpp
@@ -1017,8 +1017,7 @@ CodeGenAction::CreateASTConsumer(CompilerInstance &CI, 
StringRef InFile) {
   if (BA != Backend_EmitNothing && !OS)
 return nullptr;
 
-  if (CI.getCodeGenOpts().OpaquePointers)
-VMContext->setOpaquePointers(true);
+  VMContext->setOpaquePointers(CI.getCodeGenOpts().OpaquePointers);
 
   // Load bitcode modules to link with, if we need to.
   if (LinkModules.empty())



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

[PATCH] D126642: [Clang] NFCI: Repurpose HasExtParameterInfos for HasExtraBitfields

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

I'm not sure I'm grokking hte difference between the ExtraBitfields and 
ExtParamInfos here.  Also, the 'hasBitfields' seems like the answer should just 
be 'no' in the case when its 'no'...




Comment at: clang/include/clang/AST/Type.h:4103
   bool hasExtraBitfields() const {
-return hasExtraBitfields(getExceptionSpecType());
+assert((getExceptionSpecType() != EST_Dynamic ||
+FunctionTypeBits.HasExtraBitfields) &&

Why is asking if we DO have extra bitfields an assert here?  I would think this 
is a valid question...

Why would 'dynamic' and extra-bitfields be exclusive here?



Comment at: clang/lib/AST/Type.cpp:3219
+ExtraBits = FunctionTypeExtraBitfields();
+  } else
+FunctionTypeBits.HasExtraBitfields = false;

this else should have braces, since the 'if' above does. (nit).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126642

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

[PATCH] D126642: [Clang] NFCI: Repurpose HasExtParameterInfos for HasExtraBitfields

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Thanks for this! I'm still thinking about the design for this, but spotted a 
few minor things that could be addressed in the meantime.




Comment at: clang/include/clang/AST/Type.h:3801-3802
   /// FunctionTypeBitfields. Aligned to alignof(void *) to maintain the
   /// alignment of subsequent objects in TrailingObjects. You must update
   /// hasExtraBitfields in FunctionProtoType after adding extra data here.
   struct alignas(void *) FunctionTypeExtraBitfields {

It looks like this comment is now out of date.



Comment at: clang/include/clang/AST/Type.h:3810
+/// Whether this function has extended parameter information.
+bool HasExtParameterInfos : 1;
+

More forward-looking given that `NumExceptionType` really should be an 8-bit 
wide bit-field.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126642

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

[PATCH] D119646: [clang] Allow consteval functions in default arguments

[Erich Keane via Phabricator via cfe-commits]

erichkeane accepted this revision.
erichkeane added a comment.

This seems innocuous enough, and seems to better reflect the intent of the 
standard, so LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119646

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

[PATCH] D126479: [Clang] Allow 'Complex float __attribute__((mode(HC)))'

[Jolanta Jensen via Phabricator via cfe-commits]

jolanta.jensen updated this revision to Diff 433081.
jolanta.jensen added a comment.

Addressing review comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126479

Files:
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/test/CodeGen/aarch64-attr-mode-complex.c
  clang/test/Sema/attr-mode-vector-types.c
  clang/test/Sema/attr-mode.c

Index: clang/test/Sema/attr-mode.c
===
--- clang/test/Sema/attr-mode.c
+++ clang/test/Sema/attr-mode.c
@@ -37,6 +37,11 @@
 __attribute__((mode(QI))) int invalid_func(void) { return 1; } // expected-error{{'mode' attribute only applies to variables, enums, typedefs, and non-static data members}}
 enum invalid_enum { A1 __attribute__((mode(QI))) }; // expected-error{{'mode' attribute only applies to}}
 
+typedef _Complex float c16a __attribute((mode(HC)));
+int c16a_test[sizeof(c16a) == 4 ? 1 : -1];
+typedef _Complex double c16b __attribute((mode(HC)));
+int c16b_test[sizeof(c16b) == 4 ? 1 : -1];
+
 typedef _Complex double c32 __attribute((mode(SC)));
 int c32_test[sizeof(c32) == 8 ? 1 : -1];
 typedef _Complex float c64 __attribute((mode(DC)));
Index: clang/test/Sema/attr-mode-vector-types.c
===
--- clang/test/Sema/attr-mode-vector-types.c
+++ clang/test/Sema/attr-mode-vector-types.c
@@ -22,8 +22,7 @@
 // expected-error@-1{{unsupported machine mode 'QC'}}
 // expected-error@-2{{type of machine mode does not match type of base type}}
 typedef _Complex float __attribute__((mode(HC))) __attribute__((vector_size(256))) vec_t9;
-// expected-error@-1{{unsupported machine mode 'HC'}}
-// expected-error@-2{{invalid vector element type '_Complex float'}}
+// expected-error@-1{{invalid vector element type '_Complex float'}}
 typedef int __attribute__((mode(SC))) __attribute__((vector_size(256))) vec_t10;
 // expected-error@-1{{type of machine mode does not match type of base type}}
 // expected-error@-2{{type of machine mode does not support base vector types}}
Index: clang/test/CodeGen/aarch64-attr-mode-complex.c
===
--- /dev/null
+++ clang/test/CodeGen/aarch64-attr-mode-complex.c
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -triple arm64-none-linux-gnu -emit-llvm %s -o - | FileCheck %s
+
+typedef _Complex float c16a __attribute((mode(HC)));
+typedef _Complex double c16b __attribute((mode(HC)));
+typedef _Complex float c32a __attribute((mode(SC)));
+typedef _Complex double c32b __attribute((mode(SC)));
+typedef _Complex float c64a __attribute((mode(DC)));
+typedef _Complex double c64b __attribute((mode(DC)));
+
+// CHECK: define{{.*}} { half, half } @c16_test([2 x half] noundef {{.*}}
+// CHECK:   ret { half, half } {{.*}}
+c16b c16_test(c16a x) {
+  return x + x;
+}
+
+// CHECK: define{{.*}} { float, float } @c32_test([2 x float] noundef {{.*}})
+// CHECK:   ret { float, float } {{.*}}
+c32b c32_test(c32a x) {
+  return x + x;
+}
+
+// CHECK: define{{.*}} { double, double } @c64_test([2 x double] noundef {{.*}})
+// CHECK:   ret { double, double } {{.*}}
+c64b c64_test(c64a x) {
+  return x + x;
+}
Index: clang/lib/Basic/TargetInfo.cpp
===
--- clang/lib/Basic/TargetInfo.cpp
+++ clang/lib/Basic/TargetInfo.cpp
@@ -284,6 +284,8 @@
 
 FloatModeKind TargetInfo::getRealTypeByWidth(unsigned BitWidth,
  FloatModeKind ExplicitType) const {
+  if (getHalfWidth() == BitWidth)
+return FloatModeKind::Half;
   if (getFloatWidth() == BitWidth)
 return FloatModeKind::Float;
   if (getDoubleWidth() == BitWidth)
Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -11742,6 +11742,8 @@
   FloatModeKind Ty =
   getTargetInfo().getRealTypeByWidth(DestWidth, ExplicitType);
   switch (Ty) {
+  case FloatModeKind::Half:
+return HalfTy;
   case FloatModeKind::Float:
 return FloatTy;
   case FloatModeKind::Double:
Index: clang/include/clang/Basic/TargetInfo.h
===
--- clang/include/clang/Basic/TargetInfo.h
+++ clang/include/clang/Basic/TargetInfo.h
@@ -56,7 +56,8 @@
   Double,
   LongDouble,
   Float128,
-  Ibm128
+  Ibm128,
+  Half
 };
 
 /// Fields controlling how types are laid out in memory; these may need to
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D126479: [Clang] Allow 'Complex float __attribute__((mode(HC)))'

[Jolanta Jensen via Phabricator via cfe-commits]

jolanta.jensen added inline comments.



Comment at: clang/test/Sema/attr-mode.c:40
 
+typedef _Complex float c16a __attribute((mode(HC)));
+int c16a_test[sizeof(c16a) == 4 ? 1 : -1];

mgabka wrote:
> shouldn't we have here and in the line below : "// expected-no-diagnostics" ?
I don't think we can have both expected-error and expected-no-diagnostic in the 
same file.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126479

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

[PATCH] D126479: [Clang] Allow 'Complex float __attribute__((mode(HC)))'

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a reviewer: tahonermann.
aaron.ballman added inline comments.



Comment at: clang/lib/Basic/TargetInfo.cpp:287-288
  FloatModeKind ExplicitType) const 
{
+  if (getHalfWidth() == BitWidth)
+return FloatModeKind::Half;
   if (getFloatWidth() == BitWidth)

I *think* this is correct, but it's a bit worrying because we have multiple 
floating-point types with the same width. e.g., `HalfTy` and `BFloat16Ty`, so I 
am a bit uncomfortable with the `getRealTypeByWidth()` interface in general 
once we go down this route. `getRealTypeForBitwidth()` will have similar issues.



Comment at: clang/test/CodeGen/aarch64-attr-mode-complex.c:3-4
+
+typedef _Complex float c16a __attribute((mode(HC)));
+typedef _Complex double c16b __attribute((mode(HC)));
+typedef _Complex float c32a __attribute((mode(SC)));

Don't your changes also impact the behavior for `mode(HF)`? If so, there should 
be test coverage added for it.



Comment at: clang/test/Sema/attr-mode.c:40
 
+typedef _Complex float c16a __attribute((mode(HC)));
+int c16a_test[sizeof(c16a) == 4 ? 1 : -1];

jolanta.jensen wrote:
> mgabka wrote:
> > shouldn't we have here and in the line below : "// expected-no-diagnostics" 
> > ?
> I don't think we can have both expected-error and expected-no-diagnostic in 
> the same file.
Nope -- that marker is only for when the entire test file expects no 
diagnostics.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126479

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

[PATCH] D126186: [clang-tidy] Extend cert-oop57-cpp to check non-zero memset values

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126186

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

[PATCH] D116638: [clang-format] Fix ignoring JavaScriptWrapImport when ColumnWidth: 0

[Andrey Mishchenko via Phabricator via cfe-commits]

andmis added a comment.

In D116638#3545246 , @stasm wrote:

> I'm still interested in seeing this fixed. Would it help if I rebased this 
> change and addressed the outstanding review comments?

Go for it! I don't plan to do any further work on this. (I'm the original 
author of the patch.)


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

https://reviews.llvm.org/D116638

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

[clang] 35b1cfc - [Driver][Modules] Remove dependence on linking support from clang/test/Driver/modules.cpp

[Daniel McIntosh via cfe-commits]

Author: Daniel McIntosh
Date: 2022-05-31T10:33:55-04:00
New Revision: 35b1cfc76f08faabf3f27c0bd054acc7c854a6ca

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

LOG: [Driver][Modules] Remove dependence on linking support from 
clang/test/Driver/modules.cpp

The new tests in clang/test/Driver/modules.cpp added by D120540 will fail if the
toolchain getting tested doesn't support linking. This reduces the utility of
the test since we would like a failure of this test to reflect a problem with
modules. We should already have other tests that validate linking support.

Reviewed By: ChuanqiXu

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

Added: 


Modified: 
clang/test/Driver/modules.cpp

Removed: 




diff  --git a/clang/test/Driver/modules.cpp b/clang/test/Driver/modules.cpp
index 472b07c657992..f532b5b3c775f 100644
--- a/clang/test/Driver/modules.cpp
+++ b/clang/test/Driver/modules.cpp
@@ -76,11 +76,8 @@ FOO;
 
 // Check the independent use of -fcxx-modules
 //
-// RUN: %clang -fcxx-modules -std=c++17 -### %s 2>&1 | FileCheck %s 
--check-prefix=CHECK-CXX17-MODULES
-// CHECK-CXX17-MODULES: "-fcxx-modules"
-// RUN: %clang -fcxx-modules -std=c++14 -### %s 2>&1 | FileCheck %s 
--check-prefix=CHECK-CXX14-MODULES
-// CHECK-CXX14-MODULES: "-fcxx-modules"
-// RUN: %clang -fcxx-modules -std=c++11 -### %s 2>&1 | FileCheck %s 
--check-prefix=CHECK-CXX11-MODULES
-// CHECK-CXX11-MODULES: "-fcxx-modules"
-// RUN: %clang -fcxx-modules -std=c++03 -### %s 2>&1 | FileCheck %s 
--check-prefix=CHECK-CXX03-MODULES
-// CHECK-CXX03-MODULES: "-fcxx-modules"
+// RUN: %clang -fcxx-modules -std=c++17 -### -c %s 2>&1 | FileCheck %s 
--check-prefix=CHECK-CXX-MODULES
+// RUN: %clang -fcxx-modules -std=c++14 -### -c %s 2>&1 | FileCheck %s 
--check-prefix=CHECK-CXX-MODULES
+// RUN: %clang -fcxx-modules -std=c++11 -### -c %s 2>&1 | FileCheck %s 
--check-prefix=CHECK-CXX-MODULES
+// RUN: %clang -fcxx-modules -std=c++03 -### -c %s 2>&1 | FileCheck %s 
--check-prefix=CHECK-CXX-MODULES
+// CHECK-CXX-MODULES: "-fcxx-modules"



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

[PATCH] D126669: [Driver][Modules] Remove dependence on linking support from clang/test/Driver/modules.cpp

[Daniel McIntosh via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG35b1cfc76f08: [Driver][Modules] Remove dependence on linking 
support from… (authored by DanielMcIntosh-IBM).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126669

Files:
  clang/test/Driver/modules.cpp


Index: clang/test/Driver/modules.cpp
===
--- clang/test/Driver/modules.cpp
+++ clang/test/Driver/modules.cpp
@@ -76,11 +76,8 @@
 
 // Check the independent use of -fcxx-modules
 //
-// RUN: %clang -fcxx-modules -std=c++17 -### %s 2>&1 | FileCheck %s 
--check-prefix=CHECK-CXX17-MODULES
-// CHECK-CXX17-MODULES: "-fcxx-modules"
-// RUN: %clang -fcxx-modules -std=c++14 -### %s 2>&1 | FileCheck %s 
--check-prefix=CHECK-CXX14-MODULES
-// CHECK-CXX14-MODULES: "-fcxx-modules"
-// RUN: %clang -fcxx-modules -std=c++11 -### %s 2>&1 | FileCheck %s 
--check-prefix=CHECK-CXX11-MODULES
-// CHECK-CXX11-MODULES: "-fcxx-modules"
-// RUN: %clang -fcxx-modules -std=c++03 -### %s 2>&1 | FileCheck %s 
--check-prefix=CHECK-CXX03-MODULES
-// CHECK-CXX03-MODULES: "-fcxx-modules"
+// RUN: %clang -fcxx-modules -std=c++17 -### -c %s 2>&1 | FileCheck %s 
--check-prefix=CHECK-CXX-MODULES
+// RUN: %clang -fcxx-modules -std=c++14 -### -c %s 2>&1 | FileCheck %s 
--check-prefix=CHECK-CXX-MODULES
+// RUN: %clang -fcxx-modules -std=c++11 -### -c %s 2>&1 | FileCheck %s 
--check-prefix=CHECK-CXX-MODULES
+// RUN: %clang -fcxx-modules -std=c++03 -### -c %s 2>&1 | FileCheck %s 
--check-prefix=CHECK-CXX-MODULES
+// CHECK-CXX-MODULES: "-fcxx-modules"


Index: clang/test/Driver/modules.cpp
===
--- clang/test/Driver/modules.cpp
+++ clang/test/Driver/modules.cpp
@@ -76,11 +76,8 @@
 
 // Check the independent use of -fcxx-modules
 //
-// RUN: %clang -fcxx-modules -std=c++17 -### %s 2>&1 | FileCheck %s --check-prefix=CHECK-CXX17-MODULES
-// CHECK-CXX17-MODULES: "-fcxx-modules"
-// RUN: %clang -fcxx-modules -std=c++14 -### %s 2>&1 | FileCheck %s --check-prefix=CHECK-CXX14-MODULES
-// CHECK-CXX14-MODULES: "-fcxx-modules"
-// RUN: %clang -fcxx-modules -std=c++11 -### %s 2>&1 | FileCheck %s --check-prefix=CHECK-CXX11-MODULES
-// CHECK-CXX11-MODULES: "-fcxx-modules"
-// RUN: %clang -fcxx-modules -std=c++03 -### %s 2>&1 | FileCheck %s --check-prefix=CHECK-CXX03-MODULES
-// CHECK-CXX03-MODULES: "-fcxx-modules"
+// RUN: %clang -fcxx-modules -std=c++17 -### -c %s 2>&1 | FileCheck %s --check-prefix=CHECK-CXX-MODULES
+// RUN: %clang -fcxx-modules -std=c++14 -### -c %s 2>&1 | FileCheck %s --check-prefix=CHECK-CXX-MODULES
+// RUN: %clang -fcxx-modules -std=c++11 -### -c %s 2>&1 | FileCheck %s --check-prefix=CHECK-CXX-MODULES
+// RUN: %clang -fcxx-modules -std=c++03 -### -c %s 2>&1 | FileCheck %s --check-prefix=CHECK-CXX-MODULES
+// CHECK-CXX-MODULES: "-fcxx-modules"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D126186: [clang-tidy] Extend cert-oop57-cpp to check non-zero memset values

[Eugene Zelenko via Phabricator via cfe-commits]

Eugene.Zelenko added inline comments.



Comment at: clang-tools-extra/docs/ReleaseNotes.rst:160
+- Made :doc:`cert-oop57-cpp ` more sensitive
+  by checking for an arbitrary expression in the second argument of `memset`.
+

Please use double back-ticks for language constructs.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126186

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

[PATCH] D126308: cmake: use llvm dir variables for clang/utils/hmaptool

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

In D126308#3546235 , @mizvekov wrote:

> In D126308#3545937 , @Ericson2314 
> wrote:
>
>> There is a lot of cruft behind the signs. I would just use 
>> `LLVM_TOOLS_INSTALL_DIR` then which is exported to get this unblocked, and 
>> I'll rebase D117977  to try to clean these 
>> things up later.
>
> Done in https://reviews.llvm.org/D126671

Thanks for the fix! Unfortunately I'm still seeing a build failure related to 
this change:

  [176/1855] cd 
/builddir/build/BUILD/clang-15.0.0.src/redhat-linux-build/utils/hmaptool && 
/usr/bin/cmake -E copy 
/builddir/build/BUILD/clang-15.0.0.src/utils/hmaptool/hmaptool /usr/bin
  FAILED: /usr/bin/hmaptool
  cd /builddir/build/BUILD/clang-15.0.0.src/redhat-linux-build/utils/hmaptool 
&& /usr/bin/cmake -E copy 
/builddir/build/BUILD/clang-15.0.0.src/utils/hmaptool/hmaptool /usr/bin
  Error copying file 
"/builddir/build/BUILD/clang-15.0.0.src/utils/hmaptool/hmaptool" to "/usr/bin".

TBH I don't really understand why this fails and I can't reproduce this when 
running the commands manually. I'd have said there is a race condition here due 
to a missing dependency, but as this is copying a file from the source 
directory, I don't really see how that could be.

However, seeing this copy command, I think the change being make here is 
fundamentally incorrect. This is copying hmaptool into LLVM_TOOLS_BINARY_DIR 
(as part of the normal build, //not// as part of an install command), where 
LLVM_TOOLS_BINARY_DIR is the location of the //installed// LLVM tools. This 
means we end up copying `hmaptool` into something like `/usr/bin` as part of a 
normal build, which definitely shouldn't be happening. The tool should only get 
copied into the right location in the cmake build directory (which is what the 
previous implementation did).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126308

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

[PATCH] D126397: [pseudo] Fix pseudo-gen usage when cross-compiling

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

In D126397#3547060 , @thakis wrote:

> Should pseudo-gen honor LLVM_USE_HOST_TOOLS too? It looks like it's basically 
> the same situation.

Yes, I agree, it should. I'll send a patch.
One caveat here: that there are (too) many possible configurations here, and 
little documentation or buildbot coverage, so we're kind of fixing this blind.

> Maybe it'd make sense to make this a tblgen-based tool? Then this would've 
> Just Worked.).

There are a few reasons it didn't seem like a good fit for tblgen:

- it necessarily has a dependency on a separate library clangPseudoGrammar (for 
now it's conceivably possible to copy into the tablegen backend, but soon this 
will include the LR automaton generator etc). I didn't see any precedent for 
this.
- tablegen isn't the right format for the input data, and so isn't adding any 
value except build system bits
- this isn't part of clang, and there isn't a clang-tools-extra-tblgen, so we'd 
need a new clang-pseudo-tblgen in any case. This would solve *some* problems, 
but not all.

> Regarding building native tools while cross compiling - for other tools so 
> far, we’ve also had the option to pass an option like 
> -DLLVM_TABLEGEN=path/to/llvm-tblgen. If all the needed native tools are 
> provided that way, the build doesn’t need to set up the nested native cmake 
> build while cross compiling. Should we prove a way to do that for this build 
> time generation tool too?

Yeah, it seems reasonable to spend a little bit more cmake complexity for this.
I hope it can be done in a few lines (digging into it) esp given how hard it is 
to maintain non-bot-covered cmake configs.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126397

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

[PATCH] D124486: [clangd] ExtractVariable support for C and Objective-C

[David Goldman via Phabricator via cfe-commits]

dgoldman added inline comments.



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp:418
+  if (const auto *ME = dyn_cast(E))
+if (const auto *TE = dyn_cast(ME->getBase()))
+  if (TE->isImplicit())

sammccall wrote:
> dgoldman wrote:
> > sammccall wrote:
> > > dgoldman wrote:
> > > > sammccall wrote:
> > > > > oops, I forgot one detail: we want ME->getBase()->IgnoreImpCasts()
> > > > > 
> > > > > (in `void nonConstMethod() { constMethod(); }` there's an 
> > > > > ImplicitCastExpr in there...
> > > > Hmm, is this right, I tested out that example and it seems like that's 
> > > > actually a `CXXMemberCallExpr` which this doesn't handle?
> > > The callee of the CXXMemberCallExpr is the MemberExpr i'm talking about 
> > > here.
> > Right but this code here doesn't handle CXXMemberCallExpr, only MemberExpr 
> > - so we don't even see the callee here. If I add the following above:
> > 
> > ```
> >   if (const auto *MCE = dyn_cast(E))
> > E = MCE->getCallee();
> > ```
> > 
> > and do `ME->getBase()->IgnoreImpCasts()` then:
> > 
> > 
> > ```
> > class Test {
> >   int constMethod() const { return 1; }
> >   int nonConstMethod() { return [[constMethod()]]; }
> > };
> > ```
> > 
> > will be unavailable.
> > Right but this code here doesn't handle CXXMemberCallExpr, only MemberExpr 
> > - so we don't even see the callee here.
> 
> I don't understand what you mean.
> 
> If you select `  int nonConstMethod() { return [[constMethod]](); }`, then 
> isn't N such a MemberExpr?
Nope, still seems to be `CXXMemberCallExpr`. I'll go ahead and land this with 
`ME->getBase()->IgnoreImpCasts()` check although the example isn't working as 
expected.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124486

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

[clang-tools-extra] ae67984 - [clangd] ExtractVariable support for C and Objective-C

[David Goldman via cfe-commits]

Author: David Goldman
Date: 2022-05-31T11:14:51-04:00
New Revision: ae67984ca6d89c7ccdbdca258cd05c151d8b6431

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

LOG: [clangd] ExtractVariable support for C and Objective-C

- Use the expression's type for non-C++ as the variable type. This works
  well, but might not preserve the typedefs due to type
  canonicalization.

- Improve support for Objective-C property references which are
  represented using `ObjCPropertyRefExpr` and `BuiltinType::PseudoObject`.

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

Added: 


Modified: 
clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp
clang-tools-extra/clangd/unittests/tweaks/ExtractVariableTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp 
b/clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp
index 942d7eec6dbd8..5efe09fb3cb27 100644
--- a/clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp
+++ b/clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp
@@ -5,6 +5,7 @@
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 
//===--===//
+#include "AST.h"
 #include "ParsedAST.h"
 #include "Protocol.h"
 #include "Selection.h"
@@ -50,6 +51,7 @@ class ExtractionContext {
 private:
   bool Extractable = false;
   const clang::Expr *Expr;
+  QualType VarType;
   const SelectionTree::Node *ExprNode;
   // Stmt before which we will extract
   const clang::Stmt *InsertionPoint = nullptr;
@@ -81,6 +83,31 @@ computeReferencedDecls(const clang::Expr *Expr) {
   return Visitor.ReferencedDecls;
 }
 
+static QualType computeVariableType(const Expr *Expr, const ASTContext &Ctx) {
+  if (Ctx.getLangOpts().CPlusPlus11)
+return Ctx.getAutoDeductType();
+
+  if (Expr->hasPlaceholderType(BuiltinType::PseudoObject)) {
+if (const auto *PR = dyn_cast(Expr)) {
+  if (PR->isMessagingSetter()) {
+// Don't support extracting a compound reference like `self.prop += 1`
+// since the meaning changes after extraction since we'll no longer 
call
+// the setter. Non compound access like `self.prop = 1` is invalid 
since
+// it returns nil (setter method must have a void return type).
+return QualType();
+  } else if (PR->isMessagingGetter()) {
+if (PR->isExplicitProperty())
+  return PR->getExplicitProperty()->getType();
+else
+  return PR->getImplicitPropertyGetter()->getReturnType();
+  }
+} else {
+  return QualType();
+}
+  }
+  return Expr->getType();
+}
+
 ExtractionContext::ExtractionContext(const SelectionTree::Node *Node,
  const SourceManager &SM,
  const ASTContext &Ctx)
@@ -90,6 +117,12 @@ ExtractionContext::ExtractionContext(const 
SelectionTree::Node *Node,
   InsertionPoint = computeInsertionPoint();
   if (InsertionPoint)
 Extractable = true;
+  VarType = computeVariableType(Expr, Ctx);
+  if (VarType.isNull())
+Extractable = false;
+  else
+// Strip the outer nullability since it's not common for local variables.
+AttributedType::stripOuterNullability(VarType);
 }
 
 // checks whether extracting before InsertionPoint will take a
@@ -173,9 +206,9 @@ ExtractionContext::insertDeclaration(llvm::StringRef 
VarName,
   toHalfOpenFileRange(SM, Ctx.getLangOpts(),
   InsertionPoint->getSourceRange())
   ->getBegin();
-  // FIXME: Replace auto with explicit type and add &/&& as necessary
-  std::string ExtractedVarDecl = std::string("auto ") + VarName.str() + " = " +
- ExtractionCode.str() + "; ";
+  std::string ExtractedVarDecl =
+  printType(VarType, ExprNode->getDeclContext(), VarName) + " = " +
+  ExtractionCode.str() + "; ";
   return tooling::Replacement(SM, InsertionLoc, 0, ExtractedVarDecl);
 }
 
@@ -365,15 +398,27 @@ bool eligibleForExtraction(const SelectionTree::Node *N) {
 return false;
 
   // Void expressions can't be assigned to variables.
-  if (const Type *ExprType = E->getType().getTypePtrOrNull())
-if (ExprType->isVoidType())
-  return false;
+  const Type *ExprType = E->getType().getTypePtrOrNull();
+  if (!ExprType || ExprType->isVoidType())
+return false;
+
+  // Must know the type of the result in order to spell it, or instead use
+  // `auto` in C++.
+  if (!N->getDeclContext().getParentASTContext().getLangOpts().CPlusPlus11 &&
+  !ExprType)
+return false;
 
   // A plain reference to a name (e.g. variable) isn't  worth extracting.
   // FIXME: really? What if it's e.g. `std::is_same::value`?
-  if (llvm::isa(E) || llvm::isa(E))
+  if (l

[PATCH] D124486: [clangd] ExtractVariable support for C and Objective-C

[David Goldman via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGae67984ca6d8: [clangd] ExtractVariable support for C and 
Objective-C (authored by dgoldman).

Changed prior to commit:
  https://reviews.llvm.org/D124486?vs=425914&id=433089#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124486

Files:
  clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp
  clang-tools-extra/clangd/unittests/tweaks/ExtractVariableTests.cpp

Index: clang-tools-extra/clangd/unittests/tweaks/ExtractVariableTests.cpp
===
--- clang-tools-extra/clangd/unittests/tweaks/ExtractVariableTests.cpp
+++ clang-tools-extra/clangd/unittests/tweaks/ExtractVariableTests.cpp
@@ -24,7 +24,7 @@
 int z;
   } t;
   // return statement
-  return t.b[[a]]r]](t.z)]];
+  return t.b[[a]]r]]([[t.z]])]];
 }
 void f() {
   int a = [[5 +]] [[4 * xyz]]();
@@ -59,11 +59,22 @@
   EXPECT_AVAILABLE(AvailableCases);
 
   ExtraArgs = {"-xc"};
-  const char *AvailableButC = R"cpp(
+  const char *AvailableC = R"cpp(
 void foo() {
   int x = [[1]];
 })cpp";
-  EXPECT_UNAVAILABLE(AvailableButC);
+  EXPECT_AVAILABLE(AvailableC);
+  ExtraArgs = {"-xobjective-c"};
+  const char *AvailableObjC = R"cpp(
+__attribute__((objc_root_class))
+@interface Foo
+@end
+@implementation Foo
+- (void)method {
+  int x = [[1 + 2]];
+}
+@end)cpp";
+  EXPECT_AVAILABLE(AvailableObjC);
   ExtraArgs = {};
 
   const char *NoCrashCases = R"cpp(
@@ -79,10 +90,12 @@
   const char *UnavailableCases = R"cpp(
 int xyz(int a = [[1]]) {
   struct T {
-int bar(int a = [[1]]);
+int bar(int a = [[1]]) {
+  int b = [[z]];
+}
 int z = [[1]];
   } t;
-  return [[t]].bar(t]].z]]);
+  return [[t]].bar([[t]].z);
 }
 void v() { return; }
 // function default argument
@@ -123,7 +136,7 @@
   EXPECT_UNAVAILABLE(UnavailableCases);
 
   // vector of pairs of input and output strings
-  const std::vector> InputOutputs = {
+  std::vector> InputOutputs = {
   // extraction from variable declaration/assignment
   {R"cpp(void varDecl() {
int a = 5 * (4 + (3 [[- 1)]]);
@@ -291,6 +304,99 @@
   for (const auto &IO : InputOutputs) {
 EXPECT_EQ(IO.second, apply(IO.first)) << IO.first;
   }
+
+  ExtraArgs = {"-xobjective-c"};
+  EXPECT_UNAVAILABLE(R"cpp(
+  __attribute__((objc_root_class))
+  @interface Foo
+  - (void)setMethod1:(int)a;
+  - (int)method1;
+  @property int prop1;
+  @end
+  @implementation Foo
+  - (void)method {
+[[self.method1]] = 1;
+[[self.method1]] += 1;
+[[self.prop1]] = 1;
+[[self.prop1]] += 1;
+  }
+  @end)cpp");
+  InputOutputs = {
+  // Function Pointers
+  {R"cpp(struct Handlers {
+   void (*handlerFunc)(int);
+ };
+ void runFunction(void (*func)(int)) {}
+ void f(struct Handlers *handler) {
+   runFunction([[handler->handlerFunc]]);
+ })cpp",
+   R"cpp(struct Handlers {
+   void (*handlerFunc)(int);
+ };
+ void runFunction(void (*func)(int)) {}
+ void f(struct Handlers *handler) {
+   void (*placeholder)(int) = handler->handlerFunc; runFunction(placeholder);
+ })cpp"},
+  {R"cpp(int (*foo(char))(int);
+ void bar() {
+   (void)[[foo('c')]];
+ })cpp",
+   R"cpp(int (*foo(char))(int);
+ void bar() {
+   int (*placeholder)(int) = foo('c'); (void)placeholder;
+ })cpp"},
+  {R"cpp(typedef long NSInteger;
+ void varDecl() {
+NSInteger a = 2 * 5;
+NSInteger b = [[a * 7]] + 3;
+ })cpp",
+   R"cpp(typedef long NSInteger;
+ void varDecl() {
+NSInteger a = 2 * 5;
+long placeholder = a * 7; NSInteger b = placeholder + 3;
+ })cpp"},
+  // Support ObjC property references (explicit property getter).
+  {R"cpp(__attribute__((objc_root_class))
+ @interface Foo
+ @property int prop1;
+ @end
+ @implementation Foo
+ - (void)method {
+   int x = [[self.prop1]] + 1;
+ }
+ @end)cpp",
+   R"cpp(__attribute__((objc_root_class))
+ @interface Foo
+ @property int prop1;
+ @end
+ @implementation Foo
+ - (void)method {
+   int placeholder = self.prop1; int x = placeholder + 1;
+ }
+ @end)cpp"},
+  // Support ObjC property references (implicit property getter).
+  {R"cpp(__attribute__((objc_root_class))
+   

[PATCH] D125723: [MSVC] Add support for MSVC pragma optimize

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/Parse/ParsePragma.cpp:3662
+  }
+  ExprResult StringResult = Parser::ParseStringLiteralExpression();
+  if (StringResult.isInvalid())





Comment at: clang/lib/Parse/ParsePragma.cpp:3671
   }
   // We could syntax check the string but it's probably not worth the effort.
 

I think we should be syntax checking the string. Microsoft doesn't, but... 
what's the benefit to silently doing nothing?



Comment at: clang/lib/Sema/SemaAttr.cpp:1099
 
+void Sema::ActOnPragmaMSOptimize(SourceLocation Loc, bool On,
+ StringRef OptimizationList) {

I got tripped up below by seeing `[On]` and thinking it only ever looped over 
the "enabled" items in the list.



Comment at: clang/lib/Sema/SemaAttr.cpp:1108
+MSOptimizeOperations.clear();
+if (!On) {
+  MSOptimizeOperations.push_back(&Sema::AddOptnoneAttributeIfNoConflicts);

It looks like we're not handling this bit of the MS documentation: 
```
Using the optimize pragma with the empty string ("") is a special form of the 
directive:

...

When you use the on parameter, it resets the optimizations to the ones that you 
specified using the /O compiler option.
```



Comment at: clang/lib/Sema/SemaAttr.cpp:1224
+  FD->dropAttr();
+  FD->addAttr(NeverOptimizeNoneAttr::CreateImplicit(Context));
+}

Can you explain why this is needed?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125723

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

[PATCH] D126664: Expand definition deprecation warning to include constexpr statements.

[Hans Wennborg via Phabricator via cfe-commits]

hans added a reviewer: aaron.ballman.
hans added a comment.

Looks reasonable to me. It would be good if Richard or Aaron could take a look 
too.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126664

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

[PATCH] D125723: [MSVC] Add support for MSVC pragma optimize

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/Sema/SemaAttr.cpp:1207-1213
+  FD->addAttr(FramePointerAttr::CreateImplicit(Context, Kind));
+}
+
+void Sema::AddOptsize(FunctionDecl *FD, SourceLocation Loc) {
+  FD->dropAttr();
+  OptimizeSizeAttr::Kind Kind = OptimizeSizeAttr::On;
+  FD->addAttr(OptimizeSizeAttr::CreateImplicit(Context, Kind));

Rather than creating two new, implicit attributes for this, why not add support 
for `__attribute__((optimize(...)))` from GCC and reuse that one?

https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes

It seems like that serves the same function as these implicit attributes, but 
then users would get two features for the price of one.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125723

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

[PATCH] D126704: [HIP] Pass -Xoffload-linker option to device linker

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl created this revision.
yaxunl added a reviewer: tra.
Herald added a project: All.
yaxunl requested review of this revision.
Herald added a subscriber: MaskRay.

Reuse -Xoffload-linker option for HIP toolchain.


https://reviews.llvm.org/D126704

Files:
  clang/lib/Driver/ToolChains/HIPAMD.cpp
  clang/test/Driver/hip-options.hip


Index: clang/test/Driver/hip-options.hip
===
--- clang/test/Driver/hip-options.hip
+++ clang/test/Driver/hip-options.hip
@@ -106,3 +106,13 @@
 // RUN:   --offload-arch=gfx906 -fopenmp -fopenmp-targets=amdgcn %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=OMPTGT %s
 // OMPTGT: unsupported option '-fopenmp-targets=' for language mode 'HIP'
+
+// Check -Xoffload-linker option is passed to lld.
+
+// RUN: %clang -### --target=x86_64-unknown-linux-gnu -nogpuinc -nogpulib \
+// RUN:   --cuda-gpu-arch=gfx906 -fgpu-rdc -Xoffload-linker --build-id=md5 %s 
2>&1 \
+// RUN:   | FileCheck -check-prefix=OFL-LINK %s
+// RUN: %clang -### --target=x86_64-unknown-linux-gnu -nogpuinc -nogpulib \
+// RUN:   --cuda-gpu-arch=gfx906 -Xoffload-linker --build-id=md5 %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=OFL-LINK %s
+// OFL-LINK: lld{{.*}}"--build-id=md5"
Index: clang/lib/Driver/ToolChains/HIPAMD.cpp
===
--- clang/lib/Driver/ToolChains/HIPAMD.cpp
+++ clang/lib/Driver/ToolChains/HIPAMD.cpp
@@ -153,6 +153,9 @@
 
   addLinkerCompressDebugSectionsOption(TC, Args, LldArgs);
 
+  for (auto *Arg : Args.filtered(options::OPT_Xoffload_linker))
+LldArgs.push_back(Arg->getValue(1));
+
   LldArgs.append({"-o", Output.getFilename()});
   for (auto Input : Inputs)
 LldArgs.push_back(Input.getFilename());


Index: clang/test/Driver/hip-options.hip
===
--- clang/test/Driver/hip-options.hip
+++ clang/test/Driver/hip-options.hip
@@ -106,3 +106,13 @@
 // RUN:   --offload-arch=gfx906 -fopenmp -fopenmp-targets=amdgcn %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=OMPTGT %s
 // OMPTGT: unsupported option '-fopenmp-targets=' for language mode 'HIP'
+
+// Check -Xoffload-linker option is passed to lld.
+
+// RUN: %clang -### --target=x86_64-unknown-linux-gnu -nogpuinc -nogpulib \
+// RUN:   --cuda-gpu-arch=gfx906 -fgpu-rdc -Xoffload-linker --build-id=md5 %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=OFL-LINK %s
+// RUN: %clang -### --target=x86_64-unknown-linux-gnu -nogpuinc -nogpulib \
+// RUN:   --cuda-gpu-arch=gfx906 -Xoffload-linker --build-id=md5 %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=OFL-LINK %s
+// OFL-LINK: lld{{.*}}"--build-id=md5"
Index: clang/lib/Driver/ToolChains/HIPAMD.cpp
===
--- clang/lib/Driver/ToolChains/HIPAMD.cpp
+++ clang/lib/Driver/ToolChains/HIPAMD.cpp
@@ -153,6 +153,9 @@
 
   addLinkerCompressDebugSectionsOption(TC, Args, LldArgs);
 
+  for (auto *Arg : Args.filtered(options::OPT_Xoffload_linker))
+LldArgs.push_back(Arg->getValue(1));
+
   LldArgs.append({"-o", Output.getFilename()});
   for (auto Input : Inputs)
 LldArgs.push_back(Input.getFilename());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 10555a8 - [PS5] Tweak dllexport test

[Paul Robinson via cfe-commits]

Author: Paul Robinson
Date: 2022-05-31T08:22:15-07:00
New Revision: 10555a82df22bf67a9c30165e952b44969b46b6f

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

LOG: [PS5] Tweak dllexport test

Post-commit review pointed out that both PS4 and PS5 were using the
same -std argument, better to use different ones just in case.

Added: 


Modified: 
clang/test/SemaCXX/dllexport.cpp

Removed: 




diff  --git a/clang/test/SemaCXX/dllexport.cpp 
b/clang/test/SemaCXX/dllexport.cpp
index 4aa1427563a2e..7d8bfdadbb839 100644
--- a/clang/test/SemaCXX/dllexport.cpp
+++ b/clang/test/SemaCXX/dllexport.cpp
@@ -4,7 +4,7 @@
 // RUN: %clang_cc1 -triple x86_64-mingw32 -fsyntax-only 
-fms-extensions -verify -std=c++11 -Wunsupported-dll-base-class-template %s
 // RUN: %clang_cc1 -triple i686-windows-itanium   -fsyntax-only 
-fms-extensions -verify -std=c++11 -Wunsupported-dll-base-class-template -DWI %s
 // RUN: %clang_cc1 -triple x86_64-windows-itanium -fsyntax-only 
-fms-extensions -verify -std=c++1y -Wunsupported-dll-base-class-template -DWI %s
-// RUN: %clang_cc1 -triple x86_64-scei-ps4-fsyntax-only -fdeclspec 
 -verify -std=c++1y -Wunsupported-dll-base-class-template -DWI %s
+// RUN: %clang_cc1 -triple x86_64-scei-ps4-fsyntax-only -fdeclspec 
 -verify -std=c++11 -Wunsupported-dll-base-class-template -DWI %s
 // RUN: %clang_cc1 -triple x86_64-sie-ps5 -fsyntax-only -fdeclspec 
 -verify -std=c++1y -Wunsupported-dll-base-class-template -DWI %s
 
 // Helper structs to make templates more expressive.



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

[PATCH] D126308: cmake: use llvm dir variables for clang/utils/hmaptool

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added a comment.

In D126308#3547435 , @nikic wrote:

> In D126308#3546235 , @mizvekov 
> wrote:
>
>> In D126308#3545937 , @Ericson2314 
>> wrote:
>>
>>> There is a lot of cruft behind the signs. I would just use 
>>> `LLVM_TOOLS_INSTALL_DIR` then which is exported to get this unblocked, and 
>>> I'll rebase D117977  to try to clean 
>>> these things up later.
>>
>> Done in https://reviews.llvm.org/D126671
>
> Thanks for the fix! Unfortunately I'm still seeing a build failure related to 
> this change:
>
>   [176/1855] cd 
> /builddir/build/BUILD/clang-15.0.0.src/redhat-linux-build/utils/hmaptool && 
> /usr/bin/cmake -E copy 
> /builddir/build/BUILD/clang-15.0.0.src/utils/hmaptool/hmaptool /usr/bin
>   FAILED: /usr/bin/hmaptool
>   cd /builddir/build/BUILD/clang-15.0.0.src/redhat-linux-build/utils/hmaptool 
> && /usr/bin/cmake -E copy 
> /builddir/build/BUILD/clang-15.0.0.src/utils/hmaptool/hmaptool /usr/bin
>   Error copying file 
> "/builddir/build/BUILD/clang-15.0.0.src/utils/hmaptool/hmaptool" to 
> "/usr/bin".
>
> TBH I don't really understand why this fails and I can't reproduce this when 
> running the commands manually. I'd have said there is a race condition here 
> due to a missing dependency, but as this is copying a file from the source 
> directory, I don't really see how that could be.
>
> However, seeing this copy command, I think the change being make here is 
> fundamentally incorrect. This is copying hmaptool into LLVM_TOOLS_BINARY_DIR 
> (as part of the normal build, //not// as part of an install command), where 
> LLVM_TOOLS_BINARY_DIR is the location of the //installed// LLVM tools. This 
> means we end up copying `hmaptool` into something like `/usr/bin` as part of 
> a normal build, which definitely shouldn't be happening. The tool should only 
> get copied into the right location in the cmake build directory (which is 
> what the previous implementation did).

On a unified build, this is what I get:
`LLVM_TOOLS_BINARY_DIR: C:/Users/mizve/source/repos/llvm/build/dbg/llvm/./bin`

If on a standalone build that points to the llvm install dir, then this is 
confusing, but I understand now.

I will try to get this resolved, but if this is blocking you then feel free to 
revert for now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126308

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

[PATCH] D125788: [flang][driver] Rename `flang-new` as `flang`

[Steve Scalpone via Phabricator via cfe-commits]

sscalpone added a comment.

I'm fine with removing or renaming the existing flang shell script.

My proposal is not to wait for a 100% pass rate.   My proposal is to wait until 
the messages for unimplemented features are converted to TODOs that reference 
the program's source line and that legal programs which compile and link will 
execute without error.  In short, what flang compiles should work, and what 
flang doesn't compile should offer a reasonable message to the user to 
understand the limitation.

This proposal is not restricted to F95  but to 
any source that someone might attempt to compile.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125788

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

[PATCH] D126642: [Clang] NFCI: Repurpose HasExtParameterInfos for HasExtraBitfields

[Sander de Smalen via Phabricator via cfe-commits]

sdesmalen added a comment.

In D126642#3547284 , @erichkeane 
wrote:

> I'm not sure I'm grokking hte difference between the ExtraBitfields and 
> ExtParamInfos here.

The reason I repurposed the bit was because I previously tried adding a bit to 
`unsigned ExtInfo : 13;` but that fails

  static_assert(sizeof(*this) <= 8 + sizeof(ExtQualsTypeCommonBase), "changing 
bitfields changed sizeof(Type)!");

so perhaps incorrectly I assumed I couldn't add any new bits to FunctionType 
and thought I'd repurpose this one bit, because it's only ever used for 
FunctionProtoType (never for FunctionNoProtoType).

But I now realised I can just add an extra bit, so that we can leave this bit 
as-is. What do you think?




Comment at: clang/include/clang/AST/Type.h:4103
   bool hasExtraBitfields() const {
-return hasExtraBitfields(getExceptionSpecType());
+assert((getExceptionSpecType() != EST_Dynamic ||
+FunctionTypeBits.HasExtraBitfields) &&

erichkeane wrote:
> Why is asking if we DO have extra bitfields an assert here?  I would think 
> this is a valid question...
> 
> Why would 'dynamic' and extra-bitfields be exclusive here?
This assert is merely confirming that HasExtraBitfields **must** be true if the 
ExceptionSpecType is `EST_Dynamic`, because that was the old behaviour (and I 
wanted to avoid introducing failures if some code still assumed that 
hasExtraBitfields == true, but for some reason HasExtraBitfields had not yet 
been set to `true`).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126642

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

[PATCH] D126560: [analyzer][NFC] SimpleSValBuilder simplification: Remove superfluous workaround code

[Gabor Marton via Phabricator via cfe-commits]

martong updated this revision to Diff 433097.
martong added a comment.

- Add AssumeStack to track recursive assume calls


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126560

Files:
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/ConstraintManager.h
  clang/lib/StaticAnalyzer/Core/ConstraintManager.cpp
  clang/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp


Index: clang/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
===
--- clang/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
+++ clang/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
@@ -1190,7 +1190,6 @@
 
 const llvm::APSInt *SimpleSValBuilder::getKnownValue(ProgramStateRef state,
SVal V) {
-  V = simplifySVal(state, V);
   if (V.isUnknownOrUndef())
 return nullptr;
 
@@ -1376,14 +1375,6 @@
 SVal VisitSVal(SVal V) { return V; }
   };
 
-  // A crude way of preventing this function from calling itself from 
evalBinOp.
-  static bool isReentering = false;
-  if (isReentering)
-return V;
-
-  isReentering = true;
   SVal SimplifiedV = Simplifier(State).Visit(V);
-  isReentering = false;
-
   return SimplifiedV;
 }
Index: clang/lib/StaticAnalyzer/Core/ConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/ConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/ConstraintManager.cpp
@@ -16,6 +16,7 @@
 #include "clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/ProgramState_Fwd.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/SVals.h"
+#include "llvm/ADT/ScopeExit.h"
 
 using namespace clang;
 using namespace ento;
@@ -46,6 +47,19 @@
 ConstraintManager::ProgramStatePair
 ConstraintManager::assumeDualImpl(ProgramStateRef &State,
   AssumeFunction &Assume) {
+
+  // Assume functions might recurse (see `reAssume` or `tryRearrange`). During
+  // the recursion the State might not change anymore, that means we reached a
+  // fixpoint.
+  // We avoid infinite recursion of assume calls by checking already visited
+  // States on the stack of assume function calls.
+  const ProgramState *RawSt = State.get();
+  if (AssumeStack.hasCycle(RawSt))
+return {State, State};
+  AssumeStack.push(RawSt);
+  auto AssumeStackBuilder =
+  llvm::make_scope_exit([this, RawSt]() { AssumeStack.pop(RawSt); });
+
   ProgramStateRef StTrue = Assume(true);
 
   if (!StTrue) {
Index: clang/include/clang/StaticAnalyzer/Core/PathSensitive/ConstraintManager.h
===
--- clang/include/clang/StaticAnalyzer/Core/PathSensitive/ConstraintManager.h
+++ clang/include/clang/StaticAnalyzer/Core/PathSensitive/ConstraintManager.h
@@ -18,6 +18,7 @@
 #include "clang/StaticAnalyzer/Core/PathSensitive/SVals.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/SymExpr.h"
 #include "llvm/ADT/Optional.h"
+#include "llvm/ADT/SmallSet.h"
 #include "llvm/Support/SaveAndRestore.h"
 #include 
 #include 
@@ -144,6 +145,18 @@
   /// but not thread-safe.
   bool NotifyAssumeClients = true;
 
+  /// A helper class to simulate the call stack of nested assume calls.
+  class AssumeStackTy {
+  public:
+void push(const ProgramState *S) { Aux.insert(S); }
+void pop(const ProgramState *S) { Aux.erase(S); }
+bool hasCycle(const ProgramState *S) const { return Aux.contains(S); }
+
+  private:
+llvm::SmallSet Aux;
+  };
+  AssumeStackTy AssumeStack;
+
   virtual ProgramStateRef assumeInternal(ProgramStateRef state,
  DefinedSVal Cond, bool Assumption) = 
0;
 


Index: clang/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
===
--- clang/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
+++ clang/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
@@ -1190,7 +1190,6 @@
 
 const llvm::APSInt *SimpleSValBuilder::getKnownValue(ProgramStateRef state,
SVal V) {
-  V = simplifySVal(state, V);
   if (V.isUnknownOrUndef())
 return nullptr;
 
@@ -1376,14 +1375,6 @@
 SVal VisitSVal(SVal V) { return V; }
   };
 
-  // A crude way of preventing this function from calling itself from evalBinOp.
-  static bool isReentering = false;
-  if (isReentering)
-return V;
-
-  isReentering = true;
   SVal SimplifiedV = Simplifier(State).Visit(V);
-  isReentering = false;
-
   return SimplifiedV;
 }
Index: clang/lib/StaticAnalyzer/Core/ConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/ConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/ConstraintManager.cpp
@@ -16,6 +16,7 @@
 #include "clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h"
 #include "clang/Stati

[clang-tools-extra] c797952 - [clangd] Minor fixes to ExtractVariableTests missed in D124486

[David Goldman via cfe-commits]

Author: David Goldman
Date: 2022-05-31T11:34:35-04:00
New Revision: c797952d4f012275b2e23f5ffcab1f39eacd184d

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

LOG: [clangd] Minor fixes to ExtractVariableTests missed in D124486

Added: 


Modified: 
clang-tools-extra/clangd/unittests/tweaks/ExtractVariableTests.cpp

Removed: 




diff  --git 
a/clang-tools-extra/clangd/unittests/tweaks/ExtractVariableTests.cpp 
b/clang-tools-extra/clangd/unittests/tweaks/ExtractVariableTests.cpp
index bd06f318b2a9..70ecc202d0b2 100644
--- a/clang-tools-extra/clangd/unittests/tweaks/ExtractVariableTests.cpp
+++ b/clang-tools-extra/clangd/unittests/tweaks/ExtractVariableTests.cpp
@@ -305,22 +305,7 @@ TEST_F(ExtractVariableTest, Test) {
 EXPECT_EQ(IO.second, apply(IO.first)) << IO.first;
   }
 
-  ExtraArgs = {"-xobjective-c"};
-  EXPECT_UNAVAILABLE(R"cpp(
-  __attribute__((objc_root_class))
-  @interface Foo
-  - (void)setMethod1:(int)a;
-  - (int)method1;
-  @property int prop1;
-  @end
-  @implementation Foo
-  - (void)method {
-[[self.method1]] = 1;
-[[self.method1]] += 1;
-[[self.prop1]] = 1;
-[[self.prop1]] += 1;
-  }
-  @end)cpp");
+  ExtraArgs = {"-xc"};
   InputOutputs = {
   // Function Pointers
   {R"cpp(struct Handlers {
@@ -345,6 +330,7 @@ TEST_F(ExtractVariableTest, Test) {
  void bar() {
int (*placeholder)(int) = foo('c'); (void)placeholder;
  })cpp"},
+  // Arithmetic on typedef types yields plain integer types
   {R"cpp(typedef long NSInteger;
  void varDecl() {
 NSInteger a = 2 * 5;
@@ -355,6 +341,28 @@ TEST_F(ExtractVariableTest, Test) {
 NSInteger a = 2 * 5;
 long placeholder = a * 7; NSInteger b = placeholder + 3;
  })cpp"},
+  };
+  for (const auto &IO : InputOutputs) {
+EXPECT_EQ(IO.second, apply(IO.first)) << IO.first;
+  }
+
+  ExtraArgs = {"-xobjective-c"};
+  EXPECT_UNAVAILABLE(R"cpp(
+  __attribute__((objc_root_class))
+  @interface Foo
+  - (void)setMethod1:(int)a;
+  - (int)method1;
+  @property int prop1;
+  @end
+  @implementation Foo
+  - (void)method {
+[[self.method1]] = 1;
+[[self.method1]] += 1;
+[[self.prop1]] = 1;
+[[self.prop1]] += 1;
+  }
+  @end)cpp");
+  InputOutputs = {
   // Support ObjC property references (explicit property getter).
   {R"cpp(__attribute__((objc_root_class))
  @interface Foo



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

[PATCH] D126642: [Clang] NFCI: Repurpose HasExtParameterInfos for HasExtraBitfields

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

In D126642#3547496 , @sdesmalen wrote:

> In D126642#3547284 , @erichkeane 
> wrote:
>
>> I'm not sure I'm grokking hte difference between the ExtraBitfields and 
>> ExtParamInfos here.
>
> The reason I repurposed the bit was because I previously tried adding a bit 
> to `unsigned ExtInfo : 13;` but that fails
>
>   static_assert(sizeof(*this) <= 8 + sizeof(ExtQualsTypeCommonBase), 
> "changing bitfields changed sizeof(Type)!");

Right, yeah.  One thing to consider: `ExtInfo` was 'first', and so it got to 
keep the 'in bitfield bits'. However, much of what is in there is, IMO, not 
something that is used often enough to be worth having in there.  Of the bits 
being used there, I think 'NoReturn' is the only one used with any regularity 
(other than perhaps 'this call' in Windows-32-bit machines).  I wonder if we 
should consider moving as much of that as possible over.

> so perhaps incorrectly I assumed I couldn't add any new bits to FunctionType 
> and thought I'd repurpose this one bit, because it's only ever used for 
> FunctionProtoType (never for FunctionNoProtoType).
>
> But I now realised I can just add an extra bit, so that we can leave this bit 
> as-is. What do you think?

I think there is probably value to that, yes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126642

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

[PATCH] D126707: [analyzer][NFC] Move overconstrained check from reAssume to assumeDualImpl

[Gabor Marton via Phabricator via cfe-commits]

martong created this revision.
martong added reviewers: steakhal, NoQ.
Herald added subscribers: manas, ASDenysPetrov, gamesh411, dkrupp, donat.nagy, 
Szelethus, mikhail.ramalho, a.sidorin, rnkovacs, szepet, baloghadamsoftware, 
xazax.hun.
Herald added a reviewer: Szelethus.
Herald added a project: All.
martong requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Depends on D126406 . Checking of the 
overconstrained property is much
better suited here.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D126707

Files:
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h
  clang/lib/StaticAnalyzer/Core/ConstraintManager.cpp
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp


Index: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -20,8 +20,8 @@
 #include "llvm/ADT/FoldingSet.h"
 #include "llvm/ADT/ImmutableSet.h"
 #include "llvm/ADT/STLExtras.h"
-#include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/SmallSet.h"
+#include "llvm/ADT/StringExtras.h"
 #include "llvm/Support/Compiler.h"
 #include "llvm/Support/raw_ostream.h"
 #include 
@@ -2530,19 +2530,10 @@
   return State;
 }
 
-// We must declare reAssume in clang::ento, otherwise we could not declare that
-// as a friend in ProgramState. More precisely, the call of reAssume would be
-// ambiguous (one in the global namespace and an other which is declared in
-// ProgramState is in clang::ento).
-namespace clang {
-namespace ento {
 // Re-evaluate an SVal with top-level `State->assume` logic.
 LLVM_NODISCARD ProgramStateRef reAssume(ProgramStateRef State,
 const RangeSet *Constraint,
 SVal TheValue) {
-  assert(State);
-  if (State->isPosteriorlyOverconstrained())
-return nullptr;
   if (!Constraint)
 return State;
 
@@ -2565,8 +2556,6 @@
   return State->assumeInclusiveRange(DefinedVal, Constraint->getMinValue(),
  Constraint->getMaxValue(), true);
 }
-} // namespace ento
-} // namespace clang
 
 // Iterate over all symbols and try to simplify them. Once a symbol is
 // simplified then we check if we can merge the simplified symbol's equivalence
Index: clang/lib/StaticAnalyzer/Core/ConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/ConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/ConstraintManager.cpp
@@ -46,6 +46,9 @@
 ConstraintManager::ProgramStatePair
 ConstraintManager::assumeDualImpl(ProgramStateRef &State,
   AssumeFunction &Assume) {
+  if (State->isPosteriorlyOverconstrained())
+return {State, State};
+
   ProgramStateRef StTrue = Assume(true);
 
   if (!StTrue) {
Index: clang/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h
===
--- clang/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h
+++ clang/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h
@@ -118,8 +118,6 @@
   // overconstrained-related functions. We want to keep this API inaccessible
   // for Checkers.
   friend class ConstraintManager;
-  friend ProgramStateRef reAssume(ProgramStateRef State,
-  const RangeSet *Constraint, SVal TheValue);
   bool isPosteriorlyOverconstrained() const {
 return PosteriorlyOverconstrained;
   }


Index: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -20,8 +20,8 @@
 #include "llvm/ADT/FoldingSet.h"
 #include "llvm/ADT/ImmutableSet.h"
 #include "llvm/ADT/STLExtras.h"
-#include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/SmallSet.h"
+#include "llvm/ADT/StringExtras.h"
 #include "llvm/Support/Compiler.h"
 #include "llvm/Support/raw_ostream.h"
 #include 
@@ -2530,19 +2530,10 @@
   return State;
 }
 
-// We must declare reAssume in clang::ento, otherwise we could not declare that
-// as a friend in ProgramState. More precisely, the call of reAssume would be
-// ambiguous (one in the global namespace and an other which is declared in
-// ProgramState is in clang::ento).
-namespace clang {
-namespace ento {
 // Re-evaluate an SVal with top-level `State->assume` logic.
 LLVM_NODISCARD ProgramStateRef reAssume(ProgramStateRef State,
 const RangeSet *Constraint,
 SVal TheValue) {
-  assert(State);
-  if (State->isPosteriorlyOverconstrained())
-return nullptr;
   if (!Constraint)
 r

[clang] e22b02d - [Clang][Docs] Document the clang-offload-packager better

[Joseph Huber via cfe-commits]

Author: Joseph Huber
Date: 2022-05-31T11:53:27-04:00
New Revision: e22b02d9b4f8bb968628ac7cf2d9a42bf13e2898

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

LOG: [Clang][Docs] Document the clang-offload-packager better

Summary:
This patch adds more in-depth documentation to the
clang-offload-packacker's binary format. This format is used to create
fat binaries and link them.

Added: 


Modified: 
clang/docs/ClangOffloadPackager.rst

Removed: 




diff  --git a/clang/docs/ClangOffloadPackager.rst 
b/clang/docs/ClangOffloadPackager.rst
index 5d15cc4c5caf6..2211f3bd600f3 100644
--- a/clang/docs/ClangOffloadPackager.rst
+++ b/clang/docs/ClangOffloadPackager.rst
@@ -16,21 +16,130 @@ together. The image format is a small header wrapping 
around a string map. This
 tool creates bundled binaries so that they can be embedded into the host to
 create a fat-binary.
 
-An embedded binary is marked by the ``0x10FF10AD`` magic bytes, followed by a
+Binary Format
+=
+
+The binary format is marked by the ``0x10FF10AD`` magic bytes, followed by a
 version. Each created binary contains its own magic bytes. This allows us to
 locate all the embedded offloading sections even after they may have been 
merged
-by the linker, such as when using relocatable linking. The format used is
-primarily a binary serialization of the following struct.
-
-.. code-block:: c++
-
-  struct OffloadingImage {
-uint16_t TheImageKind;
-uint16_t TheOffloadKind;
-uint32_t Flags;
-StringMap StringData;
-MemoryBufferRef Image;
-  };
+by the linker, such as when using relocatable linking. Conceptually, this 
binary
+format is a serialization of a string map and an image buffer. The binary 
header
+is described in the following :ref:`table`.
+
+.. table:: Offloading Binary Header
+:name: table-binary_header
+
+
+--+--++
+|   Type   |  Identifier  | Description
|
+
+==+==++
+| uint8_t  |magic | The magic bytes for the binary format 
(0x10FF10AD) |
+
+--+--++
+| uint32_t |   version| Version of this format (currently version 1)   
|
+
+--+--++
+| uint64_t |size  | Size of this binary in bytes   
|
+
+--+--++
+| uint64_t | entry offset | Absolute offset of the offload entries in 
bytes|
+
+--+--++
+| uint64_t |  entry size  | Size of the offload entries in bytes   
|
+
+--+--++
+
+Once identified through the magic bytes, we use the size field to take a slice
+of the binary blob containing the information for a single offloading image. We
+can then use the offset field to find the actual offloading entries containing
+the image and metadata. The offload entry contains information about the device
+image. It contains the fields shown in the following
+:ref:`table`.
+
+.. table:: Offloading Entry Table
+:name: table-binary_entry
+
+
+--+---++
+|   Type   |   Identifier  | Description   
 |
+
+==+===++
+| uint16_t |  image kind   | The kind of the device image (e.g. bc, cubin) 
 |
+
+--+---++
+| uint16_t | offload kind  | The producer of the image (e.g. openmp, cuda) 
 |
+
+--+---++
+| uint32_t | flags | Generic flags for the image   
 |
+
+--+---++
+| uint64_t | string offset | Absolute offset of the string metadata table  
 |
+
+--+---++
+| uint64_t |  num strings  | Number of string entries in the table 
 |
+
+--+---++
+| uint64_t |  image offset | Absolute offset of the device image in bytes  
 |
+
+--+---++
+| uint64_t |   

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

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 433104.
Herald added a subscriber: jsji.

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

https://reviews.llvm.org/D113107

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

Index: clang/test/SemaCXX/Float16.cpp
===
--- clang/test/SemaCXX/Float16.cpp
+++ clang/test/SemaCXX/Float16.cpp
@@ -1,18 +1,10 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
-// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
 
-#ifdef HAVE
 // expected-no-diagnostics
-#endif // HAVE
 
-#ifndef HAVE
-// expected-error@+2{{_Float16 is not supported on this target}}
-#endif // !HAVE
 _Float16 f;
 
-#ifndef HAVE
-// expected-error@+2{{invalid suffix 'F16' on floating constant}}
-#endif // !HAVE
 const auto g = 1.1F16;
Index: clang/test/Sema/conversion-target-dep.c
===
--- clang/test/Sema/conversion-target-dep.c
+++ clang/test/Sema/conversion-target-dep.c
@@ -6,7 +6,7 @@
 
 long double ld;
 double d;
-_Float16 f16; // x86-error {{_Float16 is not supported on this target}}
+_Float16 f16;
 
 int main(void) {
   ld = d; // x86-warning {{implicit conversion increases floating-point precision: 'double' to 'long double'}}
Index: clang/test/Sema/Float16.c
===
--- clang/test/Sema/Float16.c
+++ clang/test/Sema/Float16.c
@@ -1,18 +1,12 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
-// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc -target-feature +avx512fp16 %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc -target-feature +avx512fp16 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
 
-#ifndef HAVE
-// expected-error@+2{{_Float16 is not supported on this target}}
-#endif // HAVE
-_Float16 f;
-
-#ifdef HAVE
 _Complex _Float16 a;
 void builtin_complex(void) {
   _Float16 a = 0;
   (void)__builtin_complex(a, a); // expected-error {{'_Complex _Float16' is invalid}}
 }
-#endif
+
Index: clang/test/CodeGen/X86/Float16-complex.c
===
--- clang/test/CodeGen/X86/Float16-complex.c
+++ clang/test/CodeGen/X86/Float16-complex.c
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -target-feature +avx512fp16 -o - | FileCheck %s --check-prefix=X86
+// RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -o - | FileCheck %s --check-prefixes=X86
 
 _Float16 _Complex add_half_rr(_Float16 a, _Float16 b) {
   // X86-LABEL: @add_half_rr(
Index: clang/test/CodeGen/X86/Float16-arithmetic.c
===
--- /dev/null
+++ clang/test/CodeGen/X86/Float16-arithmetic.c
@@ -0,0 +1,97 @@
+// RUN: %clang_cc1 -triple  x86_64-unknown-unknown \
+// RUN: -emit-llvm -o - %s  | FileCheck %s --check-prefixes=CHECK
+
+_Float16 add1(_Float16 a, _Float16 b) {
+  // CHECK-LABEL: define {{.*}} half @add1
+  // CHECK: alloca half
+  // CHECK: alloca half
+  // CHECK: store half {{.*}}, ptr {{.*}}
+  // CHECK: store half {{.*}}, ptr {{.*}}
+  // CHECK: load half, ptr {{.*}}
+  // CHECK: fpext half {{.*}} to float
+  // CHECK: load half, ptr {{.*}}
+  // CHECK: fpext half {{.*}} to float
+  // CHECK: fadd float {{.*}}, {{.*}}
+  // CHECK: fptrunc float {{.*}} to half
+  // CHECK: ret half
+  return a + b;
+}
+
+_Float16 add2(_Float16 a, _Float16 b, _Float16 c) {
+  // CHECK-LABEL: define dso_local half @add2
+  // CHECK: alloca half
+  // CHECK: alloca half
+  // CHECK: alloca half
+  // CHECK: store half {{.*}}, ptr {{.*}}
+  // CHECK: store half {{.*}}, ptr {{.*}}
+  // CHECK: store half {{.*}}, ptr {{.*}}
+  // C

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

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

In D113107#3520773 , @rjmccall wrote:

> Okay, well, first off, we definitely shouldn't be repeating conditions like 
> `isX86()` all over the place.  What you want to do is to have a general 
> predicate which answers whether we should emit this operation with excess 
> precision; imagine an architecture that wanted to emit `float` operations 
> with `double` and try to design something that would work for both your case 
> and that one.
>
> It looks like you ought to be able to use the abstraction around `BinOpInfo` 
> to good effect here.  You can add a promotion type on the `ScalarExprEmitter` 
> which, if set, tells the emitter that it should actually produce a value of 
> that type.  `EmitBinOps` can recognize that a promotion type is already set 
> and use that type as the operation type instead of the formal type of the 
> expression.  If a promotion type isn't set on the emitter, `EmitBinOps` can 
> try to recognize that it's in the case where it needs a promotion type; it 
> would then set a promotion type before evaluating the operands, but then 
> truncate the result (and clear the promotion type) before returning.  The 
> logic around compound assignment will take some care (and good testing), but 
> it should work the same basic way, and similarly in the complex emitter.

@rjmccall  Thanks for the review. I have updated the patch. There are still a 
few things  that I am not sure about, so I haven't' changed the complex emitter 
yet!
I have added as you suggested a promotion type to the ScalarExprEmitter and 
pushed most of things in EmitBinOps. The one thing that I am not sure about is 
the truncation. I don't seem able to do that in EmitBinOps since I don't really 
have a lvalue available. Please let me know if this is in the direction that 
you expected it to.
Once again thanks for the review and at your convenience please take a look at 
these latest changes.


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

https://reviews.llvm.org/D113107

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

[PATCH] D126397: [pseudo] Fix pseudo-gen usage when cross-compiling

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

In D126397#3547060 , @thakis wrote:

> Even after this, you still have to explicitly set 
> `-DCMAKE_SYSTEM_NAME=Darwin` when building clang for mac/arm on mac/intel. 
> Given that the host and target systems are both mac, that's a bit weird. 
> llvm-tblgen doesn't need this, it just works as long as you set 
> `LLVM_USE_HOST_TOOLS=ON`. Should pseudo-gen honor LLVM_USE_HOST_TOOLS too? It 
> looks like it's basically the same situation.
>
> (It's only the 2nd compiled binary in all of llvm that needs to run as part 
> of the build (if you count the various tblgen binaries as a single binary). 
> Maybe it'd make sense to make this a tblgen-based tool? Then this would've 
> Just Worked.).

I was checking for `CMAKE_CROSSCOMPILING` instead of `LLVM_USE_HOST_TOOLS` 
because I didn't want this to fire for `LLVM_OPTIMIZED_TABLEGEN`, but I guess 
`LLVM_OPTIMIZED_TABLEGEN` could be interpreted as a generic "optimized host 
tools" option in that case, given that the NATIVE build is always Release.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126397

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

[clang] 259a9df - [Clang][Docs] Fix typo in offload packager reference

[Joseph Huber via cfe-commits]

Author: Joseph Huber
Date: 2022-05-31T12:27:33-04:00
New Revision: 259a9df963ca5f28f325ed6f6bfe5da639c78cbf

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

LOG: [Clang][Docs] Fix typo in offload packager reference

Added: 


Modified: 
clang/docs/ClangOffloadPackager.rst

Removed: 




diff  --git a/clang/docs/ClangOffloadPackager.rst 
b/clang/docs/ClangOffloadPackager.rst
index 2211f3bd600f..707462b77eb8 100644
--- a/clang/docs/ClangOffloadPackager.rst
+++ b/clang/docs/ClangOffloadPackager.rst
@@ -76,7 +76,7 @@ along with some other integer information. The image kind 
lets us easily
 identify the type of image stored here without needing to inspect the binary.
 The offloading kind is used to determine which registration code or linking
 semantics are necessary for this image. These are stored as enumerations with
-the following values for the :ref:`offload kind` and the
 :ref:`image kind`.
 
 .. table:: Image Kind



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

[PATCH] D125585: [HLSL][clang][Driver] Parse target profile early to update Driver::TargetTriple.

[Chris Bieneman via Phabricator via cfe-commits]

beanz added inline comments.



Comment at: clang/lib/Driver/Driver.cpp:1249
+// Build TargetTriple from target_profile option for clang-dxc.
+if (const Arg *A = Args.getLastArg(options::OPT_target_profile)) {
+  StringRef TargetProfile = A->getValue();

The `-T` flag is required for DXCMode, so the else of this should emit an 
error. That also means the code above that explicitly sets the OS to 
ShaderModel can be removed too.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125585

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

[PATCH] D125723: [MSVC] Add support for MSVC pragma optimize

[Stephen Long via Phabricator via cfe-commits]

steplong added inline comments.



Comment at: clang/lib/Sema/SemaAttr.cpp:1207-1213
+  FD->addAttr(FramePointerAttr::CreateImplicit(Context, Kind));
+}
+
+void Sema::AddOptsize(FunctionDecl *FD, SourceLocation Loc) {
+  FD->dropAttr();
+  OptimizeSizeAttr::Kind Kind = OptimizeSizeAttr::On;
+  FD->addAttr(OptimizeSizeAttr::CreateImplicit(Context, Kind));

aaron.ballman wrote:
> Rather than creating two new, implicit attributes for this, why not add 
> support for `__attribute__((optimize(...)))` from GCC and reuse that one?
> 
> https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
> 
> It seems like that serves the same function as these implicit attributes, but 
> then users would get two features for the price of one.
Hmm that makes sense. So, `pragma optimize(on, "s")` would be equivalent to 
`__attribute__((optimize("-Os"))`. Could you give me a brief description of 
what I would have to do to implement the attribute? I'm new to this



Comment at: clang/lib/Sema/SemaAttr.cpp:1224
+  FD->dropAttr();
+  FD->addAttr(NeverOptimizeNoneAttr::CreateImplicit(Context));
+}

aaron.ballman wrote:
> Can you explain why this is needed?
I added this attr, so we can remove the attr optnone even if -O0 was passed on 
the cmdline


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125723

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

[PATCH] D126308: cmake: use llvm dir variables for clang/utils/hmaptool

[John Ericson via Phabricator via cfe-commits]

Ericson2314 added a comment.

I am sorry, I completely forgot one of my motivations for 
https://reviews.llvm.org/D117977 was that `LLVM_TOOLS_BINARY_DIR` was 
completely misnamed and just this sort of foot-gun!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126308

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

[PATCH] D125788: [flang][driver] Rename `flang-new` as `flang`

[Damian Rouson via Phabricator via cfe-commits]

rouson added a comment.

On Mon, May 30, 2022 at 2:39 AM Andrzej Warzynski via Phabricator 
 wrote:

> 1. Lets rename `flang` as `flang-to-external-fc` regardless of what's decided 
> for `flang-new`. That would already be a huge step forward (and  > would 
> reflect accurately what the bash wrapper script actually does).

I support this.  I think the proposed new name is better reflects what the 
current flang script currently does and thereby reduces the likelihood of 
surprise when a user sees an error message from an external compiler.

> 2. As for the NAG test suite, I hope that we can agree not to use it as the 
> condition for renaming `flang-new`. If it's decided that that's a valid > 
> equirement, then I agree with @kiranchandramohan that we should find a way to 
> openly track the progress towards the required pass rate
>
> (and how that's defined).

I agree.

> Perhaps we could discuss more in the call today?

Any news from the call?

Damian


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125788

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

[PATCH] D126137: [X86] Add support for `-mharden-sls=[none|all|return|indirect-jmp]`

[Nick Desaulniers via Phabricator via cfe-commits]

nickdesaulniers accepted this revision.
nickdesaulniers added a comment.
This revision is now accepted and ready to land.
Herald added a subscriber: jsji.

Thanks again Phoebe for the patch!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126137

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

[PATCH] D120201: [Clang] Extend -gen-reproducer flag

[Alex Brachet via Phabricator via cfe-commits]

abrachet updated this revision to Diff 433120.
abrachet marked an inline comment as done.
abrachet added a comment.

Fix tests on macOS and compile test with `-fsyntax-only`


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

https://reviews.llvm.org/D120201

Files:
  clang/include/clang/Driver/Driver.h
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/crash-report-crashfile.m
  clang/tools/driver/driver.cpp

Index: clang/tools/driver/driver.cpp
===
--- clang/tools/driver/driver.cpp
+++ clang/tools/driver/driver.cpp
@@ -482,32 +482,37 @@
   }
 
   std::unique_ptr C(TheDriver.BuildCompilation(Args));
+
+  Driver::ReproLevel ReproLevel = Driver::ReproLevel::OnCrash;
+  if (Arg *A = C->getArgs().getLastArg(options::OPT_gen_reproducer_eq)) {
+auto Level = llvm::StringSwitch>(A->getValue())
+ .Case("off", Driver::ReproLevel::Off)
+ .Case("crash", Driver::ReproLevel::OnCrash)
+ .Case("error", Driver::ReproLevel::OnError)
+ .Case("always", Driver::ReproLevel::Always)
+ .Default(None);
+if (!Level) {
+  llvm::errs() << "Unknown value for " << A->getSpelling() << ": '"
+   << A->getValue() << "'\n";
+  return 1;
+}
+ReproLevel = *Level;
+  }
+  if (!!::getenv("FORCE_CLANG_DIAGNOSTICS_CRASH"))
+ReproLevel = Driver::ReproLevel::Always;
+
   int Res = 1;
   bool IsCrash = false;
+  Driver::CommandStatus CommandStatus = Driver::CommandStatus::Ok;
+  // Pretend the first command failed if ReproStatus is Always.
+  const Command *FailingCommand = &*C->getJobs().begin();
   if (C && !C->containsError()) {
 SmallVector, 4> FailingCommands;
 Res = TheDriver.ExecuteCompilation(*C, FailingCommands);
 
-// Force a crash to test the diagnostics.
-if (TheDriver.GenReproducer) {
-  Diags.Report(diag::err_drv_force_crash)
-<< !::getenv("FORCE_CLANG_DIAGNOSTICS_CRASH");
-
-  // Pretend that every command failed.
-  FailingCommands.clear();
-  for (const auto &J : C->getJobs())
-if (const Command *C = dyn_cast(&J))
-  FailingCommands.push_back(std::make_pair(-1, C));
-
-  // Print the bug report message that would be printed if we did actually
-  // crash, but only if we're crashing due to FORCE_CLANG_DIAGNOSTICS_CRASH.
-  if (::getenv("FORCE_CLANG_DIAGNOSTICS_CRASH"))
-llvm::dbgs() << llvm::getBugReportMsg();
-}
-
 for (const auto &P : FailingCommands) {
   int CommandRes = P.first;
-  const Command *FailingCommand = P.second;
+  FailingCommand = P.second;
   if (!Res)
 Res = CommandRes;
 
@@ -526,13 +531,21 @@
   // https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap02.html
   IsCrash |= CommandRes > 128;
 #endif
-  if (IsCrash) {
-TheDriver.generateCompilationDiagnostics(*C, *FailingCommand);
+  CommandStatus =
+  IsCrash ? Driver::CommandStatus::Crash : Driver::CommandStatus::Error;
+  if (IsCrash)
 break;
-  }
 }
   }
 
+  // Print the bug report message that would be printed if we did actually
+  // crash, but only if we're crashing due to FORCE_CLANG_DIAGNOSTICS_CRASH.
+  if (::getenv("FORCE_CLANG_DIAGNOSTICS_CRASH"))
+llvm::dbgs() << llvm::getBugReportMsg();
+  if (TheDriver.maybeGenerateCompilationDiagnostics(CommandStatus, ReproLevel,
+*C, *FailingCommand))
+Res = 1;
+
   Diags.getClient()->finish();
 
   if (!UseNewCC1Process && IsCrash) {
Index: clang/test/Driver/crash-report-crashfile.m
===
--- clang/test/Driver/crash-report-crashfile.m
+++ clang/test/Driver/crash-report-crashfile.m
@@ -17,8 +17,8 @@
 @import simple;
 const int x = MODULE_MACRO;
 
-// CRASH_ENV: failing because environment variable 'FORCE_CLANG_DIAGNOSTICS_CRASH' is set
 // CRASH_ENV: PLEASE submit a bug report to {{.*}} and include the crash backtrace, preprocessed source, and associated run script.
+// CRASH_ENV: failing because environment variable 'FORCE_CLANG_DIAGNOSTICS_CRASH' is set
 // CRASH_ENV: Preprocessed source(s) and associated run script(s) are located at:
 // CRASH_ENV-NEXT: note: diagnostic msg: {{.*}}.m
 // CRASH_ENV-NEXT: note: diagnostic msg: {{.*}}.cache
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -198,8 +198,7 @@
   CCPrintOptions(false), CCPrintHeaders(false), CCLogDiagnostics(false),
   CCGenDiagnostics(false), CCPrintProcessStats(false),
   TargetTriple(TargetTriple), Saver(Alloc), CheckInputsExist(true),
-  ProbePrecompiled(true), GenReproducer(false),
-  SuppressMissingInputWarning(false) {
+  ProbePrecompiled(true), SuppressMi

[PATCH] D120201: [Clang] Extend -gen-reproducer flag

[Alex Brachet via Phabricator via cfe-commits]

abrachet updated this revision to Diff 433122.

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

https://reviews.llvm.org/D120201

Files:
  clang/include/clang/Driver/Driver.h
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/crash-report-crashfile.m
  clang/test/Driver/emit-reproducer.c
  clang/tools/driver/driver.cpp

Index: clang/tools/driver/driver.cpp
===
--- clang/tools/driver/driver.cpp
+++ clang/tools/driver/driver.cpp
@@ -482,32 +482,37 @@
   }
 
   std::unique_ptr C(TheDriver.BuildCompilation(Args));
+
+  Driver::ReproLevel ReproLevel = Driver::ReproLevel::OnCrash;
+  if (Arg *A = C->getArgs().getLastArg(options::OPT_gen_reproducer_eq)) {
+auto Level = llvm::StringSwitch>(A->getValue())
+ .Case("off", Driver::ReproLevel::Off)
+ .Case("crash", Driver::ReproLevel::OnCrash)
+ .Case("error", Driver::ReproLevel::OnError)
+ .Case("always", Driver::ReproLevel::Always)
+ .Default(None);
+if (!Level) {
+  llvm::errs() << "Unknown value for " << A->getSpelling() << ": '"
+   << A->getValue() << "'\n";
+  return 1;
+}
+ReproLevel = *Level;
+  }
+  if (!!::getenv("FORCE_CLANG_DIAGNOSTICS_CRASH"))
+ReproLevel = Driver::ReproLevel::Always;
+
   int Res = 1;
   bool IsCrash = false;
+  Driver::CommandStatus CommandStatus = Driver::CommandStatus::Ok;
+  // Pretend the first command failed if ReproStatus is Always.
+  const Command *FailingCommand = &*C->getJobs().begin();
   if (C && !C->containsError()) {
 SmallVector, 4> FailingCommands;
 Res = TheDriver.ExecuteCompilation(*C, FailingCommands);
 
-// Force a crash to test the diagnostics.
-if (TheDriver.GenReproducer) {
-  Diags.Report(diag::err_drv_force_crash)
-<< !::getenv("FORCE_CLANG_DIAGNOSTICS_CRASH");
-
-  // Pretend that every command failed.
-  FailingCommands.clear();
-  for (const auto &J : C->getJobs())
-if (const Command *C = dyn_cast(&J))
-  FailingCommands.push_back(std::make_pair(-1, C));
-
-  // Print the bug report message that would be printed if we did actually
-  // crash, but only if we're crashing due to FORCE_CLANG_DIAGNOSTICS_CRASH.
-  if (::getenv("FORCE_CLANG_DIAGNOSTICS_CRASH"))
-llvm::dbgs() << llvm::getBugReportMsg();
-}
-
 for (const auto &P : FailingCommands) {
   int CommandRes = P.first;
-  const Command *FailingCommand = P.second;
+  FailingCommand = P.second;
   if (!Res)
 Res = CommandRes;
 
@@ -526,13 +531,21 @@
   // https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap02.html
   IsCrash |= CommandRes > 128;
 #endif
-  if (IsCrash) {
-TheDriver.generateCompilationDiagnostics(*C, *FailingCommand);
+  CommandStatus =
+  IsCrash ? Driver::CommandStatus::Crash : Driver::CommandStatus::Error;
+  if (IsCrash)
 break;
-  }
 }
   }
 
+  // Print the bug report message that would be printed if we did actually
+  // crash, but only if we're crashing due to FORCE_CLANG_DIAGNOSTICS_CRASH.
+  if (::getenv("FORCE_CLANG_DIAGNOSTICS_CRASH"))
+llvm::dbgs() << llvm::getBugReportMsg();
+  if (TheDriver.maybeGenerateCompilationDiagnostics(CommandStatus, ReproLevel,
+*C, *FailingCommand))
+Res = 1;
+
   Diags.getClient()->finish();
 
   if (!UseNewCC1Process && IsCrash) {
Index: clang/test/Driver/emit-reproducer.c
===
--- /dev/null
+++ clang/test/Driver/emit-reproducer.c
@@ -0,0 +1,41 @@
+// RUN: rm -rf %t && mkdir %t
+
+// RUN: echo "%s -fcrash-diagnostics-dir=%t -fsyntax-only" > %t.rsp
+
+// RUN: not %clang -DFATAL @%t.rsp -gen-reproducer=off2>&1 | FileCheck %s --check-prefix=NOT
+// RUN: not %clang -DFATAL @%t.rsp -fno-crash-diagnostics 2>&1 | FileCheck %s --check-prefix=NOT
+// RUN: not %clang -DFATAL @%t.rsp2>&1 | FileCheck %s
+// RUN: not %clang -DFATAL @%t.rsp -gen-reproducer=crash  2>&1 | FileCheck %s
+// RUN: not %clang -DFATAL @%t.rsp -gen-reproducer=error  2>&1 | FileCheck %s
+// RUN: not %clang -DFATAL @%t.rsp -gen-reproducer=always 2>&1 | FileCheck %s
+// RUN: not %clang -DFATAL @%t.rsp -gen-reproducer2>&1 | FileCheck %s
+
+// RUN: not %clang -DERROR @%t.rsp -gen-reproducer=off2>&1 | FileCheck %s --check-prefix=NOT
+// RUN: not %clang -DERROR @%t.rsp -fno-crash-diagnostics 2>&1 | FileCheck %s --check-prefix=NOT
+// RUN: not %clang -DERROR @%t.rsp2>&1 | FileCheck %s --check-prefix=NOT
+// RUN: not %clang -DERROR @%t.rsp -gen-reproducer=crash  2>&1 | FileCheck %s --check-prefix=NOT
+// RUN: not %clang -DERROR @%t.rsp -gen-reproducer=error  2>&1 | FileCheck %s
+// RUN: not %clang -DERROR @%t.rsp -gen-reproducer=always

[clang] 7d76d60 - [Clang] Extend -gen-reproducer flag

[Alex Brachet via cfe-commits]

Author: Alex Brachet
Date: 2022-05-31T17:10:16Z
New Revision: 7d76d6095880f34914d85d876b260cc4a4ea640d

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

LOG: [Clang] Extend -gen-reproducer flag

`-gen-reproducer` causes crash reproduction to be emitted
even when clang didn't crash, and now can optionally take an
argument of never, on-crash (default), on-error and always.

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

Added: 
clang/test/Driver/emit-reproducer.c

Modified: 
clang/include/clang/Driver/Driver.h
clang/include/clang/Driver/Options.td
clang/lib/Driver/Driver.cpp
clang/test/Driver/crash-report-crashfile.m
clang/tools/driver/driver.cpp

Removed: 




diff  --git a/clang/include/clang/Driver/Driver.h 
b/clang/include/clang/Driver/Driver.h
index f0f294a669d98..67ff4dc2e01e8 100644
--- a/clang/include/clang/Driver/Driver.h
+++ b/clang/include/clang/Driver/Driver.h
@@ -12,6 +12,7 @@
 #include "clang/Basic/Diagnostic.h"
 #include "clang/Basic/LLVM.h"
 #include "clang/Driver/Action.h"
+#include "clang/Driver/DriverDiagnostic.h"
 #include "clang/Driver/InputInfo.h"
 #include "clang/Driver/Options.h"
 #include "clang/Driver/Phases.h"
@@ -276,11 +277,6 @@ class Driver {
   unsigned ProbePrecompiled : 1;
 
 public:
-  /// Force clang to emit reproducer for driver invocation. This is enabled
-  /// indirectly by setting FORCE_CLANG_DIAGNOSTICS_CRASH environment variable
-  /// or when using the -gen-reproducer driver flag.
-  unsigned GenReproducer : 1;
-
   // getFinalPhase - Determine which compilation mode we are in and record
   // which option we used to determine the final phase.
   // TODO: Much of what getFinalPhase returns are not actually true compiler
@@ -505,6 +501,35 @@ class Driver {
   StringRef AdditionalInformation = "",
   CompilationDiagnosticReport *GeneratedReport = nullptr);
 
+  enum class CommandStatus {
+Crash = 1,
+Error,
+Ok,
+  };
+
+  enum class ReproLevel {
+Off = 0,
+OnCrash = static_cast(CommandStatus::Crash),
+OnError = static_cast(CommandStatus::Error),
+Always = static_cast(CommandStatus::Ok),
+  };
+
+  bool maybeGenerateCompilationDiagnostics(
+  CommandStatus CS, ReproLevel Level, Compilation &C,
+  const Command &FailingCommand, StringRef AdditionalInformation = "",
+  CompilationDiagnosticReport *GeneratedReport = nullptr) {
+if (static_cast(CS) > static_cast(Level))
+  return false;
+if (CS != CommandStatus::Crash)
+  Diags.Report(diag::err_drv_force_crash)
+  << !::getenv("FORCE_CLANG_DIAGNOSTICS_CRASH");
+// Hack to ensure that diagnostic notes get emitted.
+Diags.setLastDiagnosticIgnored(false);
+generateCompilationDiagnostics(C, FailingCommand, AdditionalInformation,
+   GeneratedReport);
+return true;
+  }
+
   /// @}
   /// @name Helper Methods
   /// @{

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 0343e48c1a9d1..26d003b001a61 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -558,7 +558,10 @@ def arcmt_migrate_report_output : Separate<["-"], 
"arcmt-migrate-report-output">
 def arcmt_migrate_emit_arc_errors : Flag<["-"], "arcmt-migrate-emit-errors">,
   HelpText<"Emit ARC errors even if the migrator can fix them">, 
Flags<[CC1Option]>,
   MarshallingInfoFlag>;
+def gen_reproducer_eq: Joined<["-"], "gen-reproducer=">, 
Flags<[NoArgumentUnused, CoreOption]>,
+  HelpText<"Emit reproducer on (option: off, crash (default), error, always)">;
 def gen_reproducer: Flag<["-"], "gen-reproducer">, InternalDebugOpt,
+  Alias, AliasArgs<["always"]>,
   HelpText<"Auto-generates preprocessed source files and a reproduction 
script">;
 def gen_cdb_fragment_path: Separate<["-"], "gen-cdb-fragment-path">, 
InternalDebugOpt,
   HelpText<"Emit a compilation database fragment to the specified directory">;
@@ -1397,6 +1400,7 @@ def fexperimental_new_constant_interpreter : Flag<["-"], 
"fexperimental-new-cons
 def fconstexpr_backtrace_limit_EQ : Joined<["-"], 
"fconstexpr-backtrace-limit=">,
 Group;
 def fno_crash_diagnostics : Flag<["-"], "fno-crash-diagnostics">, 
Group, Flags<[NoArgumentUnused, CoreOption]>,
+  Alias, AliasArgs<["off"]>,
   HelpText<"Disable auto-generation of preprocessed source files and a script 
for reproduction during a clang crash">;
 def fcrash_diagnostics_dir : Joined<["-"], "fcrash-diagnostics-dir=">,
   Group, Flags<[NoArgumentUnused, CoreOption]>,

diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 94925568aec23..aaef2e1ded327 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -198,8 +198,7 @

[PATCH] D126681: [HIP] Fix static lib name on windows

[Artem Belevich via Phabricator via cfe-commits]

tra accepted this revision.
tra added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:1788
+for (auto Prefix : {"/libdevice/", "/"}) {
+  if (IsMSVC) {
+AOBFileNames.push_back(Twine(LPath + Prefix + Lib + ".lib").str());

style nit: no need for braces here
https://llvm.org/docs/CodingStandards.html#don-t-use-braces-on-simple-single-statement-bodies-of-if-else-loop-statements


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

https://reviews.llvm.org/D126681

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

[clang] 35a032e - [InstrProf] Stop exporting lprofDirMode

[Alex Brachet via cfe-commits]

Author: Alex Brachet
Date: 2022-05-31T17:13:00Z
New Revision: 35a032eaf429abd2b9785b2d989f5a42c89bc6a8

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

LOG: [InstrProf] Stop exporting lprofDirMode

This symbol should not be exposed and doesn't need to be.

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/Darwin.cpp
compiler-rt/lib/profile/InstrProfilingUtil.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Darwin.cpp 
b/clang/lib/Driver/ToolChains/Darwin.cpp
index b0d72c74dcb74..665a3894302ab 100644
--- a/clang/lib/Driver/ToolChains/Darwin.cpp
+++ b/clang/lib/Driver/ToolChains/Darwin.cpp
@@ -1349,7 +1349,6 @@ void Darwin::addProfileRTLibs(const ArgList &Args,
   addExportedSymbol(CmdArgs, "___llvm_profile_filename");
   addExportedSymbol(CmdArgs, "___llvm_profile_raw_version");
 }
-addExportedSymbol(CmdArgs, "_lprofDirMode");
   }
 
   // Align __llvm_prf_{cnts,data} sections to the maximum expected page

diff  --git a/compiler-rt/lib/profile/InstrProfilingUtil.c 
b/compiler-rt/lib/profile/InstrProfilingUtil.c
index cd179d03bc831..cd18cba3e268f 100644
--- a/compiler-rt/lib/profile/InstrProfilingUtil.c
+++ b/compiler-rt/lib/profile/InstrProfilingUtil.c
@@ -46,7 +46,7 @@
 #include "InstrProfiling.h"
 #include "InstrProfilingUtil.h"
 
-COMPILER_RT_WEAK unsigned lprofDirMode = 0755;
+COMPILER_RT_VISIBILITY unsigned lprofDirMode = 0755;
 
 COMPILER_RT_VISIBILITY
 void __llvm_profile_recursive_mkdir(char *path) {



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

[PATCH] D126548: [InstrProf] Stop exporting lprofDirMode

[Alex Brachet via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG35a032eaf429: [InstrProf] Stop exporting lprofDirMode 
(authored by abrachet).
Herald added subscribers: Sanitizers, cfe-commits, Enna1.
Herald added projects: clang, Sanitizers.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126548

Files:
  clang/lib/Driver/ToolChains/Darwin.cpp
  compiler-rt/lib/profile/InstrProfilingUtil.c


Index: compiler-rt/lib/profile/InstrProfilingUtil.c
===
--- compiler-rt/lib/profile/InstrProfilingUtil.c
+++ compiler-rt/lib/profile/InstrProfilingUtil.c
@@ -46,7 +46,7 @@
 #include "InstrProfiling.h"
 #include "InstrProfilingUtil.h"
 
-COMPILER_RT_WEAK unsigned lprofDirMode = 0755;
+COMPILER_RT_VISIBILITY unsigned lprofDirMode = 0755;
 
 COMPILER_RT_VISIBILITY
 void __llvm_profile_recursive_mkdir(char *path) {
Index: clang/lib/Driver/ToolChains/Darwin.cpp
===
--- clang/lib/Driver/ToolChains/Darwin.cpp
+++ clang/lib/Driver/ToolChains/Darwin.cpp
@@ -1349,7 +1349,6 @@
   addExportedSymbol(CmdArgs, "___llvm_profile_filename");
   addExportedSymbol(CmdArgs, "___llvm_profile_raw_version");
 }
-addExportedSymbol(CmdArgs, "_lprofDirMode");
   }
 
   // Align __llvm_prf_{cnts,data} sections to the maximum expected page


Index: compiler-rt/lib/profile/InstrProfilingUtil.c
===
--- compiler-rt/lib/profile/InstrProfilingUtil.c
+++ compiler-rt/lib/profile/InstrProfilingUtil.c
@@ -46,7 +46,7 @@
 #include "InstrProfiling.h"
 #include "InstrProfilingUtil.h"
 
-COMPILER_RT_WEAK unsigned lprofDirMode = 0755;
+COMPILER_RT_VISIBILITY unsigned lprofDirMode = 0755;
 
 COMPILER_RT_VISIBILITY
 void __llvm_profile_recursive_mkdir(char *path) {
Index: clang/lib/Driver/ToolChains/Darwin.cpp
===
--- clang/lib/Driver/ToolChains/Darwin.cpp
+++ clang/lib/Driver/ToolChains/Darwin.cpp
@@ -1349,7 +1349,6 @@
   addExportedSymbol(CmdArgs, "___llvm_profile_filename");
   addExportedSymbol(CmdArgs, "___llvm_profile_raw_version");
 }
-addExportedSymbol(CmdArgs, "_lprofDirMode");
   }
 
   // Align __llvm_prf_{cnts,data} sections to the maximum expected page
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D116638: [clang-format] Fix ignoring JavaScriptWrapImport when ColumnWidth: 0

[Stanisław Małolepszy via Phabricator via cfe-commits]

stasm added a comment.

In D116638#3547366 , @andmis wrote:

> In D116638#3545246 , @stasm wrote:
>
>> I'm still interested in seeing this fixed. Would it help if I rebased this 
>> change and addressed the outstanding review comments?
>
> Go for it! I don't plan to do any further work on this. (I'm the original 
> author of the patch.)

Thanks for letting me know! I'll see what I can do :)


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

https://reviews.llvm.org/D116638

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

[PATCH] D125723: [MSVC] Add support for MSVC pragma optimize

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

I think it's fine to implement this, but I wanted to share some of the 
motivation for the current state of things. In our experience, the majority of 
uses of pragma optimize were to work around MSVC compiler bugs. So, instead of 
honoring them, we felt it was best to ignore them with a warning 
(`-Wignored-pragma-optimize`). Of course, that warning is typically disabled in 
build systems of large projects, so our current behavior can still surprise 
users. Implementing the feature is probably the most predictable and least 
surprising thing Clang can do.

Something we can't easily support for either GCC or MSVC attribute is enabling 
optimizations for some functions in an -O0 build. Maybe it's now possible to 
set up a full pass pipeline after semantic analysis is complete, but it's not 
straightforward. You should consider what to do with that corner case.




Comment at: clang/lib/Parse/ParsePragma.cpp:3706
-  }
-  PP.Diag(StartLoc, diag::warn_pragma_optimize);
 }

This diagnostic is probably dead now, please remove it from the .td file.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125723

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

[clang] c4d9698 - [clang][Driver] Fix SIE builders

[Alex Brachet via cfe-commits]

Author: Alex Brachet
Date: 2022-05-31T17:26:18Z
New Revision: c4d9698f3c8db47ac7a0bee8bba6b9b8b91f7d58

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

LOG: [clang][Driver] Fix SIE builders

Added: 


Modified: 
clang/test/Driver/emit-reproducer.c

Removed: 




diff  --git a/clang/test/Driver/emit-reproducer.c 
b/clang/test/Driver/emit-reproducer.c
index 18846108459f..fa9d71463a66 100644
--- a/clang/test/Driver/emit-reproducer.c
+++ b/clang/test/Driver/emit-reproducer.c
@@ -29,8 +29,8 @@
 // RUN: not %clang -gen-reproducer=badvalue 2>&1 | FileCheck %s 
--check-prefix=BAD-VALUE
 // BAD-VALUE: Unknown value for -gen-reproducer=: 'badvalue'
 
-// CHECK:   note: diagnostic msg: {{.*}}emit-reproducer-{{.*}}.c
-// NOT-NOT: note: diagnostic msg: {{.*}}emit-reproducer-{{.*}}.c
+// CHECK:   note: diagnostic msg: {{.*}}emit-reproducer{{.*}}.c
+// NOT-NOT: note: diagnostic msg: {{.*}}emit-reproducer{{.*}}.c
 
 #ifdef FATAL
 #pragma clang __debug crash



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

[clang] a0ef52c - Fix windows build

[Alex Brachet via cfe-commits]

Author: Alex Brachet
Date: 2022-05-31T17:31:55Z
New Revision: a0ef52cc102504c4282dec7001664ee020396681

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

LOG: Fix windows build

Added: 


Modified: 
clang/test/Driver/emit-reproducer.c

Removed: 




diff  --git a/clang/test/Driver/emit-reproducer.c 
b/clang/test/Driver/emit-reproducer.c
index fa9d71463a66..b8d6841077c4 100644
--- a/clang/test/Driver/emit-reproducer.c
+++ b/clang/test/Driver/emit-reproducer.c
@@ -1,6 +1,6 @@
 // RUN: rm -rf %t && mkdir %t
 
-// RUN: echo "%s -fcrash-diagnostics-dir=%t -fsyntax-only" > %t.rsp
+// RUN: echo "%s -fcrash-diagnostics-dir=%t -fsyntax-only" | sed -e 
's/\\//g' > %t.rsp
 
 // RUN: not %clang -DFATAL @%t.rsp -gen-reproducer=off2>&1 | FileCheck %s 
--check-prefix=NOT
 // RUN: not %clang -DFATAL @%t.rsp -fno-crash-diagnostics 2>&1 | FileCheck %s 
--check-prefix=NOT
@@ -29,8 +29,8 @@
 // RUN: not %clang -gen-reproducer=badvalue 2>&1 | FileCheck %s 
--check-prefix=BAD-VALUE
 // BAD-VALUE: Unknown value for -gen-reproducer=: 'badvalue'
 
-// CHECK:   note: diagnostic msg: {{.*}}emit-reproducer{{.*}}.c
-// NOT-NOT: note: diagnostic msg: {{.*}}emit-reproducer{{.*}}.c
+// CHECK:   note: diagnostic msg: {{.*}}emit-reproducer-{{.*}}.c
+// NOT-NOT: note: diagnostic msg: {{.*}}emit-reproducer-{{.*}}.c
 
 #ifdef FATAL
 #pragma clang __debug crash



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

[PATCH] D120201: [Clang] Extend -gen-reproducer flag

[Douglas Yung via Phabricator via cfe-commits]

dyung added a comment.

The test you added seems to be failing on the PS4 Windows bot. A quick glance 
seems to suggest that you aren't properly escaping the path separators 
somewhere. Can you take a look and revert if you need time to investigate?

https://lab.llvm.org/buildbot/#/builders/216/builds/5164


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

https://reviews.llvm.org/D120201

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

[PATCH] D120201: [Clang] Extend -gen-reproducer flag

[Alex Brachet via Phabricator via cfe-commits]

abrachet added a comment.

In D120201#3547834 , @dyung wrote:

> The test you added seems to be failing on the PS4 Windows bot. A quick glance 
> seems to suggest that you aren't properly escaping the path separators 
> somewhere. Can you take a look and revert if you need time to investigate?
>
> https://lab.llvm.org/buildbot/#/builders/216/builds/5164

Should be fixed by 
https://github.com/llvm/llvm-project/commit/a0ef52cc102504c4282dec7001664ee020396681


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

https://reviews.llvm.org/D120201

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

[PATCH] D125742: Minor refactor of CanonicalIncludes::addSystemHeadersMapping.

[Paul Pluzhnikov via Phabricator via cfe-commits]

ppluzhnikov added a comment.

Ping?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125742

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

[PATCH] D120201: [Clang] Extend -gen-reproducer flag

[Douglas Yung via Phabricator via cfe-commits]

dyung added a comment.

In D120201#3547835 , @abrachet wrote:

> In D120201#3547834 , @dyung wrote:
>
>> The test you added seems to be failing on the PS4 Windows bot. A quick 
>> glance seems to suggest that you aren't properly escaping the path 
>> separators somewhere. Can you take a look and revert if you need time to 
>> investigate?
>>
>> https://lab.llvm.org/buildbot/#/builders/216/builds/5164
>
> Should be fixed by 
> https://github.com/llvm/llvm-project/commit/a0ef52cc102504c4282dec7001664ee020396681

Indeed it has, thanks for the quick action!


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

https://reviews.llvm.org/D120201

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

[PATCH] D125936: [Sema] Relax an assertion in BuildStmtExpr

[Akira Hatanaka via Phabricator via cfe-commits]

ahatanak added inline comments.



Comment at: clang/lib/Sema/SemaExpr.cpp:15746
 ExprResult Sema::BuildStmtExpr(SourceLocation LPLoc, Stmt *SubStmt,
SourceLocation RPLoc, unsigned TemplateDepth) {
   assert(SubStmt && isa(SubStmt) && "Invalid action 
invocation!");

rsmith wrote:
> Is it possible to pass a flag into here to indicate if we're really building 
> an `asm` statement? I don't think we want to remove the assert for a 
> user-written statement expression that happens to begin with an `asm` 
> statement.
> 
> It's ironic that we're building a statement expression to wrap an `asm` 
> statement in order to make sure that cleanups are handled properly, and the 
> `StmtExpr` is asserting because it doesn't expect to need to handle 
> cleanups...
Maybe we can add a flag to `StmtExpr` and set it in 
`Sema::MaybeCreateStmtWithCleanups` to distinguish `StmtExpr`s that are created 
for gnu statement expressions from those that aren't?

If we don't want to use `StmtExpr` for asm statements, maybe we have to create 
a new `Stmt` type just for that purpose as suggested in 
`Sema::MaybeCreateStmtWithCleanups`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125936

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

[PATCH] D75277: [WebAssembly] Remove restriction on main name mangling

[Sam Clegg via Phabricator via cfe-commits]

sbc100 updated this revision to Diff 433138.
sbc100 added a comment.
Herald added subscribers: llvm-commits, asb, hiraditya.
Herald added a project: LLVM.

- update


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75277

Files:
  clang/lib/AST/Mangle.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyFixFunctionBitcasts.cpp

Index: llvm/lib/Target/WebAssembly/WebAssemblyFixFunctionBitcasts.cpp
===
--- llvm/lib/Target/WebAssembly/WebAssemblyFixFunctionBitcasts.cpp
+++ llvm/lib/Target/WebAssembly/WebAssemblyFixFunctionBitcasts.cpp
@@ -214,22 +214,9 @@
   return Wrapper;
 }
 
-// Test whether a main function with type FuncTy should be rewritten to have
-// type MainTy.
-static bool shouldFixMainFunction(FunctionType *FuncTy, FunctionType *MainTy) {
-  // Only fix the main function if it's the standard zero-arg form. That way,
-  // the standard cases will work as expected, and users will see signature
-  // mismatches from the linker for non-standard cases.
-  return FuncTy->getReturnType() == MainTy->getReturnType() &&
- FuncTy->getNumParams() == 0 &&
- !FuncTy->isVarArg();
-}
-
 bool FixFunctionBitcasts::runOnModule(Module &M) {
   LLVM_DEBUG(dbgs() << "** Fix Function Bitcasts **\n");
 
-  Function *Main = nullptr;
-  CallInst *CallMain = nullptr;
   SmallVector, 0> Uses;
 
   // Collect all the places that need wrappers.
@@ -239,29 +226,6 @@
 if (F.getCallingConv() == CallingConv::Swift)
   continue;
 findUses(&F, F, Uses);
-
-// If we have a "main" function, and its type isn't
-// "int main(int argc, char *argv[])", create an artificial call with it
-// bitcasted to that type so that we generate a wrapper for it, so that
-// the C runtime can call it.
-if (F.getName() == "main") {
-  Main = &F;
-  LLVMContext &C = M.getContext();
-  Type *MainArgTys[] = {Type::getInt32Ty(C),
-PointerType::get(Type::getInt8PtrTy(C), 0)};
-  FunctionType *MainTy = FunctionType::get(Type::getInt32Ty(C), MainArgTys,
-   /*isVarArg=*/false);
-  if (shouldFixMainFunction(F.getFunctionType(), MainTy)) {
-LLVM_DEBUG(dbgs() << "Found `main` function with incorrect type: "
-  << *F.getFunctionType() << "\n");
-Value *Args[] = {UndefValue::get(MainArgTys[0]),
- UndefValue::get(MainArgTys[1])};
-Value *Casted =
-ConstantExpr::getBitCast(Main, PointerType::get(MainTy, 0));
-CallMain = CallInst::Create(MainTy, Casted, Args, "call_main");
-Uses.push_back(std::make_pair(CallMain, &F));
-  }
-}
   }
 
   DenseMap, Function *> Wrappers;
@@ -282,25 +246,5 @@
 CB->setCalledOperand(Wrapper);
   }
 
-  // If we created a wrapper for main, rename the wrapper so that it's the
-  // one that gets called from startup.
-  if (CallMain) {
-Main->setName("__original_main");
-auto *MainWrapper =
-cast(CallMain->getCalledOperand()->stripPointerCasts());
-delete CallMain;
-if (Main->isDeclaration()) {
-  // The wrapper is not needed in this case as we don't need to export
-  // it to anyone else.
-  MainWrapper->eraseFromParent();
-} else {
-  // Otherwise give the wrapper the same linkage as the original main
-  // function, so that it can be called from the same places.
-  MainWrapper->setName("main");
-  MainWrapper->setLinkage(Main->getLinkage());
-  MainWrapper->setVisibility(Main->getVisibility());
-}
-  }
-
   return true;
 }
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -555,10 +555,8 @@
 CodeGenFunction(*this).EmitCfiCheckStub();
   }
   emitAtAvailableLinkGuard();
-  if (Context.getTargetInfo().getTriple().isWasm() &&
-  !Context.getTargetInfo().getTriple().isOSEmscripten()) {
+  if (Context.getTargetInfo().getTriple().isWasm())
 EmitMainVoidAlias();
-  }
 
   if (getTriple().isAMDGPU()) {
 // Emit reference of __amdgpu_device_library_preserve_asan_functions to
@@ -6357,8 +6355,10 @@
   // new-style no-argument main is in used.
   if (llvm::Function *F = getModule().getFunction("main")) {
 if (!F->isDeclaration() && F->arg_size() == 0 && !F->isVarArg() &&
-F->getReturnType()->isIntegerTy(Context.getTargetInfo().getIntWidth()))
-  addUsedGlobal(llvm::GlobalAlias::create("__main_void", F));
+F->getReturnType()->isIntegerTy(Context.getTargetInfo().getIntWidth())) {
+  auto *GA = llvm::GlobalAlias::create("__main_void", F);
+  GA->setVisibility(llvm::GlobalValue::DefaultVisibility);
+}
   }
 }
 
Index: clang/lib/AST/Mangle.cpp
=

[PATCH] D75277: [WebAssembly] Remove restriction on main name mangling

[Sam Clegg via Phabricator via cfe-commits]

sbc100 added a comment.

Currently waiting on https://github.com/emscripten-core/emscripten/pull/17099 
to land.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75277

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

[PATCH] D126479: [Clang] Allow 'Complex float __attribute__((mode(HC)))'

[Tom Honermann via Phabricator via cfe-commits]

tahonermann added inline comments.



Comment at: clang/lib/Basic/TargetInfo.cpp:287-288
  FloatModeKind ExplicitType) const 
{
+  if (getHalfWidth() == BitWidth)
+return FloatModeKind::Half;
   if (getFloatWidth() == BitWidth)

aaron.ballman wrote:
> I *think* this is correct, but it's a bit worrying because we have multiple 
> floating-point types with the same width. e.g., `HalfTy` and `BFloat16Ty`, so 
> I am a bit uncomfortable with the `getRealTypeByWidth()` interface in general 
> once we go down this route. `getRealTypeForBitwidth()` will have similar 
> issues.
I think this is probably ok. If support for the other 16-bit types is needed in 
the future, then new mode attribute arguments will have to be specified as is 
done for the 128-bit types with "K", "T", and "I".


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126479

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

[PATCH] D126479: [Clang] Allow 'Complex float __attribute__((mode(HC)))'

[Tom Honermann via Phabricator via cfe-commits]

tahonermann added inline comments.



Comment at: clang/include/clang/Basic/TargetInfo.h:60
+  Ibm128,
+  Half
 };

The existing enumerators were ordered according to precision. Consider moving 
`Half` to before `Float` if doing so doesn't cause any problems (I would hope 
there is no dependence on the assigned enumerator values anywhere; if there is, 
then it would be helpful to add a comment about that here).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126479

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

[PATCH] D126642: [Clang] NFCI: Add a new bit HasExtraBitfields to FunctionType.

[Sander de Smalen via Phabricator via cfe-commits]

sdesmalen updated this revision to Diff 433140.
sdesmalen marked 4 inline comments as done.
sdesmalen retitled this revision from "[Clang] NFCI: Repurpose 
HasExtParameterInfos for HasExtraBitfields" to "[Clang] NFCI: Add a new bit 
HasExtraBitfields to FunctionType.".
sdesmalen edited the summary of this revision.
sdesmalen added a comment.

Instead of repurposing the HasExtParameterInfos bit, added an extra field for 
HasExtraBitfields.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126642

Files:
  clang/include/clang/AST/Type.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/Type.cpp

Index: clang/lib/AST/Type.cpp
===
--- clang/lib/AST/Type.cpp
+++ clang/lib/AST/Type.cpp
@@ -3213,12 +3213,15 @@
   FunctionTypeBits.Variadic = epi.Variadic;
   FunctionTypeBits.HasTrailingReturn = epi.HasTrailingReturn;
 
-  // Fill in the extra trailing bitfields if present.
-  if (hasExtraBitfields(epi.ExceptionSpec.Type)) {
+  if (epi.requiresFunctionProtoTypeExtraBitfields()) {
+FunctionTypeBits.HasExtraBitfields = true;
 auto &ExtraBits = *getTrailingObjects();
-ExtraBits.NumExceptionType = epi.ExceptionSpec.Exceptions.size();
+ExtraBits = FunctionTypeExtraBitfields();
+  } else {
+FunctionTypeBits.HasExtraBitfields = false;
   }
 
+
   // Fill in the trailing argument array.
   auto *argSlot = getTrailingObjects();
   for (unsigned i = 0; i != getNumParams(); ++i) {
@@ -3229,6 +3232,9 @@
 
   // Fill in the exception type array if present.
   if (getExceptionSpecType() == EST_Dynamic) {
+auto &ExtraBits = *getTrailingObjects();
+ExtraBits.NumExceptionType = epi.ExceptionSpec.Exceptions.size();
+
 assert(hasExtraBitfields() && "missing trailing extra bitfields!");
 auto *exnSlot =
 reinterpret_cast(getTrailingObjects());
Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -4451,8 +4451,7 @@
   QualType, SourceLocation, FunctionType::FunctionTypeExtraBitfields,
   FunctionType::ExceptionType, Expr *, FunctionDecl *,
   FunctionProtoType::ExtParameterInfo, Qualifiers>(
-  NumArgs, EPI.Variadic,
-  FunctionProtoType::hasExtraBitfields(EPI.ExceptionSpec.Type),
+  NumArgs, EPI.Variadic, EPI.requiresFunctionProtoTypeExtraBitfields(),
   ESH.NumExceptionType, ESH.NumExprPtr, ESH.NumFunctionDeclPtr,
   EPI.ExtParameterInfos ? NumArgs : 0,
   EPI.TypeQuals.hasNonFastQualifiers() ? 1 : 0);
Index: clang/include/clang/AST/Type.h
===
--- clang/include/clang/AST/Type.h
+++ clang/include/clang/AST/Type.h
@@ -1624,6 +1624,9 @@
 /// Whether this function has extended parameter information.
 unsigned HasExtParameterInfos : 1;
 
+/// Whether this function has extra bitfields for the prototype.
+unsigned HasExtraBitfields : 1;
+
 /// Whether the function is variadic.
 unsigned Variadic : 1;
 
@@ -3798,13 +3801,14 @@
 
   /// A simple holder for various uncommon bits which do not fit in
   /// FunctionTypeBitfields. Aligned to alignof(void *) to maintain the
-  /// alignment of subsequent objects in TrailingObjects. You must update
-  /// hasExtraBitfields in FunctionProtoType after adding extra data here.
+  /// alignment of subsequent objects in TrailingObjects.
   struct alignas(void *) FunctionTypeExtraBitfields {
 /// The number of types in the exception specification.
 /// A whole unsigned is not needed here and according to
 /// [implimits] 8 bits would be enough here.
 unsigned NumExceptionType;
+
+FunctionTypeExtraBitfields() : NumExceptionType(0) {}
   };
 
 protected:
@@ -3998,6 +4002,10 @@
   Result.ExceptionSpec = ESI;
   return Result;
 }
+
+bool requiresFunctionProtoTypeExtraBitfields() const {
+  return ExceptionSpec.Type == EST_Dynamic;
+}
   };
 
 private:
@@ -4088,16 +4096,13 @@
 return getExceptionSpecSize(getExceptionSpecType(), getNumExceptions());
   }
 
-  /// Whether the trailing FunctionTypeExtraBitfields is present.
-  static bool hasExtraBitfields(ExceptionSpecificationType EST) {
-// If the exception spec type is EST_Dynamic then we have > 0 exception
-// types and the exact number is stored in FunctionTypeExtraBitfields.
-return EST == EST_Dynamic;
-  }
-
   /// Whether the trailing FunctionTypeExtraBitfields is present.
   bool hasExtraBitfields() const {
-return hasExtraBitfields(getExceptionSpecType());
+assert((getExceptionSpecType() != EST_Dynamic ||
+FunctionTypeBits.HasExtraBitfields) &&
+   "ExtraBitfields are required for given ExceptionSpecType");
+return FunctionTypeBits.HasExtraBitfields;
+
   }
 
   bool hasExtQualifiers() const {

[PATCH] D126642: [Clang] NFCI: Add a new bit HasExtraBitfields to FunctionType.

[Sander de Smalen via Phabricator via cfe-commits]

sdesmalen added a comment.

In D126642#3547526 , @erichkeane 
wrote:

> Right, yeah.  One thing to consider: `ExtInfo` was 'first', and so it got to 
> keep the 'in bitfield bits'. However, much of what is in there is, IMO, not 
> something that is used often enough to be worth having in there.  Of the bits 
> being used there, I think 'NoReturn' is the only one used with any regularity 
> (other than perhaps 'this call' in Windows-32-bit machines).  I wonder if we 
> should consider moving as much of that as possible over.

That sounds sensible. Some of the fields there are also valid in 
FunctionNoProtoType though, and I don't believe I saw an equivalent to 
ExtProtoInfo for FunctionNoProtoType, is that because it's uncommon enough that 
it only requires changing in a handful of places? I'm not too familiar with 
Clang code, so I didn't look to deep into this.

>> so perhaps incorrectly I assumed I couldn't add any new bits to FunctionType 
>> and thought I'd repurpose this one bit, because it's only ever used for 
>> FunctionProtoType (never for FunctionNoProtoType).
>>
>> But I now realised I can just add an extra bit, so that we can leave this 
>> bit as-is. What do you think?
>
> I think there is probably value to that, yes.

Great, thanks, I've updated that now!




Comment at: clang/include/clang/AST/Type.h:3801-3802
   /// FunctionTypeBitfields. Aligned to alignof(void *) to maintain the
   /// alignment of subsequent objects in TrailingObjects. You must update
   /// hasExtraBitfields in FunctionProtoType after adding extra data here.
   struct alignas(void *) FunctionTypeExtraBitfields {

aaron.ballman wrote:
> It looks like this comment is now out of date.
Good spot, thanks!



Comment at: clang/include/clang/AST/Type.h:4103
   bool hasExtraBitfields() const {
-return hasExtraBitfields(getExceptionSpecType());
+assert((getExceptionSpecType() != EST_Dynamic ||
+FunctionTypeBits.HasExtraBitfields) &&

sdesmalen wrote:
> erichkeane wrote:
> > Why is asking if we DO have extra bitfields an assert here?  I would think 
> > this is a valid question...
> > 
> > Why would 'dynamic' and extra-bitfields be exclusive here?
> This assert is merely confirming that HasExtraBitfields **must** be true if 
> the ExceptionSpecType is `EST_Dynamic`, because that was the old behaviour 
> (and I wanted to avoid introducing failures if some code still assumed that 
> hasExtraBitfields == true, but for some reason HasExtraBitfields had not yet 
> been set to `true`).
I've marked the comment as done hoping that my above explanation clarified it, 
but let me know if you're not happy with it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126642

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

[PATCH] D126559: [MSVC] Fix pragma alloc_text failing for C files

[Stephen Long via Phabricator via cfe-commits]

steplong added a comment.

It looks like MSVC also accepts

  // foo.c
  static void foo();
  #pragma alloc_text("hello", foo)
  void foo() {}

and

  // foo.cpp
  extern "C" {
  static void foo();
  #pragma alloc_text("hello", foo)
  void foo() {}
  }

Do you know of a way I can check whether a function is coming from c or c++? 
`isExternC()` returns false for the static case


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126559

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

[PATCH] D125585: [HLSL][clang][Driver] Parse target profile early to update Driver::TargetTriple.

[Xiang Li via Phabricator via cfe-commits]

python3kgae updated this revision to Diff 433143.
python3kgae added a comment.

Add check for no -T option.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125585

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/HLSL.cpp
  clang/lib/Driver/ToolChains/HLSL.h
  clang/test/Driver/dxc_fcgl.hlsl
  clang/unittests/Driver/ToolChainTest.cpp

Index: clang/unittests/Driver/ToolChainTest.cpp
===
--- clang/unittests/Driver/ToolChainTest.cpp
+++ clang/unittests/Driver/ToolChainTest.cpp
@@ -387,6 +387,28 @@
   std::vector> Errors;
 };
 
+static void validateTargetProfile(StringRef TargetProfile,
+  StringRef ExpectTriple, Driver &TheDriver,
+  DiagnosticsEngine &Diags) {
+  EXPECT_TRUE(TheDriver.BuildCompilation(
+  {"clang", "--driver-mode=dxc", TargetProfile.data(), "foo.hlsl"}));
+  EXPECT_STREQ(TheDriver.getTargetTriple().c_str(), ExpectTriple.data());
+  EXPECT_EQ(Diags.getNumErrors(), 0u);
+}
+
+static void validateTargetProfile(StringRef TargetProfile,
+  StringRef ExpectError, Driver &TheDriver,
+  DiagnosticsEngine &Diags,
+  SimpleDiagnosticConsumer *DiagConsumer,
+  unsigned NumOfErrors) {
+  EXPECT_TRUE(TheDriver.BuildCompilation(
+  {"clang", "--driver-mode=dxc", TargetProfile.data(), "foo.hlsl"}));
+  EXPECT_EQ(Diags.getNumErrors(), NumOfErrors);
+  EXPECT_STREQ(DiagConsumer->Errors.back().c_str(), ExpectError.data());
+  Diags.Clear();
+  DiagConsumer->clear();
+}
+
 TEST(DxcModeTest, TargetProfileValidation) {
   IntrusiveRefCntPtr DiagID(new DiagnosticIDs());
 
@@ -400,111 +422,40 @@
   IntrusiveRefCntPtr DiagOpts = new DiagnosticOptions();
   DiagnosticsEngine Diags(DiagID, &*DiagOpts, DiagConsumer);
   Driver TheDriver("/bin/clang", "", Diags, "", InMemoryFileSystem);
-  std::unique_ptr C(
-  TheDriver.BuildCompilation({"clang", "--driver-mode=dxc", "foo.hlsl"}));
-  EXPECT_TRUE(C);
-  EXPECT_TRUE(!C->containsError());
-
-  auto &TC = C->getDefaultToolChain();
-  bool ContainsError = false;
-  auto Args = TheDriver.ParseArgStrings({"-Tvs_6_0"}, false, ContainsError);
-  EXPECT_FALSE(ContainsError);
-  auto Triple = TC.ComputeEffectiveClangTriple(Args);
-  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.0-vertex");
-  EXPECT_EQ(Diags.getNumErrors(), 0u);
-
-  Args = TheDriver.ParseArgStrings({"-Ths_6_1"}, false, ContainsError);
-  EXPECT_FALSE(ContainsError);
-  Triple = TC.ComputeEffectiveClangTriple(Args);
-  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.1-hull");
-  EXPECT_EQ(Diags.getNumErrors(), 0u);
-
-  Args = TheDriver.ParseArgStrings({"-Tds_6_2"}, false, ContainsError);
-  EXPECT_FALSE(ContainsError);
-  Triple = TC.ComputeEffectiveClangTriple(Args);
-  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.2-domain");
-  EXPECT_EQ(Diags.getNumErrors(), 0u);
-
-  Args = TheDriver.ParseArgStrings({"-Tds_6_2"}, false, ContainsError);
-  EXPECT_FALSE(ContainsError);
-  Triple = TC.ComputeEffectiveClangTriple(Args);
-  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.2-domain");
-  EXPECT_EQ(Diags.getNumErrors(), 0u);
-
-  Args = TheDriver.ParseArgStrings({"-Tgs_6_3"}, false, ContainsError);
-  EXPECT_FALSE(ContainsError);
-  Triple = TC.ComputeEffectiveClangTriple(Args);
-  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.3-geometry");
-  EXPECT_EQ(Diags.getNumErrors(), 0u);
-
-  Args = TheDriver.ParseArgStrings({"-Tps_6_4"}, false, ContainsError);
-  EXPECT_FALSE(ContainsError);
-  Triple = TC.ComputeEffectiveClangTriple(Args);
-  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.4-pixel");
-  EXPECT_EQ(Diags.getNumErrors(), 0u);
-
-  Args = TheDriver.ParseArgStrings({"-Tcs_6_5"}, false, ContainsError);
-  EXPECT_FALSE(ContainsError);
-  Triple = TC.ComputeEffectiveClangTriple(Args);
-  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.5-compute");
-  EXPECT_EQ(Diags.getNumErrors(), 0u);
-
-  Args = TheDriver.ParseArgStrings({"-Tms_6_6"}, false, ContainsError);
-  EXPECT_FALSE(ContainsError);
-  Triple = TC.ComputeEffectiveClangTriple(Args);
-  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.6-mesh");
-  EXPECT_EQ(Diags.getNumErrors(), 0u);
 
-  Args = TheDriver.ParseArgStrings({"-Tas_6_7"}, false, ContainsError);
-  EXPECT_FALSE(ContainsError);
-  Triple = TC.ComputeEffectiveClangTriple(Args);
-  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.7-amplification");
-  EXPECT_EQ(Diags.getNumErrors(), 0u);
-
-  Args = TheDriver.ParseArgStrings({"-Tlib_6_x"}, false, ContainsError);
-  EXPECT_FALSE(ContainsError);
-  Triple = TC.ComputeEffectiveClangTriple(Args);
-  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.15-library");
-  EXPECT_EQ(Diags.getNumErrors(), 0u);
+  validateTargetP

[PATCH] D126642: [Clang] NFCI: Add a new bit HasExtraBitfields to FunctionType.

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

In D126642#3547905 , @sdesmalen wrote:

> In D126642#3547526 , @erichkeane 
> wrote:
>
>> Right, yeah.  One thing to consider: `ExtInfo` was 'first', and so it got to 
>> keep the 'in bitfield bits'. However, much of what is in there is, IMO, not 
>> something that is used often enough to be worth having in there.  Of the 
>> bits being used there, I think 'NoReturn' is the only one used with any 
>> regularity (other than perhaps 'this call' in Windows-32-bit machines).  I 
>> wonder if we should consider moving as much of that as possible over.
>
> That sounds sensible. Some of the fields there are also valid in 
> FunctionNoProtoType though, and I don't believe I saw an equivalent to 
> ExtProtoInfo for FunctionNoProtoType, is that because it's uncommon enough 
> that it only requires changing in a handful of places? I'm not too familiar 
> with Clang code, so I didn't look to deep into this.

Ah, hrmph, yeah, those have to be available anywhere that a function type is 
defined, since they are part of the no-prototype type of the function.  So we'd 
likely need to extract that at the "FunctionType" level, and put it into 
trailing storage in BOTH places (that is, FunctionNoProtoType would have 
trailing storage for it if necessary, and FunctionProtoType would as well).  
ExtProtoInfo doesn't exist for FunctionNoProtoType because it is 
C++/parameter-specific stuff (prototypeless function types aren't permitted in 
C++).

>>> so perhaps incorrectly I assumed I couldn't add any new bits to 
>>> FunctionType and thought I'd repurpose this one bit, because it's only ever 
>>> used for FunctionProtoType (never for FunctionNoProtoType).
>>>
>>> But I now realised I can just add an extra bit, so that we can leave this 
>>> bit as-is. What do you think?
>>
>> I think there is probably value to that, yes.
>
> Great, thanks, I've updated that now!




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126642

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

[clang] 7689c7f - Create specialization of -Wgnu-statement-expression for expressions found in macros.

[Michael Wyman via cfe-commits]

Author: Michael Wyman
Date: 2022-05-31T11:13:08-07:00
New Revision: 7689c7fc9e08cc430daca3714bcffdd00fd538bd

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

LOG: Create specialization of -Wgnu-statement-expression for expressions found 
in macros.

-Wgnu-statement-expression currently warns for both direct source uses of 
statement expressions but also macro expansions; since they may be used by 
macros to avoid multiple evaluation of macro arguments, engineers might want to 
suppress warnings when statement expressions are expanded from macros but see 
them if introduced directly in source code.

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

Added: 


Modified: 
clang/include/clang/Basic/DiagnosticGroups.td
clang/include/clang/Basic/DiagnosticParseKinds.td
clang/lib/Parse/ParseExpr.cpp
clang/test/Sema/gnu-flags.c

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticGroups.td 
b/clang/include/clang/Basic/DiagnosticGroups.td
index a7c34038ba3f..81ab2e494976 100644
--- a/clang/include/clang/Basic/DiagnosticGroups.td
+++ b/clang/include/clang/Basic/DiagnosticGroups.td
@@ -611,7 +611,12 @@ def StaticInInline : DiagGroup<"static-in-inline">;
 def StaticLocalInInline : DiagGroup<"static-local-in-inline">;
 def GNUStaticFloatInit : DiagGroup<"gnu-static-float-init">;
 def StaticFloatInit : DiagGroup<"static-float-init", [GNUStaticFloatInit]>;
-def GNUStatementExpression : DiagGroup<"gnu-statement-expression">;
+// Allow 
diff erentiation between GNU statement expressions in a macro versus
+// written directly in source.
+def GNUStatementExpressionFromMacroExpansion :
+  DiagGroup<"gnu-statement-expression-from-macro-expansion">;
+def GNUStatementExpression : DiagGroup<"gnu-statement-expression",
+   
[GNUStatementExpressionFromMacroExpansion]>;
 def StringConcatation : DiagGroup<"string-concatenation">;
 def StringCompare : DiagGroup<"string-compare">;
 def StringPlusInt : DiagGroup<"string-plus-int">;

diff  --git a/clang/include/clang/Basic/DiagnosticParseKinds.td 
b/clang/include/clang/Basic/DiagnosticParseKinds.td
index 74930a4690d7..dd6bba720ce2 100644
--- a/clang/include/clang/Basic/DiagnosticParseKinds.td
+++ b/clang/include/clang/Basic/DiagnosticParseKinds.td
@@ -174,6 +174,9 @@ def err_stmtexpr_file_scope : Error<
   "statement expression not allowed at file scope">;
 def ext_gnu_statement_expr : Extension<
   "use of GNU statement expression extension">, 
InGroup;
+def ext_gnu_statement_expr_macro : Extension<
+  "use of GNU statement expression extension from macro expansion">,
+  InGroup;
 def ext_gnu_conditional_expr : Extension<
   "use of GNU ?: conditional expression extension, omitting middle operand">, 
InGroup;
 def ext_gnu_empty_initializer : Extension<

diff  --git a/clang/lib/Parse/ParseExpr.cpp b/clang/lib/Parse/ParseExpr.cpp
index 54ba115a65f9..1002a0e11c0f 100644
--- a/clang/lib/Parse/ParseExpr.cpp
+++ b/clang/lib/Parse/ParseExpr.cpp
@@ -2870,7 +2870,8 @@ Parser::ParseParenExpression(ParenParseOption &ExprType, 
bool stopIfCastExpr,
   // None of these cases should fall through with an invalid Result
   // unless they've already reported an error.
   if (ExprType >= CompoundStmt && Tok.is(tok::l_brace)) {
-Diag(Tok, diag::ext_gnu_statement_expr);
+Diag(Tok, OpenLoc.isMacroID() ? diag::ext_gnu_statement_expr_macro
+  : diag::ext_gnu_statement_expr);
 
 checkCompoundToken(OpenLoc, tok::l_paren, CompoundToken::StmtExprBegin);
 

diff  --git a/clang/test/Sema/gnu-flags.c b/clang/test/Sema/gnu-flags.c
index b454549ba945..8389cb6055bc 100644
--- a/clang/test/Sema/gnu-flags.c
+++ b/clang/test/Sema/gnu-flags.c
@@ -1,5 +1,5 @@
 // RUN: %clang_cc1 -fsyntax-only -verify %s -DNONE -Wno-gnu
-// RUN: %clang_cc1 -fsyntax-only -verify %s -DALL -Wgnu 
+// RUN: %clang_cc1 -fsyntax-only -verify %s -DALL -Wgnu
 // RUN: %clang_cc1 -fsyntax-only -verify %s -DALL -Wno-gnu \
 // RUN:   -Wgnu-alignof-expression -Wgnu-case-range -Wgnu-complex-integer 
-Wgnu-conditional-omitted-operand \
 // RUN:   -Wgnu-empty-initializer -Wgnu-label-as-value 
-Wgnu-statement-expression \
@@ -20,6 +20,7 @@
 // %clang_cc1 -fsyntax-only -verify %s -DEMPTYINIT -Wno-gnu 
-Wgnu-empty-initializer
 // %clang_cc1 -fsyntax-only -verify %s -DLABELVALUE -Wno-gnu 
-Wgnu-label-as-value
 // %clang_cc1 -fsyntax-only -verify %s -DSTATEMENTEXP -Wno-gnu 
-Wgnu-statement-expression
+// %clang_cc1 -fsyntax-only -verify %s -DSTATEMENTEXPMACRO -Wno-gnu 
-Wgnu-statement-expression-from-macro-expansion
 // %clang_cc1 -fsyntax-only -verify %s -DCOMPOUNDLITERALINITIALIZER -Wno-gnu 
-Wgnu-compound-literal-initializer
 // %clang_cc1 -fsyntax-only -verify %s -DFLEXIBLEARRAYINITIALIZER -Wno-gnu 
-Wgnu-flexible-array-i

[PATCH] D126522: Create specialization of `-Wgnu-statement-expression` for expressions found in macros.

[Michael Wyman via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG7689c7fc9e08: Create specialization of 
-Wgnu-statement-expression for expressions found in… (authored by mwyman).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126522

Files:
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/lib/Parse/ParseExpr.cpp
  clang/test/Sema/gnu-flags.c


Index: clang/test/Sema/gnu-flags.c
===
--- clang/test/Sema/gnu-flags.c
+++ clang/test/Sema/gnu-flags.c
@@ -1,5 +1,5 @@
 // RUN: %clang_cc1 -fsyntax-only -verify %s -DNONE -Wno-gnu
-// RUN: %clang_cc1 -fsyntax-only -verify %s -DALL -Wgnu 
+// RUN: %clang_cc1 -fsyntax-only -verify %s -DALL -Wgnu
 // RUN: %clang_cc1 -fsyntax-only -verify %s -DALL -Wno-gnu \
 // RUN:   -Wgnu-alignof-expression -Wgnu-case-range -Wgnu-complex-integer 
-Wgnu-conditional-omitted-operand \
 // RUN:   -Wgnu-empty-initializer -Wgnu-label-as-value 
-Wgnu-statement-expression \
@@ -20,6 +20,7 @@
 // %clang_cc1 -fsyntax-only -verify %s -DEMPTYINIT -Wno-gnu 
-Wgnu-empty-initializer
 // %clang_cc1 -fsyntax-only -verify %s -DLABELVALUE -Wno-gnu 
-Wgnu-label-as-value
 // %clang_cc1 -fsyntax-only -verify %s -DSTATEMENTEXP -Wno-gnu 
-Wgnu-statement-expression
+// %clang_cc1 -fsyntax-only -verify %s -DSTATEMENTEXPMACRO -Wno-gnu 
-Wgnu-statement-expression-from-macro-expansion
 // %clang_cc1 -fsyntax-only -verify %s -DCOMPOUNDLITERALINITIALIZER -Wno-gnu 
-Wgnu-compound-literal-initializer
 // %clang_cc1 -fsyntax-only -verify %s -DFLEXIBLEARRAYINITIALIZER -Wno-gnu 
-Wgnu-flexible-array-initializer
 // %clang_cc1 -fsyntax-only -verify %s -DREDECLAREDENUM -Wno-gnu 
-Wgnu-redeclared-enum
@@ -95,6 +96,14 @@
int a = ({ 1; });
 }
 
+#if ALL || STATEMENTEXP || STATEMENTEXPMACRO
+// expected-warning@+5 {{use of GNU statement expression extension from macro 
expansion}}
+#endif
+
+#define STMT_EXPR_MACRO(a) ({ (a); })
+void statementexprmacro(void) {
+  int a = STMT_EXPR_MACRO(1);
+}
 
 #if ALL || COMPOUNDLITERALINITIALIZER
 // expected-warning@+4 {{initialization of an array of type 'int[5]' from a 
compound literal of type 'int[5]' is a GNU extension}}
Index: clang/lib/Parse/ParseExpr.cpp
===
--- clang/lib/Parse/ParseExpr.cpp
+++ clang/lib/Parse/ParseExpr.cpp
@@ -2870,7 +2870,8 @@
   // None of these cases should fall through with an invalid Result
   // unless they've already reported an error.
   if (ExprType >= CompoundStmt && Tok.is(tok::l_brace)) {
-Diag(Tok, diag::ext_gnu_statement_expr);
+Diag(Tok, OpenLoc.isMacroID() ? diag::ext_gnu_statement_expr_macro
+  : diag::ext_gnu_statement_expr);
 
 checkCompoundToken(OpenLoc, tok::l_paren, CompoundToken::StmtExprBegin);
 
Index: clang/include/clang/Basic/DiagnosticParseKinds.td
===
--- clang/include/clang/Basic/DiagnosticParseKinds.td
+++ clang/include/clang/Basic/DiagnosticParseKinds.td
@@ -174,6 +174,9 @@
   "statement expression not allowed at file scope">;
 def ext_gnu_statement_expr : Extension<
   "use of GNU statement expression extension">, 
InGroup;
+def ext_gnu_statement_expr_macro : Extension<
+  "use of GNU statement expression extension from macro expansion">,
+  InGroup;
 def ext_gnu_conditional_expr : Extension<
   "use of GNU ?: conditional expression extension, omitting middle operand">, 
InGroup;
 def ext_gnu_empty_initializer : Extension<
Index: clang/include/clang/Basic/DiagnosticGroups.td
===
--- clang/include/clang/Basic/DiagnosticGroups.td
+++ clang/include/clang/Basic/DiagnosticGroups.td
@@ -611,7 +611,12 @@
 def StaticLocalInInline : DiagGroup<"static-local-in-inline">;
 def GNUStaticFloatInit : DiagGroup<"gnu-static-float-init">;
 def StaticFloatInit : DiagGroup<"static-float-init", [GNUStaticFloatInit]>;
-def GNUStatementExpression : DiagGroup<"gnu-statement-expression">;
+// Allow differentiation between GNU statement expressions in a macro versus
+// written directly in source.
+def GNUStatementExpressionFromMacroExpansion :
+  DiagGroup<"gnu-statement-expression-from-macro-expansion">;
+def GNUStatementExpression : DiagGroup<"gnu-statement-expression",
+   
[GNUStatementExpressionFromMacroExpansion]>;
 def StringConcatation : DiagGroup<"string-concatenation">;
 def StringCompare : DiagGroup<"string-compare">;
 def StringPlusInt : DiagGroup<"string-plus-int">;


Index: clang/test/Sema/gnu-flags.c
===
--- clang/test/Sema/gnu-flags.c
+++ clang/test/Sema/gnu-flags.c
@@ -1,5 +1,5 @@
 // RUN: %clang_cc1 -fsyntax-only -verify %s -DNONE -Wno-gnu
-// RUN: %clang_cc1 -fsy

[PATCH] D126642: [Clang] NFCI: Add a new bit HasExtraBitfields to FunctionType.

[Erich Keane via Phabricator via cfe-commits]

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

I think I'm Ok with this as a 1st step for the cleanup.  I think we should 
probably evaluate what amount of work is necessary to extract the ExtInfo out 
into trailing storage, depending on whether it saves us room in the 
FunctionProtoType and FunctionNoProtoType types.




Comment at: clang/include/clang/AST/Type.h:4103
   bool hasExtraBitfields() const {
-return hasExtraBitfields(getExceptionSpecType());
+assert((getExceptionSpecType() != EST_Dynamic ||
+FunctionTypeBits.HasExtraBitfields) &&

sdesmalen wrote:
> sdesmalen wrote:
> > erichkeane wrote:
> > > Why is asking if we DO have extra bitfields an assert here?  I would 
> > > think this is a valid question...
> > > 
> > > Why would 'dynamic' and extra-bitfields be exclusive here?
> > This assert is merely confirming that HasExtraBitfields **must** be true if 
> > the ExceptionSpecType is `EST_Dynamic`, because that was the old behaviour 
> > (and I wanted to avoid introducing failures if some code still assumed that 
> > hasExtraBitfields == true, but for some reason HasExtraBitfields had not 
> > yet been set to `true`).
> I've marked the comment as done hoping that my above explanation clarified 
> it, but let me know if you're not happy with it.
Ah, that makes sense, thanks.  


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126642

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

[PATCH] D125585: [HLSL][clang][Driver] Parse target profile early to update Driver::TargetTriple.

[Chris Bieneman via Phabricator via cfe-commits]

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

LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125585

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

[PATCH] D126536: [pseudo] Add grammar annotations support.

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

Nice!

This has tests for the parsing-the-attribute bits, but I think we're missing 
tests for the actual guards added.




Comment at: clang-tools-extra/pseudo/include/clang-pseudo/GLR.h:114
+using ReduceGuard =
+std::function RHS,
+   const TokenStream &Tokens, const Grammar &G)>;

this signature seems a little off to me.

Guard logic is identified by a guard ID and we look it up, but we're not 
passing in the guard ID for some reason. Instead we pass in the rule ID, which 
this function uses to look up the guard ID again. Why not just pass the guard 
ID?

That said, it's a bit surprising that we have the rules declare separate guard 
rules, but then they're all implemented by one function. A map of functions 
seems more natural. (but not a performance advantage I guess)

Naming: it's confusing that this umbrella function is called "guard", but a 
specific rule like "guard=Override" is also called "guard". I'd either call 
this a GuardTester or bypass the issue by making this a DenseMap whose values 
are Guards.

Altogether I might write this as:
```
using Guard = llvm::function_ref RHS, 
const TokenStream &, const Grammar &)>;
...
const DenseMap &Guards;
```



Comment at: clang-tools-extra/pseudo/include/clang-pseudo/GLR.h:129
+
+  ReduceGuard Guard; // Guard for reducing.
 };

either a reference, or a lightweight reference type like function_ref, for 
consistency with other fields?



Comment at: clang-tools-extra/pseudo/include/clang-pseudo/Grammar.h:22
 //
+//  Attributes have the syntax form of [guard=value;key=value], they are
+//  associated with a grammar symbol (on the right-hand side of the symbol) or

nit: first "guard" should be "key"?



Comment at: clang-tools-extra/pseudo/include/clang-pseudo/Grammar.h:87
+// Defines the built-in attribute keys.
+enum class AttributeKey : uint8_t {
+  // A guard controls whether a reduction of a rule will be conducted by the 
GLR

hokein wrote:
> new names are welcome. Attribute is the name I came up with (I think it is 
> clearer than the original `Hook`), 
I don't understand why we need AttributeKey, and to parse things into it, 
rather than just using StringRef.

(Also here you've put it in the header, but it's not used in any interfaces)



Comment at: clang-tools-extra/pseudo/include/clang-pseudo/Grammar.h:94
+// It is the index into a table of attribute values.
+// NOTE: value among attributes must be unique even within different keys!
+using AttributeID = uint16_t;

hokein wrote:
> I'm not quite happy with using the value as the ID, I think we can encode the 
> Key into the ID as well (ID := Key | Value). 
> 
> Similar to the generated enum name, currently we just use the name of Value 
> (`Override`), it will be more confusing when we add more keys/values, one 
> idea is to add key as well (`GuardOverride` etc?).
Packing all the possible values into a single unstructured enum is weird, but 
the problem (if it's a problem) is _redundancy_ and packing the attribute name 
in there as well just makes that worse.

If we want to fix this, I think a sounder fix is something like:
```
// Grammar.h
using AttributeEnum = uint8_t;
struct Rule { ...; AttributeEnum Guard = 0; }
// CXX.h
enum class GuardID : AttributeEnum { Override = 1; };
enum class RecoveryID : AttributeEnum { Parens = 1; };
```

i.e. we keep track of the unique values per attribute name and emit an enum for 
each attribute. This probably means emitting the actual enum definitions in 
tablegen, rather than a generic .inc file.

(But I'm also fine with not fixing it at this point, and keeping one flat enum 
for the values) 



Comment at: clang-tools-extra/pseudo/include/clang-pseudo/Grammar.h:95
+// NOTE: value among attributes must be unique even within different keys!
+using AttributeID = uint16_t;
+// A sentinel attributeID indicating no attributes, by default.

I agree HookID is an unfortunately vague name, but I did consider and reject 
AttributeID which I think is actively confusing.
In the plain-english meaning, "guard" is an attribute, and "override" is its 
value. So assigning "override" an "attribute ID" is very confusing.

The difficulty of naming this is that we can't refer to the semantics (e.g. 
"Guard") as we want a single namespace for all of them, and all they have in 
common is syntax. However referring to "attribute values" makes for confusing 
internal data structures, as we don't model the whole attribute generically.

So we're left with names that suggest "this is some kind of anchor to attach 
custom code to". Maybe `ExtensionID` is a little clearer than `HookID`?



Comment at: clang-tools-extra/pseudo/include/clang-pseudo/Grammar.h:97
+// A sentinel attributeID indicating no attributes, by default.
+static const

[PATCH] D126498: [clangd] Fix hover crashing on integral or enumeral casts

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

Oh wow, my mental model of these was all wrong.

Thank you! Do you want me to land this for you?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126498

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

[PATCH] D125723: [MSVC] Add support for MSVC pragma optimize

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/Sema/SemaAttr.cpp:1207-1213
+  FD->addAttr(FramePointerAttr::CreateImplicit(Context, Kind));
+}
+
+void Sema::AddOptsize(FunctionDecl *FD, SourceLocation Loc) {
+  FD->dropAttr();
+  OptimizeSizeAttr::Kind Kind = OptimizeSizeAttr::On;
+  FD->addAttr(OptimizeSizeAttr::CreateImplicit(Context, Kind));

steplong wrote:
> aaron.ballman wrote:
> > Rather than creating two new, implicit attributes for this, why not add 
> > support for `__attribute__((optimize(...)))` from GCC and reuse that one?
> > 
> > https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
> > 
> > It seems like that serves the same function as these implicit attributes, 
> > but then users would get two features for the price of one.
> Hmm that makes sense. So, `pragma optimize(on, "s")` would be equivalent to 
> `__attribute__((optimize("-Os"))`. Could you give me a brief description of 
> what I would have to do to implement the attribute? I'm new to this
> Hmm that makes sense. So, pragma optimize(on, "s") would be equivalent to 
> __attribute__((optimize("-Os")).

Yup, effectively! And in terms of the AST, your pragma can implicitly create an 
`OptimizeAttr` with the appropriate arguments; then everything works off the 
same machinery.

> Could you give me a brief description of what I would have to do to implement 
> the attribute? I'm new to this

Absolutely! 
https://clang.llvm.org/docs/InternalsManual.html#how-to-add-an-attribute has 
most of the information you need. I'm happy to give you more information if 
you'd like it, though.



Comment at: clang/lib/Sema/SemaAttr.cpp:1224
+  FD->dropAttr();
+  FD->addAttr(NeverOptimizeNoneAttr::CreateImplicit(Context));
+}

steplong wrote:
> aaron.ballman wrote:
> > Can you explain why this is needed?
> I added this attr, so we can remove the attr optnone even if -O0 was passed 
> on the cmdline
I think if you add an `OptimizeAttr`, that could be used to carry this 
information instead of using a dedicated attribute for just the "never optnone" 
part.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125723

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

[clang-tools-extra] 9d991da - [pseudo] Respect LLVM_USE_HOST_TOOLS

[Sam McCall via cfe-commits]

Author: Sam McCall
Date: 2022-05-31T20:47:57+02:00
New Revision: 9d991da60df492a191b34aa3e75484ddd27e8930

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

LOG: [pseudo] Respect LLVM_USE_HOST_TOOLS

This is the intended way to request that build-time tools be built in a
distinct configuration.

This is set implicitly by LLVM_OPTIMIZED_TABLEGEN, which may be
surprising, but if undesired this should be fixed elsewhere.

Should fix crbug.com/1330304

Added: 


Modified: 
clang-tools-extra/pseudo/include/CMakeLists.txt

Removed: 




diff  --git a/clang-tools-extra/pseudo/include/CMakeLists.txt 
b/clang-tools-extra/pseudo/include/CMakeLists.txt
index e4265b18c2b2e..3bf9709c2bed8 100644
--- a/clang-tools-extra/pseudo/include/CMakeLists.txt
+++ b/clang-tools-extra/pseudo/include/CMakeLists.txt
@@ -1,9 +1,7 @@
 # The cxx.bnf grammar file
 set(cxx_bnf ${CMAKE_CURRENT_SOURCE_DIR}/../lib/cxx.bnf)
 
-# Using CMAKE_CROSSCOMPILING and not LLVM_USE_HOST_TOOLS because the latter is
-# also set for LLVM_OPTIMIZED_TABLEGEN, which we don't care about here.
-if(CMAKE_CROSSCOMPILING)
+if(LLVM_USE_HOST_TOOLS)
   build_native_tool(pseudo-gen pseudo_gen)
   set(pseudo_gen_target "${pseudo_gen}")
 else()



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

[PATCH] D125788: [flang][driver] Rename `flang-new` as `flang`

[Andrzej Warzynski via Phabricator via cfe-commits]

awarzynski added a comment.

In D125788#3547494 , @sscalpone wrote:

> I'm fine with removing or renaming the existing flang shell script.



In D125788#3547656 , @rouson wrote:

> On Mon, May 30, 2022 at 2:39 AM Andrzej Warzynski via Phabricator 
>  wrote:
> I support this.

Great, thank you both! "Step 1" merged: https://reviews.llvm.org/D125832. This 
leaves us with `flang` as a symlink pointing to `flang-to-external-fc`, which I 
will be removing once buildbots are reconfigured: 
https://reviews.llvm.org/D125796. I'd like this to happen soon.

In D125788#3547494 , @sscalpone wrote:

> This proposal is not restricted to F95  but to 
> any source that someone might attempt to compile.

I would really appreciate if we could agree on more specific criteria. IMHO, 
"any source" leaves too much room for interpretation.

In D125788#3547656 , @rouson wrote:

> Any news from the call?

Not much - it was a very quiet call (Memorial Day for some folks, ISC 2022 for 
others, unexpected hiccup with Teams for the rest ). We decided to re-visit in 
the next call.

**Next steps**
Just to avoid any confusion:

- `flang`, the bash script, will be renamed as `flang-to-external-fc` (see 
D125832 )
- `flang-new` won't be renamed just yet - perhaps we could discuss more in the 
forthcoming call(s)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125788

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

[PATCH] D126642: [Clang] NFCI: Add a new bit HasExtraBitfields to FunctionType.

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM aside from a nit.




Comment at: clang/include/clang/AST/Type.h:3809-3811
 unsigned NumExceptionType;
+
+FunctionTypeExtraBitfields() : NumExceptionType(0) {}




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126642

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