[PATCH] D60760: Adapt -fsanitize=function to SANITIZER_NON_UNIQUE_TYPEINFO

[Stephan Bergmann via Phabricator via cfe-commits]

sberg added a comment.

Added missing tests at https://reviews.llvm.org/D61479 "Add tests for 'Adapt 
-fsanitize=function to SANITIZER_NON_UNIQUE_TYPEINFO'".


Repository:
  rL LLVM

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

https://reviews.llvm.org/D60760



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

[PATCH] D60925: [analyzer] Don't display implementation checkers under -analyzer-checker-help, but do under the new flag -analyzer-checker-help-hidden

[Gyorgy Orban via Phabricator via cfe-commits]

o.gyorgy added a comment.

Great, at least the users will not enable the debug checkers by accident!
We will check on the CodeChecker side if any configuration needs to be updated.

LGTM


Repository:
  rL LLVM

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

https://reviews.llvm.org/D60925



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

[PATCH] D61454: [CodeGen][ObjC] Remove the leading 'l_' from ObjC symbols and make private symbols in the __DATA segment internal.

[Akira Hatanaka via Phabricator via cfe-commits]

ahatanak updated this revision to Diff 197918.
ahatanak marked 2 inline comments as done.
ahatanak added a comment.

- Instead of passing a flag to `CreateMetadataVar` that indicates the section 
is in segment `__DATA`, just scan the section name string inside 
`CreateMetadataVar`.
- Fix test case `ns-constant-strings.m`.


Repository:
  rC Clang

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

https://reviews.llvm.org/D61454

Files:
  lib/CodeGen/CGObjCMac.cpp
  test/CodeGenObjC/arc.m
  test/CodeGenObjC/boxing.m
  test/CodeGenObjC/exceptions-asm-attribute.m
  test/CodeGenObjC/externally-initialized-selectors.m
  test/CodeGenObjC/forward-protocol-metadata-symbols.m
  test/CodeGenObjC/instance-method-metadata.m
  test/CodeGenObjC/interface-layout-64.m
  test/CodeGenObjC/metadata-class-properties.m
  test/CodeGenObjC/metadata-symbols-32.m
  test/CodeGenObjC/metadata-symbols-64.m
  test/CodeGenObjC/metadata_symbols.m
  test/CodeGenObjC/mrc-weak.m
  test/CodeGenObjC/non-lazy-classes.m
  test/CodeGenObjC/private-extern-selector-reference.m
  test/CodeGenObjC/property-category-impl.m
  test/CodeGenObjC/property-list-in-class.m
  test/CodeGenObjC/property-list-in-extension.m
  test/CodeGenObjC/protocol-comdat.m
  test/CodeGenObjC/protocols.m
  test/CodeGenObjC/section-name.m
  test/CodeGenObjC/sections.m
  test/CodeGenObjCXX/externally-initialized-selectors.mm
  test/CodeGenObjCXX/mrc-weak.mm

Index: test/CodeGenObjCXX/mrc-weak.mm
===
--- test/CodeGenObjCXX/mrc-weak.mm
+++ test/CodeGenObjCXX/mrc-weak.mm
@@ -7,7 +7,7 @@
 @end
 
 // CHECK-MODERN: @OBJC_CLASS_NAME_{{.*}} = {{.*}} c"\01\00"
-// CHECK-MODERN: @"\01l_OBJC_CLASS_RO_$_Foo" = {{.*}} { i32 772
+// CHECK-MODERN: @"_OBJC_CLASS_RO_$_Foo" = {{.*}} { i32 772
 //   772 == 0x304
 //^ HasMRCWeakIvars
 //^ HasCXXDestructorOnly
Index: test/CodeGenObjCXX/externally-initialized-selectors.mm
===
--- test/CodeGenObjCXX/externally-initialized-selectors.mm
+++ test/CodeGenObjCXX/externally-initialized-selectors.mm
@@ -1,7 +1,8 @@
-// RUN: %clang_cc1 -fobjc-runtime=macosx-fragile-10.5 -o - -emit-llvm %s | FileCheck %s
-// RUN: %clang_cc1 -o - -emit-llvm %s | FileCheck %s
+// RUN: %clang_cc1 -fobjc-runtime=macosx-fragile-10.5 -o - -emit-llvm %s | FileCheck -check-prefix=FRAGILE %s
+// RUN: %clang_cc1 -o - -emit-llvm %s | FileCheck -check-prefix=NONFRAGILE %s
 
