RE: [PATCH] D13015: [X86] Make f16c intrinsics accessible through emmintrin.h, per Intel docs

[Kuperstein, Michael M via cfe-commits]

Hi Paul,

I'd rather not move them into immintrin.h. The current situation is that if you 
include emmintrin.h you get "too many" intrinsics w.r.t to the Intel docs (and 
immintrin.h is just right, since it recursively includes emmintrin.h), while if 
we move it to immintrin.h, including emmintrin.h would provide "not enough" 
intrinsics. So, in terms of compatibility, I think this is slightly better.
Regarding MSVC and GCC - MSVC doesn't have an emmintrin.h (or any other 
specialized intrinsic file) and puts everything in immintrin.h. GCC, in my 
opinion, should probably also be fixed. :-)

On the other hand, I undersand why providing _mm256 stuff in emmintrin.h may be 
a problem. Perhaps we can split the file in two (or move the relevant 
intrinsics directly into emm/immintrin)?
That would means our header structure is slightly different from GCC's, but 
since this file should not be included directly anyway, that doesn't really 
bother me.
Does that sound reasonable to you?

Michael

-Original Message-
From: Paul Robinson [mailto:paul_robin...@playstation.sony.com] 
Sent: Monday, November 30, 2015 23:01
To: Kuperstein, Michael M; Badouh, Asaf
Cc: cfe-commits@lists.llvm.org
Subject: Re: [PATCH] D13015: [X86] Make f16c intrinsics accessible through 
emmintrin.h, per Intel docs

probinson added a subscriber: probinson.
probinson added a comment.

Regarding _mm[256]_cvtps_ph and ...cvtph_ps, I can find an Intel doc that say 
the _mm_* functions are in emmintrin.h and the _mm256_* are in immintrin.h, so 
putting them all with emmintrin.h is not consistent with what Intel says.  I 
can find a Microsoft doc that say these are all available with immintrin.h (not 
emmintrin.h).  It looks like gcc puts them with immintrin.h also.

Can we move the #include of f16cintrin.h from emmintrin.h to immintrin.h?  It 
would be more compatible with everybody else, and equally inconsistent with 
Intel's doc AFAICT.


Repository:
  rL LLVM

http://reviews.llvm.org/D13015



-
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r254389 - [X86] Improve codegen for AVX2 gather with an all 1s mask.

[Craig Topper via cfe-commits]

Author: ctopper
Date: Tue Dec  1 01:12:59 2015
New Revision: 254389

URL: http://llvm.org/viewvc/llvm-project?rev=254389&view=rev
Log:
[X86] Improve codegen for AVX2 gather with an all 1s mask.

Use undefined instead of setzero as the pass through input since its going to 
be fully overwritten. Use cmpeq of two zero vectors to produce the all 1s 
vector. Casting -1 to a double and vectorizing causes a constant load of a -1.0 
floating point value.

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

Modified: cfe/trunk/lib/Headers/avx2intrin.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/avx2intrin.h?rev=254389&r1=254388&r2=254389&view=diff
==
--- cfe/trunk/lib/Headers/avx2intrin.h (original)
+++ cfe/trunk/lib/Headers/avx2intrin.h Tue Dec  1 01:12:59 2015
@@ -1100,103 +1100,112 @@ _mm_srlv_epi64(__m128i __X, __m128i __Y)
(__v4di)(__m256i)(mask), (s)); })
 
 #define _mm_i32gather_pd(m, i, s) __extension__ ({ \
-  (__m128d)__builtin_ia32_gatherd_pd((__v2df)_mm_setzero_pd(), \
+  (__m128d)__builtin_ia32_gatherd_pd((__v2df)_mm_undefined_pd(), \
  (double const *)(m), \
  (__v4si)(__m128i)(i), \
- (__v2df)_mm_set1_pd( \
-   (double)(long long int)-1), \
+ (__v2df)_mm_cmpeq_pd(_mm_setzero_pd(), \
+  _mm_setzero_pd()), \
  (s)); })
 
 #define _mm256_i32gather_pd(m, i, s) __extension__ ({ \
-  (__m256d)__builtin_ia32_gatherd_pd256((__v4df)_mm256_setzero_pd(), \
+  (__m256d)__builtin_ia32_gatherd_pd256((__v4df)_mm256_undefined_pd(), \
 (double const *)(m), \
 (__v4si)(__m128i)(i), \
-(__v4df)_mm256_set1_pd( \
-  (double)(long long int)-1), \
+
(__v4df)_mm256_cmp_pd(_mm256_setzero_pd(), \
+  
_mm256_setzero_pd(), \
+  _CMP_EQ_OQ), \
 (s)); })
 
 #define _mm_i64gather_pd(m, i, s) __extension__ ({ \
-  (__m128d)__builtin_ia32_gatherq_pd((__v2df)_mm_setzero_pd(), \
+  (__m128d)__builtin_ia32_gatherq_pd((__v2df)_mm_undefined_pd(), \
  (double const *)(m), \
  (__v2di)(__m128i)(i), \
- (__v2df)_mm_set1_pd( \
-   (double)(long long int)-1), \
+ (__v2df)_mm_cmpeq_pd(_mm_setzero_pd(), \
+  _mm_setzero_pd()), \
  (s)); })
 
 #define _mm256_i64gather_pd(m, i, s) __extension__ ({ \
-  (__m256d)__builtin_ia32_gatherq_pd256((__v4df)_mm256_setzero_pd(), \
+  (__m256d)__builtin_ia32_gatherq_pd256((__v4df)_mm256_undefined_pd(), \
 (double const *)(m), \
 (__v4di)(__m256i)(i), \
-(__v4df)_mm256_set1_pd( \
-  (double)(long long int)-1), \
+
(__v4df)_mm256_cmp_pd(_mm256_setzero_pd(), \
+  
_mm256_setzero_pd(), \
+  _CMP_EQ_OQ), \
 (s)); })
 
 #define _mm_i32gather_ps(m, i, s) __extension__ ({ \
-  (__m128)__builtin_ia32_gatherd_ps((__v4sf)_mm_setzero_ps(), \
-(float const *)(m), (__v4si)(__m128i)(i), \
-(__v4sf)_mm_set1_ps((float)(int)-1), \
+  (__m128)__builtin_ia32_gatherd_ps((__v4sf)_mm_undefined_ps(), \
+(float const *)(m), \
+(__v4si)(__m128i)(i), \
+(__v4sf)_mm_cmpeq_ps(_mm_setzero_ps(), \
+ _mm_setzero_ps()), \
 (s)); })
 
 #define _mm256_i32gather_ps(m, i, s) __extension__ ({ \
