[PATCH] D136809: [CMake] Ensure `CLANG_RESOURCE_DIR` is respected

[LJC via Phabricator via cfe-commits]

paperchalice updated this revision to Diff 475706.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136809

Files:
  clang/lib/Headers/CMakeLists.txt
  clang/lib/Tooling/CMakeLists.txt
  clang/runtime/CMakeLists.txt
  cmake/Modules/GetClangResourceDir.cmake
  compiler-rt/cmake/base-config-ix.cmake
  lldb/source/Plugins/ExpressionParser/Clang/ClangHost.cpp
  lldb/unittests/Expression/ClangParserTest.cpp
  llvm/cmake/modules/LLVMExternalProjectUtils.cmake
  openmp/CMakeLists.txt

Index: openmp/CMakeLists.txt
===
--- openmp/CMakeLists.txt
+++ openmp/CMakeLists.txt
@@ -79,8 +79,8 @@
 if(${OPENMP_STANDALONE_BUILD})
   set(LIBOMP_HEADERS_INSTALL_PATH "${CMAKE_INSTALL_INCLUDEDIR}")
 else()
-  string(REGEX MATCH "[0-9]+" CLANG_VERSION ${PACKAGE_VERSION})
-  set(LIBOMP_HEADERS_INSTALL_PATH "${OPENMP_INSTALL_LIBDIR}/clang/${CLANG_VERSION}/include")
+  include(GetClangResourceDir)
+  get_clang_resource_dir(LIBOMP_HEADERS_INSTALL_PATH SUBDIR include)
 endif()
 
 # Build host runtime library, after LIBOMPTARGET variables are set since they are needed
Index: llvm/cmake/modules/LLVMExternalProjectUtils.cmake
===
--- llvm/cmake/modules/LLVMExternalProjectUtils.cmake
+++ llvm/cmake/modules/LLVMExternalProjectUtils.cmake
@@ -257,7 +257,11 @@
 if(CMAKE_CXX_COMPILER_ID MATCHES "Clang")
   string(REGEX MATCH "^[0-9]+" CLANG_VERSION_MAJOR
  ${PACKAGE_VERSION})
-  set(resource_dir "${LLVM_LIBRARY_DIR}/clang/${CLANG_VERSION_MAJOR}")
+  if(DEFINED CLANG_RESOURCE_DIR AND NOT CLANG_RESOURCE_DIR STREQUAL "")
+set(resource_dir ${LLVM_TOOLS_BINARY_DIR}/${CLANG_RESOURCE_DIR})
+  else()
+set(resource_dir "${LLVM_LIBRARY_DIR}/clang/${CLANG_VERSION_MAJOR}")
+  endif()
   set(flag_types ASM C CXX MODULE_LINKER SHARED_LINKER EXE_LINKER)
   foreach(type ${flag_types})
 set(${type}_flag -DCMAKE_${type}_FLAGS=-resource-dir=${resource_dir})
Index: lldb/unittests/Expression/ClangParserTest.cpp
===
--- lldb/unittests/Expression/ClangParserTest.cpp
+++ lldb/unittests/Expression/ClangParserTest.cpp
@@ -7,6 +7,7 @@
 //===--===//
 
 #include "clang/Basic/Version.h"
+#include "clang/Config/config.h"
 
 #include "Plugins/ExpressionParser/Clang/ClangHost.h"
 #include "TestingSupport/SubsystemRAII.h"
@@ -37,12 +38,16 @@
 TEST_F(ClangHostTest, ComputeClangResourceDirectory) {
 #if !defined(_WIN32)
   std::string path_to_liblldb = "/foo/bar/lib/";
-  std::string path_to_clang_dir =
-  "/foo/bar/" LLDB_INSTALL_LIBDIR_BASENAME "/clang/" CLANG_VERSION_MAJOR_STRING;
+  std::string path_to_clang_dir = CLANG_RESOURCE_DIR[0]
+  ? "/foo/bar/bin/" CLANG_RESOURCE_DIR
+  : "/foo/bar/" LLDB_INSTALL_LIBDIR_BASENAME
+"/clang/" CLANG_VERSION_MAJOR_STRING;
 #else
   std::string path_to_liblldb = "C:\\foo\\bar\\lib";
   std::string path_to_clang_dir =
-  "C:\\foo\\bar\\lib\\clang\\" CLANG_VERSION_MAJOR_STRING;
+  CLANG_RESOURCE_DIR[0]
+  ? "C:\\foo\\bar\\bin\\" CLANG_RESOURCE_DIR
+  : "C:\\foo\\bar\\lib\\clang\\" CLANG_VERSION_MAJOR_STRING;
 #endif
   EXPECT_EQ(ComputeClangResourceDir(path_to_liblldb), path_to_clang_dir);
 
Index: lldb/source/Plugins/ExpressionParser/Clang/ClangHost.cpp
===
--- lldb/source/Plugins/ExpressionParser/Clang/ClangHost.cpp
+++ lldb/source/Plugins/ExpressionParser/Clang/ClangHost.cpp
@@ -54,8 +54,11 @@
 
   static const llvm::StringRef kResourceDirSuffixes[] = {
   // LLVM.org's build of LLDB uses the clang resource directory placed
-  // in $install_dir/lib{,64}/clang/$clang_version.
-  CLANG_INSTALL_LIBDIR_BASENAME "/clang/" CLANG_VERSION_MAJOR_STRING,
+  // in $install_dir/lib{,64}/clang/$clang_version or
+  // $install_dir/bin/$CLANG_RESOURCE_DIR
+  CLANG_RESOURCE_DIR[0] ? "bin/" CLANG_RESOURCE_DIR
+: CLANG_INSTALL_LIBDIR_BASENAME
+  "/clang/" CLANG_VERSION_MAJOR_STRING,
   // swift-lldb uses the clang resource directory copied from swift, which
   // by default is placed in $install_dir/lib{,64}/lldb/clang. LLDB places
   // it there, so we use LLDB_INSTALL_LIBDIR_BASENAME.
Index: compiler-rt/cmake/base-config-ix.cmake
===
--- compiler-rt/cmake/base-config-ix.cmake
+++ compiler-rt/cmake/base-config-ix.cmake
@@ -7,6 +7,7 @@
 include(CheckIncludeFile)
 include(CheckCXXSourceCompiles)
 include(GNUInstallDirs)
+include(GetClangResourceDir)
 include(ExtendPath)
 
 check_include_file(unwind.h HAVE_UNWIND_H)
@@ 

[PATCH] D138094: [LoongArch] Add intrinsics for ibar, break and syscall

[Gong LingQin via Phabricator via cfe-commits]

gonglingqin added inline comments.



Comment at: clang/include/clang/Basic/BuiltinsLoongArch.def:20-23
 TARGET_BUILTIN(__builtin_loongarch_dbar, "vIUi", "nc", "")
+TARGET_BUILTIN(__builtin_loongarch_ibar, "vIUi", "nc", "")
+TARGET_BUILTIN(__builtin_loongarch_break, "vIUi", "nc", "")
+TARGET_BUILTIN(__builtin_loongarch_syscall, "vIUi", "nc", "")

arsenm wrote:
> These all have I parameters but the underlying intrinsic wasn't marked with 
> immarg 
Thanks for checking, I'll add constraints.



Comment at: clang/test/CodeGen/LoongArch/intrinsic-error.c:21
+  __builtin_loongarch_ibar(-1); // expected-error {{argument value 4294967295 
is outside the valid range [0, 32767]}}
+}
+

arsenm wrote:
> Should also test non-constant cases 
Thanks, I'll add the test cases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138094

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

[PATCH] D138094: [LoongArch] Add intrinsics for ibar, break and syscall

[Gong LingQin via Phabricator via cfe-commits]

gonglingqin updated this revision to Diff 475715.
gonglingqin added a comment.

Address @arsenm's comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138094

Files:
  clang/include/clang/Basic/BuiltinsLoongArch.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Headers/larchintrin.h
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/LoongArch/intrinsic-error.c
  clang/test/CodeGen/LoongArch/intrinsic.c
  llvm/include/llvm/IR/IntrinsicsLoongArch.td
  llvm/lib/Target/LoongArch/LoongArchISelLowering.cpp
  llvm/lib/Target/LoongArch/LoongArchISelLowering.h
  llvm/lib/Target/LoongArch/LoongArchInstrInfo.td
  llvm/test/CodeGen/LoongArch/intrinsic-error.ll
  llvm/test/CodeGen/LoongArch/intrinsic-not-constant-error.ll
  llvm/test/CodeGen/LoongArch/intrinsic.ll

Index: llvm/test/CodeGen/LoongArch/intrinsic.ll
===
--- llvm/test/CodeGen/LoongArch/intrinsic.ll
+++ llvm/test/CodeGen/LoongArch/intrinsic.ll
@@ -3,6 +3,9 @@
 ; RUN: llc --mtriple=loongarch64 < %s | FileCheck %s
 
 declare void @llvm.loongarch.dbar(i32)
+declare void @llvm.loongarch.ibar(i32)
+declare void @llvm.loongarch.break(i32)
+declare void @llvm.loongarch.syscall(i32)
 
 define void @foo() nounwind {
 ; CHECK-LABEL: foo:
@@ -13,3 +16,33 @@
   call void @llvm.loongarch.dbar(i32 0)
   ret void
 }
+
+define void @ibar() nounwind {
+; CHECK-LABEL: ibar:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:ibar 0
+; CHECK-NEXT:ret
+entry:
+  call void @llvm.loongarch.ibar(i32 0)
+  ret void
+}
+
+define void @break() nounwind {
+; CHECK-LABEL: break:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:break 1
+; CHECK-NEXT:ret
+entry:
+  call void @llvm.loongarch.break(i32 1)
+  ret void
+}
+
+define void @syscall() nounwind {
+; CHECK-LABEL: syscall:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:syscall 1
+; CHECK-NEXT:ret
+entry:
+  call void @llvm.loongarch.syscall(i32 1)
+  ret void
+}
Index: llvm/test/CodeGen/LoongArch/intrinsic-not-constant-error.ll
===
--- /dev/null
+++ llvm/test/CodeGen/LoongArch/intrinsic-not-constant-error.ll
@@ -0,0 +1,35 @@
+; RUN: not llc --mtriple=loongarch32 < %s 2>&1 | FileCheck %s
+; RUN: not llc --mtriple=loongarch64 < %s 2>&1 | FileCheck %s
+
+declare void @llvm.loongarch.dbar(i32)
+declare void @llvm.loongarch.ibar(i32)
+declare void @llvm.loongarch.break(i32)
+declare void @llvm.loongarch.syscall(i32)
+
+define void @dbar_not_constant(i32 %x) nounwind {
+; CHECK: immarg operand has non-immediate parameter
+entry:
+  call void @llvm.loongarch.dbar(i32 %x)
+  ret void
+}
+
+define void @ibar(i32 %x) nounwind {
+; CHECK: immarg operand has non-immediate parameter
+entry:
+  call void @llvm.loongarch.ibar(i32 %x)
+  ret void
+}
+
+define void @break(i32 %x) nounwind {
+; CHECK: immarg operand has non-immediate parameter
+entry:
+  call void @llvm.loongarch.break(i32 %x)
+  ret void
+}
+
+define void @syscall(i32 %x) nounwind {
+; CHECK: immarg operand has non-immediate parameter
+entry:
+  call void @llvm.loongarch.syscall(i32 %x)
+  ret void
+}
Index: llvm/test/CodeGen/LoongArch/intrinsic-error.ll
===
--- llvm/test/CodeGen/LoongArch/intrinsic-error.ll
+++ llvm/test/CodeGen/LoongArch/intrinsic-error.ll
@@ -1,12 +1,10 @@
-; RUN: not llc --mtriple=loongarch32 --disable-verify < %s 2>&1 | FileCheck %s
-; RUN: not llc --mtriple=loongarch64 --disable-verify < %s 2>&1 | FileCheck %s
+; RUN: not llc --mtriple=loongarch32 < %s 2>&1 | FileCheck %s
+; RUN: not llc --mtriple=loongarch64 < %s 2>&1 | FileCheck %s
 
-define void @dbar_not_constant(i32 %x) nounwind {
-; CHECK: argument to '__builtin_loongarch_dbar' must be a constant integer
-entry:
-  call void @llvm.loongarch.dbar(i32 %x)
-  ret void
-}
+declare void @llvm.loongarch.dbar(i32)
+declare void @llvm.loongarch.ibar(i32)
+declare void @llvm.loongarch.break(i32)
+declare void @llvm.loongarch.syscall(i32)
 
 define void @dbar_imm_out_of_hi_range() nounwind {
 ; CHECK: argument to '__builtin_loongarch_dbar' out of range
@@ -22,4 +20,44 @@
   ret void
 }
 
-declare void @llvm.loongarch.dbar(i32)
+define void @ibar_imm_out_of_hi_range() nounwind {
+; CHECK: argument to '__builtin_loongarch_ibar' out of range
+entry:
+  call void @llvm.loongarch.ibar(i32 32769)
+  ret void
+}
+
+define void @ibar_imm_out_of_lo_range() nounwind {
+; CHECK: argument to '__builtin_loongarch_ibar' out of range
+entry:
+  call void @llvm.loongarch.ibar(i32 -1)
+  ret void
+}
+
+define void @break_imm_out_of_hi_range() nounwind {
+; CHECK: argument to '__builtin_loongarch_break' out of range
+entry:
+  call void @llvm.loongarch.break(i32 32769)
+  ret void
+}
+
+define void @break_imm_out_of_lo_range() nounwind {
+; CHECK: argument to '__builtin_loongarch_break' out of range
+entry:
+  call void @llvm.loo

[clang] d128a03 - [clang][Interp][NFC] Use constexpr if in OffsetHelper

[Timm Bäder via cfe-commits]

Author: Timm Bäder
Date: 2022-11-16T09:56:29+01:00
New Revision: d128a03ff3b1d3e48fae41a10e790faf3a775d35

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

LOG: [clang][Interp][NFC] Use constexpr if in OffsetHelper

Add here is a template parameter, so we can do this.

Added: 


Modified: 
clang/lib/AST/Interp/Interp.h

Removed: 




diff  --git a/clang/lib/AST/Interp/Interp.h b/clang/lib/AST/Interp/Interp.h
index a90e1246311d8..002571e731371 100644
--- a/clang/lib/AST/Interp/Interp.h
+++ b/clang/lib/AST/Interp/Interp.h
@@ -1056,7 +1056,12 @@ template  bool 
OffsetHelper(InterpState &S, CodePtr OpPC) {
   // Offset is valid - compute it on unsigned.
   int64_t WideIndex = static_cast(Index);
   int64_t WideOffset = static_cast(Offset);
-  int64_t Result = Add ? (WideIndex + WideOffset) : (WideIndex - WideOffset);
+  int64_t Result;
+  if constexpr (Add)
+Result = WideIndex + WideOffset;
+  else
+Result = WideIndex - WideOffset;
+
   S.Stk.push(Ptr.atIndex(static_cast(Result)));
   return true;
 }



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

[PATCH] D137534: [C++20] [Modules] [ClangScanDeps] Allow clang-scan-deps to without specified compilation database in P1689

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu updated this revision to Diff 475719.
ChuanqiXu retitled this revision from "[C++20] [Modules] [ClangScanDeps] 
Support to query separate file for P1689 (3/3)" to "[C++20] [Modules] 
[ClangScanDeps] Allow clang-scan-deps to without specified compilation database 
in P1689".
ChuanqiXu edited the summary of this revision.

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

https://reviews.llvm.org/D137534

Files:
  clang/test/ClangScanDeps/P1689.cppm
  clang/tools/clang-scan-deps/ClangScanDeps.cpp

Index: clang/tools/clang-scan-deps/ClangScanDeps.cpp
===
--- clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -167,7 +167,7 @@
 
 llvm::cl::opt
 CompilationDB("compilation-database",
-  llvm::cl::desc("Compilation database"), llvm::cl::Required,
+  llvm::cl::desc("Compilation database"), llvm::cl::Optional,
   llvm::cl::cat(DependencyScannerCategory));
 
 llvm::cl::opt ModuleName(
@@ -175,6 +175,30 @@
 llvm::cl::desc("the module of which the dependencies are to be computed"),
 llvm::cl::cat(DependencyScannerCategory));
 
+llvm::cl::opt P1689TargetedFileName(
+"p1689-targeted-file-name", llvm::cl::Optional,
+llvm::cl::desc("Only supported for P1689, the targeted file name of which "
+   "the dependencies are to be computed."),
+llvm::cl::cat(DependencyScannerCategory));
+
+llvm::cl::opt P1689TargetedOutput(
+"p1689-targeted-output", llvm::cl::Optional,
+llvm::cl::desc("Only supported for P1689, the targeted output of which the "
+   "dependencies are to be computed."),
+llvm::cl::cat(DependencyScannerCategory));
+
+llvm::cl::opt P1689TargetedDirectory(
+"p1689-targeted-directory", llvm::cl::Optional,
+llvm::cl::desc("Only supported for P1689, the targeted directory of which "
+   "the dependencies are to be computed."),
+llvm::cl::cat(DependencyScannerCategory));
+
+llvm::cl::opt P1689TargetedCommand(
+"p1689-targeted-command", llvm::cl::Optional,
+llvm::cl::desc("Only supported for P1689, the targeted command of which "
+   "the dependencies are to be computed."),
+llvm::cl::cat(DependencyScannerCategory));
+
 llvm::cl::list ModuleDepTargets(
 "dependency-target",
 llvm::cl::desc("The names of dependency targets for the dependency file"),
@@ -522,6 +546,46 @@
   return std::string(Path);
 }
 
+// getCompilationDataBase - If -compilation-database is set, load the
+// compilation database from the specified file. Otherwise if the we're
+// generating P1689 format, trying to generate the compilation database
+// form the p1689 related command lines. Otherwise, the invocation is
+// ill-formed.
+static std::unique_ptr
+getCompilationDataBase(std::string &ErrorMessage) {
+  if (!CompilationDB.empty())
+return tooling::JSONCompilationDatabase::loadFromFile(
+CompilationDB, ErrorMessage,
+tooling::JSONCommandLineSyntax::AutoDetect);
+
+  if (Format != ScanningOutputFormat::P1689) {
+llvm::errs() << "the --compilation-database option: must be specified at "
+"least once!";
+return nullptr;
+  }
+
+  if (P1689TargetedFileName.empty() || P1689TargetedOutput.empty() ||
+  P1689TargetedDirectory.empty() || P1689TargetedCommand.empty()) {
+llvm::errs() << "missing compilation database and failed to contruct "
+"one by --p1689-targeted-file-name, --p1689-targeted-output"
+"--p1689-targeted-directory and --p1689-targeted-command";
+return nullptr;
+  }
+
+  llvm::raw_string_ostream OS(CompilationDB);
+
+  using namespace llvm::json;
+  Array Entries;
+  Object Output{{"directory", P1689TargetedDirectory},
+{"command", P1689TargetedCommand},
+{"file", P1689TargetedFileName},
+{"output", P1689TargetedOutput}};
+  Entries.push_back(std::move(Output));
+  OS << Value(std::move(Entries));
+  return tooling::JSONCompilationDatabase::loadFromBuffer(
+  CompilationDB, ErrorMessage, tooling::JSONCommandLineSyntax::AutoDetect);
+}
+
 int main(int argc, const char **argv) {
   llvm::InitLLVM X(argc, argv);
   llvm::cl::HideUnrelatedOptions(DependencyScannerCategory);
@@ -530,9 +594,7 @@
 
   std::string ErrorMessage;
   std::unique_ptr Compilations =
-  tooling::JSONCompilationDatabase::loadFromFile(
-  CompilationDB, ErrorMessage,
-  tooling::JSONCommandLineSyntax::AutoDetect);
+  getCompilationDataBase(ErrorMessage);
   if (!Compilations) {
 llvm::errs() << "error: " << ErrorMessage << "\n";
 return 1;
Index: clang/test/ClangScanDeps/P1689.cppm
===
--- clang/test/ClangScanDeps/P1689.cppm
+++ clang/test/ClangScanDeps/P1689.cppm
@@ -5,6 +5,23 @@
 // RUN: sed "s|DIR|%/t|g" %t/P1689.j

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

[Qiu Chaofan via Phabricator via cfe-commits]

qiucf created this revision.
qiucf added reviewers: nemanjai, shchenz, PowerPC, quinnp, stefanp.
Herald added subscribers: kbarton, hiraditya.
Herald added a project: All.
qiucf requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

We've exploited test data class instructions for `f32` `f64` v2f64` and 
`v4f32`. This patch unifies the LLVM intrinsic into the same 
`ppc_test_data_class` and add support for 128-bit precision float values using 
`xststdcqp`.

Vector versions of the intrinsic can't be unified because they return vector 
int instead of int.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D138105

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/PowerPC/builtins-ppc-p9-f128.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-test.c
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPCISelLowering.cpp
  llvm/test/CodeGen/PowerPC/builtins-ppc-p9-f128.ll
  llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-test.ll

Index: llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-test.ll
===
--- llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-test.ll
+++ llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-test.ll
@@ -77,11 +77,11 @@
 ; CHECK-NEXT:iseleq 3, 4, 3
 ; CHECK-NEXT:blr
 entry:
-  %test_data_class = tail call i32 @llvm.ppc.test.data.class.d(double %d, i32 0)
+  %test_data_class = tail call i32 @llvm.ppc.test.data.class.f64(double %d, i32 0)
   ret i32 %test_data_class
 }
 
-declare i32 @llvm.ppc.test.data.class.d(double, i32 immarg)
+declare i32 @llvm.ppc.test.data.class.f64(double, i32 immarg)
 
 define i32 @test_builtin_ppc_test_data_class_f(float %f) {
 ; CHECK-LABEL: test_builtin_ppc_test_data_class_f:
@@ -92,8 +92,8 @@
 ; CHECK-NEXT:iseleq 3, 4, 3
 ; CHECK-NEXT:blr
 entry:
-  %test_data_class = tail call i32 @llvm.ppc.test.data.class.f(float %f, i32 127)
+  %test_data_class = tail call i32 @llvm.ppc.test.data.class.f32(float %f, i32 127)
   ret i32 %test_data_class
 }
 
-declare i32 @llvm.ppc.test.data.class.f(float, i32 immarg)
+declare i32 @llvm.ppc.test.data.class.f32(float, i32 immarg)
Index: llvm/test/CodeGen/PowerPC/builtins-ppc-p9-f128.ll
===
--- llvm/test/CodeGen/PowerPC/builtins-ppc-p9-f128.ll
+++ llvm/test/CodeGen/PowerPC/builtins-ppc-p9-f128.ll
@@ -136,3 +136,16 @@
 ; Function Attrs: nounwind readnone
 declare i64 @llvm.ppc.scalar.extract.expq(fp128)
 
+define i32 @test_data_class_f128(fp128 %d) {
+entry:
+  %test_data_class = tail call i32 @llvm.ppc.test.data.class.f128(fp128 %d, i32 0)
+  ret i32 %test_data_class
+; CHECK-LABEL: test_data_class_f128:
+; CHECK: xststdcqp cr0, v2, 0
+; CHECK-NEXT: li r3, 0
+; CHECK-NEXT: li r4, 1
+; CHECK-NEXT: iseleq r3, r4, r3
+; CHECK-NEXT: blr
+}
+
+declare i32 @llvm.ppc.test.data.class.f128(fp128, i32 immarg)
Index: llvm/lib/Target/PowerPC/PPCISelLowering.cpp
===
--- llvm/lib/Target/PowerPC/PPCISelLowering.cpp
+++ llvm/lib/Target/PowerPC/PPCISelLowering.cpp
@@ -10548,11 +10548,11 @@
  DAG.getTargetConstant(Pred, dl, MVT::i32)}),
 0);
   }
