date:20200517

[PATCH] D79754: [OpenMP][AMDGCN] Support OpenMP offloading for AMDGCN architecture - Part 1

2020-05-17 Thread Sameer Sahasrabuddhe via Phabricator via cfe-commits

sameerds added inline comments.



Comment at: clang/lib/AST/Decl.cpp:3224
 
+  // HIP does not have device-side standard library. printf and malloc are
+  // the only special cases that are supported by device-side runtime.

This should say "OpenMP does not have ..."?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79754



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

[PATCH] D79754: [OpenMP][AMDGCN] Support OpenMP offloading for AMDGCN architecture - Part 1

2020-05-17 Thread Sameer Sahasrabuddhe via Phabricator via cfe-commits

sameerds added inline comments.



Comment at: clang/lib/AST/Decl.cpp:3227
+  !(BuiltinID == Builtin::BIprintf || BuiltinID == Builtin::BImalloc))
+return 0;
+

sameerds wrote:
> This needs a test.
This still needs a test. One that shows that specific builtins are allowed and 
others are not.



Comment at: clang/test/Driver/openmp-offload-gpu.c:257
 // RUN:   | FileCheck -check-prefix=CUDA_MODE %s
-// CUDA_MODE: clang{{.*}}"-cc1"{{.*}}"-triple" "nvptx64-nvidia-cuda"
-// CUDA_MODE-SAME: "-fopenmp-cuda-mode"

Is there a functional reason to move these lines? Changes to existing files 
should be minimized to show only functional changes. Any NFC rearrangement 
should be a separate patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79754



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

[PATCH] D79770: [RISCV] Fix passing two floating-point values in complex separately by two GPRs on RV64

2020-05-17 Thread Jim Lin via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG7ee479a760e0: [RISCV] Fix passing two floating-point values 
in complex separately by two GPRs… (authored by Jim).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79770

Files:
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/riscv64-lp64-abi.c
  clang/test/CodeGen/riscv64-lp64f-lp64d-abi.c


Index: clang/test/CodeGen/riscv64-lp64f-lp64d-abi.c
===
--- clang/test/CodeGen/riscv64-lp64f-lp64d-abi.c
+++ clang/test/CodeGen/riscv64-lp64f-lp64d-abi.c
@@ -165,6 +165,35 @@
   return (struct floatcomplex_s){1.0};
 }
 
+// Complex floating-point values or structs containing a single complex
+// floating-point value should be passed in GPRs if no two FPRs is available.
+
+// CHECK: define void @f_floatcomplex_insufficient_fprs1(float %a.coerce0, 
float %a.coerce1, float %b.coerce0, float %b.coerce1, float %c.coerce0, float 
%c.coerce1, float %d.coerce0, float %d.coerce1, i64 %e.coerce)
+void f_floatcomplex_insufficient_fprs1(float __complex__ a, float __complex__ 
b,
+   float __complex__ c, float __complex__ 
d,
+   float __complex__ e) {}
+
+
+// CHECK: define void @f_floatcomplex_s_arg_insufficient_fprs1(float %0, float 
%1, float %2, float %3, float %4, float %5, float %6, float %7, i64 %e.coerce)
+void f_floatcomplex_s_arg_insufficient_fprs1(struct floatcomplex_s a,
+ struct floatcomplex_s b,
+ struct floatcomplex_s c,
+ struct floatcomplex_s d,
+ struct floatcomplex_s e) {}
+
+// CHECK: define void @f_floatcomplex_insufficient_fprs2(float %a, float 
%b.coerce0, float %b.coerce1, float %c.coerce0, float %c.coerce1, float 
%d.coerce0, float %d.coerce1, i64 %e.coerce)
+void f_floatcomplex_insufficient_fprs2(float a,
+   float __complex__ b, float __complex__ 
c,
+   float __complex__ d, float __complex__ 
e) {}
+
+
+// CHECK: define void @f_floatcomplex_s_arg_insufficient_fprs2(float %a, float 
%0, float %1, float %2, float %3, float %4, float %5, i64 %e.coerce)
+void f_floatcomplex_s_arg_insufficient_fprs2(float a,
+ struct floatcomplex_s b,
+ struct floatcomplex_s c,
+ struct floatcomplex_s d,
+ struct floatcomplex_s e) {}
+
 // Test single or two-element structs that need flattening. e.g. those
 // containing nested structs, floats in small arrays, zero-length structs etc.
 
Index: clang/test/CodeGen/riscv64-lp64-abi.c
===
--- clang/test/CodeGen/riscv64-lp64-abi.c
+++ clang/test/CodeGen/riscv64-lp64-abi.c
@@ -30,3 +30,24 @@
   uint8_t e, int8_t f, uint8_t g) {
   return (struct large){a, e, f, g};
 }
+
+// Complex floating-point values or structs containing a single complex
+// floating-point value should be passed in a GPR.
+
+// CHECK: define void @f_floatcomplex(i64 %a.coerce)
+void f_floatcomplex(float __complex__ a) {}
+
+// CHECK: define i64 @f_ret_floatcomplex()
+float __complex__ f_ret_floatcomplex() {
+  return 1.0;
+}
+
+struct floatcomplex_s { float __complex__ c; };
+
+// CHECK: define void @f_floatcomplex_s_arg(i64 %a.coerce)
+void f_floatcomplex_s_arg(struct floatcomplex_s a) {}
+
+// CHECK: define i64 @f_ret_floatcomplex_s()
+struct floatcomplex_s f_ret_floatcomplex_s() {
+  return (struct floatcomplex_s){1.0};
+}
Index: clang/lib/CodeGen/TargetInfo.cpp
===
--- clang/lib/CodeGen/TargetInfo.cpp
+++ clang/lib/CodeGen/TargetInfo.cpp
@@ -10238,7 +10238,8 @@
   uint64_t Size = getContext().getTypeSize(Ty);
 
   // Pass floating point values via FPRs if possible.
-  if (IsFixed && Ty->isFloatingType() && FLen >= Size && ArgFPRsLeft) {
+  if (IsFixed && Ty->isFloatingType() && !Ty->isComplexType() &&
+  FLen >= Size && ArgFPRsLeft) {
 ArgFPRsLeft--;
 return ABIArgInfo::getDirect();
   }


Index: clang/test/CodeGen/riscv64-lp64f-lp64d-abi.c
===
--- clang/test/CodeGen/riscv64-lp64f-lp64d-abi.c
+++ clang/test/CodeGen/riscv64-lp64f-lp64d-abi.c
@@ -165,6 +165,35 @@
   return (struct floatcomplex_s){1.0};
 }
 
+// Complex floating-point values or structs containing a single complex
+// floating-point value should be passed in GPRs if no two FPRs is available.
+
+// CHECK: define void @f_floatcomplex_insufficient_fprs1(float %a.coerce0, float

[PATCH] D79754: [OpenMP][AMDGCN] Support OpenMP offloading for AMDGCN architecture - Part 1

2020-05-17 Thread Saiyedul Islam via Phabricator via cfe-commits

saiislam updated this revision to Diff 264529.
saiislam added a comment.

Removed isOpenMPGPU() to avoid defining OpenMP compatibility of an architecture.
Reverting back to explicitly checking NVPTX and AMDGCN architectures. Also, 
split
handling of NVPTX's and AMDGCN's handling of getBuiltinID. For AMDGCN it now 
uses
OpenMPIsDevice LangOpt and returns 0 for every device library function, except 
for
printf and malloc.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79754

Files:
  clang/lib/AST/Decl.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/Driver/openmp-offload-gpu.c
  clang/test/OpenMP/target_parallel_no_exceptions.cpp
  llvm/include/llvm/ADT/Triple.h

Index: llvm/include/llvm/ADT/Triple.h
===
--- llvm/include/llvm/ADT/Triple.h
+++ llvm/include/llvm/ADT/Triple.h
@@ -692,6 +692,9 @@
 return getArch() == Triple::nvptx || getArch() == Triple::nvptx64;
   }
 
+  /// Tests whether the target is AMDGCN
+  bool isAMDGCN() const { return getArch() == Triple::amdgcn; }
+
   bool isAMDGPU() const {
 return getArch() == Triple::r600 || getArch() == Triple::amdgcn;
   }
Index: clang/test/OpenMP/target_parallel_no_exceptions.cpp
===
--- clang/test/OpenMP/target_parallel_no_exceptions.cpp
+++ clang/test/OpenMP/target_parallel_no_exceptions.cpp
@@ -1,6 +1,7 @@
 /// Make sure no exception messages are inclided in the llvm output.
 // RUN: %clang_cc1 -fopenmp -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm-bc %s -o %t-ppc-host.bc
 // RUN: %clang_cc1 -fopenmp -x c++ -std=c++11 -triple nvptx64-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck %s --check-prefix CHK-EXCEPTION
