date:20160331

Re: [PATCH] D18567: Block: Fix a crash when we have type attributes or qualifiers with omitted return type.

2016-03-31 Thread Manman Ren via cfe-commits

manmanren marked 3 inline comments as done.


Comment at: lib/Sema/SemaType.cpp:1253-1254
@@ -1252,4 +1253,4 @@
   break;
 } else if (declarator.getContext() == Declarator::LambdaExprContext ||
isOmittedBlockReturnType(declarator)) {
   Result = Context.DependentTy;

rsmith wrote:
> Instead of checking for qualifiers below, how about checking here (or, 
> preferably, in `isOmittedBlockReturnType`) whether there were any present, 
> and not treating the block as having an omitted return type if there actually 
> is a return type present?
Makes sense to put related things together .


Comment at: lib/Sema/SemaType.cpp:1561
@@ +1560,3 @@
+AttributeList *cur = attrs, *prev = nullptr;
+while (cur) {
+  AttributeList  = *cur;

rsmith wrote:
> Maybe write this as `for (AttributeList *cur = attrs; cur; cur = 
> cur->getNext())` and drop the `cur = cur->getNext()` assignments below.
Yes.


Comment at: lib/Sema/SemaType.cpp:1575-1583
@@ +1574,11 @@
+  // Remove cur from the list.
+  if (attrs == cur) {
+attrs = attr.getNext();
+prev = nullptr;
+cur = cur->getNext();
+continue;
+  }
+  prev->setNext(attr.getNext());
+  prev = cur;
+  cur = cur->getNext();
+}

rsmith wrote:
> You can express this more simply as:
> 
>   if (prev)
> prev->setNext(cur->getNext());
>   else
> attrs = cur->getNext();
>   cur = cur->getNext();
> 
Yes.


Comment at: test/SemaOpenCL/invalid-block.cl:8-9
@@ -8,4 +7,4 @@
+  int (^bl1)() = ^() {return 1;}; // expected-error{{invalid block variable 
declaration - must be const qualified}}
   int (^const bl2)(); // expected-error{{invalid block variable declaration - 
must be initialized}}
-  int (^const bl3)() = ^const(){
-  };
+  int (^const bl3)() = ^(){return 1;};
 }

Yes, John is right. The DependentTy is never replaced if wrapped with an 
Attributed type or a qualified type.


http://reviews.llvm.org/D18567



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

r265104 - Visual Studio native visualizers for clang::TemplateSpecializationType

2016-03-31 Thread Mike Spertus via cfe-commits

Author: mps
Date: Thu Mar 31 22:31:43 2016
New Revision: 265104

URL: http://llvm.org/viewvc/llvm-project?rev=265104=rev
Log:
Visual Studio native visualizers for clang::TemplateSpecializationType

Displays a template specialization as, say, A. Does not
yet handle UncommonTemplateNameStorage, QualifiedTemplateName, or
DependentTemplateName, but still more than worthwhile

Modified:
cfe/trunk/utils/ClangVisualizers/clang.natvis

Modified: cfe/trunk/utils/ClangVisualizers/clang.natvis
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/utils/ClangVisualizers/clang.natvis?rev=265104=265103=265104=diff
==
--- cfe/trunk/utils/ClangVisualizers/clang.natvis (original)
+++ cfe/trunk/utils/ClangVisualizers/clang.natvis Thu Mar 31 22:31:43 2016
@@ -229,6 +229,7 @@ For later versions of Visual Studio, no
 
   
   
+{*(clang::QualType 
*)TypeOrValue.V,view(cpp)}
 {(clang::TemplateArgument::ArgKind)TypeOrValue.Kind,en} 
template parameter: {*(clang::QualType *)TypeOrValue.V}
 
   *(clang::QualType 
*)TypeOrValue.V
@@ -269,8 +270,22 @@ For later versions of Visual Studio, no
   
 
   
-{(clang::TemplateDecl 
*)((Template.Storage.Val.Val.Value  2)  2)}
-{Template.Storage}
+
+{((clang::TemplateArgument 
*)(this+1))[0],view(cpp)}{*this,view(arg1)}
+
+, {((clang::TemplateArgument 
*)(this+1))[1],view(cpp)}{*this,view(arg2)}
+
+, {((clang::TemplateArgument 
*)(this+1))[2],view(cpp)}{*this,view(arg3)}
+
+  {*((clang::TemplateDecl *)((Template.Storage.Val.Val.Value  2) 
 2))->TemplatedDecl,view(cpp)}{*this,view(arg0)}
+
+
+  Template.Storage
+  
+NumArgs
+(clang::TemplateArgument *)(this+1)
+  
+
   
   
 {((llvm::StringMapEntryclang::IdentifierInfo 
**)Entry)+1,sb}


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

r265103 - [analyzer] Prefer accessor method in extension over category in CallEvent.

2016-03-31 Thread Devin Coughlin via cfe-commits

Author: dcoughlin
Date: Thu Mar 31 22:24:13 2016
New Revision: 265103

URL: http://llvm.org/viewvc/llvm-project?rev=265103=rev
Log:
[analyzer] Prefer accessor method in extension over category in CallEvent.

In ObjCMethodCall:getRuntimeDefinition(), if the method is an accessor in a
category, and it doesn't have a self declaration, first try to find the method
in a class extension. This works around a bug in Sema where multiple accessors
are synthesized for properties in class extensions that are redeclared in a
category. The implicit parameters are not filled in for the method on the
category, which causes a crash when trying to synthesize a getter for the
property in BodyFarm. The Sema bug is tracked as rdar://problem/25481164.

rdar://problem/25056531

Modified:
cfe/trunk/lib/StaticAnalyzer/Core/CallEvent.cpp
cfe/trunk/test/Analysis/properties.m

Modified: cfe/trunk/lib/StaticAnalyzer/Core/CallEvent.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/CallEvent.cpp?rev=265103=265102=265103=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Core/CallEvent.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Core/CallEvent.cpp Thu Mar 31 22:24:13 2016
@@ -958,8 +958,30 @@ RuntimeDefinition ObjCMethodCall::getRun
   // even if we don't actually have an implementation.
   if (!*Val)
 if (const ObjCMethodDecl *CompileTimeMD = E->getMethodDecl())
-  if (CompileTimeMD->isPropertyAccessor())
-Val = IDecl->lookupInstanceMethod(Sel);
+  if (CompileTimeMD->isPropertyAccessor()) {
+if (!CompileTimeMD->getSelfDecl() &&
+isa(CompileTimeMD->getDeclContext())) {
+  // If the method is an accessor in a category, and it doesn't
+  // have a self declaration, first
+  // try to find the method in a class extension. This
+  // works around a bug in Sema where multiple accessors
+  // are synthesized for properties in class
+  // extensions that are redeclared in a category and the
+  // the implicit parameters are not filled in for
+  // the method on the category.
+  // This ensures we find the accessor in the extension, which
+  // has the implicit parameters filled in.
+  auto *ID = CompileTimeMD->getClassInterface();
+  for (auto *CatDecl : ID->visible_extensions()) {
+Val = CatDecl->getMethod(Sel,
+ 
CompileTimeMD->isInstanceMethod());
+if (*Val)
+  break;
+  }
+}
+if (!*Val)
+  Val = IDecl->lookupInstanceMethod(Sel);
+  }
 }
 
 const ObjCMethodDecl *MD = Val.getValue();

Modified: cfe/trunk/test/Analysis/properties.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/properties.m?rev=265103=265102=265103=diff
==
--- cfe/trunk/test/Analysis/properties.m (original)
+++ cfe/trunk/test/Analysis/properties.m Thu Mar 31 22:24:13 2016
@@ -247,6 +247,55 @@ void testConsistencyAssign(Person *p) {
 }
 @end
 
+// Tests for the analyzer fix that works around a Sema bug
+// where multiple methods are created for properties in class extensions that
+// are redeclared in a category method.
+// The Sema bug is tracked as .
+@interface ClassWithRedeclaredPropertyInExtensionFollowedByCategory
+@end
+
+@interface ClassWithRedeclaredPropertyInExtensionFollowedByCategory ()
+@end
+
+@interface ClassWithRedeclaredPropertyInExtensionFollowedByCategory ()
+@property (readwrite) int someProp;
+@property (readonly) int otherProp;
+@end
+
+@interface ClassWithRedeclaredPropertyInExtensionFollowedByCategory (MyCat)
+@property (readonly) int someProp;
+@property (readonly) int otherProp;
+@end
+
+@implementation ClassWithRedeclaredPropertyInExtensionFollowedByCategory
+- (void)testSynthesisForRedeclaredProperties; {
+  clang_analyzer_eval(self.someProp == self.someProp); // 
expected-warning{{TRUE}}
+  clang_analyzer_eval([self someProp] == self.someProp); // 
expected-warning{{TRUE}}
+
+  clang_analyzer_eval(self.otherProp == self.otherProp); // 
expected-warning{{TRUE}}
+  clang_analyzer_eval([self otherProp] == self.otherProp); // 
expected-warning{{TRUE}}
+}
+@end
+
+// The relative order of the extension and the category matter, so test both.
+@interface ClassWithRedeclaredPropertyInCategoryFollowedByExtension
+@end
+
+@interface ClassWithRedeclaredPropertyInCategoryFollowedByExtension ()
+@property (readwrite) int someProp;
+@end
+
+@interface ClassWithRedeclaredPropertyInCategoryFollowedByExtension (MyCat)
+@property (readonly) int someProp;
+@end
+
+@implementation

Re: [PATCH] D18575: [clang-tidy] New checker to replace deprecated throw() specifications

2016-03-31 Thread don hinton via cfe-commits

hintonda added a comment.

Addressed comments and believe it's ready for review.


http://reviews.llvm.org/D18575



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

Re: [PATCH] D18575: [clang-tidy] New checker to replace deprecated throw() specifications

2016-03-31 Thread don hinton via cfe-commits

hintonda marked 8 inline comments as done.
hintonda added a comment.

http://reviews.llvm.org/D18575



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

Re: [PATCH] D18575: [clang-tidy] New checker to replace deprecated throw() specifications

2016-03-31 Thread don hinton via cfe-commits

hintonda updated this revision to Diff 52322.
hintonda added a comment.

Address comments and refactor.


http://reviews.llvm.org/D18575

Files:
  clang-tidy/modernize/CMakeLists.txt
  clang-tidy/modernize/ModernizeTidyModule.cpp
  clang-tidy/modernize/UseNoexceptCheck.cpp
  clang-tidy/modernize/UseNoexceptCheck.h
  docs/clang-tidy/checks/modernize-use-noexcept.rst
  test/clang-tidy/modernize-use-noexcept-macro.cpp
  test/clang-tidy/modernize-use-noexcept.cpp

Index: test/clang-tidy/modernize-use-noexcept.cpp
===
--- /dev/null
+++ test/clang-tidy/modernize-use-noexcept.cpp
@@ -0,0 +1,22 @@
+// RUN: %check_clang_tidy %s modernize-use-noexcept %t -- \
+// RUN:   -- -std=c++11
+
+class A{};
+class B{};
+
+void foo() throw();
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: function 'foo': Replace dynamic exception specifications 'throw()' with 'noexcept' [modernize-use-noexcept]
+// CHECK-FIXES: void foo() noexcept;
+
+void bar() throw(...);
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: function 'bar': Replace dynamic exception specifications 'throw(...)' with 'noexcept(false)' [modernize-use-noexcept]
+// CHECK-FIXES: void bar() noexcept(false);
+
+void foobar() throw(A, B)
+{}
+// CHECK-MESSAGES: :[[@LINE-2]]:6: warning: function 'foobar': Replace dynamic exception specifications 'throw(A, B)' with 'noexcept(false)' [modernize-use-noexcept]
+// CHECK-FIXES: void foobar() noexcept(false)
+
+// Should not trigger a replacement.
+void titi() noexcept {}
+void toto() noexcept(true) {}
Index: test/clang-tidy/modernize-use-noexcept-macro.cpp
===
--- /dev/null
+++ test/clang-tidy/modernize-use-noexcept-macro.cpp
@@ -0,0 +1,13 @@
+// RUN: %check_clang_tidy %s modernize-use-noexcept %t -- \
+// RUN:   -config="{CheckOptions: [{key: modernize-use-noexcept.ReplacementString, value: 'NOEXCEPT'}]}" \
+// RUN:   -- -std=c++11
+
+#define NOEXCEPT noexcept
+
+void bar() throw() {}
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: function 'bar': Replace dynamic exception specifications 'throw()' with 'NOEXCEPT' [modernize-use-noexcept]
+// CHECK-FIXES: void bar() NOEXCEPT {}
+
+// Should not trigger a replacement.
+void foo() noexcept(true);
+
Index: docs/clang-tidy/checks/modernize-use-noexcept.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/modernize-use-noexcept.rst
@@ -0,0 +1,50 @@
+.. title:: clang-tidy - modernize-use-noexcept
+
+modernize-use-noexcept
+==
+
+The check converts dynamic exception specifications, e.g., throw(),
+throw([,...]), or throw(...) to noexcept, noexcept(false),
+or a user defined macro.
+
+Example
+---
+
+.. code-block:: c++
+
+  void foo() throw();
+	void bar() throw(int) {}
+
+transforms to:
+
+.. code-block:: c++
+
+  void foo() noexcept;
+	void bar() noexcept(false) {}
+
+
+User defined macros
+---
+
+By default this check will only replace ``throw()`` with ``noexcept``,
+and ``throw([,...])`` or ``throw(...)`` with
+``throw(false)``.  Additinally, users can also use
+:option:``ReplacementString`` to specify a macro to use instead of
+``noexcept``.  This is useful when maintaining source code that must
+compile on older compilers that don't support the ``noexcept``
+keyword.
+
+Example
+^^^
+
+.. code-block:: c++
+
+  void foo() throw() {}
+
+transforms to:
+
+.. code-block:: c++
+
+  void foo() NOEXCEPT {}
+
+if the ``ReplacementString`` option is set to ``NOEXCEPT``.
Index: clang-tidy/modernize/UseNoexceptCheck.h
===
--- /dev/null
+++ clang-tidy/modernize/UseNoexceptCheck.h
@@ -0,0 +1,53 @@
+//===--- UseNoexceptCheck.h - clang-tidy-*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MODERNIZE_USE_NOEXCEPT_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MODERNIZE_USE_NOEXCEPT_H
+
+#include "../ClangTidy.h"
+
+namespace clang {
+namespace tidy {
+namespace modernize {
+
+using CandidateSet = llvm::StringSet;
+
+/// \brief Replace dynamic exception specifications, with
+/// noexcept[({true|false})] or a user defined macro.
+/// \code
+///   void foo() throw();
+/// \endcode
+/// Is converted to:
+/// \code
+///   void foo() noexcept;
+/// \endcode
+///
+/// For the user-facing documentation see:
+/// http://clang.llvm.org/extra/clang-tidy/checks/modernize-use-noexcept.html
+class UseNoexceptCheck : public ClangTidyCheck {
+public:
+  UseNoexceptCheck(StringRef Name, ClangTidyContext *Context)
+  : ClangTidyCheck(Name, Context),
+ReplacementStr(Options.get("ReplacementString", "noexcept")) {}
+
+  void

Re: [PATCH] D18635: Rework interface for bitset-using features to use a notion of class scope.

2016-03-31 Thread Peter Collingbourne via cfe-commits

pcc added inline comments.


Comment at: docs/ClassScope.rst:2
@@ +1,3 @@
+===
+Class Scope
+===

rsmith wrote:
> pcc wrote:
> > rsmith wrote:
> > > pcc wrote:
> > > > rsmith wrote:
> > > > > Can you use some word other than "scope" here? "Class scope" is 
> > > > > already a term of art in C++, meaning something completely different. 
> > > > > I think what you're referring to is exactly the visibility of the 
> > > > > class (in the ELF sense).
> > > > Yes, this is pretty much visibility. I wanted to avoid using the term 
> > > > "visibility" because I'm introducing flags and attributes which can 
> > > > make scope mean something different to object file visibility, so I 
> > > > wanted to avoid the overload to avoid confusion.
> > > > 
> > > > Maybe the overloading would help with understanding though if I add a 
> > > > qualifying adjective. This is all about whether all derived classes are 
> > > > visible, so maybe the right term is something like "derived visibility"?
> > > We already have attributes that can set the visibility of a class (which 
> > > in turn affects the visibility of the vtable etc.) In what way is that 
> > > different from what you're proposing? Is this a valuable difference, 
> > > given the complexity of having two similar-but-different ways of 
> > > describing the cross-DSO visibility of a class?
> > Yes, ideally I'd like to just use visibility for this. There were a couple 
> > of things that motivated a design that separated the concepts, though:
> > 
> > 1. The part of the executable or DSO that we're LTOing may be a subset of 
> > the whole executable or DSO. If the user has prebuilt object files that 
> > they need to link into their executable or DSO, we need to exclude those 
> > classes from our analysis. One example of this would be the standard 
> > library. On most platforms this is marked up with default visibility 
> > attributes, so we're fine, but on Windows the platform ships an un-marked 
> > up standard library as a static library, and allows users to link to it. 
> > The idea is that Windows users who use the static standard library would be 
> > able to say
> > ```
> > namespace [[clang::global_scope]] std {}
> > ```
> > in a `-include`d header and get global scope on the standard library.
> > 
> > 2. I wanted `-fsanitize=cfi*` to turn on CFI checks on classes by default. 
> > It would be surprising to users if that flag on its own did not enable CFI 
> > on classes declared in the normal way, and it could easily lead to users 
> > shipping unprotected binaries. I suppose an alternative thing we could do 
> > would be to make `-fsanitize=cfi*` imply `-fvisibility=hidden`. Then if 
> > things break, they would at least be likely to break loudly.
> I'm really not happy about having a third granularity for entity uniqueness 
> (LTO granularity) between DSO granularity (visibility) and module granularity 
> (linkage). But if we need that to accurately represent the state of the 
> world, then perhaps there's no way to escape it (although if that is the 
> intent, then the documentation here should be talking about something like 
> LTO units rather than linkage units).
> 
>  1) Would it be inappropriate for entities in `namespace std` on Windows to 
> be given default visibility when people do this?
> 
>  2) I don't think it makes sense for the `-fsanitize=cfi*` flag to enable 
> "types can only be declared within their own LTO unit by default" semantics, 
> whether those semantics are related to devirtualization, CFI, or symbol 
> visibility. Sanitizer flags are supposed to turn on checks for the ambient 
> configuration, not change what the code means; I'd prefer to say that it's an 
> error if you enable `-fsanitize=cfi*` and don't *also* enable 
> `fvisibility=hidden` (or a hypothetical `-fclass-visibility=hidden`).
1. Deciding to treat `std` specially based on flags like `/MT` makes sense to 
me, but visibility isn't a thing on Windows, and dll*port affects the ABI, so 
we probably need the in-between state there.
2. Okay, I prefer that over what I proposed. I suppose users could specify 
`-fvisibility=default` if that's really what they want.

Let's say we simplify this down to no new driver flags and one new attribute 
that disables vtable opt and CFI on hidden visibility and non-dll*port classes 
(no namespace attributes). Let me confirm that that's enough for the use cases 
I care about.


http://reviews.llvm.org/D18635



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

Re: [PATCH] D18672: [NVPTX] Read __CUDA_FTZ from module flags in NVVMReflect.

2016-03-31 Thread Justin Lebar via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL265090: [NVPTX] Read __CUDA_FTZ from module flags in 
NVVMReflect. (authored by jlebar).

Changed prior to commit:
  http://reviews.llvm.org/D18672?vs=52274=52320#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D18672

Files:
  llvm/trunk/lib/Target/NVPTX/NVVMReflect.cpp
  llvm/trunk/test/CodeGen/NVPTX/nvvm-reflect-module-flag.ll

Index: llvm/trunk/test/CodeGen/NVPTX/nvvm-reflect-module-flag.ll
===
--- llvm/trunk/test/CodeGen/NVPTX/nvvm-reflect-module-flag.ll
+++ llvm/trunk/test/CodeGen/NVPTX/nvvm-reflect-module-flag.ll
@@ -0,0 +1,13 @@
+; RUN: opt < %s -S -nvvm-reflect | FileCheck %s
+
+declare i32 @__nvvm_reflect(i8*)
+@str = private unnamed_addr addrspace(1) constant [11 x i8] c"__CUDA_FTZ\00"
+
+define i32 @foo() {
+  %call = call i32 @__nvvm_reflect(i8* addrspacecast (i8 addrspace(1)* 
getelementptr inbounds ([11 x i8], [11 x i8] addrspace(1)* @str, i32 0, i32 0) 
to i8*))
+  ; CHECK: ret i32 42
+  ret i32 %call
+}
+
+!llvm.module.flags = !{!0}
+!0 = !{i32 4, !"nvvm-reflect-ftz", i32 42}
Index: llvm/trunk/lib/Target/NVPTX/NVVMReflect.cpp
===
--- llvm/trunk/lib/Target/NVPTX/NVVMReflect.cpp
+++ llvm/trunk/lib/Target/NVPTX/NVVMReflect.cpp
@@ -7,11 +7,16 @@
 //
 
//===--===//
 //
-// This pass replaces occurrences of __nvvm_reflect("string") and
-// llvm.nvvm.reflect with an integer based on the value of -nvvm-reflect-list
-// string=.
+// This pass replaces occurrences of __nvvm_reflect("foo") and 
llvm.nvvm.reflect
+// with an integer.
 //
-// If we see a string not specified in our flags, we replace that call with 0.
+// We choose the value we use by looking, in this order, at:
+//
+//  * the -nvvm-reflect-list flag, which has the format "foo=1,bar=42",
+//  * the StringMap passed to the pass's constructor, and
+//  * metadata in the module itself.
+//
+// If we see an unknown string, we replace its call with 0.
 //
 
//===--===//
 
@@ -55,10 +60,9 @@
   static char ID;
   NVVMReflect() : NVVMReflect(StringMap()) {}
 
-  NVVMReflect(const StringMap ) : FunctionPass(ID) {
+  NVVMReflect(const StringMap )
+  : FunctionPass(ID), VarMap(Mapping) {
 initializeNVVMReflectPass(*PassRegistry::getPassRegistry());
-for (const auto  : Mapping)
-  VarMap[KV.getKey()] = KV.getValue();
 setVarMap();
   }
 
@@ -206,6 +210,12 @@
 auto Iter = VarMap.find(ReflectArg);
 if (Iter != VarMap.end())
   ReflectVal = Iter->second;
+else if (ReflectArg == "__CUDA_FTZ") {
+  // Try to pull __CUDA_FTZ from the nvvm-reflect-ftz module flag.
+  if (auto *Flag = mdconst::extract_or_null(
+  F.getParent()->getModuleFlag("nvvm-reflect-ftz")))
+ReflectVal = Flag->getSExtValue();
+}
 Call->replaceAllUsesWith(ConstantInt::get(Call->getType(), ReflectVal));
 ToRemove.push_back(Call);
   }


Index: llvm/trunk/test/CodeGen/NVPTX/nvvm-reflect-module-flag.ll
===
--- llvm/trunk/test/CodeGen/NVPTX/nvvm-reflect-module-flag.ll
+++ llvm/trunk/test/CodeGen/NVPTX/nvvm-reflect-module-flag.ll
@@ -0,0 +1,13 @@
+; RUN: opt < %s -S -nvvm-reflect | FileCheck %s
+
+declare i32 @__nvvm_reflect(i8*)
+@str = private unnamed_addr addrspace(1) constant [11 x i8] c"__CUDA_FTZ\00"
+
+define i32 @foo() {
+  %call = call i32 @__nvvm_reflect(i8* addrspacecast (i8 addrspace(1)* getelementptr inbounds ([11 x i8], [11 x i8] addrspace(1)* @str, i32 0, i32 0) to i8*))
+  ; CHECK: ret i32 42
+  ret i32 %call
+}
+
+!llvm.module.flags = !{!0}
+!0 = !{i32 4, !"nvvm-reflect-ftz", i32 42}
Index: llvm/trunk/lib/Target/NVPTX/NVVMReflect.cpp
===
--- llvm/trunk/lib/Target/NVPTX/NVVMReflect.cpp
+++ llvm/trunk/lib/Target/NVPTX/NVVMReflect.cpp
@@ -7,11 +7,16 @@
 //
 //===--===//
 //
-// This pass replaces occurrences of __nvvm_reflect("string") and
-// llvm.nvvm.reflect with an integer based on the value of -nvvm-reflect-list
-// string=.
+// This pass replaces occurrences of __nvvm_reflect("foo") and llvm.nvvm.reflect
+// with an integer.
 //
-// If we see a string not specified in our flags, we replace that call with 0.
+// We choose the value we use by looking, in this order, at:
+//
+//  * the -nvvm-reflect-list flag, which has the format "foo=1,bar=42",
+//  * the StringMap passed to the pass's constructor, and
+//  * metadata in the module itself.
+//
+// If we see an unknown string, we replace its call with 0.
 //
 //===--===//
 
@@ -55,10 +60,9 @@
   static char ID;
   NVVMReflect() :

Re: [PATCH] D18567: Block: Fix a crash when we have type attributes or qualifiers with omitted return type.

2016-03-31 Thread Richard Smith via cfe-commits

rsmith added inline comments.


Comment at: lib/Sema/SemaType.cpp:1253-1254
@@ -1252,4 +1253,4 @@
   break;
 } else if (declarator.getContext() == Declarator::LambdaExprContext ||
isOmittedBlockReturnType(declarator)) {
   Result = Context.DependentTy;

Instead of checking for qualifiers below, how about checking here (or, 
preferably, in `isOmittedBlockReturnType`) whether there were any present, and 
not treating the block as having an omitted return type if there actually is a 
return type present?


Comment at: lib/Sema/SemaType.cpp:1561
@@ +1560,3 @@
+AttributeList *cur = attrs, *prev = nullptr;
+while (cur) {
+  AttributeList  = *cur;

Maybe write this as `for (AttributeList *cur = attrs; cur; cur = 
cur->getNext())` and drop the `cur = cur->getNext()` assignments below.


Comment at: lib/Sema/SemaType.cpp:1575-1583
@@ +1574,11 @@
+  // Remove cur from the list.
+  if (attrs == cur) {
+attrs = attr.getNext();
+prev = nullptr;
+cur = cur->getNext();
+continue;
+  }
+  prev->setNext(attr.getNext());
+  prev = cur;
+  cur = cur->getNext();
+}

You can express this more simply as:

  if (prev)
prev->setNext(cur->getNext());
  else
attrs = cur->getNext();
  cur = cur->getNext();



http://reviews.llvm.org/D18567



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

Re: [PATCH] D18635: Rework interface for bitset-using features to use a notion of class scope.

2016-03-31 Thread Richard Smith via cfe-commits

rsmith added inline comments.


Comment at: docs/ClassScope.rst:2
@@ +1,3 @@
+===
+Class Scope
+===

pcc wrote:
> rsmith wrote:
> > pcc wrote:
> > > rsmith wrote:
> > > > Can you use some word other than "scope" here? "Class scope" is already 
> > > > a term of art in C++, meaning something completely different. I think 
> > > > what you're referring to is exactly the visibility of the class (in the 
> > > > ELF sense).
> > > Yes, this is pretty much visibility. I wanted to avoid using the term 
> > > "visibility" because I'm introducing flags and attributes which can make 
> > > scope mean something different to object file visibility, so I wanted to 
> > > avoid the overload to avoid confusion.
> > > 
> > > Maybe the overloading would help with understanding though if I add a 
> > > qualifying adjective. This is all about whether all derived classes are 
> > > visible, so maybe the right term is something like "derived visibility"?
> > We already have attributes that can set the visibility of a class (which in 
> > turn affects the visibility of the vtable etc.) In what way is that 
> > different from what you're proposing? Is this a valuable difference, given 
> > the complexity of having two similar-but-different ways of describing the 
> > cross-DSO visibility of a class?
> Yes, ideally I'd like to just use visibility for this. There were a couple of 
> things that motivated a design that separated the concepts, though:
> 
> 1. The part of the executable or DSO that we're LTOing may be a subset of the 
> whole executable or DSO. If the user has prebuilt object files that they need 
> to link into their executable or DSO, we need to exclude those classes from 
> our analysis. One example of this would be the standard library. On most 
> platforms this is marked up with default visibility attributes, so we're 
> fine, but on Windows the platform ships an un-marked up standard library as a 
> static library, and allows users to link to it. The idea is that Windows 
> users who use the static standard library would be able to say
> ```
> namespace [[clang::global_scope]] std {}
> ```
> in a `-include`d header and get global scope on the standard library.
> 
> 2. I wanted `-fsanitize=cfi*` to turn on CFI checks on classes by default. It 
> would be surprising to users if that flag on its own did not enable CFI on 
> classes declared in the normal way, and it could easily lead to users 
> shipping unprotected binaries. I suppose an alternative thing we could do 
> would be to make `-fsanitize=cfi*` imply `-fvisibility=hidden`. Then if 
> things break, they would at least be likely to break loudly.
I'm really not happy about having a third granularity for entity uniqueness 
(LTO granularity) between DSO granularity (visibility) and module granularity 
(linkage). But if we need that to accurately represent the state of the world, 
then perhaps there's no way to escape it (although if that is the intent, then 
the documentation here should be talking about something like LTO units rather 
than linkage units).

 1) Would it be inappropriate for entities in `namespace std` on Windows to be 
