date:20210730

[clang] a9d1970 - Revert "[clang][cache] Update Fuchsia-stage2.cmake to create hwasan multilibs"

2021-07-30 Thread Petr Hosek via cfe-commits


Author: Petr Hosek
Date: 2021-07-30T18:56:51-07:00
New Revision: a9d1970384aa3908adbf6f50f110c375def58947

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

LOG: Revert "[clang][cache] Update Fuchsia-stage2.cmake to create hwasan 
multilibs"

This reverts commit bb438f6cbfc08eaa2cd9124a0ad581dd29f819b4 since
it broke our Windows builders and we need more time to investigate
the issue.

Added: 


Modified: 
clang/cmake/caches/Fuchsia-stage2.cmake

Removed: 




diff  --git a/clang/cmake/caches/Fuchsia-stage2.cmake 
b/clang/cmake/caches/Fuchsia-stage2.cmake
index 8c7518d7da31..aa45c1549340 100644
--- a/clang/cmake/caches/Fuchsia-stage2.cmake
+++ b/clang/cmake/caches/Fuchsia-stage2.cmake
@@ -226,30 +226,11 @@ if(FUCHSIA_SDK)
 list(APPEND RUNTIME_BUILD_ID_LINK "${target}")
   endforeach()
 
-  # HWAsan
-  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan_LLVM_BUILD_COMPILER_RT OFF CACHE 
BOOL "")
-  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan_LLVM_USE_SANITIZER "HWAddress" 
CACHE STRING "")
-  
set(RUNTIMES_aarch64-unknown-fuchsia+hwasan_LIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS
 OFF CACHE BOOL "")
-  
set(RUNTIMES_aarch64-unknown-fuchsia+hwasan_LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS
 OFF CACHE BOOL "")
-  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan_CMAKE_CXX_FLAGS 
"${RUNTIMES_aarch64-unknown-fuchsia+hwasan_CMAKE_CXX_FLAGS} -mllvm 
--hwasan-globals=0" CACHE STRING "")
-
-  # HWASan+noexcept
-  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_LLVM_BUILD_COMPILER_RT 
OFF CACHE BOOL "")
-  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_LLVM_USE_SANITIZER 
"HWAddress" CACHE STRING "")
-  
set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_LIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS
 OFF CACHE BOOL "")
-  
set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS
 OFF CACHE BOOL "")
-  
set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_LIBCXXABI_ENABLE_EXCEPTIONS
 OFF CACHE BOOL "")
-  
set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_LIBCXX_ENABLE_EXCEPTIONS 
OFF CACHE BOOL "")
-  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_CMAKE_CXX_FLAGS 
"${RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_CMAKE_CXX_FLAGS} -mllvm 
--hwasan-globals=0" CACHE STRING "")
-
-  set(LLVM_RUNTIME_MULTILIBS 
"asan;noexcept;compat;asan+noexcept;hwasan;hwasan+noexcept" CACHE STRING "")
-
+  set(LLVM_RUNTIME_MULTILIBS "asan;noexcept;compat;asan+noexcept" CACHE STRING 
"")
   set(LLVM_RUNTIME_MULTILIB_asan_TARGETS 
"x86_64-unknown-fuchsia;aarch64-unknown-fuchsia" CACHE STRING "")
   set(LLVM_RUNTIME_MULTILIB_noexcept_TARGETS 
"x86_64-unknown-fuchsia;aarch64-unknown-fuchsia" CACHE STRING "")
   set(LLVM_RUNTIME_MULTILIB_compat_TARGETS 
"x86_64-unknown-fuchsia;aarch64-unknown-fuchsia" CACHE STRING "")
   set(LLVM_RUNTIME_MULTILIB_asan+noexcept_TARGETS 
"x86_64-unknown-fuchsia;aarch64-unknown-fuchsia" CACHE STRING "")
-  set(LLVM_RUNTIME_MULTILIB_hwasan_TARGETS "aarch64-unknown-fuchsia" CACHE 
STRING "")
-  set(LLVM_RUNTIME_MULTILIB_hwasan+noexcept_TARGETS "aarch64-unknown-fuchsia" 
CACHE STRING "")
 endif()
 
 set(LLVM_BUILTIN_TARGETS "${BUILTIN_TARGETS}" CACHE STRING "")



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

[PATCH] D99364: [clang][cache] Update Fuchsia-stage2.cmake to create hwasan multilibs

2021-07-30 Thread Petr Hosek via Phabricator via cfe-commits

phosek added inline comments.



Comment at: clang/cmake/caches/Fuchsia-stage2.cmake:234
+  
set(RUNTIMES_aarch64-unknown-fuchsia+hwasan_LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS
 OFF CACHE BOOL "")
+  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan_CMAKE_CXX_FLAGS 
"${RUNTIMES_aarch64-unknown-fuchsia+hwasan_CMAKE_CXX_FLAGS} -mllvm 
--hwasan-globals=0" CACHE STRING "")
+

I missed this earlier, but this isn't going to work since the variable isn't 
populated, you're going to need 
`${FUCHSIA_aarch64-unknown-fuchsia+hwasan_COMPILER_FLAGS}` here.



Comment at: clang/cmake/caches/Fuchsia-stage2.cmake:234
+  
set(RUNTIMES_aarch64-unknown-fuchsia+hwasan_LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS
 OFF CACHE BOOL "")
+  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan_CMAKE_CXX_FLAGS 
"${RUNTIMES_aarch64-unknown-fuchsia+hwasan_CMAKE_CXX_FLAGS} -mllvm 
--hwasan-globals=0" CACHE STRING "")
+

phosek wrote:
> I missed this earlier, but this isn't going to work since the variable isn't 
> populated, you're going to need 
> `${FUCHSIA_aarch64-unknown-fuchsia+hwasan_COMPILER_FLAGS}` here.
Could we set this in the backend when targeting Fuchsia and avoid the having to 
pass the flag manually?



Comment at: clang/cmake/caches/Fuchsia-stage2.cmake:243
+  
set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_LIBCXX_ENABLE_EXCEPTIONS 
OFF CACHE BOOL "")
+  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_CMAKE_CXX_FLAGS 
"${RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_CMAKE_CXX_FLAGS} -mllvm 
--hwasan-globals=0" CACHE STRING "")
+

Ditto


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99364

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

[PATCH] D106755: Extended format string checking to wprintf/wscanf

2021-07-30 Thread Marcus Johnson via Phabricator via cfe-commits

MarcusJohnson91 updated this revision to Diff 363245.
MarcusJohnson91 added a comment.

Rebased


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

https://reviews.llvm.org/D106755

Files:
  clang-tools-extra/clang-tidy/boost/UseToStringCheck.cpp
  clang-tools-extra/clang-tidy/misc/ThrowByValueCatchByReferenceCheck.cpp
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/Expr.h
  clang/include/clang/AST/FormatString.h
  clang/include/clang/AST/Type.h
  clang/include/clang/ASTMatchers/ASTMatchers.h
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/AST/Expr.cpp
  clang/lib/AST/ExprCXX.cpp
  clang/lib/AST/OSLog.cpp
  clang/lib/AST/TemplateBase.cpp
  clang/lib/AST/Type.cpp
  clang/lib/Lex/LiteralSupport.cpp
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprObjC.cpp
  clang/lib/Sema/SemaFixItUtils.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/StaticAnalyzer/Checkers/CheckSecuritySyntaxOnly.cpp
  clang/test/Sema/format-strings-c90.c
  clang/test/Sema/format-strings-darwin.c
  clang/test/Sema/format-strings-int-typedefs.c
  clang/test/Sema/format-strings-ms.c
  clang/test/Sema/format-strings-non-iso.c
  clang/test/Sema/format-strings-pedantic.c
  clang/test/Sema/format-strings-scanf.c
  clang/test/Sema/string-plus-char.c
  clang/test/SemaCXX/format-strings-0x.cpp
  clang/test/SemaCXX/format-strings.cpp

Index: clang/test/SemaCXX/format-strings.cpp
===
--- clang/test/SemaCXX/format-strings.cpp
+++ clang/test/SemaCXX/format-strings.cpp
@@ -8,6 +8,9 @@
 extern int scanf(const char *restrict, ...);
 extern int printf(const char *restrict, ...);
 extern int vprintf(const char *restrict, va_list);
+extern int wscanf(const wchar_t *restrict, ...);
+extern int wprintf(const wchar_t *restrict, ...);
+extern int vwprintf(const wchar_t *restrict, va_list);
 }
 
 void f(char **sp, float *fp) {
@@ -18,12 +21,23 @@
   // expected-warning@-4 {{format specifies type 'float *' but the argument has type 'char **'}}
 #endif
 
+  scanf("%as", sp);
+#if __cplusplus <= 199711L
+  // expected-warning@-2 {{'a' length modifier is not supported by ISO C}}
+#else
+  // expected-warning@-4 {{format specifies type 'float *' but the argument has type 'wchar_t **'}}
+#endif
+
   printf("%a", 1.0);
   scanf("%afoobar", fp);
+
+  wprintf("%a", 1.0);
+  wscanf("%afoobar", fp);
 }
 
 void g() {
   printf("%ls", "foo"); // expected-warning{{format specifies type 'wchar_t *' but the argument has type 'const char *'}}
+  wprintf("%ls", "foo"); // expected-warning{{format specifies type 'wchar_t *' but the argument has type 'const char *'}}
 }
 
 // Test that we properly handle format_idx on C++ members.
Index: clang/test/SemaCXX/format-strings-0x.cpp
===
--- clang/test/SemaCXX/format-strings-0x.cpp
+++ clang/test/SemaCXX/format-strings-0x.cpp
@@ -3,33 +3,54 @@
 extern "C" {
 extern int scanf(const char *restrict, ...);
 extern int printf(const char *restrict, ...);
+extern int wscanf(const wchar_t *restrict, ...);
+extern int wprintf(const wchar_t *restrict, ...);
 }
 
 void f(char **sp, float *fp) {
   scanf("%as", sp); // expected-warning{{format specifies type 'float *' but the argument has type 'char **'}}
+  wscanf("%as", sp); // expected-warning{{format specifies type 'float *' but the argument has type 'char **'}}
 
   printf("%p", sp); // expected-warning{{format specifies type 'void *' but the argument has type 'char **'}}
+  wprintf("%p", sp); // expected-warning{{format specifies type 'void *' but the argument has type 'char **'}}
   scanf("%p", sp);  // expected-warning{{format specifies type 'void **' but the argument has type 'char **'}}
+  wscanf("%p", sp); // expected-warning{{format specifies type 'void **' but the argument has type 'char **'}}
 
   printf("%a", 1.0);
   scanf("%afoobar", fp);
+  wprintf(L"%a", 1.0);
+  wscanf(L"%afoobar", fp);
   printf(nullptr);
   printf(*sp); // expected-warning {{not a string literal}}
   // expected-note@-1{{treat the string as an argument to avoid this}}
+  wprintf(*sp); // expected-warning {{not a string literal}}
+  // expected-note@-1{{treat the string as an argument to avoid this}}
 
   // PR13099
   printf(
 R"foobar(%)foobar"
 R"bazquux(d)bazquux" // expected-warning {{more '%' conversions than data arguments}}
 R"xyzzy()xyzzy");
+  wprintf(
+  LR"foobar(%)foobar"
+  LR"bazquux(d)bazquux" // expected-warning {{more '%' conversions than data arguments}}
+  LR"xyzzy()xyzzy");
 
   printf(u8"this is %d test", 0); // ok
+  wprintf(L"this is %d test", 0); // ok
   printf(u8R"foo(
   \u1234\U0010fffe
   %d)foo" // expected-warning {{more '%' conversions than data arguments}}
   );
+  wprintf(LR"foo(
+

[PATCH] D106756: Added l16/l32 length modifiers for char16_t/char32_t

2021-07-30 Thread Marcus Johnson via Phabricator via cfe-commits

MarcusJohnson91 updated this revision to Diff 363244.
MarcusJohnson91 added a comment.

Rebased on Main


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

https://reviews.llvm.org/D106756

Files:
  clang/include/clang/AST/FormatString.h
  clang/lib/AST/FormatString.cpp
  clang/test/Sema/format-strings-int-typedefs.c
  clang/test/SemaCXX/format-strings.cpp

Index: clang/test/SemaCXX/format-strings.cpp
===
--- clang/test/SemaCXX/format-strings.cpp
+++ clang/test/SemaCXX/format-strings.cpp
@@ -24,6 +24,8 @@
 
 void g() {
   printf("%ls", "foo"); // expected-warning{{format specifies type 'wchar_t *' but the argument has type 'const char *'}}
+  printf("%l16s", "foo"); // expected-warning{{format specifies type 'char16_t *' but the argument has type 'const char *'}}
+  printf("%l32s", "foo"); // expected-warning{{format specifies type 'char32_t *' but the argument has type 'const char *'}}
 }
 
 // Test that we properly handle format_idx on C++ members.
Index: clang/test/Sema/format-strings-int-typedefs.c
===
--- clang/test/Sema/format-strings-int-typedefs.c
+++ clang/test/Sema/format-strings-int-typedefs.c
@@ -10,18 +10,35 @@
   printf("%td", 42.0); // expected-warning {{format specifies type 'ptrdiff_t' (aka 'int')}}
   printf("%lc", 42.0); // expected-warning {{format specifies type 'wint_t' (aka 'int')}}
   printf("%ls", 42.0); // expected-warning {{format specifies type 'wchar_t *' (aka 'int *')}}
+  printf("%l16c", 42.0); // expected-warning {{format specifies type 'char16_t' (aka 'int')}}
+  printf("%l16s", 42.0); // expected-warning {{format specifies type 'char16_t *' (aka 'int *')}}
+  printf("%l32c", 42.0); // expected-warning {{format specifies type 'char32_t' (aka 'int')}}
+  printf("%l32s", 42.0); // expected-warning {{format specifies type 'char32_t *' (aka 'int *')}}
   printf("%S", 42.0);  // expected-warning {{format specifies type 'wchar_t *' (aka 'int *')}}
   printf("%C", 42.0);  // expected-warning {{format specifies type 'wchar_t' (aka 'int')}}
 
+  wprintf(L"%l16c", 42.0); // expected-warning {{format specifies type 'char16_t' (aka 'short')}}
+  wprintf(L"%l16s", 42.0); // expected-warning {{format specifies type 'char16_t *' (aka 'short *')}}
+  wprintf(L"%l32c", 42.0); // expected-warning {{format specifies type 'char32_t' (aka 'int')}}
+  wprintf(L"%l32s", 42.0); // expected-warning {{format specifies type 'char32_t *' (aka 'int *')}}
+
   scanf("%jd", 0); // expected-warning {{format specifies type 'intmax_t *' (aka 'long long *')}}
   scanf("%ju", 0); // expected-warning {{format specifies type 'uintmax_t *' (aka 'unsigned long long *')}}
   scanf("%zu", 0); // expected-warning {{format specifies type 'size_t *' (aka 'unsigned long *')}}
   scanf("%td", 0); // expected-warning {{format specifies type 'ptrdiff_t *' (aka 'int *')}}
   scanf("%lc", 0); // expected-warning {{format specifies type 'wchar_t *' (aka 'int *')}}
   scanf("%ls", 0); // expected-warning {{format specifies type 'wchar_t *' (aka 'int *')}}
+  scanf("%l16c", 0); // expected-warning {{format specifies type 'char16_t *' (aka 'int *')}}
+  scanf("%l16s", 0); // expected-warning {{format specifies type 'char16_t *' (aka 'int *')}}
+  scanf("%l32c", 0); // expected-warning {{format specifies type 'char32_t *' (aka 'int *')}}
+  scanf("%l32s", 0); // expected-warning {{format specifies type 'char32_t *' (aka 'int *')}}
   scanf("%S",  0);  // expected-warning {{format specifies type 'wchar_t *' (aka 'int *')}}
   scanf("%C",  0);  // expected-warning {{format specifies type 'wchar_t *' (aka 'int *')}}
 
+  wscanf("%l16c", 0); // expected-warning {{format specifies type 'char16_t *' (aka 'int *')}}
+  wscanf("%l16s", 0); // expected-warning {{format specifies type 'char16_t *' (aka 'int *')}}
+  wscanf("%l32c", 0); // expected-warning {{format specifies type 'char32_t *' (aka 'int *')}}
+  wscanf("%l32s", 0); // expected-warning {{format specifies type 'char32_t *' (aka 'int *')}}
 
   // typedef size_t et al. to something crazy.
   typedef void *size_t;
Index: clang/lib/AST/FormatString.cpp
===
--- clang/lib/AST/FormatString.cpp
+++ clang/lib/AST/FormatString.cpp
@@ -520,6 +520,12 @@
 case WCStrTy:
   Res = C.getPointerType(C.getWideCharType());
   break;
+case Char16Ty:
+  Res = C.getPointerType(C.getChar16Type());
+  break;
+case Char32Ty:
+  Res = C.getPointerType(C.getChar32Type());
+  break;
 case ObjCPointerTy:
   Res = C.ObjCBuiltinIdTy;
   break;
@@ -607,6 +613,10 @@
 return "m";
   case AsWide:
 return "w";
+  case AsUTF16:
+return "l16";
+  case AsUTF32:
+return "l32";
   case None:
 return "";
   }
@@ -860,6 +870,17 @@
 default:
   return false;
   }
+case LengthModifier::AsUTF16:
+case

[PATCH] D106753: ConvertUTF: Created wrapper convertUTF32ToUTF8String

2021-07-30 Thread Eli Friedman via Phabricator via cfe-commits

efriedma added a comment.

If you're having trouble making Arcanist work correctly, you can always just 
upload "git diff" or "git show" output at 
https://reviews.llvm.org/differential/diff/create/ .


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

https://reviews.llvm.org/D106753

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

[PATCH] D104601: [Preprocessor] Implement -fminimize-whitespace.

2021-07-30 Thread Alexander Kornienko via Phabricator via cfe-commits

alexfh added a comment.

In D104601#2916973 , @Meinersbur 
wrote:

> @romanovvlad This is due to -fms-extensions. It Expands `__Pragma` to 
> `#pragma` instead of keeping it a `__Pragma`. This is a one-line fix.
>
> @alexfh This was fixed by D106924 

You're right. It turns out that my comment 
https://reviews.llvm.org/D104601#2915122 was a mistake and 
c6b0b16c0f55c34f4eaa05184815bbbe97f4b750 
 actually 
fixes this particular issue.

> I would suggest to not revert. Will upload a patch for `-fms-extensions` 
> after some cleanup.

I'm running more thorough testing of clang with the 
c6b0b16c0f55c34f4eaa05184815bbbe97f4b750 
 commit to 
ensure we're not missing anything else here.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104601

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

[PATCH] D107139: [RISCV] Rename vector inline constraint from 'v' to 'vr' and 'vm' in IR.

2021-07-30 Thread Craig Topper via Phabricator via cfe-commits

craig.topper accepted this revision.
craig.topper 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/D107139/new/

https://reviews.llvm.org/D107139

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

[PATCH] D107155: [clang][deps] Substitute clang-scan-deps executable in lit tests

2021-07-30 Thread David Blaikie via Phabricator via cfe-commits

dblaikie added a comment.

In D107155#2917400 , @dexonsmith 
wrote:

> In D107155#2916664 , @dblaikie 
> wrote:
>
>> Hmm, don't we have some other substitution feature that avoids the need to 
>> add the %? (like, I think LLVM's tests don't usually use the % for many tool 
>> names - but they still make for good copy/pastable command lines, if I'm not 
>> mistaken?)
>
> I think that'd be adding clang-scan-deps somehow to the `tools` variable in 
> clang/test/lit.cfg.py:
>  https://github.com/llvm/llvm-project/blob/main/clang/test/lit.cfg.py#L59
> (which will then call `add_tool_substitutions` at 
> https://github.com/llvm/llvm-project/blob/main/clang/test/lit.cfg.py#L111)

Hmm, fair enough. Yeah - guess all the actual clang tests use %clang, 
%clang_cc1 - so I guess there's precedent in both directions. I wonder what the 
"norm" is (which tools use one approach, which use the other). But anyway, no 
objection in this case given the precedent. Though it does sound like this is a 
"tool" like the other cases, so maybe should be handled that way - up to you 
folks, though.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107155

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

[PATCH] D107139: [RISCV] Rename vector inline constraint from 'v' to 'vr' and 'vm' in IR.

2021-07-30 Thread Hsiangkai Wang via Phabricator via cfe-commits

HsiangKai updated this revision to Diff 363241.
HsiangKai added a comment.

Use '^' instead of '@2'.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107139

Files:
  clang/lib/Basic/Targets/RISCV.cpp
  clang/test/CodeGen/RISCV/riscv-inline-asm-rvv.c
  llvm/lib/Target/RISCV/RISCVISelLowering.cpp
  llvm/test/CodeGen/RISCV/rvv/inline-asm.ll

Index: llvm/test/CodeGen/RISCV/rvv/inline-asm.ll
===
--- llvm/test/CodeGen/RISCV/rvv/inline-asm.ll
+++ llvm/test/CodeGen/RISCV/rvv/inline-asm.ll
@@ -10,7 +10,7 @@
 ; CHECK-NEXT:#NO_APP
 ; CHECK-NEXT:ret
 entry:
-  %0 = tail call  asm "vmand.mm $0, $1, $2", "=v,v,v"( %in,  %in2)
+  %0 = tail call  asm "vmand.mm $0, $1, $2", "=^vm,^vm,^vm"( %in,  %in2)
   ret  %0
 }
 
@@ -22,7 +22,7 @@
 ; CHECK-NEXT:#NO_APP
 ; CHECK-NEXT:ret
 entry:
-  %0 = tail call  asm "vmand.mm $0, $1, $2", "=v,v,v"( %in,  %in2)
+  %0 = tail call  asm "vmand.mm $0, $1, $2", "=^vm,^vm,^vm"( %in,  %in2)
   ret  %0
 }
 
@@ -34,7 +34,7 @@
 ; CHECK-NEXT:#NO_APP
 ; CHECK-NEXT:ret
 entry:
-  %0 = tail call  asm "vmand.mm $0, $1, $2", "=v,v,v"( %in,  %in2)
+  %0 = tail call  asm "vmand.mm $0, $1, $2", "=^vm,^vm,^vm"( %in,  %in2)
   ret  %0
 }
 
@@ -46,7 +46,7 @@
 ; CHECK-NEXT:#NO_APP
 ; CHECK-NEXT:ret
 entry:
-  %0 = tail call  asm "vmand.mm $0, $1, $2", "=v,v,v"( %in,  %in2)
+  %0 = tail call  asm "vmand.mm $0, $1, $2", "=^vm,^vm,^vm"( %in,  %in2)
   ret  %0
 }
 
@@ -58,7 +58,7 @@
 ; CHECK-NEXT:#NO_APP
 ; CHECK-NEXT:ret
 entry:
-  %0 = tail call  asm "vmand.mm $0, $1, $2", "=v,v,v"( %in,  %in2)
+  %0 = tail call  asm "vmand.mm $0, $1, $2", "=^vm,^vm,^vm"( %in,  %in2)
   ret  %0
 }
 
@@ -70,7 +70,7 @@
 ; CHECK-NEXT:#NO_APP
 ; CHECK-NEXT:ret
 entry:
-  %0 = tail call  asm "vmand.mm $0, $1, $2", "=v,v,v"( %in,  %in2)
+  %0 = tail call  asm "vmand.mm $0, $1, $2", "=^vm,^vm,^vm"( %in,  %in2)
   ret  %0
 }
 
@@ -82,7 +82,7 @@
 ; CHECK-NEXT:#NO_APP
 ; CHECK-NEXT:ret
 entry:
-  %0 = tail call  asm "vmand.mm $0, $1, $2", "=v,v,v"( %in,  %in2)
+  %0 = tail call  asm "vmand.mm $0, $1, $2", "=^vm,^vm,^vm"( %in,  %in2)
   ret  %0
 }
 
@@ -94,7 +94,7 @@
 ; CHECK-NEXT:#NO_APP
 ; CHECK-NEXT:ret
 entry:
-  %0 = tail call  asm "vadd.vv $0, $1, $2", "=v,v,v"( %in,  %in2)
+  %0 = tail call  asm "vadd.vv $0, $1, $2", "=^vr,^vr,^vr"( %in,  %in2)
   ret  %0
 }
 
@@ -106,7 +106,7 @@
 ; CHECK-NEXT:#NO_APP
 ; CHECK-NEXT:ret
 entry:
-  %0 = tail call  asm "vadd.vv $0, $1, $2", "=v,v,v"( %in,  %in2)
+  %0 = tail call  asm "vadd.vv $0, $1, $2", "=^vr,^vr,^vr"( %in,  %in2)
   ret  %0
 }
 
@@ -118,7 +118,7 @@
 ; CHECK-NEXT:#NO_APP
 ; CHECK-NEXT:ret
 entry:
-  %0 = tail call  asm "vadd.vv $0, $1, $2", "=v,v,v"( %in,  %in2)
+  %0 = tail call  asm "vadd.vv $0, $1, $2", "=^vr,^vr,^vr"( %in,  %in2)
   ret  %0
 }
 
@@ -130,7 +130,7 @@
 ; CHECK-NEXT:#NO_APP
 ; CHECK-NEXT:ret
 entry:
-  %0 = tail call  asm "vadd.vv $0, $1, $2", "=v,v,v"( %in,  %in2)
+  %0 = tail call  asm "vadd.vv $0, $1, $2", "=^vr,^vr,^vr"( %in,  %in2)
   ret  %0
 }
 
@@ -142,7 +142,7 @@
 ; CHECK-NEXT:#NO_APP
 ; CHECK-NEXT:ret
 entry:
-  %0 = tail call  asm "vadd.vv $0, $1, $2", "=v,v,v"( %in,  %in2)
+  %0 = tail call  asm "vadd.vv $0, $1, $2", "=^vr,^vr,^vr"( %in,  %in2)
   ret  %0
 }
 
@@ -154,7 +154,7 @@
 ; CHECK-NEXT:#NO_APP
 ; CHECK-NEXT:ret
 entry:
-  %0 = tail call  asm "vadd.vv $0, $1, $2", "=v,v,v"( %in,  %in2)
+  %0 = tail call  asm "vadd.vv $0, $1, $2", "=^vr,^vr,^vr"( %in,  %in2)
   ret  %0
 }
 
@@ -166,7 +166,7 @@
 ; CHECK-NEXT:#NO_APP
 ; CHECK-NEXT:ret
 entry:
-  %0 = tail call  asm "vadd.vv $0, $1, $2", "=v,v,v"( %in,  %in2)
+  %0 = tail call  asm "vadd.vv $0, $1, $2", "=^vr,^vr,^vr"( %in,  %in2)
   ret  %0
 }
 
@@ -178,7 +178,7 @@
 ; CHECK-NEXT:#NO_APP
 ; CHECK-NEXT:ret
 entry:
-  %0 = tail call  asm "vadd.vv $0, $1, $2", "=v,v,v"( %in,  %in2)
+  %0 = tail call  asm "vadd.vv $0, $1, $2", "=^vr,^vr,^vr"( %in,  %in2)
   ret  %0
 }
 
@@ -190,7 +190,7 @@
 ; CHECK-NEXT:#NO_APP
 ; CHECK-NEXT:ret
 entry:
-  %0 = tail call  asm "vadd.vv $0, $1, $2", "=v,v,v"( %in,  %in2)
+  %0 = tail call  asm "vadd.vv $0, $1, $2", "=^vr,^vr,^vr"( %in,  %in2)
   ret  %0
 }
 
@@ -202,7 +202,7 @@
 ; CHECK-NEXT:#NO_APP
 ; CHECK-NEXT:ret
 entry:
-  %0 = tail call  asm "vadd.vv $0, $1, $2", "=v,v,v"( %in,  %in2)
+  %0 = tail call  asm "vadd.vv $0, $1, $2", "=^vr,^vr,^vr"( %in,  %in2)
   ret  %0
 }
 
@@ -214,7 +214,7 @@
 ; CHECK-NEXT:#NO_APP
 ; CHECK-NEXT:ret
 entry:
-  %0 = tail call  asm "vadd.vv $0, $1, $2", "=v,v,v"( %in,  %in2)
+  %0 = tail call  asm "vadd.vv $0, $1, $2", "=^vr,^vr,^vr"( %in,  %in2)
   ret  %0
 }
 
@@ -226,7 +226,7 @@
 ; CHECK-NEXT:#NO_APP
 ; CHECK-NEXT:ret
 entry:
-  %0 = tail call  asm "vadd.vv $0, $1, $2", "=v,v,v"( %in,  %in2)
+  %0 = tail call  asm "vadd.vv $0, $1, $2",

[PATCH] D107078: [analyzer] Catch leaking stack addresses via stack variables

2021-07-30 Thread Artem Dergachev via Phabricator via cfe-commits

NoQ added a comment.

Y'all writing really good patches lately.

The updates on the C++ tests look spot on to me. I'm not sure if these tests 
contain any actual UB but the checker was anyway designed to be a bit more 
aggressive than that and that's exactly the kind of stuff we wanted it to warn 
us about. And even if it turns out to have been a bad idea from the start, 
that's a separate story.

