[PATCH] D133634: [clang] Allow vector of BitInt

2022-09-09 Thread Xiang Li via Phabricator via cfe-commits
python3kgae created this revision.
python3kgae added reviewers: beanz, pow2clk, Anastasia, aaron.ballman, bogner.
Herald added a project: All.
python3kgae requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Remove check which disable BitInt as element type for ext_vector.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133634

Files:
  clang/lib/AST/ASTContext.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/Sema/builtin-classify-type.c


Index: clang/test/Sema/builtin-classify-type.c
===
--- clang/test/Sema/builtin-classify-type.c
+++ clang/test/Sema/builtin-classify-type.c
@@ -29,6 +29,8 @@
   __attribute__((vector_size(16))) int vec;
   typedef __attribute__((ext_vector_type(4))) int evec_t;
   evec_t evec;
+  typedef _BitInt(16) int16_t3 __attribute__((ext_vector_type(3)));
+  int16_t3 t3;
   _Atomic int atomic_i;
   _Atomic double atomic_d;
   _Complex int complex_i;
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -2707,7 +2707,7 @@
   // We explictly allow bool elements in ext_vector_type for C/C++.
   bool IsNoBoolVecLang = getLangOpts().OpenCL || getLangOpts().OpenCLCPlusPlus;
   if ((!T->isDependentType() && !T->isIntegerType() &&
-   !T->isRealFloatingType()) || T->isBitIntType() ||
+   !T->isRealFloatingType()) ||
   (IsNoBoolVecLang && T->isBooleanType())) {
 Diag(AttrLoc, diag::err_attribute_invalid_vector_type) << T;
 return QualType();
Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -4080,9 +4080,10 @@
 
 /// getExtVectorType - Return the unique reference to an extended vector type 
of
 /// the specified element type and size. VectorType must be a built-in type.
-QualType
-ASTContext::getExtVectorType(QualType vecType, unsigned NumElts) const {
-  assert(vecType->isBuiltinType() || vecType->isDependentType());
+QualType ASTContext::getExtVectorType(QualType vecType,
+  unsigned NumElts) const {
+  assert(vecType->isBuiltinType() || vecType->isDependentType() ||
+ vecType->isBitIntType());
 
   // Check if we've already instantiated a vector of this type.
   llvm::FoldingSetNodeID ID;


Index: clang/test/Sema/builtin-classify-type.c
===
--- clang/test/Sema/builtin-classify-type.c
+++ clang/test/Sema/builtin-classify-type.c
@@ -29,6 +29,8 @@
   __attribute__((vector_size(16))) int vec;
   typedef __attribute__((ext_vector_type(4))) int evec_t;
   evec_t evec;
+  typedef _BitInt(16) int16_t3 __attribute__((ext_vector_type(3)));
+  int16_t3 t3;
   _Atomic int atomic_i;
   _Atomic double atomic_d;
   _Complex int complex_i;
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -2707,7 +2707,7 @@
   // We explictly allow bool elements in ext_vector_type for C/C++.
   bool IsNoBoolVecLang = getLangOpts().OpenCL || getLangOpts().OpenCLCPlusPlus;
   if ((!T->isDependentType() && !T->isIntegerType() &&
-   !T->isRealFloatingType()) || T->isBitIntType() ||
+   !T->isRealFloatingType()) ||
   (IsNoBoolVecLang && T->isBooleanType())) {
 Diag(AttrLoc, diag::err_attribute_invalid_vector_type) << T;
 return QualType();
Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -4080,9 +4080,10 @@
 
 /// getExtVectorType - Return the unique reference to an extended vector type of
 /// the specified element type and size. VectorType must be a built-in type.
-QualType
-ASTContext::getExtVectorType(QualType vecType, unsigned NumElts) const {
-  assert(vecType->isBuiltinType() || vecType->isDependentType());
+QualType ASTContext::getExtVectorType(QualType vecType,
+  unsigned NumElts) const {
+  assert(vecType->isBuiltinType() || vecType->isDependentType() ||
+ vecType->isBitIntType());
 
   // Check if we've already instantiated a vector of this type.
   llvm::FoldingSetNodeID ID;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D133633: [CMake] Add ClangBootstrap configuration

2022-09-09 Thread Amir Ayupov via Phabricator via cfe-commits
Amir created this revision.
Amir added reviewers: phosek, MaskRay.
Herald added subscribers: StephenFan, mgorny.
Herald added a reviewer: alexander-shaposhnikov.
Herald added a project: All.
Amir requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Factor out the common parts of Clang bootstrap configuration into a separate
CMake module.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133633

Files:
  clang/CMakeLists.txt
  clang/cmake/modules/ClangBootstrap.cmake

Index: clang/cmake/modules/ClangBootstrap.cmake
===
--- /dev/null
+++ clang/cmake/modules/ClangBootstrap.cmake
@@ -0,0 +1,54 @@
+include(ExternalProject)
+
+# clang_Bootstrap_Add(name ...
+#   DEPENDS targets...
+# Targets that this project depends on
+#   TABLEGEN
+#   LINKER
+#   AR
+#   RANLIB
+#   OBJCOPY
+#   STRIP
+# Toolchain binaries
+#   CMAKE_ARGS arguments...
+# Optional cmake arguments to pass when configuring the project
+#   BUILD_TOOL_ARGS arguments...
+# Optional arguments to pass to the build tool
+macro(clang_Bootstrap_Add name)
+  cmake_parse_arguments(ARG "" "LINKER;AR;RANLIB;OBJCOPY;STRIP"
+"DEPENDS;TABLEGEN;CMAKE_ARGS;BUILD_TOOL_ARGS"
+${ARGN})
+  set(STAMP_DIR ${CMAKE_CURRENT_BINARY_DIR}/${name}-stamps/)
+  set(BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR}/${name}-bins/)
+  # Build arguments for native tool used in CMake.
+  set(build_configuration "$")
+
+  ExternalProject_Add(${name}
+DEPENDS ${ARG_DEPENDS}
+PREFIX ${name}
+SOURCE_DIR ${CMAKE_SOURCE_DIR}
+STAMP_DIR ${STAMP_DIR}
+BINARY_DIR ${BINARY_DIR}
+EXCLUDE_FROM_ALL 1
+CMAKE_ARGS
+${ARG_TABLEGEN}
+${ARG_LINKER}
+${ARG_AR}
+${ARG_RANLIB}
+${ARG_OBJCOPY}
+${ARG_STRIP}
+# We shouldn't need to set this here, but INSTALL_DIR doesn't
+# seem to work, so instead I'm passing this through
+-DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}
+${ARG_CMAKE_ARGS}
+BUILD_COMMAND ${CMAKE_COMMAND} --build ${BINARY_DIR}
+   --config ${build_configuration}
+   ${ARG_BUILD_TOOL_ARGS}
+INSTALL_COMMAND ""
+STEP_TARGETS configure build
+USES_TERMINAL_CONFIGURE 1
+USES_TERMINAL_BUILD 1
+USES_TERMINAL_INSTALL 1
+LIST_SEPARATOR |
+  )
+endmacro()
Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -797,45 +797,29 @@
   endforeach()
 
   # Build arguments for native tool used in CMake.
-  set(build_configuration "$")
   set(build_tool_args "${LLVM_EXTERNAL_PROJECT_BUILD_TOOL_ARGS}")
   if(NOT build_tool_args STREQUAL "")
 string(PREPEND build_tool_args "-- ")
 separate_arguments(build_tool_args UNIX_COMMAND "${build_tool_args}")
   endif()
 
-  ExternalProject_Add(${NEXT_CLANG_STAGE}
+  include(ClangBootstrap)
+  clang_Bootstrap_Add(${NEXT_CLANG_STAGE}
 DEPENDS clang-bootstrap-deps
-PREFIX ${NEXT_CLANG_STAGE}
-SOURCE_DIR ${CMAKE_SOURCE_DIR}
-STAMP_DIR ${STAMP_DIR}
-BINARY_DIR ${BINARY_DIR}
-EXCLUDE_FROM_ALL 1
+TABLEGEN ${${CLANG_STAGE}_TABLEGEN}
+LINKER   ${${CLANG_STAGE}_LINKER}
+AR   ${${CLANG_STAGE}_AR}
+RANLIB   ${${CLANG_STAGE}_RANLIB}
+OBJCOPY  ${${CLANG_STAGE}_OBJCOPY}
+STRIP${${CLANG_STAGE}_STRIP}
 CMAKE_ARGS
-# We shouldn't need to set this here, but INSTALL_DIR doesn't
-# seem to work, so instead I'm passing this through
--DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}
 ${PASSTHROUGH_VARIABLES}
 ${CLANG_BOOTSTRAP_CMAKE_ARGS}
  -DCLANG_STAGE=${NEXT_CLANG_STAGE}
 ${COMPILER_OPTIONS}
-${${CLANG_STAGE}_TABLEGEN}
 ${LTO_LIBRARY} ${verbose} ${PGO_OPT}
-${${CLANG_STAGE}_LINKER}
-${${CLANG_STAGE}_AR}
-${${CLANG_STAGE}_RANLIB}
-${${CLANG_STAGE}_OBJCOPY}
-${${CLANG_STAGE}_STRIP}
-BUILD_COMMAND ${CMAKE_COMMAND} --build ${BINARY_DIR}
-   --config ${build_configuration}
-   ${build_tool_args}
-INSTALL_COMMAND ""
-STEP_TARGETS configure build
-USES_TERMINAL_CONFIGURE 1
-USES_TERMINAL_BUILD 1
-USES_TERMINAL_INSTALL 1
-LIST_SEPARATOR |
-)
+BUILD_TOOL_ARGS ${build_tool_args}
+  )
 
   # exclude really-install from main target
   set_target_properties(${NEXT_CLANG_STAGE} PROPERTIES _EP_really-install_EXCLUDE_FROM_MAIN On)
@@ -916,36 +900,31 @@
   )
 
   # Build specified targets with instrumented Clang to collect the profile
-  set(STAMP_DIR 

[PATCH] D86049: RFC: Implement optional exportable wrapper function generation for objc_direct methods.

2022-09-09 Thread Puyan Lotfi via Phabricator via cfe-commits
plotfi added inline comments.



Comment at: clang/include/clang/Basic/Attr.td:2251-2256
+def ObjCDirectVisible : Attr {
+  let Spellings = [Clang<"objc_direct_visible">];
+  let Subjects = SubjectList<[ObjCMethod], ErrorDiag>;
+  let LangOpts = [ObjC];
+  let Documentation = [ObjCDirectVisibleDocs];
+}

mwyman wrote:
> Should this inherit `ObjCDirect`, to include both objc_direct and the 
> visibility aspect? I don't see any reason we would want to add 
> `objc_direct_visible` without also having `objc_direct`, so why make 
> developers add both?
> 
> As an alternative, would it make sense to allow adding 
> `__attribute__((visibility("default")))` on direct methods?
> 
> Also, it doesn't seem like this allows making `@property`s visible, so should 
> there be a similar attribute for properties?
I'd prefer to do `@property`s in a separate commit, but I suppose you are 
thinking like a `objc_direct_members_visible` attribute? I think I can add that 
in a subsequent commit. 

I took a look at how to make things inherit and I think the most 
straightforward way is to have `handleObjCDirectVisibleAttr` set the 
objc_direct attribute if it is not set already.

As for `__attribute__((visibility("default")))` I think the trouble lies in 
what we want the default visibility behavior for objc methods to be and if we 
want the behavior to be controlled by `-fvisibility=`. I tried going by 
attribute visibility before and had some trouble too (I forget exactly what 
though). 





Comment at: clang/lib/CodeGen/CGObjCMac.cpp:4025-4036
+  if (OMD->isDirectMethodVisible() && Fn->getName().str()[0] == '\1') {
+// Drop '\1' to work with dlsym.
+std::string Name = Fn->getName().str().substr(1);
+
+assert(Name[0] == '-' || Name[0] == '+');
+assert(Name[1] == '[' && Name[Name.length() - 1] == ']');
+

mwyman wrote:
> Should this move to clang/lib/AST/Mangle.cpp's mangleObjCMethodName?
I like this idea. I will look into doing it next.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86049

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


[PATCH] D86049: RFC: Implement optional exportable wrapper function generation for objc_direct methods.

2022-09-09 Thread Puyan Lotfi via Phabricator via cfe-commits
plotfi updated this revision to Diff 459257.
plotfi added a comment.

Updated with some of @mwyman's feedback.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86049

Files:
  clang/include/clang/AST/DeclObjC.h
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/lib/AST/DeclObjC.cpp
  clang/lib/CodeGen/CGObjC.cpp
  clang/lib/CodeGen/CGObjCMac.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/CodeGenObjC/objc-direct-wrapper.m

Index: clang/test/CodeGenObjC/objc-direct-wrapper.m
===
--- /dev/null
+++ clang/test/CodeGenObjC/objc-direct-wrapper.m
@@ -0,0 +1,50 @@
+// RUN: %clang -fobjc-arc -Wno-objc-root-class -ObjC -fobjc-runtime=ios -FFoundation \
+// RUN: -DENABLE_VISIBLE_OBJC_DIRECT=1 \
+// RUN: -target x86_64-apple-macosx10.15.0 -c -o - %s | \
+// RUN: llvm-nm - | FileCheck -check-prefix=CHECK-WRAPPER %s
+
+// RUN: %clang -fobjc-arc -Wno-objc-root-class \
+// RUN: -target x86_64-apple-macosx10.15.0 \
+// RUN: -ObjC -fobjc-runtime=ios -FFoundation -c -o - %s | llvm-nm - | \
+// RUN: FileCheck -check-prefix=CHECK-DEFAULT %s
+
+// RUN: %clang -fobjc-arc -Wno-objc-root-class \
+// RUN: -DENABLE_VISIBLE_OBJC_DIRECT=1 \
+// RUN: -target x86_64-apple-macosx10.15.0 \
+// RUN: -ObjC -fobjc-runtime=ios -FFoundation -c -o - %s -S -emit-llvm | \
+// RUN: FileCheck -check-prefix=CHECK-WRAPPER-IR-DEFINE %s
+
+// RUN: %clang -fobjc-arc -Wno-objc-root-class -DNO_OBJC_IMPL \
+// RUN: -DENABLE_VISIBLE_OBJC_DIRECT=1 \
+// RUN: -target x86_64-apple-macosx10.15.0 \
+// RUN: -ObjC -fobjc-runtime=ios -FFoundation -c -o - %s -S -emit-llvm | \
+// RUN: FileCheck -check-prefix=CHECK-WRAPPER-IR-DECLARE %s
+
+// CHECK-WRAPPER: T _-
+ // TODO: Fix this
+// CHECK-DEFAULT: t -[C testMethod:bar:]
+// CHECK-WRAPPER-IR-DEFINE: define {{(dso_local )?}}void @"-"
+// CHECK-WRAPPER-IR-DECLARE: declare {{(dso_local )?}}void @"-"
+
+#if ENABLE_VISIBLE_OBJC_DIRECT
+#define OBJC_DIRECT __attribute((objc_direct)) __attribute__((objc_direct_visible))
+#else
+#define OBJC_DIRECT
+#endif
+
+@interface C
+- (void)testMethod:(int)arg1 bar:(float)arg2 OBJC_DIRECT __attribute__((visibility("default"))) ;
+@end
+
+#ifndef NO_OBJC_IMPL
+@implementation C
+- (void)testMethod:(int)arg1 bar:(float)arg2 OBJC_DIRECT {
+}
+@end
+#endif
+
+C *c;
+
+__attribute__((visibility("hidden"))) void f() {
+  [c testMethod:1 bar:1.0];
+}
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -2943,6 +2943,22 @@
   }
 }
 
+static void handleObjCDirectVisibleAttr(Sema , Decl *D, const ParsedAttr ) {
+  // objc_direct cannot be set on methods declared in the context of a protocol
+  if (isa(D->getDeclContext())) {
+S.Diag(AL.getLoc(), diag::err_objc_direct_on_protocol) << false;
+return;
+  }
+
+  if (S.getLangOpts().ObjCRuntime.allowsDirectDispatch()) {
+if (!D->hasAttr())
+  handleSimpleAttribute(S, D, AL);
+handleSimpleAttribute(S, D, AL);
+  } else {
+S.Diag(AL.getLoc(), diag::warn_objc_direct_ignored) << AL;
+  }
+}
+
 static void handleObjCMethodFamilyAttr(Sema , Decl *D, const ParsedAttr ) {
   const auto *M = cast(D);
   if (!AL.isArgIdent(0)) {
@@ -8783,6 +8799,9 @@
   case ParsedAttr::AT_ObjCDirect:
 handleObjCDirectAttr(S, D, AL);
 break;
+  case ParsedAttr::AT_ObjCDirectVisible:
+handleObjCDirectVisibleAttr(S, D, AL);
+break;
   case ParsedAttr::AT_ObjCDirectMembers:
 handleObjCDirectMembersAttr(S, D, AL);
 handleSimpleAttribute(S, D, AL);
Index: clang/lib/CodeGen/CGObjCMac.cpp
===
--- clang/lib/CodeGen/CGObjCMac.cpp
+++ clang/lib/CodeGen/CGObjCMac.cpp
@@ -4021,6 +4021,20 @@
 DirectMethodDefinitions.insert(std::make_pair(COMD, Fn));
   }
 
+  // If we want to explicitly export objc_direct methods, we need a name fixup.
+  if (OMD->isDirectMethodVisible() && Fn->getName().str()[0] == '\1') {
+// Drop '\1' to work with dlsym.
+std::string Name = Fn->getName().str().substr(1);
+
+assert(Name[0] == '-' || Name[0] == '+');
+assert(Name[1] == '[' && Name[Name.length() - 1] == ']');
+
+// replace "[ ]" by  "< >" to avoid strip by ld64.
+Name = Name.substr(0, 1) + "<" + Name.substr(2, Name.length() - 3) + ">";
+
+Fn->setName(Name);
+  }
+
   return Fn;
 }
 
Index: clang/lib/CodeGen/CGObjC.cpp
===
--- clang/lib/CodeGen/CGObjC.cpp
+++ clang/lib/CodeGen/CGObjC.cpp
@@ -760,7 +760,9 @@
 
   const CGFunctionInfo  = CGM.getTypes().arrangeObjCMethodDeclaration(OMD);
   if (OMD->isDirectMethod()) {
-Fn->setVisibility(llvm::Function::HiddenVisibility);
+Fn->setVisibility(OMD->isDirectMethodVisible()
+  ? 

[PATCH] D133574: [C2x] reject type definitions in offsetof

2022-09-09 Thread YingChi Long via Phabricator via cfe-commits
inclyc updated this revision to Diff 459248.
inclyc added a comment.

Use RAII object to maintain the Parser state

> have you explored making a new DeclSpecContext and modifying 
> isDefiningTypeSpecifierContext()? I think that would likely be a cleaner 
> approach.

Emm, I've tried passing a DeclaratorContext into `ParseTypeName()`

  SourceLocation TypeLoc = Tok.getLocation();
  InBuiltInOffsetOfBaseRAIIObject InOffsetof(*this, true);
  TypeResult Ty = ParseTypeName(nullptr, /*Context=???*/); 

But defining a new DeclaratorContext I have to complete a bunch of `case`
statements.

  // Parser.h
  static bool isTypeSpecifier(DeclSpecContext DSC);
  static AllowDefiningTypeSpec isDefiningTypeSpecifierContext(DeclSpecContext 
DSC, bool IsCPlusPlus);
  static bool isOpaqueEnumDeclarationContext(DeclSpecContext DSC);
  /* ... */

And I think it is somehow strange to determine these properties within
__builtin_offsetof()? I'm not sure if it is really appropriate to define a
special context for a built-in function. This place should only need to
forbidden definitions, right?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133574

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Parse/Parser.h
  clang/include/clang/Parse/RAIIObjectsForParser.h
  clang/include/clang/Sema/Sema.h
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Parse/ParseExpr.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/test/Parser/declarators.c
  clang/test/Sema/offsetof.c

Index: clang/test/Sema/offsetof.c
===
--- clang/test/Sema/offsetof.c
+++ clang/test/Sema/offsetof.c
@@ -70,3 +70,16 @@
   return __builtin_offsetof(Array, array[*(int*)0]); // expected-warning{{indirection of non-volatile null pointer}} expected-note{{__builtin_trap}}
 }
 
+// Reject definitions in __builtin_offsetof
+// https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm
+int test_definition(void) {
+  return __builtin_offsetof(struct A // expected-error{{'struct A' cannot be defined in '__builtin_offsetof'}} 
+  { 
+int a;
+struct B // expected-error{{'struct B' cannot be defined in '__builtin_offsetof'}}
+{
+  int c;
+  int d;
+} x;
+  }, a);
+}
Index: clang/test/Parser/declarators.c
===
--- clang/test/Parser/declarators.c
+++ clang/test/Parser/declarators.c
@@ -80,10 +80,6 @@
 struct test10 { int a; } static test10x;
 struct test11 { int a; } const test11x;
 
-// PR6216
-void test12(void) {
-  (void)__builtin_offsetof(struct { char c; int i; }, i);
-}
 
 // rdar://7608537
 struct test13 { int a; } (test13x);
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -16254,7 +16254,7 @@
  SourceLocation ScopedEnumKWLoc,
  bool ScopedEnumUsesClassTag, TypeResult UnderlyingType,
  bool IsTypeSpecifier, bool IsTemplateParamOrArg,
- SkipBodyInfo *SkipBody) {
+ SkipBodyInfo *SkipBody, bool IsWithinOffsetOf) {
   // If this is not a definition, it must have a name.
   IdentifierInfo *OrigName = Name;
   assert((Name != nullptr || TUK == TUK_Definition) &&
@@ -17027,6 +17027,12 @@
cast_or_null(PrevDecl));
   }
 
+  if (IsWithinOffsetOf && TUK == TUK_Definition) {
+Diag(New->getLocation(), diag::err_type_defined_in_offsetof)
+<< Context.getTagDeclType(New);
+Invalid = true;
+  }
+
   // C++11 [dcl.type]p3:
   //   A type-specifier-seq shall not define a class or enumeration [...].
   if (getLangOpts().CPlusPlus && (IsTypeSpecifier || IsTemplateParamOrArg) &&
Index: clang/lib/Parse/ParseExpr.cpp
===
--- clang/lib/Parse/ParseExpr.cpp
+++ clang/lib/Parse/ParseExpr.cpp
@@ -2579,6 +2579,7 @@
   }
   case tok::kw___builtin_offsetof: {
 SourceLocation TypeLoc = Tok.getLocation();
+InBuiltInOffsetOfBaseRAIIObject InOffsetof(*this, true);
 TypeResult Ty = ParseTypeName();
 if (Ty.isInvalid()) {
   SkipUntil(tok::r_paren, StopAtSemi);
Index: clang/lib/Parse/ParseDeclCXX.cpp
===
--- clang/lib/Parse/ParseDeclCXX.cpp
+++ clang/lib/Parse/ParseDeclCXX.cpp
@@ -2030,7 +2030,7 @@
 DSC == DeclSpecContext::DSC_type_specifier,
 DSC == DeclSpecContext::DSC_template_param ||
 DSC == DeclSpecContext::DSC_template_type_arg,
-);
+, InBuiltInOffsetOfBase);
 
 // If ActOnTag said the type was dependent, try again with the
 // less common call.
Index: clang/include/clang/Sema/Sema.h
===
--- 

[PATCH] D133613: [clang][cmake] Remove extra brace

2022-09-09 Thread Mohammed Keyvanzadeh via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG467bb47c8418: [clang][cmake] Remove extra brace (authored by 
VoltrexMaster).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133613

Files:
  clang/cmake/modules/AddClang.cmake


Index: clang/cmake/modules/AddClang.cmake
===
--- clang/cmake/modules/AddClang.cmake
+++ clang/cmake/modules/AddClang.cmake
@@ -70,7 +70,7 @@
 ${CLANG_SOURCE_DIR}/include/clang/${lib_path}/*.td
   )
   source_group("TableGen descriptions" FILES ${tds})
-  set_source_files_properties(${tds}} PROPERTIES HEADER_FILE_ONLY ON)
+  set_source_files_properties(${tds} PROPERTIES HEADER_FILE_ONLY ON)
 
   if(headers OR tds)
 set(srcs ${headers} ${tds})


Index: clang/cmake/modules/AddClang.cmake
===
--- clang/cmake/modules/AddClang.cmake
+++ clang/cmake/modules/AddClang.cmake
@@ -70,7 +70,7 @@
 ${CLANG_SOURCE_DIR}/include/clang/${lib_path}/*.td
   )
   source_group("TableGen descriptions" FILES ${tds})
-  set_source_files_properties(${tds}} PROPERTIES HEADER_FILE_ONLY ON)
+  set_source_files_properties(${tds} PROPERTIES HEADER_FILE_ONLY ON)
 
   if(headers OR tds)
 set(srcs ${headers} ${tds})
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 467bb47 - [clang][cmake] Remove extra brace

2022-09-09 Thread Mohammed Keyvanzadeh via cfe-commits

Author: Mohammed Keyvanzadeh
Date: 2022-09-10T05:00:23+04:30
New Revision: 467bb47c841897450990f3ab82e79fec5f2d1f60

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

LOG: [clang][cmake] Remove extra brace

Remove the extra trailing brace from the local variable accessor.

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

Added: 


Modified: 
clang/cmake/modules/AddClang.cmake

Removed: 




diff  --git a/clang/cmake/modules/AddClang.cmake 
b/clang/cmake/modules/AddClang.cmake
index 21ac332e4f5fc..d952ff3165587 100644
--- a/clang/cmake/modules/AddClang.cmake
+++ b/clang/cmake/modules/AddClang.cmake
@@ -70,7 +70,7 @@ macro(add_clang_library name)
 ${CLANG_SOURCE_DIR}/include/clang/${lib_path}/*.td
   )
   source_group("TableGen descriptions" FILES ${tds})
-  set_source_files_properties(${tds}} PROPERTIES HEADER_FILE_ONLY ON)
+  set_source_files_properties(${tds} PROPERTIES HEADER_FILE_ONLY ON)
 
   if(headers OR tds)
 set(srcs ${headers} ${tds})



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


[PATCH] D133622: [clang][test] Disallow using the default module cache path in lit tests

2022-09-09 Thread Bruno Cardoso Lopes via Phabricator via cfe-commits
bruno accepted this revision.
bruno added a comment.
This revision is now accepted and ready to land.

Awesome!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133622

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


[PATCH] D133066: fix a typo in comment of AddConversionCandidate

2022-09-09 Thread zhouyizhou via Phabricator via cfe-commits
zhouyizhou added a comment.

In D133066#3780900 , @aaron.ballman 
wrote:

> In D133066#3768091 , @zhouyizhou 
> wrote:
>
>> In D133066#3767146 , 
>> @aaron.ballman wrote:
>>
>>> In D133066#3765503 , @zhouyizhou 
>>> wrote:
>>>
 In D133066#3764384 , 
 @aaron.ballman wrote:

> The existing comment is correct according to my copy of the C++11 
> standard, but the standard has changed since C++11 and those words no 
> longer appear in http://eel.is/c++draft/dcl.init.ref#5. Some more 
> investigation is needed, but I suspect the correct action to take here is 
> to update the comment based on the current standards wording or to see if 
> there's a bug because the code does not match the comment.

 thank Aaron for review my patch, 
 I am a passionate beginner,
>>>
>>> Welcome to the community, we're glad to have you here!
>>
>> Thank Aaron for your encouragement and guidance! Hope I can be some 
>> beneficial to the community.
>>
 this is a very good learning experience for me ;-)  I am looking forward 
 to seeing the final change.
>>>
>>> Happy to help, but to be clear on the next steps: are you planning to do 
>>> the investigation work, or were you hoping someone else would do it?
>>
>> As an amateur, this is a difficult job for me, but I can't help taking a try.
>
> For what it's worth, it's not easy for experts either. :-D

Thanks again for your patience, and sorry for the late feedback, I think I will 
spend 3 more weeks to work out and submit my tentative work.

>> Following your guidance, I found the original C++11 document on the 
>> internet: 
>> https://raw.githubusercontent.com/yjlintw/book-Coding-Developer/master/%E6%A0%87%E5%87%86%E6%96%87%E6%A1%A3/ISO%20IEC%2014882%202011%20(C%2B%2B11).pdf
>>  
>> (the non ASCII code in URL means this document is maintained by a Chinese 
>> like me). 
>> And those words are there!
>
> Yup, that matches my copy of C++11; btw, you can find a late-stage working 
> draft on the committee website at: 
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf

Yes, and I also find those words in above document and the example that follows 
is almost the same except a minor difference.

>> I am eager to do some investigation work in the elementary stage, but I 
>> believe the final work should be done by someone else.
>>
>> Thanks again for your enthusiasm and your patience!
>
> My pleasure!
>
> For the moment, I don't think any changes are needed here regarding the 
> comment.

Thanks again for your guidance. OK. and I use "git log -p  cba72b1f620fd" the 
study the original submit which add those words.
This is a fruitful and happy journey for me ;-)

Cheers
Zhouyi


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133066

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


[clang] f4a13c9 - [Clang][ScanDeps] Change multiple-commands.c test to use -fmodules-cache-path on implicit builds

2022-09-09 Thread Bruno Cardoso Lopes via cfe-commits

Author: Bruno Cardoso Lopes
Date: 2022-09-09T16:20:04-07:00
New Revision: f4a13c9c0a049d40e0365477c58c2a5369eda6dc

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

LOG: [Clang][ScanDeps] Change multiple-commands.c test to use 
-fmodules-cache-path on implicit builds

The module cache escapes the test output dirs in this test. Since its default 
location maybe
composed of system and user related path this can cause problems in some 
builders (e.g. not
accessible paths inherited in a chroot environment).

Clean the test a bit by passing `-fmodules-cache-path` inside the test output 
dirs.

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

Added: 


Modified: 
clang/test/ClangScanDeps/multiple-commands.c

Removed: 




diff  --git a/clang/test/ClangScanDeps/multiple-commands.c 
b/clang/test/ClangScanDeps/multiple-commands.c
index 6640d40e6e7c6..bb169ea10995a 100644
--- a/clang/test/ClangScanDeps/multiple-commands.c
+++ b/clang/test/ClangScanDeps/multiple-commands.c
@@ -150,7 +150,7 @@
   },
   {
 "directory": "DIR"
-"command": "clang_tool -target x86_64-apple-darwin -c 
DIR/tu_save_temps_module.c -save-temps=obj -o DIR/tu_save_temps_module.o 
-fmodules -fimplicit-modules -fimplicit-module-maps"
+"command": "clang_tool -target x86_64-apple-darwin -c 
DIR/tu_save_temps_module.c -save-temps=obj -o DIR/tu_save_temps_module.o 
-fmodules -fimplicit-modules -fimplicit-module-maps 
-fmodules-cache-path=DIR/cache"
 "file": "DIR/tu_save_temps_module.c"
   }
 ]



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


[PATCH] D133617: [Clang][ScanDeps] Change multiple-commands.c test to use -fmodules-cache-path on implicit builds

2022-09-09 Thread Bruno Cardoso Lopes 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 rGf4a13c9c0a04: [Clang][ScanDeps] Change multiple-commands.c 
test to use -fmodules-cache-path… (authored by bruno).

Changed prior to commit:
  https://reviews.llvm.org/D133617?vs=459212=459225#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133617

Files:
  clang/test/ClangScanDeps/multiple-commands.c


Index: clang/test/ClangScanDeps/multiple-commands.c
===
--- clang/test/ClangScanDeps/multiple-commands.c
+++ clang/test/ClangScanDeps/multiple-commands.c
@@ -150,7 +150,7 @@
   },
   {
 "directory": "DIR"
-"command": "clang_tool -target x86_64-apple-darwin -c 
DIR/tu_save_temps_module.c -save-temps=obj -o DIR/tu_save_temps_module.o 
-fmodules -fimplicit-modules -fimplicit-module-maps"
+"command": "clang_tool -target x86_64-apple-darwin -c 
DIR/tu_save_temps_module.c -save-temps=obj -o DIR/tu_save_temps_module.o 
-fmodules -fimplicit-modules -fimplicit-module-maps 
-fmodules-cache-path=DIR/cache"
 "file": "DIR/tu_save_temps_module.c"
   }
 ]


Index: clang/test/ClangScanDeps/multiple-commands.c
===
--- clang/test/ClangScanDeps/multiple-commands.c
+++ clang/test/ClangScanDeps/multiple-commands.c
@@ -150,7 +150,7 @@
   },
   {
 "directory": "DIR"
-"command": "clang_tool -target x86_64-apple-darwin -c DIR/tu_save_temps_module.c -save-temps=obj -o DIR/tu_save_temps_module.o -fmodules -fimplicit-modules -fimplicit-module-maps"
+"command": "clang_tool -target x86_64-apple-darwin -c DIR/tu_save_temps_module.c -save-temps=obj -o DIR/tu_save_temps_module.o -fmodules -fimplicit-modules -fimplicit-module-maps -fmodules-cache-path=DIR/cache"
 "file": "DIR/tu_save_temps_module.c"
   }
 ]
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D132913: [HLSL] Preserve vec3 for HLSL.

2022-09-09 Thread Xiang Li via Phabricator via cfe-commits
python3kgae added a comment.

In D132913#3781611 , @python3kgae 
wrote:

> In D132913#3781591 , @chapuni wrote:
>
>> The fix looks good. Thanks.
>>
>>> Is -DLLVM_ENABLE_ASSERTIONS=ON what you mean by -Asserts?
>>
>> Oh excuse me, "-Asserts" was an ancient term, "w/o assertsions" in the 
>> autoconf age.
>> An antonym was "+Asserts". it means `LLVM_ENABLE_ASSERTIONS=ON`
>
> I see. I'll test LLVM_ENABLE_ASSERTIONS=OFF this time.

Confirmed pass with LLVM_ENABLE_ASSERTIONS=OFF


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132913

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


[PATCH] D133617: [Clang][ScanDeps] Change multiple-commands.c test to use -fmodules-cache-path on implicit builds

2022-09-09 Thread Ben Langmuir via Phabricator via cfe-commits
benlangmuir added a comment.

Attempting to not do this again: https://reviews.llvm.org/D133622


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133617

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


[PATCH] D133622: [clang][test] Disallow using the default module cache path in lit tests

2022-09-09 Thread Ben Langmuir via Phabricator via cfe-commits
benlangmuir created this revision.
benlangmuir added reviewers: bruno, jansvoboda11, arphaman.
Herald added a subscriber: delcypher.
Herald added a project: All.
benlangmuir requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

Make the default module cache path invalid when running lit tests so
that tests are forced to provide a cache path. This avoids accidentally
escaping to the system default location, and would have caught the
failure recently found in ClangScanDeps/multiple-commands.c.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133622

Files:
  clang/test/Driver/modules-cache-path.m
  clang/test/Modules/driver.c
  llvm/utils/lit/lit/llvm/config.py


Index: llvm/utils/lit/lit/llvm/config.py
===
--- llvm/utils/lit/lit/llvm/config.py
+++ llvm/utils/lit/lit/llvm/config.py
@@ -495,6 +495,10 @@
 
 self.clear_environment(possibly_dangerous_env_vars)
 
+# Make the default module cache path invalid so that tests are forced 
to
+# provide a cache path if they use implicit modules.
+self.with_environment('CLANG_MODULE_CACHE_PATH', '/dev/null')
+
 # Tweak the PATH to include the tools dir and the scripts dir.
 # Put Clang first to avoid LLVM from overriding out-of-tree clang
 # builds.
Index: clang/test/Modules/driver.c
===
--- clang/test/Modules/driver.c
+++ clang/test/Modules/driver.c
@@ -1,4 +1,4 @@
-// RUN: %clang -fmodules -fimplicit-module-maps %s -### 2>&1 | FileCheck 
-check-prefix CHECK-NO_MODULE_CACHE %s
+// RUN: env -u CLANG_MODULE_CACHE_PATH %clang -fmodules -fimplicit-module-maps 
%s -### 2>&1 | FileCheck -check-prefix CHECK-NO_MODULE_CACHE %s
 // RUN: %clang -fmodules -fimplicit-module-maps -fmodules-cache-path=blarg %s 
-### 2>&1 | FileCheck -check-prefix CHECK-WITH_MODULE_CACHE %s
 
 // CHECK-NO_MODULE_CACHE: {{clang.*"-fmodules-cache-path=.*ModuleCache"}}
Index: clang/test/Driver/modules-cache-path.m
===
--- clang/test/Driver/modules-cache-path.m
+++ clang/test/Driver/modules-cache-path.m
@@ -1,4 +1,4 @@
-// RUN: %clang -fmodules -### %s 2>&1 | FileCheck %s 
-check-prefix=CHECK-DEFAULT
+// RUN: env -u CLANG_MODULE_CACHE_PATH %clang -fmodules -### %s 2>&1 | 
FileCheck %s -check-prefix=CHECK-DEFAULT
 // CHECK-DEFAULT: -fmodules-cache-path={{.*}}clang{{[/\\]+}}ModuleCache
 
 // RUN: env CLANG_MODULE_CACHE_PATH=/dev/null \


Index: llvm/utils/lit/lit/llvm/config.py
===
--- llvm/utils/lit/lit/llvm/config.py
+++ llvm/utils/lit/lit/llvm/config.py
@@ -495,6 +495,10 @@
 
 self.clear_environment(possibly_dangerous_env_vars)
 
+# Make the default module cache path invalid so that tests are forced to
+# provide a cache path if they use implicit modules.
+self.with_environment('CLANG_MODULE_CACHE_PATH', '/dev/null')
+
 # Tweak the PATH to include the tools dir and the scripts dir.
 # Put Clang first to avoid LLVM from overriding out-of-tree clang
 # builds.
Index: clang/test/Modules/driver.c
===
--- clang/test/Modules/driver.c
+++ clang/test/Modules/driver.c
@@ -1,4 +1,4 @@
-// RUN: %clang -fmodules -fimplicit-module-maps %s -### 2>&1 | FileCheck -check-prefix CHECK-NO_MODULE_CACHE %s
+// RUN: env -u CLANG_MODULE_CACHE_PATH %clang -fmodules -fimplicit-module-maps %s -### 2>&1 | FileCheck -check-prefix CHECK-NO_MODULE_CACHE %s
 // RUN: %clang -fmodules -fimplicit-module-maps -fmodules-cache-path=blarg %s -### 2>&1 | FileCheck -check-prefix CHECK-WITH_MODULE_CACHE %s
 
 // CHECK-NO_MODULE_CACHE: {{clang.*"-fmodules-cache-path=.*ModuleCache"}}
Index: clang/test/Driver/modules-cache-path.m
===
--- clang/test/Driver/modules-cache-path.m
+++ clang/test/Driver/modules-cache-path.m
@@ -1,4 +1,4 @@
-// RUN: %clang -fmodules -### %s 2>&1 | FileCheck %s -check-prefix=CHECK-DEFAULT
+// RUN: env -u CLANG_MODULE_CACHE_PATH %clang -fmodules -### %s 2>&1 | FileCheck %s -check-prefix=CHECK-DEFAULT
 // CHECK-DEFAULT: -fmodules-cache-path={{.*}}clang{{[/\\]+}}ModuleCache
 
 // RUN: env CLANG_MODULE_CACHE_PATH=/dev/null \
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D133617: [Clang][ScanDeps] Change multiple-commands.c test to use -fmodules-cache-path on implicit builds

2022-09-09 Thread Bruno Cardoso Lopes via Phabricator via cfe-commits
bruno added a comment.

Thanks for the fast review! Good suggestions, will apply and land.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133617

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


[PATCH] D133617: [Clang][ScanDeps] Change multiple-commands.c test to use -fmodules-cache-path on implicit builds

2022-09-09 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 accepted this revision.
jansvoboda11 added a comment.

LGTM, thanks! Though we usually put the cache directory into `%t/cache` (aka 
`DIR/cache` in the JSON file) in other scanner tests, which would allow you to 
drop the second `sed` expression. (And you'd want to `rm -rf %t` instead.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133617

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


[PATCH] D132913: [HLSL] Preserve vec3 for HLSL.

2022-09-09 Thread Xiang Li via Phabricator via cfe-commits
python3kgae added a comment.

In D132913#3781591 , @chapuni wrote:

> The fix looks good. Thanks.
>
>> Is -DLLVM_ENABLE_ASSERTIONS=ON what you mean by -Asserts?
>
> Oh excuse me, "-Asserts" was an ancient term, "w/o assertsions" in the 
> autoconf age.
> An antonym was "+Asserts". it means `LLVM_ENABLE_ASSERTIONS=ON`

I see. I'll test LLVM_ENABLE_ASSERTIONS=OFF this time.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132913

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


[PATCH] D133617: [Clang][ScanDeps] Change multiple-commands.c test to use -fmodules-cache-path on implicit builds

2022-09-09 Thread Ben Langmuir via Phabricator via cfe-commits
benlangmuir accepted this revision.
benlangmuir added a comment.
This revision is now accepted and ready to land.

Thanks for catching this!




Comment at: clang/test/ClangScanDeps/multiple-commands.c:11
 // RUN: split-file %s %t
-// RUN: sed -e "s|DIR|%/t|g" %t/cdb.json.in > %t/cdb.json
+// RUN: sed -e "s|DIR|%/t|g" -e "s|CACHE_PATH|%t.modcache|g" %t/cdb.json.in > 
%t/cdb.json
 

Nit: we could just put it inside DIR/modcache and not need a second 
substitution.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133617

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


[PATCH] D133617: [Clang][ScanDeps] Change multiple-commands.c test to use -fmodules-cache-path on implicit builds

2022-09-09 Thread Bruno Cardoso Lopes via Phabricator via cfe-commits
bruno created this revision.
bruno added reviewers: benlangmuir, jansvoboda11, arphaman.
Herald added subscribers: hoy, modimo, wenlei.
Herald added a project: All.
bruno requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

The module cache escapes the test output dirs in this test. Since its default 
location maybe
composed of system and user related path this can cause problems in some 
builders (e.g. not
accessible paths inherited in a chroot environment).

Clean the test a bit by passing `-fmodules-cache-path` inside the test output 
dirs.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133617

Files:
  clang/test/ClangScanDeps/multiple-commands.c


Index: clang/test/ClangScanDeps/multiple-commands.c
===
--- clang/test/ClangScanDeps/multiple-commands.c
+++ clang/test/ClangScanDeps/multiple-commands.c
@@ -6,9 +6,9 @@
 // the driver. Platforms without an integrated assembler have different 
commands
 // REQUIRES: x86-registered-target
 
-// RUN: rm -rf %t
+// RUN: rm -rf %t %t.modcache
 // RUN: split-file %s %t
-// RUN: sed -e "s|DIR|%/t|g" %t/cdb.json.in > %t/cdb.json
+// RUN: sed -e "s|DIR|%/t|g" -e "s|CACHE_PATH|%t.modcache|g" %t/cdb.json.in > 
%t/cdb.json
 
 // RUN: clang-scan-deps -compilation-database %t/cdb.json -module-files-dir 
%t/modules \
 // RUN:   -j 1 -format experimental-full -mode 
preprocess-dependency-directives \
@@ -150,7 +150,7 @@
   },
   {
 "directory": "DIR"
-"command": "clang_tool -target x86_64-apple-darwin -c 
DIR/tu_save_temps_module.c -save-temps=obj -o DIR/tu_save_temps_module.o 
-fmodules -fimplicit-modules -fimplicit-module-maps"
+"command": "clang_tool -target x86_64-apple-darwin -c 
DIR/tu_save_temps_module.c -save-temps=obj -o DIR/tu_save_temps_module.o 
-fmodules -fimplicit-modules -fimplicit-module-maps 
-fmodules-cache-path=CACHE_PATH"
 "file": "DIR/tu_save_temps_module.c"
   }
 ]


Index: clang/test/ClangScanDeps/multiple-commands.c
===
--- clang/test/ClangScanDeps/multiple-commands.c
+++ clang/test/ClangScanDeps/multiple-commands.c
@@ -6,9 +6,9 @@
 // the driver. Platforms without an integrated assembler have different commands
 // REQUIRES: x86-registered-target
 
-// RUN: rm -rf %t
+// RUN: rm -rf %t %t.modcache
 // RUN: split-file %s %t
-// RUN: sed -e "s|DIR|%/t|g" %t/cdb.json.in > %t/cdb.json
+// RUN: sed -e "s|DIR|%/t|g" -e "s|CACHE_PATH|%t.modcache|g" %t/cdb.json.in > %t/cdb.json
 
 // RUN: clang-scan-deps -compilation-database %t/cdb.json -module-files-dir %t/modules \
 // RUN:   -j 1 -format experimental-full -mode preprocess-dependency-directives \
@@ -150,7 +150,7 @@
   },
   {
 "directory": "DIR"
-"command": "clang_tool -target x86_64-apple-darwin -c DIR/tu_save_temps_module.c -save-temps=obj -o DIR/tu_save_temps_module.o -fmodules -fimplicit-modules -fimplicit-module-maps"
+"command": "clang_tool -target x86_64-apple-darwin -c DIR/tu_save_temps_module.c -save-temps=obj -o DIR/tu_save_temps_module.o -fmodules -fimplicit-modules -fimplicit-module-maps -fmodules-cache-path=CACHE_PATH"
 "file": "DIR/tu_save_temps_module.c"
   }
 ]
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D132913: [HLSL] Preserve vec3 for HLSL.

2022-09-09 Thread NAKAMURA Takumi via Phabricator via cfe-commits
chapuni added a comment.

The fix looks good. Thanks.

> Is -DLLVM_ENABLE_ASSERTIONS=ON what you mean by -Asserts?

Oh excuse me, "-Asserts" was an ancient term, "w/o assertsions" in the autoconf 
age.
An antonym was "+Asserts". it means `LLVM_ENABLE_ASSERTIONS=ON`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132913

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


[PATCH] D132913: [HLSL] Preserve vec3 for HLSL.

2022-09-09 Thread Xiang Li via Phabricator via cfe-commits
python3kgae added a comment.

In D132913#3781494 , @chapuni wrote:

> The test fails for -Asserts.

Fixed the %0 issue in 
https://github.com/llvm/llvm-project/commit/71fae33f5e7c1b11e32db695fd24dd50aead737c
It passed locally on build with -DLLVM_ENABLE_ASSERTIONS=ON

Is -DLLVM_ENABLE_ASSERTIONS=ON what you mean by -Asserts?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132913

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


[PATCH] D132916: [clang] Explicitly set the EmulatedTLS codegen option

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

LGTM

(I think you can call it "NFC" if there's no visible change in community; you 
don't have to try to account for downstream changes that might interact with 
it.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132916

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


[clang] 71fae33 - [NFC] Cleanup test for D132913 Preserve vec3 for HLSL

2022-09-09 Thread Xiang Li via cfe-commits

Author: Xiang Li
Date: 2022-09-09T15:04:59-07:00
New Revision: 71fae33f5e7c1b11e32db695fd24dd50aead737c

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

LOG: [NFC] Cleanup test for D132913 Preserve vec3 for HLSL

Support number for parameter test added in
https://reviews.llvm.org/D132913

Added: 


Modified: 
clang/test/CodeGenHLSL/float3.hlsl

Removed: 




diff  --git a/clang/test/CodeGenHLSL/float3.hlsl 
b/clang/test/CodeGenHLSL/float3.hlsl
index 6ee43157cecec..4adda8dee1214 100644
--- a/clang/test/CodeGenHLSL/float3.hlsl
+++ b/clang/test/CodeGenHLSL/float3.hlsl
@@ -1,9 +1,9 @@
 // RUN: %clang --driver-mode=dxc -Tlib_6_7 -fcgl  -Fo - %s | FileCheck %s
 
 // Make sure float3 is not changed into float4.
-// CHECK:<3 x float> @"?foo@@YAT?$__vector@M$02@__clang@@T12@@Z"(<3 x float> 
noundef %a)
+// CHECK:<3 x float> @"?foo@@YAT?$__vector@M$02@__clang@@T12@@Z"(<3 x float> 
noundef %[[PARAM:[0-9a-zA-Z]+]])
 // CHECK:%[[A_ADDR:.+]] = alloca <3 x float>, align 16
-// CHECK-NEXT:store <3 x float> %a, ptr %[[A_ADDR]], align 16
+// CHECK-NEXT:store <3 x float> %[[PARAM]], ptr %[[A_ADDR]], align 16
 // CHECK-NEXT:%[[V:[0-9]+]] = load <3 x float>, ptr %[[A_ADDR]], align 16
 // CHECK-NEXT:ret <3 x float> %[[V]]
 float3 foo(float3 a) {



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


[PATCH] D132952: [Sema] disable -Wvla for function array parameters

2022-09-09 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added a comment.

That sounds fine.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132952

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


[PATCH] D132186: Clang: Add a new flag Wmisnoinline for printing hot noinline functions

2022-09-09 Thread Archit Saxena via Phabricator via cfe-commits
iamarchit123 added a comment.

Hi  @modimo @paulkirth any good open source benchmarks where I also can test 
this? The problem is finding some standard benchmarks which are profiled as 
well as have standard performance measuring metric to measure improvement.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132186

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


[PATCH] D133586: [clang] do not hash undefined qualifiers for FunctionNoProtoType

2022-09-09 Thread Richard Trieu via Phabricator via cfe-commits
rtrieu added a comment.

In D133586#3781468 , @rmaz wrote:

> In D133586#3781381 , @rtrieu wrote:
>
>> Do you have a test case for this?
>
> Was struggling to think of a good one. How about a test that repeatedly 
> generates a pcm for a func decl with no params and checks if the 
> DECL_FUNCTION record is the same?

Have you looked at clang/test/Modules/odr_hash.cpp?  It's where most of the ODR 
hash testing takes place by testing that Decls can be merged properly instead 
of checking the contents of pcm files..  Using `#if define`, it creates 
multiple modules from the same file.  I would suggest creating two functions in 
each of the modules, then in the main file, using the function to force it to 
be loaded from the modules and merged together.  The test should fail with the 
current Clang, but pass with your patch.  You may need to create your test file 
if you need different compiler options.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133586

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


[PATCH] D53847: [C++2a] P0634r3: Down with typename!

2022-09-09 Thread Alan Zhao via Phabricator via cfe-commits
ayzhao updated this revision to Diff 459205.
ayzhao added a comment.

Fix typename-specifier-3.cpp test

Things done:

- the warning should also include a check that C++20 is required
- the warning should only show up for precxx17, as %std_cxx17- translates to 
-std=c++2b


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D53847

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Parse/Parser.h
  clang/include/clang/Sema/DeclSpec.h
  clang/include/clang/Sema/Sema.h
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Parse/ParseExpr.cpp
  clang/lib/Parse/ParseExprCXX.cpp
  clang/lib/Parse/ParseTemplate.cpp
  clang/lib/Parse/ParseTentative.cpp
  clang/lib/Parse/Parser.cpp
  clang/lib/Sema/DeclSpec.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/test/CXX/basic/basic.lookup/basic.lookup.qual/class.qual/p2.cpp
  clang/test/CXX/drs/dr1xx.cpp
  clang/test/CXX/drs/dr2xx.cpp
  clang/test/CXX/drs/dr4xx.cpp
  clang/test/CXX/drs/dr5xx.cpp
  clang/test/CXX/temp/temp.res/p3.cpp
  clang/test/CXX/temp/temp.res/p4.cpp
  clang/test/CXX/temp/temp.res/temp.dep/temp.dep.type/p1.cpp
  clang/test/FixIt/fixit.cpp
  clang/test/Parser/cxx-member-initializers.cpp
  clang/test/SemaCXX/MicrosoftCompatibility.cpp
  clang/test/SemaCXX/MicrosoftExtensions.cpp
  clang/test/SemaCXX/MicrosoftSuper.cpp
  clang/test/SemaCXX/rounding-math-crash.cpp
  clang/test/SemaCXX/typo-correction.cpp
  clang/test/SemaCXX/unknown-type-name.cpp
  clang/test/SemaTemplate/alias-templates.cpp
  clang/test/SemaTemplate/typename-specifier-3.cpp

Index: clang/test/SemaTemplate/typename-specifier-3.cpp
===
--- clang/test/SemaTemplate/typename-specifier-3.cpp
+++ clang/test/SemaTemplate/typename-specifier-3.cpp
@@ -28,7 +28,7 @@
   typedef int arg;
 };
 struct C {
-  typedef B::X x; // expected-error {{missing 'typename'}}
+  typedef B::X x; // precxx17-warning{{missing 'typename' prior to dependent type name B::X; implicit 'typename' is a C++20 extension}}
 };
   };
 
Index: clang/test/SemaTemplate/alias-templates.cpp
===
--- clang/test/SemaTemplate/alias-templates.cpp
+++ clang/test/SemaTemplate/alias-templates.cpp
@@ -193,11 +193,10 @@
   struct base {
 template  struct derived;
   };
-  // FIXME: The diagnostics here are terrible.
   template 
-  using derived = base::template derived; // expected-error {{expected a type}} expected-error {{expected ';'}}
+  using derived = base::template derived; // expected-warning {{missing 'typename'}}
   template 
-  using derived2 = ::PR16904::base::template derived; // expected-error {{expected a type}} expected-error {{expected ';'}}
+  using derived2 = ::PR16904::base::template derived; // expected-warning {{missing 'typename'}}
 }
 
 namespace PR14858 {
Index: clang/test/SemaCXX/unknown-type-name.cpp
===
--- clang/test/SemaCXX/unknown-type-name.cpp
+++ clang/test/SemaCXX/unknown-type-name.cpp
@@ -36,15 +36,15 @@
 
   static int n;
   static type m;
-  static int h(T::type, int); // expected-error{{missing 'typename'}}
-  static int h(T::type x, char); // expected-error{{missing 'typename'}}
+  static int h(T::type, int); // expected-warning{{implicit 'typename' is a C++20 extension}}
+  static int h(T::type x, char); // expected-warning{{implicit 'typename' is a C++20 extension}}
 };
 
 template
-A::type g(T t) { return t; } // expected-error{{missing 'typename'}}
+A::type g(T t) { return t; } // expected-warning{{implicit 'typename' is a C++20 extension}}
 
 template
-A::type A::f() { return type(); } // expected-error{{missing 'typename'}}
+A::type A::f() { return type(); } // expected-warning{{implicit 'typename' is a C++20 extension}}
 
 template
 void f(T::type) { } // expected-error{{missing 'typename'}}
@@ -84,11 +84,11 @@
 
 template int A::n(T::value); // ok
 template
-A::type // expected-error{{missing 'typename'}}
+A::type // expected-warning {{implicit 'typename' is a C++20 extension}}
 A::m(T::value, 0); // ok
 
-template int A::h(T::type, int) {} // expected-error{{missing 'typename'}}
-template int A::h(T::type x, char) {} // expected-error{{missing 'typename'}}
+template int A::h(T::type, int) {} // expected-warning{{implicit 'typename' is a C++20 extension}}
+template int A::h(T::type x, char) {} // expected-warning{{implicit 'typename' is a C++20 extension}}
 
 template int h(T::type, int); // expected-error{{missing 'typename'}}
 template int h(T::type x, char); // expected-error{{missing 'typename'}}
@@ -116,4 +116,5 @@
 // FIXME: We know which type specifier should have been specified here. Provide
 //a fix-it to add 'typename A::type'
 template
-A::g() { } // expected-error{{a type 

[PATCH] D133157: Add -fsanitizer-coverage=control-flow

2022-09-09 Thread Navid Emamdoost via Phabricator via cfe-commits
Navidem added inline comments.



Comment at: clang/lib/Driver/SanitizerArgs.cpp:814
 (CoverageTracePC | CoverageTracePCGuard | CoverageInline8bitCounters |
- CoverageInlineBoolFlag))
+ CoverageInlineBoolFlag | CoverageControlFlow))
   CoverageFeatures |= CoverageEdge;

vitalybuka wrote:
> why do you need CoverageEdge if enabled CoverageControlFlow?
No essential need, but here I am implicitly enabling `edge` when 
instrumentation type is not specified. This was the way that I could get 
`-fsanitizer-coverage=control-flow` working without passing 
`-fsanitizer-coverage=bb,control-flow`.



Comment at: clang/lib/Driver/SanitizerArgs.cpp:807
 << "-fsanitize-coverage=[func|bb|edge]"
-<< "-fsanitize-coverage=[func|bb|edge],[trace-pc-guard|trace-pc]";
+<< 
"-fsanitize-coverage=[func|bb|edge],[trace-pc-guard|trace-pc|control-flow]";
   }

Navidem wrote:
> vitalybuka wrote:
> > shouldn't this be:
> > ,[trace-pc-guard|trace-pc],[control-flow]
> > 
> > probably even:
> > [,(trace-pc-guard|trace-pc)][,control-flow]
> > shouldn't this be:
> > ,[trace-pc-guard|trace-pc],[control-flow]
> > 
> > probably even:
> > [,(trace-pc-guard|trace-pc)][,control-flow]
> 
> 
> shouldn't this be:
> ,[trace-pc-guard|trace-pc],[control-flow]

This makes sense, thanks!




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133157

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


[PATCH] D133157: Add -fsanitizer-coverage=control-flow

2022-09-09 Thread Navid Emamdoost via Phabricator via cfe-commits
Navidem updated this revision to Diff 459201.
Navidem added a comment.

Bring back the runtime test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133157

Files:
  clang/docs/SanitizerCoverage.rst
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Basic/CodeGenOptions.h
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/SanitizerArgs.cpp
  
compiler-rt/test/sanitizer_common/TestCases/sanitizer_coverage_control_flow.cpp
  llvm/include/llvm/Transforms/Instrumentation.h
  llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
  llvm/test/Instrumentation/SanitizerCoverage/control-flow.ll

Index: llvm/test/Instrumentation/SanitizerCoverage/control-flow.ll
===
--- /dev/null
+++ llvm/test/Instrumentation/SanitizerCoverage/control-flow.ll
@@ -0,0 +1,22 @@
+; Test -sanitizer-coverage-control-flow.
+; RUN: opt < %s -passes='module(sancov-module)' -sanitizer-coverage-level=3 -sanitizer-coverage-control-flow -S | FileCheck %s
+
+target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
+target triple = "x86_64-unknown-linux-gnu"
+define void @foo(ptr %a) sanitize_address {
+entry:
+  %tobool = icmp eq i32* %a, null
+  br i1 %tobool, label %if.end, label %if.then
+
+  if.then:  ; preds = %entry
+  store i32 0, i32* %a, align 4
+  call void @foo(i32* %a)
+  br label %if.end
+
+  if.end:   ; preds = %entry, %if.then
+  ret void
+}
+
+; CHECK: private constant [17 x ptr] [{{.*}}@foo{{.*}}blockaddress{{.*}}blockaddress{{.*}}blockaddress{{.*}}blockaddress{{.*}}blockaddress{{.*}}blockaddress{{.*}}blockaddress{{.*}}@foo{{.*}}null{{.*}}null], section "__sancov_cfs", comdat($foo), align 8
+; CHECK:  @__start___sancov_cfs = extern_weak hidden global
+; CHECK-NEXT: @__stop___sancov_cfs = extern_weak hidden global
Index: llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
===
--- llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
+++ llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
@@ -75,11 +75,13 @@
 const char SanCov8bitCountersInitName[] = "__sanitizer_cov_8bit_counters_init";
 const char SanCovBoolFlagInitName[] = "__sanitizer_cov_bool_flag_init";
 const char SanCovPCsInitName[] = "__sanitizer_cov_pcs_init";
+const char SanCovCFsInitName[] = "__sanitizer_cov_cfs_init";
 
 const char SanCovGuardsSectionName[] = "sancov_guards";
 const char SanCovCountersSectionName[] = "sancov_cntrs";
 const char SanCovBoolFlagSectionName[] = "sancov_bools";
 const char SanCovPCsSectionName[] = "sancov_pcs";
+const char SanCovCFsSectionName[] = "sancov_cfs";
 
 const char SanCovLowestStackName[] = "__sancov_lowest_stack";
 
@@ -147,6 +149,10 @@
   cl::desc("max stack depth tracing"),
   cl::Hidden, cl::init(false));
 
+static cl::opt ClCollectCF("sanitizer-coverage-control-flow",
+  cl::desc("collect control flow for each function"),
+  cl::Hidden, cl::init(false));
+
 namespace {
 
 SanitizerCoverageOptions getOptions(int LegacyCoverageLevel) {
@@ -193,6 +199,7 @@
   !Options.Inline8bitCounters && !Options.StackDepth &&
   !Options.InlineBoolFlag && !Options.TraceLoads && !Options.TraceStores)
 Options.TracePCGuard = true; // TracePCGuard is default.
+  Options.CollectControlFlow |= ClCollectCF;
   return Options;
 }
 
@@ -212,6 +219,7 @@
 PostDomTreeCallback PDTCallback);
 
 private:
+  void createFunctionControlFlow(Function );
   void instrumentFunction(Function , DomTreeCallback DTCallback,
   PostDomTreeCallback PDTCallback);
   void InjectCoverageForIndirectCalls(Function ,
@@ -270,6 +278,7 @@
   GlobalVariable *Function8bitCounterArray;  // for inline-8bit-counters.
   GlobalVariable *FunctionBoolArray; // for inline-bool-flag.
   GlobalVariable *FunctionPCsArray;  // for pc-table.
+  GlobalVariable *FunctionCFsArray;  // for control flow table
   SmallVector GlobalsToAppendToUsed;
   SmallVector GlobalsToAppendToCompilerUsed;
 
@@ -378,6 +387,7 @@
   Function8bitCounterArray = nullptr;
   FunctionBoolArray = nullptr;
   FunctionPCsArray = nullptr;
+  FunctionCFsArray = nullptr;
   IntptrTy = Type::getIntNTy(*C, DL->getPointerSizeInBits());
   IntptrPtrTy = PointerType::getUnqual(IntptrTy);
   Type *VoidTy = Type::getVoidTy(*C);
@@ -502,6 +512,15 @@
 IRBuilder<> IRBCtor(Ctor->getEntryBlock().getTerminator());
 IRBCtor.CreateCall(InitFunction, {SecStartEnd.first, SecStartEnd.second});
   }
+
+  if (Ctor && Options.CollectControlFlow) {
+auto 

[PATCH] D133157: Add -fsanitizer-coverage=control-flow

2022-09-09 Thread Vitaly Buka via Phabricator via cfe-commits
vitalybuka added inline comments.



Comment at: clang/docs/SanitizerCoverage.rst:382
+  void __sanitizer_cov_cfs_init(const uintptr_t *cfs_beg,
+const uintptr_t *cfs_end) {
+// [cfs_beg,cfs_end) is the array of ptr-sized integers representing

vitalybuka wrote:
> we can also generate normal structs, per function, and pass them into 
> __sanitizer_cov_cfs_init(const MyStruct* begin, const MyStruct* end);
> this was can avoid  this magic encoding completely?
Works for me either way. @kcc WDYT? 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133157

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


[PATCH] D132913: [HLSL] Preserve vec3 for HLSL.

2022-09-09 Thread Xiang Li via Phabricator via cfe-commits
python3kgae added inline comments.



Comment at: clang/test/CodeGenHLSL/float3.hlsl:4
+// Make sure float3 is not changed into float4.
+// CHECK:<3 x float> @"?foo@@YAT?$__vector@M$02@__clang@@T12@@Z"(<3 x float> 
noundef %a)
+// CHECK:%[[A_ADDR:.+]] = alloca <3 x float>, align 16

chapuni wrote:
> Also `%a` may be unnamed, like `%0`
Thanks for pointing this out.
I'll fix it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132913

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


[PATCH] D133157: Add -fsanitizer-coverage=control-flow

2022-09-09 Thread Vitaly Buka via Phabricator via cfe-commits
vitalybuka added a comment.

we need to update
llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_coverage_interface.inc
llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_interface_internal.h

you can search by __sanitizer_cov_8bit_counters_init if anything missing

Something like SingletonCounterCoverage could be useful.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133157

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


[PATCH] D132913: [HLSL] Preserve vec3 for HLSL.

2022-09-09 Thread NAKAMURA Takumi via Phabricator via cfe-commits
chapuni added a comment.

The test fails for -Asserts.




Comment at: clang/test/CodeGenHLSL/float3.hlsl:4
+// Make sure float3 is not changed into float4.
+// CHECK:<3 x float> @"?foo@@YAT?$__vector@M$02@__clang@@T12@@Z"(<3 x float> 
noundef %a)
+// CHECK:%[[A_ADDR:.+]] = alloca <3 x float>, align 16

Also `%a` may be unnamed, like `%0`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132913

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


[PATCH] D130867: [clang] adds builtin `std::invoke` and `std::invoke_r`

2022-09-09 Thread Louis Dionne via Phabricator via cfe-commits
ldionne added a comment.

In D130867#3781429 , @cjdb wrote:

> I had not realised that libc++ was listed as a reviewer.

The change does have an impact on libc++, so I think it makes sense to look at 
it not only from the compiler perspective, but from the whole clang/libc++ 
ecosystem's perspective.

> I am going to abandon this revision, since I only wish to interact with that 
> community when it is both business-critical and unavoidable.

While you're not saying so explicitly, you seem to be implying some sort of 
fault on libc++ here, which I don't understand. I am trying to engage in a 
genuine and productive discussion. I'm asking questions to clarify my 
understanding of your benchmarks, raising IMO reasonable technical concerns 
with the patch, and doing so politely unless I missed something. I'm not saying 
we should not move forward with the patch -- there must be a reason why you put 
in all this effort into it. I'm merely raising concerns because no, this isn't 
a black-and-white situation -- there is a tradeoff with this patch.

I don't know whether your comment targets me personally or the libc++ community 
as a whole, but either way, honestly this sort of "I won't talk to you" 
behavior is kind of hurtful. If you feel there's something wrong with the 
libc++ community or with me, the LLVM Foundation has channels to remediate to 
that, and I encourage you (or anyone feeling bad about any part of LLVM) to use 
them.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130867

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


[PATCH] D133157: Add -fsanitizer-coverage=control-flow

2022-09-09 Thread Vitaly Buka via Phabricator via cfe-commits
vitalybuka added inline comments.



Comment at: clang/docs/SanitizerCoverage.rst:382
+  void __sanitizer_cov_cfs_init(const uintptr_t *cfs_beg,
+const uintptr_t *cfs_end) {
+// [cfs_beg,cfs_end) is the array of ptr-sized integers representing

we can also generate normal structs, per function, and pass them into 
__sanitizer_cov_cfs_init(const MyStruct* begin, const MyStruct* end);
this was can avoid  this magic encoding completely?



Comment at: clang/lib/Driver/SanitizerArgs.cpp:814
 (CoverageTracePC | CoverageTracePCGuard | CoverageInline8bitCounters |
- CoverageInlineBoolFlag))
+ CoverageInlineBoolFlag | CoverageControlFlow))
   CoverageFeatures |= CoverageEdge;

why do you need CoverageEdge if enabled CoverageControlFlow?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133157

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


[PATCH] D133609: [Sema] compat warning of using deduced type in non-type template parameter

2022-09-09 Thread Matheus Izvekov via Phabricator via cfe-commits
mizvekov added inline comments.



Comment at: clang/lib/Sema/SemaTemplate.cpp:1535-1545
+if (TInfo->getType()->getContainedAutoType()) {
+  // template
+  Diag(D.getIdentifierLoc(),
+   diag::warn_cxx14_compat_template_nontype_parm_auto_type)
+  << QualType(TInfo->getType()->getContainedAutoType(), 0);
+} else {
+  // template

This largely duplicates the effort from D132990

Your patch will also fix the crash fixed by D132990, and I even suggested there 
also handling deduced template specializations.

Two points about this change though:

* The new diagnosticis too generic and does not explain what the user did wrong.
* Please test for each case of AutoType and DeducedTemplateSpecializationType 
explicitly, and llvm_unreachable on anything else, so that when a new kind of 
DeducedType is added, we handle it with an appropriate message. This goes with 
the first bullet, if you know what each case is, you can produce more 
explanatory diagnostics.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133609

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


[PATCH] D133586: [clang] do not hash undefined qualifiers for FunctionNoProtoType

2022-09-09 Thread Richard Howell via Phabricator via cfe-commits
rmaz added a comment.

In D133586#3781381 , @rtrieu wrote:

> Do you have a test case for this?

Was struggling to think of a good one. How about a test that repeatedly 
generates a pcm for a func decl with no params and checks if the DECL_FUNCTION 
record is the same?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133586

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


[PATCH] D130867: [clang] adds builtin `std::invoke` and `std::invoke_r`

2022-09-09 Thread Christopher Di Bella via Phabricator via cfe-commits
cjdb abandoned this revision.
cjdb added a comment.

I had not realised that libc++ was listed as a reviewer. I am going to abandon 
this revision, since I only wish to interact with that community when it is 
both business-critical and unavoidable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130867

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


[PATCH] D133611: [clang] sort additional module maps when serializing

2022-09-09 Thread Ben Langmuir via Phabricator via cfe-commits
benlangmuir accepted this revision.
benlangmuir added a comment.
This revision is now accepted and ready to land.

Good catch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133611

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


[PATCH] D133570: Clang codegen, fixes issue with emitting partially initialized constant arrays larger than 2^32

2022-09-09 Thread Ofek Shochat via Phabricator via cfe-commits
OfekShochat added a comment.

Yeah. But it's really not clear how it does that, as it gets all the functions 
from the generated file


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133570

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


[PATCH] D133570: Clang codegen, fixes issue with emitting partially initialized constant arrays larger than 2^32

2022-09-09 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added a comment.

FYI, the "Visit" method comes from the base class StmtVisitor; it just forwards 
to the relevant method.  (For example, if you call "Visit" with an 
InitListExpr, it calls VisitInitListExpr.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133570

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


[PATCH] D133589: [clang-format] JSON formatting add new option for controlling newlines in json arrays

2022-09-09 Thread Marek Kurdej via Phabricator via cfe-commits
curdeius added inline comments.



Comment at: clang/docs/ClangFormatStyleOptions.rst:3115
 
+**JsonMultilineArrays** (``Boolean``) :versionbadge:`clang-format 16`
+  If ``true``, clang-format will always break after a Json array `[`

Why limiting to JSON only?
Could we name it in a general fashion (we comment that it's JSON only for the 
time being). I believe it may be an interesting option for various languages.

How about BreakMultilineArrays, or just BreakArrays to follow the naming of 
existing options a bit?



Comment at: clang/lib/Format/TokenAnnotator.cpp:4413
+  while (Tok) {
+if (Tok->isOneOf(tok::l_brace, tok::l_square)) {
+  return true;

Please elide braces in the ifs.



Comment at: clang/lib/Format/TokenAnnotator.cpp:4427
+if (Left.is(tok::comma)) {
+  if (Right.is(tok::l_brace)) {
+return true;

You can elide braces here.



Comment at: clang/lib/Format/TokenAnnotator.cpp:4434
+  while (Tok) {
+if (Tok->isOneOf(tok::l_brace, tok::l_square)) {
+  return true;

You might elide braces in both ifs.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133589

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


[PATCH] D133613: [clang][cmake] Remove extra brace

2022-09-09 Thread Petr Hosek via Phabricator via cfe-commits
phosek accepted this revision.
phosek added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133613

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


[PATCH] D133586: [clang] do not hash undefined qualifiers for FunctionNoProtoType

2022-09-09 Thread Richard Trieu via Phabricator via cfe-commits
rtrieu added a comment.

Do you have a test case for this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133586

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


[PATCH] D133571: [clang-format] Introduce NoFallThrough option into AllowShortCaseLabelsOnASingleLine

2022-09-09 Thread Marek Kurdej via Phabricator via cfe-commits
curdeius accepted this revision.
curdeius added a comment.
This revision is now accepted and ready to land.

LGTM after fixing the last comment.




Comment at: clang/lib/Format/UnwrappedLineFormatter.cpp:650
+  // Don't merge if the last thing on the line before was an attribute.
+  if (PreviousLine->Last->Previous && PreviousLine->Last->Previous) {
+auto *PrevPrev = PreviousLine->Last->Previous->Previous;

Haven't seen this before.


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

https://reviews.llvm.org/D133571

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


[PATCH] D133613: [clang][cmake] Remove extra brace

2022-09-09 Thread Mohammed Keyvanzadeh via Phabricator via cfe-commits
VoltrexMaster created this revision.
VoltrexMaster added reviewers: phosek, Ericson2314.
Herald added a subscriber: mgorny.
Herald added a project: All.
VoltrexMaster requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Remove the extra trailing brace from the local variable accessor.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133613

Files:
  clang/cmake/modules/AddClang.cmake


Index: clang/cmake/modules/AddClang.cmake
===
--- clang/cmake/modules/AddClang.cmake
+++ clang/cmake/modules/AddClang.cmake
@@ -70,7 +70,7 @@
 ${CLANG_SOURCE_DIR}/include/clang/${lib_path}/*.td
   )
   source_group("TableGen descriptions" FILES ${tds})
-  set_source_files_properties(${tds}} PROPERTIES HEADER_FILE_ONLY ON)
+  set_source_files_properties(${tds} PROPERTIES HEADER_FILE_ONLY ON)
 
   if(headers OR tds)
 set(srcs ${headers} ${tds})


Index: clang/cmake/modules/AddClang.cmake
===
--- clang/cmake/modules/AddClang.cmake
+++ clang/cmake/modules/AddClang.cmake
@@ -70,7 +70,7 @@
 ${CLANG_SOURCE_DIR}/include/clang/${lib_path}/*.td
   )
   source_group("TableGen descriptions" FILES ${tds})
-  set_source_files_properties(${tds}} PROPERTIES HEADER_FILE_ONLY ON)
+  set_source_files_properties(${tds} PROPERTIES HEADER_FILE_ONLY ON)
 
   if(headers OR tds)
 set(srcs ${headers} ${tds})
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D133611: [clang] sort additional module maps when serializing

2022-09-09 Thread Richard Howell via Phabricator via cfe-commits
rmaz created this revision.
Herald added a subscriber: mgrang.
Herald added a project: All.
rmaz requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Sort additional module maps when serializing pcm files. This ensures
the `MODULE_MAP_FILE` record is deterministic across repeated builds.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133611

Files:
  clang/lib/Serialization/ASTWriter.cpp


Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -1282,7 +1282,11 @@
 if (auto *AdditionalModMaps =
 Map.getAdditionalModuleMapFiles(WritingModule)) {
   Record.push_back(AdditionalModMaps->size());
-  for (const FileEntry *F : *AdditionalModMaps)
+  SmallVector ModMaps(AdditionalModMaps->begin(), 
AdditionalModMaps->end());
+  llvm::sort(ModMaps, [](const FileEntry *A, const FileEntry *B) {
+return A->getName() < B->getName();
+  });
+  for (const FileEntry *F : ModMaps)
 AddPath(F->getName(), Record);
 } else {
   Record.push_back(0);


Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -1282,7 +1282,11 @@
 if (auto *AdditionalModMaps =
 Map.getAdditionalModuleMapFiles(WritingModule)) {
   Record.push_back(AdditionalModMaps->size());
-  for (const FileEntry *F : *AdditionalModMaps)
+  SmallVector ModMaps(AdditionalModMaps->begin(), AdditionalModMaps->end());
+  llvm::sort(ModMaps, [](const FileEntry *A, const FileEntry *B) {
+return A->getName() < B->getName();
+  });
+  for (const FileEntry *F : ModMaps)
 AddPath(F->getName(), Record);
 } else {
   Record.push_back(0);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D133609: [Sema] compat warning of using deduced type in non-type template parameter

2022-09-09 Thread YingChi Long via Phabricator via cfe-commits
inclyc added inline comments.



Comment at: clang/test/SemaCXX/template-nontype-args-compat.cpp:1
+// RUN: %clang_cc1 -fsyntax-only -Wpre-c++20-compat -std=c++20 -verify=cpp20 
%s 
+

I cannot find other tests of compatibility warnings though. Is it necessary to 
add such tests here? (in subsequent patches)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133609

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


[PATCH] D133518: [HLSL] Call global destructors from entries

2022-09-09 Thread Chris Bieneman via Phabricator via cfe-commits
beanz added a comment.

In D133518#3781101 , @aaron.ballman 
wrote:

> This generally LGTM, but to double-check: the behavior if the user does call 
> `atexit()` or or `at_quick_exit()` is that we simply don't call those 
> handlers? As opposed to something worse like we dispatch to the handler and 
> then crash on exit or something like that?

There should be no way to successfully compile and link a shader calling 
`atexit()` or `at_quick_exit()`. Neither of those functions are provided by the 
runtime so it should turn into a compile or linking error somewhere in the 
build process (either missing declaration or missing symbol resolution).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133518

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


[PATCH] D133609: [Sema] compat warning of using deduced type in non-type template parameter

2022-09-09 Thread YingChi Long via Phabricator via cfe-commits
inclyc created this revision.
Herald added a subscriber: kristof.beyls.
Herald added a project: All.
inclyc added reviewers: aaron.ballman, mizvekov, clang-language-wg.
inclyc published this revision for review.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Seems we are missing C++20 compatibility warning of using deduced type
(e.g. some template class) as a non-type template parameter. Before this
patch the following code crashes clang.

  template
  struct DC {};
  
  template // using deduced type, but considered as "auto" type
  auto test() {}

It triggered warn_cxx14_compat_template_nontype_parm_auto_type. However
there is no such "auto" type at all.

Using deduced type within non-type template parameter was introduced in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0732r2.pdf.

This patch create a new compatibility diagnostic message for this.

Fixes: https://github.com/llvm/llvm-project/issues/57643


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133609

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaTemplate.cpp
  clang/test/SemaCXX/template-nontype-args-compat.cpp


Index: clang/test/SemaCXX/template-nontype-args-compat.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/template-nontype-args-compat.cpp
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -fsyntax-only -Wpre-c++20-compat -std=c++20 -verify=cpp20 
%s 
+
+namespace DeducedClass {
+template
+struct DC {};
+
+template // cpp20-warning{{non-type template parameters declared with 
'DC' are incompatible with C++ standards before C++20}}
+auto test() {}
+} // namespace DeducedClass
Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -1532,9 +1532,17 @@
   CheckValidDeclSpecifiers();
 
   if (TInfo->getType()->isUndeducedType()) {
-Diag(D.getIdentifierLoc(),
- diag::warn_cxx14_compat_template_nontype_parm_auto_type)
-  << QualType(TInfo->getType()->getContainedAutoType(), 0);
+if (TInfo->getType()->getContainedAutoType()) {
+  // template
+  Diag(D.getIdentifierLoc(),
+   diag::warn_cxx14_compat_template_nontype_parm_auto_type)
+  << QualType(TInfo->getType()->getContainedAutoType(), 0);
+} else {
+  // template
+  Diag(D.getIdentifierLoc(),
+   diag::warn_cxx17_compat_template_nontype_parm_deduced_class)
+  << TInfo->getType();
+}
   }
 
   assert(S->isTemplateParamScope() &&
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -4833,6 +4833,10 @@
   "non-type template parameter of type %0 is incompatible with "
   "C++ standards before C++20">,
   DefaultIgnore, InGroup;
+def warn_cxx17_compat_template_nontype_parm_deduced_class : Warning<
+  "non-type template parameters declared with %0 are incompatible with C++ "
+  "standards before C++20">,
+  DefaultIgnore, InGroup;
 def warn_cxx14_compat_template_nontype_parm_auto_type : Warning<
   "non-type template parameters declared with %0 are incompatible with C++ "
   "standards before C++17">,
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -95,6 +95,9 @@
   `Issue 57169 `_
 - Clang configuration files are now read through the virtual file system
   rather than the physical one, if these are different.
+- Fix `Issue 57643 `_.
+  Missing C++20 compatibility warning of deduced type as non-type template
+  parameters.
 
 
 Improvements to Clang's diagnostics


Index: clang/test/SemaCXX/template-nontype-args-compat.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/template-nontype-args-compat.cpp
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -fsyntax-only -Wpre-c++20-compat -std=c++20 -verify=cpp20 %s 
+
+namespace DeducedClass {
+template
+struct DC {};
+
+template // cpp20-warning{{non-type template parameters declared with 'DC' are incompatible with C++ standards before C++20}}
+auto test() {}
+} // namespace DeducedClass
Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -1532,9 +1532,17 @@
   CheckValidDeclSpecifiers();
 
   if (TInfo->getType()->isUndeducedType()) {
-Diag(D.getIdentifierLoc(),
- diag::warn_cxx14_compat_template_nontype_parm_auto_type)
-  << QualType(TInfo->getType()->getContainedAutoType(), 0);
+if 

[PATCH] D133194: rewording note note_constexpr_invalid_cast

2022-09-09 Thread Muhammad Usman Shahid via Phabricator via cfe-commits
Codesbyusman updated this revision to Diff 459175.
Codesbyusman added a comment.

updated, I am not getting why this is happening but in the .cpp test file 
without Wvla all is working and is detecting by default as you are saying but 
when I use vla-warning/note it gives me error that "warning seen but not 
expected"


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133194

Files:
  clang/include/clang/Basic/DiagnosticASTKinds.td
  clang/lib/AST/ExprConstant.cpp
  clang/test/Sema/cast.c
  clang/test/SemaCXX/constant-expression-cxx11.cpp

Index: clang/test/SemaCXX/constant-expression-cxx11.cpp
===
--- clang/test/SemaCXX/constant-expression-cxx11.cpp
+++ clang/test/SemaCXX/constant-expression-cxx11.cpp
@@ -2,6 +2,7 @@
 // RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify=expected,cxx11_20,cxx20_2b -triple x86_64-linux -Wno-string-plus-int -Wno-pointer-arith -Wno-zero-length-array -Wno-c99-designator -fcxx-exceptions -pedantic %s -Wno-comment -Wno-tautological-pointer-compare -Wno-bool-conversion
 // RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify=expected,cxx11_20,cxx11-triple x86_64-linux -Wno-string-plus-int -Wno-pointer-arith -Wno-zero-length-array -Wno-c99-designator -fcxx-exceptions -pedantic %s -Wno-comment -Wno-tautological-pointer-compare -Wno-bool-conversion
 
+
 namespace StaticAssertFoldTest {
 
 int x;
@@ -11,6 +12,10 @@
 
 }
 
+int array[(long)(char *)0]; // expected-warning {{variable length arrays are a C99 feature}} \
+// expected-warning {{variable length array folded to constant array as an extension}} \
+// expected-note {{cast that performs the conversions of a reinterpret_cast is not allowed in a constant expression}}
+
 typedef decltype(sizeof(char)) size_t;
 
 template constexpr T id(const T ) { return t; }
@@ -2449,6 +2454,6 @@
 
   constexpr EMaxInt x19 = static_cast(__INT_MAX__-1);
   constexpr EMaxInt x20 = static_cast((long)__INT_MAX__+1); // expected-error {{must be initialized by a constant expression}}
-  // expected-note@-1 {{integer value 2147483648 is outside the valid range of values [-2147483648, 2147483647] for this enumeration type}}
+  // expected-note@-1 {{integer value 2147483648 is outside the valid range of values [-2147483648, 2147483647] for this enumeration type}} 
 }
 }
Index: clang/test/Sema/cast.c
===
--- clang/test/Sema/cast.c
+++ clang/test/Sema/cast.c
@@ -1,4 +1,8 @@
-// RUN: %clang_cc1 -fsyntax-only -triple x86_64-unknown-unknown %s -verify
+// RUN: %clang_cc1 -fsyntax-only -triple x86_64-unknown-unknown %s -verify -Wvla
+
+int array[(long)(char *)0]; // expected-warning {{variable length array used}} \
+// expected-warning {{variable length array folded to constant array as an extension}} \
+// expected-note {{this conversion is not allowed in a constant expression}}
 
 typedef struct { unsigned long bits[(((1) + (64) - 1) / (64))]; } cpumask_t;
 cpumask_t x;
Index: clang/lib/AST/ExprConstant.cpp
===
--- clang/lib/AST/ExprConstant.cpp
+++ clang/lib/AST/ExprConstant.cpp
@@ -7473,7 +7473,8 @@
   }
 
   bool VisitCXXReinterpretCastExpr(const CXXReinterpretCastExpr *E) {
-CCEDiag(E, diag::note_constexpr_invalid_cast) << 0;
+CCEDiag(E, diag::note_constexpr_invalid_cast)
+<< 0 << Info.Ctx.getLangOpts().CPlusPlus;
 return static_cast(this)->VisitCastExpr(E);
   }
   bool VisitCXXDynamicCastExpr(const CXXDynamicCastExpr *E) {
@@ -8179,7 +8180,8 @@
   return LValueExprEvaluatorBaseTy::VisitCastExpr(E);
 
 case CK_LValueBitCast:
-  this->CCEDiag(E, diag::note_constexpr_invalid_cast) << 2;
+  this->CCEDiag(E, diag::note_constexpr_invalid_cast)
+  << 2 << Info.Ctx.getLangOpts().CPlusPlus;
   if (!Visit(E->getSubExpr()))
 return false;
   Result.Designator.setInvalid();
@@ -8890,9 +8892,10 @@
 Result.Designator.setInvalid();
 if (SubExpr->getType()->isVoidPointerType())
   CCEDiag(E, diag::note_constexpr_invalid_cast)
-<< 3 << SubExpr->getType();
+  << 3 << SubExpr->getType();
 else
-  CCEDiag(E, diag::note_constexpr_invalid_cast) << 2;
+  CCEDiag(E, diag::note_constexpr_invalid_cast)
+  << 2 << Info.Ctx.getLangOpts().CPlusPlus;
   }
 }
 if (E->getCastKind() == CK_AddressSpaceConversion && Result.IsNullPtr)
@@ -8929,7 +8932,8 @@
 return ZeroInitialization(E);
 
   case CK_IntegralToPointer: {
-CCEDiag(E, diag::note_constexpr_invalid_cast) << 2;
+CCEDiag(E, diag::note_constexpr_invalid_cast)
+<< 2 << Info.Ctx.getLangOpts().CPlusPlus;
 
 APValue Value;
 if (!EvaluateIntegerOrLValue(SubExpr, Value, 

[PATCH] D133354: [Clang]: Diagnose deprecated copy operations also in MSVC compatibility mode

2022-09-09 Thread Julius via Phabricator via cfe-commits
ningvin added a comment.

That is indeed a better option than to simply copy the test case. I did some 
more digging and found the following test cases which reference the deprecated 
copy warning (all located under clang/test/CXX/):

- deprecated.cpp 

- deprecated-copy.cpp 

- deprecated-copy-with-dtor.cpp 

- deprecated-copy-with-user-provided-copy.cpp 

- deprecated-copy-with-user-provided-dtor.cpp 


I suppose adding the respective RUN lines with `-fms-compatibility` to all of 
them is the way to go. I will try that tomorrow to see if something breaks and 
then update this patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133354

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


[PATCH] D133194: rewording note note_constexpr_invalid_cast

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



Comment at: clang/test/SemaCXX/constant-expression-cxx11.cpp:3
 // RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify=expected,cxx11_20,cxx20_2b 
-triple x86_64-linux -Wno-string-plus-int -Wno-pointer-arith 
-Wno-zero-length-array -Wno-c99-designator -fcxx-exceptions -pedantic %s 
-Wno-comment -Wno-tautological-pointer-compare -Wno-bool-conversion
-// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify=expected,cxx11_20,cxx11
-triple x86_64-linux -Wno-string-plus-int -Wno-pointer-arith 
-Wno-zero-length-array -Wno-c99-designator -fcxx-exceptions -pedantic %s 
-Wno-comment -Wno-tautological-pointer-compare -Wno-bool-conversion
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify=expected,cxx11_20,cxx11
-triple x86_64-linux -Wno-string-plus-int -Wno-pointer-arith 
-Wno-zero-length-array -Wno-c99-designator -fcxx-exceptions -pedantic %s 
-Wno-comment -Wno-tautological-pointer-compare -Wno-bool-conversion -Wvla 
+

Codesbyusman wrote:
> aaron.ballman wrote:
> > aaron.ballman wrote:
> > > We don't need to use `-Wvla` to see the diagnostic change, and this will 
> > > fix the test failures from the other RUN lines not generating the same 
> > > warning about use of a VLA.
> > And this is a better suggestion here.
> Sorry I forget to mention removing here in cpp case -Wvla was working so go 
> with vla or without it?
Let's go with the vla here as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133194

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


[PATCH] D133194: rewording note note_constexpr_invalid_cast

2022-09-09 Thread Muhammad Usman Shahid via Phabricator via cfe-commits
Codesbyusman marked an inline comment as done.
Codesbyusman added inline comments.



Comment at: clang/test/SemaCXX/constant-expression-cxx11.cpp:3
 // RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify=expected,cxx11_20,cxx20_2b 
-triple x86_64-linux -Wno-string-plus-int -Wno-pointer-arith 
-Wno-zero-length-array -Wno-c99-designator -fcxx-exceptions -pedantic %s 
-Wno-comment -Wno-tautological-pointer-compare -Wno-bool-conversion
-// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify=expected,cxx11_20,cxx11
-triple x86_64-linux -Wno-string-plus-int -Wno-pointer-arith 
-Wno-zero-length-array -Wno-c99-designator -fcxx-exceptions -pedantic %s 
-Wno-comment -Wno-tautological-pointer-compare -Wno-bool-conversion
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify=expected,cxx11_20,cxx11
-triple x86_64-linux -Wno-string-plus-int -Wno-pointer-arith 
-Wno-zero-length-array -Wno-c99-designator -fcxx-exceptions -pedantic %s 
-Wno-comment -Wno-tautological-pointer-compare -Wno-bool-conversion -Wvla 
+

aaron.ballman wrote:
> aaron.ballman wrote:
> > We don't need to use `-Wvla` to see the diagnostic change, and this will 
> > fix the test failures from the other RUN lines not generating the same 
> > warning about use of a VLA.
> And this is a better suggestion here.
Sorry I forget to mention removing here in cpp case -Wvla was working so go 
with vla or without it?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133194

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


[PATCH] D133194: rewording note note_constexpr_invalid_cast

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



Comment at: clang/test/Sema/cast.c:1-5
+// RUN: %clang_cc1 -fsyntax-only -triple x86_64-unknown-unknown %s -verify 
-Wvla
+
+int array[(long)(char *)0]; // expected-warning {{variable length array used}} 
\
+// expected-warning {{variable length array folded 
to constant array as an extension}} \
+// expected-note {{this conversion is not allowed 
in a constant expression}}

Codesbyusman wrote:
> aaron.ballman wrote:
> > I realized that we don't need to pass `-Wvla` at all, the other warning and 
> > note are on by default.
> > I realized that we don't need to pass `-Wvla` at all, the other warning and 
> > note are on by default.
> 
> But the note is not enabled without it, without it i got this error:
> that I am expecting but there is no diagnostic for it
> 
> > error: 'note' diagnostics expected but not seen: 
> >   File /home/kali/llvm-project/clang/test/Sema/cast.c Line 3: this 
> > conversion is not allowed in a constant expression
> > 1 error generated.
> 
> 
> 
Oh! I was thinking that the note was associated with the constant folding 
warning, not the "you used a VLA" warning, but you're absolutely right! Ignore 
the suggestion and keep passing -Wvla here.



Comment at: clang/test/SemaCXX/constant-expression-cxx11.cpp:3
 // RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify=expected,cxx11_20,cxx20_2b 
-triple x86_64-linux -Wno-string-plus-int -Wno-pointer-arith 
-Wno-zero-length-array -Wno-c99-designator -fcxx-exceptions -pedantic %s 
-Wno-comment -Wno-tautological-pointer-compare -Wno-bool-conversion
-// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify=expected,cxx11_20,cxx11
-triple x86_64-linux -Wno-string-plus-int -Wno-pointer-arith 
-Wno-zero-length-array -Wno-c99-designator -fcxx-exceptions -pedantic %s 
-Wno-comment -Wno-tautological-pointer-compare -Wno-bool-conversion
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify=expected,cxx11_20,cxx11
-triple x86_64-linux -Wno-string-plus-int -Wno-pointer-arith 
-Wno-zero-length-array -Wno-c99-designator -fcxx-exceptions -pedantic %s 
-Wno-comment -Wno-tautological-pointer-compare -Wno-bool-conversion -Wvla 
+

aaron.ballman wrote:
> We don't need to use `-Wvla` to see the diagnostic change, and this will fix 
> the test failures from the other RUN lines not generating the same warning 
> about use of a VLA.
And this is a better suggestion here.



Comment at: clang/test/SemaCXX/constant-expression-cxx11.cpp:15-17
+int array[(long)(char *)0]; // expected-warning {{variable length arrays are a 
C99 feature}} \
+// expected-warning {{variable length array folded 
to constant array as an extension}} \
+// expected-note {{cast that performs the 
conversions of a reinterpret_cast is not allowed in a constant expression}}

aaron.ballman wrote:
> 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133194

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


[PATCH] D132916: [clang] Explicitly set the EmulatedTLS codegen option

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

In D132916#3781108 , @aaron.ballman 
wrote:

> In D132916#3773791 , @mstorsjo 
> wrote:
>
>> @efriedma Does this look like what you had in mind; does it seem reasonable 
>> to @aaron.ballman?
>
> This seems reasonable to me, but I leave it to @efriedma and @rjmccall for 
> the final sign-off. This looks to be NFC, or have I missed something? (If it 
> is NFC, you should add that to the title, and if it's not NFC, is there test 
> coverage that can be added?)

There's no observable change in upstream llvm-project/clang, but it is a 
functional change for downstreams with other vendor patches applied. So I'm a 
bit undecided whether it should be marked that or not; you're certainly right 
about the point that a patch either is NFC or should have test changes though...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132916

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


[PATCH] D133574: [C2x] reject type definitions in offsetof

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

Thank you for working on this! This approach can work (though I would recommend 
using an RAII object akin to `InMessageExpressionRAIIObject`), but have you 
explored making a new `DeclSpecContext` and modifying 
`isDefiningTypeSpecifierContext()`? I think that would likely be a cleaner 
approach.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133574

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


[PATCH] D133194: rewording note note_constexpr_invalid_cast

2022-09-09 Thread Muhammad Usman Shahid via Phabricator via cfe-commits
Codesbyusman marked 4 inline comments as done.
Codesbyusman added inline comments.



Comment at: clang/test/Sema/cast.c:1-5
+// RUN: %clang_cc1 -fsyntax-only -triple x86_64-unknown-unknown %s -verify 
-Wvla
+
+int array[(long)(char *)0]; // expected-warning {{variable length array used}} 
\
+// expected-warning {{variable length array folded 
to constant array as an extension}} \
+// expected-note {{this conversion is not allowed 
in a constant expression}}

aaron.ballman wrote:
> I realized that we don't need to pass `-Wvla` at all, the other warning and 
> note are on by default.
> I realized that we don't need to pass `-Wvla` at all, the other warning and 
> note are on by default.

But the note is not enabled without it, without it i got this error:
that I am expecting but there is no diagnostic for it

> error: 'note' diagnostics expected but not seen: 
>   File /home/kali/llvm-project/clang/test/Sema/cast.c Line 3: this conversion 
> is not allowed in a constant expression
> 1 error generated.





Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133194

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


[PATCH] D133354: [Clang]: Diagnose deprecated copy operations also in MSVC compatibility mode

2022-09-09 Thread Hans Wennborg via Phabricator via cfe-commits
hans added inline comments.



Comment at: clang/test/SemaCXX/deprecated-copy-msvc.cpp:1
+// RUN: %clang_cc1 %s -std=c++11 %s -Wdeprecated-copy -verify 
-fms-compatibility
+

Can we just add a RUN line with -fms-compatibility to 
clang/test/SemaCXX/deprecated-copy.cpp ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133354

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


[PATCH] D132916: [clang] Explicitly set the EmulatedTLS codegen option

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

In D132916#3773791 , @mstorsjo wrote:

> @efriedma Does this look like what you had in mind; does it seem reasonable 
> to @aaron.ballman?

This seems reasonable to me, but I leave it to @efriedma and @rjmccall for the 
final sign-off. This looks to be NFC, or have I missed something? (If it is 
NFC, you should add that to the title, and if it's not NFC, is there test 
coverage that can be added?)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132916

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


[PATCH] D133518: [HLSL] Call global destructors from entries

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

This generally LGTM, but to double-check: the behavior if the user does call 
`atexit()` or or `at_quick_exit()` is that we simply don't call those handlers? 
As opposed to something worse like we dispatch to the handler and then crash on 
exit or something like that?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133518

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


[PATCH] D133157: Add -fsanitizer-coverage=control-flow

2022-09-09 Thread Navid Emamdoost via Phabricator via cfe-commits
Navidem marked an inline comment as done and an inline comment as not done.
Navidem added inline comments.



Comment at: clang/lib/Driver/SanitizerArgs.cpp:807
 << "-fsanitize-coverage=[func|bb|edge]"
-<< "-fsanitize-coverage=[func|bb|edge],[trace-pc-guard|trace-pc]";
+<< 
"-fsanitize-coverage=[func|bb|edge],[trace-pc-guard|trace-pc|control-flow]";
   }

vitalybuka wrote:
> shouldn't this be:
> ,[trace-pc-guard|trace-pc],[control-flow]
> 
> probably even:
> [,(trace-pc-guard|trace-pc)][,control-flow]
> shouldn't this be:
> ,[trace-pc-guard|trace-pc],[control-flow]
> 
> probably even:
> [,(trace-pc-guard|trace-pc)][,control-flow]




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133157

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


[PATCH] D133157: Add -fsanitizer-coverage=control-flow

2022-09-09 Thread Navid Emamdoost via Phabricator via cfe-commits
Navidem updated this revision to Diff 459157.
Navidem added a comment.

Update doc


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133157

Files:
  clang/docs/SanitizerCoverage.rst
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Basic/CodeGenOptions.h
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/SanitizerArgs.cpp
  llvm/include/llvm/Transforms/Instrumentation.h
  llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
  llvm/test/Instrumentation/SanitizerCoverage/control-flow.ll

Index: llvm/test/Instrumentation/SanitizerCoverage/control-flow.ll
===
--- /dev/null
+++ llvm/test/Instrumentation/SanitizerCoverage/control-flow.ll
@@ -0,0 +1,22 @@
+; Test -sanitizer-coverage-control-flow.
+; RUN: opt < %s -passes='module(sancov-module)' -sanitizer-coverage-level=3 -sanitizer-coverage-control-flow -S | FileCheck %s
+
+target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
+target triple = "x86_64-unknown-linux-gnu"
+define void @foo(ptr %a) sanitize_address {
+entry:
+  %tobool = icmp eq i32* %a, null
+  br i1 %tobool, label %if.end, label %if.then
+
+  if.then:  ; preds = %entry
+  store i32 0, i32* %a, align 4
+  call void @foo(i32* %a)
+  br label %if.end
+
+  if.end:   ; preds = %entry, %if.then
+  ret void
+}
+
+; CHECK: private constant [17 x ptr] [{{.*}}@foo{{.*}}blockaddress{{.*}}blockaddress{{.*}}blockaddress{{.*}}blockaddress{{.*}}blockaddress{{.*}}blockaddress{{.*}}blockaddress{{.*}}@foo{{.*}}null{{.*}}null], section "__sancov_cfs", comdat($foo), align 8
+; CHECK:  @__start___sancov_cfs = extern_weak hidden global
+; CHECK-NEXT: @__stop___sancov_cfs = extern_weak hidden global
Index: llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
===
--- llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
+++ llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
@@ -75,11 +75,13 @@
 const char SanCov8bitCountersInitName[] = "__sanitizer_cov_8bit_counters_init";
 const char SanCovBoolFlagInitName[] = "__sanitizer_cov_bool_flag_init";
 const char SanCovPCsInitName[] = "__sanitizer_cov_pcs_init";
+const char SanCovCFsInitName[] = "__sanitizer_cov_cfs_init";
 
 const char SanCovGuardsSectionName[] = "sancov_guards";
 const char SanCovCountersSectionName[] = "sancov_cntrs";
 const char SanCovBoolFlagSectionName[] = "sancov_bools";
 const char SanCovPCsSectionName[] = "sancov_pcs";
+const char SanCovCFsSectionName[] = "sancov_cfs";
 
 const char SanCovLowestStackName[] = "__sancov_lowest_stack";
 
@@ -147,6 +149,10 @@
   cl::desc("max stack depth tracing"),
   cl::Hidden, cl::init(false));
 
+static cl::opt ClCollectCF("sanitizer-coverage-control-flow",
+  cl::desc("collect control flow for each function"),
+  cl::Hidden, cl::init(false));
+
 namespace {
 
 SanitizerCoverageOptions getOptions(int LegacyCoverageLevel) {
@@ -193,6 +199,7 @@
   !Options.Inline8bitCounters && !Options.StackDepth &&
   !Options.InlineBoolFlag && !Options.TraceLoads && !Options.TraceStores)
 Options.TracePCGuard = true; // TracePCGuard is default.
+  Options.CollectControlFlow |= ClCollectCF;
   return Options;
 }
 
@@ -212,6 +219,7 @@
 PostDomTreeCallback PDTCallback);
 
 private:
+  void createFunctionControlFlow(Function );
   void instrumentFunction(Function , DomTreeCallback DTCallback,
   PostDomTreeCallback PDTCallback);
   void InjectCoverageForIndirectCalls(Function ,
@@ -270,6 +278,7 @@
   GlobalVariable *Function8bitCounterArray;  // for inline-8bit-counters.
   GlobalVariable *FunctionBoolArray; // for inline-bool-flag.
   GlobalVariable *FunctionPCsArray;  // for pc-table.
+  GlobalVariable *FunctionCFsArray;  // for control flow table
   SmallVector GlobalsToAppendToUsed;
   SmallVector GlobalsToAppendToCompilerUsed;
 
@@ -378,6 +387,7 @@
   Function8bitCounterArray = nullptr;
   FunctionBoolArray = nullptr;
   FunctionPCsArray = nullptr;
+  FunctionCFsArray = nullptr;
   IntptrTy = Type::getIntNTy(*C, DL->getPointerSizeInBits());
   IntptrPtrTy = PointerType::getUnqual(IntptrTy);
   Type *VoidTy = Type::getVoidTy(*C);
@@ -502,6 +512,15 @@
 IRBuilder<> IRBCtor(Ctor->getEntryBlock().getTerminator());
 IRBCtor.CreateCall(InitFunction, {SecStartEnd.first, SecStartEnd.second});
   }
+
+  if (Ctor && Options.CollectControlFlow) {
+auto SecStartEnd = CreateSecStartEnd(M, SanCovCFsSectionName, IntptrPtrTy);
+FunctionCallee InitFunction = 

[PATCH] D128958: Add assembler plumbing for sanitize_memtag

2022-09-09 Thread Evgenii Stepanov via Phabricator via cfe-commits
eugenis added inline comments.



Comment at: llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp:713
 
+  if (GV->hasSanitizerMetadata() && GV->isTagged()) {
+Triple T = TM.getTargetTriple();

isTagged() already includes a check for hasSanitizerMetadata()


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128958

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


[PATCH] D133392: [MTE] Add AArch64GlobalsTagging Pass

2022-09-09 Thread Evgenii Stepanov via Phabricator via cfe-commits
eugenis added a comment.

Change description says that the new pass "marks them as tagged". That's not 
what is happening.




Comment at: llvm/lib/CodeGen/GlobalMerge.cpp:657
+// Tagged global variables shouldn't be merged, as they are assigned unique
+// memory tags at runtime.
+if (GV.isTagged())

This comment is not convincing. The change description is right that some 
globals can be merged, copy that here, or extend the comment a little to 
explain why and under what assumptions.



Comment at: llvm/lib/MC/ELFObjectWriter.cpp:1344
+  // when relocating `end` symbols, and this can only be determined by the
+  // attributes of the symbol itself.
+  if (Sym->isMemtag())

Isn't a bigger reason that we need to know the address tag to put on the 
pointer, and that requires a symbol, not a section reference?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133392

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


[PATCH] D132421: [HLSL] Support PCH for cc1 mode

2022-09-09 Thread Xiang Li via Phabricator via cfe-commits
python3kgae marked an inline comment as done.
python3kgae added inline comments.



Comment at: clang/lib/Frontend/FrontendAction.cpp:1036
+// Only add HLSLSema when not in MultiSource.
+if (!MultiSource->HasSource())
+  MultiSource->AddSource(HLSLSema.get());

beanz wrote:
> This seems off. The multi source should always have at least two external 
> sema sources.
> 
> Is there any situation where the HLSL sema would already be added?
Remove. I thought BeginSourceFile would reuse the same ExternalSource.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132421

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


[PATCH] D132421: [HLSL] Support PCH for cc1 mode

2022-09-09 Thread Xiang Li via Phabricator via cfe-commits
python3kgae updated this revision to Diff 459149.
python3kgae added a comment.

Remove useless code since ExternalSource is not be reused when there're more 
than one Input files.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132421

Files:
  clang/include/clang/Sema/HLSLExternalSemaSource.h
  clang/lib/Frontend/FrontendAction.cpp
  clang/lib/Sema/HLSLExternalSemaSource.cpp
  clang/test/AST/HLSL/Inputs/pch.hlsl
  clang/test/AST/HLSL/Inputs/pch_with_buf.hlsl
  clang/test/AST/HLSL/pch.hlsl
  clang/test/AST/HLSL/pch_with_buf.hlsl

Index: clang/test/AST/HLSL/pch_with_buf.hlsl
===
--- /dev/null
+++ clang/test/AST/HLSL/pch_with_buf.hlsl
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.3-library -x hlsl -finclude-default-header -emit-pch -o %t %S/Inputs/pch_with_buf.hlsl
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.3-library -x hlsl \
+// RUN:  -finclude-default-header -include-pch %t -fsyntax-only -ast-dump-all %s | FileCheck  %s
+
+// Make sure PCH works by using function declared in PCH header.
+// CHECK:FunctionDecl 0x[[FOO:[0-9a-f]+]] <{{.*}}:2:1, line:4:1> line:2:8 imported used foo 'float2 (float2, float2)'
+// Make sure buffer defined in PCH works.
+// CHECK:VarDecl 0x{{[0-9a-f]+}}  col:17 imported Buf 'RWBuffer':'hlsl::RWBuffer<>'
+// Make sure declare a RWBuffer in current file works.
+// CHECK:VarDecl 0x{{[0-9a-f]+}} <{{.*}}:11:1, col:23> col:23 Buf2 'hlsl::RWBuffer':'hlsl::RWBuffer<>'
+hlsl::RWBuffer Buf2;
+
+float2 bar(float2 a, float2 b) {
+// CHECK:CallExpr 0x{{[0-9a-f]+}}  'float2':'float __attribute__((ext_vector_type(2)))'
+// CHECK-NEXT:ImplicitCastExpr 0x{{[0-9a-f]+}}  'float2 (*)(float2, float2)' 
+// CHECK-NEXT:`-DeclRefExpr 0x{{[0-9a-f]+}}  'float2 (float2, float2)' lvalue Function 0x[[FOO]] 'foo' 'float2 (float2, float2)'
+  return foo(a, b);
+}
Index: clang/test/AST/HLSL/pch.hlsl
===
--- /dev/null
+++ clang/test/AST/HLSL/pch.hlsl
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.3-library -x hlsl \
+// RUN:  -finclude-default-header -emit-pch -o %t %S/Inputs/pch.hlsl
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.3-library -x hlsl \
+// RUN:  -finclude-default-header -include-pch %t -fsyntax-only -ast-dump-all %s \
+// RUN: | FileCheck  %s
+
+// Make sure PCH works by using function declared in PCH header and declare a RWBuffer in current file.
+// CHECK:FunctionDecl 0x[[FOO:[0-9a-f]+]] <{{.*}}:2:1, line:4:1> line:2:8 imported used foo 'float2 (float2, float2)'
+// CHECK:VarDecl 0x{{[0-9a-f]+}} <{{.*}}:10:1, col:23> col:23 Buffer 'hlsl::RWBuffer':'hlsl::RWBuffer<>'
+hlsl::RWBuffer Buffer;
+
+float2 bar(float2 a, float2 b) {
+// CHECK:CallExpr 0x{{[0-9a-f]+}}  'float2':'float __attribute__((ext_vector_type(2)))'
+// CHECK-NEXT:ImplicitCastExpr 0x{{[0-9a-f]+}}  'float2 (*)(float2, float2)' 
+// CHECK-NEXT:`-DeclRefExpr 0x{{[0-9a-f]+}}  'float2 (float2, float2)' lvalue Function 0x[[FOO]] 'foo' 'float2 (float2, float2)'
+  return foo(a, b);
+}
Index: clang/test/AST/HLSL/Inputs/pch_with_buf.hlsl
===
--- /dev/null
+++ clang/test/AST/HLSL/Inputs/pch_with_buf.hlsl
@@ -0,0 +1,6 @@
+
+float2 foo(float2 a, float2 b) {
+  return a + b;
+}
+
+RWBuffer Buf;
Index: clang/test/AST/HLSL/Inputs/pch.hlsl
===
--- /dev/null
+++ clang/test/AST/HLSL/Inputs/pch.hlsl
@@ -0,0 +1,4 @@
+
+float2 foo(float2 a, float2 b) {
+  return a + b;
+}
Index: clang/lib/Sema/HLSLExternalSemaSource.cpp
===
--- clang/lib/Sema/HLSLExternalSemaSource.cpp
+++ clang/lib/Sema/HLSLExternalSemaSource.cpp
@@ -30,6 +30,7 @@
 struct BuiltinTypeDeclBuilder {
   CXXRecordDecl *Record = nullptr;
   ClassTemplateDecl *Template = nullptr;
+  ClassTemplateDecl *PrevTemplate = nullptr;
   NamespaceDecl *HLSLNamespace = nullptr;
   llvm::StringMap Fields;
 
@@ -43,48 +44,46 @@
 ASTContext  = S.getASTContext();
 IdentifierInfo  = AST.Idents.get(Name, tok::TokenKind::identifier);
 
+LookupResult Result(S, , SourceLocation(), Sema::LookupTagName);
+CXXRecordDecl *PrevDecl = nullptr;
+if (S.LookupQualifiedName(Result, HLSLNamespace)) {
+  NamedDecl *Found = Result.getFoundDecl();
+  if (auto *TD = dyn_cast(Found)) {
+PrevDecl = TD->getTemplatedDecl();
+PrevTemplate = TD;
+  } else
+PrevDecl = dyn_cast(Found);
+  assert(PrevDecl && "Unexpected lookup result type.");
+}
+
+if (PrevDecl && PrevDecl->isCompleteDefinition()) {
+  Record = PrevDecl;
+  return;
+}
+
 Record = CXXRecordDecl::Create(AST, TagDecl::TagKind::TTK_Class,
HLSLNamespace, SourceLocation(),
-   

[PATCH] D133194: rewording note note_constexpr_invalid_cast

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



Comment at: clang/lib/AST/ExprConstant.cpp:7476-7483
+CCEDiag(E, diag::note_constexpr_invalid_cast)
+<< 0 << Info.Ctx.getLangOpts().CPlusPlus;
 return static_cast(this)->VisitCastExpr(E);
   }
   bool VisitCXXDynamicCastExpr(const CXXDynamicCastExpr *E) {
 if (!Info.Ctx.getLangOpts().CPlusPlus20)
+  CCEDiag(E, diag::note_constexpr_invalid_cast)

You shouldn't pass the extra argument to either of these -- `0` maps to 
`reinterpret_cast` and `1` maps to `dynamic_cast` in the `%select{}`, neither 
of which use a `%1` placeholder.



Comment at: clang/lib/AST/ExprConstant.cpp:8896
   CCEDiag(E, diag::note_constexpr_invalid_cast)
-<< 3 << SubExpr->getType();
+  << 3 << SubExpr->getType() << Info.Ctx.getLangOpts().CPlusPlus;
 else

This one should also drop the extra streamed argument for similar reasons as 
above.



Comment at: clang/test/Sema/cast.c:1-5
+// RUN: %clang_cc1 -fsyntax-only -triple x86_64-unknown-unknown %s -verify 
-Wvla
+
+int array[(long)(char *)0]; // expected-warning {{variable length array used}} 
\
+// expected-warning {{variable length array folded 
to constant array as an extension}} \
+// expected-note {{this conversion is not allowed 
in a constant expression}}

I realized that we don't need to pass `-Wvla` at all, the other warning and 
note are on by default.



Comment at: clang/test/SemaCXX/constant-expression-cxx11.cpp:3
 // RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify=expected,cxx11_20,cxx20_2b 
-triple x86_64-linux -Wno-string-plus-int -Wno-pointer-arith 
-Wno-zero-length-array -Wno-c99-designator -fcxx-exceptions -pedantic %s 
-Wno-comment -Wno-tautological-pointer-compare -Wno-bool-conversion
-// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify=expected,cxx11_20,cxx11
-triple x86_64-linux -Wno-string-plus-int -Wno-pointer-arith 
-Wno-zero-length-array -Wno-c99-designator -fcxx-exceptions -pedantic %s 
-Wno-comment -Wno-tautological-pointer-compare -Wno-bool-conversion
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify=expected,cxx11_20,cxx11
-triple x86_64-linux -Wno-string-plus-int -Wno-pointer-arith 
-Wno-zero-length-array -Wno-c99-designator -fcxx-exceptions -pedantic %s 
-Wno-comment -Wno-tautological-pointer-compare -Wno-bool-conversion -Wvla 
+

We don't need to use `-Wvla` to see the diagnostic change, and this will fix 
the test failures from the other RUN lines not generating the same warning 
about use of a VLA.



Comment at: clang/test/SemaCXX/constant-expression-cxx11.cpp:15-17
+int array[(long)(char *)0]; // expected-warning {{variable length arrays are a 
C99 feature}} \
+// expected-warning {{variable length array folded 
to constant array as an extension}} \
+// expected-note {{cast that performs the 
conversions of a reinterpret_cast is not allowed in a constant expression}}




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133194

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


[PATCH] D133066: fix a typo in comment of AddConversionCandidate

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

In D133066#3768091 , @zhouyizhou 
wrote:

> In D133066#3767146 , @aaron.ballman 
> wrote:
>
>> In D133066#3765503 , @zhouyizhou 
>> wrote:
>>
>>> In D133066#3764384 , 
>>> @aaron.ballman wrote:
>>>
 The existing comment is correct according to my copy of the C++11 
 standard, but the standard has changed since C++11 and those words no 
 longer appear in http://eel.is/c++draft/dcl.init.ref#5. Some more 
 investigation is needed, but I suspect the correct action to take here is 
 to update the comment based on the current standards wording or to see if 
 there's a bug because the code does not match the comment.
>>>
>>> thank Aaron for review my patch, 
>>> I am a passionate beginner,
>>
>> Welcome to the community, we're glad to have you here!
>
> Thank Aaron for your encouragement and guidance! Hope I can be some 
> beneficial to the community.
>
>>> this is a very good learning experience for me ;-)  I am looking forward to 
>>> seeing the final change.
>>
>> Happy to help, but to be clear on the next steps: are you planning to do the 
>> investigation work, or were you hoping someone else would do it?
>
> As an amateur, this is a difficult job for me, but I can't help taking a try.

For what it's worth, it's not easy for experts either. :-D

> Following your guidance, I found the original C++11 document on the internet: 
> https://raw.githubusercontent.com/yjlintw/book-Coding-Developer/master/%E6%A0%87%E5%87%86%E6%96%87%E6%A1%A3/ISO%20IEC%2014882%202011%20(C%2B%2B11).pdf
>  
> (the non ASCII code in URL means this document is maintained by a Chinese 
> like me). 
> And those words are there!

Yup, that matches my copy of C++11; btw, you can find a late-stage working 
draft on the committee website at: 
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf

> I am eager to do some investigation work in the elementary stage, but I 
> believe the final work should be done by someone else.
>
> Thanks again for your enthusiasm and your patience!

My pleasure!

For the moment, I don't think any changes are needed here regarding the comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133066

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


[PATCH] D131465: C++/ObjC++: switch to gnu++17 as the default standard

2022-09-09 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

In D131465#3780833 , @AaronLiu wrote:

> In D131465#3780767 , @aaron.ballman 
> wrote:
>
>> In D131465#3780717 , @AaronLiu 
>> wrote:
>>
>>> This cause a large amount failures in our testing with errors such as:
>>>
>>>   error: ISO C++17 does not allow 'register' storage class specifier 
>>> [-Wregister]
>>>
>>>   error: ISO C++17 does not allow dynamic exception specifications 
>>> [-Wdynamic-exception-spec]
>>
>> Sorry to hear that. Who is "our" in this case and do you have a suggestion 
>> for how you'd like to proceed?
>
> Some down stream regression tests.

I don't think this is qualified as a request for revert. Isn't it a matter of 
add -std=gnu++14 to your project?
See my previous comment about a target maintainer's request if your downstream 
project is related to a target which for some reasons want to stick with 
gnu++14.

> I see the above comments:
>
>> I've reverted this change because it causes major llvm-test-suite breakage.
>
> Probably currently this is the best way.
> Thanks!

I disagree. The issue was fixed on llvm-test-suite by pinning projects to 14. 
They previously used the implicit default.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131465

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


[PATCH] D133194: rewording note note_constexpr_invalid_cast

2022-09-09 Thread Muhammad Usman Shahid via Phabricator via cfe-commits
Codesbyusman updated this revision to Diff 459134.
Codesbyusman added a comment.

updating test


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133194

Files:
  clang/include/clang/Basic/DiagnosticASTKinds.td
  clang/lib/AST/ExprConstant.cpp
  clang/test/Sema/cast.c
  clang/test/SemaCXX/constant-expression-cxx11.cpp

Index: clang/test/SemaCXX/constant-expression-cxx11.cpp
===
--- clang/test/SemaCXX/constant-expression-cxx11.cpp
+++ clang/test/SemaCXX/constant-expression-cxx11.cpp
@@ -1,6 +1,7 @@
 // RUN: %clang_cc1 -std=c++2b -fsyntax-only -verify=expected,cxx20_2b,cxx2b-triple x86_64-linux -Wno-string-plus-int -Wno-pointer-arith -Wno-zero-length-array -Wno-c99-designator -fcxx-exceptions -pedantic %s -Wno-comment -Wno-tautological-pointer-compare -Wno-bool-conversion
 // RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify=expected,cxx11_20,cxx20_2b -triple x86_64-linux -Wno-string-plus-int -Wno-pointer-arith -Wno-zero-length-array -Wno-c99-designator -fcxx-exceptions -pedantic %s -Wno-comment -Wno-tautological-pointer-compare -Wno-bool-conversion
-// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify=expected,cxx11_20,cxx11-triple x86_64-linux -Wno-string-plus-int -Wno-pointer-arith -Wno-zero-length-array -Wno-c99-designator -fcxx-exceptions -pedantic %s -Wno-comment -Wno-tautological-pointer-compare -Wno-bool-conversion
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify=expected,cxx11_20,cxx11-triple x86_64-linux -Wno-string-plus-int -Wno-pointer-arith -Wno-zero-length-array -Wno-c99-designator -fcxx-exceptions -pedantic %s -Wno-comment -Wno-tautological-pointer-compare -Wno-bool-conversion -Wvla 
+
 
 namespace StaticAssertFoldTest {
 
@@ -11,6 +12,10 @@
 
 }
 
+int array[(long)(char *)0]; // expected-warning {{variable length arrays are a C99 feature}} \
+// expected-warning {{variable length array folded to constant array as an extension}} \
+// expected-note {{cast that performs the conversions of a reinterpret_cast is not allowed in a constant expression}}
+
 typedef decltype(sizeof(char)) size_t;
 
 template constexpr T id(const T ) { return t; }
@@ -2449,6 +2454,6 @@
 
   constexpr EMaxInt x19 = static_cast(__INT_MAX__-1);
   constexpr EMaxInt x20 = static_cast((long)__INT_MAX__+1); // expected-error {{must be initialized by a constant expression}}
-  // expected-note@-1 {{integer value 2147483648 is outside the valid range of values [-2147483648, 2147483647] for this enumeration type}}
+  // expected-note@-1 {{integer value 2147483648 is outside the valid range of values [-2147483648, 2147483647] for this enumeration type}} 
 }
 }
Index: clang/test/Sema/cast.c
===
--- clang/test/Sema/cast.c
+++ clang/test/Sema/cast.c
@@ -1,4 +1,8 @@
-// RUN: %clang_cc1 -fsyntax-only -triple x86_64-unknown-unknown %s -verify
+// RUN: %clang_cc1 -fsyntax-only -triple x86_64-unknown-unknown %s -verify -Wvla
+
+int array[(long)(char *)0]; // expected-warning {{variable length array used}} \
+// expected-warning {{variable length array folded to constant array as an extension}} \
+// expected-note {{this conversion is not allowed in a constant expression}}
 
 typedef struct { unsigned long bits[(((1) + (64) - 1) / (64))]; } cpumask_t;
 cpumask_t x;
Index: clang/lib/AST/ExprConstant.cpp
===
--- clang/lib/AST/ExprConstant.cpp
+++ clang/lib/AST/ExprConstant.cpp
@@ -7473,12 +7473,14 @@
   }
 
   bool VisitCXXReinterpretCastExpr(const CXXReinterpretCastExpr *E) {
-CCEDiag(E, diag::note_constexpr_invalid_cast) << 0;
+CCEDiag(E, diag::note_constexpr_invalid_cast)
+<< 0 << Info.Ctx.getLangOpts().CPlusPlus;
 return static_cast(this)->VisitCastExpr(E);
   }
   bool VisitCXXDynamicCastExpr(const CXXDynamicCastExpr *E) {
 if (!Info.Ctx.getLangOpts().CPlusPlus20)
-  CCEDiag(E, diag::note_constexpr_invalid_cast) << 1;
+  CCEDiag(E, diag::note_constexpr_invalid_cast)
+  << 1 << Info.Ctx.getLangOpts().CPlusPlus;
 return static_cast(this)->VisitCastExpr(E);
   }
   bool VisitBuiltinBitCastExpr(const BuiltinBitCastExpr *E) {
@@ -8179,7 +8181,8 @@
   return LValueExprEvaluatorBaseTy::VisitCastExpr(E);
 
 case CK_LValueBitCast:
-  this->CCEDiag(E, diag::note_constexpr_invalid_cast) << 2;
+  this->CCEDiag(E, diag::note_constexpr_invalid_cast)
+  << 2 << Info.Ctx.getLangOpts().CPlusPlus;
   if (!Visit(E->getSubExpr()))
 return false;
   Result.Designator.setInvalid();
@@ -8890,9 +8893,10 @@
 Result.Designator.setInvalid();
 if (SubExpr->getType()->isVoidPointerType())
   CCEDiag(E, diag::note_constexpr_invalid_cast)
-<< 3 << 

[PATCH] D132421: [HLSL] Support PCH for cc1 mode

2022-09-09 Thread Chris Bieneman via Phabricator via cfe-commits
beanz added a reviewer: aaron.ballman.
beanz added a subscriber: aaron.ballman.
beanz added a comment.

Looping @aaron.ballman in here too. I think we need some eyes from outside our 
team on this before landing it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132421

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


[PATCH] D133587: Loop names used in reporting can grow very large

2022-09-09 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133587

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


[PATCH] D133194: rewording note note_constexpr_invalid_cast

2022-09-09 Thread Muhammad Usman Shahid via Phabricator via cfe-commits
Codesbyusman added inline comments.



Comment at: clang/test/Sema/cast.c:2
 // RUN: %clang_cc1 -fsyntax-only -triple x86_64-unknown-unknown %s -verify
+// RUN: %clang_cc1 -std=c99 -fsyntax-only -DConstantCast -Wvla -verify %s 
+

aaron.ballman wrote:
> Instead of adding this RUN line, I think you can modify the previous RUN line 
> to add `-Wvla`, and skip the `#ifdef` entirely.
> 
> The reason this test is passing for you locally but failing on the server is 
> because this RUN line is missing a triple and there are parts of the test 
> which are sensitive to the target architecture.
> Instead of adding this RUN line, I think you can modify the previous RUN line 
> to add `-Wvla`, and skip the `#ifdef` entirely.
> 
> The reason this test is passing for you locally but failing on the server is 
> because this RUN line is missing a triple and there are parts of the test 
> which are sensitive to the target architecture.

ok, Thank you


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133194

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


[PATCH] D132421: [HLSL] Support PCH for cc1 mode

2022-09-09 Thread Chris Bieneman via Phabricator via cfe-commits
beanz added inline comments.



Comment at: clang/lib/Frontend/FrontendAction.cpp:1036
+// Only add HLSLSema when not in MultiSource.
+if (!MultiSource->HasSource())
+  MultiSource->AddSource(HLSLSema.get());

This seems off. The multi source should always have at least two external sema 
sources.

Is there any situation where the HLSL sema would already be added?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132421

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


[PATCH] D132952: [Sema] disable -Wvla for function array parameters

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

In D132952#3773469 , @inclyc wrote:

>> Yeah, that's a different way of delineating than I was thinking originally 
>> and it's worth more thought. I was thinking the separation would be "this is 
>> a VLA" (for people who want to avoid all VLA stack allocations due to the 
>> security concerns) and "this is a portability concern" (for people who want 
>> to port to older language standards, C++, other compilers).
>
> I think it is a good idea to separate `-Wvla` into 
> `-Wvla-portability`(warnings on portability) and `-Wvla-stack` (warnings on 
> stack allocations, security issue). Report `-Wvla-portability` if compilers 
> implementations in practice don't support any `vla` syntax especially in C89 
> mode and report `-Wvla-stack` if it causes stack allocations.

This is largely the same conclusion I think I've come to as well. Add two new 
warning groups (we can bikeshed the names later): `-Wvla-portability` and 
`-Wvla-stack-allocation` grouped under the existing `-Wvla`. The behavior of 
`-Wvla` won't change, but users can opt into the kind of specific diagnostic 
they want. `void func(int n, int array[n]);` would trigger `-Wvla-portability` 
but not `-Wvla-stack-allocation`, and `void func(int n) { int array[n]; }` 
would trigger both diagnostics (though we could debate having it skip the 
`-Wvla-portability` warning whenever giving any other "you're using a VLA" kind 
of warning). @efriedma are you on board with that plan as well?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132952

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


[PATCH] D131465: C++/ObjC++: switch to gnu++17 as the default standard

2022-09-09 Thread Aaron H Liu via Phabricator via cfe-commits
AaronLiu added a comment.

In D131465#3780767 , @aaron.ballman 
wrote:

> In D131465#3780717 , @AaronLiu 
> wrote:
>
>> This cause a large amount failures in our testing with errors such as:
>>
>>   error: ISO C++17 does not allow 'register' storage class specifier 
>> [-Wregister]
>>
>>   error: ISO C++17 does not allow dynamic exception specifications 
>> [-Wdynamic-exception-spec]
>
> Sorry to hear that. Who is "our" in this case and do you have a suggestion 
> for how you'd like to proceed?

Some down stream regression tests.
I see the above comments:

> I've reverted this change because it causes major llvm-test-suite breakage.

Probably currently this is the best way.
Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131465

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


[PATCH] D132913: [HLSL] Preserve vec3 for HLSL.

2022-09-09 Thread Xiang Li via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
python3kgae marked an inline comment as done.
Closed by commit rGc9d2b6b92d6c: [HLSL] Preserve vec3 for HLSL. (authored by 
python3kgae).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132913

Files:
  clang/include/clang/Driver/Options.td
  clang/test/CodeGenHLSL/float3.hlsl


Index: clang/test/CodeGenHLSL/float3.hlsl
===
--- /dev/null
+++ clang/test/CodeGenHLSL/float3.hlsl
@@ -0,0 +1,11 @@
+// RUN: %clang --driver-mode=dxc -Tlib_6_7 -fcgl  -Fo - %s | FileCheck %s
+
+// Make sure float3 is not changed into float4.
+// CHECK:<3 x float> @"?foo@@YAT?$__vector@M$02@__clang@@T12@@Z"(<3 x float> 
noundef %a)
+// CHECK:%[[A_ADDR:.+]] = alloca <3 x float>, align 16
+// CHECK-NEXT:store <3 x float> %a, ptr %[[A_ADDR]], align 16
+// CHECK-NEXT:%[[V:[0-9]+]] = load <3 x float>, ptr %[[A_ADDR]], align 16
+// CHECK-NEXT:ret <3 x float> %[[V]]
+float3 foo(float3 a) {
+  return a;
+}
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -6170,7 +6170,8 @@
 
 def fpreserve_vec3_type : Flag<["-"], "fpreserve-vec3-type">,
   HelpText<"Preserve 3-component vector type">,
-  MarshallingInfoFlag>;
+  MarshallingInfoFlag>,
+  ImpliedByAnyOf<[hlsl.KeyPath]>;
 def fwchar_type_EQ : Joined<["-"], "fwchar-type=">,
   HelpText<"Select underlying type for wchar_t">,
   Values<"char,short,int">,


Index: clang/test/CodeGenHLSL/float3.hlsl
===
--- /dev/null
+++ clang/test/CodeGenHLSL/float3.hlsl
@@ -0,0 +1,11 @@
+// RUN: %clang --driver-mode=dxc -Tlib_6_7 -fcgl  -Fo - %s | FileCheck %s
+
+// Make sure float3 is not changed into float4.
+// CHECK:<3 x float> @"?foo@@YAT?$__vector@M$02@__clang@@T12@@Z"(<3 x float> noundef %a)
+// CHECK:%[[A_ADDR:.+]] = alloca <3 x float>, align 16
+// CHECK-NEXT:store <3 x float> %a, ptr %[[A_ADDR]], align 16
+// CHECK-NEXT:%[[V:[0-9]+]] = load <3 x float>, ptr %[[A_ADDR]], align 16
+// CHECK-NEXT:ret <3 x float> %[[V]]
+float3 foo(float3 a) {
+  return a;
+}
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -6170,7 +6170,8 @@
 
 def fpreserve_vec3_type : Flag<["-"], "fpreserve-vec3-type">,
   HelpText<"Preserve 3-component vector type">,
-  MarshallingInfoFlag>;
+  MarshallingInfoFlag>,
+  ImpliedByAnyOf<[hlsl.KeyPath]>;
 def fwchar_type_EQ : Joined<["-"], "fwchar-type=">,
   HelpText<"Select underlying type for wchar_t">,
   Values<"char,short,int">,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] c9d2b6b - [HLSL] Preserve vec3 for HLSL.

2022-09-09 Thread Xiang Li via cfe-commits

Author: Xiang Li
Date: 2022-09-09T10:55:45-07:00
New Revision: c9d2b6b92d6c29d00f6adc0527cf2331dbaae31a

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

LOG: [HLSL] Preserve vec3 for HLSL.

Preserve vec3 for HLSL by set -fpreserve-vec3-type.

Reviewed By: beanz

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

Added: 
clang/test/CodeGenHLSL/float3.hlsl

Modified: 
clang/include/clang/Driver/Options.td

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index b9be33396fdfe..d6a4ad40f5020 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -6170,7 +6170,8 @@ def fdeclare_opencl_builtins : Flag<["-"], 
"fdeclare-opencl-builtins">,
 
 def fpreserve_vec3_type : Flag<["-"], "fpreserve-vec3-type">,
   HelpText<"Preserve 3-component vector type">,
-  MarshallingInfoFlag>;
+  MarshallingInfoFlag>,
+  ImpliedByAnyOf<[hlsl.KeyPath]>;
 def fwchar_type_EQ : Joined<["-"], "fwchar-type=">,
   HelpText<"Select underlying type for wchar_t">,
   Values<"char,short,int">,

diff  --git a/clang/test/CodeGenHLSL/float3.hlsl 
b/clang/test/CodeGenHLSL/float3.hlsl
new file mode 100644
index 0..6ee43157cecec
--- /dev/null
+++ b/clang/test/CodeGenHLSL/float3.hlsl
@@ -0,0 +1,11 @@
+// RUN: %clang --driver-mode=dxc -Tlib_6_7 -fcgl  -Fo - %s | FileCheck %s
+
+// Make sure float3 is not changed into float4.
+// CHECK:<3 x float> @"?foo@@YAT?$__vector@M$02@__clang@@T12@@Z"(<3 x float> 
noundef %a)
+// CHECK:%[[A_ADDR:.+]] = alloca <3 x float>, align 16
+// CHECK-NEXT:store <3 x float> %a, ptr %[[A_ADDR]], align 16
+// CHECK-NEXT:%[[V:[0-9]+]] = load <3 x float>, ptr %[[A_ADDR]], align 16
+// CHECK-NEXT:ret <3 x float> %[[V]]
+float3 foo(float3 a) {
+  return a;
+}



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


[PATCH] D132913: [HLSL] Preserve vec3 for HLSL.

2022-09-09 Thread Chris Bieneman via Phabricator via cfe-commits
beanz accepted this revision.
beanz added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132913

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


[PATCH] D131465: C++/ObjC++: switch to gnu++17 as the default standard

2022-09-09 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

In D131465#3776841 , @nikic wrote:

> In D131465#3776599 , @nikic wrote:
>
>> It looks like the switch to `-std=c++17` has some major compile-time impact: 
>> http://llvm-compile-time-tracker.com/compare.php?from=047c7aa96dadf8a2c71a29e2df610d628d9e7e3e=3e99b8d947ac024831e59be2b604ac67a24fed94=instructions
>>  The `O0` build of 7zip becomes 80% slower (without codegen changes).
>
> I suspect this is due to increased STL size in in C++17. Taking one sample 
> file, preprocessed source is 289149 bytes with `-std=gnu++14` and 654888 with 
> `-std=gnu++17`. The source size increased by more than a factor of two, so 
> it's not very surprising that the parsing time also increased by the same 
> factor.

Thanks for the analysis. C++'s fault then...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131465

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


[PATCH] D129883: [HLSL] Support cbuffer/tbuffer for hlsl.

2022-09-09 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129883

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


[PATCH] D133570: Clang codegen, fixes issue with emitting partially initialized constant arrays larger than 2^32

2022-09-09 Thread Ofek Shochat via Phabricator via cfe-commits
OfekShochat added a subscriber: eli.friedman.
OfekShochat added a comment.

yep @eli.friedman. probably gonna scratch this idea, makes more sense to 
actually tackle the problem itself, which is that getArrayFiller doesnt return 
anything. trying to actually get to the problem, but its quite hard, Visit's 
are thrown everywhere, and I cant really look at the problem. 
tryEmitPrivateForVarInit is called, and then it calls a Visit, which somehow 
transfers it to VisitInitListExpr. that thing worked just because it worked 
around that problem, even if not intentionally


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133570

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


[PATCH] D133587: Loop names used in reporting can grow very large

2022-09-09 Thread Jamie Schmeiser 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 rG5e3ac7969039: Loop names used in reporting can grow very 
large (authored by jamieschmeiser).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133587

Files:
  clang/test/CodeGen/thinlto-distributed-newpm.ll
  llvm/lib/Passes/StandardInstrumentations.cpp
  llvm/test/Other/loop-pass-ordering.ll
  llvm/test/Other/loop-pass-printer.ll
  llvm/test/Other/loopnest-pass-ordering.ll
  llvm/test/Other/new-pm-lto-defaults.ll
  llvm/test/Other/new-pm-thinlto-defaults.ll
  llvm/test/Other/pass-pipeline-parsing.ll
  llvm/test/Other/print-before-after.ll
  llvm/test/Transforms/LoopPredication/invalidate-analyses.ll
  llvm/test/Transforms/LoopPredication/preserve-bpi.ll
  llvm/test/Transforms/LoopRotate/pr35210.ll
  llvm/test/Transforms/LoopUnroll/revisit.ll
  llvm/test/Transforms/LoopUnroll/unroll-loop-invalidation.ll
  
llvm/test/Transforms/SimpleLoopUnswitch/nontrivial-unswitch-markloopasdeleted.ll

Index: llvm/test/Transforms/SimpleLoopUnswitch/nontrivial-unswitch-markloopasdeleted.ll
===
--- llvm/test/Transforms/SimpleLoopUnswitch/nontrivial-unswitch-markloopasdeleted.ll
+++ llvm/test/Transforms/SimpleLoopUnswitch/nontrivial-unswitch-markloopasdeleted.ll
@@ -4,7 +4,7 @@
 ; Running loop-distribute will result in LoopAccessAnalysis being required and
 ; cached in the LoopAnalysisManagerFunctionProxy.
 ;
-; CHECK: Running analysis: LoopAccessAnalysis on Loop at depth 2 containing: %loop_a_inner
+; CHECK: Running analysis: LoopAccessAnalysis on loop_a_inner
 
 
 ; Then simple-loop-unswitch is removing/replacing some loops (resulting in
@@ -17,7 +17,7 @@
 ; SimpleLoopUnswitch not marking the Loop as removed, so we missed clearing
 ; the analysis caches.
 ;
-; CHECK: Running pass: SimpleLoopUnswitchPass on Loop at depth 1 containing: %loop_begin,%loop_b,%loop_b_inner,%loop_b_inner_exit,%loop_a,%loop_a_inner,%loop_a_inner_exit,%latch
+; CHECK: Running pass: SimpleLoopUnswitchPass on loop_begin
 ; CHECK-NEXT: Running analysis: OuterAnalysisManagerProxy
 ; CHECK-NEXT: Clearing all analysis results for: loop_a_inner
 
@@ -27,7 +27,7 @@
 ; loop_a_inner.us). This kind of verifies that it was correct to remove the
 ; loop_a_inner related analysis above.
 ;
-; CHECK: Running analysis: LoopAccessAnalysis on Loop at depth 2 containing: %loop_a_inner.us
+; CHECK: Running analysis: LoopAccessAnalysis on loop_a_inner.us
 
 
 define i32 @test6(i1* %ptr, i1 %cond1, i32* %a.ptr, i32* %b.ptr) {
Index: llvm/test/Transforms/LoopUnroll/unroll-loop-invalidation.ll
===
--- llvm/test/Transforms/LoopUnroll/unroll-loop-invalidation.ll
+++ llvm/test/Transforms/LoopUnroll/unroll-loop-invalidation.ll
@@ -8,22 +8,22 @@
 ; CHECK: Running analysis: LoopAnalysis
 ; CHECK: Running analysis: InnerAnalysisManagerProxy<
 ; CHECK: Running pass: RequireAnalysisPass<{{.*}}LoopAccessAnalysis
-; CHECK: Running analysis: LoopAccessAnalysis on Loop at depth 2 containing: %inner1.header
+; CHECK: Running analysis: LoopAccessAnalysis on inner1.header
 ; CHECK: Running pass: RequireAnalysisPass<{{.*}}LoopAccessAnalysis
-; CHECK: Running analysis: LoopAccessAnalysis on Loop at depth 2 containing: %inner2.header
+; CHECK: Running analysis: LoopAccessAnalysis on inner2.header
 ; CHECK: Running pass: RequireAnalysisPass<{{.*}}LoopAccessAnalysis
-; CHECK: Running analysis: LoopAccessAnalysis on Loop at depth 1 containing: %outer.header
+; CHECK: Running analysis: LoopAccessAnalysis on outer.header
 ; CHECK: Running pass: LoopUnrollPass
 ; CHECK: Clearing all analysis results for: inner2.header
 ; CHECK: Clearing all analysis results for: outer.header
 ; CHECK: Invalidating analysis: LoopAccessAnalysis on {{.*}}inner1.header
 ; CHECK-NOT: Invalidating analysis: LoopAccessAnalysis on {{.*}}inner1.header.1
 ; CHECK: Running pass: LoopAccessInfoPrinterPass
-; CHECK: Running analysis: LoopAccessAnalysis on Loop at depth 1 containing: %inner1.header
+; CHECK: Running analysis: LoopAccessAnalysis on inner1.header
 ; CHECK: Loop access info in function 'test':
 ; CHECK:   inner1.header:
 ; CHECK: Running pass: LoopAccessInfoPrinterPass
-; CHECK: Running analysis: LoopAccessAnalysis on Loop at depth 1 containing: %inner1.header.1
+; CHECK: Running analysis: LoopAccessAnalysis on inner1.header.1
 ; CHECK: Loop access info in function 'test':
 ; CHECK:   inner1.header.1:
 
Index: llvm/test/Transforms/LoopUnroll/revisit.ll
===
--- llvm/test/Transforms/LoopUnroll/revisit.ll
+++ llvm/test/Transforms/LoopUnroll/revisit.ll
@@ -39,7 +39,7 @@
 l0.0.0:
   %cond.0.0.0 = load volatile i1, i1* %ptr
   br i1 %cond.0.0.0, label %l0.0.0, label %l0.0.1.ph
-; CHECK: 

[clang] 5e3ac79 - Loop names used in reporting can grow very large

2022-09-09 Thread Jamie Schmeiser via cfe-commits

Author: Jamie Schmeiser
Date: 2022-09-09T13:45:14-04:00
New Revision: 5e3ac7969039678fc017a5599b051ea2b78075a4

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

LOG: Loop names used in reporting can grow very large

Summary:
The code for generating a name for loops for various reporting scenarios
created a name by serializing the loop into a string.  This may result in
a very large name for a loop containing many blocks.  Use the getName()
function on the loop instead.

Author: Jamie Schmeiser 
Reviewed By: Whitney (Whitney Tsang), aeubanks (Arthur Eubanks)
Differential Revision: https://reviews.llvm.org/D133587

Added: 


Modified: 
clang/test/CodeGen/thinlto-distributed-newpm.ll
llvm/lib/Passes/StandardInstrumentations.cpp
llvm/test/Other/loop-pass-ordering.ll
llvm/test/Other/loop-pass-printer.ll
llvm/test/Other/loopnest-pass-ordering.ll
llvm/test/Other/new-pm-lto-defaults.ll
llvm/test/Other/new-pm-thinlto-defaults.ll
llvm/test/Other/pass-pipeline-parsing.ll
llvm/test/Other/print-before-after.ll
llvm/test/Transforms/LoopPredication/invalidate-analyses.ll
llvm/test/Transforms/LoopPredication/preserve-bpi.ll
llvm/test/Transforms/LoopRotate/pr35210.ll
llvm/test/Transforms/LoopUnroll/revisit.ll
llvm/test/Transforms/LoopUnroll/unroll-loop-invalidation.ll

llvm/test/Transforms/SimpleLoopUnswitch/nontrivial-unswitch-markloopasdeleted.ll

Removed: 




diff  --git a/clang/test/CodeGen/thinlto-distributed-newpm.ll 
b/clang/test/CodeGen/thinlto-distributed-newpm.ll
index 463fc522c6a28..3dbc55e23e28d 100644
--- a/clang/test/CodeGen/thinlto-distributed-newpm.ll
+++ b/clang/test/CodeGen/thinlto-distributed-newpm.ll
@@ -83,7 +83,7 @@
 ; CHECK-O: Running pass: LowerConstantIntrinsicsPass on main
 ; CHECK-O: Running pass: LoopSimplifyPass on main
 ; CHECK-O: Running pass: LCSSAPass on main
-; CHECK-O: Running pass: LoopRotatePass on Loop at depth 1 containing: %b
+; CHECK-O: Running pass: LoopRotatePass on b
 ; CHECK-O: Running pass: LoopDistributePass on main
 ; CHECK-O: Running pass: InjectTLIMappings on main
 ; CHECK-O: Running pass: LoopVectorizePass on main
@@ -99,7 +99,7 @@
 ; CHECK-O: Running pass: 
RequireAnalysisPass<{{.*}}OptimizationRemarkEmitterAnalysis
 ; CHECK-O: Running pass: LoopSimplifyPass on main
 ; CHECK-O: Running pass: LCSSAPass on main
-; CHECK-O: Running pass: LICMPass on Loop at depth 1 containing: %b
+; CHECK-O: Running pass: LICMPass on b
 ; CHECK-O: Running pass: AlignmentFromAssumptionsPass on main
 ; CHECK-O: Running pass: LoopSinkPass on main
 ; CHECK-O: Running pass: InstSimplifyPass on main

diff  --git a/llvm/lib/Passes/StandardInstrumentations.cpp 
b/llvm/lib/Passes/StandardInstrumentations.cpp
index 861e76b38f66b..1ac557d975cec 100644
--- a/llvm/lib/Passes/StandardInstrumentations.cpp
+++ b/llvm/lib/Passes/StandardInstrumentations.cpp
@@ -188,10 +188,7 @@ std::string getIRName(Any IR) {
 
   if (any_isa(IR)) {
 const Loop *L = any_cast(IR);
-std::string S;
-raw_string_ostream OS(S);
-L->print(OS, /*Verbose*/ false, /*PrintNested*/ false);
-return OS.str();
+return L->getName().str();
   }
 
   llvm_unreachable("Unknown wrapped IR type");