given default visibility when people do this?

 2) I don't think it makes sense for the `-fsanitize=cfi*` flag to enable 
"types can only be declared within their own LTO unit by default" semantics, 
whether those semantics are related to devirtualization, CFI, or symbol 
visibility. Sanitizer flags are supposed to turn on checks for the ambient 
configuration, not change what the code means; I'd prefer to say that it's an 
error if you enable `-fsanitize=cfi*` and don't *also* enable 
`fvisibility=hidden` (or a hypothetical `-fclass-visibility=hidden`).


http://reviews.llvm.org/D18635



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

Re: [PATCH] D18565: Implement an "I'm dtrace, please retain all debug types" option.

2016-03-31 Thread David Blaikie via cfe-commits

On Wed, Mar 30, 2016 at 10:49 AM, Adrian Prantl  wrote:

>
> On Mar 29, 2016, at 10:06 PM, David Blaikie  wrote:
>
>
>
> On Tue, Mar 29, 2016 at 12:03 PM, Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>>
>> > On Mar 29, 2016, at 12:00 PM, Joerg Sonnenberger <
>> jo...@britannica.bec.de> wrote:
>> >
>> > On Tue, Mar 29, 2016 at 06:47:24PM +, Adrian Prantl via cfe-commits
>> wrote:
>> >> This code in this patch listens to the driver option -gfull, and
>> lowers it to the new cc1 option -debug-retain-types (1).
>> >> When -debug-retain-types is present, CGDebugInfo will retain every(2)
>> type it creates.
>> >
>> > Is there a good reason for calling it -gfull? I would find something
>> > -gall-types or -gretain-all-types to make a lot more sense. This should
>> > be orthogonal to other options like providing only line tables?
>>
>> My thinking was this:
>> The driver already supports -gfull, but it doesn’t do anything.
>> This patch can be considered a first step towards making -gfull behave as
>> expected.
>> Eventually it should emit debug info for *all* types.
>>
>
> Seems somewhat problematic to half implement it, though. (admittedly we're
> just silently ignoring it right now)
>
>
> I don’t think this is problematic at all. This is incremental development.
>

It strikes me as a strange increment. Implementing full -gfull doesn't seem
like it would take much time to implement, etc.

>
> & is 'real' -gfull what dtrace really wants? (seems it isn't - since
> clang's never really implemented it?)
>
>
> Admitted, ‘real' -gfull is probably more than it absolutely needs.
>

If just retaining referenced types is all it needs, yeah, it seems -gfull
would be rather beyond that.


>
> Emitting all types referenced by used (even if later optimized away) code
> seems like the thing? -greferenced? or maybe a -f flag? Not sure.
>
>
> I don’t see a compelling case for adding another driver option to the
> already confusing zoo of existing driver options.
>

My point is I think a -gfull that does something other than full would
possibly be more confusing than not.


> Note that we currently also accept a -gused option which according to the
> driver code is supposed to be the opposite of -gfull.
>

Are -gused/-gfull meant to toggle each other?

Huh, seems they're not general GCC flags, they're Darwin things - I didn't
know that.

Looks like GCC usually spells this -f[no-]eliminate-unused-debug-types. But
doesn't seem to have an intermediate version that would be what you're
going for.


> Adding a -greferenced option IMO will only make this more confusion
> instead of helping.
> My suggestion is to have -gfull (also) activate -debug-retain-types. In
> the somewhat hypothetical scenario that someone implements a more
> comprehensive version of -gfull we should revisit this and analyze whether
> the resulting debug information is really too large to be practical, and if
> we conclude that this is a problem, we can still decide to expose
> -debug-retain-types to the driver with a new separate option.
>

I would be concerned about breaking other existing users that may grow once
we support the flag. (& perhaps inconsistency between GCC and Clang, but
inconsistency already exists there of course)

- David


>
> -- adrian
>
>
>
>>
>> > Joerg
>> >
>> > PS: Slightly related side question, do we have any tools for extracting
>> > a given list of types for retaining? Either by name or global variable
>> > expression.
>>
>> Extract them from where? Can you give an example?
>>
>> -- adrian
>> ___
>> 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

r265083 - [CUDA] Fix typo in __clang_cuda_runtime_wrapper.h.

2016-03-31 Thread Justin Lebar via cfe-commits

Author: jlebar
Date: Thu Mar 31 19:25:42 2016
New Revision: 265083

URL: http://llvm.org/viewvc/llvm-project?rev=265083=rev
Log:
[CUDA] Fix typo in __clang_cuda_runtime_wrapper.h.

We're #including the wrong file!

Modified:
cfe/trunk/lib/Headers/__clang_cuda_runtime_wrapper.h

Modified: cfe/trunk/lib/Headers/__clang_cuda_runtime_wrapper.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/__clang_cuda_runtime_wrapper.h?rev=265083=265082=265083=diff
==
--- cfe/trunk/lib/Headers/__clang_cuda_runtime_wrapper.h (original)
+++ cfe/trunk/lib/Headers/__clang_cuda_runtime_wrapper.h Thu Mar 31 19:25:42 
2016
@@ -43,7 +43,7 @@
 #if defined(__CUDA__) && defined(__clang__)
 
 // Include some forward declares that must come before cmath.
-#include <__clang_cuda_runtime_wrapper.h>
+#include <__clang_cuda_math_forward_declares.h>
 
 // Include some standard headers to avoid CUDA headers including them
 // while some required macros (like __THROW) are in a weird state.


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

Re: [PATCH] D18635: Rework interface for bitset-using features to use a notion of class scope.

2016-03-31 Thread Peter Collingbourne via cfe-commits

pcc added inline comments.

Comment at: docs/ClassScope.rst:2
@@ +1,3 @@
+===
+Class Scope
+===

rsmith wrote:
> pcc wrote:
> > rsmith wrote:
> > > Can you use some word other than "scope" here? "Class scope" is already a 
> > > term of art in C++, meaning something completely different. I think what 
> > > you're referring to is exactly the visibility of the class (in the ELF 
> > > sense).
> > Yes, this is pretty much visibility. I wanted to avoid using the term 
> > "visibility" because I'm introducing flags and attributes which can make 
> > scope mean something different to object file visibility, so I wanted to 
> > avoid the overload to avoid confusion.
> > 
> > Maybe the overloading would help with understanding though if I add a 
> > qualifying adjective. This is all about whether all derived classes are 
> > visible, so maybe the right term is something like "derived visibility"?
> We already have attributes that can set the visibility of a class (which in 
> turn affects the visibility of the vtable etc.) In what way is that different 
> from what you're proposing? Is this a valuable difference, given the 
> complexity of having two similar-but-different ways of describing the 
> cross-DSO visibility of a class?
Yes, ideally I'd like to just use visibility for this. There were a couple of 
things that motivated a design that separated the concepts, though:

1. The part of the executable or DSO that we're LTOing may be a subset of the 
whole executable or DSO. If the user has prebuilt object files that they need 
to link into their executable or DSO, we need to exclude those classes from our 
analysis. One example of this would be the standard library. On most platforms 
this is marked up with default visibility attributes, so we're fine, but on 
Windows the platform ships an un-marked up standard library as a static 
library, and allows users to link to it. The idea is that Windows users who use 
the static standard library would be able to say
```
namespace [[clang::global_scope]] std {}
```
in a `-include`d header and get global scope on the standard library.

2. I wanted `-fsanitize=cfi*` to turn on CFI checks on classes by default. It 
would be surprising to users if that flag on its own did not enable CFI on 
classes declared in the normal way, and it could easily lead to users shipping 
unprotected binaries. I suppose an alternative thing we could do would be to 
make `-fsanitize=cfi*` imply `-fvisibility=hidden`. Then if things break, they 
would at least be likely to break loudly.

http://reviews.llvm.org/D18635

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

r265078 - Adapt to LLVM API change in r265077.

2016-03-31 Thread Adrian Prantl via cfe-commits

Author: adrian
Date: Thu Mar 31 18:57:45 2016
New Revision: 265078

URL: http://llvm.org/viewvc/llvm-project?rev=265078=rev
Log:
Adapt to LLVM API change in r265077.
EmissionKind moved from DIBuilder to DICompileUnit.




Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/test/CodeGenCXX/debug-info-namespace.cpp

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=265078=265077=265078=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Thu Mar 31 18:57:45 2016
@@ -403,8 +403,8 @@ void CGDebugInfo::CreateCompileUnit() {
   Producer, LO.Optimize, CGM.getCodeGenOpts().DwarfDebugFlags, RuntimeVers,
   CGM.getCodeGenOpts().SplitDwarfFile,
   DebugKind <= codegenoptions::DebugLineTablesOnly
-  ? llvm::DIBuilder::LineTablesOnly
-  : llvm::DIBuilder::FullDebug,
+  ? llvm::DICompileUnit::LineTablesOnly
+  : llvm::DICompileUnit::FullDebug,
   0 /* DWOid */, DebugKind != codegenoptions::LocTrackingOnly);
 }
 
@@ -1746,7 +1746,7 @@ CGDebugInfo::getOrCreateModuleRef(Extern
 DIB.createCompileUnit(TheCU->getSourceLanguage(), Mod.getModuleName(),
   Mod.getPath(), TheCU->getProducer(), true,
   StringRef(), 0, Mod.getASTFile(),
-  llvm::DIBuilder::FullDebug, Signature);
+  llvm::DICompileUnit::FullDebug, Signature);
 DIB.finalize();
   }
   llvm::DIModule *Parent =

Modified: cfe/trunk/test/CodeGenCXX/debug-info-namespace.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-namespace.cpp?rev=265078=265077=265078=diff
==
--- cfe/trunk/test/CodeGenCXX/debug-info-namespace.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/debug-info-namespace.cpp Thu Mar 31 18:57:45 2016
@@ -103,7 +103,7 @@ void B::func_fwd() {}
 // CHECK: [[M17]] = !DIImportedEntity(tag: DW_TAG_imported_declaration, scope: 
[[CTXT]], entity: [[I]]
 
 // CHECK-GMLT: [[CU:![0-9]+]] = distinct !DICompileUnit(
-// CHECK-GMLT-SAME:emissionKind: 2,
+// CHECK-GMLT-SAME:emissionKind: LineTablesOnly,
 // CHECK-GMLT-NOT: imports:
 
 // CHECK-NOLIMIT: !DICompositeType(tag: DW_TAG_structure_type, name: 
"bar",{{.*}} line: 6,


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

Re: [PATCH] D18635: Rework interface for bitset-using features to use a notion of class scope.

2016-03-31 Thread Richard Smith via cfe-commits

rsmith added inline comments.


Comment at: docs/ClassScope.rst:2
@@ +1,3 @@
+===
+Class Scope
+===

pcc wrote:
> rsmith wrote:
> > Can you use some word other than "scope" here? "Class scope" is already a 
> > term of art in C++, meaning something completely different. I think what 
> > you're referring to is exactly the visibility of the class (in the ELF 
> > sense).
> Yes, this is pretty much visibility. I wanted to avoid using the term 
> "visibility" because I'm introducing flags and attributes which can make 
> scope mean something different to object file visibility, so I wanted to 
> avoid the overload to avoid confusion.
> 
> Maybe the overloading would help with understanding though if I add a 
> qualifying adjective. This is all about whether all derived classes are 
> visible, so maybe the right term is something like "derived visibility"?
We already have attributes that can set the visibility of a class (which in 
turn affects the visibility of the vtable etc.) In what way is that different 
from what you're proposing? Is this a valuable difference, given the complexity 
of having two similar-but-different ways of describing the cross-DSO visibility 
of a class?


http://reviews.llvm.org/D18635



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

Re: [PATCH] D18671: [CUDA] Add --cuda-flush-denormals-to-zero.

2016-03-31 Thread Justin Lebar via cfe-commits

jlebar added a comment.

Thank you for explaining that, Reid!


http://reviews.llvm.org/D18671



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

Re: [PATCH] D18671: [CUDA] Add --cuda-flush-denormals-to-zero.

2016-03-31 Thread Justin Lebar via cfe-commits

jlebar added inline comments.


Comment at: lib/Frontend/CompilerInvocation.cpp:1567
@@ +1566,3 @@
+  if (Opts.CUDAIsDevice && Args.hasArg(OPT_fcuda_flush_denormals_to_zero))
+Opts.CUDADeviceFlushDenormalsToZero = 1;
+

Aha, I knew there had to be a better way to do that.  Thanks.


http://reviews.llvm.org/D18671



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

Re: [PATCH] D18671: [CUDA] Add --cuda-flush-denormals-to-zero.

2016-03-31 Thread Justin Lebar via cfe-commits

jlebar updated this revision to Diff 52310.
jlebar marked an inline comment as done.
jlebar added a comment.

Update flags so we only pass -fcuda-flush-denormals-to-zero to cc1 if 
appropriate.


http://reviews.llvm.org/D18671

Files:
  include/clang/Basic/LangOptions.def
  include/clang/Driver/Options.td
  lib/CodeGen/CGCall.cpp
  lib/CodeGen/CodeGenModule.cpp
  lib/Driver/ToolChains.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/CodeGenCUDA/flush-denormals.cu

Index: test/CodeGenCUDA/flush-denormals.cu
===
--- /dev/null
+++ test/CodeGenCUDA/flush-denormals.cu
@@ -0,0 +1,23 @@
+// RUN: %clang_cc1 -fcuda-is-device \
+// RUN:   -triple nvptx-nvidia-cuda -emit-llvm -o - %s | FileCheck %s -check-prefix NOFTZ
+// RUN: %clang_cc1 -fcuda-is-device -fcuda-flush-denormals-to-zero \
+// RUN:   -triple nvptx-nvidia-cuda -emit-llvm -o - %s | FileCheck %s -check-prefix FTZ
+
+#include "Inputs/cuda.h"
+
+// Checks that device function calls get emitted with the "ntpvx-f32ftz"
+// attribute set to "true" when we compile CUDA device code with
+// -fcuda-flush-denormals-to-zero.  Further, check that we reflect the presence
+// or absence of -fcuda-flush-denormals-to-zero in a module flag.
+
+// CHECK: define void @foo() #0
+extern "C" __device__ void foo() {}
+
+// FTZ: attributes #0 = {{.*}} "nvptx-f32ftz"="true"
+// NOFTZ-NOT: attributes #0 = {{.*}} "nvptx-f32ftz"
+
+// FTZ:!llvm.module.flags = !{[[MODFLAG:![0-9]+]]}
+// FTZ:[[MODFLAG]] = !{i32 4, !"nvvm-reflect-ftz", i32 1}
+
+// NOFTZ:!llvm.module.flags = !{[[MODFLAG:![0-9]+]]}
+// NOFTZ:[[MODFLAG]] = !{i32 4, !"nvvm-reflect-ftz", i32 0}
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -1563,6 +1563,9 @@
   if (Args.hasArg(OPT_fno_cuda_host_device_constexpr))
 Opts.CUDAHostDeviceConstexpr = 0;
 
+  if (Opts.CUDAIsDevice && Args.hasArg(OPT_fcuda_flush_denormals_to_zero))
+Opts.CUDADeviceFlushDenormalsToZero = 1;
+
   if (Opts.ObjC1) {
 if (Arg *arg = Args.getLastArg(OPT_fobjc_runtime_EQ)) {
   StringRef value = arg->getValue();
Index: lib/Driver/ToolChains.cpp
===
--- lib/Driver/ToolChains.cpp
+++ lib/Driver/ToolChains.cpp
@@ -4208,6 +4208,10 @@
   Linux::addClangTargetOptions(DriverArgs, CC1Args);
   CC1Args.push_back("-fcuda-is-device");
 
+  if (DriverArgs.hasFlag(options::OPT_fcuda_flush_denormals_to_zero,
+ options::OPT_fno_cuda_flush_denormals_to_zero, false))
+CC1Args.push_back("-fcuda-flush-denormals-to-zero");
+
   if (DriverArgs.hasArg(options::OPT_nocudalib))
 return;
 
Index: lib/CodeGen/CodeGenModule.cpp
===
--- lib/CodeGen/CodeGenModule.cpp
+++ lib/CodeGen/CodeGenModule.cpp
@@ -472,6 +472,14 @@
 getModule().addModuleFlag(llvm::Module::Override, "Cross-DSO CFI", 1);
   }
 
+  if (LangOpts.CUDAIsDevice && getTarget().getTriple().isNVPTX()) {
+// Indicate whether __nvvm_reflect should be configured to flush denormal
+// floating point values to 0.  (This corresponds to its "__CUDA_FTZ"
+// property.)
+getModule().addModuleFlag(llvm::Module::Override, "nvvm-reflect-ftz",
+  LangOpts.CUDADeviceFlushDenormalsToZero ? 1 : 0);
+  }
+
   if (uint32_t PLevel = Context.getLangOpts().PICLevel) {
 llvm::PICLevel::Level PL = llvm::PICLevel::Default;
 switch (PLevel) {
Index: lib/CodeGen/CGCall.cpp
===
--- lib/CodeGen/CGCall.cpp
+++ lib/CodeGen/CGCall.cpp
@@ -1763,6 +1763,10 @@
 // __syncthreads(), and so can't have certain optimizations applied around
 // them).  LLVM will remove this attribute where it safely can.
 FuncAttrs.addAttribute(llvm::Attribute::Convergent);
+
+// Respect -fcuda-flush-denormals-to-zero.
+if (getLangOpts().CUDADeviceFlushDenormalsToZero)
+  FuncAttrs.addAttribute("nvptx-f32ftz", "true");
   }
 
   ClangToLLVMArgMapping IRFunctionArgs(getContext(), FI);
Index: include/clang/Driver/Options.td
===
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -382,6 +382,9 @@
   HelpText<"Enable device-side debug info generation. Disables ptxas optimizations.">;
 def cuda_path_EQ : Joined<["--"], "cuda-path=">, Group,
   HelpText<"CUDA installation path">;
+def fcuda_flush_denormals_to_zero : Flag<["-"], "fcuda-flush-denormals-to-zero">,
+  Flags<[CC1Option]>, HelpText<"Flush denormal floating point values to zero in CUDA device mode.">;
+def fno_cuda_flush_denormals_to_zero : Flag<["-"], "fno-cuda-flush-denormals-to-zero">;
 def dA : Flag<["-"], "dA">, Group;
 def dD : Flag<["-"], "dD">, Group, Flags<[CC1Option]>,
   HelpText<"Print macro

Re: [PATCH] D18635: Rework interface for bitset-using features to use a notion of class scope.

2016-03-31 Thread Peter Collingbourne via cfe-commits

pcc added inline comments.


Comment at: docs/ControlFlowIntegrity.rst:271
@@ +270,3 @@
+linkage-unit scope. With this flag enabled, the compiler will emit cross-DSO
+CFI checks for all classes, except for those which appear in the CFI blacklist
+or which use a ``no_sanitize`` attribute.

eugenis wrote:
> Do we emit a fast non-cross-DSO check for classes with linkage-unit scope?
We do not. I reckon we can start doing that in a follow up, this change is 
large enough as it is.


http://reviews.llvm.org/D18635



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

Re: [PATCH] D18635: Rework interface for bitset-using features to use a notion of class scope.

2016-03-31 Thread Peter Collingbourne via cfe-commits

pcc added inline comments.


Comment at: docs/ClassScope.rst:2
@@ +1,3 @@
+===
+Class Scope
+===

rsmith wrote:
> Can you use some word other than "scope" here? "Class scope" is already a 
> term of art in C++, meaning something completely different. I think what 
> you're referring to is exactly the visibility of the class (in the ELF sense).
Yes, this is pretty much visibility. I wanted to avoid using the term 
"visibility" because I'm introducing flags and attributes which can make scope 
mean something different to object file visibility, so I wanted to avoid the 
overload to avoid confusion.

Maybe the overloading would help with understanding though if I add a 
qualifying adjective. This is all about whether all derived classes are 
visible, so maybe the right term is something like "derived visibility"?


Comment at: docs/ClassScope.rst:13
@@ +12,3 @@
+to a single linkage unit (i.e. the executable or DSO). It is effectively an
+ODR violation to declare classes with linkage-unit scope in multiple linkage
+units.  Classes with global scope may be defined in multiple linkage units,

rsmith wrote:
> classes -> a class
> 
> Otherwise this reads like you're saying at most one linkage unit per program 
> can declare classes with linkage-unit scope.
Will do


Comment at: docs/ClassScope.rst:14
@@ +13,3 @@
+ODR violation to declare classes with linkage-unit scope in multiple linkage
+units.  Classes with global scope may be defined in multiple linkage units,
+but the tradeoff is that the virtual function call optimization and control

rsmith wrote:
> Classes -> A class
Will do


Comment at: docs/ClassScope.rst:23
@@ +22,3 @@
+
+  -  ``-fdefault-class-scope=attrs`` indicates that the compiler will infer
+ class scope based on platform-specific attributes that control the class's

eugenis wrote:
> Maybe call it "default"? Attrs sounds too specific. Basically this setting 
> lets clang figure out scope based on the source code.
`-fdefault-class-scope=default`? Sounds a little stuttery. Although `attrs` 
isn't entirely accurate (it's also affected by flags), it's close enough I 
reckon.


Comment at: docs/ClassScope.rst:28
@@ +27,3 @@
+ or the ``-fvisibility=hidden -fvisibility-inlines-hidden`` flags)
+ receive global scope, and all others receive linkage-unit scope. When
+ targeting Windows, classes with the ``__declspec(dllexport)`` or

eugenis wrote:
> hidden visibility = linkage-unit scope, not global scope.
Yes, I somehow completely screwed up the sense of these, even in the Windows 
part. Will fix.


http://reviews.llvm.org/D18635



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

Re: [PATCH] D18567: Block: Fix a crash when we have type attributes or qualifiers with omitted return type.

2016-03-31 Thread Manman Ren via cfe-commits

manmanren added a comment.

Thanks for reviewing!

I will update the patch addressing the comments soon!

Manman



Comment at: lib/Sema/SemaType.cpp:1569
@@ +1568,3 @@
+// Mark them as invalid.
+attr.setInvalid();
+  }

rsmith wrote:
> rjmccall wrote:
> > manmanren wrote:
> > > rjmccall wrote:
> > > > It's not generally a good idea to set things as invalid if you're just 
> > > > emitting a warning.  It might be different for parsed AttributeList 
> > > > objects, but... I'm not sure about that.
> > > Here we mark the AttributeList as invalid so when we call 
> > > processTypeAttrs later, we will ignore these attributes, instead of 
> > > creating AttributedType based on DependentTy for omitted block return 
> > > type.
> > I'm just worried that there might be code which suppresses *error* 
> > diagnostics (or semantic analysis) when it sees an invalid attribute.  Like 
> > I said, though, that might not be a problem for AttributeList.
> Even if it didn't cause problems today, it's very likely to cause confusion 
> and problems down the line. We should not have two different meanings for 
> "invalid" for different kinds of AST nodes. Manman, can you remove the 
> attribute(s) in question from the attribute list instead?
John and Richard,

I got your point now. I didn't think about removing it from the attribute list 
before.

I looked at the interface for AttributeList, there is no interface for removing 
an item from the list, it has a setNext function.
But I found a helper function called spliceAttrOutOfList, I will try to use it.




http://reviews.llvm.org/D18567



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

[clang-tools-extra] r265072 - Update release notes with list of checks added since 3.8.

2016-03-31 Thread Eugene Zelenko via cfe-commits

Author: eugenezelenko
Date: Thu Mar 31 18:09:42 2016
New Revision: 265072

URL: http://llvm.org/viewvc/llvm-project?rev=265072=rev
Log:
Update release notes with list of checks added since 3.8.

Fix some checks documentation style.

Differential revision: http://reviews.llvm.org/D18582

Modified:
clang-tools-extra/trunk/docs/ReleaseNotes.rst
clang-tools-extra/trunk/docs/clang-tidy/checks/misc-dangling-handle.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/performance-faster-string-find.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/performance-implicit-cast-in-loop.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/readability-redundant-control-flow.rst

Modified: clang-tools-extra/trunk/docs/ReleaseNotes.rst
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/docs/ReleaseNotes.rst?rev=265072=265071=265072=diff
==
--- clang-tools-extra/trunk/docs/ReleaseNotes.rst (original)
+++ clang-tools-extra/trunk/docs/ReleaseNotes.rst Thu Mar 31 18:09:42 2016
@@ -63,14 +63,101 @@ Improvements to clang-tidy
 explain them more clearly, and provide more accurate fix-its for the issues
 identified.  The improvements since the 3.8 release include:
 
-- New ``modernize-raw-string-literal`` check
+- New `cert-env33-c
+  `_ check
 
-  selectively replaces string literals containing escaped characters with raw
+  Flags calls to ``system()``, ``popen()``, and ``_popen()``, which execute a
+  command processor.
+
+- New `cert-flp30-c
+  `_ check
+
+  Flags ``for`` loops where the induction expression has a floating-point type.
+
+- New `cppcoreguidelines-pro-type-member-init
+  
`_
 check
+
+  Flags user-defined constructor definitions that do not initialize all builtin
+  and pointer fields which leaves their memory in an undefined state.
+
+- New `misc-dangling-handle
+  `_ 
check
+
+  Detects dangling references in value handlers like
+  ``std::experimental::string_view``.
+
+- New `misc-forward-declaration-namespace
+  
`_
 check
+
+  Checks if an unused forward declaration is in a wrong namespace.
+
+- New `misc-misplaced-widening-cast
+  
`_
 check
+
+  Warns when there is a explicit redundant cast of a calculation result to a
+  bigger type.
+
+- New `misc-suspicious-missing-comma
+  
`_
 check
+
+  Warns about 'probably' missing comma in string literals initializer list.
+
+- New `misc-suspicious-semicolon
+  
`_
 check
+
+  Finds most instances of stray semicolons that unexpectedly alter the meaning
+  of the code.
+
+- New `modernize-deprecated-headers
+  
`_
 check
+
+  Replaces C standard library headers with their C++ alternatives.
+
+- New `modernize-raw-string-literal
+  
`_
 check
+
+  Selectively replaces string literals containing escaped characters with raw
   string literals.
 
-- New ``readability-avoid-const-params-in-decls`` check
+- New `performance-faster-string-find
+  
`_
 check
+
+  Optimize calls to ``std::string::find()`` and friends when the needle passed
+  is a single character string literal.
+
+- New `performance-implicit-cast-in-loop
+  
`_
 check
+
+  Warns about range-based loop with a loop variable of const ref type where the
+  type of the variable does not match the one returned by the iterator.
+
+- New `performance-unnecessary-value-param
+  
`_
 check