I'll have some bikeshedding about warning and note text but overall I really 
like it.




Comment at: clang/lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp:397-398
+   Ctx.getLocationContext());
+  Report->addNote("The temporary object gets destroyed at the end of the "
+  "full expression",
+  L);

This is part of the path, right? We're reporting these bugs at 
`checkEndFunction` rather than at the store site so the destruction has already 
happened by the time we report it. In this case it should be a path note, not 
an extra blue-bubble note.

As for wording, I suggest `full-expression` with a dash (that's what other 
clang diagnostics use) and probably drop the initial "The"(?)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107078

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

[PATCH] D107200: Stop emit incomplete type error for a variable in an omp map clause where should not.

2021-07-30 Thread Alexey Bataev via Phabricator via cfe-commits

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

LG with a nit.




Comment at: clang/lib/Sema/SemaOpenMP.cpp:18446
   bool FullCheck = true) {
-  NamedDecl *ND;
-  if (QTy->isIncompleteType()) {
-SemaRef.Diag(SL, diag::err_incomplete_type) << QTy << SR;
+  if (SemaRef.RequireCompleteType(SL, QTy,
+  diag::err_incomplete_type))

Formatting?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107200

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

[PATCH] D106753: ConvertUTF: Created wrapper convertUTF32ToUTF8String

2021-07-30 Thread Marcus Johnson via Phabricator via cfe-commits

MarcusJohnson91 added a comment.

There is only one function in ConvertUTFWrapper.cpp: convertUTF32ToUTF8String

idk wtf is going on, maybe the ammending the commit is breaking something?

the diff I see here is correct...

Maybe I should just make a new diff here entirely?


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

https://reviews.llvm.org/D106753

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

[PATCH] D107200: Stop emit incomplete type error for a variable in an omp map clause where should not.

2021-07-30 Thread Jennifer Yu via Phabricator via cfe-commits

jyu2 created this revision.
jyu2 added reviewers: jdoerfert, ABataev, mikerice, cfe-commits.
jyu2 added a project: OpenMP.
jyu2 requested review of this revision.
Herald added a subscriber: sstefan1.
Herald added a project: clang.

Stop emit incomplete type error for a variable in a map clause
where should not.

Currently we are using QTy->isIncompleteType() to check incomplete
type.  But before doing that, need to instantiate for a class template
specialization or a class member of a class template specialization,
or an array with known size of such..., so that we know it is really
incomplete type.

To fix this using RequireCompleteType instead.

The new test is added into "test/OpenMP/target_update_messages.cpp"

The different using RequireCompleteType when emit incomplete type, a
note is also emitted to point to where incomplete type is declared.
Because this change, many tests are needed to be fixed where adding
additional note.

This is to fix https://bugs.llvm.org/show_bug.cgi?id=50508


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D107200

Files:
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/distribute_firstprivate_messages.cpp
  clang/test/OpenMP/distribute_parallel_for_firstprivate_messages.cpp
  clang/test/OpenMP/distribute_parallel_for_lastprivate_messages.cpp
  clang/test/OpenMP/distribute_parallel_for_reduction_messages.cpp
  clang/test/OpenMP/distribute_parallel_for_shared_messages.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_aligned_messages.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_firstprivate_messages.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_lastprivate_messages.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_linear_messages.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_reduction_messages.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_shared_messages.cpp
  clang/test/OpenMP/distribute_simd_aligned_messages.cpp
  clang/test/OpenMP/distribute_simd_firstprivate_messages.cpp
  clang/test/OpenMP/distribute_simd_lastprivate_messages.cpp
  clang/test/OpenMP/distribute_simd_linear_messages.cpp
  clang/test/OpenMP/distribute_simd_reduction_messages.cpp
  clang/test/OpenMP/target_map_messages.cpp
  clang/test/OpenMP/target_parallel_for_map_messages.cpp
  clang/test/OpenMP/target_parallel_for_simd_map_messages.cpp
  clang/test/OpenMP/target_parallel_map_messages.cpp
  clang/test/OpenMP/target_simd_map_messages.cpp
  clang/test/OpenMP/target_teams_distribute_map_messages.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_map_messages.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_simd_map_messages.cpp
  clang/test/OpenMP/target_teams_distribute_simd_map_messages.cpp
  clang/test/OpenMP/target_teams_map_messages.cpp
  clang/test/OpenMP/target_update_from_messages.cpp
  clang/test/OpenMP/target_update_messages.cpp
  clang/test/OpenMP/target_update_to_messages.cpp
  clang/test/OpenMP/teams_distribute_firstprivate_messages.cpp
  clang/test/OpenMP/teams_distribute_lastprivate_messages.cpp
  clang/test/OpenMP/teams_distribute_parallel_for_firstprivate_messages.cpp
  clang/test/OpenMP/teams_distribute_parallel_for_lastprivate_messages.cpp
  clang/test/OpenMP/teams_distribute_parallel_for_reduction_messages.cpp
  clang/test/OpenMP/teams_distribute_parallel_for_shared_messages.cpp
  clang/test/OpenMP/teams_distribute_parallel_for_simd_aligned_messages.cpp
  clang/test/OpenMP/teams_distribute_parallel_for_simd_firstprivate_messages.cpp
  clang/test/OpenMP/teams_distribute_parallel_for_simd_lastprivate_messages.cpp
  clang/test/OpenMP/teams_distribute_parallel_for_simd_linear_messages.cpp
  clang/test/OpenMP/teams_distribute_parallel_for_simd_reduction_messages.cpp
  clang/test/OpenMP/teams_distribute_parallel_for_simd_shared_messages.cpp
  clang/test/OpenMP/teams_distribute_reduction_messages.cpp
  clang/test/OpenMP/teams_distribute_shared_messages.cpp
  clang/test/OpenMP/teams_distribute_simd_aligned_messages.cpp
  clang/test/OpenMP/teams_distribute_simd_firstprivate_messages.cpp
  clang/test/OpenMP/teams_distribute_simd_lastprivate_messages.cpp
  clang/test/OpenMP/teams_distribute_simd_linear_messages.cpp
  clang/test/OpenMP/teams_distribute_simd_reduction_messages.cpp
  clang/test/OpenMP/teams_distribute_simd_shared_messages.cpp
  clang/test/OpenMP/teams_firstprivate_messages.cpp
  clang/test/OpenMP/teams_reduction_messages.cpp
  clang/test/OpenMP/teams_shared_messages.cpp

Index: clang/test/OpenMP/teams_shared_messages.cpp
===
--- clang/test/OpenMP/teams_shared_messages.cpp
+++ clang/test/OpenMP/teams_shared_messages.cpp
@@ -8,8 +8,7 @@
 bool foobool(int argc) {
   return argc;
 }
-
-struct S1; // expected-note {{declared here}}
+struct S1; // expected-note {{declared here}}  // expected-note {{forward declaration of 'S1'}}
 extern S1 a;
 class S2 {
   mutable int a;
Index: clang/test/OpenMP/teams_reduction_messages.cpp

[PATCH] D106753: ConvertUTF: Created wrapper convertUTF32ToUTF8String

2021-07-30 Thread Eli Friedman via Phabricator via cfe-commits

efriedma added a comment.

As far as I can tell, the lastest version of the diff you uploaded still has 
the following issues that haven't been addressed:

1. The BOM handling is actually actively a problem if you're planning to use 
the interface to interpret wprintf format strings. We don't want to byteswap 
`L"\uFFFE%s"` or something like that.
2. `SrcBytes.size() * UNI_MAX_UTF8_BYTES_PER_CODE_POINT + 1` seems like way too 
much memory.


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

https://reviews.llvm.org/D106753

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

[PATCH] D106727: [flang] Produce proper "preprocessor output" for -E option

2021-07-30 Thread Peter Klausler 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 rG3338ef93b028: [flang] Produce proper preprocessor 
output for -E option (authored by klausler).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D106727?vs=363212=363221#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106727

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Flang.cpp
  flang/include/flang/Frontend/FrontendOptions.h
  flang/include/flang/Frontend/PreprocessorOptions.h
  flang/include/flang/Parser/parsing.h
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/Frontend/FrontendActions.cpp
  flang/lib/Frontend/FrontendOptions.cpp
  flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
  flang/lib/Parser/parsing.cpp
  flang/lib/Parser/provenance.cpp
  flang/lib/Parser/token-sequence.cpp
  flang/lib/Parser/token-sequence.h
  flang/test/Driver/cpp-nocpp-command-line-macro.f90
  flang/test/Driver/driver-help-hidden.f90
  flang/test/Driver/driver-help.f90
  flang/test/Driver/escaped-backslash.f90
  flang/test/Driver/fixed-free-detection.f90
  flang/test/Driver/fixed-line-length.f90
  flang/test/Driver/frontend-forwarding.f90
  flang/test/Driver/include-header.f90
  flang/test/Driver/input-from-stdin.f90
  flang/test/Driver/macro-def-undef.F90
  flang/test/Driver/macro-multiline.F90
  flang/test/Parser/badlabel.f
  flang/test/Preprocessing/assert.F90
  flang/test/Preprocessing/dash-E.F90
  flang/test/Preprocessing/fixed-rescan.F
  flang/test/Preprocessing/hollerith.f
  flang/test/Preprocessing/pp001.F
  flang/test/Preprocessing/pp002.F
  flang/test/Preprocessing/pp003.F
  flang/test/Preprocessing/pp004.F
  flang/test/Preprocessing/pp005.F
  flang/test/Preprocessing/pp006.F
  flang/test/Preprocessing/pp007.F
  flang/test/Preprocessing/pp008.F
  flang/test/Preprocessing/pp009.F
  flang/test/Preprocessing/pp010.F
  flang/test/Preprocessing/pp011.F
  flang/test/Preprocessing/pp012.F
  flang/test/Preprocessing/pp013.F
  flang/test/Preprocessing/pp014.F
  flang/test/Preprocessing/pp015.F
  flang/test/Preprocessing/pp016.F
  flang/test/Preprocessing/pp017.F
  flang/test/Preprocessing/pp018.F
  flang/test/Preprocessing/pp019.F
  flang/test/Preprocessing/pp020.F
  flang/test/Preprocessing/pp021.F
  flang/test/Preprocessing/pp022.F
  flang/test/Preprocessing/pp023.F
  flang/test/Preprocessing/pp024.F
  flang/test/Preprocessing/pp025.F
  flang/test/Preprocessing/pp026.F
  flang/test/Preprocessing/pp027.F
  flang/test/Preprocessing/pp028.F
  flang/test/Preprocessing/pp029.F
  flang/test/Preprocessing/pp030.F
  flang/test/Preprocessing/pp031.F
  flang/test/Preprocessing/pp032.F
  flang/test/Preprocessing/pp033.F
  flang/test/Preprocessing/pp034.F
  flang/test/Preprocessing/pp035.F
  flang/test/Preprocessing/pp036.F
  flang/test/Preprocessing/pp037.F
  flang/test/Preprocessing/pp038.F
  flang/test/Preprocessing/pp039.F
  flang/test/Preprocessing/pp041.F
  flang/test/Preprocessing/pp043.F
  flang/test/Preprocessing/pp044.F
  flang/test/Preprocessing/pp101.F90
  flang/test/Preprocessing/pp102.F90
  flang/test/Preprocessing/pp104.F90
  flang/test/Preprocessing/pp107.F90
  flang/test/Preprocessing/pp108.F90
  flang/test/Preprocessing/pp111.F90
  flang/test/Preprocessing/pp112.F90
  flang/test/Preprocessing/pp115.F90
  flang/test/Preprocessing/pp116.F90
  flang/test/Preprocessing/pp117.F90
  flang/test/Preprocessing/pp118.F90
  flang/test/Preprocessing/pp121.F90
  flang/test/Preprocessing/pp123.F90
  flang/test/Preprocessing/pp124.F90
  flang/test/Preprocessing/pp125.F90
  flang/test/Preprocessing/pp126.F90
  flang/test/Preprocessing/pp127.F90
  flang/test/Preprocessing/pp128.F90
  flang/tools/f18-parse-demo/f18-parse-demo.cpp
  flang/tools/f18/f18.cpp
  flang/unittests/Frontend/FrontendActionTest.cpp

Index: flang/unittests/Frontend/FrontendActionTest.cpp
===
--- flang/unittests/Frontend/FrontendActionTest.cpp
+++ flang/unittests/Frontend/FrontendActionTest.cpp
@@ -1,4 +1,4 @@
-//===- unittests/Frontend/PrintPreprocessedTest.cpp  FrontendAction tests--===//
+//===- unittests/Frontend/FrontendActionTest.cpp  FrontendAction tests-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
@@ -116,6 +116,7 @@
 
   // Set-up the action kind.
   compInst_.invocation().frontendOpts().programAction_ = PrintPreprocessedInput;
+  compInst_.invocation().preprocessorOpts().noReformat = true;
 
   // Set-up the output stream. We are using output buffer wrapped as an output
   // stream, as opposed to an actual file (or a file descriptor).
Index: flang/tools/f18/f18.cpp

[clang] 3338ef9 - [flang] Produce proper "preprocessor output" for -E option

2021-07-30 Thread peter klausler via cfe-commits


Author: peter klausler
Date: 2021-07-30T15:13:56-07:00
New Revision: 3338ef93b02837edf69abc203e15a42fa55aa1b3

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

LOG: [flang] Produce proper "preprocessor output" for -E option

Rename the current -E option to "-E -Xflang -fno-reformat".

Add a new Parsing::EmitPreprocessedSource() routine to convert the
cooked character stream output of the prescanner back to something
more closely resembling output from a traditional preprocessor;
call this new routine when -E appears.

The new -E output is suitable for use as fixed form Fortran source to
compilation by (one hopes) any Fortran compiler.  If the original
top-level source file had been free form source, the output will be
suitable for use as free form source as well; otherwise there may be
diagnostics about missing spaces if they were indeed absent in the
original fixed form source.

Unless the -P option appears, #line directives are interspersed
with the output (but be advised, f18 will ignore these if presented
with them in a later compilation).

An effort has been made to preserve original alphabetic character case
and source indentation.

Add -P and -fno-reformat to the new drivers.

Tweak test options to avoid confusion with prior -E output; use
-fno-reformat where needed, but prefer to keep -E, sometimes
in concert with -P, on most, updating expected results accordingly.

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

Added: 
flang/test/Preprocessing/dash-E.F90

Modified: 
clang/include/clang/Driver/Options.td
clang/lib/Driver/ToolChains/Flang.cpp
flang/include/flang/Frontend/FrontendOptions.h
flang/include/flang/Frontend/PreprocessorOptions.h
flang/include/flang/Parser/parsing.h
flang/lib/Frontend/CompilerInvocation.cpp
flang/lib/Frontend/FrontendActions.cpp
flang/lib/Frontend/FrontendOptions.cpp
flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
flang/lib/Parser/parsing.cpp
flang/lib/Parser/provenance.cpp
flang/lib/Parser/token-sequence.cpp
flang/lib/Parser/token-sequence.h
flang/test/Driver/cpp-nocpp-command-line-macro.f90
flang/test/Driver/driver-help-hidden.f90
flang/test/Driver/driver-help.f90
flang/test/Driver/escaped-backslash.f90
flang/test/Driver/fixed-free-detection.f90
flang/test/Driver/fixed-line-length.f90
flang/test/Driver/frontend-forwarding.f90
flang/test/Driver/include-header.f90
flang/test/Driver/input-from-stdin.f90
flang/test/Driver/macro-def-undef.F90
flang/test/Driver/macro-multiline.F90
flang/test/Parser/badlabel.f
flang/test/Preprocessing/assert.F90
flang/test/Preprocessing/fixed-rescan.F
flang/test/Preprocessing/hollerith.f
flang/test/Preprocessing/pp001.F
flang/test/Preprocessing/pp002.F
flang/test/Preprocessing/pp003.F
flang/test/Preprocessing/pp004.F
flang/test/Preprocessing/pp005.F
flang/test/Preprocessing/pp006.F
flang/test/Preprocessing/pp007.F
flang/test/Preprocessing/pp008.F
flang/test/Preprocessing/pp009.F
flang/test/Preprocessing/pp010.F
flang/test/Preprocessing/pp011.F
flang/test/Preprocessing/pp012.F
flang/test/Preprocessing/pp013.F
flang/test/Preprocessing/pp014.F
flang/test/Preprocessing/pp015.F
flang/test/Preprocessing/pp016.F
flang/test/Preprocessing/pp017.F
flang/test/Preprocessing/pp018.F
flang/test/Preprocessing/pp019.F
flang/test/Preprocessing/pp020.F
flang/test/Preprocessing/pp021.F
flang/test/Preprocessing/pp022.F
flang/test/Preprocessing/pp023.F
flang/test/Preprocessing/pp024.F
flang/test/Preprocessing/pp025.F
flang/test/Preprocessing/pp026.F
flang/test/Preprocessing/pp027.F
flang/test/Preprocessing/pp028.F
flang/test/Preprocessing/pp029.F
flang/test/Preprocessing/pp030.F
flang/test/Preprocessing/pp031.F
flang/test/Preprocessing/pp032.F
flang/test/Preprocessing/pp033.F
flang/test/Preprocessing/pp034.F
flang/test/Preprocessing/pp035.F
flang/test/Preprocessing/pp036.F
flang/test/Preprocessing/pp037.F
flang/test/Preprocessing/pp038.F
flang/test/Preprocessing/pp039.F
flang/test/Preprocessing/pp041.F
flang/test/Preprocessing/pp043.F
flang/test/Preprocessing/pp044.F
flang/test/Preprocessing/pp101.F90
flang/test/Preprocessing/pp102.F90
flang/test/Preprocessing/pp104.F90
flang/test/Preprocessing/pp107.F90
flang/test/Preprocessing/pp108.F90
flang/test/Preprocessing/pp111.F90
flang/test/Preprocessing/pp112.F90
flang/test/Preprocessing/pp115.F90
flang/test/Preprocessing/pp116.F90
flang/test/Preprocessing/pp117.F90
flang/test/Preprocessing/pp118.F90
flang/test/Preprocessing/pp121.F90
flang/test/Preprocessing/pp123.F90
flang/test/Preprocessing/pp124.F90

[PATCH] D106753: ConvertUTF: Created wrapper convertUTF32ToUTF8String

2021-07-30 Thread Marcus Johnson via Phabricator via cfe-commits

MarcusJohnson91 updated this revision to Diff 363216.
MarcusJohnson91 added a comment.

It seems like this diff keeps getting reverted?

I've fixed all the issues mentioned, and the tests work now, everything is 
formatted correctly too.

I've set git up to do full context diffs, but it's not working?


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

https://reviews.llvm.org/D106753

Files:
  llvm/include/llvm/Support/ConvertUTF.h
  llvm/lib/Support/ConvertUTFWrapper.cpp
  llvm/unittests/Support/ConvertUTFTest.cpp

Index: llvm/unittests/Support/ConvertUTFTest.cpp
===
--- llvm/unittests/Support/ConvertUTFTest.cpp
+++ llvm/unittests/Support/ConvertUTFTest.cpp
@@ -25,6 +25,17 @@
   EXPECT_EQ(Expected, Result);
 }
 
+TEST(ConvertUTFTest, ConvertUTF32LittleEndianToUTF8String) {
+  // Src is a crystal ball.
+  alignas(UTF32) static const char Src[] = "\x2E\xF5\x01\x00";
+  ArrayRef Ref(Src, sizeof(Src) - 1);
+  std::string Result;
+  bool Success = convertUTF32ToUTF8String(Ref, Result);
+  EXPECT_TRUE(Success);
+  std::string Expected("\xF0\x9F\x94\xAE");
+  EXPECT_EQ(Expected, Result);
+}
+
 TEST(ConvertUTFTest, ConvertUTF16BigEndianToUTF8String) {
   // Src is the look of disapproval.
   alignas(UTF16) static const char Src[] = "\xfe\xff\x0c\xa0\x00_\x0c\xa0";
@@ -36,6 +47,17 @@
   EXPECT_EQ(Expected, Result);
 }
 
+TEST(ConvertUTFTest, ConvertUTF32BigEndianToUTF8String) {
+  // Src is a crystal ball.
+  alignas(UTF32) static const char Src[] = "\x00\x00\xfe\xff\x00\x01\xF5\x2E";
+  ArrayRef Ref(Src, sizeof(Src) - 1);
+  std::string Result;
+  bool Success = convertUTF32ToUTF8String(Ref, Result);
+  EXPECT_TRUE(Success);
+  std::string Expected("\xF0\x9F\x94\xAE");
+  EXPECT_EQ(Expected, Result);
+}
+
 TEST(ConvertUTFTest, ConvertUTF8ToUTF16String) {
   // Src is the look of disapproval.
   static const char Src[] = "\xe0\xb2\xa0_\xe0\xb2\xa0";
Index: llvm/lib/Support/ConvertUTFWrapper.cpp
===
--- llvm/lib/Support/ConvertUTFWrapper.cpp
+++ llvm/lib/Support/ConvertUTFWrapper.cpp
@@ -141,6 +141,60 @@
   Src.size() * sizeof(UTF16)), Out);
 }
 