-  (__m256)__builtin_ia32_gatherd_ps256((__v8sf)_mm256_setzero_ps(), \
+  (__m256)__builtin_ia32_gatherd_ps256((__v8sf)_mm256_undefined_ps(), \
(float const *)(m), \
(__v8si)(__m256i)(i), \
-   (__v8sf)_mm256_set1_ps((float)(int)-1), 
\
+   
(__v8sf)_mm256_cmp_ps(_mm2

Re: [PATCH] D14180: enable -fms-extensions by default on the mingw-w64 target

[Martell Malone via cfe-commits]

martell added a comment.

I tried testing __has_builtin(_InterlockedCompareExchangeAdd) as it seem to not 
exist even when -fms-extensions is passed
Is this a bug or it is intended ?


http://reviews.llvm.org/D14180



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

Re: Buildbot numbers for week of 11/22/2015 - 11/28/2015

[Tobias Grosser via cfe-commits]

On 12/01/2015 02:05 AM, David Blaikie wrote:



On Mon, Nov 30, 2015 at 5:00 PM, Galina Kistanova mailto:gkistan...@gmail.com>> wrote:

Hi David,

Thank you for the useful suggestions, I will work on these.

>I guess the entries with no entry in the failed column have zero failures?
Yes.

  perf-x86_64-penryn-O3-polly-before-vectorizer
| 31 | 31 |
  perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only
| 31 | 27 | 05:28:12

These /\ two builders failed most of the time, but they also only
ran a handful of times. I guess they're triggering off polly changes
only? I wonder if they should trigger off LLVM changes too, but I'm
not sure.

They build on llvm changes also, but they both build for quite a
long time. I think it's the reason why they do not build more.


Ah, OK - so the other suggestions might help demonstrate/understand that
behavior better.


These buildbots run performance tests, meaning they run the LNT test 
suite 10 times per run to get stable results. They are triggered on any 
LLVM/clang/Polly test but do not run more often just because we do not
have more hardware to run them more often. The relevant buildslave is 
constantly building something.



Tobias - any idea why these builders are /quite/ so slow & whether they
could be improved? With large blame lists that come from a small number
of slaves on a slow builder task it makes them hard to action. Are they
useful to you?


These bots do _not_ send out any emails, exactly for this reason. But 
yes, they are very useful to quickly get an idea of our current 
compile-time/run-time performance.


Thanks for you taking care of the buildbot noise. If my bots cause any 
issue for you, please let me know. Ensuring low noise is very important.


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

Re: [PATCH] D14731: [libcxx] Add clang thread safety annotations to mutex and lock_guard

[Marshall Clow via cfe-commits]

mclow.lists added a comment.

Where are the tests?


http://reviews.llvm.org/D14731



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

Re: [PATCH] D14940: [OpenMP] Update target directive codegen to use 4.5 implicit data mappings.

[Samuel Antao via cfe-commits]

sfantao added a comment.

Hi Alexey,

Thanks for the review!



Comment at: include/clang/AST/Stmt.h:2018-2020
@@ -2016,2 +2017,5 @@
 break;
+  case VCK_ByCopy:
+assert(Var && "capturing by copy must have a variable!");
+break;
   case VCK_VLAType:

ABataev wrote:
> Also add assertion that only pointers anmd scalars are allowed to be captured 
> by value
Done! Note however that VarDecl was an incomplete type here. So I moved the 
code to Stmt.cpp.


Comment at: lib/Sema/SemaOpenMP.cpp:818-819
@@ +817,4 @@
+// captures in that those cases.
+IsByRef = isa(Ty) || isa(Ty) ||
+  isa(Ty);
+  }

ABataev wrote:
> Wow. I think it is just enough to check !Ty->isScalarType().
Oh, right. Changed that to use `isScalarType`.


http://reviews.llvm.org/D14940



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

r254365 - [modules] Don't reject multiple modules providing contents for the same embedded file.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Mon Nov 30 21:32:49 2015
New Revision: 254365

URL: http://llvm.org/viewvc/llvm-project?rev=254365&view=rev
Log:
[modules] Don't reject multiple modules providing contents for the same 
embedded file.

Added:
cfe/trunk/test/Modules/embed-files.cpp
Modified:
cfe/trunk/lib/Serialization/ASTReader.cpp

Modified: cfe/trunk/lib/Serialization/ASTReader.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTReader.cpp?rev=254365&r1=254364&r2=254365&view=diff
==
--- cfe/trunk/lib/Serialization/ASTReader.cpp (original)
+++ cfe/trunk/lib/Serialization/ASTReader.cpp Mon Nov 30 21:32:49 2015
@@ -1963,7 +1963,8 @@ InputFile ASTReader::getInputFile(Module
   // can lead to problems when lexing using the source locations from the
   // PCH.
   SourceManager &SM = getSourceManager();
-  if (!Overridden && SM.isFileOverridden(File)) {
+  // FIXME: Reject if the overrides are different.
+  if ((!Overridden && !Transient) && SM.isFileOverridden(File)) {
 if (Complain)
   Error(diag::err_fe_pch_file_overridden, Filename);
 // After emitting the diagnostic, recover by disabling the override so

Added: cfe/trunk/test/Modules/embed-files.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/embed-files.cpp?rev=254365&view=auto
==
--- cfe/trunk/test/Modules/embed-files.cpp (added)
+++ cfe/trunk/test/Modules/embed-files.cpp Mon Nov 30 21:32:49 2015
@@ -0,0 +1,15 @@
+// RUN: rm -rf %t
+// RUN: mkdir %t
+// RUN: echo 'module a { header "a.h" } module b { header "b.h" }' > 
%t/modulemap
+// RUN: echo 'extern int t;' > %t/t.h
+// RUN: echo '#include "t.h"' > %t/a.h
+// RUN: echo '#include "t.h"' > %t/b.h
+
+// RUN: %clang_cc1 -fmodules -I%t -fmodules-cache-path=%t 
-fmodule-map-file=%t/modulemap -fmodules-embed-all-files %s -verify
+#include "a.h"
+char t; // expected-error {{different type}}
+// expected-note@t.h:1 {{here}}
+#include "t.h"
+#include "b.h"
+char t; // expected-error {{different type}}
+// expected-note@t.h:1 {{here}}


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

Re: [PATCH] D15095: Accept "-Weverything" in pragma clang diagnostic ...

[Richard Smith via cfe-commits]

rsmith added a subscriber: rsmith.


Comment at: lib/Basic/Diagnostic.cpp:251-257
@@ -250,2 +250,9 @@
 SourceLocation Loc) {
+  // Special handling for pragma clang diagnostic ... "-Weverything"
+  // There is no formal group named "everything", so there has to be a special
+  // case for it.
+  if (Group == "everything") {
+   setSeverityForAll(Flavor, Map, Loc);
+   return false;
+  }
   // Get the diagnostics in this group.

If you want to handle this at the `DiagnosticsEngine` level, please do so 
consistently: teach `getDiagnosticsInGroup` about this special case too, and 
remove the now-redundant code in `clang::ProcessWarningOptions`.

This is not currently setting the `EnableAllWarnings` flag correctly on the 
`DiagnosticsEngine`.


Comment at: test/Frontend/Peverything.cpp:1
@@ +1,2 @@
+// RUN: %clang_cc1 %s -fsyntax-only -verify
+#pragma clang diagnostic error "-Weverything" 

This test belongs in **test/Preprocessor/pragma_diagnostic.c**.


Comment at: test/Frontend/Peverything.cpp:2
@@ +1,3 @@
+// RUN: %clang_cc1 %s -fsyntax-only -verify
+#pragma clang diagnostic error "-Weverything" 
+

Please also test that `#pragma clang diagnostic push/pop` work for this flag.


http://reviews.llvm.org/D15095



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

Re: [PATCH] D14919: Fix IssueHash generation

[Anna Zaks via cfe-commits]

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

LGTM.


http://reviews.llvm.org/D14919



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

Re: [Static Analyzer] New checker hook: checkInitialState

[Gabor Kozar via cfe-commits]

This patch proposal is now on Phabricator: http://reviews.llvm.org/D15090 - 
let's continue this discussion there.

> At a glance, I wonder if it's worth it to provide a CheckerContext
inside this callback and then handle transitions properly (which would
allow the checker to split the program state at the very beginning of
the function). I cannot instantly think of a use-case (hmm, maybe
somebody would like to eagerly discriminate between a NULL and non-NULL
pointer argument of the function), but at the same time I don't see any
obvious problems with adding it, especially because it'd be hard to
change the API when the use-case appears.

Artem: thanks for your comment! I've added it to the Phabricator
summary, along with my reaction to it. I think your proposal is good,
I've started working on implementing it, but I also want to hear what
others (Anna, Jordan) think.

---
Best regards,

Gábor 'ShdNx' Kozár http://gaborkozar.me



On Mon, Nov 30, 2015, at 16:38, Artem Dergachev via cfe-commits wrote:
> Hmm. I once thought about creating a 'checkBeginAnalysis()' callback
> to match 'checkEndAnalysis()'; this one's more powerful, and matches
> 'checkEndFunction()' in a similar manner.
>
> At a glance, I wonder if it's worth it to provide a CheckerContext
> inside this callback and then handle transitions properly (which would
> allow the checker to split the program state at the very beginning of
> the function). I cannot instantly think of a use-case (hmm, maybe
> somebody would like to eagerly discriminate between a NULL and non-
> NULL pointer argument of the function), but at the same time I don't
> see any obvious problems with adding it, especially because it'd be
> hard to change the API when the use-case appears.
> _
> 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] D14980: PR18513: make gcc compatible layout for bit-fields with explicit aligned attribute

[John McCall via cfe-commits]

On Mon, Nov 30, 2015 at 2:31 PM, Richard Smith 
wrote:

> On Mon, Nov 30, 2015 at 11:33 AM, John McCall  wrote:
>
>> rjmccall added a comment.
>>
>> In http://reviews.llvm.org/D14980#298754, @rsmith wrote:
>>
>> > GCC's behavior (`aligned` on a field specifies the alignment of the
>> start of that field) makes a little more sense to me than Clang's behavior
>> (the type and alignment of a field specify a flavour of storage unit, and
>> the field goes in the next such storage unit that it fits into), but both
>> seem defensible.
>>
>>
>> Are you saying that `aligned` on a bit-field always starts new storage on
>> GCC?
>
>
> Not exactly. For instance, given
>
> struct X {
>   __attribute__((aligned(1))) char a : 2, b : 2, c : 2, d : 2;
> } x = {0, 1, 2, 3};
>
> ... GCC produces
>
> x:
> .byte   0
> .byte   1
> .byte   2
> .byte   3
>
> The result is the same for any other bit-field type (except that we get
> tail padding for types wider than 4 bytes), and in particular, we don't
> allocate a new storage unit for 'b' and 'd' when the type is 'short'; we
> just insert padding to get to a 1-byte-aligned boundary.
>

This is what I meant by starting new storage: it never fills space in the
previous byte.  And now I realize that of course that's the major effect of
this patch.

The rule that a bit-field can't straddle a naturally-aligned storage unit
> for the underlying type still applies (for non-packed structs).
>

This is going to require significant surgery to this function.  And it
looks like this rule should apply to ms_struct layout as well.

In other words:
  - The offset of the field is rounded up to the next multiple of the
explicit alignment that (unless the field is packed) does not cause the
field to straddle its natural alignment boundary, which can happen if its
explicit alignment is less than its natural alignment.
  - On platforms (like ARM) that ignore the natural alignment of
bit-fields, this seems to have no effect except to always start a new
byte.  We seem to be getting this wrong, too.
  - Both the field's natural alignment and its explicit alignment, as
capped by the max field alignment, contribute to the alignment of the
aggregate, unless the field is packed.  Again, currently wrong.

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

r254359 - Fix use-after-free when a C++ thread_local variable gets replaced (because its

[Richard Smith via cfe-commits]

Author: rsmith
Date: Mon Nov 30 19:10:48 2015
New Revision: 254359

URL: http://llvm.org/viewvc/llvm-project?rev=254359&view=rev
Log:
Fix use-after-free when a C++ thread_local variable gets replaced (because its
type changes when the initializer is attached). Don't hold onto the
GlobalVariable*; recompute it from the VarDecl* instead.

Modified:
cfe/trunk/lib/CodeGen/CGCXXABI.h
cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.h
cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
cfe/trunk/test/CodeGenCXX/cxx11-thread-local.cpp

Modified: cfe/trunk/lib/CodeGen/CGCXXABI.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCXXABI.h?rev=254359&r1=254358&r2=254359&view=diff
==
--- cfe/trunk/lib/CodeGen/CGCXXABI.h (original)
+++ cfe/trunk/lib/CodeGen/CGCXXABI.h Mon Nov 30 19:10:48 2015
@@ -538,11 +538,9 @@ public:
   ///thread_local variables, a list of functions to perform the
   ///initialization.
   virtual void EmitThreadLocalInitFuncs(
-  CodeGenModule &CGM,
-  ArrayRef>
-  CXXThreadLocals,
+  CodeGenModule &CGM, ArrayRef CXXThreadLocals,
   ArrayRef CXXThreadLocalInits,
-  ArrayRef CXXThreadLocalInitVars) = 0;
+  ArrayRef CXXThreadLocalInitVars) = 0;
 
   // Determine if references to thread_local global variables can be made
   // directly or require access through a thread wrapper function.

Modified: cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDeclCXX.cpp?rev=254359&r1=254358&r2=254359&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDeclCXX.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDeclCXX.cpp Mon Nov 30 19:10:48 2015
@@ -337,7 +337,7 @@ CodeGenModule::EmitCXXGlobalVarDeclInitF
 // FIXME: We only need to register one __cxa_thread_atexit function for the
 // entire TU.
 CXXThreadLocalInits.push_back(Fn);
-CXXThreadLocalInitVars.push_back(Addr);
+CXXThreadLocalInitVars.push_back(D);
   } else if (PerformInit && ISA) {
 EmitPointerToInitFunc(D, Addr, Fn, ISA);
   } else if (auto *IPA = D->getAttr()) {

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=254359&r1=254358&r2=254359&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Mon Nov 30 19:10:48 2015
@@ -1986,7 +1986,7 @@ CodeGenModule::GetOrCreateLLVMGlobal(Str
 
 if (D->getTLSKind()) {
   if (D->getTLSKind() == VarDecl::TLS_Dynamic)
-CXXThreadLocals.push_back(std::make_pair(D, GV));
+CXXThreadLocals.push_back(D);
   setTLSMode(GV, *D);
 }
 
@@ -2379,7 +2379,7 @@ void CodeGenModule::EmitGlobalVarDefinit
 
   if (D->getTLSKind() && !GV->isThreadLocal()) {
 if (D->getTLSKind() == VarDecl::TLS_Dynamic)
-  CXXThreadLocals.push_back(std::make_pair(D, GV));
+  CXXThreadLocals.push_back(D);
 setTLSMode(GV, *D);
   }
 

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.h?rev=254359&r1=254358&r2=254359&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.h (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.h Mon Nov 30 19:10:48 2015
@@ -378,13 +378,12 @@ private:
   StaticExternCMap StaticExternCValues;
 
   /// \brief thread_local variables defined or used in this TU.
-  std::vector >
-CXXThreadLocals;
+  std::vector CXXThreadLocals;
 
   /// \brief thread_local variables with initializers that need to run
   /// before any thread_local variable in this TU is odr-used.
   std::vector CXXThreadLocalInits;
-  std::vector CXXThreadLocalInitVars;
+  std::vector CXXThreadLocalInitVars;
 
   /// Global variables with initializers that need to run before main.
   std::vector CXXGlobalInits;

Modified: cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp?rev=254359&r1=254358&r2=254359&view=diff
==
--- cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp (original)
+++ cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp Mon Nov 30 19:10:48 2015
@@ -327,10 +327,9 @@ public:
 llvm::Value *Val);
   void EmitThreadLocalInitFuncs(
   CodeGenModule &CGM,
-  ArrayRef>
-  CXXThreadLocals,
+  ArrayRef CXXThreadLocals,
   ArrayRef CXXThreadLocalInits,
-  ArrayRef CXXThreadLocalInitVars) override;
+  ArrayRef CXXThreadLocalInitVars) override;
 
   bool usesThre

Re: Buildbot numbers for week of 11/22/2015 - 11/28/2015

[David Blaikie via cfe-commits]

On Mon, Nov 30, 2015 at 5:00 PM, Galina Kistanova 
wrote:

> Hi David,
>
> Thank you for the useful suggestions, I will work on these.
>
> >I guess the entries with no entry in the failed column have zero failures?
> Yes.
>
>  perf-x86_64-penryn-O3-polly-before-vectorizer |
> 31 | 31 |
>  perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only |
> 31 | 27 | 05:28:12
>
> These /\ two builders failed most of the time, but they also only ran a
> handful of times. I guess they're triggering off polly changes only? I
> wonder if they should trigger off LLVM changes too, but I'm not sure.
>
> They build on llvm changes also, but they both build for quite a long
> time. I think it's the reason why they do not build more.
>

Ah, OK - so the other suggestions might help demonstrate/understand that
behavior better.

Tobias - any idea why these builders are /quite/ so slow & whether they
could be improved? With large blame lists that come from a small number of
slaves on a slow builder task it makes them hard to action. Are they useful
to you?

- Dave


>
> Thanks
>
> Galina
>
>
>
>
> On Mon, Nov 30, 2015 at 4:28 PM, David Blaikie  wrote:
>
>> Thanks for tracking these results, Galina
>>
>> I think it might be better to send these to the -dev lists, rather than
>> the -commits lists, but I'm not sure what other people think on that.
>>
>> On Mon, Nov 30, 2015 at 4:17 PM, Galina Kistanova via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Hello everyone,
>>>
>>> Below are some buildbot numbers for the last week of 11/22/2015 -
>>> 11/28/2015.
>>>
>>> Thanks
>>>
>>> Galina
>>>
>>>
>>>
>>> Top 10 fastest builders(not docs):
>>>
>>>  lldb-amd64-ninja-freebsd11
>>>  clang-bpf-build
>>>  llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast
>>>  libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03
>>>  sanitizer-windows
>>>  libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11
>>>  libcxx-libcxxabi-x86_64-linux-ubuntu-cxx1z
>>>  libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14
>>>  libcxx-libcxxabi-x86_64-linux-ubuntu-unstable-abi
>>>  llvm-hexagon-elf
>>>
>>>
>>>
>>>  10 most slow builders:
>>>
>>>  clang-native-arm-lnt-perf
>>>  clang-native-aarch64-full
>>>  clang-atom-d525-fedora
>>>  clang-cmake-thumbv7-a15-full-sh
>>>  perf-x86_64-penryn-O3
>>>  perf-x86_64-penryn-O3-polly
>>>  perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only
>>>  clang-cmake-armv7-a15-selfhost-neon
>>>  llvm-mips-linux
>>>  sanitizer-x86_64-linux-bootstrap
>>>
>>>
>>>
>>> Number of commits by project:
>>>
>>>  project   |   commits
>>> ---
>>>  llvm  |   218
>>>  cfe   |67
>>>  compiler-rt   |33
>>>  lld   |30
>>>  lldb  |23
>>>  polly | 8
>>>  clang-tools-extra | 7
>>>  libcxx| 4
>>>  llgo  | 1
>>> ---
>>>391
>>>
>>>
>>> Number of completed builds, failed builds and average build time for
>>> successful builds per active builder:
>>>
>>
>> Maybe we could sort this \/ list by some ratio of failed/completed?
>>
>> I guess the entries with no entry in the failed column have zero failures?
>>
>>
>>>
>>>  buildername   | completed
>>> | failed | time
>>>
>>> -
>>>  clang-aarch64-lnt | 56
>>> |  3 | 02:31:36
>>>  clang-atom-d525-fedora| 21
>>> |  5 | 08:06:27
>>>  clang-atom-d525-fedora-rel| 80
>>> | 12 | 01:31:08
>>>  clang-bpf-build   |239
>>> | 47 | 00:02:59
>>>  clang-cmake-aarch64-42vma |214
>>> | 80 | 00:16:33
>>>  clang-cmake-aarch64-full  |  1
>>> || 03:17:48
>>>  clang-cmake-aarch64-quick |178
>>> | 64 | 00:22:56
>>>  clang-cmake-armv7-a15 |170
>>> |  9 | 00:27:14
>>>  clang-cmake-armv7-a15-full|135
>>> | 31 | 00:47:54
>>>  clang-cmake-armv7-a15-selfhost| 41
>>> | 17 | 04:13:48
>>>  clang-cmake-armv7-a15-selfhost-neon   | 38
>>> | 18 | 05:04:39
>>>  clang-cmake-mips  |158
>>> | 50 | 00:27:47
>>>  clang-cmake-thumbv7-a15   |157
>>> | 22 | 00:27:57
>>>  clang-cmake-thumbv7-a15-full-sh

Re: Buildbot numbers for week of 11/22/2015 - 11/28/2015

[Galina Kistanova via cfe-commits]

Hi David,

Thank you for the useful suggestions, I will work on these.

>I guess the entries with no entry in the failed column have zero failures?
Yes.

 perf-x86_64-penryn-O3-polly-before-vectorizer | 31
| 31 |
 perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only | 31
| 27 | 05:28:12

These /\ two builders failed most of the time, but they also only ran a
handful of times. I guess they're triggering off polly changes only? I
wonder if they should trigger off LLVM changes too, but I'm not sure.

They build on llvm changes also, but they both build for quite a long time.
I think it's the reason why they do not build more.

Thanks

Galina




On Mon, Nov 30, 2015 at 4:28 PM, David Blaikie  wrote:

> Thanks for tracking these results, Galina
>
> I think it might be better to send these to the -dev lists, rather than
> the -commits lists, but I'm not sure what other people think on that.
>
> On Mon, Nov 30, 2015 at 4:17 PM, Galina Kistanova via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Hello everyone,
>>
>> Below are some buildbot numbers for the last week of 11/22/2015 -
>> 11/28/2015.
>>
>> Thanks
>>
>> Galina
>>
>>
>>
>> Top 10 fastest builders(not docs):
>>
>>  lldb-amd64-ninja-freebsd11
>>  clang-bpf-build
>>  llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast
>>  libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03
>>  sanitizer-windows
>>  libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11
>>  libcxx-libcxxabi-x86_64-linux-ubuntu-cxx1z
>>  libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14
>>  libcxx-libcxxabi-x86_64-linux-ubuntu-unstable-abi
>>  llvm-hexagon-elf
>>
>>
>>
>>  10 most slow builders:
>>
>>  clang-native-arm-lnt-perf
>>  clang-native-aarch64-full
>>  clang-atom-d525-fedora
>>  clang-cmake-thumbv7-a15-full-sh
>>  perf-x86_64-penryn-O3
>>  perf-x86_64-penryn-O3-polly
>>  perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only
>>  clang-cmake-armv7-a15-selfhost-neon
>>  llvm-mips-linux
>>  sanitizer-x86_64-linux-bootstrap
>>
>>
>>
>> Number of commits by project:
>>
>>  project   |   commits
>> ---
>>  llvm  |   218
>>  cfe   |67
>>  compiler-rt   |33
>>  lld   |30
>>  lldb  |23
>>  polly | 8
>>  clang-tools-extra | 7
>>  libcxx| 4
>>  llgo  | 1
>> ---
>>391
>>
>>
>> Number of completed builds, failed builds and average build time for
>> successful builds per active builder:
>>
>
> Maybe we could sort this \/ list by some ratio of failed/completed?
>
> I guess the entries with no entry in the failed column have zero failures?
>
>
>>
>>  buildername   | completed  |
>> failed | time
>>
>> -
>>  clang-aarch64-lnt | 56
>> |  3 | 02:31:36
>>  clang-atom-d525-fedora| 21
>> |  5 | 08:06:27
>>  clang-atom-d525-fedora-rel| 80
>> | 12 | 01:31:08
>>  clang-bpf-build   |239
>> | 47 | 00:02:59
>>  clang-cmake-aarch64-42vma |214
>> | 80 | 00:16:33
>>  clang-cmake-aarch64-full  |  1
>> || 03:17:48
>>  clang-cmake-aarch64-quick |178
>> | 64 | 00:22:56
>>  clang-cmake-armv7-a15 |170
>> |  9 | 00:27:14
>>  clang-cmake-armv7-a15-full|135
>> | 31 | 00:47:54
>>  clang-cmake-armv7-a15-selfhost| 41
>> | 17 | 04:13:48
>>  clang-cmake-armv7-a15-selfhost-neon   | 38
>> | 18 | 05:04:39
>>  clang-cmake-mips  |158
>> | 50 | 00:27:47
>>  clang-cmake-thumbv7-a15   |157
>> | 22 | 00:27:57
>>  clang-cmake-thumbv7-a15-full-sh   | 28
>> | 12 | 06:13:18
>>  clang-hexagon-elf |139
>> | 12 | 00:16:00
>>  clang-native-aarch64-full | 16
>> |  5 | 08:14:29
>>  clang-native-arm-lnt  |107
>> | 17 | 01:08:19
>>  clang-native-arm-lnt-perf | 25
>> | 11 | 08:40:48
>>  clang-ppc64-elf-linux |11

[PATCH] D15097: [Sema] Issue a warning for integer overflow in struct initializer

[Akira Hatanaka via cfe-commits]

ahatanak created this revision.
ahatanak added a subscriber: cfe-commits.

Issue a warning if an initializing integer expression overflows.

For example, clang should issue a warning when compiling the following code 
because 4 * 1024 * 1024 * 1024 doesn't fit into a 32-bit integer:

struct s {
unsigned x;
} s = {
 .x = 4 * 1024 * 1024 * 1024
};

http://reviews.llvm.org/D15097

Files:
  lib/Sema/SemaChecking.cpp
  test/Sema/integer-overflow.c

Index: test/Sema/integer-overflow.c
===
--- test/Sema/integer-overflow.c
+++ test/Sema/integer-overflow.c
@@ -145,3 +145,11 @@
 // expected-warning@+1 2{{overflow in expression; result is 536870912 with 
type 'int'}}
   return ((4608 * 1024 * 1024) + ((uint64_t)(4608 * 1024 * 1024)));
 }
