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

2022-10-31 Thread Michał Górny via Phabricator via cfe-commits
mgorny reopened this revision.
mgorny added a comment.
This revision is now accepted and ready to land.

Gotta figure the buildbot regression out.


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] D137024: [compiler-rt] Switch from llvm-config to find_package(LLVM)

2022-10-31 Thread Michał Górny via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG37acf9bdd468: [compiler-rt] Switch from llvm-config to 
find_package(LLVM) (authored by mgorny).
Herald added a project: Sanitizers.
Herald added a subscriber: Sanitizers.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137024

Files:
  compiler-rt/cmake/Modules/CompilerRTUtils.cmake
  compiler-rt/lib/xray/tests/CMakeLists.txt

Index: compiler-rt/lib/xray/tests/CMakeLists.txt
===
--- compiler-rt/lib/xray/tests/CMakeLists.txt
+++ compiler-rt/lib/xray/tests/CMakeLists.txt
@@ -59,19 +59,26 @@
 LLVM_ENABLE_TERMINFO
 -l${COMPILER_RT_TERMINFO_LIB} XRAY_UNITTEST_LINK_FLAGS)
 
+  # We add the library directories one at a time in our CFLAGS.
+  foreach (DIR ${LLVM_LIBRARY_DIR})
+list(APPEND XRAY_UNITTEST_LINK_FLAGS -L${DIR})
+  endforeach()
+
   if (COMPILER_RT_STANDALONE_BUILD)
-append_list_if(COMPILER_RT_HAS_LLVMXRAY ${LLVM_XRAY_LDFLAGS} XRAY_UNITTEST_LINK_FLAGS)
-append_list_if(COMPILER_RT_HAS_LLVMXRAY ${LLVM_XRAY_LIBLIST} XRAY_UNITTEST_LINK_FLAGS)
-append_list_if(COMPILER_RT_HAS_LLVMTESTINGSUPPORT
-  ${LLVM_TESTINGSUPPORT_LDFLAGS} XRAY_UNITTEST_LINK_FLAGS)
-append_list_if(COMPILER_RT_HAS_LLVMTESTINGSUPPORT
-  ${LLVM_TESTINGSUPPORT_LIBLIST} XRAY_UNITTEST_LINK_FLAGS)
+if (COMPILER_RT_HAS_LLVMXRAY OR COMPILER_RT_HAS_LLVMTESTINGSUPPORT)
+  if (LLVM_LINK_LLVM_DYLIB)
+list(APPEND XRAY_UNITTEST_LINK_FLAGS -lLLVM)
+  endif()
+else()
+  if (COMPILER_RT_HAS_LLVMXRAY)
+list(APPEND XRAY_UNITTEST_LINK_FLAGS -lLLVMXRay)
+  endif()
+  if (COMPILER_RT_HAS_TESTINGSUPPORT)
+list(APPEND XRAY_UNITTEST_LINK_FLAGS -lLLVMTestingSupport)
+  endif()
+  list(APPEND XRAY_UNITTEST_LINK_FLAGS -lLLVMSupport -lLLVMDemangle)
+endif()
   else()
-# We add the library directories one at a time in our CFLAGS.
-foreach (DIR ${LLVM_LIBRARY_DIR})
-  list(APPEND XRAY_UNITTEST_LINK_FLAGS -L${DIR})
-endforeach()
-
 # We also add the actual libraries to link as dependencies.
 list(APPEND XRAY_UNITTEST_LINK_FLAGS -lLLVMXRay -lLLVMSupport -lLLVMDemangle -lLLVMTestingSupport)
   endif()
Index: compiler-rt/cmake/Modules/CompilerRTUtils.cmake
===
--- compiler-rt/cmake/Modules/CompilerRTUtils.cmake
+++ compiler-rt/cmake/Modules/CompilerRTUtils.cmake
@@ -268,16 +268,6 @@
 endfunction()
 
 macro(load_llvm_config)
-  if (NOT LLVM_CONFIG_PATH)
-find_program(LLVM_CONFIG_PATH "llvm-config"
- DOC "Path to llvm-config binary")
-if (NOT LLVM_CONFIG_PATH)
-  message(WARNING "UNSUPPORTED COMPILER-RT CONFIGURATION DETECTED: "
-  "llvm-config not found.\n"
-  "Reconfigure with -DLLVM_CONFIG_PATH=path/to/llvm-config.")
-endif()
-  endif()
-
   # Compute path to LLVM sources assuming the monorepo layout.
   # We don't set `LLVM_MAIN_SRC_DIR` directly to avoid overriding a user provided
   # CMake cache value.
@@ -290,114 +280,33 @@
   "You are not using the monorepo layout. This configuration is DEPRECATED.")
   endif()
 
-  set(FOUND_LLVM_CMAKE_DIR FALSE)
-  if (LLVM_CONFIG_PATH)
-execute_process(
-  COMMAND ${LLVM_CONFIG_PATH} "--obj-root" "--bindir" "--libdir" "--src-root" "--includedir"
-  RESULT_VARIABLE HAD_ERROR
-  OUTPUT_VARIABLE CONFIG_OUTPUT)
-if (HAD_ERROR)
-  message(FATAL_ERROR "llvm-config failed with status ${HAD_ERROR}")
-endif()
-string(REGEX REPLACE "[ \t]*[\r\n]+[ \t]*" ";" CONFIG_OUTPUT ${CONFIG_OUTPUT})
-list(GET CONFIG_OUTPUT 0 BINARY_DIR)
-list(GET CONFIG_OUTPUT 1 TOOLS_BINARY_DIR)
-list(GET CONFIG_OUTPUT 2 LIBRARY_DIR)
-list(GET CONFIG_OUTPUT 3 MAIN_SRC_DIR)
-list(GET CONFIG_OUTPUT 4 INCLUDE_DIR)
-
-set(LLVM_BINARY_DIR ${BINARY_DIR} CACHE PATH "Path to LLVM build tree")
-set(LLVM_LIBRARY_DIR ${LIBRARY_DIR} CACHE PATH "Path to llvm/lib")
-set(LLVM_TOOLS_BINARY_DIR ${TOOLS_BINARY_DIR} CACHE PATH "Path to llvm/bin")
-set(LLVM_INCLUDE_DIR ${INCLUDE_DIR} CACHE PATH "Paths to LLVM headers")
-
-if (NOT EXISTS "${LLVM_MAIN_SRC_DIR_DEFAULT}")
-  # TODO(dliew): Remove this legacy fallback path.
-  message(WARNING
-"Consulting llvm-config for the LLVM source path "
-"as a fallback. This behavior will be removed in the future.")
-  # We don't set `LLVM_MAIN_SRC_DIR` directly to avoid overriding a user
-  # provided CMake cache value.
-  set(LLVM_MAIN_SRC_DIR_DEFAULT "${MAIN_SRC_DIR}")
-  message(STATUS "Using LLVM source path (${LLVM_MAIN_SRC_DIR_DEFAULT}) from llvm-config")
-endif()
-
-# Detect if we have the LLVMXRay and TestingSupport library installed and
-# available from llvm-config.
-execute_process(
-  COMMAND 

[PATCH] D137052: [clang-format] Don't skip #else/#elif of #if 0

2022-10-31 Thread Owen Pan via Phabricator via cfe-commits
owenpan added a comment.

In D137052#3895426 , @sstwcw wrote:

> This patch fixes the regression caused by 2183fe2 
>  while 
> introducing a new regression.  But in my opinion the new regression is less 
> of a problem than the old one.  Therefore I think it is okay.
>
> Take this piece of code similar to the example in 71814b4.
>
> before
>
>   void SomeFunction(int param1,
> template <
>   #ifdef A
>   #if 0
>   #endif
> MyType>
>   #else
> Type1, Type2>
>   #endif
> param2,
> param3) {
> f();
>   }
>
> after
>
>   void SomeFunction(int param1,
> template <
>   #ifdef A
>   #if 0
>   #endif
> MyType>
>   #else
> Type1,
> Type2 >
>   #endif
> param2,
> param3) {
> f();
>   }

Fixed.


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

https://reviews.llvm.org/D137052

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


[PATCH] D137052: [clang-format] Don't skip #else/#elif of #if 0

2022-10-31 Thread Owen Pan via Phabricator via cfe-commits
owenpan updated this revision to Diff 472204.
owenpan added a comment.

Tweaked the fix and added a test.


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

https://reviews.llvm.org/D137052

Files:
  clang/lib/Format/UnwrappedLineParser.cpp
  clang/unittests/Format/FormatTest.cpp


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -6119,7 +6119,7 @@
  "#endif");
 
   // Verify that indentation is correct when there is an `#if 0` with an
-  // `#else`.
+  // `#else`/`#elif`.
   verifyFormat("#if 0\n"
"{\n"
"#else\n"
@@ -6127,6 +6127,40 @@
"#endif\n"
"  x;\n"
"}");
+  verifyFormat("#if 0\n"
+   "{\n"
+   "#elif FOO\n"
+   "{\n"
+   "#endif\n"
+   "  x;\n"
+   "}");
+
+  verifyFormat("#if 0\n"
+   "#endif\n"
+   "#if X\n"
+   "int something_fairly_long; // Align here please\n"
+   "#endif // Should be aligned");
+
+  verifyFormat("#if 0\n"
+   "#endif\n"
+   "#if X\n"
+   "#else  // Align\n"
+   ";\n"
+   "#endif // Align");
+
+  verifyFormat("void SomeFunction(int param1,\n"
+   "  template <\n"
+   "#ifdef A\n"
+   "#if 0\n"
+   "#endif\n"
+   "  MyType>\n"
+   "#else\n"
+   "  Type1, Type2>\n"
+   "#endif\n"
+   "  param2,\n"
+   "  param3) {\n"
+   "  f();\n"
+   "}");
 }
 
 TEST_F(FormatTest, GraciouslyHandleIncorrectPreprocessorConditions) {
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -1144,12 +1144,10 @@
   ++PPBranchLevel;
   assert(PPBranchLevel >= 0 && PPBranchLevel <= 
(int)PPLevelBranchIndex.size());
   if (PPBranchLevel == (int)PPLevelBranchIndex.size()) {
-// If the first branch is unreachable, set the BranchIndex to 1.  This way
-// the next branch will be parsed if there is one.
-PPLevelBranchIndex.push_back(Unreachable ? 1 : 0);
+PPLevelBranchIndex.push_back(0);
 PPLevelBranchCount.push_back(0);
   }
-  PPChainBranchIndex.push(0);
+  PPChainBranchIndex.push(Unreachable ? -1 : 0);
   bool Skip = PPLevelBranchIndex[PPBranchLevel] > 0;
   conditionalCompilationCondition(Unreachable || Skip);
 }


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -6119,7 +6119,7 @@
  "#endif");
 
   // Verify that indentation is correct when there is an `#if 0` with an
-  // `#else`.
+  // `#else`/`#elif`.
   verifyFormat("#if 0\n"
"{\n"
"#else\n"
@@ -6127,6 +6127,40 @@
"#endif\n"
"  x;\n"
"}");
+  verifyFormat("#if 0\n"
+   "{\n"
+   "#elif FOO\n"
+   "{\n"
+   "#endif\n"
+   "  x;\n"
+   "}");
+
+  verifyFormat("#if 0\n"
+   "#endif\n"
+   "#if X\n"
+   "int something_fairly_long; // Align here please\n"
+   "#endif // Should be aligned");
+
+  verifyFormat("#if 0\n"
+   "#endif\n"
+   "#if X\n"
+   "#else  // Align\n"
+   ";\n"
+   "#endif // Align");
+
+  verifyFormat("void SomeFunction(int param1,\n"
+   "  template <\n"
+   "#ifdef A\n"
+   "#if 0\n"
+   "#endif\n"
+   "  MyType>\n"
+   "#else\n"
+   "  Type1, Type2>\n"
+   "#endif\n"
+   "  param2,\n"
+   "  param3) {\n"
+   "  f();\n"
+   "}");
 }
 
 TEST_F(FormatTest, GraciouslyHandleIncorrectPreprocessorConditions) {
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -1144,12 +1144,10 @@
   ++PPBranchLevel;
   assert(PPBranchLevel >= 0 && PPBranchLevel <= (int)PPLevelBranchIndex.size());
   if (PPBranchLevel == (int)PPLevelBranchIndex.size()) {
-// If the first branch is unreachable, set the BranchIndex to 1.  This way
-// the next branch will 

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

2022-10-31 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu added a comment.

In D137059#3896661 , @dblaikie wrote:

> Could you link to the email/discourse discussion about supporting this mode 
> (I think you've linked it in other discussions, be good to have it for 
> reference here & Probably in the other review)? (I'm wondering if we need a 
> new flag for this, or if it'll be OK to change the driver behavior to always 
> coalesce the .cppm->.pcm->.o path into a single step, for instance - I 
> realize this is a somewhat breaking change but may be acceptable given that 
> modules aren't widely deployed yet)

Done. From my reading, in that discourse discussing, we're not talking about to 
add the new flags. I add the flag since I don't want the `.pcm` file pollutes 
the user space accidentally.

> if it'll be OK to change the driver behavior to always coalesce the 
> .cppm->.pcm->.o path into a single step

I am not sure what you mean. Do you talk about to forbidden the original 
2-phase compilation model? If so, I think it is definitely the wrong direction. 
The 2-phase compilation model should be the correct direction in the long term 
since it has higher parallelism.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137059

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


[PATCH] D135937: [X86] Support -march=raptorlake, meteorlake

2022-10-31 Thread Freddy, Ye via Phabricator via cfe-commits
FreddyYe added a comment.

For saving capacity of ProcessorSubtypes, gcc decided to not support part of 
compiler features of these two cpus:

  __builtin_cpu_is("meteorlake")
  __attribute__((target("arch=raptorlake")))
  ... some others I don't know.

Updated to align with gcc first. Welcome opinions and review!




Comment at: clang/test/Preprocessor/predefined-arch-macros.c:2233
 
+// RUN: %clang -march=raptorlake -m32 -E -dM %s -o - 2>&1 \
+// RUN: -target i386-unknown-linux \

RKSimon wrote:
> (pedantic) Probably better to put these after the alderlake tests so its 
> easier to find?
I merged them with the check-prefix.



Comment at: compiler-rt/lib/builtins/cpu_model.c:111
+  ZHAOXIN_FAM7H_LUJIAZUI,
+  INTEL_COREI7_RAPTORLAKE,
+  INTEL_COREI7_METEORLAKE,

skan wrote:
> I see. But if possible, could we split "ZHAOXIN_FAM7H_LUJIAZUI" to another 
> patch?
Related change is removed. See my latest comment.



Comment at: compiler-rt/lib/builtins/cpu_model.c:478
+  *Type = INTEL_COREI7;
+  *Subtype = INTEL_COREI7_METEORLAKE;
+

MaskRay wrote:
> fallthrough?
Good catch! While related changes are removed, see my latest comment.



Comment at: llvm/lib/Support/Host.cpp:836
+  *Type = X86::INTEL_COREI7;
+  *Subtype = X86::INTEL_COREI7_METEORLAKE;
+

MaskRay wrote:
> fallthrough?
Good catch!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135937

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


[PATCH] D135937: [WIP][X86] Support -march=raptorlake, meteorlake

2022-10-31 Thread Freddy, Ye via Phabricator via cfe-commits
FreddyYe updated this revision to Diff 472203.
FreddyYe marked 7 inline comments as done.
FreddyYe added a comment.

Address comments and update to align with gcc. See my latest comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135937

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Basic/Targets/X86.cpp
  clang/test/Driver/x86-march.c
  clang/test/Misc/target-invalid-cpu-note.c
  clang/test/Preprocessor/predefined-arch-macros.c
  llvm/docs/ReleaseNotes.rst
  llvm/include/llvm/Support/X86TargetParser.h
  llvm/lib/Support/Host.cpp
  llvm/lib/Support/X86TargetParser.cpp
  llvm/lib/Target/X86/X86.td
  llvm/test/CodeGen/X86/cpus-intel.ll

Index: llvm/test/CodeGen/X86/cpus-intel.ll
===
--- llvm/test/CodeGen/X86/cpus-intel.ll
+++ llvm/test/CodeGen/X86/cpus-intel.ll
@@ -17,6 +17,8 @@
 ; RUN: llc < %s -o /dev/null -mtriple=i686-unknown-unknown -mcpu=yonah 2>&1 | FileCheck %s --check-prefix=CHECK-NO-ERROR --allow-empty
 ; RUN: llc < %s -o /dev/null -mtriple=i686-unknown-unknown -mcpu=prescott 2>&1 | FileCheck %s --check-prefix=CHECK-NO-ERROR --allow-empty
 ; RUN: llc < %s -o /dev/null -mtriple=i686-unknown-unknown -mcpu=lakemont 2>&1 | FileCheck %s --check-prefix=CHECK-NO-ERROR --allow-empty
+; RUN: llc < %s -o /dev/null -mtriple=i686-unknown-unknown -mcpu=raptorlake 2>&1 | FileCheck %s --check-prefix=CHECK-NO-ERROR --allow-empty
+; RUN: llc < %s -o /dev/null -mtriple=i686-unknown-unknown -mcpu=meteorlake 2>&1 | FileCheck %s --check-prefix=CHECK-NO-ERROR --allow-empty
 
 ; RUN: llc < %s -o /dev/null -mtriple=x86_64-unknown-unknown -mcpu=nocona 2>&1 | FileCheck %s --check-prefix=CHECK-NO-ERROR --allow-empty
 ; RUN: llc < %s -o /dev/null -mtriple=x86_64-unknown-unknown -mcpu=core2 2>&1 | FileCheck %s --check-prefix=CHECK-NO-ERROR --allow-empty
@@ -52,6 +54,8 @@
 ; RUN: llc < %s -o /dev/null -mtriple=x86_64-unknown-unknown -mcpu=tremont 2>&1 | FileCheck %s --check-prefix=CHECK-NO-ERROR --allow-empty
 ; RUN: llc < %s -o /dev/null -mtriple=x86_64-unknown-unknown -mcpu=knl 2>&1 | FileCheck %s --check-prefix=CHECK-NO-ERROR --allow-empty
 ; RUN: llc < %s -o /dev/null -mtriple=x86_64-unknown-unknown -mcpu=knm 2>&1 | FileCheck %s --check-prefix=CHECK-NO-ERROR --allow-empty
+; RUN: llc < %s -o /dev/null -mtriple=x86_64-unknown-unknown -mcpu=raptorlake 2>&1 | FileCheck %s --check-prefix=CHECK-NO-ERROR --allow-empty
+; RUN: llc < %s -o /dev/null -mtriple=x86_64-unknown-unknown -mcpu=meteorlake 2>&1 | FileCheck %s --check-prefix=CHECK-NO-ERROR --allow-empty
 
 define void @foo() {
   ret void
Index: llvm/lib/Target/X86/X86.td
===
--- llvm/lib/Target/X86/X86.td
+++ llvm/lib/Target/X86/X86.td
@@ -1499,6 +1499,10 @@
 ProcessorFeatures.SPRFeatures, ProcessorFeatures.SPRTuning>;
 def : ProcModel<"alderlake", AlderlakePModel,
 ProcessorFeatures.ADLFeatures, ProcessorFeatures.ADLTuning>;
+def : ProcModel<"raptorlake", AlderlakePModel,
+ProcessorFeatures.ADLFeatures, ProcessorFeatures.ADLTuning>;
+def : ProcModel<"meteorlake", AlderlakePModel,
+ProcessorFeatures.ADLFeatures, ProcessorFeatures.ADLTuning>;
 
 // AMD CPUs.
 
Index: llvm/lib/Support/X86TargetParser.cpp
===
--- llvm/lib/Support/X86TargetParser.cpp
+++ llvm/lib/Support/X86TargetParser.cpp
@@ -370,6 +370,10 @@
   { {"sapphirerapids"}, CK_SapphireRapids, FEATURE_AVX512BF16, FeaturesSapphireRapids },
   // Alderlake microarchitecture based processors.
   { {"alderlake"}, CK_Alderlake, FEATURE_AVX2, FeaturesAlderlake },
+  // Raptorlake microarchitecture based processors.
+  { {"raptorlake"}, CK_Raptorlake, FEATURE_AVX2, FeaturesAlderlake },
+  // Meteorlake microarchitecture based processors.
+  { {"meteorlake"}, CK_Meteorlake, FEATURE_AVX2, FeaturesAlderlake },
   // Knights Landing processor.
   { {"knl"}, CK_KNL, FEATURE_AVX512F, FeaturesKNL },
   // Knights Mill processor.
Index: llvm/lib/Support/Host.cpp
===
--- llvm/lib/Support/Host.cpp
+++ llvm/lib/Support/Host.cpp
@@ -815,6 +815,12 @@
 // Alderlake:
 case 0x97:
 case 0x9a:
+// Raptorlake:
+case 0xb7:
+// Meteorlake:
+case 0xb5:
+case 0xaa:
+case 0xac:
   CPU = "alderlake";
   *Type = X86::INTEL_COREI7;
   *Subtype = X86::INTEL_COREI7_ALDERLAKE;
Index: llvm/include/llvm/Support/X86TargetParser.h
===
--- llvm/include/llvm/Support/X86TargetParser.h
+++ llvm/include/llvm/Support/X86TargetParser.h
@@ -104,6 +104,8 @@
   CK_Tigerlake,
   CK_SapphireRapids,
   CK_Alderlake,
+  CK_Raptorlake,
+  CK_Meteorlake,
   CK_KNL,
   CK_KNM,
   CK_Lakemont,
Index: llvm/docs/ReleaseNotes.rst

[PATCH] D136786: Fix `unsafe-fp-math` attribute emission.

2022-10-31 Thread Michele Scandale via Phabricator via cfe-commits
michele.scandale added inline comments.



Comment at: clang/lib/CodeGen/CodeGenFunction.cpp:181
+  FPFeatures.allowFPContractAcrossStatement());
 }
 

zahiraam wrote:
> Shouldn't then this also check for FPFeatures.getFPContractMode() ?
This should be covered by `FPFeatures.allowFPContractAcrossStatement()` which 
is basically `getFPContractMode() == LangOptions::FPM_Fast`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136786

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


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

2022-10-31 Thread Alan Zhao via Phabricator via cfe-commits
ayzhao added a comment.

Status update:

While investigating @cor3ntin's comment about refactoring `VisitInitListExpr` 
and `VisitCXXParenListInitExpr` as they share common code, I discovered that 
flexible array members would cause this patch to explode. Specifically, the 
following code:

  struct S {
  int b;
  int a[];
  };
  
  S s2(1, {1, 2});

was causing this assertion 

 to fail.

I took a look at GCC, and it turns out that GCC doesn't allow flexible array 
members at all in paren list initialization of aggregates, even in contexts 
where the corresponding designated initializer expression succeeds: 
https://godbolt.org/z/E73433erb

For now, I updated this implementation to follow GCC's behavior and disallow 
flexible array members, as IIRC in C++ they are a GCC extension and we should 
therefore follow GCC behavior. However, I am open to other thoughts.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129531

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


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

2022-10-31 Thread Alan Zhao via Phabricator via cfe-commits
ayzhao updated this revision to Diff 472190.
ayzhao marked 6 inline comments as done.
ayzhao added a comment.

address some comments and implement disallowing flexible array members


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129531

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

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

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

[PATCH] D136894: Add clang-doc readme

2022-10-31 Thread Paul Kirth via Phabricator via cfe-commits
paulkirth requested changes to this revision.
paulkirth added a comment.
This revision now requires changes to proceed.

First, I don't think this is a good fit for a `README.txt` based on the content 
of other clang-tool `README.txt` files. Most of them only outline project scope 
or point to formal documentation on llvm.org. Other README files also tend to 
only provide build or dependency information. The one example I can find that 
does more is `clangd/quality/README.md`, which provides details on a number of 
internal data structures. Its preferable to document project internals in the 
`.rst` files as part of the developer facing documentation on llvm.org, so I 
think that's where something like this would ultimately belong.

I think there are some other issues with the content of this patch.

- I think there is some miscommunication about clang-doc's design. Clang-doc 
follows LLVM's architecture to a large extent by translating the AST into its 
own intermediate representation, and then letting custom backends generate the 
appropriate output. Further, this design allows the clang-doc IR to be 
serialized(though I understand this is not yet implemented), which is important 
for testing and scalability. The initial clang-doc RFC and discussion with 
other clang-tool developers pointed to this design as the best practice for 
scaling up to large organizations. I understand the tool is not meeting 
expectations in that regard, but it doesn't mean the design is the incorrect 
choice. While you're certainly free to disagree with that approach, this 
document isn't the place to codify that opinion. You're also free to submit 
patches to refactor clang-doc in the way you think it should be architected. 
Contributions, as always are welcome. 
- Call outs to "watch out" don't seem appropriate for formal documentation. A 
"note" or some other descriptor will work just as well without using language 
that makes the tool sound dangerous.
- The introduction is a coarse approximation of how libTooling operates, you 
can just say that it's build on libTooling and point to its documentation. I 
think that will 1) be more concise, and 2) allow you to focus on the details of 
clang-doc without worrying about describing the infrastructure its built upon. 
If you still feel that its central to this document, you may wish to quote it 
directly.
- Describing how to add a new field is mostly fine. The code should probably 
cary a reference to this documentation (or should generate the documentation).

My recommendation here is that you should move this into an `rst` file under 
`doc` and revise this document to more closely model the existing documentation 
practices in LLVM. I've left some suggestions inline that you may find useful. 
How you revise the document is up to you, and I won't' be a stickler if you 
would like to word something differently than I've suggested.




Comment at: clang-tools-extra/clang-doc/README.txt:5-10
+Clang-doc uses the "tooling" library which can run the compiler. It can take 
the files directly or
+it can extract the file list and the commands corresponding to each from a 
compile_commands.json
+file.
+
+The tooling library spins up threads and parses the compilation units in 
parallel. Clang-doc
+registers a callback to run on the AST of each unit.

the libtooling documentation covers this, can we just link to that?



Comment at: clang-tools-extra/clang-doc/README.txt:12-16
+When the AST is known, the MapASTVisitor in Mapper.cpp is run on the AST. It 
has callbacks for the
+main AST nodes that clang-doc cares about. This is a very simple object that 
mostly calls into
+Serialize.cpp to generate the "representation" of the code. These are the 
various *Info structures
+like FunctionInfo and NamespaceInfo defined in Representation.h that 
correspond to each element of
+the code that might be documented.





Comment at: clang-tools-extra/clang-doc/README.txt:18-20
+The representation from each execution thread is serialized to bitcode using 
BitcodeWriter.cpp. This
+is a custom bitcode defined in BitcodeWriter.h and is NOT regular LLVM bitcode 
IR. Watch out: the
+"Serialize.cpp" file is not related to this step though the name may imply it.





Comment at: clang-tools-extra/clang-doc/README.txt:22-27
+These bitcode representations are then passed back to the main thread and 
deserialized back to a
+new copy of the representation in BitcodeReader.cpp. This round-trip through 
bitcode is used only to
+get the data out of the AST visitor (which is expected to return a byte 
stream) and is never saved
+or used for any other purpose. This round-trip adds significant complexity and 
we should consider
+passing the Representation object hierarchy back to the main thread 
out-of-band without
+serialization and deleting the bitcode representation.

I'd drop this 

[PATCH] D136844: [libclang] Expose completion result kind in `CXCompletionResult`

2022-10-31 Thread Ben Barham via Phabricator via cfe-commits
bnbarham accepted this revision.
bnbarham added a comment.
This revision is now accepted and ready to land.

Thanks Egor!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136844

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


[PATCH] D136844: [libclang] Expose completion result kind in `CXCompletionResult`

2022-10-31 Thread Egor Zhdan via Phabricator via cfe-commits
egorzhdan updated this revision to Diff 472171.
egorzhdan added a comment.

Preserve `CodeCompletionResult::ResultKind` and do the conversion to 
`CXCompletionResultKind` in `CIndexCodeCompletion.cpp`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136844

Files:
  clang/include/clang-c/Index.h
  clang/test/Index/arc-complete.m
  clang/test/Index/code-completion.cpp
  clang/test/Index/complete-at-directives.m
  clang/test/Index/complete-at-exprstmt.m
  clang/test/Index/complete-declarators.cpp
  clang/test/Index/complete-declarators.m
  clang/test/Index/complete-exprs.c
  clang/test/Index/complete-exprs.cpp
  clang/test/Index/complete-exprs.m
  clang/test/Index/complete-lambdas.cpp
  clang/test/Index/complete-lambdas.mm
  clang/test/Index/complete-memfunc-cvquals.cpp
  clang/test/Index/complete-method-decls.m
  clang/test/Index/complete-modules.m
  clang/test/Index/complete-preprocessor.m
  clang/test/Index/complete-recovery.m
  clang/test/Index/complete-stmt.c
  clang/test/Index/complete-super.cpp
  clang/test/Index/complete-synthesized.m
  clang/test/Index/complete-type-factors.m
  clang/tools/c-index-test/c-index-test.c
  clang/tools/libclang/CIndex.cpp
  clang/tools/libclang/CIndexCodeCompletion.cpp
  clang/tools/libclang/libclang.map

Index: clang/tools/libclang/libclang.map
===
--- clang/tools/libclang/libclang.map
+++ clang/tools/libclang/libclang.map
@@ -4,6 +4,11 @@
 # On platforms where versions scripts are not used, this file will be used to
 # generate a list of exports for libclang.so
 
+LLVM_15 {
+  global:
+clang_getCompletionResultKindSpelling;
+};
+
 LLVM_13 {
   global:
 clang_BlockCommandComment_getArgText;
Index: clang/tools/libclang/CIndexCodeCompletion.cpp
===
--- clang/tools/libclang/CIndexCodeCompletion.cpp
+++ clang/tools/libclang/CIndexCodeCompletion.cpp
@@ -586,6 +586,20 @@
   includeBriefComments());
 
 CXCompletionResult R;
+switch (Results[I].Kind) {
+case CodeCompletionResult::RK_Declaration:
+  R.ResultKind = CXCompletionResult_Declaration;
+  break;
+case CodeCompletionResult::RK_Keyword:
+  R.ResultKind = CXCompletionResult_Keyword;
+  break;
+case CodeCompletionResult::RK_Macro:
+  R.ResultKind = CXCompletionResult_Macro;
+  break;
+case CodeCompletionResult::RK_Pattern:
+  R.ResultKind = CXCompletionResult_Pattern;
+  break;
+}
 R.CursorKind = Results[I].CursorKind;
 R.CompletionString = StoredCompletion;
 StoredResults.push_back(R);
@@ -666,6 +680,7 @@
 includeBriefComments(), Braced);
 
 CXCompletionResult R;
+R.ResultKind = CXCompletionResult_Declaration;
 R.CursorKind = CXCursor_OverloadCandidate;
 R.CompletionString = StoredCompletion;
 StoredResults.push_back(R);
Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -5390,6 +5390,22 @@
   return clang_getCursorSpelling(C);
 }
 
