[PATCH] D92634: [Analyzer] Diagnose signed integer overflow

[Daniel Marjamäki via Phabricator via cfe-commits]

danielmarjamaki added a comment.

I have run clang static analysis on random open source projects. The very first 
finding that I look at seems (to me) to be a false positive. :-(

My code seems to think that a variable `print_count` has the value INT_MAX for 
some reason and to me that seems impossible. I'll investigate this..

analyzed package:
ftp://ftp.de.debian.org/debian/pool/main/libm/libmsiecf/libmsiecf_20181227.orig.tar.gz

>
=

libcerror_error.c:426:45: warning: The result of the '+' expression is 
undefined [core.UndefinedBinaryOperatorResult]

error_string_size = (size_t) print_count + 1;


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92634

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

[PATCH] D86855: Convert __m64 intrinsics to unconditionally use SSE2 instead of MMX instructions.

[Craig Topper via Phabricator via cfe-commits]

craig.topper added inline comments.



Comment at: clang/lib/Headers/mmintrin.h:1264
 {
-return (__m64)__builtin_ia32_pcmpgtw((__v4hi)__m1, (__v4hi)__m2);
+return (__m64)((__v4hi)__m1 > (__v4hi)__m2);
 }

jyknight wrote:
> craig.topper wrote:
> > Same here
> This is a short, which is always signed, so it should be ok as written.
Yeah. I don't know why I wrote that now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86855

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

[PATCH] D94067: [clang][ASTImporter] Fix a possible assertion failure `NeedsInjectedClassNameType(Decl)'.

[Balázs Kéri via Phabricator via cfe-commits]

balazske updated this revision to Diff 315055.
balazske added a comment.

Removing unrelated (for the bug fix) change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94067

Files:
  clang/lib/AST/ASTImporter.cpp
  clang/unittests/AST/ASTImporterTest.cpp


Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -6141,6 +6141,41 @@
   EXPECT_EQ(ToAttr->getAnnotation(), "A");
 }
 
+TEST_P(ASTImporterOptionSpecificTestBase,
+   ImportOfTemplatedDeclWhenPreviousDeclHasNoDescribedTemplateSet) {
+  Decl *FromTU = getTuDecl(
+  R"(
+
+  namespace std {
+template
+class basic_stringbuf;
+  }
+  namespace std {
+class char_traits;
+template
+class basic_stringbuf;
+  }
+  namespace std {
+template
+class basic_stringbuf {};
+  }
+
+  )",
+  Lang_CXX11);
+
+  auto *From1 = FirstDeclMatcher().match(
+  FromTU,
+  classTemplateDecl(hasName("basic_stringbuf"), unless(isImplicit(;
+  auto *To1 = cast_or_null(Import(From1, Lang_CXX11));
+  EXPECT_TRUE(To1);
+
+  auto *From2 = LastDeclMatcher().match(
+  FromTU,
+  classTemplateDecl(hasName("basic_stringbuf"), unless(isImplicit(;
+  auto *To2 = cast_or_null(Import(From2, Lang_CXX11));
+  EXPECT_TRUE(To2);
+}
+
 INSTANTIATE_TEST_CASE_P(ParameterizedTests, ASTImporterLookupTableTest,
 DefaultTestValuesForRunOptions, );
 
Index: clang/lib/AST/ASTImporter.cpp
===
--- clang/lib/AST/ASTImporter.cpp
+++ clang/lib/AST/ASTImporter.cpp
@@ -5393,16 +5393,16 @@
 
   CXXRecordDecl *FromTemplated = D->getTemplatedDecl();
 
+  auto TemplateParamsOrErr = import(D->getTemplateParameters());
+  if (!TemplateParamsOrErr)
+return TemplateParamsOrErr.takeError();
+
   // Create the declaration that is being templated.
   CXXRecordDecl *ToTemplated;
   if (Error Err = importInto(ToTemplated, FromTemplated))
 return std::move(Err);
 
   // Create the class template declaration itself.
-  auto TemplateParamsOrErr = import(D->getTemplateParameters());
-  if (!TemplateParamsOrErr)
-return TemplateParamsOrErr.takeError();
-
   ClassTemplateDecl *D2;
   if (GetImportedOrCreateDecl(D2, D, Importer.getToContext(), DC, Loc, Name,
   *TemplateParamsOrErr, ToTemplated))


Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -6141,6 +6141,41 @@
   EXPECT_EQ(ToAttr->getAnnotation(), "A");
 }
 
+TEST_P(ASTImporterOptionSpecificTestBase,
+   ImportOfTemplatedDeclWhenPreviousDeclHasNoDescribedTemplateSet) {
+  Decl *FromTU = getTuDecl(
+  R"(
+
+  namespace std {
+template
+class basic_stringbuf;
+  }
+  namespace std {
+class char_traits;
+template
+class basic_stringbuf;
+  }
+  namespace std {
+template
+class basic_stringbuf {};
+  }
+
+  )",
+  Lang_CXX11);
+
+  auto *From1 = FirstDeclMatcher().match(
+  FromTU,
+  classTemplateDecl(hasName("basic_stringbuf"), unless(isImplicit(;
+  auto *To1 = cast_or_null(Import(From1, Lang_CXX11));
+  EXPECT_TRUE(To1);
+
+  auto *From2 = LastDeclMatcher().match(
+  FromTU,
+  classTemplateDecl(hasName("basic_stringbuf"), unless(isImplicit(;
+  auto *To2 = cast_or_null(Import(From2, Lang_CXX11));
+  EXPECT_TRUE(To2);
+}
+
 INSTANTIATE_TEST_CASE_P(ParameterizedTests, ASTImporterLookupTableTest,
 DefaultTestValuesForRunOptions, );
 
Index: clang/lib/AST/ASTImporter.cpp
===
--- clang/lib/AST/ASTImporter.cpp
+++ clang/lib/AST/ASTImporter.cpp
@@ -5393,16 +5393,16 @@
 
   CXXRecordDecl *FromTemplated = D->getTemplatedDecl();
 
+  auto TemplateParamsOrErr = import(D->getTemplateParameters());
+  if (!TemplateParamsOrErr)
+return TemplateParamsOrErr.takeError();
+
   // Create the declaration that is being templated.
   CXXRecordDecl *ToTemplated;
   if (Error Err = importInto(ToTemplated, FromTemplated))
 return std::move(Err);
 
   // Create the class template declaration itself.
-  auto TemplateParamsOrErr = import(D->getTemplateParameters());
-  if (!TemplateParamsOrErr)
-return TemplateParamsOrErr.takeError();
-
   ClassTemplateDecl *D2;
   if (GetImportedOrCreateDecl(D2, D, Importer.getToContext(), DC, Loc, Name,
   *TemplateParamsOrErr, ToTemplated))
___
cfe-commits mailing list
cfe-commits@lists.llvm.org

[PATCH] D92812: [X86] Update tests for znver3

[Ganesh Gopalasubramanian via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGdbfc1ac4d86c: [X86] Update tests for znver3 (authored by 
GGanesh).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92812

Files:
  clang/test/Driver/x86-march.c
  clang/test/Frontend/x86-target-cpu.c
  llvm/test/MC/X86/x86_long_nop.s


Index: llvm/test/MC/X86/x86_long_nop.s
===
--- llvm/test/MC/X86/x86_long_nop.s
+++ llvm/test/MC/X86/x86_long_nop.s
@@ -15,6 +15,8 @@
 # RUN: llvm-mc -filetype=obj -arch=x86 -triple=i686-pc-linux-gnu %s 
-mcpu=znver1 | llvm-objdump -d --no-show-raw-insn - | FileCheck %s 
--check-prefix=LNOP15
 # RUN: llvm-mc -filetype=obj -arch=x86 -triple=x86_64-pc-linux-gnu 
-mcpu=znver2 %s | llvm-objdump -d --no-show-raw-insn - | FileCheck %s 
--check-prefix=LNOP15
 # RUN: llvm-mc -filetype=obj -arch=x86 -triple=i686-pc-linux-gnu %s 
-mcpu=znver2 | llvm-objdump -d --no-show-raw-insn - | FileCheck %s 
--check-prefix=LNOP15
+# RUN: llvm-mc -filetype=obj -arch=x86 -triple=x86_64-pc-linux-gnu 
-mcpu=znver3 %s | llvm-objdump -d --no-show-raw-insn - | FileCheck %s 
--check-prefix=LNOP15
+# RUN: llvm-mc -filetype=obj -arch=x86 -triple=i686-pc-linux-gnu %s 
-mcpu=znver3 | llvm-objdump -d --no-show-raw-insn - | FileCheck %s 
--check-prefix=LNOP15
 # RUN: llvm-mc -filetype=obj -arch=x86 -triple=i686-pc-linux-gnu -mcpu=nehalem 
%s | llvm-objdump -d --no-show-raw-insn - | FileCheck --check-prefix=LNOP10 %s
 # RUN: llvm-mc -filetype=obj -arch=x86 -triple=i686-pc-linux-gnu 
-mcpu=westmere %s | llvm-objdump -d --no-show-raw-insn - | FileCheck 
--check-prefix=LNOP10 %s
 # RUN: llvm-mc -filetype=obj -arch=x86 -triple=i686-pc-linux-gnu 
-mcpu=sandybridge %s | llvm-objdump -d --no-show-raw-insn - | FileCheck 
--check-prefix=LNOP15 %s
Index: clang/test/Frontend/x86-target-cpu.c
===
--- clang/test/Frontend/x86-target-cpu.c
+++ clang/test/Frontend/x86-target-cpu.c
@@ -36,5 +36,6 @@
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu btver2 -verify %s
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu znver1 -verify %s
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu znver2 -verify %s
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu znver3 -verify %s
 //
 // expected-no-diagnostics
Index: clang/test/Driver/x86-march.c
===
--- clang/test/Driver/x86-march.c
+++ clang/test/Driver/x86-march.c
@@ -179,6 +179,10 @@
 // RUN: %clang -target x86_64-unknown-unknown -c -### %s -march=znver2 2>&1 \
 // RUN:   | FileCheck %s -check-prefix=znver2
 // znver2: "-target-cpu" "znver2"
+//
+// RUN: %clang -target x86_64-unknown-unknown -c -### %s -march=znver3 2>&1 \
+// RUN:   | FileCheck %s -check-prefix=znver3
+// znver3: "-target-cpu" "znver3"
 
 // RUN: %clang -target x86_64 -c -### %s -march=x86-64 2>&1 | FileCheck %s 
--check-prefix=x86-64
 // x86-64: "-target-cpu" "x86-64"


Index: llvm/test/MC/X86/x86_long_nop.s
===
--- llvm/test/MC/X86/x86_long_nop.s
+++ llvm/test/MC/X86/x86_long_nop.s
@@ -15,6 +15,8 @@
 # RUN: llvm-mc -filetype=obj -arch=x86 -triple=i686-pc-linux-gnu %s -mcpu=znver1 | llvm-objdump -d --no-show-raw-insn - | FileCheck %s --check-prefix=LNOP15
 # RUN: llvm-mc -filetype=obj -arch=x86 -triple=x86_64-pc-linux-gnu -mcpu=znver2 %s | llvm-objdump -d --no-show-raw-insn - | FileCheck %s --check-prefix=LNOP15
 # RUN: llvm-mc -filetype=obj -arch=x86 -triple=i686-pc-linux-gnu %s -mcpu=znver2 | llvm-objdump -d --no-show-raw-insn - | FileCheck %s --check-prefix=LNOP15
+# RUN: llvm-mc -filetype=obj -arch=x86 -triple=x86_64-pc-linux-gnu -mcpu=znver3 %s | llvm-objdump -d --no-show-raw-insn - | FileCheck %s --check-prefix=LNOP15
+# RUN: llvm-mc -filetype=obj -arch=x86 -triple=i686-pc-linux-gnu %s -mcpu=znver3 | llvm-objdump -d --no-show-raw-insn - | FileCheck %s --check-prefix=LNOP15
 # RUN: llvm-mc -filetype=obj -arch=x86 -triple=i686-pc-linux-gnu -mcpu=nehalem %s | llvm-objdump -d --no-show-raw-insn - | FileCheck --check-prefix=LNOP10 %s
 # RUN: llvm-mc -filetype=obj -arch=x86 -triple=i686-pc-linux-gnu -mcpu=westmere %s | llvm-objdump -d --no-show-raw-insn - | FileCheck --check-prefix=LNOP10 %s
 # RUN: llvm-mc -filetype=obj -arch=x86 -triple=i686-pc-linux-gnu -mcpu=sandybridge %s | llvm-objdump -d --no-show-raw-insn - | FileCheck --check-prefix=LNOP15 %s
Index: clang/test/Frontend/x86-target-cpu.c
===
--- clang/test/Frontend/x86-target-cpu.c
+++ clang/test/Frontend/x86-target-cpu.c
@@ -36,5 +36,6 @@
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu btver2 -verify %s
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu znver1 -verify %s
 // RUN: %clang_cc1 

[clang] dbfc1ac - [X86] Update tests for znver3

[Ganesh Gopalasubramanian via cfe-commits]

Author: Ganesh Gopalasubramanian
Date: 2021-01-07T11:51:50+05:30
New Revision: dbfc1ac4d86c1c08dc5ccd90a0389254e13c6d01

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

LOG: [X86] Update tests for znver3

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

Added: 


Modified: 
clang/test/Driver/x86-march.c
clang/test/Frontend/x86-target-cpu.c
llvm/test/MC/X86/x86_long_nop.s

Removed: 




diff  --git a/clang/test/Driver/x86-march.c b/clang/test/Driver/x86-march.c
index 871f47109b40..515981eec506 100644
--- a/clang/test/Driver/x86-march.c
+++ b/clang/test/Driver/x86-march.c
@@ -179,6 +179,10 @@
 // RUN: %clang -target x86_64-unknown-unknown -c -### %s -march=znver2 2>&1 \
 // RUN:   | FileCheck %s -check-prefix=znver2
 // znver2: "-target-cpu" "znver2"
+//
+// RUN: %clang -target x86_64-unknown-unknown -c -### %s -march=znver3 2>&1 \
+// RUN:   | FileCheck %s -check-prefix=znver3
+// znver3: "-target-cpu" "znver3"
 
 // RUN: %clang -target x86_64 -c -### %s -march=x86-64 2>&1 | FileCheck %s 
--check-prefix=x86-64
 // x86-64: "-target-cpu" "x86-64"

diff  --git a/clang/test/Frontend/x86-target-cpu.c 
b/clang/test/Frontend/x86-target-cpu.c
index 05b28f0f68fe..84b100f7e944 100644
--- a/clang/test/Frontend/x86-target-cpu.c
+++ b/clang/test/Frontend/x86-target-cpu.c
@@ -36,5 +36,6 @@
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu btver2 -verify %s
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu znver1 -verify %s
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu znver2 -verify %s
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu znver3 -verify %s
 //
 // expected-no-diagnostics

diff  --git a/llvm/test/MC/X86/x86_long_nop.s b/llvm/test/MC/X86/x86_long_nop.s
index 981a38f75972..17941a5cff9d 100644
--- a/llvm/test/MC/X86/x86_long_nop.s
+++ b/llvm/test/MC/X86/x86_long_nop.s
@@ -15,6 +15,8 @@
 # RUN: llvm-mc -filetype=obj -arch=x86 -triple=i686-pc-linux-gnu %s 
-mcpu=znver1 | llvm-objdump -d --no-show-raw-insn - | FileCheck %s 
--check-prefix=LNOP15
 # RUN: llvm-mc -filetype=obj -arch=x86 -triple=x86_64-pc-linux-gnu 
-mcpu=znver2 %s | llvm-objdump -d --no-show-raw-insn - | FileCheck %s 
--check-prefix=LNOP15
 # RUN: llvm-mc -filetype=obj -arch=x86 -triple=i686-pc-linux-gnu %s 
-mcpu=znver2 | llvm-objdump -d --no-show-raw-insn - | FileCheck %s 
--check-prefix=LNOP15
+# RUN: llvm-mc -filetype=obj -arch=x86 -triple=x86_64-pc-linux-gnu 
-mcpu=znver3 %s | llvm-objdump -d --no-show-raw-insn - | FileCheck %s 
--check-prefix=LNOP15
+# RUN: llvm-mc -filetype=obj -arch=x86 -triple=i686-pc-linux-gnu %s 
-mcpu=znver3 | llvm-objdump -d --no-show-raw-insn - | FileCheck %s 
--check-prefix=LNOP15
 # RUN: llvm-mc -filetype=obj -arch=x86 -triple=i686-pc-linux-gnu -mcpu=nehalem 
%s | llvm-objdump -d --no-show-raw-insn - | FileCheck --check-prefix=LNOP10 %s
 # RUN: llvm-mc -filetype=obj -arch=x86 -triple=i686-pc-linux-gnu 
-mcpu=westmere %s | llvm-objdump -d --no-show-raw-insn - | FileCheck 
--check-prefix=LNOP10 %s
 # RUN: llvm-mc -filetype=obj -arch=x86 -triple=i686-pc-linux-gnu 
-mcpu=sandybridge %s | llvm-objdump -d --no-show-raw-insn - | FileCheck 
--check-prefix=LNOP15 %s



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

[PATCH] D92751: [clang][aarch64] Precondition isHomogeneousAggregate on isCXX14Aggregate

[David Truby via Phabricator via cfe-commits]

DavidTruby marked 2 inline comments as done.
DavidTruby added inline comments.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:5137
+
+  if (!isHomogeneousAggregateForABI(CXXRD))
+return false;

rnk wrote:
> Apologies for moving the goalposts, but after re-reading the code, I feel 
> like it would make more sense to make this a CGCXXABI virtual method. This 
> code then would read:
>   if (!getCXXABI().isPermittedToBeHomogeneousAggregate(CXXRD))
> return false;
> 
> IMO it also makes sense to move this up before checking bases.
I agree this is much cleaner and have made the change based on your suggestion. 
Thanks for the review!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92751

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

[PATCH] D92751: [clang][aarch64] Precondition isHomogeneousAggregate on isCXX14Aggregate

[David Truby via Phabricator via cfe-commits]

DavidTruby updated this revision to Diff 315042.
DavidTruby added a comment.

Refactor based on review


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92751

Files:
  clang/lib/CodeGen/CGCXXABI.h
  clang/lib/CodeGen/MicrosoftCXXABI.cpp
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGenCXX/homogeneous-aggregates.cpp
  llvm/test/CodeGen/AArch64/arm64-windows-calls.ll

Index: llvm/test/CodeGen/AArch64/arm64-windows-calls.ll
===
--- llvm/test/CodeGen/AArch64/arm64-windows-calls.ll
+++ llvm/test/CodeGen/AArch64/arm64-windows-calls.ll
@@ -98,3 +98,74 @@
   %this1 = load %class.C*, %class.C** %this.addr, align 8
   ret void
 }
+
+; The following tests correspond to tests in
+; clang/test/CodeGenCXX/microsoft-abi-sret-and-byval.cpp
+
+; Pod is a trivial HFA
+%struct.Pod = type { [2 x double] }
+; Not an aggregate according to C++14 spec => not HFA according to MSVC
+%struct.NotCXX14Aggregate  = type { %struct.Pod }
+; NotPod is a C++14 aggregate. But not HFA, because it contains
+; NotCXX14Aggregate (which itself is not HFA because it's not a C++14
+; aggregate).
+%struct.NotPod = type { %struct.NotCXX14Aggregate }
+
+define dso_local %struct.Pod @copy_pod(%struct.Pod* %x) {
+  %x1 = load %struct.Pod, %struct.Pod* %x, align 8
+  ret %struct.Pod %x1
+; CHECK-LABEL: ldp d0, d1, [x0]
+}
+
+declare void @llvm.memcpy.p0i8.p0i8.i64(i8* noalias nocapture writeonly, i8* noalias nocapture readonly, i64, i1 immarg)
+
+define dso_local void
+@copy_notcxx14aggregate(%struct.NotCXX14Aggregate* inreg noalias sret(%struct.NotCXX14Aggregate) align 8 %agg.result,
+%struct.NotCXX14Aggregate* %x) {
+  %1 = bitcast %struct.NotCXX14Aggregate* %agg.result to i8*
+  %2 = bitcast %struct.NotCXX14Aggregate* %x to i8*
+  call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 8 %1, i8* align 8 %2, i64 16, i1 false)
+  ret void
+; CHECK-LABEL: str q0, [x0]
+}
+
+define dso_local [2 x i64] @copy_notpod(%struct.NotPod* %x) {
+  %x1 = bitcast %struct.NotPod* %x to [2 x i64]*
+  %x2 = load [2 x i64], [2 x i64]* %x1
+  ret [2 x i64] %x2
+; CHECK-LABEL: ldp x8, x1, [x0]
+; CHECK: mov x0, x8
+}
+
+@Pod = external global %struct.Pod
+
+define void @call_copy_pod() {
+  %x = call %struct.Pod @copy_pod(%struct.Pod* @Pod)
+  store %struct.Pod %x, %struct.Pod* @Pod
+  ret void
+  ; CHECK-LABEL: bl copy_pod
+  ; CHECK-NEXT: stp d0, d1, [{{.*}}]
+}
+
+@NotCXX14Aggregate = external global %struct.NotCXX14Aggregate
+
+define void @call_copy_notcxx14aggregate() {
+  %x = alloca %struct.NotCXX14Aggregate
+  call void @copy_notcxx14aggregate(%struct.NotCXX14Aggregate* %x, %struct.NotCXX14Aggregate* @NotCXX14Aggregate)
+  %x1 = load %struct.NotCXX14Aggregate, %struct.NotCXX14Aggregate* %x
+  store %struct.NotCXX14Aggregate %x1, %struct.NotCXX14Aggregate* @NotCXX14Aggregate
+  ret void
+  ; CHECK-LABEL: bl copy_notcxx14aggregate
+  ; CHECK-NEXT: ldp {{.*}}, {{.*}}, [sp]
+}
+
+@NotPod = external global %struct.NotPod
+
+define void @call_copy_notpod() {
+  %x = call [2 x i64] @copy_notpod(%struct.NotPod* @NotPod)
+  %notpod = bitcast %struct.NotPod* @NotPod to [2 x i64]*
+  store [2 x i64] %x, [2 x i64]* %notpod
+  ret void
+  ; CHECK-LABEL: bl copy_notpod
+  ; CHECK-NEXT: stp x0, x1, [{{.*}}]
+}
Index: clang/test/CodeGenCXX/homogeneous-aggregates.cpp
===
--- clang/test/CodeGenCXX/homogeneous-aggregates.cpp
+++ clang/test/CodeGenCXX/homogeneous-aggregates.cpp
@@ -104,3 +104,66 @@
 // ARM32: define arm_aapcs_vfpcc void @_Z19with_empty_bitfield20HVAWithEmptyBitField(%struct.HVAWithEmptyBitField %a.coerce)
 // X64: define dso_local x86_vectorcallcc void @"\01_Z19with_empty_bitfield20HVAWithEmptyBitField@@16"(%struct.HVAWithEmptyBitField inreg %a.coerce)
 void CC with_empty_bitfield(HVAWithEmptyBitField a) {}
+
+namespace pr47611 {
+// MSVC on Arm includes "isCXX14Aggregate" as part of its definition of
+// Homogeneous Floating-point Aggregate (HFA). Additionally, it has a different
+// handling of C++14 aggregates, which can lead to confusion.
+
+// Pod is a trivial HFA.
+struct Pod {
+  double b[2];
+};
+// Not an aggregate according to C++14 spec => not HFA according to MSVC.
+struct NotCXX14Aggregate {
+  NotCXX14Aggregate();
+  Pod p;
+};
+// NotPod is a C++14 aggregate. But not HFA, because it contains
+// NotCXX14Aggregate (which itself is not HFA because it's not a C++14
+// aggregate).
+struct NotPod {
+  NotCXX14Aggregate x;
+};
+struct Empty {};
+// A class with a base is returned using the sret calling convetion by MSVC.
+struct HasEmptyBase : public Empty {
+  double b[2];
+};
+struct HasPodBase : public Pod {};
+// WOA64-LABEL: define dso_local %"struct.pr47611::Pod" @"?copy@pr47611@@YA?AUPod@1@PEAU21@@Z"(%"struct.pr47611::Pod"* %x)
+Pod copy(Pod *x) { return *x; } // MSVC: ldp d0,d1,[x0], Clang: ldp d0,d1,[x0]
+// 

[PATCH] D94213: Clang: Remove support for 3DNow!, both intrinsics and builtins.

[James Y Knight via Phabricator via cfe-commits]

jyknight created this revision.
jyknight added reviewers: craig.topper, spatel, RKSimon.
Herald added subscribers: dang, pengfei.
jyknight requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

This set of instructions was only supported by AMD chips starting in
the K6 -2 (introduced 1998), and before the 
"Bulldozer" family
(2011). They were never much used, as they were effectively superseded
by the more-widely-implemented SSE (first implemented on the AMD side
in Athlon XP in 2001).

As part of the general removal of MMX register usage
(https://reviews.llvm.org/D86855), something also needs to be done
with the 3dnow intrinsics. Since there is almost no usage of these,
and no hardware implements them, simple removal of both the intrinsics
and the corresponding `__3dNOW__` feature define seems like the best
option.

Support for the underlying LLVM intrinsics remains unchanged, at least
for the moment, although it quite likely makes sense to remove support
on the LLVM side as well.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D94213

Files:
  clang/include/clang/Basic/BuiltinsX86.def
  clang/include/clang/Driver/Options.td
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Driver/ToolChains/Arch/X86.cpp
  clang/lib/Headers/mm3dnow.h
  clang/lib/Headers/x86intrin.h
  clang/test/CodeGen/X86/3dnow-builtins.c
  clang/test/CodeGen/builtins-x86.c
  clang/test/Driver/x86-target-features.c
  clang/test/Headers/mm3dnow.c
  clang/test/Preprocessor/predefined-arch-macros.c
  clang/test/Preprocessor/x86_target_features.c
  llvm/include/llvm/IR/IntrinsicsX86.td

Index: llvm/include/llvm/IR/IntrinsicsX86.td
===
--- llvm/include/llvm/IR/IntrinsicsX86.td
+++ llvm/include/llvm/IR/IntrinsicsX86.td
@@ -95,57 +95,57 @@
 // 3DNow!
 
 let TargetPrefix = "x86" in {
-  def int_x86_3dnow_pavgusb : GCCBuiltin<"__builtin_ia32_pavgusb">,
+  def int_x86_3dnow_pavgusb :
   Intrinsic<[llvm_x86mmx_ty], [llvm_x86mmx_ty, llvm_x86mmx_ty],
 [IntrNoMem]>;
-  def int_x86_3dnow_pf2id : GCCBuiltin<"__builtin_ia32_pf2id">,
+  def int_x86_3dnow_pf2id :
   Intrinsic<[llvm_x86mmx_ty], [llvm_x86mmx_ty], [IntrNoMem]>;
-  def int_x86_3dnow_pfacc : GCCBuiltin<"__builtin_ia32_pfacc">,
+  def int_x86_3dnow_pfacc :
   Intrinsic<[llvm_x86mmx_ty], [llvm_x86mmx_ty, llvm_x86mmx_ty],
 [IntrNoMem]>;
-  def int_x86_3dnow_pfadd : GCCBuiltin<"__builtin_ia32_pfadd">,
+  def int_x86_3dnow_pfadd :
   Intrinsic<[llvm_x86mmx_ty], [llvm_x86mmx_ty, llvm_x86mmx_ty],
 [IntrNoMem]>;
-  def int_x86_3dnow_pfcmpeq : GCCBuiltin<"__builtin_ia32_pfcmpeq">,
+  def int_x86_3dnow_pfcmpeq :
   Intrinsic<[llvm_x86mmx_ty], [llvm_x86mmx_ty, llvm_x86mmx_ty],
 [IntrNoMem]>;
-  def int_x86_3dnow_pfcmpge : GCCBuiltin<"__builtin_ia32_pfcmpge">,
+  def int_x86_3dnow_pfcmpge :
   Intrinsic<[llvm_x86mmx_ty], [llvm_x86mmx_ty, llvm_x86mmx_ty],
 [IntrNoMem]>;
-  def int_x86_3dnow_pfcmpgt : GCCBuiltin<"__builtin_ia32_pfcmpgt">,
+  def int_x86_3dnow_pfcmpgt :
   Intrinsic<[llvm_x86mmx_ty], [llvm_x86mmx_ty, llvm_x86mmx_ty],
 [IntrNoMem]>;
-  def int_x86_3dnow_pfmax : GCCBuiltin<"__builtin_ia32_pfmax">,
+  def int_x86_3dnow_pfmax :
   Intrinsic<[llvm_x86mmx_ty], [llvm_x86mmx_ty, llvm_x86mmx_ty],
 [IntrNoMem]>;
-  def int_x86_3dnow_pfmin : GCCBuiltin<"__builtin_ia32_pfmin">,
+  def int_x86_3dnow_pfmin :
   Intrinsic<[llvm_x86mmx_ty], [llvm_x86mmx_ty, llvm_x86mmx_ty],
 [IntrNoMem]>;
-  def int_x86_3dnow_pfmul : GCCBuiltin<"__builtin_ia32_pfmul">,
+  def int_x86_3dnow_pfmul :
   Intrinsic<[llvm_x86mmx_ty], [llvm_x86mmx_ty, llvm_x86mmx_ty],
 [IntrNoMem]>;
-  def int_x86_3dnow_pfrcp : GCCBuiltin<"__builtin_ia32_pfrcp">,
+  def int_x86_3dnow_pfrcp :
   Intrinsic<[llvm_x86mmx_ty], [llvm_x86mmx_ty], [IntrNoMem]>;
-  def int_x86_3dnow_pfrcpit1 : GCCBuiltin<"__builtin_ia32_pfrcpit1">,
+  def int_x86_3dnow_pfrcpit1 :
   Intrinsic<[llvm_x86mmx_ty], [llvm_x86mmx_ty, llvm_x86mmx_ty],
 [IntrNoMem]>;
-  def int_x86_3dnow_pfrcpit2 : GCCBuiltin<"__builtin_ia32_pfrcpit2">,
+  def int_x86_3dnow_pfrcpit2 :
   Intrinsic<[llvm_x86mmx_ty], [llvm_x86mmx_ty, llvm_x86mmx_ty],
 [IntrNoMem]>;
-  def int_x86_3dnow_pfrsqrt : GCCBuiltin<"__builtin_ia32_pfrsqrt">,
+  def int_x86_3dnow_pfrsqrt :
   Intrinsic<[llvm_x86mmx_ty], [llvm_x86mmx_ty], [IntrNoMem]>;
-  def int_x86_3dnow_pfrsqit1 : GCCBuiltin<"__builtin_ia32_pfrsqit1">,
+  def int_x86_3dnow_pfrsqit1 :
 

[PATCH] D86855: Convert __m64 intrinsics to unconditionally use SSE2 instead of MMX instructions.

[James Y Knight via Phabricator via cfe-commits]

jyknight marked 7 inline comments as done.
jyknight added a comment.
Herald added a subscriber: pengfei.

I've finally got back to moving this patch forward -- PTAL, thanks!

To start with, I wrote a simple test-suite to verify the functionality of these 
changes. I've included the tests I wrote under mmx-tests/ in this version of 
the patch -- although it doesn't actually belong there. I'm not exactly sure 
where it _does_ belong, however.

The test-suite runs a number of combinations of inputs against two different 
compilers' implementations of these intrinsics, and makes sure they produce 
identical results. I used this to ensure that there are no changes in behavior 
between old clang and clang after this change, as well as compared clang to 
GCC. Using that, I've fixed and verified all the bugs you noticed in codereview 
already, as well as additional bugs the testsuite found (in _mm_maddubs_pi16 
and _mm_shuffle_pi8). I'm feeling reasonably confident, now, that this change 
will not change behavior of these functions. The tests also discovered two bugs 
in GCC, https://gcc.gnu.org/PR98495, https://gcc.gnu.org/PR98522.

Some other changes in this update:

I switched _mm_extract_pi16 and _mm_insert_pi16 back to using an clang 
intrinsic, for consistency with the other extract/insert macros, which are 
using an intrinsic function simply to force the element-number to be a 
compile-time constant, and produce an error when it's not. But, the intrinsic 
now lowers to generic IR like all the other `__builtin_ia32_vec_{ext,set}_*`, 
rather than an llvm intrinsic forcing MMX. I modified the "composite" functions 
in xmmintrin.h to directly use 128-bit operations, instead of composites of 
multiple 64bit operations, where possible.

Finally, the clang tests have been updated, so that all tests pass again.




Comment at: clang/lib/Headers/mmintrin.h:367
 {
-return (__m64)__builtin_ia32_paddb((__v8qi)__m1, (__v8qi)__m2);
+return (__m64)(((__v8qi)__m1) + ((__v8qi)__m2));
 }

craig.topper wrote:
> I think you we should use __v8qu to match what we do in emmintrin.h. We don't 
> currently set nsw on signed vector arithmetic, but we should be careful in 
> case that changes in the future.
Done, here and everywhere else I was using signed math (except the comparisons).



Comment at: clang/lib/Headers/mmintrin.h:1097
 {
-return __builtin_ia32_pand((__v1di)__m1, (__v1di)__m2);
+return (__m64)(((__v1di)__m1) & ((__v1di)__m2));
 }

craig.topper wrote:
> I think we probably want to use a v2su or v2si here. Using v1di scalarizes 
> and splits on 32-bit targets. On 64-bit targets it emits GPR code.
AFAICT, this doesn't matter? It seems to emit GPR or XMM code just depending on 
whether the result values are needed as XMM or not, independent of whether the 
type is specified as v2su or v1du.




Comment at: clang/lib/Headers/mmintrin.h:1242
 {
-return (__m64)__builtin_ia32_pcmpgtb((__v8qi)__m1, (__v8qi)__m2);
+return (__m64)((__v8qi)__m1 > (__v8qi)__m2);
 }

craig.topper wrote:
> Need to use __v8qs here to force "signed char" elements. __v8qi uses "char" 
> which has platform dependent signedness or can be changed with a command line.
Done.



Comment at: clang/lib/Headers/mmintrin.h:1264
 {
-return (__m64)__builtin_ia32_pcmpgtw((__v4hi)__m1, (__v4hi)__m2);
+return (__m64)((__v4hi)__m1 > (__v4hi)__m2);
 }

craig.topper wrote:
> Same here
This is a short, which is always signed, so it should be ok as written.



Comment at: clang/lib/Headers/mmintrin.h:1394
 {
-return _mm_set_pi32(__i, __i);
+return __extension__ (__m64)(__v2si){__i, __i};
 }

craig.topper wrote:
> Is this needed?
No, reverted this change and the others like it.



Comment at: clang/lib/Headers/mmintrin.h:1452
 {
-return _mm_set_pi32(__i1, __i0);
+return __extension__ (__m64)(__v2si){__i1, __i0};
 }

craig.topper wrote:
> I don't think this change is needed. And I think the operands are in the 
> wrong order.
Change was unnecessary, so reverted. (But operands are supposed to be backwards 
here.)



Comment at: clang/lib/Headers/tmmintrin.h:17
 #define __DEFAULT_FN_ATTRS __attribute__((__always_inline__, __nodebug__, 
__target__("ssse3"), __min_vector_width__(64)))
-#define __DEFAULT_FN_ATTRS_MMX __attribute__((__always_inline__, __nodebug__, 
__target__("mmx,ssse3"), __min_vector_width__(64)))
+#define __trunc64(x) (__m64)__builtin_shufflevector((__v2di)(x), __extension__ 
(__v2di){}, 0)
+#define __anyext128(x) (__m128i)__builtin_shufflevector((__v1di)(x), 
__extension__ (__v1di){}, 0, -1)

craig.topper wrote:
> I'm worried that using v1di with the shuffles will lead to scalarization in 
> the type legalizer. Should we use v2si instead?
Converting `__trunc64` to v4si (and thus v2si return 

[PATCH] D91556: [OpenMPIRBuilder} Add capturing of parameters to pass to omp::parallel

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added inline comments.



Comment at: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:784
+}
+  }
+

1) If we would need this, remove the Counter stuff everywhere, if you want to 
iterate a container: `for (const T& : Container)`
2) `BlockParents` seems to be a set with the blocks, we already have that, it's 
called `ParallelRegionBlockSet`, simply pass it in.
3) Why don't we use the `Inputs` and `Outputs` set computed by the 
`findInputsOutputs` call. Those are the live-in and live-out values of the 
parallel region.



Comment at: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:795
+  unsigned CapturedSize = CapturedValues.size();
+  std::vector StructTypes;
+  StructTypes.reserve(CapturedSize);





Comment at: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:806
+llvm::IRBuilder<>::InsertPointGuard Guard(Builder);
+Builder.SetInsertPoint(InsertBeforeInst);
+

The alloca needs to go in the `OuterAllocaIP` passed in by the caller of 
`CreateParallel`.



Comment at: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:821
+Value *LoadedValue =
+Builder.CreateExtractValue(LoadedAlloca, SrcIdx.index());
+

I'm not too happy with this insert/extract value scheme. Without further 
optimization (-O0) this might not be lowered properly. Why don't we create a 
GEP and load/store to the appropriate location instead?



Comment at: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:831
+U.set(LoadedValue);
+  }
+}

Instead of doing this, unpack/load the location in the `PrivHelper` like we did 
before. Also, pass the loaded value as `Inner` to the `PrivCB` so that the 
callback has both the original value `V` and the reload `Inner`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91556

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

[PATCH] D93978: [clangd] DefineOutline doesn't require implementation file being saved

[Nathan James via Phabricator via cfe-commits]

njames93 added a comment.

In D93978#2479440 , @sammccall wrote:

> Ah, thanks for working on this!
>
> A few thoughts:
>
> - when we're pseudoparsing the file we're going to modify as we do here, 
> using the new content is strictly better, no downside :-)
> - the old method here of accessing the content through the FS attached to the 
> AST is a hack
> - however I think DraftStore is the wrong abstraction here and VFS is the 
> right one.
>   - each tweak shouldn't have to deal with falling back from DraftStore to 
> VFS (and rename also has an implementation of this!)
>   - C++ embedders don't have a DraftStore lying around
>   - bug: this code won't find a named but unsaved implementation file (since 
> getCorrespondingHeaderOrSource uses VFS)
> - (also Tweak::Selection isn't a pure abstraction, we can jam the FS in there 
> instead of passing it around as a separate param everywhere)
>
> So I think the right way to expose this to tweaks is to add a 
> `vfs::FileSystem *` member to `Tweak::Selection`, that allows accessing the 
> current FS (as opposed to the one used for building).
> The simplest implementation uses OverlayVFS + InMemoryFS + 
> TUScheduler::getAllFileContents(). This isn't as expensive as it sounds as we 
> need only set the FS pointer for `apply()`.
> (We can also implement a FS that copies more lazily, though I suspect it's 
> not worth it)

I'm getting a little stuck here. I've made a OverlayFS which has the a 
TFS::view as the base, and an InMemoryFS containing the contents of the 
TUScheduler. I Passed that in the Selection and it all worked.
However once I changed the `getSourceFile` function to also use that same FS, 
it would find the file ok, but then clangd would crash(with no visible trace) 
when it tried to open the file.

  auto Buffer = FS.getBufferForFile(*CCFile); // Here

From what I can getCorrespondingSourceOrHeader is querying the InMemoryFS and 
maybe those calls to FS::exists are somehow corrupting something.
Whatever it is, it all seems a bit messed up to me.

I'm gonna try with a debug build (and possibly asan) to see If I could possibly 
get anything more.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93978

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

[clang-tools-extra] 3505d8d - [clangd][NFC] Use PathRef for getCorrespondingHeaderOrSource

[Nathan James via cfe-commits]

Author: Nathan James
Date: 2021-01-07T02:41:19Z
New Revision: 3505d8dc07427b3d9165538d8f1cee574ea66804

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

LOG: [clangd][NFC] Use PathRef for getCorrespondingHeaderOrSource

Added: 


Modified: 
clang-tools-extra/clangd/ClangdServer.cpp
clang-tools-extra/clangd/HeaderSourceSwitch.cpp
clang-tools-extra/clangd/HeaderSourceSwitch.h
clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/ClangdServer.cpp 
b/clang-tools-extra/clangd/ClangdServer.cpp
index b760b31c0b87..d5e21cfb063e 100644
--- a/clang-tools-extra/clangd/ClangdServer.cpp
+++ b/clang-tools-extra/clangd/ClangdServer.cpp
@@ -549,8 +549,8 @@ void ClangdServer::switchSourceHeader(
   // the same directory.
   //  2) if 1) fails, we use the AST approach, it is slower but supports
   // 
diff erent code layout.
-  if (auto CorrespondingFile = getCorrespondingHeaderOrSource(
-  std::string(Path), TFS.view(llvm::None)))
+  if (auto CorrespondingFile =
+  getCorrespondingHeaderOrSource(Path, TFS.view(llvm::None)))
 return CB(std::move(CorrespondingFile));
   auto Action = [Path = Path.str(), CB = std::move(CB),
  this](llvm::Expected InpAST) mutable {

diff  --git a/clang-tools-extra/clangd/HeaderSourceSwitch.cpp 
b/clang-tools-extra/clangd/HeaderSourceSwitch.cpp
index d6b0b98f8d42..cd493a72b242 100644
--- a/clang-tools-extra/clangd/HeaderSourceSwitch.cpp
+++ b/clang-tools-extra/clangd/HeaderSourceSwitch.cpp
@@ -17,8 +17,7 @@ namespace clang {
 namespace clangd {
 
 llvm::Optional getCorrespondingHeaderOrSource(
-const Path ,
-llvm::IntrusiveRefCntPtr VFS) {
+PathRef OriginalFile, llvm::IntrusiveRefCntPtr VFS) 
{
   llvm::StringRef SourceExtensions[] = {".cpp", ".c", ".cc", ".cxx",
 ".c++", ".m", ".mm"};
   llvm::StringRef HeaderExtensions[] = {".h", ".hh", ".hpp", ".hxx", ".inc"};
@@ -51,25 +50,23 @@ llvm::Optional getCorrespondingHeaderOrSource(
 NewExts = SourceExtensions;
 
   // Storage for the new path.
-  llvm::SmallString<128> NewPath = llvm::StringRef(OriginalFile);
+  llvm::SmallString<128> NewPath = OriginalFile;
 
   // Loop through switched extension candidates.
   for (llvm::StringRef NewExt : NewExts) {
 llvm::sys::path::replace_extension(NewPath, NewExt);
 if (VFS->exists(NewPath))
-  return NewPath.str().str(); // First str() to convert from SmallString to
-  // StringRef, second to convert from 
StringRef
-  // to std::string
+  return Path(NewPath);
 
 // Also check NewExt in upper-case, just in case.
 llvm::sys::path::replace_extension(NewPath, NewExt.upper());
 if (VFS->exists(NewPath))
-  return NewPath.str().str();
+  return Path(NewPath);
   }
   return None;
 }
 
-llvm::Optional getCorrespondingHeaderOrSource(const Path ,
+llvm::Optional getCorrespondingHeaderOrSource(PathRef OriginalFile,
 ParsedAST ,
 const SymbolIndex *Index) {
   if (!Index) {
@@ -121,7 +118,7 @@ llvm::Optional getCorrespondingHeaderOrSource(const 
Path ,
   // candidates.
   Best = It;
   }
-  return Path(std::string(Best->first()));
+  return Path(Best->first());
 }
 
 std::vector getIndexableLocalDecls(ParsedAST ) {

diff  --git a/clang-tools-extra/clangd/HeaderSourceSwitch.h 
b/clang-tools-extra/clangd/HeaderSourceSwitch.h
index a971b385d74c..8cdd3f028280 100644
--- a/clang-tools-extra/clangd/HeaderSourceSwitch.h
+++ b/clang-tools-extra/clangd/HeaderSourceSwitch.h
@@ -18,12 +18,11 @@ namespace clangd {
 /// Given a header file, returns the best matching source file, and vice visa.
 /// It only uses the filename heuristics to do the inference.
 llvm::Optional getCorrespondingHeaderOrSource(
-const Path ,
-llvm::IntrusiveRefCntPtr VFS);
+PathRef OriginalFile, llvm::IntrusiveRefCntPtr VFS);
 
 /// Given a header file, returns the best matching source file, and vice visa.
 /// The heuristics incorporate with the AST and the index (if provided).
-llvm::Optional getCorrespondingHeaderOrSource(const Path ,
+llvm::Optional getCorrespondingHeaderOrSource(PathRef OriginalFile,
 ParsedAST ,
 const SymbolIndex *Index);
 

diff  --git a/clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp 
b/clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
index 6f7ad2e2a541..7a40ffae3d1c 100644
--- a/clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
+++ 

[PATCH] D92270: [ConstantFold] Fold more operations to poison

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

It turned out to be UB in our code as far as I can tell, see 
https://bugs.chromium.org/p/angleproject/issues/detail?id=5500#c36 and the 
follow-on.

(If this is known to trigger an existing bug more often, it might still be a 
good idea to undo it until that existing bug is fixed? But we're not affected 
by this existing bug as far as I can tell, so this is just a suggestion.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92270

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

[PATCH] D93638: [hip] Enable HIP compilation with ` on MSVC.

[Michael Liao via Phabricator via cfe-commits]

hliao added inline comments.



Comment at: clang/lib/Headers/__clang_hip_runtime_wrapper.h:73-74
+#define __HOST_DEVICE__
\
+  static __host__ __device__ inline __attribute__((always_inline))
+__HOST_DEVICE__ double _Cosh(double x, double y) { return cosh(x) * y; }
+__HOST_DEVICE__ float _FCosh(float x, float y) { return coshf(x) * y; }

hliao wrote:
> tra wrote:
> > hliao wrote:
> > > tra wrote:
> > > > hliao wrote:
> > > > > tra wrote:
> > > > > > hliao wrote:
> > > > > > > tra wrote:
> > > > > > > > I don't think we want to provide a HD implementation.
> > > > > > > > This will potentially change the meaning of these functions on 
> > > > > > > > the host side vs what they do in a C++ compilation.
> > > > > > > > It should probably be just `__device__`.
> > > > > > > > 
> > > > > > > > Next question is -- do we want to provide the definitions, or 
> > > > > > > > would just declarations be sufficient?
> > > > > > > > In other words -- are these functions needed for some standard 
> > > > > > > > C++ library functionality that we expect to work on the GPU?
> > > > > > > > If it's just to aid with overload resolution, declarations 
> > > > > > > > should do. 
> > > > > > > > 
> > > > > > > These functions are declared in ymath.h and, in the host 
> > > > > > > compilation, are resolved by linking MSVC RT libraries. For the 
> > > > > > > device function, as we already mark all prototypes in ymath.h as 
> > > > > > > HD, we have to implement them as HD to match the declaration. 
> > > > > > > But, those definitions should be only available in the device 
> > > > > > > compilation to avoid conflicts in the host compilation.
> > > > > > You don't need the definitions to avoid conflicting declarations.
> > > > > > 
> > > > > > I'm still not convinced that HD is needed.
> > > > > > Did you try just making these declarations `__device__` and remove 
> > > > > > the `ymath.h` wrapper?
> > > > > > Basically I'm trying to find the bare minimum we need to do to make 
> > > > > > it work.
> > > > > We don't call these functions directly. They are called in MSVC's 
> > > > > . As functions in  are marked as HD, we need to 
> > > > > mark these functions in ymath.h as HD to pass the compilation.
> > > > I assume that we're dealing with this file:
> > > > https://github.com/microsoft/STL/blob/master/stl/inc/ymath.h
> > > > 
> > > > I don't think we need a wrapper for ymath.
> > > > It may be sufficient to define or declare  `__device__ _Cosh()` and 
> > > > other functions and let overload resolution pick the right function.
> > > > I think it would be a better approach than providing an `inline 
> > > > __host__ __device__` definition for those functions and effectively 
> > > > replacing MSVC-provided host-side implementation of those functions.
> > > > 
> > > `ymath.h` could be included before ``. That implies `_Cosh` 
> > > could be declared as H only and results in the compilation failure.
> > > BTW, I don't think replacing host-side implementation is a good idea as 
> > > the host compilation should be kept consistent with the host compiler as 
> > > much as possible.
> > How? Isn't __clang_hip_runtime_wrapper.h included before anything in the 
> > user source file is processed? If the __clang_hip_runtime_wrapper.h is not 
> > included, first, then the ymath.h wrapper will not work either as it needs 
> > `__device__` macros.
> > 
> > > replacing host-side implementation is a good idea 
> > 
> > While consistency between host/device is good, we should not introduce a 
> > possible inconsistency between host-side TUs.
> > Considering vastly larger amounts of host-side code compiled as C++ (e.g. 
> > TF has way more C++ code than HIP/CUDA) and correspondingly more [[ 
> > https://www.hyrumslaw.com/ | reliance on every possible detail of the 
> > implementation ]], I would err on the side of not changing host-side 
> > behavior in any way at all, if possible.
> > 
> > It's reasonably safe to add an overload (it may still be observable, but 
> > it's usually possible to add it in a way that does not affect the host). 
> > Replacing host-side things is more risky, as it greatly expands the 
> > opportunities for things to go wrong.
> > 
> > 
> > 
> `` is also included in other headers, which is not wrapped. If we 
> don't wrap ``, there's a chance that it's included as it is. That's 
> why we have to wrap `` to ensure all functions marked with HD. Do I 
> miss anything?
I am wondering whether we could assume `` is an internal header *only*.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93638

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

[PATCH] D93638: [hip] Enable HIP compilation with ` on MSVC.

[Michael Liao via Phabricator via cfe-commits]

hliao added inline comments.



Comment at: clang/lib/Headers/__clang_hip_runtime_wrapper.h:73-74
+#define __HOST_DEVICE__
\
+  static __host__ __device__ inline __attribute__((always_inline))
+__HOST_DEVICE__ double _Cosh(double x, double y) { return cosh(x) * y; }
+__HOST_DEVICE__ float _FCosh(float x, float y) { return coshf(x) * y; }

tra wrote:
> hliao wrote:
> > tra wrote:
> > > hliao wrote:
> > > > tra wrote:
> > > > > hliao wrote:
> > > > > > tra wrote:
> > > > > > > I don't think we want to provide a HD implementation.
> > > > > > > This will potentially change the meaning of these functions on 
> > > > > > > the host side vs what they do in a C++ compilation.
> > > > > > > It should probably be just `__device__`.
> > > > > > > 
> > > > > > > Next question is -- do we want to provide the definitions, or 
> > > > > > > would just declarations be sufficient?
> > > > > > > In other words -- are these functions needed for some standard 
> > > > > > > C++ library functionality that we expect to work on the GPU?
> > > > > > > If it's just to aid with overload resolution, declarations should 
> > > > > > > do. 
> > > > > > > 
> > > > > > These functions are declared in ymath.h and, in the host 
> > > > > > compilation, are resolved by linking MSVC RT libraries. For the 
> > > > > > device function, as we already mark all prototypes in ymath.h as 
> > > > > > HD, we have to implement them as HD to match the declaration. But, 
> > > > > > those definitions should be only available in the device 
> > > > > > compilation to avoid conflicts in the host compilation.
> > > > > You don't need the definitions to avoid conflicting declarations.
> > > > > 
> > > > > I'm still not convinced that HD is needed.
> > > > > Did you try just making these declarations `__device__` and remove 
> > > > > the `ymath.h` wrapper?
> > > > > Basically I'm trying to find the bare minimum we need to do to make 
> > > > > it work.
> > > > We don't call these functions directly. They are called in MSVC's 
> > > > . As functions in  are marked as HD, we need to mark 
> > > > these functions in ymath.h as HD to pass the compilation.
> > > I assume that we're dealing with this file:
> > > https://github.com/microsoft/STL/blob/master/stl/inc/ymath.h
> > > 
> > > I don't think we need a wrapper for ymath.
> > > It may be sufficient to define or declare  `__device__ _Cosh()` and other 
> > > functions and let overload resolution pick the right function.
> > > I think it would be a better approach than providing an `inline __host__ 
> > > __device__` definition for those functions and effectively replacing 
> > > MSVC-provided host-side implementation of those functions.
> > > 
> > `ymath.h` could be included before ``. That implies `_Cosh` could 
> > be declared as H only and results in the compilation failure.
> > BTW, I don't think replacing host-side implementation is a good idea as the 
> > host compilation should be kept consistent with the host compiler as much 
> > as possible.
> How? Isn't __clang_hip_runtime_wrapper.h included before anything in the user 
> source file is processed? If the __clang_hip_runtime_wrapper.h is not 
> included, first, then the ymath.h wrapper will not work either as it needs 
> `__device__` macros.
> 
> > replacing host-side implementation is a good idea 
> 
> While consistency between host/device is good, we should not introduce a 
> possible inconsistency between host-side TUs.
> Considering vastly larger amounts of host-side code compiled as C++ (e.g. TF 
> has way more C++ code than HIP/CUDA) and correspondingly more [[ 
> https://www.hyrumslaw.com/ | reliance on every possible detail of the 
> implementation ]], I would err on the side of not changing host-side behavior 
> in any way at all, if possible.
> 
> It's reasonably safe to add an overload (it may still be observable, but it's 
> usually possible to add it in a way that does not affect the host). Replacing 
> host-side things is more risky, as it greatly expands the opportunities for 
> things to go wrong.
> 
> 
> 
`` is also included in other headers, which is not wrapped. If we 
don't wrap ``, there's a chance that it's included as it is. That's 
why we have to wrap `` to ensure all functions marked with HD. Do I 
miss anything?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93638

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

[PATCH] D94206: [clang-format] turn on formatting after "clang-format on" while sorting includes

[Rafał Jelonek via Phabricator via cfe-commits]

rjelonek created this revision.
rjelonek added reviewers: rsmith, rnk.
rjelonek created this object with visibility "All Users".
rjelonek created this object with edit policy "Members of Project: clang".
rjelonek added a project: clang-format.
rjelonek requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Formatting is not active after "clang-format on" due to merging lines while 
formatting is off. Also, use trimmed line. Behaviour with LF is different than 
with CRLF.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D94206

Files:
  clang/lib/Format/Format.cpp
  clang/unittests/Format/SortIncludesTest.cpp


Index: clang/unittests/Format/SortIncludesTest.cpp
===
--- clang/unittests/Format/SortIncludesTest.cpp
+++ clang/unittests/Format/SortIncludesTest.cpp
@@ -879,6 +879,58 @@
  "#include \"a.h\""));
 }
 
+TEST_F(SortIncludesTest, DetectClangFormatOn) {
+  Style.IncludeBlocks = Style.IBS_Merge;
+  std::string Code = "// clang-format off\r\n"
+ "#include \"d.h\"\r\n"
+ "#include \"b.h\"\r\n"
+ "// clang-format on\r\n"
+ "\r\n"
+ "#include \"c.h\"\r\n"
+ "#include \"a.h\"\r\n"
+ "#include \"e.h\"\r\n";
+
+  std::string Expected = "// clang-format off\r\n"
+ "#include \"d.h\"\r\n"
+ "#include \"b.h\"\r\n"
+ "// clang-format on\r\n"
+ "\r\n"
+ "#include \"e.h\"\r\n"
+ "#include \"a.h\"\r\n"
+ "#include \"c.h\"\r\n";
+
+  EXPECT_EQ(Expected, sort(Code, "e.cpp", 1));
+}
+
+TEST_F(SortIncludesTest, MergeLinesWhenCodeContainsLF) {
+  Style.IncludeBlocks = Style.IBS_Merge;
+  std::string Code = "#include \"c.h\"\n"
+ "#include \"b\\\n"
+ ".h\"\n"
+ "#include \"a.h\"\n";
+
+  std::string Expected = "#include \"a.h\"\n"
+ "#include \"b\\\n"
+ ".h\"\n"
+ "#include \"c.h\"\n";
+
+  EXPECT_EQ(Expected, sort(Code, "a.cpp", 1));
+}
+
+TEST_F(SortIncludesTest, MergeLinesWhenCodeContainsCRLF) {
+  Style.IncludeBlocks = Style.IBS_Merge;
+  std::string Code = "#include \"c.h\"\r\n"
+ "#include \"b\\\r\n"
+ ".h\"\r\n"
+ "#include \"a.h\"\r\n";
+
+  std::string Expected = "#include \"a.h\"\r\n"
+ "#include \"b\\\r\n"
+ ".h\"\r\n"
+ "#include \"c.h\"\r\n";
+
+  EXPECT_EQ(Expected, sort(Code, "a.cpp", 1));
+}
 } // end namespace
 } // end namespace format
 } // end namespace clang
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -2289,7 +2289,8 @@
  Style.IncludeStyle.IncludeBlocks ==
  tooling::IncludeStyle::IBS_Regroup);
 
-if (!FormattingOff && !Line.endswith("\\")) {
+bool MergeNextLine = Trimmed.endswith("\\");
+if (!FormattingOff && !MergeNextLine) {
   if (IncludeRegex.match(Line, )) {
 StringRef IncludeName = Matches[2];
 int Category = Categories.getIncludePriority(
@@ -2307,10 +2308,12 @@
 IncludesInBlock.clear();
 FirstIncludeBlock = false;
   }
-  Prev = Pos + 1;
 }
 if (Pos == StringRef::npos || Pos + 1 == Code.size())
   break;
+
+if (!MergeNextLine)
+  Prev = Pos + 1;
 SearchFrom = Pos + 1;
   }
   if (!IncludesInBlock.empty()) {


Index: clang/unittests/Format/SortIncludesTest.cpp
===
--- clang/unittests/Format/SortIncludesTest.cpp
+++ clang/unittests/Format/SortIncludesTest.cpp
@@ -879,6 +879,58 @@
  "#include \"a.h\""));
 }
 
+TEST_F(SortIncludesTest, DetectClangFormatOn) {
+  Style.IncludeBlocks = Style.IBS_Merge;
+  std::string Code = "// clang-format off\r\n"
+ "#include \"d.h\"\r\n"
+ "#include \"b.h\"\r\n"
+ "// clang-format on\r\n"
+ "\r\n"
+ "#include \"c.h\"\r\n"
+ "#include \"a.h\"\r\n"
+ "#include \"e.h\"\r\n";
+
+  std::string Expected = "// clang-format off\r\n"
+ "#include \"d.h\"\r\n"
+ "#include \"b.h\"\r\n"
+ "// clang-format on\r\n"
+ "\r\n"
+ "#include \"e.h\"\r\n"
+ "#include \"a.h\"\r\n"
+ "#include \"c.h\"\r\n";
+
+  EXPECT_EQ(Expected, sort(Code, "e.cpp", 1));
+}
+

[PATCH] D94196: [NFC] Move readAPValue/writeAPValue up the inheritance hierarchy

[Varun Gandhi via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG37e83bc6db3a: [NFC] Move readAPValue/writeAPValue up the 
inheritance hierarchy (authored by varungandhi-apple).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94196

Files:
  clang/include/clang/AST/APValue.h
  clang/include/clang/AST/AbstractBasicReader.h
  clang/include/clang/AST/AbstractBasicWriter.h
  clang/include/clang/AST/PropertiesBase.td
  clang/include/clang/Serialization/ASTRecordReader.h
  clang/include/clang/Serialization/ASTRecordWriter.h
  clang/include/clang/Serialization/ASTWriter.h
  clang/lib/AST/APValue.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/utils/TableGen/ClangASTPropertiesEmitter.cpp

Index: clang/utils/TableGen/ClangASTPropertiesEmitter.cpp
===
--- clang/utils/TableGen/ClangASTPropertiesEmitter.cpp
+++ clang/utils/TableGen/ClangASTPropertiesEmitter.cpp
@@ -708,15 +708,13 @@
   // Emit the Basic{Reader,Writer}Base template.
   Out << "template \n"
  "class Basic" << info.ClassSuffix << "Base {\n";
-  if (info.IsReader)
-Out << "  ASTContext \n";
+  Out << "  ASTContext \n";
   Out << "protected:\n"
- "  Basic" << info.ClassSuffix << "Base"
-   << (info.IsReader ? "(ASTContext ) : C(ctx)" : "()")
-   << " {}\n"
+ "  Basic"
+  << info.ClassSuffix << "Base" << ("(ASTContext ) : C(ctx)")
+  << " {}\n"
  "public:\n";
-  if (info.IsReader)
-Out << "  ASTContext () { return C; }\n";
+  Out << "  ASTContext () { return C; }\n";
   Out << "  Impl () { return static_cast(*this); }\n";
 
   auto enterReaderWriterMethod = [&](StringRef cxxTypeName,
Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -5121,144 +5121,6 @@
   AddAPInt(Value.bitcastToAPInt());
 }
 
-static void WriteFixedPointSemantics(ASTRecordWriter ,
- llvm::FixedPointSemantics FPSema) {
-  Record.push_back(FPSema.getWidth());
-  Record.push_back(FPSema.getScale());
-  Record.push_back(FPSema.isSigned() | FPSema.isSaturated() << 1 |
-   FPSema.hasUnsignedPadding() << 2);
-}
-
-void ASTRecordWriter::AddAPValue(const APValue ) {
-  APValue::ValueKind Kind = Value.getKind();
-  push_back(static_cast(Kind));
-  switch (Kind) {
-  case APValue::None:
-  case APValue::Indeterminate:
-return;
-  case APValue::Int:
-AddAPSInt(Value.getInt());
-return;
-  case APValue::Float:
-push_back(static_cast(
-llvm::APFloatBase::SemanticsToEnum(Value.getFloat().getSemantics(;
-AddAPFloat(Value.getFloat());
-return;
-  case APValue::FixedPoint: {
-WriteFixedPointSemantics(*this, Value.getFixedPoint().getSemantics());
-AddAPSInt(Value.getFixedPoint().getValue());
-return;
-  }
-  case APValue::ComplexInt: {
-AddAPSInt(Value.getComplexIntReal());
-AddAPSInt(Value.getComplexIntImag());
-return;
-  }
-  case APValue::ComplexFloat: {
-assert(llvm::APFloatBase::SemanticsToEnum(
-   Value.getComplexFloatImag().getSemantics()) ==
-   llvm::APFloatBase::SemanticsToEnum(
-   Value.getComplexFloatReal().getSemantics()));
-push_back(static_cast(llvm::APFloatBase::SemanticsToEnum(
-Value.getComplexFloatReal().getSemantics(;
-AddAPFloat(Value.getComplexFloatReal());
-AddAPFloat(Value.getComplexFloatImag());
-return;
-  }
-  case APValue::Vector:
-push_back(Value.getVectorLength());
-for (unsigned Idx = 0; Idx < Value.getVectorLength(); Idx++)
-  AddAPValue(Value.getVectorElt(Idx));
-return;
-  case APValue::Array:
-push_back(Value.getArrayInitializedElts());
-push_back(Value.getArraySize());
-for (unsigned Idx = 0; Idx < Value.getArrayInitializedElts(); Idx++)
-  AddAPValue(Value.getArrayInitializedElt(Idx));
-if (Value.hasArrayFiller())
-  AddAPValue(Value.getArrayFiller());
-return;
-  case APValue::Struct:
-push_back(Value.getStructNumBases());
-push_back(Value.getStructNumFields());
-for (unsigned Idx = 0; Idx < Value.getStructNumBases(); Idx++)
-  AddAPValue(Value.getStructBase(Idx));
-for (unsigned Idx = 0; Idx < Value.getStructNumFields(); Idx++)
-  AddAPValue(Value.getStructField(Idx));
-return;
-  case APValue::Union:
-AddDeclRef(Value.getUnionField());
-AddAPValue(Value.getUnionValue());
-return;
-  case APValue::AddrLabelDiff:
-AddStmt(const_cast(Value.getAddrLabelDiffLHS()));
-AddStmt(const_cast(Value.getAddrLabelDiffRHS()));
-return;
-  case APValue::MemberPointer: {
-push_back(Value.isMemberPointerToDerivedMember());
-AddDeclRef(Value.getMemberPointerDecl());
- 

[clang] 37e83bc - [NFC] Move readAPValue/writeAPValue up the inheritance hierarchy

[Varun Gandhi via cfe-commits]

Author: Varun Gandhi
Date: 2021-01-06T16:44:50-08:00
New Revision: 37e83bc6db3ad7d9a5d182694ebe71ebbc6120de

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

LOG: [NFC] Move readAPValue/writeAPValue up the inheritance hierarchy

The implementation for (de)serialization of APValues can be shared
between Clang and Swift, so we prefer pushing the methods up
the inheritance hierarchy, instead of having the methods live in
ASTReader/ASTWriter. Fixes rdar://72592937.

Reviewed By: rjmccall

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

Added: 


Modified: 
clang/include/clang/AST/APValue.h
clang/include/clang/AST/AbstractBasicReader.h
clang/include/clang/AST/AbstractBasicWriter.h
clang/include/clang/AST/PropertiesBase.td
clang/include/clang/Serialization/ASTRecordReader.h
clang/include/clang/Serialization/ASTRecordWriter.h
clang/include/clang/Serialization/ASTWriter.h
clang/lib/AST/APValue.cpp
clang/lib/Serialization/ASTReader.cpp
clang/lib/Serialization/ASTWriter.cpp
clang/utils/TableGen/ClangASTPropertiesEmitter.cpp

Removed: 




diff  --git a/clang/include/clang/AST/APValue.h 
b/clang/include/clang/AST/APValue.h
index eded34808ad7..f9b189926c76 100644
--- a/clang/include/clang/AST/APValue.h
+++ b/clang/include/clang/AST/APValue.h
@@ -23,6 +23,10 @@
 #include "llvm/Support/AlignOf.h"
 
 namespace clang {
+namespace serialization {
+template  class BasicReaderBase;
+} // end namespace serialization
+
   class AddrLabelExpr;
   class ASTContext;
   class CharUnits;
@@ -233,12 +237,20 @@ class APValue {
   return llvm::hash_value(A.Value);
 }
   };
+  class LValuePathSerializationHelper {
+const void *ElemTy;
+
+  public:
+ArrayRef Path;
+
+LValuePathSerializationHelper(ArrayRef, QualType);
+QualType getType();
+  };
   struct NoLValuePath {};
   struct UninitArray {};
   struct UninitStruct {};
 
-  friend class ASTRecordReader;
-  friend class ASTWriter;
+  template  friend class clang::serialization::BasicReaderBase;
   friend class ASTImporter;
   friend class ASTNodeImporter;
 

diff  --git a/clang/include/clang/AST/AbstractBasicReader.h 
b/clang/include/clang/AST/AbstractBasicReader.h
index d7b3a9da88ec..5505d661b44e 100644
--- a/clang/include/clang/AST/AbstractBasicReader.h
+++ b/clang/include/clang/AST/AbstractBasicReader.h
@@ -177,6 +177,40 @@ class DataStreamBasicReader : public BasicReaderBase 
{
 return llvm::APInt(bitWidth, numWords, [0]);
   }
 
+  llvm::FixedPointSemantics readFixedPointSemantics() {
+unsigned width = asImpl().readUInt32();
+unsigned scale = asImpl().readUInt32();
+unsigned tmp = asImpl().readUInt32();
+bool isSigned = tmp & 0x1;
+bool isSaturated = tmp & 0x2;
+bool hasUnsignedPadding = tmp & 0x4;
+return llvm::FixedPointSemantics(width, scale, isSigned, isSaturated,
+ hasUnsignedPadding);
+  }
+
+  APValue::LValuePathSerializationHelper readLValuePathSerializationHelper(
+  SmallVectorImpl ) {
+auto elemTy = asImpl().readQualType();
+unsigned pathLength = asImpl().readUInt32();
+for (unsigned i = 0; i < pathLength; ++i) {
+  if (elemTy->template getAs()) {
+unsigned int_ = asImpl().readUInt32();
+Decl *decl = asImpl().template readDeclAs();
+if (auto *recordDecl = dyn_cast(decl))
+  elemTy = getASTContext().getRecordType(recordDecl);
+else
+  elemTy = cast(decl)->getType();
+path.push_back(
+APValue::LValuePathEntry(APValue::BaseOrMemberType(decl, int_)));
+  } else {
+elemTy = getASTContext().getAsArrayType(elemTy)->getElementType();
+path.push_back(
+APValue::LValuePathEntry::ArrayIndex(asImpl().readUInt32()));
+  }
+}
+return APValue::LValuePathSerializationHelper(path, elemTy);
+  }
+
   Qualifiers readQualifiers() {
 static_assert(sizeof(Qualifiers().getAsOpaqueValue()) <= sizeof(uint32_t),
   "update this if the value size changes");

diff  --git a/clang/include/clang/AST/AbstractBasicWriter.h 
b/clang/include/clang/AST/AbstractBasicWriter.h
index 0a6730c86bbf..75aef734ba9b 100644
--- a/clang/include/clang/AST/AbstractBasicWriter.h
+++ b/clang/include/clang/AST/AbstractBasicWriter.h
@@ -9,6 +9,7 @@
 #ifndef CLANG_AST_ABSTRACTBASICWRITER_H
 #define CLANG_AST_ABSTRACTBASICWRITER_H
 
+#include "clang/AST/ASTContext.h"
 #include "clang/AST/DeclTemplate.h"
 
 namespace clang {
@@ -121,6 +122,7 @@ template 
 class DataStreamBasicWriter : public BasicWriterBase {
 protected:
   using BasicWriterBase::asImpl;
+  DataStreamBasicWriter(ASTContext ) : BasicWriterBase(ctx) {}
 
 public:
   /// Implement property-find by ignoring it.  We rely on properties being
@@ 

[PATCH] D93868: [analyzer] Update Fuchsia checker to catch when releasing unowned handles.

[Haowei Wu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG8deaec122ec6: [analyzer] Update Fuchsia checker to catch 
releasing unowned handles. (authored by Daniel Hwang ar...@google.com, 
committed by haowei).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93868

Files:
  clang/lib/StaticAnalyzer/Checkers/FuchsiaHandleChecker.cpp
  clang/test/Analysis/fuchsia_handle.cpp

Index: clang/test/Analysis/fuchsia_handle.cpp
===
--- clang/test/Analysis/fuchsia_handle.cpp
+++ clang/test/Analysis/fuchsia_handle.cpp
@@ -12,10 +12,12 @@
 #define ZX_HANDLE_ACQUIRE __attribute__((acquire_handle("Fuchsia")))
 #define ZX_HANDLE_RELEASE __attribute__((release_handle("Fuchsia")))
 #define ZX_HANDLE_USE __attribute__((use_handle("Fuchsia")))
+#define ZX_HANDLE_ACQUIRE_UNOWNED __attribute__((acquire_handle("FuchsiaUnowned")))
 #else
 #define ZX_HANDLE_ACQUIRE
 #define ZX_HANDLE_RELEASE
 #define ZX_HANDLE_USE
+#define ZX_HANDLE_ACQUIRE_UNOWNED
 #endif
 
 zx_status_t zx_channel_create(
@@ -26,6 +28,11 @@
 zx_status_t zx_handle_close(
 zx_handle_t handle ZX_HANDLE_RELEASE);
 
+ZX_HANDLE_ACQUIRE_UNOWNED
+zx_handle_t zx_process_self();
+
+void zx_process_self_param(zx_handle_t *out ZX_HANDLE_ACQUIRE_UNOWNED);
+
 ZX_HANDLE_ACQUIRE
 zx_handle_t return_handle();
 
@@ -45,6 +52,20 @@
   zx_handle_t operator+(zx_handle_t ZX_HANDLE_RELEASE replace);
 };
 
+void checkUnownedHandle01() {
+  zx_handle_t h0;
+  h0 = zx_process_self(); // expected-note {{Function 'zx_process_self' returns an unowned handle}}
+  zx_handle_close(h0);// expected-warning {{Releasing an unowned handle}}
+  // expected-note@-1 {{Releasing an unowned handle}}
+}
+
+void checkUnownedHandle02() {
+  zx_handle_t h0;
+  zx_process_self_param(); // expected-note {{Unowned handle allocated through 1st parameter}}
+  zx_handle_close(h0);// expected-warning {{Releasing an unowned handle}}
+  // expected-note@-1 {{Releasing an unowned handle}}
+}
+
 void checkInvalidHandle01() {
   zx_handle_t sa, sb;
   zx_channel_create(0, , );
Index: clang/lib/StaticAnalyzer/Checkers/FuchsiaHandleChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/FuchsiaHandleChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/FuchsiaHandleChecker.cpp
@@ -20,29 +20,39 @@
 // Art:
 //
 //
-//  +-+-v-+ ++
-//   acquire_func succeeded | | Escape  ||
-//+->  Allocated  +->  Escaped   <--+
-//| | | ||  |
-//| +-+--++ ++  |
-//|   |  |  |
-//| release_func  |  +--+   |
-//|   | | handle  ++|
-//|   | | dies|||
-//|  +v-+   +-> Leaked ||
-//|  |  | |(REPORT)||
-// +--+--+   | Released | Escape  ++|
-// | |   |  +---+
-// | Not tracked <--+++---+-+
-// | |  | |   |As argument by value
-// +--+--+  |release_func |   +--+ in function call
-//| | |  | or by reference in
-//| | |  | use_func call
-//+-++v-+| +---+
-//acquire_func failed| Double   |+-> Use after |
-//   | released |  | released  |
-//   | (REPORT) |  | (REPORT)  |
-//   +--+  +---+
+// +-+ ++
+//  acquire_func succeeded | | Escape  ||
+//   +->  Allocated  +->  Escaped   <--+
+//   | | | ||  |
+//   | +-+--++ ++  |
+//   |   |  |  |
+// acquire_func  | release_func  |  +--+   |
+//failed |   | | handle  ++|
+// +-+   |   | | dies|||
+// | |   |  

[clang] 8deaec1 - [analyzer] Update Fuchsia checker to catch releasing unowned handles.

[Haowei Wu via cfe-commits]

Author: Daniel Hwang
Date: 2021-01-06T16:23:49-08:00
New Revision: 8deaec122ec68746c53ec2afb893873124053d8d

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

LOG: [analyzer] Update Fuchsia checker to catch releasing unowned handles.

Certain Fuchsia functions may return handles that are not owned by the
current closure. This adds a check in order to determine when these
handles are released.

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

Added: 


Modified: 
clang/lib/StaticAnalyzer/Checkers/FuchsiaHandleChecker.cpp
clang/test/Analysis/fuchsia_handle.cpp

Removed: 




diff  --git a/clang/lib/StaticAnalyzer/Checkers/FuchsiaHandleChecker.cpp 
b/clang/lib/StaticAnalyzer/Checkers/FuchsiaHandleChecker.cpp
index c246a8db3067..e3f4be0726c8 100644
--- a/clang/lib/StaticAnalyzer/Checkers/FuchsiaHandleChecker.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/FuchsiaHandleChecker.cpp
@@ -20,29 +20,39 @@
 // Art:
 //
 //
-//  +-+-v-+ ++
-//   acquire_func succeeded | | Escape  ||
-//+->  Allocated  +->  Escaped   <--+
-//| | | ||  |
-//| +-+--++ ++  |
-//|   |  |  |
-//| release_func  |  +--+   |
-//|   | | handle  ++|
-//|   | | dies|||
-//|  +v-+   +-> Leaked ||
-//|  |  | |(REPORT)||
-// +--+--+   | Released | Escape  ++|
-// | |   |  +---+
-// | Not tracked <--+++---+-+
-// | |  | |   |As argument by value
-// +--+--+  |release_func |   +--+ in function call
-//| | |  | or by reference in
-//| | |  | use_func call
-//+-++v-+| +---+
-//acquire_func failed| Double   |+-> Use after |
-//   | released |  | released  |
-//   | (REPORT) |  | (REPORT)  |
-//   +--+  +---+
+// +-+ ++
+//  acquire_func succeeded | | Escape  ||
+//   +->  Allocated  +->  Escaped   <--+
+//   | | | ||  |
+//   | +-+--++ ++  |
+//   |   |  |  |
+// acquire_func  | release_func  |  +--+   |
+//failed |   | | handle  ++|
+// +-+   |   | | dies|||
+// | |   |  +v-+   +-> Leaked ||
+// | |   |  |  | |(REPORT)||
+// |  +--+--+   | Released | Escape  ++|
+// |  | |   |  +---+
+// +--> Not tracked |   ++---+-+
+//| ||   |As argument by value
+//+--+--+   release_func |   +--+ in function call
+//   |   |  | or by reference in
+//   |   |  | use_func call
+//unowned|  +v-+| +---+
+//  acquire_func |  | Double   |+-> Use after |
+//   succeeded   |  | released |  | released  |
+//   |  | (REPORT) |  | (REPORT)  |
+//+---+ +--+  +---+
+//| Allocated |
+//| Unowned   |  release_func
+//|   +-+
+//+---+ |
+//  |
+//+-v--+
+//| Release of |
+//| unowned handle |
+//| (REPORT)   |
+//++
 //
 // acquire_func represents the 

[PATCH] D93638: [hip] Enable HIP compilation with ` on MSVC.

[Artem Belevich via Phabricator via cfe-commits]

tra added inline comments.



Comment at: clang/lib/Headers/__clang_hip_runtime_wrapper.h:73-74
+#define __HOST_DEVICE__
\
+  static __host__ __device__ inline __attribute__((always_inline))
+__HOST_DEVICE__ double _Cosh(double x, double y) { return cosh(x) * y; }
+__HOST_DEVICE__ float _FCosh(float x, float y) { return coshf(x) * y; }

hliao wrote:
> tra wrote:
> > hliao wrote:
> > > tra wrote:
> > > > hliao wrote:
> > > > > tra wrote:
> > > > > > I don't think we want to provide a HD implementation.
> > > > > > This will potentially change the meaning of these functions on the 
> > > > > > host side vs what they do in a C++ compilation.
> > > > > > It should probably be just `__device__`.
> > > > > > 
> > > > > > Next question is -- do we want to provide the definitions, or would 
> > > > > > just declarations be sufficient?
> > > > > > In other words -- are these functions needed for some standard C++ 
> > > > > > library functionality that we expect to work on the GPU?
> > > > > > If it's just to aid with overload resolution, declarations should 
> > > > > > do. 
> > > > > > 
> > > > > These functions are declared in ymath.h and, in the host compilation, 
> > > > > are resolved by linking MSVC RT libraries. For the device function, 
> > > > > as we already mark all prototypes in ymath.h as HD, we have to 
> > > > > implement them as HD to match the declaration. But, those definitions 
> > > > > should be only available in the device compilation to avoid conflicts 
> > > > > in the host compilation.
> > > > You don't need the definitions to avoid conflicting declarations.
> > > > 
> > > > I'm still not convinced that HD is needed.
> > > > Did you try just making these declarations `__device__` and remove the 
> > > > `ymath.h` wrapper?
> > > > Basically I'm trying to find the bare minimum we need to do to make it 
> > > > work.
> > > We don't call these functions directly. They are called in MSVC's 
> > > . As functions in  are marked as HD, we need to mark 
> > > these functions in ymath.h as HD to pass the compilation.
> > I assume that we're dealing with this file:
> > https://github.com/microsoft/STL/blob/master/stl/inc/ymath.h
> > 
> > I don't think we need a wrapper for ymath.
> > It may be sufficient to define or declare  `__device__ _Cosh()` and other 
> > functions and let overload resolution pick the right function.
> > I think it would be a better approach than providing an `inline __host__ 
> > __device__` definition for those functions and effectively replacing 
> > MSVC-provided host-side implementation of those functions.
> > 
> `ymath.h` could be included before ``. That implies `_Cosh` could be 
> declared as H only and results in the compilation failure.
> BTW, I don't think replacing host-side implementation is a good idea as the 
> host compilation should be kept consistent with the host compiler as much as 
> possible.
How? Isn't __clang_hip_runtime_wrapper.h included before anything in the user 
source file is processed? If the __clang_hip_runtime_wrapper.h is not included, 
first, then the ymath.h wrapper will not work either as it needs `__device__` 
macros.

> replacing host-side implementation is a good idea 

While consistency between host/device is good, we should not introduce a 
possible inconsistency between host-side TUs.
Considering vastly larger amounts of host-side code compiled as C++ (e.g. TF 
has way more C++ code than HIP/CUDA) and correspondingly more [[ 
https://www.hyrumslaw.com/ | reliance on every possible detail of the 
implementation ]], I would err on the side of not changing host-side behavior 
in any way at all, if possible.

It's reasonably safe to add an overload (it may still be observable, but it's 
usually possible to add it in a way that does not affect the host). Replacing 
host-side things is more risky, as it greatly expands the opportunities for 
things to go wrong.





Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93638

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

