Re: [PATCH] D10834: Added functions to retrieve information about variable storage in libclang and its python bindings.

[guibufolo+l...@gmail.com via cfe-commits]

RedX2501 added a comment.

Ping


http://reviews.llvm.org/D10834



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

Re: [PATCH] D10833: Retrieve BinaryOperator::getOpcode and BinaryOperator::getOpcodeStr via libclang and its python interface

[guibufolo+l...@gmail.com via cfe-commits]

RedX2501 added a comment.

Ping


http://reviews.llvm.org/D10833



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

Re: [PATCH] D12244: Implement ACLE 2.0 macros of chapters 6.4 and 6.5 for [ARM] and [Aarch64] targets

[Alexandros Lamprineas via cfe-commits]

labrinea updated this revision to Diff 32934.
labrinea added a comment.

Reordered macro definitions to make review easier.


http://reviews.llvm.org/D12244

Files:
  lib/Basic/Targets.cpp
  test/Preprocessor/aarch64-target-features.c
  test/Preprocessor/arm-acle-6.4.c
  test/Preprocessor/arm-acle-6.5.c

Index: test/Preprocessor/arm-acle-6.5.c
===
--- test/Preprocessor/arm-acle-6.5.c
+++ test/Preprocessor/arm-acle-6.5.c
@@ -1,22 +1,96 @@
-// RUN: %clang -target arm-eabi -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-DEFAULT
+// RUN: %clang -target arm-eabi -mfpu=none -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-NO-FP
+// RUN: %clang -target armv4-eabi -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-NO-FP
+// RUN: %clang -target armv5-eabi -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-NO-FP
+// RUN: %clang -target armv6m-eabi -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-NO-FP
+// RUN: %clang -target armv7r-eabi -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-NO-FP
+// RUN: %clang -target armv7m-eabi -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-NO-FP
 
-// CHECK-DEFAULT-NOT: __ARM_FP
+// CHECK-NO-FP-NOT: __ARM_FP 0x{{.*}}
+// CHECK-NO-FP-NOT: __ARM_FP16_FORMAT_IEEE
+
+// RUN: %clang -target arm-eabi -mfpu=vfpv3xd -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-SP
+// RUN: %clang -target arm-eabi -mfpu=vfpv3xd-fp16 -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-SP
+// RUN: %clang -target arm-eabi -mfpu=fpv4-sp-d16 -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-SP
+// RUN: %clang -target arm-eabi -mfpu=fpv5-sp-d16 -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-SP
+
+// CHECK-SP: __ARM_FP 0x4
+// CHECK-SP-NOT: __ARM_FP16_FORMAT_IEEE
 
 // RUN: %clang -target arm-eabi -mfpu=vfp -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-SP-DP
-// RUN: %clang -target arm-eabi -mfpu=vfp3 -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-SP-DP
+// RUN: %clang -target arm-eabi -mfpu=vfpv2 -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-SP-DP
+// RUN: %clang -target arm-eabi -mfpu=vfpv3 -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-SP-DP
 // RUN: %clang -target arm-eabi -mfpu=vfp3-d16 -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-SP-DP
 // RUN: %clang -target arm-eabi -mfpu=neon -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-SP-DP
-// RUN: %clang -target arm-eabi -mfpu=vfp3 -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-SP-DP
-// RUN: %clang -target armv7-eabi -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-SP-DP
+// RUN: %clang -target armv6-eabi -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-SP-DP
+// RUN: %clang -target armv7a-eabi -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-SP-DP
 
-// CHECK-SP-DP: __ARM_FP 0xC
+// CHECK-SP-DP: __ARM_FP 0xC
+// CHECK-SP-DP-NOT: __ARM_FP16_FORMAT_IEEE
 
+// RUN: %clang -target arm-eabi -mfpu=vfpv3-fp16 -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-SP-DP-HP
+// RUN: %clang -target arm-eabi -mfpu=vfpv3-d16-fp16 -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-SP-DP-HP
 // RUN: %clang -target arm-eabi -mfpu=vfpv4 -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-SP-DP-HP
 // RUN: %clang -target arm-eabi -mfpu=vfpv4-d16 -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-SP-DP-HP
+// RUN: %clang -target arm-eabi -mfpu=fpv5-d16 -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-SP-DP-HP
 // RUN: %clang -target arm-eabi -mfpu=fp-armv8 -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-SP-DP-HP
+// RUN: %clang -target arm-eabi -mfpu=neon-fp16 -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-SP-DP-HP
+// RUN: %clang -target arm-eabi -mfpu=neon-vfpv4 -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-SP-DP-HP
 // RUN: %clang -target arm-eabi -mfpu=neon-fp-armv8 -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-SP-DP-HP
 // RUN: %clang -target arm-eabi -mfpu=crypto-neon-fp-armv8 -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-SP-DP-HP
 // RUN: %clang -target armv8-eabi -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-SP-DP-HP
 
 // CHECK-SP-DP-HP: __ARM_FP 0xE
+// CHECK-SP-DP-HP: __ARM_FP16_FORMAT_IEEE 1
+
+// RUN: %clang -target armv4-eabi -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-NO-FMA
+// RUN: %clang -target armv5-eabi -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-NO-FMA
+// RUN: %clang -target armv6-eabi -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-NO-FMA
+// RUN: %clang -target armv6m-eabi -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-NO-FMA
+// RUN: %clang -target armv7m-eabi -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-NO-FMA
+
+// CHECK-NO-FMA-NOT: __ARM_FEATURE_FMA
+
+// RUN: %clang -target armv7a-eabi -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-FMA
+// RUN: %clang -target armv7r-eabi -x c -E -dM %s -o - | FileCheck %s -check-prefix CH

Re: [PATCH] D12244: Implement ACLE 2.0 macros of chapters 6.4 and 6.5 for [ARM] and [Aarch64] targets

[Alexandros Lamprineas via cfe-commits]

labrinea added inline comments.


Comment at: lib/Basic/Targets.cpp:4757
@@ -4679,2 +4756,3 @@
   Builder.defineMacro("__ARM_NEON__");
+  Builder.defineMacro("__ARM_NEON_FP", "0x" + llvm::utohexstr(HW_FP & 
~HW_FP_DP));
 }

According to the ACLE document, current AArch32 NEON implementations do not 
support double-precision floating-point even when it is present in VFP.


http://reviews.llvm.org/D12244



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

RE: [PATCH] RE: [cfe-dev] missing return statement for non-void functions in C++

[Sjoerd Meijer via cfe-commits]

I've taken the latest suggestions into account, see attached patch. Could you 
have a look?
Thanks.

-Original Message-
From: scott douglass [mailto:sdougl...@arm.com] 
Sent: 18 August 2015 14:16
To: Sjoerd Meijer
Cc: 'Marshall Clow'; 'Gabriel Dos Reis'; 'Richard Smith'; 'cfe-commits'
Subject: RE: [PATCH] RE: [cfe-dev] missing return statement for non-void 
functions in C++

> Please see updated patch file attached, which now includes a 
> fixed/added regression test.

I think it's a good idea; two minor remarks:

