[PATCH] D57220: Test fix for isViableInline remark message

[Yevgeny Rouban via Phabricator via cfe-commits]

yrouban created this revision.
yrouban added reviewers: xbolva00, anemet.
Herald added a subscriber: cfe-commits.
yrouban added a parent revision: D57089: Provide reason messages for unviable 
inlining.

This patch adjusts the test remark message that is changed by D57089 
.


Repository:
  rC Clang

https://reviews.llvm.org/D57220

Files:
  test/Frontend/optimization-remark-with-hotness.c


Index: test/Frontend/optimization-remark-with-hotness.c
===
--- test/Frontend/optimization-remark-with-hotness.c
+++ test/Frontend/optimization-remark-with-hotness.c
@@ -66,7 +66,7 @@
 
 int main(int argc, const char *argv[]) {
   for (int i = 0; i < 30; i++)
-// expected-remark@+1 {{bar not inlined into main because it should never 
be inlined (cost=never): always inliner (hotness:}}
+// expected-remark@+1 {{bar not inlined into main because it should never 
be inlined (cost=never): no alwaysinline attribute (hotness:}}
 bar(argc);
   return sum;
 }


Index: test/Frontend/optimization-remark-with-hotness.c
===
--- test/Frontend/optimization-remark-with-hotness.c
+++ test/Frontend/optimization-remark-with-hotness.c
@@ -66,7 +66,7 @@
 
 int main(int argc, const char *argv[]) {
   for (int i = 0; i < 30; i++)
-// expected-remark@+1 {{bar not inlined into main because it should never be inlined (cost=never): always inliner (hotness:}}
+// expected-remark@+1 {{bar not inlined into main because it should never be inlined (cost=never): no alwaysinline attribute (hotness:}}
 bar(argc);
   return sum;
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D57100: [clang-tidy] refactor bugprone-exception-escape analysis into class

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

To me, modulo the `"IgnoredExceptions"` change, this seems like a 
straight-forward refactoring.




Comment at: clang-tidy/utils/ExceptionAnalyzer.h:25
+/// give the possibility of an exception.
+class ExceptionAnalyzer {
+public:

What is the test plan for this utility class, BTW?
Ensuring that the main user (`bugprone-exception-escape`) has sufficiently full 
test coverage?


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D57100



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

[PATCH] D57209: Revert "[AArch64] Use LL for 64-bit intrinsic arguments"

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo added a comment.

In D57209#1370608 , @rnk wrote:

> and I don't think anyone has set up a continuous Windows ARM64 build with ToT 
> clang anywhere in the world yet.


Not sure if it qualifies as a proper continuous Windows ARM64 build, but I 
build latest llvm+mingw-w64+compiler-rt+libcxx nightly and test build a bunch 
of video-related projects including VLC on it (for all 4 current architectures, 
i686/x86_64/armv7/aarch64), and run a bunch of tests of projects built with 
that compiler in wine. But I'm pretty sure none of the projects I test use 
these intrinsics.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57209



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

r352173 - [X86] Remove mask and passthru arguments from vpconflict builtins. Use select in IR instead.

[Craig Topper via cfe-commits]

Author: ctopper
Date: Thu Jan 24 23:08:22 2019
New Revision: 352173

URL: http://llvm.org/viewvc/llvm-project?rev=352173=rev
Log:
[X86] Remove mask and passthru arguments from vpconflict builtins. Use select 
in IR instead.

Modified:
cfe/trunk/include/clang/Basic/BuiltinsX86.def
cfe/trunk/lib/Headers/avx512cdintrin.h
cfe/trunk/lib/Headers/avx512vlcdintrin.h
cfe/trunk/test/CodeGen/avx512cdintrin.c
cfe/trunk/test/CodeGen/avx512vlcd-builtins.c

Modified: cfe/trunk/include/clang/Basic/BuiltinsX86.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsX86.def?rev=352173=352172=352173=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsX86.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsX86.def Thu Jan 24 23:08:22 2019
@@ -1067,12 +1067,12 @@ TARGET_BUILTIN(__builtin_ia32_psubsw512,
 TARGET_BUILTIN(__builtin_ia32_psubusb512, "V64cV64cV64c", "ncV:512:", 
"avx512bw")
 TARGET_BUILTIN(__builtin_ia32_psubusw512, "V32sV32sV32s", "ncV:512:", 
"avx512bw")
 
-TARGET_BUILTIN(__builtin_ia32_vpconflictdi_128_mask, "V2LLiV2LLiV2LLiUc", 
"ncV:128:", "avx512cd,avx512vl")
-TARGET_BUILTIN(__builtin_ia32_vpconflictdi_256_mask, "V4LLiV4LLiV4LLiUc", 
"ncV:256:", "avx512cd,avx512vl")
-TARGET_BUILTIN(__builtin_ia32_vpconflictsi_128_mask, "V4iV4iV4iUc", 
"ncV:128:", "avx512cd,avx512vl")
-TARGET_BUILTIN(__builtin_ia32_vpconflictsi_256_mask, "V8iV8iV8iUc", 
"ncV:256:", "avx512cd,avx512vl")
-TARGET_BUILTIN(__builtin_ia32_vpconflictdi_512_mask, "V8LLiV8LLiV8LLiUc", 
"ncV:512:", "avx512cd")
-TARGET_BUILTIN(__builtin_ia32_vpconflictsi_512_mask, "V16iV16iV16iUs", 
"ncV:512:", "avx512cd")
+TARGET_BUILTIN(__builtin_ia32_vpconflictdi_128, "V2LLiV2LLi", "ncV:128:", 
"avx512cd,avx512vl")
+TARGET_BUILTIN(__builtin_ia32_vpconflictdi_256, "V4LLiV4LLi", "ncV:256:", 
"avx512cd,avx512vl")
+TARGET_BUILTIN(__builtin_ia32_vpconflictsi_128, "V4iV4i", "ncV:128:", 
"avx512cd,avx512vl")
+TARGET_BUILTIN(__builtin_ia32_vpconflictsi_256, "V8iV8i", "ncV:256:", 
"avx512cd,avx512vl")
+TARGET_BUILTIN(__builtin_ia32_vpconflictdi_512, "V8LLiV8LLi", "ncV:512:", 
"avx512cd")
+TARGET_BUILTIN(__builtin_ia32_vpconflictsi_512, "V16iV16i", "ncV:512:", 
"avx512cd")
 TARGET_BUILTIN(__builtin_ia32_vplzcntd_512, "V16iV16i", "ncV:512:", "avx512cd")
 TARGET_BUILTIN(__builtin_ia32_vplzcntq_512, "V8LLiV8LLi", "ncV:512:", 
"avx512cd")
 

Modified: cfe/trunk/lib/Headers/avx512cdintrin.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/avx512cdintrin.h?rev=352173=352172=352173=diff
==
--- cfe/trunk/lib/Headers/avx512cdintrin.h (original)
+++ cfe/trunk/lib/Headers/avx512cdintrin.h Thu Jan 24 23:08:22 2019
@@ -34,49 +34,45 @@
 static __inline__ __m512i __DEFAULT_FN_ATTRS
 _mm512_conflict_epi64 (__m512i __A)
 {
-  return (__m512i) __builtin_ia32_vpconflictdi_512_mask ((__v8di) __A,
- (__v8di) _mm512_setzero_si512 (),
- (__mmask8) -1);
+  return (__m512i) __builtin_ia32_vpconflictdi_512 ((__v8di) __A);
 }
 
 static __inline__ __m512i __DEFAULT_FN_ATTRS
 _mm512_mask_conflict_epi64 (__m512i __W, __mmask8 __U, __m512i __A)
 {
-  return (__m512i) __builtin_ia32_vpconflictdi_512_mask ((__v8di) __A,
-   (__v8di) __W,
-   (__mmask8) __U);
+  return (__m512i)__builtin_ia32_selectq_512((__mmask8)__U,
+ 
(__v8di)_mm512_conflict_epi64(__A),
+ (__v8di)__W);
 }
 
 static __inline__ __m512i __DEFAULT_FN_ATTRS
 _mm512_maskz_conflict_epi64 (__mmask8 __U, __m512i __A)
 {
-  return (__m512i) __builtin_ia32_vpconflictdi_512_mask ((__v8di) __A,
- (__v8di) _mm512_setzero_si512 (),
- (__mmask8) __U);
+  return (__m512i)__builtin_ia32_selectq_512((__mmask8)__U,
+ 
(__v8di)_mm512_conflict_epi64(__A),
+ (__v8di)_mm512_setzero_si512 ());
 }
 
 static __inline__ __m512i __DEFAULT_FN_ATTRS
 _mm512_conflict_epi32 (__m512i __A)
 {
-  return (__m512i) __builtin_ia32_vpconflictsi_512_mask ((__v16si) __A,
- (__v16si) _mm512_setzero_si512 (),
- (__mmask16) -1);
+  return (__m512i) __builtin_ia32_vpconflictsi_512 ((__v16si) __A);
 }
 
 static __inline__ __m512i __DEFAULT_FN_ATTRS
 _mm512_mask_conflict_epi32 (__m512i __W, __mmask16 __U, __m512i __A)
 {
-  return (__m512i) __builtin_ia32_vpconflictsi_512_mask ((__v16si) __A,
-   (__v16si) __W,
-   (__mmask16) __U);
+  return (__m512i)__builtin_ia32_selectd_512((__mmask16)__U,
+
(__v16si)_mm512_conflict_epi32(__A),
+(__v16si)__W);
 }
 
 static __inline__ __m512i __DEFAULT_FN_ATTRS
 _mm512_maskz_conflict_epi32 (__mmask16 __U, __m512i __A)
 {
-  return 

[PATCH] D57219: [Fixed Point Arithmetic] Fixed Point Comparisons

[Leonard Chan via Phabricator via cfe-commits]

leonardchan created this revision.
leonardchan added reviewers: rjmccall, bjope, ebevhan.
leonardchan added a project: clang.
leonardchan added a parent revision: D46917: [Fixed Point Arithmetic] 
Comparison and Unary Operations for Fixed Point Types.

This patch implements fixed point comparisons with other fixed point types and 
integers. This also provides constant expression evaluation for them.


Repository:
  rC Clang

https://reviews.llvm.org/D57219

Files:
  clang/lib/AST/ExprConstant.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/test/Frontend/fixed_point_comparisons.c

Index: clang/test/Frontend/fixed_point_comparisons.c
===
--- /dev/null
+++ clang/test/Frontend/fixed_point_comparisons.c
@@ -0,0 +1,344 @@
+// RUN: %clang_cc1 -ffixed-point -S -emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK,SIGNED
+// RUN: %clang_cc1 -ffixed-point -fpadding-on-unsigned-fixed-point -S -emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK,UNSIGNED
+
+// Fixed point against other fixed point
+_Bool b_eq_true = 2.5hk == 2.5uhk;  // CHECK-DAG: @b_eq_true  = {{.*}}global i8 1, align 1
+_Bool b_eq_false = 2.5hk == 2.4uhk; // CHECK-DAG: @b_eq_false = {{.*}}global i8 0, align 1
+
+_Bool b_ne_true = 2.5hk != 2.4uhk;  // CHECK-DAG: @b_ne_true  = {{.*}}global i8 1, align 1
+_Bool b_ne_false = 2.5hk != 2.5uhk; // CHECK-DAG: @b_ne_false = {{.*}}global i8 0, align 1
+
+_Bool b_lt_true = 2.5hk < 2.75uhk; // CHECK-DAG: @b_lt_true  = {{.*}}global i8 1, align 1
+_Bool b_lt_false = 2.5hk < 2.5uhk; // CHECK-DAG: @b_lt_false = {{.*}}global i8 0, align 1
+
+_Bool b_le_true = 2.5hk <= 2.75uhk; // CHECK-DAG: @b_le_true  = {{.*}}global i8 1, align 1
+_Bool b_le_true2 = 2.5hk <= 2.5uhk; // CHECK-DAG: @b_le_true2 = {{.*}}global i8 1, align 1
+_Bool b_le_false = 2.5hk <= 2.4uhk; // CHECK-DAG: @b_le_false = {{.*}}global i8 0, align 1
+
+_Bool b_gt_true = 2.75hk > 2.5uhk;   // CHECK-DAG: @b_gt_true  = {{.*}}global i8 1, align 1
+_Bool b_gt_false = 2.75hk > 2.75uhk; // CHECK-DAG: @b_gt_false = {{.*}}global i8 0, align 1
+
+_Bool b_ge_true = 2.75hk >= 2.5uhk;   // CHECK-DAG: @b_ge_true  = {{.*}}global i8 1, align 1
+_Bool b_ge_true2 = 2.75hk >= 2.75uhk; // CHECK-DAG: @b_ge_true2 = {{.*}}global i8 1, align 1
+_Bool b_ge_false = 2.5hk >= 2.75uhk;  // CHECK-DAG: @b_ge_false = {{.*}}global i8 0, align 1
+
+// Fixed point against int
+_Bool b_ieq_true = 2.0hk == 2;  // CHECK-DAG: @b_ieq_true  = {{.*}}global i8 1, align 1
+_Bool b_ieq_false = 2.0hk == 3; // CHECK-DAG: @b_ieq_false = {{.*}}global i8 0, align 1
+
+_Bool b_ine_true = 2.0hk != 3;  // CHECK-DAG: @b_ine_true  = {{.*}}global i8 1, align 1
+_Bool b_ine_false = 2.0hk != 2; // CHECK-DAG: @b_ine_false = {{.*}}global i8 0, align 1
+
+_Bool b_ilt_true = 2.0hk < 3;  // CHECK-DAG: @b_ilt_true  = {{.*}}global i8 1, align 1
+_Bool b_ilt_false = 2.0hk < 2; // CHECK-DAG: @b_ilt_false = {{.*}}global i8 0, align 1
+
+_Bool b_ile_true = 2.0hk <= 3;  // CHECK-DAG: @b_ile_true  = {{.*}}global i8 1, align 1
+_Bool b_ile_true2 = 2.0hk <= 2; // CHECK-DAG: @b_ile_true2 = {{.*}}global i8 1, align 1
+_Bool b_ile_false = 2.0hk <= 1; // CHECK-DAG: @b_ile_false = {{.*}}global i8 0, align 1
+
+_Bool b_igt_true = 2.0hk > 1;  // CHECK-DAG: @b_igt_true  = {{.*}}global i8 1, align 1
+_Bool b_igt_false = 2.0hk > 2; // CHECK-DAG: @b_igt_false = {{.*}}global i8 0, align 1
+
+_Bool b_ige_true = 2.0hk >= 1;  // CHECK-DAG: @b_ige_true  = {{.*}}global i8 1, align 1
+_Bool b_ige_true2 = 2.0hk >= 2; // CHECK-DAG: @b_ige_true2 = {{.*}}global i8 1, align 1
+_Bool b_ige_false = 2.0hk >= 3; // CHECK-DAG: @b_ige_false = {{.*}}global i8 0, align 1
+
+// Different signage
+// Since we can have different precisions, non powers of 2 fractions may have
+// different actual values when being compared.
+_Bool b_sne_true = 2.6hk != 2.6uhk;
+// SIGNED-DAG:   @b_sne_true = {{.*}}global i8 1, align 1
+// UNSIGNED-DAG: @b_sne_true = {{.*}}global i8 0, align 1
+
+_Bool b_seq_true = 2.0hk == 2u;  // CHECK-DAG: @b_seq_true  = {{.*}}global i8 1, align 1
+_Bool b_seq_true2 = 2.0uhk == 2; // CHECK-DAG: @b_seq_true2 = {{.*}}global i8 1, align 1
+
+void TestComparisons() {
+  short _Accum sa;
+  _Accum a;
+  unsigned short _Accum usa;
+  unsigned _Accum ua;
+
+  // Each of these should be a fixed point conversion followed by the actual
+  // comparison operation.
+  sa == a;
+  // CHECK:  [[A:%[0-9]+]] = load i16, i16* %sa, align 2
+  // CHECK-NEXT: [[A2:%[0-9]+]] = load i32, i32* %a, align 4
+  // CHECK-NEXT: [[RESIZE_A:%[a-z0-9]+]] = sext i16 [[A]] to i32
+  // CHECK-NEXT: [[UPSCALE_A:%[a-z0-9]+]] = shl i32 [[RESIZE_A]], 8
+  // CHECK-NEXT: {{.*}} = icmp eq i32 [[UPSCALE_A]], [[A2]]
+
+  sa != a;
+  // CHECK:  [[A:%[0-9]+]] = load i16, i16* %sa, align 2
+  // CHECK-NEXT: [[A2:%[0-9]+]] = load i32, i32* %a, align 4
+  // CHECK-NEXT: [[RESIZE_A:%[a-z0-9]+]] = sext i16 [[A]] to i32
+  // CHECK-NEXT: [[UPSCALE_A:%[a-z0-9]+]] = shl i32 [[RESIZE_A]], 8
+  // CHECK-NEXT: 

[PATCH] D56624: [Sanitizers] UBSan unreachable incompatible with ASan in the presence of `noreturn` calls

[Vedant Kumar via Phabricator via cfe-commits]

vsk added a comment.

In D56624#1370607 , @yln wrote:

> In D56624#1370579 , @eugenis wrote:
>
> > Maybe the frontend should insert __asan_handle_noreturn whenever ASan is 
> > enabled, and then ASan would not care about the attribute? I'd like to 
> > avoid having this logic in two places.
>
>
> +1 for this. @vsk Can you sign off on this design?


Sounds good to me.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D56624



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

[PATCH] D57135: [ExprConstant] Unify handling of array init with lvalues.

[Eli Friedman via Phabricator via cfe-commits]

efriedma abandoned this revision.
efriedma added a comment.

I'm now convinced this is the wrong approach.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57135



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

[PATCH] D56792: Rename getTypeQualifiers to getMethodQualifiers

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

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

There isn't really a standard name for this; in the absence of such a name, 
this seems as good as anything.


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

https://reviews.llvm.org/D56792



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

r352156 - [AArch64] Make the test for rsr and rsr64 stricter

[Petr Hosek via cfe-commits]

Author: phosek
Date: Thu Jan 24 18:42:30 2019
New Revision: 352156

URL: http://llvm.org/viewvc/llvm-project?rev=352156=rev
Log:
[AArch64] Make the test for rsr and rsr64 stricter

ACLE specifies that return type for rsr and rsr64 is uint32_t and
uint64_t respectively. D56852 change the return type of rsr64 from
unsigned long to unsigned long long which at least on Linux doesn't
match uint64_t, but the test isn't strict enough to detect that
because compiler implicitly converts unsigned long long to uint64_t,
but it breaks other uses such as printf with PRIx64 type specifier.
This change makes the test stricter enforcing that the return type
of rsr and rsr64 builtins is what is actually specified in ACLE.

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

Modified:
cfe/trunk/test/CodeGen/builtins-arm64.c

Modified: cfe/trunk/test/CodeGen/builtins-arm64.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/builtins-arm64.c?rev=352156=352155=352156=diff
==
--- cfe/trunk/test/CodeGen/builtins-arm64.c (original)
+++ cfe/trunk/test/CodeGen/builtins-arm64.c Thu Jan 24 18:42:30 2019
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -triple arm64-unknown-linux -disable-O0-optnone -emit-llvm 
-o - %s | opt -S -mem2reg | FileCheck %s
+#include 
 
 void f0(void *a, void *b) {
__clear_cache(a,b);
@@ -49,13 +50,17 @@ void prefetch() {
 // CHECK: call {{.*}} @llvm.prefetch(i8* null, i32 0, i32 3, i32 0)
 }
 
-unsigned rsr() {
+__typeof__(__builtin_arm_rsr("1:2:3:4:5")) rsr(void);
+
+uint32_t rsr() {
   // CHECK: [[V0:[%A-Za-z0-9.]+]] = call i64 @llvm.read_register.i64(metadata 
![[M0:[0-9]]])
   // CHECK-NEXT: trunc i64 [[V0]] to i32
   return __builtin_arm_rsr("1:2:3:4:5");
 }
 
-unsigned long rsr64() {
+__typeof__(__builtin_arm_rsr64("1:2:3:4:5")) rsr64(void);
+
+uint64_t rsr64() {
   // CHECK: call i64 @llvm.read_register.i64(metadata ![[M0:[0-9]]])
   return __builtin_arm_rsr64("1:2:3:4:5");
 }


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

[PATCH] D57210: [AArch64] Make the test for rsr and rsr64 stricter

[Petr Hosek via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL352156: [AArch64] Make the test for rsr and rsr64 stricter 
(authored by phosek, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D57210?vs=183448=183471#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D57210

Files:
  cfe/trunk/test/CodeGen/builtins-arm64.c


Index: cfe/trunk/test/CodeGen/builtins-arm64.c
===
--- cfe/trunk/test/CodeGen/builtins-arm64.c
+++ cfe/trunk/test/CodeGen/builtins-arm64.c
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -triple arm64-unknown-linux -disable-O0-optnone -emit-llvm 
-o - %s | opt -S -mem2reg | FileCheck %s
+#include 
 
 void f0(void *a, void *b) {
__clear_cache(a,b);
@@ -49,13 +50,17 @@
 // CHECK: call {{.*}} @llvm.prefetch(i8* null, i32 0, i32 3, i32 0)
 }
 
-unsigned rsr() {
+__typeof__(__builtin_arm_rsr("1:2:3:4:5")) rsr(void);
+
+uint32_t rsr() {
   // CHECK: [[V0:[%A-Za-z0-9.]+]] = call i64 @llvm.read_register.i64(metadata 
![[M0:[0-9]]])
   // CHECK-NEXT: trunc i64 [[V0]] to i32
   return __builtin_arm_rsr("1:2:3:4:5");
 }
 
-unsigned long rsr64() {
+__typeof__(__builtin_arm_rsr64("1:2:3:4:5")) rsr64(void);
+
+uint64_t rsr64() {
   // CHECK: call i64 @llvm.read_register.i64(metadata ![[M0:[0-9]]])
   return __builtin_arm_rsr64("1:2:3:4:5");
 }


Index: cfe/trunk/test/CodeGen/builtins-arm64.c
===
--- cfe/trunk/test/CodeGen/builtins-arm64.c
+++ cfe/trunk/test/CodeGen/builtins-arm64.c
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -triple arm64-unknown-linux -disable-O0-optnone -emit-llvm -o - %s | opt -S -mem2reg | FileCheck %s
+#include 
 
 void f0(void *a, void *b) {
 	__clear_cache(a,b);
@@ -49,13 +50,17 @@
 // CHECK: call {{.*}} @llvm.prefetch(i8* null, i32 0, i32 3, i32 0)
 }
 
-unsigned rsr() {
+__typeof__(__builtin_arm_rsr("1:2:3:4:5")) rsr(void);
+
+uint32_t rsr() {
   // CHECK: [[V0:[%A-Za-z0-9.]+]] = call i64 @llvm.read_register.i64(metadata ![[M0:[0-9]]])
   // CHECK-NEXT: trunc i64 [[V0]] to i32
   return __builtin_arm_rsr("1:2:3:4:5");
 }
 
-unsigned long rsr64() {
+__typeof__(__builtin_arm_rsr64("1:2:3:4:5")) rsr64(void);
+
+uint64_t rsr64() {
   // CHECK: call i64 @llvm.read_register.i64(metadata ![[M0:[0-9]]])
   return __builtin_arm_rsr64("1:2:3:4:5");
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D57209: Revert "[AArch64] Use LL for 64-bit intrinsic arguments"

[Petr Hosek via Phabricator via cfe-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rC352153: Revert [AArch64] Use LL for 64-bit intrinsic 
arguments (authored by phosek, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D57209?vs=183446=183467#toc

Repository:
  rC Clang

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

https://reviews.llvm.org/D57209

Files:
  include/clang/Basic/BuiltinsAArch64.def
  test/CodeGen/arm64-crc32.c
  test/CodeGen/builtins-arm64.c

Index: include/clang/Basic/BuiltinsAArch64.def
===
--- include/clang/Basic/BuiltinsAArch64.def
+++ include/clang/Basic/BuiltinsAArch64.def
@@ -32,7 +32,7 @@
 
 // Bit manipulation
 BUILTIN(__builtin_arm_rbit, "UiUi", "nc")
-BUILTIN(__builtin_arm_rbit64, "LLUiLLUi", "nc")
+BUILTIN(__builtin_arm_rbit64, "LUiLUi", "nc")
 
 // HINT
 BUILTIN(__builtin_arm_nop, "v", "")
@@ -49,8 +49,8 @@
 BUILTIN(__builtin_arm_crc32ch, "UiUiUs", "nc")
 BUILTIN(__builtin_arm_crc32w, "UiUiUi", "nc")
 BUILTIN(__builtin_arm_crc32cw, "UiUiUi", "nc")
-BUILTIN(__builtin_arm_crc32d, "UiUiLLUi", "nc")
-BUILTIN(__builtin_arm_crc32cd, "UiUiLLUi", "nc")
+BUILTIN(__builtin_arm_crc32d, "UiUiLUi", "nc")
+BUILTIN(__builtin_arm_crc32cd, "UiUiLUi", "nc")
 
 // Memory barrier
 BUILTIN(__builtin_arm_dmb, "vUi", "nc")
@@ -62,10 +62,10 @@
 
 // System Registers
 BUILTIN(__builtin_arm_rsr, "UicC*", "nc")
-BUILTIN(__builtin_arm_rsr64, "LLUicC*", "nc")
+BUILTIN(__builtin_arm_rsr64, "LUicC*", "nc")
 BUILTIN(__builtin_arm_rsrp, "v*cC*", "nc")
 BUILTIN(__builtin_arm_wsr, "vcC*Ui", "nc")
-BUILTIN(__builtin_arm_wsr64, "vcC*LLUi", "nc")
+BUILTIN(__builtin_arm_wsr64, "vcC*LUi", "nc")
 BUILTIN(__builtin_arm_wsrp, "vcC*vC*", "nc")
 
 // MSVC
Index: test/CodeGen/arm64-crc32.c
===
--- test/CodeGen/arm64-crc32.c
+++ test/CodeGen/arm64-crc32.c
@@ -1,57 +1,54 @@
 // REQUIRES: aarch64-registered-target
 // RUN: %clang_cc1 -triple arm64-none-linux-gnu \
 // RUN:  -disable-O0-optnone -S -emit-llvm -o - %s | opt -S -mem2reg | FileCheck %s
-// RUN: %clang_cc1 -triple aarch64-windows \
-// RUN:  -disable-O0-optnone -S -emit-llvm -o - %s | opt -S -mem2reg | FileCheck %s
-#include 
 
-uint32_t crc32b(uint32_t a, uint8_t b)
+int crc32b(int a, char b)
 {
 return __builtin_arm_crc32b(a,b);
 // CHECK: [[T0:%[0-9]+]] = zext i8 %b to i32
 // CHECK: call i32 @llvm.aarch64.crc32b(i32 %a, i32 [[T0]])
 }
 
-uint32_t crc32cb(uint32_t a, uint8_t b)
+int crc32cb(int a, char b)
 {
 return __builtin_arm_crc32cb(a,b);
 // CHECK: [[T0:%[0-9]+]] = zext i8 %b to i32
 // CHECK: call i32 @llvm.aarch64.crc32cb(i32 %a, i32 [[T0]])
 }
 
-uint32_t crc32h(uint32_t a, uint16_t b)
+int crc32h(int a, short b)
 {
 return __builtin_arm_crc32h(a,b);
 // CHECK: [[T0:%[0-9]+]] = zext i16 %b to i32
 // CHECK: call i32 @llvm.aarch64.crc32h(i32 %a, i32 [[T0]])
 }
 
-uint32_t crc32ch(uint32_t a, uint16_t b)
+int crc32ch(int a, short b)
 {
 return __builtin_arm_crc32ch(a,b);
 // CHECK: [[T0:%[0-9]+]] = zext i16 %b to i32
 // CHECK: call i32 @llvm.aarch64.crc32ch(i32 %a, i32 [[T0]])
 }
 
-uint32_t crc32w(uint32_t a, uint32_t b)
+int crc32w(int a, int b)
 {
 return __builtin_arm_crc32w(a,b);
 // CHECK: call i32 @llvm.aarch64.crc32w(i32 %a, i32 %b)
 }
 
-uint32_t crc32cw(uint32_t a, uint32_t b)
+int crc32cw(int a, int b)
 {
 return __builtin_arm_crc32cw(a,b);
 // CHECK: call i32 @llvm.aarch64.crc32cw(i32 %a, i32 %b)
 }
 
-uint32_t crc32d(uint32_t a, uint64_t b)
+int crc32d(int a, long b)
 {
 return __builtin_arm_crc32d(a,b);
 // CHECK: call i32 @llvm.aarch64.crc32x(i32 %a, i64 %b)
 }
 
-uint32_t crc32cd(uint32_t a, uint64_t b)
+int crc32cd(int a, long b)
 {
 return __builtin_arm_crc32cd(a,b);
 // CHECK: call i32 @llvm.aarch64.crc32cx(i32 %a, i64 %b)
Index: test/CodeGen/builtins-arm64.c
===
--- test/CodeGen/builtins-arm64.c
+++ test/CodeGen/builtins-arm64.c
@@ -1,6 +1,4 @@
 // RUN: %clang_cc1 -triple arm64-unknown-linux -disable-O0-optnone -emit-llvm -o - %s | opt -S -mem2reg | FileCheck %s
-// RUN: %clang_cc1 -triple aarch64-windows -disable-O0-optnone -emit-llvm -o - %s | opt -S -mem2reg | FileCheck %s
-#include 
 
 void f0(void *a, void *b) {
 	__clear_cache(a,b);
@@ -57,7 +55,7 @@
   return __builtin_arm_rsr("1:2:3:4:5");
 }
 
-uint64_t rsr64() {
+unsigned long rsr64() {
   // CHECK: call i64 @llvm.read_register.i64(metadata ![[M0:[0-9]]])
   return __builtin_arm_rsr64("1:2:3:4:5");
 }
@@ -74,7 +72,7 @@
   __builtin_arm_wsr("1:2:3:4:5", v);
 }
 
-void wsr64(uint64_t v) {
+void wsr64(unsigned long v) {
   // CHECK: call void @llvm.write_register.i64(metadata ![[M0:[0-9]]], i64 %v)
   __builtin_arm_wsr64("1:2:3:4:5", v);
 }
___

r352153 - Revert "[AArch64] Use LL for 64-bit intrinsic arguments"

[Petr Hosek via cfe-commits]

Author: phosek
Date: Thu Jan 24 18:16:29 2019
New Revision: 352153

URL: http://llvm.org/viewvc/llvm-project?rev=352153=rev
Log:
Revert "[AArch64] Use LL for 64-bit intrinsic arguments"

This reverts commit r351740: this broke on platforms where unsigned long
long isn't the same as uint64_t which is what ACLE specifies for the
return value of rsr64.

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

Modified:
cfe/trunk/include/clang/Basic/BuiltinsAArch64.def
cfe/trunk/test/CodeGen/arm64-crc32.c
cfe/trunk/test/CodeGen/builtins-arm64.c

Modified: cfe/trunk/include/clang/Basic/BuiltinsAArch64.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsAArch64.def?rev=352153=352152=352153=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsAArch64.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsAArch64.def Thu Jan 24 18:16:29 2019
@@ -32,7 +32,7 @@ BUILTIN(__builtin_arm_clrex, "v", "")
 
 // Bit manipulation
 BUILTIN(__builtin_arm_rbit, "UiUi", "nc")
-BUILTIN(__builtin_arm_rbit64, "LLUiLLUi", "nc")
+BUILTIN(__builtin_arm_rbit64, "LUiLUi", "nc")
 
 // HINT
 BUILTIN(__builtin_arm_nop, "v", "")
@@ -49,8 +49,8 @@ BUILTIN(__builtin_arm_crc32h, "UiUiUs",
 BUILTIN(__builtin_arm_crc32ch, "UiUiUs", "nc")
 BUILTIN(__builtin_arm_crc32w, "UiUiUi", "nc")
 BUILTIN(__builtin_arm_crc32cw, "UiUiUi", "nc")
-BUILTIN(__builtin_arm_crc32d, "UiUiLLUi", "nc")
-BUILTIN(__builtin_arm_crc32cd, "UiUiLLUi", "nc")
+BUILTIN(__builtin_arm_crc32d, "UiUiLUi", "nc")
+BUILTIN(__builtin_arm_crc32cd, "UiUiLUi", "nc")
 
 // Memory barrier
 BUILTIN(__builtin_arm_dmb, "vUi", "nc")
@@ -62,10 +62,10 @@ BUILTIN(__builtin_arm_prefetch, "vvC*UiU
 
 // System Registers
 BUILTIN(__builtin_arm_rsr, "UicC*", "nc")
-BUILTIN(__builtin_arm_rsr64, "LLUicC*", "nc")
+BUILTIN(__builtin_arm_rsr64, "LUicC*", "nc")
 BUILTIN(__builtin_arm_rsrp, "v*cC*", "nc")
 BUILTIN(__builtin_arm_wsr, "vcC*Ui", "nc")
-BUILTIN(__builtin_arm_wsr64, "vcC*LLUi", "nc")
+BUILTIN(__builtin_arm_wsr64, "vcC*LUi", "nc")
 BUILTIN(__builtin_arm_wsrp, "vcC*vC*", "nc")
 
 // MSVC

Modified: cfe/trunk/test/CodeGen/arm64-crc32.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/arm64-crc32.c?rev=352153=352152=352153=diff
==
--- cfe/trunk/test/CodeGen/arm64-crc32.c (original)
+++ cfe/trunk/test/CodeGen/arm64-crc32.c Thu Jan 24 18:16:29 2019
@@ -1,57 +1,54 @@
 // REQUIRES: aarch64-registered-target
 // RUN: %clang_cc1 -triple arm64-none-linux-gnu \
 // RUN:  -disable-O0-optnone -S -emit-llvm -o - %s | opt -S -mem2reg | 
FileCheck %s
-// RUN: %clang_cc1 -triple aarch64-windows \
-// RUN:  -disable-O0-optnone -S -emit-llvm -o - %s | opt -S -mem2reg | 
FileCheck %s
-#include 
 
-uint32_t crc32b(uint32_t a, uint8_t b)
+int crc32b(int a, char b)
 {
 return __builtin_arm_crc32b(a,b);
 // CHECK: [[T0:%[0-9]+]] = zext i8 %b to i32
 // CHECK: call i32 @llvm.aarch64.crc32b(i32 %a, i32 [[T0]])
 }
 
-uint32_t crc32cb(uint32_t a, uint8_t b)
+int crc32cb(int a, char b)
 {
 return __builtin_arm_crc32cb(a,b);
 // CHECK: [[T0:%[0-9]+]] = zext i8 %b to i32
 // CHECK: call i32 @llvm.aarch64.crc32cb(i32 %a, i32 [[T0]])
 }
 
-uint32_t crc32h(uint32_t a, uint16_t b)
+int crc32h(int a, short b)
 {
 return __builtin_arm_crc32h(a,b);
 // CHECK: [[T0:%[0-9]+]] = zext i16 %b to i32
 // CHECK: call i32 @llvm.aarch64.crc32h(i32 %a, i32 [[T0]])
 }
 
-uint32_t crc32ch(uint32_t a, uint16_t b)
+int crc32ch(int a, short b)
 {
 return __builtin_arm_crc32ch(a,b);
 // CHECK: [[T0:%[0-9]+]] = zext i16 %b to i32
 // CHECK: call i32 @llvm.aarch64.crc32ch(i32 %a, i32 [[T0]])
 }
 
-uint32_t crc32w(uint32_t a, uint32_t b)
+int crc32w(int a, int b)
 {
 return __builtin_arm_crc32w(a,b);
 // CHECK: call i32 @llvm.aarch64.crc32w(i32 %a, i32 %b)
 }
 
-uint32_t crc32cw(uint32_t a, uint32_t b)
+int crc32cw(int a, int b)
 {
 return __builtin_arm_crc32cw(a,b);
 // CHECK: call i32 @llvm.aarch64.crc32cw(i32 %a, i32 %b)
 }
 
-uint32_t crc32d(uint32_t a, uint64_t b)
+int crc32d(int a, long b)
 {
 return __builtin_arm_crc32d(a,b);
 // CHECK: call i32 @llvm.aarch64.crc32x(i32 %a, i64 %b)
 }
 
-uint32_t crc32cd(uint32_t a, uint64_t b)
+int crc32cd(int a, long b)
 {
 return __builtin_arm_crc32cd(a,b);
 // CHECK: call i32 @llvm.aarch64.crc32cx(i32 %a, i64 %b)

Modified: cfe/trunk/test/CodeGen/builtins-arm64.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/builtins-arm64.c?rev=352153=352152=352153=diff
==
--- cfe/trunk/test/CodeGen/builtins-arm64.c (original)
+++ cfe/trunk/test/CodeGen/builtins-arm64.c Thu Jan 24 18:16:29 2019
@@ -1,6 +1,4 @@
 // RUN: %clang_cc1 -triple arm64-unknown-linux -disable-O0-optnone -emit-llvm 
-o - %s | opt -S -mem2reg | FileCheck %s
-// RUN: %clang_cc1 -triple 

[PATCH] D57209: Revert "[AArch64] Use LL for 64-bit intrinsic arguments"

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

I'd say go for it, it's basically already EOD Pacific time, and I don't think 
anyone has set up a continuous Windows ARM64 build with ToT clang anywhere in 
the world yet.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57209



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

[PATCH] D56624: [Sanitizers] UBSan unreachable incompatible with ASan in the presence of `noreturn` calls

[Julian Lettner via Phabricator via cfe-commits]

yln added a comment.

In D56624#1370579 , @eugenis wrote:

> Maybe the frontend should insert __asan_handle_noreturn whenever ASan is 
> enabled, and then ASan would not care about the attribute? I'd like to avoid 
> having this logic in two places.


+1 for this. @vsk Can you sign off on this design?


Repository:
  rL LLVM

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

https://reviews.llvm.org/D56624



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

[PATCH] D57209: Revert "[AArch64] Use LL for 64-bit intrinsic arguments"

[Petr Hosek via Phabricator via cfe-commits]

phosek added a comment.

Is it OK with you to land this revert, followed by D57210 
, and then reland this with the appropriate 
fix?


Repository:
  rC Clang

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

https://reviews.llvm.org/D57209



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

[PATCH] D57075: [ObjC] For type substitution in generics use a regular recursive type visitor.

[Volodymyr Sapsai via Phabricator via cfe-commits]

vsapsai added a comment.

I've added a test case with typedef and think it should be emitting a warning. 
I.e., the behaviour with typedef should be the same as without it, modulo 
different pretty-printing in diagnostic. The interesting part is that this test 
is failing even without my change. I'll look into that and depending on the 
fix, I'll update this change accordingly.


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

https://reviews.llvm.org/D57075



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

[PATCH] D57204: [AST] Add a method to get a call type from an ObjCMessageExpr

[George Karpenkov via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rC352147: [AST] Add a method to get a call type from an 
ObjCMessageExpr (authored by george.karpenkov, committed by ).
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D57204?vs=183439=183453#toc

Repository:
  rC Clang

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

https://reviews.llvm.org/D57204

Files:
  include/clang/AST/ExprObjC.h
  lib/AST/ExprObjC.cpp


Index: include/clang/AST/ExprObjC.h
===
--- include/clang/AST/ExprObjC.h
+++ include/clang/AST/ExprObjC.h
@@ -1180,6 +1180,13 @@
   /// sent to.
   ReceiverKind getReceiverKind() const { return (ReceiverKind)Kind; }
 
+  /// \return the return type of the message being sent.
+  /// This is not always the type of the message expression itself because
+  /// of references (the expression would not have a reference type).
+  /// It is also not always the declared return type of the method because
+  /// of `instancetype` (in that case it's an expression type).
+  QualType getCallReturnType(ASTContext ) const;
+
   /// Source range of the receiver.
   SourceRange getReceiverRange() const;
 
Index: lib/AST/ExprObjC.cpp
===
--- lib/AST/ExprObjC.cpp
+++ lib/AST/ExprObjC.cpp
@@ -292,6 +292,31 @@
 SelLocs.push_back(getSelectorLoc(i));
 }
 
+
+QualType ObjCMessageExpr::getCallReturnType(ASTContext ) const {
+  if (const ObjCMethodDecl *MD = getMethodDecl()) {
+QualType QT = MD->getReturnType();
+if (QT == Ctx.getObjCInstanceType()) {
+  // instancetype corresponds to expression types.
+  return getType();
+}
+return QT;
+  }
+
+  // Expression type might be different from an expected call return type,
+  // as expression type would never be a reference even if call returns a
+  // reference. Reconstruct the original expression type.
+  QualType QT = getType();
+  switch (getValueKind()) {
+  case VK_LValue:
+return Ctx.getLValueReferenceType(QT);
+  case VK_XValue:
+return Ctx.getRValueReferenceType(QT);
+  case VK_RValue:
+return QT;
+  }
+}
+
 SourceRange ObjCMessageExpr::getReceiverRange() const {
   switch (getReceiverKind()) {
   case Instance:


Index: include/clang/AST/ExprObjC.h
===
--- include/clang/AST/ExprObjC.h
+++ include/clang/AST/ExprObjC.h
@@ -1180,6 +1180,13 @@
   /// sent to.
   ReceiverKind getReceiverKind() const { return (ReceiverKind)Kind; }
 
+  /// \return the return type of the message being sent.
+  /// This is not always the type of the message expression itself because
+  /// of references (the expression would not have a reference type).
+  /// It is also not always the declared return type of the method because
+  /// of `instancetype` (in that case it's an expression type).
+  QualType getCallReturnType(ASTContext ) const;
+
   /// Source range of the receiver.
   SourceRange getReceiverRange() const;
 
Index: lib/AST/ExprObjC.cpp
===
--- lib/AST/ExprObjC.cpp
+++ lib/AST/ExprObjC.cpp
@@ -292,6 +292,31 @@
 SelLocs.push_back(getSelectorLoc(i));
 }
 
+
+QualType ObjCMessageExpr::getCallReturnType(ASTContext ) const {
+  if (const ObjCMethodDecl *MD = getMethodDecl()) {
+QualType QT = MD->getReturnType();
+if (QT == Ctx.getObjCInstanceType()) {
+  // instancetype corresponds to expression types.
+  return getType();
+}
+return QT;
+  }
+
+  // Expression type might be different from an expected call return type,
+  // as expression type would never be a reference even if call returns a
+  // reference. Reconstruct the original expression type.
+  QualType QT = getType();
+  switch (getValueKind()) {
+  case VK_LValue:
+return Ctx.getLValueReferenceType(QT);
+  case VK_XValue:
+return Ctx.getRValueReferenceType(QT);
+  case VK_RValue:
+return QT;
+  }
+}
+
 SourceRange ObjCMessageExpr::getReceiverRange() const {
   switch (getReceiverKind()) {
   case Instance:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D57210: [AArch64] Make the test for rsr and rsr64 stricter

[Eli Friedman via Phabricator via cfe-commits]

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

LGTM


Repository:
  rC Clang

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

https://reviews.llvm.org/D57210



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

[PATCH] D56624: [Sanitizers] UBSan unreachable incompatible with ASan in the presence of `noreturn` calls

[Evgenii Stepanov via Phabricator via cfe-commits]

eugenis added a comment.

Maybe the frontend should insert __asan_handle_noreturn whenever ASan is 
enabled, and then ASan would not care about the attribute? I'd like to avoid 
having this logic in two places.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D56624



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

r352148 - [analysis] Introduce an AnyCall helper class, for abstraction over different callables

[George Karpenkov via cfe-commits]

Author: george.karpenkov
Date: Thu Jan 24 17:23:51 2019
New Revision: 352148

URL: http://llvm.org/viewvc/llvm-project?rev=352148=rev
Log:
[analysis] Introduce an AnyCall helper class, for abstraction over different 
callables

A lot of code, particularly in the analyzer, has to perform a lot of
duplication to handle functions/ObjCMessages/destructors/constructors in
a generic setting.
The analyzer already has a CallEvent helper class abstracting over such
calls, but it's not always suitable, since it's tightly coupled to other
analyzer classes (ExplodedNode, ProgramState, etc.) and it's not always
possible to construct.

This change introduces a very simple, very lightweight helper class to
do simple generic operations over callables.

In future, parts of CallEvent could be changed to use this class to
avoid some duplication.

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

Added:
cfe/trunk/include/clang/Analysis/AnyCall.h

Added: cfe/trunk/include/clang/Analysis/AnyCall.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Analysis/AnyCall.h?rev=352148=auto
==
--- cfe/trunk/include/clang/Analysis/AnyCall.h (added)
+++ cfe/trunk/include/clang/Analysis/AnyCall.h Thu Jan 24 17:23:51 2019
@@ -0,0 +1,174 @@
+//=== AnyCall.h - Abstraction over different callables *- C++ -*--//
+//
+// 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
+//
+//===--===//
+//
+// A utility class for performing generic operations over different callables.
+//
+//===--===//
+//
+#ifndef LLVM_CLANG_ANALYSIS_ANY_CALL_H
+#define LLVM_CLANG_ANALYSIS_ANY_CALL_H
+
+#include "clang/AST/Decl.h"
+#include "clang/AST/ExprCXX.h"
+#include "clang/AST/ExprObjC.h"
+
+namespace clang {
+
+/// An instance of this class corresponds to a 'callable' call.
+class AnyCall {
+public:
+  enum Kind {
+/// A function, function pointer, or a C++ method call
+Function,
+
+/// A call to an Objective-C method
+ObjCMethod,
+
+/// A call to an Objective-C block
+Block,
+
+/// An implicit C++ destructor call (called implicitly
+/// or by operator 'delete')
+Destructor,
+
+/// An implicit or explicit C++ constructor call
+Constructor,
+
+/// A C++ allocation function call (operator `new`), via C++ new-expression
+Allocator,
+
+/// A C++ deallocation function call (operator `delete`), via C++
+/// delete-expression
+Deallocator
+  };
+
+private:
+  /// Call expression, remains null iff the call is an implicit destructor 
call.
+  const Expr *E = nullptr;
+
+  /// Corresponds to a statically known declaration of the called function,
+  /// or null if it is not known (e.g. for a function pointer).
+  const Decl *D = nullptr;
+  Kind K;
+
+  AnyCall(const Expr *E, const Decl *D, Kind K) : E(E), D(D), K(K) {}
+
+public:
+  AnyCall(const CallExpr *CE) : E(CE) {
+D = CE->getCalleeDecl();
+K = (CE->getCallee()->getType()->getAs()) ? Block
+: Function;
+if (D && ((K == Function && !isa(D)) ||
+  (K == Block && !isa(D
+  D = nullptr;
+  }
+
+  AnyCall(const ObjCMessageExpr *ME)
+  : E(ME), D(ME->getMethodDecl()), K(ObjCMethod) {}
+
+  AnyCall(const CXXNewExpr *NE)
+  : E(NE), D(NE->getOperatorNew()), K(Allocator) {}
+
+  AnyCall(const CXXDeleteExpr *NE)
+  : E(NE), D(NE->getOperatorDelete()), K(Deallocator) {}
+
+  AnyCall(const CXXConstructExpr *NE)
+  : E(NE), D(NE->getConstructor()), K(Constructor) {}
+
+  /// If {@code E} is a generic call (to ObjC method /function/block/etc),
+  /// return a constructed {@code AnyCall} object. Return None otherwise.
+  static Optional forExpr(const Expr *E) {
+if (const auto *ME = dyn_cast(E)) {
+  return AnyCall(ME);
+} else if (const auto *CE = dyn_cast(E)) {
+  return AnyCall(CE);
+} else if (const auto *CXNE = dyn_cast(E)) {
+  return AnyCall(CXNE);
+} else if (const auto *CXDE = dyn_cast(E)) {
+  return AnyCall(CXDE);
+} else if (const auto *CXCE = dyn_cast(E)) {
+  return AnyCall(CXCE);
+} else {
+  return None;
+}
+  }
+
+  static AnyCall forDestructorCall(const CXXDestructorDecl *D) {
+return AnyCall(/*E=*/nullptr, D, Destructor);
+  }
+
+  /// \returns formal parameters for direct calls (including virtual calls)
+  ArrayRef parameters() const {
+if (!D)
+  return None;
+
+if (const auto *FD = dyn_cast(D)) {
+  return FD->parameters();
+} else if (const auto *MD = dyn_cast(D)) {
+  return MD->parameters();
+} else if (const auto *CD = dyn_cast(D)) {
+  return CD->parameters();
+  

r352147 - [AST] Add a method to get a call type from an ObjCMessageExpr

[George Karpenkov via cfe-commits]

Author: george.karpenkov
Date: Thu Jan 24 17:23:37 2019
New Revision: 352147

URL: http://llvm.org/viewvc/llvm-project?rev=352147=rev
Log:
[AST] Add a method to get a call type from an ObjCMessageExpr

Due to references, expression type does not always correspond to an
expected method return type (e.g. for a method returning int & the
expression type of the call would still be int).
We have a helper method for getting the expected type on CallExpr, but
not on ObjCMessageExpr.

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

Modified:
cfe/trunk/include/clang/AST/ExprObjC.h
cfe/trunk/lib/AST/ExprObjC.cpp

Modified: cfe/trunk/include/clang/AST/ExprObjC.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ExprObjC.h?rev=352147=352146=352147=diff
==
--- cfe/trunk/include/clang/AST/ExprObjC.h (original)
+++ cfe/trunk/include/clang/AST/ExprObjC.h Thu Jan 24 17:23:37 2019
@@ -1180,6 +1180,13 @@ public:
   /// sent to.
   ReceiverKind getReceiverKind() const { return (ReceiverKind)Kind; }
 
+  /// \return the return type of the message being sent.
+  /// This is not always the type of the message expression itself because
+  /// of references (the expression would not have a reference type).
+  /// It is also not always the declared return type of the method because
+  /// of `instancetype` (in that case it's an expression type).
+  QualType getCallReturnType(ASTContext ) const;
+
   /// Source range of the receiver.
   SourceRange getReceiverRange() const;
 

Modified: cfe/trunk/lib/AST/ExprObjC.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprObjC.cpp?rev=352147=352146=352147=diff
==
--- cfe/trunk/lib/AST/ExprObjC.cpp (original)
+++ cfe/trunk/lib/AST/ExprObjC.cpp Thu Jan 24 17:23:37 2019
@@ -292,6 +292,31 @@ void ObjCMessageExpr::getSelectorLocs(
 SelLocs.push_back(getSelectorLoc(i));
 }
 
+
+QualType ObjCMessageExpr::getCallReturnType(ASTContext ) const {
+  if (const ObjCMethodDecl *MD = getMethodDecl()) {
+QualType QT = MD->getReturnType();
+if (QT == Ctx.getObjCInstanceType()) {
+  // instancetype corresponds to expression types.
+  return getType();
+}
+return QT;
+  }
+
+  // Expression type might be different from an expected call return type,
+  // as expression type would never be a reference even if call returns a
+  // reference. Reconstruct the original expression type.
+  QualType QT = getType();
+  switch (getValueKind()) {
+  case VK_LValue:
+return Ctx.getLValueReferenceType(QT);
+  case VK_XValue:
+return Ctx.getRValueReferenceType(QT);
+  case VK_RValue:
+return QT;
+  }
+}
+
 SourceRange ObjCMessageExpr::getReceiverRange() const {
   switch (getReceiverKind()) {
   case Instance:


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

[PATCH] D57209: Revert "[AArch64] Use LL for 64-bit intrinsic arguments"

[Eli Friedman via Phabricator via cfe-commits]

efriedma added a comment.

Oh, rsr and wsr are macros, not functions... I was confused how it would break.

The correct signature for __builtin_arm_rsr64 is "WUicC*", I think.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57209



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

[PATCH] D57075: [ObjC] For type substitution in generics use a regular recursive type visitor.

[Volodymyr Sapsai via Phabricator via cfe-commits]

vsapsai updated this revision to Diff 183450.
vsapsai added a comment.

- Add a failing test case.


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

https://reviews.llvm.org/D57075

Files:
  clang/lib/AST/Type.cpp
  clang/test/SemaObjC/parameterized_classes_subst.m

Index: clang/test/SemaObjC/parameterized_classes_subst.m
===
--- clang/test/SemaObjC/parameterized_classes_subst.m
+++ clang/test/SemaObjC/parameterized_classes_subst.m
@@ -104,6 +104,12 @@
 @property (nonatomic,retain) ViewType view;
 @end
 
+@interface TypedefTypeParam : NSObject
+typedef T AliasT;
+- (void)test:(AliasT)object;
+// expected-note@-1 {{parameter 'object' here}}
+@end
+
 // --
 // Nullability
 // --
@@ -190,6 +196,7 @@
MutableSetOfArrays *mutStringArraySet,
NSMutableSet *mutSet,
MutableSetOfArrays *mutArraySet,
+   TypedefTypeParam *typedefTypeParam,
void (^block)(void)) {
   Window *window;
 
@@ -199,6 +206,7 @@
   [mutStringArraySet addObject: window]; // expected-warning{{parameter of type 'NSArray *'}}
   [mutSet addObject: window]; // expected-warning{{parameter of incompatible type 'id'}}
   [mutArraySet addObject: window]; // expected-warning{{parameter of incompatible type 'id'}}
+  [typedefTypeParam test: window]; // expected-warning{{parameter of type 'NSString *'}}
   [block addObject: window]; // expected-warning{{parameter of incompatible type 'id'}}
 }
 
Index: clang/lib/AST/Type.cpp
===
--- clang/lib/AST/Type.cpp
+++ clang/lib/AST/Type.cpp
@@ -722,25 +722,30 @@
   return ctx.getObjCObjectPointerType(obj)->castAs();
 }
 
-template
-static QualType simpleTransform(ASTContext , QualType type, F &);
-
 namespace {
 
-/// Visitor used by simpleTransform() to perform the transformation.
-template
-struct SimpleTransformVisitor
- : public TypeVisitor, QualType> {
+/// Visitor used to perform a simple type transformation that does not change
+/// the semantics of the type.
+template 
+struct SimpleTransformVisitor : public TypeVisitor {
   ASTContext 
-  F &
 
   QualType recurse(QualType type) {
-return simpleTransform(Ctx, type, std::move(TheFunc));
+// Split out the qualifiers from the type.
+SplitQualType splitType = type.split();
+
+// Visit the type itself.
+QualType result = static_cast(this)->Visit(splitType.Ty);
+if (result.isNull())
+  return result;
+
+// Reconstruct the transformed type by applying the local qualifiers
+// from the split type.
+return Ctx.getQualifiedType(result, splitType.Quals);
   }
 
 public:
-  SimpleTransformVisitor(ASTContext , F &)
-  : Ctx(ctx), TheFunc(std::move(f)) {}
+  explicit SimpleTransformVisitor(ASTContext ) : Ctx(ctx) {}
 
   // None of the clients of this transformation can occur where
   // there are dependent types, so skip dependent types.
@@ -1108,220 +1113,205 @@
 #undef TRIVIAL_TYPE_CLASS
 };
 
-} // namespace
+struct SubstObjCTypeArgsVisitor
+: public SimpleTransformVisitor {
+  using BaseType = SimpleTransformVisitor;
 
-/// Perform a simple type transformation that does not change the
-/// semantics of the type.
-template
-static QualType simpleTransform(ASTContext , QualType type, F &) {
-  // Transform the type. If it changed, return the transformed result.
-  QualType transformed = f(type);
-  if (transformed.getAsOpaquePtr() != type.getAsOpaquePtr())
-return transformed;
-
-  // Split out the qualifiers from the type.
-  SplitQualType splitType = type.split();
-
-  // Visit the type itself.
-  SimpleTransformVisitor visitor(ctx, std::forward(f));
-  QualType result = visitor.Visit(splitType.Ty);
-  if (result.isNull())
-return result;
-
-  // Reconstruct the transformed type by applying the local qualifiers
-  // from the split type.
-  return ctx.getQualifiedType(result, splitType.Quals);
-}
+  ArrayRef TypeArgs;
+  ObjCSubstitutionContext SubstContext;
 
-/// Substitute the given type arguments for Objective-C type
-/// parameters within the given type, recursively.
-QualType QualType::substObjCTypeArgs(
-   ASTContext ,
-   ArrayRef typeArgs,
-   ObjCSubstitutionContext context) const {
-  return simpleTransform(ctx, *this,
- [&](QualType type) -> QualType {
-SplitQualType splitType = type.split();
+  SubstObjCTypeArgsVisitor(ASTContext , ArrayRef typeArgs,
+   ObjCSubstitutionContext context)
+  : BaseType(ctx), TypeArgs(typeArgs), SubstContext(context) {}
 
+  QualType VisitObjCTypeParamType(const ObjCTypeParamType *OTPTy) {
 // Replace an Objective-C type parameter reference with the corresponding
 // type argument.
-if (const auto *OTPTy = dyn_cast(splitType.Ty)) {
-  

[PATCH] D56852: [AArch64] Use LL for 64-bit arguments

[Petr Hosek via Phabricator via cfe-commits]

phosek added a comment.

This broke our kernel build which uses `PRIx64` to print the return value of 
`__builtin_arm_rsr64`. This is correct because according to ACLE, the return 
type of that builtin should be `uint64_t`. Problem is that on AArch64, 
`unsigned long` is equivalent to `uint64_t`, not `unsigned long long` (at least 
on Linux and other platforms like Fuchsia).

The reason this wasn't caught by the test is because that test isn't strict 
enough. I've updated the test in D57210 . I 
believe this change should be reverted because it's wrong and I created revert 
in D57209 . I think the correct solution might 
be what rnk suggested in his comment, that is to use `W` instead of `LL`. I 
plan on landing my revert if I don't hear back by EOD because this is currently 
blocking our kernel build with the latest Clang.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D56852



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

[PATCH] D57210: [AArch64] Make the test for rsr and rsr64 stricter

[Petr Hosek via Phabricator via cfe-commits]

phosek created this revision.
phosek added reviewers: samparker, efriedma, t.p.northover, rnk.
Herald added subscribers: cfe-commits, kristof.beyls, javed.absar.

ACLE specifies that return type for rsr and rsr64 is uint32_t and
uint64_t respectively. D56852  change the 
return type of rsr64 from
unsigned long to unsigned long long which at least on Linux doesn't
match uint64_t, but the test isn't strict enough to detect that
because compiler implicitly converts unsigned long long to uint64_t,
but it breaks other uses such as printf with PRIx64 type specifier.
This change makes the test stricter enforcing that the return type
of rsr and rsr64 builtins is what is actually specified in ACLE.


Repository:
  rC Clang

https://reviews.llvm.org/D57210

Files:
  clang/test/CodeGen/builtins-arm64.c


Index: clang/test/CodeGen/builtins-arm64.c
===
--- clang/test/CodeGen/builtins-arm64.c
+++ clang/test/CodeGen/builtins-arm64.c
@@ -51,12 +51,16 @@
 // CHECK: call {{.*}} @llvm.prefetch(i8* null, i32 0, i32 3, i32 0)
 }
 
-unsigned rsr() {
+__typeof__(__builtin_arm_rsr("1:2:3:4:5")) rsr(void);
+
+uint32_t rsr() {
   // CHECK: [[V0:[%A-Za-z0-9.]+]] = call i64 @llvm.read_register.i64(metadata 
![[M0:[0-9]]])
   // CHECK-NEXT: trunc i64 [[V0]] to i32
   return __builtin_arm_rsr("1:2:3:4:5");
 }
 
+__typeof__(__builtin_arm_rsr64("1:2:3:4:5")) rsr64(void);
+
 uint64_t rsr64() {
   // CHECK: call i64 @llvm.read_register.i64(metadata ![[M0:[0-9]]])
   return __builtin_arm_rsr64("1:2:3:4:5");


Index: clang/test/CodeGen/builtins-arm64.c
===
--- clang/test/CodeGen/builtins-arm64.c
+++ clang/test/CodeGen/builtins-arm64.c
@@ -51,12 +51,16 @@
 // CHECK: call {{.*}} @llvm.prefetch(i8* null, i32 0, i32 3, i32 0)
 }
 
-unsigned rsr() {
+__typeof__(__builtin_arm_rsr("1:2:3:4:5")) rsr(void);
+
+uint32_t rsr() {
   // CHECK: [[V0:[%A-Za-z0-9.]+]] = call i64 @llvm.read_register.i64(metadata ![[M0:[0-9]]])
   // CHECK-NEXT: trunc i64 [[V0]] to i32
   return __builtin_arm_rsr("1:2:3:4:5");
 }
 
+__typeof__(__builtin_arm_rsr64("1:2:3:4:5")) rsr64(void);
+
 uint64_t rsr64() {
   // CHECK: call i64 @llvm.read_register.i64(metadata ![[M0:[0-9]]])
   return __builtin_arm_rsr64("1:2:3:4:5");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56624: [Sanitizers] UBSan unreachable incompatible with ASan in the presence of `noreturn` calls

[Julian Lettner via Phabricator via cfe-commits]

yln added a comment.

Seems as if we reached consensus! :)  I will change the revision to use an 
intrinsic.

Before I start doing that, just one more quick idea:
Would it work if UBsan directly inserts calls to `__asan_handle_no_return` (of 
course only when ASan is requested). Similar to how it inserts calls to it's 
own runtime functions (e.g., `__ubsan_handle_builtin_unreachable`).
If we strive for the "simplest" solution... but maybe I am missing something in 
this is too simple?


Repository:
  rL LLVM

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

https://reviews.llvm.org/D56624



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

[PATCH] D57209: Revert "[AArch64] Use LL for 64-bit intrinsic arguments"

[Petr Hosek via Phabricator via cfe-commits]

phosek created this revision.
phosek added reviewers: samparker, efriedma, t.p.northover, rnk.
Herald added subscribers: cfe-commits, kristof.beyls, javed.absar.

This reverts commit r351740: this broke on platforms where unsigned long
long isn't the same as uint64_t which is what ACLE specifies for the
return value of rsr64.


Repository:
  rC Clang

https://reviews.llvm.org/D57209

Files:
  clang/include/clang/Basic/BuiltinsAArch64.def
  clang/test/CodeGen/arm64-crc32.c
  clang/test/CodeGen/builtins-arm64.c

Index: clang/test/CodeGen/builtins-arm64.c
===
--- clang/test/CodeGen/builtins-arm64.c
+++ clang/test/CodeGen/builtins-arm64.c
@@ -1,6 +1,4 @@
 // RUN: %clang_cc1 -triple arm64-unknown-linux -disable-O0-optnone -emit-llvm -o - %s | opt -S -mem2reg | FileCheck %s
-// RUN: %clang_cc1 -triple aarch64-windows -disable-O0-optnone -emit-llvm -o - %s | opt -S -mem2reg | FileCheck %s
-#include 
 
 void f0(void *a, void *b) {
 	__clear_cache(a,b);
@@ -57,7 +55,7 @@
   return __builtin_arm_rsr("1:2:3:4:5");
 }
 
-uint64_t rsr64() {
+unsigned long rsr64() {
   // CHECK: call i64 @llvm.read_register.i64(metadata ![[M0:[0-9]]])
   return __builtin_arm_rsr64("1:2:3:4:5");
 }
@@ -74,7 +72,7 @@
   __builtin_arm_wsr("1:2:3:4:5", v);
 }
 
-void wsr64(uint64_t v) {
+void wsr64(unsigned long v) {
   // CHECK: call void @llvm.write_register.i64(metadata ![[M0:[0-9]]], i64 %v)
   __builtin_arm_wsr64("1:2:3:4:5", v);
 }
Index: clang/test/CodeGen/arm64-crc32.c
===
--- clang/test/CodeGen/arm64-crc32.c
+++ clang/test/CodeGen/arm64-crc32.c
@@ -1,57 +1,54 @@
 // REQUIRES: aarch64-registered-target
 // RUN: %clang_cc1 -triple arm64-none-linux-gnu \
 // RUN:  -disable-O0-optnone -S -emit-llvm -o - %s | opt -S -mem2reg | FileCheck %s
-// RUN: %clang_cc1 -triple aarch64-windows \
-// RUN:  -disable-O0-optnone -S -emit-llvm -o - %s | opt -S -mem2reg | FileCheck %s
-#include 
 
-uint32_t crc32b(uint32_t a, uint8_t b)
+int crc32b(int a, char b)
 {
 return __builtin_arm_crc32b(a,b);
 // CHECK: [[T0:%[0-9]+]] = zext i8 %b to i32
 // CHECK: call i32 @llvm.aarch64.crc32b(i32 %a, i32 [[T0]])
 }
 
-uint32_t crc32cb(uint32_t a, uint8_t b)
+int crc32cb(int a, char b)
 {
 return __builtin_arm_crc32cb(a,b);
 // CHECK: [[T0:%[0-9]+]] = zext i8 %b to i32
 // CHECK: call i32 @llvm.aarch64.crc32cb(i32 %a, i32 [[T0]])
 }
 
-uint32_t crc32h(uint32_t a, uint16_t b)
+int crc32h(int a, short b)
 {
 return __builtin_arm_crc32h(a,b);
 // CHECK: [[T0:%[0-9]+]] = zext i16 %b to i32
 // CHECK: call i32 @llvm.aarch64.crc32h(i32 %a, i32 [[T0]])
 }
 
-uint32_t crc32ch(uint32_t a, uint16_t b)
+int crc32ch(int a, short b)
 {
 return __builtin_arm_crc32ch(a,b);
 // CHECK: [[T0:%[0-9]+]] = zext i16 %b to i32
 // CHECK: call i32 @llvm.aarch64.crc32ch(i32 %a, i32 [[T0]])
 }
 
-uint32_t crc32w(uint32_t a, uint32_t b)
+int crc32w(int a, int b)
 {
 return __builtin_arm_crc32w(a,b);
 // CHECK: call i32 @llvm.aarch64.crc32w(i32 %a, i32 %b)
 }
 
-uint32_t crc32cw(uint32_t a, uint32_t b)
+int crc32cw(int a, int b)
 {
 return __builtin_arm_crc32cw(a,b);
 // CHECK: call i32 @llvm.aarch64.crc32cw(i32 %a, i32 %b)
 }
 
-uint32_t crc32d(uint32_t a, uint64_t b)
+int crc32d(int a, long b)
 {
 return __builtin_arm_crc32d(a,b);
 // CHECK: call i32 @llvm.aarch64.crc32x(i32 %a, i64 %b)
 }
 
-uint32_t crc32cd(uint32_t a, uint64_t b)
+int crc32cd(int a, long b)
 {
 return __builtin_arm_crc32cd(a,b);
 // CHECK: call i32 @llvm.aarch64.crc32cx(i32 %a, i64 %b)
Index: clang/include/clang/Basic/BuiltinsAArch64.def
===
--- clang/include/clang/Basic/BuiltinsAArch64.def
+++ clang/include/clang/Basic/BuiltinsAArch64.def
@@ -32,7 +32,7 @@
 
 // Bit manipulation
 BUILTIN(__builtin_arm_rbit, "UiUi", "nc")
-BUILTIN(__builtin_arm_rbit64, "LLUiLLUi", "nc")
+BUILTIN(__builtin_arm_rbit64, "LUiLUi", "nc")
 
 // HINT
 BUILTIN(__builtin_arm_nop, "v", "")
@@ -49,8 +49,8 @@
 BUILTIN(__builtin_arm_crc32ch, "UiUiUs", "nc")
 BUILTIN(__builtin_arm_crc32w, "UiUiUi", "nc")
 BUILTIN(__builtin_arm_crc32cw, "UiUiUi", "nc")
-BUILTIN(__builtin_arm_crc32d, "UiUiLLUi", "nc")
-BUILTIN(__builtin_arm_crc32cd, "UiUiLLUi", "nc")
+BUILTIN(__builtin_arm_crc32d, "UiUiLUi", "nc")
+BUILTIN(__builtin_arm_crc32cd, "UiUiLUi", "nc")
 
 // Memory barrier
 BUILTIN(__builtin_arm_dmb, "vUi", "nc")
@@ -62,10 +62,10 @@
 
 // System Registers
 BUILTIN(__builtin_arm_rsr, "UicC*", "nc")
-BUILTIN(__builtin_arm_rsr64, "LLUicC*", "nc")
+BUILTIN(__builtin_arm_rsr64, "LUicC*", "nc")
 BUILTIN(__builtin_arm_rsrp, "v*cC*", "nc")
 BUILTIN(__builtin_arm_wsr, "vcC*Ui", "nc")
-BUILTIN(__builtin_arm_wsr64, "vcC*LLUi", "nc")
+BUILTIN(__builtin_arm_wsr64, "vcC*LUi", "nc")
 BUILTIN(__builtin_arm_wsrp, "vcC*vC*", "nc")
 
 // MSVC
___
cfe-commits mailing list

[PATCH] D57208: Replace two RecursiveASTVisitor insantiations with StmtVisitor

[Reid Kleckner via Phabricator via cfe-commits]

rnk created this revision.
rnk added reviewers: arphaman, rsmith.

RecursiveASTVisitor is very expensive to instantiate and results in
needlessly slow compilation. For these availability check fixits, we
don't need to instantiate the full complexity of the declaration walking
machinery, we can use a plain StmtVisitor.

This change reduces time to compile SemaDeclAttr.cpp and saves object
file size:

  | before   | after

time (s) | 1m7.821s | 0m52.459s
obj (kb) | 13280| 11364

So, 15s and 1.9 MB of object file. If clang had presubmits checks, I'd
add a check that warned on new inclusions of RecursiveASTVisitor.h.  =/

I won't promise that this doesn't change functionality, since RAV walks
through quite a number of things that StmtVisitor doesn't, like blocks
and lambdas.

I noticed that SemaOpenMP has a very similar utility called
LocalVarRefChecker, so there is definitely some opportunity for
refactoring further after this.


https://reviews.llvm.org/D57208

Files:
  clang/lib/Sema/SemaDeclAttr.cpp

Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -21,6 +21,7 @@
 #include "clang/AST/ExprCXX.h"
 #include "clang/AST/Mangle.h"
 #include "clang/AST/RecursiveASTVisitor.h"
+#include "clang/AST/StmtVisitor.h"
 #include "clang/Basic/CharInfo.h"
 #include "clang/Basic/SourceManager.h"
 #include "clang/Basic/TargetInfo.h"
@@ -8038,10 +8039,8 @@
 ObjCPropertyAccess);
 }
 
-namespace {
-
 /// Returns true if the given statement can be a body-like child of \p Parent.
-bool isBodyLikeChildStmt(const Stmt *S, const Stmt *Parent) {
+static bool isBodyLikeChildStmt(const Stmt *S, const Stmt *Parent) {
   switch (Parent->getStmtClass()) {
   case Stmt::IfStmtClass:
 return cast(Parent)->getThen() == S ||
@@ -8064,30 +8063,49 @@
   }
 }
 
-class StmtUSEFinder : public RecursiveASTVisitor {
+namespace {
+
+class StmtUSEFinder : public ConstStmtVisitor {
   const Stmt *Target;
 
 public:
-  bool VisitStmt(Stmt *S) { return S != Target; }
+  bool VisitStmt(const Stmt *S) {
+if (S == Target)
+  return true;
+for (const Stmt *Child : S->children())
+  if (Child && Visit(Child))
+return true;
+return false;
+  }
 
   /// Returns true if the given statement is present in the given declaration.
-  static bool isContained(const Stmt *Target, const Decl *D) {
+  /// Typically statements are contained in variable initializers.
+  static bool isContained(const Stmt *Target, const VarDecl *VD) {
 StmtUSEFinder Visitor;
 Visitor.Target = Target;
-return !Visitor.TraverseDecl(const_cast(D));
+if (const Expr *Init = VD->getInit())
+  return Visitor.Visit(Init);
+return false;
   }
 };
 
 /// Traverses the AST and finds the last statement that used a given
 /// declaration.
-class LastDeclUSEFinder : public RecursiveASTVisitor {
+class LastDeclUSEFinder : public ConstStmtVisitor {
   const Decl *D;
 
 public:
-  bool VisitDeclRefExpr(DeclRefExpr *DRE) {
+  bool VisitDeclRefExpr(const DeclRefExpr *DRE) {
 if (DRE->getDecl() == D)
-  return false;
-return true;
+  return true;
+return false;
+  }
+
+  bool VisitStmt(const Stmt *S) {
+for (const Stmt *Child : S->children())
+  if (Child && Visit(Child))
+return true;
+return false;
   }
 
   static const Stmt *findLastStmtThatUsesDecl(const Decl *D,
@@ -8096,7 +8114,7 @@
 Visitor.D = D;
 for (auto I = Scope->body_rbegin(), E = Scope->body_rend(); I != E; ++I) {
   const Stmt *S = *I;
-  if (!Visitor.TraverseStmt(const_cast(S)))
+  if (S && Visitor.Visit(S))
 return S;
 }
 return nullptr;
@@ -8272,9 +8290,12 @@
 const Stmt *LastStmtOfUse = nullptr;
 if (isa(StmtOfUse) && Scope) {
   for (const Decl *D : cast(StmtOfUse)->decls()) {
-if (StmtUSEFinder::isContained(StmtStack.back(), D)) {
-  LastStmtOfUse = LastDeclUSEFinder::findLastStmtThatUsesDecl(D, Scope);
-  break;
+if (const auto *VD = dyn_cast(D)) {
+  if (StmtUSEFinder::isContained(StmtStack.back(), VD)) {
+LastStmtOfUse =
+LastDeclUSEFinder::findLastStmtThatUsesDecl(VD, Scope);
+break;
+  }
 }
   }
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D57207: [clang-tidy] Make google-objc-function-naming ignore implicit functions 

[Stephane Moore via Phabricator via cfe-commits]

stephanemoore created this revision.
Herald added subscribers: cfe-commits, xazax.hun.

Implicit functions are outside the control of source authors and should
be exempt from style restrictions.

Tested via running clang tools tests.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D57207

Files:
  clang-tidy/google/FunctionNamingCheck.cpp
  test/clang-tidy/google-objc-function-naming.m


Index: test/clang-tidy/google-objc-function-naming.m
===
--- test/clang-tidy/google-objc-function-naming.m
+++ test/clang-tidy/google-objc-function-naming.m
@@ -1,5 +1,11 @@
 // RUN: %check_clang_tidy %s google-objc-function-naming %t
 
+#import 
+
+static void TestImplicitlyDefinedFunction(int a) {
+  printf("%d", a);
+}
+
 typedef _Bool bool;
 
 static bool ispositive(int a) { return a > 0; }
Index: clang-tidy/google/FunctionNamingCheck.cpp
===
--- clang-tidy/google/FunctionNamingCheck.cpp
+++ clang-tidy/google/FunctionNamingCheck.cpp
@@ -98,7 +98,7 @@
   Finder->addMatcher(
   functionDecl(
   unless(anyOf(isExpansionInSystemHeader(), cxxMethodDecl(),
-   hasAncestor(namespaceDecl()), isMain(),
+   hasAncestor(namespaceDecl()), isMain(), isImplicit(),
matchesName(validFunctionNameRegex(true)),
allOf(isStaticStorageClass(),
  matchesName(validFunctionNameRegex(false))


Index: test/clang-tidy/google-objc-function-naming.m
===
--- test/clang-tidy/google-objc-function-naming.m
+++ test/clang-tidy/google-objc-function-naming.m
@@ -1,5 +1,11 @@
 // RUN: %check_clang_tidy %s google-objc-function-naming %t
 
+#import 
+
+static void TestImplicitlyDefinedFunction(int a) {
+  printf("%d", a);
+}
+
 typedef _Bool bool;
 
 static bool ispositive(int a) { return a > 0; }
Index: clang-tidy/google/FunctionNamingCheck.cpp
===
--- clang-tidy/google/FunctionNamingCheck.cpp
+++ clang-tidy/google/FunctionNamingCheck.cpp
@@ -98,7 +98,7 @@
   Finder->addMatcher(
   functionDecl(
   unless(anyOf(isExpansionInSystemHeader(), cxxMethodDecl(),
-   hasAncestor(namespaceDecl()), isMain(),
+   hasAncestor(namespaceDecl()), isMain(), isImplicit(),
matchesName(validFunctionNameRegex(true)),
allOf(isStaticStorageClass(),
  matchesName(validFunctionNameRegex(false))
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D57075: [ObjC] For type substitution in generics use a regular recursive type visitor.

[Volodymyr Sapsai via Phabricator via cfe-commits]

vsapsai planned changes to this revision.
vsapsai added inline comments.



Comment at: clang/lib/AST/Type.cpp:1295
+
+  QualType VisitObjCObjectType(const ObjCObjectType *objType) {
+if (!objType->isKindOfType())

erik.pilkington wrote:
> Does this works with type sugar? i.e. previously calling 
> `Ty->getAs()` would have stripped through `TypedefType`, but 
> its not obvious to me that this traversal is doing the right thing for that 
> case.
You are right, great catch. And I have a test case to confirm that.

I've started this refactoring to avoid copy-pasting

```lang=c++
QualType modifiedType = recurse(T->getModifiedType());
if (modifiedType.isNull())
  return {};

QualType equivalentType = recurse(T->getEquivalentType());
if (equivalentType.isNull())
  return {};

if (modifiedType.getAsOpaquePtr()
  == T->getModifiedType().getAsOpaquePtr() &&
equivalentType.getAsOpaquePtr()
  == T->getEquivalentType().getAsOpaquePtr())
  return QualType(T, 0);
```

and use `BaseType::VisitAttributedType(attrType)` instead. I think it is 
possible to achieve the previous behaviour with the traditional recursive 
visitor. But ideas that I have are pretty complicated and I don't think that's 
the right trade-off.


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

https://reviews.llvm.org/D57075



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

[PATCH] D56424: [clang-tidy] Add check for underscores in googletest names.

[Kar Epker via Phabricator via cfe-commits]

karepker updated this revision to Diff 183437.
karepker added a comment.

Rebasing against master.

Not sure if re-arc diffing this is necessary, but I hope it doesn't hurt.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D56424

Files:
  clang-tidy/google/AvoidUnderscoreInGoogletestNameCheck.cpp
  clang-tidy/google/AvoidUnderscoreInGoogletestNameCheck.h
  clang-tidy/google/CMakeLists.txt
  clang-tidy/google/GoogleTidyModule.cpp
  docs/ReleaseNotes.rst
  
docs/clang-tidy/checks/google-readability-avoid-underscore-in-googletest-name.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/readability-avoid-underscore-in-googletest-name.cpp

Index: test/clang-tidy/readability-avoid-underscore-in-googletest-name.cpp
===
--- /dev/null
+++ test/clang-tidy/readability-avoid-underscore-in-googletest-name.cpp
@@ -0,0 +1,108 @@
+// RUN: %check_clang_tidy %s google-readability-avoid-underscore-in-googletest-name %t
+
+#define TEST(test_case_name, test_name) void test_case_name##test_name()
+#define TEST_F(test_case_name, test_name) void test_case_name##test_name()
+#define TEST_P(test_case_name, test_name) void test_case_name##test_name()
+#define TYPED_TEST(test_case_name, test_name) void test_case_name##test_name()
+#define TYPED_TEST_P(test_case_name, test_name) void test_case_name##test_name()
+#define FRIEND_TEST(test_case_name, test_name) void test_case_name##test_name()
+
+TEST(TestCaseName, Illegal_TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:20: warning: avoid using "_" in test name "Illegal_TestName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+
+TEST(TestCaseName, DISABLED_Illegal_TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:20: warning: avoid using "_" in test name "Illegal_TestName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+TEST(TestCaseName, Illegal_Test_Name) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:20: warning: avoid using "_" in test name "Illegal_Test_Name" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+TEST(Illegal_TestCaseName, TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: avoid using "_" in test case name "Illegal_TestCaseName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+TEST(Illegal_Test_CaseName, TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: avoid using "_" in test case name "Illegal_Test_CaseName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+TEST(Illegal_TestCaseName, Illegal_TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: avoid using "_" in test case name "Illegal_TestCaseName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+// CHECK-MESSAGES: :[[@LINE-2]]:28: warning: avoid using "_" in test name "Illegal_TestName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+
+TEST_F(TestCaseFixtureName, Illegal_TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: avoid using "_" in test name "Illegal_TestName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+TEST_F(TestCaseFixtureName, DISABLED_Illegal_Test_Name) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: avoid using "_" in test name "Illegal_Test_Name" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+TEST_F(TestCaseFixtureName, Illegal_Test_Name) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: avoid using "_" in test name "Illegal_Test_Name" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+
+TEST_F(Illegal_TestCaseFixtureName, TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: avoid using "_" in test case name "Illegal_TestCaseFixtureName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+TEST_F(Illegal_TestCaseFixtureName, Illegal_TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: avoid using "_" in test case name "Illegal_TestCaseFixtureName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+// CHECK-MESSAGES: :[[@LINE-2]]:37: warning: avoid using "_" in test name "Illegal_TestName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+
+TEST_F(Illegal_Test_CaseFixtureName, TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: avoid using "_" in test case name "Illegal_Test_CaseFixtureName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+
+TEST_P(ParameterizedTestCaseFixtureName, Illegal_TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:42: warning: avoid using "_" in test name "Illegal_TestName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+TEST_P(ParameterizedTestCaseFixtureName, 

[PATCH] D56624: [Sanitizers] UBSan unreachable incompatible with ASan in the presence of `noreturn` calls

[Vedant Kumar via Phabricator via cfe-commits]

vsk added a comment.

In D56624#1370280 , @eugenis wrote:

> > Wouldn’t it be preferable to unpoison the stack inside of maybe_longjmp, 
> > once the opaque condition can be checked?
>
> Sure, but that's not always possible. That's why we have interceptors.


Fair enough!

>>> One possible optimization that I can think of is splitting code after the 
>>> call into a separate basic block and marking it as cold.
>>>  Admittedly, that's unlikely to have big impact in practice. I'd guess that 
>>> [[expect_noreturn]] calls are typically not very hot in the first place.
>> 
>> The cold attribute is already used for this kind of splitting/reordering. I 
>> don't yet see how expect_noreturn creates new opportunities for the 
>> optimizer.
> 
> Strictly speaking, cold attribute on a function means that it is rarely 
> called. It does not say anything about the code after the call being colder 
> than the code before the call (within the same BB), which makes splitting the 
> BB pointless.

That's true, but it's safe to assume that code which dominates the cold call 
(or is post-dominated by it) is at least as cold as the call.

> Anyway, I agree that the arguments [[expect_noreturn]] are not that strong 
> and perhaps don't make the bar for the addition of a new IR attribute.
>  Should we go back to the intrinsic idea?

Sgtm, I think that'd be the simplest solution (something like inserting 
llvm.asan.stack_unpoison() where needed).


Repository:
  rL LLVM

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

https://reviews.llvm.org/D56624



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

Re: r351579 - [mips] Add '-mrelax-pic-calls', '-mno-relax-pic-calls'

[Hans Wennborg via cfe-commits]

Merged to 8.0 in r352139.

On Fri, Jan 18, 2019 at 11:58 AM Vladimir Stefanovic via cfe-commits
 wrote:
>
> Author: vstefanovic
> Date: Fri Jan 18 11:54:51 2019
> New Revision: 351579
>
> URL: http://llvm.org/viewvc/llvm-project?rev=351579=rev
> Log:
> [mips] Add '-mrelax-pic-calls', '-mno-relax-pic-calls'
>
> These two options enable/disable emission of R_{MICRO}MIPS_JALR fixups along
> with PIC calls. The linker may then try to turn PIC calls into direct jumps.
> By default, these fixups do get emitted by the backend, use
> '-mno-relax-pic-calls' to omit them.
>
> Differential revision: https://reviews.llvm.org/D56878
>
> Modified:
> cfe/trunk/include/clang/Driver/Options.td
> cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> cfe/trunk/test/Driver/mips-features.c
>
> Modified: cfe/trunk/include/clang/Driver/Options.td
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=351579=351578=351579=diff
> ==
> --- cfe/trunk/include/clang/Driver/Options.td (original)
> +++ cfe/trunk/include/clang/Driver/Options.td Fri Jan 18 11:54:51 2019
> @@ -2418,6 +2418,14 @@ def modd_spreg : Flag<["-"], "modd-spreg
>  def mno_odd_spreg : Flag<["-"], "mno-odd-spreg">, 
> Group,
>HelpText<"Disable odd single-precision floating point registers">,
>Flags<[HelpHidden]>;
> +def mrelax_pic_calls : Flag<["-"], "mrelax-pic-calls">,
> +  Group,
> +  HelpText<"Try turning PIC calls (j{al}r{c} $25) into direct calls "
> +  "(MIPS only)">, Flags<[HelpHidden]>;
> +def mno_relax_pic_calls : Flag<["-"], "mno-relax-pic-calls">,
> +  Group,
> +  HelpText<"Do not try turning PIC calls (j{al}r{c} $25) into direct calls "
> +  "(MIPS only)">, Flags<[HelpHidden]>;
>  def mglibc : Flag<["-"], "mglibc">, Group, Flags<[HelpHidden]>;
>  def muclibc : Flag<["-"], "muclibc">, Group, 
> Flags<[HelpHidden]>;
>  def module_file_info : Flag<["-"], "module-file-info">, 
> Flags<[DriverOption,CC1Option]>, Group,
>
> Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=351579=351578=351579=diff
> ==
> --- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
> +++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Fri Jan 18 11:54:51 2019
> @@ -1716,6 +1716,14 @@ void Clang::AddMIPSTargetArgs(const ArgL
>  } else
>D.Diag(diag::warn_target_unsupported_compact_branches) << CPUName;
>}
> +
> +  if (Arg *A = Args.getLastArg(options::OPT_mrelax_pic_calls,
> +   options::OPT_mno_relax_pic_calls)) {
> +if (A->getOption().matches(options::OPT_mno_relax_pic_calls)) {
> +  CmdArgs.push_back("-mllvm");
> +  CmdArgs.push_back("-mips-jalr-reloc=0");
> +}
> +  }
>  }
>
>  void Clang::AddPPCTargetArgs(const ArgList ,
>
> Modified: cfe/trunk/test/Driver/mips-features.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/mips-features.c?rev=351579=351578=351579=diff
> ==
> --- cfe/trunk/test/Driver/mips-features.c (original)
> +++ cfe/trunk/test/Driver/mips-features.c Fri Jan 18 11:54:51 2019
> @@ -444,3 +444,15 @@
>  // RUN: -mginv -mno-ginv 2>&1 \
>  // RUN:   | FileCheck --check-prefix=CHECK-NO-GINV %s
>  // CHECK-NO-GINV: "-target-feature" "-ginv"
> +//
> +// -mrelax-pic-calls
> +// RUN: %clang -target mips-unknown-linux-gnu -### -c %s \
> +// RUN: -mno-relax-pic-calls -mrelax-pic-calls 2>&1 \
> +// RUN:   | FileCheck --check-prefix=CHECK-RELAX-PIC-CALLS %s
> +// CHECK-RELAX-PIC-CALLS-NOT: "-mllvm" "-mips-jalr-reloc=0"
> +//
> +// -mno-relax-pic-calls
> +// RUN: %clang -target mips-unknown-linux-gnu -### -c %s \
> +// RUN: -mrelax-pic-calls -mno-relax-pic-calls 2>&1 \
> +// RUN:   | FileCheck --check-prefix=CHECK-NO-RELAX-PIC-CALLS %s
> +// CHECK-NO-RELAX-PIC-CALLS: "-mllvm" "-mips-jalr-reloc=0"
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D57064: [Sema] Improve a -Warray-bounds diagnostic

[Erik Pilkington via Phabricator via cfe-commits]

erik.pilkington marked an inline comment as done.
erik.pilkington added inline comments.



Comment at: clang/include/clang/AST/ASTContext.h:2092
+  Optional getTypeSizeInCharsIfKnown(QualType Ty) const {
+if (Ty->isIncompleteType() || Ty->isDependentType())
+  return None;

aaron.ballman wrote:
> Can you add a dependent type test as well?
I don't think its possible to get a dependent type here, since this feature is 
only supported in C mode.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57064



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

Re: r352102 - Add a triple to this test so it passes for targets where alignof(double)

[Hans Wennborg via cfe-commits]

Merged to 8.0 in r352132.

On Thu, Jan 24, 2019 at 12:52 PM Richard Smith via cfe-commits
 wrote:
>
> Author: rsmith
> Date: Thu Jan 24 12:52:56 2019
> New Revision: 352102
>
> URL: http://llvm.org/viewvc/llvm-project?rev=352102=rev
> Log:
> Add a triple to this test so it passes for targets where alignof(double)
> really should be equal to alignof(float).
>
> Modified:
> cfe/trunk/test/CXX/dcl.dcl/dcl.attr/dcl.align/p8.cpp
>
> Modified: cfe/trunk/test/CXX/dcl.dcl/dcl.attr/dcl.align/p8.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CXX/dcl.dcl/dcl.attr/dcl.align/p8.cpp?rev=352102=352101=352102=diff
> ==
> --- cfe/trunk/test/CXX/dcl.dcl/dcl.attr/dcl.align/p8.cpp (original)
> +++ cfe/trunk/test/CXX/dcl.dcl/dcl.attr/dcl.align/p8.cpp Thu Jan 24 12:52:56 
> 2019
> @@ -1,4 +1,4 @@
> -// RUN: %clang_cc1 -std=c++11 -verify %s
> +// RUN: %clang_cc1 -std=c++11 -verify %s -triple x86_64-linux-gnu
>
>  alignas(double) void f(); // expected-error {{'alignas' attribute only 
> applies to variables, data members and tag types}}
>  alignas(double) unsigned char c[sizeof(double)]; // expected-note 
> {{previous}}
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D57188: Disable _Float16 for non ARM/SPIR Targets

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: docs/LanguageExtensions.rst:497
 defined by the C standards committee, so using ``_Float16`` will not prevent
-code from being ported to architectures other than Arm.  Also, ``_Float16``
-arithmetic and operations will directly map on half-precision instructions when
-they are available (e.g. Armv8.2-A), avoiding conversions to/from
-single-precision, and thus will result in more performant code. If
-half-precision instructions are unavailable, values will be promoted to
+code from being ported to architectures other than Arm, though ``_Float16`` is
+currently disabled on most platforms until support is added to their published

This entire documentation section really just needs to be reworked.  Here's a 
starting point:

  Clang supports two half-precision (16-bit) floating point types: ``__fp16`` 
and
  ``_Float16``.  These types are supported in all language modes.

  ``__fp16`` is supported on every target, as it is purely a storage format; 
see below.
  ``_Float16`` is currently only supported on the following targets:
  - 32-bit ARM
  - 64-bit ARM (AArch64)
  - SPIR
  ``_Float16`` will be supported on more targets as they define ABIs for them.

  ``__fp16`` is a storage and interchange format only.  This means that values 
of
  ``__fp16`` are immediately promoted to (at least) ``float`` when used in 
arithmetic
  operations, so that e.g. the result of adding two ``__fp16`` values has type 
``float``.
  The behavior of ``__fp16`` is specified by the ARM C Language Extensions 
(`ACLE 
`_).
  Clang uses the ``binary16`` format from IEEE 754-2008 for ``__fp16``, not the 
ARM
  alternative format.

  ``_Float16`` is an extended floating-point type.  This means that, just like 
arithmetic on
  ``float`` or ``double``, arithmetic on ``_Float16`` operands is formally 
performed in the
  ``_Float16`` type, so that e.g. the result of adding two ``_Float16`` values 
has type
  ``_Float16``.  The behavior of ``_Float16`` is specified by ISO/IEC TS 
18661-3:2015
  ("Floating-point extensions for C").  As with ``__fp16``, Clang uses the 
``binary16``
  format from IEEE 754-2008 for ``_Float16``.

  ``_Float16`` arithmetic will be performed using native half-precision support
  when available on the target (e.g. on ARMv8.2a); otherwise it will be 
performed
  at a higher precision (currently always ``float``) and then truncated down to
  ``_Float16``.  Note that C and C++ allow intermediate floating-point operands
  of an expression to be computed with greater precision than is expressible in
  their type, so Clang may avoid intermediate truncations in certain cases; 
this may
  lead to results that are inconsistent with native arithmetic.

  It is recommended that portable code use ``_Float16`` instead of ``__fp16``,
  as it has been defined by the C standards committee and has behavior that is
  more familiar to most programmers.

  Because ``__fp16`` operands are always immediately promoted to ``float``, the
  common real type of ``__fp16`` and ``_Float16`` for the purposes of the usual
  arithmetic conversions is ``float``.

  A literal can be given ``_Float16`` type using the suffix ``f16``; for 
example:
  ```
3.14f16
  ```

  Because default argument promotion only applies to the standard floating-point
  types, ``_Float16`` values are not promoted to ``double`` when passed as 
variadic
  or untyped arguments.  As a consequence, some caution must be taken when using
  certain library facilities with ``_Float16``; for example, there is no 
``printf`` format
  specifier for ``_Float16``, and (unlike ``float``) it will not be implicitly 
promoted to
  ``double`` when passed to ``printf``, so the programmer must explicitly cast 
it to
  ``double`` before using it with an ``%f`` or similar specifier.



Comment at: lib/Basic/Targets/AArch64.cpp:52
   HasLegalHalfType = true;
+  HasFloat16= true;
 

spacing



Comment at: lib/Basic/Targets/SPIR.h:50
 HasLegalHalfType = true;
+HasFloat16= true;
 // Define available target features

spacing


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

https://reviews.llvm.org/D57188



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

[PATCH] D57104: [AST] Pack GenericSelectionExpr

[Bruno Ricci via Phabricator via cfe-commits]

riccibruno added a comment.

In D57104#1370275 , @steveire wrote:

> In D57104#1370081 , @riccibruno 
> wrote:
>
> > > I highly recommend this 9 minute video if this is new to you or you 
> > > haven't seen it before: https://youtu.be/qpdYRPL3SVE?t=103
> >
> > I would like to add an additional meta-comment here, but please don't take 
> > this in a bad way. I am wondering
> >  about the usefulness and the productivity of the "if this is new to you" 
> > in what I am assuming is a discussion
> >  between professionals. I will be happy to address any further technical 
> > comments regarding the code itself.
>
>
> Sorry for that. It's a confusing conversation and text doesn't help! :)


I totally agree with that.

> Other classes have `::Create` methods and if it's a justification you're 
> looking for precedent could be it :).
> 
> My proposal is a patch which only does one thing (Pack GenericSelectionExpr) 
> and a commit message that corresponds to that one thing. I'm not proposing 
> 'doing half a thing' in a commit like just inheriting from 
> `llvm::TrailingObjects`.
> 
> Your preference is a patch that packs GenericSelectionExpr and does something 
> else.

I don't think that this is accurate. This patch does one thing: pack 
`GenericSelectionExpr`. It does this by doing two logically distinct things:
1.) move some data to the bit-fields of `Stmt` and 2) tail-allocate the array 
of `Stmt *` and the array of `TypeSourceInfo`.

The addition of the `Create` function is part of 2) and not something distinct.

> I don't see how a person in the future would find the former more confusing 
> than the latter. Someone in the future won't care that at the end of January 
> 2019 the thing didn't already have a `::Create` method. There is future-value 
> reducing noise in commits. I know that's fuzzy and there isn't agreement on 
> the specifics, but maybe you agree with the principle. I know many people 
> don't agree with that principle, and many more people never use something 
> like gitk/git log and don't see the value in granular commits (hence why 
> someone went and gave a talk at a conference about it :)).

I agree with you that granular commits (with good and accurate commit 
messages!) doing one thing are important.
I am (and I think that everyone is) a fan of (git log/blame/etc). It is indeed 
frustrating to do some git archaeology
and end up to a commit with no explanation.

I believe however that our disagreement here is not on whether we should have 
good commit messages (duh, of course we should),
nor on whether we should have granular commits (duh, of course we should too), 
but on whether this is a granular change.

I am arguing that it is and it seems that you are arguing that this is not the 
case.

> So, I've given that feedback and you have your LGTM. In my book, the rest is 
> up to you! :)

Consensus is important and I can totally miss things so I don't want to just 
ignore you and push ahead.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57104



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

[PATCH] D56581: [ASTImporter] Set the described template if not set

[Shafik Yaghmour via Phabricator via cfe-commits]

shafik added a comment.

@martong Unfortunately this causes a regression on one of the lldb tests 
`TestDataFormatterLibcxxVector.py` e.g.

  lldb-dotest -p TestDataFormatterLibcxxVector.py -t -G gmodules 
--no-multiprocess 

So this is specific to modules. If you can't reproduce this I can provide a 
back-trace.


Repository:
  rC Clang

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

https://reviews.llvm.org/D56581



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

[PATCH] D56226: [clang-format] square parens that are followed by '=' are not Objective-C message sends

[Alex Lorenz via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rC352125: [clang-format] square parens with one token are not 
Objective-C message sends (authored by arphaman, committed by ).

Repository:
  rC Clang

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

https://reviews.llvm.org/D56226

Files:
  lib/Format/TokenAnnotator.cpp
  unittests/Format/FormatTestObjC.cpp


Index: lib/Format/TokenAnnotator.cpp
===
--- lib/Format/TokenAnnotator.cpp
+++ lib/Format/TokenAnnotator.cpp
@@ -494,9 +494,14 @@
   if (CurrentToken->is(tok::r_square)) {
 if (IsCpp11AttributeSpecifier)
   CurrentToken->Type = TT_AttributeSquare;
-else if (CurrentToken->Next && CurrentToken->Next->is(tok::l_paren) &&
+else if (((CurrentToken->Next &&
+   CurrentToken->Next->is(tok::l_paren)) ||
+  (CurrentToken->Previous &&
+   CurrentToken->Previous->Previous == Left)) &&
  Left->is(TT_ObjCMethodExpr)) {
-  // An ObjC method call is rarely followed by an open parenthesis.
+  // An ObjC method call is rarely followed by an open parenthesis. It
+  // also can't be composed of just one token, unless it's a macro that
+  // will be expanded to more tokens.
   // FIXME: Do we incorrectly label ":" with this?
   StartsObjCMethodExpr = false;
   Left->Type = TT_Unknown;
Index: unittests/Format/FormatTestObjC.cpp
===
--- unittests/Format/FormatTestObjC.cpp
+++ unittests/Format/FormatTestObjC.cpp
@@ -165,6 +165,20 @@
   EXPECT_EQ(FormatStyle::LK_ObjC, Style->Language);
 }
 
+TEST(FormatTestObjCStyle, AvoidDetectingDesignatedInitializersAsObjCInHeaders) 
{
+  auto Style = getStyle("LLVM", "a.h", "none",
+"static const char *names[] = {[0] = \"foo\",\n"
+"[kBar] = \"bar\"};");
+  ASSERT_TRUE((bool)Style);
+  EXPECT_EQ(FormatStyle::LK_Cpp, Style->Language);
+
+  Style = getStyle("LLVM", "a.h", "none",
+   "static const char *names[] = {[0] EQ \"foo\",\n"
+   "[kBar] EQ \"bar\"};");
+  ASSERT_TRUE((bool)Style);
+  EXPECT_EQ(FormatStyle::LK_Cpp, Style->Language);
+}
+
 TEST_F(FormatTestObjC, FormatObjCTryCatch) {
   verifyFormat("@try {\n"
"  f();\n"


Index: lib/Format/TokenAnnotator.cpp
===
--- lib/Format/TokenAnnotator.cpp
+++ lib/Format/TokenAnnotator.cpp
@@ -494,9 +494,14 @@
   if (CurrentToken->is(tok::r_square)) {
 if (IsCpp11AttributeSpecifier)
   CurrentToken->Type = TT_AttributeSquare;
-else if (CurrentToken->Next && CurrentToken->Next->is(tok::l_paren) &&
+else if (((CurrentToken->Next &&
+   CurrentToken->Next->is(tok::l_paren)) ||
+  (CurrentToken->Previous &&
+   CurrentToken->Previous->Previous == Left)) &&
  Left->is(TT_ObjCMethodExpr)) {
-  // An ObjC method call is rarely followed by an open parenthesis.
+  // An ObjC method call is rarely followed by an open parenthesis. It
+  // also can't be composed of just one token, unless it's a macro that
+  // will be expanded to more tokens.
   // FIXME: Do we incorrectly label ":" with this?
   StartsObjCMethodExpr = false;
   Left->Type = TT_Unknown;
Index: unittests/Format/FormatTestObjC.cpp
===
--- unittests/Format/FormatTestObjC.cpp
+++ unittests/Format/FormatTestObjC.cpp
@@ -165,6 +165,20 @@
   EXPECT_EQ(FormatStyle::LK_ObjC, Style->Language);
 }
 
+TEST(FormatTestObjCStyle, AvoidDetectingDesignatedInitializersAsObjCInHeaders) {
+  auto Style = getStyle("LLVM", "a.h", "none",
+"static const char *names[] = {[0] = \"foo\",\n"
+"[kBar] = \"bar\"};");
+  ASSERT_TRUE((bool)Style);
+  EXPECT_EQ(FormatStyle::LK_Cpp, Style->Language);
+
+  Style = getStyle("LLVM", "a.h", "none",
+   "static const char *names[] = {[0] EQ \"foo\",\n"
+   "[kBar] EQ \"bar\"};");
+  ASSERT_TRUE((bool)Style);
+  EXPECT_EQ(FormatStyle::LK_Cpp, Style->Language);
+}
+
 TEST_F(FormatTestObjC, FormatObjCTryCatch) {
   verifyFormat("@try {\n"
"  f();\n"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r352125 - [clang-format] square parens with one token are not Objective-C message sends

[Alex Lorenz via cfe-commits]

Author: arphaman
Date: Thu Jan 24 15:07:58 2019
New Revision: 352125

URL: http://llvm.org/viewvc/llvm-project?rev=352125=rev
Log:
[clang-format] square parens with one token are not Objective-C message sends

The commit r322690 introduced support for ObjC detection in header files.
Unfortunately some C headers that use designated initializers are now
incorrectly detected as Objective-C.
This commit fixes it by ensuring that `[ token ]` is not annotated as an
Objective-C message send.

rdar://45504376

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

Modified:
cfe/trunk/lib/Format/TokenAnnotator.cpp
cfe/trunk/unittests/Format/FormatTestObjC.cpp

Modified: cfe/trunk/lib/Format/TokenAnnotator.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/TokenAnnotator.cpp?rev=352125=352124=352125=diff
==
--- cfe/trunk/lib/Format/TokenAnnotator.cpp (original)
+++ cfe/trunk/lib/Format/TokenAnnotator.cpp Thu Jan 24 15:07:58 2019
@@ -494,9 +494,14 @@ private:
   if (CurrentToken->is(tok::r_square)) {
 if (IsCpp11AttributeSpecifier)
   CurrentToken->Type = TT_AttributeSquare;
-else if (CurrentToken->Next && CurrentToken->Next->is(tok::l_paren) &&
+else if (((CurrentToken->Next &&
+   CurrentToken->Next->is(tok::l_paren)) ||
+  (CurrentToken->Previous &&
+   CurrentToken->Previous->Previous == Left)) &&
  Left->is(TT_ObjCMethodExpr)) {
-  // An ObjC method call is rarely followed by an open parenthesis.
+  // An ObjC method call is rarely followed by an open parenthesis. It
+  // also can't be composed of just one token, unless it's a macro that
+  // will be expanded to more tokens.
   // FIXME: Do we incorrectly label ":" with this?
   StartsObjCMethodExpr = false;
   Left->Type = TT_Unknown;

Modified: cfe/trunk/unittests/Format/FormatTestObjC.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTestObjC.cpp?rev=352125=352124=352125=diff
==
--- cfe/trunk/unittests/Format/FormatTestObjC.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTestObjC.cpp Thu Jan 24 15:07:58 2019
@@ -165,6 +165,20 @@ TEST(FormatTestObjCStyle, DetectsObjCInH
   EXPECT_EQ(FormatStyle::LK_ObjC, Style->Language);
 }
 
+TEST(FormatTestObjCStyle, AvoidDetectingDesignatedInitializersAsObjCInHeaders) 
{
+  auto Style = getStyle("LLVM", "a.h", "none",
+"static const char *names[] = {[0] = \"foo\",\n"
+"[kBar] = \"bar\"};");
+  ASSERT_TRUE((bool)Style);
+  EXPECT_EQ(FormatStyle::LK_Cpp, Style->Language);
+
+  Style = getStyle("LLVM", "a.h", "none",
+   "static const char *names[] = {[0] EQ \"foo\",\n"
+   "[kBar] EQ \"bar\"};");
+  ASSERT_TRUE((bool)Style);
+  EXPECT_EQ(FormatStyle::LK_Cpp, Style->Language);
+}
+
 TEST_F(FormatTestObjC, FormatObjCTryCatch) {
   verifyFormat("@try {\n"
"  f();\n"


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

[PATCH] D56624: [Sanitizers] UBSan unreachable incompatible with ASan in the presence of `noreturn` calls

[Evgenii Stepanov via Phabricator via cfe-commits]

eugenis added a comment.

> Wouldn’t it be preferable to unpoison the stack inside of maybe_longjmp, once 
> the opaque condition can be checked?

Sure, but that's not always possible. That's why we have interceptors.

>> One possible optimization that I can think of is splitting code after the 
>> call into a separate basic block and marking it as cold.
>>  Admittedly, that's unlikely to have big impact in practice. I'd guess that 
>> [[expect_noreturn]] calls are typically not very hot in the first place.
> 
> The cold attribute is already used for this kind of splitting/reordering. I 
> don't yet see how expect_noreturn creates new opportunities for the optimizer.

Strictly speaking, cold attribute on a function means that it is rarely called. 
It does not say anything about the code after the call being colder than the 
code before the call (within the same BB), which makes splitting the BB 
pointless.

Anyway, I agree that the arguments [[expect_noreturn]] are not that strong and 
perhaps don't make the bar for the addition of a new IR attribute.
Should we go back to the intrinsic idea?


Repository:
  rL LLVM

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

https://reviews.llvm.org/D56624



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

[PATCH] D57104: [AST] Pack GenericSelectionExpr

[Stephen Kelly via Phabricator via cfe-commits]

steveire added a comment.

In D57104#1370081 , @riccibruno wrote:

> > I highly recommend this 9 minute video if this is new to you or you haven't 
> > seen it before: https://youtu.be/qpdYRPL3SVE?t=103
>
> I would like to add an additional meta-comment here, but please don't take 
> this in a bad way. I am wondering
>  about the usefulness and the productivity of the "if this is new to you" in 
> what I am assuming is a discussion
>  between professionals. I will be happy to address any further technical 
> comments regarding the code itself.


Sorry for that. It's a confusing conversation and text doesn't help! :)

Other classes have `::Create` methods and if it's a justification you're 
looking for precedent could be it :).

My proposal is a patch which only does one thing (Pack GenericSelectionExpr) 
and a commit message that corresponds to that one thing. I'm not proposing 
'doing half a thing' in a commit like just inheriting from 
`llvm::TrailingObjects`.

Your preference is a patch that packs GenericSelectionExpr and does something 
else.

I don't see how a person in the future would find the former more confusing 
than the latter. Someone in the future won't care that at the end of January 
2019 the thing didn't already have a `::Create` method. There is future-value 
reducing noise in commits. I know that's fuzzy and there isn't agreement on the 
specifics, but maybe you agree with the principle. I know many people don't 
agree with that principle, and many more people never use something like 
gitk/git log and don't see the value in granular commits (hence why someone 
went and gave a talk at a conference about it :)).

So, I've given that feedback and you have your LGTM. In my book, the rest is up 
to you! :)


Repository:
  rC Clang

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

https://reviews.llvm.org/D57104



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

[PATCH] D56624: [Sanitizers] UBSan unreachable incompatible with ASan in the presence of `noreturn` calls

[Vedant Kumar via Phabricator via cfe-commits]

vsk added a comment.

In D56624#1370243 , @eugenis wrote:

> > Because "expect_noreturn" calls are allowed to return, the compiler must 
> > behave as they could. In particular, this means that unpoisoning the stack 
> > before expect_noreturn calls (given the current semantics) is premature.
>
> I don't think that's true. A hypothetical function
>
>   maybe_longjmp(jmp_buf env)
>
> that checks an opaque condition needs stack unpoisoning before the call, in 
> the absense of a better solution.


Wouldn’t it be preferable to unpoison the stack inside of maybe_longjmp, once 
the opaque condition can be checked? Even if not, a narrower sanitizer_noreturn 
attribute is still perfectly fine, here.

> One possible optimization that I can think of is splitting code after the 
> call into a separate basic block and marking it as cold.
>  Admittedly, that's unlikely to have big impact in practice. I'd guess that 
> [[expect_noreturn]] calls are typically not very hot in the first place.

The cold attribute is already used for this kind of splitting/reordering. I 
don't yet see how expect_noreturn creates new opportunities for the optimizer.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D56624



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

[PATCH] D57106: [AST] Introduce GenericSelectionExpr::Association

[David Blaikie via Phabricator via cfe-commits]

dblaikie added inline comments.



Comment at: include/clang/AST/Expr.h:5103
+using reference = AssociationTy;
+using pointer = AssociationTy;
+AssociationIteratorTy() = default;

aaron.ballman wrote:
> riccibruno wrote:
> > aaron.ballman wrote:
> > > Carrying over the conversation from D57098:
> > > 
> > > >> @aaron.ballman Cute, but I suspect this may come back to bite us at 
> > > >> some point. For instance, if someone thinks they're working with a 
> > > >> real pointer, they're likely to expect pointer arithmetic to work when 
> > > >> it won't (at least they'll get compile errors though).
> > > > @riccibruno Hmm, but pointer is just the return type of operator-> no ? 
> > > > Is it actually required to behave like a pointer ? The only requirement 
> > > > I can find is that It->x must be equivalent to (*It).x, which is true 
> > > > here.
> > > 
> > > I double-checked and you're right, this is not a requirement of the STL.
> > > 
> > > > Also looking at the requirements for forward iterators I think that 
> > > > this iterator should actually be downgraded to an input iterator, 
> > > > because of the requirement that reference = T&.
> > > 
> > > My concern is that with the less functional iterators, common algorithms 
> > > get more expensive. For instance, `std::distance()`, `std::advance()` 
> > > become more expensive without random access, and things like 
> > > `std::prev()` become impossible.
> > > 
> > > It seems like the view this needs to provide is a read-only access to the 
> > > `AssociationTy` objects (because we need to construct them on the fly), 
> > > but not the data contained within them. If the only thing you can get 
> > > back from the iterator is a const pointer/reference/value type, then we 
> > > could store a local "current association" object in the iterator and 
> > > return a pointer/reference to that. WDYT?
> > I am worried about lifetime issues with this approach. Returning a 
> > reference/pointer to an `Association` object stored in the iterator means 
> > that the reference/pointer will dangle as soon as the iterator goes out of 
> > scope. This is potentially surprising since the "container" (that is the 
> > `GenericSelectionExpr`) here will still be in scope. Returning a value is 
> > safer in this aspect.
> > 
> > I believe it should be possible to make the iterator a random access 
> > iterator, at least
> > if we are willing to ignore some requirements:
> > 
> > 1.) For forward iterators and up, we must have `reference = T&` or `const 
> > T&`.
> > 2.) For forward iterators and up, `It1 == It2` if and only if `*It1` and 
> > `*It2` are bound to the same object.
> > I am worried about lifetime issues with this approach. Returning a 
> > reference/pointer to an Association object stored in the iterator means 
> > that the reference/pointer will dangle as soon as the iterator goes out of 
> > scope. This is potentially surprising since the "container" (that is the 
> > GenericSelectionExpr) here will still be in scope. Returning a value is 
> > safer in this aspect.
> 
> That's valid.
> 
> > I believe it should be possible to make the iterator a random access 
> > iterator, at least if we are willing to ignore some requirements:
> >
> > 1.) For forward iterators and up, we must have reference = T& or const T&.
> > 2.) For forward iterators and up, It1 == It2 if and only if *It1 and *It2 
> > are bound to the same object.
> 
> Yes, but then passing these iterators to STL algorithms will have UB because 
> we claim to meet the requirements for random access iteration but don't 
> actually meet the requirements. I am not certain what problems might arise 
> from violating these requirements.
> 
> @dblaikie, @mclow.lists: do you have opinions on whether it's okay to not 
> meet these requirements or suggestions on what we could do differently with 
> the design?
My vote is usually "yeah, have a member inside the iterator you return a 
reference/pointer to" to meet the iterator requirements. Yes, it means if you 
keep a pointer/reference to it, that is invalidated when you increment the 
iterator. But that's well established in iterator semantics.

(might be shooting from the hip here/not fully understanding the 
nuances/tradeoffs in this case)



Comment at: include/clang/AST/Expr.h:5084
+  /// storage of Stmt * and TypeSourceInfo * in GenericSelectionExpr.
+  template  class AssociationIteratorTy {
+friend class GenericSelectionExpr;

Worth using any of the iterator helpers LLVM has? (iterator_facade or the like)


Repository:
  rC Clang

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

https://reviews.llvm.org/D57106



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

[PATCH] D56936: Fix handling of overriden methods during ASTImport

[Shafik Yaghmour via Phabricator via cfe-commits]

shafik updated this revision to Diff 183406.
shafik marked 3 inline comments as done.
shafik added a comment.

Changes based on comments

- Refactoring ImportFunctionDeclBody to return Error
- Refactoring test/Analysis/ctu-main.cpp based on Gabor's patch
- Removing merging of function body for later PR


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

https://reviews.llvm.org/D56936

Files:
  lib/AST/ASTImporter.cpp
  test/Analysis/Inputs/ctu-other.cpp
  test/Analysis/ctu-main.cpp
  unittests/AST/ASTImporterTest.cpp

Index: unittests/AST/ASTImporterTest.cpp
===
--- unittests/AST/ASTImporterTest.cpp
+++ unittests/AST/ASTImporterTest.cpp
@@ -2233,6 +2233,191 @@
 }).match(ToTU, functionDecl()));
 }
 
+TEST_P(ImportFunctions, ImportOverriddenMethodTwice) {
+  auto Code =
+  R"(
+  struct B { virtual void f(); };
+  struct D:B { void f(); };
+  )";
+  auto BFP =
+  cxxMethodDecl(hasName("f"), hasParent(cxxRecordDecl(hasName("B";
+  auto DFP =
+  cxxMethodDecl(hasName("f"), hasParent(cxxRecordDecl(hasName("D";
+
+  Decl *FromTU0 = getTuDecl(Code, Lang_CXX);
+  auto *DF = FirstDeclMatcher().match(FromTU0, DFP);
+  Import(DF, Lang_CXX);
+
+  Decl *FromTU1 = getTuDecl(Code, Lang_CXX, "input1.cc");
+  auto *BF = FirstDeclMatcher().match(FromTU1, BFP);
+  Import(BF, Lang_CXX);
+
+  auto *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
+
+  EXPECT_EQ(DeclCounter().match(ToTU, BFP), 1u);
+  EXPECT_EQ(DeclCounter().match(ToTU, DFP), 1u);
+}
+
+TEST_P(ImportFunctions, ImportOverriddenMethodTwiceDefinitionFirst) {
+  auto CodeWithoutDef =
+  R"(
+  struct B { virtual void f(); };
+  struct D:B { void f(); };
+  )";
+  auto CodeWithDef =
+  R"(
+struct B { virtual void f(){}; };
+struct D:B { void f(){}; };
+  )";
+  auto BFP =
+  cxxMethodDecl(hasName("f"), hasParent(cxxRecordDecl(hasName("B";
+  auto DFP =
+  cxxMethodDecl(hasName("f"), hasParent(cxxRecordDecl(hasName("D";
+  auto BFDefP = cxxMethodDecl(
+  hasName("f"), hasParent(cxxRecordDecl(hasName("B"))), isDefinition());
+  auto DFDefP = cxxMethodDecl(
+  hasName("f"), hasParent(cxxRecordDecl(hasName("D"))), isDefinition());
+  auto FDefAllP = cxxMethodDecl(hasName("f"), isDefinition());
+
+  {
+Decl *FromTU = getTuDecl(CodeWithDef, Lang_CXX, "input0.cc");
+auto *FromD = FirstDeclMatcher().match(FromTU, DFP);
+Import(FromD, Lang_CXX);
+  }
+  {
+Decl *FromTU = getTuDecl(CodeWithoutDef, Lang_CXX, "input1.cc");
+auto *FromB = FirstDeclMatcher().match(FromTU, BFP);
+Import(FromB, Lang_CXX);
+  }
+
+  auto *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
+
+  EXPECT_EQ(DeclCounter().match(ToTU, BFP), 1u);
+  EXPECT_EQ(DeclCounter().match(ToTU, DFP), 1u);
+  EXPECT_EQ(DeclCounter().match(ToTU, BFDefP), 1u);
+  EXPECT_EQ(DeclCounter().match(ToTU, DFDefP), 1u);
+  EXPECT_EQ(DeclCounter().match(ToTU, FDefAllP), 2u);
+}
+
+TEST_P(ImportFunctions, ImportOverriddenMethodTwiceOutOfClassDef) {
+  auto Code =
+  R"(
+  struct B { virtual void f(); };
+  struct D:B { void f(); };
+  void B::f(){};
+  )";
+
+  auto BFP =
+  cxxMethodDecl(hasName("f"), hasParent(cxxRecordDecl(hasName("B";
+  auto BFPIsDefP = cxxMethodDecl(
+  hasName("f"), hasParent(cxxRecordDecl(hasName("B"))), isDefinition());
+  auto DFP = cxxMethodDecl(hasName("f"), hasParent(cxxRecordDecl(hasName("D"))),
+   unless(isDefinition()));
+
+  Decl *FromTU0 = getTuDecl(Code, Lang_CXX);
+  auto *D = FirstDeclMatcher().match(FromTU0, DFP);
+  Import(D, Lang_CXX);
+
+  Decl *FromTU1 = getTuDecl(Code, Lang_CXX, "input1.cc");
+  auto *B = FirstDeclMatcher().match(FromTU1, BFP);
+  Import(B, Lang_CXX);
+
+  auto *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
+
+  EXPECT_EQ(DeclCounter().match(ToTU, BFP), 1u);
+  EXPECT_EQ(DeclCounter().match(ToTU, BFPIsDefP), 0u);
+
+  auto *ToB = FirstDeclMatcher().match(
+  ToTU, cxxRecordDecl(hasName("B")));
+  auto *ToBFInClass = FirstDeclMatcher().match(ToTU, BFP);
+  auto *ToBFOutOfClass = FirstDeclMatcher().match(
+  ToTU, cxxMethodDecl(hasName("f"), isDefinition()));
+
+  // The definition should be out-of-class.
+  EXPECT_NE(ToBFInClass, ToBFOutOfClass);
+  EXPECT_NE(ToBFInClass->getLexicalDeclContext(),
+ToBFOutOfClass->getLexicalDeclContext());
+  EXPECT_EQ(ToBFOutOfClass->getDeclContext(), ToB);
+  EXPECT_EQ(ToBFOutOfClass->getLexicalDeclContext(), ToTU);
+
+  // Check that the redecl chain is intact.
+  EXPECT_EQ(ToBFOutOfClass->getPreviousDecl(), ToBFInClass);
+}
+
+TEST_P(ImportFunctions,
+   ImportOverriddenMethodTwiceOutOfClassDefInSeparateCode) {
+  auto CodeTU0 =
+  R"(
+  struct B { virtual void f(); };
+  struct D:B { void f(); };
+  )";
+  auto CodeTU1 =
+  R"(
+  struct B { virtual void f(); };
+  struct D:B { void f(); };
+  void 

[PATCH] D56936: Fix handling of overriden methods during ASTImport

[Shafik Yaghmour via Phabricator via cfe-commits]

shafik added a comment.

@martong so I just tested your `lit-tests.patch` and it looks good!




Comment at: lib/AST/ASTImporter.cpp:2959
+}
+
 ExpectedDecl ASTNodeImporter::VisitFunctionDecl(FunctionDecl *D) {

balazske wrote:
> Code formatting is not OK in this function (and other places). (Indentation 
> and spaces around "(" ")".)
Apologies, I forgot to run clang-format


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

https://reviews.llvm.org/D56936



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

[PATCH] D56624: [Sanitizers] UBSan unreachable incompatible with ASan in the presence of `noreturn` calls

[Evgenii Stepanov via Phabricator via cfe-commits]

eugenis added a comment.

> Because "expect_noreturn" calls are allowed to return, the compiler must 
> behave as they could. In particular, this means that unpoisoning the stack 
> before expect_noreturn calls (given the current semantics) is premature.

I don't think that's true. A hypothetical function

  maybe_longjmp(jmp_buf env)

that checks an opaque condition needs stack unpoisoning before the call, in the 
absense of a better solution.

One possible optimization that I can think of is splitting code after the call 
into a separate basic block and marking it as cold.
Admittedly, that's unlikely to have big impact in practice. I'd guess that 
[[expect_noreturn]] calls are typically not very hot in the first place.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D56624



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

Re: [clang-tools-extra] r352040 - [CodeComplete] [clangd] Fix crash on ValueDecl with a null type

[Hans Wennborg via cfe-commits]

Merged in r352118 (cfe) and r352120 (clang-tools-extra). Please let me
know if there are any follow-ups.

Thanks,
Hans

On Thu, Jan 24, 2019 at 5:11 AM Ilya Biryukov  wrote:
>
> +Hans Wennborg, could you please merge this fix into the release branch?
>
> On Thu, Jan 24, 2019 at 1:41 PM Ilya Biryukov via cfe-commits 
>  wrote:
>>
>> Author: ibiryukov
>> Date: Thu Jan 24 02:41:43 2019
>> New Revision: 352040
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=352040=rev
>> Log:
>> [CodeComplete] [clangd] Fix crash on ValueDecl with a null type
>>
>> Reviewers: kadircet
>>
>> Reviewed By: kadircet
>>
>> Subscribers: ioeric, MaskRay, jkorous, arphaman, cfe-commits
>>
>> Differential Revision: https://reviews.llvm.org/D57093
>>
>> Modified:
>> clang-tools-extra/trunk/clangd/ExpectedTypes.cpp
>> clang-tools-extra/trunk/unittests/clangd/CodeCompleteTests.cpp
>>
>> Modified: clang-tools-extra/trunk/clangd/ExpectedTypes.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ExpectedTypes.cpp?rev=352040=352039=352040=diff
>> ==
>> --- clang-tools-extra/trunk/clangd/ExpectedTypes.cpp (original)
>> +++ clang-tools-extra/trunk/clangd/ExpectedTypes.cpp Thu Jan 24 02:41:43 2019
>> @@ -35,8 +35,10 @@ static llvm::Optional
>>  typeOfCompletion(const CodeCompletionResult ) {
>>auto *VD = dyn_cast_or_null(R.Declaration);
>>if (!VD)
>> -return None; // We handle only variables and functions below.
>> +return llvm::None; // We handle only variables and functions below.
>>auto T = VD->getType();
>> +  if (T.isNull())
>> +return llvm::None;
>>if (auto FuncT = T->getAs()) {
>>  // Functions are a special case. They are completed as 'foo()' and we 
>> want
>>  // to match their return type rather than the function type itself.
>>
>> Modified: clang-tools-extra/trunk/unittests/clangd/CodeCompleteTests.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/unittests/clangd/CodeCompleteTests.cpp?rev=352040=352039=352040=diff
>> ==
>> --- clang-tools-extra/trunk/unittests/clangd/CodeCompleteTests.cpp (original)
>> +++ clang-tools-extra/trunk/unittests/clangd/CodeCompleteTests.cpp Thu Jan 
>> 24 02:41:43 2019
>> @@ -2319,6 +2319,17 @@ TEST(CompletionTest, ObjectiveCMethodTwo
>>EXPECT_THAT(C, ElementsAre(SnippetSuffix("${1:(unsigned int)}")));
>>  }
>>
>> +TEST(CompletionTest, WorksWithNullType) {
>> +  auto R = completions(R"cpp(
>> +int main() {
>> +  for (auto [loopVar] : y ) { // y has to be unresolved.
>> +int z = loopV^;
>> +  }
>> +}
>> +  )cpp");
>> +  EXPECT_THAT(R.Completions, ElementsAre(Named("loopVar")));
>> +}
>> +
>>  } // namespace
>>  } // namespace clangd
>>  } // namespace clang
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
>
> --
> Regards,
> Ilya Biryukov
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56900: [Fixed Point Arithmetic] Fixed Point and Integer Conversions

[Leonard Chan via Phabricator via cfe-commits]

leonardchan added a comment.

Oh I forgot to submit the comments.




Comment at: clang/lib/AST/ExprConstant.cpp:9825
+if (Result.isSigned() && !DstSigned) {
+  Overflow = Result < 0 || Result.ugt(DstMax);
+} else if (Result.isUnsigned() && DstSigned) {

ebevhan wrote:
> leonardchan wrote:
> > ebevhan wrote:
> > > The `Result < 0` is more clearly expressed as `Result.isNegative()` I 
> > > think.
> > Ah, so I ran into something similar with the patch preceding this in 
> > `APFixedPoint::convert()`. `isNegative()` is a method of `APInt` which 
> > doesn't care about signage. It just checks if the last bit is set. `Result 
> > < 0` calls `APSInt::operator<()` which cares about the sign and checks if 
> > this signed int is less than zero. 
> > 
> >  have no big problem with this, but if `Result.isNegative()` is more 
> > readable, I could also add `Result.isSigned()` which together effectively 
> > does the same thing as `Result < 0`.
> This makes sense, but you're already checking if the value is signed in the 
> line above, so it shouldn't be an issue.
Ah, forgot about that.



Comment at: clang/test/Frontend/fixed_point_conversions.c:426
+  _Sat short _Accum sat_sa;
+  _Sat unsigned short _Accum sat_usa;
+

ebevhan wrote:
> There are no tests here for what you get if you convert an integer to a 
> fixed-point type with a larger integral part than the integer has.
Added to the end of `TestIntToFixedPoint`



Comment at: clang/test/Frontend/fixed_point_conversions.c:437
+  // DEFAULT-NEXT: [[RES:%[a-z0-9]+]] = trunc i39 [[SATMIN]] to i16
+  // DEFAULT-NEXT: store i16 [[RES]], i16* %sat_sa, align 2
+

ebevhan wrote:
> Conversions like this are a bit odd. There shouldn't be a need to 
> upsize/upscale the container before the saturation, should there?
I see. You're saying that we can just check directly if the value exceeds 255 
(or goes under -256) since the range of target values can always fit in the 
range of source values. Therefore we do not need to cast up since the only 
reason we would need to is if converting to a type with a greater source range.

In this case, we could technically have a special case for integers where I 
think we can perform the saturation checks without the initial sign extension. 
I think it might be simpler though if in `EmitFixedPointConversion`, we treat 
an integer as a 'zero-scale fixed point number'. I think the reason the 
upsizing occurs in the first place is so that we satisfy the first FX 
conversion rule of calculating the result with full precision of both operands.


Repository:
  rC Clang

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

https://reviews.llvm.org/D56900



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

[PATCH] D57189: Fix compatibility with the msvc AI compiler option

[Reid Kleckner via Phabricator via cfe-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rL352119: [clang-cl] Ignore space-separated /AI arguments 
(authored by rnk, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D57189?vs=183398=183402#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D57189

Files:
  cfe/trunk/include/clang/Driver/CLCompatOptions.td
  cfe/trunk/test/Driver/cl-options.c


Index: cfe/trunk/include/clang/Driver/CLCompatOptions.td
===
--- cfe/trunk/include/clang/Driver/CLCompatOptions.td
+++ cfe/trunk/include/clang/Driver/CLCompatOptions.td
@@ -394,7 +394,7 @@
 
 // Unsupported:
 
-def _SLASH_AI : CLJoined<"AI">;
+def _SLASH_AI : CLJoinedOrSeparate<"AI">;
 def _SLASH_Bt : CLFlag<"Bt">;
 def _SLASH_Bt_plus : CLFlag<"Bt+">;
 def _SLASH_clr : CLJoined<"clr">;
Index: cfe/trunk/test/Driver/cl-options.c
===
--- cfe/trunk/test/Driver/cl-options.c
+++ cfe/trunk/test/Driver/cl-options.c
@@ -387,6 +387,7 @@
 // (/Zs is for syntax-only)
 // RUN: %clang_cl /Zs \
 // RUN: /AIfoo \
+// RUN: /AI foo_does_not_exist \
 // RUN: /Bt \
 // RUN: /Bt+ \
 // RUN: /clr:pure \


Index: cfe/trunk/include/clang/Driver/CLCompatOptions.td
===
--- cfe/trunk/include/clang/Driver/CLCompatOptions.td
+++ cfe/trunk/include/clang/Driver/CLCompatOptions.td
@@ -394,7 +394,7 @@
 
 // Unsupported:
 
-def _SLASH_AI : CLJoined<"AI">;
+def _SLASH_AI : CLJoinedOrSeparate<"AI">;
 def _SLASH_Bt : CLFlag<"Bt">;
 def _SLASH_Bt_plus : CLFlag<"Bt+">;
 def _SLASH_clr : CLJoined<"clr">;
Index: cfe/trunk/test/Driver/cl-options.c
===
--- cfe/trunk/test/Driver/cl-options.c
+++ cfe/trunk/test/Driver/cl-options.c
@@ -387,6 +387,7 @@
 // (/Zs is for syntax-only)
 // RUN: %clang_cl /Zs \
 // RUN: /AIfoo \
+// RUN: /AI foo_does_not_exist \
 // RUN: /Bt \
 // RUN: /Bt+ \
 // RUN: /clr:pure \
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r352119 - [clang-cl] Ignore space-separated /AI arguments

[Reid Kleckner via cfe-commits]

Author: rnk
Date: Thu Jan 24 14:26:51 2019
New Revision: 352119

URL: http://llvm.org/viewvc/llvm-project?rev=352119=rev
Log:
[clang-cl] Ignore space-separated /AI arguments

The /AI flag is for #using directives, which I don't think we support.
This is consistent with how the /I flag is handled by MSVC.  Add a test
for it.

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

Modified:
cfe/trunk/include/clang/Driver/CLCompatOptions.td
cfe/trunk/test/Driver/cl-options.c

Modified: cfe/trunk/include/clang/Driver/CLCompatOptions.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CLCompatOptions.td?rev=352119=352118=352119=diff
==
--- cfe/trunk/include/clang/Driver/CLCompatOptions.td (original)
+++ cfe/trunk/include/clang/Driver/CLCompatOptions.td Thu Jan 24 14:26:51 2019
@@ -394,7 +394,7 @@ def _SLASH_Zo_ : CLIgnoredFlag<"Zo-">;
 
 // Unsupported:
 
-def _SLASH_AI : CLJoined<"AI">;
+def _SLASH_AI : CLJoinedOrSeparate<"AI">;
 def _SLASH_Bt : CLFlag<"Bt">;
 def _SLASH_Bt_plus : CLFlag<"Bt+">;
 def _SLASH_clr : CLJoined<"clr">;

Modified: cfe/trunk/test/Driver/cl-options.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/cl-options.c?rev=352119=352118=352119=diff
==
--- cfe/trunk/test/Driver/cl-options.c (original)
+++ cfe/trunk/test/Driver/cl-options.c Thu Jan 24 14:26:51 2019
@@ -387,6 +387,7 @@
 // (/Zs is for syntax-only)
 // RUN: %clang_cl /Zs \
 // RUN: /AIfoo \
+// RUN: /AI foo_does_not_exist \
 // RUN: /Bt \
 // RUN: /Bt+ \
 // RUN: /clr:pure \


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

[PATCH] D57189: Fix compatibility with the msvc AI compiler option

[Reid Kleckner via Phabricator via cfe-commits]

rnk updated this revision to Diff 183398.
rnk added a comment.

- add test


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

https://reviews.llvm.org/D57189

Files:
  clang/include/clang/Driver/CLCompatOptions.td
  clang/test/Driver/cl-options.c


Index: clang/test/Driver/cl-options.c
===
--- clang/test/Driver/cl-options.c
+++ clang/test/Driver/cl-options.c
@@ -387,6 +387,7 @@
 // (/Zs is for syntax-only)
 // RUN: %clang_cl /Zs \
 // RUN: /AIfoo \
+// RUN: /AI foo_does_not_exist \
 // RUN: /Bt \
 // RUN: /Bt+ \
 // RUN: /clr:pure \
Index: clang/include/clang/Driver/CLCompatOptions.td
===
--- clang/include/clang/Driver/CLCompatOptions.td
+++ clang/include/clang/Driver/CLCompatOptions.td
@@ -394,7 +394,7 @@
 
 // Unsupported:
 
-def _SLASH_AI : CLJoined<"AI">;
+def _SLASH_AI : CLJoinedOrSeparate<"AI">;
 def _SLASH_Bt : CLFlag<"Bt">;
 def _SLASH_Bt_plus : CLFlag<"Bt+">;
 def _SLASH_clr : CLJoined<"clr">;


Index: clang/test/Driver/cl-options.c
===
--- clang/test/Driver/cl-options.c
+++ clang/test/Driver/cl-options.c
@@ -387,6 +387,7 @@
 // (/Zs is for syntax-only)
 // RUN: %clang_cl /Zs \
 // RUN: /AIfoo \
+// RUN: /AI foo_does_not_exist \
 // RUN: /Bt \
 // RUN: /Bt+ \
 // RUN: /clr:pure \
Index: clang/include/clang/Driver/CLCompatOptions.td
===
--- clang/include/clang/Driver/CLCompatOptions.td
+++ clang/include/clang/Driver/CLCompatOptions.td
@@ -394,7 +394,7 @@
 
 // Unsupported:
 
-def _SLASH_AI : CLJoined<"AI">;
+def _SLASH_AI : CLJoinedOrSeparate<"AI">;
 def _SLASH_Bt : CLFlag<"Bt">;
 def _SLASH_Bt_plus : CLFlag<"Bt+">;
 def _SLASH_clr : CLJoined<"clr">;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D57189: Fix compatibility with the msvc AI compiler option

[Reid Kleckner via Phabricator via cfe-commits]

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

lgtm, I'll go ahead and commit this soon.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57189



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

[PATCH] D56326: [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive

[Lingda Li via Phabricator via cfe-commits]

lildmh added inline comments.



Comment at: lib/AST/DeclOpenMP.cpp:164
+  if (NumClauses) {
+Clauses = (OMPClause **)C.Allocate(sizeof(OMPClause *) * NumClauses);
+setClauses(CL);

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > lildmh wrote:
> > > > > > ABataev wrote:
> > > > > > > lildmh wrote:
> > > > > > > > ABataev wrote:
> > > > > > > > > No, bad idea. Use tail allocation for the clauses. Check the 
> > > > > > > > > implementation of `OMPRequiresDecl`
> > > > > > > > I think it is possible to use TrailingObjects for clause 
> > > > > > > > storage when the number of clauses are known before creating 
> > > > > > > > the directive (e.g., for OMPRequiresDecl and 
> > > > > > > > OMPExecutableDirective). 
> > > > > > > > 
> > > > > > > > The reason that I had to create OMPDeclareMapperDecl before 
> > > > > > > > parsing map clauses, is the mapper variable (AA in the example 
> > > > > > > > below) needs to be declared within OMPDeclareMapperDecl, 
> > > > > > > > because the following map clauses will use it.
> > > > > > > > 
> > > > > > > > ```
> > > > > > > > #pragma omp declare mapper(struct S AA) map(AA.field1)
> > > > > > > > ```
> > > > > > > > 
> > > > > > > > A possible way to get around this is to count the number of map 
> > > > > > > > clauses before hand. But this solution is not trivial since the 
> > > > > > > > normal method for parsing map clauses cannot be used (e.g., it 
> > > > > > > > does not know AA when parsing map(AA.field1)). A customized and 
> > > > > > > > complex (because it needs to handle all possible situations) 
> > > > > > > > parsing method needs to be created, just for counting clause 
> > > > > > > > number. I think it's not worthy to do this compared with 
> > > > > > > > allocating map clause space later.
> > > > > > > > 
> > > > > > > > I checked the code for OMPDeclareReductionDecl that you wrote. 
> > > > > > > > It also has to be created before parsing the combiner and 
> > > > > > > > initializer. It does not have a variable number of clauses 
> > > > > > > > though.
> > > > > > > > 
> > > > > > > > Any suggestions?
> > > > > > > Instead, you can introduce special DeclContext-based declaration 
> > > > > > > and keep the reference to this declaration inside of the 
> > > > > > > `OMPDeclareMapperDecl`.
> > > > > > Hi Alexey,
> > > > > > 
> > > > > > Thanks a lot for your quick response! I don't think I understand 
> > > > > > your idea. Can you establish more on that?
> > > > > > 
> > > > > > In my current implementation, OMPDeclareMapperDecl is used as the 
> > > > > > DeclConext of the variable AA in the above example, and it already 
> > > > > > includes the reference to AA's declaration.
> > > > > > 
> > > > > > My problem is, I need to create OMPDeclareMapperDecl before parsing 
> > > > > > map clauses. But before parsing map clauses, I don't know the 
> > > > > > number of clauses. Using TrailingObject requires to know how many 
> > > > > > clauses there are when creating OMPDeclareMapperDecl. So I couldn't 
> > > > > > use TrailingObject.
> > > > > > 
> > > > > > My current solution is to create OMPDeclareMapperDecl before 
> > > > > > parsing map clauses, and to create the clause storage after parsing 
> > > > > > finishes.
> > > > > What I meant, that you don't need to use `OMPDeclareMapperDecl` for 
> > > > > this, instead you can add another (very simple) special declaration 
> > > > > based on `DeclContext` to use it as the parent declaration for the 
> > > > > variable. In the `OMPDeclareMapperDecl` you can keep the reference to 
> > > > > this special declaration.
> > > > Thanks for your response! Please let me know if my understanding below 
> > > > is correct:
> > > > 
> > > > `OMPDeclareMapperDecl` no longer inherits from `DeclContext`. Instead, 
> > > > we create something like `OMPDeclareMapperDeclContext` which inherits 
> > > > from `DeclContext`, and `OMPDeclareMapperDecl` keeps a pointer that 
> > > > points to this `OMPDeclareMapperDeclContext`.  AA and map clauses are 
> > > > parsed within `OMPDeclareMapperDeclContext`.
> > > > 
> > > > This sounds a bit more complex, but if you believe it's better, I can 
> > > > change the code. Please share your thoughts.
> > > Yes, something like this.
> > Hi Alexey,
> > 
> > Sorry for the late response. I was working on something else last week.
> > 
> > When I tried to modify the code based on your suggestions, I found out that 
> > `DeclContext` is only meant to be used for a `Decl` (please see the 
> > comments before `class DeclContext {...}` in include/clang/AST/DeclBase.h).
> > 
> > It means, if I create a `OMPDeclareMapperDeclContext ` which is a 
> > `DeclContext ` but not a `Decl`, the code cannot work correctly. Therefore 
> > `OMPDeclareMapperDeclContext` must be a `Decl` itself. If I do it this way, 
> > a lot of useless information (all inherited from `Decl`) will exist within 
> > 

[PATCH] D53199: Fix the behavior of clang's -w flag.

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

rsmith accepted this revision.
rsmith marked an inline comment as done.
rsmith added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/lib/Basic/DiagnosticIDs.cpp:460-463
+  // Honor -w: this disables all messages mapped to Warning severity, and 
*also*
+  // any diagnostics which are not Error/Fatal by default (that is, they were
+  // upgraded by any of the mechanisms available: -Werror, -pedantic, or 
#pragma
+  // diagnostic)

I think this would be clearer if phrased the other way around:

> [...] disables all messages that are not Error/Fatal by default, and also any 
> diagnostics that are Error/Fatal by default but that have been downgraded to 
> Warning severity by any of the mechanisms available: -Wno-error or #pragma 
> diagnostic



Comment at: clang/lib/Basic/DiagnosticIDs.cpp:466
+if (Result == diag::Severity::Warning ||
+!isDefaultMappingAsError((diag::kind)DiagID))
+  return diag::Severity::Ignored;

I think this change will also cause `-w` to disable all remarks. Was that your 
intent?


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

https://reviews.llvm.org/D53199



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

[PATCH] D57189: Fix compatibility with the msvc AI compiler option

[Zachary Henkel via Phabricator via cfe-commits]

zahen created this revision.
zahen added reviewers: rnk, zturner.
Herald added a subscriber: cfe-commits.

The unsupported /AI option accepts directory paths in a manner similar to the 
supported /I option and allows spaces between the flag and the directory.  An 
example snippet from our production compile that broke on clang-cl.exe because 
it read the path as an input file.

  /AI %WindowsSdkDir%\References\%WindowsSDKVersion% /I 
%WindowsSdkDir%\Include\%WindowsSDKVersion%\winrt


Repository:
  rC Clang

https://reviews.llvm.org/D57189

Files:
  include/clang/Driver/CLCompatOptions.td


Index: include/clang/Driver/CLCompatOptions.td
===
--- include/clang/Driver/CLCompatOptions.td
+++ include/clang/Driver/CLCompatOptions.td
@@ -394,7 +394,7 @@
 
 // Unsupported:
 
-def _SLASH_AI : CLJoined<"AI">;
+def _SLASH_AI : CLJoinedOrSeparate<"AI">;
 def _SLASH_Bt : CLFlag<"Bt">;
 def _SLASH_Bt_plus : CLFlag<"Bt+">;
 def _SLASH_clr : CLJoined<"clr">;


Index: include/clang/Driver/CLCompatOptions.td
===
--- include/clang/Driver/CLCompatOptions.td
+++ include/clang/Driver/CLCompatOptions.td
@@ -394,7 +394,7 @@
 
 // Unsupported:
 
-def _SLASH_AI : CLJoined<"AI">;
+def _SLASH_AI : CLJoinedOrSeparate<"AI">;
 def _SLASH_Bt : CLFlag<"Bt">;
 def _SLASH_Bt_plus : CLFlag<"Bt+">;
 def _SLASH_clr : CLJoined<"clr">;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D57185: [clang-tidy] Add the abseil-duration-addition check

[Eugene Zelenko via Phabricator via cfe-commits]

Eugene.Zelenko added inline comments.



Comment at: docs/ReleaseNotes.rst:76
 
+- New :doc:`abseil-duration-addition
+  ` check.

Please use alphabetical order for new checks.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D57185



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

[PATCH] D57188: Disable _Float16 for non ARM/SPIR Targets

[Erich Keane via Phabricator via cfe-commits]

erichkeane created this revision.
erichkeane added reviewers: rjmccall, andrew.w.kaylor.
Herald added subscribers: kristof.beyls, javed.absar.

As Discussed here:
http://lists.llvm.org/pipermail/llvm-dev/2019-January/129543.html

There are problems exposing the _Float16 type on architectures that
haven't defined the ABI/ISel for the type yet, so we're temporarily
disabling the type and making it opt-in.


https://reviews.llvm.org/D57188

Files:
  docs/LanguageExtensions.rst
  include/clang/Basic/TargetInfo.h
  lib/Basic/TargetInfo.cpp
  lib/Basic/Targets/AArch64.cpp
  lib/Basic/Targets/ARM.cpp
  lib/Basic/Targets/SPIR.h
  lib/Sema/SemaType.cpp
  test/AST/float16.cpp
  test/CodeGenCXX/float16-declarations.cpp
  test/CodeGenCXX/mangle-ms.cpp
  test/Lexer/half-literal.cpp
  test/Sema/Float16.c

Index: test/Sema/Float16.c
===
--- /dev/null
+++ test/Sema/Float16.c
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+
+#ifdef HAVE
+// expected-no-diagnostics
+#else
+// expected-error@+2{{_Float16 is not supported on this target}}
+#endif // HAVE
+_Float16 f;
Index: test/Lexer/half-literal.cpp
===
--- test/Lexer/half-literal.cpp
+++ test/Lexer/half-literal.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -pedantic %s
+// RUN: %clang_cc1 -fsyntax-only -verify -pedantic -triple aarch64-linux-gnu %s
 float a = 1.0h; // expected-error{{no matching literal operator for call to 'operator""h' with argument of type 'long double' or 'const char *', and no matching literal operator template}}
 float b = 1.0H; // expected-error{{invalid suffix 'H' on floating constant}}
 
Index: test/CodeGenCXX/mangle-ms.cpp
===
--- test/CodeGenCXX/mangle-ms.cpp
+++ test/CodeGenCXX/mangle-ms.cpp
@@ -1,5 +1,6 @@
 // RUN: %clang_cc1 -fblocks -emit-llvm %s -o - -triple=i386-pc-win32 -std=c++98 | FileCheck %s
 // RUN: %clang_cc1 -fblocks -emit-llvm %s -o - -triple=x86_64-pc-win32 -std=c++98| FileCheck -check-prefix X64 %s
+// RUN: %clang_cc1 -fblocks -emit-llvm %s -o - -triple=aarch64-pc-win32 -std=c++98 -DARM | FileCheck -check-prefixes=X64,ARM %s
 
 int a;
 // CHECK-DAG: @"?a@@3HA"
@@ -466,10 +467,12 @@
 // CHECK-DAG: define dso_local void @"?f@Complex@@YAXU?$_Complex@H@__clang@@@Z"(
 void f(_Complex int) {}
 }
+#ifdef ARM
 namespace Float16 {
-// CHECK-DAG: define dso_local void @"?f@Float16@@YAXU_Float16@__clang@@@Z"(
+// ARM-DAG: define dso_local void @"?f@Float16@@YAXU_Float16@__clang@@@Z"(
 void f(_Float16) {}
 }
+#endif // ARM
 
 namespace PR26029 {
 template 
Index: test/CodeGenCXX/float16-declarations.cpp
===
--- test/CodeGenCXX/float16-declarations.cpp
+++ test/CodeGenCXX/float16-declarations.cpp
@@ -1,5 +1,4 @@
 // RUN: %clang -std=c++11 --target=aarch64-arm--eabi -S -emit-llvm %s -o - | FileCheck %s  --check-prefix=CHECK --check-prefix=CHECK-AARCH64
-// RUN: %clang -std=c++11 --target=x86_64 -S -emit-llvm %s -o - | FileCheck %s  --check-prefix=CHECK --check-prefix=CHECK-X86
 
 /*  Various contexts where type _Float16 can appear. */
 
@@ -15,7 +14,6 @@
 
   _Float16 arr1n[10];
 // CHECK-AARCH64-DAG: @_ZN12_GLOBAL__N_15arr1nE = internal global [10 x half] zeroinitializer, align 2
-// CHECK-X86-DAG: @_ZN12_GLOBAL__N_15arr1nE = internal global [10 x half] zeroinitializer, align 16
 
   _Float16 arr2n[] = { 1.2, 3.0, 3.e4 };
 // CHECK-DAG: @_ZN12_GLOBAL__N_15arr2nE = internal global [3 x half] [half 0xH3CCD, half 0xH4200, half 0xH7753], align 2
@@ -30,14 +28,12 @@
 
 _Float16 f1f;
 // CHECK-AARCH64-DAG: @f1f = dso_local global half 0xH, align 2
-// CHECK-X86-DAG: @f1f = dso_local global half 0xH, align 2
 
 _Float16 f2f = 32.4;
 // CHECK-DAG: @f2f = dso_local global half 0xH500D, align 2
 
 _Float16 arr1f[10];
 // CHECK-AARCH64-DAG: @arr1f = dso_local global [10 x half] zeroinitializer, align 2
-// CHECK-X86-DAG: @arr1f = dso_local global [10 x half] zeroinitializer, align 16
 
 _Float16 arr2f[] = { -1.2, -3.0, -3.e4 };
 // CHECK-DAG: @arr2f = dso_local global [3 x half] [half 0xHBCCD, half 0xHC200, half 0xHF753], align 2
@@ -137,8 +133,6 @@
   long double cvtld = f2n;
 //CHECK-AARCh64-DAG: [[H2LD:%[a-z0-9]+]] = fpext half {{%[0-9]+}} to fp128
 //CHECK-AARCh64-DAG: store fp128 [[H2LD]], fp128* %{{.*}}, align 16
-//CHECK-X86-DAG: [[H2LD:%[a-z0-9]+]] = fpext half {{%[0-9]+}} to x86_fp80
-//CHECK-X86-DAG: store x86_fp80 [[H2LD]], x86_fp80* %{{.*}}, align 16
 
   _Float16 f2h = 42.0f;
 //CHECK-DAG: store half 0xH5140, half* %{{.*}}, align 2
Index: test/AST/float16.cpp

[PATCH] D57104: [AST] Pack GenericSelectionExpr

[Bruno Ricci via Phabricator via cfe-commits]

riccibruno added a comment.

> I highly recommend this 9 minute video if this is new to you or you haven't 
> seen it before: https://youtu.be/qpdYRPL3SVE?t=103

I would like to add an additional meta-comment here, but please don't take this 
in a bad way. I am wondering
about the usefulness and the productivity of the "if this is new to you" in 
what I am assuming is a discussion
between professionals. I will be happy to address any further technical 
comments regarding the code itself.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57104



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

[PATCH] D57185: [clang-tidy] Add the abseil-duration-addition check

[Hyrum Wright via Phabricator via cfe-commits]

hwright created this revision.
hwright added reviewers: hokein, aaron.ballman, JonasToth.
hwright added a project: clang-tools-extra.
Herald added subscribers: cfe-commits, xazax.hun, mgorny.

This is an analog to the existing `abseil-duration-subtraction` check.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D57185

Files:
  clang-tidy/abseil/AbseilTidyModule.cpp
  clang-tidy/abseil/CMakeLists.txt
  clang-tidy/abseil/DurationAdditionCheck.cpp
  clang-tidy/abseil/DurationAdditionCheck.h
  clang-tidy/abseil/DurationRewriter.cpp
  clang-tidy/abseil/DurationRewriter.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/abseil-duration-addition.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/Inputs/absl/time/time.h
  test/clang-tidy/abseil-duration-addition.cpp

Index: test/clang-tidy/abseil-duration-addition.cpp
===
--- /dev/null
+++ test/clang-tidy/abseil-duration-addition.cpp
@@ -0,0 +1,78 @@
+// RUN: %check_clang_tidy %s abseil-duration-addition %t -- -- -I%S/Inputs
+
+#include "absl/time/time.h"
+
+void f() {
+  absl::Time t;
+  int i;
+
+  i = absl::ToUnixHours(t) + 5;
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixHours(t + absl::Hours(5))
+  i = absl::ToUnixMinutes(t) + 5;
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixMinutes(t + absl::Minutes(5))
+  i = absl::ToUnixSeconds(t) + 5;
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixSeconds(t + absl::Seconds(5))
+  i = absl::ToUnixMillis(t) + 5;
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixMillis(t + absl::Milliseconds(5))
+  i = absl::ToUnixMicros(t) + 5;
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixMicros(t + absl::Microseconds(5))
+  i = absl::ToUnixNanos(t) + 5;
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixNanos(t + absl::Nanoseconds(5))
+
+  i = 3 + absl::ToUnixHours(t);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixHours(absl::Hours(3) + t)
+  i = 3 + absl::ToUnixMinutes(t);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixMinutes(absl::Minutes(3) + t)
+  i = 3 + absl::ToUnixSeconds(t);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixSeconds(absl::Seconds(3) + t)
+  i = 3 + absl::ToUnixMillis(t);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixMillis(absl::Milliseconds(3) + t)
+  i = 3 + absl::ToUnixMicros(t);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixMicros(absl::Microseconds(3) + t)
+  i = 3 + absl::ToUnixNanos(t);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixNanos(absl::Nanoseconds(3) + t)
+
+  // Undoing inverse conversions
+  i = absl::ToUnixMicros(t) + absl::ToInt64Microseconds(absl::Seconds(1));
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixMicros(t + absl::Seconds(1))
+
+  // Float folding
+  i = absl::ToUnixSeconds(t) + 5.0;
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixSeconds(t + absl::Seconds(5))
+
+  // We can rewrite the argument of the duration conversion
+#define THIRTY absl::FromUnixSeconds(30)
+  i = absl::ToUnixSeconds(THIRTY) + 1;
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixSeconds(THIRTY + absl::Seconds(1))
+#undef THIRTY
+
+  // Some other contexts
+  if (absl::ToUnixSeconds(t) + 1.0 > 10) {}
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform addition in the duration domain [abseil-duration-addition]
+  // CHECK-FIXES: absl::ToUnixSeconds(t + absl::Seconds(1))
+
+  // These should not match
+  i = 5 + 6;
+  i = absl::ToUnixSeconds(t) - 1.0;
+  i = absl::ToUnixSeconds(t) * 1.0;
+  i = absl::ToUnixSeconds(t) / 1.0;
+
+#define PLUS_FIVE(z) absl::ToUnixSeconds(z) + 5
+  i = PLUS_FIVE(t);
+#undef 

[PATCH] D57104: [AST] Pack GenericSelectionExpr

[Bruno Ricci via Phabricator via cfe-commits]

riccibruno added a comment.

In D57104#1370025 , @aaron.ballman 
wrote:

> In D57104#1369985 , @steveire wrote:
>
> > There's definitely a better possible ordering in two commits:
> >
> > 1. Introduce `::Create` and port to it
> > 2. Use trailing objects, taking advantage of the fact that `::Create` 
> > exists.
> >
> >   That would make it clear in the future to other people because both 
> > commits would be cleaner, both commit messages would say what the commit 
> > does, and neither commit would have the noise of the other change.
> >
> >   Not splitting this commit makes it less reviewable to people who are not 
> > around today.
>
>
> I would find reviewing that more confusing because the two reviews are 
> inextricably linked. There's no need for a `Create()` method without the 
> other changes, and the other changes require a `Create()` method. I get what 
> you mean about keeping reviews concise, but at some point you can split the 
> reviews so much that it becomes really difficult to perform a sensible review 
> because you get too much information in isolation.


+1 You can cut a commit into arbitrarily small pieces. As a silly example I 
could inherit from `llvm::TrailingObjects` in one commit.
Then remove the `Stmt **` in another one and so on.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57104



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

[PATCH] D56326: [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: lib/AST/DeclOpenMP.cpp:164
+  if (NumClauses) {
+Clauses = (OMPClause **)C.Allocate(sizeof(OMPClause *) * NumClauses);
+setClauses(CL);

lildmh wrote:
> ABataev wrote:
> > lildmh wrote:
> > > ABataev wrote:
> > > > lildmh wrote:
> > > > > ABataev wrote:
> > > > > > lildmh wrote:
> > > > > > > ABataev wrote:
> > > > > > > > No, bad idea. Use tail allocation for the clauses. Check the 
> > > > > > > > implementation of `OMPRequiresDecl`
> > > > > > > I think it is possible to use TrailingObjects for clause storage 
> > > > > > > when the number of clauses are known before creating the 
> > > > > > > directive (e.g., for OMPRequiresDecl and OMPExecutableDirective). 
> > > > > > > 
> > > > > > > The reason that I had to create OMPDeclareMapperDecl before 
> > > > > > > parsing map clauses, is the mapper variable (AA in the example 
> > > > > > > below) needs to be declared within OMPDeclareMapperDecl, because 
> > > > > > > the following map clauses will use it.
> > > > > > > 
> > > > > > > ```
> > > > > > > #pragma omp declare mapper(struct S AA) map(AA.field1)
> > > > > > > ```
> > > > > > > 
> > > > > > > A possible way to get around this is to count the number of map 
> > > > > > > clauses before hand. But this solution is not trivial since the 
> > > > > > > normal method for parsing map clauses cannot be used (e.g., it 
> > > > > > > does not know AA when parsing map(AA.field1)). A customized and 
> > > > > > > complex (because it needs to handle all possible situations) 
> > > > > > > parsing method needs to be created, just for counting clause 
> > > > > > > number. I think it's not worthy to do this compared with 
> > > > > > > allocating map clause space later.
> > > > > > > 
> > > > > > > I checked the code for OMPDeclareReductionDecl that you wrote. It 
> > > > > > > also has to be created before parsing the combiner and 
> > > > > > > initializer. It does not have a variable number of clauses though.
> > > > > > > 
> > > > > > > Any suggestions?
> > > > > > Instead, you can introduce special DeclContext-based declaration 
> > > > > > and keep the reference to this declaration inside of the 
> > > > > > `OMPDeclareMapperDecl`.
> > > > > Hi Alexey,
> > > > > 
> > > > > Thanks a lot for your quick response! I don't think I understand your 
> > > > > idea. Can you establish more on that?
> > > > > 
> > > > > In my current implementation, OMPDeclareMapperDecl is used as the 
> > > > > DeclConext of the variable AA in the above example, and it already 
> > > > > includes the reference to AA's declaration.
> > > > > 
> > > > > My problem is, I need to create OMPDeclareMapperDecl before parsing 
> > > > > map clauses. But before parsing map clauses, I don't know the number 
> > > > > of clauses. Using TrailingObject requires to know how many clauses 
> > > > > there are when creating OMPDeclareMapperDecl. So I couldn't use 
> > > > > TrailingObject.
> > > > > 
> > > > > My current solution is to create OMPDeclareMapperDecl before parsing 
> > > > > map clauses, and to create the clause storage after parsing finishes.
> > > > What I meant, that you don't need to use `OMPDeclareMapperDecl` for 
> > > > this, instead you can add another (very simple) special declaration 
> > > > based on `DeclContext` to use it as the parent declaration for the 
> > > > variable. In the `OMPDeclareMapperDecl` you can keep the reference to 
> > > > this special declaration.
> > > Thanks for your response! Please let me know if my understanding below is 
> > > correct:
> > > 
> > > `OMPDeclareMapperDecl` no longer inherits from `DeclContext`. Instead, we 
> > > create something like `OMPDeclareMapperDeclContext` which inherits from 
> > > `DeclContext`, and `OMPDeclareMapperDecl` keeps a pointer that points to 
> > > this `OMPDeclareMapperDeclContext`.  AA and map clauses are parsed within 
> > > `OMPDeclareMapperDeclContext`.
> > > 
> > > This sounds a bit more complex, but if you believe it's better, I can 
> > > change the code. Please share your thoughts.
> > Yes, something like this.
> Hi Alexey,
> 
> Sorry for the late response. I was working on something else last week.
> 
> When I tried to modify the code based on your suggestions, I found out that 
> `DeclContext` is only meant to be used for a `Decl` (please see the comments 
> before `class DeclContext {...}` in include/clang/AST/DeclBase.h).
> 
> It means, if I create a `OMPDeclareMapperDeclContext ` which is a 
> `DeclContext ` but not a `Decl`, the code cannot work correctly. Therefore 
> `OMPDeclareMapperDeclContext` must be a `Decl` itself. If I do it this way, a 
> lot of useless information (all inherited from `Decl`) will exist within 
> `OMPDeclareMapperDeclContext`, which is very inefficient.
> 
> An alternative way is to have something called `OMPDeclareMapperClauses` that 
> inherits from `TrailingObject` to store clause information, and 
> `OMPDeclareMapperDecl` keeps 

[PATCH] D57104: [AST] Pack GenericSelectionExpr

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D57104#1369985 , @steveire wrote:

> There's definitely a better possible ordering in two commits:
>
> 1. Introduce `::Create` and port to it
> 2. Use trailing objects, taking advantage of the fact that `::Create` exists.
>
>   That would make it clear in the future to other people because both commits 
> would be cleaner, both commit messages would say what the commit does, and 
> neither commit would have the noise of the other change.
>
>   Not splitting this commit makes it less reviewable to people who are not 
> around today.


I would find reviewing that more confusing because the two reviews are 
inextricably linked. There's no need for a `Create()` method without the other 
changes, and the other changes require a `Create()` method. I get what you mean 
about keeping reviews concise, but at some point you can split the reviews so 
much that it becomes really difficult to perform a sensible review because you 
get too much information in isolation.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57104



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

[PATCH] D57104: [AST] Pack GenericSelectionExpr

[Bruno Ricci via Phabricator via cfe-commits]

riccibruno added a comment.

In D57104#1369985 , @steveire wrote:

> There's definitely a better possible ordering in two commits:
>
> 1. Introduce `::Create` and port to it
> 2. Use trailing objects, taking advantage of the fact that `::Create` exists.
>
>   That would make it clear in the future to other people because both commits 
> would be cleaner, both commit messages would say what the commit does, and 
> neither commit would have the noise of the other change.
>
>   Not splitting this commit makes it less reviewable to people who are not 
> around today.


I strongly disagree. The only reason for the `Create` method to exist is 
because we are using trailing objects.
It is not "oh nice `Create` exists, lets use it!". Furthermore, this is a 
standard pattern across the code-base and
this patch is already tiny.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57104



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

[PATCH] D57184: [clang-format] Allow configuring list of function-like macros that resolve to a type

[Marcin Radomski via Phabricator via cfe-commits]

dextero created this revision.
dextero added reviewers: Typz, krasimir, djasper.
Herald added a subscriber: cfe-commits.

Adds a `TypenameMacros` configuration option that causes certain identifiers to 
be handled in a way similar to `typeof()`.

This is enough to:

- Prevent misinterpreting declarations of pointers to such types as expressions 
(`STACK_OF(int) * foo` -> `STACK_OF(int) *foo`),
- Avoid surprising line breaks in variable/struct field declarations 
(`STACK_OF(int)\nfoo;` -> `STACK_OF(int) foo;`, see 
https://bugs.llvm.org/show_bug.cgi?id=30353).


Repository:
  rC Clang

https://reviews.llvm.org/D57184

Files:
  docs/ClangFormatStyleOptions.rst
  include/clang/Format/Format.h
  lib/Format/Format.cpp
  lib/Format/FormatToken.h
  lib/Format/FormatTokenLexer.cpp
  lib/Format/TokenAnnotator.cpp
  unittests/Format/FormatTest.cpp

Index: unittests/Format/FormatTest.cpp
===
--- unittests/Format/FormatTest.cpp
+++ unittests/Format/FormatTest.cpp
@@ -12806,6 +12806,35 @@
   guessLanguage("foo.h", "#define FOO ({ foo(); ({ NSString *s; }) })"));
 }
 
+TEST_F(FormatTest, TypenameMacros) {
+  std::vector TypenameMacros = {"STACK_OF", "LIST", "TAILQ_ENTRY"};
+
+  // Test case reported in https://bugs.llvm.org/show_bug.cgi?id=30353
+  FormatStyle Google = getGoogleStyleWithColumns(0);
+  Google.TypenameMacros = TypenameMacros;
+  verifyFormat("struct foo {\n"
+   "  int bar;\n"
+   "  TAILQ_ENTRY(a) bleh;\n"
+   "};", Google);
+
+  FormatStyle Macros = getLLVMStyle();
+  Macros.TypenameMacros = TypenameMacros;
+
+  verifyFormat("STACK_OF(int) a;", Macros);
+  verifyFormat("STACK_OF(int) *a;", Macros);
+  verifyFormat("STACK_OF(int const *) *a;", Macros);
+  verifyFormat("STACK_OF(int *const) *a;", Macros);
+  verifyFormat("STACK_OF(int, string) a;", Macros);
+  verifyFormat("STACK_OF(LIST(int)) a;", Macros);
+  verifyFormat("STACK_OF(LIST(int)) a, b;", Macros);
+  verifyFormat("for (LIST(int) *a = NULL; a;) {\n}", Macros);
+  verifyFormat("STACK_OF(int) f(LIST(int) *arg);", Macros);
+
+  Macros.PointerAlignment = FormatStyle::PAS_Left;
+  verifyFormat("STACK_OF(int)* a;", Macros);
+  verifyFormat("STACK_OF(int*)* a;", Macros);
+}
+
 } // end namespace
 } // end namespace format
 } // end namespace clang
Index: lib/Format/TokenAnnotator.cpp
===
--- lib/Format/TokenAnnotator.cpp
+++ lib/Format/TokenAnnotator.cpp
@@ -1134,8 +1134,9 @@
 // Reset token type in case we have already looked at it and then
 // recovered from an error (e.g. failure to find the matching >).
 if (!CurrentToken->isOneOf(TT_LambdaLSquare, TT_ForEachMacro,
-   TT_FunctionLBrace, TT_ImplicitStringLiteral,
-   TT_InlineASMBrace, TT_JsFatArrow, TT_LambdaArrow,
+   TT_TypenameMacro, TT_FunctionLBrace,
+   TT_ImplicitStringLiteral, TT_InlineASMBrace,
+   TT_JsFatArrow, TT_LambdaArrow,
TT_OverloadedOperator, TT_RegexLiteral,
TT_TemplateString, TT_ObjCStringLiteral))
   CurrentToken->Type = TT_Unknown;
@@ -1354,6 +1355,7 @@
   if (AfterParen->Tok.isNot(tok::caret)) {
 if (FormatToken *BeforeParen = Current.MatchingParen->Previous)
   if (BeforeParen->is(tok::identifier) &&
+  !BeforeParen->is(TT_TypenameMacro) &&
   BeforeParen->TokenText == BeforeParen->TokenText.upper() &&
   (!BeforeParen->Previous ||
BeforeParen->Previous->ClosesTemplateDeclaration))
@@ -1604,7 +1606,8 @@
   FormatToken *TokenBeforeMatchingParen =
   PrevToken->MatchingParen->getPreviousNonComment();
   if (TokenBeforeMatchingParen &&
-  TokenBeforeMatchingParen->isOneOf(tok::kw_typeof, tok::kw_decltype))
+  TokenBeforeMatchingParen->isOneOf(tok::kw_typeof, tok::kw_decltype,
+TT_TypenameMacro))
 return TT_PointerOrReference;
 }
 
@@ -2455,7 +2458,8 @@
   FormatToken *TokenBeforeMatchingParen =
   Left.MatchingParen->getPreviousNonComment();
   if (!TokenBeforeMatchingParen ||
-  !TokenBeforeMatchingParen->isOneOf(tok::kw_typeof, tok::kw_decltype))
+  !TokenBeforeMatchingParen->isOneOf(tok::kw_typeof, tok::kw_decltype,
+ TT_TypenameMacro))
 return true;
 }
 return (Left.Tok.isLiteral() ||
Index: lib/Format/FormatTokenLexer.cpp
===
--- lib/Format/FormatTokenLexer.cpp
+++ lib/Format/FormatTokenLexer.cpp
@@ -39,6 +39,8 @@
 Macros.insert({(ForEachMacro), TT_ForEachMacro});
   for (const std::string  : Style.StatementMacros)
 

r352108 - [WebAssembly] Add WebAssemblyImportModule to pragma-attribute-supported-attributes-list.test

[Dan Gohman via cfe-commits]

Author: djg
Date: Thu Jan 24 13:20:03 2019
New Revision: 352108

URL: http://llvm.org/viewvc/llvm-project?rev=352108=rev
Log:
[WebAssembly] Add WebAssemblyImportModule to 
pragma-attribute-supported-attributes-list.test

Modified:
cfe/trunk/test/Misc/pragma-attribute-supported-attributes-list.test

Modified: cfe/trunk/test/Misc/pragma-attribute-supported-attributes-list.test
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Misc/pragma-attribute-supported-attributes-list.test?rev=352108=352107=352108=diff
==
--- cfe/trunk/test/Misc/pragma-attribute-supported-attributes-list.test 
(original)
+++ cfe/trunk/test/Misc/pragma-attribute-supported-attributes-list.test Thu Jan 
24 13:20:03 2019
@@ -138,6 +138,7 @@
 // CHECK-NEXT: WarnUnusedResult (SubjectMatchRule_objc_method, 
SubjectMatchRule_enum, SubjectMatchRule_record, 
SubjectMatchRule_hasType_functionType)
 // CHECK-NEXT: Weak (SubjectMatchRule_variable, SubjectMatchRule_function, 
SubjectMatchRule_record)
 // CHECK-NEXT: WeakRef (SubjectMatchRule_variable, SubjectMatchRule_function)
+// CHECK-NEXT: WebAssemblyImportModule (SubjectMatchRule_function)
 // CHECK-NEXT: WorkGroupSizeHint (SubjectMatchRule_function)
 // CHECK-NEXT: XRayInstrument (SubjectMatchRule_function, 
SubjectMatchRule_objc_method)
 // CHECK-NEXT: XRayLogArgs (SubjectMatchRule_function, 
SubjectMatchRule_objc_method)


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

[PATCH] D57104: [AST] Pack GenericSelectionExpr

[Stephen Kelly via Phabricator via cfe-commits]

steveire added a comment.

In D57104#1369985 , @steveire wrote:

> There's definitely a better possible ordering in two commits:
>
> 1. Introduce `::Create` and port to it
> 2. Use trailing objects, taking advantage of the fact that `::Create` exists.
>
>   That would make it clear in the future to other people because both commits 
> would be cleaner, both commit messages would say what the commit does, and 
> neither commit would have the noise of the other change.
>
>   Not splitting this commit makes it less reviewable to people who are not 
> around today.


I highly recommend this 9 minute video if this is new to you or you haven't 
seen it before: https://youtu.be/qpdYRPL3SVE?t=103


Repository:
  rC Clang

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

https://reviews.llvm.org/D57104



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

[PATCH] D56160: [clang-tidy] modernize-use-trailing-return check

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D56160#1367811 , @JonasToth wrote:

> In D56160#1367074 , @bernhardmgruber 
> wrote:
>
> > Thank you again @JonasToth for all your valueable input! I could almost 
> > successfully run my check on the llvm/lib subfolder. I created a 
> > compilation database from within Visual Studio using an extension called 
> > SourceTrail 
> > .
> >  One of the issues was the following:
>
>
> Very good!
>
> >   struct Object { long long value; };
> >   class C {
> > int Object;
> > struct Object m();
> >   };
> >   Object C::m() { return {0}; }
> > 
> > 
> > If I rewrite this to the following
> > 
> >   struct Object { long long value; };
> >   class C {
> > int Object;
> > struct Object m();
> >   };
> >   auto C::m() -> Object { return {0}; }
> > 
> > 
> > a compilation error occurs afterwards, because Object now refers to the 
> > class member. I discovered a similar problem colliding with the name of a 
> > function argument. So essentially, I believe I now require a name lookup of 
> > the return type (if it is unqualified) in the scope of the function. In 
> > case such a name already exists, i have to prefix `struct/class` or perform 
> > no replacement. I looked at the documentation of `ASTContext`, but it seems 
> > all the good stuff is in `DeclContext`, which I have not available. How can 
> > I perform a name lookup inside the `check` member function?
>
> That is very interesting and I was not aware of this possibility :D
>
> Every `Decl` derives from `DeclContext`, see for example the docs for 
> `CXXMethodDecl` 
> (https://clang.llvm.org/doxygen/classclang_1_1CXXMethodDecl.html)
>  You should be able to look up the names you are interested. I don't know of 
> a good way to check for the issue we have right now, @aaron.ballman knows 
> that probably better then I do.
>  Try to experiment, but If you don't find a solution come back to us, we will 
> figure something out (or ask in IRC).


I think you may be able to skip the lookup (which could get expensive) and 
instead rely on the fact that the user must have explicitly written that type 
as an elaborated type specifier when trying to calculate the source range for 
the return type. I suspect what's happening right now is that 
`findReturnTypeAndCVSourceRange()` isn't noticing the `struct` specifier and 
that's why it's getting dropped. If the user wrote it as an elaborated type 
specifier, we should probably retain that when shifting it to a trailing return 
type.




Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:132
+  // If the return type has no local qualifiers, it's source range is accurate.
+  if (!F.getReturnType().hasLocalQualifiers())
+return ReturnTypeRange;

I think you may need to check here if the return type is an elaborated type 
(e.g., one that is written as `struct S` rather than `S`).



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:153
+!ExtendedLeft) {
+  for (int J = static_cast(I) - 1; J >= 0 && IsCV(Tokens[J]); J--)
+ReturnTypeRange.setBegin(Tokens[J].getLocation());

And then look for the elaborated tag type here.


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

https://reviews.llvm.org/D56160



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

[PATCH] D57104: [AST] Pack GenericSelectionExpr

[Stephen Kelly via Phabricator via cfe-commits]

steveire added a comment.

There's definitely a better possible ordering in two commits:

1. Introduce `::Create` and port to it
2. Use trailing objects, taking advantage of the fact that `::Create` exists.

That would make it clear in the future to other people because both commits 
would be cleaner, both commit messages would say what the commit does, and 
neither commit would have the noise of the other change.

Not splitting this commit makes it less reviewable to people who are not around 
today.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57104



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

[PATCH] D57160: [WebAssembly] Add an import_module function attribute

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rC352106: [WebAssembly] Add an import_module function 
attribute (authored by djg, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D57160?vs=183322=183378#toc

Repository:
  rC Clang

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

https://reviews.llvm.org/D57160

Files:
  include/clang/Basic/Attr.td
  include/clang/Basic/AttrDocs.td
  lib/CodeGen/TargetInfo.cpp
  lib/Sema/SemaDeclAttr.cpp
  test/CodeGen/wasm-import-module.c

Index: include/clang/Basic/AttrDocs.td
===
--- include/clang/Basic/AttrDocs.td
+++ include/clang/Basic/AttrDocs.td
@@ -3711,7 +3711,23 @@
 For more information see
 `gcc documentation `_
 or `msvc documentation `_.
-}];
+}]; }
+
+def WebAssemblyImportModuleDocs : Documentation {
+  let Category = DocCatFunction;
+  let Content = [{
+Clang supports the ``__attribute__((import_module()))`` 
+attribute for the WebAssembly target. This attribute may be attached to a
+function declaration, where it modifies how the symbol is to be imported
+within the WebAssembly linking environment.
+
+WebAssembly imports use a two-level namespace scheme, consisting of a module
+name, which typically identifies a module from which to import, and a field
+name, which typically identifies a field from that module to import. By
+default, module names for C/C++ symbols are assigned automatically by the
+linker. This attribute can be used to override the default behavior, and
+reuqest a specific module name be used instead.
+  }];
 }
 
 def ArtificialDocs : Documentation {
Index: include/clang/Basic/Attr.td
===
--- include/clang/Basic/Attr.td
+++ include/clang/Basic/Attr.td
@@ -331,6 +331,7 @@
 def TargetRISCV : TargetArch<["riscv32", "riscv64"]>;
 def TargetX86 : TargetArch<["x86"]>;
 def TargetAnyX86 : TargetArch<["x86", "x86_64"]>;
+def TargetWebAssembly : TargetArch<["wasm32", "wasm64"]>;
 def TargetWindows : TargetArch<["x86", "x86_64", "arm", "thumb", "aarch64"]> {
   let OSes = ["Win32"];
 }
@@ -1510,6 +1511,14 @@
   let Subjects = SubjectList<[Function], ErrorDiag, "kernel functions">;
 }
 
+def WebAssemblyImportModule : InheritableAttr,
+  TargetSpecificAttr {
+  let Spellings = [Clang<"import_module">];
+  let Args = [StringArgument<"ImportModuleName">];
+  let Documentation = [WebAssemblyImportModuleDocs];
+  let Subjects = SubjectList<[Function], ErrorDiag>;
+}
+
 def NoSplitStack : InheritableAttr {
   let Spellings = [GCC<"no_split_stack">];
   let Subjects = SubjectList<[Function], ErrorDiag>;
Index: test/CodeGen/wasm-import-module.c
===
--- test/CodeGen/wasm-import-module.c
+++ test/CodeGen/wasm-import-module.c
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -triple wasm32-unknown-unknown-wasm -emit-llvm -o - %s | FileCheck %s
+
+void __attribute__((import_module("bar"))) foo(void);
+
+void call(void) {
+  foo();
+}
+
+// CHECK: declare void @foo() [[A:#[0-9]+]]
+
+// CHECK: attributes [[A]] = {{{.*}} "wasm-import-module"="bar" {{.*}}}
Index: lib/Sema/SemaDeclAttr.cpp
===
--- lib/Sema/SemaDeclAttr.cpp
+++ lib/Sema/SemaDeclAttr.cpp
@@ -5709,6 +5709,28 @@
   handleSimpleAttribute(S, D, AL);
 }
 
+static void handleWebAssemblyImportModuleAttr(Sema , Decl *D, const ParsedAttr ) {
+  if (!isFunctionOrMethod(D)) {
+S.Diag(D->getLocation(), diag::warn_attribute_wrong_decl_type)
+<< "'import_module'" << ExpectedFunction;
+return;
+  }
+
+  auto *FD = cast(D);
+  if (FD->isThisDeclarationADefinition()) {
+S.Diag(D->getLocation(), diag::err_alias_is_definition) << FD << 0;
+return;
+  }
+
+  StringRef Str;
+  SourceLocation ArgLoc;
+  if (!S.checkStringLiteralArgumentAttr(AL, 0, Str, ))
+return;
+
+  FD->addAttr(::new (S.Context) WebAssemblyImportModuleAttr(
+  AL.getRange(), S.Context, Str,
+  AL.getAttributeSpellingListIndex()));
+}
 
 static void handleRISCVInterruptAttr(Sema , Decl *D,
  const ParsedAttr ) {
@@ -6464,6 +6486,9 @@
   case ParsedAttr::AT_AVRSignal:
 handleAVRSignalAttr(S, D, AL);
 break;
+  case ParsedAttr::AT_WebAssemblyImportModule:
+handleWebAssemblyImportModuleAttr(S, D, AL);
+break;
   case ParsedAttr::AT_IBAction:
 handleSimpleAttribute(S, D, AL);
 break;
Index: lib/CodeGen/TargetInfo.cpp
===
--- lib/CodeGen/TargetInfo.cpp
+++ lib/CodeGen/TargetInfo.cpp
@@ -760,6 +760,16 @@
 
   void setTargetAttributes(const Decl *D, llvm::GlobalValue *GV,

r352106 - [WebAssembly] Add an import_module function attribute

[Dan Gohman via cfe-commits]

Author: djg
Date: Thu Jan 24 13:08:30 2019
New Revision: 352106

URL: http://llvm.org/viewvc/llvm-project?rev=352106=rev
Log:
[WebAssembly] Add an import_module function attribute

This adds a C/C++ attribute which corresponds to the LLVM IR wasm-import-module
attribute. It allows code to specify an explicit import module.

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

Added:
cfe/trunk/test/CodeGen/wasm-import-module.c
Modified:
cfe/trunk/include/clang/Basic/Attr.td
cfe/trunk/include/clang/Basic/AttrDocs.td
cfe/trunk/lib/CodeGen/TargetInfo.cpp
cfe/trunk/lib/Sema/SemaDeclAttr.cpp

Modified: cfe/trunk/include/clang/Basic/Attr.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=352106=352105=352106=diff
==
--- cfe/trunk/include/clang/Basic/Attr.td (original)
+++ cfe/trunk/include/clang/Basic/Attr.td Thu Jan 24 13:08:30 2019
@@ -331,6 +331,7 @@ def TargetMSP430 : TargetArch<["msp430"]
 def TargetRISCV : TargetArch<["riscv32", "riscv64"]>;
 def TargetX86 : TargetArch<["x86"]>;
 def TargetAnyX86 : TargetArch<["x86", "x86_64"]>;
+def TargetWebAssembly : TargetArch<["wasm32", "wasm64"]>;
 def TargetWindows : TargetArch<["x86", "x86_64", "arm", "thumb", "aarch64"]> {
   let OSes = ["Win32"];
 }
@@ -1510,6 +1511,14 @@ def AMDGPUNumVGPR : InheritableAttr {
   let Subjects = SubjectList<[Function], ErrorDiag, "kernel functions">;
 }
 
+def WebAssemblyImportModule : InheritableAttr,
+  TargetSpecificAttr {
+  let Spellings = [Clang<"import_module">];
+  let Args = [StringArgument<"ImportModuleName">];
+  let Documentation = [WebAssemblyImportModuleDocs];
+  let Subjects = SubjectList<[Function], ErrorDiag>;
+}
+
 def NoSplitStack : InheritableAttr {
   let Spellings = [GCC<"no_split_stack">];
   let Subjects = SubjectList<[Function], ErrorDiag>;

Modified: cfe/trunk/include/clang/Basic/AttrDocs.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttrDocs.td?rev=352106=352105=352106=diff
==
--- cfe/trunk/include/clang/Basic/AttrDocs.td (original)
+++ cfe/trunk/include/clang/Basic/AttrDocs.td Thu Jan 24 13:08:30 2019
@@ -3711,7 +3711,23 @@ definition (
 For more information see
 `gcc documentation 
`_
 or `msvc documentation `_.
-}];
+}]; }
+
+def WebAssemblyImportModuleDocs : Documentation {
+  let Category = DocCatFunction;
+  let Content = [{
+Clang supports the ``__attribute__((import_module()))`` 
+attribute for the WebAssembly target. This attribute may be attached to a
+function declaration, where it modifies how the symbol is to be imported
+within the WebAssembly linking environment.
+
+WebAssembly imports use a two-level namespace scheme, consisting of a module
+name, which typically identifies a module from which to import, and a field
+name, which typically identifies a field from that module to import. By
+default, module names for C/C++ symbols are assigned automatically by the
+linker. This attribute can be used to override the default behavior, and
+reuqest a specific module name be used instead.
+  }];
 }
 
 def ArtificialDocs : Documentation {

Modified: cfe/trunk/lib/CodeGen/TargetInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.cpp?rev=352106=352105=352106=diff
==
--- cfe/trunk/lib/CodeGen/TargetInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/TargetInfo.cpp Thu Jan 24 13:08:30 2019
@@ -760,6 +760,16 @@ public:
 
   void setTargetAttributes(const Decl *D, llvm::GlobalValue *GV,
CodeGen::CodeGenModule ) const override {
+TargetCodeGenInfo::setTargetAttributes(D, GV, CGM);
+if (const auto *FD = dyn_cast_or_null(D)) {
+  if (const auto *Attr = FD->getAttr()) {
+llvm::Function *Fn = cast(GV);
+llvm::AttrBuilder B;
+B.addAttribute("wasm-import-module", Attr->getImportModuleName());
+Fn->addAttributes(llvm::AttributeList::FunctionIndex, B);
+  }
+}
+
 if (auto *FD = dyn_cast_or_null(D)) {
   llvm::Function *Fn = cast(GV);
   if (!FD->doesThisDeclarationHaveABody() && !FD->hasPrototype())

Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=352106=352105=352106=diff
==
--- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Thu Jan 24 13:08:30 2019
@@ -5709,6 +5709,28 @@ static void handleAVRSignalAttr(Sema ,
   handleSimpleAttribute(S, D, AL);
 }
 
+static void handleWebAssemblyImportModuleAttr(Sema , Decl *D, const 

[PATCH] D57155: [WebAssembly] Add a __wasi__ target macro

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL352105: [WebAssembly] Add a __wasi__ target macro (authored 
by djg, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D57155?vs=183306=183375#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D57155

Files:
  cfe/trunk/lib/Basic/Targets.cpp
  cfe/trunk/lib/Basic/Targets/OSTargets.h
  cfe/trunk/test/Preprocessor/init.c

Index: cfe/trunk/test/Preprocessor/init.c
===
--- cfe/trunk/test/Preprocessor/init.c
+++ cfe/trunk/test/Preprocessor/init.c
@@ -9114,6 +9114,12 @@
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=wasm64-unknown-unknown \
 // RUN:   < /dev/null \
 // RUN:   | FileCheck -match-full-lines -check-prefixes=WEBASSEMBLY,WEBASSEMBLY64 %s
+// RUN: %clang_cc1 -E -dM -ffreestanding -triple=wasm32-unknown-wasi \
+// RUN:   < /dev/null \
+// RUN:   | FileCheck -match-full-lines -check-prefixes=WEBASSEMBLY,WEBASSEMBLY32,WEBASSEMBLY-WASI %s
+// RUN: %clang_cc1 -E -dM -ffreestanding -triple=wasm64-unknown-wasi \
+// RUN:   < /dev/null \
+// RUN:   | FileCheck -match-full-lines -check-prefixes=WEBASSEMBLY,WEBASSEMBLY64,WEBASSEMBLY-WASI %s
 //
 // WEBASSEMBLY32:#define _ILP32 1
 // WEBASSEMBLY32-NOT:#define _LP64
@@ -9468,6 +9474,7 @@
 // WEBASSEMBLY-NEXT:#define __llvm__ 1
 // WEBASSEMBLY-NOT:#define __unix
 // WEBASSEMBLY-NOT:#define __unix__
+// WEBASSEMBLY-WASI-NEXT:#define __wasi__ 1
 // WEBASSEMBLY-NOT:#define __wasm_simd128__
 // WEBASSEMBLY-NOT:#define __wasm_simd256__
 // WEBASSEMBLY-NOT:#define __wasm_simd512__
Index: cfe/trunk/lib/Basic/Targets/OSTargets.h
===
--- cfe/trunk/lib/Basic/Targets/OSTargets.h
+++ cfe/trunk/lib/Basic/Targets/OSTargets.h
@@ -763,8 +763,9 @@
 template 
 class LLVM_LIBRARY_VISIBILITY WebAssemblyOSTargetInfo
 : public OSTargetInfo {
+protected:
   void getOSDefines(const LangOptions , const llvm::Triple ,
-MacroBuilder ) const final {
+MacroBuilder ) const {
 // A common platform macro.
 if (Opts.POSIXThreads)
   Builder.defineMacro("_REENTRANT");
@@ -785,6 +786,21 @@
   }
 };
 
+// WASI target
+template 
+class LLVM_LIBRARY_VISIBILITY WASITargetInfo
+: public WebAssemblyOSTargetInfo {
+  void getOSDefines(const LangOptions , const llvm::Triple ,
+MacroBuilder ) const final {
+WebAssemblyOSTargetInfo::getOSDefines(Opts, Triple, Builder);
+Builder.defineMacro("__wasi__");
+  }
+
+public:
+  explicit WASITargetInfo(const llvm::Triple , const TargetOptions )
+  : WebAssemblyOSTargetInfo(Triple, Opts) {}
+};
+
 } // namespace targets
 } // namespace clang
 #endif // LLVM_CLANG_LIB_BASIC_TARGETS_OSTARGETS_H
Index: cfe/trunk/lib/Basic/Targets.cpp
===
--- cfe/trunk/lib/Basic/Targets.cpp
+++ cfe/trunk/lib/Basic/Targets.cpp
@@ -569,19 +569,27 @@
 Triple.getVendor() != llvm::Triple::UnknownVendor ||
 !Triple.isOSBinFormatWasm())
   return nullptr;
-if (Triple.getOS() != llvm::Triple::UnknownOS &&
-Triple.getOS() != llvm::Triple::WASI)
-  return nullptr;
-return new WebAssemblyOSTargetInfo(Triple, Opts);
+switch (Triple.getOS()) {
+  case llvm::Triple::WASI:
+return new WASITargetInfo(Triple, Opts);
+  case llvm::Triple::UnknownOS:
+return new WebAssemblyOSTargetInfo(Triple, Opts);
+  default:
+return nullptr;
+}
   case llvm::Triple::wasm64:
 if (Triple.getSubArch() != llvm::Triple::NoSubArch ||
 Triple.getVendor() != llvm::Triple::UnknownVendor ||
 !Triple.isOSBinFormatWasm())
   return nullptr;
-if (Triple.getOS() != llvm::Triple::UnknownOS &&
-Triple.getOS() != llvm::Triple::WASI)
-  return nullptr;
-return new WebAssemblyOSTargetInfo(Triple, Opts);
+switch (Triple.getOS()) {
+  case llvm::Triple::WASI:
+return new WASITargetInfo(Triple, Opts);
+  case llvm::Triple::UnknownOS:
+return new WebAssemblyOSTargetInfo(Triple, Opts);
+  default:
+return nullptr;
+}
 
   case llvm::Triple::renderscript32:
 return new LinuxTargetInfo(Triple, Opts);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r352105 - [WebAssembly] Add a __wasi__ target macro

[Dan Gohman via cfe-commits]

Author: djg
Date: Thu Jan 24 13:05:11 2019
New Revision: 352105

URL: http://llvm.org/viewvc/llvm-project?rev=352105=rev
Log:
[WebAssembly] Add a __wasi__ target macro

This adds a `__wasi__` macro for the wasi OS, similar to `__linux__` etc. for
other OS's.

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

Modified:
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/lib/Basic/Targets/OSTargets.h
cfe/trunk/test/Preprocessor/init.c

Modified: cfe/trunk/lib/Basic/Targets.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=352105=352104=352105=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Thu Jan 24 13:05:11 2019
@@ -569,19 +569,27 @@ TargetInfo *AllocateTarget(const llvm::T
 Triple.getVendor() != llvm::Triple::UnknownVendor ||
 !Triple.isOSBinFormatWasm())
   return nullptr;
-if (Triple.getOS() != llvm::Triple::UnknownOS &&
-Triple.getOS() != llvm::Triple::WASI)
-  return nullptr;
-return new WebAssemblyOSTargetInfo(Triple, Opts);
+switch (Triple.getOS()) {
+  case llvm::Triple::WASI:
+return new WASITargetInfo(Triple, Opts);
+  case llvm::Triple::UnknownOS:
+return new WebAssemblyOSTargetInfo(Triple, 
Opts);
+  default:
+return nullptr;
+}
   case llvm::Triple::wasm64:
 if (Triple.getSubArch() != llvm::Triple::NoSubArch ||
 Triple.getVendor() != llvm::Triple::UnknownVendor ||
 !Triple.isOSBinFormatWasm())
   return nullptr;
-if (Triple.getOS() != llvm::Triple::UnknownOS &&
-Triple.getOS() != llvm::Triple::WASI)
-  return nullptr;
-return new WebAssemblyOSTargetInfo(Triple, Opts);
+switch (Triple.getOS()) {
+  case llvm::Triple::WASI:
+return new WASITargetInfo(Triple, Opts);
+  case llvm::Triple::UnknownOS:
+return new WebAssemblyOSTargetInfo(Triple, 
Opts);
+  default:
+return nullptr;
+}
 
   case llvm::Triple::renderscript32:
 return new LinuxTargetInfo(Triple, Opts);

Modified: cfe/trunk/lib/Basic/Targets/OSTargets.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/OSTargets.h?rev=352105=352104=352105=diff
==
--- cfe/trunk/lib/Basic/Targets/OSTargets.h (original)
+++ cfe/trunk/lib/Basic/Targets/OSTargets.h Thu Jan 24 13:05:11 2019
@@ -763,8 +763,9 @@ public:
 template 
 class LLVM_LIBRARY_VISIBILITY WebAssemblyOSTargetInfo
 : public OSTargetInfo {
+protected:
   void getOSDefines(const LangOptions , const llvm::Triple ,
-MacroBuilder ) const final {
+MacroBuilder ) const {
 // A common platform macro.
 if (Opts.POSIXThreads)
   Builder.defineMacro("_REENTRANT");
@@ -785,6 +786,21 @@ public:
   }
 };
 
+// WASI target
+template 
+class LLVM_LIBRARY_VISIBILITY WASITargetInfo
+: public WebAssemblyOSTargetInfo {
+  void getOSDefines(const LangOptions , const llvm::Triple ,
+MacroBuilder ) const final {
+WebAssemblyOSTargetInfo::getOSDefines(Opts, Triple, Builder);
+Builder.defineMacro("__wasi__");
+  }
+
+public:
+  explicit WASITargetInfo(const llvm::Triple , const TargetOptions 
)
+  : WebAssemblyOSTargetInfo(Triple, Opts) {}
+};
+
 } // namespace targets
 } // namespace clang
 #endif // LLVM_CLANG_LIB_BASIC_TARGETS_OSTARGETS_H

Modified: cfe/trunk/test/Preprocessor/init.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Preprocessor/init.c?rev=352105=352104=352105=diff
==
--- cfe/trunk/test/Preprocessor/init.c (original)
+++ cfe/trunk/test/Preprocessor/init.c Thu Jan 24 13:05:11 2019
@@ -9114,6 +9114,12 @@
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=wasm64-unknown-unknown \
 // RUN:   < /dev/null \
 // RUN:   | FileCheck -match-full-lines 
-check-prefixes=WEBASSEMBLY,WEBASSEMBLY64 %s
+// RUN: %clang_cc1 -E -dM -ffreestanding -triple=wasm32-unknown-wasi \
+// RUN:   < /dev/null \
+// RUN:   | FileCheck -match-full-lines 
-check-prefixes=WEBASSEMBLY,WEBASSEMBLY32,WEBASSEMBLY-WASI %s
+// RUN: %clang_cc1 -E -dM -ffreestanding -triple=wasm64-unknown-wasi \
+// RUN:   < /dev/null \
+// RUN:   | FileCheck -match-full-lines 
-check-prefixes=WEBASSEMBLY,WEBASSEMBLY64,WEBASSEMBLY-WASI %s
 //
 // WEBASSEMBLY32:#define _ILP32 1
 // WEBASSEMBLY32-NOT:#define _LP64
@@ -9468,6 +9474,7 @@
 // WEBASSEMBLY-NEXT:#define __llvm__ 1
 // WEBASSEMBLY-NOT:#define __unix
 // WEBASSEMBLY-NOT:#define __unix__
+// WEBASSEMBLY-WASI-NEXT:#define __wasi__ 1
 // WEBASSEMBLY-NOT:#define __wasm_simd128__
 // WEBASSEMBLY-NOT:#define __wasm_simd256__
 // WEBASSEMBLY-NOT:#define __wasm_simd512__


___
cfe-commits mailing list
cfe-commits@lists.llvm.org

[PATCH] D56624: [Sanitizers] UBSan unreachable incompatible with ASan in the presence of `noreturn` calls

[Vedant Kumar via Phabricator via cfe-commits]

vsk added a comment.

In D56624#1369940 , @yln wrote:

> Note that all of this currently only matters when compiling with 
> `-fsanitize=unreachable`. The following discussion is within the context of 
> the current implementation: UBSan removes the `noreturn` so it can instrument 
> `unreachable` without the added instrumentation being optimized away. Maybe 
> we should take a step back and ask if that is the right approach at all?
>
> In D56624#1369795 , @vsk wrote:
>
> > Because "expect_noreturn" calls are allowed to return, the compiler must 
> > behave as they could. In particular, this means that unpoisoning the stack 
> > before expect_noreturn calls (given the current semantics) is premature.
> >
> > Put another way, a frontend author may (understandably, but mistakenly!) 
> > attach expect_noreturn to calls which they expect to be cold.
>
>
> I think about this differently. Yes, most noreturn functions are also cold, 
> e.g., `abort`, but not necessarily, e.g., calls to `longjmp` do not 
> necessarily have to be. Why would it be okay to attach expect_noreturn 
> instead of cold?


It would be okay by definition, because it would be allowed by the proposed IR 
semantics.

> Why do we think that this is an easy-to-make mistake?

I don't think that's the right question. Rather, we should ask: why is it 
acceptable to define semantics in a way that makes the mistake possible?

My thinking on this is: it's not acceptable, because a narrower change (say, 
introducing a sanitizer_noreturn attribute) would address the issue without as 
much potential for abuse.

> Can we agree on the following?
>  "It is orthogonal on the language level, but seems to be redundant in terms 
> of the optimizer. Since LLVM IR's main purpose it support the optimizer, this 
> is a strong argument against the general purpose attribute."

I'm making a more neutral point: that expect_noreturn conflates different 
concerns -- optimization and sanitizer correctness. I'm not making a claim 
about what the main purpose of IR is.

>> That would regress ASan coverage.
> 
> You talk specifically about cases of misuses of the attribute, right?
>  In the context of the current issue with UBSan the possibility for false 
> negative is not too much of a regression: it only occurs when UBSan is going 
> to diagnose an "unreachable error" anyways.
> 
> So the main point is whether or not to use a "general purpose" attribute or a 
> "narrow purpose" attribute/intrinsic. My understanding is that you list the 
> following points as arguments against general purpose. Is my understanding 
> accurate?
> 
> 1. Potential misuse can regress ASan coverage
> 2. Complicates optimizer
> 
>   Narrow purpose: No potential misuses, and optimizer can simply ignore it.

Yes, I think this is a fair summary, thanks :).

> Initially I proposed a narrow purpose attribute, but while iterating on this 
> revision changed it to be general purpose. @eugenis 
>  Now, I have a slight preference for general purpose: I don't think 1. is a 
> big issue (but then again, I have no experience here),

Changes to the IR semantics have hard-to-predict ripple effects on many, many 
other projects. It pays to be conservative in this area.

>   and 2. it is always correct for the optimizer to continue ignoring the 
> attribute (current status).
> 
> Actually, 2. also encompasses the potential upside: a more complicated 
> optimizer that takes advantage of the attribute to do additional 
> optimizations.

I'm having a hard time thinking of any optimizations based on expect_noreturn 
which aren't already enabled by the cold attribute. What do you have in mind?


Repository:
  rL LLVM

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

https://reviews.llvm.org/D56624



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

[PATCH] D57114: Remove Expr sugar decorating the CXXUuidofExpr node.

[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!




Comment at: lib/Sema/SemaTemplate.cpp:6311
 if (isa(E)) {
-  Converted = TemplateArgument(ArgResult.get());
+  Converted = TemplateArgument(ArgResult.get()->IgnoreImpCasts());
   break;

void wrote:
> aaron.ballman wrote:
> > `IgnoreParenImpCasts()` or are the paren expressions of value?
> I want to make this a minimal change. Richard was okay with just the implicit 
> casts. I'm not relaly qualified in this part of the code to say that we 
> should also include parentheses in this. I'll leave that up to you and 
> Richard.
> 
>   https://bugs.llvm.org/show_bug.cgi?id=40395
> I want to make this a minimal change. Richard was okay with just the implicit 
> casts. I'm not relaly qualified in this part of the code to say that we 
> should also include parentheses in this. I'll leave that up to you and 
> Richard.

Ah, thank you for the link, that helps!

>  I was looking at which of the Expr::Ignore* function to use for something 
> else and it seems that IgnoreParenImpCasts() is *not* equivalent to doing 
> IgnoreParens() + IgnoreImpCasts() until reaching a fixed point.

That is surprising, and good to know!


Repository:
  rC Clang

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

https://reviews.llvm.org/D57114



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

r352102 - Add a triple to this test so it passes for targets where alignof(double)

[Richard Smith via cfe-commits]

Author: rsmith
Date: Thu Jan 24 12:52:56 2019
New Revision: 352102

URL: http://llvm.org/viewvc/llvm-project?rev=352102=rev
Log:
Add a triple to this test so it passes for targets where alignof(double)
really should be equal to alignof(float).

Modified:
cfe/trunk/test/CXX/dcl.dcl/dcl.attr/dcl.align/p8.cpp

Modified: cfe/trunk/test/CXX/dcl.dcl/dcl.attr/dcl.align/p8.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CXX/dcl.dcl/dcl.attr/dcl.align/p8.cpp?rev=352102=352101=352102=diff
==
--- cfe/trunk/test/CXX/dcl.dcl/dcl.attr/dcl.align/p8.cpp (original)
+++ cfe/trunk/test/CXX/dcl.dcl/dcl.attr/dcl.align/p8.cpp Thu Jan 24 12:52:56 
2019
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -std=c++11 -verify %s
+// RUN: %clang_cc1 -std=c++11 -verify %s -triple x86_64-linux-gnu
 
 alignas(double) void f(); // expected-error {{'alignas' attribute only applies 
to variables, data members and tag types}}
 alignas(double) unsigned char c[sizeof(double)]; // expected-note {{previous}}


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

[PATCH] D56226: [clang-format] square parens that are followed by '=' are not Objective-C message sends

[Alex Lorenz via Phabricator via cfe-commits]

arphaman updated this revision to Diff 183372.
arphaman marked 3 inline comments as done.
arphaman added a comment.

Update for Ben's comments.


Repository:
  rC Clang

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

https://reviews.llvm.org/D56226

Files:
  lib/Format/TokenAnnotator.cpp
  unittests/Format/FormatTestObjC.cpp


Index: unittests/Format/FormatTestObjC.cpp
===
--- unittests/Format/FormatTestObjC.cpp
+++ unittests/Format/FormatTestObjC.cpp
@@ -165,6 +165,20 @@
   EXPECT_EQ(FormatStyle::LK_ObjC, Style->Language);
 }
 
+TEST(FormatTestObjCStyle, AvoidDetectingDesignatedInitializersAsObjCInHeaders) 
{
+  auto Style = getStyle("LLVM", "a.h", "none",
+"static const char *names[] = {[0] = \"foo\",\n"
+"[kBar] = \"bar\"};");
+  ASSERT_TRUE((bool)Style);
+  EXPECT_EQ(FormatStyle::LK_Cpp, Style->Language);
+
+  Style = getStyle("LLVM", "a.h", "none",
+   "static const char *names[] = {[0] EQ \"foo\",\n"
+   "[kBar] EQ \"bar\"};");
+  ASSERT_TRUE((bool)Style);
+  EXPECT_EQ(FormatStyle::LK_Cpp, Style->Language);
+}
+
 TEST_F(FormatTestObjC, FormatObjCTryCatch) {
   verifyFormat("@try {\n"
"  f();\n"
Index: lib/Format/TokenAnnotator.cpp
===
--- lib/Format/TokenAnnotator.cpp
+++ lib/Format/TokenAnnotator.cpp
@@ -494,9 +494,14 @@
   if (CurrentToken->is(tok::r_square)) {
 if (IsCpp11AttributeSpecifier)
   CurrentToken->Type = TT_AttributeSquare;
-else if (CurrentToken->Next && CurrentToken->Next->is(tok::l_paren) &&
+else if (((CurrentToken->Next &&
+   CurrentToken->Next->is(tok::l_paren)) ||
+  (CurrentToken->Previous &&
+   CurrentToken->Previous->Previous == Left)) &&
  Left->is(TT_ObjCMethodExpr)) {
-  // An ObjC method call is rarely followed by an open parenthesis.
+  // An ObjC method call is rarely followed by an open parenthesis. It
+  // also can't be composed of just one token, unless it's a macro that
+  // will be expanded to more tokens.
   // FIXME: Do we incorrectly label ":" with this?
   StartsObjCMethodExpr = false;
   Left->Type = TT_Unknown;


Index: unittests/Format/FormatTestObjC.cpp
===
--- unittests/Format/FormatTestObjC.cpp
+++ unittests/Format/FormatTestObjC.cpp
@@ -165,6 +165,20 @@
   EXPECT_EQ(FormatStyle::LK_ObjC, Style->Language);
 }
 
+TEST(FormatTestObjCStyle, AvoidDetectingDesignatedInitializersAsObjCInHeaders) {
+  auto Style = getStyle("LLVM", "a.h", "none",
+"static const char *names[] = {[0] = \"foo\",\n"
+"[kBar] = \"bar\"};");
+  ASSERT_TRUE((bool)Style);
+  EXPECT_EQ(FormatStyle::LK_Cpp, Style->Language);
+
+  Style = getStyle("LLVM", "a.h", "none",
+   "static const char *names[] = {[0] EQ \"foo\",\n"
+   "[kBar] EQ \"bar\"};");
+  ASSERT_TRUE((bool)Style);
+  EXPECT_EQ(FormatStyle::LK_Cpp, Style->Language);
+}
+
 TEST_F(FormatTestObjC, FormatObjCTryCatch) {
   verifyFormat("@try {\n"
"  f();\n"
Index: lib/Format/TokenAnnotator.cpp
===
--- lib/Format/TokenAnnotator.cpp
+++ lib/Format/TokenAnnotator.cpp
@@ -494,9 +494,14 @@
   if (CurrentToken->is(tok::r_square)) {
 if (IsCpp11AttributeSpecifier)
   CurrentToken->Type = TT_AttributeSquare;
-else if (CurrentToken->Next && CurrentToken->Next->is(tok::l_paren) &&
+else if (((CurrentToken->Next &&
+   CurrentToken->Next->is(tok::l_paren)) ||
+  (CurrentToken->Previous &&
+   CurrentToken->Previous->Previous == Left)) &&
  Left->is(TT_ObjCMethodExpr)) {
-  // An ObjC method call is rarely followed by an open parenthesis.
+  // An ObjC method call is rarely followed by an open parenthesis. It
+  // also can't be composed of just one token, unless it's a macro that
+  // will be expanded to more tokens.
   // FIXME: Do we incorrectly label ":" with this?
   StartsObjCMethodExpr = false;
   Left->Type = TT_Unknown;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56411: [CUDA][HIP][Sema] Fix template kernel with function as template parameter

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In D56411#1369906 , @yaxunl wrote:

> In D56411#1365745 , @rjmccall wrote:
>
> > In D56411#1365727 , @yaxunl wrote:
> >
> > > In D56411#1360010 , @rjmccall 
> > > wrote:
> > >
> > > > I think the diagnostic should come during instantiation when you find 
> > > > an evaluated use of a host function within a device function.
> > >
> > >
> > > It seems the body of function template is checked only during parsing of 
> > > the definition of the template itself. When a function
> > >  template is instantiated, the body of the instantiated function is not 
> > > checked again.
> >
> >
> > No, that's not correct.  However, it's checked somewhat differently, and 
> > it's possible that the existing diagnostic is not set up to fire along all 
> > common paths.  Try moving the diagnostic to `MarkFunctionReferenced`, and 
> > note that `OdrUse` will be `false` in all the unevaluated contexts.
>
>
> I got regression in the folowing test when checking CheckCUDACall in 
> MarkFunctionReferenced:
>
>   typedef struct {
> template  void *foo() { return 0; }
>   
> void foo() {
>   foo<0>();
> }
>   } A;
>   
>   
>
> Basically clang does not allow getting linkage of foo<0> before 
> ActOnTypedefDeclarator, quoting SemaDecl.cpp line 4171
>
>   // If we've already computed linkage for the anonymous tag, then
>   // adding a typedef name for the anonymous decl can change that
>   // linkage, which might be a serious problem.  Diagnose this as
>   // unsupported and ignore the typedef name.  TODO: we should
>   // pursue this as a language defect and establish a formal rule
>   // for how to handle it.
>   if (TagFromDeclSpec->hasLinkageBeenComputed()) {
> Diag(NewTD->getLocation(), diag::err_typedef_changes_linkage);
>   
>   
>
> However, CheckCUDACall needs to call GetGVALinkageForFunction on the callee 
> to know if it will be emitted,
>  which causes the linkage of the anonymous struct to be cached and triggers 
> err_typedef_changes_linkage.


Sounds like you were missing a case in the diagnostic, then.

Can you check whether you're in an `inline` function before you check the 
linkage?  It's a bit of a hack but it might work.  You have logic to look for 
evaluated references in used inline functions anyway, right?


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

https://reviews.llvm.org/D56411



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

[PATCH] D57075: [ObjC] For type substitution in generics use a regular recursive type visitor.

[Erik Pilkington via Phabricator via cfe-commits]

erik.pilkington added inline comments.



Comment at: clang/lib/AST/Type.cpp:1295
+
+  QualType VisitObjCObjectType(const ObjCObjectType *objType) {
+if (!objType->isKindOfType())

Does this works with type sugar? i.e. previously calling 
`Ty->getAs()` would have stripped through `TypedefType`, but 
its not obvious to me that this traversal is doing the right thing for that 
case.


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

https://reviews.llvm.org/D57075



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

[PATCH] D56624: [Sanitizers] UBSan unreachable incompatible with ASan in the presence of `noreturn` calls

[Julian Lettner via Phabricator via cfe-commits]

yln added a comment.

Note that all of this currently only matters when compiling with 
`-fsanitize=unreachable`. The following discussion is within the context of the 
current implementation: UBSan removes the `noreturn` so it can instrument 
`unreachable` without the added instrumentation being optimized away. Maybe we 
should take a step back and ask if that is the right approach at all?

In D56624#1369795 , @vsk wrote:

> Because "expect_noreturn" calls are allowed to return, the compiler must 
> behave as they could. In particular, this means that unpoisoning the stack 
> before expect_noreturn calls (given the current semantics) is premature.
>
> Put another way, a frontend author may (understandably, but mistakenly!) 
> attach expect_noreturn to calls which they expect to be cold.


I think about this differently. Yes, most noreturn functions are also cold, 
e.g., `abort`, but not necessarily, e.g., calls to `longjmp` do not necessarily 
have to be. Why would it be okay to attach expect_noreturn instead of cold? Why 
do we think that this is an easy-to-make mistake? Have people accidentally put 
noreturn on cold functions before?
Can we agree on the following?
"It is orthogonal on the language level, but seems to be redundant in terms of 
the optimizer. Since LLVM IR's main purpose it support the optimizer, this is a 
strong argument against the general purpose attribute."

> That would regress ASan coverage.

You talk specifically about cases of misuses of the attribute, right?
In the context of the current issue with UBSan the possibility for false 
negative is not too much of a regression: it only occurs when UBSan is going to 
diagnose an "unreachable error" anyways.

So the main point is whether or not to use a "general purpose" attribute or a 
"narrow purpose" attribute/intrinsic. My understanding is that you list the 
following points as arguments against general purpose. Is my understanding 
accurate?

1. Potential misuse can regress ASan coverage
2. Complicates optimizer

Narrow purpose: No potential misuses, and optimizer can simply ignore it.

Initially I proposed a narrow purpose attribute, but while iterating on this 
revision changed it to be general purpose. @eugenis 
Now, I have a slight preference for general purpose: I don't think 1. is a big 
issue (but then again, I have no experience here),  and 2. it is always correct 
for the optimizer to continue ignoring the attribute (current status).
Actually, 2. also encompasses the potential upside: a more complicated 
optimizer that takes advantage of the attribute to do additional optimizations.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D56624



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

[PATCH] D57104: [AST] Pack GenericSelectionExpr

[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 D57104#1369885 , @riccibruno wrote:

> In D57104#1369864 , @steveire wrote:
>
> > Thanks, but I don't see the factored out changes in the repo. Are you going 
> > to commit those first?
> >
> > Also, please factor out the introduction and use of `::Create`. It seems to 
> > be unrelated to the trailing objects change.
>
>
> I was planning to yes. I don't agree that the introduction of `Create` is 
> unrelated. It is very much part of the changes
>  since the introduction of the trailing objects implies the need to do a 
> placement new, which implies the need to
>  use a `Create` function. Also see pretty much every other patch which 
> introduced trailing objects for the
>  statement/expression nodes.


+1, the changes to the `Create` methods are germane to this review.

This LGTM, thank you for working on it!


Repository:
  rC Clang

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

https://reviews.llvm.org/D57104



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

[PATCH] D57057: [clangd] Log clang-tidy configuration, NFC

[Jan Korous via Phabricator via cfe-commits]

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

LGTM


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D57057



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

[PATCH] D56411: [CUDA][HIP][Sema] Fix template kernel with function as template parameter

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

In D56411#1365745 , @rjmccall wrote:

> In D56411#1365727 , @yaxunl wrote:
>
> > In D56411#1360010 , @rjmccall 
> > wrote:
> >
> > > I think the diagnostic should come during instantiation when you find an 
> > > evaluated use of a host function within a device function.
> >
> >
> > It seems the body of function template is checked only during parsing of 
> > the definition of the template itself. When a function
> >  template is instantiated, the body of the instantiated function is not 
> > checked again.
>
>
> No, that's not correct.  However, it's checked somewhat differently, and it's 
> possible that the existing diagnostic is not set up to fire along all common 
> paths.  Try moving the diagnostic to `MarkFunctionReferenced`, and note that 
> `OdrUse` will be `false` in all the unevaluated contexts.


I got regression in the folowing test when checking CheckCUDACall in 
MarkFunctionReferenced:

  typedef struct {
template  void *foo() { return 0; }
  
void foo() {
  foo<0>();
}
  } A;

Basically clang does not allow getting linkage of foo<0> before 
ActOnTypedefDeclarator, quoting SemaDecl.cpp line 4171

  // If we've already computed linkage for the anonymous tag, then
  // adding a typedef name for the anonymous decl can change that
  // linkage, which might be a serious problem.  Diagnose this as
  // unsupported and ignore the typedef name.  TODO: we should
  // pursue this as a language defect and establish a formal rule
  // for how to handle it.
  if (TagFromDeclSpec->hasLinkageBeenComputed()) {
Diag(NewTD->getLocation(), diag::err_typedef_changes_linkage);

However, CheckCUDACall needs to call GetGVALinkageForFunction on the callee to 
know if it will be emitted,
which causes the linkage of the anonymous struct to be cached and triggers 
err_typedef_changes_linkage.


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

https://reviews.llvm.org/D56411



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

[PATCH] D57154: [WebAssembly] Support __float128

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rC352100: [WebAssembly] Support __float128 (authored by djg, 
committed by ).
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D57154?vs=183302=183369#toc

Repository:
  rC Clang

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

https://reviews.llvm.org/D57154

Files:
  lib/Basic/Targets/OSTargets.h
  test/Preprocessor/init.c


Index: test/Preprocessor/init.c
===
--- test/Preprocessor/init.c
+++ test/Preprocessor/init.c
@@ -9159,6 +9159,7 @@
 // WEBASSEMBLY-NEXT:#define __DECIMAL_DIG__ __LDBL_DECIMAL_DIG__
 // WEBASSEMBLY-NOT:#define __ELF__
 // WEBASSEMBLY-NEXT:#define __FINITE_MATH_ONLY__ 0
+// WEBASSEMBLY-NEXT:#define __FLOAT128__ 1
 // WEBASSEMBLY-NEXT:#define __FLT16_DECIMAL_DIG__ 5
 // WEBASSEMBLY-NEXT:#define __FLT16_DENORM_MIN__ 5.9604644775390625e-8F16
 // WEBASSEMBLY-NEXT:#define __FLT16_DIG__ 3
Index: lib/Basic/Targets/OSTargets.h
===
--- lib/Basic/Targets/OSTargets.h
+++ lib/Basic/Targets/OSTargets.h
@@ -771,6 +771,8 @@
 // Follow g++ convention and predefine _GNU_SOURCE for C++.
 if (Opts.CPlusPlus)
   Builder.defineMacro("_GNU_SOURCE");
+// Indicate that we have __float128.
+Builder.defineMacro("__FLOAT128__");
   }
 
 public:
@@ -779,6 +781,7 @@
   : OSTargetInfo(Triple, Opts) {
 this->MCountName = "__mcount";
 this->TheCXXABI.set(TargetCXXABI::WebAssembly);
+this->HasFloat128 = true;
   }
 };
 


Index: test/Preprocessor/init.c
===
--- test/Preprocessor/init.c
+++ test/Preprocessor/init.c
@@ -9159,6 +9159,7 @@
 // WEBASSEMBLY-NEXT:#define __DECIMAL_DIG__ __LDBL_DECIMAL_DIG__
 // WEBASSEMBLY-NOT:#define __ELF__
 // WEBASSEMBLY-NEXT:#define __FINITE_MATH_ONLY__ 0
+// WEBASSEMBLY-NEXT:#define __FLOAT128__ 1
 // WEBASSEMBLY-NEXT:#define __FLT16_DECIMAL_DIG__ 5
 // WEBASSEMBLY-NEXT:#define __FLT16_DENORM_MIN__ 5.9604644775390625e-8F16
 // WEBASSEMBLY-NEXT:#define __FLT16_DIG__ 3
Index: lib/Basic/Targets/OSTargets.h
===
--- lib/Basic/Targets/OSTargets.h
+++ lib/Basic/Targets/OSTargets.h
@@ -771,6 +771,8 @@
 // Follow g++ convention and predefine _GNU_SOURCE for C++.
 if (Opts.CPlusPlus)
   Builder.defineMacro("_GNU_SOURCE");
+// Indicate that we have __float128.
+Builder.defineMacro("__FLOAT128__");
   }
 
 public:
@@ -779,6 +781,7 @@
   : OSTargetInfo(Triple, Opts) {
 this->MCountName = "__mcount";
 this->TheCXXABI.set(TargetCXXABI::WebAssembly);
+this->HasFloat128 = true;
   }
 };
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56561: [Preprocessor] For missing file in framework add note about framework location.

[Jan Korous via Phabricator via cfe-commits]

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

LGTM with nits about doxygen annotations.




Comment at: clang/include/clang/Lex/DirectoryLookup.h:175
+  /// \param [out] IsFrameworkFound For a framework directory set to true if
+  /// specified '.framework' directory is found.
+  ///

We might make this easier to understand by explaining where/how the 
'.framework' directory is specified.



Comment at: clang/include/clang/Lex/HeaderSearch.h:396
+  /// \param IsFrameworkFound If non-null, will be set to true for a framework
+  /// include and if corresponding '.framework' directory was found. Doesn't
+  /// guarantee the requested file is found.

We might try to explain what exactly is meant by corresponding .framework 
directory.


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

https://reviews.llvm.org/D56561



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

r352100 - [WebAssembly] Support __float128

[Dan Gohman via cfe-commits]

Author: djg
Date: Thu Jan 24 12:33:28 2019
New Revision: 352100

URL: http://llvm.org/viewvc/llvm-project?rev=352100=rev
Log:
[WebAssembly] Support __float128

This enables support for the "__float128" keyword.

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

Modified:
cfe/trunk/lib/Basic/Targets/OSTargets.h
cfe/trunk/test/Preprocessor/init.c

Modified: cfe/trunk/lib/Basic/Targets/OSTargets.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/OSTargets.h?rev=352100=352099=352100=diff
==
--- cfe/trunk/lib/Basic/Targets/OSTargets.h (original)
+++ cfe/trunk/lib/Basic/Targets/OSTargets.h Thu Jan 24 12:33:28 2019
@@ -771,6 +771,8 @@ class LLVM_LIBRARY_VISIBILITY WebAssembl
 // Follow g++ convention and predefine _GNU_SOURCE for C++.
 if (Opts.CPlusPlus)
   Builder.defineMacro("_GNU_SOURCE");
+// Indicate that we have __float128.
+Builder.defineMacro("__FLOAT128__");
   }
 
 public:
@@ -779,6 +781,7 @@ public:
   : OSTargetInfo(Triple, Opts) {
 this->MCountName = "__mcount";
 this->TheCXXABI.set(TargetCXXABI::WebAssembly);
+this->HasFloat128 = true;
   }
 };
 

Modified: cfe/trunk/test/Preprocessor/init.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Preprocessor/init.c?rev=352100=352099=352100=diff
==
--- cfe/trunk/test/Preprocessor/init.c (original)
+++ cfe/trunk/test/Preprocessor/init.c Thu Jan 24 12:33:28 2019
@@ -9159,6 +9159,7 @@
 // WEBASSEMBLY-NEXT:#define __DECIMAL_DIG__ __LDBL_DECIMAL_DIG__
 // WEBASSEMBLY-NOT:#define __ELF__
 // WEBASSEMBLY-NEXT:#define __FINITE_MATH_ONLY__ 0
+// WEBASSEMBLY-NEXT:#define __FLOAT128__ 1
 // WEBASSEMBLY-NEXT:#define __FLT16_DECIMAL_DIG__ 5
 // WEBASSEMBLY-NEXT:#define __FLT16_DENORM_MIN__ 5.9604644775390625e-8F16
 // WEBASSEMBLY-NEXT:#define __FLT16_DIG__ 3


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

r352099 - [WebAssembly] Factor commonality between wasm32 and wasm64 in test/Preprocessor/init.c

[Dan Gohman via cfe-commits]

Author: djg
Date: Thu Jan 24 12:31:11 2019
New Revision: 352099

URL: http://llvm.org/viewvc/llvm-project?rev=352099=rev
Log:
[WebAssembly] Factor commonality between wasm32 and wasm64 in 
test/Preprocessor/init.c

Use the -check-prefixes= feature to merge most of the WEBASSEMBLY32 and
WEBASSEMBLY64 test checks into a shared WEBASSEMBLY test check.

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

Modified:
cfe/trunk/test/Preprocessor/init.c

Modified: cfe/trunk/test/Preprocessor/init.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Preprocessor/init.c?rev=352099=352098=352099=diff
==
--- cfe/trunk/test/Preprocessor/init.c (original)
+++ cfe/trunk/test/Preprocessor/init.c Thu Jan 24 12:31:11 2019
@@ -9110,667 +9110,376 @@
 //
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=wasm32-unknown-unknown \
 // RUN:   < /dev/null \
-// RUN:   | FileCheck -match-full-lines -check-prefix=WEBASSEMBLY32 %s
+// RUN:   | FileCheck -match-full-lines 
-check-prefixes=WEBASSEMBLY,WEBASSEMBLY32 %s
+// RUN: %clang_cc1 -E -dM -ffreestanding -triple=wasm64-unknown-unknown \
+// RUN:   < /dev/null \
+// RUN:   | FileCheck -match-full-lines 
-check-prefixes=WEBASSEMBLY,WEBASSEMBLY64 %s
 //
 // WEBASSEMBLY32:#define _ILP32 1
 // WEBASSEMBLY32-NOT:#define _LP64
-// WEBASSEMBLY32-NEXT:#define __ATOMIC_ACQUIRE 2
-// WEBASSEMBLY32-NEXT:#define __ATOMIC_ACQ_REL 4
-// WEBASSEMBLY32-NEXT:#define __ATOMIC_CONSUME 1
-// WEBASSEMBLY32-NEXT:#define __ATOMIC_RELAXED 0
-// WEBASSEMBLY32-NEXT:#define __ATOMIC_RELEASE 3
-// WEBASSEMBLY32-NEXT:#define __ATOMIC_SEQ_CST 5
-// WEBASSEMBLY32-NEXT:#define __BIGGEST_ALIGNMENT__ 16
-// WEBASSEMBLY32-NEXT:#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
-// WEBASSEMBLY32-NEXT:#define __CHAR16_TYPE__ unsigned short
-// WEBASSEMBLY32-NEXT:#define __CHAR32_TYPE__ unsigned int
-// WEBASSEMBLY32-NEXT:#define __CHAR_BIT__ 8
-// WEBASSEMBLY32-NOT:#define __CHAR_UNSIGNED__
-// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_BOOL_LOCK_FREE 2
-// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_CHAR16_T_LOCK_FREE 2
-// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_CHAR32_T_LOCK_FREE 2
-// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_CHAR_LOCK_FREE 2
-// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_INT_LOCK_FREE 2
-// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_LLONG_LOCK_FREE 2
-// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_LONG_LOCK_FREE 2
-// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_POINTER_LOCK_FREE 2
-// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_SHORT_LOCK_FREE 2
-// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_WCHAR_T_LOCK_FREE 2
-// WEBASSEMBLY32-NEXT:#define __CONSTANT_CFSTRINGS__ 1
-// WEBASSEMBLY32-NEXT:#define __DBL_DECIMAL_DIG__ 17
-// WEBASSEMBLY32-NEXT:#define __DBL_DENORM_MIN__ 4.9406564584124654e-324
-// WEBASSEMBLY32-NEXT:#define __DBL_DIG__ 15
-// WEBASSEMBLY32-NEXT:#define __DBL_EPSILON__ 2.2204460492503131e-16
-// WEBASSEMBLY32-NEXT:#define __DBL_HAS_DENORM__ 1
-// WEBASSEMBLY32-NEXT:#define __DBL_HAS_INFINITY__ 1
-// WEBASSEMBLY32-NEXT:#define __DBL_HAS_QUIET_NAN__ 1
-// WEBASSEMBLY32-NEXT:#define __DBL_MANT_DIG__ 53
-// WEBASSEMBLY32-NEXT:#define __DBL_MAX_10_EXP__ 308
-// WEBASSEMBLY32-NEXT:#define __DBL_MAX_EXP__ 1024
-// WEBASSEMBLY32-NEXT:#define __DBL_MAX__ 1.7976931348623157e+308
-// WEBASSEMBLY32-NEXT:#define __DBL_MIN_10_EXP__ (-307)
-// WEBASSEMBLY32-NEXT:#define __DBL_MIN_EXP__ (-1021)
-// WEBASSEMBLY32-NEXT:#define __DBL_MIN__ 2.2250738585072014e-308
-// WEBASSEMBLY32-NEXT:#define __DECIMAL_DIG__ __LDBL_DECIMAL_DIG__
-// WEBASSEMBLY32-NOT:#define __ELF__
-// WEBASSEMBLY32-NEXT:#define __FINITE_MATH_ONLY__ 0
-// WEBASSEMBLY32:#define __FLT_DECIMAL_DIG__ 9
-// WEBASSEMBLY32-NEXT:#define __FLT_DENORM_MIN__ 1.40129846e-45F
-// WEBASSEMBLY32-NEXT:#define __FLT_DIG__ 6
-// WEBASSEMBLY32-NEXT:#define __FLT_EPSILON__ 1.19209290e-7F
-// WEBASSEMBLY32-NEXT:#define __FLT_EVAL_METHOD__ 0
-// WEBASSEMBLY32-NEXT:#define __FLT_HAS_DENORM__ 1
-// WEBASSEMBLY32-NEXT:#define __FLT_HAS_INFINITY__ 1
-// WEBASSEMBLY32-NEXT:#define __FLT_HAS_QUIET_NAN__ 1
-// WEBASSEMBLY32-NEXT:#define __FLT_MANT_DIG__ 24
-// WEBASSEMBLY32-NEXT:#define __FLT_MAX_10_EXP__ 38
-// WEBASSEMBLY32-NEXT:#define __FLT_MAX_EXP__ 128
-// WEBASSEMBLY32-NEXT:#define __FLT_MAX__ 3.40282347e+38F
-// WEBASSEMBLY32-NEXT:#define __FLT_MIN_10_EXP__ (-37)
-// WEBASSEMBLY32-NEXT:#define __FLT_MIN_EXP__ (-125)
-// WEBASSEMBLY32-NEXT:#define __FLT_MIN__ 1.17549435e-38F
-// WEBASSEMBLY32-NEXT:#define __FLT_RADIX__ 2
-// WEBASSEMBLY32-NEXT:#define __GCC_ATOMIC_BOOL_LOCK_FREE 2
-// WEBASSEMBLY32-NEXT:#define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 2
-// WEBASSEMBLY32-NEXT:#define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2
-// WEBASSEMBLY32-NEXT:#define __GCC_ATOMIC_CHAR_LOCK_FREE 2
-// WEBASSEMBLY32-NEXT:#define __GCC_ATOMIC_INT_LOCK_FREE 2
-// WEBASSEMBLY32-NEXT:#define __GCC_ATOMIC_LLONG_LOCK_FREE 2
-// WEBASSEMBLY32-NEXT:#define __GCC_ATOMIC_LONG_LOCK_FREE 2
-// WEBASSEMBLY32-NEXT:#define 

[PATCH] D57104: [AST] Pack GenericSelectionExpr

[Bruno Ricci via Phabricator via cfe-commits]

riccibruno added a comment.

In D57104#1369864 , @steveire wrote:

> Thanks, but I don't see the factored out changes in the repo. Are you going 
> to commit those first?
>
> Also, please factor out the introduction and use of `::Create`. It seems to 
> be unrelated to the trailing objects change.


I was planning to yes. I don't agree that the introduction of `Create` is 
unrelated. It is very much part of the changes
since the introduction of the trailing objects implies the need to do a 
placement new, which implies the need to
use a `Create` function. Also see pretty much every other patch which 
introduced trailing objects for the
statement/expression nodes.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57104



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

LLVM buildmaster will be restarted tonight

[Galina Kistanova via cfe-commits]

 Hello everyone,

LLVM buildmaster will be updated and restarted after 6PM Pacific time today.

Thanks

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

[PATCH] D57104: [AST] Pack GenericSelectionExpr

[Stephen Kelly via Phabricator via cfe-commits]

steveire added a comment.

Thanks, but I don't see the factored out changes in the repo. Are you going to 
commit those first?

Also, please factor out the introduction and use of `::Create`. It seems to be 
unrelated to the trailing objects change.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57104



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

r352090 - [NFC][clang] Test updates for CreateAlignmentAssumption() changes in D54653

[Roman Lebedev via cfe-commits]

Author: lebedevri
Date: Thu Jan 24 11:32:49 2019
New Revision: 352090

URL: http://llvm.org/viewvc/llvm-project?rev=352090=rev
Log:
[NFC][clang] Test updates for CreateAlignmentAssumption() changes in D54653

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

Modified:
cfe/trunk/test/CodeGen/alloc-align-attr.c

cfe/trunk/test/CodeGen/catch-alignment-assumption-attribute-alloc_align-on-function-variable.cpp

Modified: cfe/trunk/test/CodeGen/alloc-align-attr.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/alloc-align-attr.c?rev=352090=352089=352090=diff
==
--- cfe/trunk/test/CodeGen/alloc-align-attr.c (original)
+++ cfe/trunk/test/CodeGen/alloc-align-attr.c Thu Jan 24 11:32:49 2019
@@ -6,11 +6,9 @@ __INT32_TYPE__*m1(__INT32_TYPE__ i) __at
 __INT32_TYPE__ test1(__INT32_TYPE__ a) {
 // CHECK: define i32 @test1
   return *m1(a);
-// CHECK: call i32* @m1(i32 [[PARAM1:%[^\)]+]]) 
-// CHECK: [[ALIGNCAST1:%.+]] = sext i32 [[PARAM1]] to i64
-// CHECK: [[ISPOS1:%.+]] = icmp sgt i64 [[ALIGNCAST1]], 0
-// CHECK: [[POSMASK1:%.+]] = sub i64 [[ALIGNCAST1]], 1
-// CHECK: [[MASK1:%.+]] = select i1 [[ISPOS1]], i64 [[POSMASK1]], i64 0
+// CHECK: call i32* @m1(i32 [[PARAM1:%[^\)]+]])
+// CHECK: [[ALIGNCAST1:%.+]] = zext i32 [[PARAM1]] to i64
+// CHECK: [[MASK1:%.+]] = sub i64 [[ALIGNCAST1]], 1
 // CHECK: [[PTRINT1:%.+]] = ptrtoint
 // CHECK: [[MASKEDPTR1:%.+]] = and i64 [[PTRINT1]], [[MASK1]]
 // CHECK: [[MASKCOND1:%.+]] = icmp eq i64 [[MASKEDPTR1]], 0
@@ -22,10 +20,8 @@ __INT32_TYPE__ test2(__SIZE_TYPE__ a) {
   return *m1(a);
 // CHECK: [[CONV2:%.+]] = trunc i64 %{{.+}} to i32
 // CHECK: call i32* @m1(i32 [[CONV2]])
-// CHECK: [[ALIGNCAST2:%.+]] = sext i32 [[CONV2]] to i64
-// CHECK: [[ISPOS2:%.+]] = icmp sgt i64 [[ALIGNCAST2]], 0
-// CHECK: [[POSMASK2:%.+]] = sub i64 [[ALIGNCAST2]], 1
-// CHECK: [[MASK2:%.+]] = select i1 [[ISPOS2]], i64 [[POSMASK2]], i64 0
+// CHECK: [[ALIGNCAST2:%.+]] = zext i32 [[CONV2]] to i64
+// CHECK: [[MASK2:%.+]] = sub i64 [[ALIGNCAST2]], 1
 // CHECK: [[PTRINT2:%.+]] = ptrtoint
 // CHECK: [[MASKEDPTR2:%.+]] = and i64 [[PTRINT2]], [[MASK2]]
 // CHECK: [[MASKCOND2:%.+]] = icmp eq i64 [[MASKEDPTR2]], 0
@@ -39,9 +35,7 @@ __INT32_TYPE__ test3(__INT32_TYPE__ a) {
   return *m2(a);
 // CHECK: [[CONV3:%.+]] = sext i32 %{{.+}} to i64
 // CHECK: call i32* @m2(i64 [[CONV3]])
-// CHECK: [[ISPOS3:%.+]] = icmp sgt i64 [[CONV3]], 0
-// CHECK: [[POSMASK3:%.+]] = sub i64 [[CONV3]], 1
-// CHECK: [[MASK3:%.+]] = select i1 [[ISPOS3]], i64 [[POSMASK3]], i64 0
+// CHECK: [[MASK3:%.+]] = sub i64 [[CONV3]], 1
 // CHECK: [[PTRINT3:%.+]] = ptrtoint
 // CHECK: [[MASKEDPTR3:%.+]] = and i64 [[PTRINT3]], [[MASK3]]
 // CHECK: [[MASKCOND3:%.+]] = icmp eq i64 [[MASKEDPTR3]], 0
@@ -52,10 +46,8 @@ __INT32_TYPE__ test3(__INT32_TYPE__ a) {
 __INT32_TYPE__ test4(__SIZE_TYPE__ a) {
 // CHECK: define i32 @test4
   return *m2(a);
-// CHECK: call i32* @m2(i64 [[PARAM4:%[^\)]+]]) 
-// CHECK: [[ISPOS4:%.+]] = icmp sgt i64 [[PARAM4]], 0
-// CHECK: [[POSMASK4:%.+]] = sub i64 [[PARAM4]], 1
-// CHECK: [[MASK4:%.+]] = select i1 [[ISPOS4]], i64 [[POSMASK4]], i64 0
+// CHECK: call i32* @m2(i64 [[PARAM4:%[^\)]+]])
+// CHECK: [[MASK4:%.+]] = sub i64 [[PARAM4]], 1
 // CHECK: [[PTRINT4:%.+]] = ptrtoint
 // CHECK: [[MASKEDPTR4:%.+]] = and i64 [[PTRINT4]], [[MASK4]]
 // CHECK: [[MASKCOND4:%.+]] = icmp eq i64 [[MASKEDPTR4]], 0
@@ -72,11 +64,9 @@ __INT32_TYPE__ test5(__int128_t a) {
 // CHECK: define i32 @test5
   struct Empty e;
   return *m3(e, a);
-// CHECK: call i32* @m3(i64 %{{.*}}, i64 %{{.*}}) 
+// CHECK: call i32* @m3(i64 %{{.*}}, i64 %{{.*}})
 // CHECK: [[ALIGNCAST5:%.+]] = trunc i128 %{{.*}} to i64
-// CHECK: [[ISPOS5:%.+]] = icmp sgt i64 [[ALIGNCAST5]], 0
-// CHECK: [[POSMASK5:%.+]] = sub i64 [[ALIGNCAST5]], 1
-// CHECK: [[MASK5:%.+]] = select i1 [[ISPOS5]], i64 [[POSMASK5]], i64 0
+// CHECK: [[MASK5:%.+]] = sub i64 [[ALIGNCAST5]], 1
 // CHECK: [[PTRINT5:%.+]] = ptrtoint
 // CHECK: [[MASKEDPTR5:%.+]] = and i64 [[PTRINT5]], [[MASK5]]
 // CHECK: [[MASKCOND5:%.+]] = icmp eq i64 [[MASKEDPTR5]], 0
@@ -88,11 +78,9 @@ __INT32_TYPE__ test6(__int128_t a) {
 // CHECK: define i32 @test6
   struct MultiArgs e;
   return *m4(e, a);
-// CHECK: call i32* @m4(i64 %{{.*}}, i64 %{{.*}}, i64 %{{.*}}) 
+// CHECK: call i32* @m4(i64 %{{.*}}, i64 %{{.*}}, i64 %{{.*}})
 // CHECK: [[ALIGNCAST6:%.+]] = trunc i128 %{{.*}} to i64
-// CHECK: [[ISPOS6:%.+]] = icmp sgt i64 [[ALIGNCAST6]], 0
-// CHECK: [[POSMASK6:%.+]] = sub i64 [[ALIGNCAST6]], 1
-// CHECK: [[MASK6:%.+]] = select i1 [[ISPOS6]], i64 [[POSMASK6]], i64 0
+// CHECK: [[MASK6:%.+]] = sub i64 [[ALIGNCAST6]], 1
 // CHECK: [[PTRINT6:%.+]] = ptrtoint
 // CHECK: [[MASKEDPTR6:%.+]] = and i64 [[PTRINT6]], [[MASK6]]
 // CHECK: [[MASKCOND6:%.+]] = icmp eq i64 [[MASKEDPTR6]], 0

Modified: 
cfe/trunk/test/CodeGen/catch-alignment-assumption-attribute-alloc_align-on-function-variable.cpp
URL: 

[PATCH] D57175: [NFC][clang] Test updates for CreateAlignmentAssumption() changes in D54653

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL352090: [NFC][clang] Test updates for 
CreateAlignmentAssumption() changes in D54653 (authored by lebedevri, committed 
by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D57175?vs=183350=183356#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D57175

Files:
  cfe/trunk/test/CodeGen/alloc-align-attr.c
  
cfe/trunk/test/CodeGen/catch-alignment-assumption-attribute-alloc_align-on-function-variable.cpp


Index: 
cfe/trunk/test/CodeGen/catch-alignment-assumption-attribute-alloc_align-on-function-variable.cpp
===
--- 
cfe/trunk/test/CodeGen/catch-alignment-assumption-attribute-alloc_align-on-function-variable.cpp
+++ 
cfe/trunk/test/CodeGen/catch-alignment-assumption-attribute-alloc_align-on-function-variable.cpp
@@ -30,9 +30,7 @@
   // CHECK-NEXT:%[[X_RELOADED:.*]] = load i8**, i8*** 
%[[X_ADDR]], align 8
   // CHECK-NEXT:%[[ALIGNMENT_RELOADED:.*]] = load i64, 
i64* %[[ALIGNMENT_ADDR]], align 8
   // CHECK-NEXT:%[[X_RETURNED:.*]] = call i8** 
@[[PASSTHROUGH]](i8** %[[X_RELOADED]], i64 %[[ALIGNMENT_RELOADED]])
-  // CHECK-NEXT:%[[ISPOSITIVE:.*]] = icmp sgt i64 
%[[ALIGNMENT_RELOADED]], 0
-  // CHECK-NEXT:%[[POSITIVEMASK:.*]] = sub i64 
%[[ALIGNMENT_RELOADED]], 1
-  // CHECK-NEXT:%[[MASK:.*]] = select i1 
%[[ISPOSITIVE]], i64 %[[POSITIVEMASK]], i64 0
+  // CHECK-NEXT:%[[MASK:.*]] = sub i64 
%[[ALIGNMENT_RELOADED]], 1
   // CHECK-NEXT:%[[PTRINT:.*]] = ptrtoint i8** 
%[[X_RETURNED]] to i64
   // CHECK-NEXT:%[[MASKEDPTR:.*]] = and i64 
%[[PTRINT]], %[[MASK]]
   // CHECK-NEXT:%[[MASKCOND:.*]] = icmp eq i64 
%[[MASKEDPTR]], 0
Index: cfe/trunk/test/CodeGen/alloc-align-attr.c
===
--- cfe/trunk/test/CodeGen/alloc-align-attr.c
+++ cfe/trunk/test/CodeGen/alloc-align-attr.c
@@ -6,11 +6,9 @@
 __INT32_TYPE__ test1(__INT32_TYPE__ a) {
 // CHECK: define i32 @test1
   return *m1(a);
-// CHECK: call i32* @m1(i32 [[PARAM1:%[^\)]+]]) 
-// CHECK: [[ALIGNCAST1:%.+]] = sext i32 [[PARAM1]] to i64
-// CHECK: [[ISPOS1:%.+]] = icmp sgt i64 [[ALIGNCAST1]], 0
-// CHECK: [[POSMASK1:%.+]] = sub i64 [[ALIGNCAST1]], 1
-// CHECK: [[MASK1:%.+]] = select i1 [[ISPOS1]], i64 [[POSMASK1]], i64 0
+// CHECK: call i32* @m1(i32 [[PARAM1:%[^\)]+]])
+// CHECK: [[ALIGNCAST1:%.+]] = zext i32 [[PARAM1]] to i64
+// CHECK: [[MASK1:%.+]] = sub i64 [[ALIGNCAST1]], 1
 // CHECK: [[PTRINT1:%.+]] = ptrtoint
 // CHECK: [[MASKEDPTR1:%.+]] = and i64 [[PTRINT1]], [[MASK1]]
 // CHECK: [[MASKCOND1:%.+]] = icmp eq i64 [[MASKEDPTR1]], 0
@@ -22,10 +20,8 @@
   return *m1(a);
 // CHECK: [[CONV2:%.+]] = trunc i64 %{{.+}} to i32
 // CHECK: call i32* @m1(i32 [[CONV2]])
-// CHECK: [[ALIGNCAST2:%.+]] = sext i32 [[CONV2]] to i64
-// CHECK: [[ISPOS2:%.+]] = icmp sgt i64 [[ALIGNCAST2]], 0
-// CHECK: [[POSMASK2:%.+]] = sub i64 [[ALIGNCAST2]], 1
-// CHECK: [[MASK2:%.+]] = select i1 [[ISPOS2]], i64 [[POSMASK2]], i64 0
+// CHECK: [[ALIGNCAST2:%.+]] = zext i32 [[CONV2]] to i64
+// CHECK: [[MASK2:%.+]] = sub i64 [[ALIGNCAST2]], 1
 // CHECK: [[PTRINT2:%.+]] = ptrtoint
 // CHECK: [[MASKEDPTR2:%.+]] = and i64 [[PTRINT2]], [[MASK2]]
 // CHECK: [[MASKCOND2:%.+]] = icmp eq i64 [[MASKEDPTR2]], 0
@@ -39,9 +35,7 @@
   return *m2(a);
 // CHECK: [[CONV3:%.+]] = sext i32 %{{.+}} to i64
 // CHECK: call i32* @m2(i64 [[CONV3]])
-// CHECK: [[ISPOS3:%.+]] = icmp sgt i64 [[CONV3]], 0
-// CHECK: [[POSMASK3:%.+]] = sub i64 [[CONV3]], 1
-// CHECK: [[MASK3:%.+]] = select i1 [[ISPOS3]], i64 [[POSMASK3]], i64 0
+// CHECK: [[MASK3:%.+]] = sub i64 [[CONV3]], 1
 // CHECK: [[PTRINT3:%.+]] = ptrtoint
 // CHECK: [[MASKEDPTR3:%.+]] = and i64 [[PTRINT3]], [[MASK3]]
 // CHECK: [[MASKCOND3:%.+]] = icmp eq i64 [[MASKEDPTR3]], 0
@@ -52,10 +46,8 @@
 __INT32_TYPE__ test4(__SIZE_TYPE__ a) {
 // CHECK: define i32 @test4
   return *m2(a);
-// CHECK: call i32* @m2(i64 [[PARAM4:%[^\)]+]]) 
-// CHECK: [[ISPOS4:%.+]] = icmp sgt i64 [[PARAM4]], 0
-// CHECK: [[POSMASK4:%.+]] = sub i64 [[PARAM4]], 1
-// CHECK: [[MASK4:%.+]] = select i1 [[ISPOS4]], i64 [[POSMASK4]], i64 0
+// CHECK: call i32* @m2(i64 [[PARAM4:%[^\)]+]])
+// CHECK: [[MASK4:%.+]] = sub i64 [[PARAM4]], 1
 // CHECK: [[PTRINT4:%.+]] = ptrtoint
 // CHECK: [[MASKEDPTR4:%.+]] = and i64 [[PTRINT4]], [[MASK4]]
 // CHECK: [[MASKCOND4:%.+]] = icmp eq i64 [[MASKEDPTR4]], 0
@@ -72,11 +64,9 @@
 // CHECK: define i32 @test5
   struct Empty e;
   return *m3(e, a);
-// CHECK: call i32* @m3(i64 %{{.*}}, i64 %{{.*}}) 
+// CHECK: call i32* @m3(i64 %{{.*}}, i64 %{{.*}})
 // CHECK: [[ALIGNCAST5:%.+]] = trunc i128 %{{.*}} to 

[PATCH] D57155: [WebAssembly] Add a __wasi__ target macro

[Derek Schuff via Phabricator via cfe-commits]

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

LGTM; don't forget to include all the context in the future


Repository:
  rL LLVM

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

https://reviews.llvm.org/D57155



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

[clang-tools-extra] r352088 - [clang-tidy] Rename the absl duration helper functions; NFC

[Hyrum Wright via cfe-commits]

Author: hwright
Date: Thu Jan 24 11:23:50 2019
New Revision: 352088

URL: http://llvm.org/viewvc/llvm-project?rev=352088=rev
Log:
[clang-tidy] Rename the absl duration helper functions; NFC

Modified:
clang-tools-extra/trunk/clang-tidy/abseil/DurationComparisonCheck.cpp
clang-tools-extra/trunk/clang-tidy/abseil/DurationConversionCastCheck.cpp
clang-tools-extra/trunk/clang-tidy/abseil/DurationFactoryScaleCheck.cpp
clang-tools-extra/trunk/clang-tidy/abseil/DurationRewriter.cpp
clang-tools-extra/trunk/clang-tidy/abseil/DurationRewriter.h
clang-tools-extra/trunk/clang-tidy/abseil/DurationSubtractionCheck.cpp

Modified: clang-tools-extra/trunk/clang-tidy/abseil/DurationComparisonCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/abseil/DurationComparisonCheck.cpp?rev=352088=352087=352088=diff
==
--- clang-tools-extra/trunk/clang-tidy/abseil/DurationComparisonCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/abseil/DurationComparisonCheck.cpp Thu 
Jan 24 11:23:50 2019
@@ -34,7 +34,7 @@ void DurationComparisonCheck::registerMa
 void DurationComparisonCheck::check(const MatchFinder::MatchResult ) {
   const auto *Binop = Result.Nodes.getNodeAs("binop");
 
-  llvm::Optional Scale = getScaleForInverse(
+  llvm::Optional Scale = getScaleForDurationInverse(
   Result.Nodes.getNodeAs("function_decl")->getName());
   if (!Scale)
 return;

Modified: 
clang-tools-extra/trunk/clang-tidy/abseil/DurationConversionCastCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/abseil/DurationConversionCastCheck.cpp?rev=352088=352087=352088=diff
==
--- clang-tools-extra/trunk/clang-tidy/abseil/DurationConversionCastCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/abseil/DurationConversionCastCheck.cpp 
Thu Jan 24 11:23:50 2019
@@ -44,14 +44,15 @@ void DurationConversionCastCheck::check(
   const auto *Arg = Result.Nodes.getNodeAs("arg");
   StringRef ConversionFuncName = FuncDecl->getName();
 
-  llvm::Optional Scale = getScaleForInverse(ConversionFuncName);
+  llvm::Optional Scale =
+  getScaleForDurationInverse(ConversionFuncName);
   if (!Scale)
 return;
 
   // Casting a double to an integer.
   if (MatchedCast->getTypeAsWritten()->isIntegerType() &&
   ConversionFuncName.contains("Double")) {
-llvm::StringRef NewFuncName = getInverseForScale(*Scale).second;
+llvm::StringRef NewFuncName = getDurationInverseForScale(*Scale).second;
 
 diag(MatchedCast->getBeginLoc(),
  "duration should be converted directly to an integer rather than "
@@ -66,7 +67,7 @@ void DurationConversionCastCheck::check(
   // Casting an integer to a double.
   if (MatchedCast->getTypeAsWritten()->isRealFloatingType() &&
   ConversionFuncName.contains("Int64")) {
-llvm::StringRef NewFuncName = getInverseForScale(*Scale).first;
+llvm::StringRef NewFuncName = getDurationInverseForScale(*Scale).first;
 
 diag(MatchedCast->getBeginLoc(), "duration should be converted directly to 
"
  "a floating-piont number rather than "

Modified: 
clang-tools-extra/trunk/clang-tidy/abseil/DurationFactoryScaleCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/abseil/DurationFactoryScaleCheck.cpp?rev=352088=352087=352088=diff
==
--- clang-tools-extra/trunk/clang-tidy/abseil/DurationFactoryScaleCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/abseil/DurationFactoryScaleCheck.cpp Thu 
Jan 24 11:23:50 2019
@@ -209,7 +209,7 @@ void DurationFactoryScaleCheck::check(co
   diag(Call->getBeginLoc(), "internal duration scaling can be removed")
   << FixItHint::CreateReplacement(
  Call->getSourceRange(),
- (llvm::Twine(getFactoryForScale(*NewScale)) + "(" +
+ (llvm::Twine(getDurationFactoryForScale(*NewScale)) + "(" +
   tooling::fixit::getText(*Remainder, *Result.Context) + ")")
  .str());
 }
@@ -222,7 +222,7 @@ void DurationFactoryScaleCheck::check(co
 diag(Call->getBeginLoc(), "internal duration scaling can be removed")
 << FixItHint::CreateReplacement(
Call->getSourceRange(),
-   (llvm::Twine(getFactoryForScale(*NewScale)) + "(" +
+   (llvm::Twine(getDurationFactoryForScale(*NewScale)) + "(" +
 tooling::fixit::getText(*Remainder, *Result.Context) + ")")
.str());
   }

Modified: clang-tools-extra/trunk/clang-tidy/abseil/DurationRewriter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/abseil/DurationRewriter.cpp?rev=352088=352087=352088=diff

[PATCH] D14686: Protect against overloaded comma in random_shuffle and improve tests

[Marshall Clow via Phabricator via cfe-commits]

mclow.lists closed this revision.
mclow.lists added a comment.
Herald added a subscriber: llvm-commits.

(Finally) committed this as revision 352087.
I cut out most of the random_shuffle_rand.pass.cpp test, because it relied on 
C++11 features, and didn't work for C++03.
If you want to re-submit the test as a separate patch, I promise to review it 
in a more timely manner.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D14686



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

[PATCH] D56624: [Sanitizers] UBSan unreachable incompatible with ASan in the presence of `noreturn` calls

[Vedant Kumar via Phabricator via cfe-commits]

vsk added a comment.

In D56624#1369767 , @yln wrote:

> In D56624#1369635 , @vsk wrote:
>
> > What are the advantages of a generalized expect_noreturn attribute, vs. a 
> > narrower attribute or intrinsic? The expect_noreturn semantics do not 
> > provide strong guarantees, and are not really orthogonal from the 
> > pre-existing cold attribute.
>
>
> @eugenis Do you want to chime in here?
>  I think they convey different meanings even if their treatment by the 
> optimizer is similar. The `cold` attribute says nothing about whether or not 
> a function is expected to return.


That's my point: it doesn't need to, because it's orthogonal. It's just a hint 
that a call is cold and could be profitable to split/reorder. Features of llvm 
IR generally try to be orthogonal to reduce complexity in the optimizer.

>> In particular, expect_noreturn doesn't even seem strong enough to allow ASan 
>> to unpoison its stack.
> 
> I am not sure I understand this part. Can you elaborate?

Because "expect_noreturn" calls are allowed to return, the compiler must behave 
as they could. In particular, this means that unpoisoning the stack before 
expect_noreturn calls (given the current semantics) is premature.

Put another way, a frontend author may (understandably, but mistakenly!) attach 
expect_noreturn to calls which they expect to be cold. That would regress ASan 
coverage.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D56624



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

[PATCH] D50452: [WIP] clangd XPC adapter

[Jan Korous via Phabricator via cfe-commits]

jkorous added a comment.

Abandonned in favor of https://reviews.llvm.org/D54428


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D50452



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

[PATCH] D57175: [NFC][clang] Test updates for CreateAlignmentAssumption() changes in D54653

[Roman Lebedev via Phabricator via cfe-commits]

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

Self-accepting since D54653  got reviewed.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57175



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

[PATCH] D56892: Add a priority field to availability attributes to prioritize explicit attributes from declaration over attributes from '#pragma clang attribute'

[Alex Lorenz via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL352084: Add a priority field to availability attributes to 
prioritize explicit (authored by arphaman, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D56892?vs=182608=183353#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D56892

Files:
  cfe/trunk/include/clang/Basic/Attr.td
  cfe/trunk/include/clang/Basic/AttrDocs.td
  cfe/trunk/include/clang/Sema/ParsedAttr.h
  cfe/trunk/include/clang/Sema/Sema.h
  cfe/trunk/lib/Sema/SemaAttr.cpp
  cfe/trunk/lib/Sema/SemaDecl.cpp
  cfe/trunk/lib/Sema/SemaDeclAttr.cpp
  cfe/trunk/test/SemaObjC/attr-availability-priority.m

Index: cfe/trunk/include/clang/Sema/Sema.h
===
--- cfe/trunk/include/clang/Sema/Sema.h
+++ cfe/trunk/include/clang/Sema/Sema.h
@@ -2459,18 +2459,38 @@
 AMK_ProtocolImplementation,
   };
 
+  /// Describes the kind of priority given to an availability attribute.
+  ///
+  /// The sum of priorities deteremines the final priority of the attribute.
+  /// The final priority determines how the attribute will be merged.
+  /// An attribute with a lower priority will always remove higher priority
+  /// attributes for the specified platform when it is being applied. An
+  /// attribute with a higher priority will not be applied if the declaration
+  /// already has an availability attribute with a lower priority for the
+  /// specified platform. The final prirority values are not expected to match
+  /// the values in this enumeration, but instead should be treated as a plain
+  /// integer value. This enumeration just names the priority weights that are
+  /// used to calculate that final vaue.
+  enum AvailabilityPriority : int {
+/// The availability attribute was specified explicitly next to the
+/// declaration.
+AP_Explicit = 0,
+
+/// The availability attribute was applied using '#pragma clang attribute'.
+AP_PragmaClangAttribute = 1,
+
+/// The availability attribute for a specific platform was inferred from
+/// an availability attribute for another platform.
+AP_InferredFromOtherPlatform = 2
+  };
+
   /// Attribute merging methods. Return true if a new attribute was added.
-  AvailabilityAttr *mergeAvailabilityAttr(NamedDecl *D, SourceRange Range,
-  IdentifierInfo *Platform,
-  bool Implicit,
-  VersionTuple Introduced,
-  VersionTuple Deprecated,
-  VersionTuple Obsoleted,
-  bool IsUnavailable,
-  StringRef Message,
-  bool IsStrict, StringRef Replacement,
-  AvailabilityMergeKind AMK,
-  unsigned AttrSpellingListIndex);
+  AvailabilityAttr *mergeAvailabilityAttr(
+  NamedDecl *D, SourceRange Range, IdentifierInfo *Platform, bool Implicit,
+  VersionTuple Introduced, VersionTuple Deprecated, VersionTuple Obsoleted,
+  bool IsUnavailable, StringRef Message, bool IsStrict,
+  StringRef Replacement, AvailabilityMergeKind AMK, int Priority,
+  unsigned AttrSpellingListIndex);
   TypeVisibilityAttr *mergeTypeVisibilityAttr(Decl *D, SourceRange Range,
TypeVisibilityAttr::VisibilityType Vis,
   unsigned AttrSpellingListIndex);
Index: cfe/trunk/include/clang/Sema/ParsedAttr.h
===
--- cfe/trunk/include/clang/Sema/ParsedAttr.h
+++ cfe/trunk/include/clang/Sema/ParsedAttr.h
@@ -207,6 +207,9 @@
   /// A cached value.
   mutable unsigned ProcessingCache : 8;
 
+  /// True if the attribute is specified using '#pragma clang attribute'.
+  mutable unsigned IsPragmaClangAttribute : 1;
+
   /// The location of the 'unavailable' keyword in an
   /// availability attribute.
   SourceLocation UnavailableLoc;
@@ -238,7 +241,8 @@
 ScopeLoc(scopeLoc), EllipsisLoc(ellipsisLoc), NumArgs(numArgs),
 SyntaxUsed(syntaxUsed), Invalid(false), UsedAsTypeAttr(false),
 IsAvailability(false), IsTypeTagForDatatype(false), IsProperty(false),
-HasParsedType(false), HasProcessingCache(false) {
+HasParsedType(false), HasProcessingCache(false),
+IsPragmaClangAttribute(false) {
 if (numArgs) memcpy(getArgsBuffer(), args, numArgs * sizeof(ArgsUnion));
 AttrKind = getKind(getName(), getScopeName(), syntaxUsed);
   }
@@ -255,8 +259,8 @@
 ScopeLoc(scopeLoc), NumArgs(1), SyntaxUsed(syntaxUsed), Invalid(false),
 UsedAsTypeAttr(false), 

r352084 - Add a priority field to availability attributes to prioritize explicit

[Alex Lorenz via cfe-commits]

Author: arphaman
Date: Thu Jan 24 11:14:39 2019
New Revision: 352084

URL: http://llvm.org/viewvc/llvm-project?rev=352084=rev
Log:
Add a priority field to availability attributes to prioritize explicit
attributes from declaration over attributes from '#pragma clang attribute'

Before this commit users had an issue when using #pragma clang attribute with
availability attributes:

The explicit attribute that's specified next to the declaration is not
guaranteed to be preferred over the attribute specified in the pragma.

This commit fixes this by introducing a priority field to the availability
attribute to control how they're merged. Attributes with higher priority are
applied over attributes with lower priority for the same platform. The
implicitly inferred attributes are given the lower priority. This ensures that:

- explicit attributes are preferred over all other attributes.
- implicitly inferred attributes that are inferred from an explicit attribute
  are discarded if there's an explicit attribute or an attribute specified
  using a #pragma for the same platform.
- implicitly inferred attributes that are inferred from an attribute in the
  #pragma are not used if there's an explicit, explicit #pragma, or an
  implicit attribute inferred from an explicit attribute for the declaration.

This is the resulting ranking:

`platform availability > platform availability from pragma > inferred 
availability > inferred availability from pragma`

rdar://46390243

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

Added:
cfe/trunk/test/SemaObjC/attr-availability-priority.m
Modified:
cfe/trunk/include/clang/Basic/Attr.td
cfe/trunk/include/clang/Basic/AttrDocs.td
cfe/trunk/include/clang/Sema/ParsedAttr.h
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Sema/SemaAttr.cpp
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/lib/Sema/SemaDeclAttr.cpp

Modified: cfe/trunk/include/clang/Basic/Attr.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=352084=352083=352084=diff
==
--- cfe/trunk/include/clang/Basic/Attr.td (original)
+++ cfe/trunk/include/clang/Basic/Attr.td Thu Jan 24 11:14:39 2019
@@ -717,7 +717,8 @@ def Availability : InheritableAttr {
   let Args = [IdentifierArgument<"platform">, VersionArgument<"introduced">,
   VersionArgument<"deprecated">, VersionArgument<"obsoleted">,
   BoolArgument<"unavailable">, StringArgument<"message">,
-  BoolArgument<"strict">, StringArgument<"replacement">];
+  BoolArgument<"strict">, StringArgument<"replacement">,
+  IntArgument<"priority">];
   let AdditionalMembers =
 [{static llvm::StringRef getPrettyPlatformName(llvm::StringRef Platform) {
 return llvm::StringSwitch(Platform)

Modified: cfe/trunk/include/clang/Basic/AttrDocs.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttrDocs.td?rev=352084=352083=352084=diff
==
--- cfe/trunk/include/clang/Basic/AttrDocs.td (original)
+++ cfe/trunk/include/clang/Basic/AttrDocs.td Thu Jan 24 11:14:39 2019
@@ -1152,11 +1152,14 @@ replacement=\ *string-literal*
   the deprecated declaration with the new declaration specified.
 
 Multiple availability attributes can be placed on a declaration, which may
-correspond to different platforms.  Only the availability attribute with the
-platform corresponding to the target platform will be used; any others will be
-ignored.  If no availability attribute specifies availability for the current
-target platform, the availability attributes are ignored.  Supported platforms
-are:
+correspond to different platforms. For most platforms, the availability
+attribute with the platform corresponding to the target platform will be used;
+any others will be ignored. However, the availability for ``watchOS`` and
+``tvOS`` can be implicitly inferred from an ``iOS`` availability attribute.
+Any explicit availability attributes for those platforms are still prefered 
over
+the implicitly inferred availability attributes. If no availability attribute
+specifies availability for the current target platform, the availability
+attributes are ignored. Supported platforms are:
 
 ``ios``
   Apple's iOS operating system.  The minimum deployment target is specified by
@@ -1229,6 +1232,63 @@ Starting with the macOS 10.12 SDK, the `
   - (id)otherMethod API_AVAILABLE(macos(10.11), ios(11.0));
   @end
 
+Availability attributes can also be applied using a ``#pragma clang 
attribute``.
+Any explicit availability attribute whose platform corresponds to the target
+platform is applied to a declaration regardless of the availability attributes
+specified in the pragma. For example, in the code below,
+``hasExplicitAvailabilityAttribute`` will use the ``macOS`` availability
+attribute that is specified with the