Re: [PATCH] D13516: Fix overlapping replacements in clang-tidy.

[Daniel Jasper via cfe-commits]

djasper added a subscriber: djasper.


Comment at: clang-tidy/ClangTidyDiagnosticConsumer.cpp:495-496
@@ +494,4 @@
+  for (unsigned I = 0; I < NumErrors; ++I) {
+const auto  = Errors[I];
+// Skip errors without fixes. They are never going to overlap with anything
+// and the bounding box is undefined.

From a brief look, it seems like it might be slightly easier, to do what this 
is currently doing, but skip the bounding-box-calculation step. Simple do the 
same with each interval of each fix. We are just interested to efficiently 
calculate, which fixes overlap at all.

Now, I am not sure whether this is going to be more or less efficient:
* It might be hard / not worth it to calculate which fixes have already been 
compared so we might compare the same two fixes repeatedly (once for each 
"touching point").
* We might not need to carefully compare fixes at all in spite of their 
bounding boxes overlapping, e.g. two fixes A and B might have 3 entirely 
disjoint intervals: A, B, A. Then, we don't need to do the sweep at all.




http://reviews.llvm.org/D13516



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

Re: [PATCH] D13643: [Sema] Warn on ternary comparison

[Aaron Ballman via cfe-commits]

aaron.ballman added a comment.

In http://reviews.llvm.org/D13643#266649, @mgrabovsky wrote:

> In http://reviews.llvm.org/D13643#265976, @aaron.ballman wrote:
>
> > Should there be an exception to this diagnostic for code involving Boolean 
> > values? e.g.,
> >
> > void f(bool a, bool b, bool c) {
> >
> >   if (a == b == c)
> > ;
> >
> > }
> >
> > At the very least, it seems like this should also follow GCC's behavior and 
> > suggest parenthesis directly.
>
>
> Interesting. This might be more complex than I had predicted. I'll try to dig 
> into GCC's code and see what they do exactly. I can't guarantee returning 
> sane, though.
>
> Some thoughts: Even if `a, b, c` are Booleans, what did the user mean by `a 
> == b == c`? Do they realise that the compiler interprets it as `(a == b) == 
> c`? What about 'type mismatches', i.e. if `a, b` are `int`s, while `b` is 
> `bool` – clearly the user must be aware of the interpretation above here. 
> What if `a, b, c` are all `int`s – C90 doesn't have Booleans, so it might be 
> intended as either.


I would spend some time digging into how GCC handles those cases, and use that 
as a baseline that we can then improve upon. I like the fact that GCC basically 
says "use parens to clarify your intent", as that solves all of the cases 
regarding equality and inequality.

I would imagine type == type == bool should behave the same as bool == bool == 
bool; it can be valid code that just needs parens to clarify intent. As for C90 
behavior, I'm not too worried about what we do there.



Comment at: include/clang/Basic/DiagnosticSemaKinds.td:5865
@@ -5864,1 +5864,3 @@
 
+def warn_ternary_comparison : Warning<"ternary comparisons do not work "
+  "as expected">,

mgrabovsky wrote:
> aaron.ballman wrote:
> > This diagnostic somewhat implies that ?: does not work as expected. I 
> > prefer GCC's wording for this:
> > 
> > "comparisons like 'X<=Y<=Z' do not have their mathematical meaning"
> > 
> > However, I would love it if we could do one step better and use the same 
> > operators the user wrote, if reasonable. ;-)
> > This diagnostic somewhat implies that ?: does not work as expected.
> 
> ?: is a ternary operator but it's not a comparison.
> 
> > I prefer GCC's wording for this
> 
> I wasn't sure if we wanted to be copycats, but OK.
> 
> > would love it if we could do one step better and use the same operators the 
> > user wrote
> 
> Yes, that would be nice.
> I wasn't sure if we wanted to be copycats, but OK.

If we can improve on their wording, I am all for it. I just find their wording 
more clear than the proposed wording.


http://reviews.llvm.org/D13643



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

Re: [PATCH] D11908: Clang support for -fthinlto.

[Teresa Johnson via cfe-commits]

Ping.
Thanks,
Teresa

On Sat, Oct 3, 2015 at 6:51 PM, Teresa Johnson  wrote:
> tejohnson updated this revision to Diff 36453.
> tejohnson added a comment.
>
> - Rename code gen option to EmitFunctionSummary as per review for 
> http://reviews.llvm.org/D13107.
> - Clang format the latest changes.
>
>   Let me know if it looks good now.
>
>
> http://reviews.llvm.org/D11908
>
> Files:
>   include/clang/Driver/Driver.h
>   include/clang/Driver/Options.td
>   include/clang/Frontend/CodeGenOptions.def
>   lib/CodeGen/BackendUtil.cpp
>   lib/Driver/Driver.cpp
>   lib/Driver/SanitizerArgs.cpp
>   lib/Driver/Tools.cpp
>   lib/Frontend/CompilerInvocation.cpp
>   test/Driver/clang_f_opts.c
>   test/Driver/lto.c
>   test/Driver/thinlto.c
>   test/Misc/thinlto.c
>



-- 
Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r250298 - Tweak a -g related test for the PS4

[Filipe Cabecinhas via cfe-commits]

Author: filcab
Date: Wed Oct 14 09:45:36 2015
New Revision: 250298

URL: http://llvm.org/viewvc/llvm-project?rev=250298=rev
Log:
Tweak a -g related test for the PS4

Make sure we're matching what we want:
 - Always have -generate-arange-section (independent of -g)
 - Emit a -dwarf-version=... when -g is there.

Modified:
cfe/trunk/test/Driver/debug-options.c

Modified: cfe/trunk/test/Driver/debug-options.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/debug-options.c?rev=250298=250297=250298=diff
==
--- cfe/trunk/test/Driver/debug-options.c (original)
+++ cfe/trunk/test/Driver/debug-options.c Wed Oct 14 09:45:36 2015
@@ -30,7 +30,7 @@
 // On the PS4, -g defaults to -gno-column-info, and we always generate the
 // arange section.
 // RUN: %clang -### -c %s -target x86_64-scei-ps4 2>&1 \
-// RUN: | FileCheck -check-prefix=G_PS4 %s
+// RUN: | FileCheck -check-prefix=NOG_PS4 %s
 // RUN: %clang -### -c %s -g -target x86_64-scei-ps4 2>&1 \
 // RUN: | FileCheck -check-prefix=G_PS4 %s
 // RUN: %clang -### -c %s -g -target x86_64-scei-ps4 2>&1 \
@@ -98,7 +98,13 @@
 // G_DARWIN: "-cc1"
 // G_DARWIN: "-dwarf-version=2"
 //
+// NOG_PS4: "-cc1"
+// NOG_PS4-NOT "-dwarf-version=
+// NOG_PS4: "-generate-arange-section"
+// NOG_PS4-NOT: "-dwarf-version=
+//
 // G_PS4: "-cc1"
+// G_PS4: "-dwarf-version=
 // G_PS4: "-generate-arange-section"
 //
 // G_D2: "-cc1"


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

Re: [PATCH] D13516: Fix overlapping replacements in clang-tidy.

[Daniel Jasper via cfe-commits]

djasper added a comment.

There might be an even easier algorithm:

What if we put all start and end points into a single sorted list. Identical 
start points are sorted by decreasing end points and identical end points are 
sorted by increasing start points. Now do a single sweep and simply count the 
total number of starts vs. the total number of ends, call this C (if you 
encounter a start point, ++C, if you encounter an end point, --C). If you 
encounter a start-point and C != 0, mark the interval and corresponding Fixit 
as inapplicable. Similarly if you encounter an end point and C != 1, mark the 
fixit as inapplicable. Basically, this does a single sweep over all fixits and 
marks the ones as bad that have either their start point or their endpoint 
within a different interval.

(Take this as an additional idea, if you have an existing algorithm that you 
like better, I am fine with keeping that. Just wanted to give my additional 
thoughts).


http://reviews.llvm.org/D13516



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

Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain

[Romanova, Katya via cfe-commits]

Thank you, Filipe!
Katya.

Sent from my iPhone

On Oct 14, 2015, at 6:12 AM, "Filipe Cabecinhas" 
> 
wrote:

Hi all,

I have harnessed the powers of time zones and did the last tweak we needed to 
get it comitted.
It's still going through some bots, but I don't foresee big problems. The fast 
bots liked it.

Thanks to everyone that reviewed it and worked on it!

  Filipe

On Wed, Oct 14, 2015 at 8:54 AM, Romanova, Katya 
>
 wrote:
Hi Sean,

I don’t think that the whole patch should have been reverted. There were much 
easier way to make the PS4 bot green. A single test could have been marked as 
“XFAIL: ps4” for a few hours until a better solution is implemented. Reverting 
this huge patch is more drastic measure that might cause more problems later.

As you saw in my previous email, I kept an eye on the bots, noticed the failure 
on PS4 buildbot, explained why it happened in the email and ask community for 
an opinion if it could be temporarily marked as “XFAIL” for ps4 only. I had to 
leave work at certain point. When I got home, I saw that you reverted the whole 
fix. Now I will have to go through all the pain with maintaining a huge commit, 
instead of making one line change affecting one of the tests on PS4 platform 
only… But, I guess, if it’s a general practice,  then it’s a different story. I 
was not aware of this practice and I thought that the other solution was much 
more reasonable.

Thank you for letting me know about LLVM_DEFAULT_TARGET_TRIPLE=x86_64-scei-ps4. 
I will definitely run it before the next commit.

Katya.


From: Sean Silva [mailto:chisophu...@gmail.com]
Sent: Tuesday, October 13, 2015 11:56 PM
To: Eric Christopher
Cc: 
reviews+d13482+public+a1a9627af638c...@reviews.llvm.org;
 Romanova, Katya; Alex Rosenberg; Robinson, Paul; 
filcab+llvm.phabrica...@gmail.com; 
Jonathan Roelofs; Bedwell, Greg; 
pierregoussea...@gmail.com; Anton 
Korobeynikov; Takumi NAKAMURA; cfe-commits
Subject: Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain



On Tue, Oct 13, 2015 at 11:40 PM, Eric Christopher 
> wrote:

On Tue, Oct 13, 2015 at 11:38 PM Sean Silva 
> wrote:
On Tue, Oct 13, 2015 at 11:33 PM, Eric Christopher 
> wrote:
It was already reverted, but I agree, let's get this fixed first.

It was reintroduced in r250252. It is breaking 
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/1362


Ah, I missed that. Yeah, please go ahead and revert for now.

reverted in r250273
(bot is back to green: 
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/1363
 )

Katya - remember to run the tests with 
LLVM_DEFAULT_TARGET_TRIPLE=x86_64-scei-ps4 (and also remember to keep an eye on 
the bots after committing)

-- Sean Silva


Thanks!

-eric

-- Sean Silva


Thanks!

-eric

On Tue, Oct 13, 2015 at 11:33 PM Sean Silva 
> wrote:
On Tue, Oct 13, 2015 at 7:51 PM, Katya Romanova 
>
 wrote:
kromanova added a comment.

Hi,

The initial PS4 patch caused a test failure (debug-options.c) on the PS4 bot. I 
suspect that I know why the problem happens, but I'm not sure what will be the 
best way to handle it. If someone knows how to fix this test more "elegantly", 
I would appreciate their advice.

FAIL: Clang :: Driver/debug-options.c (3509 of 24708)

- TEST 'Clang :: Driver/debug-options.c' FAILED 

Script:
---

/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/clang
  -### -c -g 
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
 -target x86_64-linux-gnu 2>&1  | 
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
 -check-prefix=G /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-


/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/clang
  -### -g 
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
 2>&1 | 
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
 -check-prefix=CI 
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c

Re: [PATCH] D13516: Fix overlapping replacements in clang-tidy.

[Angel Garcia via cfe-commits]

angelgarcia added a comment.

That works pretty well (well, identical end points have to be sorted
decreasingly, if I understand correctly). I see a couple of problems
though, like equal intervals, or consecutive. But the algorithm is way more
efficient than what we currently have, I will try to make it work.


http://reviews.llvm.org/D13516



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

Re: [PATCH] D13516: Fix overlapping replacements in clang-tidy.

[Angel Garcia via cfe-commits]

angelgarcia added a comment.

I've done a couple of runs for each version, and these are the results (I
have clang-tidy compiled with the option "RelWithDebInfo"):

$ time clang-tidy -checks=* test.cpp -- -std=c++11

Without looking for overlaps.

Suppressed 23463 warnings (23463 in non-user code).
Use -header-filter=.* to display errors from all non-system headers.

real2m14.572s
user2m13.136s
sys 0m0.483s

real2m15.103s
user2m13.361s
sys 0m0.687s

Bounding boxes

Suppressed 23463 warnings (23463 in non-user code).
Use -header-filter=.* to display errors from all non-system headers.

real2m14.208s
user2m13.051s
sys 0m0.643s

real2m16.368s
user2m14.286s
sys 0m0.986s

Quadratic

Suppressed 23463 warnings (23463 in non-user code).
Use -header-filter=.* to display errors from all non-system headers.

real2m15.130s
user2m13.627s
sys 0m0.499s

real2m15.322s
user2m13.660s
sys 0m0.683s

The time is about the same for all three versions. Note that the first
version doesn't do any sweep at all, and the last version invariably does
(23463 choose 2) = 275244453 sweeps. The amount of time required to do this
seems to be too low compared to the time that clang-tidy takes to output
these diagnostics.
Also, the fact that all three versions take about the same time is a bit
suspicious, but I double-checked that I was doing it right (I did a small
file with would cause overlapping and I checked if the message "note: this
fix will not be applied because it overlaps with another fix" was there
before each run).

I intended to implement Daniel's idea to check out which one was more
efficient, but with these results in sight I don't think it is worth it.


http://reviews.llvm.org/D13516



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

Re: [PATCH] D13714: [libcxx] Use __config_site to configure the test suite features.

[Jonathan Roelofs via cfe-commits]

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

LGTM


http://reviews.llvm.org/D13714



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

[PATCH] D13731: [RFC][Analyzer] Supporting function attributes in .model files.

[pierre gousseau via cfe-commits]

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

Dear All,

I would like to propose a patch for specifying function attributes in .model 
files to be used by the analyzer checkers.

There are a number of checkers (such as UncheckedReturn) that contain hardcoded 
list of functions, I would like to make these checkers available to a wider 
number of functions by tagging the function definition with appropriate 
attribute information.  I have a situation where we cannot append the function 
attributes to library header files; instead I propose a patch that allows us to 
publish attribute information via .model files. The patch modifies the .model 
file parser to allow for the extraction of function declarations found in the 
.model file.  The UncheckedReturn checker is modified to handle the 
'warn_unused_result' attribute.  Attributes obtained from non-model files are 
still available to the analyzer, and the interface does not try to hide the 
origin of the attribute.

Please can you review this for submission

Regards,

Pierre Gousseau
SN-Systems - Sony Computer Entertainment

http://reviews.llvm.org/D13731

Files:
  include/clang/Analysis/AnalysisContext.h
  include/clang/Analysis/CodeInjector.h
  include/clang/StaticAnalyzer/Frontend/FrontendActions.h
  include/clang/StaticAnalyzer/Frontend/ModelConsumer.h
  lib/Analysis/AnalysisDeclContext.cpp
  lib/Analysis/BodyFarm.cpp
  lib/Analysis/BodyFarm.h
  lib/StaticAnalyzer/Checkers/CheckSecuritySyntaxOnly.cpp
  lib/StaticAnalyzer/Frontend/FrontendActions.cpp
  lib/StaticAnalyzer/Frontend/ModelConsumer.cpp
  lib/StaticAnalyzer/Frontend/ModelInjector.cpp
  lib/StaticAnalyzer/Frontend/ModelInjector.h
  test/Analysis/Inputs/Models/returnNeedsCheckHasModelFile.model
  test/Analysis/unchecked-return.cpp

Index: test/Analysis/unchecked-return.cpp
===
--- /dev/null
+++ test/Analysis/unchecked-return.cpp
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -analyze -analyzer-checker=core,security.insecureAPI.UncheckedReturn -analyzer-config faux-bodies=true,model-path=%S/Inputs/Models %s -verify
+
+int returnNeedsCheckHasModelFile();
+
+int f0() {
+  returnNeedsCheckHasModelFile(); // expected-warning{{The return value from the call to 'returnNeedsCheckHasModelFile' is not checked.}}
+  return 0;
+}
Index: test/Analysis/Inputs/Models/returnNeedsCheckHasModelFile.model
===
--- /dev/null
+++ test/Analysis/Inputs/Models/returnNeedsCheckHasModelFile.model
@@ -0,0 +1 @@
+int returnNeedsCheckHasModelFile() __attribute__((warn_unused_result));
Index: lib/StaticAnalyzer/Frontend/ModelInjector.h
===
--- lib/StaticAnalyzer/Frontend/ModelInjector.h
+++ lib/StaticAnalyzer/Frontend/ModelInjector.h
@@ -45,6 +45,7 @@
   ModelInjector(CompilerInstance );
   Stmt *getBody(const FunctionDecl *D) override;
   Stmt *getBody(const ObjCMethodDecl *D) override;
+  FunctionDecl *getModelDecl(const FunctionDecl *D) override;
 
 private:
   /// \brief Synthesize a body for a declaration
@@ -67,6 +68,9 @@
   // FIXME: double memoization is redundant, with memoization both here and in
   // BodyFarm.
   llvm::StringMap Bodies;
+
+  // Store the model's function declaration if provided.
+  llvm::StringMap Decls;
 };
 }
 }
Index: lib/StaticAnalyzer/Frontend/ModelInjector.cpp
===
--- lib/StaticAnalyzer/Frontend/ModelInjector.cpp
+++ lib/StaticAnalyzer/Frontend/ModelInjector.cpp
@@ -37,6 +37,11 @@
   return Bodies[D->getName()];
 }
 