+
+  Flags value parameter declarations of expensive to copy types that are copied
+  for each invocation but it would suffice to pass them by const reference.
+
+- New `readability-avoid-const-params-in-decls
+  
`_
 check
+
+  Warns about top-level const parameters in function declarations.
+
+- New `readability-redundant-control-flow
+  
`_
 check
+
+  Looks for procedures (functions returning no value) with ``return``

Re: [PATCH] D18509: clang-tidy: add_new_check.py stubs out release notes

2016-03-31 Thread Alexander Kornienko via cfe-commits

alexfh added a comment.

In http://reviews.llvm.org/D18509#388071, @hintonda wrote:

> With this change, won't you need to update 2 different repos: clang and 
> extra?  Is it possible to update both with a single Phabricator patch?

Clang-tidy release notes are now in the clang-tools-extra repository.

http://reviews.llvm.org/D18509

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

Re: [PATCH] D18509: clang-tidy: add_new_check.py stubs out release notes

2016-03-31 Thread Eugene Zelenko via cfe-commits

Eugene.Zelenko added a subscriber: Eugene.Zelenko.
Eugene.Zelenko added a comment.

Please use single ` around check name and also add link. See 
http://reviews.llvm.org/D18582 as example.


http://reviews.llvm.org/D18509



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

Re: [PATCH] D18582: [Clang-tidy] Update release notes with list of checks added since 3.8

2016-03-31 Thread Alexander Kornienko via cfe-commits

alexfh added a comment.

Good to submit now. Thank you for working on this!


Repository:
  rL LLVM

http://reviews.llvm.org/D18582



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

Re: [PATCH] D18582: [Clang-tidy] Update release notes with list of checks added since 3.8

2016-03-31 Thread Eugene Zelenko via cfe-commits

Eugene.Zelenko added a comment.

I fixed indentation.

Should I commit changes?


Repository:
  rL LLVM

http://reviews.llvm.org/D18582



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

Re: [PATCH] D18582: [Clang-tidy] Update release notes with list of checks added since 3.8

2016-03-31 Thread Alexander Kornienko via cfe-commits

alexfh added a comment.

In http://reviews.llvm.org/D18582#388931, @Eugene.Zelenko wrote:

> I align them as in 3.8 changes, to first `. If you think that alignment 
> should be other way, I'll change it.

This observation doesn't capture the intent correctly. They are aligned with 
the first column after the "- ", which in some cases happens to contain the 
first backquote.

Repository:
  rL LLVM

http://reviews.llvm.org/D18582

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

Re: [PATCH] D18582: [Clang-tidy] Update release notes with list of checks added since 3.8

2016-03-31 Thread Eugene Zelenko via cfe-commits

Eugene.Zelenko updated this revision to Diff 52306.
Eugene.Zelenko added a comment.

Updated to trunk. Changed per Alexander comments.


Repository:
  rL LLVM

http://reviews.llvm.org/D18582

Files:
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/misc-dangling-handle.rst
  docs/clang-tidy/checks/performance-faster-string-find.rst
  docs/clang-tidy/checks/performance-implicit-cast-in-loop.rst
  docs/clang-tidy/checks/readability-redundant-control-flow.rst

Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -63,15 +63,102 @@
 explain them more clearly, and provide more accurate fix-its for the issues
 identified.  The improvements since the 3.8 release include:
 
-- New ``modernize-raw-string-literal`` check
+- New `cert-env33-c
+  `_ check
 
-  selectively replaces string literals containing escaped characters with raw
+  Flags calls to ``system()``, ``popen()``, and ``_popen()``, which execute a
+  command processor.
+
+- New `cert-flp30-c
+  `_ check
+
+  Flags ``for`` loops where the induction expression has a floating-point type.
+
+- New `cppcoreguidelines-pro-type-member-init
+  `_ check
+
+  Flags user-defined constructor definitions that do not initialize all builtin
+  and pointer fields which leaves their memory in an undefined state.
+
+- New `misc-dangling-handle
+  `_ check
+
+  Detects dangling references in value handlers like
+  ``std::experimental::string_view``.
+
+- New `misc-forward-declaration-namespace
+  `_ check
+
+  Checks if an unused forward declaration is in a wrong namespace.
+
+- New `misc-misplaced-widening-cast
+  `_ check
+
+  Warns when there is a explicit redundant cast of a calculation result to a
+  bigger type.
+
+- New `misc-suspicious-missing-comma
+  `_ check
+
+  Warns about 'probably' missing comma in string literals initializer list.
+
+- New `misc-suspicious-semicolon
+  `_ check
+
+  Finds most instances of stray semicolons that unexpectedly alter the meaning
+  of the code.
+
+- New `modernize-deprecated-headers
+  `_ check
+
+  Replaces C standard library headers with their C++ alternatives.
+
+- New `modernize-raw-string-literal
+  `_ check
+
+  Selectively replaces string literals containing escaped characters with raw
   string literals.
 
-- New ``readability-avoid-const-params-in-decls`` check
+- New `performance-faster-string-find
+  `_ check
 
-  warns about top-level const parameters in function declarations.
+  Optimize calls to ``std::string::find()`` and friends when the needle passed
+  is a single character string literal.
 
+- New `performance-implicit-cast-in-loop
+  `_ check
+
+  Warns about range-based loop with a loop variable of const ref type where the
+  type of the variable does not match the one returned by the iterator.
+
+- New `performance-unnecessary-value-param
+  `_ check
+
+  Flags value parameter declarations of expensive to copy types that are copied
+  for each invocation but it would suffice to pass them by const reference.
+
+- New `readability-avoid-const-params-in-decls
+  `_ check
+
+  Warns about top-level const parameters in function declarations.
+
+- New `readability-redundant-control-flow
+  `_ check
+
+  Looks for procedures (functions returning no value) with ``return`` statements
+  at the end of the function.  Such `return` statements are redundant.
+
+- New `readability-redundant-string-init
+  `_ check
+
+  Finds unnecessary string initializations.
+
+Fixed bugs:
+
+  Crash when running on compile database with relative source files paths.
+
+  Crash when running with the `-fdelayed-template-parsing` flag.
+
 Clang-tidy changes

Re: [PATCH] D18396: Clang-tidy:modernize-use-override. Fix for __declspec attributes and const=0 without spacse

2016-03-31 Thread Alexander Kornienko via cfe-commits

alexfh added a comment.

In http://reviews.llvm.org/D18396#388287, @Rob wrote:

> I tried
>
>   check_clang_tidy.py modernize-use-override-ms.cpp modernize-use-override 
> temp -- -- -fms-extensions

It also needs -std=c++11, since you specify options manually and "opt out" of 
the defaults (which are currently -std=c++11).

> and

> 

>   check_clang_tidy.py modernize-use-override-ms.cpp modernize-use-override 
> temp 

> 

> on OSX and nethier work as expected.

> 

> So instead I have changed the test to use visibility attributes when _MSC_VER 
> is not defined.

... which means that the code is not tested on non-windows platforms, though it 
could be.

> Also updated the release notes.

Thanks!

Comment at: docs/ReleaseNotes.rst:73
@@ +72,3 @@
+
+  The fix-its placement around __declspec attributes on windows and other 
+  attributes is improved.

nit: Please enclose `__declspec` in double backquotes.

http://reviews.llvm.org/D18396

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

Re: [PATCH] D18396: Clang-tidy:modernize-use-override. Fix for __declspec attributes and const=0 without spacse

2016-03-31 Thread Alexander Kornienko via cfe-commits

alexfh added a comment.

In http://reviews.llvm.org/D18396#388287, @Rob wrote:

> I tried
>
>   check_clang_tidy.py modernize-use-override-ms.cpp modernize-use-override 
> temp -- -- -fms-extensions


It also needs -std=c++11, which needs to be specified, when you specify any 
options manually.

> and

> 

>   check_clang_tidy.py modernize-use-override-ms.cpp modernize-use-override 
> temp 

> 

> on OSX and nethier work as expected.

> 

> So instead I have changed the test to use visibility attributes when _MSC_VER 
> is not defined.


... which means that the code is not tested on non-windows platforms, though it 
could be.

> Also updated the release notes.


Thanks!



Comment at: test/clang-tidy/modernize-use-override-ms.cpp:1
@@ +1,2 @@
+// RUN: %check_clang_tidy %s modernize-use-override %t
+

