Re: [PATCH] D12664: Fixed comparison.

[James Touton via cfe-commits]

jtouton abandoned this revision.
jtouton added a comment.

This change was introduced quite some time ago now.


https://reviews.llvm.org/D12664



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

Re: [PATCH] D22712: Remove FileEntry copy-constructor

[Alexander Shaposhnikov via cfe-commits]

alexshap added a comment.

two separate observations:

1. **without my changes** :

I checked the following revision: r276508 | rsmith | 2016-07-22 19:32:21 
(with gcc 4.7.4, g++ 4.7.4, Ubuntu 16.04.1 LTS)
build of llvm/clang failed, the logs are here: https://reviews.llvm.org/P6916
(emplace is one of the issues)

so if i understand correctly right now **without any of my changes** the build 
with gcc 4.7.4 is failing.

2. **one more detail about this cleanup**

yeah, you are right that for gcc 4.7.4 this particular place would be an issue 
too:

A. FileEntries are owned by std::map 
UniqueRealFiles
(llvm/tools/clang/include/clang/Basic/FileManager.h:125)

B. The code populating that map is located in 
llvm/tools/clang/lib/Basic/FileManager.cpp
and starts with this:

// llvm/tools/clang/lib/Basic/FileManager.cpp:263
FileEntry &UFE = UniqueRealFiles[Data.UniqueID]; -

unfortunately, with gcc-4.7.4 this code wants not only default constructor, but 
copy-constructor as well:
https://reviews.llvm.org/P6919
("make -j4 clangBasic" logs)


https://reviews.llvm.org/D22712



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

r276618 - Update description for CLANG_DEFAULT_CXX_STDLIB and add comment. NFC

[Jonas Hahnfeld via cfe-commits]

Author: hahnfeld
Date: Mon Jul 25 03:04:26 2016
New Revision: 276618

URL: http://llvm.org/viewvc/llvm-project?rev=276618&view=rev
Log:
Update description for CLANG_DEFAULT_CXX_STDLIB and add comment. NFC

We agreed to call it "platform default" instead of "architecture default".
(see D17286)

Modified:
cfe/trunk/CMakeLists.txt
cfe/trunk/lib/Driver/ToolChain.cpp

Modified: cfe/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/CMakeLists.txt?rev=276618&r1=276617&r2=276618&view=diff
==
--- cfe/trunk/CMakeLists.txt (original)
+++ cfe/trunk/CMakeLists.txt Mon Jul 25 03:04:26 2016
@@ -193,11 +193,11 @@ set(ENABLE_X86_RELAX_RELOCATIONS OFF CAC
 "enable x86 relax relocations by default")
 
 set(CLANG_DEFAULT_CXX_STDLIB "" CACHE STRING
-  "Default C++ stdlib to use (empty for architecture default, \"libstdc++\" or 
\"libc++\"")
+  "Default C++ stdlib to use (empty for platform default, \"libstdc++\" or 
\"libc++\"")
 if (NOT(CLANG_DEFAULT_CXX_STDLIB STREQUAL "" OR
 CLANG_DEFAULT_CXX_STDLIB STREQUAL "libstdc++" OR
 CLANG_DEFAULT_CXX_STDLIB STREQUAL "libc++"))
-  message(WARNING "Resetting default C++ stdlib to use architecture default")
+  message(WARNING "Resetting default C++ stdlib to use platform default")
   set(CLANG_DEFAULT_CXX_STDLIB "")
 endif()
 

Modified: cfe/trunk/lib/Driver/ToolChain.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChain.cpp?rev=276618&r1=276617&r2=276618&view=diff
==
--- cfe/trunk/lib/Driver/ToolChain.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChain.cpp Mon Jul 25 03:04:26 2016
@@ -577,6 +577,8 @@ ToolChain::CXXStdlibType ToolChain::GetC
 << A->getAsString(Args);
   }
 
+  // If no argument was provided or its value was invalid, look for the
+  // default unless forced or configured to take the platform default.
   if (!HasValidType && (ForcePlatformDefault ||
   !ParseCXXStdlibType(CLANG_DEFAULT_CXX_STDLIB, Type)))
 Type = GetDefaultCXXStdlibType();


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

Re: [PATCH] D21748: Implement tooling::Replacements as a class.

[Eric Liu via cfe-commits]

ioeric added a comment.

ping :)


https://reviews.llvm.org/D21748



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

Re: [PATCH] D22663: Support setting default value for -rtlib at build time

[Jonas Hahnfeld via cfe-commits]

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

In general the idea looks good and takes this point off my personal todo list 
:-)

With the changes applied and configured with `CLANG_DEFAULT_RTLIB=compiler-rt` 
some tests fail so you may have to adapt the idea of `-rtlib=platform` for the 
tests.

Just a minor comment: Please include the full context in your diff as explained 
in the docs: 
http://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface
This makes reviewing easier because one can browse the surrounding code ;-)



Comment at: lib/Driver/ToolChain.cpp:530
@@ -538,1 +529,3 @@
+  const Arg* A = Args.getLastArg(options::OPT_rtlib_EQ);
+  StringRef LibName = A ? A->getValue() : CLANG_DEFAULT_RTLIB;
 

What I dislike here is that it falls back to the platform default if the 
specified argument value is invalid regardless of what was configured. This may 
be surprising for the user as he gets a different behaviour when specifiying 
`-rtlib=bla` than completely omitting.

I just added a comment explaining how this works in `GetCXXStdlibType`. Maybe 
you can adapt its idea?


https://reviews.llvm.org/D22663



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

Re: [PATCH] D22654: [Clang-rename] Remove custom version, fix extra space in error message

[Kirill Bobyrev via cfe-commits]

omtcyfz added a comment.

Just remove it then?


Repository:
  rL LLVM

https://reviews.llvm.org/D22654



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

[clang-tools-extra] r276620 - [clang-rename] fix typos in tests

[Kirill Bobyrev via cfe-commits]

Author: omtcyfz
Date: Mon Jul 25 03:56:11 2016
New Revision: 276620

URL: http://llvm.org/viewvc/llvm-project?rev=276620&view=rev
Log:
[clang-rename] fix typos in tests

TemplateFunctionFindBy{Declaration|Use}.cpp contained typos and therefore were
failing. clang-rename passes these tests after typos are fixed.

Modified:

clang-tools-extra/trunk/test/clang-rename/TemplateFunctionFindByDeclaration.cpp
clang-tools-extra/trunk/test/clang-rename/TemplateFunctionFindByUse.cpp

Modified: 
clang-tools-extra/trunk/test/clang-rename/TemplateFunctionFindByDeclaration.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-rename/TemplateFunctionFindByDeclaration.cpp?rev=276620&r1=276619&r2=276620&view=diff
==
--- 
clang-tools-extra/trunk/test/clang-rename/TemplateFunctionFindByDeclaration.cpp 
(original)
+++ 
clang-tools-extra/trunk/test/clang-rename/TemplateFunctionFindByDeclaration.cpp 
Mon Jul 25 03:56:11 2016
@@ -1,12 +1,9 @@
 // RUN: cat %s > %t.cpp
-// RUN: clang-rename -offset=241 -new-name=bar %t.cpp -i --
+// RUN: clang-rename -offset=154 -new-name=bar %t.cpp -i --
 // RUN: sed 's,//.*,,' %t.cpp | FileCheck %s
 
-// FIXME: clang-rename should be able to rename functions with templates.
-// XFAIL: *
-
 template 
