Re: Patch for Bug 30413, including test case

2017-02-19 Thread Akira Hatanaka via cfe-commits 
This patch changes the encoding of an id conforming to a protocol, which I 
think was not intended: For example:

@encode(id)

Would passing IVD to the call to getObjCEncodingForType in 
CGObjCGNU::GenerateClass solve the problem?

> On Feb 15, 2017, at 1:59 PM, Lobron, David via cfe-commits 
>  wrote:
> 
> Hi All,
> 
> I am re-submitting my patch for Bug 30413, this time with a test case 
> included as well (ivar-type-encoding.m).  The test case file should be added 
> to clang/test/CodeGenObjC.  The test verifies that correct metadata is 
> emitted by clang for an object-valued instance variable.  I've verified that 
> the test passes when the patch has been applied to ASTContext.cpp, and fails 
> otherwise.
> 
> Please let me know if this looks OK, or if any additional information is 
> needed.
> 
> Thanks,
> 
> David
> 
> ___
> 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] D28348: [analyzer] Taught the analyzer about Glib API to check Memory-leak

2017-02-19 Thread Leslie Zhai via Phabricator via cfe-commits 
xiangzhai added a comment.

Hi Anna,

I am not clear why need to calculate the precise allocated size? for example:

void *ptr = malloc(size);
void *gptr = g_malloc_n(n_blocks, n_block_bytes);

Memory-leak and Use-after-free issues' MallocChecker need the ***size*** or 
***n_blocks*** x ***n_block_bytes***, but if the size is inaccurate, the 
checker is also ***able*** to detect the issues.

Regards,
Leslie Zhai




Comment at: lib/StaticAnalyzer/Checkers/MallocChecker.cpp:889
+} else if (FunI == II_g_realloc_n || FunI == II_g_try_realloc_n) {
+  if (CE->getNumArgs() < 2)
+return;

zaks.anna wrote:
> Should this be 'getNumArgs() < 3' ?
sorry typo...


Repository:
  rL LLVM

https://reviews.llvm.org/D28348



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

r295635 - Enable support for __float128 in Clang on OpenBSD/X86

2017-02-19 Thread Brad Smith via cfe-commits 
Author: brad
Date: Sun Feb 19 21:18:15 2017
New Revision: 295635

URL: http://llvm.org/viewvc/llvm-project?rev=295635=rev
Log:
Enable support for __float128 in Clang on OpenBSD/X86

/usr/local/include/c++/4.9.4/type_traits:279:39: error: __float128 is not
supported on this target

Modified:
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/test/CodeGenCXX/float128-declarations.cpp

Modified: cfe/trunk/lib/Basic/Targets.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=295635=295634=295635=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Sun Feb 19 21:18:15 2017
@@ -545,6 +545,8 @@ protected:
 Builder.defineMacro("__ELF__");
 if (Opts.POSIXThreads)
   Builder.defineMacro("_REENTRANT");
+if (this->HasFloat128)
+  Builder.defineMacro("__FLOAT128__");
   }
 public:
   OpenBSDTargetInfo(const llvm::Triple , const TargetOptions )