-  case Intrinsic::ppc_test_data_class_d:
-  case Intrinsic::ppc_test_data_class_f: {
-unsigned CmprOpc = PPC::XSTSTDCDP;
-if (IntrinsicID == Intrinsic::ppc_test_data_class_f)
-  CmprOpc = PPC::XSTSTDCSP;
+  case Intrinsic::ppc_test_data_class: {
+EVT OpVT = Op.getOperand(1).getValueType();
+unsigned CmprOpc = OpVT == MVT::f128 ? PPC::XSTSTDCQP
+ : (OpVT == MVT::f64 ? PPC::XSTSTDCDP
+ : PPC::XSTSTDCSP);
 return SDValue(
 DAG.getMachineNode(
 PPC::SELECT_CC_I4, dl, MVT::i32,
Index: llvm/include/llvm/IR/IntrinsicsPowerPC.td
===
--- llvm/include/llvm/IR/IntrinsicsPowerPC.td
+++ llvm/include/llvm/IR/IntrinsicsPowerPC.td
@@ -1803,12 +1803,9 @@
Intrinsic<[llvm_i32_ty], 
  [llvm_double_ty, llvm_double_ty], 
  [IntrNoMem]>;
-  def int_ppc_test_data_class_d : Intrinsic<[llvm_i32_ty],
-[llvm_double_ty, llvm_i32_ty],
-[IntrNoMem, ImmArg>]>;
-  def int_ppc_test_data_class_f : Intrinsic<[llvm_i32_ty],
-[llvm_float_ty, llvm_i32_ty],
-[IntrNoMem, ImmArg>]>;
+  def int_ppc_test_data_class : Intrinsic<[llvm_i32_ty],
+  [llvm_anyfloat_ty, llvm_i32_ty],
+  [IntrNoMem, ImmArg>]>;
   def int_ppc_f

[clang] 0512303 - [clang][NFC] Remove unused CastForMoving parameter

[Timm Bäder via cfe-commits]

Author: Timm Bäder
Date: 2022-11-16T10:02:52+01:00
New Revision: 051230359c6e405a41ecad48162939f8a00c0532

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

LOG: [clang][NFC] Remove unused CastForMoving parameter

Nothing ever passes a third parameter to CastForMoving.

Added: 


Modified: 
clang/lib/Sema/SemaDeclCXX.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaDeclCXX.cpp b/clang/lib/Sema/SemaDeclCXX.cpp
index a15824fb7d90f..0ea99a835e887 100644
--- a/clang/lib/Sema/SemaDeclCXX.cpp
+++ b/clang/lib/Sema/SemaDeclCXX.cpp
@@ -4691,10 +4691,10 @@ Sema::BuildBaseInitializer(QualType BaseType, 
TypeSourceInfo *BaseTInfo,
 }
 
 // Create a static_cast\(expr).
-static Expr *CastForMoving(Sema &SemaRef, Expr *E, QualType T = QualType()) {
-  if (T.isNull()) T = E->getType();
-  QualType TargetType = SemaRef.BuildReferenceType(
-  T, /*SpelledAsLValue*/false, SourceLocation(), DeclarationName());
+static Expr *CastForMoving(Sema &SemaRef, Expr *E) {
+  QualType TargetType =
+  SemaRef.BuildReferenceType(E->getType(), /*SpelledAsLValue*/ false,
+ SourceLocation(), DeclarationName());
   SourceLocation ExprLoc = E->getBeginLoc();
   TypeSourceInfo *TargetLoc = SemaRef.Context.getTrivialTypeSourceInfo(
   TargetType, ExprLoc);



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

[clang] 981dac8 - [clang][Parse][NFC] Remove unused DenseMap

[Timm Bäder via cfe-commits]

Author: Timm Bäder
Date: 2022-11-16T10:02:52+01:00
New Revision: 981dac8bd6fef375847e81ea5df19d4e760532b8

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

LOG: [clang][Parse][NFC] Remove unused DenseMap

Added: 


Modified: 
clang/lib/Parse/ParseDeclCXX.cpp

Removed: 




diff  --git a/clang/lib/Parse/ParseDeclCXX.cpp 
b/clang/lib/Parse/ParseDeclCXX.cpp
index bb5394f04..7456df00f77f3 100644
--- a/clang/lib/Parse/ParseDeclCXX.cpp
+++ b/clang/lib/Parse/ParseDeclCXX.cpp
@@ -4487,8 +4487,6 @@ void 
Parser::ParseCXX11AttributeSpecifierInternal(ParsedAttributes &Attrs,
   Diag(Tok.getLocation(), diag::err_expected) << tok::colon;
   }
 
-  llvm::SmallDenseMap SeenAttrs;
-
   bool AttrParsed = false;
   while (!Tok.isOneOf(tok::r_square, tok::semi, tok::eof)) {
 if (AttrParsed) {



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

[PATCH] D138010: [AArch64][ARM] add Armv8.9-a/Armv9.4-a identifier support

[Tomas Matheson via Phabricator via cfe-commits]

tmatheson accepted this revision.
tmatheson 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/D138010/new/

https://reviews.llvm.org/D138010

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

[clang] 983f63f - [AArch64][ARM] add Armv8.9-a/Armv9.4-a identifier support

[Ties Stuij via cfe-commits]

Author: Ties Stuij
Date: 2022-11-16T10:20:14Z
New Revision: 983f63f7f0d1643eb138db004351a18d1b3e91a3

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

LOG: [AArch64][ARM] add Armv8.9-a/Armv9.4-a identifier support

For both ARM and AArch64 add support for specifying -march=armv8.9a/armv9.4a to
clang. Add backend plumbing like target parser and predicate support.

For a summary of Amv8.9/Armv9.4 features, see:
https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-a-profile-architecture-2022

For detailed information, consult the Arm Architecture Reference Manual for
A-profile architecture:
https://developer.arm.com/documentation/ddi0487/latest/

People who contributed to this patch:
- Keith Walker
- Ties Stuij

Reviewed By: tmatheson

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

Added: 
clang/test/Driver/aarch64-v89a.c
clang/test/Driver/aarch64-v94a.c

Modified: 
clang/lib/Basic/Targets/AArch64.cpp
clang/lib/Basic/Targets/AArch64.h
clang/lib/Basic/Targets/ARM.cpp
clang/lib/Driver/ToolChains/Arch/AArch64.cpp
clang/test/Driver/arm-cortex-cpus-1.c
clang/test/Preprocessor/arm-target-features.c
llvm/include/llvm/ADT/Triple.h
llvm/include/llvm/Support/AArch64TargetParser.def
llvm/include/llvm/Support/ARMTargetParser.def
llvm/lib/Support/ARMTargetParser.cpp
llvm/lib/Support/ARMTargetParserCommon.cpp
llvm/lib/Support/Triple.cpp
llvm/lib/Target/AArch64/AArch64.td
llvm/lib/Target/AArch64/AArch64InstrInfo.td
llvm/lib/Target/AArch64/AsmParser/AArch64AsmParser.cpp
llvm/lib/Target/ARM/ARM.td
llvm/lib/Target/ARM/ARMSubtarget.h
llvm/lib/Target/ARM/MCTargetDesc/ARMELFStreamer.cpp
llvm/unittests/Support/TargetParserTest.cpp

Removed: 




diff  --git a/clang/lib/Basic/Targets/AArch64.cpp 
b/clang/lib/Basic/Targets/AArch64.cpp
index c070462bc5d1f..c283aca85f4e2 100644
--- a/clang/lib/Basic/Targets/AArch64.cpp
+++ b/clang/lib/Basic/Targets/AArch64.cpp
@@ -50,6 +50,7 @@ static StringRef getArchVersionString(llvm::AArch64::ArchKind 
Kind) {
   case llvm::AArch64::ArchKind::ARMV9_1A:
   case llvm::AArch64::ArchKind::ARMV9_2A:
   case llvm::AArch64::ArchKind::ARMV9_3A:
+  case llvm::AArch64::ArchKind::ARMV9_4A:
 return "9";
   default:
 return "8";
@@ -235,6 +236,12 @@ void AArch64TargetInfo::getTargetDefinesARMV88A(const 
LangOptions &Opts,
   getTargetDefinesARMV87A(Opts, Builder);
 }
 
+void AArch64TargetInfo::getTargetDefinesARMV89A(const LangOptions &Opts,
+MacroBuilder &Builder) const {
+  // Also include the Armv8.8 defines
+  getTargetDefinesARMV88A(Opts, Builder);
+}
+
 void AArch64TargetInfo::getTargetDefinesARMV9A(const LangOptions &Opts,
MacroBuilder &Builder) const {
   // Armv9-A maps to Armv8.5-A
@@ -259,6 +266,12 @@ void AArch64TargetInfo::getTargetDefinesARMV93A(const 
LangOptions &Opts,
   getTargetDefinesARMV88A(Opts, Builder);
 }
 
+void AArch64TargetInfo::getTargetDefinesARMV94A(const LangOptions &Opts,
+MacroBuilder &Builder) const {
+  // Armv9.4-A maps to Armv8.9-A
+  getTargetDefinesARMV89A(Opts, Builder);
+}
+
 void AArch64TargetInfo::getTargetDefines(const LangOptions &Opts,
  MacroBuilder &Builder) const {
   // Target identification.
@@ -473,6 +486,9 @@ void AArch64TargetInfo::getTargetDefines(const LangOptions 
&Opts,
   case llvm::AArch64::ArchKind::ARMV8_8A:
 getTargetDefinesARMV88A(Opts, Builder);
 break;
+  case llvm::AArch64::ArchKind::ARMV8_9A:
+getTargetDefinesARMV89A(Opts, Builder);
+break;
   case llvm::AArch64::ArchKind::ARMV9A:
 getTargetDefinesARMV9A(Opts, Builder);
 break;
@@ -485,6 +501,9 @@ void AArch64TargetInfo::getTargetDefines(const LangOptions 
&Opts,
   case llvm::AArch64::ArchKind::ARMV9_3A:
 getTargetDefinesARMV93A(Opts, Builder);
 break;
+  case llvm::AArch64::ArchKind::ARMV9_4A:
+getTargetDefinesARMV94A(Opts, Builder);
+break;
   }
 
   // All of the __sync_(bool|val)_compare_and_swap_(1|2|4|8) builtins work.
@@ -658,6 +677,8 @@ bool 
AArch64TargetInfo::handleTargetFeatures(std::vector &Features,
   ArchKind = llvm::AArch64::ArchKind::ARMV8_7A;
 if (Feature == "+v8.8a" && ArchKind < llvm::AArch64::ArchKind::ARMV8_8A)
   ArchKind = llvm::AArch64::ArchKind::ARMV8_8A;
+if (Feature == "+v8.9a" && ArchKind < llvm::AArch64::ArchKind::ARMV8_9A)
+  ArchKind = llvm::AArch64::ArchKind::ARMV8_9A;
 if (Feature == "+v9a" && ArchKind < llvm::AArch64::ArchKind::ARMV9A)
   ArchKind = llvm::AArch64::ArchKind::ARMV9A;
 if (Feature == "+v9.1a" && ArchKind < llvm::AArch64::ArchKind::AR

[PATCH] D138010: [AArch64][ARM] add Armv8.9-a/Armv9.4-a identifier support

[Ties Stuij via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG983f63f7f0d1: [AArch64][ARM] add Armv8.9-a/Armv9.4-a 
identifier support (authored by stuij).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138010

Files:
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Basic/Targets/AArch64.h
  clang/lib/Basic/Targets/ARM.cpp
  clang/lib/Driver/ToolChains/Arch/AArch64.cpp
  clang/test/Driver/aarch64-v89a.c
  clang/test/Driver/aarch64-v94a.c
  clang/test/Driver/arm-cortex-cpus-1.c
  clang/test/Preprocessor/arm-target-features.c
  llvm/include/llvm/ADT/Triple.h
  llvm/include/llvm/Support/AArch64TargetParser.def
  llvm/include/llvm/Support/ARMTargetParser.def
  llvm/lib/Support/ARMTargetParser.cpp
  llvm/lib/Support/ARMTargetParserCommon.cpp
  llvm/lib/Support/Triple.cpp
  llvm/lib/Target/AArch64/AArch64.td
  llvm/lib/Target/AArch64/AArch64InstrInfo.td
  llvm/lib/Target/AArch64/AsmParser/AArch64AsmParser.cpp
  llvm/lib/Target/ARM/ARM.td
  llvm/lib/Target/ARM/ARMSubtarget.h
  llvm/lib/Target/ARM/MCTargetDesc/ARMELFStreamer.cpp
  llvm/unittests/Support/TargetParserTest.cpp

Index: llvm/unittests/Support/TargetParserTest.cpp
===
--- llvm/unittests/Support/TargetParserTest.cpp
+++ llvm/unittests/Support/TargetParserTest.cpp
@@ -32,10 +32,12 @@
 "armv8a",   "armv8l",  "armv8.1-a",  "armv8.1a","armv8.2-a",
 "armv8.2a", "armv8.3-a",   "armv8.3a",   "armv8.4-a",   "armv8.4a",
 "armv8.5-a","armv8.5a","armv8.6-a",  "armv8.6a","armv8.7-a",
-"armv8.7a", "armv8.8-a",   "armv8.8a",   "armv8-r", "armv8r",
-"armv8-m.base", "armv8m.base", "armv8-m.main",   "armv8m.main", "iwmmxt",
-"iwmmxt2",  "xscale",  "armv8.1-m.main", "armv9-a", "armv9",
-"armv9a",   "armv9.1-a",   "armv9.1a",   "armv9.2-a",   "armv9.2a",
+"armv8.7a", "armv8.8-a",   "armv8.8a",   "armv8.9-a",   "armv8.9a",
+"armv8-r",  "armv8r",  "armv8-m.base",   "armv8m.base", "armv8-m.main",
+"armv8m.main",  "iwmmxt",  "iwmmxt2","xscale",  "armv8.1-m.main",
+"armv9-a",  "armv9",   "armv9a", "armv9.1-a",   "armv9.1a",
+"armv9.2-a","armv9.2a","armv9.3-a",  "armv9.3a","armv9.4-a",
+"armv9.4a",
 };
 
 template 
@@ -510,6 +512,9 @@
   ARMBuildAttrs::CPUArch::v8_A));
   EXPECT_TRUE(testARMArch("armv8.8-a", "generic", "v8.8a",
   ARMBuildAttrs::CPUArch::v8_A));
+  EXPECT_TRUE(
+  testARMArch("armv8.9-a", "generic", "v8.9a",
+  ARMBuildAttrs::CPUArch::v8_A));
   EXPECT_TRUE(
   testARMArch("armv9-a", "generic", "v9a",
   ARMBuildAttrs::CPUArch::v9_A));
@@ -522,6 +527,9 @@
   EXPECT_TRUE(
   testARMArch("armv9.3-a", "generic", "v9.3a",
   ARMBuildAttrs::CPUArch::v9_A));
+  EXPECT_TRUE(
+  testARMArch("armv9.4-a", "generic", "v9.4a",
+  ARMBuildAttrs::CPUArch::v9_A));
   EXPECT_TRUE(
   testARMArch("armv8-r", "cortex-r52", "v8r",
   ARMBuildAttrs::CPUArch::v8_R));
@@ -852,10 +860,12 @@
 case ARM::ArchKind::ARMV8_6A:
 case ARM::ArchKind::ARMV8_7A:
 case ARM::ArchKind::ARMV8_8A:
+case ARM::ArchKind::ARMV8_9A:
 case ARM::ArchKind::ARMV9A:
 case ARM::ArchKind::ARMV9_1A:
 case ARM::ArchKind::ARMV9_2A:
 case ARM::ArchKind::ARMV9_3A:
+case ARM::ArchKind::ARMV9_4A:
   EXPECT_EQ(ARM::ProfileKind::A, ARM::parseArchProfile(ARMArch[i]));
   break;
 default:
@@ -1422,12 +1432,18 @@
   ARMBuildAttrs::CPUArch::v8_A));
   EXPECT_TRUE(testAArch64Arch("armv8.8-a", "generic", "v8.8a",
   ARMBuildAttrs::CPUArch::v8_A));
+  EXPECT_TRUE(testAArch64Arch("armv8.9-a", "generic", "v8.9a",
+  ARMBuildAttrs::CPUArch::v8_A));
   EXPECT_TRUE(testAArch64Arch("armv9-a", "generic", "v9a",
   ARMBuildAttrs::CPUArch::v8_A));
   EXPECT_TRUE(testAArch64Arch("armv9.1-a", "generic", "v9.1a",
   ARMBuildAttrs::CPUArch::v8_A));
   EXPECT_TRUE(testAArch64Arch("armv9.2-a", "generic", "v9.2a",
   ARMBuildAttrs::CPUArch::v8_A));
+  EXPECT_TRUE(testAArch64Arch("armv9.3-a", "generic", "v9.3a",
+  ARMBuildAttrs::CPUArch::v8_A));
+  EXPECT_TRUE(testAArch64Arch("armv9.4-a", "generic", "v9.4a",
+  ARMBuildAttrs::CPUArch::v8_A));
 }
 
 bool testAArch64Extension(StringRef CPUName, AArch64::ArchKind AK,
Index: llvm/lib/Target/ARM/MCTargetDesc/ARMELFStreamer.cpp
===
--- llvm/lib/Target/ARM/MCTargetDesc/

[PATCH] D136809: [CMake] Ensure `CLANG_RESOURCE_DIR` is respected

[LJC via Phabricator via cfe-commits]

paperchalice added a comment.

Ping @Ericson2314


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136809

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

[PATCH] D136940: [clang][Driver] allow tilde in user config dir

[LJC via Phabricator via cfe-commits]

paperchalice added a comment.

Ping @MaskRay


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136940

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

[PATCH] D138109: [clang] Fix -fp-model={strict|precise} to disable -fapprox-func

[KAWASHIMA Takahiro via Phabricator via cfe-commits]

kawashima-fj created this revision.
kawashima-fj added reviewers: masoud.ataei, zahiraam.
kawashima-fj added a project: clang.
Herald added a project: All.
kawashima-fj requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.

`-fapprox-func` should be disabled by `-fp-model={strict|precise}`, as well as 
other fast-math flags. See the last changes in `clang/test/Driver/fp-model.c`.

Probably this route (`case options::OPT_ffp_model_EQ`) was forgot to update in 
D106191  and D114564 
. There is no appropriate reason not to 
disable the flag.

This commit also updates other regression tests, which are not directly related 
to this bug, for consistency with other fast-math flags.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D138109

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/fp-options-to-fast-math-flags.c
  clang/test/Driver/fast-math.c
  clang/test/Driver/fp-model.c

Index: clang/test/Driver/fp-model.c
===
--- clang/test/Driver/fp-model.c
+++ clang/test/Driver/fp-model.c
@@ -66,6 +66,10 @@
 // RUN:   | FileCheck --check-prefix=WARN10 %s
 // WARN10: warning: overriding '-ffp-model=strict' option with '-fdenormal-fp-math=preserve-sign,preserve-sign' [-Woverriding-t-option]
 
+// RUN: %clang -### -ffp-model=strict -fapprox-func -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=WARN11 %s
+// WARN11: warning: overriding '-ffp-model=strict' option with '-fapprox-func' [-Woverriding-t-option]
+
 // RUN: %clang -### -c %s 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-NOROUND %s
 // CHECK-NOROUND: "-cc1"
@@ -86,6 +90,7 @@
 // CHECK-FPM-FAST: "-cc1"
 // CHECK-FPM-FAST: "-menable-no-infs"
 // CHECK-FPM-FAST: "-menable-no-nans"
+// CHECK-FPM-FAST: "-fapprox-func"
 // CHECK-FPM-FAST: "-funsafe-math-optimizations"
 // CHECK-FPM-FAST: "-fno-signed-zeros"
 // CHECK-FPM-FAST: "-mreassociate"
@@ -126,3 +131,32 @@
 // CHECK-FEB-IGNORE: "-fno-rounding-math"
 // CHECK-FEB-IGNORE: "-ffp-exception-behavior=ignore"
 
+// RUN: %clang -### -nostdinc -ffast-math -ffp-model=precise -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FASTMATH-FPM-PRECISE %s
+// CHECK-FASTMATH-FPM-PRECISE: "-cc1"
+// CHECK-FASTMATH-FPM-PRECISE-NOT: "-menable-no-infs"
+// CHECK-FASTMATH-FPM-PRECISE-NOT: "-menable-no-nans"
+// CHECK-FASTMATH-FPM-PRECISE-NOT: "-fapprox-func"
+// CHECK-FASTMATH-FPM-PRECISE-NOT: "-funsafe-math-optimizations"
+// CHECK-FASTMATH-FPM-PRECISE-NOT: "-fno-signed-zeros"
+// CHECK-FASTMATH-FPM-PRECISE-NOT: "-mreassociate"
+// CHECK-FASTMATH-FPM-PRECISE-NOT: "-freciprocal-math"
+// CHECK-FASTMATH-FPM-PRECISE: "-ffp-contract=on"
+// CHECK-FASTMATH-FPM-PRECISE: "-fno-rounding-math"
+// CHECK-FASTMATH-FPM-PRECISE-NOT: "-ffast-math"
+// CHECK-FASTMATH-FPM-PRECISE-NOT: "-ffinite-math-only"
+
+// RUN: %clang -### -nostdinc -ffast-math -ffp-model=strict -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FASTMATH-FPM-STRICT %s
+// CHECK-FASTMATH-FPM-STRICT: "-cc1"
+// CHECK-FASTMATH-FPM-STRICT-NOT: "-menable-no-infs"
+// CHECK-FASTMATH-FPM-STRICT-NOT: "-menable-no-nans"
+// CHECK-FASTMATH-FPM-STRICT-NOT: "-fapprox-func"
+// CHECK-FASTMATH-FPM-STRICT-NOT: "-funsafe-math-optimizations"
+// CHECK-FASTMATH-FPM-STRICT-NOT: "-fno-signed-zeros"
+// CHECK-FASTMATH-FPM-STRICT-NOT: "-mreassociate"
+// CHECK-FASTMATH-FPM-STRICT-NOT: "-freciprocal-math"
+// CHECK-FASTMATH-FPM-STRICT: "-ffp-contract=off"
+// CHECK-FASTMATH-FPM-STRICT-NOT: "-fno-rounding-math"
+// CHECK-FASTMATH-FPM-STRICT-NOT: "-ffast-math"
+// CHECK-FASTMATH-FPM-STRICT-NOT: "-ffinite-math-only"
Index: clang/test/Driver/fast-math.c
===
--- clang/test/Driver/fast-math.c
+++ clang/test/Driver/fast-math.c
@@ -91,6 +91,16 @@
 // CHECK-APPROX-FUNC: "-cc1"
 // CHECK-APPROX-FUNC: "-fapprox-func"
 //
+// RUN: %clang -### -fno-fast-math -fapprox-func -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-NO-FAST-MATH-APPROX-FUNC %s
+// CHECK-NO-FAST-MATH-APPROX-FUNC: "-cc1"
+// CHECK-NO-FAST-MATH-APPROX-FUNC: "-fapprox-func"
+//
+// RUN: %clang -### -fapprox-func -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-APPROX-FUNC-NO-FAST-MATH %s
+// CHECK-APPROX-FUNC-NO-FAST-MATH: "-cc1"
+// CHECK-APPROX-FUNC-NO-FAST-MATH-NOT: "-fapprox-func"
+//
 // RUN: %clang -### -fmath-errno -c %s 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-MATH-ERRNO %s
 // CHECK-MATH-ERRNO: "-cc1"
Index: clang/test/CodeGen/fp-options-to-fast-math-flags.c
===
--- clang/test/CodeGen/fp-options-to-fast-math-flags.c
+++ clang/test/CodeGen/fp-options-to-fast-math-flags.c
@@ -5,6 +5,7 @@
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown -fno-signed-zeros -emit-llvm -o - %s | FileCheck -check-prefix CHECK-NO-SIGNED-ZEROS %s
 // RUN: %clang_c

[PATCH] D138109: [clang] Fix -fp-model={strict|precise} to disable -fapprox-func

[KAWASHIMA Takahiro via Phabricator via cfe-commits]

kawashima-fj added a comment.

I found some errors in Clang Compiler User’s Manual 
. I will update of the Manual in 
another patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138109

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

[PATCH] D138047: Fix use of dangling stack allocated string in IncludeFixer

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added a comment.

yeah unfortunately testing this is hard, but bug&fix are obvious so it's fine 
to land without a test.

but i think we should rather fix the broken call site at 
clang-tools-extra/clangd/ParsedAST.cpp and move `BuildDir` to outer scope where 
it'll outlive IncludeFixer (~line 468).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138047

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

[PATCH] D136940: [clang][Driver] allow tilde in user config dir

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

mgorny added a comment.

Ah, I'm sorry for the delay. I have time right now, so I'll test and push it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136940

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

[PATCH] D137817: [clangd] Improve action `RemoveUsingNamespace` for user-defined literals

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added a comment.

thanks for pinging @tom-anders , i've added some concerns about the behaviour 
in general. sorry if these are discussed somewhere else but i've missed.




Comment at: 
clang-tools-extra/clangd/unittests/tweaks/RemoveUsingNamespaceTests.cpp:294
+}
+using namespace ns1::ns2;
+using namespace ns1::ns3;

sorry i am having trouble understanding why we are:
- only handling user defined literals from inline namespaces and not others?
- producing using directives and not using declarations
- inserting these at top level rather than where the usage is


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137817

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

[PATCH] D137919: [clangd] use fine-grained code action kinds

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added a comment.

as discussed in 
https://github.com/clangd/clangd/issues/1326#issuecomment-1313502572, we've 
decided to not move forward with the change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137919

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

[PATCH] D137712: Correctly handle Substitution failure in concept specialization.

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added a comment.

We discussed this with Utkarsh offline, he's OOO for some time, so I wanted to 
leave the summary here.
This patch attempts to attack the problem by keeping the information about 
substitution failure in template arguments of `ConceptSpecializationExpr`.
However, it seems that the standard does not give any special treatment to 
those as compared to other forms of substitution failure and we should rethink 
our approach. The problem seems to be in how we evaluate SFINAE inside 
`requires-expression` and/or `nested-requirement`.

E.g. if we replace a concept by a template variable, a failure to substitute 
template arguments should **not** cause the whole `requires-expression` to 
evaluate to false:

  template  constexpr bool true_v = true; 
  template  constexpr int foo() requires requires { requires 
true_v || true_v; }
  { return 123; }
  
  static_assert(foo() == 123);

GCC and MSVC succeed here, Clang fails: https://gcc.godbolt.org/z/WGdKWYM7e. 
Clang's behavior seems to be non-standard here.
The proper fix seems to be changing Clang behavior so that the 
`requires-expression` evaluates to true despite its first branch having a 
subsitution failure.

Utkarsh has also found an interesting example where GCC (IMO, unexpectedly) 
evaluates the concept to true despite a substitution failure in its template 
arguments:

  template  concept true_c = true; 
  template  constexpr int foo() 
  requires requires { requires true_c; }
  { return 123; }
  
  static_assert(foo() == 123);

Clang and MSVC fail here, GCC succeeds: https://gcc.godbolt.org/z/5qYjcW75q. 
The standard does not seem to be very clear here. It says that an "atomic 
constraint" that we must evaluate contains both an expression (`true`) and a 
template parameter mapping (`U -> typename T::type`, where `T` is `int`). The 
template parameter mapping is clearly not well-formed, the expression still 
evaluates to `true` and the standard does not seem to mention what to do when 
template parameter mapping is not well-formed. IMO, to form the template 
parameter mapping we must substitute `T -> int` into the template argument list 
(``) and at that point we see a substitution failure, hence 
`requires-expression` should evaluate to `false`. Someone should probably raise 
this with WG21 to know for sure.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137712

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

[PATCH] D138091: [Clang] Fix Sema::ClassifyName so that it classifies EnumConstantDecl as NonType when they are brought into scope via using enum

[Nathan Sidwell via Phabricator via cfe-commits]

urnathan added a comment.

Thanks, I didn;'t know about ClassifyName, and obviously never hit a need to 
adjust it.  Thanks for fixing.

The comment above says we don't resolve member-access non-overload sets in 
order to check access.  Do we still get that right for, say,

  class B {
   enum A {E}; 
   static auto F (B *p) { return p->E;} // ok
  };
  auto F (B *p) { return p->E; } // not ok

If so, I guess that comment's not right (any more).


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

https://reviews.llvm.org/D138091

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

[PATCH] D138115: [clang] Short-circuit evaluation in ::EvaluateAsConstantExpr

[Timm Bäder via Phabricator via cfe-commits]

tbaeder created this revision.
tbaeder added reviewers: aaron.ballman, erichkeane.
Herald added a project: All.
tbaeder requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This adds another case to `FastEvaluateAsRValue()` for boolean expressions as 
well as calls `FastEvaluateAsRValue()` in `Expr::EvaluateAsConstantExpr()` as 
well.

This way we can short-circuit evaluating simple integer and boolean literals 
here.

I don't have before/after numbers for compilation times, since my local builds 
have asan enabled (so valgrind doesn't work) and I lost access to the my 
asan-less build. But it shouldn't be worse than before... right?

Sorry, can't find better reviewers to add.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D138115

Files:
  clang/lib/AST/ExprConstant.cpp


Index: clang/lib/AST/ExprConstant.cpp
===
--- clang/lib/AST/ExprConstant.cpp
+++ clang/lib/AST/ExprConstant.cpp
@@ -15056,6 +15056,12 @@
 return true;
   }
 
+  if (const auto *L = dyn_cast(Exp)) {
+Result.Val = APValue(APSInt(APInt(1, L->getValue(;
+IsConst = true;
+return true;
+  }
+
   // This case should be rare, but we need to check it before we check on
   // the type below.
   if (Exp->getType().isNull()) {
@@ -15240,6 +15246,9 @@
   ConstantExprKind Kind) const {
   assert(!isValueDependent() &&
  "Expression evaluator can't be called on a dependent expression.");
+  bool IsConst;
+  if (FastEvaluateAsRValue(this, Result, Ctx, IsConst))
+return true;
 
   ExprTimeTraceScope TimeScope(this, Ctx, "EvaluateAsConstantExpr");
   EvalInfo::EvaluationMode EM = EvalInfo::EM_ConstantExpression;


Index: clang/lib/AST/ExprConstant.cpp
===
--- clang/lib/AST/ExprConstant.cpp
+++ clang/lib/AST/ExprConstant.cpp
@@ -15056,6 +15056,12 @@
 return true;
   }
 
+  if (const auto *L = dyn_cast(Exp)) {
+Result.Val = APValue(APSInt(APInt(1, L->getValue(;
+IsConst = true;
+return true;
+  }
+
   // This case should be rare, but we need to check it before we check on
   // the type below.
   if (Exp->getType().isNull()) {
@@ -15240,6 +15246,9 @@
   ConstantExprKind Kind) const {
   assert(!isValueDependent() &&
  "Expression evaluator can't be called on a dependent expression.");
+  bool IsConst;
+  if (FastEvaluateAsRValue(this, Result, Ctx, IsConst))
+return true;
 
   ExprTimeTraceScope TimeScope(this, Ctx, "EvaluateAsConstantExpr");
   EvalInfo::EvaluationMode EM = EvalInfo::EM_ConstantExpression;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D138117: [clang][docs] Correct floating point option explanations

[KAWASHIMA Takahiro via Phabricator via cfe-commits]

kawashima-fj created this revision.
kawashima-fj added reviewers: zahiraam, andrew.w.kaylor.
kawashima-fj added a project: clang.
Herald added a project: All.
kawashima-fj requested review of this revision.
Herald added a subscriber: cfe-commits.

Explanations for options of floating point are updated to match the 
`RenderFloatingPointOptions` function in 
`clang/lib/Driver/ToolChains/Clang.cpp`.

Missing explanations are also added.

This patch is based on D138088 , and assumes 
D138109  will be accepted.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D138117

Files:
  clang/docs/UsersManual.rst

Index: clang/docs/UsersManual.rst
===
--- clang/docs/UsersManual.rst
+++ clang/docs/UsersManual.rst
@@ -1431,21 +1431,15 @@
This option implies:
 
* ``-fno-honor-infinities``
-
* ``-fno-honor-nans``
-
+   * ``-fapprox-func``
* ``-fno-math-errno``
-
* ``-ffinite-math-only``
-
* ``-fassociative-math``
-
* ``-freciprocal-math``
-
* ``-fno-signed-zeros``
-
* ``-fno-trapping-math``
-
+   * ``-fno-rounding-math``
* ``-ffp-contract=fast``
 
Note: ``-ffast-math`` causes ``crtfastmath.o`` to be linked with code. See
@@ -1454,30 +1448,24 @@
 .. option:: -fno-fast-math
 
Disable fast-math mode.  This options disables unsafe floating-point
-   optimizations by preventing the compiler from making any tranformations that
+   optimizations by preventing the compiler from making any transformations that
could affect the results.
 
This option implies:
 
* ``-fhonor-infinities``
-
* ``-fhonor-nans``
-
-   * ``-fmath-errno``
-
+   * ``-fno-approx-func``
* ``-fno-finite-math-only``
-
* ``-fno-associative-math``
-
* ``-fno-reciprocal-math``
-
* ``-fsigned-zeros``
-
-   * ``-fno-trapping-math``
-
* ``-ffp-contract=on``
 
-   * ``-fdenormal-fp-math=ieee``
+   Also, this option resets following options to their target-dependent defaults.
+
+   * ``-f[no-]math-errno``
+   * ``-fdenormal-fp-math=``
 
There is ambiguity about how ``-ffp-contract``, ``-ffast-math``,
and ``-fno-fast-math`` behave in combination. To keep the value of
@@ -1513,7 +1501,8 @@
* ``preserve-sign`` - the sign of a flushed-to-zero number is preserved in the sign of 0
* ``positive-zero`` - denormals are flushed to positive zero
 
-   Defaults to ``ieee``.
+   The default value depends on the target. For most targets, defaults to
+   ``ieee``.
 
 .. option:: -f[no-]strict-float-cast-overflow
 
@@ -1522,6 +1511,7 @@
By default, Clang will not guarantee any particular result in that case.
With the 'no-strict' option, Clang will saturate towards the smallest and
largest representable integer values instead. NaNs will be converted to zero.
+   Defaults to ``-fstrict-float-cast-overflow``.
 
 .. option:: -f[no-]math-errno
 
@@ -1569,11 +1559,19 @@
 
 .. option:: -f[no-]honor-infinities
 
+   Allow floating-point optimizations that assume arguments and results are
+   not +-Inf.
+   Defaults to ``-fhonor-infinities``.
+
If both ``-fno-honor-infinities`` and ``-fno-honor-nans`` are used,
has the same effect as specifying ``-ffinite-math-only``.
 
 .. option:: -f[no-]honor-nans
 
+   Allow floating-point optimizations that assume arguments and results are
+   not NaNs.
+   Defaults to ``-fhonor-nans``.
+
If both ``-fno-honor-infinities`` and ``-fno-honor-nans`` are used,
has the same effect as specifying ``-ffinite-math-only``.
 
@@ -1589,7 +1587,7 @@
 .. option:: -f[no-]signed-zeros
 
Allow optimizations that ignore the sign of floating point zeros.
-   Defaults to ``-fno-signed-zeros``.
+   Defaults to ``-fsigned-zeros``.
 
 .. option:: -f[no-]associative-math
 
@@ -1605,24 +1603,48 @@
 
 .. option:: -f[no-]unsafe-math-optimizations
 
-   Allow unsafe floating-point optimizations. Also implies:
+   Allow unsafe floating-point optimizations.
+   ``-funsafe-math-optimizations`` also implies:
 
+   * ``-fapprox-func``
* ``-fassociative-math``
* ``-freciprocal-math``
* ``-fno-signed-zeroes``
-   * ``-fno-trapping-math``.
+   * ``-fno-trapping-math``
+   * ``-ffp-contract=fast``
+
+   ``-fno-unsafe-math-optimizations`` implies:
+
+   * ``-fno-approx-func``
+   * ``-fno-associative-math``
+   * ``-fno-reciprocal-math``
+   * ``-fsigned-zeroes``
+   * ``-ftrapping-math``
+   * ``-ffp-contract=on``
+   * ``-fdenormal-fp-math=ieee``
+
+   There is ambiguity about how ``-ffp-contract``,
+   ``-funsafe-math-optimizations``, and ``-fno-unsafe-math-optimizations``
+   behave in combination. Explanation in :option:`-fno-fast-math` also applies
+   to these options.
 
Defaults to ``-fno-unsafe-math-optimizations``.
 
 .. option:: -f[no-]finite-math-only
 
Allow floating-point optimizations that assume arguments and results are
-   not NaNs or +-Inf.  This defines the ``__FINITE_MATH_ONLY__``

[PATCH] D137531: [clang] Add the check of membership in decltype for the issue #58674

[Liming Liu via Phabricator via cfe-commits]

lime updated this revision to Diff 475768.

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

https://reviews.llvm.org/D137531

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Sema/SemaExpr.cpp
  clang/test/SemaCXX/decltype.cpp

Index: clang/test/SemaCXX/decltype.cpp
===
--- clang/test/SemaCXX/decltype.cpp
+++ clang/test/SemaCXX/decltype.cpp
@@ -101,6 +101,44 @@
   template void foo(decltype(T(LP1{ .p1 = g1, .p1.x[1] = 'x' }))) {}
 }
 
+namespace GH58674 {
+  struct Foo {
+float value_;
+struct nested {
+  float value_;
+};
+  };
+
+  template 
+  struct TemplateFoo {
+float value_;
+  };
+
+  float bar;
+
+  template 
+  struct Animal{};
+
+  template 
+  class Cat : Animal {
+using okay = decltype(Foo::value_);
+using also_okay = decltype(bar);
+using okay2 = decltype(Foo::nested::value_);
+using okay3 = decltype(TemplateFoo::value_);
+  public:
+void meow() {
+  using okay = decltype(Foo::value_);
+  using also_okay = decltype(bar);
+  using okay2 = decltype(Foo::nested::value_);
+  using okay3 = decltype(TemplateFoo::value_);
+}
+  };
+
+  void baz() {
+  Cat{}.meow();
+  }
+}
+
 template
 class conditional {
 };
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -2692,20 +2692,34 @@
   // to get this right here so that we don't end up making a
   // spuriously dependent expression if we're inside a dependent
   // instance method.
+  //
+  // We also don't need to do this if R resolved to a member in another
+  // class, which can happen in an unevaluated operand:
+  //
+  // C++ [expr.prim.id]p3.3:
+  //   If that id-expression denotes a non-static data member and it
+  //   appears in an unevaluated operand.
   if (!R.empty() && (*R.begin())->isCXXClassMember()) {
-bool MightBeImplicitMember;
-if (!IsAddressOfOperand)
-  MightBeImplicitMember = true;
-else if (!SS.isEmpty())
-  MightBeImplicitMember = false;
-else if (R.isOverloadedResult())
-  MightBeImplicitMember = false;
-else if (R.isUnresolvableResult())
-  MightBeImplicitMember = true;
-else
-  MightBeImplicitMember = isa(R.getFoundDecl()) ||
-  isa(R.getFoundDecl()) ||
-  isa(R.getFoundDecl());
+bool MightBeImplicitMember = true, CheckField = true;
+if (IsAddressOfOperand) {
+  MightBeImplicitMember = SS.isEmpty() && !R.isOverloadedResult();
+  CheckField = !R.isUnresolvableResult();
+}
+if (MightBeImplicitMember && CheckField) {
+  if (R.isSingleResult() &&
+  isa(R.getFoundDecl())) {
+auto Class = cast((*R.begin())->getDeclContext());
+for (auto Curr = S->getLookupEntity(); Curr && !Curr->isFileContext();
+ Curr = Curr->getParent()) {
+  if (auto ThisClass = dyn_cast_if_present(Curr)) {
+if ((MightBeImplicitMember = ThisClass->Equals(Class) ||
+ ThisClass->isDerivedFrom(Class)))
+  break;
+  }
+}
+  } else if (IsAddressOfOperand)
+MightBeImplicitMember = false;
+}
 
 if (MightBeImplicitMember)
   return BuildPossibleImplicitMemberExpr(SS, TemplateKWLoc,
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -298,6 +298,9 @@
   and Clang 15 accidentally stopped predeclaring those functions in that
   language mode. Clang 16 now predeclares those functions again. This fixes
   `Issue 56607 `_.
+- Fix an issue about ``decltype`` in the members of class templates derived from
+  templates with related parameters.
+  `Issue 58674 `_
 
 Improvements to Clang's diagnostics
 ^^^
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D138117: [clang][docs] Correct floating point option explanations

[KAWASHIMA Takahiro via Phabricator via cfe-commits]

kawashima-fj added a comment.

I don't know it is inteded that `-fno-fast-math` does not imply 
`-ftrapping-math` and `-frounding-math`.
`-ffast-math` and `-fno-fast-math` is not symmetric in 
RenderFloatingPointOptions 
.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138117

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

[clang] b3f94fe - [clang][Driver] allow tilde in user config dir

[Michał Górny via cfe-commits]

Author: Michał Górny
Date: 2022-11-16T13:23:25+01:00
New Revision: b3f94fe1c3c4f4fd7a937288b5543c4067b3e2f2

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

LOG: [clang][Driver] allow tilde in user config dir

This patch allows users to configure clang with option
e.g. `-DCLANG_CONFIG_FILE_USER_DIR=~/.config/clang` or invoke clang
with `--config-user-dir=~/.config/clang`.

Patch merged on behalf of @paperchalice (LJC)

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

Added: 


Modified: 
clang/lib/Driver/Driver.cpp
clang/test/Driver/config-file3.c

Removed: 




diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index c63160e55ea3..b6f6122ff40a 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -220,7 +220,11 @@ Driver::Driver(StringRef ClangExecutable, StringRef 
TargetTriple,
   SystemConfigDir = CLANG_CONFIG_FILE_SYSTEM_DIR;
 #endif
 #if defined(CLANG_CONFIG_FILE_USER_DIR)
-  UserConfigDir = CLANG_CONFIG_FILE_USER_DIR;
+  {
+SmallString<128> P;
+llvm::sys::fs::expand_tilde(CLANG_CONFIG_FILE_USER_DIR, P);
+UserConfigDir = static_cast(P);
+  }
 #endif
 
   // Compute the path to the resource directory.
@@ -1008,8 +1012,8 @@ bool Driver::loadConfigFiles() {
 }
 if (CLOptions->hasArg(options::OPT_config_user_dir_EQ)) {
   SmallString<128> CfgDir;
-  CfgDir.append(
-  CLOptions->getLastArgValue(options::OPT_config_user_dir_EQ));
+  llvm::sys::fs::expand_tilde(
+  CLOptions->getLastArgValue(options::OPT_config_user_dir_EQ), CfgDir);
   if (CfgDir.empty() || getVFS().makeAbsolute(CfgDir))
 UserConfigDir.clear();
   else

diff  --git a/clang/test/Driver/config-file3.c 
b/clang/test/Driver/config-file3.c
index 5f712020e79f..7bd86a2ae9dc 100644
--- a/clang/test/Driver/config-file3.c
+++ b/clang/test/Driver/config-file3.c
@@ -221,3 +221,8 @@
 //
 // RUN: rm %t/testdmode/clang-g++.cfg
 // RUN: %t/testdmode/x86_64-unknown-linux-gnu-clang-g++ --config-system-dir= 
--config-user-dir= -no-canonical-prefixes --version 2>&1 | FileCheck %s 
-check-prefix NO-CONFIG
+
+//--- Tilde expansion in user configuration file directory
+//
+// RUN: HOME=%S/Inputs/config %clang --config-user-dir=~ -v 2>&1 | FileCheck 
%s -check-prefix CHECK-TILDE
+// CHECK-TILDE: User configuration file directory: {{.*}}/Inputs/config



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

[PATCH] D136940: [clang][Driver] allow tilde in user config dir

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

This revision was automatically updated to reflect the committed changes.
Closed by commit rGb3f94fe1c3c4: [clang][Driver] allow tilde in user config dir 
(authored by mgorny).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136940

Files:
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/config-file3.c


Index: clang/test/Driver/config-file3.c
===
--- clang/test/Driver/config-file3.c
+++ clang/test/Driver/config-file3.c
@@ -221,3 +221,8 @@
 //
 // RUN: rm %t/testdmode/clang-g++.cfg
 // RUN: %t/testdmode/x86_64-unknown-linux-gnu-clang-g++ --config-system-dir= 
--config-user-dir= -no-canonical-prefixes --version 2>&1 | FileCheck %s 
-check-prefix NO-CONFIG
+
+//--- Tilde expansion in user configuration file directory
+//
+// RUN: HOME=%S/Inputs/config %clang --config-user-dir=~ -v 2>&1 | FileCheck 
%s -check-prefix CHECK-TILDE
+// CHECK-TILDE: User configuration file directory: {{.*}}/Inputs/config
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -220,7 +220,11 @@
   SystemConfigDir = CLANG_CONFIG_FILE_SYSTEM_DIR;
 #endif
 #if defined(CLANG_CONFIG_FILE_USER_DIR)
-  UserConfigDir = CLANG_CONFIG_FILE_USER_DIR;
+  {
+SmallString<128> P;
+llvm::sys::fs::expand_tilde(CLANG_CONFIG_FILE_USER_DIR, P);
+UserConfigDir = static_cast(P);
+  }
 #endif
 
   // Compute the path to the resource directory.
@@ -1008,8 +1012,8 @@
 }
 if (CLOptions->hasArg(options::OPT_config_user_dir_EQ)) {
   SmallString<128> CfgDir;
-  CfgDir.append(
-  CLOptions->getLastArgValue(options::OPT_config_user_dir_EQ));
+  llvm::sys::fs::expand_tilde(
+  CLOptions->getLastArgValue(options::OPT_config_user_dir_EQ), CfgDir);
   if (CfgDir.empty() || getVFS().makeAbsolute(CfgDir))
 UserConfigDir.clear();
   else


Index: clang/test/Driver/config-file3.c
===
--- clang/test/Driver/config-file3.c
+++ clang/test/Driver/config-file3.c
@@ -221,3 +221,8 @@
 //
 // RUN: rm %t/testdmode/clang-g++.cfg
 // RUN: %t/testdmode/x86_64-unknown-linux-gnu-clang-g++ --config-system-dir= --config-user-dir= -no-canonical-prefixes --version 2>&1 | FileCheck %s -check-prefix NO-CONFIG
+
+//--- Tilde expansion in user configuration file directory
+//
+// RUN: HOME=%S/Inputs/config %clang --config-user-dir=~ -v 2>&1 | FileCheck %s -check-prefix CHECK-TILDE
+// CHECK-TILDE: User configuration file directory: {{.*}}/Inputs/config
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -220,7 +220,11 @@
   SystemConfigDir = CLANG_CONFIG_FILE_SYSTEM_DIR;
 #endif
 #if defined(CLANG_CONFIG_FILE_USER_DIR)
-  UserConfigDir = CLANG_CONFIG_FILE_USER_DIR;
+  {
+SmallString<128> P;
+llvm::sys::fs::expand_tilde(CLANG_CONFIG_FILE_USER_DIR, P);
+UserConfigDir = static_cast(P);
+  }
 #endif
 
   // Compute the path to the resource directory.
@@ -1008,8 +1012,8 @@
 }
 if (CLOptions->hasArg(options::OPT_config_user_dir_EQ)) {
   SmallString<128> CfgDir;
-  CfgDir.append(
-  CLOptions->getLastArgValue(options::OPT_config_user_dir_EQ));
+  llvm::sys::fs::expand_tilde(
+  CLOptions->getLastArgValue(options::OPT_config_user_dir_EQ), CfgDir);
   if (CfgDir.empty() || getVFS().makeAbsolute(CfgDir))
 UserConfigDir.clear();
   else
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Paul Eggert via cfe-commits]

Can you cite any examples of a real-world security flaw what would be
found by Clang erroring out because 'char foo(void);' is the wrong
prototype? Is it plausible that any such security flaw exists?



CVE-2006-1174 is a possibly reasonable example.


CVE-2006-1174 is not an example, because no prototype 'char foo(void);' 
was involved.[1]


Here's a more concrete proposal that should allay any realistic concerns 
about CVEs. If Clang decides to change its behavior in this area, so 
that Clang starts to exit with nonzero status if the user declares a 
function with a prototype incompatible with the C library, it would be a 
service to real users if Clang merely issues a warning and does *not* 
error out if the declaration is 'char foo();' (current Autoconf) or 
'char foo(void);' (future Autoconf).


This may be a hack, but it's a *good* hack. It's likely to fix 
real-world bugs that would be caused if Clang becomes overly pedantic by 
default here. And the probability of introducing real-world bugs is 
essentially zero.




You can run into that same bug
with use of `-Werror`


That's OK, as the Autoconf documentation already says "don't do that". 
And if Clang exits with nonzero status in the above situation when 
-Werror is specified, that's fine too.



[1] CVE-2006-1174 is not even an example of prototype mismatch, as the 
bad C code did not misdeclare the function in question: it used a POSIX 
standard include file for the function prototype, which is the standard 
way to do things.



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

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Ben Boeckel via cfe-commits]

On Tue, Nov 15, 2022 at 15:09:19 -0800, Paul Eggert wrote:
> This may be a hack, but it's a *good* hack. It's likely to fix 
> real-world bugs that would be caused if Clang becomes overly pedantic by 
> default here. And the probability of introducing real-world bugs is 
> essentially zero.

FWIW, CMake uses the same signature for detecting whether a function
exists or not:


https://gitlab.kitware.com/cmake/cmake/-/blob/master/Modules/CheckFunctionExists.c

It's also been like this (without the `void`) for 20 years; the `void`
argument was added 6 years ago:


https://gitlab.kitware.com/cmake/cmake/-/commits/master/Modules/CheckFunctionExists.c

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

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Bob Friesenhahn via cfe-commits]

On Tue, 15 Nov 2022, Sam James wrote:





On 13 Nov 2022, at 00:43, Paul Eggert  wrote:

On 2022-11-11 07:11, Aaron Ballman wrote:

We believe the runtime behavior is sufficiently dangerous to
warrant a conservative view that any call to a function will be a call
that gets executed at runtime, hence a definitive signature mismatch
is something we feel comfortable diagnosing (in some form) by default.


As long as these diagnostics by default do not cause the compiler to exit with nonzero status, we 
should be OK with Autoconf-generated 'configure' scripts. Although there will be problems with 
people who run "./configure CFLAGS='-Werror'", that sort of usage has always been 
problematic and unsupported by Autoconf, so we can simply continue to tell people "don't do 
that".



Is there somewhere in the autoconf docs we actually say this?

I've seen a few instances of folks adding it themselves very
early in their configure scripts (which is a pain for distros
anyway) which then ends up affecting the rest.


Autoconf can help with this issue due to GCC and some other compilers 
providing extensions (usually a pragma) to control warnings while 
compiling the C code.  So configure can run without -Werror, but 
Autoconf could help by providing an easy way for enabling -Werror 
while compiling the application.


Of course the above does not require Autoconf since application 
developers can figure it out by themselves using preprocessor logic 
and knowledge of compiler-specific behavior.


If Autoconf is able to help, then the convoluted code can be in just 
one place (in Autoconf).


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D137817: [clangd] Improve action `RemoveUsingNamespace` for user-defined literals

[v1nh1shungry via Phabricator via cfe-commits]

v1nh1shungry added a comment.

@kadircet Thank you for reviewing and giving suggestions! Please check my reply 
to your concerns. Sorry if I misunderstood anything.




Comment at: 
clang-tools-extra/clangd/unittests/tweaks/RemoveUsingNamespaceTests.cpp:294
+}
+using namespace ns1::ns2;
+using namespace ns1::ns3;

kadircet wrote:
> sorry i am having trouble understanding why we are:
> - only handling user defined literals from inline namespaces and not others?
> - producing using directives and not using declarations
> - inserting these at top level rather than where the usage is
The first question:

Because others have already been handled. Say

```
namespace a { inline namespace b { void foobar(); } }
using namespace ^a;
int main() { foobar(); }
```

can become

```
namespace a { inline namespace b { void foobar(); } }

int main() { a::foobar(); }
```

But user-defined literals just can't add a qualifier, right?

---

The second question:

Yes, this is a good idea. I didn't realize we can use using-declarations 
instead of using-directives.

---

The last question:

Hmm, I think it is cleaner if there are multiple usages. Since we can only 
remove the using-directives at the top level, this doesn't hurt anything. And 
it is the easiest solution to implement as well :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137817

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

[PATCH] D138122: Lift EHPersonalities from Analysis to IR (NFC)

[Stefan Gränitz via Phabricator via cfe-commits]

sgraenitz created this revision.
sgraenitz added reviewers: rnk, efriedma, dblaikie, compnerd.
Herald added subscribers: Enna1, wenlei, pengfei, hiraditya.
Herald added a project: All.
sgraenitz requested review of this revision.
Herald added subscribers: cfe-commits, aheejin.
Herald added projects: clang, LLVM.

Computing EH-related information was only relevant for analysis passes so far. 
Lifting it to IR will allow the IR Verifier to calculate EH funclet coloring 
and validate funclet operand bundles in a follow-up step.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D138122

Files:
  clang/docs/tools/clang-formatted-files.txt
  llvm/include/llvm/Analysis/EHPersonalities.h
  llvm/include/llvm/Analysis/MustExecute.h
  llvm/include/llvm/CodeGen/MachineFunction.h
  llvm/include/llvm/IR/EHPersonalities.h
  llvm/lib/Analysis/CMakeLists.txt
  llvm/lib/Analysis/EHPersonalities.cpp
  llvm/lib/Analysis/ValueTracking.cpp
  llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
  llvm/lib/CodeGen/DwarfEHPrepare.cpp
  llvm/lib/CodeGen/MachineFunction.cpp
  llvm/lib/CodeGen/MachineVerifier.cpp
  llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
  llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp
  llvm/lib/CodeGen/StackProtector.cpp
  llvm/lib/CodeGen/WinEHPrepare.cpp
  llvm/lib/IR/CMakeLists.txt
  llvm/lib/IR/EHPersonalities.cpp
  llvm/lib/Target/M68k/M68kCollapseMOVEMPass.cpp
  llvm/lib/Target/M68k/M68kExpandPseudo.cpp
  llvm/lib/Target/X86/X86ExpandPseudo.cpp
  llvm/lib/Target/X86/X86FrameLowering.cpp
  llvm/lib/Target/X86/X86ISelLowering.cpp
  llvm/lib/Target/X86/X86WinEHState.cpp
  llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
  llvm/lib/Transforms/Instrumentation/GCOVProfiling.cpp
  llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp
  llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
  llvm/lib/Transforms/ObjCARC/ObjCARC.h
  llvm/lib/Transforms/ObjCARC/ObjCARCContract.cpp
  llvm/lib/Transforms/ObjCARC/ObjCARCOpts.cpp
  llvm/lib/Transforms/Utils/EscapeEnumerator.cpp
  llvm/lib/Transforms/Utils/InlineFunction.cpp
  llvm/lib/Transforms/Utils/Local.cpp
  llvm/utils/gn/secondary/llvm/lib/Analysis/BUILD.gn
  llvm/utils/gn/secondary/llvm/lib/IR/BUILD.gn

Index: llvm/utils/gn/secondary/llvm/lib/IR/BUILD.gn
===
--- llvm/utils/gn/secondary/llvm/lib/IR/BUILD.gn
+++ llvm/utils/gn/secondary/llvm/lib/IR/BUILD.gn
@@ -33,6 +33,7 @@
 "DiagnosticInfo.cpp",
 "DiagnosticPrinter.cpp",
 "Dominators.cpp",
+"EHPersonalities.cpp",
 "FPEnv.cpp",
 "Function.cpp",
 "GCStrategy.cpp",
Index: llvm/utils/gn/secondary/llvm/lib/Analysis/BUILD.gn
===
--- llvm/utils/gn/secondary/llvm/lib/Analysis/BUILD.gn
+++ llvm/utils/gn/secondary/llvm/lib/Analysis/BUILD.gn
@@ -50,7 +50,6 @@
 "DomPrinter.cpp",
 "DomTreeUpdater.cpp",
 "DominanceFrontier.cpp",
-"EHPersonalities.cpp",
 "FunctionPropertiesAnalysis.cpp",
 "GlobalsModRef.cpp",
 "GuardUtils.cpp",
Index: llvm/lib/Transforms/Utils/Local.cpp
===
--- llvm/lib/Transforms/Utils/Local.cpp
+++ llvm/lib/Transforms/Utils/Local.cpp
@@ -27,7 +27,7 @@
 #include "llvm/Analysis/AssumeBundleQueries.h"
 #include "llvm/Analysis/ConstantFolding.h"
 #include "llvm/Analysis/DomTreeUpdater.h"
-#include "llvm/Analysis/EHPersonalities.h"
+#include "llvm/IR/EHPersonalities.h"
 #include "llvm/Analysis/InstructionSimplify.h"
 #include "llvm/Analysis/MemoryBuiltins.h"
 #include "llvm/Analysis/MemorySSAUpdater.h"
Index: llvm/lib/Transforms/Utils/InlineFunction.cpp
===
--- llvm/lib/Transforms/Utils/InlineFunction.cpp
+++ llvm/lib/Transforms/Utils/InlineFunction.cpp
@@ -25,7 +25,7 @@
 #include "llvm/Analysis/BlockFrequencyInfo.h"
 #include "llvm/Analysis/CallGraph.h"
 #include "llvm/Analysis/CaptureTracking.h"
-#include "llvm/Analysis/EHPersonalities.h"
+#include "llvm/IR/EHPersonalities.h"
 #include "llvm/Analysis/InstructionSimplify.h"
 #include "llvm/Analysis/MemoryProfileInfo.h"
 #include "llvm/Analysis/ObjCARCAnalysisUtils.h"
Index: llvm/lib/Transforms/Utils/EscapeEnumerator.cpp
===
--- llvm/lib/Transforms/Utils/EscapeEnumerator.cpp
+++ llvm/lib/Transforms/Utils/EscapeEnumerator.cpp
@@ -13,7 +13,7 @@
 
 #include "llvm/Transforms/Utils/EscapeEnumerator.h"
 #include "llvm/ADT/Triple.h"
-#include "llvm/Analysis/EHPersonalities.h"
+#include "llvm/IR/EHPersonalities.h"
 #include "llvm/IR/Module.h"
 #include "llvm/Transforms/Utils/Local.h"
 
Index: llvm/lib/Transforms/ObjCARC/ObjCARCOpts.cpp
===
--- llvm/lib/Transforms/ObjCARC/ObjCARCOpts.cpp
+++ llvm/lib/Transforms/ObjCARC/ObjCARCOpts.cpp
@@ -37,7 +37,7 @@
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/ADT

[PATCH] D137960: [Lexer] Speedup LexTokenInternal

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM! FYI: there's still some unrelated formatting changes ;-)


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

https://reviews.llvm.org/D137960

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

[PATCH] D137817: [clangd] Improve action `RemoveUsingNamespace` for user-defined literals

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added inline comments.



Comment at: 
clang-tools-extra/clangd/unittests/tweaks/RemoveUsingNamespaceTests.cpp:294
+}
+using namespace ns1::ns2;
+using namespace ns1::ns3;

v1nh1shungry wrote:
> kadircet wrote:
> > sorry i am having trouble understanding why we are:
> > - only handling user defined literals from inline namespaces and not others?
> > - producing using directives and not using declarations
> > - inserting these at top level rather than where the usage is
> The first question:
> 
> Because others have already been handled. Say
> 
> ```
> namespace a { inline namespace b { void foobar(); } }
> using namespace ^a;
> int main() { foobar(); }
> ```
> 
> can become
> 
> ```
> namespace a { inline namespace b { void foobar(); } }
> 
> int main() { a::foobar(); }
> ```
> 
> But user-defined literals just can't add a qualifier, right?
> 
> ---
> 
> The second question:
> 
> Yes, this is a good idea. I didn't realize we can use using-declarations 
> instead of using-directives.
> 
> ---
> 
> The last question:
> 
> Hmm, I think it is cleaner if there are multiple usages. Since we can only 
> remove the using-directives at the top level, this doesn't hurt anything. And 
> it is the easiest solution to implement as well :)
> Because others have already been handled. Say

i was emphasizing on the difference between user defined literals inside inline 
namespaces, and user defined literals from regular namespaces. not other types 
of decls inside an inline namespace, eg:
```
namespace ns { long double operator"" _o(long double); }
```

we should also introduce a using-decl for `_o` despite it not being inside an 
inline namespace.



Comment at: 
clang-tools-extra/clangd/unittests/tweaks/RemoveUsingNamespaceTests.cpp:294
+}
+using namespace ns1::ns2;
+using namespace ns1::ns3;

kadircet wrote:
> v1nh1shungry wrote:
> > kadircet wrote:
> > > sorry i am having trouble understanding why we are:
> > > - only handling user defined literals from inline namespaces and not 
> > > others?
> > > - producing using directives and not using declarations
> > > - inserting these at top level rather than where the usage is
> > The first question:
> > 
> > Because others have already been handled. Say
> > 
> > ```
> > namespace a { inline namespace b { void foobar(); } }
> > using namespace ^a;
> > int main() { foobar(); }
> > ```
> > 
> > can become
> > 
> > ```
> > namespace a { inline namespace b { void foobar(); } }
> > 
> > int main() { a::foobar(); }
> > ```
> > 
> > But user-defined literals just can't add a qualifier, right?
> > 
> > ---
> > 
> > The second question:
> > 
> > Yes, this is a good idea. I didn't realize we can use using-declarations 
> > instead of using-directives.
> > 
> > ---
> > 
> > The last question:
> > 
> > Hmm, I think it is cleaner if there are multiple usages. Since we can only 
> > remove the using-directives at the top level, this doesn't hurt anything. 
> > And it is the easiest solution to implement as well :)
> > Because others have already been handled. Say
> 
> i was emphasizing on the difference between user defined literals inside 
> inline namespaces, and user defined literals from regular namespaces. not 
> other types of decls inside an inline namespace, eg:
> ```
> namespace ns { long double operator"" _o(long double); }
> ```
> 
> we should also introduce a using-decl for `_o` despite it not being inside an 
> inline namespace.
> Hmm, I think it is cleaner if there are multiple usages. Since we can only 
> remove the using-directives at the top level, this doesn't hurt anything. And 
> it is the easiest solution to implement as well :)

right, but introducing these at the top level will have unintended consequences 
(e.g. if this is a header, symbols will all of a sudden be visible in all the 
dependents).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137817

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

[PATCH] D138125: [clang] Fix wrong ABI on AVRTiny

[Ben Shi via Phabricator via cfe-commits]

benshi001 created this revision.
benshi001 added reviewers: aykevl, dylanmckay.
Herald added a subscriber: Jim.
Herald added a project: All.
benshi001 requested review of this revision.
Herald added subscribers: cfe-commits, jacquesguan.
Herald added a project: clang.

A scalar which exceeds 4 bytes should be returned
via a stack slot, on AVRTiny.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D138125

Files:
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/avr/struct.c


Index: clang/test/CodeGen/avr/struct.c
===
--- clang/test/CodeGen/avr/struct.c
+++ clang/test/CodeGen/avr/struct.c
@@ -33,12 +33,17 @@
   return a0;
 }
 
+long long fooi64(void) {
+  return 0xaa5533;
+}
+
 // AVR: %struct.s10 = type { i16, i16, i16, i16, i16 }
 // AVR: %struct.s06 = type { i16, i16, i16 }
 // AVR: %struct.s04 = type { i16, i16 }
 // AVR: define{{.*}} void @foo10(ptr {{.*}}, i16 noundef %a, i16 noundef %b, 
i16 noundef %c)
 // AVR: define{{.*}} %struct.s06 @foo06(i16 noundef %a, i16 noundef %b, i16 
noundef %c)
 // AVR: define{{.*}} %struct.s04 @foo04(i16 noundef %a, i16 noundef %b)
+// AVR: define{{.*}} i64 @fooi64()
 
 // TINY: %struct.s10 = type { i16, i16, i16, i16, i16 }
 // TINY: %struct.s06 = type { i16, i16, i16 }
@@ -46,3 +51,4 @@
 // TINY: define{{.*}} void @foo10(ptr {{.*}}, i16 noundef %a, i16 noundef %b, 
i16 noundef %c)
 // TINY: define{{.*}} void @foo06(ptr {{.*}}, i16 noundef %a, i16 noundef %b, 
i16 noundef %c)
 // TINY: define{{.*}} %struct.s04 @foo04(i16 noundef %a, i16 noundef %b)
+// TINY: define{{.*}} void @fooi64(ptr {{.*}})
Index: clang/lib/CodeGen/TargetInfo.cpp
===
--- clang/lib/CodeGen/TargetInfo.cpp
+++ clang/lib/CodeGen/TargetInfo.cpp
@@ -8339,15 +8339,16 @@
   : DefaultABIInfo(CGT), ParamRegs(NPR), RetRegs(NRR) {}
 
   ABIArgInfo classifyReturnType(QualType Ty, bool &LargeRet) const {
-if (isAggregateTypeForABI(Ty)) {
-  // On AVR, a return struct with size less than or equals to 8 bytes is
-  // returned directly via registers R18-R25. On AVRTiny, a return struct
-  // with size less than or equals to 4 bytes is returned directly via
-  // registers R22-R25.
-  if (getContext().getTypeSize(Ty) <= RetRegs * 8)
-return ABIArgInfo::getDirect();
-  // A return struct with larger size is returned via a stack
-  // slot, along with a pointer to it as the function's implicit argument.
+// On AVR, a return struct with size less than or equals to 8 bytes is
+// returned directly via registers R18-R25. On AVRTiny, a return struct
+// with size less than or equals to 4 bytes is returned directly via
+// registers R22-R25.
+if (isAggregateTypeForABI(Ty) &&
+getContext().getTypeSize(Ty) <= RetRegs * 8)
+  return ABIArgInfo::getDirect();
+// A return value (struct or scalar) with larger size is returned via a
+// stack slot, along with a pointer as the function's implicit argument.
+if (getContext().getTypeSize(Ty) > RetRegs * 8) {
   LargeRet = true;
   return getNaturalAlignIndirect(Ty);
 }


Index: clang/test/CodeGen/avr/struct.c
===
--- clang/test/CodeGen/avr/struct.c
+++ clang/test/CodeGen/avr/struct.c
@@ -33,12 +33,17 @@
   return a0;
 }
 
+long long fooi64(void) {
+  return 0xaa5533;
+}
+
 // AVR: %struct.s10 = type { i16, i16, i16, i16, i16 }
 // AVR: %struct.s06 = type { i16, i16, i16 }
 // AVR: %struct.s04 = type { i16, i16 }
 // AVR: define{{.*}} void @foo10(ptr {{.*}}, i16 noundef %a, i16 noundef %b, i16 noundef %c)
 // AVR: define{{.*}} %struct.s06 @foo06(i16 noundef %a, i16 noundef %b, i16 noundef %c)
 // AVR: define{{.*}} %struct.s04 @foo04(i16 noundef %a, i16 noundef %b)
+// AVR: define{{.*}} i64 @fooi64()
 
 // TINY: %struct.s10 = type { i16, i16, i16, i16, i16 }
 // TINY: %struct.s06 = type { i16, i16, i16 }
@@ -46,3 +51,4 @@
 // TINY: define{{.*}} void @foo10(ptr {{.*}}, i16 noundef %a, i16 noundef %b, i16 noundef %c)
 // TINY: define{{.*}} void @foo06(ptr {{.*}}, i16 noundef %a, i16 noundef %b, i16 noundef %c)
 // TINY: define{{.*}} %struct.s04 @foo04(i16 noundef %a, i16 noundef %b)
+// TINY: define{{.*}} void @fooi64(ptr {{.*}})
Index: clang/lib/CodeGen/TargetInfo.cpp
===
--- clang/lib/CodeGen/TargetInfo.cpp
+++ clang/lib/CodeGen/TargetInfo.cpp
@@ -8339,15 +8339,16 @@
   : DefaultABIInfo(CGT), ParamRegs(NPR), RetRegs(NRR) {}
 
   ABIArgInfo classifyReturnType(QualType Ty, bool &LargeRet) const {
-if (isAggregateTypeForABI(Ty)) {
-  // On AVR, a return struct with size less than or equals to 8 bytes is
-  // returned directly via registers R18-R25. On AVRTiny, a return struct
-  // with size less than or equals to 4 bytes is returned directly via
-  // registers R22-R25.
-  if (getCon

[PATCH] D138125: [clang] Fix wrong ABI on AVRTiny

[Ben Shi via Phabricator via cfe-commits]

benshi001 added inline comments.



Comment at: clang/test/CodeGen/avr/struct.c:37
+long long fooi64(void) {
+  return 0xaa5533;
+}

This file should be renamed to return.c instead of current struct.c, I will do 
that in another patch, just let you see clearly what I have changed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138125

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

[PATCH] D137751: Produce a more informative diagnostics when Clang runs out of source locations

[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! Please add a release note when landing so folks know about the 
improvements here. Thanks!




Comment at: clang/include/clang/Basic/SourceManager.h:1695-1696
+  // Produce notes describing the current source location address space usage.
+  void noteSLocAddressSpaceUsage(DiagnosticsEngine &Diag,
+ unsigned MaxNotes = 50) const;
+

rsmith wrote:
> aaron.ballman wrote:
> > Not that I'm opposed, but how did you arrive at 50?
> I was aiming for a number that's small enough that the diagnostic won't run 
> for pages (will fit into a relatively small scroll buffer) but large enough 
> that it should capture problematic usage.
> 
> But, you know what, we should be consistent. A default of 32 would match our 
> default limit for notes in constexpr and template backtraces; let's use that. 
> Plus powers of 2 are the best arbitrary numbers.
Thanks, that makes more sense! Someday (not today) we might want to consider 
making this a named constant and using it rather than magic numbers.



Comment at: clang/lib/Basic/SourceManager.cpp:675
   LocalSLocEntryTable.push_back(SLocEntry::get(NextLocalOffset, Info));
+  // TODO: Produce a proper diagnostic for this case.
   assert(NextLocalOffset + Length + 1 > NextLocalOffset &&

rsmith wrote:
> aaron.ballman wrote:
> > Are you planning to do this as part of this patch, or is this more of an 
> > aspirational FIXME for the future?
> This is aspirational. I think it'll be a lot of work to make all the 
> transitive callers of this be able to handle it failing.
SGTM, thanks!



Comment at: clang/lib/Lex/Pragma.cpp:1187
+  // specifically report information about.
+  uint64_t MaxNotes = (uint64_t)-1;
+  Token ArgToken;

rsmith wrote:
> aaron.ballman wrote:
> > `~0ULL`?
> That would be `(unsigned long long)-1`, which isn't necessarily the same 
> value.
> 
> But I think we can do better than forming a large unsigned number here; 
> changed to use `Optional`.
Even better! Thanks


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

https://reviews.llvm.org/D137751

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

[PATCH] D138125: [clang] Fix wrong ABI on AVRTiny

[Ayke via Phabricator via cfe-commits]

aykevl added inline comments.



Comment at: clang/test/CodeGen/avr/struct.c:37
+long long fooi64(void) {
+  return 0xaa5533;
+}

benshi001 wrote:
> This file should be renamed to return.c instead of current struct.c, I will 
> do that in another patch, just let you see clearly what I have changed.
You can do that in the same patch. Phabricator should detect the renamed file 
and display it just like it does now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138125

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

[PATCH] D137817: [clangd] Improve action `RemoveUsingNamespace` for user-defined literals

[v1nh1shungry via Phabricator via cfe-commits]

v1nh1shungry added a comment.

@kadircet Thank you for the excellent suggestions! Will dive into it to figure 
out the implementations.




Comment at: 
clang-tools-extra/clangd/unittests/tweaks/RemoveUsingNamespaceTests.cpp:294
+}
+using namespace ns1::ns2;
+using namespace ns1::ns3;

kadircet wrote:
> kadircet wrote:
> > v1nh1shungry wrote:
> > > kadircet wrote:
> > > > sorry i am having trouble understanding why we are:
> > > > - only handling user defined literals from inline namespaces and not 
> > > > others?
> > > > - producing using directives and not using declarations
> > > > - inserting these at top level rather than where the usage is
> > > The first question:
> > > 
> > > Because others have already been handled. Say
> > > 
> > > ```
> > > namespace a { inline namespace b { void foobar(); } }
> > > using namespace ^a;
> > > int main() { foobar(); }
> > > ```
> > > 
> > > can become
> > > 
> > > ```
> > > namespace a { inline namespace b { void foobar(); } }
> > > 
> > > int main() { a::foobar(); }
> > > ```
> > > 
> > > But user-defined literals just can't add a qualifier, right?
> > > 
> > > ---
> > > 
> > > The second question:
> > > 
> > > Yes, this is a good idea. I didn't realize we can use using-declarations 
> > > instead of using-directives.
> > > 
> > > ---
> > > 
> > > The last question:
> > > 
> > > Hmm, I think it is cleaner if there are multiple usages. Since we can 
> > > only remove the using-directives at the top level, this doesn't hurt 
> > > anything. And it is the easiest solution to implement as well :)
> > > Because others have already been handled. Say
> > 
> > i was emphasizing on the difference between user defined literals inside 
> > inline namespaces, and user defined literals from regular namespaces. not 
> > other types of decls inside an inline namespace, eg:
> > ```
> > namespace ns { long double operator"" _o(long double); }
> > ```
> > 
> > we should also introduce a using-decl for `_o` despite it not being inside 
> > an inline namespace.
> > Hmm, I think it is cleaner if there are multiple usages. Since we can only 
> > remove the using-directives at the top level, this doesn't hurt anything. 
> > And it is the easiest solution to implement as well :)
> 
> right, but introducing these at the top level will have unintended 
> consequences (e.g. if this is a header, symbols will all of a sudden be 
> visible in all the dependents).
You're right. Sorry for misunderstanding it.



Comment at: 
clang-tools-extra/clangd/unittests/tweaks/RemoveUsingNamespaceTests.cpp:294
+}
+using namespace ns1::ns2;
+using namespace ns1::ns3;

v1nh1shungry wrote:
> kadircet wrote:
> > kadircet wrote:
> > > v1nh1shungry wrote:
> > > > kadircet wrote:
> > > > > sorry i am having trouble understanding why we are:
> > > > > - only handling user defined literals from inline namespaces and not 
> > > > > others?
> > > > > - producing using directives and not using declarations
> > > > > - inserting these at top level rather than where the usage is
> > > > The first question:
> > > > 
> > > > Because others have already been handled. Say
> > > > 
> > > > ```
> > > > namespace a { inline namespace b { void foobar(); } }
> > > > using namespace ^a;
> > > > int main() { foobar(); }
> > > > ```
> > > > 
> > > > can become
> > > > 
> > > > ```
> > > > namespace a { inline namespace b { void foobar(); } }
> > > > 
> > > > int main() { a::foobar(); }
> > > > ```
> > > > 
> > > > But user-defined literals just can't add a qualifier, right?
> > > > 
> > > > ---
> > > > 
> > > > The second question:
> > > > 
> > > > Yes, this is a good idea. I didn't realize we can use 
> > > > using-declarations instead of using-directives.
> > > > 
> > > > ---
> > > > 
> > > > The last question:
> > > > 
> > > > Hmm, I think it is cleaner if there are multiple usages. Since we can 
> > > > only remove the using-directives at the top level, this doesn't hurt 
> > > > anything. And it is the easiest solution to implement as well :)
> > > > Because others have already been handled. Say
> > > 
> > > i was emphasizing on the difference between user defined literals inside 
> > > inline namespaces, and user defined literals from regular namespaces. not 
> > > other types of decls inside an inline namespace, eg:
> > > ```
> > > namespace ns { long double operator"" _o(long double); }
> > > ```
> > > 
> > > we should also introduce a using-decl for `_o` despite it not being 
> > > inside an inline namespace.
> > > Hmm, I think it is cleaner if there are multiple usages. Since we can 
> > > only remove the using-directives at the top level, this doesn't hurt 
> > > anything. And it is the easiest solution to implement as well :)
> > 
> > right, but introducing these at the top level will have unintended 
> > consequences (e.g. if this is a header, symbols will all of a sudden be 
> > visible in all the dependents).
> You're right. Sorry for misunderstanding 

[PATCH] D138125: [clang] Fix wrong ABI on AVRTiny

[Ben Shi via Phabricator via cfe-commits]

benshi001 updated this revision to Diff 475808.

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

https://reviews.llvm.org/D138125

Files:
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/avr/return-value.c
  clang/test/CodeGen/avr/struct.c


Index: clang/test/CodeGen/avr/return-value.c
===
--- clang/test/CodeGen/avr/return-value.c
+++ clang/test/CodeGen/avr/return-value.c
@@ -33,12 +33,17 @@
   return a0;
 }
 
+long long fooi64(void) {
+  return 0xaa5533;
+}
+
 // AVR: %struct.s10 = type { i16, i16, i16, i16, i16 }
 // AVR: %struct.s06 = type { i16, i16, i16 }
 // AVR: %struct.s04 = type { i16, i16 }
 // AVR: define{{.*}} void @foo10(ptr {{.*}}, i16 noundef %a, i16 noundef %b, 
i16 noundef %c)
 // AVR: define{{.*}} %struct.s06 @foo06(i16 noundef %a, i16 noundef %b, i16 
noundef %c)
 // AVR: define{{.*}} %struct.s04 @foo04(i16 noundef %a, i16 noundef %b)
+// AVR: define{{.*}} i64 @fooi64()
 
 // TINY: %struct.s10 = type { i16, i16, i16, i16, i16 }
 // TINY: %struct.s06 = type { i16, i16, i16 }
@@ -46,3 +51,4 @@
 // TINY: define{{.*}} void @foo10(ptr {{.*}}, i16 noundef %a, i16 noundef %b, 
i16 noundef %c)
 // TINY: define{{.*}} void @foo06(ptr {{.*}}, i16 noundef %a, i16 noundef %b, 
i16 noundef %c)
 // TINY: define{{.*}} %struct.s04 @foo04(i16 noundef %a, i16 noundef %b)
+// TINY: define{{.*}} void @fooi64(ptr {{.*}})
Index: clang/lib/CodeGen/TargetInfo.cpp
===
--- clang/lib/CodeGen/TargetInfo.cpp
+++ clang/lib/CodeGen/TargetInfo.cpp
@@ -8339,15 +8339,16 @@
   : DefaultABIInfo(CGT), ParamRegs(NPR), RetRegs(NRR) {}
 
   ABIArgInfo classifyReturnType(QualType Ty, bool &LargeRet) const {
-if (isAggregateTypeForABI(Ty)) {
-  // On AVR, a return struct with size less than or equals to 8 bytes is
-  // returned directly via registers R18-R25. On AVRTiny, a return struct
-  // with size less than or equals to 4 bytes is returned directly via
-  // registers R22-R25.
-  if (getContext().getTypeSize(Ty) <= RetRegs * 8)
-return ABIArgInfo::getDirect();
-  // A return struct with larger size is returned via a stack
-  // slot, along with a pointer to it as the function's implicit argument.
+// On AVR, a return struct with size less than or equals to 8 bytes is
+// returned directly via registers R18-R25. On AVRTiny, a return struct
+// with size less than or equals to 4 bytes is returned directly via
+// registers R22-R25.
+if (isAggregateTypeForABI(Ty) &&
+getContext().getTypeSize(Ty) <= RetRegs * 8)
+  return ABIArgInfo::getDirect();
+// A return value (struct or scalar) with larger size is returned via a
+// stack slot, along with a pointer as the function's implicit argument.
+if (getContext().getTypeSize(Ty) > RetRegs * 8) {
   LargeRet = true;
   return getNaturalAlignIndirect(Ty);
 }


Index: clang/test/CodeGen/avr/return-value.c
===
--- clang/test/CodeGen/avr/return-value.c
+++ clang/test/CodeGen/avr/return-value.c
@@ -33,12 +33,17 @@
   return a0;
 }
 
+long long fooi64(void) {
+  return 0xaa5533;
+}
+
 // AVR: %struct.s10 = type { i16, i16, i16, i16, i16 }
 // AVR: %struct.s06 = type { i16, i16, i16 }
 // AVR: %struct.s04 = type { i16, i16 }
 // AVR: define{{.*}} void @foo10(ptr {{.*}}, i16 noundef %a, i16 noundef %b, i16 noundef %c)
 // AVR: define{{.*}} %struct.s06 @foo06(i16 noundef %a, i16 noundef %b, i16 noundef %c)
 // AVR: define{{.*}} %struct.s04 @foo04(i16 noundef %a, i16 noundef %b)
+// AVR: define{{.*}} i64 @fooi64()
 
 // TINY: %struct.s10 = type { i16, i16, i16, i16, i16 }
 // TINY: %struct.s06 = type { i16, i16, i16 }
@@ -46,3 +51,4 @@
 // TINY: define{{.*}} void @foo10(ptr {{.*}}, i16 noundef %a, i16 noundef %b, i16 noundef %c)
 // TINY: define{{.*}} void @foo06(ptr {{.*}}, i16 noundef %a, i16 noundef %b, i16 noundef %c)
 // TINY: define{{.*}} %struct.s04 @foo04(i16 noundef %a, i16 noundef %b)
+// TINY: define{{.*}} void @fooi64(ptr {{.*}})
Index: clang/lib/CodeGen/TargetInfo.cpp
===
--- clang/lib/CodeGen/TargetInfo.cpp
+++ clang/lib/CodeGen/TargetInfo.cpp
@@ -8339,15 +8339,16 @@
   : DefaultABIInfo(CGT), ParamRegs(NPR), RetRegs(NRR) {}
 
   ABIArgInfo classifyReturnType(QualType Ty, bool &LargeRet) const {
-if (isAggregateTypeForABI(Ty)) {
-  // On AVR, a return struct with size less than or equals to 8 bytes is
-  // returned directly via registers R18-R25. On AVRTiny, a return struct
-  // with size less than or equals to 4 bytes is returned directly via
-  // registers R22-R25.
-  if (getContext().getTypeSize(Ty) <= RetRegs * 8)
-return ABIArgInfo::getDirect();
-  // A return struct with larger size is returned via a stack
-  // slot, along with a pointer to it as the fu

[PATCH] D138125: [clang] Fix wrong ABI on AVRTiny

[Ben Shi via Phabricator via cfe-commits]

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



Comment at: clang/test/CodeGen/avr/struct.c:37
+long long fooi64(void) {
+  return 0xaa5533;
+}

aykevl wrote:
> benshi001 wrote:
> > This file should be renamed to return.c instead of current struct.c, I will 
> > do that in another patch, just let you see clearly what I have changed.
> You can do that in the same patch. Phabricator should detect the renamed file 
> and display it just like it does now.
thanks.


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

https://reviews.llvm.org/D138125

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

[PATCH] D138115: [clang] Short-circuit evaluation in ::EvaluateAsConstantExpr

[Erich Keane via Phabricator via cfe-commits]

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

This seems to make sense to me.  I'll accept, but please give others time to 
take a look.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138115

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

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Michael Matz via cfe-commits]

Hi,

On Tue, 15 Nov 2022, Paul Eggert wrote:

> On 2022-11-15 11:27, Jonathan Wakely wrote:
> > Another perspective is that autoconf shouldn't get in the way of
> > making the C and C++ toolchain more secure by default.
> 
> Can you cite any examples of a real-world security flaw what would be 
> found by Clang erroring out because 'char foo(void);' is the wrong 
> prototype? Is it plausible that any such security flaw exists?
> 
> On the contrary, it's more likely that Clang's erroring out here would 
> *introduce* a security flaw, because it would cause 'configure' to 
> incorrectly infer that an important security-relevant function is 
> missing and that a flawed substitute needs to be used.
> 
> Let's focus on real problems rather than worrying about imaginary ones.

I sympathize, and I would think a compiler emitting an error (not a 
warning) in the situation at hand (in absence of -Werror) is overly 
pedantic.  But, could autoconf perhaps avoid the problem?  AFAICS the 
ac_fn_c_check_func really does only a link test to check for symbol 
existence, and the perceived problem is that the call statement in main() 
invokes UB.  So, let's avoid the call then while retaining the access to 
the symbol?  Like:

-
char foobar(void);
int main(void) {
  return &foobar != 0;
}
-

No call involved: no reason for compiler to complain.  The prototype decl 
itself will still be "wrong", but compilers complaining about that (in 
absence of a pre-existing different prototype, which is avoided by 
autoconf) seem unlikely.

Obviously this program will also say "foobar exists" if it's a data 
symbol, but that's the same with the variant using the call on most 
platforms (after all it's not run).

The idea is so obvious that I'm probably missing something, why autoconf 
can't use that idiom instead.  But perhaps the (historic?) reasons why it 
couldn't be used are gone now?


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

[PATCH] D137979: parse: process GNU and standard attributes on top-level decls

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman edited reviewers, added: eandrews; removed: elizabethandrews.
aaron.ballman added a comment.

I added the wrong account for Elizabeth, so fixing that up.


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

https://reviews.llvm.org/D137979

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

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Alexander Monakov via cfe-commits]

On Wed, 16 Nov 2022, Michael Matz via Gcc wrote:

> I sympathize, and I would think a compiler emitting an error (not a 
> warning) in the situation at hand (in absence of -Werror) is overly 
> pedantic.  But, could autoconf perhaps avoid the problem?  AFAICS the 
> ac_fn_c_check_func really does only a link test to check for symbol 
> existence, and the perceived problem is that the call statement in main() 
> invokes UB.  So, let's avoid the call then while retaining the access to 
> the symbol?  Like:
> 
> -
> char foobar(void);
> int main(void) {
>   return &foobar != 0;
> }
> -
> 
> No call involved: no reason for compiler to complain.  The prototype decl 
> itself will still be "wrong", but compilers complaining about that (in 
> absence of a pre-existing different prototype, which is avoided by 
> autoconf) seem unlikely.
> 
> Obviously this program will also say "foobar exists" if it's a data 
> symbol, but that's the same with the variant using the call on most 
> platforms (after all it's not run).
> 
> The idea is so obvious that I'm probably missing something, why autoconf 
> can't use that idiom instead.  But perhaps the (historic?) reasons why it 
> couldn't be used are gone now?

Ironically, modern GCC and LLVM optimize '&foobar != 0' to '1' even at -O0,
and thus no symbol reference remains in the resulting assembly.

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

[clang] cb3f8d5 - [Lexer] Speedup LexTokenInternal

[via cfe-commits]

Author: serge-sans-paille
Date: 2022-11-16T15:57:32+01:00
New Revision: cb3f8d53e6c35e6538ccbb54fdd848de2b3d0d1e

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

LOG: [Lexer] Speedup LexTokenInternal

Only reset "NeedsCleaning" flag in case of re-entrant call.
Do not needlessly blank IdentifierInfo. This information will be set
once the token type is picked.

This yields a nice 1% speedup when pre-processing sqlite amalgamation
through:

valgrind --tool=callgrind ./bin/clang -E sqlite3.c -o/dev/null

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

Added: 


Modified: 
clang/include/clang/Lex/Token.h
clang/lib/Lex/Lexer.cpp

Removed: 




diff  --git a/clang/include/clang/Lex/Token.h b/clang/include/clang/Lex/Token.h
index 7115d68f0f269..f0c0794096778 100644
--- a/clang/include/clang/Lex/Token.h
+++ b/clang/include/clang/Lex/Token.h
@@ -175,6 +175,8 @@ class Token {
 Loc = SourceLocation().getRawEncoding();
   }
 
+  bool hasPtrData() const { return PtrData != nullptr; }
+
   IdentifierInfo *getIdentifierInfo() const {
 assert(isNot(tok::raw_identifier) &&
"getIdentifierInfo() on a tok::raw_identifier token!");

diff  --git a/clang/lib/Lex/Lexer.cpp b/clang/lib/Lex/Lexer.cpp
index a0a0802da1736..b6ffb85cd2fa6 100644
--- a/clang/lib/Lex/Lexer.cpp
+++ b/clang/lib/Lex/Lexer.cpp
@@ -3516,10 +3516,9 @@ bool Lexer::Lex(Token &Result) {
 /// token, not a normal token, as such, it is an internal interface.  It 
assumes
 /// that the Flags of result have been cleared before calling this.
 bool Lexer::LexTokenInternal(Token &Result, bool TokAtPhysicalStartOfLine) {
-LexNextToken:
-  // New token, can't need cleaning yet.
-  Result.clearFlag(Token::NeedsCleaning);
-  Result.setIdentifierInfo(nullptr);
+LexStart:
+  assert(!Result.needsCleaning() && "Result doesn't need cleaning");
+  assert(!Result.hasPtrData() && "Result has been reset");
 
   // CurPtr - Cache BufferPtr in an automatic variable.
   const char *CurPtr = BufferPtr;
@@ -4301,6 +4300,10 @@ bool Lexer::LexTokenInternal(Token &Result, bool 
TokAtPhysicalStartOfLine) {
 
   // We parsed the directive; lex a token with the new state.
   return false;
+
+LexNextToken:
+  Result.clearFlag(Token::NeedsCleaning);
+  goto LexStart;
 }
 
 const char *Lexer::convertDependencyDirectiveToken(



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

[PATCH] D137960: [Lexer] Speedup LexTokenInternal

[serge via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGcb3f8d53e6c3: [Lexer] Speedup LexTokenInternal (authored by 
serge-sans-paille).

Changed prior to commit:
  https://reviews.llvm.org/D137960?vs=475699&id=475818#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137960

Files:
  clang/include/clang/Lex/Token.h
  clang/lib/Lex/Lexer.cpp


Index: clang/lib/Lex/Lexer.cpp
===
--- clang/lib/Lex/Lexer.cpp
+++ clang/lib/Lex/Lexer.cpp
@@ -3516,10 +3516,9 @@
 /// token, not a normal token, as such, it is an internal interface.  It 
assumes
 /// that the Flags of result have been cleared before calling this.
 bool Lexer::LexTokenInternal(Token &Result, bool TokAtPhysicalStartOfLine) {
-LexNextToken:
-  // New token, can't need cleaning yet.
-  Result.clearFlag(Token::NeedsCleaning);
-  Result.setIdentifierInfo(nullptr);
+LexStart:
+  assert(!Result.needsCleaning() && "Result doesn't need cleaning");
+  assert(!Result.hasPtrData() && "Result has been reset");
 
   // CurPtr - Cache BufferPtr in an automatic variable.
   const char *CurPtr = BufferPtr;
@@ -4301,6 +4300,10 @@
 
   // We parsed the directive; lex a token with the new state.
   return false;
+
+LexNextToken:
+  Result.clearFlag(Token::NeedsCleaning);
+  goto LexStart;
 }
 
 const char *Lexer::convertDependencyDirectiveToken(
Index: clang/include/clang/Lex/Token.h
===
--- clang/include/clang/Lex/Token.h
+++ clang/include/clang/Lex/Token.h
@@ -175,6 +175,8 @@
 Loc = SourceLocation().getRawEncoding();
   }
 
+  bool hasPtrData() const { return PtrData != nullptr; }
+
   IdentifierInfo *getIdentifierInfo() const {
 assert(isNot(tok::raw_identifier) &&
"getIdentifierInfo() on a tok::raw_identifier token!");


Index: clang/lib/Lex/Lexer.cpp
===
--- clang/lib/Lex/Lexer.cpp
+++ clang/lib/Lex/Lexer.cpp
@@ -3516,10 +3516,9 @@
 /// token, not a normal token, as such, it is an internal interface.  It assumes
 /// that the Flags of result have been cleared before calling this.
 bool Lexer::LexTokenInternal(Token &Result, bool TokAtPhysicalStartOfLine) {
-LexNextToken:
-  // New token, can't need cleaning yet.
-  Result.clearFlag(Token::NeedsCleaning);
-  Result.setIdentifierInfo(nullptr);
+LexStart:
+  assert(!Result.needsCleaning() && "Result doesn't need cleaning");
+  assert(!Result.hasPtrData() && "Result has been reset");
 
   // CurPtr - Cache BufferPtr in an automatic variable.
   const char *CurPtr = BufferPtr;
@@ -4301,6 +4300,10 @@
 
   // We parsed the directive; lex a token with the new state.
   return false;
+
+LexNextToken:
+  Result.clearFlag(Token::NeedsCleaning);
+  goto LexStart;
 }
 
 const char *Lexer::convertDependencyDirectiveToken(
Index: clang/include/clang/Lex/Token.h
===
--- clang/include/clang/Lex/Token.h
+++ clang/include/clang/Lex/Token.h
@@ -175,6 +175,8 @@
 Loc = SourceLocation().getRawEncoding();
   }
 
+  bool hasPtrData() const { return PtrData != nullptr; }
+
   IdentifierInfo *getIdentifierInfo() const {
 assert(isNot(tok::raw_identifier) &&
"getIdentifierInfo() on a tok::raw_identifier token!");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D138134: [include-cleaner] Defer decl->stdlib conversion into decl->location conversion

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet created this revision.
kadircet added reviewers: hokein, sammccall.
Herald added a project: All.
kadircet requested review of this revision.
Herald added a project: clang-tools-extra.
Herald added a subscriber: cfe-commits.

We preserve decls for stdlib symbols after this patch in symbol. That
way we have a more unified view of stdlib and regular decls and can provide
reacher information in applications.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D138134

Files:
  clang-tools-extra/include-cleaner/include/clang-include-cleaner/Types.h
  clang-tools-extra/include-cleaner/lib/Analysis.cpp
  clang-tools-extra/include-cleaner/lib/Types.cpp


Index: clang-tools-extra/include-cleaner/lib/Types.cpp
===
--- clang-tools-extra/include-cleaner/lib/Types.cpp
+++ clang-tools-extra/include-cleaner/lib/Types.cpp
@@ -22,8 +22,6 @@
 return OS << S.declaration().getDeclKindName();
   case Symbol::Macro:
 return OS << S.macro().Name;
-  case Symbol::Standard:
-return OS << S.standard().scope() << S.standard().name();
   }
   llvm_unreachable("Unhandled Symbol kind");
 }
Index: clang-tools-extra/include-cleaner/lib/Analysis.cpp
===
--- clang-tools-extra/include-cleaner/lib/Analysis.cpp
+++ clang-tools-extra/include-cleaner/lib/Analysis.cpp
@@ -25,13 +25,14 @@
   for (auto *Root : ASTRoots) {
 auto &SM = Root->getASTContext().getSourceManager();
 walkAST(*Root, [&](SourceLocation Loc, NamedDecl &ND, RefType RT) {
+  SymbolReference SymRef{Loc, ND, RT};
   if (auto SS = Recognizer(&ND)) {
 // FIXME: Also report forward decls from main-file, so that the caller
 // can decide to insert/ignore a header.
-return CB({Loc, Symbol(*SS), RT}, findHeaders(*SS, SM, PI));
+return CB(SymRef, findHeaders(*SS, SM, PI));
   }
   // FIXME: Extract locations from redecls.
-  return CB({Loc, Symbol(ND), RT}, findHeaders(ND.getLocation(), SM, PI));
+  return CB(SymRef, findHeaders(ND.getLocation(), SM, PI));
 });
   }
   for (const SymbolReference &MacroRef : MacroRefs) {
Index: clang-tools-extra/include-cleaner/include/clang-include-cleaner/Types.h
===
--- clang-tools-extra/include-cleaner/include/clang-include-cleaner/Types.h
+++ clang-tools-extra/include-cleaner/include/clang-include-cleaner/Types.h
@@ -52,27 +52,21 @@
 Declaration,
 /// A preprocessor macro, as defined in a specific location.
 Macro,
-/// A recognized symbol from the standard library, like std::string.
-Standard,
   };
 
   Symbol(const Decl &D) : Storage(&D) {}
   Symbol(struct Macro M) : Storage(M) {}
-  Symbol(tooling::stdlib::Symbol S) : Storage(S) {}
 
   Kind kind() const { return static_cast(Storage.index()); }
   bool operator==(const Symbol &RHS) const { return Storage == RHS.Storage; }
 
   const Decl &declaration() const { return *std::get(Storage); }
   struct Macro macro() const { return std::get(Storage); }
-  tooling::stdlib::Symbol standard() const {
-return std::get(Storage);
-  }
 
 private:
   // FIXME: Add support for macros.
   // Order must match Kind enum!
-  std::variant Storage;
+  std::variant Storage;
 };
 llvm::raw_ostream &operator<<(llvm::raw_ostream &, const Symbol &);
 
@@ -122,9 +116,7 @@
   tooling::stdlib::Header standard() const {
 return std::get(Storage);
   }
-  StringRef verbatim() const {
-return std::get(Storage);
-  }
+  StringRef verbatim() const { return std::get(Storage); }
 
 private:
   // Order must match Kind enum!


Index: clang-tools-extra/include-cleaner/lib/Types.cpp
===
--- clang-tools-extra/include-cleaner/lib/Types.cpp
+++ clang-tools-extra/include-cleaner/lib/Types.cpp
@@ -22,8 +22,6 @@
 return OS << S.declaration().getDeclKindName();
   case Symbol::Macro:
 return OS << S.macro().Name;
-  case Symbol::Standard:
-return OS << S.standard().scope() << S.standard().name();
   }
   llvm_unreachable("Unhandled Symbol kind");
 }
Index: clang-tools-extra/include-cleaner/lib/Analysis.cpp
===
--- clang-tools-extra/include-cleaner/lib/Analysis.cpp
+++ clang-tools-extra/include-cleaner/lib/Analysis.cpp
@@ -25,13 +25,14 @@
   for (auto *Root : ASTRoots) {
 auto &SM = Root->getASTContext().getSourceManager();
 walkAST(*Root, [&](SourceLocation Loc, NamedDecl &ND, RefType RT) {
+  SymbolReference SymRef{Loc, ND, RT};
   if (auto SS = Recognizer(&ND)) {
 // FIXME: Also report forward decls from main-file, so that the caller
 // can decide to insert/ignore a header.
-return CB({Loc, Symbol(*SS), RT}, findHeaders(*SS, SM, PI));
+return CB(SymRef, findHeaders(*SS, SM, PI));
   }
   // FIXME: Extract locations from 

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Michael Matz via cfe-commits]

Hey,

On Wed, 16 Nov 2022, Alexander Monakov wrote:

> > The idea is so obvious that I'm probably missing something, why autoconf 
> > can't use that idiom instead.  But perhaps the (historic?) reasons why it 
> > couldn't be used are gone now?
> 
> Ironically, modern GCC and LLVM optimize '&foobar != 0' to '1' even at -O0,
> and thus no symbol reference remains in the resulting assembly.

Err, right, *head-->table*.
Playing with volatile should help:

char foobar(void);
char (* volatile ptr)(void);
int main(void) {
ptr = foobar;
return ptr != 0;
}


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

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

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

At some point, you should also add a release note to tell users about the new 
functionality.




Comment at: clang/include/clang/AST/Type.h:4008
 bool HasTrailingReturn : 1;
+unsigned AArch64SMEAttributes : 8;
 Qualifiers TypeQuals;

erichkeane wrote:
> sdesmalen wrote:
> > aaron.ballman wrote:
> > > So functions without prototypes cannot have any of these attributes?
> > Yes, the ACLE explicitly states that 
> > [[https://github.com/ARM-software/acle/pull/188/commits/59751df91d9630400531a64108f179e3951c3b89#diff-516526d4a18101dc85300bc2033d0f86dc46c505b7510a7694baabea851aedfaR503|here]]:
> > > The function type attributes cannot be used with K&R-style “unprototyped” 
> > > C function types
> Are they aware that includes; `void Baz();` ?
FWIW, the linked docs say:
```
> Functions like `some_func` and `another_func` are referred to as
> (K&R-style) “unprototyped” functions. The first C standard categorized
> them as an obsolescent feature and C18 removed all remaining support
> for them.
```
That's not quite accurate. They've always been obsolete in standard C (both 
ANSI and ISO C), so that's correct. But it's C2x that removes all remaining 
support for them. (Also, there's no such release as C18, there's C11, C17, and 
expected to be C23).

> Are they aware that includes; void Baz(); ?

Just to expound on this question: this means `void baz();` in C17 mode cannot 
have the attribute but `void baz();` in C2x mode can. Folks coming from C++ 
tend to expect the C2x behavior to be the default and so it's plausible to see 
such signatures in older language modes. Will that cause any pain or confusion 
for you?



Comment at: clang/include/clang/Basic/AttrDocs.td:6318
+def ArmSmeStreamingDocs : Documentation {
+  let Category = DocCatType;
+  let Content = [{

There are enough of these attributes that I think we should consider adding an 
`ARM C Language Extensions for SME` documentation category:
```
def DocCatACLE_SME : DocumentationCategory<"ARM C Language Extensions for SME"> 
{
  let Content = [{
Put general information about what ACLE SME is here to give an overview of the 
functionality and a place to link to the official ACLE SME documentation for 
more in-depth details.
}];
}
```
and then use this for the `Category` for each of the attributes so they group 
together.



Comment at: clang/include/clang/Basic/AttrDocs.td:6334-6336
+(ACLE) for SME. It is used to mark a function's body (not the interface) as 
requiring
+``PSTATE.SM`` to be ``1``, although the function is expected to be called with
+``PSTATE.SM=0`` and return with ``PSTATE.SM`` unchanged.

I'm not certain I understand what this is telling me. The function is expected 
to be called with PSTATE.SM == 0 and return with it unchanged, so what does it 
mean for it to also require PSTATE.SM to be 1? I *think* it might be saying 
that the function is called with SM = 0 and returns with SM = 0, but within the 
function body itself SM will be 1?



Comment at: clang/include/clang/Basic/AttrDocs.td:6366-6367
+The ``arm_shared_za`` attribute is defined by the Arm C Language Extensions
+(ACLE) for SME. It is used to mark a function as sharing the state of ZA, the
+acculator array, with that of it's callers.
+

Is `acculator` a typo or is that a term of art I am unfamiliar with?



Comment at: clang/include/clang/Basic/AttrDocs.td:6389-6396
+def ArmSmePreservesZADocs : Documentation {
+  let Category = DocCatType;
+  let Content = [{
+The ``arm_preserves_za`` attribute is defined by the Arm C Language Extensions
+(ACLE) for SME. If a function is marked as ``arm_preserves_za``, it is a hint 
to
+the compiler that the function and any of it's callees will preserve the state
+of ZA.

If this is a hint, why is the attribute part of the type system? It seems like 
it'd be fine for the hint to be lost when forming a function pointer, as in:
```
__attribute__((arm_preserves_za)) void func(void);

void foo(void) {
  void (*fp)(void) = func; // Doesn't need to be an error, right?
}
```



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:2000
   "overridden virtual function is here">;
+def err_conflicting_overriding_attributes : Error<
+  "virtual function %0 has different attributes "

aaron.ballman wrote:
> rsandifo-arm wrote:
> > sdesmalen wrote:
> > > aaron.ballman wrote:
> > > > sdesmalen wrote:
> > > > > aaron.ballman wrote:
> > > > > > This error and the one below make me wonder whether an attribute 
> > > > > > spelling is the appropriate way to surface this functionality as 
> > > > > > opposed to a keyword. Attributes don't typically don't cause errors 
> > > > > > in these situations, but because these attributes are strongly 
> > > > > > coupled to their type system effects I can see why you want these 
> > 

[PATCH] D138109: [clang] Fix -fp-model={strict|precise} to disable -fapprox-func

[Masoud Ataei via Phabricator via cfe-commits]

masoud.ataei accepted this revision.
masoud.ataei 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/D138109/new/

https://reviews.llvm.org/D138109

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

[clang] 6c38ffc - [Concepts] Fix friend-checking to include NTTPs

[Erich Keane via cfe-commits]

Author: Erich Keane
Date: 2022-11-16T07:33:15-08:00
New Revision: 6c38ffc7b6f46fda94e29ed6cf34b814aeeaab45

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

LOG: [Concepts] Fix friend-checking to include NTTPs

More work for temp.friend p9, this fixes a previous bug where we didn't
properly consider a friend to depend on the enclosing template if it
only did so via an NTTP.

Added: 


Modified: 
clang/lib/Sema/SemaTemplate.cpp
clang/test/SemaTemplate/concepts-friends.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaTemplate.cpp b/clang/lib/Sema/SemaTemplate.cpp
index b04458687ac02..08ff4f4aecb5e 100644
--- a/clang/lib/Sema/SemaTemplate.cpp
+++ b/clang/lib/Sema/SemaTemplate.cpp
@@ -1707,6 +1707,18 @@ class ConstraintRefersToContainingTemplateChecker
   Result = true;
   }
 
+  void CheckNonTypeTemplateParmDecl(NonTypeTemplateParmDecl *D) {
+assert(D->getDepth() <= TemplateDepth &&
+   "Nothing should reference a value below the actual template depth, "
+   "depth is likely wrong");
+if (D->getDepth() != TemplateDepth)
+  Result = true;
+
+// Necessary because the type of the NTTP might be what refers to the 
parent
+// constriant.
+TransformType(D->getType());
+  }
+
 public:
   using inherited = TreeTransform;
 
@@ -1742,6 +1754,8 @@ class ConstraintRefersToContainingTemplateChecker
 // unreachable should catch future instances/cases.
 if (auto *TD = dyn_cast(D))
   TransformType(TD->getUnderlyingType());
+else if (auto *NTTPD = dyn_cast(D))
+  CheckNonTypeTemplateParmDecl(NTTPD);
 else if (auto *VD = dyn_cast(D))
   TransformType(VD->getType());
 else if (auto *TD = dyn_cast(D))

diff  --git a/clang/test/SemaTemplate/concepts-friends.cpp 
b/clang/test/SemaTemplate/concepts-friends.cpp
index 6aa461841f9ca..3a9b308a65c5d 100644
--- a/clang/test/SemaTemplate/concepts-friends.cpp
+++ b/clang/test/SemaTemplate/concepts-friends.cpp
@@ -411,3 +411,33 @@ namespace RefersToParentInConstraint {
 S y;
   }
 } // namespace RefersToParentInConstraint
+
+namespace NTTP {
+  struct Base{};
+  template
+  struct S : Base {
+// N is from the parent template.
+template
+  friend int templ_func(Base&) requires(N > 0)
+  { return 10; }
+  };
+
+  template
+  struct U : Base {
+template
+  friend int templ_func(Base&) requires(N>0)
+  { return 10; }
+  };
+
+  void use() {
+S<1> s1;
+templ_func(s1);
+S<2> s2;
+templ_func(s2);
+
+U u1;
+templ_func<1>(u1);
+U u2;
+templ_func<1>(u2);
+  }
+}



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

[PATCH] D137217: [LTO][COFF] Use bitcode file names in lto native object file names.

[Teresa Johnson via Phabricator via cfe-commits]

tejohnson added inline comments.



Comment at: lld/COFF/LTO.cpp:238
+  sys::path::append(path, directory,
+outputFileBaseName + ".lto." + baseName);
+  sys::path::remove_dots(path, true);

MaskRay wrote:
> What if two input bitcode files have the same basename, e.g. `dir1/a.obj` and 
> `dir2/a.obj`?
I think that should be ok as the output file path created here includes the 
directory. So you should get dir1/a.out.lto.a.obj and dir2/a.out.lto.a.obj.



Comment at: lld/COFF/LTO.cpp:229
+StringRef ltoObjName;
+if (bitcodeFilePath == "ld-temp.o") {
+  ltoObjName =

MaskRay wrote:
> MaskRay wrote:
> > tejohnson wrote:
> > > zequanwu wrote:
> > > > tejohnson wrote:
> > > > > This case should always be i==0 I think?
> > > > IIUC, "ld-temp.o" is the name of combined module. Do you mean there 
> > > > will be only 1 combined module and it will always be the first task?
> > > Yes. So you don't need the handling for i==0 in the name in this case 
> > > (you could probably assert that i==0).
> > This looks like a hack. `assert(i == 0)` will fail with 
> > `-opt:lldltopartitions=2`: `buf[1]` will be called `ld-temp.o` as well.
> > 
> > In addition, if an input bitcode file is called `ld-temp.o` (for some 
> > reason they don't use `.obj`, just `ld-temp.o`), `assert(i == 0)` will fail 
> > as well.
> I guess `if (i < config->ltoPartitions)` may fix the issue.
Ah ok, forgot about the lto partitions case. Sorry, @zequanwu, looks like you 
will need to go back to your old handling that appends i if it is non-zero.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137217

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

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Richard Biener via cfe-commits]

On Wed, Nov 16, 2022 at 4:02 PM Michael Matz via Gcc  wrote:
>
> Hey,
>
> On Wed, 16 Nov 2022, Alexander Monakov wrote:
>
> > > The idea is so obvious that I'm probably missing something, why autoconf
> > > can't use that idiom instead.  But perhaps the (historic?) reasons why it
> > > couldn't be used are gone now?
> >
> > Ironically, modern GCC and LLVM optimize '&foobar != 0' to '1' even at -O0,
> > and thus no symbol reference remains in the resulting assembly.
>
> Err, right, *head-->table*.
> Playing with volatile should help:
>
> char foobar(void);
> char (* volatile ptr)(void);
> int main(void) {
> ptr = foobar;
> return ptr != 0;
> }

using printf for foobar this works even with GCC 2.95.2 and with trunk
and -Wall diagnoses

t.c:1:6: warning: conflicting types for built-in function 'printf';
expected 'int(const char *, ...)' [-Wbuiltin-declaration-mismatch]
1 | char printf(void);
  |  ^~
t.c:1:1: note: 'printf' is declared in header ''
  +++ |+#include 
1 | char printf(void);

so without -Werror this should be fine.

Richard.

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

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Sam James via cfe-commits]

> On 16 Nov 2022, at 15:27, Richard Biener  wrote:
> 
> On Wed, Nov 16, 2022 at 4:02 PM Michael Matz via Gcc  wrote:
>> 
>> Hey,
>> 
>> On Wed, 16 Nov 2022, Alexander Monakov wrote:
>> 
 The idea is so obvious that I'm probably missing something, why autoconf
 can't use that idiom instead.  But perhaps the (historic?) reasons why it
 couldn't be used are gone now?
>>> 
>>> Ironically, modern GCC and LLVM optimize '&foobar != 0' to '1' even at -O0,
>>> and thus no symbol reference remains in the resulting assembly.
>> 
>> Err, right, *head-->table*.
>> Playing with volatile should help:
>> 
>> char foobar(void);
>> char (* volatile ptr)(void);
>> int main(void) {
>>ptr = foobar;
>>return ptr != 0;
>> }
> 
> using printf for foobar this works even with GCC 2.95.2 and with trunk
> and -Wall diagnoses
> 
> t.c:1:6: warning: conflicting types for built-in function 'printf';
> expected 'int(const char *, ...)' [-Wbuiltin-declaration-mismatch]
>1 | char printf(void);
>  |  ^~
> t.c:1:1: note: 'printf' is declared in header ''
>  +++ |+#include 
>1 | char printf(void);
> 
> so without -Werror this should be fine.
> 
Unrelated but I was a bit tempted to ask for throwing in 
-Wbuiltin-declaration-mismatch
to default -Werror while Clang 16 was at it, but I suppose we don't want the 
world to
burn too much, and it's got a very obvious usecase (this one) whereas implicit
func decls are too hard to justify.

> Richard.


signature.asc
Description: Message signed with OpenPGP
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] e5739eb - [include-cleaner] Defer decl->stdlib conversion into decl->location conversion

[Kadir Cetinkaya via cfe-commits]

Author: Kadir Cetinkaya
Date: 2022-11-16T16:52:39+01:00
New Revision: e5739eb4f8135e20da7590c86d724920fd66753e

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

LOG: [include-cleaner] Defer decl->stdlib conversion into decl->location 
conversion

We preserve decls for stdlib symbols after this patch in symbol. That
way we have a more unified view of stdlib and regular decls and can provide
reacher information in applications.

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

Added: 


Modified: 
clang-tools-extra/include-cleaner/include/clang-include-cleaner/Types.h
clang-tools-extra/include-cleaner/lib/Analysis.cpp
clang-tools-extra/include-cleaner/lib/Types.cpp

Removed: 




diff  --git 
a/clang-tools-extra/include-cleaner/include/clang-include-cleaner/Types.h 
b/clang-tools-extra/include-cleaner/include/clang-include-cleaner/Types.h
index 85e3fe4d7827d..29a3aa7ea7f73 100644
--- a/clang-tools-extra/include-cleaner/include/clang-include-cleaner/Types.h
+++ b/clang-tools-extra/include-cleaner/include/clang-include-cleaner/Types.h
@@ -52,27 +52,21 @@ struct Symbol {
 Declaration,
 /// A preprocessor macro, as defined in a specific location.
 Macro,
-/// A recognized symbol from the standard library, like std::string.
-Standard,
   };
 
   Symbol(const Decl &D) : Storage(&D) {}
   Symbol(struct Macro M) : Storage(M) {}
-  Symbol(tooling::stdlib::Symbol S) : Storage(S) {}
 
   Kind kind() const { return static_cast(Storage.index()); }
   bool operator==(const Symbol &RHS) const { return Storage == RHS.Storage; }
 
   const Decl &declaration() const { return *std::get(Storage); }
   struct Macro macro() const { return std::get(Storage); }
-  tooling::stdlib::Symbol standard() const {
-return std::get(Storage);
-  }
 
 private:
   // FIXME: Add support for macros.
   // Order must match Kind enum!
-  std::variant Storage;
+  std::variant Storage;
 };
 llvm::raw_ostream &operator<<(llvm::raw_ostream &, const Symbol &);
 
@@ -122,9 +116,7 @@ struct Header {
   tooling::stdlib::Header standard() const {
 return std::get(Storage);
   }
-  StringRef verbatim() const {
-return std::get(Storage);
-  }
+  StringRef verbatim() const { return std::get(Storage); }
 
 private:
   // Order must match Kind enum!

diff  --git a/clang-tools-extra/include-cleaner/lib/Analysis.cpp 
b/clang-tools-extra/include-cleaner/lib/Analysis.cpp
index 9e04ab7dd5668..890e5e13fa57f 100644
--- a/clang-tools-extra/include-cleaner/lib/Analysis.cpp
+++ b/clang-tools-extra/include-cleaner/lib/Analysis.cpp
@@ -25,13 +25,14 @@ void walkUsed(llvm::ArrayRef ASTRoots,
   for (auto *Root : ASTRoots) {
 auto &SM = Root->getASTContext().getSourceManager();
 walkAST(*Root, [&](SourceLocation Loc, NamedDecl &ND, RefType RT) {
+  SymbolReference SymRef{Loc, ND, RT};
   if (auto SS = Recognizer(&ND)) {
 // FIXME: Also report forward decls from main-file, so that the caller
 // can decide to insert/ignore a header.
-return CB({Loc, Symbol(*SS), RT}, findHeaders(*SS, SM, PI));
+return CB(SymRef, findHeaders(*SS, SM, PI));
   }
   // FIXME: Extract locations from redecls.
-  return CB({Loc, Symbol(ND), RT}, findHeaders(ND.getLocation(), SM, PI));
+  return CB(SymRef, findHeaders(ND.getLocation(), SM, PI));
 });
   }
   for (const SymbolReference &MacroRef : MacroRefs) {

diff  --git a/clang-tools-extra/include-cleaner/lib/Types.cpp 
b/clang-tools-extra/include-cleaner/lib/Types.cpp
index d7b17376d1319..08c9b5980060b 100644
--- a/clang-tools-extra/include-cleaner/lib/Types.cpp
+++ b/clang-tools-extra/include-cleaner/lib/Types.cpp
@@ -22,8 +22,6 @@ llvm::raw_ostream &operator<<(llvm::raw_ostream &OS, const 
Symbol &S) {
 return OS << S.declaration().getDeclKindName();
   case Symbol::Macro:
 return OS << S.macro().Name;
-  case Symbol::Standard:
-return OS << S.standard().scope() << S.standard().name();
   }
   llvm_unreachable("Unhandled Symbol kind");
 }



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

[PATCH] D138134: [include-cleaner] Defer decl->stdlib conversion into decl->location conversion

[Kadir Cetinkaya via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGe5739eb4f813: [include-cleaner] Defer decl->stdlib 
conversion into decl->location conversion (authored by kadircet).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138134

Files:
  clang-tools-extra/include-cleaner/include/clang-include-cleaner/Types.h
  clang-tools-extra/include-cleaner/lib/Analysis.cpp
  clang-tools-extra/include-cleaner/lib/Types.cpp


Index: clang-tools-extra/include-cleaner/lib/Types.cpp
===
--- clang-tools-extra/include-cleaner/lib/Types.cpp
+++ clang-tools-extra/include-cleaner/lib/Types.cpp
@@ -22,8 +22,6 @@
 return OS << S.declaration().getDeclKindName();
   case Symbol::Macro:
 return OS << S.macro().Name;
-  case Symbol::Standard:
-return OS << S.standard().scope() << S.standard().name();
   }
   llvm_unreachable("Unhandled Symbol kind");
 }
Index: clang-tools-extra/include-cleaner/lib/Analysis.cpp
===
--- clang-tools-extra/include-cleaner/lib/Analysis.cpp
+++ clang-tools-extra/include-cleaner/lib/Analysis.cpp
@@ -25,13 +25,14 @@
   for (auto *Root : ASTRoots) {
 auto &SM = Root->getASTContext().getSourceManager();
 walkAST(*Root, [&](SourceLocation Loc, NamedDecl &ND, RefType RT) {
+  SymbolReference SymRef{Loc, ND, RT};
   if (auto SS = Recognizer(&ND)) {
 // FIXME: Also report forward decls from main-file, so that the caller
 // can decide to insert/ignore a header.
-return CB({Loc, Symbol(*SS), RT}, findHeaders(*SS, SM, PI));
+return CB(SymRef, findHeaders(*SS, SM, PI));
   }
   // FIXME: Extract locations from redecls.
-  return CB({Loc, Symbol(ND), RT}, findHeaders(ND.getLocation(), SM, PI));
+  return CB(SymRef, findHeaders(ND.getLocation(), SM, PI));
 });
   }
   for (const SymbolReference &MacroRef : MacroRefs) {
Index: clang-tools-extra/include-cleaner/include/clang-include-cleaner/Types.h
===
--- clang-tools-extra/include-cleaner/include/clang-include-cleaner/Types.h
+++ clang-tools-extra/include-cleaner/include/clang-include-cleaner/Types.h
@@ -52,27 +52,21 @@
 Declaration,
 /// A preprocessor macro, as defined in a specific location.
 Macro,
-/// A recognized symbol from the standard library, like std::string.
-Standard,
   };
 
   Symbol(const Decl &D) : Storage(&D) {}
   Symbol(struct Macro M) : Storage(M) {}
-  Symbol(tooling::stdlib::Symbol S) : Storage(S) {}
 
   Kind kind() const { return static_cast(Storage.index()); }
   bool operator==(const Symbol &RHS) const { return Storage == RHS.Storage; }
 
   const Decl &declaration() const { return *std::get(Storage); }
   struct Macro macro() const { return std::get(Storage); }
-  tooling::stdlib::Symbol standard() const {
-return std::get(Storage);
-  }
 
 private:
   // FIXME: Add support for macros.
   // Order must match Kind enum!
-  std::variant Storage;
+  std::variant Storage;
 };
 llvm::raw_ostream &operator<<(llvm::raw_ostream &, const Symbol &);
 
@@ -122,9 +116,7 @@
   tooling::stdlib::Header standard() const {
 return std::get(Storage);
   }
-  StringRef verbatim() const {
-return std::get(Storage);
-  }
+  StringRef verbatim() const { return std::get(Storage); }
 
 private:
   // Order must match Kind enum!


Index: clang-tools-extra/include-cleaner/lib/Types.cpp
===
--- clang-tools-extra/include-cleaner/lib/Types.cpp
+++ clang-tools-extra/include-cleaner/lib/Types.cpp
@@ -22,8 +22,6 @@
 return OS << S.declaration().getDeclKindName();
   case Symbol::Macro:
 return OS << S.macro().Name;
-  case Symbol::Standard:
-return OS << S.standard().scope() << S.standard().name();
   }
   llvm_unreachable("Unhandled Symbol kind");
 }
Index: clang-tools-extra/include-cleaner/lib/Analysis.cpp
===
--- clang-tools-extra/include-cleaner/lib/Analysis.cpp
+++ clang-tools-extra/include-cleaner/lib/Analysis.cpp
@@ -25,13 +25,14 @@
   for (auto *Root : ASTRoots) {
 auto &SM = Root->getASTContext().getSourceManager();
 walkAST(*Root, [&](SourceLocation Loc, NamedDecl &ND, RefType RT) {
+  SymbolReference SymRef{Loc, ND, RT};
   if (auto SS = Recognizer(&ND)) {
 // FIXME: Also report forward decls from main-file, so that the caller
 // can decide to insert/ignore a header.
-return CB({Loc, Symbol(*SS), RT}, findHeaders(*SS, SM, PI));
+return CB(SymRef, findHeaders(*SS, SM, PI));
   }
   // FIXME: Extract locations from redecls.
-  return CB({Loc, Symbol(ND), RT}, findHeaders(ND.getLocation(), SM, P

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Michael Matz via cfe-commits]

Hello,

On Wed, 16 Nov 2022, Sam James wrote:

> Unrelated but I was a bit tempted to ask for throwing in 
> -Wbuiltin-declaration-mismatch to default -Werror while Clang 16 was at 
> it, but I suppose we don't want the world to burn too much,

:-)  It's IMHO a bug in the standard that it misses "if any of its 
associated headers are included" in the item for reservation of external 
linkage identifiers; it has that for all other items about reserved 
identifiers in the Library clause.  If that restriction were added you 
couldn't justify erroring on the example at hand (because it doesn't 
include e.g.  and then printf wouldn't be reserved).  A warning 
is of course always okay and reasonable.  As is, you could justify 
erroring out, but I too think that would be overzealous.


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

[PATCH] D138109: [clang] Fix -fp-model={strict|precise} to disable -fapprox-func

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added inline comments.



Comment at: clang/test/Driver/fp-model.c:162
+// CHECK-FASTMATH-FPM-STRICT-NOT: "-ffast-math"
+// CHECK-FASTMATH-FPM-STRICT-NOT: "-ffinite-math-only"

Shouldn't be worth adding a rule for -ffast-math and ffp-model=fast (even if it 
seems redundant)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138109

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

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

[Paul Walker via Phabricator via cfe-commits]

paulwalker-arm added a comment.

Hi @rsandifo-arm , what are your thoughts on Arron's observations? My 
interpretation is that Arm originally figured the distinction between keywords 
and gnu attributes was minimal and thus using our previous norms made most 
sense. This is not my world so my understand is somewhat naive but it does 
sound like Arron has raised some good reasons why keywords are a better design 
decision.  Do you agree? I wonder if it's worth having this conversation on 
https://github.com/ARM-software/abi-aa/pull/123 (unless Richard has a better 
link) so we can capture the rational for future design changes if any. 
@aaron.ballman, are you ok with this or do you prefer to keep the design 
conversation linked to this clang implementation?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127762

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

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Jonathan Wakely via cfe-commits]

On Wed, 16 Nov 2022 at 15:59, Michael Matz  wrote:
>
> Hello,
>
> On Wed, 16 Nov 2022, Sam James wrote:
>
> > Unrelated but I was a bit tempted to ask for throwing in
> > -Wbuiltin-declaration-mismatch to default -Werror while Clang 16 was at
> > it, but I suppose we don't want the world to burn too much,
>
> :-)  It's IMHO a bug in the standard that it misses "if any of its
> associated headers are included" in the item for reservation of external
> linkage identifiers; it has that for all other items about reserved
> identifiers in the Library clause.  If that restriction were added you
> couldn't justify erroring on the example at hand (because it doesn't
> include e.g.  and then printf wouldn't be reserved).  A warning
> is of course always okay and reasonable.  As is, you could justify
> erroring out, but I too think that would be overzealous.


I think that's very intentional and not a defect in the standard.

If one TU was allowed to define:

void printf() { }

and have that compiled into the program, then that would cause
unexpected behaviour for every other TU which includes  and
calls printf. They would get the non-standard rogue printf.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D137995: [Flang][Driver] Handle target CPU and features

[Kiran Chandramohan via Phabricator via cfe-commits]

kiranchandramohan added a comment.

Thanks @mnadeem for this patch. A few minor comments first. Try to replace auto 
in all places except where the type is on the RHS.

We might need `-fc1` tests as well.




Comment at: clang/lib/Driver/ToolChains/Flang.cpp:85
+ ArgStringList &CmdArgs) const {
+  // return;
+  const auto &TC = getToolChain();

Nit: leftover code?



Comment at: clang/lib/Driver/ToolChains/Flang.cpp:86
+  // return;
+  const auto &TC = getToolChain();
+  const llvm::Triple &Triple = TC.getEffectiveTriple();

Nit: replace auto.



Comment at: clang/lib/Driver/ToolChains/Flang.cpp:99
+  default:
+// Untested for other targets but should work generally.
+break;

I get a segfault in ` Fortran::frontend::CodeGenAction::setUpTargetMachine()` 
currently when using `./bin/flang-new --target=x86_64-linux-gnu  file.f90`



Comment at: flang/lib/Frontend/CompilerInvocation.cpp:179
+
+  for (const auto *currentArg :
+   args.filtered(clang::driver::options::OPT_target_feature))

Nit: Can you remove the auto here?



Comment at: flang/lib/Frontend/FrontendActions.cpp:594
 
-  const std::string &theTriple = ci.getInvocation().getTargetOpts().triple;
+  const auto &targetOpts = ci.getInvocation().getTargetOpts();
+  const std::string &theTriple = targetOpts.triple;

Nit: Can you remove the auto here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137995

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

[PATCH] D138137: [CodeGen][ARM] Fix ARMABIInfo::EmitVAAarg crash with empty record type variadic arg

[Lin Yurong via Phabricator via cfe-commits]

yronglin created this revision.
yronglin added reviewers: rjmccall, asl.
Herald added a subscriber: kristof.beyls.
Herald added a project: All.
yronglin requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Fix ARMABIInfo::EmitVAAarg crash with empty record type variadic arg

Open issue: https://github.com/llvm/llvm-project/issues/58794


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D138137

Files:
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/arm-vaarg.c


Index: clang/test/CodeGen/arm-vaarg.c
===
--- /dev/null
+++ clang/test/CodeGen/arm-vaarg.c
@@ -0,0 +1,23 @@
+// RUN: %clang -Xclang -no-opaque-pointers -mfloat-abi=soft -target 
arm-linux-gnu -emit-llvm -S -o - %s | FileCheck %s
+
+struct Empty {};
+
+struct Empty emptyvar;
+
+void take_args(int a, ...) {
+// CHECK: [[ALLOCA_VA_LIST:%[0-9]]] = alloca %struct.__va_list, align 4
+// CHECK: call void @llvm.va_start
+// CHECK-NEXT: [[AP_ADDR:%[0-9]+]] = bitcast %struct.__va_list* 
[[ALLOCA_VA_LIST]] to i8**
+// CHECK-NEXT: [[LOAD_AP:%[0-9]+]] = load i8*, i8** [[AP_ADDR]], align 4
+// CHECK-NEXT: [[EMPTY_PTR:%[0-9]+]] = bitcast i8* [[LOAD_AP]] to 
%struct.Empty*
+
+  // It's conceivable that EMPTY_PTR may not actually be a valid pointer
+  // (e.g. it's at the very bottom of the stack and the next page is
+  // invalid). This doesn't matter provided it's never loaded (there's no
+  // well-defined way to tell), but it becomes a problem if we do try to use 
it.
+// CHECK-NOT: load %struct.Empty, %struct.Empty* [[EMPTY_PTR]]
+  __builtin_va_list l;
+  __builtin_va_start(l, a);
+  emptyvar = __builtin_va_arg(l, struct Empty);
+  __builtin_va_end(l);
+}
Index: clang/lib/CodeGen/TargetInfo.cpp
===
--- clang/lib/CodeGen/TargetInfo.cpp
+++ clang/lib/CodeGen/TargetInfo.cpp
@@ -7050,10 +7050,10 @@
 
   // Empty records are ignored for parameter passing purposes.
   if (isEmptyRecord(getContext(), Ty, true)) {
-Address Addr = Address(CGF.Builder.CreateLoad(VAListAddr),
-   getVAListElementType(CGF), SlotSize);
-Addr = CGF.Builder.CreateElementBitCast(Addr, CGF.ConvertTypeForMem(Ty));
-return Addr;
+VAListAddr = CGF.Builder.CreateElementBitCast(VAListAddr, CGF.Int8PtrTy);
+auto *Load = CGF.Builder.CreateLoad(VAListAddr);
+Address Addr = Address(Load, CGF.Int8Ty, SlotSize);
+return CGF.Builder.CreateElementBitCast(Addr, CGF.ConvertTypeForMem(Ty));
   }
 
   CharUnits TySize = getContext().getTypeSizeInChars(Ty);


Index: clang/test/CodeGen/arm-vaarg.c
===
--- /dev/null
+++ clang/test/CodeGen/arm-vaarg.c
@@ -0,0 +1,23 @@
+// RUN: %clang -Xclang -no-opaque-pointers -mfloat-abi=soft -target arm-linux-gnu -emit-llvm -S -o - %s | FileCheck %s
+
+struct Empty {};
+
+struct Empty emptyvar;
+
+void take_args(int a, ...) {
+// CHECK: [[ALLOCA_VA_LIST:%[0-9]]] = alloca %struct.__va_list, align 4
+// CHECK: call void @llvm.va_start
+// CHECK-NEXT: [[AP_ADDR:%[0-9]+]] = bitcast %struct.__va_list* [[ALLOCA_VA_LIST]] to i8**
+// CHECK-NEXT: [[LOAD_AP:%[0-9]+]] = load i8*, i8** [[AP_ADDR]], align 4
+// CHECK-NEXT: [[EMPTY_PTR:%[0-9]+]] = bitcast i8* [[LOAD_AP]] to %struct.Empty*
+
+  // It's conceivable that EMPTY_PTR may not actually be a valid pointer
+  // (e.g. it's at the very bottom of the stack and the next page is
+  // invalid). This doesn't matter provided it's never loaded (there's no
+  // well-defined way to tell), but it becomes a problem if we do try to use it.
+// CHECK-NOT: load %struct.Empty, %struct.Empty* [[EMPTY_PTR]]
+  __builtin_va_list l;
+  __builtin_va_start(l, a);
+  emptyvar = __builtin_va_arg(l, struct Empty);
+  __builtin_va_end(l);
+}
Index: clang/lib/CodeGen/TargetInfo.cpp
===
--- clang/lib/CodeGen/TargetInfo.cpp
+++ clang/lib/CodeGen/TargetInfo.cpp
@@ -7050,10 +7050,10 @@
 
   // Empty records are ignored for parameter passing purposes.
   if (isEmptyRecord(getContext(), Ty, true)) {
-Address Addr = Address(CGF.Builder.CreateLoad(VAListAddr),
-   getVAListElementType(CGF), SlotSize);
-Addr = CGF.Builder.CreateElementBitCast(Addr, CGF.ConvertTypeForMem(Ty));
-return Addr;
+VAListAddr = CGF.Builder.CreateElementBitCast(VAListAddr, CGF.Int8PtrTy);
+auto *Load = CGF.Builder.CreateLoad(VAListAddr);
+Address Addr = Address(Load, CGF.Int8Ty, SlotSize);
+return CGF.Builder.CreateElementBitCast(Addr, CGF.ConvertTypeForMem(Ty));
   }
 
   CharUnits TySize = getContext().getTypeSizeInChars(Ty);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Michael Matz via cfe-commits]

Hello,

On Wed, 16 Nov 2022, Jonathan Wakely wrote:

> > > Unrelated but I was a bit tempted to ask for throwing in
> > > -Wbuiltin-declaration-mismatch to default -Werror while Clang 16 was at
> > > it, but I suppose we don't want the world to burn too much,
> >
> > :-)  It's IMHO a bug in the standard that it misses "if any of its
> > associated headers are included" in the item for reservation of external
> > linkage identifiers; it has that for all other items about reserved
> > identifiers in the Library clause.  If that restriction were added you
> > couldn't justify erroring on the example at hand (because it doesn't
> > include e.g.  and then printf wouldn't be reserved).  A warning
> > is of course always okay and reasonable.  As is, you could justify
> > erroring out, but I too think that would be overzealous.
> 
> 
> I think that's very intentional and not a defect in the standard.
> 
> If one TU was allowed to define:
> 
> void printf() { }
> 
> and have that compiled into the program, then that would cause
> unexpected behaviour for every other TU which includes  and
> calls printf. They would get the non-standard rogue printf.

True.  But suppose the restriction would be added.  I could argue that 
then your problem program (in some other TU) _does_ include the header, 
hence the identifier would have been reserved and so the above definition 
would have been wrong.  I.e. I think adding the restriction wouldn't allow 
the problematic situation either.

I'm aware that the argument would then invoke all the usual problems of 
what constitutes a full program, and if that includes the library even 
when not including headers and so on.  And in any case currently the 
standard does say they're reserved so it's idle speculation anyway :)


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

[PATCH] D137875: clang/AMDGPU: Drop volatile from builtin_atomic* pointers

[Matt Arsenault via Phabricator via cfe-commits]

arsenm added a comment.

ping


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

https://reviews.llvm.org/D137875

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

[PATCH] D126818: Itanium ABI: Implement mangling for constrained friends

[Erich Keane via Phabricator via cfe-commits]

erichkeane updated this revision to Diff 475836.
erichkeane added a comment.

Updated to work via option-3 above, I believe this is the appropriate solution 
based on the itanium proposal and the C++ standard.  @rjmccall, what concerns 
do we still have about Itanium being willing to add this?  Do we think any 
progress is EVER going to be made?


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

https://reviews.llvm.org/D126818

Files:
  clang/lib/AST/ItaniumMangle.cpp
  clang/test/CodeGenCXX/friend-concepts-mangling.cpp

Index: clang/test/CodeGenCXX/friend-concepts-mangling.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/friend-concepts-mangling.cpp
@@ -0,0 +1,71 @@
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -std=c++20 -emit-llvm -o - %s | FileCheck %s
+
+// See US115 from P2103R0 and 
+// https://github.com/itanium-cxx-abi/cxx-abi/issues/24.
+// Friends that have concept constraints that refer to a containing template 
+// (which makes them required to be a definition) must mangle their containing
+// type.
+struct Base {};
+
+template 
+struct S : public Base {
+  friend int func(Base &)
+requires(N == 1)
+{ return 1; }
+  friend int func(Base &)
+requires(N == 2)
+{ return 3; }
+  // Without the 'F' mangling addition, this is in conflict with the above.
+  int func(Base &) { return 5; }
+
+  template
+friend int templ_func(Base &)
+requires(N == 1 || N == 2)
+{ return 10; }
+
+  template
+int templ_func(Base &)
+{ return 15; }
+};
+
+void useS() {
+  S<1> s1{};
+  S<2> s2{};
+  auto const func1 = func(s1);
+  // CHECK: call noundef i32 @_ZN1SILi1EEF4funcER4Base
+  auto const func2 = func(s2);
+  // CHECK: call noundef i32 @_ZN1SILi2EEF4funcER4Base
+
+  // These have the same signature, so we need to make sure they have a
+  // different mangling (or more correctly, that the friend functions do not
+  // conflict). Note that these are the same as above, with the exception of the
+  // missing 'F' before the unqualified name.
+  auto const func3 = s1.func(s1);
+  // CHECK: call noundef i32 @_ZN1SILi1EE4funcER4Base
+  auto const func4 = s2.func(s2);
+  // CHECK: call noundef i32 @_ZN1SILi2EE4funcER4Base
+
+  auto const templ1 = templ_func(s1);
+  // CHECK: call noundef i32 @_ZN1SILi1EEF10templ_funcIiEEiR4Base
+  auto const templ2 = templ_func(s2);
+  // CHECK: call noundef i32 @_ZN1SILi2EEF10templ_funcIiEEiR4Base
+  auto const templ3 = s1.templ_func(s1);
+  // CHECK: call noundef i32 @_ZN1SILi1EE10templ_funcIiEEiR4Base
+  auto const templ4 = s2.templ_func(s2);
+  // CHECK: call noundef i32 @_ZN1SILi2EE10templ_funcIiEEiR4Base
+}
+
+
+template
+struct U {
+  friend void foo(int) requires (N == 1) {}
+  friend void foo(int) requires (N == 2) {}
+  operator int() const;
+};
+
+void UseU() {
+  foo(U<1>{});
+  // CHECK: call void @_ZN1UILi1EEF3fooEi
+  foo(U<2>{});
+  // CHECK: call void @_ZN1UILi2EEF3fooEi
+}
Index: clang/lib/AST/ItaniumMangle.cpp
===
--- clang/lib/AST/ItaniumMangle.cpp
+++ clang/lib/AST/ItaniumMangle.cpp
@@ -610,6 +610,26 @@
   return StdNamespace;
 }
 
+// Determine if this is a constrained friend that meets the requirements to be a
+// different scope, according to [temp.friend]p9.
+static bool IsDifferentlyMangledConstrainedFriend(const Decl *D) {
+  if (const auto *FTD = dyn_cast(D))
+return IsDifferentlyMangledConstrainedFriend(FTD->getTemplatedDecl());
+
+  if (D->getFriendObjectKind() == Decl::FOK_None)
+return false;
+
+  const FunctionDecl *FD = dyn_cast(D);
+
+  if (!FD)
+return false;
+
+  if (FD->getPrimaryTemplate())
+return FD->FriendConstraintRefersToEnclosingTemplate();
+
+  return FD->getTrailingRequiresClause();
+}
+
 /// Retrieve the declaration context that should be used when mangling the given
 /// declaration.
 const DeclContext *
@@ -659,6 +679,11 @@
 if (FD->isExternC())
   return getASTContext().getTranslationUnitDecl();
 
+  // If these are mangled differently because they are constrained friends,
+  // mangle it in its lexical context.
+  if (IsDifferentlyMangledConstrainedFriend(D))
+return D->getLexicalDeclContext();
+
   return DC->getRedeclContext();
 }
 
@@ -1694,13 +1719,22 @@
   Out << II->getLength() << II->getName();
 }
 
+// See if the 'F' between the prefix of a nested name or nested template is
+// necessary.  That is, is this a friend with a constraint that refers to an
+// enclosing template.
+static void mangleConstrainedFriendness(llvm::raw_ostream &Out, GlobalDecl GD) {
+  if (IsDifferentlyMangledConstrainedFriend(GD.getDecl()))
+  Out << 'F';
+}
+
 void CXXNameMangler::mangleNestedName(GlobalDecl GD,
   const DeclContext *DC,
   const AbiTagList *AdditionalAbiTags,
   bool NoFunction) {
   const NamedDecl *ND = cast(GD.getDecl()

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Jonathan Wakely via cfe-commits]

On Wed, 16 Nov 2022 at 16:34, Michael Matz  wrote:
>
> Hello,
>
> On Wed, 16 Nov 2022, Jonathan Wakely wrote:
>
> > > > Unrelated but I was a bit tempted to ask for throwing in
> > > > -Wbuiltin-declaration-mismatch to default -Werror while Clang 16 was at
> > > > it, but I suppose we don't want the world to burn too much,
> > >
> > > :-)  It's IMHO a bug in the standard that it misses "if any of its
> > > associated headers are included" in the item for reservation of external
> > > linkage identifiers; it has that for all other items about reserved
> > > identifiers in the Library clause.  If that restriction were added you
> > > couldn't justify erroring on the example at hand (because it doesn't
> > > include e.g.  and then printf wouldn't be reserved).  A warning
> > > is of course always okay and reasonable.  As is, you could justify
> > > erroring out, but I too think that would be overzealous.
> >
> >
> > I think that's very intentional and not a defect in the standard.
> >
> > If one TU was allowed to define:
> >
> > void printf() { }
> >
> > and have that compiled into the program, then that would cause
> > unexpected behaviour for every other TU which includes  and
> > calls printf. They would get the non-standard rogue printf.
>
> True.  But suppose the restriction would be added.  I could argue that
> then your problem program (in some other TU) _does_ include the header,
> hence the identifier would have been reserved and so the above definition
> would have been wrong.  I.e. I think adding the restriction wouldn't allow
> the problematic situation either.
>
> I'm aware that the argument would then invoke all the usual problems of
> what constitutes a full program, and if that includes the library even
> when not including headers and so on.  And in any case currently the
> standard does say they're reserved so it's idle speculation anyway :)

Since we're idly speculating anyway ...

I'd always assumed the "if any of its associated headers is included"
meant in the current TU, but it doesn't actually say that. Which does
suggest that I can't use the identifier "assert" anywhere in a program
if any TU in the program includes . Huh.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D127762#3930988 , @paulwalker-arm 
wrote:

> Hi @rsandifo-arm , what are your thoughts on Arron's observations? My 
> interpretation is that Arm originally figured the distinction between 
> keywords and gnu attributes was minimal and thus using our previous norms 
> made most sense. This is not my world so my understanding is somewhat naive 
> but it does sound like Arron has raised some good reasons why keywords are a 
> better design decision.  Do you agree? I wonder if it's worth having this 
> conversation on https://github.com/ARM-software/abi-aa/pull/123 (unless 
> Richard has a better link) so we can capture the rational for future design 
> changes if any. @aaron.ballman, are you ok with this or do you prefer to keep 
> the design conversation linked to this clang implementation?

I'm fine having that conversation on the design document rather than here on 
the review. We can use links to connect the dots between the design pull 
request and the phab review.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127762

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

[PATCH] D137979: parse: process GNU and standard attributes on top-level decls

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel added inline comments.



Comment at: clang/unittests/Tooling/SourceCodeTest.cpp:259-268
+  // Includes attributes through macro expansion.
+  Visitor.runOverAnnotated(R"cpp(
+  #define MACRO_EXPANSION __attribute__((deprecated("message")))
+  $r[[MACRO_EXPANSION
+  int x;]])cpp");
+
+  // Includes attributes through macro expansion with comments.

Added tests, here and below, look good to me. Thanks!


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

https://reviews.llvm.org/D137979

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

[PATCH] D137986: [Clang][CodeGen][AIX] Map __builtin_frexpl, __builtin_ldexpl, and __builtin_modfl to 'double' version lib calls in 64-bit 'long double' mode

[David Tenty via Phabricator via cfe-commits]

daltenty added inline comments.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:110
+  // The AIX library functions frexpl, ldexpl, and modfl are for 128-bit
+  // 'long double'. Map to the 'double' versions if it is 64-bit 'long
+  // double' mode.

I feel like we should be clear about which 128-bit double format we are talking 
about, since it may not be immediately clear for folks who aren't intimately 
familiar with AIX. Maybe we can reference __ibm128 or ibm 128-bit, so it's 
clear what we mean.



Comment at: clang/test/CodeGen/aix-builtin-mapping.c:2
+// AIX library functions frexpl, ldexpl, and modfl are for 128-bit
+// 'long double'. Check that the compiler generates calls to the 'double'
+// versions for correspoding builtin functions in 64-bit 'long double' mode.





Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137986

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

[PATCH] D138117: [clang][docs] Correct floating point option explanations

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

It would probably be better to make these changes with the appropriate code 
changes you are making for each semantic mode. And may be keep this patch only 
for the other changes you are proposing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138117

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

[PATCH] D137024: [compiler-rt] Switch from llvm-config to find_package(LLVM)

[Brittany Blue Gaston via Phabricator via cfe-commits]

thetruestblue added a comment.

This breaks our use case. We run sanitizer tests built in a standalone build 
using an artifact toolchain that contains binaries only. 
Compiler-rt tests rely on the llvm tools binary being in the PATH.

This patch removes the logic that sets the binary tools dir using llvm-config. 
We don't have llvmConfig.cmake in our toolchain relied on llvm-config to 
set(LLVM_TOOLS_BINARY_DIR "${LLVM_TOOLS_BINARY_DIR}"directory.

We can work around this by setting the LLVM_TOOLS_BINARY_DIR directly (and 
potentially other paths... tbd).

But I think we need to reactor this cmake file so that this is considered a 
valid code path.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137024

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

[PATCH] D138117: [clang][docs] Correct floating point option explanations

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

In D138117#3930423 , @kawashima-fj 
wrote:

> I don't know it is inteded that `-fno-fast-math` does not imply 
> `-ftrapping-math` and `-frounding-math`.
> `-ffast-math` and `-fno-fast-math` is not symmetric in 
> RenderFloatingPointOptions 
> .

I would think that there should be symmetry between ffast-math and 
fno-fast-math.  Unless there is a good reason for it, in which case a comment 
should be added? @andrew.w.kaylor WDYT?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138117

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

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

[Reid Kleckner via Phabricator via cfe-commits]

rnk added subscribers: efriedma, hans.
rnk added a comment.

Sorry for the delay, dev meeting. I think we should try to add some reviewers 
for IR gen to help, I don't have a lot of time to be responsive:
https://github.com/llvm/llvm-project/blob/main/clang/CodeOwners.rst#clang-llvm-ir-generation
+@efriedma @hans




Comment at: clang/test/CodeGenCXX/PR19955.cpp:17
 
-// CHECK-LABEL: @"??__Evarp@@YAXXZ"
-// CHECK-DAG: store ptr @"?var@@3HA", ptr @"?varp@@3PAHA"

This seems concerning to me, are we sure this is the right change? It's 
important that `varp` points to the imported `var`, and not a local copy, which 
is what https://llvm.org/PR19955 deals with.


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

https://reviews.llvm.org/D137107

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

[PATCH] D137024: [compiler-rt] Switch from llvm-config to find_package(LLVM)

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

mgorny added a comment.

In D137024#3931126 , @thetruestblue 
wrote:

> This patch removes the logic that sets the binary tools dir using 
> llvm-config. We don't have llvmConfig.cmake in our toolchain or our build 
> tree and relied on llvm-config to 
> set(LLVM_TOOLS_BINARY_DIR "${LLVM_TOOLS_BINARY_DIR}"directory.

While I sympathize with you, I don't think this is valid reason to maintain 
full compatibility with `llvm-config`. Unless i'm mistaken, its use for 
building other LLVM projects standalone was deprecated for a few years already, 
and compiler-rt was the last project to carry the compatibility code. 
Furthermore, skipping cmake files from LLVM seems wrong.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137024

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

[PATCH] D138078: [CodeGenPrepare] split critical indirect edges from callbr w/ outputs

[Nick Desaulniers via Phabricator via cfe-commits]

nickdesaulniers planned changes to this revision.
nickdesaulniers added a comment.

> the question "when is the best time to split critical edges" is perhaps 
> important to consider.



In D138078#3929590 , @efriedma wrote:

> You can't put transforms that are necessary for correctness in 
> CodeGenPrepare; it isn't enabled at -O0.

Of course...

ok overnight I was thinking maybe we do the critical edge splitting on the MBB 
level based on if the BB has a critical edge (in 
`SelectionDAGBuilder::visitCallBr`).  Then I think we can remove the 
`isInlineAsmBrIndirectTarget` guard from 
`MachineBasicBlock::canSplitCriticalEdge` (I wonder if we always eagerly split 
critical edges, if we might be able to remove the 
`MachineBasicBlock::IsInlineAsmBrIndirectTarget` machinery outright, but that 
might be too aggressive).  Let me play with doing the splitting in 
`SelectionDAGBuilder::visitCallBr`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138078

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

[PATCH] D138047: Fix use of dangling stack allocated string in IncludeFixer

[David Goldman via Phabricator via cfe-commits]

dgoldman updated this revision to Diff 475850.
dgoldman added a comment.

Fix in ParsedAST.cpp


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138047

Files:
  clang-tools-extra/clangd/ParsedAST.cpp


Index: clang-tools-extra/clangd/ParsedAST.cpp
===
--- clang-tools-extra/clangd/ParsedAST.cpp
+++ clang-tools-extra/clangd/ParsedAST.cpp
@@ -465,6 +465,8 @@
   std::vector> CTChecks;
   ast_matchers::MatchFinder CTFinder;
   llvm::Optional CTContext;
+  // Must outlive FixIncludes.
+  auto BuildDir = VFS->getCurrentWorkingDirectory();
   llvm::Optional FixIncludes;
   llvm::DenseMap OverriddenSeverity;
   // No need to run clang-tidy or IncludeFixerif we are not going to surface
@@ -551,7 +553,6 @@
 
 // Add IncludeFixer which can recover diagnostics caused by missing 
includes
 // (e.g. incomplete type) and attach include insertion fixes to 
diagnostics.
-auto BuildDir = VFS->getCurrentWorkingDirectory();
 if (Inputs.Index && !BuildDir.getError()) {
   auto Style =
   getFormatStyleForFile(Filename, Inputs.Contents, *Inputs.TFS);


Index: clang-tools-extra/clangd/ParsedAST.cpp
===
--- clang-tools-extra/clangd/ParsedAST.cpp
+++ clang-tools-extra/clangd/ParsedAST.cpp
@@ -465,6 +465,8 @@
   std::vector> CTChecks;
   ast_matchers::MatchFinder CTFinder;
   llvm::Optional CTContext;
+  // Must outlive FixIncludes.
+  auto BuildDir = VFS->getCurrentWorkingDirectory();
   llvm::Optional FixIncludes;
   llvm::DenseMap OverriddenSeverity;
   // No need to run clang-tidy or IncludeFixerif we are not going to surface
@@ -551,7 +553,6 @@
 
 // Add IncludeFixer which can recover diagnostics caused by missing includes
 // (e.g. incomplete type) and attach include insertion fixes to diagnostics.
-auto BuildDir = VFS->getCurrentWorkingDirectory();
 if (Inputs.Index && !BuildDir.getError()) {
   auto Style =
   getFormatStyleForFile(Filename, Inputs.Contents, *Inputs.TFS);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D138047: Fix use of dangling stack allocated string in IncludeFixer

[David Goldman via Phabricator via cfe-commits]

dgoldman added a comment.

In D138047#3930211 , @kadircet wrote:

> yeah unfortunately testing this is hard, but bug&fix are obvious so it's fine 
> to land without a test.
>
> but i think we should rather fix the broken call site at 
> clang-tools-extra/clangd/ParsedAST.cpp and move `BuildDir` to outer scope 
> where it'll outlive IncludeFixer (~line 468).

Done.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138047

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

[PATCH] D137986: [Clang][CodeGen][AIX] Map __builtin_frexpl, __builtin_ldexpl, and __builtin_modfl to 'double' version lib calls in 64-bit 'long double' mode

[Xing Xue via Phabricator via cfe-commits]

xingxue updated this revision to Diff 475853.
xingxue marked 5 inline comments as done.
xingxue edited the summary of this revision.
xingxue added a comment.

Addressed comments:

- rename `AIXLongDoubleBuiltins` to `AIXLongDouble64Builtins`
- test IR output instead of assembly output
- fix a typo in a comment
- mention `frexpl()`, `ldexpl()`, and `modfl()` are for 128-bit IBM `long 
double`, i.e. `__ibm128`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137986

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/aix-builtin-mapping.c


Index: clang/test/CodeGen/aix-builtin-mapping.c
===
--- /dev/null
+++ clang/test/CodeGen/aix-builtin-mapping.c
@@ -0,0 +1,22 @@
+// AIX library functions frexpl, ldexpl, and modfl are for 128-bit IBM
+// 'long double' (i.e. __ibm128). Check that the compiler generates
+// calls to the 'double' versions for corresponding builtin functions in
+// 64-bit 'long double' mode.
+
+// RUN: %clang_cc1 -triple powerpc-ibm-aix -mlong-double-64 -emit-llvm -o - %s 
| FileCheck -check-prefix=CHECK %s
+// RUN: %clang_cc1 -triple powerpc64-ibm-aix -mlong-double-64 -emit-llvm -o - 
%s | FileCheck -check-prefix=CHECK %s
+
+int main()
+{
+  int DummyInt;
+  long double DummyLongDouble;
+  long double returnValue;
+
+  returnValue = __builtin_modfl(1.0L, &DummyLongDouble);
+  returnValue = __builtin_frexpl(0.0L, &DummyInt);
+  returnValue = __builtin_ldexpl(1.0L, 1);
+}
+
+// CHECK: %call = call double @modf(double noundef 1.00e+00, ptr noundef 
%DummyLongDouble) #3
+// CHECK: %call1 = call double @frexp(double noundef 0.00e+00, ptr noundef 
%DummyInt) #3
+// CHECK: %call2 = call double @ldexp(double noundef 1.00e+00, i32 noundef 
{{(signext )?}}1) #4
Index: clang/lib/CodeGen/CGBuiltin.cpp
===
--- clang/lib/CodeGen/CGBuiltin.cpp
+++ clang/lib/CodeGen/CGBuiltin.cpp
@@ -106,6 +106,15 @@
   {Builtin::BI__builtin_nexttowardf128, "__nexttowardieee128"},
   };
 
+  // The AIX library functions frexpl, ldexpl, and modfl are for 128-bit
+  // IBM 'long double' (i.e. __ibm128). Map to the 'double' versions
+  // if it is 64-bit 'long double' mode.
+  static SmallDenseMap AIXLongDouble64Builtins{
+  {Builtin::BI__builtin_frexpl, "frexp"},
+  {Builtin::BI__builtin_ldexpl, "ldexp"},
+  {Builtin::BI__builtin_modfl, "modf"},
+  };
+
   // If the builtin has been declared explicitly with an assembler label,
   // use the mangled name. This differs from the plain label on platforms
   // that prefix labels.
@@ -118,6 +127,12 @@
 &getTarget().getLongDoubleFormat() == &llvm::APFloat::IEEEquad() &&
 F128Builtins.find(BuiltinID) != F128Builtins.end())
   Name = F128Builtins[BuiltinID];
+else if (getTriple().isOSAIX() &&
+ &getTarget().getLongDoubleFormat() ==
+ &llvm::APFloat::IEEEdouble() &&
+ AIXLongDouble64Builtins.find(BuiltinID) !=
+ AIXLongDouble64Builtins.end())
+  Name = AIXLongDouble64Builtins[BuiltinID];
 else
   Name = Context.BuiltinInfo.getName(BuiltinID) + 10;
   }