-// CHECK: @OBJC_SELECTOR_REFERENCES_ = private externally_initialized global
+// NONFRAGILE: @OBJC_SELECTOR_REFERENCES_ = internal externally_initialized global
+// FRAGILE: @OBJC_SELECTOR_REFERENCES_ = private externally_initialized global
 
 void test(id x) {
   [x doSomething];
Index: test/CodeGenObjC/sections.m
===
--- test/CodeGenObjC/sections.m
+++ test/CodeGenObjC/sections.m
@@ -37,9 +37,9 @@
 // CHECK-COFF: @"OBJC_CLASSLIST_SUP_REFS_$_" = {{.*}}, section ".objc_superrefs$B"
 // CHECK-COFF: @OBJC_SELECTOR_REFERENCES_ = {{.*}}, section ".objc_selrefs$B"
 // CHECK-COFF: @"OBJC_CLASSLIST_REFERENCES_$_" = {{.*}}, section ".objc_classrefs$B"
-// CHECK-COFF: @"\01l_objc_msgSend_fixup_class" = {{.*}}, section ".objc_msgrefs$B"
+// CHECK-COFF: @_objc_msgSend_fixup_class = {{.*}}, section ".objc_msgrefs$B"
 // CHECK-COFF: @"_OBJC_LABEL_PROTOCOL_$_P" = {{.*}}, section ".objc_protolist$B"
-// CHECK-COFF: @"\01l_OBJC_PROTOCOL_REFERENCE_$_P" = {{.*}}, section ".objc_protorefs$B"
+// CHECK-COFF: @"_OBJC_PROTOCOL_REFERENCE_$_P" = {{.*}}, section ".objc_protorefs$B"
 // CHECK-COFF: @"OBJC_LABEL_CLASS_$" = {{.*}}, section ".objc_classlist$B"
 // CHECK-COFF: @"OBJC_LABEL_NONLAZY_CLASS_$" = {{.*}}, section ".objc_nlclslist$B"
 // CHECK-COFF: @"OBJC_LABEL_CATEGORY_$" = {{.*}}, section ".objc_catlist$B"
@@ -49,9 +49,9 @@
 // CHECK-ELF: @"OBJC_CLASSLIST_SUP_REFS_$_" = {{.*}}, section "objc_superrefs"
 // CHECK-ELF: @OBJC_SELECTOR_REFERENCES_ = {{.*}}, section "objc_selrefs"
 // CHECK-ELF: @"OBJC_CLASSLIST_REFERENCES_$_" = {{.*}}, section "objc_classrefs"
-// CHECK-ELF: @"\01l_objc_msgSend_fixup_class" = {{.*}}, section "objc_msgrefs"
+// CHECK-ELF: @_objc_msgSend_fixup_class = {{.*}}, section "objc_msgrefs"
 // CHECK-ELF: @"_OBJC_LABEL_PROTOCOL_$_P" = {{.*}}, section "objc_protolist"
-// CHECK-ELF: @"\01l_OBJC_PROTOCOL_REFERENCE_$_P" = {{.*}}, section "objc_protorefs"
+// CHECK-ELF: @"_OBJC_PROTOCOL_REFERENCE_$_P" = {{.*}}, section "objc_protorefs"
 // CHECK-ELF: @"OBJC_LABEL_CLASS_$" = {{.*}}, section "objc_classlist"
 // CHECK-ELF: @"OBJC_LABEL_NONLAZY_CLASS_$" = {{.*}}, section "objc_nlclslist"
 // CHECK-ELF: @"OBJC_LABEL_CATEGORY_$" = {{.*}}, section "objc_catlist"
@@ -61,9 +61,9 @@
 // CHECK-MACHO: @"OBJC_CLASSLIST_SUP_REFS_$_" = {{.*}}, section "__DATA,__objc_superrefs,regular,no_dead_strip"
 // CHECK-MACHO: @OBJC_SELECTOR_REFERENCES_ = {{.*}}, section "__DATA,__objc_selrefs,literal_pointers,no_d

r359859 - Revert "[Attribute/Diagnostics] Print macro if definition is an attribute declaration"

[Leonard Chan via cfe-commits]

Author: leonardchan
Date: Thu May  2 20:28:06 2019
New Revision: 359859

URL: http://llvm.org/viewvc/llvm-project?rev=359859&view=rev
Log:
Revert "[Attribute/Diagnostics] Print macro if definition is an attribute 
declaration"

This reverts commit fc40cbd9d8c63e65eed3590ba925321afe782e1d.

Removed:
cfe/trunk/test/Frontend/macro_defined_type.cpp
cfe/trunk/test/Sema/address_space_print_macro.c
Modified:
cfe/trunk/include/clang/AST/ASTContext.h
cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
cfe/trunk/include/clang/AST/Type.h
cfe/trunk/include/clang/AST/TypeLoc.h
cfe/trunk/include/clang/AST/TypeNodes.def
cfe/trunk/include/clang/Parse/Parser.h
cfe/trunk/include/clang/Sema/ParsedAttr.h
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/include/clang/Serialization/ASTBitCodes.h
cfe/trunk/lib/ARCMigrate/TransGCAttrs.cpp
cfe/trunk/lib/AST/ASTContext.cpp
cfe/trunk/lib/AST/ASTDiagnostic.cpp
cfe/trunk/lib/AST/ASTStructuralEquivalence.cpp
cfe/trunk/lib/AST/ItaniumMangle.cpp
cfe/trunk/lib/AST/Type.cpp
cfe/trunk/lib/AST/TypePrinter.cpp
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
cfe/trunk/lib/Parse/ParseDecl.cpp
cfe/trunk/lib/Sema/SemaExpr.cpp
cfe/trunk/lib/Sema/SemaStmt.cpp
cfe/trunk/lib/Sema/SemaType.cpp
cfe/trunk/lib/Sema/TreeTransform.h
cfe/trunk/lib/Serialization/ASTReader.cpp
cfe/trunk/lib/Serialization/ASTWriter.cpp
cfe/trunk/test/Sema/address_spaces.c
cfe/trunk/test/SemaObjC/externally-retained.m
cfe/trunk/test/SemaObjC/gc-attributes.m
cfe/trunk/test/SemaObjC/mrc-weak.m
cfe/trunk/test/SemaObjCXX/gc-attributes.mm
cfe/trunk/tools/libclang/CIndex.cpp

Modified: cfe/trunk/include/clang/AST/ASTContext.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTContext.h?rev=359859&r1=359858&r2=359859&view=diff
==
--- cfe/trunk/include/clang/AST/ASTContext.h (original)
+++ cfe/trunk/include/clang/AST/ASTContext.h Thu May  2 20:28:06 2019
@@ -1441,9 +1441,6 @@ public:
 
   QualType getParenType(QualType NamedType) const;
 
-  QualType getMacroQualifiedType(QualType UnderlyingTy,
- const IdentifierInfo *MacroII) const;
-
   QualType getElaboratedType(ElaboratedTypeKeyword Keyword,
  NestedNameSpecifier *NNS, QualType NamedType,
  TagDecl *OwnedTagDecl = nullptr) const;

Modified: cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/RecursiveASTVisitor.h?rev=359859&r1=359858&r2=359859&view=diff
==
--- cfe/trunk/include/clang/AST/RecursiveASTVisitor.h (original)
+++ cfe/trunk/include/clang/AST/RecursiveASTVisitor.h Thu May  2 20:28:06 2019
@@ -1065,9 +1065,6 @@ DEF_TRAVERSE_TYPE(AttributedType,
 
 DEF_TRAVERSE_TYPE(ParenType, { TRY_TO(TraverseType(T->getInnerType())); })
 
-DEF_TRAVERSE_TYPE(MacroQualifiedType,
-  { TRY_TO(TraverseType(T->getUnderlyingType())); })
-
 DEF_TRAVERSE_TYPE(ElaboratedType, {
   if (T->getQualifier()) {
 TRY_TO(TraverseNestedNameSpecifier(T->getQualifier()));
@@ -1311,9 +1308,6 @@ DEF_TRAVERSE_TYPELOC(InjectedClassNameTy
 
 DEF_TRAVERSE_TYPELOC(ParenType, { TRY_TO(TraverseTypeLoc(TL.getInnerLoc())); })
 
-DEF_TRAVERSE_TYPELOC(MacroQualifiedType,
- { TRY_TO(TraverseTypeLoc(TL.getInnerLoc())); })
-
 DEF_TRAVERSE_TYPELOC(AttributedType,
  { TRY_TO(TraverseTypeLoc(TL.getModifiedLoc())); })
 

Modified: cfe/trunk/include/clang/AST/Type.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Type.h?rev=359859&r1=359858&r2=359859&view=diff
==
--- cfe/trunk/include/clang/AST/Type.h (original)
+++ cfe/trunk/include/clang/AST/Type.h Thu May  2 20:28:06 2019
@@ -4184,41 +4184,6 @@ public:
   static bool classof(const Type *T) { return T->getTypeClass() == Typedef; }
 };
 
-/// Sugar type that represents a type that was qualified by a qualifier written
-/// as a macro invocation.
-class MacroQualifiedType : public Type {
-  friend class ASTContext; // ASTContext creates these.
-
-  QualType UnderlyingTy;
-  const IdentifierInfo *MacroII;
-
-  MacroQualifiedType(QualType UnderlyingTy, QualType CanonTy,
- const IdentifierInfo *MacroII)
-  : Type(MacroQualified, CanonTy, UnderlyingTy->isDependentType(),
- UnderlyingTy->isInstantiationDependentType(),
- UnderlyingTy->isVariablyModifiedType(),
- UnderlyingTy->containsUnexpandedParameterPack()),
-UnderlyingTy(UnderlyingTy), MacroII(MacroII) {
-assert(isa(UnderlyingTy) &&
-   "Expected a macro qualified type to only wrap attributed types.");
-  }
-
-public:
-

Re: r359814 - [Sema] Emit warning for visibility attribute on internal-linkage declaration

[Nico Weber via cfe-commits]

This also breaks building libc++ [1]. Reverted for now in r359858.

1:
FAILED: obj/buildtools/third_party/libc++/libc++/new.o
../../third_party/llvm-build/Release+Asserts/bin/clang++ -MMD -MF
obj/buildtools/third_party/libc++/libc++/new.o.d -D_LIBCPP_BUILDING_LIBRARY
-DLIBCXX_BUILDING_LIBCXXABI -DUSE_UDEV -DUSE_AURA=1 -DUSE_GLIB=1
-DUSE_NSS_CERTS=1 -DUSE_X11=1 -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD
-DSAFE_BROWSING_DB_LOCAL -DCHROMIUM_BUILD -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_GNU_SOURCE
-DCR_CLANG_REVISION=\"359857-0\" -DCOMPONENT_BUILD -D_LIBCPP_ABI_UNSTABLE
-D_LIBCPP_ABI_VERSION=Cr -D_LIBCPP_ENABLE_NODISCARD
-DCR_LIBCXX_REVISION=358423
-DCR_SYSROOT_HASH=e7c53f04bd88d29d075bfd1f62b073aeb69cbe09 -DNDEBUG
-DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -I../.. -Igen
-fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector
-funwind-tables -fPIC -B../../third_party/binutils/Linux_x64/Release/bin
-pthread -fcolor-diagnostics -fmerge-all-constants
-fcrash-diagnostics-dir=../../tools/clang/crashreports -Xclang -mllvm
-Xclang -instcombine-lower-dbg-declare=0 -fcomplete-member-pointers -m64
-march=x86-64 -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__=
-D__TIMESTAMP__= -Xclang -fdebug-compilation-dir -Xclang .
-no-canonical-prefixes -O2 -fno-ident -fdata-sections -ffunction-sections
-fno-omit-frame-pointer -g2 -ggnu-pubnames -Wheader-hygiene
-Wstring-conversion -Wtautological-overlap-compare -fstrict-aliasing -fPIC
-Werror -Wall -Wno-unused-variable -Wno-missing-field-initializers
-Wno-unused-parameter -Wno-c++11-narrowing
-Wno-unneeded-internal-declaration -Wno-undefined-var-template
-Wno-ignored-pragma-optimize -fvisibility=default -std=c++14 -nostdinc++
-isystem../../buildtools/third_party/libc++/trunk/include
-isystem../../buildtools/third_party/libc++abi/trunk/include
--sysroot=../../build/linux/debian_sid_amd64-sysroot -fexceptions -frtti -c
../../buildtools/third_party/libc++/trunk/src/new.cpp -o
obj/buildtools/third_party/libc++/libc++/new.o
In file included from
../../buildtools/third_party/libc++/trunk/src/new.cpp:12:
../../buildtools/third_party/libc++/trunk/src/include/atomic_support.h:55:8:
error: '__visibility__' attribute is ignored on a non-external symbol
[-Werror,-Wignored-attributes]
inline _LIBCPP_INLINE_VISIBILITY
   ^
../../buildtools/third_party/libc++/trunk/include/__config:820:35: note:
expanded from macro '_LIBCPP_INLINE_VISIBILITY'
#define _LIBCPP_INLINE_VISIBILITY _LIBCPP_HIDE_FROM_ABI
  ^
../../buildtools/third_party/libc++/trunk/include/__config:805:35: note:
expanded from macro '_LIBCPP_HIDE_FROM_ABI'
#define _LIBCPP_HIDE_FROM_ABI _LIBCPP_HIDDEN
_LIBCPP_EXCLUDE_FROM_EXPLICIT_INSTANTIATION
  ^
../../buildtools/third_party/libc++/trunk/include/__config:695:44: note:
expanded from macro '_LIBCPP_HIDDEN'
#define _LIBCPP_HIDDEN __attribute__ ((__visibility__("hidden")))
   ^

On Thu, May 2, 2019 at 10:35 PM via cfe-commits 
wrote:

> Hi Richard,
>
> Thank you for the heads up. Feel free to revert, or I can when I can get
> back to a terminal. I'm not sure where the right place is to warn if using
> the linkage calculator here is too early, so it might take a bit of time
> for me to fix the patch.
>
> Thanks,
> Scott
>
> On May 2, 2019 9:42 PM, Richard Smith  wrote:
>
> This will trigger computation and caching the linkage of the
> declaration too early (before we actually know it) in some cases. For
> instance, I believe this is causing a rejects-valid on:
>
> typedef struct __attribute__((visibility("hidden"))) {} A;
>
> ... which we used to accept but now reject with:
>
> :1:31: warning: 'visibility' attribute is ignored on a
> non-external symbol [-Wignored-attributes]
> typedef struct __attribute__((visibility("hidden"))) {} A;
>   ^
> :1:57: error: unsupported: typedef changes linkage of anonymous
> type, but linkage was already computed
> typedef struct __attribute__((visibility("hidden"))) {} A;
> ^
> :1:15: note: use a tag name here to establish linkage prior to
> definition
> typedef struct __attribute__((visibility("hidden"))) {} A;
>   ^
>A
>
> In addition to the error, note that the warning is wrong, because the
> linkage was computed too early (before it was known).
>
> On Thu, 2 May 2019 at 12:01, Scott Linder via cfe-commits
>  wrote:
> >
> > Author: scott.linder
> > Date: Thu May  2 12:03:57 2019
> > New Revision: 359814
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=359814&view=rev
> > Log:
> > [Sema] Emit warning for visibility attribute on internal-linkage
> declaration
> >
> > GCC warns on these cases, but we currently just silently ignore the
> attribute.
> >
> > Differential Revision: https://reviews.llvm.org/D61097
> >
> > Modified:
> > cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> >

r359858 - Revert r359814 "[Sema] Emit warning for visibility attribute on internal-linkage declaration"

[Nico Weber via cfe-commits]

Author: nico
Date: Thu May  2 20:16:07 2019
New Revision: 359858

URL: http://llvm.org/viewvc/llvm-project?rev=359858&view=rev
Log:
Revert r359814 "[Sema] Emit warning for visibility attribute on 
internal-linkage declaration"

See cfe-commits thread for r359814.

Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/Sema/SemaDeclAttr.cpp
cfe/trunk/test/Sema/attr-visibility.c
cfe/trunk/test/SemaCXX/ast-print.cpp
cfe/trunk/test/SemaCXX/attr-visibility.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=359858&r1=359857&r2=359858&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Thu May  2 20:16:07 
2019
@@ -2778,9 +2778,6 @@ def warn_attribute_ignored : Warning<"%0
 def warn_attribute_ignored_on_inline :
   Warning<"%0 attribute ignored on inline function">,
   InGroup;
-def warn_attribute_ignored_on_non_external :
-  Warning<"%0 attribute is ignored on a non-external symbol">,
-  InGroup;
 def warn_nocf_check_attribute_ignored :
   Warning<"'nocf_check' attribute ignored; use -fcf-protection to enable the 
attribute">,
   InGroup;

Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=359858&r1=359857&r2=359858&view=diff
==
--- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Thu May  2 20:16:07 2019
@@ -2615,14 +2615,6 @@ static void handleVisibilityAttr(Sema &S
 return;
   }
 
-  // Visibility attributes have no effect on symbols with internal linkage.
-  if (const auto *ND = dyn_cast(D)) {
-if (!ND->isExternallyVisible())
-  S.Diag(AL.getRange().getBegin(),
- diag::warn_attribute_ignored_on_non_external)
-  << AL;
-  }
-
   // Check that the argument is a string literal.
   StringRef TypeStr;
   SourceLocation LiteralLoc;

Modified: cfe/trunk/test/Sema/attr-visibility.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/attr-visibility.c?rev=359858&r1=359857&r2=359858&view=diff
==
--- cfe/trunk/test/Sema/attr-visibility.c (original)
+++ cfe/trunk/test/Sema/attr-visibility.c Thu May  2 20:16:07 2019
@@ -26,9 +26,3 @@ typedef int __attribute__((visibility("d
 int x __attribute__((type_visibility("default"))); // expected-error 
{{'type_visibility' attribute only applies to types and namespaces}}
 
 int PR17105 __attribute__((visibility(hidden))); // expected-error 
{{'visibility' attribute requires a string}}
-
-static int test8 __attribute__((visibility("default"))); // expected-warning 
{{'visibility' attribute is ignored on a non-external symbol}}
-static int test9 __attribute__((visibility("hidden"))); // expected-warning 
{{'visibility' attribute is ignored on a non-external symbol}}
-static int test10 __attribute__((visibility("internal"))); // expected-warning 
{{'visibility' attribute is ignored on a non-external symbol}}
-
-static int test11() __attribute__((visibility("default"))); // 
expected-warning {{'visibility' attribute is ignored on a non-external symbol}}

Modified: cfe/trunk/test/SemaCXX/ast-print.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/ast-print.cpp?rev=359858&r1=359857&r2=359858&view=diff
==
--- cfe/trunk/test/SemaCXX/ast-print.cpp (original)
+++ cfe/trunk/test/SemaCXX/ast-print.cpp Thu May  2 20:16:07 2019
@@ -209,8 +209,10 @@ void test(int i) {
 }
 }
 
+namespace {
 // CHECK: struct {{\[\[gnu::visibility\(\"hidden\"\)\]\]}} S;
 struct [[gnu::visibility("hidden")]] S;
+}
 
 // CHECK:  struct CXXFunctionalCastExprPrint {
 // CHECK-NEXT: } fce = CXXFunctionalCastExprPrint{};

Modified: cfe/trunk/test/SemaCXX/attr-visibility.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/attr-visibility.cpp?rev=359858&r1=359857&r2=359858&view=diff
==
--- cfe/trunk/test/SemaCXX/attr-visibility.cpp (original)
+++ cfe/trunk/test/SemaCXX/attr-visibility.cpp Thu May  2 20:16:07 2019
@@ -18,9 +18,3 @@ void foo() {
 struct x3 {
   static int y;
 } __attribute((visibility("default"))); // expected-warning {{attribute 
'visibility' after definition is ignored}}
-
-const int test4 __attribute__((visibility("default"))) = 0; // 
expected-warning {{'visibility' attribute is ignored on a non-external symbol}}
-
-namespace {
-  int test5 __attribute__((visibility("default"))); // expected-warning 
{{'visibility' attribute is ignored on a non-external symbol}}
-};


___

[PATCH] D61456: [gn] Update the clangd test lit site configuration

[Nico Weber via Phabricator via cfe-commits]

thakis closed this revision.
thakis added a comment.

This landed in r359825.


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

https://reviews.llvm.org/D61456



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

Re: [PATCH] D61458: [hip] Relax CUDA call restriction within `decltype` context.

[Justin Lebar via cfe-commits]

> In any case, it seems like your examples argue for disallowing a
return-type mismatch between host and device overloads, not disallowing
observing the type?

Oh no, we have to allow return-type mismatches between host and device
overloads, that is a common thing in CUDA code I've seen.  You can safely
observe this difference *so long as you're inside of a function*.  This is
because we have this caller-sensitive function parsing thing.  When parsing
a __host__ __device__ function, we look at the caller to understand what
context we're in.

What I think you can't do is observe the return-type mismatch between host
and device overloads *from outside of a function*, e.g. from within a
trailing return type.

But perhaps rsmith or another expert can take my attempt at a
contract above and trap me in a Faustian contradiction.

On Thu, May 2, 2019 at 7:47 PM Finkel, Hal J.  wrote:

> Thanks, Justin. It sees like we have the standard set of options: We can
> disallow the mismatch. We can allow it with a warning. We can allow it
> without a warning. We can say that if the mismatch contributes to the type
> of a kernel function, that's illformed (NDR).
>
> In any case, it seems like your examples argue for disallowing a
> return-type mismatch between host and device overloads, not disallowing
> observing the type? Or maybe disallowing observing the type only when
> there's a mismatch?
>
>  -Hal
>
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
>
> --
> *From:* Justin Lebar 
> *Sent:* Thursday, May 2, 2019 9:16 PM
> *To:* reviews+d61458+public+f6ea501465ad5...@reviews.llvm.org
> *Cc:* michael.hl...@gmail.com; Artem Belevich; John McCall; Liu, Yaxun
> (Sam); Finkel, Hal J.; Richard Smith; Clang Commits; mlek...@skidmore.edu;
> blitzrak...@gmail.com; Han Shen
> *Subject:* Re: [PATCH] D61458: [hip] Relax CUDA call restriction within
> `decltype` context.
>
> > So, actually, I wonder if that's not the right answer. We generally
> allow different overloads to have different return types. What if, for
> example, the return type on the host is __float128 and on the device it's
> `MyLongFloatTy`?
>
> The problem is that conceptually compiling for host/device does not create
> a new set of overloads.
>
> When we compile for (say) host, we build a full AST for all functions,
> including device functions, and that AST must pass sema checks.  This is
> significant for example because when compiling for device we need to know
> which kernel templates were instantiated on the host side, so we know which
> kernels to emit.
>
> Here's a contrived example.
>
> ```
>  __host__ int8 bar();
> __device__ int16 bar();
> __host__ __device__ auto foo() -> decltype(bar()) {}
>
> template  __global__ kernel();
>
> void launch_kernel() {
>   kernel<<<...>>>();
> }
> ```
>
> This template instantiation had better be the same when compiling for host
> and device.
>
> That's contrived, but consider this much simpler case:
>
> ```
> void host_fn() {
>   static_assert(sizeof(decltype(foo())) == sizeof(int8));
> }
> ```
>
> If we let foo return int16 in device mode, this static_assert will fail
> when compiling in *device* mode even though host_fn is never called on the
> device.  https://gcc.godbolt.org/z/gYq901
>
> Why are we doing sema checks on the host code when compiling for device?
> See contrived example above, we need quite a bit of info about the host
> code to infer those templates.
>
> On Thu, May 2, 2019 at 7:05 PM Hal Finkel via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
> hfinkel added a comment.
>
> In D61458#1488970 , @jlebar
> wrote:
>
> > Here's one for you:
> >
> >   __host__ float bar();
> >   __device__ int bar();
> >   __host__ __device__ auto foo() -> decltype(bar()) {}
> >
> >
> > What is the return type of `foo`?  :)
> >
> > I don't believe the right answer is, "float when compiling for host, int
> when compiling for device."
>
>
> So, actually, I wonder if that's not the right answer. We generally allow
> different overloads to have different return types. What if, for example,
> the return type on the host is __float128 and on the device it's
> `MyLongFloatTy`?
>
> > I'd be happy if we said this was an error, so long as it's well-defined
> what exactly we're disallowing.  But I bet @rsmith can come up with
> substantially more evil testcases than this.
>
>
>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D61458/new/
>
> https://reviews.llvm.org/D61458
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61458: [hip] Relax CUDA call restriction within `decltype` context.

[Hal Finkel via Phabricator via cfe-commits]

hfinkel added a comment.

> Only if they also differ in some other way. C++ does not (generally) have 
> return-type-based overloading. The two functions described would even mangle 
> the same way if CUDA didn't include host/device in the mangling.

Certainly. I didn't mean to imply otherwise.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61458



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

[PATCH] D61458: [hip] Relax CUDA call restriction within `decltype` context.

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In D61458#1488972 , @hfinkel wrote:

> In D61458#1488970 , @jlebar wrote:
>
> > Here's one for you:
> >
> >   __host__ float bar();
> >   __device__ int bar();
> >   __host__ __device__ auto foo() -> decltype(bar()) {}
> >
> >
> > What is the return type of `foo`?  :)
> >
> > I don't believe the right answer is, "float when compiling for host, int 
> > when compiling for device."
>
>
> So, actually, I wonder if that's not the right answer. We generally allow 
> different overloads to have different return types.


Only if they also differ in some other way.  C++ does not (generally) have 
return-type-based overloading.  The two functions described would even mangle 
the same way if CUDA didn't include host/device in the mangling.

(Function templates can differ only by return type, but if both return types 
successfully instantiate for a given set of (possibly inferred) template 
arguments then the templates can only be distinguished when taking their 
address, not when calling.)

I think I've said before that adding this kind of overloading is not a good 
idea, but since it's apparently already there, you should consult the 
specification (or at least existing practice) to figure out what you're 
supposed to do.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61458



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

Re: [PATCH] D61458: [hip] Relax CUDA call restriction within `decltype` context.

[Finkel, Hal J. via cfe-commits]

Thanks, Justin. It sees like we have the standard set of options: We can 
disallow the mismatch. We can allow it with a warning. We can allow it without 
a warning. We can say that if the mismatch contributes to the type of a kernel 
function, that's illformed (NDR).

In any case, it seems like your examples argue for disallowing a return-type 
mismatch between host and device overloads, not disallowing observing the type? 
Or maybe disallowing observing the type only when there's a mismatch?

 -Hal

Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory


From: Justin Lebar 
Sent: Thursday, May 2, 2019 9:16 PM
To: reviews+d61458+public+f6ea501465ad5...@reviews.llvm.org
Cc: michael.hl...@gmail.com; Artem Belevich; John McCall; Liu, Yaxun (Sam); 
Finkel, Hal J.; Richard Smith; Clang Commits; mlek...@skidmore.edu; 
blitzrak...@gmail.com; Han Shen
Subject: Re: [PATCH] D61458: [hip] Relax CUDA call restriction within 
`decltype` context.

> So, actually, I wonder if that's not the right answer. We generally allow 
> different overloads to have different return types. What if, for example, the 
> return type on the host is __float128 and on the device it's `MyLongFloatTy`?

The problem is that conceptually compiling for host/device does not create a 
new set of overloads.

When we compile for (say) host, we build a full AST for all functions, 
including device functions, and that AST must pass sema checks.  This is 
significant for example because when compiling for device we need to know which 
kernel templates were instantiated on the host side, so we know which kernels 
to emit.

Here's a contrived example.

```
 __host__ int8 bar();
__device__ int16 bar();
__host__ __device__ auto foo() -> decltype(bar()) {}

template  __global__ kernel();

void launch_kernel() {
  kernel<<<...>>>();
}
```

This template instantiation had better be the same when compiling for host and 
device.

That's contrived, but consider this much simpler case:

```
void host_fn() {
  static_assert(sizeof(decltype(foo())) == sizeof(int8));
}
```

If we let foo return int16 in device mode, this static_assert will fail when 
compiling in *device* mode even though host_fn is never called on the device.  
https://gcc.godbolt.org/z/gYq901

Why are we doing sema checks on the host code when compiling for device?  See 
contrived example above, we need quite a bit of info about the host code to 
infer those templates.

On Thu, May 2, 2019 at 7:05 PM Hal Finkel via Phabricator 
mailto:revi...@reviews.llvm.org>> wrote:
hfinkel added a comment.

In D61458#1488970 , @jlebar wrote:

> Here's one for you:
>
>   __host__ float bar();
>   __device__ int bar();
>   __host__ __device__ auto foo() -> decltype(bar()) {}
>
>
> What is the return type of `foo`?  :)
>
> I don't believe the right answer is, "float when compiling for host, int when 
> compiling for device."


So, actually, I wonder if that's not the right answer. We generally allow 
different overloads to have different return types. What if, for example, the 
return type on the host is __float128 and on the device it's `MyLongFloatTy`?

> I'd be happy if we said this was an error, so long as it's well-defined what 
> exactly we're disallowing.  But I bet @rsmith can come up with substantially 
> more evil testcases than this.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61458



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

Re: r359814 - [Sema] Emit warning for visibility attribute on internal-linkage declaration

[via cfe-commits]

Hi Richard,Thank you for the heads up. Feel free to revert, or I can when I can get back to a terminal. I'm not sure where the right place is to warn if using the linkage calculator here is too early, so it might take a bit of time for me to fix the patch.Thanks,ScottOn May 2, 2019 9:42 PM, Richard Smith  wrote:This will trigger computation and caching the linkage of the

declaration too early (before we actually know it) in some cases. For

instance, I believe this is causing a rejects-valid on:



typedef struct __attribute__((visibility("hidden"))) {} A;



... which we used to accept but now reject with:



:1:31: warning: 'visibility' attribute is ignored on a

non-external symbol [-Wignored-attributes]

typedef struct __attribute__((visibility("hidden"))) {} A;

  ^

:1:57: error: unsupported: typedef changes linkage of anonymous

type, but linkage was already computed

typedef struct __attribute__((visibility("hidden"))) {} A;

    ^

:1:15: note: use a tag name here to establish linkage prior to definition

typedef struct __attribute__((visibility("hidden"))) {} A;

  ^

   A



In addition to the error, note that the warning is wrong, because the

linkage was computed too early (before it was known).



On Thu, 2 May 2019 at 12:01, Scott Linder via cfe-commits

 wrote:

>

> Author: scott.linder

> Date: Thu May  2 12:03:57 2019

> New Revision: 359814

>

> URL: http://llvm.org/viewvc/llvm-project?rev=359814&view=rev

> Log:

> [Sema] Emit warning for visibility attribute on internal-linkage declaration

>

> GCC warns on these cases, but we currently just silently ignore the attribute.

>

> Differential Revision: https://reviews.llvm.org/D61097

>

> Modified:

> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td

> cfe/trunk/lib/Sema/SemaDeclAttr.cpp

> cfe/trunk/test/Sema/attr-visibility.c

> cfe/trunk/test/SemaCXX/ast-print.cpp

> cfe/trunk/test/SemaCXX/attr-visibility.cpp

>

> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td

> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=359814&r1=359813&r2=359814&view=diff

> ==

> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)

> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Thu May  2 12:03:57 2019

> @@ -2778,6 +2778,9 @@ def warn_attribute_ignored : Warning<"%0

>  def warn_attribute_ignored_on_inline :

>    Warning<"%0 attribute ignored on inline function">,

>    InGroup;

> +def warn_attribute_ignored_on_non_external :

> +  Warning<"%0 attribute is ignored on a non-external symbol">,

> +  InGroup;

>  def warn_nocf_check_attribute_ignored :

>    Warning<"'nocf_check' attribute ignored; use -fcf-protection to enable the attribute">,

>    InGroup;

>

> Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp

> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=359814&r1=359813&r2=359814&view=diff

> ==

> --- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)

> +++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Thu May  2 12:03:57 2019

> @@ -2615,6 +2615,14 @@ static void handleVisibilityAttr(Sema &S

>  return;

>    }

>

> +  // Visibility attributes have no effect on symbols with internal linkage.

> +  if (const auto *ND = dyn_cast(D)) {

> +    if (!ND->isExternallyVisible())

> +  S.Diag(AL.getRange().getBegin(),

> + diag::warn_attribute_ignored_on_non_external)

> +  << AL;

> +  }

> +

>    // Check that the argument is a string literal.

>    StringRef TypeStr;

>    SourceLocation LiteralLoc;

>

> Modified: cfe/trunk/test/Sema/attr-visibility.c

> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/attr-visibility.c?rev=359814&r1=359813&r2=359814&view=diff

> ==

> --- cfe/trunk/test/Sema/attr-visibility.c (original)

> +++ cfe/trunk/test/Sema/attr-visibility.c Thu May  2 12:03:57 2019

> @@ -26,3 +26,9 @@ typedef int __attribute__((visibility("d

>  int x __attribute__((type_visibility("default"))); // expected-error {{'type_visibility' attribute only applies to types and namespaces}}

>

>  int PR17105 __attribute__((visibility(hidden))); // expected-error {{'visibility' attribute requires a string}}

> +

> +static int test8 __attribute__((visibility("default"))); // expected-warning {{'visibility' attribute is ignored on a non-external symbol}}

> +static int test9 __attribute__((visibility("hidden"))); // expected-warning {{'visibility' attribute is ignored on a non-external symbol}}

> +static int test10 __attribute__((visibility("internal"))); // expected-warning {{'visibility' attribute is ignored on a non-external symbol}}

> +

> +s

[PATCH] D61399: [OpenMP][Clang] Support for target math functions

[Gheorghe-Teodor Bercea via Phabricator via cfe-commits]

gtbercea updated this revision to Diff 197911.
gtbercea added a comment.

- Address comments.
- Add math and cmath inclusion tests.
- Add driver test.


Repository:
  rC Clang

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

https://reviews.llvm.org/D61399

Files:
  lib/Driver/ToolChains/Clang.cpp
  lib/Headers/CMakeLists.txt
  lib/Headers/__clang_cuda_cmath.h
  lib/Headers/__clang_cuda_device_functions.h
  lib/Headers/__clang_cuda_libdevice_declares.h
  lib/Headers/__clang_cuda_math_forward_declares.h
  lib/Headers/openmp_wrappers/__clang_openmp_math.h
  lib/Headers/openmp_wrappers/cmath
  lib/Headers/openmp_wrappers/math.h
  test/CodeGen/nvptx_device_cmath_functions.c
  test/CodeGen/nvptx_device_math_functions.c
  test/Driver/openmp-offload-gpu.c

Index: test/Driver/openmp-offload-gpu.c
===
--- test/Driver/openmp-offload-gpu.c
+++ test/Driver/openmp-offload-gpu.c
@@ -278,3 +278,8 @@
 // RUN:   | FileCheck -check-prefix=CUDA_RED_RECS %s
 // CUDA_RED_RECS: clang{{.*}}"-cc1"{{.*}}"-triple" "nvptx64-nvidia-cuda"
 // CUDA_RED_RECS-SAME: "-fopenmp-cuda-teams-reduction-recs-num=2048"
+
+// RUN:   %clang -### -no-canonical-prefixes -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=OPENMP_NVPTX_WRAPPERS %s
+// OPENMP_NVPTX_WRAPPERS: clang{{.*}}"-cc1"{{.*}}"-triple" "nvptx64-nvidia-cuda"
+// OPENMP_NVPTX_WRAPPERS-SAME: "-internal-isystem" "{{.*}}openmp_wrappers"
Index: test/CodeGen/nvptx_device_math_functions.c
===
--- /dev/null
+++ test/CodeGen/nvptx_device_math_functions.c
@@ -0,0 +1,24 @@
+// Test calling of device math functions.
+///==///
+
+// REQUIRES: nvptx-registered-target
+
+// RUN: %clang -fmath-errno -S -emit-llvm -o - %s -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda | FileCheck -check-prefix CHECK-YES %s
+#include 
+
+void test_sqrt(double a1) {
+  #pragma omp target
+  {
+// CHECK-YES: call double @llvm.nvvm.sqrt.rn.d(double
+double l1 = sqrt(a1);
+// CHECK-YES: call double @__internal_accurate_pow(double
+double l2 = pow(a1, a1);
+// CHECK-YES: call i32 @llvm.nvvm.d2i.hi(double
+// CHECK-YES: call double @llvm.nvvm.trunc.d(double
+// CHECK-YES: call i32 @llvm.nvvm.d2i.hi(double
+// CHECK-YES: call i32 @llvm.nvvm.d2i.lo(double
+// CHECK-YES: call i32 @llvm.nvvm.d2i.hi(double
+// CHECK-YES: call double @llvm.nvvm.lohi.i2d(i32
+double l3 = modf(a1 + 3.5, &a1);
+  }
+}
Index: test/CodeGen/nvptx_device_cmath_functions.c
===
--- /dev/null
+++ test/CodeGen/nvptx_device_cmath_functions.c
@@ -0,0 +1,24 @@
+// Test calling of device math functions.
+///==///
+
+// REQUIRES: nvptx-registered-target
+
+// RUN: %clang++ -fmath-errno -S -emit-llvm -o - %s -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda | FileCheck -check-prefix CHECK-YES %s
+#include 
+
+void test_math_funcs(double a1) {
+  #pragma omp target
+  {
+// CHECK-YES: call double @llvm.nvvm.sqrt.rn.d(double
+double l1 = sqrt(a1);
+// CHECK-YES: call double @__internal_accurate_pow(double
+double l2 = pow(a1, a1);
+// CHECK-YES: call i32 @llvm.nvvm.d2i.hi(double
+// CHECK-YES: call double @llvm.nvvm.trunc.d(double
+// CHECK-YES: call i32 @llvm.nvvm.d2i.hi(double
+// CHECK-YES: call i32 @llvm.nvvm.d2i.lo(double
+// CHECK-YES: call i32 @llvm.nvvm.d2i.hi(double
+// CHECK-YES: call double @llvm.nvvm.lohi.i2d(i32
+double l3 = modf(a1 + 3.5, &a1);
+  }
+}
Index: lib/Headers/openmp_wrappers/math.h
===
--- /dev/null
+++ lib/Headers/openmp_wrappers/math.h
@@ -0,0 +1,17 @@
+/*===- math.h - Alternative math.h header --===
+ *
+ * Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+ * See https://llvm.org/LICENSE.txt for license information.
+ * SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+ *
+ *===---===
+ */
+
+#include <__clang_openmp_math.h>
+
+#ifndef __CLANG_NO_HOST_MATH__
+#include_next 
+#else
+#undef __CLANG_NO_HOST_MATH__
+#endif
+
Index: lib/Headers/openmp_wrappers/cmath
===
--- /dev/null
+++ lib/Headers/openmp_wrappers/cmath
@@ -0,0 +1,16 @@
+/*===-- cmath - Alternative cmath header ---===
+ *
+ * Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+ * See https://llvm.org/LICENSE.txt for license information.
+ * SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+ *
+ *===---===
+

Re: [PATCH] D61458: [hip] Relax CUDA call restriction within `decltype` context.

[Justin Lebar via cfe-commits]

> So, actually, I wonder if that's not the right answer. We generally allow
different overloads to have different return types. What if, for example,
the return type on the host is __float128 and on the device it's
`MyLongFloatTy`?

The problem is that conceptually compiling for host/device does not create
a new set of overloads.

When we compile for (say) host, we build a full AST for all functions,
including device functions, and that AST must pass sema checks.  This is
significant for example because when compiling for device we need to know
which kernel templates were instantiated on the host side, so we know which
kernels to emit.

Here's a contrived example.

```
 __host__ int8 bar();
__device__ int16 bar();
__host__ __device__ auto foo() -> decltype(bar()) {}

template  __global__ kernel();

void launch_kernel() {
  kernel<<<...>>>();
}
```

This template instantiation had better be the same when compiling for host
and device.

That's contrived, but consider this much simpler case:

```
void host_fn() {
  static_assert(sizeof(decltype(foo())) == sizeof(int8));
}
```

If we let foo return int16 in device mode, this static_assert will fail
when compiling in *device* mode even though host_fn is never called on the
device.  https://gcc.godbolt.org/z/gYq901

Why are we doing sema checks on the host code when compiling for device?
See contrived example above, we need quite a bit of info about the host
code to infer those templates.

On Thu, May 2, 2019 at 7:05 PM Hal Finkel via Phabricator <
revi...@reviews.llvm.org> wrote:

> hfinkel added a comment.
>
> In D61458#1488970 , @jlebar
> wrote:
>
> > Here's one for you:
> >
> >   __host__ float bar();
> >   __device__ int bar();
> >   __host__ __device__ auto foo() -> decltype(bar()) {}
> >
> >
> > What is the return type of `foo`?  :)
> >
> > I don't believe the right answer is, "float when compiling for host, int
> when compiling for device."
>
>
> So, actually, I wonder if that's not the right answer. We generally allow
> different overloads to have different return types. What if, for example,
> the return type on the host is __float128 and on the device it's
> `MyLongFloatTy`?
>
> > I'd be happy if we said this was an error, so long as it's well-defined
> what exactly we're disallowing.  But I bet @rsmith can come up with
> substantially more evil testcases than this.
>
>
>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D61458/new/
>
> https://reviews.llvm.org/D61458
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61458: [hip] Relax CUDA call restriction within `decltype` context.

[Hal Finkel via Phabricator via cfe-commits]

hfinkel added a comment.

In D61458#1488970 , @jlebar wrote:

> Here's one for you:
>
>   __host__ float bar();
>   __device__ int bar();
>   __host__ __device__ auto foo() -> decltype(bar()) {}
>
>
> What is the return type of `foo`?  :)
>
> I don't believe the right answer is, "float when compiling for host, int when 
> compiling for device."


So, actually, I wonder if that's not the right answer. We generally allow 
different overloads to have different return types. What if, for example, the 
return type on the host is __float128 and on the device it's `MyLongFloatTy`?

> I'd be happy if we said this was an error, so long as it's well-defined what 
> exactly we're disallowing.  But I bet @rsmith can come up with substantially 
> more evil testcases than this.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61458



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

[PATCH] D61458: [hip] Relax CUDA call restriction within `decltype` context.

[Justin Lebar via Phabricator via cfe-commits]

jlebar added a subscriber: rsmith.
jlebar added a comment.

Here's one for you:

  __host__ float bar();
  __device__ int bar();
  __host__ __device__ auto foo() -> decltype(bar()) {}

What is the return type of `foo`?  :)

I don't believe the right answer is, "float when compiling for host, int when 
compiling for device."

I'd be happy if we said this was an error, so long as it's well-defined what 
exactly we're disallowing.  But I bet @rsmith can come up with substantially 
more evil testcases than this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61458



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

[PATCH] D61475: Update an information about ReSharper C++ and clang-tidy custom binary integration

[Alexander Zaitsev via Phabricator via cfe-commits]

ZaMaZaN4iK created this revision.
ZaMaZaN4iK added reviewers: NoQ, JonasToth.
ZaMaZaN4iK added a project: clang-tools-extra.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

According to the release notes from JetBrains 
(https://www.jetbrains.com/resharper-cpp/whatsnew/#v2019-1-clang-tidy) now it's 
possible to set custom clang-tidy binary


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D61475

Files:
  clang-tools-extra/docs/clang-tidy/Integrations.rst


Index: clang-tools-extra/docs/clang-tidy/Integrations.rst
===
--- clang-tools-extra/docs/clang-tidy/Integrations.rst
+++ clang-tools-extra/docs/clang-tidy/Integrations.rst
@@ -34,7 +34,7 @@
 
+--++-+--+-+--+
 |Qt Creator IDE| \+\|  
 \+\   |   \-\| \-\ 
|   \+\|
 
+--++-+--+-+--+
-|ReSharper C++ for Visual Studio   | \+\|  
 \+\   |   \-\| \+\ 
|   \-\|
+|ReSharper C++ for Visual Studio   | \+\|  
 \+\   |   \-\| \+\ 
|   \+\|
 
+--++-+--+-+--+
 |Syntastic for Vim | \+\|  
 \-\   |   \-\| \-\ 
|   \+\|
 
+--++-+--+-+--+


Index: clang-tools-extra/docs/clang-tidy/Integrations.rst
===
--- clang-tools-extra/docs/clang-tidy/Integrations.rst
+++ clang-tools-extra/docs/clang-tidy/Integrations.rst
@@ -34,7 +34,7 @@
 +--++-+--+-+--+
 |Qt Creator IDE| \+\|   \+\   |   \-\| \-\ |   \+\|
 +--++-+--+-+--+
-|ReSharper C++ for Visual Studio   | \+\|   \+\   |   \-\| \+\ |   \-\|
+|ReSharper C++ for Visual Studio   | \+\|   \+\   |   \-\| \+\ |   \+\|
 +--++-+--+-+--+
 |Syntastic for Vim | \+\|   \-\   |   \-\| \-\ |   \+\|
 +--++-+--+-+--+
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61474: [CUDA][Clang][Bugfix] Add missing CUDA 9.2 case

[Gheorghe-Teodor Bercea via Phabricator via cfe-commits]

gtbercea created this revision.
gtbercea added reviewers: tra, ABataev, caomhin.
Herald added subscribers: cfe-commits, jdoerfert.
Herald added a project: clang.

The bug was reported on the OpenMP-dev list:

.../obj-release/lib/clang/9.0.0/include/__clang_cuda_intrinsics.h:173:35: 
error: '__nvvm_shfl_sync_idx_i32' needs target feature ptx60|ptx61|ptx63|ptx64
__MAKE_SYNC_SHUFFLES(__shfl_sync, __nvvm_shfl_sync_idx_i32,

This problem occurs when trying to compile a .cu file that requires a newer ptx 
version (>ptx60 in this case) than ptx42.


Repository:
  rC Clang

https://reviews.llvm.org/D61474

Files:
  lib/Driver/ToolChains/Cuda.cpp


Index: lib/Driver/ToolChains/Cuda.cpp
===
--- lib/Driver/ToolChains/Cuda.cpp
+++ lib/Driver/ToolChains/Cuda.cpp
@@ -656,6 +656,9 @@
 case CudaVersion::CUDA_100:
   PtxFeature = "+ptx63";
   break;
+case CudaVersion::CUDA_92:
+  PtxFeature = "+ptx61";
+  break;
 case CudaVersion::CUDA_91:
   PtxFeature = "+ptx61";
   break;


Index: lib/Driver/ToolChains/Cuda.cpp
===
--- lib/Driver/ToolChains/Cuda.cpp
+++ lib/Driver/ToolChains/Cuda.cpp
@@ -656,6 +656,9 @@
 case CudaVersion::CUDA_100:
   PtxFeature = "+ptx63";
   break;
+case CudaVersion::CUDA_92:
+  PtxFeature = "+ptx61";
+  break;
 case CudaVersion::CUDA_91:
   PtxFeature = "+ptx61";
   break;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r359814 - [Sema] Emit warning for visibility attribute on internal-linkage declaration

[Richard Smith via cfe-commits]

This will trigger computation and caching the linkage of the
declaration too early (before we actually know it) in some cases. For
instance, I believe this is causing a rejects-valid on:

typedef struct __attribute__((visibility("hidden"))) {} A;

... which we used to accept but now reject with:

:1:31: warning: 'visibility' attribute is ignored on a
non-external symbol [-Wignored-attributes]
typedef struct __attribute__((visibility("hidden"))) {} A;
  ^
:1:57: error: unsupported: typedef changes linkage of anonymous
type, but linkage was already computed
typedef struct __attribute__((visibility("hidden"))) {} A;
^
:1:15: note: use a tag name here to establish linkage prior to definition
typedef struct __attribute__((visibility("hidden"))) {} A;
  ^
   A

In addition to the error, note that the warning is wrong, because the
linkage was computed too early (before it was known).

On Thu, 2 May 2019 at 12:01, Scott Linder via cfe-commits
 wrote:
>
> Author: scott.linder
> Date: Thu May  2 12:03:57 2019
> New Revision: 359814
>
> URL: http://llvm.org/viewvc/llvm-project?rev=359814&view=rev
> Log:
> [Sema] Emit warning for visibility attribute on internal-linkage declaration
>
> GCC warns on these cases, but we currently just silently ignore the attribute.
>
> Differential Revision: https://reviews.llvm.org/D61097
>
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> cfe/trunk/lib/Sema/SemaDeclAttr.cpp
> cfe/trunk/test/Sema/attr-visibility.c
> cfe/trunk/test/SemaCXX/ast-print.cpp
> cfe/trunk/test/SemaCXX/attr-visibility.cpp
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=359814&r1=359813&r2=359814&view=diff
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Thu May  2 12:03:57 
> 2019
> @@ -2778,6 +2778,9 @@ def warn_attribute_ignored : Warning<"%0
>  def warn_attribute_ignored_on_inline :
>Warning<"%0 attribute ignored on inline function">,
>InGroup;
> +def warn_attribute_ignored_on_non_external :
> +  Warning<"%0 attribute is ignored on a non-external symbol">,
> +  InGroup;
>  def warn_nocf_check_attribute_ignored :
>Warning<"'nocf_check' attribute ignored; use -fcf-protection to enable the 
> attribute">,
>InGroup;
>
> Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=359814&r1=359813&r2=359814&view=diff
> ==
> --- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Thu May  2 12:03:57 2019
> @@ -2615,6 +2615,14 @@ static void handleVisibilityAttr(Sema &S
>  return;
>}
>
> +  // Visibility attributes have no effect on symbols with internal linkage.
> +  if (const auto *ND = dyn_cast(D)) {
> +if (!ND->isExternallyVisible())
> +  S.Diag(AL.getRange().getBegin(),
> + diag::warn_attribute_ignored_on_non_external)
> +  << AL;
> +  }
> +
>// Check that the argument is a string literal.
>StringRef TypeStr;
>SourceLocation LiteralLoc;
>
> Modified: cfe/trunk/test/Sema/attr-visibility.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/attr-visibility.c?rev=359814&r1=359813&r2=359814&view=diff
> ==
> --- cfe/trunk/test/Sema/attr-visibility.c (original)
> +++ cfe/trunk/test/Sema/attr-visibility.c Thu May  2 12:03:57 2019
> @@ -26,3 +26,9 @@ typedef int __attribute__((visibility("d
>  int x __attribute__((type_visibility("default"))); // expected-error 
> {{'type_visibility' attribute only applies to types and namespaces}}
>
>  int PR17105 __attribute__((visibility(hidden))); // expected-error 
> {{'visibility' attribute requires a string}}
> +
> +static int test8 __attribute__((visibility("default"))); // expected-warning 
> {{'visibility' attribute is ignored on a non-external symbol}}
> +static int test9 __attribute__((visibility("hidden"))); // expected-warning 
> {{'visibility' attribute is ignored on a non-external symbol}}
> +static int test10 __attribute__((visibility("internal"))); // 
> expected-warning {{'visibility' attribute is ignored on a non-external 
> symbol}}
> +
> +static int test11() __attribute__((visibility("default"))); // 
> expected-warning {{'visibility' attribute is ignored on a non-external 
> symbol}}
>
> Modified: cfe/trunk/test/SemaCXX/ast-print.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/ast-print.cpp?rev=359814&r1=359813&r2=359814&view=diff
> 

[PATCH] D51329: [Attribute/Diagnostics] Print macro if definition is an attribute declaration

[Leonard Chan via Phabricator via cfe-commits]

leonardchan added a comment.

In D51329#1488918 , @JDevlieghere 
wrote:

> I think this is change is causing an assertion to be hit:
>
> http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/25103/consoleFull#-239233992d489585b-5106-414a-ac11-3ff90657619c
>  http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/56122/console
>
> Can you have a look?


I've noticed it. Still looking at it. I'll revert this if I don't figure out 
what's causing it by the end of the night.


Repository:
  rC Clang

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

https://reviews.llvm.org/D51329



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

[PATCH] D51329: [Attribute/Diagnostics] Print macro if definition is an attribute declaration

[Jonas Devlieghere via Phabricator via cfe-commits]

JDevlieghere added a comment.

I think this is change is causing an assertion to be hit:

http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/25103/consoleFull#-239233992d489585b-5106-414a-ac11-3ff90657619c
http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/56122/console

Can you have a look?


Repository:
  rC Clang

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

https://reviews.llvm.org/D51329



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

[PATCH] D61357: SemaOverload: Complete candidates before emitting the error, to ensure diagnostics emitted (or suppressed) during completion don't interfere with the overload notes

[David Blaikie via Phabricator via cfe-commits]

dblaikie marked an inline comment as done.
dblaikie added a comment.

In D61357#1488839 , @rsmith wrote:

> In D61357#1485581 , @dblaikie wrote:
>
> > Oh, @rsmith - if there's any better/different testing (if you can figure 
> > out how to reduce the test case down further, now that we know the cause - 
> > or if you'd like testing for other codepaths I've touched in this patch) 
> > I'm all ears. (also naming/API wrangling - my changes were just the minimal 
> > sort of "this works" based on what we discussed, but totally happy to do 
> > more involved/different things if there's such to be done)
>
>
> Perhaps we could add a diagnostic scope object of some kind, which would 
> assert (or reorder the diagnostics?) if a diagnostic is produced while 
> producing notes for a different diagnostic. That might help for new code and 
> for places where we're aware -- or suspect -- there is a problem, but we 
> don't know where the existing bugs are and that doesn't help us find them. :(


Yeah, I was thinking about something like that. Yeah, doesn't seem any reason 
we couldn't retrofit something on top of the diagnostics infratsructure - or a 
utility in it that connects notes to their diagnostic & either asserts, or 
delays emission, etc.

I was thinking about that in the context of cleaning up /everything/ to use 
that, but yeah - we could do it as an incremental migration/as needed sort of 
thing.




Comment at: lib/Sema/SemaOverload.cpp:3518-3519
   << false << From->getType() << From->getSourceRange() << ToType;
   } else
 return false;
+

rsmith wrote:
> Can we avoid calling `CompleteCandidates` on this path?
Yeah, I raised up the two if conditions to a pre-check:

if (!(OvResult == OR_Ambiguous ||
  (OvResult == OR_No_Viable_Function && !CandidateSet.empty(
  return false;

auto Cands = ...
if (...Ambiguous)
  ...
else { // No_Viable_Function && !empty()
  ...
NoteCandidates

(open to other ideas, couldn't quite think of anything that didn't involve some 
duplication - either duplicating the conditions or the CompleteCandidates call, 
etc)


Repository:
  rC Clang

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

https://reviews.llvm.org/D61357



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

[PATCH] D61357: SemaOverload: Complete candidates before emitting the error, to ensure diagnostics emitted (or suppressed) during completion don't interfere with the overload notes

[David Blaikie via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rC359854: SemaOverload: Complete candidates before emitting 
the error, to ensure… (authored by dblaikie, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D61357?vs=197491&id=197901#toc

Repository:
  rC Clang

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

https://reviews.llvm.org/D61357

Files:
  include/clang/AST/TemplateName.h
  include/clang/Basic/PartialDiagnostic.h
  include/clang/Sema/Overload.h
  lib/AST/TemplateName.cpp
  lib/Sema/SemaCast.cpp
  lib/Sema/SemaExprCXX.cpp
  lib/Sema/SemaInit.cpp
  lib/Sema/SemaOverload.cpp
  lib/Sema/SemaStmt.cpp
  test/SemaCXX/overload-template.cpp

Index: lib/AST/TemplateName.cpp
===
--- lib/AST/TemplateName.cpp
+++ lib/AST/TemplateName.cpp
@@ -250,6 +250,20 @@
   return DB << NameStr;
 }
 
+const PartialDiagnostic&clang::operator<<(const PartialDiagnostic &PD,
+   TemplateName N) {
+  std::string NameStr;
+  llvm::raw_string_ostream OS(NameStr);
+  LangOptions LO;
+  LO.CPlusPlus = true;
+  LO.Bool = true;
+  OS << '\'';
+  N.print(OS, PrintingPolicy(LO));
+  OS << '\'';
+  OS.flush();
+  return PD << NameStr;
+}
+
 void TemplateName::dump(raw_ostream &OS) const {
   LangOptions LO;  // FIXME!
   LO.CPlusPlus = true;
Index: lib/Sema/SemaStmt.cpp
===
--- lib/Sema/SemaStmt.cpp
+++ lib/Sema/SemaStmt.cpp
@@ -2227,9 +2227,11 @@
   return Sema::FRS_Success;
 
 case Sema::FRS_NoViableFunction:
-  SemaRef.Diag(BeginRange->getBeginLoc(), diag::err_for_range_invalid)
-  << BeginRange->getType() << BEFFound;
-  CandidateSet->NoteCandidates(SemaRef, OCD_AllCandidates, BeginRange);
+  CandidateSet->NoteCandidates(
+  PartialDiagnosticAt(BeginRange->getBeginLoc(),
+  SemaRef.PDiag(diag::err_for_range_invalid)
+  << BeginRange->getType() << BEFFound),
+  SemaRef, OCD_AllCandidates, BeginRange);
   LLVM_FALLTHROUGH;
 
 case Sema::FRS_DiagnosticIssued:
@@ -2526,9 +2528,12 @@
   // Otherwise, emit diagnostics if we haven't already.
   if (RangeStatus == FRS_NoViableFunction) {
 Expr *Range = BEFFailure ? EndRangeRef.get() : BeginRangeRef.get();
-Diag(Range->getBeginLoc(), diag::err_for_range_invalid)
-<< RangeLoc << Range->getType() << BEFFailure;
-CandidateSet.NoteCandidates(*this, OCD_AllCandidates, Range);
+CandidateSet.NoteCandidates(
+PartialDiagnosticAt(Range->getBeginLoc(),
+PDiag(diag::err_for_range_invalid)
+<< RangeLoc << Range->getType()
+<< BEFFailure),
+*this, OCD_AllCandidates, Range);
   }
   // Return an error if no fix was discovered.
   if (RangeStatus != FRS_Success)
Index: lib/Sema/SemaOverload.cpp
===
--- lib/Sema/SemaOverload.cpp
+++ lib/Sema/SemaOverload.cpp
@@ -3505,18 +3505,25 @@
   OverloadingResult OvResult =
 IsUserDefinedConversion(*this, From, ToType, ICS.UserDefined,
 CandidateSet, false, false);
+
+  if (!(OvResult == OR_Ambiguous ||
+(OvResult == OR_No_Viable_Function && !CandidateSet.empty(
+return false;
+
+  auto Cands = CandidateSet.CompleteCandidates(*this, OCD_AllCandidates, From);
   if (OvResult == OR_Ambiguous)
 Diag(From->getBeginLoc(), diag::err_typecheck_ambiguous_condition)
 << From->getType() << ToType << From->getSourceRange();
-  else if (OvResult == OR_No_Viable_Function && !CandidateSet.empty()) {
+  else { // OR_No_Viable_Function && !CandidateSet.empty()
 if (!RequireCompleteType(From->getBeginLoc(), ToType,
  diag::err_typecheck_nonviable_condition_incomplete,
  From->getType(), From->getSourceRange()))
   Diag(From->getBeginLoc(), diag::err_typecheck_nonviable_condition)
   << false << From->getType() << From->getSourceRange() << ToType;
-  } else
-return false;
-  CandidateSet.NoteCandidates(*this, OCD_AllCandidates, From);
+  }
+
+  CandidateSet.NoteCandidates(
+  *this, From, Cands);
   return true;
 }
 
@@ -10745,11 +10752,9 @@
   }
 }
 
-/// When overload resolution fails, prints diagnostic messages containing the
-/// candidates in the candidate set.
-void OverloadCandidateSet::NoteCandidates(
+SmallVector OverloadCandidateSet::CompleteCandidates(
 Sema &S, OverloadCandidateDisplayKind OCD, ArrayRef Args,
-StringRef Opc, SourceLocation OpLoc,
+SourceLocation OpLoc,
 llvm::function_ref Filter) {
   // Sort the candidates by viability and positi

r359854 - SemaOverload: Complete candidates before emitting the error, to ensure diagnostics emitted (or suppressed) during completion don't interfere with the overload notes

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Thu May  2 17:44:50 2019
New Revision: 359854

URL: http://llvm.org/viewvc/llvm-project?rev=359854&view=rev
Log:
SemaOverload: Complete candidates before emitting the error, to ensure 
diagnostics emitted (or suppressed) during completion don't interfere with the 
overload notes

Because diagnostics and their notes are not connected at the API level,
if the error message for an overload is emitted, then the overload
candidates are completed - if a diagnostic is emitted during that work,
the notes related to overload candidates would be attached to the latter
diagnostic, not the original error. Sort of worse, if the latter
diagnostic was disabled, the notes are disabled.

Reviewers: rsmith

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

Added:
cfe/trunk/test/SemaCXX/overload-template.cpp
Modified:
cfe/trunk/include/clang/AST/TemplateName.h
cfe/trunk/include/clang/Basic/PartialDiagnostic.h
cfe/trunk/include/clang/Sema/Overload.h
cfe/trunk/lib/AST/TemplateName.cpp
cfe/trunk/lib/Sema/SemaCast.cpp
cfe/trunk/lib/Sema/SemaExprCXX.cpp
cfe/trunk/lib/Sema/SemaInit.cpp
cfe/trunk/lib/Sema/SemaOverload.cpp
cfe/trunk/lib/Sema/SemaStmt.cpp

Modified: cfe/trunk/include/clang/AST/TemplateName.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/TemplateName.h?rev=359854&r1=359853&r2=359854&view=diff
==
--- cfe/trunk/include/clang/AST/TemplateName.h (original)
+++ cfe/trunk/include/clang/AST/TemplateName.h Thu May  2 17:44:50 2019
@@ -31,6 +31,7 @@ class NamedDecl;
 class NestedNameSpecifier;
 enum OverloadedOperatorKind : int;
 class OverloadedTemplateStorage;
+class PartialDiagnostic;
 struct PrintingPolicy;
 class QualifiedTemplateName;
 class SubstTemplateTemplateParmPackStorage;
@@ -319,6 +320,8 @@ public:
 /// into a diagnostic with <<.
 const DiagnosticBuilder &operator<<(const DiagnosticBuilder &DB,
 TemplateName N);
+const PartialDiagnostic &operator<<(const PartialDiagnostic &PD,
+TemplateName N);
 
 /// A structure for storing the information associated with a
 /// substituted template template parameter.

Modified: cfe/trunk/include/clang/Basic/PartialDiagnostic.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/PartialDiagnostic.h?rev=359854&r1=359853&r2=359854&view=diff
==
--- cfe/trunk/include/clang/Basic/PartialDiagnostic.h (original)
+++ cfe/trunk/include/clang/Basic/PartialDiagnostic.h Thu May  2 17:44:50 2019
@@ -16,6 +16,7 @@
 #define LLVM_CLANG_BASIC_PARTIALDIAGNOSTIC_H
 
 #include "clang/Basic/Diagnostic.h"
+#include "clang/Basic/PartialDiagnostic.h"
 #include "clang/Basic/LLVM.h"
 #include "clang/Basic/SourceLocation.h"
 #include "llvm/ADT/SmallVector.h"

Modified: cfe/trunk/include/clang/Sema/Overload.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Overload.h?rev=359854&r1=359853&r2=359854&view=diff
==
--- cfe/trunk/include/clang/Sema/Overload.h (original)
+++ cfe/trunk/include/clang/Sema/Overload.h Thu May  2 17:44:50 2019
@@ -961,13 +961,23 @@ class Sema;
 OverloadingResult BestViableFunction(Sema &S, SourceLocation Loc,
  OverloadCandidateSet::iterator& Best);
 
-void NoteCandidates(Sema &S,
-OverloadCandidateDisplayKind OCD,
-ArrayRef Args,
+SmallVector CompleteCandidates(
+Sema &S, OverloadCandidateDisplayKind OCD, ArrayRef Args,
+SourceLocation OpLoc = SourceLocation(),
+llvm::function_ref Filter =
+[](OverloadCandidate &) { return true; });
+
+void NoteCandidates(
+PartialDiagnosticAt PA, Sema &S, OverloadCandidateDisplayKind OCD,
+ArrayRef Args, StringRef Opc = "",
+SourceLocation Loc = SourceLocation(),
+llvm::function_ref Filter =
+[](OverloadCandidate &) { return true; });
+
+void NoteCandidates(Sema &S, ArrayRef Args,
+ArrayRef Cands,
 StringRef Opc = "",
-SourceLocation Loc = SourceLocation(),
-llvm::function_ref Filter =
-  [](OverloadCandidate&) { return true; });
+SourceLocation OpLoc = SourceLocation());
   };
 
   bool isBetterOverloadCandidate(Sema &S,

Modified: cfe/trunk/lib/AST/TemplateName.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/TemplateName.cpp?rev=359854&r1=359853&r2=359854&view=diff
==
--- cfe/trunk/lib/AST/TemplateName.cpp (original)
+++ cfe/trunk/lib/AST/TemplateName.cpp Thu May  2 17:44:50 2019
@@ -250,6 +250,20 @@ co

[PATCH] D61399: [OpenMP][Clang] Support for target math functions

[Hal Finkel via Phabricator via cfe-commits]

hfinkel added a comment.

In D61399#1488366 , @ABataev wrote:

> In D61399#1488329 , @hfinkel wrote:
>
> > In D61399#1488309 , @ABataev wrote:
> >
> > > In D61399#1488299 , @hfinkel 
> > > wrote:
> > >
> > > > In D61399#1488262 , @ABataev 
> > > > wrote:
> > > >
> > > > > I don't like this implementation. Seems to me, it breaks one of the 
> > > > > OpenMP standard requirements: the program can be compiled without 
> > > > > openmp support. I assume, that with this includes the program won't 
> > > > > be able to be compiled without OpenMP support anymore because it may 
> > > > > use some device-specific math functions explicitly.
> > > > >  Instead, I would like to see some additional, device-scpecific math 
> > > > > header file, that must be included explicitly to support some 
> > > > > device-specific math functions. And we need to provide default 
> > > > > implementations for those extra math functions for all the platforms 
> > > > > we're going to support, including default host implementations.
> > > >
> > > >
> > > > Can you provide an example of a conforming program that can't be 
> > > > compiled without OpenMP support? Regardless of the use of any 
> > > > device-specific functions (which isn't covered by the standard, of 
> > > > course, but might be needed in practice), the code still needs to be 
> > > > compilable by the host in order to generate the host-fallback version. 
> > > > This doesn't change that. Thus, any program that uses anything from 
> > > > this math.h, etc. needs to compile for the host, and thus, likely 
> > > > compiles without OpenMP support. Maybe I'm missing your point, however.
> > >
> > >
> > > Assume we have something like this:
> > >
> > >   #pragma omp target if(cond)
> > >   a = __nv_();
> > >
> > >
> > > Instead of `__nv_xxx` you can try to use any Cuda-specific function, 
> > > which is not the part of the standard `math.h`/`cmath` files. Will it be 
> > > compilable even with OpenMP?
> >
> >
> > I don't think that this changes that one way or the other. Your example 
> > won't work, AFAIK, unless you do something like:
> >
> >   #pragma omp target if(cond)
> >   #ifdef __NVPTX__
> >   a = __nv_();
> >   #else
> >   a = something_on_the_host;
> >   #endif
> >   
> >
> > and anything from these headers that doesn't also have a host version will 
> > suffer the same fate: if it won't also compile for the host (one way or 
> > another), then it won't work.
>
>
> The problem with this header file is that it allows to use those 
> Cuda-specific functions unconditionally in some cases:
>
>   #pragma omp target
>   a = __nv_();
>
>
> It won't require any target-specific guards to compile this code (if we 
> compile it only for Cuda-specific devices) and we're loosing the consistency 
> here: in some cases target regions will require special device guards, in 
> others, with the same function calls, it is not. And the worst thing, is that 
> we implicitly allow to introduce this kind of incostistency into users code. 
> That's why I would prefer to see a special kind of the include file, NVPTX 
> specific, that must be included explicitly, so the user explictly commanded 
> to use some target-specific math functions, if he really wants it. Plus, 
> maybe, in this files we need force check of the platform and warn users that 
> the functions from this header file must be used using device-specific 
> checks. Or provide some kind of the default implementations for all the 
> platforms, that do not support those math function natively.


I believe that I understand your point, but two things:

1. I think that you're mistaken on the underlying premise. That code will not 
meaningfully compile without ifdefs, even if only CUDA-specific devices are the 
only ones selected. We *always* compile code for the host as well, not for 
offloading proper, but for the fallback (for execution when the offloading 
fails). If I emulate this situation by writing this:



  #ifdef __NVPTX__
  int __nv_floor();
  #endif
  
  int main() {
  #pragma omp target
  __nv_floor();
  }

and try to compile using Clang with -fopenmp -fopenmp-targets=nvptx64, the 
compilation fails:

  int1.cpp:8:1: error: use of undeclared identifier '__nv_floor'

and this is because, when we invoke the compilation for the host, there is no 
declaration for that function. This is true even though nvptx64 is the only 
target for which the code is being compiled (because we always also compile the 
host fallback).

2. I believe that the future state -- what we get by following this patch, and 
then when declare variant is available using that -- gives us all what we want. 
When we have declare variant, then all of the definitions in these headers will 
be declared as variants only available

[PATCH] D61464: [RiscV] Typo in register aliases

[James Clarke via Phabricator via cfe-commits]

jrtc27 added a comment.

Ouch; LGTM.


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

https://reviews.llvm.org/D61464



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

[PATCH] D61464: [RiscV] Typo in register aliases

[Eric Christopher via Phabricator via cfe-commits]

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

LGTM. Sorry I didn't notice this earlier.

-eric


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

https://reviews.llvm.org/D61464



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

[PATCH] D61357: SemaOverload: Complete candidates before emitting the error, to ensure diagnostics emitted (or suppressed) during completion don't interfere with the overload notes

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

In D61357#1485581 , @dblaikie wrote:

> Oh, @rsmith - if there's any better/different testing (if you can figure out 
> how to reduce the test case down further, now that we know the cause - or if 
> you'd like testing for other codepaths I've touched in this patch) I'm all 
> ears. (also naming/API wrangling - my changes were just the minimal sort of 
> "this works" based on what we discussed, but totally happy to do more 
> involved/different things if there's such to be done)


Perhaps we could add a diagnostic scope object of some kind, which would assert 
(or reorder the diagnostics?) if a diagnostic is produced while producing notes 
for a different diagnostic. That might help for new code and for places where 
we're aware -- or suspect -- there is a problem, but we don't know where the 
existing bugs are and that doesn't help us find them. :(


Repository:
  rC Clang

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

https://reviews.llvm.org/D61357



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

[PATCH] D61357: SemaOverload: Complete candidates before emitting the error, to ensure diagnostics emitted (or suppressed) during completion don't interfere with the overload notes

[Richard Smith - zygoloid via Phabricator via cfe-commits]

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

LGTM, thanks!




Comment at: lib/Sema/SemaOverload.cpp:3518-3519
   << false << From->getType() << From->getSourceRange() << ToType;
   } else
 return false;
+

Can we avoid calling `CompleteCandidates` on this path?


Repository:
  rC Clang

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

https://reviews.llvm.org/D61357



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

r359844 - Fix -Wunsequenced false-positives in code controlled by a branch on

[Richard Smith via cfe-commits]

Author: rsmith
Date: Thu May  2 16:21:28 2019
New Revision: 359844

URL: http://llvm.org/viewvc/llvm-project?rev=359844&view=rev
Log:
Fix -Wunsequenced false-positives in code controlled by a branch on
__builtin_constant_p.

If the operand of __builtin_constant_p is not constant and has
side-effects, then code controlled by a branch on it is unreachable and
we should not emit runtime behavior warnings in such code.

Modified:
cfe/trunk/lib/AST/ExprConstant.cpp
cfe/trunk/test/Sema/warn-unsequenced.c

Modified: cfe/trunk/lib/AST/ExprConstant.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprConstant.cpp?rev=359844&r1=359843&r2=359844&view=diff
==
--- cfe/trunk/lib/AST/ExprConstant.cpp (original)
+++ cfe/trunk/lib/AST/ExprConstant.cpp Thu May  2 16:21:28 2019
@@ -8269,11 +8269,14 @@ bool IntExprEvaluator::VisitBuiltinCallE
 
   case Builtin::BI__builtin_constant_p: {
 const Expr *Arg = E->getArg(0);
-if (EvaluateBuiltinConstantP(Info, Arg))
+if (EvaluateBuiltinConstantP(Info, Arg)) {
   return Success(true, E);
-else if (Info.InConstantContext)
+} else if (Info.InConstantContext || Arg->HasSideEffects(Info.Ctx)) {
+  // Outside a constant context, eagerly evaluate to false in the presence
+  // of side-effects in order to avoid -Wunsequenced false-positives in
+  // a branch on __builtin_constant_p(expr).
   return Success(false, E);
-else {
+} else {
   Info.FFDiag(E, diag::note_invalid_subexpr_in_const_expr);
   return false;
 }

Modified: cfe/trunk/test/Sema/warn-unsequenced.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/warn-unsequenced.c?rev=359844&r1=359843&r2=359844&view=diff
==
--- cfe/trunk/test/Sema/warn-unsequenced.c (original)
+++ cfe/trunk/test/Sema/warn-unsequenced.c Thu May  2 16:21:28 2019
@@ -93,4 +93,6 @@ void test() {
   _Generic(++a, default: 0) + ++a; // ok
   sizeof(++a) + ++a; // ok
   _Alignof(++a) + ++a; // expected-warning {{extension}}
+
+  __builtin_constant_p(f(++a, 0)) ? f(f(++a, 0), f(++a, 0)) : 0;
 }


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

[PATCH] D60934: [clang] adding explicit(bool) from c++2a

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 added a comment.

Also please update
https://clang.llvm.org/cxx_status.html


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

https://reviews.llvm.org/D60934



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

[PATCH] D61454: [CodeGen][ObjC] Remove the leading 'l_' from ObjC symbols and make private symbols in the __DATA segment internal.

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: lib/CodeGen/CGObjCMac.cpp:3961
+  // linkage so that the linker preserves the symbol name.
+  llvm::GlobalValue::LinkageTypes LT = ExplicitDataSegment || Section.empty()
+   ? llvm::GlobalValue::InternalLinkage

ahatanak wrote:
> vsk wrote:
> > Hm. I wonder whether it'd be less error-prone to simply define LT as 
> > 'Section.empty() || Section.startswith("__DATA")'. Is there an advantage to 
> > explicitly defining 'ExplicitDataSegment' in the caller? 
> I was just trying to avoid scanning the string, but probably doing so isn't 
> that expensive.
Yeah, probably not.  I'd love it if there was some better way to specify these 
sections that felt less Mach-O-specific and more semantic, but given what we're 
doing, I think it'd be cleaner to scan the section name.

Or you could just pass the linkage down; I'm not sure DATA vs. OBJC is the only 
interesting division between things.


Repository:
  rC Clang

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

https://reviews.llvm.org/D61454



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

[PATCH] D61452: [WebAssembly] Always include /lib in library path

[Dan Gohman via Phabricator via cfe-commits]

sunfish added a comment.

If "$sysroot/lib" ends up coming to mean "wasm32" because people come to depend 
on that, then wasm64 may end up needing to be different in a gratuitous way, 
which I'd like to avoid.

I'd like to keep our sysroots tidy when we can. If some libraries are installed 
in `lib/wasm32-wasi` and others `lib` for no reason other than build script 
inertia, that's untidy.

It's not an absolute for me, but I am inclined to see if we can understand the 
need better first. Single-arch sysroots are possible either way, for example.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61452



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

[PATCH] D61454: [CodeGen][ObjC] Remove the leading 'l_' from ObjC symbols and make private symbols in the __DATA segment internal.

[Akira Hatanaka via Phabricator via cfe-commits]

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



Comment at: lib/CodeGen/CGObjCMac.cpp:3961
+  // linkage so that the linker preserves the symbol name.
+  llvm::GlobalValue::LinkageTypes LT = ExplicitDataSegment || Section.empty()
+   ? llvm::GlobalValue::InternalLinkage

vsk wrote:
> Hm. I wonder whether it'd be less error-prone to simply define LT as 
> 'Section.empty() || Section.startswith("__DATA")'. Is there an advantage to 
> explicitly defining 'ExplicitDataSegment' in the caller? 
I was just trying to avoid scanning the string, but probably doing so isn't 
that expensive.


Repository:
  rC Clang

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

https://reviews.llvm.org/D61454



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

[PATCH] D61470: [CUDA] Do not pass deprecated option fo fatbinary

[Artem Belevich via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rC359838: [CUDA] Do not pass deprecated option fo fatbinary 
(authored by tra, committed by ).
Herald added a project: clang.

Changed prior to commit:
  https://reviews.llvm.org/D61470?vs=197876&id=197880#toc

Repository:
  rC Clang

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

https://reviews.llvm.org/D61470

Files:
  lib/Driver/ToolChains/Cuda.cpp


Index: lib/Driver/ToolChains/Cuda.cpp
===
--- lib/Driver/ToolChains/Cuda.cpp
+++ lib/Driver/ToolChains/Cuda.cpp
@@ -454,7 +454,8 @@
   assert(TC.getTriple().isNVPTX() && "Wrong platform");
 
   ArgStringList CmdArgs;
-  CmdArgs.push_back("--cuda");
+  if (TC.CudaInstallation.version() <= CudaVersion::CUDA_100)
+CmdArgs.push_back("--cuda");
   CmdArgs.push_back(TC.getTriple().isArch64Bit() ? "-64" : "-32");
   CmdArgs.push_back(Args.MakeArgString("--create"));
   CmdArgs.push_back(Args.MakeArgString(Output.getFilename()));


Index: lib/Driver/ToolChains/Cuda.cpp
===
--- lib/Driver/ToolChains/Cuda.cpp
+++ lib/Driver/ToolChains/Cuda.cpp
@@ -454,7 +454,8 @@
   assert(TC.getTriple().isNVPTX() && "Wrong platform");
 
   ArgStringList CmdArgs;
-  CmdArgs.push_back("--cuda");
+  if (TC.CudaInstallation.version() <= CudaVersion::CUDA_100)
+CmdArgs.push_back("--cuda");
   CmdArgs.push_back(TC.getTriple().isArch64Bit() ? "-64" : "-32");
   CmdArgs.push_back(Args.MakeArgString("--create"));
   CmdArgs.push_back(Args.MakeArgString(Output.getFilename()));
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r359838 - [CUDA] Do not pass deprecated option fo fatbinary

[Artem Belevich via cfe-commits]

Author: tra
Date: Thu May  2 15:37:19 2019
New Revision: 359838

URL: http://llvm.org/viewvc/llvm-project?rev=359838&view=rev
Log:
[CUDA] Do not pass deprecated option fo fatbinary

CUDA 10.1 tools deprecated some command line options.
fatbinary no longer needs --cuda.

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

Modified:
cfe/trunk/lib/Driver/ToolChains/Cuda.cpp

Modified: cfe/trunk/lib/Driver/ToolChains/Cuda.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Cuda.cpp?rev=359838&r1=359837&r2=359838&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Cuda.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Cuda.cpp Thu May  2 15:37:19 2019
@@ -454,7 +454,8 @@ void NVPTX::Linker::ConstructJob(Compila
   assert(TC.getTriple().isNVPTX() && "Wrong platform");
 
   ArgStringList CmdArgs;
-  CmdArgs.push_back("--cuda");
+  if (TC.CudaInstallation.version() <= CudaVersion::CUDA_100)
+CmdArgs.push_back("--cuda");
   CmdArgs.push_back(TC.getTriple().isArch64Bit() ? "-64" : "-32");
   CmdArgs.push_back(Args.MakeArgString("--create"));
   CmdArgs.push_back(Args.MakeArgString(Output.getFilename()));


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

[PATCH] D61454: [CodeGen][ObjC] Remove the leading 'l_' from ObjC symbols and make private symbols in the __DATA segment internal.

[Vedant Kumar via Phabricator via cfe-commits]

vsk added inline comments.



Comment at: lib/CodeGen/CGObjCMac.cpp:3961
+  // linkage so that the linker preserves the symbol name.
+  llvm::GlobalValue::LinkageTypes LT = ExplicitDataSegment || Section.empty()
+   ? llvm::GlobalValue::InternalLinkage

Hm. I wonder whether it'd be less error-prone to simply define LT as 
'Section.empty() || Section.startswith("__DATA")'. Is there an advantage to 
explicitly defining 'ExplicitDataSegment' in the caller? 


Repository:
  rC Clang

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

https://reviews.llvm.org/D61454



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

[PATCH] D61454: [CodeGen][ObjC] Remove the leading 'l_' from ObjC symbols and make private symbols in the __DATA segment internal.

[Akira Hatanaka via Phabricator via cfe-commits]

ahatanak updated this revision to Diff 197877.
ahatanak marked 6 inline comments as done.
ahatanak edited the summary of this revision.
ahatanak added a comment.

Address review comments.


Repository:
  rC Clang

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

https://reviews.llvm.org/D61454

Files:
  lib/CodeGen/CGObjCMac.cpp
  test/CodeGenObjC/arc.m
  test/CodeGenObjC/boxing.m
  test/CodeGenObjC/exceptions-asm-attribute.m
  test/CodeGenObjC/externally-initialized-selectors.m
  test/CodeGenObjC/forward-protocol-metadata-symbols.m
  test/CodeGenObjC/instance-method-metadata.m
  test/CodeGenObjC/interface-layout-64.m
  test/CodeGenObjC/metadata-class-properties.m
  test/CodeGenObjC/metadata-symbols-32.m
  test/CodeGenObjC/metadata-symbols-64.m
  test/CodeGenObjC/metadata_symbols.m
  test/CodeGenObjC/mrc-weak.m
  test/CodeGenObjC/non-lazy-classes.m
  test/CodeGenObjC/ns-constant-strings.m
  test/CodeGenObjC/private-extern-selector-reference.m
  test/CodeGenObjC/property-category-impl.m
  test/CodeGenObjC/property-list-in-class.m
  test/CodeGenObjC/property-list-in-extension.m
  test/CodeGenObjC/protocol-comdat.m
  test/CodeGenObjC/protocols.m
  test/CodeGenObjC/section-name.m
  test/CodeGenObjC/sections.m
  test/CodeGenObjCXX/externally-initialized-selectors.mm
  test/CodeGenObjCXX/mrc-weak.mm

Index: test/CodeGenObjCXX/mrc-weak.mm
===
--- test/CodeGenObjCXX/mrc-weak.mm
+++ test/CodeGenObjCXX/mrc-weak.mm
@@ -7,7 +7,7 @@
 @end
 
 // CHECK-MODERN: @OBJC_CLASS_NAME_{{.*}} = {{.*}} c"\01\00"
-// CHECK-MODERN: @"\01l_OBJC_CLASS_RO_$_Foo" = {{.*}} { i32 772
+// CHECK-MODERN: @"_OBJC_CLASS_RO_$_Foo" = {{.*}} { i32 772
 //   772 == 0x304
 //^ HasMRCWeakIvars
 //^ HasCXXDestructorOnly
Index: test/CodeGenObjCXX/externally-initialized-selectors.mm
===
--- test/CodeGenObjCXX/externally-initialized-selectors.mm
+++ test/CodeGenObjCXX/externally-initialized-selectors.mm
@@ -1,7 +1,8 @@
-// RUN: %clang_cc1 -fobjc-runtime=macosx-fragile-10.5 -o - -emit-llvm %s | FileCheck %s
-// RUN: %clang_cc1 -o - -emit-llvm %s | FileCheck %s
+// RUN: %clang_cc1 -fobjc-runtime=macosx-fragile-10.5 -o - -emit-llvm %s | FileCheck -check-prefix=FRAGILE %s
+// RUN: %clang_cc1 -o - -emit-llvm %s | FileCheck -check-prefix=NONFRAGILE %s
 
-// CHECK: @OBJC_SELECTOR_REFERENCES_ = private externally_initialized global
+// NONFRAGILE: @OBJC_SELECTOR_REFERENCES_ = internal externally_initialized global
+// FRAGILE: @OBJC_SELECTOR_REFERENCES_ = private externally_initialized global
 
 void test(id x) {
   [x doSomething];
Index: test/CodeGenObjC/sections.m
===
--- test/CodeGenObjC/sections.m
+++ test/CodeGenObjC/sections.m
@@ -37,9 +37,9 @@
 // CHECK-COFF: @"OBJC_CLASSLIST_SUP_REFS_$_" = {{.*}}, section ".objc_superrefs$B"
 // CHECK-COFF: @OBJC_SELECTOR_REFERENCES_ = {{.*}}, section ".objc_selrefs$B"
 // CHECK-COFF: @"OBJC_CLASSLIST_REFERENCES_$_" = {{.*}}, section ".objc_classrefs$B"
-// CHECK-COFF: @"\01l_objc_msgSend_fixup_class" = {{.*}}, section ".objc_msgrefs$B"
+// CHECK-COFF: @_objc_msgSend_fixup_class = {{.*}}, section ".objc_msgrefs$B"
 // CHECK-COFF: @"_OBJC_LABEL_PROTOCOL_$_P" = {{.*}}, section ".objc_protolist$B"
-// CHECK-COFF: @"\01l_OBJC_PROTOCOL_REFERENCE_$_P" = {{.*}}, section ".objc_protorefs$B"
+// CHECK-COFF: @"_OBJC_PROTOCOL_REFERENCE_$_P" = {{.*}}, section ".objc_protorefs$B"
 // CHECK-COFF: @"OBJC_LABEL_CLASS_$" = {{.*}}, section ".objc_classlist$B"
 // CHECK-COFF: @"OBJC_LABEL_NONLAZY_CLASS_$" = {{.*}}, section ".objc_nlclslist$B"
 // CHECK-COFF: @"OBJC_LABEL_CATEGORY_$" = {{.*}}, section ".objc_catlist$B"
@@ -49,9 +49,9 @@
 // CHECK-ELF: @"OBJC_CLASSLIST_SUP_REFS_$_" = {{.*}}, section "objc_superrefs"
 // CHECK-ELF: @OBJC_SELECTOR_REFERENCES_ = {{.*}}, section "objc_selrefs"
 // CHECK-ELF: @"OBJC_CLASSLIST_REFERENCES_$_" = {{.*}}, section "objc_classrefs"
-// CHECK-ELF: @"\01l_objc_msgSend_fixup_class" = {{.*}}, section "objc_msgrefs"
+// CHECK-ELF: @_objc_msgSend_fixup_class = {{.*}}, section "objc_msgrefs"
 // CHECK-ELF: @"_OBJC_LABEL_PROTOCOL_$_P" = {{.*}}, section "objc_protolist"
-// CHECK-ELF: @"\01l_OBJC_PROTOCOL_REFERENCE_$_P" = {{.*}}, section "objc_protorefs"
+// CHECK-ELF: @"_OBJC_PROTOCOL_REFERENCE_$_P" = {{.*}}, section "objc_protorefs"
 // CHECK-ELF: @"OBJC_LABEL_CLASS_$" = {{.*}}, section "objc_classlist"
 // CHECK-ELF: @"OBJC_LABEL_NONLAZY_CLASS_$" = {{.*}}, section "objc_nlclslist"
 // CHECK-ELF: @"OBJC_LABEL_CATEGORY_$" = {{.*}}, section "objc_catlist"
@@ -61,9 +61,9 @@
 // CHECK-MACHO: @"OBJC_CLASSLIST_SUP_REFS_$_" = {{.*}}, section "__DATA,__objc_superrefs,regular,no_dead_strip"
 // CHECK-MACHO: @OBJC_SELECTOR_REFERENCES_ = {{.*}}, section "__DATA,__objc_selrefs,literal_pointers,no_dead_strip"
 // CHECK-MACHO: @"OBJC_CLASSLIST_REFERENCES_$_" = {{.*}}, section "__DATA,__objc_cl

[PATCH] D60934: [clang] adding explicit(bool) from c++2a

[Richard Smith - zygoloid via Phabricator via cfe-commits]

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

Looks good, thank you!




Comment at: clang/lib/Sema/SemaInit.cpp:9359
   //   The converting constructors of T are candidate functions.
   if (Kind.isCopyInit() && !ListInit) {
 // Only consider converting constructors.

Please simplify this to `if (!AllowExplicit)`


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

https://reviews.llvm.org/D60934



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

[PATCH] D61454: [CodeGen][ObjC] Remove the leading 'l_' from ObjC symbols and make private symbols in the __DATA segment internal.

[Akira Hatanaka via Phabricator via cfe-commits]

ahatanak added inline comments.



Comment at: lib/CodeGen/CGObjCMac.cpp:1978
+? llvm::GlobalVariable::InternalLinkage
+: llvm::GlobalValue::PrivateLinkage);
   // FIXME. Fix section.

rjmccall wrote:
> 1. Why are these using different classes to name these enumerators?
> 2. Why are we promoting to internal linkage in some cases?  That seems to be 
> an additional semantic change not discussed in the commit message, and it 
> should probably also get a good inline comment.
This is a mistake. It should have been `llvm::GlobalValue::InternalLinkage`.



Comment at: lib/CodeGen/CGObjCMac.cpp:1983
+  else
+GV->setSection("__OBJC,__cstring_object,regular,no_dead_strip");
+

vsk wrote:
> Are constant NSStrings within the shared cache ever dirtied? I was under the 
> impression that they couldn't be, so I'm not sure there's an advantage to 
> making them internal.
I was making all symbols in `__DATA` internal, but you are right, there isn't 
any advantage to making constant NSStrings internal for the purpose of this 
patch.


Repository:
  rC Clang

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

https://reviews.llvm.org/D61454



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

Re: r359809 - Use primary template parameter names for variable template debug info

[Richard Smith via cfe-commits]

On Thu, 2 May 2019 at 10:43, Reid Kleckner via cfe-commits
 wrote:
>
> Author: rnk
> Date: Thu May  2 10:45:54 2019
> New Revision: 359809
>
> URL: http://llvm.org/viewvc/llvm-project?rev=359809&view=rev
> Log:
> Use primary template parameter names for variable template debug info
>
> Summary:
> Fixes PR41677
>
> Consider:
>   template  constexpr bool is_same_v = false;
>   template  constexpr bool is_same_v = true;
>   template constexpr bool is_same_v;
>
> Before this change, when emitting debug info for the
> `is_same_v` global variable, clang would crash because it
> would try to use the template parameter list from the partial
> specialization to give parameter names to template arguments. This
> doesn't work in general, since a partial specialization can have fewer
> arguments than the primary template. Therefore, always use the primary
> template. Hypothetically we could try to use the parameter names from
> the partial specialization when possible, but it's not clear this really
> helps debugging in practice.

Hmm, consider:

template constexpr bool is_pointer = false;
template constexpr bool is_pointer = true;

If I somehow inspect is_pointer in a debugger, I think it'd be
surprising to find I had T=int* instead of T=int. (This is likely not
a big deal for a case like this, but there could be a lambda on the
right-hand side of the =, and stepping into that should put the right
set of things in scope.)

> Reviewers: JDevlieghere, aprantl, ormris, dblaikie
>
> Subscribers: cfe-commits
>
> Tags: #clang
>
> Differential Revision: https://reviews.llvm.org/D61408
>
> Added:
> cfe/trunk/test/CodeGenCXX/debug-info-var-template-partial.cpp
> Modified:
> cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> cfe/trunk/test/CodeGenCXX/debug-info-template-member.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=359809&r1=359808&r2=359809&view=diff
> ==
> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Thu May  2 10:45:54 2019
> @@ -1827,32 +1827,24 @@ CGDebugInfo::CollectFunctionTemplatePara
>  }
>
>  llvm::DINodeArray CGDebugInfo::CollectVarTemplateParams(const VarDecl *VL,
> -llvm::DIFile *Unit) {
> -  if (auto *TS = dyn_cast(VL)) {
> -auto T = TS->getSpecializedTemplateOrPartial();
> -auto TA = TS->getTemplateArgs().asArray();
> -// Collect parameters for a partial specialization
> -if (T.is()) {
> -  const TemplateParameterList *TList =
> -T.get()
> -->getTemplateParameters();
> -  return CollectTemplateParams(TList, TA, Unit);
> -}
> -
> -// Collect parameters for an explicit specialization
> -if (T.is()) {
> -  const TemplateParameterList *TList = T.get()
> -->getTemplateParameters();
> -  return CollectTemplateParams(TList, TA, Unit);
> -}
> -  }
> -  return llvm::DINodeArray();
> +llvm::DIFile *Unit) {
> +  // Always get the full list of parameters, not just the ones from the
> +  // specialization. A partial specialization may have fewer parameters than
> +  // there are arguments.
> +  auto *TS = dyn_cast(VL);
> +  if (!TS)
> +return llvm::DINodeArray();
> +  VarTemplateDecl *T = TS->getSpecializedTemplate();
> +  const TemplateParameterList *TList = T->getTemplateParameters();
> +  auto TA = TS->getTemplateArgs().asArray();
> +  return CollectTemplateParams(TList, TA, Unit);
>  }
>
>  llvm::DINodeArray CGDebugInfo::CollectCXXTemplateParams(
>  const ClassTemplateSpecializationDecl *TSpecial, llvm::DIFile *Unit) {
> -  // Always get the full list of parameters, not just the ones from
> -  // the specialization.
> +  // Always get the full list of parameters, not just the ones from the
> +  // specialization. A partial specialization may have fewer parameters than
> +  // there are arguments.
>TemplateParameterList *TPList =
>TSpecial->getSpecializedTemplate()->getTemplateParameters();
>const TemplateArgumentList &TAList = TSpecial->getTemplateArgs();
>
> Modified: cfe/trunk/test/CodeGenCXX/debug-info-template-member.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-template-member.cpp?rev=359809&r1=359808&r2=359809&view=diff
> ==
> --- cfe/trunk/test/CodeGenCXX/debug-info-template-member.cpp (original)
> +++ cfe/trunk/test/CodeGenCXX/debug-info-template-member.cpp Thu May  2 
> 10:45:54 2019
> @@ -30,7 +30,7 @@ inline int add3(int x) {
>  // CHECK: {{![0-9]+}} = distinct !DIGlobalVariable(
>  // CHECK-SAME: name: "var"
>  // CHECK-SAME: templateParams: {{![0-9]+}}
> -// CHECK: !DITemplateTypeParameter(name: "P", type: {{![0-9]+}})
> +// CHECK: !DITemplateTypeParameter(name: "T", type: {{![0-9]+}})
>  // CHECK: {{![0-9]+}} 

[PATCH] D61470: [CUDA] Do not pass deprecated option fo fatbinary

[Artem Belevich via Phabricator via cfe-commits]

tra created this revision.
tra added a reviewer: jlebar.
Herald added a subscriber: bixia.

CUDA 10.1 tools have deprecated some command line options, so fatbinary no 
longer needs --cuda parameter.


https://reviews.llvm.org/D61470

Files:
  clang/lib/Driver/ToolChains/Cuda.cpp


Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -454,7 +454,8 @@
   assert(TC.getTriple().isNVPTX() && "Wrong platform");
 
   ArgStringList CmdArgs;
-  CmdArgs.push_back("--cuda");
+  if (TC.CudaInstallation.version() <= CudaVersion::CUDA_100)
+CmdArgs.push_back("--cuda");
   CmdArgs.push_back(TC.getTriple().isArch64Bit() ? "-64" : "-32");
   CmdArgs.push_back(Args.MakeArgString("--create"));
   CmdArgs.push_back(Args.MakeArgString(Output.getFilename()));


Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -454,7 +454,8 @@
   assert(TC.getTriple().isNVPTX() && "Wrong platform");
 
   ArgStringList CmdArgs;
-  CmdArgs.push_back("--cuda");
+  if (TC.CudaInstallation.version() <= CudaVersion::CUDA_100)
+CmdArgs.push_back("--cuda");
   CmdArgs.push_back(TC.getTriple().isArch64Bit() ? "-64" : "-32");
   CmdArgs.push_back(Args.MakeArgString("--create"));
   CmdArgs.push_back(Args.MakeArgString(Output.getFilename()));
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61467: [Rewrite] Extend to further accept CharSourceRange

[Joel E. Denny via Phabricator via cfe-commits]

jdenny created this revision.
jdenny added reviewers: akyrtzi, Eugene.Zelenko, rsmith.
Herald added subscribers: dexonsmith, mgorny.
Herald added a project: clang.

Some Rewrite functions are already overloaded to accept CharSourceRange, and 
this extends others in the same manner.  I'm calling these in code that's not 
ready to upstream, but I figure they might be useful to others in the meantime.

This patch also adds some unit tests.  I'm not very familiar with unit testing 
here.  I used clangTooling to build the AST.  Is that appropriate?


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D61467

Files:
  clang/include/clang/Rewrite/Core/Rewriter.h
  clang/lib/Rewrite/Rewriter.cpp
  clang/unittests/Rewrite/CMakeLists.txt
  clang/unittests/Rewrite/RewriterTest.cpp

Index: clang/unittests/Rewrite/RewriterTest.cpp
===
--- /dev/null
+++ clang/unittests/Rewrite/RewriterTest.cpp
@@ -0,0 +1,65 @@
+//===- unittests/Rewrite/RewriteTest.cpp - RewriteBuffer tests ===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "clang/Rewrite/Core/Rewriter.h"
+#include "clang/Tooling/Tooling.h"
+#include "gtest/gtest.h"
+
+using namespace clang;
+
+namespace {
+
+struct RangeTypeTest {
+  std::unique_ptr AST;
+  Rewriter Rewrite;
+  SourceLocation FileStart;
+  CharSourceRange CRange;
+  CharSourceRange TRange;
+  SourceRange SRange;
+  SourceLocation makeLoc(int Off) { return FileStart.getLocWithOffset(Off); }
+  CharSourceRange makeCharRange(int StartOff, int EndOff) {
+return CharSourceRange::getCharRange(makeLoc(StartOff), makeLoc(EndOff));
+  }
+  RangeTypeTest(StringRef Code, int StartOff, int EndOff) {
+AST = tooling::buildASTFromCode(Code);
+ASTContext &C = AST->getASTContext();
+Rewrite = Rewriter(C.getSourceManager(), C.getLangOpts());
+FileStart = AST->getStartOfMainFileID();
+CRange = makeCharRange(StartOff, EndOff);
+SRange = CRange.getAsRange();
+TRange = CharSourceRange::getTokenRange(SRange);
+  }
+};
+
+TEST(Rewriter, GetRewrittenTextRangeTypes) {
+  StringRef Code = "int main() { return 0; }";
+  // ^~~+++
+  RangeTypeTest T(Code, 13, 16);
+  EXPECT_EQ(T.Rewrite.getRewrittenText(T.CRange), "ret");
+  EXPECT_EQ(T.Rewrite.getRewrittenText(T.TRange), "return");
+  EXPECT_EQ(T.Rewrite.getRewrittenText(T.SRange), "return");
+  T.Rewrite.InsertText(T.makeLoc(13), "x");
+  EXPECT_EQ(T.Rewrite.getRewrittenText(T.CRange), "xret");
+  EXPECT_EQ(T.Rewrite.getRewrittenText(T.TRange), "xreturn");
+  EXPECT_EQ(T.Rewrite.getRewrittenText(T.SRange), "xreturn");
+}
+
+TEST(Rewriter, ReplaceTextRangeTypes) {
+  StringRef Code = "int main(int argc, char *argv[]) { return argc; }";
+  //  ^~++
+  //  ^
+  RangeTypeTest T(Code, 42, 44);
+  T.Rewrite.ReplaceText(T.CRange, "foo");
+  EXPECT_EQ(T.Rewrite.getRewrittenText(T.makeCharRange(42, 47)), "foogc;");
+  T.Rewrite.ReplaceText(T.TRange, "bar");
+  EXPECT_EQ(T.Rewrite.getRewrittenText(T.makeCharRange(42, 47)), "bar;");
+  T.Rewrite.ReplaceText(T.SRange, "0");
+  EXPECT_EQ(T.Rewrite.getRewrittenText(T.makeCharRange(42, 47)), "0;");
+}
+
+} // anonymous namespace
Index: clang/unittests/Rewrite/CMakeLists.txt
===
--- clang/unittests/Rewrite/CMakeLists.txt
+++ clang/unittests/Rewrite/CMakeLists.txt
@@ -4,8 +4,10 @@
 
 add_clang_unittest(RewriteTests
   RewriteBufferTest.cpp
+  RewriterTest.cpp
   )
 target_link_libraries(RewriteTests
   PRIVATE
   clangRewrite
+  clangTooling
   )
Index: clang/lib/Rewrite/Rewriter.cpp
===
--- clang/lib/Rewrite/Rewriter.cpp
+++ clang/lib/Rewrite/Rewriter.cpp
@@ -170,7 +170,7 @@
 /// in different buffers, this returns an empty string.
 ///
 /// Note that this method is not particularly efficient.
-std::string Rewriter::getRewrittenText(SourceRange Range) const {
+std::string Rewriter::getRewrittenText(CharSourceRange Range) const {
   if (!isRewritable(Range.getBegin()) ||
   !isRewritable(Range.getEnd()))
 return {};
@@ -193,7 +193,9 @@
 
 // Adjust the end offset to the end of the last token, instead of being the
 // start of the last token.
-EndOff += Lexer::MeasureTokenLength(Range.getEnd(), *SourceMgr, *LangOpts);
+if (Range.isTokenRange())
+  EndOff += Lexer::MeasureTokenLength(Range.getEnd(), *SourceMgr,
+  *LangOpts);
 return std::string(Ptr, Ptr+EndOff-StartOff);
   }
 
@@ -203,7 +205,8 @@
 
   // Adjust the end offset to the en

[PATCH] D61458: [hip] Relax CUDA call restriction within `decltype` context.

[Artem Belevich via Phabricator via cfe-commits]

tra added inline comments.



Comment at: clang/include/clang/Sema/Sema.h:10407-10409
   bool IsAllowedCUDACall(const FunctionDecl *Caller,
  const FunctionDecl *Callee) {
+if (llvm::any_of(ExprEvalContexts,

One more thing. The idea of this function is that we're checking if the 
`Caller` is allowed to call the `Callee`.
However here, you're checking the current context, which may not necessarily be 
the same as the caller's. I.e. someone could potentially call it way after the 
context is gone.

Currently all uses of this function obtain the caller from `CurContext`, but if 
we start relying on other properties of the current context other than the 
caller function, then we may neet to pass the context explicitly, or only pass 
the Callee and check if it's callable from the current context.

```



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61458



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

[PATCH] D61165: Fix a crash where a [[no_destroy]] destructor was not emitted in an array

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In D61165#1488553 , @erik.pilkington 
wrote:

> In D61165#1487328 , @rjmccall wrote:
>
> > In D61165#1487100 , 
> > @erik.pilkington wrote:
> >
> > > It seems like the most common sense interpretation here is to just treat 
> > > the initialization of `G` as completed at the point when the constructor 
> > > finishes (this appears to be what GCC implements: 
> > > https://wandbox.org/permlink/R3C9pPhoT4efAdL1).
> >
> >
> > Your example doesn't actually demonstrate that that's what GCC implements 
> > because it doesn't try to execute the declaration twice.  But you're right, 
> > GCC does appear to consider the initialization complete as soon as the 
> > static object's constructor returns normally.  On the other hand, GCC gets 
> > the array case here wrong: if a static local has array type, and a 
> > destructor for a temporary required by the first element initializer 
> > throws, then it does not destroy the element but also (correctly) does not 
> > mark the variable as fully initialized, and so a second attempt to run the 
> > initializer will simply construct a new object on top of an 
> > already-constructed one.  This is arguably correct under the standard — the 
> > first array element is not a previously-constructed object of automatic 
> > duration — but I hope it's obvious that that's a defect.
> >
> > > So if it was static it would just get destroyed at exit-time, and 
> > > therefore should be disable-able with `no_destroy`. If the standard 
> > > implies that we should be doing something else, then we should do that, 
> > > but I can't seem to find any reference to the rule you're describing.
> >
> > Like I said, this is a poorly-specified part of the standard, because at 
> > least *some* objects with static storage duration have to be destroyed when 
> > an exception is thrown (because of aggregate initialization), but the 
> > standard wants to pretend that this isn't true.  I think that allowing 
> > temporary destructors to cancel initialization uniformly across all kinds 
> > of objects is the most consistent rule,
>
>
> That's only true for subobjects of an enclosing aggregate before that 
> aggregate's initialization is complete though, right? So it doesn't seem like 
> that much of an inconsistency, just mimicking what we would be doing if an 
> exception was thrown in, say, the body of the ctor before the object's 
> initialization is completed.


Conceptually yes, but formally no.  The standard *could* write this rule as 
"all currently-initialized subobjects must be separately destroyed when an 
exception aborts initialization of the containing aggregate, including 
constructor bodies and aggregate initialization", but it doesn't actually do 
so; instead it has specific rules covering the behavior when an exception is 
thrown out of the body of a constructor, and those rules simply do not apply to 
aggregate initialization.

Even if it did, though, that wouldn't tell us how to resolve this because this 
is fundamentally about when exactly the initialization of an object is 
"complete", which doesn't seem to be clearly defined in the standard.  There's 
a rule for when a *constructor* is complete, but among other things, not all 
initializations involve constructors.

>> but if the standard wants to use a rule that non-aggregate initialization of 
>> static and thread-local locals is complete as soon as the constructor (or 
>> assignment) completes, as opposed to the end of the full-expression, that's 
>> also implementable.
> 
> So what should that path forward be here? I'd really like to get this crash 
> fixed soon. If we want to consider a static local no_destroy dtor 
> potentially-invoked in Sema if the initializer has a temporary with a 
> throwing dtor, then we could do that, but it'd be unfortunate for 98/03 where 
> I believe a dtor isn't noexcept by default, so we'd have to assume the worst. 
> I guess it'd be easier to change our minds in the future if we treat the dtor 
> as potentially-invoked, but I'm not really seeing the argument that we 
> shouldn't just use this rule.

I think the simplest rule would be to say that the destructor must still be 
accessible for static or thread-local locals and that it'll be used in certain 
cases when initialization is aborted.

>> I guess it would also technically be feasible for repeated attempts at 
>> initialization to just pick up after the last subobject to be successfully 
>> constructed, although that would be really obnoxious to actually implement 
>> (and would require an ABI change for static local aggregates with vague 
>> linkage).
> 
> Yeah, that seems quite strange, especially if initialization got picked up in 
> another thread :)

Actually, cross-thread isn't a problem because the C++ runtime already 
serializes all initialization attempts.


CHANGES SINCE LAST ACT

[PATCH] D50860: [libc++][test] Remove non-portable assumption that thread's constructor allocates with ::new

[Casey Carter via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rCXX359827: [libc++][test] Remove non-portable assumption that 
thread's constructor… (authored by CaseyCarter, committed by ).
Herald added subscribers: libcxx-commits, jfb, ldionne.

Changed prior to commit:
  https://reviews.llvm.org/D50860?vs=171344&id=197868#toc

Repository:
  rCXX libc++

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

https://reviews.llvm.org/D50860

Files:
  
test/std/thread/thread.threads/thread.thread.class/thread.thread.constr/F.pass.cpp


Index: 
test/std/thread/thread.threads/thread.thread.class/thread.thread.constr/F.pass.cpp
===
--- 
test/std/thread/thread.threads/thread.thread.class/thread.thread.constr/F.pass.cpp
+++ 
test/std/thread/thread.threads/thread.thread.class/thread.thread.constr/F.pass.cpp
@@ -30,9 +30,10 @@
 
 void* operator new(std::size_t s) TEST_THROW_SPEC(std::bad_alloc)
 {
-if (throw_one == 0)
-TEST_THROW(std::bad_alloc());
---throw_one;
+unsigned expected = throw_one;
+do {
+if (expected == 0) TEST_THROW(std::bad_alloc());
+} while (!throw_one.compare_exchange_weak(expected, expected - 1));
 ++outstanding_new;
 void* ret = std::malloc(s);
 if (!ret) std::abort(); // placate MSVC's unchecked malloc warning
@@ -41,6 +42,7 @@
 
 void  operator delete(void* p) TEST_NOEXCEPT
 {
+if (!p) return;
 --outstanding_new;
 std::free(p);
 }
@@ -108,13 +110,17 @@
 //  B std::thread's constructor should properly handle exceptions and not leak
 //memory.
 // Plan:
-//  1 Create a thread and count the number of allocations, 'N', it performs.
+//  1 Create a thread and count the number of allocations, 'numAllocs', it
+//performs.
 //  2 For each allocation performed run a test where that allocation throws.
 //2.1 check that the exception can be caught in the parent thread.
 //2.2 Check that the functor has not been called.
 //2.3 Check that no memory allocated by the creation of the thread is 
leaked.
-//  3 Finally check that a thread runs successfully if we throw after 'N+1'
-//allocations.
+//  3 Finally check that a thread runs successfully if we throw after
+//'numAllocs + 1' allocations.
+
+int numAllocs;
+
 void test_throwing_new_during_thread_creation() {
 #ifndef TEST_HAS_NO_EXCEPTIONS
 throw_one = 0xFFF;
@@ -122,7 +128,7 @@
 std::thread t(f);
 t.join();
 }
-const int numAllocs = 0xFFF - throw_one;
+numAllocs = 0xFFF - throw_one;
 // i <= numAllocs means the last iteration is expected not to throw.
 for (int i=0; i <= numAllocs; ++i) {
 throw_one = i;
@@ -166,7 +172,10 @@
 }
 G::op_run = false;
 #ifndef TEST_HAS_NO_EXCEPTIONS
-{
+// The test below expects `std::thread` to call `new`, which may not be the
+// case for all implementations.
+LIBCPP_ASSERT(numAllocs > 0); // libc++ should call new.
+if (numAllocs > 0) {
 try
 {
 throw_one = 0;
@@ -175,7 +184,7 @@
 std::thread t((G()));
 assert(false);
 }
-catch (...)
+catch (std::bad_alloc const&)
 {
 throw_one = 0x;
 assert(G::n_alive == 0);
@@ -201,5 +210,5 @@
 }
 #endif
 
-  return 0;
+return 0;
 }


Index: test/std/thread/thread.threads/thread.thread.class/thread.thread.constr/F.pass.cpp
===
--- test/std/thread/thread.threads/thread.thread.class/thread.thread.constr/F.pass.cpp
+++ test/std/thread/thread.threads/thread.thread.class/thread.thread.constr/F.pass.cpp
@@ -30,9 +30,10 @@
 
 void* operator new(std::size_t s) TEST_THROW_SPEC(std::bad_alloc)
 {
-if (throw_one == 0)
-TEST_THROW(std::bad_alloc());
---throw_one;
+unsigned expected = throw_one;
+do {
+if (expected == 0) TEST_THROW(std::bad_alloc());
+} while (!throw_one.compare_exchange_weak(expected, expected - 1));
 ++outstanding_new;
 void* ret = std::malloc(s);
 if (!ret) std::abort(); // placate MSVC's unchecked malloc warning
@@ -41,6 +42,7 @@
 
 void  operator delete(void* p) TEST_NOEXCEPT
 {
+if (!p) return;
 --outstanding_new;
 std::free(p);
 }
@@ -108,13 +110,17 @@
 //  B std::thread's constructor should properly handle exceptions and not leak
 //memory.
 // Plan:
-//  1 Create a thread and count the number of allocations, 'N', it performs.
+//  1 Create a thread and count the number of allocations, 'numAllocs', it
+//performs.
 //  2 For each allocation performed run a test where that allocation throws.
 //2.1 check that the exception can be caught in the parent thread.
 //2.2 Check that the functor has not been called.
 //2.3 Check that no memory allocated by the creation of the thread is leaked.
-//  3 Finally check that a thread runs successfully if we throw a

[PATCH] D61466: [Rewrite][NFC] Add FIXME about RemoveLineIfEmpty

[Joel E. Denny via Phabricator via cfe-commits]

jdenny created this revision.
jdenny added reviewers: akyrtzi, Eugene.Zelenko, rsmith.
Herald added a subscriber: dexonsmith.
Herald added a project: clang.

I'd like to add these comments to warn others of problems I encountered when 
trying to use RemoveLineIfEmpty.  I originally tried to fix the problem, but I 
realized I could implement the functionality more easily and efficiently in my 
calling code where I can make the simplifying assumption that there are no 
prior edits to the line from which text is being removed.  While I've lost the 
motivation to write a fix, which doesn't look easy, I figure a warning to 
others is better than silence.

While I'm sure of the bug, some of these comments might be naive as I haven't 
fully digested the implementation here.  If someone prefers to write entirely 
different comments or wants to fix the bug, I'm happy to abandon this patch.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D61466

Files:
  clang/include/clang/Rewrite/Core/Rewriter.h
  clang/lib/Rewrite/Rewriter.cpp


Index: clang/lib/Rewrite/Rewriter.cpp
===
--- clang/lib/Rewrite/Rewriter.cpp
+++ clang/lib/Rewrite/Rewriter.cpp
@@ -96,6 +96,15 @@
 }
 if (posI != end() && *posI == '\n') {
   Buffer.erase(curLineStartOffs, lineSize + 1/* + '\n'*/);
+  // FIXME: Here, the offset of the start of the line is supposed to be
+  // expressed in terms of the original input not the "real" rewrite
+  // buffer.  How do we compute that reliably?  It might be tempting to use
+  // curLineStartOffs + OrigOffset - RealOffset, but that assumes the
+  // difference between the original and real offset is the same at the
+  // removed text and at the start of the line, but that's not true if
+  // edits were previously made earlier on the line.  Even if that's
+  // corrected, this still assumes all the whitespace characters being
+  // removed were originally contiguous.  Is that OK?
   AddReplaceDelta(curLineStartOffs, -(lineSize + 1/* + '\n'*/));
 }
   }
Index: clang/include/clang/Rewrite/Core/Rewriter.h
===
--- clang/include/clang/Rewrite/Core/Rewriter.h
+++ clang/include/clang/Rewrite/Core/Rewriter.h
@@ -46,6 +46,16 @@
 
 /// If true and removing some text leaves a blank line
 /// also remove the empty line (false by default).
+///
+/// FIXME: This sometimes corrupts the file's rewrite buffer due to
+/// incorrect indexing in the implementation.  Moreover, it's inefficient
+/// because it must scan the buffer from the beginning to find the start of
+/// the line.  When feasible, it's better for the caller to check for a
+/// blank line and then, if found, expand the removal range to include it.
+/// Checking for a blank line is easy if, for example, the caller can
+/// guarantee this is the first edit of a line.  In that case, it can just
+/// scan before and after the removal range until the next newline or
+/// begin/end of the input.
 bool RemoveLineIfEmpty = false;
 
 RewriteOptions() {}


Index: clang/lib/Rewrite/Rewriter.cpp
===
--- clang/lib/Rewrite/Rewriter.cpp
+++ clang/lib/Rewrite/Rewriter.cpp
@@ -96,6 +96,15 @@
 }
 if (posI != end() && *posI == '\n') {
   Buffer.erase(curLineStartOffs, lineSize + 1/* + '\n'*/);
+  // FIXME: Here, the offset of the start of the line is supposed to be
+  // expressed in terms of the original input not the "real" rewrite
+  // buffer.  How do we compute that reliably?  It might be tempting to use
+  // curLineStartOffs + OrigOffset - RealOffset, but that assumes the
+  // difference between the original and real offset is the same at the
+  // removed text and at the start of the line, but that's not true if
+  // edits were previously made earlier on the line.  Even if that's
+  // corrected, this still assumes all the whitespace characters being
+  // removed were originally contiguous.  Is that OK?
   AddReplaceDelta(curLineStartOffs, -(lineSize + 1/* + '\n'*/));
 }
   }