+FunctionDecl *ModelInjector::getModelDecl(const FunctionDecl *D) {
+  onBodySynthesis(D);
+  return Decls[D->getName()];
+}
+
 void ModelInjector::onBodySynthesis(const NamedDecl *D) {
 
   // FIXME: what about overloads? Declarations can be used as keys but what
@@ -60,6 +65,7 @@
 
   if (!llvm::sys::fs::exists(fileName.str())) {
 Bodies[D->getName()] = nullptr;
+Decls[D->getName()] = nullptr;
 return;
   }
 
@@ -95,7 +101,7 @@
 
   Instance.getPreprocessor().InitializeForModelFile();
 
-  ParseModelFileAction parseModelFile(Bodies);
+  ParseModelFileAction parseModelFile(Bodies, Decls);
 
   const unsigned ThreadStackSize = 8 << 20;
   llvm::CrashRecoveryContext CRC;
Index: lib/StaticAnalyzer/Frontend/ModelConsumer.cpp
===
--- lib/StaticAnalyzer/Frontend/ModelConsumer.cpp
+++ lib/StaticAnalyzer/Frontend/ModelConsumer.cpp
@@ -26,16 +26,20 @@
 using namespace clang;
 using namespace ento;
 
-ModelConsumer::ModelConsumer(llvm::StringMap )
-: Bodies(Bodies) {}
+ModelConsumer::ModelConsumer(llvm::StringMap ,
+ llvm::StringMap )
+: Bodies(Bodies), Decls(Decls) {}
 
 bool ModelConsumer::HandleTopLevelDecl(DeclGroupRef D) {
   for (DeclGroupRef::iterator I = D.begin(), E 

Re: [libcxx] r249738 - Split out of .

[Adrian Prantl via cfe-commits]

To make it easier to find and investigate issues like this, I set up an 
experimental bot on the Green Dragon Jenkins installation on lab.llvm.org that 
builds a stage2 on Darwin with LLVM_ENABLE_MODULES:

  http://lab.llvm.org:8080/green/job/clang-stage2-cmake-modulesRDA/

I’ve configured it to dump the output of the CMake error log to facilitate 
diagnosis:

  
http://lab.llvm.org:8080/green/job/clang-stage2-cmake-modulesRDA_build/5/consoleFull#2020635013e9a0fee5-ebcc-4238-a641-c5aa112c323e

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

r250301 - Intrin.h: implement __emul and __emulu

[Hans Wennborg via cfe-commits]

Author: hans
Date: Wed Oct 14 11:24:28 2015
New Revision: 250301

URL: http://llvm.org/viewvc/llvm-project?rev=250301=rev
Log:
Intrin.h: implement __emul and __emulu

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

Modified: cfe/trunk/lib/Headers/Intrin.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/Intrin.h?rev=250301=250300=250301=diff
==
--- cfe/trunk/lib/Headers/Intrin.h (original)
+++ cfe/trunk/lib/Headers/Intrin.h Wed Oct 14 11:24:28 2015
@@ -432,6 +432,17 @@ __umulh(unsigned __int64 _Multiplier, un
 #endif /* __x86_64__ */
 
 
/**\
+|* Multiplication
+\**/
+static __inline__ __int64 __DEFAULT_FN_ATTRS
+__emul(int __in1, int __in2) {
+  return (__int64)__in1 * (__int64)__in2;
+}
+static __inline__ unsigned __int64 __DEFAULT_FN_ATTRS
+__emulu(unsigned int __in1, unsigned int __in2) {
+  return (unsigned __int64)__in1 * (unsigned __int64)__in2;
+}
+/**\
 |* Bit Twiddling
 
\**/
 static __inline__ unsigned char __DEFAULT_FN_ATTRS


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

Re: [PATCH] D11908: Clang support for -fthinlto.

[Mehdi AMINI via cfe-commits]

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

LGTM


http://reviews.llvm.org/D11908



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

RE: r250173 - Always pass a -dwarf-version argument to integrated as.

[Robinson, Paul via cfe-commits]

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of
> Douglas Katzman via cfe-commits
> Sent: Tuesday, October 13, 2015 9:23 AM
> To: cfe-commits@lists.llvm.org
> Subject: r250173 - Always pass a -dwarf-version argument to integrated as.
> 
> Author: dougk
> Date: Tue Oct 13 11:22:51 2015
> New Revision: 250173
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=250173=rev
> Log:
> Always pass a -dwarf-version argument to integrated as.
> 
> This removes the default of 3 hidden in the assembler previously.
> 
> Fixes breakage caused by r249655, reported by vsukharev.
> 
> Added:
> cfe/trunk/test/Driver/as-default-dwarf.s
> Modified:
> cfe/trunk/lib/Driver/Tools.cpp
> cfe/trunk/tools/driver/cc1as_main.cpp
> 
> Modified: cfe/trunk/lib/Driver/Tools.cpp
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/lib/Driver/Tools.cpp?rev=250173=250172=250173
> =diff
> ==
> 
> --- cfe/trunk/lib/Driver/Tools.cpp (original)
> +++ cfe/trunk/lib/Driver/Tools.cpp Tue Oct 13 11:22:51 2015
> @@ -5632,10 +5632,11 @@ void ClangAs::ConstructJob(Compilation &
>  if (Arg *A = Args.getLastArg(options::OPT_g_Group)) {
>WantDebug = !A->getOption().matches(options::OPT_g0);
>if (WantDebug) {
> -if ((DwarfVersion = DwarfVersionNum(A->getSpelling())) == 0)
> -  DwarfVersion = getToolChain().GetDefaultDwarfVersion();
> +DwarfVersion = DwarfVersionNum(A->getSpelling());
>}

The braces can be removed now that it's a one-liner 'then' clause.
--paulr

>  }
> +if (DwarfVersion == 0)
> +  DwarfVersion = getToolChain().GetDefaultDwarfVersion();
>  RenderDebugEnablingArgs(Args, CmdArgs,
>  (WantDebug ? CodeGenOptions::LimitedDebugInfo
> : CodeGenOptions::NoDebugInfo),
> 
> Added: cfe/trunk/test/Driver/as-default-dwarf.s
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/as-default-
> dwarf.s?rev=250173=auto
> ==
> 
> --- cfe/trunk/test/Driver/as-default-dwarf.s (added)
> +++ cfe/trunk/test/Driver/as-default-dwarf.s Tue Oct 13 11:22:51 2015
> @@ -0,0 +1,15 @@
> +@ REQUIRES: arm-registered-target
> +@ RUN: %clang --target=armv8a--linux-gnueabi -c %s -o %t
> +@ RUN: llvm-objdump -t %t | FileCheck %s
> +.text
> +.type   foo,%function
> +foo:
> +.fnstart
> +.cfi_startproc
> +
> +.Ltmp2:
> +.size   foo, .Ltmp2-foo
> +.cfi_endproc
> +.fnend
> +.cfi_sections .debug_frame
> +@ CHECK: foo
> 
> Modified: cfe/trunk/tools/driver/cc1as_main.cpp
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/tools/driver/cc1as_main.cpp?rev=250173=250172=2501
> 73=diff
> ==
> 
> --- cfe/trunk/tools/driver/cc1as_main.cpp (original)
> +++ cfe/trunk/tools/driver/cc1as_main.cpp Tue Oct 13 11:22:51 2015
> @@ -144,7 +144,7 @@ public:
>  RelaxAll = 0;
>  NoExecStack = 0;
>  FatalWarnings = 0;
> -DwarfVersion = 3;
> +DwarfVersion = 0;
>}
> 
>static bool CreateFromArgs(AssemblerInvocation ,
> 
> 
> ___
> 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

[libcxxabi] r250307 - Add config.project_obj_root to the libc++abi testsuite

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Wed Oct 14 13:20:48 2015
New Revision: 250307

URL: http://llvm.org/viewvc/llvm-project?rev=250307=rev
Log:
Add config.project_obj_root to the libc++abi testsuite

Modified:
libcxxabi/trunk/test/lit.site.cfg.in

Modified: libcxxabi/trunk/test/lit.site.cfg.in
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/test/lit.site.cfg.in?rev=250307=250306=250307=diff
==
--- libcxxabi/trunk/test/lit.site.cfg.in (original)
+++ libcxxabi/trunk/test/lit.site.cfg.in Wed Oct 14 13:20:48 2015
@@ -1,5 +1,6 @@
 @AUTO_GEN_COMMENT@
 config.cxx_under_test   = "@LIBCXXABI_COMPILER@"
+config.project_obj_root = "@CMAKE_BINARY_DIR@"
 config.libcxxabi_src_root   = "@LIBCXXABI_SOURCE_DIR@"
 config.libcxxabi_obj_root   = "@LIBCXXABI_BINARY_DIR@"
 config.abi_library_path = "@LIBCXXABI_LIBRARY_DIR@"


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

Re: [libcxx] r249738 - Split out of .

[Adrian Prantl via cfe-commits]

> On Oct 13, 2015, at 7:43 PM, Richard Smith  wrote:
> 
> On Tue, Oct 13, 2015 at 6:54 PM, Sean Silva  > wrote:
> On Tue, Oct 13, 2015 at 6:14 PM, Richard Smith  > wrote:
> On Tue, Oct 13, 2015 at 5:31 PM, Sean Silva  > wrote:
> On Tue, Oct 13, 2015 at 3:17 PM, Richard Smith via cfe-commits 
> > wrote:
> On Tue, Oct 13, 2015 at 2:10 PM, Adrian Prantl via cfe-commits 
> > wrote:
> Hi Richard,
> 
> this commit appears to break the module self-host on Darwin.
> 
> When compiling the following program generated by clang’s own cmake script:
> 
> > #undef NDEBUG
> > #include 
> > #define NDEBUG
> > #include 
> > int main() { assert(this code is not compiled); }
> 
> with clang++ -std=c++11 -fmodules -fcxx-modules test.cpp
> 
> (You don't need -fcxx-modules here.)
>  
> I get
> 
> > While building module 'std' imported from 
> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
> >  :
> > While building module 'Darwin' imported from 
> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39
> >  :
> > In file included from :98:
> > In file included from 
> > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/wchar.h:92:
> > In file included from 
> > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/_wctype.h:57:
> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/ctype.h:33:10
> >  : fatal 
> > error: cyclic dependency in module 'std': std -> Darwin -> std
> > #include <__config>
> >  ^
> > While building module 'std' imported from 
> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
> >  :
> > In file included from :1:
> > In file included from 
> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/algorithm:624
> >  :
> > In file included from 
> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/initializer_list:47
> >  :
> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:10
> >  : fatal 
> > error: could not build module 'Darwin'
> > #include 
> >  ^
> > In file included from test.cpp:2:
> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:10
> >  : fatal 
> > error: could not build module 'std'
> > #include <__config>
> >  ^
> > 3 errors generated.
> 
> Let me know how I can help in diagnosing what’s going on here.
> 
> OK, I see what's wrong. Is this working any better for you in r250236?
> 
> We're still seeing:
> 
> While building module 'Darwin' imported from /usr/include/assert.h:42:
> While building module 'std' imported from 
> /path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:
> 
> Argh, this is including , which is in the std module. Can you 
> try removing the header "type_traits" line from the libc++ module map and see 
> if that helps?
> 
> I've run into this issue in the past, and I don't think that will fix it (see 
> below). Just to be sure, here is the output with type_traits removed from the 
> module map::
> 
> While building module 'Darwin' imported from /usr/include/assert.h:42:
> While building module 'std' imported from 
> /path/to/build_cmake/stage1/bin/../include/c++/v1/type_traits:211:
> 
> That's an include of . We'd need to apply this workaround to that 
> header too (but I think the buck stops there).

After commenting out the cstddef module as well, the test case compiles again. 
Should I commit that and the type_traits change to libcxx, or are you working 
on a better fix?

-- adrian

> 
> In file included from :1:
> In file included from 
> /path/to/build_cmake/stage1/bin/../include/c++/v1/algorithm:624:
> In file included from 
> /path/to/build_cmake/stage1/bin/../include/c++/v1/initializer_list:47:
> In file included from 
> /path/to/build_cmake/stage1/bin/../include/c++/v1/cstddef:43:
> /path/to/build_cmake/stage1/bin/../include/c++/v1/stddef.h:46:15: fatal 
> error: cyclic dependency in module 'Darwin': Darwin -> 

Re: [PATCH] D13713: [libc++] Stop marking interface symbols always_inline + hidden when building for unstable ABI

[Eric Fiselier via cfe-commits]

EricWF added a comment.

- I would love to have some documentation in libc++ about always-inline, the 
ABI problem it is trying to solve, and how it falls short. Because you tried to 
fix these semantics in clang would you be willing to write up a short summary 
of when always-inline does and doesn't work.
- If this is about always-inline semantics why are we turning off the 
hidden-visibility part of the macro?
- Can you offer other approaches for hiding internal symbols such as helper 
functions.? For example

  inline _LIBCPP_INLINE_VISIBILITY __foo_impl(); // current way.
  static inline _LIBCPP_HIDDEN __foo_impl(); // better way?
  namespace { inline __foo_impl(); } // a (probably bad) possibility



- The test suite speedup is amazing. Is it possible to safely remove the 
`__always_inline__` attribute from functions in the stable ABI configuration?

It seems like always-inline semantics can hurt our users in debug builds and we 
would benefit from drastically reducing its usage. However I need to understand 
exactly what `__always_inline__` buys us in ABI stability before I can make an 
informed decision on changing its usage.


Repository:
  rL LLVM

http://reviews.llvm.org/D13713



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

Re: [PATCH] D13643: [Sema] Warn on ternary comparison

[Matěj Grabovský via cfe-commits]

mgrabovsky added a comment.

In http://reviews.llvm.org/D13643#265976, @aaron.ballman wrote:

> Should there be an exception to this diagnostic for code involving Boolean 
> values? e.g.,
>
> void f(bool a, bool b, bool c) {
>
>   if (a == b == c)
> ;
>
> }
>
> At the very least, it seems like this should also follow GCC's behavior and 
> suggest parenthesis directly.


Interesting. This might be more complex than I had predicted. I'll try to dig 
into GCC's code and see what they do exactly. I can't guarantee returning sane, 
though.

Some thoughts: Even if `a, b, c` are Booleans, what did the user mean by `a == 
b == c`? Do they realise that the compiler interprets it as `(a == b) == c`? 
What about 'type mismatches', i.e. if `a, b` are `int`s, while `b` is `bool` – 
clearly the user must be aware of the interpretation above here. What if `a, b, 
c` are all `int`s – C90 doesn't have Booleans, so it might be intended as 
either.



Comment at: include/clang/Basic/DiagnosticSemaKinds.td:5865
@@ -5864,1 +5864,3 @@
 
+def warn_ternary_comparison : Warning<"ternary comparisons do not work "
+  "as expected">,

aaron.ballman wrote:
> This diagnostic somewhat implies that ?: does not work as expected. I prefer 
> GCC's wording for this:
> 
> "comparisons like 'X<=Y<=Z' do not have their mathematical meaning"
> 
> However, I would love it if we could do one step better and use the same 
> operators the user wrote, if reasonable. ;-)
> This diagnostic somewhat implies that ?: does not work as expected.

?: is a ternary operator but it's not a comparison.

> I prefer GCC's wording for this

I wasn't sure if we wanted to be copycats, but OK.

> would love it if we could do one step better and use the same operators the 
> user wrote

Yes, that would be nice.


http://reviews.llvm.org/D13643



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

Re: [PATCH] D13289: [libc++] Provide additional templates for valarray transcendentals that satisfy the standard synopsis

[Eric Fiselier via cfe-commits]

EricWF added a subscriber: EricWF.
EricWF added reviewers: EricWF, mclow.lists.
EricWF added a comment.

> This is required by the standard and is needed if the user tries to 
> explicitly instantiate the transcendental functions using _Tp, for example, 
> std::abs(int_valarray).


These may in fact be required by the standard but not for the reason you say. 
The standard essentially prohibits users from doing anything with standard 
library functions other than calling them with a list of arguments. This 
includes specifying default template parameters. The relevant text from the 
current C++ draft:

> [17.6.5.4] global.functions`

> 

> 2. A call to a global or non-member function signature described in Clauses 
> 18 through 30 and Annex D shall behave as if the implementation declared no 
> additional global or non-member function signatures


However the overloads you need are required for standard conformance because 
they provide an interface that requires an implicit conversion to 
`valarray` be performed. This subtly changes its ranking in overload 
resolution. For this reason we need this patch.

At first look this patch looks good, and it adds lots of tests which is even 
better.


http://reviews.llvm.org/D13289



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

Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain

[Sean Silva via cfe-commits]

On Tue, Oct 13, 2015 at 11:33 PM, Eric Christopher 
wrote:

> It was already reverted, but I agree, let's get this fixed first.
>

It was reintroduced in r250252. It is breaking
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/1362

-- Sean Silva


>
> Thanks!
>
> -eric
>
> On Tue, Oct 13, 2015 at 11:33 PM Sean Silva  wrote:
>
>> On Tue, Oct 13, 2015 at 7:51 PM, Katya Romanova <
>> katya_roman...@playstation.sony.com> wrote:
>>
>>> kromanova added a comment.
>>>
>>> Hi,
>>>
>>> The initial PS4 patch caused a test failure (debug-options.c) on the PS4
>>> bot. I suspect that I know why the problem happens, but I'm not sure what
>>> will be the best way to handle it. If someone knows how to fix this test
>>> more "elegantly", I would appreciate their advice.
>>>
>>> FAIL: Clang :: Driver/debug-options.c (3509 of 24708)
>>>
>>> - TEST 'Clang :: Driver/debug-options.c' FAILED 
>>>
>>> Script:
>>> ---
>>>
>>> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/clang
>>> -### -c -g
>>> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
>>> -target x86_64-linux-gnu 2>&1  |
>>> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
>>> -check-prefix=G /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-
>>> 
>>>
>>> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/clang
>>> -### -g
>>> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
>>> 2>&1 |
>>> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
>>> -check-prefix=CI
>>> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
>>>
>>> 
>>>
>>> Exit Code: 1
>>>
>>> Command Output (stderr):
>>> 
>>>
>>> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c:139:8:
>>> error: expected string not found in input
>>> // CI: "-dwarf-column-info"
>>>
>>>   ^
>>>
>>> :1:1: note: scanning from here
>>> clang version 3.8.0 (trunk 250262)
>>> ^
>>> :5:438: note: possible intended match here
>>>  
>>> "/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/bin/clang-3.8"
>>> "-cc1" "-triple" "x86_64-scei-ps4" "-emit-obj" "-mrelax-all"
>>> "-disable-free" "-main-file-name" "debug-options.c" "-mrelocation-model"
>>> "pic" "-pic-level" "2" "-mthread-model" "posix" "-mdisable-fp-elim"
>>> "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-target-cpu"
>>> "btver2" "-momit-leaf-frame-pointer" "-debug-info-kind=limited"
>>> "-dwarf-version=4" "-backend-option" "-generate-arange-section"
>>> "-resource-dir"
>>> "/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/bin/../lib/clang/3.8.0"
>>> "-fdebug-compilation-dir"
>>> "/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/clang/test/Driver"
>>> "-ferror-limit" "19" "-fmessage-length" "0" "-stack-protector" "2"
>>> "-fdeclspec" "-fobjc-runtime=gnustep" "-fdiagnostics-show-option" "-o"
>>> "/tmp/debug-options-1505f5.o" "-x" "c"
>>> "/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c"
>>>
>>>
>>>
>>>
>>>
>>>^
>>>
>>> -
>>>
>>> The latest driver patch introduced a change, causing the PS4 driver
>>> *not* to have -gcolumn-info enabled by default.
>>>
>>> Consequently, this generic line started to fail on the PS4 bot.
>>> // RUN: %clang -### -g %s 2>&1 | FileCheck -check-prefix=CI %s
>>>
>>> Does someone know what will be the best way to run the test line for all
>>> the platforms, except PS4?
>>>
>>> In the patch, we have added a couple of PS4 specific lines to this test,
>>> to verify that the behavior on PS4 is correct:
>>>
>>> // RUN: %clang -### -c %s -g -target x86_64-scei-ps4 2>&1 \
>>> // RUN: | FileCheck -check-prefix=NOCI %s
>>>
>>> // RUN: %clang -### -c %s -g -gcolumn-info -target x86_64-scei-ps4 2>&1 \
>>> // RUN: | FileCheck -check-prefix=CI %s
>>>
>>> I do not want to make this test XFAIL for PS4 (though I might do it as
>>> an interim 

Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain

[Eric Christopher via cfe-commits]

On Tue, Oct 13, 2015 at 11:38 PM Sean Silva  wrote:

> On Tue, Oct 13, 2015 at 11:33 PM, Eric Christopher 
> wrote:
>
>> It was already reverted, but I agree, let's get this fixed first.
>>
>
> It was reintroduced in r250252. It is breaking
> http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/1362
>
>
Ah, I missed that. Yeah, please go ahead and revert for now.

Thanks!

-eric


> -- Sean Silva
>
>
>>
>> Thanks!
>>
>> -eric
>>
>> On Tue, Oct 13, 2015 at 11:33 PM Sean Silva 
>> wrote:
>>
>>> On Tue, Oct 13, 2015 at 7:51 PM, Katya Romanova <
>>> katya_roman...@playstation.sony.com> wrote:
>>>
 kromanova added a comment.

 Hi,

 The initial PS4 patch caused a test failure (debug-options.c) on the
 PS4 bot. I suspect that I know why the problem happens, but I'm not sure
 what will be the best way to handle it. If someone knows how to fix this
 test more "elegantly", I would appreciate their advice.

 FAIL: Clang :: Driver/debug-options.c (3509 of 24708)

 - TEST 'Clang :: Driver/debug-options.c' FAILED 

 Script:
 ---

 /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/clang
 -### -c -g
 /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
 -target x86_64-linux-gnu 2>&1  |
 /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
 -check-prefix=G /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-
 

 /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/clang
 -### -g
 /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
 2>&1 |
 /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
 -check-prefix=CI
 /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c

 

 Exit Code: 1

 Command Output (stderr):
 

 /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c:139:8:
 error: expected string not found in input
 // CI: "-dwarf-column-info"

   ^

 :1:1: note: scanning from here
 clang version 3.8.0 (trunk 250262)
 ^
 :5:438: note: possible intended match here
  
 "/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/bin/clang-3.8"
 "-cc1" "-triple" "x86_64-scei-ps4" "-emit-obj" "-mrelax-all"
 "-disable-free" "-main-file-name" "debug-options.c" "-mrelocation-model"
 "pic" "-pic-level" "2" "-mthread-model" "posix" "-mdisable-fp-elim"
 "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-target-cpu"
 "btver2" "-momit-leaf-frame-pointer" "-debug-info-kind=limited"
 "-dwarf-version=4" "-backend-option" "-generate-arange-section"
 "-resource-dir"
 "/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/bin/../lib/clang/3.8.0"
 "-fdebug-compilation-dir"
 "/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/clang/test/Driver"
 "-ferror-limit" "19" "-fmessage-length" "0" "-stack-protector" "2"
 "-fdeclspec" "-fobjc-runtime=gnustep" "-fdiagnostics-show-option" "-o"
 "/tmp/debug-options-1505f5.o" "-x" "c"
 "/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c"





^

 -

 The latest driver patch introduced a change, causing the PS4 driver
 *not* to have -gcolumn-info enabled by default.

 Consequently, this generic line started to fail on the PS4 bot.
 // RUN: %clang -### -g %s 2>&1 | FileCheck -check-prefix=CI %s

 Does someone know what will be the best way to run the test line for
 all the platforms, except PS4?

 In the patch, we have added a couple of PS4 specific lines to this
 test, to verify that the behavior on PS4 is correct:

 // RUN: %clang -### -c %s -g -target x86_64-scei-ps4 2>&1 \
 // RUN: 

Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain

[Sean Silva via cfe-commits]

On Tue, Oct 13, 2015 at 7:51 PM, Katya Romanova <
katya_roman...@playstation.sony.com> wrote:

> kromanova added a comment.
>
> Hi,
>
> The initial PS4 patch caused a test failure (debug-options.c) on the PS4
> bot. I suspect that I know why the problem happens, but I'm not sure what
> will be the best way to handle it. If someone knows how to fix this test
> more "elegantly", I would appreciate their advice.
>
> FAIL: Clang :: Driver/debug-options.c (3509 of 24708)
>
> - TEST 'Clang :: Driver/debug-options.c' FAILED 
>
> Script:
> ---
>
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/clang
> -### -c -g
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
> -target x86_64-linux-gnu 2>&1  |
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
> -check-prefix=G /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-
> 
>
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/clang
> -### -g
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
> 2>&1 |
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
> -check-prefix=CI
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
>
> 
>
> Exit Code: 1
>
> Command Output (stderr):
> 
>
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c:139:8:
> error: expected string not found in input
> // CI: "-dwarf-column-info"
>
>   ^
>
> :1:1: note: scanning from here
> clang version 3.8.0 (trunk 250262)
> ^
> :5:438: note: possible intended match here
>  
> "/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/bin/clang-3.8"
> "-cc1" "-triple" "x86_64-scei-ps4" "-emit-obj" "-mrelax-all"
> "-disable-free" "-main-file-name" "debug-options.c" "-mrelocation-model"
> "pic" "-pic-level" "2" "-mthread-model" "posix" "-mdisable-fp-elim"
> "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-target-cpu"
> "btver2" "-momit-leaf-frame-pointer" "-debug-info-kind=limited"
> "-dwarf-version=4" "-backend-option" "-generate-arange-section"
> "-resource-dir"
> "/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/bin/../lib/clang/3.8.0"
> "-fdebug-compilation-dir"
> "/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/clang/test/Driver"
> "-ferror-limit" "19" "-fmessage-length" "0" "-stack-protector" "2"
> "-fdeclspec" "-fobjc-runtime=gnustep" "-fdiagnostics-show-option" "-o"
> "/tmp/debug-options-1505f5.o" "-x" "c"
> "/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c"
>
>
>
>
>
>  ^
>
> -
>
> The latest driver patch introduced a change, causing the PS4 driver *not*
> to have -gcolumn-info enabled by default.
>
> Consequently, this generic line started to fail on the PS4 bot.
> // RUN: %clang -### -g %s 2>&1 | FileCheck -check-prefix=CI %s
>
> Does someone know what will be the best way to run the test line for all
> the platforms, except PS4?
>
> In the patch, we have added a couple of PS4 specific lines to this test,
> to verify that the behavior on PS4 is correct:
>
> // RUN: %clang -### -c %s -g -target x86_64-scei-ps4 2>&1 \
> // RUN: | FileCheck -check-prefix=NOCI %s
>
> // RUN: %clang -### -c %s -g -gcolumn-info -target x86_64-scei-ps4 2>&1 \
> // RUN: | FileCheck -check-prefix=CI %s
>
> I do not want to make this test XFAIL for PS4 (though I might do it as an
> interim solution). I would also prefer to avoid duplicating most of the
> content of this file into a separate ps4-specific file.
> Any ideas how to handle this issue "more elegantly"?
>
> If nobody objects, I will mark this test as XFAIL for PS4 for a time being.
>

Please revert until you can solve the issue.

-- Sean Silva


>
> Katya.
>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D13482
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain

[Eric Christopher via cfe-commits]

It was already reverted, but I agree, let's get this fixed first.

Thanks!

-eric

On Tue, Oct 13, 2015 at 11:33 PM Sean Silva  wrote:

> On Tue, Oct 13, 2015 at 7:51 PM, Katya Romanova <
> katya_roman...@playstation.sony.com> wrote:
>
>> kromanova added a comment.
>>
>> Hi,
>>
>> The initial PS4 patch caused a test failure (debug-options.c) on the PS4
>> bot. I suspect that I know why the problem happens, but I'm not sure what
>> will be the best way to handle it. If someone knows how to fix this test
>> more "elegantly", I would appreciate their advice.
>>
>> FAIL: Clang :: Driver/debug-options.c (3509 of 24708)
>>
>> - TEST 'Clang :: Driver/debug-options.c' FAILED 
>>
>> Script:
>> ---
>>
>> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/clang
>> -### -c -g
>> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
>> -target x86_64-linux-gnu 2>&1  |
>> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
>> -check-prefix=G /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-
>> 
>>
>> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/clang
>> -### -g
>> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
>> 2>&1 |
>> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
>> -check-prefix=CI
>> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
>>
>> 
>>
>> Exit Code: 1
>>
>> Command Output (stderr):
>> 
>>
>> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c:139:8:
>> error: expected string not found in input
>> // CI: "-dwarf-column-info"
>>
>>   ^
>>
>> :1:1: note: scanning from here
>> clang version 3.8.0 (trunk 250262)
>> ^
>> :5:438: note: possible intended match here
>>  
>> "/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/bin/clang-3.8"
>> "-cc1" "-triple" "x86_64-scei-ps4" "-emit-obj" "-mrelax-all"
>> "-disable-free" "-main-file-name" "debug-options.c" "-mrelocation-model"
>> "pic" "-pic-level" "2" "-mthread-model" "posix" "-mdisable-fp-elim"
>> "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-target-cpu"
>> "btver2" "-momit-leaf-frame-pointer" "-debug-info-kind=limited"
>> "-dwarf-version=4" "-backend-option" "-generate-arange-section"
>> "-resource-dir"
>> "/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/bin/../lib/clang/3.8.0"
>> "-fdebug-compilation-dir"
>> "/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/clang/test/Driver"
>> "-ferror-limit" "19" "-fmessage-length" "0" "-stack-protector" "2"
>> "-fdeclspec" "-fobjc-runtime=gnustep" "-fdiagnostics-show-option" "-o"
>> "/tmp/debug-options-1505f5.o" "-x" "c"
>> "/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c"
>>
>>
>>
>>
>>
>>  ^
>>
>> -
>>
>> The latest driver patch introduced a change, causing the PS4 driver *not*
>> to have -gcolumn-info enabled by default.
>>
>> Consequently, this generic line started to fail on the PS4 bot.
>> // RUN: %clang -### -g %s 2>&1 | FileCheck -check-prefix=CI %s
>>
>> Does someone know what will be the best way to run the test line for all
>> the platforms, except PS4?
>>
>> In the patch, we have added a couple of PS4 specific lines to this test,
>> to verify that the behavior on PS4 is correct:
>>
>> // RUN: %clang -### -c %s -g -target x86_64-scei-ps4 2>&1 \
>> // RUN: | FileCheck -check-prefix=NOCI %s
>>
>> // RUN: %clang -### -c %s -g -gcolumn-info -target x86_64-scei-ps4 2>&1 \
>> // RUN: | FileCheck -check-prefix=CI %s
>>
>> I do not want to make this test XFAIL for PS4 (though I might do it as an
>> interim solution). I would also prefer to avoid duplicating most of the
>> content of this file into a separate ps4-specific file.
>> Any ideas how to handle this issue "more elegantly"?
>>
>> If nobody objects, I will mark this test as XFAIL for PS4 for a time
>> being.
>>
>
> Please revert until you can solve the issue.
>
> -- Sean Silva
>
>
>>
>> 

r250273 - Revert-to-green r250262 (PS4 toolchain patch)

[Sean Silva via cfe-commits]

Author: silvas
Date: Wed Oct 14 01:45:07 2015
New Revision: 250273

URL: http://llvm.org/viewvc/llvm-project?rev=250273=rev
Log:
Revert-to-green r250262 (PS4 toolchain patch)

It is breaking llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast
e.g. 
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/1362

Removed:
cfe/trunk/test/Driver/Inputs/scei-ps4_tree/target/include/.keep
cfe/trunk/test/Driver/Inputs/scei-ps4_tree/target/include_common/.keep
cfe/trunk/test/Driver/no-integrated-as.s
cfe/trunk/test/Driver/ps4-header-search.c
cfe/trunk/test/Driver/ps4-linker-non-win.c
cfe/trunk/test/Driver/ps4-linker-win.c
cfe/trunk/test/Driver/ps4-pic.c
cfe/trunk/test/Driver/ps4-sdk-root.c
Modified:
cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
cfe/trunk/include/clang/Basic/DiagnosticGroups.td
cfe/trunk/lib/Driver/Driver.cpp
cfe/trunk/lib/Driver/ToolChains.cpp
cfe/trunk/lib/Driver/ToolChains.h
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/lib/Driver/Tools.h
cfe/trunk/lib/Frontend/InitHeaderSearch.cpp
cfe/trunk/test/Driver/debug-options.c
cfe/trunk/test/Driver/stack-protector.c

Modified: cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td?rev=250273=250272=250273=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td Wed Oct 14 01:45:07 
2015
@@ -196,18 +196,4 @@ def warn_target_unsupported_nan2008 : Wa
 def warn_target_unsupported_nanlegacy : Warning<
   "ignoring '-mnan=legacy' option because the '%0' architecture does not 
support it">,
   InGroup;
-
-def warn_drv_unable_to_find_directory_expected : Warning<
-  "unable to find %0 directory, expected to be in '%1'">,
-  InGroup, DefaultIgnore;
-
-def warn_drv_ps4_force_pic : Warning<
-  "option '%0' was ignored by the PS4 toolchain, using '-fPIC'">,
-  InGroup;
-
-def warn_drv_ps4_sdk_dir : Warning<
-  "environment variable SCE_PS4_SDK_DIR is set, but points to invalid or 
nonexistent directory '%0'">,
-  InGroup;
-
-def err_drv_unsupported_linker : Error<"unsupported value '%0' for -linker 
option">;
 }

Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticGroups.td?rev=250273=250272=250273=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Wed Oct 14 01:45:07 2015
@@ -823,7 +823,3 @@ def CudaCompat : DiagGroup<"cuda-compat"
 
 // A warning group for things that will change semantics in the future.
 def FutureCompat : DiagGroup<"future-compat">;
-
-def InvalidOrNonExistentDirectory : 
DiagGroup<"invalid-or-nonexistent-directory">;
-
-def OptionIgnored : DiagGroup<"option-ignored">;

Modified: cfe/trunk/lib/Driver/Driver.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=250273=250272=250273=diff
==
--- cfe/trunk/lib/Driver/Driver.cpp (original)
+++ cfe/trunk/lib/Driver/Driver.cpp Wed Oct 14 01:45:07 2015
@@ -2261,9 +2261,6 @@ const ToolChain ::getToolChain(co
 case llvm::Triple::CUDA:
   TC = new toolchains::CudaToolChain(*this, Target, Args);
   break;
-case llvm::Triple::PS4:
-  TC = new toolchains::PS4CPU(*this, Target, Args);
-  break;
 default:
   // Of these targets, Hexagon is the only one that might have
   // an OS of Linux, in which case it got handled above already.

Modified: cfe/trunk/lib/Driver/ToolChains.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp?rev=250273=250272=250273=diff
==
--- cfe/trunk/lib/Driver/ToolChains.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains.cpp Wed Oct 14 01:45:07 2015
@@ -4066,77 +4066,3 @@ void WebAssembly::addClangTargetOptions(
  options::OPT_fno_use_init_array, true))
 CC1Args.push_back("-fuse-init-array");
 }
-
-PS4CPU::PS4CPU(const Driver , const llvm::Triple , const ArgList 
)
-: Generic_ELF(D, Triple, Args) {
-  if (Args.hasArg(options::OPT_static))
-D.Diag(diag::err_drv_unsupported_opt_for_target) << "-static" << "PS4";
-
-  // Determine where to find the PS4 libraries. We use SCE_PS4_SDK_DIR
-  // if it exists; otherwise use the driver's installation path, which
-  // should be /host_tools/bin.
-
-  SmallString<512> PS4SDKDir;
-  if (const char *EnvValue = getenv("SCE_PS4_SDK_DIR")) {
-if (!llvm::sys::fs::exists(EnvValue))
-  getDriver().Diag(clang::diag::warn_drv_ps4_sdk_dir) << EnvValue;
-PS4SDKDir = EnvValue;
-  } else {
-

RE: [PATCH] D13482: Revised Initial patch for PS4 toolchain

[Romanova, Katya via cfe-commits]

Hi Sean,

I don’t think that the whole patch should have been reverted. There were much 
easier way to make the PS4 bot green. A single test could have been marked as 
“XFAIL: ps4” for a few hours until a better solution is implemented. Reverting 
this huge patch is more drastic measure that might cause more problems later.

As you saw in my previous email, I kept an eye on the bots, noticed the failure 
on PS4 buildbot, explained why it happened in the email and ask community for 
an opinion if it could be temporarily marked as “XFAIL” for ps4 only. I had to 
leave work at certain point. When I got home, I saw that you reverted the whole 
fix. Now I will have to go through all the pain with maintaining a huge commit, 
instead of making one line change affecting one of the tests on PS4 platform 
only… But, I guess, if it’s a general practice,  then it’s a different story. I 
was not aware of this practice and I thought that the other solution was much 
more reasonable.

Thank you for letting me know about LLVM_DEFAULT_TARGET_TRIPLE=x86_64-scei-ps4. 
I will definitely run it before the next commit.

Katya.


From: Sean Silva [mailto:chisophu...@gmail.com]
Sent: Tuesday, October 13, 2015 11:56 PM
To: Eric Christopher
Cc: reviews+d13482+public+a1a9627af638c...@reviews.llvm.org; Romanova, Katya; 
Alex Rosenberg; Robinson, Paul; filcab+llvm.phabrica...@gmail.com; Jonathan 
Roelofs; Bedwell, Greg; pierregoussea...@gmail.com; Anton Korobeynikov; Takumi 
NAKAMURA; cfe-commits
Subject: Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain



On Tue, Oct 13, 2015 at 11:40 PM, Eric Christopher 
> wrote:

On Tue, Oct 13, 2015 at 11:38 PM Sean Silva 
> wrote:
On Tue, Oct 13, 2015 at 11:33 PM, Eric Christopher 
> wrote:
It was already reverted, but I agree, let's get this fixed first.

It was reintroduced in r250252. It is breaking 
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/1362


Ah, I missed that. Yeah, please go ahead and revert for now.

reverted in r250273
(bot is back to green: 
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/1363
 )

Katya - remember to run the tests with 
LLVM_DEFAULT_TARGET_TRIPLE=x86_64-scei-ps4 (and also remember to keep an eye on 
the bots after committing)

-- Sean Silva


Thanks!

-eric

-- Sean Silva


Thanks!

-eric

On Tue, Oct 13, 2015 at 11:33 PM Sean Silva 
> wrote:
On Tue, Oct 13, 2015 at 7:51 PM, Katya Romanova 
>
 wrote:
kromanova added a comment.

Hi,

The initial PS4 patch caused a test failure (debug-options.c) on the PS4 bot. I 
suspect that I know why the problem happens, but I'm not sure what will be the 
best way to handle it. If someone knows how to fix this test more "elegantly", 
I would appreciate their advice.

FAIL: Clang :: Driver/debug-options.c (3509 of 24708)

- TEST 'Clang :: Driver/debug-options.c' FAILED 

Script:
---

/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/clang
  -### -c -g 
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
 -target x86_64-linux-gnu 2>&1  | 
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
 -check-prefix=G /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-


/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/clang
  -### -g 
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
 2>&1 | 
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
 -check-prefix=CI 
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c


Exit Code: 1

Command Output (stderr):


/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c:139:8:
 error: expected string not found in input
// CI: "-dwarf-column-info"

  ^

:1:1: note: scanning from here
clang version 3.8.0 (trunk 250262)
^
:5:438: note: possible intended match here
 

Re: [PATCH] D13504: Prevent modernize-use-auto from emitting a warning when 'auto' was already being used.

[Angel Garcia via cfe-commits]

angelgarcia added a comment.

Ping


http://reviews.llvm.org/D13504



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

[clang-tools-extra] r250283 - Support every kind of initialization.

[Angel Garcia Gomez via cfe-commits]

Author: angelgarcia
Date: Wed Oct 14 04:22:32 2015
New Revision: 250283

URL: http://llvm.org/viewvc/llvm-project?rev=250283=rev
Log:
Support every kind of initialization.

Summary: modernize-make-unique now correctly supports the different kinds of 
list initialization.

Reviewers: klimek

Subscribers: cfe-commits, alexfh

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

Modified:
clang-tools-extra/trunk/clang-tidy/modernize/MakeUniqueCheck.cpp
clang-tools-extra/trunk/test/clang-tidy/modernize-make-unique.cpp

Modified: clang-tools-extra/trunk/clang-tidy/modernize/MakeUniqueCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/modernize/MakeUniqueCheck.cpp?rev=250283=250282=250283=diff
==
--- clang-tools-extra/trunk/clang-tidy/modernize/MakeUniqueCheck.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/modernize/MakeUniqueCheck.cpp Wed Oct 14 
04:22:32 2015
@@ -54,8 +54,11 @@ void MakeUniqueCheck::check(const MatchF
   SourceManager  = *Result.SourceManager;
   const auto *Construct =
   Result.Nodes.getNodeAs(ConstructorCall);
-  const auto *New = Result.Nodes.getNodeAs(NewExpression);
   const auto *Type = Result.Nodes.getNodeAs(PointerType);
+  const auto *New = Result.Nodes.getNodeAs(NewExpression);
+
+  if (New->getNumPlacementArgs() != 0)
+return;
 
   SourceLocation ConstructCallStart = Construct->getExprLoc();
 
@@ -86,6 +89,20 @@ void MakeUniqueCheck::check(const MatchF
   CharSourceRange::getCharRange(ConstructCallStart, ConstructCallEnd),
   "std::make_unique");
 
+  // If the unique_ptr is built with brace enclosed direct initialization, use
+  // parenthesis instead.
+  if (Construct->isListInitialization()) {
+SourceRange BraceRange = Construct->getParenOrBraceRange();
+Diag << FixItHint::CreateReplacement(
+CharSourceRange::getCharRange(
+BraceRange.getBegin(), BraceRange.getBegin().getLocWithOffset(1)),
+"(");
+Diag << FixItHint::CreateReplacement(
+CharSourceRange::getCharRange(BraceRange.getEnd(),
+  BraceRange.getEnd().getLocWithOffset(1)),
+")");
+  }
+
   SourceLocation NewStart = New->getSourceRange().getBegin();
   SourceLocation NewEnd = New->getSourceRange().getEnd();
   switch (New->getInitializationStyle()) {
@@ -101,9 +118,30 @@ void MakeUniqueCheck::check(const MatchF
 break;
   }
   case CXXNewExpr::ListInit: {
-SourceRange InitRange = New->getInitializer()->getSourceRange();
+// Range of the substring that we do not want to remove.
+SourceRange InitRange;
+if (const auto *NewConstruct = New->getConstructExpr()) {
+  // Direct initialization with initialization list.
+  //   struct S { S(int x) {} };
+  //   std::unique_ptr(new S{5});
+  // The arguments in the initialization list are going to be forwarded to
+  // the constructor, so this has to be replaced with:
+  //   struct S { S(int x) {} };
+  //   std::make_unique(5);
+  InitRange = SourceRange(
+  NewConstruct->getParenOrBraceRange().getBegin().getLocWithOffset(1),
+  NewConstruct->getParenOrBraceRange().getEnd().getLocWithOffset(-1));
+} else {
+  // Aggregate initialization.
+  //   std::unique_ptr(new Pair{first, second});
+  // Has to be replaced with:
+  //   std::make_unique(Pair{first, second});
+  InitRange = SourceRange(
+  New->getAllocatedTypeSourceInfo()->getTypeLoc().getLocStart(),
+  New->getInitializer()->getSourceRange().getEnd());
+}
 Diag << FixItHint::CreateRemoval(
-SourceRange(NewStart, InitRange.getBegin().getLocWithOffset(-1)));
+CharSourceRange::getCharRange(NewStart, InitRange.getBegin()));
 Diag << FixItHint::CreateRemoval(
 SourceRange(InitRange.getEnd().getLocWithOffset(1), NewEnd));
 break;

Modified: clang-tools-extra/trunk/test/clang-tidy/modernize-make-unique.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/modernize-make-unique.cpp?rev=250283=250282=250283=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/modernize-make-unique.cpp (original)
+++ clang-tools-extra/trunk/test/clang-tidy/modernize-make-unique.cpp Wed Oct 
14 04:22:32 2015
@@ -34,12 +34,22 @@ struct Derived : public Base {
   Derived(int, int);
 };
 
-struct Pair {
+struct APair {
   int a, b;
 };
 
+struct DPair {
+  DPair() : a(0), b(0) {}
+  DPair(int x, int y) : a(y), b(x) {}
+  int a, b;
+};
+
+struct Empty {};
+
 template using unique_ptr_ = std::unique_ptr;
 
+void *operator new(unsigned long Count, void *Ptr);
+
 int g(std::unique_ptr P);
 
 std::unique_ptr getPointer() {
@@ -48,7 +58,7 @@ std::unique_ptr getPointer() {
   // CHECK-FIXES: return std::make_unique();
 }
 
-void f() {
+void basic() {
   std::unique_ptr P1 = 

[clang-tools-extra] r250284 - Prevent modernize-use-auto from emitting a warning when 'auto' was already being used.

[Angel Garcia Gomez via cfe-commits]

Author: angelgarcia
Date: Wed Oct 14 04:29:55 2015
New Revision: 250284

URL: http://llvm.org/viewvc/llvm-project?rev=250284=rev
Log:
Prevent modernize-use-auto from emitting a warning when 'auto' was already 
being used.

Summary: This fixes https://llvm.org/bugs/show_bug.cgi?id=25082 .

Reviewers: bkramer, klimek

Subscribers: cfe-commits, alexfh

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

Modified:
clang-tools-extra/trunk/clang-tidy/modernize/UseAutoCheck.cpp
clang-tools-extra/trunk/test/clang-tidy/modernize-use-auto-new.cpp

Modified: clang-tools-extra/trunk/clang-tidy/modernize/UseAutoCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/modernize/UseAutoCheck.cpp?rev=250284=250283=250284=diff
==
--- clang-tools-extra/trunk/clang-tidy/modernize/UseAutoCheck.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/modernize/UseAutoCheck.cpp Wed Oct 14 
04:29:55 2015
@@ -222,6 +222,9 @@ StatementMatcher makeDeclWithNewMatcher(
  has(varDecl()),
  unless(has(varDecl(anyOf(
  unless(hasInitializer(ignoringParenImpCasts(cxxNewExpr(,
+ // Skip declarations that are already using auto.
+ anyOf(hasType(autoType()),
+   hasType(pointerType(pointee(autoType(),
  // FIXME: TypeLoc information is not reliable where CV
  // qualifiers are concerned so these types can't be
  // handled for now.

Modified: clang-tools-extra/trunk/test/clang-tidy/modernize-use-auto-new.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/modernize-use-auto-new.cpp?rev=250284=250283=250284=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/modernize-use-auto-new.cpp 
(original)
+++ clang-tools-extra/trunk/test/clang-tidy/modernize-use-auto-new.cpp Wed Oct 
14 04:29:55 2015
@@ -95,4 +95,9 @@ void auto_new() {
 // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use auto when initializing 
with new
 // CHECK-FIXES: auto g = new int*, h = new int_p;
   }
+
+  // Don't warn when 'auto' is already being used.
+  auto aut = new MyType();
+  auto *paut = new MyType();
+  const auto *pcaut = new MyType();
 }


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

[PATCH] D13720: Use __SIZE_TYPE__ to fix buildbot failures.

[Angel Garcia via cfe-commits]

angelgarcia created this revision.
angelgarcia added a reviewer: klimek.
angelgarcia added a subscriber: cfe-commits.

Use __SIZE_TYPE__ to fix buildbot failures.

http://reviews.llvm.org/D13720

Files:
  test/clang-tidy/modernize-make-unique.cpp

Index: test/clang-tidy/modernize-make-unique.cpp
===
--- test/clang-tidy/modernize-make-unique.cpp
+++ test/clang-tidy/modernize-make-unique.cpp
@@ -48,7 +48,7 @@
 
 template using unique_ptr_ = std::unique_ptr;
 
-void *operator new(unsigned long Count, void *Ptr);
+void *operator new(__SIZE_TYPE__ Count, void *Ptr);
 
 int g(std::unique_ptr P);
 


Index: test/clang-tidy/modernize-make-unique.cpp
===
--- test/clang-tidy/modernize-make-unique.cpp
+++ test/clang-tidy/modernize-make-unique.cpp
@@ -48,7 +48,7 @@
 
 template using unique_ptr_ = std::unique_ptr;
 
-void *operator new(unsigned long Count, void *Ptr);
+void *operator new(__SIZE_TYPE__ Count, void *Ptr);
 
 int g(std::unique_ptr P);
 
___
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 updated this revision to Diff 37321.
ABataev marked 16 inline comments as done.
ABataev added a comment.

Update after review


http://reviews.llvm.org/D11182

Files:
  include/clang/AST/DataRecursiveASTVisitor.h
  include/clang/AST/DeclBase.h
  include/clang/AST/DeclCXX.h
  include/clang/AST/DeclOpenMP.h
  include/clang/AST/RecursiveASTVisitor.h
  include/clang/Basic/DeclNodes.td
  include/clang/Basic/DiagnosticParseKinds.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/OpenMPKinds.def
  include/clang/Parse/Parser.h
  include/clang/Sema/ScopeInfo.h
  include/clang/Sema/Sema.h
  include/clang/Serialization/ASTBitCodes.h
  lib/AST/CXXInheritance.cpp
  lib/AST/Decl.cpp
  lib/AST/DeclBase.cpp
  lib/AST/DeclOpenMP.cpp
  lib/AST/DeclPrinter.cpp
  lib/AST/ItaniumMangle.cpp
  lib/AST/MicrosoftMangle.cpp
  lib/Basic/OpenMPKinds.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CodeGenModule.cpp
  lib/CodeGen/CodeGenModule.h
  lib/Parse/ParseDecl.cpp
  lib/Parse/ParseDeclCXX.cpp
  lib/Parse/ParseOpenMP.cpp
  lib/Parse/Parser.cpp
  lib/Sema/ScopeInfo.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaLookup.cpp
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  lib/Serialization/ASTCommon.cpp
  lib/Serialization/ASTReaderDecl.cpp
  lib/Serialization/ASTWriterDecl.cpp
  test/OpenMP/declare_reduction_ast_print.c
  test/OpenMP/declare_reduction_ast_print.cpp
  test/OpenMP/declare_reduction_messages.c
  test/OpenMP/declare_reduction_messages.cpp
  tools/libclang/CIndex.cpp

Index: lib/Serialization/ASTWriterDecl.cpp
===
--- lib/Serialization/ASTWriterDecl.cpp
+++ lib/Serialization/ASTWriterDecl.cpp
@@ -131,6 +131,7 @@
 void VisitObjCPropertyDecl(ObjCPropertyDecl *D);
 void VisitObjCPropertyImplDecl(ObjCPropertyImplDecl *D);
 void VisitOMPThreadPrivateDecl(OMPThreadPrivateDecl *D);
+void VisitOMPDeclareReductionDecl(OMPDeclareReductionDecl *D);
 
 /// Add an Objective-C type parameter list to the given record.
 void AddObjCTypeParamList(ObjCTypeParamList *typeParams) {
@@ -1617,6 +1618,16 @@
   Code = serialization::DECL_OMP_THREADPRIVATE;
 }
 
+void ASTDeclWriter::VisitOMPDeclareReductionDecl(OMPDeclareReductionDecl *D) {
+  VisitNamedDecl(D);
+  Writer.AddSourceLocation(D->getLocStart(), Record);
+  Writer.AddStmt(D->getCombiner());
+  Writer.AddStmt(D->getInitializer());
+  Writer.AddDeclRef(D->getPrevDeclInScope(), Record);
+  Writer.AddTypeRef(D->getType(), Record);
+  Code = serialization::DECL_OMP_DECLARE_REDUCTION;
+}
+
 //===--===//
 // ASTWriter Implementation
 //===--===//
Index: lib/Serialization/ASTReaderDecl.cpp
===
--- lib/Serialization/ASTReaderDecl.cpp
+++ lib/Serialization/ASTReaderDecl.cpp
@@ -349,6 +349,7 @@
 void VisitObjCPropertyDecl(ObjCPropertyDecl *D);
 void VisitObjCPropertyImplDecl(ObjCPropertyImplDecl *D);
 void VisitOMPThreadPrivateDecl(OMPThreadPrivateDecl *D);
+void VisitOMPDeclareReductionDecl(OMPDeclareReductionDecl *D);
 
 /// We've merged the definition \p MergedDef into the existing definition
 /// \p Def. Ensure that \p Def is made visible whenever \p MergedDef is made
@@ -2349,6 +2350,15 @@
   D->setVars(Vars);
 }
 
+void ASTDeclReader::VisitOMPDeclareReductionDecl(OMPDeclareReductionDecl *D) {
+  VisitNamedDecl(D);
+  D->setLocation(Reader.ReadSourceLocation(F, Record, Idx));
+  D->setCombiner(Reader.ReadExpr(F));
+  D->setInitializer(Reader.ReadExpr(F));
+  D->PrevDeclInScope = Reader.ReadDeclID(F, Record, Idx);
+  D->setType(Reader.readType(F, Record, Idx));
+}
+
 //===--===//
 // Attribute Reading
 //===--===//
@@ -2398,7 +2408,8 @@
   isa(D) || 
   isa(D) ||
   isa(D) ||
-  isa(D))
+  isa(D) ||
+  isa(D))
 return true;
   if (VarDecl *Var = dyn_cast(D))
 return Var->isFileVarDecl() &&
@@ -3294,6 +3305,9 @@
   case DECL_OMP_THREADPRIVATE:
 D = OMPThreadPrivateDecl::CreateDeserialized(Context, ID, Record[Idx++]);
 break;
+  case DECL_OMP_DECLARE_REDUCTION:
+D = OMPDeclareReductionDecl::CreateDeserialized(Context, ID);
+break;
   case DECL_EMPTY:
 D = EmptyDecl::CreateDeserialized(Context, ID);
 break;
Index: lib/Serialization/ASTCommon.cpp
===
--- lib/Serialization/ASTCommon.cpp
+++ lib/Serialization/ASTCommon.cpp
@@ -329,6 +329,7 @@
   case Decl::ClassScopeFunctionSpecialization:
   case Decl::Import:
   case Decl::OMPThreadPrivate:
+  case Decl::OMPDeclareReduction:
 return false;
 
   // These indirectly derive from Redeclarable but are not actually
Index: 

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

[Alexey Bataev via cfe-commits]

ABataev marked 40 inline comments as done.
ABataev added a comment.

Richard, thanks for the review! Tried to fix all your comments.



Comment at: include/clang/AST/DeclOpenMP.h:95
@@ +94,3 @@
+/// #pragma omp declare reduction (foo : int,float : omp_out += omp_in)
+/// initializer (omp_priv = 0)
+/// \endcode

rsmith wrote:
> I think automatic formatting has messed up your example. Maybe indent this 
> line a bit more to show it's a continuation of the previous line.
Fixed, thanks


Comment at: include/clang/AST/DeclOpenMP.h:99
@@ +98,3 @@
+/// Here 'omp_out += omp_in' is a combiner and 'omp_priv = 0' is an 
initializer.
+class OMPDeclareReductionDecl : public DeclaratorDecl, public DeclContext {
+private:

rsmith wrote:
> rsmith wrote:
> > OK, then you need to update some parts of class `DeclContext` for this. At 
> > least the comment on that class needs to be updated, and possibly other 
> > parts too.
> Why is this a `DeclaratorDecl` rather than merely a `NamedDecl`? It doesn't 
> have a declarator, or even a type.
Fixed


Comment at: include/clang/AST/DeclOpenMP.h:106
@@ +105,3 @@
+  Stmt *Initializer;
+  /// \brief Reference to the previous declare reduction construct in the same
+  /// scope with the same name. Required for proper templates instantiation if

rsmith wrote:
> The comment doesn't match the name. Does this point to the next or previous 
> declaration? The previous decl would make more sense, since AST nodes are 
> intended to be immutable once created. Storing them in this order will also 
> create problems for template instantiation.
Fixed


Comment at: lib/AST/ASTContext.cpp:8321-8322
@@ -8320,4 +8320,4 @@
   return false;
-  } else if (isa(D))
+  } else if (isa(D) || isa(D))
 return true;
   else

rsmith wrote:
> Can these be forward-declared / used from a different translation unit than 
> their definition? If not, it would seem better to emit them on use rather 
> than emitting them eagerly.
Threadprivates can, but declare reduction can't. Fixed


Comment at: lib/Parse/ParseOpenMP.cpp:86-143
@@ -82,1 +85,60 @@
 
+static DeclarationName parseOpenMPReductionId(Parser ) {
+  DeclarationName Name;
+  const Token  = P.getCurToken();
+  Sema  = P.getActions();
+  switch (Tok.getKind()) {
+  case tok::plus: // '+'
+Name = Actions.getASTContext().DeclarationNames.getIdentifier(
+("+"));
+P.ConsumeToken();
+break;
+  case tok::minus: // '-'
+Name = Actions.getASTContext().DeclarationNames.getIdentifier(
+("-"));
+P.ConsumeToken();
+break;
+  case tok::star: // '*'
+Name = Actions.getASTContext().DeclarationNames.getIdentifier(
+("*"));
+P.ConsumeToken();
+break;
+  case tok::amp: // '&'
+Name = Actions.getASTContext().DeclarationNames.getIdentifier(
+("&"));
+P.ConsumeToken();
+break;
+  case tok::pipe: // '|'
+Name = Actions.getASTContext().DeclarationNames.getIdentifier(
+("|"));
+P.ConsumeToken();
+break;
+  case tok::caret: // '^'
+Name = Actions.getASTContext().DeclarationNames.getIdentifier(
+("^"));
+P.ConsumeToken();
+break;
+  case tok::ampamp: // '&&'
+Name = Actions.getASTContext().DeclarationNames.getIdentifier(
+("&&"));
+P.ConsumeToken();
+break;
+  case tok::pipepipe: // '||'
+Name = Actions.getASTContext().DeclarationNames.getIdentifier(
+("||"));
+P.ConsumeToken();
+break;
+  case tok::identifier: // identifier
+Name = Actions.getASTContext().DeclarationNames.getIdentifier(
+Tok.getIdentifierInfo());
+P.ConsumeToken();
+break;
+  default:
+P.Diag(Tok.getLocation(), diag::err_omp_expected_reduction_identifier);
+P.SkipUntil(tok::colon, tok::r_paren, tok::annot_pragma_openmp_end,
+Parser::StopBeforeMatch);
+break;
+  }
+  return Name;
+}
+

rsmith wrote:
> Mapping the non-identifier operators to `IdentifierInfo`s is not the right 
> approach. These should be a new kind of `DeclarationName` (you could reuse 
> `CXXOperatorName`, but that's a bit of a hack, since that represents a name 
> of the form `operator*`).
Reworked the whole function. I know about CXXOperatorName, but tried to 
simplify future lookup. Actually, I don't think that this is a hack, since 
OpenMP specifies that for non-identifier ops a form of 'operator op' is used.


Comment at: lib/Parse/ParseOpenMP.cpp:171-176
@@ +170,8 @@
+  // Consume ':'.
+  if (Tok.is(tok::colon)) {
+ConsumeAnyToken();
+  } else {
+Diag(Tok.getLocation(), diag::err_expected) << "':'";
+IsCorrect = false;
+  }
+

rsmith wrote:
> Use `ExpectAndConsume(tok::colon)` for this.
Thanks, forgot about this function.


Comment at: lib/Parse/ParseOpenMP.cpp:484
@@ +483,3 @@
+}
+

Re: [PATCH] D13504: Prevent modernize-use-auto from emitting a warning when 'auto' was already being used.

[Manuel Klimek via cfe-commits]

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

lg


http://reviews.llvm.org/D13504



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

Re: [PATCH] D13289: [libc++] Provide additional templates for valarray transcendentals that satisfy the standard synopsis

[Eric Fiselier via cfe-commits]

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

One thing does need to change though. For each overload you added you need to 
change all of the uses of `__is_val_expr` in the original overload to a new 
metafunction that only accepts `__val_expr` templates and not `valarray`.

I'm marking as "changes requested" so phabricator properly bins this. Thanks 
again for the patch.


http://reviews.llvm.org/D13289



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

r250278 - [CMake] Add LLVM_VERSION_PATCH to the -current_version flag for libclang.

[Chris Bieneman via cfe-commits]

Author: cbieneman
Date: Wed Oct 14 02:50:47 2015
New Revision: 250278

URL: http://llvm.org/viewvc/llvm-project?rev=250278=rev
Log:
[CMake] Add LLVM_VERSION_PATCH to the -current_version flag for libclang.

This is to match autoconf where LLVM_SUBMIT_SUBVERSION is usually set to 
${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH}.

Modified:
cfe/trunk/tools/libclang/CMakeLists.txt

Modified: cfe/trunk/tools/libclang/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/libclang/CMakeLists.txt?rev=250278=250277=250278=diff
==
--- cfe/trunk/tools/libclang/CMakeLists.txt (original)
+++ cfe/trunk/tools/libclang/CMakeLists.txt Wed Oct 14 02:50:47 2015
@@ -111,7 +111,7 @@ if(ENABLE_SHARED)
 
   if(APPLE)
 set(LIBCLANG_LINK_FLAGS " -Wl,-compatibility_version -Wl,1")
-set(LIBCLANG_LINK_FLAGS "${LIBCLANG_LINK_FLAGS} -Wl,-current_version 
-Wl,${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}")
+set(LIBCLANG_LINK_FLAGS "${LIBCLANG_LINK_FLAGS} -Wl,-current_version 
-Wl,${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH}")
 
 set_property(TARGET libclang APPEND_STRING PROPERTY
  LINK_FLAGS ${LIBCLANG_LINK_FLAGS})


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

[libcxx] r250279 - Fix GCC atomic implementation in C++03

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Wed Oct 14 03:36:22 2015
New Revision: 250279

URL: http://llvm.org/viewvc/llvm-project?rev=250279=rev
Log:
Fix GCC atomic implementation in C++03

Modified:
libcxx/trunk/include/atomic

Modified: libcxx/trunk/include/atomic
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/atomic?rev=250279=250278=250279=diff
==
--- libcxx/trunk/include/atomic (original)
+++ libcxx/trunk/include/atomic Wed Oct 14 03:36:22 2015
@@ -552,7 +552,12 @@ typedef enum memory_order
 namespace __gcc_atomic {
 template 
 struct __gcc_atomic_t {
-  __gcc_atomic_t() _NOEXCEPT {}
+  _LIBCPP_INLINE_VISIBILITY
+#ifndef _LIBCPP_HAS_NO_DEFAULTED_FUNCTIONS
+__gcc_atomic_t() _NOEXCEPT = default;
+#else
+__gcc_atomic_t() _NOEXCEPT : __a_value() {}
+#endif // _LIBCPP_HAS_NO_DEFAULTED_FUNCTIONS
   _LIBCPP_CONSTEXPR explicit __gcc_atomic_t(_Tp value) _NOEXCEPT
 : __a_value(value) {}
   _Tp __a_value;
@@ -573,7 +578,7 @@ struct __can_assign {
   sizeof(__test_atomic_assignable<_Tp, _Td>(1)) == sizeof(char);
 };
 
-static inline constexpr int __to_gcc_order(memory_order __order) {
+static inline _LIBCPP_CONSTEXPR int __to_gcc_order(memory_order __order) {
   // Avoid switch statement to make this a constexpr.
   return __order == memory_order_relaxed ? __ATOMIC_RELAXED:
  (__order == memory_order_acquire ? __ATOMIC_ACQUIRE:
@@ -583,7 +588,7 @@ static inline constexpr int __to_gcc_ord
   __ATOMIC_CONSUME;
 }
 
-static inline constexpr int __to_gcc_failure_order(memory_order __order) {
+static inline _LIBCPP_CONSTEXPR int __to_gcc_failure_order(memory_order 
__order) {
   // Avoid switch statement to make this a constexpr.
   return __order == memory_order_relaxed ? __ATOMIC_RELAXED:
  (__order == memory_order_acquire ? __ATOMIC_ACQUIRE:


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

Re: [PATCH] D13590: Support every kind of initialization.

[Angel Garcia via cfe-commits]

angelgarcia updated this revision to Diff 37322.
angelgarcia added a comment.

Remove \code and \endcode.


http://reviews.llvm.org/D13590

Files:
  clang-tidy/modernize/MakeUniqueCheck.cpp
  test/clang-tidy/modernize-make-unique.cpp

Index: test/clang-tidy/modernize-make-unique.cpp
===
--- test/clang-tidy/modernize-make-unique.cpp
+++ test/clang-tidy/modernize-make-unique.cpp
@@ -34,21 +34,31 @@
   Derived(int, int);
 };
 
-struct Pair {
+struct APair {
   int a, b;
 };
 
+struct DPair {
+  DPair() : a(0), b(0) {}
+  DPair(int x, int y) : a(y), b(x) {}
+  int a, b;
+};
+
+struct Empty {};
+
 template using unique_ptr_ = std::unique_ptr;
 
+void *operator new(unsigned long Count, void *Ptr);
+
 int g(std::unique_ptr P);
 
 std::unique_ptr getPointer() {
   return std::unique_ptr(new Base);
   // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: use std::make_unique instead
   // CHECK-FIXES: return std::make_unique();
 }
 
-void f() {
+void basic() {
   std::unique_ptr P1 = std::unique_ptr(new int());
   // CHECK-MESSAGES: :[[@LINE-1]]:29: warning: use std::make_unique instead [modernize-make-unique]
   // CHECK-FIXES: std::unique_ptr P1 = std::make_unique();
@@ -78,24 +88,76 @@
   // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: use std::make_unique instead
   // CHECK-FIXES: int T = g(std::make_unique());
 
-  // Arguments are correctly handled.
-  std::unique_ptr Pbase = std::unique_ptr(new Base(5, T));
-  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning: use std::make_unique instead
-  // CHECK-FIXES: std::unique_ptr Pbase = std::make_unique(5, T);
-
-  // Works with init lists.
-  std::unique_ptr Ppair = std::unique_ptr(new Pair{T, 1});
-  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning: use std::make_unique instead
-  // CHECK-FIXES: std::unique_ptr Ppair = std::make_unique({T, 1});
-
   // Only replace if the type in the template is the same than the type returned
   // by the new operator.
   auto Pderived = std::unique_ptr(new Derived());
 
   // The pointer is returned by the function, nothing to do.
   std::unique_ptr RetPtr = getPointer();
 
-  // Aliases.
+  // This emulates std::move.
+  std::unique_ptr Move = static_cast(P1);
+
+  // Placemenet arguments should not be removed.
+  int *PInt = new int;
+  std::unique_ptr Placement = std::unique_ptr(new (PInt) int{3});
+}
+
+void initialization(int T, Base b) {
+  // Test different kinds of initialization of the pointee.
+
+  // Direct initialization with parenthesis.
+  std::unique_ptr PDir1 = std::unique_ptr(new DPair(1, T));
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning: use std::make_unique instead
+  // CHECK-FIXES: std::unique_ptr PDir1 = std::make_unique(1, T);
+
+  // Direct initialization with braces.
+  std::unique_ptr PDir2 = std::unique_ptr(new DPair{2, T});
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning: use std::make_unique instead
+  // CHECK-FIXES: std::unique_ptr PDir2 = std::make_unique(2, T);
+
+  // Aggregate initialization.
+  std::unique_ptr PAggr = std::unique_ptr(new APair{T, 1});
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning: use std::make_unique instead
+  // CHECK-FIXES: std::unique_ptr PAggr = std::make_unique(APair{T, 1});
+
+
+  // Test different kinds of initialization of the pointee, when the unique_ptr
+  // is initialized with braces.
+
+  // Direct initialization with parenthesis.
+  std::unique_ptr PDir3 = std::unique_ptr{new DPair(3, T)};
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning: use std::make_unique instead
+  // CHECK-FIXES: std::unique_ptr PDir3 = std::make_unique(3, T);
+
+  // Direct initialization with braces.
+  std::unique_ptr PDir4 = std::unique_ptr{new DPair{4, T}};
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning: use std::make_unique instead
+  // CHECK-FIXES: std::unique_ptr PDir4 = std::make_unique(4, T);
+
+  // Aggregate initialization.
+  std::unique_ptr PAggr2 = std::unique_ptr{new APair{T, 2}};
+  // CHECK-MESSAGES: :[[@LINE-1]]:35: warning: use std::make_unique instead
+  // CHECK-FIXES: std::unique_ptr PAggr2 = std::make_unique(APair{T, 2});
+
+
+  // Direct initialization with parenthesis, without arguments.
+  std::unique_ptr PDir5 = std::unique_ptr(new DPair());
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning: use std::make_unique instead
+  // CHECK-FIXES: std::unique_ptr PDir5 = std::make_unique();
+
+  // Direct initialization with braces, without arguments.
+  std::unique_ptr PDir6 = std::unique_ptr(new DPair{});
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning: use std::make_unique instead
+  // CHECK-FIXES: std::unique_ptr PDir6 = std::make_unique();
+
+  // Aggregate initialization without arguments.
+  std::unique_ptr PEmpty = std::unique_ptr(new Empty{});
+  // CHECK-MESSAGES: :[[@LINE-1]]:35: warning: use std::make_unique instead
+  // CHECK-FIXES: std::unique_ptr PEmpty = std::make_unique(Empty{});
+}
+
+void aliases() {
   typedef std::unique_ptr IntPtr;
   IntPtr Typedef = IntPtr(new int);
   // 

Re: [PATCH] D13516: Fix overlapping replacements in clang-tidy.

[Angel Garcia via cfe-commits]

angelgarcia added a comment.

> These need to be documented.


Done.

> I'd name this Queue instead (reading later I had no idea what this was).


Done.

> Why are you calling this "Sit"?


I didn't even know how to describe this variable without using examples,
and naming it is harder. More or less, it keeps track of the different
overlapping situations that have been spotted during the process, so "Sit"
stands for that. But I know it is a really poor name and I'd like to change
it, any ideas?

Why do we need to sort?

> 


It's a remnant of a different approach that I tried before. Removed.


http://reviews.llvm.org/D13516



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

Re: [PATCH] D13739: [libcxx] Make libc++.so a linker script by default on most platforms.

[Christopher Bergström via cfe-commits]

cbergstrom added a comment.

‎And does this hardcode the abi and break cxxrt? It's not just me who uses that 

  Original Message  
From: Eric Fiselier
Sent: Thursday, October 15, 2015 03:26
To: e...@efcs.ca; mclow.li...@gmail.com; jonat...@codesourcery.com; 
danalb...@google.com; compn...@compnerd.org
Reply To: 
reviews+http://reviews.llvm.org/d13739+public+524ebe3e6873e...@reviews.llvm.org
Cc: ema...@freebsd.org; renato.go...@linaro.org; cbergst...@pathscale.com; 
cfe-commits@lists.llvm.org
Subject: [PATCH] http://reviews.llvm.org/D13739: [libcxx] Make libc++.so a 
linker script by default on most platforms.

EricWF created this revision.
EricWF added reviewers: mclow.lists, jroelofs, danalbert, compnerd.
EricWF added subscribers: cfe-commits, cbergstrom, rengolin, emaste.

This patch turns on `LIBCXX_ENABLE_ABI_LINKER_SCRIPT` by default whenever 
`LLVM_HAVE_LINK_VERSION_SCRIPT` is ON. This turns out to be whenever:

1. WIN32 is not defined.

2 UNIX is defined.

3. APPLE is not defined.

While `LLVM_HAVE_LINK_VERSION_SCRIPT` is meant to reflect exactly what we are 
asking I think it's close enough.

After committing this patch Linux users will no longer have to use "-lc++abi" 
explicitly!

http://reviews.llvm.org/D13739

Files:
CMakeLists.txt
cmake/Modules/HandleOutOfTreeLLVM.cmake
docs/BuildingLibcxx.rst
docs/UsingLibcxx.rst


http://reviews.llvm.org/D13739



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

[libcxxabi] r250316 - Fix LIBCXXABI_HAS_NO_THREADS configuration.

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Wed Oct 14 14:21:38 2015
New Revision: 250316

URL: http://llvm.org/viewvc/llvm-project?rev=250316=rev
Log:
Fix LIBCXXABI_HAS_NO_THREADS configuration.

Modified:
libcxxabi/trunk/test/libcxxabi/test/config.py

Modified: libcxxabi/trunk/test/libcxxabi/test/config.py
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/test/libcxxabi/test/config.py?rev=250316=250315=250316=diff
==
--- libcxxabi/trunk/test/libcxxabi/test/config.py (original)
+++ libcxxabi/trunk/test/libcxxabi/test/config.py Wed Oct 14 14:21:38 2015
@@ -28,8 +28,10 @@ class Configuration(LibcxxConfiguration)
 def configure_compile_flags(self):
 self.cxx.compile_flags += ['-DLIBCXXABI_NO_TIMER']
 self.cxx.compile_flags += ['-funwind-tables']
-super(Configuration, self).configure_compile_flags()
-
+if not self.get_lit_bool('enable_threads', True):
+self.cxx.compile_flags += ['-DLIBCXXABI_HAS_NO_THREADS=1']
+super(Configuration, self).configure_compile_flags()
+
 def configure_compile_flags_header_includes(self):
 self.configure_config_site_header()
 cxx_headers = self.get_lit_conf(
@@ -54,12 +56,6 @@ class Configuration(LibcxxConfiguration)
 def configure_compile_flags_rtti(self):
 pass
 
-def configure_compile_flags_no_threads(self):
-self.cxx.compile_flags += ['-DLIBCXXABI_HAS_NO_THREADS=1']
-
-def configure_compile_flags_no_monotonic_clock(self):
-pass
-
 # TODO(ericwf): Remove this. This is a hack for OS X.
 # libc++ *should* export all of the symbols found in libc++abi on OS X.
 # For this reason LibcxxConfiguration will not link libc++abi in OS X.


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

Re: [Diffusion] rL244063: Add missing atomic libcall support.

[Dimitry Andric via cfe-commits]

dim added a subscriber: dim.
dim added auditors: 3.7-release, cfe-commits, tstellarAMD, jyknight, compnerd, 
majnemer.
dim added a comment.

This is a change that was required to be able to use clang 3.7.0 for FreeBSD on 
arm.  Please merge this to the 3.7 branch.  (I already mailed this to James 
earlier, and he said it looked good to him.)


Users:
  jyknight (Author, Auditor)
  3.7-release (Auditor)
  cfe-commits (Auditor)
  tstellarAMD (Auditor)
  compnerd (Auditor)
  majnemer (Auditor)

http://reviews.llvm.org/rL244063



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

[libcxx] r250319 - [libcxx] Make it drastically simpler to link libc++.

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Wed Oct 14 14:54:03 2015
New Revision: 250319

URL: http://llvm.org/viewvc/llvm-project?rev=250319=rev
Log:
[libcxx] Make it drastically simpler to link libc++.

Summary:
Currently on most platforms you have to manually link the c++ abi library used 
with libc++ whenever you use libc++. So your typical libc++ command like 
invocation might look like:

```
clang++ -stdlib=libc++ foo.cpp -lc++abi
```

Having to manually link `libc++abi.so` makes it harder for libc++ to be used 
generically. This patch fixes that by generating a linker script for 
`libc++.so` that correctly links the ABI library. On linux the linker script 
for libc++abi would look like:

```
# libc++.so
INPUT(libc++.so.1 -lc++abi)
```

With the linker script you can now use libc++ using only `-stdlib=libc++`. This 
is the technique that is used on FreeBSD in ordered to link cxxrt and I think 
it's the best approach to make our users lives simpler.

The CMake option used to enable this is `LIBCXX_ENABLE_ABI_LINKER_SCRIPT`. In 
future I would like to enable this by default on all platforms except for 
Darwin.

Reviewers: mclow.lists, danalbert, rsmith, jroelofs, EricWF

Subscribers: cfe-commits

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

Added:
libcxx/trunk/utils/gen_link_script/
libcxx/trunk/utils/gen_link_script/gen_link_script.py   (with props)
Modified:
libcxx/trunk/CMakeLists.txt
libcxx/trunk/lib/CMakeLists.txt
libcxx/trunk/test/CMakeLists.txt

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=250319=250318=250319=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Wed Oct 14 14:54:03 2015
@@ -69,6 +69,11 @@ set_property(CACHE LIBCXX_CXX_ABI PROPER
 
 option(LIBCXX_ENABLE_STATIC_ABI_LIBRARY "Statically link the ABI library" OFF)
 
+# Generate and install a linker script inplace of libc++.so. The linker script
+# will link libc++ to the correct ABI library.
+option(LIBCXX_ENABLE_ABI_LINKER_SCRIPT
+  "Use and install a linker script for the given ABI library" OFF)
+
 # Build libc++abi with libunwind. We need this option to determine whether to
 # link with libunwind or libgcc_s while running the test cases.
 option(LIBCXXABI_USE_LLVM_UNWINDER "Build and use the LLVM unwinder." OFF)
@@ -153,6 +158,21 @@ if (LIBCXX_ENABLE_STATIC_ABI_LIBRARY)
   endif()
 endif()
 
+if (LIBCXX_ENABLE_ABI_LINKER_SCRIPT)
+if (APPLE)
+  message(FATAL_ERROR "LIBCXX_ENABLE_ABI_LINKER_SCRIPT cannot be used on 
APPLE targets")
+endif()
+if (NOT PYTHONINTERP_FOUND)
+  message(FATAL_ERROR "LIBCXX_ENABLE_ABI_LINKER_SCRIPT requires python but 
it was not found.")
+endif()
+endif()
+
+if (LIBCXX_ENABLE_STATIC_ABI_LIBRARY AND LIBCXX_ENABLE_ABI_LINKER_SCRIPT)
+message(FATAL_ERROR "Conflicting options given.
+LIBCXX_ENABLE_STATIC_ABI_LIBRARY cannot be specified with
+LIBCXX_ENABLE_ABI_LINKER_SCRIPT")
+endif()
+
 
#===
 # Configure System
 
#===

Modified: libcxx/trunk/lib/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/lib/CMakeLists.txt?rev=250319=250318=250319=diff
==
--- libcxx/trunk/lib/CMakeLists.txt (original)
+++ libcxx/trunk/lib/CMakeLists.txt Wed Oct 14 14:54:03 2015
@@ -133,11 +133,40 @@ set_target_properties(cxx
 SOVERSION "${LIBCXX_ABI_VERSION}"
   )
 
+# Generate a linker script inplace of a libc++.so symlink. Rerun this command
+# after cxx builds.
+if (LIBCXX_ENABLE_ABI_LINKER_SCRIPT)
+  # Get the name of the ABI library and handle the case where CXXABI_LIBNAME
+  # is a target name and not a library. Ex cxxabi_shared.
+  set(SCRIPT_ABI_LIBNAME "${CXXABI_LIBNAME}")
+  if (SCRIPT_ABI_LIBNAME STREQUAL "cxxabi_shared")
+set("${SCRIPT_ABI_LIBNAME}" "c++abi")
+  endif()
+  # Generate a linker script inplace of a libc++.so symlink. Rerun this command
+  # after cxx builds.
+  add_custom_command(TARGET cxx POST_BUILD
+COMMAND
+  ${PYTHON_EXECUTABLE} 
${LIBCXX_SOURCE_DIR}/utils/gen_link_script/gen_link_script.py
+ARGS
+  "$"
+  "${SCRIPT_ABI_LIBNAME}"
+WORKING_DIRECTORY ${LIBCXX_BUILD_DIR}
+  )
+endif()
+
+
 if (LIBCXX_INSTALL_LIBRARY)
   install(TARGETS cxx
 LIBRARY DESTINATION lib${LIBCXX_LIBDIR_SUFFIX} COMPONENT libcxx
 ARCHIVE DESTINATION lib${LIBCXX_LIBDIR_SUFFIX} COMPONENT libcxx
 )
+  # NOTE: This install command must go after the cxx install command otherwise
+  # it will not be executed after the library symlinks are installed.
+  if (LIBCXX_ENABLE_ABI_LINKER_SCRIPT)
+install(FILES "$"
+  DESTINATION lib${LIBCXX_LIBDIR_SUFFIX}
+  COMPONENT libcxx)
+  endif()
 endif()
 
 if (NOT 

[libcxx] r250323 - Update testing guide for libc++

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Wed Oct 14 15:44:44 2015
New Revision: 250323

URL: http://llvm.org/viewvc/llvm-project?rev=250323=rev
Log:
Update testing guide for libc++

Modified:
libcxx/trunk/docs/TestingLibcxx.rst

Modified: libcxx/trunk/docs/TestingLibcxx.rst
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/docs/TestingLibcxx.rst?rev=250323=250322=250323=diff
==
--- libcxx/trunk/docs/TestingLibcxx.rst (original)
+++ libcxx/trunk/docs/TestingLibcxx.rst Wed Oct 14 15:44:44 2015
@@ -18,7 +18,6 @@ Please see the `Lit Command Guide`_ for
 
 .. _LIT Command Guide: http://llvm.org/docs/CommandGuide/lit.html
 
-
 Setting up the Environment
 --
 
@@ -38,6 +37,52 @@ LIT.
 
  $ export LIBCXX_SITE_CONFIG=path/to/build-libcxx/test/lit.site.cfg
 
+Example Usage
+-
+
+Once you have your environment set up and you have built libc++ you can run
+parts of the libc++ test suite by simply running `lit` on a specified test or
+directory. For example:
+
+.. code-block:: bash
+
+  $ cd path/to/src/libcxx
+  $ lit -sv test/std/re # Run all of the std::regex tests
+  $ lit -sv test/std/depr/depr.c.headers/stdlib_h.pass.cpp # Run a single test
+  $ lit -sv test/std/atomics test/std/threads # Test std::thread and 
std::atomic
+
+Sometimes you'll want to change the way LIT is running the tests. Custom 
options
+can be specified using the `--param==` flag. The most common option
+you'll want to change is the standard dialect (ie -std=c++XX). By default the
+test suite will select the newest C++ dialect supported by the compiler and use
+that. However if you want to manually specify the option like so:
+
+.. code-block:: bash
+
+  $ lit -sv test/std/containers # Run the tests with the newest -std
+  $ lit -sv --param=std=c++03 test/std/containers # Run the tests in C++03
+
+Occasionally you'll want to add extra compile or link flags when testing.
+You can do this as follows:
+
+.. code-block:: bash
+
+  $ lit -sv --param=compile_flags='-Wcustom-warning'
+  $ lit -sv --param=link_flags='-L/custom/library/path'
+
+Some other common examples include:
+
+.. code-block:: bash
+
+  # Specify a custom compiler.
+  $ lit -sv --param=cxx_under_test=/opt/bin/g++ test/std
+
+  # Enable warnings in the test suite
+  $ lit -sv --param=enable_warnings=true test/std
+
+  # Use UBSAN when running the tests.
+  $ lit -sv --param=use_sanitizer=Undefined
+
 
 LIT Options
 ===
@@ -53,6 +98,16 @@ configuration. Passing the option on the
 
 .. program:: lit
 
+.. option:: cxx_under_test=
+
+  Specify the compiler used to build the tests.
+
+.. option:: std=
+
+  **Values**: c++98, c++03, c++11, c++14, c++1z
+
+  Change the standard version used when building the tests.
+
 .. option:: libcxx_site_config=
 
   Specify the site configuration to use when running the tests.  This option
@@ -100,12 +155,6 @@ configuration. Passing the option on the
 
   Specify additional link flags as a space delimited string.
 
-.. option:: std=
-
-  **Values**: c++98, c++03, c++11, c++14, c++1z
-
-  Change the standard version used when building the tests.
-
 .. option:: debug_level=
 
   **Values**: 0, 1


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

[PATCH] D13739: [libcxx] Make libc++.so a linker script by default on most platforms.

[Eric Fiselier via cfe-commits]

EricWF created this revision.
EricWF added reviewers: mclow.lists, jroelofs, danalbert, compnerd.
EricWF added subscribers: cfe-commits, cbergstrom, rengolin, emaste.

This patch turns on `LIBCXX_ENABLE_ABI_LINKER_SCRIPT` by default whenever 
`LLVM_HAVE_LINK_VERSION_SCRIPT` is ON. This turns out to be whenever:

1. WIN32 is not defined.
2 UNIX is defined.
3. APPLE is not defined.

While `LLVM_HAVE_LINK_VERSION_SCRIPT` is meant to reflect exactly what we are 
asking I think it's close enough.

After committing this patch Linux users will no longer have to use "-lc++abi" 
explicitly!




http://reviews.llvm.org/D13739

Files:
  CMakeLists.txt
  cmake/Modules/HandleOutOfTreeLLVM.cmake
  docs/BuildingLibcxx.rst
  docs/UsingLibcxx.rst

Index: docs/UsingLibcxx.rst
===
--- docs/UsingLibcxx.rst
+++ docs/UsingLibcxx.rst
@@ -54,10 +54,10 @@
 Using libc++ on Linux
 =
 
-On Linux libc++ typically links to a shared version of libc++abi. Unfortunately
-you can't simply run clang with "-stdlib=libc++" as clang is not set up to
-link for this configuration. To get around this you'll have to manually
-link libc++abi yourself. For example:
+On Linux libc++ can typically be used with only '-stdlib=libc++'. However
+some libc++ installations require the user manually link libc++abi themselves.
+If you are running into linker errors when using libc++ try adding "-lc++abi"
+to the link line.  For example:
 
 .. code-block:: bash
 
Index: docs/BuildingLibcxx.rst
===
--- docs/BuildingLibcxx.rst
+++ docs/BuildingLibcxx.rst
@@ -170,6 +170,14 @@
   If this option is enabled, libc++ will try and link the selected ABI library
   statically.
 
+.. option:: LIBCXX_ENABLE_ABI_LINKER_SCRIPT:BOOL
+
+  **Default**: ``OFF`` On Windows and Apple or when
+  ``LIBCXX_ENABLE_STATIC_ABI_LIBRARY`` is specified and ``ON`` otherwise.
+
+  This option generate and installs a linker script as ``libc++.so`` which
+  links the correct ABI library.
+
 .. option:: LIBCXXABI_USE_LLVM_UNWINDER:BOOL
 
   **Default**: ``OFF``
Index: cmake/Modules/HandleOutOfTreeLLVM.cmake
===
--- cmake/Modules/HandleOutOfTreeLLVM.cmake
+++ cmake/Modules/HandleOutOfTreeLLVM.cmake
@@ -109,6 +109,30 @@
 message(STATUS "Sphinx disabled.")
   endif()
 
+  # FIXME - This is cribbed from HandleLLVMOptions.cmake.
+  if(WIN32)
+set(LLVM_HAVE_LINK_VERSION_SCRIPT 0)
+if(CYGWIN)
+  set(LLVM_ON_WIN32 0)
+  set(LLVM_ON_UNIX 1)
+else(CYGWIN)
+  set(LLVM_ON_WIN32 1)
+  set(LLVM_ON_UNIX 0)
+endif(CYGWIN)
+  else(WIN32)
+if(UNIX)
+  set(LLVM_ON_WIN32 0)
+  set(LLVM_ON_UNIX 1)
+  if(APPLE)
+set(LLVM_HAVE_LINK_VERSION_SCRIPT 0)
+  else(APPLE)
+set(LLVM_HAVE_LINK_VERSION_SCRIPT 1)
+  endif(APPLE)
+else(UNIX)
+  MESSAGE(SEND_ERROR "Unable to determine platform")
+endif(UNIX)
+  endif(WIN32)
+
   # Add LLVM Functions 
   include(AddLLVM OPTIONAL)
 endif()
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -67,12 +67,21 @@
 set(CXXABIS none libcxxabi libcxxrt libstdc++ libsupc++)
 set_property(CACHE LIBCXX_CXX_ABI PROPERTY STRINGS ;${CXXABIS})
 
+# Use a static copy of the ABI library when linking libc++. This option
+# cannot be used with LIBCXX_ENABLE_ABI_LINKER_SCRIPT.
 option(LIBCXX_ENABLE_STATIC_ABI_LIBRARY "Statically link the ABI library" OFF)
 
 # Generate and install a linker script inplace of libc++.so. The linker script
-# will link libc++ to the correct ABI library.
+# will link libc++ to the correct ABI library. This option is ON by default
+# On UNIX platforms other than Apple unless 'LIBCXX_ENABLE_STATIC_ABI_LIBRARY'
+# is ON.
+set(DEFAULT_VALUE OFF)
+if (LLVM_HAVE_LINK_VERSION_SCRIPT AND NOT LIBCXX_ENABLE_STATIC_ABI_LIBRARY)
+set(DEFAULT_VALUE ON)
+endif()
+
 option(LIBCXX_ENABLE_ABI_LINKER_SCRIPT
-  "Use and install a linker script for the given ABI library" OFF)
+  "Use and install a linker script for the given ABI library" ${DEFAULT_VALUE})
 
 # Build libc++abi with libunwind. We need this option to determine whether to
 # link with libunwind or libgcc_s while running the test cases.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxxabi] r250313 - Configure for config site header

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Wed Oct 14 14:01:47 2015
New Revision: 250313

URL: http://llvm.org/viewvc/llvm-project?rev=250313=rev
Log:
Configure for config site header

Modified:
libcxxabi/trunk/test/libcxxabi/test/config.py

Modified: libcxxabi/trunk/test/libcxxabi/test/config.py
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/test/libcxxabi/test/config.py?rev=250313=250312=250313=diff
==
--- libcxxabi/trunk/test/libcxxabi/test/config.py (original)
+++ libcxxabi/trunk/test/libcxxabi/test/config.py Wed Oct 14 14:01:47 2015
@@ -31,6 +31,7 @@ class Configuration(LibcxxConfiguration)
 super(Configuration, self).configure_compile_flags()
 
 def configure_compile_flags_header_includes(self):
+self.configure_config_site_header()
 cxx_headers = self.get_lit_conf(
 'cxx_headers',
 os.path.join(self.libcxx_src_root, '/include'))


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

Re: [PATCH] D12508: [libcxx] Make it drastically simpler to link libc++.

[Eric Fiselier via cfe-commits]

EricWF updated this revision to Diff 37376.
EricWF added a comment.

Updating diff so it merges cleanly against master.


http://reviews.llvm.org/D12508

Files:
  CMakeLists.txt
  lib/CMakeLists.txt
  test/CMakeLists.txt
  utils/gen_link_script/gen_link_script.py

Index: utils/gen_link_script/gen_link_script.py
===
--- /dev/null
+++ utils/gen_link_script/gen_link_script.py
@@ -0,0 +1,79 @@
+#!/usr/bin/env python
+import os
+import sys
+
+def print_and_exit(msg):
+sys.stderr.write(msg + '\n')
+sys.exit(1)
+
+def usage_and_exit():
+print_and_exit("Usage: ./gen_link_script.py [--help] [--dryrun]  ")
+
+def help_and_exit():
+help_msg = \
+"""Usage
+
+  gen_link_script.py [--help] [--dryrun]  
+
+  Generate a linker script that links libc++ to the proper ABI library.
+  The script replaces the specified libc++ symlink.
+  An example script for c++abi would look like "INPUT(libc++.so.1 -lc++abi)".
+
+Arguments
+   - The top level symlink to the versioned libc++ shared
+library. This file is replaced with a linker script.
+ - The name of the ABI library to use in the linker script.
+The name must be one of [c++abi, stdc++, supc++, cxxrt].
+
+Exit Status:
+  0 if OK,
+  1 if the action failed.
+"""
+print_and_exit(help_msg)
+
+def parse_args():
+args = list(sys.argv)
+del args[0]
+if len(args) == 0:
+usage_and_exit()
+if args[0] == '--help':
+help_and_exit()
+dryrun = '--dryrun' == args[0]
+if dryrun:
+del args[0]
+if len(args) != 2:
+usage_and_exit()
+symlink_file = args[0]
+abi_libname = args[1]
+return dryrun, symlink_file, abi_libname
+
+def main():
+dryrun, symlink_file, abi_libname = parse_args()
+
+# Check that the given libc++.so file is a valid symlink.
+if not os.path.islink(symlink_file):
+print_and_exit("symlink file %s is not a symlink" % symlink_file)
+
+# Read the symlink so we know what libc++ to link to in the linker script.
+linked_libcxx = os.readlink(symlink_file)
+
+# Check that the abi_libname is one of the supported values.
+supported_abi_list = ['c++abi', 'stdc++', 'supc++', 'cxxrt']
+if abi_libname not in supported_abi_list:
+print_and_exit("abi name '%s' is not supported: Use one of %r" %
+(abi_libname, supported_abi_list))
+
+# Generate the linker script contents and print the script and destination
+# information.
+contents = "INPUT(%s -l%s)" % (linked_libcxx, abi_libname)
+print("GENERATING SCRIPT: '%s' as file %s" % (contents, symlink_file))
+
+# Remove the existing libc++ symlink and replace it with the script.
+if not dryrun:
+os.unlink(symlink_file)
+with open(symlink_file, 'w') as f:
+f.write(contents + "\n")
+
+
+if __name__ == '__main__':
+main()
Index: test/CMakeLists.txt
===
--- test/CMakeLists.txt
+++ test/CMakeLists.txt
@@ -17,10 +17,11 @@
 pythonize_bool(LIBCXXABI_USE_LLVM_UNWINDER)
 
 # The tests shouldn't link to any ABI library when it has been linked into
-# libc++ statically.
-if (LIBCXX_ENABLE_STATIC_ABI_LIBRARY)
+# libc++ statically or via a linker script.
+if (LIBCXX_ENABLE_STATIC_ABI_LIBRARY OR LIBCXX_ENABLE_ABI_LINKER_SCRIPT)
   set(LIBCXX_CXX_ABI_LIBNAME "none")
 endif()
+
 set(LIBCXX_TARGET_INFO "libcxx.test.target_info.LocalTI" CACHE STRING
 "TargetInfo to use when setting up test environment.")
 set(LIBCXX_EXECUTOR "None" CACHE STRING
Index: lib/CMakeLists.txt
===
--- lib/CMakeLists.txt
+++ lib/CMakeLists.txt
@@ -133,11 +133,40 @@
 SOVERSION "${LIBCXX_ABI_VERSION}"
   )
 
+# Generate a linker script inplace of a libc++.so symlink. Rerun this command
+# after cxx builds.
+if (LIBCXX_ENABLE_ABI_LINKER_SCRIPT)
+  # Get the name of the ABI library and handle the case where CXXABI_LIBNAME
+  # is a target name and not a library. Ex cxxabi_shared.
+  set(SCRIPT_ABI_LIBNAME "${CXXABI_LIBNAME}")
+  if (SCRIPT_ABI_LIBNAME STREQUAL "cxxabi_shared")
+set("${SCRIPT_ABI_LIBNAME}" "c++abi")
+  endif()
+  # Generate a linker script inplace of a libc++.so symlink. Rerun this command
+  # after cxx builds.
+  add_custom_command(TARGET cxx POST_BUILD
+COMMAND
+  ${PYTHON_EXECUTABLE} ${LIBCXX_SOURCE_DIR}/utils/gen_link_script/gen_link_script.py
+ARGS
+  "$"
+  "${SCRIPT_ABI_LIBNAME}"
+WORKING_DIRECTORY ${LIBCXX_BUILD_DIR}
+  )
+endif()
+
+
 if (LIBCXX_INSTALL_LIBRARY)
   install(TARGETS cxx
 LIBRARY DESTINATION lib${LIBCXX_LIBDIR_SUFFIX} COMPONENT libcxx
 ARCHIVE DESTINATION lib${LIBCXX_LIBDIR_SUFFIX} COMPONENT libcxx
 )
+  # NOTE: This install command must go after the cxx install command otherwise
+  # it will not be executed after the library symlinks are 

Re: [PATCH] D13739: [libcxx] Make libc++.so a linker script by default on most platforms.

[Jonathan Roelofs via cfe-commits]

jroelofs added inline comments.


Comment at: CMakeLists.txt:71
@@ -70,1 +70,3 @@
+# Use a static copy of the ABI library when linking libc++. This option
+# cannot be used with LIBCXX_ENABLE_ABI_LINKER_SCRIPT.
 option(LIBCXX_ENABLE_STATIC_ABI_LIBRARY "Statically link the ABI library" OFF)

Should probably make this a cmake error, not just have it do something other 
than what you wanted.


Comment at: CMakeLists.txt:76
@@ +75,3 @@
+# will link libc++ to the correct ABI library. This option is ON by default
+# On UNIX platforms other than Apple unless 'LIBCXX_ENABLE_STATIC_ABI_LIBRARY'
+# is ON.

s/On/on/ ?


Comment at: CMakeLists.txt:78
@@ +77,3 @@
+# is ON.
+set(DEFAULT_VALUE OFF)
+if (LLVM_HAVE_LINK_VERSION_SCRIPT AND NOT LIBCXX_ENABLE_STATIC_ABI_LIBRARY)

`DEFAULT_VALUE` seems too generic a name for this... or is this a common CMake 
pattern that I'm unaware of?


Comment at: cmake/Modules/HandleOutOfTreeLLVM.cmake:116
@@ +115,3 @@
+if(CYGWIN)
+  set(LLVM_ON_WIN32 0)
+  set(LLVM_ON_UNIX 1)

Where are `LLVM_ON_WIN32` and `LLVM_ON_UNIX` used?


Comment at: docs/BuildingLibcxx.rst:176
@@ +175,3 @@
+  **Default**: ``OFF`` On Windows and Apple or when
+  ``LIBCXX_ENABLE_STATIC_ABI_LIBRARY`` is specified and ``ON`` otherwise.
+

I find this sentence hard to parse. Maybe phrase it the same way you did in the 
comment: 

"ON by default on UNIX platforms other than Apple unless 
'LIBCXX_ENABLE_STATIC_ABI_LIBRARY' is ON"


Comment at: docs/UsingLibcxx.rst:59
@@ +58,3 @@
+some libc++ installations require the user manually link libc++abi themselves.
+If you are running into linker errors when using libc++ try adding "-lc++abi"
+to the link line.  For example:

Looks like an inconsistent use of `"` vs `'` for `'-stdlib=libc++'` and 
`"-lc++abi"`. I don't have good RST-fu, but that seems fishy.


http://reviews.llvm.org/D13739



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

Re: [libcxx] r249738 - Split out of .

[Adrian Prantl via cfe-commits]

> On Oct 14, 2015, at 3:32 PM, Richard Smith  wrote:
> 
> On Wed, Oct 14, 2015 at 2:03 PM, Adrian Prantl via cfe-commits 
> > wrote:
>> On Oct 14, 2015, at 11:37 AM, Adrian Prantl via cfe-commits 
>> > wrote:
>>> On Oct 13, 2015, at 7:43 PM, Richard Smith >> > wrote:
>>> 
>>> On Tue, Oct 13, 2015 at 6:54 PM, Sean Silva >> > wrote:
>>> On Tue, Oct 13, 2015 at 6:14 PM, Richard Smith >> > wrote:
>>> On Tue, Oct 13, 2015 at 5:31 PM, Sean Silva >> > wrote:
>>> On Tue, Oct 13, 2015 at 3:17 PM, Richard Smith via cfe-commits 
>>> > wrote:
>>> On Tue, Oct 13, 2015 at 2:10 PM, Adrian Prantl via cfe-commits 
>>> > wrote:
>>> Hi Richard,
>>> 
>>> this commit appears to break the module self-host on Darwin.
>>> 
>>> When compiling the following program generated by clang’s own cmake script:
>>> 
>>> > #undef NDEBUG
>>> > #include 
>>> > #define NDEBUG
>>> > #include 
>>> > int main() { assert(this code is not compiled); }
>>> 
>>> with clang++ -std=c++11 -fmodules -fcxx-modules test.cpp
>>> 
>>> (You don't need -fcxx-modules here.)
>>>  
>>> I get
>>> 
>>> > While building module 'std' imported from 
>>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
>>> >  :
>>> > While building module 'Darwin' imported from 
>>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39
>>> >  :
>>> > In file included from :98:
>>> > In file included from 
>>> > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/wchar.h:92:
>>> > In file included from 
>>> > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/_wctype.h:57:
>>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/ctype.h:33:10
>>> >  : 
>>> > fatal error: cyclic dependency in module 'std': std -> Darwin -> std
>>> > #include <__config>
>>> >  ^
>>> > While building module 'std' imported from 
>>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
>>> >  :
>>> > In file included from :1:
>>> > In file included from 
>>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/algorithm:624
>>> >  :
>>> > In file included from 
>>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/initializer_list:47
>>> >  
>>> > :
>>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:10
>>> >  : 
>>> > fatal error: could not build module 'Darwin'
>>> > #include 
>>> >  ^
>>> > In file included from test.cpp:2:
>>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:10
>>> >  : 
>>> > fatal error: could not build module 'std'
>>> > #include <__config>
>>> >  ^
>>> > 3 errors generated.
>>> 
>>> Let me know how I can help in diagnosing what’s going on here.
>>> 
>>> OK, I see what's wrong. Is this working any better for you in r250236?
>>> 
>>> We're still seeing:
>>> 
>>> While building module 'Darwin' imported from /usr/include/assert.h:42:
>>> While building module 'std' imported from 
>>> /path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:
>>> 
>>> Argh, this is including , which is in the std module. Can you 
>>> try removing the header "type_traits" line from the libc++ module map and 
>>> see if that helps?
>>> 
>>> I've run into this issue in the past, and I don't think that will fix it 
>>> (see below). Just to be sure, here is the output with type_traits removed 
>>> from the module map::
>>> 
>>> While building module 'Darwin' imported from /usr/include/assert.h:42:
>>> While building module 'std' imported from 
>>> /path/to/build_cmake/stage1/bin/../include/c++/v1/type_traits:211:
>>> 
>>> That's an include of . We'd need to apply this workaround to that 
>>> header too (but I think the buck stops there).
>> 
>> After commenting out the cstddef 

[libcxx] r250325 - Link to new documentation from existing homepage

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Wed Oct 14 15:51:33 2015
New Revision: 250325

URL: http://llvm.org/viewvc/llvm-project?rev=250325=rev
Log:
Link to new documentation from existing homepage

Modified:
libcxx/trunk/www/index.html

Modified: libcxx/trunk/www/index.html
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/index.html?rev=250325=250324=250325=diff
==
--- libcxx/trunk/www/index.html (original)
+++ libcxx/trunk/www/index.html Wed Oct 14 15:51:33 2015
@@ -43,6 +43,16 @@
  under the MIT license and the UIUC License (a BSD-like license).
 
   
+  New Documentation Coming Soon!
+  
+
+   Looking for documentation on how to use, build and test libc++? If so
+  checkout the new libc++ documentation.
+
+  http://libcxx.llvm.org/docs/;>
+  Click here for the new libc++ documentation.
+
+  
   Features and Goals
   
 


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

Re: [PATCH] D13739: [libcxx] Make libc++.so a linker script by default on most platforms.

[Jonathan Roelofs via cfe-commits]

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

LGTM


http://reviews.llvm.org/D13739



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

Re: [PATCH] D13746: [clang-tidy] add check cppcoreguidelines-pro-bounds-constant-array-index

[Matthias Gehre via cfe-commits]

mgehre updated this revision to Diff 37401.
mgehre added a comment.

Remove dead codet


http://reviews.llvm.org/D13746

Files:
  clang-tidy/cppcoreguidelines/CMakeLists.txt
  clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
  clang-tidy/cppcoreguidelines/ProBoundsConstantArrayIndexCheck.cpp
  clang-tidy/cppcoreguidelines/ProBoundsConstantArrayIndexCheck.h
  docs/clang-tidy/checks/cppcoreguidelines-pro-bounds-constant-array-index.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index.cpp

Index: test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index.cpp
===
--- /dev/null
+++ test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index.cpp
@@ -0,0 +1,68 @@
+// RUN: %python %S/check_clang_tidy.py %s cppcoreguidelines-pro-bounds-constant-array-index %t
+#include 
+
+namespace gsl {
+  template
+  T& at( T()[N], size_t index );
+
+  template
+  T& at( std::array , size_t index );
+}
+
+constexpr int const_index(int base) {
+  return base + 3;
+}
+
+void f(std::array a, int pos) {
+  a[pos / 2] = 1;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: do not use array subscript when the index is not a compile-time constant; use gsl::at() instead [cppcoreguidelines-pro-bounds-constant-array-index]
+  a[pos - 1] = 2;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: do not use array subscript when the index is not a compile-time constant; use gsl::at() instead
+
+  a.at(pos-1) = 2; // OK, at() instead of []
+  gsl::at(a, pos-1) = 2; // OK, gsl::at() instead of []
+
+  a[-1] = 3;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: array index -1 is before the beginning of the array [cppcoreguidelines-pro-bounds-constant-array-index]
+  a[10] = 4;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: array index 10 is past the end of the array (which contains 10 elements) [cppcoreguidelines-pro-bounds-constant-array-index]
+
+  a[const_index(7)] = 3;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: array index 10 is past the end of the array (which contains 10 elements)
+
+  a[0] = 3; // OK, constant index and inside bounds
+  a[1] = 3; // OK, constant index and inside bounds
+  a[9] = 3; // OK, constant index and inside bounds
+  a[const_index(6)] = 3; // OK, constant index and inside bounds
+}
+
+void g() {
+  int a[10];
+  for (int i = 0; i < 10; ++i) {
+a[i] = i;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: do not use array subscript when the index is not a compile-time constant; use gsl::at() instead
+gsl::at(a, i) = i; // OK, gsl::at() instead of []
+  }
+
+  a[-1] = 3;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: array index -1 is before the beginning of the array
+  a[10] = 4;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: array index 10 is past the end of the array (which contains 10 elements)
+  a[const_index(7)] = 3;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: array index 10 is past the end of the array (which contains 10 elements)
+
+  a[0] = 3; // OK, constant index and inside bounds
+  a[1] = 3; // OK, constant index and inside bounds
+  a[9] = 3; // OK, constant index and inside bounds
+  a[const_index(6)] = 3; // OK, constant index and inside bounds
+}
+
+struct S {
+  int& operator[](int i);
+};
+
+void customOperator() {
+  S s;
+  int i = 0;
+  s[i] = 3; // OK, custom operator
+}
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -4,6 +4,7 @@
 .. toctree::
cert-setlongjmp
cert-variadic-function-def
+   cppcoreguidelines-pro-bounds-constant-array-index
cppcoreguidelines-pro-bounds-pointer-arithmetic
cppcoreguidelines-pro-type-const-cast
cppcoreguidelines-pro-type-reinterpret-cast
Index: docs/clang-tidy/checks/cppcoreguidelines-pro-bounds-constant-array-index.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/cppcoreguidelines-pro-bounds-constant-array-index.rst
@@ -0,0 +1,9 @@
+cppcoreguidelines-pro-bounds-constant-array-index
+=
+
+This check flags all array subscriptions on static arrays and std::arrays that either have a non-compile-time constant index or are out of bounds.
+
+Dynamic accesses into arrays are difficult for both tools and humans to validate as safe. array_view is a bounds-checked, safe type for accessing arrays of data. at() is another alternative that ensures single accesses are bounds-checked. If iterators are needed to access an array, use the iterators from an array_view constructed over the array.
+
+This rule is part of the "Bounds safety" profile of the C++ Core Guidelines, see
+https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#-bounds2-only-index-into-arrays-using-constant-expressions
Index: 

Re: [PATCH] D13640: [clang-tidy] Add new check cppcoreguidelines-pro-bounds-array-to-pointer-decay

[Matthias Gehre via cfe-commits]

mgehre updated this revision to Diff 37417.
mgehre marked 7 inline comments as done.
mgehre added a comment.

Matcher does not rely on __range anymore


http://reviews.llvm.org/D13640

Files:
  clang-tidy/cppcoreguidelines/CMakeLists.txt
  clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
  clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp
  clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.h
  docs/clang-tidy/checks/cppcoreguidelines-pro-bounds-array-to-pointer-decay.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp

Index: test/clang-tidy/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp
===
--- /dev/null
+++ test/clang-tidy/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp
@@ -0,0 +1,44 @@
+// RUN: %python %S/check_clang_tidy.py %s cppcoreguidelines-pro-bounds-array-to-pointer-decay %t
+#include 
+
+namespace gsl {
+  template
+  class array_view {
+  public:
+template< class U, size_t N >
+array_view( U ()[N] );
+  };
+}
+
+void pointerfun(int* p);
+void arrayfun(int p[]);
+void arrayviewfun(gsl::array_view );
+size_t s();
+
+void f()
+{
+  int a[5];
+  pointerfun(a);
+  // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: do not (implicitly) convert an array to a pointer; use gsl::array_view instead [cppcoreguidelines-pro-bounds-array-to-pointer-decay]
+  pointerfun((int*)a);
+  // CHECK-MESSAGES: :[[@LINE-1]]:20: warning: do not (implicitly) convert an array to a pointer; use gsl::array_view instead
+  arrayfun(a);
+  // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: do not (implicitly) convert an array to a pointer; use gsl::array_view instead
+
+  pointerfun(a + s() - 10); // Convert to [g() - 10];
+  // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: do not (implicitly) convert an array to a pointer; use gsl::array_view instead
+
+  gsl::array_view av(a);
+  arrayviewfun(av); // OK
+
+  int i = a[0]; // OK
+  pointerfun([0]); // OK
+
+  for(auto  : a ) // OK, iteration internally decays array to pointer
+e = 1;
+}
+
+const char* g()
+{
+return "clang"; // OK, decay string literal to pointer
+}
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -4,6 +4,7 @@
 .. toctree::
cert-setlongjmp
cert-variadic-function-def
+   cppcoreguidelines-pro-bounds-array-to-pointer-decay
cppcoreguidelines-pro-bounds-pointer-arithmetic
cppcoreguidelines-pro-type-const-cast
cppcoreguidelines-pro-type-reinterpret-cast
Index: docs/clang-tidy/checks/cppcoreguidelines-pro-bounds-array-to-pointer-decay.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/cppcoreguidelines-pro-bounds-array-to-pointer-decay.rst
@@ -0,0 +1,9 @@
+cppcoreguidelines-pro-bounds-array-to-pointer-decay
+===
+
+This check flags all array to pointer decays.
+
+Pointers should not be used as arrays. array_view is a bounds-checked, safe alternative to using pointers to access arrays.
+
+This rule is part of the "Bounds safety" profile of the C++ Core Guidelines, see
+https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#-bounds3-no-array-to-pointer-decay
Index: clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.h
===
--- /dev/null
+++ clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.h
@@ -0,0 +1,34 @@
+//===--- ProBoundsArrayToPointerDecayCheck.h - clang-tidy*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_CPPCOREGUIDELINES_PRO_BOUNDS_ARRAY_TO_POINTER_DECAY_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_CPPCOREGUIDELINES_PRO_BOUNDS_ARRAY_TO_POINTER_DECAY_H
+
+#include "../ClangTidy.h"
+
+namespace clang {
+namespace tidy {
+
+/// This check flags all array to pointer decays
+///
+/// For the user-facing documentation see:
+/// http://clang.llvm.org/extra/clang-tidy/checks/cppcoreguidelines-pro-bounds-array-to-pointer-decay.html
+class ProBoundsArrayToPointerDecayCheck : public ClangTidyCheck {
+public:
+  ProBoundsArrayToPointerDecayCheck(StringRef Name, ClangTidyContext *Context)
+  : ClangTidyCheck(Name, Context) {}
+  void registerMatchers(ast_matchers::MatchFinder *Finder) override;
+  void check(const ast_matchers::MatchFinder::MatchResult ) override;
+};
+
+} // namespace tidy
+} // namespace clang
+
+#endif // LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_CPPCOREGUIDELINES_PRO_BOUNDS_ARRAY_TO_POINTER_DECAY_H
+
Index: 

Re: [PATCH] D13739: [libcxx] Make libc++.so a linker script by default on most platforms.

[Eric Fiselier via cfe-commits]

EricWF added a comment.

@cbergstrom After installing libcxxrt I ran the libc++ configuration with 
`-DLIBCXX_CXX_ABI=libcxxrt` and everything worked perfectly. It generated 
libc++.so as `INPUT(libc++.so.1 -lcxxrt)` and after running it against the test 
suite everything works great.


http://reviews.llvm.org/D13739



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

[PATCH] D13746: [clang-tidy] add check cppcoreguidelines-pro-bounds-constant-array-index

[Matthias Gehre via cfe-commits]

mgehre created this revision.
mgehre added reviewers: alexfh, sbenza, bkramer, aaron.ballman.
mgehre added a subscriber: cfe-commits.

This check flags all array subscriptions on static arrays and
std::arrays that either have a non-compile-time-constant index or are
out of bounds.

Dynamic accesses into arrays are difficult for both tools and humans to
validate as safe. array_view is a bounds-checked, safe type for
accessing arrays of data. at() is another alternative that ensures
single accesses are bounds-checked. If iterators are needed to access an
array, use the iterators from an array_view constructed over the array.

This rule is part of the "Bounds safety" profile of the C++ Core
Guidelines, see
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#-bounds2-only-index-into-arrays-using-constant-expressions

http://reviews.llvm.org/D13746

Files:
  clang-tidy/cppcoreguidelines/CMakeLists.txt
  clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
  clang-tidy/cppcoreguidelines/ProBoundsConstantArrayIndexCheck.cpp
  clang-tidy/cppcoreguidelines/ProBoundsConstantArrayIndexCheck.h
  docs/clang-tidy/checks/cppcoreguidelines-pro-bounds-constant-array-index.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index.cpp

Index: test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index.cpp
===
--- /dev/null
+++ test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index.cpp
@@ -0,0 +1,68 @@
+// RUN: %python %S/check_clang_tidy.py %s cppcoreguidelines-pro-bounds-constant-array-index %t
+#include 
+
+namespace gsl {
+  template
+  T& at( T()[N], size_t index );
+
+  template
+  T& at( std::array , size_t index );
+}
+
+constexpr int const_index(int base) {
+  return base + 3;
+}
+
+void f(std::array a, int pos) {
+  a[pos / 2] = 1;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: do not use array subscript when the index is not a compile-time constant; use gsl::at() instead [cppcoreguidelines-pro-bounds-constant-array-index]
+  a[pos - 1] = 2;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: do not use array subscript when the index is not a compile-time constant; use gsl::at() instead
+
+  a.at(pos-1) = 2; // OK, at() instead of []
+  gsl::at(a, pos-1) = 2; // OK, gsl::at() instead of []
+
+  a[-1] = 3;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: array index -1 is before the beginning of the array [cppcoreguidelines-pro-bounds-constant-array-index]
+  a[10] = 4;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: array index 10 is past the end of the array (which contains 10 elements) [cppcoreguidelines-pro-bounds-constant-array-index]
+
+  a[const_index(7)] = 3;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: array index 10 is past the end of the array (which contains 10 elements)
+
+  a[0] = 3; // OK, constant index and inside bounds
+  a[1] = 3; // OK, constant index and inside bounds
+  a[9] = 3; // OK, constant index and inside bounds
+  a[const_index(6)] = 3; // OK, constant index and inside bounds
+}
+
+void g() {
+  int a[10];
+  for (int i = 0; i < 10; ++i) {
+a[i] = i;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: do not use array subscript when the index is not a compile-time constant; use gsl::at() instead
+gsl::at(a, i) = i; // OK, gsl::at() instead of []
+  }
+
+  a[-1] = 3;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: array index -1 is before the beginning of the array
+  a[10] = 4;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: array index 10 is past the end of the array (which contains 10 elements)
+  a[const_index(7)] = 3;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: array index 10 is past the end of the array (which contains 10 elements)
+
+  a[0] = 3; // OK, constant index and inside bounds
+  a[1] = 3; // OK, constant index and inside bounds
+  a[9] = 3; // OK, constant index and inside bounds
+  a[const_index(6)] = 3; // OK, constant index and inside bounds
+}
+
+struct S {
+  int& operator[](int i);
+};
+
+void customOperator() {
+  S s;
+  int i = 0;
+  s[i] = 3; // OK, custom operator
+}
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -4,6 +4,7 @@
 .. toctree::
cert-setlongjmp
cert-variadic-function-def
+   cppcoreguidelines-pro-bounds-constant-array-index
cppcoreguidelines-pro-bounds-pointer-arithmetic
cppcoreguidelines-pro-type-const-cast
cppcoreguidelines-pro-type-reinterpret-cast
Index: docs/clang-tidy/checks/cppcoreguidelines-pro-bounds-constant-array-index.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/cppcoreguidelines-pro-bounds-constant-array-index.rst
@@ -0,0 +1,9 @@
+cppcoreguidelines-pro-bounds-constant-array-index
+=
+
+This check 

Re: [PATCH] D13739: [libcxx] Make libc++.so a linker script by default on most platforms.

[Eric Fiselier via cfe-commits]

EricWF added a comment.

Thanks for the review. I'm going to wait a little to see if any objections crop 
up before committing.


http://reviews.llvm.org/D13739



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

[libcxx] r250336 - Update issues status

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Wed Oct 14 17:26:40 2015
New Revision: 250336

URL: http://llvm.org/viewvc/llvm-project?rev=250336=rev
Log:
Update issues status

Modified:
libcxx/trunk/www/kona.html

Modified: libcxx/trunk/www/kona.html
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/kona.html?rev=250336=250335=250336=diff
==
--- libcxx/trunk/www/kona.html (original)
+++ libcxx/trunk/www/kona.html Wed Oct 14 17:26:40 2015
@@ -74,7 +74,7 @@
http://cplusplus.github.io/LWG/lwg-defects.html#2259;>2259Issues
 in 17.6.5.5 rules for member functionsKonaComplete
http://cplusplus.github.io/LWG/lwg-defects.html#2336;>2336is_trivially_constructible/is_trivially_assignable
 traits are always falseKona
http://cplusplus.github.io/LWG/lwg-defects.html#2353;>2353std::next
 is over-constrainedKona
-   http://cplusplus.github.io/LWG/lwg-defects.html#2367;>2367pair
 and tuple are not correctly implemented for is_constructible 
with no argsKona
+   http://cplusplus.github.io/LWG/lwg-defects.html#2367;>2367pair
 and tuple are not correctly implemented for is_constructible 
with no argsKonaPatch Ready
http://cplusplus.github.io/LWG/lwg-defects.html#2380;>2380May
 cstdlib provide long ::abs(long) and long long 
::abs(long long)?KonaComplete
http://cplusplus.github.io/LWG/lwg-defects.html#2384;>2384Allocator's
 deallocate function needs better 
specificationKonaComplete
http://cplusplus.github.io/LWG/lwg-defects.html#2385;>2385function::assign
 allocator argument doesn't make senseKona
@@ -119,7 +119,7 @@
 2259 - No code changes needed here.
 2336 - Check later
 2353 - Simple change, needs a test. (test probably used to exist)
-2367 - Already done in tuple, pair needs to be done. Tests. (Eric)
+2367 - Patch Available as D13750 (Eric)
 2380 - No code changes here; we already do this.
 2384 - Wording cleanup; no code change required
 2385 - Removing broken signatures. Only question is "how far back"?


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

Re: [PATCH] D13640: [clang-tidy] Add new check cppcoreguidelines-pro-bounds-array-to-pointer-decay

[Matthias Gehre via cfe-commits]

mgehre added a comment.

Updated commit to fix comments


http://reviews.llvm.org/D13640



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

Re: [PATCH] D13739: [libcxx] Make libc++.so a linker script by default on most platforms.

[Eric Fiselier via cfe-commits]

EricWF added a comment.

In http://reviews.llvm.org/D13739#267286, @cbergstrom wrote:

> ‎And does this hardcode the abi and break cxxrt? It's not just me who uses 
> that 


No it does not hard code the ABI. The linker script is generated based on the 
name of the ABI library selected at build time. For libcxxrt the linker script 
would be "INPUT(libc++.so.1 -lcxxrt)".
This shouldn't make it any harder to use libcxxrt.


http://reviews.llvm.org/D13739



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

Re: [PATCH] D13739: [libcxx] Make libc++.so a linker script by default on most platforms.

[Eric Fiselier via cfe-commits]

EricWF updated this revision to Diff 37393.
EricWF marked 5 inline comments as done.
EricWF added a comment.

Address review comments.


http://reviews.llvm.org/D13739

Files:
  CMakeLists.txt
  cmake/Modules/HandleOutOfTreeLLVM.cmake
  docs/BuildingLibcxx.rst
  docs/UsingLibcxx.rst

Index: docs/UsingLibcxx.rst
===
--- docs/UsingLibcxx.rst
+++ docs/UsingLibcxx.rst
@@ -54,10 +54,10 @@
 Using libc++ on Linux
 =
 
-On Linux libc++ typically links to a shared version of libc++abi. Unfortunately
-you can't simply run clang with "-stdlib=libc++" as clang is not set up to
-link for this configuration. To get around this you'll have to manually
-link libc++abi yourself. For example:
+On Linux libc++ can typically be used with only '-stdlib=libc++'. However
+some libc++ installations require the user manually link libc++abi themselves.
+If you are running into linker errors when using libc++ try adding '-lc++abi'
+to the link line.  For example:
 
 .. code-block:: bash
 
Index: docs/BuildingLibcxx.rst
===
--- docs/BuildingLibcxx.rst
+++ docs/BuildingLibcxx.rst
@@ -170,6 +170,14 @@
   If this option is enabled, libc++ will try and link the selected ABI library
   statically.
 
+.. option:: LIBCXX_ENABLE_ABI_LINKER_SCRIPT:BOOL
+
+  **Default**: ``ON`` by default on UNIX platforms other than Apple unless
+  'LIBCXX_ENABLE_STATIC_ABI_LIBRARY' is ON. Otherwise the default value is ``OFF``.
+
+  This option generate and installs a linker script as ``libc++.so`` which
+  links the correct ABI library.
+
 .. option:: LIBCXXABI_USE_LLVM_UNWINDER:BOOL
 
   **Default**: ``OFF``
Index: cmake/Modules/HandleOutOfTreeLLVM.cmake
===
--- cmake/Modules/HandleOutOfTreeLLVM.cmake
+++ cmake/Modules/HandleOutOfTreeLLVM.cmake
@@ -109,6 +109,30 @@
 message(STATUS "Sphinx disabled.")
   endif()
 
+  # FIXME - This is cribbed from HandleLLVMOptions.cmake.
+  if(WIN32)
+set(LLVM_HAVE_LINK_VERSION_SCRIPT 0)
+if(CYGWIN)
+  set(LLVM_ON_WIN32 0)
+  set(LLVM_ON_UNIX 1)
+else(CYGWIN)
+  set(LLVM_ON_WIN32 1)
+  set(LLVM_ON_UNIX 0)
+endif(CYGWIN)
+  else(WIN32)
+if(UNIX)
+  set(LLVM_ON_WIN32 0)
+  set(LLVM_ON_UNIX 1)
+  if(APPLE)
+set(LLVM_HAVE_LINK_VERSION_SCRIPT 0)
+  else(APPLE)
+set(LLVM_HAVE_LINK_VERSION_SCRIPT 1)
+  endif(APPLE)
+else(UNIX)
+  MESSAGE(SEND_ERROR "Unable to determine platform")
+endif(UNIX)
+  endif(WIN32)
+
   # Add LLVM Functions 
   include(AddLLVM OPTIONAL)
 endif()
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -67,12 +67,22 @@
 set(CXXABIS none libcxxabi libcxxrt libstdc++ libsupc++)
 set_property(CACHE LIBCXX_CXX_ABI PROPERTY STRINGS ;${CXXABIS})
 
+# Use a static copy of the ABI library when linking libc++. This option
+# cannot be used with LIBCXX_ENABLE_ABI_LINKER_SCRIPT.
 option(LIBCXX_ENABLE_STATIC_ABI_LIBRARY "Statically link the ABI library" OFF)
 
 # Generate and install a linker script inplace of libc++.so. The linker script
-# will link libc++ to the correct ABI library.
+# will link libc++ to the correct ABI library. This option is on by default
+# On UNIX platforms other than Apple unless 'LIBCXX_ENABLE_STATIC_ABI_LIBRARY'
+# is on.
+set(ENABLE_LINKER_SCRIPT_DEFAULT_VALUE OFF)
+if (LLVM_HAVE_LINK_VERSION_SCRIPT AND NOT LIBCXX_ENABLE_STATIC_ABI_LIBRARY)
+set(ENABLE_LINKER_SCRIPT_DEFAULT_VALUE ON)
+endif()
+
 option(LIBCXX_ENABLE_ABI_LINKER_SCRIPT
-  "Use and install a linker script for the given ABI library" OFF)
+  "Use and install a linker script for the given ABI library"
+  ${ENABLE_LINKER_SCRIPT_DEFAULT_VALUE})
 
 # Build libc++abi with libunwind. We need this option to determine whether to
 # link with libunwind or libgcc_s while running the test cases.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D13739: [libcxx] Make libc++.so a linker script by default on most platforms.

[Eric Fiselier via cfe-commits]

EricWF added inline comments.


Comment at: CMakeLists.txt:71
@@ -70,1 +70,3 @@
+# Use a static copy of the ABI library when linking libc++. This option
+# cannot be used with LIBCXX_ENABLE_ABI_LINKER_SCRIPT.
 option(LIBCXX_ENABLE_STATIC_ABI_LIBRARY "Statically link the ABI library" OFF)

jroelofs wrote:
> Should probably make this a cmake error, not just have it do something other 
> than what you wanted.
It already is :-). Theres some logic near line #179.


Comment at: CMakeLists.txt:78
@@ +77,3 @@
+# is ON.
+set(DEFAULT_VALUE OFF)
+if (LLVM_HAVE_LINK_VERSION_SCRIPT AND NOT LIBCXX_ENABLE_STATIC_ABI_LIBRARY)

jroelofs wrote:
> `DEFAULT_VALUE` seems too generic a name for this... or is this a common 
> CMake pattern that I'm unaware of?
Nope, I was just being lazy with the name because it's not meant to be a global 
name but instead a scratch variable. I'll fix it anyway.


Comment at: cmake/Modules/HandleOutOfTreeLLVM.cmake:116
@@ +115,3 @@
+if(CYGWIN)
+  set(LLVM_ON_WIN32 0)
+  set(LLVM_ON_UNIX 1)

jroelofs wrote:
> Where are `LLVM_ON_WIN32` and `LLVM_ON_UNIX` used?
Nowhere yet but they will be used to validate sanitizer flags and other UNIX 
specific behavior. The whole chunk is copy and pasted from 
HandleLLVMOptions.cmake


http://reviews.llvm.org/D13739



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

[PATCH] D13748: [libcxx] Fix PR15638 - Only allocate in parent when starting a thread to prevent calling terminate.

[Eric Fiselier via cfe-commits]

EricWF created this revision.
EricWF added reviewers: mclow.lists, danalbert, jroelofs.
EricWF added a subscriber: cfe-commits.

Hi,

When creating a new thread libc++ performs at least 2 allocations. The first 
allocates a tuple of args and the functor that will be passed to the new 
thread. The second allocation is for the thread local storage needed internally 
by libc++. Currently the second allocation happens in the child thread, meaning 
that if it throws the program will terminate with an uncaught bad alloc.

The solution to this is to allocate ALL memory in the parent thread and then 
pass it to the child.

See https://llvm.org/bugs/show_bug.cgi?id=15638

http://reviews.llvm.org/D13748

Files:
  include/thread
  
test/std/thread/thread.threads/thread.thread.class/thread.thread.constr/F.pass.cpp

Index: test/std/thread/thread.threads/thread.thread.class/thread.thread.constr/F.pass.cpp
===
--- test/std/thread/thread.threads/thread.thread.class/thread.thread.constr/F.pass.cpp
+++ test/std/thread/thread.threads/thread.thread.class/thread.thread.constr/F.pass.cpp
@@ -19,23 +19,28 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
 #include "test_macros.h"
 
-unsigned throw_one = 0x;
+std::atomic throw_one(0x);
+std::atomic outstanding_new(0);
+
 
 void* operator new(std::size_t s) throw(std::bad_alloc)
 {
 if (throw_one == 0)
 throw std::bad_alloc();
 --throw_one;
+++outstanding_new;
 return std::malloc(s);
 }
 
 void  operator delete(void* p) throw()
 {
+--outstanding_new;
 std::free(p);
 }
 
@@ -93,27 +98,58 @@
 
 #endif
 
-int main()
-{
+// Test throwing std::bad_alloc
+//-
+// Concerns:
+//  A Each allocation performed during thread construction should be performed
+//in the parent thread so that std::terminate is not called if
+//std::bad_alloc is thrown by new.
+//  B std::threads constructor should properly handle exceptions and not leak
+//memory.
+// Plan:
+//  1 Create a thread and count the number of allocations, 'N', it performs.
+//  2 For each allocation performed run a test where that allocation throws.
+//2.1 check that the exception can be caught in the parent thread.
+//2.2 Check that the functor has not been called.
+//2.3 Check that no memory allocated by the creation of the thread is leaked.
+//  3 Finally check that a thread runs successfully if we throw after 'N+1'
+//allocations.
+void test_throwing_new_during_thread_creation() {
+throw_one = 0xFFF;
 {
 std::thread t(f);
 t.join();
-assert(f_run == true);
 }
-f_run = false;
-{
-try
-{
-throw_one = 0;
+const int numAllocs = 0xFFF - throw_one;
+// i <= numAllocs means the last iteration is expected not to throw.
+for (int i=0; i <= numAllocs; ++i) {
+throw_one = i;
+f_run = false;
+unsigned old_outstanding = outstanding_new;
+try {
 std::thread t(f);
-assert(false);
-}
-catch (...)
-{
-throw_one = 0x;
-assert(!f_run);
+assert(i == numAllocs); // Only final iteration will not throw.
+t.join();
+assert(f_run);
+} catch (std::bad_alloc const&) {
+assert(i < numAllocs);
+assert(!f_run); // (2.2)
 }
+assert(old_outstanding == outstanding_new); // (2.3)
+}
+f_run = false;
+throw_one = 0xFFF;
+}
+
+int main()
+{
+test_throwing_new_during_thread_creation();
+{
+std::thread t(f);
+t.join();
+assert(f_run == true);
 }
+
 {
 assert(G::n_alive == 0);
 assert(!G::op_run);
Index: include/thread
===
--- include/thread
+++ include/thread
@@ -338,21 +338,21 @@
 
 #ifndef _LIBCPP_HAS_NO_VARIADICS
 
-template 
+template 
 inline _LIBCPP_INLINE_VISIBILITY
 void
-__thread_execute(tuple<_Fp, _Args...>& __t, __tuple_indices<_Indices...>)
+__thread_execute(tuple<_TSp, _Fp, _Args...>& __t, __tuple_indices<_Indices...>)
 {
-__invoke(_VSTD::move(_VSTD::get<0>(__t)), _VSTD::move(_VSTD::get<_Indices>(__t))...);
+__invoke(_VSTD::move(_VSTD::get<1>(__t)), _VSTD::move(_VSTD::get<_Indices>(__t))...);
 }
 
 template 
-void*
-__thread_proxy(void* __vp)
+void* __thread_proxy(void* __vp)
 {
-__thread_local_data().reset(new __thread_struct);
+// _Fp = std::tuple< unique_ptr<__thread_struct>, Functor, Args...>
 std::unique_ptr<_Fp> __p(static_cast<_Fp*>(__vp));
-typedef typename __make_tuple_indices::value, 1>::type _Index;
+__thread_local_data().reset(_VSTD::get<0>(*__p).release());
+typedef typename __make_tuple_indices::value, 2>::type _Index;
 __thread_execute(*__p, _Index());
 return nullptr;
 }
@@ -362,9 +362,13 @@
  

Re: [libcxx] r249738 - Split out of .

[Duncan P. N. Exon Smith via cfe-commits]

+Ted

> On 2015-Oct-14, at 15:32, Richard Smith via cfe-commits 
>  wrote:
> 
>> While building module 'LLVM_Utils' imported from 
>> ../lib/Support/APFloat.cpp:15:
>> In file included from :1:
>> In file included from ../include/llvm/ADT/APFloat.h:20:
>> In file included from ../include/llvm/ADT/APInt.h:19:
>> In file included from ../include/llvm/ADT/ArrayRef.h:14:
>> In file included from ../include/llvm/ADT/SmallVector.h:20:
>> In file included from ../include/llvm/Support/MathExtras.h:21:
>> /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/type_traits:220:8:
>>  error: redefinition of '__void_t'
>> struct __void_t { typedef void type; };
>>^
>> /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/type_traits:220:8:
>>  note: previous definition is here
>> struct __void_t { typedef void type; };
>>^
>> If there is a way to prevent Clang from going into std when building Darwin, 
>> it looks like that’d be the way to go.
> 
> There is no such way currently, but we could add one. The question is, is it 
> OK that newer versions of libc++ would only work with newer versions of Clang 
> if modules are enabled? I'm inclined to think this is fine, since Clang's 
> modules support is still advertised as being experimental, but if (say) you 
> or the Sony folks tell me you need new versions of libc++ to work with some 
> already-shipped Clang binary then we'll need to reconsider.

I think this is okay for Apple, assuming I understand it correctly: you're 
going to make it so that C++ modules only work with libc++ headers if you have 
a clang that is >= the headers.

My understanding is that we don't expect clang to be used with *newer* libc++ 
headers, just older or equal.  This kind of break is a little unfortunate, but 
probably fine.  Ted, can you confirm?
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Adrian Prantl via cfe-commits]

> On Oct 14, 2015, at 11:37 AM, Adrian Prantl via cfe-commits 
>  wrote:
> 
>> 
>> On Oct 13, 2015, at 7:43 PM, Richard Smith > > wrote:
>> 
>> On Tue, Oct 13, 2015 at 6:54 PM, Sean Silva > > wrote:
>> On Tue, Oct 13, 2015 at 6:14 PM, Richard Smith > > wrote:
>> On Tue, Oct 13, 2015 at 5:31 PM, Sean Silva > > wrote:
>> On Tue, Oct 13, 2015 at 3:17 PM, Richard Smith via cfe-commits 
>> > wrote:
>> On Tue, Oct 13, 2015 at 2:10 PM, Adrian Prantl via cfe-commits 
>> > wrote:
>> Hi Richard,
>> 
>> this commit appears to break the module self-host on Darwin.
>> 
>> When compiling the following program generated by clang’s own cmake script:
>> 
>> > #undef NDEBUG
>> > #include 
>> > #define NDEBUG
>> > #include 
>> > int main() { assert(this code is not compiled); }
>> 
>> with clang++ -std=c++11 -fmodules -fcxx-modules test.cpp
>> 
>> (You don't need -fcxx-modules here.)
>>  
>> I get
>> 
>> > While building module 'std' imported from 
>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
>> >  :
>> > While building module 'Darwin' imported from 
>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39
>> >  :
>> > In file included from :98:
>> > In file included from 
>> > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/wchar.h:92:
>> > In file included from 
>> > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/_wctype.h:57:
>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/ctype.h:33:10
>> >  : 
>> > fatal error: cyclic dependency in module 'std': std -> Darwin -> std
>> > #include <__config>
>> >  ^
>> > While building module 'std' imported from 
>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
>> >  :
>> > In file included from :1:
>> > In file included from 
>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/algorithm:624
>> >  :
>> > In file included from 
>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/initializer_list:47
>> >  :
>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:10
>> >  : 
>> > fatal error: could not build module 'Darwin'
>> > #include 
>> >  ^
>> > In file included from test.cpp:2:
>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:10
>> >  : 
>> > fatal error: could not build module 'std'
>> > #include <__config>
>> >  ^
>> > 3 errors generated.
>> 
>> Let me know how I can help in diagnosing what’s going on here.
>> 
>> OK, I see what's wrong. Is this working any better for you in r250236?
>> 
>> We're still seeing:
>> 
>> While building module 'Darwin' imported from /usr/include/assert.h:42:
>> While building module 'std' imported from 
>> /path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:
>> 
>> Argh, this is including , which is in the std module. Can you 
>> try removing the header "type_traits" line from the libc++ module map and 
>> see if that helps?
>> 
>> I've run into this issue in the past, and I don't think that will fix it 
>> (see below). Just to be sure, here is the output with type_traits removed 
>> from the module map::
>> 
>> While building module 'Darwin' imported from /usr/include/assert.h:42:
>> While building module 'std' imported from 
>> /path/to/build_cmake/stage1/bin/../include/c++/v1/type_traits:211:
>> 
>> That's an include of . We'd need to apply this workaround to that 
>> header too (but I think the buck stops there).
> 
> After commenting out the cstddef module as well, the test case compiles 
> again. Should I commit that and the type_traits change to libcxx, or are you 
> working on a better fix?

To answer my previous question, removing the type_traits module allows us to 
finish all the cmake checks, but it then fails when building the LLVM_Utils 
module:

While building module 'LLVM_Utils' imported 

Re: [PATCH] D12747: Implement [depr.c.headers]

[Richard Smith via cfe-commits]

rsmith abandoned this revision.
rsmith added a comment.

Patch has been split up and the individual parts have all been committed 
(except the module map changes, which are currently problematic due to libc / 
libc++ layering issues).


Repository:
  rL LLVM

http://reviews.llvm.org/D12747



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

Re: [PATCH] D13640: [clang-tidy] Add new check cppcoreguidelines-pro-bounds-array-to-pointer-decay

[Matthias Gehre via cfe-commits]

mgehre updated this revision to Diff 37396.
mgehre marked an inline comment as done.
mgehre added a comment.

Test more complex array arithmetic, test gsl::array_view works, add "use 
array_view instead" to diagnostic


http://reviews.llvm.org/D13640

Files:
  clang-tidy/cppcoreguidelines/CMakeLists.txt
  clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
  clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp
  clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.h
  docs/clang-tidy/checks/cppcoreguidelines-pro-bounds-array-to-pointer-decay.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp

Index: test/clang-tidy/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp
===
--- /dev/null
+++ test/clang-tidy/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp
@@ -0,0 +1,44 @@
+// RUN: %python %S/check_clang_tidy.py %s cppcoreguidelines-pro-bounds-array-to-pointer-decay %t
+#include 
+
+namespace gsl {
+  template
+  class array_view {
+  public:
+template< class U, size_t N >
+array_view( U ()[N] );
+  };
+}
+
+void pointerfun(int* p);
+void arrayfun(int p[]);
+void arrayviewfun(gsl::array_view );
+size_t s();
+
+void f()
+{
+  int a[5];
+  pointerfun(a);
+  // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: do not (implicitly) convert an array to a pointer; use gsl::array_view instead [cppcoreguidelines-pro-bounds-array-to-pointer-decay]
+  pointerfun((int*)a);
+  // CHECK-MESSAGES: :[[@LINE-1]]:20: warning: do not (implicitly) convert an array to a pointer; use gsl::array_view instead
+  arrayfun(a);
+  // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: do not (implicitly) convert an array to a pointer; use gsl::array_view instead
+
+  pointerfun(a + s() - 10); // Convert to [g() - 10];
+  // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: do not (implicitly) convert an array to a pointer; use gsl::array_view instead
+
+  gsl::array_view av(a);
+  arrayviewfun(av); // OK
+
+  int i = a[0]; // OK
+  pointerfun([0]); // OK
+
+  for(auto e : a ) // OK, iteration internally decays array to pointer
+;
+}
+
+const char* g()
+{
+return "clang"; // OK, decay string literal to pointer
+}
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -4,6 +4,7 @@
 .. toctree::
cert-setlongjmp
cert-variadic-function-def
+   cppcoreguidelines-pro-bounds-array-to-pointer-decay
cppcoreguidelines-pro-type-const-cast
cppcoreguidelines-pro-type-reinterpret-cast
google-build-explicit-make-pair
Index: docs/clang-tidy/checks/cppcoreguidelines-pro-bounds-array-to-pointer-decay.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/cppcoreguidelines-pro-bounds-array-to-pointer-decay.rst
@@ -0,0 +1,9 @@
+cppcoreguidelines-pro-bounds-array-to-pointer-decay
+===
+
+This check flags all array to pointer decays.
+
+Pointers should not be used as arrays. array_view is a bounds-checked, safe alternative to using pointers to access arrays.
+
+This rule is part of the "Bounds safety" profile of the C++ Core Guidelines, see
+https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#-bounds3-no-array-to-pointer-decay
Index: clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.h
===
--- /dev/null
+++ clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.h
@@ -0,0 +1,34 @@
+//===--- ProBoundsArrayToPointerDecayCheck.h - clang-tidy*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_CPPCOREGUIDELINES_PRO_BOUNDS_ARRAY_TO_POINTER_DECAY_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_CPPCOREGUIDELINES_PRO_BOUNDS_ARRAY_TO_POINTER_DECAY_H
+
+#include "../ClangTidy.h"
+
+namespace clang {
+namespace tidy {
+
+/// This check flags all array to pointer decays
+///
+/// For the user-facing documentation see:
+/// http://clang.llvm.org/extra/clang-tidy/checks/cppcoreguidelines-pro-bounds-array-to-pointer-decay.html
+class ProBoundsArrayToPointerDecayCheck : public ClangTidyCheck {
+public:
+  ProBoundsArrayToPointerDecayCheck(StringRef Name, ClangTidyContext *Context)
+  : ClangTidyCheck(Name, Context) {}
+  void registerMatchers(ast_matchers::MatchFinder *Finder) override;
+  void check(const ast_matchers::MatchFinder::MatchResult ) override;
+};
+
+} // namespace tidy
+} // namespace clang
+
+#endif // 

Re: [libcxx] r249738 - Split out of .

[Richard Smith via cfe-commits]

On Wed, Oct 14, 2015 at 2:03 PM, Adrian Prantl via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Oct 14, 2015, at 11:37 AM, Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> On Oct 13, 2015, at 7:43 PM, Richard Smith  wrote:
>
> On Tue, Oct 13, 2015 at 6:54 PM, Sean Silva  wrote:
>
>> On Tue, Oct 13, 2015 at 6:14 PM, Richard Smith 
>> wrote:
>>
>>> On Tue, Oct 13, 2015 at 5:31 PM, Sean Silva 
>>> wrote:
>>>
 On Tue, Oct 13, 2015 at 3:17 PM, Richard Smith via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

> On Tue, Oct 13, 2015 at 2:10 PM, Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Hi Richard,
>>
>> this commit appears to break the module self-host on Darwin.
>>
>> When compiling the following program generated by clang’s own cmake
>> script:
>>
>> > #undef NDEBUG
>> > #include 
>> > #define NDEBUG
>> > #include 
>> > int main() { assert(this code is not compiled); }
>>
>> with clang++ -std=c++11 -fmodules -fcxx-modules test.cpp
>>
>
> (You don't need -fcxx-modules here.)
>
>
>> I get
>>
>> > While building module 'std' imported from /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
>> :
>> > While building module 'Darwin' imported from
>> /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39
>> :
>> > In file included from :98:
>> > In file included from
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/wchar.h:92:
>> > In file included from
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/_wctype.h:57:
>
> > /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/ctype.h:33:10
>> :
>> fatal error: cyclic dependency in module 'std': std -> Darwin -> std
>> > #include <__config>
>> >  ^
>> > While building module 'std' imported from /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
>> :
>> > In file included from :1:
>> > In file included from /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/algorithm:624
>> :
>> > In file included from /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/initializer_list:47
>> 
>> :
>> > /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:10
>> :
>> fatal error: could not build module 'Darwin'
>> > #include 
>> >  ^
>> > In file included from test.cpp:2:
>> > /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:10
>> :
>> fatal error: could not build module 'std'
>> > #include <__config>
>> >  ^
>> > 3 errors generated.
>>
>> Let me know how I can help in diagnosing what’s going on here.
>>
>
> OK, I see what's wrong. Is this working any better for you in r250236?
>

 We're still seeing:

 While building module 'Darwin' imported from /usr/include/assert.h:42:
 While building module 'std' imported from
 /path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:

>>>
>>> Argh, this is including , which is in the std module. Can
>>> you try removing the header "type_traits" line from the libc++ module map
>>> and see if that helps?
>>>
>>
>> I've run into this issue in the past, and I don't think that will fix it
>> (see below). Just to be sure, here is the output with type_traits removed
>> from the module map::
>>
>> While building module 'Darwin' imported from /usr/include/assert.h:42:
>> While building module 'std' imported from
>> /path/to/build_cmake/stage1/bin/../include/c++/v1/type_traits:211:
>>
>
> That's an include of . We'd need to apply this workaround to that
> header too (but I think the buck stops there).
>
>
> After commenting out the cstddef module as well, the test case compiles
> again. Should I commit that and the type_traits change to libcxx, or are
> you working on a better fix?
>
>
> To answer my previous 

Re: [PATCH] D13673: Add initial support for the MUSL C library.

[Vasileios Kalintiris via cfe-commits]

vkalintiris updated this revision to Diff 37335.
vkalintiris added a comment.

Address reviewers' comments.


http://reviews.llvm.org/D13673

Files:
  CMakeLists.txt
  include/__config
  include/__config_site.in
  include/__locale
  include/support/musl/xlocale.h
  src/locale.cpp

Index: src/locale.cpp
===
--- src/locale.cpp
+++ src/locale.cpp
@@ -812,7 +812,8 @@
 {
 #ifdef _LIBCPP_HAS_DEFAULTRUNELOCALE
 return isascii(c) ? _DefaultRuneLocale.__mapupper[c] : c;
-#elif defined(__GLIBC__) || defined(__EMSCRIPTEN__) || defined(__NetBSD__)
+#elif defined(__GLIBC__) || defined(__EMSCRIPTEN__) || \
+  defined(__NetBSD__) || defined(_LIBCPP_HAS_MUSL_LIBC)
 return isascii(c) ? ctype::__classic_upper_table()[c] : c;
 #else
 return (isascii(c) && iswlower_l(c, _LIBCPP_GET_C_LOCALE)) ? c-L'a'+L'A' : c;
@@ -825,7 +826,8 @@
 for (; low != high; ++low)
 #ifdef _LIBCPP_HAS_DEFAULTRUNELOCALE
 *low = isascii(*low) ? _DefaultRuneLocale.__mapupper[*low] : *low;
-#elif defined(__GLIBC__) || defined(__EMSCRIPTEN__) || defined(__NetBSD__)
+#elif defined(__GLIBC__) || defined(__EMSCRIPTEN__) || \
+  defined(__NetBSD__) || defined(_LIBCPP_HAS_MUSL_LIBC)
 *low = isascii(*low) ? ctype::__classic_upper_table()[*low]
  : *low;
 #else
@@ -839,7 +841,8 @@
 {
 #ifdef _LIBCPP_HAS_DEFAULTRUNELOCALE
 return isascii(c) ? _DefaultRuneLocale.__maplower[c] : c;
-#elif defined(__GLIBC__) || defined(__EMSCRIPTEN__) || defined(__NetBSD__)
+#elif defined(__GLIBC__) || defined(__EMSCRIPTEN__) || \
+  defined(__NetBSD_) || defined(_LIBCPP_HAS_MUSL_LIBC)
 return isascii(c) ? ctype::__classic_lower_table()[c] : c;
 #else
 return (isascii(c) && isupper_l(c, _LIBCPP_GET_C_LOCALE)) ? c-L'A'+'a' : c;
@@ -852,7 +855,8 @@
 for (; low != high; ++low)
 #ifdef _LIBCPP_HAS_DEFAULTRUNELOCALE
 *low = isascii(*low) ? _DefaultRuneLocale.__maplower[*low] : *low;
-#elif defined(__GLIBC__) || defined(__EMSCRIPTEN__) || defined(__NetBSD__)
+#elif defined(__GLIBC__) || defined(__EMSCRIPTEN__) || \
+  defined(__NetBSD__) || defined(_LIBCPP_HAS_MUSL_LIBC)
 *low = isascii(*low) ? ctype::__classic_lower_table()[*low]
  : *low;
 #else
@@ -921,8 +925,8 @@
   static_cast(_DefaultRuneLocale.__mapupper[static_cast(c)]) : c;
 #elif defined(__NetBSD__)
 return static_cast(__classic_upper_table()[static_cast(c)]);
-#elif defined(__GLIBC__) || defined(__EMSCRIPTEN__)
-return isascii(c) ? 
+#elif defined(__GLIBC__) || defined(__EMSCRIPTEN__) || defined(_LIBCPP_HAS_MUSL_LIBC)
+return isascii(c) ?
   static_cast(__classic_upper_table()[static_cast(c)]) : c;
 #else
 return (isascii(c) && islower_l(c, _LIBCPP_GET_C_LOCALE)) ? c-'a'+'A' : c;
@@ -938,7 +942,7 @@
   static_cast(_DefaultRuneLocale.__mapupper[static_cast(*low)]) : *low;
 #elif defined(__NetBSD__)
 *low = static_cast(__classic_upper_table()[static_cast(*low)]);
-#elif defined(__GLIBC__) || defined(__EMSCRIPTEN__)
+#elif defined(__GLIBC__) || defined(__EMSCRIPTEN__) || defined(_LIBCPP_HAS_MUSL_LIBC)
 *low = isascii(*low) ?
   static_cast(__classic_upper_table()[static_cast(*low)]) : *low;
 #else
@@ -955,7 +959,7 @@
   static_cast(_DefaultRuneLocale.__maplower[static_cast(c)]) : c;
 #elif defined(__NetBSD__)
 return static_cast(__classic_lower_table()[static_cast(c)]);
-#elif defined(__GLIBC__) || defined(__EMSCRIPTEN__) || defined(__NetBSD__)
+#elif defined(__GLIBC__) || defined(__EMSCRIPTEN__) || defined(_LIBCPP_HAS_MUSL_LIBC)
 return isascii(c) ?
   static_cast(__classic_lower_table()[static_cast(c)]) : c;
 #else
@@ -971,7 +975,7 @@
 *low = isascii(*low) ? static_cast(_DefaultRuneLocale.__maplower[static_cast(*low)]) : *low;
 #elif defined(__NetBSD__)
 *low = static_cast(__classic_lower_table()[static_cast(*low)]);
-#elif defined(__GLIBC__) || defined(__EMSCRIPTEN__)
+#elif defined(__GLIBC__) || defined(__EMSCRIPTEN__) || defined(_LIBCPP_HAS_MUSL_LIBC)
 *low = isascii(*low) ? static_cast(__classic_lower_table()[static_cast(*low)]) : *low;
 #else
 *low = (isascii(*low) && isupper_l(*low, _LIBCPP_GET_C_LOCALE)) ? *low-'A'+'a' : *low;
@@ -1012,7 +1016,7 @@
 return low;
 }
 
-#ifdef __EMSCRIPTEN__
+#if defined(__EMSCRIPTEN__) || defined(_LIBCPP_HAS_MUSL_LIBC)
 extern "C" const unsigned short ** __ctype_b_loc();
 extern "C" const int ** __ctype_tolower_loc();
 extern "C" const int ** __ctype_toupper_loc();
@@ -1114,7 +1118,7 @@
 return _ctype+1; // internal ctype mask table defined in msvcrt.dll
 // This is assumed to be safe, which is a nonsense assumption because we're
 // going to end up dereferencing it later...
-#elif defined(__EMSCRIPTEN__)
+#elif defined(__EMSCRIPTEN__) || defined(_LIBCPP_HAS_MUSL_LIBC)
 return *__ctype_b_loc();
 #elif defined(_NEWLIB_VERSION)
 // Newlib has a 257-entry table in ctype_.c, 

Re: [PATCH] D13516: Fix overlapping replacements in clang-tidy.

[Manuel Klimek via cfe-commits]

klimek added a comment.





Comment at: clang-tidy/ClangTidyDiagnosticConsumer.cpp:438-440
@@ +437,5 @@
+  int Count[2] = {0, 0};
+  // Sit[1][0] will tell if there exists any range that is covered by the
+  // first set but not by the second one, Sit[1][1] will tell if there is a
+  // range covered by both sets, etc.
+  bool Sit[2][2] = {{false, false}, {false, false}};

The description makes it unclear whether the indices stand for the set, or the 
dimensions stand for the sets (I can see it's the dimensions from where it is 
set, and that the indices are bools, but that's unclear without that / hard to 
grasp).
Here's a slightly denormalized way, that uses early-exit and might be easier to 
understand (more opinions would be nice, though).
(note that I probably messed up the FirstInsideSecond setting somewhere :)

  bool Overlaps = false;
  bool FirstInsideSecond = false;

  // In the loop:
  if (Count[0] != 0 && Count[1] != 0) {
Overlaps = true;
  } else if (Overlaps && ((Count[0] != 0 && FirstInsideSecond) ||
  (Count[1] != 0 && !FirstInsideSecond)) {
return OK_Overlap;
  } else if (Count[0] != 0 || Count[1] != 0) {
FirstInsideSecond = Count[1] != 0;
  }

  // After the loop:
  if (!Overlaps)
return OK_Disjoint;
  return FirstInsideSecond ? OK_FirstInsideSecond : OK_SecondInsideFirst;



http://reviews.llvm.org/D13516



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

Re: [PATCH] D13516: Fix overlapping replacements in clang-tidy.

[Angel Garcia via cfe-commits]

angelgarcia updated this revision to Diff 37334.
angelgarcia added a comment.

Add an enum and rename "Sit" to "Coverage" to improve readability.


http://reviews.llvm.org/D13516

Files:
  clang-tidy/ClangTidyDiagnosticConsumer.cpp
  clang-tidy/ClangTidyDiagnosticConsumer.h
  unittests/clang-tidy/OverlappingReplacementsTest.cpp

Index: unittests/clang-tidy/OverlappingReplacementsTest.cpp
===
--- unittests/clang-tidy/OverlappingReplacementsTest.cpp
+++ unittests/clang-tidy/OverlappingReplacementsTest.cpp
@@ -77,11 +77,12 @@
 auto *VD = Result.Nodes.getNodeAs(BoundDecl);
 std::string NewName = newName(VD->getName());
 
-auto Diag = diag(VD->getLocation(), "refactor")
+auto Diag = diag(VD->getLocation(), "refactor %0 into %1")
+<< VD->getName() << NewName
 << FixItHint::CreateReplacement(
-CharSourceRange::getTokenRange(VD->getLocation(),
-   VD->getLocation()),
-NewName);
+   CharSourceRange::getTokenRange(VD->getLocation(),
+  VD->getLocation()),
+   NewName);
 
 class UsageVisitor : public RecursiveASTVisitor {
 public:
@@ -281,7 +282,7 @@
 
   // Apply the UseCharCheck together with the IfFalseCheck.
   //
-  // The 'If' fix is bigger, so that is the one that has to be applied.
+  // The 'If' fix contains the other, so that is the one that has to be applied.
   // } else if (int a = 0) {
   //^^^ -> char
   //~ -> false
@@ -294,16 +295,16 @@
   }
 })";
   Res = runCheckOnCode(Code);
-  // FIXME: EXPECT_EQ(CharIfFix, Res);
+  EXPECT_EQ(CharIfFix, Res);
 
   // Apply the IfFalseCheck with the StartsWithPotaCheck.
   //
   // The 'If' replacement is bigger here.
   // if (char potato = 0) {
   //  ^^ -> tomato
   // ~~~ -> false
   //
-  // But the refactoring is bigger here:
+  // But the refactoring is the one that contains the other here:
   // char potato = 0;
   //  ^^ -> tomato
   // if (potato) potato;
@@ -318,60 +319,73 @@
   }
 })";
   Res = runCheckOnCode(Code);
-  // FIXME: EXPECT_EQ(IfStartsFix, Res);
-
-  // Silence warnings.
-  (void)CharIfFix;
-  (void)IfStartsFix;
+  EXPECT_EQ(IfStartsFix, Res);
 }
 
-TEST(OverlappingReplacementsTest, ApplyFullErrorOrNothingWhenOverlapping) {
-  std::string Res;
+TEST(OverlappingReplacements, TwoReplacementsInsideOne) {
   const char Code[] =
   R"(void f() {
-  int potato = 0;
-  potato += potato * potato;
-  if (char this_name_make_this_if_really_long = potato) potato;
+  if (int potato = 0) {
+int a = 0;
+  }
 })";
 
-  // StartsWithPotaCheck will try to refactor 'potato' into 'tomato',
-  // and EndsWithTatoCheck will try to use 'pomelo'. We have to apply
-  // either all conversions from one check, or all from the other.
-  const char StartsFix[] =
+  // The two smallest replacements should not be applied.
+  // if (int potato = 0) {
+  // ^^ -> tomato
+  // *** -> char
+  // ~~ -> false
+  // But other errors from the same checks should not be affected.
+  //   int a = 0;
+  //   *** -> char
+  const char Fix[] =
   R"(void f() {
-  int tomato = 0;
-  tomato += tomato * tomato;
-  if (char this_name_make_this_if_really_long = tomato) tomato;
+  if (false) {
+char a = 0;
+  }
 })";
-  const char EndsFix[] =
+  std::string Res =
+  runCheckOnCode(Code);
+  EXPECT_EQ(Fix, Res);
+}
+
+TEST(OverlappingReplacementsTest, DiscardBothChangesWhenPartialOverlapping) {
+  const char Code[] =
   R"(void f() {
-  int pomelo = 0;
-  pomelo += pomelo * pomelo;
-  if (char this_name_make_this_if_really_long = pomelo) pomelo;
+  if (int potato = 0) {
+int a = potato;
+  }
 })";
-  // In case of overlapping, we will prioritize the biggest fix. However, these
-  // two fixes have the same size and position, so we don't know yet which one
-  // will have preference.
-  Res = runCheckOnCode(Code);
-  // FIXME: EXPECT_TRUE(Res == StartsFix || Res == EndsFix);
 
-  // StartsWithPotaCheck will try to refactor 'potato' into 'tomato', but
-  // replacing the 'if' condition is a bigger change than all the refactoring
-  // changes together (48 vs 36), so this is the one that is going to be
-  // applied.
-  const char IfFix[] =
+  // These two replacements overlap, but none of them is completely contained
+  // inside the other. Both of them are discarded.
+  // if (int potato = 0) {
+  // ^^ -> tomato
+  // ~~ -> false
+  //   int a = potato;
+  //   ^^ -> tomato
+  std::string Res = runCheckOnCode(Code);
+  EXPECT_EQ(Code, Res);
+}
+

Re: [PATCH] D13673: Add initial support for the MUSL C library.

[Vasileios Kalintiris via cfe-commits]

vkalintiris added inline comments.


Comment at: CMakeLists.txt:309
@@ -307,1 +308,3 @@
 
+config_define_if(LIBCXX_LIBC_IS_MUSL _LIBCXX_LIBC_IS_MUSL)
+

EricWF wrote:
> Please name the macro "_LIBCPP_HAS_MUSL_LIBC" for consistency. 
Should I rename the corresponding cmake option too?


http://reviews.llvm.org/D13673



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

Re: [PATCH] D13516: Fix overlapping replacements in clang-tidy.

[Manuel Klimek via cfe-commits]

klimek added inline comments.


Comment at: clang-tidy/ClangTidyDiagnosticConsumer.cpp:444-448
@@ +443,7 @@
+  };
+  // Keep track of the different coverage situations that have been spotted
+  // during the process: Coverage[Covered][Empty] will tell if there exists any
+  // range that is covered by the first set but not by the second one,
+  // Coverage[Covered][Covered] will tell if there is a range covered by both
+  // sets, etc.
+  bool Coverage[2][2] = {{false, false}, {false, false}};