Index: clang/test/CodeGen/aix-builtin-mapping.c
===
--- /dev/null
+++ clang/test/CodeGen/aix-builtin-mapping.c
@@ -0,0 +1,22 @@
+// AIX library functions frexpl, ldexpl, and modfl are for 128-bit IBM
+// 'long double' (i.e. __ibm128). Check that the compiler generates
+// calls to the 'double' versions for corresponding builtin functions in
+// 64-bit 'long double' mode.
+
+// RUN: %clang_cc1 -triple powerpc-ibm-aix -mlong-double-64 -emit-llvm -o - %s | FileCheck -check-prefix=CHECK %s
+// RUN: %clang_cc1 -triple powerpc64-ibm-aix -mlong-double-64 -emit-llvm -o - %s | FileCheck -check-prefix=CHECK %s
+
+int main()
+{
+  int DummyInt;
+  long double DummyLongDouble;
+  long double returnValue;
+
+  returnValue = __builtin_modfl(1.0L, &DummyLongDouble);
+  returnValue = __builtin_frexpl(0.0L, &DummyInt);
+  returnValue = __builtin_ldexpl(1.0L, 1);
+}
+
+// CHECK: %call = call double @modf(double noundef 1.00e+00, ptr noundef %DummyLongDouble) #3
+// CHECK: %call1 = call double @frexp(double noundef 0.00e+00, ptr noundef %DummyInt) #3
+// CHECK: %call2 = call double @ldexp(double noundef 1.00e+00, i32 noundef {{(signext )?}}1) #4
Index: clang/lib/CodeGen/CGBuiltin.cpp
===
--- clang/lib/CodeGen/CGBuiltin.cpp
+++ clang/lib/CodeGen/CGBuiltin.cpp
@@ -106,6 +106,15 @@
   {Builtin::BI__builtin_nexttowardf128, "__nexttowardieee128"},
   };
 
