[PATCH] D123655: [clang-tidy] Add portability-std-allocator-const-t check

2022-04-12 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay created this revision.
MaskRay added reviewers: alexfh, aaron.ballman, njames93, whisperity.
Herald added subscribers: carlosgalvezp, StephenFan, rnkovacs, xazax.hun, 
mgorny.
Herald added a project: All.
MaskRay requested review of this revision.
Herald added a project: clang-tools-extra.
Herald added a subscriber: cfe-commits.

Find undefined container usage due to std::allocator. This is
unsupported in libstdc++ and may be unsupported in future libc++ (D120996 
). See
docs/clang-tidy/checks/portability-std-allocator-const-t.rst for detail.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D123655

Files:
  clang-tools-extra/clang-tidy/portability/CMakeLists.txt
  clang-tools-extra/clang-tidy/portability/PortabilityTidyModule.cpp
  clang-tools-extra/clang-tidy/portability/StdAllocatorConstTCheck.cpp
  clang-tools-extra/clang-tidy/portability/StdAllocatorConstTCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/docs/clang-tidy/checks/portability-std-allocator-const-t.rst
  
clang-tools-extra/test/clang-tidy/checkers/portability-std-allocator-const-t.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/portability-std-allocator-const-t.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/portability-std-allocator-const-t.cpp
@@ -0,0 +1,72 @@
+// RUN: %check_clang_tidy -std=c++11-or-later %s portability-std-allocator-const-t %t --
+
+namespace std {
+typedef unsigned size_t;
+
+template 
+class allocator {};
+template 
+class hash {};
+template 
+class equal_to {};
+template 
+class less {};
+
+template >
+class deque {};
+template >
+class forward_list {};
+template >
+class list {};
+template >
+class vector {};
+
+template , class A = std::allocator>
+class multiset {};
+template , class A = std::allocator>
+class set {};
+
+template >
+class stack {};
+} // namespace std
+
+namespace absl {
+template , class Eq = std::equal_to, class A = std::allocator>
+class flat_hash_set {};
+} // namespace absl
+
+template 
+class allocator {};
+
+void simple(std::vector a) {
+  // CHECK-MESSAGES: [[#@LINE-1]]:13: warning: container using std::allocator is undefined; remove const to work with libstdc++ and future libc++ [portability-std-allocator-const-t]
+  std::deque d;
+  // CHECK-MESSAGES: [[#@LINE-1]]:3: warning: container
+  std::list l;
+  // CHECK-MESSAGES: [[#@LINE-1]]:3: warning: container
+
+  std::multiset ms;
+  // CHECK-MESSAGES: [[#@LINE-1]]:3: warning: container
+  std::set> s;
+  // CHECK-MESSAGES: [[#@LINE-1]]:3: warning: container
+
+  absl::flat_hash_set fhs;
+  // CHECK-MESSAGES: [[#@LINE-1]]:3: warning: container
+
+  std::vector neg0;
+  std::vector neg1; // not const T
+  std::vector> neg2; // not use std::allocator
+  std::forward_list forward;  // rare, don't bother
+  std::stack stack;   // not caught, but rare
+}
+
+template 
+void temp() {
+  std::vector v;
+  // CHECK-MESSAGES: [[#@LINE-1]]:3: warning: container
+
+  std::vector neg;
+}
+void use_temp() {
+  temp();
+}
Index: clang-tools-extra/docs/clang-tidy/checks/portability-std-allocator-const-t.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/portability-std-allocator-const-t.rst
@@ -0,0 +1,22 @@
+.. title:: clang-tidy - portability-std-allocator-const-t
+
+portability-std-allocator-const-t
+=
+
+Per C++ ``[allocator.requirements.general]``: "T is any cv-unqualified object
+type", ``std::allocator`` is undefined. Many standard containers use
+``std::allocator`` by default and therefore their ``const T`` instantiations are
+undefined.
+
+libstdc++ never supports ``std::allocator`` and containers using them.
+Since GCC 8.0 (`PR48101 `),
+there is a better diagnostic for some containers.
+
+.. code:: c++
+
+  std::deque deque; // error: static assertion failed: std::deque must have a non-const, non-volatile value_type
+  std::set set; // error: static assertion failed: std::set must have a non-const, non-volatile value_type
+  std::vector vector; // error: static assertion failed: std::vector must have a non-const, non-volatile value_type
+
+However, code bases not compiled with libstdc++ may accrue such undefined usage.
+This check finds such code and prevents backsliding while clean-up is ongoing.
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -289,6 +289,7 @@
`performance-unnecessary-value-param `_, "Yes"
`portability-restrict-system-includes `_, "Yes"
`portability-simd-intrinsics `_,
+   `portability-std-allocator

[PATCH] D119221: [clang][lexer] Allow u8 character literal prefixes in C2x

2022-04-12 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder updated this revision to Diff 422402.
tbaeder marked an inline comment as done.

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

https://reviews.llvm.org/D119221

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Lex/Lexer.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/Lexer/utf8-char-literal.cpp
  clang/www/c_status.html

Index: clang/www/c_status.html
===
--- clang/www/c_status.html
+++ clang/www/c_status.html
@@ -720,7 +720,7 @@
 
   Adding the u8 character prefix
   http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2418.pdf";>N2418
-  No
+  Clang 15
 
 
   Remove support for function definitions with identifier lists
Index: clang/test/Lexer/utf8-char-literal.cpp
===
--- clang/test/Lexer/utf8-char-literal.cpp
+++ clang/test/Lexer/utf8-char-literal.cpp
@@ -1,5 +1,6 @@
 // RUN: %clang_cc1 -triple x86_64-apple-darwin -std=c++11 -fsyntax-only -verify %s
 // RUN: %clang_cc1 -triple x86_64-apple-darwin -std=c11 -x c -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple x86_64-apple-darwin -std=c2x -x c -fsyntax-only -verify %s
 // RUN: %clang_cc1 -triple x86_64-apple-darwin -std=c++1z -fsyntax-only -verify %s
 
 int array0[u'ñ' == u'\xf1'? 1 : -1];
@@ -12,4 +13,16 @@
 char d = u8'\u1234'; // expected-error {{character too large for enclosing character literal type}}
 char e = u8'ሴ'; // expected-error {{character too large for enclosing character literal type}}
 char f = u8'ab'; // expected-error {{Unicode character literals may not contain multiple characters}}
+#elif __STDC_VERSION__ > 202000L
+char a = u8'ñ';  // expected-error {{character too large for enclosing character literal type}}
+char b = u8'\x80';   // ok
+char c = u8'\u0080'; // expected-error {{universal character name refers to a control character}}
+char d = u8'\u1234'; // expected-error {{character too large for enclosing character literal type}}
+char e = u8'ሴ';  // expected-error {{character too large for enclosing character literal type}}
+char f = u8'ab'; // expected-error {{Unicode character literals may not contain multiple characters}}
+_Static_assert(
+_Generic(u8'a',
+ default : 0,
+ unsigned char : 1),
+"Surprise!");
 #endif
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -3595,6 +3595,8 @@
   QualType Ty;
   if (Literal.isWide())
 Ty = Context.WideCharTy; // L'x' -> wchar_t in C and C++.
+  else if (Literal.isUTF8() && getLangOpts().C2x)
+Ty = Context.UnsignedCharTy; // u8'x' -> unsigned char in C2x
   else if (Literal.isUTF8() && getLangOpts().Char8)
 Ty = Context.Char8Ty; // u8'x' -> char8_t when it exists.
   else if (Literal.isUTF16())
@@ -3604,7 +3606,8 @@
   else if (!getLangOpts().CPlusPlus || Literal.isMultiChar())
 Ty = Context.IntTy;   // 'x' -> int in C, 'wxyz' -> int in C++.
   else
-Ty = Context.CharTy;  // 'x' -> char in C++
+Ty = Context.CharTy; // 'x' -> char in C++;
+ // u8'x' -> char in C11-C17 and in C++ without char8_t.
 
   CharacterLiteral::CharacterKind Kind = CharacterLiteral::Ascii;
   if (Literal.isWide())
Index: clang/lib/Lex/Lexer.cpp
===
--- clang/lib/Lex/Lexer.cpp
+++ clang/lib/Lex/Lexer.cpp
@@ -3459,7 +3459,10 @@
 MIOpt.ReadToken();
 return LexNumericConstant(Result, CurPtr);
 
-  case 'u':   // Identifier (uber) or C11/C++11 UTF-8 or UTF-16 string literal
+  // Identifier (e.g., uber), or
+  // UTF-8 (C2x/C++17) or UTF-16 (C11/C++11) character literal, or
+  // UTF-8 or UTF-16 string literal (C11/C++11).
+  case 'u':
 // Notify MIOpt that we read a non-whitespace/non-comment token.
 MIOpt.ReadToken();
 
@@ -3493,7 +3496,7 @@
ConsumeChar(ConsumeChar(CurPtr, SizeTmp, Result),
SizeTmp2, Result),
tok::utf8_string_literal);
-if (Char2 == '\'' && LangOpts.CPlusPlus17)
+if (Char2 == '\'' && (LangOpts.CPlusPlus17 || LangOpts.C2x))
   return LexCharConstant(
   Result, ConsumeChar(ConsumeChar(CurPtr, SizeTmp, Result),
   SizeTmp2, Result),
@@ -3517,7 +3520,7 @@
 // treat u like the start of an identifier.
 return LexIdentifierContinue(Result, CurPtr);
 
-  case 'U':   // Identifier (Uber) or C11/C++11 UTF-32 string literal
+  case 'U': // Identifier (e.g. Uber) or C11/C++11 UTF-32 string literal
 // Notify MIOpt that we read a non-whitespace/non-comment token.
 MIOpt.ReadToken();
 
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst

[PATCH] D119221: [clang][lexer] Allow u8 character literal prefixes in C2x

2022-04-12 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder marked 2 inline comments as done.
tbaeder added inline comments.



Comment at: clang/test/Lexer/utf8-char-literal.cpp:24
+char g = u8'\x80';  // expected-warning {{implicit conversion from 
'int' to 'char' changes value from 128 to -128}}
 #endif

aaron.ballman wrote:
> tbaeder wrote:
> > tahonermann wrote:
> > > We should also exercise the preprocessor with something like this:
> > >   #if u8'\xff' != 0xff
> > >   #error uh oh
> > >   #endif
> > > 
> > > Hmm, this currently fails for C++20 for both Clang and gcc unless 
> > > `-funsigned-char` is passed. That seems wrong. 
> > > https://godbolt.org/z/Tb7z85ToG. MSVC gets this wrong too, but I think 
> > > for a different reason; see the implementation impact section of [[ 
> > > https://wg21.link/p2029 | P2029 ]] if curious.
> > This also fails in C2x.
> I don't think we need to fix the preprocessor behavior as part of this patch, 
> but it would be good to file an issue for this so we know to track it down at 
> some point.
I've opened https://github.com/llvm/llvm-project/issues/54886


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

https://reviews.llvm.org/D119221

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


[PATCH] D122789: [compiler-rt] [scudo] Use -mcrc32 on x86 when available

2022-04-12 Thread Phoebe Wang via Phabricator via cfe-commits
pengfei added a subscriber: hjl.tools.
pengfei added a comment.

In D122789#3446865 , @MaskRay wrote:

> To kurly (original Gentoo reporter):
>
>   printf '#include \n#include \nuint32_t 
> computeHardwareCRC32(uint32_t Crc, uint32_t Data) { return _mm_crc32_u32(Crc, 
> Data); }' > a.c
>
>
>
>   % clang -m32 -march=i686 -msse4.2 -c a.c  # seems to compile fine
>   % gcc -m32 -march=i686 -msse4.2 -c a.c
>   % gcc -m32 -march=i686 -mcrc32 -c a.c
>   In file included from a.c:1:
>   a.c: In function ‘computeHardwareCRC32’:
>   /usr/lib/gcc/x86_64-linux-gnu/11/include/smmintrin.h:839:1: error: inlining 
> failed in call to ‘always_inline’ ‘_mm_crc32_u32’: target specific option 
> mismatch
> 839 | _mm_crc32_u32 (unsigned int __C, unsigned int __V)
> | ^
>   a.c:3:69: note: called from here
>   3 | uint32_t computeHardwareCRC32(uint32_t Crc, uint32_t Data) { return 
> _mm_crc32_u32(Crc, Data); }
> | 
> ^~~~
>
> I have some older GCC and latest GCC (2022-04, multilib), `gcc -m32 
> -march=i686 -msse4.2 -c a.c`  builds while `-mcrc32` doesn't.
>
> I suspect we should revert the `-mcrc32` change. The `__CRC32__` macro may be 
> fine.

Thanks for the infromation. I got the same result. That's weird. I believe at 
some point, GCC supported `-mcrc32`. @hjl.tools, did GCC intentionally remove 
the support for `-mcrc32`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122789

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


[PATCH] D122659: [clang][preprocessor] Allow calling DumpToken() on annotation tokens

2022-04-12 Thread Timm Bäder via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG0eb5891adcb8: [clang][preprocessor] Allow calling 
DumpToken() on annotation tokens (authored by tbaeder).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122659

Files:
  clang/lib/Lex/Preprocessor.cpp


Index: clang/lib/Lex/Preprocessor.cpp
===
--- clang/lib/Lex/Preprocessor.cpp
+++ clang/lib/Lex/Preprocessor.cpp
@@ -232,8 +232,10 @@
 }
 
 void Preprocessor::DumpToken(const Token &Tok, bool DumpFlags) const {
-  llvm::errs() << tok::getTokenName(Tok.getKind()) << " '"
-   << getSpelling(Tok) << "'";
+  llvm::errs() << tok::getTokenName(Tok.getKind());
+
+  if (!Tok.isAnnotation())
+llvm::errs() << " '" << getSpelling(Tok) << "'";
 
   if (!DumpFlags) return;
 


Index: clang/lib/Lex/Preprocessor.cpp
===
--- clang/lib/Lex/Preprocessor.cpp
+++ clang/lib/Lex/Preprocessor.cpp
@@ -232,8 +232,10 @@
 }
 
 void Preprocessor::DumpToken(const Token &Tok, bool DumpFlags) const {
-  llvm::errs() << tok::getTokenName(Tok.getKind()) << " '"
-   << getSpelling(Tok) << "'";
+  llvm::errs() << tok::getTokenName(Tok.getKind());
+
+  if (!Tok.isAnnotation())
+llvm::errs() << " '" << getSpelling(Tok) << "'";
 
   if (!DumpFlags) return;
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 0eb5891 - [clang][preprocessor] Allow calling DumpToken() on annotation tokens

2022-04-12 Thread Timm Bäder via cfe-commits

Author: Timm Bäder
Date: 2022-04-13T07:06:00+02:00
New Revision: 0eb5891adcb84ccf665e88a62f573a1e22696782

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

LOG: [clang][preprocessor] Allow calling DumpToken() on annotation tokens

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

Added: 


Modified: 
clang/lib/Lex/Preprocessor.cpp

Removed: 




diff  --git a/clang/lib/Lex/Preprocessor.cpp b/clang/lib/Lex/Preprocessor.cpp
index 43b9930db1d6d..abbd1e9d3 100644
--- a/clang/lib/Lex/Preprocessor.cpp
+++ b/clang/lib/Lex/Preprocessor.cpp
@@ -232,8 +232,10 @@ void Preprocessor::FinalizeForModelFile() {
 }
 
 void Preprocessor::DumpToken(const Token &Tok, bool DumpFlags) const {
-  llvm::errs() << tok::getTokenName(Tok.getKind()) << " '"
-   << getSpelling(Tok) << "'";
+  llvm::errs() << tok::getTokenName(Tok.getKind());
+
+  if (!Tok.isAnnotation())
+llvm::errs() << " '" << getSpelling(Tok) << "'";
 
   if (!DumpFlags) return;
 



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


[clang] 0cb9c6e - [clang-format] Allow empty .clang-format file

2022-04-12 Thread via cfe-commits

Author: owenca
Date: 2022-04-12T21:20:54-07:00
New Revision: 0cb9c6ea8398519bfb09479cc8cb29835e707440

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

LOG: [clang-format] Allow empty .clang-format file

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

Added: 


Modified: 
clang/lib/Format/Format.cpp
clang/test/Format/style-on-command-line.cpp

Removed: 




diff  --git a/clang/lib/Format/Format.cpp b/clang/lib/Format/Format.cpp
index 0bbd54353d7b8..bce66d117dbd1 100644
--- a/clang/lib/Format/Format.cpp
+++ b/clang/lib/Format/Format.cpp
@@ -1722,7 +1722,7 @@ std::error_code parseConfiguration(llvm::MemoryBufferRef 
Config,
   FormatStyle::LanguageKind Language = Style->Language;
   assert(Language != FormatStyle::LK_None);
   if (Config.getBuffer().trim().empty())
-return make_error_code(ParseError::Error);
+return make_error_code(ParseError::Success);
   Style->StyleSet.Clear();
   std::vector Styles;
   llvm::yaml::Input Input(Config, /*Ctxt=*/nullptr, DiagHandler,

diff  --git a/clang/test/Format/style-on-command-line.cpp 
b/clang/test/Format/style-on-command-line.cpp
index 3fd89f587dc6f..9825269ef0715 100644
--- a/clang/test/Format/style-on-command-line.cpp
+++ b/clang/test/Format/style-on-command-line.cpp
@@ -5,7 +5,7 @@
 // RUN: mkdir -p %t
 // RUN: printf "BasedOnStyle: google\nIndentWidth: 5\n" > %t/.clang-format
 // RUN: clang-format -style=file -assume-filename=%t/foo.cpp < %s | FileCheck 
-strict-whitespace -check-prefix=CHECK5 %s
-// RUN: printf "\n" > %t/.clang-format
+// RUN: printf "Invalid:\n" > %t/.clang-format
 // RUN: not clang-format -style=file -fallback-style=webkit 
-assume-filename=%t/foo.cpp < %s 2>&1 | FileCheck -strict-whitespace 
-check-prefix=CHECK6 %s
 // RUN: rm %t/.clang-format
 // RUN: printf "BasedOnStyle: google\nIndentWidth: 6\n" > %t/_clang-format
@@ -20,6 +20,13 @@
 // Test yaml with no based style, and fallback style "none", LLVM formatting 
applied
 // RUN: clang-format -style="{IndentWidth: 7}" -fallback-style=none %s | 
FileCheck -strict-whitespace -check-prefix=CHECK11 %s
 
+// Empty config file tests
+// RUN: touch %t/.clang-format
+// RUN: clang-format -style=file -assume-filename=%t/foo.cpp < %s | FileCheck 
-strict-whitespace -check-prefix=CHECK12 %s
+// RUN: rm %t/.clang-format
+// RUN: printf "\n" > %t/_clang-format
+// RUN: clang-format -style=file -assume-filename=%t/foo.cpp < %s | FileCheck 
-strict-whitespace -check-prefix=CHECK13 %s
+
 void f() {
 // CHECK1: {{^int\* i;$}}
 // CHECK2: {{^   int \*i;$}}
@@ -27,12 +34,15 @@ void f() {
 // CHECK3: Error parsing -style: [[MSG]]
 // CHECK4: Error parsing -style: [[MSG]]
 // CHECK5: {{^ int\* i;$}}
+// CHECK6: unknown key 'Invalid'
 // CHECK6: {{^Error reading .*\.clang-format: (I|i)nvalid argument}}
 // CHECK7: {{^  int\* i;$}}
 // CHECK8: {{^  int\* i;$}}
 // CHECK9: {{^int \*i;$}}
 // CHECK10: {{^  int \*i;$}}
 // CHECK11: {{^   int \*i;$}}
+// CHECK12: {{^  int \*i;$}}
+// CHECK13: {{^  int \*i;$}}
 int*i;
 int j;
 }



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


[PATCH] D123612: [Driver] Support linking to compiler-rt on AVR

2022-04-12 Thread Ben Shi via Phabricator via cfe-commits
benshi001 updated this revision to Diff 422388.
Herald added a subscriber: ormris.

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

https://reviews.llvm.org/D123612

Files:
  clang/lib/Driver/ToolChains/AVR.cpp
  clang/lib/Driver/ToolChains/AVR.h
  clang/test/Driver/Inputs/basic_avr_tree/usr/lib/gcc/avr/5.4.0/avr5/libgcc.a
  
clang/test/Driver/Inputs/resource_dir_with_per_target_subdir/lib/avr/libclang_rt.builtins-avr5.a
  clang/test/Driver/avr-toolchain.c

Index: clang/test/Driver/avr-toolchain.c
===
--- clang/test/Driver/avr-toolchain.c
+++ clang/test/Driver/avr-toolchain.c
@@ -58,3 +58,12 @@
 // NOGCC-NOT: warning: {{.*}} microcontroller
 // NOGCC-NOT: warning: {{.*}} avr-libc
 // NOGCC-NOT: warning: {{.*}} data section address
+
+// RUN: %clang %s -### --target=avr -mmcu=atmega328 --sysroot=%S/Inputs/basic_avr_tree/ -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir 2>&1 | FileCheck --check-prefix=LIBGCC %s
+// RUN: %clang %s -### --target=avr -mmcu=atmega328 --sysroot=%S/Inputs/basic_avr_tree/ -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir --rtlib=libgcc 2>&1 | FileCheck --check-prefix=LIBGCC %s
+// LIBGCC: "-lgcc"
+// LIBGCC-NOT: libclang_rt
+
+// RUN: %clang %s -### --target=avr -mmcu=atmega328 --sysroot=%S/Inputs/basic_avr_tree/ -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir --rtlib=compiler-rt 2>&1 | FileCheck --check-prefix=COMRT %s
+// COMRT: libclang_rt.builtins-avr5.a
+// COMRT-NOT: "-lgcc"
Index: clang/lib/Driver/ToolChains/AVR.h
===
--- clang/lib/Driver/ToolChains/AVR.h
+++ clang/lib/Driver/ToolChains/AVR.h
@@ -34,11 +34,20 @@
   llvm::Optional findAVRLibcInstallation() const;
   StringRef getGCCInstallPath() const { return GCCInstallPath; }
 
+  std::string buildCompilerRTBasename(const llvm::opt::ArgList &Args,
+  StringRef Component, FileType Type,
+  bool AddArch) const override;
+
+  std::string getCompilerRTPath() const override;
+
+  ToolChain::RuntimeLibType GetDefaultRuntimeLibType() const override;
+
 protected:
   Tool *buildLinker() const override;
 
 private:
   StringRef GCCInstallPath;
+  std::string MCU;
 };
 
 } // end namespace toolchains
Index: clang/lib/Driver/ToolChains/AVR.cpp
===
--- clang/lib/Driver/ToolChains/AVR.cpp
+++ clang/lib/Driver/ToolChains/AVR.cpp
@@ -19,6 +19,7 @@
 #include "llvm/MC/SubtargetFeature.h"
 #include "llvm/Option/ArgList.h"
 #include "llvm/Support/FileSystem.h"
+#include "llvm/Support/Path.h"
 
 using namespace clang::driver;
 using namespace clang::driver::toolchains;
@@ -369,14 +370,13 @@
 : Generic_ELF(D, Triple, Args) {
   GCCInstallation.init(Triple, Args);
 
-  std::string CPU = getCPUName(D, Args, Triple);
-  if (CPU.empty())
+  MCU = getCPUName(D, Args, Triple);
+  if (MCU.empty())
 D.Diag(diag::warn_drv_avr_mcu_not_specified);
 
   // Only add default libraries if the user hasn't explicitly opted out.
   if (!Args.hasArg(options::OPT_nostdlib) &&
-  !Args.hasArg(options::OPT_nodefaultlibs) &&
-  GCCInstallation.isValid()) {
+  !Args.hasArg(options::OPT_nodefaultlibs) && GCCInstallation.isValid()) {
 GCCInstallPath = GCCInstallation.getInstallPath();
 std::string GCCParentPath(GCCInstallation.getParentLibPath());
 getProgramPaths().push_back(GCCParentPath + "/../bin");
@@ -415,6 +415,36 @@
 CC1Args.push_back("-fno-use-cxa-atexit");
 }
 
+std::string
+AVRToolChain::buildCompilerRTBasename(const llvm::opt::ArgList &Args,
+  StringRef Component, FileType Type,
+  bool AddArch) const {
+  // Each device family has its own compiler-rt build.
+  std::string Arch;
+  if (AddArch) {
+Optional FamilyName = GetMCUFamilyName(MCU);
+if (FamilyName)
+  Arch = "-" + (*FamilyName).str();
+  }
+  // libgcc distributed with avr-gcc always named 'libgcc.a' even on windows.
+  return (Twine("libclang_rt.") + Component + Arch + ".a").str();
+}
+
+std::string AVRToolChain::getCompilerRTPath() const {
+  // Return default path appended with "/avr", if it exists.
+  SmallString<128> Path(ToolChain::getCompilerRTPath());
+  llvm::sys::path::append(Path, "avr");
+  if (llvm::sys::fs::is_directory(Path))
+return std::string(Path.str());
+  // Fall back to default.
+  return ToolChain::getCompilerRTPath();
+}
+
+ToolChain::RuntimeLibType AVRToolChain::GetDefaultRuntimeLibType() const {
+  return GCCInstallation.isValid() ? ToolChain::RLT_Libgcc
+   : ToolChain::RLT_CompilerRT;
+}
+
 Tool *AVRToolChain::buildLinker() const {
   return new tools::AVR::Linker(getTriple(), *this);
 }
@@ -445,13 +475,19 @@
   Args.AddAllArgs(CmdArgs, options::OPT_L);
   getToolChain().AddFilePathLibArgs(Args, CmdArgs);
 

[PATCH] D123648: Restrict lvalue-to-rvalue conversions in CGExprConstant.

2022-04-12 Thread 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


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123648

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


[PATCH] D123438: [Clang] Move Hexagon / VE IAS enabling to Generic_GCC::IsIntegratedAssemblerDefault

2022-04-12 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay accepted this revision.
MaskRay added a comment.
This revision is now accepted and ready to land.
Herald added a subscriber: StephenFan.

LGTM. The subject can be changed to mention NFC.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123438

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


[PATCH] D123642: [clang codegen] Assume arguments of __atomic_* are aligned.

2022-04-12 Thread James Y Knight via Phabricator via cfe-commits
jyknight added a comment.

I disagree with this on principle -- IMO, it is basically a historical bug in 
GCC that it ignores the type alignment, and we should NOT try to match that -- 
it's dangerous.

We ought to resolve the bug via other fixes:

- As a workaround: add alignas(uint64_t) to the affected struct in lld. (is 
GHashCell the only one?)
- Fix `__builtin_addressof` in Clang to propagate alignment in the same way `&` 
does (they ought to act equivalently; I think a new stanza in 
CodeGenFunction::EmitPointerWithAlignment will fix that).
- Ask GCC to modify libstdc++ so that `__builtin_addressof` is called directly, 
instead of going through `std::__addressof`.

In addition to not liking the intended change, I think this implementation is 
wrong -- and will be treacherous to attempt to fix -- because I'm pretty sure 
GCC's implementation doesn't assume particular alignments in general; if it 
decides it _cannot_ emit inline atomics (based on the size and target's 
configuration), then no extra alignment is assumed. (And note that Clang's idea 
of MaxPromoteWidth is unrelated to which sizes of atomics GCC inlines.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123642

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


[PATCH] D123441: [CUDA][HIP] Fix host used external kernel in archive

2022-04-12 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl marked an inline comment as done.
yaxunl added a comment.

In D123441#3446719 , @tra wrote:

> So, a main TU with just `__global__ void kernel();` would emit a reference 
> when it's compiled on the GPU side. That, in turn will tell the linker what 
> it needs to pull from the libraries and things should just work.
> If that's the case, then it would work in my example, too.

Yes, this patch creates artificial references in the device IR originating from 
the host functions in the same TU, or, in other words, it creates the missing 
references which should be there but are not there and no more references than 
those.




Comment at: clang/lib/CodeGen/CodeGenModule.cpp:602
+getModule(), ATy, false, llvm::GlobalValue::AppendingLinkage,
+llvm::ConstantArray::get(ATy, UsedArray), "hip.used.external");
+addCompilerUsedGlobal(GV);

tra wrote:
> This is not HIP-specific and should have a more generic name. 
> `@gpu.used.external` ?
will do when committing.


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

https://reviews.llvm.org/D123441

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


[PATCH] D123298: [NFC] [AST] Reduce the size of TemplateParmPosition

2022-04-12 Thread Chuanqi Xu via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG36de2d639eca: [NFC] [AST] Reduce the size of 
TemplateParmPosition (authored by ChuanqiXu).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123298

Files:
  clang/include/clang/AST/DeclTemplate.h


Index: clang/include/clang/AST/DeclTemplate.h
===
--- clang/include/clang/AST/DeclTemplate.h
+++ clang/include/clang/AST/DeclTemplate.h
@@ -1148,23 +1148,40 @@
 /// parameters and is not part of the Decl hierarchy. Just a facility.
 class TemplateParmPosition {
 protected:
-  // FIXME: These probably don't need to be ints. int:5 for depth, int:8 for
-  // position? Maybe?
-  unsigned Depth;
-  unsigned Position;
+  enum { DepthWidth = 20, PositionWidth = 12 };
+  unsigned Depth : DepthWidth;
+  unsigned Position : PositionWidth;
 
-  TemplateParmPosition(unsigned D, unsigned P) : Depth(D), Position(P) {}
+  static constexpr unsigned MaxDepth = (1U << DepthWidth) - 1;
+  static constexpr unsigned MaxPosition = (1U << PositionWidth) - 1;
+
+  TemplateParmPosition(unsigned D, unsigned P) : Depth(D), Position(P) {
+// The input may fill maximum values to show that it is invalid.
+// Add one here to convert it to zero.
+assert((D + 1) <= MaxDepth &&
+   "The depth of template parmeter position is more than 2^20!");
+assert((P + 1) <= MaxPosition &&
+   "The position of template parmeter position is more than 2^12!");
+  }
 
 public:
   TemplateParmPosition() = delete;
 
   /// Get the nesting depth of the template parameter.
   unsigned getDepth() const { return Depth; }
-  void setDepth(unsigned D) { Depth = D; }
+  void setDepth(unsigned D) {
+assert((D + 1) <= MaxDepth &&
+   "The depth of template parmeter position is more than 2^20!");
+Depth = D;
+  }
 
   /// Get the position of the template parameter within its parameter list.
   unsigned getPosition() const { return Position; }
-  void setPosition(unsigned P) { Position = P; }
+  void setPosition(unsigned P) {
+assert((P + 1) <= MaxPosition &&
+   "The position of template parmeter position is more than 2^12!");
+Position = P;
+  }
 
   /// Get the index of the template parameter within its parameter list.
   unsigned getIndex() const { return Position; }


Index: clang/include/clang/AST/DeclTemplate.h
===
--- clang/include/clang/AST/DeclTemplate.h
+++ clang/include/clang/AST/DeclTemplate.h
@@ -1148,23 +1148,40 @@
 /// parameters and is not part of the Decl hierarchy. Just a facility.
 class TemplateParmPosition {
 protected:
-  // FIXME: These probably don't need to be ints. int:5 for depth, int:8 for
-  // position? Maybe?
-  unsigned Depth;
-  unsigned Position;
+  enum { DepthWidth = 20, PositionWidth = 12 };
+  unsigned Depth : DepthWidth;
+  unsigned Position : PositionWidth;
 
-  TemplateParmPosition(unsigned D, unsigned P) : Depth(D), Position(P) {}
+  static constexpr unsigned MaxDepth = (1U << DepthWidth) - 1;
+  static constexpr unsigned MaxPosition = (1U << PositionWidth) - 1;
+
+  TemplateParmPosition(unsigned D, unsigned P) : Depth(D), Position(P) {
+// The input may fill maximum values to show that it is invalid.
+// Add one here to convert it to zero.
+assert((D + 1) <= MaxDepth &&
+   "The depth of template parmeter position is more than 2^20!");
+assert((P + 1) <= MaxPosition &&
+   "The position of template parmeter position is more than 2^12!");
+  }
 
 public:
   TemplateParmPosition() = delete;
 
   /// Get the nesting depth of the template parameter.
   unsigned getDepth() const { return Depth; }
-  void setDepth(unsigned D) { Depth = D; }
+  void setDepth(unsigned D) {
+assert((D + 1) <= MaxDepth &&
+   "The depth of template parmeter position is more than 2^20!");
+Depth = D;
+  }
 
   /// Get the position of the template parameter within its parameter list.
   unsigned getPosition() const { return Position; }
-  void setPosition(unsigned P) { Position = P; }
+  void setPosition(unsigned P) {
+assert((P + 1) <= MaxPosition &&
+   "The position of template parmeter position is more than 2^12!");
+Position = P;
+  }
 
   /// Get the index of the template parameter within its parameter list.
   unsigned getIndex() const { return Position; }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 36de2d6 - [NFC] [AST] Reduce the size of TemplateParmPosition

2022-04-12 Thread Chuanqi Xu via cfe-commits

Author: Chuanqi Xu
Date: 2022-04-13T10:56:13+08:00
New Revision: 36de2d639eca4cead62a6c6d288a501cee8bb6e7

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

LOG: [NFC] [AST] Reduce the size of TemplateParmPosition

I found this when reading the codes. I think it makes sense to reduce
the space for TemplateParmPosition. It is hard to image the depth of
template parameter is larger than 2^20 and the index is larger than
2^12. So I think the patch might be reasonable.

Reviewed By: aaron.ballman

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

Added: 


Modified: 
clang/include/clang/AST/DeclTemplate.h

Removed: 




diff  --git a/clang/include/clang/AST/DeclTemplate.h 
b/clang/include/clang/AST/DeclTemplate.h
index ca3a8030ffc61..66e0bb2c02a1f 100644
--- a/clang/include/clang/AST/DeclTemplate.h
+++ b/clang/include/clang/AST/DeclTemplate.h
@@ -1148,23 +1148,40 @@ class FunctionTemplateDecl : public 
RedeclarableTemplateDecl {
 /// parameters and is not part of the Decl hierarchy. Just a facility.
 class TemplateParmPosition {
 protected:
-  // FIXME: These probably don't need to be ints. int:5 for depth, int:8 for
-  // position? Maybe?
-  unsigned Depth;
-  unsigned Position;
+  enum { DepthWidth = 20, PositionWidth = 12 };
+  unsigned Depth : DepthWidth;
+  unsigned Position : PositionWidth;
 
-  TemplateParmPosition(unsigned D, unsigned P) : Depth(D), Position(P) {}
+  static constexpr unsigned MaxDepth = (1U << DepthWidth) - 1;
+  static constexpr unsigned MaxPosition = (1U << PositionWidth) - 1;
+
+  TemplateParmPosition(unsigned D, unsigned P) : Depth(D), Position(P) {
+// The input may fill maximum values to show that it is invalid.
+// Add one here to convert it to zero.
+assert((D + 1) <= MaxDepth &&
+   "The depth of template parmeter position is more than 2^20!");
+assert((P + 1) <= MaxPosition &&
+   "The position of template parmeter position is more than 2^12!");
+  }
 
 public:
   TemplateParmPosition() = delete;
 
   /// Get the nesting depth of the template parameter.
   unsigned getDepth() const { return Depth; }
-  void setDepth(unsigned D) { Depth = D; }
+  void setDepth(unsigned D) {
+assert((D + 1) <= MaxDepth &&
+   "The depth of template parmeter position is more than 2^20!");
+Depth = D;
+  }
 
   /// Get the position of the template parameter within its parameter list.
   unsigned getPosition() const { return Position; }
-  void setPosition(unsigned P) { Position = P; }
+  void setPosition(unsigned P) {
+assert((P + 1) <= MaxPosition &&
+   "The position of template parmeter position is more than 2^12!");
+Position = P;
+  }
 
   /// Get the index of the template parameter within its parameter list.
   unsigned getIndex() const { return Position; }



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


[PATCH] D123298: [NFC] [AST] Reduce the size of TemplateParmPosition

2022-04-12 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu added a comment.

In D123298#3445131 , @aaron.ballman 
wrote:

> Still LG to me, but please watch the build bots and issues list closely for 
> any new template instantiation depth/position related issues over the next 
> short while given that we're making a best guess at the bit widths here.

Thanks! I looked at the build bots and the failure cases is about ompt. And I 
think it is unrelated to this patch though.


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

https://reviews.llvm.org/D123298

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


[PATCH] D123300: [Clang] Enable opaque pointers by default

2022-04-12 Thread Arthur Eubanks via Phabricator via cfe-commits
aeubanks added a comment.

In D123300#3447116 , @maryammo wrote:

> @nikic, it seems breaking the  clang-ppc64le-rhel build
>
>   htps://lab.llvm.org/buildbot/#/builders/57/builds/16776
>
> Can you please take a look?

should be fixed by 
https://github.com/llvm/llvm-project/commit/cbcdd5ff8addd8677a0d15c08d449e759801e355


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123300

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


[clang] cbcdd5f - [clang][test] Disable opaque pointers in test

2022-04-12 Thread Arthur Eubanks via cfe-commits

Author: Arthur Eubanks
Date: 2022-04-12T19:15:33-07:00
New Revision: cbcdd5ff8addd8677a0d15c08d449e759801e355

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

LOG: [clang][test] Disable opaque pointers in test

Was missed in opaque pointer switch due to not being run on x86.

Added: 


Modified: 
clang/test/CodeGen/PowerPC/ppc-mm-malloc-le.c

Removed: 




diff  --git a/clang/test/CodeGen/PowerPC/ppc-mm-malloc-le.c 
b/clang/test/CodeGen/PowerPC/ppc-mm-malloc-le.c
index f68577c8edcdd..816e3408f2c53 100644
--- a/clang/test/CodeGen/PowerPC/ppc-mm-malloc-le.c
+++ b/clang/test/CodeGen/PowerPC/ppc-mm-malloc-le.c
@@ -6,7 +6,7 @@
 // require installing target headers in build env, otherwise expecting
 // failures. So this test will focus on native build only.
 
-// RUN: %clang -target powerpc64le-unknown-linux-gnu -S -emit-llvm %s 
-fno-discard-value-names -mllvm -disable-llvm-optzns -o - | llvm-cxxfilt | 
FileCheck %s
+// RUN: %clang -Xclang -no-opaque-pointers -target 
powerpc64le-unknown-linux-gnu -S -emit-llvm %s -fno-discard-value-names -mllvm 
-disable-llvm-optzns -o - | llvm-cxxfilt | FileCheck %s
 
 #include 
 



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


[PATCH] D123648: Restrict lvalue-to-rvalue conversions in CGExprConstant.

2022-04-12 Thread LiqinWeng via Phabricator via cfe-commits
Miss_Grape added inline comments.



Comment at: clang/lib/CodeGen/CGExprConstant.cpp:1096
+case CK_LValueToRValue: {
+  // We don't really support doing lvalue-to-rvalue conversions here; any
+  // interesting conversions should be done in Evaluate().  But as a

Could you add a test case?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123648

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


[PATCH] D123345: Treat `std::move`, `forward`, and `move_if_noexcept` as builtins.

2022-04-12 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added inline comments.



Comment at: clang/docs/CommandGuide/clang.rst:264
+
+.. option:: -fno-builtin-std-
+

xbolva00 wrote:
> -fno-builtin=xxx,yyy,zzz
> 
> wdyt?
Seems reasonable to me to treat `-fno-builtin-` and `-fno-builtin=` 
as equivalent, and I certainly prefer the latter form. I think that's somewhat 
orthogonal to this patch, though: I'm not introducing `-fno-builtin-blah` here, 
only documenting it. (It's a GCC flag originally.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123345

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


[PATCH] D122865: [HLSL][clang][Driver] Support target profile command line option.

2022-04-12 Thread Xiang Li via Phabricator via cfe-commits
python3kgae updated this revision to Diff 422377.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122865

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Driver.h
  clang/include/clang/Driver/Options.h
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/CMakeLists.txt
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/HLSL.cpp
  clang/lib/Driver/ToolChains/HLSL.h
  clang/lib/Driver/Types.cpp
  clang/test/lit.cfg.py
  clang/unittests/Driver/ToolChainTest.cpp

Index: clang/unittests/Driver/ToolChainTest.cpp
===
--- clang/unittests/Driver/ToolChainTest.cpp
+++ clang/unittests/Driver/ToolChainTest.cpp
@@ -300,6 +300,12 @@
   EXPECT_TRUE(Res.ModeSuffix == "clang-cl");
   EXPECT_STREQ(Res.DriverMode, "--driver-mode=cl");
   EXPECT_FALSE(Res.TargetIsValid);
+
+  Res = ToolChain::getTargetAndModeFromProgramName("clang-dxc");
+  EXPECT_TRUE(Res.TargetPrefix.empty());
+  EXPECT_TRUE(Res.ModeSuffix == "clang-dxc");
+  EXPECT_STREQ(Res.DriverMode, "--driver-mode=dxc");
+  EXPECT_FALSE(Res.TargetIsValid);
 }
 
 TEST(ToolChainTest, CommandOutput) {
@@ -361,4 +367,141 @@
   EXPECT_EQ(getDriverMode(Args[0], llvm::makeArrayRef(Args).slice(1)), "bar");
 }
 
+TEST(DxcModeTest, TargetProfileValidation) {
+  IntrusiveRefCntPtr DiagID(new DiagnosticIDs());
+  struct SimpleDiagnosticConsumer : public DiagnosticConsumer {
+void HandleDiagnostic(DiagnosticsEngine::Level DiagLevel,
+  const Diagnostic &Info) override {
+  if (DiagLevel == DiagnosticsEngine::Level::Error) {
+Errors.emplace_back();
+Info.FormatDiagnostic(Errors.back());
+  } else {
+Msgs.emplace_back();
+Info.FormatDiagnostic(Msgs.back());
+  }
+}
+void clear() override {
+  Msgs.clear();
+  Errors.clear();
+  DiagnosticConsumer::clear();
+}
+std::vector> Msgs;
+std::vector> Errors;
+  };
+
+  IntrusiveRefCntPtr InMemoryFileSystem(
+  new llvm::vfs::InMemoryFileSystem);
+
+  InMemoryFileSystem->addFile("foo.hlsl", 0,
+  llvm::MemoryBuffer::getMemBuffer("\n"));
+
+  auto *DiagConsumer = new SimpleDiagnosticConsumer;
+  IntrusiveRefCntPtr DiagOpts = new DiagnosticOptions();
+  DiagnosticsEngine Diags(DiagID, &*DiagOpts, DiagConsumer);
+  Driver TheDriver("/bin/clang", "", Diags, "", InMemoryFileSystem);
+  std::unique_ptr C(
+  TheDriver.BuildCompilation({"clang", "--driver-mode=dxc", "foo.hlsl"}));
+  EXPECT_TRUE(C);
+  EXPECT_TRUE(!C->containsError());
+
+  auto &TC = C->getDefaultToolChain();
+  bool ContainsError = false;
+  auto Args = TheDriver.ParseArgStrings({"-Tvs_6_0"}, false, ContainsError);
+  EXPECT_FALSE(ContainsError);
+  auto Triple = TC.ComputeEffectiveClangTriple(Args);
+  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.0-vertex");
+  EXPECT_EQ(Diags.getNumErrors(), 0);
+
+  Args = TheDriver.ParseArgStrings({"-Ths_6_1"}, false, ContainsError);
+  EXPECT_FALSE(ContainsError);
+  Triple = TC.ComputeEffectiveClangTriple(Args);
+  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.1-hull");
+  EXPECT_EQ(Diags.getNumErrors(), 0);
+
+  Args = TheDriver.ParseArgStrings({"-Tds_6_2"}, false, ContainsError);
+  EXPECT_FALSE(ContainsError);
+  Triple = TC.ComputeEffectiveClangTriple(Args);
+  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.2-domain");
+  EXPECT_EQ(Diags.getNumErrors(), 0);
+
+  Args = TheDriver.ParseArgStrings({"-Tds_6_2"}, false, ContainsError);
+  EXPECT_FALSE(ContainsError);
+  Triple = TC.ComputeEffectiveClangTriple(Args);
+  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.2-domain");
+  EXPECT_EQ(Diags.getNumErrors(), 0);
+
+  Args = TheDriver.ParseArgStrings({"-Tgs_6_3"}, false, ContainsError);
+  EXPECT_FALSE(ContainsError);
+  Triple = TC.ComputeEffectiveClangTriple(Args);
+  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.3-geometry");
+  EXPECT_EQ(Diags.getNumErrors(), 0);
+
+  Args = TheDriver.ParseArgStrings({"-Tps_6_4"}, false, ContainsError);
+  EXPECT_FALSE(ContainsError);
+  Triple = TC.ComputeEffectiveClangTriple(Args);
+  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.4-pixel");
+  EXPECT_EQ(Diags.getNumErrors(), 0);
+
+  Args = TheDriver.ParseArgStrings({"-Tcs_6_5"}, false, ContainsError);
+  EXPECT_FALSE(ContainsError);
+  Triple = TC.ComputeEffectiveClangTriple(Args);
+  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.5-compute");
+  EXPECT_EQ(Diags.getNumErrors(), 0);
+
+  Args = TheDriver.ParseArgStrings({"-Tms_6_6"}, false, ContainsError);
+  EXPECT_FALSE(ContainsError);
+  Triple = TC.ComputeEffectiveClangTriple(Args);
+  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.6-mesh");
+  EXPECT_EQ(Diags.getNumErrors(), 0);
+
+  Args = TheDriver.ParseArgStrings({"-Tas_6_7"}, false, ContainsError);
+  EXPECT_FALSE(ContainsError);
+  Triple = TC.Comput

[PATCH] D123300: [Clang] Enable opaque pointers by default

2022-04-12 Thread Maryam Moghadas via Phabricator via cfe-commits
maryammo added a comment.

@nikic, it seems breaking the  clang-ppc64le-rhel build

  htps://lab.llvm.org/buildbot/#/builders/57/builds/16776

Can you please take a look?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123300

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


[PATCH] D123345: Treat `std::move`, `forward`, and `move_if_noexcept` as builtins.

2022-04-12 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 added inline comments.



Comment at: clang/docs/CommandGuide/clang.rst:264
+
+.. option:: -fno-builtin-std-
+

-fno-builtin=xxx,yyy,zzz

wdyt?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123345

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


[PATCH] D123535: [clang-format] Allow empty .clang-format file

2022-04-12 Thread Owen Pan via Phabricator via cfe-commits
owenpan updated this revision to Diff 422373.
owenpan added a comment.

Updated command line tests.


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

https://reviews.llvm.org/D123535

Files:
  clang/lib/Format/Format.cpp
  clang/test/Format/style-on-command-line.cpp


Index: clang/test/Format/style-on-command-line.cpp
===
--- clang/test/Format/style-on-command-line.cpp
+++ clang/test/Format/style-on-command-line.cpp
@@ -5,7 +5,7 @@
 // RUN: mkdir -p %t
 // RUN: printf "BasedOnStyle: google\nIndentWidth: 5\n" > %t/.clang-format
 // RUN: clang-format -style=file -assume-filename=%t/foo.cpp < %s | FileCheck 
-strict-whitespace -check-prefix=CHECK5 %s
-// RUN: printf "\n" > %t/.clang-format
+// RUN: printf "Invalid:\n" > %t/.clang-format
 // RUN: not clang-format -style=file -fallback-style=webkit 
-assume-filename=%t/foo.cpp < %s 2>&1 | FileCheck -strict-whitespace 
-check-prefix=CHECK6 %s
 // RUN: rm %t/.clang-format
 // RUN: printf "BasedOnStyle: google\nIndentWidth: 6\n" > %t/_clang-format
@@ -20,6 +20,13 @@
 // Test yaml with no based style, and fallback style "none", LLVM formatting 
applied
 // RUN: clang-format -style="{IndentWidth: 7}" -fallback-style=none %s | 
FileCheck -strict-whitespace -check-prefix=CHECK11 %s
 
+// Empty config file tests
+// RUN: touch %t/.clang-format
+// RUN: clang-format -style=file -assume-filename=%t/foo.cpp < %s | FileCheck 
-strict-whitespace -check-prefix=CHECK12 %s
+// RUN: rm %t/.clang-format
+// RUN: printf "\n" > %t/_clang-format
+// RUN: clang-format -style=file -assume-filename=%t/foo.cpp < %s | FileCheck 
-strict-whitespace -check-prefix=CHECK13 %s
+
 void f() {
 // CHECK1: {{^int\* i;$}}
 // CHECK2: {{^   int \*i;$}}
@@ -27,12 +34,15 @@
 // CHECK3: Error parsing -style: [[MSG]]
 // CHECK4: Error parsing -style: [[MSG]]
 // CHECK5: {{^ int\* i;$}}
+// CHECK6: unknown key 'Invalid'
 // CHECK6: {{^Error reading .*\.clang-format: (I|i)nvalid argument}}
 // CHECK7: {{^  int\* i;$}}
 // CHECK8: {{^  int\* i;$}}
 // CHECK9: {{^int \*i;$}}
 // CHECK10: {{^  int \*i;$}}
 // CHECK11: {{^   int \*i;$}}
+// CHECK12: {{^  int \*i;$}}
+// CHECK13: {{^  int \*i;$}}
 int*i;
 int j;
 }
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -1722,7 +1722,7 @@
   FormatStyle::LanguageKind Language = Style->Language;
   assert(Language != FormatStyle::LK_None);
   if (Config.getBuffer().trim().empty())
-return make_error_code(ParseError::Error);
+return make_error_code(ParseError::Success);
   Style->StyleSet.Clear();
   std::vector Styles;
   llvm::yaml::Input Input(Config, /*Ctxt=*/nullptr, DiagHandler,


Index: clang/test/Format/style-on-command-line.cpp
===
--- clang/test/Format/style-on-command-line.cpp
+++ clang/test/Format/style-on-command-line.cpp
@@ -5,7 +5,7 @@
 // RUN: mkdir -p %t
 // RUN: printf "BasedOnStyle: google\nIndentWidth: 5\n" > %t/.clang-format
 // RUN: clang-format -style=file -assume-filename=%t/foo.cpp < %s | FileCheck -strict-whitespace -check-prefix=CHECK5 %s
-// RUN: printf "\n" > %t/.clang-format
+// RUN: printf "Invalid:\n" > %t/.clang-format
 // RUN: not clang-format -style=file -fallback-style=webkit -assume-filename=%t/foo.cpp < %s 2>&1 | FileCheck -strict-whitespace -check-prefix=CHECK6 %s
 // RUN: rm %t/.clang-format
 // RUN: printf "BasedOnStyle: google\nIndentWidth: 6\n" > %t/_clang-format
@@ -20,6 +20,13 @@
 // Test yaml with no based style, and fallback style "none", LLVM formatting applied
 // RUN: clang-format -style="{IndentWidth: 7}" -fallback-style=none %s | FileCheck -strict-whitespace -check-prefix=CHECK11 %s
 
+// Empty config file tests
+// RUN: touch %t/.clang-format
+// RUN: clang-format -style=file -assume-filename=%t/foo.cpp < %s | FileCheck -strict-whitespace -check-prefix=CHECK12 %s
+// RUN: rm %t/.clang-format
+// RUN: printf "\n" > %t/_clang-format
+// RUN: clang-format -style=file -assume-filename=%t/foo.cpp < %s | FileCheck -strict-whitespace -check-prefix=CHECK13 %s
+
 void f() {
 // CHECK1: {{^int\* i;$}}
 // CHECK2: {{^   int \*i;$}}
@@ -27,12 +34,15 @@
 // CHECK3: Error parsing -style: [[MSG]]
 // CHECK4: Error parsing -style: [[MSG]]
 // CHECK5: {{^ int\* i;$}}
+// CHECK6: unknown key 'Invalid'
 // CHECK6: {{^Error reading .*\.clang-format: (I|i)nvalid argument}}
 // CHECK7: {{^  int\* i;$}}
 // CHECK8: {{^  int\* i;$}}
 // CHECK9: {{^int \*i;$}}
 // CHECK10: {{^  int \*i;$}}
 // CHECK11: {{^   int \*i;$}}
+// CHECK12: {{^  int \*i;$}}
+// CHECK13: {{^  int \*i;$}}
 int*i;
 int j;
 }
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -1722,7 +1722,7 @@
   FormatStyle::Languag

[PATCH] D123649: Allow flexible array initialization in C++.

2022-04-12 Thread Eli Friedman via Phabricator via cfe-commits
efriedma created this revision.
efriedma added reviewers: aaron.ballman, rsmith, erichkeane.
Herald added a project: All.
efriedma requested review of this revision.
Herald added a project: clang.

Flexible array initialization is a C/C++ extension implemented in many 
compilers to allow initializing the flexible array tail of a struct type that 
contains a flexible array.  In clang, this is currently restricted to C. But 
this construct is used in the Microsoft SDK headers, so I'd like to extend it 
to C++.

For now, this doesn't handle dynamic initialization; probably not hard to 
implement, but it's extra code, and I don't think it's necessary for the 
expected uses.  And I'm not handling constant evaluation; it should fail 
gracefully.

I've added some additional code to assert that flexible array init works the 
way we expect it to in both C and C++.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D123649

Files:
  clang/include/clang/AST/Decl.h
  clang/lib/AST/Decl.cpp
  clang/lib/CodeGen/CGDecl.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/Sema/SemaInit.cpp
  clang/test/CodeGenCXX/flexible-array-init.cpp
  clang/test/SemaCXX/constant-expression-cxx11.cpp

Index: clang/test/SemaCXX/constant-expression-cxx11.cpp
===
--- clang/test/SemaCXX/constant-expression-cxx11.cpp
+++ clang/test/SemaCXX/constant-expression-cxx11.cpp
@@ -2383,9 +2383,10 @@
   static_assert(b[2].x == 3, "");
   static_assert(b[2].arr[0], ""); // expected-error {{constant expression}} expected-note {{array member without known bound}}
 
-  // If we ever start to accept this, we'll need to ensure we can
-  // constant-evaluate it properly.
-  constexpr A c = {1, 2, 3}; // expected-error {{initialization of flexible array member}}
+  // Flexible array initialization is currently not supported by constant
+  // evaluation. Make sure we emit a sane error message, for now.
+  constexpr A c = {1, 2, 3}; // expected-warning {{flexible array initialization is a GNU extension}}
+  static_assert(c.arr[0] == 1, ""); // expected-error {{constant expression}} expected-note {{array member without known bound}}
 }
 
 void local_constexpr_var() {
Index: clang/test/CodeGenCXX/flexible-array-init.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/flexible-array-init.cpp
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -triple i386-unknown-unknown -emit-llvm -o - %s | FileCheck %s
+
+struct A { int x; int y[]; };
+A a = { 1, 7, 11 };
+// CHECK: @a ={{.*}} global { i32, [2 x i32] } { i32 1, [2 x i32] [i32 7, i32 11] }
+
+struct B { int x; int y[]; };
+B b = { 1, { 13, 15 } };
+// CHECK: @b ={{.*}} global { i32, [2 x i32] } { i32 1, [2 x i32] [i32 13, i32 15] }
Index: clang/lib/Sema/SemaInit.cpp
===
--- clang/lib/Sema/SemaInit.cpp
+++ clang/lib/Sema/SemaInit.cpp
@@ -2004,10 +2004,6 @@
   cast(InitExpr)->getNumInits() == 0) {
 // Empty flexible array init always allowed as an extension
 FlexArrayDiag = diag::ext_flexible_array_init;
-  } else if (SemaRef.getLangOpts().CPlusPlus) {
-// Disallow flexible array init in C++; it is not required for gcc
-// compatibility, and it needs work to IRGen correctly in general.
-FlexArrayDiag = diag::err_flexible_array_init;
   } else if (!TopLevelObject) {
 // Disallow flexible array init on non-top-level object
 FlexArrayDiag = diag::err_flexible_array_init;
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -4614,6 +4614,8 @@
 T = D->getType();
 
   if (getLangOpts().CPlusPlus) {
+if (!InitDecl->getFlexibleArrayInitChars(getContext()).isZero())
+  ErrorUnsupported(D, "flexible array initializer");
 Init = EmitNullConstant(T);
 NeedsGlobalCtor = true;
   } else {
@@ -4627,6 +4629,14 @@
   // also don't need to register a destructor.
   if (getLangOpts().CPlusPlus && !NeedsGlobalDtor)
 DelayedCXXInitPosition.erase(D);
+
+#ifndef NDEBUG
+  CharUnits VarSize = getContext().getTypeSizeInChars(ASTTy) +
+  InitDecl->getFlexibleArrayInitChars(getContext());
+  CharUnits CstSize = CharUnits::fromQuantity(
+  getDataLayout().getTypeAllocSize(Init->getType()));
+  assert(VarSize == CstSize && "Emitted constant has unexpected size");
+#endif
 }
   }
 
Index: clang/lib/CodeGen/CGDecl.cpp
===
--- clang/lib/CodeGen/CGDecl.cpp
+++ clang/lib/CodeGen/CGDecl.cpp
@@ -342,6 +342,8 @@
   if (!Init) {
 if (!getLangOpts().CPlusPlus)
   CGM.ErrorUnsupported(D.getInit(), "constant l-value expression");
+else if (!D.getFlexibleArrayInitChars(getContext()).isZero())
+  CGM.ErrorUnsuppo

[PATCH] D123648: Restrict lvalue-to-rvalue conversions in CGExprConstant.

2022-04-12 Thread Eli Friedman via Phabricator via cfe-commits
efriedma created this revision.
efriedma added reviewers: aaron.ballman, rjmccall, rsmith.
Herald added a project: All.
efriedma requested review of this revision.
Herald added a project: clang.

We were generating wrong code for cxx20-consteval-crash.cpp: instead of loading 
a value of a variable, we were using its address as the initializer.

Found while adding code to verify the size of constant initializers.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D123648

Files:
  clang/lib/CodeGen/CGExprConstant.cpp
  clang/test/CodeGenCXX/cxx20-consteval-crash.cpp


Index: clang/test/CodeGenCXX/cxx20-consteval-crash.cpp
===
--- clang/test/CodeGenCXX/cxx20-consteval-crash.cpp
+++ clang/test/CodeGenCXX/cxx20-consteval-crash.cpp
@@ -9,7 +9,7 @@
 
 // CHECK: @_ZN7PR507872x_E = external global i32, align 4
 // CHECK-NEXT: @_ZN7PR507872x1E = constant i32* @_ZN7PR507872x_E, align 8
-// CHECK-NEXT: @_ZN7PR507872x2E = global i32* @_ZN7PR507872x_E, align 4
+// CHECK-NEXT: @_ZN7PR507872x2E = global i32 0, align 4
 }
 
 namespace PR51484 {
@@ -18,7 +18,7 @@
 consteval X g() { return {0}; }
 void f() { g(); }
 
-// CHECK: define dso_local void @_ZN7PR514841fEv() #0 {
+// CHECK: define dso_local void @_ZN7PR514841fEv() #1 {
 // CHECK: entry:
 // CHECK-NOT: call i32 @_ZN7PR514841gEv()
 // CHECK:  ret void
Index: clang/lib/CodeGen/CGExprConstant.cpp
===
--- clang/lib/CodeGen/CGExprConstant.cpp
+++ clang/lib/CodeGen/CGExprConstant.cpp
@@ -1092,7 +1092,16 @@
  destAS, destTy);
 }
 
-case CK_LValueToRValue:
+case CK_LValueToRValue: {
+  // We don't really support doing lvalue-to-rvalue conversions here; any
+  // interesting conversions should be done in Evaluate().  But as a
+  // special case, allow compound literals to support the gcc extension
+  // allowing "struct x {int x;} x = (struct x) {};".
+  if (auto *E = dyn_cast(subExpr->IgnoreParens()))
+return Visit(E->getInitializer(), destType);
+  return nullptr;
+}
+
 case CK_AtomicToNonAtomic:
 case CK_NonAtomicToAtomic:
 case CK_NoOp:


Index: clang/test/CodeGenCXX/cxx20-consteval-crash.cpp
===
--- clang/test/CodeGenCXX/cxx20-consteval-crash.cpp
+++ clang/test/CodeGenCXX/cxx20-consteval-crash.cpp
@@ -9,7 +9,7 @@
 
 // CHECK: @_ZN7PR507872x_E = external global i32, align 4
 // CHECK-NEXT: @_ZN7PR507872x1E = constant i32* @_ZN7PR507872x_E, align 8
-// CHECK-NEXT: @_ZN7PR507872x2E = global i32* @_ZN7PR507872x_E, align 4
+// CHECK-NEXT: @_ZN7PR507872x2E = global i32 0, align 4
 }
 
 namespace PR51484 {
@@ -18,7 +18,7 @@
 consteval X g() { return {0}; }
 void f() { g(); }
 
-// CHECK: define dso_local void @_ZN7PR514841fEv() #0 {
+// CHECK: define dso_local void @_ZN7PR514841fEv() #1 {
 // CHECK: entry:
 // CHECK-NOT: call i32 @_ZN7PR514841gEv()
 // CHECK:  ret void
Index: clang/lib/CodeGen/CGExprConstant.cpp
===
--- clang/lib/CodeGen/CGExprConstant.cpp
+++ clang/lib/CodeGen/CGExprConstant.cpp
@@ -1092,7 +1092,16 @@
  destAS, destTy);
 }
 
-case CK_LValueToRValue:
+case CK_LValueToRValue: {
+  // We don't really support doing lvalue-to-rvalue conversions here; any
+  // interesting conversions should be done in Evaluate().  But as a
+  // special case, allow compound literals to support the gcc extension
+  // allowing "struct x {int x;} x = (struct x) {};".
+  if (auto *E = dyn_cast(subExpr->IgnoreParens()))
+return Visit(E->getInitializer(), destType);
+  return nullptr;
+}
+
 case CK_AtomicToNonAtomic:
 case CK_NonAtomicToAtomic:
 case CK_NoOp:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D123345: Treat `std::move`, `forward`, and `move_if_noexcept` as builtins.

2022-04-12 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith updated this revision to Diff 422366.
rsmith added a comment.

- Switch to a different example with underscores.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123345

Files:
  clang/docs/CommandGuide/clang.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Basic/Builtins.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/AST/ExprConstant.cpp
  clang/lib/Analysis/BodyFarm.cpp
  clang/lib/Basic/Builtins.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaInit.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/test/Analysis/use-after-move.cpp
  clang/test/CodeGenCXX/builtin-std-move.cpp
  clang/test/CodeGenCXX/microsoft-abi-throw.cpp
  clang/test/SemaCXX/builtin-std-move-nobuiltin.cpp
  clang/test/SemaCXX/builtin-std-move.cpp
  clang/test/SemaCXX/unqualified-std-call-fixits.cpp
  clang/test/SemaCXX/unqualified-std-call.cpp
  clang/test/SemaCXX/warn-consumed-analysis.cpp

Index: clang/test/SemaCXX/warn-consumed-analysis.cpp
===
--- clang/test/SemaCXX/warn-consumed-analysis.cpp
+++ clang/test/SemaCXX/warn-consumed-analysis.cpp
@@ -953,12 +953,12 @@
 namespace std {
   void move();
   template
-  void move(T&&);
+  T &&move(T&);
 
   namespace __1 {
 void move();
 template
-void move(T&&);
+T &&move(T&);
   }
 }
 
@@ -971,7 +971,7 @@
   void test() {
 x.move();
 std::move();
-std::move(x);
+std::move(x); // expected-warning {{ignoring return value}}
 std::__1::move();
 std::__1::move(x);
   }
Index: clang/test/SemaCXX/unqualified-std-call.cpp
===
--- clang/test/SemaCXX/unqualified-std-call.cpp
+++ clang/test/SemaCXX/unqualified-std-call.cpp
@@ -1,17 +1,17 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -Wall -std=c++11 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -Wall -std=c++11 %s -Wno-unused-value
 
 namespace std {
 
 template 
 void dummy(T &&) {}
 template 
-void move(T &&) {}
+T &&move(T &&x) { return x; }
 template 
 void move(T &&, U &&) {}
 
 inline namespace __1 {
 template 
-void forward(T &) {}
+T &forward(T &x) { return x; }
 } // namespace __1
 
 struct foo {};
Index: clang/test/SemaCXX/unqualified-std-call-fixits.cpp
===
--- clang/test/SemaCXX/unqualified-std-call-fixits.cpp
+++ clang/test/SemaCXX/unqualified-std-call-fixits.cpp
@@ -6,9 +6,9 @@
 
 namespace std {
 
-void move(auto &&a) {}
+int &&move(auto &&a) { return a; }
 
-void forward(auto &a) {}
+int &&forward(auto &a) { return a; }
 
 } // namespace std
 
@@ -16,8 +16,8 @@
 
 void f() {
   int i = 0;
-  move(i); // expected-warning {{unqualified call to std::move}}
-  // CHECK: {{^}}  std::
-  forward(i); // expected-warning {{unqualified call to std::forward}}
-  // CHECK: {{^}}  std::
+  (void)move(i); // expected-warning {{unqualified call to std::move}}
+  // CHECK: {{^}}  (void)std::move
+  (void)forward(i); // expected-warning {{unqualified call to std::forward}}
+  // CHECK: {{^}}  (void)std::forward
 }
Index: clang/test/SemaCXX/builtin-std-move.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/builtin-std-move.cpp
@@ -0,0 +1,90 @@
+// RUN: %clang_cc1 -std=c++17 -verify %s
+// RUN: %clang_cc1 -std=c++17 -verify %s -DNO_CONSTEXPR
+// RUN: %clang_cc1 -std=c++20 -verify %s
+
+namespace std {
+#ifndef NO_CONSTEXPR
+#define CONSTEXPR constexpr
+#else
+#define CONSTEXPR
+#endif
+
+  template CONSTEXPR T &&move(T &x) {
+static_assert(T::moveable, "instantiated move"); // expected-error {{no member named 'moveable' in 'B'}}
+ // expected-error@-1 {{no member named 'moveable' in 'C'}}
+return static_cast(x);
+  }
+
+  // Unrelated move functions are not the builtin.
+  template CONSTEXPR int move(T, T) { return 5; }
+
+  template struct ref { using type = T&; };
+  template struct ref { using type = T&&; };
+
+  template CONSTEXPR auto move_if_noexcept(T &x) -> typename ref(x)))>::type {
+static_assert(T::moveable, "instantiated move_if_noexcept"); // expected-error {{no member named 'moveable' in 'B'}}
+return static_cast(x)))>::type>(x);
+  }
+
+  template struct remove_reference { using type = T; };
+  template struct remove_reference { using type = T; };
+  template struct remove_reference { using type = T; };
+
+  template CONSTEXPR T &&forward(typename remove_reference::type &x) {
+static_assert(T::moveable, "instantiated forward"); // expected-error {{no member named 'moveable' in 'B'}}
+ 

[PATCH] D122865: [HLSL][clang][Driver] Support target profile command line option.

2022-04-12 Thread Xiang Li via Phabricator via cfe-commits
python3kgae updated this revision to Diff 422365.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122865

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Driver.h
  clang/include/clang/Driver/Options.h
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/CMakeLists.txt
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/HLSL.cpp
  clang/lib/Driver/ToolChains/HLSL.h
  clang/lib/Driver/Types.cpp
  clang/test/lit.cfg.py
  clang/unittests/Driver/ToolChainTest.cpp

Index: clang/unittests/Driver/ToolChainTest.cpp
===
--- clang/unittests/Driver/ToolChainTest.cpp
+++ clang/unittests/Driver/ToolChainTest.cpp
@@ -300,6 +300,12 @@
   EXPECT_TRUE(Res.ModeSuffix == "clang-cl");
   EXPECT_STREQ(Res.DriverMode, "--driver-mode=cl");
   EXPECT_FALSE(Res.TargetIsValid);
+
+  Res = ToolChain::getTargetAndModeFromProgramName("clang-dxc");
+  EXPECT_TRUE(Res.TargetPrefix.empty());
+  EXPECT_TRUE(Res.ModeSuffix == "clang-dxc");
+  EXPECT_STREQ(Res.DriverMode, "--driver-mode=dxc");
+  EXPECT_FALSE(Res.TargetIsValid);
 }
 
 TEST(ToolChainTest, CommandOutput) {
@@ -361,4 +367,141 @@
   EXPECT_EQ(getDriverMode(Args[0], llvm::makeArrayRef(Args).slice(1)), "bar");
 }
 
+TEST(DxcModeTest, TargetProfileValidation) {
+  IntrusiveRefCntPtr DiagID(new DiagnosticIDs());
+  struct SimpleDiagnosticConsumer : public DiagnosticConsumer {
+void HandleDiagnostic(DiagnosticsEngine::Level DiagLevel,
+  const Diagnostic &Info) override {
+  if (DiagLevel == DiagnosticsEngine::Level::Error) {
+Errors.emplace_back();
+Info.FormatDiagnostic(Errors.back());
+  } else {
+Msgs.emplace_back();
+Info.FormatDiagnostic(Msgs.back());
+  }
+}
+void clear() override {
+  Msgs.clear();
+  Errors.clear();
+  DiagnosticConsumer::clear();
+}
+std::vector> Msgs;
+std::vector> Errors;
+  };
+
+  IntrusiveRefCntPtr InMemoryFileSystem(
+  new llvm::vfs::InMemoryFileSystem);
+
+  InMemoryFileSystem->addFile("foo.hlsl", 0,
+  llvm::MemoryBuffer::getMemBuffer("\n"));
+
+  auto *DiagConsumer = new SimpleDiagnosticConsumer;
+  IntrusiveRefCntPtr DiagOpts = new DiagnosticOptions();
+  DiagnosticsEngine Diags(DiagID, &*DiagOpts, DiagConsumer);
+  Driver TheDriver("/bin/clang", "", Diags, "", InMemoryFileSystem);
+  std::unique_ptr C(
+  TheDriver.BuildCompilation({"clang", "--driver-mode=dxc", "foo.hlsl"}));
+  EXPECT_TRUE(C);
+  EXPECT_TRUE(!C->containsError());
+
+  auto &TC = C->getDefaultToolChain();
+  bool ContainsError = false;
+  auto Args = TheDriver.ParseArgStrings({"-Tvs_6_0"}, false, ContainsError);
+  EXPECT_FALSE(ContainsError);
+  auto Triple = TC.ComputeEffectiveClangTriple(Args);
+  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.0-vertex");
+  EXPECT_EQ(Diags.getNumErrors(), 0);
+
+  Args = TheDriver.ParseArgStrings({"-Ths_6_1"}, false, ContainsError);
+  EXPECT_FALSE(ContainsError);
+  Triple = TC.ComputeEffectiveClangTriple(Args);
+  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.1-hull");
+  EXPECT_EQ(Diags.getNumErrors(), 0);
+
+  Args = TheDriver.ParseArgStrings({"-Tds_6_2"}, false, ContainsError);
+  EXPECT_FALSE(ContainsError);
+  Triple = TC.ComputeEffectiveClangTriple(Args);
+  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.2-domain");
+  EXPECT_EQ(Diags.getNumErrors(), 0);
+
+  Args = TheDriver.ParseArgStrings({"-Tds_6_2"}, false, ContainsError);
+  EXPECT_FALSE(ContainsError);
+  Triple = TC.ComputeEffectiveClangTriple(Args);
+  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.2-domain");
+  EXPECT_EQ(Diags.getNumErrors(), 0);
+
+  Args = TheDriver.ParseArgStrings({"-Tgs_6_3"}, false, ContainsError);
+  EXPECT_FALSE(ContainsError);
+  Triple = TC.ComputeEffectiveClangTriple(Args);
+  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.3-geometry");
+  EXPECT_EQ(Diags.getNumErrors(), 0);
+
+  Args = TheDriver.ParseArgStrings({"-Tps_6_4"}, false, ContainsError);
+  EXPECT_FALSE(ContainsError);
+  Triple = TC.ComputeEffectiveClangTriple(Args);
+  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.4-pixel");
+  EXPECT_EQ(Diags.getNumErrors(), 0);
+
+  Args = TheDriver.ParseArgStrings({"-Tcs_6_5"}, false, ContainsError);
+  EXPECT_FALSE(ContainsError);
+  Triple = TC.ComputeEffectiveClangTriple(Args);
+  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.5-compute");
+  EXPECT_EQ(Diags.getNumErrors(), 0);
+
+  Args = TheDriver.ParseArgStrings({"-Tms_6_6"}, false, ContainsError);
+  EXPECT_FALSE(ContainsError);
+  Triple = TC.ComputeEffectiveClangTriple(Args);
+  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.6-mesh");
+  EXPECT_EQ(Diags.getNumErrors(), 0);
+
+  Args = TheDriver.ParseArgStrings({"-Tas_6_7"}, false, ContainsError);
+  EXPECT_FALSE(ContainsError);
+  Triple = TC.Comput

[PATCH] D123586: [clang][dataflow] Weaken abstract comparison to enable loop termination.

2022-04-12 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun accepted this revision.
xazax.hun added a comment.
This revision is now accepted and ready to land.

Yeah, this is a hard problem in general. This looks like a sensible workaround 
for the short term, but I'm looking forward to a better solution. I'm a bit 
worried that the memory model will need some upgrades to properly solve this 
problem.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123586

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


[PATCH] D123642: [clang codegen] Assume arguments of __atomic_* are aligned.

2022-04-12 Thread Eli Friedman via Phabricator via cfe-commits
efriedma created this revision.
efriedma added reviewers: jyknight, craig.topper, jfb, rjmccall.
Herald added a subscriber: StephenFan.
Herald added a project: All.
efriedma requested review of this revision.
Herald added a project: clang.

This seems weird, but it's necessary to match gcc, and avoid unnecessary calls 
to libatomic from libstdc++ .

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


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D123642

Files:
  clang/lib/CodeGen/CGAtomic.cpp
  clang/test/CodeGen/atomic-ops.c
  clang/test/CodeGen/atomics-sema-alignment.c

Index: clang/test/CodeGen/atomics-sema-alignment.c
===
--- clang/test/CodeGen/atomics-sema-alignment.c
+++ clang/test/CodeGen/atomics-sema-alignment.c
@@ -12,10 +12,10 @@
 
 void func(IntPair *p) {
   IntPair res;
-  __atomic_load(p, &res, 0);// expected-warning {{misaligned atomic operation may incur significant performance penalty; the expected alignment (8 bytes) exceeds the actual alignment (4 bytes)}}
-  __atomic_store(p, &res, 0);   // expected-warning {{misaligned atomic operation may incur significant performance penalty; the expected alignment (8 bytes) exceeds the actual alignment (4 bytes)}}
-  __atomic_fetch_add((unaligned_int *)p, 1, 2); // expected-warning {{misaligned atomic operation may incur significant performance penalty; the expected alignment (4 bytes) exceeds the actual alignment (1 bytes)}}
-  __atomic_fetch_sub((unaligned_int *)p, 1, 3); // expected-warning {{misaligned atomic operation may incur significant performance penalty; the expected alignment (4 bytes) exceeds the actual alignment (1 bytes)}}
+  __atomic_load(p, &res, 0);
+  __atomic_store(p, &res, 0);
+  __atomic_fetch_add((unaligned_int *)p, 1, 2);
+  __atomic_fetch_sub((unaligned_int *)p, 1, 3);
 }
 
 void func1(LongStruct *p) {
@@ -40,7 +40,7 @@
 
 void braz(Foo *foo, ThirtyTwo *braz) {
   Foo bar;
-  __atomic_load(foo, &bar, __ATOMIC_RELAXED); // expected-warning {{misaligned atomic operation may incur significant performance penalty; the expected alignment (16 bytes) exceeds the actual alignment (8 bytes)}}
+  __atomic_load(foo, &bar, __ATOMIC_RELAXED);
 
   ThirtyTwo thirtyTwo1;
   ThirtyTwo thirtyTwo2;
Index: clang/test/CodeGen/atomic-ops.c
===
--- clang/test/CodeGen/atomic-ops.c
+++ clang/test/CodeGen/atomic-ops.c
@@ -200,9 +200,8 @@
   // CHECK: [[RETVAL:%.*]] = alloca %struct.S, align 4
   // CHECK: [[A:%.*]]   = bitcast %struct.S* {{.*}} to i64*
   // CHECK: [[CAST:%.*]]  = bitcast %struct.S* [[RETVAL]] to i64*
-  // CHECK: [[SRC:%.*]]  = bitcast i64* [[A]] to i8*
-  // CHECK: [[DEST:%.*]]  = bitcast i64* [[CAST]] to i8*
-  // CHECK: call void @__atomic_load(i32 noundef 8, i8* noundef [[SRC]], i8* noundef [[DEST]], i32 noundef 5)
+  // CHECK: load atomic i64, i64* [[A]]
+  // CHECK: store i64 {{.*}}, i64* [[CAST]]
   // CHECK: ret
   struct S ret;
   __atomic_load(a, &ret, memory_order_seq_cst);
@@ -219,9 +218,8 @@
   // CHECK-NEXT: [[LOAD_B_PTR:%.*]] = load %struct.S*, %struct.S** [[B_ADDR]], align 4
   // CHECK-NEXT: [[COERCED_A_TMP:%.*]] = bitcast %struct.S* [[LOAD_A_PTR]] to i64*
   // CHECK-NEXT: [[COERCED_B:%.*]] = bitcast %struct.S* [[LOAD_B_PTR]] to i64*
-  // CHECK-NEXT: [[COERCED_A:%.*]] = bitcast i64* [[COERCED_A_TMP]] to i8*
-  // CHECK-NEXT: [[CAST_B:%.*]] = bitcast i64* [[COERCED_B]] to i8*
-  // CHECK-NEXT: call void @__atomic_store(i32 noundef 8, i8* noundef [[COERCED_A]], i8* noundef [[CAST_B]],
+  // CHECK-NEXT: load i64, i64* [[COERCED_B]]
+  // CHECK-NEXT: store atomic i64 {{.*}}, i64* [[COERCED_A_TMP]]
   // CHECK-NEXT: ret void
   __atomic_store(a, b, memory_order_seq_cst);
 }
@@ -240,11 +238,8 @@
   // CHECK-NEXT: [[COERCED_A_TMP:%.*]] = bitcast %struct.S* [[LOAD_A_PTR]] to i64*
   // CHECK-NEXT: [[COERCED_B:%.*]] = bitcast %struct.S* [[LOAD_B_PTR]] to i64*
   // CHECK-NEXT: [[COERCED_C:%.*]] = bitcast %struct.S* [[LOAD_C_PTR]] to i64*
-  // CHECK-NEXT: [[COERCED_A:%.*]] = bitcast i64* [[COERCED_A_TMP]] to i8*
-  // CHECK-NEXT: [[CAST_B:%.*]] = bitcast i64* [[COERCED_B]] to i8*
-  // CHECK-NEXT: [[CAST_C:%.*]] = bitcast i64* [[COERCED_C]] to i8*
-  // CHECK-NEXT: call void @__atomic_exchange(i32 noundef 8, i8* noundef [[COERCED_A]], i8* noundef [[CAST_B]], i8* noundef [[CAST_C]],
-
+  // CHECK-NEXT: load i64, i64* [[COERCED_B]]
+  // CHECK-NEXT: atomicrmw xchg i64* [[COERCED_A_TMP]]
   __atomic_exchange(a, b, c, memory_order_seq_cst);
 }
 
@@ -262,11 +257,9 @@
   // CHECK-NEXT: [[COERCED_A_TMP:%.*]] = bitcast %struct.S* [[LOAD_A_PTR]] to i64*
   // CHECK-NEXT: [[COERCED_B_TMP:%.*]] = bitcast %struct.S* [[LOAD_B_PTR]] to i64*
   // CHECK-NEXT: [[COERCED_C:%.*]] = bitcast %struct.S* [[LOAD_C_PTR]] to i64*
-  // CHECK-NEXT: [[COERCED_A:%.*]] = bitcast i64* [[COERCED_A_TMP]] to i8*
-  // CHECK-NEXT: [[COERCED_B:%.*]] = bitcast i64* [[COE

[clang] 0cde8bd - Revert "[clang-format] Allow empty .clang-format file"

2022-04-12 Thread via cfe-commits

Author: owenca
Date: 2022-04-12T16:05:39-07:00
New Revision: 0cde8bdb0bd0d2e681be43e8a4057138048eb421

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

LOG: Revert "[clang-format] Allow empty .clang-format file"

This reverts commit 4e814a6f2db90046914734fac4f9e3110c7e0424.

Added: 


Modified: 
clang/lib/Format/Format.cpp
clang/test/Format/style-on-command-line.cpp

Removed: 




diff  --git a/clang/lib/Format/Format.cpp b/clang/lib/Format/Format.cpp
index bce66d117dbd1..0bbd54353d7b8 100644
--- a/clang/lib/Format/Format.cpp
+++ b/clang/lib/Format/Format.cpp
@@ -1722,7 +1722,7 @@ std::error_code parseConfiguration(llvm::MemoryBufferRef 
Config,
   FormatStyle::LanguageKind Language = Style->Language;
   assert(Language != FormatStyle::LK_None);
   if (Config.getBuffer().trim().empty())
-return make_error_code(ParseError::Success);
+return make_error_code(ParseError::Error);
   Style->StyleSet.Clear();
   std::vector Styles;
   llvm::yaml::Input Input(Config, /*Ctxt=*/nullptr, DiagHandler,

diff  --git a/clang/test/Format/style-on-command-line.cpp 
b/clang/test/Format/style-on-command-line.cpp
index 7d5c7f4cbe562..3fd89f587dc6f 100644
--- a/clang/test/Format/style-on-command-line.cpp
+++ b/clang/test/Format/style-on-command-line.cpp
@@ -6,7 +6,7 @@
 // RUN: printf "BasedOnStyle: google\nIndentWidth: 5\n" > %t/.clang-format
 // RUN: clang-format -style=file -assume-filename=%t/foo.cpp < %s | FileCheck 
-strict-whitespace -check-prefix=CHECK5 %s
 // RUN: printf "\n" > %t/.clang-format
-// RUN: clang-format -style=file -fallback-style=webkit 
-assume-filename=%t/foo.cpp < %s 2>&1 | FileCheck -strict-whitespace 
-check-prefix=CHECK6 %s
+// RUN: not clang-format -style=file -fallback-style=webkit 
-assume-filename=%t/foo.cpp < %s 2>&1 | FileCheck -strict-whitespace 
-check-prefix=CHECK6 %s
 // RUN: rm %t/.clang-format
 // RUN: printf "BasedOnStyle: google\nIndentWidth: 6\n" > %t/_clang-format
 // RUN: clang-format -style=file -assume-filename=%t/foo.cpp < %s | FileCheck 
-strict-whitespace -check-prefix=CHECK7 %s



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


[PATCH] D122865: [HLSL][clang][Driver] Support target profile command line option.

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



Comment at: clang/lib/Driver/Driver.cpp:1196
+
+  if (IsDXCMode()) {
+// clang-dxc target is build from target_profile option.

nit: this can be an `else` for the `if` above



Comment at: clang/lib/Driver/ToolChains/HLSL.cpp:39
+
+  VersionTuple MaxVer(6, MaxShaderModel6Minor);
+  switch (Kind) {

I don't think there is a good reason to verify max versions in the compiler.

This kind of code just makes more places we have to update when things move 
forward.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122865

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


[PATCH] D122865: [HLSL][clang][Driver] Support target profile command line option.

2022-04-12 Thread Xiang Li via Phabricator via cfe-commits
python3kgae updated this revision to Diff 422350.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122865

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Driver.h
  clang/include/clang/Driver/Options.h
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/CMakeLists.txt
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/HLSL.cpp
  clang/lib/Driver/ToolChains/HLSL.h
  clang/lib/Driver/Types.cpp
  clang/test/lit.cfg.py
  clang/unittests/Driver/ToolChainTest.cpp

Index: clang/unittests/Driver/ToolChainTest.cpp
===
--- clang/unittests/Driver/ToolChainTest.cpp
+++ clang/unittests/Driver/ToolChainTest.cpp
@@ -300,6 +300,12 @@
   EXPECT_TRUE(Res.ModeSuffix == "clang-cl");
   EXPECT_STREQ(Res.DriverMode, "--driver-mode=cl");
   EXPECT_FALSE(Res.TargetIsValid);
+
+  Res = ToolChain::getTargetAndModeFromProgramName("clang-dxc");
+  EXPECT_TRUE(Res.TargetPrefix.empty());
+  EXPECT_TRUE(Res.ModeSuffix == "clang-dxc");
+  EXPECT_STREQ(Res.DriverMode, "--driver-mode=dxc");
+  EXPECT_FALSE(Res.TargetIsValid);
 }
 
 TEST(ToolChainTest, CommandOutput) {
@@ -361,4 +367,141 @@
   EXPECT_EQ(getDriverMode(Args[0], llvm::makeArrayRef(Args).slice(1)), "bar");
 }
 
+TEST(DxcModeTest, TargetProfileValidation) {
+  IntrusiveRefCntPtr DiagID(new DiagnosticIDs());
+  struct SimpleDiagnosticConsumer : public DiagnosticConsumer {
+void HandleDiagnostic(DiagnosticsEngine::Level DiagLevel,
+  const Diagnostic &Info) override {
+  if (DiagLevel == DiagnosticsEngine::Level::Error) {
+Errors.emplace_back();
+Info.FormatDiagnostic(Errors.back());
+  } else {
+Msgs.emplace_back();
+Info.FormatDiagnostic(Msgs.back());
+  }
+}
+void clear() override {
+  Msgs.clear();
+  Errors.clear();
+  DiagnosticConsumer::clear();
+}
+std::vector> Msgs;
+std::vector> Errors;
+  };
+
+  IntrusiveRefCntPtr InMemoryFileSystem(
+  new llvm::vfs::InMemoryFileSystem);
+
+  InMemoryFileSystem->addFile("foo.hlsl", 0,
+  llvm::MemoryBuffer::getMemBuffer("\n"));
+
+  auto *DiagConsumer = new SimpleDiagnosticConsumer;
+  IntrusiveRefCntPtr DiagOpts = new DiagnosticOptions();
+  DiagnosticsEngine Diags(DiagID, &*DiagOpts, DiagConsumer);
+  Driver TheDriver("/bin/clang", "", Diags, "", InMemoryFileSystem);
+  std::unique_ptr C(
+  TheDriver.BuildCompilation({"clang", "--driver-mode=dxc", "foo.hlsl"}));
+  EXPECT_TRUE(C);
+  EXPECT_TRUE(!C->containsError());
+
+  auto &TC = C->getDefaultToolChain();
+  bool ContainsError = false;
+  auto Args = TheDriver.ParseArgStrings({"-Tvs_6_0"}, false, ContainsError);
+  EXPECT_FALSE(ContainsError);
+  auto Triple = TC.ComputeEffectiveClangTriple(Args);
+  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.0-vertex");
+  EXPECT_EQ(Diags.getNumErrors(), 0);
+
+  Args = TheDriver.ParseArgStrings({"-Ths_6_1"}, false, ContainsError);
+  EXPECT_FALSE(ContainsError);
+  Triple = TC.ComputeEffectiveClangTriple(Args);
+  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.1-hull");
+  EXPECT_EQ(Diags.getNumErrors(), 0);
+
+  Args = TheDriver.ParseArgStrings({"-Tds_6_2"}, false, ContainsError);
+  EXPECT_FALSE(ContainsError);
+  Triple = TC.ComputeEffectiveClangTriple(Args);
+  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.2-domain");
+  EXPECT_EQ(Diags.getNumErrors(), 0);
+
+  Args = TheDriver.ParseArgStrings({"-Tds_6_2"}, false, ContainsError);
+  EXPECT_FALSE(ContainsError);
+  Triple = TC.ComputeEffectiveClangTriple(Args);
+  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.2-domain");
+  EXPECT_EQ(Diags.getNumErrors(), 0);
+
+  Args = TheDriver.ParseArgStrings({"-Tgs_6_3"}, false, ContainsError);
+  EXPECT_FALSE(ContainsError);
+  Triple = TC.ComputeEffectiveClangTriple(Args);
+  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.3-geometry");
+  EXPECT_EQ(Diags.getNumErrors(), 0);
+
+  Args = TheDriver.ParseArgStrings({"-Tps_6_4"}, false, ContainsError);
+  EXPECT_FALSE(ContainsError);
+  Triple = TC.ComputeEffectiveClangTriple(Args);
+  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.4-pixel");
+  EXPECT_EQ(Diags.getNumErrors(), 0);
+
+  Args = TheDriver.ParseArgStrings({"-Tcs_6_5"}, false, ContainsError);
+  EXPECT_FALSE(ContainsError);
+  Triple = TC.ComputeEffectiveClangTriple(Args);
+  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.5-compute");
+  EXPECT_EQ(Diags.getNumErrors(), 0);
+
+  Args = TheDriver.ParseArgStrings({"-Tms_6_6"}, false, ContainsError);
+  EXPECT_FALSE(ContainsError);
+  Triple = TC.ComputeEffectiveClangTriple(Args);
+  EXPECT_STREQ(Triple.c_str(), "dxil--shadermodel6.6-mesh");
+  EXPECT_EQ(Diags.getNumErrors(), 0);
+
+  Args = TheDriver.ParseArgStrings({"-Tas_6_7"}, false, ContainsError);
+  EXPECT_FALSE(ContainsError);
+  Triple = TC.Comput

[PATCH] D123640: Make comment consistent with allow|ignore list renamings

2022-04-12 Thread Aditya Kumar via Phabricator via cfe-commits
hiraditya created this revision.
hiraditya added a reviewer: thakis.
Herald added a project: All.
hiraditya requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D123640

Files:
  clang/lib/Driver/SanitizerArgs.cpp


Index: clang/lib/Driver/SanitizerArgs.cpp
===
--- clang/lib/Driver/SanitizerArgs.cpp
+++ clang/lib/Driver/SanitizerArgs.cpp
@@ -175,7 +175,7 @@
   DiagnoseErrors);
 }
 
-/// Parse -f(no-)?sanitize-(coverage-)?(white|ignore)list argument's values,
+/// Parse -f(no-)?sanitize-(coverage-)?(allow|ignore)list argument's values,
 /// diagnosing any invalid file paths and validating special case list format.
 static void parseSpecialCaseListArg(const Driver &D,
 const llvm::opt::ArgList &Args,
@@ -185,7 +185,7 @@
 unsigned MalformedSCLErrorDiagID,
 bool DiagnoseErrors) {
   for (const auto *Arg : Args) {
-// Match -fsanitize-(coverage-)?(white|ignore)list.
+// Match -fsanitize-(coverage-)?(allow|ignore)list.
 if (Arg->getOption().matches(SCLOptionID)) {
   Arg->claim();
   std::string SCLPath = Arg->getValue();
@@ -788,7 +788,7 @@
   CoverageFeatures |= CoverageFunc;
   }
 
-  // Parse -fsanitize-coverage-(ignore|white)list options if coverage enabled.
+  // Parse -fsanitize-coverage-(allow|ignore)list options if coverage enabled.
   // This also validates special case lists format.
   // Here, OptSpecifier() acts as a never-matching command-line argument.
   // So, there is no way to clear coverage lists but you can append to them.


Index: clang/lib/Driver/SanitizerArgs.cpp
===
--- clang/lib/Driver/SanitizerArgs.cpp
+++ clang/lib/Driver/SanitizerArgs.cpp
@@ -175,7 +175,7 @@
   DiagnoseErrors);
 }
 
-/// Parse -f(no-)?sanitize-(coverage-)?(white|ignore)list argument's values,
+/// Parse -f(no-)?sanitize-(coverage-)?(allow|ignore)list argument's values,
 /// diagnosing any invalid file paths and validating special case list format.
 static void parseSpecialCaseListArg(const Driver &D,
 const llvm::opt::ArgList &Args,
@@ -185,7 +185,7 @@
 unsigned MalformedSCLErrorDiagID,
 bool DiagnoseErrors) {
   for (const auto *Arg : Args) {
-// Match -fsanitize-(coverage-)?(white|ignore)list.
+// Match -fsanitize-(coverage-)?(allow|ignore)list.
 if (Arg->getOption().matches(SCLOptionID)) {
   Arg->claim();
   std::string SCLPath = Arg->getValue();
@@ -788,7 +788,7 @@
   CoverageFeatures |= CoverageFunc;
   }
 
-  // Parse -fsanitize-coverage-(ignore|white)list options if coverage enabled.
+  // Parse -fsanitize-coverage-(allow|ignore)list options if coverage enabled.
   // This also validates special case lists format.
   // Here, OptSpecifier() acts as a never-matching command-line argument.
   // So, there is no way to clear coverage lists but you can append to them.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D123535: [clang-format] Allow empty .clang-format file

2022-04-12 Thread Owen Pan via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG4e814a6f2db9: [clang-format] Allow empty .clang-format file 
(authored by owenpan).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123535

Files:
  clang/lib/Format/Format.cpp
  clang/test/Format/style-on-command-line.cpp


Index: clang/test/Format/style-on-command-line.cpp
===
--- clang/test/Format/style-on-command-line.cpp
+++ clang/test/Format/style-on-command-line.cpp
@@ -6,7 +6,7 @@
 // RUN: printf "BasedOnStyle: google\nIndentWidth: 5\n" > %t/.clang-format
 // RUN: clang-format -style=file -assume-filename=%t/foo.cpp < %s | FileCheck 
-strict-whitespace -check-prefix=CHECK5 %s
 // RUN: printf "\n" > %t/.clang-format
-// RUN: not clang-format -style=file -fallback-style=webkit 
-assume-filename=%t/foo.cpp < %s 2>&1 | FileCheck -strict-whitespace 
-check-prefix=CHECK6 %s
+// RUN: clang-format -style=file -fallback-style=webkit 
-assume-filename=%t/foo.cpp < %s 2>&1 | FileCheck -strict-whitespace 
-check-prefix=CHECK6 %s
 // RUN: rm %t/.clang-format
 // RUN: printf "BasedOnStyle: google\nIndentWidth: 6\n" > %t/_clang-format
 // RUN: clang-format -style=file -assume-filename=%t/foo.cpp < %s | FileCheck 
-strict-whitespace -check-prefix=CHECK7 %s
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -1722,7 +1722,7 @@
   FormatStyle::LanguageKind Language = Style->Language;
   assert(Language != FormatStyle::LK_None);
   if (Config.getBuffer().trim().empty())
-return make_error_code(ParseError::Error);
+return make_error_code(ParseError::Success);
   Style->StyleSet.Clear();
   std::vector Styles;
   llvm::yaml::Input Input(Config, /*Ctxt=*/nullptr, DiagHandler,


Index: clang/test/Format/style-on-command-line.cpp
===
--- clang/test/Format/style-on-command-line.cpp
+++ clang/test/Format/style-on-command-line.cpp
@@ -6,7 +6,7 @@
 // RUN: printf "BasedOnStyle: google\nIndentWidth: 5\n" > %t/.clang-format
 // RUN: clang-format -style=file -assume-filename=%t/foo.cpp < %s | FileCheck -strict-whitespace -check-prefix=CHECK5 %s
 // RUN: printf "\n" > %t/.clang-format
-// RUN: not clang-format -style=file -fallback-style=webkit -assume-filename=%t/foo.cpp < %s 2>&1 | FileCheck -strict-whitespace -check-prefix=CHECK6 %s
+// RUN: clang-format -style=file -fallback-style=webkit -assume-filename=%t/foo.cpp < %s 2>&1 | FileCheck -strict-whitespace -check-prefix=CHECK6 %s
 // RUN: rm %t/.clang-format
 // RUN: printf "BasedOnStyle: google\nIndentWidth: 6\n" > %t/_clang-format
 // RUN: clang-format -style=file -assume-filename=%t/foo.cpp < %s | FileCheck -strict-whitespace -check-prefix=CHECK7 %s
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -1722,7 +1722,7 @@
   FormatStyle::LanguageKind Language = Style->Language;
   assert(Language != FormatStyle::LK_None);
   if (Config.getBuffer().trim().empty())
-return make_error_code(ParseError::Error);
+return make_error_code(ParseError::Success);
   Style->StyleSet.Clear();
   std::vector Styles;
   llvm::yaml::Input Input(Config, /*Ctxt=*/nullptr, DiagHandler,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 4e814a6 - [clang-format] Allow empty .clang-format file

2022-04-12 Thread via cfe-commits

Author: owenca
Date: 2022-04-12T15:45:22-07:00
New Revision: 4e814a6f2db90046914734fac4f9e3110c7e0424

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

LOG: [clang-format] Allow empty .clang-format file

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

Added: 


Modified: 
clang/lib/Format/Format.cpp
clang/test/Format/style-on-command-line.cpp

Removed: 




diff  --git a/clang/lib/Format/Format.cpp b/clang/lib/Format/Format.cpp
index 0bbd54353d7b8..bce66d117dbd1 100644
--- a/clang/lib/Format/Format.cpp
+++ b/clang/lib/Format/Format.cpp
@@ -1722,7 +1722,7 @@ std::error_code parseConfiguration(llvm::MemoryBufferRef 
Config,
   FormatStyle::LanguageKind Language = Style->Language;
   assert(Language != FormatStyle::LK_None);
   if (Config.getBuffer().trim().empty())
-return make_error_code(ParseError::Error);
+return make_error_code(ParseError::Success);
   Style->StyleSet.Clear();
   std::vector Styles;
   llvm::yaml::Input Input(Config, /*Ctxt=*/nullptr, DiagHandler,

diff  --git a/clang/test/Format/style-on-command-line.cpp 
b/clang/test/Format/style-on-command-line.cpp
index 3fd89f587dc6f..7d5c7f4cbe562 100644
--- a/clang/test/Format/style-on-command-line.cpp
+++ b/clang/test/Format/style-on-command-line.cpp
@@ -6,7 +6,7 @@
 // RUN: printf "BasedOnStyle: google\nIndentWidth: 5\n" > %t/.clang-format
 // RUN: clang-format -style=file -assume-filename=%t/foo.cpp < %s | FileCheck 
-strict-whitespace -check-prefix=CHECK5 %s
 // RUN: printf "\n" > %t/.clang-format
-// RUN: not clang-format -style=file -fallback-style=webkit 
-assume-filename=%t/foo.cpp < %s 2>&1 | FileCheck -strict-whitespace 
-check-prefix=CHECK6 %s
+// RUN: clang-format -style=file -fallback-style=webkit 
-assume-filename=%t/foo.cpp < %s 2>&1 | FileCheck -strict-whitespace 
-check-prefix=CHECK6 %s
 // RUN: rm %t/.clang-format
 // RUN: printf "BasedOnStyle: google\nIndentWidth: 6\n" > %t/_clang-format
 // RUN: clang-format -style=file -assume-filename=%t/foo.cpp < %s | FileCheck 
-strict-whitespace -check-prefix=CHECK7 %s



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


[PATCH] D105263: [X86] AVX512FP16 instructions enabling 1/6

2022-04-12 Thread Jameson Nash via Phabricator via cfe-commits
vtjnash added a comment.
Herald added a subscriber: StephenFan.
Herald added a project: All.

I was tracking back a recent ABI break (also failing now in gcc 12, so maybe 
this irregularity is intentional), and was concerned that this commit is 
observed to cause the platform ABI to change depending on the feature flags of 
the current compilation unit. Prior to this change, f16 was always treated as 
i16 for the purpose of the calling-convention (e.g. returned in %ax). But after 
this change, the ABI of the value is now inconsistent between compile units. I 
made a small change to one of the existing tests to show this. Note how the 
callq result was in %ax without this mattr flag, and in %xmm0 with this mattr 
flag added. But the function known as "identity.half" is external, and did not 
change between those two calls to the llvm.

  diff --git a/llvm/test/CodeGen/X86/half.ll b/llvm/test/CodeGen/X86/half.ll
  index 46179e7d9113..8c1b8c4b76ff 100644
  --- a/llvm/test/CodeGen/X86/half.ll
  +++ b/llvm/test/CodeGen/X86/half.ll
  @@ -5,6 +5,8 @@
   ; RUN:   | FileCheck %s -check-prefixes=CHECK,CHECK-LIBCALL,BWOFF
   ; RUN: llc < %s -mtriple=x86_64-unknown-linux-gnu -mattr=+f16c 
-fixup-byte-word-insts=1 \
   ; RUN:| FileCheck %s -check-prefixes=CHECK,BWON,BWON-F16C
  +; RUN: llc < %s -mtriple=x86_64-unknown-linux-gnu -mattr=+avx512fp16 
-fixup-byte-word-insts=0 \
  +; RUN:| FileCheck %s -check-prefixes=CHECK-CC
   ; RUN: llc < %s -mtriple=i686-unknown-linux-gnu -mattr +sse2 
-fixup-byte-word-insts=0  \
   ; RUN:| FileCheck %s -check-prefixes=CHECK-I686
  
  @@ -163,16 +199,31 @@ define void @test_trunc32(float %in, half* %addr) #0 {
 ret void
   }
   
  +declare half @identity.half(half)
  +
   define void @test_trunc64(double %in, half* %addr) #0 {
   ; CHECK-LABEL: test_trunc64:
   ; CHECK:   # %bb.0:
   ; CHECK-NEXT:pushq %rbx
   ; CHECK-NEXT:movq %rdi, %rbx
   ; CHECK-NEXT:callq __truncdfhf2@PLT
  +; CHECK-NEXT:# kill: def $ax killed $ax def $eax
  +; CHECK-NEXT:movl %eax, %edi
  +; CHECK-NEXT:callq identity.half@PLT
   ; CHECK-NEXT:movw %ax, (%rbx)
   ; CHECK-NEXT:popq %rbx
   ; CHECK-NEXT:retq
   ;
  +; CHECK-CC-LABEL: test_trunc64:
  +; CHECK-CC:   # %bb.0:
  +; CHECK-CC-NEXT:pushq %rbx
  +; CHECK-CC-NEXT:movq %rdi, %rbx
  +; CHECK-CC-NEXT:vcvtsd2sh %xmm0, %xmm0, %xmm0
  +; CHECK-CC-NEXT:callq identity.half@PLT
  +; CHECK-CC-NEXT:vmovsh %xmm0, (%rbx)
  +; CHECK-CC-NEXT:popq %rbx
  +; CHECK-CC-NEXT:retq
  +;
   ; CHECK-I686-LABEL: test_trunc64:
   ; CHECK-I686:   # %bb.0:
   ; CHECK-I686-NEXT:pushl %esi
  @@ -181,12 +232,16 @@ define void @test_trunc64(double %in, half* %addr) #0 {
   ; CHECK-I686-NEXT:movsd {{.*#+}} xmm0 = mem[0],zero
   ; CHECK-I686-NEXT:movsd %xmm0, (%esp)
   ; CHECK-I686-NEXT:calll __truncdfhf2
  +; CHECK-I686-NEXT:# kill: def $ax killed $ax def $eax
  +; CHECK-I686-NEXT:movl %eax, (%esp)
  +; CHECK-I686-NEXT:calll identity.half@PLT
   ; CHECK-I686-NEXT:movw %ax, (%esi)
   ; CHECK-I686-NEXT:addl $8, %esp
   ; CHECK-I686-NEXT:popl %esi
   ; CHECK-I686-NEXT:retl
 %val16 = fptrunc double %in to half
  -  store half %val16, half* %addr
  +  %val16b = call half @identity.half(half %val16)
  +  store half %val16b, half* %addr
 ret void
   }

Is this intentional? We do already have code to handle the ABI dependency on 
vector-sizes, and could add this to the list of flags that change the ABI (i.e. 
we disable it if it will break the ABI), but wanted to confirm first if that 
was the intent here.

discovered from https://github.com/JuliaLang/julia/issues/44829


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105263

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


[PATCH] D122789: [compiler-rt] [scudo] Use -mcrc32 on x86 when available

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

This is to kurly (original Gentoo reporter)
`printf '#include \n#include \nuint32_t 
computeHardwareCRC32(uint32_t Crc, uint32_t Data) { return _mm_crc32_u32(Crc, 
Data); }' > a.c`