I'd just call out the 3 cases, like I suggested in my previous comment ("etc" 
sounds for me like there's more than 1 case left ;)


Comment at: clang-tidy/ClangTidyDiagnosticConsumer.cpp:461
@@ +460,3 @@
+
+  // If they never appeared at the same position, there is no overlapping.
+  if (!Coverage[Covered][Covered])

I'd say:
// If both sets never cover the same range, there is no overlap.


Comment at: clang-tidy/ClangTidyDiagnosticConsumer.cpp:472-475
@@ +471,6 @@
+  // first one, but not the other way around.
+  if (Coverage[Empty][Covered])
+return OK_FirstInsideSecond;
+
+  return OK_SecondInsideFirst;
+}

I'd make that:
return Coverage[Empty][Covered] ? OK_FirstInsideSecond : OK_SecondInsideFirst;
(and adapt the comment)


http://reviews.llvm.org/D13516



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

Re: [PATCH] D13713: [libc++] Stop marking interface symbols always_inline + hidden when building for unstable ABI

[Evgeniy Stepanov via cfe-commits]

eugenis added a comment.

I've wrote down my understanding of the problem in ABIVersioning.rst.
AFAIK, Howard added the attribute so he might know more about it.

Why does windows need this attributes in the unstable abi build?

Hidden visibility and always_inline work together for the same goal, so I'm 
removing them both. Keeping hidden visibility but removing always inline would 
break things because user code will expect external definitions for class 
members that would not be there.