Index: clang/include/clang/Rewrite/Core/Rewriter.h
===
--- clang/include/clang/Rewrite/Core/Rewriter.h
+++ clang/include/clang/Rewrite/Core/Rewriter.h
@@ -46,6 +46,16 @@
 
 /// If true and removing some text leaves a blank line
 /// also remove the empty line (false by default).
+///
+/// FIXME: This sometimes corrupts the file's rewrite buffer due to
+/// incorrect indexing in the implementation.  Moreover, it's inefficient
+/// because it must scan the buffer from the beginning to find the start of
+/// the line.  When feasible, it's better for the caller to check for a
+/// blank line and then, if found, expand the removal range to incl

[PATCH] D61464: [RiscV] Typo in register aliases

[John LLVM via Phabricator via cfe-commits]

JohnLLVM updated this revision to Diff 197864.
JohnLLVM added a comment.

Proper context.


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

https://reviews.llvm.org/D61464

Files:
  lib/Basic/Targets/RISCV.cpp


Index: lib/Basic/Targets/RISCV.cpp
===
--- lib/Basic/Targets/RISCV.cpp
+++ lib/Basic/Targets/RISCV.cpp
@@ -31,7 +31,7 @@
   {{"zero"}, "x0"}, {{"ra"}, "x1"},  {{"sp"}, "x2"},   {{"gp"}, "x3"},
   {{"tp"}, "x4"},   {{"t0"}, "x5"},  {{"t1"}, "x6"},   {{"t2"}, "x7"},
   {{"s0"}, "x8"},   {{"s1"}, "x9"},  {{"a0"}, "x10"},  {{"a1"}, "x11"},