+bool convertUTF32ToUTF8String(ArrayRef SrcBytes, std::string ) {
+  assert(Out.empty());
+
+  // Avoid OOB by returning early on empty input.
+  if (SrcBytes.empty())
+return true;
+
+  const UTF32 *Src = reinterpret_cast(SrcBytes.begin());
+  const UTF32 *SrcEnd = reinterpret_cast(SrcBytes.end());
+
+  assert((uintptr_t)Src % sizeof(UTF32) == 0);
+
+  // Byteswap if necessary.
+  std::vector ByteSwapped;
+  if (Src[0] == UNI_UTF32_BYTE_ORDER_MARK_SWAPPED) {
+ByteSwapped.insert(ByteSwapped.end(), Src, SrcEnd);
+for (unsigned I = 0, E = ByteSwapped.size(); I != E; ++I)
+  ByteSwapped[I] = llvm::ByteSwap_32(ByteSwapped[I]);
+Src = [0];
+SrcEnd = [ByteSwapped.size() - 1] + 1;
+  }
+
+  // Skip the BOM for conversion.
+  if (Src[0] == UNI_UTF32_BYTE_ORDER_MARK_NATIVE)
+Src++;
+
+  // Just allocate enough space up front.  We'll shrink it later.  Allocate
+  // enough that we can fit a null terminator without reallocating.
+  Out.resize(SrcBytes.size() * UNI_MAX_UTF8_BYTES_PER_CODE_POINT + 1);
+  UTF8 *Dst = reinterpret_cast([0]);
+  UTF8 *DstEnd = Dst + Out.size();
+
+  ConversionResult CR =
+  ConvertUTF32toUTF8(, SrcEnd, , DstEnd, strictConversion);
+  assert(CR != targetExhausted);
+
+  if (CR != conversionOK) {
+Out.clear();
+return false;
+  }
+
+  Out.resize(reinterpret_cast(Dst) - [0]);
+  Out.push_back(0);
+  Out.pop_back();
+  return true;
+}
+
+bool convertUTF32ToUTF8String(ArrayRef Src, std::string ) {
+  return convertUTF32ToUTF8String(
+  llvm::ArrayRef(reinterpret_cast(Src.data()),
+   Src.size() * sizeof(UTF32)),
+  Out);
+}
+
 bool convertUTF8ToUTF16String(StringRef SrcUTF8,
   SmallVectorImpl ) {
   assert(DstUTF16.empty());
Index: llvm/include/llvm/Support/ConvertUTF.h
===
--- llvm/include/llvm/Support/ConvertUTF.h
+++ llvm/include/llvm/Support/ConvertUTF.h
@@ -123,6 +123,9 @@
 #define UNI_UTF16_BYTE_ORDER_MARK_NATIVE  0xFEFF
 #define UNI_UTF16_BYTE_ORDER_MARK_SWAPPED 0xFFFE
 
+#define UNI_UTF32_BYTE_ORDER_MARK_NATIVE 0xFEFF
+#define UNI_UTF32_BYTE_ORDER_MARK_SWAPPED 0xFFFE
+
 typedef enum {
   conversionOK,   /* conversion successful */
   sourceExhausted,/* partial character in source, but hit end */
@@ -278,6 +281,24 @@
 */
 bool convertUTF16ToUTF8String(ArrayRef Src, std::string );
 
+/**
+ * Converts a stream of raw bytes assumed to be UTF32 into a UTF8 std::string.
+ *
+ * \param [in] SrcBytes A buffer of what is assumed to be UTF-32 encoded text.
+ * \param [out] Out Converted UTF-8 is stored here on success.
+ * \returns true on success
+ */
+bool convertUTF32ToUTF8String(ArrayRef SrcBytes, std::string );
+
+/**
+ *

[PATCH] D106959: [PowerPC] swdiv builtins for XL compatibility

2021-07-30 Thread Amy Kwan via Phabricator via cfe-commits

amyk added inline comments.



Comment at: llvm/include/llvm/IR/IntrinsicsPowerPC.td:1436
+
+def int_ppc_ftdivdp : Intrinsic<[llvm_i32_ty], [llvm_double_ty, 
llvm_double_ty], [IntrNoMem]>;
 }

Line too long?



Comment at: llvm/include/llvm/IR/IntrinsicsPowerPC.td:1724
+  Intrinsic<[llvm_double_ty], [llvm_double_ty, 
llvm_double_ty],
+  [IntrNoMem]>;
+  def int_ppc_swdivs : GCCBuiltin<"__builtin_ppc_swdivs">,

Minor indentation nit.



Comment at: llvm/include/llvm/IR/IntrinsicsPowerPC.td:1727
+   Intrinsic<[llvm_float_ty], [llvm_float_ty, 
llvm_float_ty],
+   [IntrNoMem]>;
 }

Minor indentation nit.



Comment at: llvm/lib/Target/PowerPC/PPCTargetMachine.cpp:451
   TargetPassConfig::addIRPasses();
+
+  addPass(createPPCLowerCheckedFPArithPass());

Nit: Add a comment before creating the pass as the other pass calls also follow 
a comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106959

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

[PATCH] D107125: [Diagnostic] Split 'qualifier on reference type has no effect' out into a new flag

2021-07-30 Thread Luna Kirkby via Phabricator via cfe-commits

lunasorcery added a comment.

Sure thing - would the suite in /clang/test/SemaCXX/ be the right place to put 
that?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107125

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

[PATCH] D106755: Extended format string checking to wprintf/wscanf

2021-07-30 Thread Eli Friedman via Phabricator via cfe-commits

efriedma added subscribers: tahonermann, cor3ntin.
efriedma added inline comments.



Comment at: clang/lib/AST/Expr.cpp:1081
+ArrayRef AR(getTrailingObjects(),
+  getTrailingObjects() + getByteLength());
+if (llvm::convertUTF16ToUTF8String(AR, Output)) {

getStringAsChar16?



Comment at: clang/lib/AST/Type.cpp:1979
+while (!Desugar->isCanonicalUnqualified()) {
+  if (Desugar.getAsString() == "char16_t") {
+return true;

(The discussion of the typedefs on D103426 didn't really finish.)



Comment at: clang/lib/Lex/LiteralSupport.cpp:1923
 if (*SpellingPtr != '\\') {
   ++SpellingPtr;
   --ByteNo;

The math here probably needs to change for wide strings.



Comment at: clang/lib/Sema/SemaChecking.cpp:9609
+
   size_t StrLen = std::min(std::max(TypeSize, size_t(1)) - 1, StrRef.size());
   return analyze_format_string::ParseFormatStringHasSArg(Str, Str + StrLen,

The math here looks suspicious... TypeSize is not in the same units as 
StrRef.size().


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

https://reviews.llvm.org/D106755

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

[PATCH] D106753: ConvertUTF: Created wrapper convertUTF32ToUTF8String

2021-07-30 Thread Eli Friedman via Phabricator via cfe-commits

efriedma added inline comments.



Comment at: llvm/lib/Support/ConvertUTFWrapper.cpp:176
+  // enough that we can fit a null terminator without reallocating.
+  Out.resize(SrcBytes.size() * UNI_MAX_UTF8_BYTES_PER_CODE_POINT + 1);
+  UTF8 *Dst = reinterpret_cast([0]);

MarcusJohnson91 wrote:
> efriedma wrote:
> > `SrcBytes.size() * UNI_MAX_UTF8_BYTES_PER_CODE_POINT + 1` seems like way 
> > too much memory.
> I copied that from the UTF16 code
I'm not sure the math is right even for UTF-16, but anyway, UTF-32 is a little 
different from UTF-16.  A 2-byte character in UTF-16 can translate to 3 bytes 
in UTF-8.  That sort of thing is impossible in UTF-32: a UTF-32 string is never 
shorter than its translation to UTF-8.  A codepoint in UTF-8 is at most 4 bytes.



Comment at: llvm/lib/Support/ConvertUTFWrapper.cpp:168
+  std::vector ByteSwapped;
+  if (Src[0] == UNI_UTF16_BYTE_ORDER_MARK_SWAPPED) {
+ByteSwapped.insert(ByteSwapped.end(), Src, SrcEnd);

efriedma wrote:
> MarcusJohnson91 wrote:
> > efriedma wrote:
> > > Wrong constant.
> > > 
> > > Is this really the function you want to be using from clang?  I don't 
> > > really understand why you'd want to handle byte order marks.
> > I don't really care about the BOM tbh, I just figured if I was in here, I 
> > should flesh out the UTF-32 interface.
> The BOM handling is actually actively a problem if you're planning to use the 
> interface to interpret wprintf format strings.  We don't want to byteswap 
> `L"\uFFFE%s"` or something like that.
Any thoughts on this?


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

https://reviews.llvm.org/D106753

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

[PATCH] D107026: [Clang] Add support for attribute 'escape'

2021-07-30 Thread Artem Dergachev via Phabricator via cfe-commits

NoQ added inline comments.



Comment at: clang/include/clang/Basic/AttrDocs.td:260
+``escape`` placed on a function parameter of a pointer type is used to indicate
+that the pointer can escape the function. This means that a reference to the 
object
+the pointer points to that is derived from the parameter value may survive

aaron.ballman wrote:
> guitard0g wrote:
> > NoQ wrote:
> > > Are you sure you want "can escape" instead of "will escape"? In the 
> > > former case it's impossible to implement the warning without false 
> > > positives ("well, it says it may escape, but I know for sure that if I 
> > > pass these other arguments then it won't escape"). In the latter case, of 
> > > course, a lot of places where the value escapes conditionally won't be 
> > > able to wear the attribute. Do I understand correctly that you want to 
> > > proceed with the more aggressive diagnostic?
> > Hmm that's an interesting question. Initially my thought was that any 
> > possibility of escaping should eliminate the option of passing in a 
> > temporary pointer, which I think is reasonable in Swift's implicit bridging 
> > use-case. In terms of the API contract, I was thinking that any API author 
> > who annotates their function parameter with 'escaping' is effectively 
> > saying you shouldn't pass in a pointer that you're not comfortable 
> > escaping. I think it may be a little restrictive to say that the pointer 
> > will always escape for certain, but I do think that anybody using a 
> > function that takes an escaping parameter should treat this as if it were 
> > always escaping (if that makes sense). I suppose my question then would be, 
> > do you think it's better to say "will escape" if that's what the client 
> > calling into an API should expect (even though the pointer might not always 
> > escape in the implementation)? 
> > ``escape`` placed on a function parameter of a pointer type is used to 
> > indicate that the pointer can escape the function.
> 
> FWIW, this reads a bit strangely to me because that's already the case 
> without the attribute. Anything that's not marked *can* escape. I think "will 
> escape" more clearly identifies to the person reading the function signature 
> that the parameter should be treated as though it will escape. If it does not 
> escape, that's not necessarily an issue because that shouldn't change how the 
> user treats the argument (for example, it may not escape today but it may 
> start to escape in the future).
> 
> One thing the docs are missing is an explanation of what benefit you get from 
> using this annotation. Does this improve optimizations? Enable better 
> checking somewhere? That sort of thing (with examples) would be good to add.
If I understand correctly, the new attribute proclaims "Do not, under any 
circumstances, pass stack pointers here". Like, it doesn't necessarily escape 
every time, but you should expect the function to be able to stash that pointer 
somewhere without telling you, for indefinite amount of time, so if you put 
your temporaries into this function you're 100% doing something wrong and you 
want to be notified about this.

This take probably raises more questions though. Like, if the pointer is a heap 
pointer but we see a nearby `delete` of that pointer with our own eyes, do we 
warn too? Where exactly is the boundary between short-lived and long-lived 
objects? (IIUC the answer is yes, we do want to warn, because the function 
stashes the pointer for *indefinite* amount of time so it should be the judge 
for when to delete it, not you).

I think there could be a simple compiler warning associated with that attribute 
which would pattern-match the argument to see if it's an immediate stack 
address such as `()` or `` where `Var` is a local variable. A static 
analyzer check for the more sophisticated cases works too of course.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107026

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

[PATCH] D107139: [RISCV] Rename vector inline constraint from 'v' to 'vr' and 'vm' in IR.

2021-07-30 Thread Craig Topper via Phabricator via cfe-commits

craig.topper added inline comments.



Comment at: clang/lib/Basic/Targets/RISCV.cpp:108
   case 'v':
-R = std::string("v");
+R = std::string("@2") + std::string(Constraint, 2);
 Constraint += 1;

I believe most targets use `std::string("^") + std::string(Constraint, 2)` for 
2 letter constraints

AArch64 added the @ format and uses @3 for a 3 letter constraint. But it didn't 
get documented in the LangRef.

Can we use the ^ here which is documented.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107139

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

[clang] 7f97dda - Revert "[OpenMP][AMDGCN] Initial math headers support"

2021-07-30 Thread Jon Chesterfield via cfe-commits


Author: Jon Chesterfield
Date: 2021-07-30T22:07:00+01:00
New Revision: 7f97ddaf8aa0062393e866b63e68c9f74da375fb

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

LOG: Revert "[OpenMP][AMDGCN] Initial math headers support"

Broke nvptx compilation on files including 

This reverts commit 12da97ea10a941f0123340831300d09a2121e173.

Added: 


Modified: 
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Headers/__clang_hip_cmath.h
clang/lib/Headers/__clang_hip_math.h
clang/lib/Headers/openmp_wrappers/__clang_openmp_device_functions.h
clang/lib/Headers/openmp_wrappers/cmath
clang/lib/Headers/openmp_wrappers/math.h
clang/test/Headers/Inputs/include/cstdlib
clang/test/Headers/openmp_device_math_isnan.cpp

Removed: 
clang/test/Headers/Inputs/include/algorithm
clang/test/Headers/Inputs/include/utility
clang/test/Headers/amdgcn_openmp_device_math.c



diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 278ae118563d6..e13302528cbd1 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -1256,8 +1256,7 @@ void Clang::AddPreprocessingOptions(Compilation , const 
JobAction ,
   // If we are offloading to a target via OpenMP we need to include the
   // openmp_wrappers folder which contains alternative system headers.
   if (JA.isDeviceOffloading(Action::OFK_OpenMP) &&
-  (getToolChain().getTriple().isNVPTX() ||
-   getToolChain().getTriple().isAMDGCN())) {
+  getToolChain().getTriple().isNVPTX()){
 if (!Args.hasArg(options::OPT_nobuiltininc)) {
   // Add openmp_wrappers/* to our system include path.  This lets us wrap
   // standard library headers.

diff  --git a/clang/lib/Headers/__clang_hip_cmath.h 
b/clang/lib/Headers/__clang_hip_cmath.h
index d488db0a94d9d..7342705434e6b 100644
--- a/clang/lib/Headers/__clang_hip_cmath.h
+++ b/clang/lib/Headers/__clang_hip_cmath.h
@@ -10,7 +10,7 @@
 #ifndef __CLANG_HIP_CMATH_H__
 #define __CLANG_HIP_CMATH_H__
 
-#if !defined(__HIP__) && !defined(__OPENMP_AMDGCN__)
+#if !defined(__HIP__)
 #error "This file is for HIP and OpenMP AMDGCN device compilation only."
 #endif
 
@@ -25,43 +25,31 @@
 #endif // !defined(__HIPCC_RTC__)
 
 #pragma push_macro("__DEVICE__")
-#pragma push_macro("__CONSTEXPR__")
-#ifdef __OPENMP_AMDGCN__
-#define __DEVICE__ static __attribute__((always_inline, nothrow))
-#define __CONSTEXPR__ constexpr
-#else
 #define __DEVICE__ static __device__ inline __attribute__((always_inline))
-#define __CONSTEXPR__
-#endif // __OPENMP_AMDGCN__
 
 // Start with functions that cannot be defined by DEF macros below.
 #if defined(__cplusplus)
-#if defined __OPENMP_AMDGCN__
-__DEVICE__ __CONSTEXPR__ float fabs(float __x) { return ::fabsf(__x); }
-__DEVICE__ __CONSTEXPR__ float sin(float __x) { return ::sinf(__x); }
-__DEVICE__ __CONSTEXPR__ float cos(float __x) { return ::cosf(__x); }
-#endif
-__DEVICE__ __CONSTEXPR__ double abs(double __x) { return ::fabs(__x); }
-__DEVICE__ __CONSTEXPR__ float abs(float __x) { return ::fabsf(__x); }
-__DEVICE__ __CONSTEXPR__ long long abs(long long __n) { return ::llabs(__n); }
-__DEVICE__ __CONSTEXPR__ long abs(long __n) { return ::labs(__n); }
-__DEVICE__ __CONSTEXPR__ float fma(float __x, float __y, float __z) {
+__DEVICE__ double abs(double __x) { return ::fabs(__x); }
+__DEVICE__ float abs(float __x) { return ::fabsf(__x); }
+__DEVICE__ long long abs(long long __n) { return ::llabs(__n); }
+__DEVICE__ long abs(long __n) { return ::labs(__n); }
+__DEVICE__ float fma(float __x, float __y, float __z) {
   return ::fmaf(__x, __y, __z);
 }
 #if !defined(__HIPCC_RTC__)
 // The value returned by fpclassify is platform dependent, therefore it is not
 // supported by hipRTC.
-__DEVICE__ __CONSTEXPR__ int fpclassify(float __x) {
+__DEVICE__ int fpclassify(float __x) {
   return __builtin_fpclassify(FP_NAN, FP_INFINITE, FP_NORMAL, FP_SUBNORMAL,
   FP_ZERO, __x);
 }
-__DEVICE__ __CONSTEXPR__ int fpclassify(double __x) {
+__DEVICE__ int fpclassify(double __x) {
   return __builtin_fpclassify(FP_NAN, FP_INFINITE, FP_NORMAL, FP_SUBNORMAL,
   FP_ZERO, __x);
 }
 #endif // !defined(__HIPCC_RTC__)
 
-__DEVICE__ __CONSTEXPR__ float frexp(float __arg, int *__exp) {
+__DEVICE__ float frexp(float __arg, int *__exp) {
   return ::frexpf(__arg, __exp);
 }
 
@@ -83,101 +71,93 @@ __DEVICE__ __CONSTEXPR__ float frexp(float __arg, int 
*__exp) {
 //of the variants inside the inner region and avoid the clash.
 #pragma omp begin declare variant match(implementation = {vendor(llvm)})
 
-__DEVICE__ __CONSTEXPR__ int isinf(float __x) { return ::__isinff(__x); }
-__DEVICE__ __CONSTEXPR__ int isinf(double __x) { return ::__isinf(__x); }

[PATCH] D104904: [OpenMP][AMDGCN] Initial math headers support

2021-07-30 Thread Jon Chesterfield via Phabricator via cfe-commits

JonChesterfield added a comment.

In D104904#2916943 , @ye-luo wrote:

> Unforuantely I hit error on my ubuntu 20.04 system.
>
>   #include 
>   int main()
>   { }

Given that ^ in fail.cpp and an invocation on a machine that doesn't have cuda 
or an nvidia card (it had built nvptx devicertl, probably doesn't matter for 
this)
`$HOME/llvm-install/bin/clang++ -fopenmp -fopenmp-targets=nvptx64 fail.cpp  
-nocudalib`

I also get a failure. This time on libstdc++ 10, various failures, starting from

  In file included from 
/home/amd/llvm-install/lib/clang/14.0.0/include/openmp_wrappers/complex:26:
  In file included from 
/usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/complex:45:
  In file included from 
/usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/sstream:38:
  In file included from 
/usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/istream:38:
  In file included from 
/usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/ios:40:
  
/usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/char_traits.h:216:7:
 error: no member named 'copy' in namespace 'std'; did you mean
simply 'copy'?
std::copy(__s2, __s2 + __n, __s1);
^

Reverting replaces that error with the expected "ptxas" doesn't exist. 
Therefore reverting this change, will reapply once the unexpected change of 
behaviour on nvptx is understood and avoided.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104904

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

[PATCH] D106959: [PowerPC] swdiv builtins for XL compatibility

2021-07-30 Thread Eli Friedman via Phabricator via cfe-commits

efriedma added inline comments.



Comment at: llvm/test/CodeGen/PowerPC/LowerCheckedFPArith.ll:36
+; CHECK-NEXT:  %2 = fdiv fast float %0, %1
+; CHECK-NEXT:  %3 = fcmp une float %2, %2
+; CHECK-NEXT:  br i1 %3, label %swdiv_HWDIV, label %swdiv_MERGE

quinnp wrote:
> efriedma wrote:
> > A "fast" fdiv never produces NaN, per LangRef.  Using fcmp like this is 
> > fragile at best.
> > 
> > (Maybe you want "fdiv arcp"?)
> Thank you, I see what you mean. I have changed it to emit a `fdiv ninf arcp` 
> instead of a `fdiv fast`. I included the `ninf` flag because without it the 
> compiler doesn't produce the software div estimate.
ninf is also an issue, although maybe less likely to bite in practice.  
Consider what happens if someone passes infinity to swdivs: the fdiv reduces to 
poison, so the branch is undefined behavior.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106959

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

[PATCH] D107190: [AMDGPU][HIP] Switch default DWARF version to 5

2021-07-30 Thread Tony Tye via Phabricator via cfe-commits

t-tye accepted this revision.
t-tye 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/D107190/new/

https://reviews.llvm.org/D107190

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

[PATCH] D107138: [PowerPC] Implement cmplxl builtins

2021-07-30 Thread Amy Kwan via Phabricator via cfe-commits

amyk added inline comments.



Comment at: clang/test/CodeGen/builtins-ppc-xlcompat-complex.c:35
+  // CHECK-NEXT: %1 = load ppc_fp128, ppc_fp128* @ldb
+  // CHECK-NEXT: %.fca.0.insert = insertvalue { ppc_fp128, ppc_fp128 } undef, 
ppc_fp128 %0, 0
+  // CHECK-NEXT: %.fca.1.insert = insertvalue { ppc_fp128, ppc_fp128 } 
%.fca.0.insert, ppc_fp128 %1, 1

I think it would probably be better not to hardcode the variable names in the 
tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107138

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

[PATCH] D106959: [PowerPC] swdiv builtins for XL compatibility

2021-07-30 Thread Quinn Pham via Phabricator via cfe-commits

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



Comment at: llvm/test/CodeGen/PowerPC/LowerCheckedFPArith.ll:36
+; CHECK-NEXT:  %2 = fdiv fast float %0, %1
+; CHECK-NEXT:  %3 = fcmp une float %2, %2
+; CHECK-NEXT:  br i1 %3, label %swdiv_HWDIV, label %swdiv_MERGE

efriedma wrote:
> A "fast" fdiv never produces NaN, per LangRef.  Using fcmp like this is 
> fragile at best.
> 
> (Maybe you want "fdiv arcp"?)
Thank you, I see what you mean. I have changed it to emit a `fdiv ninf arcp` 
instead of a `fdiv fast`. I included the `ninf` flag because without it the 
compiler doesn't produce the software div estimate.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106959

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

[PATCH] D105821: [analyzer] [WIP] Model destructor for std::unique_ptr

2021-07-30 Thread Artem Dergachev via Phabricator via cfe-commits

NoQ added a comment.

> Well some of them are exactly the same type as the `Lame` class example 
> above. Like: 
> `simbody/report-TestArray.cpp-testMoveConstructionAndAssignment-27-1.html#EndPath`.
>  (So the incomplete modelling of the destructor is at least one cause. The 
> other reason that you suggested might as well be true).

The problem with the `Lame` class above was the constructor in `make_unique`, 
not the destructor.

But more importantly, in this case the destructor most likely isn't responsible 
for freeing memory. The `push_back()` method most likely *moves* the smart 
pointer into the array, so by the time `~unique_ptr()` hits the smart pointer 
is already empty, there's nothing to free. What we're missing is a "pointer 
escape" event for the raw pointer. It sounds like a feature we have to 
implement: when the smart pointer region pointer-escapes (in this case, due to 
being passed into an unknown function via rvalue reference), the raw pointer 
region should also pointer-escape. (Or, if `push_back()` is inlined then 
there's a different reason for escape, something along the lines of getting 
move-assigned into the heap, which we should probably also implement 
separately!). Damn, that's an interesting can of worms.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105821

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

[PATCH] D106959: [PowerPC] swdiv builtins for XL compatibility

2021-07-30 Thread Quinn Pham via Phabricator via cfe-commits

quinnp updated this revision to Diff 363189.
quinnp added a comment.

Addressing review comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106959

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/Basic/Targets/PPC.cpp
  clang/test/CodeGen/builtins-ppc-xlcompat-swdiv.c
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/CMakeLists.txt
  llvm/lib/Target/PowerPC/PPC.h
  llvm/lib/Target/PowerPC/PPCInstrInfo.td
  llvm/lib/Target/PowerPC/PPCInstrVSX.td
  llvm/lib/Target/PowerPC/PPCLowerCheckedFPArith.cpp
  llvm/lib/Target/PowerPC/PPCTargetMachine.cpp
  llvm/test/CodeGen/PowerPC/LowerCheckedFPArith.ll
  llvm/test/CodeGen/PowerPC/O3-pipeline.ll
  llvm/test/CodeGen/PowerPC/int-ppc-ftdivdp.ll

Index: llvm/test/CodeGen/PowerPC/int-ppc-ftdivdp.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/int-ppc-ftdivdp.ll
@@ -0,0 +1,32 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-unknown \
+; RUN:   -mcpu=pwr7 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-unknown \
+; RUN:   -mcpu=pwr8 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc-unknown-aix \
+; RUN:   -mcpu=pwr7 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-aix \
+; RUN:   -mcpu=pwr7 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-unknown \
+; RUN:   -mattr=-vsx -mcpu=pwr8 < %s | FileCheck %s --check-prefix=CHECK-NOVSX
+
+define dso_local i32 @test_ftdivdp(double %a, double %b) local_unnamed_addr {
+; CHECK-LABEL: test_ftdivdp:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:xstdivdp 0, 1, 2
+; CHECK-NEXT:mfocrf 3, 128
+; CHECK-NEXT:srwi 3, 3, 28
+; CHECK-NEXT:blr
+;
+; CHECK-NOVSX-LABEL: test_ftdivdp:
+; CHECK-NOVSX:   # %bb.0: # %entry
+; CHECK-NOVSX-NEXT:ftdiv 0, 1, 2
+; CHECK-NOVSX-NEXT:mfocrf 3, 128
+; CHECK-NOVSX-NEXT:srwi 3, 3, 28
+; CHECK-NOVSX-NEXT:blr
+entry:
+  %c = tail call i32 @llvm.ppc.ftdivdp(double %a, double %b)
+  ret i32 %c
+}
+
+declare i32 @llvm.ppc.ftdivdp(double, double)
Index: llvm/test/CodeGen/PowerPC/O3-pipeline.ll
===
--- llvm/test/CodeGen/PowerPC/O3-pipeline.ll
+++ llvm/test/CodeGen/PowerPC/O3-pipeline.ll
@@ -63,6 +63,8 @@
 ; CHECK-NEXT:   Expand vector predication intrinsics
 ; CHECK-NEXT:   Scalarize Masked Memory Intrinsics
 ; CHECK-NEXT:   Expand reduction intrinsics
+; CHECK-NEXT:   Lower Checked Floating Point Arithmetic
+; CHECK-NEXT:   Dominator Tree Construction
 ; CHECK-NEXT:   Natural Loop Information
 ; CHECK-NEXT:   CodeGen Prepare
 ; CHECK-NEXT:   Dominator Tree Construction
Index: llvm/test/CodeGen/PowerPC/LowerCheckedFPArith.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/LowerCheckedFPArith.ll
@@ -0,0 +1,53 @@
+; RUN: opt -ppc-lower-checked-fp-arith -S -o - < %s | FileCheck %s
+
+@a = external local_unnamed_addr global double
+@b = external local_unnamed_addr global double
+@c = external local_unnamed_addr global float
+@d = external local_unnamed_addr global float
+
+; CHECK-LABEL: @test_swdiv(
+; CHECK:  %0 = load double, double* @a, align 8
+; CHECK-NEXT:  %1 = load double, double* @b, align 8
+; CHECK-NEXT:  %2 = call i32 @llvm.ppc.ftdivdp(double %0, double %1)
+; CHECK-NEXT:  %3 = icmp eq i32 %2, 0
+; CHECK-NEXT:  %4 = fdiv ninf arcp double %0, %1
+; CHECK-NEXT:  br i1 %3, label %swdiv_HWDIV, label %swdiv_MERGE
+
+; CHECK:  %5 = fdiv double %0, %1
+; CHECK-NEXT:  br label %swdiv_MERGE
+
+; CHECK:  %6 = phi double [ %4, %entry ], [ %5, %swdiv_HWDIV ]
+; CHECK-NEXT:  ret double %6
+
+define dso_local double @test_swdiv() local_unnamed_addr {
+entry:
+  %0 = load double, double* @a
+  %1 = load double, double* @b
+  %2 = tail call double @llvm.ppc.swdiv(double %0, double %1)
+  ret double %2
+}
+
+declare double @llvm.ppc.swdiv(double, double)
+
+; CHECK-LABEL: @test_swdivs(
+; CHECK:  %0 = load float, float* @c, align 4
+; CHECK-NEXT:  %1 = load float, float* @d, align 4
+; CHECK-NEXT:  %2 = fdiv ninf arcp float %0, %1
+; CHECK-NEXT:  %3 = fcmp une float %2, %2
+; CHECK-NEXT:  br i1 %3, label %swdiv_HWDIV, label %swdiv_MERGE
+
+; CHECK:  %4 = fdiv float %0, %1
+; CHECK-NEXT:  br label %swdiv_MERGE
+
+; CHECK:  %5 = phi float [ %2, %entry ], [ %4, %swdiv_HWDIV ]
+; CHECK-NEXT:  ret float %5
+
+define dso_local float @test_swdivs() local_unnamed_addr {
+entry:
+  %0 = load float, float* @c
+  %1 = load float, float* @d
+  %2 = tail call float @llvm.ppc.swdivs(float %0, float %1)
+  ret float %2
+}
+
+declare float @llvm.ppc.swdivs(float, float)
Index: llvm/lib/Target/PowerPC/PPCTargetMachine.cpp

[PATCH] D105909: [clang][CallGraphSection] Add type id metadata to indirect call and targets

2021-07-30 Thread Fangrui Song via Phabricator via cfe-commits

MaskRay added a comment.

(Two comments I forgot to push yesterday.)




Comment at: clang/test/CodeGen/call-graph-section-1.cpp:39
+  void f6(const Cls1 *a) {}
+
+  // FT-DAG: define {{.*}} void @_ZN4Cls22f7ER4Cls1({{.*}} !type 
[[F_TCLS2F7:![0-9]+]]

needs a test for an out-of-line definition.



Comment at: clang/test/CodeGen/call-graph-section-3.cpp:24
+
+// FT-DAG: [[F_TVF]] = !{i64 0, !"_ZTSFiPvE.generalized"}
+

Metadata nodes are guaranteed to be in the end. Drop `-DAG`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105909

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

[PATCH] D94639: [DebugInfo][CodeView] Change in line tables only mode to emit parent/context scopes for functions, using declarations for types

2021-07-30 Thread Reid Kleckner via Phabricator via cfe-commits

rnk added a comment.

In D94639#2917340 , @SeTSeR wrote:

> Hello! As far as I understand, Clang does not preserve info about namespace 
> for functions declared in namespaces with `-gline-numbers-only` flag. Is 
> there any way to retrieve this info for DWARF? I thought FIXME at line 261 in 
> CGDebugInfo was addressing exactly this issue.

No, I don't think there is a way to achieve this.

The current -gcodeview -gline-tables-only behavior as I understand it is to 
emit regular debug info, but skip two key source of info:

- never emit complete class declarations, always use forward decls
- never emit variable locations, only emit source locations

For DWARF, I think we also try to skip namespace scopes, class forward decls, 
function types, and other things like that, but I forget the details.

I happen to know that many users of -gline-tables-only are very space 
constrained: we can't simply port this change from CV to DWARF. We'd have to 
add a new flag. The bar for such a flag is high. If someone provides a 
well-motivated use case, we could consider it.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94639

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

[PATCH] D107189: [z/OS]Remove overriding default attribute aligned value

2021-07-30 Thread Fanbo Meng 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 rGbdf4c7b738ee: [z/OS]Remove overriding default attribute 
aligned value (authored by fanbo-meng).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107189

Files:
  clang/lib/Basic/Targets/OSTargets.h
  clang/test/CodeGen/SystemZ/zos-alignment.c


Index: clang/test/CodeGen/SystemZ/zos-alignment.c
===
--- clang/test/CodeGen/SystemZ/zos-alignment.c
+++ clang/test/CodeGen/SystemZ/zos-alignment.c
@@ -147,7 +147,7 @@
 } S10;
 // CHECK:  0 | struct s10
 // CHECK-NEXT: 0 |   unsigned int a
-// CHECK-NEXT:   | [sizeof=16, align=16]
+// CHECK-NEXT:   | [sizeof=8, align=8]
 
 struct s11 {
   char a;
Index: clang/lib/Basic/Targets/OSTargets.h
===
--- clang/lib/Basic/Targets/OSTargets.h
+++ clang/lib/Basic/Targets/OSTargets.h
@@ -796,7 +796,6 @@
 this->UseZeroLengthBitfieldAlignment = true;
 this->UseLeadingZeroLengthBitfield = false;
 this->ZeroLengthBitfieldBoundary = 32;
-this->DefaultAlignForAttributeAligned = 128;
   }
 };
 


Index: clang/test/CodeGen/SystemZ/zos-alignment.c
===
--- clang/test/CodeGen/SystemZ/zos-alignment.c
+++ clang/test/CodeGen/SystemZ/zos-alignment.c
@@ -147,7 +147,7 @@
 } S10;
 // CHECK:  0 | struct s10
 // CHECK-NEXT: 0 |   unsigned int a
-// CHECK-NEXT:   | [sizeof=16, align=16]
+// CHECK-NEXT:   | [sizeof=8, align=8]
 
 struct s11 {
   char a;
Index: clang/lib/Basic/Targets/OSTargets.h
===
--- clang/lib/Basic/Targets/OSTargets.h
+++ clang/lib/Basic/Targets/OSTargets.h
@@ -796,7 +796,6 @@
 this->UseZeroLengthBitfieldAlignment = true;
 this->UseLeadingZeroLengthBitfield = false;
 this->ZeroLengthBitfieldBoundary = 32;
-this->DefaultAlignForAttributeAligned = 128;
   }
 };
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] bdf4c7b - [z/OS]Remove overriding default attribute aligned value

2021-07-30 Thread Fanbo Meng via cfe-commits


Author: Fanbo Meng
Date: 2021-07-30T15:51:40-04:00
New Revision: bdf4c7b738ee3dfbcd468ec347beec58b6e43a5a

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

LOG: [z/OS]Remove overriding default attribute aligned value

Make DefaultAlignForAttributeAligned consistent with SystemZ.

Reviewed By: abhina.sreeskantharajan, anirudhp

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

Added: 


Modified: 
clang/lib/Basic/Targets/OSTargets.h
clang/test/CodeGen/SystemZ/zos-alignment.c

Removed: 




diff  --git a/clang/lib/Basic/Targets/OSTargets.h 
b/clang/lib/Basic/Targets/OSTargets.h
index 6329acf756834..9780d5036aa23 100644
--- a/clang/lib/Basic/Targets/OSTargets.h
+++ b/clang/lib/Basic/Targets/OSTargets.h
@@ -796,7 +796,6 @@ class LLVM_LIBRARY_VISIBILITY ZOSTargetInfo : public 
OSTargetInfo {
 this->UseZeroLengthBitfieldAlignment = true;
 this->UseLeadingZeroLengthBitfield = false;
 this->ZeroLengthBitfieldBoundary = 32;
-this->DefaultAlignForAttributeAligned = 128;
   }
 };
 

diff  --git a/clang/test/CodeGen/SystemZ/zos-alignment.c 
b/clang/test/CodeGen/SystemZ/zos-alignment.c
index 7b08f4bf7f4a7..be26c5a2785dd 100644
--- a/clang/test/CodeGen/SystemZ/zos-alignment.c
+++ b/clang/test/CodeGen/SystemZ/zos-alignment.c
@@ -147,7 +147,7 @@ struct s10 {
 } S10;
 // CHECK:  0 | struct s10
 // CHECK-NEXT: 0 |   unsigned int a
-// CHECK-NEXT:   | [sizeof=16, align=16]
+// CHECK-NEXT:   | [sizeof=8, align=8]
 
 struct s11 {
   char a;



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

[PATCH] D104058: ThinLTO: Fix inline assembly references to static functions with CFI

2021-07-30 Thread Nick Desaulniers via Phabricator via cfe-commits

nickdesaulniers added inline comments.



Comment at: llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp:45
+  }
+  return true;
+}

samitolvanen wrote:
> nickdesaulniers wrote:
> > samitolvanen wrote:
> > > nickdesaulniers wrote:
> > > > Can llvm::any_of or llvm::none_of be used here?
> > > > llvm/ADT/STLExtras.h
> > > Maybe, but I don't see how they would make this function any cleaner. Did 
> > > you have something specific in mind?
> > Something like?
> > 
> > return any_of(Name, [](const char ) { return isAlnum(C) || C == '_' || C 
> > == '.'; }
> > 
> > or maybe we need !none_of(...)? (not sure if characters of a string can be 
> > enumerated this way)
> Since we want to ensure all the characters in the string match the predicate, 
> I believe it would make sense to use `all_of()` instead.
> 
> However, I don't see the point of introducing additional complexity to such a 
> trivial function to shave off a couple of lines of code. While it might not 
> actually matter here, using `all_of()` also seems to generate ~5x as many 
> instructions to execute:
> 
> https://godbolt.org/z/Pndfxj6rM
> 
> If you feel like the current version is too long, I can drop one line by 
> changing the loop to use:
> ```
> if (!isAlnum(C) && C != '_' && C != '.')
>   return false;
> ```
> I initially wanted to keep the test identical to 
> `MCAsmInfo::isAcceptableChar()` to make it easier to see it actually matches, 
> but since it's no longer identical, I suppose that doesn't matter.
> 
> Thoughts?
> using all_of() also seems to generate ~5x as many instructions to execute:

Hard to argue with that.

Might be nice to add some test coverage of this code with an mscv target triple 
though.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104058

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

[PATCH] D104058: ThinLTO: Fix inline assembly references to static functions with CFI

2021-07-30 Thread Reid Kleckner via Phabricator via cfe-commits

rnk added a comment.

I think the new approach of skipping non C-ish identifier names is reasonable. 
Looks good to me, but wait for the more active reviewers to stamp it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104058

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

[PATCH] D106900: [PowerPC][AIX] Packed zero-width bitfields do not affect alignment.

2021-07-30 Thread Steven Wan via Phabricator via cfe-commits

stevewan added inline comments.



Comment at: clang/lib/AST/RecordLayoutBuilder.cpp:1783
+if (FieldPacked) {
+  FieldAlign = UnpackedFieldAlign = 1;
+} else if (!MaxFieldAlignment.isZero()) {

`UnpackedFieldAlign` is used to check if the packed attribute is unnecessary 
(-Wpacked). here the attribute is making a difference, we probably shouldn't 
set `FieldAlign = UnpackedFieldAlign`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106900

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

[PATCH] D107189: [z/OS]Remove overriding default attribute aligned value

2021-07-30 Thread Abhina Sree via Phabricator via cfe-commits

abhina.sreeskantharajan accepted this revision.
abhina.sreeskantharajan added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107189

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

[clang] 9019b55 - [PowerPC] Fix byte ordering of ld/st with length on BE

2021-07-30 Thread Nemanja Ivanovic via cfe-commits


Author: Nemanja Ivanovic
Date: 2021-07-30T14:37:24-05:00
New Revision: 9019b55b605a26cb5389399eceb34fa9ea0f

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

LOG: [PowerPC] Fix byte ordering of ld/st with length on BE

The builtins vec_xl_len_r and vec_xst_len_r actually use the
wrong side of the vector on big endian Power9 systems. We never
spotted this before because there was no such thing as a big
endian distro that supported Power9. Now we have AIX and the
elements are in the wrong part of the vector. This just fixes
it so the elements are loaded to and stored from the right
side of the vector.

Added: 


Modified: 
clang/lib/Headers/altivec.h
clang/test/CodeGen/builtins-ppc-ld-st-rmb.c
clang/test/CodeGen/builtins-ppc-p9vector.c

Removed: 




diff  --git a/clang/lib/Headers/altivec.h b/clang/lib/Headers/altivec.h
index 0dd8c859366b..d548d8a0dd75 100644
--- a/clang/lib/Headers/altivec.h
+++ b/clang/lib/Headers/altivec.h
@@ -3049,13 +3049,10 @@ static __inline__ vector unsigned char __ATTRS_o_ai
 vec_xl_len_r(const unsigned char *__a, size_t __b) {
   vector unsigned char __res =
   (vector unsigned char)__builtin_vsx_lxvll(__a, (__b << 56));
-#ifdef __LITTLE_ENDIAN__
   vector unsigned char __mask =
   (vector unsigned char)__builtin_altivec_lvsr(16 - __b, (int *)NULL);
-  __res = (vector unsigned char)__builtin_altivec_vperm_4si(
+  return (vector unsigned char)__builtin_altivec_vperm_4si(
   (vector int)__res, (vector int)__res, __mask);
-#endif
-  return __res;
 }
 
 // vec_xst_len
@@ -3130,15 +3127,11 @@ static __inline__ void __ATTRS_o_ai vec_xst_len(vector 
double __a, double *__b,
 static __inline__ void __ATTRS_o_ai vec_xst_len_r(vector unsigned char __a,
   unsigned char *__b,
   size_t __c) {
-#ifdef __LITTLE_ENDIAN__
   vector unsigned char __mask =
   (vector unsigned char)__builtin_altivec_lvsl(16 - __c, (int *)NULL);
   vector unsigned char __res =
   __builtin_altivec_vperm_4si((vector int)__a, (vector int)__a, __mask);
   return __builtin_vsx_stxvll((vector int)__res, __b, (__c << 56));
-#else
-  return __builtin_vsx_stxvll((vector int)__a, __b, (__c << 56));
-#endif
 }
 #endif
 #endif

diff  --git a/clang/test/CodeGen/builtins-ppc-ld-st-rmb.c 
b/clang/test/CodeGen/builtins-ppc-ld-st-rmb.c
index 0921d05f0325..76eb87c8db59 100644
--- a/clang/test/CodeGen/builtins-ppc-ld-st-rmb.c
+++ b/clang/test/CodeGen/builtins-ppc-ld-st-rmb.c
@@ -46,6 +46,7 @@
 // BE-PWR9-NEXT:[[__A_ADDR_I:%.*]] = alloca i8*, align 8
 // BE-PWR9-NEXT:[[__B_ADDR_I:%.*]] = alloca i64, align 8
 // BE-PWR9-NEXT:[[__RES_I:%.*]] = alloca <16 x i8>, align 16
+// BE-PWR9-NEXT:[[__MASK_I:%.*]] = alloca <16 x i8>, align 16
 // BE-PWR9-NEXT:[[PTR_ADDR:%.*]] = alloca i8*, align 8
 // BE-PWR9-NEXT:store i8* [[PTR:%.*]], i8** [[PTR_ADDR]], align 8
 // BE-PWR9-NEXT:[[TMP0:%.*]] = load i8*, i8** [[PTR_ADDR]], align 8
@@ -54,11 +55,23 @@
 // BE-PWR9-NEXT:[[TMP1:%.*]] = load i8*, i8** [[__A_ADDR_I]], align 8
 // BE-PWR9-NEXT:[[TMP2:%.*]] = load i64, i64* [[__B_ADDR_I]], align 8
 // BE-PWR9-NEXT:[[SHL_I:%.*]] = shl i64 [[TMP2]], 56
-// BE-PWR9-NEXT:[[TMP3:%.*]] = call <4 x i32> @llvm.ppc.vsx.lxvll(i8* 
[[TMP1]], i64 [[SHL_I]]) #[[ATTR3:[0-9]+]]
+// BE-PWR9-NEXT:[[TMP3:%.*]] = call <4 x i32> @llvm.ppc.vsx.lxvll(i8* 
[[TMP1]], i64 [[SHL_I]]) #[[ATTR4:[0-9]+]]
 // BE-PWR9-NEXT:[[TMP4:%.*]] = bitcast <4 x i32> [[TMP3]] to <16 x i8>
 // BE-PWR9-NEXT:store <16 x i8> [[TMP4]], <16 x i8>* [[__RES_I]], align 16
-// BE-PWR9-NEXT:[[TMP5:%.*]] = load <16 x i8>, <16 x i8>* [[__RES_I]], 
align 16
-// BE-PWR9-NEXT:ret <16 x i8> [[TMP5]]
+// BE-PWR9-NEXT:[[TMP5:%.*]] = load i64, i64* [[__B_ADDR_I]], align 8
+// BE-PWR9-NEXT:[[SUB_I:%.*]] = sub i64 16, [[TMP5]]
+// BE-PWR9-NEXT:[[CONV_I:%.*]] = trunc i64 [[SUB_I]] to i8
+// BE-PWR9-NEXT:[[TMP6:%.*]] = getelementptr i8, i8* null, i8 [[CONV_I]]
+// BE-PWR9-NEXT:[[TMP7:%.*]] = call <16 x i8> @llvm.ppc.altivec.lvsr(i8* 
[[TMP6]]) #[[ATTR4]]
+// BE-PWR9-NEXT:store <16 x i8> [[TMP7]], <16 x i8>* [[__MASK_I]], align 16
+// BE-PWR9-NEXT:[[TMP8:%.*]] = load <16 x i8>, <16 x i8>* [[__RES_I]], 
align 16
+// BE-PWR9-NEXT:[[TMP9:%.*]] = bitcast <16 x i8> [[TMP8]] to <4 x i32>
+// BE-PWR9-NEXT:[[TMP10:%.*]] = load <16 x i8>, <16 x i8>* [[__RES_I]], 
align 16
+// BE-PWR9-NEXT:[[TMP11:%.*]] = bitcast <16 x i8> [[TMP10]] to <4 x i32>
+// BE-PWR9-NEXT:[[TMP12:%.*]] = load <16 x i8>, <16 x i8>* [[__MASK_I]], 
align 16
+// BE-PWR9-NEXT:[[TMP13:%.*]] = call <4 x i32> @llvm.ppc.altivec.vperm(<4 
x i32> [[TMP9]], <4 x i32> [[TMP11]], <16 x i8> [[TMP12]])

[PATCH] D107155: [clang][deps] Substitute clang-scan-deps executable in lit tests

2021-07-30 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits

dexonsmith added a comment.

In D107155#2916664 , @dblaikie wrote:

> Hmm, don't we have some other substitution feature that avoids the need to 
> add the %? (like, I think LLVM's tests don't usually use the % for many tool 
> names - but they still make for good copy/pastable command lines, if I'm not 
> mistaken?)

I think that'd be adding clang-scan-deps somehow to the `tools` variable in 
clang/test/lit.cfg.py:
 https://github.com/llvm/llvm-project/blob/main/clang/test/lit.cfg.py#L59
(which will then call `add_tool_substitutions` at 
https://github.com/llvm/llvm-project/blob/main/clang/test/lit.cfg.py#L111)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107155

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

[PATCH] D74436: Change clang option -ffp-model=precise to select ffp-contract=on

2021-07-30 Thread Melanie Blower via Phabricator via cfe-commits

mibintc added a comment.

In D74436#2917357 , @haowei wrote:

> We are seeing float related unit tests failing in Fuchsia after this patch. 
> What flags should we add to our build to match llvm's previous float point 
> behavior?

This option: ffp-contract=off


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74436

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

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

2021-07-30 Thread Vassil Vassilev via Phabricator via cfe-commits

v.g.vassilev added inline comments.



Comment at: clang/unittests/Interpreter/InterpreterTest.cpp:64
+// address of main, and some platforms can't implement GetMainExecutable
+// without being given the address of a function in the main executable).
+std::string GetExecutablePath(const char *Argv0, void *MainAddr) {

rsmith wrote:
> I don't follow why this can't be static. Is there some problem with using the 
> address of this function if it's static?
That's a standard comment for each `GetExecutablePath` and I copy pasted it as 
done elsewhere. That requirement might be lifted in recent systems but I do not 
know the platform coverage to check.


Repository:
  rC Clang

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

https://reviews.llvm.org/D107049

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

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

2021-07-30 Thread Richard Smith - zygoloid via Phabricator via cfe-commits

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



Comment at: clang/unittests/Interpreter/InterpreterTest.cpp:64
+// address of main, and some platforms can't implement GetMainExecutable
+// without being given the address of a function in the main executable).
+std::string GetExecutablePath(const char *Argv0, void *MainAddr) {

I don't follow why this can't be static. Is there some problem with using the 
address of this function if it's static?


Repository:
  rC Clang

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

https://reviews.llvm.org/D107049

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

[PATCH] D104058: ThinLTO: Fix inline assembly references to static functions with CFI

2021-07-30 Thread Sami Tolvanen via Phabricator via cfe-commits

samitolvanen added inline comments.

Comment at: llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp:45
+  }
+  return true;
+}

nickdesaulniers wrote:
> samitolvanen wrote:
> > nickdesaulniers wrote:
> > > Can llvm::any_of or llvm::none_of be used here?
> > > llvm/ADT/STLExtras.h
> > Maybe, but I don't see how they would make this function any cleaner. Did 
> > you have something specific in mind?
> Something like?
> 
> return any_of(Name, [](const char ) { return isAlnum(C) || C == '_' || C == 
> '.'; }
> 
> or maybe we need !none_of(...)? (not sure if characters of a string can be 
> enumerated this way)
Since we want to ensure all the characters in the string match the predicate, I 
believe it would make sense to use `all_of()` instead.

However, I don't see the point of introducing additional complexity to such a 
trivial function to shave off a couple of lines of code. While it might not 
actually matter here, using `all_of()` also seems to generate ~5x as many 
instructions to execute:

https://godbolt.org/z/Pndfxj6rM

If you feel like the current version is too long, I can drop one line by 
changing the loop to use:
```
if (!isAlnum(C) && C != '_' && C != '.')
  return false;
```
I initially wanted to keep the test identical to 
`MCAsmInfo::isAcceptableChar()` to make it easier to see it actually matches, 
but since it's no longer identical, I suppose that doesn't matter.

Thoughts?

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104058

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

[PATCH] D74436: Change clang option -ffp-model=precise to select ffp-contract=on

2021-07-30 Thread Haowei Wu via Phabricator via cfe-commits

haowei added a comment.

We are seeing float related unit tests failing in Fuchsia after this patch. 
What flags should we add to our build to match llvm's previous float point 
behavior?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74436

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

[PATCH] D107190: [AMDGPU][HIP] Switch default DWARF version to 5

2021-07-30 Thread Scott Linder via Phabricator via cfe-commits

scott.linder created this revision.
Herald added subscribers: kerbowa, t-tye, tpr, dstuttard, yaxunl, nhaehnle, 
jvesely, kzhuravl.
scott.linder requested review of this revision.
Herald added subscribers: cfe-commits, wdng.
Herald added a project: clang.

Another attempt at changing this default, now that tooling has greater
support for DWARF 5.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D107190

Files:
  clang/lib/Driver/ToolChains/AMDGPU.h
  clang/lib/Driver/ToolChains/HIP.h
  clang/test/Driver/amdgpu-toolchain.c
  clang/test/Driver/hip-toolchain-dwarf.hip


Index: clang/test/Driver/hip-toolchain-dwarf.hip
===
--- clang/test/Driver/hip-toolchain-dwarf.hip
+++ clang/test/Driver/hip-toolchain-dwarf.hip
@@ -6,4 +6,4 @@
 // RUN:   -x hip --cuda-gpu-arch=gfx803 %s \
 // RUN:   -Xarch_gfx803 -g 2>&1 | FileCheck %s -check-prefix=DWARF_VER
 
-// DWARF_VER: "-dwarf-version=4"
+// DWARF_VER: "-dwarf-version=5"
Index: clang/test/Driver/amdgpu-toolchain.c
===
--- clang/test/Driver/amdgpu-toolchain.c
+++ clang/test/Driver/amdgpu-toolchain.c
@@ -8,7 +8,7 @@
 // AS_LINK: clang{{.*}} "-cc1as"
 // AS_LINK: ld.lld{{.*}} "-shared"
 
-// DWARF_VER: "-dwarf-version=4"
+// DWARF_VER: "-dwarf-version=5"
 
 // RUN: %clang -### -target amdgcn-amd-amdhsa -mcpu=gfx906 -nogpulib \
 // RUN:   -flto %s 2>&1 | FileCheck -check-prefix=LTO %s
Index: clang/lib/Driver/ToolChains/HIP.h
===
--- clang/lib/Driver/ToolChains/HIP.h
+++ clang/lib/Driver/ToolChains/HIP.h
@@ -92,7 +92,7 @@
   computeMSVCVersion(const Driver *D,
  const llvm::opt::ArgList ) const override;
 
-  unsigned GetDefaultDwarfVersion() const override { return 4; }
+  unsigned GetDefaultDwarfVersion() const override { return 5; }
 
   const ToolChain 
   void checkTargetID(const llvm::opt::ArgList ) const override;
Index: clang/lib/Driver/ToolChains/AMDGPU.h
===
--- clang/lib/Driver/ToolChains/AMDGPU.h
+++ clang/lib/Driver/ToolChains/AMDGPU.h
@@ -60,7 +60,7 @@
 public:
   AMDGPUToolChain(const Driver , const llvm::Triple ,
   const llvm::opt::ArgList );
-  unsigned GetDefaultDwarfVersion() const override { return 4; }
+  unsigned GetDefaultDwarfVersion() const override { return 5; }
   bool IsIntegratedAssemblerDefault() const override { return true; }
   bool IsMathErrnoDefault() const override { return false; }
 


Index: clang/test/Driver/hip-toolchain-dwarf.hip
===
--- clang/test/Driver/hip-toolchain-dwarf.hip
+++ clang/test/Driver/hip-toolchain-dwarf.hip
@@ -6,4 +6,4 @@
 // RUN:   -x hip --cuda-gpu-arch=gfx803 %s \
 // RUN:   -Xarch_gfx803 -g 2>&1 | FileCheck %s -check-prefix=DWARF_VER
 
-// DWARF_VER: "-dwarf-version=4"
+// DWARF_VER: "-dwarf-version=5"
Index: clang/test/Driver/amdgpu-toolchain.c
===
--- clang/test/Driver/amdgpu-toolchain.c
+++ clang/test/Driver/amdgpu-toolchain.c
@@ -8,7 +8,7 @@
 // AS_LINK: clang{{.*}} "-cc1as"
 // AS_LINK: ld.lld{{.*}} "-shared"
 
-// DWARF_VER: "-dwarf-version=4"
+// DWARF_VER: "-dwarf-version=5"
 
 // RUN: %clang -### -target amdgcn-amd-amdhsa -mcpu=gfx906 -nogpulib \
 // RUN:   -flto %s 2>&1 | FileCheck -check-prefix=LTO %s
Index: clang/lib/Driver/ToolChains/HIP.h
===
--- clang/lib/Driver/ToolChains/HIP.h
+++ clang/lib/Driver/ToolChains/HIP.h
@@ -92,7 +92,7 @@
   computeMSVCVersion(const Driver *D,
  const llvm::opt::ArgList ) const override;
 
-  unsigned GetDefaultDwarfVersion() const override { return 4; }
+  unsigned GetDefaultDwarfVersion() const override { return 5; }
 
   const ToolChain 
   void checkTargetID(const llvm::opt::ArgList ) const override;
Index: clang/lib/Driver/ToolChains/AMDGPU.h
===
--- clang/lib/Driver/ToolChains/AMDGPU.h
+++ clang/lib/Driver/ToolChains/AMDGPU.h
@@ -60,7 +60,7 @@
 public:
   AMDGPUToolChain(const Driver , const llvm::Triple ,
   const llvm::opt::ArgList );
-  unsigned GetDefaultDwarfVersion() const override { return 4; }
+  unsigned GetDefaultDwarfVersion() const override { return 5; }
   bool IsIntegratedAssemblerDefault() const override { return true; }
   bool IsMathErrnoDefault() const override { return false; }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D94639: [DebugInfo][CodeView] Change in line tables only mode to emit parent/context scopes for functions, using declarations for types

2021-07-30 Thread Sergey Makarov via Phabricator via cfe-commits

SeTSeR added a comment.

Hello! As far as I understand, Clang does not preserve info about namespace for 
functions declared in namespaces with `-gline-numbers-only` flag. Is there any 
way to retrieve this info for DWARF? I thought FIXME at line 261 in CGDebugInfo 
was addressing exactly this issue.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94639

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

[PATCH] D107189: [z/OS]Remove overriding default attribute aligned value

2021-07-30 Thread Fanbo Meng via Phabricator via cfe-commits

fanbo-meng created this revision.
fanbo-meng requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Make DefaultAlignForAttributeAligned consistent with SystemZ.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D107189

Files:
  clang/lib/Basic/Targets/OSTargets.h
  clang/test/CodeGen/SystemZ/zos-alignment.c


Index: clang/test/CodeGen/SystemZ/zos-alignment.c
===
--- clang/test/CodeGen/SystemZ/zos-alignment.c
+++ clang/test/CodeGen/SystemZ/zos-alignment.c
@@ -147,7 +147,7 @@
 } S10;
 // CHECK:  0 | struct s10
 // CHECK-NEXT: 0 |   unsigned int a
-// CHECK-NEXT:   | [sizeof=16, align=16]
+// CHECK-NEXT:   | [sizeof=8, align=8]
 
 struct s11 {
   char a;
Index: clang/lib/Basic/Targets/OSTargets.h
===
--- clang/lib/Basic/Targets/OSTargets.h
+++ clang/lib/Basic/Targets/OSTargets.h
@@ -796,7 +796,6 @@
 this->UseZeroLengthBitfieldAlignment = true;
 this->UseLeadingZeroLengthBitfield = false;
 this->ZeroLengthBitfieldBoundary = 32;
-this->DefaultAlignForAttributeAligned = 128;
   }
 };
 


Index: clang/test/CodeGen/SystemZ/zos-alignment.c
===
--- clang/test/CodeGen/SystemZ/zos-alignment.c
+++ clang/test/CodeGen/SystemZ/zos-alignment.c
@@ -147,7 +147,7 @@
 } S10;
 // CHECK:  0 | struct s10
 // CHECK-NEXT: 0 |   unsigned int a
-// CHECK-NEXT:   | [sizeof=16, align=16]
+// CHECK-NEXT:   | [sizeof=8, align=8]
 
 struct s11 {
   char a;
Index: clang/lib/Basic/Targets/OSTargets.h
===
--- clang/lib/Basic/Targets/OSTargets.h
+++ clang/lib/Basic/Targets/OSTargets.h
@@ -796,7 +796,6 @@
 this->UseZeroLengthBitfieldAlignment = true;
 this->UseLeadingZeroLengthBitfield = false;
 this->ZeroLengthBitfieldBoundary = 32;
-this->DefaultAlignForAttributeAligned = 128;
   }
 };
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D105821: [analyzer] [WIP] Model destructor for std::unique_ptr

2021-07-30 Thread Deep Majumder via Phabricator via cfe-commits

RedDocMD added a comment.

Well some of them are exactly the same type as the `Lame` class example above. 
Like: 
`simbody/report-TestArray.cpp-testMoveConstructionAndAssignment-27-1.html#EndPath`.
 (So the incomplete modelling of the destructor is at least one cause. The 
other reason that you suggested might as well be true).
Btw, the `destructor1.txt` file from my previous comment should be used to 
drill down the newly added reports.

F18239807: simbody.tar.xz 

F18239806: fmt.tar.xz 

F18239805: faiss.tar.xz 

F18239804: re2.tar.xz 

F18239803: oatpp.tar.xz 

F18239802: drogon.tar.xz 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105821

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

[PATCH] D99364: [clang][cache] Update Fuchsia-stage2.cmake to create hwasan multilibs

2021-07-30 Thread Leonard Chan via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rGbb438f6cbfc0: [clang][cache] Update Fuchsia-stage2.cmake to 
create hwasan multilibs (authored by leonardchan).

Changed prior to commit:
  https://reviews.llvm.org/D99364?vs=349700=363173#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99364

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -226,11 +226,30 @@
 list(APPEND RUNTIME_BUILD_ID_LINK "${target}")
   endforeach()
 
-  set(LLVM_RUNTIME_MULTILIBS "asan;noexcept;compat;asan+noexcept" CACHE STRING 
"")
+  # HWAsan
+  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan_LLVM_BUILD_COMPILER_RT OFF CACHE 
BOOL "")
+  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan_LLVM_USE_SANITIZER "HWAddress" 
CACHE STRING "")
+  
set(RUNTIMES_aarch64-unknown-fuchsia+hwasan_LIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS
 OFF CACHE BOOL "")
+  
set(RUNTIMES_aarch64-unknown-fuchsia+hwasan_LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS
 OFF CACHE BOOL "")
+  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan_CMAKE_CXX_FLAGS 
"${RUNTIMES_aarch64-unknown-fuchsia+hwasan_CMAKE_CXX_FLAGS} -mllvm 
--hwasan-globals=0" CACHE STRING "")
+
+  # HWASan+noexcept
+  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_LLVM_BUILD_COMPILER_RT 
OFF CACHE BOOL "")
+  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_LLVM_USE_SANITIZER 
"HWAddress" CACHE STRING "")
+  
set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_LIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS
 OFF CACHE BOOL "")
+  
set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS
 OFF CACHE BOOL "")
+  
set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_LIBCXXABI_ENABLE_EXCEPTIONS
 OFF CACHE BOOL "")
+  
set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_LIBCXX_ENABLE_EXCEPTIONS 
OFF CACHE BOOL "")
+  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_CMAKE_CXX_FLAGS 
"${RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_CMAKE_CXX_FLAGS} -mllvm 
--hwasan-globals=0" CACHE STRING "")
+
+  set(LLVM_RUNTIME_MULTILIBS 
"asan;noexcept;compat;asan+noexcept;hwasan;hwasan+noexcept" CACHE STRING "")
+
   set(LLVM_RUNTIME_MULTILIB_asan_TARGETS 
"x86_64-unknown-fuchsia;aarch64-unknown-fuchsia" CACHE STRING "")
   set(LLVM_RUNTIME_MULTILIB_noexcept_TARGETS 
"x86_64-unknown-fuchsia;aarch64-unknown-fuchsia" CACHE STRING "")
   set(LLVM_RUNTIME_MULTILIB_compat_TARGETS 
"x86_64-unknown-fuchsia;aarch64-unknown-fuchsia" CACHE STRING "")
   set(LLVM_RUNTIME_MULTILIB_asan+noexcept_TARGETS 
"x86_64-unknown-fuchsia;aarch64-unknown-fuchsia" CACHE STRING "")
+  set(LLVM_RUNTIME_MULTILIB_hwasan_TARGETS "aarch64-unknown-fuchsia" CACHE 
STRING "")
+  set(LLVM_RUNTIME_MULTILIB_hwasan+noexcept_TARGETS "aarch64-unknown-fuchsia" 
CACHE STRING "")
 endif()
 
 set(LLVM_BUILTIN_TARGETS "${BUILTIN_TARGETS}" CACHE STRING "")


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -226,11 +226,30 @@
 list(APPEND RUNTIME_BUILD_ID_LINK "${target}")
   endforeach()
 
-  set(LLVM_RUNTIME_MULTILIBS "asan;noexcept;compat;asan+noexcept" CACHE STRING "")
+  # HWAsan
+  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan_LLVM_BUILD_COMPILER_RT OFF CACHE BOOL "")
+  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan_LLVM_USE_SANITIZER "HWAddress" CACHE STRING "")
+  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan_LIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS OFF CACHE BOOL "")
+  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan_LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS OFF CACHE BOOL "")
+  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan_CMAKE_CXX_FLAGS "${RUNTIMES_aarch64-unknown-fuchsia+hwasan_CMAKE_CXX_FLAGS} -mllvm --hwasan-globals=0" CACHE STRING "")
+
+  # HWASan+noexcept
+  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_LLVM_BUILD_COMPILER_RT OFF CACHE BOOL "")
+  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_LLVM_USE_SANITIZER "HWAddress" CACHE STRING "")
+  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_LIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS OFF CACHE BOOL "")
+  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS OFF CACHE BOOL "")
+  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_LIBCXXABI_ENABLE_EXCEPTIONS OFF CACHE BOOL "")
+  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_LIBCXX_ENABLE_EXCEPTIONS OFF CACHE BOOL "")
+  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_CMAKE_CXX_FLAGS "${RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_CMAKE_CXX_FLAGS} -mllvm --hwasan-globals=0" CACHE STRING "")
+
+  set(LLVM_RUNTIME_MULTILIBS "asan;noexcept;compat;asan+noexcept;hwasan;hwasan+noexcept"

[clang] bb438f6 - [clang][cache] Update Fuchsia-stage2.cmake to create hwasan multilibs

2021-07-30 Thread Leonard Chan via cfe-commits


Author: Leonard Chan
Date: 2021-07-30T11:53:21-07:00
New Revision: bb438f6cbfc08eaa2cd9124a0ad581dd29f819b4

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

LOG: [clang][cache] Update Fuchsia-stage2.cmake to create hwasan multilibs

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

Added: 


Modified: 
clang/cmake/caches/Fuchsia-stage2.cmake

Removed: 




diff  --git a/clang/cmake/caches/Fuchsia-stage2.cmake 
b/clang/cmake/caches/Fuchsia-stage2.cmake
index aa45c1549340b..8c7518d7da312 100644
--- a/clang/cmake/caches/Fuchsia-stage2.cmake
+++ b/clang/cmake/caches/Fuchsia-stage2.cmake
@@ -226,11 +226,30 @@ if(FUCHSIA_SDK)
 list(APPEND RUNTIME_BUILD_ID_LINK "${target}")
   endforeach()
 
-  set(LLVM_RUNTIME_MULTILIBS "asan;noexcept;compat;asan+noexcept" CACHE STRING 
"")
+  # HWAsan
+  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan_LLVM_BUILD_COMPILER_RT OFF CACHE 
BOOL "")
+  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan_LLVM_USE_SANITIZER "HWAddress" 
CACHE STRING "")
+  
set(RUNTIMES_aarch64-unknown-fuchsia+hwasan_LIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS
 OFF CACHE BOOL "")
+  
set(RUNTIMES_aarch64-unknown-fuchsia+hwasan_LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS
 OFF CACHE BOOL "")
+  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan_CMAKE_CXX_FLAGS 
"${RUNTIMES_aarch64-unknown-fuchsia+hwasan_CMAKE_CXX_FLAGS} -mllvm 
--hwasan-globals=0" CACHE STRING "")
+
+  # HWASan+noexcept
+  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_LLVM_BUILD_COMPILER_RT 
OFF CACHE BOOL "")
+  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_LLVM_USE_SANITIZER 
"HWAddress" CACHE STRING "")
+  
set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_LIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS
 OFF CACHE BOOL "")
+  
set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS
 OFF CACHE BOOL "")
+  
set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_LIBCXXABI_ENABLE_EXCEPTIONS
 OFF CACHE BOOL "")
+  
set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_LIBCXX_ENABLE_EXCEPTIONS 
OFF CACHE BOOL "")
+  set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_CMAKE_CXX_FLAGS 
"${RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_CMAKE_CXX_FLAGS} -mllvm 
--hwasan-globals=0" CACHE STRING "")
+
+  set(LLVM_RUNTIME_MULTILIBS 
"asan;noexcept;compat;asan+noexcept;hwasan;hwasan+noexcept" CACHE STRING "")
+
   set(LLVM_RUNTIME_MULTILIB_asan_TARGETS 
"x86_64-unknown-fuchsia;aarch64-unknown-fuchsia" CACHE STRING "")
   set(LLVM_RUNTIME_MULTILIB_noexcept_TARGETS 
"x86_64-unknown-fuchsia;aarch64-unknown-fuchsia" CACHE STRING "")
   set(LLVM_RUNTIME_MULTILIB_compat_TARGETS 
"x86_64-unknown-fuchsia;aarch64-unknown-fuchsia" CACHE STRING "")
   set(LLVM_RUNTIME_MULTILIB_asan+noexcept_TARGETS 
"x86_64-unknown-fuchsia;aarch64-unknown-fuchsia" CACHE STRING "")
+  set(LLVM_RUNTIME_MULTILIB_hwasan_TARGETS "aarch64-unknown-fuchsia" CACHE 
STRING "")
+  set(LLVM_RUNTIME_MULTILIB_hwasan+noexcept_TARGETS "aarch64-unknown-fuchsia" 
CACHE STRING "")
 endif()
 
 set(LLVM_BUILTIN_TARGETS "${BUILTIN_TARGETS}" CACHE STRING "")



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

[clang] a1532ed - [InstrProfiling] Make CountersPtr in __profd_ relative

2021-07-30 Thread Fangrui Song via cfe-commits


Author: Fangrui Song
Date: 2021-07-30T11:52:18-07:00
New Revision: a1532ed27582038e2d9588108ba0fe8237f01844

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

LOG: [InstrProfiling] Make CountersPtr in __profd_ relative

Change `CountersPtr` in `__profd_` to a label difference, which is a link-time
constant. On ELF, when linking a shared object, this requires that `__profc_` is
either private or linkonce/linkonce_odr hidden. On COFF, we need D104564 so that
`.quad a-b` (64-bit label difference) can lower to a 32-bit PC-relative 
relocation.

```
# ELF: R_X86_64_PC64 (PC-relative)
.quad .L__profc_foo-.L__profd_foo

# Mach-O: a pair of 8-byte X86_64_RELOC_UNSIGNED and X86_64_RELOC_SUBTRACTOR
.quad l___profc_foo-l___profd_foo

# COFF: we actually use IMAGE_REL_AMD64_REL32/IMAGE_REL_ARM64_REL32 so
# the high 32-bit value is zero even if .L__profc_foo < .L__profd_foo
# As compensation, we truncate CountersDelta in the header so that
# __llvm_profile_merge_from_buffer and llvm-profdata reader keep working.
.quad .L__profc_foo-.L__profd_foo
```

(Note: link.exe sorts `.lprfc` before `.lprfd` even if the object writer
has `.lprfd` before `.lprfc`, so we cannot work around by reordering
`.lprfc` and `.lprfd`.)

With this change, a stage 2 (`-DLLVM_TARGETS_TO_BUILD=X86 
-DLLVM_BUILD_INSTRUMENTED=IR`)
`ld -pie` linked clang is 1.74% smaller due to fewer R_X86_64_RELATIVE 
relocations.
```
% readelf -r pie | awk '$3~/R.*/{s[$3]++} END {for (k in s) print k, s[k]}'
R_X86_64_JUMP_SLO 331
R_X86_64_TPOFF64 2
R_X86_64_RELATIVE 476059  # was: 607712
R_X86_64_64 2616
R_X86_64_GLOB_DAT 31
```

The absolute function address (used by llvm-profdata to collect indirect call
targets) can be converted to relative as well, but is not done in this patch.

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

Added: 


Modified: 
clang/test/Profile/c-linkage-available_externally.c
compiler-rt/include/profile/InstrProfData.inc
compiler-rt/lib/profile/InstrProfilingMerge.c
compiler-rt/lib/profile/InstrProfilingWriter.c
llvm/include/llvm/ProfileData/InstrProfData.inc
llvm/lib/ProfileData/InstrProfReader.cpp
llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp
llvm/test/Instrumentation/InstrProfiling/icall.ll
llvm/test/Instrumentation/InstrProfiling/profiling.ll
llvm/test/Transforms/PGOProfile/comdat_internal.ll
llvm/test/Transforms/PGOProfile/indirect_call_profile.ll
llvm/test/Transforms/PGOProfile/memcpy.ll
llvm/test/tools/llvm-profdata/Inputs/c-general.profraw
llvm/test/tools/llvm-profdata/raw-32-bits-be.test
llvm/test/tools/llvm-profdata/raw-32-bits-le.test
llvm/test/tools/llvm-profdata/raw-64-bits-be.test
llvm/test/tools/llvm-profdata/raw-64-bits-le.test

Removed: 




diff  --git a/clang/test/Profile/c-linkage-available_externally.c 
b/clang/test/Profile/c-linkage-available_externally.c
index 5ac777b267ab8..5482fabc0aaa0 100644
--- a/clang/test/Profile/c-linkage-available_externally.c
+++ b/clang/test/Profile/c-linkage-available_externally.c
@@ -3,7 +3,7 @@
 // RUN: %clang_cc1 -O2 -triple x86_64-apple-macosx10.9 -main-file-name 
c-linkage-available_externally.c %s -o - -emit-llvm -fprofile-instrument=clang 
| FileCheck %s
 
 // CHECK: @__profc_foo = linkonce_odr hidden global [1 x i64] zeroinitializer, 
section "__DATA,__llvm_prf_cnts", align 8
-// CHECK: @__profd_foo = linkonce_odr hidden global {{.*}} i64* getelementptr 
inbounds ([1 x i64], [1 x i64]* @__profc_foo, i32 0, i32 0){{.*}}, section 
"__DATA,__llvm_prf_data,regular,live_support", align 8
+// CHECK: @__profd_foo = linkonce_odr hidden global {{.*}} i64 sub (i64 
ptrtoint ([1 x i64]* @__profc_foo to i64), i64 ptrtoint ({ i64, i64, i64, i8*, 
i8*, i32, [2 x i16] }* @__profd_foo to i64)), {{.*}}, section 
"__DATA,__llvm_prf_data,regular,live_support", align 8
 inline int foo(void) { return 1; }
 
 int main(void) {

diff  --git a/compiler-rt/include/profile/InstrProfData.inc 
b/compiler-rt/include/profile/InstrProfData.inc
index 08a6424696278..2870c9ffb97f3 100644
--- a/compiler-rt/include/profile/InstrProfData.inc
+++ b/compiler-rt/include/profile/InstrProfData.inc
@@ -75,9 +75,7 @@ INSTR_PROF_DATA(const uint64_t, llvm::Type::getInt64Ty(Ctx), 
NameRef, \
 INSTR_PROF_DATA(const uint64_t, llvm::Type::getInt64Ty(Ctx), FuncHash, \
 ConstantInt::get(llvm::Type::getInt64Ty(Ctx), \
 Inc->getHash()->getZExtValue()))
-INSTR_PROF_DATA(const IntPtrT, llvm::Type::getInt64PtrTy(Ctx), CounterPtr, \
-ConstantExpr::getBitCast(CounterPtr, \
-llvm::Type::getInt64PtrTy(Ctx)))
+INSTR_PROF_DATA(const IntPtrT, IntPtrTy, CounterPtr, RelativeCounterPtr)
 /* This is used to map function pointers for the indirect call targets to
  * function

[PATCH] D106959: [PowerPC] swdiv builtins for XL compatibility

2021-07-30 Thread Victor Huang via Phabricator via cfe-commits

NeHuang added inline comments.



Comment at: llvm/test/CodeGen/PowerPC/O3-pipeline.ll:211
   ret void
-}
\ No newline at end of file
+}

unrelated change?



Comment at: llvm/test/CodeGen/PowerPC/int-ppc-ftdivdp.ll:7
+; RUN: llc -verify-machineinstrs -mtriple=powerpc-unknown-aix \
+; RUN:   -mcpu=pwr8 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-unknown \

nit: `pwr7`  for aix run lines



Comment at: llvm/test/CodeGen/PowerPC/int-ppc-ftdivdp.ll:8
+; RUN:   -mcpu=pwr8 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-unknown \
+; RUN:   -mattr=-vsx -mcpu=pwr8 < %s | FileCheck %s --check-prefix=CHECK-NOVSX

can we also add a run line for 64 bit AIX?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106959

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

[PATCH] D107138: [PowerPC] Implement cmplxl builtins

2021-07-30 Thread Victor Huang via Phabricator via cfe-commits

NeHuang added inline comments.



Comment at: clang/test/CodeGen/builtins-ppc-xlcompat-complex.c:1
+// RUN: %clang_cc1 -O2 -triple powerpc64-unknown-unknown \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | FileCheck %s

`// REQUIRES: powerpc-registered-target`



Comment at: clang/test/CodeGen/builtins-ppc-xlcompat-complex.c:1
+// RUN: %clang_cc1 -O2 -triple powerpc64-unknown-unknown \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | FileCheck %s

NeHuang wrote:
> `// REQUIRES: powerpc-registered-target`
Question: why do we need `-O2` for this builtin?




Comment at: 
llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-complex-32bit-only.ll:1
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc-unknown-aix \

nemanjai wrote:
> I don't think we need the back end tests. No new IR is produced in this patch.
+1


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107138

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

[PATCH] D107002: [PowerPC] Implement XL compatibility builtin __addex

2021-07-30 Thread Victor Huang via Phabricator via cfe-commits

NeHuang added inline comments.



Comment at: clang/lib/Sema/SemaChecking.cpp:3426
+  case PPC::BI__builtin_ppc_addex: {
+if (SemaFeatureCheck(*this, TheCall, "power9-vector",
+ diag::err_ppc_builtin_only_on_arch, "9") ||

I think we start using `isa-v30-instructions` for pwr9 only (or later process)  
in `SemaFeatureCheck`



Comment at: clang/test/CodeGen/builtins-ppc-xlcompat-pwr9-warning.c:4
+// RUN:   -verify %s
+
+extern unsigned long long ull;

can we also add the run lines for 64 bit LE Linux, 64 bit AIX and 32 bit AIX?  
Will also need `#ifdef __PPC64__` for the test case. 



Comment at: llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-pwr9-64bit.ll:44
+
+define dso_local i64 @call_addex_1(i64 %a, i64 %b) {
+; CHECK-LABEL: call_addex_1:

This test case is identical as `call_addex_0`  The unsigned long long and 
signed long long scenarios produce identical IR and we should only keep one 
test case here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107002

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

[PATCH] D107176: [OpenCL] Replace test for pipe struct to test it with fixed triple

2021-07-30 Thread Anton Zabaznov via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG4e124ff25681: [OpenCL] Replace test for pipe struct to test 
it with fixed triple (authored by azabaznov).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107176

Files:
  clang/test/CodeGenOpenCL/pipe_builtin.cl
  clang/test/CodeGenOpenCL/pipe_types.cl


Index: clang/test/CodeGenOpenCL/pipe_types.cl
===
--- clang/test/CodeGenOpenCL/pipe_types.cl
+++ clang/test/CodeGenOpenCL/pipe_types.cl
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 
-cl-std=CL2.0 -o - %s | FileCheck %s
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 
-cl-std=CL3.0 
-cl-ext=+__opencl_c_pipes,+__opencl_c_generic_address_space,+__opencl_c_program_scope_global_variables
 -o - %s | FileCheck %s
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 
-cl-std=CL3.0 
-cl-ext=+__opencl_c_pipes,+__opencl_c_generic_address_space,-__opencl_c_program_scope_global_variables
 -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 
-cl-std=CL2.0 -DTEST_STRUCT -o - %s | FileCheck 
--check-prefixes=CHECK,CHECK-STRUCT %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 
-cl-std=CL3.0 
-cl-ext=+__opencl_c_pipes,+__opencl_c_generic_address_space,+__opencl_c_program_scope_global_variables
 -o - %s | FileCheck --check-prefixes=CHECK %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 
-cl-std=CL3.0 
-cl-ext=+__opencl_c_pipes,+__opencl_c_generic_address_space,-__opencl_c_program_scope_global_variables
 -o - %s | FileCheck --check-prefixes=CHECK %s
 
 // CHECK: %opencl.pipe_ro_t = type opaque
 // CHECK: %opencl.pipe_wo_t = type opaque
@@ -33,3 +33,21 @@
 kernel void test6(MyPipe p) {
 // CHECK: define{{.*}} spir_kernel void @test6(%opencl.pipe_ro_t* %p)
 }
+
+#ifdef TEST_STRUCT
+// FIXME: not supported for OpenCL C 3.0 as language built-ins not supported 
yet
+struct Person {
+  const char *Name;
+  bool isFemale;
+  int ID;
+};
+
+void test_reserved_read_pipe(global struct Person *SDst,
+ read_only pipe struct Person SPipe) {
+  // CHECK-STRUCT: define{{.*}} void @test_reserved_read_pipe
+  read_pipe (SPipe, SDst);
+  // CHECK-STRUCT: call i32 @__read_pipe_2(%opencl.pipe_ro_t* %{{.*}}, i8* 
%{{.*}}, i32 16, i32 8)
+  read_pipe (SPipe, SDst);
+  // CHECK-STRUCT: call i32 @__read_pipe_2(%opencl.pipe_ro_t* %{{.*}}, i8* 
%{{.*}}, i32 16, i32 8)
+}
+#endif // TEST_STRUCT
Index: clang/test/CodeGenOpenCL/pipe_builtin.cl
===
--- clang/test/CodeGenOpenCL/pipe_builtin.cl
+++ clang/test/CodeGenOpenCL/pipe_builtin.cl
@@ -71,16 +71,3 @@
   // CHECK: call i32 @__get_pipe_max_packets_wo(%opencl.pipe_wo_t* %{{.*}}, 
i32 4, i32 4)
   *ptr = get_pipe_max_packets(p);
 }
-
-struct Person {
-  const char *Name;
-  bool isFemale;
-  int ID;
-};
-
-void test9(global struct Person *SDst, read_only pipe struct Person SPipe) {
-  // CHECK: call i32 @__read_pipe_2(%opencl.pipe_ro_t* %{{.*}}, i8* %{{.*}}, 
i32 16, i32 8)
-  read_pipe (SPipe, SDst);
-  // CHECK: call i32 @__read_pipe_2(%opencl.pipe_ro_t* %{{.*}}, i8* %{{.*}}, 
i32 16, i32 8)
-  read_pipe (SPipe, SDst);
-}