+
+struct s {
+  unsigned x;
+  unsigned y;
+} s = {
+  .y = 5,
+  .x = 4 * 1024 * 1024 * 1024  // expected-warning {{overflow in expression; 
result is 0 with type 'int'}}
+};
Index: lib/Sema/SemaChecking.cpp
===
--- lib/Sema/SemaChecking.cpp
+++ lib/Sema/SemaChecking.cpp
@@ -7817,6 +7817,10 @@
 void Sema::CheckForIntOverflow (Expr *E) {
   if (isa(E->IgnoreParenCasts()))
 E->IgnoreParenCasts()->EvaluateForOverflow(Context);
+  else if (auto InitList = dyn_cast(E))
+for (Expr *E : InitList->inits())
+  if (isa(E->IgnoreParenCasts()))
+E->IgnoreParenCasts()->EvaluateForOverflow(Context);
 }
 
 namespace {


Index: test/Sema/integer-overflow.c
===
--- test/Sema/integer-overflow.c
+++ test/Sema/integer-overflow.c
@@ -145,3 +145,11 @@
 // expected-warning@+1 2{{overflow in expression; result is 536870912 with type 'int'}}
   return ((4608 * 1024 * 1024) + ((uint64_t)(4608 * 1024 * 1024)));
 }
+
+struct s {
+  unsigned x;
+  unsigned y;
+} s = {
+  .y = 5,
+  .x = 4 * 1024 * 1024 * 1024  // expected-warning {{overflow in expression; result is 0 with type 'int'}}
+};
Index: lib/Sema/SemaChecking.cpp
===
--- lib/Sema/SemaChecking.cpp
+++ lib/Sema/SemaChecking.cpp
@@ -7817,6 +7817,10 @@
 void Sema::CheckForIntOverflow (Expr *E) {
   if (isa(E->IgnoreParenCasts()))
 E->IgnoreParenCasts()->EvaluateForOverflow(Context);
+  else if (auto InitList = dyn_cast(E))
+for (Expr *E : InitList->inits())
+  if (isa(E->IgnoreParenCasts()))
+E->IgnoreParenCasts()->EvaluateForOverflow(Context);
 }
 
 namespace {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Buildbot numbers for week of 11/22/2015 - 11/28/2015

[David Blaikie via cfe-commits]

Thanks for tracking these results, Galina

I think it might be better to send these to the -dev lists, rather than the
-commits lists, but I'm not sure what other people think on that.

On Mon, Nov 30, 2015 at 4:17 PM, Galina Kistanova via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Hello everyone,
>
> Below are some buildbot numbers for the last week of 11/22/2015 -
> 11/28/2015.
>
> Thanks
>
> Galina
>
>
>
> Top 10 fastest builders(not docs):
>
>  lldb-amd64-ninja-freebsd11
>  clang-bpf-build
>  llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast
>  libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03
>  sanitizer-windows
>  libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11
>  libcxx-libcxxabi-x86_64-linux-ubuntu-cxx1z
>  libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14
>  libcxx-libcxxabi-x86_64-linux-ubuntu-unstable-abi
>  llvm-hexagon-elf
>
>
>
>  10 most slow builders:
>
>  clang-native-arm-lnt-perf
>  clang-native-aarch64-full
>  clang-atom-d525-fedora
>  clang-cmake-thumbv7-a15-full-sh
>  perf-x86_64-penryn-O3
>  perf-x86_64-penryn-O3-polly
>  perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only
>  clang-cmake-armv7-a15-selfhost-neon
>  llvm-mips-linux
>  sanitizer-x86_64-linux-bootstrap
>
>
>
> Number of commits by project:
>
>  project   |   commits
> ---
>  llvm  |   218
>  cfe   |67
>  compiler-rt   |33
>  lld   |30
>  lldb  |23
>  polly | 8
>  clang-tools-extra | 7
>  libcxx| 4
>  llgo  | 1
> ---
>391
>
>
> Number of completed builds, failed builds and average build time for
> successful builds per active builder:
>

Maybe we could sort this \/ list by some ratio of failed/completed?

I guess the entries with no entry in the failed column have zero failures?


>
>  buildername   | completed  |
> failed | time
>
> -
>  clang-aarch64-lnt | 56
> |  3 | 02:31:36
>  clang-atom-d525-fedora| 21
> |  5 | 08:06:27
>  clang-atom-d525-fedora-rel| 80
> | 12 | 01:31:08
>  clang-bpf-build   |239
> | 47 | 00:02:59
>  clang-cmake-aarch64-42vma |214
> | 80 | 00:16:33
>  clang-cmake-aarch64-full  |  1
> || 03:17:48
>  clang-cmake-aarch64-quick |178
> | 64 | 00:22:56
>  clang-cmake-armv7-a15 |170
> |  9 | 00:27:14
>  clang-cmake-armv7-a15-full|135
> | 31 | 00:47:54
>  clang-cmake-armv7-a15-selfhost| 41
> | 17 | 04:13:48
>  clang-cmake-armv7-a15-selfhost-neon   | 38
> | 18 | 05:04:39
>  clang-cmake-mips  |158
> | 50 | 00:27:47
>  clang-cmake-thumbv7-a15   |157
> | 22 | 00:27:57
>  clang-cmake-thumbv7-a15-full-sh   | 28
> | 12 | 06:13:18
>  clang-hexagon-elf |139
> | 12 | 00:16:00
>  clang-native-aarch64-full | 16
> |  5 | 08:14:29
>  clang-native-arm-lnt  |107
> | 17 | 01:08:19
>  clang-native-arm-lnt-perf | 25
> | 11 | 08:40:48
>  clang-ppc64-elf-linux |110
> |  3 | 01:01:45
>  clang-ppc64-elf-linux2| 83
> | 14 | 01:31:11
>  clang-sphinx-docs |111
> || 00:00:20
>  clang-x64-ninja-win7  |158
> | 28 | 00:34:54
>  clang-x86-win2008-selfhost|110
> | 17 | 01:02:17
>  clang-x86_64-darwin13-cross-arm   |197
> |  5 | 00:19:48
>  clang-x86_64-darwin13-cross-mingw32   |184
> |  5 | 00:23:16
>  clang-x86_64-debian-fast  |137
> | 24 | 00:10:32
>  clang-x86_64-linux-abi-test   |243
> |  3 | 00:18:45
>  clang-x86_64-linux-selfhost-modules  

Buildbot numbers for week of 11/22/2015 - 11/28/2015

[Galina Kistanova via cfe-commits]

Hello everyone,

Below are some buildbot numbers for the last week of 11/22/2015 -
11/28/2015.

Thanks

Galina



Top 10 fastest builders(not docs):

 lldb-amd64-ninja-freebsd11
 clang-bpf-build
 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03
 sanitizer-windows
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx1z
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14
 libcxx-libcxxabi-x86_64-linux-ubuntu-unstable-abi
 llvm-hexagon-elf



 10 most slow builders:

 clang-native-arm-lnt-perf
 clang-native-aarch64-full
 clang-atom-d525-fedora
 clang-cmake-thumbv7-a15-full-sh
 perf-x86_64-penryn-O3
 perf-x86_64-penryn-O3-polly
 perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only
 clang-cmake-armv7-a15-selfhost-neon
 llvm-mips-linux
 sanitizer-x86_64-linux-bootstrap



Number of commits by project:

 project   |   commits
---
 llvm  |   218
 cfe   |67
 compiler-rt   |33
 lld   |30
 lldb  |23
 polly | 8
 clang-tools-extra | 7
 libcxx| 4
 llgo  | 1
---
   391


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

 buildername   | completed  |
failed | time
-
 clang-aarch64-lnt | 56
|  3 | 02:31:36
 clang-atom-d525-fedora| 21
|  5 | 08:06:27
 clang-atom-d525-fedora-rel| 80
| 12 | 01:31:08
 clang-bpf-build   |239
| 47 | 00:02:59
 clang-cmake-aarch64-42vma |214
| 80 | 00:16:33
 clang-cmake-aarch64-full  |  1
|| 03:17:48
 clang-cmake-aarch64-quick |178
| 64 | 00:22:56
 clang-cmake-armv7-a15 |170
|  9 | 00:27:14
 clang-cmake-armv7-a15-full|135
| 31 | 00:47:54
 clang-cmake-armv7-a15-selfhost| 41
| 17 | 04:13:48
 clang-cmake-armv7-a15-selfhost-neon   | 38
| 18 | 05:04:39
 clang-cmake-mips  |158
| 50 | 00:27:47
 clang-cmake-thumbv7-a15   |157
| 22 | 00:27:57
 clang-cmake-thumbv7-a15-full-sh   | 28
| 12 | 06:13:18
 clang-hexagon-elf |139
| 12 | 00:16:00
 clang-native-aarch64-full | 16
|  5 | 08:14:29
 clang-native-arm-lnt  |107
| 17 | 01:08:19
 clang-native-arm-lnt-perf | 25
| 11 | 08:40:48
 clang-ppc64-elf-linux |110
|  3 | 01:01:45
 clang-ppc64-elf-linux2| 83
| 14 | 01:31:11
 clang-sphinx-docs |111
|| 00:00:20
 clang-x64-ninja-win7  |158
| 28 | 00:34:54
 clang-x86-win2008-selfhost|110
| 17 | 01:02:17
 clang-x86_64-darwin13-cross-arm   |197
|  5 | 00:19:48
 clang-x86_64-darwin13-cross-mingw32   |184
|  5 | 00:23:16
 clang-x86_64-debian-fast  |137
| 24 | 00:10:32
 clang-x86_64-linux-abi-test   |243
|  3 | 00:18:45
 clang-x86_64-linux-selfhost-modules   |212
| 45 | 00:15:08
 clang-x86_64-ubuntu-gdb-75|131
| 45 | 00:49:38
 libcxx-libcxxabi-arm-linux|  4
|| 01:09:42
 libcxx-libcxxabi-singlethreaded-x86_64-linux-debian   |  4
|| 00:08:08
 libcxx-libcxxabi-x86_64-linux-debian  |  4
|| 00:08:33
 libcxx-libcxxabi-x86_64-linux-debian-noexceptions |  4
|| 00:08:03
 libcxx-libcxxabi-x86_64-linux-ubuntu-asan |  4
|| 00:08:25
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03

Re: [PATCH] D14824: [PATCH] Add clang-tidy check for static or thread_local objects where construction may throw

[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/utils/Matchers.h:26
@@ -25,1 +25,3 @@
 
+AST_MATCHER(FunctionDecl, isNoThrow) {
+  const auto *FnTy = Node.getType()->getAs();

Anything wrong with putting this to the astmatchers library?


http://reviews.llvm.org/D14824



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

[PATCH] D15095: Accept "-Weverything" in pragma clang diagnostic ...

[Sunil Srivastava via cfe-commits]

Sunil_Srivastava created this revision.
Sunil_Srivastava added a subscriber: cfe-commits.

Special handling for “-Weverything” in ‘pragma clang diagnostic handling’
There is no formal diagnostic group named “everything”, so this code is needed.


http://reviews.llvm.org/D15095

Files:
  lib/Basic/Diagnostic.cpp
  test/Frontend/Peverything.cpp

Index: test/Frontend/Peverything.cpp
===
--- test/Frontend/Peverything.cpp
+++ test/Frontend/Peverything.cpp
@@ -0,0 +1,6 @@
+// RUN: %clang_cc1 %s -fsyntax-only -verify
+#pragma clang diagnostic error "-Weverything" 
+
+void ppp() // expected-error {{no previous prototype for function 'ppp'}}
+{
+}
Index: lib/Basic/Diagnostic.cpp
===
--- lib/Basic/Diagnostic.cpp
+++ lib/Basic/Diagnostic.cpp
@@ -248,6 +248,13 @@
 bool DiagnosticsEngine::setSeverityForGroup(diag::Flavor Flavor,
 StringRef Group, diag::Severity 
Map,
 SourceLocation Loc) {
+  // Special handling for pragma clang diagnostic ... "-Weverything"
+  // There is no formal group named "everything", so there has to be a special
+  // case for it.
+  if (Group == "everything") {
+   setSeverityForAll(Flavor, Map, Loc);
+   return false;
+  }
   // Get the diagnostics in this group.
   SmallVector GroupDiags;
   if (Diags->getDiagnosticsInGroup(Flavor, Group, GroupDiags))


Index: test/Frontend/Peverything.cpp
===
--- test/Frontend/Peverything.cpp
+++ test/Frontend/Peverything.cpp
@@ -0,0 +1,6 @@
+// RUN: %clang_cc1 %s -fsyntax-only -verify
+#pragma clang diagnostic error "-Weverything" 
+
+void ppp() // expected-error {{no previous prototype for function 'ppp'}}
+{
+}
Index: lib/Basic/Diagnostic.cpp
===
--- lib/Basic/Diagnostic.cpp
+++ lib/Basic/Diagnostic.cpp
@@ -248,6 +248,13 @@
 bool DiagnosticsEngine::setSeverityForGroup(diag::Flavor Flavor,
 StringRef Group, diag::Severity Map,
 SourceLocation Loc) {
+  // Special handling for pragma clang diagnostic ... "-Weverything"
+  // There is no formal group named "everything", so there has to be a special
+  // case for it.
+  if (Group == "everything") {
+   setSeverityForAll(Flavor, Map, Loc);
+   return false;
+  }
   // Get the diagnostics in this group.
   SmallVector GroupDiags;
   if (Diags->getDiagnosticsInGroup(Flavor, Group, GroupDiags))
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r254323 - [MS Compat] Adjust thiscall to cdecl when deducing template arguments

[NAKAMURA Takumi via cfe-commits]

You forgot to update test/CXX/drs/dr5xx.cpp. Updated in r254346.

On Tue, Dec 1, 2015 at 5:37 AM David Majnemer via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: majnemer
> Date: Mon Nov 30 14:34:28 2015
> New Revision: 254323
>
> URL: http://llvm.org/viewvc/llvm-project?rev=254323&view=rev
> Log:
> [MS Compat] Adjust thiscall to cdecl when deducing template arguments
>
> Function types can be extracted from member pointer types.
> However, the type is not appropriate without first adjusting the calling
> convention.
>
> This fixes PR25661.
>
> Modified:
> cfe/trunk/lib/Sema/SemaTemplateDeduction.cpp
> cfe/trunk/test/SemaCXX/calling-conv-compat.cpp
>
> Modified: cfe/trunk/lib/Sema/SemaTemplateDeduction.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaTemplateDeduction.cpp?rev=254323&r1=254322&r2=254323&view=diff
>
> ==
> --- cfe/trunk/lib/Sema/SemaTemplateDeduction.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaTemplateDeduction.cpp Mon Nov 30 14:34:28 2015
> @@ -1517,10 +1517,19 @@ DeduceTemplateArgumentsByTypeMatch(Sema
>if (!MemPtrArg)
>  return Sema::TDK_NonDeducedMismatch;
>
> +  QualType ParamPointeeType = MemPtrParam->getPointeeType();
> +  if (ParamPointeeType->isFunctionType())
> +S.adjustMemberFunctionCC(ParamPointeeType, /*IsStatic=*/true,
> + /*IsCtorOrDtor=*/false,
> Info.getLocation());
> +  QualType ArgPointeeType = MemPtrArg->getPointeeType();
> +  if (ArgPointeeType->isFunctionType())
> +S.adjustMemberFunctionCC(ArgPointeeType, /*IsStatic=*/true,
> + /*IsCtorOrDtor=*/false,
> Info.getLocation());
> +
>if (Sema::TemplateDeductionResult Result
>  = DeduceTemplateArgumentsByTypeMatch(S, TemplateParams,
> -
>  MemPtrParam->getPointeeType(),
> -
>  MemPtrArg->getPointeeType(),
> + ParamPointeeType,
> + ArgPointeeType,
>   Info, Deduced,
>   TDF &
> TDF_IgnoreQualifiers))
>  return Result;
>
> Modified: cfe/trunk/test/SemaCXX/calling-conv-compat.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/calling-conv-compat.cpp?rev=254323&r1=254322&r2=254323&view=diff
>
> ==
> --- cfe/trunk/test/SemaCXX/calling-conv-compat.cpp (original)
> +++ cfe/trunk/test/SemaCXX/calling-conv-compat.cpp Mon Nov 30 14:34:28 2015
> @@ -370,6 +370,19 @@ X::p tmpl6 = &A::method_th
>  X::p tmpl7 = &A::method_stdcall;
>  X::p tmpl8 = &A::method_fastcall;
>
> +// Make sure we adjust thiscall to cdecl when extracting the function
> type from
> +// a member pointer.
> +template  struct Y;
> +
> +template 
> +struct Y {
> +  typedef Fn *p;
> +};
> +
> +void __cdecl f_cdecl();
> +Y::p tmpl9 = &f_cdecl;
> +
> +
>  } // end namespace MemberPointers
>
>  // Test that lambdas that capture nothing convert to cdecl function
> pointers.
>
>
> ___
> 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

r254346 - [PR25661] Revert part of r217213 according to r254323.

[NAKAMURA Takumi via cfe-commits]

Author: chapuni
Date: Mon Nov 30 17:46:32 2015
New Revision: 254346

URL: http://llvm.org/viewvc/llvm-project?rev=254346&view=rev
Log:
[PR25661] Revert part of r217213 according to r254323.

Modified:
cfe/trunk/test/CXX/drs/dr5xx.cpp

Modified: cfe/trunk/test/CXX/drs/dr5xx.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CXX/drs/dr5xx.cpp?rev=254346&r1=254345&r2=254346&view=diff
==
--- cfe/trunk/test/CXX/drs/dr5xx.cpp (original)
+++ cfe/trunk/test/CXX/drs/dr5xx.cpp Mon Nov 30 17:46:32 2015
@@ -519,23 +519,12 @@ namespace dr546 { // dr546: yes
 }
 
 namespace dr547 { // dr547: yes
-  // When targeting the MS x86 ABI, the type of a member function includes a
-  // __thiscall qualifier. This is non-conforming, but we still implement
-  // the intent of dr547
-#if defined(_M_IX86) || (defined(__MINGW32__) && !defined(__MINGW64__))
-#define THISCALL __thiscall
-#else
-#define THISCALL
-#endif
-
   template struct X;
-  template struct X {};
+  template struct X {};
   template X f(T C::*) { return X(); }
 
   struct S { void f() const; };
-  X x = f(&S::f);
-
-#undef THISCALL
+  X x = f(&S::f);
 }
 
 namespace dr548 { // dr548: dup 482


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

Re: [PATCH] D13357: [Concepts] Diagnose when 'concept' is specified on a specialization

[Nathan Wilson via cfe-commits]

nwilson updated this revision to Diff 41441.
nwilson added a comment.

Updating to r254337


http://reviews.llvm.org/D13357

Files:
  include/clang/AST/Decl.h
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaTemplate.cpp
  test/CXX/concepts-ts/dcl.dcl/dcl.spec/dcl.spec.concept/p1.cpp

Index: test/CXX/concepts-ts/dcl.dcl/dcl.spec/dcl.spec.concept/p1.cpp
===
--- test/CXX/concepts-ts/dcl.dcl/dcl.spec/dcl.spec.concept/p1.cpp
+++ test/CXX/concepts-ts/dcl.dcl/dcl.spec/dcl.spec.concept/p1.cpp
@@ -41,3 +41,20 @@
 void fpc(concept int i) {} // expected-error {{'concept' can only appear on the definition of a function template or variable template}}
 
 concept bool; // expected-error {{'concept' can only appear on the definition of a function template or variable template}}
+
+template concept bool VCEI { true };
+template concept bool VCEI; // expected-error {{'concept' cannot be applied on an explicit instantiation}}
+extern template concept bool VCEI; // expected-error {{'concept' cannot be applied on an explicit instantiation}}
+
+template concept bool VCPS { true };
+template concept bool VCPS { true }; // expected-error {{'concept' cannot be applied on an partial specialization}}
+
+template concept bool VCES { true };
+template<> concept bool VCES { true }; // expected-error {{'concept' cannot be applied on an explicit specialization}}
+
+template concept bool FCEI() { return true; }
+template concept bool FCEI(); // expected-error {{'concept' cannot be applied on an explicit instantiation}}
+extern template concept bool FCEI(); // expected-error {{'concept' cannot be applied on an explicit instantiation}}
+
+template concept bool FCES() { return true; }
+template<> concept bool FCES() { return true; } // expected-error {{'concept' cannot be applied on an explicit specialization}}
Index: lib/Sema/SemaTemplate.cpp
===
--- lib/Sema/SemaTemplate.cpp
+++ lib/Sema/SemaTemplate.cpp
@@ -7665,6 +7665,17 @@
 Diag(D.getDeclSpec().getConstexprSpecLoc(),
  diag::err_explicit_instantiation_constexpr);
 
+  // C++ Concepts TS [dcl.spec.concept]p1: The concept specifier shall be
+  // applied only to the definition of a function template or variable template,
+  // declared in namespace scope. A concept definition refers to either a
+  // function concept and its definition or a variable concept and its
+  // initializer.
+  if (D.getDeclSpec().isConceptSpecified()) {
+Diag(D.getDeclSpec().getConceptSpecLoc(),
+ diag:: err_concept_specified_specialization) << 0;
+return true;
+  }
+
   // C++0x [temp.explicit]p2:
   //   There are two forms of explicit instantiation: an explicit instantiation
   //   definition and an explicit instantiation declaration. An explicit
Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -5943,6 +5943,16 @@
 << 0 << 3;
 NewVD->setInvalidDecl(true);
   }
+
+  // C++ Concepts TS [dcl.spec.concept]p1: The concept specifier shall be
+  // applied only to the definition of a [...] variable template, declared
+  // in namespace scope. [...] A concept definition refers to [...] a
+  // variable concept and its initializer.
+  if (IsVariableTemplateSpecialization) {
+Diag(D.getDeclSpec().getConceptSpecLoc(),
+ diag::err_concept_specified_specialization)
+  << (IsPartialSpecialization ? 2 : 1);
+  }
 }
   }
 
@@ -7600,6 +7610,9 @@
 }
 
 if (isConcept) {
+  // This is a function concept.
+  NewFD->setConcept(true);
+
   // C++ Concepts TS [dcl.spec.concept]p1: The concept specifier shall be
   // applied only to the definition of a function template [...]
   if (!D.isFunctionDefinition()) {
@@ -7658,6 +7671,15 @@
 << 1 << 3;
 NewFD->setInvalidDecl(true);
   }
+
+  // C++ Concepts TS [dcl.spec.concept]p1: The concept specifier shall be
+  // applied only to the definition of a function template [...], declared
+  // in namespace scope. [...] A concept definition refers to either a
+  // function concept and its definition [...].
+  if (isFunctionTemplateSpecialization) {
+Diag(D.getDeclSpec().getConceptSpecLoc(),
+ diag::err_concept_specified_specialization) << 1;
+  }
 }
 
 // If __module_private__ was specified, mark the function accordingly.
@@ -7919,9 +7941,9 @@
  TemplateId->NumArgs);
   translateTemplateArguments(TemplateArgsPtr,
  TemplateArgs);
-
+
   HasExplicitTemplateArgs = true;
-
+
   if (NewFD->isInvalidDecl()) {
 HasExplicitTemplateArgs = false;
   } else if (FunctionTemplate) {
Index: include/clang/Basic/DiagnosticSemaKind

Re: [PATCH] D13357: [Concepts] Diagnose when 'concept' is specified on a specialization

[Nathan Wilson via cfe-commits]

nwilson added inline comments.


Comment at: lib/Sema/SemaDecl.cpp:7659
@@ +7658,3 @@
+Diag(D.getDeclSpec().getConceptSpecLoc(),
+ diag::err_concept_specified_specialization) << 1;
+  }

rsmith wrote:
> hubert.reinterpretcast wrote:
> > nwilson wrote:
> > > hubert.reinterpretcast wrote:
> > > > I don't think the declaration should still be marked as a concept in 
> > > > this case.
> > > Hmm, Richard - did you have any thoughts about this? IIRC, we might be 
> > > okay here by only looking at the concept flag of the primary template.
> > A consideration:
> > When processing the body associated with the specialization, should the 
> > requirements for a function concept body be checked?
> I think the `concept` flag logically belongs on the template declaration 
> rather than on the templated declaration; moving it there would make this 
> question irrelevant =)
Sorry for the slow reply.