diff  --git a/llvm/test/Other/loop-pass-ordering.ll 
b/llvm/test/Other/loop-pass-ordering.ll
index ab3839f5cc997..fde49a7b73a5f 100644
--- a/llvm/test/Other/loop-pass-ordering.ll
+++ b/llvm/test/Other/loop-pass-ordering.ll
@@ -8,11 +8,11 @@
 ;  /  \\
 ; loop.0.0  loop.0.1  loop.1.0
 ;
-; CHECK: Running pass: NoOpLoopPass on Loop at depth 2 containing: %loop.0.0
-; CHECK: Running pass: NoOpLoopPass on Loop at depth 2 containing: %loop.0.1
-; CHECK: Running pass: NoOpLoopPass on Loop at depth 1 containing: %loop.0
-; CHECK: Running pass: NoOpLoopPass on Loop at depth 2 containing: %loop.1.0
-; CHECK: Running pass: NoOpLoopPass on Loop at depth 1 containing: %loop.1
+; CHECK: Running pass: NoOpLoopPass on loop.0.0
+; CHECK: Running pass: NoOpLoopPass on loop.0.1
+; CHECK: Running pass: NoOpLoopPass on loop.0
+; CHECK: Running pass: NoOpLoopPass on loop.1.0
+; CHECK: Running pass: NoOpLoopPass on loop.1
 
 define void @f() {
 entry:

diff  --git a/llvm/test/Other/loop-pass-printer.ll 
b/llvm/test/Other/loop-pass-printer.ll
index 98ad72b142bca..60bfdbbaea9ef 100644
--- a/llvm/test/Other/loop-pass-printer.ll
+++ b/llvm/test/Other/loop-pass-printer.ll
@@ -35,7 +35,7 @@
 ; BAR: ; Exit blocks
 ; BAR:  end:
 
-; FOO-MODULE: IR Dump After {{Unroll|LoopFullUnrollPass}} {{.*}}%loop
+; FOO-MODULE: IR Dump After {{Unroll|LoopFullUnrollPass}} {{.*}}loop
 ; FOO-MODULE-NEXT: ModuleID =
 ; FOO-MODULE: define void @foo
 ; FOO-MODULE: define void @bar

diff  --git a/llvm/test/Other/loopnest-pass-ordering.ll 

[PATCH] D131465: C++/ObjC++: switch to gnu++17 as the default standard

2022-09-09 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

In D131465#3780717 , @AaronLiu wrote:

> This cause a large amount failures in our testing with errors such as:
>
>   error: ISO C++17 does not allow 'register' storage class specifier 
> [-Wregister]
>
>   error: ISO C++17 does not allow dynamic exception specifications 
> [-Wdynamic-exception-spec]

You may want to `-std=gnu++14` or `-std=c++14` to pin your projects to C++14, 
instead of relying on the Clang default.
Is your case is like PlayStation 4 and 5 where a platform wants to have a 
different default (I'd hope that we can try avoiding such differences), a 
target maintainer can weigh in and perhaps change it.
(The configuration file discussions are interesting, too 
https://discourse.llvm.org/t/configuration-files/42529 
https://discourse.llvm.org/t/rfc-adding-a-default-file-location-to-config-file-support/63606)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131465

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


[PATCH] D133194: rewording note note_constexpr_invalid_cast

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



Comment at: clang/test/Sema/cast.c:2
 // RUN: %clang_cc1 -fsyntax-only -triple x86_64-unknown-unknown %s -verify
+// RUN: %clang_cc1 -std=c99 -fsyntax-only -DConstantCast -Wvla -verify %s 
+

Instead of adding this RUN line, I think you can modify the previous RUN line 
to add `-Wvla`, and skip the `#ifdef` entirely.

The reason this test is passing for you locally but failing on the server is 
because this RUN line is missing a triple and there are parts of the test which 
are sensitive to the target architecture.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133194

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


[PATCH] D133570: Clang codegen, fixes issue with emitting partially initialized constant arrays larger than 2^32

2022-09-09 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added inline comments.



Comment at: clang/lib/CodeGen/CGExprConstant.cpp:1225
 assert(CAT && "can't emit array init for non-constant-bound array");
-unsigned NumInitElements = ILE->getNumInits();
-unsigned NumElements = CAT->getSize().getZExtValue();
+uint64_t NumInitElements = ILE->getNumInits();
+uint64_t NumElements = CAT->getSize().getZExtValue();

Note that getNumInits() itself is returning "unsigned".  (Looks easy to fix, 
though.)



Comment at: clang/lib/CodeGen/CGExprConstant.cpp:1265
+
+Inits.push_back(llvm::ConstantAggregateZero::get(FillerType));
+

Need to be careful here: in general, you can't just fill everything with zero.  
Need to check how getArrayFiller() is lowered.  (For example, consider `class 
X; int X::*a[10] = { 0 };`.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133570

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


[PATCH] D130270: [clang][dataflow] Use a dedicated bool to encode which branch was taken

2022-09-09 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel added a comment.

In D130270#3780705 , @samestep wrote:

> @ymandel Huh, interesting! I'll go ahead and abandon this patch, then?

Please. Sorry I didn't catch this earlier!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130270

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


[PATCH] D133194: rewording note note_constexpr_invalid_cast

2022-09-09 Thread Muhammad Usman Shahid via Phabricator via cfe-commits
Codesbyusman updated this revision to Diff 459121.
Codesbyusman added a comment.

updating one time again, to again run test as no failed test on my system.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133194

Files:
  clang/include/clang/Basic/DiagnosticASTKinds.td
  clang/lib/AST/ExprConstant.cpp
  clang/test/Sema/cast.c
  clang/test/SemaCXX/constant-expression-cxx11.cpp

Index: clang/test/SemaCXX/constant-expression-cxx11.cpp
===
--- clang/test/SemaCXX/constant-expression-cxx11.cpp
+++ clang/test/SemaCXX/constant-expression-cxx11.cpp
@@ -1,6 +1,7 @@
 // RUN: %clang_cc1 -std=c++2b -fsyntax-only -verify=expected,cxx20_2b,cxx2b-triple x86_64-linux -Wno-string-plus-int -Wno-pointer-arith -Wno-zero-length-array -Wno-c99-designator -fcxx-exceptions -pedantic %s -Wno-comment -Wno-tautological-pointer-compare -Wno-bool-conversion
 // RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify=expected,cxx11_20,cxx20_2b -triple x86_64-linux -Wno-string-plus-int -Wno-pointer-arith -Wno-zero-length-array -Wno-c99-designator -fcxx-exceptions -pedantic %s -Wno-comment -Wno-tautological-pointer-compare -Wno-bool-conversion
-// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify=expected,cxx11_20,cxx11-triple x86_64-linux -Wno-string-plus-int -Wno-pointer-arith -Wno-zero-length-array -Wno-c99-designator -fcxx-exceptions -pedantic %s -Wno-comment -Wno-tautological-pointer-compare -Wno-bool-conversion
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify=expected,cxx11_20,cxx11-triple x86_64-linux -Wno-string-plus-int -Wno-pointer-arith -Wno-zero-length-array -Wno-c99-designator -fcxx-exceptions -pedantic %s -Wno-comment -Wno-tautological-pointer-compare -Wno-bool-conversion -Wvla 
+
 
 namespace StaticAssertFoldTest {
 
@@ -11,6 +12,10 @@
 
 }
 
+int array[(long)(char *)0]; // expected-warning {{variable length arrays are a C99 feature}} \
+// expected-warning {{variable length array folded to constant array as an extension}} \
+// expected-note {{cast that performs the conversions of a reinterpret_cast is not allowed in a constant expression}}
+
 typedef decltype(sizeof(char)) size_t;
 
 template constexpr T id(const T ) { return t; }
@@ -2449,6 +2454,6 @@
 
   constexpr EMaxInt x19 = static_cast(__INT_MAX__-1);
   constexpr EMaxInt x20 = static_cast((long)__INT_MAX__+1); // expected-error {{must be initialized by a constant expression}}
-  // expected-note@-1 {{integer value 2147483648 is outside the valid range of values [-2147483648, 2147483647] for this enumeration type}}
+  // expected-note@-1 {{integer value 2147483648 is outside the valid range of values [-2147483648, 2147483647] for this enumeration type}} 
 }
 }
Index: clang/test/Sema/cast.c
===
--- clang/test/Sema/cast.c
+++ clang/test/Sema/cast.c
@@ -1,4 +1,11 @@
 // RUN: %clang_cc1 -fsyntax-only -triple x86_64-unknown-unknown %s -verify
+// RUN: %clang_cc1 -std=c99 -fsyntax-only -DConstantCast -Wvla -verify %s 
+
+#ifdef ConstantCast
+int array[(long)(char *)0]; // expected-warning {{variable length array used}} \
+// expected-warning {{variable length array folded to constant array as an extension}} \
+// expected-note {{this conversion is not allowed in a constant expression}}
+#endif
 
 typedef struct { unsigned long bits[(((1) + (64) - 1) / (64))]; } cpumask_t;
 cpumask_t x;
Index: clang/lib/AST/ExprConstant.cpp
===
--- clang/lib/AST/ExprConstant.cpp
+++ clang/lib/AST/ExprConstant.cpp
@@ -7473,12 +7473,14 @@
   }
 
   bool VisitCXXReinterpretCastExpr(const CXXReinterpretCastExpr *E) {
-CCEDiag(E, diag::note_constexpr_invalid_cast) << 0;
+CCEDiag(E, diag::note_constexpr_invalid_cast)
+<< 0 << Info.Ctx.getLangOpts().CPlusPlus;
 return static_cast(this)->VisitCastExpr(E);
   }
   bool VisitCXXDynamicCastExpr(const CXXDynamicCastExpr *E) {
 if (!Info.Ctx.getLangOpts().CPlusPlus20)
-  CCEDiag(E, diag::note_constexpr_invalid_cast) << 1;
+  CCEDiag(E, diag::note_constexpr_invalid_cast)
+  << 1 << Info.Ctx.getLangOpts().CPlusPlus;
 return static_cast(this)->VisitCastExpr(E);
   }
   bool VisitBuiltinBitCastExpr(const BuiltinBitCastExpr *E) {
@@ -8179,7 +8181,8 @@
   return LValueExprEvaluatorBaseTy::VisitCastExpr(E);
 
 case CK_LValueBitCast:
-  this->CCEDiag(E, diag::note_constexpr_invalid_cast) << 2;
+  this->CCEDiag(E, diag::note_constexpr_invalid_cast)
+  << 2 << Info.Ctx.getLangOpts().CPlusPlus;
   if (!Visit(E->getSubExpr()))
 return false;
   Result.Designator.setInvalid();
@@ -8890,9 +8893,10 @@
 Result.Designator.setInvalid();
 if 

[PATCH] D133578: [OpenMP] Add generation of SIMD align assumptions to OMPIRBuilder

2022-09-09 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added a comment.

Thanks for this patch! I have two drive by comments that should probably be 
addressed first.




Comment at: llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h:629
+ llvm::ArrayRef AlignedVars,
+ llvm::Value *Alignment, Value *IfCond, ConstantInt *Simdlen,
  ConstantInt *Safelen);

Aren't there different alignments possible, so X is aligned 32 and Y is aligned 
64? If so, should we tie the Value and Alignment together in the API?



Comment at: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:2976
 
+  const int DefaultAlignment = 16;
+

This doesn't work. Use the data layout for any default values please.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133578

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


[PATCH] D133499: [clang]: Add DeclContext::dumpDecl() in order to conveniently dump an AST from a DeclContext.

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



Comment at: clang/lib/AST/ASTDumper.cpp:205
+  if (const Decl *D = dyn_cast(this))
+D->dump();
+}