+CXString
+clang_getCompletionResultKindSpelling(enum CXCompletionResultKind Kind) {
+  switch (Kind) {
+  case CXCompletionResult_Declaration:
+return cxstring::createRef("Declaration");
+  case CXCompletionResult_Keyword:
+return cxstring::createRef("Keyword");
+  case CXCompletionResult_Macro:
+return cxstring::createRef("Macro");
+  case CXCompletionResult_Pattern:
+return cxstring::createRef("Pattern");
+  }
+
+  llvm_unreachable("Unhandled CXCompletionResultKind");
+}
+
 CXString clang_getCursorKindSpelling(enum CXCursorKind Kind) {
   switch (Kind) {
   case CXCursor_FunctionDecl:
Index: clang/tools/c-index-test/c-index-test.c
===
--- clang/tools/c-index-test/c-index-test.c
+++ clang/tools/c-index-test/c-index-test.c
@@ -2505,7 +2505,10 @@
 unsigned index,
 FILE *file) {
   CXCompletionResult *completion_result = completion_results->Results + index;
-  CXString ks = clang_getCursorKindSpelling(completion_result->CursorKind);
+  CXString ks =
+  completion_result->CursorKind == CXCursor_NotImplemented
+  ? clang_getCompletionResultKindSpelling(completion_result->ResultKind)
+  : clang_getCursorKindSpelling(completion_result->CursorKind);
   unsigned annotationCount;
   enum CXCursorKind ParentKind;
   CXString ParentName;
Index: clang/test/Index/complete-type-factors.m
===
--- clang/test/Index/complete-type-factors.m
+++ 

[PATCH] D136790: [Clang][Sema] Add -Wincompatible-function-pointer-types-strict

2022-10-31 Thread Sami Tolvanen via Phabricator via cfe-commits
samitolvanen added a comment.

In D136790#3897184 , @aaron.ballman 
wrote:

> please be sure to add a release note so users know there's a new warning.

I'll add a release note. Thanks for the reminder!




Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:8217
+  err_typecheck_convert_incompatible_function_pointer.Text>,
+  InGroup>, 
DefaultIgnore;
 def ext_typecheck_convert_discards_qualifiers : ExtWarn<

aaron.ballman wrote:
> We don't typically add new off-by-default warnings because we have evidence 
> that users don't enable them enough to be worth adding them. Is there a way 
> we can enable this warning by default for CFI compilation units (or when the 
> cfi sanitizer is enabled) so that it's only off by default for non-CFI users? 
> I don't think we have any examples of doing this in the code base, so I 
> believe this would be breaking new ground (and thus is worth thinking about 
> more, perhaps it's a bad idea for some reason).
> Is there a way we can enable this warning by default for CFI compilation 
> units (or when the cfi sanitizer is enabled) so that it's only off by default 
> for non-CFI users?

I can look into it, but I'm not sure if there's a convenient way to do that. An 
alternative to this could be to enable the warning by default, but only 
actually perform the check if CFI is enabled. This way non-CFI users would 
never see the warning because this really isn't a concern for them, but CFI 
users would still get the warning without explicitly enabling it. Or do you 
think this behavior would be confusing?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136790

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


[PATCH] D129156: Add -fpass-plugin option to Flang

2022-10-31 Thread Tarun Prabhu via Phabricator via cfe-commits
tarunprabhu updated this revision to Diff 472161.
tarunprabhu added a comment.

Added a dependence for the flang tests on LLVM's Bye plugin. This results in 
the Bye plugin being built when check-flang is run, even if building examples 
has been explicitly disabled.

Removed the dependency on 'examples' in the pass-plugin.f90 test.

Some minor changes to function names for better consistency.


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

https://reviews.llvm.org/D129156

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Flang.cpp
  clang/lib/Driver/ToolChains/Flang.h
  flang/docs/FlangDriver.md
  flang/docs/ReleaseNotes.md
  flang/include/flang/Frontend/CodeGenOptions.h
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/Frontend/FrontendActions.cpp
  flang/test/CMakeLists.txt
  flang/test/Driver/driver-help-hidden.f90
  flang/test/Driver/driver-help.f90
  flang/test/Driver/frontend-forwarding.f90
  flang/test/Driver/pass-plugin-not-found.f90
  flang/test/Driver/pass-plugin.f90

Index: flang/test/Driver/pass-plugin.f90
===
--- /dev/null
+++ flang/test/Driver/pass-plugin.f90
@@ -0,0 +1,13 @@
+! Verify that the plugin passed to -fpass-plugin is loaded and run
+
+! UNSUPPORTED: system-windows
+
+! REQUIRES: plugins, shell
+
+! RUN: %flang -S %s -fpass-plugin=%llvmshlibdir/Bye%pluginext -Xflang -fdebug-pass-manager -o /dev/null 2>&1 | FileCheck %s
+! RUN: %flang_fc1 -S %s -fpass-plugin=%llvmshlibdir/Bye%pluginext -fdebug-pass-manager -o /dev/null 2>&1 | FileCheck %s
+
+! CHECK: Running pass: {{.*}}Bye on empty_
+
+subroutine empty
+end subroutine empty
Index: flang/test/Driver/pass-plugin-not-found.f90
===
--- /dev/null
+++ flang/test/Driver/pass-plugin-not-found.f90
@@ -0,0 +1,8 @@
+! Check the correct error diagnostic is reported when a pass plugin shared object isn't found
+
+! REQUIRES: plugins, shell
+
+! RUN: not %flang -fpass-plugin=X.Y %s 2>&1 | FileCheck %s --check-prefix=ERROR
+! RUN: not %flang_fc1 -emit-llvm -o /dev/null -fpass-plugin=X.Y %s 2>&1 | FileCheck %s --check-prefix=ERROR
+
+! ERROR: error: unable to load plugin 'X.Y': 'Could not load library 'X.Y': X.Y: cannot open shared object file: No such file or directory'
Index: flang/test/Driver/frontend-forwarding.f90
===
--- flang/test/Driver/frontend-forwarding.f90
+++ flang/test/Driver/frontend-forwarding.f90
@@ -9,6 +9,7 @@
 ! RUN: -flarge-sizes \
 ! RUN: -fconvert=little-endian \
 ! RUN: -ffp-contract=fast \
+! RUN: -fpass-plugin=Bye%pluginext \
 ! RUN: -mllvm -print-before-all\
 ! RUN: -P \
 ! RUN:   | FileCheck %s
@@ -21,4 +22,5 @@
 ! CHECK: "-flarge-sizes"
 ! CHECK: "-ffp-contract=fast"
 ! CHECK: "-fconvert=little-endian"
-! CHECK:  "-mllvm" "-print-before-all"
+! CHECK: "-fpass-plugin=Bye
+! CHECK: "-mllvm" "-print-before-all"
Index: flang/test/Driver/driver-help.f90
===
--- flang/test/Driver/driver-help.f90
+++ flang/test/Driver/driver-help.f90
@@ -44,6 +44,7 @@
 ! HELP-NEXT: -fno-integrated-as  Disable the integrated assembler
 ! HELP-NEXT: -fopenacc  Enable OpenACC
 ! HELP-NEXT: -fopenmp   Parse OpenMP pragmas and generate parallel code.
+! HELP-NEXT: -fpass-plugin= Load pass plugin from a dynamic shared object file (only with new pass manager).
 ! HELP-NEXT: -fsyntax-only  Run the preprocessor, parser and semantic analysis stages
 ! HELP-NEXT: -fxor-operator Enable .XOR. as a synonym of .NEQV.
 ! HELP-NEXT: -help  Display available options
@@ -124,6 +125,7 @@
 ! HELP-FC1-NEXT: -fno-reformat  Dump the cooked character stream in -E mode
 ! HELP-FC1-NEXT: -fopenacc  Enable OpenACC
 ! HELP-FC1-NEXT: -fopenmp   Parse OpenMP pragmas and generate parallel code.
+! HELP-FC1-NEXT: -fpass-plugin= Load pass plugin from a dynamic shared object file (only with new pass manager).
 ! HELP-FC1-NEXT: -fsyntax-only  Run the preprocessor, parser and semantic analysis stages
 ! HELP-FC1-NEXT: -fxor-operator Enable .XOR. as a synonym of .NEQV.
 ! HELP-FC1-NEXT: -help  Display available options
Index: flang/test/Driver/driver-help-hidden.f90
===
--- flang/test/Driver/driver-help-hidden.f90
+++ flang/test/Driver/driver-help-hidden.f90
@@ -46,6 +46,7 @@
 ! CHECK-NEXT: -fno-integrated-as Disable the integrated assembler
 ! CHECK-NEXT: -fopenacc  Enable OpenACC
 ! CHECK-NEXT: -fopenmp   Parse OpenMP pragmas and generate parallel code.
+! CHECK-NEXT: -fpass-plugin= Load pass plugin from a dynamic shared object file (only with new pass manager).
 ! CHECK-NEXT: -fsyntax-only  Run the preprocessor, parser and 

[PATCH] D137073: [clang] Fix inline builtin functions of an __asm__ renamed function with symbol prefixes

2022-10-31 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added inline comments.



Comment at: clang/lib/CodeGen/CGExpr.cpp:5020
+std::string AsmName;
+if (auto *A = FD->getAttr()) {
+  StringRef UserLabelPrefix =

I think you can call CGM.getMangledName, but I might be wrong. It's worth doing 
if straightforward.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137073

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


[PATCH] D136497: [Clang] support for outputs along indirect edges of asm goto

2022-10-31 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers added inline comments.



Comment at: clang/lib/CodeGen/CGStmt.cpp:2868-2873
+  // If we happen to share the same indirect and default dest, don't re-add
+  // stores. That was done for the default destination in the above call to
+  // EmitAsmStores.
+  llvm::BasicBlock *Succ = CBR->getIndirectDest(i);
+  if (Succ == CBR->getDefaultDest())
+continue;

nickdesaulniers wrote:
> void wrote:
> > nickdesaulniers wrote:
> > > nickdesaulniers wrote:
> > > > I'm not sure that I need to handle this case (of a callbr with the same 
> > > > indirect destination as the default destination).  That might result 
> > > > from optimizations, but I don't think clang can or will generate such 
> > > > IR.  Maybe I should turn this into an: `assert(CBR->getIndirectDest(i) 
> > > > != CBR->getDefaultDest(i) && "We already emitted asm stores in the 
> > > > default dest");`?
> > > Yeah, it's impossible. While a CallBrInst can have a same indirect 
> > > destination as the default destination as a result of optimizations, 
> > > above we always create an `"asm.fallthrough"` block that is distinct from 
> > > any of the named labels from the `asm goto`.
> > It could only happen with something like this:
> > 
> > ```
> > asm goto (...  indirect);
> > 
> > indirect:;
> > ```
> > 
> > In that simplified case, it looks like clang emits this:
> > 
> > ```
> > define dso_local void @foo() #0 {
> >   callbr void asm sideeffect "", "i,~{dirflag},~{fpsr},~{flags}"(i8* 
> > blockaddress(@foo, %2)) #1
> >   to label %1 [label %2], !srcloc !6
> > 
> > 1:; preds = %0
> >   br label %2
> > 
> > 2:; preds = %1, %0
> >   ret void
> > }
> > ```
> > 
> > So it's probably safe to make this an assert.
> Oh, it's not just the default and indirects sharing, but what if the same 
> indirect is listed twice?  I should add a test for that...i.e.
> 
> ```
> asm goto (...  indirect,indirect);
> ```
Oh, right, we don't allow that.

```
error: duplicate use of asm operand name "indirect"
note: asm operand name "indirect" first referenced here
```

I'm going to leave these asserts out and mark this thread done, but please 
reopen this thread with a new comment if you feel strongly that I should add it 
back (`assert(CBR->getIndirectDest(i) != CBR->getDefaultDest(i) && "We already 
emitted asm stores in the default dest");`).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136497

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


[PATCH] D136497: [Clang] support for outputs along indirect edges of asm goto

2022-10-31 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers updated this revision to Diff 472152.
nickdesaulniers marked an inline comment as done.
nickdesaulniers added a comment.

- reroll for a new sha so that phab unmarks this as "changes planned"


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136497

Files:
  clang/docs/LanguageExtensions.rst
  clang/lib/CodeGen/CGStmt.cpp
  clang/test/CodeGen/asm-goto.c
  clang/test/CodeGen/asm-goto2.c
  clang/test/Modules/asm-goto.c

Index: clang/test/Modules/asm-goto.c
===
--- clang/test/Modules/asm-goto.c
+++ clang/test/Modules/asm-goto.c
@@ -5,7 +5,7 @@
 
 // CHECK-LABEL: define {{.*}} @foo(
 // CHECK: callbr {{.*}} "=r,!i{{.*}}()
-// CHECK-NEXT: to label %asm.fallthrough [label %indirect]
+// CHECK-NEXT: to label %asm.fallthrough [label %indirect.split]
 
 int bar(void) {
   return foo();
Index: clang/test/CodeGen/asm-goto2.c
===
--- /dev/null
+++ clang/test/CodeGen/asm-goto2.c
@@ -0,0 +1,156 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// REQUIRES: x86-registered-target
+// RUN: %clang_cc1 -triple x86_64-pc-linux-gnu -O0 -emit-llvm %s -o - | FileCheck %s
+
+// CHECK-LABEL: @test0(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[RET:%.*]] = alloca i32, align 4
+// CHECK-NEXT:[[TMP0:%.*]] = callbr i32 asm "", "=r,!i,~{dirflag},~{fpsr},~{flags}"() #[[ATTR1:[0-9]+]]
+// CHECK-NEXT:to label [[ASM_FALLTHROUGH:%.*]] [label %z.split], !srcloc !2
+// CHECK:   asm.fallthrough:
+// CHECK-NEXT:store i32 [[TMP0]], ptr [[RET]], align 4
+// CHECK-NEXT:store i32 42, ptr [[RET]], align 4
+// CHECK-NEXT:br label [[Z:%.*]]
+// CHECK:   z:
+// CHECK-NEXT:[[TMP1:%.*]] = load i32, ptr [[RET]], align 4
+// CHECK-NEXT:ret i32 [[TMP1]]
+// CHECK:   z.split:
+// CHECK-NEXT:store i32 [[TMP0]], ptr [[RET]], align 4
+// CHECK-NEXT:br label [[Z]]
+//
+int test0 (void) {
+  int ret;
+  asm goto ("" : "=r"(ret):::z);
+  ret = 42;
+z:
+  return ret;
+}
+
+// CHECK-LABEL: @test1(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[RET:%.*]] = alloca i32, align 4
+// CHECK-NEXT:[[B:%.*]] = alloca i32, align 4
+// CHECK-NEXT:[[TMP0:%.*]] = callbr { i32, i32 } asm "", "=r,=r,!i,~{dirflag},~{fpsr},~{flags}"() #[[ATTR1]]
+// CHECK-NEXT:to label [[ASM_FALLTHROUGH:%.*]] [label %z.split], !srcloc !3
+// CHECK:   asm.fallthrough:
+// CHECK-NEXT:[[ASMRESULT:%.*]] = extractvalue { i32, i32 } [[TMP0]], 0
+// CHECK-NEXT:[[ASMRESULT1:%.*]] = extractvalue { i32, i32 } [[TMP0]], 1
+// CHECK-NEXT:store i32 [[ASMRESULT]], ptr [[RET]], align 4
+// CHECK-NEXT:store i32 [[ASMRESULT1]], ptr [[B]], align 4
+// CHECK-NEXT:store i32 42, ptr [[RET]], align 4
+// CHECK-NEXT:br label [[Z:%.*]]
+// CHECK:   z:
+// CHECK-NEXT:[[TMP1:%.*]] = load i32, ptr [[RET]], align 4
+// CHECK-NEXT:ret i32 [[TMP1]]
+// CHECK:   z.split:
+// CHECK-NEXT:[[ASMRESULT2:%.*]] = extractvalue { i32, i32 } [[TMP0]], 0
+// CHECK-NEXT:[[ASMRESULT3:%.*]] = extractvalue { i32, i32 } [[TMP0]], 1
+// CHECK-NEXT:store i32 [[ASMRESULT2]], ptr [[RET]], align 4
+// CHECK-NEXT:store i32 [[ASMRESULT3]], ptr [[B]], align 4
+// CHECK-NEXT:br label [[Z]]
+//
+int test1 (void) {
+  int ret, b;
+  asm goto ("" : "=r"(ret), "=r"(b):::z);
+  ret = 42;
+z:
+  return ret;
+}
+
+// CHECK-LABEL: @test2(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[RET:%.*]] = alloca i32, align 4
+// CHECK-NEXT:[[B:%.*]] = alloca i32, align 4
+// CHECK-NEXT:[[TMP0:%.*]] = callbr { i32, i32 } asm "", "=r,=r,!i,~{dirflag},~{fpsr},~{flags}"() #[[ATTR1]]
+// CHECK-NEXT:to label [[ASM_FALLTHROUGH:%.*]] [label %z.split], !srcloc !4
+// CHECK:   asm.fallthrough:
+// CHECK-NEXT:[[ASMRESULT:%.*]] = extractvalue { i32, i32 } [[TMP0]], 0
+// CHECK-NEXT:[[ASMRESULT1:%.*]] = extractvalue { i32, i32 } [[TMP0]], 1
+// CHECK-NEXT:store i32 [[ASMRESULT]], ptr [[RET]], align 4
+// CHECK-NEXT:store i32 [[ASMRESULT1]], ptr [[B]], align 4
+// CHECK-NEXT:[[TMP1:%.*]] = callbr { i32, i32 } asm "", "=r,=r,!i,~{dirflag},~{fpsr},~{flags}"() #[[ATTR1]]
+// CHECK-NEXT:to label [[ASM_FALLTHROUGH4:%.*]] [label %z.split9], !srcloc !5
+// CHECK:   asm.fallthrough4:
+// CHECK-NEXT:[[ASMRESULT5:%.*]] = extractvalue { i32, i32 } [[TMP1]], 0
+// CHECK-NEXT:[[ASMRESULT6:%.*]] = extractvalue { i32, i32 } [[TMP1]], 1
+// CHECK-NEXT:store i32 [[ASMRESULT5]], ptr [[RET]], align 4
+// CHECK-NEXT:store i32 [[ASMRESULT6]], ptr [[B]], align 4
+// CHECK-NEXT:br label [[Z:%.*]]
+// CHECK:   z:
+// CHECK-NEXT:[[TMP2:%.*]] = load i32, ptr [[RET]], align 4
+// CHECK-NEXT:ret i32 [[TMP2]]
+// CHECK:   z.split:
+// CHECK-NEXT:[[ASMRESULT2:%.*]] = extractvalue { i32, i32 } [[TMP0]], 0
+// CHECK-NEXT:[[ASMRESULT3:%.*]] = extractvalue 

[PATCH] D136497: [Clang] support for outputs along indirect edges of asm goto

2022-10-31 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers added inline comments.



Comment at: clang/lib/CodeGen/CGStmt.cpp:2868-2873
+  // If we happen to share the same indirect and default dest, don't re-add
+  // stores. That was done for the default destination in the above call to
+  // EmitAsmStores.
+  llvm::BasicBlock *Succ = CBR->getIndirectDest(i);
+  if (Succ == CBR->getDefaultDest())
+continue;

void wrote:
> nickdesaulniers wrote:
> > nickdesaulniers wrote:
> > > I'm not sure that I need to handle this case (of a callbr with the same 
> > > indirect destination as the default destination).  That might result from 
> > > optimizations, but I don't think clang can or will generate such IR.  
> > > Maybe I should turn this into an: `assert(CBR->getIndirectDest(i) != 
> > > CBR->getDefaultDest(i) && "We already emitted asm stores in the default 
> > > dest");`?
> > Yeah, it's impossible. While a CallBrInst can have a same indirect 
> > destination as the default destination as a result of optimizations, above 
> > we always create an `"asm.fallthrough"` block that is distinct from any of 
> > the named labels from the `asm goto`.
> It could only happen with something like this:
> 
> ```
> asm goto (...  indirect);
> 
> indirect:;
> ```
> 
> In that simplified case, it looks like clang emits this:
> 
> ```
> define dso_local void @foo() #0 {
>   callbr void asm sideeffect "", "i,~{dirflag},~{fpsr},~{flags}"(i8* 
> blockaddress(@foo, %2)) #1
>   to label %1 [label %2], !srcloc !6
> 
> 1:; preds = %0
>   br label %2
> 
> 2:; preds = %1, %0
>   ret void
> }
> ```
> 
> So it's probably safe to make this an assert.
Oh, it's not just the default and indirects sharing, but what if the same 
indirect is listed twice?  I should add a test for that...i.e.

```
asm goto (...  indirect,indirect);
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136497

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


[PATCH] D136497: [Clang] support for outputs along indirect edges of asm goto

2022-10-31 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers updated this revision to Diff 472144.
nickdesaulniers added a comment.

- remove unnecssary asserts


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136497

Files:
  clang/docs/LanguageExtensions.rst
  clang/lib/CodeGen/CGStmt.cpp
  clang/test/CodeGen/asm-goto.c
  clang/test/CodeGen/asm-goto2.c
  clang/test/Modules/asm-goto.c

Index: clang/test/Modules/asm-goto.c
===
--- clang/test/Modules/asm-goto.c
+++ clang/test/Modules/asm-goto.c
@@ -5,7 +5,7 @@
 
 // CHECK-LABEL: define {{.*}} @foo(
 // CHECK: callbr {{.*}} "=r,!i{{.*}}()
-// CHECK-NEXT: to label %asm.fallthrough [label %indirect]
+// CHECK-NEXT: to label %asm.fallthrough [label %indirect.split]
 
 int bar(void) {
   return foo();
Index: clang/test/CodeGen/asm-goto2.c
===
--- /dev/null
+++ clang/test/CodeGen/asm-goto2.c
@@ -0,0 +1,156 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// REQUIRES: x86-registered-target
+// RUN: %clang_cc1 -triple x86_64-pc-linux-gnu -O0 -emit-llvm %s -o - | FileCheck %s
+
+// CHECK-LABEL: @test0(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[RET:%.*]] = alloca i32, align 4
+// CHECK-NEXT:[[TMP0:%.*]] = callbr i32 asm "", "=r,!i,~{dirflag},~{fpsr},~{flags}"() #[[ATTR1:[0-9]+]]
+// CHECK-NEXT:to label [[ASM_FALLTHROUGH:%.*]] [label %z.split], !srcloc !2
+// CHECK:   asm.fallthrough:
+// CHECK-NEXT:store i32 [[TMP0]], ptr [[RET]], align 4
+// CHECK-NEXT:store i32 42, ptr [[RET]], align 4
+// CHECK-NEXT:br label [[Z:%.*]]
+// CHECK:   z:
+// CHECK-NEXT:[[TMP1:%.*]] = load i32, ptr [[RET]], align 4
+// CHECK-NEXT:ret i32 [[TMP1]]
+// CHECK:   z.split:
+// CHECK-NEXT:store i32 [[TMP0]], ptr [[RET]], align 4
+// CHECK-NEXT:br label [[Z]]
+//
+int test0 (void) {
+  int ret;
+  asm goto ("" : "=r"(ret):::z);
+  ret = 42;
+z:
+  return ret;
+}
+
+// CHECK-LABEL: @test1(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[RET:%.*]] = alloca i32, align 4
+// CHECK-NEXT:[[B:%.*]] = alloca i32, align 4
+// CHECK-NEXT:[[TMP0:%.*]] = callbr { i32, i32 } asm "", "=r,=r,!i,~{dirflag},~{fpsr},~{flags}"() #[[ATTR1]]
+// CHECK-NEXT:to label [[ASM_FALLTHROUGH:%.*]] [label %z.split], !srcloc !3
+// CHECK:   asm.fallthrough:
+// CHECK-NEXT:[[ASMRESULT:%.*]] = extractvalue { i32, i32 } [[TMP0]], 0
+// CHECK-NEXT:[[ASMRESULT1:%.*]] = extractvalue { i32, i32 } [[TMP0]], 1
+// CHECK-NEXT:store i32 [[ASMRESULT]], ptr [[RET]], align 4
+// CHECK-NEXT:store i32 [[ASMRESULT1]], ptr [[B]], align 4
+// CHECK-NEXT:store i32 42, ptr [[RET]], align 4
+// CHECK-NEXT:br label [[Z:%.*]]
+// CHECK:   z:
+// CHECK-NEXT:[[TMP1:%.*]] = load i32, ptr [[RET]], align 4
+// CHECK-NEXT:ret i32 [[TMP1]]
+// CHECK:   z.split:
+// CHECK-NEXT:[[ASMRESULT2:%.*]] = extractvalue { i32, i32 } [[TMP0]], 0
+// CHECK-NEXT:[[ASMRESULT3:%.*]] = extractvalue { i32, i32 } [[TMP0]], 1
+// CHECK-NEXT:store i32 [[ASMRESULT2]], ptr [[RET]], align 4
+// CHECK-NEXT:store i32 [[ASMRESULT3]], ptr [[B]], align 4
+// CHECK-NEXT:br label [[Z]]
+//
+int test1 (void) {
+  int ret, b;
+  asm goto ("" : "=r"(ret), "=r"(b):::z);
+  ret = 42;
+z:
+  return ret;
+}
+
+// CHECK-LABEL: @test2(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[RET:%.*]] = alloca i32, align 4
+// CHECK-NEXT:[[B:%.*]] = alloca i32, align 4
+// CHECK-NEXT:[[TMP0:%.*]] = callbr { i32, i32 } asm "", "=r,=r,!i,~{dirflag},~{fpsr},~{flags}"() #[[ATTR1]]
+// CHECK-NEXT:to label [[ASM_FALLTHROUGH:%.*]] [label %z.split], !srcloc !4
+// CHECK:   asm.fallthrough:
+// CHECK-NEXT:[[ASMRESULT:%.*]] = extractvalue { i32, i32 } [[TMP0]], 0
+// CHECK-NEXT:[[ASMRESULT1:%.*]] = extractvalue { i32, i32 } [[TMP0]], 1
+// CHECK-NEXT:store i32 [[ASMRESULT]], ptr [[RET]], align 4
+// CHECK-NEXT:store i32 [[ASMRESULT1]], ptr [[B]], align 4
+// CHECK-NEXT:[[TMP1:%.*]] = callbr { i32, i32 } asm "", "=r,=r,!i,~{dirflag},~{fpsr},~{flags}"() #[[ATTR1]]
+// CHECK-NEXT:to label [[ASM_FALLTHROUGH4:%.*]] [label %z.split9], !srcloc !5
+// CHECK:   asm.fallthrough4:
+// CHECK-NEXT:[[ASMRESULT5:%.*]] = extractvalue { i32, i32 } [[TMP1]], 0
+// CHECK-NEXT:[[ASMRESULT6:%.*]] = extractvalue { i32, i32 } [[TMP1]], 1
+// CHECK-NEXT:store i32 [[ASMRESULT5]], ptr [[RET]], align 4
+// CHECK-NEXT:store i32 [[ASMRESULT6]], ptr [[B]], align 4
+// CHECK-NEXT:br label [[Z:%.*]]
+// CHECK:   z:
+// CHECK-NEXT:[[TMP2:%.*]] = load i32, ptr [[RET]], align 4
+// CHECK-NEXT:ret i32 [[TMP2]]
+// CHECK:   z.split:
+// CHECK-NEXT:[[ASMRESULT2:%.*]] = extractvalue { i32, i32 } [[TMP0]], 0
+// CHECK-NEXT:[[ASMRESULT3:%.*]] = extractvalue { i32, i32 } [[TMP0]], 1
+// CHECK-NEXT:store i32 [[ASMRESULT2]], ptr [[RET]], align 4

[PATCH] D136497: [Clang] support for outputs along indirect edges of asm goto

2022-10-31 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers added inline comments.



Comment at: clang/lib/CodeGen/CGStmt.cpp:2868-2873
+  // If we happen to share the same indirect and default dest, don't re-add
+  // stores. That was done for the default destination in the above call to
+  // EmitAsmStores.
+  llvm::BasicBlock *Succ = CBR->getIndirectDest(i);
+  if (Succ == CBR->getDefaultDest())
+continue;

nickdesaulniers wrote:
> I'm not sure that I need to handle this case (of a callbr with the same 
> indirect destination as the default destination).  That might result from 
> optimizations, but I don't think clang can or will generate such IR.  Maybe I 
> should turn this into an: `assert(CBR->getIndirectDest(i) != 
> CBR->getDefaultDest(i) && "We already emitted asm stores in the default 
> dest");`?
Yeah, it's impossible. While a CallBrInst can have a same indirect destination 
as the default destination as a result of optimizations, above we always create 
an `"asm.fallthrough"` block that is distinct from any of the named labels from 
the `asm goto`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136497

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


[PATCH] D137116: [AggressiveInstCombine] Remove legacy PM pass

2022-10-31 Thread Arthur Eubanks via Phabricator via cfe-commits
aeubanks created this revision.
aeubanks added a reviewer: asbirlea.
Herald added a reviewer: deadalnix.
Herald added subscribers: ormris, hiraditya.
Herald added a reviewer: ctetreau.
Herald added a reviewer: ctetreau.
Herald added a reviewer: ctetreau.
Herald added a reviewer: ctetreau.
Herald added a project: All.
aeubanks requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

As part of legacy PM optimization pipeline removal.

This shouldn't be used in codegen pipelines so it should be ok to remove.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D137116

Files:
  clang/tools/clang-fuzzer/fuzzer-initialize/fuzzer_initialize.cpp
  llvm/bindings/python/llvm/core.py
  llvm/include/llvm-c/Initialization.h
  llvm/include/llvm-c/Transforms/AggressiveInstCombine.h
  llvm/include/llvm/InitializePasses.h
  llvm/include/llvm/LinkAllPasses.h
  llvm/include/llvm/Transforms/AggressiveInstCombine/AggressiveInstCombine.h
  llvm/lib/Transforms/AggressiveInstCombine/AggressiveInstCombine.cpp
  llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
  llvm/test/Transforms/PhaseOrdering/X86/pr52078.ll
  llvm/test/Transforms/PhaseOrdering/X86/pr52253.ll
  llvm/tools/bugpoint/bugpoint.cpp
  llvm/tools/llvm-c-test/include-all.c
  llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp
  llvm/tools/opt/opt.cpp

Index: llvm/tools/opt/opt.cpp
===
--- llvm/tools/opt/opt.cpp
+++ llvm/tools/opt/opt.cpp
@@ -499,7 +499,6 @@
   initializeAnalysis(Registry);
   initializeTransformUtils(Registry);
   initializeInstCombine(Registry);
-  initializeAggressiveInstCombine(Registry);
   initializeTarget(Registry);
   // For codegen passes, only passes that do IR to IR transformation are
   // supported.
Index: llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp
===
--- llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp
+++ llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp
@@ -197,7 +197,6 @@
   initializeAnalysis(Registry);
   initializeTransformUtils(Registry);
   initializeInstCombine(Registry);
-  initializeAggressiveInstCombine(Registry);
   initializeTarget(Registry);
 
   // Parse input options
Index: llvm/tools/llvm-c-test/include-all.c
===
--- llvm/tools/llvm-c-test/include-all.c
+++ llvm/tools/llvm-c-test/include-all.c
@@ -35,7 +35,6 @@
 #include "llvm-c/Support.h"
 #include "llvm-c/Target.h"
 #include "llvm-c/TargetMachine.h"
-#include "llvm-c/Transforms/AggressiveInstCombine.h"
 #include "llvm-c/Transforms/InstCombine.h"
 #include "llvm-c/Transforms/IPO.h"
 #include "llvm-c/Transforms/PassManagerBuilder.h"
Index: llvm/tools/bugpoint/bugpoint.cpp
===
--- llvm/tools/bugpoint/bugpoint.cpp
+++ llvm/tools/bugpoint/bugpoint.cpp
@@ -148,7 +148,6 @@
   initializeAnalysis(Registry);
   initializeTransformUtils(Registry);
   initializeInstCombine(Registry);
-  initializeAggressiveInstCombine(Registry);
   initializeTarget(Registry);
 
   if (std::getenv("bar") == (char*) -1) {
Index: llvm/test/Transforms/PhaseOrdering/X86/pr52253.ll
===
--- llvm/test/Transforms/PhaseOrdering/X86/pr52253.ll
+++ llvm/test/Transforms/PhaseOrdering/X86/pr52253.ll
@@ -1,7 +1,7 @@
 ; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
 ; RUN: opt -O3 -S < %s | FileCheck %s
-; RUN: opt -instcombine -sccp -bdce -S < %s | FileCheck %s
-; RUN: opt -aggressive-instcombine -instcombine -sccp -bdce -S < %s | FileCheck %s
+; RUN: opt -passes=instcombine,sccp,bdce -S < %s | FileCheck %s
+; RUN: opt -passes=aggressive-instcombine,instcombine,sccp,bdce -S < %s | FileCheck %s
 
 target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
 target triple = "x86_64-unknown-linux-gnu"
Index: llvm/test/Transforms/PhaseOrdering/X86/pr52078.ll
===
--- llvm/test/Transforms/PhaseOrdering/X86/pr52078.ll
+++ llvm/test/Transforms/PhaseOrdering/X86/pr52078.ll
@@ -1,7 +1,7 @@
 ; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
 ; RUN: opt -O2 -S < %s | FileCheck %s
-; RUN: opt -instcombine -S < %s | FileCheck %s --check-prefix=IC
-; RUN: opt -aggressive-instcombine -instcombine -S < %s | FileCheck %s --check-prefix=AIC_AND_IC
+; RUN: opt -passes=instcombine -S < %s | FileCheck %s --check-prefix=IC
+; RUN: opt -passes=aggressive-instcombine,instcombine -S < %s | FileCheck %s --check-prefix=AIC_AND_IC
 
 target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
 target triple = "x86_64-unknown-linux-gnu"
Index: llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
===
--- 

[PATCH] D136497: [Clang] support for outputs along indirect edges of asm goto

2022-10-31 Thread Bill Wendling via Phabricator via cfe-commits
void added inline comments.



Comment at: clang/lib/CodeGen/CGStmt.cpp:2868-2873
+  // If we happen to share the same indirect and default dest, don't re-add
+  // stores. That was done for the default destination in the above call to
+  // EmitAsmStores.
+  llvm::BasicBlock *Succ = CBR->getIndirectDest(i);
+  if (Succ == CBR->getDefaultDest())
+continue;

nickdesaulniers wrote:
> I'm not sure that I need to handle this case (of a callbr with the same 
> indirect destination as the default destination).  That might result from 
> optimizations, but I don't think clang can or will generate such IR.  Maybe I 
> should turn this into an: `assert(CBR->getIndirectDest(i) != 
> CBR->getDefaultDest(i) && "We already emitted asm stores in the default 
> dest");`?
It could only happen with something like this:

```
asm goto (...  indirect);

indirect:;
```

In that simplified case, it looks like clang emits this:

```
define dso_local void @foo() #0 {
  callbr void asm sideeffect "", "i,~{dirflag},~{fpsr},~{flags}"(i8* 
blockaddress(@foo, %2)) #1
  to label %1 [label %2], !srcloc !6

1:; preds = %0
  br label %2

2:; preds = %1, %0
  ret void
}
```

So it's probably safe to make this an assert.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136497

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


[PATCH] D136497: [Clang] support for outputs along indirect edges of asm goto

2022-10-31 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers planned changes to this revision.
nickdesaulniers added inline comments.



Comment at: clang/lib/CodeGen/CGStmt.cpp:2867
+for (unsigned i = 0, e = CBR->getNumIndirectDests(); i != e; ++i) {
+  assert(CBRRegResults[i].size() == ResultRegTypes.size());
+  // If we happen to share the same indirect and default dest, don't re-add

Oh, I can remove this now, I moved it into `EmitAsmStores`.



Comment at: clang/lib/CodeGen/CGStmt.cpp:2868-2873
+  // If we happen to share the same indirect and default dest, don't re-add
+  // stores. That was done for the default destination in the above call to
+  // EmitAsmStores.
+  llvm::BasicBlock *Succ = CBR->getIndirectDest(i);
+  if (Succ == CBR->getDefaultDest())
+continue;

I'm not sure that I need to handle this case (of a callbr with the same 
indirect destination as the default destination).  That might result from 
optimizations, but I don't think clang can or will generate such IR.  Maybe I 
should turn this into an: `assert(CBR->getIndirectDest(i) != 
CBR->getDefaultDest(i) && "We already emitted asm stores in the default 
dest");`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136497

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


[PATCH] D137113: [Clang] refactor CodeGenFunction::EmitAsmStmt NFC

2022-10-31 Thread Bill Wendling via Phabricator via cfe-commits
void accepted this revision.
void 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/D137113/new/

https://reviews.llvm.org/D137113

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


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

2022-10-31 Thread Martin Storsjö via Phabricator via cfe-commits
mstorsjo added a comment.

In D137107#3897326 , @rnk wrote:

> Unless I'm missing something, I think Clang's behavior here is preferable to 
> MSVC's. MSVC produces code which will not link. Clang turns the linker error 
> into a compiler error, which is generally easier for the user to understand. 
> To my knowledge, it is still true that there is no COFF relocation which can 
> statically initialize a global variable with the address of a dllimported 
> symbol.
>
> For the use case you are considering, how do things work out in practice? Is 
> there some new import patching facility that I'm not aware of? Is the 
> variable linked statically instead of dynamically, and then the linker 
> relaxes the __imp references to direct references?

The testcase that is shown here is peculiar in the sense that `constexpr int& 
val_ref = val;` is located within `main()`, so it isn't really constexpr (as 
far as I'd undestand it), but MSVC produces a load from `__imp_val`.

> I am ready to be wrong here: if things have changed and my info is stale, we 
> should definitely adapt.

I'm not aware of anything that would have changed here...

For the cases where this needs to be really statically initialized, the mingw 
pseudo relocations do fill that spot (which fakes it by initializing it very 
early on, from a linker-generated list of spots in the binary that needs 
patching). For non-constexpr cases in C++, Clang solves it by implicitly 
generating a static constructor which fetches it from the dllimported variable.


Repository:
  rG LLVM Github Monorepo

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] D135987: [clangBasic] Refactor StaticAnalyzer to use `clang::SarifDocumentWriter`

2022-10-31 Thread Vaibhav Yenamandra via Phabricator via cfe-commits
vaibhav.y created this revision.
vaibhav.y added reviewers: aaron.ballman, cjdb.
Herald added subscribers: steakhal, wenlei, martong.
Herald added a reviewer: NoQ.
Herald added a project: All.
vaibhav.y updated this revision to Diff 472133.
vaibhav.y added a comment.
vaibhav.y added a reviewer: dbeer1.
vaibhav.y retitled this revision from "[clangBasic] Create 
`FullSourceLoc::getDecomposedExpansionLoc`" to "[clangBasic] Refactor 
StaticAnalyzer to use `clang::SarifDocumentWriter`".
vaibhav.y edited the summary of this revision.
Herald added subscribers: manas, ASDenysPetrov, dkrupp, donat.nagy, Szelethus, 
a.sidorin, baloghadamsoftware.
vaibhav.y published this revision for review.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Update unit tests




Comment at: clang/lib/Basic/Sarif.cpp:121-123
+  std::pair LocInfo = Loc.getDecomposedExpansionLoc();
+  assert(LocInfo.second > Loc.getExpansionColumnNumber() &&
+ "position in file is before column number?");

L121 was copied wrong, `libStaticAnalyzer` (sensibly) uses the expansion loc. 
This has been fixed as well.


Refactor StaticAnalyzer to use `clang::SarifDocumentWriter` for serializing 
sarif diagnostics.

Uses `clang::SarifDocumentWriter` to generate SARIF output in the 
StaticAnalyzer.

Various bugfixes are also made to `clang::SarifDocumentWriter`.

Summary of changes:

- `clang/lib/Basic/Sarif.cpp`:
  - Fix bug in adjustColumnPos introduced from prev move, it now uses 
FullSourceLoc::getDecomposedExpansionLoc which provides the correct location 
(in the presence of macros) instead of `FullSourceLoc::getDecomposedLoc`.
  - Fix `createTextRegion` so that it handles caret ranges correctly, this 
should bring it to parity with the previous implementation.
- `clang/test/Analysis/diagnostics/Inputs/expected-sarif`:
  - Update the schema URL to the offical website
  - Add the emitted `defaultConfiguration` sections to all rules
  - Annotate results with the "level" property
- `clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp`:
  - Update `SarifDiagnostics` class to hold a `clang::SarifDocumentWriter` that 
it uses to convert diagnostics to SARIF.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D135987

Files:
  clang/include/clang/Basic/SourceLocation.h
  clang/lib/Basic/Sarif.cpp
  clang/lib/Basic/SourceLocation.cpp
  clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
  
clang/test/Analysis/diagnostics/Inputs/expected-sarif/sarif-diagnostics-taint-test.c.sarif
  
clang/test/Analysis/diagnostics/Inputs/expected-sarif/sarif-multi-diagnostic-test.c.sarif
  clang/unittests/Basic/SarifTest.cpp

Index: clang/unittests/Basic/SarifTest.cpp
===
--- clang/unittests/Basic/SarifTest.cpp
+++ clang/unittests/Basic/SarifTest.cpp
@@ -292,7 +292,7 @@
 TEST_F(SarifDocumentWriterTest, checkSerializingArtifacts) {
   // GIVEN:
   const std::string ExpectedOutput =
-  R"({"$schema":"https://docs.oasis-open.org/sarif/sarif/v2.1.0/cos02/schemas/sarif-schema-2.1.0.json","runs":[{"artifacts":[{"length":40,"location":{"index":0,"uri":"file:///main.cpp"},"mimeType":"text/plain","roles":["resultFile"]}],"columnKind":"unicodeCodePoints","results":[{"level":"error","locations":[{"physicalLocation":{"artifactLocation":{"index":0},"region":{"endColumn":14,"startColumn":14,"startLine":3}}}],"message":{"text":"expected ';' after top level declarator"},"ruleId":"clang.unittest","ruleIndex":0}],"tool":{"driver":{"fullName":"sarif test runner","informationUri":"https://clang.llvm.org/docs/UsersManual.html","language":"en-US","name":"sarif test","rules":[{"defaultConfiguration":{"enabled":true,"level":"warning","rank":-1},"fullDescription":{"text":"Example rule created during unit tests"},"id":"clang.unittest","name":"clang unit test"}],"version":"1.0.0"}}}],"version":"2.1.0"})";
+  R"({"$schema":"https://docs.oasis-open.org/sarif/sarif/v2.1.0/cos02/schemas/sarif-schema-2.1.0.json","runs":[{"artifacts":[{"length":40,"location":{"index":0,"uri":"file:///main.cpp"},"mimeType":"text/plain","roles":["resultFile"]}],"columnKind":"unicodeCodePoints","results":[{"level":"error","locations":[{"physicalLocation":{"artifactLocation":{"index":0,"uri":"file:///main.cpp"},"region":{"endColumn":14,"startColumn":14,"startLine":3}}}],"message":{"text":"expected ';' after top level declarator"},"ruleId":"clang.unittest","ruleIndex":0}],"tool":{"driver":{"fullName":"sarif test runner","informationUri":"https://clang.llvm.org/docs/UsersManual.html","language":"en-US","name":"sarif test","rules":[{"defaultConfiguration":{"enabled":true,"level":"warning","rank":-1},"fullDescription":{"text":"Example rule created during unit tests"},"id":"clang.unittest","name":"clang unit test"}],"version":"1.0.0"}}}],"version":"2.1.0"})";
 
   SarifDocumentWriter Writer{SourceMgr};
   const SarifRule  =
@@ -332,7 +332,7 @@
 TEST_F(SarifDocumentWriterTest, 

[PATCH] D136497: [Clang] support for outputs along indirect edges of asm goto

2022-10-31 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers updated this revision to Diff 472136.
nickdesaulniers added a comment.

- rebase on D137113 , add comment


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136497

Files:
  clang/docs/LanguageExtensions.rst
  clang/lib/CodeGen/CGStmt.cpp
  clang/test/CodeGen/asm-goto.c
  clang/test/CodeGen/asm-goto2.c
  clang/test/Modules/asm-goto.c

Index: clang/test/Modules/asm-goto.c
===
--- clang/test/Modules/asm-goto.c
+++ clang/test/Modules/asm-goto.c
@@ -5,7 +5,7 @@
 
 // CHECK-LABEL: define {{.*}} @foo(
 // CHECK: callbr {{.*}} "=r,!i{{.*}}()
-// CHECK-NEXT: to label %asm.fallthrough [label %indirect]
+// CHECK-NEXT: to label %asm.fallthrough [label %indirect.split]
 
 int bar(void) {
   return foo();
Index: clang/test/CodeGen/asm-goto2.c
===
--- /dev/null
+++ clang/test/CodeGen/asm-goto2.c
@@ -0,0 +1,156 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// REQUIRES: x86-registered-target
+// RUN: %clang_cc1 -triple x86_64-pc-linux-gnu -O0 -emit-llvm %s -o - | FileCheck %s
+
+// CHECK-LABEL: @test0(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[RET:%.*]] = alloca i32, align 4
+// CHECK-NEXT:[[TMP0:%.*]] = callbr i32 asm "", "=r,!i,~{dirflag},~{fpsr},~{flags}"() #[[ATTR1:[0-9]+]]
+// CHECK-NEXT:to label [[ASM_FALLTHROUGH:%.*]] [label %z.split], !srcloc !2
+// CHECK:   asm.fallthrough:
+// CHECK-NEXT:store i32 [[TMP0]], ptr [[RET]], align 4
+// CHECK-NEXT:store i32 42, ptr [[RET]], align 4
+// CHECK-NEXT:br label [[Z:%.*]]
+// CHECK:   z:
+// CHECK-NEXT:[[TMP1:%.*]] = load i32, ptr [[RET]], align 4
+// CHECK-NEXT:ret i32 [[TMP1]]
+// CHECK:   z.split:
+// CHECK-NEXT:store i32 [[TMP0]], ptr [[RET]], align 4
+// CHECK-NEXT:br label [[Z]]
+//
+int test0 (void) {
+  int ret;
+  asm goto ("" : "=r"(ret):::z);
+  ret = 42;
+z:
+  return ret;
+}
+
+// CHECK-LABEL: @test1(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[RET:%.*]] = alloca i32, align 4
+// CHECK-NEXT:[[B:%.*]] = alloca i32, align 4
+// CHECK-NEXT:[[TMP0:%.*]] = callbr { i32, i32 } asm "", "=r,=r,!i,~{dirflag},~{fpsr},~{flags}"() #[[ATTR1]]
+// CHECK-NEXT:to label [[ASM_FALLTHROUGH:%.*]] [label %z.split], !srcloc !3
+// CHECK:   asm.fallthrough:
+// CHECK-NEXT:[[ASMRESULT:%.*]] = extractvalue { i32, i32 } [[TMP0]], 0
+// CHECK-NEXT:[[ASMRESULT1:%.*]] = extractvalue { i32, i32 } [[TMP0]], 1
+// CHECK-NEXT:store i32 [[ASMRESULT]], ptr [[RET]], align 4
+// CHECK-NEXT:store i32 [[ASMRESULT1]], ptr [[B]], align 4
+// CHECK-NEXT:store i32 42, ptr [[RET]], align 4
+// CHECK-NEXT:br label [[Z:%.*]]
+// CHECK:   z:
+// CHECK-NEXT:[[TMP1:%.*]] = load i32, ptr [[RET]], align 4
+// CHECK-NEXT:ret i32 [[TMP1]]
+// CHECK:   z.split:
+// CHECK-NEXT:[[ASMRESULT2:%.*]] = extractvalue { i32, i32 } [[TMP0]], 0
+// CHECK-NEXT:[[ASMRESULT3:%.*]] = extractvalue { i32, i32 } [[TMP0]], 1
+// CHECK-NEXT:store i32 [[ASMRESULT2]], ptr [[RET]], align 4
+// CHECK-NEXT:store i32 [[ASMRESULT3]], ptr [[B]], align 4
+// CHECK-NEXT:br label [[Z]]
+//
+int test1 (void) {
+  int ret, b;
+  asm goto ("" : "=r"(ret), "=r"(b):::z);
+  ret = 42;
+z:
+  return ret;
+}
+
+// CHECK-LABEL: @test2(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[RET:%.*]] = alloca i32, align 4
+// CHECK-NEXT:[[B:%.*]] = alloca i32, align 4
+// CHECK-NEXT:[[TMP0:%.*]] = callbr { i32, i32 } asm "", "=r,=r,!i,~{dirflag},~{fpsr},~{flags}"() #[[ATTR1]]
+// CHECK-NEXT:to label [[ASM_FALLTHROUGH:%.*]] [label %z.split], !srcloc !4
+// CHECK:   asm.fallthrough:
+// CHECK-NEXT:[[ASMRESULT:%.*]] = extractvalue { i32, i32 } [[TMP0]], 0
+// CHECK-NEXT:[[ASMRESULT1:%.*]] = extractvalue { i32, i32 } [[TMP0]], 1
+// CHECK-NEXT:store i32 [[ASMRESULT]], ptr [[RET]], align 4
+// CHECK-NEXT:store i32 [[ASMRESULT1]], ptr [[B]], align 4
+// CHECK-NEXT:[[TMP1:%.*]] = callbr { i32, i32 } asm "", "=r,=r,!i,~{dirflag},~{fpsr},~{flags}"() #[[ATTR1]]
+// CHECK-NEXT:to label [[ASM_FALLTHROUGH4:%.*]] [label %z.split9], !srcloc !5
+// CHECK:   asm.fallthrough4:
+// CHECK-NEXT:[[ASMRESULT5:%.*]] = extractvalue { i32, i32 } [[TMP1]], 0
+// CHECK-NEXT:[[ASMRESULT6:%.*]] = extractvalue { i32, i32 } [[TMP1]], 1
+// CHECK-NEXT:store i32 [[ASMRESULT5]], ptr [[RET]], align 4
+// CHECK-NEXT:store i32 [[ASMRESULT6]], ptr [[B]], align 4
+// CHECK-NEXT:br label [[Z:%.*]]
+// CHECK:   z:
+// CHECK-NEXT:[[TMP2:%.*]] = load i32, ptr [[RET]], align 4
+// CHECK-NEXT:ret i32 [[TMP2]]
+// CHECK:   z.split:
+// CHECK-NEXT:[[ASMRESULT2:%.*]] = extractvalue { i32, i32 } [[TMP0]], 0
+// CHECK-NEXT:[[ASMRESULT3:%.*]] = extractvalue { i32, i32 } [[TMP0]], 1
+// CHECK-NEXT:store 

[PATCH] D136497: [Clang] support for outputs along indirect edges of asm goto

2022-10-31 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers added inline comments.



Comment at: clang/lib/CodeGen/CGStmt.cpp:2850
 
   assert(RegResults.size() == ResultRegTypes.size());
   assert(RegResults.size() == ResultTruncRegTypes.size());

nickdesaulniers wrote:
> void wrote:
> > Should these asserts (or some of them) be moved into `EmitAsmStores()`?
> Ah, yeah, let me add those to D137113.
Now done in D137113.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136497

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


[PATCH] D137113: [Clang] refactor CodeGenFunction::EmitAsmStmt NFC

2022-10-31 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers updated this revision to Diff 472132.
nickdesaulniers added a comment.

- move asserts


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137113

Files:
  clang/lib/CodeGen/CGStmt.cpp

Index: clang/lib/CodeGen/CGStmt.cpp
===
--- clang/lib/CodeGen/CGStmt.cpp
+++ clang/lib/CodeGen/CGStmt.cpp
@@ -24,6 +24,7 @@
 #include "clang/Basic/PrettyStackTrace.h"
 #include "clang/Basic/SourceManager.h"
 #include "clang/Basic/TargetInfo.h"
+#include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/SmallSet.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/IR/Assumptions.h"
@@ -2325,6 +2326,93 @@
   }
 }
 
+static void
+EmitAsmStores(CodeGenFunction , const AsmStmt ,
+  const llvm::ArrayRef RegResults,
+  const llvm::ArrayRef ResultRegTypes,
+  const llvm::ArrayRef ResultTruncRegTypes,
+  const llvm::ArrayRef ResultRegDests,
+  const llvm::ArrayRef ResultRegQualTys,
+  const llvm::BitVector ,
+  const llvm::BitVector ) {
+  CGBuilderTy  = CGF.Builder;
+  CodeGenModule  = CGF.CGM;
+  llvm::LLVMContext  = CGF.getLLVMContext();
+
+  assert(RegResults.size() == ResultRegTypes.size());
+  assert(RegResults.size() == ResultTruncRegTypes.size());
+  assert(RegResults.size() == ResultRegDests.size());
+  // ResultRegDests can be also populated by addReturnRegisterOutputs() above,
+  // in which case its size may grow.
+  assert(ResultTypeRequiresCast.size() <= ResultRegDests.size());
+  assert(ResultRegIsFlagReg.size() <= ResultRegDests.size());
+
+  for (unsigned i = 0, e = RegResults.size(); i != e; ++i) {
+llvm::Value *Tmp = RegResults[i];
+llvm::Type *TruncTy = ResultTruncRegTypes[i];
+
+if ((i < ResultRegIsFlagReg.size()) && ResultRegIsFlagReg[i]) {
+  // Target must guarantee the Value `Tmp` here is lowered to a boolean
+  // value.
+  llvm::Constant *Two = llvm::ConstantInt::get(Tmp->getType(), 2);
+  llvm::Value *IsBooleanValue =
+  Builder.CreateCmp(llvm::CmpInst::ICMP_ULT, Tmp, Two);
+  llvm::Function *FnAssume = CGM.getIntrinsic(llvm::Intrinsic::assume);
+  Builder.CreateCall(FnAssume, IsBooleanValue);
+}
+
+// If the result type of the LLVM IR asm doesn't match the result type of
+// the expression, do the conversion.
+if (ResultRegTypes[i] != TruncTy) {
+
+  // Truncate the integer result to the right size, note that TruncTy can be
+  // a pointer.
+  if (TruncTy->isFloatingPointTy())
+Tmp = Builder.CreateFPTrunc(Tmp, TruncTy);
+  else if (TruncTy->isPointerTy() && Tmp->getType()->isIntegerTy()) {
+uint64_t ResSize = CGM.getDataLayout().getTypeSizeInBits(TruncTy);
+Tmp = Builder.CreateTrunc(
+Tmp, llvm::IntegerType::get(CTX, (unsigned)ResSize));
+Tmp = Builder.CreateIntToPtr(Tmp, TruncTy);
+  } else if (Tmp->getType()->isPointerTy() && TruncTy->isIntegerTy()) {
+uint64_t TmpSize =
+CGM.getDataLayout().getTypeSizeInBits(Tmp->getType());
+Tmp = Builder.CreatePtrToInt(
+Tmp, llvm::IntegerType::get(CTX, (unsigned)TmpSize));
+Tmp = Builder.CreateTrunc(Tmp, TruncTy);
+  } else if (TruncTy->isIntegerTy()) {
+Tmp = Builder.CreateZExtOrTrunc(Tmp, TruncTy);
+  } else if (TruncTy->isVectorTy()) {
+Tmp = Builder.CreateBitCast(Tmp, TruncTy);
+  }
+}
+
+LValue Dest = ResultRegDests[i];
+// ResultTypeRequiresCast elements correspond to the first
+// ResultTypeRequiresCast.size() elements of RegResults.
+if ((i < ResultTypeRequiresCast.size()) && ResultTypeRequiresCast[i]) {
+  unsigned Size = CGF.getContext().getTypeSize(ResultRegQualTys[i]);
+  Address A =
+  Builder.CreateElementBitCast(Dest.getAddress(CGF), ResultRegTypes[i]);
+  if (CGF.getTargetHooks().isScalarizableAsmOperand(CGF, TruncTy)) {
+Builder.CreateStore(Tmp, A);
+continue;
+  }
+
+  QualType Ty =
+  CGF.getContext().getIntTypeForBitwidth(Size, /*Signed*/ false);
+  if (Ty.isNull()) {
+const Expr *OutExpr = S.getOutputExpr(i);
+CGM.getDiags().Report(OutExpr->getExprLoc(),
+  diag::err_store_value_to_reg);
+return;
+  }
+  Dest = CGF.MakeAddrLValue(A, Ty);
+}
+CGF.EmitStoreThroughLValue(RValue::get(Tmp), Dest);
+  }
+}
+
 void CodeGenFunction::EmitAsmStmt(const AsmStmt ) {
   // Pop all cleanup blocks at the end of the asm statement.
   CodeGenFunction::RunCleanupsScope Cleanups(*this);
@@ -2625,7 +2713,7 @@
   SmallVector Transfer;
   llvm::BasicBlock *Fallthrough = nullptr;
   bool IsGCCAsmGoto = false;
-  if (const auto *GS =  dyn_cast()) {
+  if (const auto *GS = dyn_cast()) {
 IsGCCAsmGoto = GS->isAsmGoto();
 if (IsGCCAsmGoto) {
   for (const auto *E : GS->labels()) {
@@ 

[PATCH] D136533: [clang] Fix missing diagnostic of declaration use when accessing TypeDecls through typename access

2022-10-31 Thread Mike Hommey via Phabricator via cfe-commits
glandium added a comment.

> you're using the SDK libc++ with a ToT clang, which is technically not a 
> supported combination.

Where is it specified that it's not a supported combination? Why should it not 
be supported? You don't even get libc++ from the llvm tree unless you 
explicitly enable it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136533

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


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

2022-10-31 Thread Zahira Ammarguellat via Phabricator via cfe-commits
zahiraam added a comment.

In D137107#3897326 , @rnk wrote:

> Unless I'm missing something, I think Clang's behavior here is preferable to 
> MSVC's. MSVC produces code which will not link. Clang turns the linker error 
> into a compiler error, which is generally easier for the user to understand. 
> To my knowledge, it is still true that there is no COFF relocation which can 
> statically initialize a global variable with the address of a dllimported 
> symbol.
>
> For the use case you are considering, how do things work out in practice? Is 
> there some new import patching facility that I'm not aware of? Is the 
> variable linked statically instead of dynamically, and then the linker 
> relaxes the __imp references to direct references?

I haven't used any import patch. I just used MSVC 2019 and the test compiles 
and links. Not sure how the variable is linked.
The symbols generated are:
009  UNDEF  notype   External | __imp_?next@@YAHH@Z 
(__declspec(dllimport) int __cdecl next(int))
012  UNDEF  notype   External | __imp_?val@@3HA 
(__declspec(dllimport) int val)
and this is the asm:
mainPROC
$LN3:

  sub rsp, 56 ; 0038H

; Line 5

  mov rax, QWORD PTR __imp_?val@@3HA
  mov QWORD PTR val_ref$[rsp], rax

; Line 6

  mov rax, QWORD PTR val_ref$[rsp]
  mov ecx, DWORD PTR [rax]
  callQWORD PTR __imp_?next@@YAHH@Z
  mov DWORD PTR i$[rsp], eax

; Line 8

  mov eax, DWORD PTR i$[rsp]

; Line 9

  add rsp, 56 ; 0038H
  ret 0

mainENDP


Repository:
  rG LLVM Github Monorepo

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] D136497: [Clang] support for outputs along indirect edges of asm goto

2022-10-31 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers added inline comments.



Comment at: clang/lib/CodeGen/CGStmt.cpp:2362
+  // a pointer.
+  if (TruncTy->isFloatingPointTy())
+Tmp = Builder.CreateFPTrunc(Tmp, TruncTy);

nickdesaulniers wrote:
> void wrote:
> > This looks like a direct copy from below (which is fine). I'm a bit iffy on 
> > whether this covers *all* of the value types that could come through here...
> Note: this code was simply moved wholesale.  If value types are missing, that 
> is a pre-existing bug and should be a prerequisite to fix for this patch.
> 
> I've broken out D137113 as a child patch to make that clearer.
s/should/shouldn't/


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136497

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


[PATCH] D137113: [Clang] refactor CodeGenFunction::EmitAsmStmt NFC

2022-10-31 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers planned changes to this revision.
nickdesaulniers added a comment.

Let me move the asserts, too.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137113

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


[PATCH] D136497: [Clang] support for outputs along indirect edges of asm goto

2022-10-31 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers planned changes to this revision.
nickdesaulniers added a comment.

In D136497#3889938 , @void wrote:

> It might be easier to see the main changes here if you submit the (very nice) 
> refactoring of `EmitAsmStores` first.

D137113  TODO(Nick): rebase on D137113 





Comment at: clang/lib/CodeGen/CGStmt.cpp:2358
+// the expression, do the conversion.
+if (ResultRegTypes[i] != ResultTruncRegTypes[i]) {
+

void wrote:
> s/ResultTruncRegTypes[i]/TruncTy/
Done in D137113



Comment at: clang/lib/CodeGen/CGStmt.cpp:2362
+  // a pointer.
+  if (TruncTy->isFloatingPointTy())
+Tmp = Builder.CreateFPTrunc(Tmp, TruncTy);

void wrote:
> This looks like a direct copy from below (which is fine). I'm a bit iffy on 
> whether this covers *all* of the value types that could come through here...
Note: this code was simply moved wholesale.  If value types are missing, that 
is a pre-existing bug and should be a prerequisite to fix for this patch.

I've broken out D137113 as a child patch to make that clearer.



Comment at: clang/lib/CodeGen/CGStmt.cpp:2850
 
   assert(RegResults.size() == ResultRegTypes.size());
   assert(RegResults.size() == ResultTruncRegTypes.size());

void wrote:
> Should these asserts (or some of them) be moved into `EmitAsmStores()`?
Ah, yeah, let me add those to D137113.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136497

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


[PATCH] D137113: [Clang] refactor CodeGenFunction::EmitAsmStmt NFC

2022-10-31 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers created this revision.
nickdesaulniers added reviewers: void, nikic, jyknight, efriedma, craig.topper.
Herald added a subscriber: StephenFan.
Herald added a project: All.
nickdesaulniers requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Prerequisite to further modifications in D136497 
.

Basically, there is a large body of code in CodeGenFunction::EmitAsmStmt
for emitting stores of outputs. We want to be able to repeat this logic,
for each destination of a callbr (rather than just the default
destination which is what the code currently does).

Also does some smaller cleanups like whitespace cleanups, and removing
pointless casts.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D137113

Files:
  clang/lib/CodeGen/CGStmt.cpp

Index: clang/lib/CodeGen/CGStmt.cpp
===
--- clang/lib/CodeGen/CGStmt.cpp
+++ clang/lib/CodeGen/CGStmt.cpp
@@ -24,6 +24,7 @@
 #include "clang/Basic/PrettyStackTrace.h"
 #include "clang/Basic/SourceManager.h"
 #include "clang/Basic/TargetInfo.h"
+#include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/SmallSet.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/IR/Assumptions.h"
@@ -2325,6 +2326,85 @@
   }
 }
 
+static void
+EmitAsmStores(CodeGenFunction , const AsmStmt ,
+  const llvm::ArrayRef RegResults,
+  const llvm::ArrayRef ResultRegTypes,
+  const llvm::ArrayRef ResultTruncRegTypes,
+  const llvm::ArrayRef ResultRegDests,
+  const llvm::ArrayRef ResultRegQualTys,
+  const llvm::BitVector ,
+  const llvm::BitVector ) {
+  CGBuilderTy  = CGF.Builder;
+  CodeGenModule  = CGF.CGM;
+  llvm::LLVMContext  = CGF.getLLVMContext();
+
+  for (unsigned i = 0, e = RegResults.size(); i != e; ++i) {
+llvm::Value *Tmp = RegResults[i];
+llvm::Type *TruncTy = ResultTruncRegTypes[i];
+
+if ((i < ResultRegIsFlagReg.size()) && ResultRegIsFlagReg[i]) {
+  // Target must guarantee the Value `Tmp` here is lowered to a boolean
+  // value.
+  llvm::Constant *Two = llvm::ConstantInt::get(Tmp->getType(), 2);
+  llvm::Value *IsBooleanValue =
+  Builder.CreateCmp(llvm::CmpInst::ICMP_ULT, Tmp, Two);
+  llvm::Function *FnAssume = CGM.getIntrinsic(llvm::Intrinsic::assume);
+  Builder.CreateCall(FnAssume, IsBooleanValue);
+}
+
+// If the result type of the LLVM IR asm doesn't match the result type of
+// the expression, do the conversion.
+if (ResultRegTypes[i] != TruncTy) {
+
+  // Truncate the integer result to the right size, note that TruncTy can be
+  // a pointer.
+  if (TruncTy->isFloatingPointTy())
+Tmp = Builder.CreateFPTrunc(Tmp, TruncTy);
+  else if (TruncTy->isPointerTy() && Tmp->getType()->isIntegerTy()) {
+uint64_t ResSize = CGM.getDataLayout().getTypeSizeInBits(TruncTy);
+Tmp = Builder.CreateTrunc(
+Tmp, llvm::IntegerType::get(CTX, (unsigned)ResSize));
+Tmp = Builder.CreateIntToPtr(Tmp, TruncTy);
+  } else if (Tmp->getType()->isPointerTy() && TruncTy->isIntegerTy()) {
+uint64_t TmpSize =
+CGM.getDataLayout().getTypeSizeInBits(Tmp->getType());
+Tmp = Builder.CreatePtrToInt(
+Tmp, llvm::IntegerType::get(CTX, (unsigned)TmpSize));
+Tmp = Builder.CreateTrunc(Tmp, TruncTy);
+  } else if (TruncTy->isIntegerTy()) {
+Tmp = Builder.CreateZExtOrTrunc(Tmp, TruncTy);
+  } else if (TruncTy->isVectorTy()) {
+Tmp = Builder.CreateBitCast(Tmp, TruncTy);
+  }
+}
+
+LValue Dest = ResultRegDests[i];
+// ResultTypeRequiresCast elements correspond to the first
+// ResultTypeRequiresCast.size() elements of RegResults.
+if ((i < ResultTypeRequiresCast.size()) && ResultTypeRequiresCast[i]) {
+  unsigned Size = CGF.getContext().getTypeSize(ResultRegQualTys[i]);
+  Address A =
+  Builder.CreateElementBitCast(Dest.getAddress(CGF), ResultRegTypes[i]);
+  if (CGF.getTargetHooks().isScalarizableAsmOperand(CGF, TruncTy)) {
+Builder.CreateStore(Tmp, A);
+continue;
+  }
+
+  QualType Ty =
+  CGF.getContext().getIntTypeForBitwidth(Size, /*Signed*/ false);
+  if (Ty.isNull()) {
+const Expr *OutExpr = S.getOutputExpr(i);
+CGM.getDiags().Report(OutExpr->getExprLoc(),
+  diag::err_store_value_to_reg);
+return;
+  }
+  Dest = CGF.MakeAddrLValue(A, Ty);
+}
+CGF.EmitStoreThroughLValue(RValue::get(Tmp), Dest);
+  }
+}
+
 void CodeGenFunction::EmitAsmStmt(const AsmStmt ) {
   // Pop all cleanup blocks at the end of the asm statement.
   CodeGenFunction::RunCleanupsScope Cleanups(*this);
@@ -2625,7 +2705,7 @@
   SmallVector Transfer;
   llvm::BasicBlock *Fallthrough = nullptr;
   bool IsGCCAsmGoto = false;
-  if (const auto *GS =  

[PATCH] D134089: [clang] Mention vector in the description for -mno-implict-float.

2022-10-31 Thread Eli Friedman via Phabricator via cfe-commits
efriedma accepted this revision.
efriedma added a comment.
This revision is now accepted and ready to land.

LGTM

We might want per-target documentation somewhere for what counts as an 
"floating point or vector instruction".  It's not entirely obvious whether, for 
example, `cvtss2si (%rax), %ecx` is a floating-point instruction.  But I don't 
think we can get much more clear in a one or two line description.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134089

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


[clang] 1391843 - [Hexagon] Add builtins and intrinsics for V6_v[add|sub]carryo

2022-10-31 Thread Krzysztof Parzyszek via cfe-commits

Author: Krzysztof Parzyszek
Date: 2022-10-31T13:41:31-07:00
New Revision: 13918432cf67c60d56b7a89bf9b1acf9c0d0866a

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

LOG: [Hexagon] Add builtins and intrinsics for V6_v[add|sub]carryo

Added: 


Modified: 
clang/include/clang/Basic/BuiltinsHexagonDep.def
clang/include/clang/Basic/BuiltinsHexagonMapCustomDep.def
clang/lib/CodeGen/CGBuiltin.cpp
clang/test/CodeGen/builtins-hexagon-v66-128B.c
clang/test/CodeGen/builtins-hexagon-v66.c
llvm/include/llvm/IR/IntrinsicsHexagonDep.td
llvm/lib/Target/Hexagon/HexagonDepInstrIntrinsics.inc
llvm/lib/Target/Hexagon/HexagonDepMapAsm2Intrin.td

Removed: 




diff  --git a/clang/include/clang/Basic/BuiltinsHexagonDep.def 
b/clang/include/clang/Basic/BuiltinsHexagonDep.def
index 2eb4ca69c7bde..f08fa2f75cb9b 100644
--- a/clang/include/clang/Basic/BuiltinsHexagonDep.def
+++ b/clang/include/clang/Basic/BuiltinsHexagonDep.def
@@ -1720,6 +1720,8 @@ TARGET_BUILTIN(__builtin_HEXAGON_V6_vscattermwq_128B, 
"vV128biiV32iV32i", "", HV
 
 // V66 HVX Instructions.
 
+TARGET_BUILTIN(__builtin_HEXAGON_V6_vaddcarryo, "V16iV16iV16iv*", "", HVXV66)
+TARGET_BUILTIN(__builtin_HEXAGON_V6_vaddcarryo_128B, "V32iV32iV32iv*", "", 
HVXV66)
 TARGET_BUILTIN(__builtin_HEXAGON_V6_vaddcarrysat, "V16iV16iV16iV64b", "", 
HVXV66)
 TARGET_BUILTIN(__builtin_HEXAGON_V6_vaddcarrysat_128B, "V32iV32iV32iV128b", 
"", HVXV66)
 TARGET_BUILTIN(__builtin_HEXAGON_V6_vasr_into, "V32iV32iV16iV16i", "", HVXV66)
@@ -1728,6 +1730,8 @@ TARGET_BUILTIN(__builtin_HEXAGON_V6_vrotr, 
"V16iV16iV16i", "", HVXV66)
 TARGET_BUILTIN(__builtin_HEXAGON_V6_vrotr_128B, "V32iV32iV32i", "", HVXV66)
 TARGET_BUILTIN(__builtin_HEXAGON_V6_vsatdw, "V16iV16iV16i", "", HVXV66)
 TARGET_BUILTIN(__builtin_HEXAGON_V6_vsatdw_128B, "V32iV32iV32i", "", HVXV66)
+TARGET_BUILTIN(__builtin_HEXAGON_V6_vsubcarryo, "V16iV16iV16iv*", "", HVXV66)
+TARGET_BUILTIN(__builtin_HEXAGON_V6_vsubcarryo_128B, "V32iV32iV32iv*", "", 
HVXV66)
 
 // V68 HVX Instructions.
 

diff  --git a/clang/include/clang/Basic/BuiltinsHexagonMapCustomDep.def 
b/clang/include/clang/Basic/BuiltinsHexagonMapCustomDep.def
index 389eadb21d01c..9390d54e08477 100644
--- a/clang/include/clang/Basic/BuiltinsHexagonMapCustomDep.def
+++ b/clang/include/clang/Basic/BuiltinsHexagonMapCustomDep.def
@@ -12,3 +12,7 @@ CUSTOM_BUILTIN_MAPPING(V6_vaddcarry, 64)
 CUSTOM_BUILTIN_MAPPING(V6_vaddcarry_128B, 128)
 CUSTOM_BUILTIN_MAPPING(V6_vsubcarry, 64)
 CUSTOM_BUILTIN_MAPPING(V6_vsubcarry_128B, 128)
+CUSTOM_BUILTIN_MAPPING(V6_vaddcarryo, 64)
+CUSTOM_BUILTIN_MAPPING(V6_vaddcarryo_128B, 128)
+CUSTOM_BUILTIN_MAPPING(V6_vsubcarryo, 64)
+CUSTOM_BUILTIN_MAPPING(V6_vsubcarryo_128B, 128)

diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index 0ca664bfed9e9..8bb5626392bd3 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -19303,6 +19303,25 @@ Value 
*CodeGenFunction::EmitHexagonBuiltinExpr(unsigned BuiltinID,
 PredAddr.getAlignment());
 return Builder.CreateExtractValue(Result, 0);
   }
+  // These are identical to the builtins above, except they don't consume
+  // input carry, only generate carry-out. Since they still produce two
+  // outputs, generate the store of the predicate, but no load.
+  case Hexagon::BI__builtin_HEXAGON_V6_vaddcarryo:
+  case Hexagon::BI__builtin_HEXAGON_V6_vaddcarryo_128B:
+  case Hexagon::BI__builtin_HEXAGON_V6_vsubcarryo:
+  case Hexagon::BI__builtin_HEXAGON_V6_vsubcarryo_128B: {
+// Get the type from the 0-th argument.
+llvm::Type *VecType = ConvertType(E->getArg(0)->getType());
+Address PredAddr = Builder.CreateElementBitCast(
+EmitPointerWithAlignment(E->getArg(2)), VecType);
+llvm::Value *Result = Builder.CreateCall(CGM.getIntrinsic(ID),
+{EmitScalarExpr(E->getArg(0)), EmitScalarExpr(E->getArg(1))});
+
+llvm::Value *PredOut = Builder.CreateExtractValue(Result, 1);
+Builder.CreateAlignedStore(Q2V(PredOut), PredAddr.getPointer(),
+PredAddr.getAlignment());
+return Builder.CreateExtractValue(Result, 0);
+  }
 
   case Hexagon::BI__builtin_HEXAGON_V6_vmaskedstoreq:
   case Hexagon::BI__builtin_HEXAGON_V6_vmaskedstorenq:

diff  --git a/clang/test/CodeGen/builtins-hexagon-v66-128B.c 
b/clang/test/CodeGen/builtins-hexagon-v66-128B.c
index 5839d3ae975ec..62beeb5c871f6 100644
--- a/clang/test/CodeGen/builtins-hexagon-v66-128B.c
+++ b/clang/test/CodeGen/builtins-hexagon-v66-128B.c
@@ -65,3 +65,35 @@ HEXAGON_Vect2048 test28(void *in1, void *in2, void *out) {
 
   return __builtin_HEXAGON_V6_vasr_into_128B(vr, v1, v2);
 }
+
+// CHECK-LABEL: @test29
+// CHECK: call { <32 x i32>, <128 x i1> } @llvm.hexagon.V6.vaddcarryo.128B(<32 
x i32> %{{[0-9]+}}, <32 x i32> 

[clang] 6288f70 - [lit] Fix typo in REQUIRES clause

2022-10-31 Thread Paul Robinson via cfe-commits

Author: Paul Robinson
Date: 2022-10-31T13:15:09-07:00
New Revision: 6288f70bda7438c7d249a4d54d8317172bce2b88

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

LOG: [lit] Fix typo in REQUIRES clause

Added: 


Modified: 

clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-load-store-reversed-64bit-only.c

Removed: 




diff  --git 
a/clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-load-store-reversed-64bit-only.c
 
b/clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-load-store-reversed-64bit-only.c
index ba97bfa199103..8053516f60175 100644
--- 
a/clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-load-store-reversed-64bit-only.c
+++ 
b/clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-load-store-reversed-64bit-only.c
@@ -1,4 +1,4 @@
-// REQUIRES: powerpc-registered-target.
+// REQUIRES: powerpc-registered-target
 // RUN: %clang_cc1 -triple powerpc64-unknown-linux-gnu \
 // RUN:   -emit-llvm %s -o - -target-cpu pwr7 | FileCheck %s
 // RUN: %clang_cc1 -triple powerpc64le-unknown-linux-gnu \



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


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

2022-10-31 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added a subscriber: akhuang.
rnk added a comment.

@akhuang, can you help out with this? The address of dllimport symbols not 
being constexpr is a big pain point for our users too, and I'd love to fix it:
https://github.com/protocolbuffers/protobuf/issues/10159

I am ready to be wrong here: if things have changed and my info is stale, we 
should definitely adapt.


Repository:
  rG LLVM Github Monorepo

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] D133998: [HIP][test] Avoid %T

2022-10-31 Thread Paul Robinson via Phabricator via cfe-commits
probinson added a comment.

I filed #58711  to get the 
test fixed; in the meantime, removed `clang-driver` and added `XFAIL: *` in 
rG7af01fe4 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133998

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


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

2022-10-31 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added a comment.

Unless I'm missing something, I think Clang's behavior here is preferable to 
MSVC's. MSVC produces code which will not link. Clang turns the linker error 
into a compiler error, which is generally easier for the user to understand. To 
my knowledge, it is still true that there is no COFF relocation which can 
statically initialize a global variable with the address of a dllimported 
symbol.

For the use case you are considering, how do things work out in practice? Is 
there some new import patching facility that I'm not aware of? Is the variable 
linked statically instead of dynamically, and then the linker relaxes the __imp 
references to direct references?


Repository:
  rG LLVM Github Monorepo

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] D136807: [clang][Sema] Fix a clang crash with btf_type_tag

2022-10-31 Thread Yonghong Song via Phabricator via cfe-commits
yonghong-song added a comment.

@aaron.ballman or @dblaikie I have addressed the comments, could you take a 
look again?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136807

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


[clang] 7af01fe - [lit] Remove undefined keyword from a Driver test

2022-10-31 Thread Paul Robinson via cfe-commits

Author: Paul Robinson
Date: 2022-10-31T13:01:05-07:00
New Revision: 7af01fe42f1634297601016cd4ef84c34cd84bca

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

LOG: [lit] Remove undefined keyword from a Driver test

`clang-driver` hasn't been a valid keyword for a long time.
The test fails when the keyword is removed, so added XFAIL: *
to reflect the true status of the test (XFAIL not UNSUPPORTED)
and filed issue #58711 to get it fixed.

Added: 


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

Removed: 




diff  --git a/clang/test/Driver/hip-link-bc-to-bc.hip 
b/clang/test/Driver/hip-link-bc-to-bc.hip
index df858cf158522..972822b5260c2 100644
--- a/clang/test/Driver/hip-link-bc-to-bc.hip
+++ b/clang/test/Driver/hip-link-bc-to-bc.hip
@@ -1,4 +1,6 @@
-// REQUIRES: clang-driver, x86-registered-target, amdgpu-registered-target
+// REQUIRES: x86-registered-target, amdgpu-registered-target
+// See issue #58711
+// XFAIL: *
 
 // Check that clang unbundles the two bitcodes and links via llvm-link
 // RUN: rm -rf %t && mkdir %t



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


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

2022-10-31 Thread Zahira Ammarguellat via Phabricator via cfe-commits
zahiraam created this revision.
zahiraam added reviewers: majnemer, rnk.
Herald added a project: All.
zahiraam requested review of this revision.
Herald added a project: clang.

Microsoft allows the support of ‘constexpr’ with ‘__declspec(dllimport) starting
from VS2017 15.u update 4. See Constexpr doesn't support __declspec(dllimport)
in VS2017 15.8 - Visual Studio Feedback.

Let’s consider this example.
lib.cpp: 
__declspec(dllexport) int val=12;
__declspec(dllexport)
int next(int n)
{

  return n + 1;

}

app1.cpp: 
#include 
extern int __declspec(dllimport) next(int n);
int main () {

  extern int __declspec(dllimport) val;
  constexpr int& val_ref = val;
  int i = next(val_ref);
  std::cout << "i: " << i << std::endl;
  return i;

}

Compiling this will give the expected output. 
 $ cl /LD lib.cpp
 $ cl /EHsc app1.cpp /link lib.lib
 $ ./app1.exe
 i: 13

The Intel compiler has the same behavior than MSVC.
Clang compiles this test case with this error:
error: constexpr variable 'val_ref' must be initialized by a constant

  expression
  constexpr int& val_ref = val;
 ^ ~~~

1 error generated.

I think this should be fixed. This patch is doing that.

Now let’s look now at this example (dllimport at TU scope level):
app2.cpp: 
#include 
extern int __declspec(dllimport) next(int n);
extern int __declspec(dllimport) val;
constexpr int& val_ref = val;

int main () {

  int i = next(val_ref);
  std::cout << "i: " << i << std::endl;
  return i;

}
Compiling this will result into an unresolved symbol: 
 $ cl /EHsc app2.cpp /link lib.lib
 app2.obj : error LNK2001: unresolved external symbol "int val" (?val@@3HA)
 app2.exe : fatal error LNK1120: 1 unresolved externals

ICL and clang generate the same error.

These are the symols generated for all 3 compilers:
ICL:
003  UNDEF  notype   External | __imp_?next@@YAHH@Z 
(__declspec(dllimport) int __cdecl next(int))
004  UNDEF  notype   External | __imp_?val@@3HA 
(__declspec(dllimport) int val)
00C  SECT4  notype   External | ?val_ref@@3AEAHEA (int & 
val_ref)
00D  UNDEF  notype   External | ?val@@3HA (int val)
MSVC:
00A  UNDEF  notype   External | __imp_?next@@YAHH@Z 
(__declspec(dllimport) int __cdecl next(int))
015  SECT6  notype   Static   | ?val_ref@@3AEAHEA (int & 
val_ref)

The symbols generated by ICL seem to be what's expected. MSVC should be 
generating an "__imp_?val" symbol.

Clang with the change in this patch is generating the expected symbols:
010  UNDEF  notype   External | __imp_?val@@3HA 
(__declspec(dllimport) int val)
011  UNDEF  notype   External | __imp_?next@@YAHH@Z 
(__declspec(dllimport) int __cdecl next(int))
012  SECT5  notype   External | ?val_ref@@3AEAHEA (int & 
val_ref)
013  UNDEF  notype   External | ?val@@3HA (int val)

Fixes issue https://github.com/llvm/llvm-project/issues/53182


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D137107

Files:
  clang/lib/AST/ExprConstant.cpp
  clang/test/CodeGenCXX/PR19955.cpp
  clang/test/CodeGenCXX/dllimport.cpp
  clang/test/SemaCXX/PR19955.cpp
  clang/test/SemaCXX/dllimport-constexpr.cpp


Index: clang/test/SemaCXX/dllimport-constexpr.cpp
===
--- clang/test/SemaCXX/dllimport-constexpr.cpp
+++ clang/test/SemaCXX/dllimport-constexpr.cpp
@@ -40,7 +40,6 @@
 // constexpr initialization doesn't work for dllimport things.
 // expected-error@+1{{must be initialized by a constant expression}}
 constexpr void (*constexpr_import_func)() = _func;
-// expected-error@+1{{must be initialized by a constant expression}}
 constexpr int *constexpr_import_int = _int;
 // expected-error@+1{{must be initialized by a constant expression}}
 constexpr void (Foo::*constexpr_memptr)() = ::imported_method;
Index: clang/test/SemaCXX/PR19955.cpp
===
--- clang/test/SemaCXX/PR19955.cpp
+++ clang/test/SemaCXX/PR19955.cpp
@@ -2,7 +2,7 @@
 // RUN: %clang_cc1 -triple i686-mingw32 -verify -std=c++11 %s
 
 extern int __attribute__((dllimport)) var;
-constexpr int *varp =  // expected-error {{must be initialized by a 
constant expression}}
+constexpr int *varp = 
 
 extern __attribute__((dllimport)) void fun();
 constexpr void (*funp)(void) =  // expected-error {{must be initialized 
by a constant expression}}
Index: clang/test/CodeGenCXX/dllimport.cpp
===
--- clang/test/CodeGenCXX/dllimport.cpp
+++ clang/test/CodeGenCXX/dllimport.cpp
@@ -97,9 +97,9 @@
 };
 USE(inlineStaticLocalsFunc);
 
-// The address of a dllimport global cannot be used in constant initialization.
-// M32-DAG: @"?arr@?1??initializationFunc@@YAPAHXZ@4QBQAHB" = internal global 
[1 x ptr] zeroinitializer
-// GNU-DAG: @_ZZ18initializationFuncvE3arr = internal global [1 x ptr] 

[PATCH] D136554: Implement CWG2631

2022-10-31 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin updated this revision to Diff 472108.
cor3ntin added a comment.

Move more getExpr methods in the header.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136554

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/AST/ExprCXX.h
  clang/include/clang/AST/Stmt.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/ExprCXX.cpp
  clang/lib/Parse/ParseCXXInlineMethods.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReaderStmt.cpp
  clang/lib/Serialization/ASTWriterStmt.cpp
  clang/test/CXX/class/class.local/p1-0x.cpp
  clang/test/CodeGenCXX/default-arguments-with-immediate.cpp
  clang/test/PCH/default-argument-with-immediate-calls.cpp
  clang/test/SemaCXX/cxx2a-consteval-default-params.cpp
  clang/test/SemaCXX/source_location.cpp

Index: clang/test/SemaCXX/source_location.cpp
===
--- clang/test/SemaCXX/source_location.cpp
+++ clang/test/SemaCXX/source_location.cpp
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -std=c++1z -fcxx-exceptions -fexceptions -verify %s
+// RUN: %clang_cc1 -std=c++2a -fcxx-exceptions -DUSE_CONSTEVAL -fexceptions -verify %s
 // expected-no-diagnostics
 
 #define assert(...) ((__VA_ARGS__) ? ((void)0) : throw 42)
@@ -8,15 +9,22 @@
 template 
 struct Printer;
 
+#ifdef USE_CONSTEVAL
+#define SOURCE_LOC_EVAL_KIND consteval
+#else
+#define SOURCE_LOC_EVAL_KIND constexpr
+#endif
+
 namespace std {
 class source_location {
   struct __impl;
 
 public:
-  static constexpr source_location current(const __impl *__p = __builtin_source_location()) noexcept {
-source_location __loc;
-__loc.__m_impl = __p;
-return __loc;
+  static SOURCE_LOC_EVAL_KIND source_location
+current(const __impl *__p = __builtin_source_location()) noexcept {
+  source_location __loc;
+  __loc.__m_impl = __p;
+  return __loc;
   }
   constexpr source_location() = default;
   constexpr source_location(source_location const &) = default;
@@ -593,3 +601,22 @@
   }
   static_assert(test());
 }
+
+namespace Lambda {
+#line 8000 "TestLambda.cpp"
+constexpr int nested_lambda(int l = []{
+  return SL::current().line();
+}()) {
+  return l;
+}
+static_assert(nested_lambda() == __LINE__ - 4);
+
+constexpr int lambda_param(int l = [](int l = SL::current().line()) {
+  return l;
+}()) {
+  return l;
+}
+static_assert(lambda_param() == __LINE__);
+
+
+}
Index: clang/test/SemaCXX/cxx2a-consteval-default-params.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/cxx2a-consteval-default-params.cpp
@@ -0,0 +1,65 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++20 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++2b %s
+
+consteval int undefined();  // expected-note 4 {{declared here}}
+
+void check_lambdas_unused(
+int a = []
+{
+return undefined();  // expected-error {{not a constant expression}} \
+ // expected-note  {{undefined function 'undefined'}}
+}(),
+int b = [](int no_error = undefined()) {
+return no_error;
+}(0),
+int c = [](int defaulted = undefined()) {
+return defaulted;
+}()
+) {}
+
+int check_lambdas_used(
+int b = [](int no_error = undefined()) {
+return no_error;
+}(0),
+int c = [](int defaulted = undefined()) { // expected-error {{not a constant expression}} \
+  // expected-note  {{declared here}} \
+  // expected-note  {{undefined function 'undefined'}}
+return defaulted;
+}(),  // expected-note {{in the default initalizer of 'defaulted'}}
+int d = [](int defaulted = sizeof(undefined())) {
+return defaulted;
+}()
+) {
+return 0;
+}
+
+int test_check_lambdas_used = check_lambdas_used();
+
+struct UnusedInitWithLambda {
+int a = [] {
+return undefined();  // expected-error {{not a constant expression}} \
+ // expected-note  {{undefined function 'undefined'}}
+}();
+// UnusedInitWithLambda is never constructed, so the initializer
+// of b and undefined() are never evaluated.
+int b = [](int no_error = undefined()) {
+return no_error;
+}();
+};
+
+consteval int ub(int n) {
+return 0/n; // expected-note  {{division}}
+}
+
+struct InitWithLambda {
+int b = [](int error = undefined()) { // expected-error {{not a constant expression}} \
+  // expected-note  {{declared here}} \
+  // expected-note  {{undefined function 'undefined'}}
+return error;
+}(); // expected-note {{in the default initalizer of 'error'}}
+int c = 

[PATCH] D137104: [clangd] Add scoped enum constants to all-scopes-completion

2022-10-31 Thread Tom Praschan via Phabricator via cfe-commits
tom-anders updated this revision to Diff 472103.
tom-anders added a comment.

Added missing hunk in CodeComplete.cpp


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137104

Files:
  clang-tools-extra/clangd/CodeComplete.cpp
  clang-tools-extra/clangd/CodeComplete.h
  clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp


Index: clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
===
--- clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
+++ clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
@@ -1329,7 +1329,7 @@
   AllOf(qName("Color"), forCodeCompletion(true)),
   AllOf(qName("Green"), forCodeCompletion(true)),
   AllOf(qName("Color2"), forCodeCompletion(true)),
-  AllOf(qName("Color2::Yellow"), forCodeCompletion(false)),
+  AllOf(qName("Color2::Yellow"), forCodeCompletion(true)),
   AllOf(qName("Color3"), forCodeCompletion(true)),
   AllOf(qName("Color3::Blue"), forCodeCompletion(true)),
   AllOf(qName("ns"), forCodeCompletion(true)),
Index: clang-tools-extra/clangd/CodeComplete.h
===
--- clang-tools-extra/clangd/CodeComplete.h
+++ clang-tools-extra/clangd/CodeComplete.h
@@ -291,7 +291,7 @@
 // For index-based completion, we only consider:
 //   * symbols in namespaces or translation unit scopes (e.g. no class
 // members, no locals)
-//   * enum constants in unscoped enum decl (e.g. "red" in "enum {red};")
+//   * enum constants (both scoped and unscoped)
 //   * primary templates (no specializations)
 // For the other cases, we let Clang do the completion because it does not
 // need any non-local information and it will be much better at following
Index: clang-tools-extra/clangd/CodeComplete.cpp
===
--- clang-tools-extra/clangd/CodeComplete.cpp
+++ clang-tools-extra/clangd/CodeComplete.cpp
@@ -2114,9 +2114,6 @@
 };
 return false;
   };
-  auto InClassScope = [](const NamedDecl ) {
-return ND.getDeclContext()->getDeclKind() == Decl::CXXRecord;
-  };
   // We only complete symbol's name, which is the same as the name of the
   // *primary* template in case of template specializations.
   if (isExplicitTemplateSpecialization())
@@ -2135,8 +2132,8 @@
   // Always index enum constants, even if they're not in the top level scope:
   // when
   // --all-scopes-completion is set, we'll want to complete those as well.
-  if (const auto *EnumDecl = dyn_cast(ND.getDeclContext()))
-return (InTopLevelScope(*EnumDecl) || InClassScope(*EnumDecl)) && 
!EnumDecl->isScoped();
+  if (llvm::isa(ND.getDeclContext()))
+return true;
 
   return false;
 }


Index: clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
===
--- clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
+++ clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
@@ -1329,7 +1329,7 @@
   AllOf(qName("Color"), forCodeCompletion(true)),
   AllOf(qName("Green"), forCodeCompletion(true)),
   AllOf(qName("Color2"), forCodeCompletion(true)),
-  AllOf(qName("Color2::Yellow"), forCodeCompletion(false)),
+  AllOf(qName("Color2::Yellow"), forCodeCompletion(true)),
   AllOf(qName("Color3"), forCodeCompletion(true)),
   AllOf(qName("Color3::Blue"), forCodeCompletion(true)),
   AllOf(qName("ns"), forCodeCompletion(true)),
Index: clang-tools-extra/clangd/CodeComplete.h
===
--- clang-tools-extra/clangd/CodeComplete.h
+++ clang-tools-extra/clangd/CodeComplete.h
@@ -291,7 +291,7 @@
 // For index-based completion, we only consider:
 //   * symbols in namespaces or translation unit scopes (e.g. no class
 // members, no locals)
-//   * enum constants in unscoped enum decl (e.g. "red" in "enum {red};")
+//   * enum constants (both scoped and unscoped)
 //   * primary templates (no specializations)
 // For the other cases, we let Clang do the completion because it does not
 // need any non-local information and it will be much better at following
Index: clang-tools-extra/clangd/CodeComplete.cpp
===
--- clang-tools-extra/clangd/CodeComplete.cpp
+++ clang-tools-extra/clangd/CodeComplete.cpp
@@ -2114,9 +2114,6 @@
 };
 return false;
   };