-  {{"a2"}, "x12"},  {{"a3"}, "x13"}, {{"a4"}, "x15"},  {{"a5"}, "x15"},
+  {{"a2"}, "x12"},  {{"a3"}, "x13"}, {{"a4"}, "x14"},  {{"a5"}, "x15"},
   {{"a6"}, "x16"},  {{"a7"}, "x17"}, {{"s2"}, "x18"},  {{"s3"}, "x19"},
   {{"s4"}, "x20"},  {{"s5"}, "x21"}, {{"s6"}, "x22"},  {{"s7"}, "x23"},
   {{"s8"}, "x24"},  {{"s9"}, "x25"}, {{"s10"}, "x26"}, {{"s11"}, "x27"},


Index: lib/Basic/Targets/RISCV.cpp
===
--- lib/Basic/Targets/RISCV.cpp
+++ lib/Basic/Targets/RISCV.cpp
@@ -31,7 +31,7 @@
   {{"zero"}, "x0"}, {{"ra"}, "x1"},  {{"sp"}, "x2"},   {{"gp"}, "x3"},
   {{"tp"}, "x4"},   {{"t0"}, "x5"},  {{"t1"}, "x6"},   {{"t2"}, "x7"},
   {{"s0"}, "x8"},   {{"s1"}, "x9"},  {{"a0"}, "x10"},  {{"a1"}, "x11"},
-  {{"a2"}, "x12"},  {{"a3"}, "x13"}, {{"a4"}, "x15"},  {{"a5"}, "x15"},
+  {{"a2"}, "x12"},  {{"a3"}, "x13"}, {{"a4"}, "x14"},  {{"a5"}, "x15"},
   {{"a6"}, "x16"},  {{"a7"}, "x17"}, {{"s2"}, "x18"},  {{"s3"}, "x19"},
   {{"s4"}, "x20"},  {{"s5"}, "x21"}, {{"s6"}, "x22"},  {{"s7"}, "x23"},
   {{"s8"}, "x24"},  {{"s9"}, "x25"}, {{"s10"}, "x26"}, {{"s11"}, "x27"},
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61458: [hip] Relax CUDA call restriction within `decltype` context.

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

In D61458#1488550 , @hliao wrote:

> In D61458#1488523 , @tra wrote:
>
> > Perhaps we should allow this in all unevaluated contexts? 
> >  I.e. `int s = sizeof(foo(x));` should also work.
>
>
> good point, do we have a dedicated context for sizeof? that make the checking 
> easier.


Sema::isUnevaluatedContext()  may be able to do the job.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61458



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

[PATCH] D61464: [RiscV] Typo in register aliases

[John LLVM via Phabricator via cfe-commits]

JohnLLVM created this revision.
JohnLLVM added a reviewer: echristo.
JohnLLVM added a project: clang.
Herald added subscribers: cfe-commits, benna, psnobl, jocewei, PkmX, rkruppe, 
the_o, brucehoult, MartinMosbeck, rogfer01, edward-jones, zzheng, jrtc27, 
shiva0217, kito-cheng, niosHD, sabuasal, apazos, simoncook, johnrusso, rbar, 
asb.

Not much to say, this typo did break inline assembly routines.

@echristo: I have no idea who to put as reviewer. Putting your name as there is 
"inline assembly" in `CODE_OWNERS.txt`. Do not hesitate to put someone else 
instead.