+// RUN: %clang_cc1 -fopenmp -x c++ -std=c++11 -triple x86_64-unknown-unknown -fopenmp-targets=amdgcn-amd-amdhsa -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck %s --check-prefix CHK-EXCEPTION
 
 void test_increment() {
 #pragma omp target
Index: clang/test/Driver/openmp-offload-gpu.c
===
--- clang/test/Driver/openmp-offload-gpu.c
+++ clang/test/Driver/openmp-offload-gpu.c
@@ -6,6 +6,7 @@
 // REQUIRES: x86-registered-target
 // REQUIRES: powerpc-registered-target
 // REQUIRES: nvptx-registered-target
+// REQUIRES: amdgpu-registered-target
 
 /// ###
 
@@ -249,30 +250,49 @@
 // HAS_DEBUG-SAME: "--return-at-end"
 // HAS_DEBUG: nvlink
 // HAS_DEBUG-SAME: "-g"
+// CUDA_MODE: clang{{.*}}"-cc1"{{.*}}"-triple" "{{nvptx64-nvidia-cuda|amdgcn-amd-amdhsa}}"
+// CUDA_MODE-SAME: "-fopenmp-cuda-mode"
+// NO_CUDA_MODE-NOT: "-{{fno-|f}}openmp-cuda-mode"
 
 // RUN:   %clang -### -no-canonical-prefixes -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda -Xopenmp-target -march=sm_60 %s -fopenmp-cuda-mode 2>&1 \
 // RUN:   | FileCheck -check-prefix=CUDA_MODE %s
 // RUN:   %clang -### -no-canonical-prefixes -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda -Xopenmp-target -march=sm_60 %s -fno-openmp-cuda-mode -fopenmp-cuda-mode 2>&1 \
 // RUN:   | FileCheck -check-prefix=CUDA_MODE %s
-// CUDA_MODE: clang{{.*}}"-cc1"{{.*}}"-triple" "nvptx64-nvidia-cuda"
-// CUDA_MODE-SAME: "-fopenmp-cuda-mode"
 // RUN:   %clang -### -no-canonical-prefixes -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda -Xopenmp-target -march=sm_60 %s -fno-openmp-cuda-mode 2>&1 \
 // RUN:   | FileCheck -check-prefix=NO_CUDA_MODE %s
 // RUN:   %clang -### -no-canonical-prefixes -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda -Xopenmp-target -march=sm_60 %s -fopenmp-cuda-mode -fno-openmp-cuda-mode 2>&1 \
 // RUN:   | FileCheck -check-prefix=NO_CUDA_MODE %s
-// NO_CUDA_MODE-NOT: "-{{fno-|f}}openmp-cuda-mode"
+
+// RUN:   %clang -### -no-canonical-prefixes -fopenmp=libomp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target -march=gfx906 %s -fopenmp-cuda-mode 2>&1 \
+// RUN:   | FileCheck -check-prefix=CUDA_MODE %s
+// RUN:   %clang -### -no-canonical-prefixes -fopenmp=libomp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target -march=gfx906 %s -fno-openmp-cuda-mode -fopenmp-cuda-mode 2>&1 \
+// RUN:   | FileCheck -check-prefix=CUDA_MODE %s
+// RUN:   %clang -### -no-canonical-prefixes -fopenmp=libomp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target -march=gfx906 %s -fno-openmp-cuda-mode 2>&1 \
+// RUN:   | FileCheck -check-prefix=NO_CUDA_MODE %s
+// RUN:   %clang -### -no-canonical-prefixes -fopenmp=libomp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target -march=gfx906 %s -fopenmp-cuda-mode -fno-openmp-cuda-mode 2>&1 \
+// RUN:   | FileCheck -check-prefix=NO_CUDA_MODE %s
+
+// FULL_RUNTIME: clang{{.*}}"-cc1"{{.*}}"-triple"

[clang] 7ee479a - [RISCV] Fix passing two floating-point values in complex separately by two GPRs on RV64

2020-05-17 Thread Jim Lin via cfe-commits


Author: Jim Lin
Date: 2020-05-18T13:13:22+08:00
New Revision: 7ee479a760e0a4402b4eb7fb6168768a44f66945

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

LOG: [RISCV] Fix passing two floating-point values in complex separately by two 
GPRs on RV64

Summary:
This patch fixed the error of counting the remaining FPRs. Complex 
floating-point
values should be passed by two FPRs for the hard-float ABI. If no two FPRs are
available, it should be passed via a 64-bit GPR (fp+fp). `ArgFPRsLeft` is only
decreased one while the type is complex floating-point. It causes two 
floating-point
values in the complex are passed separately by two GPRs.

Reviewers: asb, luismarques, lenary

Reviewed By: asb

Subscribers: rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, 
shiva0217, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, 
the_o, rkruppe, PkmX, jocewei, psnobl, benna, s.egerton, pzheng, 
sameer.abuasal, apazos, evandro, cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang/lib/CodeGen/TargetInfo.cpp
clang/test/CodeGen/riscv64-lp64-abi.c
clang/test/CodeGen/riscv64-lp64f-lp64d-abi.c

Removed: 




diff  --git a/clang/lib/CodeGen/TargetInfo.cpp 
b/clang/lib/CodeGen/TargetInfo.cpp
index 44608ea461ec..a4ca0b07da9e 100644
--- a/clang/lib/CodeGen/TargetInfo.cpp
+++ b/clang/lib/CodeGen/TargetInfo.cpp
@@ -10238,7 +10238,8 @@ ABIArgInfo RISCVABIInfo::classifyArgumentType(QualType 
Ty, bool IsFixed,
   uint64_t Size = getContext().getTypeSize(Ty);
 
   // Pass floating point values via FPRs if possible.
-  if (IsFixed && Ty->isFloatingType() && FLen >= Size && ArgFPRsLeft) {
+  if (IsFixed && Ty->isFloatingType() && !Ty->isComplexType() &&
+  FLen >= Size && ArgFPRsLeft) {
 ArgFPRsLeft--;
 return ABIArgInfo::getDirect();
   }

diff  --git a/clang/test/CodeGen/riscv64-lp64-abi.c 
b/clang/test/CodeGen/riscv64-lp64-abi.c
index 8347056c54d3..00d8c66af155 100644
--- a/clang/test/CodeGen/riscv64-lp64-abi.c
+++ b/clang/test/CodeGen/riscv64-lp64-abi.c
@@ -30,3 +30,24 @@ struct large f_scalar_stack_2(double a, __int128_t b, long 
double c, v32i8 d,
   uint8_t e, int8_t f, uint8_t g) {
   return (struct large){a, e, f, g};
 }
+
+// Complex floating-point values or structs containing a single complex
+// floating-point value should be passed in a GPR.
+
+// CHECK: define void @f_floatcomplex(i64 %a.coerce)
+void f_floatcomplex(float __complex__ a) {}
+
+// CHECK: define i64 @f_ret_floatcomplex()
+float __complex__ f_ret_floatcomplex() {
+  return 1.0;
+}
+
+struct floatcomplex_s { float __complex__ c; };
+
+// CHECK: define void @f_floatcomplex_s_arg(i64 %a.coerce)
+void f_floatcomplex_s_arg(struct floatcomplex_s a) {}
+
+// CHECK: define i64 @f_ret_floatcomplex_s()
+struct floatcomplex_s f_ret_floatcomplex_s() {
+  return (struct floatcomplex_s){1.0};
+}

diff  --git a/clang/test/CodeGen/riscv64-lp64f-lp64d-abi.c 
b/clang/test/CodeGen/riscv64-lp64f-lp64d-abi.c
index 9a44928cac8d..7a25cef6cadc 100644
--- a/clang/test/CodeGen/riscv64-lp64f-lp64d-abi.c
+++ b/clang/test/CodeGen/riscv64-lp64f-lp64d-abi.c
@@ -165,6 +165,35 @@ struct floatcomplex_s f_ret_floatcomplex_s() {
   return (struct floatcomplex_s){1.0};
 }
 
+// Complex floating-point values or structs containing a single complex
+// floating-point value should be passed in GPRs if no two FPRs is available.
+
+// CHECK: define void @f_floatcomplex_insufficient_fprs1(float %a.coerce0, 
float %a.coerce1, float %b.coerce0, float %b.coerce1, float %c.coerce0, float 
%c.coerce1, float %d.coerce0, float %d.coerce1, i64 %e.coerce)
+void f_floatcomplex_insufficient_fprs1(float __complex__ a, float __complex__ 
b,
+   float __complex__ c, float __complex__ 
d,
+   float __complex__ e) {}
+
+
+// CHECK: define void @f_floatcomplex_s_arg_insufficient_fprs1(float %0, float 
%1, float %2, float %3, float %4, float %5, float %6, float %7, i64 %e.coerce)
+void f_floatcomplex_s_arg_insufficient_fprs1(struct floatcomplex_s a,
+ struct floatcomplex_s b,
+ struct floatcomplex_s c,
+ struct floatcomplex_s d,
+ struct floatcomplex_s e) {}
+
+// CHECK: define void @f_floatcomplex_insufficient_fprs2(float %a, float 
%b.coerce0, float %b.coerce1, float %c.coerce0, float %c.coerce1, float 
%d.coerce0, float %d.coerce1, i64 %e.coerce)
+void f_floatcomplex_insufficient_fprs2(float a,
+   float __complex__ b, float __complex__ 
c,
+   float

[PATCH] D74166: [AIX][Frontend] Static init implementation for AIX considering no priority

2020-05-17 Thread Hubert Tong via Phabricator via cfe-commits

hubert.reinterpretcast added inline comments.



Comment at: clang/test/CodeGen/static-init.cpp:14
+// CHECK: @llvm.global_dtors = appending global [1 x { i32, void ()*, i8* }] 
[{ i32, void ()*, i8* } { i32 65535, void ()* 
@__sterm8000_clang_b2e4830f1c9d2d063e5ea946868f3bfd, i8* null }]
+// CHECK: define dso_local void @__cxx_global_var_init() #0 {
+// CHECK: entry:

Shouldn't this be `internal`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74166



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

[PATCH] D80020: [PowerPC] Add support for -mcpu=pwr10 in both clang and llvm

2020-05-17 Thread Qing Shan Zhang via Phabricator via cfe-commits

steven.zhang added inline comments.



Comment at: clang/lib/Basic/Targets/PPC.cpp:272
 .Default(false);
 
   Features["qpx"] = (CPU == "a2q");

Do we miss to define this macro ?
```
 __POWER10_VECTOR__
```



Comment at: llvm/lib/Target/PowerPC/PPC.td:211
+ "true",
+ "Enable instructions added in ISA 3.1.">;
 def FeatureP9Altivec : SubtargetFeature<"power9-altivec", "HasP9Altivec", 
"true",

Nit: no ending dot.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80020



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

[PATCH] D80020: [PowerPC] Add support for -mcpu=pwr10 in both clang and llvm

2020-05-17 Thread Qing Shan Zhang via Phabricator via cfe-commits

steven.zhang added inline comments.



Comment at: clang/lib/Basic/Targets/PPC.cpp:272
 .Default(false);
 
   Features["qpx"] = (CPU == "a2q");

steven.zhang wrote:
> Do we miss to define this macro ?
> ```
>  __POWER10_VECTOR__
> ```
Well, pls ignore this comments as that macro should be added when p10 vector 
feature is added.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80020



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

[PATCH] D77704: [gold] Add support for loading pass plugins

2020-05-17 Thread Dominic Chen via Phabricator via cfe-commits

ddcc added a comment.

ping, any feedback?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77704



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

[PATCH] D79704: [Analyzer] [NFC] Parameter Regions

2020-05-17 Thread Artem Dergachev via Phabricator via cfe-commits

NoQ added a comment.

> It turns out that parameter regions are never created for functions without 
> `Decl` because of the first lines in 
> `CallEvent::getCalleeAnalysisDeclContext()`.

Removing these lines is more or less the whole point of your work.


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

https://reviews.llvm.org/D79704



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

[PATCH] D79704: [Analyzer] [NFC] Parameter Regions

2020-05-17 Thread Artem Dergachev via Phabricator via cfe-commits

NoQ added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/MemRegion.cpp:191
+const ParmVarDecl *ParamRegion::getDecl() const {
+  const Decl *D = getStackFrame()->getDecl();
+

baloghadamsoftware wrote:
> NoQ wrote:
> > baloghadamsoftware wrote:
> > > NoQ wrote:
> > > > baloghadamsoftware wrote:
> > > > > NoQ wrote:
> > > > > > This doesn't work when the callee is unknown.
> > > > > Please give me an example where the callee is unknown. As I wrote, 
> > > > > originally I put a `getExpr()` method here as well and `getType()` 
> > > > > fell back to it if it could not find the `Decl()`. However, it was 
> > > > > never invoked on the whole test suite. (I put an `assert(false)` into 
> > > > > it, and did not get a crash.
> > > > > Please give me an example where the callee is unknown.
> > > > 
> > > > >>! In D79704#2034571, @NoQ wrote:
> > > > >>>! In D79704#2032947, @Szelethus wrote:
> > > > >> Could you give a specific code example? 
> > > > > 
> > > > > ```lang=c++
> > > > > struct S {
> > > > >   S() {
> > > > > this; // What region does 'this' point to...
> > > > >   }
> > > > > };
> > > > > 
> > > > > void foo(void (*bar)(S)) {
> > > > >   bar(S()); // ...in this invocation?
> > > > > }
> > > > > ```
> > > OK, but it still does not crash the analyzer, even if I enable creation 
> > > of stack frames for all the callees, even for those without definition. 
> > > What else should I do to enforce the crash (null pointer dereference)? 
> > > Try to use `getParameterLocation()` in a unit test?
> > Yes. I demonstrated how you can get the region without a decl but you 
> > should turn this into a test that actually calls one of the problematic 
> > functions. Like, `clang_analyzer_dump()` it or something.
> Of  course I tried `clang_analyzer_explain()`, but neither 
> `clang_analyzer_dump()` helps. I also tried a unit test now where I call 
> `getParameterLocation()` explicitly. It turns out that parameter regions are 
> never created for functions without `Decl` because of the first lines in 
> `CallEvent::getCalleeAnalysisDeclContext()`. This function //needs// the 
> `Decl` to retrieve the `AnalysisDeclContext` of the callee, which is needed 
> to retrieve its stack  frame by `getCalleeStackFrame()`. Without stack frame 
> we do not create `ParamRegion`. The other two functions creating 
> `ParamRegion` (`CallEvent::addParameterValuesToBindings` and the newly 
> created `MemRegionManager::getRegionForParam`) start from `ParmVarDecl` which 
> always belongs to a `Decl`. So we can safely assume that currently all 
> parameter regions have a `Decl`. Of course, this can be changed in the 
> future, but I must not include dead code in a patch that cannot even be 
> tested in the current phase. Even creation of callee stack frame for 
> functions without //definition// is not part of this patch, but of the 
> subsequent one.
> neither `clang_analyzer_dump()` helps

So, does it dump a parameter region? Because it obviously should.


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

https://reviews.llvm.org/D79704



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

[PATCH] D80054: [ASTMatchers] Added BinaryOperator hasOperands matcher

2020-05-17 Thread Nathan James via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG74bcb00e00f3: [ASTMatchers] Added BinaryOperator hasOperands 
matcher (authored by njames93).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80054

Files:
  clang/docs/LibASTMatchersReference.html
  clang/include/clang/ASTMatchers/ASTMatchers.h
  clang/lib/ASTMatchers/Dynamic/Registry.cpp
  clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp


Index: clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
@@ -1160,6 +1160,17 @@
   EXPECT_TRUE(notMatches("void x() { true || true; }", HasOperand));
 }
 
+TEST(MatchBinaryOperator, HasOperands) {
+  StatementMatcher HasOperands = binaryOperator(
+  hasOperands(integerLiteral(equals(1)), integerLiteral(equals(2;
+  EXPECT_TRUE(matches("void x() { 1 + 2; }", HasOperands));
+  EXPECT_TRUE(matches("void x() { 2 + 1; }", HasOperands));
+  EXPECT_TRUE(notMatches("void x() { 1 + 1; }", HasOperands));
+  EXPECT_TRUE(notMatches("void x() { 2 + 2; }", HasOperands));
+  EXPECT_TRUE(notMatches("void x() { 0 + 0; }", HasOperands));
+  EXPECT_TRUE(notMatches("void x() { 0 + 1; }", HasOperands));
+}
+
 TEST(Matcher, BinaryOperatorTypes) {
   // Integration test that verifies the AST provides all binary operators in
   // a way we expect.
Index: clang/lib/ASTMatchers/Dynamic/Registry.cpp
===
--- clang/lib/ASTMatchers/Dynamic/Registry.cpp
+++ clang/lib/ASTMatchers/Dynamic/Registry.cpp
@@ -294,6 +294,7 @@
   REGISTER_MATCHER(hasName);
   REGISTER_MATCHER(hasNullSelector);
   REGISTER_MATCHER(hasObjectExpression);
+  REGISTER_MATCHER(hasOperands);
   REGISTER_MATCHER(hasOperatorName);
   REGISTER_MATCHER(hasOverloadedOperatorName);
   REGISTER_MATCHER(hasParameter);
Index: clang/include/clang/ASTMatchers/ASTMatchers.h
===
--- clang/include/clang/ASTMatchers/ASTMatchers.h
+++ clang/include/clang/ASTMatchers/ASTMatchers.h
@@ -4869,6 +4869,23 @@
   return anyOf(hasLHS(InnerMatcher), hasRHS(InnerMatcher));
 }
 
+/// Matches if both matchers match with opposite sides of the binary operator.
+///
+/// Example matcher = binaryOperator(hasOperands(integerLiteral(equals(1),
+///  integerLiteral(equals(2)))
+/// \code
+///   1 + 2 // Match
+///   2 + 1 // Match
+///   1 + 1 // No match
+///   2 + 2 // No match
+/// \endcode
+inline internal::Matcher
+hasOperands(const internal::Matcher ,
+const internal::Matcher ) {
+  return anyOf(allOf(hasLHS(Matcher1), hasRHS(Matcher2)),
+   allOf(hasLHS(Matcher2), hasRHS(Matcher1)));
+}
+
 /// Matches if the operand of a unary operator matches.
 ///
 /// Example matches true (matcher = hasUnaryOperand(
Index: clang/docs/LibASTMatchersReference.html
===
--- clang/docs/LibASTMatchersReference.html
+++ clang/docs/LibASTMatchersReference.html
@@ -5033,6 +5033,18 @@
 
 
 
+Matcherhttps://clang.llvm.org/doxygen/classclang_1_1BinaryOperator.html;>BinaryOperatorhasOperandsMatcherhttps://clang.llvm.org/doxygen/classclang_1_1Expr.html;>Expr  
Matcher1, Matcherhttps://clang.llvm.org/doxygen/classclang_1_1Expr.html;>Expr  
Matcher2
+Matches if both 
matchers match with opposite sides of the binary operator.
+
+Example matcher = binaryOperator(hasOperands(integerLiteral(equals(1),
+ integerLiteral(equals(2)))
+  1 + 2 // Match
+  2 + 1 // Match
+  1 + 1 // No match
+  2 + 2 // No match
+
+
+
 Matcherhttps://clang.llvm.org/doxygen/classclang_1_1BinaryOperator.html;>BinaryOperatorhasRHSMatcherhttps://clang.llvm.org/doxygen/classclang_1_1Expr.html;>Expr 
InnerMatcher
 Matches the right hand side 
of binary operator expressions.
 


Index: clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
@@ -1160,6 +1160,17 @@
   EXPECT_TRUE(notMatches("void x() { true || true; }", HasOperand));
 }
 
+TEST(MatchBinaryOperator, HasOperands) {
+  StatementMatcher HasOperands = binaryOperator(
+  hasOperands(integerLiteral(equals(1)), integerLiteral(equals(2;
+  EXPECT_TRUE(matches("void x() { 1 + 2; }", HasOperands));
+  EXPECT_TRUE(matches("void x() { 2 + 1; }", HasOperands));
+  EXPECT_TRUE(notMatches("void x() { 1 + 1; }", HasOperands));
+  EXPECT_TRUE(notMatches("void x() { 2 + 2; }", HasOperands));
+  EXPECT_TRUE(notMatches("void x() { 0 + 0; }", HasOperands));
+  EXPECT_TRUE(notMatches("void x() { 0 + 1;

[PATCH] D79961: [PGO] Fix computation of fuction Hash

2020-05-17 Thread Fangrui Song via Phabricator via cfe-commits

MaskRay added inline comments.



Comment at: clang/lib/CodeGen/CodeGenPGO.cpp:759
   MD5.final(Result);
   using namespace llvm::support;
   return Result.low();

Can the using be deleted?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79961



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

[PATCH] D79961: [PGO] Fix computation of fuction Hash

2020-05-17 Thread Fangrui Song via Phabricator via cfe-commits

MaskRay added a comment.

This patch is correct. A clarification of the description:

> Previous implementation was incorrectly passing an integer, that got 
> converted to a pointer, to finalize the hash computation.

Working (an `uint64_t`) was truncated to an `uint8_t`, converted to a 
one-element `ArrayRef`, then passed to `MD5.update`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79961



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

[clang] 74bcb00 - [ASTMatchers] Added BinaryOperator hasOperands matcher

2020-05-17 Thread Nathan James via cfe-commits


Author: Nathan James
Date: 2020-05-17T19:54:14+01:00
New Revision: 74bcb00e00f3ef971e4c584a124e99289f2ebf34

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

LOG: [ASTMatchers] Added BinaryOperator hasOperands matcher

Summary: Adds a matcher called `hasOperands` for `BinaryOperator`'s when you 
need to match both sides but the order isn't important, usually on commutative 
operators.

Reviewers: klimek, aaron.ballman, gribozavr2, alexfh

Reviewed By: aaron.ballman

Subscribers: cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang/docs/LibASTMatchersReference.html
clang/include/clang/ASTMatchers/ASTMatchers.h
clang/lib/ASTMatchers/Dynamic/Registry.cpp
clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp

Removed: 




diff  --git a/clang/docs/LibASTMatchersReference.html 
b/clang/docs/LibASTMatchersReference.html
index f5106f0e0ba2..f57352389e4c 100644
--- a/clang/docs/LibASTMatchersReference.html
+++ b/clang/docs/LibASTMatchersReference.html
@@ -5033,6 +5033,18 @@ AST Traversal Matchers
 
 
 
+Matcherhttps://clang.llvm.org/doxygen/classclang_1_1BinaryOperator.html;>BinaryOperatorhasOperandsMatcherhttps://clang.llvm.org/doxygen/classclang_1_1Expr.html;>Expr  
Matcher1, Matcherhttps://clang.llvm.org/doxygen/classclang_1_1Expr.html;>Expr  
Matcher2
+Matches if both 
matchers match with opposite sides of the binary operator.
+
+Example matcher = binaryOperator(hasOperands(integerLiteral(equals(1),
+ integerLiteral(equals(2)))
+  1 + 2 // Match
+  2 + 1 // Match
+  1 + 1 // No match
+  2 + 2 // No match
+
+
+
 Matcherhttps://clang.llvm.org/doxygen/classclang_1_1BinaryOperator.html;>BinaryOperatorhasRHSMatcherhttps://clang.llvm.org/doxygen/classclang_1_1Expr.html;>Expr 
InnerMatcher
 Matches the right hand side 
of binary operator expressions.
 

diff  --git a/clang/include/clang/ASTMatchers/ASTMatchers.h 
b/clang/include/clang/ASTMatchers/ASTMatchers.h
index ce702bc44edd..460962d9e73b 100644
--- a/clang/include/clang/ASTMatchers/ASTMatchers.h
+++ b/clang/include/clang/ASTMatchers/ASTMatchers.h
@@ -4869,6 +4869,23 @@ inline internal::Matcher 
hasEitherOperand(
   return anyOf(hasLHS(InnerMatcher), hasRHS(InnerMatcher));
 }
 
+/// Matches if both matchers match with opposite sides of the binary operator.
+///
+/// Example matcher = binaryOperator(hasOperands(integerLiteral(equals(1),
+///  integerLiteral(equals(2)))
+/// \code
+///   1 + 2 // Match
+///   2 + 1 // Match
+///   1 + 1 // No match
+///   2 + 2 // No match
+/// \endcode
+inline internal::Matcher
+hasOperands(const internal::Matcher ,
+const internal::Matcher ) {
+  return anyOf(allOf(hasLHS(Matcher1), hasRHS(Matcher2)),
+   allOf(hasLHS(Matcher2), hasRHS(Matcher1)));
+}
+
 /// Matches if the operand of a unary operator matches.
 ///
 /// Example matches true (matcher = hasUnaryOperand(

diff  --git a/clang/lib/ASTMatchers/Dynamic/Registry.cpp 
b/clang/lib/ASTMatchers/Dynamic/Registry.cpp
index e7659feaf1e9..0a7d09e55c88 100644
--- a/clang/lib/ASTMatchers/Dynamic/Registry.cpp
+++ b/clang/lib/ASTMatchers/Dynamic/Registry.cpp
@@ -294,6 +294,7 @@ RegistryMaps::RegistryMaps() {
   REGISTER_MATCHER(hasName);
   REGISTER_MATCHER(hasNullSelector);
   REGISTER_MATCHER(hasObjectExpression);
+  REGISTER_MATCHER(hasOperands);
   REGISTER_MATCHER(hasOperatorName);
   REGISTER_MATCHER(hasOverloadedOperatorName);
   REGISTER_MATCHER(hasParameter);

diff  --git a/clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp 
b/clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
index 2972fc91b908..0c9a3d9eb1ed 100644
--- a/clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
+++ b/clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
@@ -1160,6 +1160,17 @@ TEST(MatchBinaryOperator, HasEitherOperand) {
   EXPECT_TRUE(notMatches("void x() { true || true; }", HasOperand));
 }
 
+TEST(MatchBinaryOperator, HasOperands) {
+  StatementMatcher HasOperands = binaryOperator(
+  hasOperands(integerLiteral(equals(1)), integerLiteral(equals(2;
+  EXPECT_TRUE(matches("void x() { 1 + 2; }", HasOperands));
+  EXPECT_TRUE(matches("void x() { 2 + 1; }", HasOperands));
+  EXPECT_TRUE(notMatches("void x() { 1 + 1; }", HasOperands));
+  EXPECT_TRUE(notMatches("void x() { 2 + 2; }", HasOperands));
+  EXPECT_TRUE(notMatches("void x() { 0 + 0; }", HasOperands));
+  EXPECT_TRUE(notMatches("void x() { 0 + 1; }", HasOperands));
+}
+
 TEST(Matcher, BinaryOperatorTypes) {
   // Integration test that verifies the AST provides all binary operators in
   // a way we expect.



___
cfe-commits mailing list

[PATCH] D68115: Zero initialize padding in unions

2020-05-17 Thread JF Bastien via Phabricator via cfe-commits

jfb added a comment.

In D68115#2040696 , @tschuett wrote:

> As an outsider: In Swift, reading an uninitialized variable is a compile-time 
> error. Clang is not powerful enough to do this analysis. Aren't you really 
> looking for the Clang Intermediate Language (CIL) ?


I have an entire talk about this: https://www.youtube.com/watch?v=I-XUHPimq3o


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68115



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

[PATCH] D79744: clang: Add address space to indirect abi info and use it for kernels

2020-05-17 Thread John McCall via Phabricator via cfe-commits

rjmccall added a comment.

In D79744#2040434 , @jdoerfert wrote:

> In D79744#2040380 , @rjmccall wrote:
>
> > In D79744#2040348 , @jdoerfert 
> > wrote:
> >
> > > Drive by, I haven't read the entire history.
> > >
> > > In D79744#2040208 , @rjmccall 
> > > wrote:
> > >
> > > > I don't understand why `noalias` is even a concern if the whole buffer 
> > > > passed to the kernel is read-only.  `noalias` is primarily about 
> > > > proving non-interference, but if you can tell IR that the buffer is 
> > > > read-only, that's a much more powerful statement.
> > >
> > >
> > > The problem is that it is a "per-pointer" attribute and not "per-object". 
> > > Given two argument pointers, where one is marked `readonly`, may still 
> > > alias. Similarly, an access to a global, indirect accesses, ... can write 
> > > the "readonly" memory.
> >
> >
> > Oh, do we really not have a way to mark that memory is known to be truly 
> > immutable for a time?  That seems like a really bad limitation.  It should 
> > be doable with a custom alias analysis at least.
>
>
> `noalias` + `readone` on an argument basically implies immutable for the 
> function scope. I think we have invariant intrinsics that could do the trick 
> as well, though I'm not too familiar with those. I was eventually hoping for 
> paired/scoped `llvm.assumes` which would allow `noalias` + `readnone` again. 
> Then there is `invariant` which can be placed on a load instruction. Finally, 
> TBAA has a "constant memory" tag (or something like that), but again it is a 
> per-access thing. That are all the in-tree ways I can think of right now.
>
> Custom alias analysis can probably be used to some degree but except address 
> spaces I'm unsure we have much that you can attach to a pointer and that 
> "really sticks".
>
> >>> Regardless, if you do need `noalias`, you should be able to emit the same 
> >>> IR that we'd emit if pointers to all the fields were assigned into 
> >>> `restrict` local variables and then only those variables were 
> >>> subsequently used.
> >> 
> >> We are still debating the local restrict pointer support. Once we merge 
> >> that in it should be usable here.
> > 
> > I thought that was finished a few years ago; is it really not considered 
> > usable yet?  Or does "we" not just mean LLVM here?
>
> Yes, I meant "we" = LLVM here. Maybe we talk about different things. I was 
> referring to local restrict qualified variables, e.g., `double * __restrict 
> Ptr = ...`. The proposal to not just ignore the restrict (see 
> https://godbolt.org/z/jLzjR3) came last year, it was a big one and progress 
> unfortunately stalled (partly my fault). Now we are just about to see a 
> second push to get it done.
>  Is that what you meant too?


I thought I remembered Hal doing a lot of work on local restrict a few years 
ago.  I'm probably just misremembering, or I didn't realize that the work never 
landed or got pulled out later.

Okay.  So where we're at is that you'd like to add a new argument-passing 
convention that's basically "passed indirect but immutable", implying that the 
frontend has to copy it in order to create the mutable local parameter.  That's 
not actually a totally ridiculous convention in principle, although it has poor 
worst-case behavior (copies on both sides), and that happens to be what the 
frontend will often have to conservatively emit.  I would still prefer not to 
add new argument-passing conventions just to satisfy short-term optimization 
needs, though.  Are there any other reasonable options?


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

https://reviews.llvm.org/D79744



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

[PATCH] D75791: [clang-format] Added new option IndentExternBlock

2020-05-17 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay added inline comments.



Comment at: clang/include/clang/Format/Format.h:1555
+  IndentExternBlockStyle IndentExternBlock;
+
   /// A vector of prefixes ordered by the desired groups for Java imports.

Something is not quie right here, this text isn't ending up in the 
ClangFormatStyleOptions.rst


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

https://reviews.llvm.org/D75791



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

[PATCH] D68115: Zero initialize padding in unions

2020-05-17 Thread Thorsten via Phabricator via cfe-commits

tschuett added a comment.

As an outsider: In Swift, reading an uninitialized variable is a compile-time 
error. Clang is not powerful enough to do this analysis. Aren't you really 
looking for the Clang Intermediate Language (CIL) ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68115



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

[PATCH] D77491: [Sema] Introduce BuiltinAttr, per-declaration builtin-ness

2020-05-17 Thread Raul Tambre via Phabricator via cfe-commits

tambre marked 4 inline comments as done.
tambre added a comment.

Thanks for the reviews and design pointers, John!

There are still a few tests failing, but I'd rather not dive in before the 
general approach is considered acceptable.

Comment at: clang/lib/Sema/SemaDecl.cpp:8880
+  }
+}
+

rjmccall wrote:
> Hmm.  I'm concerned about not doing any sort of semantic compatibility check 
> here before we assign the function special semantics.  Have we really never 
> done those in C++?
> 
> If not, I wonder if we can reasonably make an implicit declaration but just 
> make it hidden from lookup.
Currently there's no semantic compatibility checking for builtin 
redeclarations. There is for initial declarations though.

I've added this checking by splitting the actual builtin declaration creation 
off from `LazilyCreateBuiltin` into `CreateBuiltin` and checking if the current 
declaration is compatible with what the builtin's would be.
This results in stronger typechecking than before for builtin declarations, so 
some incompatible declarations are no longer marked as builtin. See 
`cxx1z-noexcept-function-type.cpp` for an example.

Comment at: clang/lib/Sema/SemaExpr.cpp:6047
   OverloadDecl->setParams(Params);
+  Sema->mergeDeclAttributes(OverloadDecl, FDecl);
   return OverloadDecl;

`rewriteBuiltinFunctionDecl()` creates a new function declaration and happened 
to disregard the builtin's attributes. This caused `BuiltinAttr` to go missing 
in a bunch of OpenCL tests, resulting in failures.

Comment at: clang/test/Sema/warn-fortify-source.c:20
 void *memcpy(void *dst, const void *src, size_t c);
 static void *memcpy(void *dst __attribute__((pass_object_size(1))), const void 
*src, size_t c) __attribute__((overloadable)) __asm__("merp");
 static void *memcpy(void *const dst __attribute__((pass_object_size(1))), 
const void *src, size_t c) __attribute__((overloadable)) {

Not quite sure what to do here. These were previously recognized as builtins 
due to their name despite being incompatible and thus had fortify checking 
similar to the real `memcpy`.

Maybe:
1. Introduce a generic version of `ArmBuiltinAliasAttr`.
2. Something like `FormatAttr`.

Comment at: clang/test/SemaCXX/cxx11-compat.cpp:35
+#define PRIuS "zu"
 int printf(const char *, ...);
 typedef __typeof(sizeof(int)) size_t;

For some reason this `printf` didn't get format checking before. Same for 
`SemaCXX/warn-unused-local-typedef.cpp`.

Comment at: clang/test/SemaCXX/cxx1z-noexcept-function-type.cpp:120
   extern "C" int strcmp(const char *, const char *);
-  extern "C" int strncmp(const char *, const char *, decltype(sizeof(0))) 
noexcept;
+  extern "C" int strncmp(const char *, const char *, decltype(sizeof(0)));

This doesn't work anymore since we now properly check builtin declaration 
compatibility and since C++17 noexcept is part of the function type but 
builtins aren't noexcept.
Thoughts?

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77491

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

[PATCH] D75791: [clang-format] Added new option IndentExternBlock

2020-05-17 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay added a comment.

Please clang-format the patch


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

https://reviews.llvm.org/D75791



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

[PATCH] D77491: [Sema] Introduce BuiltinAttr, per-declaration builtin-ness

2020-05-17 Thread Raul Tambre via Phabricator via cfe-commits

tambre updated this revision to Diff 264497.
tambre marked an inline comment as not done.
tambre added a comment.

Semantic compatibility checking for C++ builtin redeclarations.
Remove some now unnecessary logic from getBuiltinID().
Update more tests. 4 tests still failing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77491

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/IdentifierTable.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/Decl.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaLookup.cpp
  clang/test/AST/ast-dump-attr.cpp
  clang/test/CodeGen/builtin-redeclaration.c
  clang/test/CodeGen/callback_pthread_create.c
  clang/test/CodeGen/ms-intrinsics.c
  clang/test/Sema/implicit-builtin-decl.c
  clang/test/Sema/warn-fortify-source.c
  clang/test/SemaCXX/cxx11-compat.cpp
  clang/test/SemaCXX/cxx1z-noexcept-function-type.cpp
  clang/test/SemaCXX/warn-unused-local-typedef.cpp

Index: clang/test/SemaCXX/warn-unused-local-typedef.cpp
===
--- clang/test/SemaCXX/warn-unused-local-typedef.cpp
+++ clang/test/SemaCXX/warn-unused-local-typedef.cpp
@@ -67,10 +67,10 @@
 
 void test() {
   typedef signed long int superint; // no diag
-  printf("%f", (superint) 42);
+  printf("%ld", (superint)42);
 
   typedef signed long int superint2; // no diag
-  printf("%f", static_cast(42));
+  printf("%ld", static_cast(42));
 
 #pragma clang diagnostic push
 #pragma clang diagnostic ignored "-Wunused-local-typedef"
Index: clang/test/SemaCXX/cxx1z-noexcept-function-type.cpp
===
--- clang/test/SemaCXX/cxx1z-noexcept-function-type.cpp
+++ clang/test/SemaCXX/cxx1z-noexcept-function-type.cpp
@@ -117,7 +117,7 @@
 namespace Builtins {
   // Pick two functions that ought to have the same noexceptness.
   extern "C" int strcmp(const char *, const char *);
-  extern "C" int strncmp(const char *, const char *, decltype(sizeof(0))) noexcept;
+  extern "C" int strncmp(const char *, const char *, decltype(sizeof(0)));
 
   // Check we recognized both as builtins.
   typedef int arr[strcmp("bar", "foo") + 4 * strncmp("foo", "bar", 4)];
Index: clang/test/SemaCXX/cxx11-compat.cpp
===
--- clang/test/SemaCXX/cxx11-compat.cpp
+++ clang/test/SemaCXX/cxx11-compat.cpp
@@ -31,7 +31,7 @@
 s = { n }, // expected-warning {{non-constant-expression cannot be narrowed from type 'int' to 'char' in initializer list in C++11}} expected-note {{explicit cast}}
 t = { 1234 }; // expected-warning {{constant expression evaluates to 1234 which cannot be narrowed to type 'char' in C++11}} expected-warning {{changes value}} expected-note {{explicit cast}}
 
-#define PRIuS "uS"
+#define PRIuS "zu"
 int printf(const char *, ...);
 typedef __typeof(sizeof(int)) size_t;
 void h(size_t foo, size_t bar) {
Index: clang/test/Sema/warn-fortify-source.c
===
--- clang/test/Sema/warn-fortify-source.c
+++ clang/test/Sema/warn-fortify-source.c
@@ -1,10 +1,12 @@
 // RUN: %clang_cc1 -triple x86_64-apple-macosx10.14.0 %s -verify
-// RUN: %clang_cc1 -triple x86_64-apple-macosx10.14.0 %s -verify -DUSE_PASS_OBJECT_SIZE
 // RUN: %clang_cc1 -triple x86_64-apple-macosx10.14.0 %s -verify -DUSE_BUILTINS
 // RUN: %clang_cc1 -xc++ -triple x86_64-apple-macosx10.14.0 %s -verify
-// RUN: %clang_cc1 -xc++ -triple x86_64-apple-macosx10.14.0 %s -verify -DUSE_PASS_OBJECT_SIZE
 // RUN: %clang_cc1 -xc++ -triple x86_64-apple-macosx10.14.0 %s -verify -DUSE_BUILTINS
 
+// FIXME: Incompatible builtin redeclarations aren't considered builtins and thus don't call the builtin nor inherit their attributes.
+// %clang_cc1 -triple x86_64-apple-macosx10.14.0 %s -verify -DUSE_PASS_OBJECT_SIZE
+// %clang_cc1 -xc++ -triple x86_64-apple-macosx10.14.0 %s -verify -DUSE_PASS_OBJECT_SIZE
+
 typedef unsigned long size_t;
 
 #ifdef __cplusplus
Index: clang/test/Sema/implicit-builtin-decl.c
===
--- clang/test/Sema/implicit-builtin-decl.c
+++ clang/test/Sema/implicit-builtin-decl.c
@@ -60,12 +60,15 @@
 
 extern float fmaxf(float, float);
 
-struct __jmp_buf_tag {};
-void sigsetjmp(struct __jmp_buf_tag[1], int); // expected-warning{{declaration of built-in function 'sigsetjmp' requires the declaration of the 'jmp_buf' type, commonly provided in the header .}}
+typedef struct __jmp_buf_tag {
+} sigjmp_buf[1];
 
-// CHECK: FunctionDecl {{.*}}  col:6 sigsetjmp '
+int sigsetjmp(struct __jmp_buf_tag[1], int);
+
+// CHECK: FunctionDecl {{.*}}  col:5 implicit sigsetjmp '
+// CHECK: FunctionDecl {{.*}}  col:5 sigsetjmp '
 // CHECK-NOT: FunctionDecl
-// CHECK: ReturnsTwiceAttr {{.*}} <{{.*}}> Implicit
+// CHECK: ReturnsTwiceAttr {{.*}} <{{.*}}>

[PATCH] D80054: [ASTMatchers] Added BinaryOperator hasOperands matcher

2020-05-17 Thread Aaron Ballman via Phabricator via cfe-commits

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

LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80054



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

[PATCH] D72530: Set traversal explicitly where needed in clang-tidy

2020-05-17 Thread Aaron Ballman via Phabricator via cfe-commits

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

In D72530#2040521 , @steveire wrote:

> In D72530#2038561 , @aaron.ballman 
> wrote:
>
> > The changes here look reasonable, but can some of this code be simplified 
> > to use the default behavior and less complex matchers that don't have to 
> > carefully ignore implicit nodes? This would demonstrate that the feature 
> > really is an improvement over the status quo and would also exercise more 
> > test code with the new defaults demonstrating equivalence. I'm not 
> > envisioning anything onerous, more just wondering if you think there is 
> > some low-hanging fruit that could be picked rather than converting 
> > everything to AsIs.
>
>
> After changing the default there will be opportunities for that as a 
> follow-up, yes. But this patch is ordered before changing the default. The 
> change you describe is a follow-up. What I am doing with that ordering is 
> called "non-atomic refactoring".
>
> Here's an example of such a future change: 
> https://gist.github.com/steveire/32fbf457377bc6c57bd3906cc9c8fb9c

Thanks for the example, that's the kind of improvement I was hoping to see. 
Given that one of the claims in the RFC is that this makes writing matchers 
easier, I think it's reasonable to expect a patch showing that it actually does 
make writing those matchers more simple. I suppose I'm fine if it's a separate 
patch from this one, but I'd slightly prefer it was done in this patch so that 
we don't churn the code unnecessarily (and it makes it easier to do the 
comparison between the original code and the code for simplified matcher, as 
your changes here are adding interim complexity). Regardless, I'd like to see a 
patch that shows some of these simplifications as part of this patch set (if 
not this specific review).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72530

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

[PATCH] D72531: Set traversal explicitly where needed in tests

2020-05-17 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added inline comments.



Comment at: clang/unittests/Tooling/StencilTest.cpp:63
   ASTContext  = AstUnit->getASTContext();
-  auto Matches = ast_matchers::match(wrapMatcher(Matcher), Context);
+  auto Matches = ast_matchers::match(
+  traverse(ast_type_traits::TK_AsIs, wrapMatcher(Matcher)), Context);

steveire wrote:
> aaron.ballman wrote:
> > Was this change made because you didn't want to accept the traversal mode 
> > as a parameter to `matchStmt` and force each caller to decide which mode 
> > they use? Or is there some other reason why this change was needed?
> Yes, the test currently expects `AsIs`. If someone wanted to change that in 
> the future, that is an issue for future work.
You say "the test" as though there's only one. There are numerous tests which 
use `matchStmt`. Do *all* of the tests require `AsIs`? (I think that's an 
example of what's causing some of the confusion @shafik and I had and I'm 
trying to ensure his question gets answered and that I'm fully understanding 
your changes.) From spot-checking, it looks like there are tests using 
`matchStmt` that don't need `AsIs` traversal and that this sort of cleanup work 
could happen in the future, but for now you're going with the easiest approach 
instead of expanding the test coverage for ignoring implicit nodes; is that 
correct?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72531



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

[PATCH] D75791: [clang-format] Added new option IndentExternBlock

2020-05-17 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay added a comment.

In D75791#2040558 , @MarcusJohnson91 
wrote:

> In D75791#2040532 , @MyDeveloperDay 
> wrote:
>
> > LGTM
>
>
> So what's the next step? I've never committed to LLVM before.


In my mind you have two choices

1. require commit access
2. get someone else to land it

If you think you'd like to continue to be involved and maybe help out from time 
to time (especially with reviews which is where we REALLY lack people) then I 
would recommend 1)

but I'm happy to do 2) for you if not, but you have to be prepared to support 
the patch a little afterwards. (no fire and forget please ;-) )


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

https://reviews.llvm.org/D75791



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

[PATCH] D78491: Avoid relying on address space zero default parameter in llvm/IR

2020-05-17 Thread Alexander Richardson via Phabricator via cfe-commits

arichardson added a comment.

In D78491#2040424 , @dylanmckay wrote:

> I really like the idea behind this patch, but I suspect there is a better way 
> to go about it.
>
> The only drawbacks to upstreaming this patch as-is is the idea that because 
> it is implemented as a compiler define directive, it effectively splinters 
> the the core LLVM C++ API into two different versions. Of course, this is 
> kind of the point, but my only worry is that the `LLVM_DEFAULT_AS_PARAM` 
> macro adds an additional layer of complexity to all users of the API that 
> will be encountered and must be considered.
>
> I think, if we have already identified all the call sites that break under 
> the `LLVM_DEFAULT_AS_PARAM` patch, then we should instead make two final 
> patches that fix the root rather than add the `LLVM_DEFAULT_AS_PARAM` for 
> retroactive discovery. 1) replace all calls to `getUnqual` with the 
> appropriate logic, which it looks like you've already done, and 2) remove the 
> default value of `0` from all address space parameters so the callers *must* 
> explicitly pass the address space in. I think that 2) would be hard to swing 
> in the past whilst AVR was an experimental target, but now that AVR is an 
> officially supported LLVM target, it is invariably true that all calls to 
> `getOrCreateInternalVariable` and friends without explicit address spaces 
> will break an officially supported in-tree target. It no longer makes sense 
> to default to zero, so let's fix the root cause.
>
> This would the problem at the root, stopping all new LLVM code from 
> implicitly defaulting to address space `0`. This still leaves open the 
> problem of developers explicitly calling `getUnqual` when constructing 
> pointers, but this problem is left open under this patch currently as 
> regardless of the default parameter or not, calls to `getUnqual` are still 
> allowed.
>
> **tl;dr** I suggest removing the `LLVM_DEFAULT_AS_PARAM` directive from this 
> patch, instead permanently removing the default value of `= 0`. This will 
> achieve the same end result, but it will fix the broken API rather than just 
> making it easier for downstream users like CHERI to discover.
>
> What are your thoughts?


I would love to do that, but it would require many hundreds of changes. This is 
why I decided to go for a per-directory opt-in approach. 
The next step would be to change it to an opt-out and finally remove it.

I can try inverting the logic to explicitly request implicit address space zero 
and see how many CMakeLists.txt need changing.
The benefit of that approach would be that new directories will automatically 
require explicit address spaces.

One reason the default AS macro might be useful is for out-of-tree consumers of 
the LLVM libraries that always use address space zero and changing it would 
require large update costs to move to LLVM 11+.
I'm not sure that's a reason though since the APIs are not considered stable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78491



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

[PATCH] D80079: [clang-format] [NFC] isCpp() is inconsistently used to mean both C++ and Objective C, add language specific isXXX() functions

2020-05-17 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay updated this revision to Diff 264495.

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

https://reviews.llvm.org/D80079

Files:
  clang/include/clang/Format/Format.h
  clang/lib/Format/BreakableToken.cpp
  clang/lib/Format/ContinuationIndenter.cpp
  clang/lib/Format/Format.cpp
  clang/lib/Format/FormatToken.h
  clang/lib/Format/FormatTokenLexer.cpp
  clang/lib/Format/TokenAnnotator.cpp
  clang/lib/Format/UnwrappedLineFormatter.cpp
  clang/lib/Format/UnwrappedLineParser.cpp

Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -299,11 +299,10 @@
 void UnwrappedLineParser::parseFile() {
   // The top-level context in a file always has declarations, except for pre-
   // processor directives and JavaScript files.
-  bool MustBeDeclaration =
-  !Line->InPPDirective && Style.Language != FormatStyle::LK_JavaScript;
+  bool MustBeDeclaration = !Line->InPPDirective && !Style.isJavaScript();
   ScopedDeclarationState DeclarationState(*Line, DeclarationScopeStack,
   MustBeDeclaration);
-  if (Style.Language == FormatStyle::LK_TextProto)
+  if (Style.isTextProtoBuf())
 parseBracedList();
   else
 parseLevel(/*HasOpeningBrace=*/false);
@@ -317,8 +316,7 @@
   //   // endfile comment
   // do not have a chance to be put on a line of their own until this point.
   // Here we add this newline before end-of-file comments.
-  if (Style.Language == FormatStyle::LK_TextProto &&
-  !CommentsBeforeNextToken.empty())
+  if (Style.isTextProtoBuf() && !CommentsBeforeNextToken.empty())
 addUnwrappedLine();
   flushComments(true);
   addUnwrappedLine();
@@ -411,8 +409,7 @@
   LLVM_FALLTHROUGH;
 }
 case tok::kw_case:
-  if (Style.Language == FormatStyle::LK_JavaScript &&
-  Line->MustBeDeclaration) {
+  if (Style.isJavaScript() && Line->MustBeDeclaration) {
 // A 'case: string' style field declaration.
 parseStructuralElement();
 break;
@@ -461,7 +458,7 @@
 
 switch (Tok->Tok.getKind()) {
 case tok::l_brace:
-  if (Style.Language == FormatStyle::LK_JavaScript && PrevTok) {
+  if (Style.isJavaScript() && PrevTok) {
 if (PrevTok->isOneOf(tok::colon, tok::less))
   // A ':' indicates this code is in a type, or a braced list
   // following a label in an object literal ({a: {b: 1}}).
@@ -486,7 +483,7 @@
 break;
   if (LBraceStack.back()->BlockKind == BK_Unknown) {
 bool ProbablyBracedList = false;
-if (Style.Language == FormatStyle::LK_Proto) {
+if (Style.isProtoBuf()) {
   ProbablyBracedList = NextTok->isOneOf(tok::comma, tok::r_square);
 } else {
   // Using OriginalColumn to distinguish between ObjC methods and
@@ -503,7 +500,7 @@
   // FIXME: Some of these do not apply to JS, e.g. "} {" can never be a
   // braced list in JS.
   ProbablyBracedList =
-  (Style.Language == FormatStyle::LK_JavaScript &&
+  (Style.isJavaScript() &&
NextTok->isOneOf(Keywords.kw_of, Keywords.kw_in,
 Keywords.kw_as)) ||
   (Style.isCpp() && NextTok->is(tok::l_paren)) ||
@@ -693,7 +690,7 @@
   FormatTok->BlockKind = BK_Block;
   nextToken();
   {
-bool SkipIndent = (Style.Language == FormatStyle::LK_JavaScript &&
+bool SkipIndent = (Style.isJavaScript() &&
(isGoogScope(*Line) || isIIFE(*Line, Keywords)));
 ScopedLineState LineState(*this);
 ScopedDeclarationState DeclarationState(*Line, DeclarationScopeStack,
@@ -1021,8 +1018,7 @@
 
 void UnwrappedLineParser::parseStructuralElement() {
   assert(!FormatTok->is(tok::l_brace));
-  if (Style.Language == FormatStyle::LK_TableGen &&
-  FormatTok->is(tok::pp_include)) {
+  if (Style.isTableGen() && FormatTok->is(tok::pp_include)) {
 nextToken();
 if (FormatTok->is(tok::string_literal))
   nextToken();
@@ -1053,39 +1049,38 @@
   case tok::kw_public:
   case tok::kw_protected:
   case tok::kw_private:
-if (Style.Language == FormatStyle::LK_Java ||
-Style.Language == FormatStyle::LK_JavaScript || Style.isCSharp())
+if (Style.isJava() || Style.isJavaScript() || Style.isCSharp())
   nextToken();
 else
   parseAccessSpecifier();
 return;
   case tok::kw_if:
-if (Style.Language == FormatStyle::LK_JavaScript && Line->MustBeDeclaration)
+if (Style.isJavaScript() && Line->MustBeDeclaration)
   // field/method declaration.
   break;
 parseIfThenElse();
 return;
   case tok::kw_for:
   case tok::kw_while:
-if (Style.Language == FormatStyle::LK_JavaScript && Line->MustBeDeclaration)
+if (Style.isJavaScript() && Line->MustBeDeclaration)
   // field/method declaration.
   break;

[clang] ede6005 - [AVR] Explicitly set the address of the data section when invoking the linker

2020-05-17 Thread Dylan McKay via cfe-commits


Author: Dylan McKay
Date: 2020-05-18T02:24:51+12:00
New Revision: ede6005e7092ddae454e4d365d8adefeaec1f5e3

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

LOG: [AVR] Explicitly set the address of the data section when invoking the 
linker

This is required to get avr-gdb correctly showing values at the right
addresses. This problem was discovered by using debug symbols in an
external program to lookup values in an AVR simulator.

Added: 


Modified: 
clang/lib/Driver/ToolChains/AVR.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/AVR.cpp 
b/clang/lib/Driver/ToolChains/AVR.cpp
index 6405db1a11a9..04655d5b1885 100644
--- a/clang/lib/Driver/ToolChains/AVR.cpp
+++ b/clang/lib/Driver/ToolChains/AVR.cpp
@@ -120,6 +120,13 @@ void AVR::Linker::ConstructJob(Compilation , const 
JobAction ,
   Args.AddAllArgs(CmdArgs, options::OPT_L);
   getToolChain().AddFilePathLibArgs(Args, CmdArgs);
 
+  //   "Not [sic] that addr must be offset by adding 0x80 the to
+  //real SRAM address so that the linker knows that the address
+  //is in the SRAM memory space."
+  //
+  //  - https://www.nongnu.org/avr-libc/user-manual/mem_sections.html
+  CmdArgs.push_back("-Tdata=0x800100");
+
   // If the family name is known, we can link with the device-specific libgcc.
   // Without it, libgcc will simply not be linked. This matches avr-gcc
   // behavior.



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

[PATCH] D80079: [clang-format] [NFC] isCpp() is inconsistently used to mean both C++ and Objective C, add language specific isXXX() functions

2020-05-17 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay updated this revision to Diff 264492.
MyDeveloperDay added a comment.

Remove erroneous changes


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

https://reviews.llvm.org/D80079

Files:
  clang/include/clang/Format/Format.h
  clang/lib/Format/BreakableToken.cpp
  clang/lib/Format/ContinuationIndenter.cpp
  clang/lib/Format/Format.cpp
  clang/lib/Format/FormatToken.h
  clang/lib/Format/FormatTokenLexer.cpp
  clang/lib/Format/TokenAnnotator.cpp
  clang/lib/Format/UnwrappedLineFormatter.cpp
  clang/lib/Format/UnwrappedLineParser.cpp

Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -299,11 +299,10 @@
 void UnwrappedLineParser::parseFile() {
   // The top-level context in a file always has declarations, except for pre-
   // processor directives and JavaScript files.
-  bool MustBeDeclaration =
-  !Line->InPPDirective && Style.Language != FormatStyle::LK_JavaScript;
+  bool MustBeDeclaration = !Line->InPPDirective && !Style.isJavaScript();
   ScopedDeclarationState DeclarationState(*Line, DeclarationScopeStack,
   MustBeDeclaration);
-  if (Style.Language == FormatStyle::LK_TextProto)
+  if (Style.isTextProtoBuf())
 parseBracedList();
   else
 parseLevel(/*HasOpeningBrace=*/false);
@@ -317,8 +316,7 @@
   //   // endfile comment
   // do not have a chance to be put on a line of their own until this point.
   // Here we add this newline before end-of-file comments.
-  if (Style.Language == FormatStyle::LK_TextProto &&
-  !CommentsBeforeNextToken.empty())
+  if (Style.isTextProtoBuf() && !CommentsBeforeNextToken.empty())
 addUnwrappedLine();
   flushComments(true);
   addUnwrappedLine();
@@ -411,8 +409,7 @@
   LLVM_FALLTHROUGH;
 }
 case tok::kw_case:
-  if (Style.Language == FormatStyle::LK_JavaScript &&
-  Line->MustBeDeclaration) {
+  if (Style.isJavaScript() && Line->MustBeDeclaration) {
 // A 'case: string' style field declaration.
 parseStructuralElement();
 break;
@@ -461,7 +458,7 @@
 
 switch (Tok->Tok.getKind()) {
 case tok::l_brace:
-  if (Style.Language == FormatStyle::LK_JavaScript && PrevTok) {
+  if (Style.isJavaScript() && PrevTok) {
 if (PrevTok->isOneOf(tok::colon, tok::less))
   // A ':' indicates this code is in a type, or a braced list
   // following a label in an object literal ({a: {b: 1}}).
@@ -486,7 +483,7 @@
 break;
   if (LBraceStack.back()->BlockKind == BK_Unknown) {
 bool ProbablyBracedList = false;
-if (Style.Language == FormatStyle::LK_Proto) {
+if (Style.isProtoBuf()) {
   ProbablyBracedList = NextTok->isOneOf(tok::comma, tok::r_square);
 } else {
   // Using OriginalColumn to distinguish between ObjC methods and
@@ -503,7 +500,7 @@
   // FIXME: Some of these do not apply to JS, e.g. "} {" can never be a
   // braced list in JS.
   ProbablyBracedList =
-  (Style.Language == FormatStyle::LK_JavaScript &&
+  (Style.isJavaScript() &&
NextTok->isOneOf(Keywords.kw_of, Keywords.kw_in,
 Keywords.kw_as)) ||
   (Style.isCpp() && NextTok->is(tok::l_paren)) ||
@@ -693,7 +690,7 @@
   FormatTok->BlockKind = BK_Block;
   nextToken();
   {
-bool SkipIndent = (Style.Language == FormatStyle::LK_JavaScript &&
+bool SkipIndent = (Style.isJavaScript() &&
(isGoogScope(*Line) || isIIFE(*Line, Keywords)));
 ScopedLineState LineState(*this);
 ScopedDeclarationState DeclarationState(*Line, DeclarationScopeStack,
@@ -1021,8 +1018,7 @@
 
 void UnwrappedLineParser::parseStructuralElement() {
   assert(!FormatTok->is(tok::l_brace));
-  if (Style.Language == FormatStyle::LK_TableGen &&
-  FormatTok->is(tok::pp_include)) {
+  if (Style.isTableGen() && FormatTok->is(tok::pp_include)) {
 nextToken();
 if (FormatTok->is(tok::string_literal))
   nextToken();
@@ -1053,39 +1049,38 @@
   case tok::kw_public:
   case tok::kw_protected:
   case tok::kw_private:
-if (Style.Language == FormatStyle::LK_Java ||
-Style.Language == FormatStyle::LK_JavaScript || Style.isCSharp())
+if (Style.isJava() || Style.isJavaScript() || Style.isCSharp())
   nextToken();
 else
   parseAccessSpecifier();
 return;
   case tok::kw_if:
-if (Style.Language == FormatStyle::LK_JavaScript && Line->MustBeDeclaration)
+if (Style.isJavaScript() && Line->MustBeDeclaration)
   // field/method declaration.
   break;
 parseIfThenElse();
 return;
   case tok::kw_for:
   case tok::kw_while:
-if (Style.Language == FormatStyle::LK_JavaScript && Line->MustBeDeclaration)
+if (Style.isJavaScript() && Line->MustBeDeclaration)
   //

[PATCH] D75791: [clang-format] Added new option IndentExternBlock

2020-05-17 Thread Marcus Johnson via Phabricator via cfe-commits

MarcusJohnson91 added a comment.

In D75791#2040532 , @MyDeveloperDay 
wrote:

> LGTM


So what's the next step? I've never committed to LLVM before.


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

https://reviews.llvm.org/D75791



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

[PATCH] D80079: [clang-format] [NFC] isCpp() is inconsistently used to mean both C++ and Objective C, add language specific isXXX() functions

2020-05-17 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay created this revision.
MyDeveloperDay added reviewers: krasimir, JakeMerdichAMD, mitchell-stellar, 
klimek, owenpan, sammccall, curdeius.
MyDeveloperDay added projects: clang, clang-format.
MyDeveloperDay updated this revision to Diff 264485.
MyDeveloperDay added a comment.

Missed some cases


This revision puts the `Style.Lanauge==LK_` behind convenience functions to 
begin to avoid potential issues regarding the use of `Style.isCpp()`

It's unclear in a number of places what people really mean when using isCpp() 
as such I have introduced a `isCppOnly()` to help identify those places where 
people where not checking both languages

Ideally I'd make `isCpp()` mean only C/C++ and use `isCpp() || isObjectiveC()` 
but so many of those places overlap I can see why we'd have one function, but 
perhaps a better name for `isCpp()` is `isCStyleLanguages()` then let 
`isCppOnly()` be renamed to `isCpp()` but I'm not comfortable doing that in one 
go.

Regardless I feel introducing 
`isObjectiveC(),isJava(),JavaScript(),isProtoBuf(),isTextProtoBuf and 
isTableGen()` helps the code read a little better


https://reviews.llvm.org/D80079

Files:
  clang/include/clang/Format/Format.h
  clang/lib/Format/BreakableToken.cpp
  clang/lib/Format/ContinuationIndenter.cpp
  clang/lib/Format/Format.cpp
  clang/lib/Format/FormatToken.h
  clang/lib/Format/FormatTokenLexer.cpp
  clang/lib/Format/TokenAnnotator.cpp
  clang/lib/Format/UnwrappedLineFormatter.cpp
  clang/lib/Format/UnwrappedLineParser.cpp

Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -299,11 +299,10 @@
 void UnwrappedLineParser::parseFile() {
   // The top-level context in a file always has declarations, except for pre-
   // processor directives and JavaScript files.
-  bool MustBeDeclaration =
-  !Line->InPPDirective && Style.Language != FormatStyle::LK_JavaScript;
+  bool MustBeDeclaration = !Line->InPPDirective && !Style.isJavaScript();
   ScopedDeclarationState DeclarationState(*Line, DeclarationScopeStack,
   MustBeDeclaration);
-  if (Style.Language == FormatStyle::LK_TextProto)
+  if (Style.isTextProtoBuf())
 parseBracedList();
   else
 parseLevel(/*HasOpeningBrace=*/false);
@@ -317,8 +316,7 @@
   //   // endfile comment
   // do not have a chance to be put on a line of their own until this point.
   // Here we add this newline before end-of-file comments.
-  if (Style.Language == FormatStyle::LK_TextProto &&
-  !CommentsBeforeNextToken.empty())
+  if (Style.isTextProtoBuf() && !CommentsBeforeNextToken.empty())
 addUnwrappedLine();
   flushComments(true);
   addUnwrappedLine();
@@ -411,8 +409,7 @@
   LLVM_FALLTHROUGH;
 }
 case tok::kw_case:
-  if (Style.Language == FormatStyle::LK_JavaScript &&
-  Line->MustBeDeclaration) {
+  if (Style.isJavaScript() && Line->MustBeDeclaration) {
 // A 'case: string' style field declaration.
 parseStructuralElement();
 break;
@@ -461,7 +458,7 @@
 
 switch (Tok->Tok.getKind()) {
 case tok::l_brace:
-  if (Style.Language == FormatStyle::LK_JavaScript && PrevTok) {
+  if (Style.isJavaScript() && PrevTok) {
 if (PrevTok->isOneOf(tok::colon, tok::less))
   // A ':' indicates this code is in a type, or a braced list
   // following a label in an object literal ({a: {b: 1}}).
@@ -486,7 +483,7 @@
 break;
   if (LBraceStack.back()->BlockKind == BK_Unknown) {
 bool ProbablyBracedList = false;
-if (Style.Language == FormatStyle::LK_Proto) {
+if (Style.isProtoBuf()) {
   ProbablyBracedList = NextTok->isOneOf(tok::comma, tok::r_square);
 } else {
   // Using OriginalColumn to distinguish between ObjC methods and
@@ -503,7 +500,7 @@
   // FIXME: Some of these do not apply to JS, e.g. "} {" can never be a
   // braced list in JS.
   ProbablyBracedList =
-  (Style.Language == FormatStyle::LK_JavaScript &&
+  (Style.isJavaScript() &&
NextTok->isOneOf(Keywords.kw_of, Keywords.kw_in,
 Keywords.kw_as)) ||
   (Style.isCpp() && NextTok->is(tok::l_paren)) ||
@@ -693,7 +690,7 @@
   FormatTok->BlockKind = BK_Block;
   nextToken();
   {
-bool SkipIndent = (Style.Language == FormatStyle::LK_JavaScript &&
+bool SkipIndent = (Style.isJavaScript() &&
(isGoogScope(*Line) || isIIFE(*Line, Keywords)));
 ScopedLineState LineState(*this);
 ScopedDeclarationState DeclarationState(*Line, DeclarationScopeStack,
@@ -1021,8 +1018,7 @@
 
 void UnwrappedLineParser::parseStructuralElement() {
   assert(!FormatTok->is(tok::l_brace));
-  if (Style.Language == FormatStyle::LK_TableGen &&
-  FormatTok->is(tok::pp_include)) {
+  if

[PATCH] D80079: [clang-format] [NFC] isCpp() is inconsistently used to mean both C++ and Objective C, add language specific isXXX() functions

2020-05-17 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay updated this revision to Diff 264485.
MyDeveloperDay added a comment.

Missed some cases


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

https://reviews.llvm.org/D80079

Files:
  clang/include/clang/Format/Format.h
  clang/lib/Format/BreakableToken.cpp
  clang/lib/Format/ContinuationIndenter.cpp
  clang/lib/Format/Format.cpp
  clang/lib/Format/FormatToken.h
  clang/lib/Format/FormatTokenLexer.cpp
  clang/lib/Format/TokenAnnotator.cpp
  clang/lib/Format/UnwrappedLineFormatter.cpp
  clang/lib/Format/UnwrappedLineParser.cpp

Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -299,11 +299,10 @@
 void UnwrappedLineParser::parseFile() {
   // The top-level context in a file always has declarations, except for pre-
   // processor directives and JavaScript files.
-  bool MustBeDeclaration =
-  !Line->InPPDirective && Style.Language != FormatStyle::LK_JavaScript;
+  bool MustBeDeclaration = !Line->InPPDirective && !Style.isJavaScript();
   ScopedDeclarationState DeclarationState(*Line, DeclarationScopeStack,
   MustBeDeclaration);
-  if (Style.Language == FormatStyle::LK_TextProto)
+  if (Style.isTextProtoBuf())
 parseBracedList();
   else
 parseLevel(/*HasOpeningBrace=*/false);
@@ -317,8 +316,7 @@
   //   // endfile comment
   // do not have a chance to be put on a line of their own until this point.
   // Here we add this newline before end-of-file comments.
-  if (Style.Language == FormatStyle::LK_TextProto &&
-  !CommentsBeforeNextToken.empty())
+  if (Style.isTextProtoBuf() && !CommentsBeforeNextToken.empty())
 addUnwrappedLine();
   flushComments(true);
   addUnwrappedLine();
@@ -411,8 +409,7 @@
   LLVM_FALLTHROUGH;
 }
 case tok::kw_case:
-  if (Style.Language == FormatStyle::LK_JavaScript &&
-  Line->MustBeDeclaration) {
+  if (Style.isJavaScript() && Line->MustBeDeclaration) {
 // A 'case: string' style field declaration.
 parseStructuralElement();
 break;
@@ -461,7 +458,7 @@
 
 switch (Tok->Tok.getKind()) {
 case tok::l_brace:
-  if (Style.Language == FormatStyle::LK_JavaScript && PrevTok) {
+  if (Style.isJavaScript() && PrevTok) {
 if (PrevTok->isOneOf(tok::colon, tok::less))
   // A ':' indicates this code is in a type, or a braced list
   // following a label in an object literal ({a: {b: 1}}).
@@ -486,7 +483,7 @@
 break;
   if (LBraceStack.back()->BlockKind == BK_Unknown) {
 bool ProbablyBracedList = false;
-if (Style.Language == FormatStyle::LK_Proto) {
+if (Style.isProtoBuf()) {
   ProbablyBracedList = NextTok->isOneOf(tok::comma, tok::r_square);
 } else {
   // Using OriginalColumn to distinguish between ObjC methods and
@@ -503,7 +500,7 @@
   // FIXME: Some of these do not apply to JS, e.g. "} {" can never be a
   // braced list in JS.
   ProbablyBracedList =
-  (Style.Language == FormatStyle::LK_JavaScript &&
+  (Style.isJavaScript() &&
NextTok->isOneOf(Keywords.kw_of, Keywords.kw_in,
 Keywords.kw_as)) ||
   (Style.isCpp() && NextTok->is(tok::l_paren)) ||
@@ -693,7 +690,7 @@
   FormatTok->BlockKind = BK_Block;
   nextToken();
   {
-bool SkipIndent = (Style.Language == FormatStyle::LK_JavaScript &&
+bool SkipIndent = (Style.isJavaScript() &&
(isGoogScope(*Line) || isIIFE(*Line, Keywords)));
 ScopedLineState LineState(*this);
 ScopedDeclarationState DeclarationState(*Line, DeclarationScopeStack,
@@ -1021,8 +1018,7 @@
 
 void UnwrappedLineParser::parseStructuralElement() {
   assert(!FormatTok->is(tok::l_brace));
-  if (Style.Language == FormatStyle::LK_TableGen &&
-  FormatTok->is(tok::pp_include)) {
+  if (Style.isTableGen() && FormatTok->is(tok::pp_include)) {
 nextToken();
 if (FormatTok->is(tok::string_literal))
   nextToken();
@@ -1053,39 +1049,38 @@
   case tok::kw_public:
   case tok::kw_protected:
   case tok::kw_private:
-if (Style.Language == FormatStyle::LK_Java ||
-Style.Language == FormatStyle::LK_JavaScript || Style.isCSharp())
+if (Style.isJava() || Style.isJavaScript() || Style.isCSharp())
   nextToken();
 else
   parseAccessSpecifier();
 return;
   case tok::kw_if:
-if (Style.Language == FormatStyle::LK_JavaScript && Line->MustBeDeclaration)
+if (Style.isJavaScript() && Line->MustBeDeclaration)
   // field/method declaration.
   break;
 parseIfThenElse();
 return;
   case tok::kw_for:
   case tok::kw_while:
-if (Style.Language == FormatStyle::LK_JavaScript && Line->MustBeDeclaration)
+if (Style.isJavaScript() && Line->MustBeDeclaration)
   // field/method

[PATCH] D75791: [clang-format] Added new option IndentExternBlock

2020-05-17 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay added a comment.

LGTM


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

https://reviews.llvm.org/D75791



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

[PATCH] D72531: Set traversal explicitly where needed in tests

2020-05-17 Thread Stephen Kelly via Phabricator via cfe-commits

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



Comment at: clang/unittests/Tooling/StencilTest.cpp:63
   ASTContext  = AstUnit->getASTContext();
-  auto Matches = ast_matchers::match(wrapMatcher(Matcher), Context);
+  auto Matches = ast_matchers::match(
+  traverse(ast_type_traits::TK_AsIs, wrapMatcher(Matcher)), Context);

aaron.ballman wrote:
> Was this change made because you didn't want to accept the traversal mode as 
> a parameter to `matchStmt` and force each caller to decide which mode they 
> use? Or is there some other reason why this change was needed?
Yes, the test currently expects `AsIs`. If someone wanted to change that in the 
future, that is an issue for future work.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72531



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

[PATCH] D47521: [clang-format] Fix parsing lambdas with noexcept

2020-05-17 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay added a comment.

This was addressed with D56909: [clang-format] Fix line parsing for noexcept 
lambdas  can we please abandon


Repository:
  rC Clang

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

https://reviews.llvm.org/D47521



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

[PATCH] D72530: Set traversal explicitly where needed in clang-tidy

2020-05-17 Thread Stephen Kelly via Phabricator via cfe-commits

steveire added a comment.

In D72530#2038561 , @aaron.ballman 
wrote:

> The changes here look reasonable, but can some of this code be simplified to 
> use the default behavior and less complex matchers that don't have to 
> carefully ignore implicit nodes? This would demonstrate that the feature 
> really is an improvement over the status quo and would also exercise more 
> test code with the new defaults demonstrating equivalence. I'm not 
> envisioning anything onerous, more just wondering if you think there is some 
> low-hanging fruit that could be picked rather than converting everything to 
> AsIs.


After changing the default there will be opportunities for that as a follow-up, 
yes. But this patch is ordered before changing the default. The change you 
describe is a follow-up.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72530



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

[PATCH] D80031: [clang-format] [NFC] release note placed in the wrong location and other rst linting errors

2020-05-17 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay closed this revision.
MyDeveloperDay added a comment.

I missed the Differential Revision off the commit message

https://reviews.llvm.org/rG49c9a68d7fc62aabdf4d625fcb2954555496772b


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80031



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

[PATCH] D79465: [clang-format] Fix line lengths w/ comments in align

2020-05-17 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay accepted this revision.
MyDeveloperDay 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/D79465/new/

https://reviews.llvm.org/D79465



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

[clang] 3841ed4 - [Driver] Render -T for Gnu.cpp

2020-05-17 Thread Fangrui Song via cfe-commits


Author: Fangrui Song
Date: 2020-05-16T23:54:31-07:00
New Revision: 3841ed4104ac32eae7305d07e4558ea607fa69f3

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

LOG: [Driver] Render -T for Gnu.cpp

clang -T a.lds a.c currently does not render -T.

Added: 


Modified: 
clang/lib/Driver/ToolChains/Gnu.cpp
clang/test/Driver/Xlinker-args.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Gnu.cpp 
b/clang/lib/Driver/ToolChains/Gnu.cpp
index 315988faf40a..9a340142a242 100644
--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -630,6 +630,8 @@ void tools::gnutools::Linker::ConstructJob(Compilation , 
const JobAction ,
   AddHIPLinkerScript(getToolChain(), C, Output, Inputs, Args, CmdArgs, JA,
  *this);
 
+  Args.AddAllArgs(CmdArgs, options::OPT_T);
+
   const char *Exec = Args.MakeArgString(ToolChain.GetLinkerPath());
   C.addCommand(std::make_unique(JA, *this, Exec, CmdArgs, Inputs));
 }

diff  --git a/clang/test/Driver/Xlinker-args.c 
b/clang/test/Driver/Xlinker-args.c
index a828f15b2b9a..72c2fd2698e8 100644
--- a/clang/test/Driver/Xlinker-args.c
+++ b/clang/test/Driver/Xlinker-args.c
@@ -5,15 +5,16 @@
 // RUN:   -Xlinker one -Xlinker --no-demangle \
 // RUN:   -Wl,two,--no-demangle,three -Xlinker four -z five -r %s 2> %t
 // RUN: FileCheck -check-prefix=DARWIN < %t %s
-//
+
+/// -T is reordered to the last to make sure -L takes precedence.
 // RUN: %clang -target x86_64-pc-linux-gnu -### \
-// RUN:   -Xlinker one -Xlinker --no-demangle \
+// RUN:   -T a.lds -Xlinker one -Xlinker --no-demangle \
 // RUN:   -Wl,two,--no-demangle,three -Xlinker four -z five -r %s 2> %t
 // RUN: FileCheck -check-prefix=LINUX < %t %s
 //
 // DARWIN-NOT: --no-demangle
 // DARWIN: "one" "two" "three" "four" "-z" "five" "-r"
-// LINUX: "--no-demangle" "one" "two" "three" "four" "-z" "five" "-r"
+// LINUX: "--no-demangle" "one" "two" "three" "four" "-z" "five" "-r" {{.*}} 
"-T" "a.lds"
 
 // Check that we forward '-Xlinker' and '-Wl,' on Windows.
 // RUN: %clang -target i686-pc-win32 -### \



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

40 matches

Mail list logo