Other approaches don't work for class members. AFAIK, there is no way in C++ to 
declare a class member function to have an internal linkage. In C this is done 
with the "static" keywords, but C++ went ahead an redefined it to mean 
something completely different.

One idea that we had for this was to introduce a 
__attribute__((internal_linkage)) and use it in place of always_inline with the 
supporting compiler.

I remeasured the test suite speed up on a different, faster machine and it is 
just 10%. Still quite a lot.


Repository:
  rL LLVM

http://reviews.llvm.org/D13713



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

Re: [libcxx] r249738 - Split out of .

[Adrian Prantl via cfe-commits]

> On Oct 14, 2015, at 5:07 PM, Richard Smith  wrote:
> 
> On Wed, Oct 14, 2015 at 3:58 PM, Adrian Prantl via cfe-commits 
> > wrote:
>> On Oct 14, 2015, at 3:32 PM, Richard Smith > > wrote:
>> 
>> On Wed, Oct 14, 2015 at 2:03 PM, Adrian Prantl via cfe-commits 
>> > wrote:
>>> On Oct 14, 2015, at 11:37 AM, Adrian Prantl via cfe-commits 
>>> > wrote:
 On Oct 13, 2015, at 7:43 PM, Richard Smith > wrote:
 
 On Tue, Oct 13, 2015 at 6:54 PM, Sean Silva > wrote:
 On Tue, Oct 13, 2015 at 6:14 PM, Richard Smith > wrote:
 On Tue, Oct 13, 2015 at 5:31 PM, Sean Silva > wrote:
 On Tue, Oct 13, 2015 at 3:17 PM, Richard Smith via cfe-commits 
 > wrote:
 On Tue, Oct 13, 2015 at 2:10 PM, Adrian Prantl via cfe-commits 
 > wrote:
 Hi Richard,
 
 this commit appears to break the module self-host on Darwin.
 
 When compiling the following program generated by clang’s own cmake script:
 
 > #undef NDEBUG
 > #include 
 > #define NDEBUG
 > #include 
 > int main() { assert(this code is not compiled); }
 
 with clang++ -std=c++11 -fmodules -fcxx-modules test.cpp
 
 (You don't need -fcxx-modules here.)
  
 I get
 
 > While building module 'std' imported from 
 > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
 >  :
 > While building module 'Darwin' imported from 
 > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39
 >  :
 > In file included from :98:
 > In file included from 
 > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/wchar.h:92:
 > In file included from 
 > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/_wctype.h:57:
 > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/ctype.h:33:10
 >  : 
 > fatal error: cyclic dependency in module 'std': std -> Darwin -> std
 > #include <__config>
 >  ^
 > While building module 'std' imported from 
 > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
 >  :
 > In file included from :1:
 > In file included from 
 > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/algorithm:624
 >  :
 > In file included from 
 > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/initializer_list:47
 >  
 > :
 > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:10
 >  : 
 > fatal error: could not build module 'Darwin'
 > #include 
 >  ^
 > In file included from test.cpp:2:
 > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:10
 >  : 
 > fatal error: could not build module 'std'
 > #include <__config>
 >  ^
 > 3 errors generated.
 
 Let me know how I can help in diagnosing what’s going on here.
 
 OK, I see what's wrong. Is this working any better for you in r250236?
 
 We're still seeing:
 
 While building module 'Darwin' imported from /usr/include/assert.h:42:
 While building module 'std' imported from 
 /path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:
 
 Argh, this is including , which is in the std module. Can you 
 try removing the header "type_traits" line from the libc++ module map and 
 see if that helps?
 
 I've run into this issue in the past, and I don't think that will fix it 
 (see below). Just to be sure, here is the output with type_traits removed 
 from the module map::
 
 While 

Re: [PATCH] D12614: [OpenMP] Offloading descriptor registration and device codegen.

[Samuel Antao via cfe-commits]

sfantao added a comment.

Ping!


http://reviews.llvm.org/D12614



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

Re: [PATCH] D9888: [OPENMP] Driver support for OpenMP offloading

[Samuel Antao via cfe-commits]

sfantao added a comment.

Are there any more comments/suggestions about this patch?

Thanks!
Samuel


http://reviews.llvm.org/D9888



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

RE: [PATCH] D13482: Revised Initial patch for PS4 toolchain

[Romanova, Katya via cfe-commits]

Filipe,
I have one question regarding the change in debug-option.c that you made to get 
the builds green again… (r250294).

Basically you changed the generic run line that used to test the drivers for 
every single platform
// RUN: %clang -### -g %s 2>&1 | FileCheck -check-prefix=CI %s

into the run line that tests x86_64 drivers only.
// RUN: %clang -### -g -target x86_64-unknown-unknown %s 2>&1 \
// | FileCheck -check-prefix=CI %s

By making this change, we reduced driver coverage for the other platforms, e.g. 
AMD.  This run line will continue to pass for AMD irrespective of whether the 
AMD driver enabled or disabled emitting column information by default. I 
suspect that *non*-x86_64 developers won't be happy that we reduced their 
drivers’ test coverage without letting them know.

Is there a better way to address this issue?

From what I understand, it’s impossible now to execute a specific RUN line for 
all the platforms, except platform . However, it’s easy to do it for the 
whole file (XFAIL: ). Does anyone know how hard it would be to expand lit 
functionality to do XFAIL:  for a block of RUN lines in a file (e.g. XFAIL 
: begin:  …. XFAIL : end : ? Or, even a simpler approach: force XFAIL 
to take effect only for the RUN lines that follow XFAIL line. It will 
definitely add much more power/flexibility to FAIL functionality in lit. It 
might also reduce test code duplication. What do you think?

But for now (for our specific problem)  maybe it’s better to remove the run 
lines that work differently for PS4 and for the rest of the world from 
debug_options.c  file and place them into a ps4 specific file (e.g. 
ps4-Gcolumn-info.c) and into non-ps4 generic file (e.g gcolumn-info.c) and make 
gcolumn-info.c to XFAIL for PS4. We could do this extraction for gcolumn_info, 
debug_aranges, and anything else that is different for PS4 and everyone else,

Katya.


From: fil...@gmail.com [mailto:fil...@gmail.com] On Behalf Of Filipe Cabecinhas
Sent: Wednesday, October 14, 2015 6:11 AM
To: Romanova, Katya
Cc: Sean Silva; Eric Christopher; 
reviews+d13482+public+a1a9627af638c...@reviews.llvm.org; Alex Rosenberg; 
Robinson, Paul; Jonathan Roelofs; Bedwell, Greg; pierregoussea...@gmail.com; 
Anton Korobeynikov; Takumi NAKAMURA; cfe-commits
Subject: Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain

Hi all,

I have harnessed the powers of time zones and did the last tweak we needed to 
get it comitted.
It's still going through some bots, but I don't foresee big problems. The fast 
bots liked it.

Thanks to everyone that reviewed it and worked on it!

  Filipe

On Wed, Oct 14, 2015 at 8:54 AM, Romanova, Katya 
>
 wrote:
Hi Sean,

I don’t think that the whole patch should have been reverted. There were much 
easier way to make the PS4 bot green. A single test could have been marked as 
“XFAIL: ps4” for a few hours until a better solution is implemented. Reverting 
this huge patch is more drastic measure that might cause more problems later.

As you saw in my previous email, I kept an eye on the bots, noticed the failure 
on PS4 buildbot, explained why it happened in the email and ask community for 
an opinion if it could be temporarily marked as “XFAIL” for ps4 only. I had to 
leave work at certain point. When I got home, I saw that you reverted the whole 
fix. Now I will have to go through all the pain with maintaining a huge commit, 
instead of making one line change affecting one of the tests on PS4 platform 
only… But, I guess, if it’s a general practice,  then it’s a different story. I 
was not aware of this practice and I thought that the other solution was much 
more reasonable.

Thank you for letting me know about LLVM_DEFAULT_TARGET_TRIPLE=x86_64-scei-ps4. 
I will definitely run it before the next commit.

Katya.


From: Sean Silva [mailto:chisophu...@gmail.com]
Sent: Tuesday, October 13, 2015 11:56 PM
To: Eric Christopher
Cc: 
reviews+d13482+public+a1a9627af638c...@reviews.llvm.org;
 Romanova, Katya; Alex Rosenberg; Robinson, Paul; 
filcab+llvm.phabrica...@gmail.com; 
Jonathan Roelofs; Bedwell, Greg; 
pierregoussea...@gmail.com; Anton 
Korobeynikov; Takumi NAKAMURA; cfe-commits
Subject: Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain



On Tue, Oct 13, 2015 at 11:40 PM, Eric Christopher 
> wrote:

On Tue, Oct 13, 2015 at 11:38 PM Sean Silva 
> wrote:
On Tue, Oct 13, 2015 at 11:33 PM, Eric Christopher 
> wrote:
It was already reverted, but I agree, let's get this fixed first.

It was reintroduced in r250252. It is breaking 

Re: [libcxx] r249738 - Split out of .

[Ted Kremenek via cfe-commits]

> On Oct 14, 2015, at 3:49 PM, Duncan P. N. Exon Smith  
> wrote:
> 
> My understanding is that we don't expect clang to be used with *newer* libc++ 
> headers, just older or equal.  This kind of break is a little unfortunate, 
> but probably fine.  Ted, can you confirm?

On Apple platforms, we will always be shipping new clangs whenever the libc++ 
headers are updated, so I see no concerns there.  That’s pretty much in line 
with how we handle our headers + compiler changes in general at Apple.  For 
example, we rolled out new Objective-C changes in the last update that were 
widely and unconditionally adopted in our headers.  Even the Clang we released 
the previous year can no longer parse those headers because of those language 
changes.


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

r250348 - [X86] Use C+11 non-static data member initialization to initialize all the X86 feature controls. NFC

[Craig Topper via cfe-commits]

Author: ctopper
Date: Wed Oct 14 18:47:57 2015
New Revision: 250348

URL: http://llvm.org/viewvc/llvm-project?rev=250348=rev
Log:
[X86] Use C+11 non-static data member initialization to initialize all the X86 
feature controls. NFC

This simplifies the constructor initialization list and makes it less likely a 
feature flag will be forgotten there.

Modified:
cfe/trunk/lib/Basic/Targets.cpp

Modified: cfe/trunk/lib/Basic/Targets.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=250348=250347=250348=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Wed Oct 14 18:47:57 2015
@@ -2060,36 +2060,40 @@ const TargetInfo::AddlRegName AddlRegNam
 class X86TargetInfo : public TargetInfo {
   enum X86SSEEnum {
 NoSSE, SSE1, SSE2, SSE3, SSSE3, SSE41, SSE42, AVX, AVX2, AVX512F
-  } SSELevel;
+  } SSELevel = NoSSE;
   enum MMX3DNowEnum {
 NoMMX3DNow, MMX, AMD3DNow, AMD3DNowAthlon
-  } MMX3DNowLevel;
+  } MMX3DNowLevel = NoMMX3DNow;
   enum XOPEnum {
 NoXOP,
 SSE4A,
 FMA4,
 XOP
-  } XOPLevel;
+  } XOPLevel = NoXOP;
 