Okay. That makes sense. So, we'd be okay putting the IsConcept bit (and the 
associated member functions) in TemplateDecl then?

You'd be okay with the extra byte used?


http://reviews.llvm.org/D13357



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

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

[Richard Smith via cfe-commits]

On Mon, Nov 30, 2015 at 11:33 AM, John McCall  wrote:

> rjmccall added a comment.
>
> In http://reviews.llvm.org/D14980#298754, @rsmith wrote:
>
> > GCC's behavior (`aligned` on a field specifies the alignment of the
> start of that field) makes a little more sense to me than Clang's behavior
> (the type and alignment of a field specify a flavour of storage unit, and
> the field goes in the next such storage unit that it fits into), but both
> seem defensible.
>
>
> Are you saying that `aligned` on a bit-field always starts new storage on
> GCC?


Not exactly. For instance, given

struct X {
  __attribute__((aligned(1))) char a : 2, b : 2, c : 2, d : 2;
} x = {0, 1, 2, 3};

... GCC produces

x:
.byte   0
.byte   1
.byte   2
.byte   3

The result is the same for any other bit-field type (except that we get
tail padding for types wider than 4 bytes), and in particular, we don't
allocate a new storage unit for 'b' and 'd' when the type is 'short'; we
just insert padding to get to a 1-byte-aligned boundary.