shafik wrote:
> aaron.ballman wrote:
> > shafik wrote:
> > > aaron.ballman wrote:
> > > > erichkeane wrote:
> > > > > aaron.ballman wrote:
> > > > > > erichkeane wrote:
> > > > > > > One thing to note is that the 'else' case here is a little 
> > > > > > > uninformative.  See 
> > > > > > > https://clang.llvm.org/doxygen/DeclBase_8cpp_source.html#l00915 
> > > > > > > for some similar logic here (though not sure we should be 
> > > > > > > emulating that).
> > > > > > > 
> > > > > > > More, I wonder if there is SOME message here that should be 
> > > > > > > dumped for 'else'.
> > > > > > Looking at what inherits from `DeclContext`, is there use of it 
> > > > > > which is *not* a `Decl`? I couldn't find a use where it's not also 
> > > > > > a `Decl`.
> > > > > I've DEFINITELY run into it in the debugger before, but I have no 
> > > > > idea WHAT case that is. It is sometimes just "DeclContext is an 
> > > > > invalid pointer" kinda thing, so it might be worth-while to have SOME 
> > > > > output besides "print nothing", particularly when debugging.
> > > > IIRC, the case this comes up in is when the object is only partially 
> > > > constructed, and so I agree that having an `else` clause here would be 
> > > > useful -- because this interface is predominately used from a debugger, 
> > > > it has to deal with special "impossible" situations a bit more 
> > > > carefully.
> > > So looking at the other dump member functions, all of them seem to assume 
> > > we have a valid `DeclContext` and so they do not have any else either.
> > > 
> > > So maybe we want to think about making the rest a bit smarter as well?
> > > So maybe we want to think about making the rest a bit smarter as well?
> > 
> > What do you have in mind?
> > 
> > I think it's plausible to be in a partially constructed state in terms of 
> > when ctors are called, but I'm far less worried about people calling a dump 
> > method in the middle of the member inits happening.
> > > So maybe we want to think about making the rest a bit smarter as well?
> > 
> > What do you have in mind?
> > 
> > I think it's plausible to be in a partially constructed state in terms of 
> > when ctors are called, but I'm far less worried about people calling a dump 
> > method in the middle of the member inits happening.
> 
> Apologies, what I meant was if we are going to add an `else` here then we 
> should be consistent and add it in the other dump functions as well. 
None of the other DeclContext dump functions cast to `Decl`, so I'm not certain 
there's an `else` to add to any of them, or am I misunderstanding?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133499

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