[PATCH] D92270: [ConstantFold] Fold more operations to poison

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

To fix the old bug quite a few patches in LLVM have landed so far and it is 
still ongoing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92270

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

[PATCH] D92270: [ConstantFold] Fold more operations to poison

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

In D92270#2482741 , @thakis wrote:

> We bisected a test failure to this 
> (https://bugs.chromium.org/p/angleproject/issues/detail?id=5500#c17). Can you 
> expand a bit on what this patch means in practice? I'm guessing it makes UB 
> in C++ code have bad effects more often? If so, what type of UB?

This patch makes the result of erroneous operations in source to participate in 
constant folding in more eager manner.
BTW, I am aware that this patch interacts with existing old (but hard to fix) 
bug in LLVM and miscompiles codes in certain code that has conditional branch + 
shifts. https://bugs.llvm.org/show_bug.cgi?id=48353 has more context.
Do you think your bug is related to this bug report?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92270

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

[PATCH] D94201: [clang-format] Skip UTF8 Byte Order Mark

[Rafał Jelonek via Phabricator via cfe-commits]

rjelonek created this revision.
rjelonek added reviewers: rsmith, rnk.
rjelonek created this object with visibility "All Users".
rjelonek created this object with edit policy "Members of Project: clang".
rjelonek added a project: clang-format.
rjelonek requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

If file contain BOM then first instruction (include or clang-format off) is 
ignored


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D94201

Files:
  clang/lib/Format/Format.cpp
  clang/unittests/Format/SortIncludesTest.cpp


Index: clang/unittests/Format/SortIncludesTest.cpp
===
--- clang/unittests/Format/SortIncludesTest.cpp
+++ clang/unittests/Format/SortIncludesTest.cpp
@@ -879,6 +879,42 @@
  "#include \"a.h\""));
 }
 