Index: clang/test/CodeGenOpenCL/pipe_types.cl
===
--- clang/test/CodeGenOpenCL/pipe_types.cl
+++ clang/test/CodeGenOpenCL/pipe_types.cl
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 -cl-std=CL2.0 -o - %s | FileCheck %s
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 -cl-std=CL3.0 -cl-ext=+__opencl_c_pipes,+__opencl_c_generic_address_space,+__opencl_c_program_scope_global_variables -o - %s | FileCheck %s
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 -cl-std=CL3.0 -cl-ext=+__opencl_c_pipes,+__opencl_c_generic_address_space,-__opencl_c_program_scope_global_variables -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 -cl-std=CL2.0 -DTEST_STRUCT -o - %s | FileCheck --check-prefixes=CHECK,CHECK-STRUCT %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 -cl-std=CL3.0 -cl-ext=+__opencl_c_pipes,+__opencl_c_generic_address_space,+__opencl_c_program_scope_global_variables -o - %s | FileCheck --check-prefixes=CHECK %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 -cl-std=CL3.0 -cl-ext=+__opencl_c_pipes,+__opencl_c_generic_address_space,-__opencl_c_program_scope_global_variables -o - %s | FileCheck --check-prefixes=CHECK %s
 
 // CHECK: %opencl.pipe_ro_t = type opaque
 // CHECK: %opencl.pipe_wo_t = type opaque