The rule that a bit-field can't straddle a naturally-aligned storage unit
for the underlying type still applies (for non-packed structs). For
instance,

struct Y {
  char : 1;
  __attribute__((aligned(1))) int n : 24;
} y = { 0x010203 };

struct Z {
  char : 1;
  __attribute__((aligned(1))) int n : 25;
} z = { 0x010203 };

gives:

y:
.zero   1
.byte   3
.byte   2
.byte   1
z:
.zero   4
.byte   3
.byte   2
.byte   1
.byte   0

... and if the structs are packed, y is unchanged and z changes to this:

z:
.zero   1
.byte   3
.byte   2
.byte   1
.byte   0
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r254337 - [libFuzzer] clarify the limitation of fsanitize-coverage=trace-cmp

[Kostya Serebryany via cfe-commits]

Author: kcc
Date: Mon Nov 30 16:17:19 2015
New Revision: 254337

URL: http://llvm.org/viewvc/llvm-project?rev=254337&view=rev
Log:
[libFuzzer] clarify the limitation of fsanitize-coverage=trace-cmp

Modified:
cfe/trunk/docs/SanitizerCoverage.rst

Modified: cfe/trunk/docs/SanitizerCoverage.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SanitizerCoverage.rst?rev=254337&r1=254336&r2=254337&view=diff
==
--- cfe/trunk/docs/SanitizerCoverage.rst (original)
+++ cfe/trunk/docs/SanitizerCoverage.rst Mon Nov 30 16:17:19 2015
@@ -275,6 +275,7 @@ they will be called by the instrumented
   void __sanitizer_cov_trace_switch(uint64_t Val, uint64_t *Cases);
 
 This interface is a subject to change.
+The current implementation is not thread-safe and thus can be safely used only 
for single-threaded targets.
 
 Output directory
 


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

Re: [PATCH] D14731: [libcxx] Add clang thread safety annotations to mutex and lock_guard

[Marshall Clow via cfe-commits]

mclow.lists added a comment.

>   We usually state things in the negative, so the controlling macro should be 
> _LIBCPP_HAS_NO_THREAD_ANNOTATION


Or actually, `_LIBCPP_HAS_NO_THREAD_ANNOTATIONS`


http://reviews.llvm.org/D14731



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

Re: [PATCH] D14731: [libcxx] Add clang thread safety annotations to mutex and lock_guard

[Marshall Clow via cfe-commits]

mclow.lists added a comment.

In general, this looks fine. There are a few nits.

1. There needs to be a way to disable these annotations.

The usual way in libc++ is to check to see if `_LIBCPP_THREAD_ANNOTATION` is 
already defined, and if so, do not define it. We usually state things in the 
negative, so the controlling macro should be `_LIBCPP_HAS_NO_THREAD_ANNOTATION`

2. We need to support non-ToT versions of clang, so the test needs to be more 
nuanced than `#if defined(__clang__)`. See L432 of <__config> for an example 
there.

More as I see them


http://reviews.llvm.org/D14731



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

Re: [PATCH] D14871: [Power PC] fix calculating address of arguments on stack for variadic functions

[John McCall via cfe-commits]

rjmccall added a comment.

Thank you.  A few more style complaints; with those fixed, LGTM.



Comment at: lib/CodeGen/TargetInfo.cpp:166
@@ +165,3 @@
+// Dynamically round a pointer up to a multiple of the given alignment.
+static llvm::Value* emitRoundPointerUpToAlignment(CodeGenFunction &CGF,
+  llvm::Value *Ptr,

Minor code-style nitpick: please put the * next to the function name, not the 
type.


Comment at: lib/CodeGen/TargetInfo.cpp:216
@@ -208,1 +215,3 @@
+  else
+Addr = Address(Ptr, SlotSize); 
 

LLVM code style is to always leave the braces there.


Comment at: lib/CodeGen/TargetInfo.cpp:3087
@@ -3089,1 +3086,3 @@
+overflow_arg_area = emitRoundPointerUpToAlignment(CGF, overflow_arg_area,
+  Align);
 

Braces.


http://reviews.llvm.org/D14871



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

[PATCH] D15090: [Static Analyzer] New checker hook: checkInitialState

[Gábor Kozár via cfe-commits]

shdnx created this revision.
shdnx added reviewers: zaks.anna, jordan_rose.
shdnx added a subscriber: cfe-commits.

Adds a new analyzer hook:

```
ProgramStateRef checkInitialState(const EntryPointInfo& EPInfo) /* non-const */;
```

This allows checkers to act on entry points, set up their initial state (by 
returning a new state) or prevent the analyzer from continuing from this entry 
point (by returning nullptr). It also serves to balance the existing 
checkEndFunction() and checkEndAnalysis() hooks.

EntryPointInfo is currently a very simple class containing a const Decl* of the 
declaration being used as an entry point and a ProgramStateRef of the initial 
state. It can later be extended, if we want to add more information to it.

Original discussion: 
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20151123/143961.html 
and http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20151130/144002.html
Original-original discussion (very old, ~2 years ago, when the idea first came 
up): 
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20131216/095565.html

Artem Dergachev has commented that a similar hook allowing to add multiple 
transitions using a CheckerContext might be more favourable:

> At a glance, I wonder if it's worth it to provide a CheckerContext 
> inside this callback and then handle transitions properly (which would 
> allow the checker to split the program state at the very beginning of 
> the function). I cannot instantly think of a use-case (hmm, maybe 
> somebody would like to eagerly discriminate between a NULL and non-NULL 
> pointer argument of the function), but at the same time I don't see any 
> obvious problems with adding it, especially because it'd be hard to 
> change the API when the use-case appears.

That wasn't a use case I had in mind, but it might be a good idea. That would 
serve a more general function, and I'm thinking that its interface would look 
something like:

```
void checkEntryPoint(const Decl *D, CheckerContext &Context) const;
```

Other thoughts?

http://reviews.llvm.org/D15090

Files:
  include/clang/StaticAnalyzer/Core/Checker.h
  include/clang/StaticAnalyzer/Core/CheckerManager.h
  include/clang/StaticAnalyzer/Core/PathSensitive/EntryPointInfo.h
  lib/StaticAnalyzer/Core/CheckerManager.cpp
  lib/StaticAnalyzer/Core/CoreEngine.cpp
  lib/StaticAnalyzer/Core/ExprEngine.cpp

Index: lib/StaticAnalyzer/Core/ExprEngine.cpp
===
--- lib/StaticAnalyzer/Core/ExprEngine.cpp
+++ lib/StaticAnalyzer/Core/ExprEngine.cpp
@@ -176,7 +176,7 @@
 }
   }
 