Repository:
  rC Clang

https://reviews.llvm.org/D61464

Files:
  lib/Basic/Targets/RISCV.cpp


Index: lib/Basic/Targets/RISCV.cpp
===
--- lib/Basic/Targets/RISCV.cpp
+++ lib/Basic/Targets/RISCV.cpp
@@ -31,7 +31,7 @@
   {{"zero"}, "x0"}, {{"ra"}, "x1"},  {{"sp"}, "x2"},   {{"gp"}, "x3"},
   {{"tp"}, "x4"},   {{"t0"}, "x5"},  {{"t1"}, "x6"},   {{"t2"}, "x7"},
   {{"s0"}, "x8"},   {{"s1"}, "x9"},  {{"a0"}, "x10"},  {{"a1"}, "x11"},
-  {{"a2"}, "x12"},  {{"a3"}, "x13"}, {{"a4"}, "x15"},  {{"a5"}, "x15"},
+  {{"a2"}, "x12"},  {{"a3"}, "x13"}, {{"a4"}, "x14"},  {{"a5"}, "x15"},
   {{"a6"}, "x16"},  {{"a7"}, "x17"}, {{"s2"}, "x18"},  {{"s3"}, "x19"},
   {{"s4"}, "x20"},  {{"s5"}, "x21"}, {{"s6"}, "x22"},  {{"s7"}, "x23"},
   {{"s8"}, "x24"},  {{"s9"}, "x25"}, {{"s10"}, "x26"}, {{"s11"}, "x27"},


Index: lib/Basic/Targets/RISCV.cpp
===
--- lib/Basic/Targets/RISCV.cpp
+++ lib/Basic/Targets/RISCV.cpp
@@ -31,7 +31,7 @@
   {{"zero"}, "x0"}, {{"ra"}, "x1"},  {{"sp"}, "x2"},   {{"gp"}, "x3"},
   {{"tp"}, "x4"},   {{"t0"}, "x5"},  {{"t1"}, "x6"},   {{"t2"}, "x7"},
   {{"s0"}, "x8"},   {{"s1"}, "x9"},  {{"a0"}, "x10"},  {{"a1"}, "x11"},
-  {{"a2"}, "x12"},  {{"a3"}, "x13"}, {{"a4"}, "x15"},  {{"a5"}, "x15"},
+  {{"a2"}, "x12"},  {{"a3"}, "x13"}, {{"a4"}, "x14"},  {{"a5"}, "x15"},
   {{"a6"}, "x16"},  {{"a7"}, "x17"}, {{"s2"}, "x18"},  {{"s3"}, "x19"},
   {{"s4"}, "x20"},  {{"s5"}, "x21"}, {{"s6"}, "x22"},  {{"s7"}, "x23"},
   {{"s8"}, "x24"},  {{"s9"}, "x25"}, {{"s10"}, "x26"}, {{"s11"}, "x27"},
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61458: [hip] Relax CUDA call restriction within `decltype` context.

[Michael Liao via Phabricator via cfe-commits]

hliao marked an inline comment as done.
hliao added a comment.

In D61458#1488523 , @tra wrote:

> Perhaps we should allow this in all unevaluated contexts? 
>  I.e. `int s = sizeof(foo(x));` should also work.


good point, do we have a dedicated context for sizeof? that make the checking 
easier.