-  bool HasAES;
-  bool HasPCLMUL;
-  bool HasLZCNT;
-  bool HasRDRND;
-  bool HasFSGSBASE;
-  bool HasBMI;
-  bool HasBMI2;
-  bool HasPOPCNT;
-  bool HasRTM;
-  bool HasPRFCHW;
-  bool HasRDSEED;
-  bool HasADX;
-  bool HasTBM;
-  bool HasFMA;
-  bool HasF16C;
-  bool HasAVX512CD, HasAVX512ER, HasAVX512PF, HasAVX512DQ, HasAVX512BW,
-  HasAVX512VL;
-  bool HasSHA;
-  bool HasCX16;
+  bool HasAES = false;
+  bool HasPCLMUL = false;
+  bool HasLZCNT = false;
+  bool HasRDRND = false;
+  bool HasFSGSBASE = false;
+  bool HasBMI = false;
+  bool HasBMI2 = false;
+  bool HasPOPCNT = false;
+  bool HasRTM = false;
+  bool HasPRFCHW = false;
+  bool HasRDSEED = false;
+  bool HasADX = false;
+  bool HasTBM = false;
+  bool HasFMA = false;
+  bool HasF16C = false;
+  bool HasAVX512CD = false;
+  bool HasAVX512ER = false;
+  bool HasAVX512PF = false;
+  bool HasAVX512DQ = false;
+  bool HasAVX512BW = false;
+  bool HasAVX512VL = false;
+  bool HasSHA = false;
+  bool HasCX16 = false;
 
   /// \brief Enumeration of all of the X86 CPUs supported by Clang.
   ///