-  return state;
+  return getCheckerManager().runCheckersForInitialState(D, state);
 }
 
 ProgramStateRef
Index: lib/StaticAnalyzer/Core/CoreEngine.cpp
===
--- lib/StaticAnalyzer/Core/CoreEngine.cpp
+++ lib/StaticAnalyzer/Core/CoreEngine.cpp
@@ -191,11 +191,21 @@
 // Set the current block counter to being empty.
 WList->setBlockCounter(BCounterFactory.GetEmptyCounter());
 
-if (!InitState)
-  // Generate the root.
-  generateNode(StartLoc, SubEng.getInitialState(L), nullptr);
-else
-  generateNode(StartLoc, InitState, nullptr);
+if (!InitState) {
+  InitState = SubEng.getInitialState(L);
+
+  // it's possible for a checker to return NULL state, in which case getInitialState()
+  // above will return NULL - this means that we don't want this code path checked;
+  // return early
+  // TODO: correct? (seems to work)
+  if (!InitState) {
+SubEng.processEndWorklist(hasWorkRemaining());
+return WList->hasWork();
+  }
+}
+
+// Generate the root.
+generateNode(StartLoc, InitState, nullptr);
   }
 
   // Check if we have a steps limit
Index: lib/StaticAnalyzer/Core/CheckerManager.cpp
===
--- lib/StaticAnalyzer/Core/CheckerManager.cpp
+++ lib/StaticAnalyzer/Core/CheckerManager.cpp
@@ -11,6 +11,7 @@
 //
 //===--===//
 
+#include "clang/StaticAnalyzer/Core/PathSensitive/EntryPointInfo.h"
 #include "clang/StaticAnalyzer/Core/CheckerManager.h"
 #include "clang/AST/DeclBase.h"
 #include "clang/Analysis/ProgramPoint.h"
@@ -36,7 +37,8 @@
  !DeadSymbolsCheckers.empty()   ||
  !RegionChangesCheckers.empty() ||
  !EvalAssumeCheckers.empty()||
- !EvalCallCheckers.empty();
+ !EvalCallCheckers.empty()   ||
+ !InitialStateCheckers.empty();
 }
 
 void CheckerManager::finishedCheckerRegistration() {
@@ -611,6 +613,18 @@
 I->second->printState(Out, State, NL, Sep);
 }
 
+ProgramStateRef
+CheckerManager::runCheckersForInitialState(const Decl *D, ProgramStateRef State) {
+  EntryPointInfo E

Re: [PATCH] D13015: [X86] Make f16c intrinsics accessible through emmintrin.h, per Intel docs

[Paul Robinson via cfe-commits]

probinson added a subscriber: probinson.
probinson added a comment.

Regarding _mm[256]_cvtps_ph and ...cvtph_ps, I can find an Intel doc that say 
the _mm_* functions are in emmintrin.h and the _mm256_* are in immintrin.h, so 
putting them all with emmintrin.h is not consistent with what Intel says.  I 
can find a Microsoft doc that say these are all available with immintrin.h (not 
emmintrin.h).  It looks like gcc puts them with immintrin.h also.

Can we move the #include of f16cintrin.h from emmintrin.h to immintrin.h?  It 
would be more compatible with everybody else, and equally inconsistent with 
Intel's doc AFAICT.


Repository:
  rL LLVM

http://reviews.llvm.org/D13015



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

Re: add null pointer check

[Mathieu Baudet via cfe-commits]

Awesome. Looking forward to the full fix :)
—
Mathieu

On Nov 30, 2015, at 12:48 PM, Gábor Horváth 
mailto:xazax@gmail.com>> wrote:

Hi!


Thank you for reporting this.
A more complete fix is available here: 
http://reviews.llvm.org/D14919

I recommend to use that one :)

Best Regards,
Gabor

On 30 November 2015 at 21:38, Mathieu Baudet 
mailto:mathieubau...@fb.com>> wrote:
Hello,

While running some private CSA checkers on a recent checkout of clang (dev), I 
found the following fix to be necessary to prevent a null pointer error in 
lib/StaticAnalyzer/Core/IssueHash.cpp

— Mathieu





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

Re: add null pointer check

[Gábor Horváth via cfe-commits]

Hi!


Thank you for reporting this.
A more complete fix is available here: http://reviews.llvm.org/D14919

I recommend to use that one :)

Best Regards,
Gabor

On 30 November 2015 at 21:38, Mathieu Baudet  wrote:

> Hello,
>
> While running some private CSA checkers on a recent checkout of clang
> (dev), I found the following fix to be necessary to prevent a null pointer
> error in lib/StaticAnalyzer/Core/IssueHash.cpp
>
> — Mathieu
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

add null pointer check

[Mathieu Baudet via cfe-commits]

Hello,

While running some private CSA checkers on a recent checkout of clang (dev), I 
found the following fix to be necessary to prevent a null pointer error in 
lib/StaticAnalyzer/Core/IssueHash.cpp

— Mathieu



diff --git a/lib/StaticAnalyzer/Core/IssueHash.cpp 
b/lib/StaticAnalyzer/Core/IssueHash.cpp
--- a/lib/StaticAnalyzer/Core/IssueHash.cpp
+++ b/lib/StaticAnalyzer/Core/IssueHash.cpp
@@ -128,6 +128,9 @@ static StringRef GetNthLineOfFile(llvm::MemoryBuffer 
*Buffer, int Line) {
 
 static std::string NormalizeLine(const SourceManager &SM, FullSourceLoc &L,
  const Decl *D) {
+  if (!D)
+return "";
+
   static StringRef Whitespaces = " \t\n";
 
   const LangOptions &Opts = D->getASTContext().getLangOpts();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r254323 - [MS Compat] Adjust thiscall to cdecl when deducing template arguments

[David Majnemer via cfe-commits]

Author: majnemer
Date: Mon Nov 30 14:34:28 2015
New Revision: 254323

URL: http://llvm.org/viewvc/llvm-project?rev=254323&view=rev
Log:
[MS Compat] Adjust thiscall to cdecl when deducing template arguments

Function types can be extracted from member pointer types.
However, the type is not appropriate without first adjusting the calling
convention.

This fixes PR25661.

Modified:
cfe/trunk/lib/Sema/SemaTemplateDeduction.cpp
cfe/trunk/test/SemaCXX/calling-conv-compat.cpp

Modified: cfe/trunk/lib/Sema/SemaTemplateDeduction.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaTemplateDeduction.cpp?rev=254323&r1=254322&r2=254323&view=diff
==
--- cfe/trunk/lib/Sema/SemaTemplateDeduction.cpp (original)
+++ cfe/trunk/lib/Sema/SemaTemplateDeduction.cpp Mon Nov 30 14:34:28 2015
@@ -1517,10 +1517,19 @@ DeduceTemplateArgumentsByTypeMatch(Sema
   if (!MemPtrArg)
 return Sema::TDK_NonDeducedMismatch;
 
+  QualType ParamPointeeType = MemPtrParam->getPointeeType();
+  if (ParamPointeeType->isFunctionType())
+S.adjustMemberFunctionCC(ParamPointeeType, /*IsStatic=*/true,
+ /*IsCtorOrDtor=*/false, Info.getLocation());
+  QualType ArgPointeeType = MemPtrArg->getPointeeType();
+  if (ArgPointeeType->isFunctionType())
+S.adjustMemberFunctionCC(ArgPointeeType, /*IsStatic=*/true,
+ /*IsCtorOrDtor=*/false, Info.getLocation());
+
   if (Sema::TemplateDeductionResult Result
 = DeduceTemplateArgumentsByTypeMatch(S, TemplateParams,
- MemPtrParam->getPointeeType(),
- MemPtrArg->getPointeeType(),
+ ParamPointeeType,
+ ArgPointeeType,
  Info, Deduced,
  TDF & TDF_IgnoreQualifiers))
 return Result;

Modified: cfe/trunk/test/SemaCXX/calling-conv-compat.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/calling-conv-compat.cpp?rev=254323&r1=254322&r2=254323&view=diff
==
--- cfe/trunk/test/SemaCXX/calling-conv-compat.cpp (original)
+++ cfe/trunk/test/SemaCXX/calling-conv-compat.cpp Mon Nov 30 14:34:28 2015
@@ -370,6 +370,19 @@ X::p tmpl6 = &A::method_th
 X::p tmpl7 = &A::method_stdcall;
 X::p tmpl8 = &A::method_fastcall;
 
+// Make sure we adjust thiscall to cdecl when extracting the function type from
+// a member pointer.
+template  struct Y;
+
+template 
+struct Y {
+  typedef Fn *p;
+};
+
+void __cdecl f_cdecl();
+Y::p tmpl9 = &f_cdecl;
+
+
 } // end namespace MemberPointers
 
 // Test that lambdas that capture nothing convert to cdecl function pointers.


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

Re: [PATCH] D13446: [PATCH] Add checker discouraging definition of variadic function definitions in C++

[Aaron Ballman via cfe-commits]

As a follow-up on this topic, I have proposed a patch in:
http://reviews.llvm.org/D15087

~Aaron

On Tue, Nov 3, 2015 at 1:05 PM, Aaron Ballman  wrote:
> On Tue, Nov 3, 2015 at 7:19 AM, Alexander Kornienko  wrote:
>> On Fri, Oct 9, 2015 at 12:13 PM, Aaron Ballman 
>> wrote:
>>>
>>> On Fri, Oct 9, 2015 at 3:09 PM, Daniel Berlin  wrote:
>>> > dberlin added a subscriber: dberlin.
>>> >
>>> > 
>>> > Comment at: docs/clang-tidy/checks/cert-variadic-function-def.rst:13
>>> > @@ +12,2 @@
>>> > +`DCL50-CPP. Do not define a C-style variadic function
>>> >
>>> > +`_.
>>> > 
>>> > I'm sure this is oversight on CERT's part, but their website actually
>>> > has terms of use (click the terms of use at the bottom of the page) that
>>> > says this can't be copied/reused, and here you are, copying it.
>>> > It explicit says: "
>>> > Use of the Service. You may only display the content of the Service for
>>> > your own personal use (i.e., non-commercial use) and may not otherwise 
>>> > copy,
>>> > reproduce, alter, modify, create derivative works, or publicly display any
>>> > content. "
>>> >
>>> > Before this is accepted, someone should email cert and say "hey, uh,
>>> > yeah, this seems bad", and get them to okay you doing this.
>>> > I'm sure they'll go and fix this.
>>>
>>> That's an excellent point, I will bring it up internally (I work for
>>> CERT) and report back.
>>
>>
>> Any news here?
>
> Yes; I have heard back from CERT's legal team, and they have a
> document that I have sent (off-list) to Daniel for review. If it seems
> like it would resolve his concerns, then I think the next step will be
> to bring it to the LLVM foundation more formally to see how they would
> like to handle it.
>
> ~Aaron
>
>>
>>>
>>>
>>> ~Aaron
>>>
>>> >
>>> >
>>> >
>>> > http://reviews.llvm.org/D13446
>>> >
>>> >
>>> >
>>
>>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D15087: [PATCH] Add CERT license clarification

[Aaron Ballman via cfe-commits]

aaron.ballman created this revision.
aaron.ballman added reviewers: dberlin, chandlerc, alexfh.
aaron.ballman added a subscriber: cfe-commits.

During the review of D13446, Daniel pointed out that the CERT website's Terms 
of Use appear to prohibit using the rule title and minimal descriptions in our 
documentation. CERT's legal team has confirmed that our uses are acceptable, 
and drafted a license agreement that states such. I have verified that none of 
our documentation replicates the descriptions used in CERT's guidelines, and 
this patch is updating the license file with CERT's confirmation.

http://reviews.llvm.org/D15087

Files:
  LICENSE.TXT
  clang-tidy/cert/LICENSE.TXT

Index: LICENSE.TXT
===
--- LICENSE.TXT
+++ LICENSE.TXT
@@ -59,5 +59,4 @@
 
 Program Directory
 --- -
-
-
+clang-tidy  clang-tidy/cert
Index: clang-tidy/cert/LICENSE.TXT
===
--- clang-tidy/cert/LICENSE.TXT
+++ clang-tidy/cert/LICENSE.TXT
@@ -0,0 +1,22 @@
+--
+clang-tidy CERT Files
+--
+All clang-tidy files are licensed under the LLVM license with the following
+additions:
+
+Any file referencing a CERT Secure Coding guideline:
+Please allow this letter to serve as confirmation that open source projects on
+http://llvm.org are permitted to link via hypertext to the CERT(R) secure 
coding
+guidelines available at https://www.securecoding.cert.org.   
+
+The foregoing is permitted by the Terms of Use as follows:
+"Linking to the Service
+Because we update many of our Web documents regularly, we would prefer that you
+link to our Web pages whenever possible rather than reproduce them. It is not
+necessary to request permission to make referential hypertext links to The
+Service."
+http://www.sei.cmu.edu/legal/ip/index.cfm.
+
+Please allow this letter to also confirm that no formal permission is required
+to reproduce the title of the content being linked to, nor to reproduce any
+de Minimis description of such content.


Index: LICENSE.TXT
===
--- LICENSE.TXT
+++ LICENSE.TXT
@@ -59,5 +59,4 @@
 
 Program Directory
 --- -
-
-
+clang-tidy  clang-tidy/cert
Index: clang-tidy/cert/LICENSE.TXT
===
--- clang-tidy/cert/LICENSE.TXT
+++ clang-tidy/cert/LICENSE.TXT
@@ -0,0 +1,22 @@
+--
+clang-tidy CERT Files
+--
+All clang-tidy files are licensed under the LLVM license with the following
+additions:
+
+Any file referencing a CERT Secure Coding guideline:
+Please allow this letter to serve as confirmation that open source projects on
+http://llvm.org are permitted to link via hypertext to the CERT(R) secure coding
+guidelines available at https://www.securecoding.cert.org.   
+
+The foregoing is permitted by the Terms of Use as follows:
+"Linking to the Service
+Because we update many of our Web documents regularly, we would prefer that you
+link to our Web pages whenever possible rather than reproduce them. It is not
+necessary to request permission to make referential hypertext links to The
+Service."
+http://www.sei.cmu.edu/legal/ip/index.cfm.
+
+Please allow this letter to also confirm that no formal permission is required
+to reproduce the title of the content being linked to, nor to reproduce any
+de Minimis description of such content.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D10599: [OPENMP 4.0] Initial support for '#pragma omp declare simd' directive.

[Alexey Bataev via cfe-commits]

ABataev added a comment.

Ping


http://reviews.llvm.org/D10599



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

Re: [PATCH] D11182: [OPENMP 4.0] Initial support for 'omp declare reduction' construct.

[Alexey Bataev via cfe-commits]

ABataev added a comment.

Richard, could you take a look one more time, please?


http://reviews.llvm.org/D11182



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

Re: [PATCH] D14409: Remove visibility attributes from out-of-class method definitions in iostreams.

[Evgeniy Stepanov via cfe-commits]

eugenis added a comment.

ping


Repository:
  rL LLVM

http://reviews.llvm.org/D14409



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

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

[John McCall via cfe-commits]

rjmccall added a comment.

In http://reviews.llvm.org/D14980#298754, @rsmith wrote:

> GCC's behavior (`aligned` on a field specifies the alignment of the start of 
> that field) makes a little more sense to me than Clang's behavior (the type 
> and alignment of a field specify a flavour of storage unit, and the field 
> goes in the next such storage unit that it fits into), but both seem 
> defensible.