@@ -552,11 +554,11 @@ public:
 this->TLSSupported = false;
 
   switch (Triple.getArch()) {
-default:
 case llvm::Triple::x86:
 case llvm::Triple::x86_64:
-case llvm::Triple::arm:
-case llvm::Triple::sparc:
+  this->HasFloat128 = true;
+  // FALLTHROUGH
+default:
   this->MCountName = "__mcount";
   break;
 case llvm::Triple::mips64:

Modified: cfe/trunk/test/CodeGenCXX/float128-declarations.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/float128-declarations.cpp?rev=295635=295634=295635=diff
==
--- cfe/trunk/test/CodeGenCXX/float128-declarations.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/float128-declarations.cpp Sun Feb 19 21:18:15 2017
@@ -8,6 +8,10 @@
 // RUN:   %s -o - | FileCheck %s -check-prefix=CHECK-X86
 // RUN: %clang_cc1 -emit-llvm -triple systemz-unknown-linux-gnu -std=c++11 \
 // RUN:   %s -o - | FileCheck %s -check-prefix=CHECK-SYSZ
+// RUN: %clang_cc1 -emit-llvm -triple i686-pc-openbsd -std=c++11 \
+// RUN:   %s -o - | FileCheck %s -check-prefix=CHECK-X86
+// RUN: %clang_cc1 -emit-llvm -triple amd64-pc-openbsd -std=c++11 \
+// RUN:   %s -o - | FileCheck %s -check-prefix=CHECK-X86
 //
 /*  Various contexts where type __float128 can appear. The different check
 prefixes are due to different mangling on X86 and different calling


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

[PATCH] D28348: [analyzer] Taught the analyzer about Glib API to check Memory-leak

2017-02-19 Thread Leslie Zhai via Phabricator via cfe-commits 
xiangzhai marked 3 inline comments as done.
xiangzhai added a comment.

Hi Anna,

Thank you so much for the review!

I will try to implement extend MallocMemAux and ReallocMem in the follow up 
patch.

Regards,
Leslie Zhai




Comment at: lib/StaticAnalyzer/Checkers/MallocChecker.cpp:885
+return;
+  State = MallocMemAux(C, CE, CE->getArg(0), UndefinedVal(), State);
+  State = ProcessZeroAllocation(C, CE, 0, State);

zaks.anna wrote:
> I am not sure this is correct as the third argument is "size of allocation", 
> which in this case would be the value of CE->getArg(0) times the value of 
> CE->getArg(2).
> 
> The current implementation of MallocMemAux would need to be extended to 
> incorporate this:
> `  // Set the region's extent equal to the Size parameter.
>   const SymbolicRegion *R =
>   dyn_cast_or_null(RetVal.getAsRegion());
>   if (!R)
> return nullptr;
>   if (Optional DefinedSize =
>   Size.getAs()) {
> SValBuilder  = C.getSValBuilder();
> DefinedOrUnknownSVal Extent = R->getExtent(svalBuilder);
> DefinedOrUnknownSVal extentMatchesSize =
> svalBuilder.evalEQ(State, Extent, *DefinedSize);
> 
> State = State->assume(extentMatchesSize, true);
> assert(State);
>   }`
> 
> My suggestion is to submit the patch without the 'n' variants and extend 
> MallocMemAux to deal with them as a follow up patch.
Hi Anna,

Thanks for your review!

> I am not sure this is correct as the third argument is "size of allocation", 
> which in this case would be the value of CE->getArg(0) times the value of 
> CE->getArg(2).

```g_malloc_n``` just use two arguments 
https://developer.gnome.org/glib/stable/glib-Memory-Allocation.html#g-malloc-n

so in this case would be the value of CE->getArg(0) x CE->getArg(1)?

> My suggestion is to submit the patch without the 'n' variants and extend 
> MallocMemAux to deal with them as a follow up patch.

I will drop XXX_n from this patch, then implement them until extend 
MallocMemAux and ReallocMem implemented in the follow up patch.

Regards,
Leslie Zhai


Repository:
  rL LLVM

https://reviews.llvm.org/D28348



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

r295620 - Driver: inline a single caller of a function (NFC)

2017-02-19 Thread Saleem Abdulrasool via cfe-commits 
Author: compnerd
Date: Sun Feb 19 15:50:40 2017
New Revision: 295620

URL: http://llvm.org/viewvc/llvm-project?rev=295620=rev
Log:
Driver: inline a single caller of a function (NFC)

Inline the addCompilerRT call to the single caller.  NFC.

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=295620=295619=295620=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Sun Feb 19 15:50:40 2017
@@ -3246,14 +3246,6 @@ static void CollectArgsForIntegratedAsse
   }
 }
 
-// This adds the static libclang_rt.builtins-arch.a directly to the command 
line
-// FIXME: Make sure we can also emit shared objects if they're requested
-// and available, check for possible errors, etc.
-static void addClangRT(const ToolChain , const ArgList ,
-   ArgStringList ) {
-  CmdArgs.push_back(TC.getCompilerRTArgString(Args, "builtins"));
-}
-
 static void addOpenMPRuntime(ArgStringList , const ToolChain ,
   const ArgList ) {
   if (!Args.hasFlag(options::OPT_fopenmp, options::OPT_fopenmp_EQ,
@@ -10074,7 +10066,7 @@ static void AddRunTimeLibs(const ToolCha
 case llvm::Triple::Win32:
 case llvm::Triple::Linux:
 case llvm::Triple::Fuchsia:
-  addClangRT(TC, Args, CmdArgs);
+  CmdArgs.push_back(TC.getCompilerRTArgString(Args, "builtins"));
   break;
 }
 break;


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

r295614 - Always use --eh-frame-hdr on OpenBSD, even for -static

2017-02-19 Thread Brad Smith via cfe-commits 
Author: brad
Date: Sun Feb 19 14:11:48 2017
New Revision: 295614

URL: http://llvm.org/viewvc/llvm-project?rev=295614=rev
Log:
Always use --eh-frame-hdr on OpenBSD, even for -static

Modified:
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/test/Driver/openbsd.c

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=295614=295613=295614=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Sun Feb 19 14:11:48 2017
@@ -9005,12 +9005,12 @@ void openbsd::Linker::ConstructJob(Compi
 CmdArgs.push_back("__start");
   }
 
+  CmdArgs.push_back("--eh-frame-hdr");
   if (Args.hasArg(options::OPT_static)) {
 CmdArgs.push_back("-Bstatic");
   } else {
 if (Args.hasArg(options::OPT_rdynamic))
   CmdArgs.push_back("-export-dynamic");
-CmdArgs.push_back("--eh-frame-hdr");
 CmdArgs.push_back("-Bdynamic");
 if (Args.hasArg(options::OPT_shared)) {
   CmdArgs.push_back("-shared");

Modified: cfe/trunk/test/Driver/openbsd.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/openbsd.c?rev=295614=295613=295614=diff
==
--- cfe/trunk/test/Driver/openbsd.c (original)
+++ cfe/trunk/test/Driver/openbsd.c Sun Feb 19 14:11:48 2017
@@ -3,6 +3,12 @@
 // CHECK-LD: clang{{.*}}" "-cc1" "-triple" "i686-pc-openbsd"
 // CHECK-LD: ld{{.*}}" "-e" "__start" "--eh-frame-hdr" "-Bdynamic" 
"-dynamic-linker" "{{.*}}ld.so" "-o" "a.out" "{{.*}}crt0.o" "{{.*}}crtbegin.o" 
"{{.*}}.o" "-lgcc" "-lc" "-lgcc" "{{.*}}crtend.o"
 
+// Check for --eh-frame-hdr being passed with static linking
+// RUN: %clang -no-canonical-prefixes -target i686-pc-openbsd -static %s -### 
2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-LD-STATIC-EH %s
+// CHECK-LD-STATIC-EH: clang{{.*}}" "-cc1" "-triple" "i686-pc-openbsd"
+// CHECK-LD-STATIC-EH: ld{{.*}}" "-e" "__start" "--eh-frame-hdr" "-Bstatic" 
"-o" "a.out" "{{.*}}rcrt0.o" "{{.*}}crtbegin.o" "{{.*}}.o" "-lgcc" "-lc" 
"-lgcc" "{{.*}}crtend.o"
+
 // RUN: %clang -no-canonical-prefixes -target i686-pc-openbsd -pg -pthread %s 
-### 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-PG %s
 // CHECK-PG: clang{{.*}}" "-cc1" "-triple" "i686-pc-openbsd"


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

[PATCH] D30158: [clang-tidy] modernize: Find usage of random_shuffle and replace it with shuffle.

2017-02-19 Thread Eugene Zelenko via Phabricator via cfe-commits 
Eugene.Zelenko added inline comments.



Comment at: docs/ReleaseNotes.rst:78
+
+  Finds and fixes usage of random_shuffle as the function has been removed 
from C++17.
+

Please add std:: and enclose random_shuffle in ``.



Comment at: docs/clang-tidy/checks/modernize-replace-random-shuffle.rst:6
+
+This check will find occurences of ``random_shuffle`` and replace it with 
``shuffle``. In C++17 ``random_shuffle`` will no longer be available and thus 
we need to replace it.
+

I think std:: should be added.


https://reviews.llvm.org/D30158



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

r295610 - Link static PIE programs against rcrt0.o on OpenBSD

2017-02-19 Thread Brad Smith via cfe-commits 
Author: brad
Date: Sun Feb 19 13:33:26 2017
New Revision: 295610

URL: http://llvm.org/viewvc/llvm-project?rev=295610=rev
Log:
Link static PIE programs against rcrt0.o on OpenBSD

Patch by Stefan Kempf.

Modified:
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/test/Driver/openbsd.c

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=295610=295609=295610=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Sun Feb 19 13:33:26 2017
@@ -9035,6 +9035,10 @@ void openbsd::Linker::ConstructJob(Compi
   if (Args.hasArg(options::OPT_pg))
 CmdArgs.push_back(
 Args.MakeArgString(getToolChain().GetFilePath("gcrt0.o")));
+  else if (Args.hasArg(options::OPT_static) &&
+   !Args.hasArg(options::OPT_nopie))
+CmdArgs.push_back(
+Args.MakeArgString(getToolChain().GetFilePath("rcrt0.o")));
   else
 CmdArgs.push_back(
 Args.MakeArgString(getToolChain().GetFilePath("crt0.o")));

Modified: cfe/trunk/test/Driver/openbsd.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/openbsd.c?rev=295610=295609=295610=diff
==
--- cfe/trunk/test/Driver/openbsd.c (original)
+++ cfe/trunk/test/Driver/openbsd.c Sun Feb 19 13:33:26 2017
@@ -67,3 +67,26 @@
 // CHECK-MIPS64-PIC: as{{.*}}" "-mabi" "64" "-EB" "-KPIC"
 // CHECK-MIPS64EL: as{{.*}}" "-mabi" "64" "-EL"
 // CHECK-MIPS64EL-PIC: as{{.*}}" "-mabi" "64" "-EL" "-KPIC"
+
+// Check linking against correct startup code when (not) using PIE
+// RUN: %clang -no-canonical-prefixes -target i686-pc-openbsd %s -### 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHECK-PIE %s
+// RUN: %clang -no-canonical-prefixes -target i686-pc-openbsd %s -fno-pie %s 
-### 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHECK-PIE %s
+// RUN: %clang -no-canonical-prefixes -target i686-pc-openbsd -static %s -### 
2>&1 \
+// RUN:   | FileCheck -check-prefix=CHECK-STATIC-PIE %s
+// RUN: %clang -no-canonical-prefixes -target i686-pc-openbsd -static -fno-pie 
%s -### 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHECK-STATIC-PIE %s
+// RUN: %clang -no-canonical-prefixes -target i686-pc-openbsd -nopie %s -### 
2>&1 \
+// RUN:   | FileCheck -check-prefix=CHECK-NOPIE %s
+// RUN: %clang -no-canonical-prefixes -target i686-pc-openbsd -fno-pie -nopie 
%s -### 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHECK-NOPIE %s
+// RUN: %clang -no-canonical-prefixes -target i686-pc-openbsd -static -nopie 
%s -### 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHECK-NOPIE %s
+// RUN: %clang -no-canonical-prefixes -target i686-pc-openbsd -fno-pie -static 
-nopie %s -### 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHECK-NOPIE %s
+// CHECK-PIE: "{{.*}}crt0.o"
+// CHECK-PIE-NOT: "-nopie"
+// CHECK-STATIC-PIE: "{{.*}}rcrt0.o"
+// CHECK-STATIC-PIE-NOT: "-nopie"
+// CHECK-NOPIE: "-nopie" "{{.*}}crt0.o"


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

r295609 - [CUDA] Don't pass -stack-protector to NVPTX compilations.

2017-02-19 Thread Justin Lebar via cfe-commits 
Author: jlebar
Date: Sun Feb 19 13:05:32 2017
New Revision: 295609

URL: http://llvm.org/viewvc/llvm-project?rev=295609=rev
Log:
[CUDA] Don't pass -stack-protector to NVPTX compilations.

We can't support stack-protector on NVPTX because NVPTX doesn't expose a
stack to the compiler!

Fixes PR32009.

Added:
cfe/trunk/test/Driver/cuda-no-stack-protector.cu
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=295609=295608=295609=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Sun Feb 19 13:05:32 2017
@@ -5544,25 +5544,29 @@ void Clang::ConstructJob(Compilation ,
 
   // -stack-protector=0 is default.
   unsigned StackProtectorLevel = 0;
-  if (Arg *A = Args.getLastArg(options::OPT_fno_stack_protector,
-   options::OPT_fstack_protector_all,
-   options::OPT_fstack_protector_strong,
-   options::OPT_fstack_protector)) {
-if (A->getOption().matches(options::OPT_fstack_protector)) {
-  StackProtectorLevel = std::max(
-  LangOptions::SSPOn,
-  getToolChain().GetDefaultStackProtectorLevel(KernelOrKext));
-} else if (A->getOption().matches(options::OPT_fstack_protector_strong))
-  StackProtectorLevel = LangOptions::SSPStrong;
-else if (A->getOption().matches(options::OPT_fstack_protector_all))
-  StackProtectorLevel = LangOptions::SSPReq;
-  } else {
-StackProtectorLevel =
-getToolChain().GetDefaultStackProtectorLevel(KernelOrKext);
-// Only use a default stack protector on Darwin in case -ffreestanding
-// is not specified.
-if (Triple.isOSDarwin() && !IsHosted)
-  StackProtectorLevel = 0;
+  // NVPTX doesn't support stack protectors; from the compiler's perspective, 
it
+  // doesn't even have a stack!
+  if (!Triple.isNVPTX()) {
+if (Arg *A = Args.getLastArg(options::OPT_fno_stack_protector,
+ options::OPT_fstack_protector_all,
+ options::OPT_fstack_protector_strong,
+ options::OPT_fstack_protector)) {
+  if (A->getOption().matches(options::OPT_fstack_protector)) {
+StackProtectorLevel = std::max(
+LangOptions::SSPOn,
+getToolChain().GetDefaultStackProtectorLevel(KernelOrKext));
+  } else if (A->getOption().matches(options::OPT_fstack_protector_strong))
+StackProtectorLevel = LangOptions::SSPStrong;
+  else if (A->getOption().matches(options::OPT_fstack_protector_all))
+StackProtectorLevel = LangOptions::SSPReq;
+} else {
+  StackProtectorLevel =
+  getToolChain().GetDefaultStackProtectorLevel(KernelOrKext);
+  // Only use a default stack protector on Darwin in case -ffreestanding
+  // is not specified.
+  if (Triple.isOSDarwin() && !IsHosted)
+StackProtectorLevel = 0;
+}
   }
   if (StackProtectorLevel) {
 CmdArgs.push_back("-stack-protector");

Added: cfe/trunk/test/Driver/cuda-no-stack-protector.cu
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/cuda-no-stack-protector.cu?rev=295609=auto
==
--- cfe/trunk/test/Driver/cuda-no-stack-protector.cu (added)
+++ cfe/trunk/test/Driver/cuda-no-stack-protector.cu Sun Feb 19 13:05:32 2017
@@ -0,0 +1,23 @@
+// Check that -stack-protector doesn't get passed down to device-side
+// compilation.
+//
+// REQUIRES: clang-driver
+//
+// RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=sm_20 \
+// RUN:   -fstack-protector-all %s 2>&1 | \
+// RUN: FileCheck %s
+//
+// RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=sm_20 \
+// RUN:   -fstack-protector-strong %s 2>&1 | \
+// RUN: FileCheck %s
+//
+// RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=sm_20 \
+// RUN:   -fstack-protector %s 2>&1 | \
+// RUN: FileCheck %s
+//
+// CHECK-NOT: error: unsupported option '-fstack-protector
+// CHECK-DAG: "-fcuda-is-device"
+// CHECK-NOT: "-stack-protector"
+// CHECK-NOT: "-stack-protector-buffer-size"
+// CHECK-DAG: "-triple" "x86_64--linux-gnu"
+// CHECK: "-stack-protector"


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

[PATCH] D30158: [clang-tidy] modernize: Find usage of random_shuffle and replace it with shuffle.

2017-02-19 Thread Mads Ravn via Phabricator via cfe-commits 
madsravn created this revision.
Herald added subscribers: JDevlieghere, mgorny.

random_shuffle was deprecated by C++14 and will be removed by C++17. This check 
will find and replace usage of random_shuffle with its modern counterpart 
(shuffle).


https://reviews.llvm.org/D30158

Files:
  clang-tidy/modernize/CMakeLists.txt
  clang-tidy/modernize/ModernizeTidyModule.cpp
  clang-tidy/modernize/ReplaceRandomShuffleCheck.cpp
  clang-tidy/modernize/ReplaceRandomShuffleCheck.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/modernize-replace-random-shuffle.rst
  test/clang-tidy/modernize-replace-random-shuffle.cpp

Index: test/clang-tidy/modernize-replace-random-shuffle.cpp
===
--- test/clang-tidy/modernize-replace-random-shuffle.cpp
+++ test/clang-tidy/modernize-replace-random-shuffle.cpp
@@ -0,0 +1,55 @@
+// RUN: %check_clang_tidy %s modernize-replace-random-shuffle %t -- -- -std=c++11
+
+namespace std {
+template  struct vec_iterator {
+  T *ptr;
+  vec_iterator operator++(int);
+};
+
+template  struct vector {
+  typedef vec_iterator iterator;
+
+  iterator begin();
+  iterator end();
+};
+
+template 
+void random_shuffle(FwIt begin, FwIt end);
+
+template 
+void random_shuffle(FwIt begin, FwIt end, randomFunc& randomfunc);
+
+template 
+void shuffle(FwIt begin, FwIt end);
+} // namespace std
+
+// Random Func
+int myrandom (int i) { return i;}
+
+int main() {
+  std::vector vec;
+
+  std::random_shuffle(vec.begin(), vec.end());
+  // CHECK-MESSAGE: [[@LINE-1]]:3: warning: do not use 'random_shuffle'. It is deprecated and replaced by 'shuffle'
+  // CHECK-FIXES: std::shuffle(vec.begin(), vec.begin(), std::mt19937(std::random_device()()));
+
+  std::random_shuffle(vec.begin(), vec.end(), myrandom);
+  // CHECK-MESSAGE: [[@LINE-1]]:3: warning: do not use 'random_shuffle'. It is deprecated and replaced by 'shuffle'. The old user defined 'RandomFunction' is not usable for shuffle. You need to make additional changes if you want a specific random function
+  // CHECK-FIXES: std::shuffle(vec.begin(), vec.begin(), std::mt19937(std::random_device()()));
+
+  std::shuffle(vec.begin(), vec.end());
+
+  using namespace std;
+
+  random_shuffle(vec.begin(), vec.end());
+  // CHECK-MESSAGE: [[@LINE-1]]:3: warning: do not use 'random_shuffle'. It is deprecated and replaced by 'shuffle'
+  // CHECK-FIXES: shuffle(vec.begin(), vec.begin(), std::mt19937(std::random_device()()));
+
+  random_shuffle(vec.begin(), vec.end(), myrandom);
+  // CHECK-MESSAGE: [[@LINE-1]]:3: warning: do not use 'random_shuffle'. It is deprecated and replaced by 'shuffle'. The old user defined 'RandomFunction' is not usable for shuffle. You need to make additional changes if you want a specific random function
+  // CHECK-FIXES: shuffle(vec.begin(), vec.begin(), std::mt19937(std::random_device()()));
+
+  shuffle(vec.begin(), vec.end());
+
+  return 0;
+}
Index: docs/clang-tidy/checks/modernize-replace-random-shuffle.rst
===
--- docs/clang-tidy/checks/modernize-replace-random-shuffle.rst
+++ docs/clang-tidy/checks/modernize-replace-random-shuffle.rst
@@ -0,0 +1,26 @@
+.. title:: clang-tidy - modernize-replace-random-shuffle
+
+modernize-replace-random-shuffle
+
+
+This check will find occurences of ``random_shuffle`` and replace it with ``shuffle``. In C++17 ``random_shuffle`` will no longer be available and thus we need to replace it.
+
+Below is two examples of what kind of occurences will be found and two examples of what it will be replaced with.
+
+.. code-block:: c++
+
+  std::vector v;
+
+  // First example
+  std::random_shuffle(vec.begin(), vec.end());
+
+  // Second example
+  std::random_shuffle(vec.begin(), vec.end(), randomFun);
+
+Both these examples will be replaced with
+
+.. code-block:: c++
+
+  std::shuffle(vec.begin(), vec.end(), std::mt19937(std::random_device()()));
+
+The second example will also receive a warning that ``randomFunc`` is no longer supported in the same way as before so if the user wants the same functionality, the user will need to change the implementation of the ``randomFunc``.
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -110,6 +110,7 @@
modernize-raw-string-literal
modernize-redundant-void-arg
modernize-replace-auto-ptr
+   modernize-replace-random-shuffle
modernize-return-braced-init-list
modernize-shrink-to-fit
modernize-use-auto
Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -72,6 +72,11 @@
 
   Finds uses of inline assembler.
 
+- New `modernize-replace-random-shuffle
+

[PATCH] D15227: [analyzer] Valist checkers.

2017-02-19 Thread Gábor Horváth via Phabricator via cfe-commits 
xazax.hun added a comment.

In https://reviews.llvm.org/D15227#681127, @zaks.anna wrote:

> >   But as far as I remember, this produced false negatives in the tests not 
> > false positives.
>
> Could you double check that? Maybe you still have some notes in your mail box 
> or just by looking at the code.
>
> Did none of the checks work or just some of them?
>
> Also, which platforms did this not work on?
>
> It would be great to move all of the useful checks out of alpha since alpha 
> essentially means "unsupported" and we do not recommend turning those 
> checkers on.
>
> Thanks!


I think I managed to solve the problems due to the different AST variants. In 
the future this should be abstracted away by the analyzer core. You can see the 
patch here: https://reviews.llvm.org/D30157

Early next week I will rerun this check on a larger open source project. If it 
does not give me too much false positives or crash, I think it is a good 
candidate to move out from alpha.


Repository:
  rL LLVM

https://reviews.llvm.org/D15227



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

[PATCH] D30157: [analyzer] Improve valist check

2017-02-19 Thread Gábor Horváth via Phabricator via cfe-commits 
xazax.hun created this revision.

This patch makes the valist check more robust to the different kind of ASTs 
that are generated on different platforms:

Generated on x86_64-pc-linux-gnu:

  |-TypedefDecl 0x1d07a40 <>  implicit 
__builtin_ms_va_list 'char *'
  | `-PointerType 0x1d07a00 'char *'
  |   `-BuiltinType 0x1d071b0 'char'
  
  |-TypedefDecl 0x1d07d08 <>  implicit referenced 
__builtin_va_list 'struct __va_list_tag [1]'
  | `-ConstantArrayType 0x1d07cb0 'struct __va_list_tag [1]' 1 
  |   `-RecordType 0x1d07b20 'struct __va_list_tag'
  | `-Record 0x1d07a90 '__va_list_tag'

Generated on hexagon-unknown-linux:

  -TypedefDecl 0x6c47e0 <>  implicit referenced 
__builtin_va_list 'char *'
  | `-PointerType 0x6c47a0 'char *'
  |   `-BuiltinType 0x6c4020 'char'
  
  |-TypedefDecl 0x6c4860 
 col:27 referenced va_list '__builtin_va_list':'char *'
  | `-TypedefType 0x6c4830 '__builtin_va_list' sugar
  |   |-Typedef 0x6c47e0 '__builtin_va_list'
  |   `-PointerType 0x6c47a0 'char *'
  | `-BuiltinType 0x6c4020 'char'

This patch also manages to fix one of the FIXMEs in the tests.

Note that, some tests are only there for x86_64-pc-linux-gnu. The reason is 
that, the analyzer manages to notice the uninitializedness of va_list on 
hexagon-unknown-linux, so it generates a sink node before this check could be 
triggered.


https://reviews.llvm.org/D30157

Files:
  lib/StaticAnalyzer/Checkers/ValistChecker.cpp
  test/Analysis/valist-uninitialized-no-undef.c
  test/Analysis/valist-uninitialized.c
  test/Analysis/valist-unterminated.c

Index: test/Analysis/valist-unterminated.c
===
--- test/Analysis/valist-unterminated.c
+++ test/Analysis/valist-unterminated.c
@@ -1,3 +1,4 @@
+// RUN: %clang_cc1 -triple hexagon-unknown-linux -analyze -analyzer-checker=core,alpha.valist.Unterminated,alpha.valist.CopyToSelf -analyzer-output=text -analyzer-store=region -verify %s
 // RUN: %clang_cc1 -triple x86_64-pc-linux-gnu -analyze -analyzer-checker=core,alpha.valist.Unterminated,alpha.valist.CopyToSelf -analyzer-output=text -analyzer-store=region -verify %s
 
 #include "Inputs/system-header-simulator-for-valist.h"
@@ -28,9 +29,8 @@
 }
 
 void f5(va_list fst, ...) {
-  va_start(fst, fst);
-  //FIXME: this should cause a warning
-} // no-warning
+  va_start(fst, fst); // expected-note{{Initialized va_list}}
+} // expected-warning{{Initialized va_list}} expected-note{{Initialized va_list}}
 
 void f6(va_list *fst, ...) {
   va_start(*fst, fst); // expected-note{{Initialized va_list}}
Index: test/Analysis/valist-uninitialized.c
===
--- test/Analysis/valist-uninitialized.c
+++ test/Analysis/valist-uninitialized.c
@@ -1,4 +1,5 @@
-// RUN: %clang_cc1 -triple x86_64-pc-linux-gnu -analyze -analyzer-checker=core,alpha.valist.Uninitialized,alpha.valist.CopyToSelf -analyzer-output=text -analyzer-store=region -verify %s
+// RUN: %clang_cc1 -triple hexagon-unknown-linux -analyze -analyzer-checker=core,alpha.valist.Uninitialized,alpha.valist.CopyToSelf -analyzer-disable-checker=core.CallAndMessage -analyzer-output=text -analyzer-store=region -verify %s
+// RUN: %clang_cc1 -triple x86_64-pc-linux-gnu -analyze -analyzer-checker=core,alpha.valist.Uninitialized,alpha.valist.CopyToSelf -analyzer-disable-checker=core.CallAndMessage -analyzer-output=text -analyzer-store=region -verify %s
 
 #include "Inputs/system-header-simulator-for-valist.h"
 
@@ -38,13 +39,6 @@
   va_end(fst);
 } // no-warning
 
-//FIXME: this should not cause a warning
-void f6(va_list *fst, ...) {
-  va_start(*fst, fst);
-  (void)va_arg(*fst, int); //expected-warning{{va_arg() is called on an uninitialized va_list}} expected-note{{va_arg() is called on an uninitialized va_list}}
-  va_end(*fst);
-}
-
 void f7(int *fst, ...) {
   va_list x;
   va_list *y = 
@@ -141,36 +135,13 @@
   (void)va_arg(arg, int);
 } //no-warning
 
-// This is the same function as the previous one, but it is called in call_uses_arg2(),
-// and the warning is generated during the analysis of call_uses_arg2().
-void inlined_uses_arg(va_list arg) {
-  (void)va_arg(arg, int); //expected-warning{{va_arg() is called on an uninitialized va_list}} expected-note{{va_arg() is called on an uninitialized va_list}}
-}
-
-void call_inlined_uses_arg(int fst, ...) {
-  va_list va;
-  inlined_uses_arg(va); // expected-note{{Calling 'inlined_uses_arg'}}
-}
-
 void call_vprintf_ok(int isstring, ...) {
   va_list va;
   va_start(va, isstring);
   vprintf(isstring ? "%s" : "%d", va);
   va_end(va);
 } //no-warning
 
-void call_vprintf_bad(int isstring, ...) {
-  va_list va;
-  vprintf(isstring ? "%s" : "%d", va); //expected-warning{{Function 'vprintf' is called with an uninitialized va_list argument}} expected-note{{Function 'vprintf' is called with an uninitialized va_list argument}} expected-note{{Assuming 'isstring' is 0}} expected-note{{'?' condition is false}}
-}
-
-void

[PATCH] D27827: [ObjC] CodeGen support for @available on macOS

2017-02-19 Thread Erik Pilkington via Phabricator via cfe-commits 
erik.pilkington updated this revision to Diff 89067.
erik.pilkington added a comment.

This new patch just generates a call to the function `_IsOSVersionAtLeast` and 
branches on the result. `_IsOSVersionAtLeast` is going through review here: 
https://reviews.llvm.org/D30136.

I decided to parse the SystemVersion.plist file, I think mapping from kernel 
versions to marketing versions works for macOS, but not for iOS, as iOS tends 
to cling on to darwin versions for longer. For example, darwin 14.0.0 was used 
from iOS 7.0 until iOS 8.4.1, (based on the table here: 
https://www.theiphonewiki.com/wiki/Kernel) which is not fine grain enough for 
use with `@available`.

Thanks for taking a look!
Erik


https://reviews.llvm.org/D27827

Files:
  lib/CodeGen/CGExprScalar.cpp
  lib/CodeGen/CGObjC.cpp
  lib/CodeGen/CodeGenFunction.h
  lib/CodeGen/CodeGenModule.h
  test/CodeGenObjC/availability-check.m

Index: test/CodeGenObjC/availability-check.m
===
--- test/CodeGenObjC/availability-check.m
+++ test/CodeGenObjC/availability-check.m
@@ -0,0 +1,15 @@
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.11 -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -xc -triple x86_64-apple-macosx10.11 -emit-llvm -o - %s | FileCheck %s
+
+void use_at_available() {
+  // CHECK: call i32 @_IsOSVersionAtLeast(i32 10, i32 12, i32 0)
+  // CHECK-NEXT: icmp ne
+  if (__builtin_available(macos 10.12, *))
+;
+  // This check should be folded: our deployment target is 10.11.
+  // CHECK-NOT: call i32 @_IsOSVersionAtLeast
+  if (__builtin_available(macos 10.11, *))
+;
+}
+
+// CHECK: declare i32 @_IsOSVersionAtLeast(i32, i32, i32)
Index: lib/CodeGen/CodeGenModule.h
===
--- lib/CodeGen/CodeGenModule.h
+++ lib/CodeGen/CodeGenModule.h
@@ -546,6 +546,10 @@
 return *ObjCData;
   }
 
+  // Version checking function, used to implement ObjC's @available:
+  // i32 @_IsOSVersionAtLeast(i32, i32, i32)
+  llvm::Constant *ObjCIsOSVersionAtLeastFn = nullptr;
+
   InstrProfStats () { return PGOStats; }
   llvm::IndexedInstrProfReader *getPGOReader() const { return PGOReader.get(); }
 
Index: lib/CodeGen/CodeGenFunction.h
===
--- lib/CodeGen/CodeGenFunction.h
+++ lib/CodeGen/CodeGenFunction.h
@@ -2476,6 +2476,8 @@
   void EmitObjCAtSynchronizedStmt(const ObjCAtSynchronizedStmt );
   void EmitObjCAutoreleasePoolStmt(const ObjCAutoreleasePoolStmt );
 
+  llvm::Value *EmitObjCIsOSVersionAtLeast(ArrayRef Args);
+
   void EmitCoroutineBody(const CoroutineBodyStmt );
   RValue EmitCoroutineIntrinsic(const CallExpr *E, unsigned int IID);
 
Index: lib/CodeGen/CGObjC.cpp
===
--- lib/CodeGen/CGObjC.cpp
+++ lib/CodeGen/CGObjC.cpp
@@ -3399,5 +3399,21 @@
   return Val;
 }
 
+llvm::Value *
+CodeGenFunction::EmitObjCIsOSVersionAtLeast(ArrayRef Args) {
+  assert(Args.size() == 3 && "Expected 3 argument here!");
+
+  if (!CGM.ObjCIsOSVersionAtLeastFn) {
+llvm::FunctionType *FTy =
+llvm::FunctionType::get(Int32Ty, {Int32Ty, Int32Ty, Int32Ty}, false);
+CGM.ObjCIsOSVersionAtLeastFn =
+CGM.CreateRuntimeFunction(FTy, "_IsOSVersionAtLeast");
+  }
+
+  llvm::Value *CallRes =
+  EmitNounwindRuntimeCall(CGM.ObjCIsOSVersionAtLeastFn, Args);
+
+  return Builder.CreateICmpNE(CallRes, llvm::Constant::getNullValue(Int32Ty));
+}
 
 CGObjCRuntime::~CGObjCRuntime() {}
Index: lib/CodeGen/CGExprScalar.cpp
===
--- lib/CodeGen/CGExprScalar.cpp
+++ lib/CodeGen/CGExprScalar.cpp
@@ -300,6 +300,24 @@
 return V;
   }
 
+  Value *VisitObjCAvailabilityCheckExpr(ObjCAvailabilityCheckExpr *E) {
+VersionTuple Version = E->getVersion();
+
+// If we're checking for a platform older than our minimum deployment
+// target, we can fold the check away.
+if (Version <= CGF.CGM.getTarget().getPlatformMinVersion())
+  return llvm::ConstantInt::get(Builder.getInt1Ty(), 1);
+
+Optional Min = Version.getMinor(), SMin = Version.getSubminor();
+llvm::Value *Args[] = {
+llvm::ConstantInt::get(CGF.CGM.Int32Ty, Version.getMajor()),
+llvm::ConstantInt::get(CGF.CGM.Int32Ty, Min ? *Min : 0),
+llvm::ConstantInt::get(CGF.CGM.Int32Ty, SMin ? *SMin : 0),
+};
+
+return CGF.EmitObjCIsOSVersionAtLeast(Args);
+  }
+
   Value *VisitArraySubscriptExpr(ArraySubscriptExpr *E);
   Value *VisitShuffleVectorExpr(ShuffleVectorExpr *E);
   Value *VisitConvertVectorExpr(ConvertVectorExpr *E);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D30155: [clang-tools-extra] [test] Fix clang library dir in LD_LIBRARY_PATH For stand-alone build

2017-02-19 Thread Michał Górny via Phabricator via cfe-commits 
mgorny created this revision.
mgorny added a project: clang-tools-extra.

Prepend the clang library directory (determined using SHLIBDIR, alike
in clang) to the LD_LIBRARY_PATH to ensure that just-built clang
libraries will be used instead of a previous installed version.

When a stand-alone build is performed, LLVM_LIBS_DIR contains the path
to installed LLVM library directory. The same directory frequently
contains a previously installed version of clang. SHLIBDIR, on the other
hand, is always the build-tree directory, and therefore contains
the freshly built clang libraries.

In a non-stand-alone build, both paths will be the same and therefore
including them both will not cause any issues.


Repository:
  rL LLVM

https://reviews.llvm.org/D30155

Files:
  test/Unit/lit.cfg
  test/lit.cfg
  test/lit.site.cfg.in


Index: test/lit.site.cfg.in
===
--- test/lit.site.cfg.in
+++ test/lit.site.cfg.in
@@ -7,6 +7,7 @@
 config.lit_tools_dir = "@LLVM_LIT_TOOLS_DIR@"
 config.clang_tools_binary_dir = "@CLANG_TOOLS_BINARY_DIR@"
 config.clang_tools_dir = "@CLANG_TOOLS_DIR@"
+config.clang_libs_dir = "@SHLIBDIR@"
 config.python_executable = "@PYTHON_EXECUTABLE@"
 config.target_triple = "@TARGET_TRIPLE@"
 
Index: test/lit.cfg
===
--- test/lit.cfg
+++ test/lit.cfg
@@ -99,10 +99,13 @@
 clang_tools_dir, llvm_tools_dir, config.environment['PATH']))
 config.environment['PATH'] = path
 
+clang_libs_dir = getattr(config, 'clang_libs_dir', None)
+if not clang_libs_dir:
+lit_config.fatal('No Clang libs dir set!')
 llvm_libs_dir = getattr(config, 'llvm_libs_dir', None)
 if not llvm_libs_dir:
 lit_config.fatal('No LLVM libs dir set!')
-path = os.path.pathsep.join((llvm_libs_dir,
+path = os.path.pathsep.join((clang_libs_dir, llvm_libs_dir,
  config.environment.get('LD_LIBRARY_PATH','')))
 config.environment['LD_LIBRARY_PATH'] = path
 
Index: test/Unit/lit.cfg
===
--- test/Unit/lit.cfg
+++ test/Unit/lit.cfg
@@ -41,14 +41,17 @@
 shlibpath_var = 'PATH'
 
 # Point the dynamic loader at dynamic libraries in 'lib'.
+shlibdir = getattr(config, 'shlibdir', None)
+if not shlibdir:
+lit_config.fatal('No shlibdir set!')
 llvm_libs_dir = getattr(config, 'llvm_libs_dir', None)
 if not llvm_libs_dir:
 lit_config.fatal('No LLVM libs dir set!')
-shlibpath = os.path.pathsep.join((llvm_libs_dir,
+shlibpath = os.path.pathsep.join((shlibdir, llvm_libs_dir,
  config.environment.get(shlibpath_var,'')))
 
 # Win32 seeks DLLs along %PATH%.
-if sys.platform in ['win32', 'cygwin'] and os.path.isdir(config.shlibdir):
-shlibpath = os.path.pathsep.join((config.shlibdir, shlibpath))
+if sys.platform in ['win32', 'cygwin'] and os.path.isdir(shlibdir):
+shlibpath = os.path.pathsep.join((shlibdir, shlibpath))
 
 config.environment[shlibpath_var] = shlibpath


Index: test/lit.site.cfg.in
===
--- test/lit.site.cfg.in
+++ test/lit.site.cfg.in
@@ -7,6 +7,7 @@
 config.lit_tools_dir = "@LLVM_LIT_TOOLS_DIR@"
 config.clang_tools_binary_dir = "@CLANG_TOOLS_BINARY_DIR@"
 config.clang_tools_dir = "@CLANG_TOOLS_DIR@"
+config.clang_libs_dir = "@SHLIBDIR@"
 config.python_executable = "@PYTHON_EXECUTABLE@"
 config.target_triple = "@TARGET_TRIPLE@"
 
Index: test/lit.cfg
===
--- test/lit.cfg
+++ test/lit.cfg
@@ -99,10 +99,13 @@
 clang_tools_dir, llvm_tools_dir, config.environment['PATH']))
 config.environment['PATH'] = path
 
+clang_libs_dir = getattr(config, 'clang_libs_dir', None)
+if not clang_libs_dir:
+lit_config.fatal('No Clang libs dir set!')
 llvm_libs_dir = getattr(config, 'llvm_libs_dir', None)
 if not llvm_libs_dir:
 lit_config.fatal('No LLVM libs dir set!')
-path = os.path.pathsep.join((llvm_libs_dir,
+path = os.path.pathsep.join((clang_libs_dir, llvm_libs_dir,
  config.environment.get('LD_LIBRARY_PATH','')))
 config.environment['LD_LIBRARY_PATH'] = path
 
Index: test/Unit/lit.cfg
===
--- test/Unit/lit.cfg
+++ test/Unit/lit.cfg
@@ -41,14 +41,17 @@
 shlibpath_var = 'PATH'
 
 # Point the dynamic loader at dynamic libraries in 'lib'.
+shlibdir = getattr(config, 'shlibdir', None)
+if not shlibdir:
+lit_config.fatal('No shlibdir set!')
 llvm_libs_dir = getattr(config, 'llvm_libs_dir', None)
 if not llvm_libs_dir:
 lit_config.fatal('No LLVM libs dir set!')
-shlibpath = os.path.pathsep.join((llvm_libs_dir,
+shlibpath = os.path.pathsep.join((shlibdir, llvm_libs_dir,
  config.environment.get(shlibpath_var,'')))
 
 # Win32