@@ -2257,7 +2261,7 @@ class X86TargetInfo : public TargetInfo
 //@{
 CK_Geode
 //@}
-  } CPU;
+  } CPU = CK_Generic;
 
   CPUKind getCPUKind(StringRef CPU) const {
 return llvm::StringSwitch(CPU)
@@ -2332,18 +2336,10 @@ class X86TargetInfo : public TargetInfo
 FP_Default,
 FP_SSE,
 FP_387
-  } FPMath;
+  } FPMath = FP_Default;
 
 public:
-  X86TargetInfo(const llvm::Triple )
-  : TargetInfo(Triple), SSELevel(NoSSE), MMX3DNowLevel(NoMMX3DNow),
-XOPLevel(NoXOP), HasAES(false), HasPCLMUL(false), HasLZCNT(false),
-HasRDRND(false), HasFSGSBASE(false), HasBMI(false), HasBMI2(false),
-HasPOPCNT(false), HasRTM(false), HasPRFCHW(false), HasRDSEED(false),
-HasADX(false), HasTBM(false), HasFMA(false), HasF16C(false),
-HasAVX512CD(false), HasAVX512ER(false), HasAVX512PF(false),
-HasAVX512DQ(false), HasAVX512BW(false), HasAVX512VL(false),
-HasSHA(false), HasCX16(false), CPU(CK_Generic), FPMath(FP_Default) {
+  X86TargetInfo(const llvm::Triple ) : TargetInfo(Triple) {
 BigEndian = false;
 LongDoubleFormat = ::APFloat::x87DoubleExtended;
   }


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

Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain

[Sean Silva via cfe-commits]

On Wed, Oct 14, 2015 at 12:54 AM, Romanova, Katya <
katya_roman...@playstation.sony.com> wrote:

> Hi Sean,
>
>
>
> I don’t think that the whole patch should have been reverted. There were
> much easier way to make the PS4 bot green. A single test could have been
> marked as “XFAIL: ps4” for a few hours until a better solution is
> implemented. Reverting this huge patch is more drastic measure that might
> cause more problems later.
>
>
>
> As you saw in my previous email, I kept an eye on the bots, noticed the
> failure on PS4 buildbot, explained why it happened in the email and ask
> community for an opinion if it could be temporarily marked as “XFAIL” for
> ps4 only. I had to leave work at certain point. When I got home, I saw that
> you reverted the whole fix. Now I will have to go through all the pain with
> maintaining a huge commit, instead of making one line change affecting one
> of the tests on PS4 platform only… But, I guess, if it’s a general
> practice,  then it’s a different story. I was not aware of this practice
> and I thought that the other solution was much more reasonable.
>

Yes, it is general practice. Reverting is easier and sends a clear signal
that broken code is not allowed. XFAIL gives the impression that it is
failing for some reason that is not preventable (for example, the operating
system doesn't support some system call that is needed); that is not true
in this case: there was just an oversight and broken code was committed.

Also, the bot had been red for a *very* long time and there was no
indication that you were doing anything about it (I reverted at almost
midnight). In the future, be sure to keep an eye on the bots and either
commit a fix or revert to green. "commit and go home" is very inconsiderate
to all fellow community members.

-- Sean Silva


>
>
> Thank you for letting me know about 
> LLVM_DEFAULT_TARGET_TRIPLE=x86_64-scei-ps4.
> I will definitely run it before the next commit.
>
>
>
> Katya.
>
>
>
>
>
> *From:* Sean Silva [mailto:chisophu...@gmail.com]
> *Sent:* Tuesday, October 13, 2015 11:56 PM
> *To:* Eric Christopher
> *Cc:* reviews+d13482+public+a1a9627af638c...@reviews.llvm.org; Romanova,
> Katya; Alex Rosenberg; Robinson, Paul; filcab+llvm.phabrica...@gmail.com;
> Jonathan Roelofs; Bedwell, Greg; pierregoussea...@gmail.com; Anton
> Korobeynikov; Takumi NAKAMURA; cfe-commits
> *Subject:* Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain
>
>
>
>
>
>
>
> On Tue, Oct 13, 2015 at 11:40 PM, Eric Christopher 
> wrote:
>
>
>
> On Tue, Oct 13, 2015 at 11:38 PM Sean Silva  wrote:
>
> On Tue, Oct 13, 2015 at 11:33 PM, Eric Christopher 
> wrote:
>
> It was already reverted, but I agree, let's get this fixed first.
>
>
>
> It was reintroduced in r250252. It is breaking
> http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/1362
>
>
>
>
>
> Ah, I missed that. Yeah, please go ahead and revert for now.
>
>
>
> reverted in r250273
>
> (bot is back to green:
> http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/1363
> )
>
>
>
> Katya - remember to run the tests
> with LLVM_DEFAULT_TARGET_TRIPLE=x86_64-scei-ps4 (and also remember to keep
> an eye on the bots after committing)
>
>
>
> -- Sean Silva
>
>
>
>
>
> Thanks!
>
>
>
> -eric
>
>
>
> -- Sean Silva
>
>
>
>
>
> Thanks!
>
>
>
> -eric
>
>
>
> On Tue, Oct 13, 2015 at 11:33 PM Sean Silva  wrote:
>
> On Tue, Oct 13, 2015 at 7:51 PM, Katya Romanova <
> katya_roman...@playstation.sony.com> wrote:
>
> kromanova added a comment.
>
> Hi,
>
> The initial PS4 patch caused a test failure (debug-options.c) on the PS4
> bot. I suspect that I know why the problem happens, but I'm not sure what
> will be the best way to handle it. If someone knows how to fix this test
> more "elegantly", I would appreciate their advice.
>
> FAIL: Clang :: Driver/debug-options.c (3509 of 24708)
>
> - TEST 'Clang :: Driver/debug-options.c' FAILED 
>
> Script:
> ---
>
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/clang
> -### -c -g
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
> -target x86_64-linux-gnu 2>&1  |
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
> -check-prefix=G /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-
> 
>
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/clang
> -### -g
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
> 2>&1 |
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
> -check-prefix=CI
> 

Re: [PATCH] D13713: [libc++] Stop marking interface symbols always_inline + hidden when building for unstable ABI

[Evgeniy Stepanov via cfe-commits]

eugenis updated this revision to Diff 37427.

Repository:
  rL LLVM

http://reviews.llvm.org/D13713

Files:
  docs/DesignDocs/ABIVersioning.rst
  include/__config

Index: include/__config
===
--- include/__config
+++ include/__config
@@ -31,6 +31,13 @@
 #define _LIBCPP_ABI_ALTERNATE_STRING_LAYOUT
 #endif
 
+#if defined(_LIBCPP_ABI_UNSTABLE)
+// The only purpose of the always_inline thing is ABI stability.
+// Disable it when building for unstable ABI.
+#define _LIBCPP_INLINE_VISIBILITY
+#define _LIBCPP_ALWAYS_INLINE
+#endif
+
 #define _LIBCPP_CONCAT1(_LIBCPP_X,_LIBCPP_Y) _LIBCPP_X##_LIBCPP_Y
 #define _LIBCPP_CONCAT(_LIBCPP_X,_LIBCPP_Y) 
_LIBCPP_CONCAT1(_LIBCPP_X,_LIBCPP_Y)
 
Index: docs/DesignDocs/ABIVersioning.rst
===
--- docs/DesignDocs/ABIVersioning.rst
+++ docs/DesignDocs/ABIVersioning.rst
@@ -15,3 +15,40 @@
 
 Any ABI-changing feature is placed under it's own macro, _LIBCPP_ABI_XXX, 
which is enabled
 based on the value of _LIBCPP_ABI_VERSION. _LIBCPP_ABI_UNSTABLE, if set, 
enables all features at once.
+
+
+Always_inline attributes
+
+
+To ensure ABI stability, libc++ attempts to tightly control the set of
+symbols exported from libc++.so.  This is achieved with a "trick" of
+marking all functions and class methods defined in the library headers
+on Linux/MacOSX with::
+
+  __attribute__((always_inline, visibility("hidden")))
+
+All direct calls to functions marked with the always_inline attribute
+are inlined and are never emitted as an external symbol
+reference. Hidden visibility removes the symbol from the shared
+library exports list.
+
+This approach has a number of drawbacks.
+
+* always_inline functions are not always inlined. Inlining is an
+  optimization, and there are multiple cases when a compiler can
+  decide against it.
+
+  * As of version 3.7, Clang can sometimes emit an **unreachable**
+call to an always_inline function as an external symbol reference.
+  * Inlining may be impossible between functions with incompatible
+attributes. For example, ``__attribute__((no_sanitize_address))``,
+which suppresses AddressSanitizer instrumentation in a function,
+prevents inlining of functions that do not have the same
+attribute.
+
+* At -O0 optimization level indiscriminate inlining results in very
+  large stack frames. As a consequence, removing these attributes
+  speeds up libc++ test suite by 10%.
+
+These attributes are removed when building with
+LIBCXX_ABI_UNSTABLE=ON.


Index: include/__config
===
--- include/__config
+++ include/__config
@@ -31,6 +31,13 @@
 #define _LIBCPP_ABI_ALTERNATE_STRING_LAYOUT
 #endif
 
+#if defined(_LIBCPP_ABI_UNSTABLE)
+// The only purpose of the always_inline thing is ABI stability.
+// Disable it when building for unstable ABI.
+#define _LIBCPP_INLINE_VISIBILITY
+#define _LIBCPP_ALWAYS_INLINE
+#endif
+
 #define _LIBCPP_CONCAT1(_LIBCPP_X,_LIBCPP_Y) _LIBCPP_X##_LIBCPP_Y
 #define _LIBCPP_CONCAT(_LIBCPP_X,_LIBCPP_Y) _LIBCPP_CONCAT1(_LIBCPP_X,_LIBCPP_Y)
 
Index: docs/DesignDocs/ABIVersioning.rst
===
--- docs/DesignDocs/ABIVersioning.rst
+++ docs/DesignDocs/ABIVersioning.rst
@@ -15,3 +15,40 @@
 
 Any ABI-changing feature is placed under it's own macro, _LIBCPP_ABI_XXX, which is enabled
 based on the value of _LIBCPP_ABI_VERSION. _LIBCPP_ABI_UNSTABLE, if set, enables all features at once.
+
+
+Always_inline attributes
+
+
+To ensure ABI stability, libc++ attempts to tightly control the set of
+symbols exported from libc++.so.  This is achieved with a "trick" of
+marking all functions and class methods defined in the library headers
+on Linux/MacOSX with::
+
+  __attribute__((always_inline, visibility("hidden")))
+
+All direct calls to functions marked with the always_inline attribute
+are inlined and are never emitted as an external symbol
+reference. Hidden visibility removes the symbol from the shared
+library exports list.
+
+This approach has a number of drawbacks.
+
+* always_inline functions are not always inlined. Inlining is an
+  optimization, and there are multiple cases when a compiler can
+  decide against it.
+
+  * As of version 3.7, Clang can sometimes emit an **unreachable**
+call to an always_inline function as an external symbol reference.
+  * Inlining may be impossible between functions with incompatible
+attributes. For example, ``__attribute__((no_sanitize_address))``,
+which suppresses AddressSanitizer instrumentation in a function,
+prevents inlining of functions that do not have the same
+attribute.
+
+* At -O0 optimization level indiscriminate inlining results in very
+  large stack frames. As a consequence, removing these attributes
+  speeds up 

Re: [libcxx] r249738 - Split out of .

[Richard Smith via cfe-commits]

On Wed, Oct 14, 2015 at 3:58 PM, Adrian Prantl via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Oct 14, 2015, at 3:32 PM, Richard Smith  wrote:
>
> On Wed, Oct 14, 2015 at 2:03 PM, Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On Oct 14, 2015, at 11:37 AM, Adrian Prantl via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>> On Oct 13, 2015, at 7:43 PM, Richard Smith  wrote:
>>
>> On Tue, Oct 13, 2015 at 6:54 PM, Sean Silva 
>> wrote:
>>
>>> On Tue, Oct 13, 2015 at 6:14 PM, Richard Smith 
>>> wrote:
>>>
 On Tue, Oct 13, 2015 at 5:31 PM, Sean Silva 
 wrote:

> On Tue, Oct 13, 2015 at 3:17 PM, Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On Tue, Oct 13, 2015 at 2:10 PM, Adrian Prantl via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Hi Richard,
>>>
>>> this commit appears to break the module self-host on Darwin.
>>>
>>> When compiling the following program generated by clang’s own cmake
>>> script:
>>>
>>> > #undef NDEBUG
>>> > #include 
>>> > #define NDEBUG
>>> > #include 
>>> > int main() { assert(this code is not compiled); }
>>>
>>> with clang++ -std=c++11 -fmodules -fcxx-modules test.cpp
>>>
>>
>> (You don't need -fcxx-modules here.)
>>
>>
>>> I get
>>>
>>> > While building module 'std' imported from /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
>>> :
>>> > While building module 'Darwin' imported from
>>> /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39
>>> :
>>> > In file included from :98:
>>> > In file included from
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/wchar.h:92:
>>> > In file included from
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/_wctype.h:57:
>>
>> > /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/ctype.h:33:10
>>> :
>>> fatal error: cyclic dependency in module 'std': std -> Darwin -> std
>>> > #include <__config>
>>> >  ^
>>> > While building module 'std' imported from /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
>>> :
>>> > In file included from :1:
>>> > In file included from /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/algorithm:624
>>> :
>>> > In file included from /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/initializer_list:47
>>> 
>>> :
>>> > /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:10
>>> :
>>> fatal error: could not build module 'Darwin'
>>> > #include 
>>> >  ^
>>> > In file included from test.cpp:2:
>>> > /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:10
>>> :
>>> fatal error: could not build module 'std'
>>> > #include <__config>
>>> >  ^
>>> > 3 errors generated.
>>>
>>> Let me know how I can help in diagnosing what’s going on here.
>>>
>>
>> OK, I see what's wrong. Is this working any better for you in r250236?
>>
>
> We're still seeing:
>
> While building module 'Darwin' imported from /usr/include/assert.h:42:
> While building module 'std' imported from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:
>

 Argh, this is including , which is in the std module. Can
 you try removing the header "type_traits" line from the libc++ module map
 and see if that helps?

>>>
>>> I've run into this issue in the past, and I don't think that will fix it
>>> (see below). Just to be sure, here is the output with type_traits removed
>>> from the module map::
>>>
>>> While building module 'Darwin' imported from /usr/include/assert.h:42:
>>> While building module 'std' imported from
>>> /path/to/build_cmake/stage1/bin/../include/c++/v1/type_traits:211:
>>>
>>
>> That's an include of . We'd 

Re: [libcxx] r249738 - Split out of .

[Sean Silva via cfe-commits]

On Wed, Oct 14, 2015 at 3:32 PM, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Wed, Oct 14, 2015 at 2:03 PM, Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On Oct 14, 2015, at 11:37 AM, Adrian Prantl via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>> On Oct 13, 2015, at 7:43 PM, Richard Smith  wrote:
>>
>> On Tue, Oct 13, 2015 at 6:54 PM, Sean Silva 
>> wrote:
>>
>>> On Tue, Oct 13, 2015 at 6:14 PM, Richard Smith 
>>> wrote:
>>>
 On Tue, Oct 13, 2015 at 5:31 PM, Sean Silva 
 wrote:

> On Tue, Oct 13, 2015 at 3:17 PM, Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On Tue, Oct 13, 2015 at 2:10 PM, Adrian Prantl via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Hi Richard,
>>>
>>> this commit appears to break the module self-host on Darwin.
>>>
>>> When compiling the following program generated by clang’s own cmake
>>> script:
>>>
>>> > #undef NDEBUG
>>> > #include 
>>> > #define NDEBUG
>>> > #include 
>>> > int main() { assert(this code is not compiled); }
>>>
>>> with clang++ -std=c++11 -fmodules -fcxx-modules test.cpp
>>>
>>
>> (You don't need -fcxx-modules here.)
>>
>>
>>> I get
>>>
>>> > While building module 'std' imported from /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
>>> :
>>> > While building module 'Darwin' imported from
>>> /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39
>>> :
>>> > In file included from :98:
>>> > In file included from
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/wchar.h:92:
>>> > In file included from
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/_wctype.h:57:
>>
>> > /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/ctype.h:33:10
>>> :
>>> fatal error: cyclic dependency in module 'std': std -> Darwin -> std
>>> > #include <__config>
>>> >  ^
>>> > While building module 'std' imported from /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
>>> :
>>> > In file included from :1:
>>> > In file included from /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/algorithm:624
>>> :
>>> > In file included from /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/initializer_list:47
>>> 
>>> :
>>> > /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:10
>>> :
>>> fatal error: could not build module 'Darwin'
>>> > #include 
>>> >  ^
>>> > In file included from test.cpp:2:
>>> > /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:10
>>> :
>>> fatal error: could not build module 'std'
>>> > #include <__config>
>>> >  ^
>>> > 3 errors generated.
>>>
>>> Let me know how I can help in diagnosing what’s going on here.
>>>
>>
>> OK, I see what's wrong. Is this working any better for you in r250236?
>>
>
> We're still seeing:
>
> While building module 'Darwin' imported from /usr/include/assert.h:42:
> While building module 'std' imported from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:
>

 Argh, this is including , which is in the std module. Can
 you try removing the header "type_traits" line from the libc++ module map
 and see if that helps?

>>>
>>> I've run into this issue in the past, and I don't think that will fix it
>>> (see below). Just to be sure, here is the output with type_traits removed
>>> from the module map::
>>>
>>> While building module 'Darwin' imported from /usr/include/assert.h:42:
>>> While building module 'std' imported from
>>> /path/to/build_cmake/stage1/bin/../include/c++/v1/type_traits:211:
>>>
>>
>> That's an include of . We'd need to apply this workaround to
>> that header too (but I think the buck stops 

[PATCH] D13759: [Clang] Fix Clang-tidy modernize-use-auto warnings in headers and generated files; other minor cleanups.

[Eugene Zelenko via cfe-commits]

Eugene.Zelenko created this revision.
Eugene.Zelenko added a reviewer: hans.
Eugene.Zelenko added a subscriber: cfe-commits.
Eugene.Zelenko set the repository for this revision to rL LLVM.
Herald added a subscriber: klimek.

I checked this patch on my own build on RHEL 6. Regressions were OK.

Please check it in if it's OK, because I don't have SVN write access.

Repository:
  rL LLVM

http://reviews.llvm.org/D13759

Files:
  include/clang/AST/ASTVector.h
  include/clang/AST/DeclContextInternals.h
  include/clang/AST/DeclTemplate.h
  include/clang/ASTMatchers/ASTMatchersInternal.h
  include/clang/Analysis/Analyses/Consumed.h
  include/clang/Rewrite/Core/Rewriter.h
  include/clang/Sema/Template.h
  include/clang/StaticAnalyzer/Core/BugReporter/PathDiagnostic.h
  include/clang/StaticAnalyzer/Core/CheckerManager.h
  utils/TableGen/ClangAttrEmitter.cpp

Index: utils/TableGen/ClangAttrEmitter.cpp
===
--- utils/TableGen/ClangAttrEmitter.cpp
+++ utils/TableGen/ClangAttrEmitter.cpp
@@ -952,7 +952,7 @@
 }
 
 void writeTemplateInstantiation(raw_ostream ) const override {
-  OS << "  " << getType() << " *tempInst" << getUpperName()
+  OS << "  auto *tempInst" << getUpperName()
  << " = new (C, 16) " << getType()
  << "[A->" << getLowerName() << "_size()];\n";
   OS << "  {\n";
@@ -1506,7 +1506,7 @@
 }
 OS << ", SourceRange Loc = SourceRange()";
 OS << ") {\n";
-OS << "" << R.getName() << "Attr *A = new (Ctx) " << R.getName();
+OS << "auto *A = new (Ctx) " << R.getName();
 OS << "Attr(Loc, Ctx, ";
 for (auto const  : Args) {
   ai->writeImplicitCtorArgs(OS);
@@ -1848,7 +1848,7 @@
 OS << "  case attr::" << R.getName() << ": {\n";
 Args = R.getValueAsListOfDefs("Args");
 if (R.isSubClassOf(InhClass) || !Args.empty())
-  OS << "const " << R.getName() << "Attr *SA = cast<" << R.getName()
+  OS << "const auto *SA = cast<" << R.getName()
  << "Attr>(A);\n";
 if (R.isSubClassOf(InhClass))
   OS << "Record.push_back(SA->isInherited());\n";
@@ -2164,7 +2164,7 @@
   continue;
 }
 
-OS << "  const " << R.getName() << "Attr *A = cast<"
+OS << "  const auto *A = cast<"
<< R.getName() << "Attr>(At);\n";
 bool TDependent = R.getValueAsBit("TemplateDependent");
 
@@ -2767,7 +2767,7 @@
 
 Args = R.getValueAsListOfDefs("Args");
 if (!Args.empty()) {
-  OS << "const " << R.getName() << "Attr *SA = cast<" << R.getName()
+  OS << "const auto *SA = cast<" << R.getName()
  << "Attr>(A);\n";
   for (const auto *Arg : Args)
 createArgument(*Arg, R.getName())->writeDump(OS);
Index: include/clang/ASTMatchers/ASTMatchersInternal.h
===
--- include/clang/ASTMatchers/ASTMatchersInternal.h
+++ include/clang/ASTMatchers/ASTMatchersInternal.h
@@ -76,7 +76,7 @@
   /// it cannot be converted to the specified type.
   template 
   const T *getNodeAs(StringRef ID) const {
-IDToNodeMap::const_iterator It = NodeMap.find(ID);
+const auto It = NodeMap.find(ID);
 if (It == NodeMap.end()) {
   return nullptr;
 }
@@ -84,7 +84,7 @@
   }
 
   ast_type_traits::DynTypedNode getNode(StringRef ID) const {
-IDToNodeMap::const_iterator It = NodeMap.find(ID);
+const auto It = NodeMap.find(ID);
 if (It == NodeMap.end()) {
   return ast_type_traits::DynTypedNode();
 }
@@ -131,7 +131,7 @@
   /// BoundNodesTree.
   class Visitor {
   public:
-virtual ~Visitor() {}
+virtual ~Visitor() = default;
 
 /// \brief Called multiple times during a single call to VisitMatches(...).
 ///
@@ -209,7 +209,7 @@
 template 
 class MatcherInterface : public DynMatcherInterface {
 public:
-  ~MatcherInterface() override {}
+  ~MatcherInterface() override = default;
 
   /// \brief Returns true if 'Node' can be matched.
   ///
@@ -798,7 +798,7 @@
 AMM_ParentOnly
   };
 
-  virtual ~ASTMatchFinder() {}
+  virtual ~ASTMatchFinder() = default;
 
   /// \brief Returns true if the given class is directly or indirectly derived
   /// from a base type matching \c base.
@@ -1575,4 +1575,4 @@
 } // end namespace ast_matchers
 } // end namespace clang
 
-#endif
+#endif // LLVM_CLANG_ASTMATCHERS_ASTMATCHERSINTERNAL_H
Index: include/clang/StaticAnalyzer/Core/CheckerManager.h
===
--- include/clang/StaticAnalyzer/Core/CheckerManager.h
+++ include/clang/StaticAnalyzer/Core/CheckerManager.h
@@ -140,7 +140,7 @@
 if (ref)
   return static_cast(ref); // already registered.
 
-CHECKER *checker = new CHECKER();
+auto *checker = new CHECKER();
 checker->Name = CurrentCheckName;
 CheckerDtors.push_back(CheckerDtor(checker, destruct));
 CHECKER::_register(checker, *this);
@@ -155,7 +155,7 @@
 if (ref)
   return 

Re: [PATCH] D13516: Fix overlapping replacements in clang-tidy.

[Angel Garcia via cfe-commits]

angelgarcia updated this revision to Diff 37336.
angelgarcia added a comment.

Done.


http://reviews.llvm.org/D13516

Files:
  clang-tidy/ClangTidyDiagnosticConsumer.cpp
  clang-tidy/ClangTidyDiagnosticConsumer.h
  unittests/clang-tidy/OverlappingReplacementsTest.cpp

Index: unittests/clang-tidy/OverlappingReplacementsTest.cpp
===
--- unittests/clang-tidy/OverlappingReplacementsTest.cpp
+++ unittests/clang-tidy/OverlappingReplacementsTest.cpp
@@ -77,11 +77,12 @@
 auto *VD = Result.Nodes.getNodeAs(BoundDecl);
 std::string NewName = newName(VD->getName());
 
-auto Diag = diag(VD->getLocation(), "refactor")
+auto Diag = diag(VD->getLocation(), "refactor %0 into %1")
+<< VD->getName() << NewName
 << FixItHint::CreateReplacement(
-CharSourceRange::getTokenRange(VD->getLocation(),
-   VD->getLocation()),
-NewName);
+   CharSourceRange::getTokenRange(VD->getLocation(),
+  VD->getLocation()),
+   NewName);
 
 class UsageVisitor : public RecursiveASTVisitor {
 public:
@@ -281,7 +282,7 @@
 
   // Apply the UseCharCheck together with the IfFalseCheck.
   //
-  // The 'If' fix is bigger, so that is the one that has to be applied.
+  // The 'If' fix contains the other, so that is the one that has to be applied.
   // } else if (int a = 0) {
   //^^^ -> char
   //~ -> false
@@ -294,16 +295,16 @@
   }
 })";
   Res = runCheckOnCode(Code);
-  // FIXME: EXPECT_EQ(CharIfFix, Res);
+  EXPECT_EQ(CharIfFix, Res);
 
   // Apply the IfFalseCheck with the StartsWithPotaCheck.
   //
   // The 'If' replacement is bigger here.
   // if (char potato = 0) {
   //  ^^ -> tomato
   // ~~~ -> false
   //
-  // But the refactoring is bigger here:
+  // But the refactoring is the one that contains the other here:
   // char potato = 0;
   //  ^^ -> tomato
   // if (potato) potato;
@@ -318,60 +319,73 @@
   }
 })";
   Res = runCheckOnCode(Code);