+TEST_F(SortIncludesTest, skipUTF8ByteOrderMarkMerge) {
+  Style.IncludeBlocks = Style.IBS_Merge;
+  std::string Code = "\xEF\xBB\xBF#include \"d.h\"\r\n"
+ "#include \"b.h\"\r\n"
+ "\r\n"
+ "#include \"c.h\"\r\n"
+ "#include \"a.h\"\r\n"
+ "#include \"e.h\"\r\n";
+
+  std::string Expected = "\xEF\xBB\xBF#include \"e.h\"\r\n"
+ "#include \"a.h\"\r\n"
+ "#include \"b.h\"\r\n"
+ "#include \"c.h\"\r\n"
+ "#include \"d.h\"\r\n";
+
+  EXPECT_EQ(Expected, sort(Code, "e.cpp", 1));
+}
+
+TEST_F(SortIncludesTest, skipUTF8ByteOrderMarkPreserve) {
+  Style.IncludeBlocks = Style.IBS_Preserve;
+  std::string Code = "\xEF\xBB\xBF#include \"d.h\"\r\n"
+ "#include \"b.h\"\r\n"
+ "\r\n"
+ "#include \"c.h\"\r\n"
+ "#include \"a.h\"\r\n"
+ "#include \"e.h\"\r\n";
+
+  std::string Expected = "\xEF\xBB\xBF#include \"b.h\"\r\n"
+ "#include \"d.h\"\r\n"
+ "\r\n"
+ "#include \"a.h\"\r\n"
+ "#include \"c.h\"\r\n"
+ "#include \"e.h\"\r\n";
+
+  EXPECT_EQ(Expected, sort(Code, "e.cpp", 2));
+}
 } // end namespace
 } // end namespace format
 } // end namespace clang
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -2253,7 +2253,9 @@
   StringRef FileName,
   tooling::Replacements ,
   unsigned *Cursor) {
-  unsigned Prev = 0;
+  unsigned Prev = llvm::StringSwitch(Code)
+  .StartsWith("\xEF\xBB\xBF", 3) // UTF-8 BOM
+  .Default(0);
   unsigned SearchFrom = 0;
   llvm::Regex IncludeRegex(CppIncludeRegexPattern);
   SmallVector Matches;


Index: clang/unittests/Format/SortIncludesTest.cpp
===
--- clang/unittests/Format/SortIncludesTest.cpp
+++ clang/unittests/Format/SortIncludesTest.cpp
@@ -879,6 +879,42 @@
  "#include \"a.h\""));
 }
 
+TEST_F(SortIncludesTest, skipUTF8ByteOrderMarkMerge) {
+  Style.IncludeBlocks = Style.IBS_Merge;
+  std::string Code = "\xEF\xBB\xBF#include \"d.h\"\r\n"
+ "#include \"b.h\"\r\n"
+ "\r\n"
+ "#include \"c.h\"\r\n"
+ "#include \"a.h\"\r\n"
+ "#include \"e.h\"\r\n";
+
+  std::string Expected = "\xEF\xBB\xBF#include \"e.h\"\r\n"
+ "#include \"a.h\"\r\n"
+ "#include \"b.h\"\r\n"
+ "#include \"c.h\"\r\n"
+ "#include \"d.h\"\r\n";
+
+  EXPECT_EQ(Expected, sort(Code, "e.cpp", 1));
+}
+
+TEST_F(SortIncludesTest, skipUTF8ByteOrderMarkPreserve) {
+  Style.IncludeBlocks = Style.IBS_Preserve;
+  std::string Code = "\xEF\xBB\xBF#include \"d.h\"\r\n"
+ "#include \"b.h\"\r\n"
+ "\r\n"
+ "#include \"c.h\"\r\n"
+ "#include \"a.h\"\r\n"
+ "#include \"e.h\"\r\n";
+
+  std::string Expected = "\xEF\xBB\xBF#include \"b.h\"\r\n"
+ "#include \"d.h\"\r\n"
+ "\r\n"
+ "#include \"a.h\"\r\n"
+ "#include \"c.h\"\r\n"
+ "#include \"e.h\"\r\n";
+
+  EXPECT_EQ(Expected, sort(Code, "e.cpp", 2));
+}
 } // end namespace
 } // end namespace format
 } // end namespace clang
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -2253,7 +2253,9 @@
   StringRef 

[PATCH] D94039: [WebAssembly] Update WasmEHPrepare for the new spec

[Derek Schuff via Phabricator via cfe-commits]

dschuff added inline comments.



Comment at: llvm/lib/CodeGen/WasmEHPrepare.cpp:374-375
+  // be lowered to wasm 'catch' instruction. We do this mainly because
+  // instruction selection cannot handle wasm.get.exception intrinsic's token
+  // argument.
+  Instruction *CatchCI =

tlively wrote:
> What is the token argument used for? Could clang generate `llvm.wasm.catch` 
> directly?
Token arguments (https://llvm.org/docs/ExceptionHandling.html#wineh) are used 
to preserve the original scoping structure in mid-level optimization passes. I 
haven't looked at this intrinsic recently but I'd guess that maybe the token 
keeps it from getting moved out of its containing scope?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94039

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

[PATCH] D93095: Introduce -Wreserved-identifier

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

Quuxplusone added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:377
+  "%0 is a reserved identifier">,
+  InGroup, DefaultIgnore;
+

If you leave it like this, you //will// receive multiple bug reports per year 
about how in some contexts the compiler diagnoses `_X` and `_x` equally, and in 
other contexts the compiler diagnoses `_X` but fails to diagnose `_x`.

You should make two diagnostics: `-Wreserved-extern-identifier` and 
`-Wreserved-pp-identifier` (or something along those lines), and their messages 
should be carefully worded to explain //why// the warning is happening — 
"identifier %0 is reserved for use at file scope," "identifier %0 is reserved 
in all contexts," etc.

Btw, the reason some identifiers (like `_X`) are reserved in all contexts is so 
that the implementation can define them as macros (e.g. header guards).



Comment at: clang/test/Sema/reserved-identifier.c:9
+int _foo() { return 0; }// expected-warning {{'_foo' is a reserved 
identifier}}
+
+// This one is explicitly skipped by -Wreserved-identifier

aaron.ballman wrote:
> Can you add a test that we do not warn on an extern declaration? e.g.,
> ```
> extern char *_strdup(const char *);
> ```
> This is sometimes used (esp in older C code bases) to avoid having to include 
> an entire header to scrape one declaration out of it, and there are popular 
> libraries (like the MSVC CRT) that have APIs starting with a single 
> underscore and lowercase letter.
> 
> The idea here is: if it's an extern declaration, the identifier is "owned" by 
> some other declaration and this is not likely something the user has control 
> over.
Should that logic also apply to a forward declaration like `struct _foo;`? 
Should it apply to `struct _foo { int i; };`? These are also things the user 
might not have control over. (And they're equally things that the user 
//could// pull out into a separate .h file surrounded by disabled-warning 
pragmas, if they really wanted to.)


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

https://reviews.llvm.org/D93095

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

[PATCH] D93668: [clang] Add -ffuchsia-c++-abi flag to explicitly use the Fuchsia C++ ABI

[Petr Hosek via Phabricator via cfe-commits]

phosek added a comment.

In D93668#2482995 , @rnk wrote:

> I guess a triple of -fuchsia-itanium would be a reasonable way of expressing 
> this.
>
> Why would we want a feature flag for the wasm C++ ABI? Is there a use case 
> for using the webassembly C++ ABI on non-wasm ISAs?

We've been considering the use of WASM as a binary format in Fuchsia at which 
point we'd need to decide which C++ ABI to use in those cases. There are no 
concrete plans yet, but I want to make sure that whatever solution we come up 
with doesn't result in multiple new flags down the line.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93668

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

[PATCH] D94196: [NFC] Move readAPValue/writeAPValue up the inheritance hierarchy

[John McCall via Phabricator via cfe-commits]

rjmccall accepted this revision.
rjmccall 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/D94196/new/

https://reviews.llvm.org/D94196

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

[PATCH] D94196: [NFC] Move readAPValue/writeAPValue up the inheritance hierarchy

[Varun Gandhi via Phabricator via cfe-commits]

varungandhi-apple updated this revision to Diff 315005.
varungandhi-apple added a comment.

Appease clang-tidy.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94196

Files:
  clang/include/clang/AST/APValue.h
  clang/include/clang/AST/AbstractBasicReader.h
  clang/include/clang/AST/AbstractBasicWriter.h
  clang/include/clang/AST/PropertiesBase.td
  clang/include/clang/Serialization/ASTRecordReader.h
  clang/include/clang/Serialization/ASTRecordWriter.h
  clang/include/clang/Serialization/ASTWriter.h
  clang/lib/AST/APValue.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/utils/TableGen/ClangASTPropertiesEmitter.cpp

Index: clang/utils/TableGen/ClangASTPropertiesEmitter.cpp
===
--- clang/utils/TableGen/ClangASTPropertiesEmitter.cpp
+++ clang/utils/TableGen/ClangASTPropertiesEmitter.cpp
@@ -708,15 +708,13 @@
   // Emit the Basic{Reader,Writer}Base template.
   Out << "template \n"
  "class Basic" << info.ClassSuffix << "Base {\n";
-  if (info.IsReader)
-Out << "  ASTContext \n";
+  Out << "  ASTContext \n";
   Out << "protected:\n"
- "  Basic" << info.ClassSuffix << "Base"
-   << (info.IsReader ? "(ASTContext ) : C(ctx)" : "()")
-   << " {}\n"
+ "  Basic"
+  << info.ClassSuffix << "Base" << ("(ASTContext ) : C(ctx)")
+  << " {}\n"
  "public:\n";
-  if (info.IsReader)
-Out << "  ASTContext () { return C; }\n";
+  Out << "  ASTContext () { return C; }\n";
   Out << "  Impl () { return static_cast(*this); }\n";
 
   auto enterReaderWriterMethod = [&](StringRef cxxTypeName,
Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -5121,144 +5121,6 @@
   AddAPInt(Value.bitcastToAPInt());
 }
 