[PATCH] D131465: C++/ObjC++: switch to gnu++17 as the default standard

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

In D131465#3780717 , @AaronLiu wrote:

> This cause a large amount failures in our testing with errors such as:
>
>   error: ISO C++17 does not allow 'register' storage class specifier 
> [-Wregister]
>
>   error: ISO C++17 does not allow dynamic exception specifications 
> [-Wdynamic-exception-spec]

Sorry to hear that. Who is "our" in this case and do you have a suggestion for 
how you'd like to proceed?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131465

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


[PATCH] D133499: [clang]: Add DeclContext::dumpDecl() in order to conveniently dump an AST from a DeclContext.

2022-09-09 Thread Shafik Yaghmour via Phabricator via cfe-commits
shafik added inline comments.



Comment at: clang/lib/AST/ASTDumper.cpp:205
+  if (const Decl *D = dyn_cast(this))
+D->dump();
+}

aaron.ballman wrote:
> shafik wrote:
> > aaron.ballman wrote:
> > > erichkeane wrote:
> > > > aaron.ballman wrote:
> > > > > erichkeane wrote:
> > > > > > One thing to note is that the 'else' case here is a little 
> > > > > > uninformative.  See 
> > > > > > https://clang.llvm.org/doxygen/DeclBase_8cpp_source.html#l00915 for 
> > > > > > some similar logic here (though not sure we should be emulating 
> > > > > > that).
> > > > > > 
> > > > > > More, I wonder if there is SOME message here that should be dumped 
> > > > > > for 'else'.
> > > > > Looking at what inherits from `DeclContext`, is there use of it which 
> > > > > is *not* a `Decl`? I couldn't find a use where it's not also a `Decl`.
> > > > I've DEFINITELY run into it in the debugger before, but I have no idea 
> > > > WHAT case that is. It is sometimes just "DeclContext is an invalid 
> > > > pointer" kinda thing, so it might be worth-while to have SOME output 
> > > > besides "print nothing", particularly when debugging.
> > > IIRC, the case this comes up in is when the object is only partially 
> > > constructed, and so I agree that having an `else` clause here would be 
> > > useful -- because this interface is predominately used from a debugger, 
> > > it has to deal with special "impossible" situations a bit more carefully.
> > So looking at the other dump member functions, all of them seem to assume 
> > we have a valid `DeclContext` and so they do not have any else either.
> > 
> > So maybe we want to think about making the rest a bit smarter as well?
> > So maybe we want to think about making the rest a bit smarter as well?
> 
> What do you have in mind?
> 
> I think it's plausible to be in a partially constructed state in terms of 
> when ctors are called, but I'm far less worried about people calling a dump 
> method in the middle of the member inits happening.
> > So maybe we want to think about making the rest a bit smarter as well?
> 
> What do you have in mind?
> 
> I think it's plausible to be in a partially constructed state in terms of 
> when ctors are called, but I'm far less worried about people calling a dump 
> method in the middle of the member inits happening.