aaron.ballman wrote:
> I *think* this run line may require -fms-extensions in order to compile under 
> non-MSVC-built versions of clang because of the __declspec.
I've just tried this on Linux and it actually needs `-fms-extensions` 
(actually, you'll need to append `-- -- -std=c++11 -fms-extensions`).


http://reviews.llvm.org/D18396



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

Re: [PATCH] D18582: [Clang-tidy] Update release notes with list of checks added since 3.8

2016-03-31 Thread Eugene Zelenko via cfe-commits

Eugene.Zelenko added a comment.

I align them as in 3.8 changes, to first `. If you think that alignment should 
be other way, I'll change it.


Repository:
  rL LLVM

http://reviews.llvm.org/D18582



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

Re: [PATCH] D18582: [Clang-tidy] Update release notes with list of checks added since 3.8

2016-03-31 Thread Alexander Kornienko via cfe-commits

alexfh added a comment.

One more nit.



Comment at: docs/clang-tidy/checks/performance-implicit-cast-in-loop.rst:4
@@ -3,3 +3,3 @@
 
-This warning appears in range-based loop with loop variable of const ref type
+This warning appears in range-based loop with a loop variable of const ref type
 where the type of the variable does not match the one returned by the iterator.

nit: 'range-based loops' or 'a range-based loop'.


Repository:
  rL LLVM

http://reviews.llvm.org/D18582



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

Re: [PATCH] D18671: [CUDA] Add --cuda-flush-denormals-to-zero.

2016-03-31 Thread Reid Kleckner via cfe-commits

rnk requested changes to this revision.
This revision now requires changes to proceed.


Comment at: include/clang/Driver/Options.td:385
@@ -384,1 +384,3 @@
   HelpText<"CUDA installation path">;
+def fcuda_flush_denormals_to_zero : Flag<["-"], 
"fcuda-flush-denormals-to-zero">,
+  Group, Flags<[CC1Option]>,

I agree it would be simpler, but it's not what we do elsewhere. There's this 
idea that the -cc1 line is a canonicalized command line, where no-op options 
are removed, like -fno-exceptions when EH is off by default.


Comment at: lib/Frontend/CompilerInvocation.cpp:1567
@@ +1566,3 @@
+  if (Opts.CUDAIsDevice)
+if (Arg *A = Args.getLastArg(OPT_fcuda_flush_denormals_to_zero,
+ OPT_fno_cuda_flush_denormals_to_zero))

The right idiom for this is:
  Opts.Thing = Args.hasFlag(OPT_fthing, OPT_fno_thing, false);


http://reviews.llvm.org/D18671



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

Re: [PATCH] D18582: [Clang-tidy] Update release notes with list of checks added since 3.8

2016-03-31 Thread Alexander Kornienko via cfe-commits

alexfh added inline comments.


Comment at: docs/ReleaseNotes.rst:67
@@ -67,1 +66,3 @@
+- New `cert-env33-c
+  `_ check
 

Should these lines be indented to `New ...` (i.e. with just two spaces)?


Repository:
  rL LLVM

http://reviews.llvm.org/D18582



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

Re: [PATCH] D18671: [CUDA] Add --cuda-flush-denormals-to-zero.

2016-03-31 Thread Justin Lebar via cfe-commits

jlebar updated this revision to Diff 52302.
jlebar marked an inline comment as done.
jlebar added a comment.

Add -fno variant.


http://reviews.llvm.org/D18671

Files:
  include/clang/Basic/LangOptions.def
  include/clang/Driver/Options.td
  lib/CodeGen/CGCall.cpp
  lib/CodeGen/CodeGenModule.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/CodeGenCUDA/flush-denormals.cu

Index: test/CodeGenCUDA/flush-denormals.cu
===
--- /dev/null
+++ test/CodeGenCUDA/flush-denormals.cu
@@ -0,0 +1,32 @@
+// RUN: %clang_cc1 -fcuda-is-device \
+// RUN:   -triple nvptx-nvidia-cuda -emit-llvm -o - %s | FileCheck %s -check-prefix NOFTZ
+// RUN: %clang_cc1 -fcuda-is-device -fno-cuda-flush-denormals-to-zero \
+// RUN:   -triple nvptx-nvidia-cuda -emit-llvm -o - %s | FileCheck %s -check-prefix NOFTZ
+// RUN: %clang_cc1 -fcuda-is-device -fcuda-flush-denormals-to-zero \
+// RUN:   -fno-cuda-flush-denormals-to-zero -triple nvptx-nvidia-cuda \
+// RUN:   -emit-llvm -o - %s | FileCheck %s -check-prefix NOFTZ
+
+// RUN: %clang_cc1 -fcuda-is-device -fcuda-flush-denormals-to-zero \
+// RUN:   -triple nvptx-nvidia-cuda -emit-llvm -o - %s | FileCheck %s -check-prefix FTZ
+// RUN: %clang_cc1 -fcuda-is-device -fno-cuda-flush-denormals-to-zero \
+// RUN:   -fcuda-flush-denormals-to-zero -triple nvptx-nvidia-cuda \
+// RUN:   -emit-llvm -o - %s | FileCheck %s -check-prefix FTZ
+
+#include "Inputs/cuda.h"
+
+// Checks that device function calls get emitted with the "ntpvx-f32ftz"
+// attribute set to "true" when we compile CUDA device code with
+// -fcuda-flush-denormals-to-zero.  Further, check that we reflect the presence
+// or absence of -fcuda-flush-denormals-to-zero in a module flag.
+
+// CHECK: define void @foo() #0
+extern "C" __device__ void foo() {}
+
+// FTZ: attributes #0 = {{.*}} "nvptx-f32ftz"="true"
+// NOFTZ-NOT: attributes #0 = {{.*}} "nvptx-f32ftz"
+
+// FTZ:!llvm.module.flags = !{[[MODFLAG:![0-9]+]]}
+// FTZ:[[MODFLAG]] = !{i32 4, !"nvvm-reflect-ftz", i32 1}
+
+// NOFTZ:!llvm.module.flags = !{[[MODFLAG:![0-9]+]]}
+// NOFTZ:[[MODFLAG]] = !{i32 4, !"nvvm-reflect-ftz", i32 0}
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -1563,6 +1563,12 @@
   if (Args.hasArg(OPT_fno_cuda_host_device_constexpr))
 Opts.CUDAHostDeviceConstexpr = 0;
 
+  if (Opts.CUDAIsDevice)
+if (Arg *A = Args.getLastArg(OPT_fcuda_flush_denormals_to_zero,
+ OPT_fno_cuda_flush_denormals_to_zero))
+  Opts.CUDADeviceFlushDenormalsToZero =
+  A->getOption().getID() == OPT_fcuda_flush_denormals_to_zero;
+
   if (Opts.ObjC1) {
 if (Arg *arg = Args.getLastArg(OPT_fobjc_runtime_EQ)) {
   StringRef value = arg->getValue();
Index: lib/CodeGen/CodeGenModule.cpp
===
--- lib/CodeGen/CodeGenModule.cpp
+++ lib/CodeGen/CodeGenModule.cpp
@@ -472,6 +472,14 @@
 getModule().addModuleFlag(llvm::Module::Override, "Cross-DSO CFI", 1);
   }
 
+  if (LangOpts.CUDAIsDevice && getTarget().getTriple().isNVPTX()) {
+// Indicate whether __nvvm_reflect should be configured to flush denormal
+// floating point values to 0.  (This corresponds to its "__CUDA_FTZ"
+// property.)
+getModule().addModuleFlag(llvm::Module::Override, "nvvm-reflect-ftz",
+  LangOpts.CUDADeviceFlushDenormalsToZero ? 1 : 0);
+  }
+
   if (uint32_t PLevel = Context.getLangOpts().PICLevel) {
 llvm::PICLevel::Level PL = llvm::PICLevel::Default;
 switch (PLevel) {
Index: lib/CodeGen/CGCall.cpp
===
--- lib/CodeGen/CGCall.cpp
+++ lib/CodeGen/CGCall.cpp
@@ -1763,6 +1763,10 @@
 // __syncthreads(), and so can't have certain optimizations applied around
 // them).  LLVM will remove this attribute where it safely can.
 FuncAttrs.addAttribute(llvm::Attribute::Convergent);
+
+// Respect -fcuda-flush-denormals-to-zero.
+if (getLangOpts().CUDADeviceFlushDenormalsToZero)
+  FuncAttrs.addAttribute("nvptx-f32ftz", "true");
   }
 
   ClangToLLVMArgMapping IRFunctionArgs(getContext(), FI);
Index: include/clang/Driver/Options.td
===
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -382,6 +382,11 @@
   HelpText<"Enable device-side debug info generation. Disables ptxas optimizations.">;
 def cuda_path_EQ : Joined<["--"], "cuda-path=">, Group,
   HelpText<"CUDA installation path">;
+def fcuda_flush_denormals_to_zero : Flag<["-"], "fcuda-flush-denormals-to-zero">,
+  Group, Flags<[CC1Option]>,
+  HelpText<"Flush denormal floating point values to zero in CUDA device mode.">;
+def fno_cuda_flush_denormals_to_zero : Flag<["-"], "fno-cuda-flush-denormals-to-zero">,
+  Group,

Re: [PATCH] D18671: [CUDA] Add --cuda-flush-denormals-to-zero.

2016-03-31 Thread Justin Lebar via cfe-commits

jlebar marked an inline comment as done.


Comment at: include/clang/Driver/Options.td:385
@@ -384,1 +384,3 @@
   HelpText<"CUDA installation path">;
+def fcuda_flush_denormals_to_zero : Flag<["-"], 
"fcuda-flush-denormals-to-zero">,
+  Group, Flags<[CC1Option]>,

rnk wrote:
> rnk wrote:
> > Let's stick with the long descriptive name for now.
> Personally I would add an -fno variant, and add code to the driver that 
> conditionally forwards the flag to cc1.
OK, added an -fno variant.  But it seems simpler to pass both the -f flag and 
-fno flag to cc1 and let it figure things out?  lmk what you think.


http://reviews.llvm.org/D18671



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

Re: [PATCH] D17926: [clang-tidy] Don't delete unused parameter in class override method in anonymous namespace.

2016-03-31 Thread Alexander Kornienko via cfe-commits

alexfh added inline comments.


Comment at: clang-tidy/misc/UnusedParametersCheck.cpp:80
@@ -78,2 +79,3 @@
   !Result.SourceManager->isInMainFile(Function->getLocation()) ||
-  UsedByRef()) {
+  !ast_matchers::match(DeclRefExpr, *Result.Context).empty()||
+  isOverrideMethod(Function)) {

nit: Please update formatting.


http://reviews.llvm.org/D17926



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

Re: [PATCH] D17926: [clang-tidy] Don't delete unused parameter in class override method in anonymous namespace.

2016-03-31 Thread Alexander Kornienko via cfe-commits

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

LG. Thank you!


http://reviews.llvm.org/D17926



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

Re: [PATCH] D17933: Set MaxAtomicInlineWidth properly for i386, i486, and x86-64 cpus without cmpxchg16b.

2016-03-31 Thread Richard Smith via cfe-commits

rsmith added a subscriber: rsmith.


Comment at: lib/Basic/Targets.cpp:4080
@@ -4079,1 +4079,3 @@
+// x86-64 has atomics up to 16 bytes, when the HasCX16 target
+// feature is enabled, 64 otherwise.
 MaxAtomicPromoteWidth = 128;

... where by 64, you mean 8, right? :)


Comment at: test/CodeGen/atomic-ops.c:1
@@ -1,2 +1,2 @@
-// RUN: %clang_cc1 %s -emit-llvm -o - -ffreestanding -ffake-address-space-map 
-triple=i686-apple-darwin9 | FileCheck %s
+// RUN: %clang_cc1 %s -emit-llvm -o - -ffreestanding -ffake-address-space-map 
-triple=i686-apple-darwin9 -target-cpu i686 | FileCheck %s
 // REQUIRES: x86-registered-target

Why do you need a -target-cpu i686 in addition to the i686 triple?


Comment at: test/Preprocessor/arm-target-features.c:108-118
@@ -107,2 +107,13 @@
 // V8M_BASELINE-NOT: __ARM_FP 0x{{.*}}
-// V8M_BASELINE-NOT: __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1
+// V8M_BASELINE: #define __GCC_ATOMIC_BOOL_LOCK_FREE 2
+// V8M_BASELINE: #define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 2
+// V8M_BASELINE: #define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2
+// V8M_BASELINE: #define __GCC_ATOMIC_CHAR_LOCK_FREE 2
+// V8M_BASELINE: #define __GCC_ATOMIC_INT_LOCK_FREE 2
+// V8M_BASELINE: #define __GCC_ATOMIC_LLONG_LOCK_FREE 1
+// V8M_BASELINE: #define __GCC_ATOMIC_LONG_LOCK_FREE 2
+// V8M_BASELINE: #define __GCC_ATOMIC_POINTER_LOCK_FREE 2
+// V8M_BASELINE: #define __GCC_ATOMIC_SHORT_LOCK_FREE 2
+// V8M_BASELINE: #define __GCC_ATOMIC_TEST_AND_SET_TRUEVAL 1
+// V8M_BASELINE: #define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2
+// V8M_BASELINE: __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1

Maybe drop the #define on these lines for consistency with the surrounding 
tests?


Comment at: test/Preprocessor/init.c:3295
@@ -3292,1 +3294,3 @@
+// MIPSN32BE: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
+// MIPSN32BE: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1
 // MIPSN32BE: #define __GNUC_MINOR__ 2

Can you add a `MIPSN32BE-NOT: ` for the 16 byte form? Likewise for the below 
cases.


http://reviews.llvm.org/D17933



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

Re: [PATCH] D18582: [Clang-tidy] Update release notes with list of checks added since 3.8

2016-03-31 Thread Alexander Kornienko via cfe-commits

alexfh added inline comments.


Comment at: docs/clang-tidy/checks/performance-implicit-cast-in-loop.rst:4
@@ -3,3 +3,3 @@
 
-This warning appears in range-based loop with loop variable of const ref type
+This warning appears in range-based loop with loop a variable of const ref type
 where the type of the variable does not match the one returned by the iterator.

Did you mean 'in a range-based loop with a loop variable of const ref type'?


Repository:
  rL LLVM

http://reviews.llvm.org/D18582



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

Re: [PATCH] D18582: [Clang-tidy] Update release notes with list of checks added since 3.8

2016-03-31 Thread Alexander Kornienko via cfe-commits

alexfh added a comment.

In http://reviews.llvm.org/D18582#388496, @Eugene.Zelenko wrote:

> Updated per Etienne comments.
>
> Links are still need to be added, but I'm not clear about address.

I'd point the links to the live version (e.g. 
http://clang.llvm.org/extra/clang-tidy/checks/readability-redundant-string-init.html)
 and then update them once the next release is branched.

Repository:
  rL LLVM

http://reviews.llvm.org/D18582

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

Re: [PATCH] D17933: Set MaxAtomicInlineWidth properly for i386, i486, and x86-64 cpus without cmpxchg16b.

2016-03-31 Thread James Y Knight via cfe-commits

jyknight added a comment.

Ping.


http://reviews.llvm.org/D17933



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

Re: [PATCH] D18671: [CUDA] Add --cuda-flush-denormals-to-zero.

2016-03-31 Thread Reid Kleckner via cfe-commits

rnk added inline comments.


Comment at: include/clang/Driver/Options.td:385
@@ -384,1 +384,3 @@
   HelpText<"CUDA installation path">;
+def fcuda_flush_denormals_to_zero : Flag<["-"], 
"fcuda-flush-denormals-to-zero">,
+  Group, Flags<[CC1Option]>,

rnk wrote:
> Let's stick with the long descriptive name for now.
Personally I would add an -fno variant, and add code to the driver that 
conditionally forwards the flag to cc1.


http://reviews.llvm.org/D18671



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

Re: [PATCH] D18671: [CUDA] Add --cuda-flush-denormals-to-zero.

2016-03-31 Thread Reid Kleckner via cfe-commits

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


Comment at: include/clang/Driver/Options.td:385
@@ -384,1 +384,3 @@
   HelpText<"CUDA installation path">;
+def fcuda_flush_denormals_to_zero : Flag<["-"], 
"fcuda-flush-denormals-to-zero">,
+  Group, Flags<[CC1Option]>,

Let's stick with the long descriptive name for now.


http://reviews.llvm.org/D18671



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

Re: [PATCH] D18671: [CUDA] Add --cuda-flush-denormals-to-zero.

2016-03-31 Thread Justin Lebar via cfe-commits

jlebar updated this revision to Diff 52292.
jlebar added a comment.

Address tra's review comments.

I also decided no longer to turn this on when -menable-unsafe-fp-math is on:
That's a cc1 flag that's implied by various clang flags, but now ftz is a clang
flag, so turning it on implicitly didn't make a ton of sense to me.


http://reviews.llvm.org/D18671

Files:
  include/clang/Basic/LangOptions.def
  include/clang/Driver/Options.td
  lib/CodeGen/CGCall.cpp
  lib/CodeGen/CodeGenModule.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/CodeGenCUDA/flush-denormals.cu

Index: test/CodeGenCUDA/flush-denormals.cu
===
--- /dev/null
+++ test/CodeGenCUDA/flush-denormals.cu
@@ -0,0 +1,23 @@
+// RUN: %clang_cc1 -fcuda-is-device \
+// RUN:   -triple nvptx-nvidia-cuda -emit-llvm -o - %s | FileCheck %s -check-prefix NOFTZ
+// RUN: %clang_cc1 -fcuda-is-device -fcuda-flush-denormals-to-zero \
+// RUN:   -triple nvptx-nvidia-cuda -emit-llvm -o - %s | FileCheck %s -check-prefix FTZ
+
+#include "Inputs/cuda.h"
+
+// Checks that device function calls get emitted with the "ntpvx-f32ftz"
+// attribute set to "true" when we compile CUDA device code with
+// -fcuda-flush-denormals-to-zero.  Further, check that we reflect the presence
+// or absence of -fcuda-flush-denormals-to-zero in a module flag.
+
+// CHECK: define void @foo() #0
+extern "C" __device__ void foo() {}
+
+// FTZ: attributes #0 = {{.*}} "nvptx-f32ftz"="true"
+// NOFTZ-NOT: attributes #0 = {{.*}} "nvptx-f32ftz"
+
+// FTZ:!llvm.module.flags = !{[[MODFLAG:![0-9]+]]}
+// FTZ:[[MODFLAG]] = !{i32 4, !"nvvm-reflect-ftz", i32 1}
+
+// NOFTZ:!llvm.module.flags = !{[[MODFLAG:![0-9]+]]}
+// NOFTZ:[[MODFLAG]] = !{i32 4, !"nvvm-reflect-ftz", i32 0}
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -1563,6 +1563,9 @@
   if (Args.hasArg(OPT_fno_cuda_host_device_constexpr))
 Opts.CUDAHostDeviceConstexpr = 0;
 
+  if (Opts.CUDAIsDevice && Args.hasArg(OPT_fcuda_flush_denormals_to_zero))
+Opts.CUDADeviceFlushDenormalsToZero = 1;
+
   if (Opts.ObjC1) {
 if (Arg *arg = Args.getLastArg(OPT_fobjc_runtime_EQ)) {
   StringRef value = arg->getValue();
Index: lib/CodeGen/CodeGenModule.cpp
===
--- lib/CodeGen/CodeGenModule.cpp
+++ lib/CodeGen/CodeGenModule.cpp
@@ -472,6 +472,14 @@
 getModule().addModuleFlag(llvm::Module::Override, "Cross-DSO CFI", 1);
   }
 
+  if (LangOpts.CUDAIsDevice && getTarget().getTriple().isNVPTX()) {
+// Indicate whether __nvvm_reflect should be configured to flush denormal
+// floating point values to 0.  (This corresponds to its "__CUDA_FTZ"
+// property.)
+getModule().addModuleFlag(llvm::Module::Override, "nvvm-reflect-ftz",
+  LangOpts.CUDADeviceFlushDenormalsToZero ? 1 : 0);
+  }
+
   if (uint32_t PLevel = Context.getLangOpts().PICLevel) {
 llvm::PICLevel::Level PL = llvm::PICLevel::Default;
 switch (PLevel) {
Index: lib/CodeGen/CGCall.cpp
===
--- lib/CodeGen/CGCall.cpp
+++ lib/CodeGen/CGCall.cpp
@@ -1763,6 +1763,10 @@
 // __syncthreads(), and so can't have certain optimizations applied around
 // them).  LLVM will remove this attribute where it safely can.
 FuncAttrs.addAttribute(llvm::Attribute::Convergent);
+
+// Respect -fcuda-flush-denormals-to-zero.
+if (getLangOpts().CUDADeviceFlushDenormalsToZero)
+  FuncAttrs.addAttribute("nvptx-f32ftz", "true");
   }
 
   ClangToLLVMArgMapping IRFunctionArgs(getContext(), FI);
Index: include/clang/Driver/Options.td
===
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -382,6 +382,9 @@
   HelpText<"Enable device-side debug info generation. Disables ptxas optimizations.">;
 def cuda_path_EQ : Joined<["--"], "cuda-path=">, Group,
   HelpText<"CUDA installation path">;
+def fcuda_flush_denormals_to_zero : Flag<["-"], "fcuda-flush-denormals-to-zero">,
+  Group, Flags<[CC1Option]>,
+  HelpText<"Flush denormal floating point values to zero in CUDA device mode.">;
 def dA : Flag<["-"], "dA">, Group;
 def dD : Flag<["-"], "dD">, Group, Flags<[CC1Option]>,
   HelpText<"Print macro definitions in -E mode in addition to normal output">;
Index: include/clang/Basic/LangOptions.def
===
--- include/clang/Basic/LangOptions.def
+++ include/clang/Basic/LangOptions.def
@@ -173,6 +173,7 @@
 LANGOPT(CUDAIsDevice  , 1, 0, "compiling for CUDA device")
 LANGOPT(CUDAAllowVariadicFunctions, 1, 0, "allowing variadic functions in CUDA device code")
 LANGOPT(CUDAHostDeviceConstexpr, 1, 1, "treating unattributed constexpr functions as __host__ __device__")

Re: [PATCH] D18671: [CUDA] Add --cuda-flush-denormals-to-zero.

2016-03-31 Thread Justin Lebar via cfe-commits

jlebar added a comment.

Thank you for the review, Art!

Comment at: include/clang/Driver/Options.td:385
@@ -384,1 +384,3 @@
   HelpText<"CUDA installation path">;
+def cuda_flush_denormals_to_zero : Flag<["--"], 
"cuda-flush-denormals-to-zero">,
+  HelpText<"Flush denormal floating point values to zero in CUDA device 
mode.">;

tra wrote:
> We need a provide a way to both enable and disable this. We either need a 
> "-no" variant or make it an option with value.
> 
> Also, can we shorten it to --cuda-ftz? I would probably mistype current name 
> more often than not.
> 
> We need a provide a way to both enable and disable this. We either need a 
> "-no" variant or make it an option with value.

Many (most) of the -f flags don't have -fno variants -- how do we decide which 
ones get an -fno and which don't?

> Also, can we shorten it to --cuda-ftz? I would probably mistype current name 
> more often than not.

Well, you and I both were calling it "ctz" about 50% of the time, so I'm not 
sure --cuda-ftz would solve the problem!  :)  (In all seriousness, that was one 
of the reasons I chose not to abbreviate it.)

Maybe "ftz" is a well-known acronym.  Doesn't quite look like it from googling, 
though.

I looked through the flags and concluded that "ftz" was more abbreviated than 
most of them.  Although "flush-denormals-to-zero" is at the verbose end of the 
spectrum.  I considered "flush-denormals", thought that was a big ambiguous -- 
flush them how?

Comment at: include/clang/Driver/Options.td:386
@@ -385,1 +385,3 @@
+def cuda_flush_denormals_to_zero : Flag<["--"], 
"cuda-flush-denormals-to-zero">,
+  HelpText<"Flush denormal floating point values to zero in CUDA device 
mode.">;
 def dA : Flag<["-"], "dA">, Group;

tra wrote:
> Is there an equivalent for ftz fo host-side FP operations? It would be good 
> to keep identical host and device side calculations as close as we can.
> Is there an equivalent for ftz fo host-side FP operations?

Not that I can tell.  The only other one I saw was opencl's equivalent flag, 
which does nothing at the moment.

Comment at: lib/Driver/ToolChains.cpp:4212
@@ +4211,3 @@
+  if (DriverArgs.hasArg(options::OPT_cuda_flush_denormals_to_zero))
+CC1Args.push_back("-fcuda-flush-denormals-to-zero");
+

tra wrote:
> Perhaps we don't need different flags at driver and CC1 levels. Top-level 
> "-f*" options in OPT_f_group are passed to CC1 automatically.
Aha, much better, thank you!

http://reviews.llvm.org/D18671

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

Re: [PATCH] D18672: [NVPTX] Read __CUDA_FTZ from module flags in NVVMReflect.

2016-03-31 Thread Artem Belevich via cfe-commits

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

LGTM.


http://reviews.llvm.org/D18672



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

Re: [PATCH] D18671: [CUDA] Add --cuda-flush-denormals-to-zero.

2016-03-31 Thread Artem Belevich via cfe-commits

tra added inline comments.


Comment at: include/clang/Driver/Options.td:385
@@ -384,1 +384,3 @@
   HelpText<"CUDA installation path">;
+def cuda_flush_denormals_to_zero : Flag<["--"], 
"cuda-flush-denormals-to-zero">,
+  HelpText<"Flush denormal floating point values to zero in CUDA device 
mode.">;

We need a provide a way to both enable and disable this. We either need a "-no" 
variant or make it an option with value.

Also, can we shorten it to --cuda-ftz? I would probably mistype current name 
more often than not.



Comment at: include/clang/Driver/Options.td:386
@@ -385,1 +385,3 @@
+def cuda_flush_denormals_to_zero : Flag<["--"], 
"cuda-flush-denormals-to-zero">,
+  HelpText<"Flush denormal floating point values to zero in CUDA device 
mode.">;
 def dA : Flag<["-"], "dA">, Group;

Is there an equivalent for ftz fo host-side FP operations? It would be good to 
keep identical host and device side calculations as close as we can.


Comment at: lib/Driver/ToolChains.cpp:4212
@@ +4211,3 @@
+  if (DriverArgs.hasArg(options::OPT_cuda_flush_denormals_to_zero))
+CC1Args.push_back("-fcuda-flush-denormals-to-zero");
+

Perhaps we don't need different flags at driver and CC1 levels. Top-level "-f*" 
options in OPT_f_group are passed to CC1 automatically.


http://reviews.llvm.org/D18671



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

r265042 - [index] Fix regression where ObjC method declarations may mistakenly get indexed as definition.

2016-03-31 Thread Argyrios Kyrtzidis via cfe-commits

Author: akirtzidis
Date: Thu Mar 31 15:18:22 2016
New Revision: 265042

URL: http://llvm.org/viewvc/llvm-project?rev=265042=rev
Log:
[index] Fix regression where ObjC method declarations may mistakenly get 
indexed as definition.

rdar://25372906

Modified:
cfe/trunk/lib/Index/IndexingContext.cpp
cfe/trunk/test/Index/Core/index-source.m
cfe/trunk/test/Index/index-decls.m
cfe/trunk/tools/libclang/CXIndexDataConsumer.cpp

Modified: cfe/trunk/lib/Index/IndexingContext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Index/IndexingContext.cpp?rev=265042=265041=265042=diff
==
--- cfe/trunk/lib/Index/IndexingContext.cpp (original)
+++ cfe/trunk/lib/Index/IndexingContext.cpp Thu Mar 31 15:18:22 2016
@@ -171,7 +171,7 @@ static const Decl *adjustTemplateImplici
   return nullptr;
 }
 
-static bool isDeclADefinition(const Decl *D, ASTContext ) {
+static bool isDeclADefinition(const Decl *D, const DeclContext *ContainerDC, 
ASTContext ) {
   if (auto VD = dyn_cast(D))
 return VD->isThisDeclarationADefinition(Ctx);
 
@@ -182,7 +182,7 @@ static bool isDeclADefinition(const Decl
 return TD->isThisDeclarationADefinition();
 
   if (auto MD = dyn_cast(D))
-return MD->isThisDeclarationADefinition();
+return MD->isThisDeclarationADefinition() || 
isa(ContainerDC);
 
   if (isa(D) ||
   isa(D) ||
@@ -284,7 +284,7 @@ bool IndexingContext::handleDeclOccurren
 
   if (IsRef)
 Roles |= (unsigned)SymbolRole::Reference;
-  else if (isDeclADefinition(D, *Ctx))
+  else if (isDeclADefinition(D, ContainerDC, *Ctx))
 Roles |= (unsigned)SymbolRole::Definition;
   else
 Roles |= (unsigned)SymbolRole::Declaration;

Modified: cfe/trunk/test/Index/Core/index-source.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/Core/index-source.m?rev=265042=265041=265042=diff
==
--- cfe/trunk/test/Index/Core/index-source.m (original)
+++ cfe/trunk/test/Index/Core/index-source.m Thu Mar 31 15:18:22 2016
@@ -71,3 +71,37 @@ typedef int jmp_buf[(18)];
 // CHECK: [[@LINE+2]]:12 | function/C | setjmp | c:@F@setjmp | _setjmp | Decl 
| rel: 0
 // CHECK: [[@LINE+1]]:19 | type-alias/C | jmp_buf | c:index-source.m@T@jmp_buf 
|  | Ref | rel: 0
 extern int setjmp(jmp_buf);
+
+@class I1;
+@interface I1
+// CHECK: [[@LINE+1]]:1 | instance-method/ObjC | meth | c:objc(cs)I1(im)meth | 
-[I1 meth] | Decl,Dyn,RelChild | rel: 1
+-(void)meth;
+@end
+
+@interface I2
+@property (readwrite) id prop;
+@end
+
+// CHECK: [[@LINE+2]]:17 | field/ObjC | _prop | c:objc(cs)I2@_prop | 
 | Def,Impl,RelChild | rel: 1
+// CHECK-NEXT: RelChild | I2 | c:objc(cs)I2
+@implementation I2
+// CHECK: [[@LINE+5]]:13 | instance-property/ObjC | prop | 
c:objc(cs)I2(py)prop |  | Ref | rel: 0
+// CHECK: [[@LINE+4]]:13 | instance-method/ObjC | prop | c:objc(cs)I2(im)prop 
| -[I2 prop] | Def,RelChild | rel: 1
+// CHECK-NEXT: RelChild | I2 | c:objc(cs)I2
+// CHECK: [[@LINE+2]]:13 | instance-method/ObjC | setProp: | 
c:objc(cs)I2(im)setProp: | -[I2 setProp:] | Def,RelChild | rel: 1
+// CHECK-NEXT: RelChild | I2 | c:objc(cs)I2
+@synthesize prop = _prop;
+@end
+
+@interface I3
+@property (readwrite) id prop;
+-(id)prop;
+-(void)setProp:(id)p;
+@end
+
+@implementation I3
+// CHECK: [[@LINE+3]]:13 | instance-property/ObjC | prop | 
c:objc(cs)I3(py)prop |  | Ref | rel: 0
+// CHECK: [[@LINE+2]]:13 | instance-method/ObjC | prop | c:objc(cs)I3(im)prop 
| -[I3 prop] | Def,RelChild | rel: 1
+// CHECK: [[@LINE+1]]:13 | instance-method/ObjC | setProp: | 
c:objc(cs)I3(im)setProp: | -[I3 setProp:] | Def,RelChild | rel: 1
+@synthesize prop = _prop;
+@end

Modified: cfe/trunk/test/Index/index-decls.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/index-decls.m?rev=265042=265041=265042=diff
==
--- cfe/trunk/test/Index/index-decls.m (original)
+++ cfe/trunk/test/Index/index-decls.m Thu Mar 31 15:18:22 2016
@@ -48,6 +48,12 @@ int test1() {
 }
 @end
 
+// rdar://25372906
+@class I5;
+@interface I5
+-(void)meth;
+@end
+
 // RUN: c-index-test -index-file %s -target x86_64-apple-macosx10.7 > %t
 // RUN: FileCheck %s -input-file=%t
 // CHECK: [indexDeclaration]: kind: objc-class | name: I | {{.*}} | loc: 1:12
@@ -71,5 +77,8 @@ int test1() {
 // CHECK: [indexEntityReference]: kind: function | name: extfn | {{.*}} | loc: 
33:10
 
 // CHECK: [indexDeclaration]: kind: objc-class | name: I4 | {{.*}} | loc: 36:12
+// CHECK: [indexEntityReference]: kind: objc-property | name: prop | {{.*}} | 
cursor: ObjCSynthesizeDecl=prop:37:34 (Definition) | loc: 43:13 | :: 
kind: objc-class | name: I4 | {{.*}} | container: [I4:42:17] | refkind: direct
 // CHECK-NOT: [indexDeclaration]: kind: objc-instance-method {{.*}} loc: 37:
 // CHECK-NOT: [indexDeclaration]: kind: objc-instance-method {{.*}} loc: 43:
+
+// CHECK: [indexDeclaration]:

[PATCH] D18672: [NVPTX] Read __CUDA_FTZ from module flags in NVVMReflect.

2016-03-31 Thread Justin Lebar via cfe-commits

jlebar created this revision.
jlebar added reviewers: tra, rnk.
jlebar added a subscriber: cfe-commits.
Herald added a subscriber: jholewinski.

Previously the NVVMReflect pass would read its configuration from
command-line flags or a static configuration given to the pass at
instantiation time.

This doesn't quite work for clang's use-case.  It needs to pass a value
for __CUDA_FTZ down on a per-module basis.  We use a module flag for
this, so the NVVMReflect pass needs to be updated to read said flag.

http://reviews.llvm.org/D18672

Files:
  lib/Target/NVPTX/NVVMReflect.cpp
  test/CodeGen/NVPTX/nvvm-reflect-module-flag.ll

Index: test/CodeGen/NVPTX/nvvm-reflect-module-flag.ll
===
--- /dev/null
+++ test/CodeGen/NVPTX/nvvm-reflect-module-flag.ll
@@ -0,0 +1,13 @@
+; RUN: opt < %s -S -nvvm-reflect | FileCheck %s
+
+declare i32 @__nvvm_reflect(i8*)
+@str = private unnamed_addr addrspace(1) constant [11 x i8] c"__CUDA_FTZ\00"
+
+define i32 @foo() {
+  %call = call i32 @__nvvm_reflect(i8* addrspacecast (i8 addrspace(1)* 
getelementptr inbounds ([11 x i8], [11 x i8] addrspace(1)* @str, i32 0, i32 0) 
to i8*))
+  ; CHECK: ret i32 42
+  ret i32 %call
+}
+
+!llvm.module.flags = !{!0}
+!0 = !{i32 4, !"nvvm-reflect-ftz", i32 42}
Index: lib/Target/NVPTX/NVVMReflect.cpp
===
--- lib/Target/NVPTX/NVVMReflect.cpp
+++ lib/Target/NVPTX/NVVMReflect.cpp
@@ -7,11 +7,16 @@
 //
 
//===--===//
 //
-// This pass replaces occurrences of __nvvm_reflect("string") and
-// llvm.nvvm.reflect with an integer based on the value of -nvvm-reflect-list
-// string=.
+// This pass replaces occurrences of __nvvm_reflect("foo") and 
llvm.nvvm.reflect
+// with an integer.
 //
-// If we see a string not specified in our flags, we replace that call with 0.
+// We choose the value we use by looking, in this order, at:
+//
+//  * the -nvvm-reflect-list flag, which has the format "foo=1,bar=42",
+//  * the StringMap passed to the pass's constructor, and
+//  * metadata in the module itself.
+//
+// If we see an unknown string, we replace its call with 0.
 //
 
//===--===//
 
@@ -55,10 +60,9 @@
   static char ID;
   NVVMReflect() : NVVMReflect(StringMap()) {}
 
-  NVVMReflect(const StringMap ) : FunctionPass(ID) {
+  NVVMReflect(const StringMap )
+  : FunctionPass(ID), VarMap(Mapping) {
 initializeNVVMReflectPass(*PassRegistry::getPassRegistry());
-for (const auto  : Mapping)
-  VarMap[KV.getKey()] = KV.getValue();
 setVarMap();
   }
 
@@ -206,6 +210,12 @@
 auto Iter = VarMap.find(ReflectArg);
 if (Iter != VarMap.end())
   ReflectVal = Iter->second;
+else if (ReflectArg == "__CUDA_FTZ") {
+  // Try to pull __CUDA_FTZ from the nvvm-reflect-ftz module flag.
+  if (auto *Flag = mdconst::extract_or_null(
+  F.getParent()->getModuleFlag("nvvm-reflect-ftz")))
+ReflectVal = Flag->getSExtValue();
+}
 Call->replaceAllUsesWith(ConstantInt::get(Call->getType(), ReflectVal));
 ToRemove.push_back(Call);
   }


Index: test/CodeGen/NVPTX/nvvm-reflect-module-flag.ll
===
--- /dev/null
+++ test/CodeGen/NVPTX/nvvm-reflect-module-flag.ll
@@ -0,0 +1,13 @@
+; RUN: opt < %s -S -nvvm-reflect | FileCheck %s
+
+declare i32 @__nvvm_reflect(i8*)
+@str = private unnamed_addr addrspace(1) constant [11 x i8] c"__CUDA_FTZ\00"
+
+define i32 @foo() {
+  %call = call i32 @__nvvm_reflect(i8* addrspacecast (i8 addrspace(1)* getelementptr inbounds ([11 x i8], [11 x i8] addrspace(1)* @str, i32 0, i32 0) to i8*))
+  ; CHECK: ret i32 42
+  ret i32 %call
+}
+
+!llvm.module.flags = !{!0}
+!0 = !{i32 4, !"nvvm-reflect-ftz", i32 42}
Index: lib/Target/NVPTX/NVVMReflect.cpp
===
--- lib/Target/NVPTX/NVVMReflect.cpp
+++ lib/Target/NVPTX/NVVMReflect.cpp
@@ -7,11 +7,16 @@
 //
 //===--===//
 //
-// This pass replaces occurrences of __nvvm_reflect("string") and
-// llvm.nvvm.reflect with an integer based on the value of -nvvm-reflect-list
-// string=.
+// This pass replaces occurrences of __nvvm_reflect("foo") and llvm.nvvm.reflect
+// with an integer.
 //
-// If we see a string not specified in our flags, we replace that call with 0.
+// We choose the value we use by looking, in this order, at:
+//
+//  * the -nvvm-reflect-list flag, which has the format "foo=1,bar=42",
+//  * the StringMap passed to the pass's constructor, and
+//  * metadata in the module itself.
+//
+// If we see an unknown string, we replace its call with 0.
 //
 //===--===//
 
@@ -55,10 +60,9 @@
   static char ID;
   NVVMReflect() :

[PATCH] D18671: [CUDA] Add --cuda-flush-denormals-to-zero.

2016-03-31 Thread Justin Lebar via cfe-commits

jlebar created this revision.
jlebar added reviewers: tra, rnk.
jlebar added a subscriber: cfe-commits.

Setting this flag causes all functions are annotated with the
"nvvm-f32ftz" = "true" attribute.

In addition, we annotate the module with "nvvm-reflect-ftz" set
to 0 or 1, depending on whether -cuda-flush-denormals-to-zero is set.
This is read by the NVVMReflect pass.

http://reviews.llvm.org/D18671

Files:
  include/clang/Basic/LangOptions.def
  include/clang/Driver/CC1Options.td
  include/clang/Driver/Options.td
  lib/CodeGen/CGCall.cpp
  lib/CodeGen/CodeGenModule.cpp
  lib/Driver/ToolChains.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/CodeGenCUDA/flush-denormals.cu

Index: test/CodeGenCUDA/flush-denormals.cu
===
--- /dev/null
+++ test/CodeGenCUDA/flush-denormals.cu
@@ -0,0 +1,23 @@
+// RUN: %clang_cc1 -fcuda-is-device \
+// RUN:   -triple nvptx-nvidia-cuda -emit-llvm -o - %s | FileCheck %s -check-prefix NOFTZ
+// RUN: %clang_cc1 -fcuda-is-device -fcuda-flush-denormals-to-zero \
+// RUN:   -triple nvptx-nvidia-cuda -emit-llvm -o - %s | FileCheck %s -check-prefix FTZ
+
+#include "Inputs/cuda.h"
+
+// Checks that device function calls get emitted with the "ntpvx-f32ftz"
+// attribute set to "true" when we compile CUDA device code with
+// -fcuda-flush-denormals-to-zero.  Further, check that we reflect the presence
+// or absence of -fcuda-flush-denormals-to-zero in a module flag.
+
+// CHECK: define void @foo() #0
+extern "C" __device__ void foo() {}
+
+// FTZ: attributes #0 = {{.*}} "nvptx-f32ftz"="true"
+// NOFTZ-NOT: attributes #0 = {{.*}} "nvptx-f32ftz"
+
+// FTZ:!llvm.module.flags = !{[[MODFLAG:![0-9]+]]}
+// FTZ:[[MODFLAG]] = !{i32 4, !"nvvm-reflect-ftz", i32 1}
+
+// NOFTZ:!llvm.module.flags = !{[[MODFLAG:![0-9]+]]}
+// NOFTZ:[[MODFLAG]] = !{i32 4, !"nvvm-reflect-ftz", i32 0}
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -1563,6 +1563,10 @@
   if (Args.hasArg(OPT_fno_cuda_host_device_constexpr))
 Opts.CUDAHostDeviceConstexpr = 0;
 
+  if (Opts.CUDAIsDevice &&
+  (Args.hasArg(OPT_fcuda_flush_denormals_to_zero) || Opts.UnsafeFPMath))
+Opts.CUDADeviceFlushDenormalsToZero = 1;
+
   if (Opts.ObjC1) {
 if (Arg *arg = Args.getLastArg(OPT_fobjc_runtime_EQ)) {
   StringRef value = arg->getValue();
Index: lib/Driver/ToolChains.cpp
===
--- lib/Driver/ToolChains.cpp
+++ lib/Driver/ToolChains.cpp
@@ -4208,6 +4208,9 @@
   Linux::addClangTargetOptions(DriverArgs, CC1Args);
   CC1Args.push_back("-fcuda-is-device");
 
+  if (DriverArgs.hasArg(options::OPT_cuda_flush_denormals_to_zero))
+CC1Args.push_back("-fcuda-flush-denormals-to-zero");
+
   if (DriverArgs.hasArg(options::OPT_nocudalib))
 return;
 
Index: lib/CodeGen/CodeGenModule.cpp
===
--- lib/CodeGen/CodeGenModule.cpp
+++ lib/CodeGen/CodeGenModule.cpp
@@ -472,6 +472,14 @@
 getModule().addModuleFlag(llvm::Module::Override, "Cross-DSO CFI", 1);
   }
 
+  if (LangOpts.CUDAIsDevice && getTarget().getTriple().isNVPTX()) {
+// Indicate whether __nvvm_reflect should be configured to flush denormal
+// floating point values to 0.  (This corresponds to its "__CUDA_FTZ"
+// property.)
+getModule().addModuleFlag(llvm::Module::Override, "nvvm-reflect-ftz",
+  LangOpts.CUDADeviceFlushDenormalsToZero ? 1 : 0);
+  }
+
   if (uint32_t PLevel = Context.getLangOpts().PICLevel) {
 llvm::PICLevel::Level PL = llvm::PICLevel::Default;
 switch (PLevel) {
Index: lib/CodeGen/CGCall.cpp
===
--- lib/CodeGen/CGCall.cpp
+++ lib/CodeGen/CGCall.cpp
@@ -1763,6 +1763,10 @@
 // __syncthreads(), and so can't have certain optimizations applied around
 // them).  LLVM will remove this attribute where it safely can.
 FuncAttrs.addAttribute(llvm::Attribute::Convergent);
+
+// Respect -fcuda-flush-denormals-to-zero.
+if (getLangOpts().CUDADeviceFlushDenormalsToZero)
+  FuncAttrs.addAttribute("nvptx-f32ftz", "true");
   }
 
   ClangToLLVMArgMapping IRFunctionArgs(getContext(), FI);
Index: include/clang/Driver/Options.td
===
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -382,6 +382,8 @@
   HelpText<"Enable device-side debug info generation. Disables ptxas optimizations.">;
 def cuda_path_EQ : Joined<["--"], "cuda-path=">, Group,
   HelpText<"CUDA installation path">;
+def cuda_flush_denormals_to_zero : Flag<["--"], "cuda-flush-denormals-to-zero">,
+  HelpText<"Flush denormal floating point values to zero in CUDA device mode.">;
 def dA : Flag<["-"], "dA">, Group;
 def dD : Flag<["-"], "dD">, Group,

Re: [PATCH] D18635: Rework interface for bitset-using features to use a notion of class scope.

2016-03-31 Thread Richard Smith via cfe-commits

rsmith added inline comments.


Comment at: docs/ClassScope.rst:2
@@ +1,3 @@
+===
+Class Scope
+===

Can you use some word other than "scope" here? "Class scope" is already a term 
of art in C++, meaning something completely different. I think what you're 
referring to is exactly the visibility of the class (in the ELF sense).


Comment at: docs/ClassScope.rst:13
@@ +12,3 @@
+to a single linkage unit (i.e. the executable or DSO). It is effectively an
+ODR violation to declare classes with linkage-unit scope in multiple linkage
+units.  Classes with global scope may be defined in multiple linkage units,

classes -> a class

Otherwise this reads like you're saying at most one linkage unit per program 
can declare classes with linkage-unit scope.


Comment at: docs/ClassScope.rst:14
@@ +13,3 @@
+ODR violation to declare classes with linkage-unit scope in multiple linkage
+units.  Classes with global scope may be defined in multiple linkage units,
+but the tradeoff is that the virtual function call optimization and control

Classes -> A class


http://reviews.llvm.org/D18635



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

Re: [PATCH] D18635: Rework interface for bitset-using features to use a notion of class scope.

2016-03-31 Thread Evgeniy Stepanov via cfe-commits

eugenis added inline comments.


Comment at: docs/ClassScope.rst:23
@@ +22,3 @@
+
+  -  ``-fdefault-class-scope=attrs`` indicates that the compiler will infer
+ class scope based on platform-specific attributes that control the class's

Maybe call it "default"? Attrs sounds too specific. Basically this setting lets 
clang figure out scope based on the source code.


Comment at: docs/ClassScope.rst:28
@@ +27,3 @@
+ or the ``-fvisibility=hidden -fvisibility-inlines-hidden`` flags)
+ receive global scope, and all others receive linkage-unit scope. When
+ targeting Windows, classes with the ``__declspec(dllexport)`` or

hidden visibility = linkage-unit scope, not global scope.


Comment at: docs/ControlFlowIntegrity.rst:271
@@ +270,3 @@
+linkage-unit scope. With this flag enabled, the compiler will emit cross-DSO
+CFI checks for all classes, except for those which appear in the CFI blacklist
+or which use a ``no_sanitize`` attribute.

Do we emit a fast non-cross-DSO check for classes with linkage-unit scope?


http://reviews.llvm.org/D18635



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

r265038 - Diagnostics: remove dodgy handler for bitcode inlineasm diagnostics.

2016-03-31 Thread Tim Northover via cfe-commits

Author: tnorthover
Date: Thu Mar 31 14:19:24 2016
New Revision: 265038

URL: http://llvm.org/viewvc/llvm-project?rev=265038=rev
Log:
Diagnostics: remove dodgy handler for bitcode inlineasm diagnostics.

Whatever crash it was there to present appears to have been fixed in the
backend now, and it had the nasty side-effect of causing clang to exit(0) and
leave a .o containing goodness knows what even when an error hit.

Modified:
cfe/trunk/lib/CodeGen/CodeGenAction.cpp
cfe/trunk/test/CodeGen/asm-errors.c

Modified: cfe/trunk/lib/CodeGen/CodeGenAction.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenAction.cpp?rev=265038=265037=265038=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenAction.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenAction.cpp Thu Mar 31 14:19:24 2016
@@ -756,12 +756,6 @@ CodeGenAction::CreateASTConsumer(Compile
   return std::move(Result);
 }
 
-static void BitcodeInlineAsmDiagHandler(const llvm::SMDiagnostic ,
- void *Context,
- unsigned LocCookie) {
-  SM.print(nullptr, llvm::errs());
-}
-
 void CodeGenAction::ExecuteAction() {
   // If this is an IR file, we have to treat it specially.
   if (getCurrentFileKind() == IK_LLVM_IR) {
@@ -810,8 +804,6 @@ void CodeGenAction::ExecuteAction() {
   TheModule->setTargetTriple(TargetOpts.Triple);
 }
 
-LLVMContext  = TheModule->getContext();
-Ctx.setInlineAsmDiagnosticHandler(BitcodeInlineAsmDiagHandler);
 EmitBackendOutput(CI.getDiagnostics(), CI.getCodeGenOpts(), TargetOpts,
   CI.getLangOpts(), CI.getTarget().getDataLayout(),
   TheModule.get(), BA, OS);

Modified: cfe/trunk/test/CodeGen/asm-errors.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/asm-errors.c?rev=265038=265037=265038=diff
==
--- cfe/trunk/test/CodeGen/asm-errors.c (original)
+++ cfe/trunk/test/CodeGen/asm-errors.c Thu Mar 31 14:19:24 2016
@@ -3,7 +3,7 @@
 // RUN: not %clang_cc1 -triple i386-apple-darwin10 -emit-obj %s -o /dev/null > 
%t 2>&1
 // RUN: FileCheck %s < %t
 // RUN: %clang_cc1 -triple i386-apple-darwin10 -emit-llvm-bc %s -o %t.bc
-// RUN: %clang_cc1 -triple i386-apple-darwin10 -emit-obj %t.bc -o /dev/null 
2>&1 | \
+// RUN: not %clang_cc1 -triple i386-apple-darwin10 -emit-obj %t.bc -o 
/dev/null 2>&1 | \
 // RUN:   FileCheck --check-prefix=CRASH-REPORT %s
 // CRASH-REPORT: :
 // CRASH-REPORT: error: invalid instruction mnemonic 'abc'


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

Re: [PATCH] D18582: [Clang-tidy] Update release notes with list of checks added since 3.8

2016-03-31 Thread Eugene Zelenko via cfe-commits

Eugene.Zelenko updated this revision to Diff 52253.
Eugene.Zelenko added a comment.

Updated per Etienne comments.

Links are still need to be added, but I'm not clear about address.


Repository:
  rL LLVM

http://reviews.llvm.org/D18582

Files:
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/misc-dangling-handle.rst
  docs/clang-tidy/checks/performance-faster-string-find.rst
  docs/clang-tidy/checks/performance-implicit-cast-in-loop.rst
  docs/clang-tidy/checks/readability-redundant-control-flow.rst

Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -63,11 +63,83 @@
 explain them more clearly, and provide more accurate fix-its for the issues
 identified.  The improvements since the 3.8 release include:
 
-- New ``modernize-raw-string-literal`` check
+- New `cert-env33-c` check
 
-  This check selectively replaces string literals containing escaped
-  characters with raw string literals.
+  Flags calls to ``system()``, ``popen()``, and ``_popen()``, which execute a
+  command processor.
 
+- New `cert-flp30-c` check
+
+  Flags ``for`` loops where the induction expression has a floating-point type.
+
+- New `cppcoreguidelines-pro-type-member-init` check
+
+  Flags user-defined constructor definitions that do not initialize all builtin
+  and pointer fields which leaves their memory in an undefined state.
+
+- New `misc-dangling-handle` check
+
+  Detects dangling references in value handlers like
+  ``std::experimental::string_view``.
+
+- New `misc-forward-declaration-namespace` check
+
+  Checks if an unused forward declaration is in a wrong namespace.
+
+- New `misc-misplaced-widening-cast` check
+
+  Warns when there is a explicit redundant cast of a calculation result to a
+  bigger type.
+
+- New `misc-suspicious-missing-comma` check
+
+  Warns about 'probably' missing comma in string literals initializer list.
+
+- New `misc-suspicious-semicolon` check
+
+  Finds most instances of stray semicolons that unexpectedly alter the meaning
+  of the code.
+
+- New `modernize-deprecated-headers` check
+
+  Replaces C standard library headers with their C++ alternatives.
+
+- New `modernize-raw-string-literal` check
+
+  Selectively replaces string literals containing escaped characters with raw
+  string literals.
+
+- New `performance-faster-string-find` check
+
+  Optimize calls to ``std::string::find()`` and friends when the needle passed
+  is a single character string literal.
+
+- New `performance-implicit-cast-in-loop` check
+
+  Warns about range-based loop with a loop variable of const ref type where the
+  type of the variable does not match the one returned by the iterator.
+
+- New `performance-unnecessary-value-param` check
+
+  Flags value parameter declarations of expensive to copy types that are copied
+  for each invocation but it would suffice to pass them by const reference.
+
+- New `readability-redundant-control-flow` check
+
+  Looks for procedures (functions returning no value) with ``return`` statements
+  at the end of the function.  Such `return` statements are redundant.
+
+- New `readability-redundant-string-init` check
+
+  Finds unnecessary string initializations.
+
+Fixed bugs:
+
+  Crash when :program:`clang-tidy` runs on compile database with relative source files
+  paths.
+
+  Crash when running with the `-fdelayed-template-parsing` flag.
+
 Clang-tidy changes from 3.7 to 3.8
 ^^
 
Index: docs/clang-tidy/checks/readability-redundant-control-flow.rst
===
--- docs/clang-tidy/checks/readability-redundant-control-flow.rst
+++ docs/clang-tidy/checks/readability-redundant-control-flow.rst
@@ -3,11 +3,12 @@
 readability-redundant-control-flow
 ==
 
-This check looks for procedures (functions returning no value) with `return`
-statements at the end of the function.  Such `return` statements are redundant.
+This check looks for procedures (functions returning no value) with ``return``
+statements at the end of the function.  Such ``return`` statements are
+redundant.
 
-Loop statements (`for`, `while`, `do while`) are checked for redundant
-`continue` statements at the end of the loop body.
+Loop statements (``for``, ``while``, ``do while``) are checked for redundant
+``continue`` statements at the end of the loop body.
 
 Examples:
 
Index: docs/clang-tidy/checks/performance-implicit-cast-in-loop.rst
===
--- docs/clang-tidy/checks/performance-implicit-cast-in-loop.rst
+++ docs/clang-tidy/checks/performance-implicit-cast-in-loop.rst
@@ -1,7 +1,7 @@
 performance-implicit-cast-in-loop
 =
 
-This warning appears in range-based loop with loop variable of const ref type
+This warning appears in range-based loop with loop a variable of const ref type
 where the type

Re: [PATCH] D18654: In C++11 it is undefined to shift into the sign bit

2016-03-31 Thread Filipe Cabecinhas via cfe-commits

filcab abandoned this revision.
filcab added a comment.

Thanks for clarifying, Richard.
I'll think about getting some fixes/tests in for our DRs.


http://reviews.llvm.org/D18654



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

Re: [PATCH] D18636: [PGO] Avoid instrumenting constants at value sites

2016-03-31 Thread Betul Buyukkurt via cfe-commits

betulb added a comment.

Committed as r265037.


Repository:
  rL LLVM

http://reviews.llvm.org/D18636



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

Re: [PATCH] D18652: [Inline asm] Correctly parse GCC-style asm line following MS-style asm line

2016-03-31 Thread Richard Smith via cfe-commits

rsmith added a subscriber: rsmith.


Comment at: lib/Parse/ParseStmtAsm.cpp:423
@@ -421,3 +422,3 @@
 bool isAsm = Tok.is(tok::kw_asm);
-if (SingleLineMode && !isAsm)
+if (SingleLineMode && (!isAsm || NextToken().is(tok::l_paren)))
   break;

The next token in GCC-style inline asm could also be `volatile` (or `const` or 
`goto` -- though we don't support the latter).

Please make this GCC / MS dialect selection the same way that 
`ParseAsmStatement` does (and factor out a static `isGCCAsmStatement(Token 
)` function or similar).


http://reviews.llvm.org/D18652



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

r265037 - [PGO] Avoid instrumenting constants at value sites

2016-03-31 Thread Betul Buyukkurt via cfe-commits

Author: betulb
Date: Thu Mar 31 13:41:34 2016
New Revision: 265037

URL: http://llvm.org/viewvc/llvm-project?rev=265037=rev
Log:
[PGO] Avoid instrumenting constants at value sites

Value profiling should not profile constants and/or constant
expressions when they appear as callees in call instructions.
Constant expressions form when a direct callee has bitcasts or
inttoptr(ptrtint (callee)) nests surrounding it. Value profiling
should avoid instrumenting such cases. Mostly NFC.


Added:
cfe/trunk/test/Profile/c-avoid-direct-call.c
Modified:
cfe/trunk/lib/CodeGen/CodeGenPGO.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenPGO.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenPGO.cpp?rev=265037=265036=265037=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenPGO.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenPGO.cpp Thu Mar 31 13:41:34 2016
@@ -755,6 +755,9 @@ void CodeGenPGO::valueProfile(CGBuilderT
   if (!ValuePtr || !ValueSite || !Builder.GetInsertBlock())
 return;
 
+  if (isa(ValuePtr))
+return;
+
   bool InstrumentValueSites = CGM.getCodeGenOpts().hasProfileClangInstr();
   if (InstrumentValueSites && RegionCounterMap) {
 auto BuilderInsertPoint = Builder.saveIP();

Added: cfe/trunk/test/Profile/c-avoid-direct-call.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Profile/c-avoid-direct-call.c?rev=265037=auto
==
--- cfe/trunk/test/Profile/c-avoid-direct-call.c (added)
+++ cfe/trunk/test/Profile/c-avoid-direct-call.c Thu Mar 31 13:41:34 2016
@@ -0,0 +1,11 @@
+// Check the value profiling instrinsics emitted by instrumentation.
+
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.9 -main-file-name 
c-avoid-direct-call.c %s -o - -emit-llvm -fprofile-instrument=clang -mllvm 
-enable-value-profiling | FileCheck %s
+
+void foo();
+
+int main(void) {
+// CHECK-NOT: call void @__llvm_profile_instrument_target
+  foo(21);
+  return 0;
+}


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

Re: [PATCH] D18582: [Clang-tidy] Update release notes with list of checks added since 3.8

2016-03-31 Thread Etienne Bergeron via cfe-commits

etienneb accepted this revision.
etienneb added a comment.

thanks for taking care of this.



Comment at: docs/ReleaseNotes.rst:131
@@ +130,3 @@
+  Finds unnecessary string initializations.
+
+Fixed bugs:

I just landed this one: http://reviews.llvm.org/D18457

I'll appreciate if you can add the entry here.

Thanks.


- New `misc-suspicious-missing-comma` check

  Warns about 'probably' missing comma in string literals initializer list.


Comment at: docs/ReleaseNotes.rst:136
@@ -71,1 +135,3 @@
+  paths.
+
 Clang-tidy changes from 3.7 to 3.8

Crash when running with the ``-fdelayed-template-parsing`` flag.

see: http://reviews.llvm.org/D18238


Repository:
  rL LLVM

http://reviews.llvm.org/D18582



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

Re: [PATCH] D18654: In C++11 it is undefined to shift into the sign bit

2016-03-31 Thread Richard Smith via cfe-commits

rsmith added a comment.

In http://reviews.llvm.org/D18654#388419, @filcab wrote:

> That means that our C++11 mode will have some fixes, right?

Right. The standard's rules are often incoherent or unimplementable without the 
fixes in DRs, so it's not meaningful to implement ISO C++ as standardized. In 
order to avoid making judgement calls ourselves, we (and many other compiler 
vendors) enable *all* relevant DR fixes for each language mode.

> How can we call what out C++11 mode is?

It's ISO C++11, plus all relevant defect reports. (Incidentally, this is why 
C++98 and C++03 modes are identical across typical compilers -- the difference 
is only DRs.)

> Are there updated versions of the standard?

No. (As the C++ standard editor, I've been considering maintaining such an 
alternative standard, but it's a large amount of work, and it would give the 
false impression that the document containing the standard + DRs is in some way 
an official product of the ISO C++ committee.)

> Are there lists of defects that we have fixed and others we haven't?

clang.llvm.org/cxx_dr_status.html is has a complete list of core issues, along 
with an incomplete list of Clang's implementation status for them. If you want 
to get involved with that, there are tests in clang's test/CXX/drs/... for each 
such issue, containing special comments describing our implementation status 
(the HTML status page is then generated by scraping those comments); tests for 
more DRs would be appreciated!

http://reviews.llvm.org/D18654

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

Re: [PATCH] D18636: [PGO] Avoid instrumenting constants at value sites

2016-03-31 Thread Betul Buyukkurt via cfe-commits

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

Addressed review comments.


http://reviews.llvm.org/D18636

Files:
  lib/CodeGen/CodeGenPGO.cpp
  test/Profile/c-avoid-direct-call.c

Index: test/Profile/c-avoid-direct-call.c
===
--- /dev/null
+++ test/Profile/c-avoid-direct-call.c
@@ -0,0 +1,11 @@
+// Check the value profiling instrinsics emitted by instrumentation.
+
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.9 -main-file-name 
c-avoid-direct-call.c %s -o - -emit-llvm -fprofile-instrument=clang -mllvm 
-enable-value-profiling | FileCheck %s
+
+void foo();
+
+int main(void) {
+// CHECK-NOT: call void @__llvm_profile_instrument_target
+  foo(21);
+  return 0;
+}
Index: lib/CodeGen/CodeGenPGO.cpp
===
--- lib/CodeGen/CodeGenPGO.cpp
+++ lib/CodeGen/CodeGenPGO.cpp
@@ -755,6 +755,9 @@
   if (!ValuePtr || !ValueSite || !Builder.GetInsertBlock())
 return;
 
+  if (isa(ValuePtr))
+return;
+
   bool InstrumentValueSites = CGM.getCodeGenOpts().hasProfileClangInstr();
   if (InstrumentValueSites && RegionCounterMap) {
 auto BuilderInsertPoint = Builder.saveIP();


Index: test/Profile/c-avoid-direct-call.c
===
--- /dev/null
+++ test/Profile/c-avoid-direct-call.c
@@ -0,0 +1,11 @@
+// Check the value profiling instrinsics emitted by instrumentation.
+
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.9 -main-file-name c-avoid-direct-call.c %s -o - -emit-llvm -fprofile-instrument=clang -mllvm -enable-value-profiling | FileCheck %s
+
+void foo();
+
+int main(void) {
+// CHECK-NOT: call void @__llvm_profile_instrument_target
+  foo(21);
+  return 0;
+}
Index: lib/CodeGen/CodeGenPGO.cpp
===
--- lib/CodeGen/CodeGenPGO.cpp
+++ lib/CodeGen/CodeGenPGO.cpp
@@ -755,6 +755,9 @@
   if (!ValuePtr || !ValueSite || !Builder.GetInsertBlock())
 return;
 
+  if (isa(ValuePtr))
+return;
+
   bool InstrumentValueSites = CGM.getCodeGenOpts().hasProfileClangInstr();
   if (InstrumentValueSites && RegionCounterMap) {
 auto BuilderInsertPoint = Builder.saveIP();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D18479: [CodeGenCXX] Fix ItaniumCXXABI::getAlignmentOfExnObject to return 8-byte alignment on Darwin

2016-03-31 Thread Akira Hatanaka via cfe-commits

ahatanak added inline comments.


Comment at: cfe/trunk/include/clang/Basic/TargetInfo.h:426
@@ +425,3 @@
+/// we assume that alignment here.  (It's generally 16 bytes, but
+/// some targets overwrite it.)
+return getDefaultAlignForAttributeAligned();

rjmccall wrote:
> This should just be an ordinary comment, not a /// comment.
> 
> Please also add this to the documentation comment:
> 
>   This is only meaningful for targets that allocate C++ exceptions in a 
> system runtime, such as those using the Itanium C++ ABI.
Fixed in r265035.


Repository:
  rL LLVM

http://reviews.llvm.org/D18479



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

[clang-tools-extra] r265033 - [clang-tidy] Add a new checker to detect missing comma in initializer list.

2016-03-31 Thread Etienne Bergeron via cfe-commits

Author: etienneb
Date: Thu Mar 31 13:12:23 2016
New Revision: 265033

URL: http://llvm.org/viewvc/llvm-project?rev=265033=rev
Log:
[clang-tidy] Add a new checker to detect missing comma in initializer list.

Summary:
This checker is able to detect missing comma in 
an array of string literals.

```
  const char* A[] = {
"abc",
"def"   // missing comma (no compiler warnings)
"ghi",
  };
```

The ratio of false-positive is reduced by restricting the
size of the array considered and the ratio of missing
comma.

To validate the quantity of false positive, the checker
was tried over LLVM and chromium code and detected these
cases:

[[ http://reviews.llvm.org/D18454 | http://reviews.llvm.org/D18454 ]]
[[https://codereview.chromium.org/1807753002/ | 
https://codereview.chromium.org/1807753002/]]
[[https://codereview.chromium.org/1826193002/ | 
https://codereview.chromium.org/1826193002/]]
[[https://codereview.chromium.org/1805713002/ | 
https://codereview.chromium.org/1805713002/]]

Reviewers: alexfh

Subscribers: LegalizeAdulthood, szdominik, xazax.hun, cfe-commits

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

Added:
clang-tools-extra/trunk/clang-tidy/misc/SuspiciousMissingCommaCheck.cpp
clang-tools-extra/trunk/clang-tidy/misc/SuspiciousMissingCommaCheck.h

clang-tools-extra/trunk/docs/clang-tidy/checks/misc-suspicious-missing-comma.rst
clang-tools-extra/trunk/test/clang-tidy/misc-suspicious-missing-comma.cpp
Modified:
clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt
clang-tools-extra/trunk/clang-tidy/misc/MiscTidyModule.cpp
clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst

Modified: clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt?rev=265033=265032=265033=diff
==
--- clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clang-tidy/misc/CMakeLists.txt Thu Mar 31 13:12:23 
2016
@@ -23,6 +23,7 @@ add_clang_library(clangTidyMiscModule
   SizeofContainerCheck.cpp
   StaticAssertCheck.cpp
   StringIntegerAssignmentCheck.cpp
+  SuspiciousMissingCommaCheck.cpp
   SuspiciousSemicolonCheck.cpp
   SwappedArgumentsCheck.cpp
   ThrowByValueCatchByReferenceCheck.cpp

Modified: clang-tools-extra/trunk/clang-tidy/misc/MiscTidyModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/MiscTidyModule.cpp?rev=265033=265032=265033=diff
==
--- clang-tools-extra/trunk/clang-tidy/misc/MiscTidyModule.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/misc/MiscTidyModule.cpp Thu Mar 31 
13:12:23 2016
@@ -31,6 +31,7 @@
 #include "SizeofContainerCheck.h"
 #include "StaticAssertCheck.h"
 #include "StringIntegerAssignmentCheck.h"
+#include "SuspiciousMissingCommaCheck.h"
 #include "SuspiciousSemicolonCheck.h"
 #include "SwappedArgumentsCheck.h"
 #include "ThrowByValueCatchByReferenceCheck.h"
@@ -88,6 +89,8 @@ public:
 "misc-static-assert");
 CheckFactories.registerCheck(
 "misc-string-integer-assignment");
+CheckFactories.registerCheck(
+"misc-suspicious-missing-comma");
 CheckFactories.registerCheck(
 "misc-suspicious-semicolon");
 CheckFactories.registerCheck(

Added: clang-tools-extra/trunk/clang-tidy/misc/SuspiciousMissingCommaCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/SuspiciousMissingCommaCheck.cpp?rev=265033=auto
==
--- clang-tools-extra/trunk/clang-tidy/misc/SuspiciousMissingCommaCheck.cpp 
(added)
+++ clang-tools-extra/trunk/clang-tidy/misc/SuspiciousMissingCommaCheck.cpp Thu 
Mar 31 13:12:23 2016
@@ -0,0 +1,80 @@
+//===--- SuspiciousMissingCommaCheck.cpp - 
clang-tidy--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "SuspiciousMissingCommaCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+namespace misc {
+
+namespace {
+
+AST_MATCHER(StringLiteral, isConcatenatedLiteral) {
+  return Node.getNumConcatenated() > 1;
+}
+
+}  // namespace
+
+SuspiciousMissingCommaCheck::SuspiciousMissingCommaCheck(
+StringRef Name, ClangTidyContext *Context)
+: ClangTidyCheck(Name, Context),
+  SizeThreshold(Options.get("SizeThreshold", 5U)),
+  RatioThreshold(std::stod(Options.get("RatioThreshold", ".2"))) {}
+
+void SuspiciousMissingCommaCheck::storeOptions(
+ClangTidyOptions::OptionMap ) {
+

Re: [PATCH] D18654: In C++11 it is undefined to shift into the sign bit

2016-03-31 Thread Filipe Cabecinhas via cfe-commits

That means that our C++11 mode will have some fixes, right?
How can we call what out C++11 mode is? Are there updated versions of
the standard? Are there lists of defects that we have fixed and others
we haven't?

Sorry, I'm not too familiar with how the standard+fixes usually work.

Thank you,

  Filipe

On Thu, Mar 31, 2016 at 6:59 PM, Richard Smith via cfe-commits
 wrote:
> rsmith requested changes to this revision.
> rsmith added a comment.
> This revision now requires changes to proceed.
>
> Core issue 1457 is a DR against C++11, so it applies to our C++11 mode.
>
>
> http://reviews.llvm.org/D18654
>
>
>
> ___
> 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] D18654: In C++11 it is undefined to shift into the sign bit

2016-03-31 Thread Filipe Cabecinhas via cfe-commits

filcab added a subscriber: filcab.
filcab added a comment.

That means that our C++11 mode will have some fixes, right?
How can we call what out C++11 mode is? Are there updated versions of
the standard? Are there lists of defects that we have fixed and others
we haven't?

Sorry, I'm not too familiar with how the standard+fixes usually work.

Thank you,

  Filipe


http://reviews.llvm.org/D18654



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

Re: [PATCH] D18653: [Sema] Diagnose template alias declaration in local class

2016-03-31 Thread Richard Smith via cfe-commits

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


Comment at: test/CXX/temp/temp.decls/temp.mem/p2.cpp:11
@@ -10,2 +10,3 @@
 template  void qux(); // expected-error{{templates cannot be 
declared inside of a local class}}
+template  using corge = int; // expected-error{{templates cannot 
be declared inside of a local class}}
   };

Can you add a test for a static data member template too, please?


http://reviews.llvm.org/D18653



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

Re: [PATCH] D18654: In C++11 it is undefined to shift into the sign bit

2016-03-31 Thread Richard Smith via cfe-commits

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

Core issue 1457 is a DR against C++11, so it applies to our C++11 mode.


http://reviews.llvm.org/D18654



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

Re: [PATCH] D18584: Complete support for C++ Core Guidelines Type.6: Always initialize a member variable.

2016-03-31 Thread Michael Miller via cfe-commits

michael_miller updated this revision to Diff 52238.
michael_miller added a comment.

Ran clang-format on all modified source files.


http://reviews.llvm.org/D18584

Files:
  clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.cpp
  clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/cppcoreguidelines-pro-type-member-init.rst
  test/clang-tidy/cppcoreguidelines-pro-type-member-init-cxx98.cpp
  test/clang-tidy/cppcoreguidelines-pro-type-member-init-delayed.cpp
  test/clang-tidy/cppcoreguidelines-pro-type-member-init.cpp

Index: test/clang-tidy/cppcoreguidelines-pro-type-member-init.cpp
===
--- test/clang-tidy/cppcoreguidelines-pro-type-member-init.cpp
+++ test/clang-tidy/cppcoreguidelines-pro-type-member-init.cpp
@@ -4,13 +4,13 @@
   int F;
   // CHECK-FIXES: int F{};
   PositiveFieldBeforeConstructor() {}
-  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize these built-in/pointer fields: F
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize these fields: F
   // CHECK-FIXES: PositiveFieldBeforeConstructor() {}
 };
 
 struct PositiveFieldAfterConstructor {
   PositiveFieldAfterConstructor() {}
-  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize these built-in/pointer fields: F, G
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize these fields: F, G
   // CHECK-FIXES: PositiveFieldAfterConstructor() {}
   int F;
   // CHECK-FIXES: int F{};
@@ -26,12 +26,12 @@
 };
 
 PositiveSeparateDefinition::PositiveSeparateDefinition() {}
-// CHECK-MESSAGES: :[[@LINE-1]]:1: warning: constructor does not initialize these built-in/pointer fields: F
+// CHECK-MESSAGES: :[[@LINE-1]]:1: warning: constructor does not initialize these fields: F
 // CHECK-FIXES: PositiveSeparateDefinition::PositiveSeparateDefinition() {}
 
 struct PositiveMixedFieldOrder {
   PositiveMixedFieldOrder() : J(0) {}
-  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize these built-in/pointer fields: I, K
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize these fields: I, K
   // CHECK-FIXES: PositiveMixedFieldOrder() : J(0) {}
   int I;
   // CHECK-FIXES: int I{};
@@ -43,7 +43,7 @@
 template 
 struct Template {
   Template() {}
-  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize these built-in/pointer fields: F
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize these fields: F
   int F;
   // CHECK-FIXES: int F{};
   T T1;
@@ -67,7 +67,6 @@
 };
 NegativeFieldInitializedInDefinition::NegativeFieldInitializedInDefinition() : F() {}
 
-
 struct NegativeInClassInitialized {
   int F = 0;
 
@@ -87,25 +86,238 @@
 };
 
 #define UNINITIALIZED_FIELD_IN_MACRO_BODY(FIELD) \
-  struct UninitializedField##FIELD {		 \
-UninitializedField##FIELD() {}		 \
-int FIELD;	 \
-  };		 \
+  struct UninitializedField##FIELD { \
+UninitializedField##FIELD() {}   \
+int FIELD;   \
+  }; \
 // Ensure FIELD is not initialized since fixes inside of macros are disabled.
 // CHECK-FIXES: int FIELD;
 
 UNINITIALIZED_FIELD_IN_MACRO_BODY(F);
-// CHECK-MESSAGES: :[[@LINE-1]]:1: warning: constructor does not initialize these built-in/pointer fields: F
+// CHECK-MESSAGES: :[[@LINE-1]]:1: warning: constructor does not initialize these fields: F
 UNINITIALIZED_FIELD_IN_MACRO_BODY(G);
-// CHECK-MESSAGES: :[[@LINE-1]]:1: warning: constructor does not initialize these built-in/pointer fields: G
+// CHECK-MESSAGES: :[[@LINE-1]]:1: warning: constructor does not initialize these fields: G
 
 #define UNINITIALIZED_FIELD_IN_MACRO_ARGUMENT(ARGUMENT) \
-  ARGUMENT		\
+  ARGUMENT
 
 UNINITIALIZED_FIELD_IN_MACRO_ARGUMENT(struct UninitializedFieldInMacroArg {
   UninitializedFieldInMacroArg() {}
   int Field;
 });
-// CHECK-MESSAGES: :[[@LINE-3]]:3: warning: constructor does not initialize these built-in/pointer fields: Field
+// CHECK-MESSAGES: :[[@LINE-3]]:3: warning: constructor does not initialize these fields: Field
 // Ensure FIELD is not initialized since fixes inside of macros are disabled.
 // CHECK-FIXES: int Field;
+
+struct NegativeAggregateType {
+  int X;
+  int Y;
+  int Z;
+};
+
+struct PositiveTrivialType {
+  PositiveTrivialType() {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize these fields: F
+
+  NegativeAggregateType F;
+  // CHECK-FIXES: NegativeAggregateType F{};
+};
+
+struct NegativeNonTrivialType {
+  PositiveTrivialType F;
+};
+
+static void PositiveUninitializedTrivialType() {
+  NegativeAggregateType X;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: uninitialized record type: X
+  // CHECK-FIXES: NegativeAggregateType X{};
+
+  NegativeAggregateType A[10];
+  // Don't warn because this

[PATCH] D18657: Propagate missing empty exception spec from function declared in system header

2016-03-31 Thread Denis Zobnin via cfe-commits

d.zobnin.bugzilla created this revision.
d.zobnin.bugzilla added reviewers: doug.gregor, rjmccall.
d.zobnin.bugzilla added a subscriber: cfe-commits.

If new function is missing empty exception specification "throw()" and 
"throw()" came from system header, don't emit errors. It is already implemented 
in Clang, but taking into account only last redeclaration of a function. Look 
for declaration in system header up to the first declaration in redeclaration 
chain, as GCC seems to do.

This patch enables compilation of Facebook/ds2 application.

http://reviews.llvm.org/D18657

Files:
  lib/Sema/SemaExceptionSpec.cpp
  test/SemaCXX/Inputs/malloc.h
  test/SemaCXX/builtin-exception-spec.cpp

Index: lib/Sema/SemaExceptionSpec.cpp
===
--- lib/Sema/SemaExceptionSpec.cpp
+++ lib/Sema/SemaExceptionSpec.cpp
@@ -254,9 +254,15 @@
   // to many libc functions as an optimization. Unfortunately, that
   // optimization isn't permitted by the C++ standard, so we're forced
   // to work around it here.
-  if (MissingEmptyExceptionSpecification && NewProto &&
-  (Old->getLocation().isInvalid() ||
-   Context.getSourceManager().isInSystemHeader(Old->getLocation())) &&
+  bool IsFromSystemHeader = false;
+  for (const FunctionDecl *Prev = Old; Prev; Prev = Prev->getPreviousDecl())
+if (Prev->getLocation().isInvalid() ||
+Context.getSourceManager().isInSystemHeader(Prev->getLocation())) {
+  IsFromSystemHeader = true;
+  break;
+}
+
+  if (MissingEmptyExceptionSpecification && NewProto && IsFromSystemHeader &&
   Old->isExternC()) {
 New->setType(Context.getFunctionType(
 NewProto->getReturnType(), NewProto->getParamTypes(),
Index: test/SemaCXX/builtin-exception-spec.cpp
===
--- test/SemaCXX/builtin-exception-spec.cpp
+++ test/SemaCXX/builtin-exception-spec.cpp
@@ -4,4 +4,7 @@
 
 extern "C" {
 void *malloc(__SIZE_TYPE__);
+
+void MyFunc() __attribute__((__weak__));
+void MyFunc() { return; }
 }
Index: test/SemaCXX/Inputs/malloc.h
===
--- test/SemaCXX/Inputs/malloc.h
+++ test/SemaCXX/Inputs/malloc.h
@@ -1,3 +1,5 @@
 extern "C" {
 extern void *malloc (__SIZE_TYPE__ __size) throw () __attribute__ 
((__malloc__)) ;
+
+void MyFunc() throw();
 }


Index: lib/Sema/SemaExceptionSpec.cpp
===
--- lib/Sema/SemaExceptionSpec.cpp
+++ lib/Sema/SemaExceptionSpec.cpp
@@ -254,9 +254,15 @@
   // to many libc functions as an optimization. Unfortunately, that
   // optimization isn't permitted by the C++ standard, so we're forced
   // to work around it here.
-  if (MissingEmptyExceptionSpecification && NewProto &&
-  (Old->getLocation().isInvalid() ||
-   Context.getSourceManager().isInSystemHeader(Old->getLocation())) &&
+  bool IsFromSystemHeader = false;
+  for (const FunctionDecl *Prev = Old; Prev; Prev = Prev->getPreviousDecl())
+if (Prev->getLocation().isInvalid() ||
+Context.getSourceManager().isInSystemHeader(Prev->getLocation())) {
+  IsFromSystemHeader = true;
+  break;
+}
+
+  if (MissingEmptyExceptionSpecification && NewProto && IsFromSystemHeader &&
   Old->isExternC()) {
 New->setType(Context.getFunctionType(
 NewProto->getReturnType(), NewProto->getParamTypes(),
Index: test/SemaCXX/builtin-exception-spec.cpp
===
--- test/SemaCXX/builtin-exception-spec.cpp
+++ test/SemaCXX/builtin-exception-spec.cpp
@@ -4,4 +4,7 @@
 
 extern "C" {
 void *malloc(__SIZE_TYPE__);
+
+void MyFunc() __attribute__((__weak__));
+void MyFunc() { return; }
 }
Index: test/SemaCXX/Inputs/malloc.h
===
--- test/SemaCXX/Inputs/malloc.h
+++ test/SemaCXX/Inputs/malloc.h
@@ -1,3 +1,5 @@
 extern "C" {
 extern void *malloc (__SIZE_TYPE__ __size) throw () __attribute__ ((__malloc__)) ;
+
+void MyFunc() throw();
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D18369: [OpenCL] Upstreaming khronos OpenCL 1.2/2.0 header files.

2016-03-31 Thread Yaxun Liu via cfe-commits

yaxunl added a comment.

> Rather than having a separate header for each version with another header for 
> the common parts, couldn't we just have a single header that uses #if guards 
> for the version specific functionality? e.g.

> 

>   size_t __attribute__((overloadable)) get_global_id(uint dim);

>   

>   #if __OPENCL_C_VERSION__ >= 200

>   size_t __attribute__((overloadable)) get_global_linear_id(void);

>   #endif

> 

> 

> This also allows an easy path for having OpenCL 1.1 and 1.0 support without 
> having to add more copies of the header.


I think it is a good idea. It simplifies the file names and organization.


http://reviews.llvm.org/D18369



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

[PATCH] D18654: In C++11 it is undefined to shift into the sign bit

2016-03-31 Thread Filipe Cabecinhas via cfe-commits

filcab created this revision.
filcab added reviewers: rsmith, samsonov.
filcab added a subscriber: cfe-commits.

Clang was using C++14 rules for shifts into the sign bit with any C++
standard. Now it has the C++ <14 special case (same as C).

Using this C++11 standard draft as reference (before CWG 1457):
https://github.com/cplusplus/draft/blob/672675e01528fba6ca02f5340eee747566ebdca8/papers/N3376.pdf

http://reviews.llvm.org/D18654

Files:
  lib/CodeGen/CGExprScalar.cpp
  test/CodeGen/cxx-signed-shift-overflow.cpp
  test/CodeGenCXX/catch-undef-behavior.cpp

Index: test/CodeGenCXX/catch-undef-behavior.cpp
===
--- test/CodeGenCXX/catch-undef-behavior.cpp
+++ test/CodeGenCXX/catch-undef-behavior.cpp
@@ -137,11 +137,7 @@
   // CHECK-NEXT: %[[SHIFTED_OUT_WIDTH:.*]] = sub nuw nsw i32 31, %[[RHS]]
   // CHECK-NEXT: %[[SHIFTED_OUT:.*]] = lshr i32 %[[LHS:.*]], 
%[[SHIFTED_OUT_WIDTH]]
 
-  // This is present for C++11 but not for C: C++ core issue 1457 allows a '1'
-  // to be shifted into the sign bit, but not out of it.
-  // CHECK-NEXT: %[[SHIFTED_OUT_NOT_SIGN:.*]] = lshr i32 %[[SHIFTED_OUT]], 1
-
-  // CHECK-NEXT: %[[NO_OVERFLOW:.*]] = icmp eq i32 %[[SHIFTED_OUT_NOT_SIGN]], 0
+  // CHECK-NEXT: %[[NO_OVERFLOW:.*]] = icmp eq i32 %[[SHIFTED_OUT]], 0
   // CHECK-NEXT: br label %[[CONT_BB]]
 
   // CHECK:  [[CONT_BB]]:
Index: test/CodeGen/cxx-signed-shift-overflow.cpp
===
--- /dev/null
+++ test/CodeGen/cxx-signed-shift-overflow.cpp
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -std=c++11 -triple x86_64-apple-darwin10 
-fsanitize=shift-base %s -emit-llvm -o - | FileCheck %s -check-prefix=CXX11 
-check-prefix=BOTH
+// RUN: %clang_cc1 -std=c++14 -triple x86_64-apple-darwin10 
-fsanitize=shift-base %s -emit-llvm -o - | FileCheck %s -check-prefix=CXX14 
-check-prefix=BOTH
+
+int shiftoverflow(int b, int e) {
+  // BOTH-LABEL: shiftoverflow
+  // CXX14-LABEL: check:
+  // CXX14: %shl.check = lshr
+  // CXX14: lshr i{{[^ ]*}} %shl.check, 1
+  // CXX11-LABEL: check:
+  // CXX11: %shl.check = lshr
+  // CXX11-NOT: lshr i{{[^ ]*}} %shl.check, 1
+  return b << e;
+}
Index: lib/CodeGen/CGExprScalar.cpp
===
--- lib/CodeGen/CGExprScalar.cpp
+++ lib/CodeGen/CGExprScalar.cpp
@@ -2746,11 +2746,12 @@
Builder.CreateSub(WidthMinusOne, RHS, "shl.zeros",
  /*NUW*/true, /*NSW*/true),
"shl.check");
-  if (CGF.getLangOpts().CPlusPlus) {
-// In C99, we are not permitted to shift a 1 bit into the sign bit.
-// Under C++11's rules, shifting a 1 bit into the sign bit is
-// OK, but shifting a 1 bit out of it is not. (C89 and C++03 don't
-// define signed left shifts, so we use the C99 and C++11 rules there).
+  if (CGF.getLangOpts().CPlusPlus && CGF.getLangOpts().CPlusPlus14) {
+// In C99 and C++11, we are not permitted to shift a 1 bit into the 
sign
+// bit.
+// Under C++14's rules, shifting a 1 bit into the sign bit is OK, but
+// shifting a 1 bit out of it is not. (C89 and C++03 don't define 
signed
+// left shifts, so we use the C99 and C++11 rules there).
 llvm::Value *One = llvm::ConstantInt::get(BitsShiftedOff->getType(), 
1);
 BitsShiftedOff = Builder.CreateLShr(BitsShiftedOff, One);
   }


Index: test/CodeGenCXX/catch-undef-behavior.cpp
===
--- test/CodeGenCXX/catch-undef-behavior.cpp
+++ test/CodeGenCXX/catch-undef-behavior.cpp
@@ -137,11 +137,7 @@
   // CHECK-NEXT: %[[SHIFTED_OUT_WIDTH:.*]] = sub nuw nsw i32 31, %[[RHS]]
   // CHECK-NEXT: %[[SHIFTED_OUT:.*]] = lshr i32 %[[LHS:.*]], %[[SHIFTED_OUT_WIDTH]]
 
-  // This is present for C++11 but not for C: C++ core issue 1457 allows a '1'
-  // to be shifted into the sign bit, but not out of it.
-  // CHECK-NEXT: %[[SHIFTED_OUT_NOT_SIGN:.*]] = lshr i32 %[[SHIFTED_OUT]], 1
-
-  // CHECK-NEXT: %[[NO_OVERFLOW:.*]] = icmp eq i32 %[[SHIFTED_OUT_NOT_SIGN]], 0
+  // CHECK-NEXT: %[[NO_OVERFLOW:.*]] = icmp eq i32 %[[SHIFTED_OUT]], 0
   // CHECK-NEXT: br label %[[CONT_BB]]
 
   // CHECK:  [[CONT_BB]]:
Index: test/CodeGen/cxx-signed-shift-overflow.cpp
===
--- /dev/null
+++ test/CodeGen/cxx-signed-shift-overflow.cpp
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -std=c++11 -triple x86_64-apple-darwin10 -fsanitize=shift-base %s -emit-llvm -o - | FileCheck %s -check-prefix=CXX11 -check-prefix=BOTH
+// RUN: %clang_cc1 -std=c++14 -triple x86_64-apple-darwin10 -fsanitize=shift-base %s -emit-llvm -o - | FileCheck %s -check-prefix=CXX14 -check-prefix=BOTH
+
+int shiftoverflow(int b, int e) {
+  // BOTH-LABEL: shiftoverflow
+  // CXX14-LABEL: check:
+  // CXX14: %shl.check = lshr
+  // CXX14: lshr i{{[^

Re: [PATCH] D18649: [clang-tidy] cppcoreguidelines-interfaces-global-init

2016-03-31 Thread Eugene Zelenko via cfe-commits

Eugene.Zelenko added a subscriber: Eugene.Zelenko.
Eugene.Zelenko added a comment.

Please mention new check in docs/ReleaseNotes.rst.


http://reviews.llvm.org/D18649



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

Re: [PATCH] D18567: Block: Fix a crash when we have type attributes or qualifiers with omitted return type.

2016-03-31 Thread John McCall via cfe-commits

rjmccall added inline comments.


Comment at: lib/Sema/SemaType.cpp:1569
@@ +1568,3 @@
+// Mark them as invalid.
+attr.setInvalid();
+  }

manmanren wrote:
> rjmccall wrote:
> > It's not generally a good idea to set things as invalid if you're just 
> > emitting a warning.  It might be different for parsed AttributeList 
> > objects, but... I'm not sure about that.
> Here we mark the AttributeList as invalid so when we call processTypeAttrs 
> later, we will ignore these attributes, instead of creating AttributedType 
> based on DependentTy for omitted block return type.
I'm just worried that there might be code which suppresses *error* diagnostics 
(or semantic analysis) when it sees an invalid attribute.  Like I said, though, 
that might not be a problem for AttributeList.


Comment at: test/SemaOpenCL/invalid-block.cl:9
@@ -8,3 +8,3 @@
   int (^const bl2)(); // expected-error{{invalid block variable declaration - 
must be initialized}}
-  int (^const bl3)() = ^const(){
+  int (^const bl3)() = ^(){ // expected-error{{incompatible block pointer 
types initializing 'int (^const)()' with an expression of type 'void 
(^)(void)'}}
   };

Anastasia wrote:
> Anastasia wrote:
> > I think this test had a bug initially (multiple actually!). It was meant to 
> > initialize with int(^)() expression. Could you please add an int return so 
> > that this line has no error. 
> I am not getting why this error didn't appear before your change. How does 
> your change trigger this error now, as you seem to be only changing the 
> attributes and not the deduced block type...
Probably because of the unfortunate choice in block semantic analysis to use 
DependentTy as the marker for an unspecified block result type rather than some 
other placeholder type (like the undeduced-auto placeholder).  This will cause 
the block to have a dependent type and basically disable a lot of downstream 
analysis if, as here, the placeholder is never actually replaced.


Comment at: test/SemaOpenCL/invalid-block.cl:39
@@ -38,3 +38,3 @@
 void f5(int i) {
-  bl1_t bl1 = ^const(int i) {return 1;};
-  bl1_t bl2 = ^const(int i) {return 2;};
+  bl1_t bl1 = ^(int i) {return 1;};
+  bl1_t bl2 = ^(int i) {return 2;};

Anastasia wrote:
> So the return type is deduced to be int for this block expression here?
Yes.  Block return types are deduced according to the types of the operands of 
the return statements within the block.  The deduction rule is somewhat more 
permissive / complex than the lambda deduction rule.


http://reviews.llvm.org/D18567



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

Re: [PATCH] D18596: [MSVC] PR27132: Proper mangling for __unaligned qualifier

2016-03-31 Thread Aaron Ballman via cfe-commits

aaron.ballman added a comment.

In http://reviews.llvm.org/D18596#388148, @andreybokhanko wrote:

> Aaron, Reid, David, thank you for the review!
>
> I resolved some of your comments. As for
>
> In http://reviews.llvm.org/D18596#386841, @aaron.ballman wrote:
>
> > I'd like to see some Sema tests for sanity checking; like applying 
> > __unaligned to a non-pointer type, to a declaration, when 
> > -fno-ms-extensions is enabled, etc.
>
>
> Do we want to accept __unaligned for non-pointer types, as MS compiler does? 
> Their doc (https://msdn.microsoft.com/en-us/library/ms177389.aspx) only 
> mentions pointers, but cl.exe also accepts non-pointers with __unaligned, 
> with no visible effect to generated code (including mangling). Clang 
> currently does accept this, so starting to issue an error would be a 
> regression.

Regression is a bit of a question mark, to me depending on the diagnostic. I 
think warning the user "this has absolutely no effect" is a reasonable 
diagnostic for that situation -- the user wrote something, possibly expecting 
it to have an effect, and it turns out that it does absolutely nothing 
(including in the compiler that implements the language extension). If MSVC 
were to ever add semantic effect in those cases (diverging from what Clang 
implements), the diagnostic becomes even more important for Clang users. So I 
think it's fine to accept __unaligned for non-pointer types, but issue an 
"attribute ignored" warning diagnostic.

http://reviews.llvm.org/D18596

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

Re: [PATCH] D18457: [clang-tidy] Add a new checker to detect missing comma in initializer list.

2016-03-31 Thread Etienne Bergeron via cfe-commits

etienneb added a comment.

ready to land.



Comment at: clang-tidy/misc/SuspiciousMissingCommaCheck.cpp:75
@@ +74,3 @@
+  diag(ConcatenatedLiteral->getLocStart(),
+   "suspicious string literal, probably missing a comma");
+}

alexfh wrote:
> xazax.hun wrote:
> > alexfh wrote:
> > > We need to add a recommendation on how to silence this warning (use 
> > > parentheses, for example). Fine for a follow up.
> > A possible way to silence this warning would be to implement a heuristic 
> > that is available in szdominik's implementation, i.e.: when the size of the 
> > array is explicitly given by the user and it matches the length of the 
> > initializer list do not warn.
> The check shouldn't complain in this case, but I wouldn't recommend this as a 
> fix, since it makes the code more strict in an inconvenient way.
I'll provide the recommendation when it will be implemented. Next patch.


Comment at: clang-tidy/misc/SuspiciousMissingCommaCheck.cpp:75
@@ +74,3 @@
+  diag(ConcatenatedLiteral->getLocStart(),
+   "suspicious string literal, probably missing a comma");
+}

etienneb wrote:
> alexfh wrote:
> > xazax.hun wrote:
> > > alexfh wrote:
> > > > We need to add a recommendation on how to silence this warning (use 
> > > > parentheses, for example). Fine for a follow up.
> > > A possible way to silence this warning would be to implement a heuristic 
> > > that is available in szdominik's implementation, i.e.: when the size of 
> > > the array is explicitly given by the user and it matches the length of 
> > > the initializer list do not warn.
> > The check shouldn't complain in this case, but I wouldn't recommend this as 
> > a fix, since it makes the code more strict in an inconvenient way.
> I'll provide the recommendation when it will be implemented. Next patch.
in case of a fixed array size, the algorithm could be more aggressive.
Feel free to push a patch for this.

I don't believe it's quite common to set the size for string literals. If you 
have example for it, please share it.


http://reviews.llvm.org/D18457



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

Re: [PATCH] D18396: Clang-tidy:modernize-use-override. Fix for __declspec attributes and const=0 without spacse

2016-03-31 Thread Robert Bolter via cfe-commits

Rob updated this revision to Diff 52227.
Rob added a comment.

I tried

  check_clang_tidy.py modernize-use-override-ms.cpp modernize-use-override temp 
-- -- -fms-extensions

and

  check_clang_tidy.py modernize-use-override-ms.cpp modernize-use-override temp 

on OSX and nethier work as expected.

So instead I have changed the test to use visibility attributes when _MSC_VER 
is not defined.

Also updated the release notes.


http://reviews.llvm.org/D18396

Files:
  clang-tidy/modernize/UseOverrideCheck.cpp
  docs/ReleaseNotes.rst
  test/clang-tidy/modernize-use-override-ms.cpp
  test/clang-tidy/modernize-use-override.cpp

Index: test/clang-tidy/modernize-use-override.cpp
===
--- test/clang-tidy/modernize-use-override.cpp
+++ test/clang-tidy/modernize-use-override.cpp
@@ -21,6 +21,7 @@
   virtual void d2();
   virtual void e() = 0;
   virtual void f() = 0;
+  virtual void f2() const = 0;
   virtual void g() = 0;
 
   virtual void j() const;
@@ -74,7 +75,11 @@
 
   virtual void f()=0;
   // CHECK-MESSAGES: :[[@LINE-1]]:16: warning: prefer using
-  // CHECK-FIXES: {{^}}  void f()override =0;
+  // CHECK-FIXES: {{^}}  void f() override =0;
+
+  virtual void f2() const=0;
+  // CHECK-MESSAGES: :[[@LINE-1]]:16: warning: prefer using
+  // CHECK-FIXES: {{^}}  void f2() const override =0;
 
   virtual void g() ABSTRACT;
   // CHECK-MESSAGES: :[[@LINE-1]]:16: warning: prefer using
Index: test/clang-tidy/modernize-use-override-ms.cpp
===
--- /dev/null
+++ test/clang-tidy/modernize-use-override-ms.cpp
@@ -0,0 +1,30 @@
+// RUN: %check_clang_tidy %s modernize-use-override %t -- -- -fms-extensions
+
+// This test is designed to test ms-extension __declspec(dllexport) attributes.
+// On non-windows platforms these are not available so we test visibility attributes instead.
+#if defined(_MSC_VER)
+#  define EXPORT __declspec(dllexport)
+#else
+#  define EXPORT __attribute__((visibility("default")))
+#endif
+
+class Base {
+  virtual EXPORT void a();
+};
+
+class EXPORT InheritedBase {
+  virtual void a();
+};
+
+class Derived : public Base {
+  virtual EXPORT void a();
+  // CHECK-MESSAGES: :[[@LINE-1]]:23: warning: prefer using 'override' or (rarely) 'final' instead of 'virtual' [modernize-use-override]
+  // CHECK-FIXES: {{^}}  EXPORT void a() override;
+};
+
+class EXPORT InheritedDerived : public InheritedBase {
+  virtual void a();
+  // CHECK-MESSAGES: :[[@LINE-1]]:16: warning: prefer using 'override' or (rarely) 'final' instead of 'virtual' [modernize-use-override]
+  // CHECK-FIXES: {{^}}  void a() override;
+};
+
Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -67,6 +67,12 @@
 
   This check selectively replaces string literals containing escaped
   characters with raw string literals.
+  
+- Improved ``modernize-use-override`` check
+
+  The fix-its placement around __declspec attributes on windows and other 
+  attributes is improved.
+  
 
 Clang-tidy changes from 3.7 to 3.8
 ^^
Index: clang-tidy/modernize/UseOverrideCheck.cpp
===
--- clang-tidy/modernize/UseOverrideCheck.cpp
+++ clang-tidy/modernize/UseOverrideCheck.cpp
@@ -95,9 +95,9 @@
: "'override' is";
 StringRef Correct = HasFinal ? "'final'" : "'override'";
 
-Message =
-(llvm::Twine(Redundant) +
- " redundant since the function is already declared " + Correct).str();
+Message = (llvm::Twine(Redundant) +
+   " redundant since the function is already declared " + Correct)
+  .str();
   }
 
   DiagnosticBuilder Diag = diag(Method->getLocation(), Message);
@@ -118,21 +118,24 @@
   if (!HasFinal && !HasOverride) {
 SourceLocation InsertLoc;
 StringRef ReplacementText = "override ";
+SourceLocation MethodLoc = Method->getLocation();
 
 for (Token T : Tokens) {
-  if (T.is(tok::kw___attribute)) {
+  if (T.is(tok::kw___attribute) &&
+  !Sources.isBeforeInTranslationUnit(T.getLocation(), MethodLoc)) {
 InsertLoc = T.getLocation();
 break;
   }
 }
 
 if (Method->hasAttrs()) {
   for (const clang::Attr *A : Method->getAttrs()) {
-if (!A->isImplicit()) {
+if (!A->isImplicit() && !A->isInherited()) {
   SourceLocation Loc =
   Sources.getExpansionLoc(A->getRange().getBegin());
-  if (!InsertLoc.isValid() ||
-  Sources.isBeforeInTranslationUnit(Loc, InsertLoc))
+  if ((!InsertLoc.isValid() ||
+   Sources.isBeforeInTranslationUnit(Loc, InsertLoc)) &&
+  !Sources.isBeforeInTranslationUnit(Loc, MethodLoc))
 InsertLoc = Loc;
 }
   }
@@ -163,6 +166,9 @@

Re: [PATCH] D18651: [X86] Introduction of -march=lakemont

2016-03-31 Thread Andrey Turetskiy via cfe-commits

aturetsk added a comment.

I used existing test "test/CodeGen/attr-target-x86.c" to check Lakemont's 
target features. However the test is actually run with 64-bit triple 
"x86_64-linux-gnu", so "+mmx,+sse,+sse2" are included in target features. The 
same thing happens with Pentium and other 32-bit-only CPUs. I wonder if we 
should have some check so that 32-bit-only CPUs couldn't be used with 64-bit 
triple. What do you think?


http://reviews.llvm.org/D18651



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

Re: [PATCH] D18457: [clang-tidy] Add a new checker to detect missing comma in initializer list.

2016-03-31 Thread Etienne Bergeron via cfe-commits

etienneb updated this revision to Diff 52226.
etienneb added a comment.

nits


http://reviews.llvm.org/D18457

Files:
  clang-tidy/misc/CMakeLists.txt
  clang-tidy/misc/MiscTidyModule.cpp
  clang-tidy/misc/SuspiciousMissingCommaCheck.cpp
  clang-tidy/misc/SuspiciousMissingCommaCheck.h
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/misc-suspicious-missing-comma.rst
  test/clang-tidy/misc-suspicious-missing-comma.cpp

Index: test/clang-tidy/misc-suspicious-missing-comma.cpp
===
--- /dev/null
+++ test/clang-tidy/misc-suspicious-missing-comma.cpp
@@ -0,0 +1,34 @@
+// RUN: %check_clang_tidy %s misc-suspicious-missing-comma %t
+
+const char* Cartoons[] = {
+  "Bugs Bunny",
+  "Homer Simpson",
+  "Mickey Mouse",
+  "Bart Simpson",
+  "Charlie Brown"  // There is a missing comma here.
+  "Fred Flintstone",
+  "Popeye",
+};
+// CHECK-MESSAGES: :[[@LINE-4]]:3: warning: suspicious string literal, probably missing a comma [misc-suspicious-missing-comma]
+
+const wchar_t* Colors[] = {
+  L"Red", L"Yellow", L"Blue", L"Green", L"Purple", L"Rose", L"White", L"Black"
+};
+
+// The following array should not trigger any warnings.
+const char* HttpCommands[] = {
+  "GET / HTTP/1.0\r\n"
+  "\r\n",
+
+  "GET /index.html HTTP/1.0\r\n"
+  "\r\n",
+
+  "GET /favicon.ico HTTP/1.0\r\n"
+  "header: dummy"
+  "\r\n",
+};
+
+// This array is too small to trigger a warning.
+const char* SmallArray[] = {
+  "a" "b", "c"
+};
Index: docs/clang-tidy/checks/misc-suspicious-missing-comma.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/misc-suspicious-missing-comma.rst
@@ -0,0 +1,35 @@
+.. title:: clang-tidy - misc-suspicious-missing-comma
+
+misc-suspicious-missing-comma
+=
+
+String literals placed side-by-side are concatenated at translation phase 6
+(after the preprocessor). This feature is used to represent long string
+literal on multiple lines.
+
+For instance, these declarations are equivalent:
+  const char* A[] = "This is a test";
+  const char* B[] = "This" " is a "
+"test";
+
+A common mistake done by programmers is to forget a comma between two string
+literals in an array initializer list.
+
+  const char* Test[] = {
+"line 1",
+"line 2" // Missing comma!
+"line 3",
+"line 4",
+"line 5"
+  };
+
+The array contains the string "line 2line3" at offset 1 (i.e. Test[1]). Clang
+won't generate warnings at compile time.
+
+This checker may warn incorrectly on cases like:
+
+  const char* SupportedFormat[] = {
+"Error %s",
+"Code " PRIu64,   // May warn here.
+"Warning %s",
+  };
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -66,6 +66,7 @@
misc-sizeof-container
misc-static-assert
misc-string-integer-assignment
+   misc-suspicious-missing-comma
misc-suspicious-semicolon
misc-swapped-arguments
misc-throw-by-value-catch-by-reference
Index: clang-tidy/misc/SuspiciousMissingCommaCheck.h
===
--- /dev/null
+++ clang-tidy/misc/SuspiciousMissingCommaCheck.h
@@ -0,0 +1,41 @@
+//===--- SuspiciousMissingCommaCheck.h - clang-tidy--*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_SUSPICIOUS_MISSING_COMMA_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_SUSPICIOUS_MISSING_COMMA_H
+
+#include "../ClangTidy.h"
+
+namespace clang {
+namespace tidy {
+namespace misc {
+
+/// This check finds string literals which are probably concatenated accidentally.
+///
+/// For the user-facing documentation see:
+/// http://clang.llvm.org/extra/clang-tidy/checks/misc-suspicious-missing-comma.html
+class SuspiciousMissingCommaCheck : public ClangTidyCheck {
+public:
+  SuspiciousMissingCommaCheck(StringRef Name, ClangTidyContext *Context);
+  void storeOptions(ClangTidyOptions::OptionMap ) override;  
+  void registerMatchers(ast_matchers::MatchFinder *Finder) override;
+  void check(const ast_matchers::MatchFinder::MatchResult ) override;
+
+private:
+  // Minimal size of a string literals array to be considered by the checker.
+  const unsigned SizeThreshold;
+  // Maximal threshold ratio of suspicious string literals to be considered.
+  const double RatioThreshold;
+};
+
+} // namespace misc
+} // namespace tidy
+} // namespace clang
+
+#endif // LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_SUSPICIOUS_MISSING_COMMA_H
Index: clang-tidy/misc/SuspiciousMissingCommaCheck.cpp

Re: [PATCH] D18457: [clang-tidy] Add a new checker to detect missing comma in initializer list.

2016-03-31 Thread Etienne Bergeron via cfe-commits

etienneb updated this revision to Diff 52225.
etienneb marked 5 inline comments as done.
etienneb added a comment.

address alexfh@ comments.


http://reviews.llvm.org/D18457

Files:
  clang-tidy/misc/CMakeLists.txt
  clang-tidy/misc/MiscTidyModule.cpp
  clang-tidy/misc/SuspiciousMissingCommaCheck.cpp
  clang-tidy/misc/SuspiciousMissingCommaCheck.h
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/misc-suspicious-missing-comma.rst
  test/clang-tidy/misc-suspicious-missing-comma.cpp

Index: test/clang-tidy/misc-suspicious-missing-comma.cpp
===
--- /dev/null
+++ test/clang-tidy/misc-suspicious-missing-comma.cpp
@@ -0,0 +1,34 @@
+// RUN: %check_clang_tidy %s misc-suspicious-missing-comma %t
+
+const char* Cartoons[] = {
+  "Bugs Bunny",
+  "Homer Simpson",
+  "Mickey Mouse",
+  "Bart Simpson",
+  "Charlie Brown"  // There is a missing comma here.
+  "Fred Flintstone",
+  "Popeye",
+};
+// CHECK-MESSAGES: :[[@LINE-4]]:3: warning: suspicious string literal, probably missing a comma [misc-suspicious-missing-comma]
+
+const wchar_t* Colors[] = {
+  L"Red", L"Yellow", L"Blue", L"Green", L"Purple", L"Rose", L"White", L"Black"
+};
+
+// The following array should not trigger any warnings.
+const char* HttpCommands[] = {
+  "GET / HTTP/1.0\r\n"
+  "\r\n",
+
+  "GET /index.html HTTP/1.0\r\n"
+  "\r\n",
+
+  "GET /favicon.ico HTTP/1.0\r\n"
+  "header: dummy"
+  "\r\n",
+};
+
+// This array is too small to trigger a warning.
+const char* SmallArray[] = {
+  "a" "b", "c"
+};
Index: docs/clang-tidy/checks/misc-suspicious-missing-comma.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/misc-suspicious-missing-comma.rst
@@ -0,0 +1,35 @@
+.. title:: clang-tidy - misc-suspicious-missing-comma
+
+misc-suspicious-missing-comma
+=
+
+String literals placed side-by-side are concatenated at translation phase 6
+(after the preprocessor). This feature is used to represent long string
+literal on multiple lines.
+
+For instance, these declarations are equivalent:
+  const char* A[] = "This is a test";
+  const char* B[] = "This" " is a "
+"test";
+
+A common mistake done by programmers is to forget a comma between two string
+literals in an array initializer list.
+
+  const char* Test[] = {
+"line 1",
+"line 2" // Missing comma!
+"line 3",
+"line 4",
+"line 5"
+  };
+
+The array contains the string "line 2line3" at offset 1 (i.e. Test[1]). Clang
+won't generate warnings at compile time.
+
+This checker may warn incorrectly on cases like:
+
+  const char* SupportedFormat[] = {
+"Error %s",
+"Code " PRIu64,   // May warn here.
+"Warning %s",
+  };
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -66,6 +66,7 @@
misc-sizeof-container
misc-static-assert
misc-string-integer-assignment
+   misc-suspicious-missing-comma
misc-suspicious-semicolon
misc-swapped-arguments
misc-throw-by-value-catch-by-reference
Index: clang-tidy/misc/SuspiciousMissingCommaCheck.h
===
--- /dev/null
+++ clang-tidy/misc/SuspiciousMissingCommaCheck.h
@@ -0,0 +1,41 @@
+//===--- SuspiciousMissingCommaCheck.h - clang-tidy--*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_SUSPICIOUS_MISSING_COMMA_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_SUSPICIOUS_MISSING_COMMA_H
+
+#include "../ClangTidy.h"
+
+namespace clang {
+namespace tidy {
+namespace misc {
+
+/// This check finds string literals which are probably concatenated accidentally.
+///
+/// For the user-facing documentation see:
+/// http://clang.llvm.org/extra/clang-tidy/checks/misc-suspicious-missing-comma.html
+class SuspiciousMissingCommaCheck : public ClangTidyCheck {
+public:
+  SuspiciousMissingCommaCheck(StringRef Name, ClangTidyContext *Context);
+  void storeOptions(ClangTidyOptions::OptionMap ) override;  
+  void registerMatchers(ast_matchers::MatchFinder *Finder) override;
+  void check(const ast_matchers::MatchFinder::MatchResult ) override;
+
+private:
+  // Minimal size of an string literals array to be considered by the checker.
+  const unsigned SizeThreshold;
+  // Maximal threshold ratio of suspicious string literals to be considered.
+  const double RatioThreshold;
+};
+
+} // namespace misc
+} // namespace tidy
+} // namespace clang
+
+#endif // LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_SUSPICIOUS_MISSING_COMMA_H
Index:

[PATCH] D18652: [Inline asm] Correctly parse GCC-style asm line following MS-style asm line

2016-03-31 Thread Denis Zobnin via cfe-commits

d.zobnin.bugzilla created this revision.
d.zobnin.bugzilla added a reviewer: echristo.
d.zobnin.bugzilla added a subscriber: cfe-commits.

Clang fails to compile the following code:

void f() {
  __asm mov ebx, ecx
  __asm__("movl %ecx, %edx");
}

reporting unexpected token "__asm__" at start of statement.
Quit parsing MS-style assembly if the following statement has GCC style to 
handle such code.

http://reviews.llvm.org/D18652

Files:
  lib/Parse/ParseStmtAsm.cpp
  test/CodeGen/inline-asm-mixed-style.c

Index: lib/Parse/ParseStmtAsm.cpp
===
--- lib/Parse/ParseStmtAsm.cpp
+++ lib/Parse/ParseStmtAsm.cpp
@@ -417,9 +417,10 @@
 // If this is a single-line __asm, we're done, except if the next
 // line begins with an __asm too, in which case we finish a comment
 // if needed and then keep processing the next line as a single
-// line __asm.
+// line __asm. Also break if the next __asm is followed by an '(' -
+// GCC-style asm.
 bool isAsm = Tok.is(tok::kw_asm);
-if (SingleLineMode && !isAsm)
+if (SingleLineMode && (!isAsm || NextToken().is(tok::l_paren)))
   break;
 // We're no longer in a comment.
 InAsmComment = false;
Index: test/CodeGen/inline-asm-mixed-style.c
===
--- test/CodeGen/inline-asm-mixed-style.c
+++ test/CodeGen/inline-asm-mixed-style.c
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -triple i386-unknown-unknown -fasm-blocks -fsyntax-only 
-verify %s
+// expected-no-diagnostics
+// RUN: %clang_cc1 -triple i386-unknown-unknown -fasm-blocks -emit-llvm -S %s 
-o - | FileCheck %s
+
+void f() {
+  __asm mov eax, ebx
+  __asm mov ebx, ecx
+  __asm__("movl %ecx, %edx");
+
+  // CHECK: movl%ebx, %eax
+  // CHECK: movl%ecx, %ebx
+  // CHECK: movl%ecx, %edx
+}


Index: lib/Parse/ParseStmtAsm.cpp
===
--- lib/Parse/ParseStmtAsm.cpp
+++ lib/Parse/ParseStmtAsm.cpp
@@ -417,9 +417,10 @@
 // If this is a single-line __asm, we're done, except if the next
 // line begins with an __asm too, in which case we finish a comment
 // if needed and then keep processing the next line as a single
-// line __asm.
+// line __asm. Also break if the next __asm is followed by an '(' -
+// GCC-style asm.
 bool isAsm = Tok.is(tok::kw_asm);
-if (SingleLineMode && !isAsm)
+if (SingleLineMode && (!isAsm || NextToken().is(tok::l_paren)))
   break;
 // We're no longer in a comment.
 InAsmComment = false;
Index: test/CodeGen/inline-asm-mixed-style.c
===
--- test/CodeGen/inline-asm-mixed-style.c
+++ test/CodeGen/inline-asm-mixed-style.c
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -triple i386-unknown-unknown -fasm-blocks -fsyntax-only -verify %s
+// expected-no-diagnostics
+// RUN: %clang_cc1 -triple i386-unknown-unknown -fasm-blocks -emit-llvm -S %s -o - | FileCheck %s
+
+void f() {
+  __asm mov eax, ebx
+  __asm mov ebx, ecx
+  __asm__("movl %ecx, %edx");
+
+  // CHECK: movl%ebx, %eax
+  // CHECK: movl%ecx, %ebx
+  // CHECK: movl%ecx, %edx
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D18542: [OPENMP] Parsing and Sema support for 'omp declare target' directive

2016-03-31 Thread Aaron Ballman via cfe-commits

aaron.ballman added a comment.

In http://reviews.llvm.org/D18542#387934, @DmitryPolukhin wrote:

> Could you please take a look to OMPDeclareTargetDecl attribute implementation 
> and printPrettyEnd approach in general?
>  For post print mechanism alternative approach is to use ad hoc solution in 
> DeclPrinter.

Attributes are meant to be wholly-contained entities syntactically, so I'm not 
entirely comfortable with the notion of an attribute having an "ending" because 
that breaks the model. However, pragmas and statement-level attributes are 
examples of attribute constructs that sometimes want to be paired together, so 
I see utility in the overall idea. I sort of feel like what we need is the 
notion of grouping related attributes together (we already need this for mutual 
exclusion of attributes, but I see no reason why it couldn't also cover mutual 
inclusion). Then pretty printing has a natural place for "end" logic within 
this declarative container.

If you don't feel like doing all that design work (which I'm not attempting to 
sign you up for!), I think the ad hoc solution may be preferable to the 
proposed approach. Do you intend to add several more pragmas that need this 
same sort of behavior, or is this a one-off?

Comment at: include/clang/Basic/Attr.td:2250
@@ +2249,3 @@
+def OMPDeclareTargetDecl : Attr {
+  // This attribute has no spellings as it is only ever created implicitly.
+  let Spellings = [Pragma<"omp", "declare target", "end declare target">];

It's a bit odd to say it has no spellings and then give it a spelling list. ;-)

http://reviews.llvm.org/D18542

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

[PATCH] D18651: [X86] Introduction of -march=lakemont

2016-03-31 Thread Andrey Turetskiy via cfe-commits

aturetsk created this revision.
aturetsk added reviewers: rsmith, echristo.
aturetsk added subscribers: cfe-commits, zinovy.nis.

Add a new CPU - Lakemont.

http://reviews.llvm.org/D18651

Files:
  lib/Basic/Targets.cpp
  test/CodeGen/attr-target-x86.c
  test/Preprocessor/predefined-arch-macros.c

Index: test/Preprocessor/predefined-arch-macros.c
===
--- test/Preprocessor/predefined-arch-macros.c
+++ test/Preprocessor/predefined-arch-macros.c
@@ -1004,6 +1004,18 @@
 // CHECK_SLM_M64: #define __x86_64 1
 // CHECK_SLM_M64: #define __x86_64__ 1
 //
+// RUN: %clang -march=lakemont -m32 -E -dM %s -o - 2>&1 \
+// RUN: -target i386-unknown-linux \
+// RUN:   | FileCheck %s -check-prefix=CHECK_LMT_M32
+// CHECK_LMT_M32: #define __i386 1
+// CHECK_LMT_M32: #define __i386__ 1
+// CHECK_LMT_M32: #define __tune_lakemont__ 1
+// CHECK_LMT_M32: #define i386 1
+// RUN: not %clang -march=lakemont -m64 -E -dM %s -o - 2>&1 \
+// RUN: -target i386-unknown-linux \
+// RUN:   | FileCheck %s -check-prefix=CHECK_LMT_M64
+// CHECK_LMT_M64: error:
+//
 // RUN: %clang -march=geode -m32 -E -dM %s -o - 2>&1 \
 // RUN: -target i386-unknown-linux \
 // RUN:   | FileCheck %s -check-prefix=CHECK_GEODE_M32
Index: test/CodeGen/attr-target-x86.c
===
--- test/CodeGen/attr-target-x86.c
+++ test/CodeGen/attr-target-x86.c
@@ -18,6 +18,8 @@
 
 int __attribute__((target("no-mmx"))) qq(int a) { return 40; }
 
+int __attribute__((target("arch=lakemont"))) lake(int a) { return 4; }
+
 // Check that we emit the additional subtarget and cpu features for foo and not for baz or bar.
 // CHECK: baz{{.*}} #0
 // CHECK: foo{{.*}} #1
@@ -31,9 +33,11 @@
 // CHECK: qux{{.*}} #1
 // CHECK: qax{{.*}} #4
 // CHECK: qq{{.*}} #5
+// CHECK: lake{{.*}} #6
 // CHECK: #0 = {{.*}}"target-cpu"="x86-64" "target-features"="+fxsr,+mmx,+sse,+sse2,+x87"
 // CHECK: #1 = {{.*}}"target-cpu"="ivybridge" "target-features"="+aes,+avx,+cx16,+f16c,+fsgsbase,+fxsr,+mmx,+pclmul,+popcnt,+rdrnd,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3,+x87,+xsave,+xsaveopt"
 // CHECK: #2 = {{.*}}"target-cpu"="x86-64" "target-features"="+fxsr,+mmx,+sse,+x87,-aes,-avx,-avx2,-avx512bw,-avx512cd,-avx512dq,-avx512er,-avx512f,-avx512ifma,-avx512pf,-avx512vbmi,-avx512vl,-f16c,-fma,-fma4,-pclmul,-sha,-sse2,-sse3,-sse4.1,-sse4.2,-sse4a,-ssse3,-xop,-xsave,-xsaveopt"
 // CHECK: #3 = {{.*}}"target-cpu"="x86-64" "target-features"="+fxsr,+mmx,+popcnt,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3,+x87"
 // CHECK: #4 = {{.*}}"target-cpu"="ivybridge" "target-features"="+avx,+cx16,+f16c,+fsgsbase,+fxsr,+mmx,+pclmul,+popcnt,+rdrnd,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3,+x87,+xsave,+xsaveopt,-aes"
 // CHECK: #5 = {{.*}}"target-cpu"="x86-64" "target-features"="+fxsr,+sse,+sse2,+x87,-3dnow,-3dnowa,-mmx"
+// CHECK: #6 = {{.*}}"target-cpu"="lakemont" "target-features"="+mmx,+sse,+sse2"
Index: lib/Basic/Targets.cpp
===
--- lib/Basic/Targets.cpp
+++ lib/Basic/Targets.cpp
@@ -2236,6 +2236,10 @@
 /// Knights Landing processor.
 CK_KNL,
 
+/// \name Lakemont
+/// Lakemont microarchitecture based processors.
+CK_Lakemont,
+
 /// \name K6
 /// K6 architecture processors.
 //@{
@@ -2340,6 +2344,7 @@
 .Case("skx", CK_SkylakeServer) // Legacy name.
 .Case("cannonlake", CK_Cannonlake)
 .Case("knl", CK_KNL)
+.Case("lakemont", CK_Lakemont)
 .Case("k6", CK_K6)
 .Case("k6-2", CK_K6_2)
 .Case("k6-3", CK_K6_3)
@@ -2487,6 +2492,7 @@
 case CK_C3_2:
 case CK_Pentium4:
 case CK_Pentium4M:
+case CK_Lakemont:
 case CK_Prescott:
 case CK_K6:
 case CK_K6_2:
@@ -2585,17 +2591,21 @@
   if (getTriple().getArch() == llvm::Triple::x86_64)
 setFeatureEnabledImpl(Features, "sse2", true);
 
-  // Enable X87 for all X86 processors.
-  setFeatureEnabledImpl(Features, "x87", true);
+  const CPUKind Kind = getCPUKind(CPU);
+
+  // Enable X87 for all X86 processors but Lakemont.
+  if (Kind != CK_Lakemont)
+setFeatureEnabledImpl(Features, "x87", true);
 
-  switch (getCPUKind(CPU)) {
+  switch (Kind) {
   case CK_Generic:
   case CK_i386:
   case CK_i486:
   case CK_i586:
   case CK_Pentium:
   case CK_i686:
   case CK_PentiumPro:
+  case CK_Lakemont:
 break;
   case CK_PentiumMMX:
   case CK_Pentium2:
@@ -3250,6 +3260,9 @@
   case CK_KNL:
 defineCPUMacros(Builder, "knl");
 break;
+  case CK_Lakemont:
+Builder.defineMacro("__tune_lakemont__");
+break;
   case CK_K6_2:
 Builder.defineMacro("__k6_2__");
 Builder.defineMacro("__tune_k6_2__");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D18369: [OpenCL] Upstreaming khronos OpenCL 1.2/2.0 header files.

2016-03-31 Thread James Price via cfe-commits

jprice added a subscriber: jprice.
jprice added a comment.

In http://reviews.llvm.org/D18369#387560, @yaxunl wrote:

> In http://reviews.llvm.org/D18369#385799, @Anastasia wrote:
>
> > Is there any chance we could factor out the common bits into separate files 
> > to avoid large code repetition? I would imagine it should be quite doable 
> > as libs of each standard contain incremental changes.
>
>
> I saw some inconsistencies in the common part of the 1.2 and 2.0 headers. I 
> will try to consolidate them first then try to split.

Rather than having a separate header for each version with another header for 
the common parts, couldn't we just have a single header that uses #if guards 
for the version specific functionality? e.g.

  size_t __attribute__((overloadable)) get_global_id(uint dim);

  #if __OPENCL_C_VERSION__ >= 200
  size_t __attribute__((overloadable)) get_global_linear_id(void);
  #endif

This also allows an easy path for having OpenCL 1.1 and 1.0 support without 
having to add more copies of the header.

http://reviews.llvm.org/D18369

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

Re: r264428 - [ASTMatchers] Fix build for VariadicFunction.

2016-03-31 Thread Samuel Benzaquen via cfe-commits

On Thu, Mar 31, 2016 at 11:16 AM, David Blaikie  wrote:

> Yep, reproduces even with a plain (non template arg) function pointer -
> and immediately goes away with a real function of the same type.
>

Thanks for the extra reduction.


> That's bothersome. I played around with a few ways of writing the
> call-to-function-pointer but couldn't find any particular syntax that
> seemed to untickle GCC's problem here. Maybe if you find the filed GCC bug
> there might be a workaround listed (if it's been filed/investigated
> already).
>

I couldn't not find a bug for it. Maybe someone with a little experience in
bugzilla has a little more luck?


>
> On Thu, Mar 31, 2016 at 6:53 AM, Samuel Benzaquen 
> wrote:
>
>> I was able to reduce the bug to this:
>>
>> struct A {
>>
>>   A(int (&)[1]);
>>
>> };
>>
>> template 
>>
>> int E() {
>>
>>   int X[] = {0};
>>
>>   return F(X);
>>
>> }
>>
>>
>> Note that the array is not empty and we are not using variadics anymore.
>> The problem seems to be related to the function pointer template
>> parameter.
>> gcc doesn't want to do the implicit conversion from X to A, but if I make
>> the conversion explicit it works.
>>
>>
>> On Fri, Mar 25, 2016 at 1:58 PM, Alexey Samsonov 
>> wrote:
>>
>>>
>>> On Fri, Mar 25, 2016 at 10:55 AM, David Blaikie via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>


 On Fri, Mar 25, 2016 at 10:46 AM, Samuel Benzaquen via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

> Author: sbenza
> Date: Fri Mar 25 12:46:02 2016
> New Revision: 264428
>
> URL: http://llvm.org/viewvc/llvm-project?rev=264428=rev
> Log:
> [ASTMatchers] Fix build for VariadicFunction.
>
> Under some conditions the implicit conversion from array to ArrayRef<>
> is not working.
>

 Any idea what those conditions are?

>>>
>>> This was causing the build failure with opt GCC. I will try to create a
>>> smaller reproducer later today.
>>>
>>>


> Fix the build by making it explicit.
>
> Modified:
> cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
>
> Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h?rev=264428=264427=264428=diff
>
> ==
> --- cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
> (original)
> +++ cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h Fri Mar
> 25 12:46:02 2016
> @@ -90,7 +90,7 @@ private:
>// before we make the array.
>template  ResultT Execute(const ArgsT &... Args)
> const {
>  const ArgT *const ArgsArray[] = {};
> -return Func(ArgsArray);
> +return Func(ArrayRef(ArgsArray, sizeof...(ArgsT)));
>}
>  };
>
>
>
> ___
> 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


>>>
>>>
>>> --
>>> 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] D18442: A clang-tidy check for std:accumulate.

2016-03-31 Thread Clement Courbet via cfe-commits

courbet added a comment.

ping ?


http://reviews.llvm.org/D18442



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

[PATCH] D18649: [clang-tidy] cppcoreguidelines-interfaces-global-init

2016-03-31 Thread Clement Courbet via cfe-commits

courbet created this revision.
courbet added a reviewer: alexfh.
courbet added a subscriber: cfe-commits.

This check flags initializers of globals that access extern objects, and 
therefore can lead to order-of-initialization problems (this recommandation is 
part of CPP core guidelines).
Note that this only checks half of the guideline for now (it does not enforce 
using constexpr functions).

http://reviews.llvm.org/D18649

Files:
  clang-tidy/cppcoreguidelines/CMakeLists.txt
  clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
  clang-tidy/cppcoreguidelines/InterfacesGlobalInitCheck.cpp
  clang-tidy/cppcoreguidelines/InterfacesGlobalInitCheck.h
  docs/clang-tidy/checks/cppcoreguidelines-interfaces-global-init.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/cppcoreguidelines-interfaces-global-init.cpp

Index: test/clang-tidy/cppcoreguidelines-interfaces-global-init.cpp
===
--- /dev/null
+++ test/clang-tidy/cppcoreguidelines-interfaces-global-init.cpp
@@ -0,0 +1,64 @@
+// RUN: %check_clang_tidy %s cppcoreguidelines-interfaces-global-init %t
+
+constexpr int makesInt() { return 3; }
+constexpr int takesInt(int i) { return i + 1; }
+constexpr int takesIntPtr(int *i) { return *i; }
+
+extern int ExternGlobal;
+static int GlobalScopeBadInit1 = ExternGlobal;
+// CHECK-MESSAGES: [[@LINE-1]]:12: warning: initializing static variable with
+// non-const expression depending on static variable 'ExternGlobal'
+static int GlobalScopeBadInit2 = takesInt(ExternGlobal);
+// CHECK-MESSAGES: [[@LINE-1]]:12: warning: initializing static variable with
+// non-const expression depending on static variable 'ExternGlobal'
+static int GlobalScopeBadInit3 = takesIntPtr();
+// CHECK-MESSAGES: [[@LINE-1]]:12: warning: initializing static variable with
+// non-const expression depending on static variable 'ExternGlobal'
+static int GlobalScopeBadInit4 = 3 * (ExternGlobal + 2);
+// CHECK-MESSAGES: [[@LINE-1]]:12: warning: initializing static variable with
+// non-const expression depending on static variable 'ExternGlobal'
+
+namespace ns {
+static int NamespaceScope = makesInt();
+static int NamespaceScopeBadInit = takesInt(ExternGlobal);
+// CHECK-MESSAGES: [[@LINE-1]]:12: warning: initializing static variable with
+// non-const expression depending on static variable 'ExternGlobal'
+
+struct A {
+  static int ClassScope;
+  static int ClassScopeBadInit;
+};
+
+int A::ClassScopeBadInit = takesInt(ExternGlobal);
+// CHECK-MESSAGES: [[@LINE-1]]:8: warning: initializing static variable with
+// non-const expression depending on static variable 'ExternGlobal'
+
+static int FromClassBadInit = takesInt(A::ClassScope);
+// CHECK-MESSAGES: [[@LINE-1]]:12: warning: initializing static variable with
+// non-const expression depending on static variable 'ClassScope'
+} // namspace ns
+
+void f() {
+  // This is fine, it's executed after dynamic initilization occurs.
+  static int G = takesInt(ExternGlobal);
+}
+
+// Defined global variables are fine:
+static int GlobalScope = makesInt();
+static int GlobalScopeBadInit = takesInt(GlobalScope);
+static int GlobalScope2 = takesInt(ns::NamespaceScope);
+
+// Enums are fine.
+enum Enum { kEnumValue = 1 };
+static int GlobalScopeFromEnum = takesInt(kEnumValue);
+
+// Leave constexprs alone.
+extern constexpr int GlobalScopeConstexpr = makesInt();
+static constexpr int GlobalScopeConstexprOk =
+takesInt(GlobalScopeConstexpr);
+
+// This is a pretty common instance: People are usually not using constexpr, but
+// this is what they should write:
+static constexpr const char kValue[] = "value";
+constexpr int Fingerprint(const char *value) { return 0; }
+static int kFingerprint = Fingerprint(kValue);
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -16,6 +16,7 @@
cert-fio38-c (redirects to misc-non-copyable-objects) 
cert-flp30-c
cert-oop11-cpp (redirects to misc-move-constructor-init) 
+   cppcoreguidelines-interfaces-global-init
cppcoreguidelines-pro-bounds-array-to-pointer-decay
cppcoreguidelines-pro-bounds-constant-array-index
cppcoreguidelines-pro-bounds-pointer-arithmetic
Index: docs/clang-tidy/checks/cppcoreguidelines-interfaces-global-init.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/cppcoreguidelines-interfaces-global-init.rst
@@ -0,0 +1,11 @@
+.. title:: clang-tidy - cppcoreguidelines-interfaces-global-init
+
+cppcoreguidelines-interfaces-global-init
+
+
+This check flags initializers of globals that access extern objects,
+and therefore can lead to order-of-initialization problems.
+
+This rule is part of the "Interfaces" profile of the C++ Core Guidelines, see

[PATCH] D18648: make __builtin_isfinite more efficient (PR27145)

2016-03-31 Thread Sanjay Patel via cfe-commits

spatel created this revision.
spatel added reviewers: hfinkel, scanon, chandlerc.
spatel added a subscriber: cfe-commits.
Herald added a subscriber: mcrosier.

isinf (infinite) and isfinite should be implemented with the same function 
except we change the comparison operator.
See PR27145 for more details:
https://llvm.org/bugs/show_bug.cgi?id=27145

Ref: I noticed this while looking at D18513.

http://reviews.llvm.org/D18648

Files:
  lib/CodeGen/CGBuiltin.cpp
  test/CodeGen/builtins.c

Index: test/CodeGen/builtins.c
===
--- test/CodeGen/builtins.c
+++ test/CodeGen/builtins.c
@@ -217,10 +217,8 @@
   // CHECK:  select i1 %[[ISINF]], i32 %[[SIGN]], i32 0
 
   res = __builtin_isfinite(F);
-  // CHECK: fcmp oeq float 
   // CHECK: call float @llvm.fabs.f32(float
-  // CHECK: fcmp une float {{.*}}, 0x7FF0
-  // CHECK: and i1 
+  // CHECK: fcmp one float {{.*}}, 0x7FF0
 
   res = __builtin_isnormal(F);
   // CHECK: fcmp oeq float
Index: lib/CodeGen/CGBuiltin.cpp
===
--- lib/CodeGen/CGBuiltin.cpp
+++ lib/CodeGen/CGBuiltin.cpp
@@ -788,13 +788,19 @@
 return RValue::get(Builder.CreateZExt(V, ConvertType(E->getType(;
   }
 
-  case Builtin::BI__builtin_isinf: {
-// isinf(x) --> fabs(x) == infinity
+  case Builtin::BI__builtin_isinf:
+  case Builtin::BI__builtin_isfinite: {
+// isinf(x)--> fabs(x) == infinity
+// isfinite(x) --> fabs(x) != infinity
+// x != NaN via the ordered compare in either case.
 Value *V = EmitScalarExpr(E->getArg(0));
-V = EmitFAbs(*this, V);
-
-V = Builder.CreateFCmpOEQ(V, 
ConstantFP::getInfinity(V->getType()),"isinf");
-return RValue::get(Builder.CreateZExt(V, ConvertType(E->getType(;
+Value *Fabs = EmitFAbs(*this, V);
+Constant *Infinity = ConstantFP::getInfinity(V->getType());
+CmpInst::Predicate Pred = (BuiltinID == Builtin::BI__builtin_isinf)
+  ? CmpInst::FCMP_OEQ
+  : CmpInst::FCMP_ONE;
+Value *FCmp = Builder.CreateFCmp(Pred, Fabs, Infinity, "cmpinf");
+return RValue::get(Builder.CreateZExt(FCmp, ConvertType(E->getType(;
   }
 
   case Builtin::BI__builtin_isinf_sign: {
@@ -832,19 +838,6 @@
 return RValue::get(Builder.CreateZExt(V, ConvertType(E->getType(;
   }
 
-  case Builtin::BI__builtin_isfinite: {
-// isfinite(x) --> x == x && fabs(x) != infinity;
-Value *V = EmitScalarExpr(E->getArg(0));
-Value *Eq = Builder.CreateFCmpOEQ(V, V, "iseq");
-
-Value *Abs = EmitFAbs(*this, V);
-Value *IsNotInf =
-  Builder.CreateFCmpUNE(Abs, 
ConstantFP::getInfinity(V->getType()),"isinf");
-
-V = Builder.CreateAnd(Eq, IsNotInf, "and");
-return RValue::get(Builder.CreateZExt(V, ConvertType(E->getType(;
-  }
-
   case Builtin::BI__builtin_fpclassify: {
 Value *V = EmitScalarExpr(E->getArg(5));
 llvm::Type *Ty = ConvertType(E->getArg(5)->getType());


Index: test/CodeGen/builtins.c
===
--- test/CodeGen/builtins.c
+++ test/CodeGen/builtins.c
@@ -217,10 +217,8 @@
   // CHECK:  select i1 %[[ISINF]], i32 %[[SIGN]], i32 0
 
   res = __builtin_isfinite(F);
-  // CHECK: fcmp oeq float 
   // CHECK: call float @llvm.fabs.f32(float
-  // CHECK: fcmp une float {{.*}}, 0x7FF0
-  // CHECK: and i1 
+  // CHECK: fcmp one float {{.*}}, 0x7FF0
 
   res = __builtin_isnormal(F);
   // CHECK: fcmp oeq float
Index: lib/CodeGen/CGBuiltin.cpp
===
--- lib/CodeGen/CGBuiltin.cpp
+++ lib/CodeGen/CGBuiltin.cpp
@@ -788,13 +788,19 @@
 return RValue::get(Builder.CreateZExt(V, ConvertType(E->getType(;
   }
 
-  case Builtin::BI__builtin_isinf: {
-// isinf(x) --> fabs(x) == infinity
+  case Builtin::BI__builtin_isinf:
+  case Builtin::BI__builtin_isfinite: {
+// isinf(x)--> fabs(x) == infinity
+// isfinite(x) --> fabs(x) != infinity
+// x != NaN via the ordered compare in either case.
 Value *V = EmitScalarExpr(E->getArg(0));
-V = EmitFAbs(*this, V);
-
-V = Builder.CreateFCmpOEQ(V, ConstantFP::getInfinity(V->getType()),"isinf");
-return RValue::get(Builder.CreateZExt(V, ConvertType(E->getType(;
+Value *Fabs = EmitFAbs(*this, V);
+Constant *Infinity = ConstantFP::getInfinity(V->getType());
+CmpInst::Predicate Pred = (BuiltinID == Builtin::BI__builtin_isinf)
+  ? CmpInst::FCMP_OEQ
+  : CmpInst::FCMP_ONE;
+Value *FCmp = Builder.CreateFCmp(Pred, Fabs, Infinity, "cmpinf");
+return RValue::get(Builder.CreateZExt(FCmp, ConvertType(E->getType(;
   }
 
   case Builtin::BI__builtin_isinf_sign: {
@@ -832,19 +838,6 @@
 return RValue::get(Builder.CreateZExt(V, ConvertType(E->getType(;
   }
 
-  case

Re: r264428 - [ASTMatchers] Fix build for VariadicFunction.

2016-03-31 Thread David Blaikie via cfe-commits

Yep, reproduces even with a plain (non template arg) function pointer - and
immediately goes away with a real function of the same type.

That's bothersome. I played around with a few ways of writing the
call-to-function-pointer but couldn't find any particular syntax that
seemed to untickle GCC's problem here. Maybe if you find the filed GCC bug
there might be a workaround listed (if it's been filed/investigated
already).

On Thu, Mar 31, 2016 at 6:53 AM, Samuel Benzaquen  wrote:

> I was able to reduce the bug to this:
>
> struct A {
>
>   A(int (&)[1]);
>
> };
>
> template 
>
> int E() {
>
>   int X[] = {0};
>
>   return F(X);
>
> }
>
>
> Note that the array is not empty and we are not using variadics anymore.
> The problem seems to be related to the function pointer template parameter.
> gcc doesn't want to do the implicit conversion from X to A, but if I make
> the conversion explicit it works.
>
>
> On Fri, Mar 25, 2016 at 1:58 PM, Alexey Samsonov 
> wrote:
>
>>
>> On Fri, Mar 25, 2016 at 10:55 AM, David Blaikie via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>>
>>>
>>> On Fri, Mar 25, 2016 at 10:46 AM, Samuel Benzaquen via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 Author: sbenza
 Date: Fri Mar 25 12:46:02 2016
 New Revision: 264428

 URL: http://llvm.org/viewvc/llvm-project?rev=264428=rev
 Log:
 [ASTMatchers] Fix build for VariadicFunction.

 Under some conditions the implicit conversion from array to ArrayRef<>
 is not working.

>>>
>>> Any idea what those conditions are?
>>>
>>
>> This was causing the build failure with opt GCC. I will try to create a
>> smaller reproducer later today.
>>
>>
>>>
>>>
 Fix the build by making it explicit.

 Modified:
 cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h

 Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
 URL:
 http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h?rev=264428=264427=264428=diff

 ==
 --- cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h (original)
 +++ cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h Fri Mar
 25 12:46:02 2016
 @@ -90,7 +90,7 @@ private:
// before we make the array.
template  ResultT Execute(const ArgsT &... Args)
 const {
  const ArgT *const ArgsArray[] = {};
 -return Func(ArgsArray);
 +return Func(ArrayRef(ArgsArray, sizeof...(ArgsT)));
}
  };



 ___
 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
>>>
>>>
>>
>>
>> --
>> 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] D18596: [MSVC] PR27132: Proper mangling for __unaligned qualifier

2016-03-31 Thread Andrey Bokhanko via cfe-commits

andreybokhanko updated this revision to Diff 52208.
andreybokhanko added a comment.

Resolved [some of] comments made by Aaron and Reid.


http://reviews.llvm.org/D18596

Files:
  include/clang/AST/Type.h
  include/clang/Basic/Attr.td
  include/clang/Basic/AttrDocs.td
  lib/AST/MicrosoftMangle.cpp
  lib/AST/Type.cpp
  lib/AST/TypePrinter.cpp
  lib/Sema/SemaType.cpp
  test/CodeGenCXX/mangle-ms-cxx11.cpp

Index: lib/AST/MicrosoftMangle.cpp
===
--- lib/AST/MicrosoftMangle.cpp
+++ lib/AST/MicrosoftMangle.cpp
@@ -1413,6 +1413,12 @@
 
   if (HasRestrict)
 Out << 'I';
+
+  if (!PointeeType.isNull()) {
+auto AT = PointeeType->getAs();
+if ((AT != nullptr) && (AT->getAttrKind() == AttributedType::attr_unaligned))
+  Out << 'F';
+  }
 }
 
 void MicrosoftCXXNameMangler::manglePointerCVQualifiers(Qualifiers Quals) {
Index: lib/AST/TypePrinter.cpp
===
--- lib/AST/TypePrinter.cpp
+++ lib/AST/TypePrinter.cpp
@@ -1156,6 +1156,7 @@
 case AttributedType::attr_ptr64: OS << " __ptr64"; break;
 case AttributedType::attr_sptr: OS << " __sptr"; break;
 case AttributedType::attr_uptr: OS << " __uptr"; break;
+case AttributedType::attr_unaligned: OS << " __unaligned"; break;
 }
 spaceBeforePlaceHolder(OS);
   }
Index: lib/AST/Type.cpp
===
--- lib/AST/Type.cpp
+++ lib/AST/Type.cpp
@@ -3003,6 +3003,7 @@
   case AttributedType::attr_sptr:
   case AttributedType::attr_uptr:
   case AttributedType::attr_objc_kindof:
+  case AttributedType::attr_unaligned:
 return false;
   }
   llvm_unreachable("bad attributed type kind");
@@ -3015,6 +3016,7 @@
   case attr_ptr64:
   case attr_sptr:
   case attr_uptr:
+  case attr_unaligned:
 return true;
   }
   llvm_unreachable("invalid attr kind");
@@ -3039,6 +3041,7 @@
   case attr_nullable:
   case attr_null_unspecified:
   case attr_objc_kindof:
+  case attr_unaligned:
 return false;
 
   case attr_pcs:
Index: lib/Sema/SemaType.cpp
===
--- lib/Sema/SemaType.cpp
+++ lib/Sema/SemaType.cpp
@@ -120,7 +120,8 @@
 case AttributeList::AT_Ptr32: \
 case AttributeList::AT_Ptr64: \
 case AttributeList::AT_SPtr: \
-case AttributeList::AT_UPtr
+case AttributeList::AT_UPtr: \
+case AttributeList::AT_Unaligned
 
 // Nullability qualifiers.
 #define NULLABILITY_TYPE_ATTRS_CASELIST \
@@ -4538,6 +4539,8 @@
 return AttributeList::AT_TypeNullUnspecified;
   case AttributedType::attr_objc_kindof:
 return AttributeList::AT_ObjCKindOf;
+  case AttributedType::attr_unaligned:
+return AttributeList::AT_Unaligned;
   }
   llvm_unreachable("unexpected attribute kind!");
 }
@@ -5547,8 +5550,9 @@
   }
 
   // Pointer type qualifiers can only operate on pointer types, but not
-  // pointer-to-member types.
-  if (!isa(Desugared)) {
+  // pointer-to-member types. "__unaligned" qualifier can be applied to
+  // anything, so this is an exception.
+  if (!isa(Desugared) && (Kind != AttributeList::AT_Unaligned)) {
 if (Type->isMemberPointerType())
   S.Diag(Attr.getLoc(), diag::err_attribute_no_member_pointers)
   << Attr.getName();
@@ -5565,6 +5569,7 @@
   case AttributeList::AT_Ptr64: TAK = AttributedType::attr_ptr64; break;
   case AttributeList::AT_SPtr: TAK = AttributedType::attr_sptr; break;
   case AttributeList::AT_UPtr: TAK = AttributedType::attr_uptr; break;
+  case AttributeList::AT_Unaligned: TAK = AttributedType::attr_unaligned; break;
   }
 
   Type = S.Context.getAttributedType(TAK, Type, Type);
Index: include/clang/AST/Type.h
===
--- include/clang/AST/Type.h
+++ include/clang/AST/Type.h
@@ -3639,6 +3639,7 @@
 attr_null_unspecified,
 attr_objc_kindof,
 attr_objc_inert_unsafe_unretained,
+attr_unaligned,
   };
 
 private:
Index: include/clang/Basic/AttrDocs.td
===
--- include/clang/Basic/AttrDocs.td
+++ include/clang/Basic/AttrDocs.td
@@ -1957,3 +1957,18 @@
   The system will crash if the wrong handler is used.
   }];
 }
+
+def UnalignedDocs : Documentation {
+  let Category = DocCatVariable;
+  let Content = [{
+The ``__unaligned`` modifier declares a pointer with an unaligned address.
+It is available under the ``-fms-extensions`` flag for MSVC compatibility.
+See the documentation for `__unaligned`_ on MSDN.
+
+.. _`__unaligned`: https://msdn.microsoft.com/en-us/library/ms177389.aspx 
+
+Clang supports proper mangling of the variables with ``unaligned`` modifier,
+but it doesn't affect generated code in any other way.
+  }];
+}
+
Index: include/clang/Basic/Attr.td
===
--- include/clang/Basic/Attr.td
+++ include/clang/Basic/Attr.td
@@ -2075,8

Re: r264428 - [ASTMatchers] Fix build for VariadicFunction.

2016-03-31 Thread Samuel Benzaquen via cfe-commits

I was able to reduce the bug to this:

struct A {

  A(int (&)[1]);

};

template 

int E() {

  int X[] = {0};

  return F(X);

}


Note that the array is not empty and we are not using variadics anymore.
The problem seems to be related to the function pointer template parameter.
gcc doesn't want to do the implicit conversion from X to A, but if I make
the conversion explicit it works.


On Fri, Mar 25, 2016 at 1:58 PM, Alexey Samsonov  wrote:

>
> On Fri, Mar 25, 2016 at 10:55 AM, David Blaikie via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>>
>>
>> On Fri, Mar 25, 2016 at 10:46 AM, Samuel Benzaquen via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: sbenza
>>> Date: Fri Mar 25 12:46:02 2016
>>> New Revision: 264428
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=264428=rev
>>> Log:
>>> [ASTMatchers] Fix build for VariadicFunction.
>>>
>>> Under some conditions the implicit conversion from array to ArrayRef<>
>>> is not working.
>>>
>>
>> Any idea what those conditions are?
>>
>
> This was causing the build failure with opt GCC. I will try to create a
> smaller reproducer later today.
>
>
>>
>>
>>> Fix the build by making it explicit.
>>>
>>> Modified:
>>> cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
>>>
>>> Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h?rev=264428=264427=264428=diff
>>>
>>> ==
>>> --- cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h (original)
>>> +++ cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h Fri Mar 25
>>> 12:46:02 2016
>>> @@ -90,7 +90,7 @@ private:
>>>// before we make the array.
>>>template  ResultT Execute(const ArgsT &... Args)
>>> const {
>>>  const ArgT *const ArgsArray[] = {};
>>> -return Func(ArgsArray);
>>> +return Func(ArrayRef(ArgsArray, sizeof...(ArgsT)));
>>>}
>>>  };
>>>
>>>
>>>
>>> ___
>>> 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
>>
>>
>
>
> --
> 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] D18551: Added Fixer implementation and fix() interface in clang-format for removing redundant code.

2016-03-31 Thread Eric Liu via cfe-commits

ioeric updated this revision to Diff 52199.
ioeric added a comment.

- Added fixReplacements() that fix and reformat replacements.


http://reviews.llvm.org/D18551

Files:
  include/clang/Format/Format.h
  lib/Format/Format.cpp
  lib/Format/FormatToken.h
  unittests/Format/FormatTest.cpp

Index: unittests/Format/FormatTest.cpp
===
--- unittests/Format/FormatTest.cpp
+++ unittests/Format/FormatTest.cpp
@@ -11233,6 +11233,117 @@
 
 #endif // _MSC_VER
 
+class FixTest : public ::testing::Test {
+protected:
+  std::string fix(llvm::StringRef Code,
+  const std::vector ,
+  const FormatStyle  = getLLVMStyle()) {
+DEBUG(llvm::errs() << "---\n");
+DEBUG(llvm::errs() << Code << "\n\n");
+tooling::Replacements Replaces = format::fix(Style, Code, Ranges);
+
+std::string Result = applyAllReplacements(Code, Replaces);
+EXPECT_NE("", Result);
+DEBUG(llvm::errs() << "\n" << Result << "\n\n");
+return Result;
+  }
+};
+
+TEST_F(FixTest, CtorInitializationSimpleRedundantComma) {
+  std::string Code = "class A {\nA() : , {} };";
+  std::string Expected = "class A {\nA()   {} };";
+  std::vector Ranges;
+  Ranges.push_back(tooling::Range(17, 0));
+  Ranges.push_back(tooling::Range(19, 0));
+  std::string Result = fix(Code, Ranges);
+  EXPECT_EQ(Expected, Result);
+
+  Code = "class A {\nA() : x(1), {} };";
+  Expected = "class A {\nA() : x(1) {} };";
+  Ranges.clear();
+  Ranges.push_back(tooling::Range(23, 0));
+  Result = fix(Code, Ranges);
+  EXPECT_EQ(Expected, Result);
+}
+
+TEST_F(FixTest, CtorInitializationBracesInParens) {
+  std::string Code = "class A {\nA() : x({1}),, {} };";
+  std::string Expected = "class A {\nA() : x({1}) {} };";
+  std::vector Ranges;
+  Ranges.push_back(tooling::Range(24, 0));
+  Ranges.push_back(tooling::Range(26, 0));
+  std::string Result = fix(Code, Ranges);
+  DEBUG(llvm::errs() << "\n" << Result << "\n");
+  EXPECT_EQ(Expected, Result);
+}
+
+TEST_F(FixTest, RedundantCommaNotInAffectedRanges) {
+  std::string Code =
+  "class A {\nA() : x({1}), /* comment */, { int x = 0; } };";
+  std::string Expected =
+  "class A {\nA() : x({1}), /* comment */, { int x = 0; } };";
+  // Set the affected range to be "int x = 0", which does not intercept the
+  // constructor initialization list.
+  std::vector Ranges(1, tooling::Range(42, 9));
+  std::string Result = fix(Code, Ranges);
+  EXPECT_EQ(Expected, Result);
+
+  Code = "class A {\nA() : x(1), {} };";
+  Expected = "class A {\nA() : x(1), {} };";
+  // No range. Fixer should do nothing.
+  Ranges.clear();
+  Result = fix(Code, Ranges);
+  EXPECT_EQ(Expected, Result);
+}
+
+TEST_F(FixTest, CtorInitializationCommentAroundCommas) {
+  // Remove redundant commas and comment between them.
+  std::string Code = "class A {\nA() : x({1}), /* comment */, {} };";
+  std::string Expected = "class A {\nA() : x({1})  {} };";
+  std::vector Ranges;
+  Ranges.push_back(tooling::Range(25, 0));
+  Ranges.push_back(tooling::Range(40, 0));
+  std::string Result = fix(Code, Ranges);
+  EXPECT_EQ(Expected, Result);
+
+  // Remove trailing comma and comment.
+  Code = "class A {\nA() : x({1}), // comment\n{} };";
+  Expected = "class A {\nA() : x({1}) \n{} };";
+  Ranges = std::vector(1, tooling::Range(25, 0));
+  Result = fix(Code, Ranges);
+  EXPECT_EQ(Expected, Result);
+
+  // Remove trailing comma, but leave the comment.
+  Code = "class A {\nA() : x({1}), // comment\n , y(1),{} };";
+  Expected = "class A {\nA() : x({1}), // comment\n  y(1){} };";
+  Ranges = std::vector(1, tooling::Range(38, 0));
+  Result = fix(Code, Ranges);
+  EXPECT_EQ(Expected, Result);
+
+  // Remove trailing comma and the comment before it.
+  Code = "class A {\nA() : x({1}), \n/* comment */, y(1),{} };";
+  Expected = "class A {\nA() : x({1}), \n y(1){} };";
+  Ranges = std::vector(1, tooling::Range(40, 0));
+  Result = fix(Code, Ranges);
+  EXPECT_EQ(Expected, Result);
+
+  // Remove trailing comma and the comment after it.
+  Code = "class A {\nA() : , // comment\n y(1),{} };";
+  Expected = "class A {\nA() :  \n y(1){} };";
+  Ranges = std::vector(1, tooling::Range(17, 0));
+  Result = fix(Code, Ranges);
+  EXPECT_EQ(Expected, Result);
+}
+
+TEST_F(FixTest, SkipImbalancedParentheses) {
+  std::string Code = "class A {\nA() : x((),, {} };";
+  std::string Expected = "class A {\nA() : x((),, {} };";
+  std::vector Ranges(1, tooling::Range(0, Code.size()));
+  std::string Result = fix(Code, Ranges);
+  DEBUG(llvm::errs() << "\n" << Result << "\n");
+  EXPECT_EQ(Expected, Result);
+}
+
 class ReplacementTest : public ::testing::Test {
 protected:
   tooling::Replacement createReplacement(SourceLocation Start, unsigned Length,
@@ -11274,6 +11385,42 @@
   Code, formatReplacements(Code, Replaces, Style)));
 }
 
+TEST_F(ReplacementTest, FixCodeAfterReplacements) {
+  std::string Code = "class A {\n"
+ "  A() :

Re: [PATCH] D18408: readability check for const params in declarations

2016-03-31 Thread Matthew Fowles Kulukundis via cfe-commits

I tried manually specifying --create.  The problem was that my commit
message had stuff from an early arc diff still in it which arc was picking
up and getting confused by.

Matt

On Thu, Mar 31, 2016 at 8:29 AM, Alexander Kornienko 
wrote:

> On Wed, Mar 30, 2016 at 4:01 PM, Matthew Fowles Kulukundis <
> matt.fow...@gmail.com> wrote:
>
>> My attempts to do this end with:
>>
>> $ arc diff
>>
>
> I normally use `arc diff --create` or `arc diff --update D`, and this
> works.
>
>
>> Linting...
>> No lint engine configured for this project.
>> Running unit tests...
>> No unit test engine is configured for this project.
>>  SKIP STAGING  Unable to determine repository for this change.
>> Exception
>> ERR_CLOSED: This revision has already been closed.
>> (Run with `--trace` for a full exception trace.)
>>
>>
>> On Wed, Mar 30, 2016 at 7:39 AM, Alexander Kornienko 
>> wrote:
>>
>>> alexfh added a comment.
>>>
>>> Actually, we missed one thing: may I ask you to update
>>> docs/ReleaseNotes.rst with a short description of the new check?
>>>
>>>
>>> Repository:
>>>   rL LLVM
>>>
>>> http://reviews.llvm.org/D18408
>>>
>>>
>>>
>>>
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D18509: clang-tidy: add_new_check.py stubs out release notes

2016-03-31 Thread don hinton via cfe-commits

hintonda added a subscriber: hintonda.
hintonda added a comment.

With this change, won't you need to update 2 different repos: clang and extra?  
Is it possible to update both with a single Phabricator patch?


http://reviews.llvm.org/D18509



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

Re: [PATCH] D18319: Add a PragmaHandler Registry for plugins to add PragmaHandlers to

2016-03-31 Thread John Brawn via cfe-commits

john.brawn added a comment.

In http://reviews.llvm.org/D18319#379337, @rnk wrote:

> This seems reasonable.


OK to commit then?


Repository:
  rL LLVM

http://reviews.llvm.org/D18319



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

Re: [PATCH] D18408: readability check for const params in declarations

2016-03-31 Thread Alexander Kornienko via cfe-commits

On Wed, Mar 30, 2016 at 4:01 PM, Matthew Fowles Kulukundis <
matt.fow...@gmail.com> wrote:

> My attempts to do this end with:
>
> $ arc diff
>

I normally use `arc diff --create` or `arc diff --update D`, and this
works.


> Linting...
> No lint engine configured for this project.
> Running unit tests...
> No unit test engine is configured for this project.
>  SKIP STAGING  Unable to determine repository for this change.
> Exception
> ERR_CLOSED: This revision has already been closed.
> (Run with `--trace` for a full exception trace.)
>
>
> On Wed, Mar 30, 2016 at 7:39 AM, Alexander Kornienko 
> wrote:
>
>> alexfh added a comment.
>>
>> Actually, we missed one thing: may I ask you to update
>> docs/ReleaseNotes.rst with a short description of the new check?
>>
>>
>> Repository:
>>   rL LLVM
>>
>> http://reviews.llvm.org/D18408
>>
>>
>>
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D18509: clang-tidy: add_new_check.py stubs out release notes

2016-03-31 Thread Alexander Kornienko via cfe-commits

alexfh added a comment.

I like the idea, but we could make this a bit more reliable, see the inline 
comment.



Comment at: clang-tidy/add_new_check.py:280
@@ +279,3 @@
+  if not clang_tidy_found:
+if line.startswith("Improvements to ``clang-tidy``"):
+  clang_tidy_found = True

Maybe instead add a special placeholder to the .rst file (something like 
``) and insert new text right _before_ it? 
This will solve two problems: dependency on the formatting of the text and 
chronological order of the notes.


http://reviews.llvm.org/D18509



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

Re: [PATCH] D18584: Complete support for C++ Core Guidelines Type.6: Always initialize a member variable.

2016-03-31 Thread Alexander Kornienko via cfe-commits

alexfh added a comment.

Thank you for the patch! I'd like the original author to take a look at it, so 
just a couple of peanut gallery comments from me for now.



Comment at: clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.cpp:51
@@ +50,3 @@
+static bool
+isTriviallyConstructible(const ASTContext , QualType Type) {
+  if (Type.isNull())

I wonder whether some relevant parts of SemaExprCXX.cpp could be made reusable 
so that you don't have to completely reimplement those.


Comment at: clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.cpp:56
@@ +55,3 @@
+  if (Type->isArrayType())
+return isTriviallyConstructible(Context,
+Context.getBaseElementType(Type));

Please clang-format the code.


http://reviews.llvm.org/D18584



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

Re: [PATCH] D18608: note for top-level consts in function decls tidy

2016-03-31 Thread Alexander Kornienko via cfe-commits

alexfh added a comment.

Thank you for the patch, btw!


Repository:
  rL LLVM

http://reviews.llvm.org/D18608



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

Re: [PATCH] D18608: note for top-level consts in function decls tidy

2016-03-31 Thread Alexander Kornienko via cfe-commits

alexfh added inline comments.


Comment at: docs/ReleaseNotes.rst:73
@@ +72,3 @@
+
+  This check warns about top-level const parameters in function delcartions.
+

Typo: "delcartions". Fixed in a follow up.


Repository:
  rL LLVM

http://reviews.llvm.org/D18608



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

1 2 >

1 - 100 of 118 matches

Mail list logo