Re: [PATCH] D15174: [MSVC] Fix for http://llvm.org/PR25636: indexed accessor property not supported correctly.

[John McCall via cfe-commits]

rjmccall added a comment.

I don't understand why that's true.  buildSet is called with 
captureSetValueAsResult=true, and the set value is definitely capturable, so 
that value should be set as the result; and you're not overriding it.  Why does 
the expression end up having type void?


http://reviews.llvm.org/D15174



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

Re: [PATCH] D15120: Add support for __float128 type to be used by targets that support it

[John McCall via cfe-commits]

rjmccall added a reviewer: akyrtzi.


Comment at: lib/AST/ASTContext.cpp:5424
@@ -5410,1 +5423,3 @@
+// FIXME: need to figure out what this is for __float128
+case BuiltinType::Float128:   return 'K';
 case BuiltinType::NullPtr:return '*'; // like char*

Please add this as a case to the block below for Half.  I'll ping internally 
for a decision on what @encoding to use.


Comment at: lib/Index/USRGeneration.cpp:604
@@ -602,1 +603,3 @@
+case BuiltinType::Float128:
+  c = ' '; break;
 case BuiltinType::NullPtr:

I'm pretty sure you can just choose something here that doesn't collide, but 
the right person to ask is Argyrios.


Repository:
  rL LLVM

http://reviews.llvm.org/D15120



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

Re: [PATCH] D15174: [MSVC] Fix for http://llvm.org/PR25636: indexed accessor property not supported correctly.

[Alexey Bataev via cfe-commits]

Set value is a call to SetX() function, neither the argument of the 
SetX(), nor the result of the GetX(). So, expression a.x=5 always emits 
the following code as a result a.Setx(5). 
MSPropertyRefBuilder::buildSet() does not capture results at all. It 
just ignores

captureSetValueAsResult

value. That's why we have to capture final result after 'set' is built 
completely.

Best regards,
Alexey Bataev
=
Software Engineer
Intel Compiler Team

07.12.2015 11:07, John McCall пишет:
> rjmccall added a comment.
>
> I don't understand why that's true.  buildSet is called with 
> captureSetValueAsResult=true, and the set value is definitely capturable, so 
> that value should be set as the result; and you're not overriding it.  Why 
> does the expression end up having type void?
>
>
> http://reviews.llvm.org/D15174
>
>
>

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

Re: [PATCH] D13126: New static analyzer checker for loss of sign/precision

[Daniel Marjamäki via cfe-commits]

danielmarjamaki marked 2 inline comments as done.
danielmarjamaki added a comment.

In http://reviews.llvm.org/D13126#302647, @dcoughlin wrote:

> In http://reviews.llvm.org/D13126#302328, @danielmarjamaki wrote:
>
> > When scanning 692 projects with this checker I got 56 warnings. I've 
> > triaged 21 random warnings of these so far and saw 20 TP and 1 FP.
> >
> > When I have triaged the results there is one kind of "possible FP" that I 
> > see, like this:
> >
> >   unsigned long x = largevalue;
> >   bytes[0] = x;  // Possible FP here. Technically it's a TP but it's an 
> > loss of precision by design.
> >   bytes[1] = x >> 8;
> >   
> >   
> >
> > I am currently considering to allow this FP. Any opinions about allowing it?
>
>
> Is there mechanism by which the user can suppress false positives like this 
> (for example, an explicit cast)?


Yes it can be suppressed using for instance "x & 0xff" or "(unsigned char)x".

The checker could hide the warning if the previous or next statement is 
"somevar = x >> 8". I don't think that would cause any significant FN. However 
I still consider to write the "FP".



Comment at: test/Analysis/conversion.c:23
@@ +22,2 @@
+  U8 = S+10;
+}

it was removed


http://reviews.llvm.org/D13126



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

Re: [PATCH] D15223: [ARM] [AARCH64] Add CodeGen IR tests for {VS}QRDML{AS}H v8.1a intrinsics.

[Alexandros Lamprineas via cfe-commits]

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

ASM tests have been removed.


http://reviews.llvm.org/D15223

Files:
  test/CodeGen/aarch64-v8.1a-neon-intrinsics.c
  test/CodeGen/arm-v8.1a-neon-intrinsics.c

Index: test/CodeGen/arm-v8.1a-neon-intrinsics.c
===
--- test/CodeGen/arm-v8.1a-neon-intrinsics.c
+++ test/CodeGen/arm-v8.1a-neon-intrinsics.c
@@ -1,122 +1,188 @@
 // RUN: %clang_cc1 -triple armv8.1a-linux-gnu -target-feature +neon \
-// RUN:  -O3 -S -o - %s \
+// RUN:  -O1 -S -emit-llvm -o - %s \
 // RUN:  | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-ARM
+
 // RUN: %clang_cc1 -triple aarch64-linux-gnu -target-feature +neon \
-// RUN:  -target-feature +v8.1a -O3 -S -o - %s \
+// RUN:  -target-feature +v8.1a -O1 -S -emit-llvm -o - %s \
 // RUN:  | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-AARCH64
+
 // REQUIRES: arm-registered-target,aarch64-registered-target
 
 #include 
 
 // CHECK-LABEL: test_vqrdmlah_s16
 int16x4_t test_vqrdmlah_s16(int16x4_t a, int16x4_t b, int16x4_t c) {
-// CHECK-ARM: vqrdmlah.s16 d{{[0-9]+}}, d{{[0-9]+}}, d{{[0-9]+}}
-// CHECK-AARCH64: sqrdmlah {{v[0-9]+}}.4h, {{v[0-9]+}}.4h, {{v[0-9]+}}.4h
+// CHECK-ARM: [[mul:%.*]] = tail call <4 x i16> @llvm.arm.neon.vqrdmulh.v4i16(<4 x i16> %b, <4 x i16> %c)
+// CHECK-ARM: tail call <4 x i16> @llvm.arm.neon.vqadds.v4i16(<4 x i16> %a, <4 x i16> [[mul]])
+
+// CHECK-AARCH64: [[mul:%.*]] = tail call <4 x i16> @llvm.aarch64.neon.sqrdmulh.v4i16(<4 x i16> %b, <4 x i16> %c)
+// CHECK-AARCH64: tail call <4 x i16> @llvm.aarch64.neon.sqadd.v4i16(<4 x i16> %a, <4 x i16> [[mul]])
   return vqrdmlah_s16(a, b, c);
 }
 
 // CHECK-LABEL: test_vqrdmlah_s32
 int32x2_t test_vqrdmlah_s32(int32x2_t a, int32x2_t b, int32x2_t c) {
-// CHECK-ARM: vqrdmlah.s32 d{{[0-9]+}}, d{{[0-9]+}}, d{{[0-9]+}}
-// CHECK-AARCH64: sqrdmlah {{v[0-9]+}}.2s, {{v[0-9]+}}.2s, {{v[0-9]+}}.2s
+// CHECK-ARM: [[mul:%.*]] = tail call <2 x i32> @llvm.arm.neon.vqrdmulh.v2i32(<2 x i32> %b, <2 x i32> %c)
+// CHECK-ARM: tail call <2 x i32> @llvm.arm.neon.vqadds.v2i32(<2 x i32> %a, <2 x i32> [[mul]])
+
+// CHECK-AARCH64: [[mul:%.*]] = tail call <2 x i32> @llvm.aarch64.neon.sqrdmulh.v2i32(<2 x i32> %b, <2 x i32> %c)
+// CHECK-AARCH64: tail call <2 x i32> @llvm.aarch64.neon.sqadd.v2i32(<2 x i32> %a, <2 x i32> [[mul]])
   return vqrdmlah_s32(a, b, c);
 }
 
 // CHECK-LABEL: test_vqrdmlahq_s16
 int16x8_t test_vqrdmlahq_s16(int16x8_t a, int16x8_t b, int16x8_t c) {
-// CHECK-ARM: vqrdmlah.s16 q{{[0-9]+}}, q{{[0-9]+}}, q{{[0-9]+}}
-// CHECK-AARCH64: sqrdmlah {{v[0-9]+}}.8h, {{v[0-9]+}}.8h, {{v[0-9]+}}.8h
+// CHECK-ARM: [[mul:%.*]] = tail call <8 x i16> @llvm.arm.neon.vqrdmulh.v8i16(<8 x i16> %b, <8 x i16> %c)
+// CHECK-ARM: tail call <8 x i16> @llvm.arm.neon.vqadds.v8i16(<8 x i16> %a, <8 x i16> [[mul]])
+
+// CHECK-AARCH64: [[mul:%.*]] = tail call <8 x i16> @llvm.aarch64.neon.sqrdmulh.v8i16(<8 x i16> %b, <8 x i16> %c)
+// CHECK-AARCH64: tail call <8 x i16> @llvm.aarch64.neon.sqadd.v8i16(<8 x i16> %a, <8 x i16> [[mul]])
   return vqrdmlahq_s16(a, b, c);
 }
 
 // CHECK-LABEL: test_vqrdmlahq_s32
 int32x4_t test_vqrdmlahq_s32(int32x4_t a, int32x4_t b, int32x4_t c) {
-// CHECK-ARM: vqrdmlah.s32 q{{[0-9]+}}, q{{[0-9]+}}, q{{[0-9]+}}
-// CHECK-AARCH64: sqrdmlah {{v[0-9]+}}.4s, {{v[0-9]+}}.4s, {{v[0-9]+}}.4s
+// CHECK-ARM: [[mul:%.*]] = tail call <4 x i32> @llvm.arm.neon.vqrdmulh.v4i32(<4 x i32> %b, <4 x i32> %c)
+// CHECK-ARM: tail call <4 x i32> @llvm.arm.neon.vqadds.v4i32(<4 x i32> %a, <4 x i32> [[mul]])
+
+// CHECK-AARCH64: [[mul:%.*]] = tail call <4 x i32> @llvm.aarch64.neon.sqrdmulh.v4i32(<4 x i32> %b, <4 x i32> %c)
+// CHECK-AARCH64: tail call <4 x i32> @llvm.aarch64.neon.sqadd.v4i32(<4 x i32> %a, <4 x i32> [[mul]])
   return vqrdmlahq_s32(a, b, c);
 }
 
 // CHECK-LABEL: test_vqrdmlah_lane_s16
 int16x4_t test_vqrdmlah_lane_s16(int16x4_t a, int16x4_t b, int16x4_t c) {
-// CHECK-ARM: vqrdmlah.s16 d{{[0-9]+}}, d{{[0-9]+}}, d{{[0-9]+}}[3]
-// CHECK-AARCH64: sqrdmlah {{v[0-9]+}}.4h, {{v[0-9]+}}.4h, {{v[0-9]+}}.h[3]
+// CHECK-ARM: [[shuffle:%.*]] = shufflevector <4 x i16> %c, <4 x i16> undef, <4 x i32> 
+// CHECK-ARM: [[mul:%.*]] = tail call <4 x i16> @llvm.arm.neon.vqrdmulh.v4i16(<4 x i16> %b, <4 x i16> [[shuffle]])
+// CHECK-ARM: tail call <4 x i16> @llvm.arm.neon.vqadds.v4i16(<4 x i16> %a, <4 x i16> [[mul]])
+
+// CHECK-AARCH64: [[shuffle:%.*]] = shufflevector <4 x i16> %c, <4 x i16> undef, <4 x i32> 
+// CHECK-AARCH64: [[mul:%.*]] = tail call <4 x i16> @llvm.aarch64.neon.sqrdmulh.v4i16(<4 x i16> %b, <4 x i16> [[shuffle]])
+// CHECK-AARCH64: tail call <4 x i16> @llvm.aarch64.neon.sqadd.v4i16(<4 x i16> %a, <4 x i16> [[mul]])
   return vqrdmlah_lane_s16(a, b, c, 3);
 }
 
 // CHECK-LABEL: test_vqrdmlah_lane_s32
 int32x2_t test_vqrdmlah_lane_s32(int32x2_t a, int32x2_t b, int32x2_t c) {
-// CHECK-ARM: vqrdmlah.s32 d{{[0-9]+}}, d{{[0-9]+}}, d{{[0-9]+}}[1]
-// CHECK-AARCH64: sqrdmlah {{v[0-9]+}}.2s, {{v

Re: [PATCH] D12726: [analyzer] A fix for symbolic element region index lifetime.

[Artem Dergachev via cfe-commits]

NoQ added a comment.

In http://reviews.llvm.org/D12726#303122, @zaks.anna wrote:

> > So the real question is whether (or rather how) the Store should maintain 
> > correct region liveness information 
>
> >  after completing its internal garbage collection pass, because there are, 
> > in fact, other users of 
>
> >  this information later in the chain, but this seems to be a larger problem 
> > without instantly noticeable effects.
>
>
> Could you give specific (possibly potential) examples of this problem?
>
> We assume that the symbols that are collected do not need to stick around, so 
> no-one "later in the chain" should need them. Except for the cases where we 
> artificially extend liveness by calling addSymbolDependency().


What I was trying to say is that after `StoreManager` iterates over the 
`Store`, there are also checkers that may want to make decisions on liveness of 
their symbols based on liveness of certain regions, by checking 
`SymbolReaper::isLiveRegion()`, but currently such behavior is very rare, and 
thus barely tested. But eventually, with more checkers and further development, 
we'd need to figure out how this should work (eg. 
http://reviews.llvm.org/D14277 is a step in this direction - this patch can 
only work as long as `isLiveRegion()` is reliable after GC'ing the `Store`). 
Theoretically, it still makes sense to me to say that, for example, the `Store` 
shouldn't hold its keys as live - for the reasons stated above.

So this is mostly a hand-waving thing, and i think the patch is not immediately 
affected by this potential debate, and it should be OK to commit it.


http://reviews.llvm.org/D12726



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

r254899 - [OPENMP 4.5] parsing/sema support for 'nogroup' clause.

[Alexey Bataev via cfe-commits]

Author: abataev
Date: Mon Dec  7 04:51:44 2015
New Revision: 254899

URL: http://llvm.org/viewvc/llvm-project?rev=254899&view=rev
Log:
[OPENMP 4.5] parsing/sema support for 'nogroup' clause.
OpenMP 4.5 adds 'taskloop' and 'taskloop simd' directives. These directives 
have new 'nogroup' clause. Patch adds basic parsing/sema support for this 
clause.

Modified:
cfe/trunk/include/clang/AST/OpenMPClause.h
cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
cfe/trunk/include/clang/Basic/OpenMPKinds.def
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/AST/StmtPrinter.cpp
cfe/trunk/lib/AST/StmtProfile.cpp
cfe/trunk/lib/Basic/OpenMPKinds.cpp
cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
cfe/trunk/lib/Parse/ParseOpenMP.cpp
cfe/trunk/lib/Sema/SemaOpenMP.cpp
cfe/trunk/lib/Sema/TreeTransform.h
cfe/trunk/lib/Serialization/ASTReaderStmt.cpp
cfe/trunk/lib/Serialization/ASTWriterStmt.cpp
cfe/trunk/test/OpenMP/taskloop_ast_print.cpp
cfe/trunk/test/OpenMP/taskloop_misc_messages.c
cfe/trunk/test/OpenMP/taskloop_simd_ast_print.cpp
cfe/trunk/test/OpenMP/taskloop_simd_misc_messages.c
cfe/trunk/tools/libclang/CIndex.cpp

Modified: cfe/trunk/include/clang/AST/OpenMPClause.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/OpenMPClause.h?rev=254899&r1=254898&r2=254899&view=diff
==
--- cfe/trunk/include/clang/AST/OpenMPClause.h (original)
+++ cfe/trunk/include/clang/AST/OpenMPClause.h Mon Dec  7 04:51:44 2015
@@ -2893,6 +2893,37 @@ public:
   child_range children() { return child_range(&Priority, &Priority + 1); }
 };
 
+/// \brief This represents 'nogroup' clause in the '#pragma omp ...' directive.
+///
+/// \code
+/// #pragma omp taskloop nogroup
+/// \endcode
+/// In this example directive '#pragma omp taskloop' has 'nogroup' clause.
+///
+class OMPNogroupClause : public OMPClause {
+public:
+  /// \brief Build 'nogroup' clause.
+  ///
+  /// \param StartLoc Starting location of the clause.
+  /// \param EndLoc Ending location of the clause.
+  ///
+  OMPNogroupClause(SourceLocation StartLoc, SourceLocation EndLoc)
+  : OMPClause(OMPC_nogroup, StartLoc, EndLoc) {}
+
+  /// \brief Build an empty clause.
+  ///
+  OMPNogroupClause()
+  : OMPClause(OMPC_nogroup, SourceLocation(), SourceLocation()) {}
+
+  static bool classof(const OMPClause *T) {
+return T->getClauseKind() == OMPC_nogroup;
+  }
+
+  child_range children() {
+return child_range(child_iterator(), child_iterator());
+  }
+};
+
 } // end namespace clang
 
 #endif // LLVM_CLANG_AST_OPENMPCLAUSE_H

Modified: cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/RecursiveASTVisitor.h?rev=254899&r1=254898&r2=254899&view=diff
==
--- cfe/trunk/include/clang/AST/RecursiveASTVisitor.h (original)
+++ cfe/trunk/include/clang/AST/RecursiveASTVisitor.h Mon Dec  7 04:51:44 2015
@@ -2571,6 +2571,11 @@ bool RecursiveASTVisitor::Visit
 }
 
 template 