-static void WriteFixedPointSemantics(ASTRecordWriter ,
- llvm::FixedPointSemantics FPSema) {
-  Record.push_back(FPSema.getWidth());
-  Record.push_back(FPSema.getScale());
-  Record.push_back(FPSema.isSigned() | FPSema.isSaturated() << 1 |
-   FPSema.hasUnsignedPadding() << 2);
-}
-
-void ASTRecordWriter::AddAPValue(const APValue ) {
-  APValue::ValueKind Kind = Value.getKind();
-  push_back(static_cast(Kind));
-  switch (Kind) {
-  case APValue::None:
-  case APValue::Indeterminate:
-return;
-  case APValue::Int:
-AddAPSInt(Value.getInt());
-return;
-  case APValue::Float:
-push_back(static_cast(
-llvm::APFloatBase::SemanticsToEnum(Value.getFloat().getSemantics(;
-AddAPFloat(Value.getFloat());
-return;
-  case APValue::FixedPoint: {
-WriteFixedPointSemantics(*this, Value.getFixedPoint().getSemantics());
-AddAPSInt(Value.getFixedPoint().getValue());
-return;
-  }
-  case APValue::ComplexInt: {
-AddAPSInt(Value.getComplexIntReal());
-AddAPSInt(Value.getComplexIntImag());
-return;
-  }
-  case APValue::ComplexFloat: {
-assert(llvm::APFloatBase::SemanticsToEnum(
-   Value.getComplexFloatImag().getSemantics()) ==
-   llvm::APFloatBase::SemanticsToEnum(
-   Value.getComplexFloatReal().getSemantics()));
-push_back(static_cast(llvm::APFloatBase::SemanticsToEnum(
-Value.getComplexFloatReal().getSemantics(;
-AddAPFloat(Value.getComplexFloatReal());
-AddAPFloat(Value.getComplexFloatImag());
-return;
-  }
-  case APValue::Vector:
-push_back(Value.getVectorLength());
-for (unsigned Idx = 0; Idx < Value.getVectorLength(); Idx++)
-  AddAPValue(Value.getVectorElt(Idx));
-return;
-  case APValue::Array:
-push_back(Value.getArrayInitializedElts());
-push_back(Value.getArraySize());
-for (unsigned Idx = 0; Idx < Value.getArrayInitializedElts(); Idx++)
-  AddAPValue(Value.getArrayInitializedElt(Idx));
-if (Value.hasArrayFiller())
-  AddAPValue(Value.getArrayFiller());
-return;
-  case APValue::Struct:
-push_back(Value.getStructNumBases());
-push_back(Value.getStructNumFields());
-for (unsigned Idx = 0; Idx < Value.getStructNumBases(); Idx++)
-  AddAPValue(Value.getStructBase(Idx));
-for (unsigned Idx = 0; Idx < Value.getStructNumFields(); Idx++)
-  AddAPValue(Value.getStructField(Idx));
-return;
-  case APValue::Union:
-AddDeclRef(Value.getUnionField());
-AddAPValue(Value.getUnionValue());
-return;
-  case APValue::AddrLabelDiff:
-AddStmt(const_cast(Value.getAddrLabelDiffLHS()));
-AddStmt(const_cast(Value.getAddrLabelDiffRHS()));
-return;
-  case APValue::MemberPointer: {
-push_back(Value.isMemberPointerToDerivedMember());
-AddDeclRef(Value.getMemberPointerDecl());
-ArrayRef RecordPath = Value.getMemberPointerPath();
-push_back(RecordPath.size());
-  

[PATCH] D93638: [hip] Enable HIP compilation with ` on MSVC.

[Michael Liao via Phabricator via cfe-commits]

hliao added inline comments.



Comment at: clang/lib/Headers/__clang_hip_runtime_wrapper.h:73-74
+#define __HOST_DEVICE__
\
+  static __host__ __device__ inline __attribute__((always_inline))
+__HOST_DEVICE__ double _Cosh(double x, double y) { return cosh(x) * y; }
+__HOST_DEVICE__ float _FCosh(float x, float y) { return coshf(x) * y; }

tra wrote:
> hliao wrote:
> > tra wrote:
> > > hliao wrote:
> > > > tra wrote:
> > > > > I don't think we want to provide a HD implementation.
> > > > > This will potentially change the meaning of these functions on the 
> > > > > host side vs what they do in a C++ compilation.
> > > > > It should probably be just `__device__`.
> > > > > 
> > > > > Next question is -- do we want to provide the definitions, or would 
> > > > > just declarations be sufficient?
> > > > > In other words -- are these functions needed for some standard C++ 
> > > > > library functionality that we expect to work on the GPU?
> > > > > If it's just to aid with overload resolution, declarations should do. 
> > > > > 
> > > > These functions are declared in ymath.h and, in the host compilation, 
> > > > are resolved by linking MSVC RT libraries. For the device function, as 
> > > > we already mark all prototypes in ymath.h as HD, we have to implement 
> > > > them as HD to match the declaration. But, those definitions should be 
> > > > only available in the device compilation to avoid conflicts in the host 
> > > > compilation.
> > > You don't need the definitions to avoid conflicting declarations.
> > > 
> > > I'm still not convinced that HD is needed.
> > > Did you try just making these declarations `__device__` and remove the 
> > > `ymath.h` wrapper?
> > > Basically I'm trying to find the bare minimum we need to do to make it 
> > > work.
> > We don't call these functions directly. They are called in MSVC's 
> > . As functions in  are marked as HD, we need to mark 
> > these functions in ymath.h as HD to pass the compilation.
> I assume that we're dealing with this file:
> https://github.com/microsoft/STL/blob/master/stl/inc/ymath.h
> 
> I don't think we need a wrapper for ymath.
> It may be sufficient to define or declare  `__device__ _Cosh()` and other 
> functions and let overload resolution pick the right function.
> I think it would be a better approach than providing an `inline __host__ 
> __device__` definition for those functions and effectively replacing 
> MSVC-provided host-side implementation of those functions.
> 
`ymath.h` could be included before ``. That implies `_Cosh` could be 
declared as H only and results in the compilation failure.
BTW, I don't think replacing host-side implementation is a good idea as the 
host compilation should be kept consistent with the host compiler as much as 
possible.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93638

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

[PATCH] D94196: [NFC] Move readAPValue/writeAPValue up the inheritance hierarchy

[Varun Gandhi via Phabricator via cfe-commits]

varungandhi-apple created this revision.
varungandhi-apple added a reviewer: rjmccall.
varungandhi-apple requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

The implementation for (de)serialization of APValues can be shared
between Clang and Swift, so we prefer pushing the methods up
the inheritance hierarchy, instead of having the methods live in
ASTReader/ASTWriter. Fixes rdar://72592937.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D94196

Files:
  clang/include/clang/AST/APValue.h
  clang/include/clang/AST/AbstractBasicReader.h
  clang/include/clang/AST/AbstractBasicWriter.h
  clang/include/clang/AST/PropertiesBase.td
  clang/include/clang/Serialization/ASTRecordReader.h
  clang/include/clang/Serialization/ASTRecordWriter.h
  clang/include/clang/Serialization/ASTWriter.h
  clang/lib/AST/APValue.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/utils/TableGen/ClangASTPropertiesEmitter.cpp

Index: clang/utils/TableGen/ClangASTPropertiesEmitter.cpp
===
--- clang/utils/TableGen/ClangASTPropertiesEmitter.cpp
+++ clang/utils/TableGen/ClangASTPropertiesEmitter.cpp
@@ -708,15 +708,13 @@
   // Emit the Basic{Reader,Writer}Base template.
   Out << "template \n"
  "class Basic" << info.ClassSuffix << "Base {\n";
-  if (info.IsReader)
-Out << "  ASTContext \n";
+  Out << "  ASTContext \n";
   Out << "protected:\n"
- "  Basic" << info.ClassSuffix << "Base"
-   << (info.IsReader ? "(ASTContext ) : C(ctx)" : "()")
-   << " {}\n"
+ "  Basic"
+  << info.ClassSuffix << "Base" << ("(ASTContext ) : C(ctx)")
+  << " {}\n"
  "public:\n";
-  if (info.IsReader)
-Out << "  ASTContext () { return C; }\n";
+  Out << "  ASTContext () { return C; }\n";
   Out << "  Impl () { return static_cast(*this); }\n";
 
   auto enterReaderWriterMethod = [&](StringRef cxxTypeName,
Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -5121,144 +5121,6 @@
   AddAPInt(Value.bitcastToAPInt());
 }
 
-static void WriteFixedPointSemantics(ASTRecordWriter ,
- llvm::FixedPointSemantics FPSema) {
-  Record.push_back(FPSema.getWidth());
-  Record.push_back(FPSema.getScale());
-  Record.push_back(FPSema.isSigned() | FPSema.isSaturated() << 1 |
-   FPSema.hasUnsignedPadding() << 2);
-}
-
-void ASTRecordWriter::AddAPValue(const APValue ) {
-  APValue::ValueKind Kind = Value.getKind();
-  push_back(static_cast(Kind));
-  switch (Kind) {
-  case APValue::None:
-  case APValue::Indeterminate:
-return;
-  case APValue::Int:
-AddAPSInt(Value.getInt());
-return;
-  case APValue::Float:
-push_back(static_cast(
-llvm::APFloatBase::SemanticsToEnum(Value.getFloat().getSemantics(;
-AddAPFloat(Value.getFloat());
-return;
-  case APValue::FixedPoint: {
-WriteFixedPointSemantics(*this, Value.getFixedPoint().getSemantics());
-AddAPSInt(Value.getFixedPoint().getValue());
-return;
-  }
-  case APValue::ComplexInt: {
-AddAPSInt(Value.getComplexIntReal());
-AddAPSInt(Value.getComplexIntImag());
-return;
-  }
-  case APValue::ComplexFloat: {
-assert(llvm::APFloatBase::SemanticsToEnum(
-   Value.getComplexFloatImag().getSemantics()) ==
-   llvm::APFloatBase::SemanticsToEnum(
-   Value.getComplexFloatReal().getSemantics()));
-push_back(static_cast(llvm::APFloatBase::SemanticsToEnum(
-Value.getComplexFloatReal().getSemantics(;
-AddAPFloat(Value.getComplexFloatReal());
-AddAPFloat(Value.getComplexFloatImag());
-return;
-  }
-  case APValue::Vector:
-push_back(Value.getVectorLength());
-for (unsigned Idx = 0; Idx < Value.getVectorLength(); Idx++)
-  AddAPValue(Value.getVectorElt(Idx));
-return;
-  case APValue::Array:
-push_back(Value.getArrayInitializedElts());
-push_back(Value.getArraySize());
-for (unsigned Idx = 0; Idx < Value.getArrayInitializedElts(); Idx++)
-  AddAPValue(Value.getArrayInitializedElt(Idx));
-if (Value.hasArrayFiller())
-  AddAPValue(Value.getArrayFiller());
-return;
-  case APValue::Struct:
-push_back(Value.getStructNumBases());
-push_back(Value.getStructNumFields());
-for (unsigned Idx = 0; Idx < Value.getStructNumBases(); Idx++)
-  AddAPValue(Value.getStructBase(Idx));
-for (unsigned Idx = 0; Idx < Value.getStructNumFields(); Idx++)
-  AddAPValue(Value.getStructField(Idx));
-return;
-  case APValue::Union:
-AddDeclRef(Value.getUnionField());
-AddAPValue(Value.getUnionValue());
-return;
-  case APValue::AddrLabelDiff:
-AddStmt(const_cast(Value.getAddrLabelDiffLHS()));
-

[PATCH] D93638: [hip] Enable HIP compilation with ` on MSVC.

[Artem Belevich via Phabricator via cfe-commits]

tra added inline comments.



Comment at: clang/lib/Headers/__clang_hip_runtime_wrapper.h:73-74
+#define __HOST_DEVICE__
\
+  static __host__ __device__ inline __attribute__((always_inline))
+__HOST_DEVICE__ double _Cosh(double x, double y) { return cosh(x) * y; }
+__HOST_DEVICE__ float _FCosh(float x, float y) { return coshf(x) * y; }

hliao wrote:
> tra wrote:
> > hliao wrote:
> > > tra wrote:
> > > > I don't think we want to provide a HD implementation.
> > > > This will potentially change the meaning of these functions on the host 
> > > > side vs what they do in a C++ compilation.
> > > > It should probably be just `__device__`.
> > > > 
> > > > Next question is -- do we want to provide the definitions, or would 
> > > > just declarations be sufficient?
> > > > In other words -- are these functions needed for some standard C++ 
> > > > library functionality that we expect to work on the GPU?
> > > > If it's just to aid with overload resolution, declarations should do. 
> > > > 
> > > These functions are declared in ymath.h and, in the host compilation, are 
> > > resolved by linking MSVC RT libraries. For the device function, as we 
> > > already mark all prototypes in ymath.h as HD, we have to implement them 
> > > as HD to match the declaration. But, those definitions should be only 
> > > available in the device compilation to avoid conflicts in the host 
> > > compilation.
> > You don't need the definitions to avoid conflicting declarations.
> > 
> > I'm still not convinced that HD is needed.
> > Did you try just making these declarations `__device__` and remove the 
> > `ymath.h` wrapper?
> > Basically I'm trying to find the bare minimum we need to do to make it work.
> We don't call these functions directly. They are called in MSVC's . 
> As functions in  are marked as HD, we need to mark these functions 
> in ymath.h as HD to pass the compilation.
I assume that we're dealing with this file:
https://github.com/microsoft/STL/blob/master/stl/inc/ymath.h

I don't think we need a wrapper for ymath.
It may be sufficient to define or declare  `__device__ _Cosh()` and other 
functions and let overload resolution pick the right function.
I think it would be a better approach than providing an `inline __host__ 
__device__` definition for those functions and effectively replacing 
MSVC-provided host-side implementation of those functions.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93638

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

[PATCH] D89031: [SVE] Add support to vectorize_width loop pragma for scalable vectors

[Sander de Smalen via Phabricator via cfe-commits]

sdesmalen added inline comments.



Comment at: clang/docs/LanguageExtensions.rst:3034
+integer and the type of vectorization can be specified with an optional
+second parameter. In this case 'fixed' is the default and refers to fixed width
+vectorization, whereas 'scalable' indicates the compiler should use scalable

nit: s/In this case//



Comment at: clang/docs/LanguageExtensions.rst:3036
+vectorization, whereas 'scalable' indicates the compiler should use scalable
+vectors instead. In another variation of ``vectorize_width(fixed|scalable)``
+the user can hint at the type of vectorization to use without specifying

nit: Another use of vectorize_width is



Comment at: clang/docs/LanguageExtensions.rst:3038-3040
+the exact width. In both variants of the pragma if the target does not support
+scalable vectors then the vectorizer may decide to fall back on fixed width
+vectorization as the most profitable option.

nit: In both variants of the pragma the vectorizer may decide to fall back on 
fixed width vectorization if the target does not support scalable vectors.



Comment at: clang/include/clang/Basic/DiagnosticParseKinds.td:1390
+def err_pragma_loop_invalid_vectorize_option : Error<
+  "vectorize_width loop hint malformed; use vectorize_width(X, 'fixed' or 
'scalable') "
+  "where X is an integer, or vectorize_width('fixed' or 'scalable')">;

`use vectorize_width(X, fixed) or vectorize_width(X, scalable)`
(it may otherwise lead to confusion whether fixed/scalable needs quotes, same 
below)



Comment at: clang/lib/AST/AttrImpl.cpp:46
+  else if (state == FixedWidth || state == ScalableWidth) {
+value->printPretty(OS, nullptr, Policy);
+if (state == ScalableWidth)

is there always a value, even when "vectorize_width(scalable)" is specified?



Comment at: clang/lib/CodeGen/CGLoopInfo.cpp:751-753
+  // they effectively want vectorization disabled. We leave the
+  // scalable flag unspecified in this case to avoid setting the
+  // vectorize.enable flag later on.

is that not something to fix in the code that conditionally sets 
vectorize.enable later on instead of working around it here?


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

https://reviews.llvm.org/D89031

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

[PATCH] D93587: [hip] Fix HIP version parsing.

[Michael Liao via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG2a29ce303451: [hip] Fix HIP version parsing. (authored by 
hliao).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93587

Files:
  clang/lib/Driver/ToolChains/AMDGPU.cpp
  clang/lib/Driver/ToolChains/ROCm.h
  clang/test/Driver/Inputs/rocm/bin/.hipVersion


Index: clang/test/Driver/Inputs/rocm/bin/.hipVersion
===
--- clang/test/Driver/Inputs/rocm/bin/.hipVersion
+++ clang/test/Driver/Inputs/rocm/bin/.hipVersion
@@ -1,4 +1,6 @@
 # Auto-generated by cmake
-HIP_VERSION_MAJOR=3
+# NOTE: The trailing whitespace is added on purpose to verify that these
+# whitespaces are trimmed before paring.
+HIP_VERSION_MAJOR=3 
 HIP_VERSION_MINOR=6
 HIP_VERSION_PATCH=20214-a2917cd
Index: clang/lib/Driver/ToolChains/ROCm.h
===
--- clang/lib/Driver/ToolChains/ROCm.h
+++ clang/lib/Driver/ToolChains/ROCm.h
@@ -103,7 +103,7 @@
   }
 
   void scanLibDevicePath(llvm::StringRef Path);
-  void ParseHIPVersionFile(llvm::StringRef V);
+  bool parseHIPVersionFile(llvm::StringRef V);
   SmallVector getInstallationPathCandidates();
 
 public:
Index: clang/lib/Driver/ToolChains/AMDGPU.cpp
===
--- clang/lib/Driver/ToolChains/AMDGPU.cpp
+++ clang/lib/Driver/ToolChains/AMDGPU.cpp
@@ -88,23 +88,30 @@
   }
 }
 
-void RocmInstallationDetector::ParseHIPVersionFile(llvm::StringRef V) {
+// Parse and extract version numbers from `.hipVersion`. Return `true` if
+// the parsing fails.
+bool RocmInstallationDetector::parseHIPVersionFile(llvm::StringRef V) {
   SmallVector VersionParts;
   V.split(VersionParts, '\n');
-  unsigned Major;
-  unsigned Minor;
+  unsigned Major = ~0U;
+  unsigned Minor = ~0U;
   for (auto Part : VersionParts) {
-auto Splits = Part.split('=');
-if (Splits.first == "HIP_VERSION_MAJOR")
-  Splits.second.getAsInteger(0, Major);
-else if (Splits.first == "HIP_VERSION_MINOR")
-  Splits.second.getAsInteger(0, Minor);
-else if (Splits.first == "HIP_VERSION_PATCH")
+auto Splits = Part.rtrim().split('=');
+if (Splits.first == "HIP_VERSION_MAJOR") {
+  if (Splits.second.getAsInteger(0, Major))
+return true;
+} else if (Splits.first == "HIP_VERSION_MINOR") {
+  if (Splits.second.getAsInteger(0, Minor))
+return true;
+} else if (Splits.first == "HIP_VERSION_PATCH")
   VersionPatch = Splits.second.str();
   }
+  if (Major == ~0U || Minor == ~0U)
+return true;
   VersionMajorMinor = llvm::VersionTuple(Major, Minor);
   DetectedVersion =
   (Twine(Major) + "." + Twine(Minor) + "." + VersionPatch).str();
+  return false;
 }
 
 // For candidate specified by --rocm-path we do not do strict check.
@@ -290,7 +297,8 @@
   continue;
 
 if (HIPVersionArg.empty() && VersionFile)
-  ParseHIPVersionFile((*VersionFile)->getBuffer());
+  if (parseHIPVersionFile((*VersionFile)->getBuffer()))
+continue;
 
 HasHIPRuntime = true;
 return;


Index: clang/test/Driver/Inputs/rocm/bin/.hipVersion
===
--- clang/test/Driver/Inputs/rocm/bin/.hipVersion
+++ clang/test/Driver/Inputs/rocm/bin/.hipVersion
@@ -1,4 +1,6 @@
 # Auto-generated by cmake
-HIP_VERSION_MAJOR=3
+# NOTE: The trailing whitespace is added on purpose to verify that these
+# whitespaces are trimmed before paring.
+HIP_VERSION_MAJOR=3 
 HIP_VERSION_MINOR=6
 HIP_VERSION_PATCH=20214-a2917cd
Index: clang/lib/Driver/ToolChains/ROCm.h
===
--- clang/lib/Driver/ToolChains/ROCm.h
+++ clang/lib/Driver/ToolChains/ROCm.h
@@ -103,7 +103,7 @@
   }
 
   void scanLibDevicePath(llvm::StringRef Path);
-  void ParseHIPVersionFile(llvm::StringRef V);
+  bool parseHIPVersionFile(llvm::StringRef V);
   SmallVector getInstallationPathCandidates();
 
 public:
Index: clang/lib/Driver/ToolChains/AMDGPU.cpp
===
--- clang/lib/Driver/ToolChains/AMDGPU.cpp
+++ clang/lib/Driver/ToolChains/AMDGPU.cpp
@@ -88,23 +88,30 @@
   }
 }
 
-void RocmInstallationDetector::ParseHIPVersionFile(llvm::StringRef V) {
+// Parse and extract version numbers from `.hipVersion`. Return `true` if
+// the parsing fails.
+bool RocmInstallationDetector::parseHIPVersionFile(llvm::StringRef V) {
   SmallVector VersionParts;
   V.split(VersionParts, '\n');
-  unsigned Major;
-  unsigned Minor;
+  unsigned Major = ~0U;
+  unsigned Minor = ~0U;
   for (auto Part : VersionParts) {
-auto Splits = Part.split('=');
-if (Splits.first == "HIP_VERSION_MAJOR")
-  Splits.second.getAsInteger(0, Major);
-else if (Splits.first == "HIP_VERSION_MINOR")
-  Splits.second.getAsInteger(0, Minor);
-

[clang] 2a29ce3 - [hip] Fix HIP version parsing.

[Michael Liao via cfe-commits]

Author: Michael Liao
Date: 2021-01-06T17:00:14-05:00
New Revision: 2a29ce303451375bbf1de7c971296553ef5d9beb

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

LOG: [hip] Fix HIP version parsing.

- Need trimming before parsing major or minor version numbers. This's required
  due to the different line ending on Windows.
- In addition, the integer conversion may fail due to invalid char. Return that
  parsing function return `true` when the parsing fails.

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/AMDGPU.cpp
clang/lib/Driver/ToolChains/ROCm.h
clang/test/Driver/Inputs/rocm/bin/.hipVersion

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/AMDGPU.cpp 
b/clang/lib/Driver/ToolChains/AMDGPU.cpp
index 565a77e07fd8..0971a2da62a3 100644
--- a/clang/lib/Driver/ToolChains/AMDGPU.cpp
+++ b/clang/lib/Driver/ToolChains/AMDGPU.cpp
@@ -88,23 +88,30 @@ void 
RocmInstallationDetector::scanLibDevicePath(llvm::StringRef Path) {
   }
 }
 
-void RocmInstallationDetector::ParseHIPVersionFile(llvm::StringRef V) {
+// Parse and extract version numbers from `.hipVersion`. Return `true` if
+// the parsing fails.
+bool RocmInstallationDetector::parseHIPVersionFile(llvm::StringRef V) {
   SmallVector VersionParts;
   V.split(VersionParts, '\n');
-  unsigned Major;
-  unsigned Minor;
+  unsigned Major = ~0U;
+  unsigned Minor = ~0U;
   for (auto Part : VersionParts) {
-auto Splits = Part.split('=');
-if (Splits.first == "HIP_VERSION_MAJOR")
-  Splits.second.getAsInteger(0, Major);
-else if (Splits.first == "HIP_VERSION_MINOR")
-  Splits.second.getAsInteger(0, Minor);
-else if (Splits.first == "HIP_VERSION_PATCH")
+auto Splits = Part.rtrim().split('=');
+if (Splits.first == "HIP_VERSION_MAJOR") {
+  if (Splits.second.getAsInteger(0, Major))
+return true;
+} else if (Splits.first == "HIP_VERSION_MINOR") {
+  if (Splits.second.getAsInteger(0, Minor))
+return true;
+} else if (Splits.first == "HIP_VERSION_PATCH")
   VersionPatch = Splits.second.str();
   }
+  if (Major == ~0U || Minor == ~0U)
+return true;
   VersionMajorMinor = llvm::VersionTuple(Major, Minor);
   DetectedVersion =
   (Twine(Major) + "." + Twine(Minor) + "." + VersionPatch).str();
+  return false;
 }
 
 // For candidate specified by --rocm-path we do not do strict check.
@@ -290,7 +297,8 @@ void RocmInstallationDetector::detectHIPRuntime() {
   continue;
 
 if (HIPVersionArg.empty() && VersionFile)
-  ParseHIPVersionFile((*VersionFile)->getBuffer());
+  if (parseHIPVersionFile((*VersionFile)->getBuffer()))
+continue;
 
 HasHIPRuntime = true;
 return;

diff  --git a/clang/lib/Driver/ToolChains/ROCm.h 
b/clang/lib/Driver/ToolChains/ROCm.h
index 27c7d8b0ee54..21e62a465d7b 100644
--- a/clang/lib/Driver/ToolChains/ROCm.h
+++ b/clang/lib/Driver/ToolChains/ROCm.h
@@ -103,7 +103,7 @@ class RocmInstallationDetector {
   }
 
   void scanLibDevicePath(llvm::StringRef Path);
-  void ParseHIPVersionFile(llvm::StringRef V);
+  bool parseHIPVersionFile(llvm::StringRef V);
   SmallVector getInstallationPathCandidates();
 
 public:

diff  --git a/clang/test/Driver/Inputs/rocm/bin/.hipVersion 
b/clang/test/Driver/Inputs/rocm/bin/.hipVersion
index 48ee6f10c3e4..677293c09139 100644
--- a/clang/test/Driver/Inputs/rocm/bin/.hipVersion
+++ b/clang/test/Driver/Inputs/rocm/bin/.hipVersion
@@ -1,4 +1,6 @@
 # Auto-generated by cmake
-HIP_VERSION_MAJOR=3
+# NOTE: The trailing whitespace is added on purpose to verify that these
+# whitespaces are trimmed before paring.
+HIP_VERSION_MAJOR=3 
 HIP_VERSION_MINOR=6
 HIP_VERSION_PATCH=20214-a2917cd



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

[PATCH] D93638: [hip] Enable HIP compilation with ` on MSVC.

[Michael Liao via Phabricator via cfe-commits]

hliao added inline comments.



Comment at: clang/lib/Headers/__clang_hip_runtime_wrapper.h:73-74
+#define __HOST_DEVICE__
\
+  static __host__ __device__ inline __attribute__((always_inline))
+__HOST_DEVICE__ double _Cosh(double x, double y) { return cosh(x) * y; }
+__HOST_DEVICE__ float _FCosh(float x, float y) { return coshf(x) * y; }

tra wrote:
> hliao wrote:
> > tra wrote:
> > > I don't think we want to provide a HD implementation.
> > > This will potentially change the meaning of these functions on the host 
> > > side vs what they do in a C++ compilation.
> > > It should probably be just `__device__`.
> > > 
> > > Next question is -- do we want to provide the definitions, or would just 
> > > declarations be sufficient?
> > > In other words -- are these functions needed for some standard C++ 
> > > library functionality that we expect to work on the GPU?
> > > If it's just to aid with overload resolution, declarations should do. 
> > > 
> > These functions are declared in ymath.h and, in the host compilation, are 
> > resolved by linking MSVC RT libraries. For the device function, as we 
> > already mark all prototypes in ymath.h as HD, we have to implement them as 
> > HD to match the declaration. But, those definitions should be only 
> > available in the device compilation to avoid conflicts in the host 
> > compilation.
> You don't need the definitions to avoid conflicting declarations.
> 
> I'm still not convinced that HD is needed.
> Did you try just making these declarations `__device__` and remove the 
> `ymath.h` wrapper?
> Basically I'm trying to find the bare minimum we need to do to make it work.
We don't call these functions directly. They are called in MSVC's . As 
functions in  are marked as HD, we need to mark these functions in 
ymath.h as HD to pass the compilation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93638

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

[PATCH] D93668: [clang] Add -ffuchsia-c++-abi flag to explicitly use the Fuchsia C++ ABI

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

I guess a triple of -fuchsia-itanium would be a reasonable way of expressing 
this.

Why would we want a feature flag for the wasm C++ ABI? Is there a use case for 
using the webassembly C++ ABI on non-wasm ISAs?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93668

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

[PATCH] D93668: [clang] Add -ffuchsia-c++-abi flag to explicitly use the Fuchsia C++ ABI

[Petr Hosek via Phabricator via cfe-commits]

phosek added a comment.

I'd prefer to use the target triple rather than introducing a custom flag.

With dedicated flags, you might eventually end up in a similar situation as 
D85802 , that is in the extreme case you might 
end up with `-f[no-]fuchsia-c++-abi`, `-f[no-]webassembly-c++-abi`, etc. which 
is not any better than `-fc++-abi=`.

With target triple, I can imagine using either `-unknown-fuchsia-itanium` 
or `-unknown-fuchsia-gnu`, where the former would mean targeting Fuchsia 
with Itanium C++ ABI while the latter would mean using GCC compatible ABI 
(which would imply Itanium C++ ABI). Both of these are already used by MinGW 
for the same purpose so there's a precedent and we don't need to invent 
anything new.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93668

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

[PATCH] D87702: [Frontend] Add pragma align natural and sort out pragma pack stack effect

[Xiangling Liao via Phabricator via cfe-commits]

Xiangling_L marked 9 inline comments as done.
Xiangling_L added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:893
+def warn_pragma_pack_identifer_not_supported : Warning<
+  "specifying an identifier within pragma pack is not supported, identifier is 
ignored">,
+  InGroup;

aaron.ballman wrote:
> If the user wrote an identifier, it seems like there's a strong chance that 
> ignoring the identifier will result in incorrect behavior that would lead to 
> hard-to-find ODR issues. Should this scenario be an error rather than a 
> warning where the identifier is ignored?
Could you show a more concrete example or give more details on how possible 
incorrect behavior would lead to hard-to-find ODR issues?



Comment at: clang/include/clang/Sema/Sema.h:486
+: PackAttr(true), AlignMode(M), PackNumber(Num), XLStack(IsXL) {
+  assert(Num == PackNumber && "Unexpected value.");
+}

aaron.ballman wrote:
> The string literal here doesn't really convey what's being asserted -- it 
> took me a while to figure out that this is trying to catch truncation issues 
> when `Num` cannot be represented by an `unsigned char`.
Sorry for that, I would make it clearer.



Comment at: clang/include/clang/Sema/Sema.h:512
+static AlignPackInfo getFromRawEncoding(unsigned Encoding) {
+  static_assert(sizeof(AlignPackInfo) == sizeof(uint32_t),
+"Size is not correct");

aaron.ballman wrote:
> I would feel more comfortable with this assertion if the class was using 
> bit-fields to pack the values together. As it stands, we're kind of hoping 
> that `bool`, `Mode`, and `unsigned char` will all pack in a particular way 
> (and `bool`'s representation is implementation-defined).
Yeah, good point. I will move it back to previous bitfields version.



Comment at: clang/include/clang/Sema/Sema.h:527
+
+unsigned char getPackNumber() const { return PackNumber; }
+

aaron.ballman wrote:
> Given that the ctor takes an `int` for this value, should this be returning 
> an `int`?
As we know the pack number would not exceed 16 bytes, so the intention of using 
`unsigned char` here is to save space taken by AlignPackInfo. And that's why I 
added the diagnostics and assertion in the ctor to make sure the value won't be 
truncated.



Comment at: clang/test/Sema/aix-pragma-pack-and-align.c:231
+
+// expected-no-warning

aaron.ballman wrote:
> Is this comment intentional?
Yes, my intention is to test no pragma pack or prama align is unterminated.


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

https://reviews.llvm.org/D87702

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

[PATCH] D92954: [clang-offload-bundler] Add option -list

[Yaxun Liu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG90bf3ecef4bb: [clang-offload-bundler] Add option -list 
(authored by yaxunl).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92954

Files:
  clang/test/Driver/clang-offload-bundler.c
  clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp

Index: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
===
--- clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
+++ clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
@@ -63,11 +63,11 @@
cl::desc("[,...]"),
cl::cat(ClangOffloadBundlerCategory));
 static cl::list
-OutputFileNames("outputs", cl::CommaSeparated, cl::OneOrMore,
+OutputFileNames("outputs", cl::CommaSeparated,
 cl::desc("[,...]"),
 cl::cat(ClangOffloadBundlerCategory));
 static cl::list
-TargetNames("targets", cl::CommaSeparated, cl::OneOrMore,
+TargetNames("targets", cl::CommaSeparated,
 cl::desc("[-,...]"),
 cl::cat(ClangOffloadBundlerCategory));
 static cl::opt
@@ -90,6 +90,10 @@
  cl::desc("Unbundle bundled file into several output files.\n"),
  cl::init(false), cl::cat(ClangOffloadBundlerCategory));
 
+static cl::opt
+ListBundleIDs("list", cl::desc("List bundle IDs in the bundled file.\n"),
+  cl::init(false), cl::cat(ClangOffloadBundlerCategory));
+
 static cl::opt PrintExternalCommands(
 "###",
 cl::desc("Print any external commands that are to be executed "
@@ -134,6 +138,10 @@
 /// Generic file handler interface.
 class FileHandler {
 public:
+  struct BundleInfo {
+StringRef BundleID;
+  };
+
   FileHandler() {}
 
   virtual ~FileHandler() {}
@@ -170,6 +178,48 @@
 
   /// Write the bundle from \a Input into \a OS.
   virtual Error WriteBundle(raw_fd_ostream , MemoryBuffer ) = 0;
+
+  /// List bundle IDs in \a Input.
+  virtual Error listBundleIDs(MemoryBuffer ) {
+if (Error Err = ReadHeader(Input))
+  return Err;
+
+return forEachBundle(Input, [&](const BundleInfo ) -> Error {
+  llvm::outs() << Info.BundleID << '\n';
+  Error Err = listBundleIDsCallback(Input, Info);
+  if (Err)
+return Err;
+  return Error::success();
+});
+  }
+
+  /// For each bundle in \a Input, do \a Func.
+  Error forEachBundle(MemoryBuffer ,
+  std::function Func) {
+while (true) {
+  Expected> CurTripleOrErr = ReadBundleStart(Input);
+  if (!CurTripleOrErr)
+return CurTripleOrErr.takeError();
+
+  // No more bundles.
+  if (!*CurTripleOrErr)
+break;
+
+  StringRef CurTriple = **CurTripleOrErr;
+  assert(!CurTriple.empty());
+
+  BundleInfo Info{CurTriple};
+  if (Error Err = Func(Info))
+return Err;
+}
+return Error::success();
+  }
+
+protected:
+  virtual Error listBundleIDsCallback(MemoryBuffer ,
+  const BundleInfo ) {
+return Error::success();
+  }
 };
 
 /// Handler for binary files. The bundled file will have the following format
@@ -219,22 +269,23 @@
 
 class BinaryFileHandler final : public FileHandler {
   /// Information about the bundles extracted from the header.
-  struct BundleInfo final {
+  struct BinaryBundleInfo final : public BundleInfo {
 /// Size of the bundle.
 uint64_t Size = 0u;
 /// Offset at which the bundle starts in the bundled file.
 uint64_t Offset = 0u;
 
-BundleInfo() {}
-BundleInfo(uint64_t Size, uint64_t Offset) : Size(Size), Offset(Offset) {}
+BinaryBundleInfo() {}
+BinaryBundleInfo(uint64_t Size, uint64_t Offset)
+: Size(Size), Offset(Offset) {}
   };
 
   /// Map between a triple and the corresponding bundle information.
-  StringMap BundlesInfo;
+  StringMap BundlesInfo;
 
   /// Iterator for the bundle information that is being read.
-  StringMap::iterator CurBundleInfo;
-  StringMap::iterator NextBundleInfo;
+  StringMap::iterator CurBundleInfo;
+  StringMap::iterator NextBundleInfo;
 
   /// Current bundle target to be written.
   std::string CurWriteBundleTarget;
@@ -304,7 +355,7 @@
 
   assert(BundlesInfo.find(Triple) == BundlesInfo.end() &&
  "Triple is duplicated??");
-  BundlesInfo[Triple] = BundleInfo(Size, Offset);
+  BundlesInfo[Triple] = BinaryBundleInfo(Size, Offset);
 }
 // Set the iterator to where we will start to read.
 CurBundleInfo = BundlesInfo.end();
@@ -358,7 +409,7 @@
   Write8byteIntegerToBuffer(OS, HeaderSize);
   // Size of the bundle (adds to the next bundle's offset)
   Write8byteIntegerToBuffer(OS, MB.getBufferSize());
-  BundlesInfo[T] = BundleInfo(MB.getBufferSize(), HeaderSize);
+  BundlesInfo[T] = 

[clang] 90bf3ec - [clang-offload-bundler] Add option -list

[Yaxun Liu via cfe-commits]

Author: Yaxun (Sam) Liu
Date: 2021-01-06T16:23:01-05:00
New Revision: 90bf3ecef4bb1e214a718aebcee730c24199c8ba

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

LOG: [clang-offload-bundler] Add option -list

clang-offload-bundler is not only used by clang driver
to bundle/unbundle files for offloading toolchains,
but also used by out of tree tools to unbundle
fat binaries generated by clang. It is important
to be able to list the bundle IDs in a bundled
file so that the bundles can be extracted.

This patch adds an option -list to list bundle
ID's in a bundled file. Each bundle ID is separated
by new line. If the file is not a bundled file
nothing is output and returns 0.

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

Added: 


Modified: 
clang/test/Driver/clang-offload-bundler.c
clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp

Removed: 




diff  --git a/clang/test/Driver/clang-offload-bundler.c 
b/clang/test/Driver/clang-offload-bundler.c
index b4bab6bbd1e8..3e1fab25d754 100644
--- a/clang/test/Driver/clang-offload-bundler.c
+++ b/clang/test/Driver/clang-offload-bundler.c
@@ -35,6 +35,7 @@
 // CK-HELP: {{.*}}USAGE: clang-offload-bundler [options]
 // CK-HELP: {{.*}}-allow-missing-bundles {{.*}}- Create empty files if bundles 
are missing when unbundling
 // CK-HELP: {{.*}}-inputs=  - [,...]
+// CK-HELP: {{.*}}-list {{.*}}- List bundle IDs in the bundled file.
 // CK-HELP: {{.*}}-outputs= - [,...]
 // CK-HELP: {{.*}}-targets= - [-,...]
 // CK-HELP: {{.*}}-type=- Type of the files to be 
bundled/unbundled.
@@ -54,7 +55,9 @@
 //
 // RUN: not clang-offload-bundler -type=i 
-targets=host-%itanium_abi_triple,openmp-powerpc64le-ibm-linux-gnu,openmp-x86_64-pc-linux-gnu
 -inputs=%t.i,%t.tgt1,%t.tgt2 -outputs=%t.bundle.i -unbundle 2>&1 | FileCheck 
%s --check-prefix CK-ERR1
 // CK-ERR1: error: only one input file supported in unbundling mode
-// CK-ERR1: error: number of output files and targets should match in 
unbundling mode
+
+// RUN: not clang-offload-bundler -type=i 
-targets=host-%itanium_abi_triple,openmp-powerpc64le-ibm-linux-gnu,openmp-x86_64-pc-linux-gnu
 -inputs=%t.i -outputs=%t.bundle.i -unbundle 2>&1 | FileCheck %s --check-prefix 
CK-ERR1A
+// CK-ERR1A: error: number of output files and targets should match in 
unbundling mode
 
 // RUN: not clang-offload-bundler -type=i 
-targets=host-%itanium_abi_triple,openmp-powerpc64le-ibm-linux-gnu 
-inputs=%t.i,%t.tgt1,%t.tgt2 -outputs=%t.bundle.i 2>&1 | FileCheck %s 
--check-prefix CK-ERR2
 // RUN: not clang-offload-bundler -type=i 
-targets=host-%itanium_abi_triple,openmp-powerpc64le-ibm-linux-gnu,openmp-x86_64-pc-linux-gnu
 -inputs=%t.i,%t.tgt1 -outputs=%t.bundle.i 2>&1 | FileCheck %s --check-prefix 
CK-ERR2
@@ -62,7 +65,6 @@
 
 // RUN: not clang-offload-bundler -type=i 
-targets=host-%itanium_abi_triple,openmp-powerpc64le-ibm-linux-gnu,openmp-x86_64-pc-linux-gnu
 -outputs=%t.i,%t.tgt1,%t.tgt2 -inputs=%t.bundle.i 2>&1 | FileCheck %s 
--check-prefix CK-ERR3
 // CK-ERR3: error: only one output file supported in bundling mode
-// CK-ERR3: error: number of input files and targets should match in bundling 
mode
 
 // RUN: not clang-offload-bundler -type=i 
-targets=host-%itanium_abi_triple,openmp-powerpc64le-ibm-linux-gnu 
-outputs=%t.i,%t.tgt1,%t.tgt2 -inputs=%t.bundle.i -unbundle 2>&1 | FileCheck %s 
--check-prefix CK-ERR4
 // RUN: not clang-offload-bundler -type=i 
-targets=host-%itanium_abi_triple,openmp-powerpc64le-ibm-linux-gnu,openmp-x86_64-pc-linux-gnu
 -outputs=%t.i,%t.tgt1 -inputs=%t.bundle.i -unbundle 2>&1 | FileCheck %s 
--check-prefix CK-ERR4
@@ -76,19 +78,27 @@
 // CK-ERR6: error: '[[TYPE]]': invalid file type specified
 
 // RUN: not clang-offload-bundler 2>&1 | FileCheck %s --check-prefix CK-ERR7
-// CK-ERR7-DAG: clang-offload-bundler: for the --type option: must be 
specified at least once!
-// CK-ERR7-DAG: clang-offload-bundler: for the --inputs option: must be 
specified at least once!
-// CK-ERR7-DAG: clang-offload-bundler: for the --outputs option: must be 
specified at least once!
-// CK-ERR7-DAG: clang-offload-bundler: for the --targets option: must be 
specified at least once!
+// CK-ERR7: clang-offload-bundler: for the --type option: must be specified at 
least once!
+
+// RUN: not clang-offload-bundler -type=i -inputs=%t.i,%t.tgt1,%t.tgt2 2>&1 | 
FileCheck %s -check-prefix=CK-ERR7A
+// CK-ERR7A: error: for the --outputs option: must be specified at least once!
+
+// RUN: not clang-offload-bundler -type=i -inputs=%t.i,%t.tgt1,%t.tgt2 
-outputs=%t.bundle.i 2>&1 | FileCheck %s -check-prefix=CK-ERR7B
+// CK-ERR7B: error: for the --targets option: must be specified at least once!
 
 // RUN: not clang-offload-bundler -type=i 

[PATCH] D93395: [clang][cli] Remove -f[no-]trapping-math from -cc1 command line

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith added a comment.

Please also update the commit message to explain why this is safe (that 
`-fp-exception-behavior` fully encapsulates the semantics for `-cc1`) rather 
than just saying the options were ignored (which sounds like a bug).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93395

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

[PATCH] D93395: [clang][cli] Remove -f[no-]trapping-math from -cc1 command line

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith accepted this revision.
dexonsmith added a comment.

LGTM. I've just done a careful audit myself, and I'm now confident this patch 
is correct and that there is no latent bug -- that it's correct to ignore 
`-f*trapping-math` on the `-cc1` command-line since `-fp-exception-mode` will 
always have a value matching / superseding `-f*trapping-math`.

@SjoerdMeijer , please confirm you agree as well.




Comment at: clang/lib/Driver/ToolChains/Clang.cpp:2598-2601
 FPExceptionBehavior = "strict";
 FPModel = Val;
 FPContract = "off";
 TrappingMath = true;

`FPExceptionBehavior` and `TrappingMath` are set together here (in lock step).



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:2626-2647
 case options::OPT_ftrapping_math:
   if (!TrappingMathPresent && !FPExceptionBehavior.empty() &&
   !FPExceptionBehavior.equals("strict"))
 // Warn that previous value of option is overridden.
 D.Diag(clang::diag::warn_drv_overriding_flag_option)
   << Args.MakeArgString("-ffp-exception-behavior=" + 
FPExceptionBehavior)
   << "-ftrapping-math";

Note this handling of `-ftrapping-math` in the driver, which uses it to set 
`FPExceptionBehaviour` correctly.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:2698-2717
 // Validate and pass through -ffp-exception-behavior option.
 case options::OPT_ffp_exception_behavior_EQ: {
   StringRef Val = A->getValue();
   if (!TrappingMathPresent && !FPExceptionBehavior.empty() &&
   !FPExceptionBehavior.equals(Val))
 // Warn that previous value of option is overridden.
 D.Diag(clang::diag::warn_drv_overriding_flag_option)

Note that `-ffp-exception-behaviour` also sets `FPExceptionBehaviour` (and 
`TrappingMath`).



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:2732-2733
   SignedZeros = false;
   TrappingMath = false;
   FPExceptionBehavior = "";
   break;

This will override `FPExceptionBehavior`, (wiping out any effect of 
`-ftrapping-math`), but that seems intentional and `TrappingMath` is set the 
same way.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:2739-2740
   SignedZeros = true;
   TrappingMath = true;
   FPExceptionBehavior = "strict";
 

`FPExceptionBehavior` and `TrappingMath` are also set together here.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:2829-2832
   if (TrappingMath) {
 // FP Exception Behavior is also set to strict
 assert(FPExceptionBehavior.equals("strict"));
+  }

Note: given the above, this assertion seems sufficient for confirming 
`-ftrapping-math` is effectively passed to `-cc1`.



Comment at: clang/lib/Frontend/CompilerInvocation.cpp:3068-3075
-  if (Args.hasArg(OPT_ftrapping_math)) {
-Opts.setFPExceptionMode(LangOptions::FPE_Strict);
-  }
-
-  if (Args.hasArg(OPT_fno_trapping_math)) {
-Opts.setFPExceptionMode(LangOptions::FPE_Ignore);
-  }

As long as `-cc1` always contains `-ffp-exception-behavior` (which includes any 
adjustment from `-ftrapping-math`), then it seems correct to drop this as this 
patch is doing.



Comment at: clang/lib/Frontend/CompilerInvocation.cpp:3080
   }
   Opts.setFPExceptionMode(FPEB);
 

SjoerdMeijer wrote:
> jansvoboda11 wrote:
> > SjoerdMeijer wrote:
> > > jansvoboda11 wrote:
> > > > The parsing of `OPT_ftrapping_math` and `OPT_fno_trapping_math` is 
> > > > immediately overwritten here.
> > > Yeah, I did some work in this area some years ago, but that's a few years 
> > > ago, and then in addition to that, we are talking about option handling 
> > > in Clang which I always find very confusing... Just saying I can't 
> > > remember too many details at this point.
> > > 
> > > But starting with a first observation, you're saying that things are 
> > > overwritten here, but they are different options. I.e., the deleted part 
> > > honours `OPT_ftrapping_math`, and here exception modes are set based on 
> > > `OPT_ffp_exception_behavior`. So, looks like there is some interaction 
> > > here... Do we know how this should work?
> > I see. The thing is, before this patch, we call `Opts.setFPExceptionMode` 
> > whenever we see either `OPT_ftrapping_math` or `OPT_fno_trapping_math`.
> > 
> > But then, we **unconditionally** call `Opts.setFPExceptionMode(FPEB)` again 
> > here. That **always** overwrites what we previously did for 
> > `OPT_f[no_]trapping_math`, making that a dead code.
> > 
> > `Opts.setFPExceptionMode()` doesn't do anything fancy, just assigns the 
> > argument to the `Opts.FPExceptionModel` member.
> Ah yes, I actually missed that we always set `Opts.setFPExceptionMode(FPEB)` 
> here! So that's clear now.
> 
> But looks like my previous question is still 

[PATCH] D93901: [NFC] Renaming PackStack to AlignPackStack

[Hubert Tong via Phabricator via cfe-commits]

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

LGTM; thanks.


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

https://reviews.llvm.org/D93901

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

[PATCH] D93846: [clang-format] PR16518 Add flag to suppress empty line insertion before access modifier

[Albertas Vyšniauskas via Phabricator via cfe-commits]

thezbyg updated this revision to Diff 314962.
thezbyg added a comment.

Switched `EmptyLineBeforeAccessModifierStyle` option from bool to enum.
`EmptyLineBeforeAccessModifierStyle` option can now have one of four values: 
`Never`, `DontModify`, `LogicalBlock`, `Always`.
`Never` removes all empty lines before access modifiers.
`DontModify` keeps existing empty lines.
`LogicalBlock` adds empty line only when access modifier starts a new logical 
block (current clang-format behavior).
`Always` adds empty line before all access modifiers except when access 
modifier is at the start of class/struct definition.

Updated tests to test all four option values. When testing `DontModify` option, 
some of the tests use `EXPECT_EQ()` instead of `verifyFormat()`. This is 
because empty lines are not preserved in `verifyFormat()` due to 
`test::messUp()`.


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

https://reviews.llvm.org/D93846

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/Format.cpp
  clang/lib/Format/UnwrappedLineFormatter.cpp
  clang/test/Format/access-modifiers.cpp
  clang/unittests/Format/FormatTest.cpp

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -8887,6 +8887,292 @@
getLLVMStyle());
 }
 
+TEST_F(FormatTest, FormatsAccessModifiers) {
+  verifyFormat("struct foo {\n"
+   "private:\n"
+   "  void f() {}\n"
+   "\n"
+   "private:\n"
+   "  int i;\n"
+   "\n"
+   "protected:\n"
+   "  int j;\n"
+   "};\n");
+  verifyFormat("struct foo {\n"
+   "private:\n"
+   "  void f() {}\n"
+   "\n"
+   "private:\n"
+   "  int i;\n"
+   "\n"
+   "protected:\n"
+   "  int j;\n"
+   "};\n",
+   "struct foo {\n"
+   "private:\n"
+   "  void f() {}\n"
+   "private:\n"
+   "  int i;\n"
+   "protected:\n"
+   "  int j;\n"
+   "};\n");
+  verifyFormat("struct foo { /* comment */\n"
+   "private:\n"
+   "  int i;\n"
+   "  // comment\n"
+   "private:\n"
+   "  int j;\n"
+   "};\n");
+  verifyFormat("struct foo {\n"
+   "#ifdef FOO\n"
+   "#endif\n"
+   "private:\n"
+   "  int i;\n"
+   "#ifdef FOO\n"
+   "private:\n"
+   "#endif\n"
+   "  int j;\n"
+   "};\n");
+  FormatStyle Style = getLLVMStyle();
+  Style.EmptyLineBeforeAccessModifier = FormatStyle::ELBAMS_Never;
+  verifyFormat("struct foo {\n"
+   "private:\n"
+   "  void f() {}\n"
+   "private:\n"
+   "  int i;\n"
+   "protected:\n"
+   "  int j;\n"
+   "};\n",
+   Style);
+  verifyFormat("struct foo {\n"
+   "private:\n"
+   "  void f() {}\n"
+   "private:\n"
+   "  int i;\n"
+   "protected:\n"
+   "  int j;\n"
+   "};\n",
+   "struct foo {\n"
+   "\n"
+   "private:\n"
+   "  void f() {}\n"
+   "\n"
+   "private:\n"
+   "  int i;\n"
+   "\n"
+   "protected:\n"
+   "  int j;\n"
+   "};\n",
+   Style);
+  verifyFormat("struct foo { /* comment */\n"
+   "private:\n"
+   "  int i;\n"
+   "  // comment\n"
+   "private:\n"
+   "  int j;\n"
+   "};\n",
+   "struct foo { /* comment */\n"
+   "\n"
+   "private:\n"
+   "  int i;\n"
+   "  // comment\n"
+   "\n"
+   "private:\n"
+   "  int j;\n"
+   "};\n",
+   Style);
+  verifyFormat("struct foo {\n"
+   "#ifdef FOO\n"
+   "#endif\n"
+   "private:\n"
+   "  int i;\n"
+   "#ifdef FOO\n"
+   "private:\n"
+   "#endif\n"
+   "  int j;\n"
+   "};\n",
+   "struct foo {\n"
+   "#ifdef FOO\n"
+   "#endif\n"
+   "\n"
+   "private:\n"
+   "  int i;\n"
+   "#ifdef FOO\n"
+   "\n"
+   "private:\n"
+   "#endif\n"
+   "  int j;\n"
+   "};\n",
+   Style);
+  Style.EmptyLineBeforeAccessModifier = FormatStyle::ELBAMS_Always;
+  verifyFormat("struct foo {\n"

[PATCH] D94188: [OpenCL] Documentation for experimental C++ libraries support

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

This patch is uploaded on top of https://reviews.llvm.org/D93942


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

https://reviews.llvm.org/D94188

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

[PATCH] D92160: [clang] Fix wrong FDs are used for files with same name in Tooling

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

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

(Marking as "Request Changes" to drop this from my queue; feel free to reach 
out if the direction I suggested isn't working well...)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92160

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

[PATCH] D92892: [clang] Change builtin object size to be compatible with GCC when sub-object is invalid

[Mott, Jeffrey T via Phabricator via cfe-commits]

jtmott-intel updated this revision to Diff 314965.
jtmott-intel added a comment.

Updated comments to reflect "outside of" instead of "before".


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

https://reviews.llvm.org/D92892

Files:
  clang/lib/AST/ExprConstant.cpp
  clang/test/CodeGen/object-size.c


Index: clang/test/CodeGen/object-size.c
===
--- clang/test/CodeGen/object-size.c
+++ clang/test/CodeGen/object-size.c
@@ -310,7 +310,7 @@
 void test25() {
   // CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* {{.*}}, i1 false, i1 true, 
i1
   gi = OBJECT_SIZE_BUILTIN((void*)0x1000, 0);
-  // CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* {{.*}}, i1 false, i1 true, 
i1
+  // CHECK: store i32 0
   gi = OBJECT_SIZE_BUILTIN((void*)0x1000, 1);
   // CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* {{.*}}, i1 true, i1 true, i1
   gi = OBJECT_SIZE_BUILTIN((void*)0x1000, 2);
@@ -321,7 +321,7 @@
 
   // CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* {{.*}}, i1 false, i1 true, 
i1
   gi = OBJECT_SIZE_BUILTIN((void*)0 + 0x1000, 0);
-  // CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* {{.*}}, i1 false, i1 true, 
i1
+  // CHECK: store i32 0
   gi = OBJECT_SIZE_BUILTIN((void*)0 + 0x1000, 1);
   // CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* {{.*}}, i1 true, i1 true, i1
   gi = OBJECT_SIZE_BUILTIN((void*)0 + 0x1000, 2);
@@ -337,7 +337,7 @@
 
   // CHECK: store i32 316
   gi = OBJECT_SIZE_BUILTIN([1].v[11], 0);
-  // CHECK: store i32 312
+  // CHECK: store i32 0
   gi = OBJECT_SIZE_BUILTIN([1].v[12], 1);
   // CHECK: store i32 308
   gi = OBJECT_SIZE_BUILTIN([1].v[13], 2);
@@ -433,7 +433,7 @@
 
   // CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* %{{.*}}, i1 false, i1 true, 
i1
   gi = OBJECT_SIZE_BUILTIN(d0->snd, 0);
-  // CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* %{{.*}}, i1 false, i1 true, 
i1
+  // CHECK: store i32 0
   gi = OBJECT_SIZE_BUILTIN(d0->snd, 1);
   // CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* %{{.*}}, i1 true, i1 true, 
i1
   gi = OBJECT_SIZE_BUILTIN(d0->snd, 2);
@@ -518,7 +518,7 @@
   // CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* %{{.*}}, i1 false, i1 true, 
i1
   gi = OBJECT_SIZE_BUILTIN([9].snd[0], 1);
 
-  // CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* %{{.*}}, i1 false, i1 true, 
i1
+  // CHECK: store i32 0
   gi = OBJECT_SIZE_BUILTIN([9].snd[0], 1);
 
   // CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* %{{.*}}, i1 false, i1 true, 
i1
Index: clang/lib/AST/ExprConstant.cpp
===
--- clang/lib/AST/ExprConstant.cpp
+++ clang/lib/AST/ExprConstant.cpp
@@ -11405,9 +11405,9 @@
   return false;
   }
 
-  // If we point to before the start of the object, there are no accessible
-  // bytes.
-  if (LVal.getLValueOffset().isNegative()) {
+  // If we point outside of the object, there are no accessible bytes.
+  if (LVal.getLValueOffset().isNegative() ||
+  ((Type & 1) && !LVal.Designator.isValidSubobject())) {
 Size = 0;
 return true;
   }


Index: clang/test/CodeGen/object-size.c
===
--- clang/test/CodeGen/object-size.c
+++ clang/test/CodeGen/object-size.c
@@ -310,7 +310,7 @@
 void test25() {
   // CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* {{.*}}, i1 false, i1 true, i1
   gi = OBJECT_SIZE_BUILTIN((void*)0x1000, 0);
-  // CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* {{.*}}, i1 false, i1 true, i1
+  // CHECK: store i32 0
   gi = OBJECT_SIZE_BUILTIN((void*)0x1000, 1);
   // CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* {{.*}}, i1 true, i1 true, i1
   gi = OBJECT_SIZE_BUILTIN((void*)0x1000, 2);
@@ -321,7 +321,7 @@
 
   // CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* {{.*}}, i1 false, i1 true, i1
   gi = OBJECT_SIZE_BUILTIN((void*)0 + 0x1000, 0);
-  // CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* {{.*}}, i1 false, i1 true, i1
+  // CHECK: store i32 0
   gi = OBJECT_SIZE_BUILTIN((void*)0 + 0x1000, 1);
   // CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* {{.*}}, i1 true, i1 true, i1
   gi = OBJECT_SIZE_BUILTIN((void*)0 + 0x1000, 2);
@@ -337,7 +337,7 @@
 
   // CHECK: store i32 316
   gi = OBJECT_SIZE_BUILTIN([1].v[11], 0);
-  // CHECK: store i32 312
+  // CHECK: store i32 0
   gi = OBJECT_SIZE_BUILTIN([1].v[12], 1);
   // CHECK: store i32 308
   gi = OBJECT_SIZE_BUILTIN([1].v[13], 2);
@@ -433,7 +433,7 @@
 
   // CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* %{{.*}}, i1 false, i1 true, i1
   gi = OBJECT_SIZE_BUILTIN(d0->snd, 0);
-  // CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* %{{.*}}, i1 false, i1 true, i1
+  // CHECK: store i32 0
   gi = OBJECT_SIZE_BUILTIN(d0->snd, 1);
   // CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* %{{.*}}, i1 true, i1 true, i1
   gi = OBJECT_SIZE_BUILTIN(d0->snd, 2);
@@ -518,7 +518,7 @@
   // CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* %{{.*}}, i1 false, i1 true, i1
   gi = OBJECT_SIZE_BUILTIN([9].snd[0], 1);
 
-  // CHECK: call i64 

[PATCH] D93701: [clang][cli] NFC: Pass an ignoring DiagnosticsEngine instead of nullptr to ParseDiagnosticArgs

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith added a comment.

With the above adjustment, this LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93701

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

[PATCH] D93701: [clang][cli] NFC: Pass an ignoring DiagnosticsEngine instead of nullptr to ParseDiagnosticArgs

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith added inline comments.



Comment at: clang/lib/Frontend/CompilerInvocation.cpp:1400-1402
 bool clang::ParseDiagnosticArgs(DiagnosticOptions , ArgList ,
-DiagnosticsEngine *Diags,
+DiagnosticsEngine ,
 bool DefaultDiagColor) {

Instead of this change (and updating callers), I suggest adding:
```
  Optional IgnoredDiags;
  if (!Diags) {
IgnoredDiags.emplace(new DiagnosticIDs(), new DiagnosticOptions(),
 new IgnoringDiagConsumer());
Diags = &*IgnoredDiags;
  }
```



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93701

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

[PATCH] D94188: [OpenCL] add documentation for experimental C++ libraries support

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia created this revision.
Anastasia added a reviewer: mantognini.
Herald added subscribers: ebevhan, yaxunl.
Anastasia requested review of this revision.

Started a new doc section about the OpenCL experimental features and described 
ongoing work on C++ libraries e.g. type traits.


https://reviews.llvm.org/D94188

Files:
  clang/docs/OpenCLSupport.rst


Index: clang/docs/OpenCLSupport.rst
===
--- clang/docs/OpenCLSupport.rst
+++ clang/docs/OpenCLSupport.rst
@@ -96,3 +96,56 @@
 
+--+--+--+---+
 | New functionality| Atomic mem scopes: subgroup, all devices 
including functions | :part:`worked on`| https://reviews.llvm.org/D92004 
(functions only)  |
 
+--+--+--+---+
+
+Experimental features
+=
+
+Clang provides the following new WIP features for the developers to experiment
+with and provide early feedback or contribute with further improvements.
+Feel free to contact us on `cfe-dev
+`_ or via `Bugzilla
+`_.
+
+C++ libraries for OpenCL
+
+
+There is ongoing work to support C++ standard libraries from `LLVM's libcxx
+`_ in OpenCL kernel code using C++ for OpenCL mode.
+
+It is currently possible to use `type_traits` from C++17 in the kernel sources
+if the following clang extensions are enabled ``__cl_clang_function_pointers``
+and ``__cl_clang_variadic_functions``, see :doc:`LanguageExtensions` for more
+details. The use of non-conformant features enabled by the extensions does not
+expose non-conformant behavior beyond the compilation i.e. does not get
+generated in IR or binary.  The extension only appear in metaprogramming
+mechanism to identify or verify the properties of types. This allows to provide
+the full C++ functionality without a loss of portability. To avoid unsafe use
+of the extensions it is recommended that the extensions are disabled directly
+after the header include.
+
+**Example of Use**:
+
+The example of kernel code with `type_traits` is illustrated here.
+
+.. code-block:: c++
+
+  #pragma OPENCL EXTENSION __cl_clang_function_pointers : enable
+  #pragma OPENCL EXTENSION __cl_clang_variadic_functions : enable
+  #include "type_traits"
+  #pragma OPENCL EXTENSION __cl_clang_function_pointers : disable
+  #pragma OPENCL EXTENSION __cl_clang_variadic_functions : disable
+ 
+  typedef std::make_signed::type sint_t;
+
+  __kernel void foo() {
+static_assert(!std::is_same::value);
+  }
+
+The possible clang invocation to compile the example is as follows:
+
+   .. code-block:: console
+
+ $ clang -cl-std=clc++  -I/include test.cl
+
+Note that `type_traits` is a header only library and therefore no extra
+linking step for the standard libraries is required.


Index: clang/docs/OpenCLSupport.rst
===
--- clang/docs/OpenCLSupport.rst
+++ clang/docs/OpenCLSupport.rst
@@ -96,3 +96,56 @@
 +--+--+--+---+
 | New functionality| Atomic mem scopes: subgroup, all devices including functions | :part:`worked on`| https://reviews.llvm.org/D92004 (functions only)  |
 +--+--+--+---+
+
+Experimental features
+=
+
+Clang provides the following new WIP features for the developers to experiment
+with and provide early feedback or contribute with further improvements.
+Feel free to contact us on `cfe-dev
+`_ or via `Bugzilla
+`_.
+
+C++ libraries for OpenCL
+
+
+There is ongoing work to support C++ standard libraries from `LLVM's libcxx
+`_ in OpenCL kernel code using C++ for OpenCL mode.
+
+It is currently possible to use `type_traits` from C++17 in the kernel sources
+if the following clang extensions are enabled ``__cl_clang_function_pointers``
+and ``__cl_clang_variadic_functions``, see :doc:`LanguageExtensions` for more
+details. The use of non-conformant features enabled by the extensions does not
+expose non-conformant behavior beyond the compilation i.e. does not get
+generated in IR or 

[PATCH] D94027: [OpenCL] Add clang extension for variadic functions

[Anastasia Stulova via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG0e874fc014be: [OpenCL] Add clang extension for variadic 
functions. (authored by Anastasia).
Herald added a project: clang.

Changed prior to commit:
  https://reviews.llvm.org/D94027?vs=314869=314964#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94027

Files:
  clang/docs/LanguageExtensions.rst
  clang/include/clang/Basic/OpenCLExtensions.def
  clang/lib/Basic/Targets/AMDGPU.h
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Sema/SemaType.cpp
  clang/test/Misc/amdgcn.languageOptsOpenCL.cl
  clang/test/Misc/nvptx.languageOptsOpenCL.cl
  clang/test/Misc/r600.languageOptsOpenCL.cl
  clang/test/SemaOpenCL/extension-version.cl
  clang/test/SemaOpenCL/func.cl

Index: clang/test/SemaOpenCL/func.cl
===
--- clang/test/SemaOpenCL/func.cl
+++ clang/test/SemaOpenCL/func.cl
@@ -1,18 +1,31 @@
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -triple spir-unknown-unknown
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -triple spir-unknown-unknown -DFUNCPTREXT
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -triple spir-unknown-unknown -DVARARG
 
 #ifdef FUNCPTREXT
 #pragma OPENCL EXTENSION __cl_clang_function_pointers : enable
 #endif
+#ifdef VARARGEXT
+#pragma OPENCL EXTENSION __cl_clang_variadic_functions : enable
+#endif
 
 // Variadic functions
-void vararg_f(int, ...);// expected-error {{invalid prototype, variadic arguments are not allowed in OpenCL}}
+void vararg_f(int, ...);
+#ifndef VARARGEXT
+// expected-error@-2 {{invalid prototype, variadic arguments are not allowed in OpenCL}}
+#endif
 void __vararg_f(int, ...);
-typedef void (*vararg_fptr_t)(int, ...);// expected-error {{invalid prototype, variadic arguments are not allowed in OpenCL}}
+typedef void (*vararg_fptr_t)(int, ...);
+#ifndef VARARGEXT
+// expected-error@-2 {{invalid prototype, variadic arguments are not allowed in OpenCL}}
+#endif
 #ifndef FUNCPTREXT
-// expected-error@-2 {{pointers to functions are not allowed}}
+// expected-error@-5 {{pointers to functions are not allowed}}
+#endif
+int printf(__constant const char *st, ...);
+#ifndef VARARGEXT
+// expected-error@-2 {{invalid prototype, variadic arguments are not allowed in OpenCL}}
 #endif
-int printf(__constant const char *st, ...); // expected-error {{invalid prototype, variadic arguments are not allowed in OpenCL}}
 
 // Struct type with function pointer field
 typedef struct s
Index: clang/test/SemaOpenCL/extension-version.cl
===
--- clang/test/SemaOpenCL/extension-version.cl
+++ clang/test/SemaOpenCL/extension-version.cl
@@ -24,6 +24,11 @@
 #endif
 #pragma OPENCL EXTENSION __cl_clang_function_pointers : enable
 
+#ifndef __cl_clang_variadic_functions
+#error "Missing __cl_clang_variadic_functions define"
+#endif
+#pragma OPENCL EXTENSION __cl_clang_variadic_functions : enable
+
 #ifndef cl_khr_fp16
 #error "Missing cl_khr_fp16 define"
 #endif
Index: clang/test/Misc/r600.languageOptsOpenCL.cl
===
--- clang/test/Misc/r600.languageOptsOpenCL.cl
+++ clang/test/Misc/r600.languageOptsOpenCL.cl
@@ -35,6 +35,11 @@
 #endif
 #pragma OPENCL EXTENSION __cl_clang_function_pointers : enable
 
+#ifndef __cl_clang_variadic_functions
+#error "Missing __cl_clang_variadic_functions define"
+#endif
+#pragma OPENCL EXTENSION __cl_clang_variadic_functions : enable
+
 #ifdef cl_khr_fp16
 #error "Incorrect cl_khr_fp16 define"
 #endif
Index: clang/test/Misc/nvptx.languageOptsOpenCL.cl
===
--- clang/test/Misc/nvptx.languageOptsOpenCL.cl
+++ clang/test/Misc/nvptx.languageOptsOpenCL.cl
@@ -27,6 +27,11 @@
 #endif
 #pragma OPENCL EXTENSION __cl_clang_function_pointers : enable
 
+#ifndef __cl_clang_variadic_functions
+#error "Missing __cl_clang_variadic_functions define"
+#endif
+#pragma OPENCL EXTENSION __cl_clang_variadic_functions : enable
+
 #ifdef cl_khr_fp16
 #error "Incorrect cl_khr_fp16 define"
 #endif
Index: clang/test/Misc/amdgcn.languageOptsOpenCL.cl
===
--- clang/test/Misc/amdgcn.languageOptsOpenCL.cl
+++ clang/test/Misc/amdgcn.languageOptsOpenCL.cl
@@ -19,6 +19,11 @@
 #endif
 #pragma OPENCL EXTENSION __cl_clang_function_pointers : enable
 
+#ifndef __cl_clang_variadic_functions
+#error "Missing __cl_clang_variadic_functions define"
+#endif
+#pragma OPENCL EXTENSION __cl_clang_variadic_functions : enable
+
 #ifndef cl_khr_fp16
 #error "Missing cl_khr_fp16 define"
 #endif
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -5019,6 +5019,7 @@
 // 

[PATCH] D94021: [OpenCL] Add clang extension for function pointers

[Anastasia Stulova via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG4fde2b6a0c08: [OpenCL] Add clang extension for function 
pointers. (authored by Anastasia).
Herald added a project: clang.

Changed prior to commit:
  https://reviews.llvm.org/D94021?vs=314411=314963#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94021

Files:
  clang/docs/LanguageExtensions.rst
  clang/include/clang/Basic/OpenCLExtensions.def
  clang/lib/Basic/Targets/AMDGPU.h
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/Misc/amdgcn.languageOptsOpenCL.cl
  clang/test/Misc/nvptx.languageOptsOpenCL.cl
  clang/test/Misc/r600.languageOptsOpenCL.cl
  clang/test/Parser/opencl-cxx-virtual.cl
  clang/test/SemaOpenCL/extension-version.cl
  clang/test/SemaOpenCL/func.cl
  clang/test/SemaOpenCLCXX/members.cl

Index: clang/test/SemaOpenCLCXX/members.cl
===
--- clang/test/SemaOpenCLCXX/members.cl
+++ clang/test/SemaOpenCLCXX/members.cl
@@ -1,6 +1,13 @@
 //RUN: %clang_cc1 %s -triple spir -cl-std=clc++ -verify -fsyntax-only
+//RUN: %clang_cc1 %s -triple spir -cl-std=clc++ -verify -fsyntax-only -DFUNCPTREXT
+
+#ifdef FUNCPTREXT
+#pragma OPENCL EXTENSION __cl_clang_function_pointers : enable
+//expected-no-diagnostics
+#endif
 
 // Check that pointer to member functions are diagnosed
+// unless specific clang extension is enabled.
 struct C {
   void f(int n);
 };
@@ -12,11 +19,25 @@
 
 template 
 void templ_test() {
-  typename remove_reference::type *ptr; //expected-error{{pointers to functions are not allowed}}
+  typename remove_reference::type *ptr;
+#ifndef FUNCPTREXT
+  //expected-error@-2{{pointers to functions are not allowed}}
+#endif
 }
 
 void test() {
-  void (C::*p)(int);   //expected-error{{pointers to functions are not allowed}}
-  p_t p1;  //expected-error{{pointers to functions are not allowed}}
-  templ_test(); //expected-note{{in instantiation of function template specialization}}
+  void (C::*p)(int);
+#ifndef FUNCPTREXT
+//expected-error@-2{{pointers to functions are not allowed}}
+#endif
+
+  p_t p1;
+#ifndef FUNCPTREXT
+//expected-error@-2{{pointers to functions are not allowed}}
+#endif
+
+  templ_test();
+#ifndef FUNCPTREXT
+//expected-note@-2{{in instantiation of function template specialization}}
+#endif
 }
Index: clang/test/SemaOpenCL/func.cl
===
--- clang/test/SemaOpenCL/func.cl
+++ clang/test/SemaOpenCL/func.cl
@@ -1,16 +1,26 @@
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -triple spir-unknown-unknown
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -triple spir-unknown-unknown -DFUNCPTREXT
+
+#ifdef FUNCPTREXT
+#pragma OPENCL EXTENSION __cl_clang_function_pointers : enable
+#endif
 
 // Variadic functions
 void vararg_f(int, ...);// expected-error {{invalid prototype, variadic arguments are not allowed in OpenCL}}
 void __vararg_f(int, ...);
 typedef void (*vararg_fptr_t)(int, ...);// expected-error {{invalid prototype, variadic arguments are not allowed in OpenCL}}
-// expected-error@-1{{pointers to functions are not allowed}}
+#ifndef FUNCPTREXT
+// expected-error@-2 {{pointers to functions are not allowed}}
+#endif
 int printf(__constant const char *st, ...); // expected-error {{invalid prototype, variadic arguments are not allowed in OpenCL}}
 
 // Struct type with function pointer field
 typedef struct s
 {
-   void (*f)(struct s *self, int *i);   // expected-error{{pointers to functions are not allowed}}
+   void (*f)(struct s *self, int *i);
+#ifndef FUNCPTREXT
+// expected-error@-2 {{pointers to functions are not allowed}}
+#endif
 } s_t;
 
 //Function pointer
@@ -22,7 +32,10 @@
 void bar()
 {
   // declaring a function pointer is an error
-  void (*fptr)(int); // expected-error{{pointers to functions are not allowed}}
+  void (*fptr)(int);
+#ifndef FUNCPTREXT
+  // expected-error@-2 {{pointers to functions are not allowed}}
+#endif
 
   // taking the address of a function is an error
   foo((void*)foo); // expected-error{{taking address of function is not allowed}}
Index: clang/test/SemaOpenCL/extension-version.cl
===
--- clang/test/SemaOpenCL/extension-version.cl
+++ clang/test/SemaOpenCL/extension-version.cl
@@ -17,7 +17,12 @@
 #ifndef cl_clang_storage_class_specifiers
 #error "Missing cl_clang_storage_class_specifiers define"
 #endif
-#pragma OPENCL EXTENSION cl_clang_storage_class_specifiers: enable
+#pragma OPENCL EXTENSION cl_clang_storage_class_specifiers : enable
+
+#ifndef __cl_clang_function_pointers
+#error "Missing __cl_clang_function_pointers define"
+#endif
+#pragma OPENCL EXTENSION 

[clang] 0e874fc - [OpenCL] Add clang extension for variadic functions.

[Anastasia Stulova via cfe-commits]

Author: Anastasia Stulova
Date: 2021-01-06T20:39:57Z
New Revision: 0e874fc014be818a9c6782729f2c8e8273a7a906

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

LOG: [OpenCL] Add clang extension for variadic functions.

With the internal clang extension '__cl_clang_variadic_functions'
variadic functions are accepted by the frontend.

This is not a fully supported vendor/Khronos extension
as it can only be used on targets with variadic prototype
support or in metaprogramming to represent functions with
generic prototype without calling such functions in the
kernel code.

Tags: #clang

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

Added: 


Modified: 
clang/docs/LanguageExtensions.rst
clang/include/clang/Basic/OpenCLExtensions.def
clang/lib/Basic/Targets/AMDGPU.h
clang/lib/Basic/Targets/NVPTX.h
clang/lib/Sema/SemaType.cpp
clang/test/Misc/amdgcn.languageOptsOpenCL.cl
clang/test/Misc/nvptx.languageOptsOpenCL.cl
clang/test/Misc/r600.languageOptsOpenCL.cl
clang/test/SemaOpenCL/extension-version.cl
clang/test/SemaOpenCL/func.cl

Removed: 




diff  --git a/clang/docs/LanguageExtensions.rst 
b/clang/docs/LanguageExtensions.rst
index fd011b101b6e..0c01a2bbc52b 100644
--- a/clang/docs/LanguageExtensions.rst
+++ b/clang/docs/LanguageExtensions.rst
@@ -1773,6 +1773,31 @@ correctly in any circumstances. It can be used if:
 void (*fp)(); // error - pointers to function are not allowed
   }
 
+``__cl_clang_variadic_functions``
+-
+
+With this extension it is possible to enable variadic arguments in functions
+using regular OpenCL extension pragma mechanism detailed in `the OpenCL
+Extension Specification, section 1.2
+`_.
+
+This is not conformant behavior and it can only be used portably when the
+functions with variadic prototypes do not get generated in binary e.g. the
+variadic prototype is used to spesify a function type with any number of
+arguments in metaprogramming algorithms in C++ for OpenCL.
+
+This extensions can also be used when the kernel code is intended for targets
+supporting the variadic arguments e.g. majority of CPU targets.
+
+**Example of Use**:
+
+.. code-block:: c++
+
+  #pragma OPENCL EXTENSION __cl_clang_variadic_functions : enable
+  void foo(int a, ...); // compiled - no diagnostic generated
+
+  #pragma OPENCL EXTENSION __cl_clang_variadic_functions : disable
+  void bar(int a, ...); // error - variadic prototype is not allowed
 
 Builtin Functions
 =

diff  --git a/clang/include/clang/Basic/OpenCLExtensions.def 
b/clang/include/clang/Basic/OpenCLExtensions.def
index 149594ed40b0..9353be1753b0 100644
--- a/clang/include/clang/Basic/OpenCLExtensions.def
+++ b/clang/include/clang/Basic/OpenCLExtensions.def
@@ -70,6 +70,7 @@ OPENCLEXT_INTERNAL(cl_khr_subgroups, 200, ~0U)
 // Clang Extensions.
 OPENCLEXT_INTERNAL(cl_clang_storage_class_specifiers, 100, ~0U)
 OPENCLEXT_INTERNAL(__cl_clang_function_pointers, 100, ~0U)
+OPENCLEXT_INTERNAL(__cl_clang_variadic_functions, 100, ~0U)
 
 // AMD OpenCL extensions
 OPENCLEXT_INTERNAL(cl_amd_media_ops, 100, ~0U)

diff  --git a/clang/lib/Basic/Targets/AMDGPU.h 
b/clang/lib/Basic/Targets/AMDGPU.h
index 3fdbf320a329..fba1e4288ed1 100644
--- a/clang/lib/Basic/Targets/AMDGPU.h
+++ b/clang/lib/Basic/Targets/AMDGPU.h
@@ -286,6 +286,7 @@ class LLVM_LIBRARY_VISIBILITY AMDGPUTargetInfo final : 
public TargetInfo {
 auto  = getSupportedOpenCLOpts();
 Opts.support("cl_clang_storage_class_specifiers");
 Opts.support("__cl_clang_function_pointers");
+Opts.support("__cl_clang_variadic_functions");
 
 bool IsAMDGCN = isAMDGCN(getTriple());
 

diff  --git a/clang/lib/Basic/Targets/NVPTX.h b/clang/lib/Basic/Targets/NVPTX.h
index 8e0da6554708..c4320e86e0db 100644
--- a/clang/lib/Basic/Targets/NVPTX.h
+++ b/clang/lib/Basic/Targets/NVPTX.h
@@ -129,6 +129,7 @@ class LLVM_LIBRARY_VISIBILITY NVPTXTargetInfo : public 
TargetInfo {
 auto  = getSupportedOpenCLOpts();
 Opts.support("cl_clang_storage_class_specifiers");
 Opts.support("__cl_clang_function_pointers");
+Opts.support("__cl_clang_variadic_functions");
 
 Opts.support("cl_khr_fp64");
 Opts.support("cl_khr_byte_addressable_store");

diff  --git a/clang/lib/Sema/SemaType.cpp b/clang/lib/Sema/SemaType.cpp
index 31018dc1d0e7..f51c616169f5 100644
--- a/clang/lib/Sema/SemaType.cpp
+++ b/clang/lib/Sema/SemaType.cpp
@@ -5019,6 +5019,7 @@ static TypeSourceInfo 
*GetFullTypeForDeclarator(TypeProcessingState ,
 // (s6.9.e and s6.12.5 OpenCL v2.0) except for printf.
 // We also allow here any toolchain reserved identifiers.
 if (FTI.isVariadic &&
+ 

[clang] 4fde2b6 - [OpenCL] Add clang extension for function pointers.

[Anastasia Stulova via cfe-commits]

Author: Anastasia Stulova
Date: 2021-01-06T20:39:57Z
New Revision: 4fde2b6a0c080cb2a598383b5850038d67ca6833

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

LOG: [OpenCL] Add clang extension for function pointers.

The new clang internal extension '__cl_clang_function_pointers'
allows use of function pointers and other features that have
the same functionality:
- Use of member function pointers;
- Unrestricted use of references to functions;
- Virtual member functions.

This not a vendor extension and therefore it doesn't require any
special target support. Exposing this functionality fully
will require vendor or Khronos extension.

Tags: #clang

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

Added: 


Modified: 
clang/docs/LanguageExtensions.rst
clang/include/clang/Basic/OpenCLExtensions.def
clang/lib/Basic/Targets/AMDGPU.h
clang/lib/Basic/Targets/NVPTX.h
clang/lib/Parse/ParseDecl.cpp
clang/lib/Sema/SemaDecl.cpp
clang/lib/Sema/SemaType.cpp
clang/test/Misc/amdgcn.languageOptsOpenCL.cl
clang/test/Misc/nvptx.languageOptsOpenCL.cl
clang/test/Misc/r600.languageOptsOpenCL.cl
clang/test/Parser/opencl-cxx-virtual.cl
clang/test/SemaOpenCL/extension-version.cl
clang/test/SemaOpenCL/func.cl
clang/test/SemaOpenCLCXX/members.cl

Removed: 




diff  --git a/clang/docs/LanguageExtensions.rst 
b/clang/docs/LanguageExtensions.rst
index 6280c486ccbb..fd011b101b6e 100644
--- a/clang/docs/LanguageExtensions.rst
+++ b/clang/docs/LanguageExtensions.rst
@@ -1722,6 +1722,58 @@ syntax to be used with ``std::complex`` with the same 
meaning.)
 For GCC compatibility, ``__builtin_complex(re, im)`` can also be used to
 construct a complex number from the given real and imaginary components.
 
+OpenCL Features
+===
+
+Clang supports internal OpenCL extensions documented below.
+
+``__cl_clang_function_pointers``
+
+
+With this extension it is possible to enable various language features that
+are relying on function pointers using regular OpenCL extension pragma
+mechanism detailed in `the OpenCL Extension Specification,
+section 1.2
+`_.
+
+In C++ for OpenCL this also enables:
+
+- Use of member function pointers;
+
+- Unrestricted use of references to functions;
+
+- Virtual member functions.
+
+Such functionality is not conformant and does not guarantee to compile
+correctly in any circumstances. It can be used if:
+
+- the kernel source does not contain call expressions to (member-) function
+  pointers, or virtual functions. For example this extension can be used in
+  metaprogramming algorithms to be able to specify/detect types generically.
+
+- the generated kernel binary does not contain indirect calls because they
+  are eliminated using compiler optimizations e.g. devirtualization. 
+
+- the selected target supports the function pointer like functionality e.g.
+  most CPU targets.
+
+**Example of Use**:
+
+.. code-block:: c++
+
+  #pragma OPENCL EXTENSION __cl_clang_function_pointers : enable
+  void foo()
+  {
+void (*fp)(); // compiled - no diagnostic generated
+  }
+
+  #pragma OPENCL EXTENSION __cl_clang_function_pointers : disable
+  void bar()
+  {
+void (*fp)(); // error - pointers to function are not allowed
+  }
+
+
 Builtin Functions
 =
 

diff  --git a/clang/include/clang/Basic/OpenCLExtensions.def 
b/clang/include/clang/Basic/OpenCLExtensions.def
index 17d402f300f1..149594ed40b0 100644
--- a/clang/include/clang/Basic/OpenCLExtensions.def
+++ b/clang/include/clang/Basic/OpenCLExtensions.def
@@ -69,6 +69,7 @@ OPENCLEXT_INTERNAL(cl_khr_subgroups, 200, ~0U)
 
 // Clang Extensions.
 OPENCLEXT_INTERNAL(cl_clang_storage_class_specifiers, 100, ~0U)
+OPENCLEXT_INTERNAL(__cl_clang_function_pointers, 100, ~0U)
 
 // AMD OpenCL extensions
 OPENCLEXT_INTERNAL(cl_amd_media_ops, 100, ~0U)

diff  --git a/clang/lib/Basic/Targets/AMDGPU.h 
b/clang/lib/Basic/Targets/AMDGPU.h
index 8b3f30ed70e9..3fdbf320a329 100644
--- a/clang/lib/Basic/Targets/AMDGPU.h
+++ b/clang/lib/Basic/Targets/AMDGPU.h
@@ -285,6 +285,7 @@ class LLVM_LIBRARY_VISIBILITY AMDGPUTargetInfo final : 
public TargetInfo {
   void setSupportedOpenCLOpts() override {
 auto  = getSupportedOpenCLOpts();
 Opts.support("cl_clang_storage_class_specifiers");
+Opts.support("__cl_clang_function_pointers");
 
 bool IsAMDGCN = isAMDGCN(getTriple());
 

diff  --git a/clang/lib/Basic/Targets/NVPTX.h b/clang/lib/Basic/Targets/NVPTX.h
index f8d0afdcceae..8e0da6554708 100644
--- a/clang/lib/Basic/Targets/NVPTX.h
+++ b/clang/lib/Basic/Targets/NVPTX.h
@@ -128,6 +128,7 @@ class LLVM_LIBRARY_VISIBILITY NVPTXTargetInfo 

[PATCH] D93702: [clang][cli] NFC: Make marshalling macros reusable

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

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

LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93702

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

[PATCH] D94172: [clang][cli] NFC: Move parseSimpleArgs

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

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

LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94172

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

[PATCH] D84673: [clang][cli] Port DiagnosticOpts to new option parsing system

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith added inline comments.



Comment at: clang/include/clang/Driver/Options.td:1193-1195
+defm caret_diagnostics : BoolFOption<"caret-diagnostics",
+  "DiagnosticOpts->ShowCarets", DefaultsToTrue,
+  ChangedBy, ResetBy>, IsDiag;

There was one thing in the original patch that was a bit of sanity check for 
whether `IsDiag` was added to the wrong option: the `DiagnosticOpts->` part of 
the keypath was implicit. What do you think of adding that back? That would 
make the keypath here `ShowCarets`.

It highlights that diagnostics are special (since `DiagnosticOpts` is never 
mentioned in the file, and any mistakes could be found with a `grep`).



Comment at: clang/lib/Frontend/CompilerInvocation.cpp:3212
+
+#define DIAG_OPTION_WITH_MARSHALLING OPTION_WITH_MARSHALLING
+

Making `DiagnosticOpts->` implicit requires a little more code here:
```
#define DIAG_OPTION_WITH_MARSHALLING(  \
PREFIX_TYPE, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,\
HELPTEXT, METAVAR, VALUES, SPELLING, ALWAYS_EMIT, KEYPATH, DEFAULT_VALUE,  \
IMPLIED_CHECK, IMPLIED_VALUE, NORMALIZER, DENORMALIZER, MERGER, EXTRACTOR, \
TABLE_INDEX)   \
  GENERATE_OPTION_WITH_MARSHALLING(\
  Args, SA, KIND, FLAGS, SPELLING, ALWAYS_EMIT, DiagnosticOpts->KEYPATH,   \
  DEFAULT_VALUE, IMPLIED_CHECK, IMPLIED_VALUE, DENORMALIZER, EXTRACTOR,\
  TABLE_INDEX)
```
But I think it might be worth it for the sanity check.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84673

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

[PATCH] D92954: [clang-offload-bundler] Add option -list

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl updated this revision to Diff 314957.
yaxunl marked 4 inline comments as done.
yaxunl added a comment.

revised by Artem's comments


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

https://reviews.llvm.org/D92954

Files:
  clang/test/Driver/clang-offload-bundler.c
  clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp

Index: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
===
--- clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
+++ clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
@@ -63,11 +63,11 @@
cl::desc("[,...]"),
cl::cat(ClangOffloadBundlerCategory));
 static cl::list
-OutputFileNames("outputs", cl::CommaSeparated, cl::OneOrMore,
+OutputFileNames("outputs", cl::CommaSeparated,
 cl::desc("[,...]"),
 cl::cat(ClangOffloadBundlerCategory));
 static cl::list
-TargetNames("targets", cl::CommaSeparated, cl::OneOrMore,
+TargetNames("targets", cl::CommaSeparated,
 cl::desc("[-,...]"),
 cl::cat(ClangOffloadBundlerCategory));
 static cl::opt
@@ -90,6 +90,10 @@
  cl::desc("Unbundle bundled file into several output files.\n"),
  cl::init(false), cl::cat(ClangOffloadBundlerCategory));
 
+static cl::opt
+ListBundleIDs("list", cl::desc("List bundle IDs in the bundled file.\n"),
+  cl::init(false), cl::cat(ClangOffloadBundlerCategory));
+
 static cl::opt PrintExternalCommands(
 "###",
 cl::desc("Print any external commands that are to be executed "
@@ -134,6 +138,10 @@
 /// Generic file handler interface.
 class FileHandler {
 public:
+  struct BundleInfo {
+StringRef BundleID;
+  };
+
   FileHandler() {}
 
   virtual ~FileHandler() {}
@@ -170,6 +178,48 @@
 
   /// Write the bundle from \a Input into \a OS.
   virtual Error WriteBundle(raw_fd_ostream , MemoryBuffer ) = 0;
+
+  /// List bundle IDs in \a Input.
+  virtual Error listBundleIDs(MemoryBuffer ) {
+if (Error Err = ReadHeader(Input))
+  return Err;
+
+return forEachBundle(Input, [&](const BundleInfo ) -> Error {
+  llvm::outs() << Info.BundleID << '\n';
+  Error Err = listBundleIDsCallback(Input, Info);
+  if (Err)
+return Err;
+  return Error::success();
+});
+  }
+
+  /// For each bundle in \a Input, do \a Func.
+  Error forEachBundle(MemoryBuffer ,
+  std::function Func) {
+while (true) {
+  Expected> CurTripleOrErr = ReadBundleStart(Input);
+  if (!CurTripleOrErr)
+return CurTripleOrErr.takeError();
+
+  // No more bundles.
+  if (!*CurTripleOrErr)
+break;
+
+  StringRef CurTriple = **CurTripleOrErr;
+  assert(!CurTriple.empty());
+
+  BundleInfo Info{CurTriple};
+  if (Error Err = Func(Info))
+return Err;
+}
+return Error::success();
+  }
+
+protected:
+  virtual Error listBundleIDsCallback(MemoryBuffer ,
+  const BundleInfo ) {
+return Error::success();
+  }
 };
 
 /// Handler for binary files. The bundled file will have the following format
@@ -219,22 +269,23 @@
 
 class BinaryFileHandler final : public FileHandler {
   /// Information about the bundles extracted from the header.
-  struct BundleInfo final {
+  struct BinaryBundleInfo final : public BundleInfo {
 /// Size of the bundle.
 uint64_t Size = 0u;
 /// Offset at which the bundle starts in the bundled file.
 uint64_t Offset = 0u;
 
-BundleInfo() {}
-BundleInfo(uint64_t Size, uint64_t Offset) : Size(Size), Offset(Offset) {}
+BinaryBundleInfo() {}
+BinaryBundleInfo(uint64_t Size, uint64_t Offset)
+: Size(Size), Offset(Offset) {}
   };
 
   /// Map between a triple and the corresponding bundle information.
-  StringMap BundlesInfo;
+  StringMap BundlesInfo;
 
   /// Iterator for the bundle information that is being read.
-  StringMap::iterator CurBundleInfo;
-  StringMap::iterator NextBundleInfo;
+  StringMap::iterator CurBundleInfo;
+  StringMap::iterator NextBundleInfo;
 
   /// Current bundle target to be written.
   std::string CurWriteBundleTarget;
@@ -304,7 +355,7 @@
 
   assert(BundlesInfo.find(Triple) == BundlesInfo.end() &&
  "Triple is duplicated??");
-  BundlesInfo[Triple] = BundleInfo(Size, Offset);
+  BundlesInfo[Triple] = BinaryBundleInfo(Size, Offset);
 }
 // Set the iterator to where we will start to read.
 CurBundleInfo = BundlesInfo.end();
@@ -358,7 +409,7 @@
   Write8byteIntegerToBuffer(OS, HeaderSize);
   // Size of the bundle (adds to the next bundle's offset)
   Write8byteIntegerToBuffer(OS, MB.getBufferSize());
-  BundlesInfo[T] = BundleInfo(MB.getBufferSize(), HeaderSize);
+  BundlesInfo[T] = BinaryBundleInfo(MB.getBufferSize(), HeaderSize);
   HeaderSize += MB.getBufferSize();
   // Size of the triple
 

[PATCH] D92954: [clang-offload-bundler] Add option -list

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl marked 4 inline comments as done.
yaxunl added inline comments.



Comment at: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp:176
+  /// List bundle IDs in \a Input.
+  virtual Error listBundleIDs(MemoryBuffer ) {
+if (Error Err = ReadHeader(Input))

tra wrote:
> Now that listBundleIDs is only used by ` ListBundleIDsInFile()`, perhaps it 
> could all be simplified and moved out of the class.
listBundleIDsCallback needs to be a virtual function and it is called by 
listBundleIDs. Keep listBundleIDs as a member function together with 
listBundleIDsCallback shows their relation and is more readable.



Comment at: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp:882
+// List bundle IDs. Return true if an error was found.
+static Error ListBundleIDsInFile() {
+  // Open Input file.

tra wrote:
> I'd pass InputFileNames as an argument. Makes it easier to tell what the 
> function needs.
done



Comment at: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp:1031-1035
+  Error = true;
+  reportError(createStringError(
+  errc::invalid_argument,
+  "for the --outputs option: must be specified at least once!"));
+}

tra wrote:
> Does it make sense to continue once we know that CLI options are wrong?
> If we just early-exit with an error that may help simplifying the code below 
> a bit.
> 
> 
done



Comment at: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp:1047
+errc::invalid_argument, "-unbundle and -list cannot be used 
together"));
+  } else if (ListBundleIDs) {
+if (InputFileNames.size() != 1) {

tra wrote:
> Perhaps we can separate list option processing from bundle/unbundle?
> 
> I think if we could do something like this it would be more readable:
> ```
> if (ListBundleIDs) {
>   if (Unbundle) {
> error...
> exit.
>   }
>   ... other list-specific checks...
>   ListBundleIDsInFile(InputFileNames)
>   exit 0;
> }
> 
> // complicated bundle/unbundle logic can proceed without having to bother 
> about `list` option.
> ```
done


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

https://reviews.llvm.org/D92954

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

[PATCH] D92270: [ConstantFold] Fold more operations to poison

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

We bisected a test failure to this 
(https://bugs.chromium.org/p/angleproject/issues/detail?id=5500#c17). Can you 
expand a bit on what this patch means in practice? I'm guessing it makes UB in 
C++ code have bad effects more often? If so, what type of UB?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92270

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

[clang-tools-extra] 0bfe100 - [NFC] Test case refactor

[Nathan James via cfe-commits]

Author: Nathan James
Date: 2021-01-06T20:00:15Z
New Revision: 0bfe100145634988e4a914da776b55509ba0bec0

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

LOG: [NFC] Test case refactor

Added: 


Modified: 
clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp 
b/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
index a51067896432..c87c1be6f8e9 100644
--- a/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
+++ b/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
@@ -1042,7 +1042,7 @@ TEST_F(TUSchedulerTests, CommandLineWarnings) {
 
 TEST(DebouncePolicy, Compute) {
   namespace c = std::chrono;
-  std::vector History = {
+  DebouncePolicy::clock::duration History[] = {
   c::seconds(0),
   c::seconds(5),
   c::seconds(10),
@@ -1053,8 +1053,9 @@ TEST(DebouncePolicy, Compute) {
   Policy.Max = c::seconds(25);
   // Call Policy.compute(History) and return seconds as a float.
   auto Compute = [&](llvm::ArrayRef History) {
-using FloatingSeconds = c::duration;
-return static_cast(Policy.compute(History) / FloatingSeconds(1));
+return c::duration_cast>(
+   Policy.compute(History))
+.count();
   };
   EXPECT_NEAR(10, Compute(History), 0.01) << "(upper) median = 10";
   Policy.RebuildRatio = 1.5;



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

[PATCH] D93747: Rename debug linkage name with -funique-internal-linkage-names

[Hongtao Yu via Phabricator via cfe-commits]

hoy added a comment.

In D93747#2482730 , @tmsriram wrote:

> In D93747#2482726 , @hoy wrote:
>
>> In D93747#2482519 , @tmsriram wrote:
>>
>>> In D93747#2481494 , @dblaikie 
>>> wrote:
>>>
 In D93747#2481383 , @hoy wrote:

> In D93747#2481304 , @tmsriram 
> wrote:
>
>> In D93747#2481223 , @tmsriram 
>> wrote:
>>
>>> In D93747#2481163 , @dblaikie 
>>> wrote:
>>>
 In D93747#2481095 , @hoy 
 wrote:

> In D93747#2481073 , 
> @dblaikie wrote:
>
>> Suggesting that gdb isn't using the DW_AT_name at all for "break 
>> " but instead demangling and stripping off the extras 
>> from the linkage name, and since it can't demangle this uniquified 
>> name (unlike the mangled name used when using the overloadable 
>> attribute) that degrades the debugger user experience? I'd have to 
>> test that in more detail/with some hand-hacked DWARF.
>
> Yes, I think in your case the linage name can be demangled by the 
> debugger. In my previous experiment, the uniquefied names could not 
> be demangled therefore I was not able to breakpoint.

 Ah, did some more testing. Seems it's because it isn't a classically 
 mangled name.
>>
>> The simplest fix I can think of is to emit the base 10 number of the 
>> md5hash.  That would preserve all the existing uniqueness and be 
>> demangler friendly.  @hoy @dblaikie  WDYT?
>
> I think using the base 10 form of md5hash is a smart workaround. Thanks 
> for the suggestion.

 Sure - wouldn't mind having some wording from the Itanium ABI/mangling 
 rules that explain/corroborate what we've seen from testing to ensure we 
 are using it correctly and there aren't any other ways that might be more 
 suitable, or lurking gotchas we haven't tested.
>>>
>>> Yes, makes sense. Also, like @dblaikie  pointed out in D94154 
>>>  it is now important that we don't 
>>> generate the DW_AT_linkage_name for C style names using this suffix as it 
>>> will not demangle.  I think this makes it important that we only update 
>>> this field if it already exists.
>>
>> Yes, it makes sense to do the renaming only if the linkage name preexists to 
>> not break the debuggability. Unfortunately we won't be able to support C 
>> with this patch.
>
> There is nothing needed to support C right?  overloadable attribute will 
> mangle with _Z so it will work as expected?  What did I miss?

I mean from the AutoFDO point of view, C programs with static functions are not 
getting the unique debug name support.

 It might be possible for this uniquifying step to check if the name is 
 mangled (does it start with "_Z") and if it isn't mangled, it could 
 mangle it (check the length of the name, then "_Zv") and 
 add the unique suffix. That looks to me like it preserves the original 
 debugging behavior?

 (has the problem that we don't actually know the mangling scheme at 
 this point - we do know it up in clang (where it might be Itanium 
 mangling or Microsoft mangling), might point again to the possibility 
 this feature is more suitable to implement in the frontend rather than 
 a middle end pass. And also the 'v' in the mangling is 'void return 
 type', which is a lie - not sure if we could do something better there)
>
> Doing name unification in the frontend sounds like the ultimate solution 
> and since the frontend has all the knowledge about the name mangler. I 
> think for now we can go with the solution @tmsriram suggested, i.e., 
> using the base 10 form of md5 hash.

 Any general idea of how long "for now" would be? It doesn't seem like 
 putting this off is going to make things especially better & seems like 
 more bug fixes/changes/etc are being built around the solution as it is at 
 the moment. So I'd be hesitant to put off this kind of restructuring too 
 long.
>>
>> I'm not sure. It looks like implementation in the front end has more 
>> complexity as discussed in the other thread D94154 
>> .
>>
 I think it's pretty important that we don't break tradeoff 
 debuggability for profile accuracy. It'll make for a difficult 
 tradeoff for our/any users.
>>>
>>> Agreed, I didn't expect this.
>>>
 (side note: using the original 

[PATCH] D93747: Rename debug linkage name with -funique-internal-linkage-names

[Sriraman Tallam via Phabricator via cfe-commits]

tmsriram added a comment.

In D93747#2482726 , @hoy wrote:

> In D93747#2482519 , @tmsriram wrote:
>
>> In D93747#2481494 , @dblaikie wrote:
>>
>>> In D93747#2481383 , @hoy wrote:
>>>
 In D93747#2481304 , @tmsriram 
 wrote:

> In D93747#2481223 , @tmsriram 
> wrote:
>
>> In D93747#2481163 , @dblaikie 
>> wrote:
>>
>>> In D93747#2481095 , @hoy wrote:
>>>
 In D93747#2481073 , @dblaikie 
 wrote:

> Suggesting that gdb isn't using the DW_AT_name at all for "break 
> " but instead demangling and stripping off the extras 
> from the linkage name, and since it can't demangle this uniquified 
> name (unlike the mangled name used when using the overloadable 
> attribute) that degrades the debugger user experience? I'd have to 
> test that in more detail/with some hand-hacked DWARF.

 Yes, I think in your case the linage name can be demangled by the 
 debugger. In my previous experiment, the uniquefied names could not be 
 demangled therefore I was not able to breakpoint.
>>>
>>> Ah, did some more testing. Seems it's because it isn't a classically 
>>> mangled name.
>
> The simplest fix I can think of is to emit the base 10 number of the 
> md5hash.  That would preserve all the existing uniqueness and be 
> demangler friendly.  @hoy @dblaikie  WDYT?

 I think using the base 10 form of md5hash is a smart workaround. Thanks 
 for the suggestion.
>>>
>>> Sure - wouldn't mind having some wording from the Itanium ABI/mangling 
>>> rules that explain/corroborate what we've seen from testing to ensure we 
>>> are using it correctly and there aren't any other ways that might be more 
>>> suitable, or lurking gotchas we haven't tested.
>>
>> Yes, makes sense. Also, like @dblaikie  pointed out in D94154 
>>  it is now important that we don't generate 
>> the DW_AT_linkage_name for C style names using this suffix as it will not 
>> demangle.  I think this makes it important that we only update this field if 
>> it already exists.
>
> Yes, it makes sense to do the renaming only if the linkage name preexists to 
> not break the debuggability. Unfortunately we won't be able to support C with 
> this patch.

There is nothing needed to support C right?  overloadable attribute will mangle 
with _Z so it will work as expected?  What did I miss?

>>> It might be possible for this uniquifying step to check if the name is 
>>> mangled (does it start with "_Z") and if it isn't mangled, it could 
>>> mangle it (check the length of the name, then "_Zv") and 
>>> add the unique suffix. That looks to me like it preserves the original 
>>> debugging behavior?
>>>
>>> (has the problem that we don't actually know the mangling scheme at 
>>> this point - we do know it up in clang (where it might be Itanium 
>>> mangling or Microsoft mangling), might point again to the possibility 
>>> this feature is more suitable to implement in the frontend rather than 
>>> a middle end pass. And also the 'v' in the mangling is 'void return 
>>> type', which is a lie - not sure if we could do something better there)

 Doing name unification in the frontend sounds like the ultimate solution 
 and since the frontend has all the knowledge about the name mangler. I 
 think for now we can go with the solution @tmsriram suggested, i.e., using 
 the base 10 form of md5 hash.
>>>
>>> Any general idea of how long "for now" would be? It doesn't seem like 
>>> putting this off is going to make things especially better & seems like 
>>> more bug fixes/changes/etc are being built around the solution as it is at 
>>> the moment. So I'd be hesitant to put off this kind of restructuring too 
>>> long.
>
> I'm not sure. It looks like implementation in the front end has more 
> complexity as discussed in the other thread D94154 
> .
>
>>> I think it's pretty important that we don't break tradeoff 
>>> debuggability for profile accuracy. It'll make for a difficult tradeoff 
>>> for our/any users.
>>
>> Agreed, I didn't expect this.
>>
>>> (side note: using the original source file name seems problematic - I 
>>> know in google at least, the same source file is sometimes built into 
>>> more than one library/form with different preprocessor defines, so this 
>>> may not produce as unique a name as you are expecting?)
>>
>> It was a best effort and I 

[PATCH] D93747: Rename debug linkage name with -funique-internal-linkage-names

[Hongtao Yu via Phabricator via cfe-commits]

hoy updated this revision to Diff 314955.
hoy added a comment.

Renaming debug linkage name if it preexisits.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93747

Files:
  llvm/include/llvm/IR/DebugInfoMetadata.h
  llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
  llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll

Index: llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll
===
--- llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll
+++ llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll
@@ -3,8 +3,10 @@
 ; RUN: opt -S -passes='default' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O2 --check-prefix=UNIQUE
 ; RUN: opt -S -passes='thinlto-pre-link' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O2 --check-prefix=UNIQUE
 ; RUN: opt -S -passes='thinlto-pre-link' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O2 --check-prefix=UNIQUE
+; RUN: opt -S -passes=unique-internal-linkage-names -unqiue-debug-linkage-names=0 < %s -o - | FileCheck %s --check-prefix=NODBG
+; RUN: opt -S -passes=unique-internal-linkage-names < %s -o - | FileCheck %s --check-prefix=DBG
 
-define internal i32 @foo() {
+define internal i32 @foo() !dbg !15 {
 entry:
   ret i32 0
 }
@@ -14,6 +16,27 @@
   ret i32 (...)* bitcast (i32 ()* @foo to i32 (...)*)
 }
 
+define internal i32 @go() !dbg !19 {
+entry:
+  ret i32 0
+}
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!3, !4, !5}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, enums: !2)
+!1 = !DIFile(filename: "test.c", directory: "")
+!2 = !{}
+!3 = !{i32 7, !"Dwarf Version", i32 4}
+!4 = !{i32 2, !"Debug Info Version", i32 3}
+!5 = !{i32 1, !"wchar_size", i32 4}
+!13 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!15 = distinct !DISubprogram(name: "foo", linkageName: "foo", scope: !1, file: !1, line: 5, type: !16, scopeLine: 5, spFlags: DISPFlagLocalToUnit | DISPFlagDefinition, unit: !0, declaration: !18, retainedNodes: !2)
+!16 = !DISubroutineType(types: !17)
+!17 = !{!13}
+!18 = !DISubprogram(name: "foo", linkageName: "foo", scope: !1, isDefinition: false, flags: DIFlagPrototyped, spFlags: DISPFlagOptimized)
+!19 = distinct !DISubprogram(name: "go", scope: !1, file: !1, line: 5, type: !16, scopeLine: 5, spFlags: DISPFlagLocalToUnit | DISPFlagDefinition, unit: !0, declaration: !18, retainedNodes: !2)
+
 ; O0: Running pass: UniqueInternalLinkageNamesPass
 
 ;; Check UniqueInternalLinkageNamesPass is scheduled before SampleProfileProbePass.
@@ -22,3 +45,11 @@
 
 ; UNIQUE: define internal i32 @foo.__uniq.{{[0-9a-f]+}}()
 ; UNIQUE: ret {{.*}} @foo.__uniq.{{[0-9a-f]+}} {{.*}}
+
+; NODBG: distinct !DISubprogram(name: "foo", linkageName: "foo", scope: ![[#]]
+; NODBG: !DISubprogram(name: "foo", linkageName: "foo", scope: ![[#]]
+; NODBG: distinct !DISubprogram(name: "go", scope: ![[#]]
+
+; DBG: distinct !DISubprogram(name: "foo", linkageName: "foo.__uniq.{{[0-9a-f]+}}", scope: ![[#]]
+; DBG: !DISubprogram(name: "foo", linkageName: "foo.__uniq.{{[0-9a-f]+}}", scope: ![[#]]
+; DBG: distinct !DISubprogram(name: "go", scope: ![[#]]
Index: llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
===
--- llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
+++ llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
@@ -13,13 +13,21 @@
 
 #include "llvm/Transforms/Utils/UniqueInternalLinkageNames.h"
 #include "llvm/ADT/SmallString.h"
+#include "llvm/IR/DebugInfoMetadata.h"
+#include "llvm/IR/MDBuilder.h"
 #include "llvm/IR/Module.h"
 #include "llvm/InitializePasses.h"
+#include "llvm/Support/CommandLine.h"
 #include "llvm/Support/MD5.h"
 #include "llvm/Transforms/Utils/ModuleUtils.h"
 
 using namespace llvm;
 
+static cl::opt
+UniqueDebugLinakgeNames("unqiue-debug-linkage-names", cl::init(true),
+cl::Hidden,
+cl::desc("Uniqueify debug linkage Names"));
+
 static bool uniqueifyInternalLinkageNames(Module ) {
   llvm::MD5 Md5;
   Md5.update(M.getSourceFileName());
@@ -31,11 +39,25 @@
   // this symbol is of internal linkage type.
   std::string ModuleNameHash = (Twine(".__uniq.") + Twine(Str)).str();
   bool Changed = false;
+  MDBuilder MDB(M.getContext());
 
   // Append the module hash to all internal linkage functions.
   for (auto  : M) {
 if (F.hasInternalLinkage()) {
   F.setName(F.getName() + ModuleNameHash);
+  // Replace linkage names in the debug metadata.
+  if (UniqueDebugLinakgeNames) {
+if (DISubprogram *SP = 

[PATCH] D93747: Rename debug linkage name with -funique-internal-linkage-names

[Hongtao Yu via Phabricator via cfe-commits]

hoy added a comment.

In D93747#2482519 , @tmsriram wrote:

> In D93747#2481494 , @dblaikie wrote:
>
>> In D93747#2481383 , @hoy wrote:
>>
>>> In D93747#2481304 , @tmsriram 
>>> wrote:
>>>
 In D93747#2481223 , @tmsriram 
 wrote:

> In D93747#2481163 , @dblaikie 
> wrote:
>
>> In D93747#2481095 , @hoy wrote:
>>
>>> In D93747#2481073 , @dblaikie 
>>> wrote:
>>>
 Suggesting that gdb isn't using the DW_AT_name at all for "break 
 " but instead demangling and stripping off the extras 
 from the linkage name, and since it can't demangle this uniquified 
 name (unlike the mangled name used when using the overloadable 
 attribute) that degrades the debugger user experience? I'd have to 
 test that in more detail/with some hand-hacked DWARF.
>>>
>>> Yes, I think in your case the linage name can be demangled by the 
>>> debugger. In my previous experiment, the uniquefied names could not be 
>>> demangled therefore I was not able to breakpoint.
>>
>> Ah, did some more testing. Seems it's because it isn't a classically 
>> mangled name.

 The simplest fix I can think of is to emit the base 10 number of the 
 md5hash.  That would preserve all the existing uniqueness and be demangler 
 friendly.  @hoy @dblaikie  WDYT?
>>>
>>> I think using the base 10 form of md5hash is a smart workaround. Thanks for 
>>> the suggestion.
>>
>> Sure - wouldn't mind having some wording from the Itanium ABI/mangling rules 
>> that explain/corroborate what we've seen from testing to ensure we are using 
>> it correctly and there aren't any other ways that might be more suitable, or 
>> lurking gotchas we haven't tested.
>
> Yes, makes sense. Also, like @dblaikie  pointed out in D94154 
>  it is now important that we don't generate 
> the DW_AT_linkage_name for C style names using this suffix as it will not 
> demangle.  I think this makes it important that we only update this field if 
> it already exists.

Yes, it makes sense to do the renaming only if the linkage name preexists to 
not break the debuggability. Unfortunately we won't be able to support C with 
this patch.

>> It might be possible for this uniquifying step to check if the name is 
>> mangled (does it start with "_Z") and if it isn't mangled, it could 
>> mangle it (check the length of the name, then "_Zv") and 
>> add the unique suffix. That looks to me like it preserves the original 
>> debugging behavior?
>>
>> (has the problem that we don't actually know the mangling scheme at this 
>> point - we do know it up in clang (where it might be Itanium mangling or 
>> Microsoft mangling), might point again to the possibility this feature 
>> is more suitable to implement in the frontend rather than a middle end 
>> pass. And also the 'v' in the mangling is 'void return type', which is a 
>> lie - not sure if we could do something better there)
>>>
>>> Doing name unification in the frontend sounds like the ultimate solution 
>>> and since the frontend has all the knowledge about the name mangler. I 
>>> think for now we can go with the solution @tmsriram suggested, i.e., using 
>>> the base 10 form of md5 hash.
>>
>> Any general idea of how long "for now" would be? It doesn't seem like 
>> putting this off is going to make things especially better & seems like more 
>> bug fixes/changes/etc are being built around the solution as it is at the 
>> moment. So I'd be hesitant to put off this kind of restructuring too long.

I'm not sure. It looks like implementation in the front end has more complexity 
as discussed in the other thread D94154 .

>> I think it's pretty important that we don't break tradeoff debuggability 
>> for profile accuracy. It'll make for a difficult tradeoff for our/any 
>> users.
>
> Agreed, I didn't expect this.
>
>> (side note: using the original source file name seems problematic - I 
>> know in google at least, the same source file is sometimes built into 
>> more than one library/form with different preprocessor defines, so this 
>> may not produce as unique a name as you are expecting?)
>
> It was a best effort and I think the hashing can be improved by using 
> more signals other than just the module name if needed.  For hard data 
> though, this does significantly improve performance which clearly comes 
> from better profile attribution so it does something.
>>
>> I'm OK with the idea that this helped the situation - but it 

[PATCH] D94186: [FPEnv][PowerPC] Platform builtins edition: clang should get from the AST the metadata for constrained FP builtins

[Kevin P. Neal via Phabricator via cfe-commits]

kpn created this revision.
kpn added reviewers: steven.zhang, nemanjai.
kpn added a project: clang.
Herald added subscribers: shchenz, kbarton.
kpn requested review of this revision.
Herald added a subscriber: cfe-commits.

Currently clang is not correctly retrieving from the AST the metadata for 
constrained FP builtins. This patch fixes that for the PowerPC specific 
builtins.

For previous work in this vein see D92122  for 
example.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D94186

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-ppc-fma.c
  clang/test/CodeGen/builtins-ppc-fpconstrained.c

Index: clang/test/CodeGen/builtins-ppc-fpconstrained.c
===
--- clang/test/CodeGen/builtins-ppc-fpconstrained.c
+++ clang/test/CodeGen/builtins-ppc-fpconstrained.c
@@ -2,16 +2,23 @@
 // RUN: %clang_cc1 -triple powerpc64le-gnu-linux -target-feature +vsx \
 // RUN: -emit-llvm %s -o - | FileCheck --check-prefix=CHECK-UNCONSTRAINED %s
 // RUN: %clang_cc1 -triple powerpc64le-gnu-linux -target-feature +vsx \
-// RUN:  -ffp-exception-behavior=strict -emit-llvm %s -o - | FileCheck \
-// RUN: --check-prefix=CHECK-CONSTRAINED -vv %s
+// RUN:  -ffp-exception-behavior=maytrap -DSTRICT=1 -emit-llvm %s -o - | \
+// RUN: FileCheck --check-prefix=CHECK-CONSTRAINED -vv %s
 // RUN: %clang_cc1 -triple powerpc64le-gnu-linux -target-feature +vsx \
 // RUN: -fallow-half-arguments-and-returns -S -o - %s | \
 // RUN: FileCheck --check-prefix=CHECK-ASM --check-prefix=NOT-FIXME-CHECK  %s
 // RUN: %clang_cc1 -triple powerpc64le-gnu-linux -target-feature +vsx \
-// RUN: -fallow-half-arguments-and-returns -S -ffp-exception-behavior=strict \
-// RUN: -o - %s | FileCheck --check-prefix=CHECK-ASM \
+// RUN: -fallow-half-arguments-and-returns -S -ffp-exception-behavior=maytrap \
+// RUN: -DSTRICT=1 -o - %s | FileCheck --check-prefix=CHECK-ASM \
 // RUN: --check-prefix=FIXME-CHECK  %s
 
+#ifdef STRICT
+// Test that the constrained intrinsics are picking up the exception
+// metadata from the AST instead of the global default from the command line.
+
+#pragma float_control(except, on)
+#endif
+
 typedef __attribute__((vector_size(4 * sizeof(float float vec_float;
 typedef __attribute__((vector_size(2 * sizeof(double double vec_double;
 
Index: clang/test/CodeGen/builtins-ppc-fma.c
===
--- clang/test/CodeGen/builtins-ppc-fma.c
+++ clang/test/CodeGen/builtins-ppc-fma.c
@@ -1,6 +1,17 @@
 // RUN: %clang_cc1 -triple powerpc64le-gnu-linux \
-// RUN: -target-feature +altivec -Wall -Wno-unused -Werror -emit-llvm %s -o - | FileCheck  \
+// RUN: -target-feature +altivec -Wall -Wno-unused -Werror -emit-llvm %s -o - | FileCheck --check-prefix=NOSTRICT --check-prefix=SHARED\
 // RUN: %s
+// RUN: %clang_cc1 -triple powerpc64le-gnu-linux \
+// RUN: -ffp-exception-behavior=maytrap -DSTRICT=1 \
+// RUN: -target-feature +altivec -Wall -Wno-unused -Werror -emit-llvm %s -o - | FileCheck --check-prefix=STRICT --check-prefix=SHARED\
+// RUN: %s
+
+#ifdef STRICT
+// Test that the constrained intrinsics are picking up the exception
+// metadata from the AST instead of the global default from the command line.
+
+#pragma float_control(except, on)
+#endif
 
 typedef __attribute__((vector_size(4 * sizeof(float float vec_float;
 typedef __attribute__((vector_size(2 * sizeof(double double vec_double;
@@ -10,34 +21,42 @@
 
 void test_fma(void) {
   vf = __builtin_vsx_xvmaddasp(vf, vf, vf);
-  // CHECK: @llvm.fma.v4f32(<4 x float> %{{.*}}, <4 x float> %{{.*}}, <4 x float> %{{.*}})
+  // NOSTRICT: @llvm.fma.v4f32(<4 x float> %{{.*}}, <4 x float> %{{.*}}, <4 x float> %{{.*}})
+  // STRICT: @llvm.experimental.constrained.fma.v4f32(<4 x float> %{{.*}}, <4 x float> %{{.*}}, <4 x float> %{{.*}}, metadata !"round.tonearest", metadata !"fpexcept.strict")
 
   vd = __builtin_vsx_xvmaddadp(vd, vd, vd);
-  // CHECK: @llvm.fma.v2f64(<2 x double> %{{.*}}, <2 x double> %{{.*}}, <2 x double> %{{.*}})
+  // NOSTRICT: @llvm.fma.v2f64(<2 x double> %{{.*}}, <2 x double> %{{.*}}, <2 x double> %{{.*}})
+  // STRICT: @llvm.experimental.constrained.fma.v2f64(<2 x double> %{{.*}}, <2 x double> %{{.*}}, <2 x double> %{{.*}}, metadata !"round.tonearest", metadata !"fpexcept.strict")
 
   vf = __builtin_vsx_xvnmaddasp(vf, vf, vf);
-  // CHECK: [[RESULT:%[^ ]+]] = call <4 x float> @llvm.fma.v4f32(<4 x float> %{{.*}}, <4 x float> %{{.*}}, <4 x float> %{{.*}})
-  // CHECK: fneg <4 x float> [[RESULT]]
+  // NOSTRICT: [[RESULT:%[^ ]+]] = call <4 x float> @llvm.fma.v4f32(<4 x float> %{{.*}}, <4 x float> %{{.*}}, <4 x float> %{{.*}})
+  // STRICT: [[RESULT:%[^ ]+]] = call <4 x float> @llvm.experimental.constrained.fma.v4f32(<4 x float> %{{.*}}, <4 x float> %{{.*}}, <4 x float> %{{.*}}, metadata !"round.tonearest", metadata !"fpexcept.strict")
+  // SHARED: fneg <4 x float> [[RESULT]]
 

[PATCH] D94185: [OpenMP][Docs] Mark finished features as done

[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


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94185

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

[PATCH] D93587: [hip] Fix HIP version parsing.

[Artem Belevich via Phabricator via cfe-commits]

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

LGTM overall.




Comment at: clang/lib/Driver/ToolChains/AMDGPU.cpp:92
+// Parse and extract version numbers from `.hipVersion`. Return `true` if
+// the parsing fails.
+bool RocmInstallationDetector::parseHIPVersionFile(llvm::StringRef V) {

It still does not desribe what we expect to see in that file.
E.g.:
```
HIP_VERSION_MAJOR=1
HIP_VERSION_MINOR=2
HIP_VERSION_PATCH=3
```



Comment at: clang/lib/Driver/ToolChains/AMDGPU.cpp:100
+auto Splits = Part.rtrim().split('=');
+if (Splits.first == "HIP_VERSION_MAJOR") {
+  if (Splits.second.getAsInteger(0, Major))

Perhaps we could use StringSwitch here:

```
  int  = llvm::StringSwitch(Splits.first)
  .Case("HIP_VERSION_MAJOR", Major)
  .Case("HIP_VERSION_MINOR", Minor)
  .Case("HIP_VERSION_PATCH", VersionPatch)
  if (Splits.second.getAsInteger(0, Value))
return true;
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93587

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

[PATCH] D93668: [clang] Add -ffuchsia-c++-abi flag to explicitly use the Fuchsia C++ ABI

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

Generally makes sense, but I had a concern.




Comment at: clang/include/clang/Basic/LangOptions.h:333
+  /// the -ffuchsia-c++-abi flag.
+  bool UseFuchsiaCXXABI;
+

Why isn't this part of the LangOptions.def xmacro list?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93668

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

[PATCH] D93428: [AArch64] Add bti note property when compiling asm files with -mbranch-protection=bti

[Ana Pazos via Phabricator via cfe-commits]

apazos added a comment.

Can you confirm when the GNU toolchain will have this flag supported in their 
assembler? Compatibility between LLVM and GNU toolchains is important.

Stephen - I think we can abandon this review. Users will need to be made aware 
of this additional assembler flag when building .s files with BTI enabled.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93428

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

[PATCH] D94185: [OpenMP][Docs] Mark finished features as done

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert created this revision.
jdoerfert added a reviewer: ABataev.
Herald added subscribers: guansong, bollu, yaxunl.
jdoerfert requested review of this revision.
Herald added subscribers: cfe-commits, sstefan1.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D94185

Files:
  clang/docs/OpenMPSupport.rst


Index: clang/docs/OpenMPSupport.rst
===
--- clang/docs/OpenMPSupport.rst
+++ clang/docs/OpenMPSupport.rst
@@ -193,7 +193,7 @@
 
+--+--+--+---+
 | device extension | implicitly map 'this' (this[:1])  
   | :good:`done` | D55982  
  |
 
+--+--+--+---+
-| device extension | allow access to the reference count 
(omp_target_is_present)  | :part:`worked on`|   
|
+| device extension | allow access to the reference count 
(omp_target_is_present)  | :part:`done` |   
|
 
+--+--+--+---+
 | device extension | requires directive
   | :part:`partial`  | 
  |
 
+--+--+--+---+
@@ -215,7 +215,7 @@
 
+--+--+--+---+
 | device extension | support close modifier on map clause  
   | :good:`done` | D55719,D55892   
  |
 
+--+--+--+---+
-| device extension | teams construct on the host device
   | :part:`worked on`| Clang part is done, r371553.
  |
+| device extension | teams construct on the host device
   | :part:`done` | r371553 
  |
 
+--+--+--+---+
 | device extension | support non-contiguous array sections for 
target update  | :good:`done` | 
  |
 
+--+--+--+---+


Index: clang/docs/OpenMPSupport.rst
===
--- clang/docs/OpenMPSupport.rst
+++ clang/docs/OpenMPSupport.rst
@@ -193,7 +193,7 @@
 +--+--+--+---+
 | device extension | implicitly map 'this' (this[:1]) | :good:`done` | D55982|
 +--+--+--+---+
-| device extension | allow access to the reference count (omp_target_is_present)  | :part:`worked on`|   |
+| device extension | allow access to the reference count (omp_target_is_present)  | :part:`done` |   |
 

[PATCH] D93638: [hip] Enable HIP compilation with ` on MSVC.

[Artem Belevich via Phabricator via cfe-commits]

tra added inline comments.



Comment at: clang/lib/Headers/__clang_hip_runtime_wrapper.h:73-74
+#define __HOST_DEVICE__
\
+  static __host__ __device__ inline __attribute__((always_inline))
+__HOST_DEVICE__ double _Cosh(double x, double y) { return cosh(x) * y; }
+__HOST_DEVICE__ float _FCosh(float x, float y) { return coshf(x) * y; }

hliao wrote:
> tra wrote:
> > I don't think we want to provide a HD implementation.
> > This will potentially change the meaning of these functions on the host 
> > side vs what they do in a C++ compilation.
> > It should probably be just `__device__`.
> > 
> > Next question is -- do we want to provide the definitions, or would just 
> > declarations be sufficient?
> > In other words -- are these functions needed for some standard C++ library 
> > functionality that we expect to work on the GPU?
> > If it's just to aid with overload resolution, declarations should do. 
> > 
> These functions are declared in ymath.h and, in the host compilation, are 
> resolved by linking MSVC RT libraries. For the device function, as we already 
> mark all prototypes in ymath.h as HD, we have to implement them as HD to 
> match the declaration. But, those definitions should be only available in the 
> device compilation to avoid conflicts in the host compilation.
You don't need the definitions to avoid conflicting declarations.

I'm still not convinced that HD is needed.
Did you try just making these declarations `__device__` and remove the 
`ymath.h` wrapper?
Basically I'm trying to find the bare minimum we need to do to make it work.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93638

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

[PATCH] D94123: [NVPTX] Fix debugging information being added to NVPTX target if remarks are enabled

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a comment.

In D94123#2482636 , @MaskRay wrote:

> If you use `arc diff`, you can obtain `Reviewed-by:` line from Phabricator. 
> It is more useful than `Reviewers: ` (a list of reviewers do not mean they 
> endorse or accept the patch)

`arc land`  did work, now it is `arc land --onto main`, but it does these 
things for you. I like it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94123

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

[PATCH] D94123: [NVPTX] Fix debugging information being added to NVPTX target if remarks are enabled

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

If you use `arc diff`, you can obtain `Reviewed-by:` line from Phabricator. It 
is more useful than `Reviewers: `


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94123

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

[PATCH] D93638: [hip] Enable HIP compilation with ` on MSVC.

[Michael Liao via Phabricator via cfe-commits]

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



Comment at: clang/lib/Headers/__clang_hip_runtime_wrapper.h:73-74
+#define __HOST_DEVICE__
\
+  static __host__ __device__ inline __attribute__((always_inline))
+__HOST_DEVICE__ double _Cosh(double x, double y) { return cosh(x) * y; }
+__HOST_DEVICE__ float _FCosh(float x, float y) { return coshf(x) * y; }

tra wrote:
> I don't think we want to provide a HD implementation.
> This will potentially change the meaning of these functions on the host side 
> vs what they do in a C++ compilation.
> It should probably be just `__device__`.
> 
> Next question is -- do we want to provide the definitions, or would just 
> declarations be sufficient?
> In other words -- are these functions needed for some standard C++ library 
> functionality that we expect to work on the GPU?
> If it's just to aid with overload resolution, declarations should do. 
> 
These functions are declared in ymath.h and, in the host compilation, are 
resolved by linking MSVC RT libraries. For the device function, as we already 
mark all prototypes in ymath.h as HD, we have to implement them as HD to match 
the declaration. But, those definitions should be only available in the device 
compilation to avoid conflicts in the host compilation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93638

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

[PATCH] D93638: [hip] Enable HIP compilation with ` on MSVC.

[Michael Liao via Phabricator via cfe-commits]

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

Only mark HD attributes in ymath.h wrapper header when compiled with MSVC.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93638

Files:
  clang/lib/Headers/CMakeLists.txt
  clang/lib/Headers/__clang_hip_runtime_wrapper.h
  clang/lib/Headers/cuda_wrappers/ymath.h


Index: clang/lib/Headers/cuda_wrappers/ymath.h
===
--- /dev/null
+++ clang/lib/Headers/cuda_wrappers/ymath.h
@@ -0,0 +1,28 @@
+/*=== ymath.h - HIP wrapper for  --===
+ *
+ * Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+ * See https://llvm.org/LICENSE.txt for license information.
+ * SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+ *
+ *===---===
+ */
+
+#ifndef __CLANG_CUDA_WRAPPERS_YMATH_H
+#define __CLANG_CUDA_WRAPPERS_YMATH_H
+
+// Wrapper around  that forces its functions to be __host__
+// __device__.
+
+// Only mark HD when compiled with MSVC as `ymath.h` may be an ordinary user
+// header.
+#if defined(_MSC_VER)
+#pragma clang force_cuda_host_device begin
+#endif // defined(_MSC_VER)
+
+#include_next 
+
+#if defined(_MSC_VER)
+#pragma clang force_cuda_host_device end
+#endif // defined(_MSC_VER)
+
+#endif // include guard
Index: clang/lib/Headers/__clang_hip_runtime_wrapper.h
===
--- clang/lib/Headers/__clang_hip_runtime_wrapper.h
+++ clang/lib/Headers/__clang_hip_runtime_wrapper.h
@@ -61,6 +61,28 @@
 #include 
 #include 
 #include 
+
+// Define math functions from  on MSVC for the device compilation
+// only to avoid conflicts with MSVC runtime in the host compilation.
+#if defined(_MSC_VER) && defined(__HIP_DEVICE_COMPILE__)
+#if defined(__cplusplus)
+extern "C" {
+#endif // defined(__cplusplus)
+#pragma push_macro("__HOST_DEVICE__")
+#define __HOST_DEVICE__
\
+  static __host__ __device__ inline __attribute__((always_inline))
+__HOST_DEVICE__ double _Cosh(double x, double y) { return cosh(x) * y; }
+__HOST_DEVICE__ float _FCosh(float x, float y) { return coshf(x) * y; }
+__HOST_DEVICE__ short _Dtest(double *p) { return fpclassify(*p); }
+__HOST_DEVICE__ short _FDtest(float *p) { return fpclassify(*p); }
+__HOST_DEVICE__ double _Sinh(double x, double y) { return sinh(x) * y; }
+__HOST_DEVICE__ float _FSinh(float x, float y) { return sinhf(x) * y; }
+#pragma pop_macro("__HOST_DEVICE__")
+#if defined(__cplusplus)
+}
+#endif // defined(__cplusplus)
+#endif // defined(_MSC_VER) && defined(__HIP_DEVICE_COMPILE__)
+
 #endif // !_OPENMP || __HIP_ENABLE_CUDA_WRAPPER_FOR_OPENMP__
 
 #define __CLANG_HIP_RUNTIME_WRAPPER_INCLUDED__ 1
Index: clang/lib/Headers/CMakeLists.txt
===
--- clang/lib/Headers/CMakeLists.txt
+++ clang/lib/Headers/CMakeLists.txt
@@ -142,6 +142,7 @@
   cuda_wrappers/algorithm
   cuda_wrappers/complex
   cuda_wrappers/new
+  cuda_wrappers/ymath.h
 )
 
 set(ppc_wrapper_files


Index: clang/lib/Headers/cuda_wrappers/ymath.h
===
--- /dev/null
+++ clang/lib/Headers/cuda_wrappers/ymath.h
@@ -0,0 +1,28 @@
+/*=== ymath.h - HIP wrapper for  --===
+ *
+ * Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+ * See https://llvm.org/LICENSE.txt for license information.
+ * SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+ *
+ *===---===
+ */
+
+#ifndef __CLANG_CUDA_WRAPPERS_YMATH_H
+#define __CLANG_CUDA_WRAPPERS_YMATH_H
+
+// Wrapper around  that forces its functions to be __host__
+// __device__.
+
+// Only mark HD when compiled with MSVC as `ymath.h` may be an ordinary user
+// header.
+#if defined(_MSC_VER)
+#pragma clang force_cuda_host_device begin
+#endif // defined(_MSC_VER)
+
+#include_next 
+
+#if defined(_MSC_VER)
+#pragma clang force_cuda_host_device end
+#endif // defined(_MSC_VER)
+
+#endif // include guard
Index: clang/lib/Headers/__clang_hip_runtime_wrapper.h
===
--- clang/lib/Headers/__clang_hip_runtime_wrapper.h
+++ clang/lib/Headers/__clang_hip_runtime_wrapper.h
@@ -61,6 +61,28 @@
 #include 
 #include 
 #include 
+
+// Define math functions from  on MSVC for the device compilation
+// only to avoid conflicts with MSVC runtime in the host compilation.
+#if defined(_MSC_VER) && defined(__HIP_DEVICE_COMPILE__)
+#if defined(__cplusplus)
+extern "C" {
+#endif // defined(__cplusplus)
+#pragma push_macro("__HOST_DEVICE__")
+#define __HOST_DEVICE__\
+  static __host__ __device__ 

[PATCH] D94123: [NVPTX] Fix debugging information being added to NVPTX target if remarks are enabled

[Joseph Huber via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG1ca5e68aa07e: [NVPTX] Fix debugging information being added 
to NVPTX target if remarks are… (authored by jhuber6).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94123

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


Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -384,7 +384,7 @@
 }
 return IsDebugEnabled ? EmitSameDebugInfoAsHost : DebugDirectivesOnly;
   }
-  return DisableDebugInfo;
+  return willEmitRemarks(Args) ? DebugDirectivesOnly : DisableDebugInfo;
 }
 
 void NVPTX::Assembler::ConstructJob(Compilation , const JobAction ,
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -3940,14 +3940,14 @@
 CmdArgs.push_back("-gno-inline-line-tables");
   }
 
-  // Adjust the debug info kind for the given toolchain.
-  TC.adjustDebugInfoKind(DebugInfoKind, Args);
-
   // When emitting remarks, we need at least debug lines in the output.
   if (willEmitRemarks(Args) &&
   DebugInfoKind <= codegenoptions::DebugDirectivesOnly)
 DebugInfoKind = codegenoptions::DebugLineTablesOnly;
 
+  // Adjust the debug info kind for the given toolchain.
+  TC.adjustDebugInfoKind(DebugInfoKind, Args);
+
   RenderDebugEnablingArgs(Args, CmdArgs, DebugInfoKind, EffectiveDWARFVersion,
   DebuggerTuning);
 


Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -384,7 +384,7 @@
 }
 return IsDebugEnabled ? EmitSameDebugInfoAsHost : DebugDirectivesOnly;
   }
-  return DisableDebugInfo;
+  return willEmitRemarks(Args) ? DebugDirectivesOnly : DisableDebugInfo;
 }
 
 void NVPTX::Assembler::ConstructJob(Compilation , const JobAction ,
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -3940,14 +3940,14 @@
 CmdArgs.push_back("-gno-inline-line-tables");
   }
 
-  // Adjust the debug info kind for the given toolchain.
-  TC.adjustDebugInfoKind(DebugInfoKind, Args);
-
   // When emitting remarks, we need at least debug lines in the output.
   if (willEmitRemarks(Args) &&
   DebugInfoKind <= codegenoptions::DebugDirectivesOnly)
 DebugInfoKind = codegenoptions::DebugLineTablesOnly;
 
+  // Adjust the debug info kind for the given toolchain.
+  TC.adjustDebugInfoKind(DebugInfoKind, Args);
+
   RenderDebugEnablingArgs(Args, CmdArgs, DebugInfoKind, EffectiveDWARFVersion,
   DebuggerTuning);
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 1ca5e68 - [NVPTX] Fix debugging information being added to NVPTX target if remarks are enabled

[via cfe-commits]

Author: Joseph Huber
Date: 2021-01-06T13:43:22-05:00
New Revision: 1ca5e68aa07e30567c6aa2409c5641e0a2d77355

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

LOG: [NVPTX] Fix debugging information being added to NVPTX target if remarks 
are enabled
Summary:
Optimized debugging is not supported by ptxas. Debugging information is 
degraded to line information only if optimizations are enabled, but debugging 
information would be added back in by the driver if remarks were enabled. This 
solves https://bugs.llvm.org/show_bug.cgi?id=48153.

Reviewers: jdoerfert tra jholewinski serge-sans-paille

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Driver/ToolChains/Cuda.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 917601836c0a..a462758bf1c2 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -3940,14 +3940,14 @@ static void RenderDebugOptions(const ToolChain , 
const Driver ,
 CmdArgs.push_back("-gno-inline-line-tables");
   }
 
-  // Adjust the debug info kind for the given toolchain.
-  TC.adjustDebugInfoKind(DebugInfoKind, Args);
-
   // When emitting remarks, we need at least debug lines in the output.
   if (willEmitRemarks(Args) &&
   DebugInfoKind <= codegenoptions::DebugDirectivesOnly)
 DebugInfoKind = codegenoptions::DebugLineTablesOnly;
 
+  // Adjust the debug info kind for the given toolchain.
+  TC.adjustDebugInfoKind(DebugInfoKind, Args);
+
   RenderDebugEnablingArgs(Args, CmdArgs, DebugInfoKind, EffectiveDWARFVersion,
   DebuggerTuning);
 

diff  --git a/clang/lib/Driver/ToolChains/Cuda.cpp 
b/clang/lib/Driver/ToolChains/Cuda.cpp
index 58178d5d11bc..95fd5a1fbfee 100644
--- a/clang/lib/Driver/ToolChains/Cuda.cpp
+++ b/clang/lib/Driver/ToolChains/Cuda.cpp
@@ -384,7 +384,7 @@ static DeviceDebugInfoLevel mustEmitDebugInfo(const ArgList 
) {
 }
 return IsDebugEnabled ? EmitSameDebugInfoAsHost : DebugDirectivesOnly;
   }
-  return DisableDebugInfo;
+  return willEmitRemarks(Args) ? DebugDirectivesOnly : DisableDebugInfo;
 }
 
 void NVPTX::Assembler::ConstructJob(Compilation , const JobAction ,



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

[PATCH] D93587: [hip] Fix HIP version parsing.

[Michael Liao via Phabricator via cfe-commits]

hliao updated this revision to Diff 314941.
hliao marked an inline comment as done.
hliao added a comment.

Revise following reviewers' comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93587

Files:
  clang/lib/Driver/ToolChains/AMDGPU.cpp
  clang/lib/Driver/ToolChains/ROCm.h
  clang/test/Driver/Inputs/rocm/bin/.hipVersion


Index: clang/test/Driver/Inputs/rocm/bin/.hipVersion
===
--- clang/test/Driver/Inputs/rocm/bin/.hipVersion
+++ clang/test/Driver/Inputs/rocm/bin/.hipVersion
@@ -1,4 +1,6 @@
 # Auto-generated by cmake
-HIP_VERSION_MAJOR=3
+# NOTE: The trailing whitespace is added on purpose to verify that these
+# whitespaces are trimmed before paring.
+HIP_VERSION_MAJOR=3 
 HIP_VERSION_MINOR=6
 HIP_VERSION_PATCH=20214-a2917cd
Index: clang/lib/Driver/ToolChains/ROCm.h
===
--- clang/lib/Driver/ToolChains/ROCm.h
+++ clang/lib/Driver/ToolChains/ROCm.h
@@ -103,7 +103,7 @@
   }
 
   void scanLibDevicePath(llvm::StringRef Path);
-  void ParseHIPVersionFile(llvm::StringRef V);
+  bool parseHIPVersionFile(llvm::StringRef V);
   SmallVector getInstallationPathCandidates();
 
 public:
Index: clang/lib/Driver/ToolChains/AMDGPU.cpp
===
--- clang/lib/Driver/ToolChains/AMDGPU.cpp
+++ clang/lib/Driver/ToolChains/AMDGPU.cpp
@@ -88,23 +88,30 @@
   }
 }
 
-void RocmInstallationDetector::ParseHIPVersionFile(llvm::StringRef V) {
+// Parse and extract version numbers from `.hipVersion`. Return `true` if
+// the parsing fails.
+bool RocmInstallationDetector::parseHIPVersionFile(llvm::StringRef V) {
   SmallVector VersionParts;
   V.split(VersionParts, '\n');
-  unsigned Major;
-  unsigned Minor;
+  unsigned Major = ~0U;
+  unsigned Minor = ~0U;
   for (auto Part : VersionParts) {
-auto Splits = Part.split('=');
-if (Splits.first == "HIP_VERSION_MAJOR")
-  Splits.second.getAsInteger(0, Major);
-else if (Splits.first == "HIP_VERSION_MINOR")
-  Splits.second.getAsInteger(0, Minor);
-else if (Splits.first == "HIP_VERSION_PATCH")
+auto Splits = Part.rtrim().split('=');
+if (Splits.first == "HIP_VERSION_MAJOR") {
+  if (Splits.second.getAsInteger(0, Major))
+return true;
+} else if (Splits.first == "HIP_VERSION_MINOR") {
+  if (Splits.second.getAsInteger(0, Minor))
+return true;
+} else if (Splits.first == "HIP_VERSION_PATCH")
   VersionPatch = Splits.second.str();
   }
+  if (Major == ~0U || Minor == ~0U)
+return true;
   VersionMajorMinor = llvm::VersionTuple(Major, Minor);
   DetectedVersion =
   (Twine(Major) + "." + Twine(Minor) + "." + VersionPatch).str();
+  return false;
 }
 
 // For candidate specified by --rocm-path we do not do strict check.
@@ -290,7 +297,8 @@
   continue;
 
 if (HIPVersionArg.empty() && VersionFile)
-  ParseHIPVersionFile((*VersionFile)->getBuffer());
+  if (parseHIPVersionFile((*VersionFile)->getBuffer()))
+continue;
 
 HasHIPRuntime = true;
 return;


Index: clang/test/Driver/Inputs/rocm/bin/.hipVersion
===
--- clang/test/Driver/Inputs/rocm/bin/.hipVersion
+++ clang/test/Driver/Inputs/rocm/bin/.hipVersion
@@ -1,4 +1,6 @@
 # Auto-generated by cmake
-HIP_VERSION_MAJOR=3
+# NOTE: The trailing whitespace is added on purpose to verify that these
+# whitespaces are trimmed before paring.
+HIP_VERSION_MAJOR=3 
 HIP_VERSION_MINOR=6
 HIP_VERSION_PATCH=20214-a2917cd
Index: clang/lib/Driver/ToolChains/ROCm.h
===
--- clang/lib/Driver/ToolChains/ROCm.h
+++ clang/lib/Driver/ToolChains/ROCm.h
@@ -103,7 +103,7 @@
   }
 
   void scanLibDevicePath(llvm::StringRef Path);
-  void ParseHIPVersionFile(llvm::StringRef V);
+  bool parseHIPVersionFile(llvm::StringRef V);
   SmallVector getInstallationPathCandidates();
 
 public:
Index: clang/lib/Driver/ToolChains/AMDGPU.cpp
===
--- clang/lib/Driver/ToolChains/AMDGPU.cpp
+++ clang/lib/Driver/ToolChains/AMDGPU.cpp
@@ -88,23 +88,30 @@
   }
 }
 
-void RocmInstallationDetector::ParseHIPVersionFile(llvm::StringRef V) {
+// Parse and extract version numbers from `.hipVersion`. Return `true` if
+// the parsing fails.
+bool RocmInstallationDetector::parseHIPVersionFile(llvm::StringRef V) {
   SmallVector VersionParts;
   V.split(VersionParts, '\n');
-  unsigned Major;
-  unsigned Minor;
+  unsigned Major = ~0U;
+  unsigned Minor = ~0U;
   for (auto Part : VersionParts) {
-auto Splits = Part.split('=');
-if (Splits.first == "HIP_VERSION_MAJOR")
-  Splits.second.getAsInteger(0, Major);
-else if (Splits.first == "HIP_VERSION_MINOR")
-  Splits.second.getAsInteger(0, Minor);
-else if 

[PATCH] D93587: [hip] Fix HIP version parsing.

[Michael Liao via Phabricator via cfe-commits]

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



Comment at: clang/lib/Driver/ToolChains/AMDGPU.cpp:97
   for (auto Part : VersionParts) {
 auto Splits = Part.split('=');
+if (Splits.first == "HIP_VERSION_MAJOR") {

tra wrote:
> `Part.trim().split()` (or, maybe, `rtrim()`if you only care about EOL) would 
> save you trimming in each individual case.
sure, as that file is auto-gen so far, we could simplify the unnecessary 
parsing so far. The EOL is the only issue so far.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93587

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

[PATCH] D94123: [NVPTX] Fix debugging information being added to NVPTX target if remarks are enabled

[Artem Belevich via Phabricator via cfe-commits]

tra accepted this revision.
tra 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/D94123/new/

https://reviews.llvm.org/D94123

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

[PATCH] D89490: Introduce __attribute__((darwin_abi))

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

I'm not calling Wine a niche use-case, I'm calling this feature a niche 
use-case.  The lack of this feature has not blocked Wine from being a 
successful project.  The feature has to stand on its own and be more broadly 
useful than the momentary convenience of a few developers.

Thinking about it some more, it might be much easier to hack LLVM IR output 
than assembly output.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89490

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

[PATCH] D93377: [Clang] Add __ibm128 type to represent ppc_fp128

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In D93377#2481957 , 
@hubert.reinterpretcast wrote:

> In D93377#2481312 , @rjmccall wrote:
>
>> Are you committed to the name `__ibm128`?
>
> Insofar as that's what GCC on Power (for example, `gcc (Ubuntu 
> 7.5.0-3ubuntu1~18.04) 7.5.0` from 2017) has shipped with for several years, 
> yes.

Okay, it wasn't clear from the description that this was an already-shipping 
type.  In that case, it's regrettable but obviously just something we have to 
match.


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

https://reviews.llvm.org/D93377

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

[PATCH] D93747: Rename debug linkage name with -funique-internal-linkage-names

[Sriraman Tallam via Phabricator via cfe-commits]

tmsriram added a comment.

In D93747#2481494 , @dblaikie wrote:

> In D93747#2481383 , @hoy wrote:
>
>> In D93747#2481304 , @tmsriram wrote:
>>
>>> In D93747#2481223 , @tmsriram 
>>> wrote:
>>>
 In D93747#2481163 , @dblaikie 
 wrote:

> In D93747#2481095 , @hoy wrote:
>
>> In D93747#2481073 , @dblaikie 
>> wrote:
>>
>>> Suggesting that gdb isn't using the DW_AT_name at all for "break 
>>> " but instead demangling and stripping off the extras 
>>> from the linkage name, and since it can't demangle this uniquified name 
>>> (unlike the mangled name used when using the overloadable attribute) 
>>> that degrades the debugger user experience? I'd have to test that in 
>>> more detail/with some hand-hacked DWARF.
>>
>> Yes, I think in your case the linage name can be demangled by the 
>> debugger. In my previous experiment, the uniquefied names could not be 
>> demangled therefore I was not able to breakpoint.
>
> Ah, did some more testing. Seems it's because it isn't a classically 
> mangled name.
>>>
>>> The simplest fix I can think of is to emit the base 10 number of the 
>>> md5hash.  That would preserve all the existing uniqueness and be demangler 
>>> friendly.  @hoy @dblaikie  WDYT?
>>
>> I think using the base 10 form of md5hash is a smart workaround. Thanks for 
>> the suggestion.
>
> Sure - wouldn't mind having some wording from the Itanium ABI/mangling rules 
> that explain/corroborate what we've seen from testing to ensure we are using 
> it correctly and there aren't any other ways that might be more suitable, or 
> lurking gotchas we haven't tested.

Yes, makes sense. Also, like @dblaikie  pointed out in D94154 
 it is now important that we don't generate 
the DW_AT_linkage_name for C style names using this suffix as it will not 
demangle.  I think this makes it important that we only update this field if it 
already exists.

> It might be possible for this uniquifying step to check if the name is 
> mangled (does it start with "_Z") and if it isn't mangled, it could 
> mangle it (check the length of the name, then "_Zv") and 
> add the unique suffix. That looks to me like it preserves the original 
> debugging behavior?
>
> (has the problem that we don't actually know the mangling scheme at this 
> point - we do know it up in clang (where it might be Itanium mangling or 
> Microsoft mangling), might point again to the possibility this feature is 
> more suitable to implement in the frontend rather than a middle end pass. 
> And also the 'v' in the mangling is 'void return type', which is a lie - 
> not sure if we could do something better there)
>>
>> Doing name unification in the frontend sounds like the ultimate solution and 
>> since the frontend has all the knowledge about the name mangler. I think for 
>> now we can go with the solution @tmsriram suggested, i.e., using the base 10 
>> form of md5 hash.
>
> Any general idea of how long "for now" would be? It doesn't seem like putting 
> this off is going to make things especially better & seems like more bug 
> fixes/changes/etc are being built around the solution as it is at the moment. 
> So I'd be hesitant to put off this kind of restructuring too long.
>
> I think it's pretty important that we don't break tradeoff debuggability 
> for profile accuracy. It'll make for a difficult tradeoff for our/any 
> users.

 Agreed, I didn't expect this.

> (side note: using the original source file name seems problematic - I 
> know in google at least, the same source file is sometimes built into 
> more than one library/form with different preprocessor defines, so this 
> may not produce as unique a name as you are expecting?)

 It was a best effort and I think the hashing can be improved by using more 
 signals other than just the module name if needed.  For hard data though, 
 this does significantly improve performance which clearly comes from 
 better profile attribution so it does something.
>
> I'm OK with the idea that this helped the situation - but it doesn't seem 
> very principled/rigorous. Rather than a sliding scale of "better" I think 
> it'd be worth considering in more detail what would be required to make this 
> correct.
>
> Using the object file name may be more robust - also not perfect for all 
> build systems (one could imagine a distributed build system that /might/ be 
> able to get away with having the distributed builders always build a file 
> named x.o - only to have the distribution system rename the file to its 
> 

[PATCH] D94092: [Clang] Remove unnecessary Attr.isArgIdent checks.

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In D94092#2481857 , @aaron.ballman 
wrote:

> In D94092#2481276 , @rjmccall wrote:
>
>> Without bothering to look it up, I would guess that the attribute-parsing 
>> code used to generically handle the ambiguity between identifier expressions 
>> and identifier attribute arguments by just always parsing simple identifiers 
>> as identifier arguments, making it Sema's responsibility to turn that back 
>> into an expression.  At some point, the parser was made sensitive to the 
>> actual attribute being parsed, but we never bothered to simplify Sema.  At 
>> any rate, the parser does now know exactly which argument of which attribute 
>> it's parsing, so there's zero reason for it to force this complexity on Sema 
>> anymore; if we find a case that parses identifier arguments, we should fix 
>> it in the parser to parse an expression instead.
>
> I don't think it will be quite that trivial (switching all identifiers to be 
> parsed as expressions instead). For instance, attributes that take 
> enumeration arguments can parse those arguments as identifiers, but those 
> identifiers will never be found by usual expression lookup because they don't 
> really exist. That said, any attribute that currently accepts an identifier 
> because it really wants to use that identifier in an expression in Sema 
> should update the attribute argument clauses in Attr.td and make the 
> corresponding changes in SemaDeclAttr.cpp/SemaStmt.cpp/SemaType.cpp as 
> appropriate.

You're exactly right about how it's necessary to parse certain attributes.  
Just to be clear, though, I'm not proposing any change here; I'm describing the 
change that already happened, years ago, by way of trying to identify why this 
particular bit of code was once necessary and thus why it's likely unnecessary 
now.  So I think you will find that those changes to Attr.td are in fact 
already in place.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94092

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

[PATCH] D94123: [NVPTX] Fix debugging information being added to NVPTX target if remarks are enabled

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a comment.

OK with me, @tra ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94123

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

[PATCH] D94092: [Clang] Remove unnecessary Attr.isArgIdent checks.

[Florian Hahn 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 rG7ef9139a391a: [Clang] Remove unnecessary Attr.isArgIdent 
checks. (authored by fhahn).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94092

Files:
  clang/lib/Sema/SemaType.cpp

Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -6434,25 +6434,7 @@
   return;
 }
 
-Expr *ASArgExpr;
-if (Attr.isArgIdent(0)) {
-  // Special case where the argument is a template id.
-  CXXScopeSpec SS;
-  SourceLocation TemplateKWLoc;
-  UnqualifiedId id;
-  id.setIdentifier(Attr.getArgAsIdent(0)->Ident, Attr.getLoc());
-
-  ExprResult AddrSpace = S.ActOnIdExpression(
-  S.getCurScope(), SS, TemplateKWLoc, id, /*HasTrailingLParen=*/false,
-  /*IsAddressOfOperand=*/false);
-  if (AddrSpace.isInvalid())
-return;
-
-  ASArgExpr = static_cast(AddrSpace.get());
-} else {
-  ASArgExpr = static_cast(Attr.getArgAsExpr(0));
-}
-
+Expr *ASArgExpr = static_cast(Attr.getArgAsExpr(0));
 LangAS ASIdx;
 if (!BuildAddressSpaceIndex(S, ASIdx, ASArgExpr, Attr.getLoc())) {
   Attr.setInvalid();
@@ -7658,25 +7640,7 @@
 return;
   }
 
-  Expr *SizeExpr;
-  // Special case where the argument is a template id.
-  if (Attr.isArgIdent(0)) {
-CXXScopeSpec SS;
-SourceLocation TemplateKWLoc;
-UnqualifiedId Id;
-Id.setIdentifier(Attr.getArgAsIdent(0)->Ident, Attr.getLoc());
-
-ExprResult Size = S.ActOnIdExpression(S.getCurScope(), SS, TemplateKWLoc,
-  Id, /*HasTrailingLParen=*/false,
-  /*IsAddressOfOperand=*/false);
-
-if (Size.isInvalid())
-  return;
-SizeExpr = Size.get();
-  } else {
-SizeExpr = Attr.getArgAsExpr(0);
-  }
-
+  Expr *SizeExpr = Attr.getArgAsExpr(0);
   QualType T = S.BuildVectorType(CurType, SizeExpr, Attr.getLoc());
   if (!T.isNull())
 CurType = T;
@@ -7695,28 +7659,8 @@
 return;
   }
 
-  Expr *sizeExpr;
-
-  // Special case where the argument is a template id.
-  if (Attr.isArgIdent(0)) {
-CXXScopeSpec SS;
-SourceLocation TemplateKWLoc;
-UnqualifiedId id;
-id.setIdentifier(Attr.getArgAsIdent(0)->Ident, Attr.getLoc());
-
-ExprResult Size = S.ActOnIdExpression(S.getCurScope(), SS, TemplateKWLoc,
-  id, /*HasTrailingLParen=*/false,
-  /*IsAddressOfOperand=*/false);
-if (Size.isInvalid())
-  return;
-
-sizeExpr = Size.get();
-  } else {
-sizeExpr = Attr.getArgAsExpr(0);
-  }
-
-  // Create the vector type.
-  QualType T = S.BuildExtVectorType(CurType, sizeExpr, Attr.getLoc());
+  Expr *SizeExpr = Attr.getArgAsExpr(0);
+  QualType T = S.BuildExtVectorType(CurType, SizeExpr, Attr.getLoc());
   if (!T.isNull())
 CurType = T;
 }
@@ -7988,49 +7932,8 @@
 return;
   }
 
-  Expr *RowsExpr = nullptr;
-  Expr *ColsExpr = nullptr;
-
-  // TODO: Refactor parameter extraction into separate function
-  // Get the number of rows
-  if (Attr.isArgIdent(0)) {
-CXXScopeSpec SS;
-SourceLocation TemplateKeywordLoc;
-UnqualifiedId id;
-id.setIdentifier(Attr.getArgAsIdent(0)->Ident, Attr.getLoc());
-ExprResult Rows = S.ActOnIdExpression(S.getCurScope(), SS,
-  TemplateKeywordLoc, id, false, false);
-
-if (Rows.isInvalid())
-  // TODO: maybe a good error message would be nice here
-  return;
-RowsExpr = Rows.get();
-  } else {
-assert(Attr.isArgExpr(0) &&
-   "Argument to should either be an identity or expression");
-RowsExpr = Attr.getArgAsExpr(0);
-  }
-
-  // Get the number of columns
-  if (Attr.isArgIdent(1)) {
-CXXScopeSpec SS;
-SourceLocation TemplateKeywordLoc;
-UnqualifiedId id;
-id.setIdentifier(Attr.getArgAsIdent(1)->Ident, Attr.getLoc());
-ExprResult Columns = S.ActOnIdExpression(
-S.getCurScope(), SS, TemplateKeywordLoc, id, false, false);
-
-if (Columns.isInvalid())
-  // TODO: a good error message would be nice here
-  return;
-RowsExpr = Columns.get();
-  } else {
-assert(Attr.isArgExpr(1) &&
-   "Argument to should either be an identity or expression");
-ColsExpr = Attr.getArgAsExpr(1);
-  }
-
-  // Create the matrix type.
+  Expr *RowsExpr = Attr.getArgAsExpr(0);
+  Expr *ColsExpr = Attr.getArgAsExpr(1);
   QualType T = S.BuildMatrixType(CurType, RowsExpr, ColsExpr, Attr.getLoc());
   if (!T.isNull())
 CurType = T;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 7ef9139 - [Clang] Remove unnecessary Attr.isArgIdent checks.

[Florian Hahn via cfe-commits]

Author: Florian Hahn
Date: 2021-01-06T18:01:41Z
New Revision: 7ef9139a391a6d526afab0216a97f9d65a6b5563

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

LOG: [Clang] Remove unnecessary Attr.isArgIdent checks.

The MatrixType, ExtVectorType, VectorSize and AddressSpace attributes
have arguments defined as ExprArguments in Attr.td. So their arguments
should never be ArgIdents and the logic to handle this case can be
removed.

The logic has been replaced by an assertion to ensure the arguments
are always ArgExpressions

Reviewed By: erichkeane

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

Added: 


Modified: 
clang/lib/Sema/SemaType.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaType.cpp b/clang/lib/Sema/SemaType.cpp
index 00ec0c4a0cee..3f564541d41d 100644
--- a/clang/lib/Sema/SemaType.cpp
+++ b/clang/lib/Sema/SemaType.cpp
@@ -6434,25 +6434,7 @@ static void HandleAddressSpaceTypeAttribute(QualType 
,
   return;
 }
 
-Expr *ASArgExpr;
-if (Attr.isArgIdent(0)) {
-  // Special case where the argument is a template id.
-  CXXScopeSpec SS;
-  SourceLocation TemplateKWLoc;
-  UnqualifiedId id;
-  id.setIdentifier(Attr.getArgAsIdent(0)->Ident, Attr.getLoc());
-
-  ExprResult AddrSpace = S.ActOnIdExpression(
-  S.getCurScope(), SS, TemplateKWLoc, id, /*HasTrailingLParen=*/false,
-  /*IsAddressOfOperand=*/false);
-  if (AddrSpace.isInvalid())
-return;
-
-  ASArgExpr = static_cast(AddrSpace.get());
-} else {
-  ASArgExpr = static_cast(Attr.getArgAsExpr(0));
-}
-
+Expr *ASArgExpr = static_cast(Attr.getArgAsExpr(0));
 LangAS ASIdx;
 if (!BuildAddressSpaceIndex(S, ASIdx, ASArgExpr, Attr.getLoc())) {
   Attr.setInvalid();
@@ -7658,25 +7640,7 @@ static void HandleVectorSizeAttr(QualType , 
const ParsedAttr ,
 return;
   }
 
-  Expr *SizeExpr;
-  // Special case where the argument is a template id.
-  if (Attr.isArgIdent(0)) {
-CXXScopeSpec SS;
-SourceLocation TemplateKWLoc;
-UnqualifiedId Id;
-Id.setIdentifier(Attr.getArgAsIdent(0)->Ident, Attr.getLoc());
-
-ExprResult Size = S.ActOnIdExpression(S.getCurScope(), SS, TemplateKWLoc,
-  Id, /*HasTrailingLParen=*/false,
-  /*IsAddressOfOperand=*/false);
-
-if (Size.isInvalid())
-  return;
-SizeExpr = Size.get();
-  } else {
-SizeExpr = Attr.getArgAsExpr(0);
-  }
-
+  Expr *SizeExpr = Attr.getArgAsExpr(0);
   QualType T = S.BuildVectorType(CurType, SizeExpr, Attr.getLoc());
   if (!T.isNull())
 CurType = T;
@@ -7695,28 +7659,8 @@ static void HandleExtVectorTypeAttr(QualType , 
const ParsedAttr ,
 return;
   }
 
-  Expr *sizeExpr;
-
-  // Special case where the argument is a template id.
-  if (Attr.isArgIdent(0)) {
-CXXScopeSpec SS;
-SourceLocation TemplateKWLoc;
-UnqualifiedId id;
-id.setIdentifier(Attr.getArgAsIdent(0)->Ident, Attr.getLoc());
-
-ExprResult Size = S.ActOnIdExpression(S.getCurScope(), SS, TemplateKWLoc,
-  id, /*HasTrailingLParen=*/false,
-  /*IsAddressOfOperand=*/false);
-if (Size.isInvalid())
-  return;
-
-sizeExpr = Size.get();
-  } else {
-sizeExpr = Attr.getArgAsExpr(0);
-  }
-
-  // Create the vector type.
-  QualType T = S.BuildExtVectorType(CurType, sizeExpr, Attr.getLoc());
+  Expr *SizeExpr = Attr.getArgAsExpr(0);
+  QualType T = S.BuildExtVectorType(CurType, SizeExpr, Attr.getLoc());
   if (!T.isNull())
 CurType = T;
 }
@@ -7988,49 +7932,8 @@ static void HandleMatrixTypeAttr(QualType , 
const ParsedAttr ,
 return;
   }
 
-  Expr *RowsExpr = nullptr;
-  Expr *ColsExpr = nullptr;
-
-  // TODO: Refactor parameter extraction into separate function
-  // Get the number of rows
-  if (Attr.isArgIdent(0)) {
-CXXScopeSpec SS;
-SourceLocation TemplateKeywordLoc;
-UnqualifiedId id;
-id.setIdentifier(Attr.getArgAsIdent(0)->Ident, Attr.getLoc());
-ExprResult Rows = S.ActOnIdExpression(S.getCurScope(), SS,
-  TemplateKeywordLoc, id, false, 
false);
-
-if (Rows.isInvalid())
-  // TODO: maybe a good error message would be nice here
-  return;
-RowsExpr = Rows.get();
-  } else {
-assert(Attr.isArgExpr(0) &&
-   "Argument to should either be an identity or expression");
-RowsExpr = Attr.getArgAsExpr(0);
-  }
-
-  // Get the number of columns
-  if (Attr.isArgIdent(1)) {
-CXXScopeSpec SS;
-SourceLocation TemplateKeywordLoc;
-UnqualifiedId id;
-id.setIdentifier(Attr.getArgAsIdent(1)->Ident, Attr.getLoc());
-ExprResult Columns = S.ActOnIdExpression(
-

[PATCH] D89031: [SVE] Add support to vectorize_width loop pragma for scalable vectors

[Sjoerd Meijer via Phabricator via cfe-commits]

SjoerdMeijer accepted this revision.
SjoerdMeijer added a comment.

LGTM, perhaps wait a day with committing in case there are more comments.




Comment at: clang/include/clang/Basic/Attr.td:3356
   EnumArgument<"State", "LoopHintState",
-   ["enable", "disable", "numeric", "assume_safety", 
"full"],
-   ["Enable", "Disable", "Numeric", "AssumeSafety", 
"Full"]>,
+   ["enable", "disable", "numeric", "fixed_width", 
"scalable_width", "assume_safety", "full"],
+   ["Enable", "Disable", "Numeric", "FixedWidth", 
"ScalableWidth", "AssumeSafety", "Full"]>,

aaron.ballman wrote:
> david-arm wrote:
> > aaron.ballman wrote:
> > > Should the documentation in AttrDocs.td be updated for this change?
> > Hi @aaron.ballman I had a look at LoopHintDocs in AttrDocs.td and it didn't 
> > explicitly mention these states, i.e. "assume_safety", "numeric", etc., so 
> > I'm not sure if it's necessary to add anything there?
> Oh, I see now, we're deferring to the documentation in the language 
> extensions document. I suppose that's fine as far as this patch goes, sorry 
> for the noise.
Nit: formatting, exceeding 80 columns?



Comment at: clang/include/clang/Basic/Attr.td:3357
+   ["enable", "disable", "numeric", "fixed_width", 
"scalable_width", "assume_safety", "full"],
+   ["Enable", "Disable", "Numeric", "FixedWidth", 
"ScalableWidth", "AssumeSafety", "Full"]>,
   ExprArgument<"Value">];

same?


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

https://reviews.llvm.org/D89031

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

[PATCH] D94067: [clang][ASTImporter] Fix a possible assertion failure `NeedsInjectedClassNameType(Decl)'.

[Shafik Yaghmour via Phabricator via cfe-commits]

shafik added inline comments.



Comment at: clang/lib/AST/ASTImporter.cpp:2901
+  // Skip the declaration if injected type is already set.
+  if (isa(RI->getTypeForDecl()))
+continue;

balazske wrote:
> shafik wrote:
> > Is this to fix the bug or is this for efficiency sake?
> This is not needed for the fix, it was used in the first version of the fix 
> (still only for efficiency). In the current form this looks like unrelated 
> change (the old fix included other code at the same location) so I am not 
> against removing this part (but add it in a separate change).
Yes, please if we can split the two changes that would be great.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94067

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

[PATCH] D92892: [clang] Change builtin object size to be compatible with GCC when sub-object is invalid

[George Burgess IV via Phabricator via cfe-commits]

george.burgess.iv accepted this revision.
george.burgess.iv added a comment.
This revision is now accepted and ready to land.

thanks for working on this!

just one tiny nit and lgtm




Comment at: clang/lib/AST/ExprConstant.cpp:11408
 
   // If we point to before the start of the object, there are no accessible
   // bytes.

nit: the new part of this condition makes this comment somewhat outdated. 
should it say something like "outside of" instead of "before"?


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

https://reviews.llvm.org/D92892

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

[PATCH] D93095: Introduce -Wreserved-identifier

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/test/Sema/reserved-identifier.c:9
+int _foo() { return 0; }// expected-warning {{'_foo' is a reserved 
identifier}}
+
+// This one is explicitly skipped by -Wreserved-identifier

Can you add a test that we do not warn on an extern declaration? e.g.,
```
extern char *_strdup(const char *);
```
This is sometimes used (esp in older C code bases) to avoid having to include 
an entire header to scrape one declaration out of it, and there are popular 
libraries (like the MSVC CRT) that have APIs starting with a single underscore 
and lowercase letter.

The idea here is: if it's an extern declaration, the identifier is "owned" by 
some other declaration and this is not likely something the user has control 
over.



Comment at: clang/test/Sema/reserved-identifier.c:24
+  _Other, // expected-warning {{'_Other' is a reserved identifier}}
+  _other  // no-warning
+};

I'm on the fence about whether this should have no warning or not. Enumeration 
constants in C (and sometimes in C++, depending on the enumeration) are in the 
enclosing scope. e.g.,
```
enum foo {
  _bar
};

int i = _bar;
```
So if a user has an enumeration constant named `_bar`, the implementation is 
not free to add `int _bar(void);` as it will cause compile errors. WDYT?



Comment at: clang/test/Sema/reserved-identifier.cpp:58
+// we skip this one because it's not at top-level.
+int _barbatruc; // no-warning
+}

This is another case that I'm on the fence about failing to warn on because the 
name `_barbatruc` would conflict with a name introduced by the implementation. 
Another interesting variant of the same problem, for C++:
```
static union {
  int _field;
};
```
I wonder if the rule should not be whether the declaration is at file scope or 
not, but whether the declared identifier can be found at file scope or not?



Comment at: clang/test/Sema/reserved-identifier.cpp:40
+  return foo__bar(); // no-warning
+}

aaron.ballman wrote:
> You should also have some tests for:
> ```
> template 
> void _Foobar(); // Even though it's not instantiated, it's still reserved.
> 
> template  // Reserved
> void whatever();
> 
> void func() {
>   int array[10];
>   for (auto _A : array) // Reserved
> ;
> }
> 
> class _C { // Reserved
> public:
>   _C(); // Not reserved
> };
> 
> unsigned operator "" huttah(unsigned long long); // Reserved 
> (http://eel.is/c++draft/usrlit.suffix#1)
> 
> unsigned operator "" _W(unsigned long long); // Reserved
> unsigned operator "" _w(unsigned long long); // Reserved
> 
> static unsigned operator "" _X(unsigned long long); // Not reserved
> static unsigned operator "" _x(unsigned long long); // Not reserved
> ```
I think some of these tests are still missing. I'm especially worried about the 
user-defined literal cases being diagnosed, as we'd be warning to not do the 
exact thing users are expected to do.


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

https://reviews.llvm.org/D93095

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

[PATCH] D91806: [InstCombine] Update valueCoversEntireFragment to use TypeSize

[Peter Waller 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 rGdfd3384feeca: [InstCombine] Update valueCoversEntireFragment 
to use TypeSize (authored by fpetrogalli, committed by peterwaller-arm).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91806

Files:
  llvm/lib/Transforms/Utils/Local.cpp
  llvm/test/Transforms/InstCombine/debuginfo-scalable-typesize.ll


Index: llvm/test/Transforms/InstCombine/debuginfo-scalable-typesize.ll
===
--- /dev/null
+++ llvm/test/Transforms/InstCombine/debuginfo-scalable-typesize.ll
@@ -0,0 +1,36 @@
+; RUN: opt -instcombine -S < %s 2>%t | FileCheck %s
+; RUN: FileCheck --check-prefix=WARN --allow-empty %s <%t
+
+; This test is defending against a TypeSize message raised in the method
+; `valueCoversEntireFragment` in Local.cpp because of an implicit cast from
+; `TypeSize` to `uint64_t`. This particular TypeSize message only occurred when
+; debug info was available.
+
+; If this check fails please read
+; clang/test/CodeGen/aarch64-sve-intrinsics/README for instructions on
+; how to resolve it.
+; This test must not produce any warnings. Prior to this test being introduced,
+; it produced a warning containing the text "TypeSize is not scalable".
+; WARN-NOT: warning:
+
+; CHECK-LABEL: @debug_local_scalable(
+define  @debug_local_scalable( 
%tostore) {
+  %vx = alloca , align 16
+  call void @llvm.dbg.declare(metadata * %vx, metadata 
!3, metadata !DIExpression()), !dbg !5
+  store  %tostore, * %vx, align 16
+  %ret = call  @f(* %vx)
+  ret  %ret
+}
+
+declare  @f(*)
+
+declare void @llvm.dbg.declare(metadata, metadata, metadata)
+
+!llvm.module.flags = !{!2}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1)
+!1 = !DIFile(filename: "/tmp/test.c", directory: "/tmp/")
+!2 = !{i32 2, !"Debug Info Version", i32 3}
+!3 = !DILocalVariable(scope: !4)
+!4 = distinct !DISubprogram(unit: !0)
+!5 = !DILocation(scope: !4)
Index: llvm/lib/Transforms/Utils/Local.cpp
===
--- llvm/lib/Transforms/Utils/Local.cpp
+++ llvm/lib/Transforms/Utils/Local.cpp
@@ -1340,16 +1340,22 @@
 /// least n bits.
 static bool valueCoversEntireFragment(Type *ValTy, DbgVariableIntrinsic *DII) {
   const DataLayout  = DII->getModule()->getDataLayout();
-  uint64_t ValueSize = DL.getTypeAllocSizeInBits(ValTy);
-  if (auto FragmentSize = DII->getFragmentSizeInBits())
-return ValueSize >= *FragmentSize;
+  TypeSize ValueSize = DL.getTypeAllocSizeInBits(ValTy);
+  if (Optional FragmentSize = DII->getFragmentSizeInBits()) {
+assert(!ValueSize.isScalable() &&
+   "Fragments don't work on scalable types.");
+return ValueSize.getFixedSize() >= *FragmentSize;
+  }
   // We can't always calculate the size of the DI variable (e.g. if it is a
   // VLA). Try to use the size of the alloca that the dbg intrinsic describes
   // intead.
   if (DII->isAddressOfVariable())
 if (auto *AI = dyn_cast_or_null(DII->getVariableLocation()))
-  if (auto FragmentSize = AI->getAllocationSizeInBits(DL))
-return ValueSize >= *FragmentSize;
+  if (Optional FragmentSize = AI->getAllocationSizeInBits(DL)) {
+assert(ValueSize.isScalable() == FragmentSize->isScalable() &&
+   "Both sizes should agree on the scalable flag.");
+return TypeSize::isKnownGE(ValueSize, *FragmentSize);
+  }
   // Could not determine size of variable. Conservatively return false.
   return false;
 }


Index: llvm/test/Transforms/InstCombine/debuginfo-scalable-typesize.ll
===
--- /dev/null
+++ llvm/test/Transforms/InstCombine/debuginfo-scalable-typesize.ll
@@ -0,0 +1,36 @@
+; RUN: opt -instcombine -S < %s 2>%t | FileCheck %s
+; RUN: FileCheck --check-prefix=WARN --allow-empty %s <%t
+
+; This test is defending against a TypeSize message raised in the method
+; `valueCoversEntireFragment` in Local.cpp because of an implicit cast from
+; `TypeSize` to `uint64_t`. This particular TypeSize message only occurred when
+; debug info was available.
+
+; If this check fails please read
+; clang/test/CodeGen/aarch64-sve-intrinsics/README for instructions on
+; how to resolve it.
+; This test must not produce any warnings. Prior to this test being introduced,
+; it produced a warning containing the text "TypeSize is not scalable".
+; WARN-NOT: warning:
+
+; CHECK-LABEL: @debug_local_scalable(
+define  @debug_local_scalable( %tostore) {
+  %vx = alloca , align 16
+  call void @llvm.dbg.declare(metadata * %vx, metadata !3, metadata !DIExpression()), !dbg !5
+  store  %tostore, * %vx, align 16
+  %ret = call  @f(* %vx)
+  ret  %ret
+}
+
+declare  @f(*)
+
+declare void @llvm.dbg.declare(metadata, metadata, metadata)
+
+!llvm.module.flags = 

[PATCH] D93901: [NFC] Renaming PackStack to AlignPackStack

[Xiangling Liao via Phabricator via cfe-commits]

Xiangling_L updated this revision to Diff 314911.
Xiangling_L marked 3 inline comments as done.
Xiangling_L added a comment.

Add pre-committing tests with the incorrect behaviour as part of the NFC patch.


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

https://reviews.llvm.org/D93901

Files:
  clang/include/clang/Sema/Sema.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/include/clang/Serialization/ASTReader.h
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaAttr.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/Sema/Inputs/pragma-align-pack1.h
  clang/test/Sema/misleading-pragma-align-pack-diagnostics.c

Index: clang/test/Sema/misleading-pragma-align-pack-diagnostics.c
===
--- /dev/null
+++ clang/test/Sema/misleading-pragma-align-pack-diagnostics.c
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 -triple i686-apple-darwin9 -fsyntax-only -Wpragma-pack-suspicious-include -I %S/Inputs -DALIGN_SET_HERE -verify %s
+// RUN: %clang_cc1 -triple i686-apple-darwin9 -fsyntax-only -Wpragma-pack-suspicious-include -I %S/Inputs -DRECORD_ALIGN -verify %s
+
+#ifdef ALIGN_SET_HERE
+#pragma align = natural // expected-warning {{unterminated '#pragma pack (push, ...)' at end of file}}
+// expected-warning@+9 {{the current #pragma pack alignment value is modified in the included file}}
+#endif
+
+#ifdef RECORD_ALIGN
+#pragma align = mac68k
+// expected-note@-1 {{previous '#pragma pack' directive that modifies alignment is here}}
+// expected-warning@+3 {{non-default #pragma pack value changes the alignment of struct or union members in the included file}}
+#endif
+
+#include "pragma-align-pack1.h"
+
+#ifdef RECORD_ALIGN
+#pragma align = reset
+#endif
Index: clang/test/Sema/Inputs/pragma-align-pack1.h
===
--- /dev/null
+++ clang/test/Sema/Inputs/pragma-align-pack1.h
@@ -0,0 +1,11 @@
+#ifdef ALIGN_SET_HERE
+#pragma align = mac68k
+// expected-note@-1 {{previous '#pragma pack' directive that modifies alignment is here}}
+// expected-warning@-2 {{unterminated '#pragma pack (push, ...)' at end of file}}
+#endif
+
+#ifdef RECORD_ALIGN
+struct S {
+  int x;
+};
+#endif
Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -4151,24 +4151,24 @@
   Stream.EmitRecord(POINTERS_TO_MEMBERS_PRAGMA_OPTIONS, Record);
 }
 
-/// Write the state of 'pragma pack' at the end of the module.
+/// Write the state of 'pragma align/pack' at the end of the module.
 void ASTWriter::WritePackPragmaOptions(Sema ) {
-  // Don't serialize pragma pack state for modules, since it should only take
-  // effect on a per-submodule basis.
+  // Don't serialize pragma align/pack state for modules, since it should only
+  // take effect on a per-submodule basis.
   if (WritingModule)
 return;
 
   RecordData Record;
-  Record.push_back(SemaRef.PackStack.CurrentValue);
-  AddSourceLocation(SemaRef.PackStack.CurrentPragmaLocation, Record);
-  Record.push_back(SemaRef.PackStack.Stack.size());
-  for (const auto  : SemaRef.PackStack.Stack) {
+  Record.push_back(SemaRef.AlignPackStack.CurrentValue);
+  AddSourceLocation(SemaRef.AlignPackStack.CurrentPragmaLocation, Record);
+  Record.push_back(SemaRef.AlignPackStack.Stack.size());
+  for (const auto  : SemaRef.AlignPackStack.Stack) {
 Record.push_back(StackEntry.Value);
 AddSourceLocation(StackEntry.PragmaLocation, Record);
 AddSourceLocation(StackEntry.PragmaPushLocation, Record);
 AddString(StackEntry.StackSlotLabel, Record);
   }
-  Stream.EmitRecord(PACK_PRAGMA_OPTIONS, Record);
+  Stream.EmitRecord(ALIGN_PACK_PRAGMA_OPTIONS, Record);
 }
 
 /// Write the state of 'pragma float_control' at the end of the module.
Index: clang/lib/Serialization/ASTReader.cpp
===
--- clang/lib/Serialization/ASTReader.cpp
+++ clang/lib/Serialization/ASTReader.cpp
@@ -3742,25 +3742,25 @@
   ForceCUDAHostDeviceDepth = Record[0];
   break;
 
-case PACK_PRAGMA_OPTIONS: {
+case ALIGN_PACK_PRAGMA_OPTIONS: {
   if (Record.size() < 3) {
 Error("invalid pragma pack record");
 return Failure;
   }
-  PragmaPackCurrentValue = Record[0];
-  PragmaPackCurrentLocation = ReadSourceLocation(F, Record[1]);
+  PragmaAlignPackCurrentValue = Record[0];
+  PragmaAlignPackCurrentLocation = ReadSourceLocation(F, Record[1]);
   unsigned NumStackEntries = Record[2];
   unsigned Idx = 3;
   // Reset the stack when importing a new module.
-  PragmaPackStack.clear();
+  PragmaAlignPackStack.clear();
   for (unsigned I = 0; I < NumStackEntries; ++I) {
-PragmaPackStackEntry Entry;
+PragmaAlignPackStackEntry Entry;
 Entry.Value = Record[Idx++];
  

[PATCH] D93702: [clang][cli] NFC: Make marshalling macros reusable

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 added inline comments.



Comment at: clang/lib/Frontend/CompilerInvocation.cpp:3040
 
-#define OPTION_WITH_MARSHALLING(   
\
-PREFIX_TYPE, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,
\
-HELPTEXT, METAVAR, VALUES, SPELLING, ALWAYS_EMIT, KEYPATH, DEFAULT_VALUE,  
\
-IMPLIED_CHECK, IMPLIED_VALUE, NORMALIZER, DENORMALIZER, MERGER, EXTRACTOR, 
\
-TABLE_INDEX)   
\
-  if ((FLAGS)::CC1Option) {
\
-this->KEYPATH = MERGER(this->KEYPATH, DEFAULT_VALUE);  
\
-if (IMPLIED_CHECK) 
\
-  this->KEYPATH = MERGER(this->KEYPATH, IMPLIED_VALUE);
\
-if (auto MaybeValue =  
\
-NORMALIZER(OPT_##ID, TABLE_INDEX, Args, Diags, Success))   
\
-  this->KEYPATH = MERGER(  
\
-  this->KEYPATH, static_castKEYPATH)>(*MaybeValue));   
\
-  }
-
+#define OPTION_WITH_MARSHALLING PARSE_OPTION_WITH_MARSHALLING
 #include "clang/Driver/Options.inc"

dexonsmith wrote:
> jansvoboda11 wrote:
> > dexonsmith wrote:
> > > One concern I have with this change is that the macro is using local 
> > > variable names; it really would be better to have the macro content local 
> > > to the function(s) where the variables are defined.
> > > 
> > > Can you give more context about why this has to be called from another 
> > > place? Maybe there's another way to solve the problem.
> > I've provided more context here: D93701.
> > 
> > We can solve the problem with implicit use of local variables inside the 
> > macro by promoting them to macro parameters.
> > This will make the forwarding call from `OPTION_WITH_MARSHALLING` to 
> > `PARSE_OPTION_WITH_MARSHALLING` longer, as it will need to spell out all 
> > parameters, but it would solve your concern I think.
> I like that idea. That approach also allows you to drop unused parameters 
> entirely in `PARSE_OPTIONS_WITH_MARSHALLING` (only forward the parameters 
> that get used).
I've dropped the unused parameters for the `PARSE_` macro. D84673 does the same 
for the `GENERATE_` macro.



Comment at: clang/lib/Frontend/CompilerInvocation.cpp:3331-3332
+
+#undef GENERATE_OPTION_WITH_MARSHALLING
+#undef PARSE_OPTION_WITH_MARSHALLING

dexonsmith wrote:
> I like the idea of `#undef`'ing these macros to make their scope of use 
> clear, but I'm not sure doing it at the end of file is adding a lot of value.
> 
> Is there a way of moving the call sites for each to be next to each other in 
> the file, so you can `#define` and then `#undef` in a more limited scope? 
> E.g.,
> ```
> // maybe other content...
> 
> #define PARSE_OPTION_WITH_MARSHALLING(...) ...
> void f1(...) { /* use PARSE_OPTION_WITH_MARSHALLING */ }
> void f2(...) { /* use PARSE_OPTION_WITH_MARSHALLING */ }
> #undef PARSE_OPTION_WITH_MARSHALLING
> 
> // maybe other content...
> 
> #define GENERATE_OPTION_WITH_MARSHALLING(...) ...
> void f3(...) { /* use GENERATE_OPTION_WITH_MARSHALLING*/ }
> void f4(...) { /* use GENERATE_OPTION_WITH_MARSHALLING*/ }
> #undef GENERATE_OPTION_WITH_MARSHALLING
> 
> // maybe other content...
> ```
> (If so, the code movement should be done in a separate NFC prep commit...)
Yeah, limiting the scope where the macro is defined would be nice. I've moved 
things around and we'll be able to keep the `GENERATE_` macro local to the 
function, while the `PARSE_` macro will span only the two functions that'll 
make use of it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93702

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

[PATCH] D84673: [clang][cli] Port DiagnosticOpts to new option parsing system

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 added inline comments.



Comment at: llvm/utils/TableGen/OptParserEmitter.cpp:102-107
+  std::string getMacroName() const {
+if (KeyPath.startswith("DiagnosticOpts."))
+  return (Twine("DIAG_") + MarshallingInfo::MacroName).str();
+
+return MarshallingInfo::MacroName;
+  }

dexonsmith wrote:
> jansvoboda11 wrote:
> > dexonsmith wrote:
> > > This seems like a bit of a semantic layering violation. It'd be pretty 
> > > unexpected if someone renamed `DiagnosticOpts` in clang that they'd have 
> > > to update this code in llvm. Is there another way to solve this problem?
> > I don't like it either, but the alternatives I can think of are worse.
> > 
> > We could add a `string MacroPrefix;` field to LLVM's `Option` class and 
> > populate it in Clang's TableGen file:
> > 1. Via something like an `IsDiag` multiclass that we'd need to remember to 
> > apply to each diagnostic option. I don't like it as it seems error prone 
> > and introduces duplication.
> > 2. Put all diagnostic options into a single `let MacroPrefix = "DIAG_" in { 
> > ... }` block. This removes the duplication, but doesn't ensure an option is 
> > in that block iff it's a diagnostic option with `"DiagnosticOpts.*"` 
> > keypath.
> > 3. More involved approach would be to duplicate the LLVM's `Option` and 
> > related stuff in Clang. That would get us a place to put the custom 
> > `KeyPath.startswith("DiagnosticOpts.")` logic and then forward to LLVM's 
> > `Option` with the appropriate `MacroPrefix`.
> > 
> > I'll think some more about it.
> Doing #1 + #2 seems like an okay tradeoff to me (looking back at the old 
> diff, it seems like that's similar to what @dang originally implemented 
> (except adding a more generic `MacroPrefix`), and it seems fairly clean / 
> obvious to me).
> 
> > [...] but doesn't ensure an option is in that block iff it's a diagnostic 
> > option with "DiagnosticOpts.*" keypath.
> 
> The reason I'm okay with this is that I'm having trouble envisioning how this 
> would go wrong practice.
> - If someone adds somethings to `DiagnosticOptions`, they're likely to grep 
> for how the adjacent field was defined / marshalled, duplicate the line, and 
> modify it. I'm not seeing a likely path for them to copy/paste from a 
> non-diagnostic option and/or miss adding this to the `let` block.
> - If someone accidentally adds something to the `let` block that isn't in 
> `DiagnosticOptions`, they'll get a compiler error in `ParseDiagnosticArgs`.
> 
> If you're still concerned, I wonder if there's a way to add a check in 
> asserts builds that confirms that `ParseDiagnosticArgs` fills in 
> `DiagnosticOptions` equivalently to how `createFromCommandLine` does? (and/or 
> could the latter call the former as an implementation strategy?)
> - If someone adds somethings to `DiagnosticOptions`, they're likely to grep 
> for how the adjacent field was defined / marshalled, duplicate the line, and 
> modify it. I'm not seeing a likely path for them to copy/paste from a 
> non-diagnostic option and/or miss adding this to the `let` block.

I think that's a fair assumption.

> - If someone accidentally adds something to the `let` block that isn't in 
> `DiagnosticOptions`, they'll get a compiler error in `ParseDiagnosticArgs`.

That's right.

I think it's fine to move from the check in `OptParserEmitter` to a 
`MacroPrefix` then.
I chose the `IsDiag` mixin as opposed to `let MacroPrefix = "_DIAG" in { ... 
}`, as it doesn't require moving options around - cleaner diff.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84673

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

[PATCH] D89031: [SVE] Add support to vectorize_width loop pragma for scalable vectors

[David Sherwood via Phabricator via cfe-commits]

david-arm added a comment.

Hi everyone, I realise that most people have probably been on holiday recently, 
but just a gentle ping here to see if anyone could take another look? Thanks!


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

https://reviews.llvm.org/D89031

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

[PATCH] D84673: [clang][cli] Port DiagnosticOpts to new option parsing system

[Jan Svoboda via Phabricator via cfe-commits]

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

Use arrow instead of dot in keypath


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84673

Files:
  clang/include/clang/Basic/DiagnosticOptions.h
  clang/include/clang/Driver/Options.td
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/unittests/Frontend/CompilerInvocationTest.cpp
  llvm/include/llvm/Option/OptParser.td
  llvm/utils/TableGen/OptParserEmitter.cpp

Index: llvm/utils/TableGen/OptParserEmitter.cpp
===
--- llvm/utils/TableGen/OptParserEmitter.cpp
+++ llvm/utils/TableGen/OptParserEmitter.cpp
@@ -66,6 +66,7 @@
   static constexpr const char *MacroName = "OPTION_WITH_MARSHALLING";
   const Record 
   bool ShouldAlwaysEmit;
+  StringRef MacroPrefix;
   StringRef KeyPath;
   StringRef DefaultValue;
   StringRef NormalizedValuesScope;
@@ -99,6 +100,10 @@
 
   MarshallingInfo(const Record ) : R(R) {}
 
+  std::string getMacroName() const {
+return (MacroPrefix + MarshallingInfo::MacroName).str();
+  }
+
   void emit(raw_ostream ) const {
 write_cstring(OS, StringRef(getOptionSpelling(R)));
 OS << ", ";
@@ -160,6 +165,7 @@
   MarshallingInfo Ret(R);
 
   Ret.ShouldAlwaysEmit = R.getValueAsBit("ShouldAlwaysEmit");
+  Ret.MacroPrefix = R.getValueAsString("MacroPrefix");
   Ret.KeyPath = R.getValueAsString("KeyPath");
   Ret.DefaultValue = R.getValueAsString("DefaultValue");
   Ret.NormalizedValuesScope = R.getValueAsString("NormalizedValuesScope");
@@ -420,13 +426,13 @@
 MarshallingInfos.push_back(createMarshallingInfo(*R));
 
   for (const auto  : MarshallingInfos) {
-OS << "#ifdef " << MarshallingInfo::MacroName << "\n";
-OS << MarshallingInfo::MacroName << "(";
+OS << "#ifdef " << MI.getMacroName() << "\n";
+OS << MI.getMacroName() << "(";
 WriteOptRecordFields(OS, MI.R);
 OS << ", ";
 MI.emit(OS);
 OS << ")\n";
-OS << "#endif // " << MarshallingInfo::MacroName << "\n";
+OS << "#endif // " << MI.getMacroName() << "\n";
   }
 
   OS << "\n";
Index: llvm/include/llvm/Option/OptParser.td
===
--- llvm/include/llvm/Option/OptParser.td
+++ llvm/include/llvm/Option/OptParser.td
@@ -97,6 +97,7 @@
   OptionGroup Group = ?;
   Option Alias = ?;
   list AliasArgs = [];
+  code MacroPrefix = "";
   code KeyPath = ?;
   code DefaultValue = ?;
   code ImpliedValue = ?;
Index: clang/unittests/Frontend/CompilerInvocationTest.cpp
===
--- clang/unittests/Frontend/CompilerInvocationTest.cpp
+++ clang/unittests/Frontend/CompilerInvocationTest.cpp
@@ -606,4 +606,19 @@
   ASSERT_THAT(GeneratedArgs, Contains(StrEq("-cl-mad-enable")));
   ASSERT_THAT(GeneratedArgs, Contains(StrEq("-menable-unsafe-fp-math")));
 }
+
+// Diagnostic option.
+
+TEST_F(CommandLineTest, DiagnosticOptionPresent) {
+  const char *Args[] = {"-verify=xyz"};
+
+  ASSERT_TRUE(CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags));
+
+  ASSERT_EQ(Invocation.getDiagnosticOpts().VerifyPrefixes,
+std::vector({"xyz"}));
+
+  Invocation.generateCC1CommandLine(GeneratedArgs, *this);
+
+  ASSERT_THAT(GeneratedArgs, ContainsN(StrEq("-verify=xyz"), 1));
+}
 } // anonymous namespace
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -386,7 +386,6 @@
 DiagnosticsEngine ,
 const InputArgList ) {
   LangOptions  = *Invocation.getLangOpts();
-  DiagnosticOptions  = Invocation.getDiagnosticOpts();
   CodeGenOptions  = Invocation.getCodeGenOpts();
   TargetOptions  = Invocation.getTargetOpts();
   FrontendOptions  = Invocation.getFrontendOpts();
@@ -400,8 +399,6 @@
   LangOpts.SpeculativeLoadHardening = CodeGenOpts.SpeculativeLoadHardening;
   LangOpts.CurrentModule = LangOpts.ModuleName;
 
-  llvm::sys::Process::UseANSIEscapeCodes(DiagOpts.UseANSIEscapeCodes);
-
   llvm::Triple T(TargetOpts.Triple);
   llvm::Triple::ArchType Arch = T.getArch();
 
@@ -1401,13 +1398,12 @@
 ARGS, DIAGS, SUCCESS, ID, FLAGS, PARAM, KEYPATH, DEFAULT_VALUE,\
 IMPLIED_CHECK, IMPLIED_VALUE, NORMALIZER, MERGER, TABLE_INDEX) \
   if ((FLAGS)::CC1Option) {\
-this->KEYPATH = MERGER(this->KEYPATH, DEFAULT_VALUE);  \
+KEYPATH = MERGER(KEYPATH, DEFAULT_VALUE);  \
 if (IMPLIED_CHECK) \
-  this->KEYPATH = MERGER(this->KEYPATH, IMPLIED_VALUE);\
+  KEYPATH = MERGER(KEYPATH, IMPLIED_VALUE);\
 if (auto 

[PATCH] D93401: [flang][driver] Add support for `-D`, `-U`

[Andrzej Warzynski 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 rG7809fa204000: [flang][driver] Add support for `-D`, `-U` 
(authored by FarisRehman, committed by awarzynski).

Changed prior to commit:
  https://reviews.llvm.org/D93401?vs=313532=314906#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93401

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Flang.cpp
  clang/lib/Driver/ToolChains/Flang.h
  flang/include/flang/Frontend/CompilerInstance.h
  flang/include/flang/Frontend/CompilerInvocation.h
  flang/include/flang/Frontend/PreprocessorOptions.h
  flang/lib/Frontend/CompilerInstance.cpp
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/test/Flang-Driver/driver-help-hidden.f90
  flang/test/Flang-Driver/driver-help.f90
  flang/test/Flang-Driver/macro_def_undef.f90
  flang/test/Flang-Driver/macro_multiline.f90

Index: flang/test/Flang-Driver/macro_multiline.f90
===
--- /dev/null
+++ flang/test/Flang-Driver/macro_multiline.f90
@@ -0,0 +1,22 @@
+! Ensure the end-of-line character and anything that follows after in a macro definition (-D) is ignored.
+
+! REQUIRES: new-flang-driver
+
+!--
+! FLANG DRIVER (flang-new)
+!--
+! RUN: printf -- "-DX=A\nTHIS_SHOULD_NOT_EXIST_IN_THE_OUTPUT\n" | xargs %flang-new -E %s  2>&1 | FileCheck --strict-whitespace --match-full-lines %s
+
+!-
+! FRONTEND FLANG DRIVER (flang-new -fc1)
+!-
+! RUN: printf -- "-DX=A\nTHIS_SHOULD_NOT_EXIST_IN_THE_OUTPUT\n" | xargs %flang-new -fc1 -E %s  2>&1 | FileCheck --strict-whitespace --match-full-lines %s
+
+!---
+! EXPECTED OUTPUT FOR MACRO 'X'
+!---
+! CHECK:start a end
+! CHECK-NOT:THIS_SHOULD_NOT_EXIST_IN_THE_OUTPUT
+! CHECK-NOT:this_should_not_exist_in_the_output
+
+START X END
\ No newline at end of file
Index: flang/test/Flang-Driver/macro_def_undef.f90
===
--- /dev/null
+++ flang/test/Flang-Driver/macro_def_undef.f90
@@ -0,0 +1,38 @@
+! Ensure arguments -D and -U work as expected.
+
+! REQUIRES: new-flang-driver
+
+!--
+! FLANG DRIVER (flang-new)
+!--
+! RUN: %flang-new -E %s  2>&1 | FileCheck %s --check-prefix=UNDEFINED
+! RUN: %flang-new -E -DX=A %s  2>&1 | FileCheck %s --check-prefix=DEFINED
+! RUN: %flang-new -E -DX=A -UX %s  2>&1 | FileCheck %s --check-prefix=UNDEFINED
+
+!-
+! FRONTEND FLANG DRIVER (flang-new -fc1)
+!-
+! RUN: %flang-new -fc1 -E %s  2>&1 | FileCheck %s --check-prefix=UNDEFINED
+! RUN: %flang-new -fc1 -E -DX=A %s  2>&1 | FileCheck %s --check-prefix=DEFINED
+! RUN: %flang-new -fc1 -E -DX -UX %s  2>&1 | FileCheck %s --check-prefix=UNDEFINED
+
+!
+! EXPECTED OUTPUT FOR AN UNDEFINED MACRO
+!
+! UNDEFINED:program b
+! UNDEFINED-NOT:program x
+! UNDEFINED-NEXT:end
+
+!
+! EXPECTED OUTPUT FOR MACRO 'X' DEFINED AS A
+!
+! DEFINED:program a
+! DEFINED-NOT:program b
+! DEFINED-NEXT:end
+
+#ifdef X
+program X
+#else
+program B
+#endif
+end
\ No newline at end of file
Index: flang/test/Flang-Driver/driver-help.f90
===
--- flang/test/Flang-Driver/driver-help.f90
+++ flang/test/Flang-Driver/driver-help.f90
@@ -19,11 +19,13 @@
 ! HELP-EMPTY:
 ! HELP-NEXT:OPTIONS:
 ! HELP-NEXT: -###   Print (but do not run) the commands to run for this compilation
+! HELP-NEXT: -D = Define  to  (or 1 if  omitted)
 ! HELP-NEXT: -E Only run the preprocessor
 ! HELP-NEXT: -fcolor-diagnosticsEnable colors in diagnostics
 ! HELP-NEXT: -fno-color-diagnostics Disable colors in diagnostics
 ! HELP-NEXT: -help  Display available options
 ! HELP-NEXT: -o   Write output to 
+! HELP-NEXT: -U  Undefine macro 
 ! HELP-NEXT: --version  Print version information
 
 !-
@@ -32,10 +34,12 @@
 ! HELP-FC1:USAGE: flang-new
 ! HELP-FC1-EMPTY:
 ! HELP-FC1-NEXT:OPTIONS:
-! HELP-FC1-NEXT: -EOnly run the preprocessor
-! HELP-FC1-NEXT: -help Display available options
-! HELP-FC1-NEXT: -o  Write output to 
-! HELP-FC1-NEXT: --version Print version information
+! HELP-FC1-NEXT: -D = Define  to  (or 1 if  omitted)
+! HELP-FC1-NEXT: -E Only run the preprocessor
+! HELP-FC1-NEXT: -help  Display