+  // The AIX library functions frexpl, ldexpl, and modfl are for 128-bit
+  // IBM 'long double' (i.e. __ibm128). Map to the 'double' versions
+  // if it is 64-bit 'long double' mode.
+  static SmallDenseMap AIXLongDouble64Buil

[PATCH] D138047: Fix use of dangling stack allocated string in IncludeFixer

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet accepted this revision.
kadircet 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/D138047/new/

https://reviews.llvm.org/D138047

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

[PATCH] D138143: [FPEnv] Enable strict fp for AArch64 in clang

[John Brawn via Phabricator via cfe-commits]

john.brawn created this revision.
john.brawn added reviewers: t.p.northover, fhahn, umesh.kalappa0.
Herald added subscribers: arphaman, kristof.beyls.
Herald added a project: All.
john.brawn requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

The AArch64 target now has the necessary support for strict fp, so enable it in 
clang.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D138143

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Basic/Targets/AArch64.cpp
  clang/test/CodeGen/aarch64-neon-intrinsics-constrained.c
  clang/test/CodeGen/aarch64-neon-misc-constrained.c
  clang/test/CodeGen/aarch64-neon-scalar-x-indexed-elem-constrained.c
  clang/test/CodeGen/aarch64-strictfp-builtins.c
  clang/test/CodeGen/aarch64-v8.2a-fp16-intrinsics-constrained.c
  clang/test/CodeGen/aarch64-v8.2a-neon-intrinsics-constrained.c
  clang/test/CodeGen/arm-neon-directed-rounding-constrained.c
  clang/test/CodeGen/arm64-vrnd-constrained.c
  clang/test/CodeGen/fp16-ops-strictfp.c
  clang/test/Parser/pragma-fp-warn.c