+if (!CGM.getCodeGenOpts().OptimizeSize) {
Should this be 'else if'?  I imagine there's no use emitting a trap after the 
sanitizer has emitted a missing_return check.

In the regression test, the CHECK-OPT case is now essentially the same as the 
CHECK case, so remove ' --check-prefix=CHECK-OPT' (but leave the RUN:) and 
these lines
  // CHECK-OPT: call void @llvm.trap
  // CHECK-OPT: unreachable





0001-Always-trap-for-missing-return-statements-except-whe.patch
Description: Binary data
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12240: [AArch64] Define the macro __ARM_FP16_ARGS

[Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL245833: [AArch64] Define the macro __ARM_FP16_ARGS (authored 
by kwalker).

Changed prior to commit:
  http://reviews.llvm.org/D12240?vs=32832&id=32938#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D12240

Files:
  cfe/trunk/lib/Basic/Targets.cpp
  cfe/trunk/test/Preprocessor/aarch64-target-features.c

Index: cfe/trunk/test/Preprocessor/aarch64-target-features.c
===
--- cfe/trunk/test/Preprocessor/aarch64-target-features.c
+++ cfe/trunk/test/Preprocessor/aarch64-target-features.c
@@ -19,6 +19,7 @@
 // CHECK: __ARM_FEATURE_NUMERIC_MAXMIN 1
 // CHECK: __ARM_FEATURE_UNALIGNED 1
 // CHECK: __ARM_FP 0xe
+// CHECK: __ARM_FP16_ARGS 1
 // CHECK: __ARM_FP16_FORMAT_IEEE 1
 // CHECK-NOT: __ARM_FP_FAST 1
 // CHECK: __ARM_FP_FENV_ROUNDING 1
Index: cfe/trunk/lib/Basic/Targets.cpp
===
--- cfe/trunk/lib/Basic/Targets.cpp
+++ cfe/trunk/lib/Basic/Targets.cpp
@@ -5176,6 +5176,7 @@
 // PCS specifies this for SysV variants, which is all we support. Other 
ABIs
 // may choose __ARM_FP16_FORMAT_ALTERNATIVE.
 Builder.defineMacro("__ARM_FP16_FORMAT_IEEE");
+Builder.defineMacro("__ARM_FP16_ARGS");
 
 if (Opts.FastMath || Opts.FiniteMathOnly)
   Builder.defineMacro("__ARM_FP_FAST");


Index: cfe/trunk/test/Preprocessor/aarch64-target-features.c
===
--- cfe/trunk/test/Preprocessor/aarch64-target-features.c
+++ cfe/trunk/test/Preprocessor/aarch64-target-features.c
@@ -19,6 +19,7 @@
 // CHECK: __ARM_FEATURE_NUMERIC_MAXMIN 1
 // CHECK: __ARM_FEATURE_UNALIGNED 1
 // CHECK: __ARM_FP 0xe
+// CHECK: __ARM_FP16_ARGS 1
 // CHECK: __ARM_FP16_FORMAT_IEEE 1
 // CHECK-NOT: __ARM_FP_FAST 1
 // CHECK: __ARM_FP_FENV_ROUNDING 1
Index: cfe/trunk/lib/Basic/Targets.cpp
===
--- cfe/trunk/lib/Basic/Targets.cpp
+++ cfe/trunk/lib/Basic/Targets.cpp
@@ -5176,6 +5176,7 @@
 // PCS specifies this for SysV variants, which is all we support. Other ABIs
 // may choose __ARM_FP16_FORMAT_ALTERNATIVE.
 Builder.defineMacro("__ARM_FP16_FORMAT_IEEE");
+Builder.defineMacro("__ARM_FP16_ARGS");
 
 if (Opts.FastMath || Opts.FiniteMathOnly)
   Builder.defineMacro("__ARM_FP_FAST");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r245833 - [AArch64] Define the macro __ARM_FP16_ARGS

[Keith Walker via cfe-commits]

Author: kwalker
Date: Mon Aug 24 05:11:14 2015
New Revision: 245833

URL: http://llvm.org/viewvc/llvm-project?rev=245833&view=rev
Log:
[AArch64] Define the macro __ARM_FP16_ARGS

The ACLE (ARM C Language Extensions) 2.0 defines that the predefined macro
__ARM_FP16_ARGS should be defined if __fp16 can be used as an argument and
result.

The support for __fp16 to be used as an argument and result is already
implemented for AArch64 so this change is just adding the missing macro.

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

Modified:
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/test/Preprocessor/aarch64-target-features.c

Modified: cfe/trunk/lib/Basic/Targets.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=245833&r1=245832&r2=245833&view=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Mon Aug 24 05:11:14 2015
@@ -5176,6 +5176,7 @@ public:
 // PCS specifies this for SysV variants, which is all we support. Other 
ABIs
 // may choose __ARM_FP16_FORMAT_ALTERNATIVE.
 Builder.defineMacro("__ARM_FP16_FORMAT_IEEE");
+Builder.defineMacro("__ARM_FP16_ARGS");
 
 if (Opts.FastMath || Opts.FiniteMathOnly)
   Builder.defineMacro("__ARM_FP_FAST");

Modified: cfe/trunk/test/Preprocessor/aarch64-target-features.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Preprocessor/aarch64-target-features.c?rev=245833&r1=245832&r2=245833&view=diff
==
--- cfe/trunk/test/Preprocessor/aarch64-target-features.c (original)
+++ cfe/trunk/test/Preprocessor/aarch64-target-features.c Mon Aug 24 05:11:14 
2015
@@ -19,6 +19,7 @@
 // CHECK: __ARM_FEATURE_NUMERIC_MAXMIN 1
 // CHECK: __ARM_FEATURE_UNALIGNED 1
 // CHECK: __ARM_FP 0xe
+// CHECK: __ARM_FP16_ARGS 1
 // CHECK: __ARM_FP16_FORMAT_IEEE 1
 // CHECK-NOT: __ARM_FP_FAST 1
 // CHECK: __ARM_FP_FENV_ROUNDING 1


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

Re: [PATCH] D12148: [ARM] Allow passing/returning of __fp16 arguments

[Renato Golin via cfe-commits]

rengolin added inline comments.


Comment at: lib/Driver/Tools.cpp:4254
@@ -4253,2 +4253,3 @@
   if (getToolChain().getArch() == llvm::Triple::aarch64 ||
-  getToolChain().getArch() == llvm::Triple::aarch64_be)
+  getToolChain().getArch() == llvm::Triple::aarch64_be ||
+  getToolChain().getArch() == llvm::Triple::arm ||

This could use the TargetParser to match the arch. If it's not invalid, it's 
ARM. Or a switch, maybe.


Repository:
  rL LLVM

http://reviews.llvm.org/D12148



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

[PATCH] D12278: [X86] Add MSVC-compatible intrinsics for clac, stac, lgdt and sgdt

[Michael Kuperstein via cfe-commits]

mkuper created this revision.
mkuper added reviewers: rnk, majnemer.
mkuper added a subscriber: cfe-commits.

LLVM part was posted as D12277

http://reviews.llvm.org/D12278

Files:
  include/clang/Basic/BuiltinsX86.def
  lib/Headers/Intrin.h
  test/CodeGen/builtins-x86.c

Index: lib/Headers/Intrin.h
===
--- lib/Headers/Intrin.h
+++ lib/Headers/Intrin.h
@@ -59,6 +59,7 @@
 void __addfsbyte(unsigned long, unsigned char);
 void __addfsdword(unsigned long, unsigned long);
 void __addfsword(unsigned long, unsigned short);
+static __inline__ void _clac(void);
 void __code_seg(const char *);
 static __inline__
 void __cpuid(int[4], int);
@@ -82,6 +83,7 @@
 void __invlpg(void *);
 unsigned short __inword(unsigned short);
 void __inwordstring(unsigned short, unsigned short *, unsigned long);
+static __inline__ void _lgdt(void *);
 void __lidt(void *);
 unsigned __int64 __ll_lshift(unsigned __int64, int);
 __int64 __ll_rshift(__int64, int);
@@ -130,9 +132,11 @@
 unsigned __int64 __readmsr(unsigned long);
 unsigned __int64 __readpmc(unsigned long);
 unsigned long __segmentlimit(unsigned long);
+static __inline__ void _sgdt(void *);
 void __sidt(void *);
 void *__slwpcb(void);
 static __inline__
+static __inline__ void _stac(void);
 void __stosb(unsigned char *, unsigned char, size_t);
 static __inline__
 void __stosd(unsigned long *, unsigned long, size_t);
@@ -944,6 +948,24 @@
 __writecr3(unsigned int __cr3_val) {
   __asm__ ("mov %0, %%cr3" : : "q"(__cr3_val) : "memory");
 }
+
+static __inline__ void __DEFAULT_FN_ATTRS _clac(void) {
+  __builtin_ia32_clac();
+}
+
+static __inline__ void __DEFAULT_FN_ATTRS _stac(void) {
+  __builtin_ia32_stac();
+}
+
+static __inline__ void __DEFAULT_FN_ATTRS _lgdt(void *__ptr) {
+  __builtin_ia32_lgdt(__ptr);
+}
+
+static __inline__ void __DEFAULT_FN_ATTRS _sgdt(void *__ptr) {
+  __builtin_ia32_sgdt(__ptr);
+}
+
+
 #endif
 
 #ifdef __cplusplus
Index: include/clang/Basic/BuiltinsX86.def
===
--- include/clang/Basic/BuiltinsX86.def
+++ include/clang/Basic/BuiltinsX86.def
@@ -671,6 +671,14 @@
 BUILTIN(__builtin_ia32_fxsave, "vv*", "")
 BUILTIN(__builtin_ia32_fxsave64, "vv*", "")
 
+// SMAP
+BUILTIN(__builtin_ia32_clac, "v", "")
+BUILTIN(__builtin_ia32_stac, "v", "")
+
+// LGDT, SGDT
+BUILTIN(__builtin_ia32_sgdt, "vv*", "")
+BUILTIN(__builtin_ia32_lgdt, "vv*", "")
+
 // ADX
 TARGET_BUILTIN(__builtin_ia32_addcarryx_u32, "UcUcUiUiUi*", "", "adx")
 TARGET_BUILTIN(__builtin_ia32_addcarryx_u64, "UcUcULLiULLiULLi*", "", "adx")
Index: test/CodeGen/builtins-x86.c
===
--- test/CodeGen/builtins-x86.c
+++ test/CodeGen/builtins-x86.c
@@ -264,6 +264,10 @@
   (void)__builtin_ia32_fxsave64(tmp_vp);
   (void)__builtin_ia32_fxrstor(tmp_vp);
   (void)__builtin_ia32_fxrstor64(tmp_vp);
+  (void)__builtin_ia32_clac();
+  (void)__builtin_ia32_stac();
+  (void)__builtin_ia32_sgdt(tmp_vp);
+  (void)__builtin_ia32_lgdt(tmp_vp);
   tmp_V4f = __builtin_ia32_cvtpi2ps(tmp_V4f, tmp_V2i);
   tmp_V2i = __builtin_ia32_cvtps2pi(tmp_V4f);
   tmp_i = __builtin_ia32_cvtss2si(tmp_V4f);


Index: lib/Headers/Intrin.h
===
--- lib/Headers/Intrin.h
+++ lib/Headers/Intrin.h
@@ -59,6 +59,7 @@
 void __addfsbyte(unsigned long, unsigned char);
 void __addfsdword(unsigned long, unsigned long);
 void __addfsword(unsigned long, unsigned short);
+static __inline__ void _clac(void);
 void __code_seg(const char *);
 static __inline__
 void __cpuid(int[4], int);
@@ -82,6 +83,7 @@
 void __invlpg(void *);
 unsigned short __inword(unsigned short);
 void __inwordstring(unsigned short, unsigned short *, unsigned long);
+static __inline__ void _lgdt(void *);
 void __lidt(void *);
 unsigned __int64 __ll_lshift(unsigned __int64, int);
 __int64 __ll_rshift(__int64, int);
@@ -130,9 +132,11 @@
 unsigned __int64 __readmsr(unsigned long);
 unsigned __int64 __readpmc(unsigned long);
 unsigned long __segmentlimit(unsigned long);
+static __inline__ void _sgdt(void *);
 void __sidt(void *);
 void *__slwpcb(void);
 static __inline__
+static __inline__ void _stac(void);
 void __stosb(unsigned char *, unsigned char, size_t);
 static __inline__
 void __stosd(unsigned long *, unsigned long, size_t);
@@ -944,6 +948,24 @@
 __writecr3(unsigned int __cr3_val) {
   __asm__ ("mov %0, %%cr3" : : "q"(__cr3_val) : "memory");
 }
+
+static __inline__ void __DEFAULT_FN_ATTRS _clac(void) {
+  __builtin_ia32_clac();
+}
+
+static __inline__ void __DEFAULT_FN_ATTRS _stac(void) {
+  __builtin_ia32_stac();
+}
+
+static __inline__ void __DEFAULT_FN_ATTRS _lgdt(void *__ptr) {
+  __builtin_ia32_lgdt(__ptr);
+}
+
+static __inline__ void __DEFAULT_FN_ATTRS _sgdt(void *__ptr) {
+  __builtin_ia32_sgdt(__ptr);
+}
+
+
 #endif
 
 #ifdef __cplusplus
Index: include/clang/Basic/BuiltinsX86.def
=

Re: [PATCH] D12244: Implement ACLE 2.0 macros of chapters 6.4 and 6.5 for [ARM] and [Aarch64] targets

[Oliver Stannard via cfe-commits]

olista01 added a subscriber: olista01.


Comment at: lib/Basic/Targets.cpp:4685-4686
@@ +4684,4 @@
+// ACLE 6.5.2 Half-precision (16-bit) floating-point format
+if (HW_FP & HW_FP_HP)
+  Builder.defineMacro("__ARM_FP16_FORMAT_IEEE", "1");
+

The __fp16 type is accepted even if it is not supported by the hardware 
(library calls are emitted instead), so this can be defined unconditionally. 
I'm currently working on D12148, which also sets this and _ARM_FP16_ARGS.


http://reviews.llvm.org/D12244



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

r245837 - clang-format: Properly handle braced lists in macros.

[Daniel Jasper via cfe-commits]

Author: djasper
Date: Mon Aug 24 08:23:37 2015
New Revision: 245837

URL: http://llvm.org/viewvc/llvm-project?rev=245837&view=rev
Log:
clang-format: Properly handle braced lists in macros.

Before:
  #define A\
  { a, a } \
  ,

After:
  #define A {a, a},

Modified:
cfe/trunk/lib/Format/UnwrappedLineParser.cpp
cfe/trunk/unittests/Format/FormatTest.cpp

Modified: cfe/trunk/lib/Format/UnwrappedLineParser.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/UnwrappedLineParser.cpp?rev=245837&r1=245836&r2=245837&view=diff
==
--- cfe/trunk/lib/Format/UnwrappedLineParser.cpp (original)
+++ cfe/trunk/lib/Format/UnwrappedLineParser.cpp Mon Aug 24 08:23:37 2015
@@ -284,6 +284,8 @@ void UnwrappedLineParser::parseLevel(boo
 case tok::l_brace:
   // FIXME: Add parameter whether this can happen - if this happens, we 
must
   // be in a non-declaration context.
+  if (!FormatTok->is(TT_MacroBlockBegin) && tryToParseBracedList())
+continue;
   parseBlock(/*MustBeDeclaration=*/false);
   addUnwrappedLine();
   break;

Modified: cfe/trunk/unittests/Format/FormatTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTest.cpp?rev=245837&r1=245836&r2=245837&view=diff
==
--- cfe/trunk/unittests/Format/FormatTest.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTest.cpp Mon Aug 24 08:23:37 2015
@@ -6144,6 +6144,7 @@ TEST_F(FormatTest, LayoutCxx11BraceIniti
"void f() { int i{2}; }\n"
"  };\n"
"};");
+  verifyFormat("#define A {a, a},");
 
   // In combination with BinPackArguments = false.
   FormatStyle NoBinPacking = getLLVMStyle();


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

Re: [PATCH] D12244: Implement ACLE 2.0 macros of chapters 6.4 and 6.5 for [ARM] and [Aarch64] targets

[Alexandros Lamprineas via cfe-commits]

labrinea added inline comments.


Comment at: lib/Basic/Targets.cpp:4685-4686
@@ +4684,4 @@
+// ACLE 6.5.2 Half-precision (16-bit) floating-point format
+if (HW_FP & HW_FP_HP)
+  Builder.defineMacro("__ARM_FP16_FORMAT_IEEE", "1");
+

olista01 wrote:
> The __fp16 type is accepted even if it is not supported by the hardware 
> (library calls are emitted instead), so this can be defined unconditionally. 
> I'm currently working on D12148, which also sets this and _ARM_FP16_ARGS.
Good point. As far as I know there is hardware support for having _fp16 type 
values as function arguments but not as return values (yet). If so, should 
_ARM_FP16_ARGS macro be defined or not? (ACLE 2.0: "_ARM_FP16_ARGS is defined 
to 1 if __fp16 can be used as an argument and result.")


http://reviews.llvm.org/D12244



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

[PATCH] D12281: Tests no longer need the 'REQUIRES: SHELL' line.

[Angel Garcia via cfe-commits]

angelgarcia created this revision.
angelgarcia added a reviewer: alexfh.
angelgarcia added subscribers: cfe-commits, klimek.

Update python script, so that it doesn't print that line in new tests.

http://reviews.llvm.org/D12281

Files:
  clang-tidy/add_new_check.py

Index: clang-tidy/add_new_check.py
===
--- clang-tidy/add_new_check.py
+++ clang-tidy/add_new_check.py
@@ -184,7 +184,6 @@
   with open(filename, 'w') as f:
 f.write(
 """// RUN: %%python %%S/check_clang_tidy.py %%s %(check_name_dashes)s %%t
-// REQUIRES: shell
 
 // FIXME: Add something that triggers the check here.
 void f();


Index: clang-tidy/add_new_check.py
===
--- clang-tidy/add_new_check.py
+++ clang-tidy/add_new_check.py
@@ -184,7 +184,6 @@
   with open(filename, 'w') as f:
 f.write(
 """// RUN: %%python %%S/check_clang_tidy.py %%s %(check_name_dashes)s %%t
-// REQUIRES: shell
 
 // FIXME: Add something that triggers the check here.
 void f();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12281: Tests no longer need the 'REQUIRES: SHELL' line.

[Aaron Ballman via cfe-commits]

LGTM!

~Aaron

On Mon, Aug 24, 2015 at 9:45 AM, Angel Garcia via cfe-commits
 wrote:
> angelgarcia created this revision.
> angelgarcia added a reviewer: alexfh.
> angelgarcia added subscribers: cfe-commits, klimek.
>
> Update python script, so that it doesn't print that line in new tests.
>
> http://reviews.llvm.org/D12281
>
> Files:
>   clang-tidy/add_new_check.py
>
> Index: clang-tidy/add_new_check.py
> ===
> --- clang-tidy/add_new_check.py
> +++ clang-tidy/add_new_check.py
> @@ -184,7 +184,6 @@
>with open(filename, 'w') as f:
>  f.write(
>  """// RUN: %%python %%S/check_clang_tidy.py %%s %(check_name_dashes)s %%t
> -// REQUIRES: shell
>
>  // FIXME: Add something that triggers the check here.
>  void f();
>
>
>
> ___
> 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
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12244: Implement ACLE 2.0 macros of chapters 6.4 and 6.5 for [ARM] and [Aarch64] targets

[Alexandros Lamprineas via cfe-commits]

labrinea added inline comments.


Comment at: lib/Basic/Targets.cpp:4685-4686
@@ +4684,4 @@
+// ACLE 6.5.2 Half-precision (16-bit) floating-point format
+if (HW_FP & HW_FP_HP)
+  Builder.defineMacro("__ARM_FP16_FORMAT_IEEE", "1");
+

olista01 wrote:
> labrinea wrote:
> > olista01 wrote:
> > > The __fp16 type is accepted even if it is not supported by the hardware 
> > > (library calls are emitted instead), so this can be defined 
> > > unconditionally. I'm currently working on D12148, which also sets this 
> > > and _ARM_FP16_ARGS.
> > Good point. As far as I know there is hardware support for having _fp16 
> > type values as function arguments but not as return values (yet). If so, 
> > should _ARM_FP16_ARGS macro be defined or not? (ACLE 2.0: "_ARM_FP16_ARGS 
> > is defined to 1 if __fp16 can be used as an argument and result.")
> Support for __fp16 args/returns should be independent of hardware support (at 
> least in clang/llvm), as we can always lower to library function calls.
> 
> For AArch32: There is currently no support for __fp16 arguments or returns, 
> but D12148 adds both of these, and sets the predefine.
> 
> For AArch64: There has been support for __fp16 args and returns for about a 
> year, but we only recently turned the predefine on (D12240/rL245833).
Good. I will update this patch accordingly.


http://reviews.llvm.org/D12244



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

Re: [PATCH] D11832: [Patch] [Analyzer] false positive: Potential leak connected with memcpy (PR 22954)

[pierre gousseau via cfe-commits]

pgousseau updated this revision to Diff 32955.
pgousseau added a comment.

Encapsulate 'RegionAndSymbolInvalidationTraits' by overriding 'AddToWorkList' 
following Anton's review.
Also as pointed out by Devin's review:
Add tests cases and handling for regions, bindings in super regions, and 
aliased/casted regions, with symbolic offsets.
Add test case and handling for writing past the array.
Replace 'ROffset <= UpperOffset' by 'ROffset < UpperOffset'.

Please let me know if this an acceptable change ?
Regards,
Pierre


http://reviews.llvm.org/D11832

Files:
  include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h
  lib/StaticAnalyzer/Checkers/CStringChecker.cpp
  lib/StaticAnalyzer/Core/RegionStore.cpp
  test/Analysis/pr22954.c

Index: test/Analysis/pr22954.c
===
--- /dev/null
+++ test/Analysis/pr22954.c
@@ -0,0 +1,623 @@
+// Given code 'struct aa { char s1[4]; char * s2;} a; memcpy(a.s1, ...);',
+// this test checks that the CStringChecker only invalidates the destination buffer array a.s1 (instead of a.s1 and a.s2).
+// At the moment the whole of the destination array content is invalidated.
+// If a.s1 region has a symbolic offset, the whole region of 'a' is invalidated.
+// Specific triple set to test structures of size 0.
+// RUN: %clang_cc1 -triple x86_64-pc-linux-gnu -analyze -analyzer-checker=core,unix.Malloc,debug.ExprInspection -analyzer-store=region -verify %s
+
+typedef __typeof(sizeof(int)) size_t;
+
+char *strdup(const char *s);
+void free(void *);
+void *memcpy(void *dst, const void *src, size_t n);
+void *malloc(size_t n);
+
+void clang_analyzer_eval(int);
+
+struct aa {
+char s1[4];
+char *s2;
+};
+
+// Test different types of structure initialisation.
+int f0() {
+  struct aa a0 = {{1, 2, 3, 4}, 0};
+  a0.s2 = strdup("hello");
+  char input[] = {'a', 'b', 'c', 'd'};
+  memcpy(a0.s1, input, 4);
+  clang_analyzer_eval(a0.s1[0] == 'a'); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(a0.s1[1] == 'b'); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(a0.s1[2] == 'c'); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(a0.s1[3] == 'd'); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(a0.s2 == 0); // expected-warning{{UNKNOWN}}
+  free(a0.s2); // no warning
+  return 0;
+}
+
+int f1() {
+  struct aa a1;
+  a1.s2 = strdup("hello");
+  char input[] = {'a', 'b', 'c', 'd'};
+  memcpy(a1.s1, input, 4);
+  clang_analyzer_eval(a1.s1[0] == 'a'); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(a1.s1[1] == 'b'); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(a1.s1[2] == 'c'); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(a1.s1[3] == 'd'); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(a1.s2 == 0); // expected-warning{{UNKNOWN}}
+  free(a1.s2); // no warning
+  return 0;
+}
+
+int f2() {
+  struct aa a2 = {{1, 2}};
+  a2.s2 = strdup("hello");
+  char input[] = {'a', 'b', 'c', 'd'};
+  memcpy(a2.s1, input, 4);
+  clang_analyzer_eval(a2.s1[0] == 'a'); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(a2.s1[1] == 'b'); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(a2.s1[2] == 'c'); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(a2.s1[3] == 'd'); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(a2.s2 == 0); // expected-warning{{UNKNOWN}}
+  free(a2.s2); // no warning
+  return 0;
+}
+
+int f3() {
+  struct aa a3 = {{1, 2, 3, 4}, 0};
+  a3.s2 = strdup("hello");
+  char input[] = {'a', 'b', 'c', 'd'};
+  int * dest = (int*)a3.s1;
+  memcpy(dest, input, 4);
+  clang_analyzer_eval(a3.s1[0] == 'a'); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(dest[0] == 'a'); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(a3.s1[1] == 'b'); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(dest[1] == 'b'); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(a3.s1[2] == 'c'); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(dest[2] == 'c'); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(a3.s1[3] == 'd'); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(dest[3] == 'd'); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(a3.s2 == 0); // expected-warning{{UNKNOWN}}
+  free(a3.s2); // no warning
+  return 0;
+}
+
+struct bb {
+  struct aa a;
+  char * s2;
+};
+
+int f4() {
+  struct bb b0 = {{1, 2, 3, 4}, 0};
+  b0.s2 = strdup("hello");
+  b0.a.s2 = strdup("hola");
+  char input[] = {'a', 'b', 'c', 'd'};
+  char * dest = (char*)(b0.a.s1);
+  memcpy(dest, input, 4);
+  clang_analyzer_eval(b0.a.s1[0] == 'a'); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(dest[0] == 'a'); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(b0.a.s1[1] == 'b'); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(dest[1] == 'b'); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(b0.a.s1[2] == 'c'); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(dest[2] == 'c'); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(b0.a.s1[3] == 'd'); // expected-wa

r245843 - clang-format: Make formatting of member function reference qualifiers

[Daniel Jasper via cfe-commits]

Author: djasper
Date: Mon Aug 24 09:28:08 2015
New Revision: 245843

URL: http://llvm.org/viewvc/llvm-project?rev=245843&view=rev
Log:
clang-format: Make formatting of member function reference qualifiers
more consistent.

Before:
  SomeType MemberFunction(const Deleted &)&&;
  SomeType MemberFunction(const Deleted &) && { ... }

After:
  SomeType MemberFunction(const Deleted &)&&;
  SomeType MemberFunction(const Deleted &)&& { ... }

Modified:
cfe/trunk/lib/Format/FormatToken.h
cfe/trunk/lib/Format/TokenAnnotator.cpp
cfe/trunk/unittests/Format/FormatTest.cpp

Modified: cfe/trunk/lib/Format/FormatToken.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/FormatToken.h?rev=245843&r1=245842&r2=245843&view=diff
==
--- cfe/trunk/lib/Format/FormatToken.h (original)
+++ cfe/trunk/lib/Format/FormatToken.h Mon Aug 24 09:28:08 2015
@@ -525,6 +525,8 @@ private:
 /// properly supported by Clang's lexer.
 struct AdditionalKeywords {
   AdditionalKeywords(IdentifierTable &IdentTable) {
+kw_final = &IdentTable.get("final");
+kw_override = &IdentTable.get("override");
 kw_in = &IdentTable.get("in");
 kw_CF_ENUM = &IdentTable.get("CF_ENUM");
 kw_CF_OPTIONS = &IdentTable.get("CF_OPTIONS");
@@ -538,7 +540,6 @@ struct AdditionalKeywords {
 
 kw_abstract = &IdentTable.get("abstract");
 kw_extends = &IdentTable.get("extends");
-kw_final = &IdentTable.get("final");
 kw_implements = &IdentTable.get("implements");
 kw_instanceof = &IdentTable.get("instanceof");
 kw_interface = &IdentTable.get("interface");
@@ -562,6 +563,8 @@ struct AdditionalKeywords {
   }
 
   // Context sensitive keywords.
+  IdentifierInfo *kw_final;
+  IdentifierInfo *kw_override;
   IdentifierInfo *kw_in;
   IdentifierInfo *kw_CF_ENUM;
   IdentifierInfo *kw_CF_OPTIONS;
@@ -578,7 +581,6 @@ struct AdditionalKeywords {
   // Java keywords.
   IdentifierInfo *kw_abstract;
   IdentifierInfo *kw_extends;
-  IdentifierInfo *kw_final;
   IdentifierInfo *kw_implements;
   IdentifierInfo *kw_instanceof;
   IdentifierInfo *kw_interface;

Modified: cfe/trunk/lib/Format/TokenAnnotator.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/TokenAnnotator.cpp?rev=245843&r1=245842&r2=245843&view=diff
==
--- cfe/trunk/lib/Format/TokenAnnotator.cpp (original)
+++ cfe/trunk/lib/Format/TokenAnnotator.cpp Mon Aug 24 09:28:08 2015
@@ -1139,9 +1139,11 @@ private:
   return TT_UnaryOperator;
 
 const FormatToken *NextToken = Tok.getNextNonComment();
-if (!NextToken || NextToken->is(tok::arrow) ||
+if (!NextToken ||
+NextToken->isOneOf(tok::arrow, Keywords.kw_final,
+   Keywords.kw_override) ||
 (NextToken->is(tok::l_brace) && !NextToken->getNextNonComment()))
-  return TT_Unknown;
+  return TT_PointerOrReference;
 
 if (PrevToken->is(tok::coloncolon))
   return TT_PointerOrReference;
@@ -1855,7 +1857,9 @@ bool TokenAnnotator::spaceRequiredBetwee
 !Line.IsMultiVariableDeclStmt)))
 return true;
   if (Left.is(TT_PointerOrReference))
-return Right.Tok.isLiteral() || Right.is(TT_BlockComment) ||
+return Right.Tok.isLiteral() ||
+   Right.isOneOf(TT_BlockComment, Keywords.kw_final,
+ Keywords.kw_override) ||
(Right.is(tok::l_brace) && Right.BlockKind == BK_Block) ||
(!Right.isOneOf(TT_PointerOrReference, TT_ArraySubscriptLSquare,
tok::l_paren) &&

Modified: cfe/trunk/unittests/Format/FormatTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTest.cpp?rev=245843&r1=245842&r2=245843&view=diff
==
--- cfe/trunk/unittests/Format/FormatTest.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTest.cpp Mon Aug 24 09:28:08 2015
@@ -5326,6 +5326,9 @@ TEST_F(FormatTest, UnderstandsFunctionRe
   verifyFormat("Deleted &operator=(const Deleted &)&&;");
   verifyFormat("SomeType MemberFunction(const Deleted &)&;");
   verifyFormat("SomeType MemberFunction(const Deleted &)&&;");
+  verifyFormat("SomeType MemberFunction(const Deleted &)&& {}");
+  verifyFormat("SomeType MemberFunction(const Deleted &)&& final {}");
+  verifyFormat("SomeType MemberFunction(const Deleted &)&& override {}");
 
   verifyGoogleFormat("Deleted& operator=(const Deleted&)& = default;");
   verifyGoogleFormat("SomeType MemberFunction(const Deleted&)& = delete;");
@@ -5583,11 +5586,11 @@ TEST_F(FormatTest, UnderstandsUsesOfStar
 
   // Member function reference qualifiers aren't binary operators.
   verifyFormat("string // break\n"
-   "operator()() & {}");
+   "operator()()& {}");
   verifyFormat("string // break\n"
-   "operator()() && {}");
+   "operator()()&& {}");
   ver

r245846 - clang-format: Always allow break after leading annotations.

[Daniel Jasper via cfe-commits]

Author: djasper
Date: Mon Aug 24 10:10:01 2015
New Revision: 245846

URL: http://llvm.org/viewvc/llvm-project?rev=245846&view=rev
Log:
clang-format: Always allow break after leading annotations.

Before:
  DEPRECATED("Use NewClass::NewFunction instead.") int OldFunction(
  const string ¶meter) {}

Could not be formatted at all, as clang-format would both require and
disallow the break before "int".

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

Modified: cfe/trunk/lib/Format/TokenAnnotator.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/TokenAnnotator.cpp?rev=245846&r1=245845&r2=245846&view=diff
==
--- cfe/trunk/lib/Format/TokenAnnotator.cpp (original)
+++ cfe/trunk/lib/Format/TokenAnnotator.cpp Mon Aug 24 10:10:01 2015
@@ -2236,7 +2236,7 @@ bool TokenAnnotator::canBreakBefore(cons
 return Left.isNot(tok::period); // FIXME: Properly parse ObjC calls.
   if (Left.is(tok::r_paren) && Line.Type == LT_ObjCProperty)
 return true;
-  if (Left.ClosesTemplateDeclaration)
+  if (Left.ClosesTemplateDeclaration || Left.is(TT_FunctionAnnotationRParen))
 return true;
   if (Right.isOneOf(TT_RangeBasedForLoopColon, TT_OverloadedOperatorLParen,
 TT_OverloadedOperator))

Modified: cfe/trunk/unittests/Format/FormatTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTest.cpp?rev=245846&r1=245845&r2=245846&view=diff
==
--- cfe/trunk/unittests/Format/FormatTest.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTest.cpp Mon Aug 24 10:10:01 2015
@@ -3900,6 +3900,8 @@ TEST_F(FormatTest, BreaksFunctionDeclara
 
 TEST_F(FormatTest, FunctionAnnotations) {
   verifyFormat("DEPRECATED(\"Use NewClass::NewFunction instead.\")\n"
+   "int OldFunction(const string ¶meter) {}");
+  verifyFormat("DEPRECATED(\"Use NewClass::NewFunction instead.\")\n"
"string OldFunction(const string ¶meter) {}");
   verifyFormat("template \n"
"DEPRECATED(\"Use NewClass::NewFunction instead.\")\n"


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

Re: r245843 - clang-format: Make formatting of member function reference qualifiers

[David Blaikie via cfe-commits]

On Mon, Aug 24, 2015 at 7:28 AM, Daniel Jasper via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: djasper
> Date: Mon Aug 24 09:28:08 2015
> New Revision: 245843
>
> URL: http://llvm.org/viewvc/llvm-project?rev=245843&view=rev
> Log:
> clang-format: Make formatting of member function reference qualifiers
> more consistent.
>
> Before:
>   SomeType MemberFunction(const Deleted &)&&;
>   SomeType MemberFunction(const Deleted &) && { ... }
>
> After:
>   SomeType MemberFunction(const Deleted &)&&;
>   SomeType MemberFunction(const Deleted &)&& { ... }
>

I don't think that's the way most people write them - at least I tend to
write them with a space after the ')'? (for both rvalue and lvalue ref)
same way I would with 'const'.

Any sense of how this is usually done (across LLVM or other codebases)?


>
> Modified:
> cfe/trunk/lib/Format/FormatToken.h
> cfe/trunk/lib/Format/TokenAnnotator.cpp
> cfe/trunk/unittests/Format/FormatTest.cpp
>
> Modified: cfe/trunk/lib/Format/FormatToken.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/FormatToken.h?rev=245843&r1=245842&r2=245843&view=diff
>
> ==
> --- cfe/trunk/lib/Format/FormatToken.h (original)
> +++ cfe/trunk/lib/Format/FormatToken.h Mon Aug 24 09:28:08 2015
> @@ -525,6 +525,8 @@ private:
>  /// properly supported by Clang's lexer.
>  struct AdditionalKeywords {
>AdditionalKeywords(IdentifierTable &IdentTable) {
> +kw_final = &IdentTable.get("final");
> +kw_override = &IdentTable.get("override");
>  kw_in = &IdentTable.get("in");
>  kw_CF_ENUM = &IdentTable.get("CF_ENUM");
>  kw_CF_OPTIONS = &IdentTable.get("CF_OPTIONS");
> @@ -538,7 +540,6 @@ struct AdditionalKeywords {
>
>  kw_abstract = &IdentTable.get("abstract");
>  kw_extends = &IdentTable.get("extends");
> -kw_final = &IdentTable.get("final");
>  kw_implements = &IdentTable.get("implements");
>  kw_instanceof = &IdentTable.get("instanceof");
>  kw_interface = &IdentTable.get("interface");
> @@ -562,6 +563,8 @@ struct AdditionalKeywords {
>}
>
>// Context sensitive keywords.
> +  IdentifierInfo *kw_final;
> +  IdentifierInfo *kw_override;
>IdentifierInfo *kw_in;
>IdentifierInfo *kw_CF_ENUM;
>IdentifierInfo *kw_CF_OPTIONS;
> @@ -578,7 +581,6 @@ struct AdditionalKeywords {
>// Java keywords.
>IdentifierInfo *kw_abstract;
>IdentifierInfo *kw_extends;
> -  IdentifierInfo *kw_final;
>IdentifierInfo *kw_implements;
>IdentifierInfo *kw_instanceof;
>IdentifierInfo *kw_interface;
>
> Modified: cfe/trunk/lib/Format/TokenAnnotator.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/TokenAnnotator.cpp?rev=245843&r1=245842&r2=245843&view=diff
>
> ==
> --- cfe/trunk/lib/Format/TokenAnnotator.cpp (original)
> +++ cfe/trunk/lib/Format/TokenAnnotator.cpp Mon Aug 24 09:28:08 2015
> @@ -1139,9 +1139,11 @@ private:
>return TT_UnaryOperator;
>
>  const FormatToken *NextToken = Tok.getNextNonComment();
> -if (!NextToken || NextToken->is(tok::arrow) ||
> +if (!NextToken ||
> +NextToken->isOneOf(tok::arrow, Keywords.kw_final,
> +   Keywords.kw_override) ||
>  (NextToken->is(tok::l_brace) && !NextToken->getNextNonComment()))
> -  return TT_Unknown;
> +  return TT_PointerOrReference;
>
>  if (PrevToken->is(tok::coloncolon))
>return TT_PointerOrReference;
> @@ -1855,7 +1857,9 @@ bool TokenAnnotator::spaceRequiredBetwee
>  !Line.IsMultiVariableDeclStmt)))
>  return true;
>if (Left.is(TT_PointerOrReference))
> -return Right.Tok.isLiteral() || Right.is(TT_BlockComment) ||
> +return Right.Tok.isLiteral() ||
> +   Right.isOneOf(TT_BlockComment, Keywords.kw_final,
> + Keywords.kw_override) ||
> (Right.is(tok::l_brace) && Right.BlockKind == BK_Block) ||
> (!Right.isOneOf(TT_PointerOrReference,
> TT_ArraySubscriptLSquare,
> tok::l_paren) &&
>
> Modified: cfe/trunk/unittests/Format/FormatTest.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTest.cpp?rev=245843&r1=245842&r2=245843&view=diff
>
> ==
> --- cfe/trunk/unittests/Format/FormatTest.cpp (original)
> +++ cfe/trunk/unittests/Format/FormatTest.cpp Mon Aug 24 09:28:08 2015
> @@ -5326,6 +5326,9 @@ TEST_F(FormatTest, UnderstandsFunctionRe
>verifyFormat("Deleted &operator=(const Deleted &)&&;");
>verifyFormat("SomeType MemberFunction(const Deleted &)&;");
>verifyFormat("SomeType MemberFunction(const Deleted &)&&;");
> +  verifyFormat("SomeType MemberFunction(const Deleted &)&& {}");
> +  verifyFormat("SomeType MemberFunction(const Deleted &)&& final {}");
> +  verifyFormat("SomeType Membe

Re: [PATCH] D12164: Stop treating -static as overriding -fPIC: they are distinct.

[James Y Knight via cfe-commits]

jyknight closed this revision.
jyknight added a comment.

D'oh, I copy/pasted the wrong review link when submitting this. It was 
submitted as http://reviews.llvm.org/rL245667.


http://reviews.llvm.org/D12164



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

Re: r245843 - clang-format: Make formatting of member function reference qualifiers

[Daniel Jasper via cfe-commits]

On Mon, Aug 24, 2015 at 5:46 PM, David Blaikie  wrote:

>
>
> On Mon, Aug 24, 2015 at 7:28 AM, Daniel Jasper via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: djasper
>> Date: Mon Aug 24 09:28:08 2015
>> New Revision: 245843
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=245843&view=rev
>> Log:
>> clang-format: Make formatting of member function reference qualifiers
>> more consistent.
>>
>> Before:
>>   SomeType MemberFunction(const Deleted &)&&;
>>   SomeType MemberFunction(const Deleted &) && { ... }
>>
>> After:
>>   SomeType MemberFunction(const Deleted &)&&;
>>   SomeType MemberFunction(const Deleted &)&& { ... }
>>
>
> I don't think that's the way most people write them - at least I tend to
> write them with a space after the ')'? (for both rvalue and lvalue ref)
> same way I would with 'const'.
>
> Any sense of how this is usually done (across LLVM or other codebases)?
>

You are probably right. But making this consistent is a good step either
way ;-). I'll follow up with another commit ..


>
>
>>
>> Modified:
>> cfe/trunk/lib/Format/FormatToken.h
>> cfe/trunk/lib/Format/TokenAnnotator.cpp
>> cfe/trunk/unittests/Format/FormatTest.cpp
>>
>> Modified: cfe/trunk/lib/Format/FormatToken.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/FormatToken.h?rev=245843&r1=245842&r2=245843&view=diff
>>
>> ==
>> --- cfe/trunk/lib/Format/FormatToken.h (original)
>> +++ cfe/trunk/lib/Format/FormatToken.h Mon Aug 24 09:28:08 2015
>> @@ -525,6 +525,8 @@ private:
>>  /// properly supported by Clang's lexer.
>>  struct AdditionalKeywords {
>>AdditionalKeywords(IdentifierTable &IdentTable) {
>> +kw_final = &IdentTable.get("final");
>> +kw_override = &IdentTable.get("override");
>>  kw_in = &IdentTable.get("in");
>>  kw_CF_ENUM = &IdentTable.get("CF_ENUM");
>>  kw_CF_OPTIONS = &IdentTable.get("CF_OPTIONS");
>> @@ -538,7 +540,6 @@ struct AdditionalKeywords {
>>
>>  kw_abstract = &IdentTable.get("abstract");
>>  kw_extends = &IdentTable.get("extends");
>> -kw_final = &IdentTable.get("final");
>>  kw_implements = &IdentTable.get("implements");
>>  kw_instanceof = &IdentTable.get("instanceof");
>>  kw_interface = &IdentTable.get("interface");
>> @@ -562,6 +563,8 @@ struct AdditionalKeywords {
>>}
>>
>>// Context sensitive keywords.
>> +  IdentifierInfo *kw_final;
>> +  IdentifierInfo *kw_override;
>>IdentifierInfo *kw_in;
>>IdentifierInfo *kw_CF_ENUM;
>>IdentifierInfo *kw_CF_OPTIONS;
>> @@ -578,7 +581,6 @@ struct AdditionalKeywords {
>>// Java keywords.
>>IdentifierInfo *kw_abstract;
>>IdentifierInfo *kw_extends;
>> -  IdentifierInfo *kw_final;
>>IdentifierInfo *kw_implements;
>>IdentifierInfo *kw_instanceof;
>>IdentifierInfo *kw_interface;
>>
>> Modified: cfe/trunk/lib/Format/TokenAnnotator.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/TokenAnnotator.cpp?rev=245843&r1=245842&r2=245843&view=diff
>>
>> ==
>> --- cfe/trunk/lib/Format/TokenAnnotator.cpp (original)
>> +++ cfe/trunk/lib/Format/TokenAnnotator.cpp Mon Aug 24 09:28:08 2015
>> @@ -1139,9 +1139,11 @@ private:
>>return TT_UnaryOperator;
>>
>>  const FormatToken *NextToken = Tok.getNextNonComment();
>> -if (!NextToken || NextToken->is(tok::arrow) ||
>> +if (!NextToken ||
>> +NextToken->isOneOf(tok::arrow, Keywords.kw_final,
>> +   Keywords.kw_override) ||
>>  (NextToken->is(tok::l_brace) && !NextToken->getNextNonComment()))
>> -  return TT_Unknown;
>> +  return TT_PointerOrReference;
>>
>>  if (PrevToken->is(tok::coloncolon))
>>return TT_PointerOrReference;
>> @@ -1855,7 +1857,9 @@ bool TokenAnnotator::spaceRequiredBetwee
>>  !Line.IsMultiVariableDeclStmt)))
>>  return true;
>>if (Left.is(TT_PointerOrReference))
>> -return Right.Tok.isLiteral() || Right.is(TT_BlockComment) ||
>> +return Right.Tok.isLiteral() ||
>> +   Right.isOneOf(TT_BlockComment, Keywords.kw_final,
>> + Keywords.kw_override) ||
>> (Right.is(tok::l_brace) && Right.BlockKind == BK_Block) ||
>> (!Right.isOneOf(TT_PointerOrReference,
>> TT_ArraySubscriptLSquare,
>> tok::l_paren) &&
>>
>> Modified: cfe/trunk/unittests/Format/FormatTest.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTest.cpp?rev=245843&r1=245842&r2=245843&view=diff
>>
>> ==
>> --- cfe/trunk/unittests/Format/FormatTest.cpp (original)
>> +++ cfe/trunk/unittests/Format/FormatTest.cpp Mon Aug 24 09:28:08 2015
>> @@ -5326,6 +5326,9 @@ TEST_F(FormatTest, UnderstandsFunctionRe
>>verifyFormat("Deleted &operator=(const Deleted &)&&;

[libcxx] r245849 - Fix a crasher found by libFuzzer

[Marshall Clow via cfe-commits]

Author: marshall
Date: Mon Aug 24 10:57:09 2015
New Revision: 245849

URL: http://llvm.org/viewvc/llvm-project?rev=245849&view=rev
Log:
Fix a crasher found by libFuzzer

Modified:
libcxx/trunk/include/regex
libcxx/trunk/test/std/re/re.alg/re.alg.search/grep.pass.cpp

Modified: libcxx/trunk/include/regex
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/regex?rev=245849&r1=245848&r2=245849&view=diff
==
--- libcxx/trunk/include/regex (original)
+++ libcxx/trunk/include/regex Mon Aug 24 10:57:09 2015
@@ -1733,6 +1733,8 @@ template 
 void
 __back_ref<_CharT>::__exec(__state& __s) const
 {
+if (__mexp_ > __s.__sub_matches_.size())
+__throw_regex_error();
 sub_match& __sm = __s.__sub_matches_[__mexp_-1];
 if (__sm.matched)
 {

Modified: libcxx/trunk/test/std/re/re.alg/re.alg.search/grep.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/re/re.alg/re.alg.search/grep.pass.cpp?rev=245849&r1=245848&r2=245849&view=diff
==
--- libcxx/trunk/test/std/re/re.alg/re.alg.search/grep.pass.cpp (original)
+++ libcxx/trunk/test/std/re/re.alg/re.alg.search/grep.pass.cpp Mon Aug 24 
10:57:09 2015
@@ -21,6 +21,28 @@
 
 #include "test_iterators.h"
 
+extern "C" void LLVMFuzzerTestOneInput(const char *data)
+{
+size_t size = strlen(data);
+if (size > 0)
+{
+try
+{
+std::regex::flag_type flag = std::regex_constants::grep;
+std::string s((const char *)data, size);
+std::regex re(s, flag);
+std::regex_match(s, re);
+} 
+catch (std::regex_error &ex) {} 
+} 
+}
+
+
+void fuzz_tests()  // patterns that the fuzzer has found
+{
+
LLVMFuzzerTestOneInput(R"XX(Õ)_%()()((\8'_%()_%()_%()_%(()_%()_%()_%(.t;)()¥f()_%()(.)_%;)()!¥f)()XX");
+}
+
 int main()
 {
 {
@@ -55,4 +77,5 @@ int main()
 assert(m.position(0) == 0);
 assert(m.str(0) == "");
 }
+fuzz_tests();
 }


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

[PATCH] D12287: Add replace-auto_ptr check.

[Angel Garcia via cfe-commits]

angelgarcia created this revision.
angelgarcia added a reviewer: alexfh.
angelgarcia added subscribers: cfe-commits, klimek.

Migrate replace-auto_ptr check from clang-modernize to modernize module in 
clang-tidy.

http://reviews.llvm.org/D12287

Files:
  clang-tidy/modernize/CMakeLists.txt
  clang-tidy/modernize/ModernizeTidyModule.cpp
  clang-tidy/modernize/ReplaceAutoPtrCheck.cpp
  clang-tidy/modernize/ReplaceAutoPtrCheck.h
  test/clang-tidy/Inputs/modernize-replace-auto-ptr/
  test/clang-tidy/Inputs/modernize-replace-auto-ptr/memory.h
  test/clang-tidy/modernize-replace-auto-ptr.cpp

Index: test/clang-tidy/modernize-replace-auto-ptr.cpp
===
--- /dev/null
+++ test/clang-tidy/modernize-replace-auto-ptr.cpp
@@ -0,0 +1,304 @@
+// RUN: %python %S/check_clang_tidy.py %s modernize-replace-auto-ptr %t -- \
+// RUN:   -std=c++11 -I %S/Inputs/modernize-replace-auto-ptr
+
+// CHECK-FIXES: #include 
+
+#include "memory.h"
+
+// Instrumentation for auto_ptr_ref test.
+struct Base {};
+struct Derived : Base {};
+std::auto_ptr create_derived_ptr();
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: auto_ptr is deprecated, use unique_ptr instead
+// CHECK-FIXES: std::unique_ptr create_derived_ptr();
+
+
+// Test function return values (declaration)
+std::auto_ptr f_5();
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: auto_ptr is deprecated, use unique_ptr instead
+// CHECK-FIXES: std::unique_ptr f_5()
+
+
+// Test function parameters.
+void f_6(std::auto_ptr);
+// CHECK-MESSAGES: :[[@LINE-1]]:15: warning: auto_ptr is deprecated, use unique_ptr instead
+// CHECK-FIXES: void f_6(std::unique_ptr);
+void f_7(const std::auto_ptr &);
+// CHECK-MESSAGES: :[[@LINE-1]]:21: warning: auto_ptr is deprecated, use unique_ptr instead
+// CHECK-FIXES: void f_7(const std::unique_ptr &);
+
+
+// Test on record type fields.
+struct A {
+  std::auto_ptr field;
+  // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: auto_ptr is deprecated, use unique_ptr instead
+  // CHECK-FIXES: std::unique_ptr field;
+
+  typedef std::auto_ptr int_ptr_type;
+  // CHECK-MESSAGES: :[[@LINE-1]]:16: warning: auto_ptr is deprecated, use unique_ptr instead
+  // CHECK-FIXES: typedef std::unique_ptr int_ptr_type;
+};
+
+
+// FIXME: Test template WITH instantiation.
+template  struct B {
+  typedef typename std::auto_ptr created_type;
+  // CHECK-MESSAGES: :[[@LINE-1]]:25: warning: auto_ptr is deprecated, use unique_ptr instead
+  // CHECK-FIXES: typedef typename std::unique_ptr created_type;
+
+  created_type create() { return std::auto_ptr(new T()); }
+  // CHECK-MESSAGES: :[[@LINE-1]]:39: warning: auto_ptr is deprecated, use unique_ptr instead
+  // CHECK-FIXES: created_type create() { return std::unique_ptr(new T()); }
+};
+
+
+// Test 'using' in a namespace (declaration)
+namespace ns_1 {
+// Test multiple using declarations.
+  using std::auto_ptr;
+  // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: auto_ptr is deprecated, use unique_ptr instead
+  // CHECK-FIXES: using std::unique_ptr;
+  using std::auto_ptr;
+  // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: auto_ptr is deprecated, use unique_ptr instead
+  // CHECK-FIXES: using std::unique_ptr;
+}
+
+
+namespace ns_2 {
+template  struct auto_ptr {};
+}
+
+void f_1() {
+  std::auto_ptr a;
+  // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: auto_ptr is deprecated, use unique_ptr instead
+  // CHECK-FIXES: std::unique_ptr a;
+
+  // Check that spaces aren't modified unnecessarily.
+  std:: auto_ptr  b;
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: auto_ptr is deprecated, use unique_ptr instead
+  // CHECK-FIXES: std:: unique_ptr  b;
+  std :: auto_ptr < char > c(new char());
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: auto_ptr is deprecated, use unique_ptr instead
+  // CHECK-FIXES: std :: unique_ptr < char > c(new char());
+
+  // Test construction from a temporary.
+  std::auto_ptr d = std::auto_ptr();
+  // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: auto_ptr is deprecated, use unique_ptr instead
+  // CHECK-MESSAGES: :[[@LINE-2]]:32: warning: auto_ptr is deprecated, use unique_ptr instead
+  // CHECK-FIXES: std::unique_ptr d = std::unique_ptr();
+
+  typedef std::auto_ptr int_ptr_t;
+  // CHECK-MESSAGES: :[[@LINE-1]]:16: warning: auto_ptr is deprecated, use unique_ptr instead
+  // CHECK-FIXES: typedef std::unique_ptr int_ptr_t;
+  int_ptr_t e(new int());
+
+  // Test pointers.
+  std::auto_ptr *f;
+  // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: auto_ptr is deprecated, use unique_ptr instead
+  // CHECK-FIXES: std::unique_ptr *f;
+
+  // Test 'static' declarations.
+  static std::auto_ptr g;
+  // CHECK-MESSAGES: :[[@LINE-1]]:15: warning: auto_ptr is deprecated, use unique_ptr instead
+  // CHECK-FIXES: static std::unique_ptr g;
+
+  // Test with cv-qualifiers.
+  const std::auto_ptr h;
+  // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: auto_ptr is deprecated, use unique_ptr instead
+  // CHECK-FIXES: const std::unique_ptr h;
+  volatile std::auto_ptr i;
+  // CHECK-ME

Re: [PATCH] D12148: [ARM] Allow passing/returning of __fp16 arguments

[Oliver Stannard via cfe-commits]

olista01 removed rL LLVM as the repository for this revision.
olista01 updated this revision to Diff 32967.
olista01 added a comment.

Use a switch statement to check the target architecture.


http://reviews.llvm.org/D12148

Files:
  lib/Basic/Targets.cpp
  lib/CodeGen/TargetInfo.cpp
  lib/Driver/Tools.cpp
  test/CodeGen/arm-fp16-arguments.c
  test/Preprocessor/arm-acle-6.5.c
  test/Preprocessor/arm-target-features.c

Index: test/Preprocessor/arm-target-features.c
===
--- test/Preprocessor/arm-target-features.c
+++ test/Preprocessor/arm-target-features.c
@@ -5,6 +5,8 @@
 // CHECK: __ARM_FEATURE_CRC32 1
 // CHECK: __ARM_FEATURE_DIRECTED_ROUNDING 1
 // CHECK: __ARM_FEATURE_NUMERIC_MAXMIN 1
+// CHECK: __ARM_FP16_ARGS 1
+// CHECK: __ARM_FP16_FORMAT_IEEE 1
 
 // RUN: %clang -target armv7a-none-linux-gnu -x c -E -dM %s -o - | FileCheck --check-prefix=CHECK-V7 %s
 // CHECK-V7: __ARMEL__ 1
Index: test/Preprocessor/arm-acle-6.5.c
===
--- test/Preprocessor/arm-acle-6.5.c
+++ test/Preprocessor/arm-acle-6.5.c
@@ -1,6 +1,6 @@
 // RUN: %clang -target arm-eabi -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-DEFAULT
 
-// CHECK-DEFAULT-NOT: __ARM_FP
+// CHECK-DEFAULT-NOT: __ARM_FP 0x
 
 // RUN: %clang -target arm-eabi -mfpu=vfp -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-SP-DP
 // RUN: %clang -target arm-eabi -mfpu=vfp3 -x c -E -dM %s -o - | FileCheck %s -check-prefix CHECK-SP-DP
Index: test/CodeGen/arm-fp16-arguments.c
===
--- /dev/null
+++ test/CodeGen/arm-fp16-arguments.c
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 -triple armv7a--none-eabi -target-abi aapcs -mfloat-abi soft -fallow-half-arguments-and-returns -emit-llvm -o - -O1 %s | FileCheck %s --check-prefix=CHECK --check-prefix=SOFT
+// RUN: %clang_cc1 -triple armv7a--none-eabi -target-abi aapcs -mfloat-abi hard -fallow-half-arguments-and-returns -emit-llvm -o - -O1 %s | FileCheck %s --check-prefix=CHECK --check-prefix=HARD
+
+__fp16 g;
+
+void t1(__fp16 a) { g = a; }
+// SOFT: define void @t1(i32 [[PARAM:%.*]])
+// SOFT: [[TRUNC:%.*]] = trunc i32 [[PARAM]] to i16
+// HARD: define arm_aapcs_vfpcc void @t1(float [[PARAM:%.*]])
+// HARD: [[BITCAST:%.*]] = bitcast float [[PARAM]] to i32
+// HARD: [[TRUNC:%.*]] = trunc i32 [[BITCAST]] to i16
+// CHECK: store i16 [[TRUNC]], i16* bitcast (half* @g to i16*)
+
+__fp16 t2() { return g; }
+// SOFT: define i32 @t2()
+// HARD: define arm_aapcs_vfpcc float @t2()
+// CHECK: [[LOAD:%.*]] = load i16, i16* bitcast (half* @g to i16*)
+// CHECK: [[ZEXT:%.*]] = zext i16 [[LOAD]] to i32
+// SOFT: ret i32 [[ZEXT]]
+// HARD: [[BITCAST:%.*]] = bitcast i32 [[ZEXT]] to float
+// HARD: ret float [[BITCAST]]
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -4250,9 +4250,19 @@
   CmdArgs.push_back("-mstack-probe-size=0");
   }
 
-  if (getToolChain().getArch() == llvm::Triple::aarch64 ||
-  getToolChain().getArch() == llvm::Triple::aarch64_be)
+  switch (getToolChain().getArch()) {
+  case llvm::Triple::aarch64:
+  case llvm::Triple::aarch64_be:
+  case llvm::Triple::arm:
+  case llvm::Triple::armeb:
+  case llvm::Triple::thumb:
+  case llvm::Triple::thumbeb:
 CmdArgs.push_back("-fallow-half-arguments-and-returns");
+break;
+
+  default:
+break;
+  }
 
   if (Arg *A = Args.getLastArg(options::OPT_mrestrict_it,
options::OPT_mno_restrict_it)) {
Index: lib/CodeGen/TargetInfo.cpp
===
--- lib/CodeGen/TargetInfo.cpp
+++ lib/CodeGen/TargetInfo.cpp
@@ -4714,6 +4714,15 @@
 return ABIArgInfo::getIndirect(0, /*ByVal=*/false);
   }
 
+  // __fp16 gets passed as if it were an int or float, but with the top 16 bits
+  // unspecified.
+  if (Ty->isHalfType()) {
+llvm::Type *ResType = IsEffectivelyAAPCS_VFP ?
+  llvm::Type::getFloatTy(getVMContext()) :
+  llvm::Type::getInt32Ty(getVMContext());
+return ABIArgInfo::getDirect(ResType);
+  }
+
   if (!isAggregateTypeForABI(Ty)) {
 // Treat an enum type as its underlying type.
 if (const EnumType *EnumTy = Ty->getAs()) {
@@ -4872,6 +4881,15 @@
 return ABIArgInfo::getIndirect(0);
   }
 
+  // __fp16 gets returned as if it were an int or float, but with the top 16
+  // bits unspecified.
+  if (RetTy->isHalfType()) {
+llvm::Type *ResType = IsEffectivelyAAPCS_VFP ?
+  llvm::Type::getFloatTy(getVMContext()) :
+  llvm::Type::getInt32Ty(getVMContext());
+return ABIArgInfo::getDirect(ResType);
+  }
+
   if (!isAggregateTypeForABI(RetTy)) {
 // Treat an enum type as its underlying type.
 if (const EnumType *EnumTy = RetTy->getAs())
Index: lib/Basic/Targets.cpp
===
--- lib/Basic/Targets.cpp
+

Re: [PATCH] D12271: [X86] Expose the various _rot intrinsics on non-MS platforms

[Reid Kleckner via cfe-commits]

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

This looks good.

As a larger issue, LLVM fast isel definitely won't pattern match this series of 
shifts and selects to rotl at -O0. There are some users who want branchless 
constant time rotates regardless of optimization level 
(https://llvm.org/bugs/show_bug.cgi?id=24226). My thinking is that the shifts 
are more analyzable to LLVM than an intrinsic, so we should leave these 
intrinsics alone and tell such users to use inline asm if they need these kinds 
of low-level guarantees. It still isn't very satisfactory. =/



Comment at: test/CodeGen/x86-rot-intrinsics.c:9-11
@@ +8,5 @@
+#else
+// Don't include mm_malloc.h, it's system specific.
+#define __MM_MALLOC_H
+#include 
+#endif

Any reason not to use -ffreestanding to deal with this on the Linux side of the 
test like we do for windows?


http://reviews.llvm.org/D12271



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

Re: [PATCH] D6551: Improvements to scan-build.

[Антон Ярцев via cfe-commits]

ayartsev updated this revision to Diff 32969.
ayartsev added a comment.

Updated the patch with r245621.
OK to commit?


http://reviews.llvm.org/D6551

Files:
  tools/scan-build/scan-build

Index: tools/scan-build/scan-build
===
--- tools/scan-build/scan-build
+++ tools/scan-build/scan-build
@@ -24,8 +24,8 @@
 use Term::ANSIColor qw(:constants);
 use Cwd qw/ getcwd abs_path /;
 use Sys::Hostname;
+use Hash::Util qw(lock_keys);
 
-my $Verbose = 0;   # Verbose output from this script.
 my $Prog = "scan-build";
 my $BuildName;
 my $BuildDate;
@@ -39,15 +39,40 @@
 my $UserName = HtmlEscape(getlogin() || getpwuid($<) || 'unknown');
 my $HostName = HtmlEscape(hostname() || 'unknown');
 my $CurrentDir = HtmlEscape(getcwd());
-my $CurrentDirSuffix = basename($CurrentDir);
 
-my @PluginsToLoad;
 my $CmdArgs;
 
-my $HtmlTitle;
-
 my $Date = localtime();
 
+# Command-line/config arguments.
+my %Options = (
+  Verbose => 0,  # Verbose output from this script.
+  AnalyzeHeaders => 0,
+  OutputDir => undef,# Parent directory to store HTML files.
+  HtmlTitle => basename($CurrentDir)." - scan-build results",
+  IgnoreErrors => 0, # Ignore build errors.
+  ViewResults => 0,  # View results when the build terminates.
+  ExitStatusFoundBugs => 0,  # Exit status reflects whether bugs were found
+  KeepEmpty => 0,# Don't remove output directory even with 0 results.
+  EnableCheckers => [],
+  DisableCheckers => [],
+  UseCC => undef,# C compiler to use for compilation.
+  UseCXX => undef,   # C++ compiler to use for compilation.
+  AnalyzerTarget => undef,
+  StoreModel => undef,
+  ConstraintsModel => undef,
+  InternalStats => undef,
+  OutputFormat => "html",
+  ConfigOptions => [],   # Options to pass through to the analyzer's -analyzer-config flag.
+  ReportFailures => undef,
+  AnalyzerStats => 0,
+  MaxLoop => 0,
+  PluginsToLoad => [],
+  AnalyzerDiscoveryMethod => undef,
+  OverrideCompiler => 0  # The flag corresponding to the --override-compiler command line option.
+);
+lock_keys(%Options);
+
 ####
 # Diagnostics
 ####
@@ -231,7 +256,7 @@
 return;
   }
 
-  if ($Verbose) {
+  if ($Options{Verbose}) {
 Diag("Emitting reports for this run to '$Dir'.\n");
   }
 
@@ -582,7 +607,7 @@
 print OUT <
 
-${HtmlTitle}
+${Options{HtmlTitle}}
 
 
 

LLVM buildmaster will be tonight

[Galina Kistanova via cfe-commits]

Hello everyone,

LLVM buildmaster will be restarted after 5 PM Pacific time today.

Thanks

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

Re: [PATCH] D11182: [OPENMP 4.0] Initial support for 'omp declare reduction' construct.

[Michael Wong via cfe-commits]

fraggamuffin added a comment.

Got it. Test results look good with this patch.

  Expected Passes: 7011
  Expected Failures  : 21
  Unsupported Tests  : 89
  Unexpected Failures: 47


http://reviews.llvm.org/D11182



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

Re: [PATCH] D10732: [OPENMP 4.0] Initial support for array sections.

[Alexey Bataev via cfe-commits]

ABataev marked 15 inline comments as done.
ABataev added a comment.

Richard, thanks for the review!



Comment at: include/clang/Basic/DiagnosticSemaKinds.td:7680
@@ +7679,3 @@
+def err_omp_section_length_undefined : Error<
+  "section length is unspecified, but subscripted value is not an array">;
+

rsmith wrote:
> How about "section length is unspecified and cannot be inferred because 
> subscripted value is not an array"?
> 
> Presumably there should also be an error for "section length is unspecified 
> and cannot be inferred because subscripted value is an array of unknown 
> bound"?
Done.


Comment at: lib/AST/ASTContext.cpp:1046-1047
@@ -1045,1 +1045,4 @@
 
+  // Placeholder type for OMP array sections.
+  InitBuiltinType(OMPArraySectionTy,  BuiltinType::OMPArraySection);
+

rsmith wrote:
> Condition this behind `if (LangOpts.OpenMP)`.
Done, thanks


Comment at: lib/AST/Stmt.cpp:18
@@ -17,2 +17,3 @@
 #include "clang/AST/ExprObjC.h"
+#include "clang/AST/ExprOpenMP.h"
 #include "clang/AST/Stmt.h"

rsmith wrote:
> This appears to be unused?
No, this one is required for getStmtInfoTableEntry(), check_implementations() 
and others.


Comment at: lib/Sema/SemaExpr.cpp:4001-4004
@@ +4000,6 @@
+  unsigned ArraySectionCount = 0;
+  while (auto *OASE = dyn_cast(Base)) {
+Base = OASE->getBase();
+++ArraySectionCount;
+  }
+  auto OriginalTy = Base->getType();

rsmith wrote:
> Should you `IgnoreParens()` here?
Yes, added.


Comment at: lib/Sema/SemaExpr.cpp:4006
@@ +4005,3 @@
+  auto OriginalTy = Base->getType();
+  for (unsigned i = 0; i < ArraySectionCount; ++i) {
+if (OriginalTy->isAnyPointerType())

rsmith wrote:
> Please either consistently capitalize (per prevailing style in this file), or 
> do not capitalize (per new LLVM coding style), your local variables; don't 
> mix and match.
Fixed, thanks.


Comment at: lib/Sema/SemaExpr.cpp:4017
@@ +4016,3 @@
+
+ExprResult Sema::ActOnOMPArraySectionExpr(Scope *S, Expr *Base,
+  SourceLocation LBLoc,

rsmith wrote:
> I don't think you should need a `Scope` here; you shouldn't be performing any 
> unqualified lookups while handling this expression.
Removed


Comment at: lib/Sema/SemaExpr.cpp:4072
@@ +4071,3 @@
+  if (LowerBound) {
+if (!LowerBound->getType()->isIntegerType())
+  return ExprError(Diag(LowerBound->getExprLoc(),

rsmith wrote:
> This should presumably follow the rules for the underlying language. In 
> particular, in C++, we should try to contextually implicitly convert to an 
> integral type -- see `Sema::PerformContextualImplicitConversion`).
Done.


Comment at: lib/Sema/SemaExpr.cpp:4110
@@ +4109,3 @@
+llvm::APSInt LowerBoundValue;
+if (LowerBound->EvaluateAsInt(LowerBoundValue, Context)) {
+  // OpenMP 4.0, [2.4 Array Sections]

rsmith wrote:
> Same comment here as before: using constant folding to drive an error is not 
> OK; you should only error here if the expression is an ICE.
Well, that is exactly what I'm doing here. I'm checking that this an ICE and 
only if LowerBound is ICE I'm checking its constraints. EvaluateAsInt() does 
not emit any errors if LowerBound is not ICE.


Comment at: lib/Sema/SemaExpr.cpp:4112
@@ +4111,3 @@
+  // OpenMP 4.0, [2.4 Array Sections]
+  // The lower-bound and length must evaluate to non-negative integers.
+  if (LowerBoundValue.isNegative()) {

rsmith wrote:
> Is this a constraint or a semantic rule? (Are we required to reject it, are 
> we permitted to reject it, or is a violation just UB?)
We are permitted to reject it.


Comment at: lib/Sema/SemaExpr.cpp:4146-4154
@@ +4145,11 @@
+  if (!LengthExpr) {
+if (ColonLoc.isInvalid()) {
+  LengthExpr = ActOnIntegerConstant(SourceLocation(), /*Val=*/1).get();
+} else {
+  if (auto *CAT =
+  dyn_cast(OriginalTy->getAsArrayTypeUnsafe())) 
{
+llvm::APInt SizeVal = CAT->getSize();
+LengthExpr = IntegerLiteral::Create(Context, SizeVal,
+Context.getIntPtrType(), RBLoc);
+  } else {
+auto *VAT = 
cast(OriginalTy->getAsArrayTypeUnsafe());

rsmith wrote:
> I'm not particularly happy about fabricating an expression here, especially 
> one with an invalid location. Maybe instead store a null `LengthExpr` in this 
> case and provide accessors on your AST node to determine whether it's an 
> implicit 1-element section or an implicit to-the-end section (maybe based on 
> whether `ColonLoc.isValid()`).
Ok, I'll remove all implicit expressions here and below and will build them in 
codegen.


http://reviews.llvm.org/D10732



___
cfe-commit

Re: [PATCH] D10732: [OPENMP 4.0] Initial support for array sections.

[Alexey Bataev via cfe-commits]

ABataev updated this revision to Diff 32974.
ABataev marked 10 inline comments as done.
ABataev added a comment.

Update after review


http://reviews.llvm.org/D10732

Files:
  include/clang-c/Index.h
  include/clang/AST/ASTContext.h
  include/clang/AST/BuiltinTypes.def
  include/clang/AST/DataRecursiveASTVisitor.h
  include/clang/AST/ExprOpenMP.h
  include/clang/AST/RecursiveASTVisitor.h
  include/clang/AST/StmtVisitor.h
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/StmtNodes.td
  include/clang/Sema/Sema.h
  include/clang/Serialization/ASTBitCodes.h
  lib/AST/ASTContext.cpp
  lib/AST/Expr.cpp
  lib/AST/ExprClassification.cpp
  lib/AST/ExprConstant.cpp
  lib/AST/ItaniumMangle.cpp
  lib/AST/NSAPI.cpp
  lib/AST/Stmt.cpp
  lib/AST/StmtPrinter.cpp
  lib/AST/StmtProfile.cpp
  lib/AST/Type.cpp
  lib/AST/TypeLoc.cpp
  lib/Parse/ParseExpr.cpp
  lib/Sema/SemaChecking.cpp
  lib/Sema/SemaExceptionSpec.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTCommon.cpp
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTReaderStmt.cpp
  lib/Serialization/ASTWriterStmt.cpp
  lib/StaticAnalyzer/Checkers/DereferenceChecker.cpp
  lib/StaticAnalyzer/Checkers/IdenticalExprChecker.cpp
  lib/StaticAnalyzer/Core/ExprEngine.cpp
  test/OpenMP/task_ast_print.cpp
  test/OpenMP/task_depend_messages.cpp
  tools/libclang/CIndex.cpp
  tools/libclang/CXCursor.cpp

Index: lib/Serialization/ASTWriterStmt.cpp
===
--- lib/Serialization/ASTWriterStmt.cpp
+++ lib/Serialization/ASTWriterStmt.cpp
@@ -511,6 +511,16 @@
   Code = serialization::EXPR_ARRAY_SUBSCRIPT;
 }
 
+void ASTStmtWriter::VisitOMPArraySectionExpr(OMPArraySectionExpr *E) {
+  VisitExpr(E);
+  Writer.AddStmt(E->getBase());
+  Writer.AddStmt(E->getLowerBound());
+  Writer.AddStmt(E->getLength());
+  Writer.AddSourceLocation(E->getColonLoc(), Record);
+  Writer.AddSourceLocation(E->getRBracketLoc(), Record);
+  Code = serialization::EXPR_OMP_ARRAY_SECTION;
+}
+
 void ASTStmtWriter::VisitCallExpr(CallExpr *E) {
   VisitExpr(E);
   Record.push_back(E->getNumArgs());
Index: lib/Serialization/ASTReaderStmt.cpp
===
--- lib/Serialization/ASTReaderStmt.cpp
+++ lib/Serialization/ASTReaderStmt.cpp
@@ -589,6 +589,15 @@
   E->setRBracketLoc(ReadSourceLocation(Record, Idx));
 }
 
+void ASTStmtReader::VisitOMPArraySectionExpr(OMPArraySectionExpr *E) {
+  VisitExpr(E);
+  E->setBase(Reader.ReadSubExpr());
+  E->setLowerBound(Reader.ReadSubExpr());
+  E->setLength(Reader.ReadSubExpr());
+  E->setColonLoc(ReadSourceLocation(Record, Idx));
+  E->setRBracketLoc(ReadSourceLocation(Record, Idx));
+}
+
 void ASTStmtReader::VisitCallExpr(CallExpr *E) {
   VisitExpr(E);
   E->setNumArgs(Reader.getContext(), Record[Idx++]);
@@ -2532,6 +2541,10 @@
   S = new (Context) ArraySubscriptExpr(Empty);
   break;
 
+case EXPR_OMP_ARRAY_SECTION:
+  S = new (Context) OMPArraySectionExpr(Empty);
+  break;
+
 case EXPR_CALL:
   S = new (Context) CallExpr(Context, Stmt::CallExprClass, Empty);
   break;
Index: lib/Serialization/ASTReader.cpp
===
--- lib/Serialization/ASTReader.cpp
+++ lib/Serialization/ASTReader.cpp
@@ -5824,6 +5824,10 @@
 case PREDEF_TYPE_BUILTIN_FN:
   T = Context.BuiltinFnTy;
   break;
+
+case PREDEF_TYPE_OMP_ARRAY_SECTION:
+  T = Context.OMPArraySectionTy;
+  break;
 }
 
 assert(!T.isNull() && "Unknown predefined type");
Index: lib/Serialization/ASTCommon.cpp
===
--- lib/Serialization/ASTCommon.cpp
+++ lib/Serialization/ASTCommon.cpp
@@ -72,6 +72,7 @@
   case BuiltinType::OCLEvent: ID = PREDEF_TYPE_EVENT_ID;break;
   case BuiltinType::BuiltinFn:
 ID = PREDEF_TYPE_BUILTIN_FN; break;
+  case BuiltinType::OMPArraySection:  ID = PREDEF_TYPE_OMP_ARRAY_SECTION; break;
 
   }
 
Index: lib/Parse/ParseExpr.cpp
===
--- lib/Parse/ParseExpr.cpp
+++ lib/Parse/ParseExpr.cpp
@@ -1396,21 +1396,42 @@
   BalancedDelimiterTracker T(*this, tok::l_square);
   T.consumeOpen();
   Loc = T.getOpenLocation();
-  ExprResult Idx;
+  ExprResult Idx, Length;
+  SourceLocation ColonLoc;
   if (getLangOpts().CPlusPlus11 && Tok.is(tok::l_brace)) {
 Diag(Tok, diag::warn_cxx98_compat_generalized_initializer_lists);
 Idx = ParseBraceInitializer();
+  } else if (getLangOpts().OpenMP) {
+ColonProtectionRAIIObject RAII(*this);
+// Parse [: or [ expr or [ expr :
+if (!Tok.is(tok::colon)) {
+  // [ expr
+  Idx = ParseExpression();
+}
+if (Tok.is(tok::colon)) {
+  // Consume ':'
+  ColonLoc = ConsumeToken();
+  if (Tok

Re: [PATCH] D11468: [Static Analyzer] The first implementation of nullability checker.

[Gábor Horváth via cfe-commits]

xazax.hun marked 11 inline comments as done.
xazax.hun added a comment.

Thank you for the review. I will upload the new version of the patch once the 
rest of it was reviewed.



Comment at: lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp:12
@@ +11,3 @@
+// checker is that, the user is running this checker after all the nullability
+// warnings that is emitted by the compiler was fixed.
+//

zaks.anna wrote:
> "is" -> "are"
> 
> How are we relying on this assumption? What happens if they are not fixed?
> 
> Also we should describe what we mean by nullability warnings, maybe refer to 
> the annotations themselves here? It would be great to give a high level 
> overflow of the algorithm and maybe even talk about the difference between 
> the checks?
There are no assumptions like that in the code of the checker right now. I 
updated the comment to reflect that.


Comment at: lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp:54
@@ +53,3 @@
+  return static_cast(
+  std::min(static_cast(Lhs), static_cast(Rhs)));
+}

zaks.anna wrote:
> ??
Added a comment to clarify what it is and how it is used.


Comment at: lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp:192
@@ +191,3 @@
+
+static bool shouldTrackRegion(const MemRegion *Region,
+  AnalysisDeclContext *DeclContext) {

zaks.anna wrote:
> Is this used for optimization purposes? Can you describe the rules we use 
> here?
> 
> What's the benefit of not tracking self?
Initially it was not just an optimization. It was also intended to deal with 
the caching out issue, but eventually it turned out that caching out was ok, 
and not an error in the checker. I did not erase the code afterwards.

There are several possibilities now:
* Leave this part as it is.
* Only track symbolic regions.
* Delete this function.

Which one do you prefer?



Comment at: lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp:267
@@ +266,3 @@
+return Nullability::Nonnull;
+  return Nullability::Unspecified;
+}

zaks.anna wrote:
> shouldn't this be an llvm_unreachable?
There are several AttrKind.
Source: 
http://clang.llvm.org/doxygen/classclang_1_1AttributedType.html#ab4901f7a37f5539698cb5ebd706245ed

So that code is not unreachable.


Comment at: lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp:298
@@ +297,3 @@
+TrackedNullability = State->get(
+Region->getAs()->getSuperRegion());
+if (!TrackedNullability)

zaks.anna wrote:
> Are we sure that if "!TrackedNullability", the event complains about a 
> dereference on the parent (like field access)?
Sometimes when there is an expression like p[0] or p->field, the event contains 
the region for the element or the field region. However the tracked information 
is only available for p. For this reason I also check whether the super region 
has some tracked nullability and complain about that region in this case.


http://reviews.llvm.org/D11468



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

Re: [PATCH] D12169: Relax constexpr rules to improve __builtin_object_size's accuracy

[George Burgess IV via cfe-commits]

george.burgess.iv updated this revision to Diff 32985.
george.burgess.iv added a comment.

Mostly redid the patch; removed OutermostExprEvaluator, moved evaluation intent 
into `EvaluationMode`, made it so the more interesting rulebreaking that 
`__builtin_object_size` allows is only allowed when evaluating 
`__builtin_object_size`.

Not entirely sold on adding 4 EvaluationModes, but we need to know two bits of 
information, both of which impact how we evaluate things:

- Whether we're evaluating an actual ConstantExpression or a 
PotentialConstantExpression (if we always assume the former, we get memory 
corruption by reaching into `CallStackFrame::Arguments` sometimes; if we assume 
the latter, `attribute(enable_if)` breaks).
- If we're allowed to assume that the base of a `MemberExpr` is valid.

Also, I'm not 100% on calling `LValue.set(MaybeAnRValue)` if we are assuming 
that the base of a `MemberExpr` is valid. However, in such a case, I would 
think that it's safe to assume that the caller doesn't care about the base. 
Plus, it's In The Documentation(TM) that you shouldn't rely on 
`Result.getLValueBase()` being a valid base when the EvalMode would allow this 
assumption to be made.


http://reviews.llvm.org/D12169

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

Index: test/CodeGen/object-size.c
===
--- test/CodeGen/object-size.c
+++ test/CodeGen/object-size.c
@@ -161,6 +161,15 @@
   gi = __builtin_object_size(&foo.a, 2);
   // CHECK: store i32 4
   gi = __builtin_object_size(&foo.a, 3);
+
+  // CHECK: store i32 4
+  gi = __builtin_object_size(&foo.b, 0);
+  // CHECK: store i32 4
+  gi = __builtin_object_size(&foo.b, 1);
+  // CHECK: store i32 4
+  gi = __builtin_object_size(&foo.b, 2);
+  // CHECK: store i32 4
+  gi = __builtin_object_size(&foo.b, 3);
 }
 
 // CHECK: @test20
@@ -221,25 +230,59 @@
   gi = __builtin_object_size(&t[9].t[10], 2);
   // CHECK: store i32 0
   gi = __builtin_object_size(&t[9].t[10], 3);
+
+  // CHECK: store i32 0
+  gi = __builtin_object_size((char*)&t[0] + sizeof(t), 0);
+  // CHECK: store i32 0
+  gi = __builtin_object_size((char*)&t[0] + sizeof(t), 1);
+  // CHECK: store i32 0
+  gi = __builtin_object_size((char*)&t[0] + sizeof(t), 2);
+  // CHECK: store i32 0
+  gi = __builtin_object_size((char*)&t[0] + sizeof(t), 3);
+
+  // CHECK: store i32 0
+  gi = __builtin_object_size((char*)&t[9].t[0] + 10*sizeof(t[0].t), 0);
+  // CHECK: store i32 0
+  gi = __builtin_object_size((char*)&t[9].t[0] + 10*sizeof(t[0].t), 1);
+  // CHECK: store i32 0
+  gi = __builtin_object_size((char*)&t[9].t[0] + 10*sizeof(t[0].t), 2);
+  // CHECK: store i32 0
+  gi = __builtin_object_size((char*)&t[9].t[0] + 10*sizeof(t[0].t), 3);
 }
 
-struct Test23Ty { int t[10]; };
+struct Test23Ty { int a; int t[10]; };
 
 // CHECK: @test23
-void test23(struct Test22Ty *p) {
+void test23(struct Test23Ty *p) {
   // CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* %{{.*}}, i1 false)
   gi = __builtin_object_size(p, 0);
   // CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* %{{.*}}, i1 false)
   gi = __builtin_object_size(p, 1);
   // CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* %{{.*}}, i1 true)
   gi = __builtin_object_size(p, 2);
-
   // Note: this is currently fixed at 0 because LLVM doesn't have sufficient
   // data to correctly handle type=3
   // CHECK: store i32 0
   gi = __builtin_object_size(p, 3);
-}
 
+  // CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* %{{.*}}, i1 false)
+  gi = __builtin_object_size(&p->a, 0);
+  // CHECK: store i32 4
+  gi = __builtin_object_size(&p->a, 1);
+  // CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* %{{.*}}, i1 true)
+  gi = __builtin_object_size(&p->a, 2);
+  // CHECK: store i32 4
+  gi = __builtin_object_size(&p->a, 3);
+
+  // CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* %{{.*}}, i1 false)
+  gi = __builtin_object_size(&p->t[5], 0);
+  // CHECK: store i32 20
+  gi = __builtin_object_size(&p->t[5], 1);
+  // CHECK: call i64 @llvm.objectsize.i64.p0i8(i8* %{{.*}}, i1 true)
+  gi = __builtin_object_size(&p->t[5], 2);
+  // CHECK: store i32 20
+  gi = __builtin_object_size(&p->t[5], 3);
+}
 
 // PR24493 -- ICE if __builtin_object_size called with NULL and (Type & 1) != 0
 // CHECK @test24
@@ -280,3 +323,72 @@
   // CHECK: store i32 0
   gi = __builtin_object_size((void*)0 + 0x1000, 3);
 }
+
+// CHECK: @test26
+void test26(struct Test23Ty *p) {
+  struct { int t[10]; } t[10];
+
+  // CHECK: store i32 356
+  gi = __builtin_object_size((char*)&t[1].t[1], 0);
+  // CHECK: store i32 36
+  gi = __builtin_object_size((char*)&t[1].t[1], 1);
+  // CHECK: store i32 356
+  gi = __builtin_object_size((char*)&t[1].t[1], 2);
+  // CHECK: store i32 36
+  gi = __builtin_object_size((char*)&t[1].t[1], 3);
+}
+
+// CHECK: @test27
+void test27() {
+  struct { int t[10]; } t[10];
+
+  // CHECK: store i32 359
+  gi = __builtin_object_size((char*)&t[1].t[0]+1, 0);
+  // CHECK: store i32 39
+  gi = __builtin_object_siz

Re: [PATCH] D12022: Refactored dtor sanitizing into EHScopeStack

[Naomi Musgrave via cfe-commits]

nmusgrave updated this revision to Diff 32986.
nmusgrave added a comment.

- Refactored for simpler trivial field checking


http://reviews.llvm.org/D12022

Files:
  lib/CodeGen/CGCXX.cpp
  lib/CodeGen/CGClass.cpp
  lib/CodeGen/CodeGenModule.h
  test/CodeGenCXX/sanitize-dtor-nontrivial-virtual-base.cpp
  test/CodeGenCXX/sanitize-dtor-repress-aliasing.cpp

Index: test/CodeGenCXX/sanitize-dtor-repress-aliasing.cpp
===
--- /dev/null
+++ test/CodeGenCXX/sanitize-dtor-repress-aliasing.cpp
@@ -0,0 +1,30 @@
+// Test -fsanitize-memory-use-after-dtor
+// RUN: %clang_cc1 -fsanitize=memory -O1 -fsanitize-memory-use-after-dtor -std=c++11 -triple=x86_64-pc-linux -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -fsanitize=memory -O2 -fsanitize-memory-use-after-dtor -std=c++11 -triple=x86_64-pc-linux -emit-llvm -o - %s | FileCheck %s
+
+template 
+class Vector {
+public:
+  int size;
+  ~Vector() {}
+};
+
+// Virtual function table for the derived class only contains
+// its own destructors, with no aliasing to base class dtors.
+struct Base {
+  Vector v;
+  int x;
+  Base() { x = 5; }
+  virtual ~Base() {}
+};
+
+struct Derived : public Base {
+  int z;
+  Derived() { z = 10; }
+  ~Derived() {}
+};
+
+Derived d;
+
+// Definition of virtual function table
+// CHECK: @_ZTV7Derived = {{.*}}(void (%struct.Derived*)* @_ZN7DerivedD1Ev to i8*){{.*}}(void (%struct.Derived*)* @_ZN7DerivedD0Ev to i8*)
Index: test/CodeGenCXX/sanitize-dtor-nontrivial-virtual-base.cpp
===
--- /dev/null
+++ test/CodeGenCXX/sanitize-dtor-nontrivial-virtual-base.cpp
@@ -0,0 +1,82 @@
+// RUN: %clang_cc1 -fsanitize=memory -O0 -fsanitize-memory-use-after-dtor -std=c++11 -triple=x86_64-pc-linux -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -fsanitize=memory -O1 -fsanitize-memory-use-after-dtor -std=c++11 -triple=x86_64-pc-linux -emit-llvm -o - %s | FileCheck %s
+
+template 
+class Vector {
+public:
+  int size;
+  ~Vector() {
+size += 1;
+  }
+};
+
+struct Base {
+  int b1;
+  double b2;
+  Base() {
+b1 = 5;
+b2 = 10.989;
+  }
+  virtual ~Base() {}
+};
+
+struct VirtualBase {
+  int vb1;
+  int vb2;
+  VirtualBase() {
+vb1 = 10;
+vb2 = 11;
+  }
+  virtual ~VirtualBase() {}
+};
+
+struct Derived : public Base, public virtual VirtualBase {
+  int d1;
+  Vector v;
+  int d2;
+  Derived() {
+d1 = 10;
+  }
+  ~Derived() {}
+};
+
+Derived d;
+
+// Destruction order:
+// Derived: int, Vector, Base, VirtualBase
+
+// CHECK-LABEL: define {{.*}}ZN7DerivedD1Ev
+// CHECK: call void {{.*}}ZN11VirtualBaseD2Ev
+// CHECK: ret void
+
+// CHECK-LABEL: define {{.*}}ZN7DerivedD0Ev
+// CHECK: ret void
+
+// CHECK-LABEL: define {{.*}}ZN11VirtualBaseD1Ev
+// CHECK: ret void
+
+// CHECK-LABEL: define {{.*}}ZN11VirtualBaseD0Ev
+// CHECK: ret void
+
+// poison 2 ints
+// CHECK-LABEL: define {{.*}}ZN11VirtualBaseD2Ev
+// CHECK: call void {{.*}}sanitizer_dtor_callback({{.*}}, i64 8)
+// CHECK: ret void
+
+// poison int and double
+// CHECK-LABEL: define {{.*}}ZN4BaseD2Ev
+// CHECK: call void {{.*}}sanitizer_dtor_callback({{.*}}, i64 16)
+// CHECK: ret void
+
+// poison int, ignore vector, poison int
+// CHECK-LABEL: define {{.*}}ZN7DerivedD2Ev
+// CHECK: call void {{.*}}ZN6VectorIiED1Ev
+// CHECK: call void {{.*}}sanitizer_dtor_callback({{.*}}, i64 4)
+// CHECK: call void {{.*}}sanitizer_dtor_callback({{.*}}, i64 4)
+// CHECK: call void {{.*}}ZN4BaseD2Ev
+// CHECK: ret void
+
+// poison int
+// CHECK-LABEL: define {{.*}}ZN6VectorIiED2Ev
+// CHECK: call void {{.*}}sanitizer_dtor_callback({{.*}}, i64 4)
+// CHECK: ret void
Index: lib/CodeGen/CodeGenModule.h
===
--- lib/CodeGen/CodeGenModule.h
+++ lib/CodeGen/CodeGenModule.h
@@ -1098,6 +1098,13 @@
   /// are emitted lazily.
   void EmitGlobal(GlobalDecl D);
 
+  bool
+  HasTrivialDestructorBody(ASTContext &Context,
+   const CXXRecordDecl *BaseClassDecl,
+   const CXXRecordDecl *MostDerivedClassDecl);
+  bool
+  FieldHasTrivialDestructorBody(ASTContext &Context, const FieldDecl *Field);
+
   bool TryEmitDefinitionAsAlias(GlobalDecl Alias, GlobalDecl Target,
 bool InEveryTU);
   bool TryEmitBaseDestructorAsAlias(const CXXDestructorDecl *D);
Index: lib/CodeGen/CGClass.cpp
===
--- lib/CodeGen/CGClass.cpp
+++ lib/CodeGen/CGClass.cpp
@@ -1286,11 +1286,7 @@
   CM.finish();
 }
 
-static bool
-FieldHasTrivialDestructorBody(ASTContext &Context, const FieldDecl *Field);
-
-static bool
-HasTrivialDestructorBody(ASTContext &Context,
+bool CodeGenModule::HasTrivialDestructorBody(ASTContext &Context,
  const CXXRecordDecl *BaseClassDecl,
  const CXXRecordDecl *MostDerivedClassDecl)
 {
@@ -1332,10 +1328,12 @@
   return true;
 }
 
-static

r245861 - Fixing some copy-pasta comments; NFC.

[Aaron Ballman via cfe-commits]

Author: aaronballman
Date: Mon Aug 24 13:50:01 2015
New Revision: 245861

URL: http://llvm.org/viewvc/llvm-project?rev=245861&view=rev
Log:
Fixing some copy-pasta comments; NFC.

Modified:
cfe/trunk/include/clang/AST/Decl.h

Modified: cfe/trunk/include/clang/AST/Decl.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Decl.h?rev=245861&r1=245860&r2=245861&view=diff
==
--- cfe/trunk/include/clang/AST/Decl.h (original)
+++ cfe/trunk/include/clang/AST/Decl.h Mon Aug 24 13:50:01 2015
@@ -1847,7 +1847,7 @@ public:
   bool isConstexpr() const { return IsConstexpr; }
   void setConstexpr(bool IC) { IsConstexpr = IC; }
 
-  /// Whether this is a (C++11) constexpr function or constexpr constructor.
+  /// \brief Indicates the function uses __try.
   bool usesSEHTry() const { return UsesSEHTry; }
   void setUsesSEHTry(bool UST) { UsesSEHTry = UST; }
 


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

[libcxx] r245864 - Add release goals to TODO.txt

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Mon Aug 24 14:33:40 2015
New Revision: 245864

URL: http://llvm.org/viewvc/llvm-project?rev=245864&view=rev
Log:
Add release goals to TODO.txt

Modified:
libcxx/trunk/TODO.TXT

Modified: libcxx/trunk/TODO.TXT
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/TODO.TXT?rev=245864&r1=245863&r2=245864&view=diff
==
--- libcxx/trunk/TODO.TXT (original)
+++ libcxx/trunk/TODO.TXT Mon Aug 24 14:33:40 2015
@@ -1,5 +1,15 @@
 This is meant to be a general place to list things that should be done 
"someday"
 
+3.8 Release Goals
+=
+* LFTS v1 (EricWF, MClow)
+* Filesystem TS (EricWF)
+* ASIO TS (MClow)
+*  Improvements (MClow)
+* Setup ABI Versioning policy (EricWF)
+* Fix PR19302 - Fix UB in list and __tree.
+
+
 ABI Related Tasks
 =
 * Explicitly manage and verify symbols exported from the dylib.


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

r245866 - [ARM] Error out on apple darwin platforms if float-abi is "hard".

[Akira Hatanaka via cfe-commits]

Author: ahatanak
Date: Mon Aug 24 14:50:35 2015
New Revision: 245866

URL: http://llvm.org/viewvc/llvm-project?rev=245866&view=rev
Log:
[ARM] Error out on apple darwin platforms if float-abi is "hard".

Error out if the user tries to use float-abi="hard" since it isn't
supported on darwin platforms. Previously clang issued no warnings or
erros and just passed the option to the backend, which had no effect on
code generation for targets using apcs.

rdar://problem/22257950

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

Added:
cfe/trunk/test/Driver/arm-float-abi.c
Modified:
cfe/trunk/lib/Driver/Tools.cpp

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=245866&r1=245865&r2=245866&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Mon Aug 24 14:50:35 2015
@@ -582,6 +582,10 @@ StringRef tools::arm::getARMFloatABI(con
 FloatABI = "soft";
   }
 }
+
+if (Triple.isOSDarwin() && FloatABI == "hard")
+  D.Diag(diag::err_drv_unsupported_opt_for_target) << A->getAsString(Args)
+   << Triple.getArchName();
   }
 
   // If unspecified, choose the default based on the platform.

Added: cfe/trunk/test/Driver/arm-float-abi.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/arm-float-abi.c?rev=245866&view=auto
==
--- cfe/trunk/test/Driver/arm-float-abi.c (added)
+++ cfe/trunk/test/Driver/arm-float-abi.c Mon Aug 24 14:50:35 2015
@@ -0,0 +1,5 @@
+// RUN: not %clang %s -target armv7-apple-ios -mfloat-abi=hard 2>&1 | 
FileCheck -check-prefix=ARMV7-HARD %s
+// RUN: %clang %s -target armv7-apple-ios -mfloat-abi=softfp -### 2>&1 | 
FileCheck -check-prefix=ARMV7-SOFTFP %s
+
+// ARMV7-HARD: unsupported option '-mfloat-abi=hard' for target 'thumbv7'
+// ARMV7-SOFTFP-NOT: unsupported option


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

r245867 - [libclang] For convenience to clients, make sure that nullability and __kindof annotations do not hide

[Argyrios Kyrtzidis via cfe-commits]

Author: akirtzidis
Date: Mon Aug 24 14:50:45 2015
New Revision: 245867

URL: http://llvm.org/viewvc/llvm-project?rev=245867&view=rev
Log:
[libclang] For convenience to clients, make sure that nullability and __kindof 
annotations do not hide
the underlying type.

rdar://22063577

Modified:
cfe/trunk/test/Index/get-cursor.m
cfe/trunk/test/Index/print-type.m
cfe/trunk/tools/libclang/CXType.cpp

Modified: cfe/trunk/test/Index/get-cursor.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/get-cursor.m?rev=245867&r1=245866&r2=245867&view=diff
==
--- cfe/trunk/test/Index/get-cursor.m (original)
+++ cfe/trunk/test/Index/get-cursor.m Mon Aug 24 14:50:45 2015
@@ -112,6 +112,23 @@ void foo3(Test3 *test3) {
 @property (retain) id propProp3;
 @end
 
+@interface TestNullability
+@property (strong, nonnull) id prop1;
+@property (strong, nullable) id prop2;
+@end
+
+@implementation TestNullability
+- (void)meth {
+  TestNullability *o;
+  [o.prop1 meth];
+  [o.prop2 meth];
+  _Nullable id lo1;
+  _Nonnull id lo2;
+  [lo1 meth];
+  [lo2 meth];
+}
+@end
+
 
 // RUN: c-index-test -cursor-at=%s:4:28 -cursor-at=%s:5:28 %s | FileCheck 
-check-prefix=CHECK-PROP %s
 // CHECK-PROP: ObjCPropertyDecl=foo1:4:26
@@ -170,3 +187,9 @@ void foo3(Test3 *test3) {
 // CHECK-OBJCOPTIONAL: 108:23 ObjCPropertyDecl=propProp2:108:23 (@optional) 
[retain,] Extent=[108:1 - 108:32]
 // CHECK-OBJCOPTIONAL: 111:8 ObjCInstanceMethodDecl=protMeth3:111:8 
Extent=[111:1 - 111:18]
 // CHECK-OBJCOPTIONAL: 112:23 ObjCPropertyDecl=propProp3:112:23 [retain,] 
Extent=[112:1 - 112:32]
+
+// RUN: c-index-test -cursor-at=%s:123:12 %s | FileCheck 
-check-prefix=CHECK-RECEIVER-WITH-NULLABILITY %s
+// RUN: c-index-test -cursor-at=%s:124:12 %s | FileCheck 
-check-prefix=CHECK-RECEIVER-WITH-NULLABILITY %s
+// RUN: c-index-test -cursor-at=%s:127:8 %s | FileCheck 
-check-prefix=CHECK-RECEIVER-WITH-NULLABILITY %s
+// RUN: c-index-test -cursor-at=%s:128:8 %s | FileCheck 
-check-prefix=CHECK-RECEIVER-WITH-NULLABILITY %s
+// CHECK-RECEIVER-WITH-NULLABILITY: Receiver-type=ObjCId

Modified: cfe/trunk/test/Index/print-type.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/print-type.m?rev=245867&r1=245866&r2=245867&view=diff
==
--- cfe/trunk/test/Index/print-type.m (original)
+++ cfe/trunk/test/Index/print-type.m Mon Aug 24 14:50:45 2015
@@ -3,6 +3,7 @@
 -(int) mymethod;
 -(const id) mymethod2:(id)x blah:(Class)y boo:(SEL)z;
 -(bycopy)methodIn:(in int)i andOut:(out short *)j , ...;
+-(void)kindof_meth:(__kindof Foo *)p;
 @end
 
 // RUN: c-index-test -test-print-type %s | FileCheck %s
@@ -13,3 +14,4 @@
 // CHECK: ObjCInstanceMethodDecl=methodIn:andOut::5:10 (variadic) [Bycopy,] 
[type=] [typekind=Invalid] [resulttype=id] [resulttypekind=ObjCId] [args= [int] 
[Int] [short *] [Pointer]] [isPOD=0]
 // CHECK: ParmDecl=i:5:27 (Definition) [In,] [type=int] [typekind=Int] 
[isPOD=1]
 // CHECK: ParmDecl=j:5:49 (Definition) [Out,] [type=short *] 
[typekind=Pointer] [isPOD=1] [pointeetype=short] [pointeekind=Short]
+// CHECK: ParmDecl=p:6:36 (Definition) [type=__kindof Foo *] 
[typekind=ObjCObjectPointer] [canonicaltype=__kindof Foo *] 
[canonicaltypekind=ObjCObjectPointer] [isPOD=1] [pointeetype=Foo] 
[pointeekind=ObjCInterface]

Modified: cfe/trunk/tools/libclang/CXType.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/libclang/CXType.cpp?rev=245867&r1=245866&r2=245867&view=diff
==
--- cfe/trunk/tools/libclang/CXType.cpp (original)
+++ cfe/trunk/tools/libclang/CXType.cpp Mon Aug 24 14:50:45 2015
@@ -101,6 +101,11 @@ CXType cxtype::MakeCXType(QualType T, CX
   CXTypeKind TK = CXType_Invalid;
 
   if (TU && !T.isNull()) {
+// Handle attributed types as the original type
+if (auto *ATT = T->getAs()) {
+  return MakeCXType(ATT->getModifiedType(), TU);
+}
+
 ASTContext &Ctx = cxtu::getASTUnit(TU)->getASTContext();
 if (Ctx.getLangOpts().ObjC1) {
   QualType UnqualT = T.getUnqualifiedType();


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

Re: [PATCH] D11690: [CUDA] Added stubs for new attributes used by CUDA headers.

[Artem Belevich via cfe-commits]

tra abandoned this revision.
tra added a comment.

There is no way to close revision. Abandoning it to get it off my list of 
pending changes.


http://reviews.llvm.org/D11690



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

Re: [PATCH] D12155: ARM: Error out on apple darwin platforms if float-abi is "hard"

[Akira Hatanaka via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL245866: [ARM] Error out on apple darwin platforms if 
float-abi is "hard". (authored by ahatanak).

Changed prior to commit:
  http://reviews.llvm.org/D12155?vs=32561&id=32989#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D12155

Files:
  cfe/trunk/lib/Driver/Tools.cpp
  cfe/trunk/test/Driver/arm-float-abi.c

Index: cfe/trunk/test/Driver/arm-float-abi.c
===
--- cfe/trunk/test/Driver/arm-float-abi.c
+++ cfe/trunk/test/Driver/arm-float-abi.c
@@ -0,0 +1,5 @@
+// RUN: not %clang %s -target armv7-apple-ios -mfloat-abi=hard 2>&1 | 
FileCheck -check-prefix=ARMV7-HARD %s
+// RUN: %clang %s -target armv7-apple-ios -mfloat-abi=softfp -### 2>&1 | 
FileCheck -check-prefix=ARMV7-SOFTFP %s
+
+// ARMV7-HARD: unsupported option '-mfloat-abi=hard' for target 'thumbv7'
+// ARMV7-SOFTFP-NOT: unsupported option
Index: cfe/trunk/lib/Driver/Tools.cpp
===
--- cfe/trunk/lib/Driver/Tools.cpp
+++ cfe/trunk/lib/Driver/Tools.cpp
@@ -582,6 +582,10 @@
 FloatABI = "soft";
   }
 }
+
+if (Triple.isOSDarwin() && FloatABI == "hard")
+  D.Diag(diag::err_drv_unsupported_opt_for_target) << A->getAsString(Args)
+   << Triple.getArchName();
   }
 
   // If unspecified, choose the default based on the platform.


Index: cfe/trunk/test/Driver/arm-float-abi.c
===
--- cfe/trunk/test/Driver/arm-float-abi.c
+++ cfe/trunk/test/Driver/arm-float-abi.c
@@ -0,0 +1,5 @@
+// RUN: not %clang %s -target armv7-apple-ios -mfloat-abi=hard 2>&1 | FileCheck -check-prefix=ARMV7-HARD %s
+// RUN: %clang %s -target armv7-apple-ios -mfloat-abi=softfp -### 2>&1 | FileCheck -check-prefix=ARMV7-SOFTFP %s
+
+// ARMV7-HARD: unsupported option '-mfloat-abi=hard' for target 'thumbv7'
+// ARMV7-SOFTFP-NOT: unsupported option
Index: cfe/trunk/lib/Driver/Tools.cpp
===
--- cfe/trunk/lib/Driver/Tools.cpp
+++ cfe/trunk/lib/Driver/Tools.cpp
@@ -582,6 +582,10 @@
 FloatABI = "soft";
   }
 }
+
+if (Triple.isOSDarwin() && FloatABI == "hard")
+  D.Diag(diag::err_drv_unsupported_opt_for_target) << A->getAsString(Args)
+   << Triple.getArchName();
   }
 
   // If unspecified, choose the default based on the platform.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: patch: clarify diagnostic when returned value doesn't match function return type

[Nick Lewycky via cfe-commits]

On 19 August 2015 at 15:18, Nick Lewycky  wrote:

> On 10 August 2015 at 19:08, Nick Lewycky  wrote:
>
>> This simple-minded patch extends the case where we report "no viable
>> conversion from 'X' to 'Y'" to emit a more useful diagnostic "no viable
>> conversion from returned value of type 'X' to function return type 'Y'"
>> when used in that context.
>>
>> In lieu of adding tests for this diagnostic explicitly, I've only updated
>> the tests where the patch changes their result.
>>
>> Please review!
>>
>
> Ping!
>

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

Re: [PATCH] D11664: [CUDA] Implemented additional processing steps needed to link with CUDA libdevice bitcode.

[Eric Christopher via cfe-commits]

echristo added inline comments.


Comment at: lib/CodeGen/CodeGenAction.cpp:166-170
@@ +165,7 @@
+std::vector ModuleFuncNames;
+// We need to internalize contents of the linked module but it
+// has to be done *after* the linking because internalized
+// symbols will not be linked in otherwise.
+// In order to do that, we preserve current list of function names in
+// the module and then pass it to Internalize pass to preserve.
+if (LangOpts.CUDA && LangOpts.CUDAIsDevice &&

Can you explain this in a different way perhaps? I'm not sure what you mean 
here.


Comment at: lib/CodeGen/CodeGenAction.cpp:181-190
@@ -166,2 +180,12 @@
   return;
+if (LangOpts.CUDA && LangOpts.CUDAIsDevice &&
+LangOpts.CUDAUsesLibDevice) {
+  legacy::PassManager passes;
+  passes.add(createInternalizePass(ModuleFuncNames));
+  // Considering that most of the functions we've linked are
+  // not going to be used, we may want to eliminate them
+  // early.
+  passes.add(createGlobalDCEPass());
+  passes.run(*TheModule);
+}
   }

Seems like this should be part of the normal IPO pass run? This seems like an 
odd place to put this, can you explain why a bit more?


http://reviews.llvm.org/D11664



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

Re: [PATCH] Have clang list the imported modules in the debug info

[Adrian Prantl via cfe-commits]

> On Aug 19, 2015, at 1:20 PM, David Blaikie  wrote:
> 
> 
> 
> On Mon, Aug 10, 2015 at 5:00 PM, Adrian Prantl  > wrote:
> 
>> On Jul 24, 2015, at 12:33 PM, David Blaikie > > wrote:
>> 
>> *reads back through the thread*
> 
> appreciated, it’s long :-)
> 
>> So what I originally had in mind about a year ago when we discussed this, 
>> was that the module data could have an extra table from type hash to 
>> whatever useful internal representation to find the type in the PCM.
> 
> It turned out that the most useful internal type representation to find a 
> type in a PCM is the type’s DeclContext+Name; this is how (surprise!) clang 
> looks up types in a PCM and the format is supposed to be fast for these kind 
> of lookups.
> 
> Still, I would imagine there would be some kind of direct access (the offset 
> in the file, or somesuch) rather than actually having to go through 
> hashtables, etc. No? (how does one module refer to types in another module? 
> Really by name?)

Entities in PCMs have local integer IDs (just consecutive numbers) that are 
used to encode references inside a record on disk. An external reference gets a 
global ID which is the local ID + the ID of the other module. This numbering 
scheme of course only makes sense within a module (and perhaps also within a 
chained PCH). Every (local and global) ID maps to an entry in the PCM’s 
identifier table. When deserializing, the in-memory global IdentifierTable is 
built and each module gets a map that remaps its internal global IDs to the 
“global” global IDs.

For debug info these IDs are not very useful, because they are not resilient 
against even the smallest additive change to the module. We could add an 
integer attribute with the module-internal entity ID to the forward declaration 
that the debugger can use if the module hash and the CU’s dwoid are matching, 
but I’m not yet convinced that it would be worth it. Adding it to the 
definition of the type in the module dwarf seems not worth it because then we 
already have to do a similarly expensive lookup to find the module containing 
the definition.

> 
>> Everything else would just be DWARF with type units and fission (with the 
>> slight wrinkle of type units that aren't resolvable within a single object 
>> file - they could reference cross-object/dwo file) - emitting a fission CU 
>> for each referenced module.
>> 
>> Needing modules to disambiguate/avoid collisions/support non-odr languages 
>> wasn't something I understood/had considered back then. That explains the 
>> need to add module references to the CU, so the debugger can know which 
>> modules to search for the types in (& doesn't just go loading all of them, 
>> etc).
>> 
>> I would still picture this as "normal type units + a table in the module to 
>> resolve types", but if you guys particularly like using the mangled string 
>> name (or other identifier) in the DWARF that may avoid the need for an 
>> intermediate table (but it doesn't sound like you are avoiding an 
>> intermediate table - you said something about having an 
>> accelerator-table-like thing to aid in the DWARF->AST mapping? So could that 
>> be key'd of the type hash/signature we're using, thus keeping the DWARF more 
>> plain/vanilla DWARF5 (type units + fission)?)
> 
> I originally disliked type signatures and favored using mangled names because 
> the mangled names contained the DeclContext necessary to find types in the 
> PCM. But if we can squeeze the DeclContext somewhere else, that’s fine.
> 
> From the discussion we had on FlagExternalTypeRef I got the impression that 
> long-form forward declarations are starting to look more attractive: If every 
> external type reference is a reference to a forward declaration that has a 
> complete decl context, 
> 
> While that's conveniently what we output currently, I'm not sure it's a great 
> idea to rely on it. We might one day optimize type references (& we'll 
> certainly need to optimize non-type references like member functions, etc - 
> since emitting a stub for those would start to, more visibly, reduce the 
> benefit of doing this work in the first place, I would imagine) so that when 
> there's no contents (which will be more common once we can reference members 
> directly with Bag O DWARF) we just have a DW_AT_type encoded as a 
> DW_FORM_ref_sig8 directly.

Emitting a ref_sig8 directly only works in C++, where the ODR guarantees that 
each signature is globally unique. A consumer would have to search for the type 
definition in all modules (rather than finding it via the decl context), which 
is less efficient, but still works because of the ODR. Thus we’re only 
depending on the long-form forward declarations in non-ODR languages, where we 
need the decl context to disambiguate between non-unique signatures.

> 
> with a DW_TAG_module at the root of the decl context chain,
> 
> This ^ is something I didn't have in mind and would comp

Re: [PATCH] D11280: [CUDA] Improve CUDA compilation pipeline creation.

[Eric Christopher via cfe-commits]

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

This seems like a decent incremental improvement. I think we still need to 
separate out the pipeline a bit further and have the cuda compilation just be 
separate actions that don't need this "inject" bit, but this can at least prep 
the code for that cleanup.

-eric


http://reviews.llvm.org/D11280



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

r245871 - Revert r245866.

[Akira Hatanaka via cfe-commits]

Author: ahatanak
Date: Mon Aug 24 15:30:57 2015
New Revision: 245871

URL: http://llvm.org/viewvc/llvm-project?rev=245871&view=rev
Log:
Revert r245866.

This commit was causing buildbot failures.

Removed:
cfe/trunk/test/Driver/arm-float-abi.c
Modified:
cfe/trunk/lib/Driver/Tools.cpp

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=245871&r1=245870&r2=245871&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Mon Aug 24 15:30:57 2015
@@ -582,10 +582,6 @@ StringRef tools::arm::getARMFloatABI(con
 FloatABI = "soft";
   }
 }
-
-if (Triple.isOSDarwin() && FloatABI == "hard")
-  D.Diag(diag::err_drv_unsupported_opt_for_target) << A->getAsString(Args)
-   << Triple.getArchName();
   }
 
   // If unspecified, choose the default based on the platform.

Removed: cfe/trunk/test/Driver/arm-float-abi.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/arm-float-abi.c?rev=245870&view=auto
==
--- cfe/trunk/test/Driver/arm-float-abi.c (original)
+++ cfe/trunk/test/Driver/arm-float-abi.c (removed)
@@ -1,5 +0,0 @@
-// RUN: not %clang %s -target armv7-apple-ios -mfloat-abi=hard 2>&1 | 
FileCheck -check-prefix=ARMV7-HARD %s
-// RUN: %clang %s -target armv7-apple-ios -mfloat-abi=softfp -### 2>&1 | 
FileCheck -check-prefix=ARMV7-SOFTFP %s
-
-// ARMV7-HARD: unsupported option '-mfloat-abi=hard' for target 'thumbv7'
-// ARMV7-SOFTFP-NOT: unsupported option


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

Re: [PATCH] D11963: Create a __config_site file to capture configuration decisions.

[Eric Fiselier via cfe-commits]

EricWF commandeered this revision.
EricWF edited reviewers, added: jroelofs; removed: EricWF.
EricWF added a comment.

Stealing this revision. I have a different plan.


http://reviews.llvm.org/D11963



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

Re: [PATCH] D11963: Create a __config_site file to capture configuration decisions.

[Eric Fiselier via cfe-commits]

EricWF updated this revision to Diff 32992.
EricWF added a comment.

This patch takes @jroelof's idea and runs with it. However this patch doesn't 
require a `__config_site` header. The patch works modifying 
`build-libcxx/include/c++/v1/__config` by prepending the contents of 
`__config_site`. If extra configuration options are needed the test suite uses 
`build-libcxx/include/c++/v1`. Otherwise the test suite still uses 
`libcxx/include`.

Note that if no extra configuration options are needed then 
`build-libcxx/include/c++/v1/__config` is not modified.


http://reviews.llvm.org/D11963

Files:
  CMakeLists.txt
  cmake/Modules/HandleLibcxxFlags.cmake
  include/CMakeLists.txt
  include/__config_site.in
  test/CMakeLists.txt
  test/libcxx/atomics/libcpp-has-no-threads.fail.cpp
  test/libcxx/atomics/libcpp-has-no-threads.pass.cpp
  test/libcxx/test/config.py
  test/lit.site.cfg.in
  test/std/utilities/date.time/tested_elsewhere.pass.cpp

Index: test/std/utilities/date.time/tested_elsewhere.pass.cpp
===
--- test/std/utilities/date.time/tested_elsewhere.pass.cpp
+++ test/std/utilities/date.time/tested_elsewhere.pass.cpp
@@ -30,9 +30,11 @@
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
+#ifndef _LIBCPP_HAS_NO_THREAD_UNSAFE_C_FUNCTIONS
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
+#endif
 static_assert((std::is_same::value), "");
 }
Index: test/lit.site.cfg.in
===
--- test/lit.site.cfg.in
+++ test/lit.site.cfg.in
@@ -2,6 +2,7 @@
 config.cxx_under_test   = "@LIBCXX_COMPILER@"
 config.libcxx_src_root  = "@LIBCXX_SOURCE_DIR@"
 config.libcxx_obj_root  = "@LIBCXX_BINARY_DIR@"
+config.libcxx_headers   = "@LIBCXX_TEST_HEADERS@"
 config.cxx_library_root = "@LIBCXX_LIBRARY_DIR@"
 config.enable_exceptions= "@LIBCXX_ENABLE_EXCEPTIONS@"
 config.enable_rtti  = "@LIBCXX_ENABLE_RTTI@"
Index: test/libcxx/test/config.py
===
--- test/libcxx/test/config.py
+++ test/libcxx/test/config.py
@@ -391,8 +391,13 @@
 support_path = os.path.join(self.libcxx_src_root, 'test/support')
 self.cxx.compile_flags += ['-I' + support_path]
 self.cxx.compile_flags += ['-include', os.path.join(support_path, 'nasty_macros.hpp')]
-libcxx_headers = self.get_lit_conf(
-'libcxx_headers', os.path.join(self.libcxx_src_root, 'include'))
+
+libcxx_headers = self.get_lit_conf('libcxx_headers')
+if libcxx_headers:
+self.lit_config.note('Using libc++ headers in: %s' % libcxx_headers)
+else:
+libcxx_headers = os.path.join(self.libcxx_src_root, 'include')
+
 if not os.path.isdir(libcxx_headers):
 self.lit_config.fatal("libcxx_headers='%s' is not a directory."
   % libcxx_headers)
@@ -416,36 +421,28 @@
 if not enable_global_filesystem_namespace:
 self.config.available_features.add(
 'libcpp-has-no-global-filesystem-namespace')
-self.cxx.compile_flags += [
-'-D_LIBCPP_HAS_NO_GLOBAL_FILESYSTEM_NAMESPACE']
 
 def configure_compile_flags_no_stdin(self):
 enable_stdin = self.get_lit_bool('enable_stdin', True)
 if not enable_stdin:
 self.config.available_features.add('libcpp-has-no-stdin')
-self.cxx.compile_flags += ['-D_LIBCPP_HAS_NO_STDIN']
 
 def configure_compile_flags_no_stdout(self):
 enable_stdout = self.get_lit_bool('enable_stdout', True)
 if not enable_stdout:
 self.config.available_features.add('libcpp-has-no-stdout')
-self.cxx.compile_flags += ['-D_LIBCPP_HAS_NO_STDOUT']
 
 def configure_compile_flags_no_threads(self):
-self.cxx.compile_flags += ['-D_LIBCPP_HAS_NO_THREADS']
 self.config.available_features.add('libcpp-has-no-threads')
 
 def configure_compile_flags_no_thread_unsafe_c_functions(self):
 enable_thread_unsafe_c_functions = self.get_lit_bool(
 'enable_thread_unsafe_c_functions', True)
 if not enable_thread_unsafe_c_functions:
-self.cxx.compile_flags += [
-'-D_LIBCPP_HAS_NO_THREAD_UNSAFE_C_FUNCTIONS']
 self.config.available_features.add(
 'libcpp-has-no-thread-unsafe-c-functions')
 
 def configure_compile_flags_no_monotonic_clock(self):
-self.cxx.compile_flags += ['-D_LIBCPP_HAS_NO_MONOTONIC_CLOCK']
 self.config.available_features.add('libcpp-has-no-monotonic-clock')
 
 def configure_link_flags(self):
Index: test/libcxx/atomics/libcpp-has-no-threa

Re: [PATCH] D12247: [libc++] remove possible trailing padding from aligned_storage

[Yiran Wang via cfe-commits]

yiranwang added a comment.

A test case is as following. It has to be build by GCC 4.9 -O3 (maybe or 
later), with latest libc++, and for AARCH64+ANDROID target. 
AARCH64 requires 128 bit alignment for aligned_storage and 64 bit pointers, 
while gcc 4.9 alias analysis will do field-sensitive points-to analysis. But 
this could happen for other ISA+ABI.
The fundamental issue is that for this combination, std::function has member 
__buf_ declared as 
aligned_storage<3*sizoef(void*)>::type __buf_;
Basically, it is
aligned_storage<24>::type;
This will generate aligned_storage of, _Len==24 and _Align==16;
While std::function will use the __buf_ to sizeof(__buf_) bytes (at line 1593 
and 1628 of ), which is 32. Basically, the pointer to "tbool' will 
be stored at "&__buf_+24". 
This is not a well defined memory area, and GCC alias analysis is going to 
ignore the "ESCAPE" of address of "tbool". Basically, the function 
"test_simple" would always return "false".

#include 
extern void external_test(std::functionfn);
extern bool test_simple(){

  bool tbool = false;
  int a, b;
  external_test([&a, &b, &tbool](){
tbool = true;
return true;
  });
  return tbool;

}


http://reviews.llvm.org/D12247



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

Re: [PATCH] Have clang list the imported modules in the debug info

[David Blaikie via cfe-commits]

On Mon, Aug 24, 2015 at 1:23 PM, Adrian Prantl  wrote:

>
> On Aug 19, 2015, at 1:20 PM, David Blaikie  wrote:
>
>
>
> On Mon, Aug 10, 2015 at 5:00 PM, Adrian Prantl  wrote:
>
>>
>> On Jul 24, 2015, at 12:33 PM, David Blaikie  wrote:
>>
>> *reads back through the thread*
>>
>>
>> appreciated, it’s long :-)
>>
>> So what I originally had in mind about a year ago when we discussed this,
>> was that the module data could have an extra table from type hash to
>> whatever useful internal representation to find the type in the PCM.
>>
>>
>> It turned out that the most useful internal type representation to find a
>> type in a PCM is the type’s DeclContext+Name; this is how (surprise!) clang
>> looks up types in a PCM and the format is supposed to be fast for these
>> kind of lookups.
>>
>
> Still, I would imagine there would be some kind of direct access (the
> offset in the file, or somesuch) rather than actually having to go through
> hashtables, etc. No? (how does one module refer to types in another module?
> Really by name?)
>
>
> Entities in PCMs have local integer IDs (just consecutive numbers) that
> are used to encode references inside a record on disk. An external
> reference gets a global ID which is the local ID + the ID of the other
> module. This numbering scheme of course only makes sense within a module
> (and perhaps also within a chained PCH). Every (local and global) ID maps
> to an entry in the PCM’s identifier table. When deserializing, the
> in-memory global IdentifierTable is built and each module gets a map that
> remaps its internal global IDs to the “global” global IDs.
>
> For debug info these IDs are not very useful, because they are not
> resilient against even the smallest additive change to the module. We could
> add an integer attribute with the module-internal entity ID to the forward
> declaration that the debugger can use if the module hash and the CU’s dwoid
> are matching, but I’m not yet convinced that it would be worth it. Adding
> it to the definition of the type in the module dwarf seems not worth it
> because then we already have to do a similarly expensive lookup to find the
> module containing the definition.
>

It seems that ideally a module-aware debugger would not consult the DWARF
at all, so I wouldn't advocate having the module format type ID in the
DWARF, but in a side table (either part of the module itself, or just a
section of its own in the module-as-object-file).

Why is it important that the IDs be resilient to changes in the module? I'm
suggesting that non-module debug info should only use type hashes, then
within the module itself there would be a hash-to-ID mapping (a flat table,
probably, wouldn't need to be anything fancy). This would keep the DWARF
less polluted by module concepts - it'd just be up to the consumer "oh,
here's a type hash identifier, resolve that to an AST - either by looking
in DWARF and building an AST from the DWARF type unit with the matching
hash, or by looking in the module and finding the ID/loading the type"?


>
>
>> Everything else would just be DWARF with type units and fission (with the
>> slight wrinkle of type units that aren't resolvable within a single object
>> file - they could reference cross-object/dwo file) - emitting a fission CU
>> for each referenced module.
>>
>> Needing modules to disambiguate/avoid collisions/support non-odr
>> languages wasn't something I understood/had considered back then. That
>> explains the need to add module references to the CU, so the debugger can
>> know which modules to search for the types in (& doesn't just go loading
>> all of them, etc).
>>
>> I would still picture this as "normal type units + a table in the module
>> to resolve types", but if you guys particularly like using the mangled
>> string name (or other identifier) in the DWARF that may avoid the need for
>> an intermediate table (but it doesn't sound like you are avoiding an
>> intermediate table - you said something about having an
>> accelerator-table-like thing to aid in the DWARF->AST mapping? So could
>> that be key'd of the type hash/signature we're using, thus keeping the
>> DWARF more plain/vanilla DWARF5 (type units + fission)?)
>>
>>
>> I originally disliked type signatures and favored using mangled names
>> because the mangled names contained the DeclContext necessary to find types
>> in the PCM. But if we can squeeze the DeclContext somewhere else, that’s
>> fine.
>>
>> From the discussion we had on FlagExternalTypeRef I got the impression
>> that long-form forward declarations are starting to look more attractive:
>> If every external type reference is a reference to a forward declaration
>> that has a complete decl context,
>>
>
> While that's conveniently what we output currently, I'm not sure it's a
> great idea to rely on it. We might one day optimize type references (&
> we'll certainly need to optimize non-type references like member functions,
> etc - since emitting a stub for those would start to,

[PATCH] D12294: Misc cleanups re-commandeered from D11963.

[Jonathan Roelofs via cfe-commits]

jroelofs created this revision.
jroelofs added a reviewer: EricWF.
jroelofs added a subscriber: cfe-commits.

This separates out the bits of D11963 which were drive-by fixes, which aren't 
really relevant to the __config_site part of that change.

http://reviews.llvm.org/D12294

Files:
  CMakeLists.txt
  test/std/atomics/libcpp-has-no-threads.fail.cpp
  test/std/atomics/libcpp-has-no-threads.pass.cpp
  test/std/utilities/date.time/tested_elsewhere.pass.cpp

Index: test/std/utilities/date.time/tested_elsewhere.pass.cpp
===
--- test/std/utilities/date.time/tested_elsewhere.pass.cpp
+++ test/std/utilities/date.time/tested_elsewhere.pass.cpp
@@ -30,9 +30,11 @@
 static_assert((std::is_same::value), 
"");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), 
"");
+#ifndef _LIBCPP_HAS_NO_THREAD_UNSAFE_C_FUNCTIONS
 static_assert((std::is_same::value), 
"");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), 
"");
 static_assert((std::is_same::value), "");
+#endif
 static_assert((std::is_same::value), "");
 }
Index: test/std/atomics/libcpp-has-no-threads.pass.cpp
===
--- test/std/atomics/libcpp-has-no-threads.pass.cpp
+++ test/std/atomics/libcpp-has-no-threads.pass.cpp
@@ -1,18 +0,0 @@
-//===--===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is dual licensed under the MIT and the University of Illinois Open
-// Source Licenses. See LICENSE.TXT for details.
-//
-//===--===//
-// XFAIL: libcpp-has-no-threads
-
-#ifdef _LIBCPP_HAS_NO_THREADS
-#error This should be XFAIL'd for the purpose of detecting that the LIT 
feature\
- 'libcpp-has-no-threads' is available iff _LIBCPP_HAS_NO_THREADS is defined
-#endif
-
-int main()
-{
-}
Index: test/std/atomics/libcpp-has-no-threads.fail.cpp
===
--- test/std/atomics/libcpp-has-no-threads.fail.cpp
+++ test/std/atomics/libcpp-has-no-threads.fail.cpp
@@ -1,23 +0,0 @@
-//===--===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is dual licensed under the MIT and the University of Illinois Open
-// Source Licenses. See LICENSE.TXT for details.
-//
-//===--===//
-
-// 
-
-// Test that including  fails to compile when _LIBCPP_HAS_NO_THREADS
-// is defined.
-
-#ifndef _LIBCPP_HAS_NO_THREADS
-#define _LIBCPP_HAS_NO_THREADS
-#endif
-
-#include 
-
-int main()
-{
-}
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -84,7 +84,7 @@
 option(LIBCXX_ENABLE_THREAD_UNSAFE_C_FUNCTIONS "Build libc++ with support for 
thread-unsafe C functions" ON)
 option(LIBCXX_ENABLE_MONOTONIC_CLOCK
   "Build libc++ with support for a monotonic clock.
-   This option may only be used when LIBCXX_ENABLE_THREADS=OFF." ON)
+   This option may only be set to OFF when LIBCXX_ENABLE_THREADS=OFF." ON)
 
 # Misc options 
 option(LIBCXX_ENABLE_PEDANTIC "Compile with pedantic enabled." ON)
@@ -247,7 +247,7 @@
 define_if_not(LIBCXX_ENABLE_THREAD_UNSAFE_C_FUNCTIONS 
-D_LIBCPP_HAS_NO_THREAD_UNSAFE_C_FUNCTIONS)
 
 
-# Sanitizer flags
+# Sanitizer flags =
 
 # Configure for sanitizers. If LIBCXX_BUILT_STANDALONE then we have to do
 # the flag translation ourselves. Othewise LLVM's CMakeList.txt will handle it.


Index: test/std/utilities/date.time/tested_elsewhere.pass.cpp
===
--- test/std/utilities/date.time/tested_elsewhere.pass.cpp
+++ test/std/utilities/date.time/tested_elsewhere.pass.cpp
@@ -30,9 +30,11 @@
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
+#ifndef _LIBCPP_HAS_NO_THREAD_UNSAFE_C_FUNCTIONS
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
+#endif
 static_assert((std::is_same::value), "");
 }
Index: test/std/atomics/libcpp-has-no-threads.pass.cpp
===
--- test/std/atomics/libcpp-has-no-threads.pass.cpp
+++ test/std/atomics/libcpp-has-no-threads.pass.cpp
@@ -1,18 +0,0 @@
-//===--===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is dual licensed un

Re: [PATCH] D11664: [CUDA] Implemented additional processing steps needed to link with CUDA libdevice bitcode.

[Artem Belevich via cfe-commits]

tra added inline comments.


Comment at: lib/CodeGen/CodeGenAction.cpp:166-170
@@ +165,7 @@
+std::vector ModuleFuncNames;
+// We need to internalize contents of the linked module but it
+// has to be done *after* the linking because internalized
+// symbols will not be linked in otherwise.
+// In order to do that, we preserve current list of function names in
+// the module and then pass it to Internalize pass to preserve.
+if (LangOpts.CUDA && LangOpts.CUDAIsDevice &&

echristo wrote:
> Can you explain this in a different way perhaps? I'm not sure what you mean 
> here.
From llvm.org/docs/NVPTXUsage.html

This patch implements following items:

> The internalize pass is also recommended to remove unused math functions from 
> the resulting PTX. For an input IR module module.bc, the following 
> compilation flow is recommended:
> 
> 1 Save list of external functions in module.bc
> 2 Link module.bc with libdevice.compute_XX.YY.bc
> 3 Internalize all functions not in list from (1)
> 4 Eliminate all unused internal functions

LLVM part of the changes takes care of NVVMReflect:

> * Run NVVMReflect pass
> * Run standard optimization pipeline




Comment at: lib/CodeGen/CodeGenAction.cpp:181-190
@@ -166,2 +180,12 @@
   return;
+if (LangOpts.CUDA && LangOpts.CUDAIsDevice &&
+LangOpts.CUDAUsesLibDevice) {
+  legacy::PassManager passes;
+  passes.add(createInternalizePass(ModuleFuncNames));
+  // Considering that most of the functions we've linked are
+  // not going to be used, we may want to eliminate them
+  // early.
+  passes.add(createGlobalDCEPass());
+  passes.run(*TheModule);
+}
   }

echristo wrote:
> Seems like this should be part of the normal IPO pass run? This seems like an 
> odd place to put this, can you explain why a bit more?
It will indeed happen during normal optimization, but as NVPTX docs says it 
makes fair amount of sense to eliminate quite a bit of bitcode that we know 
we're not going to need. libdevice carries ~450 functions and only handful of 
those are needed. Why run all other optimization passes on them?

In addition to that, we need to pass to Internalize list of symbols to 
preserve. As far as I can tell the way to do it within normal optimization 
pipeline is to pass them to back-end via 
-internalize-public-api-list/-internalize-public-api-file. That's not 
particularly suitable way to carry potentially large list of symbols we will 
find in the TU we're dealing with.

I could move GDCE to LLVM where it would arguably be somewhat more effective if 
done after NVVMReflect, but keeping it next to internalize makes it easier to 
see that we intentionally internalize and eliminate unused bitcode here.


http://reviews.llvm.org/D11664



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

Re: [PATCH] D12294: Misc cleanups re-commandeered from D11963.

[Jonathan Roelofs via cfe-commits]

jroelofs updated this revision to Diff 32996.
jroelofs added a comment.

The diff uploaded strangely... trying again.


http://reviews.llvm.org/D12294

Files:
  CMakeLists.txt
  test/libcxx/atomics/libcpp-has-no-threads.fail.cpp
  test/libcxx/atomics/libcpp-has-no-threads.pass.cpp
  test/std/atomics/libcpp-has-no-threads.fail.cpp
  test/std/atomics/libcpp-has-no-threads.pass.cpp
  test/std/utilities/date.time/tested_elsewhere.pass.cpp

Index: test/std/utilities/date.time/tested_elsewhere.pass.cpp
===
--- test/std/utilities/date.time/tested_elsewhere.pass.cpp
+++ test/std/utilities/date.time/tested_elsewhere.pass.cpp
@@ -30,9 +30,11 @@
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
+#ifndef _LIBCPP_HAS_NO_THREAD_UNSAFE_C_FUNCTIONS
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
+#endif
 static_assert((std::is_same::value), "");
 }
Index: test/std/atomics/libcpp-has-no-threads.pass.cpp
===
--- test/std/atomics/libcpp-has-no-threads.pass.cpp
+++ test/std/atomics/libcpp-has-no-threads.pass.cpp
@@ -1,18 +0,0 @@
-//===--===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is dual licensed under the MIT and the University of Illinois Open
-// Source Licenses. See LICENSE.TXT for details.
-//
-//===--===//
-// XFAIL: libcpp-has-no-threads
-
-#ifdef _LIBCPP_HAS_NO_THREADS
-#error This should be XFAIL'd for the purpose of detecting that the LIT feature\
- 'libcpp-has-no-threads' is available iff _LIBCPP_HAS_NO_THREADS is defined
-#endif
-
-int main()
-{
-}
Index: test/std/atomics/libcpp-has-no-threads.fail.cpp
===
--- test/std/atomics/libcpp-has-no-threads.fail.cpp
+++ test/std/atomics/libcpp-has-no-threads.fail.cpp
@@ -1,23 +0,0 @@
-//===--===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is dual licensed under the MIT and the University of Illinois Open
-// Source Licenses. See LICENSE.TXT for details.
-//
-//===--===//
-
-// 
-
-// Test that including  fails to compile when _LIBCPP_HAS_NO_THREADS
-// is defined.
-
-#ifndef _LIBCPP_HAS_NO_THREADS
-#define _LIBCPP_HAS_NO_THREADS
-#endif
-
-#include 
-
-int main()
-{
-}
Index: test/libcxx/atomics/libcpp-has-no-threads.pass.cpp
===
--- test/libcxx/atomics/libcpp-has-no-threads.pass.cpp
+++ test/libcxx/atomics/libcpp-has-no-threads.pass.cpp
@@ -0,0 +1,18 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+// XFAIL: libcpp-has-no-threads
+
+#ifdef _LIBCPP_HAS_NO_THREADS
+#error This should be XFAIL'd for the purpose of detecting that the LIT feature\
+   'libcpp-has-no-threads' is available iff _LIBCPP_HAS_NO_THREADS is defined
+#endif
+
+int main()
+{
+}
Index: test/libcxx/atomics/libcpp-has-no-threads.fail.cpp
===
--- test/libcxx/atomics/libcpp-has-no-threads.fail.cpp
+++ test/libcxx/atomics/libcpp-has-no-threads.fail.cpp
@@ -0,0 +1,23 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// 
+
+// Test that including  fails to compile when _LIBCPP_HAS_NO_THREADS
+// is defined.
+
+#ifndef _LIBCPP_HAS_NO_THREADS
+#define _LIBCPP_HAS_NO_THREADS
+#endif
+
+#include 
+
+int main()
+{
+}
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -84,7 +84,7 @@
 option(LIBCXX_ENABLE_THREAD_UNSAFE_C_FUNCTIONS "Build libc++ with support for thread-unsafe C functions" ON)
 option(LIBCXX_ENABLE_MONOTONIC_CLOCK
   "Build libc++ with support for a monotonic clock.
-   This option may only be used when LIBCXX_ENABLE_THREADS=OFF." ON)
+   This option may only be set to OFF when LIBCXX_ENABLE_THREADS=OFF." ON)

Re: [PATCH] D12294: Misc cleanups re-commandeered from D11963.

[Eric Fiselier via cfe-commits]

EricWF added a comment.

Can you move the `libcpp-has-no-threads` tests to `test/libcxx/atomics` instead 
of deleting them? (I imagine that's what you intended to do).

Also `tested_elsewhere.pass.cpp` shouldn't really be called that because it 
contains the actual test. Could you rename it to something?


http://reviews.llvm.org/D12294



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

Re: [PATCH] D12294: Misc cleanups re-commandeered from D11963.

[Eric Fiselier via cfe-commits]

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

LGTM after renaming `tested_elsewhere.pass.cpp`


http://reviews.llvm.org/D12294



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

Re: [PATCH] D12294: Misc cleanups re-commandeered from D11963.

[Eric Fiselier via cfe-commits]

EricWF added a comment.

Actually commit this as is and I'll handle the other cleanup.


http://reviews.llvm.org/D12294



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

Re: [PATCH] D12294: Misc cleanups re-commandeered from D11963.

[Jonathan Roelofs via cfe-commits]

jroelofs closed this revision.
jroelofs added a comment.

r245876


http://reviews.llvm.org/D12294



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

[libcxx] r245876 - Misc drive-by cleanups. NFC

[Jonathan Roelofs via cfe-commits]

Author: jroelofs
Date: Mon Aug 24 16:20:07 2015
New Revision: 245876

URL: http://llvm.org/viewvc/llvm-project?rev=245876&view=rev
Log:
Misc drive-by cleanups. NFC

http://reviews.llvm.org/D12294

Added:
libcxx/trunk/test/libcxx/atomics/
libcxx/trunk/test/libcxx/atomics/libcpp-has-no-threads.fail.cpp
libcxx/trunk/test/libcxx/atomics/libcpp-has-no-threads.pass.cpp
Removed:
libcxx/trunk/test/std/atomics/libcpp-has-no-threads.fail.cpp
libcxx/trunk/test/std/atomics/libcpp-has-no-threads.pass.cpp
Modified:
libcxx/trunk/CMakeLists.txt
libcxx/trunk/test/std/utilities/date.time/tested_elsewhere.pass.cpp

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=245876&r1=245875&r2=245876&view=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Mon Aug 24 16:20:07 2015
@@ -85,7 +85,7 @@ option(LIBCXX_ENABLE_THREADS "Build libc
 option(LIBCXX_ENABLE_THREAD_UNSAFE_C_FUNCTIONS "Build libc++ with support for 
thread-unsafe C functions" ON)
 option(LIBCXX_ENABLE_MONOTONIC_CLOCK
   "Build libc++ with support for a monotonic clock.
-   This option may only be used when LIBCXX_ENABLE_THREADS=OFF." ON)
+   This option may only be set to OFF when LIBCXX_ENABLE_THREADS=OFF." ON)
 
 # Misc options 
 option(LIBCXX_ENABLE_PEDANTIC "Compile with pedantic enabled." ON)
@@ -248,7 +248,7 @@ define_if_not(LIBCXX_ENABLE_MONOTONIC_CL
 define_if_not(LIBCXX_ENABLE_THREAD_UNSAFE_C_FUNCTIONS 
-D_LIBCPP_HAS_NO_THREAD_UNSAFE_C_FUNCTIONS)
 
 
-# Sanitizer flags
+# Sanitizer flags =
 
 # Configure for sanitizers. If LIBCXX_BUILT_STANDALONE then we have to do
 # the flag translation ourselves. Othewise LLVM's CMakeList.txt will handle it.

Added: libcxx/trunk/test/libcxx/atomics/libcpp-has-no-threads.fail.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/libcxx/atomics/libcpp-has-no-threads.fail.cpp?rev=245876&view=auto
==
--- libcxx/trunk/test/libcxx/atomics/libcpp-has-no-threads.fail.cpp (added)
+++ libcxx/trunk/test/libcxx/atomics/libcpp-has-no-threads.fail.cpp Mon Aug 24 
16:20:07 2015
@@ -0,0 +1,23 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// 
+
+// Test that including  fails to compile when _LIBCPP_HAS_NO_THREADS
+// is defined.
+
+#ifndef _LIBCPP_HAS_NO_THREADS
+#define _LIBCPP_HAS_NO_THREADS
+#endif
+
+#include 
+
+int main()
+{
+}

Added: libcxx/trunk/test/libcxx/atomics/libcpp-has-no-threads.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/libcxx/atomics/libcpp-has-no-threads.pass.cpp?rev=245876&view=auto
==
--- libcxx/trunk/test/libcxx/atomics/libcpp-has-no-threads.pass.cpp (added)
+++ libcxx/trunk/test/libcxx/atomics/libcpp-has-no-threads.pass.cpp Mon Aug 24 
16:20:07 2015
@@ -0,0 +1,18 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+// XFAIL: libcpp-has-no-threads
+
+#ifdef _LIBCPP_HAS_NO_THREADS
+#error This should be XFAIL'd for the purpose of detecting that the LIT 
feature\
+   'libcpp-has-no-threads' is available iff _LIBCPP_HAS_NO_THREADS is defined
+#endif
+
+int main()
+{
+}

Removed: libcxx/trunk/test/std/atomics/libcpp-has-no-threads.fail.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/atomics/libcpp-has-no-threads.fail.cpp?rev=245875&view=auto
==
--- libcxx/trunk/test/std/atomics/libcpp-has-no-threads.fail.cpp (original)
+++ libcxx/trunk/test/std/atomics/libcpp-has-no-threads.fail.cpp (removed)
@@ -1,23 +0,0 @@
-//===--===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is dual licensed under the MIT and the University of Illinois Open
-// Source Licenses. See LICENSE.TXT for details.
-//
-//===--===//
-
-// 
-
-// Test that including  fails to compile when _LIBCPP_HAS_NO_THREADS
-// is defined.
-
-#ifndef _LIBCPP_HAS_NO_THREADS
-#defin

[libcxx] r245877 - Move test/std/utilities/date.time to proper stable name utilities/time/date.time

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Mon Aug 24 16:27:25 2015
New Revision: 245877

URL: http://llvm.org/viewvc/llvm-project?rev=245877&view=rev
Log:
Move test/std/utilities/date.time to proper stable name utilities/time/date.time

Added:
libcxx/trunk/test/libcxx/utilities/time/
libcxx/trunk/test/libcxx/utilities/time/date.time/

libcxx/trunk/test/libcxx/utilities/time/date.time/asctime.thread-unsafe.fail.cpp

libcxx/trunk/test/libcxx/utilities/time/date.time/ctime.thread-unsafe.fail.cpp

libcxx/trunk/test/libcxx/utilities/time/date.time/gmtime.thread-unsafe.fail.cpp

libcxx/trunk/test/libcxx/utilities/time/date.time/localtime.thread-unsafe.fail.cpp
libcxx/trunk/test/std/utilities/time/date.time/
libcxx/trunk/test/std/utilities/time/date.time/ctime.pass.cpp
Removed:
libcxx/trunk/test/std/utilities/date.time/

Added: 
libcxx/trunk/test/libcxx/utilities/time/date.time/asctime.thread-unsafe.fail.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/libcxx/utilities/time/date.time/asctime.thread-unsafe.fail.cpp?rev=245877&view=auto
==
--- 
libcxx/trunk/test/libcxx/utilities/time/date.time/asctime.thread-unsafe.fail.cpp
 (added)
+++ 
libcxx/trunk/test/libcxx/utilities/time/date.time/asctime.thread-unsafe.fail.cpp
 Mon Aug 24 16:27:25 2015
@@ -0,0 +1,18 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// REQUIRES: libcpp-has-no-thread-unsafe-c-functions
+
+#include 
+
+int main() {
+// asctime is not thread-safe.
+std::time_t t = 0;
+std::asctime(&t);
+}

Added: 
libcxx/trunk/test/libcxx/utilities/time/date.time/ctime.thread-unsafe.fail.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/libcxx/utilities/time/date.time/ctime.thread-unsafe.fail.cpp?rev=245877&view=auto
==
--- 
libcxx/trunk/test/libcxx/utilities/time/date.time/ctime.thread-unsafe.fail.cpp 
(added)
+++ 
libcxx/trunk/test/libcxx/utilities/time/date.time/ctime.thread-unsafe.fail.cpp 
Mon Aug 24 16:27:25 2015
@@ -0,0 +1,18 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// REQUIRES: libcpp-has-no-thread-unsafe-c-functions
+
+#include 
+
+int main() {
+// ctime is not thread-safe.
+std::time_t t = 0;
+std::ctime(&t);
+}

Added: 
libcxx/trunk/test/libcxx/utilities/time/date.time/gmtime.thread-unsafe.fail.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/libcxx/utilities/time/date.time/gmtime.thread-unsafe.fail.cpp?rev=245877&view=auto
==
--- 
libcxx/trunk/test/libcxx/utilities/time/date.time/gmtime.thread-unsafe.fail.cpp 
(added)
+++ 
libcxx/trunk/test/libcxx/utilities/time/date.time/gmtime.thread-unsafe.fail.cpp 
Mon Aug 24 16:27:25 2015
@@ -0,0 +1,18 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// REQUIRES: libcpp-has-no-thread-unsafe-c-functions
+
+#include 
+
+int main() {
+// gmtime is not thread-safe.
+std::time_t t = 0;
+std::gmtime(&t);
+}

Added: 
libcxx/trunk/test/libcxx/utilities/time/date.time/localtime.thread-unsafe.fail.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/libcxx/utilities/time/date.time/localtime.thread-unsafe.fail.cpp?rev=245877&view=auto
==
--- 
libcxx/trunk/test/libcxx/utilities/time/date.time/localtime.thread-unsafe.fail.cpp
 (added)
+++ 
libcxx/trunk/test/libcxx/utilities/time/date.time/localtime.thread-unsafe.fail.cpp
 Mon Aug 24 16:27:25 2015
@@ -0,0 +1,18 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// REQUIRES: libcpp-has-no-thread-unsafe-c-functi

Re: [PATCH] D11963: Create a __config_site file to capture configuration decisions.

[Eric Fiselier via cfe-commits]

EricWF updated the summary for this revision.
EricWF updated this revision to Diff 32997.
EricWF added a comment.

Update diff to remove misc cleanup stuff.


http://reviews.llvm.org/D11963

Files:
  CMakeLists.txt
  cmake/Modules/HandleLibcxxFlags.cmake
  include/CMakeLists.txt
  include/__config_site.in
  test/CMakeLists.txt
  test/libcxx/test/config.py
  test/lit.site.cfg.in

Index: test/lit.site.cfg.in
===
--- test/lit.site.cfg.in
+++ test/lit.site.cfg.in
@@ -2,6 +2,7 @@
 config.cxx_under_test   = "@LIBCXX_COMPILER@"
 config.libcxx_src_root  = "@LIBCXX_SOURCE_DIR@"
 config.libcxx_obj_root  = "@LIBCXX_BINARY_DIR@"
+config.libcxx_headers   = "@LIBCXX_TEST_HEADERS@"
 config.cxx_library_root = "@LIBCXX_LIBRARY_DIR@"
 config.enable_exceptions= "@LIBCXX_ENABLE_EXCEPTIONS@"
 config.enable_rtti  = "@LIBCXX_ENABLE_RTTI@"
Index: test/libcxx/test/config.py
===
--- test/libcxx/test/config.py
+++ test/libcxx/test/config.py
@@ -391,8 +391,13 @@
 support_path = os.path.join(self.libcxx_src_root, 'test/support')
 self.cxx.compile_flags += ['-I' + support_path]
 self.cxx.compile_flags += ['-include', os.path.join(support_path, 'nasty_macros.hpp')]
-libcxx_headers = self.get_lit_conf(
-'libcxx_headers', os.path.join(self.libcxx_src_root, 'include'))
+
+libcxx_headers = self.get_lit_conf('libcxx_headers')
+if libcxx_headers:
+self.lit_config.note('Using libc++ headers in: %s' % libcxx_headers)
+else:
+libcxx_headers = os.path.join(self.libcxx_src_root, 'include')
+
 if not os.path.isdir(libcxx_headers):
 self.lit_config.fatal("libcxx_headers='%s' is not a directory."
   % libcxx_headers)
@@ -416,36 +421,28 @@
 if not enable_global_filesystem_namespace:
 self.config.available_features.add(
 'libcpp-has-no-global-filesystem-namespace')
-self.cxx.compile_flags += [
-'-D_LIBCPP_HAS_NO_GLOBAL_FILESYSTEM_NAMESPACE']
 
 def configure_compile_flags_no_stdin(self):
 enable_stdin = self.get_lit_bool('enable_stdin', True)
 if not enable_stdin:
 self.config.available_features.add('libcpp-has-no-stdin')
-self.cxx.compile_flags += ['-D_LIBCPP_HAS_NO_STDIN']
 
 def configure_compile_flags_no_stdout(self):
 enable_stdout = self.get_lit_bool('enable_stdout', True)
 if not enable_stdout:
 self.config.available_features.add('libcpp-has-no-stdout')
-self.cxx.compile_flags += ['-D_LIBCPP_HAS_NO_STDOUT']
 
 def configure_compile_flags_no_threads(self):
-self.cxx.compile_flags += ['-D_LIBCPP_HAS_NO_THREADS']
 self.config.available_features.add('libcpp-has-no-threads')
 
 def configure_compile_flags_no_thread_unsafe_c_functions(self):
 enable_thread_unsafe_c_functions = self.get_lit_bool(
 'enable_thread_unsafe_c_functions', True)
 if not enable_thread_unsafe_c_functions:
-self.cxx.compile_flags += [
-'-D_LIBCPP_HAS_NO_THREAD_UNSAFE_C_FUNCTIONS']
 self.config.available_features.add(
 'libcpp-has-no-thread-unsafe-c-functions')
 
 def configure_compile_flags_no_monotonic_clock(self):
-self.cxx.compile_flags += ['-D_LIBCPP_HAS_NO_MONOTONIC_CLOCK']
 self.config.available_features.add('libcpp-has-no-monotonic-clock')
 
 def configure_link_flags(self):
Index: test/CMakeLists.txt
===
--- test/CMakeLists.txt
+++ test/CMakeLists.txt
@@ -22,6 +22,10 @@
 pythonize_bool(LIBCXX_GENERATE_COVERAGE)
 pythonize_bool(LIBCXXABI_USE_LLVM_UNWINDER)
 
+if (LIBCXX_NEEDS_SITE_CONFIG)
+  set(LIBCXX_TEST_HEADERS ${LIBCXX_BINARY_DIR}/include/c++/v1)
+endif()
+
 # The tests shouldn't link to any ABI library when it has been linked into
 # libc++ statically.
 if (LIBCXX_ENABLE_STATIC_ABI_LIBRARY)
Index: include/__config_site.in
===
--- /dev/null
+++ include/__config_site.in
@@ -0,0 +1,20 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef _LIBCPP_CONFIG_SITE
+#define _LIBCPP_CONFIG_SITE
+
+#cmakedefine _LIBCPP_HAS_NO_GLOBAL_FILESYSTEM_NAMESPACE
+#cmakedefine _LIBCPP_HAS_NO_STDIN
+#cmakedefine _LIBCPP_HAS_NO_STDOUT
+#cmakedefine _LIBCPP_HAS_NO_THREADS
+#cmakedefine _LIBCPP_HAS_NO_MONOTONIC_CLOCK
+#cmakedefine _LIBCPP_HAS_NO_

r245879 - [MS ABI] Don't emit stackrestore in cleanups

[David Majnemer via cfe-commits]

Author: majnemer
Date: Mon Aug 24 16:34:21 2015
New Revision: 245879

URL: http://llvm.org/viewvc/llvm-project?rev=245879&view=rev
Log:
[MS ABI] Don't emit stackrestore in cleanups

The stackrestore intrinsic isn't meaningful inside of a cleanup funclet.

Modified:
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/lib/CodeGen/CGCall.h
cfe/trunk/test/CodeGenCXX/microsoft-abi-arg-order.cpp
cfe/trunk/test/CodeGenCXX/microsoft-abi-eh-cleanups.cpp

Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=245879&r1=245878&r2=245879&view=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Mon Aug 24 16:34:21 2015
@@ -2782,21 +2782,11 @@ void CallArgList::allocateArgumentMemory
   // alloca and store lazily on the first cleanup emission.
   StackBaseMem = CGF.CreateTempAlloca(CGF.Int8PtrTy, "inalloca.spmem");
   CGF.Builder.CreateStore(StackBase, StackBaseMem);
-  CGF.pushStackRestore(EHCleanup, StackBaseMem);
+  CGF.pushStackRestore(NormalCleanup, StackBaseMem);
   StackCleanup = CGF.EHStack.getInnermostEHScope();
   assert(StackCleanup.isValid());
 }
 
-void CallArgList::freeArgumentMemory(CodeGenFunction &CGF) const {
-  if (StackBase) {
-CGF.DeactivateCleanupBlock(StackCleanup, StackBase);
-llvm::Value *F = CGF.CGM.getIntrinsic(llvm::Intrinsic::stackrestore);
-// We could load StackBase from StackBaseMem, but in the non-exceptional
-// case we can skip it.
-CGF.Builder.CreateCall(F, StackBase);
-  }
-}
-
 void CodeGenFunction::EmitNonNullArgCheck(RValue RV, QualType ArgType,
   SourceLocation ArgLoc,
   const FunctionDecl *FD,
@@ -3533,10 +3523,6 @@ RValue CodeGenFunction::EmitCall(const C
   if (CallArgs.hasWritebacks())
 emitWritebacks(*this, CallArgs);
 
-  // The stack cleanup for inalloca arguments has to run out of the normal
-  // lexical order, so deactivate it and run it manually here.
-  CallArgs.freeArgumentMemory(*this);
-
   RValue Ret = [&] {
 switch (RetAI.getKind()) {
 case ABIArgInfo::InAlloca:

Modified: cfe/trunk/lib/CodeGen/CGCall.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.h?rev=245879&r1=245878&r2=245879&view=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.h (original)
+++ cfe/trunk/lib/CodeGen/CGCall.h Mon Aug 24 16:34:21 2015
@@ -120,7 +120,6 @@ namespace CodeGen {
 
 void allocateArgumentMemory(CodeGenFunction &CGF);
 llvm::Instruction *getStackBase() const { return StackBase; }
-void freeArgumentMemory(CodeGenFunction &CGF) const;
 
 /// \brief Returns if we're using an inalloca struct to pass arguments in
 /// memory.

Modified: cfe/trunk/test/CodeGenCXX/microsoft-abi-arg-order.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/microsoft-abi-arg-order.cpp?rev=245879&r1=245878&r2=245879&view=diff
==
--- cfe/trunk/test/CodeGenCXX/microsoft-abi-arg-order.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/microsoft-abi-arg-order.cpp Mon Aug 24 16:34:21 
2015
@@ -42,12 +42,12 @@ void call_foo() {
 // X86: call i8* @llvm.stacksave()
 // X86: %[[argmem:[^ ]*]] = alloca inalloca [[argmem_ty]]
 // X86: %[[arg3:[^ ]*]] = getelementptr inbounds [[argmem_ty]], [[argmem_ty]]* 
%[[argmem]], i32 0, i32 2
-// X86: invoke x86_thiscallcc %struct.A* @"\01??0A@@QAE@H@Z"(%struct.A* 
%[[arg3]], i32 3)
+// X86: call x86_thiscallcc %struct.A* @"\01??0A@@QAE@H@Z"(%struct.A* 
%[[arg3]], i32 3)
 // X86: %[[arg2:[^ ]*]] = getelementptr inbounds [[argmem_ty]], [[argmem_ty]]* 
%[[argmem]], i32 0, i32 1
 // X86: invoke x86_thiscallcc %struct.A* @"\01??0A@@QAE@H@Z"(%struct.A* 
%[[arg2]], i32 2)
 // X86: %[[arg1:[^ ]*]] = getelementptr inbounds [[argmem_ty]], [[argmem_ty]]* 
%[[argmem]], i32 0, i32 0
 // X86: invoke x86_thiscallcc %struct.A* @"\01??0A@@QAE@H@Z"(%struct.A* 
%[[arg1]], i32 1)
-// X86: invoke void @"\01?foo@@YAXUA@@00@Z"([[argmem_ty]]* inalloca 
%[[argmem]])
+// X86: call void @"\01?foo@@YAXUA@@00@Z"([[argmem_ty]]* inalloca %[[argmem]])
 // X86: call void @llvm.stackrestore
 // X86: ret void
 //

Modified: cfe/trunk/test/CodeGenCXX/microsoft-abi-eh-cleanups.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/microsoft-abi-eh-cleanups.cpp?rev=245879&r1=245878&r2=245879&view=diff
==
--- cfe/trunk/test/CodeGenCXX/microsoft-abi-eh-cleanups.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/microsoft-abi-eh-cleanups.cpp Mon Aug 24 16:34:21 
2015
@@ -17,18 +17,17 @@ void HasEHCleanup() {
 // WIN32-LABEL: define void @"\01?HasEHCleanup@@YAXXZ"() {{.*}} {
 // WIN32:   %[[base:.*]] = call i8* @llvm.stacksave()
 //If 

Re: [PATCH] D11664: [CUDA] Implemented additional processing steps needed to link with CUDA libdevice bitcode.

[Eric Christopher via cfe-commits]

echristo added inline comments.


Comment at: lib/CodeGen/CodeGenAction.cpp:181-190
@@ -166,2 +180,12 @@
   return;
+if (LangOpts.CUDA && LangOpts.CUDAIsDevice &&
+LangOpts.CUDAUsesLibDevice) {
+  legacy::PassManager passes;
+  passes.add(createInternalizePass(ModuleFuncNames));
+  // Considering that most of the functions we've linked are
+  // not going to be used, we may want to eliminate them
+  // early.
+  passes.add(createGlobalDCEPass());
+  passes.run(*TheModule);
+}
   }

tra wrote:
> echristo wrote:
> > Seems like this should be part of the normal IPO pass run? This seems like 
> > an odd place to put this, can you explain why a bit more?
> It will indeed happen during normal optimization, but as NVPTX docs says it 
> makes fair amount of sense to eliminate quite a bit of bitcode that we know 
> we're not going to need. libdevice carries ~450 functions and only handful of 
> those are needed. Why run all other optimization passes on them?
> 
> In addition to that, we need to pass to Internalize list of symbols to 
> preserve. As far as I can tell the way to do it within normal optimization 
> pipeline is to pass them to back-end via 
> -internalize-public-api-list/-internalize-public-api-file. That's not 
> particularly suitable way to carry potentially large list of symbols we will 
> find in the TU we're dealing with.
> 
> I could move GDCE to LLVM where it would arguably be somewhat more effective 
> if done after NVVMReflect, but keeping it next to internalize makes it easier 
> to see that we intentionally internalize and eliminate unused bitcode here.
I might not have been clear. I'm curious why all of this isn't just part of the 
normal IPO pass run that should be happening on the code anyhow? Taking a step 
back - this should just go through the normal "let's set up a pipeline for the 
code", which might end up being cuda specific, but should be handled in the 
same way.

That make sense?


http://reviews.llvm.org/D11664



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

[PATCH] D12297: [libcxx] Fix most undefined behavior in

[Eric Fiselier via cfe-commits]

EricWF created this revision.
EricWF added reviewers: mclow.lists, danalbert, rsmith.
EricWF added subscribers: cfe-commits, awi, rsmith.

This patch partially fixes the undefined behavior in ``. The undefined 
behavior is caused by casting a pointer to `__node_base __end_` to the derived 
type `__node` even though `__end_` is not a sub-object of type `__node`.

See C++14 [expr.static.cast]p11

> A prvalue of type “pointer to cv1 B,” where B is a class type, can be 
> converted to a prvalue of type “pointer to cv2 D,” where D is a class derived 
> (Clause 10) from B, if a valid standard conversion from “pointer to D” to 
> “pointer to B” exists (4.10), cv2 is the same cv-qualification as, or greater 
> cv-qualification than, cv1, and B is neither a virtual base class of D nor a 
> base class of a virtual base class of D. The null pointer value (4.10) is 
> converted to the null pointer value of the destination type. If the prvalue 
> of type “pointer to cv1 B” points to a B that is actually a subobject of an 
> object of type D, the resulting pointer points to the enclosing object of 
> type D. Otherwise, the behavior is undefined.

This patch fixes the problem by adding an intermediary void cast so that the 
conversion acts as if it were a reinterpret_cast. A reinterpret cast between 
pointer types is not used because this will not work with fancy pointers. This 
depends on the wording in:

C++14 [expr.reinterpret.cast]p7

> An object pointer can be explicitly converted to an object pointer of a 
> different type. When a prvalue v of object pointer type is converted to the 
> object pointer type “pointer to cv T”, the result is static_cast T*>(static_cast(v)). Converting a prvalue of type “pointer to T1” 
> to the type “pointer to T2” (where T1 and T2 are object types and where the 
> alignment requirements of T2 are no stricter than those of T1) and back to 
> its original type yields the original pointer value.

However, as @rsmith pointed out, this still has undefined behavior when the 
`element_type` stored in the list has a higher alignment requirement than that 
of a pointer.

I will post a patch that completely fixes this problem but that likely involves 
an ABI break.

http://reviews.llvm.org/D12297

Files:
  include/list

Index: include/list
===
--- include/list
+++ include/list
@@ -205,7 +205,8 @@
 _LIBCPP_INLINE_VISIBILITY
 pointer __self()
 {
-return 
static_cast(pointer_traits<__base_pointer>::pointer_to(*this));
+return static_cast(static_cast<_VoidPtr>(
+pointer_traits<__base_pointer>::pointer_to(*this)));
 }
 };
 
@@ -543,22 +544,18 @@
 iterator end() _NOEXCEPT
 {
 #if _LIBCPP_DEBUG_LEVEL >= 2
-return iterator(static_cast<__node_pointer>(
-pointer_traits<__node_base_pointer>::pointer_to(__end_)), 
this);
+return iterator(__end_.__self(), this);
 #else
-return iterator(static_cast<__node_pointer>(
-  
pointer_traits<__node_base_pointer>::pointer_to(__end_)));
+return iterator(__end_.__self());
 #endif
 }
 _LIBCPP_INLINE_VISIBILITY
 const_iterator end() const _NOEXCEPT
 {
 #if _LIBCPP_DEBUG_LEVEL >= 2
-return const_iterator(static_cast<__node_const_pointer>(
-
pointer_traits<__node_base_pointer>::pointer_to(const_cast<__node_base&>(__end_))),
 this);
+return const_iterator(const_cast<__node_base&>(__end_).__self(), this);
 #else
-return const_iterator(static_cast<__node_const_pointer>(
-
pointer_traits<__node_base_pointer>::pointer_to(const_cast<__node_base&>(__end_;
+return const_iterator(const_cast<__node_base&>(__end_).__self());
 #endif
 }
 


Index: include/list
===
--- include/list
+++ include/list
@@ -205,7 +205,8 @@
 _LIBCPP_INLINE_VISIBILITY
 pointer __self()
 {
-return static_cast(pointer_traits<__base_pointer>::pointer_to(*this));
+return static_cast(static_cast<_VoidPtr>(
+pointer_traits<__base_pointer>::pointer_to(*this)));
 }
 };
 
@@ -543,22 +544,18 @@
 iterator end() _NOEXCEPT
 {
 #if _LIBCPP_DEBUG_LEVEL >= 2
-return iterator(static_cast<__node_pointer>(
-pointer_traits<__node_base_pointer>::pointer_to(__end_)), this);
+return iterator(__end_.__self(), this);
 #else
-return iterator(static_cast<__node_pointer>(
-  pointer_traits<__node_base_pointer>::pointer_to(__end_)));
+return iterator(__end_.__self());
 #endif
 }
 _LIBCPP_INLINE_VISIBILITY
 const_iterator end() const _NOEXCEPT
 {
 #if _LIBCPP_DEBUG_LEVEL >= 2
-return const_iterator(static_cast<__node_const_pointer>(
-pointer_traits<__node_base_pointer>::pointer_to(const_cast<__node_base&>(__end_))), this);
+return const_iterator(const_cast<__node_base

r245881 - [modules] Remove unnecessary deserialization of fully-external HeaderFileInfos for all files we've seen in this compilation.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Mon Aug 24 16:59:32 2015
New Revision: 245881

URL: http://llvm.org/viewvc/llvm-project?rev=245881&view=rev
Log:
[modules] Remove unnecessary deserialization of fully-external HeaderFileInfos 
for all files we've seen in this compilation.

Modified:
cfe/trunk/include/clang/Lex/HeaderSearch.h
cfe/trunk/include/clang/Lex/ModuleMap.h
cfe/trunk/lib/Lex/HeaderSearch.cpp
cfe/trunk/lib/Lex/ModuleMap.cpp
cfe/trunk/lib/Serialization/ASTReader.cpp
cfe/trunk/lib/Serialization/ASTWriter.cpp

Modified: cfe/trunk/include/clang/Lex/HeaderSearch.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Lex/HeaderSearch.h?rev=245881&r1=245880&r2=245881&view=diff
==
--- cfe/trunk/include/clang/Lex/HeaderSearch.h (original)
+++ cfe/trunk/include/clang/Lex/HeaderSearch.h Mon Aug 24 16:59:32 2015
@@ -570,11 +570,16 @@ public:
   
   unsigned header_file_size() const { return FileInfo.size(); }
 
-  /// \brief Return the HeaderFileInfo structure for the specified FileEntry.
+  /// \brief Return the HeaderFileInfo structure for the specified FileEntry,
+  /// in preparation for updating it in some way.
   HeaderFileInfo &getFileInfo(const FileEntry *FE);
 
-  /// \brief Return the HeaderFileInfo structure for the specified FileEntry.
-  const HeaderFileInfo *getExistingFileInfo(const FileEntry *FE) const;
+  /// \brief Return the HeaderFileInfo structure for the specified FileEntry,
+  /// if it has ever been filled in.
+  /// \param WantExternal Whether the caller wants purely-external header file
+  ///info (where \p External is true).
+  const HeaderFileInfo *getExistingFileInfo(const FileEntry *FE,
+bool WantExternal = true) const;
 
   // Used by external tools
   typedef std::vector::const_iterator search_dir_iterator;

Modified: cfe/trunk/include/clang/Lex/ModuleMap.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Lex/ModuleMap.h?rev=245881&r1=245880&r2=245881&view=diff
==
--- cfe/trunk/include/clang/Lex/ModuleMap.h (original)
+++ cfe/trunk/include/clang/Lex/ModuleMap.h Mon Aug 24 16:59:32 2015
@@ -478,7 +478,7 @@ public:
   /// \brief Adds this header to the given module.
   /// \param Role The role of the header wrt the module.
   void addHeader(Module *Mod, Module::Header Header,
- ModuleHeaderRole Role);
+ ModuleHeaderRole Role, bool Imported = false);
 
   /// \brief Marks this header as being excluded from the given module.
   void excludeHeader(Module *Mod, Module::Header Header);

Modified: cfe/trunk/lib/Lex/HeaderSearch.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/HeaderSearch.cpp?rev=245881&r1=245880&r2=245881&view=diff
==
--- cfe/trunk/lib/Lex/HeaderSearch.cpp (original)
+++ cfe/trunk/lib/Lex/HeaderSearch.cpp Mon Aug 24 16:59:32 2015
@@ -963,21 +963,22 @@ LookupSubframeworkHeader(StringRef Filen
 /// header file info (\p HFI)
 static void mergeHeaderFileInfo(HeaderFileInfo &HFI, 
 const HeaderFileInfo &OtherHFI) {
+  assert(OtherHFI.External && "expected to merge external HFI");
+
   HFI.isImport |= OtherHFI.isImport;
   HFI.isPragmaOnce |= OtherHFI.isPragmaOnce;
   HFI.isModuleHeader |= OtherHFI.isModuleHeader;
   HFI.NumIncludes += OtherHFI.NumIncludes;
-  
+
   if (!HFI.ControllingMacro && !HFI.ControllingMacroID) {
 HFI.ControllingMacro = OtherHFI.ControllingMacro;
 HFI.ControllingMacroID = OtherHFI.ControllingMacroID;
   }
-  
-  if (OtherHFI.External) {
-HFI.DirInfo = OtherHFI.DirInfo;
-HFI.External = OtherHFI.External && (!HFI.IsValid || HFI.External);
-HFI.IndexHeaderMapHeader = OtherHFI.IndexHeaderMapHeader;
-  }
+
+  HFI.DirInfo = OtherHFI.DirInfo;
+  HFI.External = (!HFI.IsValid || HFI.External);
+  HFI.IsValid = true;
+  HFI.IndexHeaderMapHeader = OtherHFI.IndexHeaderMapHeader;
 
   if (HFI.Framework.empty())
 HFI.Framework = OtherHFI.Framework;
@@ -989,42 +990,58 @@ HeaderFileInfo &HeaderSearch::getFileInf
   if (FE->getUID() >= FileInfo.size())
 FileInfo.resize(FE->getUID() + 1);
 
-  HeaderFileInfo &HFI = FileInfo[FE->getUID()];
+  HeaderFileInfo *HFI = &FileInfo[FE->getUID()];
   // FIXME: Use a generation count to check whether this is really up to date.
-  if (ExternalSource && !HFI.Resolved) {
-HFI.Resolved = true;
-mergeHeaderFileInfo(HFI, ExternalSource->GetHeaderFileInfo(FE));
+  if (ExternalSource && !HFI->Resolved) {
+HFI->Resolved = true;
+auto ExternalHFI = ExternalSource->GetHeaderFileInfo(FE);
+
+HFI = &FileInfo[FE->getUID()];
+if (ExternalHFI.External)
+  mergeHeaderFileInfo(*HFI, ExternalHFI);
   }
 
-  HFI.IsValid = true;
+  HFI->IsValid = true;
   // We have local information about this header fi

[PATCH] D12299: [libcxx] ABI-Breaking Fix for ALL undefined behavior in .

[Eric Fiselier via cfe-commits]

EricWF created this revision.
EricWF added reviewers: mclow.lists, danalbert, jroelofs.
EricWF added a subscriber: cfe-commits.

This patch is an ABI-breaking version of D12297. However unlike D12297, this 
patch does not have any undefined behavior when `element_type` has a stricter 
alignment requirement than a pointer.

Note: More investigation needs to be done to see *how* ABI-breaking this patch 
is because it simply replaces `__node_pointer`'s via `__node_base_pointers` and 
we may be able to sneak that change in.

http://reviews.llvm.org/D12299

Files:
  include/list

Index: include/list
===
--- include/list
+++ include/list
@@ -191,21 +191,25 @@
 template 
 struct __list_node_base
 {
-typedef typename __rebind_pointer<_VoidPtr, __list_node<_Tp, _VoidPtr> >::type
-pointer;
 typedef typename __rebind_pointer<_VoidPtr, __list_node_base>::type
-__base_pointer;
-
-pointer __prev_;
-pointer __next_;
+__node_base_pointer;
+typedef typename __rebind_pointer<_VoidPtr, __list_node<_Tp, _VoidPtr> >::type
+__node_pointer;
+__node_base_pointer __prev_;
+__node_base_pointer __next_;
 
 _LIBCPP_INLINE_VISIBILITY
-__list_node_base() : __prev_(__self()), __next_(__self()) {}
+__list_node_base() : __prev_(__as_base()), __next_(__as_base()) {}
 
 _LIBCPP_INLINE_VISIBILITY
-pointer __self()
+__node_base_pointer __as_base()
 {
-return static_cast(pointer_traits<__base_pointer>::pointer_to(*this));
+return pointer_traits<__node_base_pointer>::pointer_to(*this);
+}
+_LIBCPP_INLINE_VISIBILITY
+__node_pointer __as_node()
+{
+return static_cast<__node_pointer>(__as_base());
 }
 };
 
@@ -223,21 +227,21 @@
 template 
 class _LIBCPP_TYPE_VIS_ONLY __list_iterator
 {
-typedef typename __rebind_pointer<_VoidPtr, __list_node<_Tp, _VoidPtr> >::type
-__node_pointer;
+typedef typename __rebind_pointer<_VoidPtr, __list_node_base<_Tp, _VoidPtr> >::type
+__node_base_pointer;
 
-__node_pointer __ptr_;
+__node_base_pointer __ptr_;
 
 #if _LIBCPP_DEBUG_LEVEL >= 2
 _LIBCPP_INLINE_VISIBILITY
-explicit __list_iterator(__node_pointer __p, const void* __c) _NOEXCEPT
+explicit __list_iterator(__node_base_pointer __p, const void* __c) _NOEXCEPT
 : __ptr_(__p)
 {
 __get_db()->__insert_ic(this, __c);
 }
 #else
 _LIBCPP_INLINE_VISIBILITY
-explicit __list_iterator(__node_pointer __p) _NOEXCEPT : __ptr_(__p) {}
+explicit __list_iterator(__node_base_pointer __p) _NOEXCEPT : __ptr_(__p) {}
 #endif
 
 
@@ -295,7 +299,7 @@
 _LIBCPP_ASSERT(__get_const_db()->__dereferenceable(this),
"Attempted to dereference a non-dereferenceable list::iterator");
 #endif
-return __ptr_->__value_;
+return __ptr_->__as_node()->__value_;
 }
 _LIBCPP_INLINE_VISIBILITY
 pointer operator->() const
@@ -304,7 +308,7 @@
 _LIBCPP_ASSERT(__get_const_db()->__dereferenceable(this),
"Attempted to dereference a non-dereferenceable list::iterator");
 #endif
-return pointer_traits::pointer_to(__ptr_->__value_);
+return pointer_traits::pointer_to(__ptr_->__as_node()->__value_);
 }
 
 _LIBCPP_INLINE_VISIBILITY
@@ -346,21 +350,21 @@
 template 
 class _LIBCPP_TYPE_VIS_ONLY __list_const_iterator
 {
-typedef typename __rebind_pointer<_VoidPtr, __list_node<_Tp, _VoidPtr> >::type
-__node_pointer;
+typedef typename __rebind_pointer<_VoidPtr, __list_node_base<_Tp, _VoidPtr> >::type
+__node_base_pointer;
 
-__node_pointer __ptr_;
+__node_base_pointer __ptr_;
 
 #if _LIBCPP_DEBUG_LEVEL >= 2
 _LIBCPP_INLINE_VISIBILITY
-explicit __list_const_iterator(__node_pointer __p, const void* __c) _NOEXCEPT
+explicit __list_const_iterator(__node_base_pointer __p, const void* __c) _NOEXCEPT
 : __ptr_(__p)
 {
 __get_db()->__insert_ic(this, __c);
 }
 #else
 _LIBCPP_INLINE_VISIBILITY
-explicit __list_const_iterator(__node_pointer __p) _NOEXCEPT : __ptr_(__p) {}
+explicit __list_const_iterator(__node_base_pointer __p) _NOEXCEPT : __ptr_(__p) {}
 #endif
 
 template friend class list;
@@ -422,7 +426,7 @@
 _LIBCPP_ASSERT(__get_const_db()->__dereferenceable(this),
"Attempted to dereference a non-dereferenceable list::const_iterator");
 #endif
-return __ptr_->__value_;
+return __ptr_->__as_node()->__value_;
 }
 _LIBCPP_INLINE_VISIBILITY
 pointer operator->() const
@@ -431,7 +435,7 @@
 _LIBCPP_ASSERT(__get_const_db()->__dereferenceable(this),
"Attempted to dereference a non-dereferenceable list::iterator");
 #endif
-return pointer_traits::pointer_to(__ptr_->__value_);
+return pointer_traits::pointer_to(__ptr_->__as_node()->__value_);
 }
 
 _LIB

Re: [PATCH] D10732: [OPENMP 4.0] Initial support for array sections.

[Richard Smith via cfe-commits]

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

Thanks, LGTM!



Comment at: lib/Sema/SemaExpr.cpp:4035
@@ +4034,3 @@
+  // Build an unanalyzed expression if either operand is type-dependent.
+  if (Base->isTypeDependent() || Base->isValueDependent() ||
+  (LowerBound &&

I don't think you need to care whether `Base` is value-dependent here, because 
you don't care whether you can evaluate it.


Comment at: lib/Sema/SemaExpr.cpp:4088
@@ +4087,3 @@
+  // C++ [expr.sub]p1: The type "T" shall be a completely-defined object
+  // type. Note that Functions are not objects, and that (in C99 parlance)
+  // incomplete types are not object types.

Functions -> functions


http://reviews.llvm.org/D10732



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

[PATCH] D12301: [PATCH] New checker for UB in handler of a function-try-block

[Aaron Ballman via cfe-commits]

aaron.ballman created this revision.
aaron.ballman added reviewers: alexfh, rsmith.
aaron.ballman added a subscriber: cfe-commits.

Per [except.handle]p10, the handler for a constructor or destructor 
function-try-block cannot refer to a non-static member of the object under 
construction. This patch adds a new clang-tidy check that warns the user when 
they've hit this undefined behavior.

Due to how infrequent function-try-blocks appear on constructors and 
destructors in the wild compared to how often member expressions are 
encountered, I felt this was more appropriate as a clang-tidy check than as a 
semantic warning. I was concerned with efficiency of checking whether an 
arbitrary member expression was referring to the object under 
construction/destruction within the function-try-block catch handler scope.

This patch corresponds to the CERT secure coding rule ERR53-CPP 
(https://www.securecoding.cert.org/confluence/display/cplusplus/ERR53-CPP.+Do+not+reference+base+classes+or+class+data+members+in+a+constructor+or+destructor+function-try-block+handler)

http://reviews.llvm.org/D12301

Files:
  clang-tidy/misc/CDtorCatchHandlerCheck.cpp
  clang-tidy/misc/CDtorCatchHandlerCheck.h
  clang-tidy/misc/CMakeLists.txt
  clang-tidy/misc/MiscTidyModule.cpp
  test/clang-tidy/misc-cdtor-catch-handler.cpp

Index: test/clang-tidy/misc-cdtor-catch-handler.cpp
===
--- test/clang-tidy/misc-cdtor-catch-handler.cpp
+++ test/clang-tidy/misc-cdtor-catch-handler.cpp
@@ -0,0 +1,92 @@
+// RUN: %python %S/check_clang_tidy.py %s misc-cdtor-catch-handler %t -- -fcxx-exceptions -std=c++14
+
+int FileScope;
+
+struct A {
+  int I;
+  void f();
+  A() try {
+  } catch (...) {
+	// CHECK-MESSAGES: :[[@LINE+1]]:5: warning: cannot refer to a non-static member from the handler of a constructor function-try-block
+I = 12;
+// CHECK-MESSAGES: :[[@LINE+1]]:5: warning: cannot refer to a non-static member from the handler of a constructor function-try-block
+f();
+
+FileScope = 12; // ok
+A a;
+a.I = 12; // ok
+  }
+};
+
+struct B {
+  int I;
+  void f();
+};
+
+struct C : B {
+  C() try {
+  } catch (...) {
+// CHECK-MESSAGES: :[[@LINE+1]]:5: warning: cannot refer to a non-static member from the handler of a constructor function-try-block
+I = 12;
+// CHECK-MESSAGES: :[[@LINE+1]]:5: warning: cannot refer to a non-static member from the handler of a constructor function-try-block
+f();
+  }
+};
+
+struct D {
+  static int I;
+  static void f();
+
+  D() try {
+  } catch (...) {
+I = 12; // ok
+f(); // ok
+  }
+};
+int D::I;
+
+struct E {
+  int I;
+  void f();
+  static int J;
+  static void g();
+
+  ~E() try {
+  } catch (...) {
+// CHECK-MESSAGES: :[[@LINE+1]]:5: warning: cannot refer to a non-static member from the handler of a destructor function-try-block
+I = 12;
+// CHECK-MESSAGES: :[[@LINE+1]]:5: warning: cannot refer to a non-static member from the handler of a destructor function-try-block
+f();
+
+J = 12; // ok
+g(); // ok
+  }
+};
+int E::J;
+
+struct F {
+  static int I;
+  static void f();
+};
+int F::I;
+
+struct G : F {
+  G() try {
+  } catch (...) {
+I = 12; // ok
+f(); // ok
+  }
+};
+
+struct H {
+  struct A {};
+  enum {
+E
+  };
+
+  H() try {
+  } catch (...) {
+H::A a; // ok
+int I = E; // ok
+  }
+};
Index: clang-tidy/misc/MiscTidyModule.cpp
===
--- clang-tidy/misc/MiscTidyModule.cpp
+++ clang-tidy/misc/MiscTidyModule.cpp
@@ -14,6 +14,7 @@
 #include "AssertSideEffectCheck.h"
 #include "AssignOperatorSignatureCheck.h"
 #include "BoolPointerImplicitConversionCheck.h"
+#include "CDtorCatchHandlerCheck.h"
 #include "InaccurateEraseCheck.h"
 #include "InefficientAlgorithmCheck.h"
 #include "MacroParenthesesCheck.h"
@@ -43,6 +44,8 @@
 "misc-assign-operator-signature");
 CheckFactories.registerCheck(
 "misc-bool-pointer-implicit-conversion");
+CheckFactories.registerCheck(
+"misc-cdtor-catch-handler");
 CheckFactories.registerCheck(
 "misc-inaccurate-erase");
 CheckFactories.registerCheck(
Index: clang-tidy/misc/CMakeLists.txt
===
--- clang-tidy/misc/CMakeLists.txt
+++ clang-tidy/misc/CMakeLists.txt
@@ -5,6 +5,7 @@
   AssertSideEffectCheck.cpp
   AssignOperatorSignatureCheck.cpp
   BoolPointerImplicitConversionCheck.cpp
+  CDtorCatchHandlerCheck.cpp
   InaccurateEraseCheck.cpp
   InefficientAlgorithmCheck.cpp
   MacroParenthesesCheck.cpp
Index: clang-tidy/misc/CDtorCatchHandlerCheck.h
===
--- clang-tidy/misc/CDtorCatchHandlerCheck.h
+++ clang-tidy/misc/CDtorCatchHandlerCheck.h
@@ -0,0 +1,32 @@
+//===--- CDtorCatchHandlerCheck.h - clang-tidy---*- C++ -*-===//
+//
+// The LLVM Compiler Infrastru

Re: [PATCH] Have clang list the imported modules in the debug info

[Richard Smith via cfe-commits]

+static void escape(llvm::raw_ostream &OS, StringRef String) {
+  for (auto C: String) {
+if (strchr("\\\"", C))
+  OS << '\\';
+OS << C;
+  }
+}

Do we not have an existing function somewhere to do that? Also, that strchr
call is a very complex way of writing (C == '\\' || C == '"')

On Mon, Aug 24, 2015 at 2:01 PM, David Blaikie  wrote:

>
>
> On Mon, Aug 24, 2015 at 1:23 PM, Adrian Prantl  wrote:
>
>>
>> On Aug 19, 2015, at 1:20 PM, David Blaikie  wrote:
>>
>>
>>
>> On Mon, Aug 10, 2015 at 5:00 PM, Adrian Prantl  wrote:
>>
>>>
>>> On Jul 24, 2015, at 12:33 PM, David Blaikie  wrote:
>>>
>>> *reads back through the thread*
>>>
>>>
>>> appreciated, it’s long :-)
>>>
>>> So what I originally had in mind about a year ago when we discussed
>>> this, was that the module data could have an extra table from type hash to
>>> whatever useful internal representation to find the type in the PCM.
>>>
>>>
>>> It turned out that the most useful internal type representation to find
>>> a type in a PCM is the type’s DeclContext+Name; this is how (surprise!)
>>> clang looks up types in a PCM and the format is supposed to be fast for
>>> these kind of lookups.
>>>
>>
>> Still, I would imagine there would be some kind of direct access (the
>> offset in the file, or somesuch) rather than actually having to go through
>> hashtables, etc. No? (how does one module refer to types in another module?
>> Really by name?)
>>
>>
>> Entities in PCMs have local integer IDs (just consecutive numbers) that
>> are used to encode references inside a record on disk. An external
>> reference gets a global ID which is the local ID + the ID of the other
>> module. This numbering scheme of course only makes sense within a module
>> (and perhaps also within a chained PCH). Every (local and global) ID maps
>> to an entry in the PCM’s identifier table. When deserializing, the
>> in-memory global IdentifierTable is built and each module gets a map that
>> remaps its internal global IDs to the “global” global IDs.
>>
>> For debug info these IDs are not very useful, because they are not
>> resilient against even the smallest additive change to the module. We could
>> add an integer attribute with the module-internal entity ID to the forward
>> declaration that the debugger can use if the module hash and the CU’s dwoid
>> are matching, but I’m not yet convinced that it would be worth it. Adding
>> it to the definition of the type in the module dwarf seems not worth it
>> because then we already have to do a similarly expensive lookup to find the
>> module containing the definition.
>>
>
> It seems that ideally a module-aware debugger would not consult the DWARF
> at all, so I wouldn't advocate having the module format type ID in the
> DWARF, but in a side table (either part of the module itself, or just a
> section of its own in the module-as-object-file).
>
> Why is it important that the IDs be resilient to changes in the module?
> I'm suggesting that non-module debug info should only use type hashes, then
> within the module itself there would be a hash-to-ID mapping (a flat table,
> probably, wouldn't need to be anything fancy). This would keep the DWARF
> less polluted by module concepts - it'd just be up to the consumer "oh,
> here's a type hash identifier, resolve that to an AST - either by looking
> in DWARF and building an AST from the DWARF type unit with the matching
> hash, or by looking in the module and finding the ID/loading the type"?
>
>
>>
>>
>>> Everything else would just be DWARF with type units and fission (with
>>> the slight wrinkle of type units that aren't resolvable within a single
>>> object file - they could reference cross-object/dwo file) - emitting a
>>> fission CU for each referenced module.
>>>
>>> Needing modules to disambiguate/avoid collisions/support non-odr
>>> languages wasn't something I understood/had considered back then. That
>>> explains the need to add module references to the CU, so the debugger can
>>> know which modules to search for the types in (& doesn't just go loading
>>> all of them, etc).
>>>
>>> I would still picture this as "normal type units + a table in the module
>>> to resolve types", but if you guys particularly like using the mangled
>>> string name (or other identifier) in the DWARF that may avoid the need for
>>> an intermediate table (but it doesn't sound like you are avoiding an
>>> intermediate table - you said something about having an
>>> accelerator-table-like thing to aid in the DWARF->AST mapping? So could
>>> that be key'd of the type hash/signature we're using, thus keeping the
>>> DWARF more plain/vanilla DWARF5 (type units + fission)?)
>>>
>>>
>>> I originally disliked type signatures and favored using mangled names
>>> because the mangled names contained the DeclContext necessary to find types
>>> in the PCM. But if we can squeeze the DeclContext somewhere else, that’s
>>> fine.
>>>
>>> From the discussion we had on FlagExternalTypeRef I got the impression
>>> tha

Re: [PATCH] D12301: [PATCH] New checker for UB in handler of a function-try-block

[Richard Smith via cfe-commits]

On Mon, Aug 24, 2015 at 3:23 PM, Aaron Ballman 
wrote:

> aaron.ballman created this revision.
> aaron.ballman added reviewers: alexfh, rsmith.
> aaron.ballman added a subscriber: cfe-commits.
>
> Per [except.handle]p10, the handler for a constructor or destructor
> function-try-block cannot refer to a non-static member of the object under
> construction. This patch adds a new clang-tidy check that warns the user
> when they've hit this undefined behavior.
>
> Due to how infrequent function-try-blocks appear on constructors and
> destructors in the wild compared to how often member expressions are
> encountered, I felt this was more appropriate as a clang-tidy check than as
> a semantic warning. I was concerned with efficiency of checking whether an
> arbitrary member expression was referring to the object under
> construction/destruction within the function-try-block catch handler scope.
>

Seems like this would be very cheap to check in the case where the object
expression is an implicit or explicit CXXThisExpr. It'd be good to have a
frontend warning for that case.


> This patch corresponds to the CERT secure coding rule ERR53-CPP (
> https://www.securecoding.cert.org/confluence/display/cplusplus/ERR53-CPP.+Do+not+reference+base+classes+or+class+data+members+in+a+constructor+or+destructor+function-try-block+handler
> )
>
> http://reviews.llvm.org/D12301
>
> Files:
>   clang-tidy/misc/CDtorCatchHandlerCheck.cpp
>   clang-tidy/misc/CDtorCatchHandlerCheck.h
>   clang-tidy/misc/CMakeLists.txt
>   clang-tidy/misc/MiscTidyModule.cpp
>   test/clang-tidy/misc-cdtor-catch-handler.cpp
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12281: Tests no longer need the 'REQUIRES: SHELL' line.

[Alexander Kornienko via cfe-commits]

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

LG. Thank you!


http://reviews.llvm.org/D12281



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

Re: [PATCH] Have clang list the imported modules in the debug info

[Adrian Prantl via cfe-commits]

> On Aug 24, 2015, at 2:01 PM, David Blaikie  wrote:
> 
> 
> 
> On Mon, Aug 24, 2015 at 1:23 PM, Adrian Prantl  > wrote:
> 
>> On Aug 19, 2015, at 1:20 PM, David Blaikie > > wrote:
>> 
>> 
>> 
>> On Mon, Aug 10, 2015 at 5:00 PM, Adrian Prantl > > wrote:
>> 
>>> On Jul 24, 2015, at 12:33 PM, David Blaikie >> > wrote:
>>> 
>>> *reads back through the thread*
>> 
>> appreciated, it’s long :-)
>> 
>>> So what I originally had in mind about a year ago when we discussed this, 
>>> was that the module data could have an extra table from type hash to 
>>> whatever useful internal representation to find the type in the PCM.
>> 
>> It turned out that the most useful internal type representation to find a 
>> type in a PCM is the type’s DeclContext+Name; this is how (surprise!) clang 
>> looks up types in a PCM and the format is supposed to be fast for these kind 
>> of lookups.
>> 
>> Still, I would imagine there would be some kind of direct access (the offset 
>> in the file, or somesuch) rather than actually having to go through 
>> hashtables, etc. No? (how does one module refer to types in another module? 
>> Really by name?)
> 
> Entities in PCMs have local integer IDs (just consecutive numbers) that are 
> used to encode references inside a record on disk. An external reference gets 
> a global ID which is the local ID + the ID of the other module. This 
> numbering scheme of course only makes sense within a module (and perhaps also 
> within a chained PCH). Every (local and global) ID maps to an entry in the 
> PCM’s identifier table. When deserializing, the in-memory global 
> IdentifierTable is built and each module gets a map that remaps its internal 
> global IDs to the “global” global IDs.
> 
> For debug info these IDs are not very useful, because they are not resilient 
> against even the smallest additive change to the module. We could add an 
> integer attribute with the module-internal entity ID to the forward 
> declaration that the debugger can use if the module hash and the CU’s dwoid 
> are matching, but I’m not yet convinced that it would be worth it. Adding it 
> to the definition of the type in the module dwarf seems not worth it because 
> then we already have to do a similarly expensive lookup to find the module 
> containing the definition.
> 
> It seems that ideally a module-aware debugger would not consult the DWARF at 
> all, so I wouldn't advocate having the module format type ID in the DWARF, 
> but in a side table (either part of the module itself, or just a section of 
> its own in the module-as-object-file).

Do you mean a side-table in the module that maps sig8 -> ID? If we need to 
perform hash lookups to get to the ID that we might as well look up the type by 
name in the module, because that’s also a hash table lookup. I don’t think a 
performance argument can be made for using IDs.

> 
> Why is it important that the IDs be resilient to changes in the module?

Several reasons I can think of:
- developers are used to being able to debug a binary with slightly out-of-date 
source code.
- if we use IDs we need to make the dwoid==modulehash check mandatory or we 
resolve random types, but that means that even adding whitespace to a header 
file means that module debugging won’t work any more.
- by using IDs we would be baking internal details about the clang module 
format into the debug info:
  - what if the clang module format changes?
  - a non-clang compiler+debugger could implement our debug info format with a 
different AST serialization scheme.
 
> I'm suggesting that non-module debug info should only use type hashes, then 
> within the module itself there would be a hash-to-ID mapping (a flat table, 
> probably, wouldn't need to be anything fancy).
> This would keep the DWARF less polluted by module concepts - it'd just be up 
> to the consumer "oh, here's a type hash identifier, resolve that to an AST - 
> either by looking in DWARF and building an AST from the DWARF type unit with 
> the matching hash, or by looking in the module and finding the ID/loading the 
> type”?

This is glossing over the fact that more metadata is needed to find and import 
the right version of the module. Metadata that is stored in the DW_TAG_module. 
Where is the module to be found (E.g., on Darwin the sysroot tells us whether 
to look in an OSX or an iOS SDK), which configuration of the module do we need 
to import (is -DNDEBUG enabled?), and the include path tells us where to find 
the header file if the module cache is out of date or deleted.

Ok there are really three issues here:
Should module types be looked up by ID or by name?
Should module type forward declarations be underneath the DW_TAG_module and/or 
the skeleton CU?
And, can we get away with just emitting ref_sig8s for ODR languages?
>  
> 
>> 
>>> Everything else would just be DWARF with type units and fission (with the 
>>> 

Re: [PATCH] D12301: [PATCH] New checker for UB in handler of a function-try-block

[Aaron Ballman via cfe-commits]

On Mon, Aug 24, 2015 at 6:29 PM, Richard Smith  wrote:
> On Mon, Aug 24, 2015 at 3:23 PM, Aaron Ballman 
> wrote:
>>
>> aaron.ballman created this revision.
>> aaron.ballman added reviewers: alexfh, rsmith.
>> aaron.ballman added a subscriber: cfe-commits.
>>
>> Per [except.handle]p10, the handler for a constructor or destructor
>> function-try-block cannot refer to a non-static member of the object under
>> construction. This patch adds a new clang-tidy check that warns the user
>> when they've hit this undefined behavior.
>>
>> Due to how infrequent function-try-blocks appear on constructors and
>> destructors in the wild compared to how often member expressions are
>> encountered, I felt this was more appropriate as a clang-tidy check than as
>> a semantic warning. I was concerned with efficiency of checking whether an
>> arbitrary member expression was referring to the object under
>> construction/destruction within the function-try-block catch handler scope.
>
>
> Seems like this would be very cheap to check in the case where the object
> expression is an implicit or explicit CXXThisExpr. It'd be good to have a
> frontend warning for that case.

Are you thinking the check would likely in BuildMemberReferenceExpr()
and I would just have to look at the current scope to determine
whether it's a function-try-block catch handler? When I looked into
doing a frontend warning for this, I seemed to struggle with figuring
out specifically that I was in the catch handler of a
function-try-block of a constructor or destructor.

~Aaron

>
>>
>> This patch corresponds to the CERT secure coding rule ERR53-CPP
>> (https://www.securecoding.cert.org/confluence/display/cplusplus/ERR53-CPP.+Do+not+reference+base+classes+or+class+data+members+in+a+constructor+or+destructor+function-try-block+handler)
>>
>> http://reviews.llvm.org/D12301
>>
>> Files:
>>   clang-tidy/misc/CDtorCatchHandlerCheck.cpp
>>   clang-tidy/misc/CDtorCatchHandlerCheck.h
>>   clang-tidy/misc/CMakeLists.txt
>>   clang-tidy/misc/MiscTidyModule.cpp
>>   test/clang-tidy/misc-cdtor-catch-handler.cpp
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libclc] r245894 - Update mailing list reference.

[Peter Collingbourne via cfe-commits]

Author: pcc
Date: Mon Aug 24 17:43:24 2015
New Revision: 245894

URL: http://llvm.org/viewvc/llvm-project?rev=245894&view=rev
Log:
Update mailing list reference.

Modified:
libclc/trunk/www/index.html

Modified: libclc/trunk/www/index.html
URL: 
http://llvm.org/viewvc/llvm-project/libclc/trunk/www/index.html?rev=245894&r1=245893&r2=245894&view=diff
==
--- libclc/trunk/www/index.html (original)
+++ libclc/trunk/www/index.html Mon Aug 24 17:43:24 2015
@@ -49,7 +49,7 @@ targets is welcome.
 
 Mailing List
 
-libclc-...@pcc.me.uk (http://www.pcc.me.uk/cgi-bin/mailman/listinfo/libclc-dev";>subscribe/unsubscribe,
 http://www.pcc.me.uk/pipermail/libclc-dev/";>archives)
+libclc-...@lists.llvm.org (http://lists.llvm.org/cgi-bin/mailman/listinfo/libclc-dev";>subscribe/unsubscribe,
 http://lists.llvm.org/pipermail/libclc-dev/";>archives)
 
 
 


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

Re: [PATCH] D12287: Add replace-auto_ptr check.

[Alexander Kornienko via cfe-commits]

alexfh added inline comments.


Comment at: clang-tidy/modernize/ReplaceAutoPtrCheck.h:20
@@ +19,3 @@
+
+class ReplaceAutoPtrCheck : public ClangTidyCheck {
+public:

Please add a class comment describing what the check does and why.


http://reviews.llvm.org/D12287



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

Re: [PATCH] D11857: CFI: Introduce -fsanitize=cfi-icall flag.

[Kostya Serebryany via cfe-commits]

kcc added inline comments.


Comment at: docs/ControlFlowIntegrity.rst:149
@@ +148,3 @@
+shared library boundaries are handled as if the callee was not compiled with
+``-fsanitize=cfi-icall``.
+

mention that LTO is require explicitly?


http://reviews.llvm.org/D11857



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

Re: [PATCH] Have clang list the imported modules in the debug info

[David Blaikie via cfe-commits]

On Mon, Aug 24, 2015 at 3:34 PM, Adrian Prantl  wrote:

>
> On Aug 24, 2015, at 2:01 PM, David Blaikie  wrote:
>
>
>
> On Mon, Aug 24, 2015 at 1:23 PM, Adrian Prantl  wrote:
>
>>
>> On Aug 19, 2015, at 1:20 PM, David Blaikie  wrote:
>>
>>
>>
>> On Mon, Aug 10, 2015 at 5:00 PM, Adrian Prantl  wrote:
>>
>>>
>>> On Jul 24, 2015, at 12:33 PM, David Blaikie  wrote:
>>>
>>> *reads back through the thread*
>>>
>>>
>>> appreciated, it’s long :-)
>>>
>>> So what I originally had in mind about a year ago when we discussed
>>> this, was that the module data could have an extra table from type hash to
>>> whatever useful internal representation to find the type in the PCM.
>>>
>>>
>>> It turned out that the most useful internal type representation to find
>>> a type in a PCM is the type’s DeclContext+Name; this is how (surprise!)
>>> clang looks up types in a PCM and the format is supposed to be fast for
>>> these kind of lookups.
>>>
>>
>> Still, I would imagine there would be some kind of direct access (the
>> offset in the file, or somesuch) rather than actually having to go through
>> hashtables, etc. No? (how does one module refer to types in another module?
>> Really by name?)
>>
>>
>> Entities in PCMs have local integer IDs (just consecutive numbers) that
>> are used to encode references inside a record on disk. An external
>> reference gets a global ID which is the local ID + the ID of the other
>> module. This numbering scheme of course only makes sense within a module
>> (and perhaps also within a chained PCH). Every (local and global) ID maps
>> to an entry in the PCM’s identifier table. When deserializing, the
>> in-memory global IdentifierTable is built and each module gets a map that
>> remaps its internal global IDs to the “global” global IDs.
>>
>> For debug info these IDs are not very useful, because they are not
>> resilient against even the smallest additive change to the module. We could
>> add an integer attribute with the module-internal entity ID to the forward
>> declaration that the debugger can use if the module hash and the CU’s dwoid
>> are matching, but I’m not yet convinced that it would be worth it. Adding
>> it to the definition of the type in the module dwarf seems not worth it
>> because then we already have to do a similarly expensive lookup to find the
>> module containing the definition.
>>
>
> It seems that ideally a module-aware debugger would not consult the DWARF
> at all, so I wouldn't advocate having the module format type ID in the
> DWARF, but in a side table (either part of the module itself, or just a
> section of its own in the module-as-object-file).
>
>
> Do you mean a side-table in the module that maps sig8 -> ID?
>

Yes, this is what I tried to articulate way-back-when we had the original
discussion in person at Google. That module debug info is Dwarf type units
(later bag-o-dwarf) + fission, plus a side table to make DWARF type
identifiers to module identifiers.

Certainly there are some wrinkles to that (possible type ambiguities and
module conflicts), but I'm really trying to stick to that original concept
and understand/investigate any deviation from it. (& more generally, any
deviation from existing DWARF practices in the field - while extensions are
totally reasonable, I want to really highlight when we're stepping beyond
existing practice and carefully choose how we do that rather than just
picking a representation and going with it - DWARF doesn't provide a lot of
guidance and we can pick essentially arbitrary DWARF to mean near arbitrary
things, and that'll essentially be a contract between Clang and debuggers
when we do so, so I'm inclined to be rather careful when making those
choices (because we'll eventually have to convince other debuggers to
implement those things, etc))


> If we need to perform hash lookups to get to the ID that we might as well
> look up the type by name in the module, because that’s also a hash table
> lookup. I don’t think a performance argument can be made for using IDs.
>

Having to hash the whole mangled name (let alone piecing it together from
the names in the scope chain, walking the DIE parent chain, etc) is going
to be more expensive than using the existing sig8.



>
>
> Why is it important that the IDs be resilient to changes in the module?
>
>
> Several reasons I can think of:
> - developers are used to being able to debug a binary with slightly
> out-of-date source code.
>

I'm confused - the debug info and the module are built together, and the
user's program is built from that.

You're trying to support the case where the user's binary is built but then
the module is rebuilt with a minor change? I think that's a fairly losing
battle & one I'd be pretty concerned about attempting to support.


> - if we use IDs we need to make the dwoid==modulehash check mandatory or
> we resolve random types, but that means that even adding whitespace to a
> header file means that module debugging won’t work any more.
>

Yes, generall

Re: [PATCH] D12215: [UBSan] Add the ability to print more precise error kind in summary line.

[Alexey Samsonov via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL245897: [UBSan] Add the ability to print more precise error 
kind in summary line. (authored by samsonov).

Changed prior to commit:
  http://reviews.llvm.org/D12215?vs=32753&id=33019#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D12215

Files:
  compiler-rt/trunk/lib/ubsan/ubsan_checks.inc
  compiler-rt/trunk/lib/ubsan/ubsan_diag.cc
  compiler-rt/trunk/lib/ubsan/ubsan_diag.h
  compiler-rt/trunk/lib/ubsan/ubsan_flags.inc
  compiler-rt/trunk/lib/ubsan/ubsan_handlers.cc
  compiler-rt/trunk/lib/ubsan/ubsan_handlers_cxx.cc
  compiler-rt/trunk/test/ubsan/TestCases/Float/cast-overflow.cpp
  compiler-rt/trunk/test/ubsan/TestCases/Integer/summary.cpp
  compiler-rt/trunk/test/ubsan/TestCases/Misc/bool.cpp

Index: compiler-rt/trunk/test/ubsan/TestCases/Integer/summary.cpp
===
--- compiler-rt/trunk/test/ubsan/TestCases/Integer/summary.cpp
+++ compiler-rt/trunk/test/ubsan/TestCases/Integer/summary.cpp
@@ -1,10 +1,13 @@
-// RUN: %clangxx -fsanitize=integer %s -o %t && %t 2>&1 | FileCheck %s
+// RUN: %clangxx -fsanitize=integer %s -o %t
+// RUN: %t 2>&1 | FileCheck %s --check-prefix=CHECK-NOTYPE
+// RUN: env UBSAN_OPTIONS=report_error_type=1 %t 2>&1 | FileCheck %s --check-prefix=CHECK-TYPE
 // REQUIRES: ubsan-asan
 
 #include 
 
 int main() {
   (void)(uint64_t(1000ull) + uint64_t(900ull));
-  // CHECK: SUMMARY: AddressSanitizer: undefined-behavior {{.*}}summary.cpp:[[@LINE-1]]:44
+  // CHECK-NOTYPE: SUMMARY: AddressSanitizer: undefined-behavior {{.*}}summary.cpp:[[@LINE-1]]:44
+  // CHECK-TYPE: SUMMARY: AddressSanitizer: unsigned-integer-overflow {{.*}}summary.cpp:[[@LINE-2]]:44
   return 0;
 }
Index: compiler-rt/trunk/test/ubsan/TestCases/Misc/bool.cpp
===
--- compiler-rt/trunk/test/ubsan/TestCases/Misc/bool.cpp
+++ compiler-rt/trunk/test/ubsan/TestCases/Misc/bool.cpp
@@ -1,10 +1,13 @@
-// RUN: %clangxx -fsanitize=bool %s -O3 -o %t && not %run %t 2>&1 | FileCheck %s
+// RUN: %clangxx -fsanitize=bool %s -O3 -o %t
+// RUN: not %run %t 2>&1 | FileCheck %s
+// RUN: env UBSAN_OPTIONS=print_summary=1:report_error_type=1 not %run %t 2>&1 | FileCheck %s --check-prefix=SUMMARY
 
 unsigned char NotABool = 123;
 
 int main(int argc, char **argv) {
   bool *p = (bool*)&NotABool;
 
-  // CHECK: bool.cpp:9:10: runtime error: load of value 123, which is not a valid value for type 'bool'
+  // CHECK: bool.cpp:[[@LINE+1]]:10: runtime error: load of value 123, which is not a valid value for type 'bool'
   return *p;
+  // SUMMARY: SUMMARY: {{.*}}Sanitizer: invalid-bool-load {{.*}}bool.cpp:[[@LINE-1]]
 }
Index: compiler-rt/trunk/test/ubsan/TestCases/Float/cast-overflow.cpp
===
--- compiler-rt/trunk/test/ubsan/TestCases/Float/cast-overflow.cpp
+++ compiler-rt/trunk/test/ubsan/TestCases/Float/cast-overflow.cpp
@@ -1,6 +1,6 @@
 // RUN: %clangxx -fsanitize=float-cast-overflow %s -o %t
 // RUN: %run %t _
-// RUN: env UBSAN_OPTIONS=print_summary=1 %run %t 0 2>&1 | FileCheck %s --check-prefix=CHECK-0
+// RUN: env UBSAN_OPTIONS=print_summary=1:report_error_type=1 %run %t 0 2>&1 | FileCheck %s --check-prefix=CHECK-0
 // RUN: %run %t 1 2>&1 | FileCheck %s --check-prefix=CHECK-1
 // RUN: %run %t 2 2>&1 | FileCheck %s --check-prefix=CHECK-2
 // RUN: %run %t 3 2>&1 | FileCheck %s --check-prefix=CHECK-3
@@ -88,7 +88,7 @@
 // successfully round-trip, depending on the rounding mode.
 // CHECK-0: {{.*}}cast-overflow.cpp:[[@LINE+1]]:27: runtime error: value 2.14748{{.*}} is outside the range of representable values of type 'int'
 static int test_int = MaxFloatRepresentableAsInt + 0x80;
-// CHECK-0: SUMMARY: {{.*}}Sanitizer: undefined-behavior {{.*}}cast-overflow.cpp:[[@LINE-1]]
+// CHECK-0: SUMMARY: {{.*}}Sanitizer: float-cast-overflow {{.*}}cast-overflow.cpp:[[@LINE-1]]
 return 0;
 }
   case '1': {
Index: compiler-rt/trunk/lib/ubsan/ubsan_checks.inc
===
--- compiler-rt/trunk/lib/ubsan/ubsan_checks.inc
+++ compiler-rt/trunk/lib/ubsan/ubsan_checks.inc
@@ -0,0 +1,53 @@
+//===-- ubsan_checks.inc *- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+// List of checks handled by UBSan runtime.
+//
+//===--===//
+#ifndef UBSAN_CHECK
+# error "Define UBSAN_CHECK prior to including this file!"
+#endif
+
+// UBSAN_CHECK(Name, SummaryKind, FlagName)
+// SummaryKind and FlagName should be string literals.
+
+UBSAN_CHECK(Ge

Re: [PATCH] D11737: Add -linker (and -linker=) alias for -fuse-ld=

[Eric Christopher via cfe-commits]

echristo added inline comments.


Comment at: include/clang/Driver/Options.td:1853-1854
@@ -1853,1 +1852,4 @@
+def fuse_ld_EQ : Joined<["-"], "fuse-ld=">, HelpText<"Use linker ">, 
Group;
+def linker : Separate<["-"], "linker">, Alias, 
MetaVarName<"">;
+def linker_EQ : Joined<["-"], "linker=">, Alias;
 

Any reason to have both options?


http://reviews.llvm.org/D11737



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

Re: [PATCH] D11857: CFI: Introduce -fsanitize=cfi-icall flag.

[Peter Collingbourne via cfe-commits]

pcc updated this revision to Diff 33020.
pcc added a comment.

- Address comment


http://reviews.llvm.org/D11857

Files:
  docs/ControlFlowIntegrity.rst
  include/clang/AST/Mangle.h
  include/clang/Basic/Sanitizers.def
  lib/AST/ItaniumMangle.cpp
  lib/AST/MicrosoftMangle.cpp
  lib/CodeGen/CGClass.cpp
  lib/CodeGen/CGExpr.cpp
  lib/CodeGen/CGVTables.cpp
  lib/CodeGen/CodeGenModule.cpp
  lib/Driver/ToolChain.cpp
  lib/Driver/ToolChains.cpp
  test/CodeGen/cfi-icall.c
  test/CodeGenCXX/cfi-cast.cpp
  test/CodeGenCXX/cfi-icall.cpp
  test/CodeGenCXX/cfi-ms-rtti.cpp
  test/CodeGenCXX/cfi-nvcall.cpp
  test/CodeGenCXX/cfi-vcall.cpp
  test/Driver/fsanitize.c

Index: test/Driver/fsanitize.c
===
--- test/Driver/fsanitize.c
+++ test/Driver/fsanitize.c
@@ -234,15 +234,18 @@
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=cfi-unrelated-cast -flto -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CFI-UCAST
 // RUN: %clang -target x86_64-linux-gnu -flto -fsanitize=cfi-nvcall -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CFI-NVCALL
 // RUN: %clang -target x86_64-linux-gnu -flto -fsanitize=cfi-vcall -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CFI-VCALL
-// CHECK-CFI: -emit-llvm-bc{{.*}}-fsanitize=cfi-derived-cast,cfi-unrelated-cast,cfi-nvcall,cfi-vcall
+// CHECK-CFI: -emit-llvm-bc{{.*}}-fsanitize=cfi-derived-cast,cfi-icall,cfi-unrelated-cast,cfi-nvcall,cfi-vcall
 // CHECK-CFI-DCAST: -emit-llvm-bc{{.*}}-fsanitize=cfi-derived-cast
 // CHECK-CFI-UCAST: -emit-llvm-bc{{.*}}-fsanitize=cfi-unrelated-cast
 // CHECK-CFI-NVCALL: -emit-llvm-bc{{.*}}-fsanitize=cfi-nvcall
 // CHECK-CFI-VCALL: -emit-llvm-bc{{.*}}-fsanitize=cfi-vcall
 
 // RUN: %clang -target x86_64-linux-gnu -flto -fsanitize=cfi-derived-cast -fno-lto -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CFI-NOLTO
 // CHECK-CFI-NOLTO: '-fsanitize=cfi-derived-cast' only allowed with '-flto'
 
+// RUN: %clang -target mips-unknown-linux -fsanitize=cfi-icall %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CFI-ICALL-MIPS
+// CHECK-CFI-ICALL-MIPS: unsupported option '-fsanitize=cfi-icall' for target 'mips-unknown-linux'
+
 // RUN: %clang -target x86_64-linux-gnu -fsanitize-trap=address -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-ASAN-TRAP
 // CHECK-ASAN-TRAP: error: unsupported argument 'address' to option '-fsanitize-trap'
 
Index: test/CodeGenCXX/cfi-vcall.cpp
===
--- test/CodeGenCXX/cfi-vcall.cpp
+++ test/CodeGenCXX/cfi-vcall.cpp
@@ -60,8 +60,8 @@
 // ITANIUM: define void @_Z2afP1A
 // MS: define void @"\01?af@@YAXPEAUA@@@Z"
 void af(A *a) {
-  // ITANIUM: [[P:%[^ ]*]] = call i1 @llvm.bitset.test(i8* [[VT:%[^ ]*]], metadata !"1A")
-  // MS: [[P:%[^ ]*]] = call i1 @llvm.bitset.test(i8* [[VT:%[^ ]*]], metadata !"A@@")
+  // ITANIUM: [[P:%[^ ]*]] = call i1 @llvm.bitset.test(i8* [[VT:%[^ ]*]], metadata !"_ZTS1A")
+  // MS: [[P:%[^ ]*]] = call i1 @llvm.bitset.test(i8* [[VT:%[^ ]*]], metadata !"?AUA@@")
   // CHECK-NEXT: br i1 [[P]], label %[[CONTBB:[^ ,]*]], label %[[TRAPBB:[^ ,]*]]
   // CHECK-NEXT: {{^$}}
 
@@ -82,24 +82,24 @@
 // ITANIUM: define internal void @_Z3df1PN12_GLOBAL__N_11DE
 // MS: define internal void @"\01?df1@@YAXPEAUD@?A@@@Z"
 void df1(D *d) {
-  // ITANIUM: {{%[^ ]*}} = call i1 @llvm.bitset.test(i8* {{%[^ ]*}}, metadata !"[{{.*}}cfi-vcall.cpp]N12_GLOBAL__N_11DE")
-  // MS: {{%[^ ]*}} = call i1 @llvm.bitset.test(i8* {{%[^ ]*}}, metadata !"A@@")
+  // ITANIUM: {{%[^ ]*}} = call i1 @llvm.bitset.test(i8* {{%[^ ]*}}, metadata ![[DTYPE:[0-9]+]])
+  // MS: {{%[^ ]*}} = call i1 @llvm.bitset.test(i8* {{%[^ ]*}}, metadata !"?AUA@@")
   d->f();
 }
 
 // ITANIUM: define internal void @_Z3dg1PN12_GLOBAL__N_11DE
 // MS: define internal void @"\01?dg1@@YAXPEAUD@?A@@@Z"
 void dg1(D *d) {
-  // ITANIUM: {{%[^ ]*}} = call i1 @llvm.bitset.test(i8* {{%[^ ]*}}, metadata !"1B")
-  // MS: {{%[^ ]*}} = call i1 @llvm.bitset.test(i8* {{%[^ ]*}}, metadata !"B@@")
+  // ITANIUM: {{%[^ ]*}} = call i1 @llvm.bitset.test(i8* {{%[^ ]*}}, metadata !"_ZTS1B")
+  // MS: {{%[^ ]*}} = call i1 @llvm.bitset.test(i8* {{%[^ ]*}}, metadata !"?AUB@@")
   d->g();
 }
 
 // ITANIUM: define internal void @_Z3dh1PN12_GLOBAL__N_11DE
 // MS: define internal void @"\01?dh1@@YAXPEAUD@?A@@@Z"
 void dh1(D *d) {
-  // ITANIUM: {{%[^ ]*}} = call i1 @llvm.bitset.test(i8* {{%[^ ]*}}, metadata !"[{{.*}}cfi-vcall.cpp]N12_GLOBAL__N_11DE")
-  // MS: {{%[^ ]*}} = call i1 @llvm.bitset.test(i8* {{%[^ ]*}}, metadata !"[{{.*}}cfi-vcall.cpp]D@?A@@")
+  // ITANIUM: {{%[^ ]*}} = call i1 @llvm.bitset.test(i8* {{%[^ ]*}}, metadata ![[DTYPE]])
+  // MS: {{%[^ ]*}} = call i1 @llvm.bitset.test(i8* {{%[^ ]*}}, metadata ![[DTYPE:[0-9]+]])
   d->h();
 }
 
@@ -150,8 +150,8 @@
 // ITANIUM: define void @_ZN5test21fEPNS_1DE
 // MS: define void @"\01?f@test2@@YAXPEAUD@1@@Z"
 void f(D *d) {
-  // ITANIUM: {{%[^ ]*}} = call i1 @llvm.bitset.test(i8* {{%[^ ]*}}, metadata !"N5test21DE")
-  // M

Re: [PATCH] D11857: CFI: Introduce -fsanitize=cfi-icall flag.

[Peter Collingbourne via cfe-commits]

pcc added inline comments.


Comment at: docs/ControlFlowIntegrity.rst:149
@@ +148,3 @@
+shared library boundaries are handled as if the callee was not compiled with
+``-fsanitize=cfi-icall``.
+

kcc wrote:
> mention that LTO is require explicitly?
Done above.


http://reviews.llvm.org/D11857



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

r245901 - [ARM NEON] Add missing AArch64 vget tests.

[Ahmed Bougacha via cfe-commits]

Author: ab
Date: Mon Aug 24 18:34:25 2015
New Revision: 245901

URL: http://llvm.org/viewvc/llvm-project?rev=245901&view=rev
Log:
[ARM NEON] Add missing AArch64 vget tests.

Added:
cfe/trunk/test/CodeGen/aarch64-neon-vget.c
  - copied, changed from r245893, cfe/trunk/test/CodeGen/arm64_vget.c
Removed:
cfe/trunk/test/CodeGen/arm64_vget.c

Copied: cfe/trunk/test/CodeGen/aarch64-neon-vget.c (from r245893, 
cfe/trunk/test/CodeGen/arm64_vget.c)
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/aarch64-neon-vget.c?p2=cfe/trunk/test/CodeGen/aarch64-neon-vget.c&p1=cfe/trunk/test/CodeGen/arm64_vget.c&r1=245893&r2=245901&rev=245901&view=diff
==
--- cfe/trunk/test/CodeGen/arm64_vget.c (original)
+++ cfe/trunk/test/CodeGen/aarch64-neon-vget.c Mon Aug 24 18:34:25 2015
@@ -1,13 +1,348 @@
-// RUN: %clang_cc1 -O1 -triple arm64-apple-ios7 -target-feature +neon 
-ffreestanding -S -o - -emit-llvm %s | FileCheck %s
-// Test ARM64 SIMD vget intrinsics
+// REQUIRES: aarch64-registered-target
+// RUN: %clang_cc1 -triple arm64-apple-darwin -target-feature +neon \
+// RUN:   -ffp-contract=fast -S -O3 -o - %s | FileCheck %s
 
 #include 
 
-float64_t test_vget_lane_f64(float64x1_t a1) {
-  // CHECK: test_vget_lane_f64
-  // why isn't 1 allowed as second argument?
-  return vget_lane_f64(a1, 0);
-  // CHECK: extractelement {{.*}} i32 0
-  // CHECK-NEXT: ret
+uint8_t test_vget_lane_u8(uint8x8_t a) {
+  // CHECK-LABEL: test_vget_lane_u8:
+  // CHECK-NEXT:  umov.b w0, v0[7]
+  // CHECK-NEXT:  ret
+  return vget_lane_u8(a, 7);
 }
 
+uint16_t test_vget_lane_u16(uint16x4_t a) {
+  // CHECK-LABEL: test_vget_lane_u16:
+  // CHECK-NEXT:  umov.h w0, v0[3]
+  // CHECK-NEXT:  ret
+  return vget_lane_u16(a, 3);
+}
+
+uint32_t test_vget_lane_u32(uint32x2_t a) {
+  // CHECK-LABEL: test_vget_lane_u32:
+  // CHECK-NEXT:  mov.s  w0, v0[1]
+  // CHECK-NEXT:  ret
+  return vget_lane_u32(a, 1);
+}
+
+int8_t test_vget_lane_s8(int8x8_t a) {
+  // CHECK-LABEL: test_vget_lane_s8:
+  // CHECK-NEXT:  umov.b w0, v0[7]
+  // CHECK-NEXT:  ret
+  return vget_lane_s8(a, 7);
+}
+
+int16_t test_vget_lane_s16(int16x4_t a) {
+  // CHECK-LABEL: test_vget_lane_s16:
+  // CHECK-NEXT:  umov.h w0, v0[3]
+  // CHECK-NEXT:  ret
+  return vget_lane_s16(a, 3);
+}
+
+int32_t test_vget_lane_s32(int32x2_t a) {
+  // CHECK-LABEL: test_vget_lane_s32:
+  // CHECK-NEXT:  mov.s  w0, v0[1]
+  // CHECK-NEXT:  ret
+  return vget_lane_s32(a, 1);
+}
+
+poly8_t test_vget_lane_p8(poly8x8_t a) {
+  // CHECK-LABEL: test_vget_lane_p8:
+  // CHECK-NEXT:  umov.b w0, v0[7]
+  // CHECK-NEXT:  ret
+  return vget_lane_p8(a, 7);
+}
+
+poly16_t test_vget_lane_p16(poly16x4_t a) {
+  // CHECK-LABEL: test_vget_lane_p16:
+  // CHECK-NEXT:  umov.h w0, v0[3]
+  // CHECK-NEXT:  ret
+  return vget_lane_p16(a, 3);
+}
+
+float32_t test_vget_lane_f32(float32x2_t a) {
+  // CHECK-LABEL: test_vget_lane_f32:
+  // CHECK-NEXT:  mov s0, v0[1]
+  // CHECK-NEXT:  ret
+  return vget_lane_f32(a, 1);
+}
+
+float32_t test_vget_lane_f16(float16x4_t a) {
+  // CHECK-LABEL: test_vget_lane_f16:
+  // CHECK-NEXT:  umov.h w8, v0[1]
+  // CHECK-NEXT:  fmov s0, w8
+  // CHECK-NEXT:  fcvt s0, h0
+  // CHECK-NEXT:  ret
+  return vget_lane_f16(a, 1);
+}
+
+uint8_t test_vgetq_lane_u8(uint8x16_t a) {
+  // CHECK-LABEL: test_vgetq_lane_u8:
+  // CHECK-NEXT:  umov.b w0, v0[15]
+  // CHECK-NEXT:  ret
+  return vgetq_lane_u8(a, 15);
+}
+
+uint16_t test_vgetq_lane_u16(uint16x8_t a) {
+  // CHECK-LABEL: test_vgetq_lane_u16:
+  // CHECK-NEXT:  umov.h w0, v0[7]
+  // CHECK-NEXT:  ret
+  return vgetq_lane_u16(a, 7);
+}
+
+uint32_t test_vgetq_lane_u32(uint32x4_t a) {
+  // CHECK-LABEL: test_vgetq_lane_u32:
+  // CHECK-NEXT:  mov.s  w0, v0[3]
+  // CHECK-NEXT:  ret
+  return vgetq_lane_u32(a, 3);
+}
+
+int8_t test_vgetq_lane_s8(int8x16_t a) {
+  // CHECK-LABEL: test_vgetq_lane_s8:
+  // CHECK-NEXT:  umov.b w0, v0[15]
+  // CHECK-NEXT:  ret
+  return vgetq_lane_s8(a, 15);
+}
+
+int16_t test_vgetq_lane_s16(int16x8_t a) {
+  // CHECK-LABEL: test_vgetq_lane_s16:
+  // CHECK-NEXT:  umov.h w0, v0[7]
+  // CHECK-NEXT:  ret
+  return vgetq_lane_s16(a, 7);
+}
+
+int32_t test_vgetq_lane_s32(int32x4_t a) {
+  // CHECK-LABEL: test_vgetq_lane_s32:
+  // CHECK-NEXT:  mov.s  w0, v0[3]
+  // CHECK-NEXT:  ret
+  return vgetq_lane_s32(a, 3);
+}
+
+poly8_t test_vgetq_lane_p8(poly8x16_t a) {
+  // CHECK-LABEL: test_vgetq_lane_p8:
+  // CHECK-NEXT:  umov.b w0, v0[15]
+  // CHECK-NEXT:  ret
+  return vgetq_lane_p8(a, 15);
+}
+
+poly16_t test_vgetq_lane_p16(poly16x8_t a) {
+  // CHECK-LABEL: test_vgetq_lane_p16:
+  // CHECK-NEXT:  umov.h w0, v0[7]
+  // CHECK-NEXT:  ret
+  return vgetq_lane_p16(a, 7);
+}
+
+float32_t test_vgetq_lane_f32(float32x4_t a) {
+  // CHECK-LABEL: test_vgetq_lane_f32:
+  // CHECK-NEXT:  mov s0, v0[3]
+  // CHECK-NEXT:  ret
+  return vgetq_lane_f32(a, 3);
+}
+
+float32_t test_vgetq_lane_f16(float16x8_t a) {
+  // CHECK-LABEL: test_vgetq_lane_f16:

Re: [PATCH] D12038: CodeGen: Introduce CodeGenModule::CreateMetadataIdentifierForType.

[Peter Collingbourne via cfe-commits]

pcc added a comment.

@rsmith: Ping.


http://reviews.llvm.org/D12038



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

r245904 - [ARM NEON] Replace redundant code with a new GetFloatNeonType. NFC.

[Ahmed Bougacha via cfe-commits]

Author: ab
Date: Mon Aug 24 18:41:31 2015
New Revision: 245904

URL: http://llvm.org/viewvc/llvm-project?rev=245904&view=rev
Log:
[ARM NEON] Replace redundant code with a new GetFloatNeonType. NFC.

Modified:
cfe/trunk/lib/CodeGen/CGBuiltin.cpp

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=245904&r1=245903&r2=245904&view=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Mon Aug 24 18:41:31 2015
@@ -1917,6 +1917,19 @@ static llvm::VectorType *GetNeonType(Cod
   llvm_unreachable("Unknown vector element type!");
 }
 
+static llvm::VectorType *GetFloatNeonType(CodeGenFunction *CGF,
+  NeonTypeFlags IntTypeFlags) {
+  int IsQuad = IntTypeFlags.isQuad();
+  switch (IntTypeFlags.getEltType()) {
+  case NeonTypeFlags::Int32:
+return llvm::VectorType::get(CGF->FloatTy, (2 << IsQuad));
+  case NeonTypeFlags::Int64:
+return llvm::VectorType::get(CGF->DoubleTy, (1 << IsQuad));
+  default:
+llvm_unreachable("Type can't be converted to floating-point!");
+  }
+}
+
 Value *CodeGenFunction::EmitNeonSplat(Value *V, Constant *C) {
   unsigned nElts = cast(V->getType())->getNumElements();
   Value* SV = llvm::ConstantVector::getSplat(nElts, C);
@@ -2817,13 +2830,7 @@ Value *CodeGenFunction::EmitCommonNeonBu
   case NEON::BI__builtin_neon_vcvt_n_f64_v:
   case NEON::BI__builtin_neon_vcvtq_n_f32_v:
   case NEON::BI__builtin_neon_vcvtq_n_f64_v: {
-bool Double =
-  (cast(VTy->getElementType())->getBitWidth() == 64);
-llvm::Type *FloatTy =
-GetNeonType(this, NeonTypeFlags(Double ? NeonTypeFlags::Float64
-   : NeonTypeFlags::Float32,
-false, Quad));
-llvm::Type *Tys[2] = { FloatTy, Ty };
+llvm::Type *Tys[2] = { GetFloatNeonType(this, Type), Ty };
 Int = Usgn ? LLVMIntrinsic : AltLLVMIntrinsic;
 Function *F = CGM.getIntrinsic(Int, Tys);
 return EmitNeonCall(F, Ops, "vcvt_n");
@@ -2836,13 +2843,7 @@ Value *CodeGenFunction::EmitCommonNeonBu
   case NEON::BI__builtin_neon_vcvtq_n_u32_v:
   case NEON::BI__builtin_neon_vcvtq_n_s64_v:
   case NEON::BI__builtin_neon_vcvtq_n_u64_v: {
-bool Double =
-  (cast(VTy->getElementType())->getBitWidth() == 64);
-llvm::Type *FloatTy =
-GetNeonType(this, NeonTypeFlags(Double ? NeonTypeFlags::Float64
-   : NeonTypeFlags::Float32,
-false, Quad));
-llvm::Type *Tys[2] = { Ty, FloatTy };
+llvm::Type *Tys[2] = { Ty, GetFloatNeonType(this, Type) };
 Function *F = CGM.getIntrinsic(LLVMIntrinsic, Tys);
 return EmitNeonCall(F, Ops, "vcvt_n");
   }
@@ -2854,13 +2855,7 @@ Value *CodeGenFunction::EmitCommonNeonBu
   case NEON::BI__builtin_neon_vcvtq_u32_v:
   case NEON::BI__builtin_neon_vcvtq_s64_v:
   case NEON::BI__builtin_neon_vcvtq_u64_v: {
-bool Double =
-  (cast(VTy->getElementType())->getBitWidth() == 64);
-llvm::Type *FloatTy =
-GetNeonType(this, NeonTypeFlags(Double ? NeonTypeFlags::Float64
-   : NeonTypeFlags::Float32,
-false, Quad));
-Ops[0] = Builder.CreateBitCast(Ops[0], FloatTy);
+Ops[0] = Builder.CreateBitCast(Ops[0], GetFloatNeonType(this, Type));
 return Usgn ? Builder.CreateFPToUI(Ops[0], Ty, "vcvt")
 : Builder.CreateFPToSI(Ops[0], Ty, "vcvt");
   }
@@ -2896,13 +2891,7 @@ Value *CodeGenFunction::EmitCommonNeonBu
   case NEON::BI__builtin_neon_vcvtmq_s64_v:
   case NEON::BI__builtin_neon_vcvtmq_u32_v:
   case NEON::BI__builtin_neon_vcvtmq_u64_v: {
-bool Double =
-  (cast(VTy->getElementType())->getBitWidth() == 64);
-llvm::Type *InTy =
-  GetNeonType(this,
-  NeonTypeFlags(Double ? NeonTypeFlags::Float64
-: NeonTypeFlags::Float32, false, Quad));
-llvm::Type *Tys[2] = { Ty, InTy };
+llvm::Type *Tys[2] = { Ty, GetFloatNeonType(this, Type) };
 return EmitNeonCall(CGM.getIntrinsic(LLVMIntrinsic, Tys), Ops, NameHint);
   }
   case NEON::BI__builtin_neon_vext_v:
@@ -5174,13 +5163,7 @@ Value *CodeGenFunction::EmitAArch64Built
   case NEON::BI__builtin_neon_vcvtq_u32_v:
   case NEON::BI__builtin_neon_vcvtq_s64_v:
   case NEON::BI__builtin_neon_vcvtq_u64_v: {
-bool Double =
-  (cast(VTy->getElementType())->getBitWidth() == 64);
-llvm::Type *InTy =
-  GetNeonType(this,
-  NeonTypeFlags(Double ? NeonTypeFlags::Float64
-: NeonTypeFlags::Float32, false, quad));
-Ops[0] = Builder.CreateBitCast(Ops[0], InTy);
+Ops[0] = Builder.CreateBitCast(Ops[0], GetFloatNeonType(this, Type));
 if (usgn)
   return Builder.CreateFPToUI(Ops[0], Ty

Re: [PATCH] D12301: [PATCH] New checker for UB in handler of a function-try-block

[Richard Smith via cfe-commits]

On Mon, Aug 24, 2015 at 3:36 PM, Aaron Ballman 
wrote:

> On Mon, Aug 24, 2015 at 6:29 PM, Richard Smith 
> wrote:
> > On Mon, Aug 24, 2015 at 3:23 PM, Aaron Ballman 
> > wrote:
> >>
> >> aaron.ballman created this revision.
> >> aaron.ballman added reviewers: alexfh, rsmith.
> >> aaron.ballman added a subscriber: cfe-commits.
> >>
> >> Per [except.handle]p10, the handler for a constructor or destructor
> >> function-try-block cannot refer to a non-static member of the object
> under
> >> construction. This patch adds a new clang-tidy check that warns the user
> >> when they've hit this undefined behavior.
> >>
> >> Due to how infrequent function-try-blocks appear on constructors and
> >> destructors in the wild compared to how often member expressions are
> >> encountered, I felt this was more appropriate as a clang-tidy check
> than as
> >> a semantic warning. I was concerned with efficiency of checking whether
> an
> >> arbitrary member expression was referring to the object under
> >> construction/destruction within the function-try-block catch handler
> scope.
> >
> >
> > Seems like this would be very cheap to check in the case where the object
> > expression is an implicit or explicit CXXThisExpr. It'd be good to have a
> > frontend warning for that case.
>
> Are you thinking the check would likely in BuildMemberReferenceExpr()
> and I would just have to look at the current scope to determine
> whether it's a function-try-block catch handler?


Yes, somewhere around there. You might need to wire a Scope* though a
couple of layers though.


> When I looked into
> doing a frontend warning for this, I seemed to struggle with figuring
> out specifically that I was in the catch handler of a
> function-try-block of a constructor or destructor.


Looks like there's no better method than walking up the Scope stack until
you hit a scope with the FnTryCatchScope flag (or leave the function),
currently.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r245906 - [ARM NEON] Use CGF cached Types instead of llvm::Type::get. NFC.

[Ahmed Bougacha via cfe-commits]

Author: ab
Date: Mon Aug 24 18:47:29 2015
New Revision: 245906

URL: http://llvm.org/viewvc/llvm-project?rev=245906&view=rev
Log:
[ARM NEON] Use CGF cached Types instead of llvm::Type::get. NFC.

Modified:
cfe/trunk/lib/CodeGen/CGBuiltin.cpp

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=245906&r1=245905&r2=245906&view=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Mon Aug 24 18:47:29 2015
@@ -4472,7 +4472,7 @@ Value *CodeGenFunction::EmitAArch64Built
   }
   case NEON::BI__builtin_neon_vpaddd_f64: {
 llvm::Type *Ty =
-  llvm::VectorType::get(llvm::Type::getDoubleTy(getLLVMContext()), 2);
+  llvm::VectorType::get(DoubleTy, 2);
 Value *Vec = EmitScalarExpr(E->getArg(0));
 // The vector is v2f64, so make sure it's bitcast to that.
 Vec = Builder.CreateBitCast(Vec, Ty, "v2f64");
@@ -4485,7 +4485,7 @@ Value *CodeGenFunction::EmitAArch64Built
   }
   case NEON::BI__builtin_neon_vpadds_f32: {
 llvm::Type *Ty =
-  llvm::VectorType::get(llvm::Type::getFloatTy(getLLVMContext()), 2);
+  llvm::VectorType::get(FloatTy, 2);
 Value *Vec = EmitScalarExpr(E->getArg(0));
 // The vector is v2f32, so make sure it's bitcast to that.
 Vec = Builder.CreateBitCast(Vec, Ty, "v2f32");
@@ -4640,7 +4640,7 @@ Value *CodeGenFunction::EmitAArch64Built
   case NEON::BI__builtin_neon_vsetq_lane_f64:
 // The vector type needs a cast for the v2f64 variant.
 Ops[1] = Builder.CreateBitCast(Ops[1],
-llvm::VectorType::get(llvm::Type::getDoubleTy(getLLVMContext()), 2));
+llvm::VectorType::get(DoubleTy, 2));
 Ops.push_back(EmitScalarExpr(E->getArg(2)));
 return Builder.CreateInsertElement(Ops[1], Ops[0], Ops[2], "vset_lane");
 
@@ -4671,7 +4671,7 @@ Value *CodeGenFunction::EmitAArch64Built
 "vget_lane");
   case NEON::BI__builtin_neon_vdups_lane_f32:
 Ops[0] = Builder.CreateBitCast(Ops[0],
-llvm::VectorType::get(llvm::Type::getFloatTy(getLLVMContext()), 2));
+llvm::VectorType::get(FloatTy, 2));
 return Builder.CreateExtractElement(Ops[0], EmitScalarExpr(E->getArg(1)),
 "vdups_lane");
   case NEON::BI__builtin_neon_vgetq_lane_i32:
@@ -4686,7 +4686,7 @@ Value *CodeGenFunction::EmitAArch64Built
 "vget_lane");
   case NEON::BI__builtin_neon_vdupd_lane_f64:
 Ops[0] = Builder.CreateBitCast(Ops[0],
-llvm::VectorType::get(llvm::Type::getDoubleTy(getLLVMContext()), 1));
+llvm::VectorType::get(DoubleTy, 1));
 return Builder.CreateExtractElement(Ops[0], EmitScalarExpr(E->getArg(1)),
 "vdupd_lane");
   case NEON::BI__builtin_neon_vgetq_lane_i64:
@@ -4696,24 +4696,24 @@ Value *CodeGenFunction::EmitAArch64Built
 "vgetq_lane");
   case NEON::BI__builtin_neon_vget_lane_f32:
 Ops[0] = Builder.CreateBitCast(Ops[0],
-llvm::VectorType::get(llvm::Type::getFloatTy(getLLVMContext()), 2));
+llvm::VectorType::get(FloatTy, 2));
 return Builder.CreateExtractElement(Ops[0], EmitScalarExpr(E->getArg(1)),
 "vget_lane");
   case NEON::BI__builtin_neon_vget_lane_f64:
 Ops[0] = Builder.CreateBitCast(Ops[0],
-llvm::VectorType::get(llvm::Type::getDoubleTy(getLLVMContext()), 1));
+llvm::VectorType::get(DoubleTy, 1));
 return Builder.CreateExtractElement(Ops[0], EmitScalarExpr(E->getArg(1)),
 "vget_lane");
   case NEON::BI__builtin_neon_vgetq_lane_f32:
   case NEON::BI__builtin_neon_vdups_laneq_f32:
 Ops[0] = Builder.CreateBitCast(Ops[0],
-llvm::VectorType::get(llvm::Type::getFloatTy(getLLVMContext()), 4));
+llvm::VectorType::get(FloatTy, 4));
 return Builder.CreateExtractElement(Ops[0], EmitScalarExpr(E->getArg(1)),
 "vgetq_lane");
   case NEON::BI__builtin_neon_vgetq_lane_f64:
   case NEON::BI__builtin_neon_vdupd_laneq_f64:
 Ops[0] = Builder.CreateBitCast(Ops[0],
-llvm::VectorType::get(llvm::Type::getDoubleTy(getLLVMContext()), 2));
+llvm::VectorType::get(DoubleTy, 2));
 return Builder.CreateExtractElement(Ops[0], EmitScalarExpr(E->getArg(1)),
 "vgetq_lane");
   case NEON::BI__builtin_neon_vaddd_s64:
@@ -5052,15 +5052,13 @@ Value *CodeGenFunction::EmitAArch64Built
 Int = Intrinsic::aarch64_neon_fmaxnm;
 return EmitNeonCall(CGM.getIntrinsic(Int, Ty), Ops, "vmaxnm");
   case NEON::BI__builtin_neon_vrecpss_f32: {
-llvm::Type *f32Type = llvm::Type::getFloatTy(getLLVMContext());
 Ops.push_back(EmitScalarExpr(E->getArg(1)));
-return EmitNeonCall(CGM.getIntrinsic(Intrinsic::aarch64_ne

r245908 - Use GetLinkerPath utility function to find linker for NaCl toolchain

[Derek Schuff via cfe-commits]

Author: dschuff
Date: Mon Aug 24 18:53:25 2015
New Revision: 245908

URL: http://llvm.org/viewvc/llvm-project?rev=245908&view=rev
Log:
Use GetLinkerPath utility function to find linker for NaCl toolchain

Summary:
This is more consistent with other targets and also makes the -fuse-ld
flag work.

Reviewers: jvoung

Subscribers: llvm-commits

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

Modified:
cfe/trunk/lib/Driver/ToolChains.cpp

Modified: cfe/trunk/lib/Driver/ToolChains.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp?rev=245908&r1=245907&r2=245908&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains.cpp Mon Aug 24 18:53:25 2015
@@ -2359,7 +2359,7 @@ NaClToolChain::NaClToolChain(const Drive
   }
 
   // Use provided linker, not system linker
-  Linker = GetProgramPath("ld");
+  Linker = GetLinkerPath();
   NaClArmMacrosPath = GetFilePath("nacl-arm-macros.s");
 }
 


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

r245909 - broken test. uses system ld.gold

[Derek Schuff via cfe-commits]

Author: dschuff
Date: Mon Aug 24 18:53:28 2015
New Revision: 245909

URL: http://llvm.org/viewvc/llvm-project?rev=245909&view=rev
Log:
broken test. uses system ld.gold

Added:
cfe/trunk/test/Driver/Inputs/basic_nacl_tree/
cfe/trunk/test/Driver/Inputs/basic_nacl_tree/bin/
cfe/trunk/test/Driver/Inputs/basic_nacl_tree/bin/ld
cfe/trunk/test/Driver/Inputs/basic_nacl_tree/bin/ld.gold
Modified:
cfe/trunk/test/Driver/fuse-ld.c

Added: cfe/trunk/test/Driver/Inputs/basic_nacl_tree/bin/ld
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/basic_nacl_tree/bin/ld?rev=245909&view=auto
==
(empty)

Added: cfe/trunk/test/Driver/Inputs/basic_nacl_tree/bin/ld.gold
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/basic_nacl_tree/bin/ld.gold?rev=245909&view=auto
==
(empty)

Modified: cfe/trunk/test/Driver/fuse-ld.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/fuse-ld.c?rev=245909&r1=245908&r2=245909&view=diff
==
--- cfe/trunk/test/Driver/fuse-ld.c (original)
+++ cfe/trunk/test/Driver/fuse-ld.c Mon Aug 24 18:53:28 2015
@@ -61,3 +61,9 @@
 // RUN: -gcc-toolchain %S/Inputs/basic_android_tree 2>&1 \
 // RUN:   | FileCheck %s -check-prefix=CHECK-ANDROID-ARM-GOLD-TC
 // CHECK-ANDROID-ARM-GOLD-TC: 
Inputs/basic_android_tree/lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin{{/|\\+}}ld.gold
+
+// RUN: %clang %s -### -fuse-ld=gold \
+// RUN: -target i686-unknown-nacl \
+// RUN: -B%S/Inputs/basic_nacl_tree/bin 2>&1 \
+// RUN:   | FileCheck %s -check-prefix=CHECK-NACL-GOLD-TC
+// CHECK-NACL-GOLD-TC: ld.gold


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

r245910 - Revert "broken test. uses system ld.gold"

[Derek Schuff via cfe-commits]

Author: dschuff
Date: Mon Aug 24 18:53:30 2015
New Revision: 245910

URL: http://llvm.org/viewvc/llvm-project?rev=245910&view=rev
Log:
Revert "broken test. uses system ld.gold"
We should check in a basic_nacl_tree that works and also fix --sysroot

Removed:
cfe/trunk/test/Driver/Inputs/basic_nacl_tree/bin/ld
cfe/trunk/test/Driver/Inputs/basic_nacl_tree/bin/ld.gold
Modified:
cfe/trunk/test/Driver/fuse-ld.c

Removed: cfe/trunk/test/Driver/Inputs/basic_nacl_tree/bin/ld
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/basic_nacl_tree/bin/ld?rev=245909&view=auto
==
(empty)

Removed: cfe/trunk/test/Driver/Inputs/basic_nacl_tree/bin/ld.gold
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/basic_nacl_tree/bin/ld.gold?rev=245909&view=auto
==
(empty)

Modified: cfe/trunk/test/Driver/fuse-ld.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/fuse-ld.c?rev=245910&r1=245909&r2=245910&view=diff
==
--- cfe/trunk/test/Driver/fuse-ld.c (original)
+++ cfe/trunk/test/Driver/fuse-ld.c Mon Aug 24 18:53:30 2015
@@ -61,9 +61,3 @@
 // RUN: -gcc-toolchain %S/Inputs/basic_android_tree 2>&1 \
 // RUN:   | FileCheck %s -check-prefix=CHECK-ANDROID-ARM-GOLD-TC
 // CHECK-ANDROID-ARM-GOLD-TC: 
Inputs/basic_android_tree/lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin{{/|\\+}}ld.gold
-
-// RUN: %clang %s -### -fuse-ld=gold \
-// RUN: -target i686-unknown-nacl \
-// RUN: -B%S/Inputs/basic_nacl_tree/bin 2>&1 \
-// RUN:   | FileCheck %s -check-prefix=CHECK-NACL-GOLD-TC
-// CHECK-NACL-GOLD-TC: ld.gold


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

Re: [PATCH] Have clang list the imported modules in the debug info

[Adrian Prantl via cfe-commits]

> On Aug 24, 2015, at 4:17 PM, David Blaikie  wrote:
> 
> 
> 
> On Mon, Aug 24, 2015 at 3:34 PM, Adrian Prantl  > wrote:
> 
>> On Aug 24, 2015, at 2:01 PM, David Blaikie > > wrote:
>> 
>> 
>> 
>> On Mon, Aug 24, 2015 at 1:23 PM, Adrian Prantl > > wrote:
>> 
>>> On Aug 19, 2015, at 1:20 PM, David Blaikie >> > wrote:
>>> 
>>> 
>>> 
>>> On Mon, Aug 10, 2015 at 5:00 PM, Adrian Prantl >> > wrote:
>>> 
 On Jul 24, 2015, at 12:33 PM, David Blaikie >>> > wrote:
 
 *reads back through the thread*
>>> 
>>> appreciated, it’s long :-)
>>> 
 So what I originally had in mind about a year ago when we discussed this, 
 was that the module data could have an extra table from type hash to 
 whatever useful internal representation to find the type in the PCM.
>>> 
>>> It turned out that the most useful internal type representation to find a 
>>> type in a PCM is the type’s DeclContext+Name; this is how (surprise!) clang 
>>> looks up types in a PCM and the format is supposed to be fast for these 
>>> kind of lookups.
>>> 
>>> Still, I would imagine there would be some kind of direct access (the 
>>> offset in the file, or somesuch) rather than actually having to go through 
>>> hashtables, etc. No? (how does one module refer to types in another module? 
>>> Really by name?)
>> 
>> Entities in PCMs have local integer IDs (just consecutive numbers) that are 
>> used to encode references inside a record on disk. An external reference 
>> gets a global ID which is the local ID + the ID of the other module. This 
>> numbering scheme of course only makes sense within a module (and perhaps 
>> also within a chained PCH). Every (local and global) ID maps to an entry in 
>> the PCM’s identifier table. When deserializing, the in-memory global 
>> IdentifierTable is built and each module gets a map that remaps its internal 
>> global IDs to the “global” global IDs.
>> 
>> For debug info these IDs are not very useful, because they are not resilient 
>> against even the smallest additive change to the module. We could add an 
>> integer attribute with the module-internal entity ID to the forward 
>> declaration that the debugger can use if the module hash and the CU’s dwoid 
>> are matching, but I’m not yet convinced that it would be worth it. Adding it 
>> to the definition of the type in the module dwarf seems not worth it because 
>> then we already have to do a similarly expensive lookup to find the module 
>> containing the definition.
>> 
>> It seems that ideally a module-aware debugger would not consult the DWARF at 
>> all, so I wouldn't advocate having the module format type ID in the DWARF, 
>> but in a side table (either part of the module itself, or just a section of 
>> its own in the module-as-object-file).
> 
> Do you mean a side-table in the module that maps sig8 -> ID? 
> 
> Yes, this is what I tried to articulate way-back-when we had the original 
> discussion in person at Google. That module debug info is Dwarf type units 
> (later bag-o-dwarf) + fission, plus a side table to make DWARF type 
> identifiers to module identifiers.
> 
> Certainly there are some wrinkles to that (possible type ambiguities and 
> module conflicts), but I'm really trying to stick to that original concept 
> and understand/investigate any deviation from it. (& more generally, any 
> deviation from existing DWARF practices in the field - while extensions are 
> totally reasonable, I want to really highlight when we're stepping beyond 
> existing practice and carefully choose how we do that rather than just 
> picking a representation and going with it - DWARF doesn't provide a lot of 
> guidance and we can pick essentially arbitrary DWARF to mean near arbitrary 
> things, and that'll essentially be a contract between Clang and debuggers 
> when we do so, so I'm inclined to be rather careful when making those choices 
> (because we'll eventually have to convince other debuggers to implement those 
> things, etc))
>  
> If we need to perform hash lookups to get to the ID that we might as well 
> look up the type by name in the module, because that’s also a hash table 
> lookup. I don’t think a performance argument can be made for using IDs.
> 
> Having to hash the whole mangled name (let alone piecing it together from the 
> names in the scope chain, walking the DIE parent chain, etc) is going to be 
> more expensive than using the existing sig8.

That’s not what I had in mind, let me clarify how I imagined this: A dwarf 
consumer follows the reference to the forward declaration reads the 
AT_signature looks up the type definition by signature and reconstructs the 
type from the definition. An ast consumer also follows the reference to the 
forward declaration but goes up the scope chain finds the TAG_module, imports 
it, and then uses sema to load the type by name

Re: [PATCH] D12265: [ZORG] Add support for libc++ to SphinxDocBuilder.py

[Eric Fiselier via cfe-commits]

EricWF updated this revision to Diff 33029.
EricWF marked 2 inline comments as done.

http://reviews.llvm.org/D12265

Files:
  buildbot/osuosl/master/config/builders.py
  zorg/buildbot/builders/SphinxDocsBuilder.py

Index: zorg/buildbot/builders/SphinxDocsBuilder.py
===
--- zorg/buildbot/builders/SphinxDocsBuilder.py
+++ zorg/buildbot/builders/SphinxDocsBuilder.py
@@ -6,10 +6,11 @@
 from zorg.buildbot.commands.NinjaCommand import NinjaCommand
 
 def getSphinxDocsBuildFactory(
-llvm_html  = False, # Build LLVM HTML documentation
-llvm_man   = False, # Build LLVM man pages
-clang_html = False, # Build Clang HTML documentation
-lld_html   = False  # Build LLD HTML documentation
+llvm_html   = False, # Build LLVM HTML documentation
+llvm_man= False, # Build LLVM man pages
+clang_html  = False, # Build Clang HTML documentation
+lld_html= False, # Build LLD HTML documentation
+libcxx_html = False  # Build Libc++ HTML documentation
 ):
 
 f = buildbot.process.factory.BuildFactory()
@@ -18,6 +19,8 @@
 llvm_objdir = 'llvm/build'
 clang_srcdir = llvm_srcdir + '/tools/clang'
 lld_srcdir = llvm_srcdir + '/tools/lld'
+libcxx_srcdir = llvm_srcdir + '/projects/libcxx'
+libcxxabi_srcdir = llvm_srcdir + '/projects/libcxxabi'
 
 # Get LLVM. This is essential for all builds
 # because we build all subprojects in tree
@@ -41,6 +44,18 @@
   defaultBranch='trunk',
   workdir=lld_srcdir))
 
+if libcxx_html:
+f.addStep(SVN(name='svn-libcxx',
+  mode='update',
+  baseURL='http://llvm.org/svn/llvm-project/libcxx/',
+  defaultBranch='trunk',
+  workdir=libcxx_srcdir))
+f.addStep(SVN(name='svn-libcxxabi',
+  mode='update',
+  baseURL='http://llvm.org/svn/llvm-project/libcxxabi/',
+  defaultBranch='trunk',
+  workdir=libcxxabi_srcdir))
+
 f.addStep(ShellCommand(name="create-build-dir",
command=["mkdir", "-p", llvm_objdir],
haltOnFailure=False, # We might of already 
created the directory in a previous build
@@ -92,4 +107,12 @@
targets=['docs-lld-html']
   ))
 
+if libcxx_html:
+f.addStep(NinjaCommand(name="docs-libcxx-html",
+   haltOnFailure=True,
+   description=["Build Libc++ Sphinx HTML 
documentation"],
+   workdir=llvm_objdir,
+   targets=['docs-libcxx-html']
+  ))
+
 return f
Index: buildbot/osuosl/master/config/builders.py
===
--- buildbot/osuosl/master/config/builders.py
+++ buildbot/osuosl/master/config/builders.py
@@ -1161,6 +1161,13 @@
'factory': 
SphinxDocsBuilder.getSphinxDocsBuildFactory(lld_html=True),
'category' : 'lld'
  },
+ {
+   'name':"libcxx-sphinx-docs",
+   'slavenames':["ericwf-buildslave2],
+   'builddir':"libcxx-sphinx-docs",
+   'factory': 
SphinxDocsBuilder.getSphinxDocsBuildFactory(libcxx_html=True),
+   'category' : 'libcxx'
+ }
]
 
 def get_builders():


Index: zorg/buildbot/builders/SphinxDocsBuilder.py
===
--- zorg/buildbot/builders/SphinxDocsBuilder.py
+++ zorg/buildbot/builders/SphinxDocsBuilder.py
@@ -6,10 +6,11 @@
 from zorg.buildbot.commands.NinjaCommand import NinjaCommand
 
 def getSphinxDocsBuildFactory(
-llvm_html  = False, # Build LLVM HTML documentation
-llvm_man   = False, # Build LLVM man pages
-clang_html = False, # Build Clang HTML documentation
-lld_html   = False  # Build LLD HTML documentation
+llvm_html   = False, # Build LLVM HTML documentation
+llvm_man= False, # Build LLVM man pages
+clang_html  = False, # Build Clang HTML documentation
+lld_html= False, # Build LLD HTML documentation
+libcxx_html = False  # Build Libc++ HTML documentation
 ):
 
 f = buildbot.process.factory.BuildFactory()
@@ -18,6 +19,8 @@
 llvm_objdir = 'llvm/build'
 clang_srcdir = llvm_srcdir + '/tools/clang'
 lld_srcdir = llvm_srcdir + '/tools/lld'
+libcxx_srcdir = llvm_srcdir + '/projects/libcxx'
+libcxxabi_srcdir = llvm_srcdir + '/projects/libcxxabi'
 
 # Get LLVM. This is essential for all builds
 # because we build all subprojects in tree
@@ -41,6 +44,18 @@
   defaultBranch='trunk',
   workdir=lld_srcdir))
 
+

Re: [PATCH] D12265: [ZORG] Add support for libc++ to SphinxDocBuilder.py

[Eric Fiselier via cfe-commits]

EricWF accepted this revision.
EricWF added a reviewer: EricWF.
EricWF added a comment.
This revision is now accepted and ready to land.

Accepting so I can commit.



Comment at: buildbot/osuosl/master/config/builders.py:1166
@@ +1165,3 @@
+   'name':"libcxx-sphinx-docs",
+   'slavenames':["ericwf-buildslave2],
+   'builddir':"libcxx-sphinx-docs",

delcypher wrote:
> Is there a reason you're using the slave `ericwf-buildslave2` rather than 
> `gribozavr4` which is used by the other documentation builders?
> 
> 
I have my own hardware that I might as well use. I wanted to keep gribozavr's 
hardware as free as possible in case other people need it.


Comment at: buildbot/osuosl/master/config/builders.py:1341
@@ -1333,3 +1340,3 @@
  'factory' : LNTBuilder.getLNTFactory(triple='x86_64-apple-darwin10',
-  nt_flags=['--multisample=3', 
+  nt_flags=['--multisample=3',
 '--optimize-option',

delcypher wrote:
> This spacing change doesn't really belong in this patch
I know :-( but for some reason my editor refused to leave it out. 


http://reviews.llvm.org/D12265



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

Re: [PATCH] D12265: [ZORG] Add support for libc++ to SphinxDocBuilder.py

[Eric Fiselier via cfe-commits]

EricWF closed this revision.
EricWF added a comment.

r245912.


http://reviews.llvm.org/D12265



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

Re: [PATCH] D11737: Add -linker (and -linker=) alias for -fuse-ld=

[Filipe Cabecinhas via cfe-commits]

filcab updated this revision to Diff 33030.
filcab marked an inline comment as done.
filcab added a comment.

Addressed Eric's comment.


http://reviews.llvm.org/D11737

Files:
  include/clang/Driver/Options.td
  test/Driver/fuse-ld.c

Index: test/Driver/fuse-ld.c
===
--- test/Driver/fuse-ld.c
+++ test/Driver/fuse-ld.c
@@ -24,6 +24,20 @@
 // RUN:   | FileCheck %s -check-prefix=CHECK-FREEBSD-PLIB
 // CHECK-FREEBSD-PLIB: error: invalid linker name
 
+// -linker= is an alias to fuse-ld. Don't need to retry all combinations
+// RUN: %clang %s -### -linker gold \
+// RUN: --sysroot=%S/Inputs/basic_freebsd_tree \
+// RUN: -target x86_64-unknown-freebsd \
+// RUN: -B%S/Inputs/basic_freebsd_tree/usr/bin 2>&1 \
+// RUN:   | FileCheck %s -check-prefix=CHECK-FREEBSD-GOLD
+// CHECK-FREEBSD-LINKER-GOLD: Inputs/basic_freebsd_tree/usr/bin{{/|\\+}}ld.gold
+
+// RUN: %clang %s -### -linker=gold \
+// RUN: --sysroot=%S/Inputs/basic_freebsd_tree \
+// RUN: -target x86_64-unknown-freebsd \
+// RUN: -B%S/Inputs/basic_freebsd_tree/usr/bin 2>&1 \
+// RUN:   | FileCheck %s -check-prefix=CHECK-FREEBSD-GOLD
+// CHECK-FREEBSD-LINKEREQ-GOLD: 
Inputs/basic_freebsd_tree/usr/bin{{/|\\+}}ld.gold
 
 
 // RUN: %clang %s -### \
Index: include/clang/Driver/Options.td
===
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -1849,7 +1849,8 @@
 
 def fprofile_dir : Joined<["-"], "fprofile-dir=">, 
Group;
 
-def fuse_ld_EQ : Joined<["-"], "fuse-ld=">, Group;
+def fuse_ld_EQ : Joined<["-"], "fuse-ld=">, HelpText<"Use linker ">, 
Group;
+def linker_EQ : Joined<["-"], "linker=">, Alias, 
MetaVarName<"">;
 
 defm align_functions : BooleanFFlag<"align-functions">, 
Group;
 def falign_functions_EQ : Joined<["-"], "falign-functions=">, 
Group;


Index: test/Driver/fuse-ld.c
===
--- test/Driver/fuse-ld.c
+++ test/Driver/fuse-ld.c
@@ -24,6 +24,20 @@
 // RUN:   | FileCheck %s -check-prefix=CHECK-FREEBSD-PLIB
 // CHECK-FREEBSD-PLIB: error: invalid linker name
 
+// -linker= is an alias to fuse-ld. Don't need to retry all combinations
+// RUN: %clang %s -### -linker gold \
+// RUN: --sysroot=%S/Inputs/basic_freebsd_tree \
+// RUN: -target x86_64-unknown-freebsd \
+// RUN: -B%S/Inputs/basic_freebsd_tree/usr/bin 2>&1 \
+// RUN:   | FileCheck %s -check-prefix=CHECK-FREEBSD-GOLD
+// CHECK-FREEBSD-LINKER-GOLD: Inputs/basic_freebsd_tree/usr/bin{{/|\\+}}ld.gold
+
+// RUN: %clang %s -### -linker=gold \
+// RUN: --sysroot=%S/Inputs/basic_freebsd_tree \
+// RUN: -target x86_64-unknown-freebsd \
+// RUN: -B%S/Inputs/basic_freebsd_tree/usr/bin 2>&1 \
+// RUN:   | FileCheck %s -check-prefix=CHECK-FREEBSD-GOLD
+// CHECK-FREEBSD-LINKEREQ-GOLD: Inputs/basic_freebsd_tree/usr/bin{{/|\\+}}ld.gold
 
 
 // RUN: %clang %s -### \
Index: include/clang/Driver/Options.td
===
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -1849,7 +1849,8 @@
 
 def fprofile_dir : Joined<["-"], "fprofile-dir=">, Group;
 
-def fuse_ld_EQ : Joined<["-"], "fuse-ld=">, Group;
+def fuse_ld_EQ : Joined<["-"], "fuse-ld=">, HelpText<"Use linker ">, Group;
+def linker_EQ : Joined<["-"], "linker=">, Alias, MetaVarName<"">;
 
 defm align_functions : BooleanFFlag<"align-functions">, Group;
 def falign_functions_EQ : Joined<["-"], "falign-functions=">, Group;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: patch: clarify diagnostic when returned value doesn't match function return type

[Vedant Kumar via cfe-commits]

LGTM with a caveat.

Changing diagnostic messages is scary because it can inadvertently break tools 
and IDE's. So there is a chance someone might want this reverted in the future. 
But for now it seems helpful :).

vedant

On Aug 24, 2015, at 1:19 PM, Nick Lewycky via cfe-commits 
 wrote:

> On 19 August 2015 at 15:18, Nick Lewycky  wrote:
> On 10 August 2015 at 19:08, Nick Lewycky  wrote:
> This simple-minded patch extends the case where we report "no viable 
> conversion from 'X' to 'Y'" to emit a more useful diagnostic "no viable 
> conversion from returned value of type 'X' to function return type 'Y'" when 
> used in that context.
> 
> In lieu of adding tests for this diagnostic explicitly, I've only updated the 
> tests where the patch changes their result.
> 
> Please review!
> 
> Ping!
> 
> Ping! 
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Dcommits&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=nRkKAYlatRp-Wgk-tAtmRg&m=zsNXNManBK37vPs3xRquJLuWu0PUZNNKbjXmDbYrT18&s=36cwmt-VUhgwwq4FvAY4AnJXluk0LRYerkogSqFNuqM&e=
>  

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

r245913 - [clang-cl] Only respect /Oy- for x86_32

[David Majnemer via cfe-commits]

Author: majnemer
Date: Mon Aug 24 19:46:45 2015
New Revision: 245913

URL: http://llvm.org/viewvc/llvm-project?rev=245913&view=rev
Log:
[clang-cl] Only respect /Oy- for x86_32

The /Oy- flag should have no effect for 64-bit X86, it has reliable
unwind tables.

Modified:
cfe/trunk/include/clang/Driver/CLCompatOptions.td
cfe/trunk/lib/Driver/MSVCToolChain.cpp
cfe/trunk/test/Driver/cl-fallback.c
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=245913&r1=245912&r2=245913&view=diff
==
--- cfe/trunk/include/clang/Driver/CLCompatOptions.td (original)
+++ cfe/trunk/include/clang/Driver/CLCompatOptions.td Mon Aug 24 19:46:45 2015
@@ -104,10 +104,6 @@ def _SLASH_Os : CLFlag<"Os">, HelpText<"
   AliasArgs<["s"]>;
 def _SLASH_Ot : CLFlag<"Ot">, HelpText<"Optimize for speed">, Alias,
   AliasArgs<["2"]>;
-def _SLASH_Oy : CLFlag<"Oy">, HelpText<"Enable frame pointer omission">,
-  Alias;
-def _SLASH_Oy_ : CLFlag<"Oy-">, HelpText<"Disable frame pointer omission">,
-  Alias;
 def _SLASH_QUESTION : CLFlag<"?">, Alias,
   HelpText<"Display available options">;
 def _SLASH_Qvec : CLFlag<"Qvec">,

Modified: cfe/trunk/lib/Driver/MSVCToolChain.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/MSVCToolChain.cpp?rev=245913&r1=245912&r2=245913&view=diff
==
--- cfe/trunk/lib/Driver/MSVCToolChain.cpp (original)
+++ cfe/trunk/lib/Driver/MSVCToolChain.cpp Mon Aug 24 19:46:45 2015
@@ -535,6 +535,9 @@ MSVCToolChain::TranslateArgs(const llvm:
   DerivedArgList *DAL = new DerivedArgList(Args.getBaseArgs());
   const OptTable &Opts = getDriver().getOpts();
 
+  // /Oy and /Oy- only has an effect under X86-32.
+  bool SupportsForcingFramePointer = getArch() == llvm::Triple::x86;
+
   // The -O[12xd] flag actually expands to several flags.  We must desugar the
   // flags so that options embedded can be negated.  For example, the '-O2' 
flag
   // enables '-Oy'.  Expanding '-O2' into its constituent flags allows us to
@@ -584,8 +587,9 @@ MSVCToolChain::TranslateArgs(const llvm:
   DAL->AddFlagArg(A, Opts.getOption(options::OPT_fbuiltin));
   DAL->AddJoinedArg(A, Opts.getOption(options::OPT_O), "2");
 }
-DAL->AddFlagArg(A,
-Opts.getOption(options::OPT_fomit_frame_pointer));
+if (SupportsForcingFramePointer)
+  DAL->AddFlagArg(A,
+  
Opts.getOption(options::OPT_fomit_frame_pointer));
 if (OptChar == '1' || OptChar == '2')
   DAL->AddFlagArg(A,
   Opts.getOption(options::OPT_ffunction_sections));
@@ -593,13 +597,13 @@ MSVCToolChain::TranslateArgs(const llvm:
 }
 break;
   case 'b':
-if (isdigit(OptStr[I + 1]))
+if (I + 1 != E && isdigit(OptStr[I + 1]))
   ++I;
 break;
   case 'g':
 break;
   case 'i':
-if (OptStr[I + 1] == '-') {
+if (I + 1 != E && OptStr[I + 1] == '-') {
   ++I;
   DAL->AddFlagArg(A, Opts.getOption(options::OPT_fno_builtin));
 } else {
@@ -612,16 +616,23 @@ MSVCToolChain::TranslateArgs(const llvm:
   case 't':
 DAL->AddJoinedArg(A, Opts.getOption(options::OPT_O), "2");
 break;
-  case 'y':
-if (OptStr[I + 1] == '-') {
+  case 'y': {
+bool OmitFramePointer = true;
+if (I + 1 != E && OptStr[I + 1] == '-') {
+  OmitFramePointer = false;
   ++I;
-  DAL->AddFlagArg(A,
-  Opts.getOption(options::OPT_fno_omit_frame_pointer));
-} else {
-  DAL->AddFlagArg(A, Opts.getOption(options::OPT_fomit_frame_pointer));
+}
+if (SupportsForcingFramePointer) {
+  if (OmitFramePointer)
+DAL->AddFlagArg(A,
+Opts.getOption(options::OPT_fomit_frame_pointer));
+  else
+DAL->AddFlagArg(
+A, Opts.getOption(options::OPT_fno_omit_frame_pointer));
 }
 break;
   }
+  }
 }
   }
   return DAL;

Modified: cfe/trunk/test/Driver/cl-fallback.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/cl-fallback.c?rev=245913&r1=245912&r2=245913&view=diff
==
--- cfe/trunk/test/Driver/cl-fallback.c (original)
+++ cfe/trunk/test/Driver/cl-fallback.c Mon Aug 24 19:46:45 2015
@@ -1,7 +1,7 @@
 // Note: %s must be preceded by --, otherwise it may be interpreted as a
 // command-line option, e.g. on Mac where %s is commonly under /Users.
 
-// RUN: %clang_cl /fallback /Dfoo=bar /Ubaz /Ifoo /O0 /Ox /GR /GR- /Gy /Gy- \
+// RUN: %clang_cl --target=i686

Re: [PATCH] D11737: Add -linker (and -linker=) alias for -fuse-ld=

[Eric Christopher via cfe-commits]

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

One inline comment and then OK.

-eric



Comment at: test/Driver/fuse-ld.c:27-33
@@ -26,1 +26,9 @@
 
+// -linker= is an alias to fuse-ld. Don't need to retry all combinations
+// RUN: %clang %s -### -linker gold \
+// RUN: --sysroot=%S/Inputs/basic_freebsd_tree \
+// RUN: -target x86_64-unknown-freebsd \
+// RUN: -B%S/Inputs/basic_freebsd_tree/usr/bin 2>&1 \
+// RUN:   | FileCheck %s -check-prefix=CHECK-FREEBSD-GOLD
+// CHECK-FREEBSD-LINKER-GOLD: Inputs/basic_freebsd_tree/usr/bin{{/|\\+}}ld.gold
+

Bet this doesn't work :)


http://reviews.llvm.org/D11737



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

Re: [PATCH] D11737: Add -linker (and -linker=) alias for -fuse-ld=

[Peter Collingbourne via cfe-commits]

pcc added a subscriber: pcc.


Comment at: test/Driver/fuse-ld.c:32-33
@@ +31,4 @@
+// RUN: -B%S/Inputs/basic_freebsd_tree/usr/bin 2>&1 \
+// RUN:   | FileCheck %s -check-prefix=CHECK-FREEBSD-GOLD
+// CHECK-FREEBSD-LINKER-GOLD: Inputs/basic_freebsd_tree/usr/bin{{/|\\+}}ld.gold
+

Prefix mismatch here.


Comment at: test/Driver/fuse-ld.c:39-40
@@ -27,1 +38,4 @@
+// RUN: -B%S/Inputs/basic_freebsd_tree/usr/bin 2>&1 \
+// RUN:   | FileCheck %s -check-prefix=CHECK-FREEBSD-GOLD
+// CHECK-FREEBSD-LINKEREQ-GOLD: 
Inputs/basic_freebsd_tree/usr/bin{{/|\\+}}ld.gold
 

Same here.


http://reviews.llvm.org/D11737



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

Re: [PATCH] D11737: Add -linker (and -linker=) alias for -fuse-ld=

[Nico Weber via cfe-commits]

thakis added a subscriber: thakis.
This revision is now accepted and ready to land.


Comment at: include/clang/Driver/Options.td:1853
@@ -1853,1 +1852,3 @@
+def fuse_ld_EQ : Joined<["-"], "fuse-ld=">, HelpText<"Use linker ">, 
Group;
+def linker_EQ : Joined<["-"], "linker=">, Alias, 
MetaVarName<"">;
 

Any reason to have another alias for this at all? Does gcc understand this 
spelling? If not, could you limit this flag to PS4 targets? (I'm guessing you 
need it for PS4 targets for some reason.)


http://reviews.llvm.org/D11737



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

Re: [PATCH] D11737: Add -linker (and -linker=) alias for -fuse-ld=

[Eric Christopher via cfe-commits]

echristo added inline comments.


Comment at: include/clang/Driver/Options.td:1853
@@ -1853,1 +1852,3 @@
+def fuse_ld_EQ : Joined<["-"], "fuse-ld=">, HelpText<"Use linker ">, 
Group;
+def linker_EQ : Joined<["-"], "linker=">, Alias, 
MetaVarName<"">;
 

thakis wrote:
> Any reason to have another alias for this at all? Does gcc understand this 
> spelling? If not, could you limit this flag to PS4 targets? (I'm guessing you 
> need it for PS4 targets for some reason.)
Any reason? (And I'm not sure how to limit it btw on target).


http://reviews.llvm.org/D11737



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

Re: patch: clarify diagnostic when returned value doesn't match function return type

[David Majnemer via cfe-commits]

On Mon, Aug 24, 2015 at 5:44 PM, Vedant Kumar via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> LGTM with a caveat.
>
> Changing diagnostic messages is scary because it can inadvertently break
> tools and IDE's. So there is a chance someone might want this reverted in
> the future. But for now it seems helpful :).
>

To the best of my knowledge, we have no policy which forbids us from
adding/removing/changing diagnostics.  Was this discussed at some point in
the past?


>
> vedant
>
> On Aug 24, 2015, at 1:19 PM, Nick Lewycky via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> > On 19 August 2015 at 15:18, Nick Lewycky  wrote:
> > On 10 August 2015 at 19:08, Nick Lewycky  wrote:
> > This simple-minded patch extends the case where we report "no viable
> conversion from 'X' to 'Y'" to emit a more useful diagnostic "no viable
> conversion from returned value of type 'X' to function return type 'Y'"
> when used in that context.
> >
> > In lieu of adding tests for this diagnostic explicitly, I've only
> updated the tests where the patch changes their result.
> >
> > Please review!
> >
> > Ping!
> >
> > Ping!
> > ___
> > cfe-commits mailing list
> > cfe-commits@lists.llvm.org
> >
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Dcommits&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=nRkKAYlatRp-Wgk-tAtmRg&m=zsNXNManBK37vPs3xRquJLuWu0PUZNNKbjXmDbYrT18&s=36cwmt-VUhgwwq4FvAY4AnJXluk0LRYerkogSqFNuqM&e=
>
> ___
> 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
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: patch: clarify diagnostic when returned value doesn't match function return type

[Vedant Kumar via cfe-commits]

I can't find any reference to a policy against changing diagnostics. We should 
be in the clear.

vedant

On Aug 24, 2015, at 5:49 PM, David Majnemer  wrote:
> On Mon, Aug 24, 2015 at 5:44 PM, Vedant Kumar via cfe-commits 
>  wrote:
> LGTM with a caveat.
> 
> Changing diagnostic messages is scary because it can inadvertently break 
> tools and IDE's. So there is a chance someone might want this reverted in the 
> future. But for now it seems helpful :).
> 
>> To the best of my knowledge, we have no policy which forbids us from 
>> adding/removing/changing diagnostics.  Was this discussed at some point in 
>> the past?
>  
> 
> vedant
> 
> On Aug 24, 2015, at 1:19 PM, Nick Lewycky via cfe-commits 
>  wrote:
> 
> > On 19 August 2015 at 15:18, Nick Lewycky  wrote:
> > On 10 August 2015 at 19:08, Nick Lewycky  wrote:
> > This simple-minded patch extends the case where we report "no viable 
> > conversion from 'X' to 'Y'" to emit a more useful diagnostic "no viable 
> > conversion from returned value of type 'X' to function return type 'Y'" 
> > when used in that context.
> >
> > In lieu of adding tests for this diagnostic explicitly, I've only updated 
> > the tests where the patch changes their result.
> >
> > Please review!
> >
> > Ping!
> >
> > Ping!
> > ___
> > cfe-commits mailing list
> > cfe-commits@lists.llvm.org
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Dcommits&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=nRkKAYlatRp-Wgk-tAtmRg&m=zsNXNManBK37vPs3xRquJLuWu0PUZNNKbjXmDbYrT18&s=36cwmt-VUhgwwq4FvAY4AnJXluk0LRYerkogSqFNuqM&e=
> 
> ___
> 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
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] Have clang list the imported modules in the debug info

[David Blaikie via cfe-commits]

On Mon, Aug 24, 2015 at 5:33 PM, Adrian Prantl  wrote:

>
> On Aug 24, 2015, at 4:17 PM, David Blaikie  wrote:
>
>
>
> On Mon, Aug 24, 2015 at 3:34 PM, Adrian Prantl  wrote:
>
>>
>> On Aug 24, 2015, at 2:01 PM, David Blaikie  wrote:
>>
>>
>>
>> On Mon, Aug 24, 2015 at 1:23 PM, Adrian Prantl  wrote:
>>
>>>
>>> On Aug 19, 2015, at 1:20 PM, David Blaikie  wrote:
>>>
>>>
>>>
>>> On Mon, Aug 10, 2015 at 5:00 PM, Adrian Prantl 
>>> wrote:
>>>

 On Jul 24, 2015, at 12:33 PM, David Blaikie  wrote:

 *reads back through the thread*


 appreciated, it’s long :-)

 So what I originally had in mind about a year ago when we discussed
 this, was that the module data could have an extra table from type hash to
 whatever useful internal representation to find the type in the PCM.


 It turned out that the most useful internal type representation to find
 a type in a PCM is the type’s DeclContext+Name; this is how (surprise!)
 clang looks up types in a PCM and the format is supposed to be fast for
 these kind of lookups.

>>>
>>> Still, I would imagine there would be some kind of direct access (the
>>> offset in the file, or somesuch) rather than actually having to go through
>>> hashtables, etc. No? (how does one module refer to types in another module?
>>> Really by name?)
>>>
>>>
>>> Entities in PCMs have local integer IDs (just consecutive numbers) that
>>> are used to encode references inside a record on disk. An external
>>> reference gets a global ID which is the local ID + the ID of the other
>>> module. This numbering scheme of course only makes sense within a module
>>> (and perhaps also within a chained PCH). Every (local and global) ID maps
>>> to an entry in the PCM’s identifier table. When deserializing, the
>>> in-memory global IdentifierTable is built and each module gets a map that
>>> remaps its internal global IDs to the “global” global IDs.
>>>
>>> For debug info these IDs are not very useful, because they are not
>>> resilient against even the smallest additive change to the module. We could
>>> add an integer attribute with the module-internal entity ID to the forward
>>> declaration that the debugger can use if the module hash and the CU’s dwoid
>>> are matching, but I’m not yet convinced that it would be worth it. Adding
>>> it to the definition of the type in the module dwarf seems not worth it
>>> because then we already have to do a similarly expensive lookup to find the
>>> module containing the definition.
>>>
>>
>> It seems that ideally a module-aware debugger would not consult the DWARF
>> at all, so I wouldn't advocate having the module format type ID in the
>> DWARF, but in a side table (either part of the module itself, or just a
>> section of its own in the module-as-object-file).
>>
>>
>> Do you mean a side-table in the module that maps sig8 -> ID?
>>
>
> Yes, this is what I tried to articulate way-back-when we had the original
> discussion in person at Google. That module debug info is Dwarf type units
> (later bag-o-dwarf) + fission, plus a side table to make DWARF type
> identifiers to module identifiers.
>
> Certainly there are some wrinkles to that (possible type ambiguities and
> module conflicts), but I'm really trying to stick to that original concept
> and understand/investigate any deviation from it. (& more generally, any
> deviation from existing DWARF practices in the field - while extensions are
> totally reasonable, I want to really highlight when we're stepping beyond
> existing practice and carefully choose how we do that rather than just
> picking a representation and going with it - DWARF doesn't provide a lot of
> guidance and we can pick essentially arbitrary DWARF to mean near arbitrary
> things, and that'll essentially be a contract between Clang and debuggers
> when we do so, so I'm inclined to be rather careful when making those
> choices (because we'll eventually have to convince other debuggers to
> implement those things, etc))
>
>
>> If we need to perform hash lookups to get to the ID that we might as well
>> look up the type by name in the module, because that’s also a hash table
>> lookup. I don’t think a performance argument can be made for using IDs.
>>
>
> Having to hash the whole mangled name (let alone piecing it together from
> the names in the scope chain, walking the DIE parent chain, etc) is going
> to be more expensive than using the existing sig8.
>
>
> That’s not what I had in mind, let me clarify how I imagined this: A dwarf
> consumer follows the reference to the forward declaration reads the
> AT_signature looks up the type definition by signature and reconstructs the
> type from the definition. An ast consumer also follows the reference to the
> forward declaration but goes up the scope chain finds the TAG_module,
> imports it, and then uses sema to load the type by name thus causing clang
> to deserialize the type without getting their hands dirty with module
> internal