@@ -33,3 +33,21 @@
 kernel void test6(MyPipe p) {
 // CHECK: define{{.*}} spir_kernel void @test6(%opencl.pipe_ro_t* %p)
 }
+
+#ifdef

[clang] 4e124ff - [OpenCL] Replace test for pipe struct to test it with fixed triple

2021-07-30 Thread Anton Zabaznov via cfe-commits


Author: Anton Zabaznov
Date: 2021-07-30T21:49:20+03:00
New Revision: 4e124ff256813f060efd2cc307358b1f7bf962c4

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

LOG: [OpenCL] Replace test for pipe struct to test it with fixed triple

Reviewed By: Anastasia

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

Added: 


Modified: 
clang/test/CodeGenOpenCL/pipe_builtin.cl
clang/test/CodeGenOpenCL/pipe_types.cl

Removed: 




diff  --git a/clang/test/CodeGenOpenCL/pipe_builtin.cl 
b/clang/test/CodeGenOpenCL/pipe_builtin.cl
index 227fa378c434..02b9669b7ab1 100644
--- a/clang/test/CodeGenOpenCL/pipe_builtin.cl
+++ b/clang/test/CodeGenOpenCL/pipe_builtin.cl
@@ -71,16 +71,3 @@ void test8(write_only pipe int p, global int *ptr) {
   // CHECK: call i32 @__get_pipe_max_packets_wo(%opencl.pipe_wo_t* %{{.*}}, 
i32 4, i32 4)
   *ptr = get_pipe_max_packets(p);
 }
-
-struct Person {
-  const char *Name;
-  bool isFemale;
-  int ID;
-};
-
-void test9(global struct Person *SDst, read_only pipe struct Person SPipe) {
-  // CHECK: call i32 @__read_pipe_2(%opencl.pipe_ro_t* %{{.*}}, i8* %{{.*}}, 
i32 16, i32 8)
-  read_pipe (SPipe, SDst);
-  // CHECK: call i32 @__read_pipe_2(%opencl.pipe_ro_t* %{{.*}}, i8* %{{.*}}, 
i32 16, i32 8)
-  read_pipe (SPipe, SDst);
-}

diff  --git a/clang/test/CodeGenOpenCL/pipe_types.cl 
b/clang/test/CodeGenOpenCL/pipe_types.cl
index 5247c9475df7..73ca15ea74d9 100644
--- a/clang/test/CodeGenOpenCL/pipe_types.cl
+++ b/clang/test/CodeGenOpenCL/pipe_types.cl
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 
-cl-std=CL2.0 -o - %s | FileCheck %s
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 
-cl-std=CL3.0 
-cl-ext=+__opencl_c_pipes,+__opencl_c_generic_address_space,+__opencl_c_program_scope_global_variables
 -o - %s | FileCheck %s
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 
-cl-std=CL3.0 
-cl-ext=+__opencl_c_pipes,+__opencl_c_generic_address_space,-__opencl_c_program_scope_global_variables
 -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 
-cl-std=CL2.0 -DTEST_STRUCT -o - %s | FileCheck 
--check-prefixes=CHECK,CHECK-STRUCT %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 
-cl-std=CL3.0 
-cl-ext=+__opencl_c_pipes,+__opencl_c_generic_address_space,+__opencl_c_program_scope_global_variables
 -o - %s | FileCheck --check-prefixes=CHECK %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 
-cl-std=CL3.0 
-cl-ext=+__opencl_c_pipes,+__opencl_c_generic_address_space,-__opencl_c_program_scope_global_variables
 -o - %s | FileCheck --check-prefixes=CHECK %s
 
 // CHECK: %opencl.pipe_ro_t = type opaque
 // CHECK: %opencl.pipe_wo_t = type opaque
@@ -33,3 +33,21 @@ typedef read_only pipe int MyPipe;
 kernel void test6(MyPipe p) {
 // CHECK: define{{.*}} spir_kernel void @test6(%opencl.pipe_ro_t* %p)
 }
+
+#ifdef TEST_STRUCT
+// FIXME: not supported for OpenCL C 3.0 as language built-ins not supported 
yet
+struct Person {
+  const char *Name;
+  bool isFemale;
+  int ID;
+};
+
+void test_reserved_read_pipe(global struct Person *SDst,
+ read_only pipe struct Person SPipe) {
+  // CHECK-STRUCT: define{{.*}} void @test_reserved_read_pipe
+  read_pipe (SPipe, SDst);
+  // CHECK-STRUCT: call i32 @__read_pipe_2(%opencl.pipe_ro_t* %{{.*}}, i8* 
%{{.*}}, i32 16, i32 8)
+  read_pipe (SPipe, SDst);
+  // CHECK-STRUCT: call i32 @__read_pipe_2(%opencl.pipe_ro_t* %{{.*}}, i8* 
%{{.*}}, i32 16, i32 8)
+}
+#endif // TEST_STRUCT



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

[PATCH] D103543: [compiler-rt][Fuchsia] Support HWASan on Fuchsia

2021-07-30 Thread Leonard Chan via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG606ca48d79f3: [compiler-rt][Fuchsia] Support HWASan on 
Fuchsia (authored by leonardchan).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103543

Files:
  compiler-rt/cmake/config-ix.cmake


Index: compiler-rt/cmake/config-ix.cmake
===
--- compiler-rt/cmake/config-ix.cmake
+++ compiler-rt/cmake/config-ix.cmake
@@ -711,7 +711,7 @@
 endif()
 
 if (COMPILER_RT_HAS_SANITIZER_COMMON AND HWASAN_SUPPORTED_ARCH AND
-OS_NAME MATCHES "Linux|Android")
+OS_NAME MATCHES "Linux|Android|Fuchsia")
   set(COMPILER_RT_HAS_HWASAN TRUE)
 else()
   set(COMPILER_RT_HAS_HWASAN FALSE)


Index: compiler-rt/cmake/config-ix.cmake
===
--- compiler-rt/cmake/config-ix.cmake
+++ compiler-rt/cmake/config-ix.cmake
@@ -711,7 +711,7 @@
 endif()
 
 if (COMPILER_RT_HAS_SANITIZER_COMMON AND HWASAN_SUPPORTED_ARCH AND
-OS_NAME MATCHES "Linux|Android")
+OS_NAME MATCHES "Linux|Android|Fuchsia")
   set(COMPILER_RT_HAS_HWASAN TRUE)
 else()
   set(COMPILER_RT_HAS_HWASAN FALSE)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D104058: ThinLTO: Fix inline assembly references to static functions with CFI

2021-07-30 Thread Nick Desaulniers via Phabricator via cfe-commits

nickdesaulniers added inline comments.



Comment at: llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp:45
+  }
+  return true;
+}

samitolvanen wrote:
> nickdesaulniers wrote:
> > Can llvm::any_of or llvm::none_of be used here?
> > llvm/ADT/STLExtras.h
> Maybe, but I don't see how they would make this function any cleaner. Did you 
> have something specific in mind?
Something like?

return any_of(Name, [](const char ) { return isAlnum(C) || C == '_' || C == 
'.'; }

or maybe we need !none_of(...)? (not sure if characters of a string can be 
enumerated this way)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104058

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

[PATCH] D104058: ThinLTO: Fix inline assembly references to static functions with CFI

2021-07-30 Thread Sami Tolvanen via Phabricator via cfe-commits

samitolvanen updated this revision to Diff 363166.
samitolvanen added a comment.

Also skip functions with names incompatible with XCOFF.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104058

Files:
  llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp
  llvm/test/ThinLTO/X86/devirt2.ll
  llvm/test/Transforms/ThinLTOBitcodeWriter/cfi-icall-static-inline-asm.ll
  llvm/test/Transforms/ThinLTOBitcodeWriter/split-internal2.ll
  llvm/test/Transforms/ThinLTOBitcodeWriter/split-vfunc-internal.ll

Index: llvm/test/Transforms/ThinLTOBitcodeWriter/split-vfunc-internal.ll
===
--- llvm/test/Transforms/ThinLTOBitcodeWriter/split-vfunc-internal.ll
+++ llvm/test/Transforms/ThinLTOBitcodeWriter/split-vfunc-internal.ll
@@ -1,7 +1,10 @@
+; REQUIRES: x86-registered-target
 ; RUN: opt -thinlto-bc -thinlto-split-lto-unit -o %t %s
 ; RUN: llvm-modextract -b -n 0 -o - %t | llvm-dis | FileCheck --check-prefix=M0 %s
 ; RUN: llvm-modextract -b -n 1 -o - %t | llvm-dis | FileCheck --check-prefix=M1 %s
 
+target triple = "x86_64-unknown-linux-gnu"
+
 define [1 x i8*]* @source() {
   ret [1 x i8*]* @g
 }
Index: llvm/test/Transforms/ThinLTOBitcodeWriter/split-internal2.ll
===
--- llvm/test/Transforms/ThinLTOBitcodeWriter/split-internal2.ll
+++ llvm/test/Transforms/ThinLTOBitcodeWriter/split-internal2.ll
@@ -1,3 +1,4 @@
+; REQUIRES: x86-registered-target
 ; RUN: opt -thinlto-bc -thinlto-split-lto-unit -o %t %s
 ; RUN: llvm-modextract -b -n 0 -o %t0 %t
 ; RUN: llvm-modextract -b -n 1 -o %t1 %t
@@ -7,6 +8,8 @@
 ; RUN: llvm-bcanalyzer -dump %t0 | FileCheck --check-prefix=BCA0 %s
 ; RUN: llvm-bcanalyzer -dump %t1 | FileCheck --check-prefix=BCA1 %s
 
+target triple = "x86_64-unknown-linux-gnu"
+
 ; ERROR: llvm-modextract: error: module index out of range; bitcode file contains 2 module(s)
 
 ; BCA0: setName(NewName);
   ImportGV->setVisibility(GlobalValue::HiddenVisibility);
 }
+
+if (isa() && allowPromotionAlias(OldName)) {
+  // Create a local alias with the original name to avoid breaking
+  // references from inline assembly.
+  std::string Alias = ".set " + OldName + "," + NewName + "\n";
+  ExportM.appendModuleInlineAsm(Alias);
+}
   }
 
   if (!RenamedComdats.empty())
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D99381: [compiler-rt][hwasan] Remove __sanitizer allocation functions from hwasan interface

2021-07-30 Thread Leonard Chan 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 rGb4c00b388285: [compiler-rt][hwasan] Remove __sanitizer 
allocation functions from hwasan… (authored by leonardchan).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99381

Files:
  compiler-rt/lib/hwasan/hwasan_allocation_functions.cpp
  compiler-rt/lib/hwasan/hwasan_interface_internal.h

Index: compiler-rt/lib/hwasan/hwasan_interface_internal.h
===
--- compiler-rt/lib/hwasan/hwasan_interface_internal.h
+++ compiler-rt/lib/hwasan/hwasan_interface_internal.h
@@ -168,54 +168,6 @@
 SANITIZER_INTERFACE_ATTRIBUTE
 void __hwasan_print_memory_usage();
 