Index: clang/test/Parser/pragma-fp-warn.c
===
--- clang/test/Parser/pragma-fp-warn.c
+++ clang/test/Parser/pragma-fp-warn.c
@@ -1,7 +1,7 @@
 
 // RUN: %clang_cc1 -triple wasm32 -fsyntax-only -Wno-unknown-pragmas -Wignored-pragmas -verify %s
 // RUN: %clang_cc1 -triple thumbv7 -fsyntax-only -Wno-unknown-pragmas -Wignored-pragmas -verify %s
-// RUN: %clang_cc1 -triple aarch64 -fsyntax-only -Wno-unknown-pragmas -Wignored-pragmas -verify %s
+// RUN: %clang_cc1 -DEXPOK -triple aarch64 -fsyntax-only -Wno-unknown-pragmas -Wignored-pragmas -verify %s
 // RUN: %clang_cc1 -DEXPOK -triple x86_64 -fsyntax-only -Wno-unknown-pragmas -Wignored-pragmas -verify %s
 // RUN: %clang_cc1 -DEXPOK -triple systemz -fsyntax-only -Wno-unknown-pragmas -Wignored-pragmas -verify %s
 // RUN: %clang_cc1 -DEXPOK -triple powerpc -fsyntax-only -Wno-unknown-pragmas -Wignored-pragmas -verify %s