-T foo(T value) {// CHECK: T boo(T value) {
+T foo(T value) {// CHECK: T bar(T value) {
   return value;
 }
 

Modified: 
clang-tools-extra/trunk/test/clang-rename/TemplateFunctionFindByUse.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-rename/TemplateFunctionFindByUse.cpp?rev=276620&r1=276619&r2=276620&view=diff
==
--- clang-tools-extra/trunk/test/clang-rename/TemplateFunctionFindByUse.cpp 
(original)
+++ clang-tools-extra/trunk/test/clang-rename/TemplateFunctionFindByUse.cpp Mon 
Jul 25 03:56:11 2016
@@ -1,17 +1,14 @@
 // RUN: cat %s > %t.cpp
-// RUN: clang-rename -offset=290 -new-name=Bar %t.cpp -i --
+// RUN: clang-rename -offset=233 -new-name=bar %t.cpp -i --
 // RUN: sed 's,//.*,,' %t.cpp | FileCheck %s
 
-// FIXME: clang-rename should be able to rename functions with templates.
-// XFAIL: *
-
 template 
-T foo(T value) {
+T foo(T value) {// CHECK: T bar(T value) {
   return value;
 }
 
 int main() {
-  foo(false);
-  foo(0);
+  foo(false); // CHECK: bar(false);
+  foo(0);  // CHECK: bar(0);
   return 0;
 }


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

[libunwind] r276625 - [libunwind][ARM] Add support for Thumb1 targets

[Oliver Stannard via cfe-commits]

Author: olista01
Date: Mon Jul 25 04:21:56 2016
New Revision: 276625

URL: http://llvm.org/viewvc/llvm-project?rev=276625&view=rev
Log:
[libunwind][ARM] Add support for Thumb1 targets

The Thumb1 version of the code for saving and restoring the unwind
context has a few bugs which prevent it from working:
* It uses the STM instruction without writeback, which is not valid for Thumb1
  (It was introduced in Thumb2).
* It only saves/restores the low 8 registers, the sp and the lr, so if a
  program uses r8-r12 they will not be correctly restored when throwing an
  exception.

There aren't currently any Thumb1 build-bots to test this, but we have
been successfully running the libc++abi and libc++ test suites on
Cortex-M0 models, as well as some other test suites that use C++
exceptions on a downstream version of libunwind with this patch applied.

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


Modified:
libunwind/trunk/src/UnwindRegistersRestore.S
libunwind/trunk/src/UnwindRegistersSave.S

Modified: libunwind/trunk/src/UnwindRegistersRestore.S
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/src/UnwindRegistersRestore.S?rev=276625&r1=276624&r2=276625&view=diff
==
--- libunwind/trunk/src/UnwindRegistersRestore.S (original)
+++ libunwind/trunk/src/UnwindRegistersRestore.S Mon Jul 25 04:21:56 2016
@@ -322,9 +322,18 @@ DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9li
 @
   .p2align 2
 
DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind13Registers_arm20restoreCoreAndJumpToEv)
-#if !defined(__ARM_ARCH_ISA_ARM)
-  ldr r2, [r0, #52]
-  ldr r3, [r0, #60]
+#if !defined(__ARM_ARCH_ISA_ARM) && __ARM_ARCH_ISA_THUMB == 1
+  @ r8-r11: ldm into r1-r4, then mov to r8-r11
+  adds r0, #0x20
+  ldm r0!, {r1-r4}
+  subs r0, #0x30
+  mov r8, r1
+  mov r9, r2
+  mov r10, r3
+  mov r11, r4
+  @ r12 does not need loading, it it the intra-procedure-call scratch register
+  ldr r2, [r0, #0x34]
+  ldr r3, [r0, #0x3c]
   mov sp, r2
   mov lr, r3 @ restore pc into lr
   ldm r0, {r0-r7}

Modified: libunwind/trunk/src/UnwindRegistersSave.S
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/src/UnwindRegistersSave.S?rev=276625&r1=276624&r2=276625&view=diff
==
--- libunwind/trunk/src/UnwindRegistersSave.S (original)
+++ libunwind/trunk/src/UnwindRegistersSave.S Mon Jul 25 04:21:56 2016
@@ -309,13 +309,24 @@ DEFINE_LIBUNWIND_FUNCTION(unw_getcontext
 @
   .p2align 2
 DEFINE_LIBUNWIND_FUNCTION(unw_getcontext)
-#if !defined(__ARM_ARCH_ISA_ARM)
-  stm r0, {r0-r7}
+#if !defined(__ARM_ARCH_ISA_ARM) && __ARM_ARCH_ISA_THUMB == 1
+  stm r0!, {r0-r7}
+  mov r1, r8
+  mov r2, r9
+  mov r3, r10
+  stm r0!, {r1-r3}
+  mov r1, r11
   mov r2, sp
   mov r3, lr
-  str r2, [r0, #52]
-  str r3, [r0, #56]
-  str r3, [r0, #60]  @ store return address as pc
+  str r1, [r0, #0]   @ r11
+  @ r12 does not need storing, it it the intra-procedure-call scratch register
+  str r2, [r0, #8]   @ sp
+  str r3, [r0, #12]  @ lr
+  str r3, [r0, #16]  @ store return address as pc
+  @ T1 does not have a non-cpsr-clobbering register-zeroing instruction.
+  @ It is safe to use here though because we are about to return, and cpsr is
+  @ not expected to be preserved.
+  movs r0, #0@ return UNW_ESUCCESS
 #else
   @ 32bit thumb-2 restrictions for stm:
   @ . the sp (r13) cannot be in the list
@@ -324,13 +335,6 @@ DEFINE_LIBUNWIND_FUNCTION(unw_getcontext
   str sp, [r0, #52]
   str lr, [r0, #56]
   str lr, [r0, #60]  @ store return address as pc
-#endif
-#if __ARM_ARCH_ISA_THUMB == 1
-  @ T1 does not have a non-cpsr-clobbering register-zeroing instruction.
-  @ It is safe to use here though because we are about to return, and cpsr is
-  @ not expected to be preserved.
-  movs r0, #0@ return UNW_ESUCCESS
-#else
   mov r0, #0 @ return UNW_ESUCCESS
 #endif
   JMP(lr)


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

Re: [PATCH] D22292: [libunwind] Fix unw_getcontext for ARMv6-m

[Oliver Stannard via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL276625: [libunwind][ARM] Add support for Thumb1 targets 
(authored by olista01).

Changed prior to commit:
  https://reviews.llvm.org/D22292?vs=65039&id=65317#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D22292

Files:
  libunwind/trunk/src/UnwindRegistersRestore.S
  libunwind/trunk/src/UnwindRegistersSave.S

Index: libunwind/trunk/src/UnwindRegistersRestore.S
===
--- libunwind/trunk/src/UnwindRegistersRestore.S
+++ libunwind/trunk/src/UnwindRegistersRestore.S
@@ -322,9 +322,18 @@
 @
   .p2align 2
 
DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind13Registers_arm20restoreCoreAndJumpToEv)
-#if !defined(__ARM_ARCH_ISA_ARM)
-  ldr r2, [r0, #52]
-  ldr r3, [r0, #60]
+#if !defined(__ARM_ARCH_ISA_ARM) && __ARM_ARCH_ISA_THUMB == 1
+  @ r8-r11: ldm into r1-r4, then mov to r8-r11
+  adds r0, #0x20
+  ldm r0!, {r1-r4}
+  subs r0, #0x30
+  mov r8, r1
+  mov r9, r2
+  mov r10, r3
+  mov r11, r4
+  @ r12 does not need loading, it it the intra-procedure-call scratch register
+  ldr r2, [r0, #0x34]
+  ldr r3, [r0, #0x3c]
   mov sp, r2
   mov lr, r3 @ restore pc into lr
   ldm r0, {r0-r7}
Index: libunwind/trunk/src/UnwindRegistersSave.S
===
--- libunwind/trunk/src/UnwindRegistersSave.S
+++ libunwind/trunk/src/UnwindRegistersSave.S
@@ -309,28 +309,32 @@
 @
   .p2align 2
 DEFINE_LIBUNWIND_FUNCTION(unw_getcontext)
-#if !defined(__ARM_ARCH_ISA_ARM)
-  stm r0, {r0-r7}
+#if !defined(__ARM_ARCH_ISA_ARM) && __ARM_ARCH_ISA_THUMB == 1
+  stm r0!, {r0-r7}
+  mov r1, r8
+  mov r2, r9
+  mov r3, r10
+  stm r0!, {r1-r3}
+  mov r1, r11
   mov r2, sp
   mov r3, lr
-  str r2, [r0, #52]
-  str r3, [r0, #56]
-  str r3, [r0, #60]  @ store return address as pc
+  str r1, [r0, #0]   @ r11
+  @ r12 does not need storing, it it the intra-procedure-call scratch register
+  str r2, [r0, #8]   @ sp
+  str r3, [r0, #12]  @ lr
+  str r3, [r0, #16]  @ store return address as pc
+  @ T1 does not have a non-cpsr-clobbering register-zeroing instruction.
+  @ It is safe to use here though because we are about to return, and cpsr is
+  @ not expected to be preserved.
+  movs r0, #0@ return UNW_ESUCCESS
 #else
   @ 32bit thumb-2 restrictions for stm:
   @ . the sp (r13) cannot be in the list
   @ . the pc (r15) cannot be in the list in an STM instruction
   stm r0, {r0-r12}
   str sp, [r0, #52]
   str lr, [r0, #56]
   str lr, [r0, #60]  @ store return address as pc
-#endif
-#if __ARM_ARCH_ISA_THUMB == 1
-  @ T1 does not have a non-cpsr-clobbering register-zeroing instruction.
-  @ It is safe to use here though because we are about to return, and cpsr is
-  @ not expected to be preserved.
-  movs r0, #0@ return UNW_ESUCCESS
-#else
   mov r0, #0 @ return UNW_ESUCCESS
 #endif
   JMP(lr)


Index: libunwind/trunk/src/UnwindRegistersRestore.S
===
--- libunwind/trunk/src/UnwindRegistersRestore.S
+++ libunwind/trunk/src/UnwindRegistersRestore.S
@@ -322,9 +322,18 @@
 @
   .p2align 2
 DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind13Registers_arm20restoreCoreAndJumpToEv)
-#if !defined(__ARM_ARCH_ISA_ARM)
-  ldr r2, [r0, #52]
-  ldr r3, [r0, #60]
+#if !defined(__ARM_ARCH_ISA_ARM) && __ARM_ARCH_ISA_THUMB == 1
+  @ r8-r11: ldm into r1-r4, then mov to r8-r11
+  adds r0, #0x20
+  ldm r0!, {r1-r4}
+  subs r0, #0x30
+  mov r8, r1
+  mov r9, r2
+  mov r10, r3
+  mov r11, r4
+  @ r12 does not need loading, it it the intra-procedure-call scratch register
+  ldr r2, [r0, #0x34]
+  ldr r3, [r0, #0x3c]
   mov sp, r2
   mov lr, r3 @ restore pc into lr
   ldm r0, {r0-r7}
Index: libunwind/trunk/src/UnwindRegistersSave.S
===
--- libunwind/trunk/src/UnwindRegistersSave.S
+++ libunwind/trunk/src/UnwindRegistersSave.S
@@ -309,28 +309,32 @@
 @
   .p2align 2
 DEFINE_LIBUNWIND_FUNCTION(unw_getcontext)
-#if !defined(__ARM_ARCH_ISA_ARM)
-  stm r0, {r0-r7}
+#if !defined(__ARM_ARCH_ISA_ARM) && __ARM_ARCH_ISA_THUMB == 1
+  stm r0!, {r0-r7}
+  mov r1, r8
+  mov r2, r9
+  mov r3, r10
+  stm r0!, {r1-r3}
+  mov r1, r11
   mov r2, sp
   mov r3, lr
-  str r2, [r0, #52]
-  str r3, [r0, #56]
-  str r3, [r0, #60]  @ store return address as pc
+  str r1, [r0, #0]   @ r11
+  @ r12 does not need storing, it it the intra-procedure-call scratch register
+  str r2, [r0, #8]   @ sp
+  str r3, [r0, #12]  @ lr
+  str r3, [r0, #16]  @ store return address as pc
+  @ T1 does not have a non-cpsr-clobbering register-zeroing instruction.
+  @ It is safe to use here though because we are about to return, and cpsr is
+  @ not expected to be preserved.
+  movs r0, #0@ return UNW_ESUCCESS
 #else
   @ 32bit thumb-2 restrictions for stm:
   @ . the sp (r13) cannot be in the list
   @ . the pc (r15) cannot be in the list in an 

Re: [llvm-dev] [RFC] Embedded bitcode and related upstream (Part II)

[Jonas Devlieghere via cfe-commits]

Hi,

I hope I'm not breaking any mailing list etiquette by replying to this
mail, but if I am then please accept my apologies.

On Fri, Jun 3, 2016 at 8:36 PM, Steven Wu via llvm-dev
 wrote:
> Hi everyone
>
> I am still in the process of upstreaming some improvements to the embed
> bitcode option. If you want more background, you can read the previous RFC
> (http://lists.llvm.org/pipermail/llvm-dev/2016-February/094851.html). This
> is part II of the discussion.
>
> Current Status:
> A basic version of -fembed-bitcode option is upstreamed and functioning.
> You can use -fembed-bitcode={off, all, bitcode, marker} option to control
> what gets embedded in the final object file output:
> off: default, nothing gets embedded.
> all: optimized bitcode and command line options gets embedded in the object
> file.
> bitcode: only optimized bitcode is embedded
> marker: only put a marker in the object file
>
> What needs to be improved:
> 1. Whitelist for command line options that can be used with bitcode:
> Current trunk implementation embeds all the cc1 command line options (that
> includes header include paths, warning flags and other front-end options) in
> the command line section. That is lot of redundant information. To re-create
> the object file from the embedded optimized bitcode, most of these options
> are useless. On the other hand, they can leak information of the source
> code. One solution will be keeping a list of all the options that can affect
> code generation but not encoded in the bitcode. I have internally prototyped
> with disallowing these options explicitly and allowed only the reminder of
> the  options to be embedded (http://reviews.llvm.org/D17394). A better
> solution might be encoding that information in "Options.td" as specific
> group.
>
> 2. Assembly input handling:
> This is a workaround to allow source code written in assembly to work with
> "-fembed-bitcode" options. When compiling assembly source code with
> "-fembed-bitcode", clang-as creates an empty section "__LLVM, __asm" in the
> object file. That is just a way to distinguish object files compiled from
> assembly source from those compiled from higher level source code but forgot
> to use "-fembed-bitcode" options. Linker can use this section to diagnose if
> "-fembed-bitcode" is consistently used on all the object files participated
> in the linking.
>
> 3. Bitcode symbol hiding:
> There was some concerns for leaking source code information when using
> bitcode feature. One approach to avoid the leak is to add a pass which
> renames all the globals and metadata strings. The also keeps a reverse map
> in case the original name needs to be recovered. The final bitcode should
> contain no more symbols or debug info than a stripped binary. To make sure
> modified bitcode can still be linked correctly, the renaming need to be
> consistent across all bitcode participated in the linking and everything
> that is external of the linkage unit need to be preserved. This means the
> pass can only be run during the linking and requires some LTO api.

Regarding the symbol map, are you planning to upstream a pass that
restores the symbols? I have been trying to do this myself in order to
reverse the "BCSymbolMap". However this turned out to be less
straightforward than I'd hoped. Any info on this would be greatly
appreciated!

> 4. Debug info strip to line-tables pass:
> As the name suggested, this pass strip down the full debug info to
> line-tables only. This is also one of the steps we took to prevent the leak
> of source code information in bitcode.
>
> Please let me know what do you think about the pieces above or if you have
> any concerns about the methodology. I will put up patches for review soon.
>
> Thanks
>
> Steven
>
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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

Re: [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

[Vlad Dovlekaev via cfe-commits]

vladisld added a subscriber: vladisld.
vladisld added a comment.

Have the alternatives to sub-modules and monolithic repository been discussed ?

Sub-modules have their disadvantages as described in the following blog post: 
https://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/

In our org we're using git-repo framework (https://code.google.com/p/git-repo/) 
to manage our project's multiple repositories (which include both llvm/clang) 
and it works very well. This is the same framework google is using to maintain 
Android project (200+ repos) internally AFAIK.

IMHO, using git-repo is less restrictive then git sub-modules and also allows 
multiple,independent development flows.


https://reviews.llvm.org/D22463



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

Re: [PATCH] D22507: Clang-tidy - Enum misuse check

[Peter Szecsi via cfe-commits]

szepet updated this revision to Diff 65310.
szepet added a comment.

full diff submitted


https://reviews.llvm.org/D22507

Files:
  clang-tidy/misc/CMakeLists.txt
  clang-tidy/misc/EnumMisuseCheck.cpp
  clang-tidy/misc/EnumMisuseCheck.h
  clang-tidy/misc/MiscTidyModule.cpp
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/misc-enum-misuse.rst
  test/clang-tidy/misc-enum-misuse-weak.cpp
  test/clang-tidy/misc-enum-misuse.cpp

Index: test/clang-tidy/misc-enum-misuse.cpp
===
--- /dev/null
+++ test/clang-tidy/misc-enum-misuse.cpp
@@ -0,0 +1,81 @@
+// RUN: %check_clang_tidy %s misc-enum-misuse %t -- -config="{CheckOptions: [{key: misc-enum-misuse.IsStrict, value: 0}]}" --
+
+enum Empty {
+};
+
+enum A { A = 1,
+ B = 2,
+ C = 4,
+ D = 8,
+ E = 16,
+ F = 32,
+ G = 63
+};
+
+enum X { X = 8,
+ Y = 16,
+ Z = 4
+};
+
+enum { P = 2,
+   Q = 3,
+   R = 4,
+   S = 8,
+   T = 16
+};
+
+enum { H,
+   I,
+   J,
+   K,
+   L
+};
+
+enum Days { Monday,
+Tuesday,
+Wednesday,
+Thursday,
+Friday,
+Saturday,
+Sunday
+};
+
+Days bestDay() {
+  return Friday;
+}
+
+int trigger() {
+  if (bestDay() | A)
+return 1;
+  // CHECK-MESSAGES: :[[@LINE-2]]:17: warning: enum values are from different enum types [misc-enum-misuse]
+  if (I | Y)
+return 1;
+  // CHECK-MESSAGES: :[[@LINE-2]]:9: warning: enum values are from different enum types [misc-enum-misuse]
+  unsigned p;
+  p = Q | P;
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: left hand side value is not power-of-2 unlike most other values in the enum type [misc-enum-misuse]
+}
+
+int dont_trigger() {
+  if (A + G == E)
+return 1;
+  else if ((Q | R) == T)
+return 1;
+  else
+int k = T | Q;
+  return 0;
+  Empty EmptyVal;
+  int emptytest = EmptyVal | B;
+  int a = 1, b = 5;
+  int c = a + b;
+  int d = c | H, e = b * a;
+  a = B | C;
+  b = X | Z;
+  if (Tuesday != Monday + 1 ||
+  Friday - Thursday != 1 ||
+  Sunday + Wednesday == (Sunday | Wednesday))
+return 1;
+  if (H + I + L == 42)
+return 1;
+  return 42;
+}
Index: test/clang-tidy/misc-enum-misuse-weak.cpp
===
--- /dev/null
+++ test/clang-tidy/misc-enum-misuse-weak.cpp
@@ -0,0 +1,88 @@
+// RUN: %check_clang_tidy %s misc-enum-misuse %t -- -config="{CheckOptions: [{key: misc-enum-misuse.IsStrict, value: 1}]}" --
+
+enum A { A = 1,
+ B = 2,
+ C = 4,
+ D = 8,
+ E = 16,
+ F = 32,
+ G = 63
+};
+
+enum X { X = 8,
+ Y = 16,
+ Z = 4
+};
+// CHECK-MESSAGES: :[[@LINE+1]]:1: warning: enum type seems like a bitfield but possibly contains misspelled number(s) [misc-enum-misuse]
+enum PP { P = 2,
+  Q = 3,
+  R = 4,
+  S = 8,
+  T = 16,
+  U = 31
+};
+
+enum { H,
+   I,
+   J,
+   K,
+   L
+};
+
+enum Days { Monday,
+Tuesday,
+Wednesday,
+Thursday,
+Friday,
+Saturday,
+Sunday
+};
+
+Days bestDay() {
+  return Friday;
+}
+
+int trigger() {
+  if (bestDay() | A)
+return 1;
+  // CHECK-MESSAGES: :[[@LINE-2]]:17: warning: enum values are from different enum types [misc-enum-misuse]
+  if (I | Y)
+return 1;
+  // CHECK-MESSAGES: :[[@LINE-2]]:9: warning: enum values are from different enum types [misc-enum-misuse]
+  if (P + Q == R)
+return 1;
+  // CHECK-MESSAGES: :[[@LINE-2]]:11: warning: right hand side value is not power-of-2 unlike most other values in the enum type [misc-enum-misuse]
+  else if ((Q | R) == T)
+return 1;
+  // CHECK-MESSAGES: :[[@LINE-2]]:13: warning: left hand side value is not power-of-2 unlike most other values in the enum type [misc-enum-misuse]
+  else
+int k = T | Q;
+  // CHECK-MESSAGES: :[[@LINE-1]]:17: warning: right hand side value is not power-of-2 unlike most other values in the enum type [misc-enum-misuse]
+  unsigned p = R;
+  PP pp = Q;
+  p |= pp;
+  // Line 60 triggers the LINE:18 warning
+  p = A | G;
+  //p = G | X;
+  return 0;
+}
+
+int dont_trigger() {
+  int a = 1, b = 5;
+  int c = a + b;
+  int d = c | H, e = b * a;
+  a = B | C;
+  b = X | Z;
+
+  unsigned bitflag;
+  enum A aa = B;
+  bitflag = aa | C;
+
+  if (Tuesday != Monday + 1 ||
+  Friday - Thursday != 1 ||
+  Sunday + Wednesday == (Sunday | Wednesday))
+return 1;
+  if (H + I + L == 42)
+return 1;
+  return 42;
+}
Index: docs/clang-tidy/checks/misc-enum-misuse.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/misc-enum-misuse.rst
@@ -0,0 +1,66 @@
+.. title:: clang-tidy - misc-enum-misuse
+
+misc-enum-misuse
+
+
+The checker detects various cases when an enum is probably misused (as a bitfield).
+  1. Wh

Re: r276102 - [X86][SSE] Reimplement SSE fp2si conversion intrinsics instead of using generic IR

[Andrea Di Biagio via cfe-commits]

Hi Simon (and all),

I noticed that this patch changes the definition of intrinsic _mm_cvtsd2_ss
in emmintrin.h. Is that intentional? My understanding is that your patch
should have only addressed float-to-integer conversions.

Was this change to _mm_cvtsd_ss motivated by the fact that (V)CVTSD2SS
depends on the rounding mode (control bits in the MXCSR register) for
inexact conversions? That would explain why the LLVM part (r275981) also
added a codegen test for that double-to-float conversion (I guess that none
of the reviewer spotted that extra test).

The problem I am seeing is that your change is causing a crash in the
backend (at -O1 and above). See the reproducible below:

/
#include 

__m128 test(__m128 a, const __m128d &b) {
  return _mm_cvtsd_ss(a, b);
}
/

Alternatively, here is the LLVM IR:

define <4 x float> @test(<4 x float> %a, <2 x double>* nocapture readonly
%b) {
entry:
  %0 = load <2 x double>, <2 x double>* %b, align 16
  %1 = tail call <4 x float> @llvm.x86.sse2.cvtsd2ss(<4 x float> %a, <2 x
double> %0)
  ret <4 x float> %1
}

; Function Attrs: nounwind readnone
declare <4 x float> @llvm.x86.sse2.cvtsd2ss(<4 x float>, <2 x double>)



With your patch, we now always generate a call to @llvm.x86.sse2.cvtsd2ss
when expanding the builtin call from _mm_cvtsd_ss.

ISel would then select `Int_CVTSD2SSrm` instruction, which however is
`CodeGenOnly`. Unfortunately that pseudo is never further expanded/replaced
before compilation reaches the object emitter stage. So, before we execute
Pass 'X86 Assembly/Object Emitter' we see machine code like this:

BB#0: derived from LLVM BB %entry
Live Ins: %RDI %XMM0
%XMM0 = Int_VCVTSD2SSrm %XMM0, %RDI, 1, %noreg, 0,
%noreg; mem:LD16[%b]
RETQ %XMM0


.. which then causes  the following assertion failure:

[2016-07-25 13:25:11.830351700] 0x7bad5f87e0 Executing Pass 'X86
Assembly / Object Emitter' on Function 'test'...
Cannot encode all operands of:   >


Overall, I agree that the compiler shouldn't make assumptions on the
rounding mode when coverting from double-to-float. However, the RM variant
of Int_VCVTSD2SS doesn't seem to be correctly handled/expanded by the
backend.

Can we revert the change to the double-to-single convert? Alternatively,
can we fix the codegen issue exposed by this change (and add extra test
coverage)?
My opinion is that the change to the double-to-float conversion intrinsic
should have been part of a separate patch.


Thanks,
Andrea

On Fri, Jul 22, 2016 at 2:18 PM, Hans Wennborg via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Thu, Jul 21, 2016 at 6:34 PM, Robinson, Paul via cfe-commits
>  wrote:
> >
> >
> >> -Original Message-
> >> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On
> Behalf Of
> >> Simon Pilgrim via cfe-commits
> >> Sent: Wednesday, July 20, 2016 3:18 AM
> >> To: cfe-commits@lists.llvm.org
> >> Subject: r276102 - [X86][SSE] Reimplement SSE fp2si conversion
> intrinsics
> >> instead of using generic IR
> >>
> >> Author: rksimon
> >> Date: Wed Jul 20 05:18:01 2016
> >> New Revision: 276102
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=276102&view=rev
> >> Log:
> >> [X86][SSE] Reimplement SSE fp2si conversion intrinsics instead of using
> >> generic IR
> >>
> >> D20859 and D20860 attempted to replace the SSE (V)CVTTPS2DQ and
> VCVTTPD2DQ
> >> truncating conversions with generic IR instead.
> >>
> >> It turns out that the behaviour of these intrinsics is different enough
> >> from generic IR that this will cause problems, INF/NAN/out of range
> values
> >> are guaranteed to result in a 0x8000 value - which plays havoc with
> >> constant folding which converts them to either zero or UNDEF. This is
> also
> >> an issue with the scalar implementations (which were already generic IR
> >> and what I was trying to match).
> >
> > Are the problems enough that this should be merged to the 3.9 release
> branch?
> > --paulr
>
> IIUC, this is the Clang-side of r275981, and if we merge that this
> should probably be merged too.
>
> Thanks,
> Hans
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D22220: [clang-tidy] Add check 'misc-move-forwarding-reference'

[Alexander Kornienko via cfe-commits]

alexfh added a subscriber: alexfh.


Comment at: clang-tidy/misc/MoveForwardingReferenceCheck.cpp:36
@@ +35,3 @@
+(llvm::Twine("forward<") + TypeParmType->getDecl()->getName() +
+ llvm::Twine(">"))
+.str();

nit: The second `llvm::Twine` is not necessary.


Comment at: clang-tidy/misc/MoveForwardingReferenceCheck.cpp:43-53
@@ +42,13 @@
+// another namespace).
+const StringRef OriginalText =
+Lexer::getSourceText(CallRange, SM, LangOpts);
+if (OriginalText == "::std::move") {
+  Diag << FixItHint::CreateReplacement(CallRange, "::std::" + ForwardName);
+  // If the original text was simply "move", we conservatively still put a
+  // "std::" in front of the "forward". Rationale: Even if the code
+  // apparently had a "using std::move;", that doesn't tell us whether it
+  // also had a "using std::forward;".
+} else if (OriginalText == "std::move" || OriginalText == "move") {
+  Diag << FixItHint::CreateReplacement(CallRange, "std::" + ForwardName);
+}
+  }

aaron.ballman wrote:
> I'm not certain I understand the benefit to this. We know it's a call to 
> std::move() from the standard namespace already, so why do we care about the 
> original text? I think it's reasonable to replace any call to move() from the 
> standard namespace with `::std::forward()`, so we should be able to remove 
> the if statements and not have to go read the original source text from the 
> source manager (which could involve, for instance, a query for that text over 
> a slow network).
I think, the value of this is to maintain consistency with the existing code in 
terms of whether the `std` namespace should be globally qualified or not. 
Changing `std::move` to `::std::forward` would sometimes be unwelcome, if the 
code doesn't use `::std` otherwise.


Comment at: clang-tidy/misc/MoveForwardingReferenceCheck.cpp:60
@@ +59,3 @@
+  for (const auto &Decl : UnresolvedLookup->decls()) {
+const auto *TheFunctionTemplateDecl =
+dyn_cast(Decl->getUnderlyingDecl());

The variable name is rather uncommon for LLVM/Clang code (in particular, the 
`The` prefix). Maybe `FuncTemplateDecl`? Equally clear and somewhat shorter.


Comment at: clang-tidy/misc/MoveForwardingReferenceCheck.cpp:119
@@ +118,3 @@
+
+  auto Diag = diag(FileMoveRange.getBegin(),
+   "forwarding reference passed to std::move(); did you mean "

aaron.ballman wrote:
> Is there a reason why you can't just use `CallMove->getExprLoc()` instead of 
> toying with character ranges?
I think, `makeFileCharRange` is needed. It helps finding the correct macro 
expansion level to insert the replacement on. In case the range is not on the 
same macro expansion level, the condition on the line 116 will stop the check 
from introducing changes to the code that are more likely to break it.

The only change I would suggest is to only disable the fix-it and not the whole 
diagnostic in case unsupported macro usage is detected.


https://reviews.llvm.org/D0



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

Re: [PATCH] D20795: Added basic capabilities to detect source code clones.

[Artem Dergachev via cfe-commits]

NoQ added a comment.

The idea with strings as keys is curious! I've got a few more minor comments :)



Comment at: lib/Analysis/CloneDetection.cpp:104
@@ +103,3 @@
+// Storage for the signatures of the direct child statements. This is only
+// needed if the current statemnt is a CompoundStmt.
+std::vector ChildSignatures;

Typo: statement.


Comment at: lib/Analysis/CloneDetection.cpp:147
@@ +146,3 @@
+  const CompoundStmt *CS,
+  std::vector ChildSignatures) {
+

Maybe pass `ChildSignatures` by reference?


Comment at: lib/Analysis/CloneDetection.cpp:178
@@ +177,3 @@
+
+  bool VisitFunctionDecl(FunctionDecl *D) {
+// If we found a function, we start the clone search on its body statement.

You'd probably want to add `ObjCMethodDecl` and `BlockDecl`, because they 
aren't sub-classes of `FunctionDecl` (and probably even tests for that).

Because this part of the code essentially re-implements `AnalysisConsumer`, (a 
`RecursiveASTVisitor` that tells us what code bodies to analyze with the static 
analyzer - i should've looked there earlier!!).

Alternatively, you can just rely on `AnalysisConsumer`, which would eliminate 
the recursive visitor completely: {F2205103} This way you'd be analyzing 
exactly the same code bodies that the analyzer itself would analyze; if you'd 
want to extend to various declarations, you'd be able to do that by subscribing 
on `check::ASTDecl`. But i dare not to predict what kind of different 
flexibility you'd need next.


Comment at: lib/Analysis/CloneDetection.cpp:188
@@ +187,3 @@
+void CloneDetector::analyzeTranslationUnit(TranslationUnitDecl *TU) {
+  DataCollectVisitor visitor(*this, TU->getASTContext());
+  visitor.TraverseDecl(TU);

Micro-nit: Capitalize 'V' in 'visitor'?


https://reviews.llvm.org/D20795



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

Re: [PATCH] D19815: Support '#pragma once' in headers when using PCH

[Steve O'Brien via cfe-commits]

elsteveogrande added a comment.

Looks like I have the "accept" ability in this repo, wasn't sure since I just 
registered for this recently :)

I think since the tests look good, it's a nice and elegant 1-line change, per 
the reviewer's (@rsmith 's) comments, this should be ok to go.

This would help greatly on a project I'm working on, which has reams of 
auto-generated headers, so naturally I'm antsy to get this in trunk :)

@wristow, if this still lands cleanly against trunk (I see that this has been 
around a while) and test still pass, think this can be committed soon-ish?

Thanks!


https://reviews.llvm.org/D19815



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

Re: [PATCH] D21724: [RFC] Enhance synchscope representation (clang)

[Konstantin Zhuravlyov via cfe-commits]

kzhuravl updated this revision to Diff 65343.
kzhuravl added a comment.

Remove metadata generation


https://reviews.llvm.org/D21724

Files:
  lib/CodeGen/CGBuiltin.cpp

Index: lib/CodeGen/CGBuiltin.cpp
===
--- lib/CodeGen/CGBuiltin.cpp
+++ lib/CodeGen/CGBuiltin.cpp
@@ -1539,12 +1539,13 @@
   case Builtin::BI__atomic_signal_fence:
   case Builtin::BI__c11_atomic_thread_fence:
   case Builtin::BI__c11_atomic_signal_fence: {
-llvm::SynchronizationScope Scope;
+unsigned Scope;
 if (BuiltinID == Builtin::BI__atomic_signal_fence ||
-BuiltinID == Builtin::BI__c11_atomic_signal_fence)
-  Scope = llvm::SingleThread;
-else
-  Scope = llvm::CrossThread;
+BuiltinID == Builtin::BI__c11_atomic_signal_fence) {
+  Scope = llvm::SynchScope::SingleThread;
+} else {
+  Scope = llvm::SynchScope::System;
+}
 Value *Order = EmitScalarExpr(E->getArg(0));
 if (isa(Order)) {
   int ord = cast(Order)->getZExtValue();


Index: lib/CodeGen/CGBuiltin.cpp
===
--- lib/CodeGen/CGBuiltin.cpp
+++ lib/CodeGen/CGBuiltin.cpp
@@ -1539,12 +1539,13 @@
   case Builtin::BI__atomic_signal_fence:
   case Builtin::BI__c11_atomic_thread_fence:
   case Builtin::BI__c11_atomic_signal_fence: {
-llvm::SynchronizationScope Scope;
+unsigned Scope;
 if (BuiltinID == Builtin::BI__atomic_signal_fence ||
-BuiltinID == Builtin::BI__c11_atomic_signal_fence)
-  Scope = llvm::SingleThread;
-else
-  Scope = llvm::CrossThread;
+BuiltinID == Builtin::BI__c11_atomic_signal_fence) {
+  Scope = llvm::SynchScope::SingleThread;
+} else {
+  Scope = llvm::SynchScope::System;
+}
 Value *Order = EmitScalarExpr(E->getArg(0));
 if (isa(Order)) {
   int ord = cast(Order)->getZExtValue();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D22045: [X86] Support of no_caller_saved_registers attribute (Clang part)

[H.J Lu via cfe-commits]

hjl.tools added a comment.

no_caller_saved_registers attribute can be used with any calling conventions.


https://reviews.llvm.org/D22045



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

Re: [clang-tools-extra] r276408 - [clang-tidy] new cppcoreguidelines-slicing

[Alexander Kornienko via cfe-commits]

On Fri, Jul 22, 2016 at 2:42 PM, Clement Courbet via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: courbet
> Date: Fri Jul 22 07:42:19 2016
> New Revision: 276408
>
> URL: http://llvm.org/viewvc/llvm-project?rev=276408&view=rev
> Log:
> [clang-tidy] new cppcoreguidelines-slicing
>
> Flags slicing of member variables or vtable. See:
>
>
> https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es63-dont-slice
>
> https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c145-access-polymorphic-objects-through-pointers-and-references
>
> Differential revision:
> http://reviews.llvm.org/D21974


I guess, you meant https://reviews.llvm.org/D21992


>
> Added:
> clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/SlicingCheck.cpp
> clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/SlicingCheck.h
>
> clang-tools-extra/trunk/docs/clang-tidy/checks/cppcoreguidelines-slicing.rst
> clang-tools-extra/trunk/test/clang-tidy/cppcoreguidelines-slicing.cpp
> Modified:
> clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CMakeLists.txt
>
> clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
> clang-tools-extra/trunk/docs/ReleaseNotes.rst
>
> Modified:
> clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CMakeLists.txt
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CMakeLists.txt?rev=276408&r1=276407&r2=276408&view=diff
>
> ==
> --- clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CMakeLists.txt
> (original)
> +++ clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CMakeLists.txt
> Fri Jul 22 07:42:19 2016
> @@ -13,6 +13,7 @@ add_clang_library(clangTidyCppCoreGuidel
>ProTypeStaticCastDowncastCheck.cpp
>ProTypeUnionAccessCheck.cpp
>ProTypeVarargCheck.cpp
> +  SlicingCheck.cpp
>
>LINK_LIBS
>clangAST
>
> Modified:
> clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp?rev=276408&r1=276407&r2=276408&view=diff
>
> ==
> ---
> clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
> (original)
> +++
> clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
> Fri Jul 22 07:42:19 2016
> @@ -22,6 +22,7 @@
>  #include "ProTypeStaticCastDowncastCheck.h"
>  #include "ProTypeUnionAccessCheck.h"
>  #include "ProTypeVarargCheck.h"
> +#include "SlicingCheck.h"
>
>  namespace clang {
>  namespace tidy {
> @@ -53,6 +54,8 @@ public:
>  "cppcoreguidelines-pro-type-union-access");
>  CheckFactories.registerCheck(
>  "cppcoreguidelines-pro-type-vararg");
> +CheckFactories.registerCheck(
> +"cppcoreguidelines-slicing");
>  CheckFactories.registerCheck(
>  "cppcoreguidelines-c-copy-assignment-signature");
>}
>
> Added:
> clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/SlicingCheck.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/SlicingCheck.cpp?rev=276408&view=auto
>
> ==
> --- clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/SlicingCheck.cpp
> (added)
> +++ clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/SlicingCheck.cpp
> Fri Jul 22 07:42:19 2016
> @@ -0,0 +1,135 @@
> +//===--- SlicingCheck.cpp -
> clang-tidy-===//
> +//
> +// The LLVM Compiler Infrastructure
> +//
> +// This file is distributed under the University of Illinois Open Source
> +// License. See LICENSE.TXT for details.
> +//
>
> +//===--===//
> +
> +#include "SlicingCheck.h"
> +#include "clang/AST/ASTContext.h"
> +#include "clang/AST/RecordLayout.h"
> +#include "clang/ASTMatchers/ASTMatchFinder.h"
> +#include "clang/ASTMatchers/ASTMatchers.h"
> +
> +using namespace clang::ast_matchers;
> +
> +namespace clang {
> +namespace tidy {
> +namespace cppcoreguidelines {
> +
> +void SlicingCheck::registerMatchers(MatchFinder *Finder) {
> +  // When we see:
> +  //   class B : public A { ... };
> +  //   A a;
> +  //   B b;
> +  //   a = b;
> +  // The assignment is OK if:
> +  //   - the assignment operator is defined as taking a B as second
> parameter,
> +  //   or
> +  //   - B does not define any additional members (either variables or
> +  //   overrides) wrt A.
> +  //
> +  // The same holds for copy ctor calls. This also captures stuff like:
> +  //   void f(A a);
> +  //   f(b);
> +
> +  //  Helpers.
> +  const auto OfBaseClass = ofClass(cxxRecordDecl().bind("BaseDecl"));
> +  const auto IsDerivedFromBaseDecl =
> +  

Re: [PATCH] D22045: [X86] Support of no_caller_saved_registers attribute (Clang part)

[Aaron Ballman via cfe-commits]

On Mon, Jul 25, 2016 at 11:15 AM, H.J Lu  wrote:
> hjl.tools added a comment.
>
> no_caller_saved_registers attribute can be used with any calling conventions.

Okay, so is it expected that use of this attribute through a function
pointer is not going to produce the same results as calling the
function directly? e.g.,

void func(int, int, int, int) __attribute__((no_caller_saved_registers, cdecl));

int main() {
  void (*fp)(int, int, int, int) __attribute__((cdecl)) = func;
  func(1, 2, 3, 4);
  fp(1, 2, 3, 4); // Not the same as the above call to func()?
}

~Aaron

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

r276639 - MPI-Checker: move MPIFunctionClassifier.h

[Alexander Kornienko via cfe-commits]

Author: alexfh
Date: Mon Jul 25 10:27:16 2016
New Revision: 276639

URL: http://llvm.org/viewvc/llvm-project?rev=276639&view=rev
Log:
MPI-Checker: move  MPIFunctionClassifier.h

Summary:
This patch moves the MPIFunctionClassifier header to 
`clang/include/clang/StaticAnalyzer/Checkers`,
in order to make it accessible in other parts of the architecture.

Reviewers: dcoughlin, zaks.anna

Subscribers: alexfh, cfe-commits

Patch by Alexander Droste!

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

Added:
cfe/trunk/include/clang/StaticAnalyzer/Checkers/MPIFunctionClassifier.h
  - copied, changed from r276618, 
cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIFunctionClassifier.h
Removed:
cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIFunctionClassifier.h
Modified:
cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIChecker.cpp
cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIChecker.h
cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIFunctionClassifier.cpp
cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPITypes.h

Copied: cfe/trunk/include/clang/StaticAnalyzer/Checkers/MPIFunctionClassifier.h 
(from r276618, 
cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIFunctionClassifier.h)
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Checkers/MPIFunctionClassifier.h?p2=cfe/trunk/include/clang/StaticAnalyzer/Checkers/MPIFunctionClassifier.h&p1=cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIFunctionClassifier.h&r1=276618&r2=276639&rev=276639&view=diff
==
(empty)

Modified: cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIChecker.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIChecker.cpp?rev=276639&r1=276638&r2=276639&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIChecker.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIChecker.cpp Mon Jul 25 
10:27:16 2016
@@ -43,7 +43,8 @@ void MPIChecker::checkDoubleNonblocking(
   // double nonblocking detected
   if (Req && Req->CurrentState == Request::State::Nonblocking) {
 ExplodedNode *ErrorNode = Ctx.generateNonFatalErrorNode();
-BReporter.reportDoubleNonblocking(PreCallEvent, *Req, MR, ErrorNode, 
Ctx.getBugReporter());
+BReporter.reportDoubleNonblocking(PreCallEvent, *Req, MR, ErrorNode,
+  Ctx.getBugReporter());
 Ctx.addTransition(ErrorNode->getState(), ErrorNode);
   }
   // no error
@@ -85,7 +86,8 @@ void MPIChecker::checkUnmatchedWaits(con
 State = ErrorNode->getState();
   }
   // A wait has no matching nonblocking call.
-  BReporter.reportUnmatchedWait(PreCallEvent, ReqRegion, ErrorNode, 
Ctx.getBugReporter());
+  BReporter.reportUnmatchedWait(PreCallEvent, ReqRegion, ErrorNode,
+Ctx.getBugReporter());
 }
   }
 
@@ -118,7 +120,8 @@ void MPIChecker::checkMissingWaits(Symbo
   ErrorNode = Ctx.generateNonFatalErrorNode(State, &Tag);
   State = ErrorNode->getState();
 }
-BReporter.reportMissingWait(Req.second, Req.first, ErrorNode, 
Ctx.getBugReporter());
+BReporter.reportMissingWait(Req.second, Req.first, ErrorNode,
+Ctx.getBugReporter());
   }
   State = State->remove(Req.first);
 }

Modified: cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIChecker.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIChecker.h?rev=276639&r1=276638&r2=276639&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIChecker.h (original)
+++ cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIChecker.h Mon Jul 25 
10:27:16 2016
@@ -19,8 +19,8 @@
 #define LLVM_CLANG_LIB_STATICANALYZER_CHECKERS_MPICHECKER_MPICHECKER_H
 
 #include "MPIBugReporter.h"
-#include "MPIFunctionClassifier.h"
 #include "MPITypes.h"
+#include "clang/StaticAnalyzer/Checkers/MPIFunctionClassifier.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h"
 
@@ -30,7 +30,7 @@ namespace mpi {
 
 class MPIChecker : public Checker {
 public:
-  MPIChecker() : BReporter(*this) { }
+  MPIChecker() : BReporter(*this) {}
 
   // path-sensitive callbacks
   void checkPreCall(const CallEvent &CE, CheckerContext &Ctx) const {
@@ -49,7 +49,6 @@ public:
   return;
 const_cast &>(FuncClassifier)
 .reset(new MPIFunctionClassifier{Ctx.getASTContext()});
-
   }
 
   /// Checks if a request is used by nonblocking calls multiple times

Modified: 
cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIFunctionClassifier.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cf

Re: [PATCH] D22671: MPI-Checker: move MPIFunctionClassifier.h

[Alexander Kornienko via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL276639: MPI-Checker: move  MPIFunctionClassifier.h (authored 
by alexfh).

Changed prior to commit:
  https://reviews.llvm.org/D22671?vs=65050&id=65348#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D22671

Files:
  cfe/trunk/include/clang/StaticAnalyzer/Checkers/MPIFunctionClassifier.h
  cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIChecker.cpp
  cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIChecker.h
  cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIFunctionClassifier.cpp
  cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIFunctionClassifier.h
  cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPITypes.h

Index: cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIFunctionClassifier.cpp
===
--- cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIFunctionClassifier.cpp
+++ cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIFunctionClassifier.cpp
@@ -12,7 +12,7 @@
 ///
 //===--===//
 
-#include "MPIFunctionClassifier.h"
+#include "clang/StaticAnalyzer/Checkers/MPIFunctionClassifier.h"
 #include "llvm/ADT/STLExtras.h"
 
 namespace clang {
Index: cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPITypes.h
===
--- cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPITypes.h
+++ cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPITypes.h
@@ -17,7 +17,7 @@
 #ifndef LLVM_CLANG_LIB_STATICANALYZER_CHECKERS_MPICHECKER_MPITYPES_H
 #define LLVM_CLANG_LIB_STATICANALYZER_CHECKERS_MPICHECKER_MPITYPES_H
 
-#include "MPIFunctionClassifier.h"
+#include "clang/StaticAnalyzer/Checkers/MPIFunctionClassifier.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h"
 #include "llvm/ADT/SmallSet.h"
 
@@ -53,7 +53,6 @@
 
 } // end of namespace: mpi
 
-
 template <>
 struct ProgramStateTrait
 : public ProgramStatePartialTrait {
Index: cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIChecker.h
===
--- cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIChecker.h
+++ cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIChecker.h
@@ -19,8 +19,8 @@
 #define LLVM_CLANG_LIB_STATICANALYZER_CHECKERS_MPICHECKER_MPICHECKER_H
 
 #include "MPIBugReporter.h"
-#include "MPIFunctionClassifier.h"
 #include "MPITypes.h"
+#include "clang/StaticAnalyzer/Checkers/MPIFunctionClassifier.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h"
 
@@ -30,7 +30,7 @@
 
 class MPIChecker : public Checker {
 public:
-  MPIChecker() : BReporter(*this) { }
+  MPIChecker() : BReporter(*this) {}
 
   // path-sensitive callbacks
   void checkPreCall(const CallEvent &CE, CheckerContext &Ctx) const {
@@ -49,7 +49,6 @@
   return;
 const_cast &>(FuncClassifier)
 .reset(new MPIFunctionClassifier{Ctx.getASTContext()});
-
   }
 
   /// Checks if a request is used by nonblocking calls multiple times
Index: cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIChecker.cpp
===
--- cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIChecker.cpp
+++ cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIChecker.cpp
@@ -43,7 +43,8 @@
   // double nonblocking detected
   if (Req && Req->CurrentState == Request::State::Nonblocking) {
 ExplodedNode *ErrorNode = Ctx.generateNonFatalErrorNode();
-BReporter.reportDoubleNonblocking(PreCallEvent, *Req, MR, ErrorNode, Ctx.getBugReporter());
+BReporter.reportDoubleNonblocking(PreCallEvent, *Req, MR, ErrorNode,
+  Ctx.getBugReporter());
 Ctx.addTransition(ErrorNode->getState(), ErrorNode);
   }
   // no error
@@ -85,7 +86,8 @@
 State = ErrorNode->getState();
   }
   // A wait has no matching nonblocking call.
-  BReporter.reportUnmatchedWait(PreCallEvent, ReqRegion, ErrorNode, Ctx.getBugReporter());
+  BReporter.reportUnmatchedWait(PreCallEvent, ReqRegion, ErrorNode,
+Ctx.getBugReporter());
 }
   }
 
@@ -118,7 +120,8 @@
   ErrorNode = Ctx.generateNonFatalErrorNode(State, &Tag);
   State = ErrorNode->getState();
 }
-BReporter.reportMissingWait(Req.second, Req.first, ErrorNode, Ctx.getBugReporter());
+BReporter.reportMissingWait(Req.second, Req.first, ErrorNode,
+Ctx.getBugReporter());
   }
   State = State->remove(Req.first);
 }
Index: cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIFunctionClassifier.h
===
--- cfe/trunk/lib/StaticAnalyzer/Checkers/MPI-Checker/MPIFunctionClassifier.h
+++ cfe/trunk/lib/StaticAnalyzer/Che

Re: [PATCH] D22507: Clang-tidy - Enum misuse check

[Etienne Bergeron via cfe-commits]

etienneb added a comment.

some nits



Comment at: docs/clang-tidy/checks/misc-enum-misuse.rst:37
@@ +36,3 @@
+unsigned flag;
+flag = A | H; //OK, disjoint value intervalls in the enum types > probably 
good use
+flag = B | F; //warning, have common values so they are probably misused

nit: space after //
here and below.


Comment at: docs/clang-tidy/checks/misc-enum-misuse.rst:37
@@ +36,3 @@
+unsigned flag;
+flag = A | H; //OK, disjoint value intervalls in the enum types > probably 
good use
+flag = B | F; //warning, have common values so they are probably misused

etienneb wrote:
> nit: space after //
> here and below.
nit: intervalls (typo)


Comment at: test/clang-tidy/misc-enum-misuse-weak.cpp:48
@@ +47,3 @@
+return 1;
+  // CHECK-MESSAGES: :[[@LINE-2]]:17: warning: enum values are from different 
enum types [misc-enum-misuse]
+  if (I | Y)

you can remove "[misc-enum-misuse]" from the following line.
Only the first occurrence is enough.


https://reviews.llvm.org/D22507



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

[clang-tools-extra] r276641 - Remove trailing spaces.

[Alexander Kornienko via cfe-commits]

Author: alexfh
Date: Mon Jul 25 10:43:22 2016
New Revision: 276641

URL: http://llvm.org/viewvc/llvm-project?rev=276641&view=rev
Log:
Remove trailing spaces.

Modified:
clang-tools-extra/trunk/test/clang-tidy/mpi-type-mismatch.cpp

Modified: clang-tools-extra/trunk/test/clang-tidy/mpi-type-mismatch.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/mpi-type-mismatch.cpp?rev=276641&r1=276640&r2=276641&view=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/mpi-type-mismatch.cpp (original)
+++ clang-tools-extra/trunk/test/clang-tidy/mpi-type-mismatch.cpp Mon Jul 25 
10:43:22 2016
@@ -6,11 +6,11 @@ void charNegativeTest() {
   unsigned char buf;
   MPI_Send(&buf, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'unsigned char' 
does not match the MPI datatype 'MPI_CHAR' [mpi-type-mismatch]
-  
+
   int buf2;
   MPI_Send(&buf2, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'int' does not 
match the MPI datatype 'MPI_CHAR'
-  
+
   short buf3;
   MPI_Send(&buf3, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'short' does not 
match the MPI datatype 'MPI_CHAR'
@@ -18,7 +18,7 @@ void charNegativeTest() {
   long buf4;
   MPI_Send(&buf4, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'long' does not 
match the MPI datatype 'MPI_CHAR'
-  
+
   int8_t buf5;
   MPI_Send(&buf5, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'int8_t' does not 
match the MPI datatype 'MPI_CHAR'
@@ -40,11 +40,11 @@ void intNegativeTest() {
   unsigned char buf;
   MPI_Send(&buf, 1, MPI_INT, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'unsigned char' 
does not match the MPI datatype 'MPI_INT'
-  
+
   unsigned buf2;
   MPI_Send(&buf2, 1, MPI_INT, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'unsigned int' does 
not match the MPI datatype 'MPI_INT'
-  
+
   short buf3;
   MPI_Send(&buf3, 1, MPI_INT, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'short' does not 
match the MPI datatype 'MPI_INT'
@@ -52,7 +52,7 @@ void intNegativeTest() {
   long buf4;
   MPI_Send(&buf4, 1, MPI_INT, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'long' does not 
match the MPI datatype 'MPI_INT'
-  
+
   int8_t buf5;
   MPI_Send(&buf5, 1, MPI_INT, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'int8_t' does not 
match the MPI datatype 'MPI_INT'
@@ -74,11 +74,11 @@ void longNegativeTest() {
   char buf;
   MPI_Send(&buf, 1, MPI_LONG, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'char' does not 
match the MPI datatype 'MPI_LONG'
-  
+
   unsigned buf2;
   MPI_Send(&buf2, 1, MPI_LONG, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'unsigned int' does 
not match the MPI datatype 'MPI_LONG'
-  
+
   unsigned short buf3;
   MPI_Send(&buf3, 1, MPI_LONG, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'unsigned short' 
does not match the MPI datatype 'MPI_LONG'
@@ -86,7 +86,7 @@ void longNegativeTest() {
   unsigned long buf4;
   MPI_Send(&buf4, 1, MPI_LONG, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'unsigned long' 
does not match the MPI datatype 'MPI_LONG'
-  
+
   int8_t buf5;
   MPI_Send(&buf5, 1, MPI_LONG, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'int8_t' does not 
match the MPI datatype 'MPI_LONG'
@@ -108,11 +108,11 @@ void int8_tNegativeTest() {
   char buf;
   MPI_Send(&buf, 1, MPI_INT8_T, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'char' does not 
match the MPI datatype 'MPI_INT8_T'
-  
+
   unsigned buf2;
   MPI_Send(&buf2, 1, MPI_INT8_T, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'unsigned int' does 
not match the MPI datatype 'MPI_INT8_T'
-  
+
   short buf3;
   MPI_Send(&buf3, 1, MPI_INT8_T, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'short' does not 
match the MPI datatype 'MPI_INT8_T'
@@ -120,7 +120,7 @@ void int8_tNegativeTest() {
   unsigned long buf4;
   MPI_Send(&buf4, 1, MPI_INT8_T, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'unsigned long' 
does not match the MPI datatype 'MPI_INT8_T'
-  
+
   uint8_t buf5;
   MPI_Send(&buf5, 1, MPI_INT8_T, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'uint8_t' does not 
match the MPI datatype 'MPI_INT8_T'
@@ -142,11 +142,11 @@ void complex_c_long_double_complexNegati
   char buf;
   MPI_Send(&b

[clang-tools-extra] r276640 - MPITypeMismatchCheck for Clang-Tidy

[Alexander Kornienko via cfe-commits]

Author: alexfh
Date: Mon Jul 25 10:43:14 2016
New Revision: 276640

URL: http://llvm.org/viewvc/llvm-project?rev=276640&view=rev
Log:
MPITypeMismatchCheck for Clang-Tidy

Summary:
This check verifies if buffer type and MPI (Message Passing Interface)
datatype pairs match. All MPI datatypes defined by the MPI standard (3.1)
are verified by this check. User defined typedefs, custom MPI datatypes and
null pointer constants are skipped, in the course of verification.

Instructions on how to apply the check can be found at: 
https://github.com/0ax1/MPI-Checker/tree/master/examples

Reviewers: alexfh

Subscribers: cfe-commits

Projects: #clang-tools-extra

Patch by Alexander Droste!

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

Added:
clang-tools-extra/trunk/clang-tidy/mpi/
clang-tools-extra/trunk/clang-tidy/mpi/CMakeLists.txt
clang-tools-extra/trunk/clang-tidy/mpi/MPITidyModule.cpp
clang-tools-extra/trunk/clang-tidy/mpi/TypeMismatchCheck.cpp
clang-tools-extra/trunk/clang-tidy/mpi/TypeMismatchCheck.h
clang-tools-extra/trunk/docs/clang-tidy/checks/mpi-type-mismatch.rst
clang-tools-extra/trunk/test/clang-tidy/Inputs/mpi-type-mismatch/
clang-tools-extra/trunk/test/clang-tidy/Inputs/mpi-type-mismatch/mpimock.h
clang-tools-extra/trunk/test/clang-tidy/mpi-type-mismatch.cpp
Modified:
clang-tools-extra/trunk/clang-tidy/CMakeLists.txt
clang-tools-extra/trunk/clang-tidy/plugin/CMakeLists.txt
clang-tools-extra/trunk/clang-tidy/tool/CMakeLists.txt
clang-tools-extra/trunk/clang-tidy/tool/ClangTidyMain.cpp
clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst

Modified: clang-tools-extra/trunk/clang-tidy/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/CMakeLists.txt?rev=276640&r1=276639&r2=276640&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clang-tidy/CMakeLists.txt Mon Jul 25 10:43:14 2016
@@ -34,6 +34,7 @@ add_subdirectory(cppcoreguidelines)
 add_subdirectory(google)
 add_subdirectory(misc)
 add_subdirectory(modernize)
+add_subdirectory(mpi)
 add_subdirectory(performance)
 add_subdirectory(readability)
 add_subdirectory(utils)

Added: clang-tools-extra/trunk/clang-tidy/mpi/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/mpi/CMakeLists.txt?rev=276640&view=auto
==
--- clang-tools-extra/trunk/clang-tidy/mpi/CMakeLists.txt (added)
+++ clang-tools-extra/trunk/clang-tidy/mpi/CMakeLists.txt Mon Jul 25 10:43:14 
2016
@@ -0,0 +1,15 @@
+set(LLVM_LINK_COMPONENTS support)
+
+add_clang_library(clangTidyMPIModule
+  MPITidyModule.cpp
+  TypeMismatchCheck.cpp
+
+  LINK_LIBS
+  clangAST
+  clangASTMatchers
+  clangBasic
+  clangLex
+  clangTidy
+  clangTidyUtils
+  clangTooling
+  )

Added: clang-tools-extra/trunk/clang-tidy/mpi/MPITidyModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/mpi/MPITidyModule.cpp?rev=276640&view=auto
==
--- clang-tools-extra/trunk/clang-tidy/mpi/MPITidyModule.cpp (added)
+++ clang-tools-extra/trunk/clang-tidy/mpi/MPITidyModule.cpp Mon Jul 25 
10:43:14 2016
@@ -0,0 +1,37 @@
+//===--- MPITidyModule.cpp - clang-tidy 
---===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "../ClangTidy.h"
+#include "../ClangTidyModule.h"
+#include "../ClangTidyModuleRegistry.h"
+#include "TypeMismatchCheck.h"
+
+namespace clang {
+namespace tidy {
+namespace mpi {
+
+class MPIModule : public ClangTidyModule {
+public:
+  void addCheckFactories(ClangTidyCheckFactories &CheckFactories) override {
+CheckFactories.registerCheck("mpi-type-mismatch");
+  }
+};
+
+} // namespace mpi
+
+// Register the MPITidyModule using this statically initialized variable.
+static ClangTidyModuleRegistry::Add
+X("mpi-module", "Adds MPI clang-tidy checks.");
+
+// This anchor is used to force the linker to link in the generated object file
+// and thus register the MPIModule.
+volatile int MPIModuleAnchorSource = 0;
+
+} // namespace tidy
+} // namespace clang

Added: clang-tools-extra/trunk/clang-tidy/mpi/TypeMismatchCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/mpi/TypeMismatchCheck.cpp?rev=276640&view=auto
==
--- clang-tools-extra/trunk/clang-tidy/mpi/TypeMismatchCheck.cpp (added)
+++ clang-tools-extra/trunk/clang-tidy/mpi/TypeMismatchCheck.cpp Mon Jul 25 
10:43:14 2016
@@ -0,0 +1,328 @@
+//===--

Re: [PATCH] D21962: MPITypeMismatchCheck for Clang-Tidy

[Alexander Kornienko via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL276640: MPITypeMismatchCheck for Clang-Tidy (authored by 
alexfh).

Changed prior to commit:
  https://reviews.llvm.org/D21962?vs=65222&id=65351#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D21962

Files:
  clang-tools-extra/trunk/clang-tidy/CMakeLists.txt
  clang-tools-extra/trunk/clang-tidy/mpi/CMakeLists.txt
  clang-tools-extra/trunk/clang-tidy/mpi/MPITidyModule.cpp
  clang-tools-extra/trunk/clang-tidy/mpi/TypeMismatchCheck.cpp
  clang-tools-extra/trunk/clang-tidy/mpi/TypeMismatchCheck.h
  clang-tools-extra/trunk/clang-tidy/plugin/CMakeLists.txt
  clang-tools-extra/trunk/clang-tidy/tool/CMakeLists.txt
  clang-tools-extra/trunk/clang-tidy/tool/ClangTidyMain.cpp
  clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst
  clang-tools-extra/trunk/docs/clang-tidy/checks/mpi-type-mismatch.rst
  clang-tools-extra/trunk/test/clang-tidy/Inputs/mpi-type-mismatch/mpimock.h
  clang-tools-extra/trunk/test/clang-tidy/mpi-type-mismatch.cpp

Index: clang-tools-extra/trunk/clang-tidy/mpi/TypeMismatchCheck.cpp
===
--- clang-tools-extra/trunk/clang-tidy/mpi/TypeMismatchCheck.cpp
+++ clang-tools-extra/trunk/clang-tidy/mpi/TypeMismatchCheck.cpp
@@ -0,0 +1,328 @@
+//===--- TypeMismatchCheck.cpp - clang-tidy===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "TypeMismatchCheck.h"
+#include "clang/StaticAnalyzer/Checkers/MPIFunctionClassifier.h"
+#include "clang/Lex/Lexer.h"
+#include "clang/Tooling/FixIt.h"
+#include 
+#include 
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+namespace mpi {
+
+/// Check if a BuiltinType::Kind matches the MPI datatype.
+///
+/// \param MultiMap datatype group
+/// \param Kind buffer type kind
+/// \param MPIDatatype name of the MPI datatype
+///
+/// \returns true if the pair matches
+static bool
+isMPITypeMatching(const std::multimap &MultiMap,
+  const BuiltinType::Kind Kind,
+  const std::string &MPIDatatype) {
+  auto ItPair = MultiMap.equal_range(Kind);
+  while (ItPair.first != ItPair.second) {
+if (ItPair.first->second == MPIDatatype)
+  return true;
+++ItPair.first;
+  }
+  return false;
+}
+
+/// Check if the MPI datatype is a standard type.
+///
+/// \param MPIDatatype name of the MPI datatype
+///
+/// \returns true if the type is a standard type
+static bool isStandardMPIDatatype(const std::string &MPIDatatype) {
+  static std::unordered_set AllTypes = {
+  "MPI_C_BOOL",
+  "MPI_CHAR",
+  "MPI_SIGNED_CHAR",
+  "MPI_UNSIGNED_CHAR",
+  "MPI_WCHAR",
+  "MPI_INT",
+  "MPI_LONG",
+  "MPI_SHORT",
+  "MPI_LONG_LONG",
+  "MPI_LONG_LONG_INT",
+  "MPI_UNSIGNED",
+  "MPI_UNSIGNED_SHORT",
+  "MPI_UNSIGNED_LONG",
+  "MPI_UNSIGNED_LONG_LONG",
+  "MPI_FLOAT",
+  "MPI_DOUBLE",
+  "MPI_LONG_DOUBLE",
+  "MPI_C_COMPLEX",
+  "MPI_C_FLOAT_COMPLEX",
+  "MPI_C_DOUBLE_COMPLEX",
+  "MPI_C_LONG_DOUBLE_COMPLEX",
+  "MPI_INT8_T",
+  "MPI_INT16_T",
+  "MPI_INT32_T",
+  "MPI_INT64_T",
+  "MPI_UINT8_T",
+  "MPI_UINT16_T",
+  "MPI_UINT32_T",
+  "MPI_UINT64_T",
+  "MPI_CXX_BOOL",
+  "MPI_CXX_FLOAT_COMPLEX",
+  "MPI_CXX_DOUBLE_COMPLEX",
+  "MPI_CXX_LONG_DOUBLE_COMPLEX"};
+
+  return AllTypes.find(MPIDatatype) != AllTypes.end();
+}
+
+/// Check if a BuiltinType matches the MPI datatype.
+///
+/// \param Builtin the builtin type
+/// \param BufferTypeName buffer type name, gets assigned
+/// \param MPIDatatype name of the MPI datatype
+/// \param LO language options
+///
+/// \returns true if the type matches
+static bool isBuiltinTypeMatching(const BuiltinType *Builtin,
+  std::string &BufferTypeName,
+  const std::string &MPIDatatype,
+  const LangOptions &LO) {
+  static std::multimap BuiltinMatches = {
+  {BuiltinType::SChar, "MPI_CHAR"},
+  {BuiltinType::SChar, "MPI_SIGNED_CHAR"},
+  {BuiltinType::Char_S, "MPI_CHAR"},
+  {BuiltinType::Char_S, "MPI_SIGNED_CHAR"},
+  {BuiltinType::UChar, "MPI_UNSIGNED_CHAR"},
+  {BuiltinType::Char_U, "MPI_UNSIGNED_CHAR"},
+  {BuiltinType::WChar_S, "MPI_WCHAR"},
+  {BuiltinType::WChar_U, "MPI_WCHAR"},
+  {BuiltinType::Bool, "MPI_C_BOOL"},
+  {BuiltinType::Bool, "MPI_CXX_BOOL"},
+  {BuiltinType::Short, "MPI_SHORT"},
+  {BuiltinType::Int, "MPI_INT"},
+  {BuiltinType::Long, "MPI_LONG"},
+  {BuiltinType::LongLong, "MPI_LONG_LONG"},
+  {BuiltinType::LongLong, "MPI_LONG_LONG_INT"},
+  {BuiltinType::UShor

Re: [PATCH] D22507: Clang-tidy - Enum misuse check

[Piotr Padlewski via cfe-commits]

Prazek added a subscriber: Prazek.


Comment at: clang-tidy/misc/EnumMisuseCheck.cpp:19
@@ +18,3 @@
+
+// Stores a min and a max value which describe an interval.
+struct ValueRange {

s/\/\//\/\/\/

In other words, change // to /// (doxygen comment)


Comment at: clang-tidy/misc/EnumMisuseCheck.cpp:192
@@ +191,3 @@
+  const auto *LhsConstant =
+  LhsDecExpr ? dyn_cast(LhsDecExpr->getDecl()) : nullptr;
+  const auto *RhsConstant =

If the pointer returned from dyn_cast(LhsDeclExpr->getDecl()) 
is assumed to be always not null, thn you can change it to cast<> (It will 
assert if null instead of returning nullptr)


Comment at: docs/clang-tidy/checks/misc-enum-misuse.rst:29
@@ +28,3 @@
+
+.. code:: c++
+

I think all the code here needs to be indented by one or more to get into 
..code:: block.


https://reviews.llvm.org/D22507



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

Re: [PATCH] D22227: [ubsan] Disable bounds-check for flexible array ivars

[Vedant Kumar via cfe-commits]

vsk added a comment.

Ping.


https://reviews.llvm.org/D7



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

Re: [llvm-dev] [RFC] Embedded bitcode and related upstream (Part II)

[Steven Wu via cfe-commits]

> On Jul 25, 2016, at 3:24 AM, Jonas Devlieghere  wrote:
> 
> Hi,
> 
> I hope I'm not breaking any mailing list etiquette by replying to this
> mail, but if I am then please accept my apologies.
> 
> On Fri, Jun 3, 2016 at 8:36 PM, Steven Wu via llvm-dev
>  wrote:
>> Hi everyone
>> 
>> I am still in the process of upstreaming some improvements to the embed
>> bitcode option. If you want more background, you can read the previous RFC
>> (http://lists.llvm.org/pipermail/llvm-dev/2016-February/094851.html). This
>> is part II of the discussion.
>> 
>> Current Status:
>> A basic version of -fembed-bitcode option is upstreamed and functioning.
>> You can use -fembed-bitcode={off, all, bitcode, marker} option to control
>> what gets embedded in the final object file output:
>> off: default, nothing gets embedded.
>> all: optimized bitcode and command line options gets embedded in the object
>> file.
>> bitcode: only optimized bitcode is embedded
>> marker: only put a marker in the object file
>> 
>> What needs to be improved:
>> 1. Whitelist for command line options that can be used with bitcode:
>> Current trunk implementation embeds all the cc1 command line options (that
>> includes header include paths, warning flags and other front-end options) in
>> the command line section. That is lot of redundant information. To re-create
>> the object file from the embedded optimized bitcode, most of these options
>> are useless. On the other hand, they can leak information of the source
>> code. One solution will be keeping a list of all the options that can affect
>> code generation but not encoded in the bitcode. I have internally prototyped
>> with disallowing these options explicitly and allowed only the reminder of
>> the  options to be embedded (http://reviews.llvm.org/D17394). A better
>> solution might be encoding that information in "Options.td" as specific
>> group.
>> 
>> 2. Assembly input handling:
>> This is a workaround to allow source code written in assembly to work with
>> "-fembed-bitcode" options. When compiling assembly source code with
>> "-fembed-bitcode", clang-as creates an empty section "__LLVM, __asm" in the
>> object file. That is just a way to distinguish object files compiled from
>> assembly source from those compiled from higher level source code but forgot
>> to use "-fembed-bitcode" options. Linker can use this section to diagnose if
>> "-fembed-bitcode" is consistently used on all the object files participated
>> in the linking.
>> 
>> 3. Bitcode symbol hiding:
>> There was some concerns for leaking source code information when using
>> bitcode feature. One approach to avoid the leak is to add a pass which
>> renames all the globals and metadata strings. The also keeps a reverse map
>> in case the original name needs to be recovered. The final bitcode should
>> contain no more symbols or debug info than a stripped binary. To make sure
>> modified bitcode can still be linked correctly, the renaming need to be
>> consistent across all bitcode participated in the linking and everything
>> that is external of the linkage unit need to be preserved. This means the
>> pass can only be run during the linking and requires some LTO api.
> 
> Regarding the symbol map, are you planning to upstream a pass that
> restores the symbols? I have been trying to do this myself in order to
> reverse the "BCSymbolMap". However this turned out to be less
> straightforward than I'd hoped. Any info on this would be greatly
> appreciated!

We have tools to restore symbols in the dSYM bundle (check dsymutil -symbol-map 
option in the Apple toolchain). 
I don't think we have a pass to restore the symbols in the bitcode now but that 
should be very straight forward and I am happy to implement one as a part of 
the item 3. 
Of course, that will only happen if the community thinks this feature is 
beneficial to them. At the meantime, if you need assist, please file a radar to 
Apple at https://bugreport.apple.com .

Steven


> 
>> 4. Debug info strip to line-tables pass:
>> As the name suggested, this pass strip down the full debug info to
>> line-tables only. This is also one of the steps we took to prevent the leak
>> of source code information in bitcode.
>> 
>> Please let me know what do you think about the pieces above or if you have
>> any concerns about the methodology. I will put up patches for review soon.
>> 
>> Thanks
>> 
>> Steven
>> 
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> Cheers,
> Jonas

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

Re: r276317 - Reroll "Include unreferenced nested types in member list only for CodeView"

[David Blaikie via cfe-commits]

It'd be handy to include details of what's different about this commit than
the previous time it was committed - makes review easier by focusing on the
new changes. (for some commits where I've recommitted them a few times I
end up with a bit of a timeline/history in the commit message - "fixed this
by doing this, fixed that by doing the other thing, etc" which can help
reviewers see what sort of issues this patch has in general & may spot
other cases by following that trend)

On Thu, Jul 21, 2016 at 11:50 AM Adrian McCarthy via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: amccarth
> Date: Thu Jul 21 13:43:20 2016
> New Revision: 276317
>
> URL: http://llvm.org/viewvc/llvm-project?rev=276317&view=rev
> Log:
> Reroll "Include unreferenced nested types in member list only for CodeView"
>
> Another attempt at r276271, hopefully without breaking ModuleDebugInfo
> test.
>
> Modified:
> cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> cfe/trunk/lib/CodeGen/CGDebugInfo.h
> cfe/trunk/test/CodeGenCXX/debug-info-dup-fwd-decl.cpp
> cfe/trunk/test/CodeGenCXX/debug-info-ms-abi.cpp
> cfe/trunk/test/Modules/ModuleDebugInfo.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=276317&r1=276316&r2=276317&view=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Thu Jul 21 13:43:20 2016
> @@ -1090,6 +1090,14 @@ void CGDebugInfo::CollectRecordNormalFie
>elements.push_back(FieldType);
>  }
>
> +void CGDebugInfo::CollectRecordNestedRecord(
> +const RecordDecl *RD, SmallVectorImpl &elements) {
> +  QualType Ty = CGM.getContext().getTypeDeclType(RD);
> +  SourceLocation Loc = RD->getLocation();
> +  llvm::DIType *nestedType = getOrCreateType(Ty, getOrCreateFile(Loc));
> +  elements.push_back(nestedType);
> +}
> +
>  void CGDebugInfo::CollectRecordFields(
>  const RecordDecl *record, llvm::DIFile *tunit,
>  SmallVectorImpl &elements,
> @@ -1101,6 +1109,10 @@ void CGDebugInfo::CollectRecordFields(
>else {
>  const ASTRecordLayout &layout =
> CGM.getContext().getASTRecordLayout(record);
>
> +// Debug info for nested records is included in the member list only
> for
> +// CodeView.
> +bool IncludeNestedRecords = CGM.getCodeGenOpts().EmitCodeView;
> +
>  // Field number for non-static fields.
>  unsigned fieldNo = 0;
>
> @@ -1126,7 +1138,10 @@ void CGDebugInfo::CollectRecordFields(
>
>  // Bump field number for next field.
>  ++fieldNo;
> -  }
> +  } else if (const auto *nestedRec = dyn_cast(I))
> +if (IncludeNestedRecords && !nestedRec->isImplicit() &&
> +nestedRec->getDeclContext() == record)
> +  CollectRecordNestedRecord(nestedRec, elements);
>}
>  }
>
> @@ -3620,8 +3635,8 @@ void CGDebugInfo::EmitUsingDirective(con
>if (CGM.getCodeGenOpts().getDebugInfo() <
> codegenoptions::LimitedDebugInfo)
>  return;
>const NamespaceDecl *NSDecl = UD.getNominatedNamespace();
> -  if (!NSDecl->isAnonymousNamespace() ||
> -  CGM.getCodeGenOpts().DebugExplicitImport) {
> +  if (!NSDecl->isAnonymousNamespace() ||
> +  CGM.getCodeGenOpts().DebugExplicitImport) {
>  DBuilder.createImportedModule(
>  getCurrentContextDescriptor(cast(UD.getDeclContext())),
>  getOrCreateNameSpace(NSDecl),
>
> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.h?rev=276317&r1=276316&r2=276317&view=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CGDebugInfo.h (original)
> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.h Thu Jul 21 13:43:20 2016
> @@ -254,6 +254,8 @@ class CGDebugInfo {
>  llvm::DIFile *F,
>  SmallVectorImpl &E,
>  llvm::DIType *RecordTy, const RecordDecl
> *RD);
> +  void CollectRecordNestedRecord(const RecordDecl *RD,
> + SmallVectorImpl &E);
>void CollectRecordFields(const RecordDecl *Decl, llvm::DIFile *F,
> SmallVectorImpl &E,
> llvm::DICompositeType *RecordTy);
>
> Modified: cfe/trunk/test/CodeGenCXX/debug-info-dup-fwd-decl.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-dup-fwd-decl.cpp?rev=276317&r1=276316&r2=276317&view=diff
>
> ==
> --- cfe/trunk/test/CodeGenCXX/debug-info-dup-fwd-decl.cpp (original)
> +++ cfe/trunk/test/CodeGenCXX/debug-info-dup-fwd-decl.cpp Thu Jul 21
> 13:43:20 2016
> @@ -19,6 +19,6 @@ protected:
>
>  Test t;
>
> -// CHECK: !DIDerivedType(tag: DW_TAG_pointer_type
>  // CHECK: !DICompositeType(tag: DW_TAG_structure_t

Re: [PATCH] D22505: clang-format Access Modifier Use Normal Indent

[Loki Astari via cfe-commits]

LokiAstari added a comment.

@djasper@klimek

Hi guys,
I am not sure how to move this PR forward.

I am not sure if you are uninterested or if this is two minor in comparison to 
other issues.
If there is some other task I need to do to move this forward I more than happy 
to do some leg work, but given the documentation I am not sure what else I need 
to do.

Loki.


https://reviews.llvm.org/D22505



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

Re: [PATCH] D22729: MPIBufferDerefCheck for Clang-Tidy

[Alexander Droste via cfe-commits]

Alexander_Droste updated this revision to Diff 65359.
Alexander_Droste added a comment.

- remove trailing whitespace


https://reviews.llvm.org/D22729

Files:
  clang-tidy/mpi/BufferDerefCheck.cpp
  clang-tidy/mpi/BufferDerefCheck.h
  clang-tidy/mpi/CMakeLists.txt
  clang-tidy/mpi/MPITidyModule.cpp
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/mpi-buffer-deref.rst
  test/clang-tidy/Inputs/mpi-type-mismatch/mpimock.h
  test/clang-tidy/mpi-buffer-deref.cpp
  test/clang-tidy/mpi-type-mismatch.cpp

Index: test/clang-tidy/mpi-type-mismatch.cpp
===
--- test/clang-tidy/mpi-type-mismatch.cpp
+++ test/clang-tidy/mpi-type-mismatch.cpp
@@ -6,19 +6,19 @@
   unsigned char buf;
   MPI_Send(&buf, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'unsigned char' does not match the MPI datatype 'MPI_CHAR' [mpi-type-mismatch]
-  
+
   int buf2;
   MPI_Send(&buf2, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'int' does not match the MPI datatype 'MPI_CHAR'
-  
+
   short buf3;
   MPI_Send(&buf3, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'short' does not match the MPI datatype 'MPI_CHAR'
 
   long buf4;
   MPI_Send(&buf4, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'long' does not match the MPI datatype 'MPI_CHAR'
-  
+
   int8_t buf5;
   MPI_Send(&buf5, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'int8_t' does not match the MPI datatype 'MPI_CHAR'
@@ -40,19 +40,19 @@
   unsigned char buf;
   MPI_Send(&buf, 1, MPI_INT, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'unsigned char' does not match the MPI datatype 'MPI_INT'
-  
+
   unsigned buf2;
   MPI_Send(&buf2, 1, MPI_INT, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'unsigned int' does not match the MPI datatype 'MPI_INT'
-  
+
   short buf3;
   MPI_Send(&buf3, 1, MPI_INT, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'short' does not match the MPI datatype 'MPI_INT'
 
   long buf4;
   MPI_Send(&buf4, 1, MPI_INT, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'long' does not match the MPI datatype 'MPI_INT'
-  
+
   int8_t buf5;
   MPI_Send(&buf5, 1, MPI_INT, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'int8_t' does not match the MPI datatype 'MPI_INT'
@@ -74,19 +74,19 @@
   char buf;
   MPI_Send(&buf, 1, MPI_LONG, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'char' does not match the MPI datatype 'MPI_LONG'
-  
+
   unsigned buf2;
   MPI_Send(&buf2, 1, MPI_LONG, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'unsigned int' does not match the MPI datatype 'MPI_LONG'
-  
+
   unsigned short buf3;
   MPI_Send(&buf3, 1, MPI_LONG, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'unsigned short' does not match the MPI datatype 'MPI_LONG'
 
   unsigned long buf4;
   MPI_Send(&buf4, 1, MPI_LONG, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'unsigned long' does not match the MPI datatype 'MPI_LONG'
-  
+
   int8_t buf5;
   MPI_Send(&buf5, 1, MPI_LONG, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'int8_t' does not match the MPI datatype 'MPI_LONG'
@@ -108,19 +108,19 @@
   char buf;
   MPI_Send(&buf, 1, MPI_INT8_T, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'char' does not match the MPI datatype 'MPI_INT8_T'
-  
+
   unsigned buf2;
   MPI_Send(&buf2, 1, MPI_INT8_T, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'unsigned int' does not match the MPI datatype 'MPI_INT8_T'
-  
+
   short buf3;
   MPI_Send(&buf3, 1, MPI_INT8_T, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'short' does not match the MPI datatype 'MPI_INT8_T'
 
   unsigned long buf4;
   MPI_Send(&buf4, 1, MPI_INT8_T, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'unsigned long' does not match the MPI datatype 'MPI_INT8_T'
-  
+
   uint8_t buf5;
   MPI_Send(&buf5, 1, MPI_INT8_T, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'uint8_t' does not match the MPI datatype 'MPI_INT8_T'
@@ -142,19 +142,19 @@
   char buf;
   MPI_Send(&buf, 1, MPI_C_LONG_DOUBLE_COMPLEX, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'char' does not match the MPI datatype 'MPI_C_LONG_DOUBLE_COMPLEX'
-  
+
   unsigned buf2;
   MPI_Send(&buf2, 1, MPI_C_LONG_DOUBLE_COMPLEX, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning:

Re: [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

[Justin Lebar via cfe-commits]

jlebar added a comment.

In https://reviews.llvm.org/D22463#494568, @vladisld wrote:

> Have the alternatives to sub-modules and monolithic repository been discussed 
> ?


Hi, Vlad.

Please see the ongoing thread in llvm-dev, entitled "[RFC] One or many git 
repositories?".

Tools such as git-repo, have been discussed briefly.  I think the general 
feeling is that most of us (myself included) would rather not learn a new tool 
if there's a simpler alternative, such as a vanilla git workflow.  But if you 
would like to discuss more, that thread is the right place.

-Justin


https://reviews.llvm.org/D22463



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

Re: [PATCH] D22702: [libcxx]Missing default argument for flag_type parameter in one of std::basic_regex constructors

[Hubert Tong via cfe-commits]

hubert.reinterpretcast added a comment.

Minor concerns noted. I'd be okay with this patch, but would like someone else 
to give the okay (or indicate what issues need to be addressed).



Comment at: include/regex:148
@@ -147,3 +147,3 @@
 explicit basic_regex(const charT* p, flag_type f = 
regex_constants::ECMAScript);
-basic_regex(const charT* p, size_t len, flag_type f);
+basic_regex(const charT* p, size_t len, flag_type f = 
regex_constants::ECMAScript);
 basic_regex(const basic_regex&);

This line has more than 80 characters; however, the file already has such 
lines. I guess the libc++ project does not enforce the 80-column policy.


Comment at: test/std/re/re.regex/re.regex.construct/ptr_size.pass.cpp:30
@@ +29,3 @@
+{
+test("\\(a\\)", 5, 0);
+test("\\(a[bc]\\)", 9, 0);

This appears (like `ptr_size_flg.pass.cpp`) to neglect testing `size` in favour 
of testing `flg`. Which is to say that, perhaps `size` should not always be 
`strlen(ptr)`.


https://reviews.llvm.org/D22702



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

Re: [PATCH] D22637: [OpenCL] Add extension cl_khr_mipmap_image to clang

[Anastasia Stulova via cfe-commits]

Anastasia added inline comments.


Comment at: test/Misc/amdgcn.languageOptsOpenCL.cl:188
@@ +187,3 @@
+#endif
+// expected-warning@+6{{unsupported OpenCL extension 'cl_khr_mipmap_image' - 
ignoring}}
+#else

Can you move this error message down instead of adding 6 lines offset.
Also the extension seems to be set by default although it's hard to see without 
the full diff. So why do you get this warning at all?


Comment at: test/SemaOpenCL/extension-version.cl:228
@@ +227,3 @@
+#endif
+// expected-warning@+6{{unsupported OpenCL extension 'cl_khr_mipmap_image' - 
ignoring}}
+#else

Can you move this error message down instead of adding 6 lines offset.


Repository:
  rL LLVM

https://reviews.llvm.org/D22637



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

r276646 - [Myriad]: better compatibility with vendor source

[Douglas Katzman via cfe-commits]

Author: dougk
Date: Mon Jul 25 11:36:02 2016
New Revision: 276646

URL: http://llvm.org/viewvc/llvm-project?rev=276646&view=rev
Log:
[Myriad]: better compatibility with vendor source

- Accept ma{2100,2150,2150} for -mcpu
- Define more preprocessor macros
- Don't append "le/" to little-endian lib dirs

Modified:
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/lib/Driver/ToolChains.cpp
cfe/trunk/test/Preprocessor/predefined-arch-macros.c

Modified: cfe/trunk/lib/Basic/Targets.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=276646&r1=276645&r2=276646&view=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Mon Jul 25 11:36:02 2016
@@ -6470,8 +6470,9 @@ public:
 CK_NIAGARA2,
 CK_NIAGARA3,
 CK_NIAGARA4,
-CK_MYRIAD2_1,
-CK_MYRIAD2_2,
+CK_MYRIAD2100,
+CK_MYRIAD2150,
+CK_MYRIAD2450,
 CK_LEON2,
 CK_LEON2_AT697E,
 CK_LEON2_AT697F,
@@ -6498,8 +6499,9 @@ public:
 case CK_SPARCLITE86X:
 case CK_SPARCLET:
 case CK_TSC701:
-case CK_MYRIAD2_1:
-case CK_MYRIAD2_2:
+case CK_MYRIAD2100:
+case CK_MYRIAD2150:
+case CK_MYRIAD2450:
 case CK_LEON2:
 case CK_LEON2_AT697E:
 case CK_LEON2_AT697F:
@@ -6538,9 +6540,14 @@ public:
 .Case("niagara2", CK_NIAGARA2)
 .Case("niagara3", CK_NIAGARA3)
 .Case("niagara4", CK_NIAGARA4)
-.Case("myriad2", CK_MYRIAD2_1)
-.Case("myriad2.1", CK_MYRIAD2_1)
-.Case("myriad2.2", CK_MYRIAD2_2)
+.Case("ma2100", CK_MYRIAD2100)
+.Case("ma2150", CK_MYRIAD2150)
+.Case("ma2450", CK_MYRIAD2450)
+// FIXME: the myriad2[.n] spellings are obsolete,
+// but a grace period is needed to allow updating dependent builds.
+.Case("myriad2", CK_MYRIAD2100)
+.Case("myriad2.1", CK_MYRIAD2100)
+.Case("myriad2.2", CK_MYRIAD2150)
 .Case("leon2", CK_LEON2)
 .Case("at697e", CK_LEON2_AT697E)
 .Case("at697f", CK_LEON2_AT697F)
@@ -6649,18 +6656,27 @@ public:
   break;
 }
 if (getTriple().getVendor() == llvm::Triple::Myriad) {
+  std::string MyriadArchValue, Myriad2Value;
+  Builder.defineMacro("__sparc_v8__");
+  Builder.defineMacro("__leon__");
   switch (CPU) {
-  case CK_MYRIAD2_1:
-Builder.defineMacro("__myriad2", "1");
-Builder.defineMacro("__myriad2__", "1");
+  case CK_MYRIAD2150:
+MyriadArchValue = "__ma2150";
+Myriad2Value = "2";
 break;
-  case CK_MYRIAD2_2:
-Builder.defineMacro("__myriad2", "2");
-Builder.defineMacro("__myriad2__", "2");
+  case CK_MYRIAD2450:
+MyriadArchValue = "__ma2450";
+Myriad2Value = "2";
 break;
   default:
+MyriadArchValue = "__ma2100";
+Myriad2Value = "1";
 break;
   }
+  Builder.defineMacro(MyriadArchValue, "1");
+  Builder.defineMacro(MyriadArchValue+"__", "1");
+  Builder.defineMacro("__myriad2__", Myriad2Value);
+  Builder.defineMacro("__myriad2", Myriad2Value);
 }
   }
 

Modified: cfe/trunk/lib/Driver/ToolChains.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp?rev=276646&r1=276645&r2=276646&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains.cpp Mon Jul 25 11:36:02 2016
@@ -4935,21 +4935,15 @@ MyriadToolChain::MyriadToolChain(const D
 
   if (GCCInstallation.isValid()) {
 // The contents of LibDir are independent of the version of gcc.
-// This contains libc, libg (a superset of libc), libm, libstdc++, libssp.
+// This contains libc, libg, libm, libstdc++, libssp.
+// The 'ma1x00' and 'nofpu' variants are irrelevant.
 SmallString<128> LibDir(GCCInstallation.getParentLibPath());
-if (Triple.getArch() == llvm::Triple::sparcel)
-  llvm::sys::path::append(LibDir, "../sparc-myriad-elf/lib/le");
-else
-  llvm::sys::path::append(LibDir, "../sparc-myriad-elf/lib");
+llvm::sys::path::append(LibDir, "../sparc-myriad-elf/lib");
 addPathIfExists(D, LibDir, getFilePaths());
 
 // This directory contains crt{i,n,begin,end}.o as well as libgcc.
 // These files are tied to a particular version of gcc.
 SmallString<128> CompilerSupportDir(GCCInstallation.getInstallPath());
-// There are actually 4 choices: {le,be} x {fpu,nofpu}
-// but as this toolchain is for LEON sparc, it can assume FPU.
-if (Triple.getArch() == llvm::Triple::sparcel)
-  llvm::sys::path::append(CompilerSupportDir, "le");
 addPathIfExists(D, CompilerSupportDir, getFilePaths());
   }
 }

Modified: cfe/trunk/test/Preprocessor/predefined-arch-macros.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Preprocessor/predefined-arch-macros.c?rev=276646&r1=276645&r2=27

Re: [PATCH] D22505: clang-format Access Modifier Use Normal Indent

[Daniel Jasper via cfe-commits]

djasper added a comment.

Sorry, my bad. I should have replied sooner. I believe we can move further with 
this seems to be used widely enough (though it really doesn't make sense in my 
personal opinion ;) ).

My main concern is how we are going to configure this in the long run. This is 
mostly my bad as I was trying to be too clever with the AccessModifierOffset 
setting.

I see three options:

1. Roughly go ahead with what you are suggesting, although the option should 
not be called AccessModifierStandardIndent, as that carries no meaning and 
actually is far from the "standard" way. Reasonable names that spring to mind 
are: AccessModifiersCauseAdditionalIndent or 
(Additional)IndentAfterAccessModifiers.
2. Be even more "clever" with AccessModifierOffset (I can come up with various 
ways from negative numbers to special numbers, none of them really good).
3. Deprecate AccessModifierOffset and instead use an enum with a few dedicated 
settings.

Manuel, any thoughts?


https://reviews.llvm.org/D22505



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

Re: [PATCH] D22698: [libcxx] Missing member types 'traits_type' and 'string_type' in class basic_regex

[Hubert Tong via cfe-commits]

hubert.reinterpretcast added a comment.

This looks straightforward. @mclow.lists, are you okay with me committing this 
for Jason?


https://reviews.llvm.org/D22698



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

Re: [PATCH] D19815: Support '#pragma once' in headers when using PCH

[Warren Ristow via cfe-commits]

wristow added a comment.

> @wristow, if this still patches cleanly against trunk (I see that this has 
> been around a while) and test still pass, think this can be committed 
> soon-ish?


It does still apply cleanly, and testing still looks good.

Given that the test was adjusted as suggested by Reid, and the implementation 
was simplified as Richard suggested, even though you've only recently 
registered, I'll commit this.  (Actually, I don't have commit access, but one 
of my colleagues will commit it soon.)

Thanks!


https://reviews.llvm.org/D19815



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

Re: [PATCH] D22419: [CFG] Fix crash in thread sanitizer.

[Nandor Licker via cfe-commits]

nandor added a comment.

ping?


https://reviews.llvm.org/D22419



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

Re: r276361 - Reverting r275115 which caused PR28634.

[Hans Wennborg via cfe-commits]

Should this revert be merged to 3.9?

Thanks,
Hans

On Thu, Jul 21, 2016 at 4:28 PM, Wolfgang Pieb via cfe-commits
 wrote:
> Author: wolfgangp
> Date: Thu Jul 21 18:28:18 2016
> New Revision: 276361
>
> URL: http://llvm.org/viewvc/llvm-project?rev=276361&view=rev
> Log:
> Reverting r275115 which caused PR28634.
> When empty (forwarding) basic blocks that are referenced by user labels
> are removed, incorrect code may be generated.
>
>
> Removed:
> cfe/trunk/test/CodeGen/forwarding-blocks-if.c
> Modified:
> cfe/trunk/lib/CodeGen/CGStmt.cpp
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D22208: [clang-tidy] Fixes to modernize-use-emplace

[Alexander Kornienko via cfe-commits]

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

LG



Comment at: clang-tidy/modernize/UseEmplaceCheck.cpp:115
@@ -95,1 +114,3 @@
+  auto CtorCallSourceRange = CharSourceRange::getTokenRange(
+  InnerCtorCall->getExprLoc(), CallParensRange.getBegin());
 

This doesn't seem to be an issue, since expression `v.push_back(obj.member())` 
won't trigger this check: it expects that the argument of the `push_back` call 
is a `cxxConstructExpr` or a `cxxFunctionalCastExpr`.


https://reviews.llvm.org/D22208



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

Re: r276250 - [Sema, X86] Add explicit check to ensure that builtins that require x86-64 target throw an error if used on 32-bit target.

[Hans Wennborg via cfe-commits]

I see. Since it's not a regression and there are dependencies, let's
not merge it.

Thanks,
Hans

On Fri, Jul 22, 2016 at 12:39 PM, Craig Topper  wrote:
> Most of these have been broken like this for a long time so I'm not sure.
> This patch as is depends on r276249 too since we were missing qualifiers in
> the intrinsics file.
>
> ~Craig
>
> On Fri, Jul 22, 2016 at 6:55 AM, Hans Wennborg  wrote:
>>
>> Should we merge this to 3.9?
>>
>> On Thu, Jul 21, 2016 at 3:38 AM, Craig Topper via cfe-commits
>>  wrote:
>> > Author: ctopper
>> > Date: Thu Jul 21 02:38:43 2016
>> > New Revision: 276250
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=276250&view=rev
>> > Log:
>> > [Sema,X86] Add explicit check to ensure that builtins that require
>> > x86-64 target throw an error if used on 32-bit target.
>> >
>> > If these builtins are allowed to go through on a 32-bit target they will
>> > fire assertions in the backend.
>> >
>> > Fixes PR28635.
>> >
>> > Added:
>> > cfe/trunk/test/CodeGen/builtins-x86-disabled.c
>> > Modified:
>> > cfe/trunk/lib/Sema/SemaChecking.cpp
>> >
>> > Modified: cfe/trunk/lib/Sema/SemaChecking.cpp
>> > URL:
>> > http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaChecking.cpp?rev=276250&r1=276249&r2=276250&view=diff
>> >
>> > ==
>> > --- cfe/trunk/lib/Sema/SemaChecking.cpp (original)
>> > +++ cfe/trunk/lib/Sema/SemaChecking.cpp Thu Jul 21 02:38:43 2016
>> > @@ -1597,6 +1597,56 @@ bool Sema::CheckX86BuiltinFunctionCall(u
>> >  return SemaBuiltinCpuSupports(*this, TheCall);
>> >case X86::BI__builtin_ms_va_start:
>> >  return SemaBuiltinMSVAStart(TheCall);
>> > +  case X86::BI__builtin_ia32_addcarryx_u64:
>> > +  case X86::BI__builtin_ia32_addcarry_u64:
>> > +  case X86::BI__builtin_ia32_subborrow_u64:
>> > +  case X86::BI__builtin_ia32_readeflags_u64:
>> > +  case X86::BI__builtin_ia32_writeeflags_u64:
>> > +  case X86::BI__builtin_ia32_bextr_u64:
>> > +  case X86::BI__builtin_ia32_bextri_u64:
>> > +  case X86::BI__builtin_ia32_bzhi_di:
>> > +  case X86::BI__builtin_ia32_pdep_di:
>> > +  case X86::BI__builtin_ia32_pext_di:
>> > +  case X86::BI__builtin_ia32_crc32di:
>> > +  case X86::BI__builtin_ia32_fxsave64:
>> > +  case X86::BI__builtin_ia32_fxrstor64:
>> > +  case X86::BI__builtin_ia32_xsave64:
>> > +  case X86::BI__builtin_ia32_xrstor64:
>> > +  case X86::BI__builtin_ia32_xsaveopt64:
>> > +  case X86::BI__builtin_ia32_xrstors64:
>> > +  case X86::BI__builtin_ia32_xsavec64:
>> > +  case X86::BI__builtin_ia32_xsaves64:
>> > +  case X86::BI__builtin_ia32_rdfsbase64:
>> > +  case X86::BI__builtin_ia32_rdgsbase64:
>> > +  case X86::BI__builtin_ia32_wrfsbase64:
>> > +  case X86::BI__builtin_ia32_wrgsbase64:
>> > +  case X86::BI__builtin_ia32_pbroadcastb512_gpr_mask:
>> > +  case X86::BI__builtin_ia32_pbroadcastb256_gpr_mask:
>> > +  case X86::BI__builtin_ia32_pbroadcastb128_gpr_mask:
>> > +  case X86::BI__builtin_ia32_vcvtsd2si64:
>> > +  case X86::BI__builtin_ia32_vcvtsd2usi64:
>> > +  case X86::BI__builtin_ia32_vcvtss2si64:
>> > +  case X86::BI__builtin_ia32_vcvtss2usi64:
>> > +  case X86::BI__builtin_ia32_vcvttsd2si64:
>> > +  case X86::BI__builtin_ia32_vcvttsd2usi64:
>> > +  case X86::BI__builtin_ia32_vcvttss2si64:
>> > +  case X86::BI__builtin_ia32_vcvttss2usi64:
>> > +  case X86::BI__builtin_ia32_cvtss2si64:
>> > +  case X86::BI__builtin_ia32_cvttss2si64:
>> > +  case X86::BI__builtin_ia32_cvtsd2si64:
>> > +  case X86::BI__builtin_ia32_cvttsd2si64:
>> > +  case X86::BI__builtin_ia32_cvtsi2sd64:
>> > +  case X86::BI__builtin_ia32_cvtsi2ss64:
>> > +  case X86::BI__builtin_ia32_cvtusi2sd64:
>> > +  case X86::BI__builtin_ia32_cvtusi2ss64:
>> > +  case X86::BI__builtin_ia32_rdseed64_step: {
>> > +// These builtins only work on x86-64 targets.
>> > +const llvm::Triple &TT = Context.getTargetInfo().getTriple();
>> > +if (TT.getArch() != llvm::Triple::x86_64)
>> > +  return Diag(TheCall->getCallee()->getLocStart(),
>> > +  diag::err_x86_builtin_32_bit_tgt);
>> > +return false;
>> > +  }
>> >case X86::BI__builtin_ia32_extractf64x4_mask:
>> >case X86::BI__builtin_ia32_extracti64x4_mask:
>> >case X86::BI__builtin_ia32_extractf32x8_mask:
>> >
>> > Added: cfe/trunk/test/CodeGen/builtins-x86-disabled.c
>> > URL:
>> > http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/builtins-x86-disabled.c?rev=276250&view=auto
>> >
>> > ==
>> > --- cfe/trunk/test/CodeGen/builtins-x86-disabled.c (added)
>> > +++ cfe/trunk/test/CodeGen/builtins-x86-disabled.c Thu Jul 21 02:38:43
>> > 2016
>> > @@ -0,0 +1,22 @@
>> > +// REQUIRES: x86-registered-target
>> > +// RUN: not %clang_cc1 -triple i386-unknown-unknown -emit-llvm %s -o -
>> > 2>&1 | FileCheck %s
>> > +
>> > +void call_x86_64_builtins(void)
>> > +{
>> > +  unsigned long long a = __builtin_ia32_crc32di(0, 0);
>> > +  unsigned long

Re: [PATCH] D22045: [X86] Support of no_caller_saved_registers attribute (Clang part)

[David Kreitzer via cfe-commits]

DavidKreitzer added a comment.

The example Aaron sent in email is a good one:

  void func(int, int, int, int) __attribute__((no_caller_saved_registers, 
cdecl));
  
  int main() {
void (*fp)(int, int, int, int) __attribute__((cdecl)) = func;
func(1, 2, 3, 4);
fp(1, 2, 3, 4); // Not the same as the above call to func()?
  }

Clang should at least be giving a warning for this just like it does if you try 
to mix cdecl and stdcall on IA-32 or if you mix regparm(2) and regparm(3).

The current patch silently accepts the mismatch.


https://reviews.llvm.org/D22045



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

[PATCH] D22766: Handle -mlong-calls on Hexagon

[Krzysztof Parzyszek via cfe-commits]

kparzysz created this revision.
kparzysz added reviewers: t.p.northover, echristo.
kparzysz added a subscriber: cfe-commits.
kparzysz set the repository for this revision to rL LLVM.
Herald added subscribers: mehdi_amini, aemerson.

Make -mlong-calls a general (i.e. non ARM-specific) option.

Repository:
  rL LLVM

https://reviews.llvm.org/D22766

Files:
  include/clang/Driver/Options.td
  lib/Basic/Targets.cpp
  lib/Driver/Tools.cpp
  test/Driver/hexagon-long-calls.c

Index: test/Driver/hexagon-long-calls.c
===
--- /dev/null
+++ test/Driver/hexagon-long-calls.c
@@ -0,0 +1,15 @@
+// RUN: %clang -target hexagon -### %s 2>&1 \
+// RUN:| FileCheck %s -check-prefix CHECK-DEFAULT
+
+// RUN: %clang -target hexagon -### -mlong-calls %s 2>&1 \
+// RUN:| FileCheck %s -check-prefix CHECK-LONG-CALLS
+
+// RUN: %clang -target hexagon -### -mlong-calls -mno-long-calls %s 2>&1 \
+// RUN:| FileCheck %s -check-prefix CHECK-NO-LONG-CALLS
+
+// CHECK-DEFAULT-NOT: "-target-feature" "+long-calls"
+
+// CHECK-LONG-CALLS: "-target-feature" "+long-calls"
+
+// CHECK-NO-LONG-CALLS-NOT: "-target-feature" "+long-calls"
+
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -2536,28 +2536,17 @@
 
 static void getHexagonTargetFeatures(const ArgList &Args,
  std::vector &Features) {
-  bool HasHVX = false, HasHVXD = false;
-
-  // FIXME: This should be able to use handleTargetFeaturesGroup except it is
-  // doing dependent option handling here rather than in initFeatureMap or a
-  // similar handler.
-  for (auto &A : Args) {
-auto &Opt = A->getOption();
-if (Opt.matches(options::OPT_mhexagon_hvx))
-  HasHVX = true;
-else if (Opt.matches(options::OPT_mno_hexagon_hvx))
-  HasHVXD = HasHVX = false;
-else if (Opt.matches(options::OPT_mhexagon_hvx_double))
-  HasHVXD = HasHVX = true;
-else if (Opt.matches(options::OPT_mno_hexagon_hvx_double))
-  HasHVXD = false;
-else
-  continue;
-A->claim();
+  handleTargetFeaturesGroup(Args, Features,
+options::OPT_m_hexagon_Features_Group);
+
+  bool UseLongCalls = false;
+  if (Arg *A = Args.getLastArg(options::OPT_mlong_calls,
+   options::OPT_mno_long_calls)) {
+if (A->getOption().matches(options::OPT_mlong_calls))
+  UseLongCalls = true;
   }
 
-  Features.push_back(HasHVX  ? "+hvx" : "-hvx");
-  Features.push_back(HasHVXD ? "+hvx-double" : "-hvx-double");
+  Features.push_back(UseLongCalls ? "+long-calls" : "-long-calls");
 }
 
 static void getWebAssemblyTargetFeatures(const ArgList &Args,
Index: lib/Basic/Targets.cpp
===
--- lib/Basic/Targets.cpp
+++ lib/Basic/Targets.cpp
@@ -6079,6 +6079,7 @@
   static const TargetInfo::GCCRegAlias GCCRegAliases[];
   std::string CPU;
   bool HasHVX, HasHVXDouble;
+  bool UseLongCalls;
 
 public:
   HexagonTargetInfo(const llvm::Triple &Triple, const TargetOptions &)
@@ -6103,6 +6104,7 @@
 UseBitFieldTypeAlignment = true;
 ZeroLengthBitfieldBoundary = 32;
 HasHVX = HasHVXDouble = false;
+UseLongCalls = false;
   }
 
   ArrayRef getTargetBuiltins() const override {
@@ -6137,15 +6139,19 @@
   .Case("hexagon", true)
   .Case("hvx", HasHVX)
   .Case("hvx-double", HasHVXDouble)
+  .Case("long-calls", UseLongCalls)
   .Default(false);
   }
 
+  bool handleTargetFeatures(std::vector &Features,
+DiagnosticsEngine &Diags) override;
+
   bool initFeatureMap(llvm::StringMap &Features, DiagnosticsEngine &Diags,
 StringRef CPU, const std::vector &FeaturesVec)
 const override;
 
-  bool handleTargetFeatures(std::vector &Features,
-DiagnosticsEngine &Diags) override;
+  void setFeatureEnabled(llvm::StringMap &Features, StringRef Name,
+ bool Enabled) const override;
 
   BuiltinVaListKind getBuiltinVaListKind() const override {
 return TargetInfo::CharPtrBuiltinVaList;
@@ -6226,6 +6232,11 @@
   HasHVX = HasHVXDouble = true;
 else if (F == "-hvx-double")
   HasHVXDouble = false;
+
+if (F == "+long-calls")
+  UseLongCalls = true;
+else if (F == "-long-calls")
+  UseLongCalls = false;
   }
   return true;
 }
@@ -6236,10 +6247,23 @@
   // Default for v60: -hvx, -hvx-double.
   Features["hvx"] = false;
   Features["hvx-double"] = false;
+  Features["long-calls"] = false;
 
   return TargetInfo::initFeatureMap(Features, Diags, CPU, FeaturesVec);
 }
 
+void HexagonTargetInfo::setFeatureEnabled(llvm::StringMap &Features,
+  StringRef Name, bool Enabled) const {
+  if (Enabled) {
+if (Name == "hvx-double")
+  Features["hvx"] = true;
+  } else {
+if (Name == "hvx")
+  Features["hvx-double"] = false;
+  }
+  Features[Name] = Ena

RE: r276361 - Reverting r275115 which caused PR28634.

[Pieb, Wolfgang via cfe-commits]

Yes, it should. I'm just now realizing that the original change got into 3.9.

Thanks,
Wolfgang

> -Original Message-
> From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf Of
> Hans Wennborg
> Sent: Monday, July 25, 2016 9:56 AM
> To: Pieb, Wolfgang
> Cc: cfe-commits
> Subject: Re: r276361 - Reverting r275115 which caused PR28634.
> 
> Should this revert be merged to 3.9?
> 
> Thanks,
> Hans
> 
> On Thu, Jul 21, 2016 at 4:28 PM, Wolfgang Pieb via cfe-commits  comm...@lists.llvm.org> wrote:
> > Author: wolfgangp
> > Date: Thu Jul 21 18:28:18 2016
> > New Revision: 276361
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=276361&view=rev
> > Log:
> > Reverting r275115 which caused PR28634.
> > When empty (forwarding) basic blocks that are referenced by user
> > labels are removed, incorrect code may be generated.
> >
> >
> > Removed:
> > cfe/trunk/test/CodeGen/forwarding-blocks-if.c
> > Modified:
> > cfe/trunk/lib/CodeGen/CGStmt.cpp
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

[Chris Bieneman via cfe-commits]

beanz added a subscriber: beanz.
beanz added a comment.

@rengolin, thank you for putting this all together. It is very well thought 
out, and I really like the shape it took. I have a few minor nitpick comments 
inline.

Thanks,
-Chris



Comment at: docs/Proposals/GitHub.rst:58
@@ +57,3 @@
+
+Git is also the version control most LLVM developers use. Despite the sources
+being stored in an SVN server, most people develop using the Git-SVN 
integration,

Not to be pedantic here, but do we actually /know/ that most LLVM developers 
use Git? I suspect that most do, but I don't think we actually have any 
metrics, so we should avoid using declarative language here. Maybe change 
'most' to 'many' here and below.


Comment at: docs/Proposals/GitHub.rst:87
@@ +86,3 @@
+for example development meetings, sponsoring disadvantaged people to work on
+compilers and foster diversity and equality in our community.
+

In lists you should generally keep the same verb conjugations. Maybe repharse 
this list to something more like:


> ... hosting developer meetings, sponsoring disadvantaged people... and 
> fostering diversity and equality in our community.




https://reviews.llvm.org/D22463



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

Re: [PATCH] D20811: [analyzer] Model some library functions

[Artem Dergachev via cfe-commits]

NoQ updated this revision to Diff 65369.
NoQ marked 4 inline comments as done.

https://reviews.llvm.org/D20811

Files:
  include/clang/StaticAnalyzer/Checkers/Checkers.td
  lib/StaticAnalyzer/Checkers/CMakeLists.txt
  lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
  test/Analysis/std-library-functions.c
  test/Analysis/std-library-functions.cpp

Index: test/Analysis/std-library-functions.cpp
===
--- /dev/null
+++ test/Analysis/std-library-functions.cpp
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -analyze -analyzer-checker=unix.StdLibraryFunctions,debug.ExprInspection -verify %s
+
+// Test that we don't model functions with broken prototypes.
+// Because they probably work differently as well.
+//
+// This test lives in a separate file because we wanted to test all functions
+// in the .c file, however in C there are no overloads.
+
+void clang_analyzer_eval(bool);
+bool isalpha(char);
+
+void test() {
+  clang_analyzer_eval(isalpha('A')); // no-crash // expected-warning{{UNKNOWN}}
+}
Index: test/Analysis/std-library-functions.c
===
--- /dev/null
+++ test/Analysis/std-library-functions.c
@@ -0,0 +1,184 @@
+// RUN: %clang_cc1 -analyze -analyzer-checker=unix.StdLibraryFunctions,debug.ExprInspection -verify %s
+
+void clang_analyzer_eval(int);
+
+int glob;
+
+typedef struct FILE FILE;
+#define EOF -1
+
+int getc(FILE *);
+void test_getc(FILE *fp) {
+  int x;
+  while ((x = getc(fp)) != EOF) {
+clang_analyzer_eval(x > 255); // expected-warning{{FALSE}}
+clang_analyzer_eval(x >= 0); // expected-warning{{TRUE}}
+  }
+}
+
+int fgetc(FILE *);
+void test_fgets(FILE *fp) {
+  clang_analyzer_eval(fgetc(fp) < 256); // expected-warning{{TRUE}}
+  clang_analyzer_eval(fgetc(fp) >= 0); // expected-warning{{UNKNOWN}}
+}
+
+
+typedef unsigned long size_t;
+typedef signed long ssize_t;
+ssize_t read(int, void *, size_t);
+ssize_t write(int, const void *, size_t);
+void test_read_write(int fd, char *buf) {
+  glob = 1;
+  ssize_t x = write(fd, buf, 10);
+  clang_analyzer_eval(glob); // expected-warning{{UNKNOWN}}
+  if (x >= 0) {
+clang_analyzer_eval(x <= 10); // expected-warning{{TRUE}}
+ssize_t y = read(fd, &glob, sizeof(glob));
+if (y >= 0) {
+  clang_analyzer_eval(y <= sizeof(glob)); // expected-warning{{TRUE}}
+} else {
+  // -1 overflows on promotion!
+  clang_analyzer_eval(y <= sizeof(glob)); // expected-warning{{FALSE}}
+}
+  } else {
+clang_analyzer_eval(x == -1); // expected-warning{{TRUE}}
+  }
+}
+
+size_t fread(void *, size_t, size_t, FILE *);
+size_t fwrite(const void *restrict, size_t, size_t, FILE *restrict);
+void test_fread_fwrite(FILE *fp, int *buf) {
+  size_t x = fwrite(buf, sizeof(int), 10, fp);
+  clang_analyzer_eval(x <= 10); // expected-warning{{TRUE}}
+  size_t y = fread(buf, sizeof(int), 10, fp);
+  clang_analyzer_eval(y <= 10); // expected-warning{{TRUE}}
+  size_t z = fwrite(buf, sizeof(int), y, fp);
+  // FIXME: should be TRUE once symbol-symbol constraint support is improved.
+  clang_analyzer_eval(z <= y); // expected-warning{{UNKNOWN}}
+}
+
+ssize_t getline(char **, size_t *, FILE *);
+void test_getline(FILE *fp) {
+  char *line = 0;
+  size_t n = 0;
+  ssize_t len;
+  while ((len = getline(&line, &n, fp)) != -1) {
+clang_analyzer_eval(len == 0); // expected-warning{{FALSE}}
+  }
+}
+
+int isascii(int);
+void test_isascii(int x) {
+  clang_analyzer_eval(isascii(123)); // expected-warning{{TRUE}}
+  clang_analyzer_eval(isascii(-1)); // expected-warning{{FALSE}}
+  if (isascii(x)) {
+clang_analyzer_eval(x < 128); // expected-warning{{TRUE}}
+clang_analyzer_eval(x >= 0); // expected-warning{{TRUE}}
+  } else {
+if (x > 42)
+  clang_analyzer_eval(x >= 128); // expected-warning{{TRUE}}
+else
+  clang_analyzer_eval(x < 0); // expected-warning{{TRUE}}
+  }
+  glob = 1;
+  isascii('a');
+  clang_analyzer_eval(glob); // expected-warning{{TRUE}}
+}
+
+int islower(int);
+void test_islower(int x) {
+  clang_analyzer_eval(islower('x')); // expected-warning{{TRUE}}
+  clang_analyzer_eval(islower('X')); // expected-warning{{FALSE}}
+  if (islower(x))
+clang_analyzer_eval(x < 'a'); // expected-warning{{FALSE}}
+}
+
+int getchar(void);
+void test_getchar() {
+  int x = getchar();
+  if (x == EOF)
+return;
+  clang_analyzer_eval(x < 0); // expected-warning{{FALSE}}
+  clang_analyzer_eval(x < 256); // expected-warning{{TRUE}}
+}
+
+int isalpha(int);
+void test_isalpha() {
+  clang_analyzer_eval(isalpha(']')); // expected-warning{{FALSE}}
+  clang_analyzer_eval(isalpha('Q')); // expected-warning{{TRUE}}
+  clang_analyzer_eval(isalpha(128)); // expected-warning{{UNKNOWN}}
+}
+
+int isalnum(int);
+void test_alnum() {
+  clang_analyzer_eval(isalnum('1')); // expected-warning{{TRUE}}
+  clang_analyzer_eval(isalnum(')')); // expected-warning{{FALSE}}
+}
+
+int isblank(int);
+void test_isblank() {
+  clang_ana

Re: [PATCH] D20811: [analyzer] Model some library functions

[Artem Dergachev via cfe-commits]

NoQ added inline comments.


Comment at: lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:191
@@ +190,3 @@
+// impossible to verify this precisely, but at least
+// this check avoids potential crashes.
+bool matchesCall(const CallExpr *CE) const;

zaks.anna wrote:
> Do we need to talk about crashes when describing what this does?
> Also, please, use oxygen throughout.
Added more comments below.


Comment at: lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:205
@@ +204,3 @@
+  }
+  static QualType getArgType(const CallEvent &Call, ArgNoTy ArgNo) {
+return ArgNo == Ret ? Call.getResultType().getCanonicalType()

zaks.anna wrote:
> We could either provide these APIs in CallEvent or at least have variants 
> that return canonical types. Maybe we already do some of that?
Maybe a separate commit? There are quite a few checkers from which the 
`.getArgExpr(N)->getType()` pattern could be de-duplicated, but i don't think 
many of them are interested in canonical types.


Comment at: lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:445
@@ +444,3 @@
+
+  const FunctionSpecTy &Spec = FSMI->second;
+  if (!Spec.matchesCall(CE))

zaks.anna wrote:
> When can this go wrong? Are we checking if there is a mismatch between the 
> function declaration and the call expression? It is strange that 
> findFunctionSpec takes both of those. Couldn't you always get FunctionDecl 
> out of CallExpr?
Callee decl is path-sensitive information because functions can be passed 
around by pointers, as mentioned in the comment at the beginning of the 
function. Expanded the comment, added a test.


Comment at: lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:508
@@ +507,3 @@
+  FunctionSpecMap = {
+// The isascii() family of functions.
+{ "isalnum",

zaks.anna wrote:
> you could also use /*NameOfTheField*/ convention to name the arguments if 
> that would make this map more readable.
I think compactness is worth it here, and specs are pretty easy to remember, 
imho. Added an example to the first spec to see how it looks and make it easier 
for the reader to adapt and remember, but i'm not quite convinced that 
verbosity is worth it here.


Comment at: test/Analysis/std-library-functions.c:3
@@ +2,3 @@
+
+void clang_analyzer_eval(int);
+int glob;

zaks.anna wrote:
> Why are you not testing all of the functions?
I was too bored to generate tests for all branches of all functions (and if i 
auto-generate such tests, it defeats the purpose), but i added some of the more 
creative tests and covered at least some branches of all functions with them.


https://reviews.llvm.org/D20811



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

[clang-tools-extra] r276651 - Revert "MPITypeMismatchCheck for Clang-Tidy"

[Alexander Kornienko via cfe-commits]

Author: alexfh
Date: Mon Jul 25 12:08:18 2016
New Revision: 276651

URL: http://llvm.org/viewvc/llvm-project?rev=276651&view=rev
Log:
Revert "MPITypeMismatchCheck for Clang-Tidy"

This reverts commit r276640. Breaks multiple buildbots.

Removed:
clang-tools-extra/trunk/clang-tidy/mpi/CMakeLists.txt
clang-tools-extra/trunk/clang-tidy/mpi/MPITidyModule.cpp
clang-tools-extra/trunk/clang-tidy/mpi/TypeMismatchCheck.cpp
clang-tools-extra/trunk/clang-tidy/mpi/TypeMismatchCheck.h
clang-tools-extra/trunk/docs/clang-tidy/checks/mpi-type-mismatch.rst
clang-tools-extra/trunk/test/clang-tidy/Inputs/mpi-type-mismatch/mpimock.h
clang-tools-extra/trunk/test/clang-tidy/mpi-type-mismatch.cpp
Modified:
clang-tools-extra/trunk/clang-tidy/CMakeLists.txt
clang-tools-extra/trunk/clang-tidy/plugin/CMakeLists.txt
clang-tools-extra/trunk/clang-tidy/tool/CMakeLists.txt
clang-tools-extra/trunk/clang-tidy/tool/ClangTidyMain.cpp
clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst

Modified: clang-tools-extra/trunk/clang-tidy/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/CMakeLists.txt?rev=276651&r1=276650&r2=276651&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clang-tidy/CMakeLists.txt Mon Jul 25 12:08:18 2016
@@ -34,7 +34,6 @@ add_subdirectory(cppcoreguidelines)
 add_subdirectory(google)
 add_subdirectory(misc)
 add_subdirectory(modernize)
-add_subdirectory(mpi)
 add_subdirectory(performance)
 add_subdirectory(readability)
 add_subdirectory(utils)

Removed: clang-tools-extra/trunk/clang-tidy/mpi/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/mpi/CMakeLists.txt?rev=276650&view=auto
==
--- clang-tools-extra/trunk/clang-tidy/mpi/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clang-tidy/mpi/CMakeLists.txt (removed)
@@ -1,15 +0,0 @@
-set(LLVM_LINK_COMPONENTS support)
-
-add_clang_library(clangTidyMPIModule
-  MPITidyModule.cpp
-  TypeMismatchCheck.cpp
-
-  LINK_LIBS
-  clangAST
-  clangASTMatchers
-  clangBasic
-  clangLex
-  clangTidy
-  clangTidyUtils
-  clangTooling
-  )

Removed: clang-tools-extra/trunk/clang-tidy/mpi/MPITidyModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/mpi/MPITidyModule.cpp?rev=276650&view=auto
==
--- clang-tools-extra/trunk/clang-tidy/mpi/MPITidyModule.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/mpi/MPITidyModule.cpp (removed)
@@ -1,37 +0,0 @@
-//===--- MPITidyModule.cpp - clang-tidy 
---===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is distributed under the University of Illinois Open Source
-// License. See LICENSE.TXT for details.
-//
-//===--===//
-
-#include "../ClangTidy.h"
-#include "../ClangTidyModule.h"
-#include "../ClangTidyModuleRegistry.h"
-#include "TypeMismatchCheck.h"
-
-namespace clang {
-namespace tidy {
-namespace mpi {
-
-class MPIModule : public ClangTidyModule {
-public:
-  void addCheckFactories(ClangTidyCheckFactories &CheckFactories) override {
-CheckFactories.registerCheck("mpi-type-mismatch");
-  }
-};
-
-} // namespace mpi
-
-// Register the MPITidyModule using this statically initialized variable.
-static ClangTidyModuleRegistry::Add
-X("mpi-module", "Adds MPI clang-tidy checks.");
-
-// This anchor is used to force the linker to link in the generated object file
-// and thus register the MPIModule.
-volatile int MPIModuleAnchorSource = 0;
-
-} // namespace tidy
-} // namespace clang

Removed: clang-tools-extra/trunk/clang-tidy/mpi/TypeMismatchCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/mpi/TypeMismatchCheck.cpp?rev=276650&view=auto
==
--- clang-tools-extra/trunk/clang-tidy/mpi/TypeMismatchCheck.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/mpi/TypeMismatchCheck.cpp (removed)
@@ -1,328 +0,0 @@
-//===--- TypeMismatchCheck.cpp - 
clang-tidy===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is distributed under the University of Illinois Open Source
-// License. See LICENSE.TXT for details.
-//
-//===--===//
-
-#include "TypeMismatchCheck.h"
-#include "clang/StaticAnalyzer/Checkers/MPIFunctionClassifier.h"
-#include "clang/Lex/Lexer.h"
-#include "clang/Tooling/FixIt.h"
-#include 
-#include 
-
-using namespace clang::ast_matchers;
-
-namespace clang {
-namespace tidy {
-namespace mpi {
-
-/// Check if a BuiltinTy

[clang-tools-extra] r276650 - Revert "Remove trailing spaces."

[Alexander Kornienko via cfe-commits]

Author: alexfh
Date: Mon Jul 25 12:08:10 2016
New Revision: 276650

URL: http://llvm.org/viewvc/llvm-project?rev=276650&view=rev
Log:
Revert "Remove trailing spaces."

This reverts commit r276641. Breaks multiple buildbots.

Modified:
clang-tools-extra/trunk/test/clang-tidy/mpi-type-mismatch.cpp

Modified: clang-tools-extra/trunk/test/clang-tidy/mpi-type-mismatch.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/mpi-type-mismatch.cpp?rev=276650&r1=276649&r2=276650&view=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/mpi-type-mismatch.cpp (original)
+++ clang-tools-extra/trunk/test/clang-tidy/mpi-type-mismatch.cpp Mon Jul 25 
12:08:10 2016
@@ -6,11 +6,11 @@ void charNegativeTest() {
   unsigned char buf;
   MPI_Send(&buf, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'unsigned char' 
does not match the MPI datatype 'MPI_CHAR' [mpi-type-mismatch]
-
+  
   int buf2;
   MPI_Send(&buf2, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'int' does not 
match the MPI datatype 'MPI_CHAR'
-
+  
   short buf3;
   MPI_Send(&buf3, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'short' does not 
match the MPI datatype 'MPI_CHAR'
@@ -18,7 +18,7 @@ void charNegativeTest() {
   long buf4;
   MPI_Send(&buf4, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'long' does not 
match the MPI datatype 'MPI_CHAR'
-
+  
   int8_t buf5;
   MPI_Send(&buf5, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'int8_t' does not 
match the MPI datatype 'MPI_CHAR'
@@ -40,11 +40,11 @@ void intNegativeTest() {
   unsigned char buf;
   MPI_Send(&buf, 1, MPI_INT, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'unsigned char' 
does not match the MPI datatype 'MPI_INT'
-
+  
   unsigned buf2;
   MPI_Send(&buf2, 1, MPI_INT, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'unsigned int' does 
not match the MPI datatype 'MPI_INT'
-
+  
   short buf3;
   MPI_Send(&buf3, 1, MPI_INT, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'short' does not 
match the MPI datatype 'MPI_INT'
@@ -52,7 +52,7 @@ void intNegativeTest() {
   long buf4;
   MPI_Send(&buf4, 1, MPI_INT, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'long' does not 
match the MPI datatype 'MPI_INT'
-
+  
   int8_t buf5;
   MPI_Send(&buf5, 1, MPI_INT, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'int8_t' does not 
match the MPI datatype 'MPI_INT'
@@ -74,11 +74,11 @@ void longNegativeTest() {
   char buf;
   MPI_Send(&buf, 1, MPI_LONG, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'char' does not 
match the MPI datatype 'MPI_LONG'
-
+  
   unsigned buf2;
   MPI_Send(&buf2, 1, MPI_LONG, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'unsigned int' does 
not match the MPI datatype 'MPI_LONG'
-
+  
   unsigned short buf3;
   MPI_Send(&buf3, 1, MPI_LONG, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'unsigned short' 
does not match the MPI datatype 'MPI_LONG'
@@ -86,7 +86,7 @@ void longNegativeTest() {
   unsigned long buf4;
   MPI_Send(&buf4, 1, MPI_LONG, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'unsigned long' 
does not match the MPI datatype 'MPI_LONG'
-
+  
   int8_t buf5;
   MPI_Send(&buf5, 1, MPI_LONG, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'int8_t' does not 
match the MPI datatype 'MPI_LONG'
@@ -108,11 +108,11 @@ void int8_tNegativeTest() {
   char buf;
   MPI_Send(&buf, 1, MPI_INT8_T, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'char' does not 
match the MPI datatype 'MPI_INT8_T'
-
+  
   unsigned buf2;
   MPI_Send(&buf2, 1, MPI_INT8_T, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'unsigned int' does 
not match the MPI datatype 'MPI_INT8_T'
-
+  
   short buf3;
   MPI_Send(&buf3, 1, MPI_INT8_T, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'short' does not 
match the MPI datatype 'MPI_INT8_T'
@@ -120,7 +120,7 @@ void int8_tNegativeTest() {
   unsigned long buf4;
   MPI_Send(&buf4, 1, MPI_INT8_T, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'unsigned long' 
does not match the MPI datatype 'MPI_INT8_T'
-
+  
   uint8_t buf5;
   MPI_Send(&buf5, 1, MPI_INT8_T, 0, 0, MPI_COMM_WORLD);
   // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'uint8_t' does not 
match the MPI datatype 'MPI_INT8_T'
@@ -142,11 +142,11 @@ vo

Re: r275377 - Use hasFlag instead of hasArg

[David Blaikie via cfe-commits]

Ping?

On Mon, Jul 18, 2016 at 11:28 AM David Blaikie  wrote:

> What build problem did this cause? Did this just not compile (it looks as
> if ArgList has hasArg and hasFlag, so I'm not sure what the specific
> problem might've been)
>
> On Wed, Jul 13, 2016 at 11:45 PM Dean Michael Berris via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: dberris
>> Date: Thu Jul 14 01:37:46 2016
>> New Revision: 275377
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=275377&view=rev
>> Log:
>> Use hasFlag instead of hasArg
>>
>> Summary: Fix the build to use hasFlag instead of hasArg for checking some
>> flags.
>>
>> Reviewers: echristo
>>
>> Subscribers: mehdi_amini, cfe-commits
>>
>> Differential Revision: http://reviews.llvm.org/D22338
>>
>> Modified:
>> cfe/trunk/lib/Driver/Tools.cpp
>>
>> Modified: cfe/trunk/lib/Driver/Tools.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=275377&r1=275376&r2=275377&view=diff
>>
>> ==
>> --- cfe/trunk/lib/Driver/Tools.cpp (original)
>> +++ cfe/trunk/lib/Driver/Tools.cpp Thu Jul 14 01:37:46 2016
>> @@ -4609,8 +4609,8 @@ void Clang::ConstructJob(Compilation &C,
>>
>>Args.AddAllArgs(CmdArgs, options::OPT_finstrument_functions);
>>
>> -  if (Args.hasArg(options::OPT_fxray_instrument,
>> -  options::OPT_fnoxray_instrument, false)) {
>> +  if (Args.hasFlag(options::OPT_fxray_instrument,
>> +   options::OPT_fnoxray_instrument, false)) {
>>  CmdArgs.push_back("-fxray-instrument");
>>  if (Arg *A =
>> Args.getLastArg(options::OPT_fxray_instruction_threshold_,
>>
>> options::OPT_fxray_instruction_threshold_EQ)) {
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r276653 - Support '#pragma once' in headers when using PCH

[Sunil Srivastava via cfe-commits]

Author: ssrivastava
Date: Mon Jul 25 12:17:06 2016
New Revision: 276653

URL: http://llvm.org/viewvc/llvm-project?rev=276653&view=rev
Log:
Support '#pragma once' in headers when using PCH

The '#pragma once' directive was erroneously ignored when encountered
in the header-file specified in generate-PCH-mode. This resulted in
compile-time errors in some cases with legal code, and also a misleading
warning being produced.

Patch by Warren Ristow!

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

Added:
cfe/trunk/test/PCH/Inputs/pragma-once.h
cfe/trunk/test/PCH/pragma-once.c
Modified:
cfe/trunk/lib/Lex/Pragma.cpp

Modified: cfe/trunk/lib/Lex/Pragma.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/Pragma.cpp?rev=276653&r1=276652&r2=276653&view=diff
==
--- cfe/trunk/lib/Lex/Pragma.cpp (original)
+++ cfe/trunk/lib/Lex/Pragma.cpp Mon Jul 25 12:17:06 2016
@@ -352,7 +352,9 @@ void Preprocessor::HandleMicrosoft__prag
 /// HandlePragmaOnce - Handle \#pragma once.  OnceTok is the 'once'.
 ///
 void Preprocessor::HandlePragmaOnce(Token &OnceTok) {
-  if (isInPrimaryFile()) {
+  // Don't honor the 'once' when handling the primary source file, unless
+  // this is a prefix to a TU, which indicates we're generating a PCH file.
+  if (isInPrimaryFile() && TUKind != TU_Prefix) {
 Diag(OnceTok, diag::pp_pragma_once_in_main_file);
 return;
   }

Added: cfe/trunk/test/PCH/Inputs/pragma-once.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/PCH/Inputs/pragma-once.h?rev=276653&view=auto
==
--- cfe/trunk/test/PCH/Inputs/pragma-once.h (added)
+++ cfe/trunk/test/PCH/Inputs/pragma-once.h Mon Jul 25 12:17:06 2016
@@ -0,0 +1,5 @@
+#pragma once
+
+/* For use with the pragma-once.c test */
+
+int x = 3;

Added: cfe/trunk/test/PCH/pragma-once.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/PCH/pragma-once.c?rev=276653&view=auto
==
--- cfe/trunk/test/PCH/pragma-once.c (added)
+++ cfe/trunk/test/PCH/pragma-once.c Mon Jul 25 12:17:06 2016
@@ -0,0 +1,13 @@
+// Test this without pch.
+// RUN: %clang_cc1 -include %S/Inputs/pragma-once.h -fsyntax-only -verify %s
+
+// Test with pch.
+// RUN: %clang_cc1 -emit-pch -o %t %S/Inputs/pragma-once.h
+// RUN: %clang_cc1 -include-pch %t -fsyntax-only -verify %s
+
+// expected-no-diagnostics
+
+// Including "pragma-once.h" twice, to verify the 'once' aspect is honored.
+#include "Inputs/pragma-once.h"
+#include "Inputs/pragma-once.h"
+int foo(void) { return 0; }


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

Re: [PATCH] D19815: Support '#pragma once' in headers when using PCH

[Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL276653: Support '#pragma once' in headers when using PCH 
(authored by ssrivastava).

Changed prior to commit:
  https://reviews.llvm.org/D19815?vs=57320&id=65372#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D19815

Files:
  cfe/trunk/lib/Lex/Pragma.cpp
  cfe/trunk/test/PCH/Inputs/pragma-once.h
  cfe/trunk/test/PCH/pragma-once.c

Index: cfe/trunk/test/PCH/Inputs/pragma-once.h
===
--- cfe/trunk/test/PCH/Inputs/pragma-once.h
+++ cfe/trunk/test/PCH/Inputs/pragma-once.h
@@ -0,0 +1,5 @@
+#pragma once
+
+/* For use with the pragma-once.c test */
+
+int x = 3;
Index: cfe/trunk/test/PCH/pragma-once.c
===
--- cfe/trunk/test/PCH/pragma-once.c
+++ cfe/trunk/test/PCH/pragma-once.c
@@ -0,0 +1,13 @@
+// Test this without pch.
+// RUN: %clang_cc1 -include %S/Inputs/pragma-once.h -fsyntax-only -verify %s
+
+// Test with pch.
+// RUN: %clang_cc1 -emit-pch -o %t %S/Inputs/pragma-once.h
+// RUN: %clang_cc1 -include-pch %t -fsyntax-only -verify %s
+
+// expected-no-diagnostics
+
+// Including "pragma-once.h" twice, to verify the 'once' aspect is honored.
+#include "Inputs/pragma-once.h"
+#include "Inputs/pragma-once.h"
+int foo(void) { return 0; }
Index: cfe/trunk/lib/Lex/Pragma.cpp
===
--- cfe/trunk/lib/Lex/Pragma.cpp
+++ cfe/trunk/lib/Lex/Pragma.cpp
@@ -352,7 +352,9 @@
 /// HandlePragmaOnce - Handle \#pragma once.  OnceTok is the 'once'.
 ///
 void Preprocessor::HandlePragmaOnce(Token &OnceTok) {
-  if (isInPrimaryFile()) {
+  // Don't honor the 'once' when handling the primary source file, unless
+  // this is a prefix to a TU, which indicates we're generating a PCH file.
+  if (isInPrimaryFile() && TUKind != TU_Prefix) {
 Diag(OnceTok, diag::pp_pragma_once_in_main_file);
 return;
   }


Index: cfe/trunk/test/PCH/Inputs/pragma-once.h
===
--- cfe/trunk/test/PCH/Inputs/pragma-once.h
+++ cfe/trunk/test/PCH/Inputs/pragma-once.h
@@ -0,0 +1,5 @@
+#pragma once
+
+/* For use with the pragma-once.c test */
+
+int x = 3;
Index: cfe/trunk/test/PCH/pragma-once.c
===
--- cfe/trunk/test/PCH/pragma-once.c
+++ cfe/trunk/test/PCH/pragma-once.c
@@ -0,0 +1,13 @@
+// Test this without pch.
+// RUN: %clang_cc1 -include %S/Inputs/pragma-once.h -fsyntax-only -verify %s
+
+// Test with pch.
+// RUN: %clang_cc1 -emit-pch -o %t %S/Inputs/pragma-once.h
+// RUN: %clang_cc1 -include-pch %t -fsyntax-only -verify %s
+
+// expected-no-diagnostics
+
+// Including "pragma-once.h" twice, to verify the 'once' aspect is honored.
+#include "Inputs/pragma-once.h"
+#include "Inputs/pragma-once.h"
+int foo(void) { return 0; }
Index: cfe/trunk/lib/Lex/Pragma.cpp
===
--- cfe/trunk/lib/Lex/Pragma.cpp
+++ cfe/trunk/lib/Lex/Pragma.cpp
@@ -352,7 +352,9 @@
 /// HandlePragmaOnce - Handle \#pragma once.  OnceTok is the 'once'.
 ///
 void Preprocessor::HandlePragmaOnce(Token &OnceTok) {
-  if (isInPrimaryFile()) {
+  // Don't honor the 'once' when handling the primary source file, unless
+  // this is a prefix to a TU, which indicates we're generating a PCH file.
+  if (isInPrimaryFile() && TUKind != TU_Prefix) {
 Diag(OnceTok, diag::pp_pragma_once_in_main_file);
 return;
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D16538: [cc1as] Add MCTargetOptions argument to createAsmBackend

[Joel Jones via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL276655: [cc1as] Add MCTargetOptions argument to 
createAsmBackend (authored by joel_k_jones).

Changed prior to commit:
  https://reviews.llvm.org/D16538?vs=62793&id=65374#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D16538

Files:
  cfe/trunk/tools/driver/cc1as_main.cpp

Index: cfe/trunk/tools/driver/cc1as_main.cpp
===
--- cfe/trunk/tools/driver/cc1as_main.cpp
+++ cfe/trunk/tools/driver/cc1as_main.cpp
@@ -379,7 +379,8 @@
 MCAsmBackend *MAB = nullptr;
 if (Opts.ShowEncoding) {
   CE = TheTarget->createMCCodeEmitter(*MCII, *MRI, Ctx);
-  MAB = TheTarget->createMCAsmBackend(*MRI, Opts.Triple, Opts.CPU);
+  MCTargetOptions Options;
+  MAB = TheTarget->createMCAsmBackend(*MRI, Opts.Triple, Opts.CPU, 
Options);
 }
 auto FOut = llvm::make_unique(*Out);
 Str.reset(TheTarget->createAsmStreamer(
@@ -396,8 +397,9 @@
 }
 
 MCCodeEmitter *CE = TheTarget->createMCCodeEmitter(*MCII, *MRI, Ctx);
+MCTargetOptions Options;
 MCAsmBackend *MAB = TheTarget->createMCAsmBackend(*MRI, Opts.Triple,
-  Opts.CPU);
+  Opts.CPU, Options);
 Triple T(Opts.Triple);
 Str.reset(TheTarget->createMCObjectStreamer(
 T, Ctx, *MAB, *Out, CE, *STI, Opts.RelaxAll,


Index: cfe/trunk/tools/driver/cc1as_main.cpp
===
--- cfe/trunk/tools/driver/cc1as_main.cpp
+++ cfe/trunk/tools/driver/cc1as_main.cpp
@@ -379,7 +379,8 @@
 MCAsmBackend *MAB = nullptr;
 if (Opts.ShowEncoding) {
   CE = TheTarget->createMCCodeEmitter(*MCII, *MRI, Ctx);
-  MAB = TheTarget->createMCAsmBackend(*MRI, Opts.Triple, Opts.CPU);
+  MCTargetOptions Options;
+  MAB = TheTarget->createMCAsmBackend(*MRI, Opts.Triple, Opts.CPU, Options);
 }
 auto FOut = llvm::make_unique(*Out);
 Str.reset(TheTarget->createAsmStreamer(
@@ -396,8 +397,9 @@
 }
 
 MCCodeEmitter *CE = TheTarget->createMCCodeEmitter(*MCII, *MRI, Ctx);
+MCTargetOptions Options;
 MCAsmBackend *MAB = TheTarget->createMCAsmBackend(*MRI, Opts.Triple,
-  Opts.CPU);
+  Opts.CPU, Options);
 Triple T(Opts.Triple);
 Str.reset(TheTarget->createMCObjectStreamer(
 T, Ctx, *MAB, *Out, CE, *STI, Opts.RelaxAll,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r276361 - Reverting r275115 which caused PR28634.

[Hans Wennborg via cfe-commits]

Merged the revert to 3.9 in r276656.

Thanks,
Hans

On Mon, Jul 25, 2016 at 10:02 AM, Pieb, Wolfgang  wrote:
> Yes, it should. I'm just now realizing that the original change got into 3.9.
>
> Thanks,
> Wolfgang
>
>> -Original Message-
>> From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf Of
>> Hans Wennborg
>> Sent: Monday, July 25, 2016 9:56 AM
>> To: Pieb, Wolfgang
>> Cc: cfe-commits
>> Subject: Re: r276361 - Reverting r275115 which caused PR28634.
>>
>> Should this revert be merged to 3.9?
>>
>> Thanks,
>> Hans
>>
>> On Thu, Jul 21, 2016 at 4:28 PM, Wolfgang Pieb via cfe-commits > comm...@lists.llvm.org> wrote:
>> > Author: wolfgangp
>> > Date: Thu Jul 21 18:28:18 2016
>> > New Revision: 276361
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=276361&view=rev
>> > Log:
>> > Reverting r275115 which caused PR28634.
>> > When empty (forwarding) basic blocks that are referenced by user
>> > labels are removed, incorrect code may be generated.
>> >
>> >
>> > Removed:
>> > cfe/trunk/test/CodeGen/forwarding-blocks-if.c
>> > Modified:
>> > cfe/trunk/lib/CodeGen/CGStmt.cpp
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r276655 - [cc1as] Add MCTargetOptions argument to createAsmBackend

[Joel Jones via cfe-commits]

Author: joel_k_jones
Date: Mon Jul 25 12:18:44 2016
New Revision: 276655

URL: http://llvm.org/viewvc/llvm-project?rev=276655&view=rev
Log:
[cc1as] Add MCTargetOptions argument to createAsmBackend

Allow an assembler backend to get ABI options. This is to match the changes
to http://reviews.llvm.org/D16213.

Tested with "make check-clang"

Patch by: Joel Jones

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

Modified:
cfe/trunk/tools/driver/cc1as_main.cpp

Modified: cfe/trunk/tools/driver/cc1as_main.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/driver/cc1as_main.cpp?rev=276655&r1=276654&r2=276655&view=diff
==
--- cfe/trunk/tools/driver/cc1as_main.cpp (original)
+++ cfe/trunk/tools/driver/cc1as_main.cpp Mon Jul 25 12:18:44 2016
@@ -379,7 +379,8 @@ static bool ExecuteAssembler(AssemblerIn
 MCAsmBackend *MAB = nullptr;
 if (Opts.ShowEncoding) {
   CE = TheTarget->createMCCodeEmitter(*MCII, *MRI, Ctx);
-  MAB = TheTarget->createMCAsmBackend(*MRI, Opts.Triple, Opts.CPU);
+  MCTargetOptions Options;
+  MAB = TheTarget->createMCAsmBackend(*MRI, Opts.Triple, Opts.CPU, 
Options);
 }
 auto FOut = llvm::make_unique(*Out);
 Str.reset(TheTarget->createAsmStreamer(
@@ -396,8 +397,9 @@ static bool ExecuteAssembler(AssemblerIn
 }
 
 MCCodeEmitter *CE = TheTarget->createMCCodeEmitter(*MCII, *MRI, Ctx);
+MCTargetOptions Options;
 MCAsmBackend *MAB = TheTarget->createMCAsmBackend(*MRI, Opts.Triple,
-  Opts.CPU);
+  Opts.CPU, Options);
 Triple T(Opts.Triple);
 Str.reset(TheTarget->createMCObjectStreamer(
 T, Ctx, *MAB, *Out, CE, *STI, Opts.RelaxAll,


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

Re: r276352 - [Sema] Handle errors during rewriteBuiltinFunctionDecl

[Hans Wennborg via cfe-commits]

Actually, I now see the PR doesn't reproduce on 3.9, so this must have
broke after the branch point.

On Fri, Jul 22, 2016 at 7:02 AM, Hans Wennborg  wrote:
> Richard: should we merge this to 3.9?
>
> On Thu, Jul 21, 2016 at 7:03 PM, David Majnemer via cfe-commits
>  wrote:
>> Author: majnemer
>> Date: Thu Jul 21 18:03:43 2016
>> New Revision: 276352
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=276352&view=rev
>> Log:
>> [Sema] Handle errors during rewriteBuiltinFunctionDecl
>>
>> rewriteBuiltinFunctionDecl can encounter errors when performing
>> DefaultFunctionArrayLvalueConversion.  These errors were not handled
>> which led to a null pointer dereference.
>>
>> This fixes PR28651.
>>
>> Modified:
>> cfe/trunk/lib/Sema/SemaExpr.cpp
>> cfe/trunk/test/Sema/builtins.cl
>>
>> Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExpr.cpp?rev=276352&r1=276351&r2=276352&view=diff
>> ==
>> --- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
>> +++ cfe/trunk/lib/Sema/SemaExpr.cpp Thu Jul 21 18:03:43 2016
>> @@ -5051,7 +5051,11 @@ static FunctionDecl *rewriteBuiltinFunct
>>for (QualType ParamType : FT->param_types()) {
>>
>>  // Convert array arguments to pointer to simplify type lookup.
>> -Expr *Arg = 
>> Sema->DefaultFunctionArrayLvalueConversion(ArgExprs[i++]).get();
>> +ExprResult ArgRes =
>> +Sema->DefaultFunctionArrayLvalueConversion(ArgExprs[i++]);
>> +if (ArgRes.isInvalid())
>> +  return nullptr;
>> +Expr *Arg = ArgRes.get();
>>  QualType ArgType = Arg->getType();
>>  if (!ParamType->isPointerType() ||
>>  ParamType.getQualifiers().hasAddressSpace() ||
>>
>> Modified: cfe/trunk/test/Sema/builtins.cl
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/builtins.cl?rev=276352&r1=276351&r2=276352&view=diff
>> ==
>> --- cfe/trunk/test/Sema/builtins.cl (original)
>> +++ cfe/trunk/test/Sema/builtins.cl Thu Jul 21 18:03:43 2016
>> @@ -1,8 +1,11 @@
>>  // RUN: %clang_cc1 %s -fsyntax-only -verify -pedantic
>> -// expected-no-diagnostics
>>
>>  kernel void test(global float *out, global float *in, global int* in2) {
>>out[0] = __builtin_nanf("");
>>__builtin_memcpy(out, in, 32);
>>out[0] = __builtin_frexpf(in[0], in2);
>>  }
>> +
>> +void pr28651() {
>> +  __builtin_alloca(value); // expected-error{{use of undeclared identifier}}
>> +}
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D22767: [OpenCL] Added CLK_ABGR definition for get_image_channel_order return value

[Aaron En Ye Shi via cfe-commits]

ashi1 created this revision.
ashi1 added reviewers: yaxunl, Anastasia.
ashi1 added a subscriber: cfe-commits.
ashi1 set the repository for this revision to rL LLVM.

Added CLK_ABGR definition for get_image_channel_order return value inside 
opencl-c.h file

Repository:
  rL LLVM

https://reviews.llvm.org/D22767

Files:
  lib/Headers/opencl-c.h

Index: lib/Headers/opencl-c.h
===
--- lib/Headers/opencl-c.h
+++ lib/Headers/opencl-c.h
@@ -16493,6 +16493,7 @@
 #define CLK_sRGBA 0x10C1
 #define CLK_sRGBx 0x10C0
 #define CLK_sBGRA 0x10C2
+#define CLK_ABGR  0x10C3
 #endif //__OPENCL_C_VERSION__ >= CL_VERSION_2_0
 
 int __ovld __cnfn get_image_channel_order(read_only image1d_t image);


Index: lib/Headers/opencl-c.h
===
--- lib/Headers/opencl-c.h
+++ lib/Headers/opencl-c.h
@@ -16493,6 +16493,7 @@
 #define CLK_sRGBA 0x10C1
 #define CLK_sRGBx 0x10C0
 #define CLK_sBGRA 0x10C2
+#define CLK_ABGR  0x10C3
 #endif //__OPENCL_C_VERSION__ >= CL_VERSION_2_0
 
 int __ovld __cnfn get_image_channel_order(read_only image1d_t image);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D22220: [clang-tidy] Add check 'misc-move-forwarding-reference'

[Etienne Bergeron via cfe-commits]

etienneb added a subscriber: etienneb.
etienneb added a comment.

thx for the check



Comment at: clang-tidy/misc/MoveForwardingReferenceCheck.cpp:25
@@ +24,3 @@
+  const SourceManager &SM = Context->getSourceManager();
+  const LangOptions LangOpts = Context->getLangOpts();
+

nit: reference?


Comment at: clang-tidy/misc/MoveForwardingReferenceCheck.cpp:43-53
@@ +42,13 @@
+// another namespace).
+const StringRef OriginalText =
+Lexer::getSourceText(CallRange, SM, LangOpts);
+if (OriginalText == "::std::move") {
+  Diag << FixItHint::CreateReplacement(CallRange, "::std::" + ForwardName);
+  // If the original text was simply "move", we conservatively still put a
+  // "std::" in front of the "forward". Rationale: Even if the code
+  // apparently had a "using std::move;", that doesn't tell us whether it
+  // also had a "using std::forward;".
+} else if (OriginalText == "std::move" || OriginalText == "move") {
+  Diag << FixItHint::CreateReplacement(CallRange, "std::" + ForwardName);
+}
+  }

alexfh wrote:
> aaron.ballman wrote:
> > I'm not certain I understand the benefit to this. We know it's a call to 
> > std::move() from the standard namespace already, so why do we care about 
> > the original text? I think it's reasonable to replace any call to move() 
> > from the standard namespace with `::std::forward()`, so we should be able 
> > to remove the if statements and not have to go read the original source 
> > text from the source manager (which could involve, for instance, a query 
> > for that text over a slow network).
> I think, the value of this is to maintain consistency with the existing code 
> in terms of whether the `std` namespace should be globally qualified or not. 
> Changing `std::move` to `::std::forward` would sometimes be unwelcome, if the 
> code doesn't use `::std` otherwise.
I agree with alex, it's better to keep code consistency (programmer intend).
But, at the same time, the check should be bomb proof for ugly cases like:
```
  "std:: move"
   ":: std::move",
```

For the moment, the code seems to propose a fix only when it's a known case,
and a warning is emitted in every cases.


Comment at: clang-tidy/misc/MoveForwardingReferenceCheck.cpp:92
@@ +91,3 @@
+  Finder->addMatcher(
+  callExpr(callee(unresolvedLookupExpr().bind("lookup")),
+   argumentCountIs(1),

aaron.ballman wrote:
> It might be a bit more clear if you made `isStdMove()` into a local AST 
> matcher and called it from here.
+1 I agree with Aaron here.

The match will also be more precise.


https://reviews.llvm.org/D0



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

Re: [PATCH] D22637: [OpenCL] Add extension cl_khr_mipmap_image to clang

[Yaxun Liu via cfe-commits]

yaxunl added inline comments.


Comment at: test/Misc/amdgcn.languageOptsOpenCL.cl:188
@@ +187,3 @@
+#endif
+// expected-warning@+6{{unsupported OpenCL extension 'cl_khr_mipmap_image' - 
ignoring}}
+#else

Anastasia wrote:
> Can you move this error message down instead of adding 6 lines offset.
> Also the extension seems to be set by default although it's hard to see 
> without the full diff. So why do you get this warning at all?
This warning is only for opencl version < 200. The extension is supported by 
OpenCL 2.0 and above only.


Repository:
  rL LLVM

https://reviews.llvm.org/D22637



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

Re: [PATCH] D22767: [OpenCL] Added CLK_ABGR definition for get_image_channel_order return value

[Yaxun Liu via cfe-commits]

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

LGTM. Thanks!


Repository:
  rL LLVM

https://reviews.llvm.org/D22767



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

Re: [libcxxabi] r276022 - Attempt to bring peace to -Werror buildbots.

[David Blaikie via cfe-commits]

Should we fix the diagnostic? Or is the code triggering it just esoteric
enough to not be a good justification for changing the warning?

On Tue, Jul 19, 2016 at 1:42 PM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Tue Jul 19 15:35:09 2016
> New Revision: 276022
>
> URL: http://llvm.org/viewvc/llvm-project?rev=276022&view=rev
> Log:
> Attempt to bring peace to -Werror buildbots.
>
> Modified:
> libcxxabi/trunk/test/catch_reference_nullptr.pass.cpp
>
> Modified: libcxxabi/trunk/test/catch_reference_nullptr.pass.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/test/catch_reference_nullptr.pass.cpp?rev=276022&r1=276021&r2=276022&view=diff
>
> ==
> --- libcxxabi/trunk/test/catch_reference_nullptr.pass.cpp (original)
> +++ libcxxabi/trunk/test/catch_reference_nullptr.pass.cpp Tue Jul 19
> 15:35:09 2016
> @@ -12,6 +12,12 @@
>  #include 
>  #include 
>
> +// Clang emits a warning on converting an object of type nullptr_t to
> bool,
> +// even in generic code. Suppress it.
> +#if defined(__clang__)
> +#pragma clang diagnostic ignored "-Wnull-conversion"
> +#endif
> +
>  struct A {};
>
>  template
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D16989: Change interpretation of function definition in friend declaration of template class.

[Serge Pavlov via cfe-commits]

sepavloff updated this revision to Diff 65376.
sepavloff added a comment.

Added one more case in shouldLinkDependentDeclWithPrevious


https://reviews.llvm.org/D16989

Files:
  include/clang/Sema/Sema.h
  lib/Sema/SemaDecl.cpp
  test/SemaCXX/PR25848.cpp
  test/SemaCXX/friend2.cpp

Index: test/SemaCXX/friend2.cpp
===
--- /dev/null
+++ test/SemaCXX/friend2.cpp
@@ -0,0 +1,145 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++11
+
+// If a friend function is defined in several non-template classes,
+// it is an error.
+
+void func1(int);
+struct C1a {
+  friend void func1(int) {}  // expected-note{{previous definition is here}}
+};
+struct C1b {
+  friend void func1(int) {}  // expected-error{{redefinition of 'func1'}}
+};
+
+
+// If a friend function is defined in both non-template and template
+// classes it is an error only if the template is instantiated.
+
+void func2(int);
+struct C2a {
+  friend void func2(int) {}
+};
+template struct C2b {
+  friend void func2(int) {}
+};
+
+void func3(int);
+struct C3a {
+  friend void func3(int) {}  // expected-note{{previous definition is here}}
+};
+template struct C3b {
+  friend void func3(int) {}  // expected-error{{redefinition of 'func3'}}
+};
+C3b c3;  // expected-note{{in instantiation of template class 'C3b' requested here}}
+
+
+// If a friend function is defined in several template classes it is an error
+// only if several templates are instantiated.
+
+void func4(int);
+template struct C4a {
+  friend void func4(int) {}
+};
+template struct C4b {
+  friend void func4(int) {}
+};
+
+
+void func5(int);
+template struct C5a {
+  friend void func5(int) {}
+};
+template struct C5b {
+  friend void func5(int) {}
+};
+C5a c5a;
+
+void func6(int);
+template struct C6a {
+  friend void func6(int) {}  // expected-note{{previous definition is here}}
+};
+template struct C6b {
+  friend void func6(int) {}  // expected-error{{redefinition of 'func6'}}
+};
+C6a c6a;
+C6b c6b;  // expected-note{{in instantiation of template class 'C6b' requested here}}
+
+void func7(int);
+template struct C7 {
+  friend void func7(int) {}  // expected-error{{redefinition of 'func7'}}
+ // expected-note@-1{{previous definition is here}}
+};
+C7 c7a;
+C7 c7b;  // expected-note{{in instantiation of template class 'C7' requested here}}
+
+
+// Even if clases are not instantiated and hence friend functions defined in them are not
+// available, their declarations can be checked.
+
+void func8(int);  // expected-note{{previous declaration is here}}
+template struct C8a {
+  friend long func8(int);  // expected-error{{functions that differ only in their return type cannot be overloaded}}
+};
+
+void func9(int);  // expected-note{{previous declaration is here}}
+template struct C9a {
+  friend int func9(int);  // expected-error{{functions that differ only in their return type cannot be overloaded}}
+};
+
+void func10(int);  // expected-note{{previous declaration is here}}
+template struct C10a {
+  friend int func10(int);  // expected-error{{functions that differ only in their return type cannot be overloaded}}
+};
+
+
+namespace pr22307 {
+
+struct t {
+  friend int leak(t);
+};
+
+template
+struct m {
+  friend int leak(t) { return sizeof(v); }  // expected-error{{redefinition of 'leak'}} expected-note{{previous definition is here}}
+};
+
+template struct m;
+template struct m;  // expected-note{{in instantiation of template class 'pr22307::m' requested here}}
+
+int main() {
+  leak(t());
+}
+
+}
+
+namespace pr17923 {
+
+void f(unsigned long long);
+
+template struct X {
+  friend void f(unsigned long long) {
+ T t;
+  }
+};
+
+int main() { f(1234); }
+
+}
+
+namespace pr17923a {
+
+int get();
+
+template< int value >
+class set {
+  friend int get()
+{ return value; } // return 0; is OK
+};
+
+template class set< 5 >;
+
+int main() {
+  get();
+}
+
+}
Index: test/SemaCXX/PR25848.cpp
===
--- /dev/null
+++ test/SemaCXX/PR25848.cpp
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+struct A;
+
+inline int g();  // expected-warning{{inline function 'g' is not defined}}
+
+template
+struct R {
+  friend int g() {
+return M;
+  }
+};
+
+void m() {
+  g();  // expected-note{{used here}}
+}
Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -8792,6 +8792,49 @@
   return NewFD;
 }
 
+/// \brief Checks if the new declaration declared in dependent context must be
+/// put in the same redeclaration chain as the specified declaration.
+///
+/// \param D Declaration that is checked.
+/// \param PrevDecl Previous declaration found with proper lookup method for the
+/// same declaration name.
+/// \returns True if D must be added to the redeclaration chain which PrevDecl
+///  belongs to.
+///
+

Re: [PATCH] D22637: [OpenCL] Add extension cl_khr_mipmap_image to clang

[Aaron En Ye Shi via cfe-commits]

ashi1 added inline comments.


Comment at: test/Misc/amdgcn.languageOptsOpenCL.cl:188
@@ +187,3 @@
+#endif
+// expected-warning@+6{{unsupported OpenCL extension 'cl_khr_mipmap_image' - 
ignoring}}
+#else

yaxunl wrote:
> Anastasia wrote:
> > Can you move this error message down instead of adding 6 lines offset.
> > Also the extension seems to be set by default although it's hard to see 
> > without the full diff. So why do you get this warning at all?
> This warning is only for opencl version < 200. The extension is supported by 
> OpenCL 2.0 and above only.
I've added this error message here because I am following the order inside 
include/clang/Basic/OpenCLExtensions.def. Seems it is alphabetical there and in 
same order here. What do you think?


Comment at: test/SemaOpenCL/extension-version.cl:228
@@ +227,3 @@
+#endif
+// expected-warning@+6{{unsupported OpenCL extension 'cl_khr_mipmap_image' - 
ignoring}}
+#else

Anastasia wrote:
> Can you move this error message down instead of adding 6 lines offset.
I've added this error message here because I am following the order inside 
include/clang/Basic/OpenCLExtensions.def. Seems it is alphabetical there and in 
same order here. What do you think?


Repository:
  rL LLVM

https://reviews.llvm.org/D22637



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

Re: [libcxxabi] r276022 - Attempt to bring peace to -Werror buildbots.

[Richard Smith via cfe-commits]

On 25 Jul 2016 6:29 p.m., "David Blaikie via cfe-commits" <
cfe-commits@lists.llvm.org> wrote:
>
> Should we fix the diagnostic? Or is the code triggering it just esoteric
enough to not be a good justification for changing the warning?

Hmm, maybe we should. The case is something like

template void f(T t) {
  if (t) ...
}

with T being nullptr_t. That probably doesn't justify a warning.

> On Tue, Jul 19, 2016 at 1:42 PM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
>>
>> Author: rsmith
>> Date: Tue Jul 19 15:35:09 2016
>> New Revision: 276022
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=276022&view=rev
>> Log:
>> Attempt to bring peace to -Werror buildbots.
>>
>> Modified:
>> libcxxabi/trunk/test/catch_reference_nullptr.pass.cpp
>>
>> Modified: libcxxabi/trunk/test/catch_reference_nullptr.pass.cpp
>> URL:
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/test/catch_reference_nullptr.pass.cpp?rev=276022&r1=276021&r2=276022&view=diff
>>
==
>> --- libcxxabi/trunk/test/catch_reference_nullptr.pass.cpp (original)
>> +++ libcxxabi/trunk/test/catch_reference_nullptr.pass.cpp Tue Jul 19
15:35:09 2016
>> @@ -12,6 +12,12 @@
>>  #include 
>>  #include 
>>
>> +// Clang emits a warning on converting an object of type nullptr_t to
bool,
>> +// even in generic code. Suppress it.
>> +#if defined(__clang__)
>> +#pragma clang diagnostic ignored "-Wnull-conversion"
>> +#endif
>> +
>>  struct A {};
>>
>>  template
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D21962: MPITypeMismatchCheck for Clang-Tidy

[Alexander Kornienko via cfe-commits]

alexfh added a comment.

Alexander, FYI, the patch has been reverted, since it breaks multiple 
buildbots, e.g.

- 
http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/13909/steps/ninja%20check%201/logs/FAIL%3A%20Clang%20Tools%3A%3Ampi-type-mismatch.cpp
- 
http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15/builds/14191/steps/ninja%20check%201/logs/FAIL%3A%20Clang%20Tools%3A%3Ampi-type-mismatch.cpp
- 
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/8891/steps/ninja%20check%201/logs/FAIL%3A%20Clang%20Tools%3A%3Ampi-type-mismatch.cpp

(all failures seem to be on ARM and PPC buildbots).

Please take a look.


Repository:
  rL LLVM

https://reviews.llvm.org/D21962



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

Re: [libcxxabi] r276022 - Attempt to bring peace to -Werror buildbots.

[David Blaikie via cfe-commits]

+Richard Trieu  - worth fixing? If anyone does get
around to fixing this, would be good to remove the workaround committed
here in r276022.

On Mon, Jul 25, 2016 at 10:51 AM Richard Smith 
wrote:

> On 25 Jul 2016 6:29 p.m., "David Blaikie via cfe-commits" <
> cfe-commits@lists.llvm.org> wrote:
> >
> > Should we fix the diagnostic? Or is the code triggering it just esoteric
> enough to not be a good justification for changing the warning?
>
> Hmm, maybe we should. The case is something like
>
> template void f(T t) {
>   if (t) ...
> }
>
> with T being nullptr_t. That probably doesn't justify a warning.
>
> > On Tue, Jul 19, 2016 at 1:42 PM Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
> >>
> >> Author: rsmith
> >> Date: Tue Jul 19 15:35:09 2016
> >> New Revision: 276022
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=276022&view=rev
> >> Log:
> >> Attempt to bring peace to -Werror buildbots.
> >>
> >> Modified:
> >> libcxxabi/trunk/test/catch_reference_nullptr.pass.cpp
> >>
> >> Modified: libcxxabi/trunk/test/catch_reference_nullptr.pass.cpp
> >> URL:
> http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/test/catch_reference_nullptr.pass.cpp?rev=276022&r1=276021&r2=276022&view=diff
> >>
> ==
> >> --- libcxxabi/trunk/test/catch_reference_nullptr.pass.cpp (original)
> >> +++ libcxxabi/trunk/test/catch_reference_nullptr.pass.cpp Tue Jul 19
> 15:35:09 2016
> >> @@ -12,6 +12,12 @@
> >>  #include 
> >>  #include 
> >>
> >> +// Clang emits a warning on converting an object of type nullptr_t to
> bool,
> >> +// even in generic code. Suppress it.
> >> +#if defined(__clang__)
> >> +#pragma clang diagnostic ignored "-Wnull-conversion"
> >> +#endif
> >> +
> >>  struct A {};
> >>
> >>  template
> >>
> >>
> >> ___
> >> cfe-commits mailing list
> >> cfe-commits@lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> >
> >
> > ___
> > cfe-commits mailing list
> > cfe-commits@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> >
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D20811: [analyzer] Model some library functions

[Artem Dergachev via cfe-commits]

NoQ added inline comments.


Comment at: lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:192
@@ +191,3 @@
+  };
+
+  // The map of all functions supported by the checker. It is initialized

Even though there are some doxygen-style comments in the checkers, i’ve never 
seen doxygen actually generate any docs for checker classes. Are they useful 
for IDE quick-hints only?


https://reviews.llvm.org/D20811



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

Re: [PATCH] D22654: [Clang-rename] Remove custom version, fix extra space in error message

[Eugene Zelenko via cfe-commits]

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

Don't include DiagnosticIDs.h


Repository:
  rL LLVM

https://reviews.llvm.org/D22654

Files:
  clang-rename/tool/ClangRename.cpp
  test/clang-rename/InvalidNewName.cpp

Index: test/clang-rename/InvalidNewName.cpp
===
--- test/clang-rename/InvalidNewName.cpp
+++ test/clang-rename/InvalidNewName.cpp
@@ -1,2 +1,2 @@
 // RUN: not clang-rename -new-name=class -offset=133 %s 2>&1 | FileCheck %s
-// CHECK: ERROR: new name is not a valid identifier in  C++17.
+// CHECK: ERROR: new name is not a valid identifier in C++17.
Index: clang-rename/tool/ClangRename.cpp
===
--- clang-rename/tool/ClangRename.cpp
+++ clang-rename/tool/ClangRename.cpp
@@ -15,28 +15,27 @@
 
 #include "../USRFindingAction.h"
 #include "../RenamingAction.h"
-#include "clang/AST/ASTConsumer.h"
-#include "clang/AST/ASTContext.h"
+#include "clang/Basic/Diagnostic.h"
+#include "clang/Basic/DiagnosticOptions.h"
 #include "clang/Basic/FileManager.h"
+#include "clang/Basic/IdentifierTable.h"
 #include "clang/Basic/LangOptions.h"
-#include "clang/Basic/TargetInfo.h"
-#include "clang/Basic/TargetOptions.h"
-#include "clang/Frontend/CommandLineSourceLoc.h"
-#include "clang/Frontend/CompilerInstance.h"
-#include "clang/Frontend/FrontendAction.h"
+#include "clang/Basic/SourceManager.h"
+#include "clang/Basic/TokenKinds.h"
 #include "clang/Frontend/TextDiagnosticPrinter.h"
-#include "clang/Lex/Lexer.h"
-#include "clang/Lex/Preprocessor.h"
-#include "clang/Parse/ParseAST.h"
-#include "clang/Parse/Parser.h"
 #include "clang/Rewrite/Core/Rewriter.h"
 #include "clang/Tooling/CommonOptionsParser.h"
 #include "clang/Tooling/Refactoring.h"
 #include "clang/Tooling/ReplacementsYaml.h"
 #include "clang/Tooling/Tooling.h"
 #include "llvm/ADT/IntrusiveRefCntPtr.h"
-#include "llvm/Support/Host.h"
+#include "llvm/Support/CommandLine.h"
+#include "llvm/Support/FileSystem.h"
+#include "llvm/Support/raw_ostream.h"
+#include "llvm/Support/YAMLTraits.h"
+#include 
 #include 
+#include 
 
 using namespace llvm;
 
@@ -79,12 +78,6 @@
 cl::value_desc("filename"),
 cl::cat(ClangRenameCategory));
 
-#define CLANG_RENAME_VERSION "0.0.1"
-
-static void PrintVersion() {
-  outs() << "clang-rename version " << CLANG_RENAME_VERSION << '\n';
-}
-
 using namespace clang;
 
 const char RenameUsage[] = "A tool to rename symbols in C/C++ code.\n\
@@ -93,7 +86,6 @@
 Otherwise, the results are written to stdout.\n";
 
 int main(int argc, const char **argv) {
-  cl::SetVersionPrinter(PrintVersion);
   tooling::CommonOptionsParser OP(argc, argv, ClangRenameCategory, 
RenameUsage);
 
   // Check the arguments for correctness.
@@ -110,7 +102,7 @@
   IdentifierTable Table(Options);
   auto NewNameTokKind = Table.get(NewName).getTokenID();
   if (!tok::isAnyIdentifier(NewNameTokKind)) {
-errs() << "ERROR: new name is not a valid identifier in  C++17.\n\n";
+errs() << "ERROR: new name is not a valid identifier in C++17.\n\n";
 exit(1);
   }
 


Index: test/clang-rename/InvalidNewName.cpp
===
--- test/clang-rename/InvalidNewName.cpp
+++ test/clang-rename/InvalidNewName.cpp
@@ -1,2 +1,2 @@
 // RUN: not clang-rename -new-name=class -offset=133 %s 2>&1 | FileCheck %s
-// CHECK: ERROR: new name is not a valid identifier in  C++17.
+// CHECK: ERROR: new name is not a valid identifier in C++17.
Index: clang-rename/tool/ClangRename.cpp
===
--- clang-rename/tool/ClangRename.cpp
+++ clang-rename/tool/ClangRename.cpp
@@ -15,28 +15,27 @@
 
 #include "../USRFindingAction.h"
 #include "../RenamingAction.h"
-#include "clang/AST/ASTConsumer.h"
-#include "clang/AST/ASTContext.h"
+#include "clang/Basic/Diagnostic.h"
+#include "clang/Basic/DiagnosticOptions.h"
 #include "clang/Basic/FileManager.h"
+#include "clang/Basic/IdentifierTable.h"
 #include "clang/Basic/LangOptions.h"
-#include "clang/Basic/TargetInfo.h"
-#include "clang/Basic/TargetOptions.h"
-#include "clang/Frontend/CommandLineSourceLoc.h"
-#include "clang/Frontend/CompilerInstance.h"
-#include "clang/Frontend/FrontendAction.h"
+#include "clang/Basic/SourceManager.h"
+#include "clang/Basic/TokenKinds.h"
 #include "clang/Frontend/TextDiagnosticPrinter.h"
-#include "clang/Lex/Lexer.h"
-#include "clang/Lex/Preprocessor.h"
-#include "clang/Parse/ParseAST.h"
-#include "clang/Parse/Parser.h"
 #include "clang/Rewrite/Core/Rewriter.h"
 #include "clang/Tooling/CommonOptionsParser.h"
 #include "clang/Tooling/Refactoring.h"
 #include "clang/Tooling/ReplacementsYaml.h"
 #include "clang/Tooling/Tooling.h"
 #include "llvm/ADT/IntrusiveRefCntPtr.h"
-#include "llvm/Support/Host.h"
+#include "llvm/Support/CommandLine.h"
+#include "llvm/Support/FileSystem.h"
+#include "llvm/Support/raw_ostream.h"
+#include "llvm/Support

Re: [PATCH] D20196: [clang-tidy] Inefficient string operation

[Bittner Barni via cfe-commits]

bittnerbarni updated this revision to Diff 65384.
bittnerbarni marked an inline comment as done.

https://reviews.llvm.org/D20196

Files:
  clang-tidy/performance/CMakeLists.txt
  clang-tidy/performance/InefficientStringConcatenationCheck.cpp
  clang-tidy/performance/InefficientStringConcatenationCheck.h
  clang-tidy/performance/PerformanceTidyModule.cpp
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/performance-inefficient-string-concatenation.rst
  test/clang-tidy/performance-inefficient-string-concatenation.cpp

Index: test/clang-tidy/performance-inefficient-string-concatenation.cpp
===
--- /dev/null
+++ test/clang-tidy/performance-inefficient-string-concatenation.cpp
@@ -0,0 +1,44 @@
+// RUN: %check_clang_tidy %s performance-inefficient-string-concatenation %t
+
+namespace std {
+template 
+class basic_string {
+public:
+  basic_string() {}
+  ~basic_string() {}
+  basic_string *operator+=(const basic_string &) {}
+  friend basic_string operator+(const basic_string &, const basic_string &) {}
+};
+typedef basic_string string;
+typedef basic_string wstring;
+}
+
+void f(std::string) {}
+std::string g(std::string) {}
+
+int main() {
+  std::string mystr1, mystr2;
+  std::wstring mywstr1, mywstr2;
+
+  for (int i = 0; i < 10; ++i) {
+f(mystr1 + mystr2 + mystr1);
+// CHECK-MESSAGES: :[[@LINE-1]]:23: warning: string concatenation results in allocation of unnecessary temporary strings; consider using 'operator+=' or 'string::append()' instead
+mystr1 = mystr1 + mystr2;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: string concatenation
+mystr1 = mystr2 + mystr2 + mystr2;
+// CHECK-MESSAGES: :[[@LINE-1]]:30: warning: string concatenation
+mystr1 = mystr2 + mystr1;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: string concatenation
+mywstr1 = mywstr2 + mywstr1;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: string concatenation
+mywstr1 = mywstr2 + mywstr2 + mywstr2;
+// CHECK-MESSAGES: :[[@LINE-1]]:33: warning: string concatenation
+
+mywstr1 = mywstr2 + mywstr2;
+mystr1 = mystr2 + mystr2;
+mystr1 += mystr2;
+f(mystr2 + mystr1);
+mystr1 = g(mystr1);
+  }
+  return 0;
+}
Index: docs/clang-tidy/checks/performance-inefficient-string-concatenation.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/performance-inefficient-string-concatenation.rst
@@ -0,0 +1,49 @@
+.. title:: clang-tidy - performance-inefficient-string-concatenation
+
+performance-inefficient-string-concatenation
+
+
+This check warns about the performance overhead arising from concatenating strings using the ``operator+``, for instance:
+
+.. code:: c++
+
+std::string a("Foo"), b("Bar");
+a = a + b;
+
+Instead of this structure you should use ``operator+=`` or ``std::string``'s (``std::basic_string``) class member function ``append()``. For instance:
+   
+.. code:: c++
+
+   std::string a("Foo"), b("Baz");
+   for (int i = 0; i < 2; ++i) {
+   a = a + "Bar" + b;
+   }
+
+Could be rewritten in a greatly more efficient way like:
+
+.. code:: c++
+
+   std::string a("Foo"), b("Baz");
+   for (int i = 0; i < 2; ++i) {
+   a.append("Bar").append(b);
+   } 
+
+And this can be rewritten too:
+
+.. code:: c++
+
+   void f(const std::string&) {}
+   std::string a("Foo"), b("Baz");
+   void g() {
+   f(a + "Bar" + b);
+   }
+
+In a slightly more efficient way like:
+
+.. code:: c++
+
+   void f(const std::string&) {}
+   std::string a("Foo"), b("Baz");
+   void g() {
+   f(std::string(a).append("Bar").append(b));
+   }
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -102,6 +102,7 @@
performance-faster-string-find
performance-for-range-copy
performance-implicit-cast-in-loop
+   performance-inefficient-string-concatenation
performance-unnecessary-copy-initialization
performance-unnecessary-value-param
readability-avoid-const-params-in-decls
Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -184,6 +184,12 @@
   Warns about range-based loop with a loop variable of const ref type where the
   type of the variable does not match the one returned by the iterator.
 
+- New `performance-inefficient-string-concatenation
+  `_ check
+
+  This check is to warn about the performance overhead arising from concatenating 
+  strings, using the ``operator+``, instead of ``operator+=``.
+  
 - New `performance-unnecessary-value-param
   `_

Re: [PATCH] D20196: [clang-tidy] Inefficient string operation

[Bittner Barni via cfe-commits]

bittnerbarni added inline comments.


Comment at: clang-tidy/performance/InefficientStringConcatenationCheck.cpp:55
@@ +54,3 @@
+ hasDeclaration(decl(equalsBoundNode("lhsStrT"))),
+  hasDescendant(BasicStringPlusOperator));
+

Yes this is the result of clang-format. 


https://reviews.llvm.org/D20196



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

[PATCH] D22770: [Sema, NFC] Reset HasFallthroughStmt when clearing FunctionScopeInfo

[Erik Pilkington via cfe-commits]

erik.pilkington created this revision.
erik.pilkington added a reviewer: rsmith.
erik.pilkington added a subscriber: cfe-commits.

The FunctionScopeInfo stack in Sema uses an optimization where the memory for 
the top-level functions is reused. The function FunctionScopeInfo::Clear() is 
used to reset this memory to the original, marking all the flags as false. The 
flag HasFallthroughStmt was omitted from this, meaning that once it set, it 
remained so for the rest of the TU. This meant we ran 
DiagnoseSwitchLabelsFallthrough() for every top level function in a TU where 
one function used `[[fallthrough]]`.

Thanks!

https://reviews.llvm.org/D22770

Files:
  lib/Sema/ScopeInfo.cpp

Index: lib/Sema/ScopeInfo.cpp
===
--- lib/Sema/ScopeInfo.cpp
+++ lib/Sema/ScopeInfo.cpp
@@ -29,6 +29,7 @@
   HasIndirectGoto = false;
   HasDroppedStmt = false;
   HasOMPDeclareReductionCombiner = false;
+  HasFallthroughStmt = false;
   ObjCShouldCallSuper = false;
   ObjCIsDesignatedInit = false;
   ObjCWarnForNoDesignatedInitChain = false;


Index: lib/Sema/ScopeInfo.cpp
===
--- lib/Sema/ScopeInfo.cpp
+++ lib/Sema/ScopeInfo.cpp
@@ -29,6 +29,7 @@
   HasIndirectGoto = false;
   HasDroppedStmt = false;
   HasOMPDeclareReductionCombiner = false;
+  HasFallthroughStmt = false;
   ObjCShouldCallSuper = false;
   ObjCIsDesignatedInit = false;
   ObjCWarnForNoDesignatedInitChain = false;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[ReviewRequest] [Sema/Parser] GCC Compatibility Patch: Support for __final specifier

[Keane, Erich via cfe-commits]

Hi all, my first potential-contribution, so I apologize if I'm submitting this 
improperly, I'm unfamiliar with the 'type' keys that you use in the topic, so 
hopefully I have this right.

As reported in bug 28473, GCC supports 'final' functionality in pre-C++11 code 
using the __final keyword.  Clang currently supports the 'final' keyword in 
accordance with the C++11 specification, however it ALSO supports it in 
pre-C++11 mode, with a warning.

This patch adds the '__final' keyword for compatibility with GCC in GCC 
Keywords mode (so it is enabled with existing flags), and issues a warning on 
its usage (suggesting switching to the C++11 keyword).  This patch also adds a 
regression test for the functionality described.  I believe this patch has 
minimal impact, as it simply adds a new keyword for existing behavior.

This has been validated with check-clang to avoid regressions.  Patch is 
created in reference to revisions 276665

Thanks,
Erich


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

Re: [PATCH] D22584: constexpr array support C++1z (P0031)

[Jason Turner via cfe-commits]

lefticus updated this revision to Diff 65390.
lefticus added a comment.

Fixed syntax errors in test files.


https://reviews.llvm.org/D22584

Files:
  include/array
  include/iterator
  test/std/containers/sequences/array/at.pass.cpp
  test/std/containers/sequences/array/begin.pass.cpp
  test/std/containers/sequences/array/front_back.pass.cpp
  test/std/containers/sequences/array/indexing.pass.cpp
  test/std/containers/sequences/array/iterators.pass.cpp
  test/std/iterators/iterator.primitives/iterator.operations/advance.pass.cpp
  test/std/iterators/iterator.primitives/iterator.operations/distance.pass.cpp
  test/std/iterators/iterator.primitives/iterator.operations/next.pass.cpp
  test/std/iterators/iterator.primitives/iterator.operations/prev.pass.cpp

Index: test/std/iterators/iterator.primitives/iterator.operations/prev.pass.cpp
===
--- test/std/iterators/iterator.primitives/iterator.operations/prev.pass.cpp
+++ test/std/iterators/iterator.primitives/iterator.operations/prev.pass.cpp
@@ -33,12 +33,21 @@
 
 int main()
 {
-const char* s = "1234567890";
-test(bidirectional_iterator(s+10), 10, bidirectional_iterator(s));
-test(random_access_iterator(s+10), 10, random_access_iterator(s));
-test(s+10, 10, s);
-
-test(bidirectional_iterator(s+1), bidirectional_iterator(s));
-test(random_access_iterator(s+1), random_access_iterator(s));
-test(s+1, s);
+{
+const char* s = "1234567890";
+test(bidirectional_iterator(s+10), 10, bidirectional_iterator(s));
+test(random_access_iterator(s+10), 10, random_access_iterator(s));
+test(s+10, 10, s);
+
+test(bidirectional_iterator(s+1), bidirectional_iterator(s));
+test(random_access_iterator(s+1), random_access_iterator(s));
+test(s+1, s);
+}
+
+{
+constexpr const char* s = "1234567890";
+static_assert(std::prev(s+10, 10) == s);
+static_assert(std::prev(s+1) == s);
+}
+
 }
Index: test/std/iterators/iterator.primitives/iterator.operations/next.pass.cpp
===
--- test/std/iterators/iterator.primitives/iterator.operations/next.pass.cpp
+++ test/std/iterators/iterator.primitives/iterator.operations/next.pass.cpp
@@ -35,16 +35,27 @@
 
 int main()
 {
-const char* s = "1234567890";
-test(input_iterator(s), 10, input_iterator(s+10));
-test(forward_iterator(s), 10, forward_iterator(s+10));
-test(bidirectional_iterator(s), 10, bidirectional_iterator(s+10));
-test(random_access_iterator(s), 10, random_access_iterator(s+10));
-test(s, 10, s+10);
-
-test(input_iterator(s), input_iterator(s+1));
-test(forward_iterator(s), forward_iterator(s+1));
-test(bidirectional_iterator(s), bidirectional_iterator(s+1));
-test(random_access_iterator(s), random_access_iterator(s+1));
-test(s, s+1);
+{
+const char* s = "1234567890";
+test(input_iterator(s), 10, input_iterator(s+10));
+test(forward_iterator(s), 10, forward_iterator(s+10));
+test(bidirectional_iterator(s), 10, bidirectional_iterator(s+10));
+test(random_access_iterator(s), 10, random_access_iterator(s+10));
+test(s, 10, s+10);
+
+test(input_iterator(s), input_iterator(s+1));
+test(forward_iterator(s), forward_iterator(s+1));
+test(bidirectional_iterator(s), bidirectional_iterator(s+1));
+test(random_access_iterator(s), random_access_iterator(s+1));
+test(s, s+1);
+}
+
+#if TEST_STD_VER > 14
+{
+constexpr const char* s = "1234567890";
+static_assert(std::next(s, 10) == s+10);
+static_assert(std::next(s) == s+1);
+}
+#endif
+
 }
Index: test/std/iterators/iterator.primitives/iterator.operations/distance.pass.cpp
===
--- test/std/iterators/iterator.primitives/iterator.operations/distance.pass.cpp
+++ test/std/iterators/iterator.primitives/iterator.operations/distance.pass.cpp
@@ -31,10 +31,21 @@
 
 int main()
 {
-const char* s = "1234567890";
-test(input_iterator(s), input_iterator(s+10), 10);
-test(forward_iterator(s), forward_iterator(s+10), 10);
-test(bidirectional_iterator(s), bidirectional_iterator(s+10), 10);
-test(random_access_iterator(s), random_access_iterator(s+10), 10);
-test(s, s+10, 10);
+{
+const char* s = "1234567890";
+test(input_iterator(s), input_iterator(s+10), 10);
+test(forward_iterator(s), forward_iterator(s+10), 10);
+test(bidirectional_iterator(s), bidirectional_iterator(s+10), 10);
+test(random_access_iterator(s), random_access_iterator(s+10), 10);
+test(s, s+10, 10);
+}
+
+
+#if TEST_STD_VER > 14
+{
+constexpr const char* s = "1234567890";
+static_assert(std::distance(s, s+10) == 10);
+}
+#endif
+
 }
Index: test/std/iterators/iterato

Re: [PATCH] D20196: [clang-tidy] Inefficient string operation

[Alexander Kornienko via cfe-commits]

alexfh added a comment.

A couple of nits.



Comment at: clang-tidy/performance/InefficientStringConcatenationCheck.cpp:51
@@ +50,3 @@
+  hasArgument(
+  0, declRefExpr(BasicStringType),
+  declRefExpr(hasDeclaration(decl().bind("lhsStrT"))).bind("lhsStr")),

As noted earlier, there's no need to repeat `declRefExpr`. This should be:

  declRefExpr(BasicStringType, hasDeclaration(decl().bind("lhsStrT")))


Comment at: clang-tidy/performance/InefficientStringConcatenationCheck.h:25
@@ +24,3 @@
+class InefficientStringConcatenationCheck : public ClangTidyCheck {
+ public:
+  InefficientStringConcatenationCheck(StringRef Name, ClangTidyContext 
*Context);

Please format the file with `clang-format -style=llvm`.


https://reviews.llvm.org/D20196



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

Re: [PATCH] D19544: Pass for translating math intrinsics to math library calls.

[Hal Finkel via cfe-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D19544#492258, @mmasten wrote:

> I think this is just saying that some of the weird types are not supported on 
> all targets. For now, is it ok to proceed with checking this code in?


Correct.

In https://reviews.llvm.org/D19544#493403, @mmasten wrote:

> Thanks Michael. The tests have been updated.
>
> Matt


Do you need someone to commit this for you?


https://reviews.llvm.org/D19544



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

Re: [PATCH] D22654: [Clang-rename] Remove custom version, fix extra space in error message

[Kirill Bobyrev via cfe-commits]

omtcyfz added a comment.

lgtm


Repository:
  rL LLVM

https://reviews.llvm.org/D22654



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

Re: [PATCH] D22584: constexpr array support C++1z (P0031)

[Jason Turner via cfe-commits]

lefticus marked 3 inline comments as done.
lefticus added a comment.

https://reviews.llvm.org/D22584



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

Re: [PATCH] D22584: constexpr array support C++1z (P0031)

[Jason Turner via cfe-commits]

lefticus added a comment.

I believe I messed up the context for the files, will attempt to resubmit the 
patch.


https://reviews.llvm.org/D22584



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

Re: [PATCH] D22505: clang-format Access Modifier Use Normal Indent

[Loki Astari via cfe-commits]

LokiAstari added a comment.

Hope you don't mind me chiming in:

> Roughly go ahead with what you are suggesting, although the option should not 
> be called AccessModifierStandardIndent, as that carries no meaning and 
> actually is far from the "standard" way. Reasonable names that spring to mind 
> are:


Though I personally disagree on the more standard technique :-)  Since I am the 
newbie to this I am not going to fight on that point (though I suspect if we 
meet up for some beers we could have a spirited debate).

> AccessModifiersCauseAdditionalIndent or 
> (Additional)IndentAfterAccessModifiers.


How about "AccessModifiersUseNormaIndent" as we are indenting by a normal 
indent width. But I am not going to fight over the name when it comes down to 
it.

> Be even more "clever" with AccessModifierOffset (I can come up with various 
> ways from negative numbers to special numbers, none of them really good).


I don't think this is a good idea (but as the newbie no strong feelings). 
Unfortunately a lot of large projects have stated using this is a standard part 
of their formatting; got to this project too late to prevent that :-O

> Deprecate AccessModifierOffset and instead use an enum with a few dedicated 
> settings.


The issue with this is getting all projects to update their settings with the 
new version. Not sure this is a great user experience.


https://reviews.llvm.org/D22505



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

r276674 - [CMake] Cleaning up some CMake warnings

[Chris Bieneman via cfe-commits]

Author: cbieneman
Date: Mon Jul 25 13:54:30 2016
New Revision: 276674

URL: http://llvm.org/viewvc/llvm-project?rev=276674&view=rev
Log:
[CMake] Cleaning up some CMake warnings

In Bootstrap builds Clang logs some warnings. These are caused because Clang 
passes CLANG_STAGE and BOOTSTRAP_DEFAULT_PASSTHROUGH into the next stage's 
configuration.

BOOTSTRAP_DEFAULT_PASSTHROUGH shouldn't be passed, so it is renamed to 
_BOOTSTRAP_DEFAULT_PASSTHROUGH, to prevent passthrough.

CLANG_STAGE should be passed, so I've changed the code to log it if it is set 
outside the if(CLANG_ENABLE_BOOTSTRAP) block. This makes the variable always 
used, so the warning goes away.

Modified:
cfe/trunk/CMakeLists.txt

Modified: cfe/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/CMakeLists.txt?rev=276674&r1=276673&r2=276674&view=diff
==
--- cfe/trunk/CMakeLists.txt (original)
+++ cfe/trunk/CMakeLists.txt Mon Jul 25 13:54:30 2016
@@ -463,12 +463,15 @@ endif()
 
 add_subdirectory(cmake/modules)
 
+if(CLANG_STAGE)
+  message(STATUS "Setting current clang stage to: ${CLANG_STAGE}")
+endif()
+
 if (CLANG_ENABLE_BOOTSTRAP)
   include(ExternalProject)
 
   if(NOT CLANG_STAGE)
 set(CLANG_STAGE stage1)
-message(STATUS "Setting current clang stage to: ${CLANG_STAGE}")
   endif()
 
   string(REGEX MATCH "stage([0-9]*)" MATCHED_STAGE "${CLANG_STAGE}")
@@ -526,7 +529,7 @@ if (CLANG_ENABLE_BOOTSTRAP)
 set(verbose -DCMAKE_VERBOSE_MAKEFILE=On)
   endif()
 
-  set(BOOTSTRAP_DEFAULT_PASSTHROUGH
+  set(_BOOTSTRAP_DEFAULT_PASSTHROUGH
 PACKAGE_VERSION
 LLVM_VERSION_MAJOR
 LLVM_VERSION_MINOR
@@ -577,7 +580,7 @@ if (CLANG_ENABLE_BOOTSTRAP)
   endforeach()
 
   # Populate the passthrough variables
-  foreach(variableName ${CLANG_BOOTSTRAP_PASSTHROUGH} 
${BOOTSTRAP_DEFAULT_PASSTHROUGH})
+  foreach(variableName ${CLANG_BOOTSTRAP_PASSTHROUGH} 
${_BOOTSTRAP_DEFAULT_PASSTHROUGH})
 if(${variableName})
   string(REPLACE ";" "\;" value ${${variableName}})
   list(APPEND PASSTHROUGH_VARIABLES


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

Re: [PATCH] D22584: constexpr array support C++1z (P0031)

[Jason Turner via cfe-commits]

lefticus updated this revision to Diff 65398.
lefticus added a comment.

Correct context from last patch


https://reviews.llvm.org/D22584

Files:
  include/array
  include/iterator
  test/std/containers/sequences/array/at.pass.cpp
  test/std/containers/sequences/array/begin.pass.cpp
  test/std/containers/sequences/array/front_back.pass.cpp
  test/std/containers/sequences/array/indexing.pass.cpp
  test/std/containers/sequences/array/iterators.pass.cpp
  test/std/iterators/iterator.primitives/iterator.operations/advance.pass.cpp
  test/std/iterators/iterator.primitives/iterator.operations/distance.pass.cpp
  test/std/iterators/iterator.primitives/iterator.operations/next.pass.cpp
  test/std/iterators/iterator.primitives/iterator.operations/prev.pass.cpp

Index: test/std/iterators/iterator.primitives/iterator.operations/prev.pass.cpp
===
--- test/std/iterators/iterator.primitives/iterator.operations/prev.pass.cpp
+++ test/std/iterators/iterator.primitives/iterator.operations/prev.pass.cpp
@@ -33,12 +33,21 @@
 
 int main()
 {
-const char* s = "1234567890";
-test(bidirectional_iterator(s+10), 10, bidirectional_iterator(s));
-test(random_access_iterator(s+10), 10, random_access_iterator(s));
-test(s+10, 10, s);
-
-test(bidirectional_iterator(s+1), bidirectional_iterator(s));
-test(random_access_iterator(s+1), random_access_iterator(s));
-test(s+1, s);
+{
+const char* s = "1234567890";
+test(bidirectional_iterator(s+10), 10, bidirectional_iterator(s));
+test(random_access_iterator(s+10), 10, random_access_iterator(s));
+test(s+10, 10, s);
+
+test(bidirectional_iterator(s+1), bidirectional_iterator(s));
+test(random_access_iterator(s+1), random_access_iterator(s));
+test(s+1, s);
+}
+
+{
+constexpr const char* s = "1234567890";
+static_assert(std::prev(s+10, 10) == s);
+static_assert(std::prev(s+1) == s);
+}
+
 }
Index: test/std/iterators/iterator.primitives/iterator.operations/next.pass.cpp
===
--- test/std/iterators/iterator.primitives/iterator.operations/next.pass.cpp
+++ test/std/iterators/iterator.primitives/iterator.operations/next.pass.cpp
@@ -35,16 +35,27 @@
 
 int main()
 {
-const char* s = "1234567890";
-test(input_iterator(s), 10, input_iterator(s+10));
-test(forward_iterator(s), 10, forward_iterator(s+10));
-test(bidirectional_iterator(s), 10, bidirectional_iterator(s+10));
-test(random_access_iterator(s), 10, random_access_iterator(s+10));
-test(s, 10, s+10);
-
-test(input_iterator(s), input_iterator(s+1));
-test(forward_iterator(s), forward_iterator(s+1));
-test(bidirectional_iterator(s), bidirectional_iterator(s+1));
-test(random_access_iterator(s), random_access_iterator(s+1));
-test(s, s+1);
+{
+const char* s = "1234567890";
+test(input_iterator(s), 10, input_iterator(s+10));
+test(forward_iterator(s), 10, forward_iterator(s+10));
+test(bidirectional_iterator(s), 10, bidirectional_iterator(s+10));
+test(random_access_iterator(s), 10, random_access_iterator(s+10));
+test(s, 10, s+10);
+
+test(input_iterator(s), input_iterator(s+1));
+test(forward_iterator(s), forward_iterator(s+1));
+test(bidirectional_iterator(s), bidirectional_iterator(s+1));
+test(random_access_iterator(s), random_access_iterator(s+1));
+test(s, s+1);
+}
+
+#if TEST_STD_VER > 14
+{
+constexpr const char* s = "1234567890";
+static_assert(std::next(s, 10) == s+10);
+static_assert(std::next(s) == s+1);
+}
+#endif
+
 }
Index: test/std/iterators/iterator.primitives/iterator.operations/distance.pass.cpp
===
--- test/std/iterators/iterator.primitives/iterator.operations/distance.pass.cpp
+++ test/std/iterators/iterator.primitives/iterator.operations/distance.pass.cpp
@@ -31,10 +31,21 @@
 
 int main()
 {
-const char* s = "1234567890";
-test(input_iterator(s), input_iterator(s+10), 10);
-test(forward_iterator(s), forward_iterator(s+10), 10);
-test(bidirectional_iterator(s), bidirectional_iterator(s+10), 10);
-test(random_access_iterator(s), random_access_iterator(s+10), 10);
-test(s, s+10, 10);
+{
+const char* s = "1234567890";
+test(input_iterator(s), input_iterator(s+10), 10);
+test(forward_iterator(s), forward_iterator(s+10), 10);
+test(bidirectional_iterator(s), bidirectional_iterator(s+10), 10);
+test(random_access_iterator(s), random_access_iterator(s+10), 10);
+test(s, s+10, 10);
+}
+
+
+#if TEST_STD_VER > 14
+{
+constexpr const char* s = "1234567890";
+static_assert(std::distance(s, s+10) == 10);
+}
+#endif
+
 }
Index: test/std/iterators/iterator.p

Re: [PATCH] D22584: constexpr array support C++1z (P0031)

[Jason Turner via cfe-commits]

lefticus added a comment.

I believe all or most of the "untested" comments are correctly tested in the 
updated test files via static_asserts with contexpr. I've commented on just the 
first one to make sure I understand correctly.



Comment at: include/array:156
@@ -155,3 +155,3 @@
 _LIBCPP_INLINE_VISIBILITY
-iterator begin() _NOEXCEPT {return iterator(__elems_);}
+_LIBCPP_CONSTEXPR_AFTER_CXX14 iterator begin() _NOEXCEPT {return 
iterator(__elems_);}
 _LIBCPP_INLINE_VISIBILITY

This should be tested in begin.pass.cpp:28 correct?


https://reviews.llvm.org/D22584



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

Re: [PATCH] D17820: Clang Code Completion Filtering

[Bianca-Cristina Cristescu via cfe-commits]

CrisCristescu updated this revision to Diff 65401.
CrisCristescu marked 3 inline comments as done.
CrisCristescu added a comment.

Addressing some sugesstions.


Repository:
  rL LLVM

https://reviews.llvm.org/D17820

Files:
  include/clang/Lex/Preprocessor.h
  include/clang/Sema/CodeCompleteConsumer.h
  lib/Lex/Lexer.cpp
  lib/Lex/Preprocessor.cpp
  lib/Sema/CodeCompleteConsumer.cpp
  test/CodeCompletion/filter-function-name.cpp
  test/CodeCompletion/filter-member-access.cpp
  test/CodeCompletion/filter-namespace.cpp
  test/CodeCompletion/filter-ordinary-name.cpp
  test/CodeCompletion/objc-message.mm
  test/Index/complete-method-decls.m
  test/Index/complete-objc-message-id.m
  test/Index/complete-objc-message.m
  test/Index/complete-recovery.m
  test/Index/complete-super.m

Index: test/Index/complete-super.m
===
--- test/Index/complete-super.m
+++ test/Index/complete-super.m
@@ -60,16 +60,16 @@
 // RUN: c-index-test -code-completion-at=%s:20:16 %s | FileCheck -check-prefix=CHECK-ADD-TO %s
 // CHECK-ADD-TO: ObjCInstanceMethodDecl:{ResultType void}{Informative add:}{TypedText to:}{Placeholder b} (20)
 
-// RUN: c-index-test -code-completion-at=%s:24:28 %s | FileCheck -check-prefix=CHECK-SELECTOR-FIRST %s
+// RUN: c-index-test -code-completion-at=%s:24:29 %s | FileCheck -check-prefix=CHECK-SELECTOR-FIRST %s
 // CHECK-SELECTOR-FIRST: ObjCClassMethodDecl:{ResultType void}{Informative select:}{TypedText first:}{Placeholder a}{HorizontalSpace  }{Text second:}{Placeholder b} (20)
 
 // Check "super" completion at the third identifier
 // RUN: c-index-test -code-completion-at=%s:24:37 %s | FileCheck -check-prefix=CHECK-SELECTOR-SECOND %s
 // CHECK-SELECTOR-SECOND: ObjCClassMethodDecl:{ResultType void}{Informative select:}{Informative first:}{TypedText second:}{Placeholder b} (20)
 
 // Check "super" completion with missing '['.
 // RUN: c-index-test -code-completion-at=%s:25:10 %s | FileCheck -check-prefix=CHECK-SELECTOR-SELECTOR %s
-// RUN: c-index-test -code-completion-at=%s:25:28 %s | FileCheck -check-prefix=CHECK-SELECTOR-FIRST %s
+// RUN: c-index-test -code-completion-at=%s:25:29 %s | FileCheck -check-prefix=CHECK-SELECTOR-FIRST %s
 // RUN: c-index-test -code-completion-at=%s:25:37 %s | FileCheck -check-prefix=CHECK-SELECTOR-SECOND %s
 
 // Check "super" completion for a method declared in a category.
Index: test/Index/complete-recovery.m
===
--- test/Index/complete-recovery.m
+++ test/Index/complete-recovery.m
@@ -26,7 +26,7 @@
 // Test case for fix committed in r145441.
 // RUN: env CINDEXTEST_CODE_COMPLETE_PATTERNS=1 c-index-test -code-completion-at=%s:9:20 %s -fms-compatibility | FileCheck -check-prefix=CHECK-CC1 %s
 
-// RUN: env CINDEXTEST_CODE_COMPLETE_PATTERNS=1 c-index-test -code-completion-at=%s:10:24 %s | FileCheck -check-prefix=CHECK-CC2 %s
+// RUN: env CINDEXTEST_CODE_COMPLETE_PATTERNS=1 c-index-test -code-completion-at=%s:10:25 %s | FileCheck -check-prefix=CHECK-CC2 %s
 // CHECK-CC2: NotImplemented:{ResultType char[]}{TypedText @encode}{LeftParen (}{Placeholder type-name}{RightParen )}
 // CHECK-CC2: NotImplemented:{TypedText _Bool}
 // CHECK-CC2: VarDecl:{ResultType A *}{TypedText a}
Index: test/Index/complete-objc-message.m
===
--- test/Index/complete-objc-message.m
+++ test/Index/complete-objc-message.m
@@ -218,13 +218,13 @@
 // CHECK-CC2-NEXT: Container Kind: ObjCInterfaceDecl
 // CHECK-CC2-NEXT: Container is complete
 // CHECK-CC2-NEXT: Container USR: c:objc(cs)Foo
-// RUN: c-index-test -code-completion-at=%s:61:16 %s | FileCheck -check-prefix=CHECK-CC3 %s
+// RUN: c-index-test -code-completion-at=%s:61:17 %s | FileCheck -check-prefix=CHECK-CC3 %s
 // CHECK-CC3: ObjCClassMethodDecl:{ResultType int}{TypedText MyClassMethod:}{Placeholder (id)}
 // CHECK-CC3: ObjCClassMethodDecl:{ResultType int}{TypedText MyPrivateMethod}
-// RUN: c-index-test -code-completion-at=%s:65:16 %s | FileCheck -check-prefix=CHECK-CC4 %s
+// RUN: c-index-test -code-completion-at=%s:65:17 %s | FileCheck -check-prefix=CHECK-CC4 %s
 // CHECK-CC4: ObjCInstanceMethodDecl:{ResultType int}{TypedText MyInstMethod:}{Placeholder (id)}{HorizontalSpace  }{TypedText second:}{Placeholder (id)}
 // CHECK-CC4: ObjCInstanceMethodDecl:{ResultType int}{TypedText MyPrivateInstMethod}
-// RUN: c-index-test -code-completion-at=%s:74:9 %s | FileCheck -check-prefix=CHECK-CC5 %s
+// RUN: c-index-test -code-completion-at=%s:74:10 %s | FileCheck -check-prefix=CHECK-CC5 %s
 // CHECK-CC5: ObjCInstanceMethodDecl:{ResultType int}{TypedText MyInstMethod:}{Placeholder (id)}{HorizontalSpace  }{TypedText second:}{Placeholder (id)}
 // CHECK-CC5: ObjCInstanceMethodDecl:{ResultType int}{TypedText MySubInstMethod}
 // RUN: c-index-test -code-completion-at=%s:82:8 %s | FileCheck -check-prefix=CHECK-CC6 %s
@@ -311,7 +311,7 @@
 // CHECK-CCI: ObjCInstanceMethodDecl:{Res

Re: [ReviewRequest] [Sema/Parser] GCC Compatibility Patch: Support for __final specifier

[David Majnemer via cfe-commits]

I'd rename VS_Alt_Final to VS_GNU_Final.

On Mon, Jul 25, 2016 at 2:24 PM, Keane, Erich via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Hi all, my first potential-contribution, so I apologize if I’m submitting
> this improperly, I’m unfamiliar with the ‘type’ keys that you use in the
> topic, so hopefully I have this right.
>
>
>
> As reported in bug 28473, GCC supports ‘final’ functionality in pre-C++11
> code using the __final keyword.  Clang currently supports the ‘final’
> keyword in accordance with the C++11 specification, however it ALSO
> supports it in pre-C++11 mode, with a warning.
>
>
>
> This patch adds the ‘__final’ keyword for compatibility with GCC in GCC
> Keywords mode (so it is enabled with existing flags), and issues a warning
> on its usage (suggesting switching to the C++11 keyword).  This patch also
> adds a regression test for the functionality described.  I believe this
> patch has minimal impact, as it simply adds a new keyword for existing
> behavior.
>
>
>
> This has been validated with check-clang to avoid regressions.  Patch is
> created in reference to revisions 276665
>
>
>
> Thanks,
>
> Erich
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D17820: Clang Code Completion Filtering

[Bianca-Cristina Cristescu via cfe-commits]

CrisCristescu updated this revision to Diff 65403.
CrisCristescu marked an inline comment as done.
CrisCristescu added a comment.

PP CodeCompletionII initialisation.


Repository:
  rL LLVM

https://reviews.llvm.org/D17820

Files:
  include/clang/Lex/Preprocessor.h
  include/clang/Sema/CodeCompleteConsumer.h
  lib/Lex/Lexer.cpp
  lib/Lex/Preprocessor.cpp
  lib/Sema/CodeCompleteConsumer.cpp
  test/CodeCompletion/filter-function-name.cpp
  test/CodeCompletion/filter-member-access.cpp
  test/CodeCompletion/filter-namespace.cpp
  test/CodeCompletion/filter-ordinary-name.cpp
  test/CodeCompletion/objc-message.mm
  test/Index/complete-method-decls.m
  test/Index/complete-objc-message-id.m
  test/Index/complete-objc-message.m
  test/Index/complete-recovery.m
  test/Index/complete-super.m

Index: test/Index/complete-super.m
===
--- test/Index/complete-super.m
+++ test/Index/complete-super.m
@@ -60,16 +60,16 @@
 // RUN: c-index-test -code-completion-at=%s:20:16 %s | FileCheck -check-prefix=CHECK-ADD-TO %s
 // CHECK-ADD-TO: ObjCInstanceMethodDecl:{ResultType void}{Informative add:}{TypedText to:}{Placeholder b} (20)
 
-// RUN: c-index-test -code-completion-at=%s:24:28 %s | FileCheck -check-prefix=CHECK-SELECTOR-FIRST %s
+// RUN: c-index-test -code-completion-at=%s:24:29 %s | FileCheck -check-prefix=CHECK-SELECTOR-FIRST %s
 // CHECK-SELECTOR-FIRST: ObjCClassMethodDecl:{ResultType void}{Informative select:}{TypedText first:}{Placeholder a}{HorizontalSpace  }{Text second:}{Placeholder b} (20)
 
 // Check "super" completion at the third identifier
 // RUN: c-index-test -code-completion-at=%s:24:37 %s | FileCheck -check-prefix=CHECK-SELECTOR-SECOND %s
 // CHECK-SELECTOR-SECOND: ObjCClassMethodDecl:{ResultType void}{Informative select:}{Informative first:}{TypedText second:}{Placeholder b} (20)
 
 // Check "super" completion with missing '['.
 // RUN: c-index-test -code-completion-at=%s:25:10 %s | FileCheck -check-prefix=CHECK-SELECTOR-SELECTOR %s
-// RUN: c-index-test -code-completion-at=%s:25:28 %s | FileCheck -check-prefix=CHECK-SELECTOR-FIRST %s
+// RUN: c-index-test -code-completion-at=%s:25:29 %s | FileCheck -check-prefix=CHECK-SELECTOR-FIRST %s
 // RUN: c-index-test -code-completion-at=%s:25:37 %s | FileCheck -check-prefix=CHECK-SELECTOR-SECOND %s
 
 // Check "super" completion for a method declared in a category.
Index: test/Index/complete-recovery.m
===
--- test/Index/complete-recovery.m
+++ test/Index/complete-recovery.m
@@ -26,7 +26,7 @@
 // Test case for fix committed in r145441.
 // RUN: env CINDEXTEST_CODE_COMPLETE_PATTERNS=1 c-index-test -code-completion-at=%s:9:20 %s -fms-compatibility | FileCheck -check-prefix=CHECK-CC1 %s
 
-// RUN: env CINDEXTEST_CODE_COMPLETE_PATTERNS=1 c-index-test -code-completion-at=%s:10:24 %s | FileCheck -check-prefix=CHECK-CC2 %s
+// RUN: env CINDEXTEST_CODE_COMPLETE_PATTERNS=1 c-index-test -code-completion-at=%s:10:25 %s | FileCheck -check-prefix=CHECK-CC2 %s
 // CHECK-CC2: NotImplemented:{ResultType char[]}{TypedText @encode}{LeftParen (}{Placeholder type-name}{RightParen )}
 // CHECK-CC2: NotImplemented:{TypedText _Bool}
 // CHECK-CC2: VarDecl:{ResultType A *}{TypedText a}
Index: test/Index/complete-objc-message.m
===
--- test/Index/complete-objc-message.m
+++ test/Index/complete-objc-message.m
@@ -218,13 +218,13 @@
 // CHECK-CC2-NEXT: Container Kind: ObjCInterfaceDecl
 // CHECK-CC2-NEXT: Container is complete
 // CHECK-CC2-NEXT: Container USR: c:objc(cs)Foo
-// RUN: c-index-test -code-completion-at=%s:61:16 %s | FileCheck -check-prefix=CHECK-CC3 %s
+// RUN: c-index-test -code-completion-at=%s:61:17 %s | FileCheck -check-prefix=CHECK-CC3 %s
 // CHECK-CC3: ObjCClassMethodDecl:{ResultType int}{TypedText MyClassMethod:}{Placeholder (id)}
 // CHECK-CC3: ObjCClassMethodDecl:{ResultType int}{TypedText MyPrivateMethod}
-// RUN: c-index-test -code-completion-at=%s:65:16 %s | FileCheck -check-prefix=CHECK-CC4 %s
+// RUN: c-index-test -code-completion-at=%s:65:17 %s | FileCheck -check-prefix=CHECK-CC4 %s
 // CHECK-CC4: ObjCInstanceMethodDecl:{ResultType int}{TypedText MyInstMethod:}{Placeholder (id)}{HorizontalSpace  }{TypedText second:}{Placeholder (id)}
 // CHECK-CC4: ObjCInstanceMethodDecl:{ResultType int}{TypedText MyPrivateInstMethod}
-// RUN: c-index-test -code-completion-at=%s:74:9 %s | FileCheck -check-prefix=CHECK-CC5 %s
+// RUN: c-index-test -code-completion-at=%s:74:10 %s | FileCheck -check-prefix=CHECK-CC5 %s
 // CHECK-CC5: ObjCInstanceMethodDecl:{ResultType int}{TypedText MyInstMethod:}{Placeholder (id)}{HorizontalSpace  }{TypedText second:}{Placeholder (id)}
 // CHECK-CC5: ObjCInstanceMethodDecl:{ResultType int}{TypedText MySubInstMethod}
 // RUN: c-index-test -code-completion-at=%s:82:8 %s | FileCheck -check-prefix=CHECK-CC6 %s
@@ -311,7 +311,7 @@
 // CHECK-CCI: ObjCInstanceMethodDe

Re: [PATCH] D21962: MPITypeMismatchCheck for Clang-Tidy

[Alexander Droste via cfe-commits]

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

Hi, thanks for the notification! Obviously, on some systems `char` is unsigned 
by default 
which is why the check now tolerates distinct signedness for char pairs.
http://blog.cdleary.com/2012/11/arm-chars-are-unsigned-by-default/
In addition, I removed the trailing white space from the test file.


https://reviews.llvm.org/D21962

Files:
  clang-tidy/CMakeLists.txt
  clang-tidy/mpi/CMakeLists.txt
  clang-tidy/mpi/MPITidyModule.cpp
  clang-tidy/mpi/TypeMismatchCheck.cpp
  clang-tidy/mpi/TypeMismatchCheck.h
  clang-tidy/plugin/CMakeLists.txt
  clang-tidy/tool/CMakeLists.txt
  clang-tidy/tool/ClangTidyMain.cpp
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/mpi-type-mismatch.rst
  test/clang-tidy/Inputs/mpi-type-mismatch/mpimock.h
  test/clang-tidy/mpi-type-mismatch.cpp

Index: test/clang-tidy/mpi-type-mismatch.cpp
===
--- /dev/null
+++ test/clang-tidy/mpi-type-mismatch.cpp
@@ -0,0 +1,255 @@
+// RUN: %check_clang_tidy %s mpi-type-mismatch %t -- -- -I %S/Inputs/mpi-type-mismatch
+
+#include "mpimock.h"
+
+void charNegativeTest() {
+  int buf;
+  MPI_Send(&buf, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD);
+  // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'int' does not match the MPI datatype 'MPI_CHAR'
+
+  short buf2;
+  MPI_Send(&buf2, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD);
+  // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'short' does not match the MPI datatype 'MPI_CHAR'
+
+  long buf3;
+  MPI_Send(&buf3, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD);
+  // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'long' does not match the MPI datatype 'MPI_CHAR'
+
+  int8_t buf4;
+  MPI_Send(&buf4, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD);
+  // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'int8_t' does not match the MPI datatype 'MPI_CHAR'
+
+  uint16_t buf5;
+  MPI_Send(&buf5, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD);
+  // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'uint16_t' does not match the MPI datatype 'MPI_CHAR'
+
+  long double _Complex buf6;
+  MPI_Send(&buf6, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD);
+  // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'long double _Complex' does not match the MPI datatype 'MPI_CHAR'
+
+  std::complex buf7;
+  MPI_Send(&buf7, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD);
+  // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'complex' does not match the MPI datatype 'MPI_CHAR'
+}
+
+void intNegativeTest() {
+  unsigned char buf;
+  MPI_Send(&buf, 1, MPI_INT, 0, 0, MPI_COMM_WORLD);
+  // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'unsigned char' does not match the MPI datatype 'MPI_INT'
+
+  unsigned buf2;
+  MPI_Send(&buf2, 1, MPI_INT, 0, 0, MPI_COMM_WORLD);
+  // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'unsigned int' does not match the MPI datatype 'MPI_INT'
+
+  short buf3;
+  MPI_Send(&buf3, 1, MPI_INT, 0, 0, MPI_COMM_WORLD);
+  // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'short' does not match the MPI datatype 'MPI_INT'
+
+  long buf4;
+  MPI_Send(&buf4, 1, MPI_INT, 0, 0, MPI_COMM_WORLD);
+  // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'long' does not match the MPI datatype 'MPI_INT'
+
+  int8_t buf5;
+  MPI_Send(&buf5, 1, MPI_INT, 0, 0, MPI_COMM_WORLD);
+  // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'int8_t' does not match the MPI datatype 'MPI_INT'
+
+  uint16_t buf6;
+  MPI_Send(&buf6, 1, MPI_INT, 0, 0, MPI_COMM_WORLD);
+  // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'uint16_t' does not match the MPI datatype 'MPI_INT'
+
+  long double _Complex buf7;
+  MPI_Send(&buf7, 1, MPI_INT, 0, 0, MPI_COMM_WORLD);
+  // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'long double _Complex' does not match the MPI datatype 'MPI_INT'
+
+  std::complex buf8;
+  MPI_Send(&buf8, 1, MPI_INT, 0, 0, MPI_COMM_WORLD);
+  // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'complex' does not match the MPI datatype 'MPI_INT'
+}
+
+void longNegativeTest() {
+  char buf;
+  MPI_Send(&buf, 1, MPI_LONG, 0, 0, MPI_COMM_WORLD);
+  // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'char' does not match the MPI datatype 'MPI_LONG'
+
+  unsigned buf2;
+  MPI_Send(&buf2, 1, MPI_LONG, 0, 0, MPI_COMM_WORLD);
+  // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'unsigned int' does not match the MPI datatype 'MPI_LONG'
+
+  unsigned short buf3;
+  MPI_Send(&buf3, 1, MPI_LONG, 0, 0, MPI_COMM_WORLD);
+  // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'unsigned short' does not match the MPI datatype 'MPI_LONG'
+
+  unsigned long buf4;
+  MPI_Send(&buf4, 1, MPI_LONG, 0, 0, MPI_COMM_WORLD);
+  // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: buffer type 'unsigned long' does not match the MPI datatype 'MPI_LONG'
+
+  int8_t buf5;
+  MPI_Send(&buf5, 1, MPI_LONG, 0, 0

[PATCH] D22773: Modules: add command line option fmodules-disable-diagnostic-validation to disable validation of the diagnostic options when loading the module

[Manman Ren via cfe-commits]

manmanren created this revision.
manmanren added a reviewer: benlangmuir.
manmanren added a subscriber: cfe-commits.

With PCH+Module, sometimes compiler gives a hard error:
"Module file ‘.pcm' is out of date and needs to be rebuilt"

This happens when we have a PCH importing a module and the module gets 
overwritten by another compiler instance after we build the pch (one example is 
that both compiler instances hash to the same pcm file but use different 
diagnostic options). When we try to load the pch later on, the compiler notices 
that the imported module is out of date (modification date, size do not match)  
but it can't handle this out of date pcm (i.e it does not know how to rebuild 
the pch).

This patch introduces a new command line option so for PCH + module, we can 
turn on this option and if two compiler instances only differ in diagnostic 
options, the latter instance will not invalidate the original pcm.


https://reviews.llvm.org/D22773

Files:
  include/clang/Driver/Options.td
  include/clang/Lex/HeaderSearchOptions.h
  include/clang/Serialization/ASTReader.h
  lib/Frontend/CompilerInvocation.cpp
  lib/Frontend/FrontendActions.cpp
  lib/Serialization/ASTReader.cpp
  test/Driver/modules.m
  test/Modules/Inputs/DiagOutOfDate.h
  test/Modules/Inputs/module.map
  test/Modules/Inputs/pch-import-module-out-of-date.pch
  test/Modules/diagnostic-options-out-of-date.m

Index: test/Modules/diagnostic-options-out-of-date.m
===
--- test/Modules/diagnostic-options-out-of-date.m
+++ test/Modules/diagnostic-options-out-of-date.m
@@ -0,0 +1,8 @@
+// RUN: rm -rf %t
+// RUN: %clang_cc1 -Werror -Wno-conversion -fmodules-cache-path=%t -fmodules -fimplicit-module-maps -I %S/Inputs %s
+// RUN: %clang_cc1 -Werror -Wno-conversion -emit-pch -fmodules-cache-path=%t -fmodules -fimplicit-module-maps -o %t.pch -I %S/Inputs -x objective-c-header %S/Inputs/pch-import-module-out-of-date.pch
+// RUN: %clang_cc1 -Werror -Wconversion -fmodules-cache-path=%t -fmodules -fimplicit-module-maps -I %S/Inputs %s -fmodules-disable-diagnostic-validation
+// RUN: %clang_cc1 -Werror -Wno-conversion -fmodules-cache-path=%t -fmodules -fimplicit-module-maps -fsyntax-only -I %S/Inputs -include-pch %t.pch %s -verify -fmodules-disable-diagnostic-validation
+// expected-no-diagnostics
+
+@import DiagOutOfDate;
Index: test/Modules/Inputs/pch-import-module-out-of-date.pch
===
--- test/Modules/Inputs/pch-import-module-out-of-date.pch
+++ test/Modules/Inputs/pch-import-module-out-of-date.pch
@@ -0,0 +1 @@
+@import DiagOutOfDate;
Index: test/Modules/Inputs/module.map
===
--- test/Modules/Inputs/module.map
+++ test/Modules/Inputs/module.map
@@ -418,3 +418,7 @@
 module MacroFabs1 {
   header "MacroFabs1.h"
 }
+
+module DiagOutOfDate {
+  header "DiagOutOfDate.h"
+}
Index: test/Modules/Inputs/DiagOutOfDate.h
===
--- test/Modules/Inputs/DiagOutOfDate.h
+++ test/Modules/Inputs/DiagOutOfDate.h
@@ -0,0 +1 @@
+const int a = 1;
Index: test/Driver/modules.m
===
--- test/Driver/modules.m
+++ test/Driver/modules.m
@@ -33,6 +33,12 @@
 // RUN: %clang -fmodules-validate-system-headers -### %s 2>&1 | FileCheck -check-prefix=MODULES_VALIDATE_SYSTEM_HEADERS %s
 // MODULES_VALIDATE_SYSTEM_HEADERS: -fmodules-validate-system-headers
 
+// RUN: %clang -### %s 2>&1 | FileCheck -check-prefix=MODULES_DISABLE_DIAGNOSTIC_VALIDATION_DEFAULT %s
+// MODULES_DISABLE_DIAGNOSTIC_VALIDATION_DEFAULT-NOT: -fmodules-disable-diagnostic-validation
+
+// RUN: %clang -fmodules-disable-diagnostic-validation -### %s 2>&1 | FileCheck -check-prefix=MODULES_DISABLE_DIAGNOSTIC_VALIDATION %s
+// MODULES_DISABLE_DIAGNOSTIC_VALIDATION: -fmodules-disable-diagnostic-validation
+
 // RUN: %clang -fmodules -fmodule-map-file=foo.map -fmodule-map-file=bar.map -### %s 2>&1 | FileCheck -check-prefix=CHECK-MODULE-MAP-FILES %s
 // CHECK-MODULE-MAP-FILES: "-fmodules"
 // CHECK-MODULE-MAP-FILES: "-fmodule-map-file=foo.map"
Index: lib/Serialization/ASTReader.cpp
===
--- lib/Serialization/ASTReader.cpp
+++ lib/Serialization/ASTReader.cpp
@@ -2084,7 +2084,7 @@
 ASTReader::ASTReadResult ASTReader::ReadOptionsBlock(
 BitstreamCursor &Stream, unsigned ClientLoadCapabilities,
 bool AllowCompatibleConfigurationMismatch, ASTReaderListener &Listener,
-std::string &SuggestedPredefines) {
+std::string &SuggestedPredefines, bool ValidateDiagnosticOptions) {
   if (Stream.EnterSubBlock(OPTIONS_BLOCK_ID))
 return Failure;
 
@@ -2128,7 +2128,8 @@
 
 case DIAGNOSTIC_OPTIONS: {
   bool Complain = (ClientLoadCapabilities & ARR_OutOfDate) == 0;
-  if (!AllowCompatibleConfigurationMismatch &&
+  if (ValidateDiagno

RE: [ReviewRequest] [Sema/Parser] GCC Compatibility Patch: Support for __final specifier

[Keane, Erich via cfe-commits]

Thanks for the quick review!  I’ve updated the patch with the name changes in 
the attached diff file.

From: David Majnemer [mailto:david.majne...@gmail.com]
Sent: Monday, July 25, 2016 12:40 PM
To: Keane, Erich 
Cc: cfe-commits@lists.llvm.org
Subject: Re: [ReviewRequest] [Sema/Parser] GCC Compatibility Patch: Support for 
__final specifier

I'd rename VS_Alt_Final to VS_GNU_Final.

On Mon, Jul 25, 2016 at 2:24 PM, Keane, Erich via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Hi all, my first potential-contribution, so I apologize if I’m submitting this 
improperly, I’m unfamiliar with the ‘type’ keys that you use in the topic, so 
hopefully I have this right.

As reported in bug 28473, GCC supports ‘final’ functionality in pre-C++11 code 
using the __final keyword.  Clang currently supports the ‘final’ keyword in 
accordance with the C++11 specification, however it ALSO supports it in 
pre-C++11 mode, with a warning.

This patch adds the ‘__final’ keyword for compatibility with GCC in GCC 
Keywords mode (so it is enabled with existing flags), and issues a warning on 
its usage (suggesting switching to the C++11 keyword).  This patch also adds a 
regression test for the functionality described.  I believe this patch has 
minimal impact, as it simply adds a new keyword for existing behavior.

This has been validated with check-clang to avoid regressions.  Patch is 
created in reference to revisions 276665

Thanks,
Erich

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



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

Re: [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

[Daniel Berlin via cfe-commits]

On Mon, Jul 25, 2016 at 1:03 PM, Vlad Dovlekaev via llvm-commits <
llvm-comm...@lists.llvm.org> wrote:

> vladisld added a comment.
>
> In https://reviews.llvm.org/D22463#494828, @jlebar wrote:
>
> > I think the general feeling is that most of us (myself included) would
> rather not learn a new tool if there's a simpler >alternative, such as a
> vanilla git workflow.
>
>
> Generally you're right, however learning how to use git-repo is much
> simpler than managing the intricacies of git sub-modules (and Google's
> experience with Android is a clear example of it).


Just to make some points, as a guy who watched repo being designed in the
office next to me:
Sub modules were completely and totally unusable for Google at that point,
and something was needed sooner.
There is no good reason for android to change now, so they don't.

Note that repo does not solve the issue of cross-repo atomic commits in any
way, shape, or form, and in fact, this is the biggest complaint ;)

In fact, the gerrit team (same people who produce repo) uses submodules for
pseudo-atomic cross-repo commits.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [ReviewRequest] [Sema/Parser] GCC Compatibility Patch: Support for __final specifier

[David Majnemer via cfe-commits]

You've added a comment describing the new enum value.  Please make sure the
comment starts with a cap letter and ends with a period.

On Mon, Jul 25, 2016 at 4:09 PM, Keane, Erich  wrote:

> Thanks for the quick review!  I’ve updated the patch with the name changes
> in the attached diff file.
>
>
>
> *From:* David Majnemer [mailto:david.majne...@gmail.com]
> *Sent:* Monday, July 25, 2016 12:40 PM
> *To:* Keane, Erich 
> *Cc:* cfe-commits@lists.llvm.org
> *Subject:* Re: [ReviewRequest] [Sema/Parser] GCC Compatibility Patch:
> Support for __final specifier
>
>
>
> I'd rename VS_Alt_Final to VS_GNU_Final.
>
>
>
> On Mon, Jul 25, 2016 at 2:24 PM, Keane, Erich via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> Hi all, my first potential-contribution, so I apologize if I’m submitting
> this improperly, I’m unfamiliar with the ‘type’ keys that you use in the
> topic, so hopefully I have this right.
>
>
>
> As reported in bug 28473, GCC supports ‘final’ functionality in pre-C++11
> code using the __final keyword.  Clang currently supports the ‘final’
> keyword in accordance with the C++11 specification, however it ALSO
> supports it in pre-C++11 mode, with a warning.
>
>
>
> This patch adds the ‘__final’ keyword for compatibility with GCC in GCC
> Keywords mode (so it is enabled with existing flags), and issues a warning
> on its usage (suggesting switching to the C++11 keyword).  This patch also
> adds a regression test for the functionality described.  I believe this
> patch has minimal impact, as it simply adds a new keyword for existing
> behavior.
>
>
>
> This has been validated with check-clang to avoid regressions.  Patch is
> created in reference to revisions 276665
>
>
>
> Thanks,
>
> Erich
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: [ReviewRequest] [Sema/Parser] GCC Compatibility Patch: Support for __final specifier

[Keane, Erich via cfe-commits]

Done!  Attached a new diff.

From: David Majnemer [mailto:david.majne...@gmail.com]
Sent: Monday, July 25, 2016 1:18 PM
To: Keane, Erich 
Cc: cfe-commits@lists.llvm.org
Subject: Re: [ReviewRequest] [Sema/Parser] GCC Compatibility Patch: Support for 
__final specifier

You've added a comment describing the new enum value.  Please make sure the 
comment starts with a cap letter and ends with a period.

On Mon, Jul 25, 2016 at 4:09 PM, Keane, Erich 
mailto:erich.ke...@intel.com>> wrote:
Thanks for the quick review!  I’ve updated the patch with the name changes in 
the attached diff file.

From: David Majnemer 
[mailto:david.majne...@gmail.com]
Sent: Monday, July 25, 2016 12:40 PM
To: Keane, Erich mailto:erich.ke...@intel.com>>
Cc: cfe-commits@lists.llvm.org
Subject: Re: [ReviewRequest] [Sema/Parser] GCC Compatibility Patch: Support for 
__final specifier

I'd rename VS_Alt_Final to VS_GNU_Final.

On Mon, Jul 25, 2016 at 2:24 PM, Keane, Erich via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Hi all, my first potential-contribution, so I apologize if I’m submitting this 
improperly, I’m unfamiliar with the ‘type’ keys that you use in the topic, so 
hopefully I have this right.

As reported in bug 28473, GCC supports ‘final’ functionality in pre-C++11 code 
using the __final keyword.  Clang currently supports the ‘final’ keyword in 
accordance with the C++11 specification, however it ALSO supports it in 
pre-C++11 mode, with a warning.

This patch adds the ‘__final’ keyword for compatibility with GCC in GCC 
Keywords mode (so it is enabled with existing flags), and issues a warning on 
its usage (suggesting switching to the C++11 keyword).  This patch also adds a 
regression test for the functionality described.  I believe this patch has 
minimal impact, as it simply adds a new keyword for existing behavior.

This has been validated with check-clang to avoid regressions.  Patch is 
created in reference to revisions 276665

Thanks,
Erich

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




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

[PATCH] D22774: [MSVC] Add ARM support to intrin.h for MSVC compatibility

[Martin Storsjö via cfe-commits]

mstorsjo created this revision.
mstorsjo added a subscriber: cfe-commits.
Herald added subscribers: samparker, rengolin, aemerson.

This fixes compiling with headers from the Windows SDK for ARM, where the 
YieldProcessor function (in winnt.h) refers to _ARM_BARRIER_ISHST.

The actual MSVC armintr.h contains a lot more definitions, but this is enough 
to build code that uses the Windows SDK but doesn't use  ARM intrinsics 
directly.

An alternative would to just keep the addition to intr.h (to include 
armintr.h), but not actually ship armintr.h, instead having clang's intrin.h 
include armintr.h from MSVC's include directory. (That one works fine with 
clang, at least for building code that uses the Windows SDK.)

https://reviews.llvm.org/D22774

Files:
  lib/Headers/CMakeLists.txt
  lib/Headers/armintr.h
  lib/Headers/intrin.h

Index: lib/Headers/intrin.h
===
--- lib/Headers/intrin.h
+++ lib/Headers/intrin.h
@@ -34,6 +34,10 @@
 #include 
 #endif
 
+#if defined(__arm__)
+#include 
+#endif
+
 /* For the definition of jmp_buf. */
 #if __STDC_HOSTED__
 #include 
Index: lib/Headers/armintr.h
===
--- /dev/null
+++ lib/Headers/armintr.h
@@ -0,0 +1,39 @@
+/*=== armintr.h - ARM intrinsics ---===
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ *
+ *===---===
+ */
+
+#ifndef __ARMINTR_H
+#define __ARMINTR_H
+
+typedef enum
+{
+  _ARM_BARRIER_SY= 0xF,
+  _ARM_BARRIER_ST= 0xE,
+  _ARM_BARRIER_ISH   = 0xB,
+  _ARM_BARRIER_ISHST = 0xA,
+  _ARM_BARRIER_NSH   = 0x7,
+  _ARM_BARRIER_NSHST = 0x6,
+  _ARM_BARRIER_OSH   = 0x3,
+  _ARM_BARRIER_OSHST = 0x2
+} _ARMINTR_BARRIER_TYPE;
+
+#endif /* __ARMINTR_H */
Index: lib/Headers/CMakeLists.txt
===
--- lib/Headers/CMakeLists.txt
+++ lib/Headers/CMakeLists.txt
@@ -3,6 +3,7 @@
   altivec.h
   ammintrin.h
   arm_acle.h
+  armintr.h
   avx2intrin.h
   avx512bwintrin.h
   avx512cdintrin.h


Index: lib/Headers/intrin.h
===
--- lib/Headers/intrin.h
+++ lib/Headers/intrin.h
@@ -34,6 +34,10 @@
 #include 
 #endif
 
+#if defined(__arm__)
+#include 
+#endif
+
 /* For the definition of jmp_buf. */
 #if __STDC_HOSTED__
 #include 
Index: lib/Headers/armintr.h
===
--- /dev/null
+++ lib/Headers/armintr.h
@@ -0,0 +1,39 @@
+/*=== armintr.h - ARM intrinsics ---===
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ *
+ *===---===
+ */
+
+#ifndef __ARMINTR_H
+#define __ARMINTR_H
+
+typedef enum
+{
+  _ARM_BARRIER_S

Re: [PATCH] D22654: [Clang-rename] Remove custom version, fix extra space in error message

[Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL276684: [Clang-rename] Remove custom version, fix extra 
space in error message. (authored by eugenezelenko).

Changed prior to commit:
  https://reviews.llvm.org/D22654?vs=65379&id=65412#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D22654

Files:
  clang-tools-extra/trunk/clang-rename/tool/ClangRename.cpp
  clang-tools-extra/trunk/test/clang-rename/InvalidNewName.cpp

Index: clang-tools-extra/trunk/clang-rename/tool/ClangRename.cpp
===
--- clang-tools-extra/trunk/clang-rename/tool/ClangRename.cpp
+++ clang-tools-extra/trunk/clang-rename/tool/ClangRename.cpp
@@ -15,28 +15,27 @@
 
 #include "../USRFindingAction.h"
 #include "../RenamingAction.h"
-#include "clang/AST/ASTConsumer.h"
-#include "clang/AST/ASTContext.h"
+#include "clang/Basic/Diagnostic.h"
+#include "clang/Basic/DiagnosticOptions.h"
 #include "clang/Basic/FileManager.h"
+#include "clang/Basic/IdentifierTable.h"
 #include "clang/Basic/LangOptions.h"
-#include "clang/Basic/TargetInfo.h"
-#include "clang/Basic/TargetOptions.h"
-#include "clang/Frontend/CommandLineSourceLoc.h"
-#include "clang/Frontend/CompilerInstance.h"
-#include "clang/Frontend/FrontendAction.h"
+#include "clang/Basic/SourceManager.h"
+#include "clang/Basic/TokenKinds.h"
 #include "clang/Frontend/TextDiagnosticPrinter.h"
-#include "clang/Lex/Lexer.h"
-#include "clang/Lex/Preprocessor.h"
-#include "clang/Parse/ParseAST.h"
-#include "clang/Parse/Parser.h"
 #include "clang/Rewrite/Core/Rewriter.h"
 #include "clang/Tooling/CommonOptionsParser.h"
 #include "clang/Tooling/Refactoring.h"
 #include "clang/Tooling/ReplacementsYaml.h"
 #include "clang/Tooling/Tooling.h"
 #include "llvm/ADT/IntrusiveRefCntPtr.h"
-#include "llvm/Support/Host.h"
+#include "llvm/Support/CommandLine.h"
+#include "llvm/Support/FileSystem.h"
+#include "llvm/Support/raw_ostream.h"
+#include "llvm/Support/YAMLTraits.h"
+#include 
 #include 
+#include 
 
 using namespace llvm;
 
@@ -79,21 +78,14 @@
 cl::value_desc("filename"),
 cl::cat(ClangRenameCategory));
 
-#define CLANG_RENAME_VERSION "0.0.1"
-
-static void PrintVersion() {
-  outs() << "clang-rename version " << CLANG_RENAME_VERSION << '\n';
-}
-
 using namespace clang;
 
 const char RenameUsage[] = "A tool to rename symbols in C/C++ code.\n\
 clang-rename renames every occurrence of a symbol found at  in\n\
 . If -i is specified, the edited files are overwritten to disk.\n\
 Otherwise, the results are written to stdout.\n";
 
 int main(int argc, const char **argv) {
-  cl::SetVersionPrinter(PrintVersion);
   tooling::CommonOptionsParser OP(argc, argv, ClangRenameCategory, 
RenameUsage);
 
   // Check the arguments for correctness.
@@ -110,7 +102,7 @@
   IdentifierTable Table(Options);
   auto NewNameTokKind = Table.get(NewName).getTokenID();
   if (!tok::isAnyIdentifier(NewNameTokKind)) {
-errs() << "ERROR: new name is not a valid identifier in  C++17.\n\n";
+errs() << "ERROR: new name is not a valid identifier in C++17.\n\n";
 exit(1);
   }
 
Index: clang-tools-extra/trunk/test/clang-rename/InvalidNewName.cpp
===
--- clang-tools-extra/trunk/test/clang-rename/InvalidNewName.cpp
+++ clang-tools-extra/trunk/test/clang-rename/InvalidNewName.cpp
@@ -1,2 +1,2 @@
 // RUN: not clang-rename -new-name=class -offset=133 %s 2>&1 | FileCheck %s
-// CHECK: ERROR: new name is not a valid identifier in  C++17.
+// CHECK: ERROR: new name is not a valid identifier in C++17.


Index: clang-tools-extra/trunk/clang-rename/tool/ClangRename.cpp
===
--- clang-tools-extra/trunk/clang-rename/tool/ClangRename.cpp
+++ clang-tools-extra/trunk/clang-rename/tool/ClangRename.cpp
@@ -15,28 +15,27 @@
 
 #include "../USRFindingAction.h"
 #include "../RenamingAction.h"
-#include "clang/AST/ASTConsumer.h"
-#include "clang/AST/ASTContext.h"
+#include "clang/Basic/Diagnostic.h"
+#include "clang/Basic/DiagnosticOptions.h"
 #include "clang/Basic/FileManager.h"
+#include "clang/Basic/IdentifierTable.h"
 #include "clang/Basic/LangOptions.h"
-#include "clang/Basic/TargetInfo.h"
-#include "clang/Basic/TargetOptions.h"
-#include "clang/Frontend/CommandLineSourceLoc.h"
-#include "clang/Frontend/CompilerInstance.h"
-#include "clang/Frontend/FrontendAction.h"
+#include "clang/Basic/SourceManager.h"
+#include "clang/Basic/TokenKinds.h"
 #include "clang/Frontend/TextDiagnosticPrinter.h"
-#include "clang/Lex/Lexer.h"
-#include "clang/Lex/Preprocessor.h"
-#include "clang/Parse/ParseAST.h"
-#include "clang/Parse/Parser.h"
 #include "clang/Rewrite/Core/Rewriter.h"
 #include "clang/Tooling/CommonOptionsParser.h"
 #include "clang/Tooling/Refactoring.h"
 #include "clang/Tooling/ReplacementsYaml.h"
 #include "clang/Tooling/Tooling.h"
 #include "llvm/ADT/IntrusiveRefCntPtr.h"
-#include "llvm/Support/Host.h"
+#

[clang-tools-extra] r276684 - [Clang-rename] Remove custom version, fix extra space in error message.

[Eugene Zelenko via cfe-commits]

Author: eugenezelenko
Date: Mon Jul 25 15:30:13 2016
New Revision: 276684

URL: http://llvm.org/viewvc/llvm-project?rev=276684&view=rev
Log:
[Clang-rename] Remove custom version, fix extra space in error message.

Also fixed some Include What You Use Warnings.

Differential revision: https://reviews.llvm.org/D22654

Modified:
clang-tools-extra/trunk/clang-rename/tool/ClangRename.cpp
clang-tools-extra/trunk/test/clang-rename/InvalidNewName.cpp

Modified: clang-tools-extra/trunk/clang-rename/tool/ClangRename.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-rename/tool/ClangRename.cpp?rev=276684&r1=276683&r2=276684&view=diff
==
--- clang-tools-extra/trunk/clang-rename/tool/ClangRename.cpp (original)
+++ clang-tools-extra/trunk/clang-rename/tool/ClangRename.cpp Mon Jul 25 
15:30:13 2016
@@ -15,28 +15,27 @@
 
 #include "../USRFindingAction.h"
 #include "../RenamingAction.h"
-#include "clang/AST/ASTConsumer.h"
-#include "clang/AST/ASTContext.h"
+#include "clang/Basic/Diagnostic.h"
+#include "clang/Basic/DiagnosticOptions.h"
 #include "clang/Basic/FileManager.h"
+#include "clang/Basic/IdentifierTable.h"
 #include "clang/Basic/LangOptions.h"
-#include "clang/Basic/TargetInfo.h"
-#include "clang/Basic/TargetOptions.h"
-#include "clang/Frontend/CommandLineSourceLoc.h"
-#include "clang/Frontend/CompilerInstance.h"
-#include "clang/Frontend/FrontendAction.h"
+#include "clang/Basic/SourceManager.h"
+#include "clang/Basic/TokenKinds.h"
 #include "clang/Frontend/TextDiagnosticPrinter.h"
-#include "clang/Lex/Lexer.h"
-#include "clang/Lex/Preprocessor.h"
-#include "clang/Parse/ParseAST.h"
-#include "clang/Parse/Parser.h"
 #include "clang/Rewrite/Core/Rewriter.h"
 #include "clang/Tooling/CommonOptionsParser.h"
 #include "clang/Tooling/Refactoring.h"
 #include "clang/Tooling/ReplacementsYaml.h"
 #include "clang/Tooling/Tooling.h"
 #include "llvm/ADT/IntrusiveRefCntPtr.h"
-#include "llvm/Support/Host.h"
+#include "llvm/Support/CommandLine.h"
+#include "llvm/Support/FileSystem.h"
+#include "llvm/Support/raw_ostream.h"
+#include "llvm/Support/YAMLTraits.h"
+#include 
 #include 
+#include 
 
 using namespace llvm;
 
@@ -79,12 +78,6 @@ ExportFixes(
 cl::value_desc("filename"),
 cl::cat(ClangRenameCategory));
 
-#define CLANG_RENAME_VERSION "0.0.1"
-
-static void PrintVersion() {
-  outs() << "clang-rename version " << CLANG_RENAME_VERSION << '\n';
-}
-
 using namespace clang;
 
 const char RenameUsage[] = "A tool to rename symbols in C/C++ code.\n\
@@ -93,7 +86,6 @@ clang-rename renames every occurrence of
 Otherwise, the results are written to stdout.\n";
 
 int main(int argc, const char **argv) {
-  cl::SetVersionPrinter(PrintVersion);
   tooling::CommonOptionsParser OP(argc, argv, ClangRenameCategory, 
RenameUsage);
 
   // Check the arguments for correctness.
@@ -110,7 +102,7 @@ int main(int argc, const char **argv) {
   IdentifierTable Table(Options);
   auto NewNameTokKind = Table.get(NewName).getTokenID();
   if (!tok::isAnyIdentifier(NewNameTokKind)) {
-errs() << "ERROR: new name is not a valid identifier in  C++17.\n\n";
+errs() << "ERROR: new name is not a valid identifier in C++17.\n\n";
 exit(1);
   }
 

Modified: clang-tools-extra/trunk/test/clang-rename/InvalidNewName.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-rename/InvalidNewName.cpp?rev=276684&r1=276683&r2=276684&view=diff
==
--- clang-tools-extra/trunk/test/clang-rename/InvalidNewName.cpp (original)
+++ clang-tools-extra/trunk/test/clang-rename/InvalidNewName.cpp Mon Jul 25 
15:30:13 2016
@@ -1,2 +1,2 @@
 // RUN: not clang-rename -new-name=class -offset=133 %s 2>&1 | FileCheck %s
-// CHECK: ERROR: new name is not a valid identifier in  C++17.
+// CHECK: ERROR: new name is not a valid identifier in C++17.


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

Re: r276473 - [modules] Teach the ASTWriter to ignore mutations coming from the ASTReader.

[Hans Wennborg via cfe-commits]

Should this be merged to 3.9?

On Fri, Jul 22, 2016 at 2:08 PM, Vassil Vassilev via cfe-commits
 wrote:
> Author: vvassilev
> Date: Fri Jul 22 16:08:24 2016
> New Revision: 276473
>
> URL: http://llvm.org/viewvc/llvm-project?rev=276473&view=rev
> Log:
> [modules] Teach the ASTWriter to ignore mutations coming from the ASTReader.
>
> Processing update records (and loading a module, in general) might trigger
> unexpected calls to the ASTWriter (being a mutation listener). Now we have a
> mechanism to suppress those calls to the ASTWriter but notify other possible
> mutation listeners.
>
> Fixes https://llvm.org/bugs/show_bug.cgi?id=28332
>
> Patch by Cristina Cristescu and me.
>
> Reviewed by Richard Smith (D21800).
>
> Added:
> cfe/trunk/test/Modules/Inputs/PR28332/
> cfe/trunk/test/Modules/Inputs/PR28332/TextualInclude.h
> cfe/trunk/test/Modules/Inputs/PR28332/a.h
> cfe/trunk/test/Modules/Inputs/PR28332/b.h
> cfe/trunk/test/Modules/Inputs/PR28332/c.h
> cfe/trunk/test/Modules/Inputs/PR28332/module.modulemap
> cfe/trunk/test/Modules/pr28332.cpp
> Modified:
> cfe/trunk/include/clang/Serialization/ASTReader.h
> cfe/trunk/lib/Serialization/ASTReader.cpp
> cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
> cfe/trunk/lib/Serialization/ASTWriter.cpp
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D22513: [clang-tidy] add check cppcoreguidelines-rule-of-five-and-zero

[Jonathan B Coe via cfe-commits]

jbcoe set the repository for this revision to rL LLVM.
jbcoe updated this revision to Diff 65414.
jbcoe marked an inline comment as done.
jbcoe added a comment.

Rename to cppcoreguidelines-special-member-functions to avoid the duplication 
required with naming it rule-of-3 and rule-of-5.

Reduce code duplication by iterating over a list of matchers.

Use dense map. [FIXME: I can't get DenseMap to work with the DenseMapInfo 
defined in the header. IdentifierNamingCheck.cpp does this without any issues 
but I hit compiler errors around DenseMap and SourceLocation. Moving the 
specialisation from the header to the source of SpecialMemberFunctionsCheck 
suffices to repeat the problem. Any input here would be appreciated.]


Repository:
  rL LLVM

https://reviews.llvm.org/D22513

Files:
  clang-tidy/cppcoreguidelines/CMakeLists.txt
  clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
  clang-tidy/cppcoreguidelines/SpecialMemberFunctionsCheck.cpp
  clang-tidy/cppcoreguidelines/SpecialMemberFunctionsCheck.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/cppcoreguidelines-special-member-functions.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/cppcoreguidelines-special-member-functions-cxx-03.cpp
  test/clang-tidy/cppcoreguidelines-special-member-functions.cpp

Index: test/clang-tidy/cppcoreguidelines-special-member-functions.cpp
===
--- /dev/null
+++ test/clang-tidy/cppcoreguidelines-special-member-functions.cpp
@@ -0,0 +1,52 @@
+// RUN: %check_clang_tidy %s cppcoreguidelines-special-member-functions %t
+
+class DefinesDestructor {
+  ~DefinesDestructor();
+};
+// CHECK-MESSAGES: [[@LINE-3]]:7: warning: class 'DefinesDestructor' defines a destructor but does not define a copy constructor, a copy assignment operator, a move constructor or a move assignment operator [cppcoreguidelines-special-member-functions]
+
+class DefinesCopyConstructor {
+  DefinesCopyConstructor(const DefinesCopyConstructor &);
+};
+// CHECK-MESSAGES: [[@LINE-3]]:7: warning: class 'DefinesCopyConstructor' defines a copy constructor but does not define a destructor, a copy assignment operator, a move constructor or a move assignment operator [cppcoreguidelines-special-member-functions]
+
+class DefinesCopyAssignment {
+  DefinesCopyAssignment &operator=(const DefinesCopyAssignment &);
+};
+// CHECK-MESSAGES: [[@LINE-3]]:7: warning: class 'DefinesCopyAssignment' defines a copy assignment operator but does not define a destructor, a copy constructor, a move constructor or a move assignment operator [cppcoreguidelines-special-member-functions]
+
+class DefinesMoveConstructor {
+  DefinesMoveConstructor(DefinesMoveConstructor &&);
+};
+// CHECK-MESSAGES: [[@LINE-3]]:7: warning: class 'DefinesMoveConstructor' defines a move constructor but does not define a destructor, a copy constructor, a copy assignment operator or a move assignment operator [cppcoreguidelines-special-member-functions]
+
+class DefinesMoveAssignment {
+  DefinesMoveAssignment &operator=(DefinesMoveAssignment &&);
+};
+// CHECK-MESSAGES: [[@LINE-3]]:7: warning: class 'DefinesMoveAssignment' defines a move assignment operator but does not define a destructor, a copy constructor, a copy assignment operator or a move constructor [cppcoreguidelines-special-member-functions]
+class DefinesNothing {
+};
+
+class DefinesEverything {
+  DefinesEverything(const DefinesEverything &);
+  DefinesEverything &operator=(const DefinesEverything &);
+  DefinesEverything(DefinesEverything &&);
+  DefinesEverything &operator=(DefinesEverything &&);
+  ~DefinesEverything();
+};
+
+class DeletesEverything {
+  DeletesEverything(const DeletesEverything &) = delete;
+  DeletesEverything &operator=(const DeletesEverything &) = delete;
+  DeletesEverything(DeletesEverything &&) = delete;
+  DeletesEverything &operator=(DeletesEverything &&) = delete;
+  ~DeletesEverything() = delete;
+};
+
+class DeletesCopyDefaultsMove {
+  DeletesCopyDefaultsMove(const DeletesCopyDefaultsMove &) = delete;
+  DeletesCopyDefaultsMove &operator=(const DeletesCopyDefaultsMove &) = delete;
+  DeletesCopyDefaultsMove(DeletesCopyDefaultsMove &&) = default;
+  DeletesCopyDefaultsMove &operator=(DeletesCopyDefaultsMove &&) = default;
+  ~DeletesCopyDefaultsMove() = default;
+};
Index: test/clang-tidy/cppcoreguidelines-special-member-functions-cxx-03.cpp
===
--- /dev/null
+++ test/clang-tidy/cppcoreguidelines-special-member-functions-cxx-03.cpp
@@ -0,0 +1,26 @@
+// RUN: %check_clang_tidy %s cppcoreguidelines-special-member-functions %t -- -- -std=c++03
+
+class DefinesDestructor {
+  ~DefinesDestructor();
+};
+// CHECK-MESSAGES: [[@LINE-3]]:7: warning: class 'DefinesDestructor' defines a destructor but does not define a copy constructor or a copy assignment operator [cppcoreguidelines-special-member-functions]
+
+class DefinesCopyConstructor {
+  DefinesCopyConstructor(const Define

Re: r276653 - Support '#pragma once' in headers when using PCH

[Hans Wennborg via cfe-commits]

Should me merge this to 3.9?

On Mon, Jul 25, 2016 at 10:17 AM, Sunil Srivastava via cfe-commits
 wrote:
> Author: ssrivastava
> Date: Mon Jul 25 12:17:06 2016
> New Revision: 276653
>
> URL: http://llvm.org/viewvc/llvm-project?rev=276653&view=rev
> Log:
> Support '#pragma once' in headers when using PCH
>
> The '#pragma once' directive was erroneously ignored when encountered
> in the header-file specified in generate-PCH-mode. This resulted in
> compile-time errors in some cases with legal code, and also a misleading
> warning being produced.
>
> Patch by Warren Ristow!
>
> Differential Revision: http://reviews.llvm.org/D19815
>
> Added:
> cfe/trunk/test/PCH/Inputs/pragma-once.h
> cfe/trunk/test/PCH/pragma-once.c
> Modified:
> cfe/trunk/lib/Lex/Pragma.cpp
>
> Modified: cfe/trunk/lib/Lex/Pragma.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/Pragma.cpp?rev=276653&r1=276652&r2=276653&view=diff
> ==
> --- cfe/trunk/lib/Lex/Pragma.cpp (original)
> +++ cfe/trunk/lib/Lex/Pragma.cpp Mon Jul 25 12:17:06 2016
> @@ -352,7 +352,9 @@ void Preprocessor::HandleMicrosoft__prag
>  /// HandlePragmaOnce - Handle \#pragma once.  OnceTok is the 'once'.
>  ///
>  void Preprocessor::HandlePragmaOnce(Token &OnceTok) {
> -  if (isInPrimaryFile()) {
> +  // Don't honor the 'once' when handling the primary source file, unless
> +  // this is a prefix to a TU, which indicates we're generating a PCH file.
> +  if (isInPrimaryFile() && TUKind != TU_Prefix) {
>  Diag(OnceTok, diag::pp_pragma_once_in_main_file);
>  return;
>}
>
> Added: cfe/trunk/test/PCH/Inputs/pragma-once.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/PCH/Inputs/pragma-once.h?rev=276653&view=auto
> ==
> --- cfe/trunk/test/PCH/Inputs/pragma-once.h (added)
> +++ cfe/trunk/test/PCH/Inputs/pragma-once.h Mon Jul 25 12:17:06 2016
> @@ -0,0 +1,5 @@
> +#pragma once
> +
> +/* For use with the pragma-once.c test */
> +
> +int x = 3;
>
> Added: cfe/trunk/test/PCH/pragma-once.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/PCH/pragma-once.c?rev=276653&view=auto
> ==
> --- cfe/trunk/test/PCH/pragma-once.c (added)
> +++ cfe/trunk/test/PCH/pragma-once.c Mon Jul 25 12:17:06 2016
> @@ -0,0 +1,13 @@
> +// Test this without pch.
> +// RUN: %clang_cc1 -include %S/Inputs/pragma-once.h -fsyntax-only -verify %s
> +
> +// Test with pch.
> +// RUN: %clang_cc1 -emit-pch -o %t %S/Inputs/pragma-once.h
> +// RUN: %clang_cc1 -include-pch %t -fsyntax-only -verify %s
> +
> +// expected-no-diagnostics
> +
> +// Including "pragma-once.h" twice, to verify the 'once' aspect is honored.
> +#include "Inputs/pragma-once.h"
> +#include "Inputs/pragma-once.h"
> +int foo(void) { return 0; }
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D22513: [clang-tidy] add check cppcoreguidelines-rule-of-five-and-zero

[Eugene Zelenko via cfe-commits]

Eugene.Zelenko added inline comments.


Comment at: 
docs/clang-tidy/checks/cppcoreguidelines-special-member-functions.rst:4
@@ +3,3 @@
+cppcoreguidelines-special-member-functions
+===
+

Size should be same as size of name above.


Repository:
  rL LLVM

https://reviews.llvm.org/D22513



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