-SANITIZER_INTERFACE_ATTRIBUTE
-int __sanitizer_posix_memalign(void **memptr, uptr alignment, uptr size);
-
-SANITIZER_INTERFACE_ATTRIBUTE
-void * __sanitizer_memalign(uptr alignment, uptr size);
-
-SANITIZER_INTERFACE_ATTRIBUTE
-void * __sanitizer_aligned_alloc(uptr alignment, uptr size);
-
-SANITIZER_INTERFACE_ATTRIBUTE
-void * __sanitizer___libc_memalign(uptr alignment, uptr size);
-
-SANITIZER_INTERFACE_ATTRIBUTE
-void * __sanitizer_valloc(uptr size);
-
-SANITIZER_INTERFACE_ATTRIBUTE
-void * __sanitizer_pvalloc(uptr size);
-
-SANITIZER_INTERFACE_ATTRIBUTE
-void __sanitizer_free(void *ptr);
-
-SANITIZER_INTERFACE_ATTRIBUTE
-void __sanitizer_cfree(void *ptr);
-
-SANITIZER_INTERFACE_ATTRIBUTE
-uptr __sanitizer_malloc_usable_size(const void *ptr);
-
-SANITIZER_INTERFACE_ATTRIBUTE
-__hwasan::__sanitizer_struct_mallinfo __sanitizer_mallinfo();
-
-SANITIZER_INTERFACE_ATTRIBUTE
-int __sanitizer_mallopt(int cmd, int value);
-
-SANITIZER_INTERFACE_ATTRIBUTE
-void __sanitizer_malloc_stats(void);
-
-SANITIZER_INTERFACE_ATTRIBUTE
-void * __sanitizer_calloc(uptr nmemb, uptr size);
-
-SANITIZER_INTERFACE_ATTRIBUTE
-void * __sanitizer_realloc(void *ptr, uptr size);
-
-SANITIZER_INTERFACE_ATTRIBUTE
-void * __sanitizer_reallocarray(void *ptr, uptr nmemb, uptr size);
-
-SANITIZER_INTERFACE_ATTRIBUTE
-void * __sanitizer_malloc(uptr size);
-
 SANITIZER_INTERFACE_ATTRIBUTE
 void *__hwasan_memcpy(void *dst, const void *src, uptr size);
 SANITIZER_INTERFACE_ATTRIBUTE
Index: compiler-rt/lib/hwasan/hwasan_allocation_functions.cpp
===
--- compiler-rt/lib/hwasan/hwasan_allocation_functions.cpp
+++ compiler-rt/lib/hwasan/hwasan_allocation_functions.cpp
@@ -17,6 +17,8 @@
 #include "sanitizer_common/sanitizer_allocator_interface.h"
 #include "sanitizer_common/sanitizer_tls_get_addr.h"
 
+#if !SANITIZER_FUCHSIA
+
 using namespace __hwasan;
 
 static uptr allocated_for_dlsym;
@@ -36,6 +38,9 @@
   return mem;
 }
 
+extern "C" {
+
+SANITIZER_INTERFACE_ATTRIBUTE
 int __sanitizer_posix_memalign(void **memptr, uptr alignment, uptr size) {
   GET_MALLOC_STACK_TRACE;
   CHECK_NE(memptr, 0);
@@ -43,16 +48,19 @@
   return res;
 }
 
+SANITIZER_INTERFACE_ATTRIBUTE
 void *__sanitizer_memalign(uptr alignment, uptr size) {
   GET_MALLOC_STACK_TRACE;
   return hwasan_memalign(alignment, size, );
 }
 
+SANITIZER_INTERFACE_ATTRIBUTE
 void *__sanitizer_aligned_alloc(uptr alignment, uptr size) {
   GET_MALLOC_STACK_TRACE;
   return hwasan_aligned_alloc(alignment, size, );
 }
 
+SANITIZER_INTERFACE_ATTRIBUTE
 void *__sanitizer___libc_memalign(uptr alignment, uptr size) {
   GET_MALLOC_STACK_TRACE;
   void *ptr = hwasan_memalign(alignment, size, );
@@ -61,16 +69,19 @@
   return ptr;
 }
 
+SANITIZER_INTERFACE_ATTRIBUTE
 void *__sanitizer_valloc(uptr size) {
   GET_MALLOC_STACK_TRACE;
   return hwasan_valloc(size, );
 }
 
+SANITIZER_INTERFACE_ATTRIBUTE
 void *__sanitizer_pvalloc(uptr size) {
   GET_MALLOC_STACK_TRACE;
   return hwasan_pvalloc(size, );
 }
 
+SANITIZER_INTERFACE_ATTRIBUTE
 void __sanitizer_free(void *ptr) {
   GET_MALLOC_STACK_TRACE;
   if (!ptr || UNLIKELY(IsInDlsymAllocPool(ptr)))
@@ -78,6 +89,7 @@
   hwasan_free(ptr, );
 }
 
+SANITIZER_INTERFACE_ATTRIBUTE
 void __sanitizer_cfree(void *ptr) {
   GET_MALLOC_STACK_TRACE;
   if (!ptr || UNLIKELY(IsInDlsymAllocPool(ptr)))
@@ -85,22 +97,27 @@
   hwasan_free(ptr, );
 }
 
+SANITIZER_INTERFACE_ATTRIBUTE
 uptr __sanitizer_malloc_usable_size(const void *ptr) {
   return __sanitizer_get_allocated_size(ptr);
 }
 
+SANITIZER_INTERFACE_ATTRIBUTE
 struct __sanitizer_struct_mallinfo __sanitizer_mallinfo() {
   __sanitizer_struct_mallinfo sret;
   internal_memset(, 0, sizeof(sret));
   return sret;
 }
 
+SANITIZER_INTERFACE_ATTRIBUTE
 int __sanitizer_mallopt(int cmd, int value) { return 0; }
 
+SANITIZER_INTERFACE_ATTRIBUTE
 void __sanitizer_malloc_stats(void) {
   // FIXME: implement, but don't call REAL(malloc_stats)!
 }
 
+SANITIZER_INTERFACE_ATTRIBUTE
 void *__sanitizer_calloc(uptr nmemb, uptr size) {
   GET_MALLOC_STACK_TRACE;
   if (UNLIKELY(!hwasan_inited))
@@ -109,6 +126,7 @@
   return

[PATCH] D104058: ThinLTO: Fix inline assembly references to static functions with CFI

2021-07-30 Thread Sami Tolvanen via Phabricator via cfe-commits

samitolvanen added inline comments.



Comment at: llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp:39
+  // Promotion aliases are used only in inline assembly. It's safe to
+  // simply skip unusual names. Matches MCAsmInfo::isAcceptableChar().
+  for (const char  : Name) {

nickdesaulniers wrote:
> What about `MCAsmInfoXCOFF::isAcceptableChar`?  I guess we could be targeting 
> a XCOFF object file format with LTO?
Sure, I'll drop '$' and '@' from the list to play nice with XCOFF. 



Comment at: llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp:45
+  }
+  return true;
+}

nickdesaulniers wrote:
> Can llvm::any_of or llvm::none_of be used here?
> llvm/ADT/STLExtras.h
Maybe, but I don't see how they would make this function any cleaner. Did you 
have something specific in mind?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104058

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

[PATCH] D107024: [DIBuilder] Do not replace empty enum types

2021-07-30 Thread Adrian Prantl via Phabricator via cfe-commits

aprantl added a comment.

I think that looks fine — I wonder if we should change the IR pretty printer to 
display empty arrays inline as `elements: !{}`, too.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107024

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

[PATCH] D106909: [clang] Add clang builtins support for gfx90a

2021-07-30 Thread Anshil Gandhi via Phabricator via cfe-commits

gandhi21299 marked 7 inline comments as done.
gandhi21299 added inline comments.



Comment at: clang/include/clang/Basic/BuiltinsAMDGPU.def:201
+TARGET_BUILTIN(__builtin_amdgcn_global_atomic_fadd_f32, "ff*1fi", "t", 
"gfx90a-insts")
+TARGET_BUILTIN(__builtin_amdgcn_global_atomic_fadd_2f16, "hh*1hi", "t", 
"gfx90a-insts")
+TARGET_BUILTIN(__builtin_amdgcn_global_atomic_fmin_f64, "dd*1di", "t", 
"gfx90a-insts")

arsenm wrote:
> yaxunl wrote:
> > arsenm wrote:
> > > "_2f16" looks weird to me. The instruction names call it "pk"
> > This is to have a consistent postfix naming convention, since the stem part 
> > here are the same. the postfix is for the argument type of the builtin 
> > function.
> Just a plain 2 isn't consistent either. The llvm type naming convention would 
> add a v prefix, but the builtins should probably follow the instructions
Yea, v2f16 looks reasonable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106909

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

[PATCH] D104058: ThinLTO: Fix inline assembly references to static functions with CFI

2021-07-30 Thread Nick Desaulniers via Phabricator via cfe-commits

nickdesaulniers added inline comments.



Comment at: llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp:39
+  // Promotion aliases are used only in inline assembly. It's safe to
+  // simply skip unusual names. Matches MCAsmInfo::isAcceptableChar().
+  for (const char  : Name) {

What about `MCAsmInfoXCOFF::isAcceptableChar`?  I guess we could be targeting a 
XCOFF object file format with LTO?



Comment at: llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp:45
+  }
+  return true;
+}

Can llvm::any_of or llvm::none_of be used here?
llvm/ADT/STLExtras.h


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104058

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

[PATCH] D104904: [OpenMP][AMDGCN] Initial math headers support

2021-07-30 Thread Jon Chesterfield via Phabricator via cfe-commits

JonChesterfield added a comment.

This patch didn't change complex so I'm struggling to make sense of the 
backtrace. Something in libstdc++ needs memory but doesn't include it?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104904

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

[PATCH] D107176: [OpenCL] Replace test for pipe struct to test it with fixed triple

2021-07-30 Thread Anton Zabaznov via Phabricator via cfe-commits

azabaznov updated this revision to Diff 363155.
azabaznov added a comment.

Restore original test name which was changed in D106748 
, use check-prefixes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107176

Files:
  clang/test/CodeGenOpenCL/pipe_builtin.cl
  clang/test/CodeGenOpenCL/pipe_types.cl


Index: clang/test/CodeGenOpenCL/pipe_types.cl
===
--- clang/test/CodeGenOpenCL/pipe_types.cl
+++ clang/test/CodeGenOpenCL/pipe_types.cl
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 
-cl-std=CL2.0 -o - %s | FileCheck %s
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 
-cl-std=CL3.0 
-cl-ext=+__opencl_c_pipes,+__opencl_c_generic_address_space,+__opencl_c_program_scope_global_variables
 -o - %s | FileCheck %s
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 
-cl-std=CL3.0 
-cl-ext=+__opencl_c_pipes,+__opencl_c_generic_address_space,-__opencl_c_program_scope_global_variables
 -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 
-cl-std=CL2.0 -DTEST_STRUCT -o - %s | FileCheck 
--check-prefixes=CHECK,CHECK-STRUCT %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 
-cl-std=CL3.0 
-cl-ext=+__opencl_c_pipes,+__opencl_c_generic_address_space,+__opencl_c_program_scope_global_variables
 -o - %s | FileCheck --check-prefixes=CHECK %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 
-cl-std=CL3.0 
-cl-ext=+__opencl_c_pipes,+__opencl_c_generic_address_space,-__opencl_c_program_scope_global_variables
 -o - %s | FileCheck --check-prefixes=CHECK %s
 
 // CHECK: %opencl.pipe_ro_t = type opaque
 // CHECK: %opencl.pipe_wo_t = type opaque
@@ -33,3 +33,21 @@
 kernel void test6(MyPipe p) {
 // CHECK: define{{.*}} spir_kernel void @test6(%opencl.pipe_ro_t* %p)
 }
+
+#ifdef TEST_STRUCT
+// FIXME: not supported for OpenCL C 3.0 as language built-ins not supported 
yet
+struct Person {
+  const char *Name;
+  bool isFemale;
+  int ID;
+};
+
+void test_reserved_read_pipe(global struct Person *SDst,
+ read_only pipe struct Person SPipe) {
+  // CHECK-STRUCT: define{{.*}} void @test_reserved_read_pipe
+  read_pipe (SPipe, SDst);
+  // CHECK-STRUCT: call i32 @__read_pipe_2(%opencl.pipe_ro_t* %{{.*}}, i8* 
%{{.*}}, i32 16, i32 8)
+  read_pipe (SPipe, SDst);
+  // CHECK-STRUCT: call i32 @__read_pipe_2(%opencl.pipe_ro_t* %{{.*}}, i8* 
%{{.*}}, i32 16, i32 8)
+}
+#endif // TEST_STRUCT
Index: clang/test/CodeGenOpenCL/pipe_builtin.cl
===
--- clang/test/CodeGenOpenCL/pipe_builtin.cl
+++ clang/test/CodeGenOpenCL/pipe_builtin.cl
@@ -71,16 +71,3 @@
   // CHECK: call i32 @__get_pipe_max_packets_wo(%opencl.pipe_wo_t* %{{.*}}, 
i32 4, i32 4)
   *ptr = get_pipe_max_packets(p);
 }
-
-struct Person {
-  const char *Name;
-  bool isFemale;
-  int ID;
-};
-
-void test9(global struct Person *SDst, read_only pipe struct Person SPipe) {
-  // CHECK: call i32 @__read_pipe_2(%opencl.pipe_ro_t* %{{.*}}, i8* %{{.*}}, 
i32 16, i32 8)
-  read_pipe (SPipe, SDst);
-  // CHECK: call i32 @__read_pipe_2(%opencl.pipe_ro_t* %{{.*}}, i8* %{{.*}}, 
i32 16, i32 8)
-  read_pipe (SPipe, SDst);
-}


Index: clang/test/CodeGenOpenCL/pipe_types.cl
===
--- clang/test/CodeGenOpenCL/pipe_types.cl
+++ clang/test/CodeGenOpenCL/pipe_types.cl
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 -cl-std=CL2.0 -o - %s | FileCheck %s
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 -cl-std=CL3.0 -cl-ext=+__opencl_c_pipes,+__opencl_c_generic_address_space,+__opencl_c_program_scope_global_variables -o - %s | FileCheck %s
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 -cl-std=CL3.0 -cl-ext=+__opencl_c_pipes,+__opencl_c_generic_address_space,-__opencl_c_program_scope_global_variables -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 -cl-std=CL2.0 -DTEST_STRUCT -o - %s | FileCheck --check-prefixes=CHECK,CHECK-STRUCT %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 -cl-std=CL3.0 -cl-ext=+__opencl_c_pipes,+__opencl_c_generic_address_space,+__opencl_c_program_scope_global_variables -o - %s | FileCheck --check-prefixes=CHECK %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 -cl-std=CL3.0 -cl-ext=+__opencl_c_pipes,+__opencl_c_generic_address_space,-__opencl_c_program_scope_global_variables -o - %s | FileCheck --check-prefixes=CHECK %s
 
 // CHECK: %opencl.pipe_ro_t = type opaque
 // CHECK: %opencl.pipe_wo_t = type opaque
@@ -33,3 +33,21 @@
 kernel void test6(MyPipe p) {
 // CHECK: define{{.*}} spir_kernel void @test6(%opencl.pipe_ro_t* %p)
 }
+
+#ifdef

[PATCH] D106900: [PowerPC][AIX] Packed zero-width bitfields do not affect alignment.

2021-07-30 Thread Steven Wan via Phabricator via cfe-commits

stevewan added inline comments.



Comment at: clang/lib/AST/RecordLayoutBuilder.cpp:1781
-  // pragma align(packed).
-  if (isAIXLayout(Context) && !MaxFieldAlignment.isZero() && !FieldSize)
-FieldAlign = std::min(FieldAlign, MaxFieldAlignmentInBits);

sfertile wrote:
> stevewan wrote:
> > Just noting that the comment says `MaxFieldAlignment - The maximum allowed 
> > field alignment. This is set by #pragma pack`, but `__attribute__(packed)` 
> > also seems to set it to some large value that is at least as large as the 
> > FieldAlign. Maybe edit the comment accordingly for now, and a future 
> > follow-on patch if necessary.
> Sorry Steven, not sure what you are asking for. 
> 
> attribute packed will set 'FieldPacked` to true, in which case we ignore the 
> max field alignment  (and why the new comment says, or 1 if packed). IIUC the 
> MaXFieldAlign is set by only by pragma pack and pragma align in the Itanium 
> recored layout builder, and the place where it is set based on attribute 
> packed is int he Microsoft record layout builder and doesn't affect us here.
Sorry Sean, my previous comment was indeed confusing. The old buggy behaviour 
confused me, and for some reason I thought the code must had went down this if 
statement when attribute packed is set, hence the previous comment. Now that I 
take a second look, I realize the problem was actually that we never went into 
the `if` to fix the FieldAlign. Sorry for the churn.

 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106900

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

[PATCH] D104601: [Preprocessor] Implement -fminimize-whitespace.

2021-07-30 Thread Michael Kruse via Phabricator via cfe-commits

Meinersbur added a comment.

> Correct -- that would be unfortunate as I believe you were hoping for this to 
> be in Clang 13 for ccache support.

Yes, that would have been the ideal outcome.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104601

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

[clang] 31d408f - Trim failing test

2021-07-30 Thread Paul Robinson via cfe-commits


Author: Paul Robinson
Date: 2021-07-30T10:51:08-07:00
New Revision: 31d408f9f94f3b97366d49c342734c195a343579

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

LOG: Trim failing test

Don't try to run the non-integrated assembler; just verify that the
invocations look like what we expect.  Do verify that the integrated
assembler handles warnings as expected.

Added: 


Modified: 
clang/test/Driver/as-no-warnings.c

Removed: 




diff  --git a/clang/test/Driver/as-no-warnings.c 
b/clang/test/Driver/as-no-warnings.c
index c785c054155c..d6b49217468a 100644
--- a/clang/test/Driver/as-no-warnings.c
+++ b/clang/test/Driver/as-no-warnings.c
@@ -1,20 +1,17 @@
 // RUN: %clang -### %s -c -o tmp.o -target i686-pc-linux-gnu 
-fno-integrated-as -Wa,--no-warn 2>&1 | FileCheck -check-prefix=CHECK-NOIAS %s
-// RUN: %clang -### %s -c -o tmp.o -target i686-pc-linux-gnu -integrated-as 
-Wa,--no-warn 2>&1 | FileCheck %s
+// RUN: %clang -### %s -c -o tmp.o -integrated-as -Wa,--no-warn 2>&1 | 
FileCheck %s
 
 /// -W is alias for --no-warn.
 // RUN: %clang -### %s -c -o tmp.o -target i686-pc-linux-gnu 
-fno-integrated-as -Wa,-W 2>&1 | FileCheck -check-prefix=CHECK-NOIASW %s
-// RUN: %clang -### %s -c -o tmp.o -target i686-pc-linux-gnu -integrated-as 
-Wa,-W 2>&1 | FileCheck %s
+// RUN: %clang -### %s -c -o tmp.o -integrated-as -Wa,-W 2>&1 | FileCheck %s
 
-// RUN: %clang %s -c -o %t.o -target i686-pc-linux-gnu -integrated-as 
-Wa,--no-warn 2>&1 | FileCheck -allow-empty --check-prefix=CHECK-AS-NOWARN %s
-// RUN: %clang %s -c -o %t.o -target i686-pc-linux-gnu -fno-integrated-as 
-Wa,--no-warn 2>&1 | FileCheck -allow-empty --check-prefix=CHECK-AS-NOWARN %s
-// RUN: %clang %s -c -o %t.o -target i686-pc-linux-gnu -fno-integrated-as 
-Wa,-W 2>&1 | FileCheck -allow-empty --check-prefix=CHECK-AS-NOWARN %s
-// RUN: not %clang %s -c -o %t.o -target i686-pc-linux-gnu -integrated-as 
-Wa,--fatal-warnings 2>&1 | FileCheck --check-prefix=CHECK-AS-FATAL %s
-// RUN: not %clang %s -c -o %t.o -target i686-pc-linux-gnu -fno-integrated-as 
-Wa,--fatal-warnings 2>&1 | FileCheck --check-prefix=CHECK-AS-FATAL %s
+/// Make sure warnings behave properly in integrated assembler.
+// RUN: %clang %s -c -o %t.o -integrated-as -Wa,--no-warn 2>&1 | FileCheck 
-allow-empty --check-prefix=CHECK-AS-NOWARN %s
+// RUN: not %clang %s -c -o %t.o -integrated-as -Wa,--fatal-warnings 2>&1 | 
FileCheck --check-prefix=CHECK-AS-FATAL %s
 
 // REQUIRES: clang-driver
 // REQUIRES: x86-registered-target
 // REQUIRES: system-linux
-// XFAIL: powerpc
 
 // CHECK: "-cc1" {{.*}} "-massembler-no-warn"
 // CHECK-NOIAS: "--no-warn"



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

[PATCH] D105821: [analyzer] [WIP] Model destructor for std::unique_ptr

2021-07-30 Thread Artem Dergachev via Phabricator via cfe-commits

NoQ added a comment.

In D105821#2914082 , @RedDocMD wrote:

> On running this patch on the `projects` directory, a bunch of projects emit 
> false-positives: mostly of the form `Potential memory leak`. This points to 
> the fact that without calling the destructor of the pointee type, we are 
> going to have a lot of false positives (408 for //one// project is the worst 
> I have seen). I have attached the result file.

Can you attach all or some of the newly found html reports?

Is this about invalidation in `~unique_ptr()` modeling being insufficient, or 
about us not doing anything at all with pointee on other occasions such as 
`.reset()` or might it be that the lack of invalidation for constructor inside 
`make_unique()` also plays its part?

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105821

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

[PATCH] D106900: [PowerPC][AIX] Packed zero-width bitfields do not affect alignment.

2021-07-30 Thread Sean Fertile via Phabricator via cfe-commits

sfertile updated this revision to Diff 363147.
sfertile added a comment.

Fixed spelling and added a 'long long' zero width bitfield to the testing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106900

Files:
  clang/lib/AST/RecordLayoutBuilder.cpp
  clang/test/Layout/aix-packed-bitfields.c


Index: clang/test/Layout/aix-packed-bitfields.c
===
--- clang/test/Layout/aix-packed-bitfields.c
+++ clang/test/Layout/aix-packed-bitfields.c
@@ -1,14 +1,18 @@
 // RUN: %clang_cc1 -triple powerpc-ibm-aix-xcoff -fdump-record-layouts \
-// RUN: -fsyntax-only -fxl-pragma-pack -x c %s | FileCheck  %s
+// RUN: -fsyntax-only -fxl-pragma-pack -x c %s | \
+// RUN:   FileCheck --check-prefixes=CHECK,32BIT %s
 
 // RUN: %clang_cc1 -triple powerpc-ibm-aix-xcoff -fdump-record-layouts \
-// RUN: -fsyntax-only -fxl-pragma-pack -x c++ %s | FileCheck %s
-//
+// RUN: -fsyntax-only -fxl-pragma-pack -x c++ %s | \
+// RUN:   FileCheck --check-prefixes=CHECK,32BIT %s
+
 // RUN: %clang_cc1 -triple powerpc64-ibm-aix-xcoff -fdump-record-layouts \
-// RUN: -fsyntax-only -fxl-pragma-pack -x c %s | FileCheck  %s
-//
+// RUN: -fsyntax-only -fxl-pragma-pack -x c %s | \
+// RUN:   FileCheck --check-prefixes=CHECK,64BIT %s
+
 // RUN: %clang_cc1 -triple powerpc64-ibm-aix-xcoff -fdump-record-layouts \
-// RUN: -fsyntax-only -fxl-pragma-pack -x c++ %s | FileCheck %s
+// RUN: -fsyntax-only -fxl-pragma-pack -x c++ %s | \
+// RUN:   FileCheck --check-prefixes=CHECK,64BIT %s
 
 struct A {
   int a1 : 30;
@@ -75,3 +79,35 @@
 // CHECK-NEXT: 3:6-35 |   int a2
 // CHECK-NEXT:  7:4-7 |   int a3
 // CHECK-NEXT:  sizeof=8, {{(dsize=8, )?}}align=2, preferredalign=2
+//
+struct __attribute__((packed)) PackedAttr {
+  char f1;
+  int : 0;
+  short : 3;
+  char f4 : 2;
+};
+
+int e = sizeof(struct PackedAttr);
+// CHECK:  *** Dumping AST Record Layout
+// CHECK-NEXT:  0 | struct PackedAttr
+// CHECK-NEXT:  0 |   char f1
+// CHECK-NEXT:4:- |   int
+// CHECK-NEXT:  4:0-2 |   short
+// CHECK-NEXT:  4:3-4 |   char f4
+// CHECK-NEXT:  sizeof=5, {{(dsize=5, )?}}align=1, preferredalign=1
+
+#pragma pack(2)
+struct __attribute__((packed)) PackedAttrAndPragma {
+  char f1;
+  long long : 0;
+};
+#pragma pack(pop)
+
+int f = sizeof(struct PackedAttrAndPragma);
+// CHECK:  *** Dumping AST Record Layout
+// CHECK-NEXT:  0 | struct PackedAttrAndPragma
+// CHECK-NEXT:  0 |   char f1
+// 32BIT-NEXT:4:- |   long long
+// 32BIT-NEXT:  sizeof=4, {{(dsize=4, )?}}align=1, preferredalign=1
+// 64BIT-NEXT:8:- |   long long
+// 64BIT-NEXT:  sizeof=8, {{(dsize=8, )?}}align=1, preferredalign=1
Index: clang/lib/AST/RecordLayoutBuilder.cpp
===
--- clang/lib/AST/RecordLayoutBuilder.cpp
+++ clang/lib/AST/RecordLayoutBuilder.cpp
@@ -1775,11 +1775,18 @@
   !D->getIdentifier())
 FieldAlign = UnpackedFieldAlign = 1;
 
-  // On AIX, zero-width bitfields pad out to the alignment boundary, but then
-  // do not affect overall record alignment if there is a pragma pack or
-  // pragma align(packed).
-  if (isAIXLayout(Context) && !MaxFieldAlignment.isZero() && !FieldSize)
-FieldAlign = std::min(FieldAlign, MaxFieldAlignmentInBits);
+  // On AIX, zero-width bitfields pad out to the natural alignment boundary,
+  // but do not increase the alignment greater than the MaxFieldAlignment, or 1
+  // if packed.
+  if (isAIXLayout(Context) && !FieldSize) {
+if (FieldPacked) {
+  FieldAlign = UnpackedFieldAlign = 1;
+} else if (!MaxFieldAlignment.isZero()) {
+  UnpackedFieldAlign =
+  std::min(UnpackedFieldAlign, MaxFieldAlignmentInBits);
+  FieldAlign = std::min(FieldAlign, MaxFieldAlignmentInBits);
+}
+  }
 
   // Diagnose differences in layout due to padding or packing.
   if (!UseExternalLayout)


Index: clang/test/Layout/aix-packed-bitfields.c
===
--- clang/test/Layout/aix-packed-bitfields.c
+++ clang/test/Layout/aix-packed-bitfields.c
@@ -1,14 +1,18 @@
 // RUN: %clang_cc1 -triple powerpc-ibm-aix-xcoff -fdump-record-layouts \
-// RUN: -fsyntax-only -fxl-pragma-pack -x c %s | FileCheck  %s
+// RUN: -fsyntax-only -fxl-pragma-pack -x c %s | \
+// RUN:   FileCheck --check-prefixes=CHECK,32BIT %s
 
 // RUN: %clang_cc1 -triple powerpc-ibm-aix-xcoff -fdump-record-layouts \
-// RUN: -fsyntax-only -fxl-pragma-pack -x c++ %s | FileCheck %s
-//
+// RUN: -fsyntax-only -fxl-pragma-pack -x c++ %s | \
+// RUN:   FileCheck --check-prefixes=CHECK,32BIT %s
+
 // RUN: %clang_cc1 -triple powerpc64-ibm-aix-xcoff -fdump-record-layouts \
-// RUN: -fsyntax-only -fxl-pragma-pack -x c %s | FileCheck  %s
-//
+// RUN: -fsyntax-only -fxl-pragma-pack -x c %s | \
+// RUN:   FileCheck

[PATCH] D107183: [Preprocessor] Ensure newline after #pragma introduced by -fms-extensions.

2021-07-30 Thread Michael Kruse via Phabricator via cfe-commits

Meinersbur updated this revision to Diff 363146.
Meinersbur added a comment.

Refine test case


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107183

Files:
  clang/lib/Frontend/PrintPreprocessedOutput.cpp
  clang/test/Preprocessor/whitespace-ms-extensions.c


Index: clang/test/Preprocessor/whitespace-ms-extensions.c
===
--- /dev/null
+++ clang/test/Preprocessor/whitespace-ms-extensions.c
@@ -0,0 +1,19 @@
+// RUN: %clang -E -P %s -o -| FileCheck %s
+// RUN: %clang -E -P -fms-extensions %s -o -| FileCheck %s --check-prefix=MSEXT
+
+// -fms-extensions changes __pragma into #pragma
+// Ensure that there is a newline after the #pragma line.
+
+#define MACRO\
+text \
+__pragma(PRAGMA) \
+after
+
+before MACRO text
+
+
+// CHECK:  before text __pragma(PRAGMA) after text
+
+// MSEXT:  before text
+// MSEXT-NEXT: #pragma PRAGMA
+// MSEXT-NEXT: after text
Index: clang/lib/Frontend/PrintPreprocessedOutput.cpp
===
--- clang/lib/Frontend/PrintPreprocessedOutput.cpp
+++ clang/lib/Frontend/PrintPreprocessedOutput.cpp
@@ -646,7 +646,9 @@
!Tok.is(tok::annot_module_begin) && !Tok.is(tok::annot_module_end)))
 return;
 