Apologies, what I meant was if we are going to add an `else` here then we 
should be consistent and add it in the other dump functions as well. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133499

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


[PATCH] D131465: C++/ObjC++: switch to gnu++17 as the default standard

2022-09-09 Thread Aaron H Liu via Phabricator via cfe-commits
AaronLiu added a comment.

This cause a large amount failures in our testing with errors such as:

  error: ISO C++17 does not allow 'register' storage class specifier 
[-Wregister]

  error: ISO C++17 does not allow dynamic exception specifications 
[-Wdynamic-exception-spec]


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131465

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


[PATCH] D130270: [clang][dataflow] Use a dedicated bool to encode which branch was taken

2022-09-09 Thread Sam Estep via Phabricator via cfe-commits
samestep accepted this revision.
samestep added a comment.

@ymandel Huh, interesting! I'll go ahead and abandon this patch, then?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130270

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


[PATCH] D133088: [Clang] Fix wrong diagnostic for scope identifier with internal linkage

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



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:5904-5905
 def err_block_extern_cant_init : Error<
-  "'extern' variable cannot have an initializer">;
+  "declaration of block scope identifier with %select{external|internal}0 "
+  "linkage shall have no initializer">;
 def warn_extern_init : Warning<"'extern' variable has an initializer">,

I don't think we want to try to call out external vs internal linkage here, 
more on why below. Also, we don't usually use "shall" in diagnostic wording.