Are you saying that `aligned` on a bit-field always starts new storage on GCC?

> John, are we intentionally deviating from GCC's behaviour here?


No.  I consider this to be GCC's extension, with which we are required to be 
ABI-compatible.  This is just a bug.


http://reviews.llvm.org/D14980



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

Re: [PATCH] D13980: Add "x87" in x86 target feature map

[Richard Smith via cfe-commits]

rsmith added inline comments.


Comment at: lib/Basic/Targets.cpp:2548
@@ +2547,3 @@
+  // All X86 processors but i386 have X87.
+  if (Kind != CK_i386)
+setFeatureEnabledImpl(Features, "x87", true);

aturetsk wrote:
> rsmith wrote:
> > What about `CK_Generic`? Also, if `CK_i486` can be used for the 486SX, we 
> > need to exclude it here too. It looks (from wikipedia) like all the 
> > "WinChip" flavours of 486 have an x87 unit, but it'd be nice if someone 
> > could confirm that. Maybe we should have separate `CPUKind`s for 486 SX 
> > versus 486 DX.
> Before this changeset clang would generate x87 instructions for Generic, i386 
> and i486. So one can say they had FeatureX87 enabled implicitly. If that was 
> ok formerly why do we want to change that now? Wouldn't it be better to keep 
> clang's behavior unchanged?
OK, if this means "x87 instructions probably work" (although they may be 
emulated in software) and not "x87 instructions definitely work", then we 
shouldn't be checking the CPU kind here at all. It looks like the former is how 
GCC handles this; it has `-mno-80387` to specify that we're building for an 
i386 with no support for x87 instructions. Should we handle that flag?


http://reviews.llvm.org/D13980



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

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

[John McCall via cfe-commits]

rjmccall added a comment.

Well, this is a really nasty bug.

Please check how this interacts with #pragma pack, which normally takes 
precedence over even explicit alignment attributes.  If that's the case here, 
then what you really want to do is just add the same "ExplicitFieldAlign ||" 
clause to the main computation that you do to the diagnostic computation.


http://reviews.llvm.org/D14980



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

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

[Richard Smith via cfe-commits]

rsmith added a subscriber: rsmith.
rsmith added a comment.

GCC's behavior (`aligned` on a field specifies the alignment of the start of 
that field) makes a little more sense to me than Clang's behavior (the type and 
alignment of a field specify a flavour of storage unit, and the field goes in 
the next such storage unit that it fits into), but both seem defensible.

John, are we intentionally deviating from GCC's behaviour here?



Comment at: lib/AST/RecordLayoutBuilder.cpp:1606
@@ -1605,1 +1605,3 @@
+} else if (ExplicitFieldAlign)
+  FieldOffset = llvm::RoundUpToAlignment(FieldOffset, ExplicitFieldAlign);
 

You should round up to `FieldAlign` here.


http://reviews.llvm.org/D14980



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

Re: [PATCH] D13980: Add "x87" in x86 target feature map

[Andrey Turetskiy via cfe-commits]

aturetsk added inline comments.


Comment at: lib/Basic/Targets.cpp:2548
@@ +2547,3 @@
+  // All X86 processors but i386 have X87.
+  if (Kind != CK_i386)
+setFeatureEnabledImpl(Features, "x87", true);

rsmith wrote:
> What about `CK_Generic`? Also, if `CK_i486` can be used for the 486SX, we 
> need to exclude it here too. It looks (from wikipedia) like all the "WinChip" 
> flavours of 486 have an x87 unit, but it'd be nice if someone could confirm 
> that. Maybe we should have separate `CPUKind`s for 486 SX versus 486 DX.
Before this changeset clang would generate x87 instructions for Generic, i386 
and i486. So one can say they had FeatureX87 enabled implicitly. If that was ok 
formerly why do we want to change that now? Wouldn't it be better to keep 
clang's behavior unchanged?


http://reviews.llvm.org/D13980



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

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

[Teresa Johnson via cfe-commits]

tejohnson added a comment.

Thanks for the review, comments below.
Teresa



Comment at: lib/CodeGen/CodeGenAction.cpp:190
@@ -169,3 +189,3 @@
 [=](const DiagnosticInfo &DI) {
-  linkerDiagnosticHandler(DI, LinkModule);
+  linkerDiagnosticHandler(DI, LinkModule, 
Diags);
 },

joker.eph wrote:
> Is this an unrelated change to the `-fthinlto-backend` one that could be 
> committed separately?
It is related in that I am now calling linkerDiagnosticHandler from outside 
BackendConsumer, which required moving it out of that class, and therefore we 
need to pass in the DiagnosticsEngine.


Comment at: lib/CodeGen/CodeGenAction.cpp:821
@@ +820,3 @@
+linkerDiagnosticHandler(DI, TheModule.get(),
+CI.getDiagnostics());
+  }, llvm::Linker::Flags::None, Index.get()))

joker.eph wrote:
> This lambda is the same as the one just above for `getFunctionIndexForFile`, 
> name it and define it once?
Ok


Comment at: lib/CodeGen/CodeGenAction.cpp:826
@@ +825,3 @@
+  TheModule = std::move(Combined);
+}
+