-  if (!RequireSameLine && MoveToLine(Tok, /*RequireStartOfLine=*/false)) {
+  // EmittedDirectiveOnThisLine takes priority over RequireSameLine.
+  if ((!RequireSameLine || EmittedDirectiveOnThisLine) &&
+  MoveToLine(Tok, /*RequireStartOfLine=*/EmittedDirectiveOnThisLine)) {
 if (MinimizeWhitespace) {
   // Avoid interpreting hash as a directive under -fpreprocessed.
   if (Tok.is(tok::hash))


Index: clang/test/Preprocessor/whitespace-ms-extensions.c
===
--- /dev/null
+++ clang/test/Preprocessor/whitespace-ms-extensions.c
@@ -0,0 +1,19 @@
+// RUN: %clang -E -P %s -o -| FileCheck %s
+// RUN: %clang -E -P -fms-extensions %s -o -| FileCheck %s --check-prefix=MSEXT
+
+// -fms-extensions changes __pragma into #pragma
+// Ensure that there is a newline after the #pragma line.
+
+#define MACRO\
+text \
+__pragma(PRAGMA) \
+after
+
+before MACRO text
+
+
+// CHECK:  before text __pragma(PRAGMA) after text
+
+// MSEXT:  before text
+// MSEXT-NEXT: #pragma PRAGMA
+// MSEXT-NEXT: after text
Index: clang/lib/Frontend/PrintPreprocessedOutput.cpp
===
--- clang/lib/Frontend/PrintPreprocessedOutput.cpp
+++ clang/lib/Frontend/PrintPreprocessedOutput.cpp
@@ -646,7 +646,9 @@
!Tok.is(tok::annot_module_begin) && !Tok.is(tok::annot_module_end)))
 return;
 
-  if (!RequireSameLine && MoveToLine(Tok, /*RequireStartOfLine=*/false)) {
+  // EmittedDirectiveOnThisLine takes priority over RequireSameLine.
+  if ((!RequireSameLine || EmittedDirectiveOnThisLine) &&
+  MoveToLine(Tok, /*RequireStartOfLine=*/EmittedDirectiveOnThisLine)) {
 if (MinimizeWhitespace) {
   // Avoid interpreting hash as a directive under -fpreprocessed.
   if (Tok.is(tok::hash))
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: [clang] 9ca905b - XFAIL a test on ppc64

2021-07-30 Thread via cfe-commits

H yeah, just because your compiler has both ppc and x86 targets doesn’t 
mean your system assembler is willing to target x86.
I think it can keep the -integrated-as steps that verify the warning does 
what’s expected, and abandon actually running the external assembler.
The -target options for the integrated assembler can also probably be removed 
again (I added that in my first try to fix the bots).
Thanks, hope the next step works…
--paulr

From: Hubert Tong 
Sent: Friday, July 30, 2021 1:26 PM
To: Robinson, Paul 
Cc: Amy Huang ; cfe-commits 
Subject: Re: [clang] 9ca905b - XFAIL a test on ppc64

On Fri, Jul 30, 2021 at 12:59 PM 
mailto:paul.robin...@sony.com>> wrote:
Do you have a suggestion for how to fix it?  This isn’t actually my test, I 
tripped over it and it seemed like it would be easy to get it to work.  ☹

I think removing all of the `-target` options might help. Alternatively, I 
don't see why the test should actually call out to the assembler (could just 
check the driver would invoke it with the options of interest).

If the test is also meant to check that an error from the native assembler 
produces an error return code from the driver, then that could be tested using 
an ersatz assembler picked up using `-B` (but I would hope that there's a 
different test to cover that already).

Thanks,
--paulr

From: Hubert Tong 
mailto:hubert.reinterpretc...@gmail.com>>
Sent: Friday, July 30, 2021 12:43 PM
To: Robinson, Paul mailto:paul.robin...@sony.com>>; 
Paul Robinson mailto:llvmlist...@llvm.org>>
Cc: cfe-commits mailto:cfe-commits@lists.llvm.org>>
Subject: Re: [clang] 9ca905b - XFAIL a test on ppc64

On Fri, Jul 30, 2021 at 12:05 PM Paul Robinson via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:

Author: Paul Robinson
Date: 2021-07-30T09:05:14-07:00
New Revision: 9ca905b52d53c46aceb4d28e44dfbf4a815d0c68

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

LOG: XFAIL a test on ppc64

Buildbot failure:
https://lab.llvm.org/buildbot/#/builders/105/builds/13141
which provides no details about why it failed,

Which would be because the test is set up to display warnings but won't display 
errors.

/usr/bin/as: unrecognized option '--32'

I also tried `x86_64-pc-linux-gnu`:

/usr/bin/as: unrecognized option '--64'

It probably makes sense that these options aren't supported if the system is 
64-bit only.

but the only failure
reports are for ppc64 bots.

Added:


Modified:
clang/test/Driver/as-no-warnings.c

Removed:




diff  --git a/clang/test/Driver/as-no-warnings.c 
b/clang/test/Driver/as-no-warnings.c
index 9c2b3f096872..77971389ee65 100644
--- a/clang/test/Driver/as-no-warnings.c
+++ b/clang/test/Driver/as-no-warnings.c
@@ -14,6 +14,7 @@
 // REQUIRES: clang-driver
 // REQUIRES: x86-registered-target
 // REQUIRES: system-linux
+// XFAIL: ppc64

 // CHECK: "-cc1" {{.*}} "-massembler-no-warn"
 // CHECK-NOIAS: "--no-warn"



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

[PATCH] D104601: [Preprocessor] Implement -fminimize-whitespace.

2021-07-30 Thread Michael Kruse via Phabricator via cfe-commits

Meinersbur added a comment.

Patch uploaded here: D107183 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104601

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

[PATCH] D107183: [Preprocessor] Ensure newline after #pragma introduced by -fms-extensions.

2021-07-30 Thread Michael Kruse via Phabricator via cfe-commits

Meinersbur created this revision.
Meinersbur added reviewers: aaron.ballman, dblaikie, mstorsjo, romanovvlad, 
alexfh.
Meinersbur added a project: clang.
Meinersbur requested review of this revision.

The -fms-extensions converts __pragma (and _Pragma) into a #pragma that has to 
occur at the beginning of a line and end with a newline. This patch ensures 
that the newline after the #pragma is added even though that 
`ok::isAtStartOfLine() indicated that we should not start a newline.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D107183

Files:
  clang/lib/Frontend/PrintPreprocessedOutput.cpp
  clang/test/Preprocessor/whitespace-ms-extensions.c


Index: clang/test/Preprocessor/whitespace-ms-extensions.c
===
--- /dev/null
+++ clang/test/Preprocessor/whitespace-ms-extensions.c
@@ -0,0 +1,18 @@
+// RUN: %clang -E -P %s -o -| FileCheck %s
+// RUN: %clang -E -P -fms-extensions %s -o -| FileCheck %s --check-prefix=MSEXT
+
+// -fms-extensions changes __pragma into #pragma
+// Ensure that there is a newline after the #pragma line.
+
+#define MACRO\
+__pragma(PRAGMA) \
+text
+
+beforetext MACRO aftertext
+
+
+// CHECK:  beforetext __pragma(PRAGMA) text aftertext
+
+// MSEXT:  beforetext
+// MSEXT:  #pragma PRAGMA
+// MSEXT-NEXT: text aftertext
Index: clang/lib/Frontend/PrintPreprocessedOutput.cpp
===
--- clang/lib/Frontend/PrintPreprocessedOutput.cpp
+++ clang/lib/Frontend/PrintPreprocessedOutput.cpp
@@ -646,7 +646,9 @@
!Tok.is(tok::annot_module_begin) && !Tok.is(tok::annot_module_end)))
 return;
 
-  if (!RequireSameLine && MoveToLine(Tok, /*RequireStartOfLine=*/false)) {
+  // EmittedDirectiveOnThisLine takes priority over RequireSameLine.
+  if ((!RequireSameLine || EmittedDirectiveOnThisLine) &&
+  MoveToLine(Tok, /*RequireStartOfLine=*/EmittedDirectiveOnThisLine)) {
 if (MinimizeWhitespace) {
   // Avoid interpreting hash as a directive under -fpreprocessed.
   if (Tok.is(tok::hash))


Index: clang/test/Preprocessor/whitespace-ms-extensions.c
===
--- /dev/null
+++ clang/test/Preprocessor/whitespace-ms-extensions.c
@@ -0,0 +1,18 @@
+// RUN: %clang -E -P %s -o -| FileCheck %s
+// RUN: %clang -E -P -fms-extensions %s -o -| FileCheck %s --check-prefix=MSEXT
+
+// -fms-extensions changes __pragma into #pragma
+// Ensure that there is a newline after the #pragma line.
+
+#define MACRO\
+__pragma(PRAGMA) \
+text
+
+beforetext MACRO aftertext
+
+
+// CHECK:  beforetext __pragma(PRAGMA) text aftertext
+
+// MSEXT:  beforetext
+// MSEXT:  #pragma PRAGMA
+// MSEXT-NEXT: text aftertext
Index: clang/lib/Frontend/PrintPreprocessedOutput.cpp
===
--- clang/lib/Frontend/PrintPreprocessedOutput.cpp
+++ clang/lib/Frontend/PrintPreprocessedOutput.cpp
@@ -646,7 +646,9 @@
!Tok.is(tok::annot_module_begin) && !Tok.is(tok::annot_module_end)))
 return;
 
-  if (!RequireSameLine && MoveToLine(Tok, /*RequireStartOfLine=*/false)) {
+  // EmittedDirectiveOnThisLine takes priority over RequireSameLine.
+  if ((!RequireSameLine || EmittedDirectiveOnThisLine) &&
+  MoveToLine(Tok, /*RequireStartOfLine=*/EmittedDirectiveOnThisLine)) {
 if (MinimizeWhitespace) {
   // Avoid interpreting hash as a directive under -fpreprocessed.
   if (Tok.is(tok::hash))
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [clang] 9ca905b - XFAIL a test on ppc64

2021-07-30 Thread Hubert Tong via cfe-commits

On Fri, Jul 30, 2021 at 12:59 PM  wrote:

> Do you have a suggestion for how to fix it?  This isn’t actually my test,
> I tripped over it and it seemed like it would be easy to get it to work.
> ☹
>

I think removing all of the `-target` options might help. Alternatively, I
don't see why the test should actually call out to the assembler (could
just check the driver would invoke it with the options of interest).

If the test is also meant to check that an error from the native assembler
produces an error return code from the driver, then that could be tested
using an ersatz assembler picked up using `-B` (but I would hope that
there's a different test to cover that already).

Thanks,
>
> --paulr
>
>
>
> *From:* Hubert Tong 
> *Sent:* Friday, July 30, 2021 12:43 PM
> *To:* Robinson, Paul ; Paul Robinson <
> llvmlist...@llvm.org>
> *Cc:* cfe-commits 
> *Subject:* Re: [clang] 9ca905b - XFAIL a test on ppc64
>
>
>
> On Fri, Jul 30, 2021 at 12:05 PM Paul Robinson via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>
> Author: Paul Robinson
> Date: 2021-07-30T09:05:14-07:00
> New Revision: 9ca905b52d53c46aceb4d28e44dfbf4a815d0c68
>
> URL:
> https://github.com/llvm/llvm-project/commit/9ca905b52d53c46aceb4d28e44dfbf4a815d0c68
> 
> DIFF:
> https://github.com/llvm/llvm-project/commit/9ca905b52d53c46aceb4d28e44dfbf4a815d0c68.diff
> 
>
> LOG: XFAIL a test on ppc64
>
> Buildbot failure:
> https://lab.llvm.org/buildbot/#/builders/105/builds/13141
> 
> which provides no details about why it failed,
>
>
>
> Which would be because the test is set up to display warnings but won't
> display errors.
>
>
>
> /usr/bin/as: unrecognized option '--32'
>
>
>
> I also tried `x86_64-pc-linux-gnu`:
>
>
>
> /usr/bin/as: unrecognized option '--64'
>
>
>
> It probably makes sense that these options aren't supported if the system
> is 64-bit only.
>
>
>
> but the only failure
> reports are for ppc64 bots.
>
> Added:
>
>
> Modified:
> clang/test/Driver/as-no-warnings.c
>
> Removed:
>
>
>
>
> 
> diff  --git a/clang/test/Driver/as-no-warnings.c
> b/clang/test/Driver/as-no-warnings.c
> index 9c2b3f096872..77971389ee65 100644
> --- a/clang/test/Driver/as-no-warnings.c
> +++ b/clang/test/Driver/as-no-warnings.c
> @@ -14,6 +14,7 @@
>  // REQUIRES: clang-driver
>  // REQUIRES: x86-registered-target
>  // REQUIRES: system-linux
> +// XFAIL: ppc64
>
>  // CHECK: "-cc1" {{.*}} "-massembler-no-warn"
>  // CHECK-NOIAS: "--no-warn"
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> 
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D105821: [analyzer] [WIP] Model destructor for std::unique_ptr

2021-07-30 Thread Deep Majumder via Phabricator via cfe-commits

RedDocMD updated this revision to Diff 363138.
RedDocMD added a comment.

Invalidating using inner pointer destructor call


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105821

Files:
  clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
  clang/lib/StaticAnalyzer/Core/CheckerManager.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp

Index: clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
===
--- clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
+++ clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
@@ -753,10 +753,13 @@
 *Call, *this);
 
   ExplodedNodeSet DstInvalidated;
-  StmtNodeBuilder Bldr(DstPreCall, DstInvalidated, *currBldrCtx);
-  for (ExplodedNodeSet::iterator I = DstPreCall.begin(), E = DstPreCall.end();
-   I != E; ++I)
-defaultEvalCall(Bldr, *I, *Call, CallOpts);
+  // StmtNodeBuilder Bldr(DstPreCall, DstInvalidated, *currBldrCtx);
+  // for (ExplodedNodeSet::iterator I = DstPreCall.begin(), E =
+  // DstPreCall.end();
+  //  I != E; ++I)
+  //   defaultEvalCall(Bldr, *I, *Call, CallOpts);
+  getCheckerManager().runCheckersForEvalCall(DstInvalidated, DstPreCall, *Call,
+ *this, CallOpts);
 
   getCheckerManager().runCheckersForPostCall(Dst, DstInvalidated,
  *Call, *this);
Index: clang/lib/StaticAnalyzer/Core/CheckerManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/CheckerManager.cpp
+++ clang/lib/StaticAnalyzer/Core/CheckerManager.cpp
@@ -664,14 +664,11 @@
 for (const auto  : EvalCallCheckers) {
   // TODO: Support the situation when the call doesn't correspond
   // to any Expr.
-  ProgramPoint L = ProgramPoint::getProgramPoint(
-  Call.getOriginExpr(), ProgramPoint::PostStmtKind,
-  Pred->getLocationContext(), EvalCallChecker.Checker);
   bool evaluated = false;
   { // CheckerContext generates transitions(populates checkDest) on
 // destruction, so introduce the scope to make sure it gets properly
 // populated.
-CheckerContext C(B, Eng, Pred, L);
+CheckerContext C(B, Eng, Pred, Call.getProgramPoint());
 evaluated = EvalCallChecker(Call, C);
   }
   assert(!(evaluated && anyEvaluated)
Index: clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
+++ clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
@@ -139,7 +139,7 @@
 
   if (RD->getDeclName().isIdentifier()) {
 StringRef Name = RD->getName();
-return Name == "shared_ptr" || Name == "unique_ptr" || Name == "weak_ptr";
+return llvm::is_contained(STD_PTR_NAMES, Name);
   }
   return false;
 }
@@ -279,6 +279,7 @@
 CheckerContext ) const {
 
   ProgramStateRef State = C.getState();
+  Call.dump();
 
   // If any one of the arg is a unique_ptr, then
   // we can try this function
@@ -372,6 +373,35 @@
 }
   }
 
+  if (const auto *DC = dyn_cast()) {
+llvm::errs() << "Found destructor call\n";
+// FIXME: This is a sort-of redundant operation.
+// But we can't remove it currently, otherwise shared_ptr and weak_ptr
+// causes a crash after this.
+State = DC->invalidateRegions(C.blockCount(), State);
+const MemRegion *ThisRegion = DC->getCXXThisVal().getAsRegion();
+// TODO: Remove this before pushing
+assert(ThisRegion && "We do not support explicit calls to destructor");
+const auto *InnerPtrVal = State->get(ThisRegion);
+State = State->remove(ThisRegion);
+if (InnerPtrVal) {
+  State = State->invalidateRegions(*InnerPtrVal, nullptr, C.blockCount(),
+   C.getLocationContext(), true);
+
+  const QualType  = getInnerPointerType(Call, C);
+  const auto *RD = Type->getAsCXXRecordDecl();
+  const auto *DD = RD->getDestructor();
+
+  const auto InnerDestrCall =
+  C.getStateManager().getCallEventManager().getCXXDestructorCall(
+  DD, nullptr, InnerPtrVal->getAsRegion(), RD->bases().empty(),
+  State, C.getLocationContext());
+  InnerDestrCall->invalidateRegions(C.blockCount(), State);
+}
+C.addTransition(State);
+return true;
+  }
+
   if (!ModelSmartPtrDereference)
 return false;
 
@@ -402,8 +432,8 @@
   }));
 } else {
   const auto *TrackingExpr = Call.getArgExpr(0);
-  assert(TrackingExpr->getType()->isPointerType() &&
- "Adding a non pointer value to TrackedRegionMap");
+  if (!TrackingExpr->getType()->isPointerType())
+return false;
   auto ArgVal = Call.getArgSVal(0);
   State = State->set(ThisRegion, ArgVal);

[PATCH] D104601: [Preprocessor] Implement -fminimize-whitespace.

2021-07-30 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added a comment.

In D104601#2916986 , @Meinersbur 
wrote:

> In D104601#2916897 , @aaron.ballman 
> wrote:
>
>> In D104601#2916887 , @Meinersbur 
>> wrote:
>>
>>> I am working on a fix, but I wouldn't mind reverting.
>>
>> I would be comfortable reverting the feature for Clang 13 and fixing forward 
>> on trunk (unless there's a need to revert from trunk temporarily, of 
>> course). Giving the feature a full release to bake isn't a bad outcome.
>
> While this means that ccache can only use this feature when `clang-14` is 
> detected, I fully understand.

Correct -- that would be unfortunate as I believe you were hoping for this to 
be in Clang 13 for ccache support. My fear of having this in Clang 13 is that 
very early testing has found several breakages so I worry if we've not had 
enough time to shake all those out. Having a bit more time might build our 
confidence. (So the result, to me, should be either that we back this out of 
the Clang 13 branch if we're still worried or we patch the Clang 13 branch if 
we think we've got all the cases, but I want to make sure we don't leave it 
somewhere in the middle for the release branch.)

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104601

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

[PATCH] D97699: [analyzer] Add InvalidPtrChecker

2021-07-30 Thread Csaba Dabis via Phabricator via cfe-commits

Charusso resigned from this revision.
Charusso added a comment.

@NoQ, what do you think?


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

https://reviews.llvm.org/D97699

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

[PATCH] D104601: [Preprocessor] Implement -fminimize-whitespace.

2021-07-30 Thread Michael Kruse via Phabricator via cfe-commits

Meinersbur added a comment.

In D104601#2916897 , @aaron.ballman 
wrote:

> In D104601#2916887 , @Meinersbur 
> wrote:
>
>> I am working on a fix, but I wouldn't mind reverting.
>
> I would be comfortable reverting the feature for Clang 13 and fixing forward 
> on trunk (unless there's a need to revert from trunk temporarily, of course). 
> Giving the feature a full release to bake isn't a bad outcome.

While this means that ccache can only use this feature when `clang-14` is 
detected, I fully understand.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104601

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

[PATCH] D104601: [Preprocessor] Implement -fminimize-whitespace.

2021-07-30 Thread Michael Kruse via Phabricator via cfe-commits

Meinersbur added a comment.

@romanovvlad This is due to -fms-extensions. It Expands `__Pragma` to `#pragma` 
instead of keeping it a `__Pragma`. This is a one-line fix.

@alexfh This was fixed by D106924 

I would suggest to not revert. Will upload a patch for `-fms-extensions` after 
some cleanup.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104601

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

RE: [clang] 9ca905b - XFAIL a test on ppc64

2021-07-30 Thread via cfe-commits

Do you have a suggestion for how to fix it?  This isn’t actually my test, I 
tripped over it and it seemed like it would be easy to get it to work.  ☹
Thanks,
--paulr

From: Hubert Tong 
Sent: Friday, July 30, 2021 12:43 PM
To: Robinson, Paul ; Paul Robinson 

Cc: cfe-commits 
Subject: Re: [clang] 9ca905b - XFAIL a test on ppc64

On Fri, Jul 30, 2021 at 12:05 PM Paul Robinson via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:

Author: Paul Robinson
Date: 2021-07-30T09:05:14-07:00
New Revision: 9ca905b52d53c46aceb4d28e44dfbf4a815d0c68

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

LOG: XFAIL a test on ppc64

Buildbot failure:
https://lab.llvm.org/buildbot/#/builders/105/builds/13141
which provides no details about why it failed,

Which would be because the test is set up to display warnings but won't display 
errors.

/usr/bin/as: unrecognized option '--32'

I also tried `x86_64-pc-linux-gnu`:

/usr/bin/as: unrecognized option '--64'

It probably makes sense that these options aren't supported if the system is 
64-bit only.

but the only failure
reports are for ppc64 bots.

Added:


Modified:
clang/test/Driver/as-no-warnings.c

Removed:




diff  --git a/clang/test/Driver/as-no-warnings.c 
b/clang/test/Driver/as-no-warnings.c
index 9c2b3f096872..77971389ee65 100644
--- a/clang/test/Driver/as-no-warnings.c
+++ b/clang/test/Driver/as-no-warnings.c
@@ -14,6 +14,7 @@
 // REQUIRES: clang-driver
 // REQUIRES: x86-registered-target
 // REQUIRES: system-linux
+// XFAIL: ppc64

 // CHECK: "-cc1" {{.*}} "-massembler-no-warn"
 // CHECK-NOIAS: "--no-warn"



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

[PATCH] D104904: [OpenMP][AMDGCN] Initial math headers support

2021-07-30 Thread Ye Luo via Phabricator via cfe-commits

ye-luo added a comment.

Unforuantely I hit error

  #include 
  int main()
  { }

~/opt/llvm-clang/build_mirror_offload_main/bin/clang++ -fopenmp 
-fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa 
-march=gfx906 main.cpp -c
works fine

~/opt/llvm-clang/build_mirror_offload_main/bin/clang++ -fopenmp 
-fopenmp-targets=nvptx64 main.cpp

  $ ~/opt/llvm-clang/build_mirror_offload_main/bin/clang++ -fopenmp 
-fopenmp-targets=nvptx64 
--libomptarget-nvptx-bc-path=/home/yeluo/opt/llvm-clang/build_mirror_offload_main/runtimes/runtimes-bins/openmp/libomptarget/libomptarget-nvptx-sm_80.bc
 main.cpp -c --std=c++14
  clang-14: warning: Unknown CUDA version. cuda.h: CUDA_VERSION=11040. Assuming 
the latest supported version 10.1 [-Wunknown-cuda-version]
  In file included from main.cpp:2:
  In file included from 
/home/yeluo/opt/llvm-clang/build_mirror_offload_main/lib/clang/14.0.0/include/openmp_wrappers/complex:26:
  In file included from 
/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/complex:45:
  In file included from 
/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/sstream:38:
  In file included from 
/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/istream:38:
  In file included from 
/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/ios:38:
  In file included from 
/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/iosfwd:39:
  
/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/stringfwd.h:73:30:
 error: no template named 'allocator'
 typename _Alloc = allocator<_CharT> >
   ^
  
/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/stringfwd.h:73:21:
 error: template parameter missing a default argument
 typename _Alloc = allocator<_CharT> >
  ^
  
/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/stringfwd.h:72:48:
 note: previous default template argument defined here
template,
 ^
  
/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/stringfwd.h:79:11:
 error: too few template arguments for class template 'basic_string'
typedef basic_stringstring;   
^
  
/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/stringfwd.h:74:11:
 note: template is declared here
  class basic_string;
^
  
/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/stringfwd.h:83:11:
 error: too few template arguments for class template 'basic_string'
typedef basic_string wstring;   
^
  
/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/stringfwd.h:74:11:
 note: template is declared here
  class basic_string;
^
  
/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/stringfwd.h:93:11:
 error: too few template arguments for class template 'basic_string'
typedef basic_string u16string; 
^
  
/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/stringfwd.h:74:11:
 note: template is declared here
  class basic_string;
^
  
/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/stringfwd.h:96:11:
 error: too few template arguments for class template 'basic_string'
typedef basic_string u32string; 
^
  
/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/stringfwd.h:74:11:
 note: template is declared here
  class basic_string;
^

Manually add  fixes the problem.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104904

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

Re: [clang] 9ca905b - XFAIL a test on ppc64

2021-07-30 Thread Hubert Tong via cfe-commits

On Fri, Jul 30, 2021 at 12:05 PM Paul Robinson via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> Author: Paul Robinson
> Date: 2021-07-30T09:05:14-07:00
> New Revision: 9ca905b52d53c46aceb4d28e44dfbf4a815d0c68
>
> URL:
> https://github.com/llvm/llvm-project/commit/9ca905b52d53c46aceb4d28e44dfbf4a815d0c68
> DIFF:
> https://github.com/llvm/llvm-project/commit/9ca905b52d53c46aceb4d28e44dfbf4a815d0c68.diff
>
> LOG: XFAIL a test on ppc64
>
> Buildbot failure:
> https://lab.llvm.org/buildbot/#/builders/105/builds/13141
> which provides no details about why it failed,


Which would be because the test is set up to display warnings but won't
display errors.

/usr/bin/as: unrecognized option '--32'

I also tried `x86_64-pc-linux-gnu`:

/usr/bin/as: unrecognized option '--64'

It probably makes sense that these options aren't supported if the system
is 64-bit only.


> but the only failure
> reports are for ppc64 bots.
>
> Added:
>
>
> Modified:
> clang/test/Driver/as-no-warnings.c
>
> Removed:
>
>
>
>
> 
> diff  --git a/clang/test/Driver/as-no-warnings.c
> b/clang/test/Driver/as-no-warnings.c
> index 9c2b3f096872..77971389ee65 100644
> --- a/clang/test/Driver/as-no-warnings.c
> +++ b/clang/test/Driver/as-no-warnings.c
> @@ -14,6 +14,7 @@
>  // REQUIRES: clang-driver
>  // REQUIRES: x86-registered-target
>  // REQUIRES: system-linux
> +// XFAIL: ppc64
>
>  // CHECK: "-cc1" {{.*}} "-massembler-no-warn"
>  // CHECK-NOIAS: "--no-warn"
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] c15d982 - XFAIL ppc => powerpc

2021-07-30 Thread Paul Robinson via cfe-commits


Author: Paul Robinson
Date: 2021-07-30T09:39:51-07:00
New Revision: c15d9822b3ab767d744e93d7d9c25d5f7d2faac8

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

LOG: XFAIL ppc => powerpc

Added: 


Modified: 
clang/test/Driver/as-no-warnings.c

Removed: 




diff  --git a/clang/test/Driver/as-no-warnings.c 
b/clang/test/Driver/as-no-warnings.c
index 77971389ee65..c785c054155c 100644
--- a/clang/test/Driver/as-no-warnings.c
+++ b/clang/test/Driver/as-no-warnings.c
@@ -14,7 +14,7 @@
 // REQUIRES: clang-driver
 // REQUIRES: x86-registered-target
 // REQUIRES: system-linux
-// XFAIL: ppc64
+// XFAIL: powerpc
 
 // CHECK: "-cc1" {{.*}} "-massembler-no-warn"
 // CHECK-NOIAS: "--no-warn"



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

[PATCH] D99487: [CodeGen] Port basic block sections from ELF to COFF

2021-07-30 Thread Reid Kleckner via Phabricator via cfe-commits

rnk added inline comments.



Comment at: llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp:1712
+  COFF::IMAGE_SCN_MEM_READ | COFF::IMAGE_SCN_LNK_COMDAT,
+  SectionKind::getText(), COMDATSymName,
+  COFF::IMAGE_COMDAT_SELECT_NODUPLICATES, UniqueID);

TaoPan wrote:
> TaoPan wrote:
> > TaoPan wrote:
> > > mstorsjo wrote:
> > > > rnk wrote:
> > > > > mstorsjo wrote:
> > > > > > TaoPan wrote:
> > > > > > > rnk wrote:
> > > > > > > > tmsriram wrote:
> > > > > > > > > MaskRay wrote:
> > > > > > > > > > TaoPan wrote:
> > > > > > > > > > > tmsriram wrote:
> > > > > > > > > > > > COMDATSymName can be folded to be equal to 
> > > > > > > > > > > > MBB.getSymbol()->getName() here?  Plus, you are not 
> > > > > > > > > > > > preserving the .text.hot prefix that the original 
> > > > > > > > > > > > function might get here.  Is this future work?  If the 
> > > > > > > > > > > > original function is named .text.hot.foo, the basic 
> > > > > > > > > > > > block will still be named .text.foo.__part.1 which is 
> > > > > > > > > > > > not right.
> > > > > > > > > > > > 
> > > > > > > > > > > > Plus, what about exception handling sections like 
> > > > > > > > > > > > ".eh.*"?
> > > > > > > > > > > Thanks! I'll redesign section name and comdat symbol name.
> > > > > > > > > > > The text section with prefix "hot" and "unlikely" won't 
> > > > > > > > > > > be constructed here, I added COFF text section prefix 
> > > > > > > > > > > "hot" and "unlikely" in D92073. In ELF override function, 
> > > > > > > > > > > also not handling text section with prefix "hot" and 
> > > > > > > > > > > "unlikely".
> > > > > > > > > > > The text section with prefix "split" will be constructed 
> > > > > > > > > > > here, I plan to add related code in MFS COFF patch.
> > > > > > > > > > > Also, exception handling section is future work that 
> > > > > > > > > > > support basic block sections Windows COFF exception 
> > > > > > > > > > > handling.
> > > > > > > > > > This is complex. PE-COFF has multiple COMDAT seletion 
> > > > > > > > > > kinds. I want to see a holistic plan how every component is 
> > > > > > > > > > going to be implemented.
> > > > > > > > > The basic block should just mimic the COMDAT type of its 
> > > > > > > > > containing function, is there a reason to do anything more 
> > > > > > > > > with it here?
> > > > > > > > After thinking about it a bit, I think the entry block should 
> > > > > > > > use the regular selection kind, and all of the auxilliary MBB 
> > > > > > > > sections should use IMAGE_COMDAT_SELECT_ASSOCIATIVE. They 
> > > > > > > > should be associated with the main function symbol, unless the 
> > > > > > > > function itself is associated with something else, in which 
> > > > > > > > case the BBs use that symbol.
> > > > > > > > 
> > > > > > > > This will ensure that if the main function section prevails, 
> > > > > > > > they are included, and if it does not prevail, they are 
> > > > > > > > discarded. Does that make sense?
> > > > > > > Thanks! I think set entry block sections as regular 
> > > > > > > IMAGE_COMDAT_SELECT_NODUPLICATES and set the auxilliary MBB 
> > > > > > > sections as IMAGE_COMDAT_SELECT_ASSOCIATIVE is fine. I changed.
> > > > > > @rnk - I'm not quite familiar with the concrete implications of 
> > > > > > this work here, but would this need to be mapped to the GNU style 
> > > > > > comdats, for compatibility with ld.bfd for mingw targets? (LLD 
> > > > > > itself works fine with proper associative comdats though.)
> > > > > I think basic block sections are kind of in the same category as LTO: 
> > > > > it's a very sophisticated optimization feature, and it's probably OK 
> > > > > if it's LLD-only. I think it also requires special linker support 
> > > > > that might make it LLD-only, but I've forgotten the details.
> > > > > 
> > > > > It also has potentially very high object file size overhead, and it 
> > > > > will be important to do everything possible to minimize that object 
> > > > > file size overhead. Long gnu-style section names for every basic 
> > > > > block section are likely to make the feature unusably slow, so maybe 
> > > > > it's worth removing these "if mingw" conditionals. We can leave 
> > > > > behind a comment by the use of IMAGE_COMDAT_SELECT_ASSOCIATIVE 
> > > > > indicating that gnu-style section names are not needed because the 
> > > > > feature is only designed to work with LLD.
> > > > Thanks for the clarification! Leaving the feature as LLD-only (or in 
> > > > other terms, requiring a conforming COMDAT implementation) sounds good 
> > > > to me.
> > > Thanks for discussion between @mstorsjo and @rnk !
> > > I removed "if mingw" conditionals.
> > @rnk about the issue 4.a of https://reviews.llvm.org/D99487#2821343, I 
> > tried to use clang-cl.exe with bbs option and lld to build helloworld c 
> > program, meet IMAGE_COMDAT_SELECT_XXX related problem.
> > helloworld c program is general c demo

[PATCH] D104601: [Preprocessor] Implement -fminimize-whitespace.

2021-07-30 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added a comment.

In D104601#2916887 , @Meinersbur 
wrote:

> I am working on a fix, but I wouldn't mind reverting.

I would be comfortable reverting the feature for Clang 13 and fixing forward on 
trunk (unless there's a need to revert from trunk temporarily, of course). 
Giving the feature a full release to bake isn't a bad outcome.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104601

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

[PATCH] D106262: [clang][analyzer] Use generic note tag in alpha.unix.Stream .

2021-07-30 Thread Kristóf Umann via Phabricator via cfe-commits

Szelethus added a comment.

In D106262#2915764 , @balazske wrote:

> The bug type is passed to `constructNoteTag` only to identify what message 
> will be displayed. The bug types that are related to the current function (a 
> message should be here if the bug is happening) are passed in. It should be 
> enough to look at comment before `constructNoteTag` to check this (and to the 
> bug type -> message map).
>
>   C.addTransition(StateFailed, constructNoteTag(C, StreamSym,
> {_StreamEof,
>  _IndeterminatePosition}));
>
> This indicates that if later an EOF error happens (function called in EOF 
> state) this is the place to display a message "stream becomes EOF here". And 
> if later an error "stream position indeterminate" happens the note should be 
> here too, but with other message. So we can not have a single string as last 
> parameter instead of the bug types.

Right, okay, I see that I looked over something important.

I forgot our optimization trickery. It is reminiscent of a Schrödinger's cat: 
after a failed stream operation, the stream object could simultaneously be in 
either of these states:

- Reached EOF,
- Have an indeterminate file position,
- Have ferror set.

TL;DR:
--

No matter what happens during analysis, as of now, the NoteTag message is 
unambiguous at the point of the tags construction. Do we have plans to change 
our current modeling around indeterminate file positions, or add a warning for 
FERROR that would necessitate the proposed complexity?

Onto the rest:
--

Its at the next stream operation where its decided what state it was actually 
put in. So, if a stream operation like `fseek` fails, it may leave the stream 
object in any of the above states. Later, when we analyze `fread`, we check in 
`preFread` //in order// whether the stream is null, is opened, its file 
position indicator is determinate, and whether the stream has EOF set. 
Whichever error is detected first will be the one to get emitted, and in this 
case, its going to be an indeterminate file position.

  void f(FILE *f) {
fseek(f, offset, origin); // note: stream operation failed
fread(ptr, size, count, f); // warn: indeterminate file position
  }

Now, lets check explicitly whether `fseek` left the stream in FERROR, and 
return early if so. Lets discuss how `fseek` should work another time, but for 
the sake of this example, *suppose* that it only leaves the file position 
indicator indeterminate if it also sets FERROR, and `ferror` respects this 
supposed behaviour. In that case, only the EOF flag remains.

  void f(FILE *f) {
fseek(f, offset, origin); // note: assuming stream reached eof
if (ferror(f)) // note: assuming the condition is false
  return;
fread(ptr, size, count, f); // warn: stream already in eof
  }

The bug type changed, and it would be handy if the note tag changed as well. It 
really is the inspection of the bug type (hence the Schrödinger-like behaviour) 
that decides what error was actually inflicted upon the stream object at 
`fseek`.

---

Now, its worth noting that in practice, NoteTags never change their message. 
Lets take a survey:

  BugType BT_FileNull{this, "NULL stream pointer", "Stream handling error"};
  BugType BT_UseAfterOpenFailed{this, "Invalid stream",
"Stream handling error"};

The only meaningful NoteTag is for both of these is added around a failed 
(re)open, and the emitted string shouldn't depend on which one it is. Stream 
objects are never in a "schrödinger-like" state in terms of these bugs -- a 
stream is either NULL, or NULL as a result of a failed open.

  BugType BT_IllegalWhence{this, "Illegal whence argument",
   "Stream handling error"};

This is practically a statement-local issue, and even if the whence argument 
was calculated elsewhere, its hardly the job of this checker to track down.

  BugType BT_UseAfterClose{this, "Closed stream", "Stream handling error"};

The only noteworthy event here is where was the stream was closed. Stream 
closure cannot fail, the only state a stream can remain in after a call to 
`close` is it being closed, so the note message is unambiguous.

  BugType BT_ResourceLeak{this, "Resource leak", "Stream handling error",
  /*SuppressOnSink =*/true};

The only noteworthy event is stream opening. Now, opening can fail, but we 
split the state immediately there, and we can either write "Opened stream 
here", or "Opening stream failed here". On each of these path, this message is 
unambiguous.

  BugType BT_IndeterminatePosition{this, "Invalid stream state",
   "Stream handling error"};
  BugType BT_StreamEof{this, "Stream already in EOF", "Stream handling error"};

Alright, so this is the juicy one. As demonstrated above, a number of stream

[PATCH] D104601: [Preprocessor] Implement -fminimize-whitespace.

2021-07-30 Thread Michael Kruse via Phabricator via cfe-commits

Meinersbur added a comment.

I am working on a fix, but I wouldn't mind reverting.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104601

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

[PATCH] D107176: [OpenCL] Replace test for pipe struct to test it with fixed triple

2021-07-30 Thread Anastasia Stulova via Phabricator via cfe-commits

Anastasia accepted this revision.
Anastasia 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/D107176/new/

https://reviews.llvm.org/D107176

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

[PATCH] D106431: [clang-tidy] Fix cppcoreguidelines-init-variables by removing the enum FixIt, and add support for initialization check of scoped enum.

2021-07-30 Thread Whisperity 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 rG4a097efe7784: [clang-tidy] Fix 
cppcoreguidelines-init-variables by removing the enum (authored by Sockke, 
committed by whisperity).

Changed prior to commit:
  https://reviews.llvm.org/D106431?vs=362663=363123#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106431

Files:
  clang-tools-extra/clang-tidy/cppcoreguidelines/InitVariablesCheck.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-init-variables.rst
  
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-init-variables.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-init-variables.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-init-variables.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-init-variables.cpp
@@ -92,3 +92,35 @@
   } catch (int X) {
   }
 }