Comment at: clang/lib/Sema/SemaDecl.cpp:12774-12784
+  // C99 6.7.8p5. C++ has no such restriction, but that is a defect.
   if (VDecl->isLocalVarDecl() && VDecl->hasExternalStorage()) {
-// C99 6.7.8p5. C++ has no such restriction, but that is a defect.
-Diag(VDecl->getLocation(), diag::err_block_extern_cant_init);
+unsigned LinkageKind = /*external*/ 0;
+// C2x 6.7.10p6.
+if (VDecl->getFormalLinkage() == InternalLinkage)
+  LinkageKind = /*internal*/ 1;
+





Comment at: clang/lib/Sema/SemaDecl.cpp:12776-12778
+unsigned LinkageKind = /*external*/ 0;
+// C2x 6.7.10p6.
+if (VDecl->getFormalLinkage() == InternalLinkage)





Comment at: clang/test/Sema/err-decl-block-extern-no-init.c:6
+{
+extern int x = 1; // expected-error {{declaration of block scope 
identifier with internal linkage shall have no initializer}}
+}

This example is why I think we should reword the diagnostic. As it stands, this 
diagnostic wording would be baffling to most users because they'd go "whaddya 
mean *INTERNAL* linkage, I said `extern` for a reason!" So using a diagnostic 
wording of "with linkage" sidesteps that -- what the linkage is doesn't matter 
for fixing the code, it's the initializer that's the issue.