Index: clang/test/CodeGen/fp16-ops-strictfp.c
===
--- clang/test/CodeGen/fp16-ops-strictfp.c
+++ clang/test/CodeGen/fp16-ops-strictfp.c
@@ -1,10 +1,10 @@
 // REQUIRES: arm-registered-target
 // RUN: %clang_cc1 -ffp-exception-behavior=maytrap -fexperimental-strict-floating-point -emit-llvm -o - -triple arm-none-linux-gnueabi %s | FileCheck %s --check-prefix=NOTNATIVE --check-prefix=CHECK -vv -dump-input=fail
-// RUN: %clang_cc1 -ffp-exception-behavior=maytrap -fexperimental-strict-floating-point -emit-llvm -o - -triple aarch64-none-linux-gnueabi %s | FileCheck %s --check-prefix=NOTNATIVE --check-prefix=CHECK
+// RUN: %clang_cc1 -ffp-exception-behavior=maytrap -emit-llvm -o - -triple aarch64-none-linux-gnueabi %s | FileCheck %s --check-prefix=NOTNATIVE --check-prefix=CHECK
 // RUN: %clang_cc1 -ffp-exception-behavior=maytrap -fexperimental-strict-floating-point -emit-llvm -o - -triple x86_64-linux-gnu %s | FileCheck %s --check-prefix=NOTNATIVE --check-prefix=CHECK
 // RUN: %clang_cc1 -ffp-exception-behavior=maytrap -fexperimental-strict-floating-point -emit-llvm -o - -triple arm-none-linux-gnueabi -fnative-half-type %s \
 // RUN:   | FileCheck %s --check-prefix=NATIVE-HALF --check-prefix=CHECK