joker.eph wrote:
> So for the renaming we need to duplicate completely the module? It cannot be 
> done by morphing the existing module in place? That seems quite inefficient :(
For now that is how the ModuleLinker works unfortunately. Rafael is working on 
a change to split this into two parts, and the symbol resolution would be done 
in place. So this should be resolved eventually.


http://reviews.llvm.org/D15025



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

r254306 - Add --gcc-toolchain= to one of the libclang unitests to fix issue related to

[Samuel Antao via cfe-commits]

Author: sfantao
Date: Mon Nov 30 11:26:28 2015
New Revision: 254306

URL: http://llvm.org/viewvc/llvm-project?rev=254306&view=rev
Log:
Add --gcc-toolchain= to one of the libclang unitests to fix issue related to 
the gcc libraries clang picks for when it was configures with a user defined 
path.


Modified:
cfe/trunk/unittests/libclang/LibclangTest.cpp

Modified: cfe/trunk/unittests/libclang/LibclangTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/libclang/LibclangTest.cpp?rev=254306&r1=254305&r2=254306&view=diff
==
--- cfe/trunk/unittests/libclang/LibclangTest.cpp (original)
+++ cfe/trunk/unittests/libclang/LibclangTest.cpp Mon Nov 30 11:26:28 2015
@@ -482,7 +482,8 @@ TEST_F(LibclangReparseTest, clang_parseT
   std::string Clang = "bin/clang";
   WriteFile(Clang, "");
 
-  const char *Argv[] = {Clang.c_str(), "-target", "arm-linux-gnueabi"};
+  const char *Argv[] = {Clang.c_str(), "-target", "arm-linux-gnueabi",
+"--gcc-toolchain="};
 
   EXPECT_EQ(CXError_Success,
 clang_parseTranslationUnit2FullArgv(Index, Filename.c_str(), Argv,


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

Re: [Static Analyzer] New checker hook: checkInitialState

[Artem Dergachev via cfe-commits]

Hmm. I once thought about creating a 'checkBeginAnalysis()' callback to 
match 'checkEndAnalysis()'; this one's more powerful, and matches 
'checkEndFunction()' in a similar manner.


At a glance, I wonder if it's worth it to provide a CheckerContext 
inside this callback and then handle transitions properly (which would 
allow the checker to split the program state at the very beginning of 
the function). I cannot instantly think of a use-case (hmm, maybe 
somebody would like to eagerly discriminate between a NULL and non-NULL 
pointer argument of the function), but at the same time I don't see any 
obvious problems with adding it, especially because it'd be hard to 
change the API when the use-case appears.

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

r254303 - Do not crash when dumping the objc_bridge_related attribute when its optional arguments are not supplied.

[Aaron Ballman via cfe-commits]

Author: aaronballman
Date: Mon Nov 30 09:25:34 2015
New Revision: 254303

URL: http://llvm.org/viewvc/llvm-project?rev=254303&view=rev
Log:
Do not crash when dumping the objc_bridge_related attribute when its optional 
arguments are not supplied.

Patch thanks to Joe Ranieri!

Modified:
cfe/trunk/include/clang/Basic/Attr.td
cfe/trunk/test/Misc/ast-dump-attr.cpp
cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp

Modified: cfe/trunk/include/clang/Basic/Attr.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=254303&r1=254302&r2=254303&view=diff
==
--- cfe/trunk/include/clang/Basic/Attr.td (original)
+++ cfe/trunk/include/clang/Basic/Attr.td Mon Nov 30 09:25:34 2015
@@ -1087,8 +1087,8 @@ def ObjCBridgeRelated : InheritableAttr
   let Spellings = [GNU<"objc_bridge_related">];
   let Subjects = SubjectList<[Record], ErrorDiag>;
   let Args = [IdentifierArgument<"RelatedClass">,
-  IdentifierArgument<"ClassMethod">,
-  IdentifierArgument<"InstanceMethod">];
+  IdentifierArgument<"ClassMethod", 1>,
+  IdentifierArgument<"InstanceMethod", 1>];
   let HasCustomParsing = 1;
   let Documentation = [Undocumented];
 }

Modified: cfe/trunk/test/Misc/ast-dump-attr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Misc/ast-dump-attr.cpp?rev=254303&r1=254302&r2=254303&view=diff
==
--- cfe/trunk/test/Misc/ast-dump-attr.cpp (original)
+++ cfe/trunk/test/Misc/ast-dump-attr.cpp Mon Nov 30 09:25:34 2015
@@ -150,3 +150,7 @@ void f() {
   // CHECK: DeprecatedAttr
 }
 }
+
+struct __attribute__((objc_bridge_related(NSParagraphStyle,,))) TestBridgedRef;
+// CHECK: CXXRecordDecl{{.*}} struct TestBridgedRef
+// CHECK-NEXT: ObjCBridgeRelatedAttr{{.*}} NSParagraphStyle

Modified: cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp?rev=254303&r1=254302&r2=254303&view=diff
==
--- cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp (original)
+++ cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp Mon Nov 30 09:25:34 2015
@@ -279,6 +279,8 @@ namespace {
 OS << "OS << \" \";\n";
 OS << "dumpBareDeclRef(SA->get" << getUpperName() << "());\n"; 
   } else if (type == "IdentifierInfo *") {
+if (isOptional())
+  OS << "if (SA->get" << getUpperName() << "())\n  ";
 OS << "OS << \" \" << SA->get" << getUpperName()
<< "()->getName();\n";
   } else if (type == "TypeSourceInfo *") {


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

Re: [PATCH] Don't crash when dumping objc_bridge_related attributes

[Aaron Ballman via cfe-commits]

On Thu, Nov 26, 2015 at 12:00 PM, Joe Ranieri  wrote:
> On Thu, Nov 26, 2015 at 11:29 AM, Aaron Ballman  
> wrote:
>> On Wed, Nov 25, 2015 at 6:13 PM, Joe Ranieri  wrote:
>>> Clang's AST dumping currently crashes when dumping objc_bridge_related
>>> attributes where the class method and instance method fields are left
>>> empty. The attached patch marks the two arguments as optional and
>>> updates TableGen to understand the optional flag for identifier
>>> attribute arguments when generating the dump function.
>>
>> LGTM, thank you! Do you have commit privileges, or would you like me
>> to commit on your behalf?
>>
>> ~Aaron
>
> Please commit on my behalf.

Thanks! I've commit in r254303

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

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

[Dmitry Polukhin via cfe-commits]

DmitryPolukhin added a comment.

Friendly ping, any comments about this patch?


http://reviews.llvm.org/D14980



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

[PATCH] Add a builtin for indexing into parameter packs

[Louis Dionne via cfe-commits]

Hi,

I wrote a patch that adds a `__nth_element` builtin that allows fetching the 
n-th type of a parameter pack with very little compile-time overhead. The patch 
was inspired by r252036 and r252115 by David Majnemer, which add a similar 
`__make_integer_seq` builtin for efficiently creating a 
`std::integer_sequence`. 
At its core, the builtin makes the following specialization

__nth_element

equivalent to Ti. Further analysis of the problem this patch is trying to solve 
is available on a blog post I just wrote [1]. The post also present benchmarks 
showing the compile-time improvement over existing techniques.

The patch is currently in a very rough state. It is my first time contributing 
to Clang, and I encountered some issues that I hacked around just to get a 
working solution. If there is interest in this patch, I will gladly improve 
it until it is in an acceptable state, but I will most likely need some 
pointers to do so. Things that are hacky right now:

1. I wasn't able to create a non-type template parameter from a builtin type. 
   Hence, `__nth_element` must currently be used as 
 __nth_element
   instead of just `__nth_element`, while forcing `Index` to be 
   something like `unsigned long`. This way, I was able to copy Majnemer's 
   code that creates non-type template parameters. This is probably trivial 
   to change, but I couldn't figure it out immediately.

2. I wasn't sure how to retrieve an actual integer from an `APSInt`, so right 
   now I use `getExtValue()`. This is probably wrong, as I didn't really 
   understand what I was doing.

There are certainly other issues that a code review would address, if we make 
it that far. Also, the name `__nth_element` is badly chosen, since it seems 
to refer to the `nth_element` algorithm of the standard library. We should 
settle on something else, but I have no preference.

I also wrote a corresponding patch for libc++ to use the builtin to implement
`std::tuple_element`. You can find both patches attached to this message. Also,
these patches were initially posted as bug reports [2] and [3], respectively.

Please let me know if there is any interest for going forward with these 
patches.

Regards,
Louis Dionne

[1]: http://ldionne.com/2015/11/29/efficient-parameter-pack-indexing
[2]: https://llvm.org/bugs/show_bug.cgi?id=25670
[3]: https://llvm.org/bugs/show_bug.cgi?id=25671



clang-sema.diff
Description: Binary data


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

[PATCH] D15070: [mips] Added support for -Wa,-mips32 and similar.

[Scott Egerton via cfe-commits]

s.egerton created this revision.
s.egerton added reviewers: dsanders, vkalintiris.
s.egerton added a subscriber: cfe-commits.

http://reviews.llvm.org/D15070

Files:
  lib/Driver/Tools.cpp
  test/Driver/mips-ias-Wa.s

Index: test/Driver/mips-ias-Wa.s
===
--- test/Driver/mips-ias-Wa.s
+++ test/Driver/mips-ias-Wa.s
@@ -47,3 +47,83 @@
 // RUN:   FileCheck -check-prefix=MSOFT-FLOAT-BOTH-MHARD-FLOAT-FIRST %s
 // MSOFT-FLOAT-BOTH-MHARD-FLOAT-FIRST: -cc1as
 // MSOFT-FLOAT-BOTH-MHARD-FLOAT-FIRST: "-target-feature" "-soft-float" "-target-feature" "+soft-float"
+
+// RUN: %clang -target mips-linux-gnu -### -fintegrated-as -c %s -Wa,-mips1 2>&1 | \
+// RUN:   FileCheck -check-prefix=MIPS1 %s
+// MIPS1: -cc1as
+// MIPS1: "-target-feature" "+mips1"
+
+// RUN: %clang -target mips-linux-gnu -### -fintegrated-as -c %s -Wa,-mips2 2>&1 | \
+// RUN:   FileCheck -check-prefix=MIPS2 %s
+// MIPS2: -cc1as
+// MIPS2: "-target-feature" "+mips2"
+
+// RUN: %clang -target mips-linux-gnu -### -fintegrated-as -c %s -Wa,-mips3 2>&1 | \
+// RUN:   FileCheck -check-prefix=MIPS3 %s
+// MIPS3: -cc1as
+// MIPS3: "-target-feature" "+mips3"
+
+// RUN: %clang -target mips-linux-gnu -### -fintegrated-as -c %s -Wa,-mips4 2>&1 | \
+// RUN:   FileCheck -check-prefix=MIPS4 %s
+// MIPS4: -cc1as
+// MIPS4: "-target-feature" "+mips4"
+
+// RUN: %clang -target mips-linux-gnu -### -fintegrated-as -c %s -Wa,-mips32 2>&1 | \
+// RUN:   FileCheck -check-prefix=MIPS32 %s
+// MIPS32: -cc1as
+// MIPS32: "-target-feature" "+mips32"
+
+// RUN: %clang -target mips-linux-gnu -### -fintegrated-as -c %s -Wa,-mips32r2 2>&1 | \
+// RUN:   FileCheck -check-prefix=MIPS32R2 %s
+// MIPS32R2: -cc1as
+// MIPS32R2: "-target-feature" "+mips32r2"
+
+// RUN: %clang -target mips-linux-gnu -### -fintegrated-as -c %s -Wa,-mips32r3 2>&1 | \
+// RUN:   FileCheck -check-prefix=MIPS32R3 %s
+// MIPS32R3: -cc1as
+// MIPS32R3: "-target-feature" "+mips32r3"
+
+// RUN: %clang -target mips-linux-gnu -### -fintegrated-as -c %s -Wa,-mips32r5 2>&1 | \
+// RUN:   FileCheck -check-prefix=MIPS32R5 %s
+// MIPS32R5: -cc1as
+// MIPS32R5: "-target-feature" "+mips32r5"
+
+// RUN: %clang -target mips-linux-gnu -### -fintegrated-as -c %s -Wa,-mips32r6 2>&1 | \
+// RUN:   FileCheck -check-prefix=MIPS32R6 %s
+// MIPS32R6: -cc1as
+// MIPS32R6: "-target-feature" "+mips32r6"
+
+// RUN: %clang -target mips-linux-gnu -### -fintegrated-as -c %s -Wa,-mips64 2>&1 | \
+// RUN:   FileCheck -check-prefix=MIPS64 %s
+// MIPS64: -cc1as
+// MIPS64: "-target-feature" "+mips64"
+
+// RUN: %clang -target mips-linux-gnu -### -fintegrated-as -c %s -Wa,-mips64r2 2>&1 | \
+// RUN:   FileCheck -check-prefix=MIPS64R2 %s
+// MIPS64R2: -cc1as
+// MIPS64R2: "-target-feature" "+mips64r2"
+
+// RUN: %clang -target mips-linux-gnu -### -fintegrated-as -c %s -Wa,-mips64r3 2>&1 | \
+// RUN:   FileCheck -check-prefix=MIPS64R3 %s
+// MIPS64R3: -cc1as
+// MIPS64R3: "-target-feature" "+mips64r3"
+
+// RUN: %clang -target mips-linux-gnu -### -fintegrated-as -c %s -Wa,-mips64r5 2>&1 | \
+// RUN:   FileCheck -check-prefix=MIPS64R5 %s
+// MIPS64R5: -cc1as
+// MIPS64R5: "-target-feature" "+mips64r5"
+
+// RUN: %clang -target mips-linux-gnu -### -fintegrated-as -c %s -Wa,-mips64r6 2>&1 | \
+// RUN:   FileCheck -check-prefix=MIPS64R6 %s
+// MIPS64R6: -cc1as
+// MIPS64R6: "-target-feature" "+mips64r6"
+
+// RUN: %clang -target mips-linux-gnu -### -fintegrated-as -c %s -Wa,-mips64r2,-mips4 2>&1 | \
+// RUN:   FileCheck -check-prefix=MIPS64R2-MIPS4 %s
+// MIPS64R2-MIPS4: -cc1as
+// MIPS64R2-MIPS4: "-target-feature" "+mips4"
+
+// RUN: %clang -target mips-linux-gnu -### -fintegrated-as -c %s -Wa,-mips64,-mips32,-mips32r2 2>&1 | \
+// RUN:   FileCheck -check-prefix=MIPS64-MIPS32-MIPS32R2 %s
+// MIPS64-MIPS32-MIPS32R2: -cc1as
+// MIPS64-MIPS32-MIPS32R2: "-target-feature" "+mips32r2"
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -2498,6 +2498,30 @@
   CmdArgs.push_back("-soft-float");
   continue;
 }
+
+const char *Feature = llvm::StringSwitch(Value)
+  .Case("-mips1", "+mips1")
+  .Case("-mips2", "+mips2")
+  .Case("-mips3", "+mips3")
+  .Case("-mips4", "+mips4")
+  .Case("-mips32", "+mips32")
+  .Case("-mips32r2", "+mips32r2")
+  .Case("-mips32r3", "+mips32r3")
+  .Case("-mips32r5", "+mips32r5")
+  .Case("-mips32r6", "+mips32r6")
+  .Case("-mips64", "+mips64")
+  .Case("-mips64r2", "+mips64r2")
+  .Case("-mips64r3", "+mips64r3")
+  .Case("-mips64r5"

[PATCH] Fix the err_objc_type_args_after_protocols error message.

[Ewan Mellor via cfe-commits]

Type arguments must be before protocols in Objective-C type
declarations.  The error name and code behavior are correct,
just the message is wrong.
---
 include/clang/Basic/DiagnosticParseKinds.td | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/clang/Basic/DiagnosticParseKinds.td b/include/clang/Basic/DiagnosticParseKinds.td
index af22460..66fec17 100644
--- a/include/clang/Basic/DiagnosticParseKinds.td
+++ b/include/clang/Basic/DiagnosticParseKinds.td
@@ -968,7 +968,7 @@ def err_objc_parameterized_implementation : Error<
   "@implementation cannot have type parameters">;
 
 def err_objc_type_args_after_protocols : Error<
-  "protocol qualifiers must precede type arguments">;
+  "type arguments must precede protocol qualifiers">;
 }
 
 let CategoryName = "Coroutines Issue" in {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits