[PATCH] D112941: [clang] Add support for the new pointer authentication builtins.

[Bruno Cardoso Lopes via Phabricator via cfe-commits]

bruno added a comment.

Thanks for working on upstreaming this @ab. Overall looks good to me, I see 
clang-format issues, are those legit? One more comment inline.




Comment at: clang/include/clang/Driver/Options.td:2865-2872
+let Group = f_Group in {
+  let Flags = [CC1Option] in {
+def fptrauth_intrinsics : Flag<["-"], "fptrauth-intrinsics">,
+  HelpText<"Enable pointer-authentication intrinsics">;
+  }
+  def fno_ptrauth_intrinsics : Flag<["-"], "fno-ptrauth-intrinsics">;
+}

ab wrote:
> rjmccall wrote:
> > kristof.beyls wrote:
> > > My impression is that generally for `__builtin_XXX` intrinsics, there are 
> > > no compiler flags to make them available or remove their availability.
> > > Is there a good reason why a command line option is needed for the 
> > > `__builtin_ptrauth` intrinsics, but not (IIUC) for most or any other 
> > > existing `__builtin_XXX` intrinsic?
> > > If there is no good reason, it seems better to me to not have a command 
> > > line option so there is better consistency across all `__builtin_XXX` 
> > > intrinsics?
> > > 
> > > (after having read more of the patch): my impression has changed now that 
> > > the f(no-)ptrauth-intrinsics flag rather selects whether the ptrauth 
> > > intrinsics get lowered to PAuth hardware instructions, or to "regular" 
> > > instructions emulating the behavior of authenticated pointers. If that is 
> > > correct (and assuming it's a useful option to have), I would guess a 
> > > different name for the command line option could be less misleading. As 
> > > is, it suggests this selects whether ptrauth_ intrinsics are available or 
> > > not. If instead, as I'm guessing above, this selects whether ptrauth_ 
> > > intrinsics get lowered to PAuth instructions or not, maybe something like 
> > > '-femulate-ptrauth' would describe the effect of the command line switch 
> > > a bit better?
> > The ptrauth features were implemented gradually, beginning with the 
> > intrinsics.  Originally we needed a way to enable the intrinsics feature 
> > without relying on target information.  We do still need a way to enable 
> > them without necessarily enabling automatic type/qualifier-based pointer 
> > authentication.  I don't know if we need to be able to *disable* them when 
> > the target supports them; I agree that that would be a little strange.
> > 
> > If not, we could just enable the intrinsics whenever either the target says 
> > they're okay or software emulation (a separate, experimental feature) is 
> > enabled.  The AArch64 target has a `+pauth` target feature.  However, I 
> > don't know if `-arch arm64e` actually adds that feature on Apple targets.  
> > Also, the `HasPAuth` field in the clang `TargetInfo` does not appear to be 
> > properly initialized to `false` when `+pauth` *isn't* present; fortunately, 
> > that field never used.
> > 
> > I'm not sure if it would actually be okay to remove the 
> > `-fptrauth-intrinsics` driver option if we just enabled the intrinsics 
> > based on the target feature.  That does feel cleaner, but unfortunately, we 
> > at Apple probably have explicit uses of the option that we'd have to clean 
> > up before we could remove the option.  We could treat that as an Apple 
> > problem and keep it out of the open source tree, though, and maybe remove 
> > the option altogether someday.
> > 
> > Ahmed, thoughts?
> Hmm, I agree it would be strange to need to disable the intrinsics, but we do 
> also gate the various higher-level qualifiers (and intrinsics) on 
> `ptrauth_intrinsics`.  So, in `ptrauth.h` (and in various users) the feature 
> now really means "we're in a 'ptrauth-aware' environment".  And it does make 
> more sense to keep that separate from "we're running on a CPU that 
> theoretically could support ptrauth".  It comes down to what "ptrauth-aware" 
> really means, and that's probably also an Apple problem, and all current 
> users of `ptrauth_intrinsics` should use something like `__arm64e__` instead.
> 
> That still means there's no equivalent for other targets and/or software 
> emulation, but that seems okay: `ptrauth.h` already needs changes to be 
> usable from anywhere other than arm64e (cf. the discussion about keys), and 
> we can cross that bridge when we get there.
> 
> (One could argue that all the language-feature-specific qualifiers and 
> intrinsics should be gated on the appropriate ptrauth_whatever feature, but 
> the qualifiers are often used in precisely the glue/runtime code that doesn't 
> build in the appropriate mode, so doesn't have the feature enabled.)
> 
> 
> So, concretely, we could:
> - continue gating these plain intrinsics on `ptrauth_intrinsics` in ptrauth.h 
> (IIRC there's an ACLE feature macro but it's specific to return address 
> signing and BTI defaults; I'll check)
> - enable the feature when `+pauth`
> - replace all other uses of `ptrauth_intrinsics` with `__arm64e__`, in both 
> ptrauth.h (gating the ABI qualifiers) 

[clang] 81081da - [OpenCL] Allow optional __generic in __remove_address_space utility

[Justas Janickas via cfe-commits]

Author: Justas Janickas
Date: 2021-11-09T08:13:34Z
New Revision: 81081daef0299ad59fca299c7cde3888fa691c6a

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

LOG: [OpenCL] Allow optional __generic in __remove_address_space utility

Clang builtin utility `__remove_address_space` now works if generic
address space is not supported in C++ for OpenCL 2021.

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

Added: 


Modified: 
clang/lib/Headers/opencl-c-base.h
clang/test/CodeGenOpenCLCXX/remove-address-space.clcpp

Removed: 




diff  --git a/clang/lib/Headers/opencl-c-base.h 
b/clang/lib/Headers/opencl-c-base.h
index 9c81ddb5e2a73..7485386c82346 100644
--- a/clang/lib/Headers/opencl-c-base.h
+++ b/clang/lib/Headers/opencl-c-base.h
@@ -600,9 +600,11 @@ typedef struct {
 // C++ for OpenCL - __remove_address_space
 #if defined(__OPENCL_CPP_VERSION__)
 template  struct __remove_address_space { using type = _Tp; };
+#if defined(__opencl_c_generic_address_space)
 template  struct __remove_address_space<__generic _Tp> {
   using type = _Tp;
 };
+#endif
 template  struct __remove_address_space<__global _Tp> {
   using type = _Tp;
 };

diff  --git a/clang/test/CodeGenOpenCLCXX/remove-address-space.clcpp 
b/clang/test/CodeGenOpenCLCXX/remove-address-space.clcpp
index f6f0c3290aa66..9043a7d53c682 100644
--- a/clang/test/CodeGenOpenCLCXX/remove-address-space.clcpp
+++ b/clang/test/CodeGenOpenCLCXX/remove-address-space.clcpp
@@ -1,4 +1,6 @@
-// RUN: %clang_cc1 %s -cl-std=clc++ -fdeclare-opencl-builtins 
-finclude-default-header
+// RUN: %clang_cc1 %s -cl-std=clc++1.0 -fdeclare-opencl-builtins 
-finclude-default-header
+// RUN: %clang_cc1 %s -cl-std=clc++2021 -fdeclare-opencl-builtins 
-finclude-default-header
+// RUN: %clang_cc1 %s -cl-std=clc++2021 
-cl-ext=-__opencl_c_generic_address_space,-__opencl_c_pipes 
-fdeclare-opencl-builtins -finclude-default-header
 
 template
 struct is_same {
@@ -19,8 +21,10 @@ void test_is_same() {
 void test_remove_address_space() {
   static_assert(is_same<__remove_address_space::type, int>::value,
 "type without an address space unexpectedly modified by 
__remove_address_space");
+#if defined(__opencl_c_generic_address_space)
   static_assert(is_same<__remove_address_space<__generic int>::type, 
int>::value,
 "__generic address space not removed by 
__remove_address_space");
+#endif
   static_assert(is_same<__remove_address_space<__global char>::type, 
char>::value,
 "__global address space not removed by 
__remove_address_space");
   static_assert(is_same<__remove_address_space<__private ulong>::type, 
ulong>::value,



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

[PATCH] D110155: [OpenCL] Allow optional __generic in __remove_address_space utility

[Justas Janickas 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 rG81081daef029: [OpenCL] Allow optional __generic in 
__remove_address_space utility (authored by Topotuna).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110155

Files:
  clang/lib/Headers/opencl-c-base.h
  clang/test/CodeGenOpenCLCXX/remove-address-space.clcpp


Index: clang/test/CodeGenOpenCLCXX/remove-address-space.clcpp
===
--- clang/test/CodeGenOpenCLCXX/remove-address-space.clcpp
+++ clang/test/CodeGenOpenCLCXX/remove-address-space.clcpp
@@ -1,4 +1,6 @@
-// RUN: %clang_cc1 %s -cl-std=clc++ -fdeclare-opencl-builtins 
-finclude-default-header
+// RUN: %clang_cc1 %s -cl-std=clc++1.0 -fdeclare-opencl-builtins 
-finclude-default-header
+// RUN: %clang_cc1 %s -cl-std=clc++2021 -fdeclare-opencl-builtins 
-finclude-default-header
+// RUN: %clang_cc1 %s -cl-std=clc++2021 
-cl-ext=-__opencl_c_generic_address_space,-__opencl_c_pipes 
-fdeclare-opencl-builtins -finclude-default-header
 
 template
 struct is_same {
@@ -19,8 +21,10 @@
 void test_remove_address_space() {
   static_assert(is_same<__remove_address_space::type, int>::value,
 "type without an address space unexpectedly modified by 
__remove_address_space");
+#if defined(__opencl_c_generic_address_space)
   static_assert(is_same<__remove_address_space<__generic int>::type, 
int>::value,
 "__generic address space not removed by 
__remove_address_space");
+#endif
   static_assert(is_same<__remove_address_space<__global char>::type, 
char>::value,
 "__global address space not removed by 
__remove_address_space");
   static_assert(is_same<__remove_address_space<__private ulong>::type, 
ulong>::value,
Index: clang/lib/Headers/opencl-c-base.h
===
--- clang/lib/Headers/opencl-c-base.h
+++ clang/lib/Headers/opencl-c-base.h
@@ -600,9 +600,11 @@
 // C++ for OpenCL - __remove_address_space
 #if defined(__OPENCL_CPP_VERSION__)
 template  struct __remove_address_space { using type = _Tp; };
+#if defined(__opencl_c_generic_address_space)
 template  struct __remove_address_space<__generic _Tp> {
   using type = _Tp;
 };
+#endif
 template  struct __remove_address_space<__global _Tp> {
   using type = _Tp;
 };


Index: clang/test/CodeGenOpenCLCXX/remove-address-space.clcpp
===
--- clang/test/CodeGenOpenCLCXX/remove-address-space.clcpp
+++ clang/test/CodeGenOpenCLCXX/remove-address-space.clcpp
@@ -1,4 +1,6 @@
-// RUN: %clang_cc1 %s -cl-std=clc++ -fdeclare-opencl-builtins -finclude-default-header
+// RUN: %clang_cc1 %s -cl-std=clc++1.0 -fdeclare-opencl-builtins -finclude-default-header
+// RUN: %clang_cc1 %s -cl-std=clc++2021 -fdeclare-opencl-builtins -finclude-default-header
+// RUN: %clang_cc1 %s -cl-std=clc++2021 -cl-ext=-__opencl_c_generic_address_space,-__opencl_c_pipes -fdeclare-opencl-builtins -finclude-default-header
 
 template
 struct is_same {
@@ -19,8 +21,10 @@
 void test_remove_address_space() {
   static_assert(is_same<__remove_address_space::type, int>::value,
 "type without an address space unexpectedly modified by __remove_address_space");
+#if defined(__opencl_c_generic_address_space)
   static_assert(is_same<__remove_address_space<__generic int>::type, int>::value,
 "__generic address space not removed by __remove_address_space");
+#endif
   static_assert(is_same<__remove_address_space<__global char>::type, char>::value,
 "__global address space not removed by __remove_address_space");
   static_assert(is_same<__remove_address_space<__private ulong>::type, ulong>::value,
Index: clang/lib/Headers/opencl-c-base.h
===
--- clang/lib/Headers/opencl-c-base.h
+++ clang/lib/Headers/opencl-c-base.h
@@ -600,9 +600,11 @@
 // C++ for OpenCL - __remove_address_space
 #if defined(__OPENCL_CPP_VERSION__)
 template  struct __remove_address_space { using type = _Tp; };
+#if defined(__opencl_c_generic_address_space)
 template  struct __remove_address_space<__generic _Tp> {
   using type = _Tp;
 };
+#endif
 template  struct __remove_address_space<__global _Tp> {
   using type = _Tp;
 };
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 7ecec3f - [CUDA] Bump supported CUDA version to 11.5

[Carlos Galvez via cfe-commits]

Author: Carlos Galvez
Date: 2021-11-09T08:20:53Z
New Revision: 7ecec3f0f5215c99e45d7000c11230ba2f7e421c

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

LOG: [CUDA] Bump supported CUDA version to 11.5

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

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/include/clang/Basic/BuiltinsNVPTX.def
clang/include/clang/Basic/Cuda.h
clang/lib/Basic/Cuda.cpp
clang/lib/Basic/Targets/NVPTX.cpp
clang/lib/Driver/ToolChains/Cuda.cpp
llvm/docs/CompileCudaWithLLVM.rst
llvm/lib/Target/NVPTX/NVPTX.td

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 56ed6d28949f3..fd3217c29e67e 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -158,7 +158,7 @@ C++2b Feature Support
 CUDA Language Changes in Clang
 --
 
-- Clang now supports CUDA versions up to 11.4.
+- Clang now supports CUDA versions up to 11.5.
 - Default GPU architecture has been changed from sm_20 to sm_35.
 
 Objective-C Language Changes in Clang

diff  --git a/clang/include/clang/Basic/BuiltinsNVPTX.def 
b/clang/include/clang/Basic/BuiltinsNVPTX.def
index 7afee4dbc80bc..025fef05c8e0d 100644
--- a/clang/include/clang/Basic/BuiltinsNVPTX.def
+++ b/clang/include/clang/Basic/BuiltinsNVPTX.def
@@ -41,7 +41,9 @@
 #pragma push_macro("PTX72")
 #pragma push_macro("PTX73")
 #pragma push_macro("PTX74")
-#define PTX74 "ptx74"
+#pragma push_macro("PTX75")
+#define PTX75 "ptx75"
+#define PTX74 "ptx74|" PTX75
 #define PTX73 "ptx73|" PTX74
 #define PTX72 "ptx72|" PTX73
 #define PTX71 "ptx71|" PTX72
@@ -827,3 +829,4 @@ TARGET_BUILTIN(__nvvm_cp_async_wait_all, "v", "", 
AND(SM_80,PTX70))
 #pragma pop_macro("PTX72")
 #pragma pop_macro("PTX73")
 #pragma pop_macro("PTX74")
+#pragma pop_macro("PTX75")

diff  --git a/clang/include/clang/Basic/Cuda.h 
b/clang/include/clang/Basic/Cuda.h
index ef2023cabf7f8..8c08ab3f5d749 100644
--- a/clang/include/clang/Basic/Cuda.h
+++ b/clang/include/clang/Basic/Cuda.h
@@ -33,9 +33,10 @@ enum class CudaVersion {
   CUDA_112,
   CUDA_113,
   CUDA_114,
-  FULLY_SUPPORTED = CUDA_114,
+  CUDA_115,
+  FULLY_SUPPORTED = CUDA_115,
   PARTIALLY_SUPPORTED =
-  CUDA_114, // Partially supported. Proceed with a warning.
+  CUDA_115, // Partially supported. Proceed with a warning.
   NEW = 1,  // Too new. Issue a warning, but allow using it.
 };
 const char *CudaVersionToString(CudaVersion V);

diff  --git a/clang/lib/Basic/Cuda.cpp b/clang/lib/Basic/Cuda.cpp
index f5ee1fb4c2284..e82a3a705e70c 100644
--- a/clang/lib/Basic/Cuda.cpp
+++ b/clang/lib/Basic/Cuda.cpp
@@ -40,6 +40,8 @@ const char *CudaVersionToString(CudaVersion V) {
 return "11.3";
   case CudaVersion::CUDA_114:
 return "11.4";
+  case CudaVersion::CUDA_115:
+return "11.5";
   case CudaVersion::NEW:
 return "";
   }
@@ -62,6 +64,7 @@ CudaVersion CudaStringToVersion(const llvm::Twine &S) {
   .Case("11.2", CudaVersion::CUDA_112)
   .Case("11.3", CudaVersion::CUDA_113)
   .Case("11.4", CudaVersion::CUDA_114)
+  .Case("11.5", CudaVersion::CUDA_115)
   .Default(CudaVersion::UNKNOWN);
 }
 
@@ -241,6 +244,8 @@ CudaVersion ToCudaVersion(llvm::VersionTuple Version) {
 return CudaVersion::CUDA_113;
   case 114:
 return CudaVersion::CUDA_114;
+  case 115:
+return CudaVersion::CUDA_115;
   default:
 return CudaVersion::UNKNOWN;
   }

diff  --git a/clang/lib/Basic/Targets/NVPTX.cpp 
b/clang/lib/Basic/Targets/NVPTX.cpp
index 0461a91d0add7..3561b22677bc6 100644
--- a/clang/lib/Basic/Targets/NVPTX.cpp
+++ b/clang/lib/Basic/Targets/NVPTX.cpp
@@ -44,6 +44,7 @@ NVPTXTargetInfo::NVPTXTargetInfo(const llvm::Triple &Triple,
 if (!Feature.startswith("+ptx"))
   continue;
 PTXVersion = llvm::StringSwitch(Feature)
+ .Case("+ptx75", 75)
  .Case("+ptx74", 74)
  .Case("+ptx73", 73)
  .Case("+ptx72", 72)

diff  --git a/clang/lib/Driver/ToolChains/Cuda.cpp 
b/clang/lib/Driver/ToolChains/Cuda.cpp
index 09418aa2390f2..5397c7a9a0e66 100644
--- a/clang/lib/Driver/ToolChains/Cuda.cpp
+++ b/clang/lib/Driver/ToolChains/Cuda.cpp
@@ -65,6 +65,8 @@ CudaVersion getCudaVersion(uint32_t raw_version) {
 return CudaVersion::CUDA_113;
   if (raw_version < 11050)
 return CudaVersion::CUDA_114;
+  if (raw_version < 11060)
+return CudaVersion::CUDA_115;
   return CudaVersion::NEW;
 }
 
@@ -707,6 +709,7 @@ void CudaToolChain::addClangTargetOptions(
   case CudaVersion::CUDA_##CUDA_VER:   
\
 PtxFeature = "+ptx" #PTX_VER;  
\
 break;
+CASE_CUDA_VERSION(115, 75);
 CASE_CUDA_VERSION(114

[PATCH] D113249: [CUDA] Bump CUDA version to 11.5

[Carlos Galvez via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG7ecec3f0f521: [CUDA] Bump supported CUDA version to 11.5 
(authored by carlosgalvezp).

Changed prior to commit:
  https://reviews.llvm.org/D113249?vs=385286&id=385717#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113249

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/BuiltinsNVPTX.def
  clang/include/clang/Basic/Cuda.h
  clang/lib/Basic/Cuda.cpp
  clang/lib/Basic/Targets/NVPTX.cpp
  clang/lib/Driver/ToolChains/Cuda.cpp
  llvm/docs/CompileCudaWithLLVM.rst
  llvm/lib/Target/NVPTX/NVPTX.td

Index: llvm/lib/Target/NVPTX/NVPTX.td
===
--- llvm/lib/Target/NVPTX/NVPTX.td
+++ llvm/lib/Target/NVPTX/NVPTX.td
@@ -93,6 +93,8 @@
  "Use PTX version 7.3">;
 def PTX74 : SubtargetFeature<"ptx74", "PTXVersion", "74",
  "Use PTX version 7.4">;
+def PTX75 : SubtargetFeature<"ptx75", "PTXVersion", "75",
+ "Use PTX version 7.5">;
 
 //===--===//
 // NVPTX supported processors.
Index: llvm/docs/CompileCudaWithLLVM.rst
===
--- llvm/docs/CompileCudaWithLLVM.rst
+++ llvm/docs/CompileCudaWithLLVM.rst
@@ -23,8 +23,8 @@
 -
 
 CUDA is supported since llvm 3.9. Clang currently supports CUDA 7.0 through
-10.1. If clang detects a newer CUDA version, it will issue a warning and will
-attempt to use detected CUDA SDK it as if it were CUDA-10.1.
+11.5. If clang detects a newer CUDA version, it will issue a warning and will
+attempt to use detected CUDA SDK it as if it were CUDA 11.5.
 
 Before you build CUDA code, you'll need to have installed the CUDA SDK.  See
 `NVIDIA's CUDA installation guide
Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -65,6 +65,8 @@
 return CudaVersion::CUDA_113;
   if (raw_version < 11050)
 return CudaVersion::CUDA_114;
+  if (raw_version < 11060)
+return CudaVersion::CUDA_115;
   return CudaVersion::NEW;
 }
 
@@ -707,6 +709,7 @@
   case CudaVersion::CUDA_##CUDA_VER:   \
 PtxFeature = "+ptx" #PTX_VER;  \
 break;
+CASE_CUDA_VERSION(115, 75);
 CASE_CUDA_VERSION(114, 74);
 CASE_CUDA_VERSION(113, 73);
 CASE_CUDA_VERSION(112, 72);
Index: clang/lib/Basic/Targets/NVPTX.cpp
===
--- clang/lib/Basic/Targets/NVPTX.cpp
+++ clang/lib/Basic/Targets/NVPTX.cpp
@@ -44,6 +44,7 @@
 if (!Feature.startswith("+ptx"))
   continue;
 PTXVersion = llvm::StringSwitch(Feature)
+ .Case("+ptx75", 75)
  .Case("+ptx74", 74)
  .Case("+ptx73", 73)
  .Case("+ptx72", 72)
Index: clang/lib/Basic/Cuda.cpp
===
--- clang/lib/Basic/Cuda.cpp
+++ clang/lib/Basic/Cuda.cpp
@@ -40,6 +40,8 @@
 return "11.3";
   case CudaVersion::CUDA_114:
 return "11.4";
+  case CudaVersion::CUDA_115:
+return "11.5";
   case CudaVersion::NEW:
 return "";
   }
@@ -62,6 +64,7 @@
   .Case("11.2", CudaVersion::CUDA_112)
   .Case("11.3", CudaVersion::CUDA_113)
   .Case("11.4", CudaVersion::CUDA_114)
+  .Case("11.5", CudaVersion::CUDA_115)
   .Default(CudaVersion::UNKNOWN);
 }
 
@@ -241,6 +244,8 @@
 return CudaVersion::CUDA_113;
   case 114:
 return CudaVersion::CUDA_114;
+  case 115:
+return CudaVersion::CUDA_115;
   default:
 return CudaVersion::UNKNOWN;
   }
Index: clang/include/clang/Basic/Cuda.h
===
--- clang/include/clang/Basic/Cuda.h
+++ clang/include/clang/Basic/Cuda.h
@@ -33,9 +33,10 @@
   CUDA_112,
   CUDA_113,
   CUDA_114,
-  FULLY_SUPPORTED = CUDA_114,
+  CUDA_115,
+  FULLY_SUPPORTED = CUDA_115,
   PARTIALLY_SUPPORTED =
-  CUDA_114, // Partially supported. Proceed with a warning.
+  CUDA_115, // Partially supported. Proceed with a warning.
   NEW = 1,  // Too new. Issue a warning, but allow using it.
 };
 const char *CudaVersionToString(CudaVersion V);
Index: clang/include/clang/Basic/BuiltinsNVPTX.def
===
--- clang/include/clang/Basic/BuiltinsNVPTX.def
+++ clang/include/clang/Basic/BuiltinsNVPTX.def
@@ -41,7 +41,9 @@
 #pragma push_macro("PTX72")
 #pragma push_macro("PTX73")
 #pragma push_macro("PTX74")
-#define PTX74 "ptx74"
+#pragma push_macro("PTX75")
+#define PTX75 "ptx75"
+#define PTX74 "ptx74|" PTX75
 #define PTX73

[PATCH] D112996: [CodeCompletion] Generally consider header files without extension

[Christian Kandeler via Phabricator via cfe-commits]

ckandeler added a comment.

Can someone please merge this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112996

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

[PATCH] D110927: [analyzer] Access stored value of a constant array through a pointer to another type

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

steakhal added a comment.

For testing this I would recommend using a separate test file.
That being said, you should avoid globals even in tests when you can. The 
distance between its declaration and use just makes it harder to comprehend and 
reason about.
You could have a parameter, and take its address to accomplish your reinterpret 
casts and type puns.

BTW your patch crashes on the test suite:
`initialization.cpp:242`:

  void glob_array_typedef1() {
clang_analyzer_eval(glob_arr8[0][0] == 1); // <-- crashes here
// ...
  }

  clang: ../../clang/lib/AST/ASTContext.cpp:10230: clang::QualType 
clang::ASTContext::getCorrespondingUnsignedType(clang::QualType) const: 
Assertion `(T->hasSignedIntegerRepresentation() || T->isSignedFixedPointType()) 
&& "Unexpected type"' failed.
  Called by clang::ASTContext::getCorrespondingUnsignedType() from 
RegionStoreManager::canAccessStoredValue()




Comment at: clang/lib/StaticAnalyzer/Core/RegionStore.cpp:1661
+/// E.g. for `const int[1][2][3];` returns `int`.
+QualType getConstantArrayRootElement(const ConstantArrayType *CAT) {
+  assert(CAT && "ConstantArrayType should not be null");

Maybe //unwrapConstantArrayTypes()//?



Comment at: clang/lib/StaticAnalyzer/Core/RegionStore.cpp:1790
+  // paper P1839R0 be considered by the committee.
+  if ((Index != 0))
+return false;

Even though you are technically correct, how can you know that the pointer you 
try to dereference actually points to the beginning of the object?
Consider something like this:

```lang=C++
void callback(void *payload) {
  // lets skip the first char object...
  int *num = (int*)((char*)payload + 1);
  clang_analyzer_dump(num); // Element{Element{SymRegion{payload}, 1, char}, 0, 
int}
}
```



Comment at: clang/lib/StaticAnalyzer/Core/RegionStore.cpp:1794-1795
+  // - is char, uchar, std::byte
+  if ((ThroughT == Ctx.CharTy) || (ThroughT == Ctx.UnsignedCharTy) ||
+  ThroughT->isStdByteType())
+return true;





Comment at: clang/test/Analysis/initialization.cpp:295-299
+void glob_cast_opposite_sign1() {
+  auto *ptr = (unsigned int *)glob_arr2;
+  auto x1 = ptr[0]; // no-warning
+  auto x2 = ptr[1]; // expected-warning{{garbage or undefined}}
+}

I think it's not correct.

`glob_arr2` refers to an object of dynamic type `int[2]`.
And the pointer decayed from it is `int *`, which has //similar type// to 
`unsigned *` what you are using to access the memory.
Since they are //similar//, this operation should work for all the valid 
indices, thus `ptr[0]`, `ptr[1]`, `ptr[2]`, `ptr[3]` should all be valid.





Comment at: clang/test/Analysis/initialization.cpp:311-314
+void glob_cast_invalid3() {
+  auto *ptr = (char32_t *)glob_arr2;
+  auto x = ptr[0]; // expected-warning{{garbage or undefined}}
+}

Please also try `char8_t`.


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

https://reviews.llvm.org/D110927

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

[PATCH] D112915: WIP: [clang][modules] Granular tracking of includes

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 updated this revision to Diff 385730.
jansvoboda11 added a comment.

Make loading of (sub)module includes lazy


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112915

Files:
  clang/include/clang/Lex/ExternalPreprocessorSource.h
  clang/include/clang/Lex/HeaderSearch.h
  clang/include/clang/Lex/Preprocessor.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/include/clang/Serialization/ASTReader.h
  clang/include/clang/Serialization/ASTWriter.h
  clang/include/clang/Serialization/ModuleFile.h
  clang/lib/Lex/HeaderSearch.cpp
  clang/lib/Lex/PPDirectives.cpp
  clang/lib/Lex/PPLexerChange.cpp
  clang/lib/Lex/Preprocessor.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/Modules/import-submodule-visibility.c

Index: clang/test/Modules/import-submodule-visibility.c
===
--- /dev/null
+++ clang/test/Modules/import-submodule-visibility.c
@@ -0,0 +1,80 @@
+// This test checks that imports of headers that appeared in a different submodule than
+// what is imported by the current TU don't affect the compilation.
+
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+
+//--- A.framework/Headers/A.h
+#include "Textual.h"
+//--- A.framework/Modules/module.modulemap
+framework module A { header "A.h" }
+
+//--- B.framework/Headers/B1.h
+#include "Textual.h"
+//--- B.framework/Headers/B2.h
+//--- B.framework/Modules/module.modulemap
+framework module B {
+  module B1 { header "B1.h" }
+  module B2 { header "B2.h" }
+}
+
+//--- C/C.h
+#include "Textual.h"
+//--- C/module.modulemap
+module C { header "C.h" }
+
+//--- D/D1.h
+#include "Textual.h"
+//--- D/D2.h
+//--- D/module.modulemap
+module D {
+  module D1 { header "D1.h" }
+  module D2 { header "D2.h" }
+}
+
+//--- Textual.h
+#define MACRO_TEXTUAL 1
+
+//--- test.c
+
+#ifdef A
+//
+#endif
+
+#ifdef B
+#import 
+#endif
+
+#ifdef C
+//
+#endif
+
+#ifdef D
+#import "D/D2.h"
+#endif
+
+#import "Textual.h"
+
+static int x = MACRO_TEXTUAL;
+
+// Specifying the PCM file on the command line (without actually importing "A") should not
+// prevent "Textual.h" to be included in the TU.
+//
+// RUN: %clang_cc1 -fmodules -I %t -emit-module %t/A.framework/Modules/module.modulemap -fmodule-name=A -o %t/A.pcm
+// RUN: %clang_cc1 -fmodules -I %t -fsyntax-only %t/test.c -DA -fmodule-file=%t/A.pcm -fmodule-map-file=%t/A.framework/Modules/module.modulemap
+
+// Specifying the PCM file on the command line and importing "B2" in the source does not
+// prevent "Textual.h" to be included in the TU.
+//
+// RUN: %clang_cc1 -fmodules -I %t -emit-module %t/B.framework/Modules/module.modulemap -fmodule-name=B -o %t/B.pcm
+// RUN: %clang_cc1 -fmodules -I %t -fsyntax-only %t/test.c -DB -iframework %t -fmodule-file=%t/B.pcm -fmodule-map-file=%t/B.framework/Modules/module.modulemap
+
+// Module-only version of the test with framework A.
+//
+// RUN: %clang_cc1 -fmodules -I %t -emit-module %t/C/module.modulemap -fmodule-name=C -o %t/C.pcm
+// RUN: %clang_cc1 -fmodules -I %t -fsyntax-only %t/test.c -DC -fmodule-file=%t/C.pcm -fmodule-map-file=%t/C/module.modulemap
+
+// Module-only version of the test with framework B.
+//
+// RUN: %clang_cc1 -fmodules -I %t -emit-module %t/D/module.modulemap -fmodule-name=D -o %t/D.pcm
+// RUN: %clang_cc1 -fmodules -I %t -fsyntax-only %t/test.c -DD -fmodule-file=%t/D.pcm -fmodule-map-file=%t/D/module.modulemap
Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -1696,7 +1696,7 @@
 std::pair
 EmitKeyDataLength(raw_ostream& Out, key_type_ref key, data_type_ref Data) {
   unsigned KeyLen = key.Filename.size() + 1 + 8 + 8;
-  unsigned DataLen = 1 + 2 + 4 + 4;
+  unsigned DataLen = 1 + 4 + 4;
   for (auto ModInfo : Data.KnownHeaders)
 if (Writer.getLocalOrImportedSubmoduleID(ModInfo.getModule()))
   DataLen += 4;
@@ -1728,7 +1728,6 @@
   | (Data.HFI.DirInfo << 1)
   | Data.HFI.IndexHeaderMapHeader;
   LE.write(Flags);
-  LE.write(Data.HFI.NumIncludes);
 
   if (!Data.HFI.ControllingMacro)
 LE.write(Data.HFI.ControllingMacroID);
@@ -2171,6 +2170,35 @@
   return false;
 }
 
+void ASTWriter::addIncludedFiles(
+const llvm::DenseMap &Files,
+RecordDataImpl &Record) {
+  auto Vec = llvm::to_vector<0>(Files);
+
+  // Ensure the order is stable.
+  llvm::sort(Vec, [](const auto &LHS, const auto &RHS) {
+return LHS.first->getName().compare(RHS.first->getName()) < 0;
+  });
+
+  // The first partition contains files included exactly once,
+  // the second partition contains files included more than once.
+  auto It = std::stable_partition(Vec.begin(), Vec.end(),
+  [](const auto &E

[PATCH] D113294: [IR] Remove unbounded as possible value for vscale_range minimum

[Cullen Rhodes via Phabricator via cfe-commits]

c-rhodes updated this revision to Diff 385732.
c-rhodes added a comment.

Address comments


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

https://reviews.llvm.org/D113294

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/arm-sve-vector-bits-vscale-range.c
  clang/test/Frontend/aarch64-vscale-min.c
  llvm/docs/LangRef.rst
  llvm/include/llvm/IR/Attributes.h
  llvm/lib/IR/Attributes.cpp
  llvm/lib/IR/Verifier.cpp
  llvm/test/Analysis/CostModel/AArch64/sve-gather.ll
  llvm/test/Analysis/CostModel/AArch64/sve-scatter.ll
  llvm/test/Bitcode/attributes.ll
  llvm/test/Transforms/InstCombine/icmp-vscale.ll
  llvm/test/Transforms/InstCombine/vscale_sext_and_zext.ll
  llvm/test/Transforms/InstCombine/vscale_trunc.ll
  llvm/test/Transforms/LoopVectorize/AArch64/first-order-recurrence.ll
  llvm/test/Transforms/LoopVectorize/AArch64/scalable-strict-fadd.ll
  llvm/test/Transforms/LoopVectorize/AArch64/scalable-vectorization.ll
  llvm/test/Transforms/LoopVectorize/AArch64/scalable-vf-hint.ll
  llvm/test/Transforms/LoopVectorize/AArch64/sve-cond-inv-loads.ll
  llvm/test/Transforms/LoopVectorize/AArch64/sve-gather-scatter.ll
  llvm/test/Transforms/LoopVectorize/AArch64/sve-inv-store.ll
  llvm/test/Transforms/LoopVectorize/AArch64/sve-large-strides.ll
  llvm/test/Transforms/LoopVectorize/AArch64/sve-strict-fadd-cost.ll
  llvm/test/Transforms/LoopVectorize/AArch64/sve-widen-phi.ll
  llvm/test/Verifier/vscale_range.ll

Index: llvm/test/Verifier/vscale_range.ll
===
--- llvm/test/Verifier/vscale_range.ll
+++ llvm/test/Verifier/vscale_range.ll
@@ -1,4 +1,7 @@
 ; RUN: not llvm-as %s -o /dev/null 2>&1 | FileCheck %s
 
+; CHECK: 'vscale_range' minimum must be greater than 0
+declare i8* @a(i32*) vscale_range(0, 1)
+
 ; CHECK: 'vscale_range' minimum cannot be greater than maximum
 declare i8* @b(i32*) vscale_range(8, 1)
Index: llvm/test/Transforms/LoopVectorize/AArch64/sve-widen-phi.ll
===
--- llvm/test/Transforms/LoopVectorize/AArch64/sve-widen-phi.ll
+++ llvm/test/Transforms/LoopVectorize/AArch64/sve-widen-phi.ll
@@ -175,7 +175,7 @@
   ret i32 %tmp5
 }
 
-attributes #0 = { vscale_range(0, 16) }
+attributes #0 = { vscale_range(1, 16) }
 !0 = distinct !{!0, !1, !2, !3, !4, !5}
 !1 = !{!"llvm.loop.mustprogress"}
 !2 = !{!"llvm.loop.vectorize.width", i32 4}
Index: llvm/test/Transforms/LoopVectorize/AArch64/sve-strict-fadd-cost.ll
===
--- llvm/test/Transforms/LoopVectorize/AArch64/sve-strict-fadd-cost.ll
+++ llvm/test/Transforms/LoopVectorize/AArch64/sve-strict-fadd-cost.ll
@@ -53,7 +53,7 @@
   ret double %add
 }
 
-attributes #0 = { "target-features"="+sve" vscale_range(0, 16) }
+attributes #0 = { "target-features"="+sve" vscale_range(1, 16) }
 
 !0 = distinct !{!0, !1}
 !1 = !{!"llvm.loop.vectorize.scalable.enable", i1 true}
Index: llvm/test/Transforms/LoopVectorize/AArch64/sve-large-strides.ll
===
--- llvm/test/Transforms/LoopVectorize/AArch64/sve-large-strides.ll
+++ llvm/test/Transforms/LoopVectorize/AArch64/sve-large-strides.ll
@@ -90,7 +90,7 @@
   ret void
 }
 
-attributes #0 = { vscale_range(0, 16) }
+attributes #0 = { vscale_range(1, 16) }
 !0 = distinct !{!0, !1, !2, !3, !4, !5}
 !1 = !{!"llvm.loop.mustprogress"}
 !2 = !{!"llvm.loop.vectorize.width", i32 4}
Index: llvm/test/Transforms/LoopVectorize/AArch64/sve-inv-store.ll
===
--- llvm/test/Transforms/LoopVectorize/AArch64/sve-inv-store.ll
+++ llvm/test/Transforms/LoopVectorize/AArch64/sve-inv-store.ll
@@ -59,7 +59,7 @@
   ret void
 }
 
-attributes #0 = { "target-features"="+neon,+sve" vscale_range(0, 16) }
+attributes #0 = { "target-features"="+neon,+sve" vscale_range(1, 16) }
 
 !0 = distinct !{!0, !1, !2, !3, !4, !5}
 !1 = !{!"llvm.loop.mustprogress"}
Index: llvm/test/Transforms/LoopVectorize/AArch64/sve-gather-scatter.ll
===
--- llvm/test/Transforms/LoopVectorize/AArch64/sve-gather-scatter.ll
+++ llvm/test/Transforms/LoopVectorize/AArch64/sve-gather-scatter.ll
@@ -153,7 +153,7 @@
   ret void
 }
 
-attributes #0 = { vscale_range(0, 16) }
+attributes #0 = { vscale_range(1, 16) }
 
 !0 = distinct !{!0, !1, !2, !3, !4, !5}
 !1 = !{!"llvm.loop.mustprogress"}
Index: llvm/test/Transforms/LoopVectorize/AArch64/sve-cond-inv-loads.ll
===
--- llvm/test/Transforms/LoopVectorize/AArch64/sve-cond-inv-loads.ll
+++ llvm/test/Transforms/LoopVectorize/AArch64/sve-cond-inv-loads.ll
@@ -117,7 +117,7 @@
   ret void
 }
 
-attributes #0 = 

[PATCH] D113294: [IR] Remove unbounded as possible value for vscale_range minimum

[Cullen Rhodes via Phabricator via cfe-commits]

c-rhodes marked 4 inline comments as done.
c-rhodes added a comment.

In D113294#3115354 , @sdesmalen wrote:

> It would be nice if the LLVM interfaces could be updated as well (could also 
> be done in a follow-up patch)

Thanks for reviewing, I'll create a follow-up patch to update the interfaces.


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

https://reviews.llvm.org/D113294

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

[PATCH] D110155: [OpenCL] Allow optional __generic in __remove_address_space utility

[Carlos Galvez via Phabricator via cfe-commits]

carlosgalvezp added a comment.

Hi! I believe this commit broke a number of CI jobs, would you be able to look 
into it?

https://lab.llvm.org/buildbot/#/builders/52/builds/12263


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110155

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

[PATCH] D110155: [OpenCL] Allow optional __generic in __remove_address_space utility

[Justas Janickas via Phabricator via cfe-commits]

Topotuna added a comment.

In D110155#3117786 , @carlosgalvezp 
wrote:

> Hi! I believe this commit broke a number of CI jobs, would you be able to 
> look into it?
>
> https://lab.llvm.org/buildbot/#/builders/52/builds/12263

Hi, I am aware it broke some of the builds. However, I cannot recreate the 
issue locally. Planning to revert the change shortly to investigate it further


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110155

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

[clang] d85d57e - Revert "[OpenCL] Allow optional __generic in __remove_address_space utility"

[Justas Janickas via cfe-commits]

Author: Justas Janickas
Date: 2021-11-09T09:42:17Z
New Revision: d85d57e98789d187cac415d9d8a0973ae6f2e4e1

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

LOG: Revert "[OpenCL] Allow optional __generic in __remove_address_space 
utility"

This reverts commit 81081daef0299ad59fca299c7cde3888fa691c6a.

Added: 


Modified: 
clang/lib/Headers/opencl-c-base.h
clang/test/CodeGenOpenCLCXX/remove-address-space.clcpp

Removed: 




diff  --git a/clang/lib/Headers/opencl-c-base.h 
b/clang/lib/Headers/opencl-c-base.h
index 7485386c82346..9c81ddb5e2a73 100644
--- a/clang/lib/Headers/opencl-c-base.h
+++ b/clang/lib/Headers/opencl-c-base.h
@@ -600,11 +600,9 @@ typedef struct {
 // C++ for OpenCL - __remove_address_space
 #if defined(__OPENCL_CPP_VERSION__)
 template  struct __remove_address_space { using type = _Tp; };
-#if defined(__opencl_c_generic_address_space)
 template  struct __remove_address_space<__generic _Tp> {
   using type = _Tp;
 };
-#endif
 template  struct __remove_address_space<__global _Tp> {
   using type = _Tp;
 };

diff  --git a/clang/test/CodeGenOpenCLCXX/remove-address-space.clcpp 
b/clang/test/CodeGenOpenCLCXX/remove-address-space.clcpp
index 9043a7d53c682..f6f0c3290aa66 100644
--- a/clang/test/CodeGenOpenCLCXX/remove-address-space.clcpp
+++ b/clang/test/CodeGenOpenCLCXX/remove-address-space.clcpp
@@ -1,6 +1,4 @@
-// RUN: %clang_cc1 %s -cl-std=clc++1.0 -fdeclare-opencl-builtins 
-finclude-default-header
-// RUN: %clang_cc1 %s -cl-std=clc++2021 -fdeclare-opencl-builtins 
-finclude-default-header
-// RUN: %clang_cc1 %s -cl-std=clc++2021 
-cl-ext=-__opencl_c_generic_address_space,-__opencl_c_pipes 
-fdeclare-opencl-builtins -finclude-default-header
+// RUN: %clang_cc1 %s -cl-std=clc++ -fdeclare-opencl-builtins 
-finclude-default-header
 
 template
 struct is_same {
@@ -21,10 +19,8 @@ void test_is_same() {
 void test_remove_address_space() {
   static_assert(is_same<__remove_address_space::type, int>::value,
 "type without an address space unexpectedly modified by 
__remove_address_space");
-#if defined(__opencl_c_generic_address_space)
   static_assert(is_same<__remove_address_space<__generic int>::type, 
int>::value,
 "__generic address space not removed by 
__remove_address_space");
-#endif
   static_assert(is_same<__remove_address_space<__global char>::type, 
char>::value,
 "__global address space not removed by 
__remove_address_space");
   static_assert(is_same<__remove_address_space<__private ulong>::type, 
ulong>::value,



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

[PATCH] D112915: [clang][modules] Track number of includes per submodule

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 marked 2 inline comments as done.
jansvoboda11 added a comment.

Thanks for your feedback @dexonsmith. I reworked the patch to use more sensible 
data structures as suggested, and made the AST deserialization lazy (on 
(sub)module import).

I think the only thing to figure out is the exact structure of the serialized 
information - whether we're fine with serializing all transitively included 
files in each AST file, or whether we'd like to fetch that information from 
other AST files instead.

I removed the WIP tag and would be happy to gather more feedback.




Comment at: clang/include/clang/Lex/Preprocessor.h:720-723
+  /// Efficient map with FileEntry keys.
+  template  class FileEntryMap {
+/// The underlying storage. Entries are indexed by FileEntry UID.
+std::vector UIDToValue;

dexonsmith wrote:
> I'm not sure about this choice. UIDs are unlikely to be adjacent and in 
> SubmoduleIncludeState, since a given submodule is unlikely to have "most" 
> files. Also, memory usage characteristics could be "weird" if the FileManager 
> is being reused between different compilations.
> 
> `DenseMap` will have the same number of allocations 
> (i.e., just 1). If UIDs really are dense and near each other in one of the 
> submodules then that map will be a little bigger than necessary (~2x), but it 
> should be better for the rest of them.
You're right that UIDs of files included in a single submodule are unlikely to 
have "most" files. Thanks for pointing that out.

In the latest revision, I switched to `llvm::DenseMap`.



Comment at: clang/lib/Lex/Preprocessor.cpp:1323
+auto &ModNumIncludes = SubmoduleIncludeStates[M].NumIncludes;
+for (unsigned UID = 0; UID <= ModNumIncludes.maxUID(); ++UID) {
+  CurSubmoduleIncludeState->NumIncludes[UID] += ModNumIncludes[UID];

dexonsmith wrote:
> jansvoboda11 wrote:
> > Iterating over all FileEntries is probably not very efficient, as Volodymyr 
> > mentioned. Thinking about how to make this more efficient...
> My suggestion above to drop FileEntryMap in favour of a simple DenseMap would 
> help a bit, just iterating through the files actually included by the 
> submodules.
> 
> Further, I wonder if "num-includes"/file/submodule (`unsigned`) is actually 
> useful, vs. "was-included"/file/submodule (`bool`). The only observer I see 
> is `HeaderSearch::PrintStats()` but maybe I missed something?
> 
> If I'm right and we can switch to `bool`, then NumIncludes becomes a 
> `DenseSet IncludedFiles` (or `DenseSet` for UIDs). 
> (BTW, I also wondered if you could rotate the map, using File as the outer 
> key, and then use bitsets for the sbumodules, but I doubt this is better, 
> since most files are only included by a few submodules, right?)
> 
> Then you can just do a set union here. Also simplifies bitcode serialization.
> 
> (If a `bool`/set is sufficient, then I'd suggest landing that 
> first/separately, before adding the per-submodule granularity in this patch.)
For each file, we need to have three distinct states: not included at all, 
included exactly once (`firstTimeLexingFile`), included more than once. This 
means we can't use a single `DenseSet`.

But we could use a `DenseMap`, where "not included at all" can be 
expressed as being absent from the map, exactly once as having `true` in the 
map and more than once as having `false` in the map. Alternatively, we could 
use two `DenseSet` instances to encode the same, but I don't think having two 
lookups per file to determine stuff is efficient.

I can look into this in a follow-up patch.



Comment at: clang/lib/Serialization/ASTWriter.cpp:2392-2393
+
+  // TODO: Use plain vector, submodule IDs are small and dense.
+  std::map> ToBeSerialized;
+

dexonsmith wrote:
> A vector of maps would be an improvement, but that'll still be a lot of 
> allocations.
> - Since insertion/lookup/deletion aren't intermingled, the simplest way to 
> avoid adding unnecessary overhead is a sorted vector 
> (https://llvm.org/docs/ProgrammersManual.html#dss-sortedvectormap).
> - With no lookups (at all), there's no benefit to a tiered data structure (vs 
> flat).
> 
> Leading me toward a simple flat vector + sort.
> ```
> lang=c++
> struct IncludeToSerialize { // Probably more straightforward than a 
> std::tuple...
>   StringRef Filename;
>   unsigned SMID;
>   unsigned NumIncludes;
> 
>   bool operator<(const IncludeToSerialize &RHS) const {
> if (SMID != RHS.SMID)
>   return SMID < RHS.SMID;
> int Diff = Filename.compare(RHS.Filename);
> assert(Diff && "Expected unique SMID / Filename pairs");
> return Diff < 0;
>   }
> };
> SmallVector IncludesToSerialize;
> // ...
> IncludesToSerialize.push_back({Filename, LocalSMID, NumIncludes});
> // ...
> llvm::sort(IncludesToSerialize);
> for (const IncludeToSerialize &SI : IncludesToSerialize) {
>   // emit record
> }
> ```
> (Or i

[PATCH] D113472: [clang-tidy] Fix lint warning in ClangTidyDiagnosticConsumer.cpp (NFC)

[Salman Javed via Phabricator via cfe-commits]

salman-javed-nz created this revision.
salman-javed-nz added a reviewer: carlosgalvezp.
salman-javed-nz added a project: clang-tools-extra.
Herald added a subscriber: xazax.hun.
salman-javed-nz requested review of this revision.

Calling clang-tidy on ClangTidyDiagnosticConsumer.cpp gives a
"unmatched NOLINTBEGIN without a subsequent NOLINTEND" warning.

The "NOLINTBEGIN" and "NOLINTEND" string literals used in the
implementation of `createNolintError()` get mistaken for actual
NOLINTBEGIN/END comments used to suppress clang-tidy warnings.

Rewrite the string literals so that they can no longer be mistaken for
actual suppression comments.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D113472

Files:
  clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp


Index: clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
===
--- clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
+++ clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
@@ -374,13 +374,11 @@
 bool IsNolintBegin) {
   ClangTidyError Error("clang-tidy-nolint", ClangTidyError::Error,
Context.getCurrentBuildDirectory(), false);
-  StringRef Message =
-  IsNolintBegin
-  ? "unmatched 'NOLINTBEGIN' comment without a subsequent 'NOLINTEND' "
-"comment"
-  : "unmatched 'NOLINTEND' comment without a previous 'NOLINTBEGIN' "
-"comment";
-  Error.Message = tooling::DiagnosticMessage(Message, SM, Loc);
+  auto Message = Twine("unmatched 'NOLINT") +
+ (IsNolintBegin ? "BEGIN" : "END") + "' comment without a " +
+ (IsNolintBegin ? "subsequent" : "previous") + " 'NOLINT" +
+ (IsNolintBegin ? "END" : "BEGIN") + "' comment";
+  Error.Message = tooling::DiagnosticMessage(Message.str(), SM, Loc);
   return Error;
 }
 


Index: clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
===
--- clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
+++ clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
@@ -374,13 +374,11 @@
 bool IsNolintBegin) {
   ClangTidyError Error("clang-tidy-nolint", ClangTidyError::Error,
Context.getCurrentBuildDirectory(), false);
-  StringRef Message =
-  IsNolintBegin
-  ? "unmatched 'NOLINTBEGIN' comment without a subsequent 'NOLINTEND' "
-"comment"
-  : "unmatched 'NOLINTEND' comment without a previous 'NOLINTBEGIN' "
-"comment";
-  Error.Message = tooling::DiagnosticMessage(Message, SM, Loc);
+  auto Message = Twine("unmatched 'NOLINT") +
+ (IsNolintBegin ? "BEGIN" : "END") + "' comment without a " +
+ (IsNolintBegin ? "subsequent" : "previous") + " 'NOLINT" +
+ (IsNolintBegin ? "END" : "BEGIN") + "' comment";
+  Error.Message = tooling::DiagnosticMessage(Message.str(), SM, Loc);
   return Error;
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113473: [clang][deps] Don't emit `-fmodule-map-file=`

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 created this revision.
jansvoboda11 added reviewers: Bigcheese, dexonsmith, vsapsai, bnbarham.
jansvoboda11 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

During explicit modules build, when all modules are provided via 
`-fmodule-file=` and implicit modules and implicit module maps are 
disabled (`-fno-implicit-modules`, `-fno-implicit-module-maps`), we don't need 
to load the original module map files at all. This patch stops emitting the 
`-fmodule-map-file=` arguments we don't need, saving some compilation time due 
to avoiding parsing such module maps.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D113473

Files:
  clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
  clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
  clang/test/ClangScanDeps/modules-fmodule-name-no-module-built.m
  clang/test/ClangScanDeps/modules-full.cpp
  clang/test/ClangScanDeps/modules-inferred.m
  clang/test/ClangScanDeps/modules-pch-common-submodule.c
  clang/test/ClangScanDeps/modules-pch-common-via-submodule.c
  clang/test/ClangScanDeps/modules-pch.c

Index: clang/test/ClangScanDeps/modules-pch.c
===
--- clang/test/ClangScanDeps/modules-pch.c
+++ clang/test/ClangScanDeps/modules-pch.c
@@ -59,7 +59,6 @@
 // CHECK-PCH-NEXT:   "clang-modulemap-file": "[[PREFIX]]/module.modulemap",
 // CHECK-PCH-NEXT:   "command-line": [
 // CHECK-PCH-NEXT: "-cc1"
-// CHECK-PCH:  "-fmodule-map-file=[[PREFIX]]/module.modulemap"
 // CHECK-PCH:  "-emit-module"
 // CHECK-PCH:  "-fmodule-file=[[PREFIX]]/build/[[HASH_MOD_COMMON_2]]/ModCommon2-{{.*}}.pcm"
 // CHECK-PCH:  "-fmodules"
@@ -92,10 +91,7 @@
 // CHECK-PCH-NEXT: "-fno-implicit-module-maps",
 // CHECK-PCH-NEXT: "-fmodule-file=[[PREFIX]]/build/[[HASH_MOD_COMMON_1]]/ModCommon1-{{.*}}.pcm",
 // CHECK-PCH-NEXT: "-fmodule-file=[[PREFIX]]/build/[[HASH_MOD_COMMON_2]]/ModCommon2-{{.*}}.pcm",
-// CHECK-PCH-NEXT: "-fmodule-file=[[PREFIX]]/build/[[HASH_MOD_PCH]]/ModPCH-{{.*}}.pcm",
-// CHECK-PCH-NEXT: "-fmodule-map-file=[[PREFIX]]/module.modulemap",
-// CHECK-PCH-NEXT: "-fmodule-map-file=[[PREFIX]]/module.modulemap",
-// CHECK-PCH-NEXT: "-fmodule-map-file=[[PREFIX]]/module.modulemap"
+// CHECK-PCH-NEXT: "-fmodule-file=[[PREFIX]]/build/[[HASH_MOD_PCH]]/ModPCH-{{.*}}.pcm"
 // CHECK-PCH-NEXT:   ],
 // CHECK-PCH-NEXT:   "file-deps": [
 // CHECK-PCH-NEXT: "[[PREFIX]]/pch.h"
@@ -163,8 +159,7 @@
 // CHECK-TU-NEXT:   "command-line": [
 // CHECK-TU-NEXT: "-fno-implicit-modules",
 // CHECK-TU-NEXT: "-fno-implicit-module-maps",
-// CHECK-TU-NEXT: "-fmodule-file=[[PREFIX]]/build/[[HASH_MOD_TU]]/ModTU-{{.*}}.pcm",
-// CHECK-TU-NEXT: "-fmodule-map-file=[[PREFIX]]/module.modulemap"
+// CHECK-TU-NEXT: "-fmodule-file=[[PREFIX]]/build/[[HASH_MOD_TU]]/ModTU-{{.*}}.pcm"
 // CHECK-TU-NEXT:   ],
 // CHECK-TU-NEXT:   "file-deps": [
 // CHECK-TU-NEXT: "[[PREFIX]]/tu.c",
@@ -203,7 +198,6 @@
 // CHECK-TU-WITH-COMMON-NEXT:   "clang-modulemap-file": "[[PREFIX]]/module.modulemap",
 // CHECK-TU-WITH-COMMON-NEXT:   "command-line": [
 // CHECK-TU-WITH-COMMON-NEXT: "-cc1",
-// CHECK-TU-WITH-COMMON:  "-fmodule-map-file=[[PREFIX]]/module.modulemap"
 // CHECK-TU-WITH-COMMON:  "-emit-module",
 // CHECK-TU-WITH-COMMON:  "-fmodule-file=[[PREFIX]]/build/{{.*}}/ModCommon1-{{.*}}.pcm",
 // CHECK-TU-WITH-COMMON:  "-fmodule-name=ModTUWithCommon",
@@ -230,9 +224,7 @@
 // CHECK-TU-WITH-COMMON-NEXT: "-fno-implicit-modules",
 // CHECK-TU-WITH-COMMON-NEXT: "-fno-implicit-module-maps",
 // CHECK-TU-WITH-COMMON-NEXT: "-fmodule-file=[[PREFIX]]/build/{{.*}}/ModCommon2-{{.*}}.pcm",
-// CHECK-TU-WITH-COMMON-NEXT: "-fmodule-map-file=[[PREFIX]]/module.modulemap"
-// CHECK-TU-WITH-COMMON-NEXT: "-fmodule-file=[[PREFIX]]/build/[[HASH_MOD_TU_WITH_COMMON]]/ModTUWithCommon-{{.*}}.pcm",
-// CHECK-TU-WITH-COMMON-NEXT: "-fmodule-map-file=[[PREFIX]]/module.modulemap"
+// CHECK-TU-WITH-COMMON-NEXT: "-fmodule-file=[[PREFIX]]/build/[[HASH_MOD_TU_WITH_COMMON]]/ModTUWithCommon-{{.*}}.pcm"
 // CHECK-TU-WITH-COMMON-NEXT:   ],
 // CHECK-TU-WITH-COMMON-NEXT:   "file-deps": [
 // CHECK-TU-WITH-COMMON-NEXT: "[[PREFIX]]/tu_with_common.c",
Index: clang/test/ClangScanDeps/modules-pch-common-via-submodule.c
===
--- clang/test/ClangScanDeps/modules-pch-common-via-submodule.c
+++ clang/test/ClangScanDeps/modules-pch-common-via-submodule.c
@@ -47,7 +47,6 @@
 // CHECK-PCH-NEXT: "-fno-implicit-modules"
 // CHECK-PCH-NEXT: "-fno-implicit-module-maps"
 // CHECK-PCH-NEXT: "-fmodule-file=[[PREFIX]]

[PATCH] D113474: [clang] Don't crash on an incomplete-type base specifier in template context.

[Haojian Wu via Phabricator via cfe-commits]

hokein created this revision.
hokein added a reviewer: sammccall.
hokein requested review of this revision.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D113474

Files:
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/test/SemaCXX/base-class-ambiguity-check.cpp
  clang/test/SemaCXX/ms-interface.cpp


Index: clang/test/SemaCXX/ms-interface.cpp
===
--- clang/test/SemaCXX/ms-interface.cpp
+++ clang/test/SemaCXX/ms-interface.cpp
@@ -106,3 +106,10 @@
 static_assert(!__is_interface_class(IUnknown), "oops");
 static_assert(!__is_interface_class(IFaceStruct), "oops");
 static_assert(!__is_interface_class(IFaceInheritsStruct), "oops");
+
+template
+class TemplateContext {
+  class Base;
+  // Should not crash on an incomplete-type base specifier.
+  __interface Foo : Base {};
+};
Index: clang/test/SemaCXX/base-class-ambiguity-check.cpp
===
--- clang/test/SemaCXX/base-class-ambiguity-check.cpp
+++ clang/test/SemaCXX/base-class-ambiguity-check.cpp
@@ -7,3 +7,11 @@
   // Test that this code no longer causes a crash in Sema. rdar://23291875
   struct Derived : Base, T {};
 };
+
+
+template  class Foo2 {
+  struct Base;
+
+  // Should not crash on an incomplete-type base specifier.
+  struct Derived : Base {};
+};
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -2729,6 +2729,10 @@
   KnownBase = Bases[idx];
   Bases[NumGoodBases++] = Bases[idx];
 
+  if (NewBaseType->isIncompleteType()) {
+assert(NewBaseType->isDependentType());
+continue;
+  }
   // Note this base's direct & indirect bases, if there could be ambiguity.
   if (Bases.size() > 1)
 NoteIndirectBases(Context, IndirectBaseTypes, NewBaseType);


Index: clang/test/SemaCXX/ms-interface.cpp
===
--- clang/test/SemaCXX/ms-interface.cpp
+++ clang/test/SemaCXX/ms-interface.cpp
@@ -106,3 +106,10 @@
 static_assert(!__is_interface_class(IUnknown), "oops");
 static_assert(!__is_interface_class(IFaceStruct), "oops");
 static_assert(!__is_interface_class(IFaceInheritsStruct), "oops");
+
+template
+class TemplateContext {
+  class Base;
+  // Should not crash on an incomplete-type base specifier.
+  __interface Foo : Base {};
+};
Index: clang/test/SemaCXX/base-class-ambiguity-check.cpp
===
--- clang/test/SemaCXX/base-class-ambiguity-check.cpp
+++ clang/test/SemaCXX/base-class-ambiguity-check.cpp
@@ -7,3 +7,11 @@
   // Test that this code no longer causes a crash in Sema. rdar://23291875
   struct Derived : Base, T {};
 };
+
+
+template  class Foo2 {
+  struct Base;
+
+  // Should not crash on an incomplete-type base specifier.
+  struct Derived : Base {};
+};
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -2729,6 +2729,10 @@
   KnownBase = Bases[idx];
   Bases[NumGoodBases++] = Bases[idx];
 
+  if (NewBaseType->isIncompleteType()) {
+assert(NewBaseType->isDependentType());
+continue;
+  }
   // Note this base's direct & indirect bases, if there could be ambiguity.
   if (Bases.size() > 1)
 NoteIndirectBases(Context, IndirectBaseTypes, NewBaseType);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113429: [clang-tidy] Use `hasCanonicalType()` matcher in `bugprone-unused-raii` check

[Simon Giesecke via Phabricator via cfe-commits]

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

LGTM, thanks a lot!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113429

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

[PATCH] D113473: [clang][deps] Don't emit `-fmodule-map-file=`

[Ben Barham via Phabricator via cfe-commits]

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

That was quick! Seems reasonable to me -hopefully there's not some strange case 
where this wouldn't work, will be nice to avoid the parsing time (which 
actually isn't insignificant).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113473

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

[PATCH] D112915: [clang][modules] Track number of includes per submodule

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 updated this revision to Diff 385751.
jansvoboda11 marked an inline comment as done.
jansvoboda11 added a comment.

Make clang-format happy.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112915

Files:
  clang/include/clang/Lex/ExternalPreprocessorSource.h
  clang/include/clang/Lex/HeaderSearch.h
  clang/include/clang/Lex/Preprocessor.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/include/clang/Serialization/ASTReader.h
  clang/include/clang/Serialization/ASTWriter.h
  clang/include/clang/Serialization/ModuleFile.h
  clang/lib/Lex/HeaderSearch.cpp
  clang/lib/Lex/PPDirectives.cpp
  clang/lib/Lex/PPLexerChange.cpp
  clang/lib/Lex/Preprocessor.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/Modules/import-submodule-visibility.c

Index: clang/test/Modules/import-submodule-visibility.c
===
--- /dev/null
+++ clang/test/Modules/import-submodule-visibility.c
@@ -0,0 +1,80 @@
+// This test checks that imports of headers that appeared in a different submodule than
+// what is imported by the current TU don't affect the compilation.
+
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+
+//--- A.framework/Headers/A.h
+#include "Textual.h"
+//--- A.framework/Modules/module.modulemap
+framework module A { header "A.h" }
+
+//--- B.framework/Headers/B1.h
+#include "Textual.h"
+//--- B.framework/Headers/B2.h
+//--- B.framework/Modules/module.modulemap
+framework module B {
+  module B1 { header "B1.h" }
+  module B2 { header "B2.h" }
+}
+
+//--- C/C.h
+#include "Textual.h"
+//--- C/module.modulemap
+module C { header "C.h" }
+
+//--- D/D1.h
+#include "Textual.h"
+//--- D/D2.h
+//--- D/module.modulemap
+module D {
+  module D1 { header "D1.h" }
+  module D2 { header "D2.h" }
+}
+
+//--- Textual.h
+#define MACRO_TEXTUAL 1
+
+//--- test.c
+
+#ifdef A
+//
+#endif
+
+#ifdef B
+#import 
+#endif
+
+#ifdef C
+//
+#endif
+
+#ifdef D
+#import "D/D2.h"
+#endif
+
+#import "Textual.h"
+
+static int x = MACRO_TEXTUAL;
+
+// Specifying the PCM file on the command line (without actually importing "A") should not
+// prevent "Textual.h" to be included in the TU.
+//
+// RUN: %clang_cc1 -fmodules -I %t -emit-module %t/A.framework/Modules/module.modulemap -fmodule-name=A -o %t/A.pcm
+// RUN: %clang_cc1 -fmodules -I %t -fsyntax-only %t/test.c -DA -fmodule-file=%t/A.pcm -fmodule-map-file=%t/A.framework/Modules/module.modulemap
+
+// Specifying the PCM file on the command line and importing "B2" in the source does not
+// prevent "Textual.h" to be included in the TU.
+//
+// RUN: %clang_cc1 -fmodules -I %t -emit-module %t/B.framework/Modules/module.modulemap -fmodule-name=B -o %t/B.pcm
+// RUN: %clang_cc1 -fmodules -I %t -fsyntax-only %t/test.c -DB -iframework %t -fmodule-file=%t/B.pcm -fmodule-map-file=%t/B.framework/Modules/module.modulemap
+
+// Module-only version of the test with framework A.
+//
+// RUN: %clang_cc1 -fmodules -I %t -emit-module %t/C/module.modulemap -fmodule-name=C -o %t/C.pcm
+// RUN: %clang_cc1 -fmodules -I %t -fsyntax-only %t/test.c -DC -fmodule-file=%t/C.pcm -fmodule-map-file=%t/C/module.modulemap
+
+// Module-only version of the test with framework B.
+//
+// RUN: %clang_cc1 -fmodules -I %t -emit-module %t/D/module.modulemap -fmodule-name=D -o %t/D.pcm
+// RUN: %clang_cc1 -fmodules -I %t -fsyntax-only %t/test.c -DD -fmodule-file=%t/D.pcm -fmodule-map-file=%t/D/module.modulemap
Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -1696,7 +1696,7 @@
 std::pair
 EmitKeyDataLength(raw_ostream& Out, key_type_ref key, data_type_ref Data) {
   unsigned KeyLen = key.Filename.size() + 1 + 8 + 8;
-  unsigned DataLen = 1 + 2 + 4 + 4;
+  unsigned DataLen = 1 + 4 + 4;
   for (auto ModInfo : Data.KnownHeaders)
 if (Writer.getLocalOrImportedSubmoduleID(ModInfo.getModule()))
   DataLen += 4;
@@ -1728,7 +1728,6 @@
   | (Data.HFI.DirInfo << 1)
   | Data.HFI.IndexHeaderMapHeader;
   LE.write(Flags);
-  LE.write(Data.HFI.NumIncludes);
 
   if (!Data.HFI.ControllingMacro)
 LE.write(Data.HFI.ControllingMacroID);
@@ -2171,6 +2170,35 @@
   return false;
 }
 
+void ASTWriter::addIncludedFiles(
+const llvm::DenseMap &Files,
+RecordDataImpl &Record) {
+  auto Vec = llvm::to_vector<0>(Files);
+
+  // Ensure the order is stable.
+  llvm::sort(Vec, [](const auto &LHS, const auto &RHS) {
+return LHS.first->getName().compare(RHS.first->getName()) < 0;
+  });
+
+  // The first partition contains files included exactly once,
+  // the second partition contains files included more than once.
+  auto It = std::stable_partition(Vec.begin(), Vec.end(),
+

[PATCH] D113472: [clang-tidy] Fix lint warning in ClangTidyDiagnosticConsumer.cpp (NFC)

[Carlos Galvez via Phabricator via cfe-commits]

carlosgalvezp added a comment.

Hmm, this sounds a bit hacky. I noticed a similar pattern in tests. I think it 
deteriorates readability a bit.

Can we make the detection of the tag more robust? Right now we check if a line 
contains NOLINTBEGIN/END. Why not check if it contains "// NOLINTBEGIN"? (// as 
part of the line).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113472

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

[PATCH] D113391: [Modules] Don't support clang module and c++20 module at the same time

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 added inline comments.



Comment at: clang/test/ClangScanDeps/Inputs/header-search-pruning/cdb.json:1
-[
-  {
-"directory": "DIR",
-"command": "clang -E DIR/header-search-pruning.cpp -Ibegin -I1 -Ia -I3 -I4 
-I5 -I6 -Ib -I8 -Iend DEFINES -fmodules -fcxx-modules 
-fmodules-cache-path=DIR/module-cache -fimplicit-modules 
-fmodule-map-file=DIR/module.modulemap",
-"file": "DIR/header-search-pruning.cpp"
-  }
-]
+[{
+  "directory" : "DIR",

Please undo the whitespace changes in `ClangScanDeps` tests.



Comment at: clang/test/ClangScanDeps/Inputs/header-search-pruning/cdb.json:3
+  "directory" : "DIR",
+  "command" : "clang -E DIR/header-search-pruning.cpp -Ibegin -I1 -Ia -I3 -I4 
-I5 -I6 -Ib -I8 -Iend DEFINES -fmodules -fmodules-cache-path=DIR/module-cache 
-fimplicit-modules -fmodule-map-file=DIR/module.modulemap",
+  "file" : "DIR/header-search-pruning.cpp"

Can you explain why `-fcxx-modules` is removed? We want to explicitly enable 
Clang modules for C++ inputs here. That's off by default in our downstream repo 
and we'd like to keep this upstream to prevent conflicts. (it's benign upstream)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113391

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

[PATCH] D113391: [Modules] Don't support clang module and c++20 module at the same time

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added inline comments.



Comment at: clang/test/ClangScanDeps/Inputs/header-search-pruning/cdb.json:1
-[
-  {
-"directory": "DIR",
-"command": "clang -E DIR/header-search-pruning.cpp -Ibegin -I1 -Ia -I3 -I4 
-I5 -I6 -Ib -I8 -Iend DEFINES -fmodules -fcxx-modules 
-fmodules-cache-path=DIR/module-cache -fimplicit-modules 
-fmodule-map-file=DIR/module.modulemap",
-"file": "DIR/header-search-pruning.cpp"
-  }
-]
+[{
+  "directory" : "DIR",

jansvoboda11 wrote:
> Please undo the whitespace changes in `ClangScanDeps` tests.
It looks like that it's formatted by clang-format surprisingly. I would undo 
this manually.



Comment at: clang/test/ClangScanDeps/Inputs/header-search-pruning/cdb.json:3
+  "directory" : "DIR",
+  "command" : "clang -E DIR/header-search-pruning.cpp -Ibegin -I1 -Ia -I3 -I4 
-I5 -I6 -Ib -I8 -Iend DEFINES -fmodules -fmodules-cache-path=DIR/module-cache 
-fimplicit-modules -fmodule-map-file=DIR/module.modulemap",
+  "file" : "DIR/header-search-pruning.cpp"

jansvoboda11 wrote:
> Can you explain why `-fcxx-modules` is removed? We want to explicitly enable 
> Clang modules for C++ inputs here. That's off by default in our downstream 
> repo and we'd like to keep this upstream to prevent conflicts. (it's benign 
> upstream)
According to the discussion in the link, I think it is in consensus that we 
decide to not support clang modules and c++20 modules at the same time. (I know 
many people may not have visited it. If any one disagree with the higher idea, 
I think it would be better to reply in that thread). 
So the original test case would fail.

> We want to explicitly enable Clang modules for C++ inputs here. 

I am not sure if I missed any thing. Personally, it looks like the test now 
would test clang modules for c++ inputs. Since it has `-fmodule` option so that 
clang module is enabled and the input is C++ (from its suffix). Do I 
misunderstand you?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113391

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

[PATCH] D113477: [clang-tblgen] Fix non-determinism in generating AttributeReference.rst

[Igor Kudrin via Phabricator via cfe-commits]

ikudrin created this revision.
ikudrin added reviewers: aaron.ballman, arphaman, rsmith.
ikudrin added a project: clang.
Herald added a subscriber: mgrang.
ikudrin requested review of this revision.

As for now, the categories are printed in an arbitrary order which depends on 
the addresses of dynamically allocated objects. The patch sorts them in an 
alphabetical order thus making the output stable.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D113477

Files:
  clang/utils/TableGen/ClangAttrEmitter.cpp


Index: clang/utils/TableGen/ClangAttrEmitter.cpp
===
--- clang/utils/TableGen/ClangAttrEmitter.cpp
+++ clang/utils/TableGen/ClangAttrEmitter.cpp
@@ -4433,7 +4433,13 @@
   // Gather the Documentation lists from each of the attributes, based on the
   // category provided.
   std::vector Attrs = Records.getAllDerivedDefinitions("Attr");
-  std::map> SplitDocs;
+  struct CategoryLess {
+bool operator()(const Record *L, const Record *R) const {
+  return L->getValueAsString("Name") < R->getValueAsString("Name");
+}
+  };
+  std::map, CategoryLess>
+  SplitDocs;
   for (const auto *A : Attrs) {
 const Record &Attr = *A;
 std::vector Docs = Attr.getValueAsListOfDefs("Documentation");


Index: clang/utils/TableGen/ClangAttrEmitter.cpp
===
--- clang/utils/TableGen/ClangAttrEmitter.cpp
+++ clang/utils/TableGen/ClangAttrEmitter.cpp
@@ -4433,7 +4433,13 @@
   // Gather the Documentation lists from each of the attributes, based on the
   // category provided.
   std::vector Attrs = Records.getAllDerivedDefinitions("Attr");
-  std::map> SplitDocs;
+  struct CategoryLess {
+bool operator()(const Record *L, const Record *R) const {
+  return L->getValueAsString("Name") < R->getValueAsString("Name");
+}
+  };
+  std::map, CategoryLess>
+  SplitDocs;
   for (const auto *A : Attrs) {
 const Record &Attr = *A;
 std::vector Docs = Attr.getValueAsListOfDefs("Documentation");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113391: [Modules] Don't support clang module and c++20 module at the same time

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 added inline comments.



Comment at: clang/test/ClangScanDeps/Inputs/header-search-pruning/cdb.json:1
-[
-  {
-"directory": "DIR",
-"command": "clang -E DIR/header-search-pruning.cpp -Ibegin -I1 -Ia -I3 -I4 
-I5 -I6 -Ib -I8 -Iend DEFINES -fmodules -fcxx-modules 
-fmodules-cache-path=DIR/module-cache -fimplicit-modules 
-fmodule-map-file=DIR/module.modulemap",
-"file": "DIR/header-search-pruning.cpp"
-  }
-]
+[{
+  "directory" : "DIR",

ChuanqiXu wrote:
> jansvoboda11 wrote:
> > Please undo the whitespace changes in `ClangScanDeps` tests.
> It looks like that it's formatted by clang-format surprisingly. I would undo 
> this manually.
Thanks.



Comment at: clang/test/ClangScanDeps/Inputs/header-search-pruning/cdb.json:3
+  "directory" : "DIR",
+  "command" : "clang -E DIR/header-search-pruning.cpp -Ibegin -I1 -Ia -I3 -I4 
-I5 -I6 -Ib -I8 -Iend DEFINES -fmodules -fmodules-cache-path=DIR/module-cache 
-fimplicit-modules -fmodule-map-file=DIR/module.modulemap",
+  "file" : "DIR/header-search-pruning.cpp"

ChuanqiXu wrote:
> jansvoboda11 wrote:
> > Can you explain why `-fcxx-modules` is removed? We want to explicitly 
> > enable Clang modules for C++ inputs here. That's off by default in our 
> > downstream repo and we'd like to keep this upstream to prevent conflicts. 
> > (it's benign upstream)
> According to the discussion in the link, I think it is in consensus that we 
> decide to not support clang modules and c++20 modules at the same time. (I 
> know many people may not have visited it. If any one disagree with the higher 
> idea, I think it would be better to reply in that thread). 
> So the original test case would fail.
> 
> > We want to explicitly enable Clang modules for C++ inputs here. 
> 
> I am not sure if I missed any thing. Personally, it looks like the test now 
> would test clang modules for c++ inputs. Since it has `-fmodule` option so 
> that clang module is enabled and the input is C++ (from its suffix). Do I 
> misunderstand you?
> According to the discussion in the link, I think it is in consensus that we 
> decide to not support clang modules and c++20 modules at the same time. (I 
> know many people may not have visited it. If any one disagree with the higher 
> idea, I think it would be better to reply in that thread). 
> So the original test case would fail.

What's the error message? As I say, we're enabling Clang modules for C++ input 
here, not C++20 modules.

> > We want to explicitly enable Clang modules for C++ inputs here. 
> 
> I am not sure if I missed any thing. Personally, it looks like the test now 
> would test clang modules for c++ inputs. Since it has `-fmodule` option so 
> that clang module is enabled and the input is C++ (from its suffix). Do I 
> misunderstand you?

Right. What I'm saying is that in our downstream repo, `-fmodules` is not 
enough to enable Clang modules for C++ inputs, you need to do it via 
`-fcxx-modules`. And we'd like to keep it upstream, even though it's benign 
here, to avoid conflicts between the repos.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113391

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

[PATCH] D113391: [Modules] Don't support clang module and c++20 module at the same time

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added inline comments.



Comment at: clang/test/ClangScanDeps/Inputs/header-search-pruning/cdb.json:1
-[
-  {
-"directory": "DIR",
-"command": "clang -E DIR/header-search-pruning.cpp -Ibegin -I1 -Ia -I3 -I4 
-I5 -I6 -Ib -I8 -Iend DEFINES -fmodules -fcxx-modules 
-fmodules-cache-path=DIR/module-cache -fimplicit-modules 
-fmodule-map-file=DIR/module.modulemap",
-"file": "DIR/header-search-pruning.cpp"
-  }
-]
+[{
+  "directory" : "DIR",

jansvoboda11 wrote:
> ChuanqiXu wrote:
> > jansvoboda11 wrote:
> > > Please undo the whitespace changes in `ClangScanDeps` tests.
> > It looks like that it's formatted by clang-format surprisingly. I would 
> > undo this manually.
> Thanks.
Just as a drive by assuming you are using a fairly recent clang-format, then 
clang-format should ONLY clang-format .json files if you have added the 
following code into your .clang-format 

```
BasedOnStyle: LLVM
ColumnLimit: 0
AlwaysBreakTemplateDeclarations: No
Language: Cpp
---
Language: Json
BasedOnStyle: LLVM
```

Doing so would render like this

```
$ clang-format cdb.json
[
  {
"directory": "DIR",
"command": "clang -E DIR/header-search-pruning.cpp -Ibegin -I1 -Ia -I3 -I4 -
I5 -I6 -Ib -I8 -Iend DEFINES -fmodules -fcxx-modules -fmodules-cache-path=DIR/mo
dule-cache -fimplicit-modules -fmodule-map-file=DIR/module.modulemap",
"file": "DIR/header-search-pruning.cpp"
  }
]
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113391

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

[PATCH] D113168: [clang-tblgen] Fix non-determinism in generating AttrSubMatchRulesParserStringSwitches.inc

[Igor Kudrin via Phabricator via cfe-commits]

ikudrin added a comment.

The compiler has to be deterministic and one way to check that is to recompile 
a relatively large project several times. For `clang`, that large project is 
usually `clang` itself, so it has to be compiled in a stable way.

Anyway, I've prepared a fix for generating the documentation, D113477 
. Please, take a look.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113168

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

[PATCH] D113472: [clang-tidy] Fix lint warning in ClangTidyDiagnosticConsumer.cpp (NFC)

[Salman Javed via Phabricator via cfe-commits]

salman-javed-nz added a comment.

clang-tidy looking for `NOLINT` markers but not checking to see that the marker 
is within a comment, is long-standing behaviour at this point.
cpplint has the same behaviour, which explains why clang-tidy's implementation 
started off this way.

That's not to say that we have to keep this way forever. I would love for it to 
be improved.

However, discussing what the new behaviour should be and delivering it is 
beyond the scope of this patch, which is just trying to fix lint warnings in 
the current day framework.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113472

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

[PATCH] D113472: [clang-tidy] Fix lint warning in ClangTidyDiagnosticConsumer.cpp (NFC)

[Salman Javed via Phabricator via cfe-commits]

salman-javed-nz added a comment.

I suspect that ensuring that `NOLINT`s are within a comment could be a 
reasonably large code change. If it is to be robust with `/* multiline comments 
*/`  and other shenanigans, then I would probably lean on the compiler to tell 
us what is and isn't a comment, instead of the simple text search approach we 
currently have.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113472

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

[PATCH] D113474: [clang] Don't crash on an incomplete-type base specifier in template context.

[Sam McCall via Phabricator via cfe-commits]

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



Comment at: clang/test/SemaCXX/base-class-ambiguity-check.cpp:15
+
+  // Should not crash on an incomplete-type base specifier.
+  struct Derived : Base {};

maybe put (dependent) in this comment, as it's the reason this code is valid 
without diagnostics



Comment at: clang/test/SemaCXX/base-class-ambiguity-check.cpp:17
+  struct Derived : Base {};
+};

we're asserting here there are no diagnostics, maybe instantiate the template 
and assert those?



Comment at: clang/test/SemaCXX/ms-interface.cpp:114
+  // Should not crash on an incomplete-type base specifier.
+  __interface Foo : Base {};
+};

is there some tricky interaction with __interface here that justifies testing 
this again? If it's testing the same codepath, I'd say one test is enough


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113474

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

[PATCH] D113472: [clang-tidy] Fix lint warning in ClangTidyDiagnosticConsumer.cpp (NFC)

[Carlos Galvez via Phabricator via cfe-commits]

carlosgalvezp added a comment.

> If it is to be robust with /* multiline comments */

Does it have to be? I don't recall that we have unit tests for that. I would 
personally restrict the usage to only one way to write the line. I think it's 
not hard for users to adapt to that, plus it encourage them to write more 
readable code.

But OK, since it can potentially be a large change let's leave it for another 
time.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113472

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

[PATCH] D113391: [Modules] Don't support clang module and c++20 module at the same time

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added inline comments.



Comment at: clang/test/ClangScanDeps/Inputs/header-search-pruning/cdb.json:1
-[
-  {
-"directory": "DIR",
-"command": "clang -E DIR/header-search-pruning.cpp -Ibegin -I1 -Ia -I3 -I4 
-I5 -I6 -Ib -I8 -Iend DEFINES -fmodules -fcxx-modules 
-fmodules-cache-path=DIR/module-cache -fimplicit-modules 
-fmodule-map-file=DIR/module.modulemap",
-"file": "DIR/header-search-pruning.cpp"
-  }
-]
+[{
+  "directory" : "DIR",

MyDeveloperDay wrote:
> jansvoboda11 wrote:
> > ChuanqiXu wrote:
> > > jansvoboda11 wrote:
> > > > Please undo the whitespace changes in `ClangScanDeps` tests.
> > > It looks like that it's formatted by clang-format surprisingly. I would 
> > > undo this manually.
> > Thanks.
> Just as a drive by assuming you are using a fairly recent clang-format, then 
> clang-format should ONLY clang-format .json files if you have added the 
> following code into your .clang-format 
> 
> ```
> BasedOnStyle: LLVM
> ColumnLimit: 0
> AlwaysBreakTemplateDeclarations: No
> Language: Cpp
> ---
> Language: Json
> BasedOnStyle: LLVM
> ```
> 
> Doing so would render like this
> 
> ```
> $ clang-format cdb.json
> [
>   {
> "directory": "DIR",
> "command": "clang -E DIR/header-search-pruning.cpp -Ibegin -I1 -Ia -I3 
> -I4 -
> I5 -I6 -Ib -I8 -Iend DEFINES -fmodules -fcxx-modules 
> -fmodules-cache-path=DIR/mo
> dule-cache -fimplicit-modules -fmodule-map-file=DIR/module.modulemap",
> "file": "DIR/header-search-pruning.cpp"
>   }
> ]
> ```
Oh, thanks for your kindly guide. But I have updated this manually hhh. BTW, 
the clang-format I am using is:
```
git diff -U0 --no-color --relative HEAD^ | 
clang/tools/clang-format/clang-format-diff.py -p1 -i
```

This one is recommended by the authority documentation so I think many others 
would use this too.



Comment at: clang/test/ClangScanDeps/Inputs/header-search-pruning/cdb.json:3
+  "directory" : "DIR",
+  "command" : "clang -E DIR/header-search-pruning.cpp -Ibegin -I1 -Ia -I3 -I4 
-I5 -I6 -Ib -I8 -Iend DEFINES -fmodules -fmodules-cache-path=DIR/module-cache 
-fimplicit-modules -fmodule-map-file=DIR/module.modulemap",
+  "file" : "DIR/header-search-pruning.cpp"

jansvoboda11 wrote:
> ChuanqiXu wrote:
> > jansvoboda11 wrote:
> > > Can you explain why `-fcxx-modules` is removed? We want to explicitly 
> > > enable Clang modules for C++ inputs here. That's off by default in our 
> > > downstream repo and we'd like to keep this upstream to prevent conflicts. 
> > > (it's benign upstream)
> > According to the discussion in the link, I think it is in consensus that we 
> > decide to not support clang modules and c++20 modules at the same time. (I 
> > know many people may not have visited it. If any one disagree with the 
> > higher idea, I think it would be better to reply in that thread). 
> > So the original test case would fail.
> > 
> > > We want to explicitly enable Clang modules for C++ inputs here. 
> > 
> > I am not sure if I missed any thing. Personally, it looks like the test now 
> > would test clang modules for c++ inputs. Since it has `-fmodule` option so 
> > that clang module is enabled and the input is C++ (from its suffix). Do I 
> > misunderstand you?
> > According to the discussion in the link, I think it is in consensus that we 
> > decide to not support clang modules and c++20 modules at the same time. (I 
> > know many people may not have visited it. If any one disagree with the 
> > higher idea, I think it would be better to reply in that thread). 
> > So the original test case would fail.
> 
> What's the error message? As I say, we're enabling Clang modules for C++ 
> input here, not C++20 modules.
> 
> > > We want to explicitly enable Clang modules for C++ inputs here. 
> > 
> > I am not sure if I missed any thing. Personally, it looks like the test now 
> > would test clang modules for c++ inputs. Since it has `-fmodule` option so 
> > that clang module is enabled and the input is C++ (from its suffix). Do I 
> > misunderstand you?
> 
> Right. What I'm saying is that in our downstream repo, `-fmodules` is not 
> enough to enable Clang modules for C++ inputs, you need to do it via 
> `-fcxx-modules`. And we'd like to keep it upstream, even though it's benign 
> here, to avoid conflicts between the repos.
> What's the error message? As I say, we're enabling Clang modules for C++ 
> input here, not C++20 modules.

The error message is added in this patch. After this patch landed, the original 
intentional behavior would be `-fmodules` to enable clang module and 
`-fcxx-modules` to enable C++20 modules.

> Right. What I'm saying is that in our downstream repo, -fmodules is not 
> enough to enable Clang modules for C++ inputs, you need to do it via 
> -fcxx-modules. And we'd like to keep it upstream, even though it's benign 
> here, to avoid conflicts between the repos.

Got it. But it conflicts with the idea that disable clang module and c++

[PATCH] D113391: [Modules] Don't support clang module and c++20 module at the same time

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu updated this revision to Diff 385765.
ChuanqiXu added a reviewer: jansvoboda11.
ChuanqiXu added a comment.

Undo unnecessary style change in *.json files


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113391

Files:
  clang-tools-extra/clang-tidy/ClangTidy.cpp
  clang-tools-extra/clang-tidy/ExpandModularHeadersPPCallbacks.cpp
  clang-tools-extra/test/clang-tidy/checkers/bugprone-suspicious-include.cpp
  clang-tools-extra/test/pp-trace/pp-trace-modules.cpp
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Basic/DiagnosticFrontendKinds.td
  clang/include/clang/Basic/Features.def
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/LangOptions.h
  clang/include/clang/Driver/Options.td
  clang/include/clang/Lex/Preprocessor.h
  clang/lib/ARCMigrate/ObjCMT.cpp
  clang/lib/AST/Decl.cpp
  clang/lib/AST/DeclCXX.cpp
  clang/lib/AST/DeclObjC.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/ASTUnit.cpp
  clang/lib/Frontend/CompilerInstance.cpp
  clang/lib/Frontend/FrontendAction.cpp
  clang/lib/Frontend/FrontendActions.cpp
  clang/lib/Lex/PPDirectives.cpp
  clang/lib/Lex/Preprocessor.cpp
  clang/lib/Parse/ParseObjc.cpp
  clang/lib/Sema/SemaCodeComplete.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclObjC.cpp
  clang/lib/Sema/SemaLookup.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaType.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/ClangScanDeps/Inputs/header-search-pruning/cdb.json
  clang/test/ClangScanDeps/Inputs/module_fmodule_name_cdb.json
  clang/test/ClangScanDeps/Inputs/modules_cdb.json
  clang/test/ClangScanDeps/Inputs/modules_cdb_by_mod_name.json
  clang/test/ClangScanDeps/Inputs/modules_cdb_clangcl.json
  clang/test/ClangScanDeps/Inputs/modules_cdb_clangcl_by_mod_name.json
  clang/test/ClangScanDeps/Inputs/modules_inferred_cdb.json
  clang/test/Driver/conflict-clang-module-and-cxx20-module.cpp
  clang/test/Driver/modules.mm
  clang/test/Modules/cxx20.cpp
  clang/test/Modules/ms-enums.cpp
  clang/test/SemaCXX/compare-modules-cxx2a.cpp
  clang/tools/libclang/Indexing.cpp

Index: clang/tools/libclang/Indexing.cpp
===
--- clang/tools/libclang/Indexing.cpp
+++ clang/tools/libclang/Indexing.cpp
@@ -604,7 +604,7 @@
 PPOpts.DetailedRecord = true;
   }
 
-  if (!requestedToGetTU && !CInvok->getLangOpts()->Modules)
+  if (!requestedToGetTU && !CInvok->getLangOpts()->hasModules())
 PPOpts.DetailedRecord = false;
 
   // Unless the user specified that they want the preamble on the first parse
Index: clang/test/SemaCXX/compare-modules-cxx2a.cpp
===
--- clang/test/SemaCXX/compare-modules-cxx2a.cpp
+++ clang/test/SemaCXX/compare-modules-cxx2a.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -triple x86_64-apple-darwin -fcxx-exceptions -verify -std=c++2a -fmodules -I%S/Inputs %s -fno-modules-error-recovery
+// RUN: %clang_cc1 -triple x86_64-apple-darwin -fcxx-exceptions -verify -std=c++2a -fmodules -fno-cxx-modules -I%S/Inputs %s -fno-modules-error-recovery
 
 #pragma clang module build compare
 module compare {
Index: clang/test/Modules/ms-enums.cpp
===
--- clang/test/Modules/ms-enums.cpp
+++ clang/test/Modules/ms-enums.cpp
@@ -1,5 +1,5 @@
 // RUN: rm -rf %t
-// RUN: %clang_cc1 -triple x86_64-windows-msvc -fms-extensions -fms-compatibility -x c++ -std=c++20 -fmodules-cache-path=%t -fmodules -fimplicit-module-maps -I %S/Inputs/ms-enums %s -verify -fno-modules-error-recovery
+// RUN: %clang_cc1 -triple x86_64-windows-msvc -fms-extensions -fms-compatibility -x c++ -fmodules-cache-path=%t -fmodules -fimplicit-module-maps -I %S/Inputs/ms-enums %s -verify -fno-modules-error-recovery
 
 #include "B.h"
 // expected-note@A.h:1 {{declaration here is not visible}}
Index: clang/test/Modules/cxx20.cpp
===
--- clang/test/Modules/cxx20.cpp
+++ clang/test/Modules/cxx20.cpp
@@ -1,5 +1,5 @@
 // RUN: rm -rf %t
-// RUN: %clang_cc1 -x c++ -std=c++20 -fmodules-cache-path=%t -fmodules -fimplicit-module-maps -I %S/Inputs/cxx20 %s -verify -fno-modules-error-recovery
+// RUN: %clang_cc1 -x c++ -std=c++20 -fmodules-cache-path=%t -fmodules -fno-cxx-modules -fimplicit-module-maps -I %S/Inputs/cxx20 %s -verify -fno-modules-error-recovery
 
 // expected-no-diagnostics
 
Index: clang/test/Driver/modules.mm
===
--- clang/test/Driver/modules.mm
+++ clang/test/Driver/modules.mm
@@ -1,11 +1,11 @@
 // RUN: %clang -### %s 2>&1 | FileCheck -check-prefix=CHECK-NO-MODULES %s
-// RUN: %clang -fcxx-modules -### %s 2>&1 | FileCheck -check-prefi

[PATCH] D112730: [clang-tidy] Add AUTOSAR module

[Carlos Galvez via Phabricator via cfe-commits]

carlosgalvezp added a comment.

In D112730#3116281 , @tstellar wrote:

> @carlosgalvezp The LLVM Foundation Board will conduct a legal reivew of this 
> patch.  Would you be able to share any information you have about the license 
> or usage restrictions for the AUTOSAR specification?

@tstellar Thanks for taking the time to review this, very much appreciated. 
Absolutely, here's what I know:

- The AUTOSAR C++14 guidelines can be obtained freely from here: 
https://www.autosar.org/fileadmin/user_upload/standards/adaptive/20-11/AUTOSAR_RS_CPP14Guidelines.pdf

  Note: this is a new version, compared to the one one could find via a Google 
search. It's still publicly available without any kind of paywall or 
registration needed. It can be searched here: 
https://www.autosar.org/nc/document-search/

- All pages of the pdf contain the header "AUTOSAR CONFIDENTIAL". I don't 
understand what that means legally, given that the document is public.

- The second page of the pdf contains a legal disclaimer, that claims the 
document shall be used "for information purposes only". For commercial usage, 
written permission from AUTOSAR must be obtained. I think it would be best if 
you look at the written statements directly, I might have missed important bits 
here.

- There exists a llvm-project fork that has implemented some of the checks: 
https://github.com/Bareflank/llvm-project/tree/bsl-tidy/clang-tools-extra/clang-tidy/bsl.
 They don't explicitly name Autosar anywhere in the code, but it's clear that 
they implement Autosar checks. In fact some commits refer to the rule number. 
The license of this fork is kept as the existing Apache 2.0 with LLVM 
Exceptions. I don't know if this was agreed with Autosar or simply the author 
didn't take enough consideration about the licensing aspects. I just want to 
mention that open-source Autosar checks already exist today under that license, 
whether it's a mistake or not.

- I have sent an email to AUTOSAR requesting their consent to implement 
open-source checks. Would you like me to CC you and other members of the Board 
into that mail? Who should I add?

- More restrictive guidelines, like MISRA, do allow open-source checkers, as 
long as only the rule number (not the rule text) is displayed.

I believe that's all I know, I hope it helps in reviewing this issue. Let me 
know if there are more questions or anything is unclear!


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

https://reviews.llvm.org/D112730

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

[PATCH] D112453: [Sema] When dereferencing a pointer of dependent type, infer the result type.

[Clement Courbet via Phabricator via cfe-commits]

courbet updated this revision to Diff 385768.
courbet added a comment.

one more spaceship operator fix.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112453

Files:
  clang/include/clang/AST/Type.h
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/AST/ast-dump-expr-json.cpp
  clang/test/AST/ast-dump-expr.cpp
  clang/test/AST/ast-dump-lambda.cpp
  clang/test/CXX/over/over.built/ast-20.cpp
  clang/test/CXX/over/over.built/ast.cpp
  clang/test/CXX/over/over.built/p10.cpp
  clang/test/CXX/over/over.built/p11.cpp
  clang/test/CXX/over/over.built/p13.cpp
  clang/test/CXX/over/over.built/p14.cpp
  clang/test/CXX/over/over.built/p18.cpp
  clang/test/CXX/over/over.built/p19.cpp
  clang/test/CXX/over/over.built/p20.cpp
  clang/test/CXX/over/over.built/p22.cpp
  clang/test/CXX/over/over.built/p23.cpp
  clang/test/CXX/over/over.built/p4.cpp
  clang/test/CXX/over/over.built/p5.cpp
  clang/test/CXX/over/over.built/p7.cpp
  clang/test/CXX/over/over.built/spaceship.cpp
  clang/test/Frontend/noderef_templates.cpp
  clang/test/SemaTemplate/dependent-type-identity.cpp

Index: clang/test/SemaTemplate/dependent-type-identity.cpp
===
--- clang/test/SemaTemplate/dependent-type-identity.cpp
+++ clang/test/SemaTemplate/dependent-type-identity.cpp
@@ -69,6 +69,16 @@
   void f8(typename N::X2::template apply *);
   void f8(typename N::X2::template apply *);
   void f8(typename ::Nalias::X2::template apply *); // expected-error{{redeclar}}
+
+  // (17.4.2): If an expression e is type-dependent (17.6.2.2), decltype(e)
+  // denotes a unique dependent type. Two such decltype-specifiers refer to the
+  // same type only if their expressions are equivalent (17.5.6.1)
+  T* a;
+  T* b;
+  using V = decltype(*a);
+  void f9(decltype(*a)); // expected-note{{previous}}
+  void f9(decltype(*b));
+  void f9(V); // expected-error{{redeclar}}
 };
 
 namespace PR6851 {
Index: clang/test/Frontend/noderef_templates.cpp
===
--- clang/test/Frontend/noderef_templates.cpp
+++ clang/test/Frontend/noderef_templates.cpp
@@ -3,8 +3,8 @@
 #define NODEREF __attribute__((noderef))
 
 template 
-int func(T NODEREF *a) { // expected-note 2 {{a declared here}}
-  return *a + 1; // expected-warning 2 {{dereferencing a; was declared with a 'noderef' type}}
+int func(T NODEREF *a) { // expected-note 3 {{a declared here}}
+  return *a + 1; // expected-warning 3 {{dereferencing a; was declared with a 'noderef' type}}
 }
 
 void func() {
Index: clang/test/CXX/over/over.built/spaceship.cpp
===
--- clang/test/CXX/over/over.built/spaceship.cpp
+++ clang/test/CXX/over/over.built/spaceship.cpp
@@ -11,11 +11,10 @@
 }
 
 template 
-void f(int i, float f, int* pi, T* pt, T t) {
+void f(int i, int* pi, T* pt, T t) {
   (void)(i <=> i);
-  (void)(i <=> f); // expected-error {{invalid argument type}}
-  (void)(i <=> pi); // expected-error {{invalid argument type}}
-  (void)(i <=> pt); // expected-error {{invalid argument type}}
+  (void)(i <=> pi); // expected-error {{comparison between pointer and integer}}
+  (void)(i <=> pt); // expected-error {{comparison between pointer and integer}}
   (void)(pi <=> pt);
   (void)(pi <=> t);
 }
Index: clang/test/CXX/over/over.built/p7.cpp
===
--- clang/test/CXX/over/over.built/p7.cpp
+++ clang/test/CXX/over/over.built/p7.cpp
@@ -3,10 +3,11 @@
 struct A{};
 
 template 
-void f(int* pi, A* pa, T* pt) {
+void f(int* pi, A* pa, T* pt, T t) {
   (void)*pi;
   (void)*pa;
   (void)*pt;
+  (void)*t;  // `T` might be a `U*`.
 }
 // expected-no-diagnostics
 
Index: clang/test/CXX/over/over.built/p5.cpp
===
--- clang/test/CXX/over/over.built/p5.cpp
+++ clang/test/CXX/over/over.built/p5.cpp
@@ -1,10 +1,14 @@
 // RUN: %clang_cc1 -std=c++11 -verify %s -Wno-tautological-compare
 
-void f(int i, bool b) {
+template 
+void f(int i, bool b, T t) {
   (void)--i;
   (void)i--;
 
   (void)--b; // expected-error {{cannot decrement expression of type bool}}
   (void)b--; // expected-error {{cannot decrement expression of type bool}}
+
+  (void)--t;
+  (void)t--;
 }
 
Index: clang/test/CXX/over/over.built/p4.cpp
===
--- clang/test/CXX/over/over.built/p4.cpp
+++ clang/test/CXX/over/over.built/p4.cpp
@@ -1,10 +1,14 @@
 // RUN: %clang_cc1 -std=c++17 -verify %s -Wno-tautological-compare
 
-void f(int i, bool b) {
+template 
+void f(int i, bool b, T t) {
   (void)++i;
   (void)i++;
 
   (void)++b; // expected-error {{ISO C++17 does not allow incrementing expression of type bool}}
   (void)b++; // expected-error {{ISO C++17 does not allow incrementing expression o

[clang-tools-extra] 0076957 - [clang-tidy] Fix lint warning in ClangTidyDiagnosticConsumer.cpp (NFC)

[Salman Javed via cfe-commits]

Author: Salman Javed
Date: 2021-11-10T01:09:35+13:00
New Revision: 00769572025f9b0d36dc832d3c1bc61500091ed5

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

LOG: [clang-tidy] Fix lint warning in ClangTidyDiagnosticConsumer.cpp (NFC)

Calling clang-tidy on ClangTidyDiagnosticConsumer.cpp gives a
"unmatched NOLINTBEGIN without a subsequent NOLINTEND" warning.

The "NOLINTBEGIN" and "NOLINTEND" string literals used in the
implementation of `createNolintError()` get mistaken for actual
NOLINTBEGIN/END comments used to suppress clang-tidy warnings.

Rewrite the string literals so that they can no longer be mistaken for
actual suppression comments.

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

Added: 


Modified: 
clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp 
b/clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
index 456de0e979db..9771d90de63d 100644
--- a/clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
+++ b/clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
@@ -374,13 +374,11 @@ static ClangTidyError createNolintError(const 
ClangTidyContext &Context,
 bool IsNolintBegin) {
   ClangTidyError Error("clang-tidy-nolint", ClangTidyError::Error,
Context.getCurrentBuildDirectory(), false);
-  StringRef Message =
-  IsNolintBegin
-  ? "unmatched 'NOLINTBEGIN' comment without a subsequent 'NOLINTEND' "
-"comment"
-  : "unmatched 'NOLINTEND' comment without a previous 'NOLINTBEGIN' "
-"comment";
-  Error.Message = tooling::DiagnosticMessage(Message, SM, Loc);
+  auto Message = Twine("unmatched 'NOLINT") +
+ (IsNolintBegin ? "BEGIN" : "END") + "' comment without a " +
+ (IsNolintBegin ? "subsequent" : "previous") + " 'NOLINT" +
+ (IsNolintBegin ? "END" : "BEGIN") + "' comment";
+  Error.Message = tooling::DiagnosticMessage(Message.str(), SM, Loc);
   return Error;
 }
 



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

[PATCH] D113472: [clang-tidy] Fix lint warning in ClangTidyDiagnosticConsumer.cpp (NFC)

[Salman Javed via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG00769572025f: [clang-tidy] Fix lint warning in 
ClangTidyDiagnosticConsumer.cpp (NFC) (authored by salman-javed-nz).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113472

Files:
  clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp


Index: clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
===
--- clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
+++ clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
@@ -374,13 +374,11 @@
 bool IsNolintBegin) {
   ClangTidyError Error("clang-tidy-nolint", ClangTidyError::Error,
Context.getCurrentBuildDirectory(), false);
-  StringRef Message =
-  IsNolintBegin
-  ? "unmatched 'NOLINTBEGIN' comment without a subsequent 'NOLINTEND' "
-"comment"
-  : "unmatched 'NOLINTEND' comment without a previous 'NOLINTBEGIN' "
-"comment";
-  Error.Message = tooling::DiagnosticMessage(Message, SM, Loc);
+  auto Message = Twine("unmatched 'NOLINT") +
+ (IsNolintBegin ? "BEGIN" : "END") + "' comment without a " +
+ (IsNolintBegin ? "subsequent" : "previous") + " 'NOLINT" +
+ (IsNolintBegin ? "END" : "BEGIN") + "' comment";
+  Error.Message = tooling::DiagnosticMessage(Message.str(), SM, Loc);
   return Error;
 }
 


Index: clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
===
--- clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
+++ clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
@@ -374,13 +374,11 @@
 bool IsNolintBegin) {
   ClangTidyError Error("clang-tidy-nolint", ClangTidyError::Error,
Context.getCurrentBuildDirectory(), false);
-  StringRef Message =
-  IsNolintBegin
-  ? "unmatched 'NOLINTBEGIN' comment without a subsequent 'NOLINTEND' "
-"comment"
-  : "unmatched 'NOLINTEND' comment without a previous 'NOLINTBEGIN' "
-"comment";
-  Error.Message = tooling::DiagnosticMessage(Message, SM, Loc);
+  auto Message = Twine("unmatched 'NOLINT") +
+ (IsNolintBegin ? "BEGIN" : "END") + "' comment without a " +
+ (IsNolintBegin ? "subsequent" : "previous") + " 'NOLINT" +
+ (IsNolintBegin ? "END" : "BEGIN") + "' comment";
+  Error.Message = tooling::DiagnosticMessage(Message.str(), SM, Loc);
   return Error;
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113472: [clang-tidy] Fix lint warning in ClangTidyDiagnosticConsumer.cpp (NFC)

[Salman Javed via Phabricator via cfe-commits]

salman-javed-nz added a comment.

Thanks for the review.

I will think some more about your suggestion to look for `//`. Once I have 
something that works, I will be back for another review.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113472

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

[PATCH] D113450: [clang-tidy] Fix llvm-header-guard so that it works with Windows paths

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM, thank you for the fix!




Comment at: clang-tools-extra/unittests/clang-tidy/LLVMModuleTest.cpp:248-250
+  runHeaderGuardCheck(
+  "", "SambaShare\\llvm-project\\clang-tools-extra\\clangd\\foo.h",
+  StringRef("header is missing header guard")));

Another test case is UNC paths: 
`?\\C:\\llvm-project\\clang-tools-extra\\clangd\\foo.h` (with escapes 
already added).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113450

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

[PATCH] D113472: [clang-tidy] Fix lint warning in ClangTidyDiagnosticConsumer.cpp (NFC)

[Carlos Galvez via Phabricator via cfe-commits]

carlosgalvezp added a comment.

Great! I'd be open to supporting `/*` as well if people really need it. But so 
far that use case is not documented nor tested, so I think we shouldn't add new 
functionality if it's not needed. It can be added in the future if someone has 
a compelling case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113472

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

[clang] b0de656 - Initial parsing/sema for 'align' clause

[Aaron Ballman via cfe-commits]

Author: David Pagan
Date: 2021-11-09T07:34:18-05:00
New Revision: b0de656bdf0ee3f4e51d04ae29160dab99819e8e

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

LOG: Initial parsing/sema for 'align' clause

Added basic parsing/sema/serialization support for 'align' clause for use with
'allocate' directive.

Added: 
clang/test/OpenMP/align_clause_ast_print.cpp
clang/test/OpenMP/align_clause_messages.cpp

Modified: 
clang/include/clang/AST/OpenMPClause.h
clang/include/clang/AST/RecursiveASTVisitor.h
clang/include/clang/Basic/Attr.td
clang/include/clang/Sema/Sema.h
clang/lib/AST/DeclPrinter.cpp
clang/lib/AST/OpenMPClause.cpp
clang/lib/AST/StmtProfile.cpp
clang/lib/CodeGen/CGStmtOpenMP.cpp
clang/lib/Parse/ParseOpenMP.cpp
clang/lib/Sema/SemaOpenMP.cpp
clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
clang/lib/Sema/TreeTransform.h
clang/lib/Serialization/ASTReader.cpp
clang/lib/Serialization/ASTReaderDecl.cpp
clang/lib/Serialization/ASTWriter.cpp
clang/tools/libclang/CIndex.cpp
flang/lib/Semantics/check-omp-structure.cpp
llvm/include/llvm/Frontend/OpenMP/OMP.td

Removed: 




diff  --git a/clang/include/clang/AST/OpenMPClause.h 
b/clang/include/clang/AST/OpenMPClause.h
index 99554641a64b8..565eb0c9cf99d 100644
--- a/clang/include/clang/AST/OpenMPClause.h
+++ b/clang/include/clang/AST/OpenMPClause.h
@@ -322,6 +322,81 @@ class OMPAllocatorClause : public OMPClause {
   }
 };
 
+/// This represents the 'align' clause in the '#pragma omp allocate'
+/// directive.
+///
+/// \code
+/// #pragma omp allocate(a) allocator(omp_default_mem_alloc) align(8)
+/// \endcode
+/// In this example directive '#pragma omp allocate' has simple 'allocator'
+/// clause with the allocator 'omp_default_mem_alloc' and align clause with
+/// value of 8.
+class OMPAlignClause final : public OMPClause {
+  friend class OMPClauseReader;
+
+  /// Location of '('.
+  SourceLocation LParenLoc;
+
+  /// Alignment specified with align clause.
+  Stmt *Alignment = nullptr;
+
+  /// Set alignment value.
+  void setAlignment(Expr *A) { Alignment = A; }
+
+  /// Sets the location of '('.
+  void setLParenLoc(SourceLocation Loc) { LParenLoc = Loc; }
+
+  /// Build 'align' clause with the given alignment
+  ///
+  /// \param A Alignment value.
+  /// \param StartLoc Starting location of the clause.
+  /// \param LParenLoc Location of '('.
+  /// \param EndLoc Ending location of the clause.
+  OMPAlignClause(Expr *A, SourceLocation StartLoc, SourceLocation LParenLoc,
+ SourceLocation EndLoc)
+  : OMPClause(llvm::omp::OMPC_align, StartLoc, EndLoc),
+LParenLoc(LParenLoc), Alignment(A) {}
+
+  /// Build an empty clause.
+  OMPAlignClause()
+  : OMPClause(llvm::omp::OMPC_align, SourceLocation(), SourceLocation()) {}
+
+public:
+  /// Build 'align' clause with the given alignment
+  ///
+  /// \param A Alignment value.
+  /// \param StartLoc Starting location of the clause.
+  /// \param LParenLoc Location of '('.
+  /// \param EndLoc Ending location of the clause.
+  static OMPAlignClause *Create(const ASTContext &C, Expr *A,
+SourceLocation StartLoc,
+SourceLocation LParenLoc,
+SourceLocation EndLoc);
+
+  /// Returns the location of '('.
+  SourceLocation getLParenLoc() const { return LParenLoc; }
+
+  /// Returns alignment
+  Expr *getAlignment() const { return cast_or_null(Alignment); }
+
+  child_range children() { return child_range(&Alignment, &Alignment + 1); }
+
+  const_child_range children() const {
+return const_child_range(&Alignment, &Alignment + 1);
+  }
+
+  child_range used_children() {
+return child_range(child_iterator(), child_iterator());
+  }
+  const_child_range used_children() const {
+return const_child_range(const_child_iterator(), const_child_iterator());
+  }
+
+  static bool classof(const OMPClause *T) {
+return T->getClauseKind() == llvm::omp::OMPC_align;
+  }
+};
+
 /// This represents clause 'allocate' in the '#pragma omp ...' directives.
 ///
 /// \code

diff  --git a/clang/include/clang/AST/RecursiveASTVisitor.h 
b/clang/include/clang/AST/RecursiveASTVisitor.h
index 67f0c2758bafd..9797eac53dde6 100644
--- a/clang/include/clang/AST/RecursiveASTVisitor.h
+++ b/clang/include/clang/AST/RecursiveASTVisitor.h
@@ -3093,6 +3093,12 @@ 
RecursiveASTVisitor::VisitOMPNumThreadsClause(OMPNumThreadsClause *C) {
   return true;
 }
 
+template 
+bool RecursiveASTVisitor::VisitOMPAlignClause(OMPAlignClause *C) {
+  TRY_TO(TraverseStmt(C->getAlignment()));
+  return true;
+}
+
 template 
 bool RecursiveASTVisitor::VisitOMPSafelenClause(OMPSafelenClause *C) {
   TRY_TO(TraverseStmt(C->getSafelen()));

diff  -

[PATCH] D112577: [clang][OpenMP] Initial parsing/sema for 'align' clause

[Aaron Ballman via Phabricator via cfe-commits]

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

I've commit on your behalf in b0de656bdf0ee3f4e51d04ae29160dab99819e8e 
 (clang), 
b0de656bdf0ee3f4e51d04ae29160dab99819e8e 
 (llvm), 
and b0de656bdf0ee3f4e51d04ae29160dab99819e8e 
 (flang). 
Thanks!


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

https://reviews.llvm.org/D112577

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

[PATCH] D113480: [analyzer] Fix region cast between the same types with different qualifiers.

[Denys Petrov via Phabricator via cfe-commits]

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

Specifically, this fixes the case when we get an access to array element 
through the pointer to element. This covers several //FIXME's//. in D111654 
.
Example:

  const int arr[4][2];
  const int *ptr = arr[1]; // Fixes this.

The issue is that `arr[1]` is `int*` (`&Element{Element{glob_arr5,1 
S64b,int[2]},0 S64b,int}`), and `ptr` is `const int*`. We don't take qualifiers 
into account. Consequently, we doesn't match the types as the same ones.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D113480

Files:
  clang/lib/StaticAnalyzer/Core/Store.cpp
  clang/test/Analysis/initialization.cpp


Index: clang/test/Analysis/initialization.cpp
===
--- clang/test/Analysis/initialization.cpp
+++ clang/test/Analysis/initialization.cpp
@@ -68,8 +68,7 @@
 void glob_invalid_index4() {
   const int *ptr = glob_arr4[1];
   int idx = -42;
-  // FIXME: Should warn {{garbage or undefined}}.
-  auto x = ptr[idx]; // no-warning
+  auto x = ptr[idx]; // expected-warning{{garbage or undefined}}
 }
 
 int const glob_arr5[4][2] = {{1}, 3, 4, 5};
@@ -86,16 +85,11 @@
 
 void glob_ptr_index2() {
   int const *ptr = glob_arr5[1];
-  // FIXME: Should be TRUE.
-  clang_analyzer_eval(ptr[0] == 3); // expected-warning{{UNKNOWN}}
-  // FIXME: Should be TRUE.
-  clang_analyzer_eval(ptr[1] == 4); // expected-warning{{UNKNOWN}}
-  // FIXME: Should be UNDEFINED.
-  clang_analyzer_eval(ptr[2] == 5); // expected-warning{{UNKNOWN}}
-  // FIXME: Should be UNDEFINED.
-  clang_analyzer_eval(ptr[3] == 0); // expected-warning{{UNKNOWN}}
-  // FIXME: Should be UNDEFINED.
-  clang_analyzer_eval(ptr[4] == 0); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(ptr[0] == 3); // expected-warning{{TRUE}}
+  clang_analyzer_eval(ptr[1] == 4); // expected-warning{{TRUE}}
+  clang_analyzer_eval(ptr[2] == 5); // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[3] == 0); // expected-warning{{UNDEFINED}}
+  clang_analyzer_eval(ptr[4] == 0); // expected-warning{{UNDEFINED}}
 }
 
 void glob_invalid_index5() {
@@ -106,8 +100,7 @@
 void glob_invalid_index6() {
   int const *ptr = &glob_arr5[1][0];
   int idx = 42;
-  // FIXME: Should warn {{garbage or undefined}}.
-  auto x = ptr[idx]; // no-warning
+  auto x = ptr[idx]; // expected-warning{{garbage or undefined}}
 }
 
 extern const int glob_arr_no_init[10];
Index: clang/lib/StaticAnalyzer/Core/Store.cpp
===
--- clang/lib/StaticAnalyzer/Core/Store.cpp
+++ clang/lib/StaticAnalyzer/Core/Store.cpp
@@ -101,13 +101,19 @@
   if (CanonPointeeTy.getLocalUnqualifiedType() == Ctx.VoidTy)
 return R;
 
-  // Handle casts from compatible types.
-  if (R->isBoundable())
+  const auto IsSameRegionType = [&Ctx, CanonPointeeTy](const MemRegion *R) {
 if (const auto *TR = dyn_cast(R)) {
   QualType ObjTy = Ctx.getCanonicalType(TR->getValueType());
-  if (CanonPointeeTy == ObjTy)
-return R;
+  if (CanonPointeeTy.getLocalUnqualifiedType() ==
+  ObjTy.getLocalUnqualifiedType())
+return true;
 }
+return false;
+  };
+
+  // Handle casts from compatible types.
+  if (R->isBoundable() && IsSameRegionType(R))
+return R;
 
   // Process region cast according to the kind of the region being cast.
   switch (R->getKind()) {
@@ -174,16 +180,11 @@
   CharUnits off = rawOff.getOffset();
 
   if (off.isZero()) {
-// Edge case: we are at 0 bytes off the beginning of baseR.  We
+// Edge case: we are at 0 bytes off the beginning of baseR. We
 // check to see if type we are casting to is the same as the base
-// region.  If so, just return the base region.
-if (const auto *TR = dyn_cast(baseR)) {
-  QualType ObjTy = Ctx.getCanonicalType(TR->getValueType());
-  QualType CanonPointeeTy = Ctx.getCanonicalType(PointeeTy);
-  if (CanonPointeeTy == ObjTy)
-return baseR;
-}
-
+// region. If so, just return the base region.
+if (IsSameRegionType(baseR))
+  return baseR;
 // Otherwise, create a new ElementRegion at offset 0.
 return MakeElementRegion(cast(baseR), PointeeTy);
   }


Index: clang/test/Analysis/initialization.cpp
===
--- clang/test/Analysis/initialization.cpp
+++ clang/test/Analysis/initialization.cpp
@@ -68,8 +68,7 @@
 void glob_invalid_index4() {
   const int *ptr = glob_arr4[1];
   int idx = -42;
-  // FIXME: Should warn {{garbage or undefined}}.
-  

[PATCH] D113450: [clang-tidy] Fix llvm-header-guard so that it works with Windows paths

[Salman Javed via Phabricator via cfe-commits]

salman-javed-nz updated this revision to Diff 385780.
salman-javed-nz added a comment.

Unit tests:

- Renamed Samba to SMB
- Added test for UNC paths


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113450

Files:
  clang-tools-extra/clang-tidy/llvm/HeaderGuardCheck.cpp
  clang-tools-extra/unittests/clang-tidy/LLVMModuleTest.cpp


Index: clang-tools-extra/unittests/clang-tidy/LLVMModuleTest.cpp
===
--- clang-tools-extra/unittests/clang-tidy/LLVMModuleTest.cpp
+++ clang-tools-extra/unittests/clang-tidy/LLVMModuleTest.cpp
@@ -9,8 +9,6 @@
 namespace tidy {
 namespace test {
 
-// FIXME: It seems this might be incompatible to dos path. Investigating.
-#if !defined(_WIN32)
 static std::string runHeaderGuardCheck(StringRef Code, const Twine &Filename,
Optional ExpectedWarning) {
   std::vector Errors;
@@ -220,8 +218,47 @@
 runHeaderGuardCheck(
 "", "/llvm-project/clang-tools-extra/clangd/foo.h",
 StringRef("header is missing header guard")));
-}
+
+#ifdef WIN32
+  // Check interaction with Windows-style path separators (\).
+  EXPECT_EQ(
+  "#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANGD_FOO_H\n"
+  "#define LLVM_CLANG_TOOLS_EXTRA_CLANGD_FOO_H\n"
+  "\n"
+  "\n"
+  "#endif\n",
+  runHeaderGuardCheck("", "llvm-project\\clang-tools-extra\\clangd\\foo.h",
+  StringRef("header is missing header guard")));
+
+  EXPECT_EQ("#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANGD_FOO_H\n"
+"#define LLVM_CLANG_TOOLS_EXTRA_CLANGD_FOO_H\n"
+"\n"
+"\n"
+"#endif\n",
+runHeaderGuardCheck(
+"", "C:\\llvm-project\\clang-tools-extra\\clangd\\foo.h",
+StringRef("header is missing header guard")));
+
+  EXPECT_EQ("#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANGD_FOO_H\n"
+"#define LLVM_CLANG_TOOLS_EXTRA_CLANGD_FOO_H\n"
+"\n"
+"\n"
+"#endif\n",
+runHeaderGuardCheck(
+"",
+"SMBShare\\llvm-project\\clang-tools-extra\\clangd\\foo.h",
+StringRef("header is missing header guard")));
+
+  EXPECT_EQ("#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANGD_FOO_H\n"
+"#define LLVM_CLANG_TOOLS_EXTRA_CLANGD_FOO_H\n"
+"\n"
+"\n"
+"#endif\n",
+runHeaderGuardCheck(
+"", 
"?\\C:\\llvm-project\\clang-tools-extra\\clangd\\foo.h",
+StringRef("header is missing header guard")));
 #endif
+}
 
 } // namespace test
 } // namespace tidy
Index: clang-tools-extra/clang-tidy/llvm/HeaderGuardCheck.cpp
===
--- clang-tools-extra/clang-tidy/llvm/HeaderGuardCheck.cpp
+++ clang-tools-extra/clang-tidy/llvm/HeaderGuardCheck.cpp
@@ -8,6 +8,7 @@
 
 #include "HeaderGuardCheck.h"
 #include "clang/Tooling/Tooling.h"
+#include "llvm/Support/Path.h"
 
 namespace clang {
 namespace tidy {
@@ -21,6 +22,10 @@
  StringRef OldGuard) {
   std::string Guard = tooling::getAbsolutePath(Filename);
 
+  // When running under Windows, need to convert the path separators from
+  // `\` to `/`.
+  Guard = llvm::sys::path::convert_to_slash(Guard);
+
   // Sanitize the path. There are some rules for compatibility with the 
historic
   // style in include/llvm and include/clang which we want to preserve.
 


Index: clang-tools-extra/unittests/clang-tidy/LLVMModuleTest.cpp
===
--- clang-tools-extra/unittests/clang-tidy/LLVMModuleTest.cpp
+++ clang-tools-extra/unittests/clang-tidy/LLVMModuleTest.cpp
@@ -9,8 +9,6 @@
 namespace tidy {
 namespace test {
 
-// FIXME: It seems this might be incompatible to dos path. Investigating.
-#if !defined(_WIN32)
 static std::string runHeaderGuardCheck(StringRef Code, const Twine &Filename,
Optional ExpectedWarning) {
   std::vector Errors;
@@ -220,8 +218,47 @@
 runHeaderGuardCheck(
 "", "/llvm-project/clang-tools-extra/clangd/foo.h",
 StringRef("header is missing header guard")));
-}
+
+#ifdef WIN32
+  // Check interaction with Windows-style path separators (\).
+  EXPECT_EQ(
+  "#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANGD_FOO_H\n"
+  "#define LLVM_CLANG_TOOLS_EXTRA_CLANGD_FOO_H\n"
+  "\n"
+  "\n"
+  "#endif\n",
+  runHeaderGuardCheck("", "llvm-project\\clang-tools-extra\\clangd\\foo.h",
+  StringRef("header is missing header guard")));
+
+  EXPECT_EQ("#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANGD_FOO_H\n"
+"#define LLVM_CLANG_TOOLS_EXTRA_CLANGD_FOO_H\n"
+"\n"
+"\n"
+"#endif\n",
+runHeaderGua

[PATCH] D113168: [clang-tblgen] Fix non-determinism in generating AttrSubMatchRulesParserStringSwitches.inc

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM, thanks for the fix!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113168

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

[PATCH] D113477: [clang-tblgen] Fix non-determinism in generating AttributeReference.rst

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM, thank you for the fix!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113477

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

[PATCH] D112221: Mark ATOMIC_VAR_INIT and ATOMIC_FLAG_INIT as deprecated

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a project: libc++.
aaron.ballman added a subscriber: libcxx-commits.
aaron.ballman added a comment.

Subscribing the libc++ commits list in an attempt to get the attention of a 
libc++ reviewer.


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

https://reviews.llvm.org/D112221

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

[PATCH] D112646: [clang-tidy] Add `readability-container-contains` check

[Adrian Vogelsgesang via Phabricator via cfe-commits]

avogelsgesang added a comment.

gentle ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112646

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

[PATCH] D112221: Mark ATOMIC_VAR_INIT and ATOMIC_FLAG_INIT as deprecated

[Arthur O'Dwyer via Phabricator via cfe-commits]

Quuxplusone added a comment.

If libc++ is using these macros, then I think it would be useful to include 
(the removal of) those uses in this PR.

  ../libcxx/include/atomic:#define ATOMIC_VAR_INIT(value) see below
  ../libcxx/include/atomic:#define ATOMIC_FLAG_INIT see below
  ../libcxx/include/atomic:#define ATOMIC_FLAG_INIT {false}
  ../libcxx/include/atomic:#define ATOMIC_VAR_INIT(__v) {__v}
  ../libcxx/src/barrier.cpp:__atomic_base<__barrier_phase_t> 
__phase = ATOMIC_VAR_INIT(0);
  ../libcxx/src/experimental/memory_resource.cpp:
ATOMIC_VAR_INIT(&res_init.resources.new_delete_res);
  ../libcxx/src/ios.cpp:atomic ios_base::__xindex_ = ATOMIC_VAR_INIT(0);
  
../libcxx/test/libcxx/atomics/atomics.flag/init_bool.pass.cpp:std::atomic_flag 
global = ATOMIC_FLAG_INIT;
  ../libcxx/test/std/atomics/atomics.flag/init.pass.cpp:// atomic_flag() = 
ATOMIC_FLAG_INIT;
  ../libcxx/test/std/atomics/atomics.flag/init.pass.cpp:std::atomic_flag f 
= ATOMIC_FLAG_INIT;
  
../libcxx/test/std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_var_init.pass.cpp://
 #define ATOMIC_VAR_INIT(value)
  
../libcxx/test/std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_var_init.pass.cpp:
std::atomic v = ATOMIC_VAR_INIT(5);
  
../libcxx/test/std/atomics/atomics.types.operations/atomics.types.operations.req/ctor.pass.cpp:
  constexpr Atomic a = ATOMIC_VAR_INIT(t);
  
../libcxx/test/std/thread/futures/futures.async/async.pass.cpp:std::atomic_bool 
invoked = ATOMIC_VAR_INIT(false);




Comment at: clang/test/Headers/stdatomic-deprecations.c:11
+void func(void) {
+  (void)ATOMIC_VAR_INIT(12); // expected-warning {{macro 'ATOMIC_VAR_INIT' has 
been marked as deprecated}} \
+ // expected-note@stdatomic.h:* {{macro marked 
'deprecated' here}}

This doesn't look like correct use of the `ATOMIC_VAR_INIT` macro. It should be 
initializing an atomic, yeah?
(Note for example that if you did `(void)ATOMIC_FLAG_INIT(12)`, even with 
libc++'s implementation, it would just fail with a syntax error, because 
`(void){12}` is not a valid expression AFAIK.)


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

https://reviews.llvm.org/D112221

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

[PATCH] D112647: [clang-apply-replacements] Correctly handle relative paths

[Adrian Vogelsgesang via Phabricator via cfe-commits]

avogelsgesang added a comment.

@alexfh, @ymandel: Do you know who could review this change?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112647

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

[clang] 8cc2de6 - [analyzer][docs] Fix the incorrect structure of the checker docs

[Kristóf Umann via cfe-commits]

Author: Kristóf Umann
Date: 2021-11-09T15:26:00+01:00
New Revision: 8cc2de667ec2526b055e971f46f4b3731107546c

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

LOG: [analyzer][docs] Fix the incorrect structure of the checker docs

The alpha.security.cert section came right after alpha.security, making it look
like checkers like alpha.security.MmapWriteExec belonged to that package.

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

Added: 


Modified: 
clang/docs/analyzer/checkers.rst

Removed: 




diff  --git a/clang/docs/analyzer/checkers.rst 
b/clang/docs/analyzer/checkers.rst
index 62eeb16d10dfa..80cf3bc7c3132 100644
--- a/clang/docs/analyzer/checkers.rst
+++ b/clang/docs/analyzer/checkers.rst
@@ -2064,90 +2064,6 @@ Warns against using one vs. many plural pattern in code 
when generating localize
 alpha.security
 ^^
 
-
-alpha.security.cert
-^^^
-
-SEI CERT checkers which tries to find errors based on their `C coding rules 
`_.
-
-.. _alpha-security-cert-pos-checkers:
-
-alpha.security.cert.pos
-^^^
-
-SEI CERT checkers of `POSIX C coding rules 
`__.
-
-.. _alpha-security-cert-pos-34c:
-
-alpha.security.cert.pos.34c
-"""
-Finds calls to the ``putenv`` function which pass a pointer to an automatic 
variable as the argument.
-
-.. code-block:: c
-
-  int func(const char *var) {
-char env[1024];
-int retval = snprintf(env, sizeof(env),"TEST=%s", var);
-if (retval < 0 || (size_t)retval >= sizeof(env)) {
-/* Handle error */
-}
-
-return putenv(env); // putenv function should not be called with auto 
variables
-  }
-
-alpha.security.cert.env
-^^^
-
-SEI CERT checkers of `POSIX C coding rules 
`__.
-
-.. _alpha-security-cert-env-InvalidPtr:
-
-alpha.security.cert.env.InvalidPtr
-""
-
-Corresponds to SEI CERT Rules ENV31-C and ENV34-C.
-
-ENV31-C:
-Rule is about the possible problem with `main` function's third argument, 
environment pointer,
-"envp". When enviornment array is modified using some modification function
-such as putenv, setenv or others, It may happen that memory is reallocated,
-however "envp" is not updated to reflect the changes and points to old memory
-region.
-
-ENV34-C:
-Some functions return a pointer to a statically allocated buffer.
-Consequently, subsequent call of these functions will invalidate previous
-pointer. These functions include: getenv, localeconv, asctime, setlocale, 
strerror
-
-.. code-block:: c
-
-  int main(int argc, const char *argv[], const char *envp[]) {
-if (setenv("MY_NEW_VAR", "new_value", 1) != 0) {
-  // setenv call may invalidate 'envp'
-  /* Handle error */
-}
-if (envp != NULL) {
-  for (size_t i = 0; envp[i] != NULL; ++i) {
-puts(envp[i]);
-// envp may no longer point to the current environment
-// this program has unanticipated behavior, since envp
-// does not reflect changes made by setenv function.
-  }
-}
-return 0;
-  }
-
-  void previous_call_invalidation() {
-char *p, *pp;
-
-p = getenv("VAR");
-pp = getenv("VAR2");
-// subsequent call to 'getenv' invalidated previous one
-
-*p;
-// dereferencing invalid pointer
-  }
-
 .. _alpha-security-ArrayBound:
 
 alpha.security.ArrayBound (C)
@@ -2299,6 +2215,95 @@ Check for an out-of-bound pointer being returned to 
callers.
return x; // warn: undefined or garbage returned
  }
 
+
+alpha.security.cert
+^^^
+
+SEI CERT checkers which tries to find errors based on their `C coding rules 
`_.
+
+.. _alpha-security-cert-pos-checkers:
+
+alpha.security.cert.pos
+^^^
+
+SEI CERT checkers of `POSIX C coding rules 
`_.
+
+.. _alpha-security-cert-pos-34c:
+
+alpha.security.cert.pos.34c
+"""
+Finds calls to the ``putenv`` function which pass a pointer to an automatic 
variable as the argument.
+
+.. code-block:: c
+
+  int func(const char *var) {
+char env[1024];
+int retval = snprintf(env, sizeof(env),"TEST=%s", var);
+if (retval < 0 || (size_t)retval >= sizeof(env)) {
+/* Handle error */
+}
+
+return putenv(env); // putenv function should not be called with auto 
variables
+  }
+
+alpha.security.cert.env
+^^^
+
+SEI CERT checkers of `Environment C coding rules 
`_.
+
+.. _alpha-security

[PATCH] D113397: [analyzer][docs] Fix the incorrect structure of the checker docs

[Kristóf Umann 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 rG8cc2de667ec2: [analyzer][docs] Fix the incorrect structure 
of the checker docs (authored by Szelethus).

Changed prior to commit:
  https://reviews.llvm.org/D113397?vs=385486&id=385795#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113397

Files:
  clang/docs/analyzer/checkers.rst

Index: clang/docs/analyzer/checkers.rst
===
--- clang/docs/analyzer/checkers.rst
+++ clang/docs/analyzer/checkers.rst
@@ -2064,90 +2064,6 @@
 alpha.security
 ^^
 
-
-alpha.security.cert
-^^^
-
-SEI CERT checkers which tries to find errors based on their `C coding rules `_.
-
-.. _alpha-security-cert-pos-checkers:
-
-alpha.security.cert.pos
-^^^
-
-SEI CERT checkers of `POSIX C coding rules `__.
-
-.. _alpha-security-cert-pos-34c:
-
-alpha.security.cert.pos.34c
-"""
-Finds calls to the ``putenv`` function which pass a pointer to an automatic variable as the argument.
-
-.. code-block:: c
-
-  int func(const char *var) {
-char env[1024];
-int retval = snprintf(env, sizeof(env),"TEST=%s", var);
-if (retval < 0 || (size_t)retval >= sizeof(env)) {
-/* Handle error */
-}
-
-return putenv(env); // putenv function should not be called with auto variables
-  }
-
-alpha.security.cert.env
-^^^
-
-SEI CERT checkers of `POSIX C coding rules `__.
-
-.. _alpha-security-cert-env-InvalidPtr:
-
-alpha.security.cert.env.InvalidPtr
-""
-
-Corresponds to SEI CERT Rules ENV31-C and ENV34-C.
-
-ENV31-C:
-Rule is about the possible problem with `main` function's third argument, environment pointer,
-"envp". When enviornment array is modified using some modification function
-such as putenv, setenv or others, It may happen that memory is reallocated,
-however "envp" is not updated to reflect the changes and points to old memory
-region.
-
-ENV34-C:
-Some functions return a pointer to a statically allocated buffer.
-Consequently, subsequent call of these functions will invalidate previous
-pointer. These functions include: getenv, localeconv, asctime, setlocale, strerror
-
-.. code-block:: c
-
-  int main(int argc, const char *argv[], const char *envp[]) {
-if (setenv("MY_NEW_VAR", "new_value", 1) != 0) {
-  // setenv call may invalidate 'envp'
-  /* Handle error */
-}
-if (envp != NULL) {
-  for (size_t i = 0; envp[i] != NULL; ++i) {
-puts(envp[i]);
-// envp may no longer point to the current environment
-// this program has unanticipated behavior, since envp
-// does not reflect changes made by setenv function.
-  }
-}
-return 0;
-  }
-
-  void previous_call_invalidation() {
-char *p, *pp;
-
-p = getenv("VAR");
-pp = getenv("VAR2");
-// subsequent call to 'getenv' invalidated previous one
-
-*p;
-// dereferencing invalid pointer
-  }
-
 .. _alpha-security-ArrayBound:
 
 alpha.security.ArrayBound (C)
@@ -2299,6 +2215,95 @@
return x; // warn: undefined or garbage returned
  }
 
+
+alpha.security.cert
+^^^
+
+SEI CERT checkers which tries to find errors based on their `C coding rules `_.
+
+.. _alpha-security-cert-pos-checkers:
+
+alpha.security.cert.pos
+^^^
+
+SEI CERT checkers of `POSIX C coding rules `_.
+
+.. _alpha-security-cert-pos-34c:
+
+alpha.security.cert.pos.34c
+"""
+Finds calls to the ``putenv`` function which pass a pointer to an automatic variable as the argument.
+
+.. code-block:: c
+
+  int func(const char *var) {
+char env[1024];
+int retval = snprintf(env, sizeof(env),"TEST=%s", var);
+if (retval < 0 || (size_t)retval >= sizeof(env)) {
+/* Handle error */
+}
+
+return putenv(env); // putenv function should not be called with auto variables
+  }
+
+alpha.security.cert.env
+^^^
+
+SEI CERT checkers of `Environment C coding rules `_.
+
+.. _alpha-security-cert-env-InvalidPtr:
+
+alpha.security.cert.env.InvalidPtr
+""
+
+Corresponds to SEI CERT Rules ENV31-C and ENV34-C.
+
+ENV31-C:
+Rule is about the possible problem with `main` function's third argument, environment pointer,
+"envp". When enviornment array is modified using some modification function
+such as putenv, setenv or others, It may happen that memory is

[PATCH] D113391: [Modules] Don't support clang module and c++20 module at the same time

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 added inline comments.



Comment at: clang/test/ClangScanDeps/Inputs/header-search-pruning/cdb.json:3
+  "directory" : "DIR",
+  "command" : "clang -E DIR/header-search-pruning.cpp -Ibegin -I1 -Ia -I3 -I4 
-I5 -I6 -Ib -I8 -Iend DEFINES -fmodules -fmodules-cache-path=DIR/module-cache 
-fimplicit-modules -fmodule-map-file=DIR/module.modulemap",
+  "file" : "DIR/header-search-pruning.cpp"

ChuanqiXu wrote:
> jansvoboda11 wrote:
> > ChuanqiXu wrote:
> > > jansvoboda11 wrote:
> > > > Can you explain why `-fcxx-modules` is removed? We want to explicitly 
> > > > enable Clang modules for C++ inputs here. That's off by default in our 
> > > > downstream repo and we'd like to keep this upstream to prevent 
> > > > conflicts. (it's benign upstream)
> > > According to the discussion in the link, I think it is in consensus that 
> > > we decide to not support clang modules and c++20 modules at the same 
> > > time. (I know many people may not have visited it. If any one disagree 
> > > with the higher idea, I think it would be better to reply in that 
> > > thread). 
> > > So the original test case would fail.
> > > 
> > > > We want to explicitly enable Clang modules for C++ inputs here. 
> > > 
> > > I am not sure if I missed any thing. Personally, it looks like the test 
> > > now would test clang modules for c++ inputs. Since it has `-fmodule` 
> > > option so that clang module is enabled and the input is C++ (from its 
> > > suffix). Do I misunderstand you?
> > > According to the discussion in the link, I think it is in consensus that 
> > > we decide to not support clang modules and c++20 modules at the same 
> > > time. (I know many people may not have visited it. If any one disagree 
> > > with the higher idea, I think it would be better to reply in that 
> > > thread). 
> > > So the original test case would fail.
> > 
> > What's the error message? As I say, we're enabling Clang modules for C++ 
> > input here, not C++20 modules.
> > 
> > > > We want to explicitly enable Clang modules for C++ inputs here. 
> > > 
> > > I am not sure if I missed any thing. Personally, it looks like the test 
> > > now would test clang modules for c++ inputs. Since it has `-fmodule` 
> > > option so that clang module is enabled and the input is C++ (from its 
> > > suffix). Do I misunderstand you?
> > 
> > Right. What I'm saying is that in our downstream repo, `-fmodules` is not 
> > enough to enable Clang modules for C++ inputs, you need to do it via 
> > `-fcxx-modules`. And we'd like to keep it upstream, even though it's benign 
> > here, to avoid conflicts between the repos.
> > What's the error message? As I say, we're enabling Clang modules for C++ 
> > input here, not C++20 modules.
> 
> The error message is added in this patch. After this patch landed, the 
> original intentional behavior would be `-fmodules` to enable clang module and 
> `-fcxx-modules` to enable C++20 modules.
> 
> > Right. What I'm saying is that in our downstream repo, -fmodules is not 
> > enough to enable Clang modules for C++ inputs, you need to do it via 
> > -fcxx-modules. And we'd like to keep it upstream, even though it's benign 
> > here, to avoid conflicts between the repos.
> 
> Got it. But it conflicts with the idea that disable clang module and c++20 
> module at the same time. Personally, I think it would be better to edit the 
> code in downstream. @aaron.ballman sorry if I ping you too frequently. But I 
> think now we need input from you.
Ah, I understand now, thanks for explaining.

I'm worried about changing the behavior of a driver flag, we generally don't 
break existing driver options. Have you considered keeping the `-fmodules` and 
`-fcxx-modules` semantics intact and instead add new `-fno-c++20-modules` flag 
or something like that?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113391

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

[PATCH] D112996: [CodeCompletion] Generally consider header files without extension

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

In D112996#3106469 , @ckandeler wrote:

> In D112996#3106459 , @sammccall 
> wrote:
>
>> can we the tests again though?
>
> Sorry, I don't understand what you mean by that.

Apologies, I mangled the comment.

This should have a test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112996

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

[PATCH] D108893: clang-tidy: introduce readability-containter-data-pointer check

[Whisperity via Phabricator via cfe-commits]

whisperity added a comment.

In D108893#3111674 , @steakhal wrote:

> It seems like the checker is documented as `readability-data-pointer` but in 
> the tests it reports issues under the `readability-container-data-pointer` 
> name.
> Shouldn't they be the same? I think it will confuse the users.
> @aaron.ballman @whisperity @compnerd

Sounds like a typo or an intermittent rebase or rename missing something. 
Definitely should be consistent.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108893

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

[PATCH] D112914: Misleading identifier detection

[serge 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 rG299aa4dfa1d8: Misleading unicode identifier detection pass 
(authored by serge-sans-paille).

Changed prior to commit:
  https://reviews.llvm.org/D112914?vs=384381&id=385805#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112914

Files:
  clang-tools-extra/clang-tidy/misc/CMakeLists.txt
  clang-tools-extra/clang-tidy/misc/MisleadingIdentifier.cpp
  clang-tools-extra/clang-tidy/misc/MisleadingIdentifier.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/docs/clang-tidy/checks/misc-misleading-identifier.rst
  clang-tools-extra/test/clang-tidy/checkers/misc-misleading-identifier.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/misc-misleading-identifier.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/misc-misleading-identifier.cpp
@@ -0,0 +1,15 @@
+// RUN: %check_clang_tidy %s misc-misleading-identifier %t
+
+#include 
+
+// CHECK-MESSAGES: :[[@LINE+1]]:1: warning: identifier has right-to-left codepoints
+short int א = (short int)0;
+// CHECK-MESSAGES: :[[@LINE+1]]:1: warning: identifier has right-to-left codepoints
+short int ג = (short int)12345;
+
+int main() {
+  // CHECK-MESSAGES: :[[@LINE+1]]:5: warning: identifier has right-to-left codepoints
+  int א = ג; // a local variable, set to zero?
+  printf("ג is %d\n", ג);
+  printf("א is %d\n", א);
+}
Index: clang-tools-extra/docs/clang-tidy/checks/misc-misleading-identifier.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/misc-misleading-identifier.rst
@@ -0,0 +1,23 @@
+.. title:: clang-tidy - misc-misleading-identifier
+
+misc-misleading-identifier
+==
+
+Finds identifiers that contain Unicode characters with right-to-left direction,
+which can be confusing as they may change the understanding of a whole statement
+line, as described in `Trojan Source `_.
+
+An example of such misleading code follows:
+
+.. code-block:: c
+
+#include 
+
+short int א = (short int)0;
+short int ג = (short int)12345;
+
+int main() {
+  int א = ג; // a local variable, set to zero?
+  printf("ג is %d\n", ג);
+  printf("א is %d\n", א);
+}
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -212,6 +212,7 @@
`llvmlibc-implementation-in-namespace `_,
`llvmlibc-restrict-system-libc-headers `_, "Yes"
`misc-definitions-in-headers `_, "Yes"
+   `misc-misleading-identifier `_,
`misc-misplaced-const `_,
`misc-new-delete-overloads `_,
`misc-no-recursion `_,
@@ -449,4 +450,4 @@
`hicpp-vararg `_, `cppcoreguidelines-pro-type-vararg `_,
`llvm-else-after-return `_, `readability-else-after-return `_, "Yes"
`llvm-qualified-auto `_, `readability-qualified-auto `_, "Yes"
-   
\ No newline at end of file
+   
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -101,12 +101,15 @@
   Reports identifiers whose names are too short. Currently checks local
   variables and function parameters only.
 
-
 - New :doc:`readability-data-pointer ` check.
 
   Finds cases where code could use ``data()`` rather than the address of the
   element at index 0 in a container.
 
+- New :doc:`misc-misleading-identifier ` check.
+
+  Reports identifier with unicode right-to-left characters.
+
 New check aliases
 ^
 
Index: clang-tools-extra/clang-tidy/misc/MisleadingIdentifier.h
===
--- /dev/null
+++ clang-tools-extra/clang-tidy/misc/MisleadingIdentifier.h
@@ -0,0 +1,31 @@
+//===--- MisleadingIdentifierCheck.h - clang-tidy ---*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_MISLEADINGIDENTIFIERCHECK_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_MISLEADINGIDENTIFIERCHECK_H
+
+#include "../ClangTidyCheck.h"
+
+namespace clang {
+namespace tidy {
+namespace misc {
+
+class MisleadingIdentifierCheck : public ClangTidyCheck {
+public:
+  MisleadingIdentifierCheck(StringRef Name, ClangTidyConte

[PATCH] D113474: [clang] Don't crash on an incomplete-type base specifier in template context.

[Haojian Wu via Phabricator via cfe-commits]

hokein updated this revision to Diff 385807.
hokein marked 2 inline comments as done.
hokein added a comment.

address comments and added a missing case


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113474

Files:
  clang/lib/AST/DeclCXX.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/test/SemaCXX/base-class-ambiguity-check.cpp
  clang/test/SemaCXX/ms-interface.cpp


Index: clang/test/SemaCXX/ms-interface.cpp
===
--- clang/test/SemaCXX/ms-interface.cpp
+++ clang/test/SemaCXX/ms-interface.cpp
@@ -106,3 +106,10 @@
 static_assert(!__is_interface_class(IUnknown), "oops");
 static_assert(!__is_interface_class(IFaceStruct), "oops");
 static_assert(!__is_interface_class(IFaceInheritsStruct), "oops");
+
+template
+class TemplateContext {
+  class Base;
+  // Should not crash on an incomplete-type and dependent base specifier.
+  __interface Foo : Base {};
+};
Index: clang/test/SemaCXX/base-class-ambiguity-check.cpp
===
--- clang/test/SemaCXX/base-class-ambiguity-check.cpp
+++ clang/test/SemaCXX/base-class-ambiguity-check.cpp
@@ -1,5 +1,4 @@
 // RUN: %clang_cc1 -fsyntax-only -verify %s
-// expected-no-diagnostics
 
 template  class Foo {
   struct Base : T {};
@@ -7,3 +6,14 @@
   // Test that this code no longer causes a crash in Sema. rdar://23291875
   struct Derived : Base, T {};
 };
+
+
+template  struct Foo2 {
+  struct Base1; // expected-note{{member is declared here}}
+  struct Base2; // expected-note{{member is declared here}}
+  // Should not crash on an incomplete-type and dependent base specifier.
+  struct Derived : Base1, Base2 {}; // expected-error {{implicit instantiation 
of undefined member 'Foo2::Base1'}} \
+   expected-error {{implicit instantiation 
of undefined member 'Foo2::Base2'}}
+};
+
+Foo2::Derived a; // expected-note{{in instantiation of member class}}
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -2729,6 +2729,8 @@
   KnownBase = Bases[idx];
   Bases[NumGoodBases++] = Bases[idx];
 
+  if (NewBaseType->isDependentType())
+continue;
   // Note this base's direct & indirect bases, if there could be ambiguity.
   if (Bases.size() > 1)
 NoteIndirectBases(Context, IndirectBaseTypes, NewBaseType);
Index: clang/lib/AST/DeclCXX.cpp
===
--- clang/lib/AST/DeclCXX.cpp
+++ clang/lib/AST/DeclCXX.cpp
@@ -178,6 +178,8 @@
   SmallVector WorkList = {StartRD};
   while (!WorkList.empty()) {
 const CXXRecordDecl *RD = WorkList.pop_back_val();
+if (RD->getTypeForDecl()->isDependentType())
+  continue;
 for (const CXXBaseSpecifier &BaseSpec : RD->bases()) {
   if (const CXXRecordDecl *B = BaseSpec.getType()->getAsCXXRecordDecl()) {
 if (!SeenBaseTypes.insert(B).second)


Index: clang/test/SemaCXX/ms-interface.cpp
===
--- clang/test/SemaCXX/ms-interface.cpp
+++ clang/test/SemaCXX/ms-interface.cpp
@@ -106,3 +106,10 @@
 static_assert(!__is_interface_class(IUnknown), "oops");
 static_assert(!__is_interface_class(IFaceStruct), "oops");
 static_assert(!__is_interface_class(IFaceInheritsStruct), "oops");
+
+template
+class TemplateContext {
+  class Base;
+  // Should not crash on an incomplete-type and dependent base specifier.
+  __interface Foo : Base {};
+};
Index: clang/test/SemaCXX/base-class-ambiguity-check.cpp
===
--- clang/test/SemaCXX/base-class-ambiguity-check.cpp
+++ clang/test/SemaCXX/base-class-ambiguity-check.cpp
@@ -1,5 +1,4 @@
 // RUN: %clang_cc1 -fsyntax-only -verify %s
-// expected-no-diagnostics
 
 template  class Foo {
   struct Base : T {};
@@ -7,3 +6,14 @@
   // Test that this code no longer causes a crash in Sema. rdar://23291875
   struct Derived : Base, T {};
 };
+
+
+template  struct Foo2 {
+  struct Base1; // expected-note{{member is declared here}}
+  struct Base2; // expected-note{{member is declared here}}
+  // Should not crash on an incomplete-type and dependent base specifier.
+  struct Derived : Base1, Base2 {}; // expected-error {{implicit instantiation of undefined member 'Foo2::Base1'}} \
+   expected-error {{implicit instantiation of undefined member 'Foo2::Base2'}}
+};
+
+Foo2::Derived a; // expected-note{{in instantiation of member class}}
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -2729,6 +2729,8 @@
   KnownBase = Bases[idx];
   Bases[NumGoodBases++] = Bases[idx];
 
+

[PATCH] D112221: Mark ATOMIC_VAR_INIT and ATOMIC_FLAG_INIT as deprecated

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D112221#3118314 , @Quuxplusone 
wrote:

> If libc++ is using these macros, then I think it would be useful to include 
> (the removal of) those uses in this PR.
>
>   ../libcxx/include/atomic:#define ATOMIC_VAR_INIT(value) see below
>   ../libcxx/include/atomic:#define ATOMIC_FLAG_INIT see below
>   ../libcxx/include/atomic:#define ATOMIC_FLAG_INIT {false}
>   ../libcxx/include/atomic:#define ATOMIC_VAR_INIT(__v) {__v}
>   ../libcxx/src/barrier.cpp:__atomic_base<__barrier_phase_t> 
> __phase = ATOMIC_VAR_INIT(0);
>   ../libcxx/src/experimental/memory_resource.cpp:
> ATOMIC_VAR_INIT(&res_init.resources.new_delete_res);
>   ../libcxx/src/ios.cpp:atomic ios_base::__xindex_ = ATOMIC_VAR_INIT(0);
>   
> ../libcxx/test/libcxx/atomics/atomics.flag/init_bool.pass.cpp:std::atomic_flag
>  global = ATOMIC_FLAG_INIT;
>   ../libcxx/test/std/atomics/atomics.flag/init.pass.cpp:// atomic_flag() = 
> ATOMIC_FLAG_INIT;
>   ../libcxx/test/std/atomics/atomics.flag/init.pass.cpp:std::atomic_flag 
> f = ATOMIC_FLAG_INIT;
>   
> ../libcxx/test/std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_var_init.pass.cpp://
>  #define ATOMIC_VAR_INIT(value)
>   
> ../libcxx/test/std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_var_init.pass.cpp:
> std::atomic v = ATOMIC_VAR_INIT(5);
>   
> ../libcxx/test/std/atomics/atomics.types.operations/atomics.types.operations.req/ctor.pass.cpp:
>   constexpr Atomic a = ATOMIC_VAR_INIT(t);
>   
> ../libcxx/test/std/thread/futures/futures.async/async.pass.cpp:std::atomic_bool
>  invoked = ATOMIC_VAR_INIT(false);

Thanks Arthur!

I don't know enough about libc++ to feel comfortable making those changes yet. 
For example, does libc++ need to work with other compilers than Clang 
(compilers which might give diagnostics if you fail to use `ATOMIC_VAR_INIT` in 
some language mode)? The deprecation is not really a DR, so should the uses be 
wrapped in language version checks, etc. Or are you saying I don't have to 
worry about any of that and I can rip this stuff out of libc++ with wild 
abandon?


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

https://reviews.llvm.org/D112221

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

[PATCH] D113474: [clang] Don't crash on an incomplete-type base specifier in template context.

[Haojian Wu via Phabricator via cfe-commits]

hokein added inline comments.



Comment at: clang/test/SemaCXX/base-class-ambiguity-check.cpp:15
+  // Should not crash on an incomplete-type and dependent base specifier.
+  struct Derived : Base1, Base2 {}; // expected-error {{implicit instantiation 
of undefined member 'Foo2::Base1'}} \
+   expected-error {{implicit instantiation 
of undefined member 'Foo2::Base2'}}

The diagnostic is suboptimal (I'd expect it is "invalid use of incomplete 
type"), but it is not regression, clang shows the same diagnostics for the 
following non-crash case:

```
template  struct Foo2 {
  struct Base1;
  struct Derived : Base1 {};
}
```



Comment at: clang/test/SemaCXX/ms-interface.cpp:114
+  // Should not crash on an incomplete-type base specifier.
+  __interface Foo : Base {};
+};

sammccall wrote:
> is there some tricky interaction with __interface here that justifies testing 
> this again? If it's testing the same codepath, I'd say one test is enough
They test different paths (this was founded in my previous-and-incomplete fix):
  - this tests `isInterface()` on Line 2740 in `SemaDeclCxx.cpp`;
  - the above one tests `NoteIndirectBases` (multiple base classes) on Line 
2736 in `SemaDeclCXX.cpp`;


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113474

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

[PATCH] D109701: [clang] Emit SARIF Diagnostics: Create `clang::SarifDocumentWriter` interface

[Vaibhav Yenamandra via Phabricator via cfe-commits]

vaibhav.y updated this revision to Diff 385813.
vaibhav.y added a comment.

Format code using patch from buildkite


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109701

Files:
  clang/include/clang/Basic/Sarif.h
  clang/include/clang/Basic/SourceLocation.h
  clang/lib/Basic/CMakeLists.txt
  clang/lib/Basic/Sarif.cpp
  clang/lib/Basic/SourceLocation.cpp
  clang/unittests/Basic/CMakeLists.txt
  clang/unittests/Basic/SarifTest.cpp

Index: clang/unittests/Basic/SarifTest.cpp
===
--- /dev/null
+++ clang/unittests/Basic/SarifTest.cpp
@@ -0,0 +1,138 @@
+//===- unittests/Basic/SarifTest.cpp - Test writing SARIF documents ---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "clang/Basic/Sarif.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/JSON.h"
+#include 
+
+#include "gmock/gmock.h"
+#include "gtest/gtest-death-test.h"
+#include "gtest/gtest.h"
+
+using namespace clang;
+using namespace llvm;
+
+namespace {
+
+TEST(SarifDocumentWriterTest, createEmptyDocument) {
+  // GIVEN:
+  SarifDocumentWriter writer;
+
+  // WHEN:
+  const json::Object &emptyDocument = writer.createDocument();
+  std::vector keys(emptyDocument.size());
+  std::transform(emptyDocument.begin(), emptyDocument.end(), keys.begin(),
+ [](auto item) { return item.getFirst(); });
+
+  // THEN:
+  ASSERT_THAT(keys, testing::UnorderedElementsAre("$schema", "version"));
+}
+
+// Test that a newly inserted run will associate correct tool names
+TEST(SarifDocumentWriterTest, documentWithARun) {
+  // GIVEN:
+  SarifDocumentWriter writer;
+  const char *shortName = "sariftest";
+  const char *longName = "sarif writer test";
+
+  // WHEN:
+  writer.createRun(shortName, longName);
+  writer.endRun();
+  const json::Object &document = writer.createDocument();
+  const json::Array *runs = document.getArray("runs");
+
+  // THEN:
+  // A run was created
+  ASSERT_THAT(runs, testing::NotNull());
+
+  // It is the only run
+  ASSERT_EQ(runs->size(), 1UL);
+
+  // The tool associated with the run was the tool
+  const json::Object *driver =
+  runs->begin()->getAsObject()->getObject("tool")->getObject("driver");
+  ASSERT_THAT(driver, testing::NotNull());
+
+  ASSERT_TRUE(driver->getString("name").hasValue());
+  ASSERT_TRUE(driver->getString("fullName").hasValue());
+  ASSERT_TRUE(driver->getString("language").hasValue());
+
+  EXPECT_EQ(driver->getString("name").getValue(), shortName);
+  EXPECT_EQ(driver->getString("fullName").getValue(), longName);
+  EXPECT_EQ(driver->getString("language").getValue(), "en-US");
+}
+
+// Test adding result without a run causes a crash
+TEST(SarifDocumentWriterTest, addingResultsWillCrashIfThereIsNoRun) {
+  // GIVEN:
+  SarifDocumentWriter writer;
+
+  // WHEN:
+  //  A SarifDocumentWriter::createRun(...) was not called prior to
+  //  SarifDocumentWriter::appendResult(...)
+  // But a rule exists
+  auto ruleIdx = writer.createRule(SarifRule::create());
+  SarifResult &&emptyResult = SarifResult::create(ruleIdx);
+
+  // THEN:
+  ASSERT_DEATH({ writer.appendResult(emptyResult); }, ".*create a run first.*");
+}
+
+// Test adding rule and result shows up in the final document
+TEST(SarifDocumentWriterTest, addResultWithValidRuleIsOk) {
+  // GIVEN:
+  SarifDocumentWriter writer;
+  const SarifRule &rule =
+  SarifRule::create()
+  .setRuleId("clang.unittest")
+  .setDescription("Example rule created during unit tests")
+  .setName("clang unit test");
+
+  // WHEN:
+  writer.createRun("sarif test", "sarif test runner");
+  unsigned ruleIdx = writer.createRule(rule);
+  const SarifResult &result = SarifResult::create(ruleIdx);
+
+  writer.appendResult(result);
+  const json::Object &document = writer.createDocument();
+
+  // THEN:
+  // A document with a valid schema and version exists
+  ASSERT_THAT(document.get("$schema"), ::testing::NotNull());
+  ASSERT_THAT(document.get("version"), ::testing::NotNull());
+  const json::Array *runs = document.getArray("runs");
+
+  // A run exists on this document
+  ASSERT_THAT(runs, ::testing::NotNull());
+  ASSERT_EQ(runs->size(), 1UL);
+  const json::Object *theRun = runs->back().getAsObject();
+
+  // The run has slots for tools, results, rules and artifacts
+  ASSERT_THAT(theRun->get("tool"), ::testing::NotNull());
+  ASSERT_THAT(theRun->get("results"), ::testing::NotNull());
+  ASSERT_THAT(theRun->get("artifacts"), ::testing::NotNull());
+  const json::Object *driver = theRun->getObject("tool")->getObject("driver");
+  const json::Array *results = theRun->getArray("results");
+  const json::Array *artifacts = theR

[clang] bf6986d - [clang] GCC directive extension extension: Hash NNN lines

[Nathan Sidwell via cfe-commits]

Author: Nathan Sidwell
Date: 2021-11-09T07:31:03-08:00
New Revision: bf6986d99eaa68ad850eb335cb3f98fe6406ccd0

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

LOG: [clang] GCC directive extension extension: Hash NNN lines

Some time back I extended GCC's '# NNN' line marker semantics.
Specifically popping to a blank filename will restore the filename to
that of the popped-to include.  Restore to line 5 of including file
(escaped BOL #'s to avoid git eliding them):

\# 5 "" 2

Added documentation for this line control extension.

This was useful in developing modules tests, but turned out to also be
useful with machine-generated source code.  Specifically, a generated
include file that itself includes fragments from elsewhere.  The
ability to pop to the generated include file -- with its full path
prefix -- is useful for diagnostic & debug purposes.  For instance
something like:

// Machine generated -- DO NOT EDIT
Type Var = {
\# 7 "encoded.dsl" 1 // push to snippet-container
{snippet, of, code}
\# 6 " 2 // Restore to machined-generated source
,
};

// user-code
...
\#include "dsl.h"
...

That pop to "" will restore the filename to '..includepath../dsl.h',
which is better than restoring to plain "dsl.h".

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

Added: 


Modified: 
clang/docs/LanguageExtensions.rst
clang/lib/Basic/SourceManager.cpp
clang/lib/Lex/PPDirectives.cpp
clang/test/Preprocessor/line-directive.c

Removed: 




diff  --git a/clang/docs/LanguageExtensions.rst 
b/clang/docs/LanguageExtensions.rst
index e3df9fd09960e..363cf7c4e7435 100644
--- a/clang/docs/LanguageExtensions.rst
+++ b/clang/docs/LanguageExtensions.rst
@@ -4038,6 +4038,52 @@ in user headers or code. This is controlled by 
``-Wpedantic-macros``. Final
 macros will always warn on redefinition, including situations with identical
 bodies and in system headers.
 
+Line Control
+
+
+Clang supports an extension for source line control, which takes the
+form of a preprocessor directive starting with an unsigned integral
+constant. In addition to the standard ``#line`` directive, this form
+allows control of an include stack and header file type, which is used
+in issuing diagnostics. These lines are emitted in preprocessed
+output.
+
+.. code-block:: c
+  #   
+
+The filename is optional, and if unspecified indicates no change in
+source filename. The header-type is an optional, whitespace-delimited,
+sequence of magic numbers as follows.
+
+* ``1`:` Push the current source file name onto the include stack and
+  enter a new file.
+
+* ``2``: Pop the include stack and return to the specified file. If
+  the filename is ``""``, the name popped from the include stack is
+  used. Otherwise there is no requirement that the specified filename
+  matches the current source when originally pushed.
+
+* ``3``: Enter a system-header region. System headers often contain
+  implementation-specific source that would normally emit a diagnostic.
+
+* ``4``: Enter an implicit ``extern "C"`` region. This is not required on
+  modern systems where system headers are C++-aware.
+
+At most a single ``1`` or ``2`` can be present, and values must be in
+ascending order.
+
+Examples are:
+
+.. code-block:: c
+
+   # 57 // Advance (or return) to line 57 of the current source file   
+   # 57 "frob" // Set to line 57 of "frob"
+   # 1 "foo.h" 1 // Enter "foo.h" at line 1
+   # 59 "main.c" 2 // Leave current include and return to "main.c"
+   # 1 "/usr/include/stdio.h" 1 3 // Enter a system header
+   # 60 "" 2 // return to "main.c"
+   # 1 "/usr/ancient/header.h" 1 4 // Enter an implicit extern "C" header
+
 Extended Integer Types
 ==
 

diff  --git a/clang/lib/Basic/SourceManager.cpp 
b/clang/lib/Basic/SourceManager.cpp
index 8cba379aa0f80..c2e7b684cfd8e 100644
--- a/clang/lib/Basic/SourceManager.cpp
+++ b/clang/lib/Basic/SourceManager.cpp
@@ -207,28 +207,30 @@ void LineTableInfo::AddLineNote(FileID FID, unsigned 
Offset, unsigned LineNo,
 SrcMgr::CharacteristicKind FileKind) {
   std::vector &Entries = LineEntries[FID];
 
-  // An unspecified FilenameID means use the last filename if available, or the
-  // main source file otherwise.
-  if (FilenameID == -1 && !Entries.empty())
-FilenameID = Entries.back().FilenameID;
-
   assert((Entries.empty() || Entries.back().FileOffset < Offset) &&
  "Adding line entries out of order!");
 
   unsigned IncludeOffset = 0;
-  if (EntryExit == 0) {  // No #include stack change.
-IncludeOffset = Entries.empty() ? 0 : Entries.back().IncludeOffset;
-  } else if (EntryExit == 1) {
+  if (EntryExit == 1) {
+// Push #include
 IncludeOffset = Offset-1;
-  } else if (EntryExit == 2) {
-

[PATCH] D113425: gcc extension # NNN directive lines

[Nathan Sidwell via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGbf6986d99eaa: [clang] GCC directive extension extension: 
Hash NNN lines (authored by urnathan).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D113425?vs=385794&id=385814#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113425

Files:
  clang/docs/LanguageExtensions.rst
  clang/lib/Basic/SourceManager.cpp
  clang/lib/Lex/PPDirectives.cpp
  clang/test/Preprocessor/line-directive.c

Index: clang/test/Preprocessor/line-directive.c
===
--- clang/test/Preprocessor/line-directive.c
+++ clang/test/Preprocessor/line-directive.c
@@ -1,6 +1,18 @@
 // RUN: %clang_cc1 -std=c99 -fsyntax-only -verify -pedantic %s
 // RUN: not %clang_cc1 -E %s 2>&1 | grep 'blonk.c:92:2: error: ABC'
 // RUN: not %clang_cc1 -E %s 2>&1 | grep 'blonk.c:93:2: error: DEF'
+// RUN: not %clang_cc1 -E %s 2>&1 | grep 'line-directive.c:11:2: error: MAIN7'
+// RUN: not %clang_cc1 -E %s 2>&1 | grep 'enter-1:118:2: error: ENTER1'
+// RUN: not %clang_cc1 -E %s 2>&1 | grep 'main:121:2: error: MAIN2'
+
+// expected-error@+1{{cannot pop empty include stack}}
+# 20 "" 2
+
+// a push/pop before any other line control
+# 10 "enter-0" 1
+# 11 "" 2 // pop to main file
+#error MAIN7
+// expected-error@-1{{MAIN7}}
 
 #line 'a'// expected-error {{#line directive requires a positive integer argument}}
 #line 0  // expected-warning {{#line directive with zero argument is a GNU extension}}
@@ -103,4 +115,12 @@
 #line 0 "line-directive.c" // expected-warning {{#line directive with zero argument is a GNU extension}}
 undefined t; // expected-error {{unknown type name 'undefined'}}
 
-
+# 115 "main"
+# 116 "enter-1" 1
+# 117 "enter-2" 1
+# 118 "" 2 // pop to enter-1
+#error ENTER1
+// expected-error@-1{{ENTER1}}
+# 121 "" 2 // pop to "main"
+#error MAIN2
+// expected-error@-1{{MAIN2}}
Index: clang/lib/Lex/PPDirectives.cpp
===
--- clang/lib/Lex/PPDirectives.cpp
+++ clang/lib/Lex/PPDirectives.cpp
@@ -1451,11 +1451,15 @@
   DiscardUntilEndOfDirective();
   return;
 }
-FilenameID = SourceMgr.getLineTableFilenameID(Literal.GetString());
 
 // If a filename was present, read any flags that are present.
 if (ReadLineMarkerFlags(IsFileEntry, IsFileExit, FileKind, *this))
   return;
+
+// Exiting to an empty string means pop to the including file, so leave
+// FilenameID as -1 in that case.
+if (!(IsFileExit && Literal.GetString().empty()))
+  FilenameID = SourceMgr.getLineTableFilenameID(Literal.GetString());
   }
 
   // Create a line note with this information.
Index: clang/lib/Basic/SourceManager.cpp
===
--- clang/lib/Basic/SourceManager.cpp
+++ clang/lib/Basic/SourceManager.cpp
@@ -207,28 +207,30 @@
 SrcMgr::CharacteristicKind FileKind) {
   std::vector &Entries = LineEntries[FID];
 
-  // An unspecified FilenameID means use the last filename if available, or the
-  // main source file otherwise.
-  if (FilenameID == -1 && !Entries.empty())
-FilenameID = Entries.back().FilenameID;
-
   assert((Entries.empty() || Entries.back().FileOffset < Offset) &&
  "Adding line entries out of order!");
 
   unsigned IncludeOffset = 0;
-  if (EntryExit == 0) {  // No #include stack change.
-IncludeOffset = Entries.empty() ? 0 : Entries.back().IncludeOffset;
-  } else if (EntryExit == 1) {
+  if (EntryExit == 1) {
+// Push #include
 IncludeOffset = Offset-1;
-  } else if (EntryExit == 2) {
-assert(!Entries.empty() && Entries.back().IncludeOffset &&
-   "PPDirectives should have caught case when popping empty include stack");
-
-// Get the include loc of the last entries' include loc as our include loc.
-IncludeOffset = 0;
-if (const LineEntry *PrevEntry =
-  FindNearestLineEntry(FID, Entries.back().IncludeOffset))
+  } else {
+const auto *PrevEntry = Entries.empty() ? nullptr : &Entries.back();
+if (EntryExit == 2) {
+  // Pop #include
+  assert(PrevEntry && PrevEntry->IncludeOffset &&
+ "PPDirectives should have caught case when popping empty include "
+ "stack");
+  PrevEntry = FindNearestLineEntry(FID, PrevEntry->IncludeOffset);
+}
+if (PrevEntry) {
   IncludeOffset = PrevEntry->IncludeOffset;
+  if (FilenameID == -1) {
+// An unspecified FilenameID means use the previous (or containing)
+// filename if available, or the main source file otherwise.
+FilenameID = PrevEntry->FilenameID;
+  }
+}
   }
 
   Entries.push_back(LineEntry::get(Offset, LineNo, FilenameID, FileKind,
Index: clang/docs/LanguageExten

[PATCH] D113474: [clang] Don't crash on an incomplete-type base specifier in template context.

[Sam McCall via Phabricator via cfe-commits]

sammccall accepted this revision.
sammccall added inline comments.



Comment at: clang/test/SemaCXX/base-class-ambiguity-check.cpp:15
+  // Should not crash on an incomplete-type and dependent base specifier.
+  struct Derived : Base1, Base2 {}; // expected-error {{implicit instantiation 
of undefined member 'Foo2::Base1'}} \
+   expected-error {{implicit instantiation 
of undefined member 'Foo2::Base2'}}

hokein wrote:
> The diagnostic is suboptimal (I'd expect it is "invalid use of incomplete 
> type"), but it is not regression, clang shows the same diagnostics for the 
> following non-crash case:
> 
> ```
> template  struct Foo2 {
>   struct Base1;
>   struct Derived : Base1 {};
> }
> ```
Or even
```
template  struct X;
X<42> y;
```

I think the diagnostic is OK - it's diagnosing why the type *is* incomplete, 
rather than why the type *may not* be complete.

Typical use of this pattern would be to provide an out-of-line definition 
template:

```
template  struct Foo2::Base1 {
  T contents;
}
```

in which case instantiation is the right idea.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113474

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

[clang] ae5c52b - [clang] [docs] Fix markup

[Nathan Sidwell via cfe-commits]

Author: Nathan Sidwell
Date: 2021-11-09T07:40:27-08:00
New Revision: ae5c52b933f45ba9a782909a93d1ae3c7243c6be

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

LOG: [clang] [docs]  Fix markup

code-block needs a blank line

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

Added: 


Modified: 
clang/docs/LanguageExtensions.rst

Removed: 




diff  --git a/clang/docs/LanguageExtensions.rst 
b/clang/docs/LanguageExtensions.rst
index 363cf7c4e743..1acf8961e588 100644
--- a/clang/docs/LanguageExtensions.rst
+++ b/clang/docs/LanguageExtensions.rst
@@ -4049,7 +4049,8 @@ in issuing diagnostics. These lines are emitted in 
preprocessed
 output.
 
 .. code-block:: c
-  #   
+
+   #   
 
 The filename is optional, and if unspecified indicates no change in
 source filename. The header-type is an optional, whitespace-delimited,



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

[PATCH] D102107: [OpenMP] Codegen aggregate for outlined function captures

[Giorgis Georgakoudis via Phabricator via cfe-commits]

ggeorgakoudis updated this revision to Diff 385818.
ggeorgakoudis added a comment.

Update the interface for allocating/sharing the struct aggregate
Simplify invoking tasks


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102107

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/AST/ast-dump-openmp-distribute-parallel-for-simd.c
  clang/test/AST/ast-dump-openmp-distribute-parallel-for.c
  clang/test/AST/ast-dump-openmp-target-teams-distribute-parallel-for-simd.c
  clang/test/AST/ast-dump-openmp-target-teams-distribute-parallel-for.c
  clang/test/AST/ast-dump-openmp-teams-distribute-parallel-for-simd.c
  clang/test/AST/ast-dump-openmp-teams-distribute-parallel-for.c
  clang/test/CodeGenCXX/observe-noexcept.cpp
  
clang/test/utils/update_cc_test_checks/Inputs/generated-funcs.c.generated.expected
  
clang/test/utils/update_cc_test_checks/Inputs/generated-funcs.c.no-generated.expected
  llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
  openmp/libomptarget/DeviceRTL/include/Interface.h
  openmp/libomptarget/DeviceRTL/include/generated_microtask_cases.gen
  openmp/libomptarget/DeviceRTL/src/Parallelism.cpp
  openmp/libomptarget/DeviceRTL/src/State.cpp
  openmp/libomptarget/deviceRTLs/common/generated_microtask_cases.gen
  openmp/libomptarget/deviceRTLs/common/src/data_sharing.cu
  openmp/libomptarget/deviceRTLs/common/src/parallel.cu
  openmp/libomptarget/deviceRTLs/common/src/support.cu
  openmp/libomptarget/deviceRTLs/common/support.h
  openmp/libomptarget/deviceRTLs/interface.h
  openmp/libomptarget/utils/generate_microtask_cases.py

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

[PATCH] D102107: [OpenMP] Codegen aggregate for outlined function captures

[Giorgis Georgakoudis via Phabricator via cfe-commits]

ggeorgakoudis added a comment.

TODO update tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102107

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

[PATCH] D112492: [CUDA][HIP] Allow comdat for kernels

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl updated this revision to Diff 385812.
yaxunl retitled this revision from "[HIP] Do not use kernel handle for MSVC 
target" to "[CUDA][HIP] Allow comdat for kernels".
yaxunl edited the summary of this revision.
yaxunl added a comment.

fix comdat instead


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

https://reviews.llvm.org/D112492

Files:
  clang/lib/CodeGen/CGCUDANV.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/CodeGenCUDA/kernel-stub-name.cu
  clang/test/CodeGenCUDA/usual-deallocators.cu

Index: clang/test/CodeGenCUDA/usual-deallocators.cu
===
--- clang/test/CodeGenCUDA/usual-deallocators.cu
+++ clang/test/CodeGenCUDA/usual-deallocators.cu
@@ -109,7 +109,7 @@
 }
 
 // Make sure that we've generated the kernel used by A::~A.
-// DEVICE-LABEL: define dso_local void @_Z1fIiEvT_
+// DEVICE-LABEL: define void @_Z1fIiEvT_
 
 // Make sure we've picked deallocator for the correct side of compilation.
 
Index: clang/test/CodeGenCUDA/kernel-stub-name.cu
===
--- clang/test/CodeGenCUDA/kernel-stub-name.cu
+++ clang/test/CodeGenCUDA/kernel-stub-name.cu
@@ -2,16 +2,35 @@
 
 // RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm %s \
 // RUN: -fcuda-include-gpubinary %t -o - -x hip\
-// RUN:   | FileCheck %s
+// RUN:   | FileCheck -check-prefixes=CHECK,GNU %s
+
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm %s \
+// RUN: -fcuda-include-gpubinary %t -o - -x hip\
+// RUN:   | FileCheck -check-prefix=NEG %s
+
+// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -emit-llvm %s \
+// RUN: -aux-triple amdgcn-amd-amdhsa -fcuda-include-gpubinary \
+// RUN: %t -o - -x hip\
+// RUN:   | FileCheck -check-prefixes=CHECK,MSVC %s
+
+// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -emit-llvm %s \
+// RUN: -aux-triple amdgcn-amd-amdhsa -fcuda-include-gpubinary \
+// RUN: %t -o - -x hip\
+// RUN:   | FileCheck -check-prefix=NEG %s
 
 #include "Inputs/cuda.h"
 
-// Kernel handles
+// Check kernel handles are emitted for non-MSVC target but not for MSVC target.
 
-// CHECK: @[[HCKERN:ckernel]] = constant void ()* @__device_stub__ckernel, align 8
-// CHECK: @[[HNSKERN:_ZN2ns8nskernelEv]] = constant void ()* @_ZN2ns23__device_stub__nskernelEv, align 8
-// CHECK: @[[HTKERN:_Z10kernelfuncIiEvv]] = linkonce_odr constant void ()* @_Z25__device_stub__kernelfuncIiEvv, align 8
-// CHECK: @[[HDKERN:_Z11kernel_declv]] = external constant void ()*, align 8
+// GNU: @[[HCKERN:ckernel]] = constant void ()* @[[CSTUB:__device_stub__ckernel]], align 8
+// GNU: @[[HNSKERN:_ZN2ns8nskernelEv]] = constant void ()* @[[NSSTUB:_ZN2ns23__device_stub__nskernelEv]], align 8
+// GNU: @[[HTKERN:_Z10kernelfuncIiEvv]] = linkonce_odr constant void ()* @[[TSTUB:_Z25__device_stub__kernelfuncIiEvv]], comdat, align 8
+// GNU: @[[HDKERN:_Z11kernel_declv]] = external constant void ()*, align 8
+
+// MSVC: @[[HCKERN:ckernel]] = dso_local constant void ()* @[[CSTUB:__device_stub__ckernel]], align 8
+// MSVC: @[[HNSKERN:"\?nskernel@ns@@YAXXZ.*"]] = dso_local constant void ()* @[[NSSTUB:"\?nskernel@ns@@YAXXZ"]], align 8
+// MSVC: @[[HTKERN:"\?\?\$kernelfunc@H@@YAXXZ.*"]] = linkonce_odr dso_local constant void ()* @[[TSTUB:"\?\?\$kernelfunc@H@@YAXXZ.*"]], comdat, align 8
+// MSVC: @[[HDKERN:"\?kernel_decl@@YAXXZ.*"]] = external dso_local constant void ()*, align 8
 
 extern "C" __global__ void ckernel() {}
 
@@ -24,10 +43,10 @@
 
 __global__ void kernel_decl();
 
-void (*kernel_ptr)();
-void *void_ptr;
+extern "C" void (*kernel_ptr)();
+extern "C" void *void_ptr;
 
-void launch(void *kern);
+extern "C" void launch(void *kern);
 
 // Device side kernel names
 
@@ -37,21 +56,22 @@
 
 // Non-template kernel stub functions
 
-// CHECK: define{{.*}}@[[CSTUB:__device_stub__ckernel]]
+// CHECK: define{{.*}}@[[CSTUB]]
 // CHECK: call{{.*}}@hipLaunchByPtr{{.*}}@[[HCKERN]]
-// CHECK: define{{.*}}@[[NSSTUB:_ZN2ns23__device_stub__nskernelEv]]
-// CHECK: call{{.*}}@hipLaunchByPtr{{.*}}@[[HNSKERN]]
 
+// CHECK: define{{.*}}@[[NSSTUB]]
+// CHECK: call{{.*}}@hipLaunchByPtr{{.*}}@[[HNSKERN]]
 
-// Check kernel stub is used for triple chevron
+// Check kernel stub is called for triple chevron.
 
-// CHECK-LABEL: define{{.*}}@_Z4fun1v()
+// CHECK-LABEL: define{{.*}}@fun1()
 // CHECK: call void @[[CSTUB]]()
 // CHECK: call void @[[NSSTUB]]()
-// CHECK: call void @[[TSTUB:_Z25__device_stub__kernelfuncIiEvv]]()
-// CHECK: call void @[[DSTUB:_Z26__device_stub__kernel_declv]]()
+// CHECK: call void @[[TSTUB]]()
+// GNU: call void @[[DSTUB:_Z26__device_stub__kernel_declv]]()
+// MSVC: call void @[[DSTUB:"\?kernel_decl@@YAXXZ"]]()
 
-void fun1(void) {
+extern "C" void fun1(void) {
   ckernel<<<1, 1>>>();
   ns::nskernel<<<1, 1>>>();
   kernelfunc<<<1, 1>>>();
@@ -67,28 +87,28 @@
 
 // CHECK: declare{{.*}}@[[DSTUB]]
 
-// Check kernel handle is used for passing the kernel as a function pointer
+// Check kernel 

[PATCH] D112996: [CodeCompletion] Generally consider header files without extension

[Christian Kandeler via Phabricator via cfe-commits]

ckandeler updated this revision to Diff 385826.
ckandeler added a comment.

Added test cases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112996

Files:
  clang/lib/Sema/SemaCodeComplete.cpp
  clang/test/CodeCompletion/included-files.cpp

Index: clang/test/CodeCompletion/included-files.cpp
===
--- clang/test/CodeCompletion/included-files.cpp
+++ clang/test/CodeCompletion/included-files.cpp
@@ -1,35 +1,57 @@
-// RUN: rm -rf %t && mkdir %t && cp %s %t/main.cc && mkdir %t/a
-// RUN: touch %t/foo.h && touch %t/foo.cc && touch %t/a/foosys %t/a/foosys.h
+// RUN: rm -rf %t && mkdir %t && cp %s %t/main.cc && mkdir %t/a && mkdir %t/QtCore && mkdir %t/Headers %t/Some.framework %t/Some.framework/Headers
+// RUN: touch %t/foo.h && touch %t/foo.cc && touch %t/a/foosys %t/a/foosys.h && touch %t/QtCore/foosys %t/QtCore/foo.h
+// RUN: touch %t/Headers/foosys %t/Headers/foo.h %t/Some.framework/Headers/foosys %t/Some.framework/Headers/foo.h
 
 // Quoted string shows header-ish files from CWD, and all from system.
 #include "foo.h"
-// RUN: %clang -fsyntax-only -isystem %t/a -Xclang -code-completion-at=%t/main.cc:5:13 %t/main.cc | FileCheck -check-prefix=CHECK-1 %s
+// RUN: %clang -fsyntax-only -isystem %t/a -Xclang -code-completion-at=%t/main.cc:6:13 %t/main.cc | FileCheck -check-prefix=CHECK-1 %s
 // CHECK-1-NOT: foo.cc"
 // CHECK-1: foo.h"
 // CHECK-1: foosys"
 
 // Quoted string with dir shows header-ish files in that subdir.
 #include "a/foosys"
-// RUN: %clang -fsyntax-only -isystem %t/a -Xclang -code-completion-at=%t/main.cc:12:13 %t/main.cc | FileCheck -check-prefix=CHECK-2 %s
+// RUN: %clang -fsyntax-only -isystem %t/a -Xclang -code-completion-at=%t/main.cc:13:13 %t/main.cc | FileCheck -check-prefix=CHECK-2 %s
 // CHECK-2-NOT: foo.h"
 // CHECK-2: foosys.h"
 // CHECK-2-NOT: foosys"
 
 // Angled shows headers from system dirs.
 #include 
-// RUN: %clang -fsyntax-only -isystem %t/a -Xclang -code-completion-at=%t/main.cc:19:13 %t/main.cc | FileCheck -check-prefix=CHECK-3 %s
+// RUN: %clang -fsyntax-only -isystem %t/a -Xclang -code-completion-at=%t/main.cc:20:13 %t/main.cc | FileCheck -check-prefix=CHECK-3 %s
 // CHECK-3-NOT: foo.cc>
 // CHECK-3-NOT: foo.h>
 // CHECK-3: foosys>
 
 // With -I rather than -isystem, the header extension is required.
 #include 
-// RUN: %clang -fsyntax-only -I %t/a -Xclang -code-completion-at=%t/main.cc:26:13 %t/main.cc | FileCheck -check-prefix=CHECK-4 %s
+// RUN: %clang -fsyntax-only -I %t/a -Xclang -code-completion-at=%t/main.cc:27:13 %t/main.cc | FileCheck -check-prefix=CHECK-4 %s
 // CHECK-4-NOT: foo.cc>
 // CHECK-4-NOT: foo.h>
 // CHECK-4-NOT: foosys>
 
 // Backslash handling.
 #include "a\foosys"
-// RUN: %clang -fsyntax-only -isystem %t/a -Xclang -code-completion-at=%t/main.cc:33:13 %t/main.cc -fms-compatibility | FileCheck -check-prefix=CHECK-5 %s
+// RUN: %clang -fsyntax-only -isystem %t/a -Xclang -code-completion-at=%t/main.cc:34:13 %t/main.cc -fms-compatibility | FileCheck -check-prefix=CHECK-5 %s
 // CHECK-5: foosys.h"
+
+// Qt headers don't necessarily have extensions.
+#include 
+// RUN: %clang -fsyntax-only -I %t/QtCore -Xclang -code-completion-at=%t/main.cc:39:13 %t/main.cc -fms-compatibility | FileCheck -check-prefix=CHECK-6 %s
+// CHECK-6-NOT: foo.cc>
+// CHECK-6: foo.h>
+// CHECK-6: foosys>
+
+// If the include path directly points into a framework's Headers/ directory, we allow extension-less headers.
+#include 
+// RUN: %clang -fsyntax-only -I %t/Some.framework/Headers -Xclang -code-completion-at=%t/main.cc:46:13 %t/main.cc -fms-compatibility | FileCheck -check-prefix=CHECK-7 %s
+// CHECK-7-NOT: foo.cc>
+// CHECK-7: foo.h>
+// CHECK-7: foosys>
+
+// Simply naming a directory "Headers" is not enough to allow extension-less headers.
+#include 
+// RUN: %clang -fsyntax-only -I %t/Headers -Xclang -code-completion-at=%t/main.cc:53:13 %t/main.cc -fms-compatibility | FileCheck -check-prefix=CHECK-8 %s
+// CHECK-8-NOT: foo.cc>
+// CHECK-8: foo.h>
+// CHECK-8-NOT: foosys>
Index: clang/lib/Sema/SemaCodeComplete.cpp
===
--- clang/lib/Sema/SemaCodeComplete.cpp
+++ clang/lib/Sema/SemaCodeComplete.cpp
@@ -9613,6 +9613,10 @@
   }
 }
 
+const StringRef &Dirname = llvm::sys::path::filename(Dir);
+const bool isQt = Dirname.startswith("Qt") || Dirname == "ActiveQt";
+const bool ExtensionlessHeaders =
+IsSystem || isQt || Dir.endswith(".framework/Headers");
 std::error_code EC;
 unsigned Count = 0;
 for (auto It = FS.dir_begin(Dir, EC);
@@ -9639,18 +9643,19 @@
 
 AddCompletion(Filename, /*IsDirectory=*/true);
 break;
-  case llvm::sys::fs::file_type::regular_file:
-// Only files that really look like headers. (Except in system dirs).
-if (!IsSystem) {
-  // Header extensions from Types.def, wh

[PATCH] D113049: [AIX] Disable tests that fail because of no 64-bit XCOFF object file support

[Jake Egan via Phabricator via cfe-commits]

Jake-Egan updated this revision to Diff 385830.
Jake-Egan added a comment.

Add `LLVM :: DebugInfo/attr-btf_type_tag.ll`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113049

Files:
  clang/test/ASTMerge/anonymous-fields/test.cpp
  clang/test/ASTMerge/codegen-body/test.c
  clang/test/ASTMerge/injected-class-name-decl/test.cpp
  clang/test/ClangScanDeps/modules-full-by-mod-name.cpp
  clang/test/ClangScanDeps/modules-pch-common-submodule.c
  clang/test/ClangScanDeps/modules-pch-common-via-submodule.c
  clang/test/ClangScanDeps/modules-pch.c
  clang/test/ClangScanDeps/resource_directory.c
  clang/test/CodeGenCXX/crash.cpp
  clang/test/CodeGenCXX/ubsan-coroutines.cpp
  clang/test/Driver/as-version.s
  clang/test/Driver/cc-print-proc-stat.c
  clang/test/Driver/compilation_database.c
  clang/test/Driver/modules-ts.cpp
  clang/test/Driver/report-stat.c
  clang/test/Misc/clear-ast-before-backend.c
  clang/test/Misc/time-passes.c
  clang/test/Modules/DebugInfoSubmodules.c
  clang/test/Modules/lsv-debuginfo.cpp
  clang/test/Modules/odr_hash-Friend.cpp
  clang/test/Modules/path-resolution.modulemap
  clang/test/Modules/self-referencing-lambda.cpp
  clang/test/PCH/debug-info-pch-container-path.c
  clang/test/PCH/debug-info-pch-path.c
  clang/test/PCH/pch-hdrstop-warn.cpp
  clang/test/PCH/pch-hdrstop.cpp
  clang/test/PCH/pch-no-hdrstop.cpp
  clang/test/PCH/pch-through4.cpp
  clang/test/PCH/pch-through4a.cpp
  llvm/test/CodeGen/X86/dbg-distringtype-uint.ll
  llvm/test/DebugInfo/Generic/2010-04-06-NestedFnDbgInfo.ll
  llvm/test/DebugInfo/Generic/2010-05-10-MultipleCU.ll
  llvm/test/DebugInfo/Generic/DICommonBlock.ll
  llvm/test/DebugInfo/Generic/PR20038.ll
  llvm/test/DebugInfo/Generic/constant-pointers.ll
  llvm/test/DebugInfo/Generic/containing-type-extension.ll
  llvm/test/DebugInfo/Generic/cross-cu-inlining.ll
  llvm/test/DebugInfo/Generic/cross-cu-linkonce-distinct.ll
  llvm/test/DebugInfo/Generic/cross-cu-linkonce.ll
  llvm/test/DebugInfo/Generic/cu-range-hole.ll
  llvm/test/DebugInfo/Generic/cu-ranges.ll
  llvm/test/DebugInfo/Generic/dead-argument-order.ll
  llvm/test/DebugInfo/Generic/debug-info-enum.ll
  llvm/test/DebugInfo/Generic/debug-info-qualifiers.ll
  llvm/test/DebugInfo/Generic/debug-label-inline.ll
  llvm/test/DebugInfo/Generic/debug-label.ll
  llvm/test/DebugInfo/Generic/debug-names-empty-cu.ll
  llvm/test/DebugInfo/Generic/def-line.ll
  llvm/test/DebugInfo/Generic/discriminated-union.ll
  llvm/test/DebugInfo/Generic/discriminator.ll
  llvm/test/DebugInfo/Generic/disubrange_vla.ll
  llvm/test/DebugInfo/Generic/disubrange_vla_no_dbgvalue.ll
  llvm/test/DebugInfo/Generic/dwarf-public-names.ll
  llvm/test/DebugInfo/Generic/empty.ll
  llvm/test/DebugInfo/Generic/enum.ll
  llvm/test/DebugInfo/Generic/fortran-subprogram-attr.ll
  llvm/test/DebugInfo/Generic/global.ll
  llvm/test/DebugInfo/Generic/gmlt.test
  llvm/test/DebugInfo/Generic/gmlt_profiling.ll
  llvm/test/DebugInfo/Generic/imported-name-inlined.ll
  llvm/test/DebugInfo/Generic/incorrect-variable-debugloc.ll
  llvm/test/DebugInfo/Generic/inline-scopes.ll
  llvm/test/DebugInfo/Generic/inlined-arguments.ll
  llvm/test/DebugInfo/Generic/inlined-strings.ll
  llvm/test/DebugInfo/Generic/linkage-name-abstract.ll
  llvm/test/DebugInfo/Generic/lto-comp-dir.ll
  llvm/test/DebugInfo/Generic/mainsubprogram.ll
  llvm/test/DebugInfo/Generic/member-order.ll
  llvm/test/DebugInfo/Generic/member-pointers.ll
  llvm/test/DebugInfo/Generic/namespace_function_definition.ll
  llvm/test/DebugInfo/Generic/namespace_inline_function_definition.ll
  llvm/test/DebugInfo/Generic/no-empty-child-vars.ll
  llvm/test/DebugInfo/Generic/noscopes.ll
  llvm/test/DebugInfo/Generic/pass-by-value.ll
  llvm/test/DebugInfo/Generic/ptrsize.ll
  llvm/test/DebugInfo/Generic/recursive_inlining.ll
  llvm/test/DebugInfo/Generic/skeletoncu.ll
  llvm/test/DebugInfo/Generic/sugared-constants.ll
  llvm/test/DebugInfo/Generic/template-recursive-void.ll
  llvm/test/DebugInfo/Generic/thrownTypes.ll
  llvm/test/DebugInfo/Generic/two-cus-from-same-file.ll
  llvm/test/DebugInfo/Generic/typedef.ll
  llvm/test/DebugInfo/Generic/unconditional-branch.ll
  llvm/test/DebugInfo/Generic/univariant-discriminated-union.ll
  llvm/test/DebugInfo/Generic/version.ll
  llvm/test/DebugInfo/Generic/virtual-index.ll
  llvm/test/DebugInfo/X86/dwarfdump-generic_subrange.ll
  llvm/test/DebugInfo/X86/dwarfdump-generic_subrange_const.ll
  llvm/test/DebugInfo/X86/dwarfdump-generic_subrange_count.ll
  llvm/test/DebugInfo/X86/dwarfdump-rankConst.ll
  llvm/test/DebugInfo/X86/dwarfdump-rankExp.ll
  llvm/test/DebugInfo/X86/dwarfdump-signed_const.ll
  llvm/test/DebugInfo/X86/global-constants.ll
  llvm/test/DebugInfo/X86/invalid-global-constants.ll
  llvm/test/DebugInfo/attr-btf_type_tag.ll
  llvm/test/DebugInfo/cross-cu-scope.ll
  llvm/test/DebugInfo/dwo.ll
  llvm/test/DebugInfo/omit-empty.ll
  llvm/test/DebugInfo/skeletoncu.ll
  llvm/test/LTO/X86/

[PATCH] D113447: [sancov] add tracing for loads and store

[Matt Morehouse via Phabricator via cfe-commits]

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



Comment at: clang/test/Driver/autocomplete.c:73
 // FNOSANICOVERALL-NEXT: trace-pc-guard
+// FNOSANICOVERALL-NEXT: trace-loads
+// FNOSANICOVERALL-NEXT: trace-stores

This check is failing in the harbormaster build:  
https://reviews.llvm.org/harbormaster/unit/view/1482705/



Comment at: 
compiler-rt/test/sanitizer_common/TestCases/sanitizer_coverage_trace_loads_stores.cpp:5
+//
+// RUN: %clangxx -O0 %s -fsanitize-coverage=func,trace-loads,trace-stores -o %t
+// RUN: %run %t 2>&1 | FileCheck %s

According to the documentation update in this patch, these flags don't work 
without trace-pc or inline-8bit-counters.



Comment at: llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp:719-720
+  if (Options.TraceStores)
+if (StoreInst *LD = dyn_cast(&Inst))
+  Stores.push_back(LD);
   if (Options.StackDepth)

nit


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113447

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

[PATCH] D111463: [OpenMP] Remove doing assumption propagation in the front end.

[Johannes Doerfert via Phabricator via cfe-commits]

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

I'm assuming this is simply a revert, LG in that case, once the others landed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111463

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

[PATCH] D113391: [Modules] Don't support clang module and c++20 module at the same time

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticDriverKinds.td:162-163
   "'%0': unable to use module files with this tool">;
+def err_drv_clang_module_cxx_module_conflicts : Error <
+  "Unable to use clang module and c++20 module at the same time.">;
 def err_drv_clang_unsupported : Error<

I think we can get away with `err_drv_argument_not_allowed_with` for this 
diagnostic -- this also will tell the user *which* options are in conflict.



Comment at: clang/include/clang/Basic/DiagnosticFrontendKinds.td:244
   DefaultFatal;
+def err_conflicts_clang_module_and_cxx20_module :
+  Error<"Unable to use clang module and c++20 module at the same time.">;

I think it's reasonable to give a diagnostic from the driver when the user does 
this, but in the FE for a cc1 invocation, I'm a bit less sympathetic to giving 
people nice diagnostics. Do we need this diagnostic, or can we pick one option 
to be the "winner" in this case?



Comment at: clang/test/ClangScanDeps/Inputs/header-search-pruning/cdb.json:3
+  "directory" : "DIR",
+  "command" : "clang -E DIR/header-search-pruning.cpp -Ibegin -I1 -Ia -I3 -I4 
-I5 -I6 -Ib -I8 -Iend DEFINES -fmodules -fmodules-cache-path=DIR/module-cache 
-fimplicit-modules -fmodule-map-file=DIR/module.modulemap",
+  "file" : "DIR/header-search-pruning.cpp"

jansvoboda11 wrote:
> ChuanqiXu wrote:
> > jansvoboda11 wrote:
> > > ChuanqiXu wrote:
> > > > jansvoboda11 wrote:
> > > > > Can you explain why `-fcxx-modules` is removed? We want to explicitly 
> > > > > enable Clang modules for C++ inputs here. That's off by default in 
> > > > > our downstream repo and we'd like to keep this upstream to prevent 
> > > > > conflicts. (it's benign upstream)
> > > > According to the discussion in the link, I think it is in consensus 
> > > > that we decide to not support clang modules and c++20 modules at the 
> > > > same time. (I know many people may not have visited it. If any one 
> > > > disagree with the higher idea, I think it would be better to reply in 
> > > > that thread). 
> > > > So the original test case would fail.
> > > > 
> > > > > We want to explicitly enable Clang modules for C++ inputs here. 
> > > > 
> > > > I am not sure if I missed any thing. Personally, it looks like the test 
> > > > now would test clang modules for c++ inputs. Since it has `-fmodule` 
> > > > option so that clang module is enabled and the input is C++ (from its 
> > > > suffix). Do I misunderstand you?
> > > > According to the discussion in the link, I think it is in consensus 
> > > > that we decide to not support clang modules and c++20 modules at the 
> > > > same time. (I know many people may not have visited it. If any one 
> > > > disagree with the higher idea, I think it would be better to reply in 
> > > > that thread). 
> > > > So the original test case would fail.
> > > 
> > > What's the error message? As I say, we're enabling Clang modules for C++ 
> > > input here, not C++20 modules.
> > > 
> > > > > We want to explicitly enable Clang modules for C++ inputs here. 
> > > > 
> > > > I am not sure if I missed any thing. Personally, it looks like the test 
> > > > now would test clang modules for c++ inputs. Since it has `-fmodule` 
> > > > option so that clang module is enabled and the input is C++ (from its 
> > > > suffix). Do I misunderstand you?
> > > 
> > > Right. What I'm saying is that in our downstream repo, `-fmodules` is not 
> > > enough to enable Clang modules for C++ inputs, you need to do it via 
> > > `-fcxx-modules`. And we'd like to keep it upstream, even though it's 
> > > benign here, to avoid conflicts between the repos.
> > > What's the error message? As I say, we're enabling Clang modules for C++ 
> > > input here, not C++20 modules.
> > 
> > The error message is added in this patch. After this patch landed, the 
> > original intentional behavior would be `-fmodules` to enable clang module 
> > and `-fcxx-modules` to enable C++20 modules.
> > 
> > > Right. What I'm saying is that in our downstream repo, -fmodules is not 
> > > enough to enable Clang modules for C++ inputs, you need to do it via 
> > > -fcxx-modules. And we'd like to keep it upstream, even though it's benign 
> > > here, to avoid conflicts between the repos.
> > 
> > Got it. But it conflicts with the idea that disable clang module and c++20 
> > module at the same time. Personally, I think it would be better to edit the 
> > code in downstream. @aaron.ballman sorry if I ping you too frequently. But 
> > I think now we need input from you.
> Ah, I understand now, thanks for explaining.
> 
> I'm worried about changing the behavior of a driver flag, we generally don't 
> break existing driver options. Have you considered keeping the `-fmodules` 
> and `-fcxx-modules` semantics intact and instead add new `-fno-c++20-modules` 
> flag or something like that?
> I'm worried about ch

[PATCH] D113490: [NFC] Let Microsoft mangler accept GlobalDecl

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl created this revision.
yaxunl added reviewers: rjmccall, tra.
yaxunl requested review of this revision.

This is a follow up of https://reviews.llvm.org/D75700
where support of GlobalDecl with Microsoft mangler
is incomplete.


https://reviews.llvm.org/D113490

Files:
  clang/lib/AST/MicrosoftMangle.cpp

Index: clang/lib/AST/MicrosoftMangle.cpp
===
--- clang/lib/AST/MicrosoftMangle.cpp
+++ clang/lib/AST/MicrosoftMangle.cpp
@@ -21,6 +21,7 @@
 #include "clang/AST/DeclTemplate.h"
 #include "clang/AST/Expr.h"
 #include "clang/AST/ExprCXX.h"
+#include "clang/AST/GlobalDecl.h"
 #include "clang/AST/Mangle.h"
 #include "clang/AST/VTableBuilder.h"
 #include "clang/Basic/ABI.h"
@@ -39,6 +40,18 @@
 
 namespace {
 
+// Get GlobalDecl of DeclContext of local entities.
+static GlobalDecl getGlobalDeclAsDeclContext(const DeclContext *DC) {
+  GlobalDecl GD;
+  if (auto *CD = dyn_cast(DC))
+GD = GlobalDecl(CD, Ctor_Complete);
+  else if (auto *DD = dyn_cast(DC))
+GD = GlobalDecl(DD, Dtor_Complete);
+  else
+GD = GlobalDecl(cast(DC));
+  return GD;
+}
+
 struct msvc_hashing_ostream : public llvm::raw_svector_ostream {
   raw_ostream &OS;
   llvm::SmallString<64> Buffer;
@@ -345,9 +358,9 @@
 
   raw_ostream &getStream() const { return Out; }
 
-  void mangle(const NamedDecl *D, StringRef Prefix = "?");
-  void mangleName(const NamedDecl *ND);
-  void mangleFunctionEncoding(const FunctionDecl *FD, bool ShouldMangle);
+  void mangle(GlobalDecl GD, StringRef Prefix = "?");
+  void mangleName(GlobalDecl GD);
+  void mangleFunctionEncoding(GlobalDecl GD, bool ShouldMangle);
   void mangleVariableEncoding(const VarDecl *VD);
   void mangleMemberDataPointer(const CXXRecordDecl *RD, const ValueDecl *VD,
StringRef Prefix = "$");
@@ -370,7 +383,7 @@
   const FunctionDecl *D = nullptr,
   bool ForceThisQuals = false,
   bool MangleExceptionSpec = true);
-  void mangleNestedName(const NamedDecl *ND);
+  void mangleNestedName(GlobalDecl GD);
 
 private:
   bool isStructorDecl(const NamedDecl *ND) const {
@@ -384,10 +397,10 @@
   AddrSpace == LangAS::ptr32_uptr));
   }
 
-  void mangleUnqualifiedName(const NamedDecl *ND) {
-mangleUnqualifiedName(ND, ND->getDeclName());
+  void mangleUnqualifiedName(GlobalDecl GD) {
+mangleUnqualifiedName(GD, cast(GD.getDecl())->getDeclName());
   }
-  void mangleUnqualifiedName(const NamedDecl *ND, DeclarationName Name);
+  void mangleUnqualifiedName(GlobalDecl GD, DeclarationName Name);
   void mangleSourceName(StringRef Name);
   void mangleOperatorName(OverloadedOperatorKind OO, SourceLocation Loc);
   void mangleCXXDtorType(CXXDtorType T);
@@ -396,9 +409,9 @@
   void manglePointerCVQualifiers(Qualifiers Quals);
   void manglePointerExtQualifiers(Qualifiers Quals, QualType PointeeType);
 
-  void mangleUnscopedTemplateName(const TemplateDecl *ND);
+  void mangleUnscopedTemplateName(GlobalDecl GD);
   void
-  mangleTemplateInstantiationName(const TemplateDecl *TD,
+  mangleTemplateInstantiationName(GlobalDecl GD,
   const TemplateArgumentList &TemplateArgs);
   void mangleObjCMethodName(const ObjCMethodDecl *MD);
 
@@ -533,7 +546,8 @@
   return true;
 }
 
-void MicrosoftCXXNameMangler::mangle(const NamedDecl *D, StringRef Prefix) {
+void MicrosoftCXXNameMangler::mangle(GlobalDecl GD, StringRef Prefix) {
+  const NamedDecl *D = cast(GD.getDecl());
   // MSVC doesn't mangle C++ names the same way it mangles extern "C" names.
   // Therefore it's really important that we don't decorate the
   // name with leading underscores or leading/trailing at signs. So, by
@@ -542,9 +556,9 @@
 
   //  ::= ?  
   Out << Prefix;
-  mangleName(D);
+  mangleName(GD);
   if (const FunctionDecl *FD = dyn_cast(D))
-mangleFunctionEncoding(FD, Context.shouldMangleDeclName(FD));
+mangleFunctionEncoding(GD, Context.shouldMangleDeclName(FD));
   else if (const VarDecl *VD = dyn_cast(D))
 mangleVariableEncoding(VD);
   else if (isa(D))
@@ -558,8 +572,9 @@
 llvm_unreachable("Tried to mangle unexpected NamedDecl!");
 }
 
-void MicrosoftCXXNameMangler::mangleFunctionEncoding(const FunctionDecl *FD,
+void MicrosoftCXXNameMangler::mangleFunctionEncoding(GlobalDecl GD,
  bool ShouldMangle) {
+  const FunctionDecl *FD = cast(GD.getDecl());
   //  ::=  
 
   // Since MSVC operates on the type as written and not the canonical type, it
@@ -770,13 +785,13 @@
   mangleCallingConvention(MD->getType()->castAs());
 }
 
-void MicrosoftCXXNameMangler::mangleName(const NamedDecl *ND) {
+void MicrosoftCXXNameMangler::mangleName(GlobalDecl GD) {
   //  ::=  {[]+ | []}? @
 
   // Always start with the unqualified name.
-  mangleUnqualifiedName(ND);
+  mangleUnqualifiedName(GD);
 
-  mangleNestedName(ND);
+  mangleNestedName(GD);

[PATCH] D113491: [HIP] Fix device stub name for Windows

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl created this revision.
yaxunl added reviewers: tra, rjmccall.
yaxunl requested review of this revision.

This is a follow up of https://reviews.llvm.org/D68578
where device stub name is changed for Itanium
mangling but not Microsoft mangling.


https://reviews.llvm.org/D113491

Files:
  clang/include/clang/AST/GlobalDecl.h
  clang/lib/AST/MicrosoftMangle.cpp
  clang/test/CodeGenCUDA/kernel-stub-name.cu


Index: clang/test/CodeGenCUDA/kernel-stub-name.cu
===
--- clang/test/CodeGenCUDA/kernel-stub-name.cu
+++ clang/test/CodeGenCUDA/kernel-stub-name.cu
@@ -28,8 +28,8 @@
 // GNU: @[[HDKERN:_Z11kernel_declv]] = external constant void ()*, align 8
 
 // MSVC: @[[HCKERN:ckernel]] = dso_local constant void ()* 
@[[CSTUB:__device_stub__ckernel]], align 8
-// MSVC: @[[HNSKERN:"\?nskernel@ns@@YAXXZ.*"]] = dso_local constant void ()* 
@[[NSSTUB:"\?nskernel@ns@@YAXXZ"]], align 8
-// MSVC: @[[HTKERN:"\?\?\$kernelfunc@H@@YAXXZ.*"]] = linkonce_odr dso_local 
constant void ()* @[[TSTUB:"\?\?\$kernelfunc@H@@YAXXZ.*"]], comdat, align 8
+// MSVC: @[[HNSKERN:"\?nskernel@ns@@YAXXZ.*"]] = dso_local constant void ()* 
@[[NSSTUB:"\?__device_stub__nskernel@ns@@YAXXZ"]], align 8
+// MSVC: @[[HTKERN:"\?\?\$kernelfunc@H@@YAXXZ.*"]] = linkonce_odr dso_local 
constant void ()* @[[TSTUB:"\?\?\$__device_stub__kernelfunc@H@@YAXXZ.*"]], 
comdat, align 8
 // MSVC: @[[HDKERN:"\?kernel_decl@@YAXXZ.*"]] = external dso_local constant 
void ()*, align 8
 
 extern "C" __global__ void ckernel() {}
@@ -69,7 +69,7 @@
 // CHECK: call void @[[NSSTUB]]()
 // CHECK: call void @[[TSTUB]]()
 // GNU: call void @[[DSTUB:_Z26__device_stub__kernel_declv]]()
-// MSVC: call void @[[DSTUB:"\?kernel_decl@@YAXXZ"]]()
+// MSVC: call void @[[DSTUB:"\?__device_stub__kernel_decl@@YAXXZ"]]()
 
 extern "C" void fun1(void) {
   ckernel<<<1, 1>>>();
Index: clang/lib/AST/MicrosoftMangle.cpp
===
--- clang/lib/AST/MicrosoftMangle.cpp
+++ clang/lib/AST/MicrosoftMangle.cpp
@@ -962,7 +962,20 @@
   switch (Name.getNameKind()) {
 case DeclarationName::Identifier: {
   if (const IdentifierInfo *II = Name.getAsIdentifierInfo()) {
-mangleSourceName(II->getName());
+bool IsDeviceStub =
+ND &&
+((isa(ND) && ND->hasAttr()) ||
+ (isa(ND) &&
+  cast(ND)
+  ->getTemplatedDecl()
+  ->hasAttr())) &&
+GD.getKernelReferenceKind() == KernelReferenceKind::Stub;
+if (IsDeviceStub) {
+  llvm::SmallString<128> Buf;
+  mangleSourceName((llvm::Twine("__device_stub__") + II->getName())
+   .toStringRef(Buf));
+} else
+  mangleSourceName(II->getName());
 break;
   }
 
Index: clang/include/clang/AST/GlobalDecl.h
===
--- clang/include/clang/AST/GlobalDecl.h
+++ clang/include/clang/AST/GlobalDecl.h
@@ -18,6 +18,7 @@
 #include "clang/AST/DeclCXX.h"
 #include "clang/AST/DeclObjC.h"
 #include "clang/AST/DeclOpenMP.h"
+#include "clang/AST/DeclTemplate.h"
 #include "clang/Basic/ABI.h"
 #include "clang/Basic/LLVM.h"
 #include "llvm/ADT/DenseMapInfo.h"
@@ -129,8 +130,12 @@
   }
 
   KernelReferenceKind getKernelReferenceKind() const {
-assert(isa(getDecl()) &&
-   cast(getDecl())->hasAttr() &&
+assert(((isa(getDecl()) &&
+ cast(getDecl())->hasAttr()) ||
+(isa(getDecl()) &&
+ cast(getDecl())
+ ->getTemplatedDecl()
+ ->hasAttr())) &&
"Decl is not a GPU kernel!");
 return static_cast(Value.getInt());
   }


Index: clang/test/CodeGenCUDA/kernel-stub-name.cu
===
--- clang/test/CodeGenCUDA/kernel-stub-name.cu
+++ clang/test/CodeGenCUDA/kernel-stub-name.cu
@@ -28,8 +28,8 @@
 // GNU: @[[HDKERN:_Z11kernel_declv]] = external constant void ()*, align 8
 
 // MSVC: @[[HCKERN:ckernel]] = dso_local constant void ()* @[[CSTUB:__device_stub__ckernel]], align 8
-// MSVC: @[[HNSKERN:"\?nskernel@ns@@YAXXZ.*"]] = dso_local constant void ()* @[[NSSTUB:"\?nskernel@ns@@YAXXZ"]], align 8
-// MSVC: @[[HTKERN:"\?\?\$kernelfunc@H@@YAXXZ.*"]] = linkonce_odr dso_local constant void ()* @[[TSTUB:"\?\?\$kernelfunc@H@@YAXXZ.*"]], comdat, align 8
+// MSVC: @[[HNSKERN:"\?nskernel@ns@@YAXXZ.*"]] = dso_local constant void ()* @[[NSSTUB:"\?__device_stub__nskernel@ns@@YAXXZ"]], align 8
+// MSVC: @[[HTKERN:"\?\?\$kernelfunc@H@@YAXXZ.*"]] = linkonce_odr dso_local constant void ()* @[[TSTUB:"\?\?\$__device_stub__kernelfunc@H@@YAXXZ.*"]], comdat, align 8
 // MSVC: @[[HDKERN:"\?kernel_decl@@YAXXZ.*"]] = external dso_local constant void ()*, align 8
 
 extern "C" __global__ void ckernel() {}
@@ -69,7 +69,7 @@
 // CHECK: call void @[[NSSTUB]]()
 // CHECK: call void @[[TSTUB]]()
 // GNU: call void @[[DSTUB:_Z

[PATCH] D112914: Misleading identifier detection

[Simon Pilgrim via Phabricator via cfe-commits]

RKSimon added a comment.

@serge-sans-paille Any luck with a fix for all the buildbot failures or should 
we revert ?  https://lab.llvm.org/buildbot/#/builders/109/builds/25932


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112914

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

[PATCH] D109751: [Clang] Support conversion between PPC double-double and IEEE float128

[Hubert Tong via Phabricator via cfe-commits]

hubert.reinterpretcast added inline comments.



Comment at: clang/lib/Sema/SemaExpr.cpp:1542
+  if (unsupportedTypeConversion(*this, LHSType, RHSType) &&
+  ACK != ACK_Conditional && ACK != ACK_CompAssign)
 return QualType();

GCC does not allow compound assignments either and that is is a context where 
the "usual arithmetic conversions" apply. Allowing them means this patch is 
going to need to be inventive with the semantics, because the type in with the 
calculation is to be performed is supposed to be the same one that would occur 
for the non-assigning version of the arithmetic operation.

Noting as well that "Conditional" is also a case where the "usual arithmetic 
conversions" apply. GCC seems to be happy with that particular case for some 
reason, but I don't think it makes sense to allow it for Clang: GCC's 
implementation has questionable semantics like choosing whatever type is not 
the same format as the ABI's 128-bit `long double` as the common type (in other 
words, the common type is IEEE for `-mabi=ibmlongdouble` and IBM for 
`-mabi=ieeelongdouble`).

GCC behaviour: `x` is "`long double`" and the conditional is `__float128`:
```
gcc -fsyntax-only -xc -<<<$'__ibm128 x;\n__float128 y;\nvoid q(int b) {\n  x + 
(b ? x : y);\n}'
: In function ‘q’:
:4:5: error: __float128 and long double cannot be used in the same 
expression
```

GCC behaviour: `y` is "`long double`" and the conditional is `__ibm128`:
```
gcc -fsyntax-only -xc -<<<$'__ibm128 x;\n__float128 y;\nvoid q(int b) {\n  y + 
(b ? x : y);\n}' -mabi=ieeelongdouble
cc1: warning: Using IEEE extended precision ‘long double’ [-Wpsabi]
: In function ‘q’:
:4:5: error: __ibm128 and long double cannot be used in the same 
expression
```

If we go with the GCC behaviour, there should be lots of explaining done. If we 
don't then, making the case an error avoids the inconsistency of making a 
choice regarding the common type for conditionals but not other applications of 
the usual arithmetic conversions.



Comment at: clang/test/Sema/float128-ld-incompatibility.cpp:39
+  q + b ? q : ld; // expected-no-error
 }

There's no tests for compound assignment...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109751

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

[PATCH] D109751: [Clang] Support conversion between PPC double-double and IEEE float128

[Hubert Tong via Phabricator via cfe-commits]

hubert.reinterpretcast added a comment.

It doesn't seem like the cases of implicit conversion that are expected to be 
allowed have been tested with C++?

  $ ./bin/clang -fsyntax-only -mcpu=pwr9 -mfloat128 -xc -<<<$'__ibm128 x; 
__float128 y; void f(void) { y = x; }'
  Return:  0x00:0   Tue Nov  9 11:53:23 2021 EST
  $ ./bin/clang -fsyntax-only -mcpu=pwr9 -mfloat128 -xc++ -<<<$'__ibm128 x; 
__float128 y; void f(void) { y = x; }'
  :1:46: error: assigning to '__float128' from incompatible type 
'__ibm128'
  __ibm128 x; __float128 y; void f(void) { y = x; }
   ^
  1 error generated.
  Return:  0x01:1   Tue Nov  9 11:53:43 2021 EST


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109751

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

[PATCH] D113391: [Modules] Don't support clang module and c++20 module at the same time

[David Blaikie via Phabricator via cfe-commits]

dblaikie added inline comments.



Comment at: clang/test/ClangScanDeps/Inputs/header-search-pruning/cdb.json:3
+  "directory" : "DIR",
+  "command" : "clang -E DIR/header-search-pruning.cpp -Ibegin -I1 -Ia -I3 -I4 
-I5 -I6 -Ib -I8 -Iend DEFINES -fmodules -fmodules-cache-path=DIR/module-cache 
-fimplicit-modules -fmodule-map-file=DIR/module.modulemap",
+  "file" : "DIR/header-search-pruning.cpp"

aaron.ballman wrote:
> jansvoboda11 wrote:
> > ChuanqiXu wrote:
> > > jansvoboda11 wrote:
> > > > ChuanqiXu wrote:
> > > > > jansvoboda11 wrote:
> > > > > > Can you explain why `-fcxx-modules` is removed? We want to 
> > > > > > explicitly enable Clang modules for C++ inputs here. That's off by 
> > > > > > default in our downstream repo and we'd like to keep this upstream 
> > > > > > to prevent conflicts. (it's benign upstream)
> > > > > According to the discussion in the link, I think it is in consensus 
> > > > > that we decide to not support clang modules and c++20 modules at the 
> > > > > same time. (I know many people may not have visited it. If any one 
> > > > > disagree with the higher idea, I think it would be better to reply in 
> > > > > that thread). 
> > > > > So the original test case would fail.
> > > > > 
> > > > > > We want to explicitly enable Clang modules for C++ inputs here. 
> > > > > 
> > > > > I am not sure if I missed any thing. Personally, it looks like the 
> > > > > test now would test clang modules for c++ inputs. Since it has 
> > > > > `-fmodule` option so that clang module is enabled and the input is 
> > > > > C++ (from its suffix). Do I misunderstand you?
> > > > > According to the discussion in the link, I think it is in consensus 
> > > > > that we decide to not support clang modules and c++20 modules at the 
> > > > > same time. (I know many people may not have visited it. If any one 
> > > > > disagree with the higher idea, I think it would be better to reply in 
> > > > > that thread). 
> > > > > So the original test case would fail.
> > > > 
> > > > What's the error message? As I say, we're enabling Clang modules for 
> > > > C++ input here, not C++20 modules.
> > > > 
> > > > > > We want to explicitly enable Clang modules for C++ inputs here. 
> > > > > 
> > > > > I am not sure if I missed any thing. Personally, it looks like the 
> > > > > test now would test clang modules for c++ inputs. Since it has 
> > > > > `-fmodule` option so that clang module is enabled and the input is 
> > > > > C++ (from its suffix). Do I misunderstand you?
> > > > 
> > > > Right. What I'm saying is that in our downstream repo, `-fmodules` is 
> > > > not enough to enable Clang modules for C++ inputs, you need to do it 
> > > > via `-fcxx-modules`. And we'd like to keep it upstream, even though 
> > > > it's benign here, to avoid conflicts between the repos.
> > > > What's the error message? As I say, we're enabling Clang modules for 
> > > > C++ input here, not C++20 modules.
> > > 
> > > The error message is added in this patch. After this patch landed, the 
> > > original intentional behavior would be `-fmodules` to enable clang module 
> > > and `-fcxx-modules` to enable C++20 modules.
> > > 
> > > > Right. What I'm saying is that in our downstream repo, -fmodules is not 
> > > > enough to enable Clang modules for C++ inputs, you need to do it via 
> > > > -fcxx-modules. And we'd like to keep it upstream, even though it's 
> > > > benign here, to avoid conflicts between the repos.
> > > 
> > > Got it. But it conflicts with the idea that disable clang module and 
> > > c++20 module at the same time. Personally, I think it would be better to 
> > > edit the code in downstream. @aaron.ballman sorry if I ping you too 
> > > frequently. But I think now we need input from you.
> > Ah, I understand now, thanks for explaining.
> > 
> > I'm worried about changing the behavior of a driver flag, we generally 
> > don't break existing driver options. Have you considered keeping the 
> > `-fmodules` and `-fcxx-modules` semantics intact and instead add new 
> > `-fno-c++20-modules` flag or something like that?
> > I'm worried about changing the behavior of a driver flag, we generally 
> > don't break existing driver options. Have you considered keeping the 
> > -fmodules and -fcxx-modules semantics intact and instead add new 
> > -fno-c++20-modules flag or something like that?
> 
> The goal is not "let users disable C++20 modules", it's "ensure the user 
> cannot enable two different kinds of modules at the same time". What I think 
> we want to avoid is "C++20 mode, but with Clang modules instead of standard 
> modules" or "C++20 mode, but with both clang and standard modules", etc. I 
> think the support matrix that makes sense to me is:
> 
> C++20 mode: you get standard modules, no other module schemes are allowed
> Pre-C++20 modes: you can opt into Clang modules or you can opt into C++20 
> modules
> Non-C++ modes: you can opt into Clang modules (maybe we want to als

[PATCH] D109751: [Clang] Support conversion between PPC double-double and IEEE float128

[Hubert Tong via Phabricator via cfe-commits]

hubert.reinterpretcast added a comment.

@qiucf, I'm on vacation (for 3 weeks). For the C++ side, I suggest having a 
test for the narrowing conversion diagnostic in C++. My recollection is that 
GCC's odd behaviour around the conditional operator has an analogue in its 
implementation of narrowing conversion detection (it's probably the same bug).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109751

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

[PATCH] D98895: [X86][clang] Disable long double type for -mno-x87 option

[Elizabeth Andrews via Phabricator via cfe-commits]

eandrews added a comment.

This patch causes a regression.

To reproduce - `clang -cc1 -fsycl-is-device -triple spir64 test.cpp`

  // expected-note@+2 {{'bar<__float128>' defined here}}
  template 
  T bar() { return T(); };
  
  void usage() {
// expected-error@+2 {{'bar<__float128>' requires 128 bit size '__float128' 
type support, but target 'spir64' does not support it}}
// expected-error@+1 {{'__float128' is not supported on this target}}
auto malAutoTemp5 = bar<__float128>();
  }
  template 
  __attribute__((sycl_kernel)) void kernel_single_task(const Func &kernelFunc) {
kernelFunc(); // expected-note {{called by 'kernel_single_task([=]() {
  usage(); // expected-note {{called by 'operator()'}}
});
return 0;
  }

This test now fails due to an additional diagnostic generated at template 
definition.

  test.cpp:x:3: error: 'bar<__float128>' requires 128 bit size '__float128' 
type support, but target 'spir64' does not support it
  T bar() { return T(); };
^

I looked at it briefly, and I believe the issue is call to `checkTypeSupport()` 
in `ActOnFinishFunctionBody()`. I tried deleting the call but it breaks tests 
(E.g. L26 in x86_64-no-x87.cpp). @asavonic Please take a look. I will be 
reverting the patch if this cannot be fixed soon.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98895

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

[clang] a19da87 - [ARM] implement support for TLS register based stack protector

[Ard Biesheuvel via cfe-commits]

Author: Ard Biesheuvel
Date: 2021-11-09T18:19:47+01:00
New Revision: a19da876ab93d54ebc20aadd12820f74220d2f50

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

LOG: [ARM] implement support for TLS register based stack protector

Implement support for loading the stack canary from a memory location held in
the TLS register, with an optional offset applied. This is used by the Linux
kernel to implement per-task stack canaries, which is impossible on SMP systems
when using a global variable for the stack canary.

Reviewed By: nickdesaulniers

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

Added: 
llvm/test/CodeGen/ARM/stack-guard-tls.ll

Modified: 
clang/include/clang/Basic/DiagnosticCommonKinds.td
clang/include/clang/Basic/DiagnosticDriverKinds.td
clang/lib/Driver/ToolChains/Clang.cpp
clang/test/Driver/stack-protector-guard.c
llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp
llvm/lib/Target/ARM/ARMInstrInfo.cpp
llvm/lib/Target/ARM/Thumb1InstrInfo.cpp
llvm/lib/Target/ARM/Thumb2InstrInfo.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticCommonKinds.td 
b/clang/include/clang/Basic/DiagnosticCommonKinds.td
index 1ed1c8cd9a19f..fe4ac5ed6cb03 100644
--- a/clang/include/clang/Basic/DiagnosticCommonKinds.td
+++ b/clang/include/clang/Basic/DiagnosticCommonKinds.td
@@ -298,6 +298,8 @@ def err_target_unsupported_unaligned : Error<
   "the %0 sub-architecture does not support unaligned accesses">;
 def err_target_unsupported_execute_only : Error<
   "execute only is not supported for the %0 sub-architecture">;
+def err_target_unsupported_tp_hard : Error<
+  "hardware TLS register is not supported for the %0 sub-architecture">;
 def err_target_unsupported_mcmse : Error<
   "-mcmse is not supported for %0">;
 def err_opt_not_valid_with_opt : Error<

diff  --git a/clang/include/clang/Basic/DiagnosticDriverKinds.td 
b/clang/include/clang/Basic/DiagnosticDriverKinds.td
index fa464952189ba..8e7c14dc1549b 100644
--- a/clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ b/clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -592,4 +592,7 @@ def err_cc1_round_trip_ok_then_fail : Error<
   "generated arguments parse failed in round-trip">;
 def err_cc1_round_trip_mismatch : Error<
   "generated arguments do not match in round-trip">;
+
+def err_drv_ssp_missing_offset_argument : Error<
+  "'%0' is used without '-mstack-protector-guard-offset', and there is no 
default">;
 }

diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index dc20ae05ed419..e8ad105a78290 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -3162,14 +3162,44 @@ static void RenderSSPOptions(const Driver &D, const 
ToolChain &TC,
   const std::string &TripleStr = EffectiveTriple.getTriple();
   if (Arg *A = Args.getLastArg(options::OPT_mstack_protector_guard_EQ)) {
 StringRef Value = A->getValue();
-if (!EffectiveTriple.isX86() && !EffectiveTriple.isAArch64())
+if (!EffectiveTriple.isX86() && !EffectiveTriple.isAArch64() &&
+!EffectiveTriple.isARM() && !EffectiveTriple.isThumb())
   D.Diag(diag::err_drv_unsupported_opt_for_target)
   << A->getAsString(Args) << TripleStr;
-if (EffectiveTriple.isX86() && Value != "tls" && Value != "global") {
+if ((EffectiveTriple.isX86() || EffectiveTriple.isARM() ||
+ EffectiveTriple.isThumb()) &&
+Value != "tls" && Value != "global") {
   D.Diag(diag::err_drv_invalid_value_with_suggestion)
   << A->getOption().getName() << Value << "tls global";
   return;
 }
+if ((EffectiveTriple.isARM() || EffectiveTriple.isThumb()) &&
+Value == "tls") {
+  if (!Args.hasArg(options::OPT_mstack_protector_guard_offset_EQ)) {
+D.Diag(diag::err_drv_ssp_missing_offset_argument)
+<< A->getAsString(Args);
+return;
+  }
+  // Check whether the target subarch supports the hardware TLS register
+  if (arm::getARMSubArchVersionNumber(EffectiveTriple) < 7 &&
+  llvm::ARM::parseArch(EffectiveTriple.getArchName()) !=
+  llvm::ARM::ArchKind::ARMV6T2) {
+D.Diag(diag::err_target_unsupported_tp_hard)
+<< EffectiveTriple.getArchName();
+return;
+  }
+  // Check whether the user asked for something other than -mtp=cp15
+  if (Arg *A = Args.getLastArg(options::OPT_mtp_mode_EQ)) {
+StringRef Value = A->getValue();
+if (Value != "cp15") {
+  D.Diag(diag::err_drv_argument_not_allowed_with)
+  << A->getAsString(Args) << "-mstack-protector-guard=tls";
+  return;
+}
+  }
+  CmdArgs.push_back("-target-feature");
+  CmdArgs.push_back("+read-tp-hard");
+  

[PATCH] D112768: [ARM] implement support for TLS register based stack protector

[Ard Biesheuvel via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
ardb marked an inline comment as done.
Closed by commit rGa19da876ab93: [ARM] implement support for TLS register based 
stack protector (authored by ardb).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112768

Files:
  clang/include/clang/Basic/DiagnosticCommonKinds.td
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/stack-protector-guard.c
  llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp
  llvm/lib/Target/ARM/ARMInstrInfo.cpp
  llvm/lib/Target/ARM/Thumb1InstrInfo.cpp
  llvm/lib/Target/ARM/Thumb2InstrInfo.cpp
  llvm/test/CodeGen/ARM/stack-guard-tls.ll

Index: llvm/test/CodeGen/ARM/stack-guard-tls.ll
===
--- /dev/null
+++ llvm/test/CodeGen/ARM/stack-guard-tls.ll
@@ -0,0 +1,38 @@
+; RUN: split-file %s %t
+; RUN: cat %t/main.ll %t/a.ll > %t/a2.ll
+; RUN: cat %t/main.ll %t/b.ll > %t/b2.ll
+; RUN: llc %t/a2.ll -mtriple=armv7-unknown-linux-gnueabihf -mattr=+read-tp-hard -o - | \
+; RUN: FileCheck --check-prefixes=CHECK,CHECK-SMALL %s
+; RUN: llc %t/a2.ll -mtriple=thumbv7-unknown-linux-gnueabihf -mattr=+read-tp-hard -o - | \
+; RUN: FileCheck --check-prefixes=CHECK,CHECK-SMALL %s
+; RUN: llc %t/b2.ll -mtriple=armv7-unknown-linux-gnueabihf -mattr=+read-tp-hard -o - | \
+; RUN: FileCheck --check-prefixes=CHECK,CHECK-LARGE %s
+; RUN: llc %t/b2.ll -mtriple=thumbv7-unknown-linux-gnueabihf -mattr=+read-tp-hard -o - | \
+; RUN: FileCheck --check-prefixes=CHECK,CHECK-LARGE %s
+
+;--- main.ll
+declare void @baz(i32*)
+
+define void @foo(i64 %t) sspstrong {
+  %vla = alloca i32, i64 %t, align 4
+  call void @baz(i32* nonnull %vla)
+  ret void
+}
+!llvm.module.flags = !{!1, !2}
+!1 = !{i32 2, !"stack-protector-guard", !"tls"}
+
+;--- a.ll
+!2 = !{i32 2, !"stack-protector-guard-offset", i32 1296}
+
+;--- b.ll
+!2 = !{i32 2, !"stack-protector-guard-offset", i32 4296}
+
+; CHECK: mrc p15, #0, [[REG1:r[0-9]+]], c13, c0, #3
+; CHECK-SMALL-NEXT: ldr{{(\.w)?}} [[REG1]], {{\[}}[[REG1]], #1296]
+; CHECK-LARGE-NEXT: add{{(\.w)?}} [[REG1]], [[REG1]], #4096
+; CHECK-LARGE-NEXT: ldr{{(\.w)?}} [[REG1]], {{\[}}[[REG1]], #200]
+; CHECK: bl baz
+; CHECK: mrc p15, #0, [[REG2:r[0-9]+]], c13, c0, #3
+; CHECK-SMALL-NEXT: ldr{{(\.w)?}} [[REG2]], {{\[}}[[REG2]], #1296]
+; CHECK-LARGE-NEXT: add{{(\.w)?}} [[REG2]], [[REG2]], #4096
+; CHECK-LARGE-NEXT: ldr{{(\.w)?}} [[REG2]], {{\[}}[[REG2]], #200]
Index: llvm/lib/Target/ARM/Thumb2InstrInfo.cpp
===
--- llvm/lib/Target/ARM/Thumb2InstrInfo.cpp
+++ llvm/lib/Target/ARM/Thumb2InstrInfo.cpp
@@ -250,6 +250,13 @@
 void Thumb2InstrInfo::expandLoadStackGuard(
 MachineBasicBlock::iterator MI) const {
   MachineFunction &MF = *MI->getParent()->getParent();
+  Module &M = *MF.getFunction().getParent();
+
+  if (M.getStackProtectorGuard() == "tls") {
+expandLoadStackGuardBase(MI, ARM::t2MRC, ARM::t2LDRi12);
+return;
+  }
+
   const GlobalValue *GV =
   cast((*MI->memoperands_begin())->getValue());
 
Index: llvm/lib/Target/ARM/Thumb1InstrInfo.cpp
===
--- llvm/lib/Target/ARM/Thumb1InstrInfo.cpp
+++ llvm/lib/Target/ARM/Thumb1InstrInfo.cpp
@@ -135,6 +135,11 @@
 MachineBasicBlock::iterator MI) const {
   MachineFunction &MF = *MI->getParent()->getParent();
   const TargetMachine &TM = MF.getTarget();
+  Module &M = *MF.getFunction().getParent();
+
+  assert(M.getStackProtectorGuard() != "tls" &&
+ "TLS stack protector not supported for Thumb1 targets");
+
   if (TM.isPositionIndependent())
 expandLoadStackGuardBase(MI, ARM::tLDRLIT_ga_pcrel, ARM::tLDRi);
   else
Index: llvm/lib/Target/ARM/ARMInstrInfo.cpp
===
--- llvm/lib/Target/ARM/ARMInstrInfo.cpp
+++ llvm/lib/Target/ARM/ARMInstrInfo.cpp
@@ -95,6 +95,12 @@
   MachineFunction &MF = *MI->getParent()->getParent();
   const ARMSubtarget &Subtarget = MF.getSubtarget();
   const TargetMachine &TM = MF.getTarget();
+  Module &M = *MF.getFunction().getParent();
+
+  if (M.getStackProtectorGuard() == "tls") {
+expandLoadStackGuardBase(MI, ARM::MRC, ARM::LDRi12);
+return;
+  }
 
   const GlobalValue *GV =
   cast((*MI->memoperands_begin())->getValue());
Index: llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp
===
--- llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp
+++ llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp
@@ -4890,40 +4890,70 @@
   MachineBasicBlock &MBB = *MI->getParent();
   DebugLoc DL = MI->getDebugLoc();
   Register Reg = MI->getOperand(0).getReg();
-  const GlobalValue *GV =
-  cast((*MI->memoperands_begin())->getValue());
-  bool IsIndirect = Subtarget.isGVIndirectSymbol(GV);
   MachineInstrBuilder MIB;
+  

[clang] 2477272 - [ARM] reject -mtp=cp15 if target subarch does not support it

[Ard Biesheuvel via cfe-commits]

Author: Ard Biesheuvel
Date: 2021-11-09T18:29:30+01:00
New Revision: 24772720c54500714e2d48b9109bb62d5867ad95

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

LOG: [ARM] reject -mtp=cp15 if target subarch does not support it

Currently, we permit -mtp=cp15 even for targets that don't implement the
TLS register. When building for ARMv6 or earlier, this means we emit
instructions that will UNDEF at runtime. For Thumb1, passing -mtp=cp15
will trigger an assert in the backend.

So let's add some diagnostics to ensure that -mtp=cp15 is only accepted
for ARMv6T2 or newer.

Reviewed By: nickdesaulniers

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/Arch/ARM.cpp
clang/lib/Driver/ToolChains/Arch/ARM.h
clang/test/Driver/clang-translation.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Arch/ARM.cpp 
b/clang/lib/Driver/ToolChains/Arch/ARM.cpp
index 05d83c91ba0ef..21c091e1a0ba4 100644
--- a/clang/lib/Driver/ToolChains/Arch/ARM.cpp
+++ b/clang/lib/Driver/ToolChains/Arch/ARM.cpp
@@ -148,13 +148,21 @@ bool arm::useAAPCSForMachO(const llvm::Triple &T) {
 }
 
 // Select mode for reading thread pointer (-mtp=soft/cp15).
-arm::ReadTPMode arm::getReadTPMode(const Driver &D, const ArgList &Args) {
+arm::ReadTPMode arm::getReadTPMode(const Driver &D, const ArgList &Args,
+   const llvm::Triple &Triple) {
   if (Arg *A = Args.getLastArg(options::OPT_mtp_mode_EQ)) {
 arm::ReadTPMode ThreadPointer =
 llvm::StringSwitch(A->getValue())
 .Case("cp15", ReadTPMode::Cp15)
 .Case("soft", ReadTPMode::Soft)
 .Default(ReadTPMode::Invalid);
+if (ThreadPointer == ReadTPMode::Cp15 &&
+getARMSubArchVersionNumber(Triple) < 7 &&
+llvm::ARM::parseArch(Triple.getArchName()) !=
+llvm::ARM::ArchKind::ARMV6T2) {
+  D.Diag(diag::err_target_unsupported_tp_hard) << Triple.getArchName();
+  return ReadTPMode::Invalid;
+}
 if (ThreadPointer != ReadTPMode::Invalid)
   return ThreadPointer;
 if (StringRef(A->getValue()).empty())
@@ -422,7 +430,7 @@ void arm::getARMTargetFeatures(const Driver &D, const 
llvm::Triple &Triple,
   bool KernelOrKext =
   Args.hasArg(options::OPT_mkernel, options::OPT_fapple_kext);
   arm::FloatABI ABI = arm::getARMFloatABI(D, Triple, Args);
-  arm::ReadTPMode ThreadPointer = arm::getReadTPMode(D, Args);
+  arm::ReadTPMode ThreadPointer = arm::getReadTPMode(D, Args, Triple);
   llvm::Optional> WaCPU, WaFPU, WaHDiv,
   WaArch;
 

diff  --git a/clang/lib/Driver/ToolChains/Arch/ARM.h 
b/clang/lib/Driver/ToolChains/Arch/ARM.h
index 0ab0d6c281f80..b6fd68fbb9c62 100644
--- a/clang/lib/Driver/ToolChains/Arch/ARM.h
+++ b/clang/lib/Driver/ToolChains/Arch/ARM.h
@@ -53,7 +53,8 @@ FloatABI getARMFloatABI(const Driver &D, const llvm::Triple 
&Triple,
 const llvm::opt::ArgList &Args);
 void setFloatABIInTriple(const Driver &D, const llvm::opt::ArgList &Args,
  llvm::Triple &triple);
-ReadTPMode getReadTPMode(const Driver &D, const llvm::opt::ArgList &Args);
+ReadTPMode getReadTPMode(const Driver &D, const llvm::opt::ArgList &Args,
+ const llvm::Triple &Triple);
 void setArchNameInTriple(const Driver &D, const llvm::opt::ArgList &Args,
  types::ID InputType, llvm::Triple &Triple);
 

diff  --git a/clang/test/Driver/clang-translation.c 
b/clang/test/Driver/clang-translation.c
index 9802ee3da239f..230ea8e302024 100644
--- a/clang/test/Driver/clang-translation.c
+++ b/clang/test/Driver/clang-translation.c
@@ -110,15 +110,27 @@
 // ARMV5E: "-cc1"
 // ARMV5E: "-target-cpu" "arm1022e"
 
-// RUN: %clang -target arm-linux -mtp=cp15 -### -S %s -arch armv7 2>&1 | \
+// RUN: %clang -target armv7-linux -mtp=cp15 -### -S %s 2>&1 | \
 // RUN: FileCheck -check-prefix=ARMv7_THREAD_POINTER-HARD %s
 // ARMv7_THREAD_POINTER-HARD: "-target-feature" "+read-tp-hard"
 
-// RUN: %clang -target arm-linux -mtp=soft -### -S %s -arch armv7 2>&1 | \
+// RUN: %clang -target armv6t2-linux -mtp=cp15 -### -S %s 2>&1 | \
+// RUN: FileCheck -check-prefix=ARMv6T2_THREAD_POINTER-HARD %s
+// ARMv6T2_THREAD_POINTER-HARD: "-target-feature" "+read-tp-hard"
+
+// RUN: %clang -target armv5t-linux -mtp=cp15 -### -S %s 2>&1 | \
+// RUN: FileCheck -check-prefix=ARMv5_THREAD_POINTER_UNSUPP %s
+// ARMv5_THREAD_POINTER_UNSUPP: hardware TLS register is not supported for the 
armv5 sub-architecture
+
+// RUN: %clang -target thumbv6-linux -mtp=cp15 -### -S %s 2>&1 | \
+// RUN: FileCheck -check-prefix=ARMv6_THREAD_POINTER_UNSUPP %s
+// ARMv6_THREAD_POINTER_UNSUPP: hardware TLS register is not supported for the 
armv6 sub-architecture
+
+// RUN: %clang -tar

[PATCH] D55067: [HIP] Fix offset of kernel argument for AMDGPU target

[Matt Arsenault via Phabricator via cfe-commits]

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

Is this still relevant? We want to move towards consistently using byref for 
kernel arguments anyway


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

https://reviews.llvm.org/D55067

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

[PATCH] D113451: [PowerPC] [Clang] Enable Intel intrinsics support on FreeBSD

[Alfredo Dal'Ava Júnior via Phabricator via cfe-commits]

adalava updated this revision to Diff 385849.
adalava retitled this revision from "[PowerPC] [Clang] Add MMX intrinsics 
support to FreeBSD" to "[PowerPC] [Clang] Enable Intel intrinsics support on 
FreeBSD".
adalava edited the summary of this revision.
adalava added a comment.

add more ppc_wrappers


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113451

Files:
  clang/lib/Driver/CMakeLists.txt
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/PPCFreeBSD.cpp
  clang/lib/Driver/ToolChains/PPCFreeBSD.h
  clang/lib/Headers/ppc_wrappers/emmintrin.h
  clang/lib/Headers/ppc_wrappers/mm_malloc.h
  clang/lib/Headers/ppc_wrappers/mmintrin.h
  clang/lib/Headers/ppc_wrappers/pmmintrin.h
  clang/lib/Headers/ppc_wrappers/smmintrin.h
  clang/lib/Headers/ppc_wrappers/tmmintrin.h
  clang/lib/Headers/ppc_wrappers/xmmintrin.h
  clang/test/CodeGen/ppc-mm-malloc-le.c
  clang/test/CodeGen/ppc-mm-malloc.c
  clang/test/CodeGen/ppc-mmintrin.c
  clang/test/CodeGen/ppc-pmmintrin.c
  clang/test/CodeGen/ppc-smmintrin.c
  clang/test/CodeGen/ppc-tmmintrin.c
  clang/test/CodeGen/ppc-xmmintrin.c

Index: clang/test/CodeGen/ppc-xmmintrin.c
===
--- clang/test/CodeGen/ppc-xmmintrin.c
+++ clang/test/CodeGen/ppc-xmmintrin.c
@@ -10,6 +10,15 @@
 // RUN: %clang -x c++ -fsyntax-only -target powerpc64le-unknown-linux-gnu -mcpu=pwr8 -ffreestanding -DNO_WARN_X86_INTRINSICS %s \
 // RUN:   -fno-discard-value-names -mllvm -disable-llvm-optzns
 
+// RUN: %clang -S -emit-llvm -target powerpc64-unknown-freebsd13.0 -mcpu=pwr8 -ffreestanding -DNO_WARN_X86_INTRINSICS %s \
+// RUN:   -fno-discard-value-names -mllvm -disable-llvm-optzns -o - | llvm-cxxfilt -n | FileCheck %s --check-prefixes=CHECK,CHECK-BE
+// RUN: %clang -x c++ -fsyntax-only -target powerpc64-unknown-freebsd13.0 -mcpu=pwr8 -ffreestanding -DNO_WARN_X86_INTRINSICS %s \
+// RUN:   -fno-discard-value-names -mllvm -disable-llvm-optzns
+// RUN: %clang -S -emit-llvm -target powerpc64le-unknown-freebsd13.0 -mcpu=pwr8 -ffreestanding -DNO_WARN_X86_INTRINSICS %s \
+// RUN:   -fno-discard-value-names -mllvm -disable-llvm-optzns -o - | llvm-cxxfilt -n | FileCheck %s --check-prefixes=CHECK,CHECK-LE
+// RUN: %clang -x c++ -fsyntax-only -target powerpc64le-unknown-freebsd13.0 -mcpu=pwr8 -ffreestanding -DNO_WARN_X86_INTRINSICS %s \
+// RUN:   -fno-discard-value-names -mllvm -disable-llvm-optzns
+
 #include 
 
 __m128 res, m1, m2;
Index: clang/test/CodeGen/ppc-tmmintrin.c
===
--- clang/test/CodeGen/ppc-tmmintrin.c
+++ clang/test/CodeGen/ppc-tmmintrin.c
@@ -6,6 +6,11 @@
 // RUN: %clang -S -emit-llvm -target powerpc64le-gnu-linux -mcpu=pwr8 -ffreestanding -DNO_WARN_X86_INTRINSICS %s \
 // RUN:   -fno-discard-value-names -mllvm -disable-llvm-optzns -o - | llvm-cxxfilt -n | FileCheck %s --check-prefixes=CHECK,CHECK-LE
 
+// RUN: %clang -S -emit-llvm -target powerpc64-unknown-freebsd13.0 -mcpu=pwr8 -ffreestanding -DNO_WARN_X86_INTRINSICS %s \
+// RUN:   -fno-discard-value-names -mllvm -disable-llvm-optzns -o - | llvm-cxxfilt -n | FileCheck %s --check-prefixes=CHECK,CHECK-BE
+// RUN: %clang -S -emit-llvm -target powerpc64le-unknown-freebsd13.0 -mcpu=pwr8 -ffreestanding -DNO_WARN_X86_INTRINSICS %s \
+// RUN:   -fno-discard-value-names -mllvm -disable-llvm-optzns -o - | llvm-cxxfilt -n | FileCheck %s --check-prefixes=CHECK,CHECK-LE
+
 #include 
 
 __m64 res, m1, m2;
Index: clang/test/CodeGen/ppc-smmintrin.c
===
--- clang/test/CodeGen/ppc-smmintrin.c
+++ clang/test/CodeGen/ppc-smmintrin.c
@@ -6,6 +6,12 @@
 // RUN: %clang -S -emit-llvm -target powerpc64-unknown-linux-gnu -mcpu=pwr8 -ffreestanding -DNO_WARN_X86_INTRINSICS %s \
 // RUN:   -fno-discard-value-names -mllvm -disable-llvm-optzns -o - | llvm-cxxfilt -n | FileCheck %s
 
+// RUN: %clang -S -emit-llvm -target powerpc64le-unknown-freebsd13.0 -mcpu=pwr8 -ffreestanding -DNO_WARN_X86_INTRINSICS %s \
+// RUN:   -fno-discard-value-names -mllvm -disable-llvm-optzns -o - | llvm-cxxfilt -n | FileCheck %s
+// RUN: %clang -S -emit-llvm -target powerpc64-unknown-freebsd13.0 -mcpu=pwr8 -ffreestanding -DNO_WARN_X86_INTRINSICS %s \
+// RUN:   -fno-discard-value-names -mllvm -disable-llvm-optzns -o - | llvm-cxxfilt -n | FileCheck %s
+
+
 #include 
 
 __m128i mi, m1, m2;
Index: clang/test/CodeGen/ppc-pmmintrin.c
===
--- clang/test/CodeGen/ppc-pmmintrin.c
+++ clang/test/CodeGen/ppc-pmmintrin.c
@@ -6,6 +6,12 @@
 // RUN: %clang -S -emit-llvm -target powerpc64le-gnu-linux -mcpu=pwr8 -DNO_MM_MALLOC -ffreestanding -DNO_WARN_X86_INTRINSICS %s \
 // RUN:   -fno-discard-value-names -mllvm -disable-llvm-optzns -o - | llvm-cxxfilt -n | FileCheck %s
 
+// RUN: %clang -S -emit-llvm -target powerpc64-unknown-freebsd13.0 -mcpu=pwr8 -DNO_MM_MALLOC -ff

[PATCH] D113026: [ARM] reject -mtp=cp15 if target subarch does not support it

[Ard Biesheuvel via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
ardb marked an inline comment as done.
Closed by commit rG24772720c545: [ARM] reject -mtp=cp15 if target subarch does 
not support it (authored by ardb).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113026

Files:
  clang/lib/Driver/ToolChains/Arch/ARM.cpp
  clang/lib/Driver/ToolChains/Arch/ARM.h
  clang/test/Driver/clang-translation.c


Index: clang/test/Driver/clang-translation.c
===
--- clang/test/Driver/clang-translation.c
+++ clang/test/Driver/clang-translation.c
@@ -110,15 +110,27 @@
 // ARMV5E: "-cc1"
 // ARMV5E: "-target-cpu" "arm1022e"
 
-// RUN: %clang -target arm-linux -mtp=cp15 -### -S %s -arch armv7 2>&1 | \
+// RUN: %clang -target armv7-linux -mtp=cp15 -### -S %s 2>&1 | \
 // RUN: FileCheck -check-prefix=ARMv7_THREAD_POINTER-HARD %s
 // ARMv7_THREAD_POINTER-HARD: "-target-feature" "+read-tp-hard"
 
-// RUN: %clang -target arm-linux -mtp=soft -### -S %s -arch armv7 2>&1 | \
+// RUN: %clang -target armv6t2-linux -mtp=cp15 -### -S %s 2>&1 | \
+// RUN: FileCheck -check-prefix=ARMv6T2_THREAD_POINTER-HARD %s
+// ARMv6T2_THREAD_POINTER-HARD: "-target-feature" "+read-tp-hard"
+
+// RUN: %clang -target armv5t-linux -mtp=cp15 -### -S %s 2>&1 | \
+// RUN: FileCheck -check-prefix=ARMv5_THREAD_POINTER_UNSUPP %s
+// ARMv5_THREAD_POINTER_UNSUPP: hardware TLS register is not supported for the 
armv5 sub-architecture
+
+// RUN: %clang -target thumbv6-linux -mtp=cp15 -### -S %s 2>&1 | \
+// RUN: FileCheck -check-prefix=ARMv6_THREAD_POINTER_UNSUPP %s
+// ARMv6_THREAD_POINTER_UNSUPP: hardware TLS register is not supported for the 
armv6 sub-architecture
+
+// RUN: %clang -target armv7-linux -mtp=soft -### -S %s 2>&1 | \
 // RUN: FileCheck -check-prefix=ARMv7_THREAD_POINTER_SOFT %s
 // ARMv7_THREAD_POINTER_SOFT-NOT: "-target-feature" "+read-tp-hard"
 
-// RUN: %clang -target arm-linux -### -S %s -arch armv7 2>&1 | \
+// RUN: %clang -target armv7-linux -### -S %s 2>&1 | \
 // RUN: FileCheck -check-prefix=ARMv7_THREAD_POINTER_NON %s
 // ARMv7_THREAD_POINTER_NON-NOT: "-target-feature" "+read-tp-hard"
 
Index: clang/lib/Driver/ToolChains/Arch/ARM.h
===
--- clang/lib/Driver/ToolChains/Arch/ARM.h
+++ clang/lib/Driver/ToolChains/Arch/ARM.h
@@ -53,7 +53,8 @@
 const llvm::opt::ArgList &Args);
 void setFloatABIInTriple(const Driver &D, const llvm::opt::ArgList &Args,
  llvm::Triple &triple);
-ReadTPMode getReadTPMode(const Driver &D, const llvm::opt::ArgList &Args);
+ReadTPMode getReadTPMode(const Driver &D, const llvm::opt::ArgList &Args,
+ const llvm::Triple &Triple);
 void setArchNameInTriple(const Driver &D, const llvm::opt::ArgList &Args,
  types::ID InputType, llvm::Triple &Triple);
 
Index: clang/lib/Driver/ToolChains/Arch/ARM.cpp
===
--- clang/lib/Driver/ToolChains/Arch/ARM.cpp
+++ clang/lib/Driver/ToolChains/Arch/ARM.cpp
@@ -148,13 +148,21 @@
 }
 
 // Select mode for reading thread pointer (-mtp=soft/cp15).
-arm::ReadTPMode arm::getReadTPMode(const Driver &D, const ArgList &Args) {
+arm::ReadTPMode arm::getReadTPMode(const Driver &D, const ArgList &Args,
+   const llvm::Triple &Triple) {
   if (Arg *A = Args.getLastArg(options::OPT_mtp_mode_EQ)) {
 arm::ReadTPMode ThreadPointer =
 llvm::StringSwitch(A->getValue())
 .Case("cp15", ReadTPMode::Cp15)
 .Case("soft", ReadTPMode::Soft)
 .Default(ReadTPMode::Invalid);
+if (ThreadPointer == ReadTPMode::Cp15 &&
+getARMSubArchVersionNumber(Triple) < 7 &&
+llvm::ARM::parseArch(Triple.getArchName()) !=
+llvm::ARM::ArchKind::ARMV6T2) {
+  D.Diag(diag::err_target_unsupported_tp_hard) << Triple.getArchName();
+  return ReadTPMode::Invalid;
+}
 if (ThreadPointer != ReadTPMode::Invalid)
   return ThreadPointer;
 if (StringRef(A->getValue()).empty())
@@ -422,7 +430,7 @@
   bool KernelOrKext =
   Args.hasArg(options::OPT_mkernel, options::OPT_fapple_kext);
   arm::FloatABI ABI = arm::getARMFloatABI(D, Triple, Args);
-  arm::ReadTPMode ThreadPointer = arm::getReadTPMode(D, Args);
+  arm::ReadTPMode ThreadPointer = arm::getReadTPMode(D, Args, Triple);
   llvm::Optional> WaCPU, WaFPU, WaHDiv,
   WaArch;
 


Index: clang/test/Driver/clang-translation.c
===
--- clang/test/Driver/clang-translation.c
+++ clang/test/Driver/clang-translation.c
@@ -110,15 +110,27 @@
 // ARMV5E: "-cc1"
 // ARMV5E: "-target-cpu" "arm1022e"
 
-// RUN: %clang -target arm-linux -mtp=cp15 -### -S %s -arch armv7 2>&1 | \
+// RUN: %clang -target armv7-linux -mtp=cp15 -### 

[PATCH] D113429: [clang-tidy] Use `hasCanonicalType()` matcher in `bugprone-unused-raii` check

[Fabian Wolff via Phabricator via cfe-commits]

fwolff added a comment.

Thanks for reviewing this! Can you (or someone else) commit this for me? I 
don't have commit access.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113429

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

[clang] 196554d - Comment parsing: Complete list of Doxygen commands

[Aaron Puchert via cfe-commits]

Author: Aaron Puchert
Date: 2021-11-09T18:35:26+01:00
New Revision: 196554d42d329e45363afe2293d1fc19de75673d

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

LOG: Comment parsing: Complete list of Doxygen commands

These should be all the commands from [1] except those that are marked
obsolete, and "link" / "endlink", as that conflicts with the existing
HeaderDoc pair "link / "/link". For some commands we don't have the
ideal category, but it should work good enough for most cases.

There seems to be no existing test for most commands (except the ones
interpreted by -Wdocumentation), and to some extent such a test wouldn't
look very interesting. But I added a test for the correct parsing of
formulas, as they're a bit special. And I had to adapt
comment-lots-of-unknown-commands.c because typo correction was kicking
in and recognizing some of the commands.

This should fix a couple of reported bugs: PR17437, PR19581, PR24062
(partially, no diagnostic for matching cond/endcond), PR32909, PR37813,
PR44243 (partially, em...@domain.com must be addressed separately).

[1] https://www.doxygen.nl/manual/commands.html

Reviewed By: gribozavr2

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

Added: 


Modified: 
clang/include/clang/AST/CommentCommands.td
clang/lib/AST/CommentLexer.cpp
clang/test/AST/ast-dump-comment.cpp
clang/test/Index/comment-lots-of-unknown-commands.c
clang/unittests/AST/CommentLexer.cpp
clang/utils/TableGen/ClangCommentCommandInfoEmitter.cpp

Removed: 




diff  --git a/clang/include/clang/AST/CommentCommands.td 
b/clang/include/clang/AST/CommentCommands.td
index fbbfc9f7e0b77..7e962a4b4171b 100644
--- a/clang/include/clang/AST/CommentCommands.td
+++ b/clang/include/clang/AST/CommentCommands.td
@@ -87,8 +87,21 @@ def P  : InlineCommand<"p">;
 def A  : InlineCommand<"a">;
 def E  : InlineCommand<"e">;
 def Em : InlineCommand<"em">;
-def Ref: InlineCommand<"ref">;
-def Anchor : InlineCommand<"anchor">;
+def Emoji  : InlineCommand<"emoji">;
+
+def Anchor  : InlineCommand<"anchor">;
+def Ref : InlineCommand<"ref">;
+def RefItem : InlineCommand<"refitem">;
+def Cite: InlineCommand<"cite">;
+
+def CopyBrief   : InlineCommand<"copybrief">;
+def CopyDetails : InlineCommand<"copydetails">;
+def CopyDoc : InlineCommand<"copydoc">;
+
+// Typically not used inline, but they take a single word.
+def Extends: InlineCommand<"extends">;
+def Implements : InlineCommand<"implements">;
+def MemberOf   : InlineCommand<"memberof">;
 
 
//===--===//
 // BlockCommand
@@ -145,9 +158,11 @@ def Retval : BlockCommand<"retval">;
 def Sa : BlockCommand<"sa">;
 def See: BlockCommand<"see">;
 def Since  : BlockCommand<"since">;
+def Test   : BlockCommand<"test">;
 def Todo   : BlockCommand<"todo">;
 def Version: BlockCommand<"version">;
 def Warning: BlockCommand<"warning">;
+def XRefItem   : BlockCommand<"xrefitem">;
 // HeaderDoc commands
 def Abstract  : BlockCommand<"abstract"> { let IsBriefCommand = 1; }
 def ClassDesign   : RecordLikeDetailCommand<"classdesign">;
@@ -170,6 +185,8 @@ def SuperClass: RecordLikeDetailCommand<"superclass">;
 
 defm Code  : VerbatimBlockCommand<"code", "endcode">;
 defm Verbatim  : VerbatimBlockCommand<"verbatim", "endverbatim">;
+
+defm DocbookOnly : VerbatimBlockCommand<"docbookonly", "enddocbookonly">;
 defm Htmlonly  : VerbatimBlockCommand<"htmlonly", "endhtmlonly">;
 defm Latexonly : VerbatimBlockCommand<"latexonly", "endlatexonly">;
 defm Xmlonly   : VerbatimBlockCommand<"xmlonly", "endxmlonly">;
@@ -178,10 +195,19 @@ defm Rtfonly   : VerbatimBlockCommand<"rtfonly", 
"endrtfonly">;
 
 defm Dot : VerbatimBlockCommand<"dot", "enddot">;
 defm Msc : VerbatimBlockCommand<"msc", "endmsc">;
+defm Uml : VerbatimBlockCommand<"startuml", "enduml">;
+
+// Actually not verbatim blocks, we should also parse commands within them.
+defm Internal   : VerbatimBlockCommand<"internal", "endinternal">;
+// TODO: conflicts with HeaderDoc link, /link.
+//defm Link   : VerbatimBlockCommand<"link", "endlink">;
+defm ParBlock   : VerbatimBlockCommand<"parblock", "endparblock">;
+defm SecRefList : VerbatimBlockCommand<"secreflist", "endsecreflist">;
 
 // These three commands have special support in CommentLexer to recognize their
 // names.
 def  FDollar  : VerbatimBlockCommand<"f$">; // Inline LaTeX formula
+defm FParen   : VerbatimBlockCommand<"f(", "f)">; // Inline LaTeX text
 defm FBracket : VerbatimBlockCommand<"f[", "f]">; // Displayed LaTeX formula
 defm FBrace   : VerbatimBlockCommand<"f{", "f}">; // LaTeX environment
 
@@ -199,11 +225,18 @@ def Addtogroup : VerbatimLineCommand<"addtogrou

[PATCH] D111190: Comment parsing: Complete list of Doxygen commands

[Aaron Puchert via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
aaronpuchert marked an inline comment as done.
Closed by commit rG196554d42d32: Comment parsing: Complete list of Doxygen 
commands (authored by aaronpuchert).

Changed prior to commit:
  https://reviews.llvm.org/D90?vs=377492&id=385854#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90

Files:
  clang/include/clang/AST/CommentCommands.td
  clang/lib/AST/CommentLexer.cpp
  clang/test/AST/ast-dump-comment.cpp
  clang/test/Index/comment-lots-of-unknown-commands.c
  clang/unittests/AST/CommentLexer.cpp
  clang/utils/TableGen/ClangCommentCommandInfoEmitter.cpp

Index: clang/utils/TableGen/ClangCommentCommandInfoEmitter.cpp
===
--- clang/utils/TableGen/ClangCommentCommandInfoEmitter.cpp
+++ clang/utils/TableGen/ClangCommentCommandInfoEmitter.cpp
@@ -83,6 +83,12 @@
 default:
   Mangled += Str[i];
   break;
+case '(':
+  Mangled += "lparen";
+  break;
+case ')':
+  Mangled += "rparen";
+  break;
 case '[':
   Mangled += "lsquare";
   break;
Index: clang/unittests/AST/CommentLexer.cpp
===
--- clang/unittests/AST/CommentLexer.cpp
+++ clang/unittests/AST/CommentLexer.cpp
@@ -836,12 +836,12 @@
 // LaTeX verbatim blocks.
 TEST_F(CommentLexerTest, VerbatimBlock9) {
   const char *Source =
-"/// \\f$ Aaa \\f$ \\f[ Bbb \\f] \\f{ Ccc \\f}";
+"/// \\f$ Aaa \\f$ \\f[ Bbb \\f] \\f{ Ccc \\f} \\f( Ddd \\f)";
   std::vector Toks;
 
   lexString(Source, Toks);
 
-  ASSERT_EQ(13U, Toks.size());
+  ASSERT_EQ(17U, Toks.size());
 
   ASSERT_EQ(tok::text, Toks[0].getKind());
   ASSERT_EQ(StringRef(" "),Toks[0].getText());
@@ -879,7 +879,19 @@
   ASSERT_EQ(tok::verbatim_block_end,   Toks[11].getKind());
   ASSERT_EQ(StringRef("f}"),   getVerbatimBlockName(Toks[11]));
 
-  ASSERT_EQ(tok::newline,  Toks[12].getKind());
+  ASSERT_EQ(tok::text, Toks[12].getKind());
+  ASSERT_EQ(StringRef(" "),Toks[12].getText());
+
+  ASSERT_EQ(tok::verbatim_block_begin, Toks[13].getKind());
+  ASSERT_EQ(StringRef("f("),   getVerbatimBlockName(Toks[13]));
+
+  ASSERT_EQ(tok::verbatim_block_line,  Toks[14].getKind());
+  ASSERT_EQ(StringRef(" Ddd "),Toks[14].getVerbatimBlockText());
+
+  ASSERT_EQ(tok::verbatim_block_end,   Toks[15].getKind());
+  ASSERT_EQ(StringRef("f)"),   getVerbatimBlockName(Toks[15]));
+
+  ASSERT_EQ(tok::newline,  Toks[16].getKind());
 }
 
 // Empty verbatim line.
Index: clang/test/Index/comment-lots-of-unknown-commands.c
===
--- clang/test/Index/comment-lots-of-unknown-commands.c
+++ clang/test/Index/comment-lots-of-unknown-commands.c
@@ -39,7 +39,7 @@
 @ien
 @fr
 @en
-@tet
+@teq
 @le
 @L
 @os
@@ -77,7 +77,7 @@
 @rU
 @ar
 @eD
-@iE
+@iEx
 @se
 @st1
 @rr
@@ -106,7 +106,7 @@
 @hd
 @be
 @It
-@id
+@idz
 @cm
 @ua
 @fs
@@ -114,7 +114,7 @@
 @axn
 @rt
 @to
-@is
+@isj
 @fo
 @i
 @an
@@ -185,7 +185,7 @@
 // CHECK: (CXComment_InlineCommand CommandName=[ien] RenderNormal HasTrailingNewline)
 // CHECK: (CXComment_InlineCommand CommandName=[fr] RenderNormal HasTrailingNewline)
 // CHECK: (CXComment_InlineCommand CommandName=[en] RenderNormal HasTrailingNewline)
-// CHECK: (CXComment_InlineCommand CommandName=[tet] RenderNormal HasTrailingNewline)
+// CHECK: (CXComment_InlineCommand CommandName=[teq] RenderNormal HasTrailingNewline)
 // CHECK: (CXComment_InlineCommand CommandName=[le] RenderNormal HasTrailingNewline)
 // CHECK: (CXComment_InlineCommand CommandName=[L] RenderNormal HasTrailingNewline)
 // CHECK: (CXComment_InlineCommand CommandName=[os] RenderNormal HasTrailingNewline)
@@ -223,7 +223,7 @@
 // CHECK: (CXComment_InlineCommand CommandName=[rU] RenderNormal HasTrailingNewline)
 // CHECK: (CXComment_InlineCommand CommandName=[ar] RenderNormal HasTrailingNewline)
 // CHECK: (CXComment_InlineCommand CommandName=[eD] RenderNormal HasTrailingNewline)
-// CHECK: (CXComment_InlineCommand CommandName=[iE] RenderNormal HasTrailingNewline)
+// CHECK: (CXComment_InlineCommand CommandName=[iEx] RenderNormal HasTrailingNewline)
 // CHECK: (CXComment_InlineCommand CommandName=[se] RenderNormal HasTrailingNewline)
 // CHECK: (CXComment_InlineCommand CommandName=[st1] RenderNormal HasTrailingNewline)
 // CHECK: (CXComment_InlineCommand CommandName=[rr] RenderNormal HasTrailingNewline)
@@ -252,7 +252,7 @@
 // CHECK: (CXComment_InlineCommand CommandName=[hd] RenderNormal HasTrailingNewline)
 // CHECK: (CXComment_InlineCommand CommandName=[be] RenderNormal HasTrailingNewline)
 // CHECK:   

[PATCH] D113391: [Modules] Don't support clang module and c++20 module at the same time

[Michael Spencer via Phabricator via cfe-commits]

Bigcheese added inline comments.



Comment at: clang/test/ClangScanDeps/Inputs/header-search-pruning/cdb.json:3
+  "directory" : "DIR",
+  "command" : "clang -E DIR/header-search-pruning.cpp -Ibegin -I1 -Ia -I3 -I4 
-I5 -I6 -Ib -I8 -Iend DEFINES -fmodules -fmodules-cache-path=DIR/module-cache 
-fimplicit-modules -fmodule-map-file=DIR/module.modulemap",
+  "file" : "DIR/header-search-pruning.cpp"

dblaikie wrote:
> aaron.ballman wrote:
> > jansvoboda11 wrote:
> > > ChuanqiXu wrote:
> > > > jansvoboda11 wrote:
> > > > > ChuanqiXu wrote:
> > > > > > jansvoboda11 wrote:
> > > > > > > Can you explain why `-fcxx-modules` is removed? We want to 
> > > > > > > explicitly enable Clang modules for C++ inputs here. That's off 
> > > > > > > by default in our downstream repo and we'd like to keep this 
> > > > > > > upstream to prevent conflicts. (it's benign upstream)
> > > > > > According to the discussion in the link, I think it is in consensus 
> > > > > > that we decide to not support clang modules and c++20 modules at 
> > > > > > the same time. (I know many people may not have visited it. If any 
> > > > > > one disagree with the higher idea, I think it would be better to 
> > > > > > reply in that thread). 
> > > > > > So the original test case would fail.
> > > > > > 
> > > > > > > We want to explicitly enable Clang modules for C++ inputs here. 
> > > > > > 
> > > > > > I am not sure if I missed any thing. Personally, it looks like the 
> > > > > > test now would test clang modules for c++ inputs. Since it has 
> > > > > > `-fmodule` option so that clang module is enabled and the input is 
> > > > > > C++ (from its suffix). Do I misunderstand you?
> > > > > > According to the discussion in the link, I think it is in consensus 
> > > > > > that we decide to not support clang modules and c++20 modules at 
> > > > > > the same time. (I know many people may not have visited it. If any 
> > > > > > one disagree with the higher idea, I think it would be better to 
> > > > > > reply in that thread). 
> > > > > > So the original test case would fail.
> > > > > 
> > > > > What's the error message? As I say, we're enabling Clang modules for 
> > > > > C++ input here, not C++20 modules.
> > > > > 
> > > > > > > We want to explicitly enable Clang modules for C++ inputs here. 
> > > > > > 
> > > > > > I am not sure if I missed any thing. Personally, it looks like the 
> > > > > > test now would test clang modules for c++ inputs. Since it has 
> > > > > > `-fmodule` option so that clang module is enabled and the input is 
> > > > > > C++ (from its suffix). Do I misunderstand you?
> > > > > 
> > > > > Right. What I'm saying is that in our downstream repo, `-fmodules` is 
> > > > > not enough to enable Clang modules for C++ inputs, you need to do it 
> > > > > via `-fcxx-modules`. And we'd like to keep it upstream, even though 
> > > > > it's benign here, to avoid conflicts between the repos.
> > > > > What's the error message? As I say, we're enabling Clang modules for 
> > > > > C++ input here, not C++20 modules.
> > > > 
> > > > The error message is added in this patch. After this patch landed, the 
> > > > original intentional behavior would be `-fmodules` to enable clang 
> > > > module and `-fcxx-modules` to enable C++20 modules.
> > > > 
> > > > > Right. What I'm saying is that in our downstream repo, -fmodules is 
> > > > > not enough to enable Clang modules for C++ inputs, you need to do it 
> > > > > via -fcxx-modules. And we'd like to keep it upstream, even though 
> > > > > it's benign here, to avoid conflicts between the repos.
> > > > 
> > > > Got it. But it conflicts with the idea that disable clang module and 
> > > > c++20 module at the same time. Personally, I think it would be better 
> > > > to edit the code in downstream. @aaron.ballman sorry if I ping you too 
> > > > frequently. But I think now we need input from you.
> > > Ah, I understand now, thanks for explaining.
> > > 
> > > I'm worried about changing the behavior of a driver flag, we generally 
> > > don't break existing driver options. Have you considered keeping the 
> > > `-fmodules` and `-fcxx-modules` semantics intact and instead add new 
> > > `-fno-c++20-modules` flag or something like that?
> > > I'm worried about changing the behavior of a driver flag, we generally 
> > > don't break existing driver options. Have you considered keeping the 
> > > -fmodules and -fcxx-modules semantics intact and instead add new 
> > > -fno-c++20-modules flag or something like that?
> > 
> > The goal is not "let users disable C++20 modules", it's "ensure the user 
> > cannot enable two different kinds of modules at the same time". What I 
> > think we want to avoid is "C++20 mode, but with Clang modules instead of 
> > standard modules" or "C++20 mode, but with both clang and standard 
> > modules", etc. I think the support matrix that makes sense to me is:
> > 
> > C++20 mode: you get standard modules, no other module sch

[PATCH] D110927: [analyzer] Access stored value of a constant array through a pointer to another type

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov added a comment.

In D110927#3117728 , @steakhal wrote:

> For testing this I would recommend using a separate test file.
> That being said, you should avoid globals even in tests when you can. The 
> distance between its declaration and use just makes it harder to comprehend 
> and reason about.

I'll add a new tests file.

> You could have a parameter, and take its address to accomplish your 
> reinterpret casts and type puns.

Do you mean:

  void foo(signed char * ptr) {
ptr = (signed char *)glob_arr2;
  }

instead of

  void foo() {
auto *ptr = (signed char *)glob_arr2;
  }

?
If so, IMO it doesn't matter.

> BTW your patch crashes on the test suite:
> `initialization.cpp:242`:

I caught it. Thanks! I wonder how it slipped through unnoticed.




Comment at: clang/lib/StaticAnalyzer/Core/RegionStore.cpp:1661
+/// E.g. for `const int[1][2][3];` returns `int`.
+QualType getConstantArrayRootElement(const ConstantArrayType *CAT) {
+  assert(CAT && "ConstantArrayType should not be null");

steakhal wrote:
> Maybe //unwrapConstantArrayTypes()//?
I think about //getConstantArrayRoot**Type**//. IMO such name distinctly tells 
its intention and purpose.



Comment at: clang/lib/StaticAnalyzer/Core/RegionStore.cpp:1790
+  // paper P1839R0 be considered by the committee.
+  if ((Index != 0))
+return false;

steakhal wrote:
> Even though you are technically correct, how can you know that the pointer 
> you try to dereference actually points to the beginning of the object?
> Consider something like this:
> 
> ```lang=C++
> void callback(void *payload) {
>   // lets skip the first char object...
>   int *num = (int*)((char*)payload + 1);
>   clang_analyzer_dump(num); // Element{Element{SymRegion{payload}, 1, char}, 
> 0, int}
> }
> ```
>  how can you know that the pointer you try to dereference actually points to 
> the beginning of the object?
We look at the offset of the region. In your example it is //1//. And it is UB. 
Unfortinatelly the Standard forbids to do such accesses due to the different 
strict access rules. I recommend this talk https://youtu.be/_qzMpk-22cc . I 
took inspiration from there.



Comment at: clang/test/Analysis/initialization.cpp:295-299
+void glob_cast_opposite_sign1() {
+  auto *ptr = (unsigned int *)glob_arr2;
+  auto x1 = ptr[0]; // no-warning
+  auto x2 = ptr[1]; // expected-warning{{garbage or undefined}}
+}

steakhal wrote:
> I think it's not correct.
> 
> `glob_arr2` refers to an object of dynamic type `int[2]`.
> And the pointer decayed from it is `int *`, which has //similar type// to 
> `unsigned *` what you are using to access the memory.
> Since they are //similar//, this operation should work for all the valid 
> indices, thus `ptr[0]`, `ptr[1]`, `ptr[2]`, `ptr[3]` should all be valid.
> 
> 
> glob_arr2 refers to an object of dynamic type int[2].
`glob_arr2` has an extent of 4.
> And the pointer decayed from it is int *, which has similar type to unsigned 
> * what you are using to access the memory.
Yes, they are the same and it perfectly suits to 
http://eel.is/c++draft/basic.lval#11 . But still you can't access other element 
then the first one according to http://eel.is/c++draft/basic.compound#3 : //For 
purposes of pointer arithmetic ([expr.add]) and comparison ([expr.rel], 
[expr.eq]), [...] an object of type T that is not an array element is 
considered to belong to an array with one element of type T. //
`unsigned int` and `int` are different types according to 
http://eel.is/c++draft/basic.fundamental#2 . The object of type `unsigned int` 
is NOT an array, beacuse there is no array of type `unsigned int`. Hence you 
can only only access the first and a single element of type `unsigned int`.




Comment at: clang/test/Analysis/initialization.cpp:311-314
+void glob_cast_invalid3() {
+  auto *ptr = (char32_t *)glob_arr2;
+  auto x = ptr[0]; // expected-warning{{garbage or undefined}}
+}

steakhal wrote:
> Please also try `char8_t`.
Correct. We should check it. It should be a different type as well 
(http://eel.is/c++draft/basic.fundamental#9).


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

https://reviews.llvm.org/D110927

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

[PATCH] D113455: [clang][objc][codegen] Skip emitting ObjC category metadata when the category is empty

[Josh Learn via Phabricator via cfe-commits]

guitard0g updated this revision to Diff 385870.
guitard0g added a comment.

Fixed code formatting.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113455

Files:
  clang/lib/CodeGen/CGObjCMac.cpp
  clang/test/CodeGenObjC/category-class-empty.m
  clang/test/CodeGenObjC/non-lazy-classes.m

Index: clang/test/CodeGenObjC/non-lazy-classes.m
===
--- clang/test/CodeGenObjC/non-lazy-classes.m
+++ clang/test/CodeGenObjC/non-lazy-classes.m
@@ -42,4 +42,7 @@
 @implementation E @end
 
 __attribute__((objc_nonlazy_class))
-@implementation E (MyCat) @end
+@implementation E (MyCat)
+-(void) load {
+}
+@end
Index: clang/test/CodeGenObjC/category-class-empty.m
===
--- /dev/null
+++ clang/test/CodeGenObjC/category-class-empty.m
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -triple i386-apple-darwin9 -O3 -emit-llvm -o - %s | FileCheck %s
+// PR7431
+
+// CHECK-NOT: @"_OBJC_$_CATEGORY_A_$_foo" = internal global %struct._category_t
+
+@interface A
+@end
+__attribute__((objc_direct_members))
+@interface A(foo)
+- (void)foo_myStuff;
+@end
+@implementation A(foo)
+- (void)foo_myStuff {
+}
+@end
+
Index: clang/lib/CodeGen/CGObjCMac.cpp
===
--- clang/lib/CodeGen/CGObjCMac.cpp
+++ clang/lib/CodeGen/CGObjCMac.cpp
@@ -6659,6 +6659,8 @@
   values.add(GetClassGlobal(Interface, /*metaclass*/ false, NotForDefinition));
   std::string listName =
   (Interface->getObjCRuntimeNameAsString() + "_$_" + OCD->getName()).str();
+  // Keep track of whether we have actual metadata to emit.
+  bool isEmptyCategory = true;
 
   SmallVector instanceMethods;
   SmallVector classMethods;
@@ -6672,46 +6674,61 @@
 }
   }
 
-  values.add(emitMethodList(listName, MethodListType::CategoryInstanceMethods,
-instanceMethods));
-  values.add(emitMethodList(listName, MethodListType::CategoryClassMethods,
-classMethods));
+  auto instanceMethodList = emitMethodList(
+  listName, MethodListType::CategoryInstanceMethods, instanceMethods);
+  auto classMethodList = emitMethodList(
+  listName, MethodListType::CategoryClassMethods, classMethods);
+  values.add(instanceMethodList);
+  values.add(classMethodList);
+  isEmptyCategory &=
+  instanceMethodList->isNullValue() && classMethodList->isNullValue();
 
   const ObjCCategoryDecl *Category =
-Interface->FindCategoryDeclaration(OCD->getIdentifier());
+  Interface->FindCategoryDeclaration(OCD->getIdentifier());
   if (Category) {
 SmallString<256> ExtName;
-llvm::raw_svector_ostream(ExtName) << Interface->getObjCRuntimeNameAsString() << "_$_"
-   << OCD->getName();
-values.add(EmitProtocolList("_OBJC_CATEGORY_PROTOCOLS_$_"
-   + Interface->getObjCRuntimeNameAsString() + "_$_"
-   + Category->getName(),
-Category->protocol_begin(),
-Category->protocol_end()));
-values.add(EmitPropertyList("_OBJC_$_PROP_LIST_" + ExtName.str(),
-OCD, Category, ObjCTypes, false));
-values.add(EmitPropertyList("_OBJC_$_CLASS_PROP_LIST_" + ExtName.str(),
-OCD, Category, ObjCTypes, true));
+llvm::raw_svector_ostream(ExtName)
+<< Interface->getObjCRuntimeNameAsString() << "_$_" << OCD->getName();
+auto protocolList =
+EmitProtocolList("_OBJC_CATEGORY_PROTOCOLS_$_" +
+ Interface->getObjCRuntimeNameAsString() + "_$_" +
+ Category->getName(),
+ Category->protocol_begin(), Category->protocol_end());
+auto propertyList = EmitPropertyList("_OBJC_$_PROP_LIST_" + ExtName.str(),
+ OCD, Category, ObjCTypes, false);
+auto classPropertyList =
+EmitPropertyList("_OBJC_$_CLASS_PROP_LIST_" + ExtName.str(), OCD,
+ Category, ObjCTypes, true);
+values.add(protocolList);
+values.add(propertyList);
+values.add(classPropertyList);
+isEmptyCategory &= protocolList->isNullValue() &&
+   propertyList->isNullValue() &&
+   classPropertyList->isNullValue();
   } else {
 values.addNullPointer(ObjCTypes.ProtocolListnfABIPtrTy);
 values.addNullPointer(ObjCTypes.PropertyListPtrTy);
 values.addNullPointer(ObjCTypes.PropertyListPtrTy);
   }
 
-  unsigned Size = CGM.getDataLayout().getTypeAllocSize(ObjCTypes.CategorynfABITy);
+  unsigned Size =
+  CGM.getDataLayout().getTypeAllocSize(ObjCTypes.CategorynfABITy);
   values.addInt(ObjCTypes.IntTy, Size);
 
   llvm::GlobalVariable *GCATV =
   finishAndCreateGlobal(values, ExtCatName.s

[PATCH] D55067: [HIP] Fix offset of kernel argument for AMDGPU target

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl abandoned this revision.
yaxunl added a comment.

this is no longer needed


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

https://reviews.llvm.org/D55067

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

[PATCH] D98895: [X86][clang] Disable long double type for -mno-x87 option

[Andrew Savonichev via Phabricator via cfe-commits]

asavonic added a comment.

In D98895#3118821 , @eandrews wrote:

> This patch causes a regression.
>
> To reproduce - `clang -cc1 -fsycl-is-device -triple spir64 test.cpp`
>
>   test.cpp:x:3: error: 'bar<__float128>' requires 128 bit size '__float128' 
> type support, but target 'spir64' does not support it
>   T bar() { return T(); };
> ^
>
> I looked at it briefly, and I believe the issue is call to 
> `checkTypeSupport()` in `ActOnFinishFunctionBody()`. I tried deleting the 
> call but it breaks tests (E.g. L26 in x86_64-no-x87.cpp). @asavonic Please 
> take a look. I will be reverting the patch if this cannot be fixed soon.

The diagnostic seems to be correct - this instance of `bar` returns an 
unsupported type. Why do you think it should not be diagnosed?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98895

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

[PATCH] D112914: Misleading identifier detection

[Aaron Puchert via Phabricator via cfe-commits]

aaronpuchert added inline comments.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/misc-misleading-identifier.rst:12
+
+.. code-block:: c
+

Sphinx can't parse that (perhaps unsurprisingly), could you declare that as 
having no language?

```
Warning, treated as error:
/home/buildbot/llvm-build-dir/clang-tools-sphinx-docs/llvm/src/clang-tools-extra/docs/clang-tidy/checks/misc-misleading-identifier.rst:12:Could
 not lex literal_block as "c". Highlighting skipped.
```

Should be reproducible by building `docs-clang-tools-html` (might need `-j1`).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112914

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

[PATCH] D98895: [X86][clang] Disable long double type for -mno-x87 option

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

In D98895#3119027 , @asavonic wrote:

> In D98895#3118821 , @eandrews wrote:
>
>> This patch causes a regression.
>>
>> To reproduce - `clang -cc1 -fsycl-is-device -triple spir64 test.cpp`
>>
>>   test.cpp:x:3: error: 'bar<__float128>' requires 128 bit size '__float128' 
>> type support, but target 'spir64' does not support it
>>   T bar() { return T(); };
>> ^
>>
>> I looked at it briefly, and I believe the issue is call to 
>> `checkTypeSupport()` in `ActOnFinishFunctionBody()`. I tried deleting the 
>> call but it breaks tests (E.g. L26 in x86_64-no-x87.cpp). @asavonic Please 
>> take a look. I will be reverting the patch if this cannot be fixed soon.
>
> The diagnostic seems to be correct - this instance of `bar` returns an 
> unsupported type. Why do you think it should not be diagnosed?

I believe the problem is that there are now _3_ different diagnostics for the 
same thing, the one on 'bar', plus 2 more here:

`auto malAutoTemp5 = bar<__float128>();`

I think i would expect 1 error on 'bar', 1 error on the deduced 'auto', but the 
3rd is superfluous.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98895

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

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

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

LGTM. It seems all concerns have been addressed. Shall we move ahead and land 
this patch? Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110257

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

[PATCH] D112914: Misleading identifier detection

[serge via Phabricator via cfe-commits]

serge-sans-paille added a comment.

Yep, I'm currently validating locally, I somehow messed up a rebase :-/


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112914

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

[PATCH] D98895: [X86][clang] Disable long double type for -mno-x87 option

[Andrew Savonichev via Phabricator via cfe-commits]

asavonic added a comment.

In D98895#3119064 , @erichkeane wrote:

> In D98895#3119027 , @asavonic wrote:
>
>> In D98895#3118821 , @eandrews wrote:
>>
>>> This patch causes a regression.
>>>
>>> To reproduce - `clang -cc1 -fsycl-is-device -triple spir64 test.cpp`
>>>
>>>   test.cpp:x:3: error: 'bar<__float128>' requires 128 bit size '__float128' 
>>> type support, but target 'spir64' does not support it
>>>   T bar() { return T(); };
>>> ^
>>>
>>> I looked at it briefly, and I believe the issue is call to 
>>> `checkTypeSupport()` in `ActOnFinishFunctionBody()`. I tried deleting the 
>>> call but it breaks tests (E.g. L26 in x86_64-no-x87.cpp). @asavonic Please 
>>> take a look. I will be reverting the patch if this cannot be fixed soon.
>>
>> The diagnostic seems to be correct - this instance of `bar` returns an 
>> unsupported type. Why do you think it should not be diagnosed?
>
> I believe the problem is that there are now _3_ different diagnostics for the 
> same thing, the one on 'bar', plus 2 more here:
>
> `auto malAutoTemp5 = bar<__float128>();`
>
> I think i would expect 1 error on 'bar', 1 error on the deduced 'auto', but 
> the 3rd is superfluous.

I will check if there is a way to filter it out. However, I don't think that it 
is a good reason to revert the patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98895

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

[PATCH] D98895: [X86][clang] Disable long double type for -mno-x87 option

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

In D98895#3119104 , @asavonic wrote:

> In D98895#3119064 , @erichkeane 
> wrote:
>
>> In D98895#3119027 , @asavonic wrote:
>>
>>> In D98895#3118821 , @eandrews 
>>> wrote:
>>>
 This patch causes a regression.

 To reproduce - `clang -cc1 -fsycl-is-device -triple spir64 test.cpp`

   test.cpp:x:3: error: 'bar<__float128>' requires 128 bit size 
 '__float128' type support, but target 'spir64' does not support it
   T bar() { return T(); };
 ^

 I looked at it briefly, and I believe the issue is call to 
 `checkTypeSupport()` in `ActOnFinishFunctionBody()`. I tried deleting the 
 call but it breaks tests (E.g. L26 in x86_64-no-x87.cpp). @asavonic Please 
 take a look. I will be reverting the patch if this cannot be fixed soon.
>>>
>>> The diagnostic seems to be correct - this instance of `bar` returns an 
>>> unsupported type. Why do you think it should not be diagnosed?
>>
>> I believe the problem is that there are now _3_ different diagnostics for 
>> the same thing, the one on 'bar', plus 2 more here:
>>
>> `auto malAutoTemp5 = bar<__float128>();`
>>
>> I think i would expect 1 error on 'bar', 1 error on the deduced 'auto', but 
>> the 3rd is superfluous.
>
> I will check if there is a way to filter it out. However, I don't think that 
> it is a good reason to revert the patch.

This a pretty significant regression in our downstream, which is typically more 
than enough to get a revert.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98895

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