Also, I don't know what it means for a block scope variable to have *internal* 
linkage instead of *no* linkage (and I'm not certain it's possible to observe 
the difference).

That said, I think this example should have a *second* diagnostic, which is a 
warning, letting the user know that the actual linkage does not match the 
specified linkage. (This should be done in a separate patch.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133088

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


[PATCH] D130270: [clang][dataflow] Use a dedicated bool to encode which branch was taken

2022-09-09 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel requested changes to this revision.
ymandel added a comment.
This revision now requires changes to proceed.

It turns out that this change wasn't necessary. I've deleted the relevant FIXME 
in https://reviews.llvm.org/rGabc16c7a5b0a63d14172262153608b3d24de957f.

AFAICT, the reason that the new test `JoinBackedge` fails at HEAD is because we 
discard the results of analyzing the function body, so the update `Foo = false` 
is simply ignored. This hypothesis rests on observing that each block is 
visited only once during analysis of the test. It's also consistent with the 
known (broken) behavior of our comparison operator. Interestingly, this is a 
nicely stark illustration of the unsoundness of our current approach. :( So, 
this test will be useful in the future when add proper widening.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130270

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


[PATCH] D133589: [clang-format] JSON formatting add new option for controlling newlines in json arrays

2022-09-09 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay created this revision.
MyDeveloperDay added reviewers: HazardyKnusperkeks, curdeius, owenpan.
MyDeveloperDay added a project: clang-format.
Herald added a project: All.
MyDeveloperDay requested review of this revision.
Herald added a project: clang.

Working in a mixed environment of both vscode/vim with a team configured 
prettier configuration, this can leave clang-format and prettier fighting each 
other over the formatting of arrays, both simple arrays of elements.

This review aims to add some "control knobs" to the Json formatting in 
clang-format to help align the two tools so they can be used interchangeably.

This will allow simply arrays `[1, 2, 3]` to remain on a single line but will 
break those arrays based on context within that array.

Happy to change the name of the option (this is the third name I tried)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133589

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/Format.cpp
  clang/lib/Format/TokenAnnotator.cpp
  clang/unittests/Format/FormatTestJson.cpp

Index: clang/unittests/Format/FormatTestJson.cpp
===
--- clang/unittests/Format/FormatTestJson.cpp
+++ clang/unittests/Format/FormatTestJson.cpp
@@ -159,6 +159,27 @@
"]");
 }
 