+bool RecursiveASTVisitor::VisitOMPNogroupClause(OMPNogroupClause *) {
+  return true;
+}
+
+template 
 template 
 bool RecursiveASTVisitor::VisitOMPClauseList(T *Node) {
   for (auto *E : Node->varlists()) {

Modified: cfe/trunk/include/clang/Basic/OpenMPKinds.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/OpenMPKinds.def?rev=254899&r1=254898&r2=254899&view=diff
==
--- cfe/trunk/include/clang/Basic/OpenMPKinds.def (original)
+++ cfe/trunk/include/clang/Basic/OpenMPKinds.def Mon Dec  7 04:51:44 2015
@@ -161,6 +161,7 @@ OPENMP_CLAUSE(map, OMPMapClause)
 OPENMP_CLAUSE(num_teams, OMPNumTeamsClause)
 OPENMP_CLAUSE(thread_limit, OMPThreadLimitClause)
 OPENMP_CLAUSE(priority, OMPPriorityClause)
+OPENMP_CLAUSE(nogroup, OMPNogroupClause)
 
 // Clauses allowed for OpenMP directive 'parallel'.
 OPENMP_PARALLEL_CLAUSE(if)
@@ -363,6 +364,7 @@ OPENMP_TASKLOOP_CLAUSE(final)
 OPENMP_TASKLOOP_CLAUSE(untied)
 OPENMP_TASKLOOP_CLAUSE(mergeable)
 OPENMP_TASKLOOP_CLAUSE(priority)
+OPENMP_TASKLOOP_CLAUSE(nogroup)
 
 // Clauses allowed for OpenMP directive 'taskloop simd'.
 // TODO: add next clauses
@@ -381,6 +383,7 @@ OPENMP_TASKLOOP_SIMD_CLAUSE(linear)
 OPENMP_TASKLOOP_SIMD_CLAUSE(aligned)
 OPENMP_TASKLOOP_SIMD_CLAUSE(safelen)
 OPENMP_TASKLOOP_SIMD_CLAUSE(simdlen)
+OPENMP_TASKLOOP_SIMD_CLAUSE(nogroup)
 
 #undef OPENMP_TASKLOOP_SIMD_CLAUSE
 #undef OPENMP_TASKLOOP_CLAUSE

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=254899&r1=254898&r2=254899&view=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Mon Dec  7 04:51:44 2015
@@ -8069,6 +8069,9 @

Re: [PATCH] D15225: [Driver] Sanitizer support based on runtime library presence

[Kuba Brecka via cfe-commits]

kubabrecka updated this revision to Diff 42041.
kubabrecka added a comment.

Applying clang-format.


http://reviews.llvm.org/D15225

Files:
  include/clang/Basic/DiagnosticDriverKinds.td
  include/clang/Driver/ToolChain.h
  lib/Driver/SanitizerArgs.cpp
  lib/Driver/ToolChain.cpp
  lib/Driver/ToolChains.cpp
  lib/Driver/ToolChains.h
  
test/Driver/Inputs/resource_dir_darwin_sanitizers/lib/darwin/libclang_rt.asan_iossim_dynamic.dylib
  
test/Driver/Inputs/resource_dir_darwin_sanitizers/lib/darwin/libclang_rt.asan_osx_dynamic.dylib
  
test/Driver/Inputs/resource_dir_darwin_sanitizers/lib/darwin/libclang_rt.tsan_osx_dynamic.dylib
  
test/Driver/Inputs/resource_dir_darwin_sanitizers/lib/darwin/libclang_rt.ubsan_iossim_dynamic.dylib
  
test/Driver/Inputs/resource_dir_darwin_sanitizers/lib/darwin/libclang_rt.ubsan_osx_dynamic.dylib
  test/Driver/darwin-asan-nofortify.c
  test/Driver/darwin-sanitizer-ld.c
  test/Driver/fsanitize.c
  test/Driver/sanitizer-ld.c

Index: test/Driver/sanitizer-ld.c
===
--- test/Driver/sanitizer-ld.c
+++ test/Driver/sanitizer-ld.c
@@ -295,6 +295,7 @@
 // RUN: -mmacosx-version-min=10.6 \
 // RUN: -target x86_64-apple-darwin13.4.0 \
 // RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN: -resource-dir=%S/Inputs/resource_dir_darwin_sanitizers \
 // RUN:   | FileCheck --check-prefix=CHECK-ASAN-DARWIN106-CXX %s
 // CHECK-ASAN-DARWIN106-CXX: "{{.*}}ld{{(.exe)?}}"
 // CHECK-ASAN-DARWIN106-CXX: libclang_rt.asan_osx_dynamic.dylib
Index: test/Driver/fsanitize.c
===
--- test/Driver/fsanitize.c
+++ test/Driver/fsanitize.c
@@ -10,8 +10,10 @@
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=undefined %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-UNDEFINED
 // CHECK-UNDEFINED: "-fsanitize={{((signed-integer-overflow|integer-divide-by-zero|float-divide-by-zero|function|shift-base|shift-exponent|unreachable|return|vla-bound|alignment|null|vptr|object-size|float-cast-overflow|array-bounds|enum|bool|returns-nonnull-attribute|nonnull-attribute),?){19}"}}
 
-// RUN: %clang -target x86_64-apple-darwin10 -fsanitize=undefined %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-UNDEFINED-DARWIN
-// CHECK-UNDEFINED-DARWIN: "-fsanitize={{((signed-integer-overflow|integer-divide-by-zero|float-divide-by-zero|shift-base|shift-exponent|unreachable|return|vla-bound|alignment|null|object-size|float-cast-overflow|array-bounds|enum|bool|returns-nonnull-attribute|nonnull-attribute),?){17}"}}
+// RUN: %clang -target x86_64-apple-darwin10 -resource-dir=%S/Inputs/resource_dir -fsanitize=undefined %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-UNDEFINED-DARWIN1
+// CHECK-UNDEFINED-DARWIN1: error: '-fsanitize-trap=undefined' required with '-fsanitize=undefined' option
+// RUN: %clang -target x86_64-apple-darwin10 -resource-dir=%S/Inputs/resource_dir_darwin_sanitizers -fsanitize=undefined %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-UNDEFINED-DARWIN2
+// CHECK-UNDEFINED-DARWIN2: "-fsanitize={{((signed-integer-overflow|integer-divide-by-zero|float-divide-by-zero|shift-base|shift-exponent|unreachable|return|vla-bound|alignment|null|object-size|float-cast-overflow|array-bounds|enum|bool|returns-nonnull-attribute|nonnull-attribute),?){17}"}}
 
 // RUN: %clang -target i386-unknown-openbsd -fsanitize=undefined %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-UNDEFINED-OPENBSD
 // CHECK-UNDEFINED-OPENBSD: "-fsanitize={{((signed-integer-overflow|integer-divide-by-zero|float-divide-by-zero|shift-base|shift-exponent|unreachable|return|vla-bound|alignment|null|object-size|float-cast-overflow|array-bounds|enum|bool|returns-nonnull-attribute|nonnull-attribute),?){17}"}}
@@ -28,9 +30,15 @@
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=integer %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-INTEGER
 // CHECK-INTEGER: "-fsanitize={{((signed-integer-overflow|unsigned-integer-overflow|integer-divide-by-zero|shift-base|shift-exponent),?){5}"}}
 
-// RUN: %clang -fsanitize=bounds -### -fsyntax-only %s 2>&1 | FileCheck %s --check-prefix=CHECK-BOUNDS
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=bounds -### -fsyntax-only %s 2>&1 | FileCheck %s --check-prefix=CHECK-BOUNDS
 // CHECK-BOUNDS: "-fsanitize={{((array-bounds|local-bounds),?){2}"}}
 
+// RUN: %clang -target x86_64-apple-darwin10 -resource-dir=%S/Inputs/resource_dir -fsanitize=bounds -### -fsyntax-only %s 2>&1 | FileCheck %s --check-prefix=CHECK-BOUNDS-DARWIN1
+// CHECK-BOUNDS-DARWIN1: error: '-fsanitize-trap=undefined' required with '-fsanitize=bounds' option
+
+// RUN: %clang -target x86_64-apple-darwin10 -resource-dir=%S/Inputs/resource_dir_darwin_sanitizers -fsanitize=bounds -### -fsyntax-only %s 2>&1 | FileCheck %s --check-prefix=CHECK-BOUNDS-DARWIN2
+// CHECK-BOUNDS-DARWIN2: "-fsanitize={{((array-bounds|local-bounds),?){2}"}}
+
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=all %s -### 2>&1 | FileCheck %s --check-pre

[PATCH] D15283: [ARMv8-M] Add Clang targeting for ARMv8-M Baseline/Mainline

[Bradley Smith via cfe-commits]

bsmith created this revision.
bsmith added a reviewer: t.p.northover.
bsmith added a subscriber: cfe-commits.
bsmith set the repository for this revision to rL LLVM.
Herald added subscribers: rengolin, aemerson.

This patch forms part of the ARMv8-M Baseline/Mainline support, adding Clang 
targeting for ARMv8-M Baseline/Mainline.

ARMv8-M Mainline is a superset of ARMv7-M, containing all ARMv7-M instructions 
plus ARMv8-A semaphores and atomics and the ARMv8-M security extensions.

ARMv8-M Baseline is a superset of ARMv6-M, containing all ARMv6-M instructions 
plus ARMv8-A semaphores and atomics, ARMv7-M exclusives, various code 
optimization instructions (wide branches, CBZ, hardware divide), MOVW/MOVT and 
the ARMv8-M security extensions.

Repository:
  rL LLVM

http://reviews.llvm.org/D15283

Files:
  lib/Basic/Targets.cpp
  lib/Driver/ToolChain.cpp
  lib/Driver/Tools.cpp
  test/Driver/arm-alignment.c
  test/Driver/arm-cortex-cpus.c
  test/Driver/arm-features.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
@@ -95,6 +95,43 @@
 // THUMBV8A-EABI:#define __ARM_ARCH_EXT_IDIV__ 1
 // THUMBV8A-EABI: #define __ARM_FP 0xE
 
+// RUN: %clang -target armv8m.base-none-linux-gnu -x c -E -dM %s -o - | FileCheck --check-prefix=V8M_BASELINE %s
+// V8M_BASELINE: __ARM_ARCH 8
+// V8M_BASELINE: __ARM_ARCH_8M__ 1
+// V8M_BASELINE: __ARM_ARCH_EXT_IDIV__ 1
+// V8M_BASELINE-NOT: __ARM_ARCH_ISA_ARM
+// FIXME: ABI-85 might change __ARM_ARCH_ISA_THUMB
+// V8M_BASELINE: __ARM_ARCH_ISA_THUMB 1
+// V8M_BASELINE: __ARM_ARCH_PROFILE 'B'
+// V8M_BASELINE-NOT: __ARM_FEATURE_CRC32
+// V8M_BASELINE-NOT: __ARM_FEATURE_DSP
+// V8M_BASELINE-NOT: __ARM_FP 0x{{.*}}
+// V8M_BASELINE-NOT: __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1
+
+// RUN: %clang -target armv8m.main-none-linux-gnu -x c -E -dM %s -o - | FileCheck --check-prefix=V8M_MAINLINE %s
+// V8M_MAINLINE: __ARM_ARCH 8
+// V8M_MAINLINE: __ARM_ARCH_8M__ 1
+// V8M_MAINLINE: __ARM_ARCH_EXT_IDIV__ 1
+// V8M_MAINLINE-NOT: __ARM_ARCH_ISA_ARM
+// V8M_MAINLINE: __ARM_ARCH_ISA_THUMB 2
+// V8M_MAINLINE: __ARM_ARCH_PROFILE 'M'
+// V8M_MAINLINE-NOT: __ARM_FEATURE_CRC32
+// V8M_MAINLINE-NOT: __ARM_FEATURE_DSP
+// V8M_MAINLINE: __ARM_FP 0xE
+// V8M_MAINLINE: __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
+
+// RUN: %clang -target arm-none-linux-gnu -march=armv8-m.main+dsp -x c -E -dM %s -o - | FileCheck --check-prefix=V8M_MAINLINE_DSP %s
+// V8M_MAINLINE_DSP: __ARM_ARCH 8
+// V8M_MAINLINE_DSP: __ARM_ARCH_8M__ 1
+// V8M_MAINLINE_DSP: __ARM_ARCH_EXT_IDIV__ 1
+// V8M_MAINLINE_DSP-NOT: __ARM_ARCH_ISA_ARM
+// V8M_MAINLINE_DSP: __ARM_ARCH_ISA_THUMB 2
+// V8M_MAINLINE_DSP: __ARM_ARCH_PROFILE 'M'
+// V8M_MAINLINE_DSP-NOT: __ARM_FEATURE_CRC32
+// V8M_MAINLINE_DSP: __ARM_FEATURE_DSP 1
+// V8M_MAINLINE_DSP: __ARM_FP 0xE
+// V8M_MAINLINE_DSP: __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
+
 // RUN: %clang -target arm-none-linux-gnu -x c -E -dM %s -o - | FileCheck --check-prefix=CHECK-DEFS %s
 // CHECK-DEFS:#define __ARM_PCS 1
 // CHECK-DEFS:#define __ARM_SIZEOF_MINIMAL_ENUM 4
Index: test/Driver/arm-features.c
===
--- test/Driver/arm-features.c
+++ test/Driver/arm-features.c
@@ -4,6 +4,9 @@
 // RUN: %clang -target arm-none-none-eabi -mcpu=generic+crypto -march=armv8a -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-CRYPTO %s
 // RUN: %clang -target arm-none-none-eabi -mcpu=generic -march=armv8a+crypto -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-CRYPTO %s
 // CHECK-CRYPTO: "-cc1"{{.*}} "-triple" "armv8-{{.*}} "-target-cpu" "generic"{{.*}} "-target-feature" "+crypto"
+// RUN: %clang -target arm-none-none-eabi -mcpu=generic+dsp -march=armv8m.main -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-DSP %s
+// RUN: %clang -target arm-none-none-eabi -mcpu=generic -march=armv8m.main+dsp -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-DSP %s
+// CHECK-DSP: "-cc1"{{.*}} "-triple" "thumbv8m.main-{{.*}} "-target-cpu" "generic"{{.*}} "-target-feature" "+dsp"
 
 // RUN: %clang -target arm-none-none-eabi -mcpu=generic+nocrc -march=armv8a -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-NOCRC %s
 // RUN: %clang -target arm-none-none-eabi -mcpu=generic -march=armv8a+nocrc -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-NOCRC %s
@@ -11,3 +14,6 @@
 // RUN: %clang -target arm-none-none-eabi -mcpu=generic+nocrypto -march=armv8a -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-NOCRYPTO %s
 // RUN: %clang -target arm-none-none-eabi -mcpu=generic -march=armv8a+nocrypto -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-NOCRYPTO %s
 // CHECK-NOCRYPTO: "-cc1"{{.*}} "-triple" "armv8-{{.*}} "-target-cpu" "generic"{{.*}} "-target-feature" "-crypto"
+// RUN: %clang -target arm-none-none-eabi -mcpu=generic+nodsp -march=armv8m.main -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-NODSP %s
+// RUN: %clang -target arm-none

Re: [PATCH] D15225: [Driver] Sanitizer support based on runtime library presence

[Kuba Brecka via cfe-commits]

kubabrecka added a comment.

> The one thing I'm not sure about on this is, do we really want this to be 
> darwin-only? I kinda think it might be nice if we unified this behavior 
> across all platforms.

>  ... I wonder if this can't be better abstracted.

>  I'd really like to see all operating systems have the same behavior for 
> this, so I think much of the code can be shared.

>  If the runtime library exists for a sanitizer (any sanitizer) I don't see 
> any reason clang shouldn't then support the flags.


On Darwin, the situation is easier, because all the supported sanitizers are 
dylibs.  The code to link the runtimes is very different on every platform 
(Darwin, Linux, FreeBSD, Windows).  Alexey, can you comment on this?  Does this 
change make sense for Linux as well?


http://reviews.llvm.org/D15225



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

Re: [PATCH] D12761: MPI-Checker patch for Clang Static Analyzer

[Alexander Kornienko via cfe-commits]

alexfh added a comment.

Before I can tell you whether this checker makes sense as a clang-tidy check, 
can you please explain to me (don't want to deduce this from the code) what 
specific issues does this check target? Is this limited to a set of AST 
patterns or is there (or is going to be) some path-based or data flow analysis?


http://reviews.llvm.org/D12761



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

r254903 - [OPENMP 4.5] parsing/sema support for 'grainsize' clause.

[Alexey Bataev via cfe-commits]

Author: abataev
Date: Mon Dec  7 06:52:51 2015
New Revision: 254903

URL: http://llvm.org/viewvc/llvm-project?rev=254903&view=rev
Log:
[OPENMP 4.5] parsing/sema support for 'grainsize' clause.
OpenMP 4.5 adds 'taksloop' and 'taskloop simd' directives, which have 
'grainsize' clause. Patch adds parsing/sema analysis of this clause.

Added:
cfe/trunk/test/OpenMP/taskloop_grainsize_messages.cpp
cfe/trunk/test/OpenMP/taskloop_simd_grainsize_messages.cpp
Modified:
cfe/trunk/include/clang/AST/OpenMPClause.h
cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
cfe/trunk/include/clang/Basic/OpenMPKinds.def
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/AST/StmtPrinter.cpp
cfe/trunk/lib/AST/StmtProfile.cpp
cfe/trunk/lib/Basic/OpenMPKinds.cpp
cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
cfe/trunk/lib/Parse/ParseOpenMP.cpp
cfe/trunk/lib/Sema/SemaOpenMP.cpp
cfe/trunk/lib/Sema/TreeTransform.h
cfe/trunk/lib/Serialization/ASTReaderStmt.cpp
cfe/trunk/lib/Serialization/ASTWriterStmt.cpp
cfe/trunk/test/OpenMP/taskloop_ast_print.cpp
cfe/trunk/test/OpenMP/taskloop_simd_ast_print.cpp
cfe/trunk/tools/libclang/CIndex.cpp

Modified: cfe/trunk/include/clang/AST/OpenMPClause.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/OpenMPClause.h?rev=254903&r1=254902&r2=254903&view=diff
==
--- cfe/trunk/include/clang/AST/OpenMPClause.h (original)
+++ cfe/trunk/include/clang/AST/OpenMPClause.h Mon Dec  7 06:52:51 2015
@@ -2893,6 +2893,58 @@ public:
   child_range children() { return child_range(&Priority, &Priority + 1); }
 };
 
+/// \brief This represents 'grainsize' clause in the '#pragma omp ...'
+/// directive.
+///
+/// \code
+/// #pragma omp taskloop grainsize(4)
+/// \endcode
+/// In this example directive '#pragma omp taskloop' has clause 'grainsize'
+/// with single expression '4'.
+///
+class OMPGrainsizeClause : public OMPClause {
+  friend class OMPClauseReader;
+  /// \brief Location of '('.
+  SourceLocation LParenLoc;
+  /// \brief Safe iteration space distance.
+  Stmt *Grainsize;
+
+  /// \brief Set safelen.
+  void setGrainsize(Expr *Size) { Grainsize = Size; }
+
+public:
+  /// \brief Build 'grainsize' clause.
+  ///
+  /// \param Size Expression associated with this clause.
+  /// \param StartLoc Starting location of the clause.
+  /// \param EndLoc Ending location of the clause.
+  ///
+  OMPGrainsizeClause(Expr *Size, SourceLocation StartLoc,
+ SourceLocation LParenLoc, SourceLocation EndLoc)
+  : OMPClause(OMPC_grainsize, StartLoc, EndLoc), LParenLoc(LParenLoc),
+Grainsize(Size) {}
+
+  /// \brief Build an empty clause.
+  ///
+  explicit OMPGrainsizeClause()
+  : OMPClause(OMPC_grainsize, SourceLocation(), SourceLocation()),
+LParenLoc(SourceLocation()), Grainsize(nullptr) {}
+
+  /// \brief Sets the location of '('.
+  void setLParenLoc(SourceLocation Loc) { LParenLoc = Loc; }
+  /// \brief Returns the location of '('.
+  SourceLocation getLParenLoc() const { return LParenLoc; }
+
+  /// \brief Return safe iteration space distance.
+  Expr *getGrainsize() const { return cast_or_null(Grainsize); }
+
+  static bool classof(const OMPClause *T) {
+return T->getClauseKind() == OMPC_grainsize;
+  }
+
+  child_range children() { return child_range(&Grainsize, &Grainsize + 1); }
+};
+
 /// \brief This represents 'nogroup' clause in the '#pragma omp ...' directive.
 ///
 /// \code

Modified: cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/RecursiveASTVisitor.h?rev=254903&r1=254902&r2=254903&view=diff
==
--- cfe/trunk/include/clang/AST/RecursiveASTVisitor.h (original)
+++ cfe/trunk/include/clang/AST/RecursiveASTVisitor.h Mon Dec  7 06:52:51 2015
@@ -2755,6 +2755,13 @@ bool RecursiveASTVisitor::Visit
   return true;
 }
 
+template 
+bool RecursiveASTVisitor::VisitOMPGrainsizeClause(
+OMPGrainsizeClause *C) {
+  TRY_TO(TraverseStmt(C->getGrainsize()));
+  return true;
+}
+
 // FIXME: look at the following tricky-seeming exprs to see if we
 // need to recurse on anything.  These are ones that have methods
 // returning decls or qualtypes or nestednamespecifier -- though I'm

Modified: cfe/trunk/include/clang/Basic/OpenMPKinds.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/OpenMPKinds.def?rev=254903&r1=254902&r2=254903&view=diff
==
--- cfe/trunk/include/clang/Basic/OpenMPKinds.def (original)
+++ cfe/trunk/include/clang/Basic/OpenMPKinds.def Mon Dec  7 06:52:51 2015
@@ -161,6 +161,7 @@ OPENMP_CLAUSE(map, OMPMapClause)
 OPENMP_CLAUSE(num_teams, OMPNumTeamsClause)
 OPENMP_CLAUSE(thread_limit, OMPThreadLimitClause)
 OPENMP_CLAUSE(priority, OMPPriorityClause)
+OPENMP_CLAUSE(

r254906 - [avx512] rename gcc intrinsics to be align with gcc format

[Asaf Badouh via cfe-commits]

Author: abadouh
Date: Mon Dec  7 07:14:22 2015
New Revision: 254906

URL: http://llvm.org/viewvc/llvm-project?rev=254906&view=rev
Log:
[avx512] rename gcc intrinsics to be align with gcc format
rename the gcc intrinsics suffix : _mask ->_round

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


Modified:
cfe/trunk/include/clang/Basic/BuiltinsX86.def
cfe/trunk/lib/Headers/avx512fintrin.h

Modified: cfe/trunk/include/clang/Basic/BuiltinsX86.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsX86.def?rev=254906&r1=254905&r2=254906&view=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsX86.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsX86.def Mon Dec  7 07:14:22 2015
@@ -1300,18 +1300,18 @@ TARGET_BUILTIN(__builtin_ia32_subps512_m
 TARGET_BUILTIN(__builtin_ia32_pmaddubsw512_mask, "V32sV64cV64cV32sUi", "", 
"avx512bw")
 TARGET_BUILTIN(__builtin_ia32_pmaddwd512_mask, "V16iV32sV32sV16iUs", "", 
"avx512bw")
 
-TARGET_BUILTIN(__builtin_ia32_addss_mask, "V4fV4fV4fV4fUcIi", "", "avx512f")
-TARGET_BUILTIN(__builtin_ia32_divss_mask, "V4fV4fV4fV4fUcIi", "", "avx512f")
-TARGET_BUILTIN(__builtin_ia32_mulss_mask, "V4fV4fV4fV4fUcIi", "", "avx512f")
-TARGET_BUILTIN(__builtin_ia32_subss_mask, "V4fV4fV4fV4fUcIi", "", "avx512f")
-TARGET_BUILTIN(__builtin_ia32_maxss_mask, "V4fV4fV4fV4fUcIi", "", "avx512f")
-TARGET_BUILTIN(__builtin_ia32_minss_mask, "V4fV4fV4fV4fUcIi", "", "avx512f")
-TARGET_BUILTIN(__builtin_ia32_addsd_mask, "V2dV2dV2dV2dUcIi", "", "avx512f")
-TARGET_BUILTIN(__builtin_ia32_divsd_mask, "V2dV2dV2dV2dUcIi", "", "avx512f")
-TARGET_BUILTIN(__builtin_ia32_mulsd_mask, "V2dV2dV2dV2dUcIi", "", "avx512f")
-TARGET_BUILTIN(__builtin_ia32_subsd_mask, "V2dV2dV2dV2dUcIi", "", "avx512f")
-TARGET_BUILTIN(__builtin_ia32_maxsd_mask, "V2dV2dV2dV2dUcIi", "", "avx512f")
-TARGET_BUILTIN(__builtin_ia32_minsd_mask, "V2dV2dV2dV2dUcIi", "", "avx512f")
+TARGET_BUILTIN(__builtin_ia32_addss_round, "V4fV4fV4fV4fUcIi", "", "avx512f")
+TARGET_BUILTIN(__builtin_ia32_divss_round, "V4fV4fV4fV4fUcIi", "", "avx512f")
+TARGET_BUILTIN(__builtin_ia32_mulss_round, "V4fV4fV4fV4fUcIi", "", "avx512f")
+TARGET_BUILTIN(__builtin_ia32_subss_round, "V4fV4fV4fV4fUcIi", "", "avx512f")
+TARGET_BUILTIN(__builtin_ia32_maxss_round, "V4fV4fV4fV4fUcIi", "", "avx512f")
+TARGET_BUILTIN(__builtin_ia32_minss_round, "V4fV4fV4fV4fUcIi", "", "avx512f")
+TARGET_BUILTIN(__builtin_ia32_addsd_round, "V2dV2dV2dV2dUcIi", "", "avx512f")
+TARGET_BUILTIN(__builtin_ia32_divsd_round, "V2dV2dV2dV2dUcIi", "", "avx512f")
+TARGET_BUILTIN(__builtin_ia32_mulsd_round, "V2dV2dV2dV2dUcIi", "", "avx512f")
+TARGET_BUILTIN(__builtin_ia32_subsd_round, "V2dV2dV2dV2dUcIi", "", "avx512f")
+TARGET_BUILTIN(__builtin_ia32_maxsd_round, "V2dV2dV2dV2dUcIi", "", "avx512f")
+TARGET_BUILTIN(__builtin_ia32_minsd_round, "V2dV2dV2dV2dUcIi", "", "avx512f")
 
 TARGET_BUILTIN(__builtin_ia32_addpd128_mask, "V2dV2dV2dV2dUc", "", "avx512vl")
 TARGET_BUILTIN(__builtin_ia32_addpd256_mask, "V4dV4dV4dV4dUc", "", "avx512vl")

Modified: cfe/trunk/lib/Headers/avx512fintrin.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/avx512fintrin.h?rev=254906&r1=254905&r2=254906&view=diff
==
--- cfe/trunk/lib/Headers/avx512fintrin.h (original)
+++ cfe/trunk/lib/Headers/avx512fintrin.h Mon Dec  7 07:14:22 2015
@@ -569,7 +569,7 @@ _mm512_max_ps(__m512 __A, __m512 __B)
 
 static __inline__ __m128 __DEFAULT_FN_ATTRS
 _mm_mask_max_ss(__m128 __W, __mmask8 __U,__m128 __A, __m128 __B) {
-  return (__m128) __builtin_ia32_maxss_mask ((__v4sf) __A,
+  return (__m128) __builtin_ia32_maxss_round ((__v4sf) __A,
 (__v4sf) __B,
 (__v4sf) __W,
 (__mmask8) __U,
@@ -578,7 +578,7 @@ _mm_mask_max_ss(__m128 __W, __mmask8 __U
 
 static __inline__ __m128 __DEFAULT_FN_ATTRS
 _mm_maskz_max_ss(__mmask8 __U,__m128 __A, __m128 __B) {
-  return (__m128) __builtin_ia32_maxss_mask ((__v4sf) __A,
+  return (__m128) __builtin_ia32_maxss_round ((__v4sf) __A,
 (__v4sf) __B,
 (__v4sf)  _mm_setzero_ps (),
 (__mmask8) __U,
@@ -586,20 +586,20 @@ _mm_maskz_max_ss(__mmask8 __U,__m128 __A
 }
 
 #define _mm_max_round_ss(__A, __B, __R) __extension__ ({ \
-  (__m128) __builtin_ia32_maxss_mask ((__v4sf) __A, (__v4sf) __B, \
+  (__m128) __builtin_ia32_maxss_round ((__v4sf) __A, (__v4sf) __B, \
 (__v4sf) _mm_setzero_ps(), (__mmask8) -1, __R); })
 
 #define _mm_mask_max_round_ss(__W, __U, __A, __B, __R) __extension__ ({ \
-  (__m128) __builtin_ia32_maxss_mask ((__v4sf) __A, (__v4sf) __B, \
+  (__m128) __builtin_ia32_maxss_round ((__v4sf) __A, (__v4sf) __B, \
 (__v4sf)  __W, (__mmask8) __U,__R); })
 
 #define _mm_maskz_max_round_ss(__U, __A, __B, __R) __extension__ ({ \
-  (__m128) __builtin_ia32_maxss_mask ((__v4sf) __A, (__v4sf) __B, \
+  

Re: [PATCH] D15251: [Clang] Use range loops and autos in lib/Serialization/ASTReader.cpp

[Aaron Ballman via cfe-commits]

aaron.ballman added inline comments.


Comment at: lib/Serialization/ASTReader.cpp:3390
@@ -3393,5 +3389,3 @@
 Mod->getExportedModules(Exports);
-for (SmallVectorImpl::iterator
-   I = Exports.begin(), E = Exports.end(); I != E; ++I) {
-  Module *Exported = *I;
+for (const auto &Exported : Exports) {
   if (Visited.insert(Exported).second)

hans wrote:
>   for (Module *Exported : Exports)
> 
> would be much easier to read. (And having Exported by a reference to a 
> pointer seems odd.)
> for (Module *Exported : Exports)
> would be much easier to read. (And having Exported by a reference to a 
> pointer seems odd.)

I would also find: for (const auto *Exported : Exports) to be fine, but 
definitely agree with Hans that const auto & isn't what we want here.



Comment at: lib/Serialization/ASTReader.cpp:3512
@@ -3517,5 +3511,3 @@
   // Load the AST blocks of all of the modules that we loaded.
-  for (SmallVectorImpl::iterator M = Loaded.begin(),
-  MEnd = Loaded.end();
-   M != MEnd; ++M) {
-ModuleFile &F = *M->Mod;
+  for (const auto &M : Loaded) {
+ModuleFile &F = *M.Mod;

hans wrote:
> Using a range-based for loop here is very nice, but again I'm not sure the 
> "auto" is helping.
> 
>   for (const auto &ImportedModule : ...
> 
> would be easier to read, I think.
> Using a range-based for loop here is very nice, but again I'm not sure the 
> "auto" is helping.
>
> for (const auto &ImportedModule : ...
> would be easier to read, I think.

I think const auto &M is reasonable (it fits with our usual naming 
conventions), but wouldn't complain if there were a more descriptive name used.



Comment at: lib/Serialization/ASTReader.cpp:4306
@@ -4317,3 +4305,3 @@
 case INPUT_FILE:
-  bool Overridden = static_cast(Record[3]);
+  auto Overridden = static_cast(Record[3]);
   std::string Filename = Blob;

hans wrote:
> I'd say "bool" is a better choice here.
> I'd say "bool" is a better choice here.

Agreed.


Comment at: lib/Serialization/ASTReader.cpp:5074
@@ -5087,3 +5073,3 @@
 bool operator()(ModuleFile &M) {
-  HeaderFileInfoLookupTable *Table
+  auto *Table
 = static_cast(M.HeaderFileInfoTable);

If auto doesn't shorten this sufficiently to fit on a single line, I think I 
slightly prefer HeaderFileInfoLookupTable. It's easier to figure out what Table 
is without having to go to another line in the source file to find out.


Comment at: lib/Serialization/ASTReader.cpp:5104
@@ -5117,3 +5103,3 @@
   SmallVector DiagStates;
-  for (ModuleIterator I = ModuleMgr.begin(), E = ModuleMgr.end(); I != E; ++I) 
{
-ModuleFile &F = *(*I);
+  for (const auto I : ModuleMgr) {
+ModuleFile &F = *I;

hans wrote:
> I'd spell out ModuleIterator instead of auto here.
> I'd spell out ModuleIterator instead of auto here.

I don't see a reason to do that, but I also don't like that this appears to be 
doing a copy. Is ModuleIterator a pointer? If so, this should be const auto *I 
instead. If not, const auto &.


Comment at: lib/Serialization/ASTReader.cpp:6860
@@ -6878,5 +6859,3 @@
   llvm::errs() << "\n*** PCH/Modules Loaded:";
-  for (ModuleManager::ModuleConstIterator M = ModuleMgr.begin(), 
-   MEnd = ModuleMgr.end();
-   M != MEnd; ++M)
-(*M)->dump();
+  for (const auto M : ModuleMgr)
+M->dump();

hans wrote:
> Maybe:
> 
>   for (const ModuleFile &MF : ModuleMgr)
> Maybe:
> 
> for (const ModuleFile &MF : ModuleMgr)

I don't think that naming the type adds benefit for range-based for loop 
iteration variables unless the type is really obscure. We don't name the types 
in the vast majority of places in the code base from what I can tell.


Comment at: lib/Serialization/ASTReader.cpp:7220
@@ -7240,2 +7219,3 @@
+auto *D
   = dyn_cast_or_null(GetDecl(ExtVectorDecls[I]));
 if (D)

hans wrote:
> Does this fit on one line now?
> Does this fit on one line now?

If it does not, I don't think auto is the correct type specifier to use here.


Repository:
  rL LLVM

http://reviews.llvm.org/D15251



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

Re: [PATCH] D13330: Implement __attribute__((unique_instantiation))

[Aaron Ballman via cfe-commits]

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

LGTM, but please wait for David to sign off before committing.


http://reviews.llvm.org/D13330



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

Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

[Joerg Sonnenberger via cfe-commits]

On Thu, Dec 03, 2015 at 01:36:22AM -, Richard Smith via cfe-commits wrote:
> Author: rsmith
> Date: Wed Dec  2 19:36:22 2015
> New Revision: 254574
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=254574&view=rev
> Log:
> PR17381: Treat undefined behavior during expression evaluation as an unmodeled
> side-effect, so that we don't allow speculative evaluation of such expressions
> during code generation.
> 
> This caused a diagnostic quality regression, so fix constant expression
> diagnostics to prefer either the first "can't be constant folded" diagnostic 
> or
> the first "not a constant expression" diagnostic depending on the kind of
> evaluation we're doing. This was always the intent, but didn't quite work
> correctly before.
> 
> This results in certain initializers that used to be constant initializers to
> no longer be; in particular, things like:
> 
>   float f = 1e100;
> 
> are no longer accepted in C. This seems appropriate, as such constructs would
> lead to code being executed if sanitizers are enabled.

This leads to some pretty annoying regressions as it now seems to be
impossible to use NaN or infinites as constant initializers. Expressions
like 0.0 / 0.0, 1.0 / 0.0 and -1.0 / 0.0 are perfectly well defined
under normal IEEE rules, so they shouldn't be rejected. Worse, it seems
even using __builtin_nan() for example doesn't work.

I'm not even sure about the example given in the commit message, how
exactly is that undefined behavior?

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

Re: [PATCH] D15025: [ThinLTO] Option to invoke ThinLTO backend passes and importing

[Teresa Johnson via cfe-commits]

tejohnson updated this revision to Diff 42069.
tejohnson added a comment.

- Rename -fthinlto-backend to -fthinlto-index as per review and IRC.


http://reviews.llvm.org/D15025

Files:
  include/clang/CodeGen/BackendUtil.h
  include/clang/Driver/Options.td
  include/clang/Driver/Types.h
  include/clang/Frontend/CodeGenOptions.h
  lib/CodeGen/BackendUtil.cpp
  lib/CodeGen/CodeGenAction.cpp
  lib/Driver/Tools.cpp
  lib/Driver/Types.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/CodeGen/thinlto_backend.c
  test/Driver/thinlto_backend.c

Index: test/Driver/thinlto_backend.c
===
--- /dev/null
+++ test/Driver/thinlto_backend.c
@@ -0,0 +1,10 @@
+// RUN: %clang -target x86_64-unknown-linux -O2 %s -flto=thin -c -o %t.o
+// RUN: %clang -target x86_64-unknown-linux -O2 -flto=thin -fuse-ld=gold -o %t %t.o
+
+// -fthinlto_index should be passed to cc1
+// RUN: %clang -target x86_64-unknown-linux -O2 -o %t1.o -x ir %t.o -c -fthinlto-index=%t.thinlto.bc -### 2>&1 | FileCheck %s -check-prefix=CHECK-THINLTOBE-ACTION
+// CHECK-THINLTOBE-ACTION: -fthinlto-index=
+
+// Ensure clang driver gives the expected error for incorrect input type
+// RUN: not %clang -target x86_64-unknown-linux -O2 -o %t1.o %s -c -fthinlto-index=%t.thinlto.bc 2>&1 | FileCheck %s -check-prefix=CHECK-WARNING
+// CHECK-WARNING: error: invalid argument '-fthinlto-index={{.*}}' only allowed with '-x ir'
Index: test/CodeGen/thinlto_backend.c
===
--- /dev/null
+++ test/CodeGen/thinlto_backend.c
@@ -0,0 +1,14 @@
+// RUN: %clang -target x86_64-unknown-linux -O2 %s -flto=thin -c -o %t.o
+// RUN: %clang -target x86_64-unknown-linux -O2 -flto=thin -fuse-ld=gold -o %t %t.o
+
+// Ensure clang -cc1 give expected error for incorrect input type
+// RUN: not %clang_cc1 -target x86_64-unknown-linux -O2 -o %t1.o %s -c -fthinlto-index=%t.thinlto.bc 2>&1 | FileCheck %s -check-prefix=CHECK-WARNING
+// CHECK-WARNING: error: invalid argument '-fthinlto-index={{.*}}' only allowed with '-x ir'
+
+// Ensure we get expected error for missing index file
+// RUN: %clang -target x86_64-unknown-linux -O2 -o %t1.o -x ir %t.o -c -fthinlto-index=bad.thinlto.bc 2>&1 | FileCheck %s -check-prefix=CHECK-ERROR
+// CHECK-ERROR: Error loading index file 'bad.thinlto.bc': No such file or directory
+
+// Ensure Function Importing pass added
+// RUN: %clang -target x86_64-unknown-linux -O2 -o %t1.o -x ir %t.o -c -fthinlto-index=%t.thinlto.bc -mllvm -debug-pass=Structure 2>&1 | FileCheck %s -check-prefix=CHECK-PASS
+// CHECK-PASS: Function Importing
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -521,6 +521,12 @@
   Opts.PrepareForLTO = Args.hasArg(OPT_flto, OPT_flto_EQ);
   const Arg *A = Args.getLastArg(OPT_flto, OPT_flto_EQ);
   Opts.EmitFunctionSummary = A && A->containsValue("thin");
+  if (Arg *A = Args.getLastArg(OPT_fthinlto_index_EQ)) {
+if (IK != IK_LLVM_IR)
+  Diags.Report(diag::err_drv_argument_only_allowed_with)
+  << A->getAsString(Args) << "-x ir";
+Opts.ThinLTOIndexFile = Args.getLastArgValue(OPT_fthinlto_index_EQ);
+  }
 
   Opts.MSVolatile = Args.hasArg(OPT_fms_volatile);
 
Index: lib/Driver/Types.cpp
===
--- lib/Driver/Types.cpp
+++ lib/Driver/Types.cpp
@@ -128,6 +128,19 @@
   }
 }
 
+bool types::isLLVMIR(ID Id) {
+  switch (Id) {
+  default:
+return false;
+
+  case TY_LLVM_IR:
+  case TY_LLVM_BC:
+  case TY_LTO_IR:
+  case TY_LTO_BC:
+return true;
+  }
+}
+
 bool types::isCuda(ID Id) {
   switch (Id) {
   default:
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -3413,6 +3413,13 @@
   Args.AddLastArg(CmdArgs, options::OPT_flto, options::OPT_flto_EQ);
   }
 
+  if (const Arg *A = Args.getLastArg(options::OPT_fthinlto_index_EQ)) {
+if (!types::isLLVMIR(Input.getType()))
+  D.Diag(diag::err_drv_argument_only_allowed_with) << A->getAsString(Args)
+   << "-x ir";
+Args.AddLastArg(CmdArgs, options::OPT_fthinlto_index_EQ);
+  }
+
   // We normally speed up the clang process a bit by skipping destructors at
   // exit, but when we're generating diagnostics we can rely on some of the
   // cleanup.
Index: lib/CodeGen/CodeGenAction.cpp
===
--- lib/CodeGen/CodeGenAction.cpp
+++ lib/CodeGen/CodeGenAction.cpp
@@ -26,10 +26,12 @@
 #include "llvm/IR/DebugInfo.h"
 #include "llvm/IR/DiagnosticInfo.h"
 #include "llvm/IR/DiagnosticPrinter.h"
+#include "llvm/IR/FunctionInfo.h"
 #include "llvm/IR/LLVMContext.h"
 #include "llvm/IR/Module.h"
 #include "llvm/IRReader/IRReader.h"
 #include "llvm/Linker/Linker.h"

Re: [PATCH] D15220: [OPENMP] dist_schedule clause for distribute directive

[Carlo Bertolli via cfe-commits]

carlo.bertolli updated this revision to Diff 42070.
carlo.bertolli added a comment.

Added regression test.


Repository:
  rL LLVM

http://reviews.llvm.org/D15220

Files:
  include/clang/AST/OpenMPClause.h
  include/clang/AST/RecursiveASTVisitor.h
  include/clang/Basic/OpenMPKinds.def
  include/clang/Basic/OpenMPKinds.h
  include/clang/Sema/Sema.h
  lib/AST/StmtPrinter.cpp
  lib/AST/StmtProfile.cpp
  lib/Basic/OpenMPKinds.cpp
  lib/CodeGen/CGStmtOpenMP.cpp
  lib/Parse/ParseOpenMP.cpp
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReaderStmt.cpp
  lib/Serialization/ASTWriterStmt.cpp
  test/OpenMP/distribute_dist_schedule_messages.cpp
  tools/libclang/CIndex.cpp

Index: tools/libclang/CIndex.cpp
===
--- tools/libclang/CIndex.cpp
+++ tools/libclang/CIndex.cpp
@@ -2196,6 +2196,11 @@
 void OMPClauseEnqueue::VisitOMPMapClause(const OMPMapClause *C) {
   VisitOMPClauseList(C);
 }
+void OMPClauseEnqueue::VisitOMPDistScheduleClause(
+const OMPDistScheduleClause *C) {
+  Visitor->AddStmt(C->getChunkSize());
+  Visitor->AddStmt(C->getHelperChunkSize());
+}
 }
 
 void EnqueueVisitor::EnqueueChildren(const OMPClause *S) {
Index: test/OpenMP/distribute_dist_schedule_messages.cpp
===
--- /dev/null
+++ test/OpenMP/distribute_dist_schedule_messages.cpp
@@ -0,0 +1,35 @@
+// RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 -verify -fopenmp -ferror-limit 100 -o - %s
+
+void foo() {
+}
+
+bool foobool(int argc) {
+  return argc;
+}
+
+struct S1; // expected-note {{declared here}}
+
+int main(int argc, char **argv) {
+  #pragma omp distribute dist_schedule // expected-error {{expected '(' after 'dist_schedule'}}
+  for (int i = 0; i < 10; ++i) foo();
+  #pragma omp distribute dist_schedule ( // expected-error {{expected 'static' in OpenMP clause 'dist_schedule'}} expected-error {{expected ')'}} expected-note {{to match this '('}}
+  for (int i = 0; i < 10; ++i) foo();
+  #pragma omp distribute dist_schedule () // expected-error {{expected 'static' in OpenMP clause 'dist_schedule'}}
+  for (int i = 0; i < 10; ++i) foo();
+  #pragma omp distribute dist_schedule (static // expected-error {{expected ')'}} expected-note {{to match this '('}}
+  for (int i = 0; i < 10; ++i) foo();
+  #pragma omp distribute dist_schedule (static, // expected-error {{expected expression}} expected-error {{expected ')'}} expected-note {{to match this '('}}
+  for (int i = 0; i < 10; ++i) foo();
+  #pragma omp distribute dist_schedule (argc)) // expected-error {{expected 'static' in OpenMP clause 'dist_schedule'}} expected-warning {{extra tokens at the end of '#pragma omp distribute' are ignored}}
+  for (int i = 0; i < 10; ++i) foo();
+  #pragma omp distribute dist_schedule (static, argc > 0 ? argv[1] : argv[2]) // expected-error {{expression must have integral or unscoped enumeration type, not 'char *'}}
+  for (int i = 0; i < 10; ++i) foo();
+  #pragma omp distribute dist_schedule (static), dist_schedule (static, 1) // expected-error {{directive '#pragma omp distribute' cannot contain more than one 'dist_schedule' clause}}
+  for (int i = 0; i < 10; ++i) foo();
+  #pragma omp distribute dist_schedule (static, S1) // expected-error {{'S1' does not refer to a value}}
+  for (int i = 0; i < 10; ++i) foo();
+  #pragma omp distribute dist_schedule (static, argv[1]=2) // expected-error {{expression must have integral or unscoped enumeration type, not 'char *'}} expected-error {{expected ')'}} expected-note {{to match this '('}}
+  for (int i = 0; i < 10; ++i) foo();
+
+  return 0;
+}
Index: lib/Serialization/ASTWriterStmt.cpp
===
--- lib/Serialization/ASTWriterStmt.cpp
+++ lib/Serialization/ASTWriterStmt.cpp
@@ -2016,6 +2016,15 @@
   Writer->Writer.AddSourceLocation(C->getLParenLoc(), Record);
 }
 
+void OMPClauseWriter::VisitOMPDistScheduleClause(OMPDistScheduleClause *C) {
+  Record.push_back(C->getDistScheduleKind());
+  Writer->Writer.AddStmt(C->getChunkSize());
+  Writer->Writer.AddStmt(C->getHelperChunkSize());
+  Writer->Writer.AddSourceLocation(C->getLParenLoc(), Record);
+  Writer->Writer.AddSourceLocation(C->getDistScheduleKindLoc(), Record);
+  Writer->Writer.AddSourceLocation(C->getCommaLoc(), Record);
+}
+
 //===--===//
 // OpenMP Directives.
 //===--===//
Index: lib/Serialization/ASTReaderStmt.cpp
===
--- lib/Serialization/ASTReaderStmt.cpp
+++ lib/Serialization/ASTReaderStmt.cpp
@@ -1859,6 +1859,9 @@
   case OMPC_priority:
 C = new (Context) OMPPriorityClause();
 break;
+  case OMPC_dist_schedule:
+C = new (Context) OMPDistScheduleClause();
+break;
   }
   Visit(C);
   C->setLocStart(Reader->ReadSourceLocatio

Re: [PATCH] D13731: [Analyzer] Supporting function attributes in .model files.

[pierre gousseau via cfe-commits]

pgousseau added a comment.

In http://reviews.llvm.org/D13731#302989, @zaks.anna wrote:

> Pierre,
>
> Have you seen the post about API Notes?
>  http://llvm.cc/t/cfe-dev-clang-and-swift/331
>
> I believe using API notes would be a better approach for adding annotations. 
> By the time the static analyzer sees the AST, the annotations would already 
> be there. The API Notes should already seamlessly work for nullability 
> annotations. Does that work for you? (Do we still need some parts of this 
> patch? I am not sure.)


Thanks for pointing it out! It is not clear yet if APINotes is suited for our 
problematic, will need to ask some questions first on the "Clang and Swift" 
cfe-dev thread.

> A related topic is deciding what type of attributes should be used by the 
> static analyzer checkers. Currently, there are 2 options, neither of which is 
> ideal:

> 

> 1. Extend clang with new attributes for static analyzes. This is not highly 
> desirable because the clang attributes namespace will get polluted and 
> compiler users might start using them. This approach is also not convenient 
> for proprietary checkers.

> 2. Annotate attribute (AnnotateAttr) is used in some places; however, this 
> attribute creeps into LLVMIR, which caused problems in the past.

> 

>   The best approach would be to put all analyzer attributes behind "a fence" 
> so that we could add/remove them without worrying that compiler(not analyzer) 
> users depend on them. The attribute would not be CodeGened.

> 

>   Here what it might look like: analyzer_annotate(family, arg…) family: id 
> arg: [id=] value value:  number | string | id

> 

>   Is anyone interested in implementing this?


The "analyzer_annotate" idea sounds good, I would need to do more evaluation 
before deciding this is suitable for us though.


http://reviews.llvm.org/D13731



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

Re: [PATCH] D15025: [ThinLTO] Option to invoke ThinLTO backend passes and importing

[Mehdi AMINI via cfe-commits]

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

LGTM, thanks!


http://reviews.llvm.org/D15025



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

Re: [PATCH] D12761: MPI-Checker patch for Clang Static Analyzer

[Anna Zaks via cfe-commits]

zaks.anna added a comment.

This patch contains a mix of checks, some are path sensitive and some are AST 
checks. See MPICheckerAST.cpp for the latter.


http://reviews.llvm.org/D12761



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

Re: [PATCH] D13330: Implement __attribute__((unique_instantiation))

[David Majnemer via cfe-commits]

majnemer added inline comments.


Comment at: include/clang/Basic/AttrDocs.td:1736-1755
@@ -1722,2 +1735,22 @@
+
+// Explicit template definition (in exactly ONE .cpp file)
+template struct __attribute__((unique_instantiation)) my_template;
+
+
+When the unique_instantiation attribute is specified on an explicit template
+instantiation, the compiler is given license to emit strong symbols for
+this specific explicit template instantiation.
+
+If the attribute is present on one such definition or declaration for a given
+entity, it must be present on all.
+
+Note that to ensure correct execution the user MUST make certain that no
+other translation unit has an implicit instantiation of the same entity. In
+particular this means that any usage of the entity has to be preceeded by an
+appropriate explicit template declaration or definition.
 
+It is thus recommended that explicit template declarations are placed in 
headers
+to suppress any potential implicit instantiation of the entity. In order to
+encourage this programming style, any explicit template definition with this
+attribute MUST be preceeded by an appropriate declaration.
   }];

Instead of using all-caps for emphasis in "ONE" and "MUST", why not bold the 
text instead?  It would catch the eye a little faster.


Comment at: include/clang/Basic/DiagnosticSemaKinds.td:2533-2534
@@ -2531,1 +2532,4 @@
   ":must be between 1 and %2}2">;
+def err_unique_instantiation_wrong_decl : Error<
+  "'unique_instantiation' attribute only applies to an explicit template 
declaration or instantiation">;
+def err_unique_instantiation_no_declaration : Error<

I can't seem to see any users of `err_unique_instantiation_wrong_decl`.


Comment at: lib/AST/ASTContext.cpp:8283-8286
@@ +8282,6 @@
+Context.containedInUniqueInstantiation(FD)) {
+  // We return GVA_StrongExternal here, instead of going through the logic
+  // below, because even if the definition is available inline, since the
+  // source specified  an explicit template instantiation, we want to make
+  // the symbol available.
+  return GVA_StrongExternal;

There are a lot of commas here, making it a little hard to read the 
justification.

Perhaps something along the lines of:

> This translation unit is responsible for emitting a unique instantiation of 
> this function regardless of whether or not the function is marked inline.


Comment at: lib/CodeGen/CGVTables.cpp:744-747
@@ -743,2 +743,6 @@
   case TSK_ExplicitInstantiationDefinition:
+// If the key function has strong linkage (say due to
+// UniqueInstantiationAttr), the VTable should too.
+if (Context.containedInUniqueInstantiation(keyFunction))
+  return llvm::GlobalVariable::ExternalLinkage;
 return !Context.getLangOpts().AppleKext ?

What if the key function is not contained within a record which is marked as 
`UniqueInstantiationAttr` but the key function itself is marked 
`UniqueInstantiationAttr`?


http://reviews.llvm.org/D13330



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

[PATCH] D15293: [OpenCL] Correct NULL constant handling after applying default AS

[Anastasia Stulova via cfe-commits]

Anastasia created this revision.
Anastasia added a reviewer: pekka.jaaskelainen.
Anastasia added a subscriber: cfe-commits.

In OpenCL2.0 s6.5 all pointers are implicitly in generic address space unless 
address space is explicitly specified.

Correct the behavior of NULL constant detection - generic AS void pointer 
should be accepted as a valid NULL constant.

http://reviews.llvm.org/D15293

Files:
  lib/AST/Expr.cpp
  lib/Sema/SemaExpr.cpp
  test/SemaOpenCL/null_literal.cl

Index: test/SemaOpenCL/null_literal.cl
===
--- /dev/null
+++ test/SemaOpenCL/null_literal.cl
@@ -0,0 +1,29 @@
+// RUN: %clang_cc1 -verify %s
+// RUN: %clang_cc1 -cl-std=CL2.0 -DCL20 -verify %s
+
+#define NULL ((void*)0)
+
+void foo(){
+
+global int* ptr1 = NULL;
+
+global int* ptr2 = (global void*)0;
+
+constant int* ptr3 = NULL;
+
+constant int* ptr4 = (global void*)0; // expected-error{{initializing 
'__constant int *' with an expression of type '__global void *' changes address 
space of pointer}}
+
+#ifdef CL20
+// accept explicitly pointer to generic address space in OpenCL v2.0
+global int* ptr5 = (generic void*)0;
+#endif
+
+global int* ptr6 = (local void*)0; // expected-error{{initializing '__global 
int *' with an expression of type '__local void *' changes address space of 
pointer}}
+
+bool cmp = ptr1 == NULL;
+
+cmp = ptr1 == (local void*)0; // expected-error{{comparison between  
('__global int *' and '__local void *') which are pointers to non-overlapping 
address spaces}}
+
+cmp = ptr3 == NULL;
+
+}
Index: lib/Sema/SemaExpr.cpp
===
--- lib/Sema/SemaExpr.cpp
+++ lib/Sema/SemaExpr.cpp
@@ -8807,7 +8807,8 @@
   diagnoseDistinctPointerComparison(*this, Loc, LHS, RHS, 
/*isError*/false);
 }
 if (LCanPointeeTy != RCanPointeeTy) {
-  if (getLangOpts().OpenCL) {
+  // Treat NULL constant as a special case in OpenCL
+  if (getLangOpts().OpenCL && !LHSIsNull && !RHSIsNull) {
 const PointerType *LHSPtr = LHSType->getAs();
 if 
(!LHSPtr->isAddressSpaceOverlapping(*RHSType->getAs())) {
   Diag(Loc,
Index: lib/AST/Expr.cpp
===
--- lib/AST/Expr.cpp
+++ lib/AST/Expr.cpp
@@ -3261,9 +3261,20 @@
   // Check that it is a cast to void*.
   if (const PointerType *PT = CE->getType()->getAs()) {
 QualType Pointee = PT->getPointeeType();
-if (!Pointee.hasQualifiers() &&
-Pointee->isVoidType() &&  // to void*
-CE->getSubExpr()->getType()->isIntegerType()) // from int.
+Qualifiers Q = Pointee.getQualifiers();
+// in OpenCL v2.0 generic address space acts as a placeholder
+// and should be ignored.
+bool IsASValid = true;
+if (Ctx.getLangOpts().OpenCLVersion >= 200) {
+  if (Pointee.getAddressSpace() == LangAS::opencl_generic)
+Q.removeAddressSpace();
+  else
+IsASValid = false;
+}
+
+if (IsASValid && !Q.hasQualifiers() &&
+Pointee->isVoidType() &&  // to void*
+CE->getSubExpr()->getType()->isIntegerType()) // from int.
   return CE->getSubExpr()->isNullPointerConstant(Ctx, NPC);
   }
 }


Index: test/SemaOpenCL/null_literal.cl
===
--- /dev/null
+++ test/SemaOpenCL/null_literal.cl
@@ -0,0 +1,29 @@
+// RUN: %clang_cc1 -verify %s
+// RUN: %clang_cc1 -cl-std=CL2.0 -DCL20 -verify %s
+
+#define NULL ((void*)0)
+
+void foo(){
+
+global int* ptr1 = NULL;
+
+global int* ptr2 = (global void*)0;
+
+constant int* ptr3 = NULL;
+
+constant int* ptr4 = (global void*)0; // expected-error{{initializing '__constant int *' with an expression of type '__global void *' changes address space of pointer}}
+
+#ifdef CL20
+// accept explicitly pointer to generic address space in OpenCL v2.0
+global int* ptr5 = (generic void*)0;
+#endif
+
+global int* ptr6 = (local void*)0; // expected-error{{initializing '__global int *' with an expression of type '__local void *' changes address space of pointer}}
+
+bool cmp = ptr1 == NULL;
+
+cmp = ptr1 == (local void*)0; // expected-error{{comparison between  ('__global int *' and '__local void *') which are pointers to non-overlapping address spaces}}
+
+cmp = ptr3 == NULL;
+
+}
Index: lib/Sema/SemaExpr.cpp
===
--- lib/Sema/SemaExpr.cpp
+++ lib/Sema/SemaExpr.cpp
@@ -8807,7 +8807,8 @@
   diagnoseDistinctPointerComparison(*this, Loc, LHS, RHS, /*isError*/false);
 }
 if (LCanPointeeTy != RCanPointeeTy) {
-  if (getLangOpts().OpenCL) {
+  // Treat NULL constant as a special case in OpenCL
+  if (getLangOpts().OpenCL && !LHSIsNull && !RHSIsNull) {
 const PointerType *LHSPtr = LHSType->getAs();
 if (!LH

Re: [PATCH] D14441: [OpenCL] Pipe types support.

[Anastasia Stulova via cfe-commits]

Anastasia added a comment.

I've made a few small comments. Don't see any reply though.


http://reviews.llvm.org/D14441



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

RE: [Patch][OpenCL] Custom atomic Builtin check ignores address space of a non-atomic pointer

[Anastasia Stulova via cfe-commits]

Could someone jump in, please!

I have made a small improvement in testing after the patch has been first 
approved by Pekka.

The last change is essentially this:

Index: test/CodeGen/atomic-ops.c
===
--- test/CodeGen/atomic-ops.c   (revision 250025)
+++ test/CodeGen/atomic-ops.c   (working copy)
@@ -1,10 +1,10 @@
-// RUN: %clang_cc1 %s -emit-llvm -o - -ffreestanding 
-triple=i686-apple-darwin9 | FileCheck %s
+// RUN: %clang_cc1 %s -emit-llvm -o - -ffreestanding -ffake-address-space-map 
-triple=i686-apple-darwin9 | FileCheck %s
 // REQUIRES: x86-registered-target
 
 // Also test serialization of atomic operations here, to avoid duplicating the
 // test.
-// RUN: %clang_cc1 %s -emit-pch -o %t -ffreestanding -triple=i686-apple-darwin9
-// RUN: %clang_cc1 %s -include-pch %t -ffreestanding 
-triple=i686-apple-darwin9 -emit-llvm -o - | FileCheck %s
+// RUN: %clang_cc1 %s -emit-pch -o %t -ffreestanding -ffake-address-space-map 
-triple=i686-apple-darwin9
+// RUN: %clang_cc1 %s -include-pch %t -ffreestanding -ffake-address-space-map 
-triple=i686-apple-darwin9 -emit-llvm -o - | FileCheck %s
 #ifndef ALREADY_INCLUDED
 #define ALREADY_INCLUDED
 
@@ -155,6 +155,14 @@
   return atomic_compare_exchange_strong(i, &cmp, 1);
 }
 
+#define _AS1 __attribute__((address_space(1)))
+_Bool fi4d(_Atomic(int) *i, int _AS1 *ptr2) {
+  // CHECK-LABEL: @fi4d(
+  // CHECK: [[EXPECTED:%[.0-9A-Z_a-z]+]] = load i32, i32 addrspace(1)* 
%{{[0-9]+}}
+  // CHECK: cmpxchg i32* %{{[0-9]+}}, i32 [[EXPECTED]], i32 %{{[0-9]+}} 
acquire acquire
+  return __c11_atomic_compare_exchange_strong(i, ptr2, 1, 
memory_order_acquire, memory_order_acquire);
+}
+
 float ff1(_Atomic(float) *d) {
   // CHECK-LABEL: @ff1
   // CHECK: load atomic i32, i32* {{.*}} monotonic


Thank you!

Anastasia

-Original Message-
From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of 
Anastasia Stulova via cfe-commits
Sent: 23 November 2015 10:32
To: cfe-commits@lists.llvm.org; 'Pekka Jääskeläinen'
Subject: RE: [Patch][OpenCL] Custom atomic Builtin check ignores address space 
of a non-atomic pointer

Ping! Re-attaching the final patch.

-Original Message-
From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of 
Anastasia Stulova via cfe-commits
Sent: 21 October 2015 11:49
To: 'Pekka Jääskeläinen'; cfe-commits@lists.llvm.org
Subject: RE: [Patch][OpenCL] Custom atomic Builtin check ignores address space 
of a non-atomic pointer

Hi Pekka,

Are you ok with this change?

Thanks,
Anastasia

-Original Message-
From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of 
Anastasia Stulova via cfe-commits
Sent: 12 October 2015 16:00
To: 'Pekka Jääskeläinen'; cfe-commits@lists.llvm.org
Subject: RE: [Patch][OpenCL] Custom atomic Builtin check ignores address space 
of a non-atomic pointer

I have just made one minor update in the CodeGen test 
(test/CodeGen/atomic-ops.c) that is now checking the IR output rather than only 
making sure frontend doesn't crash.

The final patch is attached here!

Thanks,
Anastasia
 

-Original Message-
From: Pekka Jääskeläinen [mailto:pekka.jaaskelai...@tut.fi]
Sent: 02 October 2015 10:20
To: Anastasia Stulova; cfe-commits@lists.llvm.org
Subject: Re: [Patch][OpenCL] Custom atomic Builtin check ignores address space 
of a non-atomic pointer

LGTM.

Related to it:
There has been so many getPointerTo() issues with multi-AS in the past that I 
wonder if it'd be time to drop the default value from it, and go through all 
the places where it's called with the default AS, thus breaking multi-AS.  
Might be a worthwhile job to do at some point.

On 09/30/2015 01:23 PM, Anastasia Stulova via cfe-commits wrote:
> Hi all,
>
> Address spaces are not handled in custom semantic checks of atomic Builtins.
>
> If there are two pointers passed to the Builtin, it doesn't allow the 
> second
>
> (non-atomic) one to be qualified with an address space.
>
> This patch removed this restriction by recording the address space of 
> the
>
> passed pointers while checking its type correctness.
>
> Currently, the following code:
>
> _Atomic int __attribute__((address_space(1))) *A;
>
> int __attribute__((address_space(2))) *B;
>
> ...
>
> ... = __c11_atomic_compare_exchange_strong(A, B, 1, 
> memory_order_seq_cst, memory_order_seq_cst);
>
> fails to compile with an error:
>
> "passing '__attribute__((address_space(2))) int *' to parameter of 
> type 'int *' changes address space of pointer".
>
> Please, review the attached fix for it!
>
> Cheers,
>
> Anastasia
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>

--
Pekka



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

Re: [PATCH] D13330: Implement __attribute__((unique_instantiation))

[Keno Fischer via cfe-commits]

loladiro added inline comments.


Comment at: include/clang/Basic/AttrDocs.td:1736-1755
@@ -1722,2 +1735,22 @@
+
+// Explicit template definition (in exactly ONE .cpp file)
+template struct __attribute__((unique_instantiation)) my_template;
+
+
+When the unique_instantiation attribute is specified on an explicit template
+instantiation, the compiler is given license to emit strong symbols for
+this specific explicit template instantiation.
+
+If the attribute is present on one such definition or declaration for a given
+entity, it must be present on all.
+
+Note that to ensure correct execution the user MUST make certain that no
+other translation unit has an implicit instantiation of the same entity. In
+particular this means that any usage of the entity has to be preceeded by an
+appropriate explicit template declaration or definition.
 
+It is thus recommended that explicit template declarations are placed in 
headers
+to suppress any potential implicit instantiation of the entity. In order to
+encourage this programming style, any explicit template definition with this
+attribute MUST be preceeded by an appropriate declaration.
   }];

majnemer wrote:
> Instead of using all-caps for emphasis in "ONE" and "MUST", why not bold the 
> text instead?  It would catch the eye a little faster.
Sure! I assume, this follows standard RST conventions where ** is bold?


Comment at: include/clang/Basic/DiagnosticSemaKinds.td:2533-2534
@@ -2531,1 +2532,4 @@
   ":must be between 1 and %2}2">;
+def err_unique_instantiation_wrong_decl : Error<
+  "'unique_instantiation' attribute only applies to an explicit template 
declaration or instantiation">;
+def err_unique_instantiation_no_declaration : Error<

majnemer wrote:
> I can't seem to see any users of `err_unique_instantiation_wrong_decl`.
Yes, it was replaced by adding a case to err_attribute_wrong_decl_type above. 
Will remove.


Comment at: lib/AST/ASTContext.cpp:8283-8286
@@ +8282,6 @@
+Context.containedInUniqueInstantiation(FD)) {
+  // We return GVA_StrongExternal here, instead of going through the logic
+  // below, because even if the definition is available inline, since the
+  // source specified  an explicit template instantiation, we want to make
+  // the symbol available.
+  return GVA_StrongExternal;

majnemer wrote:
> There are a lot of commas here, making it a little hard to read the 
> justification.
> 
> Perhaps something along the lines of:
> 
> > This translation unit is responsible for emitting a unique instantiation of 
> > this function regardless of whether or not the function is marked inline.
Sounds good.


Comment at: lib/CodeGen/CGVTables.cpp:744-747
@@ -743,2 +743,6 @@
   case TSK_ExplicitInstantiationDefinition:
+// If the key function has strong linkage (say due to
+// UniqueInstantiationAttr), the VTable should too.
+if (Context.containedInUniqueInstantiation(keyFunction))
+  return llvm::GlobalVariable::ExternalLinkage;
 return !Context.getLangOpts().AppleKext ?

majnemer wrote:
> What if the key function is not contained within a record which is marked as 
> `UniqueInstantiationAttr` but the key function itself is marked 
> `UniqueInstantiationAttr`?
I don't know, I'd be inclined to say the unique instantiation does not apply to 
the vtable unless it's explicit on the class, but I'd be open to differing 
opinions.


http://reviews.llvm.org/D13330



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

LLVM buildmaster outage during the weekend

[Galina Kistanova via cfe-commits]

Hello everyone,

There was LLVM buildmaster outage during the weekend. Sorry about this.
It seems llvm lab outgrow consumer-grade router and should be updated later
or sooner.
I will look more at this what could be done about this.

Thanks

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

Re: [PATCH] D15173: [Preprocessor] Fix assertion in AnnotatePreviousCachedTokens

[Bruno Cardoso Lopes via cfe-commits]

bruno added a comment.

Ping!


http://reviews.llvm.org/D15173



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

Re: [PATCH] D15225: [Driver] Sanitizer support based on runtime library presence

[Alexey Samsonov via cfe-commits]

samsonov added inline comments.


Comment at: include/clang/Driver/ToolChain.h:410
@@ -407,1 +409,3 @@
+  /// (don't require runtime library).
+  virtual SanitizerMask getSanitizersRequiringTrap() const;
 };

I don't think this is relevant to ToolChain at all. `SanitizerArgs` has 
`TrappingSupported` mask, which is what you should need: if you don't have 
runtimes for all sanitizers you're enabling, and *some* of these sanitizers 
support trapping, driver may advise to use this flag.


Comment at: lib/Driver/ToolChains.cpp:360
@@ +359,3 @@
+  StringRef OS = "";
+  if (isTargetMacOS()) OS = "osx";
+  if (isTargetWatchOSSimulator()) OS = "watchossim";

Can we teach ToolChain (or at least Darwin toolchain) to return us OS name 
instead?


Comment at: lib/Driver/ToolChains.cpp:369
@@ +368,3 @@
+
+  return (Twine("libclang_rt.") + Sanitizer + "_" + OS + "_dynamic.dylib")
+  .str();

Oh no, please don't return a `StringRef` which points to temporary.


Comment at: test/Driver/fsanitize.c:14
@@ +13,3 @@
+// RUN: %clang -target x86_64-apple-darwin10 
-resource-dir=%S/Inputs/resource_dir -fsanitize=undefined %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-UNDEFINED-DARWIN1
+// CHECK-UNDEFINED-DARWIN1: error: '-fsanitize-trap=undefined' required with 
'-fsanitize=undefined' option
+// RUN: %clang -target x86_64-apple-darwin10 
-resource-dir=%S/Inputs/resource_dir_darwin_sanitizers -fsanitize=undefined %s 
-### 2>&1 | FileCheck %s --check-prefix=CHECK-UNDEFINED-DARWIN2

I find this diagnostic misleading :-/ It's not the case that 
`-fsanitize=undefined` *requires* you to additionally provide 
`-fsanitize-trap=undefined`. It requires having a UBSan runtime library 
available. Or, if you can't provide it (it's not available on your system), you 
can workaround this by using `-fsanitize-trap`. The latter should be a 
suggestion, really.


Comment at: test/Driver/fsanitize.c:33
@@ -30,3 +32,3 @@
 
-// RUN: %clang -fsanitize=bounds -### -fsyntax-only %s 2>&1 | FileCheck %s 
--check-prefix=CHECK-BOUNDS
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=bounds -### -fsyntax-only 
%s 2>&1 | FileCheck %s --check-prefix=CHECK-BOUNDS
 // CHECK-BOUNDS: "-fsanitize={{((array-bounds|local-bounds),?){2}"}}

Nice catch, please commit this fix as a separate change.


Comment at: test/Driver/fsanitize.c:214
@@ -205,3 +213,3 @@
 
-// RUN: %clang -target x86_64-apple-darwin10 -fsanitize=memory %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-MSAN-DARWIN
+// RUN: %clang -target x86_64-apple-darwin10 
-resource-dir=%S/Inputs/resource_dir -fsanitize=memory %s -### 2>&1 | FileCheck 
%s --check-prefix=CHECK-MSAN-DARWIN
 // CHECK-MSAN-DARWIN: unsupported option '-fsanitize=memory' for target 
'x86_64-apple-darwin10'

Why not resource_dir_darwin_sanitizers here and below?


Comment at: test/Driver/fsanitize.c:221
@@ +220,3 @@
+// RUN: %clang -target x86_64-apple-darwin10 
-resource-dir=%S/Inputs/resource_dir -fsanitize=memory -fsanitize=thread,memory 
%s -### 2>&1 | FileCheck %s --check-prefix=CHECK-MSAN-TSAN-MSAN-DARWIN1
+// CHECK-MSAN-TSAN-MSAN-DARWIN1: unsupported option '-fsanitize=thread,memory' 
for target 'x86_64-apple-darwin10'
+// CHECK-MSAN-TSAN-MSAN-DARWIN1-NOT: unsupported option

Again, I feel like we're lying to users here: `-fsanitize=thread` *is* 
supported for this target, it just requires building a runtime.


http://reviews.llvm.org/D15225



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

Re: [PATCH] D15120: Add support for __float128 type to be used by targets that support it

[Argyrios Kyrtzidis via cfe-commits]

> On Dec 7, 2015, at 12:16 AM, John McCall  wrote:
> 
> rjmccall added a reviewer: akyrtzi.
> 
> 
> Comment at: lib/AST/ASTContext.cpp:5424
> @@ -5410,1 +5423,3 @@
> +// FIXME: need to figure out what this is for __float128
> +case BuiltinType::Float128:   return 'K';
> case BuiltinType::NullPtr:return '*'; // like char*
> 
> Please add this as a case to the block below for Half.  I'll ping internally 
> for a decision on what @encoding to use.
> 
> 
> Comment at: lib/Index/USRGeneration.cpp:604
> @@ -602,1 +603,3 @@
> +case BuiltinType::Float128:
> +  c = ' '; break;
> case BuiltinType::NullPtr:
> 
> I'm pretty sure you can just choose something here that doesn't collide, but 
> the right person to ask is Argyrios.

Indeed; I don’t have a preference, just something that doesn’t collide.

> 
> 
> Repository:
>  rL LLVM
> 
> http://reviews.llvm.org/D15120
> 
> 
> 

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

Re: [PATCH] D15223: [ARM] [AARCH64] Add CodeGen IR tests for {VS}QRDML{AS}H v8.1a intrinsics.

[Eric Christopher via cfe-commits]

echristo added a comment.

One inline comment, thanks!

-eric



Comment at: test/CodeGen/aarch64-v8.1a-neon-intrinsics.c:4
@@ -3,4 +3,3 @@
 // RUN: %clang_cc1 -triple aarch64-linux-gnu -target-feature +neon \
-// RUN:  -target-feature +v8.1a -O3 -S -o - %s \
-// RUN:  | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-AARCH64
+// RUN:  -target-feature +v8.1a -O1 -S -emit-llvm -o - %s | FileCheck %s
 

Why do you need to enable the optimizers?


http://reviews.llvm.org/D15223



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

Re: [PATCH] D15225: [Driver] Sanitizer support based on runtime library presence

[Kuba Brecka via cfe-commits]

kubabrecka added inline comments.


Comment at: test/Driver/fsanitize.c:221
@@ +220,3 @@
+// RUN: %clang -target x86_64-apple-darwin10 
-resource-dir=%S/Inputs/resource_dir -fsanitize=memory -fsanitize=thread,memory 
%s -### 2>&1 | FileCheck %s --check-prefix=CHECK-MSAN-TSAN-MSAN-DARWIN1
+// CHECK-MSAN-TSAN-MSAN-DARWIN1: unsupported option '-fsanitize=thread,memory' 
for target 'x86_64-apple-darwin10'
+// CHECK-MSAN-TSAN-MSAN-DARWIN1-NOT: unsupported option

samsonov wrote:
> Again, I feel like we're lying to users here: `-fsanitize=thread` *is* 
> supported for this target, it just requires building a runtime.
I'd like to see this from the point-of-view of a binary distribution.  If the 
binary distribution (e.g. the one from llvm.org or Apple's Clang in Xcode) 
doesn't contain a runtime library, then the sanitizer is *not* supported in 
that distribution.  Also, see http://reviews.llvm.org/D14846, we'd like to have 
CMake options to select which runtimes will be built.  If you deliberately 
choose not to build ThreadSanitizer, then that sanitizer is *not* supported in 
your version of Clang.  If you're experimenting and porting a runtime to a new 
platform, then this sanitizer *is* supported in your version of Clang.


http://reviews.llvm.org/D15225



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

r254927 - [ThinLTO] Option to invoke ThinLTO backend passes and importing

[Teresa Johnson via cfe-commits]

Author: tejohnson
Date: Mon Dec  7 13:21:34 2015
New Revision: 254927

URL: http://llvm.org/viewvc/llvm-project?rev=254927&view=rev
Log:
[ThinLTO] Option to invoke ThinLTO backend passes and importing

Summary:
Adds new option -fthinlto-index= to invoke the LTO pipeline
along with function importing via clang using the supplied function
summary index file. This supports invoking the parallel ThinLTO
backend processes in a distributed build environment via clang.

Additionally, this causes the module linker to be invoked on the bitcode
file being compiled to perform any necessary promotion and renaming of
locals that are exported via the function summary index file.

Add a couple tests that confirm we get expected errors when we try to
use the new option on a file that isn't bitcode, or specify an invalid
index file. The tests also confirm that we trigger the expected function
import pass.

Depends on D15024

Reviewers: joker.eph, dexonsmith

Subscribers: joker.eph, davidxl, cfe-commits

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

Added:
cfe/trunk/test/CodeGen/thinlto_backend.c
cfe/trunk/test/Driver/thinlto_backend.c
Modified:
cfe/trunk/include/clang/CodeGen/BackendUtil.h
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/include/clang/Driver/Types.h
cfe/trunk/include/clang/Frontend/CodeGenOptions.h
cfe/trunk/lib/CodeGen/BackendUtil.cpp
cfe/trunk/lib/CodeGen/CodeGenAction.cpp
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/lib/Driver/Types.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/CMakeLists.txt

Modified: cfe/trunk/include/clang/CodeGen/BackendUtil.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/CodeGen/BackendUtil.h?rev=254927&r1=254926&r2=254927&view=diff
==
--- cfe/trunk/include/clang/CodeGen/BackendUtil.h (original)
+++ cfe/trunk/include/clang/CodeGen/BackendUtil.h Mon Dec  7 13:21:34 2015
@@ -11,6 +11,8 @@
 #define LLVM_CLANG_CODEGEN_BACKENDUTIL_H
 
 #include "clang/Basic/LLVM.h"
+#include "llvm/IR/FunctionInfo.h"
+#include 
 
 namespace llvm {
   class Module;
@@ -31,10 +33,12 @@ namespace clang {
 Backend_EmitObj///< Emit native object files
   };
 
-  void EmitBackendOutput(DiagnosticsEngine &Diags, const CodeGenOptions 
&CGOpts,
- const TargetOptions &TOpts, const LangOptions &LOpts,
- StringRef TDesc, llvm::Module *M, BackendAction 
Action,
- raw_pwrite_stream *OS);
+  void
+  EmitBackendOutput(DiagnosticsEngine &Diags, const CodeGenOptions &CGOpts,
+const TargetOptions &TOpts, const LangOptions &LOpts,
+StringRef TDesc, llvm::Module *M, BackendAction Action,
+raw_pwrite_stream *OS,
+std::unique_ptr Index = nullptr);
 }
 
 #endif

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=254927&r1=254926&r2=254927&view=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Mon Dec  7 13:21:34 2015
@@ -693,6 +693,9 @@ def flto : Flag<["-"], "flto">, Flags<[C
   HelpText<"Enable LTO in 'full' mode">;
 def fno_lto : Flag<["-"], "fno-lto">, Group,
   HelpText<"Disable LTO mode (default)">;
+def fthinlto_index_EQ : Joined<["-"], "fthinlto-index=">,
+  Flags<[CC1Option]>, Group,
+  HelpText<"Perform ThinLTO importing using provided function summary index">;
 def fmacro_backtrace_limit_EQ : Joined<["-"], "fmacro-backtrace-limit=">,
 Group, Flags<[DriverOption, 
CoreOption]>;
 def fmerge_all_constants : Flag<["-"], "fmerge-all-constants">, Group;

Modified: cfe/trunk/include/clang/Driver/Types.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Types.h?rev=254927&r1=254926&r2=254927&view=diff
==
--- cfe/trunk/include/clang/Driver/Types.h (original)
+++ cfe/trunk/include/clang/Driver/Types.h Mon Dec  7 13:21:34 2015
@@ -63,6 +63,9 @@ namespace types {
   /// isCXX - Is this a "C++" input (C++ and Obj-C++ sources and headers).
   bool isCXX(ID Id);
 
+  /// Is this LLVM IR.
+  bool isLLVMIR(ID Id);
+
   /// isCuda - Is this a CUDA input.
   bool isCuda(ID Id);
 

Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.h?rev=254927&r1=254926&r2=254927&view=diff
==
--- cfe/trunk/include/clang/Frontend/CodeGenOptions.h (original)
+++ cfe/trunk/include/clang/Frontend/CodeGenOptions.h Mon Dec  7 13:21:34 2015
@@ -167,6 +167,10 @@ public:
   /// Name of the profile file to use 

Re: [PATCH] D15025: [ThinLTO] Option to invoke ThinLTO backend passes and importing

[Teresa Johnson via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL254927: [ThinLTO] Option to invoke ThinLTO backend passes 
and importing (authored by tejohnson).

Changed prior to commit:
  http://reviews.llvm.org/D15025?vs=42069&id=42084#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D15025

Files:
  cfe/trunk/include/clang/CodeGen/BackendUtil.h
  cfe/trunk/include/clang/Driver/Options.td
  cfe/trunk/include/clang/Driver/Types.h
  cfe/trunk/include/clang/Frontend/CodeGenOptions.h
  cfe/trunk/lib/CodeGen/BackendUtil.cpp
  cfe/trunk/lib/CodeGen/CodeGenAction.cpp
  cfe/trunk/lib/Driver/Tools.cpp
  cfe/trunk/lib/Driver/Types.cpp
  cfe/trunk/lib/Frontend/CompilerInvocation.cpp
  cfe/trunk/test/CMakeLists.txt
  cfe/trunk/test/CodeGen/thinlto_backend.c
  cfe/trunk/test/Driver/thinlto_backend.c

Index: cfe/trunk/lib/Frontend/CompilerInvocation.cpp
===
--- cfe/trunk/lib/Frontend/CompilerInvocation.cpp
+++ cfe/trunk/lib/Frontend/CompilerInvocation.cpp
@@ -521,6 +521,12 @@
   Opts.PrepareForLTO = Args.hasArg(OPT_flto, OPT_flto_EQ);
   const Arg *A = Args.getLastArg(OPT_flto, OPT_flto_EQ);
   Opts.EmitFunctionSummary = A && A->containsValue("thin");
+  if (Arg *A = Args.getLastArg(OPT_fthinlto_index_EQ)) {
+if (IK != IK_LLVM_IR)
+  Diags.Report(diag::err_drv_argument_only_allowed_with)
+  << A->getAsString(Args) << "-x ir";
+Opts.ThinLTOIndexFile = Args.getLastArgValue(OPT_fthinlto_index_EQ);
+  }
 
   Opts.MSVolatile = Args.hasArg(OPT_fms_volatile);
 
Index: cfe/trunk/lib/CodeGen/CodeGenAction.cpp
===
--- cfe/trunk/lib/CodeGen/CodeGenAction.cpp
+++ cfe/trunk/lib/CodeGen/CodeGenAction.cpp
@@ -26,10 +26,12 @@
 #include "llvm/IR/DebugInfo.h"
 #include "llvm/IR/DiagnosticInfo.h"
 #include "llvm/IR/DiagnosticPrinter.h"
+#include "llvm/IR/FunctionInfo.h"
 #include "llvm/IR/LLVMContext.h"
 #include "llvm/IR/Module.h"
 #include "llvm/IRReader/IRReader.h"
 #include "llvm/Linker/Linker.h"
+#include "llvm/Object/FunctionIndexObjectFile.h"
 #include "llvm/Pass.h"
 #include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/SourceMgr.h"
@@ -39,6 +41,24 @@
 using namespace llvm;
 
 namespace clang {
+/// Diagnostic handler used by invocations of Linker::LinkModules
+static void linkerDiagnosticHandler(const DiagnosticInfo &DI,
+const llvm::Module *LinkModule,
+DiagnosticsEngine &Diags) {
+  if (DI.getSeverity() != DS_Error)
+return;
+
+  std::string MsgStorage;
+  {
+raw_string_ostream Stream(MsgStorage);
+DiagnosticPrinterRawOStream DP(Stream);
+DI.print(DP);
+  }
+
+  Diags.Report(diag::err_fe_cannot_link_module)
+  << LinkModule->getModuleIdentifier() << MsgStorage;
+}
+
   class BackendConsumer : public ASTConsumer {
 virtual void anchor();
 DiagnosticsEngine &Diags;
@@ -167,7 +187,7 @@
 llvm::Module *LinkModule = I.second.get();
 if (Linker::linkModules(*M, *LinkModule,
 [=](const DiagnosticInfo &DI) {
-  linkerDiagnosticHandler(DI, LinkModule);
+  linkerDiagnosticHandler(DI, LinkModule, Diags);
 },
 LinkFlags))
   return;
@@ -233,9 +253,6 @@
   ((BackendConsumer*)Context)->InlineAsmDiagHandler2(SM, Loc);
 }
 
-void linkerDiagnosticHandler(const llvm::DiagnosticInfo &DI,
- const llvm::Module *LinkModule);
-
 static void DiagnosticHandler(const llvm::DiagnosticInfo &DI,
   void *Context) {
   ((BackendConsumer *)Context)->DiagnosticHandlerImpl(DI);
@@ -545,22 +562,6 @@
   EmitOptimizationMessage(D, diag::warn_fe_backend_optimization_failure);
 }
 
-void BackendConsumer::linkerDiagnosticHandler(const DiagnosticInfo &DI,
-  const llvm::Module *LinkModule) {
-  if (DI.getSeverity() != DS_Error)
-return;
-
-  std::string MsgStorage;
-  {
-raw_string_ostream Stream(MsgStorage);
-DiagnosticPrinterRawOStream DP(Stream);
-DI.print(DP);
-  }
-
-  Diags.Report(diag::err_fe_cannot_link_module)
-  << LinkModule->getModuleIdentifier() << MsgStorage;
-}
-
 /// \brief This function is invoked when the backend needs
 /// to report something to the user.
 void BackendConsumer::DiagnosticHandlerImpl(const DiagnosticInfo &DI) {
@@ -785,11 +786,44 @@
   TheModule->setTargetTriple(TargetOpts.Triple);
 }
 
+auto DiagHandler = [&](const DiagnosticInfo &DI) {
+  linkerDiagnosticHandler(DI, TheModule.get(),
+  getCompilerInstance().getDiagnostics());
+};
+
+// If we are performing ThinLTO importing compilation (indicated by
+// a non-empty index file option), then we need promote to global 

Re: [PATCH] D15174: [MSVC] Fix for http://llvm.org/PR25636: indexed accessor property not supported correctly.

[John McCall via cfe-commits]

rjmccall added a comment.

Oh, I see, of course.

It would be clearer if you asked the subclass which value to use abstractly 
(i.e. independently of the actual set expression) and then passed down 
captureSetValueAsResult=false when the subclass says to use the setter result.


http://reviews.llvm.org/D15174



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

r254933 - clang-format: Make wrapping after "./->" cheaper, even if the element

[Daniel Jasper via cfe-commits]

Author: djasper
Date: Mon Dec  7 13:50:48 2015
New Revision: 254933

URL: http://llvm.org/viewvc/llvm-project?rev=254933&view=rev
Log:
clang-format: Make wrapping after "./->" cheaper, even if the element
before it is not a closing parenthesis.

Otherwise, this frequently leads to "hanging" indents that users
perceive as "weird".

Before:
  return !soome_map.insert(
   )
  .second;

After:
  return !soome_map
  .insert()
  .second;

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=254933&r1=254932&r2=254933&view=diff
==
--- cfe/trunk/lib/Format/TokenAnnotator.cpp (original)
+++ cfe/trunk/lib/Format/TokenAnnotator.cpp Mon Dec  7 13:50:48 2015
@@ -1743,10 +1743,20 @@ unsigned TokenAnnotator::splitPenalty(co
 return 2;
 
   if (Right.isMemberAccess()) {
-if (Left.is(tok::r_paren) && Left.MatchingParen &&
-Left.MatchingParen->ParameterCount > 0)
-  return 20; // Should be smaller than breaking at a nested comma.
-return 150;
+// Breaking before the "./->" of a chained call/member access is reasonably
+// cheap, as formatting those with one call per line is generally
+// desirable. In particular, it should be cheaper to break before the call
+// than it is to break inside a call's parameters, which could lead to 
weird
+// "hanging" indents. The exception is the very last "./->" to support this
+// frequent pattern:
+//
+//   ..bbb().c(
+//   );
+//
+// which might otherwise be blown up onto many lines. Here, clang-format
+// won't produce "hanging" indents anyway as there is no other trailing
+// call.
+return Right.LastOperator ? 150 : 40;
   }
 
   if (Right.is(TT_TrailingAnnotation) &&

Modified: cfe/trunk/unittests/Format/FormatTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTest.cpp?rev=254933&r1=254932&r2=254933&view=diff
==
--- cfe/trunk/unittests/Format/FormatTest.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTest.cpp Mon Dec  7 13:50:48 2015
@@ -3341,7 +3341,7 @@ TEST_F(FormatTest, LineBreakingInBinaryE
   verifyFormat("aa = aaa(aaa, // break\n"
" aa) >>\n"
" bb;");
-  verifyFormat("Whitespaces.addUntouchableComment(\n"
+  verifyFormat("aa = Whitespaces.addUntouchableComment(\n"
"SourceMgr.getSpellingColumnNumber(\n"
"TheLine.Last->FormatTok.Tok.getLocation()) -\n"
"1);");
@@ -4157,10 +4157,14 @@ TEST_F(FormatTest, FormatsBuilderPattern
   verifyFormat("return a->a().a().aa() <\n"
"   aaa->a().a().aa();");
   verifyFormat(
-  "aaa->aaa->(\n"
+  "aaa->aaa->aaa(\n"
   "aa)\n"
   "->(aaa);");
   verifyFormat(
+  "aaa->aaa\n"
+  "
->aaa(aaa)\n"
+  "->(aaa);");
+  verifyFormat(
   "aaa()->aa(b)->aaa( // break\n"
   "aa);");
   verifyFormat(
@@ -4224,6 +4228,12 @@ TEST_F(FormatTest, FormatsBuilderPattern
   // Prefer not to break after empty parentheses.
   verifyFormat("FirstToken->WhitespaceRange.getBegin().getLocWithOffset(\n"
"First->LastNewlineOffset);");
+
+  // Prefer not to create "hanging" indents.
+  verifyFormat(
+  "return !soome_map\n"
+  ".insert()\n"
+  ".second;");
 }
 
 TEST_F(FormatTest, BreaksAccordingToOperatorPrecedence) {
@@ -7373,8 +7383,8 @@ TEST_F(FormatTest, FormatObjCMethodExpr)
"aa];");
   verifyFormat("[aaa.[a]\n"
"aa];");
-  verifyFormat("[call .aa....\n"
-   ".];", // FIXME: Indentation seems off.
+  verifyFormat("[call .aa...\n"
+   "..];", // FIXME: Indentation seems off.
getLLVMStyleWithColumns(60));
 
   verifyFormat(


___

Re: [PATCH] D15251: [Clang] Use range loops and autos in lib/Serialization/ASTReader.cpp

[Eugene Zelenko via cfe-commits]

Eugene.Zelenko removed rL LLVM as the repository for this revision.
Eugene.Zelenko updated this revision to Diff 42087.
Eugene.Zelenko added a comment.

I fixed two loops and don't use auto instead of bool.

Auto is also used for results of new.


http://reviews.llvm.org/D15251

Files:
  lib/Serialization/ASTReader.cpp

Index: lib/Serialization/ASTReader.cpp
===
--- lib/Serialization/ASTReader.cpp
+++ lib/Serialization/ASTReader.cpp
@@ -1,4 +1,4 @@
-//===-- ASTReader.cpp - AST File Reader --===//
+//===-- ASTReader.cpp - AST File Reader -*- C++ -*-===//
 //
 // The LLVM Compiler Infrastructure
 //
@@ -64,7 +64,6 @@
 using namespace clang::serialization::reader;
 using llvm::BitstreamCursor;
 
-
 //===--===//
 // ChainedASTReaderListener implementation
 //===--===//
@@ -334,7 +333,7 @@
 MacroDefinitionsMap;
   typedef llvm::DenseMap >
 DeclsMap;
-}
+} // anonymous namespace
 
 static bool checkDiagnosticGroupMappings(DiagnosticsEngine &StoredDiags,
  DiagnosticsEngine &Diags,
@@ -656,13 +655,10 @@
   OwnsDeserializationListener = TakeOwnership;
 }
 
-
-
 unsigned ASTSelectorLookupTrait::ComputeHash(Selector Sel) {
   return serialization::ComputeHash(Sel);
 }
 
-
 std::pair
 ASTSelectorLookupTrait::ReadKeyDataLength(const unsigned char*& d) {
   using namespace llvm::support;
@@ -1241,7 +1237,7 @@
   FileCharacter = (SrcMgr::CharacteristicKind)Record[2];
 FileID FID = SourceMgr.createFileID(File, IncludeLoc, FileCharacter,
 ID, BaseOffset + Record[0]);
-SrcMgr::FileInfo &FileInfo =
+auto &FileInfo =
   const_cast(SourceMgr.getSLocEntry(FID).getFile());
 FileInfo.NumCreatedFIDs = Record[5];
 if (Record[3])
@@ -1473,7 +1469,7 @@
 PreprocessingRecord &PPRec = *PP.getPreprocessingRecord();
 PreprocessingRecord::PPEntityID PPID =
 PPRec.getPPEntityID(GlobalID - 1, /*isLoaded=*/true);
-MacroDefinitionRecord *PPDef = cast_or_null(
+auto *PPDef = cast_or_null(
 PPRec.getPreprocessedEntity(PPID));
 if (PPDef)
   PPRec.RegisterMacroDefinition(Macro, PPDef);
@@ -1727,7 +1723,7 @@
 // files.
 IdentifierInfo *getIdentifierInfo() const { return Found; }
   };
-}
+} // anonymous namespace
 
 void ASTReader::updateOutOfDateIdentifier(IdentifierInfo &II) {
   // Note that we are loading an identifier.
@@ -3347,7 +3343,7 @@
 D->Hidden = false;
 
 if (wasHidden && SemaObj) {
-  if (ObjCMethodDecl *Method = dyn_cast(D)) {
+  if (auto *Method = dyn_cast(D)) {
 moveMethodToBackOfGlobalList(*SemaObj, Method);
   }
 }
@@ -3391,9 +3387,7 @@
 // Push any exported modules onto the stack to be marked as visible.
 SmallVector Exports;
 Mod->getExportedModules(Exports);
-for (SmallVectorImpl::iterator
-   I = Exports.begin(), E = Exports.end(); I != E; ++I) {
-  Module *Exported = *I;
+for (auto *Exported : Exports) {
   if (Visited.insert(Exported).second)
 Stack.push_back(Exported);
 }
@@ -3515,10 +3509,8 @@
   // Here comes stuff that we only do once the entire chain is loaded.
 
   // Load the AST blocks of all of the modules that we loaded.
-  for (SmallVectorImpl::iterator M = Loaded.begin(),
-  MEnd = Loaded.end();
-   M != MEnd; ++M) {
-ModuleFile &F = *M->Mod;
+  for (const auto &ImportedModule : Loaded) {
+ModuleFile &F = *ImportedModule.Mod;
 
 // Read the AST block.
 if (ASTReadResult Result = ReadASTBlock(F, ClientLoadCapabilities))
@@ -3549,7 +3541,7 @@
 // Preload all the pending interesting identifiers by marking them out of
 // date.
 for (auto Offset : F.PreloadIdentifierOffsets) {
-  const unsigned char *Data = reinterpret_cast(
+  auto *Data = reinterpret_cast(
   F.IdentifierTableData + Offset);
 
   ASTIdentifierLookupTrait Trait(*this, F);
@@ -3575,20 +3567,18 @@
 
   // Setup the import locations and notify the module manager that we've
   // committed to these module files.
-  for (SmallVectorImpl::iterator M = Loaded.begin(),
-  MEnd = Loaded.end();
-   M != MEnd; ++M) {
-ModuleFile &F = *M->Mod;
+  for (const auto &M : Loaded) {
+ModuleFile &F = *M.Mod;
 
 ModuleMgr.moduleFileAccepted(&F);
 
 // Set the import location.
 F.DirectImportLoc = ImportLoc;
-if (!M->ImportedBy)
-  F.ImportLoc = M->ImportLoc;
+if (!M.ImportedBy)
+  F.ImportLoc = M.ImportLoc;
 else
-  F.ImportLoc = ReadSourceLocation(*M->ImportedBy,
-   M->ImportLoc.getRawEncoding());
+

Re: [PATCH] D15251: [Clang] Use range loops and autos in lib/Serialization/ASTReader.cpp

[Eugene Zelenko via cfe-commits]

Eugene.Zelenko added inline comments.


Comment at: lib/Serialization/ASTReader.cpp:5074
@@ -5087,3 +5073,3 @@
 bool operator()(ModuleFile &M) {
-  HeaderFileInfoLookupTable *Table
+  auto *Table
 = static_cast(M.HeaderFileInfoTable);

I don't think it's good idea to make coding practices depending on formatting. 


http://reviews.llvm.org/D15251



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

r254935 - AST: defer to TypeLoc::copy in TypeLoc::initializeFullCopy

[Justin Bogner via cfe-commits]

Author: bogner
Date: Mon Dec  7 14:04:57 2015
New Revision: 254935

URL: http://llvm.org/viewvc/llvm-project?rev=254935&view=rev
Log:
AST: defer to TypeLoc::copy in TypeLoc::initializeFullCopy

If we're initializing a TypeLoc from one that's been allocated with
different alignment, memcpy will get the padding wrong. The `copy`
method already checks and handles this case, so we should just defer
to it.

This also drops the `const` off of the `initializeFullCopy`
declarations, since it isn't even remotely true (and the compiler
notices when we try to call copy() instead of tricking it with
memcpy).

Fixes llvm.org/pr23516.

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

Modified: cfe/trunk/include/clang/AST/TypeLoc.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/TypeLoc.h?rev=254935&r1=254934&r2=254935&view=diff
==
--- cfe/trunk/include/clang/AST/TypeLoc.h (original)
+++ cfe/trunk/include/clang/AST/TypeLoc.h Mon Dec  7 14:04:57 2015
@@ -170,19 +170,18 @@ public:
 
   /// \brief Initializes this by copying its information from another
   /// TypeLoc of the same type.
-  void initializeFullCopy(TypeLoc Other) const {
+  void initializeFullCopy(TypeLoc Other) {
 assert(getType() == Other.getType());
-size_t Size = getFullDataSize();
-memcpy(getOpaqueData(), Other.getOpaqueData(), Size);
+copy(Other);
   }
 
   /// \brief Initializes this by copying its information from another
   /// TypeLoc of the same type.  The given size must be the full data
   /// size.
-  void initializeFullCopy(TypeLoc Other, unsigned Size) const {
+  void initializeFullCopy(TypeLoc Other, unsigned Size) {
 assert(getType() == Other.getType());
 assert(getFullDataSize() == Size);
-memcpy(getOpaqueData(), Other.getOpaqueData(), Size);
+copy(Other);
   }
 
   /// Copies the other type loc into this one.


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

Re: [PATCH] D15251: [Clang] Use range loops and autos in lib/Serialization/ASTReader.cpp

[Aaron Ballman via cfe-commits]

aaron.ballman added inline comments.


Comment at: lib/Serialization/ASTReader.cpp:5074
@@ -5087,3 +5073,3 @@
 bool operator()(ModuleFile &M) {
-  HeaderFileInfoLookupTable *Table
+  auto *Table
 = static_cast(M.HeaderFileInfoTable);

Eugene.Zelenko wrote:
> I don't think it's good idea to make coding practices depending on 
> formatting. 
> I don't think it's good idea to make coding practices depending on formatting.

I disagree. The use of auto is only when it adds to readability of the code. 
We've distilled this down to cases where the type is obvious due to already 
being stated in the initialization of the variable. If that initialization 
means I have to look somewhere else to see the actual type, then the benefit of 
auto is reduced.


http://reviews.llvm.org/D15251



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

r254938 - Adjust test to fix bot error from r254927.

[Teresa Johnson via cfe-commits]

Author: tejohnson
Date: Mon Dec  7 14:26:57 2015
New Revision: 254938

URL: http://llvm.org/viewvc/llvm-project?rev=254938&view=rev
Log:
Adjust test to fix bot error from r254927.

Remove the part of the error message that may vary across systems.

Modified:
cfe/trunk/test/CodeGen/thinlto_backend.c

Modified: cfe/trunk/test/CodeGen/thinlto_backend.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/thinlto_backend.c?rev=254938&r1=254937&r2=254938&view=diff
==
--- cfe/trunk/test/CodeGen/thinlto_backend.c (original)
+++ cfe/trunk/test/CodeGen/thinlto_backend.c Mon Dec  7 14:26:57 2015
@@ -7,7 +7,7 @@
 
 // Ensure we get expected error for missing index file
 // RUN: %clang -target x86_64-unknown-linux -O2 -o %t1.o -x ir %t.o -c 
-fthinlto-index=bad.thinlto.bc 2>&1 | FileCheck %s -check-prefix=CHECK-ERROR
-// CHECK-ERROR: Error loading index file 'bad.thinlto.bc': No such file or 
directory
+// CHECK-ERROR: Error loading index file 'bad.thinlto.bc'
 
 // Ensure Function Importing pass added
 // RUN: %clang -target x86_64-unknown-linux -O2 -o %t1.o -x ir %t.o -c 
-fthinlto-index=%t.thinlto.bc -mllvm -debug-pass=Structure 2>&1 | FileCheck %s 
-check-prefix=CHECK-PASS


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

Re: [PATCH] D15173: [Preprocessor] Fix assertion in AnnotatePreviousCachedTokens

[Argyrios Kyrtzidis via cfe-commits]

Hi Bruno,

> On Dec 2, 2015, at 7:29 PM, Bruno Cardoso Lopes  
> wrote:
> 
> bruno created this revision.
> bruno added reviewers: doug.gregor, akyrtzi.
> bruno added subscribers: cfe-commits, dexonsmith.
> 
> Consider the following ObjC++ snippet:
> 
>  @protocol PA;
>  @protocol PB;
> 
>  @class NSArray;
>  typedef int some_t;
> 
>  id FA(NSArray> *h, some_t group);
> 
> This would hit an assertion in the parser after generating an annotation 
> token while
> trying to update the token cache:
> 
> Assertion failed: (CachedTokens[CachedLexPos-1].getLastLoc() == 
> Tok.getAnnotationEndLoc() && "The annotation should be until the most recent 
> cached token")
> ...
> 7  clang::Preprocessor::AnnotatePreviousCachedTokens(clang::Token const&) + 
> 494
> 8  clang::Parser::TryAnnotateTypeOrScopeTokenAfterScopeSpec(bool, bool, 
> clang::CXXScopeSpec&, bool) + 1163
> 9  clang::Parser::TryAnnotateTypeOrScopeToken(bool, bool) + 361
> 10 clang::Parser::isCXXDeclarationSpecifier(clang::Parser::TPResult, bool*) + 
> 598
> ...
> 
> The cached preprocessor token in this case is:
> 
> greatergreater '>>' Loc= 
> 
> while the annotation ("NSArray>") ends at "testcase.mm:7:25", hence 
> the assertion.
> The mismatch only happens because of the cached token length and the 
> assertion should account for that.
> 
> http://reviews.llvm.org/D15173
> 
> Files:
>  lib/Lex/PPCaching.cpp
>  test/Parser/objcxx11-protocol-in-template.mm
> 
> Index: test/Parser/objcxx11-protocol-in-template.mm
> ===
> --- test/Parser/objcxx11-protocol-in-template.mm
> +++ test/Parser/objcxx11-protocol-in-template.mm
> @@ -8,3 +8,11 @@
> 
> vector> v;
> vector>> v2;
> +
> +@protocol PA;
> +@protocol PB;
> +
> +@class NSArray;
> +typedef int some_t;
> +
> +id FA(NSArray> *h, some_t group);
> Index: lib/Lex/PPCaching.cpp
> ===
> --- lib/Lex/PPCaching.cpp
> +++ lib/Lex/PPCaching.cpp
> @@ -97,8 +97,19 @@
> void Preprocessor::AnnotatePreviousCachedTokens(const Token &Tok) {
>   assert(Tok.isAnnotation() && "Expected annotation token");
>   assert(CachedLexPos != 0 && "Expected to have some cached tokens");
> -  assert(CachedTokens[CachedLexPos-1].getLastLoc() == 
> Tok.getAnnotationEndLoc()
> - && "The annotation should be until the most recent cached token");
> +
> +  // The annotation should be until the most recent cached token. Since
> +  // `Tok` length could be bigger than one (e.g. greatergreater '>>'), 
> account
> +  // for that cases before checking the assertion.
> +  Token CachedLastTok = CachedTokens[CachedLexPos - 1];
> +  unsigned CachedLastTokLoc = CachedLastTok.getLastLoc().getRawEncoding();
> +  unsigned TokAnnEndLoc = Tok.getAnnotationEndLoc().getRawEncoding();
> +  if (CachedLastTokLoc != TokAnnEndLoc && !CachedLastTok.isAnnotation())
> +CachedLastTokLoc += CachedLastTok.getLength() - 1;
> +  (void)CachedLastTokLoc;
> +  (void)TokAnnEndLoc;
> +  assert(CachedLastTokLoc == TokAnnEndLoc &&
> + "The annotation should be until the most recent cached token");
> 
>   // Start from the end of the cached tokens list and look for the token
>   // that is the beginning of the annotation token.

This would be better to be wrapped inside a "#ifndef NDEBUG” section.
Also the above is a bit ad-hoc, not quite general.

How about doing something like:

Token CachedLastTok = CachedTokens[CachedLexPos - 1];
unsigned CachedLastTokLoc = 
CachedLastTok.getLastLoc().getLocWithOffset(CachedLastTok.getLength())

unsigned TokAnnEndLoc =  Tok.getAnnotationEndLoc();
unsigned TokAnnEndLocSize =  
Lexer:::MeasureTokenLength(SourceMgr.getSpellingLoc(Tok.getAnnotationEndLoc()))
TokAnnEndLocSize = TokAnnEndLoc.getLocWithOffset(TokAnnEndLocSize)


and compare the locations ? The above tries to account for possible different 
token sizes but the end locations should be the same.


> 
> 
> 

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

Re: [PATCH] D15173: [Preprocessor] Fix assertion in AnnotatePreviousCachedTokens

[Argyrios Kyrtzidis via cfe-commits]

akyrtzi added a subscriber: akyrtzi.
akyrtzi added a comment.

Hi Bruno,


http://reviews.llvm.org/D15173



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

Re: [PATCH] D14980: PR18513: make gcc compatible layout for bit-fields with explicit aligned attribute

[Dmitry Polukhin via cfe-commits]

DmitryPolukhin added a comment.

Added TODO, any other comments or suggestions?


http://reviews.llvm.org/D14980



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

r254940 - Remove target specifier from new tests

[Teresa Johnson via cfe-commits]

Author: tejohnson
Date: Mon Dec  7 14:40:36 2015
New Revision: 254940

URL: http://llvm.org/viewvc/llvm-project?rev=254940&view=rev
Log:
Remove target specifier from new tests

Hopefully fix the remaining bot failure from r254927. Remove
target specification since it shouldn't be needed, and this causes
an error when trying to check the pass execution structure in
test/CodeGen/thinlto_backend.c on non-x86 arches.

Modified:
cfe/trunk/test/CodeGen/thinlto_backend.c
cfe/trunk/test/Driver/thinlto_backend.c

Modified: cfe/trunk/test/CodeGen/thinlto_backend.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/thinlto_backend.c?rev=254940&r1=254939&r2=254940&view=diff
==
--- cfe/trunk/test/CodeGen/thinlto_backend.c (original)
+++ cfe/trunk/test/CodeGen/thinlto_backend.c Mon Dec  7 14:40:36 2015
@@ -1,14 +1,14 @@
-// RUN: %clang -target x86_64-unknown-linux -O2 %s -flto=thin -c -o %t.o
+// RUN: %clang -O2 %s -flto=thin -c -o %t.o
 // RUN: llvm-lto -thinlto -o %t %t.o
 
 // Ensure clang -cc1 give expected error for incorrect input type
-// RUN: not %clang_cc1 -target x86_64-unknown-linux -O2 -o %t1.o %s -c 
-fthinlto-index=%t.thinlto.bc 2>&1 | FileCheck %s -check-prefix=CHECK-WARNING
+// RUN: not %clang_cc1 -O2 -o %t1.o %s -c -fthinlto-index=%t.thinlto.bc 2>&1 | 
FileCheck %s -check-prefix=CHECK-WARNING
 // CHECK-WARNING: error: invalid argument '-fthinlto-index={{.*}}' only 
allowed with '-x ir'
 
 // Ensure we get expected error for missing index file
-// RUN: %clang -target x86_64-unknown-linux -O2 -o %t1.o -x ir %t.o -c 
-fthinlto-index=bad.thinlto.bc 2>&1 | FileCheck %s -check-prefix=CHECK-ERROR
+// RUN: %clang -O2 -o %t1.o -x ir %t.o -c -fthinlto-index=bad.thinlto.bc 2>&1 
| FileCheck %s -check-prefix=CHECK-ERROR
 // CHECK-ERROR: Error loading index file 'bad.thinlto.bc'
 
 // Ensure Function Importing pass added
-// RUN: %clang -target x86_64-unknown-linux -O2 -o %t1.o -x ir %t.o -c 
-fthinlto-index=%t.thinlto.bc -mllvm -debug-pass=Structure 2>&1 | FileCheck %s 
-check-prefix=CHECK-PASS
+// RUN: %clang -O2 -o %t1.o -x ir %t.o -c -fthinlto-index=%t.thinlto.bc -mllvm 
-debug-pass=Structure 2>&1 | FileCheck %s -check-prefix=CHECK-PASS
 // CHECK-PASS: Function Importing

Modified: cfe/trunk/test/Driver/thinlto_backend.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/thinlto_backend.c?rev=254940&r1=254939&r2=254940&view=diff
==
--- cfe/trunk/test/Driver/thinlto_backend.c (original)
+++ cfe/trunk/test/Driver/thinlto_backend.c Mon Dec  7 14:40:36 2015
@@ -1,10 +1,10 @@
-// RUN: %clang -target x86_64-unknown-linux -O2 %s -flto=thin -c -o %t.o
+// RUN: %clang -O2 %s -flto=thin -c -o %t.o
 // RUN: llvm-lto -thinlto -o %t %t.o
 
 // -fthinlto_index should be passed to cc1
-// RUN: %clang -target x86_64-unknown-linux -O2 -o %t1.o -x ir %t.o -c 
-fthinlto-index=%t.thinlto.bc -### 2>&1 | FileCheck %s 
-check-prefix=CHECK-THINLTOBE-ACTION
+// RUN: %clang -O2 -o %t1.o -x ir %t.o -c -fthinlto-index=%t.thinlto.bc -### 
2>&1 | FileCheck %s -check-prefix=CHECK-THINLTOBE-ACTION
 // CHECK-THINLTOBE-ACTION: -fthinlto-index=
 
 // Ensure clang driver gives the expected error for incorrect input type
-// RUN: not %clang -target x86_64-unknown-linux -O2 -o %t1.o %s -c 
-fthinlto-index=%t.thinlto.bc 2>&1 | FileCheck %s -check-prefix=CHECK-WARNING
+// RUN: not %clang -O2 -o %t1.o %s -c -fthinlto-index=%t.thinlto.bc 2>&1 | 
FileCheck %s -check-prefix=CHECK-WARNING
 // CHECK-WARNING: error: invalid argument '-fthinlto-index={{.*}}' only 
allowed with '-x ir'


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

Re: [PATCH] D15173: [Preprocessor] Fix assertion in AnnotatePreviousCachedTokens

[Bruno Cardoso Lopes via cfe-commits]

bruno added a comment.

Hi Argyrios,

Thanks for the suggestions, will apply them.
The assertion seems important to catch subtle bugs, are you sure it should be 
placed inside a "#ifndef NDEBUG”?


http://reviews.llvm.org/D15173



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

Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

[Richard Smith via cfe-commits]

On Mon, Dec 7, 2015 at 7:25 AM, Joerg Sonnenberger via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Thu, Dec 03, 2015 at 01:36:22AM -, Richard Smith via cfe-commits
> wrote:
> > Author: rsmith
> > Date: Wed Dec  2 19:36:22 2015
> > New Revision: 254574
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=254574&view=rev
> > Log:
> > PR17381: Treat undefined behavior during expression evaluation as an
> unmodeled
> > side-effect, so that we don't allow speculative evaluation of such
> expressions
> > during code generation.
> >
> > This caused a diagnostic quality regression, so fix constant expression
> > diagnostics to prefer either the first "can't be constant folded"
> diagnostic or
> > the first "not a constant expression" diagnostic depending on the kind of
> > evaluation we're doing. This was always the intent, but didn't quite work
> > correctly before.
> >
> > This results in certain initializers that used to be constant
> initializers to
> > no longer be; in particular, things like:
> >
> >   float f = 1e100;
> >
> > are no longer accepted in C. This seems appropriate, as such constructs
> would
> > lead to code being executed if sanitizers are enabled.
>
> This leads to some pretty annoying regressions as it now seems to be
> impossible to use NaN or infinites as constant initializers. Expressions
> like 0.0 / 0.0, 1.0 / 0.0 and -1.0 / 0.0 are perfectly well defined
> under normal IEEE rules, so they shouldn't be rejected.


Well, we have a problem. The evaluation semantics of these expressions
requires code to execute in some build modes (in particular, with
sanitizers enabled), and thus has a side-effect.

I'm inclined to relax the restriction added in this change for the specific
case of global variables in C, since (as you say) there is a fair amount of
code using divide-by-zero as a "portable" way of generating an inf or nan.

Worse, it seems
> even using __builtin_nan() for example doesn't work.
>

__builtin_nan() works fine for me, can you provide a testcase?

I'm not even sure about the example given in the commit message, how
> exactly is that undefined behavior?


C11 6.3.1.5/1: "If the value being converted is outside the range of values
that can be represented, the behavior is undefined."

We also have C11 6.6/4: "Each constant expression shall evaluate to a
constant that is in the range of representable values for its type."
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D13330: Implement __attribute__((unique_instantiation))

[Keno Fischer via cfe-commits]

loladiro updated this revision to Diff 42100.
loladiro added a comment.

Address stylistic concerns brought up by David


http://reviews.llvm.org/D13330

Files:
  include/clang/AST/ASTContext.h
  include/clang/Basic/Attr.td
  include/clang/Basic/AttrDocs.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Sema/AttributeList.h
  lib/AST/ASTContext.cpp
  lib/CodeGen/CGVTables.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaDeclAttr.cpp
  lib/Sema/SemaTemplate.cpp
  test/CodeGenCXX/unique-instantiation.cpp
  test/SemaCXX/unique-instantiations.cpp
  utils/TableGen/ClangAttrEmitter.cpp

Index: utils/TableGen/ClangAttrEmitter.cpp
===
--- utils/TableGen/ClangAttrEmitter.cpp
+++ utils/TableGen/ClangAttrEmitter.cpp
@@ -2373,6 +2373,8 @@
 case Func | ObjCMethod | Param: return "ExpectedFunctionMethodOrParameter";
 case Func | ObjCMethod: return "ExpectedFunctionOrMethod";
 case Func | Var: return "ExpectedVariableOrFunction";
+case Func | Class:
+  return "ExpectedFunctionOrClass";
 
 // If not compiling for C++, the class portion does not apply.
 case Func | Var | Class:
Index: test/SemaCXX/unique-instantiations.cpp
===
--- /dev/null
+++ test/SemaCXX/unique-instantiations.cpp
@@ -0,0 +1,46 @@
+// RUN: %clang -cc1 -std=c++14 -fsyntax-only -verify %s
+
+// Correct usage
+template 
+struct foo {};
+extern template struct __attribute__((unique_instantiation)) foo;
+template struct __attribute__((unique_instantiation)) foo;
+
+template  T pi = T(3.1415926535897932385);
+extern template __attribute__((unique_instantiation)) float pi;
+template __attribute__((unique_instantiation)) float pi;
+
+// Usages on non-templates
+float __attribute__((unique_instantiation)) notpi(2.71828182845904523536028747135); // expected-error{{'unique_instantiation' attribute only applies to explicit template declarations or definitions}}
+struct __attribute__((unique_instantiation)) bar{}; // expected-error{{'unique_instantiation' attribute only applies to explicit template declarations or definitions}}
+void __attribute__((unique_instantiation)) func() {} // expected-error{{'unique_instantiation' attribute only applies to explicit template declarations or definitions}}
+
+// Usages that violate one of the conditions required conditions
+template 
+struct foo1 {};
+template struct __attribute__((unique_instantiation)) foo1; // expected-error{{'unique_instantiation' attribute on an explicit instantiation requires a previous explicit instantiation declaration}}
+
+template  T pi1 = T(3.1415926535897932385);
+template __attribute__((unique_instantiation)) float pi1;  // expected-error{{'unique_instantiation' attribute on an explicit instantiation requires a previous explicit instantiation declaration}}
+
+template 
+struct foo2 {};
+extern template struct foo2;// expected-note{{previous explicit instantiation is here}}
+template struct __attribute__((unique_instantiation)) foo2; // expected-error{{'unique_instantiation' attribute must be specified for all declarations and definitions of this explicit template instantiation}}
+
+template 
+struct foo3 {};
+extern template struct __attribute__((unique_instantiation)) foo3; // expected-note{{previous explicit instantiation is here}}
+extern template struct foo3;   // expected-error{{'unique_instantiation' attribute must be specified for all declarations and definitions of this explicit template instantiation}}
+
+template 
+struct __attribute__((unique_instantiation)) foo4 {}; // expected-error{{'unique_instantiation' attribute only applies to explicit template declarations or definitions}}
+
+template 
+struct foo5 {};
+extern template struct __attribute__((unique_instantiation)) foo5; // expected-note{{previous explicit instantiation is here}}
+template struct foo5;  // expected-error{{'unique_instantiation' attribute must be specified for all declarations and definitions of this explicit template instantiation}}
+
+template 
+struct foo6 {};
+extern template struct  __attribute__((unique_instantiation(16))) foo6;// expected-error{{'unique_instantiation' attribute takes no arguments}}
Index: test/CodeGenCXX/unique-instantiation.cpp
===
--- /dev/null
+++ test/CodeGenCXX/unique-instantiation.cpp
@@ -0,0 +1,44 @@
+// RUN: %clang -std=c++14 -emit-llvm -c -S -o - %s | FileCheck %s
+
+// CHECK: @_Z2piIfE = global float
+// CHECK-NOT: @_Z2piIfE = weak_odr global float
+template  T pi = T(3.1415926535897932385);
+extern template __attribute__((unique_instantiation)) float pi;
+template __attribute__((unique_instantiation)) float pi;
+
+template 
+struct foo {
+  T x;
+  T getX() { return x; }
+  struct bar {
+T y;
+bar(T y) : y(y) {}
+  };
+};
+template 
+T b

Re: [PATCH] D15005: Fix PR8170: Clang does not check constructor declaration that uses a template-id

[Faisal Vali via cfe-commits]

faisalv added a comment.

*ping* 
My main question is, does it make sense to suppress diagnostics when checking 
the template-id, and then rewording it as I do.  If it does make sense to 
suppress and then report a new diagnostic - is my method of suppression a 
reasonable one (as opposed to SFINAETrap or passing a flag around that's 
checked prior to emitting a diagnostic)
Thanks!


http://reviews.llvm.org/D15005



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

Re: [PATCH] D13330: Implement __attribute__((unique_instantiation))

[David Majnemer via cfe-commits]

majnemer added inline comments.


Comment at: lib/AST/ASTContext.cpp:8257-8266
@@ -8256,1 +8256,12 @@
 
+bool ASTContext::containedInUniqueInstantiation(const Decl *D) {
+  const RecordDecl *RD;
+  while ((RD = dyn_cast(D->getDeclContext( {
+auto *CTSD = dyn_cast(RD);
+if (CTSD && CTSD->hasAttr())
+  return true;
+D = RD;
+  }
+  return false;
+}
+

Function templates can contain class templates which contain functions.  I 
think this code will return false if the outermost function template is the 
only one annotated with UniqueInstantiationAttr.


http://reviews.llvm.org/D13330



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

Re: [PATCH] D15005: Fix PR8170: Clang does not check constructor declaration that uses a template-id

[David Majnemer via cfe-commits]

majnemer added a subscriber: majnemer.


Comment at: lib/Sema/SemaTemplate.cpp:528
@@ +527,3 @@
+[&StringifiedTemplateArgs, this](const TemplateArgument &TA) {
+if (const bool IsFirst = !StringifiedTemplateArgs.size())
+  StringifiedTemplateArgs = "<";

You could use `StringifiedTemplateArgs.empty()` instead.


Comment at: lib/Sema/SemaTemplate.cpp:529
@@ +528,3 @@
+if (const bool IsFirst = !StringifiedTemplateArgs.size())
+  StringifiedTemplateArgs = "<";
+else

You could hoist this bit out of the `std::for_each`


http://reviews.llvm.org/D15005



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

RE: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

[Robinson, Paul via cfe-commits]

Explicitly cc: cfe-commits *again*….

| C11 6.3.1.5/1: "If the value being converted is outside the 
range of values that can be represented, the behavior is undefined."

I think 5.2.4.2.2/5 says if infinities are representable, there are no values 
"outside" the floating-point range?
And 6.3.1.5/1 starts out with "if the value being converted can be represented 
exactly in the new type, it is unchanged."  I'd think that NaNs could be 
represented "exactly" (they can certainly be represented: 5.2.4.2.2/3) despite 
not having an actual numeric value.
I don't think 6.3.1.5/1 means to exclude NaN/infinities, given that 6.3.1.4/1 
explicitly refers to "finite value" wrt conversion to an integer type.
--paulr



From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of 
Richard Smith via cfe-commits
Sent: Monday, December 07, 2015 1:32 PM
To: Joerg Sonnenberger; cfe-commits
Subject: Re: r254574 - PR17381: Treat undefined behavior during expression 
evaluation as an unmodeled

On Mon, Dec 7, 2015 at 7:25 AM, Joerg Sonnenberger via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
On Thu, Dec 03, 2015 at 01:36:22AM -, Richard Smith via cfe-commits wrote:
> Author: rsmith
> Date: Wed Dec  2 19:36:22 2015
> New Revision: 254574
>
> URL: http://llvm.org/viewvc/llvm-project?rev=254574&view=rev
> Log:
> PR17381: Treat undefined behavior during expression evaluation as an unmodeled
> side-effect, so that we don't allow speculative evaluation of such expressions
> during code generation.
>
> This caused a diagnostic quality regression, so fix constant expression
> diagnostics to prefer either the first "can't be constant folded" diagnostic 
> or
> the first "not a constant expression" diagnostic depending on the kind of
> evaluation we're doing. This was always the intent, but didn't quite work
> correctly before.
>
> This results in certain initializers that used to be constant initializers to
> no longer be; in particular, things like:
>
>   float f = 1e100;
>
> are no longer accepted in C. This seems appropriate, as such constructs would
> lead to code being executed if sanitizers are enabled.

This leads to some pretty annoying regressions as it now seems to be
impossible to use NaN or infinites as constant initializers. Expressions
like 0.0 / 0.0, 1.0 / 0.0 and -1.0 / 0.0 are perfectly well defined
under normal IEEE rules, so they shouldn't be rejected.

Well, we have a problem. The evaluation semantics of these expressions requires 
code to execute in some build modes (in particular, with sanitizers enabled), 
and thus has a side-effect.

I'm inclined to relax the restriction added in this change for the specific 
case of global variables in C, since (as you say) there is a fair amount of 
code using divide-by-zero as a "portable" way of generating an inf or nan.

Worse, it seems
even using __builtin_nan() for example doesn't work.

__builtin_nan() works fine for me, can you provide a testcase?

I'm not even sure about the example given in the commit message, how
exactly is that undefined behavior?

C11 6.3.1.5/1: "If the value being converted is outside the 
range of values that can be represented, the behavior is undefined."

We also have C11 6.6/4: "Each constant expression shall evaluate to a constant 
that is in the range of representable values for its type."
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D15305: [CUDA] Do not allow dynamic initialization of global device side variables.

[Artem Belevich via cfe-commits]

tra created this revision.
tra added reviewers: rsmith, jingyue, jpienaar.
tra added a subscriber: cfe-commits.

In general CUDA does not allow dynamic initialization of
global device-side variables except for records with empty constructors as 
described in section [[ 
http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#device-memory-qualifiers
 | E.2.3.1 of
CUDA 7.5 Programming guide ]]:

> __device__, __constant__ and __shared__ variables defined in namespace scope, 
> that are of class type, cannot have a non-empty constructor or a non-empty 
> destructor. 
> A constructor for a class type is considered empty at a point in the 
> translation unit, 
> if it is either a trivial constructor or it satisfies all of the following 
> conditions:

> * The constructor function has been defined.
> * The constructor function has no parameters, the initializer list is empty 
> and the function body is an empty compound statement.
> * Its class has no virtual functions and no virtual base classes.
> * The default constructors of all base classes of its class can be considered 
> empty.
> * For all the nonstatic data members of its class that are of class type (or 
> array thereof), the default constructors can be considered empty.

Clang is already enforcing no-initializers for __shared__ variables, but 
currently allows dynamic initialization for __device__ and __constant__ 
variables. 

This patch applies initializer checks for all device-side variables.
Empty constructors are accepted, but no code is generated for them.

http://reviews.llvm.org/D15305

Files:
  lib/CodeGen/CGDeclCXX.cpp
  lib/CodeGen/CodeGenModule.cpp
  lib/CodeGen/CodeGenModule.h
  test/CodeGenCUDA/device-var-init.cu

Index: test/CodeGenCUDA/device-var-init.cu
===
--- /dev/null
+++ test/CodeGenCUDA/device-var-init.cu
@@ -0,0 +1,371 @@
+// REQUIRES: nvptx-registered-target
+
+// Make sure we don't allow dynamic initialization for device
+// variables, but accept empty constructors allowed by CUDA.
+
+// RUN: %clang_cc1 -triple nvptx64-nvidia-cuda -fcuda-is-device -emit-llvm -o - %s \
+// RUN: | FileCheck %s
+// RUN: %clang_cc1 -triple nvptx64-nvidia-cuda -fcuda-is-device -emit-llvm \
+// RUN: -DERROR_CASE -verify -o /dev/null %s
+
+#include "Inputs/cuda.h"
+
+// no-constructor
+struct NC {
+  int nc;
+};
+
+// empty constructor
+struct EC {
+  int ec;
+  __device__ EC() {}
+};
+
+// empty constructor w/ initializer list
+struct ECI {
+  int eci;
+  __device__ ECI() : eci(1) {}
+};
+
+// non-empty constructor
+struct NEC {
+  int nec;
+  __device__ NEC() { nec = 1; }
+};
+
+// no-constructor,  virtual method
+struct NCV {
+  virtual void vm() {}
+};
+
+// no-constructor, no-constructor base class
+struct NC_B_NC : NC {
+  int nc_b_nc;
+};
+
+// no-constructor, empty-constructor base class
+struct NC_B_EC : EC {
+  int nc_b_ec;
+};
+
+// no-constructor, base class w/ constructor+init list.
+struct NC_B_ECI : ECI {
+};
+
+// no-constructor, non-empty-constructor base class
+struct NC_B_NEC : NEC {
+  int nc_b_nec;
+};
+
+// no-constructor, base class w/ virtual method
+struct NC_B_NCV : NCV {
+  int nc_b_ncv;
+};
+
+// empty constructor, no-constructor base class
+struct EC_B_NC : NC {
+  __device__ EC_B_NC() {}
+};
+
+// empty constructor, empty-constructor base class
+struct EC_B_EC : EC {
+  __device__ EC_B_EC() {}
+};
+
+// empty constructor, base class w/ constructor+init list.
+struct EC_B_ECI : ECI {
+  __device__ EC_B_ECI() {}
+};
+
+// empty constructor, non-empty-constructor base class
+struct EC_B_NEC : NEC {
+  __device__ EC_B_NEC() {}
+};
+
+// empty constructor, non-empty-constructor base class
+struct EC_B_NCV : NCV {
+  __device__ EC_B_NCV() {}
+};
+
+// no-constructor, no-constructor virtual base class
+struct NC_V_NC : virtual NC {
+};
+
+// no-constructor, empty constructor virtual base class
+struct NC_V_EC : virtual EC {
+};
+
+// empty constructor, no-constructor virtual base class
+struct EC_V_NC : virtual NC {
+  __device__ EC_V_NC() {}
+};
+
+// empty constructor, empty constructor virtual base class
+struct EC_V_EC : virtual EC {
+  __device__ EC_V_EC() {}
+};
+
+// no-constructor, no-constructor field
+struct NC_F_NC {
+  NC nc_f_nc;
+};
+
+// no-constructor, empty-constructor field
+struct NC_F_EC{
+  EC nc_f_ec;
+};
+
+// no-constructor, empty-constructor+initializer field
+struct NC_F_ECI{
+  ECI nc_f_ec;
+};
+
+// no-constructor, non-empty-constructor field
+struct NC_F_NEC {
+  NEC nc_f_nec;
+};
+
+// no-constructor, field w/ virtual method
+struct NC_F_NCV {
+  NCV nc_f_ncv;
+};
+
+// no-constructor, no-constructor field
+struct NC_FA_NC {
+  NC nc_fa_nc[2];
+};
+
+// no-constructor, empty-constructor field
+struct NC_FA_EC{
+  EC nc_fa_ec[2];
+};
+
+// no-constructor, non-empty-constructor field
+struct NC_FA_NEC {
+  NEC nc_fa_nec[2];
+};
+
+// no-constructor, field w/ virtual method
+struct NC_FA_NCV {
+  NCV nc_fa_ncv[2];
+};
+
+

Fix for Paths with Whitespace

[scott constable via cfe-commits]

Dear Reviewer,

The current doxygen.cfg.in will produce paths that cannot be understood by
Doxygen/Graphviz, when any generated paths contain white space. This patch
simply adds quotations to all generated paths so that white space cannot be
misinterpreted by Doxygen/Graphviz.

~Scott Constable


doxygen.cfg.in
Description: Binary data
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D15305: [CUDA] Do not allow dynamic initialization of global device side variables.

[Artem Belevich via cfe-commits]

tra added inline comments.


Comment at: lib/CodeGen/CGDeclCXX.cpp:329
@@ +328,3 @@
+  for (const CXXCtorInitializer *CI: CD->inits())
+if (CI->isAnyMemberInitializer() && CI->isWritten())
+  return false;

@rsmith: is this a good way to find member initializer list items?

```
struct S {
int a,b,c;
S() : a(1),b(2),c(3) {}
};
```
I'm looking for a(),b(),c() which is what I think CUDA spec wants to check for, 
but CD->inits() appears to have other initializers on the list as well.


http://reviews.llvm.org/D15305



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

Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

[David Majnemer via cfe-commits]

On Mon, Dec 7, 2015 at 4:32 PM, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Mon, Dec 7, 2015 at 7:25 AM, Joerg Sonnenberger via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On Thu, Dec 03, 2015 at 01:36:22AM -, Richard Smith via cfe-commits
>> wrote:
>> > Author: rsmith
>> > Date: Wed Dec  2 19:36:22 2015
>> > New Revision: 254574
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=254574&view=rev
>> > Log:
>> > PR17381: Treat undefined behavior during expression evaluation as an
>> unmodeled
>> > side-effect, so that we don't allow speculative evaluation of such
>> expressions
>> > during code generation.
>> >
>> > This caused a diagnostic quality regression, so fix constant expression
>> > diagnostics to prefer either the first "can't be constant folded"
>> diagnostic or
>> > the first "not a constant expression" diagnostic depending on the kind
>> of
>> > evaluation we're doing. This was always the intent, but didn't quite
>> work
>> > correctly before.
>> >
>> > This results in certain initializers that used to be constant
>> initializers to
>> > no longer be; in particular, things like:
>> >
>> >   float f = 1e100;
>> >
>> > are no longer accepted in C. This seems appropriate, as such constructs
>> would
>> > lead to code being executed if sanitizers are enabled.
>>
>> This leads to some pretty annoying regressions as it now seems to be
>> impossible to use NaN or infinites as constant initializers. Expressions
>> like 0.0 / 0.0, 1.0 / 0.0 and -1.0 / 0.0 are perfectly well defined
>> under normal IEEE rules, so they shouldn't be rejected.
>
>
> Well, we have a problem. The evaluation semantics of these expressions
> requires code to execute in some build modes (in particular, with
> sanitizers enabled), and thus has a side-effect.
>
> I'm inclined to relax the restriction added in this change for the
> specific case of global variables in C, since (as you say) there is a fair
> amount of code using divide-by-zero as a "portable" way of generating an
> inf or nan.
>
> Worse, it seems
>> even using __builtin_nan() for example doesn't work.
>>
>
> __builtin_nan() works fine for me, can you provide a testcase?
>
> I'm not even sure about the example given in the commit message, how
>> exactly is that undefined behavior?
>
>
> C11 6.3.1.5/1: "If the value being converted is outside the range of
> values that can be represented, the behavior is undefined."
>

I don't think we want to make the UB here true UB.  It would mean that code
which expected to get NaN might get undef, even outside of constant
expression evaluation.  The implementation defined behavior of providing
NaN seems more friendly...  IIRC, this broke Chrome recently because folks
were doing this in C++.  Hans, do you remember the details?


>
> We also have C11 6.6/4: "Each constant expression shall evaluate to a
> constant that is in the range of representable values for its type."
>
> ___
> 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] D15173: [Preprocessor] Fix assertion in AnnotatePreviousCachedTokens

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

> On 2015-Dec-07, at 13:29, Bruno Cardoso Lopes  wrote:
> 
> bruno added a comment.
> 
> Hi Argyrios,
> 
> Thanks for the suggestions, will apply them.
> The assertion seems important to catch subtle bugs, are you sure it should be 
> placed inside a "#ifndef NDEBUG”?

FYI, the definition for `assert` is something like:

#ifdef NDEBUG
#define assert(cond)
#else
#define assert(cond) \
if (!(cond)) { assertion_failed(#FILE ":" #LINE ": " #cond); };
#endif

> 
> 
> http://reviews.llvm.org/D15173
> 
> 
> 

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

Re: [PATCH] D15173: [Preprocessor] Fix assertion in AnnotatePreviousCachedTokens

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

> On 2015-Dec-07, at 14:22, Duncan P. N. Exon Smith  
> wrote:
> 
> 
>> On 2015-Dec-07, at 13:29, Bruno Cardoso Lopes  
>> wrote:
>> 
>> bruno added a comment.
>> 
>> Hi Argyrios,
>> 
>> Thanks for the suggestions, will apply them.
>> The assertion seems important to catch subtle bugs, are you sure it should 
>> be placed inside a "#ifndef NDEBUG”?
> 
> FYI, the definition for `assert` is something like:
> 
> #ifdef NDEBUG
> #define assert(cond)
> #else
> #define assert(cond) \
> if (!(cond)) { assertion_failed(#FILE ":" #LINE ": " #cond); };
> #endif

Probably more like:

#ifdef NDEBUG
#define assert(cond) (void)0
#else
#define assert(cond) \
do { \
   if (!(cond)) { assertion_failed(#FILE ":" #LINE ": " #cond); }; \
} while (false)
#endif

but the point is, NDEBUG is the "are assertions on?" macro.

>> 
>> 
>> http://reviews.llvm.org/D15173
>> 
>> 
>> 
> 

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

Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

[Hans Wennborg via cfe-commits]

On Mon, Dec 7, 2015 at 2:14 PM, David Majnemer  wrote:
>
>
> On Mon, Dec 7, 2015 at 4:32 PM, Richard Smith via cfe-commits
>  wrote:
>>
>> On Mon, Dec 7, 2015 at 7:25 AM, Joerg Sonnenberger via cfe-commits
>>  wrote:
>>>
>>> On Thu, Dec 03, 2015 at 01:36:22AM -, Richard Smith via cfe-commits
>>> wrote:
>>> > Author: rsmith
>>> > Date: Wed Dec  2 19:36:22 2015
>>> > New Revision: 254574
>>> >
>>> > URL: http://llvm.org/viewvc/llvm-project?rev=254574&view=rev
>>> > Log:
>>> > PR17381: Treat undefined behavior during expression evaluation as an
>>> > unmodeled
>>> > side-effect, so that we don't allow speculative evaluation of such
>>> > expressions
>>> > during code generation.
>>> >
>>> > This caused a diagnostic quality regression, so fix constant expression
>>> > diagnostics to prefer either the first "can't be constant folded"
>>> > diagnostic or
>>> > the first "not a constant expression" diagnostic depending on the kind
>>> > of
>>> > evaluation we're doing. This was always the intent, but didn't quite
>>> > work
>>> > correctly before.
>>> >
>>> > This results in certain initializers that used to be constant
>>> > initializers to
>>> > no longer be; in particular, things like:
>>> >
>>> >   float f = 1e100;
>>> >
>>> > are no longer accepted in C. This seems appropriate, as such constructs
>>> > would
>>> > lead to code being executed if sanitizers are enabled.
>>>
>>> This leads to some pretty annoying regressions as it now seems to be
>>> impossible to use NaN or infinites as constant initializers. Expressions
>>> like 0.0 / 0.0, 1.0 / 0.0 and -1.0 / 0.0 are perfectly well defined
>>> under normal IEEE rules, so they shouldn't be rejected.
>>
>>
>> Well, we have a problem. The evaluation semantics of these expressions
>> requires code to execute in some build modes (in particular, with sanitizers
>> enabled), and thus has a side-effect.
>>
>> I'm inclined to relax the restriction added in this change for the
>> specific case of global variables in C, since (as you say) there is a fair
>> amount of code using divide-by-zero as a "portable" way of generating an inf
>> or nan.
>>
>>> Worse, it seems
>>> even using __builtin_nan() for example doesn't work.
>>
>>
>> __builtin_nan() works fine for me, can you provide a testcase?
>>
>>> I'm not even sure about the example given in the commit message, how
>>> exactly is that undefined behavior?
>>
>>
>> C11 6.3.1.5/1: "If the value being converted is outside the range of
>> values that can be represented, the behavior is undefined."
>
>
> I don't think we want to make the UB here true UB.  It would mean that code
> which expected to get NaN might get undef, even outside of constant
> expression evaluation.  The implementation defined behavior of providing NaN
> seems more friendly...  IIRC, this broke Chrome recently because folks were
> doing this in C++.  Hans, do you remember the details?

Hmm, it doesn't ring a bell, but my memory sometimes fails me. Didn't
you and Reid look at something like this the other day? (But maybe
that was in internal code?)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

[David Majnemer via cfe-commits]

On Mon, Dec 7, 2015 at 5:25 PM, Hans Wennborg  wrote:

> On Mon, Dec 7, 2015 at 2:14 PM, David Majnemer 
> wrote:
> >
> >
> > On Mon, Dec 7, 2015 at 4:32 PM, Richard Smith via cfe-commits
> >  wrote:
> >>
> >> On Mon, Dec 7, 2015 at 7:25 AM, Joerg Sonnenberger via cfe-commits
> >>  wrote:
> >>>
> >>> On Thu, Dec 03, 2015 at 01:36:22AM -, Richard Smith via cfe-commits
> >>> wrote:
> >>> > Author: rsmith
> >>> > Date: Wed Dec  2 19:36:22 2015
> >>> > New Revision: 254574
> >>> >
> >>> > URL: http://llvm.org/viewvc/llvm-project?rev=254574&view=rev
> >>> > Log:
> >>> > PR17381: Treat undefined behavior during expression evaluation as an
> >>> > unmodeled
> >>> > side-effect, so that we don't allow speculative evaluation of such
> >>> > expressions
> >>> > during code generation.
> >>> >
> >>> > This caused a diagnostic quality regression, so fix constant
> expression
> >>> > diagnostics to prefer either the first "can't be constant folded"
> >>> > diagnostic or
> >>> > the first "not a constant expression" diagnostic depending on the
> kind
> >>> > of
> >>> > evaluation we're doing. This was always the intent, but didn't quite
> >>> > work
> >>> > correctly before.
> >>> >
> >>> > This results in certain initializers that used to be constant
> >>> > initializers to
> >>> > no longer be; in particular, things like:
> >>> >
> >>> >   float f = 1e100;
> >>> >
> >>> > are no longer accepted in C. This seems appropriate, as such
> constructs
> >>> > would
> >>> > lead to code being executed if sanitizers are enabled.
> >>>
> >>> This leads to some pretty annoying regressions as it now seems to be
> >>> impossible to use NaN or infinites as constant initializers.
> Expressions
> >>> like 0.0 / 0.0, 1.0 / 0.0 and -1.0 / 0.0 are perfectly well defined
> >>> under normal IEEE rules, so they shouldn't be rejected.
> >>
> >>
> >> Well, we have a problem. The evaluation semantics of these expressions
> >> requires code to execute in some build modes (in particular, with
> sanitizers
> >> enabled), and thus has a side-effect.
> >>
> >> I'm inclined to relax the restriction added in this change for the
> >> specific case of global variables in C, since (as you say) there is a
> fair
> >> amount of code using divide-by-zero as a "portable" way of generating
> an inf
> >> or nan.
> >>
> >>> Worse, it seems
> >>> even using __builtin_nan() for example doesn't work.
> >>
> >>
> >> __builtin_nan() works fine for me, can you provide a testcase?
> >>
> >>> I'm not even sure about the example given in the commit message, how
> >>> exactly is that undefined behavior?
> >>
> >>
> >> C11 6.3.1.5/1: "If the value being converted is outside the range of
> >> values that can be represented, the behavior is undefined."
> >
> >
> > I don't think we want to make the UB here true UB.  It would mean that
> code
> > which expected to get NaN might get undef, even outside of constant
> > expression evaluation.  The implementation defined behavior of providing
> NaN
> > seems more friendly...  IIRC, this broke Chrome recently because folks
> were
> > doing this in C++.  Hans, do you remember the details?
>
> Hmm, it doesn't ring a bell, but my memory sometimes fails me. Didn't
> you and Reid look at something like this the other day? (But maybe
> that was in internal code?)
>

Ah, I think you are right... Reid, do you happen to recall?
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D15309: [CUDA] emit vtables only for classes with methods usable on this side of compilation.

[Artem Belevich via cfe-commits]

tra created this revision.
tra added reviewers: rsmith, jingyue, jpienaar.
tra added a subscriber: cfe-commits.

C++ emits vtables for classes that have key function present in the
current TU. While we compile CUDA the fact that key function was found
in this TU does not mean that we are going to generate code for it. E.g.
vtable for a class with host-only methods should not be generated on 
device side, because we are not going to generate any code for the 
host-only methods during device-side compilation.

During CUDA compilation this patch checks virtual methods' target attributes 
and 
returns key function only if all virtual methods in the class are suitable for 
the current
compilation mode.


http://reviews.llvm.org/D15309

Files:
  lib/AST/RecordLayoutBuilder.cpp
  test/CodeGenCUDA/device-vtable.cu

Index: test/CodeGenCUDA/device-vtable.cu
===
--- /dev/null
+++ test/CodeGenCUDA/device-vtable.cu
@@ -0,0 +1,55 @@
+// REQUIRES: x86-registered-target
+// REQUIRES: nvptx-registered-target
+
+// Make sure we don't emit vtables for classes with methods that have
+// inappropriate target attributes. Currently it's mostly needed in
+// order to avoid emitting vtables for host-only classes on device
+// side where we can't codegen them.
+
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -o - %s \
+// RUN: | FileCheck %s -check-prefix=CHECK-HOST
+// RUN: %clang_cc1 -triple nvptx64-nvidia-cuda -fcuda-is-device -emit-llvm -o 
- %s \
+// RUN: | FileCheck %s -check-prefix=CHECK-DEVICE
+
+#include "Inputs/cuda.h"
+
+class H  {
+ public:
+  virtual void method();
+};
+//CHECK-HOST: @_ZTV1H =
+//CHECK-HOST-SAME: @_ZN1H6methodEv
+//CHECK-DEVICE-NOT: @_ZTV1H =
+
+class D  {
+ public:
+   __device__ virtual void method();
+};
+
+//CHECK-DEVICE: @_ZTV1D
+//CHECK-DEVICE-SAME: @_ZN1D6methodEv
+//CHECK-HOST-NOT: @_ZTV1D
+
+// This is the case with mixed host and device virtual methods.  It's
+// impossible to emit a valid vtable in that case because only host or
+// only device methods would be available during host or device
+// compilation. For now we'll not emit such vtable at all.
+class HD  {
+ public:
+   virtual void h_method();
+   __device__ virtual void d_method();
+};
+//CHECK-BOTH-NOT: @_ZTV2HD
+
+void H::method() {}
+//CHECK-HOST: define void @_ZN1H6methodEv
+
+void __device__ D::method() {}
+//CHECK-DEVICE: define void @_ZN1D6methodEv
+
+void __device__ HD::d_method() {}
+// CHECK-DEVICE: define void @_ZN2HD8d_methodEv
+// CHECK-HOST-NOT: define void @_ZN2HD8d_methodEv
+void HD::h_method() {}
+// CHECK-HOST: define void @_ZN2HD8h_methodEv
+// CHECK-DEVICE-NOT: define void @_ZN2HD8h_methodEv
Index: lib/AST/RecordLayoutBuilder.cpp
===
--- lib/AST/RecordLayoutBuilder.cpp
+++ lib/AST/RecordLayoutBuilder.cpp
@@ -1996,6 +1996,16 @@
   bool allowInlineFunctions =
 Context.getTargetInfo().getCXXABI().canKeyFunctionBeInline();
 
+  if (Context.getLangOpts().CUDA) {
+const bool IsDevice = Context.getLangOpts().CUDAIsDevice;
+for (const CXXMethodDecl *MD : RD->methods())
+  if (Context.getLangOpts().CUDAIsDevice && !MD->hasAttr())
+return nullptr;
+  else if (!Context.getLangOpts().CUDAIsDevice &&
+   !MD->hasAttr() && MD->hasAttr())
+return nullptr;
+  }
+
   for (const CXXMethodDecl *MD : RD->methods()) {
 if (!MD->isVirtual())
   continue;


Index: test/CodeGenCUDA/device-vtable.cu
===
--- /dev/null
+++ test/CodeGenCUDA/device-vtable.cu
@@ -0,0 +1,55 @@
+// REQUIRES: x86-registered-target
+// REQUIRES: nvptx-registered-target
+
+// Make sure we don't emit vtables for classes with methods that have
+// inappropriate target attributes. Currently it's mostly needed in
+// order to avoid emitting vtables for host-only classes on device
+// side where we can't codegen them.
+
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -o - %s \
+// RUN: | FileCheck %s -check-prefix=CHECK-HOST
+// RUN: %clang_cc1 -triple nvptx64-nvidia-cuda -fcuda-is-device -emit-llvm -o - %s \
+// RUN: | FileCheck %s -check-prefix=CHECK-DEVICE
+
+#include "Inputs/cuda.h"
+
+class H  {
+ public:
+  virtual void method();
+};
+//CHECK-HOST: @_ZTV1H =
+//CHECK-HOST-SAME: @_ZN1H6methodEv
+//CHECK-DEVICE-NOT: @_ZTV1H =
+
+class D  {
+ public:
+   __device__ virtual void method();
+};
+
+//CHECK-DEVICE: @_ZTV1D
+//CHECK-DEVICE-SAME: @_ZN1D6methodEv
+//CHECK-HOST-NOT: @_ZTV1D
+
+// This is the case with mixed host and device virtual methods.  It's
+// impossible to emit a valid vtable in that case because only host or
+// only device methods would be available during host or device
+// compilation. For now we'll not emit such vtable at all.
+class HD  {
+ public:
+   virtual void h_method();
+   __device__ virtual void d_method();
+};
+//CHECK-BOTH-NOT: @_ZTV2HD
+

r254958 - 80-col and whitespace fixups.

[Eric Christopher via cfe-commits]

Author: echristo
Date: Mon Dec  7 16:43:05 2015
New Revision: 254958

URL: http://llvm.org/viewvc/llvm-project?rev=254958&view=rev
Log:
80-col and whitespace fixups.

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=254958&r1=254957&r2=254958&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains.cpp Mon Dec  7 16:43:05 2015
@@ -3536,7 +3536,8 @@ static Distro DetectDistro(const Driver
 static std::string getMultiarchTriple(const Driver &D,
   const llvm::Triple &TargetTriple,
   StringRef SysRoot) {
-  llvm::Triple::EnvironmentType TargetEnvironment = 
TargetTriple.getEnvironment();
+  llvm::Triple::EnvironmentType TargetEnvironment =
+  TargetTriple.getEnvironment();
 
   // For most architectures, just use whatever we have rather than trying to be
   // clever.
@@ -4367,7 +4368,8 @@ MyriadToolChain::MyriadToolChain(const D
   // choose the myriad installation when targeting a non-myriad sparc install.
   switch (Triple.getArch()) {
   default:
-D.Diag(diag::err_target_unsupported_arch) << Triple.getArchName() << 
"myriad";
+D.Diag(diag::err_target_unsupported_arch) << Triple.getArchName()
+  << "myriad";
   case llvm::Triple::sparc:
   case llvm::Triple::sparcel:
   case llvm::Triple::shave:
@@ -4403,8 +4405,8 @@ void MyriadToolChain::AddClangSystemIncl
 addSystemInclude(DriverArgs, CC1Args, getDriver().SysRoot + "/include");
 }
 
-void MyriadToolChain::AddClangCXXStdlibIncludeArgs(const ArgList &DriverArgs,
-   ArgStringList &CC1Args) 
const {
+void MyriadToolChain::AddClangCXXStdlibIncludeArgs(
+const ArgList &DriverArgs, ArgStringList &CC1Args) const {
   if (DriverArgs.hasArg(options::OPT_nostdlibinc) ||
   DriverArgs.hasArg(options::OPT_nostdincxx))
 return;
@@ -4415,8 +4417,9 @@ void MyriadToolChain::AddClangCXXStdlibI
   StringRef TripleStr = GCCInstallation.getTriple().str();
   const Multilib &Multilib = GCCInstallation.getMultilib();
 
-  addLibStdCXXIncludePaths(LibDir.str() + "/../" + TripleStr.str() + 
"/include/c++/" + Version.Text,
-   "", TripleStr, "", "", Multilib.includeSuffix(), 
DriverArgs, CC1Args);
+  addLibStdCXXIncludePaths(
+  LibDir.str() + "/../" + TripleStr.str() + "/include/c++/" + Version.Text,
+  "", TripleStr, "", "", Multilib.includeSuffix(), DriverArgs, CC1Args);
 }
 
 // MyriadToolChain handles several triples:
@@ -4490,11 +4493,11 @@ PS4CPU::PS4CPU(const Driver &D, const ll
   } else {
 PS4SDKDir = getDriver().Dir;
 llvm::sys::path::append(PS4SDKDir, "/../../");
-  } 
+  }
 
-  // By default, the driver won't report a warning if it can't find 
+  // By default, the driver won't report a warning if it can't find
   // PS4's include or lib directories. This behavior could be changed if
-  // -Weverything or -Winvalid-or-nonexistent-directory options are passed.  
+  // -Weverything or -Winvalid-or-nonexistent-directory options are passed.
   // If -isysroot was passed, use that as the SDK base path.
   std::string PrefixDir;
   if (const Arg *A = Args.getLastArg(options::OPT_isysroot)) {


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

r254961 - Add llvm-objdump to compiler-rt test deps.

[Alexey Samsonov via cfe-commits]

Author: samsonov
Date: Mon Dec  7 16:45:36 2015
New Revision: 254961

URL: http://llvm.org/viewvc/llvm-project?rev=254961&view=rev
Log:
Add llvm-objdump to compiler-rt test deps.

Modified:
cfe/trunk/runtime/CMakeLists.txt

Modified: cfe/trunk/runtime/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/runtime/CMakeLists.txt?rev=254961&r1=254960&r2=254961&view=diff
==
--- cfe/trunk/runtime/CMakeLists.txt (original)
+++ cfe/trunk/runtime/CMakeLists.txt Mon Dec  7 16:45:36 2015
@@ -111,7 +111,7 @@ if(LLVM_BUILD_EXTERNAL_COMPILER_RT AND E
   if(LLVM_INCLUDE_TESTS)
 # Add binaries that compiler-rt tests depend on.
 set(COMPILER_RT_TEST_DEPENDENCIES
-  FileCheck count not llvm-nm llvm-symbolizer)
+  FileCheck count not llvm-nm llvm-objdump llvm-symbolizer)
 
 # Add top-level targets for various compiler-rt test suites.
 set(COMPILER_RT_TEST_SUITES check-asan check-asan-dynamic check-dfsan


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

[PATCH] D15311: [Clang] Use range loops and autos in lib/Serialization/ASTWriter.cpp

[Eugene Zelenko via cfe-commits]

Eugene.Zelenko created this revision.
Eugene.Zelenko added reviewers: hans, aaron.ballman.
Eugene.Zelenko added a subscriber: cfe-commits.
Eugene.Zelenko set the repository for this revision to rL LLVM.

I fixed Clang-tidy modernize-loop-convert and modernize-use-auto. Autos are 
also used for pointer variables assigned via casts. Patch includes other minor 
cleanups.

Build and regressions were finr on RHEL 6.

Repository:
  rL LLVM

http://reviews.llvm.org/D15311

Files:
  lib/Serialization/ASTWriter.cpp

Index: lib/Serialization/ASTWriter.cpp
===
--- lib/Serialization/ASTWriter.cpp
+++ lib/Serialization/ASTWriter.cpp
@@ -1,4 +1,4 @@
-//===--- ASTWriter.cpp - AST File Writer --===//
+//===--- ASTWriter.cpp - AST File Writer *- C++ -*-===//
 //
 // The LLVM Compiler Infrastructure
 //
@@ -60,6 +60,7 @@
 #include 
 #include 
 #include 
+
 using namespace clang;
 using namespace clang::serialization;
 
@@ -102,7 +103,7 @@
 #define ABSTRACT_TYPE(Class, Base)
 #include "clang/AST/TypeNodes.def"
   };
-}
+} // end anonymous namespace
 
 void ASTTypeWriter::VisitBuiltinType(const BuiltinType *T) {
   llvm_unreachable("Built-in types are never serialized");
@@ -333,9 +334,8 @@
   Record.push_back(T->isDependentType());
   Writer.AddTemplateName(T->getTemplateName(), Record);
   Record.push_back(T->getNumArgs());
-  for (TemplateSpecializationType::iterator ArgI = T->begin(), ArgE = T->end();
- ArgI != ArgE; ++ArgI)
-Writer.AddTemplateArgument(*ArgI, Record);
+  for (const auto &ArgI : *T)
+Writer.AddTemplateArgument(ArgI, Record);
   Writer.AddTypeRef(T->isTypeAlias() ? T->getAliasedType() :
 T->isCanonicalUnqualified() ? QualType()
 : T->getCanonicalTypeInternal(),
@@ -385,9 +385,8 @@
   Writer.AddNestedNameSpecifier(T->getQualifier(), Record);
   Writer.AddIdentifierRef(T->getIdentifier(), Record);
   Record.push_back(T->getNumArgs());
-  for (DependentTemplateSpecializationType::iterator
- I = T->begin(), E = T->end(); I != E; ++I)
-Writer.AddTemplateArgument(*I, Record);
+  for (const auto &I : *T)
+Writer.AddTemplateArgument(I, Record);
   Code = TYPE_DEPENDENT_TEMPLATE_SPECIALIZATION;
 }
 
@@ -466,7 +465,7 @@
   void VisitFunctionTypeLoc(FunctionTypeLoc TyLoc);
 };
 
-}
+} // end anonymous namespace
 
 void TypeLocWriter::VisitQualifiedTypeLoc(QualifiedTypeLoc TL) {
   // nothing to do
@@ -1182,7 +1181,7 @@
   RecordData Record;
   
   // Metadata
-  BitCodeAbbrev *MetadataAbbrev = new BitCodeAbbrev();
+  auto *MetadataAbbrev = new BitCodeAbbrev();
   MetadataAbbrev->Add(BitCodeAbbrevOp(METADATA));
   MetadataAbbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 16)); // Major
   MetadataAbbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 16)); // Minor
@@ -1215,7 +1214,7 @@
 }
 
 // Module name
-BitCodeAbbrev *Abbrev = new BitCodeAbbrev();
+auto *Abbrev = new BitCodeAbbrev();
 Abbrev->Add(BitCodeAbbrevOp(MODULE_NAME));
 Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Blob)); // Name
 unsigned AbbrevCode = Stream.EmitAbbrev(Abbrev);
@@ -1235,7 +1234,7 @@
  .ModuleMapFileHomeIsCwd ||
 WritingModule->Directory->getName() != StringRef(".")) {
   // Module directory.
-  BitCodeAbbrev *Abbrev = new BitCodeAbbrev();
+  auto *Abbrev = new BitCodeAbbrev();
   Abbrev->Add(BitCodeAbbrevOp(MODULE_DIRECTORY));
   Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Blob)); // Directory
   unsigned AbbrevCode = Stream.EmitAbbrev(Abbrev);
@@ -1319,11 +1318,8 @@
 
   // Comment options.
   Record.push_back(LangOpts.CommentOpts.BlockCommandNames.size());
-  for (CommentOptions::BlockCommandNamesTy::const_iterator
-   I = LangOpts.CommentOpts.BlockCommandNames.begin(),
-   IEnd = LangOpts.CommentOpts.BlockCommandNames.end();
-   I != IEnd; ++I) {
-AddString(*I, Record);
+  for (const auto &I : LangOpts.CommentOpts.BlockCommandNames) {
+AddString(I, Record);
   }
   Record.push_back(LangOpts.CommentOpts.ParseAllComments);
 
@@ -1441,7 +1437,7 @@
   // Original file name and file ID
   SourceManager &SM = Context.getSourceManager();
   if (const FileEntry *MainFile = SM.getFileEntryForID(SM.getMainFileID())) {
-BitCodeAbbrev *FileAbbrev = new BitCodeAbbrev();
+auto *FileAbbrev = new BitCodeAbbrev();
 FileAbbrev->Add(BitCodeAbbrevOp(ORIGINAL_FILE));
 FileAbbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6)); // File ID
 FileAbbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Blob)); // File name
@@ -1459,7 +1455,7 @@
 
   // Original PCH directory
   if (!OutputFile.empty() && OutputFile != "-") {
-BitCodeAbbrev *Abbrev = new BitCodeAbbrev();
+auto *Abbrev = new BitCodeAbbrev();
 Abbrev->Add(BitCodeAbbrevOp(ORIGINAL_PCH_DIR));
 Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Blob

Re: r254935 - AST: defer to TypeLoc::copy in TypeLoc::initializeFullCopy

[Alexey Samsonov via cfe-commits]

Thanks for taking care of this!

On Mon, Dec 7, 2015 at 12:04 PM, Justin Bogner via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: bogner
> Date: Mon Dec  7 14:04:57 2015
> New Revision: 254935
>
> URL: http://llvm.org/viewvc/llvm-project?rev=254935&view=rev
> Log:
> AST: defer to TypeLoc::copy in TypeLoc::initializeFullCopy
>
> If we're initializing a TypeLoc from one that's been allocated with
> different alignment, memcpy will get the padding wrong. The `copy`
> method already checks and handles this case, so we should just defer
> to it.
>
> This also drops the `const` off of the `initializeFullCopy`
> declarations, since it isn't even remotely true (and the compiler
> notices when we try to call copy() instead of tricking it with
> memcpy).
>
> Fixes llvm.org/pr23516.
>
> Modified:
> cfe/trunk/include/clang/AST/TypeLoc.h
>
> Modified: cfe/trunk/include/clang/AST/TypeLoc.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/TypeLoc.h?rev=254935&r1=254934&r2=254935&view=diff
>
> ==
> --- cfe/trunk/include/clang/AST/TypeLoc.h (original)
> +++ cfe/trunk/include/clang/AST/TypeLoc.h Mon Dec  7 14:04:57 2015
> @@ -170,19 +170,18 @@ public:
>
>/// \brief Initializes this by copying its information from another
>/// TypeLoc of the same type.
> -  void initializeFullCopy(TypeLoc Other) const {
> +  void initializeFullCopy(TypeLoc Other) {
>  assert(getType() == Other.getType());
> -size_t Size = getFullDataSize();
> -memcpy(getOpaqueData(), Other.getOpaqueData(), Size);
> +copy(Other);
>}
>
>/// \brief Initializes this by copying its information from another
>/// TypeLoc of the same type.  The given size must be the full data
>/// size.
> -  void initializeFullCopy(TypeLoc Other, unsigned Size) const {
> +  void initializeFullCopy(TypeLoc Other, unsigned Size) {
>  assert(getType() == Other.getType());
>  assert(getFullDataSize() == Size);
> -memcpy(getOpaqueData(), Other.getOpaqueData(), Size);
> +copy(Other);
>}
>
>/// Copies the other type loc into this one.
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>



-- 
Alexey Samsonov
vonos...@gmail.com
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D15005: Fix PR8170: Clang does not check constructor declaration that uses a template-id

[Faisal Vali via cfe-commits]

faisalv added inline comments.


Comment at: lib/Sema/SemaTemplate.cpp:528
@@ +527,3 @@
+[&StringifiedTemplateArgs, this](const TemplateArgument &TA) {
+if (const bool IsFirst = !StringifiedTemplateArgs.size())
+  StringifiedTemplateArgs = "<";

majnemer wrote:
> You could use `StringifiedTemplateArgs.empty()` instead.
Aah yes - Will do - Thanks!


Comment at: lib/Sema/SemaTemplate.cpp:529
@@ +528,3 @@
+if (const bool IsFirst = !StringifiedTemplateArgs.size())
+  StringifiedTemplateArgs = "<";
+else

majnemer wrote:
> You could hoist this bit out of the `std::for_each`
Well - I would still need some way to know that this is not the first 
iteration.  I was trying to avoid declaring another variable or checking that 
the string was equal to another string (I thought the empty check would be 
reasonable) -do you feel strongly about the hoist?


http://reviews.llvm.org/D15005



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

r254962 - [analyzer] Fix crash when lambda captures a variable-length array.

[Devin Coughlin via cfe-commits]

Author: dcoughlin
Date: Mon Dec  7 17:01:53 2015
New Revision: 254962

URL: http://llvm.org/viewvc/llvm-project?rev=254962&view=rev
Log:
[analyzer] Fix crash when lambda captures a variable-length array.

When a C++ lambda captures a variable-length array, it creates a capture
field to store the size of the array. The initialization expression for this
capture is null, which led the analyzer to crash when initializing the field.
To avoid this, use the size expression from the VLA type to determine the
initialization value.

rdar://problem/23748072

Modified:
cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
cfe/trunk/test/Analysis/lambdas.cpp

Modified: cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp?rev=254962&r1=254961&r2=254962&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp Mon Dec  7 17:01:53 2015
@@ -531,9 +531,23 @@ void ExprEngine::VisitLambdaExpr(const L
   for (LambdaExpr::const_capture_init_iterator i = LE->capture_init_begin(),
e = LE->capture_init_end();
i != e; ++i, ++CurField) {
-SVal Field = State->getLValue(*CurField, V);
-SVal InitExpr = State->getSVal(*i, LocCtxt);
-State = State->bindLoc(Field, InitExpr);
+FieldDecl *FieldForCapture = *CurField;
+SVal FieldLoc = State->getLValue(FieldForCapture, V);
+
+SVal InitVal;
+if (!FieldForCapture->hasCapturedVLAType()) {
+  Expr *InitExpr = *i;
+  assert(InitExpr && "Capture missing initialization expression");
+  InitVal = State->getSVal(InitExpr, LocCtxt);
+} else {
+  // The field stores the length of a captured variable-length array.
+  // These captures don't have initialization expressions; instead we
+  // get the length from the VLAType size expression.
+  Expr *SizeExpr = FieldForCapture->getCapturedVLAType()->getSizeExpr();
+  InitVal = State->getSVal(SizeExpr, LocCtxt);
+}
+
+State = State->bindLoc(FieldLoc, InitVal);
   }
 
   // Decay the Loc into an RValue, because there might be a

Modified: cfe/trunk/test/Analysis/lambdas.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/lambdas.cpp?rev=254962&r1=254961&r2=254962&view=diff
==
--- cfe/trunk/test/Analysis/lambdas.cpp (original)
+++ cfe/trunk/test/Analysis/lambdas.cpp Mon Dec  7 17:01:53 2015
@@ -173,6 +173,19 @@ void testFunctionPointerCapture() {
   clang_analyzer_eval(i == 6); // expected-warning{{TRUE}}
 }
 
+// Captured variable-length array.
+
+void testVariableLengthArrayCaptured() {
+  int n = 2;
+  int array[n];
+  array[0] = 7;
+
+  int i = [&]{
+return array[0];
+  }();
+
+  clang_analyzer_eval(i == 7); // expected-warning{{TRUE}}
+}
 
 // Test inline defensive checks
 int getNum();


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

Re: [PATCH] D15309: [CUDA] emit vtables only for classes with methods usable on this side of compilation.

[David Blaikie via cfe-commits]

On Mon, Dec 7, 2015 at 2:44 PM, Artem Belevich via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> tra created this revision.
> tra added reviewers: rsmith, jingyue, jpienaar.
> tra added a subscriber: cfe-commits.
>
> C++ emits vtables for classes that have key function present in the
> current TU. While we compile CUDA the fact that key function was found
> in this TU does not mean that we are going to generate code for it. E.g.
> vtable for a class with host-only methods should not be generated on
> device side, because we are not going to generate any code for the
> host-only methods during device-side compilation.
>
> During CUDA compilation this patch checks virtual methods' target
> attributes and
> returns key function only if all virtual methods in the class are suitable
> for the current
> compilation mode.
>
>
> http://reviews.llvm.org/D15309
>
> Files:
>   lib/AST/RecordLayoutBuilder.cpp
>   test/CodeGenCUDA/device-vtable.cu
>
> Index: test/CodeGenCUDA/device-vtable.cu
> ===
> --- /dev/null
> +++ test/CodeGenCUDA/device-vtable.cu
> @@ -0,0 +1,55 @@
> +// REQUIRES: x86-registered-target
> +// REQUIRES: nvptx-registered-target
> +
> +// Make sure we don't emit vtables for classes with methods that have
> +// inappropriate target attributes. Currently it's mostly needed in
> +// order to avoid emitting vtables for host-only classes on device
> +// side where we can't codegen them.
> +
> +// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -o - %s \
> +// RUN: | FileCheck %s -check-prefix=CHECK-HOST
> +// RUN: %clang_cc1 -triple nvptx64-nvidia-cuda -fcuda-is-device
> -emit-llvm -o - %s \
> +// RUN: | FileCheck %s -check-prefix=CHECK-DEVICE
> +
> +#include "Inputs/cuda.h"
> +
> +class H  {
> + public:
> +  virtual void method();
> +};
> +//CHECK-HOST: @_ZTV1H =
> +//CHECK-HOST-SAME: @_ZN1H6methodEv
> +//CHECK-DEVICE-NOT: @_ZTV1H =
> +
> +class D  {
> + public:
> +   __device__ virtual void method();
> +};
> +
> +//CHECK-DEVICE: @_ZTV1D
> +//CHECK-DEVICE-SAME: @_ZN1D6methodEv
> +//CHECK-HOST-NOT: @_ZTV1D
> +
> +// This is the case with mixed host and device virtual methods.  It's
> +// impossible to emit a valid vtable in that case because only host or
> +// only device methods would be available during host or device
> +// compilation. For now we'll not emit such vtable at all.
> +class HD  {
> + public:
> +   virtual void h_method();
> +   __device__ virtual void d_method();
> +};
> +//CHECK-BOTH-NOT: @_ZTV2HD
> +
> +void H::method() {}
> +//CHECK-HOST: define void @_ZN1H6methodEv
> +
> +void __device__ D::method() {}
> +//CHECK-DEVICE: define void @_ZN1D6methodEv
> +
> +void __device__ HD::d_method() {}
> +// CHECK-DEVICE: define void @_ZN2HD8d_methodEv
> +// CHECK-HOST-NOT: define void @_ZN2HD8d_methodEv
> +void HD::h_method() {}
> +// CHECK-HOST: define void @_ZN2HD8h_methodEv
> +// CHECK-DEVICE-NOT: define void @_ZN2HD8h_methodEv
> Index: lib/AST/RecordLayoutBuilder.cpp
> ===
> --- lib/AST/RecordLayoutBuilder.cpp
> +++ lib/AST/RecordLayoutBuilder.cpp
> @@ -1996,6 +1996,16 @@
>bool allowInlineFunctions =
>  Context.getTargetInfo().getCXXABI().canKeyFunctionBeInline();
>
> +  if (Context.getLangOpts().CUDA) {
> +const bool IsDevice = Context.getLangOpts().CUDAIsDevice;
>

Guess you intended to use this local variable, but didn't? ^


> +for (const CXXMethodDecl *MD : RD->methods())
> +  if (Context.getLangOpts().CUDAIsDevice &&
> !MD->hasAttr())
> +return nullptr;
> +  else if (!Context.getLangOpts().CUDAIsDevice &&
>

Drop the else after return (just "if/return/if/return")
(and/or you could roll both conditions into one if test - potentially even
using "std::any_of" (or llvm::any_of))


> +   !MD->hasAttr() &&
> MD->hasAttr())
> +return nullptr;
> +  }
> +
>for (const CXXMethodDecl *MD : RD->methods()) {
>  if (!MD->isVirtual())
>continue;
>
>
>
> ___
> 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

[PATCH] D15313: [Clang] Use range loops and autos in utils/TableGen/ClangAttrEmitter.cpp

[Eugene Zelenko via cfe-commits]

Eugene.Zelenko created this revision.
Eugene.Zelenko added reviewers: hans, aaron.ballman.
Eugene.Zelenko added a subscriber: cfe-commits.
Eugene.Zelenko set the repository for this revision to rL LLVM.

I fixed Clang-tidy modernize-loop-convert and modernize-use-auto. Autos are 
also used for pointer variables assigned via casts. Patch includes other minor 
cleanups.

Fixes are in both source and generated code.

Build and regressions were finr on RHEL 6.

Repository:
  rL LLVM

http://reviews.llvm.org/D15313

Files:
  utils/TableGen/ClangAttrEmitter.cpp

Index: utils/TableGen/ClangAttrEmitter.cpp
===
--- utils/TableGen/ClangAttrEmitter.cpp
+++ utils/TableGen/ClangAttrEmitter.cpp
@@ -619,7 +619,7 @@
 std::vector uniques;
 std::set unique_set(enums.begin(), enums.end());
 for (const auto &i : enums) {
-  std::set::iterator set_i = unique_set.find(i);
+  auto set_i = unique_set.find(i);
   if (set_i != unique_set.end()) {
 uniques.push_back(i);
 unique_set.erase(set_i);
@@ -665,8 +665,7 @@
   OS << type << " " << getUpperName();
 }
 void writeDeclarations(raw_ostream &OS) const override {
-  std::vector::const_iterator i = uniques.begin(),
-   e = uniques.end();
+  auto i = uniques.cbegin(), e = uniques.cend();
   // The last one needs to not have a comma.
   --e;
 
@@ -771,8 +770,7 @@
 bool isVariadicEnumArg() const override { return true; }
 
 void writeDeclarations(raw_ostream &OS) const override {
-  std::vector::const_iterator i = uniques.begin(),
-   e = uniques.end();
+  auto i = uniques.cbegin(), e = uniques.cend();
   // The last one needs to not have a comma.
   --e;
 
@@ -958,7 +956,7 @@
 }
 
 void writeTemplateInstantiation(raw_ostream &OS) const override {
-  OS << "  " << getType() << " *tempInst" << getUpperName()
+  OS << "  auto *tempInst" << getUpperName()
  << " = new (C, 16) " << getType()
  << "[A->" << getLowerName() << "_size()];\n";
   OS << "  {\n";
@@ -1537,7 +1535,7 @@
   }
   OS << ", SourceRange Loc = SourceRange()";
   OS << ") {\n";
-  OS << "" << R.getName() << "Attr *A = new (Ctx) " << R.getName();
+  OS << "auto *A = new (Ctx) " << R.getName();
   OS << "Attr(Loc, Ctx, ";
   for (auto const &ai : Args) {
 if (ai->isFake() && !emitFake) continue;
@@ -1654,7 +1652,7 @@
 OS << "};\n\n";
   }
 
-  OS << "#endif\n";
+  OS << "#endif // LLVM_CLANG_ATTR_CLASSES_INC\n";
 }
 
 // Emits the class method definitions for attributes.
@@ -1729,7 +1727,7 @@
 
 static void EmitAttrList(raw_ostream &OS, StringRef Class,
  const std::vector &AttrList) {
-  std::vector::const_iterator i = AttrList.begin(), e = AttrList.end();
+  auto i = AttrList.cbegin(), e = AttrList.cend();
 
   if (i != e) {
 // Move the end iterator back to emit the last attribute.
@@ -1881,7 +1879,7 @@
 OS << "  case attr::" << R.getName() << ": {\n";
 Args = R.getValueAsListOfDefs("Args");
 if (R.isSubClassOf(InhClass) || !Args.empty())
-  OS << "const " << R.getName() << "Attr *SA = cast<" << R.getName()
+  OS << "const auto *SA = cast<" << R.getName()
  << "Attr>(A);\n";
 if (R.isSubClassOf(InhClass))
   OS << "Record.push_back(SA->isInherited());\n";
@@ -2045,9 +2043,7 @@
   GenerateHasAttrSpellingStringSwitch(Pragma, OS, "Pragma");
   OS << "case AttrSyntax::CXX: {\n";
   // C++11-style attributes are further split out based on the Scope.
-  for (std::map>::iterator I = CXX.begin(),
-  E = CXX.end();
-   I != E; ++I) {
+  for (auto I = CXX.cbegin(), E = CXX.cend(); I != E; ++I) {
 if (I != CXX.begin())
   OS << " else ";
 if (I->first.empty())
@@ -2197,7 +2193,7 @@
   continue;
 }
 
-OS << "  const " << R.getName() << "Attr *A = cast<"
+OS << "  const auto *A = cast<"
<< R.getName() << "Attr>(At);\n";
 bool TDependent = R.getValueAsBit("TemplateDependent");
 
@@ -2405,7 +2401,7 @@
   // If this code has already been generated, simply return the previous
   // instance of it.
   static std::set CustomSubjectSet;
-  std::set::iterator I = CustomSubjectSet.find(FnName);
+  const auto I = CustomSubjectSet.find(FnName);
   if (I != CustomSubjectSet.end())
 return *I;
 
@@ -2419,7 +2415,7 @@
   }
 
   OS << "static bool " << FnName << "(const Decl *D) {\n";
-  OS << "  if (const " << GetSubjectWithSuffix(Base) << " *S = dyn_cast<";
+  OS << "  if (const auto *S = dyn_cast<";
   OS << GetSubjectWithSuffix(Base);
   OS << ">(D))\n";
   OS << "return " << Subject.getValueAsString("CheckCode") << ";\n";
@@ -2519,7 +2515,7 @@
   // If this code has already been generated, simply return the previo

[PATCH] D15314: Fix a bug in unavailable checking

[Manman Ren via cfe-commits]

manmanren created this revision.
manmanren added reviewers: rjmccall, rsmith.
manmanren added a subscriber: cfe-commits.

The issue —
Given the following test case, we don’t emit any message, and will silently 
ignore the variable "foo2", with a release compiler; we will get an assertion 
failure with an assert compiler.
typedef struct {
  const char *name;
  id field;
} Test9;

extern void doSomething(Test9 arg);
void test9() {
Test9 foo2 = {0, 0};
doSomething(foo2);
}

The root cause —
Back in r140457 we gave InitListChecker a verification-only mode, and will use 
CanUseDecl instead of DiagnoseUseOfDecl for verification-only mode.
These two functions handle unavailable issues differently:
In Sema::CanUseDecl, we say the decl is invalid with the following condition
  if (D->getAvailability() == AR_Unavailable &&
  cast(CurContext)->getAvailability() != AR_Unavailable)
In Sema::DiagnoseUseOfDecl, we say the decl is usable by ignoring the return 
code of DiagnoseAvailabilityOfDecl

So with an assert build, we will hit an assertion in diagnoseListInit
  assert(DiagnoseInitList.HadError() &&
 "Inconsistent init list check result.");

The question is how to make the two consistent, should we follow what is 
implemented in CanUseDecl or DiagnoseUseOfDecl?
If we follow what is implemented in CanUseDecl and treat Decls with unavailable 
issues as invalid, the variable decl of “foo2” will be marked as invalid.
Since unavailable checking is processed in delayed diagnostics (r197627), we 
will silently ignore the diagnostics when we find out that the variable decl is 
invalid.

In Sema::PopParsingDeclaration
  switch (diag.Kind) {
  case DelayedDiagnostic::Deprecation:
  case DelayedDiagnostic::Unavailable:
// Don't bother giving deprecation/unavailable diagnostics if
// the decl is invalid.
if (!decl->isInvalidDecl())
  handleDelayedAvailabilityCheck(*this, diag, decl);

The proposed fix ———
It seems that for overload resolution, we want to say decls with unavailable 
issues are invalid; but for everything else, we should say they are valid but
emit diagnostics. For this, we can add another flag “UnavailableCheck” for the 
verification-only mode. Depending on the value of the flag, CanUseDecl
can return different values for unavailable issues.

Feedback is appreciated. Any other suggestion is welcome.

Cheers,
Manman

http://reviews.llvm.org/D15314

Files:
  include/clang/Sema/Initialization.h
  include/clang/Sema/Sema.h
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaInit.cpp
  test/SemaObjC/Inputs/arc-system-header.h
  test/SemaObjC/arc-system-header.m

Index: test/SemaObjC/arc-system-header.m
===
--- test/SemaObjC/arc-system-header.m
+++ test/SemaObjC/arc-system-header.m
@@ -46,6 +46,13 @@
 // expected-note@arc-system-header.h:41 4 {{declaration uses type that is ill-formed in ARC}}
 // expected-note@arc-system-header.h:41 2 {{property 'prop' is declared unavailable here}}
 }
+
+extern void doSomething(Test9 arg);
+void test9() {
+Test9 foo2 = {0, 0}; // expected-error {{'field' is unavailable in ARC}}
+ // expected-note@arc-system-header.h:56 {{field has non-trivial ownership qualification}}
+doSomething(foo2);
+}
 #endif
 
 // test8 in header
Index: test/SemaObjC/Inputs/arc-system-header.h
===
--- test/SemaObjC/Inputs/arc-system-header.h
+++ test/SemaObjC/Inputs/arc-system-header.h
@@ -50,3 +50,8 @@
 static inline void *test8(id ptr) {
   return (__bridge_retain void*) ptr;
 }
+
+typedef struct {
+  const char *name;
+  id field;
+} Test9;
Index: lib/Sema/SemaInit.cpp
===
--- lib/Sema/SemaInit.cpp
+++ lib/Sema/SemaInit.cpp
@@ -236,6 +236,7 @@
   Sema &SemaRef;
   bool hadError;
   bool VerifyOnly; // no diagnostics, no structure building
+  bool UnavailableCheck; // Used only in VerifyOnly mode.
   llvm::DenseMap SyntacticToSemantic;
   InitListExpr *FullyStructuredList;
 
@@ -317,7 +318,7 @@
   static ExprResult PerformEmptyInit(Sema &SemaRef,
  SourceLocation Loc,
  const InitializedEntity &Entity,
- bool VerifyOnly);
+ bool VerifyOnly, bool UnavailableCheck);
 
   // Explanation on the "FillWithNoInit" mode:
   //
@@ -353,7 +354,8 @@
 
 public:
   InitListChecker(Sema &S, const InitializedEntity &Entity,
-  InitListExpr *IL, QualType &T, bool VerifyOnly);
+  InitListExpr *IL, QualType &T, bool VerifyOnly,
+  bool UnavailableCheck);
   bool HadError() { return hadError; }
 
   // @brief Retrieves the fully-structured initializer list used for
@@ -365,7 +367,8 @@
 ExprResult InitListCheck

Re: [PATCH] D15309: [CUDA] emit vtables only for classes with methods usable on this side of compilation.

[Artem Belevich via cfe-commits]

On Mon, Dec 7, 2015 at 3:20 PM, David Blaikie  wrote:

> Index: lib/AST/RecordLayoutBuilder.cpp
>> ===
>> --- lib/AST/RecordLayoutBuilder.cpp
>> +++ lib/AST/RecordLayoutBuilder.cpp
>> @@ -1996,6 +1996,16 @@
>>bool allowInlineFunctions =
>>  Context.getTargetInfo().getCXXABI().canKeyFunctionBeInline();
>>
>> +  if (Context.getLangOpts().CUDA) {
>> +const bool IsDevice = Context.getLangOpts().CUDAIsDevice;
>>
>
> Guess you intended to use this local variable, but didn't? ^
>
>
Yup. Leftover from reshuffling the code. Nuked.


> +for (const CXXMethodDecl *MD : RD->methods())
>> +  if (Context.getLangOpts().CUDAIsDevice &&
>> !MD->hasAttr())
>> +return nullptr;
>> +  else if (!Context.getLangOpts().CUDAIsDevice &&
>>
>
> Drop the else after return (just "if/return/if/return")
> (and/or you could roll both conditions into one if test - potentially even
> using "std::any_of" (or llvm::any_of))
>
>

Nice. It might be just the function to do the job.

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

Re: [PATCH] D12761: MPI-Checker patch for Clang Static Analyzer

[Alexander Kornienko via cfe-commits]

alexfh added a comment.

The only conclusion I can make is that this patch is huge and very inconvenient 
to review. I'm fine with moving the AST-based checks to clang-tidy, but I 
strongly prefer each separate check to go in a separate patch.


http://reviews.llvm.org/D12761



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

[libcxx] r254971 - Cleaned up the intro for the TS status page; really need much more info here

[Marshall Clow via cfe-commits]

Author: marshall
Date: Mon Dec  7 18:08:23 2015
New Revision: 254971

URL: http://llvm.org/viewvc/llvm-project?rev=254971&view=rev
Log:
Cleaned up the intro for the TS status page; really need much more info here

Modified:
libcxx/trunk/www/ts1z_status.html

Modified: libcxx/trunk/www/ts1z_status.html
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/ts1z_status.html?rev=254971&r1=254970&r2=254971&view=diff
==
--- libcxx/trunk/www/ts1z_status.html (original)
+++ libcxx/trunk/www/ts1z_status.html Mon Dec  7 18:08:23 2015
@@ -35,8 +35,8 @@
   Post-C++14 TS Implementation Status
   
 
-  In April 2013, the C++ standard committee approved the draft for the next 
version of the C++ standard, known as "C++1Y" (probably to be C++14)
-  The draft standard includes papers and issues that were voted on at the 
previous three meetings (Kona, Portland, and Bristol)
+  In November 2014, the C++ standard committee approved the draft for the 
next version of the C++ standard, known as "C++1z" (probably to be C++17)
+  In addition, there are several "Technical Specifications", that consist 
of new features that are proposed, but not yet accepted for C++1z.
   This page shows the status of libc++; the status of clang's support of 
the language features is http://clang.llvm.org/cxx_status.html";>here.
 
   Technical Specifications
@@ -95,7 +95,7 @@
 
   
 
-  Last Updated: 21-Jul-2015
+  Last Updated: 7-Dec-2015
 
 
 


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

r254973 - 80-column fixup.

[Eric Christopher via cfe-commits]

Author: echristo
Date: Mon Dec  7 18:10:13 2015
New Revision: 254973

URL: http://llvm.org/viewvc/llvm-project?rev=254973&view=rev
Log:
80-column fixup.

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=254973&r1=254972&r2=254973&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Mon Dec  7 18:10:13 2015
@@ -9984,7 +9984,8 @@ void tools::Myriad::Linker::ConstructJob
   static_cast(getToolChain());
   const llvm::Triple &T = TC.getTriple();
   ArgStringList CmdArgs;
-  bool UseStartfiles = !Args.hasArg(options::OPT_nostdlib, 
options::OPT_nostartfiles);
+  bool UseStartfiles =
+  !Args.hasArg(options::OPT_nostdlib, options::OPT_nostartfiles);
   bool UseDefaultLibs =
   !Args.hasArg(options::OPT_nostdlib, options::OPT_nodefaultlibs);
 


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

r254972 - Update comment.

[Eric Christopher via cfe-commits]

Author: echristo
Date: Mon Dec  7 18:10:10 2015
New Revision: 254972

URL: http://llvm.org/viewvc/llvm-project?rev=254972&view=rev
Log:
Update comment.

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=254972&r1=254971&r2=254972&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Mon Dec  7 18:10:10 2015
@@ -6639,11 +6639,11 @@ void darwin::Assembler::ConstructJob(Com
 SourceAction = SourceAction->getInputs()[0];
   }
 
-  // If -fno_integrated_as is used add -Q to the darwin assember driver to make
+  // If -fno-integrated-as is used add -Q to the darwin assember driver to make
   // sure it runs its system assembler not clang's integrated assembler.
   // Applicable to darwin11+ and Xcode 4+.  darwin<10 lacked integrated-as.
   // FIXME: at run-time detect assembler capabilities or rely on version
-  // information forwarded by -target-assembler-version (future)
+  // information forwarded by -target-assembler-version.
   if (Args.hasArg(options::OPT_fno_integrated_as)) {
 const llvm::Triple &T(getToolChain().getTriple());
 if (!(T.isMacOSX() && T.isMacOSXVersionLT(10, 7)))


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

Re: [PATCH] D15309: [CUDA] emit vtables only for classes with methods usable on this side of compilation.

[Artem Belevich via cfe-commits]

tra updated this revision to Diff 42122.
tra added a comment.

Removed unnecessary temporary variable and 'else'.


http://reviews.llvm.org/D15309

Files:
  lib/AST/RecordLayoutBuilder.cpp
  test/CodeGenCUDA/device-vtable.cu

Index: test/CodeGenCUDA/device-vtable.cu
===
--- /dev/null
+++ test/CodeGenCUDA/device-vtable.cu
@@ -0,0 +1,55 @@
+// REQUIRES: x86-registered-target
+// REQUIRES: nvptx-registered-target
+
+// Make sure we don't emit vtables for classes with methods that have
+// inappropriate target attributes. Currently it's mostly needed in
+// order to avoid emitting vtables for host-only classes on device
+// side where we can't codegen them.
+
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -o - %s \
+// RUN: | FileCheck %s -check-prefix=CHECK-HOST
+// RUN: %clang_cc1 -triple nvptx64-nvidia-cuda -fcuda-is-device -emit-llvm -o 
- %s \
+// RUN: | FileCheck %s -check-prefix=CHECK-DEVICE
+
+#include "Inputs/cuda.h"
+
+class H  {
+ public:
+  virtual void method();
+};
+//CHECK-HOST: @_ZTV1H =
+//CHECK-HOST-SAME: @_ZN1H6methodEv
+//CHECK-DEVICE-NOT: @_ZTV1H =
+
+class D  {
+ public:
+   __device__ virtual void method();
+};
+
+//CHECK-DEVICE: @_ZTV1D
+//CHECK-DEVICE-SAME: @_ZN1D6methodEv
+//CHECK-HOST-NOT: @_ZTV1D
+
+// This is the case with mixed host and device virtual methods.  It's
+// impossible to emit a valid vtable in that case because only host or
+// only device methods would be available during host or device
+// compilation. For now we'll not emit such vtable at all.
+class HD  {
+ public:
+   virtual void h_method();
+   __device__ virtual void d_method();
+};
+//CHECK-BOTH-NOT: @_ZTV2HD
+
+void H::method() {}
+//CHECK-HOST: define void @_ZN1H6methodEv
+
+void __device__ D::method() {}
+//CHECK-DEVICE: define void @_ZN1D6methodEv
+
+void __device__ HD::d_method() {}
+// CHECK-DEVICE: define void @_ZN2HD8d_methodEv
+// CHECK-HOST-NOT: define void @_ZN2HD8d_methodEv
+void HD::h_method() {}
+// CHECK-HOST: define void @_ZN2HD8h_methodEv
+// CHECK-DEVICE-NOT: define void @_ZN2HD8h_methodEv
Index: lib/AST/RecordLayoutBuilder.cpp
===
--- lib/AST/RecordLayoutBuilder.cpp
+++ lib/AST/RecordLayoutBuilder.cpp
@@ -1996,6 +1996,15 @@
   bool allowInlineFunctions =
 Context.getTargetInfo().getCXXABI().canKeyFunctionBeInline();
 
+  if (Context.getLangOpts().CUDA)
+for (const CXXMethodDecl *MD : RD->methods()) {
+  if (Context.getLangOpts().CUDAIsDevice && !MD->hasAttr())
+return nullptr;
+  if (!Context.getLangOpts().CUDAIsDevice && !MD->hasAttr() 
&&
+  MD->hasAttr())
+return nullptr;
+}
+
   for (const CXXMethodDecl *MD : RD->methods()) {
 if (!MD->isVirtual())
   continue;


Index: test/CodeGenCUDA/device-vtable.cu
===
--- /dev/null
+++ test/CodeGenCUDA/device-vtable.cu
@@ -0,0 +1,55 @@
+// REQUIRES: x86-registered-target
+// REQUIRES: nvptx-registered-target
+
+// Make sure we don't emit vtables for classes with methods that have
+// inappropriate target attributes. Currently it's mostly needed in
+// order to avoid emitting vtables for host-only classes on device
+// side where we can't codegen them.
+
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -o - %s \
+// RUN: | FileCheck %s -check-prefix=CHECK-HOST
+// RUN: %clang_cc1 -triple nvptx64-nvidia-cuda -fcuda-is-device -emit-llvm -o - %s \
+// RUN: | FileCheck %s -check-prefix=CHECK-DEVICE
+
+#include "Inputs/cuda.h"
+
+class H  {
+ public:
+  virtual void method();
+};
+//CHECK-HOST: @_ZTV1H =
+//CHECK-HOST-SAME: @_ZN1H6methodEv
+//CHECK-DEVICE-NOT: @_ZTV1H =
+
+class D  {
+ public:
+   __device__ virtual void method();
+};
+
+//CHECK-DEVICE: @_ZTV1D
+//CHECK-DEVICE-SAME: @_ZN1D6methodEv
+//CHECK-HOST-NOT: @_ZTV1D
+
+// This is the case with mixed host and device virtual methods.  It's
+// impossible to emit a valid vtable in that case because only host or
+// only device methods would be available during host or device
+// compilation. For now we'll not emit such vtable at all.
+class HD  {
+ public:
+   virtual void h_method();
+   __device__ virtual void d_method();
+};
+//CHECK-BOTH-NOT: @_ZTV2HD
+
+void H::method() {}
+//CHECK-HOST: define void @_ZN1H6methodEv
+
+void __device__ D::method() {}
+//CHECK-DEVICE: define void @_ZN1D6methodEv
+
+void __device__ HD::d_method() {}
+// CHECK-DEVICE: define void @_ZN2HD8d_methodEv
+// CHECK-HOST-NOT: define void @_ZN2HD8d_methodEv
+void HD::h_method() {}
+// CHECK-HOST: define void @_ZN2HD8h_methodEv
+// CHECK-DEVICE-NOT: define void @_ZN2HD8h_methodEv
Index: lib/AST/RecordLayoutBuilder.cpp
===
--- lib/AST/RecordLayoutBuilder.cpp
+++ lib/AST/RecordLayoutBuilder.cpp
@@ -1996,6 +1996,15 @@
   bool allowInlineFunctions =
 Context.getTargetInfo().

Buildbot numbers for week of 11/29/2015 - 12/05/2015

[Galina Kistanova via cfe-commits]

Hello everyone,

Below are some buildbot numbers for the last week of 11/29/2015 -
12/05/2015.

Thanks

Galina



Top 10 fastest builders(not docs):

 lldb-amd64-ninja-freebsd11
 clang-bpf-build
 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast
 libomp-gcc-x86_64-linux-debian
 sanitizer-windows
 llvm-hexagon-elf
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14
 lldb-x86-win7-msvc


 10 most slow builders:

 clang-native-arm-lnt-perf
 clang-atom-d525-fedora
 clang-cmake-thumbv7-a15-full-sh
 clang-native-aarch64-full
 perf-x86_64-penryn-O3-polly
 perf-x86_64-penryn-O3
 llvm-mips-linux
 clang-cmake-armv7-a15-selfhost-neon
 clang-cmake-armv7-a15-selfhost
 ppc64le-clang



Number of commits by project:

 project   |   commits
---+---
 llvm  |   337
 cfe   |83
 lldb  |50
 compiler-rt   |47
 lld   |21
 libcxx| 9
 clang-tools-extra | 7
 polly | 6
 openmp| 4
 libcxxabi | 3
 ---
   567


Number of completed builds, failed builds and average build time for
successful builds per active builder:

 buildername   | completed  |
failed | time
-
 clang-aarch64-lnt | 58
|  2 | 02:32:07
 clang-atom-d525-fedora| 15
|| 08:44:10
 clang-atom-d525-fedora-rel| 69
|| 01:40:33
 clang-bpf-build   |339
|  7 | 00:03:00
 clang-cmake-aarch64-42vma |276
| 14 | 00:18:01
 clang-cmake-aarch64-full  | 38
| 11 | 03:09:07
 clang-cmake-aarch64-quick |215
|  6 | 00:25:45
 clang-cmake-armv7-a15 |189
|  9 | 00:28:01
 clang-cmake-armv7-a15-full|144
|  6 | 00:44:34
 clang-cmake-armv7-a15-selfhost| 36
|  6 | 03:52:55
 clang-cmake-armv7-a15-selfhost-neon   | 30
|  5 | 04:52:57
 clang-cmake-mips  |211
| 17 | 00:27:43
 clang-cmake-thumbv7-a15   |180
| 11 | 00:29:57
 clang-cmake-thumbv7-a15-full-sh   | 16
|  2 | 06:40:33
 clang-hexagon-elf |251
| 44 | 00:16:38
 clang-native-aarch64-full | 24
|| 06:24:15
 clang-native-arm-lnt  | 81
|  4 | 01:07:36
 clang-native-arm-lnt-perf | 10
|  1 | 09:45:56
 clang-ppc64-elf-linux |119
|  1 | 01:04:37
 clang-ppc64-elf-linux2| 84
|  3 | 01:37:48
 clang-sphinx-docs |121
|| 00:00:22
 clang-x64-ninja-win7  |193
| 49 | 00:35:14
 clang-x86-win2008-selfhost|129
| 28 | 01:04:06
 clang-x86_64-darwin13-cross-arm   |245
|  4 | 00:20:08
 clang-x86_64-darwin13-cross-mingw32   |223
|  3 | 00:23:48
 clang-x86_64-debian-fast  |153
|| 00:11:37
 clang-x86_64-linux-abi-test   |342
|  2 | 00:18:53
 clang-x86_64-linux-selfhost-modules   |275
| 65 | 00:15:13
 clang-x86_64-ubuntu-gdb-75|143
| 25 | 00:50:20
 libcxx-libcxxabi-arm-linux|  3
|| 01:10:06
 libcxx-libcxxabi-singlethreaded-x86_64-linux-debian   |  6
|  1 | 00:08:42
 libcxx-libcxxabi-x86_64-linux-debian  |  6
|| 00:09:05
 libcxx-libcxxabi-x86_64-linux-debian-noexceptions |  5
|| 00:08:53
 libcxx-libcxxabi-x86_64-linux-ubuntu-asan |  5
|| 00:12:40
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03|  5
|| 00:06:10
 

Re: [PATCH] D13330: Implement __attribute__((unique_instantiation))

[Keno Fischer via cfe-commits]

loladiro added inline comments.


Comment at: lib/AST/ASTContext.cpp:8257-8266
@@ -8256,1 +8256,12 @@
 
+bool ASTContext::containedInUniqueInstantiation(const Decl *D) {
+  const RecordDecl *RD;
+  while ((RD = dyn_cast(D->getDeclContext( {
+auto *CTSD = dyn_cast(RD);
+if (CTSD && CTSD->hasAttr())
+  return true;
+D = RD;
+  }
+  return false;
+}
+

majnemer wrote:
> Function templates can contain class templates which contain functions.  I 
> think this code will return false if the outermost function template is the 
> only one annotated with UniqueInstantiationAttr.
So you're concerned about this case:
```
template < typename T > auto foo( T x ) {
  class inner {
  T y;
  public:
  virtual ~inner() {}
  inner(T y) : y(y) {}
  T getY() { return y; }
  };
  return inner{x}.getY();
}

extern template __attribute__((unique_instantiation)) auto foo(int);
template __attribute__((unique_instantiation)) auto foo(int);
```
Right now the inner class's vtable and method is linkonce_odr. If you think it 
should be strong I'll look into it.


http://reviews.llvm.org/D13330



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

r254981 - [diagnostics] Avoid crashes while printing macro backtraces

[Reid Kleckner via cfe-commits]

Author: rnk
Date: Mon Dec  7 19:08:09 2015
New Revision: 254981

URL: http://llvm.org/viewvc/llvm-project?rev=254981&view=rev
Log:
[diagnostics] Avoid crashes while printing macro backtraces

When attempting to map a source into a given level of macro expansion,
this code was ignoring the possibility that the start and end of the
range might take wildly different paths through the tree of macro
expansions. It was assuming that the begin spelling location would
always precede the end spelling location, which is false. A macro can
easily transpose its arguments.

This also fixes a related issue where there are extra macro arguments
between the begin location and the end location. In this situation, we
now highlight the entire macro invocation.

Pair programmed with Richard Smith.

Fixes PR12818.

Modified:
cfe/trunk/lib/Frontend/DiagnosticRenderer.cpp
cfe/trunk/test/Misc/caret-diags-macros.c

Modified: cfe/trunk/lib/Frontend/DiagnosticRenderer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/DiagnosticRenderer.cpp?rev=254981&r1=254980&r2=254981&view=diff
==
--- cfe/trunk/lib/Frontend/DiagnosticRenderer.cpp (original)
+++ cfe/trunk/lib/Frontend/DiagnosticRenderer.cpp Mon Dec  7 19:08:09 2015
@@ -308,34 +308,77 @@ void DiagnosticRenderer::emitModuleBuild
 
 /// A recursive function to trace all possible backtrace locations
 /// to match the \p CaretLocFileID.
-static SourceLocation retrieveMacroLocation(SourceLocation Loc,
-FileID MacroFileID,
-FileID CaretFileID,
-bool getBeginLoc,
-const SourceManager *SM) {
-  if (MacroFileID == CaretFileID) return Loc;
-  if (!Loc.isMacroID()) return SourceLocation();
+static SourceLocation
+retrieveMacroLocation(SourceLocation Loc, FileID MacroFileID,
+  FileID CaretFileID,
+  const SmallVectorImpl &CommonArgExpansions,
+  bool IsBegin, const SourceManager *SM) {
+  assert(SM->getFileID(Loc) == MacroFileID);
+  if (MacroFileID == CaretFileID)
+return Loc;
+  if (!Loc.isMacroID())
+return SourceLocation();
 
   SourceLocation MacroLocation, MacroArgLocation;
 
   if (SM->isMacroArgExpansion(Loc)) {
-MacroLocation = SM->getImmediateSpellingLoc(Loc);
-MacroArgLocation = getBeginLoc ? SM->getImmediateExpansionRange(Loc).first
-   : 
SM->getImmediateExpansionRange(Loc).second;
+// Only look at the immediate spelling location of this macro argument if
+// the other location in the source range is also present in that 
expansion.
+if (std::binary_search(CommonArgExpansions.begin(),
+   CommonArgExpansions.end(), MacroFileID))
+  MacroLocation = SM->getImmediateSpellingLoc(Loc);
+MacroArgLocation = IsBegin ? SM->getImmediateExpansionRange(Loc).first
+   : SM->getImmediateExpansionRange(Loc).second;
   } else {
-MacroLocation = getBeginLoc ? SM->getImmediateExpansionRange(Loc).first
-: SM->getImmediateExpansionRange(Loc).second;
+MacroLocation = IsBegin ? SM->getImmediateExpansionRange(Loc).first
+: SM->getImmediateExpansionRange(Loc).second;
 MacroArgLocation = SM->getImmediateSpellingLoc(Loc);
   }
 
-  MacroFileID = SM->getFileID(MacroLocation);
-  MacroLocation = retrieveMacroLocation(MacroLocation, MacroFileID, 
CaretFileID,
-getBeginLoc, SM);
-  if (MacroLocation.isValid()) return MacroLocation;
+  if (MacroLocation.isValid()) {
+MacroFileID = SM->getFileID(MacroLocation);
+MacroLocation =
+retrieveMacroLocation(MacroLocation, MacroFileID, CaretFileID,
+  CommonArgExpansions, IsBegin, SM);
+if (MacroLocation.isValid())
+  return MacroLocation;
+  }
 
   MacroFileID = SM->getFileID(MacroArgLocation);
   return retrieveMacroLocation(MacroArgLocation, MacroFileID, CaretFileID,
-   getBeginLoc, SM);
+   CommonArgExpansions, IsBegin, SM);
+}
+
+/// Walk up the chain of macro expansions and collect the FileIDs identifying 
the
+/// expansions.
+static void getMacroArgExpansionFileIDs(SourceLocation Loc,
+SmallVectorImpl &IDs,
+bool IsBegin, const SourceManager *SM) 
{
+  while (Loc.isMacroID()) {
+if (SM->isMacroArgExpansion(Loc)) {
+  IDs.push_back(SM->getFileID(Loc));
+  Loc = SM->getImmediateSpellingLoc(Loc);
+} else {
+  auto ExpRange = SM->getImmediateExpansionRange(Loc);
+  Loc = IsBegin ? ExpRange.first : ExpRange.second;
+}
+  }
+}
+
+/// Collect the expansions of the begin and end locations and comp

[PATCH] D15319: [Sema] Don't accept e.g. "(int *)(long)&x" as a constant expression if x is in address space != 0.

[Manuel Jacob via cfe-commits]

mjacob created this revision.
mjacob added a reviewer: rsmith.
mjacob added subscribers: cfe-commits, alex.

The constant expression evaluator for pointers returns a base and an
offset if successful.  In this case, CodeGen generates a constant pointer cast,
casting the base (with offset applied if necessary) to the destination type.
However, that is different from casting the base to an integer and then to the
destination type if the destination points to another address space as the
base.  Supporting this would require a lot of work because it can't be
expressed as base + offset.  Changing the whole constant expression evaluator
is not worthline for supporting this special case.

http://reviews.llvm.org/D15319

Files:
  lib/AST/ExprConstant.cpp
  test/Sema/const-eval.c

Index: test/Sema/const-eval.c
===
--- test/Sema/const-eval.c
+++ test/Sema/const-eval.c
@@ -137,3 +137,6 @@
 void PR24622();
 struct PR24622 {} pr24622;
 EVAL_EXPR(52, &pr24622 == (void *)&PR24622); // expected-error {{must have a 
constant size}}
+
+int __attribute__((address_space(1))) addrspace1;
+int *addrspace0_ptr = (int *)(long)&addrspace1; // expected-error {{not a 
compile-time constant}}
Index: lib/AST/ExprConstant.cpp
===
--- lib/AST/ExprConstant.cpp
+++ lib/AST/ExprConstant.cpp
@@ -4995,7 +4995,11 @@
   Result.Designator.setInvalid();
   return true;
 } else {
-  // Cast is of an lvalue, no need to change value.
+  // Cast is of an lvalue, no need to change value, unless they have
+  // different address spaces.
+  if (Info.Ctx.getTargetAddressSpace(getType(Value.getLValueBase())) !=
+  Info.Ctx.getTargetAddressSpace(E->getType()->getPointeeType()))
+return false;
   Result.setFrom(Info.Ctx, Value);
   return true;
 }


Index: test/Sema/const-eval.c
===
--- test/Sema/const-eval.c
+++ test/Sema/const-eval.c
@@ -137,3 +137,6 @@
 void PR24622();
 struct PR24622 {} pr24622;
 EVAL_EXPR(52, &pr24622 == (void *)&PR24622); // expected-error {{must have a constant size}}
+
+int __attribute__((address_space(1))) addrspace1;
+int *addrspace0_ptr = (int *)(long)&addrspace1; // expected-error {{not a compile-time constant}}
Index: lib/AST/ExprConstant.cpp
===
--- lib/AST/ExprConstant.cpp
+++ lib/AST/ExprConstant.cpp
@@ -4995,7 +4995,11 @@
   Result.Designator.setInvalid();
   return true;
 } else {
-  // Cast is of an lvalue, no need to change value.
+  // Cast is of an lvalue, no need to change value, unless they have
+  // different address spaces.
+  if (Info.Ctx.getTargetAddressSpace(getType(Value.getLValueBase())) !=
+  Info.Ctx.getTargetAddressSpace(E->getType()->getPointeeType()))
+return false;
   Result.setFrom(Info.Ctx, Value);
   return true;
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

[Reid Kleckner via cfe-commits]

It wasn't Chrome, it was some internal dependency on torch-cephes. I
submitted a patch for it upstream:
https://github.com/deepmind/torch-cephes/commit/9c4a97c90dc200ecbecb883e7230fe3c847954df
It's not a pretty, though.

I know LLVM IR rules are not C++ rules, but LLVM generally believes in NaN.
It will speculate things like fdiv above branches, leading to traps when
people configure the FPU appropriately and then conditionally divide by
zero. It would be more consistent for Clang to follow the LLVM direction
here. The fact that C++ says that FP div-by-zero is UB might just be a bug
in the standard, or a grey area that couldn't be filled in.

On Mon, Dec 7, 2015 at 2:37 PM, David Majnemer 
wrote:

>
>
> On Mon, Dec 7, 2015 at 5:25 PM, Hans Wennborg  wrote:
>
>> On Mon, Dec 7, 2015 at 2:14 PM, David Majnemer 
>> wrote:
>> >
>> >
>> > On Mon, Dec 7, 2015 at 4:32 PM, Richard Smith via cfe-commits
>> >  wrote:
>> >>
>> >> On Mon, Dec 7, 2015 at 7:25 AM, Joerg Sonnenberger via cfe-commits
>> >>  wrote:
>> >>>
>> >>> On Thu, Dec 03, 2015 at 01:36:22AM -, Richard Smith via
>> cfe-commits
>> >>> wrote:
>> >>> > Author: rsmith
>> >>> > Date: Wed Dec  2 19:36:22 2015
>> >>> > New Revision: 254574
>> >>> >
>> >>> > URL: http://llvm.org/viewvc/llvm-project?rev=254574&view=rev
>> >>> > Log:
>> >>> > PR17381: Treat undefined behavior during expression evaluation as an
>> >>> > unmodeled
>> >>> > side-effect, so that we don't allow speculative evaluation of such
>> >>> > expressions
>> >>> > during code generation.
>> >>> >
>> >>> > This caused a diagnostic quality regression, so fix constant
>> expression
>> >>> > diagnostics to prefer either the first "can't be constant folded"
>> >>> > diagnostic or
>> >>> > the first "not a constant expression" diagnostic depending on the
>> kind
>> >>> > of
>> >>> > evaluation we're doing. This was always the intent, but didn't quite
>> >>> > work
>> >>> > correctly before.
>> >>> >
>> >>> > This results in certain initializers that used to be constant
>> >>> > initializers to
>> >>> > no longer be; in particular, things like:
>> >>> >
>> >>> >   float f = 1e100;
>> >>> >
>> >>> > are no longer accepted in C. This seems appropriate, as such
>> constructs
>> >>> > would
>> >>> > lead to code being executed if sanitizers are enabled.
>> >>>
>> >>> This leads to some pretty annoying regressions as it now seems to be
>> >>> impossible to use NaN or infinites as constant initializers.
>> Expressions
>> >>> like 0.0 / 0.0, 1.0 / 0.0 and -1.0 / 0.0 are perfectly well defined
>> >>> under normal IEEE rules, so they shouldn't be rejected.
>> >>
>> >>
>> >> Well, we have a problem. The evaluation semantics of these expressions
>> >> requires code to execute in some build modes (in particular, with
>> sanitizers
>> >> enabled), and thus has a side-effect.
>> >>
>> >> I'm inclined to relax the restriction added in this change for the
>> >> specific case of global variables in C, since (as you say) there is a
>> fair
>> >> amount of code using divide-by-zero as a "portable" way of generating
>> an inf
>> >> or nan.
>> >>
>> >>> Worse, it seems
>> >>> even using __builtin_nan() for example doesn't work.
>> >>
>> >>
>> >> __builtin_nan() works fine for me, can you provide a testcase?
>> >>
>> >>> I'm not even sure about the example given in the commit message, how
>> >>> exactly is that undefined behavior?
>> >>
>> >>
>> >> C11 6.3.1.5/1: "If the value being converted is outside the range of
>> >> values that can be represented, the behavior is undefined."
>> >
>> >
>> > I don't think we want to make the UB here true UB.  It would mean that
>> code
>> > which expected to get NaN might get undef, even outside of constant
>> > expression evaluation.  The implementation defined behavior of
>> providing NaN
>> > seems more friendly...  IIRC, this broke Chrome recently because folks
>> were
>> > doing this in C++.  Hans, do you remember the details?
>>
>> Hmm, it doesn't ring a bell, but my memory sometimes fails me. Didn't
>> you and Reid look at something like this the other day? (But maybe
>> that was in internal code?)
>>
>
> Ah, I think you are right... Reid, do you happen to recall?
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r254984 - Update comment to reflect that we use other tools via the toolchain to

[Eric Christopher via cfe-commits]

Author: echristo
Date: Mon Dec  7 19:59:47 2015
New Revision: 254984

URL: http://llvm.org/viewvc/llvm-project?rev=254984&view=rev
Log:
Update comment to reflect that we use other tools via the toolchain to
handle more than just C.

Modified:
cfe/trunk/include/clang/Driver/ToolChain.h

Modified: cfe/trunk/include/clang/Driver/ToolChain.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/ToolChain.h?rev=254984&r1=254983&r2=254984&view=diff
==
--- cfe/trunk/include/clang/Driver/ToolChain.h (original)
+++ cfe/trunk/include/clang/Driver/ToolChain.h Mon Dec  7 19:59:47 2015
@@ -186,7 +186,7 @@ public:
   /// Choose a tool to use to handle the action \p JA.
   ///
   /// This can be overridden when a particular ToolChain needs to use
-  /// a C compiler other than Clang.
+  /// a compiler other than Clang.
   virtual Tool *SelectTool(const JobAction &JA) const;
 
   // Helper methods


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

r254985 - Remove name from FIXME.

[Eric Christopher via cfe-commits]

Author: echristo
Date: Mon Dec  7 19:59:51 2015
New Revision: 254985

URL: http://llvm.org/viewvc/llvm-project?rev=254985&view=rev
Log:
Remove name from FIXME.

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=254985&r1=254984&r2=254985&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Mon Dec  7 19:59:51 2015
@@ -6109,7 +6109,7 @@ void hexagon::Assembler::ConstructJob(Co
   CmdArgs.push_back(II.getFilename());
 else
   // Don't render as input, we need gcc to do the translations.
-  // FIXME: Pranav: What is this ?
+  // FIXME: What is this?
   II.getInputArg().render(Args, CmdArgs);
   }
 


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

Re: [PATCH] D13330: Implement __attribute__((unique_instantiation))

[Keno Fischer via cfe-commits]

loladiro updated this revision to Diff 42132.
loladiro added a comment.

Address David's concern about inner classes. David also suggested on IRC to 
propagate
the unique instantiation attribute down rather than walking the context chain to
check for the attribute. I'll try that out, but wanted to put up a known-good 
version
with all fixed first.


http://reviews.llvm.org/D13330

Files:
  include/clang/AST/ASTContext.h
  include/clang/Basic/Attr.td
  include/clang/Basic/AttrDocs.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Sema/AttributeList.h
  lib/AST/ASTContext.cpp
  lib/CodeGen/CGVTables.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaDeclAttr.cpp
  lib/Sema/SemaTemplate.cpp
  test/CodeGenCXX/unique-instantiation.cpp
  test/SemaCXX/unique-instantiations.cpp
  utils/TableGen/ClangAttrEmitter.cpp

Index: utils/TableGen/ClangAttrEmitter.cpp
===
--- utils/TableGen/ClangAttrEmitter.cpp
+++ utils/TableGen/ClangAttrEmitter.cpp
@@ -2373,6 +2373,8 @@
 case Func | ObjCMethod | Param: return "ExpectedFunctionMethodOrParameter";
 case Func | ObjCMethod: return "ExpectedFunctionOrMethod";
 case Func | Var: return "ExpectedVariableOrFunction";
+case Func | Class:
+  return "ExpectedFunctionOrClass";
 
 // If not compiling for C++, the class portion does not apply.
 case Func | Var | Class:
Index: test/SemaCXX/unique-instantiations.cpp
===
--- /dev/null
+++ test/SemaCXX/unique-instantiations.cpp
@@ -0,0 +1,46 @@
+// RUN: %clang -cc1 -std=c++14 -fsyntax-only -verify %s
+
+// Correct usage
+template 
+struct foo {};
+extern template struct __attribute__((unique_instantiation)) foo;
+template struct __attribute__((unique_instantiation)) foo;
+
+template  T pi = T(3.1415926535897932385);
+extern template __attribute__((unique_instantiation)) float pi;
+template __attribute__((unique_instantiation)) float pi;
+
+// Usages on non-templates
+float __attribute__((unique_instantiation)) notpi(2.71828182845904523536028747135); // expected-error{{'unique_instantiation' attribute only applies to explicit template declarations or definitions}}
+struct __attribute__((unique_instantiation)) bar{}; // expected-error{{'unique_instantiation' attribute only applies to explicit template declarations or definitions}}
+void __attribute__((unique_instantiation)) func() {} // expected-error{{'unique_instantiation' attribute only applies to explicit template declarations or definitions}}
+
+// Usages that violate one of the conditions required conditions
+template 
+struct foo1 {};
+template struct __attribute__((unique_instantiation)) foo1; // expected-error{{'unique_instantiation' attribute on an explicit instantiation requires a previous explicit instantiation declaration}}
+
+template  T pi1 = T(3.1415926535897932385);
+template __attribute__((unique_instantiation)) float pi1;  // expected-error{{'unique_instantiation' attribute on an explicit instantiation requires a previous explicit instantiation declaration}}
+
+template 
+struct foo2 {};
+extern template struct foo2;// expected-note{{previous explicit instantiation is here}}
+template struct __attribute__((unique_instantiation)) foo2; // expected-error{{'unique_instantiation' attribute must be specified for all declarations and definitions of this explicit template instantiation}}
+
+template 
+struct foo3 {};
+extern template struct __attribute__((unique_instantiation)) foo3; // expected-note{{previous explicit instantiation is here}}
+extern template struct foo3;   // expected-error{{'unique_instantiation' attribute must be specified for all declarations and definitions of this explicit template instantiation}}
+
+template 
+struct __attribute__((unique_instantiation)) foo4 {}; // expected-error{{'unique_instantiation' attribute only applies to explicit template declarations or definitions}}
+
+template 
+struct foo5 {};
+extern template struct __attribute__((unique_instantiation)) foo5; // expected-note{{previous explicit instantiation is here}}
+template struct foo5;  // expected-error{{'unique_instantiation' attribute must be specified for all declarations and definitions of this explicit template instantiation}}
+
+template 
+struct foo6 {};
+extern template struct  __attribute__((unique_instantiation(16))) foo6;// expected-error{{'unique_instantiation' attribute takes no arguments}}
Index: test/CodeGenCXX/unique-instantiation.cpp
===
--- /dev/null
+++ test/CodeGenCXX/unique-instantiation.cpp
@@ -0,0 +1,69 @@
+// RUN: %clang -std=c++14 -emit-llvm -c -S -o - %s | FileCheck %s
+
+// CHECK: @_Z2piIfE = global float
+// CHECK-NOT: @_Z2piIfE = weak_odr global float
+template  T pi = T(3.1415926535897932385);
+extern template __attribute_

r254986 - Replace a bunch of duplicate conditions with the call from types::.

[Eric Christopher via cfe-commits]

Author: echristo
Date: Mon Dec  7 20:10:19 2015
New Revision: 254986

URL: http://llvm.org/viewvc/llvm-project?rev=254986&view=rev
Log:
Replace a bunch of duplicate conditions with the call from types::.

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=254986&r1=254985&r2=254986&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Mon Dec  7 20:10:19 2015
@@ -215,13 +215,9 @@ static void AddLinkerInputs(const ToolCh
   Args.AddAllArgValues(CmdArgs, options::OPT_Zlinker_input);
 
   for (const auto &II : Inputs) {
-if (!TC.HasNativeLLVMSupport()) {
+if (!TC.HasNativeLLVMSupport() && types::isLLVMIR(II.getType()))
   // Don't try to pass LLVM inputs unless we have native support.
-  if (II.getType() == types::TY_LLVM_IR ||
-  II.getType() == types::TY_LTO_IR ||
-  II.getType() == types::TY_LLVM_BC || II.getType() == 
types::TY_LTO_BC)
-D.Diag(diag::err_drv_no_linker_llvm_support) << TC.getTripleString();
-}
+  D.Diag(diag::err_drv_no_linker_llvm_support) << TC.getTripleString();
 
 // Add filenames immediately.
 if (II.isFilename()) {
@@ -5975,8 +5971,7 @@ void gcc::Common::ConstructJob(Compilati
   // inputs into '-Wl,' options?
   for (const auto &II : Inputs) {
 // Don't try to pass LLVM or AST inputs to a generic gcc.
-if (II.getType() == types::TY_LLVM_IR || II.getType() == types::TY_LTO_IR 
||
-II.getType() == types::TY_LLVM_BC || II.getType() == types::TY_LTO_BC)
+if (types::isLLVMIR(II.getType()))
   D.Diag(diag::err_drv_no_linker_llvm_support)
   << getToolChain().getTripleString();
 else if (II.getType() == types::TY_AST)
@@ -6094,8 +6089,7 @@ void hexagon::Assembler::ConstructJob(Co
   // inputs into '-Wl,' options?
   for (const auto &II : Inputs) {
 // Don't try to pass LLVM or AST inputs to a generic gcc.
-if (II.getType() == types::TY_LLVM_IR || II.getType() == types::TY_LTO_IR 
||
-II.getType() == types::TY_LLVM_BC || II.getType() == types::TY_LTO_BC)
+if (types::isLLVMIR(II.getType()))
   D.Diag(clang::diag::err_drv_no_linker_llvm_support)
   << getToolChain().getTripleString();
 else if (II.getType() == types::TY_AST)


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

[PATCH] D15321: [OpenMP 4.0]Parsing and Sema support for 'omp declare target' directive (accelerator support)

[Michael Wong via cfe-commits]

fraggamuffin created this revision.
fraggamuffin added a reviewer: cfe-commits.
fraggamuffin set the repository for this revision to rL LLVM.

Add parsing, sema analysis for 'declare target' construct for OpenMP 4.0.
Summary
The declare target directive specifies that variables, functions (C, C++ and
Fortran), and subroutines (Fortran) are mapped to a device. The declare target
directive is a declarative directive.

The syntax of the declare target directive is as follows:
C/C++
Fortran
The syntax of the declare target directive is as follows:

For variables, functions and subroutines:


```
#pragma omp declare target new-line
declarations-definition-seq
#pragma omp end declare target new-line
```

Codegen will be done in a separate delivery. This is based on the clang-omp 
github branch adapted for 3.8.
All unit tests passes (note that message test needed to add -fnoopenmp-use-tls 
to pass specifically the threadprivate part because use-tls is now set to 
default). All regression passes.
OpenMP 4.5 changes will be delivered separately.


Repository:
  rL LLVM

http://reviews.llvm.org/D15321

Files:
  include/clang/AST/DeclBase.h
  include/clang/AST/DeclOpenMP.h
  include/clang/AST/RecursiveASTVisitor.h
  include/clang/Basic/DeclNodes.td
  include/clang/Basic/DiagnosticParseKinds.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/OpenMPKinds.def
  include/clang/Basic/OpenMPKinds.h
  include/clang/Parse/Parser.h
  include/clang/Sema/Sema.h
  include/clang/Serialization/ASTBitCodes.h
  lib/AST/ASTContext.cpp
  lib/AST/Decl.cpp
  lib/AST/DeclBase.cpp
  lib/AST/DeclOpenMP.cpp
  lib/AST/DeclPrinter.cpp
  lib/AST/ItaniumMangle.cpp
  lib/AST/MicrosoftMangle.cpp
  lib/Basic/OpenMPKinds.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CodeGenModule.cpp
  lib/CodeGen/CodeGenModule.h
  lib/Parse/ParseDecl.cpp
  lib/Parse/ParseDeclCXX.cpp
  lib/Parse/ParseOpenMP.cpp
  lib/Parse/Parser.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaLookup.cpp
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/SemaTemplateInstantiate.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  lib/Serialization/ASTCommon.cpp
  lib/Serialization/ASTReaderDecl.cpp
  lib/Serialization/ASTWriterDecl.cpp
  test/OpenMP/declare_target_ast_print.cpp
  test/OpenMP/declare_target_messages.cpp
  tools/libclang/CIndex.cpp

Index: tools/libclang/CIndex.cpp
===
--- tools/libclang/CIndex.cpp
+++ tools/libclang/CIndex.cpp
@@ -5228,6 +5228,7 @@
   case Decl::ClassScopeFunctionSpecialization:
   case Decl::Import:
   case Decl::OMPThreadPrivate:
+  case Decl::OMPDeclareTarget:
   case Decl::ObjCTypeParam:
   case Decl::BuiltinTemplate:
 return C;
Index: test/OpenMP/declare_target_messages.cpp
===
--- test/OpenMP/declare_target_messages.cpp
+++ test/OpenMP/declare_target_messages.cpp
@@ -0,0 +1,83 @@
+// RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 -verify -fopenmp -fnoopenmp-use-tls -ferror-limit 100 -o - %s
+
+#pragma omp end declare target // expected-error {{unexpected OpenMP directive '#pragma omp end declare target'}}
+
+int a, b; // expected-warning 2 {{declaration is not declared in any declare target region}}
+__thread int t; // expected-error {{threadprivate variables cannot be used in target constructs}}
+#pragma omp declare target private(a) // expected-warning {{extra tokens at the end of '#pragma omp declare target' are ignored}}
+void f();
+#pragma omp end declare target shared(a) // expected-warning {{extra tokens at the end of '#pragma omp end declare target' are ignored}}
+void c(); // expected-warning {{declaration is not declared in any declare target region}}
+
+extern int b;
+
+struct NonT {
+  int a;
+};
+
+typedef int sint;
+
+#pragma omp declare target // expected-note {{to match this '#pragma omp declare target'}}
+#pragma omp threadprivate(a) // expected-error {{threadprivate variables cannot be used in target constructs}} expected-note {{used here}}
+extern int b;
+int g;
+
+struct T { // expected-note {{mappable type cannot be polymorphic}}
+  int a;
+  virtual int method();
+};
+
+class VC { // expected-note {{mappable type cannot be polymorphic}}
+  T member;
+  NonT member1;
+  public:
+virtual int method() { T a; return 0; } // expected-error {{type 'T' is not mappable to target}}
+};
+
+struct C {
+  NonT a;
+  sint b;
+  int method();
+  int method1();
+};
+
+int C::method1() {
+  return 0;
+}
+
+void foo() {
+  a = 0; // expected-note {{used here}}
+  b = 0; // expected-note {{used here}}
+  t = 1; // expected-note {{used here}}
+  C object;
+  VC object1; // expected-error {{type 'VC' is not mappable to target}}
+  g = object.method();
+  g += object.method1();
+  g += object1.method();
+  f();
+  c(); // expected-note {{used here}}
+}
+#pragma omp declare target // expected-error {{expected '#pragma omp end declare target'}}
+void foo1() {}
+#pragma omp end declare target
+

RE: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

[Robinson, Paul via cfe-commits]

Two more questions:

(1) Commit message implied this is only for C, but I see it with C++11
(but not C++03).

$ cat t.cpp
enum { foo = 123456 * 234567 };
$ clang -c t.cpp -std=c++03
$ clang -c t.cpp -std=c++11
t.cpp:1:14: error: expression is not an integral constant expression


(2) Shouldn't it diagnose each bad expression in an initializer?
I see the error only for the first such expression.

$ cat t.c
int foo[2] = { 123456 * 234567, 654321 * 765432 };
$ clang -c t.c
t.c:1:23: error: initializer element is not a compile-time constant
int foo[2] = { 123456 * 234567, 654321 * 765432 };
   ~~~^~~~
1 error generated.

Thanks,
--paulr

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of
> Richard Smith via cfe-commits
> Sent: Wednesday, December 02, 2015 5:36 PM
> To: cfe-commits@lists.llvm.org
> Subject: r254574 - PR17381: Treat undefined behavior during expression
> evaluation as an unmodeled
> 
> Author: rsmith
> Date: Wed Dec  2 19:36:22 2015
> New Revision: 254574
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=254574&view=rev
> Log:
> PR17381: Treat undefined behavior during expression evaluation as an
> unmodeled
> side-effect, so that we don't allow speculative evaluation of such
> expressions
> during code generation.
> 
> This caused a diagnostic quality regression, so fix constant expression
> diagnostics to prefer either the first "can't be constant folded"
> diagnostic or
> the first "not a constant expression" diagnostic depending on the kind of
> evaluation we're doing. This was always the intent, but didn't quite work
> correctly before.
> 
> This results in certain initializers that used to be constant initializers
> to
> no longer be; in particular, things like:
> 
>   float f = 1e100;
> 
> are no longer accepted in C. This seems appropriate, as such constructs
> would
> lead to code being executed if sanitizers are enabled.
> 
> Added:
> cfe/trunk/test/CodeGen/ubsan-conditional.c
> Modified:
> cfe/trunk/lib/AST/ExprConstant.cpp
> cfe/trunk/lib/Sema/SemaChecking.cpp
> cfe/trunk/test/CXX/expr/expr.const/p2-0x.cpp
> cfe/trunk/test/CodeGen/complex-init-list.c
> cfe/trunk/test/PCH/floating-literal.c
> cfe/trunk/test/Sema/const-eval.c
> cfe/trunk/test/Sema/integer-overflow.c
> cfe/trunk/test/Sema/switch-1.c
> cfe/trunk/test/SemaCXX/constant-expression-cxx11.cpp
> cfe/trunk/test/SemaCXX/constexpr-printing.cpp
> 
> Modified: cfe/trunk/lib/AST/ExprConstant.cpp
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/lib/AST/ExprConstant.cpp?rev=254574&r1=254573&r2=254574&
> view=diff
> ==
> 
> --- cfe/trunk/lib/AST/ExprConstant.cpp (original)
> +++ cfe/trunk/lib/AST/ExprConstant.cpp Wed Dec  2 19:36:22 2015
> @@ -473,6 +473,10 @@ namespace {
>  /// notes attached to it will also be stored, otherwise they will not
> be.
>  bool HasActiveDiagnostic;
> 
> +/// \brief Have we emitted a diagnostic explaining why we couldn't
> constant
> +/// fold (not just why it's not strictly a constant expression)?
> +bool HasFoldFailureDiagnostic;
> +
>  enum EvaluationMode {
>/// Evaluate as a constant expression. Stop if we find that the
> expression
>/// is not a constant expression.
> @@ -537,7 +541,7 @@ namespace {
>  BottomFrame(*this, SourceLocation(), nullptr, nullptr, nullptr),
>  EvaluatingDecl((const ValueDecl *)nullptr),
>  EvaluatingDeclValue(nullptr), HasActiveDiagnostic(false),
> -EvalMode(Mode) {}
> +HasFoldFailureDiagnostic(false), EvalMode(Mode) {}
> 
>  void setEvaluatingDecl(APValue::LValueBase Base, APValue &Value) {
>EvaluatingDecl = Base;
> @@ -597,7 +601,7 @@ namespace {
>  /// Diagnose that the evaluation cannot be folded.
>  OptionalDiagnostic Diag(SourceLocation Loc, diag::kind DiagId
>= diag::note_invalid_subexpr_in_const_expr,
> -unsigned ExtraNotes = 0) {
> +unsigned ExtraNotes = 0, bool IsCCEDiag =
> false) {
>if (EvalStatus.Diag) {
>  // If we have a prior diagnostic, it will be noting that the
> expression
>  // isn't a constant expression. This diagnostic is more
> important,
> @@ -610,10 +614,9 @@ namespace {
>case EM_ConstantFold:
>case EM_IgnoreSideEffects:
>case EM_EvaluateForOverflow:
> -if (!EvalStatus.HasSideEffects)
> +if (!HasFoldFailureDiagnostic)
>break;
> -// We've had side-effects; we want the diagnostic from them,
> not
> -// some later problem.
> +// We've already failed to fold something. Keep that
> diagnostic.
>case EM_ConstantExpression:
>case EM_PotentialConstantExpression:
>case EM_ConstantExpressionUnevaluated:
>

Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

[Richard Smith via cfe-commits]

[Adding back cfe-commits]

On Mon, Dec 7, 2015 at 6:46 PM, Richard Smith  wrote:

> On Mon, Dec 7, 2015 at 1:59 PM, Robinson, Paul <
> paul_robin...@playstation.sony.com> wrote:
>
>> | C11 6.3.1.5/1: "If the value being converted is outside the range of
>> values that can be represented, the behavior is undefined."
>>
>>
>>
>> I think 5.2.4.2.2/5 says if infinities are representable, there are no
>> values "outside" the floating-point range?
>>
>
> That interpretation would also require converting UINT128_MAX to float to
> have defined behavior (it must give either FLT_MAX or +inf, as those are
> the two closest represetnable values), which it does not on real hardware.
>
>
>> And 6.3.1.5/1 starts out with "if the value being converted can be
>> represented exactly in the new type, it is unchanged."  I'd think that NaNs
>> could be represented "exactly" (they can certainly be represented:
>> 5.2.4.2.2/3) despite not having an actual numeric value.
>>
>
> In talking about NaNs, you've switched to talking about a different case;
> we were talking about doubles that don't fit in a float. The division by
> zero cases have UB because 6.5.5/5 explicitly says they do.
>
>
>> I don't think 6.3.1.5/1 means to exclude NaN/infinities, given that
>> 6.3.1.4/1 explicitly refers to "finite value" wrt conversion to an
>> integer type.
>>
>> --paulr
>>
>>
>>
>> *From:* cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] *On
>> Behalf Of *Richard Smith via cfe-commits
>> *Sent:* Monday, December 07, 2015 1:32 PM
>> *To:* Joerg Sonnenberger; cfe-commits
>> *Subject:* Re: r254574 - PR17381: Treat undefined behavior during
>> expression evaluation as an unmodeled
>>
>>
>>
>> On Mon, Dec 7, 2015 at 7:25 AM, Joerg Sonnenberger via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>> On Thu, Dec 03, 2015 at 01:36:22AM -, Richard Smith via cfe-commits
>> wrote:
>> > Author: rsmith
>> > Date: Wed Dec  2 19:36:22 2015
>> > New Revision: 254574
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=254574&view=rev
>> > Log:
>> > PR17381: Treat undefined behavior during expression evaluation as an
>> unmodeled
>> > side-effect, so that we don't allow speculative evaluation of such
>> expressions
>> > during code generation.
>> >
>> > This caused a diagnostic quality regression, so fix constant expression
>> > diagnostics to prefer either the first "can't be constant folded"
>> diagnostic or
>> > the first "not a constant expression" diagnostic depending on the kind
>> of
>> > evaluation we're doing. This was always the intent, but didn't quite
>> work
>> > correctly before.
>> >
>> > This results in certain initializers that used to be constant
>> initializers to
>> > no longer be; in particular, things like:
>> >
>> >   float f = 1e100;
>> >
>> > are no longer accepted in C. This seems appropriate, as such constructs
>> would
>> > lead to code being executed if sanitizers are enabled.
>>
>> This leads to some pretty annoying regressions as it now seems to be
>> impossible to use NaN or infinites as constant initializers. Expressions
>> like 0.0 / 0.0, 1.0 / 0.0 and -1.0 / 0.0 are perfectly well defined
>> under normal IEEE rules, so they shouldn't be rejected.
>>
>>
>>
>> Well, we have a problem. The evaluation semantics of these expressions
>> requires code to execute in some build modes (in particular, with
>> sanitizers enabled), and thus has a side-effect.
>>
>>
>>
>> I'm inclined to relax the restriction added in this change for the
>> specific case of global variables in C, since (as you say) there is a fair
>> amount of code using divide-by-zero as a "portable" way of generating an
>> inf or nan.
>>
>>
>>
>> Worse, it seems
>> even using __builtin_nan() for example doesn't work.
>>
>>
>>
>> __builtin_nan() works fine for me, can you provide a testcase?
>>
>>
>>
>> I'm not even sure about the example given in the commit message, how
>> exactly is that undefined behavior?
>>
>>
>>
>> C11 6.3.1.5/1: "If the value being converted is outside the range of
>> values that can be represented, the behavior is undefined."
>>
>>
>>
>> We also have C11 6.6/4: "Each constant expression shall evaluate to a
>> constant that is in the range of representable values for its type."
>>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

[Richard Smith via cfe-commits]

On Mon, Dec 7, 2015 at 5:26 PM, Reid Kleckner via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> It wasn't Chrome, it was some internal dependency on torch-cephes. I
> submitted a patch for it upstream:
>
> https://github.com/deepmind/torch-cephes/commit/9c4a97c90dc200ecbecb883e7230fe3c847954df
> It's not a pretty, though.
>
> I know LLVM IR rules are not C++ rules, but LLVM generally believes in
> NaN. It will speculate things like fdiv above branches, leading to traps
> when people configure the FPU appropriately and then conditionally divide
> by zero. It would be more consistent for Clang to follow the LLVM direction
> here. The fact that C++ says that FP div-by-zero is UB might just be a bug
> in the standard, or a grey area that couldn't be filled in.
>

Right, I'm not suggesting we treat floating-point division by zero as "true
UB". But the fact we have a sanitizer for it means that our behavior is
not, and cannot be, "just give a NaN or Inf". It's a choice of either "give
me a NaN or Inf" or "give me a sanitizer diagnostic, followed by a NaN or
Inf". And that means it's not constant in the general case, because
evaluating it has runtime side-effects.

Prior to this patch, Clang would determine that such divisions had no
side-effects, and speculate them *and the corresponding sanitizer checks*,
resulting in sanitizer false positives on correct code.


> On Mon, Dec 7, 2015 at 2:37 PM, David Majnemer 
> wrote:
>
>>
>>
>> On Mon, Dec 7, 2015 at 5:25 PM, Hans Wennborg  wrote:
>>
>>> On Mon, Dec 7, 2015 at 2:14 PM, David Majnemer 
>>> wrote:
>>> >
>>> >
>>> > On Mon, Dec 7, 2015 at 4:32 PM, Richard Smith via cfe-commits
>>> >  wrote:
>>> >>
>>> >> On Mon, Dec 7, 2015 at 7:25 AM, Joerg Sonnenberger via cfe-commits
>>> >>  wrote:
>>> >>>
>>> >>> On Thu, Dec 03, 2015 at 01:36:22AM -, Richard Smith via
>>> cfe-commits
>>> >>> wrote:
>>> >>> > Author: rsmith
>>> >>> > Date: Wed Dec  2 19:36:22 2015
>>> >>> > New Revision: 254574
>>> >>> >
>>> >>> > URL: http://llvm.org/viewvc/llvm-project?rev=254574&view=rev
>>> >>> > Log:
>>> >>> > PR17381: Treat undefined behavior during expression evaluation as
>>> an
>>> >>> > unmodeled
>>> >>> > side-effect, so that we don't allow speculative evaluation of such
>>> >>> > expressions
>>> >>> > during code generation.
>>> >>> >
>>> >>> > This caused a diagnostic quality regression, so fix constant
>>> expression
>>> >>> > diagnostics to prefer either the first "can't be constant folded"
>>> >>> > diagnostic or
>>> >>> > the first "not a constant expression" diagnostic depending on the
>>> kind
>>> >>> > of
>>> >>> > evaluation we're doing. This was always the intent, but didn't
>>> quite
>>> >>> > work
>>> >>> > correctly before.
>>> >>> >
>>> >>> > This results in certain initializers that used to be constant
>>> >>> > initializers to
>>> >>> > no longer be; in particular, things like:
>>> >>> >
>>> >>> >   float f = 1e100;
>>> >>> >
>>> >>> > are no longer accepted in C. This seems appropriate, as such
>>> constructs
>>> >>> > would
>>> >>> > lead to code being executed if sanitizers are enabled.
>>> >>>
>>> >>> This leads to some pretty annoying regressions as it now seems to be
>>> >>> impossible to use NaN or infinites as constant initializers.
>>> Expressions
>>> >>> like 0.0 / 0.0, 1.0 / 0.0 and -1.0 / 0.0 are perfectly well defined
>>> >>> under normal IEEE rules, so they shouldn't be rejected.
>>> >>
>>> >>
>>> >> Well, we have a problem. The evaluation semantics of these expressions
>>> >> requires code to execute in some build modes (in particular, with
>>> sanitizers
>>> >> enabled), and thus has a side-effect.
>>> >>
>>> >> I'm inclined to relax the restriction added in this change for the
>>> >> specific case of global variables in C, since (as you say) there is a
>>> fair
>>> >> amount of code using divide-by-zero as a "portable" way of generating
>>> an inf
>>> >> or nan.
>>> >>
>>> >>> Worse, it seems
>>> >>> even using __builtin_nan() for example doesn't work.
>>> >>
>>> >>
>>> >> __builtin_nan() works fine for me, can you provide a testcase?
>>> >>
>>> >>> I'm not even sure about the example given in the commit message, how
>>> >>> exactly is that undefined behavior?
>>> >>
>>> >>
>>> >> C11 6.3.1.5/1: "If the value being converted is outside the range of
>>> >> values that can be represented, the behavior is undefined."
>>> >
>>> >
>>> > I don't think we want to make the UB here true UB.  It would mean that
>>> code
>>> > which expected to get NaN might get undef, even outside of constant
>>> > expression evaluation.  The implementation defined behavior of
>>> providing NaN
>>> > seems more friendly...  IIRC, this broke Chrome recently because folks
>>> were
>>> > doing this in C++.  Hans, do you remember the details?
>>>
>>> Hmm, it doesn't ring a bell, but my memory sometimes fails me. Didn't
>>> you and Reid look at something like this the other day? (But maybe
>>> that was in internal code?)
>>>
>>
>> Ah, I think you are right... Reid, do 

Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

[David Majnemer via cfe-commits]

On Mon, Dec 7, 2015 at 9:51 PM, Richard Smith  wrote:

> On Mon, Dec 7, 2015 at 5:26 PM, Reid Kleckner via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> It wasn't Chrome, it was some internal dependency on torch-cephes. I
>> submitted a patch for it upstream:
>>
>> https://github.com/deepmind/torch-cephes/commit/9c4a97c90dc200ecbecb883e7230fe3c847954df
>> It's not a pretty, though.
>>
>> I know LLVM IR rules are not C++ rules, but LLVM generally believes in
>> NaN. It will speculate things like fdiv above branches, leading to traps
>> when people configure the FPU appropriately and then conditionally divide
>> by zero. It would be more consistent for Clang to follow the LLVM direction
>> here. The fact that C++ says that FP div-by-zero is UB might just be a bug
>> in the standard, or a grey area that couldn't be filled in.
>>
>
> Right, I'm not suggesting we treat floating-point division by zero as
> "true UB". But the fact we have a sanitizer for it means that our behavior
> is not, and cannot be, "just give a NaN or Inf". It's a choice of either
> "give me a NaN or Inf" or "give me a sanitizer diagnostic, followed by a
> NaN or Inf". And that means it's not constant in the general case, because
> evaluating it has runtime side-effects.
>

The mere existence of a sanitizer shouldn't be what determines our behavior
in the general case.  We also have a sanitizer for unsigned overflow...


>
> Prior to this patch, Clang would determine that such divisions had no
> side-effects, and speculate them *and the corresponding sanitizer checks*,
> resulting in sanitizer false positives on correct code.
>
>
>> On Mon, Dec 7, 2015 at 2:37 PM, David Majnemer 
>> wrote:
>>
>>>
>>>
>>> On Mon, Dec 7, 2015 at 5:25 PM, Hans Wennborg  wrote:
>>>
 On Mon, Dec 7, 2015 at 2:14 PM, David Majnemer <
 david.majne...@gmail.com> wrote:
 >
 >
 > On Mon, Dec 7, 2015 at 4:32 PM, Richard Smith via cfe-commits
 >  wrote:
 >>
 >> On Mon, Dec 7, 2015 at 7:25 AM, Joerg Sonnenberger via cfe-commits
 >>  wrote:
 >>>
 >>> On Thu, Dec 03, 2015 at 01:36:22AM -, Richard Smith via
 cfe-commits
 >>> wrote:
 >>> > Author: rsmith
 >>> > Date: Wed Dec  2 19:36:22 2015
 >>> > New Revision: 254574
 >>> >
 >>> > URL: http://llvm.org/viewvc/llvm-project?rev=254574&view=rev
 >>> > Log:
 >>> > PR17381: Treat undefined behavior during expression evaluation as
 an
 >>> > unmodeled
 >>> > side-effect, so that we don't allow speculative evaluation of such
 >>> > expressions
 >>> > during code generation.
 >>> >
 >>> > This caused a diagnostic quality regression, so fix constant
 expression
 >>> > diagnostics to prefer either the first "can't be constant folded"
 >>> > diagnostic or
 >>> > the first "not a constant expression" diagnostic depending on the
 kind
 >>> > of
 >>> > evaluation we're doing. This was always the intent, but didn't
 quite
 >>> > work
 >>> > correctly before.
 >>> >
 >>> > This results in certain initializers that used to be constant
 >>> > initializers to
 >>> > no longer be; in particular, things like:
 >>> >
 >>> >   float f = 1e100;
 >>> >
 >>> > are no longer accepted in C. This seems appropriate, as such
 constructs
 >>> > would
 >>> > lead to code being executed if sanitizers are enabled.
 >>>
 >>> This leads to some pretty annoying regressions as it now seems to be
 >>> impossible to use NaN or infinites as constant initializers.
 Expressions
 >>> like 0.0 / 0.0, 1.0 / 0.0 and -1.0 / 0.0 are perfectly well defined
 >>> under normal IEEE rules, so they shouldn't be rejected.
 >>
 >>
 >> Well, we have a problem. The evaluation semantics of these
 expressions
 >> requires code to execute in some build modes (in particular, with
 sanitizers
 >> enabled), and thus has a side-effect.
 >>
 >> I'm inclined to relax the restriction added in this change for the
 >> specific case of global variables in C, since (as you say) there is
 a fair
 >> amount of code using divide-by-zero as a "portable" way of
 generating an inf
 >> or nan.
 >>
 >>> Worse, it seems
 >>> even using __builtin_nan() for example doesn't work.
 >>
 >>
 >> __builtin_nan() works fine for me, can you provide a testcase?
 >>
 >>> I'm not even sure about the example given in the commit message, how
 >>> exactly is that undefined behavior?
 >>
 >>
 >> C11 6.3.1.5/1: "If the value being converted is outside the range of
 >> values that can be represented, the behavior is undefined."
 >
 >
 > I don't think we want to make the UB here true UB.  It would mean
 that code
 > which expected to get NaN might get undef, even outside of constant
 > expression evaluation.  The implementation defined behavior of
 providing NaN
>>

Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

[Richard Smith via cfe-commits]

I've amended this change to permit constant-foldable UB in C variable
initializers again in r254992.

On Mon, Dec 7, 2015 at 6:45 PM, Robinson, Paul via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Two more questions:
>
> (1) Commit message implied this is only for C, but I see it with C++11
> (but not C++03).

$ cat t.cpp
> enum { foo = 123456 * 234567 };
> $ clang -c t.cpp -std=c++03
> $ clang -c t.cpp -std=c++11
> t.cpp:1:14: error: expression is not an integral constant expression
>

That is the behavior required by the C++11 standard, but we used to accept
GNU constant folding here as an extension.


>
> (2) Shouldn't it diagnose each bad expression in an initializer?
> I see the error only for the first such expression.
>
> $ cat t.c
> int foo[2] = { 123456 * 234567, 654321 * 765432 };
> $ clang -c t.c
> t.c:1:23: error: initializer element is not a compile-time constant
> int foo[2] = { 123456 * 234567, 654321 * 765432 };
>~~~^~~~
>

That change would be unrelated to the one at hand -- this is the way we've
always behaved. Consider for instance:

  int n;
  int foo[2] = { n, n };

If you wanted to make us report the other ones, the relevant code is in
Expr::isConstantInitializer and Sema::CheckForConstantInitializer.

1 error generated.
>
> Thanks,
> --paulr
>
> > -Original Message-
> > From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf
> Of
> > Richard Smith via cfe-commits
> > Sent: Wednesday, December 02, 2015 5:36 PM
> > To: cfe-commits@lists.llvm.org
> > Subject: r254574 - PR17381: Treat undefined behavior during expression
> > evaluation as an unmodeled
> >
> > Author: rsmith
> > Date: Wed Dec  2 19:36:22 2015
> > New Revision: 254574
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=254574&view=rev
> > Log:
> > PR17381: Treat undefined behavior during expression evaluation as an
> > unmodeled
> > side-effect, so that we don't allow speculative evaluation of such
> > expressions
> > during code generation.
> >
> > This caused a diagnostic quality regression, so fix constant expression
> > diagnostics to prefer either the first "can't be constant folded"
> > diagnostic or
> > the first "not a constant expression" diagnostic depending on the kind of
> > evaluation we're doing. This was always the intent, but didn't quite work
> > correctly before.
> >
> > This results in certain initializers that used to be constant
> initializers
> > to
> > no longer be; in particular, things like:
> >
> >   float f = 1e100;
> >
> > are no longer accepted in C. This seems appropriate, as such constructs
> > would
> > lead to code being executed if sanitizers are enabled.
> >
> > Added:
> > cfe/trunk/test/CodeGen/ubsan-conditional.c
> > Modified:
> > cfe/trunk/lib/AST/ExprConstant.cpp
> > cfe/trunk/lib/Sema/SemaChecking.cpp
> > cfe/trunk/test/CXX/expr/expr.const/p2-0x.cpp
> > cfe/trunk/test/CodeGen/complex-init-list.c
> > cfe/trunk/test/PCH/floating-literal.c
> > cfe/trunk/test/Sema/const-eval.c
> > cfe/trunk/test/Sema/integer-overflow.c
> > cfe/trunk/test/Sema/switch-1.c
> > cfe/trunk/test/SemaCXX/constant-expression-cxx11.cpp
> > cfe/trunk/test/SemaCXX/constexpr-printing.cpp
> >
> > Modified: cfe/trunk/lib/AST/ExprConstant.cpp
> > URL: http://llvm.org/viewvc/llvm-
> >
> project/cfe/trunk/lib/AST/ExprConstant.cpp?rev=254574&r1=254573&r2=254574&
> > view=diff
> >
> ==
> > 
> > --- cfe/trunk/lib/AST/ExprConstant.cpp (original)
> > +++ cfe/trunk/lib/AST/ExprConstant.cpp Wed Dec  2 19:36:22 2015
> > @@ -473,6 +473,10 @@ namespace {
> >  /// notes attached to it will also be stored, otherwise they will
> not
> > be.
> >  bool HasActiveDiagnostic;
> >
> > +/// \brief Have we emitted a diagnostic explaining why we couldn't
> > constant
> > +/// fold (not just why it's not strictly a constant expression)?
> > +bool HasFoldFailureDiagnostic;
> > +
> >  enum EvaluationMode {
> >/// Evaluate as a constant expression. Stop if we find that the
> > expression
> >/// is not a constant expression.
> > @@ -537,7 +541,7 @@ namespace {
> >  BottomFrame(*this, SourceLocation(), nullptr, nullptr, nullptr),
> >  EvaluatingDecl((const ValueDecl *)nullptr),
> >  EvaluatingDeclValue(nullptr), HasActiveDiagnostic(false),
> > -EvalMode(Mode) {}
> > +HasFoldFailureDiagnostic(false), EvalMode(Mode) {}
> >
> >  void setEvaluatingDecl(APValue::LValueBase Base, APValue &Value) {
> >EvaluatingDecl = Base;
> > @@ -597,7 +601,7 @@ namespace {
> >  /// Diagnose that the evaluation cannot be folded.
> >  OptionalDiagnostic Diag(SourceLocation Loc, diag::kind DiagId
> >=
> diag::note_invalid_subexpr_in_const_expr,
> > -unsigned ExtraNotes = 0) {
> > +unsigned ExtraNotes = 0, bool 

r254992 - Explicitly permit undefined behavior in constant initializers for global

[Richard Smith via cfe-commits]

Author: rsmith
Date: Mon Dec  7 21:21:47 2015
New Revision: 254992

URL: http://llvm.org/viewvc/llvm-project?rev=254992&view=rev
Log:
Explicitly permit undefined behavior in constant initializers for global
variables in C, in the cases where we can constant-fold it to a value
regardless (such as floating-point division by zero and signed integer
overflow). Strictly enforcing this rule breaks too much code.

Modified:
cfe/trunk/include/clang/AST/Expr.h
cfe/trunk/lib/AST/Expr.cpp
cfe/trunk/lib/AST/ExprConstant.cpp
cfe/trunk/test/CodeGen/complex-init-list.c
cfe/trunk/test/PCH/floating-literal.c
cfe/trunk/test/Sema/const-eval.c
cfe/trunk/test/Sema/integer-overflow.c
cfe/trunk/test/Sema/switch-1.c
cfe/trunk/test/SemaCXX/enum.cpp

Modified: cfe/trunk/include/clang/AST/Expr.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Expr.h?rev=254992&r1=254991&r2=254992&view=diff
==
--- cfe/trunk/include/clang/AST/Expr.h (original)
+++ cfe/trunk/include/clang/AST/Expr.h Mon Dec  7 21:21:47 2015
@@ -529,10 +529,15 @@ public:
 
   /// EvalStatus is a struct with detailed info about an evaluation in 
progress.
   struct EvalStatus {
-/// HasSideEffects - Whether the evaluated expression has side effects.
+/// \brief Whether the evaluated expression has side effects.
 /// For example, (f() && 0) can be folded, but it still has side effects.
 bool HasSideEffects;
 
+/// \brief Whether the evaluation hit undefined behavior.
+/// For example, 1.0 / 0.0 can be folded to Inf, but has undefined 
behavior.
+/// Likewise, INT_MAX + 1 can be folded to INT_MIN, but has UB.
+bool HasUndefinedBehavior;
+
 /// Diag - If this is non-null, it will be filled in with a stack of notes
 /// indicating why evaluation failed (or why it failed to produce a 
constant
 /// expression).
@@ -542,7 +547,8 @@ public:
 /// expression *is* a constant expression, no notes will be produced.
 SmallVectorImpl *Diag;
 
-EvalStatus() : HasSideEffects(false), Diag(nullptr) {}
+EvalStatus()
+: HasSideEffects(false), HasUndefinedBehavior(false), Diag(nullptr) {}
 
 // hasSideEffects - Return true if the evaluated expression has
 // side effects.
@@ -575,7 +581,12 @@ public:
   /// side-effects.
   bool EvaluateAsBooleanCondition(bool &Result, const ASTContext &Ctx) const;
 
-  enum SideEffectsKind { SE_NoSideEffects, SE_AllowSideEffects };
+  enum SideEffectsKind {
+SE_NoSideEffects,  ///< Strictly evaluate the expression.
+SE_AllowUndefinedBehavior, ///< Allow UB that we can give a value, but not
+   ///< arbitrary unmodeled side effects.
+SE_AllowSideEffects///< Allow any unmodeled side effect.
+  };
 
   /// EvaluateAsInt - Return true if this is a constant which we can fold and
   /// convert to an integer, using any crazy technique that we want to.
@@ -584,7 +595,8 @@ public:
 
   /// isEvaluatable - Call EvaluateAsRValue to see if this expression can be
   /// constant folded without side-effects, but discard the result.
-  bool isEvaluatable(const ASTContext &Ctx) const;
+  bool isEvaluatable(const ASTContext &Ctx,
+ SideEffectsKind AllowSideEffects = SE_NoSideEffects) 
const;
 
   /// HasSideEffects - This routine returns true for all those expressions
   /// which have any effect other than producing a value. Example is a function

Modified: cfe/trunk/lib/AST/Expr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Expr.cpp?rev=254992&r1=254991&r2=254992&view=diff
==
--- cfe/trunk/lib/AST/Expr.cpp (original)
+++ cfe/trunk/lib/AST/Expr.cpp Mon Dec  7 21:21:47 2015
@@ -2891,7 +2891,10 @@ bool Expr::isConstantInitializer(ASTCont
 return cast(this)->getExpr()
   ->isConstantInitializer(Ctx, false, Culprit);
   }
-  if (isEvaluatable(Ctx))
+  // Allow certain forms of UB in constant initializers: signed integer
+  // overflow and floating-point division by zero. We'll give a warning on
+  // these, but they're common enough that we have to accept them.
+  if (isEvaluatable(Ctx, SE_AllowUndefinedBehavior))
 return true;
   if (Culprit)
 *Culprit = this;

Modified: cfe/trunk/lib/AST/ExprConstant.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprConstant.cpp?rev=254992&r1=254991&r2=254992&view=diff
==
--- cfe/trunk/lib/AST/ExprConstant.cpp (original)
+++ cfe/trunk/lib/AST/ExprConstant.cpp Mon Dec  7 21:21:47 2015
@@ -715,6 +715,32 @@ namespace {
   return keepEvaluatingAfterSideEffect();
 }
 
+/// Should we continue evaluation after encountering undefined behavior?
+bool keepEvaluatingAfterUndefinedBehavior() {
+  switch (EvalMode) {
+  case EM_EvaluateForOverflow:

Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

[Richard Smith via cfe-commits]

On Mon, Dec 7, 2015 at 7:20 PM, David Majnemer 
wrote:

> On Mon, Dec 7, 2015 at 9:51 PM, Richard Smith 
> wrote:
>
>> On Mon, Dec 7, 2015 at 5:26 PM, Reid Kleckner via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> It wasn't Chrome, it was some internal dependency on torch-cephes. I
>>> submitted a patch for it upstream:
>>>
>>> https://github.com/deepmind/torch-cephes/commit/9c4a97c90dc200ecbecb883e7230fe3c847954df
>>> It's not a pretty, though.
>>>
>>> I know LLVM IR rules are not C++ rules, but LLVM generally believes in
>>> NaN. It will speculate things like fdiv above branches, leading to traps
>>> when people configure the FPU appropriately and then conditionally divide
>>> by zero. It would be more consistent for Clang to follow the LLVM direction
>>> here. The fact that C++ says that FP div-by-zero is UB might just be a bug
>>> in the standard, or a grey area that couldn't be filled in.
>>>
>>
>> Right, I'm not suggesting we treat floating-point division by zero as
>> "true UB". But the fact we have a sanitizer for it means that our behavior
>> is not, and cannot be, "just give a NaN or Inf". It's a choice of either
>> "give me a NaN or Inf" or "give me a sanitizer diagnostic, followed by a
>> NaN or Inf". And that means it's not constant in the general case, because
>> evaluating it has runtime side-effects.
>>
>
> The mere existence of a sanitizer shouldn't be what determines our
> behavior in the general case.  We also have a sanitizer for unsigned
> overflow...
>

I agree, but the difference is that the unsigned overflow sanitizer is not
a conforming mode for our implementation, whereas UBSan is supposed to be
one.

Prior to this patch, Clang would determine that such divisions had no
>> side-effects, and speculate them *and the corresponding sanitizer checks*,
>> resulting in sanitizer false positives on correct code.
>>
>>
>>> On Mon, Dec 7, 2015 at 2:37 PM, David Majnemer >> > wrote:
>>>


 On Mon, Dec 7, 2015 at 5:25 PM, Hans Wennborg 
 wrote:

> On Mon, Dec 7, 2015 at 2:14 PM, David Majnemer <
> david.majne...@gmail.com> wrote:
> >
> >
> > On Mon, Dec 7, 2015 at 4:32 PM, Richard Smith via cfe-commits
> >  wrote:
> >>
> >> On Mon, Dec 7, 2015 at 7:25 AM, Joerg Sonnenberger via cfe-commits
> >>  wrote:
> >>>
> >>> On Thu, Dec 03, 2015 at 01:36:22AM -, Richard Smith via
> cfe-commits
> >>> wrote:
> >>> > Author: rsmith
> >>> > Date: Wed Dec  2 19:36:22 2015
> >>> > New Revision: 254574
> >>> >
> >>> > URL: http://llvm.org/viewvc/llvm-project?rev=254574&view=rev
> >>> > Log:
> >>> > PR17381: Treat undefined behavior during expression evaluation
> as an
> >>> > unmodeled
> >>> > side-effect, so that we don't allow speculative evaluation of
> such
> >>> > expressions
> >>> > during code generation.
> >>> >
> >>> > This caused a diagnostic quality regression, so fix constant
> expression
> >>> > diagnostics to prefer either the first "can't be constant folded"
> >>> > diagnostic or
> >>> > the first "not a constant expression" diagnostic depending on
> the kind
> >>> > of
> >>> > evaluation we're doing. This was always the intent, but didn't
> quite
> >>> > work
> >>> > correctly before.
> >>> >
> >>> > This results in certain initializers that used to be constant
> >>> > initializers to
> >>> > no longer be; in particular, things like:
> >>> >
> >>> >   float f = 1e100;
> >>> >
> >>> > are no longer accepted in C. This seems appropriate, as such
> constructs
> >>> > would
> >>> > lead to code being executed if sanitizers are enabled.
> >>>
> >>> This leads to some pretty annoying regressions as it now seems to
> be
> >>> impossible to use NaN or infinites as constant initializers.
> Expressions
> >>> like 0.0 / 0.0, 1.0 / 0.0 and -1.0 / 0.0 are perfectly well defined
> >>> under normal IEEE rules, so they shouldn't be rejected.
> >>
> >>
> >> Well, we have a problem. The evaluation semantics of these
> expressions
> >> requires code to execute in some build modes (in particular, with
> sanitizers
> >> enabled), and thus has a side-effect.
> >>
> >> I'm inclined to relax the restriction added in this change for the
> >> specific case of global variables in C, since (as you say) there is
> a fair
> >> amount of code using divide-by-zero as a "portable" way of
> generating an inf
> >> or nan.
> >>
> >>> Worse, it seems
> >>> even using __builtin_nan() for example doesn't work.
> >>
> >>
> >> __builtin_nan() works fine for me, can you provide a testcase?
> >>
> >>> I'm not even sure about the example given in the commit message,
> how
> >>> exactly is that undefined behavior?
> >>
> >>
> >> C11 6.3.1.5/1: "If the value being converted is

Re: [PATCH] D15220: [OPENMP] dist_schedule clause for distribute directive

[Alexey Bataev via cfe-commits]

ABataev added a comment.

Carlo,

1. please post your diffs exactly as said in 
http://llvm.org/docs/Phabricator.html, with full context available.
2. add a test with ast-printing, serialization/deserialization



Comment at: include/clang/Basic/OpenMPKinds.def:394-399
@@ -394,1 +393,8 @@
 
+// Clauses allowed for OpenMP directive 'distribute'
+OPENMP_DISTRIBUTE_CLAUSE(private)
+OPENMP_DISTRIBUTE_CLAUSE(firstprivate)
+OPENMP_DISTRIBUTE_CLAUSE(lastprivate)
+OPENMP_DISTRIBUTE_CLAUSE(collapse)
+OPENMP_DISTRIBUTE_CLAUSE(dist_schedule)
+

Please commit a patch with 'ditribute' directive at first


Comment at: test/OpenMP/distribute_dist_schedule_messages.cpp:1
@@ +1,2 @@
+// RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 -verify -fopenmp 
-ferror-limit 100 -o - %s
+

Template test?


Repository:
  rL LLVM

http://reviews.llvm.org/D15220



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

Re: [PATCH] D15174: [MSVC] Fix for http://llvm.org/PR25636: indexed accessor property not supported correctly.

[Alexey Bataev via cfe-commits]

Ok, I will implement this logic

Best regards,
Alexey Bataev
=
Software Engineer
Intel Compiler Team

07.12.2015 22:30, John McCall пишет:
> rjmccall added a comment.
>
> Oh, I see, of course.
>
> It would be clearer if you asked the subclass which value to use abstractly 
> (i.e. independently of the actual set expression) and then passed down 
> captureSetValueAsResult=false when the subclass says to use the setter result.
>
>
> http://reviews.llvm.org/D15174
>
>
>

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

r255001 - Add parse and sema for OpenMP distribute directive and all its clauses excluding dist_schedule.

[Carlo Bertolli via cfe-commits]

Author: cbertol
Date: Mon Dec  7 22:21:03 2015
New Revision: 255001

URL: http://llvm.org/viewvc/llvm-project?rev=255001&view=rev
Log:
Add parse and sema for OpenMP distribute directive and all its clauses 
excluding dist_schedule.

Added:
cfe/trunk/test/OpenMP/distribute_ast_print.cpp
cfe/trunk/test/OpenMP/distribute_collapse_messages.cpp
cfe/trunk/test/OpenMP/distribute_firstprivate_messages.cpp
cfe/trunk/test/OpenMP/distribute_private_messages.cpp
Modified:
cfe/trunk/include/clang-c/Index.h
cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
cfe/trunk/include/clang/AST/StmtOpenMP.h
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/include/clang/Basic/OpenMPKinds.def
cfe/trunk/include/clang/Basic/OpenMPKinds.h
cfe/trunk/include/clang/Basic/StmtNodes.td
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/include/clang/Serialization/ASTBitCodes.h
cfe/trunk/lib/AST/StmtOpenMP.cpp
cfe/trunk/lib/AST/StmtPrinter.cpp
cfe/trunk/lib/AST/StmtProfile.cpp
cfe/trunk/lib/Basic/OpenMPKinds.cpp
cfe/trunk/lib/CodeGen/CGStmt.cpp
cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.h
cfe/trunk/lib/Parse/ParseOpenMP.cpp
cfe/trunk/lib/Sema/SemaOpenMP.cpp
cfe/trunk/lib/Sema/TreeTransform.h
cfe/trunk/lib/Serialization/ASTReaderStmt.cpp
cfe/trunk/lib/Serialization/ASTWriterStmt.cpp
cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp
cfe/trunk/test/OpenMP/nesting_of_regions.cpp
cfe/trunk/tools/libclang/CIndex.cpp
cfe/trunk/tools/libclang/CXCursor.cpp

Modified: cfe/trunk/include/clang-c/Index.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang-c/Index.h?rev=255001&r1=255000&r2=255001&view=diff
==
--- cfe/trunk/include/clang-c/Index.h (original)
+++ cfe/trunk/include/clang-c/Index.h Mon Dec  7 22:21:03 2015
@@ -2264,7 +2264,11 @@ enum CXCursorKind {
*/
   CXCursor_OMPTaskLoopSimdDirective  = 259,
 
-  CXCursor_LastStmt  = CXCursor_OMPTaskLoopSimdDirective,
+   /** \brief OpenMP distribute directive.
+   */
+  CXCursor_OMPDistributeDirective= 260,
+
+  CXCursor_LastStmt  = CXCursor_OMPDistributeDirective,
 
   /**
* \brief Cursor that represents the translation unit itself.

Modified: cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/RecursiveASTVisitor.h?rev=255001&r1=255000&r2=255001&view=diff
==
--- cfe/trunk/include/clang/AST/RecursiveASTVisitor.h (original)
+++ cfe/trunk/include/clang/AST/RecursiveASTVisitor.h Mon Dec  7 22:21:03 2015
@@ -2439,6 +2439,9 @@ DEF_TRAVERSE_STMT(OMPTaskLoopDirective,
 DEF_TRAVERSE_STMT(OMPTaskLoopSimdDirective,
   { TRY_TO(TraverseOMPExecutableDirective(S)); })
 
+DEF_TRAVERSE_STMT(OMPDistributeDirective,
+  { TRY_TO(TraverseOMPExecutableDirective(S)); })
+
 // OpenMP clauses.
 template 
 bool RecursiveASTVisitor::TraverseOMPClause(OMPClause *C) {

Modified: cfe/trunk/include/clang/AST/StmtOpenMP.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/StmtOpenMP.h?rev=255001&r1=255000&r2=255001&view=diff
==
--- cfe/trunk/include/clang/AST/StmtOpenMP.h (original)
+++ cfe/trunk/include/clang/AST/StmtOpenMP.h Mon Dec  7 22:21:03 2015
@@ -424,43 +424,50 @@ protected:
   void setInc(Expr *Inc) { *std::next(child_begin(), IncOffset) = Inc; }
   void setIsLastIterVariable(Expr *IL) {
 assert((isOpenMPWorksharingDirective(getDirectiveKind()) ||
-isOpenMPTaskLoopDirective(getDirectiveKind())) &&
+isOpenMPTaskLoopDirective(getDirectiveKind()) ||
+isOpenMPDistributeDirective(getDirectiveKind())) &&
"expected worksharing loop directive");
 *std::next(child_begin(), IsLastIterVariableOffset) = IL;
   }
   void setLowerBoundVariable(Expr *LB) {
 assert((isOpenMPWorksharingDirective(getDirectiveKind()) ||
-isOpenMPTaskLoopDirective(getDirectiveKind())) &&
+isOpenMPTaskLoopDirective(getDirectiveKind()) ||
+isOpenMPDistributeDirective(getDirectiveKind())) &&
"expected worksharing loop directive");
 *std::next(child_begin(), LowerBoundVariableOffset) = LB;
   }
   void setUpperBoundVariable(Expr *UB) {
 assert((isOpenMPWorksharingDirective(getDirectiveKind()) ||
-isOpenMPTaskLoopDirective(getDirectiveKind())) &&
+isOpenMPTaskLoopDirective(getDirectiveKind()) ||
+isOpenMPDistributeDirective(getDirectiveKind())) &&
"expected worksharing loop directive");
 *std::next(child_begin(), UpperBoundVariableOffset) = UB;
   }
   void setStrideVariable(Expr *ST) {
 assert((isOpenMPWorksharingDirective(get

r255004 - [Sema] Remove tab characters. NFC

[Craig Topper via cfe-commits]

Author: ctopper
Date: Mon Dec  7 22:33:04 2015
New Revision: 255004

URL: http://llvm.org/viewvc/llvm-project?rev=255004&view=rev
Log:
[Sema] Remove tab characters. NFC

Modified:
cfe/trunk/lib/Sema/SemaExpr.cpp

Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExpr.cpp?rev=255004&r1=255003&r2=255004&view=diff
==
--- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExpr.cpp Mon Dec  7 22:33:04 2015
@@ -10410,7 +10410,7 @@ ExprResult Sema::CreateBuiltinBinOp(Sour
 break;
   case BO_AndAssign:
   case BO_OrAssign: // fallthrough
- DiagnoseSelfAssignment(*this, LHS.get(), RHS.get(), OpLoc);
+DiagnoseSelfAssignment(*this, LHS.get(), RHS.get(), OpLoc);
   case BO_XorAssign:
 CompResultTy = CheckBitwiseOperands(LHS, RHS, OpLoc, true);
 CompLHSTy = CompResultTy;
@@ -13480,7 +13480,7 @@ static void DoMarkVarDeclReferenced(Sema
 }
 
 if (!isTemplateInstantiation(TSK))
-   return;
+  return;
 
 // Instantiate, but do not mark as odr-used, variable templates.
 MarkODRUsed = false;


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

Re: [PATCH] D15125: [OPENMP] 'omp distribute' directive basic support.

[Carlo Bertolli via cfe-commits]

carlo.bertolli closed this revision.
carlo.bertolli added a comment.

This was committed in r255001.

Many thanks for all your help.


Repository:
  rL LLVM

http://reviews.llvm.org/D15125



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

Re: [PATCH] D13330: Implement __attribute__((unique_instantiation))

[Keno Fischer via cfe-commits]

loladiro updated this revision to Diff 42137.
loladiro added a comment.

Propagate unique instantiation attribute to children rather than later trying 
to look through the DeclContexts to see if we're contained in one that has the 
attribute.


http://reviews.llvm.org/D13330

Files:
  include/clang/Basic/Attr.td
  include/clang/Basic/AttrDocs.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Sema/AttributeList.h
  include/clang/Sema/Sema.h
  lib/AST/ASTContext.cpp
  lib/CodeGen/CGVTables.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaDeclAttr.cpp
  lib/Sema/SemaDeclCXX.cpp
  lib/Sema/SemaTemplate.cpp
  test/CodeGenCXX/unique-instantiation.cpp
  test/SemaCXX/unique-instantiations.cpp
  utils/TableGen/ClangAttrEmitter.cpp

Index: utils/TableGen/ClangAttrEmitter.cpp
===
--- utils/TableGen/ClangAttrEmitter.cpp
+++ utils/TableGen/ClangAttrEmitter.cpp
@@ -2373,6 +2373,8 @@
 case Func | ObjCMethod | Param: return "ExpectedFunctionMethodOrParameter";
 case Func | ObjCMethod: return "ExpectedFunctionOrMethod";
 case Func | Var: return "ExpectedVariableOrFunction";
+case Func | Class:
+  return "ExpectedFunctionOrClass";
 
 // If not compiling for C++, the class portion does not apply.
 case Func | Var | Class:
Index: test/SemaCXX/unique-instantiations.cpp
===
--- /dev/null
+++ test/SemaCXX/unique-instantiations.cpp
@@ -0,0 +1,48 @@
+// RUN: %clang -cc1 -std=c++14 -fsyntax-only -verify %s
+
+// Correct usage
+template 
+struct foo {};
+extern template struct __attribute__((unique_instantiation)) foo;
+template struct __attribute__((unique_instantiation)) foo;
+
+template 
+T pi = T(3.1415926535897932385);
+extern template __attribute__((unique_instantiation)) float pi;
+template __attribute__((unique_instantiation)) float pi;
+
+// Usages on non-templates
+float __attribute__((unique_instantiation)) notpi(2.71828182845904523536028747135); // expected-error{{'unique_instantiation' attribute only applies to explicit template declarations or definitions}}
+struct __attribute__((unique_instantiation)) bar {};// expected-error{{'unique_instantiation' attribute only applies to explicit template declarations or definitions}}
+void __attribute__((unique_instantiation)) func() {}// expected-error{{'unique_instantiation' attribute only applies to explicit template declarations or definitions}}
+
+// Usages that violate one of the conditions required conditions
+template 
+struct foo1 {};
+template struct __attribute__((unique_instantiation)) foo1; // expected-error{{'unique_instantiation' attribute on an explicit instantiation requires a previous explicit instantiation declaration}}
+
+template 
+T pi1 = T(3.1415926535897932385);
+template __attribute__((unique_instantiation)) float pi1; // expected-error{{'unique_instantiation' attribute on an explicit instantiation requires a previous explicit instantiation declaration}}
+
+template 
+struct foo2 {};
+extern template struct foo2;// expected-note{{previous explicit instantiation is here}}
+template struct __attribute__((unique_instantiation)) foo2; // expected-error{{'unique_instantiation' attribute must be specified for all declarations and definitions of this explicit template instantiation}}
+
+template 
+struct foo3 {};
+extern template struct __attribute__((unique_instantiation)) foo3; // expected-note{{previous explicit instantiation is here}}
+extern template struct foo3;   // expected-error{{'unique_instantiation' attribute must be specified for all declarations and definitions of this explicit template instantiation}}
+
+template 
+struct __attribute__((unique_instantiation)) foo4 {}; // expected-error{{'unique_instantiation' attribute only applies to explicit template declarations or definitions}}
+
+template 
+struct foo5 {};
+extern template struct __attribute__((unique_instantiation)) foo5; // expected-note{{previous explicit instantiation is here}}
+template struct foo5;  // expected-error{{'unique_instantiation' attribute must be specified for all declarations and definitions of this explicit template instantiation}}
+
+template 
+struct foo6 {};
+extern template struct __attribute__((unique_instantiation(16))) foo6; // expected-error{{'unique_instantiation' attribute takes no arguments}}
Index: test/CodeGenCXX/unique-instantiation.cpp
===
--- /dev/null
+++ test/CodeGenCXX/unique-instantiation.cpp
@@ -0,0 +1,74 @@
+// RUN: %clang -std=c++14 -emit-llvm -c -S -o - %s | FileCheck %s
+
+// CHECK: @_Z2piIfE = global float
+// CHECK-NOT: @_Z2piIfE = weak_odr global float
+template 
+T pi = T(3.1415926535897932385);
+extern template __attribute__((unique_instantiation)

Re: [PATCH] D15321: [OpenMP 4.0]Parsing and Sema support for 'omp declare target' directive (accelerator support)

[Alexey Bataev via cfe-commits]

ABataev added a comment.

Michael, please provide full diff log, as described in 
http://llvm.org/docs/Phabricator.html (with full context)


Repository:
  rL LLVM

http://reviews.llvm.org/D15321



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