`clang -m32 -march=i686 -msse4.2 -c a.c` seems to compile fine.
I have some older GCC and latest GCC (2022-04, multilib), `gcc -m32 -march=i686 
-msse4.2 -c a.c`  builds while `-mcrc32` doesn't.

I suspect we should revert the `-mcrc32` change. The `__CRC32__` macro may be 
fine.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122789

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


[PATCH] D123300: [Clang] Enable opaque pointers by default

2022-04-12 Thread Arthur Eubanks via Phabricator via cfe-commits
aeubanks added a comment.

In D123300#3446023 , @nikic wrote:

> @mstorsjo Thanks! I've reduced this to a crash in `-argpromotion`:
>
>   efine void @caller() {
> call i32 @callee(ptr null)
> ret void
>   }
>   
>   define internal void @callee(ptr %p) {
> ret void
>   }
>
> Similar issue with function type mismatch.

Should be fixed with 
https://github.com/llvm/llvm-project/commit/51561b5e8017a3153629ba45b89d013ffa665f6c


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123300

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


[PATCH] D123544: [randstruct] Automatically randomize a structure of function pointers

2022-04-12 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers added a comment.

> if the developer uses default initialization for a randomized structure.

Yeah, I suspect that @aaron.ballman @lebedev.ri @xbolva00 missed that this just 
extends the newly added opt-in `-frandomize-layout-seed=` 
(https://reviews.llvm.org/D121556). Why a developer would want the latter but 
not the former, when the existing GCC plugin being used by the kernel doesn't 
differentiate is somewhat a tangential feature request that doesn't need to be 
two distinct things at the moment for existing consumers.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123544

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


[PATCH] D123544: [randstruct] Automatically randomize a structure of function pointers

2022-04-12 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 added a comment.

>> passing one of the seed flags

Yeah, then this is fine.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123544

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


[PATCH] D123544: [randstruct] Automatically randomize a structure of function pointers

2022-04-12 Thread Bill Wendling via Phabricator via cfe-commits
void added a comment.

In D123544#3446519 , @xbolva00 wrote:

>>> If we had error diagnostics when the user is about to shoot their foot off, 
>>> I'd be more comfortable with the automatic hardening behavior.
>
> This feature IMHO should be enabled with simple easy to understand flag, not 
> silently and automatically do something which may break code or create 
> surprises in debuggers.

A developer has to go out of their way to indicate that they want to use 
`randstruct`. The attribute has no effect unless they take an extra action to 
enable it (i.e. passing one of the seed flags). I agree with Aaron though that 
we need to error out if the developer uses default initialization for a 
randomized structure.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123544

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


[PATCH] D123544: [randstruct] Automatically randomize a structure of function pointers

2022-04-12 Thread Bill Wendling via Phabricator via cfe-commits
void added a comment.

In D123544#3446416 , @aaron.ballman 
wrote:

> However, I had forgotten that the base feature *requires* the user to pass a 
> randomization seed via a flag in addition to requiring the attribute (thank 
> you for bringing that back to my attention). Because this feature requires a 
> feature flag to enable it, this behavior *is* a conforming extension (the 
> user has to take an action to get the new behavior). That said, I'm still not 
> convinced we want to do this automagically for users -- it's *really* easy 
> for that flag to be set in a makefile somewhere and the user has no idea that 
> their (non-designated) initialization is now a security vulnerability. If we 
> had error diagnostics when the user is about to shoot their foot off, I'd be 
> more comfortable with the automatic hardening behavior.

We should definitely emit an error if a user is trying to use a default 
initializer for a structure that's up for randomization. It's something that 
affects the whole feature, not just structs of function pointers. Let me work 
on that. But otherwise are you okay with this patch?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123544

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


[PATCH] D123471: [CUDA] Create offloading entries when using the new driver

2022-04-12 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 added a comment.

In D123471#3446751 , @yaxunl wrote:

> HIP is considering a unified device binary embedding scheme with OpenMP. 
> However, some large MI frameworks are compiled with -fno-gpu-rdc. If 
> compiling with -fgpu-rdc, the linking time will significantly increase since 
> the post-linking optimizations take much longer time with the large linked 
> IR. Therefore, it would be desirable if the new OpenMP device binary 
> embedding scheme supports -fno-gpu-rdc mode.

This work should be very close to that, the new driver allows us to link 
everything together so OpenMP can call HIP / CUDA functions and vice-versa. I 
have done some preliminary tests with registering CUDA device variables with 
OpenMP, the only change required is to store these offloading sections at 
`omp_offloading_entries` and the OpenMP runtime will pick them up and try to 
register them. This method allows us to compile HIP / CUDA with OpenMP but 
since we're going to be registering two different images they'll have unique 
state. For full interoperability we'd need some way for make either HIP / CUDA 
or OpenMP "borrow" the other one's registered image so they can share the state.

> That said, I think this new scheme may work for -fno-gpu-rdc, probably with 
> some minor changes.

My understanding is that non-RDC builds do all the registration per-TU. Since 
that's the case then we should just be able to link them as we do now and they 
won't emit any device code that needs to be linked. So individual files could 
specify no-rdc and then they wouldn't be touched by the device linker run later.

> For -fno-gpu-rdc, each TU has its own device binary, so the device binaries 
> in the final image would be per GPU and per TU. That seems not a big problem 
> since they can be post-fixed with a unique ID for each TU.
>
> Different offload entries may have the same name in different TU's, therefore 
> an offload entry may not be uniquely identified by its name. To uniquely 
> identify an offload entry, it needs its name and the pointer to its belonging 
> device binary. Therefore, it would be desirable to have one extra field 
> 'owner':
>
>   Type struct __tgt_offload_entry {
> void*addr;  // Pointer to the offload entry info.
> // (function or global)
> char*name;  // Name of the function or global.
> size_t  size;   // Size of the entry info (0 if it a function).
> int32_t flags;
> void  *owner; // pointer to the device binary containing this 
> offload-entry
> int32_t reserved;
>   };
>
> It may be possible to use the `reserved` field for that purpose. However, it 
> is not sure if `reserved` will be used for some other purpose later.

For OpenMP we use an `exec_mode` global to control some kernel execution, 
there's a possibility we'd want to put it in the reserved field instead. We 
could add more fields to this, but it would break the ABI. We could work around 
that but it would be some additional complexity.

> Another choice is to let addr point to a struct which contains owner info. 
> However, that would introduce another level of indirection.

Yeah, I think for arbitrary extensions that would be the easiest way without 
breaking the ABI. We could use the reserved field to indicate if we have some 
"extension" there.

I think we're working through some similar stuff. I haven't worked much with 
HIP but I think there would be some benefit to bringing this all under the new 
driver I've been working on for OpenMP. Let me know if you want to collaborate 
on something for getting this to work with HIP.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123471

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


[PATCH] D123636: [randstruct] Add test for "-frandomize-layout-seed-file" flag

2022-04-12 Thread Bill Wendling via Phabricator via cfe-commits
void created this revision.
void added reviewers: aaron.ballman, MaskRay.
Herald added a subscriber: StephenFan.
Herald added a project: All.
void requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This test makes sure that the "-frandomize-layout-seed" and
"-frandomize-layout-seed-file" flags generate the same layout for the
record.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D123636

Files:
  clang/unittests/AST/RandstructTest.cpp

Index: clang/unittests/AST/RandstructTest.cpp
===
--- clang/unittests/AST/RandstructTest.cpp
+++ clang/unittests/AST/RandstructTest.cpp
@@ -27,6 +27,7 @@
 #include "clang/Frontend/ASTUnit.h"
 #include "clang/Testing/CommandLineArgs.h"
 #include "clang/Tooling/Tooling.h"
+#include "llvm/Support/ToolOutputFile.h"
 
 #include 
 
@@ -36,18 +37,40 @@
 
 using field_names = std::vector;
 
-static std::unique_ptr makeAST(const std::string &SourceCode) {
+static std::string Seed = "1234567890abcdef";
+
+static auto makeAST = [](const std::string &SourceCode) {
   std::vector Args = getCommandLineArgsForTesting(Lang_C99);
-  Args.push_back("-frandomize-layout-seed=1234567890abcdef");
+  Args.push_back("-frandomize-layout-seed=" + Seed);
 
   IgnoringDiagConsumer IgnoringConsumer = IgnoringDiagConsumer();
 
-  return tooling::buildASTFromCodeWithArgs(
+  std::unique_ptr AST = tooling::buildASTFromCodeWithArgs(
   SourceCode, Args, "input.c", "clang-tool",
   std::make_shared(),
   tooling::getClangStripDependencyFileAdjuster(),
   tooling::FileContentMappings(), &IgnoringConsumer);
-}
+
+  int SeedFileFD = -1;
+  llvm::SmallString<256> SeedFilename;
+  EXPECT_FALSE(llvm::sys::fs::createTemporaryFile("seed", "rng", SeedFileFD,
+  SeedFilename));
+  llvm::ToolOutputFile SeedFile(SeedFilename, SeedFileFD);
+  SeedFile.os() << Seed << "\n";
+
+  Args.clear();
+  Args = getCommandLineArgsForTesting(Lang_C99);
+  Args.push_back("-frandomize-layout-seed-file=" +
+ SeedFile.getFilename().str());
+
+  std::unique_ptr ASTFileSeed = tooling::buildASTFromCodeWithArgs(
+  SourceCode, Args, "input.c", "clang-tool",
+  std::make_shared(),
+  tooling::getClangStripDependencyFileAdjuster(),
+  tooling::FileContentMappings(), &IgnoringConsumer);
+
+  return std::tuple(AST.release(), ASTFileSeed.release());
+};
 
 static RecordDecl *getRecordDeclFromAST(const ASTContext &C,
 const std::string &Name) {
@@ -85,6 +108,19 @@
   return IsSubseq;
 }
 
+static bool recordsEqual(const ASTUnit *LHS, const ASTUnit *RHS,
+ std::string RecordName) {
+  const RecordDecl *LHSRD =
+  getRecordDeclFromAST(LHS->getASTContext(), RecordName);
+  const RecordDecl *RHSRD =
+  getRecordDeclFromAST(LHS->getASTContext(), RecordName);
+
+  std::vector LHSFields = getFieldNamesFromRecord(LHSRD);
+  std::vector RHSFields = getFieldNamesFromRecord(RHSRD);
+
+  return LHSFields == RHSFields;
+}
+
 namespace clang {
 namespace ast_matchers {
 
@@ -103,7 +139,8 @@
 #define RANDSTRUCT_TEST StructureLayoutRandomization
 
 TEST(RANDSTRUCT_TEST, UnmarkedStruct) {
-  const std::unique_ptr AST = makeAST(R"c(
+  const ASTUnit *AST, *ASTFileSeed;
+  std::tie(AST, ASTFileSeed) = makeAST(R"c(
 struct test {
 int bacon;
 long lettuce;
@@ -118,10 +155,13 @@
 
   EXPECT_FALSE(RD->hasAttr());
   EXPECT_FALSE(RD->isRandomized());
+  delete AST;
+  delete ASTFileSeed;
 }
 
 TEST(RANDSTRUCT_TEST, MarkedNoRandomize) {
-  const std::unique_ptr AST = makeAST(R"c(
+  const ASTUnit *AST, *ASTFileSeed;
+  std::tie(AST, ASTFileSeed) = makeAST(R"c(
 struct test {
 int bacon;
 long lettuce;
@@ -134,12 +174,16 @@
 
   const RecordDecl *RD = getRecordDeclFromAST(AST->getASTContext(), "test");
 
+  EXPECT_TRUE(recordsEqual(AST, ASTFileSeed, "test"));
   EXPECT_TRUE(RD->hasAttr());
   EXPECT_FALSE(RD->isRandomized());
+  delete AST;
+  delete ASTFileSeed;
 }
 
 TEST(RANDSTRUCT_TEST, MarkedRandomize) {
-  const std::unique_ptr AST = makeAST(R"c(
+  const ASTUnit *AST, *ASTFileSeed;
+  std::tie(AST, ASTFileSeed) = makeAST(R"c(
 struct test {
 int bacon;
 long lettuce;
@@ -152,12 +196,16 @@
 
   const RecordDecl *RD = getRecordDeclFromAST(AST->getASTContext(), "test");
 
+  EXPECT_TRUE(recordsEqual(AST, ASTFileSeed, "test"));
   EXPECT_TRUE(RD->hasAttr());
   EXPECT_TRUE(RD->isRandomized());
+  delete AST;
+  delete ASTFileSeed;
 }
 
 TEST(RANDSTRUCT_TEST, MismatchedAttrsDeclVsDef) {
-  const std::unique_ptr AST = makeAST(R"c(
+  const ASTUnit *AST, *ASTFileSeed;
+  std::tie(AST, ASTFileSeed) = makeAST(R"c(
 struct test __attribute__((randomize_layout));
 struct test {
 int bacon;
@@ -169,18 +217,21 @@
 
   EXPECT_FALSE(AST->getDiagnostics().hasErrorOccurred());
 
-  DiagnosticsEngine &Dia

[PATCH] D123535: [clang-format] Allow empty .clang-format file

2022-04-12 Thread Owen Pan via Phabricator via cfe-commits
owenpan updated this revision to Diff 422335.
owenpan added a comment.

Updated the affected clang test.


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

https://reviews.llvm.org/D123535

Files:
  clang/lib/Format/Format.cpp
  clang/test/Format/style-on-command-line.cpp


Index: clang/test/Format/style-on-command-line.cpp
===
--- clang/test/Format/style-on-command-line.cpp
+++ clang/test/Format/style-on-command-line.cpp
@@ -6,7 +6,7 @@
 // RUN: printf "BasedOnStyle: google\nIndentWidth: 5\n" > %t/.clang-format
 // RUN: clang-format -style=file -assume-filename=%t/foo.cpp < %s | FileCheck 
-strict-whitespace -check-prefix=CHECK5 %s
 // RUN: printf "\n" > %t/.clang-format
-// RUN: not clang-format -style=file -fallback-style=webkit 
-assume-filename=%t/foo.cpp < %s 2>&1 | FileCheck -strict-whitespace 
-check-prefix=CHECK6 %s
+// RUN: clang-format -style=file -fallback-style=webkit 
-assume-filename=%t/foo.cpp < %s 2>&1 | FileCheck -strict-whitespace 
-check-prefix=CHECK6 %s
 // RUN: rm %t/.clang-format
 // RUN: printf "BasedOnStyle: google\nIndentWidth: 6\n" > %t/_clang-format
 // RUN: clang-format -style=file -assume-filename=%t/foo.cpp < %s | FileCheck 
-strict-whitespace -check-prefix=CHECK7 %s
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -1722,7 +1722,7 @@
   FormatStyle::LanguageKind Language = Style->Language;
   assert(Language != FormatStyle::LK_None);
   if (Config.getBuffer().trim().empty())
-return make_error_code(ParseError::Error);
+return make_error_code(ParseError::Success);
   Style->StyleSet.Clear();
   std::vector Styles;
   llvm::yaml::Input Input(Config, /*Ctxt=*/nullptr, DiagHandler,


Index: clang/test/Format/style-on-command-line.cpp
===
--- clang/test/Format/style-on-command-line.cpp
+++ clang/test/Format/style-on-command-line.cpp
@@ -6,7 +6,7 @@
 // RUN: printf "BasedOnStyle: google\nIndentWidth: 5\n" > %t/.clang-format
 // RUN: clang-format -style=file -assume-filename=%t/foo.cpp < %s | FileCheck -strict-whitespace -check-prefix=CHECK5 %s
 // RUN: printf "\n" > %t/.clang-format
-// RUN: not clang-format -style=file -fallback-style=webkit -assume-filename=%t/foo.cpp < %s 2>&1 | FileCheck -strict-whitespace -check-prefix=CHECK6 %s
+// RUN: clang-format -style=file -fallback-style=webkit -assume-filename=%t/foo.cpp < %s 2>&1 | FileCheck -strict-whitespace -check-prefix=CHECK6 %s
 // RUN: rm %t/.clang-format
 // RUN: printf "BasedOnStyle: google\nIndentWidth: 6\n" > %t/_clang-format
 // RUN: clang-format -style=file -assume-filename=%t/foo.cpp < %s | FileCheck -strict-whitespace -check-prefix=CHECK7 %s
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -1722,7 +1722,7 @@
   FormatStyle::LanguageKind Language = Style->Language;
   assert(Language != FormatStyle::LK_None);
   if (Config.getBuffer().trim().empty())
-return make_error_code(ParseError::Error);
+return make_error_code(ParseError::Success);
   Style->StyleSet.Clear();
   std::vector Styles;
   llvm::yaml::Input Input(Config, /*Ctxt=*/nullptr, DiagHandler,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D122734: [CUDA][HIP] Fix mangling number for local struct

2022-04-12 Thread Artem Belevich via Phabricator via cfe-commits
tra added inline comments.



Comment at: clang/lib/AST/ASTContext.cpp:11760-11763
+  auto Cutoff = [](unsigned V) { return V > 1 ? V : 1; };
+  if (CUDANameMangleCtx.MangleDeviceNameInHostCompilation)
+return Cutoff(Res >> 16);
+  return Cutoff(Res & 0x);

I think we should change the `MangleNumbers` instead to use uin64_t or, perhaps 
`unsigned[2]` or even `struct{ unsigned host; unsigned device;}`.
Reducing the max number of anything to just 64K will be prone to failing sooner 
or later. 



Comment at: clang/test/CodeGenCUDA/struct-mangling-number.cu:25
+// CHECK: define amdgpu_kernel void 
@[[KERN:_Z6kernelIZN4TestIiE3runEvE2OpEvv]](
+// CHECK: @{{.*}} = {{.*}}c"[[KERN]]\00"
+

Using HOST/DEV prefixes would work better, IMO to tell what's expected to 
happen where.


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

https://reviews.llvm.org/D122734

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


[PATCH] D123471: [CUDA] Create offloading entries when using the new driver

2022-04-12 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

HIP is considering a unified device binary embedding scheme with OpenMP. 
However, some large MI frameworks are compiled with -fno-gpu-rdc. If compiling 
with -fgpu-rdc, the linking time will significantly increase since the 
post-linking optimizations take much longer time with the large linked IR. 
Therefore, it would be desirable if the new OpenMP device binary embedding 
scheme supports -fno-gpu-rdc mode.

That said, I think this new scheme may work for -fno-gpu-rdc, probably with 
some minor changes.

For -fno-gpu-rdc, each TU has its own device binary, so the device binaries in 
the final image would be per GPU and per TU. That seems not a big problem since 
they can be post-fixed with a unique ID for each TU.

Different offload entries may have the same name in different TU's, therefore 
an offload entry may not be uniquely identified by its name. To uniquely 
identify an offload entry, it needs its name and the pointer to its belonging 
device binary. Therefore, it would be desirable to have one extra field 'owner':

  Type struct __tgt_offload_entry {
void*addr;  // Pointer to the offload entry info.
// (function or global)
char*name;  // Name of the function or global.
size_t  size;   // Size of the entry info (0 if it a function).
int32_t flags;
void  *owner; // pointer to the device binary containing this offload-entry
int32_t reserved;
  };

It may be possible to use the `reserved` field for that purpose. However, it is 
not sure if `reserved` will be used for some other purpose later.

Another choice is to let addr point to a struct which contains owner info. 
However, that would introduce another level of indirection.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123471

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


[clang] c80eaa9 - Revert "[clang-format] Allow empty .clang-format file"

2022-04-12 Thread via cfe-commits

Author: owenca
Date: 2022-04-12T14:28:02-07:00
New Revision: c80eaa919f210014312f77c4c73f502406b4989d

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

LOG: Revert "[clang-format] Allow empty .clang-format file"

This reverts commit 6eafda0ef0543cad4b190002e9dae93b036a4ded.

Added: 


Modified: 
clang/lib/Format/Format.cpp

Removed: 




diff  --git a/clang/lib/Format/Format.cpp b/clang/lib/Format/Format.cpp
index bce66d117dbd1..0bbd54353d7b8 100644
--- a/clang/lib/Format/Format.cpp
+++ b/clang/lib/Format/Format.cpp
@@ -1722,7 +1722,7 @@ std::error_code parseConfiguration(llvm::MemoryBufferRef 
Config,
   FormatStyle::LanguageKind Language = Style->Language;
   assert(Language != FormatStyle::LK_None);
   if (Config.getBuffer().trim().empty())
-return make_error_code(ParseError::Success);
+return make_error_code(ParseError::Error);
   Style->StyleSet.Clear();
   std::vector Styles;
   llvm::yaml::Input Input(Config, /*Ctxt=*/nullptr, DiagHandler,



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


[PATCH] D122952: [clang] NFC: Extend comdat validation in target multiversion function tests.

2022-04-12 Thread Tom Honermann via Phabricator via cfe-commits
tahonermann marked an inline comment as done.
tahonermann added inline comments.



Comment at: clang/test/CodeGen/attr-target-mv.c:95-111
+// WINDOWS: $foo_used = comdat any
+// WINDOWS: $foo_used2.avx_sse4.2 = comdat any
+// WINDOWS: $pr50025.resolver = comdat any
+// WINDOWS: $pr50025c.resolver = comdat any
+// WINDOWS: $foo_inline.sse4.2 = comdat any
+// WINDOWS: $foo_inline.arch_ivybridge = comdat any
+// WINDOWS: $foo_inline = comdat any

erichkeane wrote:
> tahonermann wrote:
> > The non-inline non-resolver cases here are surprising to me; they aren't 
> > COMDAT on Linux. Is this intentional?
> I don't think so, we perhaps messed that up.
Actually, I misread the code previously. The non-resolver cases do correspond 
to `inline` function definitions, so it is on the Linux side that these are 
emitted as non-COMDAT symbols. Perhaps it has something to do with ELF vs 
COFF/PE; the linkage and preemption specifiers differ as well (`linkonce` vs 
`linkonce_odr dso_local` as shown below). At any rate, it isn't clear to me 
that there is anything that should be changed here.

Linux:
  define linkonce void @foo_multi(i32 noundef %i, double noundef %d) #12 {
  ...
  define linkonce void @foo_multi.avx_sse4.2(i32 noundef %i, double noundef %d) 
#13 {

Windows:
  $foo_multi = comdat any
  ...
  $foo_multi.avx_sse4.2 = comdat any
  ...
  define linkonce_odr dso_local void @foo_multi(i32 noundef %i, double noundef 
%d) #12 comdat {
  ...
  define linkonce_odr dso_local void @foo_multi.avx_sse4.2(i32 noundef %i, 
double noundef %d) #13 comdat {


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122952

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


[PATCH] D123441: [CUDA][HIP] Fix host used external kernel in archive

2022-04-12 Thread Artem Belevich via Phabricator via cfe-commits
tra accepted this revision.
tra added a comment.
This revision is now accepted and ready to land.

In D123441#3446499 , @yaxunl wrote:

> You are talking about a use case that actually needs --whole-archive option. 
> If the main TU does not reference some symbols in the archive but wants all 
> symbols in the archive to be linked in, it is justifiable to use 
> --whole-archive and HIP toolchain can support passing -Wl,--whole-archive 
> specified in the command line to the device linking step.

Hmm. My point was the opposite -- only one object should be linked and I saw no 
way to do that without conservatively including everything.
I think I've misunderstood what your patch does.

So, a main TU with just `__global__ void kernel();` would emit a reference when 
it's compiled on the GPU side. That, in turn will tell the linker what it needs 
to pull from the libraries and things should just work.
If that's the case, then it would work in my example, too.

> However, in normal use cases, users only want to link in symbols referenced 
> by the main TU. They do not need to link every symbol in the archive.

Agreed.




Comment at: clang/lib/CodeGen/CodeGenModule.cpp:602
+getModule(), ATy, false, llvm::GlobalValue::AppendingLinkage,
+llvm::ConstantArray::get(ATy, UsedArray), "hip.used.external");
+addCompilerUsedGlobal(GV);

This is not HIP-specific and should have a more generic name. 
`@gpu.used.external` ?


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

https://reviews.llvm.org/D123441

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


[PATCH] D123627: Correctly diagnose prototype redeclaration errors in C

2022-04-12 Thread James Y Knight via Phabricator via cfe-commits
jyknight accepted this revision.
jyknight added inline comments.



Comment at: clang/test/Sema/warn-deprecated-non-prototype.c:64-70
 // FIXME: we get two diagnostics here when running in pedantic mode. The first
 // comes when forming the function type for the definition, and the second
 // comes from merging the function declarations together. The second is the
 // point at which we know the behavior has changed (because we can see the
 // previous declaration at that point), but we've already issued the type
 // warning by that point. It's not ideal to be this chatty, but this situation
 // should be pretty rare.

Reword to indicate that the second diagnostic is now an error.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123627

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


[clang] 6eafda0 - [clang-format] Allow empty .clang-format file

2022-04-12 Thread via cfe-commits

Author: owenca
Date: 2022-04-12T13:54:12-07:00
New Revision: 6eafda0ef0543cad4b190002e9dae93b036a4ded

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

LOG: [clang-format] Allow empty .clang-format file

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

Added: 


Modified: 
clang/lib/Format/Format.cpp

Removed: 




diff  --git a/clang/lib/Format/Format.cpp b/clang/lib/Format/Format.cpp
index 0bbd54353d7b8..bce66d117dbd1 100644
--- a/clang/lib/Format/Format.cpp
+++ b/clang/lib/Format/Format.cpp
@@ -1722,7 +1722,7 @@ std::error_code parseConfiguration(llvm::MemoryBufferRef 
Config,
   FormatStyle::LanguageKind Language = Style->Language;
   assert(Language != FormatStyle::LK_None);
   if (Config.getBuffer().trim().empty())
-return make_error_code(ParseError::Error);
+return make_error_code(ParseError::Success);
   Style->StyleSet.Clear();
   std::vector Styles;
   llvm::yaml::Input Input(Config, /*Ctxt=*/nullptr, DiagHandler,



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


[PATCH] D123441: [CUDA][HIP] Fix host used external kernel in archive

2022-04-12 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

Also, I don't see the advantage of resolving this issue through toolchains. You 
still need to detect kernels and device variables referenced by host code, and 
generate IR's which introduce artificial references to them. It just becomes 
more complicated since you have to do them with external tools and handle extra 
outputs and inputs with the toolchain. Whereas in the current approach the 
information is directly available in AST and the IR can be generated by clang 
codegen.


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

https://reviews.llvm.org/D123441

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


[PATCH] D122378: [doc] Rely on tblgen to dump supported options value when generating doc

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

`clang-tblgen --gen-opt-docs -I ../llvm/include -I include/clang/Driver 
include/clang/Driver/ClangOptionDocs.td`

For -gsplit-dwarf, the message has lost information. I have found similar 
patterns for other options.

   .. option:: -gsplit-dwarf=
   .. program:: clang
   
  -Set DWARF fission mode to either 'split' or 'single'
  +Set DWARF fission mode
   
   .. option:: -gstrict-dwarf, -gno-strict-dwarf


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122378

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


[PATCH] D123630: Remove connection between 'ffast-math' and 'ffp-contract'.

2022-04-12 Thread Zahira Ammarguellat via Phabricator via cfe-commits
zahiraam created this revision.
zahiraam added reviewers: aaron.ballman, andrew.w.kaylor, rjmccall, joerg, 
efriedma.
Herald added a project: All.
zahiraam requested review of this revision.
Herald added a subscriber: MaskRay.
Herald added a project: clang.

Currently the options ‘ffast-math’ and the option ‘ffp-contract’ are connect. 
When ‘ffast-math’ is set, ffp-contract is altered this way:

-ffast-math/ Ofast -> ffp-contract=fast
-fno-fast-math -> if ffp-contract= fast then ffp-contract=on else 
ffp-contract unchanged

This differs from gcc which doesn’t connect the two options, and triggered some 
spurious warnings; see issue https://github.com/llvm/llvm-project/issues/54625.

The source of the problem is that the ‘ffast-math’ option is an on/off flag, 
but the ‘ffp-contract’ is an on/off/fast flag. So when ‘fno-fast-math’ is used 
there is no 
obvious value for ‘ffp-contract’.

This patch is proposing a change to make the two options unrelated.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D123630

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/ffp-contract-option.c
  clang/test/CodeGen/ffp-model.c
  clang/test/Driver/clang_f_opts.c
  clang/test/Driver/fast-math.c

Index: clang/test/Driver/fast-math.c
===
--- clang/test/Driver/fast-math.c
+++ clang/test/Driver/fast-math.c
@@ -78,7 +78,7 @@
 // CHECK-FAST-MATH-NO-APPROX-FUNC: "-fno-signed-zeros"
 // CHECK-FAST-MATH-NO-APPROX-FUNC: "-mreassociate"
 // CHECK-FAST-MATH-NO-APPROX-FUNC: "-freciprocal-math"
-// CHECK-FAST-MATH-NO-APPROX-FUNC: "-ffp-contract=fast"
+// CHECK-FAST-MATH-NO-APPROX-FUNC: "-ffp-contract=on"
 // CHECK-FAST-MATH-NO-APPROX-FUNC-NOT: "-ffast-math"
 // CHECK-FAST-MATH-NO-APPROX-FUNC-NOT: "-fapprox-func"
 //
Index: clang/test/Driver/clang_f_opts.c
===
--- clang/test/Driver/clang_f_opts.c
+++ clang/test/Driver/clang_f_opts.c
@@ -34,9 +34,10 @@
 // DEPRECATED-OFF-CHECK-NOT: -fdeprecated-macro
 
 // RUN: %clang -### -S -ffp-contract=fast %s 2>&1 | FileCheck -check-prefix=FP-CONTRACT-FAST-CHECK %s
-// RUN: %clang -### -S -ffast-math %s 2>&1 | FileCheck -check-prefix=FP-CONTRACT-FAST-CHECK %s
+// RUN: %clang -### -S -ffast-math %s 2>&1 | FileCheck -check-prefix=FP-CONTRACT-ON-CHECK %s
 // RUN: %clang -### -S -ffp-contract=off %s 2>&1 | FileCheck -check-prefix=FP-CONTRACT-OFF-CHECK %s
 // FP-CONTRACT-FAST-CHECK: -ffp-contract=fast
+// FP-CONTRACT-ON-CHECK: -ffp-contract=on
 // FP-CONTRACT-OFF-CHECK: -ffp-contract=off
 
 // RUN: %clang -### -S -funroll-loops %s 2>&1 | FileCheck -check-prefix=CHECK-UNROLL-LOOPS %s
Index: clang/test/CodeGen/ffp-model.c
===
--- clang/test/CodeGen/ffp-model.c
+++ clang/test/CodeGen/ffp-model.c
@@ -36,13 +36,12 @@
 
   // CHECK-STRICT-FAST: load float, float*
   // CHECK-STRICT-FAST: load float, float*
-  // CHECK-STRICT-FAST: call fast float @llvm.experimental.constrained.fmul.f32(float {{.*}}, float {{.*}}, {{.*}})
+  // CHECK-STRICT-FAST:  call reassoc nnan ninf nsz arcp afn float @llvm.experimental.constrained.fmul.f32(float {{.*}}, float {{.*}}, {{.*}}, {{.*}})
   // CHECK-STRICT-FAST: load float, float*
-  // CHECK-STRICT-FAST: call fast float @llvm.experimental.constrained.fadd.f32(float {{.*}}, float {{.*}}, {{.*}}
+  // CHECK-STRICT-FAST: call reassoc nnan ninf nsz arcp afn float @llvm.experimental.constrained.fadd.f32(float {{.*}}, float {{.*}}, {{.*}})
 
   // CHECK-FAST1: load float, float*
   // CHECK-FAST1: load float, float*
-  // CHECK-FAST1: fmul fast float {{.*}}, {{.*}}
-  // CHECK-FAST1: load float, float* {{.*}}
-  // CHECK-FAST1: fadd fast float {{.*}}, {{.*}}
+  // CHECK-FAST1: load float, float*
+  // CHECK-FAST1: call reassoc nnan ninf nsz arcp afn float @llvm.fmuladd.f32(float {{.*}}, float {{.*}}, float {{.*}})
 }
Index: clang/test/CodeGen/ffp-contract-option.c
===
--- clang/test/CodeGen/ffp-contract-option.c
+++ clang/test/CodeGen/ffp-contract-option.c
@@ -35,7 +35,7 @@
 // RUN: | FileCheck %s --check-prefixes=CHECK,CHECK-FPC-ON
 
 // RUN: %clang -Xclang -no-opaque-pointers -S -emit-llvm -ffp-contract=fast -fno-fast-math \
-// RUN: %s -o - | FileCheck %s --check-prefixes=CHECK,CHECK-FPC-ON
+// RUN: %s -o - | FileCheck %s --check-prefixes=CHECK,CHECK-FPC-FAST
 
 // RUN: %clang -Xclang -no-opaque-pointers -S -emit-llvm -ffp-contract=on -fno-fast-math \
 // RUN: %s -o - | FileCheck %s --check-prefixes=CHECK,CHECK-FPC-ON
@@ -44,7 +44,7 @@
 // RUN: %s -o - | FileCheck %s --check-prefixes=CHECK,CHECK-FPC-OFF
 
 // RUN: %clang -Xclang -no-opaque-pointers -S -emit-llvm -ffp-model=fast -fno-fast-math \
-// RUN: %s -o - | FileCheck %s --check-prefixes=CHECK,CHECK-FPC-ON
+// RUN: %s -o - | FileCheck %s --check-prefixes=CHECK,CHECK-FPC-FAST
 
 // RUN: %clang -Xclang -no-opaque-pointe

[PATCH] D123211: [flang][driver] Add support for generating LLVM bytecode files

2022-04-12 Thread Emil Kieri via Phabricator via cfe-commits
ekieri added inline comments.



Comment at: flang/lib/Frontend/FrontendActions.cpp:491
+  // Create and configure `TargetMachine`
+  std::unique_ptr TM;
+

awarzynski wrote:
> ekieri wrote:
> > Is there a reason why use TM.reset instead of initialising TM like you do 
> > with os below?
> Good question!
> 
> Note that [[ 
> https://github.com/llvm/llvm-project/blob/3d0e0e1027203fe5e89104ad81ee7bb53e525f95/llvm/include/llvm/MC/TargetRegistry.h#L446-L452
>  | createTargetMachine ]] that I use below returns a plain pointer. [[ 
> https://github.com/llvm/llvm-project/blob/3d0e0e1027203fe5e89104ad81ee7bb53e525f95/clang/include/clang/Frontend/CompilerInstance.h#L703-L706
>  | createDefaultOutputFile ]] that I use for initialising `os` below returns 
> `std::unique_ptr`. IIUC, I can only [[ 
> https://en.cppreference.com/w/cpp/memory/unique_ptr/reset | reset ]] a 
> `unique_ptr` (like `TM`) with a plain pointer.
> 
> Have I missed anything?
Well, I had missed that. Thanks! Let's see if I got it right this time.

So unique_ptr has an _explicit_ constructor taking a raw pointer 
([[https://en.cppreference.com/w/cpp/memory/unique_ptr/unique_ptr | constructor 
(2)]]). So as you say (if I interpreted you correctly),

  std::unique_ptr TM = theTarget->createTargetMachine(...);

does not work, as it requires an implicit conversion from raw to unique 
pointer. But constructor syntax should (and does for me) work:

  std::unique_ptr TM(theTarget->createTargetMachine(...));

as this makes the conversion explicit. Does this make sense, or did I miss 
something more?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123211

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


[PATCH] D123627: Correctly diagnose prototype redeclaration errors in C

2022-04-12 Thread Erich Keane via Phabricator via cfe-commits
erichkeane accepted this revision.
erichkeane added a comment.
This revision is now accepted and ready to land.

This LGTM, please give a day or so for others to take a look.




Comment at: clang/test/Sema/predefined-function.c:27
 
-int foobar(int); // note {{previous declaration is here}}
-int foobar() // error {{conflicting types for 'foobar'}}
+int foobar(int); // expected-note {{previous declaration is here}}
+int foobar() // expected-error {{conflicting types for 'foobar'}}

Oh my!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123627

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


[PATCH] D123627: Correctly diagnose prototype redeclaration errors in C

2022-04-12 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman created this revision.
aaron.ballman added reviewers: jyknight, eli.friedman, clang-language-wg.
Herald added a project: All.
aaron.ballman requested review of this revision.
Herald added a project: clang.

We did not implement C99 6.7.5.3p15 fully in that we missed the rule for 
compatible function types where a prior declaration has a prototype and a 
subsequent definition (not just declaration) has an empty identifier list or an 
identifier list with a mismatch in parameter arity. This addresses that 
situation by issuing an error on code like:

  void f(int);
  void f() {} // type conflicts with previous declaration

(Note: we already diagnose the other type conflict situations appropriately, 
this was the only situation we hadn't covered that I could find.)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D123627

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/test/CodeGen/functions.c
  clang/test/Sema/predefined-function.c
  clang/test/Sema/prototype-redecls.c
  clang/test/Sema/warn-deprecated-non-prototype.c

Index: clang/test/Sema/warn-deprecated-non-prototype.c
===
--- clang/test/Sema/warn-deprecated-non-prototype.c
+++ clang/test/Sema/warn-deprecated-non-prototype.c
@@ -68,6 +68,6 @@
 // previous declaration at that point), but we've already issued the type
 // warning by that point. It's not ideal to be this chatty, but this situation
 // should be pretty rare.
-void blapp(int);
-void blapp() { } // both-warning {{a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x}} \
+void blapp(int); // both-note {{previous declaration is here}}
+void blapp() { } // both-error {{conflicting types for 'blapp'}} \
  // strict-warning {{a function declaration without a prototype is deprecated in all versions of C}}
Index: clang/test/Sema/prototype-redecls.c
===
--- /dev/null
+++ clang/test/Sema/prototype-redecls.c
@@ -0,0 +1,24 @@
+// RUN: %clang_cc1 -fsyntax-only -Wno-strict-prototypes -verify %s
+
+void blapp(int); // expected-note {{previous}}
+void blapp() { } // expected-error {{conflicting types for 'blapp'}}
+
+void yarp(int, ...); // expected-note {{previous}}
+void yarp(); // expected-error {{conflicting types for 'yarp'}}
+
+void blarg(int, ...); // expected-note {{previous}}
+void blarg() {}   // expected-error {{conflicting types for 'blarg'}}
+
+void blerp(short);  // expected-note {{previous}}
+void blerp(x) int x; {} // expected-error {{conflicting types for 'blerp'}}
+
+void glerp(int);
+void glerp(x) short x; {} // Okay, promoted type is fine
+
+// All these cases are okay
+void derp(int);
+void derp(x) int x; {}
+
+void garp(int);
+void garp();
+void garp(x) int x; {}
Index: clang/test/Sema/predefined-function.c
===
--- clang/test/Sema/predefined-function.c
+++ clang/test/Sema/predefined-function.c
@@ -19,13 +19,13 @@
 {
   return 0;
 }
-int bar() // expected-error {{redefinition of 'bar'}} 
+int bar() // expected-error {{conflicting types for 'bar'}}
 {
   return 0;
 }
 
-int foobar(int); // note {{previous declaration is here}}
-int foobar() // error {{conflicting types for 'foobar'}}
+int foobar(int); // expected-note {{previous declaration is here}}
+int foobar() // expected-error {{conflicting types for 'foobar'}}
 {
   return 0;
 }
Index: clang/test/CodeGen/functions.c
===
--- clang/test/CodeGen/functions.c
+++ clang/test/CodeGen/functions.c
@@ -16,9 +16,6 @@
   f();
 }
 
-int a(int);
-int a() {return 1;}
-
 void f0(void) {}
 // CHECK-LABEL: define{{.*}} void @f0()
 
Index: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -2244,7 +2244,8 @@
   }
 
   SemaRef.CheckFunctionDeclaration(/*Scope*/ nullptr, Function, Previous,
-   IsExplicitSpecialization);
+   IsExplicitSpecialization,
+   Function->isThisDeclarationADefinition());
 
   // Check the template parameter list against the previous declaration. The
   // goal here is to pick up default arguments added since the friend was
@@ -2605,7 +2606,8 @@
   }
 
   SemaRef.CheckFunctionDeclaration(nullptr, Method, Previous,
-   IsExplicitSpecialization);
+   IsExplicitSpecialization,
+   Method->isThisDeclarationADefinition());
 
   if (D->isPure())
 SemaRef.CheckPureMethod(Me

[clang] d10c091 - lit.cfg.py: remove obsoleted feature clang-driver

2022-04-12 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2022-04-12T13:31:07-07:00
New Revision: d10c09168377767e43efbcb22e65343d509c13f0

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

LOG: lit.cfg.py: remove obsoleted feature clang-driver

Added: 


Modified: 
clang/test/Driver/hip-wavefront-size.hip
clang/test/lit.cfg.py

Removed: 




diff  --git a/clang/test/Driver/hip-wavefront-size.hip 
b/clang/test/Driver/hip-wavefront-size.hip
index dd7ca16ae2d3d..f9ec9f6b82d4f 100644
--- a/clang/test/Driver/hip-wavefront-size.hip
+++ b/clang/test/Driver/hip-wavefront-size.hip
@@ -1,4 +1,4 @@
-// REQUIRES: clang-driver,amdgpu-registered-target
+// REQUIRES: amdgpu-registered-target
 
 // RUN: %clang -### -target x86_64-linux-gnu \
 // RUN:   --cuda-gpu-arch=gfx900 \

diff  --git a/clang/test/lit.cfg.py b/clang/test/lit.cfg.py
index d8eacce29a09c..3abed15fdc58e 100644
--- a/clang/test/lit.cfg.py
+++ b/clang/test/lit.cfg.py
@@ -185,10 +185,6 @@ def is_filesystem_case_insensitive():
 if not re.match(r'^x86_64.*-(windows-msvc|windows-gnu)$', 
config.target_triple):
 config.available_features.add('LP64')
 
-# [PR12920] "clang-driver" -- set if gcc driver is not used.
-if not re.match(r'.*-(cygwin)$', config.target_triple):
-config.available_features.add('clang-driver')
-
 # Tests that are specific to the Apple Silicon macOS.
 if re.match(r'^arm64(e)?-apple-(macos|darwin)', config.target_triple):
 config.available_features.add('apple-silicon-mac')



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


[clang] 63fbc77 - [Driver][test] Remove unused/obsoleted REQUIRES: clang-driver

2022-04-12 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2022-04-12T13:29:46-07:00
New Revision: 63fbc771218f6ec6700c607ed257a536bb016e12

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

LOG: [Driver][test] Remove unused/obsoleted REQUIRES: clang-driver

It (introduced by 556d713c70bfaf58ac18d089883f9c34c581633a) appears to be
related to the removed dragonegg project. In addition, the feature was a bit
misnamed and may lur users to unnecessarily use it.

Added: 


Modified: 
clang/test/CodeGenCUDA/amdgpu-alias-undef-symbols.cu
clang/test/CodeGenCUDASPIRV/kernel-argument.cu
clang/test/Driver/amdgpu-invalid-target-id.s
clang/test/Driver/as-warnings.c
clang/test/Driver/cl-options.cu
clang/test/Driver/clang_f_opts.c
clang/test/Driver/cuda-arch-translation.cu
clang/test/Driver/cuda-bad-arch.cu
clang/test/Driver/cuda-bail-out.cu
clang/test/Driver/cuda-bindings.cu
clang/test/Driver/cuda-constructor-alias.cu
clang/test/Driver/cuda-detect-path.cu
clang/test/Driver/cuda-detect.cu
clang/test/Driver/cuda-device-triple.cu
clang/test/Driver/cuda-dwarf-2.cu
clang/test/Driver/cuda-external-tools.cu
clang/test/Driver/cuda-macosx.cu
clang/test/Driver/cuda-march.cu
clang/test/Driver/cuda-no-pgo-or-coverage.cu
clang/test/Driver/cuda-no-sanitizers.cu
clang/test/Driver/cuda-no-stack-protector.cu
clang/test/Driver/cuda-not-found.cu
clang/test/Driver/cuda-omp-unsupported-debug-options.cu
clang/test/Driver/cuda-options.cu
clang/test/Driver/cuda-output-asm.cu
clang/test/Driver/cuda-phases.cu
clang/test/Driver/cuda-ptxas-path.cu
clang/test/Driver/cuda-unused-arg-warning.cu
clang/test/Driver/cuda-version-check.cu
clang/test/Driver/cuda-windows.cu
clang/test/Driver/dwarf-target-version-clamp.cu
clang/test/Driver/fast-math.c
clang/test/Driver/fat_archive_amdgpu.cpp
clang/test/Driver/fat_archive_nvptx.cpp
clang/test/Driver/fp-model.c
clang/test/Driver/fsanitize-ignorelist.c
clang/test/Driver/hip-autolink.hip
clang/test/Driver/hip-binding.hip
clang/test/Driver/hip-code-object-version.hip
clang/test/Driver/hip-cuid-hash.hip
clang/test/Driver/hip-cuid.hip
clang/test/Driver/hip-default-gpu-arch.hip
clang/test/Driver/hip-device-compile.hip
clang/test/Driver/hip-device-libs.hip
clang/test/Driver/hip-fpie-option.hip
clang/test/Driver/hip-gsplit-dwarf-options.hip
clang/test/Driver/hip-gz-options.hip
clang/test/Driver/hip-host-cpu-features.hip
clang/test/Driver/hip-include-path.hip
clang/test/Driver/hip-inputs.hip
clang/test/Driver/hip-invalid-target-id.hip
clang/test/Driver/hip-launch-api.hip
clang/test/Driver/hip-link-bundle-archive.hip
clang/test/Driver/hip-link-save-temps.hip
clang/test/Driver/hip-link-static-library.hip
clang/test/Driver/hip-macros.hip
clang/test/Driver/hip-no-device-libs.hip
clang/test/Driver/hip-offload-arch.hip
clang/test/Driver/hip-options.hip
clang/test/Driver/hip-output-file-name.hip
clang/test/Driver/hip-phases.hip
clang/test/Driver/hip-printf.hip
clang/test/Driver/hip-rdc-device-only.hip
clang/test/Driver/hip-sanitize-options.hip
clang/test/Driver/hip-save-temps.hip
clang/test/Driver/hip-std.hip
clang/test/Driver/hip-syntax-only.hip
clang/test/Driver/hip-target-id.hip
clang/test/Driver/hip-toolchain-device-only.hip
clang/test/Driver/hip-toolchain-dwarf.hip
clang/test/Driver/hip-toolchain-features.hip
clang/test/Driver/hip-toolchain-mllvm.hip
clang/test/Driver/hip-toolchain-no-rdc.hip
clang/test/Driver/hip-toolchain-opt.hip
clang/test/Driver/hip-toolchain-rdc-separate.hip
clang/test/Driver/hip-toolchain-rdc-static-lib.hip
clang/test/Driver/hip-toolchain-rdc.hip
clang/test/Driver/hip-unbundle-preproc.hip
clang/test/Driver/hip-version.hip
clang/test/Driver/hip-windows-filename.hip
clang/test/Driver/hipspv-device-libs.hip
clang/test/Driver/hipspv-pass-plugin.hip
clang/test/Driver/hipspv-toolchain-rdc.hip
clang/test/Driver/hipspv-toolchain.hip
clang/test/Driver/indirect-tls-seg-refs.c
clang/test/Driver/invalid-offload-options.cpp
clang/test/Driver/invalid-target-id.cl
clang/test/Driver/linker-opts.c
clang/test/Driver/lto.cu
clang/test/Driver/miamcu-opt.c
clang/test/Driver/ms-bitfields.c
clang/test/Driver/offloading-interoperability.c
clang/test/Driver/openmp-offload-gpu.c
clang/test/Driver/openmp-offload.c
clang/test/Driver/rocm-detect.cl
clang/test/Driver/rocm-detect.hip
clang/test/Driver/rocm-device-libs.cl
clang/test/Driver/rocm-not-found.cl
clang/test/Driver/stack-arg-probe.c
clang/test/Driver/stackrealign.c
clang/test/Driver/target-id-macros.cl
clang/test/Driver/target-id-macros.hip
clang/test/Driv

[PATCH] D122983: [C11/C2x] Change the behavior of the implicit function declaration warning

2022-04-12 Thread James Y Knight via Phabricator via cfe-commits
jyknight added a comment.

Looks reasonable overall.

I've added a few specific comments to some tests, but in general, I think we 
should avoid adding -std=c99 to test-cases to workaround implicit decl issues, 
unless:

- the test is explicitly testing the behavior of implicit decls (potentially in 
interaction with some other feature).
- it's a regression test, with some particular reduced/artificial inputs.
- the ARM codegen tests, for now, on the assumption the arm maintainers will 
address it separately.




Comment at: 
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-implicits.c:76
 
 void pointeeConverison(int *IP, double *DP) { pointeeConversion(DP, IP); }
 // NO-WARN: Even though this is possible in C, a swap is diagnosed by the 
compiler.

This is just a typo, you won't need the -std=c99 on this test if you fix 
pointeeConverison -> pointeeConversion



Comment at: clang/docs/ReleaseNotes.rst:141-146
+- The ``-Wimplicit-function-declaration`` warning diagnostic now defaults to
+  emitting an error (which can be downgraded to a warning with
+  ``-Wno-error=implicit-function-declaration`` or disabled entirely with
+  ``-Wno-implicit-function-declaration``) in C11 and
+  C17 mode. This is because the feature was removed in C99 and cannot be
+  supported in C2x.

Some wording suggestions here, to remove parenthetical, and more explicitly 
note that the options have no effect in C2x.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:423-426
+def ext_implicit_function_decl_c11 : ExtWarn<
+  "implicit declaration of function %0 is invalid in C99 and later and "
+  "unsupported in C2x">,
+  InGroup, DefaultError;

I think it'd be good to use the same message for both variants. (Even if you're 
building in c99, might as well note it's gone in C2x).



Comment at: clang/test/CodeGen/PowerPC/builtins-ppc-p8vector.c:4
 // RUN: %clang_cc1 -target-feature +altivec -target-feature +power8-vector 
-triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck %s 
-check-prefix=CHECK-LE
-// RUN: not %clang_cc1 -target-feature +altivec -target-feature +vsx -triple 
powerpc64-unknown-unknown -emit-llvm %s -o - 2>&1 | FileCheck %s 
-check-prefix=CHECK-PPC
+// RUN: not %clang_cc1 -std=c99 -target-feature +altivec -target-feature +vsx 
-triple powerpc64-unknown-unknown -emit-llvm %s -o - 2>&1 | FileCheck %s 
-check-prefix=CHECK-PPC
 // Added -target-feature +vsx above to avoid errors about "vector double" and 
to

This test-run is already expected to fail, so the -std=c99 seems like it 
shouldn't be necessary. I think just change the CHECK-PPC lines looking for 
"warning: implicit declaration" to look for "error: implicit declaration" 
instead.



Comment at: clang/test/CodeGen/X86/bmi2-builtins.c:1
-// RUN: %clang_cc1 -ffreestanding %s -triple=x86_64-apple-darwin 
-target-feature +bmi2 -emit-llvm -o - | FileCheck %s
+// RUN: %clang_cc1 -ffreestanding %s -triple=x86_64-apple-darwin 
-target-feature +bmi2 -emit-llvm -std=c99 -o - | FileCheck %s
 // RUN: %clang_cc1 -ffreestanding %s -triple=i386-apple-darwin -target-feature 
+bmi2 -emit-llvm -o - | FileCheck %s --check-prefix=B32

That this is needed looks like a test bug here -- it should be testing 
_mulx_u64 on x86-64 and _mulx_u32 on i386.



Comment at: clang/test/CodeGen/misaligned-param.c:1
-// RUN: %clang_cc1 %s -triple i386-apple-darwin -emit-llvm -o - | FileCheck %s
 // Misaligned parameter must be memcpy'd to correctly aligned temporary.

Declare `int bar(struct s*, struct s*);` instead



Comment at: clang/test/Headers/arm-cmse-header-ns.c:1
-// RUN: %clang_cc1 -triple thumbv8m.base-eabi -fsyntax-only%s 2>&1 
| FileCheck --check-prefix=CHECK-c %s
+// RUN: %clang_cc1 -triple thumbv8m.base-eabi -fsyntax-only -std=c99 %s 
2>&1 | FileCheck --check-prefix=CHECK-c %s
 // RUN: not %clang_cc1 -triple thumbv8m.base-eabi -fsyntax-only -x c++ %s 2>&1 
| FileCheck --check-prefix=CHECK-cpp %s

Maybe better to edit the CHECK-c lines to expect an error?



Comment at: clang/test/Modules/modulemap-locations.m:2
 // RUN: rm -rf %t 
-// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -fmodules-cache-path=%t -I 
%S/Inputs/ModuleMapLocations/Module_ModuleMap -I 
%S/Inputs/ModuleMapLocations/Both -F %S/Inputs/ModuleMapLocations -I 
%S/Inputs/ModuleMapLocations -F %S/Inputs -x objective-c -fsyntax-only %s 
-verify -Wno-private-module
+// RUN: %clang_cc1 -std=c99 -fmodules -fimplicit-module-maps 
-fmodules-cache-path=%t -I %S/Inputs/ModuleMapLocations/Module_ModuleMap -I 
%S/Inputs/ModuleMapLocations/Both -F %S/Inputs/ModuleMapLocations -I 
%S/Inputs/ModuleMapLocations -F %S/Inputs -x objective-c -fsyntax-only %s 
-verify -Wno-private-module
 

Change expected-war

[PATCH] D119290: [Clang] Add support for -fcx-limited-range, -fcx-fortran-rules options.

2022-04-12 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay requested changes to this revision.
MaskRay added inline comments.
This revision now requires changes to proceed.
Herald added a subscriber: StephenFan.



Comment at: clang/test/Driver/complex-range-flags.c:3
+
+// REQUIRES: clang-driver
+

delete

this is legacy which is not needed for a long time



Comment at: clang/test/Driver/complex-range-flags.c:6
+// CHECK-FULL-RANGE: "-cc1"
+// CHECK-FULL-RANGE: "-fcx-range=full"
+

Move CHECK lines below RUN



Comment at: clang/test/Driver/complex-range-flags.c:14
+
+// RUN: %clang -### -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FULL-RANGE %s

No need to wrap lines


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119290

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


[PATCH] D67678: PR17164: Change clang's default behavior from -flax-vector-conversions=all to -flax-vector-conversions=integer.

2022-04-12 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith reopened this revision.
rsmith added a comment.
This revision is now accepted and ready to land.
Herald added a project: All.

@dexonsmith @arphaman What do we need to do to get this re-landed?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67678

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


[PATCH] D122008: [flang][driver] Add support for generating executables

2022-04-12 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added inline comments.



Comment at: clang/lib/Driver/ToolChains/Gnu.cpp:392
+  //* on some platforms, we may need to use lib64 instead of lib (you can 
use
+  //CLANG_LIBDIR_SUFFIX to automate this)
+  //* this logic should also work on other similar platforms too, so we

I think the multilib style CLANG_LIBDIR_SUFFIX is being phased out in clang 
driver, so no need for the comment.



Comment at: clang/lib/Driver/ToolChains/Gnu.cpp:397
+  llvm::sys::path::parent_path(TC.getDriver().Dir);
+  llvm::sys::path::append(DefaultLibPath, Twine("lib"));
+  CmdArgs.push_back(Args.MakeArgString("-L" + DefaultLibPath));




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122008

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


[PATCH] D123544: [randstruct] Automatically randomize a structure of function pointers

2022-04-12 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 added a comment.

>> If we had error diagnostics when the user is about to shoot their foot off, 
>> I'd be more comfortable with the automatic hardening behavior.

This feature IMHO should be enabled with simple easy to understand flag, not 
silently and automatically do something which may break code or create 
surprises in debuggers.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123544

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


[PATCH] D123450: [clang-format] Parse Verilog if statements

2022-04-12 Thread Björn Schäpers via Phabricator via cfe-commits
HazardyKnusperkeks added inline comments.



Comment at: clang/lib/Format/FormatToken.h:374
+  /// Verilog we want to treat the backtick like a hash.
+  tok::TokenKind AliasToken = tok::unknown;
+

sstwcw wrote:
> HazardyKnusperkeks wrote:
> > Can't we do that with a type?
> > 
> > I'm not very happy about the alias, because you can still call 
> > `Tok.getKind()`.
> The main problem I seek to solve with the alias thing is with `tok::hash`.  
> In Verilog they use a backtick instead of a hash.  At first I modified all 
> places in the code to recognize the backtick.  MyDeveloperDay said "year 
> really not nice.. its like we can never use tok::hash again!"  Using a type 
> also requires modifying all instances of tok::hash if I get you right.  How 
> do I please everyone?
Then you must hide Tok in the private part, so that no one can ever access 
`Tok.getKind()` accidentally.



Comment at: clang/lib/Format/FormatToken.h:1533
+switch (Tok.Tok.getKind()) {
+case tok::kw_case:
+case tok::kw_class:

sstwcw wrote:
> HazardyKnusperkeks wrote:
> > So you have a blacklist what is not a keyword? Seems a bit non future 
> > proof, new C++ keywords would have to be added here.
> This is a whitelist of what is a keyword.
My bad. Go on.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123450

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


[PATCH] D123544: [randstruct] Automatically randomize a structure of function pointers

2022-04-12 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 added a comment.

>> Because this feature requires a feature flag to enable it, this behavior 
>> *is* a conforming extension (the user has to take an action to get the new 
>> behavior).

Well, then we should have proper C test (ok if linux only or so) to show case 
behaviour of this patch with and without that feature flag.

Looking at this unit test, I thought that would get this feature with simple 
"clang source.c" invocation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123544

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


[PATCH] D123345: Treat `std::move`, `forward`, and `move_if_noexcept` as builtins.

2022-04-12 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added a comment.

In D123345#3440935 , @aaron.ballman 
wrote:

> Any chance you'd be interested in submitting this patch to 
> http://llvm-compile-time-tracker.com/ (instructions at 
> http://llvm-compile-time-tracker.com/about.php) so we can have an idea of how 
> compile times are impacted? (It's not critical, but having some more compile 
> time performance measurements would be helpful to validate that this actually 
> saves compile time as expected.

Nice idea, done:

- Instructions executed while compiling reduced by 0.3-0.6% 

 at `-O0` on C++ benchmarks kimwitu++ and tramp3d-v4. Changes in the noise on 
other benchmarks and with optimizations enabled.
- Code size reduced by 0.51% 

 at `-O0` on those same benchmarks. No change on any others.
- Effect on compiler memory usage 

 appears to be below the noise floor.

In D123345#3442809 , @joerg wrote:

> The patch contains at least one user visible change that would be quite 
> surprising: it is no longer possible to intentionally set a break point on 
> `std::move`.

Yeah, I think it's reasonable to support `-fno-builtin-std-move` and the like 
-- done. The intended model here is to treat these `std::` functions just like 
how we treat the functions in the global namespace for which we provide 
built-in semantics, so I think `-fno-builtin` and `-ffreestanding` and the like 
should all treat these functions the same way they treat `malloc` and `strlen` 
and such.

> Thinking more about it, what about a slightly different implementation 
> strategy? Provide a compiler built-in `__builtin_std_move`. If it is present, 
> libc++ can alias it into `namespace std` using regular C++. Much of the 
> name-matching and argument checking in various places disappears. The check 
> to skip template instantiation can be done the same way. Over-all, it should 
> be much less intrusive with the same performance benefits for an 
> built-in-aware STL. It completely side-steps the question of ignoring the 
> actual implementation `of std::move` in the source, because there is none.

This is an interesting idea, but I don't think it would work out well. As a 
superficial problem, C++ aliases (eg, `using` declarations) don't let you 
change the name of a function. More fundamentally, I think this would end up 
being a lot more complicated: we'd need to implement the rules for how to 
deduce parameter types and transform them into return types ourselves, we'd 
need to somehow support `std::forward`'s explicit template argument, and in 
C++17 and before, it's valid to take the address of `std::move` and co, which 
would require us to invent a function definition for them in IR generation. 
This would also be a major deviation from how we treat all other standard 
library functions for which we have built-in knowledge.




Comment at: clang/lib/Sema/SemaExpr.cpp:20282
+  if (Context.BuiltinInfo.isInStdNamespace(BuiltinID)) {
+// Any use of these other than a direct call is ill-formed as of C++20,
+// because they are not addressable functions. In earlier language

aaron.ballman wrote:
> I wonder how often these get passed around as function objects... e.g.,
> ```
> template 
> void func(Fn &&Call);
> 
> int main() {
>   func(std::move);
> }
> ```
> (I don't see evidence that this is a common code pattern, but C++ surprises 
> me often enough that I wonder if this will cause issues.)
I expect people will tell us if it this fires a lot... if it does, we can 
consider making the C++20 error a `DefaultError` `ExtWarn`.



Comment at: clang/lib/Sema/SemaInit.cpp:8192-8195
+  // We might get back another placeholder expression if we resolved to a
+  // builtin.
+  if (!CurInit.isInvalid())
+CurInit = S.CheckPlaceholderExpr(CurInit.get());

aaron.ballman wrote:
> Do we need to make this call every time we've called 
> `FixOverloadedFunctionReference()`? I guess I'm not seeing the changes that 
> necessitated this call (or the one below).
We only need to do this in places that assume that the result doesn't have a 
placeholder type. Specifically, `FixOverloadedFunctionReference` can now take 
us from an expression whose type is the "overloaded function" builtin type to 
an expression whose type is the "builtin function" builtin type, after overload 
resolution picks a specific template specialization, which these places were 
not pre

[PATCH] D123441: [CUDA][HIP] Fix host used external kernel in archive

2022-04-12 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

In D123441#3446478 , @tra wrote:

>> This approach will only link in kernels and device variables used by host 
>> code
>
> In the absence of the explicit reference info from the host side, GPU-side 
> linker  must link all objects with symbols that **may** be used by the host.
> E.g if we have a library with three objects, each has one kernel (and thus 
> potentially used by the host), but the main TU only refers to a kernel from 
> one of them, GPU-side linker would still have to link in all three objects 
> from the library, as any of them may have been referenced by the host.

You are talking about a use case that actually needs --whole-archive option. If 
the main TU does not reference some symbols in the archive but wants all 
symbols in the archive to be linked in, it is justifiable to use 
--whole-archive and HIP toolchain can support passing -Wl,--whole-archive 
specified in the command line to the device linking step.

However, in normal use cases, users only want to link in symbols referenced by 
the main TU. They do not need to link every symbol in the archive.


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

https://reviews.llvm.org/D123441

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


[PATCH] D123471: [CUDA] Create offloading entries when using the new driver

2022-04-12 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 added a comment.

In D123471#3446464 , @tra wrote:

> I've mentioned in D123441  that it would be 
> useful to have a list of GPU-side symbols needed by the host and this offload 
> info is pretty close to what we need. The only remaining feature is being 
> able to extract them by external tool, so we could pass them to the GPU-side 
> linker. Perhaps we could just generate a GPU-side stub file which would only 
> have an array of needed GPU-side references, compile and add it to the 
> GPU-side linker as yet another input which would ensure we do link in the 
> exact set of GPU objects from the static libraries.

These will probably only be valid once the final executable is linked. Since 
the structure contains a pointers to other symbols they'll only have non-null 
values after the final linking. After linking for the host you should be able 
to just use something like `objdump -s -j cuda_offloading_entries` to get all 
of them. For my use-case I only need to be able to iterate these symbols when 
the program is run. If we want to use this for something else it would be good 
to keep them synced up to avoid duplicating error. Also the patches say "CUDA" 
but the vast majority will also apply to HIP without much change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123471

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


[clang] 7443a50 - [clang][extract-api] Add support for true anonymous enums

2022-04-12 Thread Daniel Grumberg via cfe-commits

Author: Daniel Grumberg
Date: 2022-04-12T20:42:17+01:00
New Revision: 7443a504bf6c22b83727c1e43c82c4165b2d5db5

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

LOG: [clang][extract-api] Add support for true anonymous enums

Anonymous enums without a typedef should have a "(anonymous)" identifier.

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

Added: 


Modified: 
clang/include/clang/ExtractAPI/API.h
clang/lib/ExtractAPI/API.cpp
clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
clang/test/ExtractAPI/enum.c

Removed: 




diff  --git a/clang/include/clang/ExtractAPI/API.h 
b/clang/include/clang/ExtractAPI/API.h
index 6a9429704d45e..53db46ca44c13 100644
--- a/clang/include/clang/ExtractAPI/API.h
+++ b/clang/include/clang/ExtractAPI/API.h
@@ -50,13 +50,13 @@ namespace extractapi {
 /// \endcode
 using DocComment = std::vector;
 
-// Classes deriving from APIRecord need to have Name be the first constructor
+// Classes deriving from APIRecord need to have USR be the first constructor
 // argument. This is so that they are compatible with `addTopLevelRecord`
 // defined in API.cpp
 /// The base representation of an API record. Holds common symbol information.
 struct APIRecord {
-  StringRef Name;
   StringRef USR;
+  StringRef Name;
   PresumedLoc Location;
   AvailabilityInfo Availability;
   LinkageInfo Linkage;
@@ -101,11 +101,11 @@ struct APIRecord {
 
   APIRecord() = delete;
 
-  APIRecord(RecordKind Kind, StringRef Name, StringRef USR,
+  APIRecord(RecordKind Kind, StringRef USR, StringRef Name,
 PresumedLoc Location, const AvailabilityInfo &Availability,
 LinkageInfo Linkage, const DocComment &Comment,
 DeclarationFragments Declaration, DeclarationFragments SubHeading)
-  : Name(Name), USR(USR), Location(Location), Availability(Availability),
+  : USR(USR), Name(Name), Location(Location), Availability(Availability),
 Linkage(Linkage), Comment(Comment), Declaration(Declaration),
 SubHeading(SubHeading), Kind(Kind) {}
 
@@ -117,13 +117,13 @@ struct APIRecord {
 struct GlobalFunctionRecord : APIRecord {
   FunctionSignature Signature;
 
-  GlobalFunctionRecord(StringRef Name, StringRef USR, PresumedLoc Loc,
+  GlobalFunctionRecord(StringRef USR, StringRef Name, PresumedLoc Loc,
const AvailabilityInfo &Availability,
LinkageInfo Linkage, const DocComment &Comment,
DeclarationFragments Declaration,
DeclarationFragments SubHeading,
FunctionSignature Signature)
-  : APIRecord(RK_GlobalFunction, Name, USR, Loc, Availability, Linkage,
+  : APIRecord(RK_GlobalFunction, USR, Name, Loc, Availability, Linkage,
   Comment, Declaration, SubHeading),
 Signature(Signature) {}
 
@@ -137,12 +137,12 @@ struct GlobalFunctionRecord : APIRecord {
 
 /// This holds information associated with global functions.
 struct GlobalVariableRecord : APIRecord {
-  GlobalVariableRecord(StringRef Name, StringRef USR, PresumedLoc Loc,
+  GlobalVariableRecord(StringRef USR, StringRef Name, PresumedLoc Loc,
const AvailabilityInfo &Availability,
LinkageInfo Linkage, const DocComment &Comment,
DeclarationFragments Declaration,
DeclarationFragments SubHeading)
-  : APIRecord(RK_GlobalVariable, Name, USR, Loc, Availability, Linkage,
+  : APIRecord(RK_GlobalVariable, USR, Name, Loc, Availability, Linkage,
   Comment, Declaration, SubHeading) {}
 
   static bool classof(const APIRecord *Record) {
@@ -155,12 +155,12 @@ struct GlobalVariableRecord : APIRecord {
 
 /// This holds information associated with enum constants.
 struct EnumConstantRecord : APIRecord {
-  EnumConstantRecord(StringRef Name, StringRef USR, PresumedLoc Loc,
+  EnumConstantRecord(StringRef USR, StringRef Name, PresumedLoc Loc,
  const AvailabilityInfo &Availability,
  const DocComment &Comment,
  DeclarationFragments Declaration,
  DeclarationFragments SubHeading)
-  : APIRecord(RK_EnumConstant, Name, USR, Loc, Availability,
+  : APIRecord(RK_EnumConstant, USR, Name, Loc, Availability,
   LinkageInfo::none(), Comment, Declaration, SubHeading) {}
 
   static bool classof(const APIRecord *Record) {
@@ -175,10 +175,10 @@ struct EnumConstantRecord : APIRecord {
 struct EnumRecord : APIRecord {
   SmallVector> Constants;
 
-  EnumRecord(StringRef Name, StringRef USR, PresumedLoc Loc,
+  EnumRecord(StringRef USR, StringRef Name, PresumedLoc Loc,
  const AvailabilityInfo &Availability, const DocCom

[PATCH] D123441: [CUDA][HIP] Fix host used external kernel in archive

2022-04-12 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

> This approach will only link in kernels and device variables used by host code

In the absence of the explicit reference info from the host side, GPU-side 
linker  must link all objects with symbols that **may** be used by the host.
E.g if we have a library with three objects, each has one kernel (and thus 
potentially used by the host), but the main TU only refers to a kernel from one 
of them, GPU-side linker would still have to link in all three objects from the 
library, as any of them may have been referenced by the host.

> --whole-archive will require users to carefully arrange --whole-archive and 
> --no-whole-archive options for the archives they use.

This would be done by the driver. My understanding is that we already have to 
do nontrivial stuff under the hood (e.g. unbundling) so telling the linker that 
static archives must always use `--whole-archive` should be doable. 
I don't insist on it, just exploring alternative options we may have.


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

https://reviews.llvm.org/D123441

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


[PATCH] D123471: [CUDA] Create offloading entries when using the new driver

2022-04-12 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

I've mentioned in D123441  that it would be 
useful to have a list of GPU-side symbols needed by the host and this offload 
info is pretty close to what we need. The only remaining feature is being able 
to extract them by external tool, so we could pass them to the GPU-side linker. 
Perhaps we could just generate a GPU-side stub file which would only have an 
array of needed GPU-side references, compile and add it to the GPU-side linker 
as yet another input which would ensure we do link in the exact set of GPU 
objects from the static libraries.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123471

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


[PATCH] D123441: [CUDA][HIP] Fix host used external kernel in archive

2022-04-12 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

In D123441#3446408 , @tra wrote:

> LGTM in principle. This will keep around the GPU code we do need.
>
> That said, it seems to be a rather blunt hammer. I think we'll end up linking 
> almost everything in an archive into the final executable as we'll likely 
> have a host-visible symbol in most of the GPU objects (e.g. most of them 
> would have a kernel).
> Device-side linking would also be unaware of which objects were actually 
> linked into the host executable and thus would link in more objects than 
> necessary. We could have achieved about the same result by linking with 
> `--whole-archive`.
>
> The root of the problem here is that in isolation GPU-side linking does not 
> know what will really be needed by the host and thus has to link in 
> everything, except, maybe, object files where we may have `__device__` 
> functions only.
> Ideally, the linking should be a two-phase process -- link CPU side, extract 
> references to the GPU symbols (host-side compilation would have to be 
> augmented to place them in a well known location) and pass them to the 
> GPU-side linker which would then have all the info necessary to pull in 
> relevant GPU-side objects without compiler having to force having nearly all 
> of them linked in.
>
> I realize that this would be a nontrivial change to the compilation pipeline. 
> As a short-to-medium term solution, this patch may do, though I'd probably 
> prefer just linking with `--whole-archive` as it would, in theory, be simpler.

This approach will only link in kernels and device variables used by host code, 
whereas --whole-archive will keep everything in the archive. There are use 
cases where the archive contains a large amount of kernels that the application 
only use a few of them.

Also, --whole-archive will require users to carefully arrange --whole-archive 
and --no-whole-archive options for the archives they use. This approach avoids 
that.


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

https://reviews.llvm.org/D123441

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


[PATCH] D122285: [analyzer] Add path note tags to standard library function summaries.

2022-04-12 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:879
+// knowing in advance which branch is taken.
+return (Node->succ_size() > 1) ? Note.str() : "";
+  },

NoQ wrote:
> balazske wrote:
> > balazske wrote:
> > > Can other checkers not add successor nodes (that make this check not 
> > > always correct)?
> > Is there a reason against add the note without the word "Assuming" instead 
> > of no note?
> > Can other checkers not add successor nodes (that make this check not always 
> > correct)?
> 
> They'll be chained to the newly created node, not to the same predecessor. 
> Two checkers adding transitions on the same post-call won't (and shouldn't) 
> suddenly cause a state split.
> 
> > Is there a reason against add the note without the word "Assuming" instead 
> > of no note?
> 
> We generally never have event notes in such cases.
> 
> We sometimes have control flow notes such as "`aking true branch`" (arrow 
> pointing to the branch in plist).
> 
> Then, separately from that, we have tracking notes such as "an interesting 
> value appeared in this variable from this assignment, which also makes the 
> assigned value interesting" (eg. "`null pointer value assigned to 'p'`") - we 
> could have a similar note "an interesting value was returned from that 
> function because that other value had a certain range, which also makes that 
> other value interesting" - which we should definitely consider.
> 
> But simply saying "this function call was completely predictable and we don't 
> even care what the value is in the first place" doesn't sound useful.
*`Taking`


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

https://reviews.llvm.org/D122285

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


[PATCH] D122285: [analyzer] Add path note tags to standard library function summaries.

2022-04-12 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added inline comments.



Comment at: 
clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:872-883
+if (NewState && NewState != State) {
+  StringRef Note = Case.getNote();
+  const NoteTag *Tag = C.getNoteTag(
+  // Sorry couldn't help myself.
+  [Node, Note]() {
+// Don't emit "Assuming..." note when we ended up
+// knowing in advance which branch is taken.

steakhal wrote:
> I thought we mostly have one or two cases. If we have two cases, then the 
> constraint should be the opposite of the other one.
> 
> If this is the case, when does `NewState && NewState != State` not imply 
> `Node->succ_size() > 1` given that `Summary.getCases().size() >= 2`?
Typically this is going to be the case but I wouldn't rely on that. The 
constraint solver may get confused (inb4 "system is over constrained"), there 
may be other updates to the state in the branch definition which would cause 
the state to change.



Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:879
+// knowing in advance which branch is taken.
+return (Node->succ_size() > 1) ? Note.str() : "";
+  },

balazske wrote:
> balazske wrote:
> > Can other checkers not add successor nodes (that make this check not always 
> > correct)?
> Is there a reason against add the note without the word "Assuming" instead of 
> no note?
> Can other checkers not add successor nodes (that make this check not always 
> correct)?

They'll be chained to the newly created node, not to the same predecessor. Two 
checkers adding transitions on the same post-call won't (and shouldn't) 
suddenly cause a state split.

> Is there a reason against add the note without the word "Assuming" instead of 
> no note?

We generally never have event notes in such cases.

We sometimes have control flow notes such as "`aking true branch`" (arrow 
pointing to the branch in plist).

Then, separately from that, we have tracking notes such as "an interesting 
value appeared in this variable from this assignment, which also makes the 
assigned value interesting" (eg. "`null pointer value assigned to 'p'`") - we 
could have a similar note "an interesting value was returned from that function 
because that other value had a certain range, which also makes that other value 
interesting" - which we should definitely consider.

But simply saying "this function call was completely predictable and we don't 
even care what the value is in the first place" doesn't sound useful.



Comment at: 
clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:1326-1330
   // The locale-specific range.
   .Case({ArgumentCondition(0U, WithinRange, {{128, UCharRangeMax}})})
   // Is not an unsigned char.
   .Case({ArgumentCondition(0U, OutOfRange, Range(0, UCharRangeMax)),
  ReturnValueCondition(WithinRange, SingleValue(0))}));

steakhal wrote:
> Why don't we have notes for these cases?
Like I mentioned in D122285#inline-1169194, I'm not sure these cases should 
exist at all. In particular, explaining them to the user is fairly problematic 
because justifying them in the first place is problematic.



Comment at: clang/test/Analysis/std-c-library-functions-path-notes.c:3
+// RUN: -analyzer-checker=core,apiModeling \
+// RUN: -analyzer-config assume-controlled-environment=false \
+// RUN: -analyzer-output=text

steakhal wrote:
> This is the default value. What's the benefit of passing this?
I'm not sure what the default value //should// be. I guess I can remove this 
and/or move non-`getenv` tests into another file.


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

https://reviews.llvm.org/D122285

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


[PATCH] D123610: [Testing] Drop clangTesting from clang's public library interface

2022-04-12 Thread Haojian Wu via Phabricator via cfe-commits
hokein accepted this revision.
hokein added a comment.
This revision is now accepted and ready to land.

The change makes sense to me.




Comment at: clang/lib/Testing/CMakeLists.txt:6
+# Not add_clang_library: this is not part of clang's public library interface.
+# Unit tests should depend on this with target_link_libraries, not clang_TLL.
+add_llvm_library(clangTesting

OOO, what is `clang_TLL`?



Comment at: clang/lib/Testing/CMakeLists.txt:7
+# Unit tests should depend on this with target_link_libraries, not clang_TLL.
+add_llvm_library(clangTesting
   CommandLineArgs.cpp

no related to this patch, I think `clangTestingSupport` is a better name (also 
align with the LLVM one). 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123610

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


[PATCH] D123345: Treat `std::move`, `forward`, and `move_if_noexcept` as builtins.

2022-04-12 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith updated this revision to Diff 422311.
rsmith added a comment.

- Document `-fno-builtin-std-foo`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123345

Files:
  clang/docs/CommandGuide/clang.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Basic/Builtins.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/AST/ExprConstant.cpp
  clang/lib/Analysis/BodyFarm.cpp
  clang/lib/Basic/Builtins.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaInit.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/test/Analysis/use-after-move.cpp
  clang/test/CodeGenCXX/builtin-std-move.cpp
  clang/test/CodeGenCXX/microsoft-abi-throw.cpp
  clang/test/SemaCXX/builtin-std-move-nobuiltin.cpp
  clang/test/SemaCXX/builtin-std-move.cpp
  clang/test/SemaCXX/unqualified-std-call-fixits.cpp
  clang/test/SemaCXX/unqualified-std-call.cpp
  clang/test/SemaCXX/warn-consumed-analysis.cpp

Index: clang/test/SemaCXX/warn-consumed-analysis.cpp
===
--- clang/test/SemaCXX/warn-consumed-analysis.cpp
+++ clang/test/SemaCXX/warn-consumed-analysis.cpp
@@ -953,12 +953,12 @@
 namespace std {
   void move();
   template
-  void move(T&&);
+  T &&move(T&);
 
   namespace __1 {
 void move();
 template
-void move(T&&);
+T &&move(T&);
   }
 }
 
@@ -971,7 +971,7 @@
   void test() {
 x.move();
 std::move();
-std::move(x);
+std::move(x); // expected-warning {{ignoring return value}}
 std::__1::move();
 std::__1::move(x);
   }
Index: clang/test/SemaCXX/unqualified-std-call.cpp
===
--- clang/test/SemaCXX/unqualified-std-call.cpp
+++ clang/test/SemaCXX/unqualified-std-call.cpp
@@ -1,17 +1,17 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -Wall -std=c++11 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -Wall -std=c++11 %s -Wno-unused-value
 
 namespace std {
 
 template 
 void dummy(T &&) {}
 template 
-void move(T &&) {}
+T &&move(T &&x) { return x; }
 template 
 void move(T &&, U &&) {}
 
 inline namespace __1 {
 template 
-void forward(T &) {}
+T &forward(T &x) { return x; }
 } // namespace __1
 
 struct foo {};
Index: clang/test/SemaCXX/unqualified-std-call-fixits.cpp
===
--- clang/test/SemaCXX/unqualified-std-call-fixits.cpp
+++ clang/test/SemaCXX/unqualified-std-call-fixits.cpp
@@ -6,9 +6,9 @@
 
 namespace std {
 
-void move(auto &&a) {}
+int &&move(auto &&a) { return a; }
 
-void forward(auto &a) {}
+int &&forward(auto &a) { return a; }
 
 } // namespace std
 
@@ -16,8 +16,8 @@
 
 void f() {
   int i = 0;
-  move(i); // expected-warning {{unqualified call to std::move}}
-  // CHECK: {{^}}  std::
-  forward(i); // expected-warning {{unqualified call to std::forward}}
-  // CHECK: {{^}}  std::
+  (void)move(i); // expected-warning {{unqualified call to std::move}}
+  // CHECK: {{^}}  (void)std::move
+  (void)forward(i); // expected-warning {{unqualified call to std::forward}}
+  // CHECK: {{^}}  (void)std::forward
 }
Index: clang/test/SemaCXX/builtin-std-move.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/builtin-std-move.cpp
@@ -0,0 +1,90 @@
+// RUN: %clang_cc1 -std=c++17 -verify %s
+// RUN: %clang_cc1 -std=c++17 -verify %s -DNO_CONSTEXPR
+// RUN: %clang_cc1 -std=c++20 -verify %s
+
+namespace std {
+#ifndef NO_CONSTEXPR
+#define CONSTEXPR constexpr
+#else
+#define CONSTEXPR
+#endif
+
+  template CONSTEXPR T &&move(T &x) {
+static_assert(T::moveable, "instantiated move"); // expected-error {{no member named 'moveable' in 'B'}}
+ // expected-error@-1 {{no member named 'moveable' in 'C'}}
+return static_cast(x);
+  }
+
+  // Unrelated move functions are not the builtin.
+  template CONSTEXPR int move(T, T) { return 5; }
+
+  template struct ref { using type = T&; };
+  template struct ref { using type = T&&; };
+
+  template CONSTEXPR auto move_if_noexcept(T &x) -> typename ref(x)))>::type {
+static_assert(T::moveable, "instantiated move_if_noexcept"); // expected-error {{no member named 'moveable' in 'B'}}
+return static_cast(x)))>::type>(x);
+  }
+
+  template struct remove_reference { using type = T; };
+  template struct remove_reference { using type = T; };
+  template struct remove_reference { using type = T; };
+
+  template CONSTEXPR T &&forward(typename remove_reference::type &x) {
+static_assert(T::moveable, "instantiated forward"); // expected-error {{no member named 'moveable' in 'B'}}
+

[PATCH] D123544: [randstruct] Automatically randomize a structure of function pointers

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

In D123544#3446265 , @void wrote:

> Could you explain a bit more why it's not considered conforming behavior in 
> C? The entire feature is definitely unusual and introduces some caveats (the 
> structure initialization being just one of them).

Given:

  typedef void (*func_ptr)(void);
  
  struct S {
func_ptr f1, f2, f3;
  };
  
  void func(void);
  
  struct S s = {func, 0, func};

C requires that s.f1 and s.f3 point to func and s.f2 is a null pointer, but if 
you automatically randomize the layout of that structure as in this patch, this 
strictly conforming code will break.

However, I had forgotten that the base feature *requires* the user to pass a 
randomization seed via a flag in addition to requiring the attribute (thank you 
for bringing that back to my attention). Because this feature requires a 
feature flag to enable it, this behavior *is* a conforming extension (the user 
has to take an action to get the new behavior). That said, I'm still not 
convinced we want to do this automagically for users -- it's *really* easy for 
that flag to be set in a makefile somewhere and the user has no idea that their 
(non-designated) initialization is now a security vulnerability. If we had 
error diagnostics when the user is about to shoot their foot off, I'd be more 
comfortable with the automatic hardening behavior.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123544

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


[PATCH] D123441: [CUDA][HIP] Fix host used external kernel in archive

2022-04-12 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

LGTM in principle. This will keep around the GPU code we do need.

That said, it seems to be a rather blunt hammer. I think we'll end up linking 
almost everything in an archive into the final executable as we'll likely have 
a host-visible symbol in most of the GPU objects (e.g. most of them would have 
a kernel).
Device-side linking would also be unaware of which objects were actually linked 
into the host executable and thus would link in more objects than necessary. We 
could have achieved about the same result by linking with `--whole-archive`.

The root of the problem here is that in isolation GPU-side linking does not 
know what will really be needed by the host and thus has to link in everything, 
except, maybe, object files where we may have `__device__` functions only.
Ideally, the linking should be a two-phase process -- link CPU side, extract 
references to the GPU symbols (host-side compilation would have to be augmented 
to place them in a well known location) and pass them to the GPU-side linker 
which would then have all the info necessary to pull in relevant GPU-side 
objects without compiler having to force having nearly all of them linked in.

I realize that this would be a nontrivial change to the compilation pipeline. 
As a short-to-medium term solution, this patch may do, though I'd probably 
prefer just linking with `--whole-archive` as it would, in theory, be simpler.


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

https://reviews.llvm.org/D123441

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


[PATCH] D123127: [AST] Add a new TemplateName for templates found via a using declaration.

2022-04-12 Thread Haojian Wu via Phabricator via cfe-commits
hokein updated this revision to Diff 422310.
hokein added a comment.

reland version: there is no freebit in the TemplateName's PointerUnion to store
5 different pointer types in 32-bit build, instead we change the TemplateDecl to
NamedDecl, which can be used to hold the TemplateDecl and UsingShadowDecl.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123127

Files:
  clang-tools-extra/clangd/DumpAST.cpp
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang/include/clang/AST/PropertiesBase.td
  clang/include/clang/AST/TemplateName.h
  clang/include/clang/AST/TextNodeDumper.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/ASTStructuralEquivalence.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/ODRHash.cpp
  clang/lib/AST/TemplateName.cpp
  clang/lib/AST/TextNodeDumper.cpp
  clang/lib/AST/Type.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/test/AST/ast-dump-using-template.cpp
  clang/test/CXX/temp/temp.deduct.guide/p3.cpp
  clang/tools/libclang/CIndex.cpp
  clang/unittests/AST/ASTImporterTest.cpp
  clang/unittests/AST/CMakeLists.txt
  clang/unittests/AST/TemplateNameTest.cpp

Index: clang/unittests/AST/TemplateNameTest.cpp
===
--- /dev/null
+++ clang/unittests/AST/TemplateNameTest.cpp
@@ -0,0 +1,68 @@
+//===- unittests/AST/TemplateNameTest.cpp --- Tests for TemplateName --===//
+//
+// 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 "ASTPrint.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "llvm/Support/raw_ostream.h"
+#include "gtest/gtest.h"
+
+namespace clang {
+namespace {
+using namespace ast_matchers;
+
+std::string printTemplateName(TemplateName TN, const PrintingPolicy &Policy,
+  TemplateName::Qualified Qual) {
+  std::string Result;
+  llvm::raw_string_ostream Out(Result);
+  TN.print(Out, Policy, Qual);
+  return Out.str();
+}
+
+TEST(TemplateName, PrintUsingTemplate) {
+  std::string Code = R"cpp(
+namespace std {
+  template  struct vector {};
+}
+namespace absl { using std::vector; }
+
+template class T> class X;
+
+using absl::vector;
+using A = X;
+  )cpp";
+  auto AST = tooling::buildASTFromCode(Code);
+  ASTContext &Ctx = AST->getASTContext();
+  // Match X in X.
+  auto Matcher = templateArgumentLoc().bind("id");
+
+  // !TemplateArgumentLoc is a local storage of the MatchCallback!
+  internal::CollectMatchesCallback StorageCB;
+  MatchFinder Finder;
+  Finder.addMatcher(Matcher, &StorageCB);
+  Finder.matchAST(Ctx);
+  const auto *Template =
+  selectFirst("id", StorageCB.Nodes);
+  assert(Template);
+  TemplateName TN = Template->getArgument().getAsTemplate();
+  EXPECT_EQ(TN.getKind(), TemplateName::UsingTemplate);
+  EXPECT_EQ(TN.getAsUsingShadowDecl()->getTargetDecl(), TN.getAsTemplateDecl());
+
+  EXPECT_EQ(printTemplateName(TN, Ctx.getPrintingPolicy(),
+  TemplateName::Qualified::Fully),
+"std::vector");
+  EXPECT_EQ(printTemplateName(TN, Ctx.getPrintingPolicy(),
+  TemplateName::Qualified::AsWritten),
+"vector");
+  EXPECT_EQ(printTemplateName(TN, Ctx.getPrintingPolicy(),
+  TemplateName::Qualified::None),
+"vector");
+}
+
+} // namespace
+} // namespace clang
Index: clang/unittests/AST/CMakeLists.txt
===
--- clang/unittests/AST/CMakeLists.txt
+++ clang/unittests/AST/CMakeLists.txt
@@ -31,6 +31,7 @@
   SourceLocationTest.cpp
   StmtPrinterTest.cpp
   StructuralEquivalenceTest.cpp
+  TemplateNameTest.cpp
   TypePrinterTest.cpp
   )
 
Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -890,6 +890,18 @@
  functionDecl(hasDescendant(usingDecl(hasName("bar");
 }
 
+TEST_P(ImportDecl, ImportUsingTemplate) {
+  MatchVerifier Verifier;
+  testImport("namespace ns { template  struct S {}; }"
+ "template  class T> class X {};"
+ "void declToImport() {"
+ "using ns::S;  X xi; }",
+ Lang_CXX11, "", Lang_CXX11, Verifier,
+ functionDecl(
+ hasDescendant(varDecl(hasTypeLoc(templateSpecializationTypeLoc(
+ hasAnyTemplateArgumentLoc(templateArgumentLoc(;
+}
+
 TEST_P(ImportDecl, ImportUsingEnumDecl) {
   MatchVerifier Verifier;
   testImport("nam

[PATCH] D123127: [AST] Add a new TemplateName for templates found via a using declaration.

2022-04-12 Thread Haojian Wu via Phabricator via cfe-commits
hokein reopened this revision.
hokein added a comment.
This revision is now accepted and ready to land.

reopening it for the reland version.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123127

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


[PATCH] D123574: [clang] NFCI: Use FileEntryRef in PPCallbacks::InclusionDirective

2022-04-12 Thread Ben Barham via Phabricator via cfe-commits
bnbarham accepted this revision.
bnbarham added a comment.

Thanks Jan :)!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123574

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


[PATCH] D121637: [PowerPC] Fix EmitPPCBuiltinExpr to emit arguments once

2022-04-12 Thread Quinn Pham via Phabricator via cfe-commits
quinnp reopened this revision.
quinnp added a comment.
This revision is now accepted and ready to land.

Re-opening the revision so that I can update it with a fix.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121637

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


[PATCH] D123574: [clang] NFCI: Use FileEntryRef in PPCallbacks::InclusionDirective

2022-04-12 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith accepted this revision.
dexonsmith added a comment.
This revision is now accepted and ready to land.

LGTM, with a couple of nitpicks. If you'd rather not improve the tests that's 
probably fine, since the patch doesn't make them any worse.




Comment at: clang-tools-extra/clangd/unittests/HeadersTests.cpp:71
 auto &SM = Clang->getSourceManager();
-auto Entry = SM.getFileManager().getFile(Filename);
+auto Entry = SM.getFileManager().getOptionalFileRef(Filename);
 EXPECT_TRUE(Entry);

Test might be cleaner with `EXPECT_THAT_ERROR`; see comment in 
ParsedASTTests.cpp.



Comment at: clang-tools-extra/clangd/unittests/ParsedASTTests.cpp:564-565
   IncludeStructure Includes = ExpectedAST.getIncludeStructure();
-  auto MainFE = FM.getFile(testPath("foo.cpp"));
+  auto MainFE = FM.getOptionalFileRef(testPath("foo.cpp"));
   ASSERT_TRUE(MainFE);
   auto MainID = Includes.getOrCreateID(*MainFE);

It might be nice to see the errors here on failures. You could do that with:
```
lang=c++
Optional MainFE;
ASSERT_THAT_ERROR(FM.getFileRef(testPath("foo.cpp")).moveInto(MainFE), 
Succeeded());
```
The `{EXPECT,ASSERT}_THAT_ERROR` live in `llvm/Testing/Support/Error.h`.



Comment at: clang/lib/Serialization/ASTReader.cpp:6048-6049
 if (!FullFileName.empty())
-  if (auto FE = PP.getFileManager().getFile(FullFileName))
+  if (auto FE = PP.getFileManager().getOptionalFileRef(FullFileName))
 File = *FE;
 

I think you can remove the inner `if` here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123574

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


[PATCH] D123544: [randstruct] Automatically randomize a structure of function pointers

2022-04-12 Thread Bill Wendling via Phabricator via cfe-commits
void added a comment.

In D123544#3446285 , @lebedev.ri 
wrote:

> Does this not lead to non-deterministic/non-reproducible builds?

It's deterministic based on the randomization seed.

> I do not understand why this feature must be inflicted onto everyone.

A developer must mark structures with the `randomize_layout` attribute and 
supply a randomization seed for the randstruct feature to be enabled. It's only 
when a randomization seed is supplied that it'll randomize structures 
consisting of only function pointers (which happens a lot in Linux). And you're 
able to opt-out of such a thing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123544

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


[PATCH] D123352: [analyzer] Add FixItHint to `nullability.NullReturnedFromNonnull` and `nullability.NullableReturnedFromNonnull`

2022-04-12 Thread Moshe via Phabricator via cfe-commits
MosheBerman added a comment.

Hey, bumping for feedback, please. :D


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123352

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


[PATCH] D123345: Treat `std::move`, `forward`, and `move_if_noexcept` as builtins.

2022-04-12 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith updated this revision to Diff 422305.
rsmith added a comment.

- Add support for -fno-builtin, -ffreestanding, -fno-builtin-std-move.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123345

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Basic/Builtins.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/AST/ExprConstant.cpp
  clang/lib/Analysis/BodyFarm.cpp
  clang/lib/Basic/Builtins.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaInit.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/test/Analysis/use-after-move.cpp
  clang/test/CodeGenCXX/builtin-std-move.cpp
  clang/test/CodeGenCXX/microsoft-abi-throw.cpp
  clang/test/SemaCXX/builtin-std-move-nobuiltin.cpp
  clang/test/SemaCXX/builtin-std-move.cpp
  clang/test/SemaCXX/unqualified-std-call-fixits.cpp
  clang/test/SemaCXX/unqualified-std-call.cpp
  clang/test/SemaCXX/warn-consumed-analysis.cpp

Index: clang/test/SemaCXX/warn-consumed-analysis.cpp
===
--- clang/test/SemaCXX/warn-consumed-analysis.cpp
+++ clang/test/SemaCXX/warn-consumed-analysis.cpp
@@ -953,12 +953,12 @@
 namespace std {
   void move();
   template
-  void move(T&&);
+  T &&move(T&);
 
   namespace __1 {
 void move();
 template
-void move(T&&);
+T &&move(T&);
   }
 }
 
@@ -971,7 +971,7 @@
   void test() {
 x.move();
 std::move();
-std::move(x);
+std::move(x); // expected-warning {{ignoring return value}}
 std::__1::move();
 std::__1::move(x);
   }
Index: clang/test/SemaCXX/unqualified-std-call.cpp
===
--- clang/test/SemaCXX/unqualified-std-call.cpp
+++ clang/test/SemaCXX/unqualified-std-call.cpp
@@ -1,17 +1,17 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -Wall -std=c++11 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -Wall -std=c++11 %s -Wno-unused-value
 
 namespace std {
 
 template 
 void dummy(T &&) {}
 template 
-void move(T &&) {}
+T &&move(T &&x) { return x; }
 template 
 void move(T &&, U &&) {}
 
 inline namespace __1 {
 template 
-void forward(T &) {}
+T &forward(T &x) { return x; }
 } // namespace __1
 
 struct foo {};
Index: clang/test/SemaCXX/unqualified-std-call-fixits.cpp
===
--- clang/test/SemaCXX/unqualified-std-call-fixits.cpp
+++ clang/test/SemaCXX/unqualified-std-call-fixits.cpp
@@ -6,9 +6,9 @@
 
 namespace std {
 
-void move(auto &&a) {}
+int &&move(auto &&a) { return a; }
 
-void forward(auto &a) {}
+int &&forward(auto &a) { return a; }
 
 } // namespace std
 
@@ -16,8 +16,8 @@
 
 void f() {
   int i = 0;
-  move(i); // expected-warning {{unqualified call to std::move}}
-  // CHECK: {{^}}  std::
-  forward(i); // expected-warning {{unqualified call to std::forward}}
-  // CHECK: {{^}}  std::
+  (void)move(i); // expected-warning {{unqualified call to std::move}}
+  // CHECK: {{^}}  (void)std::move
+  (void)forward(i); // expected-warning {{unqualified call to std::forward}}
+  // CHECK: {{^}}  (void)std::forward
 }
Index: clang/test/SemaCXX/builtin-std-move.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/builtin-std-move.cpp
@@ -0,0 +1,90 @@
+// RUN: %clang_cc1 -std=c++17 -verify %s
+// RUN: %clang_cc1 -std=c++17 -verify %s -DNO_CONSTEXPR
+// RUN: %clang_cc1 -std=c++20 -verify %s
+
+namespace std {
+#ifndef NO_CONSTEXPR
+#define CONSTEXPR constexpr
+#else
+#define CONSTEXPR
+#endif
+
+  template CONSTEXPR T &&move(T &x) {
+static_assert(T::moveable, "instantiated move"); // expected-error {{no member named 'moveable' in 'B'}}
+ // expected-error@-1 {{no member named 'moveable' in 'C'}}
+return static_cast(x);
+  }
+
+  // Unrelated move functions are not the builtin.
+  template CONSTEXPR int move(T, T) { return 5; }
+
+  template struct ref { using type = T&; };
+  template struct ref { using type = T&&; };
+
+  template CONSTEXPR auto move_if_noexcept(T &x) -> typename ref(x)))>::type {
+static_assert(T::moveable, "instantiated move_if_noexcept"); // expected-error {{no member named 'moveable' in 'B'}}
+return static_cast(x)))>::type>(x);
+  }
+
+  template struct remove_reference { using type = T; };
+  template struct remove_reference { using type = T; };
+  template struct remove_reference { using type = T; };
+
+  template CONSTEXPR T &&forward(typename remove_reference::type &x) {
+static_assert(T::moveable, "instantiated forward"); // expected-error {{no member named 'moveable' in 'B'}}
+

[PATCH] D123544: [randstruct] Automatically randomize a structure of function pointers

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

In D123544#3446285 , @lebedev.ri 
wrote:

> Does this not lead to non-deterministic/non-reproducible builds?
> I do not understand why this feature must be inflicted onto everyone.

It seems that the feature fixes the randomization seed in the option 
`-frandomize-layout-seed=`, so it is deterministic, but it currently has a 
possible Windows vs non-Windows host difference, probably related to MSVC's 
`std::mt19937`.
My concern is related to the lack of `-frandomize-layout-seed-file=` testing in 
the base patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123544

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


[PATCH] D123544: [randstruct] Automatically randomize a structure of function pointers

2022-04-12 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

Does this not lead to non-deterministic/non-reproducible builds?
I do not understand why this feature must be inflicted onto everyone.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123544

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


[PATCH] D123544: [randstruct] Automatically randomize a structure of function pointers

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

The Linux kernel already uses some options which deviate from standard C: 
`__attribute__((__gnu_inline__))`, `-ftrivial-auto-var-init=zero 
-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang`.

If the feature is to emulate `GCC_PLUGIN_STRUCTLEAK` in kernel 
`security/Kconfig.hardening` and the GCC plugin already does something similar, 
I am fine with this patch.
(My main concern is the lack of testing from the base patch.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123544

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


[PATCH] D121556: [randstruct] Add randomize structure layout support

2022-04-12 Thread Bill Wendling via Phabricator via cfe-commits
void added a comment.

In D121556#3445124 , @aaron.ballman 
wrote:

> In D121556#3444837 , @void wrote:
>
>> In D121556#334 , @MaskRay 
>> wrote:
>>
>>> In D121556#3444260 , @void wrote:
>>>
 In D121556#3444221 , @MaskRay 
 wrote:

> In D121556#3444131 , @void 
> wrote:
>
>> In D121556#3444021 , @MaskRay 
>> wrote:
>>
>>> 7aa8c38a9e190aea14116028c38b1d9f54cbb0b3 
>>>  
>>> still uses `std::shuffle`, not incorporating the `llvm::shuffle` fixes 
>>> I did.
>>
>> You said it was still failing after the std::shuffle to llvm::shuffle 
>> change.
>
> By saying it still failed, I meant there were other Windows vs 
> non-Windows differences, not that std::shuffle=>llvm::shuffle was an 
> unintended change.

 So does it work or not? If I change it to `llvm::shuffle`, will the tests 
 fail or will they pass regardless of the platform?
>>>
>>> If you change `std::shuffle` to `llvm::shuffle` and  add back tests like 
>>> `EXPECT_EQ(Expected, getFieldNamesFromRecord(RD));`, the test will likely 
>>> fail on Windows.
>>> I recall that @aaron.ballman uses Windows and may help you find the 
>>> differences.
>>
>> It was also failing on MacOS. And it failed a different way on another 
>> Windows version. That's why I removed the test for the deterministic shuffle.
>>
>>> I tend to agree with your `I think it's just a case where Windows' 
>>> algorithm for std::mt19937 is subtly different than the one for Linux.`
>>
>> The only other option would be to add the `EXPECT_*` stuff on one platform 
>> (like Linux). I suppose that would be better than nothing.
>
> Here's what has me confused... You're using `std::mt19937` which is a very 
> specific random number algorithm and you're giving it the same seed. I don't 
> think we *should* be getting different behavior from the random number 
> generator across platforms. The issue is the call to `std::shuffle` (see 
> https://en.cppreference.com/w/cpp/algorithm/random_shuffle#Notes), so I think 
> using `llvm::shuffle` will fix all the tests on all the platforms.

Okay. So I'll make this change and submit it during a time when there isn't a 
lot of activity so that I can revert it if it fails without annoying too many 
people.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121556

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


[PATCH] D123533: [clang][extract-api] Add support for true anonymous enums

2022-04-12 Thread Zixu Wang via Phabricator via cfe-commits
zixuw accepted this revision.
zixuw added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123533

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


[PATCH] D123544: [randstruct] Automatically randomize a structure of function pointers

2022-04-12 Thread Bill Wendling via Phabricator via cfe-commits
void added a comment.

In D123544#3445425 , @xbolva00 wrote:

>>> While I agree with the security aspects of this in principle, it is not a 
>>> conforming behavior in C and it runs significant risk of breaking existing 
>>> code such that it introduces new security issues.
>
> I agree strongly. This could happily can do more harm than good ("the road to 
> hell is paved with good intentions"). Please leave it opt-in or introduce 
> "modes" for this feature like -frandomize-struct=func-pointers | 
> -frandomize-struct=xxx | -frandomize-struct=all.

[Some context for this patch: the GCC plugin does this already. Our initial 
implementation of randstruct skipped that part.]

Could you explain a bit more why it's not considered conforming behavior in C? 
The entire feature is definitely unusual and introduces some caveats (the 
structure initialization being just one of them).

Here's an article on this feature and why randomizing structs of function 
pointers is Considered Good(tm): https://lwn.net/Articles/722293/


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123544

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


[PATCH] D123533: [clang][extract-api] Add support for true anonymous enums

2022-04-12 Thread Daniel Grumberg via Phabricator via cfe-commits
dang updated this revision to Diff 422296.
dang marked an inline comment as done.
dang added a comment.

Add a second anonymous enum to the test case to make sure that distinct symbols
are generated for both of them.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123533

Files:
  clang/include/clang/ExtractAPI/API.h
  clang/lib/ExtractAPI/API.cpp
  clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
  clang/test/ExtractAPI/enum.c

Index: clang/test/ExtractAPI/enum.c
===
--- clang/test/ExtractAPI/enum.c
+++ clang/test/ExtractAPI/enum.c
@@ -30,6 +30,14 @@
   West
 };
 
+enum {
+  Constant = 1
+};
+
+enum {
+  OtherConstant = 2
+};
+
 //--- reference.output.json.in
 {
   "metadata": {
@@ -100,6 +108,16 @@
   "kind": "memberOf",
   "source": "c:@E@Direction@West",
   "target": "c:@E@Direction"
+},
+{
+  "kind": "memberOf",
+  "source": "c:@Ea@Constant@Constant",
+  "target": "c:@Ea@Constant"
+},
+{
+  "kind": "memberOf",
+  "source": "c:@Ea@OtherConstant@OtherConstant",
+  "target": "c:@Ea@OtherConstant"
 }
   ],
   "symbols": [
@@ -641,6 +659,182 @@
 "Direction",
 "West"
   ]
+},
+{
+  "accessLevel": "public",
+  "declarationFragments": [
+{
+  "kind": "keyword",
+  "spelling": "enum"
+},
+{
+  "kind": "text",
+  "spelling": ": "
+},
+{
+  "kind": "typeIdentifier",
+  "preciseIdentifier": "c:i",
+  "spelling": "unsigned int"
+}
+  ],
+  "identifier": {
+"interfaceLanguage": "c",
+"precise": "c:@Ea@Constant"
+  },
+  "kind": {
+"displayName": "Enumeration",
+"identifier": "c.enum"
+  },
+  "location": {
+"position": {
+  "character": 1,
+  "line": 17
+},
+"uri": "file://INPUT_DIR/input.h"
+  },
+  "names": {
+"navigator": [
+  {
+"kind": "identifier",
+"spelling": "(anonymous)"
+  }
+],
+"title": "(anonymous)"
+  },
+  "pathComponents": [
+"(anonymous)"
+  ]
+},
+{
+  "accessLevel": "public",
+  "declarationFragments": [
+{
+  "kind": "identifier",
+  "spelling": "Constant"
+}
+  ],
+  "identifier": {
+"interfaceLanguage": "c",
+"precise": "c:@Ea@Constant@Constant"
+  },
+  "kind": {
+"displayName": "Enumeration Case",
+"identifier": "c.enum.case"
+  },
+  "location": {
+"position": {
+  "character": 3,
+  "line": 18
+},
+"uri": "file://INPUT_DIR/input.h"
+  },
+  "names": {
+"navigator": [
+  {
+"kind": "identifier",
+"spelling": "Constant"
+  }
+],
+"subHeading": [
+  {
+"kind": "identifier",
+"spelling": "Constant"
+  }
+],
+"title": "Constant"
+  },
+  "pathComponents": [
+"(anonymous)",
+"Constant"
+  ]
+},
+{
+  "accessLevel": "public",
+  "declarationFragments": [
+{
+  "kind": "keyword",
+  "spelling": "enum"
+},
+{
+  "kind": "text",
+  "spelling": ": "
+},
+{
+  "kind": "typeIdentifier",
+  "preciseIdentifier": "c:i",
+  "spelling": "unsigned int"
+}
+  ],
+  "identifier": {
+"interfaceLanguage": "c",
+"precise": "c:@Ea@OtherConstant"
+  },
+  "kind": {
+"displayName": "Enumeration",
+"identifier": "c.enum"
+  },
+  "location": {
+"position": {
+  "character": 1,
+  "line": 21
+},
+"uri": "file://INPUT_DIR/input.h"
+  },
+  "names": {
+"navigator": [
+  {
+"kind": "identifier",
+"spelling": "(anonymous)"
+  }
+],
+"title": "(anonymous)"
+  },
+  "pathComponents": [
+"(anonymous)"
+  ]
+},
+{
+  "accessLevel": "public",
+  "declarationFragments": [
+{
+  "kind": "identifier",
+  "spelling": "OtherConstant"
+}
+  ],
+  "identifier": {
+"interfaceLanguage": "c",
+"precise": "c:@Ea@OtherConstant@OtherConstant"
+  },
+  "kind": {
+"displayName": "Enumeration Case",
+"identifier": "c.enum.case"
+  },
+  "location": {
+"position": {
+  "character": 3,
+  "line": 22
+},
+"uri": "file://INPUT_DIR/input.h"
+  },
+  "names": {
+"navigator": [
+  {
+"kind": "identifier",
+"spelling": "OtherConstant"
+  

[PATCH] D123547: [docs] Mention that we are in the process of removing the legacy PM for the optimization pipeline

2022-04-12 Thread Arthur Eubanks via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG9faab435a357: [docs] Mention that we are in the process of 
removing the legacy PM for the… (authored by aeubanks).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123547

Files:
  clang/include/clang/Driver/Options.td
  llvm/docs/NewPassManager.rst


Index: llvm/docs/NewPassManager.rst
===
--- llvm/docs/NewPassManager.rst
+++ llvm/docs/NewPassManager.rst
@@ -480,12 +480,9 @@
 the new PM, whereas the backend target-dependent code generation only works
 with the legacy PM.
 
-For the optimization pipeline, the new PM is the default PM. The legacy PM is
-available for the optimization pipeline by setting various compiler/linker
-flags, e.g. ``-flegacy-pass-manager`` for ``clang``.
-
-There will be efforts to deprecate and remove the legacy PM for the
-optimization pipeline in the future.
+For the optimization pipeline, the new PM is the default PM. Using the legacy 
PM
+for the optimization pipeline is deprecated and there are ongoing efforts to
+remove its usage.
 
 Some IR passes are considered part of the backend codegen pipeline even if
 they are LLVM IR passes (whereas all MIR passes are codegen passes). This
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -1937,8 +1937,8 @@
   Alias;
 defm legacy_pass_manager : BoolOption<"f", "legacy-pass-manager",
   CodeGenOpts<"LegacyPassManager">, DefaultFalse,
-  PosFlag,
-  NegFlag,
+  PosFlag,
+  NegFlag,
   BothFlags<[CC1Option]>>, Group;
 def fexperimental_new_pass_manager : Flag<["-"], 
"fexperimental-new-pass-manager">,
   Group, Flags<[CC1Option]>, Alias;


Index: llvm/docs/NewPassManager.rst
===
--- llvm/docs/NewPassManager.rst
+++ llvm/docs/NewPassManager.rst
@@ -480,12 +480,9 @@
 the new PM, whereas the backend target-dependent code generation only works
 with the legacy PM.
 
-For the optimization pipeline, the new PM is the default PM. The legacy PM is
-available for the optimization pipeline by setting various compiler/linker
-flags, e.g. ``-flegacy-pass-manager`` for ``clang``.
-
-There will be efforts to deprecate and remove the legacy PM for the
-optimization pipeline in the future.
+For the optimization pipeline, the new PM is the default PM. Using the legacy PM
+for the optimization pipeline is deprecated and there are ongoing efforts to
+remove its usage.
 
 Some IR passes are considered part of the backend codegen pipeline even if
 they are LLVM IR passes (whereas all MIR passes are codegen passes). This
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -1937,8 +1937,8 @@
   Alias;
 defm legacy_pass_manager : BoolOption<"f", "legacy-pass-manager",
   CodeGenOpts<"LegacyPassManager">, DefaultFalse,
-  PosFlag,
-  NegFlag,
+  PosFlag,
+  NegFlag,
   BothFlags<[CC1Option]>>, Group;
 def fexperimental_new_pass_manager : Flag<["-"], "fexperimental-new-pass-manager">,
   Group, Flags<[CC1Option]>, Alias;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 9faab43 - [docs] Mention that we are in the process of removing the legacy PM for the optimization pipeline

2022-04-12 Thread Arthur Eubanks via cfe-commits

Author: Arthur Eubanks
Date: 2022-04-12T10:47:58-07:00
New Revision: 9faab435a35720fd7c6b3aeafe22c5dfb29f36e0

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

LOG: [docs] Mention that we are in the process of removing the legacy PM for 
the optimization pipeline

And remove references to flags to turn it off.

Reviewed By: nikic, MaskRay

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

Added: 


Modified: 
clang/include/clang/Driver/Options.td
llvm/docs/NewPassManager.rst

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 27957b10925f7..322cc800f7525 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -1937,8 +1937,8 @@ def fexperimental_isel : Flag<["-"], 
"fexperimental-isel">, Group
   Alias;
 defm legacy_pass_manager : BoolOption<"f", "legacy-pass-manager",
   CodeGenOpts<"LegacyPassManager">, DefaultFalse,
-  PosFlag,
-  NegFlag,
+  PosFlag,
+  NegFlag,
   BothFlags<[CC1Option]>>, Group;
 def fexperimental_new_pass_manager : Flag<["-"], 
"fexperimental-new-pass-manager">,
   Group, Flags<[CC1Option]>, Alias;

diff  --git a/llvm/docs/NewPassManager.rst b/llvm/docs/NewPassManager.rst
index 58d5a26d84505..fd5536c2fd1cb 100644
--- a/llvm/docs/NewPassManager.rst
+++ b/llvm/docs/NewPassManager.rst
@@ -480,12 +480,9 @@ optimization pipeline (aka the middle-end) works with both 
the legacy PM and
 the new PM, whereas the backend target-dependent code generation only works
 with the legacy PM.
 
-For the optimization pipeline, the new PM is the default PM. The legacy PM is
-available for the optimization pipeline by setting various compiler/linker
-flags, e.g. ``-flegacy-pass-manager`` for ``clang``.
-
-There will be efforts to deprecate and remove the legacy PM for the
-optimization pipeline in the future.
+For the optimization pipeline, the new PM is the default PM. Using the legacy 
PM
+for the optimization pipeline is deprecated and there are ongoing efforts to
+remove its usage.
 
 Some IR passes are considered part of the backend codegen pipeline even if
 they are LLVM IR passes (whereas all MIR passes are codegen passes). This



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


[PATCH] D118259: [AArch64] Adjust aarch64 constrained intrinsics tests and un-XFAIL

2022-04-12 Thread Kevin P. Neal via Phabricator via cfe-commits
kpn accepted this revision.
kpn added a comment.
This revision is now accepted and ready to land.

I trust you on the instruction set changes. LGTM.


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

https://reviews.llvm.org/D118259

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


[PATCH] D118259: [AArch64] Adjust aarch64 constrained intrinsics tests and un-XFAIL

2022-04-12 Thread John Brawn via Phabricator via cfe-commits
john.brawn updated this revision to Diff 422285.
john.brawn retitled this revision from "[AArch64] Adjust 
aarch64-neon-intrinsics-constrained test and un-XFAIL" to "[AArch64] Adjust 
aarch64 constrained intrinsics tests and un-XFAIL".
john.brawn edited the summary of this revision.
john.brawn added a comment.

Also adjust aarch64-v8.2a-fp16-intrinsics-constrained.c in this patch (was 
previously done in   
D115620 ) and remove the checks of the 
generated asm.


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

https://reviews.llvm.org/D118259

Files:
  clang/test/CodeGen/aarch64-neon-intrinsics-constrained.c
  clang/test/CodeGen/aarch64-v8.2a-fp16-intrinsics-constrained.c

Index: clang/test/CodeGen/aarch64-v8.2a-fp16-intrinsics-constrained.c
===
--- clang/test/CodeGen/aarch64-v8.2a-fp16-intrinsics-constrained.c
+++ clang/test/CodeGen/aarch64-v8.2a-fp16-intrinsics-constrained.c
@@ -1,31 +1,19 @@
 // RUN: %clang_cc1 -triple arm64-none-linux-gnu -target-feature +fullfp16 \
 // RUN: -fallow-half-arguments-and-returns -S -disable-O0-optnone \
 // RUN: -emit-llvm -o - %s | opt -S -mem2reg \
-// RUN: | FileCheck --check-prefix=COMMON --check-prefix=COMMONIR --check-prefix=UNCONSTRAINED %s
+// RUN: | FileCheck --check-prefixes=COMMON,COMMONIR,UNCONSTRAINED %s
 // RUN: %clang_cc1 -triple arm64-none-linux-gnu -target-feature +fullfp16 \
 // RUN: -fallow-half-arguments-and-returns -S -disable-O0-optnone \
-// RUN: -ffp-exception-behavior=strict -emit-llvm -o - %s | opt -S -mem2reg \
-// RUN: | FileCheck --check-prefix=COMMON --check-prefix=COMMONIR --check-prefix=CONSTRAINED %s
-// RUN: %clang_cc1 -triple arm64-none-linux-gnu -target-feature +fullfp16 \
-// RUN: -fallow-half-arguments-and-returns -S -disable-O0-optnone -o - %s \
-// RUN: | FileCheck --check-prefix=COMMON --check-prefix=CHECK-ASM %s
-// RUN: %clang_cc1 -triple arm64-none-linux-gnu -target-feature +fullfp16 \
-// RUN: -ffp-exception-behavior=strict \
-// RUN: -fallow-half-arguments-and-returns -S -disable-O0-optnone -o - %s \
-// RUN: | FileCheck --check-prefix=COMMON --check-prefix=CHECK-ASM %s
+// RUN: -ffp-exception-behavior=strict -fexperimental-strict-floating-point -emit-llvm -o - %s | opt -S -mem2reg \
+// RUN: | FileCheck --check-prefixes=COMMON,COMMONIR,CONSTRAINED %s
 
 // REQUIRES: aarch64-registered-target
 
-// "Lowering of strict fp16 not yet implemented"
-// XFAIL: *
-
 #include 
 
 // COMMON-LABEL: test_vceqzh_f16
 // UNCONSTRAINED:  [[TMP1:%.*]] = fcmp oeq half %a, 0xH
 // CONSTRAINED:[[TMP1:%.*]] = call i1 @llvm.experimental.constrained.fcmp.f16(half %a, half 0xH, metadata !"oeq", metadata !"fpexcept.strict")
-// CHECK-ASM:  fcmp
-// CHECK-ASM:  cset {{w[0-9]+}}, eq
 // COMMONIR:   [[TMP2:%.*]] = sext i1 [[TMP1]] to i16
 // COMMONIR:   ret i16 [[TMP2]]
 uint16_t test_vceqzh_f16(float16_t a) {
@@ -34,9 +22,7 @@
 
 // COMMON-LABEL: test_vcgezh_f16
 // UNCONSTRAINED:  [[TMP1:%.*]] = fcmp oge half %a, 0xH
-// CONSTRAINED:[[TMP1:%.*]] = call i1 @llvm.experimental.constrained.fcmp.f16(half %a, half 0xH, metadata !"oge", metadata !"fpexcept.strict")
-// CHECK-ASM:  fcmp
-// CHECK-ASM:  cset {{w[0-9]+}}, ge
+// CONSTRAINED:[[TMP1:%.*]] = call i1 @llvm.experimental.constrained.fcmps.f16(half %a, half 0xH, metadata !"oge", metadata !"fpexcept.strict")
 // COMMONIR:   [[TMP2:%.*]] = sext i1 [[TMP1]] to i16
 // COMMONIR:   ret i16 [[TMP2]]
 uint16_t test_vcgezh_f16(float16_t a) {
@@ -45,9 +31,7 @@
 
 // COMMON-LABEL: test_vcgtzh_f16
 // UNCONSTRAINED:  [[TMP1:%.*]] = fcmp ogt half %a, 0xH
-// CONSTRAINED:[[TMP1:%.*]] = call i1 @llvm.experimental.constrained.fcmp.f16(half %a, half 0xH, metadata !"ogt", metadata !"fpexcept.strict")
-// CHECK-ASM:  fcmp
-// CHECK-ASM:  cset {{w[0-9]+}}, gt
+// CONSTRAINED:[[TMP1:%.*]] = call i1 @llvm.experimental.constrained.fcmps.f16(half %a, half 0xH, metadata !"ogt", metadata !"fpexcept.strict")
 // COMMONIR:   [[TMP2:%.*]] = sext i1 [[TMP1]] to i16
 // COMMONIR:   ret i16 [[TMP2]]
 uint16_t test_vcgtzh_f16(float16_t a) {
@@ -56,9 +40,7 @@
 
 // COMMON-LABEL: test_vclezh_f16
 // UNCONSTRAINED:  [[TMP1:%.*]] = fcmp ole half %a, 0xH
-// CONSTRAINED:[[TMP1:%.*]] = call i1 @llvm.experimental.constrained.fcmp.f16(half %a, half 0xH, metadata !"ole", metadata !"fpexcept.strict")
-// CHECK-ASM:  fcmp
-// CHECK-ASM:  cset {{w[0-9]+}}, ls
+// CONSTRAINED:[[TMP1:%.*]] = call i1 @llvm.experimental.constrained.fcmps.f16(half %a, half 0xH, metadata !"ole", metadata !"fpexcept.strict")
 // COMMONIR:   [[TMP2:%.*]] = sext i1 [[TMP1]] to i16
 // COMMONIR:   ret i16 [[TMP2]]
 uint16_t test_vclezh_f16(float16_t a) {
@@ -67,9 +49,7 @@
 
 // COMMON-LABEL: test_vcltzh_f16
 // UNCONSTRAINED:  [[TMP1:%.*]] = fcmp olt half %a, 0xH
-// CONSTRAINED:[[TMP1:%.*]] = call i1 @llvm.experi

[PATCH] D119136: [clang] Implement Change scope of lambda trailing-return-type

2022-04-12 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin updated this revision to Diff 422282.
cor3ntin added a comment.

After offline discussion with Aaron, we decided that "can not appear here" was a
sufficient diagnostic, so I have implemented that.
A better solution would be to track which captures fail, and collect the 
diagnostics
to emit them after the parameter list, but this seem to add a lot of complexity
for something few people are likely to encounter.

- Add tests
- A diagnostic for use before capture  could be emited twice when parsing

a template parameter list, this was fixed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119136

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/AST/DeclCXX.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Scope.h
  clang/include/clang/Sema/ScopeInfo.h
  clang/include/clang/Sema/Sema.h
  clang/lib/Parse/ParseExprCXX.cpp
  clang/lib/Sema/Scope.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaCXXScopeSpec.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaLambda.cpp
  clang/lib/Sema/TreeTransform.h
  clang/test/CXX/expr/expr.prim/expr.prim.lambda/p11-1y.cpp
  clang/test/SemaCXX/lambda-capture-type-deduction.cpp
  clang/test/SemaCXX/warn-shadow-in-lambdas.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -1356,7 +1356,7 @@
 
   Change scope of lambda trailing-return-type
   https://wg21.link/P2036R3";>P2036R3
-  No
+  Clang 15
 
 
   Multidimensional subscript operator
Index: clang/test/SemaCXX/warn-shadow-in-lambdas.cpp
===
--- clang/test/SemaCXX/warn-shadow-in-lambdas.cpp
+++ clang/test/SemaCXX/warn-shadow-in-lambdas.cpp
@@ -95,7 +95,7 @@
 #ifdef AVOID
   auto l4 = [var = param] (int param) { ; }; // no warning
 #else
-  auto l4 = [var = param] (int param) { ; }; // expected-warning {{declaration shadows a local variable}}
+  auto l4 = [var = param](int param) { ; }; // expected-warning 2{{declaration shadows a local variable}}
 #endif
 
   // Make sure that inner lambdas work as well.
Index: clang/test/SemaCXX/lambda-capture-type-deduction.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/lambda-capture-type-deduction.cpp
@@ -0,0 +1,156 @@
+// RUN: %clang_cc1 -std=c++2b -verify -fsyntax-only %s
+
+template 
+constexpr bool is_same = false;
+
+template 
+constexpr bool is_same = true;
+
+void f() {
+
+  int y;
+
+  static_assert(is_same decltype((x)) { return x; }())>);
+
+  static_assert(is_same decltype((x)) { return x; }())>);
+
+  static_assert(is_same decltype((y)) { return y; }())>);
+
+  static_assert(is_same decltype((y)) { return y; }())>);
+
+  static_assert(is_same decltype((y)) { return y; }())>);
+
+  static_assert(is_same decltype((y)) { return y; }())>);
+
+  auto ref = [&x = y](
+ decltype([&](decltype(x)) { return 0; }) y) {
+return x;
+  };
+}
+
+void test_noexcept() {
+
+  int y;
+
+  static_assert(noexcept([x = 1] noexcept(is_same) {}()));
+  static_assert(noexcept([x = 1] mutable noexcept(is_same) {}()));
+  static_assert(noexcept([y] noexcept(is_same) {}()));
+  static_assert(noexcept([y] mutable noexcept(is_same) {}()));
+  static_assert(noexcept([=] noexcept(is_same) {}()));
+  static_assert(noexcept([=] mutable noexcept(is_same) {}()));
+  static_assert(noexcept([&] noexcept(is_same) {}()));
+  static_assert(noexcept([&] mutable noexcept(is_same) {}()));
+
+  static_assert(noexcept([&] mutable noexcept(!is_same) {}())); //expected-error {{static_assert failed due}}
+}
+
+void test_requires() {
+
+  int x;
+
+  [x = 1]() requires is_same {}
+  ();
+  [x = 1]() mutable requires is_same {}
+  ();
+  [x]() requires is_same {}
+  ();
+  [x]() mutable requires is_same {}
+  ();
+  [=]() requires is_same {}
+  ();
+  [=]() mutable requires is_same {}
+  ();
+  [&]() requires is_same {}
+  ();
+  [&]() mutable requires is_same {}
+  ();
+  [&x]() requires is_same {}
+  ();
+  [&x]() mutable requires is_same {}
+  ();
+
+  [x = 1]() requires is_same {} (); //expected-error {{no matching function for call to object of type}} \
+   // expected-note {{candidate function not viable}} \
+   // expected-note {{'is_same' evaluated to false}}
+  [x = 1]() mutable requires is_same {} (); // expected-error {{no matching function for call to object of type}} \
+ // expected-note {{candidate function not viable}} \
+ // expected-note {{'is_same' eva

  1   2   >