-  auto InClassScope = [](const NamedDecl ) {
-return ND.getDeclContext()->getDeclKind() == Decl::CXXRecord;
-  };
   // We only complete symbol's name, which is the same as the name of the
   // *primary* template in case of template 

[PATCH] D137104: [clangd] Add scoped enum constants to all-scopes-completion

2022-10-31 Thread Tom Praschan via Phabricator via cfe-commits
tom-anders created this revision.
tom-anders added a reviewer: nridge.
Herald added subscribers: kadircet, arphaman.
Herald added a project: All.
tom-anders requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang-tools-extra.

This was originally part of https://reviews.llvm.org/D136925, but we decided to 
move it to a separate patch.
In case it turns out to be controversial, it can be reverted more easily.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D137104

Files:
  clang-tools-extra/clangd/CodeComplete.h
  clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp


Index: clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
===
--- clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
+++ clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
@@ -1329,7 +1329,7 @@
   AllOf(qName("Color"), forCodeCompletion(true)),
   AllOf(qName("Green"), forCodeCompletion(true)),
   AllOf(qName("Color2"), forCodeCompletion(true)),
-  AllOf(qName("Color2::Yellow"), forCodeCompletion(false)),
+  AllOf(qName("Color2::Yellow"), forCodeCompletion(true)),
   AllOf(qName("Color3"), forCodeCompletion(true)),
   AllOf(qName("Color3::Blue"), forCodeCompletion(true)),
   AllOf(qName("ns"), forCodeCompletion(true)),