-// RUN: %clang_cc1 -ffp-exception-behavior=maytrap -fexperimental-strict-floating-point -emit-llvm -o - -triple aarch64-none-linux-gnueabi -fnative-half-type %s \
+// RUN: %clang_cc1 -ffp-exception-behavior=maytrap -emit-llvm -o - -triple aarch64-none-linux-gnueabi -fnative-half-type %s \
 // RUN:   | FileCheck %s --check-prefix=NATIVE-HALF --check-prefix=CHECK
 //
 // Test that the constrained intrinsics are picking up the exception
Index: clang/test/CodeGen/arm64-vrnd-constrained.c
===
--- clang/test/CodeGen/arm64-vrnd-constrained.c
+++ clang/test/CodeGen/arm64-vrnd-constrained.c
@@ -1,10 +1,10 @@
 // RUN: %clang_cc1 -triple arm64-apple-ios7 -target-feature +neon -ffreestanding -flax-vector-conversions=none -emit-llvm -o - %s \
 // RUN: | FileCheck --check-prefix=COMMON --check-prefix=UNCONSTRAINED %s
-// RUN: %clang_cc1 -triple arm64-apple-ios7 -target-feature +neon -ffreestanding -flax-vector-conversions=none -fexperimental-strict-floating-point -ffp-exception-behavior=strict -emit-llvm -o - %s \
+// RUN: %clang_cc1 -triple arm64-apple-ios7 -target-feature +neon -ffreestanding -flax-vector-conversions=none -ffp-exception-behavior=strict -emit-llvm -o - %s \
 // RUN: | FileCheck --check-prefix=COMMON --check-prefix=CONSTRAINED %s
 // RUN: %clang_cc1 -triple arm64-apple-ios7 -target-feature +neon -ffreestanding -flax-vector-conversions=none -emit-llvm -o - %s | llc -o=- - \
 // RUN: | FileCheck --check-prefix=COMMON --check-prefix=CHECK-ASM %s
-// RUN: %clang_cc1 -triple arm64-apple-ios7 -target-feature +neon -ffreestanding -flax-vector-conversions=none -fexperimental-strict-floating-point -ffp-exception-behavi

[PATCH] D138078: [CodeGenPrepare] split critical indirect edges from callbr w/ outputs

[Nick Desaulniers via Phabricator via cfe-commits]

nickdesaulniers added a comment.

> in SelectionDAGBuilder::visitCallBr

So the issue I hit immediate is that the ValueMap SelectionDAG has maps the 
indirect destination BB to the original MBB; I can't split the edge and have 
the CallBrInst lower correctly to refer to the synthesized MBB.

I think I can reuse this commit mostly as is, just move it from codegen prepare 
to another pass.

It looks like `indirectbr-expand` _is_ enabled at `-O0` and is necessary for 
correctness IIUC.  Thoughts on moving this there, and maybe renaming the pass 
to `indirectbr-callbr-expand`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138078

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

[PATCH] D137835: [ARM] Move ARM::parseBranchProtection into ARMTargetParserCommon

[Sam Elliott via Phabricator via cfe-commits]

lenary retitled this revision from "[ARM] Move ARM::parseBranchProtection into 
ARMTargetParser" to "[ARM] Move ARM::parseBranchProtection into 
ARMTargetParserCommon".
lenary edited the summary of this revision.
lenary updated this revision to Diff 475860.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137835

Files:
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Basic/Targets/AArch64.h
  clang/lib/Basic/Targets/ARM.cpp
  clang/lib/Basic/Targets/ARM.h
  clang/lib/Driver/ToolChains/Clang.cpp
  llvm/include/llvm/Support/ARMTargetParserCommon.h
  llvm/include/llvm/Support/TargetParser.h
  llvm/lib/Support/ARMTargetParserCommon.cpp
  llvm/lib/Support/TargetParser.cpp

Index: llvm/lib/Support/TargetParser.cpp
===
--- llvm/lib/Support/TargetParser.cpp
+++ llvm/lib/Support/TargetParser.cpp
@@ -337,51 +337,3 @@
 
 } // namespace RISCV
 } // namespace llvm
-
-// Parse a branch protection specification, which has the form
-//   standard | none | [bti,pac-ret[+b-key,+leaf]*]
-// Returns true on success, with individual elements of the specification
-// returned in `PBP`. Returns false in error, with `Err` containing
-// an erroneous part of the spec.
-bool ARM::parseBranchProtection(StringRef Spec, ParsedBranchProtection &PBP,
-StringRef &Err) {
-  PBP = {"none", "a_key", false};
-  if (Spec == "none")
-return true; // defaults are ok
-
-  if (Spec == "standard") {
-PBP.Scope = "non-leaf";
-PBP.BranchTargetEnforcement = true;
-return true;
-  }
-
-  SmallVector Opts;
-  Spec.split(Opts, "+");
-  for (int I = 0, E = Opts.size(); I != E; ++I) {
-StringRef Opt = Opts[I].trim();
-if (Opt == "bti") {
-  PBP.BranchTargetEnforcement = true;
-  continue;
-}
-if (Opt == "pac-ret") {
-  PBP.Scope = "non-leaf";
-  for (; I + 1 != E; ++I) {
-StringRef PACOpt = Opts[I + 1].trim();
-if (PACOpt == "leaf")
-  PBP.Scope = "all";
-else if (PACOpt == "b-key")
-  PBP.Key = "b_key";
-else
-  break;
-  }
-  continue;
-}
-if (Opt == "")
-  Err = "";
-else
-  Err = Opt;
-return false;
-  }
-
-  return true;
-}
Index: llvm/lib/Support/ARMTargetParserCommon.cpp
===
--- llvm/lib/Support/ARMTargetParserCommon.cpp
+++ llvm/lib/Support/ARMTargetParserCommon.cpp
@@ -11,6 +11,7 @@
 //===--===//
 
 #include "llvm/Support/ARMTargetParserCommon.h"
+#include "llvm/ADT/SmallVector.h"
 #include "llvm/ADT/StringSwitch.h"
 
 using namespace llvm;
@@ -103,3 +104,51 @@
   // Arch will either be a 'v' name (v7a) or a marketing name (xscale).
   return A;
 }
+
+// Parse a branch protection specification, which has the form
+//   standard | none | [bti,pac-ret[+b-key,+leaf]*]
+// Returns true on success, with individual elements of the specification
+// returned in `PBP`. Returns false in error, with `Err` containing
+// an erroneous part of the spec.
+bool ARM::parseBranchProtection(StringRef Spec, ParsedBranchProtection &PBP,
+StringRef &Err) {
+  PBP = {"none", "a_key", false};
+  if (Spec == "none")
+return true; // defaults are ok
+
+  if (Spec == "standard") {
+PBP.Scope = "non-leaf";
+PBP.BranchTargetEnforcement = true;
+return true;
+  }
+
+  SmallVector Opts;
+  Spec.split(Opts, "+");
+  for (int I = 0, E = Opts.size(); I != E; ++I) {
+StringRef Opt = Opts[I].trim();
+if (Opt == "bti") {
+  PBP.BranchTargetEnforcement = true;
+  continue;
+}
+if (Opt == "pac-ret") {
+  PBP.Scope = "non-leaf";
+  for (; I + 1 != E; ++I) {
+StringRef PACOpt = Opts[I + 1].trim();
+if (PACOpt == "leaf")
+  PBP.Scope = "all";
+else if (PACOpt == "b-key")
+  PBP.Key = "b_key";
+else
+  break;
+  }
+  continue;
+}
+if (Opt == "")
+  Err = "";
+else
+  Err = Opt;
+return false;
+  }
+
+  return true;
+}
Index: llvm/include/llvm/Support/TargetParser.h
===
--- llvm/include/llvm/Support/TargetParser.h
+++ llvm/include/llvm/Support/TargetParser.h
@@ -182,19 +182,6 @@
 bool getCPUFeaturesExceptStdExt(CPUKind Kind, std::vector &Features);
 
 } // namespace RISCV
-
-namespace ARM {
-struct ParsedBranchProtection {
-  StringRef Scope;
-  StringRef Key;
-  bool BranchTargetEnforcement;
-};
-
-bool parseBranchProtection(StringRef Spec, ParsedBranchProtection &PBP,
-   StringRef &Err);
-
-} // namespace ARM
-
 } // namespace llvm
 
 #endif
Index: llvm/include/llvm/Support/ARMTargetParserCommon.h
===
--- llvm/include/llvm/Support

[PATCH] D134921: [HLSL] add cos library function

[Joshua Batista via Phabricator via cfe-commits]

bob80905 updated this revision to Diff 475861.
bob80905 added a comment.

- clang format


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134921

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

Index: clang/test/CodeGenHLSL/builtins/cos.hlsl
===
--- /dev/null
+++ clang/test/CodeGenHLSL/builtins/cos.hlsl
@@ -0,0 +1,56 @@
+// RUN: %clang_cc1 -std=hlsl2021 -finclude-default-header -x hlsl -triple \
+// RUN:   dxil-pc-shadermodel6.3-library %s -fnative-half-type \
+// RUN:   -emit-llvm -disable-llvm-passes -O3 -o - | FileCheck %s
+// RUN: %clang_cc1 -std=hlsl2021 -finclude-default-header -x hlsl -triple \
+// RUN:   dxil-pc-shadermodel6.3-library %s -emit-llvm -disable-llvm-passes \
+// RUN:   -D__HLSL_ENABLE_16_BIT -o - | FileCheck %s --check-prefix=NO_HALF
+
+// CHECK: define noundef half @
+// CHECK: call half @llvm.cos.f16(
+// NO_HALF: define noundef float @"?test_cos_half@@YA$halff@$halff@@Z"(
+// NO_HALF: call float @llvm.cos.f32(
+half test_cos_half ( half p0 ) {
+  return cos ( p0 );
+}
+// CHECK: define noundef <2 x half> @
+// CHECK: call <2 x half> @llvm.cos.v2f16
+// NO_HALF: define noundef <2 x float> @"?test_cos_float2@@YAT?$__vector@M$01@__clang@@T12@@Z"(
+// NO_HALF: call <2 x float> @llvm.cos.v2f32(
+half2 test_cos_half2 ( half2 p0 ) {
+  return cos ( p0 );
+}
+// CHECK: define noundef <3 x half> @
+// CHECK: call <3 x half> @llvm.cos.v3f16
+// NO_HALF: define noundef <3 x float> @"?test_cos_float3@@YAT?$__vector@M$02@__clang@@T12@@Z"(
+// NO_HALF: call <3 x float> @llvm.cos.v3f32(
+half3 test_cos_half3 ( half3 p0 ) {
+  return cos ( p0 );
+}
+// CHECK: define noundef <4 x half> @
+// CHECK: call <4 x half> @llvm.cos.v4f16
+// NO_HALF: define noundef <4 x float> @"?test_cos_float4@@YAT?$__vector@M$03@__clang@@T12@@Z"(
+// NO_HALF: call <4 x float> @llvm.cos.v4f32(
+half4 test_cos_half4 ( half4 p0 ) {
+  return cos ( p0 );
+}
+
+// CHECK: define noundef float @
+// CHECK: call float @llvm.cos.f32(
+float test_cos_float ( float p0 ) {
+  return cos ( p0 );
+}
+// CHECK: define noundef <2 x float> @
+// CHECK: call <2 x float> @llvm.cos.v2f32
+float2 test_cos_float2 ( float2 p0 ) {
+  return cos ( p0 );
+}
+// CHECK: define noundef <3 x float> @
+// CHECK: call <3 x float> @llvm.cos.v3f32
+float3 test_cos_float3 ( float3 p0 ) {
+  return cos ( p0 );
+}
+// CHECK: define noundef <4 x float> @
+// CHECK: call <4 x float> @llvm.cos.v4f32
+float4 test_cos_float4 ( float4 p0 ) {
+  return cos ( p0 );
+}
Index: clang/lib/Headers/hlsl/hlsl_intrinsics.h
===
--- clang/lib/Headers/hlsl/hlsl_intrinsics.h
+++ clang/lib/Headers/hlsl/hlsl_intrinsics.h
@@ -101,6 +101,34 @@
 __attribute__((clang_builtin_alias(__builtin_elementwise_ceil)))
 double4 ceil(double4);
 