-  // FIXME: EXPECT_EQ(IfStartsFix, Res);
-
-  // Silence warnings.
-  (void)CharIfFix;
-  (void)IfStartsFix;
+  EXPECT_EQ(IfStartsFix, Res);
 }
 
-TEST(OverlappingReplacementsTest, ApplyFullErrorOrNothingWhenOverlapping) {
-  std::string Res;
+TEST(OverlappingReplacements, TwoReplacementsInsideOne) {
   const char Code[] =
   R"(void f() {
-  int potato = 0;
-  potato += potato * potato;
-  if (char this_name_make_this_if_really_long = potato) potato;
+  if (int potato = 0) {
+int a = 0;
+  }
 })";
 
-  // StartsWithPotaCheck will try to refactor 'potato' into 'tomato',
-  // and EndsWithTatoCheck will try to use 'pomelo'. We have to apply
-  // either all conversions from one check, or all from the other.
-  const char StartsFix[] =
+  // The two smallest replacements should not be applied.
+  // if (int potato = 0) {
+  // ^^ -> tomato
+  // *** -> char
+  // ~~ -> false
+  // But other errors from the same checks should not be affected.
+  //   int a = 0;
+  //   *** -> char
+  const char Fix[] =
   R"(void f() {
-  int tomato = 0;
-  tomato += tomato * tomato;
-  if (char this_name_make_this_if_really_long = tomato) tomato;
+  if (false) {
+char a = 0;
+  }
 })";
-  const char EndsFix[] =
+  std::string Res =
+  runCheckOnCode(Code);
+  EXPECT_EQ(Fix, Res);
+}
+
+TEST(OverlappingReplacementsTest, DiscardBothChangesWhenPartialOverlapping) {
+  const char Code[] =
   R"(void f() {
-  int pomelo = 0;
-  pomelo += pomelo * pomelo;
-  if (char this_name_make_this_if_really_long = pomelo) pomelo;
+  if (int potato = 0) {
+int a = potato;
+  }
 })";
-  // In case of overlapping, we will prioritize the biggest fix. However, these
-  // two fixes have the same size and position, so we don't know yet which one
-  // will have preference.
-  Res = runCheckOnCode(Code);
-  // FIXME: EXPECT_TRUE(Res == StartsFix || Res == EndsFix);
 
-  // StartsWithPotaCheck will try to refactor 'potato' into 'tomato', but
-  // replacing the 'if' condition is a bigger change than all the refactoring
-  // changes together (48 vs 36), so this is the one that is going to be
-  // applied.
-  const char IfFix[] =
+  // These two replacements overlap, but none of them is completely contained
+  // inside the other. Both of them are discarded.
+  // if (int potato = 0) {
+  // ^^ -> tomato
+  // ~~ -> false
+  //   int a = potato;
+  //   ^^ -> tomato
+  std::string Res = runCheckOnCode(Code);
+  EXPECT_EQ(Code, Res);
+}
+
+TEST(OverlappingReplacementsTest, 

Re: [PATCH] D13516: Fix overlapping replacements in clang-tidy.

[Manuel Klimek via cfe-commits]

klimek added inline comments.


Comment at: clang-tidy/ClangTidyDiagnosticConsumer.cpp:495-496
@@ +494,4 @@
+  std::vector Apply(NumErrors, true);
+  for (int I = 0; I < NumErrors; ++I) {
+for (int J = I + 1; J < NumErrors; ++J) {
+  OverlappingKind Kind =

I'm somewhat concerned about the quadratic runtime here, for cases where 
somebody messes up a {} pair in a header and we have 1000s of errors.
Can we do a two step algorithm:
- go over all error-lists, compute bounding rectangles for each
- sort errors
- only do the squared algorithm for errors where the bounding rectangles overlap


http://reviews.llvm.org/D13516



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

r250293 - Bring back r250262: PS4 toolchain

[Filipe Cabecinhas via cfe-commits]

Author: filcab
Date: Wed Oct 14 07:25:43 2015
New Revision: 250293

URL: http://llvm.org/viewvc/llvm-project?rev=250293=rev
Log:
Bring back r250262: PS4 toolchain

There was a minor problem with a test. Sorry for the noise yesterday.

This patch adds missing pieces to clang, including the PS4 toolchain
definition, added warnings, PS4 defaults, and Driver changes needed for
our compiler.

A patch by Filipe Cabecinhas, Pierre Gousseau and Katya Romanova!

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

Added:
cfe/trunk/test/Driver/Inputs/scei-ps4_tree/target/include/.keep
cfe/trunk/test/Driver/Inputs/scei-ps4_tree/target/include_common/.keep
cfe/trunk/test/Driver/no-integrated-as.s
cfe/trunk/test/Driver/ps4-header-search.c
cfe/trunk/test/Driver/ps4-linker-non-win.c
cfe/trunk/test/Driver/ps4-linker-win.c
cfe/trunk/test/Driver/ps4-pic.c
cfe/trunk/test/Driver/ps4-sdk-root.c
Modified:
cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
cfe/trunk/include/clang/Basic/DiagnosticGroups.td
cfe/trunk/lib/Driver/Driver.cpp
cfe/trunk/lib/Driver/ToolChains.cpp
cfe/trunk/lib/Driver/ToolChains.h
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/lib/Driver/Tools.h
cfe/trunk/lib/Frontend/InitHeaderSearch.cpp
cfe/trunk/test/Driver/debug-options.c
cfe/trunk/test/Driver/stack-protector.c

Modified: cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td?rev=250293=250292=250293=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td Wed Oct 14 07:25:43 
2015
@@ -196,4 +196,18 @@ def warn_target_unsupported_nan2008 : Wa
 def warn_target_unsupported_nanlegacy : Warning<
   "ignoring '-mnan=legacy' option because the '%0' architecture does not 
support it">,
   InGroup;
+
+def warn_drv_unable_to_find_directory_expected : Warning<
+  "unable to find %0 directory, expected to be in '%1'">,
+  InGroup, DefaultIgnore;
+
+def warn_drv_ps4_force_pic : Warning<
+  "option '%0' was ignored by the PS4 toolchain, using '-fPIC'">,
+  InGroup;
+
+def warn_drv_ps4_sdk_dir : Warning<
+  "environment variable SCE_PS4_SDK_DIR is set, but points to invalid or 
nonexistent directory '%0'">,
+  InGroup;
+
+def err_drv_unsupported_linker : Error<"unsupported value '%0' for -linker 
option">;
 }

Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticGroups.td?rev=250293=250292=250293=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Wed Oct 14 07:25:43 2015
@@ -823,3 +823,7 @@ def CudaCompat : DiagGroup<"cuda-compat"
 
 // A warning group for things that will change semantics in the future.
 def FutureCompat : DiagGroup<"future-compat">;
+
+def InvalidOrNonExistentDirectory : 
DiagGroup<"invalid-or-nonexistent-directory">;
+
+def OptionIgnored : DiagGroup<"option-ignored">;

Modified: cfe/trunk/lib/Driver/Driver.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=250293=250292=250293=diff
==
--- cfe/trunk/lib/Driver/Driver.cpp (original)
+++ cfe/trunk/lib/Driver/Driver.cpp Wed Oct 14 07:25:43 2015
@@ -2261,6 +2261,9 @@ const ToolChain ::getToolChain(co
 case llvm::Triple::CUDA:
   TC = new toolchains::CudaToolChain(*this, Target, Args);
   break;
+case llvm::Triple::PS4:
+  TC = new toolchains::PS4CPU(*this, Target, Args);
+  break;
 default:
   // Of these targets, Hexagon is the only one that might have
   // an OS of Linux, in which case it got handled above already.

Modified: cfe/trunk/lib/Driver/ToolChains.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp?rev=250293=250292=250293=diff
==
--- cfe/trunk/lib/Driver/ToolChains.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains.cpp Wed Oct 14 07:25:43 2015
@@ -4066,3 +4066,77 @@ void WebAssembly::addClangTargetOptions(
  options::OPT_fno_use_init_array, true))
 CC1Args.push_back("-fuse-init-array");
 }
+
+PS4CPU::PS4CPU(const Driver , const llvm::Triple , const ArgList 
)
+: Generic_ELF(D, Triple, Args) {
+  if (Args.hasArg(options::OPT_static))
+D.Diag(diag::err_drv_unsupported_opt_for_target) << "-static" << "PS4";
+
+  // Determine where to find the PS4 libraries. We use SCE_PS4_SDK_DIR
+  // if it exists; otherwise use the driver's installation path, which
+  // should be /host_tools/bin.
+
+  SmallString<512> PS4SDKDir;
+  if (const char *EnvValue = 

Re: [PATCH] D13516: Fix overlapping replacements in clang-tidy.

[Angel Garcia via cfe-commits]

angelgarcia updated this revision to Diff 37344.
angelgarcia added a comment.

Use bounding boxes to reduce complexity.


http://reviews.llvm.org/D13516

Files:
  clang-tidy/ClangTidyDiagnosticConsumer.cpp
  clang-tidy/ClangTidyDiagnosticConsumer.h
  unittests/clang-tidy/OverlappingReplacementsTest.cpp

Index: unittests/clang-tidy/OverlappingReplacementsTest.cpp
===
--- unittests/clang-tidy/OverlappingReplacementsTest.cpp
+++ unittests/clang-tidy/OverlappingReplacementsTest.cpp
@@ -77,11 +77,12 @@
 auto *VD = Result.Nodes.getNodeAs(BoundDecl);
 std::string NewName = newName(VD->getName());
 
-auto Diag = diag(VD->getLocation(), "refactor")
+auto Diag = diag(VD->getLocation(), "refactor %0 into %1")
+<< VD->getName() << NewName
 << FixItHint::CreateReplacement(
-CharSourceRange::getTokenRange(VD->getLocation(),
-   VD->getLocation()),
-NewName);
+   CharSourceRange::getTokenRange(VD->getLocation(),
+  VD->getLocation()),
+   NewName);
 
 class UsageVisitor : public RecursiveASTVisitor {
 public:
@@ -281,7 +282,7 @@
 
   // Apply the UseCharCheck together with the IfFalseCheck.
   //
-  // The 'If' fix is bigger, so that is the one that has to be applied.
+  // The 'If' fix contains the other, so that is the one that has to be applied.
   // } else if (int a = 0) {
   //^^^ -> char
   //~ -> false
@@ -294,16 +295,16 @@
   }
 })";
   Res = runCheckOnCode(Code);
-  // FIXME: EXPECT_EQ(CharIfFix, Res);
+  EXPECT_EQ(CharIfFix, Res);
 
   // Apply the IfFalseCheck with the StartsWithPotaCheck.
   //
   // The 'If' replacement is bigger here.
   // if (char potato = 0) {
   //  ^^ -> tomato
   // ~~~ -> false
   //
-  // But the refactoring is bigger here:
+  // But the refactoring is the one that contains the other here:
   // char potato = 0;
   //  ^^ -> tomato
   // if (potato) potato;
@@ -318,60 +319,73 @@
   }
 })";
   Res = runCheckOnCode(Code);
-  // FIXME: EXPECT_EQ(IfStartsFix, Res);
-
-  // Silence warnings.
-  (void)CharIfFix;
-  (void)IfStartsFix;
+  EXPECT_EQ(IfStartsFix, Res);
 }
 
-TEST(OverlappingReplacementsTest, ApplyFullErrorOrNothingWhenOverlapping) {
-  std::string Res;
+TEST(OverlappingReplacements, TwoReplacementsInsideOne) {
   const char Code[] =
   R"(void f() {
-  int potato = 0;
-  potato += potato * potato;
-  if (char this_name_make_this_if_really_long = potato) potato;
+  if (int potato = 0) {
+int a = 0;
+  }
 })";
 
-  // StartsWithPotaCheck will try to refactor 'potato' into 'tomato',
-  // and EndsWithTatoCheck will try to use 'pomelo'. We have to apply
-  // either all conversions from one check, or all from the other.
-  const char StartsFix[] =
+  // The two smallest replacements should not be applied.
+  // if (int potato = 0) {
+  // ^^ -> tomato
+  // *** -> char
+  // ~~ -> false
+  // But other errors from the same checks should not be affected.
+  //   int a = 0;
+  //   *** -> char
+  const char Fix[] =
   R"(void f() {
-  int tomato = 0;
-  tomato += tomato * tomato;
-  if (char this_name_make_this_if_really_long = tomato) tomato;
+  if (false) {
+char a = 0;
+  }
 })";
-  const char EndsFix[] =
+  std::string Res =
+  runCheckOnCode(Code);
+  EXPECT_EQ(Fix, Res);
+}
+
+TEST(OverlappingReplacementsTest, DiscardBothChangesWhenPartialOverlapping) {
+  const char Code[] =
   R"(void f() {
-  int pomelo = 0;
-  pomelo += pomelo * pomelo;
-  if (char this_name_make_this_if_really_long = pomelo) pomelo;
+  if (int potato = 0) {
+int a = potato;
+  }
 })";