+
+enum Color { Red,
+ Green,
+ Blue };
+
+enum Car { Benz,
+   BMW = 20,
+   Audi = BMW + 2 };
+
+enum Gender : char { Male,
+ Female };
+
+enum class Direction { Up,
+   Down,
+   Left,
+   Right };
+
+enum class Fruit : int { Apple,
+ Orange };
+
+void uninitialized_enum() {
+  Color color;
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: variable 'color' is not initialized [cppcoreguidelines-init-variables]
+  Car car;
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: variable 'car' is not initialized [cppcoreguidelines-init-variables]
+  Gender gender;
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: variable 'gender' is not initialized [cppcoreguidelines-init-variables]
+  Direction direction;
+  // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: variable 'direction' is not initialized [cppcoreguidelines-init-variables]
+  Fruit fruit;
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: variable 'fruit' is not initialized [cppcoreguidelines-init-variables]
+}
Index: clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-init-variables.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-init-variables.rst
+++ clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-init-variables.rst
@@ -37,6 +37,21 @@
  // Rest of the function.
}
 
+It warns for the uninitialized enum case, but without a FixIt:
+
+.. code-block:: c++
+
+   enum A {A1, A2, A3};
+   enum A_c : char { A_c1, A_c2, A_c3 };
+   enum class B { B1, B2, B3 };
+   enum class B_i : int { B_i1, B_i2, B_i3 };
+   void function() {
+ A a; // Warning: variable 'a' is not initialized
+ A_c a_c; // Warning: variable 'a_c' is not initialized
+ B b; // Warning: variable 'b' is not initialized
+ B_i b_i; // Warning: variable 'b_i' is not initialized
+   }
+
 Options
 ---
 
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -78,6 +78,12 @@
 Changes in existing checks
 ^^
 
+- Improved :doc:`cppcoreguidelines-init-variables` check.
+
+  Removed generating fixes for enums because the code generated was broken, trying to initialize the enum from an integer.
+
+  The check now also warns for uninitialized scoped enums.
+
 Removed checks
 ^^
 
Index: clang-tools-extra/clang-tidy/cppcoreguidelines/InitVariablesCheck.cpp
===
--- clang-tools-extra/clang-tidy/cppcoreguidelines/InitVariablesCheck.cpp
+++ clang-tools-extra/clang-tidy/cppcoreguidelines/InitVariablesCheck.cpp
@@ -78,10 +78,12 @@
 return;
 
   QualType TypePtr = MatchedDecl->getType();
-  const char *InitializationString = nullptr;
+  llvm::Optional InitializationString = llvm::None;
   bool AddMathInclude = false;
 
-  if (TypePtr->isIntegerType())
+  if (TypePtr->isEnumeralType())
+InitializationString = nullptr;
+  else if (TypePtr->isIntegerType())
 InitializationString = " = 0";
   else if (TypePtr->isFloatingType()) {
 InitializationString = " = NAN";
@@ -96,11 +98,12 @@
   if (InitializationString) {
 auto Diagnostic =
 diag(MatchedDecl->getLocation(), "variable %0 is not initialized")
-<< MatchedDecl
-<< FixItHint::CreateInsertion(
-   MatchedDecl->getLocation().getLocWithOffset(
-   MatchedDecl->getName().size()),
-   InitializationString);
+<< MatchedDecl;
+if (*InitializationString != nullptr)
+  Diagnostic << FixItHint::CreateInsertion(
+

[clang-tools-extra] 4a097ef - [clang-tidy] Fix cppcoreguidelines-init-variables by removing the enum

2021-07-30 Thread via cfe-commits


Author: Liuke Gehry
Date: 2021-07-30T18:24:47+02:00
New Revision: 4a097efe7784767b7d12ffcb8f2b22b9f4d045e2

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

LOG: [clang-tidy] Fix cppcoreguidelines-init-variables by removing the enum
FixIt, and add support for initialization check of scoped enum

In C++, the enumeration is never Integer, and the enumeration condition 
judgment is added to avoid compiling errors when it is initialized to an 
integer.
Add support for initialization check of scope enum.

As the following case show, clang-tidy will give a wrong automatic fix:

enum Color {Red, Green, Blue};
enum class Gender {Male, Female};
void func() {
  Color color; // Color color = 0; <--- fix bug
  Gender gender; // <--- no warning
}

Reviewd By: aaron.ballman, whisperity

Differential Revision: http://reviews.llvm.org/D106431

Added: 


Modified: 
clang-tools-extra/clang-tidy/cppcoreguidelines/InitVariablesCheck.cpp
clang-tools-extra/docs/ReleaseNotes.rst

clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-init-variables.rst

clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-init-variables.cpp

Removed: 




diff  --git 
a/clang-tools-extra/clang-tidy/cppcoreguidelines/InitVariablesCheck.cpp 
b/clang-tools-extra/clang-tidy/cppcoreguidelines/InitVariablesCheck.cpp
index d9be9b653e3b6..cded53487ae8f 100644
--- a/clang-tools-extra/clang-tidy/cppcoreguidelines/InitVariablesCheck.cpp
+++ b/clang-tools-extra/clang-tidy/cppcoreguidelines/InitVariablesCheck.cpp
@@ -78,10 +78,12 @@ void InitVariablesCheck::check(const 
MatchFinder::MatchResult ) {
 return;
 
   QualType TypePtr = MatchedDecl->getType();
-  const char *InitializationString = nullptr;
+  llvm::Optional InitializationString = llvm::None;
   bool AddMathInclude = false;
 
-  if (TypePtr->isIntegerType())
+  if (TypePtr->isEnumeralType())
+InitializationString = nullptr;
+  else if (TypePtr->isIntegerType())
 InitializationString = " = 0";
   else if (TypePtr->isFloatingType()) {
 InitializationString = " = NAN";
@@ -96,11 +98,12 @@ void InitVariablesCheck::check(const 
MatchFinder::MatchResult ) {
   if (InitializationString) {
 auto Diagnostic =
 diag(MatchedDecl->getLocation(), "variable %0 is not initialized")
-<< MatchedDecl
-<< FixItHint::CreateInsertion(
-   MatchedDecl->getLocation().getLocWithOffset(
-   MatchedDecl->getName().size()),
-   InitializationString);
+<< MatchedDecl;
+if (*InitializationString != nullptr)
+  Diagnostic << FixItHint::CreateInsertion(
+  MatchedDecl->getLocation().getLocWithOffset(
+  MatchedDecl->getName().size()),
+  *InitializationString);
 if (AddMathInclude) {
   Diagnostic << IncludeInserter.createIncludeInsertion(
   Source.getFileID(MatchedDecl->getBeginLoc()), MathHeader);

diff  --git a/clang-tools-extra/docs/ReleaseNotes.rst 
b/clang-tools-extra/docs/ReleaseNotes.rst
index afa685d1fbdd9..ae96b2bcf868a 100644
--- a/clang-tools-extra/docs/ReleaseNotes.rst
+++ b/clang-tools-extra/docs/ReleaseNotes.rst
@@ -78,6 +78,12 @@ New check aliases
 Changes in existing checks
 ^^
 
+- Improved 
:doc:`cppcoreguidelines-init-variables`
 check.
+
+  Removed generating fixes for enums because the code generated was broken, 
trying to initialize the enum from an integer.
+
+  The check now also warns for uninitialized scoped enums.
+
 Removed checks
 ^^
 

diff  --git 
a/clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-init-variables.rst 
b/clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-init-variables.rst
index 62af932837c15..91cf4aa0f0bb1 100644
--- 
a/clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-init-variables.rst
+++ 
b/clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-init-variables.rst
@@ -37,6 +37,21 @@ Would be rewritten to look like this:
  // Rest of the function.
}
 
+It warns for the uninitialized enum case, but without a FixIt:
+
+.. code-block:: c++
+
+   enum A {A1, A2, A3};
+   enum A_c : char { A_c1, A_c2, A_c3 };
+   enum class B { B1, B2, B3 };
+   enum class B_i : int { B_i1, B_i2, B_i3 };
+   void function() {
+ A a; // Warning: variable 'a' is not initialized
+ A_c a_c; // Warning: variable 'a_c' is not initialized
+ B b; // Warning: variable 'b' is not initialized
+ B_i b_i; // Warning: variable 'b_i' is not initialized
+   }
+
 Options
 ---
 

diff  --git 
a/clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-init-variables.cpp
 
b/clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-init-variables.cpp
index a2a59fe75aa28..3ee1f0aaec49e 100644

[PATCH] D107176: [OpenCL] Replace test for pipe struct to test it with fixed triple

2021-07-30 Thread Anton Zabaznov via Phabricator via cfe-commits

azabaznov created this revision.
azabaznov added a reviewer: Anastasia.
Herald added subscribers: ldrumm, yaxunl.
azabaznov requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D107176

Files:
  clang/test/CodeGenOpenCL/pipe_builtin.cl
  clang/test/CodeGenOpenCL/pipe_types.cl


Index: clang/test/CodeGenOpenCL/pipe_types.cl
===
--- clang/test/CodeGenOpenCL/pipe_types.cl
+++ clang/test/CodeGenOpenCL/pipe_types.cl
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 
-cl-std=CL2.0 -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 
-cl-std=CL2.0 -DTEST_STRUCT -o - %s | FileCheck %s
 // RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 
-cl-std=CL3.0 
-cl-ext=+__opencl_c_pipes,+__opencl_c_generic_address_space,+__opencl_c_program_scope_global_variables
 -o - %s | FileCheck %s
 // RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 
-cl-std=CL3.0 
-cl-ext=+__opencl_c_pipes,+__opencl_c_generic_address_space,-__opencl_c_program_scope_global_variables
 -o - %s | FileCheck %s
 
@@ -33,3 +33,19 @@
 kernel void test6(MyPipe p) {
 // CHECK: define{{.*}} spir_kernel void @test6(%opencl.pipe_ro_t* %p)
 }
+
+#ifdef TEST_STRUCT
+// FIXME: not supported for OpenCL C 3.0 as language built-ins not supported 
yet
+struct Person {
+  const char *Name;
+  bool isFemale;
+  int ID;
+};
+
+void test9(global struct Person *SDst, read_only pipe struct Person SPipe) {
+  // CHECK: call i32 @__read_pipe_2(%opencl.pipe_ro_t* %{{.*}}, i8* %{{.*}}, 
i32 16, i32 8)
+  read_pipe (SPipe, SDst);
+  // CHECK: call i32 @__read_pipe_2(%opencl.pipe_ro_t* %{{.*}}, i8* %{{.*}}, 
i32 16, i32 8)
+  read_pipe (SPipe, SDst);
+}
+#endif // TEST_STRUCT
Index: clang/test/CodeGenOpenCL/pipe_builtin.cl
===
--- clang/test/CodeGenOpenCL/pipe_builtin.cl
+++ clang/test/CodeGenOpenCL/pipe_builtin.cl
@@ -71,16 +71,3 @@
   // CHECK: call i32 @__get_pipe_max_packets_wo(%opencl.pipe_wo_t* %{{.*}}, 
i32 4, i32 4)
   *ptr = get_pipe_max_packets(p);
 }
-
-struct Person {
-  const char *Name;
-  bool isFemale;
-  int ID;
-};
-
-void test9(global struct Person *SDst, read_only pipe struct Person SPipe) {
-  // CHECK: call i32 @__read_pipe_2(%opencl.pipe_ro_t* %{{.*}}, i8* %{{.*}}, 
i32 16, i32 8)
-  read_pipe (SPipe, SDst);
-  // CHECK: call i32 @__read_pipe_2(%opencl.pipe_ro_t* %{{.*}}, i8* %{{.*}}, 
i32 16, i32 8)
-  read_pipe (SPipe, SDst);
-}


Index: clang/test/CodeGenOpenCL/pipe_types.cl
===
--- clang/test/CodeGenOpenCL/pipe_types.cl
+++ clang/test/CodeGenOpenCL/pipe_types.cl
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 -cl-std=CL2.0 -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 -cl-std=CL2.0 -DTEST_STRUCT -o - %s | FileCheck %s
 // RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 -cl-std=CL3.0 -cl-ext=+__opencl_c_pipes,+__opencl_c_generic_address_space,+__opencl_c_program_scope_global_variables -o - %s | FileCheck %s
 // RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -O0 -cl-std=CL3.0 -cl-ext=+__opencl_c_pipes,+__opencl_c_generic_address_space,-__opencl_c_program_scope_global_variables -o - %s | FileCheck %s
 
@@ -33,3 +33,19 @@
 kernel void test6(MyPipe p) {
 // CHECK: define{{.*}} spir_kernel void @test6(%opencl.pipe_ro_t* %p)
 }
+
+#ifdef TEST_STRUCT
+// FIXME: not supported for OpenCL C 3.0 as language built-ins not supported yet
+struct Person {
+  const char *Name;
+  bool isFemale;
+  int ID;
+};
+
+void test9(global struct Person *SDst, read_only pipe struct Person SPipe) {
+  // CHECK: call i32 @__read_pipe_2(%opencl.pipe_ro_t* %{{.*}}, i8* %{{.*}}, i32 16, i32 8)
+  read_pipe (SPipe, SDst);
+  // CHECK: call i32 @__read_pipe_2(%opencl.pipe_ro_t* %{{.*}}, i8* %{{.*}}, i32 16, i32 8)
+  read_pipe (SPipe, SDst);
+}
+#endif // TEST_STRUCT
Index: clang/test/CodeGenOpenCL/pipe_builtin.cl
===
--- clang/test/CodeGenOpenCL/pipe_builtin.cl
+++ clang/test/CodeGenOpenCL/pipe_builtin.cl
@@ -71,16 +71,3 @@
   // CHECK: call i32 @__get_pipe_max_packets_wo(%opencl.pipe_wo_t* %{{.*}}, i32 4, i32 4)
   *ptr = get_pipe_max_packets(p);
 }
-
-struct Person {
-  const char *Name;
-  bool isFemale;
-  int ID;
-};
-
-void test9(global struct Person *SDst, read_only pipe struct Person SPipe) {
-  // CHECK: call i32 @__read_pipe_2(%opencl.pipe_ro_t* %{{.*}}, i8* %{{.*}}, i32 16, i32 8)
-  read_pipe (SPipe, SDst);
-  // CHECK: call i32 @__read_pipe_2(%opencl.pipe_ro_t* %{{.*}}, i8* %{{.*}}, i32 16, i32 8)
-  read_pipe (SPipe, SDst);
-}
___
cfe-commits mailing

[PATCH] D106891: [AMDGPU] [Remarks] Emit optimization remarks when an FP atomic instruction is converted into a CAS loop or unsafe hardware instruction for GFX90A

2021-07-30 Thread Anshil Gandhi via Phabricator via cfe-commits

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



Comment at: llvm/lib/Target/AMDGPU/SIISelLowering.cpp:12086
+   TargetLowering::AtomicExpansionKind Kind, bool UnsafeFlag) {
+  ORE = new OptimizationRemarkEmitter(RMW->getFunction());
+  if (Kind == TargetLowering::AtomicExpansionKind::CmpXChg) {

arsenm wrote:
> This is supposed to come from the pass, I don't think you can materialize 
> this out of nowhere
I couldn't get `getAnalysis().getORE()` 
to work.



Comment at: llvm/lib/Target/AMDGPU/SIISelLowering.cpp:12100
+  }
+  delete ORE;
+  return Kind;

arsenm wrote:
> Should not need to create and delete, the analysis pass should own this
above comment


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106891

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

[PATCH] D106891: [AMDGPU] [Remarks] Emit optimization remarks when an FP atomic instruction is converted into a CAS loop or unsafe hardware instruction for GFX90A

2021-07-30 Thread Matt Arsenault via Phabricator via cfe-commits

arsenm added inline comments.



Comment at: llvm/lib/Target/AMDGPU/SIISelLowering.cpp:12090
+  OptimizationRemark Remark(DEBUG_TYPE, "Passed", RMW->getFunction());
+  Remark << "An FP atomic instruction was expanded into a CAS loop.";
+  return Remark;

Using FP abbreviation is unclear. IIRC there shouldn't be an end period in 
messages



Comment at: llvm/lib/Target/AMDGPU/SIISelLowering.cpp:12096
+  OptimizationRemark Remark(DEBUG_TYPE, "Passed", RMW->getFunction());
+  Remark << "An unsafe hardware instruction was generated.";
+  return Remark;

This message seems concerning. Unless you already know everything about this 
instruction, it doesn't really help you.



Comment at: llvm/lib/Target/AMDGPU/SIISelLowering.cpp:12100
+  }
+  delete ORE;
+  return Kind;

Should not need to create and delete, the analysis pass should own this


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106891

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

[PATCH] D106891: [AMDGPU] [Remarks] Emit optimization remarks when an FP atomic instruction is converted into a CAS loop or unsafe hardware instruction for GFX90A

2021-07-30 Thread Matt Arsenault via Phabricator via cfe-commits

arsenm added a comment.

Needs an IR only test too




Comment at: llvm/lib/Target/AMDGPU/SIISelLowering.cpp:12086
+   TargetLowering::AtomicExpansionKind Kind, bool UnsafeFlag) {
+  ORE = new OptimizationRemarkEmitter(RMW->getFunction());
+  if (Kind == TargetLowering::AtomicExpansionKind::CmpXChg) {

This is supposed to come from the pass, I don't think you can materialize this 
out of nowhere


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106891

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

[PATCH] D106909: [clang] Add clang builtins support for gfx90a

2021-07-30 Thread Matt Arsenault via Phabricator via cfe-commits

arsenm added inline comments.



Comment at: clang/include/clang/Basic/BuiltinsAMDGPU.def:201
+TARGET_BUILTIN(__builtin_amdgcn_global_atomic_fadd_f32, "ff*1fi", "t", 
"gfx90a-insts")
+TARGET_BUILTIN(__builtin_amdgcn_global_atomic_fadd_2f16, "hh*1hi", "t", 
"gfx90a-insts")
+TARGET_BUILTIN(__builtin_amdgcn_global_atomic_fmin_f64, "dd*1di", "t", 
"gfx90a-insts")

yaxunl wrote:
> arsenm wrote:
> > "_2f16" looks weird to me. The instruction names call it "pk"
> This is to have a consistent postfix naming convention, since the stem part 
> here are the same. the postfix is for the argument type of the builtin 
> function.
Just a plain 2 isn't consistent either. The llvm type naming convention would 
add a v prefix, but the builtins should probably follow the instructions



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:16114
+Intrinsic::ID IID;
+llvm::Type *ArgTy = llvm::Type::getDoubleTy(getLLVMContext());
+switch (BuiltinID) {

gandhi21299 wrote:
> arsenm wrote:
> > Initializing this here is strange, sink down to the double case
> You mean push it down after line 16119?
Yes



Comment at: clang/test/CodeGenOpenCL/builtins-fp-atomics.cl:112
+kernel void test_flat_global_max(__global double *addr, double x){
+  __builtin_amdgcn_flat_atomic_fmax_f64(addr, x, memory_order_relaxed);
+}

gandhi21299 wrote:
> arsenm wrote:
> > If you're going to bother testing the ISA, is it worth testing rtn and no 
> > rtn versions?
> Sorry, what do you mean by rtn version?
Most atomics can be optimized if they don't return the in memory value if the 
value is unused


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106909

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

[PATCH] D106891: [AMDGPU] [Remarks] Emit optimization remarks when an FP atomic instruction is converted into a CAS loop or unsafe hardware instruction for GFX90A

2021-07-30 Thread Anshil Gandhi via Phabricator via cfe-commits

gandhi21299 added a comment.

Passed PSDB


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106891

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

1 2 >

1 - 100 of 198 matches

Mail list logo