-} // namespace hlsl
+// cos builtins
+#ifdef __HLSL_ENABLE_16_BIT
+__attribute__((clang_builtin_alias(__builtin_elementwise_cos))) half cos(half);
+__attribute__((clang_builtin_alias(__builtin_elementwise_cos)))
+half2 cos(half2);
+__attribute__((clang_builtin_alias(__builtin_elementwise_cos)))
+half3 cos(half3);
+__attribute__((clang_builtin_alias(__builtin_elementwise_cos)))
+half4 cos(half4);
+#endif
 
+__attribute__((clang_builtin_alias(__builtin_elementwise_cos))) float
+cos(float);
+__attribute__((clang_builtin_alias(__builtin_elementwise_cos)))
+float2 cos(float2);
+__attribute__((clang_builtin_alias(__builtin_elementwise_cos)))
+float3 cos(float3);
+__attribute__((clang_builtin_alias(__builtin_elementwise_cos)))
+float4 cos(float4);
+
+__attribute__((clang_builtin_alias(__builtin_elementwise_cos))) double
+cos(double);
+__attribute__((clang_builtin_alias(__builtin_elementwise_cos)))
+double2 cos(double2);
+__attribute__((clang_builtin_alias(__builtin_elementwise_cos)))
+double3 cos(double3);
+__attribute__((clang_builtin_alias(__builtin_elementwise_cos)))
+double4 cos(double4);
+
+} // namespace hlsl
 #endif //_HLSL_HLSL_INTRINSICS_H_
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Eli Friedman via Phabricator via cfe-commits]

efriedma added a comment.

There are multiple notions of "constant" here:

- Whether a value is invariant at runtime.
- Whether a value is legal in a "constexpr" expression.
- Whether we can emit a constant without emitting code that runs at startup to 
initialize it.

The third is generally a superset of the second; most targets have relocations 
that allow us emit the address of a global variable into another global 
variable.  dllimport variables are an exception: even though the address is 
constant, we can't emit a relocation.

To make this work, what we need to do is:

- Extend the notion of a "constant" in the AST/Sema to allow dllimport 
variables.  (There should be code specifically checking for dllimport 
variables; we just need to drop that check.)
- Teach IR generation (clang/lib/CodeGen) how to emit constants that don't have 
a relocation.  This probably means a check that if we're generating the 
initializer for a global variable, and the initializer refers to the address of 
a dllimport variable, we instead emit a global constructor.  (Maybe with a 
higher priority that normal global constructor, so the user can't accidentally 
observe an uninitialized variable?  I forget if MSVC actually has constructor 
priorities...).  Or I guess as an initial patch, we could just emit an error if 
we detect this case.


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

https://reviews.llvm.org/D137107

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

[PATCH] D137835: [ARM] Move ARM::parseBranchProtection into ARMTargetParserCommon

[Sam Elliott via Phabricator via cfe-commits]

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



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:47
 #include "llvm/Option/ArgList.h"
+#include "llvm/Support/ARMTargetParser.h"
 #include "llvm/Support/CodeGen.h"

tmatheson wrote:
> For consistency this could just come via ARM.h
Not any more! Those two headers don't need ARMTargetParserCommon.h so I moved 
their use into the implementation file, and now this is much better at avoiding 
transitive includes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137835

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

[PATCH] D138115: [clang] Short-circuit evaluation in ::EvaluateAsConstantExpr

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138115

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

[PATCH] D137838: [RFC][Support] Move TargetParsers to new component

[Sam Elliott via Phabricator via cfe-commits]

lenary added a comment.

I've updated the patch to use forwarding headers (and to rebase past some 
changes that have happened in the interim).

The patch is still huge because of the number of places using the 
TargetParsers, which need the component added to their CMakeLists.txt.

I think after the next release, I will add `#warning` to the forwarding 
headers, so their usage can be noticed and updated.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137838

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

[PATCH] D137024: [compiler-rt] Switch from llvm-config to find_package(LLVM)

[Brittany Blue Gaston via Phabricator via cfe-commits]

thetruestblue added a comment.



> While I sympathize with you, I don't think this is valid reason to maintain 
> full compatibility with `llvm-config`.

A standalone build with LLVM_TOOLS_BINARY_DIR set directly could be a valid 
code path. We already have code to mock LLVMConfig.cmake. I believe that the 
mock and setting llvm_tools_dir directly allows compiler-rt is enough to build 
compiler-rt and run tests without llvm. 
Or perhaps a flag to indicate we're mocking llvmconfig?

The goal is to generate compiler-rt lit test suites for an arbitrary LLVM 
toolchain and then run the tests against it.

> Furthermore, skipping cmake files from LLVM seems wrong.

Not sure what you mean. Isn't this the default behavior for toolchain builds 
and standalone builds? If only compiler-rt is built, llvmconfig.cmake isn't 
built/added to build tree. Same for toolchains, which contain only binary 
files. I may be misunderstanding what you mean, though.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137024

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

[PATCH] D138073: [clang-doc] Move file layout to the generators.

[Brett Wilson via Phabricator via cfe-commits]

brettw updated this revision to Diff 475869.
brettw added a comment.

Updated the lit tests.


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

https://reviews.llvm.org/D138073

Files:
  clang-tools-extra/clang-doc/Generators.h
  clang-tools-extra/clang-doc/HTMLGenerator.cpp
  clang-tools-extra/clang-doc/MDGenerator.cpp
  clang-tools-extra/clang-doc/YAMLGenerator.cpp
  clang-tools-extra/clang-doc/tool/ClangDocMain.cpp
  clang-tools-extra/test/clang-doc/single-file-public.cpp
  clang-tools-extra/test/clang-doc/single-file.cpp

Index: clang-tools-extra/test/clang-doc/single-file.cpp
===
--- clang-tools-extra/test/clang-doc/single-file.cpp
+++ clang-tools-extra/test/clang-doc/single-file.cpp
@@ -3,7 +3,7 @@
 // RUN: echo "" > %t/compile_flags.txt
 // RUN: cp "%s" "%t/test.cpp"
 // RUN: clang-doc --doxygen --executor=standalone -p %t %t/test.cpp -output=%t/docs
-// RUN: cat %t/docs/GlobalNamespace/index.yaml | FileCheck %s --check-prefix=CHECK
+// RUN: cat %t/docs/index.yaml | FileCheck %s --check-prefix=CHECK
 // RUN: rm -rf %t
 
 void function(int x);
Index: clang-tools-extra/test/clang-doc/single-file-public.cpp
===
--- clang-tools-extra/test/clang-doc/single-file-public.cpp
+++ clang-tools-extra/test/clang-doc/single-file-public.cpp
@@ -3,7 +3,7 @@
 // RUN: echo "" > %t/compile_flags.txt
 // RUN: cp "%s" "%t/test.cpp"
 // RUN: clang-doc --doxygen --public --executor=standalone -p %t %t/test.cpp -output=%t/docs
-// RUN: cat %t/docs/GlobalNamespace/Record.yaml | FileCheck %s --check-prefix=CHECK
+// RUN: cat %t/docs/`ls %t/docs | grep -v index.yaml` | FileCheck %s --check-prefix=CHECK
 // RUN: rm -rf %t
 
 class Record {
Index: clang-tools-extra/clang-doc/tool/ClangDocMain.cpp
===
--- clang-tools-extra/clang-doc/tool/ClangDocMain.cpp
+++ clang-tools-extra/clang-doc/tool/ClangDocMain.cpp
@@ -43,6 +43,7 @@
 #include "llvm/Support/ThreadPool.h"
 #include "llvm/Support/raw_ostream.h"
 #include 
+#include 
 #include 
 
 using namespace clang::ast_matchers;
@@ -130,54 +131,6 @@
   return llvm::sys::fs::getMainExecutable(Argv0, MainAddr);
 }
 
-bool CreateDirectory(const Twine &DirName, bool ClearDirectory = false) {
-  std::error_code OK;
-  llvm::SmallString<128> DocsRootPath;
-  if (ClearDirectory) {
-std::error_code RemoveStatus = llvm::sys::fs::remove_directories(DirName);
-if (RemoveStatus != OK) {
-  llvm::errs() << "Unable to remove existing documentation directory for "
-   << DirName << ".\n";
-  return true;
-}
-  }
-  std::error_code DirectoryStatus = llvm::sys::fs::create_directories(DirName);
-  if (DirectoryStatus != OK) {
-llvm::errs() << "Unable to create documentation directories.\n";
-return true;
-  }
-  return false;
-}
-
-// A function to extract the appropriate file name for a given info's
-// documentation. The path returned is a composite of the output directory, the
-// info's relative path and name and the extension. The relative path should
-// have been constructed in the serialization phase.
-//
-// Example: Given the below, the  path for class C will be
-// /A/B/C.
-//
-// namespace A {
-// namespace B {
-//
-// class C {};
-//
-// }
-// }
-llvm::Expected> getInfoOutputFile(StringRef Root,
- StringRef RelativePath,
- StringRef Name,
- StringRef Ext) {
-  llvm::SmallString<128> Path;
-  llvm::sys::path::native(Root, Path);
-  llvm::sys::path::append(Path, RelativePath);
-  if (CreateDirectory(Path))
-return llvm::createStringError(llvm::inconvertibleErrorCode(),
-   "failed to create directory");
-  llvm::sys::path::append(Path, Name + Ext);
-  return Path;
-}
-
 int main(int argc, const char **argv) {
   llvm::sys::PrintStackTraceOnErrorSignal(argv[0]);
   std::error_code OK;
@@ -274,6 +227,11 @@
 R.first->second.emplace_back(Value);
   });
 
+  // Collects all Infos according to their unique USR value. This map is added
+  // to from the thread pool below and is protected by the USRToInfoMutex.
+  llvm::sys::Mutex USRToInfoMutex;
+  llvm::StringMap> USRToInfo;
+
   // First reducing phase (reduce all decls into one info per decl).
   llvm::outs() << "Reducing " << USRToBitcode.size() << " infos...\n";
   std::atomic Error;
@@ -304,31 +262,17 @@
 return;
   }
 
-  doc::Info *I = Reduced.get().get();
-  auto InfoPath =
-  getInfoOutputFile(OutDirectory, I->getRelativeFilePath(""),
-I->getFileBaseName(), "." + Format);
-  if (!InfoPath) {
-llvm::errs() << toString(InfoPath.takeError()) << "\n";
-Error = true;
-return;
-  }
-  std::erro

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Paul Eggert via cfe-commits]

On 2022-11-16 06:26, Michael Matz wrote:

char foobar(void);
int main(void) {
   return &foobar != 0;
}


That still has undefined behavior according to draft C23, which says 
behavior is undefined when foobar is (say) 'memset_explicit' because the 
declaration 'char memset_explicit(void);' disagrees with draft C23's 
declaration of 'memset_explicit'. It doesn't matter whether there's a 
call to 'memset_explicit'. See draft C23 §6.2.7, which says "All 
declarations that refer to the same object or function shall have 
compatible type; otherwise, the behavior is undefined."


If Clang's threatened pickiness were of some real use elsewhere, it 
might be justifiable for default Clang to break Autoconf. But so far we 
haven't seen real-world uses that would justify this pickiness for 
Autoconf's use of 'char memset_explicit(void);'.


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

[PATCH] D138081: [IR] Split out IR printing passes into IRPrinter

[Teresa Johnson via Phabricator via cfe-commits]

tejohnson added a comment.

Why not just move IRPrintingPasses.{h,cpp} as is to the new directory, vs 
splitting up the legacy vs new pm handling into separate places?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138081

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

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Jeffrey Walton via cfe-commits]

On Wed, Nov 16, 2022 at 1:18 PM Paul Eggert  wrote:
> ...
> If Clang's threatened pickiness were of some real use elsewhere, it
> might be justifiable for default Clang to break Autoconf. But so far we
> haven't seen real-world uses that would justify this pickiness for
> Autoconf's use of 'char memset_explicit(void);'.

This line of arguments is not persuasive. It is full of logical fallacies.

Maybe the Autoconf folks should argue something along the lines of,
"this is the _only_ way to do it because <...>."

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

[PATCH] D137986: [Clang][CodeGen][AIX] Map __builtin_frexpl, __builtin_ldexpl, and __builtin_modfl to 'double' version lib calls in 64-bit 'long double' mode

[Xing Xue via Phabricator via cfe-commits]

xingxue added inline comments.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:110
+  // The AIX library functions frexpl, ldexpl, and modfl are for 128-bit
+  // 'long double'. Map to the 'double' versions if it is 64-bit 'long
+  // double' mode.

daltenty wrote:
> I feel like we should be clear about which 128-bit double format we are 
> talking about, since it may not be immediately clear for folks who aren't 
> intimately familiar with AIX. Maybe we can reference __ibm128 or ibm 128-bit, 
> so it's clear what we mean.
Modified as suggested, thanks!



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:112
+  // double' mode.
+  static SmallDenseMap AIXLongDoubleBuiltins{
+  {Builtin::BI__builtin_frexpl, "frexp"},

hubert.reinterpretcast wrote:
> Please rename to "AIXLongDouble64Builtins".
Renamed as suggested, thanks!



Comment at: clang/test/CodeGen/aix-builtin-mapping.c:2
+// AIX library functions frexpl, ldexpl, and modfl are for 128-bit
+// 'long double'. Check that the compiler generates calls to the 'double'
+// versions for correspoding builtin functions in 64-bit 'long double' mode.

daltenty wrote:
> 
> 
Modified as suggested, thanks!



Comment at: clang/test/CodeGen/aix-builtin-mapping.c:3
+// 'long double'. Check that the compiler generates calls to the 'double'
+// versions for correspoding builtin functions in 64-bit 'long double' mode.
+

hubert.reinterpretcast wrote:
> Fix typo.
Fixed, thanks for catching it!



Comment at: clang/test/CodeGen/aix-builtin-mapping.c:5-6
+
+// RUN: %clang_cc1 -triple powerpc-ibm-aix -mlong-double-64 -S -o - %s | 
FileCheck %s -check-prefix=CHECK
+// RUN: %clang_cc1 -triple powerpc64-ibm-aix -mlong-double-64 -S -o - %s | 
FileCheck %s -check-prefix=CHECK
+

hubert.reinterpretcast wrote:
> This should be an IR test. Checking assembly means actually needing the 
> PowerPC target enabled in the LLVM configuration.
Changed to use IR, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137986

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

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

[Richard Sandiford via Phabricator via cfe-commits]

rsandifo-arm added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:2000
   "overridden virtual function is here">;
+def err_conflicting_overriding_attributes : Error<
+  "virtual function %0 has different attributes "

aaron.ballman wrote:
> aaron.ballman wrote:
> > rsandifo-arm wrote:
> > > sdesmalen wrote:
> > > > aaron.ballman wrote:
> > > > > sdesmalen wrote:
> > > > > > aaron.ballman wrote:
> > > > > > > This error and the one below make me wonder whether an attribute 
> > > > > > > spelling is the appropriate way to surface this functionality as 
> > > > > > > opposed to a keyword. Attributes don't typically don't cause 
> > > > > > > errors in these situations, but because these attributes are 
> > > > > > > strongly coupled to their type system effects I can see why you 
> > > > > > > want these to be errors.
> > > > > > > This error and the one below make me wonder whether an attribute 
> > > > > > > spelling is the appropriate way to surface this functionality as 
> > > > > > > opposed to a keyword. 
> > > > > > I'm not sure I understand what you mean, do you have an example?
> > > > > `override` and `final` could have been surfaced via attributes, and 
> > > > > in Clang we semantically express them as such (see `Final` and 
> > > > > `Override` in Attr.td), but instead they are surfaced to the user as 
> > > > > keywords in the language standard. You're not under the same 
> > > > > constraints as the standard (you're making a vendor-specific 
> > > > > attribute). We're not super consistent with whether we use the same 
> > > > > approach as the standard (we have some type attributes that are 
> > > > > spelled as attributes like `vector_size` and others that are spelled 
> > > > > via keywords like `_Nullable`.
> > > > > 
> > > > > So you could spell your type attributes the way you have been with 
> > > > > `__attribute__`, or you could come up with keywords for them (so 
> > > > > instead of using `GNU<"whatever">` for the attribute, you could use 
> > > > > `Keyword<_Whatever>` or `Keyword<__whatever>` (you'd also need to add 
> > > > > them as recognized keyword tokens, parse them as appropriate, etc).
> > > > > 
> > > > > Note: I don't insist on you using a keyword for these, but I am 
> > > > > wondering if that approach was considered or not given how 
> > > > > non-portable the attributes are (if an implementation ignores this 
> > > > > attribute, it sounds like the program semantics are unlikely to be 
> > > > > correct).
> > > > @rsandifo-arm can you shed some light on whether using a keyword 
> > > > instead of an `attribute` was considered?
> > > Thanks @aaron.ballman for the reviews.
> > >  
> > > Yeah, we did consider using keywords instead.  The main reason for 
> > > sticking with GNU attributes is that they were specifically designed as 
> > > an extensible way of attaching information or requirements to the source 
> > > code, and they provide well-settled semantics.  It seemed better to reuse 
> > > an existing mechanism rather than invent something new.
> > > 
> > > Also, as C++ evolves, the semantics of GNU attributes evolve to match.  
> > > If we surface the SME features as GNU attributes, we inherit this 
> > > development in the underlying semantics, without having to maintain our 
> > > own evolving specification for where the keywords can be placed.  For 
> > > example, when lambdas were introduced, GNU attributes were extended to 
> > > support lambdas.  Something similar could happen in future.
> > > 
> > > We could have defined the semantics of the keywords to be that they 
> > > behave exactly like GNU attributes.  However:
> > > 
> > > # If we do that, the advantage of using a keyword is less obvious.  (I 
> > > can see the argument that the syntax looks nicer though.)
> > > # Like you say in the review, the semantics of GNU attributes carry some 
> > > historical baggage.  If would be difficult to justify keeping that 
> > > historical baggage for something that is ostensibly new and not a GNU 
> > > attribute as such.
> > > 
> > > A minor, but still nontrivial, reason is that there is less appetite in 
> > > the GCC community for supporting target-specific extensions to the core 
> > > language.  Adding a target-specific keyword is likely to be rejected.  It 
> > > would be acceptable to make the “keyword” be a predefined macro that 
> > > expands to a GNU attribute under the hood, but I don't think that would 
> > > address the core issue.
> > > 
> > > I can definitely understand the unease about using attributes for things 
> > > that affect semantics.  Like you say, that's going against a core 
> > > principle of the standard-defined attributes.  But I think in a way, it's 
> > > unfortunate that GNU-style attributes and standard-defined attributes are 
> > > both called “attributes”, because I don't think there's a prohibition 
> > > (even in theory) against GNU attributes affecting semanti

[PATCH] D138081: [IR] Split out IR printing passes into IRPrinter

[Alexander Shaposhnikov via Phabricator via cfe-commits]

alexander-shaposhnikov added a comment.

@tejohnson - the legacy pass manager depends on the interface defined in 
IRPrintingPasses.h 
(https://github.com/llvm/llvm-project/blob/main/llvm/lib/IR/LegacyPassManager.cpp#L266)
so without splitting this would face the same issue - circular dependency 
between LLVMCore (LegacyPassManager.cpp is in LLVMCore) and IRPrinter.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138081

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

[PATCH] D138137: [CodeGen][ARM] Fix ARMABIInfo::EmitVAAarg crash with empty record type variadic arg

[John McCall via Phabricator via cfe-commits]

rjmccall accepted this revision.
rjmccall 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/D138137/new/

https://reviews.llvm.org/D138137

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

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Zack Weinberg via cfe-commits]

On Wed, Nov 16, 2022, at 1:17 PM, Paul Eggert wrote:
...
> If Clang's threatened pickiness were of some real use elsewhere, it 
> might be justifiable for default Clang to break Autoconf. But so far we 
> haven't seen real-world uses that would justify this pickiness for 
> Autoconf's use of 'char memset_explicit(void);'.

I don't have time this week to really get into this argument but I want to 
point out that I'm generally in agreement with Rich Felker's argument (in 
https://ewontfix.com/13/) that AC_CHECK_FUNC *should not* just probe for 
linkability of a symbol, because:

 - Not including the appropriate headers means that the probe bypasses 
compile-time symbol renaming and therefore probes for *the wrong symbol*, 
potentially causing both false detection and false non-detection (to tie it to 
another subthread, notice that one of the things -D_TIME_BITS=64 triggers (from 
glibc's headers) is enable dozens of __REDIRECT annotations in time.h)

 - Only probing the symbol, and not its type signature, means for instance that 
if the program expects GNU strerror_r but the system provides POSIX strerror_r, 
or vice versa, Autoconf's check will succeed but the program will fail to 
compile (in more subtle cases it might be miscompiled instead)

(N.B. I *don't* agree with the assertion at the bottom of that page that 
"taking explicit action to prevent linking against [symbols intended to be 
exposed for binary compatibility only], involves hacks that are even worse and 
more fragile than what configure is doing" -- yes, it sucks that the toolchain 
support for ELF symbol versioning is still mostly absent, 20 years after the 
concept was introduced, but `asm(".symver __strtod_l_compat, 
strtod_l@SOME_CONCRETE_VERSION_TAG")` is straightforward (if cryptic) and 
robust on all the platforms where it works at all.)

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

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

[Richard Sandiford via Phabricator via cfe-commits]

rsandifo-arm added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:2000
   "overridden virtual function is here">;
+def err_conflicting_overriding_attributes : Error<
+  "virtual function %0 has different attributes "

rsandifo-arm wrote:
> aaron.ballman wrote:
> > aaron.ballman wrote:
> > > rsandifo-arm wrote:
> > > > sdesmalen wrote:
> > > > > aaron.ballman wrote:
> > > > > > sdesmalen wrote:
> > > > > > > aaron.ballman wrote:
> > > > > > > > This error and the one below make me wonder whether an 
> > > > > > > > attribute spelling is the appropriate way to surface this 
> > > > > > > > functionality as opposed to a keyword. Attributes don't 
> > > > > > > > typically don't cause errors in these situations, but because 
> > > > > > > > these attributes are strongly coupled to their type system 
> > > > > > > > effects I can see why you want these to be errors.
> > > > > > > > This error and the one below make me wonder whether an 
> > > > > > > > attribute spelling is the appropriate way to surface this 
> > > > > > > > functionality as opposed to a keyword. 
> > > > > > > I'm not sure I understand what you mean, do you have an example?
> > > > > > `override` and `final` could have been surfaced via attributes, and 
> > > > > > in Clang we semantically express them as such (see `Final` and 
> > > > > > `Override` in Attr.td), but instead they are surfaced to the user 
> > > > > > as keywords in the language standard. You're not under the same 
> > > > > > constraints as the standard (you're making a vendor-specific 
> > > > > > attribute). We're not super consistent with whether we use the same 
> > > > > > approach as the standard (we have some type attributes that are 
> > > > > > spelled as attributes like `vector_size` and others that are 
> > > > > > spelled via keywords like `_Nullable`.
> > > > > > 
> > > > > > So you could spell your type attributes the way you have been with 
> > > > > > `__attribute__`, or you could come up with keywords for them (so 
> > > > > > instead of using `GNU<"whatever">` for the attribute, you could use 
> > > > > > `Keyword<_Whatever>` or `Keyword<__whatever>` (you'd also need to 
> > > > > > add them as recognized keyword tokens, parse them as appropriate, 
> > > > > > etc).
> > > > > > 
> > > > > > Note: I don't insist on you using a keyword for these, but I am 
> > > > > > wondering if that approach was considered or not given how 
> > > > > > non-portable the attributes are (if an implementation ignores this 
> > > > > > attribute, it sounds like the program semantics are unlikely to be 
> > > > > > correct).
> > > > > @rsandifo-arm can you shed some light on whether using a keyword 
> > > > > instead of an `attribute` was considered?
> > > > Thanks @aaron.ballman for the reviews.
> > > >  
> > > > Yeah, we did consider using keywords instead.  The main reason for 
> > > > sticking with GNU attributes is that they were specifically designed as 
> > > > an extensible way of attaching information or requirements to the 
> > > > source code, and they provide well-settled semantics.  It seemed better 
> > > > to reuse an existing mechanism rather than invent something new.
> > > > 
> > > > Also, as C++ evolves, the semantics of GNU attributes evolve to match.  
> > > > If we surface the SME features as GNU attributes, we inherit this 
> > > > development in the underlying semantics, without having to maintain our 
> > > > own evolving specification for where the keywords can be placed.  For 
> > > > example, when lambdas were introduced, GNU attributes were extended to 
> > > > support lambdas.  Something similar could happen in future.
> > > > 
> > > > We could have defined the semantics of the keywords to be that they 
> > > > behave exactly like GNU attributes.  However:
> > > > 
> > > > # If we do that, the advantage of using a keyword is less obvious.  (I 
> > > > can see the argument that the syntax looks nicer though.)
> > > > # Like you say in the review, the semantics of GNU attributes carry 
> > > > some historical baggage.  If would be difficult to justify keeping that 
> > > > historical baggage for something that is ostensibly new and not a GNU 
> > > > attribute as such.
> > > > 
> > > > A minor, but still nontrivial, reason is that there is less appetite in 
> > > > the GCC community for supporting target-specific extensions to the core 
> > > > language.  Adding a target-specific keyword is likely to be rejected.  
> > > > It would be acceptable to make the “keyword” be a predefined macro that 
> > > > expands to a GNU attribute under the hood, but I don't think that would 
> > > > address the core issue.
> > > > 
> > > > I can definitely understand the unease about using attributes for 
> > > > things that affect semantics.  Like you say, that's going against a 
> > > > core principle of the standard-defined attributes.  But I think in a 
> > > > way, it's unfortunate that GNU-style att

[clang-tools-extra] 2d5c4b8 - Fix use of dangling stack allocated string in IncludeFixer

[David Goldman via cfe-commits]

Author: David Goldman
Date: 2022-11-16T11:09:06-08:00
New Revision: 2d5c4b8f6e040eef33d4f49820868a81c4c9f1e9

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

LOG: Fix use of dangling stack allocated string in IncludeFixer

IncludeFixer uses this BuildDir string later on if given relative paths.

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

Added: 


Modified: 
clang-tools-extra/clangd/ParsedAST.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/ParsedAST.cpp 
b/clang-tools-extra/clangd/ParsedAST.cpp
index 50923c862c583..870a22cd7b1ef 100644
--- a/clang-tools-extra/clangd/ParsedAST.cpp
+++ b/clang-tools-extra/clangd/ParsedAST.cpp
@@ -465,6 +465,8 @@ ParsedAST::build(llvm::StringRef Filename, const 
ParseInputs &Inputs,
   std::vector> CTChecks;
   ast_matchers::MatchFinder CTFinder;
   llvm::Optional CTContext;
+  // Must outlive FixIncludes.
+  auto BuildDir = VFS->getCurrentWorkingDirectory();
   llvm::Optional FixIncludes;
   llvm::DenseMap OverriddenSeverity;
   // No need to run clang-tidy or IncludeFixerif we are not going to surface
@@ -551,7 +553,6 @@ ParsedAST::build(llvm::StringRef Filename, const 
ParseInputs &Inputs,
 
 // Add IncludeFixer which can recover diagnostics caused by missing 
includes
 // (e.g. incomplete type) and attach include insertion fixes to 
diagnostics.
-auto BuildDir = VFS->getCurrentWorkingDirectory();
 if (Inputs.Index && !BuildDir.getError()) {
   auto Style =
   getFormatStyleForFile(Filename, Inputs.Contents, *Inputs.TFS);



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