-  // In case of overlapping, we will prioritize the biggest fix. However, these
-  // two fixes have the same size and position, so we don't know yet which one
-  // will have preference.
-  Res = runCheckOnCode(Code);
-  // FIXME: EXPECT_TRUE(Res == StartsFix || Res == EndsFix);
 
-  // StartsWithPotaCheck will try to refactor 'potato' into 'tomato', but
-  // replacing the 'if' condition is a bigger change than all the refactoring
-  // changes together (48 vs 36), so this is the one that is going to be
-  // applied.
-  const char IfFix[] =
+  // These two replacements overlap, but none of them is completely contained
+  // inside the other. Both of them are discarded.
+  // if (int potato = 0) {
+  // ^^ -> tomato
+  // ~~ -> false
+  //   int a = potato;
+  //   ^^ -> tomato
+  std::string Res = runCheckOnCode(Code);
+  EXPECT_EQ(Code, Res);
+}
+

Re: [PATCH] D13516: Fix overlapping replacements in clang-tidy.

[Manuel Klimek via cfe-commits]

klimek added inline comments.


Comment at: clang-tidy/ClangTidyDiagnosticConsumer.cpp:438-440
@@ +437,5 @@
+  int Count[2] = {0, 0};
+  // Sit[1][0] will tell if there exists any range that is covered by the
+  // first set but not by the second one, Sit[1][1] will tell if there is a
+  // range covered by both sets, etc.
+  bool Sit[2][2] = {{false, false}, {false, false}};

klimek wrote:
> The description makes it unclear whether the indices stand for the set, or 
> the dimensions stand for the sets (I can see it's the dimensions from where 
> it is set, and that the indices are bools, but that's unclear without that / 
> hard to grasp).
> Here's a slightly denormalized way, that uses early-exit and might be easier 
> to understand (more opinions would be nice, though).
> (note that I probably messed up the FirstInsideSecond setting somewhere :)
> 
>   bool Overlaps = false;
>   bool FirstInsideSecond = false;
> 
>   // In the loop:
>   if (Count[0] != 0 && Count[1] != 0) {
> Overlaps = true;
>   } else if (Overlaps && ((Count[0] != 0 && FirstInsideSecond) ||
>   (Count[1] != 0 && !FirstInsideSecond)) {
> return OK_Overlap;
>   } else if (Count[0] != 0 || Count[1] != 0) {
> FirstInsideSecond = Count[1] != 0;
>   }
> 
>   // After the loop:
>   if (!Overlaps)
> return OK_Disjoint;
>   return FirstInsideSecond ? OK_FirstInsideSecond : OK_SecondInsideFirst;
> 
Ok, what I proposed doesn't work.

I start to like your solution more. Perhaps we just need to document it better:
a) call it Coverage
b) introduce enum with Covered and Empty (or similar)
c) document:
Coverage[Covered][Covered]: both set 1 and set 2 cover an area;
Coverage[Covered][Empty]: set 1 covers an area set 2 doesn't cover;
Coverage[Empty][Covered]: set 2 covers an area set 1 doesn't cover;



http://reviews.llvm.org/D13516



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

[clang-tools-extra] r250288 - Use __SIZE_TYPE__ to fix buildbot failures.

[Angel Garcia Gomez via cfe-commits]

Author: angelgarcia
Date: Wed Oct 14 05:30:32 2015
New Revision: 250288

URL: http://llvm.org/viewvc/llvm-project?rev=250288=rev
Log:
Use __SIZE_TYPE__ to fix buildbot failures.

Summary: Use __SIZE_TYPE__ to fix buildbot failures.

Reviewers: klimek

Subscribers: cfe-commits

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

Modified:
clang-tools-extra/trunk/test/clang-tidy/modernize-make-unique.cpp

Modified: clang-tools-extra/trunk/test/clang-tidy/modernize-make-unique.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/modernize-make-unique.cpp?rev=250288=250287=250288=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/modernize-make-unique.cpp (original)
+++ clang-tools-extra/trunk/test/clang-tidy/modernize-make-unique.cpp Wed Oct 
14 05:30:32 2015
@@ -48,7 +48,7 @@ struct Empty {};
 
 template using unique_ptr_ = std::unique_ptr;
 
-void *operator new(unsigned long Count, void *Ptr);
+void *operator new(__SIZE_TYPE__ Count, void *Ptr);
 
 int g(std::unique_ptr P);
 


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

Re: [PATCH] D13720: Use __SIZE_TYPE__ to fix buildbot failures.

[Manuel Klimek via cfe-commits]

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

lg


http://reviews.llvm.org/D13720



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

Re: [clang-tools-extra] r250283 - Support every kind of initialization.

[Renato Golin via cfe-commits]

On 14 October 2015 at 10:22, Angel Garcia Gomez via cfe-commits
 wrote:
> Author: angelgarcia
> Date: Wed Oct 14 04:22:32 2015
> New Revision: 250283
>
> URL: http://llvm.org/viewvc/llvm-project?rev=250283=rev
> Log:
> Support every kind of initialization.

Hi, this broke our ARM bots:

http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15/builds/6573
http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost/builds/5496



>  std::unique_ptr getPointer() {
> @@ -48,7 +58,7 @@ std::unique_ptr getPointer() {
>// CHECK-FIXES: return std::make_unique();
>  }

You probably just need to change to:

// CHECK-FIXES: return std::make_unique({{.*}});

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

[libcxx] r250361 - Add links to libc++ code coverage and builders

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Wed Oct 14 22:27:02 2015
New Revision: 250361

URL: http://llvm.org/viewvc/llvm-project?rev=250361=rev
Log:
Add links to libc++ code coverage and builders

Modified:
libcxx/trunk/docs/index.rst

Modified: libcxx/trunk/docs/index.rst
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/docs/index.rst?rev=250361=250360=250361=diff
==
--- libcxx/trunk/docs/index.rst (original)
+++ libcxx/trunk/docs/index.rst Wed Oct 14 22:27:02 2015
@@ -138,11 +138,13 @@ Design Documents
 
 .. __: 
https://cplusplusmusings.wordpress.com/2012/07/05/clang-and-standard-libraries-on-mac-os-x/
 
-Build Bots

+Build Bots and Test Coverage
+
 
 * `LLVM Buildbot Builders `_
 * `Apple Jenkins Builders `_
+* `EricWF's Nightly Builders `_
+* `Code Coverage Results `_
 
 Getting Involved
 


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

Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain

[Filipe Cabecinhas via cfe-commits]

Hi all,

I have harnessed the powers of time zones and did the last tweak we needed
to get it comitted.
It's still going through some bots, but I don't foresee big problems. The
fast bots liked it.

Thanks to everyone that reviewed it and worked on it!

  Filipe

On Wed, Oct 14, 2015 at 8:54 AM, Romanova, Katya <
katya_roman...@playstation.sony.com> wrote:

> Hi Sean,
>
>
>
> I don’t think that the whole patch should have been reverted. There were
> much easier way to make the PS4 bot green. A single test could have been
> marked as “XFAIL: ps4” for a few hours until a better solution is
> implemented. Reverting this huge patch is more drastic measure that might
> cause more problems later.
>
>
>
> As you saw in my previous email, I kept an eye on the bots, noticed the
> failure on PS4 buildbot, explained why it happened in the email and ask
> community for an opinion if it could be temporarily marked as “XFAIL” for
> ps4 only. I had to leave work at certain point. When I got home, I saw that
> you reverted the whole fix. Now I will have to go through all the pain with
> maintaining a huge commit, instead of making one line change affecting one
> of the tests on PS4 platform only… But, I guess, if it’s a general
> practice,  then it’s a different story. I was not aware of this practice
> and I thought that the other solution was much more reasonable.
>
>
>
> Thank you for letting me know about 
> LLVM_DEFAULT_TARGET_TRIPLE=x86_64-scei-ps4.
> I will definitely run it before the next commit.
>
>
>
> Katya.
>
>
>
>
>
> *From:* Sean Silva [mailto:chisophu...@gmail.com]
> *Sent:* Tuesday, October 13, 2015 11:56 PM
> *To:* Eric Christopher
> *Cc:* reviews+d13482+public+a1a9627af638c...@reviews.llvm.org; Romanova,
> Katya; Alex Rosenberg; Robinson, Paul; filcab+llvm.phabrica...@gmail.com;
> Jonathan Roelofs; Bedwell, Greg; pierregoussea...@gmail.com; Anton
> Korobeynikov; Takumi NAKAMURA; cfe-commits
> *Subject:* Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain
>
>
>
>
>
>
>
> On Tue, Oct 13, 2015 at 11:40 PM, Eric Christopher 
> wrote:
>
>
>
> On Tue, Oct 13, 2015 at 11:38 PM Sean Silva  wrote:
>
> On Tue, Oct 13, 2015 at 11:33 PM, Eric Christopher 
> wrote:
>
> It was already reverted, but I agree, let's get this fixed first.
>
>
>
> It was reintroduced in r250252. It is breaking
> http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/1362
>
>
>
>
>
> Ah, I missed that. Yeah, please go ahead and revert for now.
>
>
>
> reverted in r250273
>
> (bot is back to green:
> http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/1363
> )
>
>
>
> Katya - remember to run the tests
> with LLVM_DEFAULT_TARGET_TRIPLE=x86_64-scei-ps4 (and also remember to keep
> an eye on the bots after committing)
>
>
>
> -- Sean Silva
>
>
>
>
>
> Thanks!
>
>
>
> -eric
>
>
>
> -- Sean Silva
>
>
>
>
>
> Thanks!
>
>
>
> -eric
>
>
>
> On Tue, Oct 13, 2015 at 11:33 PM Sean Silva  wrote:
>
> On Tue, Oct 13, 2015 at 7:51 PM, Katya Romanova <
> katya_roman...@playstation.sony.com> wrote:
>
> kromanova added a comment.
>
> Hi,
>
> The initial PS4 patch caused a test failure (debug-options.c) on the PS4
> bot. I suspect that I know why the problem happens, but I'm not sure what
> will be the best way to handle it. If someone knows how to fix this test
> more "elegantly", I would appreciate their advice.
>
> FAIL: Clang :: Driver/debug-options.c (3509 of 24708)
>
> - TEST 'Clang :: Driver/debug-options.c' FAILED 
>
> Script:
> ---
>
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/clang
> -### -c -g
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
> -target x86_64-linux-gnu 2>&1  |
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
> -check-prefix=G /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-
> 
>
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/clang
> -### -g
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
> 2>&1 |
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
> -check-prefix=CI
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
>
> 

Re: [PATCH] D12922: Add support for function attribute "notail"

[Akira Hatanaka via cfe-commits]

ahatanak updated this revision to Diff 37437.
ahatanak added a comment.

Address some of the review comments:

- Added a c++ test which tests the c++ spelling of the attribute on member 
functions and shows which virtual functions calls get marked as "notail" in the 
IR.
- Added a check that was missing in always_inline attribute handler.
- Fixed test/Sema/attr-notail.c to test always_inline and notail are mutually 
exclusive, regardless of the order in which they are added to the function.


http://reviews.llvm.org/D12922

Files:
  include/clang/Basic/Attr.td
  include/clang/Basic/AttrDocs.td
  lib/CodeGen/CGCall.cpp
  lib/Sema/SemaDeclAttr.cpp
  test/CodeGen/attr-no-tail.c
  test/CodeGenCXX/attr-notail.cpp
  test/Sema/attr-notail.c

Index: test/Sema/attr-notail.c
===
--- /dev/null
+++ test/Sema/attr-notail.c
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+int callee0() __attribute__((notail,always_inline)); // expected-error{{'notail' and 'always_inline' attributes are not compatible}}
+int callee1() __attribute__((always_inline,notail)); // expected-error{{'always_inline' and 'notail' attributes are not compatible}}
+
+int foo(int a) {
+  return a ? callee0() : callee1();
+}
Index: test/CodeGenCXX/attr-notail.cpp
===
--- /dev/null
+++ test/CodeGenCXX/attr-notail.cpp
@@ -0,0 +1,46 @@
+// RUN: %clang_cc1 -triple=x86_64-apple-darwin -std=c++11 %s -emit-llvm -o - | FileCheck %s
+
+class Base {
+public:
+  [[clang::notail]] virtual int foo1() {
+return 0;
+  }
+  virtual ~Base() {}
+};
+
+class Derived1 : public Base {
+public:
+  int foo1() override {
+return 1;
+  }
+};
+
+class Derived2 : public Derived1 {
+public:
+  [[clang::notail]] int foo1() override {
+return 2;
+  }
+};
+
+// CHECK-LABEL: define i32 @_Z4foo1iP4BaseP8Derived1
+// CHECK: [[BASEFUNC:%[a-z0-9]+]] = load i32 (%class.Base*)*, i32 (%class.Base*)** {{%[a-z0-9]+}}
+// CHECK: {{%[a-z0-9]+}} = notail call i32 [[BASEFUNC]](%class.Base* {{%[a-z0-9]+}})
+// CHECK: [[DERIVEDFUNC1_1:%[a-z0-9]+]] = load i32 (%class.Derived1*)*, i32 (%class.Derived1*)** {{%[a-z0-9]+}}
+// CHECK: {{%[a-z0-9]+}} = call i32 [[DERIVEDFUNC1_1]](%class.Derived1* {{%[a-z0-9]+}})
+// CHECK: [[DERIVEDFUNC1_2:%[a-z0-9]+]] = load i32 (%class.Derived1*)*, i32 (%class.Derived1*)** {{%[a-z0-9]+}}
+// CHECK: {{%[a-z0-9]+}} = call i32 [[DERIVEDFUNC1_2]](%class.Derived1* {{%[a-z0-9]+}})
+// CHECK: [[DERIVEDFUNC2:%[a-z0-9]+]] = load i32 (%class.Derived2*)*, i32 (%class.Derived2*)** {{%[a-z0-9]+}}
+// CHECK: {{%[a-z0-9]+}} = notail call i32 [[DERIVEDFUNC2]](%class.Derived2* {{%[a-z0-9]+}})
+
+int foo1(int a, Base *b, Derived1 *d) {
+  if (a > 1)
+return b->foo1(); // Tail-call is prevented.
+  if (a < 0)
+return d->foo1(); // Tail-call is not prevented.
+  if (a == 0) {
+Derived1 *i = new Derived2(); // Tail-call is not prevented.
+return i->foo1();
+  }
+  Derived2 *i = new Derived2(); // Tail-call is prevented.
+  return i->foo1();
+}
Index: test/CodeGen/attr-no-tail.c
===
--- /dev/null
+++ test/CodeGen/attr-no-tail.c
@@ -0,0 +1,33 @@
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.7.0 %s -emit-llvm -o - | FileCheck %s
+
+// CHECK: %{{[a-z0-9]+}} = notail call i32 @callee0(i32 %
+// CHECK: %{{[a-z0-9]+}} = notail call i32 @callee1(i32 %
+
+// Check that indirect calls do not have the notail marker.
+// CHECK: store i32 (i32)* @callee1, i32 (i32)** [[ALLOCA1:%[A-Za-z0-9]+]], align 8
+// CHECK: [[INDIRFUNC:%[0-9]+]] = load i32 (i32)*, i32 (i32)** [[ALLOCA1]], align 8
+// CHECK: %{{[a-z0-9]+}} = call i32 [[INDIRFUNC]](i32 %6)
+
+// CHECK: %{{[a-z0-9]+}} = call i32 @callee2(i32 %
+
+int callee0(int a) __attribute__((notail)) {
+  return a + 1;
+}
+
+int callee1(int) __attribute__((notail));
+
+int callee2(int);
+
+typedef int (*FuncTy)(int);
+
+int foo0(int a) {
+  if (a > 1)
+return callee0(a);
+  if (a == 1)
+return callee1(a);
+  if (a < 0) {
+FuncTy F = callee1;
+return (*F)(a);
+  }
+  return callee2(a);
+}
Index: lib/Sema/SemaDeclAttr.cpp
===
--- lib/Sema/SemaDeclAttr.cpp
+++ lib/Sema/SemaDeclAttr.cpp
@@ -1701,6 +1701,14 @@
Attr.getAttributeSpellingListIndex()));
 }
 
+static void handleNoTailAttr(Sema , Decl *D, const AttributeList ) {
+  if (checkAttrMutualExclusion(S, D, Attr))
+return;
+
+  D->addAttr(::new (S.Context) NoTailAttr(
+  Attr.getRange(), S.Context, Attr.getAttributeSpellingListIndex()));
+}
+
 static void handleUsedAttr(Sema , Decl *D, const AttributeList ) {
   if (const VarDecl *VD = dyn_cast(D)) {
 if (VD->hasLocalStorage()) {
@@ -3335,6 +3343,9 @@
 
 static void handleAlwaysInlineAttr(Sema , Decl *D,
const AttributeList ) {
+  if (checkAttrMutualExclusion(S, D, 

Re: [PATCH] D12922: Add support for function attribute "notail"

[Akira Hatanaka via cfe-commits]

ahatanak marked an inline comment as done.


Comment at: include/clang/Basic/AttrDocs.td:1619
@@ +1618,3 @@
+  let Content = [{
+Tail call optimization is not performed on direct calls to a function marked 
``notail``.
+  }];

Perhaps direct call isn't the right term to use for this attribute. I'm still 
trying to figure out the best way to handle c++ virtual functions: this 
attribute is not very useful for someone who is looking for a way to reliably 
prevent tail-call to a virtual function.


http://reviews.llvm.org/D12922



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

Re: [PATCH] D12922: Add support for function attribute "notail"

[Duncan P. N. Exon Smith via cfe-commits]

> On 2015-Oct-13, at 09:55, Aaron Ballman  wrote:
> 
> aaron.ballman added a comment.
> 
> In http://reviews.llvm.org/D12922#265452, @ahatanak wrote:
> 
>> I think there are a couple of things that have to be discussed:
>> 
>> 1. Name of the attribute: Should it be "notail" or "notailcall"? Perhaps it 
>> should be named something like "nodirecttail" to indicate it is used to 
>> block direct calls, but not indirect calls?
> 
> 
> The attribute prevents tail calls from the call site, not for the function 
> itself. "notail", at least to me, implies that the function definition itself 
> will not have TCO; it does not imply that callers will be affected. Perhaps 
> "not_tail_called" or "disable_tail_calls"? It's a hard concept to get across 
> in a small identifier.

Note that LLVM has an IR-level attribute called "disabletailcails" that implies 
that the function definition itself will not have TCO.

I like notailcall because of its relation to noinline.  They're both structured 
like "no", and both apply to what callers can do.

I don't really have a strong opinion though, just sharing those thoughts.

> 
> Also, I would like to see a test that shows always_inline, notail also gets 
> diagnosed as mutually exclusive, and a test that the right thing happens with 
> a C++ spelling on a member function.
> 
> ~Aaron
> 
> 
> 
> Comment at: include/clang/Basic/AttrDocs.td:1619
> @@ +1618,3 @@
> +  let Content = [{
> +Tail call optimization is not performed on direct calls to a function marked 
> ``notail``.
> +  }];
> 
> It would be good to clarify what you mean by direct calls, as not all of the 
> readers are going to understand that easily. Perhaps a simple code example 
> showing a call to the function, and a call to the same function through a 
> function pointer, with comments showing which one has TCO.
> 
> You should also call out that it is mutually exclusive with always_inline.
> 
> 
> Comment at: lib/Sema/SemaDeclAttr.cpp:1705
> @@ +1704,3 @@
> +static void handleNoTailAttr(Sema , Decl *D, const AttributeList ) {
> +  if (checkAttrMutualExclusion(S, D, Attr))
> +return;
> 
> Missing the same check in the always_inline attribute handler.
> 
> 
> http://reviews.llvm.org/D12922
> 
> 
> 

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

Re: [PATCH] D13516: Fix overlapping replacements in clang-tidy.

[Manuel Klimek via cfe-commits]

klimek added a comment.

LG in general now, looks to me like we have very few tests though.
My favorite strategy to make sure I have enough tests is to comment out code 
(or do mutations) as long as the tests still pass. Then write tests that fail 
with the mutation, then undo the mutation.



Comment at: clang-tidy/ClangTidyDiagnosticConsumer.cpp:492-493
@@ +491,4 @@
+
+  // Build the sets of intervals, and their bounding boxes.
+  unsigned NumErrors = Errors.size();
+  for (unsigned I = 0; I < NumErrors; ++I) {

I think a comment at the top of this function outlining the full algorithm 
would be nice (without lots of details).


Comment at: clang-tidy/ClangTidyDiagnosticConsumer.cpp:519-521
@@ +518,5 @@
+  std::vector Apply(NumErrors, true);
+  // We use a set because we want the functionality of a priority queue but we
+  // also need to iterate over the elements.
+  std::set> Queue;
+  for (unsigned I = 0; I < Shapes.size(); ++I) {

Document what goes into the pair - I assumed 'first, second' for a moment, and 
then was confused.


http://reviews.llvm.org/D13516



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

Re: [PATCH] D12614: [OpenMP] Offloading descriptor registration and device codegen.

[Alexey Bataev via cfe-commits]

ABataev added inline comments.


Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:1962
@@ +1961,3 @@
+[LineNum][ColNum];
+assert(Entry.Order != -1u && "Entry not initialized!");
+assert(!Entry.Addr && !Entry.ID && "Entry registered already!");

~0u


Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:2349
@@ +2348,3 @@
+TgtBinaryDescriptorTy = llvm::StructType::create(
+"tgt_bin_desc", CGM.Int32Ty, getTgtDeviceImageTy()->getPointerTo(),
+getTgtOffloadEntryTy()->getPointerTo(),

I think there should be 4-bytes padding between NumDevices and DeviceImages 
fields in 64-bit mode, right? It is better to create this structure as clang 
AST RecordDecl/CXXRecordDecl and then use CGM.getTypes().ConvertTypeForMem().


Comment at: lib/CodeGen/CGOpenMPRuntime.h:325-328
@@ +324,6 @@
+  public:
+CodeGenModule 
+
+/// \brief Number of entries registered so far.
+unsigned OffloadingEntriesNum;
+

I think these members must be private.


Comment at: lib/CodeGen/CGOpenMPRuntime.h:339
@@ +338,3 @@
+// Invalid entry info.
+OFFLOAD_ENTRY_INFO_INVALID = -1u
+  };

Better ~0


Comment at: lib/CodeGen/CGOpenMPRuntime.h:343
@@ +342,3 @@
+  // \brief Order this entry was emitted.
+  unsigned Order;
+

Make it private/protected also


Comment at: lib/CodeGen/CGOpenMPRuntime.h:345
@@ +344,3 @@
+
+  OffloadEntryInfo() : Order(-1u), Kind(OFFLOAD_ENTRY_INFO_INVALID) {}
+  OffloadEntryInfo(OffloadingEntryInfoKinds Kind, unsigned Order)

explicit, ~0u


Comment at: lib/CodeGen/CGOpenMPRuntime.h:367-370
@@ +366,6 @@
+public:
+  // \brief Address of the entity that has to be mapped for offloading.
+  llvm::Constant *Addr;
+  // \brief Address that can be used as the ID of the entry.
+  llvm::Constant *ID;
+

Private/protected


Comment at: lib/CodeGen/CGOpenMPRuntime.h:372
@@ +371,3 @@
+
+  OffloadEntryInfoTargetRegion()
+  : OffloadEntryInfo(OFFLOAD_ENTRY_INFO_TARGET_REGION, -1u),

explicit


Comment at: lib/CodeGen/CGOpenMPRuntime.h:373
@@ +372,3 @@
+  OffloadEntryInfoTargetRegion()
+  : OffloadEntryInfo(OFFLOAD_ENTRY_INFO_TARGET_REGION, -1u),
+Addr(nullptr), ID(nullptr) {}

~0u


Comment at: lib/CodeGen/CGOpenMPRuntime.h:957-967
@@ -759,1 +956,13 @@
+
+  /// \brief Notify the runtime implementation that a user function definition
+  /// is about to be emmited.
+  /// \param GD Declaration of the function definition that will be emitted.
+  void pushCurrentUserFunction(GlobalDecl GD);
+
+  /// \brief Notify the runtime implementation that the emission of the current
+  /// user function is finished.
+  void popCurrentUserFunction();
+
+  /// \brief Get the declaration of the current user function being emitted.
+  StringRef getCurrentUserFunction();
 };

Do we really need this stuff? CodeGenFunction has member CurFuncDecl, which, it 
seems, could give you required info without these functions.


http://reviews.llvm.org/D12614



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

r250369 - [X86] Add proper feature names to xsave builtins.

[Craig Topper via cfe-commits]

Author: ctopper
Date: Thu Oct 15 00:23:46 2015
New Revision: 250369

URL: http://llvm.org/viewvc/llvm-project?rev=250369=rev
Log:
[X86] Add proper feature names to xsave builtins.

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

Modified: cfe/trunk/include/clang/Basic/BuiltinsX86.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsX86.def?rev=250369=250368=250369=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsX86.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsX86.def Thu Oct 15 00:23:46 2015
@@ -666,18 +666,18 @@ BUILTIN(__builtin_ia32_fxsave, "vv*", ""
 BUILTIN(__builtin_ia32_fxsave64, "vv*", "")
 
 // XSAVE
-BUILTIN(__builtin_ia32_xsave, "vv*ULLi", "")
-BUILTIN(__builtin_ia32_xsave64, "vv*ULLi", "")
-BUILTIN(__builtin_ia32_xrstor, "vv*ULLi", "")
-BUILTIN(__builtin_ia32_xrstor64, "vv*ULLi", "")
-BUILTIN(__builtin_ia32_xsaveopt, "vv*ULLi", "")
-BUILTIN(__builtin_ia32_xsaveopt64, "vv*ULLi", "")
-BUILTIN(__builtin_ia32_xrstors, "vv*ULLi", "")
-BUILTIN(__builtin_ia32_xrstors64, "vv*ULLi", "")
-BUILTIN(__builtin_ia32_xsavec, "vv*ULLi", "")
-BUILTIN(__builtin_ia32_xsavec64, "vv*ULLi", "")
-BUILTIN(__builtin_ia32_xsaves, "vv*ULLi", "")
-BUILTIN(__builtin_ia32_xsaves64, "vv*ULLi", "")
+TARGET_BUILTIN(__builtin_ia32_xsave, "vv*ULLi", "", "xsave")
+TARGET_BUILTIN(__builtin_ia32_xsave64, "vv*ULLi", "", "xsave")
+TARGET_BUILTIN(__builtin_ia32_xrstor, "vv*ULLi", "", "xsave")
+TARGET_BUILTIN(__builtin_ia32_xrstor64, "vv*ULLi", "", "xsave")
+TARGET_BUILTIN(__builtin_ia32_xsaveopt, "vv*ULLi", "", "xsaveopt")
+TARGET_BUILTIN(__builtin_ia32_xsaveopt64, "vv*ULLi", "", "xsaveopt")
+TARGET_BUILTIN(__builtin_ia32_xrstors, "vv*ULLi", "", "xsaves")
+TARGET_BUILTIN(__builtin_ia32_xrstors64, "vv*ULLi", "", "xsaves")
+TARGET_BUILTIN(__builtin_ia32_xsavec, "vv*ULLi", "", "xsavec")
+TARGET_BUILTIN(__builtin_ia32_xsavec64, "vv*ULLi", "", "xsavec")
+TARGET_BUILTIN(__builtin_ia32_xsaves, "vv*ULLi", "", "xsaves")
+TARGET_BUILTIN(__builtin_ia32_xsaves64, "vv*ULLi", "", "xsaves")
 
 // ADX
 TARGET_BUILTIN(__builtin_ia32_addcarryx_u32, "UcUcUiUiUi*", "", "adx")


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

[PATCH] D13765: clang-format: [JS] Handle string literals spanning character classes.

[Martin Probst via cfe-commits]

mprobst created this revision.
mprobst added a reviewer: djasper.
mprobst added subscribers: klimek, cfe-commits.

If a RegExp contains a character group with a quote (`/["]/`), the
trailing end of it is first tokenized as a string literal, which leads
to the merging code seeing an unbalanced bracket.

This change parses regex literals from the left hand side. That
simplifies the parsing code and also allows correctly handling escapes
and character classes, hopefully correctly parsing all regex literals.

http://reviews.llvm.org/D13765

Files:
  lib/Format/Format.cpp
  unittests/Format/FormatTestJS.cpp

Index: unittests/Format/FormatTestJS.cpp
===
--- unittests/Format/FormatTestJS.cpp
+++ unittests/Format/FormatTestJS.cpp
@@ -625,6 +625,9 @@
   verifyFormat("var regex = /[\\/]/;");
   verifyFormat("var regex = /\\[/;");
   verifyFormat("var regex = /[/]/;");
+  verifyFormat("var regex = /}[\"]/;");
+  verifyFormat("var regex = /}[/\"]/;");
+  verifyFormat("var regex = /}[\"/]/;");
 
   verifyFormat("var regex = /\\b/;");
   verifyFormat("var regex = /\\B/;");
Index: lib/Format/Format.cpp
===
--- lib/Format/Format.cpp
+++ lib/Format/Format.cpp
@@ -730,6 +730,8 @@
 assert(FirstInLineIndex == 0);
 do {
   Tokens.push_back(getNextToken());
+  if (Style.Language == FormatStyle::LK_JavaScript)
+tryParseJSRegexLiteral();
   tryMergePreviousTokens();
   if (Tokens.back()->NewlinesBefore > 0 || Tokens.back()->IsMultiline)
 FirstInLineIndex = Tokens.size() - 1;
@@ -749,10 +751,6 @@
   return;
 
 if (Style.Language == FormatStyle::LK_JavaScript) {
-  if (tryMergeJSRegexLiteral())
-return;
-  if (tryMergeEscapeSequence())
-return;
   if (tryMergeTemplateString())
 return;
 
@@ -824,107 +822,95 @@
 return true;
   }
 
-  // Tries to merge an escape sequence, i.e. a "\\" and the following
-  // character. Use e.g. inside JavaScript regex literals.
-  bool tryMergeEscapeSequence() {
-if (Tokens.size() < 2)
-  return false;
-FormatToken *Previous = Tokens[Tokens.size() - 2];
-if (Previous->isNot(tok::unknown) || Previous->TokenText != "\\")
-  return false;
-++Previous->ColumnWidth;
-StringRef Text = Previous->TokenText;
-Previous->TokenText = StringRef(Text.data(), Text.size() + 1);
-resetLexer(SourceMgr.getFileOffset(Tokens.back()->Tok.getLocation()) + 1);
-Tokens.resize(Tokens.size() - 1);
-Column = Previous->OriginalColumn + Previous->ColumnWidth;
-return true;
+  // Returns \c true if \p Tok can only be followed by an operand in JavaScript.
+  bool PrecedesOperand(FormatToken *Tok) {
+// NB: This is not entirely correct, as an r_paren can introduce an operand
+// location in e.g. `if (foo) /bar/.exec(...);`. That is a rare enough
+// corner case to not matter in practice, though.
+return (Tok->isOneOf(tok::period, tok::l_paren, tok::comma, tok::l_brace,
+ tok::r_brace, tok::l_square, tok::semi, tok::exclaim,
+ tok::colon, tok::question, tok::tilde) ||
+Tok->isOneOf(tok::kw_return, tok::kw_do, tok::kw_case,
+ tok::kw_throw, tok::kw_else, tok::kw_new,
+ tok::kw_delete, tok::kw_void, tok::kw_typeof,
+ Keywords.kw_instanceof, Keywords.kw_in) ||
+Tok->isBinaryOperator());
   }
 
-  // Try to determine whether the current token ends a JavaScript regex literal.
-  // We heuristically assume that this is a regex literal if we find two
-  // unescaped slashes on a line and the token before the first slash is one of
-  // "(;,{}![:?", a binary operator or 'return', as those cannot be followed by
-  // a division.
-  bool tryMergeJSRegexLiteral() {
-if (Tokens.size() < 2)
-  return false;
+  // Tries to parse a JavaScript Regex literal starting at the current token,
+  // if that begins with a slash and is in a location where JavaScript allows
+  // regex literals. Changes the current token to a regex literal and updates
+  // its text if successful.
+  void tryParseJSRegexLiteral() {
+FormatToken *RegexToken = Tokens.back();
+if (!RegexToken->isOneOf(tok::slash, tok::slashequal))
+  return;
 
-// If this is a string literal with a slash inside, compute the slash's
-// offset and try to find the beginning of the regex literal.
-// Also look at tok::unknown, as it can be an unterminated char literal.
-size_t SlashInStringPos = StringRef::npos;
-if (Tokens.back()->isOneOf(tok::string_literal, tok::char_constant,
-   tok::unknown)) {
-  // Start search from position 1 as otherwise, this is an unknown token
-  // for an unterminated /*-comment which is handled elsewhere.
-  SlashInStringPos = Tokens.back()->TokenText.find('/', 1);
-