[clang-tools-extra] r291653 - Only launch asynchronously if threading is enabled.

2017-01-10 Thread Manuel Klimek via cfe-commits
Author: klimek
Date: Wed Jan 11 01:20:46 2017
New Revision: 291653

URL: http://llvm.org/viewvc/llvm-project?rev=291653=rev
Log:
Only launch asynchronously if threading is enabled.

Modified:
clang-tools-extra/trunk/include-fixer/SymbolIndexManager.h

Modified: clang-tools-extra/trunk/include-fixer/SymbolIndexManager.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/include-fixer/SymbolIndexManager.h?rev=291653=291652=291653=diff
==
--- clang-tools-extra/trunk/include-fixer/SymbolIndexManager.h (original)
+++ clang-tools-extra/trunk/include-fixer/SymbolIndexManager.h Wed Jan 11 
01:20:46 2017
@@ -23,7 +23,12 @@ namespace include_fixer {
 class SymbolIndexManager {
 public:
   void addSymbolIndex(std::function F) {
-SymbolIndices.push_back(std::async(std::launch::async, F));
+#if LLVM_ENABLE_THREADS
+auto Strategy = std::launch::async;
+#else
+auto Strategy = std::launch::deferred;
+#endif
+SymbolIndices.push_back(std::async(Strategy, F));
   }
 
   /// Search for header files to be included for an identifier.


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


[PATCH] D28451: [AVR] Add support for the 'interrupt' and 'naked' attributes

2017-01-10 Thread Dylan McKay via Phabricator via cfe-commits
dylanmckay added inline comments.



Comment at: include/clang/Basic/Attr.td:488
+
+def AVRSignal : InheritableAttr, TargetSpecificAttr {
+  let Spellings = [GNU<"signal">];

aaron.ballman wrote:
> Does this attribute appertain to any specific subjects, or can you apply it 
> to any declaration?
It can be applied to function definitions only.



Comment at: test/CodeGen/avr/attributes/naked.c:4
+// CHECK: define void @foo() #0
+__attribute__((naked)) void foo(void) { }
+

aaron.ballman wrote:
> This test seems unrelated as you didn't modify anything about the naked 
> attribute?
I didn't modify the naked attribute, but I did want to include a test for AVR.


https://reviews.llvm.org/D28451



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


[PATCH] D28451: [AVR] Add support for the 'interrupt' and 'naked' attributes

2017-01-10 Thread Dylan McKay via Phabricator via cfe-commits
dylanmckay updated this revision to Diff 83913.
dylanmckay marked 2 inline comments as done.
dylanmckay added a comment.

[AVR] Document the 'interrupt' and 'naked' attributes


https://reviews.llvm.org/D28451

Files:
  include/clang/Basic/Attr.td
  include/clang/Basic/AttrDocs.td
  lib/CodeGen/TargetInfo.cpp
  lib/Sema/SemaDeclAttr.cpp
  test/CodeGen/avr/attributes/interrupt.c
  test/CodeGen/avr/attributes/naked.c
  test/CodeGen/avr/attributes/signal.c

Index: test/CodeGen/avr/attributes/signal.c
===
--- /dev/null
+++ test/CodeGen/avr/attributes/signal.c
@@ -0,0 +1,6 @@
+// RUN: %clang_cc1 -triple avr-unknown-unknown -emit-llvm %s -o - | FileCheck %s
+
+// CHECK: define void @foo() #0
+__attribute__((signal)) void foo(void) { }
+
+// CHECK: attributes #0 = {{{.*signal.*}}}
Index: test/CodeGen/avr/attributes/naked.c
===
--- /dev/null
+++ test/CodeGen/avr/attributes/naked.c
@@ -0,0 +1,6 @@
+// RUN: %clang_cc1 -triple avr-unknown-unknown -emit-llvm %s -o - | FileCheck %s
+
+// CHECK: define void @foo() #0
+__attribute__((naked)) void foo(void) { }
+
+// CHECK: attributes #0 = {{{.*naked.*}}}
Index: test/CodeGen/avr/attributes/interrupt.c
===
--- /dev/null
+++ test/CodeGen/avr/attributes/interrupt.c
@@ -0,0 +1,6 @@
+// RUN: %clang_cc1 -triple avr-unknown-unknown -emit-llvm %s -o - | FileCheck %s
+
+// CHECK: define void @foo() #0
+__attribute__((interrupt)) void foo(void) { }
+
+// CHECK: attributes #0 = {{{.*interrupt.*}}}
Index: lib/Sema/SemaDeclAttr.cpp
===
--- lib/Sema/SemaDeclAttr.cpp
+++ lib/Sema/SemaDeclAttr.cpp
@@ -5126,6 +5126,20 @@
   D->addAttr(UsedAttr::CreateImplicit(S.Context));
 }
 
+static void handleAVRInterruptAttr(Sema , Decl *D,
+   const AttributeList ) {
+  D->addAttr(::new (S.Context)
+ AVRInterruptAttr(Attr.getLoc(), S.Context,
+  Attr.getAttributeSpellingListIndex()));
+}
+
+static void handleAVRSignalAttr(Sema , Decl *D,
+const AttributeList ) {
+  D->addAttr(::new (S.Context)
+ AVRSignalAttr(Attr.getLoc(), S.Context,
+   Attr.getAttributeSpellingListIndex()));
+}
+
 static void handleInterruptAttr(Sema , Decl *D, const AttributeList ) {
   // Dispatch the interrupt attribute based on the current target.
   switch (S.Context.getTargetInfo().getTriple().getArch()) {
@@ -5140,6 +5154,9 @@
   case llvm::Triple::x86_64:
 handleAnyX86InterruptAttr(S, D, Attr);
 break;
+  case llvm::Triple::avr:
+handleAVRInterruptAttr(S, D, Attr);
+break;
   default:
 handleARMInterruptAttr(S, D, Attr);
 break;
@@ -5700,6 +5717,9 @@
   case AttributeList::AT_AMDGPUNumVGPR:
 handleAMDGPUNumVGPRAttr(S, D, Attr);
 break;
+  case AttributeList::AT_AVRSignal:
+handleAVRSignalAttr(S, D, Attr);
+break;
   case AttributeList::AT_IBAction:
 handleSimpleAttribute(S, D, Attr);
 break;
Index: lib/CodeGen/TargetInfo.cpp
===
--- lib/CodeGen/TargetInfo.cpp
+++ lib/CodeGen/TargetInfo.cpp
@@ -6884,6 +6884,31 @@
 }
 
 //===--===//
+// AVR ABI Implementation.
+//===--===//
+
+namespace {
+class AVRTargetCodeGenInfo : public TargetCodeGenInfo {
+public:
+  AVRTargetCodeGenInfo(CodeGenTypes )
+: TargetCodeGenInfo(new DefaultABIInfo(CGT)) { }
+
+  void setTargetAttributes(const Decl *D, llvm::GlobalValue *GV,
+   CodeGen::CodeGenModule ) const override {
+const FunctionDecl *FD = dyn_cast_or_null(D);
+if (!FD) return;
+llvm::Function *Fn = cast(GV);
+
+if (FD->getAttr())
+  Fn->addFnAttr("interrupt");
+
+if (FD->getAttr())
+  Fn->addFnAttr("signal");
+  }
+};
+}
+
+//===--===//
 // TCE ABI Implementation (see http://tce.cs.tut.fi). Uses mostly the defaults.
 // Currently subclassed only to implement custom OpenCL C function attribute
 // handling.
@@ -8386,6 +8411,9 @@
   case llvm::Triple::mips64el:
 return SetCGInfo(new MIPSTargetCodeGenInfo(Types, false));
 
+  case llvm::Triple::avr:
+return SetCGInfo(new AVRTargetCodeGenInfo(Types));
+
   case llvm::Triple::aarch64:
   case llvm::Triple::aarch64_be: {
 AArch64ABIInfo::ABIKind Kind = AArch64ABIInfo::AAPCS;
Index: include/clang/Basic/AttrDocs.td
===
--- include/clang/Basic/AttrDocs.td
+++ include/clang/Basic/AttrDocs.td
@@ -1181,6 +1181,33 @@
   }];
 }
 
+def AVRInterruptDocs : Documentation {
+  let Category = DocCatFunction;
+  let Content = 

Re: r291628 - Module: Do not create Implicit ImportDecl for module X if we

2017-01-10 Thread Manman Ren via cfe-commits
On Tue, Jan 10, 2017 at 5:59 PM, Richard Smith 
wrote:

> On 10 January 2017 at 17:57, Richard Smith  wrote:
>
>> On 10 January 2017 at 16:48, Manman Ren via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: mren
>>> Date: Tue Jan 10 18:48:19 2017
>>> New Revision: 291628
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=291628=rev
>>> Log:
>>> Module: Do not create Implicit ImportDecl for module X if we
>>>  are building an implemenation of module X.
>>>
>>
>> Hmm. We do actually have an include mapping to a module header in this
>> case. Perhaps it would be better to create a faithful AST representation
>> and handle this in CodeGen instead -- we should not add any link flags when
>> an implementation TU of a module imports a header of that same module.
>>
>
> It's worth pointing out that the C++ modules TS allows a modular import of
> a module interface into an implementation unit of that module, so the
> current approach won't work for that case, but filtering these imports out
> in CodeGen would work.
>

Makes sense. I will commit a follow-up patch.

Manman

>
>
>> This fixes a regression caused by r280409.
>>> rdar://problem/29930553
>>>
>>> Added:
>>> cfe/trunk/test/Modules/Inputs/module-impl-with-link/
>>> cfe/trunk/test/Modules/Inputs/module-impl-with-link/foo.h
>>> cfe/trunk/test/Modules/Inputs/module-impl-with-link/module.modulemap
>>> cfe/trunk/test/Modules/module-impl-with-link.c
>>> Modified:
>>> cfe/trunk/include/clang/Sema/Sema.h
>>> cfe/trunk/lib/Sema/SemaDecl.cpp
>>>
>>> Modified: cfe/trunk/include/clang/Sema/Sema.h
>>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/
>>> Sema/Sema.h?rev=291628=291627=291628=diff
>>> 
>>> ==
>>> --- cfe/trunk/include/clang/Sema/Sema.h (original)
>>> +++ cfe/trunk/include/clang/Sema/Sema.h Tue Jan 10 18:48:19 2017
>>> @@ -1905,7 +1905,8 @@ public:
>>>/// \brief The parser has processed a module import translated from a
>>>/// #include or similar preprocessing directive.
>>>void ActOnModuleInclude(SourceLocation DirectiveLoc, Module *Mod);
>>> -  void BuildModuleInclude(SourceLocation DirectiveLoc, Module *Mod);
>>> +  void BuildModuleInclude(SourceLocation DirectiveLoc, Module *Mod,
>>> +  bool NoImport);
>>>
>>>/// \brief The parsed has entered a submodule.
>>>void ActOnModuleBegin(SourceLocation DirectiveLoc, Module *Mod);
>>>
>>> Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
>>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaD
>>> ecl.cpp?rev=291628=291627=291628=diff
>>> 
>>> ==
>>> --- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
>>> +++ cfe/trunk/lib/Sema/SemaDecl.cpp Tue Jan 10 18:48:19 2017
>>> @@ -15652,10 +15652,11 @@ DeclResult Sema::ActOnModuleImport(Sourc
>>>
>>>  void Sema::ActOnModuleInclude(SourceLocation DirectiveLoc, Module
>>> *Mod) {
>>>checkModuleImportContext(*this, Mod, DirectiveLoc, CurContext, true);
>>> -  BuildModuleInclude(DirectiveLoc, Mod);
>>> +  BuildModuleInclude(DirectiveLoc, Mod, false/*NoImport*/);
>>>  }
>>>
>>> -void Sema::BuildModuleInclude(SourceLocation DirectiveLoc, Module
>>> *Mod) {
>>> +void Sema::BuildModuleInclude(SourceLocation DirectiveLoc, Module *Mod,
>>> +  bool NoImport) {
>>>// Determine whether we're in the #include buffer for a module. The
>>> #includes
>>>// in that buffer do not qualify as module imports; they're just an
>>>// implementation detail of us building the module.
>>> @@ -15665,7 +15666,7 @@ void Sema::BuildModuleInclude(SourceLoca
>>>TUKind == TU_Module &&
>>>getSourceManager().isWrittenInMainFile(DirectiveLoc);
>>>
>>> -  bool ShouldAddImport = !IsInModuleIncludes;
>>> +  bool ShouldAddImport = !IsInModuleIncludes && !NoImport;
>>>
>>>// If this module import was due to an inclusion directive, create an
>>>// implicit import declaration to capture it in the AST.
>>> @@ -15713,7 +15714,11 @@ void Sema::ActOnModuleEnd(SourceLocation
>>>assert(File != getSourceManager().getMainFileID() &&
>>>   "end of submodule in main source file");
>>>SourceLocation DirectiveLoc = getSourceManager().getIncludeLoc(File);
>>> -  BuildModuleInclude(DirectiveLoc, Mod);
>>> +  // Do not create implicit ImportDecl if we are building the
>>> implementation
>>> +  // of a module.
>>> +  bool NoImport = Mod->getTopLevelModuleName() ==
>>> getLangOpts().CurrentModule &&
>>> +  !getLangOpts().isCompilingModule();
>>> +  BuildModuleInclude(DirectiveLoc, Mod, NoImport);
>>>  }
>>>
>>>  void Sema::createImplicitModuleImportForErrorRecovery(SourceLocation
>>> Loc,
>>>
>>> Added: cfe/trunk/test/Modules/Inputs/module-impl-with-link/foo.h
>>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/I
>>> 

[PATCH] D26267: [Modules] Include builtins with #include instead of #import for ObjC

2017-01-10 Thread Bruno Cardoso Lopes via Phabricator via cfe-commits
bruno closed this revision.
bruno added a comment.

Thanks for the review Richard.

Committed 291644




Comment at: lib/Lex/HeaderSearch.cpp:1082
 
+  auto TryEnterImported = [&](void) -> bool {
+if (!ModulesEnabled)

rsmith wrote:
> Maybe add a FIXME here indicating that this is a workaround for the lack of 
> proper modules-aware support for `#import` / `#pragma once`?
Done. 


https://reviews.llvm.org/D26267



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


r291644 - [Modules] Support #import when entering files with modules

2017-01-10 Thread Bruno Cardoso Lopes via cfe-commits
Author: bruno
Date: Tue Jan 10 20:14:51 2017
New Revision: 291644

URL: http://llvm.org/viewvc/llvm-project?rev=291644=rev
Log:
[Modules] Support #import when entering files with modules

Textual headers and builtins that are #import'd from different
modules should get re-entered when these modules are independent
from each other.

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

rdar://problem/25881934

Added:
cfe/trunk/test/Modules/Inputs/import-textual/
cfe/trunk/test/Modules/Inputs/import-textual/M/
cfe/trunk/test/Modules/Inputs/import-textual/M/A/
cfe/trunk/test/Modules/Inputs/import-textual/M/A/A.h
cfe/trunk/test/Modules/Inputs/import-textual/M/B/
cfe/trunk/test/Modules/Inputs/import-textual/M/B/B.h
cfe/trunk/test/Modules/Inputs/import-textual/M/module.modulemap
cfe/trunk/test/Modules/Inputs/import-textual/M/someheader.h
cfe/trunk/test/Modules/Inputs/import-textual/M2/
cfe/trunk/test/Modules/Inputs/import-textual/M2/A/
cfe/trunk/test/Modules/Inputs/import-textual/M2/A/A.h
cfe/trunk/test/Modules/Inputs/import-textual/M2/B/
cfe/trunk/test/Modules/Inputs/import-textual/M2/B/B.h
cfe/trunk/test/Modules/Inputs/import-textual/M2/module.modulemap
cfe/trunk/test/Modules/Inputs/import-textual/M2/someheader.h
cfe/trunk/test/Modules/Inputs/libc-libcxx/sysroot/usr/include/c++/v1/cstddef

cfe/trunk/test/Modules/Inputs/libc-libcxx/sysroot/usr/include/c++/v1/type_traits
cfe/trunk/test/Modules/Inputs/libc-libcxx/sysroot/usr/include/sys/
cfe/trunk/test/Modules/Inputs/libc-libcxx/sysroot/usr/include/sys/_types/

cfe/trunk/test/Modules/Inputs/libc-libcxx/sysroot/usr/include/sys/_types/_ptrdiff_t.h

cfe/trunk/test/Modules/Inputs/libc-libcxx/sysroot/usr/include/sys/_types/_types.h
cfe/trunk/test/Modules/builtin-import.mm
cfe/trunk/test/Modules/import-textual-noguard.mm
cfe/trunk/test/Modules/import-textual.mm
Modified:
cfe/trunk/include/clang/Lex/HeaderSearch.h
cfe/trunk/include/clang/Lex/ModuleMap.h
cfe/trunk/lib/Lex/HeaderSearch.cpp
cfe/trunk/lib/Lex/ModuleMap.cpp
cfe/trunk/lib/Lex/PPDirectives.cpp
cfe/trunk/test/Modules/Inputs/libc-libcxx/sysroot/usr/include/c++/v1/math.h

cfe/trunk/test/Modules/Inputs/libc-libcxx/sysroot/usr/include/c++/v1/module.modulemap

cfe/trunk/test/Modules/Inputs/libc-libcxx/sysroot/usr/include/c++/v1/stddef.h

cfe/trunk/test/Modules/Inputs/libc-libcxx/sysroot/usr/include/module.modulemap
cfe/trunk/test/Modules/Inputs/libc-libcxx/sysroot/usr/include/stddef.h

Modified: cfe/trunk/include/clang/Lex/HeaderSearch.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Lex/HeaderSearch.h?rev=291644=291643=291644=diff
==
--- cfe/trunk/include/clang/Lex/HeaderSearch.h (original)
+++ cfe/trunk/include/clang/Lex/HeaderSearch.h Tue Jan 10 20:14:51 2017
@@ -406,7 +406,8 @@ public:
   /// \return false if \#including the file will have no effect or true
   /// if we should include it.
   bool ShouldEnterIncludeFile(Preprocessor , const FileEntry *File,
-  bool isImport, Module *CorrespondingModule);
+  bool isImport, bool ModulesEnabled,
+  Module *CorrespondingModule);
 
   /// \brief Return whether the specified file is a normal header,
   /// a system header, or a C++ friendly system header.

Modified: cfe/trunk/include/clang/Lex/ModuleMap.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Lex/ModuleMap.h?rev=291644=291643=291644=diff
==
--- cfe/trunk/include/clang/Lex/ModuleMap.h (original)
+++ cfe/trunk/include/clang/Lex/ModuleMap.h Tue Jan 10 20:14:51 2017
@@ -316,6 +316,14 @@ public:
 BuiltinIncludeDir = Dir;
   }
 
+  /// \brief Get the directory that contains Clang-supplied include files.
+  const DirectoryEntry *getBuiltinDir() const {
+return BuiltinIncludeDir;
+  }
+
+  /// \brief Is this a compiler builtin header?
+  static bool isBuiltinHeader(StringRef FileName);
+
   /// \brief Add a module map callback.
   void addModuleMapCallbacks(std::unique_ptr Callback) {
 Callbacks.push_back(std::move(Callback));

Modified: cfe/trunk/lib/Lex/HeaderSearch.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/HeaderSearch.cpp?rev=291644=291643=291644=diff
==
--- cfe/trunk/lib/Lex/HeaderSearch.cpp (original)
+++ cfe/trunk/lib/Lex/HeaderSearch.cpp Tue Jan 10 20:14:51 2017
@@ -1092,13 +1092,51 @@ void HeaderSearch::MarkFileModuleHeader(
 }
 
 bool HeaderSearch::ShouldEnterIncludeFile(Preprocessor ,
-  const FileEntry *File,
-  bool isImport, Module *M) {
+  const FileEntry *File, bool 

[PATCH] D28543: Elliminates uninitialized warning for volitile varibles.

2017-01-10 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

Thanks! Can you add a test somewhere?  `grep -R W.*uninitialized test/Sema*` 
will probably show you the existing test for this code. (Another technique: 
Comment some of the existing tests, run `ninja check-clang`, and see which 
tests start failing.)

You can run an individual test via `bin/llvm-lit 
../../llvm/tools/clang/test/Sema/mytest.cc`.




Comment at: clang/lib/Sema/AnalysisBasedWarnings.cpp:907
 else
   DiagUninitUse(S, VD, Use, true);
   }

Should the check be in DiagUninitUse()? Or is there a reason this one should 
happen for volatiles?


https://reviews.llvm.org/D28543



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


Re: r291628 - Module: Do not create Implicit ImportDecl for module X if we

2017-01-10 Thread Richard Smith via cfe-commits
On 10 January 2017 at 17:57, Richard Smith  wrote:

> On 10 January 2017 at 16:48, Manman Ren via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: mren
>> Date: Tue Jan 10 18:48:19 2017
>> New Revision: 291628
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=291628=rev
>> Log:
>> Module: Do not create Implicit ImportDecl for module X if we
>>  are building an implemenation of module X.
>>
>
> Hmm. We do actually have an include mapping to a module header in this
> case. Perhaps it would be better to create a faithful AST representation
> and handle this in CodeGen instead -- we should not add any link flags when
> an implementation TU of a module imports a header of that same module.
>

It's worth pointing out that the C++ modules TS allows a modular import of
a module interface into an implementation unit of that module, so the
current approach won't work for that case, but filtering these imports out
in CodeGen would work.


> This fixes a regression caused by r280409.
>> rdar://problem/29930553
>>
>> Added:
>> cfe/trunk/test/Modules/Inputs/module-impl-with-link/
>> cfe/trunk/test/Modules/Inputs/module-impl-with-link/foo.h
>> cfe/trunk/test/Modules/Inputs/module-impl-with-link/module.modulemap
>> cfe/trunk/test/Modules/module-impl-with-link.c
>> Modified:
>> cfe/trunk/include/clang/Sema/Sema.h
>> cfe/trunk/lib/Sema/SemaDecl.cpp
>>
>> Modified: cfe/trunk/include/clang/Sema/Sema.h
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/
>> Sema/Sema.h?rev=291628=291627=291628=diff
>> 
>> ==
>> --- cfe/trunk/include/clang/Sema/Sema.h (original)
>> +++ cfe/trunk/include/clang/Sema/Sema.h Tue Jan 10 18:48:19 2017
>> @@ -1905,7 +1905,8 @@ public:
>>/// \brief The parser has processed a module import translated from a
>>/// #include or similar preprocessing directive.
>>void ActOnModuleInclude(SourceLocation DirectiveLoc, Module *Mod);
>> -  void BuildModuleInclude(SourceLocation DirectiveLoc, Module *Mod);
>> +  void BuildModuleInclude(SourceLocation DirectiveLoc, Module *Mod,
>> +  bool NoImport);
>>
>>/// \brief The parsed has entered a submodule.
>>void ActOnModuleBegin(SourceLocation DirectiveLoc, Module *Mod);
>>
>> Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaD
>> ecl.cpp?rev=291628=291627=291628=diff
>> 
>> ==
>> --- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
>> +++ cfe/trunk/lib/Sema/SemaDecl.cpp Tue Jan 10 18:48:19 2017
>> @@ -15652,10 +15652,11 @@ DeclResult Sema::ActOnModuleImport(Sourc
>>
>>  void Sema::ActOnModuleInclude(SourceLocation DirectiveLoc, Module *Mod)
>> {
>>checkModuleImportContext(*this, Mod, DirectiveLoc, CurContext, true);
>> -  BuildModuleInclude(DirectiveLoc, Mod);
>> +  BuildModuleInclude(DirectiveLoc, Mod, false/*NoImport*/);
>>  }
>>
>> -void Sema::BuildModuleInclude(SourceLocation DirectiveLoc, Module *Mod)
>> {
>> +void Sema::BuildModuleInclude(SourceLocation DirectiveLoc, Module *Mod,
>> +  bool NoImport) {
>>// Determine whether we're in the #include buffer for a module. The
>> #includes
>>// in that buffer do not qualify as module imports; they're just an
>>// implementation detail of us building the module.
>> @@ -15665,7 +15666,7 @@ void Sema::BuildModuleInclude(SourceLoca
>>TUKind == TU_Module &&
>>getSourceManager().isWrittenInMainFile(DirectiveLoc);
>>
>> -  bool ShouldAddImport = !IsInModuleIncludes;
>> +  bool ShouldAddImport = !IsInModuleIncludes && !NoImport;
>>
>>// If this module import was due to an inclusion directive, create an
>>// implicit import declaration to capture it in the AST.
>> @@ -15713,7 +15714,11 @@ void Sema::ActOnModuleEnd(SourceLocation
>>assert(File != getSourceManager().getMainFileID() &&
>>   "end of submodule in main source file");
>>SourceLocation DirectiveLoc = getSourceManager().getIncludeLoc(File);
>> -  BuildModuleInclude(DirectiveLoc, Mod);
>> +  // Do not create implicit ImportDecl if we are building the
>> implementation
>> +  // of a module.
>> +  bool NoImport = Mod->getTopLevelModuleName() ==
>> getLangOpts().CurrentModule &&
>> +  !getLangOpts().isCompilingModule();
>> +  BuildModuleInclude(DirectiveLoc, Mod, NoImport);
>>  }
>>
>>  void Sema::createImplicitModuleImportForErrorRecovery(SourceLocation
>> Loc,
>>
>> Added: cfe/trunk/test/Modules/Inputs/module-impl-with-link/foo.h
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/
>> Inputs/module-impl-with-link/foo.h?rev=291628=auto
>> 
>> ==
>> --- cfe/trunk/test/Modules/Inputs/module-impl-with-link/foo.h (added)
>> +++ 

[PATCH] D28543: Elliminates uninitialized warning for volitile varibles.

2017-01-10 Thread CJ DiMeglio via Phabricator via cfe-commits
lethalantidote created this revision.
lethalantidote added a reviewer: thakis.
lethalantidote added a subscriber: cfe-commits.

Elliminates uninitialized warning for volitile variables.


https://reviews.llvm.org/D28543

Files:
  clang/lib/Sema/AnalysisBasedWarnings.cpp


Index: clang/lib/Sema/AnalysisBasedWarnings.cpp
===
--- clang/lib/Sema/AnalysisBasedWarnings.cpp
+++ clang/lib/Sema/AnalysisBasedWarnings.cpp
@@ -864,7 +864,7 @@
 /// false.
 static bool DiagnoseUninitializedUse(Sema , const VarDecl *VD,
  const UninitUse ,
- bool alwaysReportSelfInit = false) {
+ bool alwaysReportSelfInit = false) { 
   if (const DeclRefExpr *DRE = dyn_cast(Use.getUser())) {
 // Inspect the initializer of the variable declaration which is
 // being referenced prior to its initialization. We emit
@@ -891,6 +891,11 @@
   }
 }
 
+// If volatile, we don't raise this warning.
+if (VD->getType().isVolatileQualified()) {
+  return false;
+}
+
 DiagUninitUse(S, VD, Use, false);
   } else {
 const BlockExpr *BE = cast(Use.getUser());


Index: clang/lib/Sema/AnalysisBasedWarnings.cpp
===
--- clang/lib/Sema/AnalysisBasedWarnings.cpp
+++ clang/lib/Sema/AnalysisBasedWarnings.cpp
@@ -864,7 +864,7 @@
 /// false.
 static bool DiagnoseUninitializedUse(Sema , const VarDecl *VD,
  const UninitUse ,
- bool alwaysReportSelfInit = false) {
+ bool alwaysReportSelfInit = false) { 
   if (const DeclRefExpr *DRE = dyn_cast(Use.getUser())) {
 // Inspect the initializer of the variable declaration which is
 // being referenced prior to its initialization. We emit
@@ -891,6 +891,11 @@
   }
 }
 
+// If volatile, we don't raise this warning.
+if (VD->getType().isVolatileQualified()) {
+  return false;
+}
+
 DiagUninitUse(S, VD, Use, false);
   } else {
 const BlockExpr *BE = cast(Use.getUser());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D28467: [Sema] Add warning for unused lambda captures

2017-01-10 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: include/clang/Sema/ScopeInfo.h:457
+/// lambda.
+bool Used = false;
+

arphaman wrote:
> malcolm.parsons wrote:
> > Should this be moved into one of the `PointerIntPair`s?
> I'm not sure.. If we needed other capturing information in the future I would 
> say that this should be its own field, but I'm not aware of anything else 
> that's needed for this class. So I guess it would be better to pack it into 
> `VarAndNestedAndThis`, but I wouldn't say it's a deal breaker.
I'm not keen on inconsistently initializating data members; can you perform 
this initialization in the constructor instead?



Comment at: lib/Parse/ParseExprCXX.cpp:738
 /// \return A DiagnosticID if it hit something unexpected. The location for
-/// for the diagnostic is that of the current token.
+/// the diagnostic is that of the current token.
 Optional Parser::ParseLambdaIntroducer(LambdaIntroducer ,

This change is unrelated to the patch; you can go ahead and commit it without 
review rather than have it as part of this patch.



Comment at: lib/Sema/SemaLambda.cpp:1479
 for (unsigned I = 0, N = LSI->Captures.size(); I != N; ++I, ++CurField) {
-  LambdaScopeInfo::Capture From = LSI->Captures[I];
+  LambdaScopeInfo::Capture  = LSI->Captures[I];
   assert(!From.isBlockCapture() && "Cannot capture __block variables");

Why does `From` need to be a non-const reference?



Comment at: lib/Sema/SemaLambda.cpp:1483
 
+  // Warn about unused explicit captures
+  if (!CurContext->isDependentContext() && !IsImplicit && !From.isUsed()) {

Missing a full stop at the end of the comment.



Comment at: test/SemaCXX/warn-unused-lambda-capture.cpp:17
+  auto explicit_by_value_unused = [i] {}; // expected-warning{{lambda capture 
'i' is not used}}
+  auto explicit_by_value_unused_sizeof = [i] { return sizeof(i); }; // 
expected-warning{{lambda capture 'i' is not used}}
+

This does not match the behavior for other -Wunused flags. e.g.,
```
void f() {
  int i;
  (void)sizeof(i);
}
```
I don't think diagnosing this test case is correct.



Comment at: test/SemaCXX/warn-unused-lambda-capture.cpp:59
+  auto explicit_by_value_unused = [i] {}; // expected-warning{{lambda capture 
'i' is not used}}
+  auto explicit_by_value_unused_sizeof = [i] { return sizeof(i); }; // 
expected-warning{{lambda capture 'i' is not used}}
+

Likewise here.


https://reviews.llvm.org/D28467



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


r291635 - [analyzer] Fix crash in body farm for getter without implicit self.

2017-01-10 Thread Devin Coughlin via cfe-commits
Author: dcoughlin
Date: Tue Jan 10 19:02:34 2017
New Revision: 291635

URL: http://llvm.org/viewvc/llvm-project?rev=291635=rev
Log:
[analyzer] Fix crash in body farm for getter without implicit self.

Fix a crash in body farm when synthesizing a getter for a property
synthesized for a property declared in a protocol on a class extension
that shadows a declaration of the property in a category.

In this case, Sema doesn't fill in the implicit 'self' parameter for the getter
in the category, which leads to a crash when trying to synthesize the getter
for it.

To avoid the crash, skip getter synthesis in body farm if the self parameter is
not filled int.

rdar://problem/29938138

Modified:
cfe/trunk/lib/Analysis/BodyFarm.cpp
cfe/trunk/test/Analysis/properties.m

Modified: cfe/trunk/lib/Analysis/BodyFarm.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Analysis/BodyFarm.cpp?rev=291635=291634=291635=diff
==
--- cfe/trunk/lib/Analysis/BodyFarm.cpp (original)
+++ cfe/trunk/lib/Analysis/BodyFarm.cpp Tue Jan 10 19:02:34 2017
@@ -467,6 +467,8 @@ static Stmt *createObjCPropertyGetter(AS
   ASTMaker M(Ctx);
 
   const VarDecl *selfVar = Prop->getGetterMethodDecl()->getSelfDecl();
+  if (!selfVar)
+return nullptr;
 
   Expr *loadedIVar =
 M.makeObjCIvarRef(

Modified: cfe/trunk/test/Analysis/properties.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/properties.m?rev=291635=291634=291635=diff
==
--- cfe/trunk/test/Analysis/properties.m (original)
+++ cfe/trunk/test/Analysis/properties.m Tue Jan 10 19:02:34 2017
@@ -315,6 +315,32 @@ void testConsistencyAssign(Person *p) {
 }
 @end
 
+__attribute__((objc_root_class))
+@interface 
ClassWithPrivatePropertyInClassExtensionWithProtocolShadowingCategory
+@end
+
+@protocol HasStuff
+@property (nonatomic, readonly) int stuffProperty;
+@end
+
+@interface 
ClassWithPrivatePropertyInClassExtensionWithProtocolShadowingCategory (Private)
+@property (nonatomic, readonly) int stuffProperty;
+@end
+
+@interface 
ClassWithPrivatePropertyInClassExtensionWithProtocolShadowingCategory 
(Internal) 
+@end
+
+@interface 
ClassWithPrivatePropertyInClassExtensionWithProtocolShadowingCategory() 

+@end
+
+@implementation 
ClassWithPrivatePropertyInClassExtensionWithProtocolShadowingCategory
+@synthesize stuffProperty = _stuffProperty;
+
+-(void)foo {
+  (void)self.stuffProperty;
+}
+@end
+
 //--
 // Setter ivar invalidation.
 //--


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


[libcxx] r291632 - [CMake][libcxx] Do not rely on the existence of c++abi or unwind targets

2017-01-10 Thread Petr Hosek via cfe-commits
Author: phosek
Date: Tue Jan 10 18:56:10 2017
New Revision: 291632

URL: http://llvm.org/viewvc/llvm-project?rev=291632=rev
Log:
[CMake][libcxx] Do not rely on the existence of c++abi or unwind targets

There is no guaranteed order in which CMake files for individual
runtimes are invoked and therefore we cannot rely on existence of
targets defined in other runtimes. Use the new HAVE_ options
instead in those cases.

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

Modified:
libcxx/trunk/CMakeLists.txt
libcxx/trunk/lib/CMakeLists.txt

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=291632=291631=291632=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Tue Jan 10 18:56:10 2017
@@ -119,8 +119,7 @@ if (LIBCXX_CXX_ABI STREQUAL "default")
   ${LLVM_MAIN_SRC_DIR}/runtimes/libcxxabi/include
 NO_DEFAULT_PATH
   )
-  if (NOT DEFINED LIBCXX_STANDALONE_BUILD AND
-  IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
+  if (IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
 set(LIBCXX_CXX_ABI_INCLUDE_PATHS "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_INTREE 1)

Modified: libcxx/trunk/lib/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/lib/CMakeLists.txt?rev=291632=291631=291632=diff
==
--- libcxx/trunk/lib/CMakeLists.txt (original)
+++ libcxx/trunk/lib/CMakeLists.txt Tue Jan 10 18:56:10 2017
@@ -229,7 +229,8 @@ if (LIBCXX_ENABLE_STATIC)
 if (LIBCXX_CXX_ABI_LIBRARY_PATH)
   set(MERGE_ARCHIVES_SEARCH_PATHS "-L${LIBCXX_CXX_ABI_LIBRARY_PATH}")
 endif()
-if (TARGET ${LIBCXX_CXX_ABI_LIBRARY})
+if ((TARGET ${LIBCXX_CXX_ABI_LIBRARY}) OR
+(${LIBCXX_CXX_ABI_LIBRARY} STREQUAL "cxxabi(_static|_shared)?" AND 
HAVE_LIBCXXABI))
   set(MERGE_ARCHIVES_ABI_TARGET 
"$")
 else()
   set(MERGE_ARCHIVES_ABI_TARGET
@@ -300,7 +301,9 @@ if (LIBCXX_ENABLE_SHARED AND LIBCXX_ENAB
   set(LIBCXX_INTERFACE_LIBRARY_NAMES)
   foreach(lib ${LIBCXX_INTERFACE_LIBRARIES})
 # FIXME: Handle cxxabi_static and unwind_static.
-if (TARGET ${lib})
+if (TARGET ${lib} OR
+(${lib} MATCHES "cxxabi(_static|_shared)?" AND HAVE_LIBCXXABI) OR
+(${lib} MATCHES "unwind(_static|_shared)?" AND HAVE_LIBUNWIND))
   list(APPEND LIBCXX_INTERFACE_LIBRARY_NAMES 
"$")
 else()
   list(APPEND LIBCXX_INTERFACE_LIBRARY_NAMES "${lib}")


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


[PATCH] D20693: [clang-tidy] New checker to replace dynamic exception specifications

2017-01-10 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: docs/clang-tidy/checks/modernize-use-noexcept.rst:6-8
+The check converts dynamic exception specifications, e.g.,
+``throw()``, ``throw([,...])``, or ``throw(...)``, to
+``noexcept``, ``noexcept(false)``, blank, or a user defined macro.

hintonda wrote:
> alexfh wrote:
> > alexfh wrote:
> > > This description doesn't say why `noexcept` is better.
> > This still needs to be addressed.
> Absolutely, but I'll probably do all the code changes first while it's still 
> fresh in my mind. 
Since we're talking about documentation, should we note that this check does 
produce a subtle, obscure change in behavior? When you have `throw()` on a 
function signature and that function winds up throwing something, this would 
result in `std::unexpected()` being called. When that gets modified to be 
`noexcept`, the call to `std::unexpected()` is replaced by a call to 
`std::terminate()`. This hopefully does not break any code, but we may want to 
document the fact that failing to honor a dynamic exception specification is 
slightly different than failing to honor an exception specification so that 
users are aware of the slightly different semantics.


https://reviews.llvm.org/D20693



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


[PATCH] D24991: Inline hot functions in libcxx shared_ptr implementation.

2017-01-10 Thread Kuba (Brecka) Mracek via Phabricator via cfe-commits
kubabrecka added inline comments.



Comment at: libcxx/include/memory:3702
+inline T
+__libcpp_atomic_increment(T& t) _NOEXCEPT
+{

I don't think this should be named `__libcpp_atomic_increment`, because it uses 
relaxed ordering and thus it's not a generic increment (same goes for 
decrement).  Could we rename this to `__libcpp_atomic_refcount_increment` or 
something similar?  That would suggest why we're using acq+rel on one side and 
relaxed on other side.  Using these functions for non-refcount purposes will be 
wrong and the current names (`__libcpp_atomic_increment`) suggest that they're 
doing generic atomic operations.


Repository:
  rL LLVM

https://reviews.llvm.org/D24991



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


Re: r280409 - When we reach the end of a #include of a header of a local submodule that we

2017-01-10 Thread Manman via cfe-commits
Hi Richard,

I fixed a regression caused by this commit in r291628.

Let me know if you see any problem!

Manman

> On Sep 1, 2016, at 1:15 PM, Richard Smith via cfe-commits 
>  wrote:
> 
> Author: rsmith
> Date: Thu Sep  1 15:15:25 2016
> New Revision: 280409
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=280409=rev
> Log:
> When we reach the end of a #include of a header of a local submodule that we
> textually included, create an ImportDecl just as we would if we reached a
> #include of any other modular header. This is necessary in order to correctly
> determine the set of variables to initialize for an imported module.
> 
> This should hopefully make the modules selfhost buildbot green again.
> 
> Added:
>cfe/trunk/test/Modules/global-init.cpp
> Modified:
>cfe/trunk/include/clang/Sema/Sema.h
>cfe/trunk/lib/Sema/SemaDecl.cpp
>cfe/trunk/tools/libclang/CXIndexDataConsumer.cpp
> 
> Modified: cfe/trunk/include/clang/Sema/Sema.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=280409=280408=280409=diff
> ==
> --- cfe/trunk/include/clang/Sema/Sema.h (original)
> +++ cfe/trunk/include/clang/Sema/Sema.h Thu Sep  1 15:15:25 2016
> @@ -1884,6 +1884,7 @@ public:
>   /// \brief The parser has processed a module import translated from a
>   /// #include or similar preprocessing directive.
>   void ActOnModuleInclude(SourceLocation DirectiveLoc, Module *Mod);
> +  void BuildModuleInclude(SourceLocation DirectiveLoc, Module *Mod);
> 
>   /// \brief The parsed has entered a submodule.
>   void ActOnModuleBegin(SourceLocation DirectiveLoc, Module *Mod);
> 
> Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=280409=280408=280409=diff
> ==
> --- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaDecl.cpp Thu Sep  1 15:15:25 2016
> @@ -15312,7 +15312,10 @@ DeclResult Sema::ActOnModuleImport(Sourc
> 
> void Sema::ActOnModuleInclude(SourceLocation DirectiveLoc, Module *Mod) {
>   checkModuleImportContext(*this, Mod, DirectiveLoc, CurContext, true);
> +  BuildModuleInclude(DirectiveLoc, Mod);
> +}
> 
> +void Sema::BuildModuleInclude(SourceLocation DirectiveLoc, Module *Mod) {
>   // Determine whether we're in the #include buffer for a module. The 
> #includes
>   // in that buffer do not qualify as module imports; they're just an
>   // implementation detail of us building the module.
> @@ -15352,20 +15355,27 @@ void Sema::ActOnModuleBegin(SourceLocati
>   VisibleModules.setVisible(Mod, DirectiveLoc);
> }
> 
> -void Sema::ActOnModuleEnd(SourceLocation DirectiveLoc, Module *Mod) {
> -  checkModuleImportContext(*this, Mod, DirectiveLoc, CurContext);
> +void Sema::ActOnModuleEnd(SourceLocation EofLoc, Module *Mod) {
> +  checkModuleImportContext(*this, Mod, EofLoc, CurContext);
> 
>   if (getLangOpts().ModulesLocalVisibility) {
> -assert(!ModuleScopes.empty() && ModuleScopes.back().Module == Mod &&
> -   "left the wrong module scope");
> VisibleModules = std::move(ModuleScopes.back().OuterVisibleModules);
> -ModuleScopes.pop_back();
> -
> -VisibleModules.setVisible(Mod, DirectiveLoc);
> // Leaving a module hides namespace names, so our visible namespace cache
> // is now out of date.
> VisibleNamespaceCache.clear();
>   }
> +
> +  assert(!ModuleScopes.empty() && ModuleScopes.back().Module == Mod &&
> + "left the wrong module scope");
> +  ModuleScopes.pop_back();
> +
> +  // We got to the end of processing a #include of a local module. Create an
> +  // ImportDecl as we would for an imported module.
> +  FileID File = getSourceManager().getFileID(EofLoc);
> +  assert(File != getSourceManager().getMainFileID() &&
> + "end of submodule in main source file");
> +  SourceLocation DirectiveLoc = getSourceManager().getIncludeLoc(File);
> +  BuildModuleInclude(DirectiveLoc, Mod);
> }
> 
> void Sema::createImplicitModuleImportForErrorRecovery(SourceLocation Loc,
> 
> Added: cfe/trunk/test/Modules/global-init.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/global-init.cpp?rev=280409=auto
> ==
> --- cfe/trunk/test/Modules/global-init.cpp (added)
> +++ cfe/trunk/test/Modules/global-init.cpp Thu Sep  1 15:15:25 2016
> @@ -0,0 +1,19 @@
> +// RUN: rm -rf %t
> +// RUN: mkdir %t
> +//
> +// RUN: echo '#pragma once' > %t/a.h
> +// RUN: echo 'struct A { A() {} int f() const; } const a;' >> %t/a.h
> +//
> +// RUN: echo '#include "a.h"' > %t/b.h
> +//
> +// RUN: echo 'module M { module b { header "b.h" export * } module a { 
> header "a.h" export * } }' > %t/map
> +//
> +// RUN: %clang_cc1 -fmodules -fmodules-cache-path=%t 
> -fmodule-map-file=%t/map -I%t %s -emit-llvm -o 

r291628 - Module: Do not create Implicit ImportDecl for module X if we

2017-01-10 Thread Manman Ren via cfe-commits
Author: mren
Date: Tue Jan 10 18:48:19 2017
New Revision: 291628

URL: http://llvm.org/viewvc/llvm-project?rev=291628=rev
Log:
Module: Do not create Implicit ImportDecl for module X if we
 are building an implemenation of module X.

This fixes a regression caused by r280409.
rdar://problem/29930553

Added:
cfe/trunk/test/Modules/Inputs/module-impl-with-link/
cfe/trunk/test/Modules/Inputs/module-impl-with-link/foo.h
cfe/trunk/test/Modules/Inputs/module-impl-with-link/module.modulemap
cfe/trunk/test/Modules/module-impl-with-link.c
Modified:
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Sema/SemaDecl.cpp

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=291628=291627=291628=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Tue Jan 10 18:48:19 2017
@@ -1905,7 +1905,8 @@ public:
   /// \brief The parser has processed a module import translated from a
   /// #include or similar preprocessing directive.
   void ActOnModuleInclude(SourceLocation DirectiveLoc, Module *Mod);
-  void BuildModuleInclude(SourceLocation DirectiveLoc, Module *Mod);
+  void BuildModuleInclude(SourceLocation DirectiveLoc, Module *Mod,
+  bool NoImport);
 
   /// \brief The parsed has entered a submodule.
   void ActOnModuleBegin(SourceLocation DirectiveLoc, Module *Mod);

Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=291628=291627=291628=diff
==
--- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDecl.cpp Tue Jan 10 18:48:19 2017
@@ -15652,10 +15652,11 @@ DeclResult Sema::ActOnModuleImport(Sourc
 
 void Sema::ActOnModuleInclude(SourceLocation DirectiveLoc, Module *Mod) {
   checkModuleImportContext(*this, Mod, DirectiveLoc, CurContext, true);
-  BuildModuleInclude(DirectiveLoc, Mod);
+  BuildModuleInclude(DirectiveLoc, Mod, false/*NoImport*/);
 }
 
-void Sema::BuildModuleInclude(SourceLocation DirectiveLoc, Module *Mod) {
+void Sema::BuildModuleInclude(SourceLocation DirectiveLoc, Module *Mod,
+  bool NoImport) {
   // Determine whether we're in the #include buffer for a module. The #includes
   // in that buffer do not qualify as module imports; they're just an
   // implementation detail of us building the module.
@@ -15665,7 +15666,7 @@ void Sema::BuildModuleInclude(SourceLoca
   TUKind == TU_Module &&
   getSourceManager().isWrittenInMainFile(DirectiveLoc);
 
-  bool ShouldAddImport = !IsInModuleIncludes;
+  bool ShouldAddImport = !IsInModuleIncludes && !NoImport;
 
   // If this module import was due to an inclusion directive, create an
   // implicit import declaration to capture it in the AST.
@@ -15713,7 +15714,11 @@ void Sema::ActOnModuleEnd(SourceLocation
   assert(File != getSourceManager().getMainFileID() &&
  "end of submodule in main source file");
   SourceLocation DirectiveLoc = getSourceManager().getIncludeLoc(File);
-  BuildModuleInclude(DirectiveLoc, Mod);
+  // Do not create implicit ImportDecl if we are building the implementation
+  // of a module.
+  bool NoImport = Mod->getTopLevelModuleName() == getLangOpts().CurrentModule 
&&
+  !getLangOpts().isCompilingModule();
+  BuildModuleInclude(DirectiveLoc, Mod, NoImport);
 }
 
 void Sema::createImplicitModuleImportForErrorRecovery(SourceLocation Loc,

Added: cfe/trunk/test/Modules/Inputs/module-impl-with-link/foo.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/module-impl-with-link/foo.h?rev=291628=auto
==
--- cfe/trunk/test/Modules/Inputs/module-impl-with-link/foo.h (added)
+++ cfe/trunk/test/Modules/Inputs/module-impl-with-link/foo.h Tue Jan 10 
18:48:19 2017
@@ -0,0 +1 @@
+//empty

Added: cfe/trunk/test/Modules/Inputs/module-impl-with-link/module.modulemap
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/module-impl-with-link/module.modulemap?rev=291628=auto
==
--- cfe/trunk/test/Modules/Inputs/module-impl-with-link/module.modulemap (added)
+++ cfe/trunk/test/Modules/Inputs/module-impl-with-link/module.modulemap Tue 
Jan 10 18:48:19 2017
@@ -0,0 +1,4 @@
+module Clib {
+  header "foo.h"
+  link "Clib"
+}

Added: cfe/trunk/test/Modules/module-impl-with-link.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/module-impl-with-link.c?rev=291628=auto
==
--- cfe/trunk/test/Modules/module-impl-with-link.c (added)
+++ cfe/trunk/test/Modules/module-impl-with-link.c Tue Jan 10 18:48:19 2017
@@ -0,0 +1,7 @@
+// 

[PATCH] D20693: [clang-tidy] New checker to replace dynamic exception specifications

2017-01-10 Thread don hinton via Phabricator via cfe-commits
hintonda added inline comments.



Comment at: docs/clang-tidy/checks/modernize-use-noexcept.rst:6-8
+The check converts dynamic exception specifications, e.g.,
+``throw()``, ``throw([,...])``, or ``throw(...)``, to
+``noexcept``, ``noexcept(false)``, blank, or a user defined macro.

alexfh wrote:
> alexfh wrote:
> > This description doesn't say why `noexcept` is better.
> This still needs to be addressed.
Absolutely, but I'll probably do all the code changes first while it's still 
fresh in my mind. 


https://reviews.llvm.org/D20693



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


LLVM buildmaster will be updated and restarted tonight

2017-01-10 Thread Galina Kistanova via cfe-commits
Hello everyone,

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

Thanks

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


[PATCH] D28299: Module: use PCMCache to manage memory buffers for pcm files.

2017-01-10 Thread Ben Langmuir via Phabricator via cfe-commits
benlangmuir added inline comments.



Comment at: include/clang/Basic/FileManager.h:176
+  /// Manage memory buffers associated with pcm files.
+  std::unique_ptr BufferMgr;
+

manmanren wrote:
> benlangmuir wrote:
> > Why is this inside the FileManager? It isn't used by the FileManager.
> I initially had another patch that puts PCMCache object at the top level (i.e 
> whenever we create a FileManager, we create a PCMCache object). The initial 
> patch is much bigger than this patch. PCMCache is cacheing the content of a 
> PCM File, and is shared across threads that we spawned to build modules 
> implicitly, just like FileManager. I had some discussions with Bruno and 
> Adrian, we felt FileManager is a better place. But if you have other 
> suggestions, please let me know!
I see.  It's not ideal, but I see why it would be convenient to use the 
FileManager this way, since you want to share it in all the same places the 
FileManager is shared.  Since I don't have any better answer, I guess I'm okay 
with this...



Comment at: include/clang/Basic/FileManager.h:308
+  /// a thread, we pop a ThreadContext.
+  struct ThreadContext {
+/// Keep track of all module files that have been validated in this thread

manmanren wrote:
> benlangmuir wrote:
> > Can we call this something like "ModuleLoadContext" or maybe 
> > "ModuleCompilationContext"?  The word thread is misleading, since the 
> > threads are not run concurrently, and are only an implementation detail of 
> > our crash recovery.
> > 
> > Also, can you explain why it is only necessary to keep information about 
> > the the current stack of contexts?  In a situation like
> > 
> > A imports B imports C
> > A imports D imports C
> > 
> > We would no longer have information about C being validated, right?  What 
> > happens if there's a mismatch there?  Can this never happen?
> Sure, we can call it ModuleCompilationContext because we are spawning threads 
> to build modules implicitly.
> 
> The issue we are trying to detect is use-after-free, i.e we don't want a 
> thread to hold on to an invalid FileEntry. We error out before trying to 
> delete the FileEntry that is live in another thread.
> 
> In a situation like
> A imports B imports C
> A imports D imports C
> 
> A will start a thread to build B, and B will start a thread to build C, C 
> will be validated in B's compilation thread and A's compilation thread. Later 
> on, if D tries to invalidate C, D knows that an ancestor thread A has 
> validated C, so the compiler will error out. And it is okay for A to 
> invalidate C in A's compilation thread, because we can clean up the 
> references to C's FileEntry.
> 
Okay


https://reviews.llvm.org/D28299



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


[PATCH] D20693: [clang-tidy] New checker to replace dynamic exception specifications

2017-01-10 Thread Alexander Kornienko via Phabricator via cfe-commits
alexfh requested changes to this revision.
alexfh added inline comments.
This revision now requires changes to proceed.



Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:99
+
+  assert(CRange.isValid() && "Exception Specification Range is invalid.");
+  assert(FnTy && "FunctionProtoType is null.");

I suspect there might be valid code that will trigger this assertion. I would 
issue the diagnostic, just without a FixItHint.



Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:111
+
+  diag(Range.getBegin(), "found dynamic exception specification '%0'")
+  << makeDynamicExceptionString(*Result.SourceManager, CRange) << FixIt;

The message neither explains what's wrong with the code, nor says what is a 
better alternative. Something like "dynamic exception specification '%0' is so 
1998 ; consider using 'noexcept(...)' 
" would lead to less user confusion.



Comment at: docs/clang-tidy/checks/modernize-use-noexcept.rst:6-8
+The check converts dynamic exception specifications, e.g.,
+``throw()``, ``throw([,...])``, or ``throw(...)``, to
+``noexcept``, ``noexcept(false)``, blank, or a user defined macro.

alexfh wrote:
> This description doesn't say why `noexcept` is better.
This still needs to be addressed.


https://reviews.llvm.org/D20693



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


[PATCH] D28503: Documentation for the newly added x86 intrinsics.

2017-01-10 Thread Albert Gutowski via Phabricator via cfe-commits
agutowski added a comment.

For my part, LGTM.


Repository:
  rL LLVM

https://reviews.llvm.org/D28503



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


r291610 - Remove dead code.

2017-01-10 Thread Richard Smith via cfe-commits
Author: rsmith
Date: Tue Jan 10 17:04:46 2017
New Revision: 291610

URL: http://llvm.org/viewvc/llvm-project?rev=291610=rev
Log:
Remove dead code.

Modified:
cfe/trunk/lib/Parse/Parser.cpp

Modified: cfe/trunk/lib/Parse/Parser.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/Parser.cpp?rev=291610=291609=291610=diff
==
--- cfe/trunk/lib/Parse/Parser.cpp (original)
+++ cfe/trunk/lib/Parse/Parser.cpp Tue Jan 10 17:04:46 2017
@@ -1737,17 +1737,12 @@ bool Parser::TryAnnotateTypeOrScopeToken
 bool Parser::TryAnnotateTypeOrScopeTokenAfterScopeSpec(CXXScopeSpec ,
bool IsNewScope) {
   if (Tok.is(tok::identifier)) {
-IdentifierInfo *CorrectedII = nullptr;
 // Determine whether the identifier is a type name.
 if (ParsedType Ty = Actions.getTypeName(
 *Tok.getIdentifierInfo(), Tok.getLocation(), getCurScope(), ,
 false, NextToken().is(tok::period), nullptr,
 /*IsCtorOrDtorName=*/false,
 /*NonTrivialTypeSourceInfo*/ true)) {
-  // A FixIt was applied as a result of typo correction
-  if (CorrectedII)
-Tok.setIdentifierInfo(CorrectedII);
-
   SourceLocation BeginLoc = Tok.getLocation();
   if (SS.isNotEmpty()) // it was a C++ qualified type name.
 BeginLoc = SS.getBeginLoc();


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


r291598 - [Driver] Add openSuse AArch64 Triple

2017-01-10 Thread Kostya Kortchinsky via cfe-commits
Author: cryptoad
Date: Tue Jan 10 15:13:08 2017
New Revision: 291598

URL: http://llvm.org/viewvc/llvm-project?rev=291598=rev
Log:
[Driver] Add openSuse AArch64 Triple

Summary:
openSuse has AArch64 support, with images running on the Raspberry Pi 3.
The libraries and headers live under the aarch64-suse-linux subdirectory,
which is currently not in the AArch64 triples list. Address this by adding
the corresponding string to AArch64Triples.

Reviewers: chandlerc, bruno, bkramer, rengolin

Subscribers: aemerson, rengolin, cfe-commits

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

Added:
cfe/trunk/test/Driver/Inputs/opensuse_42.2_aarch64_tree/
cfe/trunk/test/Driver/Inputs/opensuse_42.2_aarch64_tree/usr/
cfe/trunk/test/Driver/Inputs/opensuse_42.2_aarch64_tree/usr/lib64/
cfe/trunk/test/Driver/Inputs/opensuse_42.2_aarch64_tree/usr/lib64/crt1.o
cfe/trunk/test/Driver/Inputs/opensuse_42.2_aarch64_tree/usr/lib64/crti.o
cfe/trunk/test/Driver/Inputs/opensuse_42.2_aarch64_tree/usr/lib64/crtn.o
cfe/trunk/test/Driver/Inputs/opensuse_42.2_aarch64_tree/usr/lib64/gcc/

cfe/trunk/test/Driver/Inputs/opensuse_42.2_aarch64_tree/usr/lib64/gcc/aarch64-suse-linux/

cfe/trunk/test/Driver/Inputs/opensuse_42.2_aarch64_tree/usr/lib64/gcc/aarch64-suse-linux/4.8/

cfe/trunk/test/Driver/Inputs/opensuse_42.2_aarch64_tree/usr/lib64/gcc/aarch64-suse-linux/4.8/crtbegin.o

cfe/trunk/test/Driver/Inputs/opensuse_42.2_aarch64_tree/usr/lib64/gcc/aarch64-suse-linux/4.8/crtend.o
Modified:
cfe/trunk/lib/Driver/ToolChains.cpp
cfe/trunk/test/Driver/linux-ld.c

Modified: cfe/trunk/lib/Driver/ToolChains.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp?rev=291598=291597=291598=diff
==
--- cfe/trunk/lib/Driver/ToolChains.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains.cpp Tue Jan 10 15:13:08 2017
@@ -1531,7 +1531,7 @@ bool Generic_GCC::GCCInstallationDetecto
   static const char *const AArch64LibDirs[] = {"/lib64", "/lib"};
   static const char *const AArch64Triples[] = {
   "aarch64-none-linux-gnu", "aarch64-linux-gnu", "aarch64-linux-android",
-  "aarch64-redhat-linux"};
+  "aarch64-redhat-linux", "aarch64-suse-linux"};
   static const char *const AArch64beLibDirs[] = {"/lib"};
   static const char *const AArch64beTriples[] = {"aarch64_be-none-linux-gnu",
  "aarch64_be-linux-gnu"};

Added: cfe/trunk/test/Driver/Inputs/opensuse_42.2_aarch64_tree/usr/lib64/crt1.o
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/opensuse_42.2_aarch64_tree/usr/lib64/crt1.o?rev=291598=auto
==
(empty)

Added: cfe/trunk/test/Driver/Inputs/opensuse_42.2_aarch64_tree/usr/lib64/crti.o
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/opensuse_42.2_aarch64_tree/usr/lib64/crti.o?rev=291598=auto
==
(empty)

Added: cfe/trunk/test/Driver/Inputs/opensuse_42.2_aarch64_tree/usr/lib64/crtn.o
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/opensuse_42.2_aarch64_tree/usr/lib64/crtn.o?rev=291598=auto
==
(empty)

Added: 
cfe/trunk/test/Driver/Inputs/opensuse_42.2_aarch64_tree/usr/lib64/gcc/aarch64-suse-linux/4.8/crtbegin.o
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/opensuse_42.2_aarch64_tree/usr/lib64/gcc/aarch64-suse-linux/4.8/crtbegin.o?rev=291598=auto
==
(empty)

Added: 
cfe/trunk/test/Driver/Inputs/opensuse_42.2_aarch64_tree/usr/lib64/gcc/aarch64-suse-linux/4.8/crtend.o
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/opensuse_42.2_aarch64_tree/usr/lib64/gcc/aarch64-suse-linux/4.8/crtend.o?rev=291598=auto
==
(empty)

Modified: cfe/trunk/test/Driver/linux-ld.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/linux-ld.c?rev=291598=291597=291598=diff
==
--- cfe/trunk/test/Driver/linux-ld.c (original)
+++ cfe/trunk/test/Driver/linux-ld.c Tue Jan 10 15:13:08 2017
@@ -618,6 +618,26 @@
 // CHECK-SUSE-10-3-PPC64: "-L[[SYSROOT]]/lib/../lib64"
 // CHECK-SUSE-10-3-PPC64: "-L[[SYSROOT]]/usr/lib/../lib64"
 //
+// Check openSuse Leap 42.2 on AArch64
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=arm64-unknown-linux-gnu \
+// RUN: --gcc-toolchain="" \
+// RUN: --sysroot=%S/Inputs/opensuse_42.2_aarch64_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-OPENSUSE-42-2-AARCH64 %s
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 

[PATCH] D28404: IRGen: Add optnone attribute on function during O0

2017-01-10 Thread Paul Robinson via Phabricator via cfe-commits
probinson added a comment.

I guess I'm getting irritated because people are trying to tell me what optnone 
means. I know what it means; I spent probably a whole year pushing to get it 
adopted.

Optnone means:  When you are running optimizations, try not to optimize this 
part, if you can.

That's it.  That's *all*.  It has never meant anything else.  Telling me 
different means you misunderstand, and trying to persuade me that *I* 
misunderstand is going to be a waste of time and effort.

I fully understand that this is not the definition of optnone that you *want*.  
Please feel free to propose a redefinition.  But don't go telling me that the 
thing you *want* is what the thing already *is* and that any difference is a 
bug.


https://reviews.llvm.org/D28404



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


[PATCH] D28526: [ARM] Add diagnostics when initialization global variables with ropi/rwpi

2017-01-10 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added a comment.

If there isn't already a LangOptions flag which reflects this, it probably 
makes sense to add one.


https://reviews.llvm.org/D28526



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


[PATCH] D28526: [ARM] Add diagnostics when initialization global variables with ropi/rwpi

2017-01-10 Thread Weiming Zhao via Phabricator via cfe-commits
weimingz added a comment.

Hi Eli,
Thanks for the comments!
I though of implementation in Sema and  I actually experimented a little bit. 
Then it seemed that the CodeGenOpts is only available in the CGM.  Any ideas?


https://reviews.llvm.org/D28526



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


[PATCH] D24991: Inline hot functions in libcxx shared_ptr implementation.

2017-01-10 Thread Kevin Hu via Phabricator via cfe-commits
hxy9243 marked an inline comment as done.
hxy9243 added a comment.

Addressed previous issues in the comments. The patch still shows consistent 
perf uplift in proprietary benchmark on shared_ptr.

@EricWF @sebpop @hiraditya Any thoughts?


Repository:
  rL LLVM

https://reviews.llvm.org/D24991



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


Re: r290450 - [PM] Introduce options to enable the (still experimental) new pass

2017-01-10 Thread Chandler Carruth via cfe-commits
(explicitly adding Richard so he sees this discussion as some of this
involves a discussion between myself and him)

On Tue, Jan 10, 2017 at 4:36 PM Justin Bogner via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Chandler Carruth via cfe-commits  writes:
> > Author: chandlerc
> > Date: Fri Dec 23 14:44:01 2016
> > New Revision: 290450
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=290450=rev
> > Log:
> > [PM] Introduce options to enable the (still experimental) new pass
> > manager, and a code path to use it.
> >
> > The option is actually a top-level option but does contain
> > 'experimental' in the name. This is the compromise suggested by Richard
> > in discussions. We expect this option will be around long enough and
> > have enough users towards the end that it merits not being relegated to
> > CC1, but it still needs to be clear that this option will go away at
> > some point.
>
> I don't really understand why this is a driver option and not just a CC1
> option. Using a driver flag makes me think we expect people to be using
> this in production before we make the new PM the default, which seems
> kind of questionable to me,


I tried to explain the thinking here, but sorry if it wasn't clear. And
maybe its just the wrong tradeoff.

My thought process is this: until we get users of Clang and LLVM using the
new PM in production, I think it's going to be between hard and impossible
to make it the default. So I've been trying to make sure we have a healthy
state for asking users to enable this including in production. Speaking
just for myself as a user, I will need to enable this in production prior
to it being the default.


> and I don't see how adding a new
> "-fexperimental" is any better than just using the "-Xclang" that people
> are already familiar with the implications of.
>

The "experimental" thing was not really intended to be anything like the
CC1 interface.

It communicates two things IMO: that the functionality is less mature at
this point, and that there will (eventually) be changes.

I would still expect us to go through a very slow process to remove this
flag, the same as I would expect for any other driver-level flag.

To give an idea of the kind of timeframe I'm trying to prepare for
(although it being faster would of course be a pleasant surprise): I
suspect we will need there to be an open source release with the
functionality finished and reasonably well tested but still not the
default. And in that release we'll want to in the release notes advertise
that this is coming and that the next release will flip the default. And
then I think we'll need to do *another* release where the old pass manager
is still around, but is not the default.

Maybe things will go substantially better/faster than I've described, but
I'm trying to have a plan that is viable even if things move that slowly.


Anyways, if the decision is to go back to a CC1 flag, we can do that. I
just really want to avoid that if possible as I'd like to avoid deploying a
CC1 flag to my users (we work actively to avoid doing this where possible).

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


[PATCH] D28530: [Driver] Correct empty files in D28238

2017-01-10 Thread Kostya Kortchinsky via Phabricator via cfe-commits
cryptoad abandoned this revision.
cryptoad added a comment.

Nevermind, it seems to be working with empty files!


https://reviews.llvm.org/D28530



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


r291600 - Serialize the UsesSEH bit on FunctionDecl

2017-01-10 Thread Reid Kleckner via cfe-commits
Author: rnk
Date: Tue Jan 10 15:27:03 2017
New Revision: 291600

URL: http://llvm.org/viewvc/llvm-project?rev=291600=rev
Log:
Serialize the UsesSEH bit on FunctionDecl

Fixes PR31539

Added:
cfe/trunk/test/PCH/uses-seh.cpp
Modified:
cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
cfe/trunk/lib/Serialization/ASTWriterDecl.cpp

Modified: cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTReaderDecl.cpp?rev=291600=291599=291600=diff
==
--- cfe/trunk/lib/Serialization/ASTReaderDecl.cpp (original)
+++ cfe/trunk/lib/Serialization/ASTReaderDecl.cpp Tue Jan 10 15:27:03 2017
@@ -748,6 +748,7 @@ void ASTDeclReader::VisitFunctionDecl(Fu
   FD->IsExplicitlyDefaulted = Record.readInt();
   FD->HasImplicitReturnZero = Record.readInt();
   FD->IsConstexpr = Record.readInt();
+  FD->UsesSEHTry = Record.readInt();
   FD->HasSkippedBody = Record.readInt();
   FD->IsLateTemplateParsed = Record.readInt();
   FD->setCachedLinkage(Linkage(Record.readInt()));

Modified: cfe/trunk/lib/Serialization/ASTWriterDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTWriterDecl.cpp?rev=291600=291599=291600=diff
==
--- cfe/trunk/lib/Serialization/ASTWriterDecl.cpp (original)
+++ cfe/trunk/lib/Serialization/ASTWriterDecl.cpp Tue Jan 10 15:27:03 2017
@@ -529,6 +529,7 @@ void ASTDeclWriter::VisitFunctionDecl(Fu
   Record.push_back(D->IsExplicitlyDefaulted);
   Record.push_back(D->HasImplicitReturnZero);
   Record.push_back(D->IsConstexpr);
+  Record.push_back(D->UsesSEHTry);
   Record.push_back(D->HasSkippedBody);
   Record.push_back(D->IsLateTemplateParsed);
   Record.push_back(D->getLinkageInternal());
@@ -2032,6 +2033,7 @@ void ASTWriter::WriteDeclAbbrevs() {
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // ExplicitlyDefaulted
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // ImplicitReturnZero
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // Constexpr
+  Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // UsesSEHTry
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // SkippedBody
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // LateParsed
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 3)); // Linkage

Added: cfe/trunk/test/PCH/uses-seh.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/PCH/uses-seh.cpp?rev=291600=auto
==
--- cfe/trunk/test/PCH/uses-seh.cpp (added)
+++ cfe/trunk/test/PCH/uses-seh.cpp Tue Jan 10 15:27:03 2017
@@ -0,0 +1,29 @@
+// Make SEH works in PCH
+//
+// Test this without pch.
+// RUN: %clang_cc1 -fms-extensions -triple x86_64-windows-msvc -std=c++11 
-include %s -emit-llvm -o - %s | FileCheck %s
+
+// Test with pch.
+// RUN: %clang_cc1 -fms-extensions -triple x86_64-windows-msvc -std=c++11 
-emit-pch -o %t %s
+// RUN: %clang_cc1 -fms-extensions -triple x86_64-windows-msvc -std=c++11 
-include-pch %t -emit-llvm -o - %s | FileCheck %s
+
+#ifndef HEADER
+#define HEADER
+
+int shouldCatch();
+inline int f() {
+  __try {
+  } __except (shouldCatch()) {
+  }
+  return 0;
+}
+int x = f();
+
+// CHECK: define linkonce_odr i32 @"\01?f@@YAHXZ"()
+// CHECK: define internal i32 @"\01?filt$0@0@f@@"({{.*}})
+
+#else
+
+// empty
+
+#endif


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


[PATCH] D28530: [Driver] Correct empty files in D28238

2017-01-10 Thread Kostya Kortchinsky via Phabricator via cfe-commits
cryptoad created this revision.
cryptoad added a reviewer: rengolin.
cryptoad added a subscriber: cfe-commits.

The binary files added as part of https://reviews.llvm.org/rL291598 seem to be
empty. Those are the actual files that should have been uploaded by arc.


https://reviews.llvm.org/D28530

Files:
  test/Driver/Inputs/opensuse_42.2_aarch64_tree/usr/lib64/crt1.o
  test/Driver/Inputs/opensuse_42.2_aarch64_tree/usr/lib64/crti.o
  test/Driver/Inputs/opensuse_42.2_aarch64_tree/usr/lib64/crtn.o
  
test/Driver/Inputs/opensuse_42.2_aarch64_tree/usr/lib64/gcc/aarch64-suse-linux/4.8/crtbegin.o
  
test/Driver/Inputs/opensuse_42.2_aarch64_tree/usr/lib64/gcc/aarch64-suse-linux/4.8/crtend.o




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


[PATCH] D28238: [Driver] Add openSuse AArch64 Triple

2017-01-10 Thread Kostya Kortchinsky via Phabricator via cfe-commits
cryptoad marked 4 inline comments as done.
cryptoad added a comment.

Thank you for the review Renato!


https://reviews.llvm.org/D28238



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


r291597 - Don't try to check implicit conversion sequences for an object argument if

2017-01-10 Thread Richard Smith via cfe-commits
Author: rsmith
Date: Tue Jan 10 14:52:50 2017
New Revision: 291597

URL: http://llvm.org/viewvc/llvm-project?rev=291597=rev
Log:
Don't try to check implicit conversion sequences for an object argument if
there is no object argument, when early checking of implicit conversion
sequences for a function template fails.

Modified:
cfe/trunk/lib/Sema/SemaOverload.cpp
cfe/trunk/test/SemaTemplate/deduction.cpp

Modified: cfe/trunk/lib/Sema/SemaOverload.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOverload.cpp?rev=291597=291596=291597=diff
==
--- cfe/trunk/lib/Sema/SemaOverload.cpp (original)
+++ cfe/trunk/lib/Sema/SemaOverload.cpp Tue Jan 10 14:52:50 2017
@@ -6596,7 +6596,9 @@ Sema::AddMethodTemplateCandidate(Functio
 Candidate.Function = MethodTmpl->getTemplatedDecl();
 Candidate.Viable = false;
 Candidate.IsSurrogate = false;
-Candidate.IgnoreObjectArgument = false;
+Candidate.IgnoreObjectArgument =
+cast(Candidate.Function)->isStatic() ||
+ObjectType.isNull();
 Candidate.ExplicitCallArguments = Args.size();
 if (Result == TDK_NonDependentConversionFailure)
   Candidate.FailureKind = ovl_fail_bad_conversion;
@@ -6658,7 +6660,11 @@ Sema::AddTemplateOverloadCandidate(Funct
 Candidate.Function = FunctionTemplate->getTemplatedDecl();
 Candidate.Viable = false;
 Candidate.IsSurrogate = false;
-Candidate.IgnoreObjectArgument = false;
+// Ignore the object argument if there is one, since we don't have an 
object
+// type.
+Candidate.IgnoreObjectArgument =
+isa(Candidate.Function) &&
+!isa(Candidate.Function);
 Candidate.ExplicitCallArguments = Args.size();
 if (Result == TDK_NonDependentConversionFailure)
   Candidate.FailureKind = ovl_fail_bad_conversion;

Modified: cfe/trunk/test/SemaTemplate/deduction.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaTemplate/deduction.cpp?rev=291597=291596=291597=diff
==
--- cfe/trunk/test/SemaTemplate/deduction.cpp (original)
+++ cfe/trunk/test/SemaTemplate/deduction.cpp Tue Jan 10 14:52:50 2017
@@ -385,10 +385,21 @@ namespace deduction_after_explicit_pack
   void q() { p(X(0), 0); } // expected-error {{no match}}
 
   struct A {
-template  void f(T, void *, int = 0); // expected-note {{no 
known conversion from 'double' to 'void *' for 2nd argument}}
-void f(); // expected-note {{requires 0}}
+template  void f(T, void *, int = 0); // expected-note 2{{no 
known conversion from 'double' to 'void *' for 2nd argument}}
+void f(); // expected-note 2{{requires 0}}
+
+template  static void g(T, void *, int = 0); // expected-note 
2{{no known conversion from 'double' to 'void *' for 2nd argument}}
+void g(); // expected-note 2{{requires 0}}
+
+void h() {
+  f(1.0, 2.0); // expected-error {{no match}}
+  g(1.0, 2.0); // expected-error {{no match}}
+}
   };
-  void f(A a) { a.f(1.0, 2.0); } // expected-error {{no match}}
+  void f(A a) {
+a.f(1.0, 2.0); // expected-error {{no match}}
+a.g(1.0, 2.0); // expected-error {{no match}}
+  }
 }
 
 namespace overload_vs_pack {


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


Re: [clang-tools-extra] r291446 - [include-fixer] Load symbol index asynchronously.

2017-01-10 Thread Galina Kistanova via cfe-commits
Hello Benjamin,

It looks like this commit added warnings to the builder:

http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/3596

C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\INCLUDE\ppltasks.h(1531): warning C4530: C++ exception handler
used, but unwind semantics are not enabled. Specify /EHsc
C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\INCLUDE\ppltasks.h(1531): warning C4530: C++ exception handler
used, but unwind semantics are not enabled. Specify /EHsc
C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\INCLUDE\ppltasks.h(1531): warning C4530: C++ exception handler
used, but unwind semantics are not enabled. Specify /EHsc
C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\INCLUDE\ppltasks.h(1531): warning C4530: C++ exception handler
used, but unwind semantics are not enabled. Specify /EHsc
C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\INCLUDE\ppltasks.h(1531): warning C4530: C++ exception handler
used, but unwind semantics are not enabled. Specify /EHsc

Please have a look at this?

Thanks

Galina

On Mon, Jan 9, 2017 at 7:18 AM, Benjamin Kramer via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: d0k
> Date: Mon Jan  9 09:18:28 2017
> New Revision: 291446
>
> URL: http://llvm.org/viewvc/llvm-project?rev=291446=rev
> Log:
> [include-fixer] Load symbol index asynchronously.
>
> We don't actually need the index until parse time, so fetch it in the
> background and start parsing. By the time it is actually needed it's
> likely that the loading phase has completed in the background.
>
> Modified:
> clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp
> clang-tools-extra/trunk/include-fixer/SymbolIndexManager.h
> clang-tools-extra/trunk/include-fixer/plugin/IncludeFixerPlugin.cpp
> clang-tools-extra/trunk/include-fixer/tool/ClangIncludeFixer.cpp
> clang-tools-extra/trunk/unittests/include-fixer/IncludeFixerTest.cpp
>
> Modified: clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp
> URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/
> trunk/include-fixer/SymbolIndexManager.cpp?rev=291446=291445=291446&
> view=diff
> 
> ==
> --- clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp
> (original)
> +++ clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp Mon Jan
> 9 09:18:28 2017
> @@ -64,7 +64,7 @@ SymbolIndexManager::search(llvm::StringR
>do {
>  std::vector Symbols;
>  for (const auto  : SymbolIndices) {
> -  auto Res = DB->search(Names.back().str());
> +  auto Res = DB.get()->search(Names.back());
>Symbols.insert(Symbols.end(), Res.begin(), Res.end());
>  }
>
>
> Modified: clang-tools-extra/trunk/include-fixer/SymbolIndexManager.h
> URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/
> trunk/include-fixer/SymbolIndexManager.h?rev=291446=291445=291446&
> view=diff
> 
> ==
> --- clang-tools-extra/trunk/include-fixer/SymbolIndexManager.h (original)
> +++ clang-tools-extra/trunk/include-fixer/SymbolIndexManager.h Mon Jan  9
> 09:18:28 2017
> @@ -13,6 +13,7 @@
>  #include "SymbolIndex.h"
>  #include "find-all-symbols/SymbolInfo.h"
>  #include "llvm/ADT/StringRef.h"
> +#include 
>
>  namespace clang {
>  namespace include_fixer {
> @@ -21,8 +22,8 @@ namespace include_fixer {
>  /// to an indentifier in the source code from multiple symbol databases.
>  class SymbolIndexManager {
>  public:
> -  void addSymbolIndex(std::unique_ptr DB) {
> -SymbolIndices.push_back(std::move(DB));
> +  void addSymbolIndex(std::function F) {
> +SymbolIndices.push_back(std::async(std::launch::async, F));
>}
>
>/// Search for header files to be included for an identifier.
> @@ -39,7 +40,7 @@ public:
>search(llvm::StringRef Identifier, bool IsNestedSearch = true) const;
>
>  private:
> -  std::vector SymbolIndices;
> +  std::vector>
> SymbolIndices;
>  };
>
>  } // namespace include_fixer
>
> Modified: clang-tools-extra/trunk/include-fixer/plugin/
> IncludeFixerPlugin.cpp
> URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/
> trunk/include-fixer/plugin/IncludeFixerPlugin.cpp?rev=
> 291446=291445=291446=diff
> 
> ==
> --- clang-tools-extra/trunk/include-fixer/plugin/IncludeFixerPlugin.cpp
> (original)
> +++ clang-tools-extra/trunk/include-fixer/plugin/IncludeFixerPlugin.cpp
> Mon Jan  9 09:18:28 2017
> @@ -61,23 +61,26 @@ public:
>  Input = Arg.substr(strlen("-input="));
>  }
>
> -llvm::ErrorOr
> SymbolIdx(
> -nullptr);
> -if (DB == "yaml") {
> -  if (!Input.empty()) {
> -SymbolIdx = include_fixer::YamlSymbolIndex::
> createFromFile(Input);
> -  } else {
> -

[PATCH] D28526: [ARM] Add diagnostics when initialization global variables with ropi/rwpi

2017-01-10 Thread Eli Friedman via Phabricator via cfe-commits
efriedma requested changes to this revision.
efriedma added a reviewer: efriedma.
efriedma added a comment.
This revision now requires changes to proceed.

We really should be checking this much earlier.

IsGlobalLValue() in ExprConstant.cpp is the canonical place to answer the 
question "is the address of the given expression constant".  Getting this right 
in semantic analysis means you don't have to chase down all the various places 
which generate global initializers.  In addition to global variables, static 
local variables and compound literals can have static storage duration in C.  
And sometimes you can even run into trouble with globals which don't exist in 
the source code.  One interesting example:

  int a;
  int g(const int**);
  int f(void) {
const int *x[] = {,,,};
return g(x);
  }

This is valid code whether or not we're in rwpi mode, but clang currently 
generates IR which won't link in rwpi mode.  If semantic analysis concludes 
that `` isn't a constant, the correct code generation falls out naturally; 
otherwise, you have yet another place to add an explicit check in IR 
generation.  And I won't even try to go into all the additional corner cases 
you can run into with C++ code.

As a bonus, you can generate nicer error messages in Sema.


https://reviews.llvm.org/D28526



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


[PATCH] D28260: Add an argumentsAre matcher

2017-01-10 Thread Matt Kulukundis via Phabricator via cfe-commits
fowles added a subscriber: jdennett.
fowles added a comment.

@jdennett wanted this matcher for something he is working on and I had some 
free cycles to write it up.  Unfortunately, I am about to leave on an extended 
vacation, so I will not be able to follow up with this patch for 2 months at 
the earliest.

I suspect the best solution is for someone to take over this patch and work 
with James to clarify any corner cases.


https://reviews.llvm.org/D28260



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


[PATCH] D28404: IRGen: Add optnone attribute on function during O0

2017-01-10 Thread Chandler Carruth via Phabricator via cfe-commits
chandlerc added a comment.

In https://reviews.llvm.org/D28404#641696, @mehdi_amini wrote:

> In https://reviews.llvm.org/D28404#641632, @probinson wrote:
>
> > In https://reviews.llvm.org/D28404#641606, @mehdi_amini wrote:
> >
> > > If we want to support `-O0 -flto` and `optnone` it the way to convey this 
> > > to the optimizer, I don't see the alternative.
> >
> >
> > optsize != -Os (according to Chandler)
> >  minsize != -Oz (according to Chandler)
> >  optnone != -O0 (according to both me and Chandler)
>
>
> Of course, but that's just an implementation limitation, mostly for 
> historical reason I believe, not by design.


There is certainly a lot of history here influencing this, but I think there is 
also some a  fundamental difference. The flag is a request from the user to 
behave in a particular way. The LLVM attribute is a tool we use in some cases 
to try to satisfy that request.

When we're not doing LTO, it is easier to satisfy the requests of '-O' flags. 
The fact that we happen to not use attributes to do it today is just an 
implementation detail.

When we are doing LTO, satisfying different requests is hard. We should do our 
best, but I think it is reasonable to explain to the user that "with LTO, we 
can't fail to optimize with the Wombat optimization because of  when 
one file requests -O0 and another requests -O2". Same thing for the other 
levels.

This seems precisely analogous to the fact that even when the user requests 
-O0, we will do some inlining. Why? Because we *have to* for semantic reasons.

So I think what Mehdi is driving at is that if '-O0 -flto' has a mismatch from 
'-O0' in terms of what users expect, we should probably try to fix that. I'd 
suggest that there may be fundamental things we can't fix and that is OK. I 
don't think this is unprincipled either, we're doing the best we can to honor 
the user's request.

The other thing that might help is to point out that there *are* principles 
behind why these flags. Unlike the differences between -O[123], all of -O0, 
-Os, and -Oz have non-threshold semantic implications. So with this change, I 
think we will have *all* the -O flags covered, because I view '-O[123]' as a 
single semantic space with a threshold modifier that we *don't* need to 
communicate to LTO. We model that state as the absence of any attribute. And 
-O0, -Os, and-Oz have dedicated attributes.

If we ever want to really push on -Og, that might indeed require an attribute 
to distinguish it.

>> optnone is not "the way to convey (-O0) to the optimizer."

So, I view '-O0' as a request from the programmer to turn off the optimizer to 
the extent possible and give them as naive, minimally transformed 
representation of th ecode as possible.

And based on that, I view optnone as a tool to implement precisely these 
semantics at a fine granularity and with survivability across bitcode roundtrip.

It just isn't the *only* tool, and sometimes we can use an easier (and cheaper 
to Mehdi's compile time point) tool.

I think the text for spec'ing optnone in the LLVM langref needs to be updated 
to reflect this though. Currently it says:

> This function attribute indicates that most optimization passes will skip 
> this function, with the exception of interprocedural optimization passes.

This is demonstrably false:

  % ag OptimizeNone lib/Transforms/IPO
  lib/Transforms/IPO/ForceFunctionAttrs.cpp
  47:  .Case("optnone", Attribute::OptimizeNone)
  
  lib/Transforms/IPO/Inliner.cpp
  813:if (F.hasFnAttribute(Attribute::OptimizeNone))
  
  lib/Transforms/IPO/InferFunctionAttrs.cpp
  30:if (F.isDeclaration() && !F.hasFnAttribute((Attribute::OptimizeNone)))
  
  lib/Transforms/IPO/FunctionAttrs.cpp
  1056:if (F.hasFnAttribute(Attribute::OptimizeNone)) {
  1137:if (!F || F->hasFnAttribute(Attribute::OptimizeNone)) {

I'll send a patch.


https://reviews.llvm.org/D28404



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


[PATCH] D28529: [test] Port clang tests to canonicalized booleans

2017-01-10 Thread Michał Górny via Phabricator via cfe-commits
mgorny created this revision.
mgorny added a reviewer: beanz.
mgorny added a subscriber: cfe-commits.
Herald added a subscriber: klimek.

Use the new llvm_canonicalize_cmake_booleans() function to canonicalize
booleans for lit tests. Replace the duplicate ENABLE_CLANG* variables
used to hold canonicalized values with in-place canonicalization. Use
implicit logic in Python code to avoid overrelying on exact 0/1 values.


https://reviews.llvm.org/D28529

Files:
  CMakeLists.txt
  test/ARCMT/lit.local.cfg
  test/Analysis/lit.local.cfg
  test/CMakeLists.txt
  test/Rewriter/lit.local.cfg
  test/Tooling/lit.local.cfg
  test/lit.cfg
  test/lit.site.cfg.in

Index: test/lit.site.cfg.in
===
--- test/lit.site.cfg.in
+++ test/lit.site.cfg.in
@@ -14,13 +14,13 @@
 config.host_triple = "@LLVM_HOST_TRIPLE@"
 config.target_triple = "@TARGET_TRIPLE@"
 config.llvm_use_sanitizer = "@LLVM_USE_SANITIZER@"
-config.have_zlib = "@HAVE_LIBZ@"
-config.clang_arcmt = @ENABLE_CLANG_ARCMT@
+config.have_zlib = @HAVE_LIBZ@
+config.clang_arcmt = @CLANG_ENABLE_ARCMT@
 config.clang_default_cxx_stdlib = "@CLANG_DEFAULT_CXX_STDLIB@"
-config.clang_staticanalyzer = @ENABLE_CLANG_STATIC_ANALYZER@
-config.clang_examples = @ENABLE_CLANG_EXAMPLES@
+config.clang_staticanalyzer = @CLANG_ENABLE_STATIC_ANALYZER@
+config.clang_examples = @CLANG_BUILD_EXAMPLES@
 config.enable_shared = @ENABLE_SHARED@
-config.enable_backtrace = "@ENABLE_BACKTRACES@"
+config.enable_backtrace = @ENABLE_BACKTRACES@
 config.host_arch = "@HOST_ARCH@"
 
 # Support substitution of the tools and libs dirs with user parameters. This is
Index: test/lit.cfg
===
--- test/lit.cfg
+++ test/lit.cfg
@@ -202,7 +202,7 @@
 # Plugins (loadable modules)
 # TODO: This should be supplied by Makefile or autoconf.
 if sys.platform in ['win32', 'cygwin']:
-has_plugins = (config.enable_shared == 1)
+has_plugins = config.enable_shared
 else:
 has_plugins = True
 
@@ -353,7 +353,7 @@
 config.available_features.add('default-cxx-stdlib-set')
 
 # Enabled/disabled features
-if config.clang_staticanalyzer != 0:
+if config.clang_staticanalyzer:
 config.available_features.add("staticanalyzer")
 
 # As of 2011.08, crash-recovery tests still do not pass on FreeBSD.
@@ -474,10 +474,10 @@
 else:
 config.available_features.add("not_ubsan")
 
-if config.enable_backtrace == "1":
+if config.enable_backtrace:
 config.available_features.add("backtrace")
 
-if config.have_zlib == "1":
+if config.have_zlib:
 config.available_features.add("zlib")
 else:
 config.available_features.add("nozlib")
Index: test/Tooling/lit.local.cfg
===
--- test/Tooling/lit.local.cfg
+++ test/Tooling/lit.local.cfg
@@ -1,2 +1,2 @@
-if config.root.clang_staticanalyzer == 0:
+if not config.root.clang_staticanalyzer:
 config.unsupported = True
Index: test/Rewriter/lit.local.cfg
===
--- test/Rewriter/lit.local.cfg
+++ test/Rewriter/lit.local.cfg
@@ -1,3 +1,3 @@
 # The Objective-C rewriters are currently grouped with ARCMT.
-if config.root.clang_arcmt == 0:
+if not config.root.clang_arcmt:
 config.unsupported = True
Index: test/CMakeLists.txt
===
--- test/CMakeLists.txt
+++ test/CMakeLists.txt
@@ -18,6 +18,12 @@
   endif()
 endif()
 
+llvm_canonicalize_cmake_booleans(
+  CLANG_BUILD_EXAMPLES
+  CLANG_ENABLE_ARCMT
+  CLANG_ENABLE_STATIC_ANALYZER
+  ENABLE_BACKTRACES)
+
 configure_lit_site_cfg(
   ${CMAKE_CURRENT_SOURCE_DIR}/lit.site.cfg.in
   ${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg
@@ -55,15 +61,15 @@
   )
 endif ()
 
-if (ENABLE_CLANG_EXAMPLES)
+if (CLANG_BUILD_EXAMPLES)
   list(APPEND CLANG_TEST_DEPS
 AnnotateFunctions
 clang-interpreter
 PrintFunctionNames
 )
 endif ()
 
-if (ENABLE_CLANG_STATIC_ANALYZER AND ENABLE_CLANG_EXAMPLES)
+if (CLANG_ENABLE_STATIC_ANALYZER AND CLANG_BUILD_EXAMPLES)
   list(APPEND CLANG_TEST_DEPS
 SampleAnalyzerPlugin
 )
Index: test/Analysis/lit.local.cfg
===
--- test/Analysis/lit.local.cfg
+++ test/Analysis/lit.local.cfg
@@ -1,2 +1,2 @@
-if config.root.clang_staticanalyzer == 0:
+if not config.root.clang_staticanalyzer:
 config.unsupported = True
Index: test/ARCMT/lit.local.cfg
===
--- test/ARCMT/lit.local.cfg
+++ test/ARCMT/lit.local.cfg
@@ -1,2 +1,2 @@
-if config.root.clang_arcmt == 0:
+if not config.root.clang_arcmt:
 config.unsupported = True
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -364,18 +364,7 @@
   "Build the Clang tools. If OFF, just generate build targets." ON)
 
 option(CLANG_ENABLE_ARCMT "Build ARCMT." 

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

2017-01-10 Thread Dimitry Andric via Phabricator via cfe-commits
dim updated this revision to Diff 83851.
dim added a comment.

Let's try this simpler version instead.


https://reviews.llvm.org/D28520

Files:
  include/__threading_support


Index: include/__threading_support
===
--- include/__threading_support
+++ include/__threading_support
@@ -40,6 +40,12 @@
 #define _LIBCPP_THREAD_ABI_VISIBILITY inline _LIBCPP_INLINE_VISIBILITY
 #endif
 
+#if defined(__clang__) && __has_attribute(no_thread_safety_analysis)
+#define _LIBCPP_NO_THREAD_SAFETY_ANALYSIS 
__attribute__((no_thread_safety_analysis))
+#else
+#define _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
+#endif
+
 _LIBCPP_BEGIN_NAMESPACE_STD
 
 #if defined(_LIBCPP_HAS_THREAD_API_PTHREAD)
@@ -98,25 +104,25 @@
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_recursive_mutex_init(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_recursive_mutex_lock(__libcpp_recursive_mutex_t *__m);
 
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_recursive_mutex_trylock(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_recursive_mutex_unlock(__libcpp_recursive_mutex_t *__m);
 
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_recursive_mutex_destroy(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_mutex_lock(__libcpp_mutex_t *__m);
 
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_mutex_trylock(__libcpp_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_mutex_unlock(__libcpp_mutex_t *__m);
 
 _LIBCPP_THREAD_ABI_VISIBILITY
@@ -129,10 +135,10 @@
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_condvar_broadcast(__libcpp_condvar_t* __cv);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_condvar_wait(__libcpp_condvar_t* __cv, __libcpp_mutex_t* __m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_condvar_timedwait(__libcpp_condvar_t *__cv, __libcpp_mutex_t *__m,
timespec *__ts);
 


Index: include/__threading_support
===
--- include/__threading_support
+++ include/__threading_support
@@ -40,6 +40,12 @@
 #define _LIBCPP_THREAD_ABI_VISIBILITY inline _LIBCPP_INLINE_VISIBILITY
 #endif
 
+#if defined(__clang__) && __has_attribute(no_thread_safety_analysis)
+#define _LIBCPP_NO_THREAD_SAFETY_ANALYSIS __attribute__((no_thread_safety_analysis))
+#else
+#define _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
+#endif
+
 _LIBCPP_BEGIN_NAMESPACE_STD
 
 #if defined(_LIBCPP_HAS_THREAD_API_PTHREAD)
@@ -98,25 +104,25 @@
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_recursive_mutex_init(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_recursive_mutex_lock(__libcpp_recursive_mutex_t *__m);
 
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_recursive_mutex_trylock(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_recursive_mutex_unlock(__libcpp_recursive_mutex_t *__m);
 
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_recursive_mutex_destroy(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_mutex_lock(__libcpp_mutex_t *__m);
 
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_mutex_trylock(__libcpp_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_mutex_unlock(__libcpp_mutex_t *__m);
 
 _LIBCPP_THREAD_ABI_VISIBILITY
@@ -129,10 +135,10 @@
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_condvar_broadcast(__libcpp_condvar_t* __cv);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_condvar_wait(__libcpp_condvar_t* __cv, __libcpp_mutex_t* __m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
 int __libcpp_condvar_timedwait(__libcpp_condvar_t *__cv, __libcpp_mutex_t *__m,
timespec *__ts);
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r291596 - Fix conversion index / argument index mismatch when diagnosing overload resolution failure.

2017-01-10 Thread Richard Smith via cfe-commits
Author: rsmith
Date: Tue Jan 10 14:19:21 2017
New Revision: 291596

URL: http://llvm.org/viewvc/llvm-project?rev=291596=rev
Log:
Fix conversion index / argument index mismatch when diagnosing overload 
resolution failure.

Modified:
cfe/trunk/lib/Sema/SemaOverload.cpp
cfe/trunk/test/SemaTemplate/deduction.cpp

Modified: cfe/trunk/lib/Sema/SemaOverload.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOverload.cpp?rev=291596=291595=291596=diff
==
--- cfe/trunk/lib/Sema/SemaOverload.cpp (original)
+++ cfe/trunk/lib/Sema/SemaOverload.cpp Tue Jan 10 14:19:21 2017
@@ -10490,56 +10490,42 @@ static void CompleteNonViableCandidate(S
   // operation somehow.
   bool SuppressUserConversions = false;
 
-  const FunctionProtoType *Proto;
-  unsigned ArgIdx = 0;
+  unsigned ConvIdx = 0;
+  ArrayRef ParamTypes;
 
   if (Cand->IsSurrogate) {
 QualType ConvType
   = Cand->Surrogate->getConversionType().getNonReferenceType();
 if (const PointerType *ConvPtrType = ConvType->getAs())
   ConvType = ConvPtrType->getPointeeType();
-Proto = ConvType->getAs();
-ArgIdx = 1;
+ParamTypes = ConvType->getAs()->getParamTypes();
+// Conversion 0 is 'this', which doesn't have a corresponding argument.
+ConvIdx = 1;
   } else if (Cand->Function) {
-Proto = Cand->Function->getType()->getAs();
+ParamTypes =
+Cand->Function->getType()->getAs()->getParamTypes();
 if (isa(Cand->Function) &&
-!isa(Cand->Function))
-  ArgIdx = 1;
+!isa(Cand->Function)) {
+  // Conversion 0 is 'this', which doesn't have a corresponding argument.
+  ConvIdx = 1;
+}
   } else {
-// Builtin binary operator with a bad first conversion.
+// Builtin operator.
 assert(ConvCount <= 3);
-for (unsigned ConvIdx = (Cand->IgnoreObjectArgument ? 1 : 0);
- ConvIdx != ConvCount; ++ConvIdx) {
-  if (Cand->Conversions[ConvIdx].isInitialized())
-continue;
-  if (Cand->BuiltinTypes.ParamTypes[ConvIdx]->isDependentType())
-Cand->Conversions[ConvIdx].setAsIdentityConversion(
-Args[ConvIdx]->getType());
-  else
-Cand->Conversions[ConvIdx] = TryCopyInitialization(
-S, Args[ConvIdx], Cand->BuiltinTypes.ParamTypes[ConvIdx],
-SuppressUserConversions,
-/*InOverloadResolution*/ true,
-/*AllowObjCWritebackConversion=*/
-S.getLangOpts().ObjCAutoRefCount);
-  // FIXME: If the conversion is bad, try to fix it.
-}
-return;
+ParamTypes = Cand->BuiltinTypes.ParamTypes;
   }
 
   // Fill in the rest of the conversions.
-  unsigned NumParams = Proto->getNumParams();
-  for (unsigned ConvIdx = (Cand->IgnoreObjectArgument ? 1 : 0);
-   ConvIdx != ConvCount; ++ConvIdx, ++ArgIdx) {
+  for (unsigned ArgIdx = 0; ConvIdx != ConvCount; ++ConvIdx, ++ArgIdx) {
 if (Cand->Conversions[ConvIdx].isInitialized()) {
-  // Found the bad conversion.
-} else if (ArgIdx < NumParams) {
-  if (Proto->getParamType(ArgIdx)->isDependentType())
+  // We've already checked this conversion.
+} else if (ArgIdx < ParamTypes.size()) {
+  if (ParamTypes[ArgIdx]->isDependentType())
 Cand->Conversions[ConvIdx].setAsIdentityConversion(
 Args[ArgIdx]->getType());
   else {
 Cand->Conversions[ConvIdx] =
-TryCopyInitialization(S, Args[ArgIdx], Proto->getParamType(ArgIdx),
+TryCopyInitialization(S, Args[ArgIdx], ParamTypes[ArgIdx],
   SuppressUserConversions,
   /*InOverloadResolution=*/true,
   /*AllowObjCWritebackConversion=*/

Modified: cfe/trunk/test/SemaTemplate/deduction.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaTemplate/deduction.cpp?rev=291596=291595=291596=diff
==
--- cfe/trunk/test/SemaTemplate/deduction.cpp (original)
+++ cfe/trunk/test/SemaTemplate/deduction.cpp Tue Jan 10 14:19:21 2017
@@ -383,6 +383,12 @@ namespace deduction_after_explicit_pack
   template struct X { X(int); operator int(); };
   template void p(T..., X, ...); // expected-note 
{{deduced conflicting}}
   void q() { p(X(0), 0); } // expected-error {{no match}}
+
+  struct A {
+template  void f(T, void *, int = 0); // expected-note {{no 
known conversion from 'double' to 'void *' for 2nd argument}}
+void f(); // expected-note {{requires 0}}
+  };
+  void f(A a) { a.f(1.0, 2.0); } // expected-error {{no match}}
 }
 
 namespace overload_vs_pack {


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


[PATCH] D28001: [X86] Teach Clang about -mfentry flag

2017-01-10 Thread Nirav Dave via Phabricator via cfe-commits
niravd added inline comments.



Comment at: include/clang/Driver/Options.td:1731
 def mno_pie_copy_relocations : Flag<["-"], "mno-pie-copy-relocations">, 
Group;
+def mfentry : Flag<["-"], "mfentry">, HelpText<"insert calls to fentry at 
function entry">, Flags<[CC1Option]>, Group;
 def mx87 : Flag<["-"], "mx87">, Group;

mcrosier wrote:
> Should this not be in the m_x86_Features_Group since this is an x86 specific 
> flag?
Done. -mfentry should eventually defined for at least aarch64 but until that 
point we should have the flag match clang's actual capabilities.



Comment at: test/CodeGen/fentry.c:1
+// RUN: %clang_cc1 -pg -mfentry -triple i386-unknown-unknown -emit-llvm -o - 
%s | FileCheck -check-prefix=HAS %s
+// RUN: %clang_cc1 -pg -mfentry -triple x86_64-unknown-linux-gnu -emit-llvm -o 
- %s | FileCheck -check-prefix=HAS %s

mcrosier wrote:
> I want to say this test should be in test/Frontend directory since you're 
> testing a new CC1 option.
That seems reasonable, but I wanted to match with the mcount test. 


https://reviews.llvm.org/D28001



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


[PATCH] D28001: [X86] Teach Clang about -mfentry flag

2017-01-10 Thread Nirav Dave via Phabricator via cfe-commits
niravd updated this revision to Diff 83850.
niravd marked 2 inline comments as done.
niravd added a comment.

Address comments


https://reviews.llvm.org/D28001

Files:
  include/clang/Driver/Options.td
  include/clang/Frontend/CodeGenOptions.def
  lib/CodeGen/CodeGenFunction.cpp
  lib/Driver/Tools.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/CodeGen/fentry.c


Index: test/CodeGen/fentry.c
===
--- /dev/null
+++ test/CodeGen/fentry.c
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -pg -mfentry -triple i386-unknown-unknown -emit-llvm -o - 
%s | FileCheck  %s
+// RUN: %clang_cc1 -pg -mfentry -triple x86_64-unknown-linux-gnu -emit-llvm -o 
- %s | FileCheck %s
+// RUN: %clang_cc1 -mfentry -triple i386-unknown-unknown -emit-llvm -o - %s | 
FileCheck -check-prefix=NOPG %s
+// RUN: %clang_cc1 -mfentry -triple x86_64-unknown-linux-gnu -emit-llvm -o - 
%s | FileCheck -check-prefix=NOPG %s
+
+int foo(void) {
+  return 0;
+}
+
+//CHECK: attributes #{{[0-9]+}} = { {{.*}}"fentry-call"="true"{{.*}} }
+//NOPG-NOT: attributes #{{[0-9]+}} = { {{.*}}"fentry-call"{{.*}} }
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -714,6 +714,7 @@
   Opts.XRayInstructionThreshold =
   getLastArgIntValue(Args, OPT_fxray_instruction_threshold_, 200, Diags);
   Opts.InstrumentForProfiling = Args.hasArg(OPT_pg);
+  Opts.CallFEntry = Args.hasArg(OPT_mfentry);
   Opts.EmitOpenCLArgMetadata = Args.hasArg(OPT_cl_kernel_arg_info);
   Opts.CompressDebugSections = Args.hasArg(OPT_compress_debug_sections);
   Opts.RelaxELFRelocations = Args.hasArg(OPT_mrelax_relocations);
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -5423,6 +5423,9 @@
   if (getToolChain().SupportsProfiling())
 Args.AddLastArg(CmdArgs, options::OPT_pg);
 
+  if (getToolChain().SupportsProfiling())
+Args.AddLastArg(CmdArgs, options::OPT_mfentry);
+
   // -flax-vector-conversions is default.
   if (!Args.hasFlag(options::OPT_flax_vector_conversions,
 options::OPT_fno_lax_vector_conversions))
Index: lib/CodeGen/CodeGenFunction.cpp
===
--- lib/CodeGen/CodeGenFunction.cpp
+++ lib/CodeGen/CodeGenFunction.cpp
@@ -852,8 +852,12 @@
   // inlining, we just add an attribute to insert a mcount call in backend.
   // The attribute "counting-function" is set to mcount function name which is
   // architecture dependent.
-  if (CGM.getCodeGenOpts().InstrumentForProfiling)
-Fn->addFnAttr("counting-function", getTarget().getMCountName());
+  if (CGM.getCodeGenOpts().InstrumentForProfiling) {
+if (CGM.getCodeGenOpts().CallFEntry)
+  Fn->addFnAttr("fentry-call", "true");
+else
+  Fn->addFnAttr("counting-function", getTarget().getMCountName());
+  }
 
   if (RetTy->isVoidType()) {
 // Void type; nothing to return.
Index: include/clang/Frontend/CodeGenOptions.def
===
--- include/clang/Frontend/CodeGenOptions.def
+++ include/clang/Frontend/CodeGenOptions.def
@@ -83,6 +83,7 @@
 VALUE_CODEGENOPT(XRayInstructionThreshold , 32, 200)
 
 CODEGENOPT(InstrumentForProfiling , 1, 0) ///< Set when -pg is enabled.
+CODEGENOPT(CallFEntry , 1, 0) ///< Set when -mfentry is enabled.
 CODEGENOPT(LessPreciseFPMAD  , 1, 0) ///< Enable less precise MAD instructions 
to
  ///< be generated.
 CODEGENOPT(PrepareForLTO , 1, 0) ///< Set when -flto is enabled on the
Index: include/clang/Driver/Options.td
===
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -1746,6 +1746,8 @@
   Flags<[CC1Option]>,
   HelpText<"Use copy relocations support for PIE builds">;
 def mno_pie_copy_relocations : Flag<["-"], "mno-pie-copy-relocations">, 
Group;
+def mfentry : Flag<["-"], "mfentry">, HelpText<"insert calls to fentry at 
function entry">,
+  Flags<[CC1Option]>, Group;
 def mx87 : Flag<["-"], "mx87">, Group;
 def m80387 : Flag<["-"], "m80387">, Alias;
 def msse2 : Flag<["-"], "msse2">, Group;


Index: test/CodeGen/fentry.c
===
--- /dev/null
+++ test/CodeGen/fentry.c
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -pg -mfentry -triple i386-unknown-unknown -emit-llvm -o - %s | FileCheck  %s
+// RUN: %clang_cc1 -pg -mfentry -triple x86_64-unknown-linux-gnu -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -mfentry -triple i386-unknown-unknown -emit-llvm -o - %s | FileCheck -check-prefix=NOPG %s
+// RUN: %clang_cc1 -mfentry -triple x86_64-unknown-linux-gnu -emit-llvm -o - %s | FileCheck -check-prefix=NOPG %s
+
+int foo(void) {
+  return 0;
+}
+
+//CHECK: attributes #{{[0-9]+}} = 

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

2017-01-10 Thread Dimitry Andric via Phabricator via cfe-commits
dim added a comment.

Hmm, actually this does not work.  The definition of 
`_LIBCPP_THREAD_SAFETY_ANNOTATION` I moved from `__mutex_base` to `__config` is 
only enabled if `_LIBCPP_ENABLE_THREAD_SAFETY_ANNOTATIONS` is manually defined.

There must have been some reason to do it like this in `__mutex_base`, but for 
`__thread_support` we unconditionally need such a macro.  I will try defining 
them slightly differently in `__thread_support` only instead.


https://reviews.llvm.org/D28520



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


[PATCH] D28080: [Docs][OpenCL] Added OpenCL feature description to user manual.

2017-01-10 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added inline comments.



Comment at: docs/UsersManual.rst:2003
+ $ clang -target nvptx64-unknown-unknown test.cl
+ $ clang -target amdgcn-unknown-amdhsa test.cl
+

$ clang -target amdgcn-amd-amdhsa-opencl test.cl



Comment at: docs/UsersManual.rst:2053
+
+Disables standard target extensions. All OpenCL targets provide a list
+of extensions that they support. Clang allows to amend this using the 
``-cl-ext``

Maybe rephrase as "Disables support of OpenCL extensions" instead of "Disable 
standard target extensions" since "standard target extension" is confusing and 
also to avoid confusion with the effect of disabling OpenCL extension as in 
'#pragam OPENCL EXTENSION X: disable'. Disabling support of an extension means 
that they cannot be enabled by pragmas in the OpenCL kernels since they are 
deemed as non-supported.



Comment at: docs/UsersManual.rst:2107
+
+ $ clang -target -triple amdgcn-unknown-amdhsa test.cl
+

$ clang -target amdgcn-amd-amdhsa-opencl test.cl



Comment at: docs/UsersManual.rst:2154
+and modules (:doc:`Modules`) are used internally to improve the compilation
+speed.
+

To enable modules for OpenCL, add option `-fmodules -fimplicit-module-maps 
-fmodules-cache-path=X` where X is the directory for storing the generated 
modules.


https://reviews.llvm.org/D28080



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


[PATCH] D28526: [ARM] Add diagnostics when initialization global variables with ropi/rwpi

2017-01-10 Thread Weiming Zhao via Phabricator via cfe-commits
weimingz created this revision.
weimingz added reviewers: olista01, jmolloy.
weimingz added a subscriber: cfe-commits.
Herald added subscribers: rengolin, aemerson.

This patch adds diagnoses when initializing a global variable using the address 
of another global variable that uses ROPI/RWPI relocation model.

For example, 
int a;
extern void foo();
int *x = // we cannot statically initialize x with -frwpi 
void *y = ();  // we can't statically initialize y with -fropi

The above code will trigger diagnoses like:

  error: 'x' cannot be initialized using address of 'a' with 'rwpi' relocation


https://reviews.llvm.org/D28526

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CodeGenModule.cpp
  lib/CodeGen/CodeGenModule.h
  test/CodeGen/arm-ropi-rwpi.c

Index: test/CodeGen/arm-ropi-rwpi.c
===
--- /dev/null
+++ test/CodeGen/arm-ropi-rwpi.c
@@ -0,0 +1,56 @@
+// REQUIRES: arm-registered-target
+
+// OK with local initialization, rwpi with const gv and ropi with non-const gv.
+// RUN: %clang_cc1 -triple armv7 -mrelocation-model ropi-rwpi %s -S -o /dev/null
+// RUN: %clang_cc1 -triple armv7 -mrelocation-model rwpi -DTEST_RO_1 -DTEST_RO_2 -DTEST_RO_STATIC %s -S -o /dev/null
+// RUN: %clang_cc1 -triple armv7 -mrelocation-model ropi -DTEST_RW_1 -DTEST_RW_STATIC %s -S -o /dev/null
+
+// RUN: not %clang_cc1 -triple armv7 -mrelocation-model ropi -DTEST_RO_1  %s -S -o /dev/null 2>&1 | FileCheck %s -check-prefix=CHECK-RO-1
+// RUN: not %clang_cc1 -triple armv7 -mrelocation-model ropi -DTEST_RO_2  %s -S -o /dev/null 2>&1 | FileCheck %s -check-prefix=CHECK-RO-2
+// RUN: not %clang_cc1 -triple armv7 -mrelocation-model ropi -DTEST_RO_STATIC  %s -S -o /dev/null 2>&1 | FileCheck %s -check-prefix=CHECK-RO-STATIC
+
+// RUN: not %clang_cc1 -triple armv7 -mrelocation-model rwpi -DTEST_RW_1  %s -S -o /dev/null 2>&1 | FileCheck %s -check-prefix=CHECK-RW-1
+
+// RUN: not %clang_cc1 -triple armv7 -mrelocation-model ropi-rwpi -DTEST_RW_STATIC  %s -S -o /dev/null 2>&1 | FileCheck %s -check-prefix=CHECK-RW-STATIC
+
+extern int func(void);
+
+extern int gv;
+
+extern const int c_gv;
+
+#ifdef TEST_RO_1
+void *p1 = 
+#endif
+// CHECK-RO-1: error: 'p1' cannot be initilized using address of 'func' with 'ropi' relocation
+
+#ifdef TEST_RO_2
+const void *p2 = _gv;
+#endif
+// CHECK-RO-2: error: 'p2' cannot be initilized using address of 'c_gv' with 'ropi' relocation
+
+#ifdef TEST_RO_STATIC
+void bar() {
+  static void *sp = 
+}
+#endif
+// CHECK-RO-STATIC: error: 'bar.sp' cannot be initilized using address of 'func' with 'ropi' relocation
+
+#ifdef TEST_RW_1
+void *p3 = 
+#endif
+// CHECK-RW-1: error: 'p3' cannot be initilized using address of 'gv' with 'rwpi' relocation
+
+#ifdef TEST_RW_STATIC
+void bar2() {
+  static void *sp = 
+}
+#endif
+// CHECK-RW-STATIC: error: 'bar2.sp' cannot be initilized using address of 'gv' with 'ropi-rwpi' relocation
+
+unsigned test() {
+  unsigned a = (unsigned)
+  unsigned b = (unsigned)
+  unsigned c = (unsigned)_gv;
+  return a + b + c;
+}
Index: lib/CodeGen/CodeGenModule.h
===
--- lib/CodeGen/CodeGenModule.h
+++ lib/CodeGen/CodeGenModule.h
@@ -500,6 +500,9 @@
   /// MDNodes.
   llvm::DenseMap MetadataIdMap;
 
+  /// The relocaton model for ARM.
+  bool IsROPI, IsRWPI;
+
 public:
   CodeGenModule(ASTContext , const HeaderSearchOptions ,
 const PreprocessorOptions ,
@@ -1189,6 +1192,10 @@
   /// \param QT is the clang QualType of the null pointer.
   llvm::Constant *getNullPointer(llvm::PointerType *T, QualType QT);
 
+  /// Check if a static initialization is valid for ROPI/RWPI.
+  bool isValidInitForPI(const llvm::Constant *Init, StringRef GVName,
+SourceLocation Loc);
+
 private:
   llvm::Constant *
   GetOrCreateLLVMFunction(StringRef MangledName, llvm::Type *Ty, GlobalDecl D,
Index: lib/CodeGen/CodeGenModule.cpp
===
--- lib/CodeGen/CodeGenModule.cpp
+++ lib/CodeGen/CodeGenModule.cpp
@@ -159,6 +159,9 @@
   // CoverageMappingModuleGen object.
   if (CodeGenOpts.CoverageMapping)
 CoverageMapping.reset(new CoverageMappingModuleGen(*this, *CoverageInfo));
+
+  IsROPI = StringRef(CodeGenOpts.RelocationModel).startswith("ropi");
+  IsRWPI = StringRef(CodeGenOpts.RelocationModel).endswith("rwpi");
 }
 
 CodeGenModule::~CodeGenModule() {}
@@ -2505,6 +2508,49 @@
   GO.setComdat(TheModule.getOrInsertComdat(GO.getName()));
 }
 
+/// Check if the address of a GV is used in the Init expr and the consntness
+/// matches with IsROPI. If such a GV is used, returns it.
+static const llvm::Constant *UseAddrOfGlobalVar(const llvm::Constant *Init,
+bool IsROPI) {
+  if (!Init)
+return nullptr;
+  if (isa(Init)) {
+bool IsConstGV = isa(Init);
+if 

[PATCH] D28404: IRGen: Add optnone attribute on function during O0

2017-01-10 Thread Mehdi AMINI via Phabricator via cfe-commits
mehdi_amini added a comment.

In https://reviews.llvm.org/D28404#641632, @probinson wrote:

> In https://reviews.llvm.org/D28404#641606, @mehdi_amini wrote:
>
> > If we want to support `-O0 -flto` and `optnone` it the way to convey this 
> > to the optimizer, I don't see the alternative.
>
>
> optsize != -Os (according to Chandler)
>  minsize != -Oz (according to Chandler)
>  optnone != -O0 (according to both me and Chandler)


Of course, but that's just an implementation limitation, mostly for historical 
reason I believe, not by design. That does not have to be set in stone and I'm 
giving you the direction with respect to LTO in particular here: these 
attributes should be able to behave the same way as the corresponding '-O' 
command line.

> optnone is not "the way to convey (-O0) to the optimizer."  Please get that 
> misunderstanding out of your head.  Clang handles -O0 by creating a short, 
> minimalist pipeline, and running everything through it.  Clang handles -O2 by 
> creating a fuller optimization pipeline, and functions with 'optnone' skip 
> many of the passes in the pipeline.

Don't get me wrong: I believe I have a very good understanding how the 
optimizer pipeline is setup and how the passes operates with respect to the 
attributes.
And it is because I understand the deficiencies (and how it is an issue with 
LTO) that I'm aligning all of this toward a consistent/coherent expected result 
for the users.

> These are architecturally different processes, you are not going to be able 
> to make 'optnone' behave exactly like -O0 without major redesign of how the 
> pipelines work.

I'd disagree about your estimation of "major". It's not gonna be tomorrow, 
sure, but it does not have to be. The most difficult part will be the inter 
procedural ones, but there are not that many.


https://reviews.llvm.org/D28404



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


[libcxx] r291592 - [CMake][libcxx] Move Python check to main CMake file

2017-01-10 Thread Petr Hosek via cfe-commits
Author: phosek
Date: Tue Jan 10 13:51:17 2017
New Revision: 291592

URL: http://llvm.org/viewvc/llvm-project?rev=291592=rev
Log:
[CMake][libcxx] Move Python check to main CMake file

This is to make sure this check is called even when building as
part of LLVM runtimes when we are doing standalone but not out of
tree build.

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

Modified:
libcxx/trunk/CMakeLists.txt
libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=291592=291591=291592=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Tue Jan 10 13:51:17 2017
@@ -32,6 +32,15 @@ if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURR
   include(HandleOutOfTreeLLVM)
 endif()
 
+if (LIBCXX_STANDALONE_BUILD)
+  include(FindPythonInterp)
+  if( NOT PYTHONINTERP_FOUND )
+message(WARNING "Failed to find python interpreter. "
+"The libc++ test suite will be disabled.")
+set(LLVM_INCLUDE_TESTS OFF)
+  endif()
+endif()
+
 # Require out of source build.
 include(MacroEnsureOutOfSourceBuild)
 MACRO_ENSURE_OUT_OF_SOURCE_BUILD(

Modified: libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake?rev=291592=291591=291592=diff
==
--- libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake (original)
+++ libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake Tue Jan 10 13:51:17 
2017
@@ -95,13 +95,6 @@ macro(configure_out_of_tree_llvm)
   endif()
 
   # LLVM Options --
-  include(FindPythonInterp)
-  if( NOT PYTHONINTERP_FOUND )
-message(WARNING "Failed to find python interpreter. "
-"The libc++ test suite will be disabled.")
-set(LLVM_INCLUDE_TESTS OFF)
-  endif()
-
   if (NOT DEFINED LLVM_INCLUDE_TESTS)
 set(LLVM_INCLUDE_TESTS ${LLVM_FOUND})
   endif()


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


Re: [clang-tools-extra] r291446 - [include-fixer] Load symbol index asynchronously.

2017-01-10 Thread Benjamin Kramer via cfe-commits
I didn't manage to reproduce this. Does adding ${PTHREAD_LIB} to
LINK_LIBS of tools/clang/tools/extra/include-fixer/plugin/CMakeLists.txt
help?

On Tue, Jan 10, 2017 at 8:31 PM, Bill Seurer  wrote:
> On 01/09/2017 09:18 AM, Benjamin Kramer via cfe-commits wrote:
>>
>> Author: d0k
>> Date: Mon Jan  9 09:18:28 2017
>> New Revision: 291446
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=291446=rev
>> Log:
>> [include-fixer] Load symbol index asynchronously.
>>
>> We don't actually need the index until parse time, so fetch it in the
>> background and start parsing. By the time it is actually needed it's
>> likely that the loading phase has completed in the background.
>
>
> This update causes a linker error on ppc64le on a Release+Asserts+Shared
> build.
>
> cmake with -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON
> -DBUILD_SHARED_LIBS=ON
>
> http://lab.llvm.org:8011/builders/clang-ppc64le-linux-multistage/builds/754
>
>
> Details:
>
> [117/123] Linking CXX shared library
> lib/libclangIncludeFixerPlugin.so.40.0svn
> FAILED: : && /home/seurer/gcc/install/gcc-5.4.0/bin/g++  -fPIC -fPIC
> -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings
> -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long
> -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment
> -Werror=date-time -std=c++11 -ffunction-sections -fdata-sections -fno-common
> -Woverloaded-virtual -fno-strict-aliasing -O3
> -L/home/seurer/gcc/install/gcc-5.4.0/lib64 -Wl,-z,defs
> -Wl,-rpath-link,/home/seurer/llvm/build/llvm-test2/./lib  -Wl,-O3
> -Wl,--gc-sections -shared -Wl,-soname,libclangIncludeFixerPlugin.so.40 -o
> lib/libclangIncludeFixerPlugin.so.40.0svn
> tools/clang/tools/extra/include-fixer/plugin/CMakeFiles/clangIncludeFixerPlugin.dir/IncludeFixerPlugin.cpp.o
> lib/libclangAST.so.40.0svn lib/libclangBasic.so.40.0svn
> lib/libclangFrontend.so.40.0svn lib/libclangIncludeFixer.so.40.0svn
> lib/libclangParse.so.40.0svn lib/libclangSema.so.40.0svn
> lib/libclangTooling.so.40.0svn lib/libLLVMSupport.so.40.0svn
> -Wl,-rpath,"\$ORIGIN/../lib" && :
> tools/clang/tools/extra/include-fixer/plugin/CMakeFiles/clangIncludeFixerPlugin.dir/IncludeFixerPlugin.cpp.o:(.toc+0xb0):
> undefined reference to `pthread_create'
> collect2: error: ld returned 1 exit status
> [117/123] Building CXX object
> tools/clang/tools/extra/include-fixer/tool/CMakeFiles/clang-include-fixer.dir/ClangIncludeFixer.cpp.o
> ninja: build stopped: subcommand failed.
> [1/7] Linking CXX shared library lib/libclangIncludeFixerPlugin.so.40.0svn
> FAILED: : && /home/seurer/gcc/install/gcc-5.4.0/bin/g++  -fPIC -fPIC
> -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings
> -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long
> -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment
> -Werror=date-time -std=c++11 -ffunction-sections -fdata-sections -fno-common
> -Woverloaded-virtual -fno-strict-aliasing -O3
> -L/home/seurer/gcc/install/gcc-5.4.0/lib64 -Wl,-z,defs
> -Wl,-rpath-link,/home/seurer/llvm/build/llvm-test2/./lib  -Wl,-O3
> -Wl,--gc-sections -shared -Wl,-soname,libclangIncludeFixerPlugin.so.40 -o
> lib/libclangIncludeFixerPlugin.so.40.0svn
> tools/clang/tools/extra/include-fixer/plugin/CMakeFiles/clangIncludeFixerPlugin.dir/IncludeFixerPlugin.cpp.o
> lib/libclangAST.so.40.0svn lib/libclangBasic.so.40.0svn
> lib/libclangFrontend.so.40.0svn lib/libclangIncludeFixer.so.40.0svn
> lib/libclangParse.so.40.0svn lib/libclangSema.so.40.0svn
> lib/libclangTooling.so.40.0svn lib/libLLVMSupport.so.40.0svn
> -Wl,-rpath,"\$ORIGIN/../lib" && :
> tools/clang/tools/extra/include-fixer/plugin/CMakeFiles/clangIncludeFixerPlugin.dir/IncludeFixerPlugin.cpp.o:(.toc+0xb0):
> undefined reference to `pthread_create'
> collect2: error: ld returned 1 exit status
>
>
>
>
>
>> Modified:
>> clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp
>> clang-tools-extra/trunk/include-fixer/SymbolIndexManager.h
>> clang-tools-extra/trunk/include-fixer/plugin/IncludeFixerPlugin.cpp
>> clang-tools-extra/trunk/include-fixer/tool/ClangIncludeFixer.cpp
>> clang-tools-extra/trunk/unittests/include-fixer/IncludeFixerTest.cpp
>>
>> Modified: clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp?rev=291446=291445=291446=diff
>>
>> ==
>> --- clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp
>> (original)
>> +++ clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp Mon Jan
>> 9 09:18:28 2017
>> @@ -64,7 +64,7 @@ SymbolIndexManager::search(llvm::StringR
>>do {
>>  std::vector Symbols;
>>  for (const auto  : SymbolIndices) {
>> -  auto Res = DB->search(Names.back().str());
>> +  auto Res = DB.get()->search(Names.back());
>>

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

2017-01-10 Thread Dimitry Andric via Phabricator via cfe-commits
dim updated this revision to Diff 83843.
dim added a comment.

- Move `_LIBCPP_THREAD_SAFETY_ANNOTATION` macro definition to `__config`.
- Add `_LIBCPP_THREAD_SAFETY_ANNOTATION(no_thread_safety_analysis)` macros to 
`__threading_support` function declarations which require them.

Note that I was not able to figure out how to make the other thread safety 
annotation attributes, such as `try_acquire_capability()`, match to the 
function signatures, as these use `int` instead of `bool`, for example.


https://reviews.llvm.org/D28520

Files:
  include/__config
  include/__mutex_base
  include/__threading_support


Index: include/__threading_support
===
--- include/__threading_support
+++ include/__threading_support
@@ -98,25 +98,25 @@
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_recursive_mutex_init(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY 
_LIBCPP_THREAD_SAFETY_ANNOTATION(no_thread_safety_analysis)
 int __libcpp_recursive_mutex_lock(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY 
_LIBCPP_THREAD_SAFETY_ANNOTATION(no_thread_safety_analysis)
 int __libcpp_recursive_mutex_trylock(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY 
_LIBCPP_THREAD_SAFETY_ANNOTATION(no_thread_safety_analysis)
 int __libcpp_recursive_mutex_unlock(__libcpp_recursive_mutex_t *__m);
 
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_recursive_mutex_destroy(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY 
_LIBCPP_THREAD_SAFETY_ANNOTATION(no_thread_safety_analysis)
 int __libcpp_mutex_lock(__libcpp_mutex_t *__m);
 
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_mutex_trylock(__libcpp_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY 
_LIBCPP_THREAD_SAFETY_ANNOTATION(no_thread_safety_analysis)
 int __libcpp_mutex_unlock(__libcpp_mutex_t *__m);
 
 _LIBCPP_THREAD_ABI_VISIBILITY
@@ -129,10 +129,10 @@
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_condvar_broadcast(__libcpp_condvar_t* __cv);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY 
_LIBCPP_THREAD_SAFETY_ANNOTATION(no_thread_safety_analysis)
 int __libcpp_condvar_wait(__libcpp_condvar_t* __cv, __libcpp_mutex_t* __m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY 
_LIBCPP_THREAD_SAFETY_ANNOTATION(no_thread_safety_analysis)
 int __libcpp_condvar_timedwait(__libcpp_condvar_t *__cv, __libcpp_mutex_t *__m,
timespec *__ts);
 
Index: include/__mutex_base
===
--- include/__mutex_base
+++ include/__mutex_base
@@ -24,14 +24,6 @@
 
 #ifndef _LIBCPP_HAS_NO_THREADS
 
-#ifndef _LIBCPP_THREAD_SAFETY_ANNOTATION
-#  ifdef _LIBCPP_HAS_THREAD_SAFETY_ANNOTATIONS
-#define _LIBCPP_THREAD_SAFETY_ANNOTATION(x) __attribute__((x))
-#  else
-#define _LIBCPP_THREAD_SAFETY_ANNOTATION(x)
-#  endif
-#endif  // _LIBCPP_THREAD_SAFETY_ANNOTATION
-
 class _LIBCPP_TYPE_VIS _LIBCPP_THREAD_SAFETY_ANNOTATION(capability("mutex")) 
mutex
 {
 #ifndef _LIBCPP_HAS_NO_CONSTEXPR
Index: include/__config
===
--- include/__config
+++ include/__config
@@ -981,6 +981,16 @@
 #define _LIBCPP_HAS_THREAD_SAFETY_ANNOTATIONS
 #endif
 
+#if !defined(_LIBCPP_HAS_NO_THREADS)
+# if !defined(_LIBCPP_THREAD_SAFETY_ANNOTATION)
+#  if defined(_LIBCPP_HAS_THREAD_SAFETY_ANNOTATIONS)
+#   define _LIBCPP_THREAD_SAFETY_ANNOTATION(x) __attribute__((x))
+#  else
+#   define _LIBCPP_THREAD_SAFETY_ANNOTATION(x)
+#  endif
+# endif
+#endif
+
 #if __has_attribute(require_constant_initialization)
 #define _LIBCPP_SAFE_STATIC 
__attribute__((__require_constant_initialization__))
 #else


Index: include/__threading_support
===
--- include/__threading_support
+++ include/__threading_support
@@ -98,25 +98,25 @@
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_recursive_mutex_init(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_THREAD_SAFETY_ANNOTATION(no_thread_safety_analysis)
 int __libcpp_recursive_mutex_lock(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_THREAD_SAFETY_ANNOTATION(no_thread_safety_analysis)
 int __libcpp_recursive_mutex_trylock(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_THREAD_SAFETY_ANNOTATION(no_thread_safety_analysis)
 int __libcpp_recursive_mutex_unlock(__libcpp_recursive_mutex_t *__m);
 
 _LIBCPP_THREAD_ABI_VISIBILITY
 int __libcpp_recursive_mutex_destroy(__libcpp_recursive_mutex_t *__m);
 
-_LIBCPP_THREAD_ABI_VISIBILITY
+_LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_THREAD_SAFETY_ANNOTATION(no_thread_safety_analysis)
 int 

[PATCH] D28404: IRGen: Add optnone attribute on function during O0

2017-01-10 Thread Paul Robinson via Phabricator via cfe-commits
probinson added a comment.

In https://reviews.llvm.org/D28404#641606, @mehdi_amini wrote:

> If we want to support `-O0 -flto` and `optnone` it the way to convey this to 
> the optimizer, I don't see the alternative.


optsize != -Os (according to Chandler)
minsize != -Oz (according to Chandler)
optnone != -O0 (according to both me and Chandler)

optnone is not "the way to convey (-O0) to the optimizer."  Please get that 
misunderstanding out of your head.  Clang handles -O0 by creating a short, 
minimalist pipeline, and running everything through it.  Clang handles -O2 by 
creating a fuller optimization pipeline, and functions with 'optnone' skip many 
of the passes in the pipeline.

These are architecturally different processes, you are not going to be able to 
make 'optnone' behave exactly like -O0 without major redesign of how the 
pipelines work.


https://reviews.llvm.org/D28404



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


[PATCH] D28419: clang-tools-extra: add gitattributes to disable EOL conversions on checkout of test source files

2017-01-10 Thread Antonio Maiorano via Phabricator via cfe-commits
amaiorano added a comment.

Last night, I realized that this problem extends to the clang/tests as well, 
not just those in clang-tools-extra. Is there someone who knows Windows, Git, 
and the testing pipeline that can weigh in more on this topic?


https://reviews.llvm.org/D28419



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


[PATCH] D28404: IRGen: Add optnone attribute on function during O0

2017-01-10 Thread Mehdi AMINI via Phabricator via cfe-commits
mehdi_amini added a comment.

In https://reviews.llvm.org/D28404#641597, @probinson wrote:

> In https://reviews.llvm.org/D28404#641557, @mehdi_amini wrote:
>
> > As I stand right now, there hasn't been any correction. 
> >  I still consider the fact that `optnone` wouldn't produce the "same" 
> > result (modulo corner cases around `merging global variables` for instance) 
> > as O0 a bug that need to be fixed.
>
>
> Why?


Why not? What's the alternative?
If we want to support `-O0 -flto` and `optnone` it the way to convey this to 
the optimizer, I don't see the alternative.


https://reviews.llvm.org/D28404



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


[PATCH] D28404: IRGen: Add optnone attribute on function during O0

2017-01-10 Thread Paul Robinson via Phabricator via cfe-commits
probinson added a comment.

In https://reviews.llvm.org/D28404#641557, @mehdi_amini wrote:

> As I stand right now, there hasn't been any correction. 
>  I still consider the fact that `optnone` wouldn't produce the "same" result 
> (modulo corner cases around `merging global variables` for instance) as O0 a 
> bug that need to be fixed.


Why?  That's not the purpose of optnone.  You've already admitted there are 
some differences.  Why are other differences important?


https://reviews.llvm.org/D28404



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


Re: [clang-tools-extra] r291446 - [include-fixer] Load symbol index asynchronously.

2017-01-10 Thread Bill Seurer via cfe-commits

On 01/09/2017 09:18 AM, Benjamin Kramer via cfe-commits wrote:

Author: d0k
Date: Mon Jan  9 09:18:28 2017
New Revision: 291446

URL: http://llvm.org/viewvc/llvm-project?rev=291446=rev
Log:
[include-fixer] Load symbol index asynchronously.

We don't actually need the index until parse time, so fetch it in the
background and start parsing. By the time it is actually needed it's
likely that the loading phase has completed in the background.


This update causes a linker error on ppc64le on a Release+Asserts+Shared 
build.


cmake with -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON 
-DBUILD_SHARED_LIBS=ON


http://lab.llvm.org:8011/builders/clang-ppc64le-linux-multistage/builds/754


Details:

[117/123] Linking CXX shared library 
lib/libclangIncludeFixerPlugin.so.40.0svn
FAILED: : && /home/seurer/gcc/install/gcc-5.4.0/bin/g++  -fPIC -fPIC 
-fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic 
-Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor 
-Wno-comment -Werror=date-time -std=c++11 -ffunction-sections 
-fdata-sections -fno-common -Woverloaded-virtual -fno-strict-aliasing 
-O3  -L/home/seurer/gcc/install/gcc-5.4.0/lib64 -Wl,-z,defs 
-Wl,-rpath-link,/home/seurer/llvm/build/llvm-test2/./lib  -Wl,-O3 
-Wl,--gc-sections -shared -Wl,-soname,libclangIncludeFixerPlugin.so.40 
-o lib/libclangIncludeFixerPlugin.so.40.0svn 
tools/clang/tools/extra/include-fixer/plugin/CMakeFiles/clangIncludeFixerPlugin.dir/IncludeFixerPlugin.cpp.o 
 lib/libclangAST.so.40.0svn lib/libclangBasic.so.40.0svn 
lib/libclangFrontend.so.40.0svn lib/libclangIncludeFixer.so.40.0svn 
lib/libclangParse.so.40.0svn lib/libclangSema.so.40.0svn 
lib/libclangTooling.so.40.0svn lib/libLLVMSupport.so.40.0svn 
-Wl,-rpath,"\$ORIGIN/../lib" && :
tools/clang/tools/extra/include-fixer/plugin/CMakeFiles/clangIncludeFixerPlugin.dir/IncludeFixerPlugin.cpp.o:(.toc+0xb0): 
undefined reference to `pthread_create'

collect2: error: ld returned 1 exit status
[117/123] Building CXX object 
tools/clang/tools/extra/include-fixer/tool/CMakeFiles/clang-include-fixer.dir/ClangIncludeFixer.cpp.o

ninja: build stopped: subcommand failed.
[1/7] Linking CXX shared library lib/libclangIncludeFixerPlugin.so.40.0svn
FAILED: : && /home/seurer/gcc/install/gcc-5.4.0/bin/g++  -fPIC -fPIC 
-fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic 
-Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor 
-Wno-comment -Werror=date-time -std=c++11 -ffunction-sections 
-fdata-sections -fno-common -Woverloaded-virtual -fno-strict-aliasing 
-O3  -L/home/seurer/gcc/install/gcc-5.4.0/lib64 -Wl,-z,defs 
-Wl,-rpath-link,/home/seurer/llvm/build/llvm-test2/./lib  -Wl,-O3 
-Wl,--gc-sections -shared -Wl,-soname,libclangIncludeFixerPlugin.so.40 
-o lib/libclangIncludeFixerPlugin.so.40.0svn 
tools/clang/tools/extra/include-fixer/plugin/CMakeFiles/clangIncludeFixerPlugin.dir/IncludeFixerPlugin.cpp.o 
 lib/libclangAST.so.40.0svn lib/libclangBasic.so.40.0svn 
lib/libclangFrontend.so.40.0svn lib/libclangIncludeFixer.so.40.0svn 
lib/libclangParse.so.40.0svn lib/libclangSema.so.40.0svn 
lib/libclangTooling.so.40.0svn lib/libLLVMSupport.so.40.0svn 
-Wl,-rpath,"\$ORIGIN/../lib" && :
tools/clang/tools/extra/include-fixer/plugin/CMakeFiles/clangIncludeFixerPlugin.dir/IncludeFixerPlugin.cpp.o:(.toc+0xb0): 
undefined reference to `pthread_create'

collect2: error: ld returned 1 exit status





Modified:
clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp
clang-tools-extra/trunk/include-fixer/SymbolIndexManager.h
clang-tools-extra/trunk/include-fixer/plugin/IncludeFixerPlugin.cpp
clang-tools-extra/trunk/include-fixer/tool/ClangIncludeFixer.cpp
clang-tools-extra/trunk/unittests/include-fixer/IncludeFixerTest.cpp

Modified: clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp?rev=291446=291445=291446=diff
==
--- clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp (original)
+++ clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp Mon Jan  9 
09:18:28 2017
@@ -64,7 +64,7 @@ SymbolIndexManager::search(llvm::StringR
   do {
 std::vector Symbols;
 for (const auto  : SymbolIndices) {
-  auto Res = DB->search(Names.back().str());
+  auto Res = DB.get()->search(Names.back());
   Symbols.insert(Symbols.end(), Res.begin(), Res.end());
 }


Modified: clang-tools-extra/trunk/include-fixer/SymbolIndexManager.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/include-fixer/SymbolIndexManager.h?rev=291446=291445=291446=diff
==
--- clang-tools-extra/trunk/include-fixer/SymbolIndexManager.h (original)

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

2017-01-10 Thread Eric Fiselier via Phabricator via cfe-commits
EricWF added a comment.

In https://reviews.llvm.org/D28520#641569, @dim wrote:

> In https://reviews.llvm.org/D28520#641563, @EricWF wrote:
>
> > Also look in `__mutex` where libc++ defines its own macros for the 
> > annotations.
>
>
> I assume you mean `__mutex_base`.  Do we want to reuse the macros from that 
> file?  If so we'd have to include it in `__thread_support`.  Maybe it is 
> better to move the macros to `__config` instead, then.


Yes sorry `__mutex_base`. Moving them to `__config` sounds reasonable.


https://reviews.llvm.org/D28520



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


[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

2017-01-10 Thread Dimitry Andric via Phabricator via cfe-commits
dim added a comment.

In https://reviews.llvm.org/D28520#641563, @EricWF wrote:

> Also look in `__mutex` where libc++ defines its own macros for the 
> annotations.


I assume you mean `__mutex_base`.  Do we want to reuse the macros from that 
file?  If so we'd have to include it in `__thread_support`.  Maybe it is better 
to move the macros to `__config` instead, then.


https://reviews.llvm.org/D28520



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


[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

2017-01-10 Thread Eric Fiselier via Phabricator via cfe-commits
EricWF added a comment.

Also look in `__mutex` where libc++ defines its own macros for the annotations.


https://reviews.llvm.org/D28520



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


[PATCH] D28148: [Sema] Suppress warnings for C's zero initializer

2017-01-10 Thread S. Gilles via Phabricator via cfe-commits
sgilles marked an inline comment as done.
sgilles added a comment.

Ping - if there are no comments, could this be accepted?


https://reviews.llvm.org/D28148



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


[PATCH] D28404: IRGen: Add optnone attribute on function during O0

2017-01-10 Thread Mehdi AMINI via Phabricator via cfe-commits
mehdi_amini added a comment.

In https://reviews.llvm.org/D28404#641538, @probinson wrote:

> > - optnone isn't *really* no optimizations: clearly this is true, but then 
> > neither is -O0. We run the always inliner, a couple of other passes, and we 
> > run several parts of the code generators optimizer. I understand why 
> > optnone deficiencies (ie, too many optimizations) might be frustrating, but 
> > having *more users* seems likely to make this *better*.
>
> We have picked all the low-hanging fruit there, and probably some 
> medium-hanging fruit.  Mehdi did have the misunderstanding that optnone == 
> -O0 and that I think was worth correcting.


As I stand right now, there hasn't been any correction. 
I still consider the fact that `optnone` wouldn't produce the "same" result 
(modulo corner cases around `merging global variables` for instance) as O0 a 
bug that need to be fixed.

(Disabling passes for compile time at O0 stays I compile time improvement, I 
never suggested to stop doing this...)


https://reviews.llvm.org/D28404



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


[PATCH] D20693: [clang-tidy] New checker to replace dynamic exception specifications

2017-01-10 Thread don hinton via Phabricator via cfe-commits
hintonda added inline comments.



Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:68
+  this);
+}
+

aaron.ballman wrote:
> hintonda wrote:
> > aaron.ballman wrote:
> > > Also missing: typedefs and using declarations.
> > As far as I know, it isn't legal to add dynamic exception specifications to 
> > typedefs and using declarations.
> Hmm, I thought you could, at least in C++17, since it's now part of the 
> function's type. However, I don't have a standard in front of me at the 
> moment, so I'll have to double-check. It can always be added in a follow-up 
> patch and need not block this one.
> 
> However, I do know the following is allowed in a typedef, and I don't think 
> your existing ParmVarDecl matcher will catch it:
> ```
> typedef void (*fp)(void (*f)(int) throw());
> ```
clang doesn't allow dynamic exception specs in typedef or using declarations 
for either c++11 or c++14, but does in c++1z since throw() is an alias for 
noexcept.  I'll try to add an appropriate test to highlight this.


I've added your typedef example -- thanks for suggesting it -- and the matcher 
does catch it and does the appropriate fixit.



Comment at: docs/clang-tidy/checks/modernize-use-noexcept.rst:30
+By default this check will only replace ``throw()`` with ``noexcept``,
+and ``throw([,...])`` or ``throw(...)`` with blank except
+for operator delete and destructors, which are replaced with

aaron.ballman wrote:
> hintonda wrote:
> > aaron.ballman wrote:
> > > I continue to object to removing the explicit exception specification 
> > > entirely as the default behavior without strong justification. Further. 
> > > there is no option to control this behavior.
> > I tried to make sure it's only applied where appropriate.  If I missed a 
> > case, please let me know, but I'm not sure an option "just in case" is 
> > right solution.
> > 
> > However, I did try to structure the code in a way to make it easy to add an 
> > option if that turns out the be the right thing to do.
> The behavior as it's implemented now is not the behavior I would expect from 
> such a check -- I think that `throw(int)` should get a FixIt to 
> `noexcept(false)` rather than no `noexcept` clause whatsoever. Despite them 
> being functionally equivalent in most cases, the explicit nature of the 
> dynamic exception specification should be retained with an explicit noexcept 
> exception specification, not discarded. If you really want `throw(int)` to be 
> modified to have no explicit exception specification, I think that should be 
> an option (off by default). If you would rather not make an option, then I 
> think the explicit exception specification should remain.
Makes sense.  Will do.



Comment at: docs/clang-tidy/checks/modernize-use-noexcept.rst:38
+that don't support the ``noexcept`` keyword.  Users can define the
+macro to be ``noexcept`` or ``throw()`` depending on whether or not
+noexcept is supported.  Specifications that can throw, e.g.,

aaron.ballman wrote:
> hintonda wrote:
> > aaron.ballman wrote:
> > > I'm not certain I understand the justification of calling out older 
> > > compilers or suggesting use of `throw()`. The check will continually flag 
> > > `throw()` and try to recommend `noexcept` in its place, won't it? At 
> > > least, that's how I read the preceding paragraph.
> > > 
> > > I think the macro replacement is a reasonable feature, but I think the 
> > > check only makes sense for C++11 or later, since C++98 users really have 
> > > no alternatives to dynamic exception specifications.
> > Libraries, e.g., libc++, that need to support both multiple versions of the 
> > standard, use macros to switch between throw() and noexcept.
> > 
> > So this option was designed to be libc++ friendly.  If that's not 
> > appropriate, I can remove it.
> I think the *option* is fine; I think the wording is confusing. How about:
> ```
> Alternatively, users can also use :option:`ReplacementString` to
> specify a macro to use instead of ``noexcept``.  This is useful when
> maintaining source code that uses custom exception specification marking
> other than ``noexcept``.
> ```
Ah, okay, that sounds much better.  I'll make this change shortly.


https://reviews.llvm.org/D20693



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


r291583 - [OpenMP] Remove outdated comments. NFC.

2017-01-10 Thread Kelvin Li via cfe-commits
Author: kli
Date: Tue Jan 10 12:57:07 2017
New Revision: 291583

URL: http://llvm.org/viewvc/llvm-project?rev=291583=rev
Log:
[OpenMP] Remove outdated comments. NFC.

Modified:
cfe/trunk/include/clang/Basic/OpenMPKinds.def

Modified: cfe/trunk/include/clang/Basic/OpenMPKinds.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/OpenMPKinds.def?rev=291583=291582=291583=diff
==
--- cfe/trunk/include/clang/Basic/OpenMPKinds.def (original)
+++ cfe/trunk/include/clang/Basic/OpenMPKinds.def Tue Jan 10 12:57:07 2017
@@ -450,7 +450,6 @@ OPENMP_TARGET_CLAUSE(firstprivate)
 OPENMP_TARGET_CLAUSE(is_device_ptr)
 
 // Clauses allowed for OpenMP directive 'target data'.
-// TODO More clauses for 'target data' directive.
 OPENMP_TARGET_DATA_CLAUSE(if)
 OPENMP_TARGET_DATA_CLAUSE(device)
 OPENMP_TARGET_DATA_CLAUSE(map)
@@ -508,7 +507,6 @@ OPENMP_TARGET_PARALLEL_FOR_CLAUSE(linear
 OPENMP_TARGET_PARALLEL_FOR_CLAUSE(is_device_ptr)
 
 // Clauses allowed for OpenMP directive 'target update'.
-// TODO More clauses for 'target update' directive.
 OPENMP_TARGET_UPDATE_CLAUSE(if)
 OPENMP_TARGET_UPDATE_CLAUSE(device)
 OPENMP_TARGET_UPDATE_CLAUSE(to)
@@ -517,7 +515,6 @@ OPENMP_TARGET_UPDATE_CLAUSE(nowait)
 OPENMP_TARGET_UPDATE_CLAUSE(depend)
 
 // Clauses allowed for OpenMP directive 'teams'.
-// TODO More clauses for 'teams' directive.
 OPENMP_TEAMS_CLAUSE(default)
 OPENMP_TEAMS_CLAUSE(private)
 OPENMP_TEAMS_CLAUSE(firstprivate)
@@ -527,7 +524,6 @@ OPENMP_TEAMS_CLAUSE(num_teams)
 OPENMP_TEAMS_CLAUSE(thread_limit)
 
 // Clauses allowed for OpenMP directive 'ordered'.
-// TODO More clauses for 'ordered' directive.
 OPENMP_ORDERED_CLAUSE(threads)
 OPENMP_ORDERED_CLAUSE(simd)
 OPENMP_ORDERED_CLAUSE(depend)


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


r291582 - [ARM] Use generic bitreverse intrinsic, rather than ARM specific rbit.

2017-01-10 Thread Chad Rosier via cfe-commits
Author: mcrosier
Date: Tue Jan 10 12:55:11 2017
New Revision: 291582

URL: http://llvm.org/viewvc/llvm-project?rev=291582=rev
Log:
[ARM] Use generic bitreverse intrinsic, rather than ARM specific rbit.

The backend already supports lowering this intrinsic to a rbit instruction.

Modified:
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/test/CodeGen/arm_acle.c
cfe/trunk/test/CodeGen/builtins-arm.c

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=291582=291581=291582=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Tue Jan 10 12:55:11 2017
@@ -4318,9 +4318,9 @@ Value *CodeGenFunction::EmitARMBuiltinEx
   }
 
   if (BuiltinID == ARM::BI__builtin_arm_rbit) {
-return Builder.CreateCall(CGM.getIntrinsic(Intrinsic::arm_rbit),
-   EmitScalarExpr(E->getArg(0)),
-  "rbit");
+llvm::Value *Arg = EmitScalarExpr(E->getArg(0));
+return Builder.CreateCall(
+CGM.getIntrinsic(Intrinsic::bitreverse, Arg->getType()), Arg, "rbit");
   }
 
   if (BuiltinID == ARM::BI__clear_cache) {

Modified: cfe/trunk/test/CodeGen/arm_acle.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/arm_acle.c?rev=291582=291581=291582=diff
==
--- cfe/trunk/test/CodeGen/arm_acle.c (original)
+++ cfe/trunk/test/CodeGen/arm_acle.c Tue Jan 10 12:55:11 2017
@@ -244,22 +244,22 @@ int16_t test_revsh(int16_t t) {
 }
 
 // ARM-LABEL: test_rbit
-// AArch32: call i32 @llvm.arm.rbit
+// AArch32: call i32 @llvm.bitreverse.i32
 // AArch64: call i32 @llvm.bitreverse.i32
 uint32_t test_rbit(uint32_t t) {
   return __rbit(t);
 }
 
 // ARM-LABEL: test_rbitl
-// AArch32: call i32 @llvm.arm.rbit
+// AArch32: call i32 @llvm.bitreverse.i32
 // AArch64: call i64 @llvm.bitreverse.i64
 long test_rbitl(long t) {
   return __rbitl(t);
 }
 
 // ARM-LABEL: test_rbitll
-// AArch32: call i32 @llvm.arm.rbit
-// AArch32: call i32 @llvm.arm.rbit
+// AArch32: call i32 @llvm.bitreverse.i32
+// AArch32: call i32 @llvm.bitreverse.i32
 // AArch64: call i64 @llvm.bitreverse.i64
 uint64_t test_rbitll(uint64_t t) {
   return __rbitll(t);

Modified: cfe/trunk/test/CodeGen/builtins-arm.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/builtins-arm.c?rev=291582=291581=291582=diff
==
--- cfe/trunk/test/CodeGen/builtins-arm.c (original)
+++ cfe/trunk/test/CodeGen/builtins-arm.c Tue Jan 10 12:55:11 2017
@@ -68,7 +68,7 @@ void test_barrier() {
   __builtin_arm_isb(3); //CHECK: call {{.*}} @llvm.arm.isb(i32 3)
 }
 
-// CHECK: call {{.*}} @llvm.arm.rbit(i32 %a)
+// CHECK: call {{.*}} @llvm.bitreverse.i32(i32 %a)
 
 unsigned rbit(unsigned a) {
   return __builtin_arm_rbit(a);


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


[PATCH] D28033: [analyzer] Treat pointers to static member functions as function pointers

2017-01-10 Thread Devin Coughlin via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL291581: [analyzer] Treat pointers to static member functions 
as function pointers (authored by dcoughlin).

Changed prior to commit:
  https://reviews.llvm.org/D28033?vs=83828=83830#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D28033

Files:
  cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp
  cfe/trunk/test/Analysis/pointer-to-member.cpp


Index: cfe/trunk/test/Analysis/pointer-to-member.cpp
===
--- cfe/trunk/test/Analysis/pointer-to-member.cpp
+++ cfe/trunk/test/Analysis/pointer-to-member.cpp
@@ -77,7 +77,8 @@
 namespace testPointerToMemberFunction {
   struct A {
 virtual int foo() { return 1; }
-int bar() { return 2;  }
+int bar() { return 2; }
+int static staticMemberFunction(int p) { return p + 1; };
   };
 
   struct B : public A {
@@ -111,11 +112,19 @@
 
 clang_analyzer_eval((APtr->*AFP)() == 3); // expected-warning{{TRUE}}
   }
+
+  void testPointerToStaticMemberCall() {
+int (*fPtr)(int) = ::staticMemberFunction;
+if (fPtr != 0) { // no-crash
+  clang_analyzer_eval(fPtr(2) == 3); // expected-warning{{TRUE}}
+}
+  }
 } // end of testPointerToMemberFunction namespace
 
 namespace testPointerToMemberData {
   struct A {
 int i;
+static int j;
   };
 
   void testPointerToMemberData() {
@@ -126,6 +135,13 @@
 a.*AMdPointer += 1;
 
 clang_analyzer_eval(a.i == 43); // expected-warning{{TRUE}}
+
+int *ptrToStaticField = ::j;
+if (ptrToStaticField != 0) {
+  *ptrToStaticField = 7;
+  clang_analyzer_eval(*ptrToStaticField == 7); // expected-warning{{TRUE}}
+  clang_analyzer_eval(A::j == 7); // expected-warning{{TRUE}}
+}
   }
 } // end of testPointerToMemberData namespace
 
Index: cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp
===
--- cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp
+++ cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp
@@ -218,6 +218,18 @@
 }
 
 DefinedSVal SValBuilder::getMemberPointer(const DeclaratorDecl* DD) {
+  assert(!DD || isa(DD) || isa(DD));
+
+  if (auto *MD = dyn_cast_or_null(DD)) {
+// Sema treats pointers to static member functions as have function pointer
+// type, so return a function pointer for the method.
+// We don't need to play a similar trick for static member fields
+// because these are represented as plain VarDecls and not FieldDecls
+// in the AST.
+if (MD->isStatic())
+  return getFunctionPointer(MD);
+  }
+
   return nonloc::PointerToMember(DD);
 }
 


Index: cfe/trunk/test/Analysis/pointer-to-member.cpp
===
--- cfe/trunk/test/Analysis/pointer-to-member.cpp
+++ cfe/trunk/test/Analysis/pointer-to-member.cpp
@@ -77,7 +77,8 @@
 namespace testPointerToMemberFunction {
   struct A {
 virtual int foo() { return 1; }
-int bar() { return 2;  }
+int bar() { return 2; }
+int static staticMemberFunction(int p) { return p + 1; };
   };
 
   struct B : public A {
@@ -111,11 +112,19 @@
 
 clang_analyzer_eval((APtr->*AFP)() == 3); // expected-warning{{TRUE}}
   }
+
+  void testPointerToStaticMemberCall() {
+int (*fPtr)(int) = ::staticMemberFunction;
+if (fPtr != 0) { // no-crash
+  clang_analyzer_eval(fPtr(2) == 3); // expected-warning{{TRUE}}
+}
+  }
 } // end of testPointerToMemberFunction namespace
 
 namespace testPointerToMemberData {
   struct A {
 int i;
+static int j;
   };
 
   void testPointerToMemberData() {
@@ -126,6 +135,13 @@
 a.*AMdPointer += 1;
 
 clang_analyzer_eval(a.i == 43); // expected-warning{{TRUE}}
+
+int *ptrToStaticField = ::j;
+if (ptrToStaticField != 0) {
+  *ptrToStaticField = 7;
+  clang_analyzer_eval(*ptrToStaticField == 7); // expected-warning{{TRUE}}
+  clang_analyzer_eval(A::j == 7); // expected-warning{{TRUE}}
+}
   }
 } // end of testPointerToMemberData namespace
 
Index: cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp
===
--- cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp
+++ cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp
@@ -218,6 +218,18 @@
 }
 
 DefinedSVal SValBuilder::getMemberPointer(const DeclaratorDecl* DD) {
+  assert(!DD || isa(DD) || isa(DD));
+
+  if (auto *MD = dyn_cast_or_null(DD)) {
+// Sema treats pointers to static member functions as have function pointer
+// type, so return a function pointer for the method.
+// We don't need to play a similar trick for static member fields
+// because these are represented as plain VarDecls and not FieldDecls
+// in the AST.
+if (MD->isStatic())
+  return getFunctionPointer(MD);
+  }
+
   return nonloc::PointerToMember(DD);
 }
 
___
cfe-commits mailing list

r291581 - [analyzer] Treat pointers to static member functions as function pointers

2017-01-10 Thread Devin Coughlin via cfe-commits
Author: dcoughlin
Date: Tue Jan 10 12:49:27 2017
New Revision: 291581

URL: http://llvm.org/viewvc/llvm-project?rev=291581=rev
Log:
[analyzer] Treat pointers to static member functions as function pointers

Sema treats pointers to static member functions as having function pointer
type, so treat treat them as function pointer values in the analyzer as well.
This prevents an assertion failure in SValBuilder::evalBinOp caused by code
that expects function pointers to be Locs (in contrast, PointerToMember values
are nonlocs).

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

Modified:
cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp
cfe/trunk/test/Analysis/pointer-to-member.cpp

Modified: cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp?rev=291581=291580=291581=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp Tue Jan 10 12:49:27 2017
@@ -218,6 +218,18 @@ SValBuilder::getDerivedRegionValueSymbol
 }
 
 DefinedSVal SValBuilder::getMemberPointer(const DeclaratorDecl* DD) {
+  assert(!DD || isa(DD) || isa(DD));
+
+  if (auto *MD = dyn_cast_or_null(DD)) {
+// Sema treats pointers to static member functions as have function pointer
+// type, so return a function pointer for the method.
+// We don't need to play a similar trick for static member fields
+// because these are represented as plain VarDecls and not FieldDecls
+// in the AST.
+if (MD->isStatic())
+  return getFunctionPointer(MD);
+  }
+
   return nonloc::PointerToMember(DD);
 }
 

Modified: cfe/trunk/test/Analysis/pointer-to-member.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/pointer-to-member.cpp?rev=291581=291580=291581=diff
==
--- cfe/trunk/test/Analysis/pointer-to-member.cpp (original)
+++ cfe/trunk/test/Analysis/pointer-to-member.cpp Tue Jan 10 12:49:27 2017
@@ -77,7 +77,8 @@ bool testDereferencing() {
 namespace testPointerToMemberFunction {
   struct A {
 virtual int foo() { return 1; }
-int bar() { return 2;  }
+int bar() { return 2; }
+int static staticMemberFunction(int p) { return p + 1; };
   };
 
   struct B : public A {
@@ -111,11 +112,19 @@ namespace testPointerToMemberFunction {
 
 clang_analyzer_eval((APtr->*AFP)() == 3); // expected-warning{{TRUE}}
   }
+
+  void testPointerToStaticMemberCall() {
+int (*fPtr)(int) = ::staticMemberFunction;
+if (fPtr != 0) { // no-crash
+  clang_analyzer_eval(fPtr(2) == 3); // expected-warning{{TRUE}}
+}
+  }
 } // end of testPointerToMemberFunction namespace
 
 namespace testPointerToMemberData {
   struct A {
 int i;
+static int j;
   };
 
   void testPointerToMemberData() {
@@ -126,6 +135,13 @@ namespace testPointerToMemberData {
 a.*AMdPointer += 1;
 
 clang_analyzer_eval(a.i == 43); // expected-warning{{TRUE}}
+
+int *ptrToStaticField = ::j;
+if (ptrToStaticField != 0) {
+  *ptrToStaticField = 7;
+  clang_analyzer_eval(*ptrToStaticField == 7); // expected-warning{{TRUE}}
+  clang_analyzer_eval(A::j == 7); // expected-warning{{TRUE}}
+}
   }
 } // end of testPointerToMemberData namespace
 


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


[PATCH] D28404: IRGen: Add optnone attribute on function during O0

2017-01-10 Thread Paul Robinson via Phabricator via cfe-commits
probinson added a comment.

In https://reviews.llvm.org/D28404#641078, @chandlerc wrote:

> For me, the arguments you're raising against -O0 and -flto don't hold up on 
> closer inspection:
>
> - O0 != optnone: correct. But this is only visible in LTO. And in LTO, Os != 
> optsize, and Oz != minsize. But we use optsize and minsize to communicate 
> between the compilation and the LTO step to the best of our ability the 
> intent of the programmer. It appears we can use optnone exactly the same way 
> here.


If the design decision is that relevant optimization controls are propagated 
into bitcode as function attributes, I grumble but concede it will do something 
similar to what was requested.

It does bother me that we keep finding things that LTO needs to know but which 
it does not know because it runs in a separate phase of the workflow.  I hope 
it is not a serious problem to ask "is there a more sensible way to fix this?"  
Maybe I'm not so good at expressing that so it comes out as a question rather 
than an objection, but that's basically what it is.

This design decision leaves -O1/-Og needing yet another attribute, when we get 
around to that, but I suppose Og would not have the 
interaction-with-other-attributes problems that optnone has.

> - optnone isn't *really* no optimizations: clearly this is true, but then 
> neither is -O0. We run the always inliner, a couple of other passes, and we 
> run several parts of the code generators optimizer. I understand why optnone 
> deficiencies (ie, too many optimizations) might be frustrating, but having 
> *more users* seems likely to make this *better*.

We have picked all the low-hanging fruit there, and probably some 
medium-hanging fruit.  Mehdi did have the misunderstanding that optnone == -O0 
and that I think was worth correcting.

> - There is no use case for -O0 + -flto:

The email thread has an exchange between Duncan and me, where I accept the use 
case.

> But all of this seems like an attempt to argue "you are wrong to have your 
> use case". I personally find that an unproductive line of discussion.

Not saying it was *wrong* just the description did not convey adequate 
justification.  Listing a few project types does not constitute a use case.  We 
did get to one, eventually, and it even involved differences in optimization 
levels.

> For example, you might ask: could we find some other way to solve the problem 
> you are trying to solve here?

There is another way to make use of the attribute, which I think will be more 
robust:

Have Sema pretend the pragma is in effect at all times, at -O0.  Then all the 
existing conflict detection/resolution logic Just Works, and there's no need to 
spend 4 lines of code hoping to replicate the correct conditions in 
CodeGenModule.

Because Sema does not have a handle on CodeGenOptions and therefore does not 
a-priori know the optimization level, probably the right thing to do is move 
the flag to LangOpts and set it under the correct conditions in 
CompilerInvocation.  It wouldn't be the first codegen-like option in LangOpts.


https://reviews.llvm.org/D28404



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


[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

2017-01-10 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In https://reviews.llvm.org/D28520#641536, @dim wrote:

> In https://reviews.llvm.org/D28520#641534, @aaron.ballman wrote:
>
> > Alternatively, these functions could be given the proper thread safety 
> > annotations, couldn't they?
>
>
> Aha, I was not aware of the existence of these attributes.  I'll take a look.


This may be of some help: http://clang.llvm.org/docs/ThreadSafetyAnalysis.html


https://reviews.llvm.org/D28520



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


[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

2017-01-10 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a reviewer: delesley.
aaron.ballman added a comment.

Alternatively, these functions could be given the proper thread safety 
annotations, couldn't they?


https://reviews.llvm.org/D28520



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


[libcxx] r291580 - Qualify some type names that I thought were fine, but some of the bots don't like.

2017-01-10 Thread Marshall Clow via cfe-commits
Author: marshall
Date: Tue Jan 10 12:40:01 2017
New Revision: 291580

URL: http://llvm.org/viewvc/llvm-project?rev=291580=rev
Log:
Qualify some type names that I thought were fine, but some of the bots don't 
like.

Modified:
libcxx/trunk/include/memory

Modified: libcxx/trunk/include/memory
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/memory?rev=291580=291579=291580=diff
==
--- libcxx/trunk/include/memory (original)
+++ libcxx/trunk/include/memory Tue Jan 10 12:40:01 2017
@@ -4713,7 +4713,7 @@ inline _LIBCPP_INLINE_VISIBILITY
 typename enable_if
 <
 !is_array<_Yp>::value &&
-is_convertible<_Yp*, element_type*>::value,
+is_convertible<_Yp*, typename shared_ptr<_Tp>::element_type*>::value,
 shared_ptr<_Tp>&
 >::type
 shared_ptr<_Tp>::operator=(auto_ptr<_Yp> __r)
@@ -4728,7 +4728,8 @@ inline _LIBCPP_INLINE_VISIBILITY
 typename enable_if
 <
 !is_array<_Yp>::value &&
-is_convertible::pointer, 
element_type*>::value,
+is_convertible::pointer, 
+   typename shared_ptr<_Tp>::element_type*>::value,
 shared_ptr<_Tp>&
 >::type
 shared_ptr<_Tp>::operator=(unique_ptr<_Yp, _Dp> __r)


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


[PATCH] D27651: [clang-format] Even with AlignConsecutiveDeclarations, PointerAlignment: Right should keep *s and to the right

2017-01-10 Thread Ken-Patrick Lehrmann via Phabricator via cfe-commits
KP updated this revision to Diff 83829.
KP added a comment.

Rename IsPointerOrReference to isPointerOrReference to comply with coding style


https://reviews.llvm.org/D27651

Files:
  lib/Format/WhitespaceManager.cpp
  unittests/Format/FormatTest.cpp

Index: unittests/Format/FormatTest.cpp
===
--- unittests/Format/FormatTest.cpp
+++ unittests/Format/FormatTest.cpp
@@ -8769,9 +8769,11 @@
   verifyFormat("int  oneTwoThree = {0}; // comment\n"
"unsigned oneTwo  = 0;   // comment",
Alignment);
+
+  // PAS_RIGHT
   EXPECT_EQ("void SomeFunction(int parameter = 0) {\n"
 "  int const i   = 1;\n"
-"  int * j   = 2;\n"
+"  int  *j   = 2;\n"
 "  int   big = 1;\n"
 "\n"
 "  unsigned oneTwoThree = 123;\n"
@@ -8792,6 +8794,141 @@
"int ll=1;\n"
"}",
Alignment));
+  EXPECT_EQ("void SomeFunction(int parameter = 0) {\n"
+"  int const i   = 1;\n"
+"  int **j   = 2, ***k;\n"
+"  int = i;\n"
+"  int &   = i + j;\n"
+"  int   big = 1;\n"
+"\n"
+"  unsigned oneTwoThree = 123;\n"
+"  int  oneTwo  = 12;\n"
+"  method();\n"
+"  float k  = 2;\n"
+"  int   ll = 1;\n"
+"}",
+format("void SomeFunction(int parameter= 0) {\n"
+   " int const  i= 1;\n"
+   "  int **j=2,***k;\n"
+   "int =i;\n"
+   "int &=i+j;\n"
+   " int big  =  1;\n"
+   "\n"
+   "unsigned oneTwoThree  =123;\n"
+   "int oneTwo = 12;\n"
+   "  method();\n"
+   "float k= 2;\n"
+   "int ll=1;\n"
+   "}",
+   Alignment));
+
+  // PAS_LEFT
+  FormatStyle AlignmentLeft = Alignment;
+  AlignmentLeft.PointerAlignment = FormatStyle::PAS_Left;
+  EXPECT_EQ("void SomeFunction(int parameter = 0) {\n"
+"  int const i   = 1;\n"
+"  int*  j   = 2;\n"
+"  int   big = 1;\n"
+"\n"
+"  unsigned oneTwoThree = 123;\n"
+"  int  oneTwo  = 12;\n"
+"  method();\n"
+"  float k  = 2;\n"
+"  int   ll = 1;\n"
+"}",
+format("void SomeFunction(int parameter= 0) {\n"
+   " int const  i= 1;\n"
+   "  int *j=2;\n"
+   " int big  =  1;\n"
+   "\n"
+   "unsigned oneTwoThree  =123;\n"
+   "int oneTwo = 12;\n"
+   "  method();\n"
+   "float k= 2;\n"
+   "int ll=1;\n"
+   "}",
+   AlignmentLeft));
+  EXPECT_EQ("void SomeFunction(int parameter = 0) {\n"
+"  int const i   = 1;\n"
+"  int** j   = 2;\n"
+"  int&  k   = i;\n"
+"  int&& l   = i + j;\n"
+"  int   big = 1;\n"
+"\n"
+"  unsigned oneTwoThree = 123;\n"
+"  int  oneTwo  = 12;\n"
+"  method();\n"
+"  float k  = 2;\n"
+"  int   ll = 1;\n"
+"}",
+format("void SomeFunction(int parameter= 0) {\n"
+   " int const  i= 1;\n"
+   "  int **j=2;\n"
+   "int =i;\n"
+   "int &=i+j;\n"
+   " int big  =  1;\n"
+   "\n"
+   "unsigned oneTwoThree  =123;\n"
+   "int oneTwo = 12;\n"
+   "  method();\n"
+   "float k= 2;\n"
+   "int ll=1;\n"
+   "}",
+   AlignmentLeft));
+  // PAS_MIDDLE
+  FormatStyle AlignmentMiddle = Alignment;
+  AlignmentMiddle.PointerAlignment = FormatStyle::PAS_Middle;
+  EXPECT_EQ("void SomeFunction(int parameter = 0) {\n"
+"  int const i   = 1;\n"
+"  int * j   = 2;\n"
+"  int   big = 1;\n"
+"\n"
+"  unsigned oneTwoThree = 123;\n"
+"  int  oneTwo  = 12;\n"
+"  method();\n"
+"  float k  = 2;\n"
+"  int   ll = 1;\n"
+"}",
+format("void SomeFunction(int parameter= 0) {\n"
+   " int const  i= 1;\n"
+   "  int *j=2;\n"
+   " int big  =  1;\n"
+   "\n"
+   "unsigned oneTwoThree  =123;\n"
+   "int oneTwo = 12;\n"
+   "  method();\n"
+   "float k= 2;\n"
+   "int ll=1;\n"

[PATCH] D20693: [clang-tidy] New checker to replace dynamic exception specifications

2017-01-10 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:68
+  this);
+}
+

hintonda wrote:
> aaron.ballman wrote:
> > Also missing: typedefs and using declarations.
> As far as I know, it isn't legal to add dynamic exception specifications to 
> typedefs and using declarations.
Hmm, I thought you could, at least in C++17, since it's now part of the 
function's type. However, I don't have a standard in front of me at the moment, 
so I'll have to double-check. It can always be added in a follow-up patch and 
need not block this one.

However, I do know the following is allowed in a typedef, and I don't think 
your existing ParmVarDecl matcher will catch it:
```
typedef void (*fp)(void (*f)(int) throw());
```



Comment at: docs/clang-tidy/checks/modernize-use-noexcept.rst:30
+By default this check will only replace ``throw()`` with ``noexcept``,
+and ``throw([,...])`` or ``throw(...)`` with blank except
+for operator delete and destructors, which are replaced with

hintonda wrote:
> aaron.ballman wrote:
> > I continue to object to removing the explicit exception specification 
> > entirely as the default behavior without strong justification. Further. 
> > there is no option to control this behavior.
> I tried to make sure it's only applied where appropriate.  If I missed a 
> case, please let me know, but I'm not sure an option "just in case" is right 
> solution.
> 
> However, I did try to structure the code in a way to make it easy to add an 
> option if that turns out the be the right thing to do.
The behavior as it's implemented now is not the behavior I would expect from 
such a check -- I think that `throw(int)` should get a FixIt to 
`noexcept(false)` rather than no `noexcept` clause whatsoever. Despite them 
being functionally equivalent in most cases, the explicit nature of the dynamic 
exception specification should be retained with an explicit noexcept exception 
specification, not discarded. If you really want `throw(int)` to be modified to 
have no explicit exception specification, I think that should be an option (off 
by default). If you would rather not make an option, then I think the explicit 
exception specification should remain.



Comment at: docs/clang-tidy/checks/modernize-use-noexcept.rst:38
+that don't support the ``noexcept`` keyword.  Users can define the
+macro to be ``noexcept`` or ``throw()`` depending on whether or not
+noexcept is supported.  Specifications that can throw, e.g.,

hintonda wrote:
> aaron.ballman wrote:
> > I'm not certain I understand the justification of calling out older 
> > compilers or suggesting use of `throw()`. The check will continually flag 
> > `throw()` and try to recommend `noexcept` in its place, won't it? At least, 
> > that's how I read the preceding paragraph.
> > 
> > I think the macro replacement is a reasonable feature, but I think the 
> > check only makes sense for C++11 or later, since C++98 users really have no 
> > alternatives to dynamic exception specifications.
> Libraries, e.g., libc++, that need to support both multiple versions of the 
> standard, use macros to switch between throw() and noexcept.
> 
> So this option was designed to be libc++ friendly.  If that's not 
> appropriate, I can remove it.
I think the *option* is fine; I think the wording is confusing. How about:
```
Alternatively, users can also use :option:`ReplacementString` to
specify a macro to use instead of ``noexcept``.  This is useful when
maintaining source code that uses custom exception specification marking
other than ``noexcept``.
```


https://reviews.llvm.org/D20693



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


[PATCH] D21279: Fix some issues in clang-format's AlignConsecutive modes

2017-01-10 Thread Erik Nyquist via Phabricator via cfe-commits
enyquist added a comment.

Well, your patch is here for me to try, and it looks like it's been accepted. 
So I guess I should just pull my finger out and try it :)
Thanks for your response-- I'll let you know if I come across any issues.


https://reviews.llvm.org/D21279



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


[PATCH] D28033: [analyzer] Treat pointers to static member functions as function pointers

2017-01-10 Thread Devin Coughlin via Phabricator via cfe-commits
dcoughlin updated this revision to Diff 83828.
dcoughlin added a comment.

Updating spacing, as @kromanenkov requested.


https://reviews.llvm.org/D28033

Files:
  lib/StaticAnalyzer/Core/SValBuilder.cpp
  test/Analysis/pointer-to-member.cpp


Index: test/Analysis/pointer-to-member.cpp
===
--- test/Analysis/pointer-to-member.cpp
+++ test/Analysis/pointer-to-member.cpp
@@ -77,7 +77,8 @@
 namespace testPointerToMemberFunction {
   struct A {
 virtual int foo() { return 1; }
-int bar() { return 2;  }
+int bar() { return 2; }
+int static staticMemberFunction(int p) { return p + 1; };
   };
 
   struct B : public A {
@@ -111,11 +112,19 @@
 
 clang_analyzer_eval((APtr->*AFP)() == 3); // expected-warning{{TRUE}}
   }
+
+  void testPointerToStaticMemberCall() {
+int (*fPtr)(int) = ::staticMemberFunction;
+if (fPtr != 0) { // no-crash
+  clang_analyzer_eval(fPtr(2) == 3); // expected-warning{{TRUE}}
+}
+  }
 } // end of testPointerToMemberFunction namespace
 
 namespace testPointerToMemberData {
   struct A {
 int i;
+static int j;
   };
 
   void testPointerToMemberData() {
@@ -126,6 +135,13 @@
 a.*AMdPointer += 1;
 
 clang_analyzer_eval(a.i == 43); // expected-warning{{TRUE}}
+
+int *ptrToStaticField = ::j;
+if (ptrToStaticField != 0) {
+  *ptrToStaticField = 7;
+  clang_analyzer_eval(*ptrToStaticField == 7); // expected-warning{{TRUE}}
+  clang_analyzer_eval(A::j == 7); // expected-warning{{TRUE}}
+}
   }
 } // end of testPointerToMemberData namespace
 
Index: lib/StaticAnalyzer/Core/SValBuilder.cpp
===
--- lib/StaticAnalyzer/Core/SValBuilder.cpp
+++ lib/StaticAnalyzer/Core/SValBuilder.cpp
@@ -218,6 +218,18 @@
 }
 
 DefinedSVal SValBuilder::getMemberPointer(const DeclaratorDecl* DD) {
+  assert(!DD || isa(DD) || isa(DD));
+
+  if (auto *MD = dyn_cast_or_null(DD)) {
+// Sema treats pointers to static member functions as have function pointer
+// type, so return a function pointer for the method.
+// We don't need to play a similar trick for static member fields
+// because these are represented as plain VarDecls and not FieldDecls
+// in the AST.
+if (MD->isStatic())
+  return getFunctionPointer(MD);
+  }
+
   return nonloc::PointerToMember(DD);
 }
 


Index: test/Analysis/pointer-to-member.cpp
===
--- test/Analysis/pointer-to-member.cpp
+++ test/Analysis/pointer-to-member.cpp
@@ -77,7 +77,8 @@
 namespace testPointerToMemberFunction {
   struct A {
 virtual int foo() { return 1; }
-int bar() { return 2;  }
+int bar() { return 2; }
+int static staticMemberFunction(int p) { return p + 1; };
   };
 
   struct B : public A {
@@ -111,11 +112,19 @@
 
 clang_analyzer_eval((APtr->*AFP)() == 3); // expected-warning{{TRUE}}
   }
+
+  void testPointerToStaticMemberCall() {
+int (*fPtr)(int) = ::staticMemberFunction;
+if (fPtr != 0) { // no-crash
+  clang_analyzer_eval(fPtr(2) == 3); // expected-warning{{TRUE}}
+}
+  }
 } // end of testPointerToMemberFunction namespace
 
 namespace testPointerToMemberData {
   struct A {
 int i;
+static int j;
   };
 
   void testPointerToMemberData() {
@@ -126,6 +135,13 @@
 a.*AMdPointer += 1;
 
 clang_analyzer_eval(a.i == 43); // expected-warning{{TRUE}}
+
+int *ptrToStaticField = ::j;
+if (ptrToStaticField != 0) {
+  *ptrToStaticField = 7;
+  clang_analyzer_eval(*ptrToStaticField == 7); // expected-warning{{TRUE}}
+  clang_analyzer_eval(A::j == 7); // expected-warning{{TRUE}}
+}
   }
 } // end of testPointerToMemberData namespace
 
Index: lib/StaticAnalyzer/Core/SValBuilder.cpp
===
--- lib/StaticAnalyzer/Core/SValBuilder.cpp
+++ lib/StaticAnalyzer/Core/SValBuilder.cpp
@@ -218,6 +218,18 @@
 }
 
 DefinedSVal SValBuilder::getMemberPointer(const DeclaratorDecl* DD) {
+  assert(!DD || isa(DD) || isa(DD));
+
+  if (auto *MD = dyn_cast_or_null(DD)) {
+// Sema treats pointers to static member functions as have function pointer
+// type, so return a function pointer for the method.
+// We don't need to play a similar trick for static member fields
+// because these are represented as plain VarDecls and not FieldDecls
+// in the AST.
+if (MD->isStatic())
+  return getFunctionPointer(MD);
+  }
+
   return nonloc::PointerToMember(DD);
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D28365: [Driver] Updated for Visual Studio 2017

2017-01-10 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added a comment.

In https://reviews.llvm.org/D28365#640868, @hamzasood wrote:

> Ha, good point. Does that include the environment stuff in Command too or 
> just the linker?


Yes, please make the Command environment changes as part of a separate patch 
with the linker environment changes.


https://reviews.llvm.org/D28365



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


[PATCH] D20693: [clang-tidy] New checker to replace dynamic exception specifications

2017-01-10 Thread don hinton via Phabricator via cfe-commits
hintonda updated this revision to Diff 83827.
hintonda marked an inline comment as done.
hintonda added a comment.

- Addressed comments.


https://reviews.llvm.org/D20693

Files:
  clang-tidy/modernize/CMakeLists.txt
  clang-tidy/modernize/ModernizeTidyModule.cpp
  clang-tidy/modernize/UseNoexceptCheck.cpp
  clang-tidy/modernize/UseNoexceptCheck.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/list.rst
  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,83 @@
+// RUN: %check_clang_tidy %s modernize-use-noexcept %t -- \
+// RUN:   -- -std=c++11
+
+class A {};
+class B {};
+
+void foo() throw();
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: found dynamic exception specification 'throw()' [modernize-use-noexcept]
+// CHECK-FIXES: void foo() noexcept;
+
+void bar() throw(...);
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: found dynamic exception specification 'throw(...)' [modernize-use-noexcept]
+// CHECK-FIXES: void bar() ;
+
+void k() throw(int(int));
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: found dynamic exception specification 'throw(int(int))' [modernize-use-noexcept]
+// CHECK-FIXES: void k() ;
+
+void foobar() throw(A, B)
+{}
+// CHECK-MESSAGES: :[[@LINE-2]]:15: warning: found dynamic exception specification 'throw(A, B)' [modernize-use-noexcept]
+// CHECK-FIXES: void foobar()
+
+void baz(int = (throw A(), 0)) throw(A, B) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:32: warning: found dynamic exception specification 'throw(A, B)' [modernize-use-noexcept]
+// CHECK-FIXES: void baz(int = (throw A(), 0)) {}
+
+void g(void (*fp)(void) throw());
+// CHECK-MESSAGES: :[[@LINE-1]]:25: warning: found dynamic exception specification 'throw()' [modernize-use-noexcept]
+// CHECK-FIXES: void g(void (*fp)(void) noexcept);
+
+void f(void (*fp)(void) throw(int)) throw(char);
+// CHECK-MESSAGES: :[[@LINE-1]]:25: warning: found dynamic exception specification 'throw(int)' [modernize-use-noexcept]
+// CHECK-MESSAGES: :[[@LINE-2]]:37: warning: found dynamic exception specification 'throw(char)' [modernize-use-noexcept]
+// CHECK-FIXES: void f(void (*fp)(void) ) ;
+
+#define THROW throw
+void h(void (*fp)(void) THROW(int)) THROW(char);
+// CHECK-MESSAGES: :[[@LINE-1]]:25: warning: found dynamic exception specification 'THROW(int)' [modernize-use-noexcept]
+// CHECK-MESSAGES: :[[@LINE-2]]:37: warning: found dynamic exception specification 'THROW(char)' [modernize-use-noexcept]
+// CHECK-FIXES: void h(void (*fp)(void) ) ;
+
+void j() throw(int(int) throw(void(void) throw(int)));
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: found dynamic exception specification 'throw(int(int) throw(void(void) throw(int)))' [modernize-use-noexcept]
+// CHECK-FIXES: void j() ;
+
+class Y {
+  Y() throw() = default;
+};
+// CHECK-MESSAGES: :[[@LINE-2]]:7: warning: found dynamic exception specification 'throw()' [modernize-use-noexcept]
+// CHECK-FIXES: Y() noexcept = default;
+
+struct Z {
+  void operator delete(void *ptr) throw();
+  void operator delete[](void *ptr) throw(int);
+  ~Z() throw(int) {}
+};
+// CHECK-MESSAGES: :[[@LINE-4]]:35: warning: found dynamic exception specification 'throw()' [modernize-use-noexcept]
+// CHECK-MESSAGES: :[[@LINE-4]]:37: warning: found dynamic exception specification 'throw(int)' [modernize-use-noexcept]
+// CHECK-MESSAGES: :[[@LINE-4]]:8: warning: found dynamic exception specification 'throw(int)' [modernize-use-noexcept]
+// CHECK-FIXES: void operator delete(void *ptr) noexcept;
+// CHECK-FIXES: void operator delete[](void *ptr) noexcept(false);
+// CHECK-FIXES: ~Z() noexcept(false) {}
+
+struct S {
+  void f() throw();
+};
+void f(void (S::*)() throw());
+// CHECK-MESSAGES: :[[@LINE-3]]:35: warning: found dynamic exception specification 'throw()' [modernize-use-noexcept]
+// CHECK-MESSAGES: :[[@LINE-2]]:37: warning: found dynamic exception specification 'throw()' [modernize-use-noexcept]
+// CHECK-FIXES: void f() noexcept;
+// CHECK-FIXES: void f(void (S::*)() noexcept);
+
+// Should not trigger a replacement.
+void titi() noexcept {}
+void toto() noexcept(true) {}
+
+// Should not trigger a replacement.
+void bad()
+#if !__has_feature(cxx_noexcept)
+throw()
+#endif
+  ;
Index: test/clang-tidy/modernize-use-noexcept-macro.cpp
===
--- /dev/null
+++ test/clang-tidy/modernize-use-noexcept-macro.cpp
@@ -0,0 +1,36 @@
+// RUN: %check_clang_tidy %s modernize-use-noexcept %t -- \
+// RUN:   -config="{CheckOptions: [{key: modernize-use-noexcept.ReplacementString, value: 'NOEXCEPT'}]}" \
+// RUN:   -- -std=c++11
+
+// Example definition of NOEXCEPT -- simplified test to see if noexcept is supported.
+#if (__has_feature(cxx_noexcept))
+#define NOEXCEPT noexcept

[PATCH] D28520: Disable -Wthread-safety-analysis for some functions in __thread_support

2017-01-10 Thread Dimitry Andric via Phabricator via cfe-commits
dim created this revision.
dim added reviewers: EricWF, mclow.lists.
dim added subscribers: cfe-commits, emaste, joerg.

Many thread-related libc++ test cases fail on FreeBSD, due to the following 
-Werror warnings:

  In file included from 
/share/dim/src/llvm/trunk/projects/libcxx/test/std/thread/thread.threads/thread.thread.this/sleep_until.pass.cpp:17:
  In file included from 
/share/dim/src/llvm/trunk/projects/libcxx/include/thread:97:
  In file included from 
/share/dim/src/llvm/trunk/projects/libcxx/include/__mutex_base:17:
  /share/dim/src/llvm/trunk/projects/libcxx/include/__threading_support:222:1: 
error: mutex '__m' is still held at the end of function 
[-Werror,-Wthread-safety-analysis]
  }
  ^
  /share/dim/src/llvm/trunk/projects/libcxx/include/__threading_support:221:10: 
note: mutex acquired here
return pthread_mutex_lock(__m);
   ^
  /share/dim/src/llvm/trunk/projects/libcxx/include/__threading_support:231:10: 
error: releasing mutex '__m' that was not held 
[-Werror,-Wthread-safety-analysis]
return pthread_mutex_unlock(__m);
   ^
  /share/dim/src/llvm/trunk/projects/libcxx/include/__threading_support:242:1: 
error: mutex '__m' is still held at the end of function 
[-Werror,-Wthread-safety-analysis]
  }
  ^
  /share/dim/src/llvm/trunk/projects/libcxx/include/__threading_support:241:10: 
note: mutex acquired here
return pthread_mutex_lock(__m);
   ^
  /share/dim/src/llvm/trunk/projects/libcxx/include/__threading_support:251:10: 
error: releasing mutex '__m' that was not held 
[-Werror,-Wthread-safety-analysis]
return pthread_mutex_unlock(__m);
   ^
  /share/dim/src/llvm/trunk/projects/libcxx/include/__threading_support:272:10: 
error: calling function 'pthread_cond_wait' requires holding mutex '__m' 
exclusively [-Werror,-Wthread-safety-analysis]
return pthread_cond_wait(__cv, __m);
   ^
  /share/dim/src/llvm/trunk/projects/libcxx/include/__threading_support:278:10: 
error: calling function 'pthread_cond_timedwait' requires holding mutex '__m' 
exclusively [-Werror,-Wthread-safety-analysis]
return pthread_cond_timedwait(__cv, __m, __ts);
   ^
  6 errors generated.

Obviously, these warnings are false, since the functions are exactly doing what 
they are supposed to do.

Therefore, add pragmas to ignored -Wthread-safety-analysis warnings.  These 
could also be set for the whole block of thread-related functions, but in this 
version I have added them per function.

I also considered doing this with macros, as Joerg suggested, but macros that 
expand to multi-line pragma statements are rather unwieldy, and don't make it 
much nicer, in my opinion.  Suggestions welcome, of course.


https://reviews.llvm.org/D28520

Files:
  include/__threading_support

Index: include/__threading_support
===
--- include/__threading_support
+++ include/__threading_support
@@ -216,40 +216,68 @@
   return 0;
 }
 
+#ifdef __clang__
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wthread-safety-analysis"
+#endif
 int __libcpp_recursive_mutex_lock(__libcpp_recursive_mutex_t *__m)
 {
   return pthread_mutex_lock(__m);
 }
+#ifdef __clang__
+#pragma clang diagnostic pop
+#endif
 
 int __libcpp_recursive_mutex_trylock(__libcpp_recursive_mutex_t *__m)
 {
   return pthread_mutex_trylock(__m);
 }
 
+#ifdef __clang__
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wthread-safety-analysis"
+#endif
 int __libcpp_recursive_mutex_unlock(__libcpp_mutex_t *__m)
 {
   return pthread_mutex_unlock(__m);
 }
+#ifdef __clang__
+#pragma clang diagnostic pop
+#endif
 
 int __libcpp_recursive_mutex_destroy(__libcpp_recursive_mutex_t *__m)
 {
   return pthread_mutex_destroy(__m);
 }
 
+#ifdef __clang__
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wthread-safety-analysis"
+#endif
 int __libcpp_mutex_lock(__libcpp_mutex_t *__m)
 {
   return pthread_mutex_lock(__m);
 }
+#ifdef __clang__
+#pragma clang diagnostic pop
+#endif
 
 int __libcpp_mutex_trylock(__libcpp_mutex_t *__m)
 {
   return pthread_mutex_trylock(__m);
 }
 
+#ifdef __clang__
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wthread-safety-analysis"
+#endif
 int __libcpp_mutex_unlock(__libcpp_mutex_t *__m)
 {
   return pthread_mutex_unlock(__m);
 }
+#ifdef __clang__
+#pragma clang diagnostic pop
+#endif
 
 int __libcpp_mutex_destroy(__libcpp_mutex_t *__m)
 {
@@ -267,16 +295,30 @@
   return pthread_cond_broadcast(__cv);
 }
 
+#ifdef __clang__
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wthread-safety-analysis"
+#endif
 int __libcpp_condvar_wait(__libcpp_condvar_t *__cv, __libcpp_mutex_t *__m)
 {
   return pthread_cond_wait(__cv, __m);
 }
+#ifdef __clang__
+#pragma clang diagnostic pop
+#endif
 
+#ifdef __clang__
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wthread-safety-analysis"
+#endif
 int 

[PATCH] D28080: [Docs][OpenCL] Added OpenCL feature description to user manual.

2017-01-10 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia marked 4 inline comments as done.
Anastasia added a comment.

Ping! Any more comments here? It would be nice to commit this before the 4.0 
rel branch is taken (on Jan 12).


https://reviews.llvm.org/D28080



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


[PATCH] D28080: [Docs][OpenCL] Added OpenCL feature description to user manual.

2017-01-10 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia updated this revision to Diff 83824.
Anastasia added a comment.

Updated with comments from Mats!


https://reviews.llvm.org/D28080

Files:
  docs/UsersManual.rst
  www/index.html

Index: www/index.html
===
--- www/index.html
+++ www/index.html
@@ -15,10 +15,10 @@
   clang: a C language family frontend for LLVM
   
   
-  The goal of the Clang project is to create a new C, C++, Objective C and
-  Objective C++ front-end for the http://www.llvm.org/;>LLVM
-  compiler.  You can get and build the source
-  today.
+  The goal of the Clang project is to create a new C based language
+  front-end: C, C++, Objective C/C++, OpenCL and others for the
+  http://www.llvm.org/;>LLVM compiler.  You can
+  get and build the source  today.
   
   
   Features and Goals
Index: docs/UsersManual.rst
===
--- docs/UsersManual.rst
+++ docs/UsersManual.rst
@@ -41,6 +41,7 @@
variants depending on base language.
 -  :ref:`C++ Language `
 -  :ref:`Objective C++ Language `
+-  :ref:`OpenCL Language `: v1.0, v1.1, v1.2, v2.0.
 
 In addition to these base languages and their dialects, Clang supports a
 broad variety of language extensions, which are documented in the
@@ -1973,6 +1974,348 @@
  is provided or target does not support TLS, code generation for threadprivate
  variables relies on OpenMP runtime library.
 
+.. _opencl:
+
+OpenCL Features
+===
+
+Clang can be used to compile OpenCL kernels for execution on a device
+(e.g. GPU). It is possible to compile the kernel into a binary (e.g. for AMD or
+Nvidia targets) that can be uploaded to run directly on a device (e.g. using
+`clCreateProgramWithBinary
+`_) or
+into generic bitcode files loadable into other toolchains.
+
+Compiling to a binary using the default target from the installation can be done
+as follows:
+
+   .. code-block:: console
+
+ $ echo "kernel void k(){}" > test.cl
+ $ clang test.cl
+
+Compiling for a specific target can be done by specifying the triple corresponding
+to the target, for example:
+
+   .. code-block:: console
+
+ $ clang -target nvptx64-unknown-unknown test.cl
+ $ clang -target amdgcn-unknown-amdhsa test.cl
+
+Compiling to bitcode can be done as follows:
+
+   .. code-block:: console
+
+ $ clang test.cl -c -emit-llvm
+
+This will produce a generic test.bc file that can be used in vendor toolchains
+to perform machine code generation.
+
+Clang currently supports OpenCL standards up to v2.0.
+
+OpenCL Specific Options
+---
+
+Most of the OpenCL build options from `the specification v2.0 section 5.8.4
+`_ are available.
+
+Examples:
+
+   .. code-block:: console
+
+ $ clang -cl-std=CL2.0 -cl-single-precision-constant test.cl
+
+Some extra options are available to support special OpenCL features.
+
+.. option:: -finclude-default-header
+
+Loads standard includes during compilations. By default OpenCL headers are not
+loaded and therefore standard library includes are not available. To load them
+automatically a flag has been added to the frontend (see also OpenCL Header
+section):
+
+   .. code-block:: console
+
+ $ clang -Xclang -finclude-default-header test.cl
+
+Alternatively ``-include`` or ``-I`` followed by the path to the header location
+can be given manually.
+
+   .. code-block:: console
+
+ $ clang -I/lib/Headers/opencl-c.h test.cl
+
+In this case the kernel code should contain ``#include `` just as a
+regular C include.
+
+.. option:: -cl-ext
+
+Disables standard target extensions. All OpenCL targets provide a list
+of extensions that they support. Clang allows to amend this using the ``-cl-ext``
+flag with a comma-separated list of extensions prefixed with ``'+'`` or ``'-'``.
+The syntax: ``-cl-ext=<(['-'|'+'][,])+>``,  where extensions
+can be either one of `the OpenCL specification extensions
+`_
+or any known vendor extension. Alternatively, ``'all'`` can be used to enable or disable
+all known extensions.
+Example disabling double support for the 64-bit SPIR target:
+
+   .. code-block:: console
+
+ $ clang -cc1 -triple spir64-unknown-unknown -cl-ext=-cl_khr_fp64 test.cl
+
+Enabling all extensions except double support in R600 AMD GPU can be done using:
+
+   .. code-block:: console
+
+ $ clang -cc1 -triple r600-unknown-unknown -cl-ext=-all,+cl_khr_fp16 test.cl
+
+.. _opencl_fake_address_space_map:
+
+.. option:: -ffake-address-space-map
+
+Overrides the target address space map with a fake map.
+This allows adding address spaces for architectures that do not provide default
+memory segment support. Passing ``-ffake-address-space-map`` will add/override
+address spaces of the target compiled for with the following 

[PATCH] D20693: [clang-tidy] New checker to replace dynamic exception specifications

2017-01-10 Thread don hinton via Phabricator via cfe-commits
hintonda marked 7 inline comments as done.
hintonda added inline comments.



Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:64
+  Finder->addMatcher(
+  parmVarDecl(hasType(pointerType(pointee(parenType(innerType(
+  functionProtoType(hasDynamicExceptionSpec(

aaron.ballman wrote:
> Will this catch pointers to member functions as well?
> ```
> struct S {
>   void f() throw();
> };
> 
> void f(void (S::*)() throw()) {
> 
> }
> ```
Added your test, but will need to change matcher to catch it.



Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:68
+  this);
+}
+

aaron.ballman wrote:
> Also missing: typedefs and using declarations.
As far as I know, it isn't legal to add dynamic exception specifications to 
typedefs and using declarations.



Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:100
+  StringRef ReplacementStr =
+  IsNoThrow ? NoexceptMacro.empty() ? "noexcept" : NoexceptMacro
+: DtorOrOperatorDel ? "noexcept(false)" : "";

malcolm.parsons wrote:
> alexfh wrote:
> > Did you consider auto-detection approach like in 
> > `getFallthroughAttrSpelling` in 
> > tools/clang/lib/Sema/AnalysisBasedWarnings.cpp?
> cpp11-migrate used to do this for -add-override - rL183001.
> clang-tidy's modernize-use-override check doesn't even have an option.
NoexceptMacro is a user option.  I'm just tested whether or not the user 
provided anything.  Perhaps I should pick a better name.  Would 
NoexceptMacroOption be better?

Did I misunderstand your comment?



Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:105
+  if (IsNoThrow || NoexceptMacro.empty())
+FixIt = FixItHint::CreateReplacement(CharSourceRange(Range, true),
+ ReplacementStr);

alexfh wrote:
> I suspect this won't work when the range is not contiguous, e.g. starts in a 
> macro definition and ends outside of it:
> 
>   #define T throw
>   void f() T(a, b) {}
> 
> Can you try this test (or construct something similar that will actually 
> break this code)? In case it doesn't work, `Lexer::makeFileCharRange` is the 
> standard way to get a contiguous file range corresponding to a  source range 
> (if possible).
As you suspected, I wasn't handling this case correctly.  I've made the change 
you suggested and will check in shortly.



Comment at: docs/clang-tidy/checks/modernize-use-noexcept.rst:30
+By default this check will only replace ``throw()`` with ``noexcept``,
+and ``throw([,...])`` or ``throw(...)`` with blank except
+for operator delete and destructors, which are replaced with

aaron.ballman wrote:
> I continue to object to removing the explicit exception specification 
> entirely as the default behavior without strong justification. Further. there 
> is no option to control this behavior.
I tried to make sure it's only applied where appropriate.  If I missed a case, 
please let me know, but I'm not sure an option "just in case" is right solution.

However, I did try to structure the code in a way to make it easy to add an 
option if that turns out the be the right thing to do.



Comment at: docs/clang-tidy/checks/modernize-use-noexcept.rst:38
+that don't support the ``noexcept`` keyword.  Users can define the
+macro to be ``noexcept`` or ``throw()`` depending on whether or not
+noexcept is supported.  Specifications that can throw, e.g.,

aaron.ballman wrote:
> I'm not certain I understand the justification of calling out older compilers 
> or suggesting use of `throw()`. The check will continually flag `throw()` and 
> try to recommend `noexcept` in its place, won't it? At least, that's how I 
> read the preceding paragraph.
> 
> I think the macro replacement is a reasonable feature, but I think the check 
> only makes sense for C++11 or later, since C++98 users really have no 
> alternatives to dynamic exception specifications.
Libraries, e.g., libc++, that need to support both multiple versions of the 
standard, use macros to switch between throw() and noexcept.

So this option was designed to be libc++ friendly.  If that's not appropriate, 
I can remove it.


https://reviews.llvm.org/D20693



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


[PATCH] D28252: [OpenMP] Sema and parsing for 'target teams distribute simd' pragma

2017-01-10 Thread Kelvin Li via Phabricator via cfe-commits
kkwli0 marked an inline comment as done.
kkwli0 added inline comments.



Comment at: lib/Sema/SemaOpenMP.cpp:6444
+
+  CapturedStmt *CS = cast(AStmt);
+  // 1.2.2 OpenMP Language Terminology

ABataev wrote:
> auto *
Will do.


https://reviews.llvm.org/D28252



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


[PATCH] D25213: Fix PR28181: Prevent operator overloading related assertion failure crash that happens in C only

2017-01-10 Thread Alex Lorenz via Phabricator via cfe-commits
arphaman updated this revision to Diff 83822.
arphaman added a comment.

Ping


Repository:
  rL LLVM

https://reviews.llvm.org/D25213

Files:
  lib/Sema/SemaExpr.cpp
  test/Sema/PR28181.c


Index: test/Sema/PR28181.c
===
--- /dev/null
+++ test/Sema/PR28181.c
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+struct spinlock_t {
+  int lock;
+} audit_skb_queue;
+
+void fn1() {
+  audit_skb_queue = (lock); // expected-error {{use of undeclared identifier 
'lock'; did you mean 'long'?}}
+}   // expected-error@-1 {{assigning to 'struct 
spinlock_t' from incompatible type ''}}
+
+void fn2() {
+  audit_skb_queue + (lock); // expected-error {{use of undeclared identifier 
'lock'; did you mean 'long'?}}
+}   // expected-error@-1 {{reference to overloaded 
function could not be resolved; did you mean to call it?}}
Index: lib/Sema/SemaExpr.cpp
===
--- lib/Sema/SemaExpr.cpp
+++ lib/Sema/SemaExpr.cpp
@@ -11496,7 +11496,7 @@
   return checkPseudoObjectAssignment(S, OpLoc, Opc, LHSExpr, RHSExpr);
 
 // Don't resolve overloads if the other type is overloadable.
-if (pty->getKind() == BuiltinType::Overload) {
+if (getLangOpts().CPlusPlus && pty->getKind() == BuiltinType::Overload) {
   // We can't actually test that if we still have a placeholder,
   // though.  Fortunately, none of the exceptions we see in that
   // code below are valid when the LHS is an overload set.  Note
@@ -11521,17 +11521,18 @@
 // An overload in the RHS can potentially be resolved by the type
 // being assigned to.
 if (Opc == BO_Assign && pty->getKind() == BuiltinType::Overload) {
-  if (LHSExpr->isTypeDependent() || RHSExpr->isTypeDependent())
+  if (getLangOpts().CPlusPlus &&
+  (LHSExpr->isTypeDependent() || RHSExpr->isTypeDependent()))
 return BuildOverloadedBinOp(*this, S, OpLoc, Opc, LHSExpr, RHSExpr);
 
-  if (LHSExpr->getType()->isOverloadableType())
+  if (getLangOpts().CPlusPlus && LHSExpr->getType()->isOverloadableType())
 return BuildOverloadedBinOp(*this, S, OpLoc, Opc, LHSExpr, RHSExpr);
 
   return CreateBuiltinBinOp(OpLoc, Opc, LHSExpr, RHSExpr);
 }
 
 // Don't resolve overloads if the other type is overloadable.
-if (pty->getKind() == BuiltinType::Overload &&
+if (getLangOpts().CPlusPlus && pty->getKind() == BuiltinType::Overload &&
 LHSExpr->getType()->isOverloadableType())
   return BuildOverloadedBinOp(*this, S, OpLoc, Opc, LHSExpr, RHSExpr);
 


Index: test/Sema/PR28181.c
===
--- /dev/null
+++ test/Sema/PR28181.c
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+struct spinlock_t {
+  int lock;
+} audit_skb_queue;
+
+void fn1() {
+  audit_skb_queue = (lock); // expected-error {{use of undeclared identifier 'lock'; did you mean 'long'?}}
+}   // expected-error@-1 {{assigning to 'struct spinlock_t' from incompatible type ''}}
+
+void fn2() {
+  audit_skb_queue + (lock); // expected-error {{use of undeclared identifier 'lock'; did you mean 'long'?}}
+}   // expected-error@-1 {{reference to overloaded function could not be resolved; did you mean to call it?}}
Index: lib/Sema/SemaExpr.cpp
===
--- lib/Sema/SemaExpr.cpp
+++ lib/Sema/SemaExpr.cpp
@@ -11496,7 +11496,7 @@
   return checkPseudoObjectAssignment(S, OpLoc, Opc, LHSExpr, RHSExpr);
 
 // Don't resolve overloads if the other type is overloadable.
-if (pty->getKind() == BuiltinType::Overload) {
+if (getLangOpts().CPlusPlus && pty->getKind() == BuiltinType::Overload) {
   // We can't actually test that if we still have a placeholder,
   // though.  Fortunately, none of the exceptions we see in that
   // code below are valid when the LHS is an overload set.  Note
@@ -11521,17 +11521,18 @@
 // An overload in the RHS can potentially be resolved by the type
 // being assigned to.
 if (Opc == BO_Assign && pty->getKind() == BuiltinType::Overload) {
-  if (LHSExpr->isTypeDependent() || RHSExpr->isTypeDependent())
+  if (getLangOpts().CPlusPlus &&
+  (LHSExpr->isTypeDependent() || RHSExpr->isTypeDependent()))
 return BuildOverloadedBinOp(*this, S, OpLoc, Opc, LHSExpr, RHSExpr);
 
-  if (LHSExpr->getType()->isOverloadableType())
+  if (getLangOpts().CPlusPlus && LHSExpr->getType()->isOverloadableType())
 return BuildOverloadedBinOp(*this, S, OpLoc, Opc, LHSExpr, RHSExpr);
 
   return CreateBuiltinBinOp(OpLoc, Opc, LHSExpr, RHSExpr);
 }
 
 // Don't resolve overloads if the other type is overloadable.
-if (pty->getKind() == BuiltinType::Overload &&
+if (getLangOpts().CPlusPlus && pty->getKind() == 

[PATCH] D27068: Improve string::find

2017-01-10 Thread Aditya Kumar via Phabricator via cfe-commits
hiraditya added a comment.

Just for the record, I ported the patch to gcc/libstdc++ as well: PR66414 
optimize std::string::find

https://github.com/gcc-mirror/gcc/commit/fc7ebc4b8d9ad7e2891b7f72152e8a2b7543cd65


Repository:
  rL LLVM

https://reviews.llvm.org/D27068



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


[PATCH] D28231: -Wunreachable-code: Avoid multiple diagnostics that are triggered by the same source range and fix the unary operator fixit source range

2017-01-10 Thread Alex Lorenz via Phabricator via cfe-commits
arphaman added inline comments.



Comment at: lib/Analysis/ReachableCode.cpp:229
+  if (SilenceableCondValNotSet && SilenceableCondVal->getBegin().isValid())
+*SilenceableCondVal = UO->getSourceRange();
+  return UO->getOpcode() == UO_LNot && IsSubExprConfigValue;

ahatanak wrote:
> Thanks, that fixed the incorrect fixit. The patch looks good to me, but there 
> are still cases in which the suggestions clang makes are not accurate. 
> Perhaps you can leave a FIXME somewhere so that we don't forget to fix it 
> later?
> 
> For example, if we change the condition in the test case to this,
> 
> ```
> if (!(s->p && 0))
> ```
> 
> , clang suggests enclosing the entire expression with a parenthesis (caret 
> points to "!"), but the warning will not go away unless the parenthesis is 
> around "0".
> 
> The second example is in function unaryOpFixit in warn-unreachable.c. clang 
> suggests enclosing "-1" with a parenthesis, but it still warns after putting 
> the parenthesis around "-1" or "1".
Thanks for pointing out these issues, I've decided to fix them in this patch. 
Since only the '!' operator can wrap a silenced expression, the updated patch 
ensures that fixits for unary operators can only be used with '!' (this fixes 
your second example). I fixed the first example by ensuring that the unary 
operator source range can be used for fixit only if the previous fixit source 
range comes from its direct child.


Repository:
  rL LLVM

https://reviews.llvm.org/D28231



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


[PATCH] D28505: CGDecl: Skip static variable initializers in unreachable code

2017-01-10 Thread Phabricator via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL291576: CGDecl: Skip static variable initializers in 
unreachable code (authored by matze).

Changed prior to commit:
  https://reviews.llvm.org/D28505?vs=83754=83820#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D28505

Files:
  cfe/trunk/lib/CodeGen/CGDecl.cpp
  cfe/trunk/test/CodeGenCXX/pr31054.cpp


Index: cfe/trunk/lib/CodeGen/CGDecl.cpp
===
--- cfe/trunk/lib/CodeGen/CGDecl.cpp
+++ cfe/trunk/lib/CodeGen/CGDecl.cpp
@@ -311,7 +311,7 @@
   if (!Init) {
 if (!getLangOpts().CPlusPlus)
   CGM.ErrorUnsupported(D.getInit(), "constant l-value expression");
-else if (Builder.GetInsertBlock()) {
+else if (HaveInsertPoint()) {
   // Since we have a static initializer, this global variable can't
   // be constant.
   GV->setConstant(false);
@@ -352,7 +352,7 @@
   GV->setConstant(CGM.isTypeConstant(D.getType(), true));
   GV->setInitializer(Init);
 
-  if (hasNontrivialDestruction(D.getType())) {
+  if (hasNontrivialDestruction(D.getType()) && HaveInsertPoint()) {
 // We have a constant initializer, but a nontrivial destructor. We still
 // need to perform a guarded "initialization" in order to register the
 // destructor.
Index: cfe/trunk/test/CodeGenCXX/pr31054.cpp
===
--- cfe/trunk/test/CodeGenCXX/pr31054.cpp
+++ cfe/trunk/test/CodeGenCXX/pr31054.cpp
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm -o - %s | 
FileCheck %s
+
+struct A { ~A(); };
+void func() {
+  return;
+  static A k;
+}
+
+// Test that we did not crash, by checking whether function was created.
+// CHECK-LABEL: define void @_Z4funcv() #0 {
+// CHECK: ret void
+// CHECK: }


Index: cfe/trunk/lib/CodeGen/CGDecl.cpp
===
--- cfe/trunk/lib/CodeGen/CGDecl.cpp
+++ cfe/trunk/lib/CodeGen/CGDecl.cpp
@@ -311,7 +311,7 @@
   if (!Init) {
 if (!getLangOpts().CPlusPlus)
   CGM.ErrorUnsupported(D.getInit(), "constant l-value expression");
-else if (Builder.GetInsertBlock()) {
+else if (HaveInsertPoint()) {
   // Since we have a static initializer, this global variable can't
   // be constant.
   GV->setConstant(false);
@@ -352,7 +352,7 @@
   GV->setConstant(CGM.isTypeConstant(D.getType(), true));
   GV->setInitializer(Init);
 
-  if (hasNontrivialDestruction(D.getType())) {
+  if (hasNontrivialDestruction(D.getType()) && HaveInsertPoint()) {
 // We have a constant initializer, but a nontrivial destructor. We still
 // need to perform a guarded "initialization" in order to register the
 // destructor.
Index: cfe/trunk/test/CodeGenCXX/pr31054.cpp
===
--- cfe/trunk/test/CodeGenCXX/pr31054.cpp
+++ cfe/trunk/test/CodeGenCXX/pr31054.cpp
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm -o - %s | FileCheck %s
+
+struct A { ~A(); };
+void func() {
+  return;
+  static A k;
+}
+
+// Test that we did not crash, by checking whether function was created.
+// CHECK-LABEL: define void @_Z4funcv() #0 {
+// CHECK: ret void
+// CHECK: }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r291576 - CGDecl: Skip static variable initializers in unreachable code

2017-01-10 Thread Matthias Braun via cfe-commits
Author: matze
Date: Tue Jan 10 11:43:01 2017
New Revision: 291576

URL: http://llvm.org/viewvc/llvm-project?rev=291576=rev
Log:
CGDecl: Skip static variable initializers in unreachable code

This fixes http://llvm.org/PR31054

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

Added:
cfe/trunk/test/CodeGenCXX/pr31054.cpp
Modified:
cfe/trunk/lib/CodeGen/CGDecl.cpp

Modified: cfe/trunk/lib/CodeGen/CGDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDecl.cpp?rev=291576=291575=291576=diff
==
--- cfe/trunk/lib/CodeGen/CGDecl.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDecl.cpp Tue Jan 10 11:43:01 2017
@@ -311,7 +311,7 @@ CodeGenFunction::AddInitializerToStaticV
   if (!Init) {
 if (!getLangOpts().CPlusPlus)
   CGM.ErrorUnsupported(D.getInit(), "constant l-value expression");
-else if (Builder.GetInsertBlock()) {
+else if (HaveInsertPoint()) {
   // Since we have a static initializer, this global variable can't
   // be constant.
   GV->setConstant(false);
@@ -352,7 +352,7 @@ CodeGenFunction::AddInitializerToStaticV
   GV->setConstant(CGM.isTypeConstant(D.getType(), true));
   GV->setInitializer(Init);
 
-  if (hasNontrivialDestruction(D.getType())) {
+  if (hasNontrivialDestruction(D.getType()) && HaveInsertPoint()) {
 // We have a constant initializer, but a nontrivial destructor. We still
 // need to perform a guarded "initialization" in order to register the
 // destructor.

Added: cfe/trunk/test/CodeGenCXX/pr31054.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/pr31054.cpp?rev=291576=auto
==
--- cfe/trunk/test/CodeGenCXX/pr31054.cpp (added)
+++ cfe/trunk/test/CodeGenCXX/pr31054.cpp Tue Jan 10 11:43:01 2017
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm -o - %s | 
FileCheck %s
+
+struct A { ~A(); };
+void func() {
+  return;
+  static A k;
+}
+
+// Test that we did not crash, by checking whether function was created.
+// CHECK-LABEL: define void @_Z4funcv() #0 {
+// CHECK: ret void
+// CHECK: }


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


[PATCH] D28231: -Wunreachable-code: Avoid multiple diagnostics that are triggered by the same source range and fix the unary operator fixit source range

2017-01-10 Thread Alex Lorenz via Phabricator via cfe-commits
arphaman updated this revision to Diff 83819.
arphaman added a comment.

Fix more issues with FIXIT for unary operators.


Repository:
  rL LLVM

https://reviews.llvm.org/D28231

Files:
  lib/Analysis/ReachableCode.cpp
  lib/Sema/AnalysisBasedWarnings.cpp
  test/Sema/warn-unreachable.c

Index: test/Sema/warn-unreachable.c
===
--- test/Sema/warn-unreachable.c
+++ test/Sema/warn-unreachable.c
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 %s -fsyntax-only -verify -fblocks -Wunreachable-code-aggressive -Wno-unused-value -Wno-covered-switch-default -I %S/Inputs
+// RUN: %clang_cc1 -fsyntax-only -fblocks -Wunreachable-code-aggressive -Wno-unused-value -Wno-covered-switch-default -fdiagnostics-parseable-fixits -I %S/Inputs %s 2>&1 | FileCheck %s
 
 #include "warn-unreachable.h"
 
@@ -396,3 +397,57 @@
   else
 calledFun();
 }
+
+// rdar://24570531
+
+struct StructWithPointer {
+  void *p;
+};
+
+void emitJustOneWarningForOr(struct StructWithPointer *s) {
+  if (1 || !s->p) // expected-note {{silence by adding parentheses to mark code as explicitly dead}}
+return; // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:7-[[@LINE-1]]:7}:"/* DISABLES CODE */ ("
+// CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:8-[[@LINE-2]]:8}:")"
+  emitJustOneWarningForOr(s); // expected-warning {{code will never be executed}}
+}
+
+void emitJustOneWarningForOrSilenced(struct StructWithPointer *s) {
+  if ((1) || !s->p)
+return;
+
+  emitJustOneWarningForOrSilenced(s); // no warning
+}
+
+void emitJustOneWarningForOr2(struct StructWithPointer *s) {
+  if (1 || !s->p) // expected-warning {{code will never be executed}}
+return; // expected-note@-1 {{silence by adding parentheses to mark code as explicitly dead}}
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:7-[[@LINE-2]]:7}:"/* DISABLES CODE */ ("
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:8-[[@LINE-3]]:8}:")"
+}
+
+void wrapOneInFixit(struct StructWithPointer *s) {
+  if (!s->p || 1) // expected-note {{silence by adding parentheses to mark code as explicitly dead}}
+return; // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:16-[[@LINE-1]]:16}:"/* DISABLES CODE */ ("
+// CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:17-[[@LINE-2]]:17}:")"
+  wrapOneInFixit(s); // expected-warning {{code will never be executed}}
+}
+
+void unaryOpNoFixit() {
+  if (- 1)
+return; // CHECK-NOT: fix-it:"{{.*}}":{[[@LINE-1]]
+  unaryOpNoFixit(); // expected-warning {{code will never be executed}}
+}
+
+void unaryOpStrictFixit(struct StructWithPointer *s) {
+  if (!(s->p && 0)) // expected-note {{silence by adding parentheses to mark code as explicitly dead}}
+return; // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:17-[[@LINE-1]]:17}:"/* DISABLES CODE */ ("
+// CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:18-[[@LINE-2]]:18}:")"
+  unaryOpStrictFixit(s); // expected-warning {{code will never be executed}}
+}
+
+void unaryOpFixitCastSubExpr(int x) {
+  if (! (int)0) // expected-note {{silence by adding parentheses to mark code as explicitly dead}}
+return; // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:7-[[@LINE-1]]:7}:"/* DISABLES CODE */ ("
+// CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:15-[[@LINE-2]]:15}:")"
+  unaryOpFixitCastSubExpr(x); // expected-warning {{code will never be executed}}
+}
Index: lib/Sema/AnalysisBasedWarnings.cpp
===
--- lib/Sema/AnalysisBasedWarnings.cpp
+++ lib/Sema/AnalysisBasedWarnings.cpp
@@ -56,14 +56,24 @@
 namespace {
   class UnreachableCodeHandler : public reachable_code::Callback {
 Sema 
+SourceRange PreviousSilenceableCondVal;
+
   public:
 UnreachableCodeHandler(Sema ) : S(s) {}
 
 void HandleUnreachable(reachable_code::UnreachableKind UK,
SourceLocation L,
SourceRange SilenceableCondVal,
SourceRange R1,
SourceRange R2) override {
+  // Avoid reporting multiple unreachable code diagnostics that are
+  // triggered by the same conditional value.
+  if (PreviousSilenceableCondVal.isValid() &&
+  SilenceableCondVal.isValid() &&
+  PreviousSilenceableCondVal == SilenceableCondVal)
+return;
+  PreviousSilenceableCondVal = SilenceableCondVal;
+
   unsigned diag = diag::warn_unreachable;
   switch (UK) {
 case reachable_code::UK_Break:
Index: lib/Analysis/ReachableCode.cpp
===
--- lib/Analysis/ReachableCode.cpp
+++ lib/Analysis/ReachableCode.cpp
@@ -218,11 +218,21 @@
 }
 case Stmt::UnaryOperatorClass: {
   const UnaryOperator *UO = cast(S);
-  if (SilenceableCondVal) 
-*SilenceableCondVal = UO->getSourceRange();  
-  return UO->getOpcode() == UO_LNot &&
- isConfigurationValue(UO->getSubExpr(), PP, SilenceableCondVal,
-  IncludeIntegers, 

[PATCH] D28400: [AArch64] Use generic bitreverse intrinsic, rather than AArch64 specific.

2017-01-10 Thread Chad Rosier via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL291574: [AArch64] Use generic bitreverse intrinsic, rather 
than AArch64 specific. (authored by mcrosier).

Changed prior to commit:
  https://reviews.llvm.org/D28400?vs=83367=83817#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D28400

Files:
  cfe/trunk/lib/CodeGen/CGBuiltin.cpp
  cfe/trunk/test/CodeGen/arm_acle.c
  cfe/trunk/test/CodeGen/builtins-arm64.c


Index: cfe/trunk/test/CodeGen/arm_acle.c
===
--- cfe/trunk/test/CodeGen/arm_acle.c
+++ cfe/trunk/test/CodeGen/arm_acle.c
@@ -245,22 +245,22 @@
 
 // ARM-LABEL: test_rbit
 // AArch32: call i32 @llvm.arm.rbit
-// AArch64: call i32 @llvm.aarch64.rbit.i32
+// AArch64: call i32 @llvm.bitreverse.i32
 uint32_t test_rbit(uint32_t t) {
   return __rbit(t);
 }
 
 // ARM-LABEL: test_rbitl
 // AArch32: call i32 @llvm.arm.rbit
-// AArch64: call i64 @llvm.aarch64.rbit.i64
+// AArch64: call i64 @llvm.bitreverse.i64
 long test_rbitl(long t) {
   return __rbitl(t);
 }
 
 // ARM-LABEL: test_rbitll
 // AArch32: call i32 @llvm.arm.rbit
 // AArch32: call i32 @llvm.arm.rbit
-// AArch64: call i64 @llvm.aarch64.rbit.i64
+// AArch64: call i64 @llvm.bitreverse.i64
 uint64_t test_rbitll(uint64_t t) {
   return __rbitll(t);
 }
Index: cfe/trunk/test/CodeGen/builtins-arm64.c
===
--- cfe/trunk/test/CodeGen/builtins-arm64.c
+++ cfe/trunk/test/CodeGen/builtins-arm64.c
@@ -10,12 +10,12 @@
 // CHECK: call {{.*}} @llvm.thread.pointer()
 }
 
-// CHECK: call {{.*}} @llvm.aarch64.rbit.i32(i32 %a)
+// CHECK: call {{.*}} @llvm.bitreverse.i32(i32 %a)
 unsigned rbit(unsigned a) {
   return __builtin_arm_rbit(a);
 }
 
-// CHECK: call {{.*}} @llvm.aarch64.rbit.i64(i64 %a)
+// CHECK: call {{.*}} @llvm.bitreverse.i64(i64 %a)
 unsigned long long rbit64(unsigned long long a) {
   return __builtin_arm_rbit64(a);
 }
Index: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
===
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp
@@ -5226,14 +5226,14 @@
"rbit of unusual size!");
 llvm::Value *Arg = EmitScalarExpr(E->getArg(0));
 return Builder.CreateCall(
-CGM.getIntrinsic(Intrinsic::aarch64_rbit, Arg->getType()), Arg, 
"rbit");
+CGM.getIntrinsic(Intrinsic::bitreverse, Arg->getType()), Arg, "rbit");
   }
   if (BuiltinID == AArch64::BI__builtin_arm_rbit64) {
 assert((getContext().getTypeSize(E->getType()) == 64) &&
"rbit of unusual size!");
 llvm::Value *Arg = EmitScalarExpr(E->getArg(0));
 return Builder.CreateCall(
-CGM.getIntrinsic(Intrinsic::aarch64_rbit, Arg->getType()), Arg, 
"rbit");
+CGM.getIntrinsic(Intrinsic::bitreverse, Arg->getType()), Arg, "rbit");
   }
 
   if (BuiltinID == AArch64::BI__clear_cache) {


Index: cfe/trunk/test/CodeGen/arm_acle.c
===
--- cfe/trunk/test/CodeGen/arm_acle.c
+++ cfe/trunk/test/CodeGen/arm_acle.c
@@ -245,22 +245,22 @@
 
 // ARM-LABEL: test_rbit
 // AArch32: call i32 @llvm.arm.rbit
-// AArch64: call i32 @llvm.aarch64.rbit.i32
+// AArch64: call i32 @llvm.bitreverse.i32
 uint32_t test_rbit(uint32_t t) {
   return __rbit(t);
 }
 
 // ARM-LABEL: test_rbitl
 // AArch32: call i32 @llvm.arm.rbit
-// AArch64: call i64 @llvm.aarch64.rbit.i64
+// AArch64: call i64 @llvm.bitreverse.i64
 long test_rbitl(long t) {
   return __rbitl(t);
 }
 
 // ARM-LABEL: test_rbitll
 // AArch32: call i32 @llvm.arm.rbit
 // AArch32: call i32 @llvm.arm.rbit
-// AArch64: call i64 @llvm.aarch64.rbit.i64
+// AArch64: call i64 @llvm.bitreverse.i64
 uint64_t test_rbitll(uint64_t t) {
   return __rbitll(t);
 }
Index: cfe/trunk/test/CodeGen/builtins-arm64.c
===
--- cfe/trunk/test/CodeGen/builtins-arm64.c
+++ cfe/trunk/test/CodeGen/builtins-arm64.c
@@ -10,12 +10,12 @@
 // CHECK: call {{.*}} @llvm.thread.pointer()
 }
 
-// CHECK: call {{.*}} @llvm.aarch64.rbit.i32(i32 %a)
+// CHECK: call {{.*}} @llvm.bitreverse.i32(i32 %a)
 unsigned rbit(unsigned a) {
   return __builtin_arm_rbit(a);
 }
 
-// CHECK: call {{.*}} @llvm.aarch64.rbit.i64(i64 %a)
+// CHECK: call {{.*}} @llvm.bitreverse.i64(i64 %a)
 unsigned long long rbit64(unsigned long long a) {
   return __builtin_arm_rbit64(a);
 }
Index: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
===
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp
@@ -5226,14 +5226,14 @@
"rbit of unusual size!");
 llvm::Value *Arg = EmitScalarExpr(E->getArg(0));
 return Builder.CreateCall(
-CGM.getIntrinsic(Intrinsic::aarch64_rbit, Arg->getType()), Arg, "rbit");
+CGM.getIntrinsic(Intrinsic::bitreverse, Arg->getType()), Arg, "rbit");
   }
   if (BuiltinID == 

r291574 - [AArch64] Use generic bitreverse intrinsic, rather than AArch64 specific.

2017-01-10 Thread Chad Rosier via cfe-commits
Author: mcrosier
Date: Tue Jan 10 11:20:28 2017
New Revision: 291574

URL: http://llvm.org/viewvc/llvm-project?rev=291574=rev
Log:
[AArch64] Use generic bitreverse intrinsic, rather than AArch64 specific.

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

Modified:
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/test/CodeGen/arm_acle.c
cfe/trunk/test/CodeGen/builtins-arm64.c

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=291574=291573=291574=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Tue Jan 10 11:20:28 2017
@@ -5226,14 +5226,14 @@ Value *CodeGenFunction::EmitAArch64Built
"rbit of unusual size!");
 llvm::Value *Arg = EmitScalarExpr(E->getArg(0));
 return Builder.CreateCall(
-CGM.getIntrinsic(Intrinsic::aarch64_rbit, Arg->getType()), Arg, 
"rbit");
+CGM.getIntrinsic(Intrinsic::bitreverse, Arg->getType()), Arg, "rbit");
   }
   if (BuiltinID == AArch64::BI__builtin_arm_rbit64) {
 assert((getContext().getTypeSize(E->getType()) == 64) &&
"rbit of unusual size!");
 llvm::Value *Arg = EmitScalarExpr(E->getArg(0));
 return Builder.CreateCall(
-CGM.getIntrinsic(Intrinsic::aarch64_rbit, Arg->getType()), Arg, 
"rbit");
+CGM.getIntrinsic(Intrinsic::bitreverse, Arg->getType()), Arg, "rbit");
   }
 
   if (BuiltinID == AArch64::BI__clear_cache) {

Modified: cfe/trunk/test/CodeGen/arm_acle.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/arm_acle.c?rev=291574=291573=291574=diff
==
--- cfe/trunk/test/CodeGen/arm_acle.c (original)
+++ cfe/trunk/test/CodeGen/arm_acle.c Tue Jan 10 11:20:28 2017
@@ -245,14 +245,14 @@ int16_t test_revsh(int16_t t) {
 
 // ARM-LABEL: test_rbit
 // AArch32: call i32 @llvm.arm.rbit
-// AArch64: call i32 @llvm.aarch64.rbit.i32
+// AArch64: call i32 @llvm.bitreverse.i32
 uint32_t test_rbit(uint32_t t) {
   return __rbit(t);
 }
 
 // ARM-LABEL: test_rbitl
 // AArch32: call i32 @llvm.arm.rbit
-// AArch64: call i64 @llvm.aarch64.rbit.i64
+// AArch64: call i64 @llvm.bitreverse.i64
 long test_rbitl(long t) {
   return __rbitl(t);
 }
@@ -260,7 +260,7 @@ long test_rbitl(long t) {
 // ARM-LABEL: test_rbitll
 // AArch32: call i32 @llvm.arm.rbit
 // AArch32: call i32 @llvm.arm.rbit
-// AArch64: call i64 @llvm.aarch64.rbit.i64
+// AArch64: call i64 @llvm.bitreverse.i64
 uint64_t test_rbitll(uint64_t t) {
   return __rbitll(t);
 }

Modified: cfe/trunk/test/CodeGen/builtins-arm64.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/builtins-arm64.c?rev=291574=291573=291574=diff
==
--- cfe/trunk/test/CodeGen/builtins-arm64.c (original)
+++ cfe/trunk/test/CodeGen/builtins-arm64.c Tue Jan 10 11:20:28 2017
@@ -10,12 +10,12 @@ void *tp (void) {
 // CHECK: call {{.*}} @llvm.thread.pointer()
 }
 
-// CHECK: call {{.*}} @llvm.aarch64.rbit.i32(i32 %a)
+// CHECK: call {{.*}} @llvm.bitreverse.i32(i32 %a)
 unsigned rbit(unsigned a) {
   return __builtin_arm_rbit(a);
 }
 
-// CHECK: call {{.*}} @llvm.aarch64.rbit.i64(i64 %a)
+// CHECK: call {{.*}} @llvm.bitreverse.i64(i64 %a)
 unsigned long long rbit64(unsigned long long a) {
   return __builtin_arm_rbit64(a);
 }


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


[PATCH] D28445: [Analyzer] Extend taint propagation and checking

2017-01-10 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added a comment.

Thanks for working on the taint! I really wish the taint analysis in the 
analyzer to flourish, and the part you've digged into is particularly 
sensitive, so i'd dump some thoughts here, hopefully helpful.

**What works as it should: **

> In the second example, the SVal obtained in 
> `GenericTaintChecker::getPointedToSymbol()` is a `LazyCompoundVal` so 
> `SVal::getAsSymbol()` returns a NULL SymbolRef, meaning the symbol is not 
> tainted.

Only symbols currently can, and in my opinion ever should, directly carry taint.

We have symbols, regions, concrete values, and compound values.

A symbol //$s// denotes a particular but unknown value from a certain set 
//**S**// (say, of all integers or all pointers); we are not generally sure if 
it can denote any value from //**S**//, or only from a smaller subset 
//**S'**// within //**S**// (for example, the analyzer may be unaware that 
//$s// is always positive, because the small part of the code it's looking into 
doesn't give any hints). Analyzer also gathers constraints //**C**// when he 
picks execution paths - for instance, on a branch condition "//if ($s < 5)//", 
if we pick the true branch, //**C**// gets cropped into //[-INT_MIN, 4]//, and 
the possible values of //$s// stay within //**S'**// intersected with 
//**C**//, while the analyzer thinks that possible values of //$s// are within 
//**S**// intersected with //**C**//.

A tainted symbol merely corresponds to the special case when we know that 
//**S'** = **S**//, which we normally don't - that is, the analyzer knows that 
for some reason the symbol's value is so much chaotic that it may definitely 
take any value from //**S**// in run-time. The analyzer can know it by seeing 
that the symbol comes from an "untrusted source" such as from "outside".

We do not really talk about tainted regions - instead, we talk about tainted 
pointer values, which are symbols. In this sense, in code

  char buffer[100];

the region of variable `buffer` cannot be tainted. No matter what we do, the 
buffer region itself comes from a perfectly trusted source - it's always in the 
same well-known segment of memory (stack or in global memory). In practice this 
means that the attacker cannot affect or forge the positioning of this segment 
in any way. On the other hand, if //$i// is a tainted index symbol, then region 
//buffer[$i]// of the //$i//'th element would be "said to be tainted" - in the 
sense, its pointer is known to possibly take any value, not necessarily within 
range of the buffer. Similarly, if a pointer-symbol is tainted, the segment of 
memory (region) it points to (called `SymbolicRegion`) is "said to be tainted". 
So //whenever we're talking about a "tainted region", it's always a shorthand 
for talking about a certain tainted symbol//.

Concrete values shouldn't be tainted for the same reason - they are already 
"known", their //**S**// would consist of one element, so there's little 
interest in saying that they can take any value from this set - they're bound 
to take that only value.

Now, we have (possibly lazy) compound values. The whole point of compound 
values is that they consist of multiple other values, and therefore there's 
usually little sense in even considering them as a whole. Some sub-values of 
them may be null, over-constrained, uninitialized, irrelevant (eg. padding), or 
tainted, while other sub-values may be completely different. In your example, 
you obtain a compound value of an array, which consists of all values of all 
elements of the array. There's no point in asking if the compound value itself 
is tainted; instead, you might be interested in particular elements. For 
example, `buffer[1]` may be tainted, while `buffer[2]` was overwritten with 
`'\0'` and is no longer tainted. If you had a structure, you may ask if a 
certain field is tainted, or if all fields are tainted.

**What works but not as it should:**

> In the first example, buf has it's symbol correctly extracted (via 
> `GenericTaintChecker::getPointedToSymbol())` as a 
> `SymbolDerived{conj_$N{char}, element{buf,0 S64b,char}}`.

Nope, unfortunately, in fact this is not correctly extracted either. This 
symbol denotes the value of the first element of the buffer. The taint checker 
marks the first element as tainted, and then later reads that the first element 
is tainted, and throws the warning. However, if we pass, say, `buffer+1` to 
`execl`, it breaks.

The root cause of the problem is how the analyzer denotes casted/typed 
pointers: the `SVal` for a pointer of type `T*` is said to be the element 
region with index 0 of the region behind the pointer. You can read this as "The 
pointer points to the first `T` on this segment of memory". In this case, we 
try to say that the value behind the pointer is tainted, and we forget that the 
value behind the pointer is not only the first element of the array, but the 
whole array, even though the pointer points to the first element only.

[libcxx] r291572 - Fix up some mismatched SFINAE conditionsin shared_ptr; some used '_Tp*', others used 'element_type *'. Today, they're the same - but soon they won't be. No functional change.

2017-01-10 Thread Marshall Clow via cfe-commits
Author: marshall
Date: Tue Jan 10 10:59:33 2017
New Revision: 291572

URL: http://llvm.org/viewvc/llvm-project?rev=291572=rev
Log:
Fix up some mismatched SFINAE conditionsin shared_ptr; some used '_Tp*', others 
used 'element_type *'. Today, they're the same - but soon they won't be. No 
functional change.

Modified:
libcxx/trunk/include/memory

Modified: libcxx/trunk/include/memory
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/memory?rev=291572=291571=291572=diff
==
--- libcxx/trunk/include/memory (original)
+++ libcxx/trunk/include/memory Tue Jan 10 10:59:33 2017
@@ -3884,6 +3884,7 @@ class _LIBCPP_TEMPLATE_VIS shared_ptr
 {
 public:
 typedef _Tp element_type;
+
 #if _LIBCPP_STD_VER > 14
 typedef weak_ptr<_Tp> weak_type;
 #endif
@@ -3914,17 +3915,17 @@ public:
 template
 _LIBCPP_INLINE_VISIBILITY
 shared_ptr(const shared_ptr<_Yp>& __r,
-   typename enable_if::value, 
__nat>::type = __nat())
+   typename enable_if::value, __nat>::type = __nat())
_NOEXCEPT;
 #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
 _LIBCPP_INLINE_VISIBILITY
 shared_ptr(shared_ptr&& __r) _NOEXCEPT;
 template _LIBCPP_INLINE_VISIBILITY  
shared_ptr(shared_ptr<_Yp>&& __r,
-   typename enable_if::value, 
__nat>::type = __nat())
+   typename enable_if::value, __nat>::type = __nat())
_NOEXCEPT;
 #endif  // _LIBCPP_HAS_NO_RVALUE_REFERENCES
 template explicit shared_ptr(const weak_ptr<_Yp>& __r,
-   typename enable_if::value, 
__nat>::type= __nat());
+   typename enable_if::value, __nat>::type= __nat());
 #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES
 template
 shared_ptr(auto_ptr<_Yp>&& __r,
@@ -4316,7 +4317,7 @@ template
 template
 inline
 shared_ptr<_Tp>::shared_ptr(const shared_ptr<_Yp>& __r,
-typename enable_if::value, __nat>::type)
+typename enable_if::value, __nat>::type)
  _NOEXCEPT
 : __ptr_(__r.__ptr_),
   __cntrl_(__r.__cntrl_)
@@ -4341,7 +4342,7 @@ template
 template
 inline
 shared_ptr<_Tp>::shared_ptr(shared_ptr<_Yp>&& __r,
-typename enable_if::value, __nat>::type)
+typename enable_if::value, __nat>::type)
  _NOEXCEPT
 : __ptr_(__r.__ptr_),
   __cntrl_(__r.__cntrl_)
@@ -4639,7 +4640,7 @@ template
 inline
 typename enable_if
 <
-is_convertible<_Yp*, _Tp*>::value,
+is_convertible<_Yp*, typename shared_ptr<_Tp>::element_type*>::value,
 shared_ptr<_Tp>&
 >::type
 shared_ptr<_Tp>::operator=(const shared_ptr<_Yp>& __r) _NOEXCEPT
@@ -4664,7 +4665,7 @@ template
 inline
 typename enable_if
 <
-is_convertible<_Yp*, _Tp*>::value,
+is_convertible<_Yp*, typename shared_ptr<_Tp>::element_type*>::value,
 shared_ptr<_Tp>&
 >::type
 shared_ptr<_Tp>::operator=(shared_ptr<_Yp>&& __r)
@@ -4679,7 +4680,7 @@ inline
 typename enable_if
 <
 !is_array<_Yp>::value &&
-is_convertible<_Yp*, _Tp*>::value,
+is_convertible<_Yp*, typename shared_ptr<_Tp>::element_type*>::value,
 shared_ptr<_Tp>
 >::type&
 shared_ptr<_Tp>::operator=(auto_ptr<_Yp>&& __r)
@@ -4694,7 +4695,8 @@ inline
 typename enable_if
 <
 !is_array<_Yp>::value &&
-is_convertible::pointer, _Tp*>::value,
+is_convertible::pointer, 
+   typename shared_ptr<_Tp>::element_type*>::value,
 shared_ptr<_Tp>&
 >::type
 shared_ptr<_Tp>::operator=(unique_ptr<_Yp, _Dp>&& __r)
@@ -4711,7 +4713,7 @@ inline _LIBCPP_INLINE_VISIBILITY
 typename enable_if
 <
 !is_array<_Yp>::value &&
-is_convertible<_Yp*, _Tp*>::value,
+is_convertible<_Yp*, element_type*>::value,
 shared_ptr<_Tp>&
 >::type
 shared_ptr<_Tp>::operator=(auto_ptr<_Yp> __r)
@@ -4726,7 +4728,7 @@ inline _LIBCPP_INLINE_VISIBILITY
 typename enable_if
 <
 !is_array<_Yp>::value &&
-is_convertible::pointer, _Tp*>::value,
+is_convertible::pointer, 
element_type*>::value,
 shared_ptr<_Tp>&
 >::type
 shared_ptr<_Tp>::operator=(unique_ptr<_Yp, _Dp> __r)
@@ -4759,7 +4761,7 @@ template
 inline
 typename enable_if
 <
-is_convertible<_Yp*, _Tp*>::value,
+is_convertible<_Yp*, typename shared_ptr<_Tp>::element_type*>::value,
 void
 >::type
 shared_ptr<_Tp>::reset(_Yp* __p)
@@ -4772,7 +4774,7 @@ template
 inline
 typename enable_if
 <
-is_convertible<_Yp*, _Tp*>::value,
+is_convertible<_Yp*, typename shared_ptr<_Tp>::element_type*>::value,
 void
 >::type
 shared_ptr<_Tp>::reset(_Yp* __p, _Dp __d)
@@ 

[PATCH] D20428: Tracking exception specification source locations

2017-01-10 Thread don hinton via Phabricator via cfe-commits
hintonda updated this revision to Diff 83816.
hintonda added a comment.

- Address comments.


https://reviews.llvm.org/D20428

Files:
  include/clang/AST/Decl.h
  include/clang/AST/TypeLoc.h
  lib/AST/Decl.cpp
  lib/Parse/ParseDeclCXX.cpp
  lib/Sema/SemaType.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTWriter.cpp
  unittests/AST/SourceLocationTest.cpp

Index: unittests/AST/SourceLocationTest.cpp
===
--- unittests/AST/SourceLocationTest.cpp
+++ unittests/AST/SourceLocationTest.cpp
@@ -670,5 +670,72 @@
   Language::Lang_CXX11));
 }
 
+class ExceptionSpecRangeVerifier : public RangeVerifier {
+protected:
+  SourceRange getRange(const TypeLoc ) override {
+auto T =
+  Node.getUnqualifiedLoc().castAs();
+assert(!T.isNull());
+return T.getExceptionSpecRange();
+  }
+};
+
+class ParmVarExceptionSpecRangeVerifier : public RangeVerifier {
+protected:
+  SourceRange getRange(const ParmVarDecl ) override {
+if (const TypeSourceInfo *TSI = Node.getTypeSourceInfo()) {
+  TypeLoc TL = TSI->getTypeLoc();
+  if (TL.getType()->isPointerType()) {
+TL = TL.getNextTypeLoc().IgnoreParens();
+if (auto FPTL = TL.getAs()) {
+  return FPTL.getExceptionSpecRange();
+}
+  }
+}
+return SourceRange();
+  }
+};
+
+TEST(FunctionDecl, ExceptionSpecifications) {
+  ExceptionSpecRangeVerifier Verifier;
+
+  Verifier.expectRange(1, 10, 1, 16);
+  EXPECT_TRUE(Verifier.match("void f() throw();\n", loc(functionType(;
+
+  Verifier.expectRange(1, 10, 1, 34);
+  EXPECT_TRUE(Verifier.match("void f() throw(void(void) throw());\n",
+ loc(functionType(;
+
+  Verifier.expectRange(1, 10, 1, 19);
+  std::vector Args;
+  Args.push_back("-fms-extensions");
+  EXPECT_TRUE(Verifier.match("void f() throw(...);\n", loc(functionType()),
+ Args, Language::Lang_CXX));
+
+  Verifier.expectRange(1, 10, 1, 10);
+  EXPECT_TRUE(Verifier.match("void f() noexcept;\n", loc(functionType()),
+ Language::Lang_CXX11));
+
+  Verifier.expectRange(1, 10, 1, 24);
+  EXPECT_TRUE(Verifier.match("void f() noexcept(false);\n", loc(functionType()),
+ Language::Lang_CXX11));
+
+  Verifier.expectRange(1, 10, 1, 32);
+  EXPECT_TRUE(Verifier.match("void f() noexcept(noexcept(1+1));\n",
+ loc(functionType()), Language::Lang_CXX11));
+
+  ParmVarExceptionSpecRangeVerifier Verifier2;
+  Verifier2.expectRange(1, 25, 1, 31);
+  EXPECT_TRUE(Verifier2.match("void g(void (*fp)(void) throw());\n",
+  parmVarDecl(hasType(pointerType(pointee(
+  parenType(innerType(functionType();
+
+  Verifier2.expectRange(1, 25, 1, 38);
+  EXPECT_TRUE(Verifier2.match("void g(void (*fp)(void) noexcept(true));\n",
+  parmVarDecl(hasType(pointerType(pointee(
+  parenType(innerType(functionType())),
+  Language::Lang_CXX11));
+}
+
 } // end namespace ast_matchers
 } // end namespace clang
Index: lib/Serialization/ASTWriter.cpp
===
--- lib/Serialization/ASTWriter.cpp
+++ lib/Serialization/ASTWriter.cpp
@@ -629,6 +629,7 @@
   Record.AddSourceLocation(TL.getLocalRangeBegin());
   Record.AddSourceLocation(TL.getLParenLoc());
   Record.AddSourceLocation(TL.getRParenLoc());
+  Record.AddSourceRange(TL.getExceptionSpecRange());
   Record.AddSourceLocation(TL.getLocalRangeEnd());
   for (unsigned i = 0, e = TL.getNumParams(); i != e; ++i)
 Record.AddDeclRef(TL.getParam(i));
Index: lib/Serialization/ASTReader.cpp
===
--- lib/Serialization/ASTReader.cpp
+++ lib/Serialization/ASTReader.cpp
@@ -5990,6 +5990,8 @@
   TL.setLocalRangeBegin(ReadSourceLocation());
   TL.setLParenLoc(ReadSourceLocation());
   TL.setRParenLoc(ReadSourceLocation());
+  TL.setExceptionSpecRange(SourceRange(Reader->ReadSourceLocation(*F, Record, Idx),
+   Reader->ReadSourceLocation(*F, Record, Idx)));
   TL.setLocalRangeEnd(ReadSourceLocation());
   for (unsigned i = 0, e = TL.getNumParams(); i != e; ++i) {
 TL.setParam(i, Reader->ReadDeclAs(*F, Record, Idx));
Index: lib/Sema/TreeTransform.h
===
--- lib/Sema/TreeTransform.h
+++ lib/Sema/TreeTransform.h
@@ -5023,6 +5023,7 @@
   NewTL.setLocalRangeBegin(TL.getLocalRangeBegin());
   NewTL.setLParenLoc(TL.getLParenLoc());
   NewTL.setRParenLoc(TL.getRParenLoc());
+  NewTL.setExceptionSpecRange(TL.getExceptionSpecRange());
   NewTL.setLocalRangeEnd(TL.getLocalRangeEnd());
   for (unsigned i = 0, e = NewTL.getNumParams(); i != e; ++i)
 NewTL.setParam(i, ParamDecls[i]);
Index: 

[PATCH] D28400: [AArch64] Use generic bitreverse intrinsic, rather than AArch64 specific.

2017-01-10 Thread silviu.bara...@arm.com via Phabricator via cfe-commits
sbaranga accepted this revision.
sbaranga added a reviewer: sbaranga.
sbaranga added a comment.
This revision is now accepted and ready to land.

This looks straight-forward to me. LGTM.

-Silviu


https://reviews.llvm.org/D28400



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


[PATCH] D20428: Tracking exception specification source locations

2017-01-10 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In https://reviews.llvm.org/D20428#641416, @hintonda wrote:

> Aaron, I've got this version in a branch, so if you like, I'd be happy to 
> apply Malcolm's suggestions.


Please do; they're good suggestions.


https://reviews.llvm.org/D20428



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


[PATCH] D28400: [AArch64] Use generic bitreverse intrinsic, rather than AArch64 specific.

2017-01-10 Thread Chad Rosier via Phabricator via cfe-commits
mcrosier added inline comments.



Comment at: test/CodeGen/arm_acle.c:247
 // ARM-LABEL: test_rbit
 // AArch32: call i32 @llvm.arm.rbit
+// AArch64: call i32 @llvm.bitreverse.i32

RKSimon wrote:
> Since you're here is it worth dealing with the AARCH32 case as well? We know 
> it works on the llvm side.
I was thinking I would commit a separate patch once this one and D28379 were 
approved.


https://reviews.llvm.org/D28400



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


[PATCH] D20428: Tracking exception specification source locations

2017-01-10 Thread don hinton via Phabricator via cfe-commits
hintonda added a comment.

Aaron, I've got this version in a branch, so if you like, I'd be happy to apply 
Malcolm's suggestions.


https://reviews.llvm.org/D20428



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


[PATCH] D28451: [AVR] Add support for the 'interrupt' and 'naked' attributes

2017-01-10 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman requested changes to this revision.
aaron.ballman added a comment.
This revision now requires changes to proceed.

The patch is also missing Sema tests that ensure the attributes are properly 
diagnosed when applied to something other than a function, a target other than 
AVR, arguments are present, etc.




Comment at: include/clang/Basic/Attr.td:485
+  let ParseKind = "Interrupt";
+  let Documentation = [Undocumented];
+}

No new undocumented attributes, please.



Comment at: include/clang/Basic/Attr.td:488
+
+def AVRSignal : InheritableAttr, TargetSpecificAttr {
+  let Spellings = [GNU<"signal">];

Does this attribute appertain to any specific subjects, or can you apply it to 
any declaration?



Comment at: include/clang/Basic/Attr.td:490
+  let Spellings = [GNU<"signal">];
+  let Documentation = [Undocumented];
+}

No new undocumented attributes, please.



Comment at: test/CodeGen/avr/attributes/naked.c:4
+// CHECK: define void @foo() #0
+__attribute__((naked)) void foo(void) { }
+

This test seems unrelated as you didn't modify anything about the naked 
attribute?


https://reviews.llvm.org/D28451



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


[PATCH] D28260: Add an argumentsAre matcher

2017-01-10 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

Given that this can't be expressed as a dynamic matcher, I'm wondering what the 
use case is for the matcher. Do you have a specific need for this 
functionality, or do you see this being generally useful?


https://reviews.llvm.org/D28260



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


[PATCH] D28260: Add an argumentsAre matcher

2017-01-10 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman requested changes to this revision.
aaron.ballman added a reviewer: aaron.ballman.
aaron.ballman added a comment.
This revision now requires changes to proceed.

You should also regenerate the HTML matcher documentation as part of this patch.




Comment at: include/clang/ASTMatchers/ASTMatchers.h:3075
+///
+/// Example matches the call to f2, but not f1 or f3.
+/// (matcher = callExpr(argumentsAre(declRefExpr(), declRefExpr(

This is a neat matcher, but I'm not certain it will work with the dynamic 
matchers, which is an unfortunate divergence for clang-query.

Another concern is that this is leaking implementation details into 
ASTMatchers.h rather than keeping them in ASTMatchersInternal.h.



Comment at: unittests/ASTMatchers/ASTMatchersTraversalTest.cpp:383
+  EXPECT_TRUE(matches("void f(int x, int y) { f(x, y); }", Call));
+  EXPECT_TRUE(notMatches("void f(int x, int y, int z) { f(x, y, z); }", Call));
+}

How does this matcher work in the presence of default arguments? e.g.,
```
void f(int a, int b = 12);
f(1);
```
Will `callExpr(argumentsAre(integerLiteral()))` match?

A similar question applies for variadic functions and functions without a 
prototype (from C).

I suspect it all works fine, but some test cases would be nice.


https://reviews.llvm.org/D28260



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


[PATCH] D20693: [clang-tidy] New checker to replace dynamic exception specifications

2017-01-10 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman requested changes to this revision.
aaron.ballman added inline comments.



Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:41
+void UseNoexceptCheck::registerMatchers(MatchFinder *Finder) {
+  if (!getLangOpts().CPlusPlus)
+return;

Shouldn't we require C++11 or later?



Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:64
+  Finder->addMatcher(
+  parmVarDecl(hasType(pointerType(pointee(parenType(innerType(
+  functionProtoType(hasDynamicExceptionSpec(

Will this catch pointers to member functions as well?
```
struct S {
  void f() throw();
};

void f(void (S::*)() throw()) {

}
```



Comment at: clang-tidy/modernize/UseNoexceptCheck.cpp:68
+  this);
+}
+

Also missing: typedefs and using declarations.



Comment at: docs/clang-tidy/checks/modernize-use-noexcept.rst:30
+By default this check will only replace ``throw()`` with ``noexcept``,
+and ``throw([,...])`` or ``throw(...)`` with blank except
+for operator delete and destructors, which are replaced with

I continue to object to removing the explicit exception specification entirely 
as the default behavior without strong justification. Further. there is no 
option to control this behavior.



Comment at: docs/clang-tidy/checks/modernize-use-noexcept.rst:38
+that don't support the ``noexcept`` keyword.  Users can define the
+macro to be ``noexcept`` or ``throw()`` depending on whether or not
+noexcept is supported.  Specifications that can throw, e.g.,

I'm not certain I understand the justification of calling out older compilers 
or suggesting use of `throw()`. The check will continually flag `throw()` and 
try to recommend `noexcept` in its place, won't it? At least, that's how I read 
the preceding paragraph.

I think the macro replacement is a reasonable feature, but I think the check 
only makes sense for C++11 or later, since C++98 users really have no 
alternatives to dynamic exception specifications.


https://reviews.llvm.org/D20693



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


[PATCH] D20428: Tracking exception specification source locations

2017-01-10 Thread Malcolm Parsons via Phabricator via cfe-commits
malcolm.parsons added inline comments.



Comment at: include/clang/AST/TypeLoc.h:1355
+  bool hasExceptionSpec() const {
+if (auto FPT = dyn_cast(getTypePtr())) {
+  return FPT->hasExceptionSpec();

`auto *`



Comment at: include/clang/AST/TypeLoc.h:1443
+if (hasExceptionSpec())
+  setExceptionSpecRange(SourceRange(Loc));
   }

`SourceRange`'s constructor from `SourceLocation` is implicit.


https://reviews.llvm.org/D20428



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


[PATCH] D28400: [AArch64] Use generic bitreverse intrinsic, rather than AArch64 specific.

2017-01-10 Thread Simon Pilgrim via Phabricator via cfe-commits
RKSimon added inline comments.



Comment at: test/CodeGen/arm_acle.c:247
 // ARM-LABEL: test_rbit
 // AArch32: call i32 @llvm.arm.rbit
+// AArch64: call i32 @llvm.bitreverse.i32

Since you're here is it worth dealing with the AARCH32 case as well? We know it 
works on the llvm side.


https://reviews.llvm.org/D28400



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


  1   2   >