Comment at: clang/include/clang/Sema/Sema.h:10411
+  auto I =
+  std::find_if(ExprEvalContexts.rbegin(), ExprEvalContexts.rend(),
+   [](const ExpressionEvaluationContextRecord &C) {

tra wrote:
> I think you want `return llvm::any_of(ExprEvalContexts, ...)` here and you 
> can fold it directly into `if()` below.
yeah, that's much simpler, I will make the change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61458



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

[PATCH] D61458: [hip] Relax CUDA call restriction within `decltype` context.

[Michael Liao via Phabricator via cfe-commits]

hliao updated this revision to Diff 197860.
hliao added a comment.

simplify the logic using `llvm::any_of`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61458

Files:
  clang/include/clang/Sema/Sema.h
  clang/test/CodeGenCUDA/function-overload.cu


Index: clang/test/CodeGenCUDA/function-overload.cu
===
--- clang/test/CodeGenCUDA/function-overload.cu
+++ clang/test/CodeGenCUDA/function-overload.cu
@@ -8,6 +8,8 @@
 // RUN: | FileCheck -check-prefix=CHECK-BOTH -check-prefix=CHECK-HOST %s
 // RUN: %clang_cc1 -triple nvptx64-nvidia-cuda -fcuda-is-device -emit-llvm -o 
- %s \
 // RUN: | FileCheck -check-prefix=CHECK-BOTH -check-prefix=CHECK-DEVICE %s
+// RUN: %clang_cc1 -std=c++11 -DCHECK_DECLTYPE -triple amdgcn -fcuda-is-device 
-emit-llvm -o - %s \
+// RUN: | FileCheck -check-prefix=CHECK-DECLTYPE %s
 
 #include "Inputs/cuda.h"
 
@@ -53,3 +55,14 @@
 // CHECK-BOTH: define linkonce_odr void @_ZN7s_cd_hdD2Ev(
 // CHECK-BOTH: store i32 32,
 // CHECK-BOTH: ret void
+
+#if defined(CHECK_DECLTYPE)
+int foo(float);
+// CHECK-DECLTYPE-LABEL: @_Z3barf
+// CHECK-DECLTYPE: fptosi
+// CHECK-DECLTYPE: sitofp
+__device__ float bar(float x) {
+  decltype(foo(x)) y = x;
+  return y + 3.f;
+}
+#endif
Index: clang/include/clang/Sema/Sema.h
===
--- clang/include/clang/Sema/Sema.h
+++ clang/include/clang/Sema/Sema.h
@@ -10406,6 +10406,12 @@
   /// semantically correct CUDA programs, but only if they're never codegen'ed.
   bool IsAllowedCUDACall(const FunctionDecl *Caller,
  const FunctionDecl *Callee) {
+if (llvm::any_of(ExprEvalContexts,
+ [](const ExpressionEvaluationContextRecord &C) {
+   return C.ExprContext ==
+  ExpressionEvaluationContextRecord::EK_Decltype;
+ }))
+  return true;
 return IdentifyCUDAPreference(Caller, Callee) != CFP_Never;
   }
 


Index: clang/test/CodeGenCUDA/function-overload.cu
===
--- clang/test/CodeGenCUDA/function-overload.cu
+++ clang/test/CodeGenCUDA/function-overload.cu
@@ -8,6 +8,8 @@
 // RUN: | FileCheck -check-prefix=CHECK-BOTH -check-prefix=CHECK-HOST %s
 // RUN: %clang_cc1 -triple nvptx64-nvidia-cuda -fcuda-is-device -emit-llvm -o - %s \
 // RUN: | FileCheck -check-prefix=CHECK-BOTH -check-prefix=CHECK-DEVICE %s
+// RUN: %clang_cc1 -std=c++11 -DCHECK_DECLTYPE -triple amdgcn -fcuda-is-device -emit-llvm -o - %s \
+// RUN: | FileCheck -check-prefix=CHECK-DECLTYPE %s
 
 #include "Inputs/cuda.h"
 
@@ -53,3 +55,14 @@
 // CHECK-BOTH: define linkonce_odr void @_ZN7s_cd_hdD2Ev(
 // CHECK-BOTH: store i32 32,
 // CHECK-BOTH: ret void
+
+#if defined(CHECK_DECLTYPE)
+int foo(float);
+// CHECK-DECLTYPE-LABEL: @_Z3barf
+// CHECK-DECLTYPE: fptosi
+// CHECK-DECLTYPE: sitofp
+__device__ float bar(float x) {
+  decltype(foo(x)) y = x;
+  return y + 3.f;
+}
+#endif
Index: clang/include/clang/Sema/Sema.h
===
--- clang/include/clang/Sema/Sema.h
+++ clang/include/clang/Sema/Sema.h
@@ -10406,6 +10406,12 @@
   /// semantically correct CUDA programs, but only if they're never codegen'ed.
   bool IsAllowedCUDACall(const FunctionDecl *Caller,
  const FunctionDecl *Callee) {
+if (llvm::any_of(ExprEvalContexts,
+ [](const ExpressionEvaluationContextRecord &C) {
+   return C.ExprContext ==
+  ExpressionEvaluationContextRecord::EK_Decltype;
+ }))
+  return true;
 return IdentifyCUDAPreference(Caller, Callee) != CFP_Never;
   }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D60974: Clang IFSO driver action.

[Jake Ehrlich via Phabricator via cfe-commits]

jakehehrlich added a comment.

> Jake, I am still not sure what you would prefer for moving forward. The 
> current patch can output the yaml format I originally proposed or the one 
> that looks similar to the one you proposed. What I need to know is:
> 
> Do you want the merging if the "ifo" files to happen inside of llvm-elfabi?
>  Do you care if we upstream the yaml we proposed as a first step (which is 
> really a distilled version of that yaml2obj can consume anyways. this right 
> now functions actually) ???
>  Or, would you rather the ifo files be merged by a different separate tool 
> (something maybe called llvm-ifsogen)???

This is my proposal:

1. We should plan on adding the code ofr merging these files inside of 
`llvm/tools/llvm-elfabi` but will it be a separate tool from `llvm-elfabi`. You 
can create "separate" tools in the same directory using the symlink trick. See 
llvm-ar and friends or llvm-objcopy and llvm-strip. The tool name can be 
discussed in review.
2. The yaml proposed thus far is not acceptable IMO for reasons already 
outlined but this can be discussed in code review. Before adding sections a 
clear reason for needing them is required which hasn't been given yet. Things 
can evolve and change later as needed but we should start with the minimum and 
add as needed later; not start with extra and remove later. Support for the new 
format should be added into TextAPI and in the review for that process we 
should discuss the format. After we add support for this new format into 
TextAPI we can add support for emitting this format into clang (well actually 
you can write the code whenever but I'm using "after" in a different sense 
here).
3. After support for emitting this is in clang has landed you can write the 
merging tool using the symlink trick. The merging tool should read in all the 
.ifo files and generate an ELFStub (see TextAPI/ELF) which can then be output 
using the code that I recently added you as a reviewer on. This will ensure 
that all of the stub solutions in llvm are consistent.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60974



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

[PATCH] D61165: Fix a crash where a [[no_destroy]] destructor was not emitted in an array

[Erik Pilkington via Phabricator via cfe-commits]

erik.pilkington added a comment.

In D61165#1487328 , @rjmccall wrote:

> In D61165#1487100 , @erik.pilkington 
> wrote:
>
> > It seems like the most common sense interpretation here is to just treat 
> > the initialization of `G` as completed at the point when the constructor 
> > finishes (this appears to be what GCC implements: 
> > https://wandbox.org/permlink/R3C9pPhoT4efAdL1).
>
>
> Your example doesn't actually demonstrate that that's what GCC implements 
> because it doesn't try to execute the declaration twice.  But you're right, 
> GCC does appear to consider the initialization complete as soon as the static 
> object's constructor returns normally.  On the other hand, GCC gets the array 
> case here wrong: if a static local has array type, and a destructor for a 
> temporary required by the first element initializer throws, then it does not 
> destroy the element but also (correctly) does not mark the variable as fully 
> initialized, and so a second attempt to run the initializer will simply 
> construct a new object on top of an already-constructed one.  This is 
> arguably correct under the standard — the first array element is not a 
> previously-constructed object of automatic duration — but I hope it's obvious 
> that that's a defect.
>
> > So if it was static it would just get destroyed at exit-time, and therefore 
> > should be disable-able with `no_destroy`. If the standard implies that we 
> > should be doing something else, then we should do that, but I can't seem to 
> > find any reference to the rule you're describing.
>
> Like I said, this is a poorly-specified part of the standard, because at 
> least *some* objects with static storage duration have to be destroyed when 
> an exception is thrown (because of aggregate initialization), but the 
> standard wants to pretend that this isn't true.  I think that allowing 
> temporary destructors to cancel initialization uniformly across all kinds of 
> objects is the most consistent rule,


That's only true for subobjects of an enclosing aggregate before that 
aggregate's initialization is complete though, right? So it doesn't seem like 
that much of an inconsistency, just mimicking what we would be doing if an 
exception was thrown in, say, the body of the ctor before the object's 
initialization is completed. Maybe I'm misunderstanding?

> but if the standard wants to use a rule that non-aggregate initialization of 
> static and thread-local locals is complete as soon as the constructor (or 
> assignment) completes, as opposed to the end of the full-expression, that's 
> also implementable.

So what should that path forward be here? I'd really like to get this crash 
fixed soon. If we want to consider a static local no_destroy dtor 
potentially-invoked in Sema if the initializer has a temporary with a throwing 
dtor, then we could do that, but it'd be unfortunate for 98/03 where I believe 
a dtor isn't noexcept by default, so we'd have to assume the worst. I guess 
it'd be easier to change our minds in the future if we treat the dtor as 
potentially-invoked, but I'm not really seeing the argument that we shouldn't 
just use this rule.

> I guess it would also technically be feasible for repeated attempts at 
> initialization to just pick up after the last subobject to be successfully 
> constructed, although that would be really obnoxious to actually implement 
> (and would require an ABI change for static local aggregates with vague 
> linkage).

Yeah, that seems quite strange, especially if initialization got picked up in 
another thread :)


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

https://reviews.llvm.org/D61165



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

[PATCH] D61407: [MS] Change the metadata for heapallocsite calls when the function return type is cast.

[Amy Huang via Phabricator via cfe-commits]

akhuang closed this revision.
akhuang added a comment.

Committed in r359823


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61407



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

[PATCH] D51329: [Attribute/Diagnostics] Print macro if definition is an attribute declaration

[Leonard Chan via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rC359826: [Attribute/Diagnostics] Print macro if definition is 
an attribute declaration (authored by leonardchan, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D51329?vs=197454&id=197854#toc

Repository:
  rC Clang

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

https://reviews.llvm.org/D51329

Files:
  include/clang/AST/ASTContext.h
  include/clang/AST/RecursiveASTVisitor.h
  include/clang/AST/Type.h
  include/clang/AST/TypeLoc.h
  include/clang/AST/TypeNodes.def
  include/clang/Parse/Parser.h
  include/clang/Sema/ParsedAttr.h
  include/clang/Sema/Sema.h
  include/clang/Serialization/ASTBitCodes.h
  lib/ARCMigrate/TransGCAttrs.cpp
  lib/AST/ASTContext.cpp
  lib/AST/ASTDiagnostic.cpp
  lib/AST/ASTStructuralEquivalence.cpp
  lib/AST/ItaniumMangle.cpp
  lib/AST/Type.cpp
  lib/AST/TypePrinter.cpp
  lib/CodeGen/CGDebugInfo.cpp
  lib/CodeGen/CodeGenFunction.cpp
  lib/Parse/ParseDecl.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaStmt.cpp
  lib/Sema/SemaType.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTWriter.cpp
  test/Frontend/macro_defined_type.cpp
  test/Sema/address_space_print_macro.c
  test/Sema/address_spaces.c
  test/SemaObjC/externally-retained.m
  test/SemaObjC/gc-attributes.m
  test/SemaObjC/mrc-weak.m
  test/SemaObjCXX/gc-attributes.mm
  tools/libclang/CIndex.cpp

Index: include/clang/AST/RecursiveASTVisitor.h
===
--- include/clang/AST/RecursiveASTVisitor.h
+++ include/clang/AST/RecursiveASTVisitor.h
@@ -1065,6 +1065,9 @@
 
 DEF_TRAVERSE_TYPE(ParenType, { TRY_TO(TraverseType(T->getInnerType())); })
 
+DEF_TRAVERSE_TYPE(MacroQualifiedType,
+  { TRY_TO(TraverseType(T->getUnderlyingType())); })
+
 DEF_TRAVERSE_TYPE(ElaboratedType, {
   if (T->getQualifier()) {
 TRY_TO(TraverseNestedNameSpecifier(T->getQualifier()));
@@ -1308,6 +1311,9 @@
 
 DEF_TRAVERSE_TYPELOC(ParenType, { TRY_TO(TraverseTypeLoc(TL.getInnerLoc())); })
 
+DEF_TRAVERSE_TYPELOC(MacroQualifiedType,
+ { TRY_TO(TraverseTypeLoc(TL.getInnerLoc())); })
+
 DEF_TRAVERSE_TYPELOC(AttributedType,
  { TRY_TO(TraverseTypeLoc(TL.getModifiedLoc())); })
 
Index: include/clang/AST/TypeNodes.def
===
--- include/clang/AST/TypeNodes.def
+++ include/clang/AST/TypeNodes.def
@@ -82,6 +82,7 @@
 DEPENDENT_TYPE(UnresolvedUsing, Type)
 NON_CANONICAL_TYPE(Paren, Type)
 NON_CANONICAL_TYPE(Typedef, Type)
+NON_CANONICAL_TYPE(MacroQualified, Type)
 NON_CANONICAL_TYPE(Adjusted, Type)
 NON_CANONICAL_TYPE(Decayed, AdjustedType)
 NON_CANONICAL_UNLESS_DEPENDENT_TYPE(TypeOfExpr, Type)
Index: include/clang/AST/Type.h
===
--- include/clang/AST/Type.h
+++ include/clang/AST/Type.h
@@ -4184,6 +4184,41 @@
   static bool classof(const Type *T) { return T->getTypeClass() == Typedef; }
 };
 
+/// Sugar type that represents a type that was qualified by a qualifier written
+/// as a macro invocation.
+class MacroQualifiedType : public Type {
+  friend class ASTContext; // ASTContext creates these.
+
+  QualType UnderlyingTy;
+  const IdentifierInfo *MacroII;
+
+  MacroQualifiedType(QualType UnderlyingTy, QualType CanonTy,
+ const IdentifierInfo *MacroII)
+  : Type(MacroQualified, CanonTy, UnderlyingTy->isDependentType(),
+ UnderlyingTy->isInstantiationDependentType(),
+ UnderlyingTy->isVariablyModifiedType(),
+ UnderlyingTy->containsUnexpandedParameterPack()),
+UnderlyingTy(UnderlyingTy), MacroII(MacroII) {
+assert(isa(UnderlyingTy) &&
+   "Expected a macro qualified type to only wrap attributed types.");
+  }
+
+public:
+  const IdentifierInfo *getMacroIdentifier() const { return MacroII; }
+  QualType getUnderlyingType() const { return UnderlyingTy; }
+
+  /// Return this attributed type's modified type with no qualifiers attached to
+  /// it.
+  QualType getModifiedType() const;
+
+  bool isSugared() const { return true; }
+  QualType desugar() const;
+
+  static bool classof(const Type *T) {
+return T->getTypeClass() == MacroQualified;
+  }
+};
+
 /// Represents a `typeof` (or __typeof__) expression (a GCC extension).
 class TypeOfExprType : public Type {
   Expr *TOExpr;
@@ -6805,6 +6840,8 @@
   Ty = P->desugar().getTypePtr();
 else if (const auto *A = dyn_cast(Ty))
   Ty = A->desugar().getTypePtr();
+else if (const auto *M = dyn_cast(Ty))
+  Ty = M->desugar().getTypePtr();
 else
   break;
   }
Index: include/clang/AST/ASTContext.h
===
--- include/clang/AST/ASTContext.h
+++ include/clang/AST/ASTContext.h
@@ -1441,6 +1441,9 @@
 
   QualType getParenType(QualType NamedType) const;
 
+  QualTy

[PATCH] D61458: [hip] Relax CUDA call restriction within `decltype` context.

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

Perhaps we should allow this in all unevaluated contexts? 
I.e. `int s = sizeof(foo(x));` should also work.




Comment at: clang/include/clang/Sema/Sema.h:10411
+  auto I =
+  std::find_if(ExprEvalContexts.rbegin(), ExprEvalContexts.rend(),
+   [](const ExpressionEvaluationContextRecord &C) {

I think you want `return llvm::any_of(ExprEvalContexts, ...)` here and you can 
fold it directly into `if()` below.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61458



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

[PATCH] D51329: [Attribute/Diagnostics] Print macro if definition is an attribute declaration

[Leonard Chan via Phabricator via cfe-commits]

leonardchan added a comment.

In D51329#1488465 , @rsmith wrote:

> Thanks, looks great!
>
> I think the handling of the expansion location in the `MacroQualifiedTypeLoc` 
> isn't quite right yet (it looks like it will never actually be set at all, 
> because the code to set it is not reachable) but it's also unused at the 
> moment, so I'm happy with that being fixed as a follow-up change after you 
> land this.


Thanks! Will make another patch eventually with the followup changes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D51329



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

r359826 - [Attribute/Diagnostics] Print macro if definition is an attribute declaration

[Leonard Chan via cfe-commits]

Author: leonardchan
Date: Thu May  2 13:38:14 2019
New Revision: 359826

URL: http://llvm.org/viewvc/llvm-project?rev=359826&view=rev
Log:
[Attribute/Diagnostics] Print macro if definition is an attribute declaration

If an address_space attribute is defined in a macro, print the macro instead
when diagnosing a warning or error for incompatible pointers with different
address_spaces.

We allow this for all attributes (not just address_space), and for multiple
attributes declared in the same macro.

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

Added:
cfe/trunk/test/Frontend/macro_defined_type.cpp
cfe/trunk/test/Sema/address_space_print_macro.c
Modified:
cfe/trunk/include/clang/AST/ASTContext.h
cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
cfe/trunk/include/clang/AST/Type.h
cfe/trunk/include/clang/AST/TypeLoc.h
cfe/trunk/include/clang/AST/TypeNodes.def
cfe/trunk/include/clang/Parse/Parser.h
cfe/trunk/include/clang/Sema/ParsedAttr.h
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/include/clang/Serialization/ASTBitCodes.h
cfe/trunk/lib/ARCMigrate/TransGCAttrs.cpp
cfe/trunk/lib/AST/ASTContext.cpp
cfe/trunk/lib/AST/ASTDiagnostic.cpp
cfe/trunk/lib/AST/ASTStructuralEquivalence.cpp
cfe/trunk/lib/AST/ItaniumMangle.cpp
cfe/trunk/lib/AST/Type.cpp
cfe/trunk/lib/AST/TypePrinter.cpp
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
cfe/trunk/lib/Parse/ParseDecl.cpp
cfe/trunk/lib/Sema/SemaExpr.cpp
cfe/trunk/lib/Sema/SemaStmt.cpp
cfe/trunk/lib/Sema/SemaType.cpp
cfe/trunk/lib/Sema/TreeTransform.h
cfe/trunk/lib/Serialization/ASTReader.cpp
cfe/trunk/lib/Serialization/ASTWriter.cpp
cfe/trunk/test/Sema/address_spaces.c
cfe/trunk/test/SemaObjC/externally-retained.m
cfe/trunk/test/SemaObjC/gc-attributes.m
cfe/trunk/test/SemaObjC/mrc-weak.m
cfe/trunk/test/SemaObjCXX/gc-attributes.mm
cfe/trunk/tools/libclang/CIndex.cpp

Modified: cfe/trunk/include/clang/AST/ASTContext.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTContext.h?rev=359826&r1=359825&r2=359826&view=diff
==
--- cfe/trunk/include/clang/AST/ASTContext.h (original)
+++ cfe/trunk/include/clang/AST/ASTContext.h Thu May  2 13:38:14 2019
@@ -1441,6 +1441,9 @@ public:
 
   QualType getParenType(QualType NamedType) const;
 
+  QualType getMacroQualifiedType(QualType UnderlyingTy,
+ const IdentifierInfo *MacroII) const;
+
   QualType getElaboratedType(ElaboratedTypeKeyword Keyword,
  NestedNameSpecifier *NNS, QualType NamedType,
  TagDecl *OwnedTagDecl = nullptr) const;

Modified: cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/RecursiveASTVisitor.h?rev=359826&r1=359825&r2=359826&view=diff
==
--- cfe/trunk/include/clang/AST/RecursiveASTVisitor.h (original)
+++ cfe/trunk/include/clang/AST/RecursiveASTVisitor.h Thu May  2 13:38:14 2019
@@ -1065,6 +1065,9 @@ DEF_TRAVERSE_TYPE(AttributedType,
 
 DEF_TRAVERSE_TYPE(ParenType, { TRY_TO(TraverseType(T->getInnerType())); })
 
+DEF_TRAVERSE_TYPE(MacroQualifiedType,
+  { TRY_TO(TraverseType(T->getUnderlyingType())); })
+
 DEF_TRAVERSE_TYPE(ElaboratedType, {
   if (T->getQualifier()) {
 TRY_TO(TraverseNestedNameSpecifier(T->getQualifier()));
@@ -1308,6 +1311,9 @@ DEF_TRAVERSE_TYPELOC(InjectedClassNameTy
 
 DEF_TRAVERSE_TYPELOC(ParenType, { TRY_TO(TraverseTypeLoc(TL.getInnerLoc())); })
 
+DEF_TRAVERSE_TYPELOC(MacroQualifiedType,
+ { TRY_TO(TraverseTypeLoc(TL.getInnerLoc())); })
+
 DEF_TRAVERSE_TYPELOC(AttributedType,
  { TRY_TO(TraverseTypeLoc(TL.getModifiedLoc())); })
 

Modified: cfe/trunk/include/clang/AST/Type.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Type.h?rev=359826&r1=359825&r2=359826&view=diff
==
--- cfe/trunk/include/clang/AST/Type.h (original)
+++ cfe/trunk/include/clang/AST/Type.h Thu May  2 13:38:14 2019
@@ -4184,6 +4184,41 @@ public:
   static bool classof(const Type *T) { return T->getTypeClass() == Typedef; }
 };
 
+/// Sugar type that represents a type that was qualified by a qualifier written
+/// as a macro invocation.
+class MacroQualifiedType : public Type {
+  friend class ASTContext; // ASTContext creates these.
+
+  QualType UnderlyingTy;
+  const IdentifierInfo *MacroII;
+
+  MacroQualifiedType(QualType UnderlyingTy, QualType CanonTy,
+ const IdentifierInfo *MacroII)
+  : Type(MacroQualified, CanonTy, UnderlyingTy->isDependentType(),
+ UnderlyingTy->isInstantiationDependentType(),
+ UnderlyingTy->isVariab

[PATCH] D61452: [WebAssembly] Always include /lib in library path

[Sam Clegg via Phabricator via cfe-commits]

sbc100 added a comment.

Even in the case of wasm64 it might well be that somebody wants to build two 
different sysroots (as they would be arm and arm64 on linux).   Even if we 
don't choose to ship a single arch sysroot for wasi somebody else might.

This doesn't seem like it does any harm to me.  It arguable I suppose that it 
allowing library authors to delay their transition to mulity-arch install.  I 
don't see why we (WebAssembly driver) should be forcing them to do that.   This 
just allows more flexibility for downstream consumers of the compiler.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61452



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

[clang-tools-extra] r359824 - [clangd][xpc] Cannonicalize value of CLANGD_BUILD_XPC before caching

[Jan Korous via cfe-commits]

Author: jkorous
Date: Thu May  2 13:32:56 2019
New Revision: 359824

URL: http://llvm.org/viewvc/llvm-project?rev=359824&view=rev
Log:
[clangd][xpc] Cannonicalize value of CLANGD_BUILD_XPC before caching

Modified:
clang-tools-extra/trunk/clangd/CMakeLists.txt

Modified: clang-tools-extra/trunk/clangd/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/CMakeLists.txt?rev=359824&r1=359823&r2=359824&view=diff
==
--- clang-tools-extra/trunk/clangd/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clangd/CMakeLists.txt Thu May  2 13:32:56 2019
@@ -6,6 +6,8 @@ if (NOT DEFINED CLANGD_BUILD_XPC)
 set(CLANGD_BUILD_XPC_DEFAULT OFF)
   endif ()
 
+  llvm_canonicalize_cmake_booleans(CLANGD_BUILD_XPC_DEFAULT)
+
   set(CLANGD_BUILD_XPC ${CLANGD_BUILD_XPC_DEFAULT} CACHE BOOL "Build XPC 
Support For Clangd." FORCE)
   unset(CLANGD_BUILD_XPC_DEFAULT)
 endif ()


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

[PATCH] D61458: [hip] Relax CUDA call restriction within `decltype` context.

[Michael Liao via Phabricator via cfe-commits]

hliao created this revision.
hliao added reviewers: tra, rjmccall, yaxunl.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

- Within `decltype`, expressions are only type-inspected. The restriction on 
CUDA calls should be relaxed.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D61458

Files:
  clang/include/clang/Sema/Sema.h
  clang/test/CodeGenCUDA/function-overload.cu


Index: clang/test/CodeGenCUDA/function-overload.cu
===
--- clang/test/CodeGenCUDA/function-overload.cu
+++ clang/test/CodeGenCUDA/function-overload.cu
@@ -8,6 +8,8 @@
 // RUN: | FileCheck -check-prefix=CHECK-BOTH -check-prefix=CHECK-HOST %s
 // RUN: %clang_cc1 -triple nvptx64-nvidia-cuda -fcuda-is-device -emit-llvm -o 
- %s \
 // RUN: | FileCheck -check-prefix=CHECK-BOTH -check-prefix=CHECK-DEVICE %s
+// RUN: %clang_cc1 -std=c++11 -DCHECK_DECLTYPE -triple amdgcn -fcuda-is-device 
-emit-llvm -o - %s \
+// RUN: | FileCheck -check-prefix=CHECK-DECLTYPE %s
 
 #include "Inputs/cuda.h"
 
@@ -53,3 +55,14 @@
 // CHECK-BOTH: define linkonce_odr void @_ZN7s_cd_hdD2Ev(
 // CHECK-BOTH: store i32 32,
 // CHECK-BOTH: ret void
+
+#if defined(CHECK_DECLTYPE)
+int foo(float);
+// CHECK-DECLTYPE-LABEL: @_Z3barf
+// CHECK-DECLTYPE: fptosi
+// CHECK-DECLTYPE: sitofp
+__device__ float bar(float x) {
+  decltype(foo(x)) y = x;
+  return y + 3.f;
+}
+#endif
Index: clang/include/clang/Sema/Sema.h
===
--- clang/include/clang/Sema/Sema.h
+++ clang/include/clang/Sema/Sema.h
@@ -10406,6 +10406,17 @@
   /// semantically correct CUDA programs, but only if they're never codegen'ed.
   bool IsAllowedCUDACall(const FunctionDecl *Caller,
  const FunctionDecl *Callee) {
+auto InDecltypeExpr = [this]() {
+  auto I =
+  std::find_if(ExprEvalContexts.rbegin(), ExprEvalContexts.rend(),
+   [](const ExpressionEvaluationContextRecord &C) {
+ return C.ExprContext ==
+ExpressionEvaluationContextRecord::EK_Decltype;
+   });
+  return I != ExprEvalContexts.rend();
+};
+if (InDecltypeExpr())
+  return true;
 return IdentifyCUDAPreference(Caller, Callee) != CFP_Never;
   }
 


Index: clang/test/CodeGenCUDA/function-overload.cu
===
--- clang/test/CodeGenCUDA/function-overload.cu
+++ clang/test/CodeGenCUDA/function-overload.cu
@@ -8,6 +8,8 @@
 // RUN: | FileCheck -check-prefix=CHECK-BOTH -check-prefix=CHECK-HOST %s
 // RUN: %clang_cc1 -triple nvptx64-nvidia-cuda -fcuda-is-device -emit-llvm -o - %s \
 // RUN: | FileCheck -check-prefix=CHECK-BOTH -check-prefix=CHECK-DEVICE %s
+// RUN: %clang_cc1 -std=c++11 -DCHECK_DECLTYPE -triple amdgcn -fcuda-is-device -emit-llvm -o - %s \
+// RUN: | FileCheck -check-prefix=CHECK-DECLTYPE %s
 
 #include "Inputs/cuda.h"
 
@@ -53,3 +55,14 @@
 // CHECK-BOTH: define linkonce_odr void @_ZN7s_cd_hdD2Ev(
 // CHECK-BOTH: store i32 32,
 // CHECK-BOTH: ret void
+
+#if defined(CHECK_DECLTYPE)
+int foo(float);
+// CHECK-DECLTYPE-LABEL: @_Z3barf
+// CHECK-DECLTYPE: fptosi
+// CHECK-DECLTYPE: sitofp
+__device__ float bar(float x) {
+  decltype(foo(x)) y = x;
+  return y + 3.f;
+}
+#endif
Index: clang/include/clang/Sema/Sema.h
===
--- clang/include/clang/Sema/Sema.h
+++ clang/include/clang/Sema/Sema.h
@@ -10406,6 +10406,17 @@
   /// semantically correct CUDA programs, but only if they're never codegen'ed.
   bool IsAllowedCUDACall(const FunctionDecl *Caller,
  const FunctionDecl *Callee) {
+auto InDecltypeExpr = [this]() {
+  auto I =
+  std::find_if(ExprEvalContexts.rbegin(), ExprEvalContexts.rend(),
+   [](const ExpressionEvaluationContextRecord &C) {
+ return C.ExprContext ==
+ExpressionEvaluationContextRecord::EK_Decltype;
+   });
+  return I != ExprEvalContexts.rend();
+};
+if (InDecltypeExpr())
+  return true;
 return IdentifyCUDAPreference(Caller, Callee) != CFP_Never;
   }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61407: [MS] Change the metadata for heapallocsite calls when the function return type is cast.

[Amy Huang via Phabricator via cfe-commits]

akhuang updated this revision to Diff 197851.
akhuang added a comment.

Change dyn_cast to isa


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61407

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/test/CodeGen/debug-info-codeview-heapallocsite.c


Index: clang/test/CodeGen/debug-info-codeview-heapallocsite.c
===
--- clang/test/CodeGen/debug-info-codeview-heapallocsite.c
+++ clang/test/CodeGen/debug-info-codeview-heapallocsite.c
@@ -1,27 +1,23 @@
 // RUN: %clang_cc1 -triple x86_64-windows-msvc -debug-info-kind=limited 
-gcodeview -fdeclspec -S -emit-llvm < %s | FileCheck %s
 
-struct Foo {
-  int x;
-};
+struct Foo;
+struct Bar;
 
 __declspec(allocator) void *alloc_void();
-__declspec(allocator) struct Foo *alloc_foo();
 
-void call_alloc_void() {
-  struct Foo *p = (struct Foo*)alloc_void();
+void call_alloc() {
+  struct Foo *p = alloc_void();
+  struct Foo *q = (struct Foo*)alloc_void();
+  struct Foo *r = (struct Foo*)(struct Bar*)alloc_void();
 }
 
-void call_alloc_foo() {
-  struct Foo *p = alloc_foo();
-}
-
-// CHECK-LABEL: define {{.*}}void @call_alloc_void
+// CHECK-LABEL: define {{.*}}void @call_alloc
 // CHECK: call i8* {{.*}}@alloc_void{{.*}} !heapallocsite [[DBG1:!.*]]
-
-// CHECK-LABEL: define {{.*}}void @call_alloc_foo
-// CHECK: call %struct.Foo* {{.*}}@alloc_foo{{.*}} !heapallocsite [[DBG2:!.*]]
+// CHECK: call i8* {{.*}}@alloc_void{{.*}} !heapallocsite [[DBG2:!.*]]
+// CHECK: call i8* {{.*}}@alloc_void{{.*}} !heapallocsite [[DBG3:!.*]]
 
 // CHECK: [[DBG1]] = !{}
-// CHECK: [[DBG2]] = distinct !DICompositeType(tag: DW_TAG_structure_type,
+// CHECK: [[DBG2]] = !DICompositeType(tag: DW_TAG_structure_type,
 // CHECK-SAME: name: "Foo"
-
+// CHECK: [[DBG3]] = !DICompositeType(tag: DW_TAG_structure_type,
+// CHECK-SAME: name: "Bar"
Index: clang/lib/CodeGen/CGExprScalar.cpp
===
--- clang/lib/CodeGen/CGExprScalar.cpp
+++ clang/lib/CodeGen/CGExprScalar.cpp
@@ -2063,6 +2063,12 @@
   }
 }
 
+// Update heapallocsite metadata when there is an explicit cast.
+if (llvm::CallInst *CI = dyn_cast(Src))
+  if (CI->getMetadata("heapallocsite") && isa(CE))
+  CGF.getDebugInfo()->
+  addHeapAllocSiteMetadata(CI, CE->getType(), CE->getExprLoc());
+
 return Builder.CreateBitCast(Src, DstTy);
   }
   case CK_AddressSpaceConversion: {
Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -4370,7 +4370,6 @@
   }
 
   // Add metadata for calls to MSAllocator functions
-  // FIXME: Get the type that the return value is cast to.
   if (getDebugInfo() && TargetDecl &&
   TargetDecl->hasAttr())
 getDebugInfo()->addHeapAllocSiteMetadata(CI, RetTy, Loc);


Index: clang/test/CodeGen/debug-info-codeview-heapallocsite.c
===
--- clang/test/CodeGen/debug-info-codeview-heapallocsite.c
+++ clang/test/CodeGen/debug-info-codeview-heapallocsite.c
@@ -1,27 +1,23 @@
 // RUN: %clang_cc1 -triple x86_64-windows-msvc -debug-info-kind=limited -gcodeview -fdeclspec -S -emit-llvm < %s | FileCheck %s
 
-struct Foo {
-  int x;
-};
+struct Foo;
+struct Bar;
 
 __declspec(allocator) void *alloc_void();
-__declspec(allocator) struct Foo *alloc_foo();
 
-void call_alloc_void() {
-  struct Foo *p = (struct Foo*)alloc_void();
+void call_alloc() {
+  struct Foo *p = alloc_void();
+  struct Foo *q = (struct Foo*)alloc_void();
+  struct Foo *r = (struct Foo*)(struct Bar*)alloc_void();
 }
 
-void call_alloc_foo() {
-  struct Foo *p = alloc_foo();
-}
-
-// CHECK-LABEL: define {{.*}}void @call_alloc_void
+// CHECK-LABEL: define {{.*}}void @call_alloc
 // CHECK: call i8* {{.*}}@alloc_void{{.*}} !heapallocsite [[DBG1:!.*]]
-
-// CHECK-LABEL: define {{.*}}void @call_alloc_foo
-// CHECK: call %struct.Foo* {{.*}}@alloc_foo{{.*}} !heapallocsite [[DBG2:!.*]]
+// CHECK: call i8* {{.*}}@alloc_void{{.*}} !heapallocsite [[DBG2:!.*]]
+// CHECK: call i8* {{.*}}@alloc_void{{.*}} !heapallocsite [[DBG3:!.*]]
 
 // CHECK: [[DBG1]] = !{}
-// CHECK: [[DBG2]] = distinct !DICompositeType(tag: DW_TAG_structure_type,
+// CHECK: [[DBG2]] = !DICompositeType(tag: DW_TAG_structure_type,
 // CHECK-SAME: name: "Foo"
-
+// CHECK: [[DBG3]] = !DICompositeType(tag: DW_TAG_structure_type,
+// CHECK-SAME: name: "Bar"
Index: clang/lib/CodeGen/CGExprScalar.cpp
===
--- clang/lib/CodeGen/CGExprScalar.cpp
+++ clang/lib/CodeGen/CGExprScalar.cpp
@@ -2063,6 +2063,12 @@
   }
 }
 
+// Update heapallocsite metadata when there

r359823 - Change the metadata for heapallocsite calls when the type is cast.

[Amy Huang via cfe-commits]

Author: akhuang
Date: Thu May  2 13:07:35 2019
New Revision: 359823

URL: http://llvm.org/viewvc/llvm-project?rev=359823&view=rev
Log:
Change the metadata for heapallocsite calls when the type is cast.

Modified:
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/lib/CodeGen/CGExprScalar.cpp
cfe/trunk/test/CodeGen/debug-info-codeview-heapallocsite.c

Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=359823&r1=359822&r2=359823&view=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Thu May  2 13:07:35 2019
@@ -4370,7 +4370,6 @@ RValue CodeGenFunction::EmitCall(const C
   }
 
   // Add metadata for calls to MSAllocator functions
-  // FIXME: Get the type that the return value is cast to.
   if (getDebugInfo() && TargetDecl &&
   TargetDecl->hasAttr())
 getDebugInfo()->addHeapAllocSiteMetadata(CI, RetTy, Loc);

Modified: cfe/trunk/lib/CodeGen/CGExprScalar.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExprScalar.cpp?rev=359823&r1=359822&r2=359823&view=diff
==
--- cfe/trunk/lib/CodeGen/CGExprScalar.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGExprScalar.cpp Thu May  2 13:07:35 2019
@@ -2063,6 +2063,12 @@ Value *ScalarExprEmitter::VisitCastExpr(
   }
 }
 
+// Update heapallocsite metadata when there is an explicit cast.
+if (llvm::CallInst *CI = dyn_cast(Src))
+  if (CI->getMetadata("heapallocsite") && isa(CE))
+  CGF.getDebugInfo()->
+  addHeapAllocSiteMetadata(CI, CE->getType(), CE->getExprLoc());
+
 return Builder.CreateBitCast(Src, DstTy);
   }
   case CK_AddressSpaceConversion: {

Modified: cfe/trunk/test/CodeGen/debug-info-codeview-heapallocsite.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/debug-info-codeview-heapallocsite.c?rev=359823&r1=359822&r2=359823&view=diff
==
--- cfe/trunk/test/CodeGen/debug-info-codeview-heapallocsite.c (original)
+++ cfe/trunk/test/CodeGen/debug-info-codeview-heapallocsite.c Thu May  2 
13:07:35 2019
@@ -1,27 +1,23 @@
 // RUN: %clang_cc1 -triple x86_64-windows-msvc -debug-info-kind=limited 
-gcodeview -fdeclspec -S -emit-llvm < %s | FileCheck %s
 
-struct Foo {
-  int x;
-};
+struct Foo;
+struct Bar;
 
 __declspec(allocator) void *alloc_void();
-__declspec(allocator) struct Foo *alloc_foo();
 
-void call_alloc_void() {
-  struct Foo *p = (struct Foo*)alloc_void();
+void call_alloc() {
+  struct Foo *p = alloc_void();
+  struct Foo *q = (struct Foo*)alloc_void();
+  struct Foo *r = (struct Foo*)(struct Bar*)alloc_void();
 }
 
-void call_alloc_foo() {
-  struct Foo *p = alloc_foo();
-}
-
-// CHECK-LABEL: define {{.*}}void @call_alloc_void
+// CHECK-LABEL: define {{.*}}void @call_alloc
 // CHECK: call i8* {{.*}}@alloc_void{{.*}} !heapallocsite [[DBG1:!.*]]
-
-// CHECK-LABEL: define {{.*}}void @call_alloc_foo
-// CHECK: call %struct.Foo* {{.*}}@alloc_foo{{.*}} !heapallocsite [[DBG2:!.*]]
+// CHECK: call i8* {{.*}}@alloc_void{{.*}} !heapallocsite [[DBG2:!.*]]
+// CHECK: call i8* {{.*}}@alloc_void{{.*}} !heapallocsite [[DBG3:!.*]]
 
 // CHECK: [[DBG1]] = !{}
-// CHECK: [[DBG2]] = distinct !DICompositeType(tag: DW_TAG_structure_type,
+// CHECK: [[DBG2]] = !DICompositeType(tag: DW_TAG_structure_type,
 // CHECK-SAME: name: "Foo"
-
+// CHECK: [[DBG3]] = !DICompositeType(tag: DW_TAG_structure_type,
+// CHECK-SAME: name: "Bar"


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

[PATCH] D51329: [Attribute/Diagnostics] Print macro if definition is an attribute declaration

[Richard Smith - zygoloid via Phabricator via cfe-commits]

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

Thanks, looks great!

I think the handling of the expansion location in the `MacroQualifiedTypeLoc` 
isn't quite right yet (it looks like it will never actually be set at all, 
because the code to set it is not reachable) but it's also unused at the 
moment, so I'm happy with that being fixed as a follow-up change after you land 
this.




Comment at: clang/lib/Sema/SemaType.cpp:5647
+void VisitMacroQualifiedTypeLoc(MacroQualifiedTypeLoc TL) {
+  TL.setExpansionLoc(Chunk.Loc);
+}

This should use `getMacroExpansionLoc` on the relevant attribute (you can store 
the location information in `TypeProcessingState` and retrieve it from here; 
see what we do for `AttributedType` for example).

I think we'll also need a `VisitMacroQualifiedTypeLoc` override on 
`TypeSpecLocFiller` for attributes in the decl-specifiers rather than 
attributes on declarator chunks. (See below.)



Comment at: clang/lib/Sema/SemaType.cpp:5727-5728
 
+while (MacroQualifiedTypeLoc TL = CurrTL.getAs())
+  CurrTL = TL.getNextTypeLoc().getUnqualifiedLoc();
+

Skipping `MacroQualifiedTypeLoc`s here means you're never reaching the above 
`DeclaratorLocFiller::VisitMacroQualifiedTypeLoc`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D51329



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

[PATCH] D61418: Another attempt to fix "could not find clang-check" lit warning in analyzer-less builds

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL359820: Another attempt to fix "could not find 
clang-check" lit warning in analyzer… (authored by nico, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D61418?vs=197690&id=197847#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D61418

Files:
  cfe/trunk/test/lit.cfg.py


Index: cfe/trunk/test/lit.cfg.py
===
--- cfe/trunk/test/lit.cfg.py
+++ cfe/trunk/test/lit.cfg.py
@@ -61,8 +61,7 @@
 tool_dirs = [config.clang_tools_dir, config.llvm_tools_dir]
 
 tools = [
-'c-index-test', 'clang-check', 'clang-diff', 'clang-format', 
'clang-tblgen',
-'opt',
+'c-index-test', 'clang-diff', 'clang-format', 'clang-tblgen', 'opt',
 ToolSubst('%clang_extdef_map', command=FindTool(
 'clang-extdef-mapping'), unresolved='ignore'),
 ]
@@ -71,6 +70,14 @@
 config.available_features.add('examples')
 tools.append('clang-interpreter')
 
+if config.clang_staticanalyzer:
+config.available_features.add('staticanalyzer')
+tools.append('clang-check')
+
+if config.clang_staticanalyzer_z3 == '1':
+config.available_features.add('z3')
+
+
 llvm_config.add_tool_substitutions(tools, tool_dirs)
 
 config.substitutions.append(
@@ -92,13 +99,6 @@
 if config.clang_default_cxx_stdlib != '':
 config.available_features.add('default-cxx-stdlib-set')
 
-# Enabled/disabled features
-if config.clang_staticanalyzer:
-config.available_features.add('staticanalyzer')
-
-if config.clang_staticanalyzer_z3 == '1':
-config.available_features.add('z3')
-
 # As of 2011.08, crash-recovery tests still do not pass on FreeBSD.
 if platform.system() not in ['FreeBSD']:
 config.available_features.add('crash-recovery')


Index: cfe/trunk/test/lit.cfg.py
===
--- cfe/trunk/test/lit.cfg.py
+++ cfe/trunk/test/lit.cfg.py
@@ -61,8 +61,7 @@
 tool_dirs = [config.clang_tools_dir, config.llvm_tools_dir]
 
 tools = [
-'c-index-test', 'clang-check', 'clang-diff', 'clang-format', 'clang-tblgen',
-'opt',
+'c-index-test', 'clang-diff', 'clang-format', 'clang-tblgen', 'opt',
 ToolSubst('%clang_extdef_map', command=FindTool(
 'clang-extdef-mapping'), unresolved='ignore'),
 ]
@@ -71,6 +70,14 @@
 config.available_features.add('examples')
 tools.append('clang-interpreter')
 
+if config.clang_staticanalyzer:
+config.available_features.add('staticanalyzer')
+tools.append('clang-check')
+
+if config.clang_staticanalyzer_z3 == '1':
+config.available_features.add('z3')
+
+
 llvm_config.add_tool_substitutions(tools, tool_dirs)
 
 config.substitutions.append(
@@ -92,13 +99,6 @@
 if config.clang_default_cxx_stdlib != '':
 config.available_features.add('default-cxx-stdlib-set')
 
-# Enabled/disabled features
-if config.clang_staticanalyzer:
-config.available_features.add('staticanalyzer')
-
-if config.clang_staticanalyzer_z3 == '1':
-config.available_features.add('z3')
-
 # As of 2011.08, crash-recovery tests still do not pass on FreeBSD.
 if platform.system() not in ['FreeBSD']:
 config.available_features.add('crash-recovery')
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r359820 - Another attempt to fix "could not find clang-check" lit warning in analyzer-less builds

[Nico Weber via cfe-commits]

Author: nico
Date: Thu May  2 12:47:05 2019
New Revision: 359820

URL: http://llvm.org/viewvc/llvm-project?rev=359820&view=rev
Log:
Another attempt to fix "could not find clang-check" lit warning in 
analyzer-less builds

r359717 added clang-check as a dep of check-clang unconditionally
because I had missed lit.local.cfg in test/Tooling.

Instead, only add clang-check to the tools if the analyzer is enabled,
since the build target only exists then, and since all tests using
clang-check are skipped when the analyzer is disabled.

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

Modified:
cfe/trunk/test/lit.cfg.py

Modified: cfe/trunk/test/lit.cfg.py
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/lit.cfg.py?rev=359820&r1=359819&r2=359820&view=diff
==
--- cfe/trunk/test/lit.cfg.py (original)
+++ cfe/trunk/test/lit.cfg.py Thu May  2 12:47:05 2019
@@ -61,8 +61,7 @@ config.substitutions.append(('%PATH%', c
 tool_dirs = [config.clang_tools_dir, config.llvm_tools_dir]
 
 tools = [
-'c-index-test', 'clang-check', 'clang-diff', 'clang-format', 
'clang-tblgen',
-'opt',
+'c-index-test', 'clang-diff', 'clang-format', 'clang-tblgen', 'opt',
 ToolSubst('%clang_extdef_map', command=FindTool(
 'clang-extdef-mapping'), unresolved='ignore'),
 ]
@@ -71,6 +70,14 @@ if config.clang_examples:
 config.available_features.add('examples')
 tools.append('clang-interpreter')
 
+if config.clang_staticanalyzer:
+config.available_features.add('staticanalyzer')
+tools.append('clang-check')
+
+if config.clang_staticanalyzer_z3 == '1':
+config.available_features.add('z3')
+
+
 llvm_config.add_tool_substitutions(tools, tool_dirs)
 
 config.substitutions.append(
@@ -92,13 +99,6 @@ if has_plugins and config.llvm_plugin_ex
 if config.clang_default_cxx_stdlib != '':
 config.available_features.add('default-cxx-stdlib-set')
 
-# Enabled/disabled features
-if config.clang_staticanalyzer:
-config.available_features.add('staticanalyzer')
-
-if config.clang_staticanalyzer_z3 == '1':
-config.available_features.add('z3')
-
 # As of 2011.08, crash-recovery tests still do not pass on FreeBSD.
 if platform.system() not in ['FreeBSD']:
 config.available_features.add('crash-recovery')


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

[PATCH] D60349: [COFF, ARM64] Fix ABI implementation of struct returns

[Mandeep Singh Grang via Phabricator via cfe-commits]

mgrang added a comment.

In D60349#1488411 , @efriedma wrote:

> LGTM, assuming it passes testing on electron


Thanks Eli. @richard.townsend.arm Can you please confirm whether Electron works 
with this patch and D60348 ?


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

https://reviews.llvm.org/D60349



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

[PATCH] D61386: [clang-tidy] Add support writing a check as a Transformer rewrite rule.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel marked an inline comment as done.
ymandel added a comment.

In D61386#1487735 , @JonasToth wrote:

> I like the new framework!


Great!




Comment at: clang-tools-extra/unittests/clang-tidy/TransformerTidyTest.cpp:38
+  IfInverterTidy(StringRef Name, ClangTidyContext *Context)
+  : TransformerTidy(invertIf(), Name, Context) {}
+};

JonasToth wrote:
> If we allow to pass in a callable, that returns a `RewriteRule`we would have 
> a more flexible framework in clang-tidy.
> Going with this for now is ok in my opinion as the only good usecase that 
> comes to my mind would be statistics.
> 
> But If some transformation needs to remember what has been done before only a 
> `RewriteRule` as state is not sufficient and stateful actions would require 
> global state (MEH!).
> If we allow to pass in a callable, that returns a RewriteRule we would have a 
> more flexible framework in clang-tidy.
> Going with this for now is ok in my opinion as the only good usecase that 
> comes to my mind would be statistics.
I'm fine with something more general, but I don't think I follow the 
particulars you have in mind.  Even w/ a callable, wouldn't that only be 
invoked *once* by clang-tidy, when it creates the class?  What kind of 
statistics do you have in mind?

> 
> But If some transformation needs to remember what has been done before only a 
> RewriteRule as state is not sufficient and stateful actions would require 
> global state (MEH!).

Indeed. The current design does preclude a (non gross) way of collecting state 
over multiple invocations.  Since this is rare, I think that's fine for now.  
But, our plan is to add support for a Translation Unit level API that supports 
things like collecting state, adding and removing header includes, inserting 
using decls and any other TU level operations.









Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61386



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

[PATCH] D61386: [clang-tidy] Add support writing a check as a Transformer rewrite rule.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel updated this revision to Diff 197836.
ymandel marked 2 inline comments as done.
ymandel added a comment.

responded to comments and shortened (unnecessarily long) variable name.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61386

Files:
  clang-tools-extra/clang-tidy/utils/CMakeLists.txt
  clang-tools-extra/clang-tidy/utils/TransformerTidy.cpp
  clang-tools-extra/clang-tidy/utils/TransformerTidy.h
  clang-tools-extra/unittests/clang-tidy/CMakeLists.txt
  clang-tools-extra/unittests/clang-tidy/TransformerTidyTest.cpp

Index: clang-tools-extra/unittests/clang-tidy/TransformerTidyTest.cpp
===
--- /dev/null
+++ clang-tools-extra/unittests/clang-tidy/TransformerTidyTest.cpp
@@ -0,0 +1,63 @@
+//=== TransformerTidyTest.cpp - clang-tidy ===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "../clang-tidy/utils/TransformerTidy.h"
+#include "ClangTidyTest.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/Tooling/Refactoring/Stencil.h"
+#include "clang/Tooling/Refactoring/Transformer.h"
+#include "gtest/gtest.h"
+
+namespace clang {
+namespace tidy {
+namespace utils {
+namespace {
+// Invert the code of an if-statement, while maintaining its semantics.
+tooling::RewriteRule invertIf() {
+  using namespace ::clang::ast_matchers;
+  using tooling::change;
+  using tooling::stencil::cat;
+  using tooling::stencil::node;
+  using tooling::stencil::sNode;
+
+  StringRef C = "C", "T", E = "E";
+  return tooling::makeRule(
+  ifStmt(hasCondition(expr().bind(C)), hasThen(stmt().bind(T)),
+ hasElse(stmt().bind(E))),
+  change(cat("if(!(", node(C), ")) ", sNode(E), " else ", sNode(T;
+}
+
+class IfInverterTidy : public TransformerTidy {
+public:
+  IfInverterTidy(StringRef Name, ClangTidyContext *Context)
+  : TransformerTidy(invertIf(), Name, Context) {}
+};
+
+// Basic test of using a rewrite rule as a ClangTidy.
+TEST(TransformerTidyTest, Basic) {
+  const std::string Input = R"cc(
+void log(const char* msg);
+void foo() {
+  if (10 > 1.0)
+log("oh no!");
+  else
+log("ok");
+}
+  )cc";
+  const std::string Expected = R"(
+void log(const char* msg);
+void foo() {
+  if(!(10 > 1.0)) log("ok"); else log("oh no!");
+}
+  )";
+  EXPECT_EQ(Expected, test::runCheckOnCode(Input));
+}
+} // namespace
+} // namespace utils
+} // namespace tidy
+} // namespace clang
Index: clang-tools-extra/unittests/clang-tidy/CMakeLists.txt
===
--- clang-tools-extra/unittests/clang-tidy/CMakeLists.txt
+++ clang-tools-extra/unittests/clang-tidy/CMakeLists.txt
@@ -17,6 +17,7 @@
   OverlappingReplacementsTest.cpp
   UsingInserterTest.cpp
   ReadabilityModuleTest.cpp
+  TransformerTidyTest.cpp
   )
 
 target_link_libraries(ClangTidyTests
@@ -36,4 +37,5 @@
   clangTidyUtils
   clangTooling
   clangToolingCore
+  clangToolingRefactor
   )
Index: clang-tools-extra/clang-tidy/utils/TransformerTidy.h
===
--- /dev/null
+++ clang-tools-extra/clang-tidy/utils/TransformerTidy.h
@@ -0,0 +1,49 @@
+//===-- TransformerTidy.h - clang-tidy ===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_TRANSFORMER_TIDY_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_TRANSFORMER_TIDY_H
+
+#include "../ClangTidy.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Tooling/Refactoring/Transformer.h"
+#include 
+#include 
+
+namespace clang {
+namespace tidy {
+namespace utils {
+
+// A base class for defining a ClangTidy check based on a rewrite rule.
+//
+// For example, given a RewriteRule `MyCheckAsRewriteRule`, one can define your
+// tidy check as follows:
+//
+// class MyTidyCheck : public TransformerTidy {
+//  public:
+//   MyTidyCheck(StringRef Name, ClangTidyContext *Context)
+//   : TransformerTidy(MyCheckAsRewriteRule, Name, Context) {}
+// };
+class TransformerTidy : public ClangTidyCheck {
+public:
+  TransformerTidy(tooling::RewriteRule R, StringRef Name,
+  ClangTidyContext *Context)
+  : ClangTidyCheck(Name, Context), Rule(std::move(R)) {}
+
+  void registerMatchers(ast_matchers::MatchFinder *Finder) override;
+  void check(const ast_matchers::Matc

[PATCH] D61456: [gn] Update the clangd test lit site configuration

[Petr Hosek via Phabricator via cfe-commits]

phosek added a comment.

In D61456#1488383 , @thakis wrote:

> Thanks! This is incomplete:
>
> - Create clangd_lit_site_cfg_files.gni next to this build file, but path to 
> generated files there
> - Edit llvm/utils/gn/secondary/llvm/utils/llvm-lit/BUILD.gn and add remapping 
> there
>
>   Else `out/gn/bin/llvm-lit clang-tools-extra/clangd/test/path/to/test` won't 
> work.
>
>   Compare to all the other test targets (e.g. clang-tools-extra) for an 
> example.


Done


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

https://reviews.llvm.org/D61456



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

[PATCH] D61456: [gn] Update the clangd test lit site configuration

[Petr Hosek via Phabricator via cfe-commits]

phosek updated this revision to Diff 197837.

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

https://reviews.llvm.org/D61456

Files:
  llvm/utils/gn/secondary/clang-tools-extra/clangd/test/BUILD.gn
  
llvm/utils/gn/secondary/clang-tools-extra/clangd/test/clangd_lit_site_cfg_files.gni
  llvm/utils/gn/secondary/llvm/utils/llvm-lit/BUILD.gn


Index: llvm/utils/gn/secondary/llvm/utils/llvm-lit/BUILD.gn
===
--- llvm/utils/gn/secondary/llvm/utils/llvm-lit/BUILD.gn
+++ llvm/utils/gn/secondary/llvm/utils/llvm-lit/BUILD.gn
@@ -1,4 +1,5 @@
 import("//clang-tools-extra/test/clang_tools_extra_lit_site_cfg_files.gni")
+import("//clang-tools-extra/clangd/test/clangd_lit_site_cfg_files.gni")
 import("//clang/test/clang_lit_site_cfg_files.gni")
 import("//lld/test/lld_lit_site_cfg_files.gni")
 import("//llvm/test/llvm_lit_site_cfg_files.gni")
@@ -42,6 +43,12 @@
   config_map +=
   "map_config('" + rebase_path("//clang-tools-extra/test/Unit/lit.cfg.py") 
+
   "', '" + rebase_path(clang_tools_extra_lit_unit_site_cfg_file) + "')\n"
+  config_map +=
+  "map_config('" + 
rebase_path("//clang-tools-extra/clangd/test/lit.cfg.py") +
+  "', '" + rebase_path(clangd_lit_site_cfg_file) + "')\n"
+  config_map +=
+  "map_config('" + 
rebase_path("//clang-tools-extra/clang/unittests/lit.cfg.py") +
+  "', '" + rebase_path(clangd_lit_unit_site_cfg_file) + "')\n"
   config_map += "map_config('" + rebase_path("//clang/test/lit.cfg.py") +
 "', '" + rebase_path(clang_lit_site_cfg_file) + "')\n"
   config_map += "map_config('" + rebase_path("//clang/test/Unit/lit.cfg.py") +
Index: 
llvm/utils/gn/secondary/clang-tools-extra/clangd/test/clangd_lit_site_cfg_files.gni
===
--- /dev/null
+++ 
llvm/utils/gn/secondary/clang-tools-extra/clangd/test/clangd_lit_site_cfg_files.gni
@@ -0,0 +1,4 @@
+clangd_lit_site_cfg_file =
+"$root_gen_dir/clang-tools-extra/clangd/test/lit.site.cfg.py"
+clangd_lit_unit_site_cfg_file =
+"$root_gen_dir/clang-tools-extra/clangd/unittests/lit.site.cfg.py"
Index: llvm/utils/gn/secondary/clang-tools-extra/clangd/test/BUILD.gn
===
--- llvm/utils/gn/secondary/clang-tools-extra/clangd/test/BUILD.gn
+++ llvm/utils/gn/secondary/clang-tools-extra/clangd/test/BUILD.gn
@@ -1,10 +1,7 @@
 import("//clang-tools-extra/clangd/xpc/enable.gni")
 import("//llvm/triples.gni")
 import("//llvm/utils/gn/build/write_cmake_config.gni")
-
-clangd_lit_site_cfg_file = 
"$root_gen_dir/clang-tools-extra/clangd/test/lit.cfg"
-clangd_lit_unit_site_cfg_file =
-"$root_gen_dir/clang-tools-extra/clangd/unittests/lit.cfg"
+import("clangd_lit_site_cfg_files.gni")
 
 template("write_lit_config") {
   write_cmake_config(target_name) {
@@ -20,7 +17,7 @@
 
 write_lit_config("lit_site_cfg") {
   # Fully-qualified instead of relative for LIT_SITE_CFG_IN_HEADER.
-  input = "//clang-tools-extra/clangd/test/lit.cfg.in"
+  input = "//clang-tools-extra/clangd/test/lit.site.cfg.py.in"
   output = clangd_lit_site_cfg_file
 
   extra_values = [
@@ -46,12 +43,14 @@
 
 write_lit_config("lit_unit_site_cfg") {
   # Fully-qualified instead of relative for LIT_SITE_CFG_IN_HEADER.
-  input = "//clang-tools-extra/clangd/unittests/lit.cfg.in"
+  input = "//clang-tools-extra/clangd/unittests/lit.site.cfg.py.in"
   output = clangd_lit_unit_site_cfg_file
   extra_values =
   [ "CMAKE_CURRENT_BINARY_DIR=" +
 rebase_path(get_label_info("//clang-tools-extra/clangd/unittests",
-   "target_out_dir")) ]
+   "target_out_dir")),
+"CMAKE_CURRENT_SOURCE_DIR=" +
+rebase_path("//clang-tools-extra/clangd/unittest")]
   if (host_os == "win") {
 # See comment for Windows solink in llvm/utils/gn/build/toolchain/BUILD.gn
 extra_values += [ "SHLIBDIR=" + rebase_path("$root_out_dir/bin") ]


Index: llvm/utils/gn/secondary/llvm/utils/llvm-lit/BUILD.gn
===
--- llvm/utils/gn/secondary/llvm/utils/llvm-lit/BUILD.gn
+++ llvm/utils/gn/secondary/llvm/utils/llvm-lit/BUILD.gn
@@ -1,4 +1,5 @@
 import("//clang-tools-extra/test/clang_tools_extra_lit_site_cfg_files.gni")
+import("//clang-tools-extra/clangd/test/clangd_lit_site_cfg_files.gni")
 import("//clang/test/clang_lit_site_cfg_files.gni")
 import("//lld/test/lld_lit_site_cfg_files.gni")
 import("//llvm/test/llvm_lit_site_cfg_files.gni")
@@ -42,6 +43,12 @@
   config_map +=
   "map_config('" + rebase_path("//clang-tools-extra/test/Unit/lit.cfg.py") +
   "', '" + rebase_path(clang_tools_extra_lit_unit_site_cfg_file) + "')\n"
+  config_map +=
+  "map_config('" + rebase_path("//clang-tools-extra/clangd/test/lit.cfg.py") +
+  "', '" + rebase_path(clangd_lit_site_cfg_file) + "')\n"
+  config_map +=
+  "map_config('" + rebase_pat

[PATCH] D61399: [OpenMP][Clang] Support for target math functions

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added a comment.

In D61399#1488329 , @hfinkel wrote:

> In D61399#1488309 , @ABataev wrote:
>
> > In D61399#1488299 , @hfinkel wrote:
> >
> > > In D61399#1488262 , @ABataev 
> > > wrote:
> > >
> > > > I don't like this implementation. Seems to me, it breaks one of the 
> > > > OpenMP standard requirements: the program can be compiled without 
> > > > openmp support. I assume, that with this includes the program won't be 
> > > > able to be compiled without OpenMP support anymore because it may use 
> > > > some device-specific math functions explicitly.
> > > >  Instead, I would like to see some additional, device-scpecific math 
> > > > header file, that must be included explicitly to support some 
> > > > device-specific math functions. And we need to provide default 
> > > > implementations for those extra math functions for all the platforms 
> > > > we're going to support, including default host implementations.
> > >
> > >
> > > Can you provide an example of a conforming program that can't be compiled 
> > > without OpenMP support? Regardless of the use of any device-specific 
> > > functions (which isn't covered by the standard, of course, but might be 
> > > needed in practice), the code still needs to be compilable by the host in 
> > > order to generate the host-fallback version. This doesn't change that. 
> > > Thus, any program that uses anything from this math.h, etc. needs to 
> > > compile for the host, and thus, likely compiles without OpenMP support. 
> > > Maybe I'm missing your point, however.
> >
> >
> > Assume we have something like this:
> >
> >   #pragma omp target if(cond)
> >   a = __nv_();
> >
> >
> > Instead of `__nv_xxx` you can try to use any Cuda-specific function, which 
> > is not the part of the standard `math.h`/`cmath` files. Will it be 
> > compilable even with OpenMP?
>
>
> I don't think that this changes that one way or the other. Your example won't 
> work, AFAIK, unless you do something like:
>
>   #pragma omp target if(cond)
>   #ifdef __NVPTX__
>   a = __nv_();
>   #else
>   a = something_on_the_host;
>   #endif
>   
>
> and anything from these headers that doesn't also have a host version will 
> suffer the same fate: if it won't also compile for the host (one way or 
> another), then it won't work.


The problem with this header file is that it allows to use those Cuda-specific 
functions unconditionally in some cases:

  #pragma omp target
  a = __nv_();

It won't require any target-specific guards to compile this code (if we compile 
it only for Cuda-specific devices) and we're loosing the consistency here: in 
some cases target regions will require special device guards, in others, with 
the same function calls, it is not. And the worst thing, is that we implicitly 
allow to introduce this kind of incostistency into users code. That's why I 
would prefer to see a special kind of the include file, NVPTX specific, that 
must be included explicitly, so the user explictly commanded to use some 
target-specific math functions, if he really wants it. Plus, maybe, in this 
files we need force check of the platform and warn users that the functions 
from this header file must be used using device-specific checks. Or provide 
some kind of the default implementations for all the platforms, that do not 
support those math function natively.


Repository:
  rC Clang

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

https://reviews.llvm.org/D61399



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

[PATCH] D61452: [WebAssembly] Always include /lib in library path

[Dan Gohman via Phabricator via cfe-commits]

sunfish added a comment.

The value of supporting single-arch sysroots is unclear to me. It's always 
possible to have a sysroot with libraries for just one architecture installed, 
even with multi-arch paths. Is this just about compatibility with build scripts 
and tools which are hard-coded to "$sysroot/lib"?

We'll eventually want the ability to have sysroots that support both wasm32 and 
wasm64. They can share headers, but they'll need their own library directories. 
If we have libraries installed in "$sysroot/lib", it'll complicate that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61452



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

[PATCH] D61456: [gn] Update the clangd test lit site configuration

[Petr Hosek via Phabricator via cfe-commits]

phosek created this revision.
phosek added a reviewer: thakis.
Herald added subscribers: llvm-commits, cfe-commits, kadircet, arphaman, 
jkorous, MaskRay, ilya-biryukov.
Herald added projects: clang, LLVM.

This reflects changes made in r359763.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D61456

Files:
  llvm/utils/gn/secondary/clang-tools-extra/clangd/test/BUILD.gn


Index: llvm/utils/gn/secondary/clang-tools-extra/clangd/test/BUILD.gn
===
--- llvm/utils/gn/secondary/clang-tools-extra/clangd/test/BUILD.gn
+++ llvm/utils/gn/secondary/clang-tools-extra/clangd/test/BUILD.gn
@@ -2,9 +2,9 @@
 import("//llvm/triples.gni")
 import("//llvm/utils/gn/build/write_cmake_config.gni")
 
-clangd_lit_site_cfg_file = 
"$root_gen_dir/clang-tools-extra/clangd/test/lit.cfg"
+clangd_lit_site_cfg_file = 
"$root_gen_dir/clang-tools-extra/clangd/test/lit.site.cfg.py"
 clangd_lit_unit_site_cfg_file =
-"$root_gen_dir/clang-tools-extra/clangd/unittests/lit.cfg"
+"$root_gen_dir/clang-tools-extra/clangd/unittests/lit.site.cfg.py"
 
 template("write_lit_config") {
   write_cmake_config(target_name) {
@@ -20,7 +20,7 @@
 
 write_lit_config("lit_site_cfg") {
   # Fully-qualified instead of relative for LIT_SITE_CFG_IN_HEADER.
-  input = "//clang-tools-extra/clangd/test/lit.cfg.in"
+  input = "//clang-tools-extra/clangd/test/lit.site.cfg.py.in"
   output = clangd_lit_site_cfg_file
 
   extra_values = [
@@ -46,12 +46,14 @@
 
 write_lit_config("lit_unit_site_cfg") {
   # Fully-qualified instead of relative for LIT_SITE_CFG_IN_HEADER.
-  input = "//clang-tools-extra/clangd/unittests/lit.cfg.in"
+  input = "//clang-tools-extra/clangd/unittests/lit.site.cfg.py.in"
   output = clangd_lit_unit_site_cfg_file
   extra_values =
   [ "CMAKE_CURRENT_BINARY_DIR=" +
 rebase_path(get_label_info("//clang-tools-extra/clangd/unittests",
-   "target_out_dir")) ]
+   "target_out_dir")),
+"CMAKE_CURRENT_SOURCE_DIR=" +
+rebase_path("//clang-tools-extra/clangd/unittest")]
   if (host_os == "win") {
 # See comment for Windows solink in llvm/utils/gn/build/toolchain/BUILD.gn
 extra_values += [ "SHLIBDIR=" + rebase_path("$root_out_dir/bin") ]


Index: llvm/utils/gn/secondary/clang-tools-extra/clangd/test/BUILD.gn
===
--- llvm/utils/gn/secondary/clang-tools-extra/clangd/test/BUILD.gn
+++ llvm/utils/gn/secondary/clang-tools-extra/clangd/test/BUILD.gn
@@ -2,9 +2,9 @@
 import("//llvm/triples.gni")
 import("//llvm/utils/gn/build/write_cmake_config.gni")
 
-clangd_lit_site_cfg_file = "$root_gen_dir/clang-tools-extra/clangd/test/lit.cfg"
+clangd_lit_site_cfg_file = "$root_gen_dir/clang-tools-extra/clangd/test/lit.site.cfg.py"
 clangd_lit_unit_site_cfg_file =
-"$root_gen_dir/clang-tools-extra/clangd/unittests/lit.cfg"
+"$root_gen_dir/clang-tools-extra/clangd/unittests/lit.site.cfg.py"
 
 template("write_lit_config") {
   write_cmake_config(target_name) {
@@ -20,7 +20,7 @@
 
 write_lit_config("lit_site_cfg") {
   # Fully-qualified instead of relative for LIT_SITE_CFG_IN_HEADER.
-  input = "//clang-tools-extra/clangd/test/lit.cfg.in"
+  input = "//clang-tools-extra/clangd/test/lit.site.cfg.py.in"
   output = clangd_lit_site_cfg_file
 
   extra_values = [
@@ -46,12 +46,14 @@
 
 write_lit_config("lit_unit_site_cfg") {
   # Fully-qualified instead of relative for LIT_SITE_CFG_IN_HEADER.
-  input = "//clang-tools-extra/clangd/unittests/lit.cfg.in"
+  input = "//clang-tools-extra/clangd/unittests/lit.site.cfg.py.in"
   output = clangd_lit_unit_site_cfg_file
   extra_values =
   [ "CMAKE_CURRENT_BINARY_DIR=" +
 rebase_path(get_label_info("//clang-tools-extra/clangd/unittests",
-   "target_out_dir")) ]
+   "target_out_dir")),
+"CMAKE_CURRENT_SOURCE_DIR=" +
+rebase_path("//clang-tools-extra/clangd/unittest")]
   if (host_os == "win") {
 # See comment for Windows solink in llvm/utils/gn/build/toolchain/BUILD.gn
 extra_values += [ "SHLIBDIR=" + rebase_path("$root_out_dir/bin") ]
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D60349: [COFF, ARM64] Fix ABI implementation of struct returns

[Eli Friedman via Phabricator via cfe-commits]

efriedma accepted this revision.
efriedma added a comment.

LGTM, assuming it passes testing on electron


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

https://reviews.llvm.org/D60349



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

[PATCH] D61097: [Sema] Emit warning for visibility attribute on internal-linkage declaration

[Scott Linder via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL359814: [Sema] Emit warning for visibility attribute on 
internal-linkage declaration (authored by scott.linder, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D61097?vs=197570&id=197838#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D61097

Files:
  cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
  cfe/trunk/lib/Sema/SemaDeclAttr.cpp
  cfe/trunk/test/Sema/attr-visibility.c
  cfe/trunk/test/SemaCXX/ast-print.cpp
  cfe/trunk/test/SemaCXX/attr-visibility.cpp


Index: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
===
--- cfe/trunk/lib/Sema/SemaDeclAttr.cpp
+++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp
@@ -2615,6 +2615,14 @@
 return;
   }
 
+  // Visibility attributes have no effect on symbols with internal linkage.
+  if (const auto *ND = dyn_cast(D)) {
+if (!ND->isExternallyVisible())
+  S.Diag(AL.getRange().getBegin(),
+ diag::warn_attribute_ignored_on_non_external)
+  << AL;
+  }
+
   // Check that the argument is a string literal.
   StringRef TypeStr;
   SourceLocation LiteralLoc;
Index: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
===
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
@@ -2778,6 +2778,9 @@
 def warn_attribute_ignored_on_inline :
   Warning<"%0 attribute ignored on inline function">,
   InGroup;
+def warn_attribute_ignored_on_non_external :
+  Warning<"%0 attribute is ignored on a non-external symbol">,
+  InGroup;
 def warn_nocf_check_attribute_ignored :
   Warning<"'nocf_check' attribute ignored; use -fcf-protection to enable the 
attribute">,
   InGroup;
Index: cfe/trunk/test/SemaCXX/ast-print.cpp
===
--- cfe/trunk/test/SemaCXX/ast-print.cpp
+++ cfe/trunk/test/SemaCXX/ast-print.cpp
@@ -209,10 +209,8 @@
 }
 }
 
-namespace {
 // CHECK: struct {{\[\[gnu::visibility\(\"hidden\"\)\]\]}} S;
 struct [[gnu::visibility("hidden")]] S;
-}
 
 // CHECK:  struct CXXFunctionalCastExprPrint {
 // CHECK-NEXT: } fce = CXXFunctionalCastExprPrint{};
Index: cfe/trunk/test/SemaCXX/attr-visibility.cpp
===
--- cfe/trunk/test/SemaCXX/attr-visibility.cpp
+++ cfe/trunk/test/SemaCXX/attr-visibility.cpp
@@ -18,3 +18,9 @@
 struct x3 {
   static int y;
 } __attribute((visibility("default"))); // expected-warning {{attribute 
'visibility' after definition is ignored}}
+
+const int test4 __attribute__((visibility("default"))) = 0; // 
expected-warning {{'visibility' attribute is ignored on a non-external symbol}}
+
+namespace {
+  int test5 __attribute__((visibility("default"))); // expected-warning 
{{'visibility' attribute is ignored on a non-external symbol}}
+};
Index: cfe/trunk/test/Sema/attr-visibility.c
===
--- cfe/trunk/test/Sema/attr-visibility.c
+++ cfe/trunk/test/Sema/attr-visibility.c
@@ -26,3 +26,9 @@
 int x __attribute__((type_visibility("default"))); // expected-error 
{{'type_visibility' attribute only applies to types and namespaces}}
 
 int PR17105 __attribute__((visibility(hidden))); // expected-error 
{{'visibility' attribute requires a string}}
+
+static int test8 __attribute__((visibility("default"))); // expected-warning 
{{'visibility' attribute is ignored on a non-external symbol}}
+static int test9 __attribute__((visibility("hidden"))); // expected-warning 
{{'visibility' attribute is ignored on a non-external symbol}}
+static int test10 __attribute__((visibility("internal"))); // expected-warning 
{{'visibility' attribute is ignored on a non-external symbol}}
+
+static int test11() __attribute__((visibility("default"))); // 
expected-warning {{'visibility' attribute is ignored on a non-external symbol}}


Index: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
===
--- cfe/trunk/lib/Sema/SemaDeclAttr.cpp
+++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp
@@ -2615,6 +2615,14 @@
 return;
   }
 
+  // Visibility attributes have no effect on symbols with internal linkage.
+  if (const auto *ND = dyn_cast(D)) {
+if (!ND->isExternallyVisible())
+  S.Diag(AL.getRange().getBegin(),
+ diag::warn_attribute_ignored_on_non_external)
+  << AL;
+  }
+
   // Check that the argument is a string literal.
   StringRef TypeStr;
   SourceLocation LiteralLoc;
Index: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
===
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
+++ cfe/trunk/include/clang/Basic/Diagno

r359814 - [Sema] Emit warning for visibility attribute on internal-linkage declaration

[Scott Linder via cfe-commits]

Author: scott.linder
Date: Thu May  2 12:03:57 2019
New Revision: 359814

URL: http://llvm.org/viewvc/llvm-project?rev=359814&view=rev
Log:
[Sema] Emit warning for visibility attribute on internal-linkage declaration

GCC warns on these cases, but we currently just silently ignore the attribute.

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

Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/Sema/SemaDeclAttr.cpp
cfe/trunk/test/Sema/attr-visibility.c
cfe/trunk/test/SemaCXX/ast-print.cpp
cfe/trunk/test/SemaCXX/attr-visibility.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=359814&r1=359813&r2=359814&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Thu May  2 12:03:57 
2019
@@ -2778,6 +2778,9 @@ def warn_attribute_ignored : Warning<"%0
 def warn_attribute_ignored_on_inline :
   Warning<"%0 attribute ignored on inline function">,
   InGroup;
+def warn_attribute_ignored_on_non_external :
+  Warning<"%0 attribute is ignored on a non-external symbol">,
+  InGroup;
 def warn_nocf_check_attribute_ignored :
   Warning<"'nocf_check' attribute ignored; use -fcf-protection to enable the 
attribute">,
   InGroup;

Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=359814&r1=359813&r2=359814&view=diff
==
--- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Thu May  2 12:03:57 2019
@@ -2615,6 +2615,14 @@ static void handleVisibilityAttr(Sema &S
 return;
   }
 
+  // Visibility attributes have no effect on symbols with internal linkage.
+  if (const auto *ND = dyn_cast(D)) {
+if (!ND->isExternallyVisible())
+  S.Diag(AL.getRange().getBegin(),
+ diag::warn_attribute_ignored_on_non_external)
+  << AL;
+  }
+
   // Check that the argument is a string literal.
   StringRef TypeStr;
   SourceLocation LiteralLoc;

Modified: cfe/trunk/test/Sema/attr-visibility.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/attr-visibility.c?rev=359814&r1=359813&r2=359814&view=diff
==
--- cfe/trunk/test/Sema/attr-visibility.c (original)
+++ cfe/trunk/test/Sema/attr-visibility.c Thu May  2 12:03:57 2019
@@ -26,3 +26,9 @@ typedef int __attribute__((visibility("d
 int x __attribute__((type_visibility("default"))); // expected-error 
{{'type_visibility' attribute only applies to types and namespaces}}
 
 int PR17105 __attribute__((visibility(hidden))); // expected-error 
{{'visibility' attribute requires a string}}
+
+static int test8 __attribute__((visibility("default"))); // expected-warning 
{{'visibility' attribute is ignored on a non-external symbol}}
+static int test9 __attribute__((visibility("hidden"))); // expected-warning 
{{'visibility' attribute is ignored on a non-external symbol}}
+static int test10 __attribute__((visibility("internal"))); // expected-warning 
{{'visibility' attribute is ignored on a non-external symbol}}
+
+static int test11() __attribute__((visibility("default"))); // 
expected-warning {{'visibility' attribute is ignored on a non-external symbol}}

Modified: cfe/trunk/test/SemaCXX/ast-print.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/ast-print.cpp?rev=359814&r1=359813&r2=359814&view=diff
==
--- cfe/trunk/test/SemaCXX/ast-print.cpp (original)
+++ cfe/trunk/test/SemaCXX/ast-print.cpp Thu May  2 12:03:57 2019
@@ -209,10 +209,8 @@ void test(int i) {
 }
 }
 
-namespace {
 // CHECK: struct {{\[\[gnu::visibility\(\"hidden\"\)\]\]}} S;
 struct [[gnu::visibility("hidden")]] S;
-}
 
 // CHECK:  struct CXXFunctionalCastExprPrint {
 // CHECK-NEXT: } fce = CXXFunctionalCastExprPrint{};

Modified: cfe/trunk/test/SemaCXX/attr-visibility.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/attr-visibility.cpp?rev=359814&r1=359813&r2=359814&view=diff
==
--- cfe/trunk/test/SemaCXX/attr-visibility.cpp (original)
+++ cfe/trunk/test/SemaCXX/attr-visibility.cpp Thu May  2 12:03:57 2019
@@ -18,3 +18,9 @@ void foo() {
 struct x3 {
   static int y;
 } __attribute((visibility("default"))); // expected-warning {{attribute 
'visibility' after definition is ignored}}
+
+const int test4 __attribute__((visibility("default"))) = 0; // 
expected-warning {{'visibility' attribute is ignored on a non-external symbol}}
+
+namespace {
+  int test5 __attribute__((visibility("default"))); // expected-warning 
{{'visibili

[PATCH] D61456: [gn] Update the clangd test lit site configuration

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

Thanks! This is incomplete:

- Create clangd_lit_site_cfg_files.gni next to this build file, but path to 
generated files there
- Edit llvm/utils/gn/secondary/llvm/utils/llvm-lit/BUILD.gn and add remapping 
there

Else `out/gn/bin/llvm-lit clang-tools-extra/clangd/test/path/to/test` won't 
work.

Compare to all the other test targets (e.g. clang-tools-extra) for an example.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D61456



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

[PATCH] D61452: [WebAssembly] Always include /lib in library path

[Sam Clegg via Phabricator via cfe-commits]

sbc100 added a comment.

In D61452#1488330 , @sunfish wrote:

> If libraries don't correctly install into multi-arch directories, can we fix 
> the libraries? We do this in the wasi-sdk repo to fix up the libc++ and 
> libc++abi libraries, for example.


Sure, yes.  I've done that on the wasm waterfall too.  But its not just that.  
We might want to make a single-arch sysroot too.   Falling back to 
non-multi-arch seems like a normal thing to do.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61452



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

[PATCH] D61454: [CodeGen][ObjC] Remove the leading 'l_' from ObjC symbols and make private symbols in the __DATA segment internal.

[Vedant Kumar via Phabricator via cfe-commits]

vsk added a comment.

Thanks for working on this!




Comment at: lib/CodeGen/CGObjCMac.cpp:1983
+  else
+GV->setSection("__OBJC,__cstring_object,regular,no_dead_strip");
+

Are constant NSStrings within the shared cache ever dirtied? I was under the 
impression that they couldn't be, so I'm not sure there's an advantage to 
making them internal.



Comment at: lib/CodeGen/CGObjCMac.cpp:3113
+  return CreateMetadataVar("_OBJC_PROTOCOLEXT_" + PD->getName(), values,
+   StringRef(), CGM.getPointerAlign(), true, false);
 }

Could you use '/*ExplicitDataSegment=*/false' (or similar) for clarity here and 
elsewhere?


Repository:
  rC Clang

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

https://reviews.llvm.org/D61454



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

[PATCH] D61318: [Sema] Prevent binding references with mismatching address spaces to temporaries

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: include/clang/AST/Type.h:463
 
-  /// Returns true if this address space is a superset of the other one.
+  /// Returns true if address space A is a superset of B.
   /// OpenCL v2.0 defines conversion rules (OpenCLC v2.0 s6.5.5) and notion of

"equal to or a superset of", just for clarity's sake.



Comment at: include/clang/AST/Type.h:478
+
+  /// Returns true if this address space is a superset of the other one.
   bool isAddressSpaceSupersetOf(Qualifiers other) const {

How about: "if the address space in these qualifiers is equal to or a superset 
of the address space in the argument qualifiers".


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

https://reviews.llvm.org/D61318



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

[PATCH] D60454: [OpenCL] Prevent mangling kernel functions

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

I think it would be more reasonable to just change `getDeclLanguageLinkage` to 
check for a kernel function.




Comment at: lib/AST/Decl.cpp:2940
+  if (hasAttr())
+return true;
   return isDeclExternC(*this);

Both of these changes should be unnecessary because they ultimately defer to 
`isInExternCContext`.

I assume that OpenCL bans making a class member function a kernel?


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

https://reviews.llvm.org/D60454



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

[PATCH] D61418: Another attempt to fix "could not find clang-check" lit warning in analyzer-less builds

[Reid Kleckner via Phabricator via cfe-commits]

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

lgtm


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

https://reviews.llvm.org/D61418



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

[PATCH] D61335: [LibTooling] Add support to Transformer for composing rules as an ordered choice.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel added a comment.

In D61335#1488212 , @ilya-biryukov 
wrote:

> - Could you provide a few real-world motivating examples?  Especially 
> interested in cases that were complicated before and are easy to do now?


Sure, below are some examples based on actual tidies I've written (although not 
released).  Let me know whether you think any of these should be expressed in 
the comments:

EXAMPLE 1
Consider a type `T` with a deterministic serialization function, `serialize()`. 
For performance reasons, we would like to make it non deterministic.  
Therefore, we want to drop the expectation that `a.serialize() = b.serialize() 
iff a = b` (although we’ll maintain `deserialize(a.serialize()) = a`).

Let’s assume this comes up in testing. We have three cases to consider:

  EXPECT_EQ(a.serialize(), b.serialize());
  EXPECT_EQ(a, b.serialize());
  EXPECT_EQ(a.serialize(), b);

With ordered choice, you can encode the above directly into matchers and then 
compose them into an ordered choice rule.  Without it, you’d have to write 
these as

  EXPECT_EQ(a.serialize(), b.serialize());
  EXPECT_EQ(a, b.serialize());  // where a != a’.serialize()
  EXPECT_EQ(a.serialize(), b);  // where b != b’.serialize()

where the constraints in the comments are explicitly in the matchers.

EXAMPLE 2
Consider patterns of the form

  absl::WrapUnique(e.release())

where `e` is an expression of type `std::unique_ptr<...>`.  This pattern was 
necessary in gcc for certain circumstances relating to upcasting the value type 
of the `unique_ptr`. It is not necessary in clang, and so should be removed.

In some cases, it should be rewritten to `e` and sometimes to `std::move(e)`, 
depending on the value category of `e` and the context (the expression of a 
return statement or not).  That is, there are two cases:
`absl::WrapUnique(e.release())` rewrites to `e`, if `e` is an r/x-value OR the 
call appears as a return expression,
`absl::WrapUnique(e.release())` rewrites to `std::move(e)`.
With ordered choice, the second case is written plainly (that is, just 
translate that expression to a matcher). Without it, you need to further 
express: unless `e` is an r/x-value OR the call appears as a return expression.

EXAMPLE 3
More generally, anywhere you’d use `anyOf(m1.bind(“m1”), m2.bind(“m2”))` and 
then dispatch on those tags in your code to decide what to do, we’ll lift that 
behavior to the rule level, so you can write 
makeOrderedRule({

  makeRule(m1, action1), makeRule(m2, action2), …

});

> - Do we expect most the rules to be written using the new API or is this 
> something that's gonna be used in `5-10%` of the cases?

I'd expect higher than 10% but not the majority of cases.  However, given that 
this semantics exactly matches that of `anyOf`, it may well be more common than 
I expect.

> - Could we consider expressing the `CompositeRewriteRule` as a `RewriteRule` 
> itself? That might require extending the `RewriteRule` abstraction, but the 
> mental model that makes sense to me is: a rewrite rule matches some AST nodes 
> and applies replacements to them. A `CompositeRewriteRule` seems to match the 
> same model, despite the fact it contains other rules. Would be nice if we 
> could make this fact internal to the implementation.
> 
>   Also a bit uneasy about the naming. `Composite` suggests the individual 
> rules compose one after another, while in practice only one alternative is 
> chosen.

Great points!  I'm fine with collapsing the types into one. As you can see from 
line 260 in Transformer.h, we're already folding the single rule into the 
composite rule.  As for naming, agreed, but does that concern drop away once we 
have only a single RewriteRule definition?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61335



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

[PATCH] D61452: [WebAssembly] Always include /lib in library path

[Dan Gohman via Phabricator via cfe-commits]

sunfish added a comment.

If libraries don't correctly install into multi-arch directories, can we fix 
the libraries? We do this in the wasi-sdk repo to fix up the libc++ and 
libc++abi libraries, for example.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61452



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

[PATCH] D61454: [CodeGen][ObjC] Remove the leading 'l_' from ObjC symbols and make private symbols in the __DATA segment internal.

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: lib/CodeGen/CGObjCMac.cpp:1024
+  bool AddToUsed,
+  bool ExplicitDataSegment);
   llvm::GlobalVariable *CreateMetadataVar(Twine Name,

Please document what this parameter means.



Comment at: lib/CodeGen/CGObjCMac.cpp:1978
+? llvm::GlobalVariable::InternalLinkage
+: llvm::GlobalValue::PrivateLinkage);
   // FIXME. Fix section.

1. Why are these using different classes to name these enumerators?
2. Why are we promoting to internal linkage in some cases?  That seems to be an 
additional semantic change not discussed in the commit message, and it should 
probably also get a good inline comment.


Repository:
  rC Clang

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

https://reviews.llvm.org/D61454



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

[PATCH] D61399: [OpenMP][Clang] Support for target math functions

[Hal Finkel via Phabricator via cfe-commits]

hfinkel added a comment.

In D61399#1488309 , @ABataev wrote:

> In D61399#1488299 , @hfinkel wrote:
>
> > In D61399#1488262 , @ABataev wrote:
> >
> > > I don't like this implementation. Seems to me, it breaks one of the 
> > > OpenMP standard requirements: the program can be compiled without openmp 
> > > support. I assume, that with this includes the program won't be able to 
> > > be compiled without OpenMP support anymore because it may use some 
> > > device-specific math functions explicitly.
> > >  Instead, I would like to see some additional, device-scpecific math 
> > > header file, that must be included explicitly to support some 
> > > device-specific math functions. And we need to provide default 
> > > implementations for those extra math functions for all the platforms 
> > > we're going to support, including default host implementations.
> >
> >
> > Can you provide an example of a conforming program that can't be compiled 
> > without OpenMP support? Regardless of the use of any device-specific 
> > functions (which isn't covered by the standard, of course, but might be 
> > needed in practice), the code still needs to be compilable by the host in 
> > order to generate the host-fallback version. This doesn't change that. 
> > Thus, any program that uses anything from this math.h, etc. needs to 
> > compile for the host, and thus, likely compiles without OpenMP support. 
> > Maybe I'm missing your point, however.
>
>
> Assume we have something like this:
>
>   #pragma omp target if(cond)
>   a = __nv_();
>
>
> Instead of `__nv_xxx` you can try to use any Cuda-specific function, which is 
> not the part of the standard `math.h`/`cmath` files. Will it be compilable 
> even with OpenMP?


I don't think that this changes that one way or the other. Your example won't 
work, AFAIK, unless you do something like:

  #pragma omp target if(cond)
  #ifdef __NVPTX__
  a = __nv_();
  #else
  a = something_on_the_host;
  #endif

and anything from these headers that doesn't also have a host version will 
suffer the same fate: if it won't also compile for the host (one way or 
another), then it won't work.


Repository:
  rC Clang

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

https://reviews.llvm.org/D61399



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

[PATCH] D61407: [MS] Change the metadata for heapallocsite calls when the function return type is cast.

[Reid Kleckner via Phabricator via cfe-commits]

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

lgtm, with a minor tweak




Comment at: clang/lib/CodeGen/CGExprScalar.cpp:2068
+if (llvm::CallInst *CI = dyn_cast(Src))
+  if (CI->getMetadata("heapallocsite") && dyn_cast(CE))
+  CGF.getDebugInfo()->

It's more idiomatic to say `isa(CE)` than to use dyn_cast and 
test for nullness. The casting API actually has reasonably good documentation 
on it if you're curious:
http://llvm.org/docs/ProgrammersManual.html#the-isa-cast-and-dyn-cast-templates


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61407



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

[PATCH] D61399: [OpenMP][Clang] Support for target math functions

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added a comment.

In D61399#1488299 , @hfinkel wrote:

> In D61399#1488262 , @ABataev wrote:
>
> > I don't like this implementation. Seems to me, it breaks one of the OpenMP 
> > standard requirements: the program can be compiled without openmp support. 
> > I assume, that with this includes the program won't be able to be compiled 
> > without OpenMP support anymore because it may use some device-specific math 
> > functions explicitly.
> >  Instead, I would like to see some additional, device-scpecific math header 
> > file, that must be included explicitly to support some device-specific math 
> > functions. And we need to provide default implementations for those extra 
> > math functions for all the platforms we're going to support, including 
> > default host implementations.
>
>
> Can you provide an example of a conforming program that can't be compiled 
> without OpenMP support? Regardless of the use of any device-specific 
> functions (which isn't covered by the standard, of course, but might be 
> needed in practice), the code still needs to be compilable by the host in 
> order to generate the host-fallback version. This doesn't change that. Thus, 
> any program that uses anything from this math.h, etc. needs to compile for 
> the host, and thus, likely compiles without OpenMP support. Maybe I'm missing 
> your point, however.


Assume we have something like this:

  #pragma omp target if(cond)
  a = __nv_();

Instead of `__nv_xxx` you can try to use any Cuda-specific function, which is 
not the part of the standard `math.h`/`cmath` files. Will it be compilable even 
with OpenMP?


Repository:
  rC Clang

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

https://reviews.llvm.org/D61399



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

[PATCH] D61407: [MS] Change the metadata for heapallocsite calls when the function return type is cast.

[Amy Huang via Phabricator via cfe-commits]

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

Reverted `getCompleteTypeIndex` change, to be fixed elsewhere


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61407



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

[PATCH] D60349: [COFF, ARM64] Fix ABI implementation of struct returns

[Mandeep Singh Grang via Phabricator via cfe-commits]

mgrang updated this revision to Diff 197831.
mgrang edited the summary of this revision.

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

https://reviews.llvm.org/D60349

Files:
  include/clang/AST/DeclCXX.h
  include/clang/CodeGen/CGFunctionInfo.h
  lib/CodeGen/CGCall.cpp
  lib/CodeGen/MicrosoftCXXABI.cpp
  lib/Sema/SemaDeclCXX.cpp
  test/CodeGen/arm64-microsoft-arguments.cpp
  test/CodeGenCXX/microsoft-abi-sret-and-byval.cpp

Index: test/CodeGenCXX/microsoft-abi-sret-and-byval.cpp
===
--- test/CodeGenCXX/microsoft-abi-sret-and-byval.cpp
+++ test/CodeGenCXX/microsoft-abi-sret-and-byval.cpp
@@ -69,6 +69,11 @@
   int bb;
 };
 
+struct SmallWithPrivate {
+private:
+ int i;
+};
+
 // WIN32: declare dso_local void @"{{.*take_bools_and_chars.*}}"
 // WIN32:   (<{ i8, [3 x i8], i8, [3 x i8], %struct.SmallWithDtor,
 // WIN32:   i8, [3 x i8], i8, [3 x i8], i32, i8, [3 x i8] }>* inalloca)
@@ -165,7 +170,7 @@
 // WIN64:   call void @"??1SmallWithDtor@@QEAA@XZ"
 // WIN64: }
 // WOA64: define dso_local void @"?small_arg_with_dtor@@YAXUSmallWithDtor@@@Z"(i64 %s.coerce) {{.*}} {
-// WOA64:   call void @"??1SmallWithDtor@@QEAA@XZ"
+// WOA64:   call void @"??1SmallWithDtor@@QEAA@XZ"(%struct.SmallWithDtor* %s)
 // WOA64: }
 
 // FIXME: MSVC incompatible!
@@ -173,6 +178,12 @@
 // WOA:   call arm_aapcs_vfpcc void @"??1SmallWithDtor@@QAA@XZ"(%struct.SmallWithDtor* %s)
 // WOA: }
 
+
+// Test that the eligible non-aggregate is passed directly, but returned
+// indirectly on ARM64 Windows.
+// WOA64: define dso_local void @"?small_arg_with_private_member@@YA?AUSmallWithPrivate@@U1@@Z"(%struct.SmallWithPrivate* inreg noalias sret %agg.result, i64 %s.coerce) {{.*}} {
+SmallWithPrivate small_arg_with_private_member(SmallWithPrivate s) { return s; }
+
 void call_small_arg_with_dtor() {
   small_arg_with_dtor(SmallWithDtor());
 }
Index: test/CodeGen/arm64-microsoft-arguments.cpp
===
--- test/CodeGen/arm64-microsoft-arguments.cpp
+++ test/CodeGen/arm64-microsoft-arguments.cpp
@@ -1,25 +1,203 @@
 // RUN: %clang_cc1 -triple aarch64-windows -ffreestanding -emit-llvm -O0 \
 // RUN: -x c++ -o - %s | FileCheck %s
 
-struct pod { int a, b, c, d, e; };
+// Pass and return for type size <= 8 bytes.
+// CHECK: define {{.*}} i64 @{{.*}}f1{{.*}}()
+// CHECK: call i64 {{.*}}func1{{.*}}(i64 %3)
+struct S1 {
+  int a[2];
+};
+
+S1 func1(S1 x);
+S1 f1() {
+  S1 x;
+  return func1(x);
+}
+
+// Pass and return type size <= 16 bytes.
+// CHECK: define {{.*}} [2 x i64] @{{.*}}f2{{.*}}()
+// CHECK: call [2 x i64] {{.*}}func2{{.*}}([2 x i64] %3)
+struct S2 {
+  int a[4];
+};
+
+S2 func2(S2 x);
+S2 f2() {
+  S2 x;
+  return func2(x);
+}
+
+// Pass and return for type size > 16 bytes.
+// CHECK: define {{.*}} void @{{.*}}f3{{.*}}(%struct.S3* noalias sret %agg.result)
+// CHECK: call void {{.*}}func3{{.*}}(%struct.S3* sret %agg.result, %struct.S3* %agg.tmp)
+struct S3 {
+  int a[5];
+};
+
+S3 func3(S3 x);
+S3 f3() {
+  S3 x;
+  return func3(x);
+}
+
+// Pass and return aggregate (of size < 16 bytes) with non-trivial destructor.
+// Passed directly but returned indirectly.
+// CHECK: define {{.*}} void {{.*}}f4{{.*}}(%struct.S4* inreg noalias sret %agg.result)
+// CHECK: call void {{.*}}func4{{.*}}(%struct.S4* inreg sret %agg.result, [2 x i64] %4)
+struct S4 {
+  int a[3];
+  ~S4();
+};
+
+S4 func4(S4 x);
+S4 f4() {
+  S4 x;
+  return func4(x);
+}
+
+// Pass and return from instance method called from instance method.
+// CHECK: define {{.*}} void @{{.*}}bar@Q1{{.*}}(%class.Q1* %this, %class.P1* inreg noalias sret %agg.result)
+// CHECK: call void {{.*}}foo@P1{{.*}}(%class.P1* %ref.tmp, %class.P1* inreg sret %agg.result, i8 %0)
+
+class P1 {
+public:
+  P1 foo(P1 x);
+};
+
+class Q1 {
+public:
+  P1 bar();
+};
+
+P1 Q1::bar() {
+  P1 p1;
+  return P1().foo(p1);
+}
+
+// Pass and return from instance method called from free function.
+// CHECK: define {{.*}} void {{.*}}bar{{.*}}()
+// CHECK: call void {{.*}}foo@P2{{.*}}(%class.P2* %ref.tmp, %class.P2* inreg sret %retval, i8 %0)
+class P2 {
+public:
+  P2 foo(P2 x);
+};
+
+P2 bar() {
+  P2 p2;
+  return P2().foo(p2);
+}
 
-struct non_pod {
-  int a;
-  non_pod() {}
+// Pass and return an object with a user-provided constructor (passed directly,
+// returned indirectly)
+// CHECK: define {{.*}} void @{{.*}}f5{{.*}}(%struct.S5* inreg noalias sret %agg.result)
+// CHECK: call void {{.*}}func5{{.*}}(%struct.S5* inreg sret %agg.result, i64 {{.*}})
+struct S5 {
+  S5();
+  int x;
 };
 
-struct pod s;
-struct non_pod t;
+S5 func5(S5 x);
+S5 f5() {
+  S5 x;
+  return func5(x);
+}
 
-struct pod bar() { return s; }
-struct non_pod foo() { return t; }
-// CHECK: define {{.*}} void @{{.*}}bar{{.*}}(%struct.pod* noalias sret %agg.result)
-// CHECK: define {{.*}} void @{{.*}}foo{{.*}}(%struct.non_pod* noalias %agg.result)
+// Pass and return an object with a non-trivial

[PATCH] D61407: [MS] Change the metadata for heapallocsite calls when the function return type is cast.

[Amy Huang via Phabricator via cfe-commits]

akhuang updated this revision to Diff 197830.
akhuang marked an inline comment as done.
akhuang added a comment.

- Add test case for multiple casts
- Remove unrelated changes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61407

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/test/CodeGen/debug-info-codeview-heapallocsite.c


Index: clang/test/CodeGen/debug-info-codeview-heapallocsite.c
===
--- clang/test/CodeGen/debug-info-codeview-heapallocsite.c
+++ clang/test/CodeGen/debug-info-codeview-heapallocsite.c
@@ -1,27 +1,23 @@
 // RUN: %clang_cc1 -triple x86_64-windows-msvc -debug-info-kind=limited 
-gcodeview -fdeclspec -S -emit-llvm < %s | FileCheck %s
 
-struct Foo {
-  int x;
-};
+struct Foo;
+struct Bar;
 
 __declspec(allocator) void *alloc_void();
-__declspec(allocator) struct Foo *alloc_foo();
 
-void call_alloc_void() {
-  struct Foo *p = (struct Foo*)alloc_void();
+void call_alloc() {
+  struct Foo *p = alloc_void();
+  struct Foo *q = (struct Foo*)alloc_void();
+  struct Foo *r = (struct Foo*)(struct Bar*)alloc_void();
 }
 
-void call_alloc_foo() {
-  struct Foo *p = alloc_foo();
-}
-
-// CHECK-LABEL: define {{.*}}void @call_alloc_void
+// CHECK-LABEL: define {{.*}}void @call_alloc
 // CHECK: call i8* {{.*}}@alloc_void{{.*}} !heapallocsite [[DBG1:!.*]]
-
-// CHECK-LABEL: define {{.*}}void @call_alloc_foo
-// CHECK: call %struct.Foo* {{.*}}@alloc_foo{{.*}} !heapallocsite [[DBG2:!.*]]
+// CHECK: call i8* {{.*}}@alloc_void{{.*}} !heapallocsite [[DBG2:!.*]]
+// CHECK: call i8* {{.*}}@alloc_void{{.*}} !heapallocsite [[DBG3:!.*]]
 
 // CHECK: [[DBG1]] = !{}
-// CHECK: [[DBG2]] = distinct !DICompositeType(tag: DW_TAG_structure_type,
+// CHECK: [[DBG2]] = !DICompositeType(tag: DW_TAG_structure_type,
 // CHECK-SAME: name: "Foo"
-
+// CHECK: [[DBG3]] = !DICompositeType(tag: DW_TAG_structure_type,
+// CHECK-SAME: name: "Bar"
Index: clang/lib/CodeGen/CGExprScalar.cpp
===
--- clang/lib/CodeGen/CGExprScalar.cpp
+++ clang/lib/CodeGen/CGExprScalar.cpp
@@ -2063,6 +2063,12 @@
   }
 }
 
+// Update heapallocsite metadata when there is an explicit cast.
+if (llvm::CallInst *CI = dyn_cast(Src))
+  if (CI->getMetadata("heapallocsite") && dyn_cast(CE))
+  CGF.getDebugInfo()->
+  addHeapAllocSiteMetadata(CI, CE->getType(), CE->getExprLoc());
+
 return Builder.CreateBitCast(Src, DstTy);
   }
   case CK_AddressSpaceConversion: {
Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -4370,7 +4370,6 @@
   }
 
   // Add metadata for calls to MSAllocator functions
-  // FIXME: Get the type that the return value is cast to.
   if (getDebugInfo() && TargetDecl &&
   TargetDecl->hasAttr())
 getDebugInfo()->addHeapAllocSiteMetadata(CI, RetTy, Loc);


Index: clang/test/CodeGen/debug-info-codeview-heapallocsite.c
===
--- clang/test/CodeGen/debug-info-codeview-heapallocsite.c
+++ clang/test/CodeGen/debug-info-codeview-heapallocsite.c
@@ -1,27 +1,23 @@
 // RUN: %clang_cc1 -triple x86_64-windows-msvc -debug-info-kind=limited -gcodeview -fdeclspec -S -emit-llvm < %s | FileCheck %s
 
-struct Foo {
-  int x;
-};
+struct Foo;
+struct Bar;
 
 __declspec(allocator) void *alloc_void();
-__declspec(allocator) struct Foo *alloc_foo();
 
-void call_alloc_void() {
-  struct Foo *p = (struct Foo*)alloc_void();
+void call_alloc() {
+  struct Foo *p = alloc_void();
+  struct Foo *q = (struct Foo*)alloc_void();
+  struct Foo *r = (struct Foo*)(struct Bar*)alloc_void();
 }
 
-void call_alloc_foo() {
-  struct Foo *p = alloc_foo();
-}
-
-// CHECK-LABEL: define {{.*}}void @call_alloc_void
+// CHECK-LABEL: define {{.*}}void @call_alloc
 // CHECK: call i8* {{.*}}@alloc_void{{.*}} !heapallocsite [[DBG1:!.*]]
-
-// CHECK-LABEL: define {{.*}}void @call_alloc_foo
-// CHECK: call %struct.Foo* {{.*}}@alloc_foo{{.*}} !heapallocsite [[DBG2:!.*]]
+// CHECK: call i8* {{.*}}@alloc_void{{.*}} !heapallocsite [[DBG2:!.*]]
+// CHECK: call i8* {{.*}}@alloc_void{{.*}} !heapallocsite [[DBG3:!.*]]
 
 // CHECK: [[DBG1]] = !{}
-// CHECK: [[DBG2]] = distinct !DICompositeType(tag: DW_TAG_structure_type,
+// CHECK: [[DBG2]] = !DICompositeType(tag: DW_TAG_structure_type,
 // CHECK-SAME: name: "Foo"
-
+// CHECK: [[DBG3]] = !DICompositeType(tag: DW_TAG_structure_type,
+// CHECK-SAME: name: "Bar"
Index: clang/lib/CodeGen/CGExprScalar.cpp
===
--- clang/lib/CodeGen/CGExprScalar.cpp
+++ clang/lib/CodeGen/CGExprScalar.cpp
@@ 

[PATCH] D61399: [OpenMP][Clang] Support for target math functions

[Hal Finkel via Phabricator via cfe-commits]

hfinkel added a comment.

In D61399#1488262 , @ABataev wrote:

> I don't like this implementation. Seems to me, it breaks one of the OpenMP 
> standard requirements: the program can be compiled without openmp support. I 
> assume, that with this includes the program won't be able to be compiled 
> without OpenMP support anymore because it may use some device-specific math 
> functions explicitly.
>  Instead, I would like to see some additional, device-scpecific math header 
> file, that must be included explicitly to support some device-specific math 
> functions. And we need to provide default implementations for those extra 
> math functions for all the platforms we're going to support, including 
> default host implementations.


Can you provide an example of a conforming program that can't be compiled 
without OpenMP support? Regardless of the use of any device-specific functions 
(which isn't covered by the standard, of course, but might be needed in 
practice), the code still needs to be compilable by the host in order to 
generate the host-fallback version. This doesn't change that. Thus, any program 
that uses anything from this math.h, etc. needs to compile for the host, and 
thus, likely compiles without OpenMP support. Maybe I'm missing your point, 
however.


Repository:
  rC Clang

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

https://reviews.llvm.org/D61399



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

[PATCH] D61455: Change the metadata for heapallocsite calls when the type is cast.

[Amy Huang via Phabricator via cfe-commits]

akhuang abandoned this revision.
akhuang added a comment.

accidentally created a new revision


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61455



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

[PATCH] D61454: [CodeGen][ObjC] Remove the leading 'l_' from ObjC symbols and make private symbols in the __DATA segment internal.

[Akira Hatanaka via Phabricator via cfe-commits]

ahatanak created this revision.
ahatanak added reviewers: rjmccall, vsk.
ahatanak added a project: clang.
Herald added subscribers: dexonsmith, jkorous.

This change is a continuation of https://reviews.llvm.org/D59234 and makes the 
symbols within __DATA visible.

rdar://problem/48887111


Repository:
  rC Clang

https://reviews.llvm.org/D61454

Files:
  lib/CodeGen/CGObjCMac.cpp
  test/CodeGenObjC/arc.m
  test/CodeGenObjC/boxing.m
  test/CodeGenObjC/exceptions-asm-attribute.m
  test/CodeGenObjC/externally-initialized-selectors.m
  test/CodeGenObjC/forward-protocol-metadata-symbols.m
  test/CodeGenObjC/instance-method-metadata.m
  test/CodeGenObjC/interface-layout-64.m
  test/CodeGenObjC/metadata-class-properties.m
  test/CodeGenObjC/metadata-symbols-32.m
  test/CodeGenObjC/metadata-symbols-64.m
  test/CodeGenObjC/metadata_symbols.m
  test/CodeGenObjC/mrc-weak.m
  test/CodeGenObjC/non-lazy-classes.m
  test/CodeGenObjC/ns-constant-strings.m
  test/CodeGenObjC/private-extern-selector-reference.m
  test/CodeGenObjC/property-category-impl.m
  test/CodeGenObjC/property-list-in-class.m
  test/CodeGenObjC/property-list-in-extension.m
  test/CodeGenObjC/protocol-comdat.m
  test/CodeGenObjC/protocols.m
  test/CodeGenObjC/section-name.m
  test/CodeGenObjC/sections.m
  test/CodeGenObjCXX/externally-initialized-selectors.mm
  test/CodeGenObjCXX/mrc-weak.mm

Index: test/CodeGenObjCXX/mrc-weak.mm
===
--- test/CodeGenObjCXX/mrc-weak.mm
+++ test/CodeGenObjCXX/mrc-weak.mm
@@ -7,7 +7,7 @@
 @end
 
 // CHECK-MODERN: @OBJC_CLASS_NAME_{{.*}} = {{.*}} c"\01\00"
-// CHECK-MODERN: @"\01l_OBJC_CLASS_RO_$_Foo" = {{.*}} { i32 772
+// CHECK-MODERN: @"_OBJC_CLASS_RO_$_Foo" = {{.*}} { i32 772
 //   772 == 0x304
 //^ HasMRCWeakIvars
 //^ HasCXXDestructorOnly
Index: test/CodeGenObjCXX/externally-initialized-selectors.mm
===
--- test/CodeGenObjCXX/externally-initialized-selectors.mm
+++ test/CodeGenObjCXX/externally-initialized-selectors.mm
@@ -1,7 +1,8 @@
-// RUN: %clang_cc1 -fobjc-runtime=macosx-fragile-10.5 -o - -emit-llvm %s | FileCheck %s
-// RUN: %clang_cc1 -o - -emit-llvm %s | FileCheck %s
+// RUN: %clang_cc1 -fobjc-runtime=macosx-fragile-10.5 -o - -emit-llvm %s | FileCheck -check-prefix=FRAGILE %s
+// RUN: %clang_cc1 -o - -emit-llvm %s | FileCheck -check-prefix=NONFRAGILE %s
 
-// CHECK: @OBJC_SELECTOR_REFERENCES_ = private externally_initialized global
+// NONFRAGILE: @OBJC_SELECTOR_REFERENCES_ = internal externally_initialized global
+// FRAGILE: @OBJC_SELECTOR_REFERENCES_ = private externally_initialized global
 
 void test(id x) {
   [x doSomething];
Index: test/CodeGenObjC/sections.m
===
--- test/CodeGenObjC/sections.m
+++ test/CodeGenObjC/sections.m
@@ -37,9 +37,9 @@
 // CHECK-COFF: @"OBJC_CLASSLIST_SUP_REFS_$_" = {{.*}}, section ".objc_superrefs$B"
 // CHECK-COFF: @OBJC_SELECTOR_REFERENCES_ = {{.*}}, section ".objc_selrefs$B"
 // CHECK-COFF: @"OBJC_CLASSLIST_REFERENCES_$_" = {{.*}}, section ".objc_classrefs$B"
-// CHECK-COFF: @"\01l_objc_msgSend_fixup_class" = {{.*}}, section ".objc_msgrefs$B"
+// CHECK-COFF: @_objc_msgSend_fixup_class = {{.*}}, section ".objc_msgrefs$B"
 // CHECK-COFF: @"_OBJC_LABEL_PROTOCOL_$_P" = {{.*}}, section ".objc_protolist$B"
-// CHECK-COFF: @"\01l_OBJC_PROTOCOL_REFERENCE_$_P" = {{.*}}, section ".objc_protorefs$B"
+// CHECK-COFF: @"_OBJC_PROTOCOL_REFERENCE_$_P" = {{.*}}, section ".objc_protorefs$B"
 // CHECK-COFF: @"OBJC_LABEL_CLASS_$" = {{.*}}, section ".objc_classlist$B"
 // CHECK-COFF: @"OBJC_LABEL_NONLAZY_CLASS_$" = {{.*}}, section ".objc_nlclslist$B"
 // CHECK-COFF: @"OBJC_LABEL_CATEGORY_$" = {{.*}}, section ".objc_catlist$B"
@@ -49,9 +49,9 @@
 // CHECK-ELF: @"OBJC_CLASSLIST_SUP_REFS_$_" = {{.*}}, section "objc_superrefs"
 // CHECK-ELF: @OBJC_SELECTOR_REFERENCES_ = {{.*}}, section "objc_selrefs"
 // CHECK-ELF: @"OBJC_CLASSLIST_REFERENCES_$_" = {{.*}}, section "objc_classrefs"
-// CHECK-ELF: @"\01l_objc_msgSend_fixup_class" = {{.*}}, section "objc_msgrefs"
+// CHECK-ELF: @_objc_msgSend_fixup_class = {{.*}}, section "objc_msgrefs"
 // CHECK-ELF: @"_OBJC_LABEL_PROTOCOL_$_P" = {{.*}}, section "objc_protolist"
-// CHECK-ELF: @"\01l_OBJC_PROTOCOL_REFERENCE_$_P" = {{.*}}, section "objc_protorefs"
+// CHECK-ELF: @"_OBJC_PROTOCOL_REFERENCE_$_P" = {{.*}}, section "objc_protorefs"
 // CHECK-ELF: @"OBJC_LABEL_CLASS_$" = {{.*}}, section "objc_classlist"
 // CHECK-ELF: @"OBJC_LABEL_NONLAZY_CLASS_$" = {{.*}}, section "objc_nlclslist"
 // CHECK-ELF: @"OBJC_LABEL_CATEGORY_$" = {{.*}}, section "objc_catlist"
@@ -61,9 +61,9 @@
 // CHECK-MACHO: @"OBJC_CLASSLIST_SUP_REFS_$_" = {{.*}}, section "__DATA,__objc_superrefs,regular,no_dead_strip"
 // CHECK-MACHO: @OBJC_SELECTOR_REFERENCES_ = {{.*}}, section "__DATA,__objc_selrefs,literal_pointers,no_dead_strip"
 // CHECK-MACHO: @"OBJC_CLASSLIST_REFERENCES_$_"

[PATCH] D61438: [ASTImporter] Use llvm::Expected and Error in the importer API

[Raphael Isemann via Phabricator via cfe-commits]

teemperor added a comment.

I think the best way to handle these errors in LLDB is to just log and then 
return some default value. That should make the current command print an error, 
which is better than terminating LLDB.

Otherwise the LLDB part of this patch LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61438



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

[PATCH] D61455: Change the metadata for heapallocsite calls when the type is cast.

[Amy Huang via Phabricator via cfe-commits]

akhuang created this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
akhuang abandoned this revision.
akhuang added a comment.

accidentally created a new revision


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D61455

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/test/CodeGen/debug-info-codeview-heapallocsite.c


Index: clang/test/CodeGen/debug-info-codeview-heapallocsite.c
===
--- clang/test/CodeGen/debug-info-codeview-heapallocsite.c
+++ clang/test/CodeGen/debug-info-codeview-heapallocsite.c
@@ -1,27 +1,23 @@
 // RUN: %clang_cc1 -triple x86_64-windows-msvc -debug-info-kind=limited 
-gcodeview -fdeclspec -S -emit-llvm < %s | FileCheck %s
 
-struct Foo {
-  int x;
-};
+struct Foo;
+struct Bar;
 
 __declspec(allocator) void *alloc_void();
-__declspec(allocator) struct Foo *alloc_foo();
 
-void call_alloc_void() {
-  struct Foo *p = (struct Foo*)alloc_void();
+void call_alloc() {
+  struct Foo *p = alloc_void();
+  struct Foo *q = (struct Foo*)alloc_void();
+  struct Foo *r = (struct Foo*)(struct Bar*)alloc_void();
 }
 
-void call_alloc_foo() {
-  struct Foo *p = alloc_foo();
-}
-
-// CHECK-LABEL: define {{.*}}void @call_alloc_void
+// CHECK-LABEL: define {{.*}}void @call_alloc
 // CHECK: call i8* {{.*}}@alloc_void{{.*}} !heapallocsite [[DBG1:!.*]]
-
-// CHECK-LABEL: define {{.*}}void @call_alloc_foo
-// CHECK: call %struct.Foo* {{.*}}@alloc_foo{{.*}} !heapallocsite [[DBG2:!.*]]
+// CHECK: call i8* {{.*}}@alloc_void{{.*}} !heapallocsite [[DBG2:!.*]]
+// CHECK: call i8* {{.*}}@alloc_void{{.*}} !heapallocsite [[DBG3:!.*]]
 
 // CHECK: [[DBG1]] = !{}
-// CHECK: [[DBG2]] = distinct !DICompositeType(tag: DW_TAG_structure_type,
+// CHECK: [[DBG2]] = !DICompositeType(tag: DW_TAG_structure_type,
 // CHECK-SAME: name: "Foo"
-
+// CHECK: [[DBG3]] = !DICompositeType(tag: DW_TAG_structure_type,
+// CHECK-SAME: name: "Bar"
Index: clang/lib/CodeGen/CGExprScalar.cpp
===
--- clang/lib/CodeGen/CGExprScalar.cpp
+++ clang/lib/CodeGen/CGExprScalar.cpp
@@ -2063,6 +2063,12 @@
   }
 }
 
+// Update heapallocsite metadata when there is an explicit cast.
+if (llvm::CallInst *CI = dyn_cast(Src))
+  if (CI->getMetadata("heapallocsite") && dyn_cast(CE))
+  CGF.getDebugInfo()->
+  addHeapAllocSiteMetadata(CI, CE->getType(), CE->getExprLoc());
+
 return Builder.CreateBitCast(Src, DstTy);
   }
   case CK_AddressSpaceConversion: {
Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -4370,7 +4370,6 @@
   }
 
   // Add metadata for calls to MSAllocator functions
-  // FIXME: Get the type that the return value is cast to.
   if (getDebugInfo() && TargetDecl &&
   TargetDecl->hasAttr())
 getDebugInfo()->addHeapAllocSiteMetadata(CI, RetTy, Loc);


Index: clang/test/CodeGen/debug-info-codeview-heapallocsite.c
===
--- clang/test/CodeGen/debug-info-codeview-heapallocsite.c
+++ clang/test/CodeGen/debug-info-codeview-heapallocsite.c
@@ -1,27 +1,23 @@
 // RUN: %clang_cc1 -triple x86_64-windows-msvc -debug-info-kind=limited -gcodeview -fdeclspec -S -emit-llvm < %s | FileCheck %s
 
-struct Foo {
-  int x;
-};
+struct Foo;
+struct Bar;
 
 __declspec(allocator) void *alloc_void();
-__declspec(allocator) struct Foo *alloc_foo();
 
-void call_alloc_void() {
-  struct Foo *p = (struct Foo*)alloc_void();
+void call_alloc() {
+  struct Foo *p = alloc_void();
+  struct Foo *q = (struct Foo*)alloc_void();
+  struct Foo *r = (struct Foo*)(struct Bar*)alloc_void();
 }
 
-void call_alloc_foo() {
-  struct Foo *p = alloc_foo();
-}
-
-// CHECK-LABEL: define {{.*}}void @call_alloc_void
+// CHECK-LABEL: define {{.*}}void @call_alloc
 // CHECK: call i8* {{.*}}@alloc_void{{.*}} !heapallocsite [[DBG1:!.*]]
-
-// CHECK-LABEL: define {{.*}}void @call_alloc_foo
-// CHECK: call %struct.Foo* {{.*}}@alloc_foo{{.*}} !heapallocsite [[DBG2:!.*]]
+// CHECK: call i8* {{.*}}@alloc_void{{.*}} !heapallocsite [[DBG2:!.*]]
+// CHECK: call i8* {{.*}}@alloc_void{{.*}} !heapallocsite [[DBG3:!.*]]
 
 // CHECK: [[DBG1]] = !{}
-// CHECK: [[DBG2]] = distinct !DICompositeType(tag: DW_TAG_structure_type,
+// CHECK: [[DBG2]] = !DICompositeType(tag: DW_TAG_structure_type,
 // CHECK-SAME: name: "Foo"
-
+// CHECK: [[DBG3]] = !DICompositeType(tag: DW_TAG_structure_type,
+// CHECK-SAME: name: "Bar"
Index: clang/lib/CodeGen/CGExprScalar.cpp
===
--- clang/lib/CodeGen/CGExprScalar.cpp
+++ clang/lib/CodeGen/CGExprScalar.cpp
@@ -2063,6 +2063,12 @@
   }
 }
 
+//

[PATCH] D61399: [OpenMP][Clang] Support for target math functions

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added a comment.

Moreover, I think this will cause troubles even in simple cases. Assume we have 
`target if(cond)` construct. In this case we will need to compile the target 
region for both, the device and the host. If the target region uses some 
device-specific math functions, it will break the compilation for the host.


Repository:
  rC Clang

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

https://reviews.llvm.org/D61399



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

[PATCH] D61399: [OpenMP][Clang] Support for target math functions

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added a comment.

I don't like this implementation. Seems to me, it breaks one of the OpenMP 
standard requirements: the program can be compiled without openmp support. I 
assume, that with this includes the program won't be able to be compiled 
without OpenMP support anymore because it may use some device-specific math 
functions explicitly.
Instead, I would like to see some additional, device-scpecific math header 
file, that must be included explicitly to support some device-specific math 
functions. And we need to provide default implementations for those extra math 
functions for all the platforms we're going to support, including default host 
implementations.


Repository:
  rC Clang

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

https://reviews.llvm.org/D61399



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