+TEST_F(FormatTestJson, JsonArrayOneLine) {
+  FormatStyle Style = getLLVMStyle(FormatStyle::LK_Json);
+  Style.JsonMultilineArrays = false;
+  Style.SpacesInContainerLiterals = false;
+  verifyFormat("[]", Style);
+  verifyFormat("[1]", Style);
+  verifyFormat("[1, 2]", Style);
+  verifyFormat("[1, 2, 3]", Style);
+  verifyFormat("[1, 2, 3, 4]", Style);
+  verifyFormat("[1, 2, 3, 4, 5]", Style);
+
+  verifyFormat("[\n"
+   "  1,\n"
+   "  2,\n"
+   "  {\n"
+   "A: 1\n"
+   "  }\n"
+   "]",
+   Style);
+}
+
 TEST_F(FormatTestJson, JsonNoStringSplit) {
   FormatStyle Style = getLLVMStyle(FormatStyle::LK_Json);
   Style.IndentWidth = 4;
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -4399,18 +4399,48 @@
 // }
 if (Left.is(TT_DictLiteral) && Left.is(tok::l_brace))
   return true;
-// Always break after a JSON array opener.
+// Always break after a JSON array opener based on JsonMultilineArrays
 // [
 // ]
 if (Left.is(TT_ArrayInitializerLSquare) && Left.is(tok::l_square) &&
 !Right.is(tok::r_square)) {
-  return true;
+  if (Right.is(tok::l_brace))
+return true;
+  // scan to the right if an we see an object or an array inside
+  // then break
+  const auto *Tok = 
+  while (Tok) {
+if (Tok->isOneOf(tok::l_brace, tok::l_square)) {
+  return true;
+}
+if (Tok->isOneOf(tok::r_brace, tok::r_square)) {
+  break;
+}
+Tok = Tok->Next;
+  }
+  return Style.JsonMultilineArrays;
 }
 // Always break after successive entries.
 // 1,
 // 2
-if (Left.is(tok::comma))
-  return true;
+if (Left.is(tok::comma)) {
+  if (Right.is(tok::l_brace)) {
+return true;
+  }
+  // scan to the right if an we see an object or an array inside
+  // then break
+  const auto *Tok = 
+  while (Tok) {
+if (Tok->isOneOf(tok::l_brace, tok::l_square)) {
+  return true;
+}
+if (Tok->isOneOf(tok::r_brace, tok::r_square)) {
+  break;
+}
+Tok = Tok->Next;
+  }
+  return Style.JsonMultilineArrays;
+}
   }
 
   // If the last token before a '}', ']', or ')' is a comma or a trailing
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -756,6 +756,8 @@
 IO.mapOptional("ExperimentalAutoDetectBinPacking",
Style.ExperimentalAutoDetectBinPacking);
 
+IO.mapOptional("JsonMultilineArrays", Style.JsonMultilineArrays);
+
 IO.mapOptional("PackConstructorInitializers",
Style.PackConstructorInitializers);
 // For backward compatibility:
@@ -1249,6 +1251,7 @@
   LLVMStyle.EmptyLineAfterAccessModifier = FormatStyle::ELAAMS_Never;
   LLVMStyle.EmptyLineBeforeAccessModifier = FormatStyle::ELBAMS_LogicalBlock;
   LLVMStyle.ExperimentalAutoDetectBinPacking = false;
+  LLVMStyle.JsonMultilineArrays = true;
   LLVMStyle.PackConstructorInitializers = FormatStyle::PCIS_BinPack;
   LLVMStyle.FixNamespaceComments = true;
   LLVMStyle.ForEachMacros.push_back("foreach");
Index: clang/include/clang/Format/Format.h
===
--- clang/include/clang/Format/Format.h
+++ clang/include/clang/Format/Format.h
@@ 

[PATCH] D133588: [NFC] Remove a FIXME fixed by an earlier patch.

2022-09-09 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGabc16c7a5b0a: [NFC] Remove a FIXME fixed by an earlier 
patch. (authored by ymandel).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133588

Files:
  clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp


Index: clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
===
--- clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
+++ clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
@@ -81,9 +81,6 @@
   Environment::ValueModel ) {
   // Join distinct boolean values preserving information about the constraints
   // in the respective path conditions.
-  //
-  // FIXME: Does not work for backedges, since the two (or more) paths will not
-  // have mutually exclusive conditions.
   if (auto *Expr1 = dyn_cast(Val1)) {
 auto *Expr2 = cast(Val2);
 auto  = MergedEnv.makeAtomicBoolValue();


Index: clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
===
--- clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
+++ clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
@@ -81,9 +81,6 @@
   Environment::ValueModel ) {
   // Join distinct boolean values preserving information about the constraints
   // in the respective path conditions.
-  //
-  // FIXME: Does not work for backedges, since the two (or more) paths will not
-  // have mutually exclusive conditions.
   if (auto *Expr1 = dyn_cast(Val1)) {
 auto *Expr2 = cast(Val2);
 auto  = MergedEnv.makeAtomicBoolValue();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


  1   2   >