Index: clang-tools-extra/clangd/CodeComplete.h
===
--- clang-tools-extra/clangd/CodeComplete.h
+++ clang-tools-extra/clangd/CodeComplete.h
@@ -291,7 +291,7 @@
 // For index-based completion, we only consider:
 //   * symbols in namespaces or translation unit scopes (e.g. no class
 // members, no locals)
-//   * enum constants in unscoped enum decl (e.g. "red" in "enum {red};")
+//   * enum constants (both scoped and unscoped)
 //   * primary templates (no specializations)
 // For the other cases, we let Clang do the completion because it does not
 // need any non-local information and it will be much better at following


Index: clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
===
--- clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
+++ clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
@@ -1329,7 +1329,7 @@
   AllOf(qName("Color"), forCodeCompletion(true)),
   AllOf(qName("Green"), forCodeCompletion(true)),
   AllOf(qName("Color2"), forCodeCompletion(true)),
-  AllOf(qName("Color2::Yellow"), forCodeCompletion(false)),
+  AllOf(qName("Color2::Yellow"), forCodeCompletion(true)),
   AllOf(qName("Color3"), forCodeCompletion(true)),
   AllOf(qName("Color3::Blue"), forCodeCompletion(true)),
   AllOf(qName("ns"), forCodeCompletion(true)),
Index: clang-tools-extra/clangd/CodeComplete.h
===
--- clang-tools-extra/clangd/CodeComplete.h
+++ clang-tools-extra/clangd/CodeComplete.h
@@ -291,7 +291,7 @@
 // For index-based completion, we only consider:
 //   * symbols in namespaces or translation unit scopes (e.g. no class
 // members, no locals)
-//   * enum constants in unscoped enum decl (e.g. "red" in "enum {red};")
+//   * enum constants (both scoped and unscoped)
 //   * primary templates (no specializations)
 // For the other cases, we let Clang do the completion because it does not
 // need any non-local information and it will be much better at following
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D136925: [clangd] Index scoped enums for code completion

2022-10-31 Thread Tom Praschan via Phabricator via cfe-commits
tom-anders updated this revision to Diff 472101.
tom-anders marked 3 inline comments as done.
tom-anders added a comment.
Herald added a subscriber: wenlei.

Add test to CodeCompletionTests, only consider unscoped enums in this patch 
(move scoped enums to separate patch)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136925

Files:
  clang-tools-extra/clangd/CodeComplete.cpp
  clang-tools-extra/clangd/index/Serialization.cpp
  clang-tools-extra/clangd/test/index-serialization/Inputs/sample.idx
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
  clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
  clang-tools-extra/clangd/unittests/TestIndex.cpp
  clang-tools-extra/clangd/unittests/TestIndex.h

Index: clang-tools-extra/clangd/unittests/TestIndex.h
===
--- clang-tools-extra/clangd/unittests/TestIndex.h
+++ clang-tools-extra/clangd/unittests/TestIndex.h
@@ -27,6 +27,8 @@
 Symbol cls(llvm::StringRef Name);
 // Creates an enum symbol.
 Symbol enm(llvm::StringRef Name);
+// Creates an enum constant symbol.
+Symbol enmConstant(llvm::StringRef Name);
 // Creates a variable symbol.
 Symbol var(llvm::StringRef Name);
 // Creates a namespace symbol.
Index: clang-tools-extra/clangd/unittests/TestIndex.cpp
===
--- clang-tools-extra/clangd/unittests/TestIndex.cpp
+++ clang-tools-extra/clangd/unittests/TestIndex.cpp
@@ -69,6 +69,10 @@
   return sym(Name, index::SymbolKind::Enum, "@E@\\0");
 }
 
+Symbol enmConstant(llvm::StringRef Name) {
+  return sym(Name, index::SymbolKind::EnumConstant, "@\\0");
+}
+
 Symbol var(llvm::StringRef Name) {
   return sym(Name, index::SymbolKind::Variable, "@\\0");
 }
Index: clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
===
--- clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
+++ clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
@@ -1316,6 +1316,11 @@
   Black
 };
 }
+class Color3 {
+  enum {
+Blue
+  };
+};
   )";
   runSymbolCollector(Header, /*Main=*/"");
   EXPECT_THAT(Symbols,
@@ -1325,6 +1330,8 @@
   AllOf(qName("Green"), forCodeCompletion(true)),
   AllOf(qName("Color2"), forCodeCompletion(true)),
   AllOf(qName("Color2::Yellow"), forCodeCompletion(false)),
+  AllOf(qName("Color3"), forCodeCompletion(true)),
+  AllOf(qName("Color3::Blue"), forCodeCompletion(true)),
   AllOf(qName("ns"), forCodeCompletion(true)),
   AllOf(qName("ns::Black"), forCodeCompletion(true;
 }
Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -1,4 +1,5 @@
-//===-- CodeCompleteTests.cpp ---*- C++ -*-===//
+//===-- CodeCompleteTests.cpp ---*- C++
+//-*-===//codecom
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
@@ -2962,14 +2963,20 @@
 }
   )cpp",
   {cls("nx::Clangd1"), cls("ny::Clangd2"), cls("Clangd3"),
-   cls("na::nb::Clangd4")},
+   cls("na::nb::Clangd4"), enmConstant("na::C::Clangd5")},
   Opts);
   EXPECT_THAT(
   Results.Completions,
-  UnorderedElementsAre(AllOf(qualifier("nx::"), named("Clangd1")),
-   AllOf(qualifier("ny::"), named("Clangd2")),
-   AllOf(qualifier(""), scope(""), named("Clangd3")),
-   AllOf(qualifier("nb::"), named("Clangd4";
+  UnorderedElementsAre(AllOf(qualifier("nx::"), named("Clangd1"),
+ kind(CompletionItemKind::Class)),
+   AllOf(qualifier("ny::"), named("Clangd2"),
+ kind(CompletionItemKind::Class)),
+   AllOf(qualifier(""), scope(""), named("Clangd3"),
+ kind(CompletionItemKind::Class)),
+   AllOf(qualifier("nb::"), named("Clangd4"),
+ kind(CompletionItemKind::Class)),
+   AllOf(qualifier("C::"), named("Clangd5"),
+ kind(CompletionItemKind::EnumMember;
 }
 
 TEST(CompletionTest, NoQualifierIfShadowed) {
Index: clang-tools-extra/clangd/index/Serialization.cpp
===
--- clang-tools-extra/clangd/index/Serialization.cpp
+++ clang-tools-extra/clangd/index/Serialization.cpp
@@ -455,7 +455,7 @@
 // The current 

[PATCH] D136872: [OpenMP][OpenMPIRBuilder] Migrate loadOffloadInfoMetadata from clang to OMPIRbuilder

2022-10-31 Thread Akash Banerjee via Phabricator via cfe-commits
TIFitis marked 2 inline comments as done.
TIFitis added inline comments.



Comment at: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:4712
+Module , OffloadEntriesInfoManager ,
+bool isDevice) {
+  // If we are in target mode, load the metadata from the host IR. This code 
has

jsjodin wrote:
> isDevice must be true (add assertion at the call site) remove the parameter, 
> and the assertions in this function. Document that this function is only 
> intended to be used with device code generation.
I've removed isDevice as a parameter. At the call site, isDevice is checked 
inside an if condition and it returns on false, thus I haven't added the 
assertion back at the call site.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136872

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


[PATCH] D136872: [OpenMP][OpenMPIRBuilder] Migrate loadOffloadInfoMetadata from clang to OMPIRbuilder

2022-10-31 Thread Akash Banerjee via Phabricator via cfe-commits
TIFitis updated this revision to Diff 472094.
TIFitis added a comment.

Removed isDevice from parameters. Added documentation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136872

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
  llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp

Index: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
===
--- llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
+++ llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
@@ -4705,6 +4705,55 @@
   getTargetRegionEntryFnName(Name, ParentName, DeviceID, FileID, Line);
 }
 
+/// Loads all the offload entries information from the host IR
+/// metadata. This function is only meant to be used with device code
+/// generation.
+void OpenMPIRBuilder::loadOffloadInfoMetadata(
+Module , OffloadEntriesInfoManager ) {
+  // If we are in target mode, load the metadata from the host IR. This code has
+  // to match the metadata creation in createOffloadEntriesAndInfoMetadata().
+
+  NamedMDNode *MD = M.getNamedMetadata(ompOffloadInfoName);
+  if (!MD)
+return;
+
+  for (MDNode *MN : MD->operands()) {
+auto & = [MN](unsigned Idx) {
+  auto *V = cast(MN->getOperand(Idx));
+  return cast(V->getValue())->getZExtValue();
+};
+
+auto & = [MN](unsigned Idx) {
+  auto *V = cast(MN->getOperand(Idx));
+  return V->getString();
+};
+
+switch (GetMDInt(0)) {
+default:
+  llvm_unreachable("Unexpected metadata!");
+  break;
+case OffloadEntriesInfoManager::OffloadEntryInfo::
+OffloadingEntryInfoTargetRegion: {
+  TargetRegionEntryInfo EntryInfo(/*ParentName=*/GetMDString(3),
+  /*DeviceID=*/GetMDInt(1),
+  /*FileID=*/GetMDInt(2),
+  /*Line=*/GetMDInt(4));
+  OffloadEntriesInfoManager.initializeTargetRegionEntryInfo(
+  EntryInfo, /*Order=*/GetMDInt(5));
+  break;
+}
+case OffloadEntriesInfoManager::OffloadEntryInfo::
+OffloadingEntryInfoDeviceGlobalVar:
+  OffloadEntriesInfoManager.initializeDeviceGlobalVarEntryInfo(
+  /*MangledName=*/GetMDString(1),
+  static_cast(
+  /*Flags=*/GetMDInt(2)),
+  /*Order=*/GetMDInt(3));
+  break;
+}
+  }
+}
+
 bool OffloadEntriesInfoManager::empty() const {
   return OffloadEntriesTargetRegion.empty() &&
  OffloadEntriesDeviceGlobalVar.empty();
Index: llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
===
--- llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
+++ llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
@@ -1681,6 +1681,18 @@
 BasicBlock *PreInsertBefore,
 BasicBlock *PostInsertBefore,
 const Twine  = {});
+  /// OMP Offload Info Metadata name string
+  const std::string ompOffloadInfoName = "omp_offload.info";
+
+  /// Loads all the offload entries information from the host IR
+  /// metadata.
+  ///
+  /// \param M Module to load Metadata info from. Module passed maybe
+  /// loaded from bitcode file, i.e, different from OpenMPIRBuilder::M module.
+  /// \param OffloadEntriesInfoManager Initialize Offload Entry information.
+  void
+  loadOffloadInfoMetadata(Module ,
+  OffloadEntriesInfoManager );
 };
 
 /// Data structure to contain the information needed to uniquely identify
Index: clang/lib/CodeGen/CGOpenMPRuntime.cpp
===
--- clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -3171,52 +3171,7 @@
 return;
   }
 
-  llvm::NamedMDNode *MD = ME.get()->getNamedMetadata("omp_offload.info");
-  if (!MD)
-return;
-
-  for (llvm::MDNode *MN : MD->operands()) {
-auto & = [MN](unsigned Idx) {
-  auto *V = cast(MN->getOperand(Idx));
-  return cast(V->getValue())->getZExtValue();
-};
-
-auto & = [MN](unsigned Idx) {
-  auto *V = cast(MN->getOperand(Idx));
-  return V->getString();
-};
-
-switch (GetMDInt(0)) {
-default:
-  llvm_unreachable("Unexpected metadata!");
-  break;
-case llvm::OffloadEntriesInfoManager::OffloadEntryInfo::
-OffloadingEntryInfoTargetRegion: {
-  assert(CGM.getLangOpts().OpenMPIsDevice && "Initialization of entries is "
- "only required for the "
- "device code generation.");
-  llvm::TargetRegionEntryInfo EntryInfo(/*ParentName=*/GetMDString(3),
-/*DeviceID=*/GetMDInt(1),
-/*FileID=*/GetMDInt(2),
- 

[PATCH] D136975: [Concepts] Correctly handle failure when checking concepts recursively

2022-10-31 Thread Erich Keane via Phabricator via cfe-commits
erichkeane updated this revision to Diff 472093.
erichkeane added a comment.

ACTUALLY add the libcxx testing, also rebase so hopefully it applies cleanly.


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

https://reviews.llvm.org/D136975

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaConcept.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/test/SemaTemplate/concepts-GH53213.cpp
  clang/test/SemaTemplate/concepts-recursive-inst.cpp
  libcxx/DELETE_ME.txt

Index: libcxx/DELETE_ME.txt
===
--- /dev/null
+++ libcxx/DELETE_ME.txt
@@ -0,0 +1 @@
+D136975
Index: clang/test/SemaTemplate/concepts-recursive-inst.cpp
===
--- /dev/null
+++ clang/test/SemaTemplate/concepts-recursive-inst.cpp
@@ -0,0 +1,122 @@
+// RUN: %clang_cc1 -std=c++20 -verify %s
+namespace GH53213 {
+template
+concept c = requires(T t) { f(t); }; // #CDEF
+
+auto f(c auto); // #FDEF
+
+void g() {
+  f(0);
+  // expected-error@-1{{no matching function for call to 'f'}}
+  // expected-note@#FDEF{{constraints not satisfied}}
+  // expected-note@#FDEF{{because 'int' does not satisfy 'c'}}
+  // expected-note@#CDEF{{because 'f(t)' would be invalid: no matching function for call to 'f'}}
+}
+} // namespace GH53213 
+
+namespace GH45736 {
+struct constrained;
+
+template
+  struct type {
+  };
+template
+  constexpr bool f(type) {
+  return true;
+  }
+
+template
+  concept matches = f(type());
+
+
+struct constrained {
+template requires matches
+explicit constrained(U value) {
+}
+};
+
+bool f(constrained const &) {
+return true;
+}
+
+struct outer {
+constrained state;
+};
+
+bool f(outer const & x) {
+return f(x.state);
+}
+} // namespace GH45736
+
+namespace DirectRecursiveCheck {
+template
+concept NotInf = true;
+template
+concept Inf = requires(T& v){ // #INF_REQ
+  {begin(v)}; // #INF_BEGIN_EXPR
+};
+
+void begin(NotInf auto& v){ } // #NOTINF_BEGIN
+// This lookup should fail, since it results in a recursive check.
+// However, this is a 'hard failure'(not a SFINAE failure or constraints
+// violation), so it needs to cause the entire lookup to fail.
+void begin(Inf auto& v){ } // #INF_BEGIN
+
+struct my_range{
+} rng;
+
+void baz() {
+auto it = begin(rng); // #BEGIN_CALL
+// expected-error@#INF_BEGIN {{satisfaction of constraint 'Inf' depends on itself}}
+// expected-note@#INF_BEGIN {{while substituting template arguments into constraint expression here}}
+// expected-note@#INF_BEGIN_EXPR {{while checking constraint satisfaction for template 'begin' required here}}
+// expected-note@#INF_BEGIN_EXPR {{while substituting deduced template arguments into function template 'begin'}}
+// expected-note@#INF_BEGIN_EXPR {{in instantiation of requirement here}}
+// expected-note@#INF_REQ {{while substituting template arguments into constraint expression here}}
+// expected-note@#INF_BEGIN {{while checking the satisfaction of concept 'Inf' requested here}}
+// expected-note@#INF_BEGIN {{while substituting template arguments into constraint expression here}}
+// expected-note@#BEGIN_CALL {{while checking constraint satisfaction for template 'begin' required here}}
+// expected-note@#BEGIN_CALL {{in instantiation of function template specialization}}
+
+// Fallout of the failure is failed lookup, which is necessary to stop odd
+// cascading errors.
+// expected-error@#BEGIN_CALL {{no matching function for call to 'begin'}}
+// expected-note@#NOTINF_BEGIN {{candidate function}}
+// expected-note@#INF_BEGIN{{candidate template ignored: constraints not satisfied}}
+}
+} // namespace DirectRecursiveCheck
+
+namespace GH50891 {
+  template 
+  concept Numeric = requires(T a) { // #NUMERIC
+  foo(a); // #FOO_CALL
+};
+
+  struct Deferred {
+friend void foo(Deferred);
+template  operator TO(); // #OP_TO
+  };
+
+  static_assert(Numeric); // #STATIC_ASSERT
+  // expected-error@#OP_TO {{satisfaction of constraint 'Numeric' depends on itself}}
+  // expected-note@#OP_TO {{while substituting template arguments into constraint expression here}}
+  // FIXME: The following two refer to type-parameter-0-0, it would be nice to
+  // see if we could instead diagnose with the sugared name.
+  // expected-note@#FOO_CALL {{while checking constraint satisfaction for template}}
+  // expected-note@#FOO_CALL {{while substituting deduced template arguments into function template}}
+  // expected-note@#FOO_CALL {{in instantiation of requirement here}}
+  // expected-note@#NUMERIC {{while substituting template arguments into constraint expression here}}
+  // expected-note@#OP_TO {{skipping 2 contexts in backtrace}}
+  // expected-note@#FOO_CALL {{while checking constraint satisfaction for template}}
+  // expected-note@#FOO_CALL {{in instantiation of 

[PATCH] D136554: Implement CWG2631

2022-10-31 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

I'm still thinking about the implementation, but I think this is heading in the 
correct direction.




Comment at: clang/lib/AST/ExprCXX.cpp:970-973
+const Expr *CXXDefaultArgExpr::getExpr() const {
+  return CXXDefaultArgExprBits.HasRewrittenInit ? getAdjustedRewrittenExpr()
+: getParam()->getDefaultArg();
+}

Should also be a const_cast in the header file.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136554

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


[PATCH] D136790: [Clang][Sema] Add -Wincompatible-function-pointer-types-strict

2022-10-31 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

Thank you for the new diagnostic, please be sure to add a release note so users 
know there's a new warning.




Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:8217
+  err_typecheck_convert_incompatible_function_pointer.Text>,
+  InGroup>, 
DefaultIgnore;
 def ext_typecheck_convert_discards_qualifiers : ExtWarn<

We don't typically add new off-by-default warnings because we have evidence 
that users don't enable them enough to be worth adding them. Is there a way we 
can enable this warning by default for CFI compilation units (or when the cfi 
sanitizer is enabled) so that it's only off by default for non-CFI users? I 
don't think we have any examples of doing this in the code base, so I believe 
this would be breaking new ground (and thus is worth thinking about more, 
perhaps it's a bad idea for some reason).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136790

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


[PATCH] D136975: [Concepts] Correctly handle failure when checking concepts recursively

2022-10-31 Thread Luke Nihlen via Phabricator via cfe-commits
luken-google added a comment.

Looks good to me!


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

https://reviews.llvm.org/D136975

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


[PATCH] D136872: [OpenMP][OpenMPIRBuilder] Migrate loadOffloadInfoMetadata from clang to OMPIRbuilder

2022-10-31 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added inline comments.



Comment at: llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h:1685
+
+  const std::string ompOffloadInfoName = "omp_offload.info";
+

Drive by, add doxygen documentation to all methods + members please.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136872

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


[PATCH] D136953: [C++20] Diagnose invalid and reserved module names

2022-10-31 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/lib/Sema/SemaModule.cpp:282
+  StringRef FirstComponentName = Path[0].first->getName();
+  if (!getSourceManager().isInSystemHeader(Path[0].second) &&
+  (FirstComponentName == "std" ||

philnik wrote:
> aaron.ballman wrote:
> > philnik wrote:
> > > aaron.ballman wrote:
> > > > philnik wrote:
> > > > > ChuanqiXu wrote:
> > > > > > aaron.ballman wrote:
> > > > > > > aaron.ballman wrote:
> > > > > > > > ChuanqiXu wrote:
> > > > > > > > > erichkeane wrote:
> > > > > > > > > > ChuanqiXu wrote:
> > > > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > > > ChuanqiXu wrote:
> > > > > > > > > > > > > cor3ntin wrote:
> > > > > > > > > > > > > > ChuanqiXu wrote:
> > > > > > > > > > > > > > > std modules should be irreverent with system 
> > > > > > > > > > > > > > > headers; The intuition of the wording should be 
> > > > > > > > > > > > > > > that the users can't declare modules like `std` 
> > > > > > > > > > > > > > > or `std.compat` to avoid possible conflicting. 
> > > > > > > > > > > > > > > The approach I imaged may be add a new 
> > > > > > > > > > > > > > > compilation flags (call it `-fstd-modules`) now. 
> > > > > > > > > > > > > > > And if the compiler found a `std` module 
> > > > > > > > > > > > > > > declaration without `-fstd-modules`, emit an 
> > > > > > > > > > > > > > > error.  
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > For now, I think we can skip the check for 
> > > > > > > > > > > > > > > `-fstd-modules` and add it back when we starts to 
> > > > > > > > > > > > > > > support std modules actually.
> > > > > > > > > > > > > > The idea is that standard modules are built from 
> > > > > > > > > > > > > > system directories... it seems a better heuristic 
> > > > > > > > > > > > > > than adding a flag for the purpose of 1 diagnostics 
> > > > > > > > > > > > > > ( maybe some other system library could in theory 
> > > > > > > > > > > > > > export std with no warning, but I'm not super 
> > > > > > > > > > > > > > worried about that being a concern in practice)
> > > > > > > > > > > > > > The idea is that standard modules are built from 
> > > > > > > > > > > > > > system directories...
> > > > > > > > > > > > > 
> > > > > > > > > > > > > This is not true. For example, if someday libc++ 
> > > > > > > > > > > > > supports std modules, then we need to build the std 
> > > > > > > > > > > > > modules in our working directory, which is not system 
> > > > > > > > > > > > > directories. And **ideally**, we would distribute and 
> > > > > > > > > > > > > install module file in the system directories. But it 
> > > > > > > > > > > > > is irreverent with the path of the source file.
> > > > > > > > > > > > > then we need to build the std modules in our working 
> > > > > > > > > > > > > directory, which is not system directories.
> > > > > > > > > > > > 
> > > > > > > > > > > > `-isystem`, pragmas, and linemarkers are all ways 
> > > > > > > > > > > > around that -- I don't think we need a feature flag for 
> > > > > > > > > > > > this, unless I'm misunderstanding something.
> > > > > > > > > > > Although it may be a little bit nit picker, the module 
> > > > > > > > > > > unit which declares the std modules won't be header. It 
> > > > > > > > > > > is a module unit. So it requires we implement std modules 
> > > > > > > > > > > by wrapping linemarkers around the std modules 
> > > > > > > > > > > declaration, which looks a little bit overkill.
> > > > > > > > > > > 
> > > > > > > > > > > And another point is that maybe we need to introduce 
> > > > > > > > > > > another feature flags to implement std modules. Although 
> > > > > > > > > > > I tried to implement std modules within the current 
> > > > > > > > > > > features, I can't prove we can implement std modules in 
> > > > > > > > > > > that way in the end of the day.
> > > > > > > > > > > 
> > > > > > > > > > > Let me add some more words. The standards require us to 
> > > > > > > > > > > implement std modules without deprecating the system 
> > > > > > > > > > > headers. This strategy leads the direction to "implement 
> > > > > > > > > > > the components in the original headers and control their 
> > > > > > > > > > > visibility in the std module unit".
> > > > > > > > > > > It may look like:
> > > > > > > > > > > 
> > > > > > > > > > > ```
> > > > > > > > > > > //--- std.cppm
> > > > > > > > > > > module;
> > > > > > > > > > > #include 
> > > > > > > > > > > ...
> > > > > > > > > > > export module std;
> > > > > > > > > > > ```
> > > > > > > > > > > 
> > > > > > > > > > > Then how can control the visibility?  In my original 
> > > > > > > > > > > experiments, I use the style:
> > > > > > > > > > > 
> > > > > > > > > > > ```
> > > > > > > > > > > //--- std.cppm
> > > > > > > > > > > module;
> > > > > > > > > > > #include 
> > > > > > > > > > > ...
> > > > > > > > > > > export module std;
> > > > > > > > > > > export namespace 

[PATCH] D136872: [OpenMP][OpenMPIRBuilder] Migrate loadOffloadInfoMetadata from clang to OMPIRbuilder

2022-10-31 Thread Jan Sjödin via Phabricator via cfe-commits
jsjodin added inline comments.



Comment at: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:4712
+Module , OffloadEntriesInfoManager ,
+bool isDevice) {
+  // If we are in target mode, load the metadata from the host IR. This code 
has

isDevice must be true (add assertion at the call site) remove the parameter, 
and the assertions in this function. Document that this function is only 
intended to be used with device code generation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136872

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


[PATCH] D136975: [Concepts] Correctly handle failure when checking concepts recursively

2022-10-31 Thread Erich Keane via Phabricator via cfe-commits
erichkeane updated this revision to Diff 472086.
erichkeane added a comment.

Add DELETE_ME so that the libcxx tests run.  Due to the nature of this patch, 
it is possible that I will have missed a few cases where we should be 
're-starting' the substitution stack checking.


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

https://reviews.llvm.org/D136975

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaConcept.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/test/SemaTemplate/concepts-GH53213.cpp
  clang/test/SemaTemplate/concepts-recursive-inst.cpp

Index: clang/test/SemaTemplate/concepts-recursive-inst.cpp
===
--- /dev/null
+++ clang/test/SemaTemplate/concepts-recursive-inst.cpp
@@ -0,0 +1,122 @@
+// RUN: %clang_cc1 -std=c++20 -verify %s
+namespace GH53213 {
+template
+concept c = requires(T t) { f(t); }; // #CDEF
+
+auto f(c auto); // #FDEF
+
+void g() {
+  f(0);
+  // expected-error@-1{{no matching function for call to 'f'}}
+  // expected-note@#FDEF{{constraints not satisfied}}
+  // expected-note@#FDEF{{because 'int' does not satisfy 'c'}}
+  // expected-note@#CDEF{{because 'f(t)' would be invalid: no matching function for call to 'f'}}
+}
+} // namespace GH53213 
+
+namespace GH45736 {
+struct constrained;
+
+template
+  struct type {
+  };
+template
+  constexpr bool f(type) {
+  return true;
+  }
+
+template
+  concept matches = f(type());
+
+
+struct constrained {
+template requires matches
+explicit constrained(U value) {
+}
+};
+
+bool f(constrained const &) {
+return true;
+}
+
+struct outer {
+constrained state;
+};
+
+bool f(outer const & x) {
+return f(x.state);
+}
+} // namespace GH45736
+
+namespace DirectRecursiveCheck {
+template
+concept NotInf = true;
+template
+concept Inf = requires(T& v){ // #INF_REQ
+  {begin(v)}; // #INF_BEGIN_EXPR
+};
+
+void begin(NotInf auto& v){ } // #NOTINF_BEGIN
+// This lookup should fail, since it results in a recursive check.
+// However, this is a 'hard failure'(not a SFINAE failure or constraints
+// violation), so it needs to cause the entire lookup to fail.
+void begin(Inf auto& v){ } // #INF_BEGIN
+
+struct my_range{
+} rng;
+
+void baz() {
+auto it = begin(rng); // #BEGIN_CALL
+// expected-error@#INF_BEGIN {{satisfaction of constraint 'Inf' depends on itself}}
+// expected-note@#INF_BEGIN {{while substituting template arguments into constraint expression here}}
+// expected-note@#INF_BEGIN_EXPR {{while checking constraint satisfaction for template 'begin' required here}}
+// expected-note@#INF_BEGIN_EXPR {{while substituting deduced template arguments into function template 'begin'}}
+// expected-note@#INF_BEGIN_EXPR {{in instantiation of requirement here}}
+// expected-note@#INF_REQ {{while substituting template arguments into constraint expression here}}
+// expected-note@#INF_BEGIN {{while checking the satisfaction of concept 'Inf' requested here}}
+// expected-note@#INF_BEGIN {{while substituting template arguments into constraint expression here}}
+// expected-note@#BEGIN_CALL {{while checking constraint satisfaction for template 'begin' required here}}
+// expected-note@#BEGIN_CALL {{in instantiation of function template specialization}}
+
+// Fallout of the failure is failed lookup, which is necessary to stop odd
+// cascading errors.
+// expected-error@#BEGIN_CALL {{no matching function for call to 'begin'}}
+// expected-note@#NOTINF_BEGIN {{candidate function}}
+// expected-note@#INF_BEGIN{{candidate template ignored: constraints not satisfied}}
+}
+} // namespace DirectRecursiveCheck
+
+namespace GH50891 {
+  template 
+  concept Numeric = requires(T a) { // #NUMERIC
+  foo(a); // #FOO_CALL
+};
+
+  struct Deferred {
+friend void foo(Deferred);
+template  operator TO(); // #OP_TO
+  };
+
+  static_assert(Numeric); // #STATIC_ASSERT
+  // expected-error@#OP_TO {{satisfaction of constraint 'Numeric' depends on itself}}
+  // expected-note@#OP_TO {{while substituting template arguments into constraint expression here}}
+  // FIXME: The following two refer to type-parameter-0-0, it would be nice to
+  // see if we could instead diagnose with the sugared name.
+  // expected-note@#FOO_CALL {{while checking constraint satisfaction for template}}
+  // expected-note@#FOO_CALL {{while substituting deduced template arguments into function template}}
+  // expected-note@#FOO_CALL {{in instantiation of requirement here}}
+  // expected-note@#NUMERIC {{while substituting template arguments into constraint expression here}}
+  // expected-note@#OP_TO {{skipping 2 contexts in backtrace}}
+  // expected-note@#FOO_CALL {{while checking constraint satisfaction for template}}
+  // expected-note@#FOO_CALL {{in instantiation of function template specialization}}
+  // expected-note@#FOO_CALL {{in 

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

2022-10-31 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added reviewers: clang-language-wg, aaron.ballman.
aaron.ballman added a comment.

Thank you for the changes! One thing you should add is a release note so users 
know there's been a diagnostic improvement.




Comment at: clang/lib/Parse/ParseDecl.cpp:5384-5385
 
+bool Parser::IsUnknownTypedefName() {
+  switch (NextToken().getKind()) {
+  default:

This is a pretty unsafe function to call from arbitrary parsing contexts. We 
should be asserting that the parser is in a reasonable state to even ask this 
question; alternatively, we could make this a static function that accepts a 
`Parser&` object.



Comment at: clang/lib/Parse/ParseDecl.cpp:5388
+return false;
+  case tok::kw___attribute:
+  case tok::star:

Why only `__attribute__` and not `__declspec`? `[[]]` attributes as well?



Comment at: clang/lib/Parse/ParseDecl.cpp:5392-5394
+  case tok::amp:
+  case tok::ampamp:
+return getLangOpts().CPlusPlus;

Looking for `*`, `&`, and `&&` will help catch some cases... but it's not 
really going to help for situations like `unknown const *` or other 
qualifiers...



Comment at: clang/lib/Parse/ParseDecl.cpp:5425
+// node in AST for such cases which is good for AST readers.
+if (IsUnknownTypedefName() && !getLangOpts().ObjC)
+  return true;

Why is ObjC exempted from this?

I need to think about this a whole lot more. On the one hand, I like the 
changes happening in the test cases; those look like good changes to me. But on 
the other hand, this function is called in a fair number of places to make 
parsing decisions and I'm not convinced that speculative answers are the best 
way to go from this interface. I need to see if I can find any situations where 
this is called and we'd get worse parsing behavior (or incorrect parsing 
behavior!).



Comment at: clang/test/SemaOpenCL/invalid-pipes-cl1.2.cl:29-34
  reserve_id_t r;
 #if defined(__OPENCL_C_VERSION__)
-// expected-error@-2 {{use of undeclared identifier 'reserve_id_t'}}
+// expected-error@-2 {{unknown type name 'reserve_id_t'}}
 #else
 // expected-error@-4 {{unknown type name 'reserve_id_t'}}
 #endif




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137020

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


[PATCH] D136886: [clang] ASTImporter: Fix importing of va_list types and declarations

2022-10-31 Thread Matheus Izvekov via Phabricator via cfe-commits
mizvekov added a comment.

I'll need to have another look at this, apparently the synthesized  `std` 
namespace breaks some tests on arm platforms.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136886

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


[PATCH] D136953: [C++20] Diagnose invalid and reserved module names

2022-10-31 Thread Nikolas Klauser via Phabricator via cfe-commits
philnik added inline comments.



Comment at: clang/lib/Sema/SemaModule.cpp:282
+  StringRef FirstComponentName = Path[0].first->getName();
+  if (!getSourceManager().isInSystemHeader(Path[0].second) &&
+  (FirstComponentName == "std" ||

aaron.ballman wrote:
> philnik wrote:
> > aaron.ballman wrote:
> > > philnik wrote:
> > > > ChuanqiXu wrote:
> > > > > aaron.ballman wrote:
> > > > > > aaron.ballman wrote:
> > > > > > > ChuanqiXu wrote:
> > > > > > > > erichkeane wrote:
> > > > > > > > > ChuanqiXu wrote:
> > > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > > ChuanqiXu wrote:
> > > > > > > > > > > > cor3ntin wrote:
> > > > > > > > > > > > > ChuanqiXu wrote:
> > > > > > > > > > > > > > std modules should be irreverent with system 
> > > > > > > > > > > > > > headers; The intuition of the wording should be 
> > > > > > > > > > > > > > that the users can't declare modules like `std` or 
> > > > > > > > > > > > > > `std.compat` to avoid possible conflicting. The 
> > > > > > > > > > > > > > approach I imaged may be add a new compilation 
> > > > > > > > > > > > > > flags (call it `-fstd-modules`) now. And if the 
> > > > > > > > > > > > > > compiler found a `std` module declaration without 
> > > > > > > > > > > > > > `-fstd-modules`, emit an error.  
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > For now, I think we can skip the check for 
> > > > > > > > > > > > > > `-fstd-modules` and add it back when we starts to 
> > > > > > > > > > > > > > support std modules actually.
> > > > > > > > > > > > > The idea is that standard modules are built from 
> > > > > > > > > > > > > system directories... it seems a better heuristic 
> > > > > > > > > > > > > than adding a flag for the purpose of 1 diagnostics ( 
> > > > > > > > > > > > > maybe some other system library could in theory 
> > > > > > > > > > > > > export std with no warning, but I'm not super worried 
> > > > > > > > > > > > > about that being a concern in practice)
> > > > > > > > > > > > > The idea is that standard modules are built from 
> > > > > > > > > > > > > system directories...
> > > > > > > > > > > > 
> > > > > > > > > > > > This is not true. For example, if someday libc++ 
> > > > > > > > > > > > supports std modules, then we need to build the std 
> > > > > > > > > > > > modules in our working directory, which is not system 
> > > > > > > > > > > > directories. And **ideally**, we would distribute and 
> > > > > > > > > > > > install module file in the system directories. But it 
> > > > > > > > > > > > is irreverent with the path of the source file.
> > > > > > > > > > > > then we need to build the std modules in our working 
> > > > > > > > > > > > directory, which is not system directories.
> > > > > > > > > > > 
> > > > > > > > > > > `-isystem`, pragmas, and linemarkers are all ways around 
> > > > > > > > > > > that -- I don't think we need a feature flag for this, 
> > > > > > > > > > > unless I'm misunderstanding something.
> > > > > > > > > > Although it may be a little bit nit picker, the module unit 
> > > > > > > > > > which declares the std modules won't be header. It is a 
> > > > > > > > > > module unit. So it requires we implement std modules by 
> > > > > > > > > > wrapping linemarkers around the std modules declaration, 
> > > > > > > > > > which looks a little bit overkill.
> > > > > > > > > > 
> > > > > > > > > > And another point is that maybe we need to introduce 
> > > > > > > > > > another feature flags to implement std modules. Although I 
> > > > > > > > > > tried to implement std modules within the current features, 
> > > > > > > > > > I can't prove we can implement std modules in that way in 
> > > > > > > > > > the end of the day.
> > > > > > > > > > 
> > > > > > > > > > Let me add some more words. The standards require us to 
> > > > > > > > > > implement std modules without deprecating the system 
> > > > > > > > > > headers. This strategy leads the direction to "implement 
> > > > > > > > > > the components in the original headers and control their 
> > > > > > > > > > visibility in the std module unit".
> > > > > > > > > > It may look like:
> > > > > > > > > > 
> > > > > > > > > > ```
> > > > > > > > > > //--- std.cppm
> > > > > > > > > > module;
> > > > > > > > > > #include 
> > > > > > > > > > ...
> > > > > > > > > > export module std;
> > > > > > > > > > ```
> > > > > > > > > > 
> > > > > > > > > > Then how can control the visibility?  In my original 
> > > > > > > > > > experiments, I use the style:
> > > > > > > > > > 
> > > > > > > > > > ```
> > > > > > > > > > //--- std.cppm
> > > > > > > > > > module;
> > > > > > > > > > #include 
> > > > > > > > > > ...
> > > > > > > > > > export module std;
> > > > > > > > > > export namespace std {
> > > > > > > > > > using std::sort;
> > > > > > > > > > }
> > > > > > > > > > ```
> > > > > > > > > > 
> > > > > > > > > > but this doesn't always work. For example, we can't `using` 
> > > > > > > > > > a 

[PATCH] D133052: [clang] Avoid crash when expanding conversion templates in concepts.

2022-10-31 Thread Erich Keane via Phabricator via cfe-commits
erichkeane requested changes to this revision.
erichkeane added a comment.
This revision now requires changes to proceed.

I think the 'this results in a hard error, not failed lookup' is a necessity 
here based on discussions on the core reflector.  Also see: 
https://reviews.llvm.org/D133052


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133052

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


[clang-tools-extra] ee1f132 - Revert "[clang] ASTImporter: Fix importing of va_list types and declarations"

2022-10-31 Thread Matheus Izvekov via cfe-commits

Author: Matheus Izvekov
Date: 2022-10-31T19:34:23+01:00
New Revision: ee1f132d2c4d399be711275a62698ea9e766c199

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

LOG: Revert "[clang] ASTImporter: Fix importing of va_list types and 
declarations"

This reverts commit 5f820c0f55cd9d4f4520cc92eae0a1c4afe05a54.

Apparently it breaks aarch64 buildbots.
https://lab.llvm.org/buildbot#builders/188/builds/21591

Added: 


Modified: 
clang-tools-extra/clang-tidy/altera/StructPackAlignCheck.cpp
clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp
clang/docs/ReleaseNotes.rst
clang/lib/Frontend/ASTMerge.cpp
clang/lib/Sema/Sema.cpp
clang/test/AST/ast-dump-file-line-json.c
clang/test/AST/ast-dump-overloaded-operators.cpp
clang/test/AST/ast-dump-record-definition-data-json.cpp
clang/test/AST/ast-dump-records-json.cpp
clang/test/AST/ast-dump-template-decls-json.cpp
clang/test/AST/ast-dump-traits.cpp
clang/test/AST/fixed_point.c
clang/test/AST/float16.cpp
clang/test/PCH/stmt-openmp_structured_block-bit.cpp
clang/unittests/AST/ASTImporterTest.cpp

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/altera/StructPackAlignCheck.cpp 
b/clang-tools-extra/clang-tidy/altera/StructPackAlignCheck.cpp
index 1735242418671..b5f8d082d8877 100644
--- a/clang-tools-extra/clang-tidy/altera/StructPackAlignCheck.cpp
+++ b/clang-tools-extra/clang-tidy/altera/StructPackAlignCheck.cpp
@@ -19,11 +19,10 @@ namespace tidy {
 namespace altera {
 
 void StructPackAlignCheck::registerMatchers(MatchFinder *Finder) {
-  Finder->addMatcher(
-  recordDecl(isStruct(), isDefinition(),
- unless(anyOf(isExpansionInSystemHeader(), isImplicit(
-  .bind("struct"),
-  this);
+  Finder->addMatcher(recordDecl(isStruct(), isDefinition(),
+unless(isExpansionInSystemHeader()))
+ .bind("struct"),
+ this);
 }
 
 CharUnits

diff  --git a/clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp 
b/clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp
index 89f2bb6aaf50a..73b47dca20930 100644
--- a/clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp
+++ b/clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp
@@ -111,10 +111,7 @@ void 
RenamerClangTidyCheck::storeOptions(ClangTidyOptions::OptionMap ) {
 }
 
 void RenamerClangTidyCheck::registerMatchers(MatchFinder *Finder) {
-  Finder->addMatcher(
-  namedDecl(unless(anyOf(isImplicit(), hasDeclContext(isImplicit()
-  .bind("decl"),
-  this);
+  Finder->addMatcher(namedDecl().bind("decl"), this);
   Finder->addMatcher(usingDecl().bind("using"), this);
   Finder->addMatcher(declRefExpr().bind("declRef"), this);
   Finder->addMatcher(cxxConstructorDecl(unless(isImplicit())).bind("classRef"),

diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 991ffac7b8316..f751f96d29e9d 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -268,7 +268,6 @@ Bug Fixes
   functions. `Issue 56154 `_
 - Fix handling of unexpanded packs in template argument expressions.
   `Issue 58679 `_
-- Fix importing of va_list types and declarations.
 
 Improvements to Clang's diagnostics
 ^^^

diff  --git a/clang/lib/Frontend/ASTMerge.cpp b/clang/lib/Frontend/ASTMerge.cpp
index 750866892d058..14d781ccdf936 100644
--- a/clang/lib/Frontend/ASTMerge.cpp
+++ b/clang/lib/Frontend/ASTMerge.cpp
@@ -59,6 +59,12 @@ void ASTMergeAction::ExecuteAction() {
 
 TranslationUnitDecl *TU = Unit->getASTContext().getTranslationUnitDecl();
 for (auto *D : TU->decls()) {
+  // Don't re-import __va_list_tag, __builtin_va_list.
+  if (const auto *ND = dyn_cast(D))
+if (IdentifierInfo *II = ND->getIdentifier())
+  if (II->isStr("__va_list_tag") || II->isStr("__builtin_va_list"))
+continue;
+
   llvm::Expected ToDOrError = Importer.Import(D);
 
   if (ToDOrError) {

diff  --git a/clang/lib/Sema/Sema.cpp b/clang/lib/Sema/Sema.cpp
index fae85921b0402..c229a77ff0b8d 100644
--- a/clang/lib/Sema/Sema.cpp
+++ b/clang/lib/Sema/Sema.cpp
@@ -449,26 +449,6 @@ void Sema::Initialize() {
   PushOnScopeChains(Context.getBuiltinMSVaListDecl(), TUScope);
   }
 
-  if (auto *ND = dyn_cast_if_present(Context.getVaListTagDecl())) {
-if (auto *DC = ND->getLexicalDeclContext(); DC->isStdNamespace()) {
-  auto *NS = cast(DC);
-  if (!StdNamespace)
-StdNamespace = NS;
-  if (!Context.getTranslationUnitDecl()->containsDecl(NS))
-PushOnScopeChains(NS, TUScope);
-  if 

[PATCH] D136844: [libclang] Expose completion result kind in `CXCompletionResult`

2022-10-31 Thread Egor Zhdan via Phabricator via cfe-commits
egorzhdan added inline comments.



Comment at: clang/include/clang/Sema/CodeCompleteConsumer.h:755
-  /// Describes the kind of result generated.
-  enum ResultKind {
-/// Refers to a declaration.

kadircet wrote:
> egorzhdan wrote:
> > kadircet wrote:
> > > i don't follow the reason for replacing this struct with 
> > > `CXCompletionResultKind` and renaming occurrences in half of the 
> > > codebase. can we keep this around, introduce the new enum type into 
> > > `Index.h` and have `clang/tools/libclang/CIndexCodeCompletion.cpp` do the 
> > > conversion from Sema type to Index type instead?
> > > 
> > > Unless I am missing some other requirement for doing so. i feel like the 
> > > conceptual dependency from Sema to Index is one we should get rid of, 
> > > rather than make tighter.
> > This was mostly done to be consistent with the way `CXCursorKind` and 
> > `CXAvailabilityKind` are declared in `Index.h` and used as fields of 
> > `CodeCompletionResult`. I think updating the enum name in a few source 
> > files shouldn't be a major problem, but I can avoid it if you feel strongly 
> > against this approach.
> I completely agree with the consistency argument, but IMO the conceptual 
> dependency from clang-sema to clang-cindex is just wrong.
> 
> cindex is mostly implemented by `libclang`, which is part of clang-tools. all 
> of this works today because clang-sema is only using declarations visible in 
> headers and doesn't properly depend on `libclang` in the build files.
> 
> Hence I believe rather than preserving consistency here, we should be moving 
> towards breaking that dependency over time. Therefore I was opposing the idea 
> of introducing another type usage that'll make this dependency more strong.
>  all of this works today because clang-sema is only using declarations 
> visible in headers and doesn't properly depend on libclang in the build files.

Oh I see, this is a great point, I didn't realize that. I'll update the patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136844

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


[PATCH] D137067: [DebugInfo][Metadata] Make AllEnumTypes holding TrackingMDNodeRef

2022-10-31 Thread Kristina Bessonova via Phabricator via cfe-commits
krisb added a comment.

In D137067#3896524 , @dblaikie wrote:

> Test case can be simplified a bit further:

Thank you!

> but otherwise I'm OK with this - I don't /fully/ understand it, but it sounds 
> plausible enough. (if you have time, I wouldn't mind hearing more about why 
> this requires local types (`Struct3`) and two similar functions to tickle the 
> issue)

The test is just a simplified code sample where the issue was original faced. 
I'm not sure we specifically need local types or two particular functions, but 
artificially reproducing the same conditions may be tricky.
Basically, the issue happens only when collisions take place twice:

- first time when a record's temporary debug metadata being replaced by a 
unique, and
- second time when tempopary's enum user being re-uniquefied.

I haven't studied deeply why the collisions happen in this particular test, 
since if collisions /may/ happen, we should handle this case correctly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137067

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


[PATCH] D137067: [DebugInfo][Metadata] Make AllEnumTypes holding TrackingMDNodeRef

2022-10-31 Thread Kristina Bessonova via Phabricator via cfe-commits
krisb updated this revision to Diff 472079.
krisb added a comment.

Apply review comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137067

Files:
  clang/test/CodeGenCXX/debug-info-enum-metadata-collision.cpp
  llvm/include/llvm/IR/DIBuilder.h
  llvm/lib/IR/DIBuilder.cpp


Index: llvm/lib/IR/DIBuilder.cpp
===
--- llvm/lib/IR/DIBuilder.cpp
+++ llvm/lib/IR/DIBuilder.cpp
@@ -84,7 +84,9 @@
   }
 
   if (!AllEnumTypes.empty())
-CUNode->replaceEnumTypes(MDTuple::get(VMContext, AllEnumTypes));
+CUNode->replaceEnumTypes(MDTuple::get(
+VMContext, SmallVector(AllEnumTypes.begin(),
+   AllEnumTypes.end(;
 
   SmallVector RetainValues;
   // Declarations and definitions of the same type may be retained. Some
@@ -556,7 +558,7 @@
   getNonCompileUnitScope(Scope), UnderlyingType, SizeInBits, AlignInBits, 
0,
   IsScoped ? DINode::FlagEnumClass : DINode::FlagZero, Elements, 0, 
nullptr,
   nullptr, UniqueIdentifier);
-  AllEnumTypes.push_back(CTy);
+  AllEnumTypes.emplace_back(CTy);
   trackIfUnresolved(CTy);
   return CTy;
 }
Index: llvm/include/llvm/IR/DIBuilder.h
===
--- llvm/include/llvm/IR/DIBuilder.h
+++ llvm/include/llvm/IR/DIBuilder.h
@@ -48,7 +48,7 @@
 Function *LabelFn;   ///< llvm.dbg.label
 Function *AddrFn;///< llvm.dbg.addr
 
-SmallVector AllEnumTypes;
+SmallVector AllEnumTypes;
 /// Track the RetainTypes, since they can be updated later on.
 SmallVector AllRetainTypes;
 SmallVector AllSubprograms;
Index: clang/test/CodeGenCXX/debug-info-enum-metadata-collision.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/debug-info-enum-metadata-collision.cpp
@@ -0,0 +1,25 @@
+// RUN: %clang_cc1 -triple %itanium_abi_triple -emit-llvm 
-debug-info-kind=constructor %s -o - | FileCheck %s
+
+// Test that clang doesn't crash while resolving temporary debug metadata of
+// a record with collisions in the record's enum users.
+
+// CHECK:  !DICompositeType(tag: DW_TAG_enumeration_type,
+// CHECK-SAME:  scope: [[SCOPE:![0-9]+]]
+// CHECK-SAME:  elements: [[ELEMENTS:![0-9]+]]
+// CHECK:  [[SCOPE]] = !DICompositeType(tag: DW_TAG_structure_type
+// CHECK-SAME:  name: "Struct1"
+// CHECK:  [[ELEMENTS]] = !{[[ELEMENT:![0-9]+]]}
+// CHECK:  [[ELEMENT]] = !DIEnumerator(name: "enumValue1"
+
+template  struct Struct1 {
+  enum { enumValue1 };
+  Struct1();
+};
+void function2() {
+  struct Struct3 {};
+  int i = Struct1::enumValue1;
+}
+void function3() {
+  struct Struct3 {};
+  int i = Struct1::enumValue1;
+}


Index: llvm/lib/IR/DIBuilder.cpp
===
--- llvm/lib/IR/DIBuilder.cpp
+++ llvm/lib/IR/DIBuilder.cpp
@@ -84,7 +84,9 @@
   }
 
   if (!AllEnumTypes.empty())
-CUNode->replaceEnumTypes(MDTuple::get(VMContext, AllEnumTypes));
+CUNode->replaceEnumTypes(MDTuple::get(
+VMContext, SmallVector(AllEnumTypes.begin(),
+   AllEnumTypes.end(;
 
   SmallVector RetainValues;
   // Declarations and definitions of the same type may be retained. Some
@@ -556,7 +558,7 @@
   getNonCompileUnitScope(Scope), UnderlyingType, SizeInBits, AlignInBits, 0,
   IsScoped ? DINode::FlagEnumClass : DINode::FlagZero, Elements, 0, nullptr,
   nullptr, UniqueIdentifier);
-  AllEnumTypes.push_back(CTy);
+  AllEnumTypes.emplace_back(CTy);
   trackIfUnresolved(CTy);
   return CTy;
 }
Index: llvm/include/llvm/IR/DIBuilder.h
===
--- llvm/include/llvm/IR/DIBuilder.h
+++ llvm/include/llvm/IR/DIBuilder.h
@@ -48,7 +48,7 @@
 Function *LabelFn;   ///< llvm.dbg.label
 Function *AddrFn;///< llvm.dbg.addr
 
-SmallVector AllEnumTypes;
+SmallVector AllEnumTypes;
 /// Track the RetainTypes, since they can be updated later on.
 SmallVector AllRetainTypes;
 SmallVector AllSubprograms;
Index: clang/test/CodeGenCXX/debug-info-enum-metadata-collision.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/debug-info-enum-metadata-collision.cpp
@@ -0,0 +1,25 @@
+// RUN: %clang_cc1 -triple %itanium_abi_triple -emit-llvm -debug-info-kind=constructor %s -o - | FileCheck %s
+
+// Test that clang doesn't crash while resolving temporary debug metadata of
+// a record with collisions in the record's enum users.
+
+// CHECK:  !DICompositeType(tag: DW_TAG_enumeration_type,
+// CHECK-SAME:  scope: [[SCOPE:![0-9]+]]
+// CHECK-SAME:  elements: [[ELEMENTS:![0-9]+]]
+// CHECK:  [[SCOPE]] = 

[PATCH] D134089: [clang] Mention vector in the description for -mno-implict-float.

2022-10-31 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added a comment.

Ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134089

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


[PATCH] D137058: [Driver] [Modules] Support -fsave-std-c++-module-file (1/2)

2022-10-31 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added a comment.

@ben.boeckel maybe this'd be the place to discuss the motivation for this 
feature (picking up from your comment here: 
https://reviews.llvm.org/D134267#3892629 )

Could you expound a bit on why "write the .pcm to the same path as the .o" 
isn't sufficient? (like Split DWARF does this, for instance - not sure we have 
lots of other things to extrapolate from (admittedly there is a flag for 
specifying the filename for Split DWARF too, but it's not a terribly official 
thing (doesn't have a '-f', '-g', etc prefix))


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137058

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


[PATCH] D136554: Implement CWG2631

2022-10-31 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin updated this revision to Diff 472071.
cor3ntin marked 6 inline comments as done.
cor3ntin added a comment.

Address Aaron's comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136554

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/AST/ExprCXX.h
  clang/include/clang/AST/Stmt.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/ExprCXX.cpp
  clang/lib/Parse/ParseCXXInlineMethods.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReaderStmt.cpp
  clang/lib/Serialization/ASTWriterStmt.cpp
  clang/test/CXX/class/class.local/p1-0x.cpp
  clang/test/CodeGenCXX/default-arguments-with-immediate.cpp
  clang/test/PCH/default-argument-with-immediate-calls.cpp
  clang/test/SemaCXX/cxx2a-consteval-default-params.cpp
  clang/test/SemaCXX/source_location.cpp

Index: clang/test/SemaCXX/source_location.cpp
===
--- clang/test/SemaCXX/source_location.cpp
+++ clang/test/SemaCXX/source_location.cpp
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -std=c++1z -fcxx-exceptions -fexceptions -verify %s
+// RUN: %clang_cc1 -std=c++2a -fcxx-exceptions -DUSE_CONSTEVAL -fexceptions -verify %s
 // expected-no-diagnostics
 
 #define assert(...) ((__VA_ARGS__) ? ((void)0) : throw 42)
@@ -8,15 +9,22 @@
 template 
 struct Printer;
 
+#ifdef USE_CONSTEVAL
+#define SOURCE_LOC_EVAL_KIND consteval
+#else
+#define SOURCE_LOC_EVAL_KIND constexpr
+#endif
+
 namespace std {
 class source_location {
   struct __impl;
 
 public:
-  static constexpr source_location current(const __impl *__p = __builtin_source_location()) noexcept {
-source_location __loc;
-__loc.__m_impl = __p;
-return __loc;
+  static SOURCE_LOC_EVAL_KIND source_location
+current(const __impl *__p = __builtin_source_location()) noexcept {
+  source_location __loc;
+  __loc.__m_impl = __p;
+  return __loc;
   }
   constexpr source_location() = default;
   constexpr source_location(source_location const &) = default;
@@ -593,3 +601,22 @@
   }
   static_assert(test());
 }
+
+namespace Lambda {
+#line 8000 "TestLambda.cpp"
+constexpr int nested_lambda(int l = []{
+  return SL::current().line();
+}()) {
+  return l;
+}
+static_assert(nested_lambda() == __LINE__ - 4);
+
+constexpr int lambda_param(int l = [](int l = SL::current().line()) {
+  return l;
+}()) {
+  return l;
+}
+static_assert(lambda_param() == __LINE__);
+
+
+}
Index: clang/test/SemaCXX/cxx2a-consteval-default-params.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/cxx2a-consteval-default-params.cpp
@@ -0,0 +1,65 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++20 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++2b %s
+
+consteval int undefined();  // expected-note 4 {{declared here}}
+
+void check_lambdas_unused(
+int a = []
+{
+return undefined();  // expected-error {{not a constant expression}} \
+ // expected-note  {{undefined function 'undefined'}}
+}(),
+int b = [](int no_error = undefined()) {
+return no_error;
+}(0),
+int c = [](int defaulted = undefined()) {
+return defaulted;
+}()
+) {}
+
+int check_lambdas_used(
+int b = [](int no_error = undefined()) {
+return no_error;
+}(0),
+int c = [](int defaulted = undefined()) { // expected-error {{not a constant expression}} \
+  // expected-note  {{declared here}} \
+  // expected-note  {{undefined function 'undefined'}}
+return defaulted;
+}(),  // expected-note {{in the default initalizer of 'defaulted'}}
+int d = [](int defaulted = sizeof(undefined())) {
+return defaulted;
+}()
+) {
+return 0;
+}
+
+int test_check_lambdas_used = check_lambdas_used();
+
+struct UnusedInitWithLambda {
+int a = [] {
+return undefined();  // expected-error {{not a constant expression}} \
+ // expected-note  {{undefined function 'undefined'}}
+}();
+// UnusedInitWithLambda is never constructed, so the initializer
+// of b and undefined() are never evaluated.
+int b = [](int no_error = undefined()) {
+return no_error;
+}();
+};
+
+consteval int ub(int n) {
+return 0/n; // expected-note  {{division}}
+}
+
+struct InitWithLambda {
+int b = [](int error = undefined()) { // expected-error {{not a constant expression}} \
+  // expected-note  {{declared here}} \
+  // expected-note  {{undefined function 'undefined'}}
+return error;
+}(); // expected-note {{in the default 

[PATCH] D136953: [C++20] Diagnose invalid and reserved module names

2022-10-31 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/lib/Sema/SemaModule.cpp:282
+  StringRef FirstComponentName = Path[0].first->getName();
+  if (!getSourceManager().isInSystemHeader(Path[0].second) &&
+  (FirstComponentName == "std" ||

philnik wrote:
> aaron.ballman wrote:
> > philnik wrote:
> > > ChuanqiXu wrote:
> > > > aaron.ballman wrote:
> > > > > aaron.ballman wrote:
> > > > > > ChuanqiXu wrote:
> > > > > > > erichkeane wrote:
> > > > > > > > ChuanqiXu wrote:
> > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > ChuanqiXu wrote:
> > > > > > > > > > > cor3ntin wrote:
> > > > > > > > > > > > ChuanqiXu wrote:
> > > > > > > > > > > > > std modules should be irreverent with system headers; 
> > > > > > > > > > > > > The intuition of the wording should be that the users 
> > > > > > > > > > > > > can't declare modules like `std` or `std.compat` to 
> > > > > > > > > > > > > avoid possible conflicting. The approach I imaged may 
> > > > > > > > > > > > > be add a new compilation flags (call it 
> > > > > > > > > > > > > `-fstd-modules`) now. And if the compiler found a 
> > > > > > > > > > > > > `std` module declaration without `-fstd-modules`, 
> > > > > > > > > > > > > emit an error.  
> > > > > > > > > > > > > 
> > > > > > > > > > > > > For now, I think we can skip the check for 
> > > > > > > > > > > > > `-fstd-modules` and add it back when we starts to 
> > > > > > > > > > > > > support std modules actually.
> > > > > > > > > > > > The idea is that standard modules are built from system 
> > > > > > > > > > > > directories... it seems a better heuristic than adding 
> > > > > > > > > > > > a flag for the purpose of 1 diagnostics ( maybe some 
> > > > > > > > > > > > other system library could in theory export std with no 
> > > > > > > > > > > > warning, but I'm not super worried about that being a 
> > > > > > > > > > > > concern in practice)
> > > > > > > > > > > > The idea is that standard modules are built from system 
> > > > > > > > > > > > directories...
> > > > > > > > > > > 
> > > > > > > > > > > This is not true. For example, if someday libc++ supports 
> > > > > > > > > > > std modules, then we need to build the std modules in our 
> > > > > > > > > > > working directory, which is not system directories. And 
> > > > > > > > > > > **ideally**, we would distribute and install module file 
> > > > > > > > > > > in the system directories. But it is irreverent with the 
> > > > > > > > > > > path of the source file.
> > > > > > > > > > > then we need to build the std modules in our working 
> > > > > > > > > > > directory, which is not system directories.
> > > > > > > > > > 
> > > > > > > > > > `-isystem`, pragmas, and linemarkers are all ways around 
> > > > > > > > > > that -- I don't think we need a feature flag for this, 
> > > > > > > > > > unless I'm misunderstanding something.
> > > > > > > > > Although it may be a little bit nit picker, the module unit 
> > > > > > > > > which declares the std modules won't be header. It is a 
> > > > > > > > > module unit. So it requires we implement std modules by 
> > > > > > > > > wrapping linemarkers around the std modules declaration, 
> > > > > > > > > which looks a little bit overkill.
> > > > > > > > > 
> > > > > > > > > And another point is that maybe we need to introduce another 
> > > > > > > > > feature flags to implement std modules. Although I tried to 
> > > > > > > > > implement std modules within the current features, I can't 
> > > > > > > > > prove we can implement std modules in that way in the end of 
> > > > > > > > > the day.
> > > > > > > > > 
> > > > > > > > > Let me add some more words. The standards require us to 
> > > > > > > > > implement std modules without deprecating the system headers. 
> > > > > > > > > This strategy leads the direction to "implement the 
> > > > > > > > > components in the original headers and control their 
> > > > > > > > > visibility in the std module unit".
> > > > > > > > > It may look like:
> > > > > > > > > 
> > > > > > > > > ```
> > > > > > > > > //--- std.cppm
> > > > > > > > > module;
> > > > > > > > > #include 
> > > > > > > > > ...
> > > > > > > > > export module std;
> > > > > > > > > ```
> > > > > > > > > 
> > > > > > > > > Then how can control the visibility?  In my original 
> > > > > > > > > experiments, I use the style:
> > > > > > > > > 
> > > > > > > > > ```
> > > > > > > > > //--- std.cppm
> > > > > > > > > module;
> > > > > > > > > #include 
> > > > > > > > > ...
> > > > > > > > > export module std;
> > > > > > > > > export namespace std {
> > > > > > > > > using std::sort;
> > > > > > > > > }
> > > > > > > > > ```
> > > > > > > > > 
> > > > > > > > > but this doesn't always work. For example, we can't `using` a 
> > > > > > > > > in-class friend definition. And there are more reasons, the 
> > > > > > > > > unreachable declarations in the global module fragment (the 
> > > > > > > > > section from `module;` to `export 

[PATCH] D136568: [Clang] Support constexpr builtin ilogb

2022-10-31 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/test/Sema/constant-builtins-ilogb.cpp:1
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+// expected-no-diagnostics

hubert.reinterpretcast wrote:
> aaron.ballman wrote:
> > hubert.reinterpretcast wrote:
> > > There seems to be no C language test in the patch (although the builtin 
> > > presumably is okay at least as part of arithmetic constant expressions).
> > > 
> > > @aaron.ballman, what are your thoughts re: integer constant expression 
> > > contexts? For example:
> > > ```
> > > struct C { int x : __builtin_ilogb(1. + 1.); };
> > > ```
> > WG14 adopted https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2713.htm for 
> > C2x to clarify that implementations are not allowed to extend what they 
> > consider to be an integer constant expression. The operand in this case is 
> > a function call expression, which is not one of the permissible things in 
> > an ICE, so the standard doesn't want us to make it one.
> > 
> > I believe that Clang's response to that paper is to implement it to the 
> > letter rather than to the intent. e.g., issue a warning that a constant 
> > expression is being folded into an ICE but otherwise accept the code. We 
> > have too many situations already in which we fold a constant expression to 
> > an ICE and changing that behavior would be observable (and a performance 
> > regression). So I think it's fine for us to treat the builtin call as an 
> > ICE so long as we issue a (pedantic) warning about folding it.
> > 
> > (FWIW, I don't think it qualifies as an arithmetic constant expression 
> > because that also doesn't allow function call expressions. But we can 
> > extend the definition of an arithmetic constant expression.)
> Thanks Aaron. I think a C language test for this patch may be a good way to 
> explore the extension space (and any pedantic conformance diagnostics).
> 
> Particular to the example above and ICEs is that the argument involves 
> floating-point operations. Would the desired model be that the call is 
> considered a literal for the purposes of the language requirements?
> 
> It seems that built-ins that are accepted in constant expressions in C are a 
> more general issue though (and I am not sure if, for this patch, we defer the 
> issue for some general approach that would take care of the class of problems 
> as a whole).
> 
> Thanks Aaron. I think a C language test for this patch may be a good way to 
> explore the extension space (and any pedantic conformance diagnostics).

+1, especially because C2x has support for constexpr object definitions (which 
we've not implemented in Clang yet).

> Particular to the example above and ICEs is that the argument involves 
> floating-point operations. Would the desired model be that the call is 
> considered a literal for the purposes of the language requirements?

I think that model makes the most sense to me. If we can compute the correct 
answer at compile time, it seems a bit silly to defer until runtime just 
because the builtin looks like a function call expression.

> It seems that built-ins that are accepted in constant expressions in C are a 
> more general issue though (and I am not sure if, for this patch, we defer the 
> issue for some general approach that would take care of the class of problems 
> as a whole).

Yeah, I think it is a more general issue with builtins in C (and how we handle 
constant expression evaluation in C). I don't think this patch will make the 
problem significantly *worse*, so I think I'd be fine not addressing the 
specific concern for this builtin in this patch. But it would probably make a 
lot of sense for us to fix up the builtin situation before converting a ton of 
math library functions to builtins since all of those are going to have the 
same class of concern.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136568

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


[PATCH] D137054: [X86][Driver] Remove stale FIXME. NFC

2022-10-31 Thread Craig Topper via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG6fa0e3df97ac: [X86][Driver] Remove stale FIXME. NFC 
(authored by craig.topper).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137054

Files:
  clang/lib/Driver/ToolChains/Arch/X86.cpp


Index: clang/lib/Driver/ToolChains/Arch/X86.cpp
===
--- clang/lib/Driver/ToolChains/Arch/X86.cpp
+++ clang/lib/Driver/ToolChains/Arch/X86.cpp
@@ -30,9 +30,6 @@
 
 // FIXME: Reject attempts to use -march=native unless the target matches
 // the host.
-//
-// FIXME: We should also incorporate the detected target features for use
-// with -native.
 CPU = llvm::sys::getHostCPUName();
 if (!CPU.empty() && CPU != "generic")
   return std::string(CPU);


Index: clang/lib/Driver/ToolChains/Arch/X86.cpp
===
--- clang/lib/Driver/ToolChains/Arch/X86.cpp
+++ clang/lib/Driver/ToolChains/Arch/X86.cpp
@@ -30,9 +30,6 @@
 
 // FIXME: Reject attempts to use -march=native unless the target matches
 // the host.
-//
-// FIXME: We should also incorporate the detected target features for use
-// with -native.
 CPU = llvm::sys::getHostCPUName();
 if (!CPU.empty() && CPU != "generic")
   return std::string(CPU);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 6fa0e3d - [X86][Driver] Remove stale FIXME. NFC

2022-10-31 Thread Craig Topper via cfe-commits

Author: Craig Topper
Date: 2022-10-31T10:41:40-07:00
New Revision: 6fa0e3df97ac1280da98bd1bc156dad5e036246b

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

LOG: [X86][Driver] Remove stale FIXME. NFC

We use getHostCPUFeatures in x86::getX86TargetFeatures so I think
this FIXME is taken care of already.

Reviewed By: RKSimon

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/Arch/X86.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Arch/X86.cpp 
b/clang/lib/Driver/ToolChains/Arch/X86.cpp
index 81cccb6d11478..d847db7018252 100644
--- a/clang/lib/Driver/ToolChains/Arch/X86.cpp
+++ b/clang/lib/Driver/ToolChains/Arch/X86.cpp
@@ -30,9 +30,6 @@ std::string x86::getX86TargetCPU(const Driver , const 
ArgList ,
 
 // FIXME: Reject attempts to use -march=native unless the target matches
 // the host.
-//
-// FIXME: We should also incorporate the detected target features for use
-// with -native.
 CPU = llvm::sys::getHostCPUName();
 if (!CPU.empty() && CPU != "generic")
   return std::string(CPU);



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


[PATCH] D136953: [C++20] Diagnose invalid and reserved module names

2022-10-31 Thread Nikolas Klauser via Phabricator via cfe-commits
philnik added inline comments.



Comment at: clang/lib/Sema/SemaModule.cpp:282
+  StringRef FirstComponentName = Path[0].first->getName();
+  if (!getSourceManager().isInSystemHeader(Path[0].second) &&
+  (FirstComponentName == "std" ||

aaron.ballman wrote:
> philnik wrote:
> > ChuanqiXu wrote:
> > > aaron.ballman wrote:
> > > > aaron.ballman wrote:
> > > > > ChuanqiXu wrote:
> > > > > > erichkeane wrote:
> > > > > > > ChuanqiXu wrote:
> > > > > > > > aaron.ballman wrote:
> > > > > > > > > ChuanqiXu wrote:
> > > > > > > > > > cor3ntin wrote:
> > > > > > > > > > > ChuanqiXu wrote:
> > > > > > > > > > > > std modules should be irreverent with system headers; 
> > > > > > > > > > > > The intuition of the wording should be that the users 
> > > > > > > > > > > > can't declare modules like `std` or `std.compat` to 
> > > > > > > > > > > > avoid possible conflicting. The approach I imaged may 
> > > > > > > > > > > > be add a new compilation flags (call it 
> > > > > > > > > > > > `-fstd-modules`) now. And if the compiler found a `std` 
> > > > > > > > > > > > module declaration without `-fstd-modules`, emit an 
> > > > > > > > > > > > error.  
> > > > > > > > > > > > 
> > > > > > > > > > > > For now, I think we can skip the check for 
> > > > > > > > > > > > `-fstd-modules` and add it back when we starts to 
> > > > > > > > > > > > support std modules actually.
> > > > > > > > > > > The idea is that standard modules are built from system 
> > > > > > > > > > > directories... it seems a better heuristic than adding a 
> > > > > > > > > > > flag for the purpose of 1 diagnostics ( maybe some other 
> > > > > > > > > > > system library could in theory export std with no 
> > > > > > > > > > > warning, but I'm not super worried about that being a 
> > > > > > > > > > > concern in practice)
> > > > > > > > > > > The idea is that standard modules are built from system 
> > > > > > > > > > > directories...
> > > > > > > > > > 
> > > > > > > > > > This is not true. For example, if someday libc++ supports 
> > > > > > > > > > std modules, then we need to build the std modules in our 
> > > > > > > > > > working directory, which is not system directories. And 
> > > > > > > > > > **ideally**, we would distribute and install module file in 
> > > > > > > > > > the system directories. But it is irreverent with the path 
> > > > > > > > > > of the source file.
> > > > > > > > > > then we need to build the std modules in our working 
> > > > > > > > > > directory, which is not system directories.
> > > > > > > > > 
> > > > > > > > > `-isystem`, pragmas, and linemarkers are all ways around that 
> > > > > > > > > -- I don't think we need a feature flag for this, unless I'm 
> > > > > > > > > misunderstanding something.
> > > > > > > > Although it may be a little bit nit picker, the module unit 
> > > > > > > > which declares the std modules won't be header. It is a module 
> > > > > > > > unit. So it requires we implement std modules by wrapping 
> > > > > > > > linemarkers around the std modules declaration, which looks a 
> > > > > > > > little bit overkill.
> > > > > > > > 
> > > > > > > > And another point is that maybe we need to introduce another 
> > > > > > > > feature flags to implement std modules. Although I tried to 
> > > > > > > > implement std modules within the current features, I can't 
> > > > > > > > prove we can implement std modules in that way in the end of 
> > > > > > > > the day.
> > > > > > > > 
> > > > > > > > Let me add some more words. The standards require us to 
> > > > > > > > implement std modules without deprecating the system headers. 
> > > > > > > > This strategy leads the direction to "implement the components 
> > > > > > > > in the original headers and control their visibility in the std 
> > > > > > > > module unit".
> > > > > > > > It may look like:
> > > > > > > > 
> > > > > > > > ```
> > > > > > > > //--- std.cppm
> > > > > > > > module;
> > > > > > > > #include 
> > > > > > > > ...
> > > > > > > > export module std;
> > > > > > > > ```
> > > > > > > > 
> > > > > > > > Then how can control the visibility?  In my original 
> > > > > > > > experiments, I use the style:
> > > > > > > > 
> > > > > > > > ```
> > > > > > > > //--- std.cppm
> > > > > > > > module;
> > > > > > > > #include 
> > > > > > > > ...
> > > > > > > > export module std;
> > > > > > > > export namespace std {
> > > > > > > > using std::sort;
> > > > > > > > }
> > > > > > > > ```
> > > > > > > > 
> > > > > > > > but this doesn't always work. For example, we can't `using` a 
> > > > > > > > in-class friend definition. And there are more reasons, the 
> > > > > > > > unreachable declarations in the global module fragment (the 
> > > > > > > > section from `module;` to `export module [module_name]`) can be 
> > > > > > > > discarded to reduce the size of the module file. And the 
> > > > > > > > reachable rules are complex. But the simple story is that it is 
> > > > > > > > 

Re: [clang] a88ebd4 - Revert "[clang] Instantiate NTTPs and template default arguments with sugar"

2022-10-31 Thread Matheus Izvekov via cfe-commits
Sure. The original reason was for a pre-existing problem uncovered in
a dependent patch (broken canonicalization of NTTPs), which the
underlying issue has been fixed, and then this was merged and reverted
again, for a different pre-existing bug with this patch made worse.
That bug has been fixed by edf1a2e89340c8fa64a679e7d4ec2b5ee92ec40f,
so this patch is merged again.

On Mon, Oct 31, 2022 at 6:14 PM David Blaikie  wrote:
>
> Please include some details about the reason for a revert in the
> revert commit message in addition to the precanned revision/subject
> quoting
>
> On Wed, Oct 26, 2022 at 1:16 AM Matheus Izvekov via cfe-commits
>  wrote:
> >
> >
> > Author: Matheus Izvekov
> > Date: 2022-10-26T10:14:27+02:00
> > New Revision: a88ebd405da67b4cebf094c5a56f9aed97875423
> >
> > URL: 
> > https://github.com/llvm/llvm-project/commit/a88ebd405da67b4cebf094c5a56f9aed97875423
> > DIFF: 
> > https://github.com/llvm/llvm-project/commit/a88ebd405da67b4cebf094c5a56f9aed97875423.diff
> >
> > LOG: Revert "[clang] Instantiate NTTPs and template default arguments with 
> > sugar"
> >
> > This reverts commit 2560c1266993af6e6c15900ce673c6db23132f8b.
> >
> > Added:
> >
> >
> > Modified:
> > clang/include/clang/Sema/Sema.h
> > clang/lib/Sema/SemaTemplate.cpp
> > clang/lib/Sema/SemaTemplateDeduction.cpp
> > clang/test/AST/ast-dump-template-decls.cpp
> > clang/test/CXX/drs/dr3xx.cpp
> > clang/test/CXX/expr/expr.const/p3-0x.cpp
> > clang/test/Misc/diag-template-diffing.cpp
> > clang/test/SemaTemplate/instantiation-default-1.cpp
> > clang/test/SemaTemplate/make_integer_seq.cpp
> >
> > Removed:
> >
> >
> >
> > 
> > diff  --git a/clang/include/clang/Sema/Sema.h 
> > b/clang/include/clang/Sema/Sema.h
> > index 37ad78f3d7969..d0757f874303f 100644
> > --- a/clang/include/clang/Sema/Sema.h
> > +++ b/clang/include/clang/Sema/Sema.h
> > @@ -8199,11 +8199,14 @@ class Sema final {
> >  SourceLocation TemplateLoc,
> >  Declarator );
> >
> > -  TemplateArgumentLoc SubstDefaultTemplateArgumentIfAvailable(
> > -  TemplateDecl *Template, SourceLocation TemplateLoc,
> > -  SourceLocation RAngleLoc, Decl *Param,
> > -  ArrayRef SugaredConverted,
> > -  ArrayRef CanonicalConverted, bool );
> > +  TemplateArgumentLoc
> > +  SubstDefaultTemplateArgumentIfAvailable(TemplateDecl *Template,
> > +  SourceLocation TemplateLoc,
> > +  SourceLocation RAngleLoc,
> > +  Decl *Param,
> > +  SmallVectorImpl
> > +,
> > +  bool );
> >
> >/// Specifies the context in which a particular template
> >/// argument is being checked.
> >
> > diff  --git a/clang/lib/Sema/SemaTemplate.cpp 
> > b/clang/lib/Sema/SemaTemplate.cpp
> > index 37eaa2a5795aa..73c681035b161 100644
> > --- a/clang/lib/Sema/SemaTemplate.cpp
> > +++ b/clang/lib/Sema/SemaTemplate.cpp
> > @@ -5261,25 +5261,27 @@ bool Sema::CheckTemplateTypeArgument(
> >  /// \param Converted the list of template arguments provided for template
> >  /// parameters that precede \p Param in the template parameter list.
> >  /// \returns the substituted template argument, or NULL if an error 
> > occurred.
> > -static TypeSourceInfo *SubstDefaultTemplateArgument(
> > -Sema , TemplateDecl *Template, SourceLocation TemplateLoc,
> > -SourceLocation RAngleLoc, TemplateTypeParmDecl *Param,
> > -ArrayRef SugaredConverted,
> > -ArrayRef CanonicalConverted) {
> > +static TypeSourceInfo *
> > +SubstDefaultTemplateArgument(Sema ,
> > + TemplateDecl *Template,
> > + SourceLocation TemplateLoc,
> > + SourceLocation RAngleLoc,
> > + TemplateTypeParmDecl *Param,
> > + SmallVectorImpl ) 
> > {
> >TypeSourceInfo *ArgType = Param->getDefaultArgumentInfo();
> >
> >// If the argument type is dependent, instantiate it now based
> >// on the previously-computed template arguments.
> >if (ArgType->getType()->isInstantiationDependentType()) {
> > -Sema::InstantiatingTemplate Inst(SemaRef, TemplateLoc, Param, Template,
> > - SugaredConverted,
> > +Sema::InstantiatingTemplate Inst(SemaRef, TemplateLoc,
> > + Param, Template, Converted,
> >   SourceRange(TemplateLoc, RAngleLoc));
> >  if (Inst.isInvalid())
> >return nullptr;
> >
> >  // Only substitute for the innermost template argument list.
> > -MultiLevelTemplateArgumentList TemplateArgLists(Template, 
> > SugaredConverted,
> 

[PATCH] D121593: [clangd][WIP] Provide clang-include-cleaner

2022-10-31 Thread Andi via Phabricator via cfe-commits
Abpostelnicu added a comment.

@sammccall was there any progress on this so far? This would be really useful 
to be a clang-tidy check.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121593

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


[PATCH] D136554: Implement CWG2631

2022-10-31 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/include/clang/AST/ExprCXX.h:1315
+  // Retrieve the rewritten init expression (for an init expression containing
+  // immediate calls) With the top level FullExpr and ConstantExpr stripped 
off.
+  const Expr *getAdjustedRewrittenExpr() const;





Comment at: clang/include/clang/Sema/Sema.h:1349-1350
+  DeclContext *Context = nullptr;
+
+  bool isValid() const { return Decl != nullptr; }
+};

This can now be removed as it's unused.



Comment at: clang/lib/AST/ExprCXX.cpp:991-999
+Expr *CXXDefaultArgExpr::getAdjustedRewrittenExpr() {
+  assert(hasRewrittenInit() &&
+ "expected this CXXDefaultArgExpr to have a rewritten init.");
+  Expr *Init = getRewrittenExpr();
+  if (auto *E = dyn_cast_if_present(Init))
+if (!isa(E))
+  return E->getSubExpr();

Rather than duplicate the logic, we usually lean on the fact that we can cast 
away const on any AST node because they're all dynamically allocated (and thus 
are not const on the object's first definition).

I think the const version of this function should be written to dispatch to the 
non-const version (inline in the header file): `return 
const_cast(this)->getAdjustedRewrittenExpr();` -- then we 
avoid the risk of updating one method and forgetting to update the other.



Comment at: clang/lib/AST/ExprCXX.cpp:1042
+/// Get the initialization expression that will be used.
+const Expr *CXXDefaultInitExpr::getExpr() const {
+  assert(Field->getInClassInitializer() && "initializer hasn't been parsed");

Same suggestion here as above.



Comment at: clang/test/CodeGenCXX/default-arguments-with-immediate.cpp:2-3
+// RUN: %clang_cc1 -std=c++2a -triple x86_64-elf-gnu %s -emit-llvm -o - | 
FileCheck %s
+
+
+consteval int immediate() { return 0;}





Comment at: clang/test/CodeGenCXX/default-arguments-with-immediate.cpp:22
+
+// CHECK: define {{.*}} i32 @_ZL3extv()
+

cor3ntin wrote:
> aaron.ballman wrote:
> > Move this check line up to where ext is declared?
> I moved it after `test_function`, which where it is defined, because it is a 
> static function, it is only defined if odr used, and only odr used if the 
> parameter is defaulted.
Ah, okay, that makes sense then.



Comment at: clang/test/SemaCXX/cxx2a-consteval-default-params.cpp:3-4
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++2b %s
+
+
+consteval int undefined();  // expected-note 4 {{declared here}}




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136554

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


[clang] 06f640d - [X86] Enable EVEX GFNI instructions without avx512bw.

2022-10-31 Thread Craig Topper via cfe-commits

Author: Craig Topper
Date: 2022-10-31T10:31:45-07:00
New Revision: 06f640d3fb060e2e9cfed1d7c44636c7ffe3308b

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

LOG: [X86] Enable EVEX GFNI instructions without avx512bw.

We only really need avx512bw for masking 256 or 512 bit GFNI
instructions due to the need for v32i1 or v64i1.

I wanted to enable 128-bit intrinsics with avx512vl, but the
__builtin_ia32_selectb_128 used in the header file requires avx512bw.
The codegen test for the same is also not using a masked instruction
because vselect with v16i1 mask and v16i8 is not legal so is expanded
before isel. To fix these issues we need a mask specific builtin and a
mask specific ISD opcode.

Fixes PR58687.

Reviewed By: pengfei

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

Added: 


Modified: 
clang/include/clang/Basic/BuiltinsX86.def
clang/lib/Headers/gfniintrin.h
clang/test/CodeGen/X86/gfni-builtins.c
llvm/lib/Target/X86/X86InstrAVX512.td
llvm/lib/Target/X86/X86InstrSSE.td
llvm/test/CodeGen/X86/avx512-gfni-intrinsics.ll

Removed: 




diff  --git a/clang/include/clang/Basic/BuiltinsX86.def 
b/clang/include/clang/Basic/BuiltinsX86.def
index fff7d58fb0d3c..c94c5b3d2f7dd 100644
--- a/clang/include/clang/Basic/BuiltinsX86.def
+++ b/clang/include/clang/Basic/BuiltinsX86.def
@@ -432,13 +432,13 @@ TARGET_BUILTIN(__builtin_ia32_aesdeclast512, 
"V8OiV8OiV8Oi", "ncV:512:", "avx512
 // GFNI
 TARGET_BUILTIN(__builtin_ia32_vgf2p8affineinvqb_v16qi, "V16cV16cV16cIc", 
"ncV:128:", "gfni")
 TARGET_BUILTIN(__builtin_ia32_vgf2p8affineinvqb_v32qi, "V32cV32cV32cIc", 
"ncV:256:", "avx,gfni")
-TARGET_BUILTIN(__builtin_ia32_vgf2p8affineinvqb_v64qi, "V64cV64cV64cIc", 
"ncV:512:", "avx512bw,gfni")
+TARGET_BUILTIN(__builtin_ia32_vgf2p8affineinvqb_v64qi, "V64cV64cV64cIc", 
"ncV:512:", "avx512f,gfni")
 TARGET_BUILTIN(__builtin_ia32_vgf2p8affineqb_v16qi, "V16cV16cV16cIc", 
"ncV:128:", "gfni")
 TARGET_BUILTIN(__builtin_ia32_vgf2p8affineqb_v32qi, "V32cV32cV32cIc", 
"ncV:256:", "avx,gfni")
-TARGET_BUILTIN(__builtin_ia32_vgf2p8affineqb_v64qi, "V64cV64cV64cIc", 
"ncV:512:", "avx512bw,gfni")
+TARGET_BUILTIN(__builtin_ia32_vgf2p8affineqb_v64qi, "V64cV64cV64cIc", 
"ncV:512:", "avx512f,gfni")
 TARGET_BUILTIN(__builtin_ia32_vgf2p8mulb_v16qi, "V16cV16cV16c", "ncV:128:", 
"gfni")
 TARGET_BUILTIN(__builtin_ia32_vgf2p8mulb_v32qi, "V32cV32cV32c", "ncV:256:", 
"avx,gfni")
-TARGET_BUILTIN(__builtin_ia32_vgf2p8mulb_v64qi, "V64cV64cV64c", "ncV:512:", 
"avx512bw,gfni")
+TARGET_BUILTIN(__builtin_ia32_vgf2p8mulb_v64qi, "V64cV64cV64c", "ncV:512:", 
"avx512f,gfni")
 
 // CLMUL
 TARGET_BUILTIN(__builtin_ia32_pclmulqdq128, "V2OiV2OiV2OiIc", "ncV:128:", 
"pclmul")

diff  --git a/clang/lib/Headers/gfniintrin.h b/clang/lib/Headers/gfniintrin.h
index a59238b0b1319..5ec53c54fc4ec 100644
--- a/clang/lib/Headers/gfniintrin.h
+++ b/clang/lib/Headers/gfniintrin.h
@@ -20,10 +20,12 @@
 /* Default attributes for YMM unmasked form. */
 #define __DEFAULT_FN_ATTRS_Y __attribute__((__always_inline__, __nodebug__, 
__target__("avx,gfni"), __min_vector_width__(256)))
 
-/* Default attributes for ZMM forms. */
-#define __DEFAULT_FN_ATTRS_Z __attribute__((__always_inline__, __nodebug__, 
__target__("avx512bw,gfni"), __min_vector_width__(512)))
+/* Default attributes for ZMM unmasked forms. */
+#define __DEFAULT_FN_ATTRS_Z __attribute__((__always_inline__, __nodebug__, 
__target__("avx512f,gfni"), __min_vector_width__(512)))
+/* Default attributes for ZMM masked forms. */
+#define __DEFAULT_FN_ATTRS_Z_MASK __attribute__((__always_inline__, 
__nodebug__, __target__("avx512bw,gfni"), __min_vector_width__(512)))
 
-/* Default attributes for VLX forms. */
+/* Default attributes for VLX masked forms. */
 #define __DEFAULT_FN_ATTRS_VL128 __attribute__((__always_inline__, 
__nodebug__, __target__("avx512bw,avx512vl,gfni"), __min_vector_width__(128)))
 #define __DEFAULT_FN_ATTRS_VL256 __attribute__((__always_inline__, 
__nodebug__, __target__("avx512bw,avx512vl,gfni"), __min_vector_width__(256)))
 
@@ -99,7 +101,7 @@ _mm512_gf2p8mul_epi8(__m512i __A, __m512i __B)
   (__v64qi) __B);
 }
 
-static __inline__ __m512i __DEFAULT_FN_ATTRS_Z
+static __inline__ __m512i __DEFAULT_FN_ATTRS_Z_MASK
 _mm512_mask_gf2p8mul_epi8(__m512i __S, __mmask64 __U, __m512i __A, __m512i __B)
 {
   return (__m512i) __builtin_ia32_selectb_512(__U,
@@ -107,7 +109,7 @@ _mm512_mask_gf2p8mul_epi8(__m512i __S, __mmask64 __U, 
__m512i __A, __m512i __B)
   (__v64qi) __S);
 }
 
-static __inline__ __m512i __DEFAULT_FN_ATTRS_Z
+static __inline__ __m512i __DEFAULT_FN_ATTRS_Z_MASK
 _mm512_maskz_gf2p8mul_epi8(__mmask64 __U, __m512i __A, __m512i __B)
 {
   return _mm512_mask_gf2p8mul_epi8((__m512i)_mm512_setzero_si512(),

diff  --git 

[PATCH] D137036: [X86] Enable EVEX GFNI instructions without avx512bw.

2022-10-31 Thread Craig Topper 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 rG06f640d3fb06: [X86] Enable EVEX GFNI instructions without 
avx512bw. (authored by craig.topper).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137036

Files:
  clang/include/clang/Basic/BuiltinsX86.def
  clang/lib/Headers/gfniintrin.h
  clang/test/CodeGen/X86/gfni-builtins.c
  llvm/lib/Target/X86/X86InstrAVX512.td
  llvm/lib/Target/X86/X86InstrSSE.td
  llvm/test/CodeGen/X86/avx512-gfni-intrinsics.ll

Index: llvm/test/CodeGen/X86/avx512-gfni-intrinsics.ll
===
--- llvm/test/CodeGen/X86/avx512-gfni-intrinsics.ll
+++ llvm/test/CodeGen/X86/avx512-gfni-intrinsics.ll
@@ -1,28 +1,58 @@
 ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
-; RUN: llc < %s -mtriple=i686-unknown-unknown -mattr=+avx512vl,+gfni,+avx512bw --show-mc-encoding | FileCheck %s --check-prefixes=CHECK,X86
-; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+avx512vl,+gfni,+avx512bw --show-mc-encoding | FileCheck %s --check-prefixes=CHECK,X64
+; RUN: llc < %s -mtriple=i686-unknown-unknown -mattr=+avx512vl,+gfni,+avx512bw --show-mc-encoding | FileCheck %s --check-prefixes=CHECK,X86BW
+; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+avx512vl,+gfni,+avx512bw --show-mc-encoding | FileCheck %s --check-prefixes=CHECK,X64BW
+; RUN: llc < %s -mtriple=i686-unknown-unknown -mattr=+avx512vl,+gfni --show-mc-encoding | FileCheck %s --check-prefixes=CHECK,X86NOBW
+; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+avx512vl,+gfni --show-mc-encoding | FileCheck %s --check-prefixes=CHECK,X64NOBW
 
 declare <16 x i8> @llvm.x86.vgf2p8affineinvqb.128(<16 x i8>, <16 x i8>, i8)
 define { <16 x i8>, <16 x i8>, <16 x i8> } @test_vgf2p8affineinvqb_128(<16 x i8> %src1, <16 x i8> %src2, <16 x i8> %passthru, i16 %mask) {
-; X86-LABEL: test_vgf2p8affineinvqb_128:
-; X86:   # %bb.0:
-; X86-NEXT:kmovw {{[0-9]+}}(%esp), %k1 # encoding: [0xc5,0xf8,0x90,0x4c,0x24,0x04]
-; X86-NEXT:vgf2p8affineinvqb $3, %xmm1, %xmm0, %xmm3 # EVEX TO VEX Compression encoding: [0xc4,0xe3,0xf9,0xcf,0xd9,0x03]
-; X86-NEXT:vgf2p8affineinvqb $4, %xmm1, %xmm0, %xmm4 {%k1} {z} # encoding: [0x62,0xf3,0xfd,0x89,0xcf,0xe1,0x04]
-; X86-NEXT:vgf2p8affineinvqb $5, %xmm1, %xmm0, %xmm2 {%k1} # encoding: [0x62,0xf3,0xfd,0x09,0xcf,0xd1,0x05]
-; X86-NEXT:vmovdqa %xmm3, %xmm0 # EVEX TO VEX Compression encoding: [0xc5,0xf9,0x6f,0xc3]
-; X86-NEXT:vmovdqa %xmm4, %xmm1 # EVEX TO VEX Compression encoding: [0xc5,0xf9,0x6f,0xcc]
-; X86-NEXT:retl # encoding: [0xc3]
-;
-; X64-LABEL: test_vgf2p8affineinvqb_128:
-; X64:   # %bb.0:
-; X64-NEXT:kmovd %edi, %k1 # encoding: [0xc5,0xfb,0x92,0xcf]
-; X64-NEXT:vgf2p8affineinvqb $3, %xmm1, %xmm0, %xmm3 # EVEX TO VEX Compression encoding: [0xc4,0xe3,0xf9,0xcf,0xd9,0x03]
-; X64-NEXT:vgf2p8affineinvqb $4, %xmm1, %xmm0, %xmm4 {%k1} {z} # encoding: [0x62,0xf3,0xfd,0x89,0xcf,0xe1,0x04]
-; X64-NEXT:vgf2p8affineinvqb $5, %xmm1, %xmm0, %xmm2 {%k1} # encoding: [0x62,0xf3,0xfd,0x09,0xcf,0xd1,0x05]
-; X64-NEXT:vmovdqa %xmm3, %xmm0 # EVEX TO VEX Compression encoding: [0xc5,0xf9,0x6f,0xc3]
-; X64-NEXT:vmovdqa %xmm4, %xmm1 # EVEX TO VEX Compression encoding: [0xc5,0xf9,0x6f,0xcc]
-; X64-NEXT:retq # encoding: [0xc3]
+; X86BW-LABEL: test_vgf2p8affineinvqb_128:
+; X86BW:   # %bb.0:
+; X86BW-NEXT:kmovw {{[0-9]+}}(%esp), %k1 # encoding: [0xc5,0xf8,0x90,0x4c,0x24,0x04]
+; X86BW-NEXT:vgf2p8affineinvqb $3, %xmm1, %xmm0, %xmm3 # EVEX TO VEX Compression encoding: [0xc4,0xe3,0xf9,0xcf,0xd9,0x03]
+; X86BW-NEXT:vgf2p8affineinvqb $4, %xmm1, %xmm0, %xmm4 {%k1} {z} # encoding: [0x62,0xf3,0xfd,0x89,0xcf,0xe1,0x04]
+; X86BW-NEXT:vgf2p8affineinvqb $5, %xmm1, %xmm0, %xmm2 {%k1} # encoding: [0x62,0xf3,0xfd,0x09,0xcf,0xd1,0x05]
+; X86BW-NEXT:vmovdqa %xmm3, %xmm0 # EVEX TO VEX Compression encoding: [0xc5,0xf9,0x6f,0xc3]
+; X86BW-NEXT:vmovdqa %xmm4, %xmm1 # EVEX TO VEX Compression encoding: [0xc5,0xf9,0x6f,0xcc]
+; X86BW-NEXT:retl # encoding: [0xc3]
+;
+; X64BW-LABEL: test_vgf2p8affineinvqb_128:
+; X64BW:   # %bb.0:
+; X64BW-NEXT:kmovd %edi, %k1 # encoding: [0xc5,0xfb,0x92,0xcf]
+; X64BW-NEXT:vgf2p8affineinvqb $3, %xmm1, %xmm0, %xmm3 # EVEX TO VEX Compression encoding: [0xc4,0xe3,0xf9,0xcf,0xd9,0x03]
+; X64BW-NEXT:vgf2p8affineinvqb $4, %xmm1, %xmm0, %xmm4 {%k1} {z} # encoding: [0x62,0xf3,0xfd,0x89,0xcf,0xe1,0x04]
+; X64BW-NEXT:vgf2p8affineinvqb $5, %xmm1, %xmm0, %xmm2 {%k1} # encoding: [0x62,0xf3,0xfd,0x09,0xcf,0xd1,0x05]
+; X64BW-NEXT:vmovdqa %xmm3, %xmm0 # EVEX TO VEX Compression encoding: [0xc5,0xf9,0x6f,0xc3]
+; X64BW-NEXT:vmovdqa %xmm4, %xmm1 # EVEX TO VEX Compression encoding: [0xc5,0xf9,0x6f,0xcc]
+; X64BW-NEXT:retq # encoding: [0xc3]
+;
+; 

[PATCH] D136930: [RISCV] Support -mcpu/mtune=native

2022-10-31 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:2190
 CmdArgs.push_back("-tune-cpu");
-CmdArgs.push_back(A->getValue());
+if (strcmp(A->getValue(), "native") == 0)
+  CmdArgs.push_back(Args.MakeArgString(llvm::sys::getHostCPUName()));

kito-cheng wrote:
> pcwang-thead wrote:
> > craig.topper wrote:
> > > Why can't we use A->getValue() == "native" here?
> > Because newly-changed support of other targets (like PowerPC) are in this 
> > form, so I think this may benefit from simplification?
> A->getValue return `const char *` rather than StringRef? maybe we could use 
> `StringRef(A->getValue()) == "native"` like X86 to improve that?
> 
> https://llvm.org/doxygen/classllvm_1_1opt_1_1Arg.html
> 
> grep result from clang folder:
> ```
> $ grpe "\"native\"" * -R
> lib/Driver/ToolChains/Clang.cpp:if (strcmp(A->getValue(), "native") == 0)
> lib/Driver/ToolChains/Clang.cpp:if (strcmp(A->getValue(), "native") == 0)
> lib/Driver/ToolChains/Clang.cpp:if (Name == "native")
> lib/Driver/ToolChains/Clang.cpp:if (strcmp(A->getValue(), "native") == 0)
> lib/Driver/ToolChains/Clang.cpp:if (Name == "native") {
> lib/Driver/ToolChains/CommonArgs.cpp:// Handle "native" by examining the 
> host. "native" isn't meaningful when
> lib/Driver/ToolChains/CommonArgs.cpp:if (CPU == "native")
> lib/Driver/ToolChains/Arch/SystemZ.cpp:if (CPUName == "native") {
> lib/Driver/ToolChains/Arch/X86.cpp:if (CPU != "native")
> lib/Driver/ToolChains/Arch/X86.cpp:if (StringRef(A->getValue()) == 
> "native") {
> lib/Driver/ToolChains/Arch/PPC.cpp:if (CPUName == "native") {
> lib/Driver/ToolChains/Arch/AArch64.cpp:  if (CPU == "native")
> lib/Driver/ToolChains/Arch/AArch64.cpp:  if (CPU == "native")
> lib/Driver/ToolChains/Arch/AArch64.cpp:  if (Split.first == "native")
> lib/Driver/ToolChains/Arch/AArch64.cpp:  if (MtuneLowerCase == "native")
> lib/Driver/ToolChains/Arch/Sparc.cpp:if (CPUName == "native") {
> lib/Driver/ToolChains/Arch/ARM.cpp:  if (CPUName == "native") {
> lib/Driver/ToolChains/Arch/ARM.cpp:  if (MArch == "native") {
> lib/Driver/ToolChains/Arch/ARM.cpp:if (MCPU == "native")
> lib/Driver/ToolChains/Arch/M68k.cpp:if (CPUName == "native") {
> ```
Thanks. I guess strcmp makes sense then to avoid an implicit call to strlen in 
the StringRef constructor.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136930

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


[PATCH] D137077: [Diagnostic] Clarify -Winfinite-recursion message

2022-10-31 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D137077#3896561 , @merrymeerkat 
wrote:

> In D137077#3896369 , @aaron.ballman 
> wrote:
>
>> Thank you for the patch! However, I think this isn't an improvement to the 
>> diagnostic -- it's a cute phrase, but it doesn't help the programmer to 
>> understand what about their code needs to change.
>
> Hi Aaron! Agreed--thank you for the review! I was just following a tutorial 
> on how to make changes to LLVM, so this was not a real code review :)
> Cheers!

Ahhh, that makes a lot more sense, thank for letting me know! (This is like the 
fourth time I've seen someone submit these same changes and I was confused as 
to why this was such a popular attempted modification, lol.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137077

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


Re: [clang] a88ebd4 - Revert "[clang] Instantiate NTTPs and template default arguments with sugar"

2022-10-31 Thread David Blaikie via cfe-commits
Please include some details about the reason for a revert in the
revert commit message in addition to the precanned revision/subject
quoting

On Wed, Oct 26, 2022 at 1:16 AM Matheus Izvekov via cfe-commits
 wrote:
>
>
> Author: Matheus Izvekov
> Date: 2022-10-26T10:14:27+02:00
> New Revision: a88ebd405da67b4cebf094c5a56f9aed97875423
>
> URL: 
> https://github.com/llvm/llvm-project/commit/a88ebd405da67b4cebf094c5a56f9aed97875423
> DIFF: 
> https://github.com/llvm/llvm-project/commit/a88ebd405da67b4cebf094c5a56f9aed97875423.diff
>
> LOG: Revert "[clang] Instantiate NTTPs and template default arguments with 
> sugar"
>
> This reverts commit 2560c1266993af6e6c15900ce673c6db23132f8b.
>
> Added:
>
>
> Modified:
> clang/include/clang/Sema/Sema.h
> clang/lib/Sema/SemaTemplate.cpp
> clang/lib/Sema/SemaTemplateDeduction.cpp
> clang/test/AST/ast-dump-template-decls.cpp
> clang/test/CXX/drs/dr3xx.cpp
> clang/test/CXX/expr/expr.const/p3-0x.cpp
> clang/test/Misc/diag-template-diffing.cpp
> clang/test/SemaTemplate/instantiation-default-1.cpp
> clang/test/SemaTemplate/make_integer_seq.cpp
>
> Removed:
>
>
>
> 
> diff  --git a/clang/include/clang/Sema/Sema.h 
> b/clang/include/clang/Sema/Sema.h
> index 37ad78f3d7969..d0757f874303f 100644
> --- a/clang/include/clang/Sema/Sema.h
> +++ b/clang/include/clang/Sema/Sema.h
> @@ -8199,11 +8199,14 @@ class Sema final {
>  SourceLocation TemplateLoc,
>  Declarator );
>
> -  TemplateArgumentLoc SubstDefaultTemplateArgumentIfAvailable(
> -  TemplateDecl *Template, SourceLocation TemplateLoc,
> -  SourceLocation RAngleLoc, Decl *Param,
> -  ArrayRef SugaredConverted,
> -  ArrayRef CanonicalConverted, bool );
> +  TemplateArgumentLoc
> +  SubstDefaultTemplateArgumentIfAvailable(TemplateDecl *Template,
> +  SourceLocation TemplateLoc,
> +  SourceLocation RAngleLoc,
> +  Decl *Param,
> +  SmallVectorImpl
> +,
> +  bool );
>
>/// Specifies the context in which a particular template
>/// argument is being checked.
>
> diff  --git a/clang/lib/Sema/SemaTemplate.cpp 
> b/clang/lib/Sema/SemaTemplate.cpp
> index 37eaa2a5795aa..73c681035b161 100644
> --- a/clang/lib/Sema/SemaTemplate.cpp
> +++ b/clang/lib/Sema/SemaTemplate.cpp
> @@ -5261,25 +5261,27 @@ bool Sema::CheckTemplateTypeArgument(
>  /// \param Converted the list of template arguments provided for template
>  /// parameters that precede \p Param in the template parameter list.
>  /// \returns the substituted template argument, or NULL if an error occurred.
> -static TypeSourceInfo *SubstDefaultTemplateArgument(
> -Sema , TemplateDecl *Template, SourceLocation TemplateLoc,
> -SourceLocation RAngleLoc, TemplateTypeParmDecl *Param,
> -ArrayRef SugaredConverted,
> -ArrayRef CanonicalConverted) {
> +static TypeSourceInfo *
> +SubstDefaultTemplateArgument(Sema ,
> + TemplateDecl *Template,
> + SourceLocation TemplateLoc,
> + SourceLocation RAngleLoc,
> + TemplateTypeParmDecl *Param,
> + SmallVectorImpl ) {
>TypeSourceInfo *ArgType = Param->getDefaultArgumentInfo();
>
>// If the argument type is dependent, instantiate it now based
>// on the previously-computed template arguments.
>if (ArgType->getType()->isInstantiationDependentType()) {
> -Sema::InstantiatingTemplate Inst(SemaRef, TemplateLoc, Param, Template,
> - SugaredConverted,
> +Sema::InstantiatingTemplate Inst(SemaRef, TemplateLoc,
> + Param, Template, Converted,
>   SourceRange(TemplateLoc, RAngleLoc));
>  if (Inst.isInvalid())
>return nullptr;
>
>  // Only substitute for the innermost template argument list.
> -MultiLevelTemplateArgumentList TemplateArgLists(Template, 
> SugaredConverted,
> -/*Final=*/true);
> +MultiLevelTemplateArgumentList TemplateArgLists(Template, Converted,
> +/*Final=*/false);
>  for (unsigned i = 0, e = Param->getDepth(); i != e; ++i)
>TemplateArgLists.addOuterTemplateArguments(None);
>
> @@ -5318,20 +5320,22 @@ static TypeSourceInfo *SubstDefaultTemplateArgument(
>  /// parameters that precede \p Param in the template parameter list.
>  ///
>  /// \returns the substituted template argument, or NULL if an error occurred.
> -static ExprResult SubstDefaultTemplateArgument(
> -Sema , 

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

2022-10-31 Thread John McIver via Phabricator via cfe-commits
jmciver added inline comments.



Comment at: clang/lib/CodeGen/CGExpr.cpp:676
+namespace {
+void applyNoundefToLoadInst(bool enable, const clang::QualType ,
+llvm::LoadInst *Load) {

tschuett wrote:
> Nit: You meant static.
Thank you for bringing that to my attention. I reviewed the [[ 
https://llvm.org/docs/CodingStandards.html#anonymous-namespaces | LLVM Coding 
Standards ]] guidance on the topic.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134410

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


[PATCH] D136786: Fix `unsafe-fp-math` attribute emission.

2022-10-31 Thread Andy Kaylor via Phabricator via cfe-commits
andrew.w.kaylor added a comment.

In D136786#3893559 , 
@michele.scandale wrote:

> The fact that `"unsafe-fp-math"="true"` implies `-ffp-contract=fast` is quite 
> unfortunate, and it is something that in principle should be addressed.
> My understanding is that the floating point math function attributes are a 
> quite old concept that predates the per-instruction fast-math flags. Ideally 
> we should get rid of the flooding point math function attribute since we do 
> have a finer grain representation.
> A while back the main issue was that all the backends code (e.g. DAGCombiner) 
> were only using the `TargetOptions` properties (hence the function 
> attributes) to control the floating point related transformations, hence 
> there would have been regressions.

Yes, the function attributes are a vestige of the time before the fast-math 
flags were introduced, but the use of them hasn't been entirely eliminated and 
I think there are a couple of cases where some people think it's necessary. I 
posted an RFC and a patch about a year ago to start cleaning this up, but I got 
pulled away before it landed and honestly I had forgotten about it. 
https://discourse.llvm.org/t/rfc-eliminating-non-ir-floating-point-controls-in-the-selection-dag/59173

> At high level, I think that we need to understand how important is to match 
> GCC behavior in this particular case. We can change the way Clang defines 
> `-funsafe-math-optimizations` to imply `-ffp-contract=fast`, but that seems 
> the wrong solution as it feels like promoting a bug to a feature.

I wouldn't consider the fact that unsafe-fp-math (as a concept) implies 
fp-contract=fast to be a bug. Yes, it may appear to deviate from the gcc 
behavior, but the reasons for that are complicated. Mostly they stem from the 
fact that gcc doesn't support fp-contract in the way that the C standard 
describes it.  In gcc, fp-contract is fast or off, and it defaults to fast. If 
you pass -ffp-contract=on to gcc, it behaves exactly like -ffp-contract=off. If 
you pass -std=c99, the default for fp-contract changes to on, but because gcc 
doesn't support fp-contract=on, FMA isn't formed. 
https://godbolt.org/z/K86Kv8W7h

My take on this is that fp-contract=on is a mode that conforms to the language 
standard and fp-contract=fast allows value changing optimizations that do not 
conform to the standard. Value-changing optimizations that do not conform to 
the standard are exactly what the definition of -funsafe-math-optimizations 
allow, so I can't see any reason that -funsafe-math-optimizations shouldn't 
imply fp-contract=fast.

So I was going to say that gcc is wrong, even by its own rules, to not allow 
fp-contract=fast behavior under -funsafe-math-optimizations, but then I 
double-checked my understanding and made a very happy discovery ... 
-funsafe-math-optimizations DOES imply fp-contract=fast in gcc! You just need 
to follow a convoluted path to see that (i.e. change the default to something 
other than fast using -std=c99 and then add the unsafe math option). 
https://godbolt.org/z/K1GonvGdT


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136786

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


[PATCH] D136953: [C++20] Diagnose invalid and reserved module names

2022-10-31 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman marked 2 inline comments as done.
aaron.ballman added inline comments.



Comment at: clang/test/Modules/reserved-names-1.cpp:33
+expected-error {{module declaration must 
occur at the start of the translation unit}}
+
+// Show that being in a system header doesn't save you from diagnostics about

ChuanqiXu wrote:
> aaron.ballman wrote:
> > ChuanqiXu wrote:
> > > We lack a test for `foo.std`;
> > reserved-named-2.cpp has that test (it uses `std0` instead of `std`). Is 
> > that sufficient?
> I feel better with `std`
Okay, I added an additional test.


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

https://reviews.llvm.org/D136953

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


[PATCH] D136953: [C++20] Diagnose invalid and reserved module names

2022-10-31 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman updated this revision to Diff 472052.
aaron.ballman marked 2 inline comments as done.
aaron.ballman added a comment.

Updated based on review feedback.

Added an additional test case, reworked the comments in one of the tests as 
well.


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

https://reviews.llvm.org/D136953

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaModule.cpp
  clang/test/CodeGenCXX/cxx20-module-std-subst-1.cppm
  clang/test/Modules/pair-unambiguous-ctor.cppm
  clang/test/Modules/reserved-names-1.cpp
  clang/test/Modules/reserved-names-2.cpp
  clang/test/Modules/reserved-names-3.cpp
  clang/test/Modules/reserved-names-4.cpp
  clang/test/Modules/reserved-names-system-header-1.cpp
  clang/test/Modules/reserved-names-system-header-2.cpp

Index: clang/test/Modules/reserved-names-system-header-2.cpp
===
--- /dev/null
+++ clang/test/Modules/reserved-names-system-header-2.cpp
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify %s
+// expected-no-diagnostics
+
+// Show that we suppress the reserved identifier diagnostic in a system header.
+# 100 "file.cpp" 1 3  // Enter a system header
+export module __test;
+# 100 "file.cpp" 2 3  // Leave the system header
Index: clang/test/Modules/reserved-names-system-header-1.cpp
===
--- /dev/null
+++ clang/test/Modules/reserved-names-system-header-1.cpp
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify %s
+// expected-no-diagnostics
+
+// Show that we suppress the reserved identifier diagnostic in a system header.
+# 100 "file.cpp" 1 3  // Enter a system header
+export module std;
+# 100 "file.cpp" 2 3  // Leave the system header
Index: clang/test/Modules/reserved-names-4.cpp
===
--- /dev/null
+++ clang/test/Modules/reserved-names-4.cpp
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify %s
+// expected-no-diagnostics
+
+// Demonstrate that we don't consider use of 'std' a reserved identifier if it
+// is not the first part of the path.
+export module should_succeed.std;
+
Index: clang/test/Modules/reserved-names-3.cpp
===
--- /dev/null
+++ clang/test/Modules/reserved-names-3.cpp
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify %s
+// expected-no-diagnostics
+
+// Demonstrate that we don't consider use of 'std' (potentially followed by
+// zero or more digits) to be a reserved identifier if it is not the only part
+// of the path.
+export module std12Three;
Index: clang/test/Modules/reserved-names-2.cpp
===
--- /dev/null
+++ clang/test/Modules/reserved-names-2.cpp
@@ -0,0 +1,6 @@
+// RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify %s
+// expected-no-diagnostics
+
+// Demonstrate that we don't consider use of 'std' followed by digits to be a
+// reserved identifier if it is not the first part of the path.
+export module should_succeed.std0;
Index: clang/test/Modules/reserved-names-1.cpp
===
--- /dev/null
+++ clang/test/Modules/reserved-names-1.cpp
@@ -0,0 +1,45 @@
+// RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify %s
+
+// expected-note@1 15{{add 'module;' to the start of the file to introduce a global module fragment}}
+
+module std;// expected-error {{'std' is a reserved name for a module}}
+module _Test;  // expected-error {{'_Test' is a reserved name for a module}} \
+  expected-error {{module declaration must occur at the start of the translation unit}}
+module module; // expected-error {{'module' is an invalid name for a module}} \
+  expected-error {{module declaration must occur at the start of the translation unit}}
+module std0;   // expected-error {{'std0' is a reserved name for a module}} \
+  expected-error {{module declaration must occur at the start of the translation unit}}
+
+export module module; // expected-error {{'module' is an invalid name for a module}} \
+ expected-error {{module declaration must occur at the start of the translation unit}}
+export module import; // expected-error {{'import' is an invalid name for a module}} \
+ expected-error {{module declaration must occur at the start of the translation unit}}
+export module _Test;  // expected-error {{'_Test' is a reserved name for a module}} \
+ expected-error {{module declaration must occur at the start of the translation unit}}
+export module __test; // expected-error {{'__test' is a reserved name for a module}} \
+ expected-error {{module declaration must occur at the start of the 

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

2022-10-31 Thread John McIver via Phabricator via cfe-commits
jmciver updated this revision to Diff 472051.
jmciver added a comment.

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

Refactor local linkage function, applyNoundefToLoadInst, to use static rather
than an anonymous namespace as per LLVM coding standards.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134410

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

[PATCH] D135919: [Clang] Correct when Itanium ABI guard variables are set for non-block variables with static or thread storage duration.

2022-10-31 Thread Tom Honermann via Phabricator via cfe-commits
tahonermann updated this revision to Diff 472050.
tahonermann retitled this revision from "[Clang] Set thread_local Itanium ABI 
guard variables before calling constructors." to "[Clang] Correct when Itanium 
ABI guard variables are set for non-block variables with static or thread 
storage duration.".
tahonermann edited the summary of this revision.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135919

Files:
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/test/CodeGenCXX/aix-static-init-temp-spec-and-inline-var.cpp
  clang/test/CodeGenCXX/cxx11-thread-local.cpp
  clang/test/CodeGenCXX/cxx1y-variable-template.cpp
  clang/test/CodeGenCXX/global-init.cpp
  clang/test/CodeGenCXX/static-data-member.cpp
  clang/test/OpenMP/threadprivate_codegen.cpp

Index: clang/test/OpenMP/threadprivate_codegen.cpp
===
--- clang/test/OpenMP/threadprivate_codegen.cpp
+++ clang/test/OpenMP/threadprivate_codegen.cpp
@@ -1585,11 +1585,11 @@
 // CHECK1-NEXT:[[GUARD_UNINITIALIZED:%.*]] = icmp eq i8 [[TMP0]], 0
 // CHECK1-NEXT:br i1 [[GUARD_UNINITIALIZED]], label [[INIT_CHECK:%.*]], label [[INIT_END:%.*]]
 // CHECK1:   init.check:
+// CHECK1-NEXT:store i8 1, ptr @_ZGVN2STI2S4E2stE, align 8
 // CHECK1-NEXT:[[TMP1:%.*]] = call i32 @__kmpc_global_thread_num(ptr @[[GLOB1]])
 // CHECK1-NEXT:call void @__kmpc_threadprivate_register(ptr @[[GLOB1]], ptr @_ZN2STI2S4E2stE, ptr @.__kmpc_global_ctor_..9, ptr null, ptr @.__kmpc_global_dtor_..10)
 // CHECK1-NEXT:call void @_ZN2S4C1Ei(ptr noundef nonnull align 4 dereferenceable(8) @_ZN2STI2S4E2stE, i32 noundef 23)
 // CHECK1-NEXT:[[TMP2:%.*]] = call i32 @__cxa_atexit(ptr @_ZN2S4D1Ev, ptr @_ZN2STI2S4E2stE, ptr @__dso_handle) #[[ATTR3]]
-// CHECK1-NEXT:store i8 1, ptr @_ZGVN2STI2S4E2stE, align 8
 // CHECK1-NEXT:br label [[INIT_END]]
 // CHECK1:   init.end:
 // CHECK1-NEXT:ret void
@@ -2214,11 +2214,11 @@
 // CHECK2-NEXT:[[GUARD_UNINITIALIZED:%.*]] = icmp eq i8 [[TMP0]], 0
 // CHECK2-NEXT:br i1 [[GUARD_UNINITIALIZED]], label [[INIT_CHECK:%.*]], label [[INIT_END:%.*]]
 // CHECK2:   init.check:
+// CHECK2-NEXT:store i8 1, ptr @_ZGVN2STI2S4E2stE, align 8
 // CHECK2-NEXT:[[TMP1:%.*]] = call i32 @__kmpc_global_thread_num(ptr @[[GLOB1]])
 // CHECK2-NEXT:call void @__kmpc_threadprivate_register(ptr @[[GLOB1]], ptr @_ZN2STI2S4E2stE, ptr @.__kmpc_global_ctor_..9, ptr null, ptr @.__kmpc_global_dtor_..10)
 // CHECK2-NEXT:call void @_ZN2S4C1Ei(ptr noundef nonnull align 4 dereferenceable(8) @_ZN2STI2S4E2stE, i32 noundef 23)
 // CHECK2-NEXT:[[TMP2:%.*]] = call i32 @__cxa_atexit(ptr @_ZN2S4D1Ev, ptr @_ZN2STI2S4E2stE, ptr @__dso_handle) #[[ATTR3]]
-// CHECK2-NEXT:store i8 1, ptr @_ZGVN2STI2S4E2stE, align 8
 // CHECK2-NEXT:br label [[INIT_END]]
 // CHECK2:   init.end:
 // CHECK2-NEXT:ret void
@@ -2697,9 +2697,9 @@
 // SIMD1-NEXT:[[GUARD_UNINITIALIZED:%.*]] = icmp eq i8 [[TMP0]], 0
 // SIMD1-NEXT:br i1 [[GUARD_UNINITIALIZED]], label [[INIT_CHECK:%.*]], label [[INIT_END:%.*]]
 // SIMD1:   init.check:
+// SIMD1-NEXT:store i8 1, ptr @_ZGVN2STI2S4E2stE, align 8
 // SIMD1-NEXT:call void @_ZN2S4C1Ei(ptr noundef nonnull align 4 dereferenceable(8) @_ZN2STI2S4E2stE, i32 noundef 23)
 // SIMD1-NEXT:[[TMP1:%.*]] = call i32 @__cxa_atexit(ptr @_ZN2S4D1Ev, ptr @_ZN2STI2S4E2stE, ptr @__dso_handle) #[[ATTR3]]
-// SIMD1-NEXT:store i8 1, ptr @_ZGVN2STI2S4E2stE, align 8
 // SIMD1-NEXT:br label [[INIT_END]]
 // SIMD1:   init.end:
 // SIMD1-NEXT:ret void
@@ -3167,9 +3167,9 @@
 // SIMD2-NEXT:[[GUARD_UNINITIALIZED:%.*]] = icmp eq i8 [[TMP0]], 0, !dbg [[DBG234]]
 // SIMD2-NEXT:br i1 [[GUARD_UNINITIALIZED]], label [[INIT_CHECK:%.*]], label [[INIT_END:%.*]], !dbg [[DBG234]]
 // SIMD2:   init.check:
+// SIMD2-NEXT:store i8 1, ptr @_ZGVN2STI2S4E2stE, align 8, !dbg [[DBG234]]
 // SIMD2-NEXT:call void @_ZN2S4C1Ei(ptr noundef nonnull align 4 dereferenceable(8) @_ZN2STI2S4E2stE, i32 noundef 23), !dbg [[DBG235:![0-9]+]]
 // SIMD2-NEXT:[[TMP1:%.*]] = call i32 @__cxa_atexit(ptr @_ZN2S4D1Ev, ptr @_ZN2STI2S4E2stE, ptr @__dso_handle) #[[ATTR3]], !dbg [[DBG234]]
-// SIMD2-NEXT:store i8 1, ptr @_ZGVN2STI2S4E2stE, align 8, !dbg [[DBG234]]
 // SIMD2-NEXT:br label [[INIT_END]], !dbg [[DBG234]]
 // SIMD2:   init.end:
 // SIMD2-NEXT:ret void, !dbg [[DBG237:![0-9]+]]
@@ -3767,9 +3767,9 @@
 // CHECK-TLS1-NEXT:[[GUARD_UNINITIALIZED:%.*]] = icmp eq i8 [[TMP0]], 0
 // CHECK-TLS1-NEXT:br i1 [[GUARD_UNINITIALIZED]], label [[INIT_CHECK:%.*]], label [[INIT_END:%.*]]
 // CHECK-TLS1:   init.check:
+// CHECK-TLS1-NEXT:store i8 1, ptr @_ZGVN2STI2S4E2stE, align 8
 // CHECK-TLS1-NEXT:call void @_ZN2S4C1Ei(ptr noundef nonnull align 4 dereferenceable(8) @_ZN2STI2S4E2stE, i32 noundef 23)
 // CHECK-TLS1-NEXT:[[TMP1:%.*]] = call i32 

[PATCH] D136953: [C++20] Diagnose invalid and reserved module names

2022-10-31 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman marked 9 inline comments as done.
aaron.ballman added inline comments.



Comment at: clang/lib/Sema/SemaModule.cpp:282
+  StringRef FirstComponentName = Path[0].first->getName();
+  if (!getSourceManager().isInSystemHeader(Path[0].second) &&
+  (FirstComponentName == "std" ||

philnik wrote:
> ChuanqiXu wrote:
> > aaron.ballman wrote:
> > > aaron.ballman wrote:
> > > > ChuanqiXu wrote:
> > > > > erichkeane wrote:
> > > > > > ChuanqiXu wrote:
> > > > > > > aaron.ballman wrote:
> > > > > > > > ChuanqiXu wrote:
> > > > > > > > > cor3ntin wrote:
> > > > > > > > > > ChuanqiXu wrote:
> > > > > > > > > > > std modules should be irreverent with system headers; The 
> > > > > > > > > > > intuition of the wording should be that the users can't 
> > > > > > > > > > > declare modules like `std` or `std.compat` to avoid 
> > > > > > > > > > > possible conflicting. The approach I imaged may be add a 
> > > > > > > > > > > new compilation flags (call it `-fstd-modules`) now. And 
> > > > > > > > > > > if the compiler found a `std` module declaration without 
> > > > > > > > > > > `-fstd-modules`, emit an error.  
> > > > > > > > > > > 
> > > > > > > > > > > For now, I think we can skip the check for 
> > > > > > > > > > > `-fstd-modules` and add it back when we starts to support 
> > > > > > > > > > > std modules actually.
> > > > > > > > > > The idea is that standard modules are built from system 
> > > > > > > > > > directories... it seems a better heuristic than adding a 
> > > > > > > > > > flag for the purpose of 1 diagnostics ( maybe some other 
> > > > > > > > > > system library could in theory export std with no warning, 
> > > > > > > > > > but I'm not super worried about that being a concern in 
> > > > > > > > > > practice)
> > > > > > > > > > The idea is that standard modules are built from system 
> > > > > > > > > > directories...
> > > > > > > > > 
> > > > > > > > > This is not true. For example, if someday libc++ supports std 
> > > > > > > > > modules, then we need to build the std modules in our working 
> > > > > > > > > directory, which is not system directories. And **ideally**, 
> > > > > > > > > we would distribute and install module file in the system 
> > > > > > > > > directories. But it is irreverent with the path of the source 
> > > > > > > > > file.
> > > > > > > > > then we need to build the std modules in our working 
> > > > > > > > > directory, which is not system directories.
> > > > > > > > 
> > > > > > > > `-isystem`, pragmas, and linemarkers are all ways around that 
> > > > > > > > -- I don't think we need a feature flag for this, unless I'm 
> > > > > > > > misunderstanding something.
> > > > > > > Although it may be a little bit nit picker, the module unit which 
> > > > > > > declares the std modules won't be header. It is a module unit. So 
> > > > > > > it requires we implement std modules by wrapping linemarkers 
> > > > > > > around the std modules declaration, which looks a little bit 
> > > > > > > overkill.
> > > > > > > 
> > > > > > > And another point is that maybe we need to introduce another 
> > > > > > > feature flags to implement std modules. Although I tried to 
> > > > > > > implement std modules within the current features, I can't prove 
> > > > > > > we can implement std modules in that way in the end of the day.
> > > > > > > 
> > > > > > > Let me add some more words. The standards require us to implement 
> > > > > > > std modules without deprecating the system headers. This strategy 
> > > > > > > leads the direction to "implement the components in the original 
> > > > > > > headers and control their visibility in the std module unit".
> > > > > > > It may look like:
> > > > > > > 
> > > > > > > ```
> > > > > > > //--- std.cppm
> > > > > > > module;
> > > > > > > #include 
> > > > > > > ...
> > > > > > > export module std;
> > > > > > > ```
> > > > > > > 
> > > > > > > Then how can control the visibility?  In my original experiments, 
> > > > > > > I use the style:
> > > > > > > 
> > > > > > > ```
> > > > > > > //--- std.cppm
> > > > > > > module;
> > > > > > > #include 
> > > > > > > ...
> > > > > > > export module std;
> > > > > > > export namespace std {
> > > > > > > using std::sort;
> > > > > > > }
> > > > > > > ```
> > > > > > > 
> > > > > > > but this doesn't always work. For example, we can't `using` a 
> > > > > > > in-class friend definition. And there are more reasons, the 
> > > > > > > unreachable declarations in the global module fragment (the 
> > > > > > > section from `module;` to `export module [module_name]`) can be 
> > > > > > > discarded to reduce the size of the module file. And the 
> > > > > > > reachable rules are complex. But the simple story is that it is 
> > > > > > > highly possible the a lot of necessary declarations in global 
> > > > > > > module fragment in the above snippet would be discarded so that 
> > > > > > > the user can't use std modules correctly. I mean, we 

[PATCH] D135919: [Clang] Correct when Itanium ABI guard variables are set for non-block variables with static or thread storage duration.

2022-10-31 Thread Tom Honermann via Phabricator via cfe-commits
tahonermann added a comment.

> Please add a comment something like this:

Done. Thank you for the prior review comments. This is again ready for review.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135919

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


[PATCH] D136565: [clang] Instantiate alias templates with sugar

2022-10-31 Thread Matheus Izvekov 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 rG279fe6281d2c: [clang] Instantiate alias templates with sugar 
(authored by mizvekov).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136565

Files:
  clang-tools-extra/clangd/unittests/HoverTests.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/test/AST/ast-dump-template-decls.cpp
  clang/test/CXX/temp/temp.deduct.guide/p3.cpp
  clang/test/Misc/diag-template-diffing.cpp
  clang/test/SemaCXX/sizeless-1.cpp
  clang/test/SemaTemplate/make_integer_seq.cpp
  clang/test/SemaTemplate/temp_arg_nontype.cpp
  
lldb/test/API/commands/expression/import-std-module/shared_ptr/TestSharedPtrFromStdModule.py
  
lldb/test/API/commands/expression/import-std-module/weak_ptr-dbg-info-content/TestDbgInfoContentWeakPtrFromStdModule.py
  
lldb/test/API/commands/expression/import-std-module/weak_ptr/TestWeakPtrFromStdModule.py

Index: lldb/test/API/commands/expression/import-std-module/weak_ptr/TestWeakPtrFromStdModule.py
===
--- lldb/test/API/commands/expression/import-std-module/weak_ptr/TestWeakPtrFromStdModule.py
+++ lldb/test/API/commands/expression/import-std-module/weak_ptr/TestWeakPtrFromStdModule.py
@@ -24,9 +24,9 @@
  result_type="std::weak_ptr",
  result_summary="3 strong=1 weak=2",
  result_children=[ValueCheck(name="__ptr_")])
-self.expect_expr("*w.lock()", result_type="int", result_value="3")
-self.expect_expr("*w.lock() = 5", result_type="int", result_value="5")
-self.expect_expr("*w.lock()", result_type="int", result_value="5")
+self.expect_expr("*w.lock()", result_type="element_type", result_value="3")
+self.expect_expr("*w.lock() = 5", result_type="element_type", result_value="5")
+self.expect_expr("*w.lock()", result_type="element_type", result_value="5")
 self.expect_expr("w.use_count()", result_type="long", result_value="1")
 self.expect("expr w.reset()")
 self.expect_expr("w.use_count()", result_type="long", result_value="0")
Index: lldb/test/API/commands/expression/import-std-module/weak_ptr-dbg-info-content/TestDbgInfoContentWeakPtrFromStdModule.py
===
--- lldb/test/API/commands/expression/import-std-module/weak_ptr-dbg-info-content/TestDbgInfoContentWeakPtrFromStdModule.py
+++ lldb/test/API/commands/expression/import-std-module/weak_ptr-dbg-info-content/TestDbgInfoContentWeakPtrFromStdModule.py
@@ -23,7 +23,7 @@
 self.expect_expr("w",
  result_type="std::weak_ptr",
  result_children=[ValueCheck(name="__ptr_")])
-self.expect_expr("*w.lock()", result_type="Foo")
+self.expect_expr("*w.lock()", result_type="element_type")
 self.expect_expr("w.lock()->a", result_type="int", result_value="3")
 self.expect_expr("w.lock()->a = 5",
  result_type="int",
Index: lldb/test/API/commands/expression/import-std-module/shared_ptr/TestSharedPtrFromStdModule.py
===
--- lldb/test/API/commands/expression/import-std-module/shared_ptr/TestSharedPtrFromStdModule.py
+++ lldb/test/API/commands/expression/import-std-module/shared_ptr/TestSharedPtrFromStdModule.py
@@ -24,9 +24,9 @@
  result_type="std::shared_ptr",
  result_summary="3 strong=1 weak=1",
  result_children=[ValueCheck(name="__ptr_")])
-self.expect_expr("*s", result_type="int", result_value="3")
-self.expect_expr("*s = 5", result_type="int", result_value="5")
-self.expect_expr("*s", result_type="int", result_value="5")
+self.expect_expr("*s", result_type="element_type", result_value="3")
+self.expect_expr("*s = 5", result_type="element_type", result_value="5")
+self.expect_expr("*s", result_type="element_type", result_value="5")
 self.expect_expr("(bool)s", result_type="bool", result_value="true")
 self.expect("expr s.reset()")
 self.expect_expr("(bool)s", result_type="bool", result_value="false")
Index: clang/test/SemaTemplate/temp_arg_nontype.cpp
===
--- clang/test/SemaTemplate/temp_arg_nontype.cpp
+++ clang/test/SemaTemplate/temp_arg_nontype.cpp
@@ -437,7 +437,7 @@
 
   template class X> struct A {
 template N> struct B; // expected-note 2{{here}}
-template struct B {}; // expected-error {{non-type template argument specializes a template parameter with dependent type 'Y' (aka 'type-parameter-0-0 *')}}
+template  struct B {}; // expected-error {{non-type template argument specializes a 

[PATCH] D136564: [clang] Instantiate NTTPs and template default arguments with sugar

2022-10-31 Thread Matheus Izvekov via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGab1140874fc6: [clang] Instantiate NTTPs and template default 
arguments with sugar (authored by mizvekov).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136564

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaTemplateDeduction.cpp
  clang/test/AST/ast-dump-template-decls.cpp
  clang/test/CXX/drs/dr3xx.cpp
  clang/test/CXX/expr/expr.const/p3-0x.cpp
  clang/test/Misc/diag-template-diffing.cpp
  clang/test/SemaTemplate/instantiation-default-1.cpp
  clang/test/SemaTemplate/make_integer_seq.cpp

Index: clang/test/SemaTemplate/make_integer_seq.cpp
===
--- clang/test/SemaTemplate/make_integer_seq.cpp
+++ clang/test/SemaTemplate/make_integer_seq.cpp
@@ -69,14 +69,14 @@
 // CHECK-NEXT:   | `-TemplateTypeParmType 0x{{[0-9A-Fa-f]+}} 'T' dependent depth 0 index 1
 // CHECK-NEXT:   |   `-TemplateTypeParm 0x{{[0-9A-Fa-f]+}} 'T'
 // CHECK-NEXT:   |-TemplateArgument expr
-// CHECK-NEXT:   | `-ImplicitCastExpr 0x{{[0-9A-Fa-f]+}}  'type-parameter-0-1':'type-parameter-0-1' 
+// CHECK-NEXT:   | `-ImplicitCastExpr 0x{{[0-9A-Fa-f]+}}  'T' 
 // CHECK-NEXT:   |   `-DeclRefExpr 0x{{[0-9A-Fa-f]+}}  'int' NonTypeTemplateParm 0x{{[0-9A-Fa-f]+}} 'N' 'int'
 // CHECK-NEXT:   `-TemplateSpecializationType 0x{{[0-9A-Fa-f]+}} '__make_integer_seq' dependent __make_integer_seq
 // CHECK-NEXT: |-TemplateArgument template
 // CHECK-NEXT: |-TemplateArgument type 'type-parameter-0-1'
 // CHECK-NEXT: | `-TemplateTypeParmType 0x{{[0-9A-Fa-f]+}} 'type-parameter-0-1' dependent depth 0 index 1
 // CHECK-NEXT: `-TemplateArgument expr
-// CHECK-NEXT:   `-ImplicitCastExpr 0x{{[0-9A-Fa-f]+}}  'type-parameter-0-1':'type-parameter-0-1' 
+// CHECK-NEXT:   `-ImplicitCastExpr 0x{{[0-9A-Fa-f]+}}  'T' 
 // CHECK-NEXT: `-DeclRefExpr 0x{{[0-9A-Fa-f]+}}  'int' NonTypeTemplateParm 0x{{[0-9A-Fa-f]+}} 'N' 'int'
 
   using test4 = __make_integer_seq;
@@ -88,14 +88,14 @@
 // CHECK-NEXT:   | `-TemplateTypeParmType 0x{{[0-9A-Fa-f]+}} 'T' dependent depth 0 index 1
 // CHECK-NEXT:   |   `-TemplateTypeParm 0x{{[0-9A-Fa-f]+}} 'T'
 // CHECK-NEXT:   |-TemplateArgument expr
-// CHECK-NEXT:   | `-ImplicitCastExpr 0x{{[0-9A-Fa-f]+}}  'type-parameter-0-1':'type-parameter-0-1' 
+// CHECK-NEXT:   | `-ImplicitCastExpr 0x{{[0-9A-Fa-f]+}}  'T' 
 // CHECK-NEXT:   |   `-IntegerLiteral 0x{{[0-9A-Fa-f]+}}  'int' 1
 // CHECK-NEXT:   `-TemplateSpecializationType 0x{{[0-9A-Fa-f]+}} '__make_integer_seq' dependent __make_integer_seq
 // CHECK-NEXT: |-TemplateArgument template A
 // CHECK-NEXT: |-TemplateArgument type 'type-parameter-0-1'
 // CHECK-NEXT: | `-TemplateTypeParmType 0x{{[0-9A-Fa-f]+}} 'type-parameter-0-1' dependent depth 0 index 1
 // CHECK-NEXT: `-TemplateArgument expr
-// CHECK-NEXT:   `-ImplicitCastExpr 0x{{[0-9A-Fa-f]+}}  'type-parameter-0-1':'type-parameter-0-1' 
+// CHECK-NEXT:   `-ImplicitCastExpr 0x{{[0-9A-Fa-f]+}}  'T' 
 // CHECK-NEXT: `-IntegerLiteral 0x{{[0-9A-Fa-f]+}}  'int' 1
 
   using test5 = __make_integer_seq;
Index: clang/test/SemaTemplate/instantiation-default-1.cpp
===
--- clang/test/SemaTemplate/instantiation-default-1.cpp
+++ clang/test/SemaTemplate/instantiation-default-1.cpp
@@ -33,7 +33,7 @@
 }
 
 typedef int& int_ref_t;
-Def2 *d2; // expected-note{{in instantiation of default argument for 'Def2' required here}}
+Def2 *d2; // expected-note{{in instantiation of default argument for 'Def2' required here}}
 
 
 template<> struct Def1 { }; // expected-error{{redefinition of 'Def1'}}
Index: clang/test/Misc/diag-template-diffing.cpp
===
--- clang/test/Misc/diag-template-diffing.cpp
+++ clang/test/Misc/diag-template-diffing.cpp
@@ -1454,7 +1454,7 @@
   D(VectorType());
 }
 // CHECK-ELIDE-NOTREE: error: no matching function for call to 'D'
-// CHECK-ELIDE-NOTREE: note: candidate function template not viable: no known conversion from 'VectorType' to 'const VectorType<(TypeAlias::X)0>' for 1st argument
+// CHECK-ELIDE-NOTREE: note: candidate function template not viable: no known conversion from 'VectorType' to 'const VectorType<(X)0>' for 1st argument
 }
 
 namespace TypeAlias2 {
Index: clang/test/CXX/expr/expr.const/p3-0x.cpp
===
--- clang/test/CXX/expr/expr.const/p3-0x.cpp
+++ clang/test/CXX/expr/expr.const/p3-0x.cpp
@@ -88,7 +88,7 @@
 Val remove_noexcept;
 Val add_noexcept;
 #if __cplusplus > 201402L
-// expected-error@-2 {{value of type 'void (*)() noexcept(false)' is not implicitly convertible to 'void (*)() 

[PATCH] D136886: [clang] ASTImporter: Fix importing of va_list types and declarations

2022-10-31 Thread Matheus Izvekov via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG5f820c0f55cd: [clang] ASTImporter: Fix importing of va_list 
types and declarations (authored by mizvekov).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136886

Files:
  clang-tools-extra/clang-tidy/altera/StructPackAlignCheck.cpp
  clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp
  clang/docs/ReleaseNotes.rst
  clang/lib/Frontend/ASTMerge.cpp
  clang/lib/Sema/Sema.cpp
  clang/test/AST/ast-dump-file-line-json.c
  clang/test/AST/ast-dump-overloaded-operators.cpp
  clang/test/AST/ast-dump-record-definition-data-json.cpp
  clang/test/AST/ast-dump-records-json.cpp
  clang/test/AST/ast-dump-template-decls-json.cpp
  clang/test/AST/ast-dump-traits.cpp
  clang/test/AST/fixed_point.c
  clang/test/AST/float16.cpp
  clang/test/PCH/stmt-openmp_structured_block-bit.cpp
  clang/unittests/AST/ASTImporterTest.cpp

Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -7499,7 +7499,14 @@
   }
   )",
   Lang_CXX14);
-  auto *FromFD = FirstDeclMatcher().match(FromTU, fieldDecl());
+
+  auto *FromF = FirstDeclMatcher().match(
+  FromTU, functionDecl(hasName("declToImport")));
+  CXXRecordDecl *FromLambda =
+  cast((cast(FromF->getBody())->body_back()))
+  ->getLambdaClass();
+
+  auto *FromFD = *FromLambda->field_begin();
   ASSERT_TRUE(FromFD);
   ASSERT_TRUE(FromFD->hasCapturedVLAType());
 
@@ -8075,6 +8082,24 @@
   EXPECT_FALSE(SharedStatePtr->isNewDecl(ToBar));
 }
 
+TEST_P(ASTImporterOptionSpecificTestBase, VaList) {
+  Decl *FromTU = getTuDecl(R"(typedef __builtin_va_list va_list;)", Lang_C99);
+
+  auto *FromVaList = FirstDeclMatcher().match(
+  FromTU, typedefDecl(hasName("va_list")));
+  ASSERT_TRUE(FromVaList);
+
+  auto *ToVaList = Import(FromVaList, Lang_C99);
+  ASSERT_TRUE(ToVaList);
+
+  auto *ToBuiltinVaList = FirstDeclMatcher().match(
+  ToAST->getASTContext().getTranslationUnitDecl(),
+  typedefDecl(hasName("__builtin_va_list")));
+
+  ASSERT_TRUE(ToAST->getASTContext().hasSameType(
+  ToVaList->getUnderlyingType(), ToBuiltinVaList->getUnderlyingType()));
+}
+
 INSTANTIATE_TEST_SUITE_P(ParameterizedTests, ASTImporterLookupTableTest,
  DefaultTestValuesForRunOptions);
 
Index: clang/test/PCH/stmt-openmp_structured_block-bit.cpp
===
--- clang/test/PCH/stmt-openmp_structured_block-bit.cpp
+++ clang/test/PCH/stmt-openmp_structured_block-bit.cpp
@@ -13,7 +13,7 @@
 // expected-no-diagnostics
 
 // CHECK: TranslationUnitDecl 0x{{.*}} <> 
-// CHECK: `-FunctionDecl 0x{{.*}} <{{.*}}stmt-openmp_structured_block-bit.cpp:8:1, line:11:1> line:8:6 {{(test|imported test)}} 'void ()'
+// CHECK:  -FunctionDecl 0x{{.*}} <{{.*}}stmt-openmp_structured_block-bit.cpp:8:1, line:11:1> line:8:6 {{(test|imported test)}} 'void ()'
 // CHECK-NEXT:   `-CompoundStmt 0x{{.*}} 
 // CHECK-NEXT: `-OMPParallelDirective 0x{{.*}} 
 // CHECK-NEXT:   `-CapturedStmt 0x{{.*}} 
Index: clang/test/AST/float16.cpp
===
--- clang/test/AST/float16.cpp
+++ clang/test/AST/float16.cpp
@@ -29,7 +29,7 @@
   }
 }
 
-//CHECK:  |-NamespaceDecl
+//CHECK:  |-NamespaceDecl {{.*}} <{{.*}}:22:1,
 //CHECK-NEXT: | |-VarDecl {{.*}} f1n '_Float16'
 //CHECK-NEXT: | |-VarDecl {{.*}} f2n '_Float16' cinit
 //CHECK-NEXT: | | `-FloatingLiteral {{.*}} '_Float16' 3.30e+01
Index: clang/test/AST/fixed_point.c
===
--- clang/test/AST/fixed_point.c
+++ clang/test/AST/fixed_point.c
@@ -402,5 +402,5 @@
 
 _Accum literallast = 1.0k;// One
 
-//CHECK-NEXT: `-VarDecl {{.*}} literallast '_Accum' cinit
+//CHECK-NEXT:  -VarDecl {{.*}} literallast '_Accum' cinit
 //CHECK-NEXT:   `-FixedPointLiteral {{.*}} '_Accum' 1.0
Index: clang/test/AST/ast-dump-traits.cpp
===
--- clang/test/AST/ast-dump-traits.cpp
+++ clang/test/AST/ast-dump-traits.cpp
@@ -52,7 +52,7 @@
 // CHECK-NEXT: | `-CompoundStmt {{.*}} 
 // CHECK-NEXT: |   `-CStyleCastExpr {{.*}}  'void' 
 // CHECK-NEXT: | `-ExpressionTraitExpr {{.*}}  'bool' __is_lvalue_expr
-// CHECK-NEXT: `-FunctionDecl {{.*}}  line:30:6{{( imported)?}} test_unary_expr_or_type_trait 'void ()'
+// CHECK-NEXT:  -FunctionDecl {{.*}}  line:30:6{{( imported)?}} test_unary_expr_or_type_trait 'void ()'
 // CHECK-NEXT:   `-CompoundStmt {{.*}} 
 // CHECK-NEXT: |-CStyleCastExpr {{.*}}  'void' 
 // CHECK-NEXT: | `-UnaryExprOrTypeTraitExpr {{.*}}  'unsigned long' sizeof 'int'
Index: clang/test/AST/ast-dump-template-decls-json.cpp

[PATCH] D136977: [clang] Fix handling of unexpanded packs in template argument expressions.

2022-10-31 Thread Matheus Izvekov via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGedf1a2e89340: [clang] Fix handling of unexpanded packs in 
template argument expressions. (authored by mizvekov).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136977

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/test/CXX/temp/temp.decls/temp.variadic/p5.cpp

Index: clang/test/CXX/temp/temp.decls/temp.variadic/p5.cpp
===
--- clang/test/CXX/temp/temp.decls/temp.variadic/p5.cpp
+++ clang/test/CXX/temp/temp.decls/temp.variadic/p5.cpp
@@ -502,3 +502,22 @@
 template  int C{ A>{}... }; // expected-error {{implicit instantiation of undefined template}}
 #endif
 } // namespace GH56094
+
+namespace GH58679 {
+#if __cplusplus >= 201402L
+template  constexpr int A = 1;
+
+template  struct B;
+template <> struct B<1> { using b1 = void; };
+
+template  using C = char;
+
+template  int D{ B>>{}... };
+
+struct E {
+  template >::b1> E(E1);
+};
+
+template  int F{ E(C{})... };
+#endif
+} // namespace GH58679
Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -7156,11 +7156,8 @@
   }
 
   // If either the parameter has a dependent type or the argument is
-  // type-dependent, there's nothing we can check now. The argument only
-  // contains an unexpanded pack during partial ordering, and there's
-  // nothing more we can check in that case.
-  if (ParamType->isDependentType() || Arg->isTypeDependent() ||
-  Arg->containsUnexpandedParameterPack()) {
+  // type-dependent, there's nothing we can check now.
+  if (ParamType->isDependentType() || Arg->isTypeDependent()) {
 // Force the argument to the type of the parameter to maintain invariants.
 auto *PE = dyn_cast(Arg);
 if (PE)
Index: clang/lib/Sema/SemaOverload.cpp
===
--- clang/lib/Sema/SemaOverload.cpp
+++ clang/lib/Sema/SemaOverload.cpp
@@ -5862,9 +5862,9 @@
 
   // C++2a [intro.execution]p5:
   //   A full-expression is [...] a constant-expression [...]
-  Result =
-  S.ActOnFinishFullExpr(Result.get(), From->getExprLoc(),
-/*DiscardedValue=*/false, /*IsConstexpr=*/true);
+  Result = S.ActOnFinishFullExpr(Result.get(), From->getExprLoc(),
+ /*DiscardedValue=*/false, /*IsConstexpr=*/true,
+ CCE == Sema::CCEKind::CCEK_TemplateArg);
   if (Result.isInvalid())
 return Result;
 
Index: clang/lib/Sema/SemaExprCXX.cpp
===
--- clang/lib/Sema/SemaExprCXX.cpp
+++ clang/lib/Sema/SemaExprCXX.cpp
@@ -8713,14 +8713,14 @@
 }
 
 ExprResult Sema::ActOnFinishFullExpr(Expr *FE, SourceLocation CC,
- bool DiscardedValue,
- bool IsConstexpr) {
+ bool DiscardedValue, bool IsConstexpr,
+ bool IsTemplateArgument) {
   ExprResult FullExpr = FE;
 
   if (!FullExpr.get())
 return ExprError();
 
-  if (DiagnoseUnexpandedParameterPack(FullExpr.get()))
+  if (!IsTemplateArgument && DiagnoseUnexpandedParameterPack(FullExpr.get()))
 return ExprError();
 
   if (DiscardedValue) {
Index: clang/include/clang/Sema/Sema.h
===
--- clang/include/clang/Sema/Sema.h
+++ clang/include/clang/Sema/Sema.h
@@ -6818,7 +6818,8 @@
 Expr, Expr ? Expr->getExprLoc() : SourceLocation(), DiscardedValue);
   }
   ExprResult ActOnFinishFullExpr(Expr *Expr, SourceLocation CC,
- bool DiscardedValue, bool IsConstexpr = false);
+ bool DiscardedValue, bool IsConstexpr = false,
+ bool IsTemplateArgument = false);
   StmtResult ActOnFinishFullStmt(Stmt *Stmt);
 
   // Marks SS invalid if it represents an incomplete type.
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -266,6 +266,8 @@
   `Issue 45736 `_
 - Fix an issue when performing constraints partial ordering on non-template
   functions. `Issue 56154 `_
+- Fix handling of unexpanded packs in template argument expressions.
+  `Issue 58679 `_
 
 Improvements to Clang's diagnostics
 ^^^

[clang-tools-extra] 279fe62 - [clang] Instantiate alias templates with sugar

2022-10-31 Thread Matheus Izvekov via cfe-commits

Author: Matheus Izvekov
Date: 2022-10-31T17:57:19+01:00
New Revision: 279fe6281d2ca5b2318c7437316c28750feaac8d

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

LOG: [clang] Instantiate alias templates with sugar

This makes use of the changes introduced in D134604, in order to
instantiate alias templates witn a final sugared substitution.

This comes at no additional relevant cost.
Since we don't track / unique them in specializations, we wouldn't be
able to resugar them later anyway.

Signed-off-by: Matheus Izvekov 

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

Added: 


Modified: 
clang-tools-extra/clangd/unittests/HoverTests.cpp
clang/lib/Sema/SemaTemplate.cpp
clang/test/AST/ast-dump-template-decls.cpp
clang/test/CXX/temp/temp.deduct.guide/p3.cpp
clang/test/Misc/diag-template-diffing.cpp
clang/test/SemaCXX/sizeless-1.cpp
clang/test/SemaTemplate/make_integer_seq.cpp
clang/test/SemaTemplate/temp_arg_nontype.cpp

lldb/test/API/commands/expression/import-std-module/shared_ptr/TestSharedPtrFromStdModule.py

lldb/test/API/commands/expression/import-std-module/weak_ptr-dbg-info-content/TestDbgInfoContentWeakPtrFromStdModule.py

lldb/test/API/commands/expression/import-std-module/weak_ptr/TestWeakPtrFromStdModule.py

Removed: 




diff  --git a/clang-tools-extra/clangd/unittests/HoverTests.cpp 
b/clang-tools-extra/clangd/unittests/HoverTests.cpp
index 9f64defaf898f..8bca0dc974539 100644
--- a/clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ b/clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -1067,7 +1067,7 @@ class Foo final {})cpp";
  HI.LocalScope = "";
  HI.Kind = index::SymbolKind::TypeAlias;
  HI.Definition = "template  using AA = A";
- HI.Type = {"A", "type-parameter-0-0"}; // FIXME: should be 'T'
+ HI.Type = {"A", "T"};
  HI.TemplateParameters = {{{"typename"}, std::string("T"), 
llvm::None}};
}},
   {// Constant array

diff  --git a/clang/lib/Sema/SemaTemplate.cpp b/clang/lib/Sema/SemaTemplate.cpp
index b04458687ac02..4a7a420759e9a 100644
--- a/clang/lib/Sema/SemaTemplate.cpp
+++ b/clang/lib/Sema/SemaTemplate.cpp
@@ -3854,8 +3854,8 @@ QualType Sema::CheckTemplateIdType(TemplateName Name,
 
 // Only substitute for the innermost template argument list.
 MultiLevelTemplateArgumentList TemplateArgLists;
-TemplateArgLists.addOuterTemplateArguments(Template, CanonicalConverted,
-   /*Final=*/false);
+TemplateArgLists.addOuterTemplateArguments(Template, SugaredConverted,
+   /*Final=*/true);
 TemplateArgLists.addOuterRetainedLevels(
 AliasTemplate->getTemplateParameters()->getDepth());
 

diff  --git a/clang/test/AST/ast-dump-template-decls.cpp 
b/clang/test/AST/ast-dump-template-decls.cpp
index 49760d17c7f22..3bc0357d1b51f 100644
--- a/clang/test/AST/ast-dump-template-decls.cpp
+++ b/clang/test/AST/ast-dump-template-decls.cpp
@@ -120,8 +120,6 @@ using type2 = typename C::type1;
 // CHECK-NEXT: TemplateArgument type 'void'
 // CHECK-NEXT: BuiltinType 0x{{[^ ]*}} 'void'
 // CHECK-NEXT: FunctionProtoType 0x{{[^ ]*}} 'void (int)' cdecl
-// CHECK-NEXT: SubstTemplateTypeParmType 0x{{[^ ]*}} 'void' sugar class depth 
0 index 0 U
-// CHECK-NEXT: TypeAliasTemplate 0x{{[^ ]*}} 'type1'
 // CHECK-NEXT: BuiltinType 0x{{[^ ]*}} 'void'
 // CHECK-NEXT: SubstTemplateTypeParmType 0x{{[^ ]*}} 'int' sugar class depth 0 
index 0 T
 // CHECK-NEXT: ClassTemplateSpecialization 0x{{[^ ]*}} 'C'
@@ -129,38 +127,24 @@ using type2 = typename C::type1;
 } // namespace PR55886
 
 namespace PR56099 {
-template  struct Y;
-template  using Z = Y;
-template  struct foo {
-  template  using bind = Z;
-};
-using t1 = foo::bind;
-// CHECK:  TemplateSpecializationType 0x{{[^ ]*}} 'Y' sugar Y
-// CHECK:  SubstTemplateTypeParmType 0x{{[^ ]*}} 'char' sugar typename 
depth 0 index 0 ... Bs pack_index 3
-// CHECK-NEXT: TypeAliasTemplate 0x{{[^ ]*}} 'Z'
-// CHECK:  SubstTemplateTypeParmType 0x{{[^ ]*}} 'float' sugar typename 
depth 0 index 0 ... Bs pack_index 2
-// CHECK-NEXT: TypeAliasTemplate 0x{{[^ ]*}} 'Z'
-// CHECK:  SubstTemplateTypeParmType 0x{{[^ ]*}} 'int' sugar typename 
depth 0 index 0 ... Bs pack_index 1
-// CHECK-NEXT: TypeAliasTemplate 0x{{[^ ]*}} 'Z'
-// CHECK:  SubstTemplateTypeParmType 0x{{[^ ]*}} 'short' sugar typename 
depth 0 index 0 ... Bs pack_index 0
-// CHECK-NEXT: TypeAliasTemplate 0x{{[^ ]*}} 'Z'
-
 template  struct D {
-  template  using B = int(int (*...p)(T, U));
+  template  struct bind {
+using bound_type = int(int (*...p)(T, U));
+  };
 };
-using t2 = D::B;
-// CHECK:  TemplateSpecializationType 0x{{[^ ]*}} 'B' sugar 
alias B

[PATCH] D136962: [clang] Improve error recovery for pack expansion of expressions

2022-10-31 Thread Matheus Izvekov via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG2492c52a05bc: [clang] Improve error recovery for pack 
expansion of expressions (authored by mizvekov).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136962

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/AST/ComputeDependence.cpp
  clang/test/CXX/temp/temp.decls/temp.variadic/p5.cpp


Index: clang/test/CXX/temp/temp.decls/temp.variadic/p5.cpp
===
--- clang/test/CXX/temp/temp.decls/temp.variadic/p5.cpp
+++ clang/test/CXX/temp/temp.decls/temp.variadic/p5.cpp
@@ -1,4 +1,5 @@
-// RUN: %clang_cc1 -fcxx-exceptions -fexceptions -std=c++11 -fblocks 
-fms-extensions -fsyntax-only -verify %s
+// RUN: %clang_cc1 -fcxx-exceptions -fexceptions -std=c++11 -fblocks 
-fms-extensions -fsyntax-only -verify=expected,cxx11 %s
+// RUN: %clang_cc1 -fcxx-exceptions -fexceptions -std=c++2b -fblocks 
-fms-extensions -fsyntax-only -verify=expected %s
 
 template struct pair;
 template struct tuple;
@@ -164,7 +165,9 @@
 // FIXME: this should test that the diagnostic reads "type contains..."
 struct alignas(Types) TestUnexpandedDecls : T{ // expected-error{{expression 
contains unexpanded parameter pack 'Types'}}
   void member_function(Types);  // expected-error{{declaration type contains 
unexpanded parameter pack 'Types'}}
+#if __cplusplus < 201703L
   void member_function () throw(Types); // expected-error{{exception type 
contains unexpanded parameter pack 'Types'}}
+#endif
   void member_function2() noexcept(Types()); // expected-error{{expression 
contains unexpanded parameter pack 'Types'}}
   operator Types() const; // expected-error{{declaration type contains 
unexpanded parameter pack 'Types'}}
   Types data_member;  // expected-error{{data member type contains unexpanded 
parameter pack 'Types'}}
@@ -427,7 +430,7 @@
 namespace PR21289 {
   template using T = int;
   template struct S { static const int value = 0; };
-  template const int vt = 0; // expected-warning {{extension}}
+  template const int vt = 0; // cxx11-warning {{extension}}
   int f(...);
   template void g() {
 f(T()...);
@@ -491,3 +494,11 @@
 using t2 = E::B;
 // expected-note@-1 {{in instantiation of template class 'pr56094::E' 
requested here}}
 } // namespace pr56094
+
+namespace GH56094 {
+#if __cplusplus >= 201402L
+template  struct A; // expected-note {{template is declared here}}
+template  using B = char;
+template  int C{ A>{}... }; // expected-error {{implicit 
instantiation of undefined template}}
+#endif
+} // namespace GH56094
Index: clang/lib/AST/ComputeDependence.cpp
===
--- clang/lib/AST/ComputeDependence.cpp
+++ clang/lib/AST/ComputeDependence.cpp
@@ -573,7 +573,7 @@
   //   - type-dependent if we don't know the type (fallback to an opaque
   // dependent type), or the type is known and dependent, or it has
   // type-dependent subexpressions.
-  auto D = toExprDependenceForImpliedType(E->getType()->getDependence()) |
+  auto D = toExprDependenceAsWritten(E->getType()->getDependence()) |
ExprDependence::ErrorDependent;
   // FIXME: remove the type-dependent bit from subexpressions, if the
   // RecoveryExpr has a non-dependent type.
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -346,6 +346,8 @@
   potentially problematic function type casts.
 - Clang will now disambiguate NTTP types when printing diagnostic that contain 
NTTP types.
   Fixes `Issue 57562 `_.
+- Better error recovery for pack expansion of expressions.
+  `Issue 58673 `_.
 
 Non-comprehensive list of changes in this release
 -


Index: clang/test/CXX/temp/temp.decls/temp.variadic/p5.cpp
===
--- clang/test/CXX/temp/temp.decls/temp.variadic/p5.cpp
+++ clang/test/CXX/temp/temp.decls/temp.variadic/p5.cpp
@@ -1,4 +1,5 @@
-// RUN: %clang_cc1 -fcxx-exceptions -fexceptions -std=c++11 -fblocks -fms-extensions -fsyntax-only -verify %s
+// RUN: %clang_cc1 -fcxx-exceptions -fexceptions -std=c++11 -fblocks -fms-extensions -fsyntax-only -verify=expected,cxx11 %s
+// RUN: %clang_cc1 -fcxx-exceptions -fexceptions -std=c++2b -fblocks -fms-extensions -fsyntax-only -verify=expected %s
 
 template struct pair;
 template struct tuple;
@@ -164,7 +165,9 @@
 // FIXME: this should test that the diagnostic reads "type contains..."
 struct alignas(Types) TestUnexpandedDecls : T{ // expected-error{{expression contains unexpanded parameter pack 'Types'}}
   void member_function(Types);  // expected-error{{declaration type contains unexpanded 

[clang] ab11408 - [clang] Instantiate NTTPs and template default arguments with sugar

2022-10-31 Thread Matheus Izvekov via cfe-commits

Author: Matheus Izvekov
Date: 2022-10-31T17:57:18+01:00
New Revision: ab1140874fc6ab8ceb55a470489b80d953e1c6a6

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

LOG: [clang] Instantiate NTTPs and template default arguments with sugar

This makes use of the changes introduced in D134604, in order to
instantiate non-type template parameters and default template arguments
with a final sugared substitution.

This comes at no additional relevant cost.
Since we don't track / unique them in specializations, we wouldn't be
able to resugar them later anyway.

Signed-off-by: Matheus Izvekov 

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

Added: 


Modified: 
clang/include/clang/Sema/Sema.h
clang/lib/Sema/SemaTemplate.cpp
clang/lib/Sema/SemaTemplateDeduction.cpp
clang/test/AST/ast-dump-template-decls.cpp
clang/test/CXX/drs/dr3xx.cpp
clang/test/CXX/expr/expr.const/p3-0x.cpp
clang/test/Misc/diag-template-diffing.cpp
clang/test/SemaTemplate/instantiation-default-1.cpp
clang/test/SemaTemplate/make_integer_seq.cpp

Removed: 




diff  --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 917c6c162e6d0..fb9906e24b5ab 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -8201,14 +8201,11 @@ class Sema final {
 SourceLocation TemplateLoc,
 Declarator );
 
-  TemplateArgumentLoc
-  SubstDefaultTemplateArgumentIfAvailable(TemplateDecl *Template,
-  SourceLocation TemplateLoc,
-  SourceLocation RAngleLoc,
-  Decl *Param,
-  SmallVectorImpl
-,
-  bool );
+  TemplateArgumentLoc SubstDefaultTemplateArgumentIfAvailable(
+  TemplateDecl *Template, SourceLocation TemplateLoc,
+  SourceLocation RAngleLoc, Decl *Param,
+  ArrayRef SugaredConverted,
+  ArrayRef CanonicalConverted, bool );
 
   /// Specifies the context in which a particular template
   /// argument is being checked.

diff  --git a/clang/lib/Sema/SemaTemplate.cpp b/clang/lib/Sema/SemaTemplate.cpp
index 985ac271e9d13..b04458687ac02 100644
--- a/clang/lib/Sema/SemaTemplate.cpp
+++ b/clang/lib/Sema/SemaTemplate.cpp
@@ -5261,27 +5261,25 @@ bool Sema::CheckTemplateTypeArgument(
 /// \param Converted the list of template arguments provided for template
 /// parameters that precede \p Param in the template parameter list.
 /// \returns the substituted template argument, or NULL if an error occurred.
-static TypeSourceInfo *
-SubstDefaultTemplateArgument(Sema ,
- TemplateDecl *Template,
- SourceLocation TemplateLoc,
- SourceLocation RAngleLoc,
- TemplateTypeParmDecl *Param,
- SmallVectorImpl ) {
+static TypeSourceInfo *SubstDefaultTemplateArgument(
+Sema , TemplateDecl *Template, SourceLocation TemplateLoc,
+SourceLocation RAngleLoc, TemplateTypeParmDecl *Param,
+ArrayRef SugaredConverted,
+ArrayRef CanonicalConverted) {
   TypeSourceInfo *ArgType = Param->getDefaultArgumentInfo();
 
   // If the argument type is dependent, instantiate it now based
   // on the previously-computed template arguments.
   if (ArgType->getType()->isInstantiationDependentType()) {
-Sema::InstantiatingTemplate Inst(SemaRef, TemplateLoc,
- Param, Template, Converted,
+Sema::InstantiatingTemplate Inst(SemaRef, TemplateLoc, Param, Template,
+ SugaredConverted,
  SourceRange(TemplateLoc, RAngleLoc));
 if (Inst.isInvalid())
   return nullptr;
 
 // Only substitute for the innermost template argument list.
-MultiLevelTemplateArgumentList TemplateArgLists(Template, Converted,
-/*Final=*/false);
+MultiLevelTemplateArgumentList TemplateArgLists(Template, SugaredConverted,
+/*Final=*/true);
 for (unsigned i = 0, e = Param->getDepth(); i != e; ++i)
   TemplateArgLists.addOuterTemplateArguments(None);
 
@@ -5320,22 +5318,20 @@ SubstDefaultTemplateArgument(Sema ,
 /// parameters that precede \p Param in the template parameter list.
 ///
 /// \returns the substituted template argument, or NULL if an error occurred.
-static ExprResult
-SubstDefaultTemplateArgument(Sema ,
- TemplateDecl *Template,
- 

[clang-tools-extra] 5f820c0 - [clang] ASTImporter: Fix importing of va_list types and declarations

2022-10-31 Thread Matheus Izvekov via cfe-commits

Author: Matheus Izvekov
Date: 2022-10-31T17:57:18+01:00
New Revision: 5f820c0f55cd9d4f4520cc92eae0a1c4afe05a54

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

LOG: [clang] ASTImporter: Fix importing of va_list types and declarations

This fixes a problem where __va_list_tag was not correctly imported,
possibly leading to multiple definitions with different types.

This adds __va_list_tag to it's proper scope, so that the ASTImporter
can find it.

Signed-off-by: Matheus Izvekov 

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

Added: 


Modified: 
clang-tools-extra/clang-tidy/altera/StructPackAlignCheck.cpp
clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp
clang/docs/ReleaseNotes.rst
clang/lib/Frontend/ASTMerge.cpp
clang/lib/Sema/Sema.cpp
clang/test/AST/ast-dump-file-line-json.c
clang/test/AST/ast-dump-overloaded-operators.cpp
clang/test/AST/ast-dump-record-definition-data-json.cpp
clang/test/AST/ast-dump-records-json.cpp
clang/test/AST/ast-dump-template-decls-json.cpp
clang/test/AST/ast-dump-traits.cpp
clang/test/AST/fixed_point.c
clang/test/AST/float16.cpp
clang/test/PCH/stmt-openmp_structured_block-bit.cpp
clang/unittests/AST/ASTImporterTest.cpp

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/altera/StructPackAlignCheck.cpp 
b/clang-tools-extra/clang-tidy/altera/StructPackAlignCheck.cpp
index b5f8d082d8877..1735242418671 100644
--- a/clang-tools-extra/clang-tidy/altera/StructPackAlignCheck.cpp
+++ b/clang-tools-extra/clang-tidy/altera/StructPackAlignCheck.cpp
@@ -19,10 +19,11 @@ namespace tidy {
 namespace altera {
 
 void StructPackAlignCheck::registerMatchers(MatchFinder *Finder) {
-  Finder->addMatcher(recordDecl(isStruct(), isDefinition(),
-unless(isExpansionInSystemHeader()))
- .bind("struct"),
- this);
+  Finder->addMatcher(
+  recordDecl(isStruct(), isDefinition(),
+ unless(anyOf(isExpansionInSystemHeader(), isImplicit(
+  .bind("struct"),
+  this);
 }
 
 CharUnits

diff  --git a/clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp 
b/clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp
index 73b47dca20930..89f2bb6aaf50a 100644
--- a/clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp
+++ b/clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp
@@ -111,7 +111,10 @@ void 
RenamerClangTidyCheck::storeOptions(ClangTidyOptions::OptionMap ) {
 }
 
 void RenamerClangTidyCheck::registerMatchers(MatchFinder *Finder) {
-  Finder->addMatcher(namedDecl().bind("decl"), this);
+  Finder->addMatcher(
+  namedDecl(unless(anyOf(isImplicit(), hasDeclContext(isImplicit()
+  .bind("decl"),
+  this);
   Finder->addMatcher(usingDecl().bind("using"), this);
   Finder->addMatcher(declRefExpr().bind("declRef"), this);
   Finder->addMatcher(cxxConstructorDecl(unless(isImplicit())).bind("classRef"),

diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index f751f96d29e9d..991ffac7b8316 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -268,6 +268,7 @@ Bug Fixes
   functions. `Issue 56154 `_
 - Fix handling of unexpanded packs in template argument expressions.
   `Issue 58679 `_
+- Fix importing of va_list types and declarations.
 
 Improvements to Clang's diagnostics
 ^^^

diff  --git a/clang/lib/Frontend/ASTMerge.cpp b/clang/lib/Frontend/ASTMerge.cpp
index 14d781ccdf936..750866892d058 100644
--- a/clang/lib/Frontend/ASTMerge.cpp
+++ b/clang/lib/Frontend/ASTMerge.cpp
@@ -59,12 +59,6 @@ void ASTMergeAction::ExecuteAction() {
 
 TranslationUnitDecl *TU = Unit->getASTContext().getTranslationUnitDecl();
 for (auto *D : TU->decls()) {
-  // Don't re-import __va_list_tag, __builtin_va_list.
-  if (const auto *ND = dyn_cast(D))
-if (IdentifierInfo *II = ND->getIdentifier())
-  if (II->isStr("__va_list_tag") || II->isStr("__builtin_va_list"))
-continue;
-
   llvm::Expected ToDOrError = Importer.Import(D);
 
   if (ToDOrError) {

diff  --git a/clang/lib/Sema/Sema.cpp b/clang/lib/Sema/Sema.cpp
index c229a77ff0b8d..fae85921b0402 100644
--- a/clang/lib/Sema/Sema.cpp
+++ b/clang/lib/Sema/Sema.cpp
@@ -449,6 +449,26 @@ void Sema::Initialize() {
   PushOnScopeChains(Context.getBuiltinMSVaListDecl(), TUScope);
   }
 
+  if (auto *ND = dyn_cast_if_present(Context.getVaListTagDecl())) {
+if (auto *DC = ND->getLexicalDeclContext(); DC->isStdNamespace()) {
+  auto *NS = cast(DC);
+  if (!StdNamespace)
+StdNamespace 

[clang] edf1a2e - [clang] Fix handling of unexpanded packs in template argument expressions.

2022-10-31 Thread Matheus Izvekov via cfe-commits

Author: Matheus Izvekov
Date: 2022-10-31T17:57:17+01:00
New Revision: edf1a2e89340c8fa64a679e7d4ec2b5ee92ec40f

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

LOG: [clang] Fix handling of unexpanded packs in template argument expressions.

Closes #58679.

Signed-off-by: Matheus Izvekov 

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

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/include/clang/Sema/Sema.h
clang/lib/Sema/SemaExprCXX.cpp
clang/lib/Sema/SemaOverload.cpp
clang/lib/Sema/SemaTemplate.cpp
clang/test/CXX/temp/temp.decls/temp.variadic/p5.cpp

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 95910fd9f4269..f751f96d29e9d 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -266,6 +266,8 @@ Bug Fixes
   `Issue 45736 `_
 - Fix an issue when performing constraints partial ordering on non-template
   functions. `Issue 56154 `_
+- Fix handling of unexpanded packs in template argument expressions.
+  `Issue 58679 `_
 
 Improvements to Clang's diagnostics
 ^^^

diff  --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 23b4e3f60cef1..917c6c162e6d0 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -6818,7 +6818,8 @@ class Sema final {
 Expr, Expr ? Expr->getExprLoc() : SourceLocation(), DiscardedValue);
   }
   ExprResult ActOnFinishFullExpr(Expr *Expr, SourceLocation CC,
- bool DiscardedValue, bool IsConstexpr = 
false);
+ bool DiscardedValue, bool IsConstexpr = false,
+ bool IsTemplateArgument = false);
   StmtResult ActOnFinishFullStmt(Stmt *Stmt);
 
   // Marks SS invalid if it represents an incomplete type.

diff  --git a/clang/lib/Sema/SemaExprCXX.cpp b/clang/lib/Sema/SemaExprCXX.cpp
index bb9cfe30e5d4d..41c4348de0791 100644
--- a/clang/lib/Sema/SemaExprCXX.cpp
+++ b/clang/lib/Sema/SemaExprCXX.cpp
@@ -8713,14 +8713,14 @@ Sema::CorrectDelayedTyposInExpr(Expr *E, VarDecl 
*InitDecl,
 }
 
 ExprResult Sema::ActOnFinishFullExpr(Expr *FE, SourceLocation CC,
- bool DiscardedValue,
- bool IsConstexpr) {
+ bool DiscardedValue, bool IsConstexpr,
+ bool IsTemplateArgument) {
   ExprResult FullExpr = FE;
 
   if (!FullExpr.get())
 return ExprError();
 
-  if (DiagnoseUnexpandedParameterPack(FullExpr.get()))
+  if (!IsTemplateArgument && DiagnoseUnexpandedParameterPack(FullExpr.get()))
 return ExprError();
 
   if (DiscardedValue) {

diff  --git a/clang/lib/Sema/SemaOverload.cpp b/clang/lib/Sema/SemaOverload.cpp
index 45bca3a31d3a7..a65cdbed7fd02 100644
--- a/clang/lib/Sema/SemaOverload.cpp
+++ b/clang/lib/Sema/SemaOverload.cpp
@@ -5862,9 +5862,9 @@ static ExprResult CheckConvertedConstantExpression(Sema 
, Expr *From,
 
   // C++2a [intro.execution]p5:
   //   A full-expression is [...] a constant-expression [...]
-  Result =
-  S.ActOnFinishFullExpr(Result.get(), From->getExprLoc(),
-/*DiscardedValue=*/false, /*IsConstexpr=*/true);
+  Result = S.ActOnFinishFullExpr(Result.get(), From->getExprLoc(),
+ /*DiscardedValue=*/false, 
/*IsConstexpr=*/true,
+ CCE == Sema::CCEKind::CCEK_TemplateArg);
   if (Result.isInvalid())
 return Result;
 

diff  --git a/clang/lib/Sema/SemaTemplate.cpp b/clang/lib/Sema/SemaTemplate.cpp
index bf6acd52f2856..985ac271e9d13 100644
--- a/clang/lib/Sema/SemaTemplate.cpp
+++ b/clang/lib/Sema/SemaTemplate.cpp
@@ -7156,11 +7156,8 @@ ExprResult 
Sema::CheckTemplateArgument(NonTypeTemplateParmDecl *Param,
   }
 
   // If either the parameter has a dependent type or the argument is
-  // type-dependent, there's nothing we can check now. The argument only
-  // contains an unexpanded pack during partial ordering, and there's
-  // nothing more we can check in that case.
-  if (ParamType->isDependentType() || Arg->isTypeDependent() ||
-  Arg->containsUnexpandedParameterPack()) {
+  // type-dependent, there's nothing we can check now.
+  if (ParamType->isDependentType() || Arg->isTypeDependent()) {
 // Force the argument to the type of the parameter to maintain invariants.
 auto *PE = dyn_cast(Arg);
 if (PE)

diff  --git a/clang/test/CXX/temp/temp.decls/temp.variadic/p5.cpp 
b/clang/test/CXX/temp/temp.decls/temp.variadic/p5.cpp
index 

  1   2   3   >