Re: [PATCH] Fix "warning: fallthrough annotation does not directly precede switch label" in lambdas.

[Richard Smith]

Yes, the extra test would be good. Thanks!
On 24 Jun 2014 18:08, "Alexander Kornienko"  wrote:

> On Tue, Jun 24, 2014 at 4:43 PM, Richard Smith 
> wrote:
>
>> LGTM
>>
>> If blocks also need a fix, feel free to do that in a later patch :)
>>
>
> Oh, you're right, I didn't think about blocks. For some reason bodies of
> blocks are not duplicated in the AST, as it is with lambdas, so the warning
> works fine with them. If you want, I can add a test for this:
>
> $ cat test/SemaCXX/switch-implicit-fallthrough-blocks.cpp
> // RUN: %clang_cc1 -fsyntax-only -verify -fblocks -std=c++11 
> -Wimplicit-fallthrough %s
>
> void fallthrough_in_blocks() {
>   void (^block)() = ^{
> int x = 0;
> switch (x) {
> case 0:
>   x++;
>   [[clang::fallthrough]]; // no diagnostics
> case 1:
>   x++;
> default: // \
> expected-warning{{unannotated fall-through between switch labels}} \
> expected-note{{insert 'break;' to avoid fall-through}}
>   break;
> }
>   };
>   block();
> }
>
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH} Remove '.bc' input support from the frontend

[Alexey Bataev]

I've definitely used the feature before and likely will again. That
said I personally don't mind doing llvm-dis on a bc file before doing
it.

The main reason to keep some aspect of the functionality: It's the
only way to be sure you're actually passing a bit of bitcode through
the precise pipeline that clang has set up.

-eric


We're using this feature often and it would be good to keep it. Alp, it 
would be good to find another solution rather than remove .bc 
compilation support from clang.


Best regards,
Alexey Bataev
=
Software Engineer
Intel Compiler Team



___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH} Remove '.bc' input support from the frontend

[Eric Christopher]

On Tue, Jun 24, 2014 at 11:11 PM, David Blaikie  wrote:
> On Tue, Jun 24, 2014 at 11:01 PM, Alp Toker  wrote:
>>
>> On 25/06/2014 08:42, David Blaikie wrote:
>>>
>>> On Tue, Jun 24, 2014 at 10:31 PM, Alp Toker  wrote:

 The attached patch removes code that apparently supported '.bc' binary
 LLVM
 bitcode as a frontend input kind.

 There were no tests and it's unclear if it was in a working state.
>>>
>>> That's vaguely surprising.
>>>
 I'm
 comfortable removing this because it doesn't really align with the
 frontend's primary objective of diagnosing textual input and lowering
 source
 code.
>>>
>>> It seems about as likely that someone would use this as they would use
>>> .ll input files. I'm not sure how likely either is. As a developer I
>>> usually use the llc, etc, tools - but sometimes I pass bitcode to
>>> clang to link (possibly after using llvm-link to link two bitcode
>>> files together & I want a linker invocation that has all the standard
>>> libraries, etc rather than trying to invoke the linker myself or do
>>> two steps of assemble+link).
>>
>>
>> It feels a little odd to push bitcode binaries through the frontend source
>> code parsing and diagnostic paths. Perhaps the driver could handle that?
>>
>> I figured the use case is to produce clang-style diagnostics that can be
>> serialized, formatted to support different IDEs and editors etc. and that
>> would only be relevant to '.ll'.
>>
>> No strong inclination either way though if you know better.
>>
>>
>>>
 The removal lets us parse and diagnose '.ll' IR inputs more efficiently
 without duplicating file contents into memory.
>>>
>>> Curious - how's that the case?
>>
>>
>> ParseAssembly() parses '.ll' source code and uses a LLVM SourceMgr, so has
>> the same underlying reference counting scheme as clang's SourceManager. That
>> means we get to not copy the whole file into memory:
>>
 -// FIXME: This is stupid, IRReader shouldn't take ownership.
 -llvm::MemoryBuffer *MainFileCopy =
 - llvm::MemoryBuffer::getMemBufferCopy(MainFile->getBuffer(),
 -   getCurrentFile());
 -
  llvm::SMDiagnostic Err;
 -TheModule.reset(ParseIR(MainFileCopy, Err, *VMContext));
 +TheModule.reset(ParseAssembly(const_cast(MainFile),
 nullptr,
 +  Err, *VMContext));
>>
>>
>> ParseIR() takes the LazyIRModule path if the input is binary, and that path
>> steals ownership which forces us to always copy.
>
> Takes ownership of the MemoryBuffer, is that it? You could just create
> a shallow MemoryBuffer (MemoryBuffer::getMemBuffer - it doesn't own
> the underlying memory) and give that to ParseIR - it can own the
> MemoryBuffer all it wants, that doesn't have to copy all that data.
> Would that suffice? (and/or presumably we could fix the acutal FIXME
> and just have that whole API not take ownership, ever?)
>
> (CC'ing Lang again - because of the ongoing saga of MemoryBuffer, its
> weird/conditional/dynamic ownership semantics, etc - something he and
> I are having ongoing (if rather unactioned) conversations about)
>
>>
>>
>>>
 (If there's desire to keep '.bc' support and someone contributes tests
 for
 it, I'm fine to explore other ways to achieve this optimisation.)
>>
>>
>> If you want to keep the feature, I can look into spinning the memory saving
>> another way.
>
> I'm not terribly invested in it - just mentioning that I /think/ I've
> relied on this feature on at least a few occasions but it wouldn't be
> hard for me to workaround - just one data point. Others may chime in
> with clearer views.
>

I've definitely used the feature before and likely will again. That
said I personally don't mind doing llvm-dis on a bc file before doing
it.

The main reason to keep some aspect of the functionality: It's the
only way to be sure you're actually passing a bit of bitcode through
the precise pipeline that clang has set up. :)

-eric

> - David
>
>> Alp.
>>
>>
>>

 Requires the recently posted MemoryBuffer patch.

 Alp.

 --
 http://www.nuanti.com
 the browser experts


 ___
 cfe-commits mailing list
 cfe-commits@cs.uiuc.edu
 http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

>>
>> --
>> http://www.nuanti.com
>> the browser experts
>>
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH} Remove '.bc' input support from the frontend

[David Blaikie]

On Tue, Jun 24, 2014 at 11:01 PM, Alp Toker  wrote:
>
> On 25/06/2014 08:42, David Blaikie wrote:
>>
>> On Tue, Jun 24, 2014 at 10:31 PM, Alp Toker  wrote:
>>>
>>> The attached patch removes code that apparently supported '.bc' binary
>>> LLVM
>>> bitcode as a frontend input kind.
>>>
>>> There were no tests and it's unclear if it was in a working state.
>>
>> That's vaguely surprising.
>>
>>> I'm
>>> comfortable removing this because it doesn't really align with the
>>> frontend's primary objective of diagnosing textual input and lowering
>>> source
>>> code.
>>
>> It seems about as likely that someone would use this as they would use
>> .ll input files. I'm not sure how likely either is. As a developer I
>> usually use the llc, etc, tools - but sometimes I pass bitcode to
>> clang to link (possibly after using llvm-link to link two bitcode
>> files together & I want a linker invocation that has all the standard
>> libraries, etc rather than trying to invoke the linker myself or do
>> two steps of assemble+link).
>
>
> It feels a little odd to push bitcode binaries through the frontend source
> code parsing and diagnostic paths. Perhaps the driver could handle that?
>
> I figured the use case is to produce clang-style diagnostics that can be
> serialized, formatted to support different IDEs and editors etc. and that
> would only be relevant to '.ll'.
>
> No strong inclination either way though if you know better.
>
>
>>
>>> The removal lets us parse and diagnose '.ll' IR inputs more efficiently
>>> without duplicating file contents into memory.
>>
>> Curious - how's that the case?
>
>
> ParseAssembly() parses '.ll' source code and uses a LLVM SourceMgr, so has
> the same underlying reference counting scheme as clang's SourceManager. That
> means we get to not copy the whole file into memory:
>
>>> -// FIXME: This is stupid, IRReader shouldn't take ownership.
>>> -llvm::MemoryBuffer *MainFileCopy =
>>> - llvm::MemoryBuffer::getMemBufferCopy(MainFile->getBuffer(),
>>> -   getCurrentFile());
>>> -
>>>  llvm::SMDiagnostic Err;
>>> -TheModule.reset(ParseIR(MainFileCopy, Err, *VMContext));
>>> +TheModule.reset(ParseAssembly(const_cast(MainFile),
>>> nullptr,
>>> +  Err, *VMContext));
>
>
> ParseIR() takes the LazyIRModule path if the input is binary, and that path
> steals ownership which forces us to always copy.

Takes ownership of the MemoryBuffer, is that it? You could just create
a shallow MemoryBuffer (MemoryBuffer::getMemBuffer - it doesn't own
the underlying memory) and give that to ParseIR - it can own the
MemoryBuffer all it wants, that doesn't have to copy all that data.
Would that suffice? (and/or presumably we could fix the acutal FIXME
and just have that whole API not take ownership, ever?)

(CC'ing Lang again - because of the ongoing saga of MemoryBuffer, its
weird/conditional/dynamic ownership semantics, etc - something he and
I are having ongoing (if rather unactioned) conversations about)

>
>
>>
>>> (If there's desire to keep '.bc' support and someone contributes tests
>>> for
>>> it, I'm fine to explore other ways to achieve this optimisation.)
>
>
> If you want to keep the feature, I can look into spinning the memory saving
> another way.

I'm not terribly invested in it - just mentioning that I /think/ I've
relied on this feature on at least a few occasions but it wouldn't be
hard for me to workaround - just one data point. Others may chime in
with clearer views.

- David

> Alp.
>
>
>
>>>
>>> Requires the recently posted MemoryBuffer patch.
>>>
>>> Alp.
>>>
>>> --
>>> http://www.nuanti.com
>>> the browser experts
>>>
>>>
>>> ___
>>> cfe-commits mailing list
>>> cfe-commits@cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>>
>
> --
> http://www.nuanti.com
> the browser experts
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH} Remove '.bc' input support from the frontend

[Alp Toker]

On 25/06/2014 08:42, David Blaikie wrote:

On Tue, Jun 24, 2014 at 10:31 PM, Alp Toker  wrote:

The attached patch removes code that apparently supported '.bc' binary LLVM
bitcode as a frontend input kind.

There were no tests and it's unclear if it was in a working state.

That's vaguely surprising.


I'm
comfortable removing this because it doesn't really align with the
frontend's primary objective of diagnosing textual input and lowering source
code.

It seems about as likely that someone would use this as they would use
.ll input files. I'm not sure how likely either is. As a developer I
usually use the llc, etc, tools - but sometimes I pass bitcode to
clang to link (possibly after using llvm-link to link two bitcode
files together & I want a linker invocation that has all the standard
libraries, etc rather than trying to invoke the linker myself or do
two steps of assemble+link).


It feels a little odd to push bitcode binaries through the frontend 
source code parsing and diagnostic paths. Perhaps the driver could 
handle that?


I figured the use case is to produce clang-style diagnostics that can be 
serialized, formatted to support different IDEs and editors etc. and 
that would only be relevant to '.ll'.


No strong inclination either way though if you know better.




The removal lets us parse and diagnose '.ll' IR inputs more efficiently
without duplicating file contents into memory.

Curious - how's that the case?


ParseAssembly() parses '.ll' source code and uses a LLVM SourceMgr, so 
has the same underlying reference counting scheme as clang's 
SourceManager. That means we get to not copy the whole file into memory:



-// FIXME: This is stupid, IRReader shouldn't take ownership.
-llvm::MemoryBuffer *MainFileCopy =
- llvm::MemoryBuffer::getMemBufferCopy(MainFile->getBuffer(),
-   getCurrentFile());
-
 llvm::SMDiagnostic Err;
-TheModule.reset(ParseIR(MainFileCopy, Err, *VMContext));
+TheModule.reset(ParseAssembly(const_cast*>(MainFile), nullptr,

+  Err, *VMContext));


ParseIR() takes the LazyIRModule path if the input is binary, and that 
path steals ownership which forces us to always copy.





(If there's desire to keep '.bc' support and someone contributes tests for
it, I'm fine to explore other ways to achieve this optimisation.)


If you want to keep the feature, I can look into spinning the memory 
saving another way.


Alp.




Requires the recently posted MemoryBuffer patch.

Alp.

--
http://www.nuanti.com
the browser experts


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits



--
http://www.nuanti.com
the browser experts

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r211665 - [Driver] Follow-up to r211598, r211663. Do not build a dynamic linker

[NAKAMURA Takumi]

Thanks. I was afraid to expand pre-concatenated strings. Bug it was trivial. ;)

2014-06-25 14:00 GMT+09:00 Simon Atanasyan :
> Author: atanasyan
> Date: Wed Jun 25 00:00:59 2014
> New Revision: 211665
>
> URL: http://llvm.org/viewvc/llvm-project?rev=211665&view=rev
> Log:
> [Driver] Follow-up to r211598, r211663. Do not build a dynamic linker
> path using sub-strings concatenation. Return the whole string explicitly.
>
> Modified:
> cfe/trunk/lib/Driver/Tools.cpp
>
> Modified: cfe/trunk/lib/Driver/Tools.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=211665&r1=211664&r2=211665&view=diff
> ==
> --- cfe/trunk/lib/Driver/Tools.cpp (original)
> +++ cfe/trunk/lib/Driver/Tools.cpp Wed Jun 25 00:00:59 2014
> @@ -6929,8 +6929,8 @@ static void AddLibgcc(const llvm::Triple
>  CmdArgs.push_back("-ldl");
>  }
>
> -static Twine getLinuxDynamicLinker(const ArgList &Args,
> -   const toolchains::Linux &ToolChain) {
> +static StringRef getLinuxDynamicLinker(const ArgList &Args,
> +   const toolchains::Linux &ToolChain) {
>if (ToolChain.getTriple().getEnvironment() == llvm::Triple::Android) {
>  if (ToolChain.getTriple().isArch64Bit())
>return "/system/bin/linker64";
> @@ -6964,11 +6964,11 @@ static Twine getLinuxDynamicLinker(const
>  return "/lib/ld.so.1";
>} else if (ToolChain.getArch() == llvm::Triple::mips64 ||
>   ToolChain.getArch() == llvm::Triple::mips64el) {
> -Twine LinkerFile =
> -mips::isNaN2008(Args) ? "ld-linux-mipsn8.so.1" : "ld.so.1";
>  if (mips::hasMipsAbiArg(Args, "n32"))
> -  return "/lib32/" + LinkerFile;
> -return "/lib64/" + LinkerFile;
> +  return mips::isNaN2008(Args) ? "/lib32/ld-linux-mipsn8.so.1"
> +   : "/lib32/ld.so.1";
> +return mips::isNaN2008(Args) ? "/lib64/ld-linux-mipsn8.so.1"
> + : "/lib64/ld.so.1";
>} else if (ToolChain.getArch() == llvm::Triple::ppc)
>  return "/lib/ld.so.1";
>else if (ToolChain.getArch() == llvm::Triple::ppc64 ||
>
>
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Don't eagerly evaluate the TypeSourceInfo when mangling names.

[Zachary Turner]

Closed by commit rL211667 (authored by @zturner).

REPOSITORY
  rL LLVM

http://reviews.llvm.org/D4281

Files:
  cfe/trunk/lib/AST/MicrosoftMangle.cpp

Index: cfe/trunk/lib/AST/MicrosoftMangle.cpp
===
--- cfe/trunk/lib/AST/MicrosoftMangle.cpp
+++ cfe/trunk/lib/AST/MicrosoftMangle.cpp
@@ -418,11 +418,11 @@
   // ::=   # pointers, references
   // Pointers and references are odd. The type of 'int * const foo;' gets
   // mangled as 'QAHA' instead of 'PAHB', for example.
-  TypeLoc TL = VD->getTypeSourceInfo()->getTypeLoc();
+  SourceRange SR = VD->getSourceRange();
   QualType Ty = VD->getType();
   if (Ty->isPointerType() || Ty->isReferenceType() ||
   Ty->isMemberPointerType()) {
-mangleType(Ty, TL.getSourceRange(), QMM_Drop);
+mangleType(Ty, SR, QMM_Drop);
 manglePointerExtQualifiers(
 Ty.getDesugaredType(getASTContext()).getLocalQualifiers(), nullptr);
 if (const MemberPointerType *MPT = Ty->getAs()) {
@@ -440,7 +440,7 @@
 else
   mangleQualifiers(Ty.getQualifiers(), false);
   } else {
-mangleType(Ty, TL.getSourceRange(), QMM_Drop);
+mangleType(Ty, SR, QMM_Drop);
 mangleQualifiers(Ty.getLocalQualifiers(), false);
   }
 }
Index: cfe/trunk/lib/AST/MicrosoftMangle.cpp
===
--- cfe/trunk/lib/AST/MicrosoftMangle.cpp
+++ cfe/trunk/lib/AST/MicrosoftMangle.cpp
@@ -418,11 +418,11 @@
   // ::=   # pointers, references
   // Pointers and references are odd. The type of 'int * const foo;' gets
   // mangled as 'QAHA' instead of 'PAHB', for example.
-  TypeLoc TL = VD->getTypeSourceInfo()->getTypeLoc();
+  SourceRange SR = VD->getSourceRange();
   QualType Ty = VD->getType();
   if (Ty->isPointerType() || Ty->isReferenceType() ||
   Ty->isMemberPointerType()) {
-mangleType(Ty, TL.getSourceRange(), QMM_Drop);
+mangleType(Ty, SR, QMM_Drop);
 manglePointerExtQualifiers(
 Ty.getDesugaredType(getASTContext()).getLocalQualifiers(), nullptr);
 if (const MemberPointerType *MPT = Ty->getAs()) {
@@ -440,7 +440,7 @@
 else
   mangleQualifiers(Ty.getQualifiers(), false);
   } else {
-mangleType(Ty, TL.getSourceRange(), QMM_Drop);
+mangleType(Ty, SR, QMM_Drop);
 mangleQualifiers(Ty.getLocalQualifiers(), false);
   }
 }
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r211667 - Don't go through the TypeSourceInfo when getting the SourceRange.

[Zachary Turner]

Author: zturner
Date: Wed Jun 25 00:37:25 2014
New Revision: 211667

URL: http://llvm.org/viewvc/llvm-project?rev=211667&view=rev
Log:
Don't go through the TypeSourceInfo when getting the SourceRange.

VarDecl provides a method getSourceRange(), which provides a more
robust way of getting the SourceRange since the TypeSourceInfo can
be null in certain cases.

Reviewed by: majnemer

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

Modified:
cfe/trunk/lib/AST/MicrosoftMangle.cpp

Modified: cfe/trunk/lib/AST/MicrosoftMangle.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/MicrosoftMangle.cpp?rev=211667&r1=211666&r2=211667&view=diff
==
--- cfe/trunk/lib/AST/MicrosoftMangle.cpp (original)
+++ cfe/trunk/lib/AST/MicrosoftMangle.cpp Wed Jun 25 00:37:25 2014
@@ -418,11 +418,11 @@ void MicrosoftCXXNameMangler::mangleVari
   // ::=   # pointers, references
   // Pointers and references are odd. The type of 'int * const foo;' gets
   // mangled as 'QAHA' instead of 'PAHB', for example.
-  TypeLoc TL = VD->getTypeSourceInfo()->getTypeLoc();
+  SourceRange SR = VD->getSourceRange();
   QualType Ty = VD->getType();
   if (Ty->isPointerType() || Ty->isReferenceType() ||
   Ty->isMemberPointerType()) {
-mangleType(Ty, TL.getSourceRange(), QMM_Drop);
+mangleType(Ty, SR, QMM_Drop);
 manglePointerExtQualifiers(
 Ty.getDesugaredType(getASTContext()).getLocalQualifiers(), nullptr);
 if (const MemberPointerType *MPT = Ty->getAs()) {
@@ -440,7 +440,7 @@ void MicrosoftCXXNameMangler::mangleVari
 else
   mangleQualifiers(Ty.getQualifiers(), false);
   } else {
-mangleType(Ty, TL.getSourceRange(), QMM_Drop);
+mangleType(Ty, SR, QMM_Drop);
 mangleQualifiers(Ty.getLocalQualifiers(), false);
   }
 }


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Change loop unroll and vectorizer metadata prefix to 'llvm.loop.'

[Mark Heffernan]

Agreed about preferring loop.vectorize to loop.vectorizer.  Thanks for
the reviews.  Attached are the updated patches.  Eli, can you submit
these?

Thanks,
Mark

On Tue, Jun 24, 2014 at 6:40 PM, Tyler Nowicki  wrote:
> Hi Mark,
>
> I also have a weak preference for the llvm.loop.unroll/vectorize option 
> because I would like to add metadata for interleaving and I think 
> interleave.enable would look better than interleaver.enable. Otherwise LGTM!
>
> Tyler
>
> On Jun 24, 2014, at 4:28 PM, Hal Finkel  wrote:
>
>> - Original Message -
>>> From: "Mark Heffernan" 
>>> To: "Hal Finkel" 
>>> Cc: llvm-comm...@cs.uiuc.edu, "cfe-commits" , 
>>> "Pekka Jääskeläinen"
>>> 
>>> Sent: Tuesday, June 24, 2014 4:18:30 PM
>>> Subject: Re: [PATCH] Change loop unroll and vectorizer metadata prefix to 
>>> 'llvm.loop.'
>>>
>>> The attached patch includes a note in ReleaseNotes.rst and code to
>>> autoupgrade llvm.vectorizer.* metadata strings to
>>> llvm.loop.vectorizer.* when reading assembly and bitcode.  PTAL.
>>
>> Okay, thanks. That's better. However, I just noticed that the proposed 
>> mapping:
>>
>>> llvm.vectorizer.* => llvm.loop.vectorizer.*
>>> llvm.loopunroll.* => llvm.loop.unroll.*
>>
>> is not grammatically consistent. I think that we should have 
>> ("llvm.loop.vectorize" and "llvm.loop.unroll") or ("llvm.loop.vectorizer" 
>> and "llvm.loop.unroller"). I have a weak preference for the first pair, but 
>> I care more about consistency than the choice.
>>
>> -Hal
>>
>>>
>>> Thanks!
>>> Mark
>>>
>>> On Tue, Jun 24, 2014 at 9:53 AM, Hal Finkel  wrote:
 - Original Message -
> From: "Mark Heffernan" 
> To: "Hal Finkel" 
> Cc: llvm-comm...@cs.uiuc.edu, "cfe-commits"
> , "Pekka Jääskeläinen"
> 
> Sent: Tuesday, June 24, 2014 11:18:33 AM
> Subject: Re: [PATCH] Change loop unroll and vectorizer metadata
> prefix to 'llvm.loop.'
>
> Thanks for the comments.  I'll add something to the release notes.
>
> On Tue, Jun 24, 2014 at 3:52 AM, Hal Finkel 
> wrote:
>> Moreover, for metadata that was supported by the 3.4 release,
>> autoupgrade support should be added. Please do this before you
>> commit.
>
> By autoupgrade do you mean be permissive about what is accepted?
> That
> is, accept llvm.vectorizer.* and llvm.loop.vectorizer.* but only
> emit
> the llvm.loop form from the FE.  Or do you mean try to rename the
> metadata as soon as it parsed?  I can see how to do the first case
> (be
> permissive) easily, but for the second (rename metadata) do you
> have
> any suggestions for the best place to cut in (I'm fairly new to
> the
> code base)?

 No, I mean the second. I believe that most of the current logic for
 this is in lib/IR/AutoUpgrade.cpp

 -Hal

>
> Thanks!
> Mark
>
>>
>> -Hal
>>
>>>
>>> On Tue, Jun 24, 2014 at 12:30 AM, Mark Heffernan
>>> 
>>> wrote:
 These patches rename the loop unrolling and loop vectorizer
 metadata
 such that they have a common 'llvm.loop.' prefix.  Metadata
 name
 changes:

 llvm.vectorizer.* => llvm.loop.vectorizer.*
 llvm.loopunroll.* => llvm.loop.unroll.*

 This was a suggestion from an earlier review
 (http://reviews.llvm.org/D4090) which added the loop
 unrolling
 metadata.  Two patches are attached.  One for front-end and
 one
 for
 optimizer.

 Mark
>>>
>>>
>>>
>>> --
>>> --PJ
>>> ___
>>> cfe-commits mailing list
>>> cfe-commits@cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>>
>>
>> --
>> Hal Finkel
>> Assistant Computational Scientist
>> Leadership Computing Facility
>> Argonne National Laboratory
>

 --
 Hal Finkel
 Assistant Computational Scientist
 Leadership Computing Facility
 Argonne National Laboratory
>>>
>>
>> --
>> Hal Finkel
>> Assistant Computational Scientist
>> Leadership Computing Facility
>> Argonne National Laboratory
>>
>> ___
>> llvm-commits mailing list
>> llvm-comm...@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
Index: lib/CodeGen/CGLoopInfo.cpp
===
--- lib/CodeGen/CGLoopInfo.cpp	(revision 211528)
+++ lib/CodeGen/CGLoopInfo.cpp	(working copy)
@@ -31,7 +31,7 @@
 
   // Setting vectorizer.width
   if (Attrs.VectorizerWidth > 0) {
-Value *Vals[] = { MDString::get(Ctx, "llvm.vectorizer.width"),
+Value *Vals[] = { MDString::get(Ctx, "llvm.loop.vectorize.width"),
   ConstantInt::get(Type::getInt32Ty(Ctx),
Attrs.VectorizerWidth) };
 Args.push_back(MDNode::get(Ctx, Vals))

Re: [PATCH} Remove '.bc' input support from the frontend

[David Blaikie]

On Tue, Jun 24, 2014 at 10:31 PM, Alp Toker  wrote:
> The attached patch removes code that apparently supported '.bc' binary LLVM
> bitcode as a frontend input kind.
>
> There were no tests and it's unclear if it was in a working state.

That's vaguely surprising.

> I'm
> comfortable removing this because it doesn't really align with the
> frontend's primary objective of diagnosing textual input and lowering source
> code.

It seems about as likely that someone would use this as they would use
.ll input files. I'm not sure how likely either is. As a developer I
usually use the llc, etc, tools - but sometimes I pass bitcode to
clang to link (possibly after using llvm-link to link two bitcode
files together & I want a linker invocation that has all the standard
libraries, etc rather than trying to invoke the linker myself or do
two steps of assemble+link).

> The removal lets us parse and diagnose '.ll' IR inputs more efficiently
> without duplicating file contents into memory.

Curious - how's that the case?

> (If there's desire to keep '.bc' support and someone contributes tests for
> it, I'm fine to explore other ways to achieve this optimisation.)
>
> Requires the recently posted MemoryBuffer patch.
>
> Alp.
>
> --
> http://www.nuanti.com
> the browser experts
>
>
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Don't eagerly evaluate the TypeSourceInfo when mangling names.

[Zachary Turner]

majnemer@ caught up with me offline and suggested a different fix, which is to 
simply call the getSourceRange() method of VarDecl instead of going through the 
TypeSourceInfo.  This also solves the problem, so I will commit this fix 
instead as it seems more straightforward.

http://reviews.llvm.org/D4281



___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

[PATCH} Remove '.bc' input support from the frontend

[Alp Toker]

The attached patch removes code that apparently supported '.bc' binary 
LLVM bitcode as a frontend input kind.


There were no tests and it's unclear if it was in a working state. I'm 
comfortable removing this because it doesn't really align with the 
frontend's primary objective of diagnosing textual input and lowering 
source code.


The removal lets us parse and diagnose '.ll' IR inputs more efficiently 
without duplicating file contents into memory.


(If there's desire to keep '.bc' support and someone contributes tests 
for it, I'm fine to explore other ways to achieve this optimisation.)


Requires the recently posted MemoryBuffer patch.

Alp.

--
http://www.nuanti.com
the browser experts

>From 6c4617344bb9f05d46ac9674b7c83e63724256c4 Mon Sep 17 00:00:00 2001
From: Alp Toker 
Date: Tue, 24 Jun 2014 23:46:25 +0300
Subject: [PATCH 3/3] Remove unused '.bc' input and optimize '.ll' support

The '.bc' binary input file support had no tests and didn't really really make
sense as a frontend input.

Removing it lets us avoid copying whole file contents into memory in the common
case because ParseAssembly() can share ownership unlike the catch-all
ParseIR().
---
 lib/CodeGen/CodeGenAction.cpp| 10 +++---
 lib/Frontend/FrontendOptions.cpp |  2 +-
 2 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/lib/CodeGen/CodeGenAction.cpp b/lib/CodeGen/CodeGenAction.cpp
index 433be66..3e48fa1 100644
--- a/lib/CodeGen/CodeGenAction.cpp
+++ b/lib/CodeGen/CodeGenAction.cpp
@@ -20,13 +20,13 @@
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/FrontendDiagnostic.h"
 #include "llvm/ADT/SmallString.h"
+#include "llvm/AsmParser/Parser.h"
 #include "llvm/Bitcode/ReaderWriter.h"
 #include "llvm/IR/DebugInfo.h"
 #include "llvm/IR/DiagnosticInfo.h"
 #include "llvm/IR/DiagnosticPrinter.h"
 #include "llvm/IR/LLVMContext.h"
 #include "llvm/IR/Module.h"
-#include "llvm/IRReader/IRReader.h"
 #include "llvm/Linker/Linker.h"
 #include "llvm/Pass.h"
 #include "llvm/Support/MemoryBuffer.h"
@@ -638,13 +638,9 @@ void CodeGenAction::ExecuteAction() {
 if (Invalid)
   return;
 
-// FIXME: This is stupid, IRReader shouldn't take ownership.
-llvm::MemoryBuffer *MainFileCopy =
-  llvm::MemoryBuffer::getMemBufferCopy(MainFile->getBuffer(),
-   getCurrentFile());
-
 llvm::SMDiagnostic Err;
-TheModule.reset(ParseIR(MainFileCopy, Err, *VMContext));
+TheModule.reset(ParseAssembly(const_cast(MainFile), 
nullptr,
+  Err, *VMContext));
 if (!TheModule) {
   // Translate from the diagnostic info to the SourceManager location.
   SourceLocation Loc = SM.translateFileLineCol(
diff --git a/lib/Frontend/FrontendOptions.cpp b/lib/Frontend/FrontendOptions.cpp
index 1869d0c..dd233e3 100644
--- a/lib/Frontend/FrontendOptions.cpp
+++ b/lib/Frontend/FrontendOptions.cpp
@@ -26,6 +26,6 @@ InputKind FrontendOptions::getInputKindForExtension(StringRef 
Extension) {
 .Cases("cpp", "CPP", "c++", "cxx", "hpp", IK_CXX)
 .Case("cl", IK_OpenCL)
 .Case("cu", IK_CUDA)
-.Cases("ll", "bc", IK_LLVM_IR)
+.Case("ll", IK_LLVM_IR)
 .Default(IK_C);
 }
-- 
1.9.1

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

[PATCH] Don't duplicate entire file contents in memory

[Alp Toker]

The attached clang patches:

 * Eliminate copying of file contents into memory in several places.
 * Avoid redundant file IO to re-stat and re-read file contents at each 
pass.

 * Enable sharing of parse buffers with the backend.

The changes will also enable future removal of old hacks like 
RetainRemappedFileBuffers/OwnsRemappedFileBuffers and SourceManager's 
DoNotFreeFlag.


A patch adding minor supporting changes on the LLVM side has been sent 
to llvm-commits.


Background:

The key feature of this approach is that reference counting is only 
handled by source managers and otherwise transparent to anything else 
that works with MemoryBuffer pointers.


That means traditional new/delete MemoryBuffer usage isn't affected and 
we maintain essentially the same MemoryBuffer lifetime guarantees as 
before, just adding the efficient transfer semantics that was sorely 
missing and saving memory allocations.


Alp.

--
http://www.nuanti.com
the browser experts

>From ea1f573a1e061cdd2ec7e7b4d99805049f20363f Mon Sep 17 00:00:00 2001
From: Alp Toker 
Date: Wed, 25 Jun 2014 03:37:51 +0300
Subject: [PATCH 1/3] SourceManager: use reference counting for MemoryBuffers

This change will make it possible to share ownership of mmap and malloc buffers
between different source managers instead of duplicating entire files into
memory.
---
 include/clang/Basic/SourceManager.h | 49 +
 include/clang/Lex/PreprocessorOptions.h |  1 +
 lib/Basic/SourceManager.cpp | 77 -
 3 files changed, 60 insertions(+), 67 deletions(-)

diff --git a/include/clang/Basic/SourceManager.h 
b/include/clang/Basic/SourceManager.h
index 585d138..777b25f 100644
--- a/include/clang/Basic/SourceManager.h
+++ b/include/clang/Basic/SourceManager.h
@@ -42,7 +42,6 @@
 #include "llvm/ADT/DenseMap.h"
 #include "llvm/ADT/DenseSet.h"
 #include "llvm/ADT/IntrusiveRefCntPtr.h"
-#include "llvm/ADT/PointerIntPair.h"
 #include "llvm/ADT/PointerUnion.h"
 #include "llvm/Support/AlignOf.h"
 #include "llvm/Support/Allocator.h"
@@ -104,7 +103,8 @@ namespace SrcMgr {
 ///
 /// This is owned by the ContentCache object.  The bits indicate
 /// whether the buffer is invalid.
-mutable llvm::PointerIntPair Buffer;
+mutable IntrusiveRefCntPtr Buffer;
+mutable unsigned BufferFlags;
 
   public:
 /// \brief Reference to the file entry representing this ContentCache.
@@ -142,32 +142,31 @@ namespace SrcMgr {
 /// \brief True if this content cache was initially created for a source
 /// file considered as a system one.
 unsigned IsSystemFile : 1;
-
+
 ContentCache(const FileEntry *Ent = nullptr)
-  : Buffer(nullptr, false), OrigEntry(Ent), ContentsEntry(Ent),
-SourceLineCache(nullptr), NumLines(0), BufferOverridden(false),
-IsSystemFile(false) {
+: BufferFlags(0), OrigEntry(Ent), ContentsEntry(Ent),
+  SourceLineCache(nullptr), NumLines(0), BufferOverridden(false),
+  IsSystemFile(false) {
   (void)NonceAligner; // Silence warnings about unused member.
 }
-
+
 ContentCache(const FileEntry *Ent, const FileEntry *contentEnt)
-  : Buffer(nullptr, false), OrigEntry(Ent), ContentsEntry(contentEnt),
-SourceLineCache(nullptr), NumLines(0), BufferOverridden(false),
-IsSystemFile(false) {}
-
+: BufferFlags(0), OrigEntry(Ent), ContentsEntry(contentEnt),
+  SourceLineCache(nullptr), NumLines(0), BufferOverridden(false),
+  IsSystemFile(false) {}
+
 ~ContentCache();
 
 /// The copy ctor does not allow copies where source object has either
 /// a non-NULL Buffer or SourceLineCache.  Ownership of allocated memory
 /// is not transferred, so this is a logical error.
 ContentCache(const ContentCache &RHS)
-  : Buffer(nullptr, false), SourceLineCache(nullptr),
-BufferOverridden(false), IsSystemFile(false) {
+: BufferFlags(0), SourceLineCache(nullptr), BufferOverridden(false),
+  IsSystemFile(false) {
   OrigEntry = RHS.OrigEntry;
   ContentsEntry = RHS.ContentsEntry;
 
-  assert(RHS.Buffer.getPointer() == nullptr &&
- RHS.SourceLineCache == nullptr &&
+  assert(!RHS.Buffer && RHS.SourceLineCache == nullptr &&
  "Passed ContentCache object cannot own a buffer.");
 
   NumLines = RHS.NumLines;
@@ -206,30 +205,24 @@ namespace SrcMgr {
 llvm::MemoryBuffer::BufferKind getMemoryBufferKind() const;
 
 void setBuffer(const llvm::MemoryBuffer *B) {
-  assert(!Buffer.getPointer() && "MemoryBuffer already set.");
-  Buffer.setPointer(B);
-  Buffer.setInt(false);
+  assert(!Buffer && "MemoryBuffer already set.");
+  Buffer = B;
+  BufferFlags = 0;
 }
 
 /// \brief Get the underlying buffer, returning NULL if the buffer is not
 /// yet available.
-const llvm::MemoryBuffer *getRawBuffer() const {
-  return Buffer.getPointer();
-}
+const l

Re: [PATCH] PR15677 - Crash in template diffing.

[Richard Trieu]

Besides the above, PrintAPSInt needs to updated since a new node format is 
being introduced.  On the else branch where "(no argument)" is printed, this 
should be changed to print the expression if E is valid, and print "(no 
argument)" if it is not.


Comment at: lib/AST/ASTDiagnostic.cpp:970
@@ -967,3 +969,3 @@
 Tree.SetKind(DiffTree::Integer);
   } else {
 Tree.SetSame(IsEqualExpr(Context, ParamWidth, FromExpr, ToExpr));

This needs another case here, (HasFromInt || HasToInt).  Use same SetNode and 
SetKind as above, but use SetSame(false).


Comment at: lib/AST/ASTDiagnostic.cpp:1122
@@ -1123,3 +1121,3 @@
   /// default arguments.
-  llvm::APInt GetInt(const TSTiterator &Iter, Expr *ArgExpr) {
+  llvm::APInt GetInt(const TSTiterator &Iter, Expr *ArgExpr, bool &HasInt) {
 // Default, value-depenedent expressions require fetching

Go with version you put in the summary: returns bool and takes APInt as an 
reference argument.  Update the comment here.


Comment at: test/Misc/diag-template-diffing.cpp:1100
@@ -1071,1 +1099,3 @@
+}
+
 // CHECK-ELIDE-NOTREE: {{[0-9]*}} errors generated.

Add another test case, just like E, but use 21 + 21 and test that "21 + 21 aka 
42" is printed.

http://reviews.llvm.org/D4226



___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r211619 - [Driver][Mips] Support mips64-linux-gnuabi64 / mips64el-linux-gnuabi64 target triples.

[Simon Atanasyan]

In fact the bug was introduced by r211598. Anyway it is my bad because
I was reviewer of that change. The r211663,r211665 should fix this
problem.

On Wed, Jun 25, 2014 at 3:50 AM, Reid Kleckner  wrote:
> This test fails for me on Windows, and you can see the failure here:
> http://bb.pgr.jp/builders/ninja-clang-i686-msc17-R/builds/9035

[...]

> On Tue, Jun 24, 2014 at 12:00 PM, Simon Atanasyan 
> wrote:
>>
>> Author: atanasyan
>> Date: Tue Jun 24 14:00:12 2014
>> New Revision: 211619
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=211619&view=rev
>> Log:
>> [Driver][Mips] Support mips64-linux-gnuabi64 / mips64el-linux-gnuabi64
>> target triples.

-- 
Simon Atanasyan
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r211665 - [Driver] Follow-up to r211598, r211663. Do not build a dynamic linker

[Simon Atanasyan]

Author: atanasyan
Date: Wed Jun 25 00:00:59 2014
New Revision: 211665

URL: http://llvm.org/viewvc/llvm-project?rev=211665&view=rev
Log:
[Driver] Follow-up to r211598, r211663. Do not build a dynamic linker
path using sub-strings concatenation. Return the whole string explicitly.

Modified:
cfe/trunk/lib/Driver/Tools.cpp

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=211665&r1=211664&r2=211665&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Wed Jun 25 00:00:59 2014
@@ -6929,8 +6929,8 @@ static void AddLibgcc(const llvm::Triple
 CmdArgs.push_back("-ldl");
 }
 
-static Twine getLinuxDynamicLinker(const ArgList &Args,
-   const toolchains::Linux &ToolChain) {
+static StringRef getLinuxDynamicLinker(const ArgList &Args,
+   const toolchains::Linux &ToolChain) {
   if (ToolChain.getTriple().getEnvironment() == llvm::Triple::Android) {
 if (ToolChain.getTriple().isArch64Bit())
   return "/system/bin/linker64";
@@ -6964,11 +6964,11 @@ static Twine getLinuxDynamicLinker(const
 return "/lib/ld.so.1";
   } else if (ToolChain.getArch() == llvm::Triple::mips64 ||
  ToolChain.getArch() == llvm::Triple::mips64el) {
-Twine LinkerFile =
-mips::isNaN2008(Args) ? "ld-linux-mipsn8.so.1" : "ld.so.1";
 if (mips::hasMipsAbiArg(Args, "n32"))
-  return "/lib32/" + LinkerFile;
-return "/lib64/" + LinkerFile;
+  return mips::isNaN2008(Args) ? "/lib32/ld-linux-mipsn8.so.1"
+   : "/lib32/ld.so.1";
+return mips::isNaN2008(Args) ? "/lib64/ld-linux-mipsn8.so.1"
+ : "/lib64/ld.so.1";
   } else if (ToolChain.getArch() == llvm::Triple::ppc)
 return "/lib/ld.so.1";
   else if (ToolChain.getArch() == llvm::Triple::ppc64 ||


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r211663 - Tools.cpp: Update getLinuxDynamicLinker() to return Twine instead of StringRef, since r211598 has introduced manipulation of return string.

[Simon Atanasyan]

I suggest a bit more simple approach - do not build a dynamic linker
paths from sub-strings at all and return a whole string. In fact I was
almost ready to commit this fix 5 minutes ago :)

On Wed, Jun 25, 2014 at 8:54 AM, NAKAMURA Takumi  wrote:
> Ah, my fix was not right. It should be rewritten with SmallString or
> std::string.
>
> It apparently fixed (for me)
> http://bb.pgr.jp/builders/ninja-clang-i686-msc17-R/builds/9035
>
> Thanks for noticing. g2g.
>
> 2014-06-25 13:51 GMT+09:00 David Blaikie :
>> On Tue, Jun 24, 2014 at 9:34 PM, NAKAMURA Takumi  
>> wrote:
>>> Author: chapuni
>>> Date: Tue Jun 24 23:34:20 2014
>>> New Revision: 211663
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=211663&view=rev
>>> Log:
>>> Tools.cpp: Update getLinuxDynamicLinker() to return Twine instead of 
>>> StringRef, since r211598 has introduced manipulation of return string.
>>
>> Returning a Twine is risky business (if the expression returned is
>> anything more than a single Twine then the Twine subexpressions will
>> be destroyed at the end of the function, leaving the top level Twine
>> dangling) - was this change fixing a compilation error? What was the
>> error?
>>
>>>
>>> Modified:
>>> cfe/trunk/lib/Driver/Tools.cpp
>>>
>>> Modified: cfe/trunk/lib/Driver/Tools.cpp
>>> URL: 
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=211663&r1=211662&r2=211663&view=diff
>>> ==
>>> --- cfe/trunk/lib/Driver/Tools.cpp (original)
>>> +++ cfe/trunk/lib/Driver/Tools.cpp Tue Jun 24 23:34:20 2014
>>> @@ -6929,8 +6929,8 @@ static void AddLibgcc(const llvm::Triple
>>>  CmdArgs.push_back("-ldl");
>>>  }
>>>
>>> -static StringRef getLinuxDynamicLinker(const ArgList &Args,
>>> -   const toolchains::Linux &ToolChain) 
>>> {
>>> +static Twine getLinuxDynamicLinker(const ArgList &Args,
>>> +   const toolchains::Linux &ToolChain) {
>>>if (ToolChain.getTriple().getEnvironment() == llvm::Triple::Android) {
>>>  if (ToolChain.getTriple().isArch64Bit())
>>>return "/system/bin/linker64";
>>> @@ -6964,7 +6964,7 @@ static StringRef getLinuxDynamicLinker(c
>>>  return "/lib/ld.so.1";
>>>} else if (ToolChain.getArch() == llvm::Triple::mips64 ||
>>>   ToolChain.getArch() == llvm::Triple::mips64el) {
>>> -std::string LinkerFile =
>>> +Twine LinkerFile =
>>>  mips::isNaN2008(Args) ? "ld-linux-mipsn8.so.1" : "ld.so.1";
>>>  if (mips::hasMipsAbiArg(Args, "n32"))
>>>return "/lib32/" + LinkerFile;
>>>
>>>
>>> ___
>>> cfe-commits mailing list
>>> cfe-commits@cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits



-- 
Simon Atanasyan
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r211663 - Tools.cpp: Update getLinuxDynamicLinker() to return Twine instead of StringRef, since r211598 has introduced manipulation of return string.

[NAKAMURA Takumi]

Ah, my fix was not right. It should be rewritten with SmallString or
std::string.

It apparently fixed (for me)
http://bb.pgr.jp/builders/ninja-clang-i686-msc17-R/builds/9035

Thanks for noticing. g2g.

2014-06-25 13:51 GMT+09:00 David Blaikie :
> On Tue, Jun 24, 2014 at 9:34 PM, NAKAMURA Takumi  wrote:
>> Author: chapuni
>> Date: Tue Jun 24 23:34:20 2014
>> New Revision: 211663
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=211663&view=rev
>> Log:
>> Tools.cpp: Update getLinuxDynamicLinker() to return Twine instead of 
>> StringRef, since r211598 has introduced manipulation of return string.
>
> Returning a Twine is risky business (if the expression returned is
> anything more than a single Twine then the Twine subexpressions will
> be destroyed at the end of the function, leaving the top level Twine
> dangling) - was this change fixing a compilation error? What was the
> error?
>
>>
>> Modified:
>> cfe/trunk/lib/Driver/Tools.cpp
>>
>> Modified: cfe/trunk/lib/Driver/Tools.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=211663&r1=211662&r2=211663&view=diff
>> ==
>> --- cfe/trunk/lib/Driver/Tools.cpp (original)
>> +++ cfe/trunk/lib/Driver/Tools.cpp Tue Jun 24 23:34:20 2014
>> @@ -6929,8 +6929,8 @@ static void AddLibgcc(const llvm::Triple
>>  CmdArgs.push_back("-ldl");
>>  }
>>
>> -static StringRef getLinuxDynamicLinker(const ArgList &Args,
>> -   const toolchains::Linux &ToolChain) {
>> +static Twine getLinuxDynamicLinker(const ArgList &Args,
>> +   const toolchains::Linux &ToolChain) {
>>if (ToolChain.getTriple().getEnvironment() == llvm::Triple::Android) {
>>  if (ToolChain.getTriple().isArch64Bit())
>>return "/system/bin/linker64";
>> @@ -6964,7 +6964,7 @@ static StringRef getLinuxDynamicLinker(c
>>  return "/lib/ld.so.1";
>>} else if (ToolChain.getArch() == llvm::Triple::mips64 ||
>>   ToolChain.getArch() == llvm::Triple::mips64el) {
>> -std::string LinkerFile =
>> +Twine LinkerFile =
>>  mips::isNaN2008(Args) ? "ld-linux-mipsn8.so.1" : "ld.so.1";
>>  if (mips::hasMipsAbiArg(Args, "n32"))
>>return "/lib32/" + LinkerFile;
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r211663 - Tools.cpp: Update getLinuxDynamicLinker() to return Twine instead of StringRef, since r211598 has introduced manipulation of return string.

[David Blaikie]

On Tue, Jun 24, 2014 at 9:34 PM, NAKAMURA Takumi  wrote:
> Author: chapuni
> Date: Tue Jun 24 23:34:20 2014
> New Revision: 211663
>
> URL: http://llvm.org/viewvc/llvm-project?rev=211663&view=rev
> Log:
> Tools.cpp: Update getLinuxDynamicLinker() to return Twine instead of 
> StringRef, since r211598 has introduced manipulation of return string.

Returning a Twine is risky business (if the expression returned is
anything more than a single Twine then the Twine subexpressions will
be destroyed at the end of the function, leaving the top level Twine
dangling) - was this change fixing a compilation error? What was the
error?

>
> Modified:
> cfe/trunk/lib/Driver/Tools.cpp
>
> Modified: cfe/trunk/lib/Driver/Tools.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=211663&r1=211662&r2=211663&view=diff
> ==
> --- cfe/trunk/lib/Driver/Tools.cpp (original)
> +++ cfe/trunk/lib/Driver/Tools.cpp Tue Jun 24 23:34:20 2014
> @@ -6929,8 +6929,8 @@ static void AddLibgcc(const llvm::Triple
>  CmdArgs.push_back("-ldl");
>  }
>
> -static StringRef getLinuxDynamicLinker(const ArgList &Args,
> -   const toolchains::Linux &ToolChain) {
> +static Twine getLinuxDynamicLinker(const ArgList &Args,
> +   const toolchains::Linux &ToolChain) {
>if (ToolChain.getTriple().getEnvironment() == llvm::Triple::Android) {
>  if (ToolChain.getTriple().isArch64Bit())
>return "/system/bin/linker64";
> @@ -6964,7 +6964,7 @@ static StringRef getLinuxDynamicLinker(c
>  return "/lib/ld.so.1";
>} else if (ToolChain.getArch() == llvm::Triple::mips64 ||
>   ToolChain.getArch() == llvm::Triple::mips64el) {
> -std::string LinkerFile =
> +Twine LinkerFile =
>  mips::isNaN2008(Args) ? "ld-linux-mipsn8.so.1" : "ld.so.1";
>  if (mips::hasMipsAbiArg(Args, "n32"))
>return "/lib32/" + LinkerFile;
>
>
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r211663 - Tools.cpp: Update getLinuxDynamicLinker() to return Twine instead of StringRef, since r211598 has introduced manipulation of return string.

[NAKAMURA Takumi]

Author: chapuni
Date: Tue Jun 24 23:34:20 2014
New Revision: 211663

URL: http://llvm.org/viewvc/llvm-project?rev=211663&view=rev
Log:
Tools.cpp: Update getLinuxDynamicLinker() to return Twine instead of StringRef, 
since r211598 has introduced manipulation of return string.

Modified:
cfe/trunk/lib/Driver/Tools.cpp

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=211663&r1=211662&r2=211663&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Tue Jun 24 23:34:20 2014
@@ -6929,8 +6929,8 @@ static void AddLibgcc(const llvm::Triple
 CmdArgs.push_back("-ldl");
 }
 
-static StringRef getLinuxDynamicLinker(const ArgList &Args,
-   const toolchains::Linux &ToolChain) {
+static Twine getLinuxDynamicLinker(const ArgList &Args,
+   const toolchains::Linux &ToolChain) {
   if (ToolChain.getTriple().getEnvironment() == llvm::Triple::Android) {
 if (ToolChain.getTriple().isArch64Bit())
   return "/system/bin/linker64";
@@ -6964,7 +6964,7 @@ static StringRef getLinuxDynamicLinker(c
 return "/lib/ld.so.1";
   } else if (ToolChain.getArch() == llvm::Triple::mips64 ||
  ToolChain.getArch() == llvm::Triple::mips64el) {
-std::string LinkerFile =
+Twine LinkerFile =
 mips::isNaN2008(Args) ? "ld-linux-mipsn8.so.1" : "ld.so.1";
 if (mips::hasMipsAbiArg(Args, "n32"))
   return "/lib32/" + LinkerFile;


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r211662 - VirtualFileSystemTest.cpp: Get rid of initializer list on std::vector, to appease msc17.

[NAKAMURA Takumi]

Author: chapuni
Date: Tue Jun 24 23:34:10 2014
New Revision: 211662

URL: http://llvm.org/viewvc/llvm-project?rev=211662&view=rev
Log:
VirtualFileSystemTest.cpp: Get rid of initializer list on std::vector, to 
appease msc17.

Modified:
cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp

Modified: cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp?rev=211662&r1=211661&r2=211662&view=diff
==
--- cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp (original)
+++ cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp Tue Jun 24 23:34:10 2014
@@ -306,8 +306,16 @@ TEST(VirtualFileSystemTest, BasicRealFSI
   EXPECT_EQ(vfs::directory_iterator(), I);
 }
 
+template 
+std::vector makeStringRefVector(const T (&Arr)[N]) {
+  std::vector Vec;
+  for (size_t i = 0; i != N; ++i)
+Vec.push_back(Arr[i]);
+  return Vec;
+}
+
 static void checkContents(vfs::directory_iterator I,
-  ArrayRef Expected) {
+  ArrayRef Expected) {
   std::error_code EC;
   auto ExpectedIter = Expected.begin(), ExpectedEnd = Expected.end();
   for (vfs::directory_iterator E;
@@ -327,25 +335,25 @@ TEST(VirtualFileSystemTest, OverlayItera
   O->pushOverlay(Upper);
 
   std::error_code EC;
-  checkContents(O->dir_begin("/", EC), ArrayRef());
+  checkContents(O->dir_begin("/", EC), ArrayRef());
 
   Lower->addRegularFile("/file1");
-  checkContents(O->dir_begin("/", EC), ArrayRef("/file1"));
+  checkContents(O->dir_begin("/", EC), ArrayRef("/file1"));
 
   Upper->addRegularFile("/file2");
   {
-std::vector Contents = {"/file2", "/file1"};
-checkContents(O->dir_begin("/", EC), Contents);
+const char *Contents[] = {"/file2", "/file1"};
+checkContents(O->dir_begin("/", EC), makeStringRefVector(Contents));
   }
 
   Lower->addDirectory("/dir1");
   Lower->addRegularFile("/dir1/foo");
   Upper->addDirectory("/dir2");
   Upper->addRegularFile("/dir2/foo");
-  checkContents(O->dir_begin("/dir2", EC), ArrayRef("/dir2/foo"));
+  checkContents(O->dir_begin("/dir2", EC), ArrayRef("/dir2/foo"));
   {
-std::vector Contents = {"/dir2", "/file2", "/dir1", "/file1"};
-checkContents(O->dir_begin("/", EC), Contents);
+const char *Contents[] = {"/dir2", "/file2", "/dir1", "/file1"};
+checkContents(O->dir_begin("/", EC), makeStringRefVector(Contents));
   }
 }
 
@@ -359,16 +367,16 @@ TEST(VirtualFileSystemTest, ThreeLevelIt
   O->pushOverlay(Upper);
 
   std::error_code EC;
-  checkContents(O->dir_begin("/", EC), ArrayRef());
+  checkContents(O->dir_begin("/", EC), ArrayRef());
 
   Middle->addRegularFile("/file2");
-  checkContents(O->dir_begin("/", EC), ArrayRef("/file2"));
+  checkContents(O->dir_begin("/", EC), ArrayRef("/file2"));
 
   Lower->addRegularFile("/file1");
   Upper->addRegularFile("/file3");
   {
-std::vector Contents = {"/file3", "/file2", "/file1"};
-checkContents(O->dir_begin("/", EC), Contents);
+const char *Contents[] = {"/file3", "/file2", "/file1"};
+checkContents(O->dir_begin("/", EC), makeStringRefVector(Contents));
   }
 }
 
@@ -391,9 +399,9 @@ TEST(VirtualFileSystemTest, HiddenInIter
   Upper->addRegularFile("/onlyInUp", sys::fs::owner_all);
   Upper->addRegularFile("/hiddenByUp", sys::fs::owner_all);
   {
-std::vector Contents = {
-"/hiddenByUp", "/onlyInUp", "/hiddenByMid", "/onlyInMid", 
"/onlyInLow"};
-checkContents(O->dir_begin("/", EC), Contents);
+const char *Contents[] = {"/hiddenByUp", "/onlyInUp", "/hiddenByMid",
+  "/onlyInMid", "/onlyInLow"};
+checkContents(O->dir_begin("/", EC), makeStringRefVector(Contents));
   }
 
   // Make sure we get the top-most entry
@@ -817,14 +825,14 @@ TEST_F(VFSFromYAMLTest, DirectoryIterati
 
   std::error_code EC;
   {
-std::vector Contents = {"//root/file1", "//root/file2",
- "//root/file3", "//root/foo"};
-checkContents(O->dir_begin("//root/", EC), Contents);
+const char *Contents[] = {"//root/file1", "//root/file2", "//root/file3",
+  "//root/foo"};
+checkContents(O->dir_begin("//root/", EC), makeStringRefVector(Contents));
   }
 
   {
-std::vector Contents = {"//root/foo/bar/a",
- "//root/foo/bar/b"};
-checkContents(O->dir_begin("//root/foo/bar", EC), Contents);
+const char *Contents[] = {"//root/foo/bar/a", "//root/foo/bar/b"};
+checkContents(O->dir_begin("//root/foo/bar", EC),
+  makeStringRefVector(Contents));
   }
 }


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r211661 - Reformat.

[NAKAMURA Takumi]

Author: chapuni
Date: Tue Jun 24 23:34:00 2014
New Revision: 211661

URL: http://llvm.org/viewvc/llvm-project?rev=211661&view=rev
Log:
Reformat.

Modified:
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=211661&r1=211660&r2=211661&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Tue Jun 24 23:34:00 2014
@@ -6963,9 +6963,9 @@ static StringRef getLinuxDynamicLinker(c
   return "/lib/ld-linux-mipsn8.so.1";
 return "/lib/ld.so.1";
   } else if (ToolChain.getArch() == llvm::Triple::mips64 ||
-   ToolChain.getArch() == llvm::Triple::mips64el) {
-std::string LinkerFile = mips::isNaN2008(Args) ? "ld-linux-mipsn8.so.1"
-   : "ld.so.1";
+ ToolChain.getArch() == llvm::Triple::mips64el) {
+std::string LinkerFile =
+mips::isNaN2008(Args) ? "ld-linux-mipsn8.so.1" : "ld.so.1";
 if (mips::hasMipsAbiArg(Args, "n32"))
   return "/lib32/" + LinkerFile;
 return "/lib64/" + LinkerFile;

Modified: cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp?rev=211661&r1=211660&r2=211661&view=diff
==
--- cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp (original)
+++ cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp Tue Jun 24 23:34:00 2014
@@ -334,7 +334,7 @@ TEST(VirtualFileSystemTest, OverlayItera
 
   Upper->addRegularFile("/file2");
   {
-std::vector Contents = { "/file2", "/file1" };
+std::vector Contents = {"/file2", "/file1"};
 checkContents(O->dir_begin("/", EC), Contents);
   }
 
@@ -344,7 +344,7 @@ TEST(VirtualFileSystemTest, OverlayItera
   Upper->addRegularFile("/dir2/foo");
   checkContents(O->dir_begin("/dir2", EC), ArrayRef("/dir2/foo"));
   {
-std::vector Contents = { "/dir2", "/file2", "/dir1", "/file1" 
};
+std::vector Contents = {"/dir2", "/file2", "/dir1", "/file1"};
 checkContents(O->dir_begin("/", EC), Contents);
   }
 }
@@ -367,7 +367,7 @@ TEST(VirtualFileSystemTest, ThreeLevelIt
   Lower->addRegularFile("/file1");
   Upper->addRegularFile("/file3");
   {
-std::vector Contents = { "/file3", "/file2", "/file1" };
+std::vector Contents = {"/file3", "/file2", "/file1"};
 checkContents(O->dir_begin("/", EC), Contents);
   }
 }
@@ -391,8 +391,8 @@ TEST(VirtualFileSystemTest, HiddenInIter
   Upper->addRegularFile("/onlyInUp", sys::fs::owner_all);
   Upper->addRegularFile("/hiddenByUp", sys::fs::owner_all);
   {
-std::vector Contents = { "/hiddenByUp", "/onlyInUp",
-"/hiddenByMid", "/onlyInMid", "/onlyInLow" };
+std::vector Contents = {
+"/hiddenByUp", "/onlyInUp", "/hiddenByMid", "/onlyInMid", 
"/onlyInLow"};
 checkContents(O->dir_begin("/", EC), Contents);
   }
 
@@ -817,15 +817,14 @@ TEST_F(VFSFromYAMLTest, DirectoryIterati
 
   std::error_code EC;
   {
-std::vector Contents = { "//root/file1", "//root/file2",
-"//root/file3", "//root/foo" };
+std::vector Contents = {"//root/file1", "//root/file2",
+ "//root/file3", "//root/foo"};
 checkContents(O->dir_begin("//root/", EC), Contents);
   }
 
   {
-std::vector Contents = {
-"//root/foo/bar/a", "//root/foo/bar/b" };
+std::vector Contents = {"//root/foo/bar/a",
+ "//root/foo/bar/b"};
 checkContents(O->dir_begin("//root/foo/bar", EC), Contents);
   }
 }
-


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r211589 - [OPENMP] Additional checking for 'collapse' clause.

[Alexey Bataev]

Hal, Done!

Best regards,
Alexey Bataev
=
Software Engineer
Intel Compiler Team

24 Июнь 2014 г. 22:58:23, Hal Finkel писал:

- Original Message -

From: "Alexey Bataev" 
To: cfe-commits@cs.uiuc.edu
Sent: Tuesday, June 24, 2014 7:55:57 AM
Subject: r211589 - [OPENMP] Additional checking for 'collapse' clause.

Author: abataev
Date: Tue Jun 24 07:55:56 2014
New Revision: 211589

URL: http://llvm.org/viewvc/llvm-project?rev=211589&view=rev
Log:
[OPENMP] Additional checking for 'collapse' clause.



[snip]



+namespace {
+struct OMPCollapseClauseFilter {
+  OMPCollapseClauseFilter() {}
+  bool operator()(const OMPClause *C) {
+return C->getClauseKind() == OMPC_collapse;
+  }
+};
+} // namespace


Can we use a lambda for this?


+
+static Expr *GetCollapseNumberExpr(ArrayRef Clauses) {
+
  OMPExecutableDirective::filtered_clause_iterator
I(
+  Clauses);
+  if (I)
+return cast(*I)->getNumForLoops();
+  return nullptr;
+}
+


  -Hal



___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r211660 - [OPENMP] Improved code and replaced struct by lambda.

[Alexey Bataev]

Author: abataev
Date: Tue Jun 24 23:09:13 2014
New Revision: 211660

URL: http://llvm.org/viewvc/llvm-project?rev=211660&view=rev
Log:
[OPENMP] Improved code and replaced struct by lambda.

Modified:
cfe/trunk/include/clang/AST/StmtOpenMP.h
cfe/trunk/lib/Sema/SemaOpenMP.cpp

Modified: cfe/trunk/include/clang/AST/StmtOpenMP.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/StmtOpenMP.h?rev=211660&r1=211659&r2=211660&view=diff
==
--- cfe/trunk/include/clang/AST/StmtOpenMP.h (original)
+++ cfe/trunk/include/clang/AST/StmtOpenMP.h Tue Jun 24 23:09:13 2014
@@ -94,16 +94,17 @@ public:
   template  class filtered_clause_iterator {
 ArrayRef::const_iterator Current;
 ArrayRef::const_iterator End;
+FilterPredicate Pred;
 void SkipToNextClause() {
-  while (Current != End && !FilterPredicate()(*Current))
+  while (Current != End && !Pred(*Current))
 ++Current;
 }
 
   public:
 typedef const OMPClause *value_type;
 filtered_clause_iterator() : Current(), End() {}
-explicit filtered_clause_iterator(ArrayRef Arr)
-: Current(Arr.begin()), End(Arr.end()) {
+filtered_clause_iterator(ArrayRef Arr, FilterPredicate Pred)
+: Current(Arr.begin()), End(Arr.end()), Pred(Pred) {
   SkipToNextClause();
 }
 value_type operator*() const { return *Current; }

Modified: cfe/trunk/lib/Sema/SemaOpenMP.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOpenMP.cpp?rev=211660&r1=211659&r2=211660&view=diff
==
--- cfe/trunk/lib/Sema/SemaOpenMP.cpp (original)
+++ cfe/trunk/lib/Sema/SemaOpenMP.cpp Tue Jun 24 23:09:13 2014
@@ -182,7 +182,7 @@ public:
 DSAStackTy::DSAVarData DSAStackTy::getDSA(StackTy::reverse_iterator Iter,
   VarDecl *D) {
   DSAVarData DVar;
-  if (Iter == Stack.rend() - 1) {
+  if (Iter == std::prev(Stack.rend())) {
 // OpenMP [2.9.1.1, Data-sharing Attribute Rules for Variables Referenced
 // in a region but not in construct]
 //  File-scope or namespace-scope variables referenced in called routines
@@ -888,7 +888,7 @@ void Sema::ActOnOpenMPRegionStart(OpenMP
   case OMPD_parallel: {
 QualType KmpInt32Ty = Context.getIntTypeForBitwidth(32, 1);
 QualType KmpInt32PtrTy = Context.getPointerType(KmpInt32Ty);
-Sema::CapturedParamNameType Params[3] = {
+Sema::CapturedParamNameType Params[] = {
 std::make_pair(".global_tid.", KmpInt32PtrTy),
 std::make_pair(".bound_tid.", KmpInt32PtrTy),
 std::make_pair(StringRef(), QualType()) // __context with shared vars
@@ -897,14 +897,14 @@ void Sema::ActOnOpenMPRegionStart(OpenMP
 break;
   }
   case OMPD_simd: {
-Sema::CapturedParamNameType Params[1] = {
+Sema::CapturedParamNameType Params[] = {
 std::make_pair(StringRef(), QualType()) // __context with shared vars
 };
 ActOnCapturedRegionStart(Loc, CurScope, CR_OpenMP, Params);
 break;
   }
   case OMPD_for: {
-Sema::CapturedParamNameType Params[1] = {
+Sema::CapturedParamNameType Params[] = {
 std::make_pair(StringRef(), QualType()) // __context with shared vars
 };
 ActOnCapturedRegionStart(Loc, CurScope, CR_OpenMP, Params);
@@ -1414,7 +1414,7 @@ static bool CheckOpenMPIterationSpace(Op
   OpenMPIterationSpaceChecker ISC(SemaRef, For->getForLoc());
 
   // Check init.
-  Stmt *Init = For->getInit();
+  auto Init = For->getInit();
   if (ISC.CheckInit(Init)) {
 return true;
   }
@@ -1422,14 +1422,14 @@ static bool CheckOpenMPIterationSpace(Op
   bool HasErrors = false;
 
   // Check loop variable's type.
-  VarDecl *Var = ISC.GetLoopVar();
+  auto Var = ISC.GetLoopVar();
 
   // OpenMP [2.6, Canonical Loop Form]
   // Var is one of the following:
   //   A variable of signed or unsigned integer type.
   //   For C++, a variable of a random access iterator type.
   //   For C, a variable of a pointer type.
-  QualType VarType = Var->getType();
+  auto VarType = Var->getType();
   if (!VarType->isDependentType() && !VarType->isIntegerType() &&
   !VarType->isPointerType() &&
   !(SemaRef.getLangOpts().CPlusPlus && VarType->isOverloadableType())) {
@@ -1525,18 +1525,12 @@ static bool CheckOpenMPLoop(OpenMPDirect
   return false;
 }
 
-namespace {
-struct OMPCollapseClauseFilter {
-  OMPCollapseClauseFilter() {}
-  bool operator()(const OMPClause *C) {
-return C->getClauseKind() == OMPC_collapse;
-  }
-};
-} // namespace
-
 static Expr *GetCollapseNumberExpr(ArrayRef Clauses) {
-  OMPExecutableDirective::filtered_clause_iterator I(
-  Clauses);
+  auto CollapseFilter = [](const OMPClause *C) -> bool {
+return C->getClauseKind() == OMPC_collapse;
+  };
+  OMPExecutableDirective::filtered_clause_iterator I(
+  Clauses, CollapseFilter);
   if (I)
 return cast(*I)->getNumForLoops();
   return nu

Re: [PATCH] Change loop unroll and vectorizer metadata prefix to 'llvm.loop.'

[Tyler Nowicki]

Hi Mark,

I also have a weak preference for the llvm.loop.unroll/vectorize option because 
I would like to add metadata for interleaving and I think interleave.enable 
would look better than interleaver.enable. Otherwise LGTM!

Tyler

On Jun 24, 2014, at 4:28 PM, Hal Finkel  wrote:

> - Original Message -
>> From: "Mark Heffernan" 
>> To: "Hal Finkel" 
>> Cc: llvm-comm...@cs.uiuc.edu, "cfe-commits" , 
>> "Pekka Jääskeläinen"
>> 
>> Sent: Tuesday, June 24, 2014 4:18:30 PM
>> Subject: Re: [PATCH] Change loop unroll and vectorizer metadata prefix to 
>> 'llvm.loop.'
>> 
>> The attached patch includes a note in ReleaseNotes.rst and code to
>> autoupgrade llvm.vectorizer.* metadata strings to
>> llvm.loop.vectorizer.* when reading assembly and bitcode.  PTAL.
> 
> Okay, thanks. That's better. However, I just noticed that the proposed 
> mapping:
> 
>> llvm.vectorizer.* => llvm.loop.vectorizer.*
>> llvm.loopunroll.* => llvm.loop.unroll.*
> 
> is not grammatically consistent. I think that we should have 
> ("llvm.loop.vectorize" and "llvm.loop.unroll") or ("llvm.loop.vectorizer" and 
> "llvm.loop.unroller"). I have a weak preference for the first pair, but I 
> care more about consistency than the choice.
> 
> -Hal
> 
>> 
>> Thanks!
>> Mark
>> 
>> On Tue, Jun 24, 2014 at 9:53 AM, Hal Finkel  wrote:
>>> - Original Message -
 From: "Mark Heffernan" 
 To: "Hal Finkel" 
 Cc: llvm-comm...@cs.uiuc.edu, "cfe-commits"
 , "Pekka Jääskeläinen"
 
 Sent: Tuesday, June 24, 2014 11:18:33 AM
 Subject: Re: [PATCH] Change loop unroll and vectorizer metadata
 prefix to 'llvm.loop.'
 
 Thanks for the comments.  I'll add something to the release notes.
 
 On Tue, Jun 24, 2014 at 3:52 AM, Hal Finkel 
 wrote:
> Moreover, for metadata that was supported by the 3.4 release,
> autoupgrade support should be added. Please do this before you
> commit.
 
 By autoupgrade do you mean be permissive about what is accepted?
 That
 is, accept llvm.vectorizer.* and llvm.loop.vectorizer.* but only
 emit
 the llvm.loop form from the FE.  Or do you mean try to rename the
 metadata as soon as it parsed?  I can see how to do the first case
 (be
 permissive) easily, but for the second (rename metadata) do you
 have
 any suggestions for the best place to cut in (I'm fairly new to
 the
 code base)?
>>> 
>>> No, I mean the second. I believe that most of the current logic for
>>> this is in lib/IR/AutoUpgrade.cpp
>>> 
>>> -Hal
>>> 
 
 Thanks!
 Mark
 
> 
> -Hal
> 
>> 
>> On Tue, Jun 24, 2014 at 12:30 AM, Mark Heffernan
>> 
>> wrote:
>>> These patches rename the loop unrolling and loop vectorizer
>>> metadata
>>> such that they have a common 'llvm.loop.' prefix.  Metadata
>>> name
>>> changes:
>>> 
>>> llvm.vectorizer.* => llvm.loop.vectorizer.*
>>> llvm.loopunroll.* => llvm.loop.unroll.*
>>> 
>>> This was a suggestion from an earlier review
>>> (http://reviews.llvm.org/D4090) which added the loop
>>> unrolling
>>> metadata.  Two patches are attached.  One for front-end and
>>> one
>>> for
>>> optimizer.
>>> 
>>> Mark
>> 
>> 
>> 
>> --
>> --PJ
>> ___
>> cfe-commits mailing list
>> cfe-commits@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>> 
> 
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
 
>>> 
>>> --
>>> Hal Finkel
>>> Assistant Computational Scientist
>>> Leadership Computing Facility
>>> Argonne National Laboratory
>> 
> 
> -- 
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> 
> ___
> llvm-commits mailing list
> llvm-comm...@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r211604 - Use lowercase windows.h for mingw cross compilation.

[Alp Toker]

On 25/06/2014 00:06, Zachary Turner wrote:
Couldn't LLVM expose a registry interface on Windows and then the 
front-end could conditionally include this header on Windows?  Other 
users of LLVM might wish to use the registry too.


Using the registry in WindowsToolChain is an unfortunate/isolated 
toolchain hack that needs to be kept around for the time being.


It's not a facility we want to propagate, abstract or normalize the 
usage of in LLVM.


Alp.




On Tue, Jun 24, 2014 at 1:11 PM, Reid Kleckner > wrote:


IMO it's OK to use windows.h directly in this case.  There's no
sensible cross-platform interface to the registry that we could
add to lib/Support.  The registry only exists on Windows.


On Tue, Jun 24, 2014 at 10:11 AM, Aaron Ballman
mailto:aa...@aaronballman.com>> wrote:

On Tue, Jun 24, 2014 at 1:09 PM, Alp Toker mailto:a...@nuanti.com>> wrote:
>
> On 24/06/2014 19:53, Aaron Ballman wrote:
>>
>> On Tue, Jun 24, 2014 at 12:18 PM, Logan Chien
mailto:tzuhsiang.ch...@gmail.com>>
>> wrote:
>>>
>>> Author: logan
>>> Date: Tue Jun 24 11:18:10 2014
>>> New Revision: 211604
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=211604&view=rev
>>> Log:
>>> Use lowercase windows.h for mingw cross compilation.
>>>
>>> Modified:
>>>  cfe/trunk/lib/Driver/WindowsToolChain.cpp
>>>
>>> Modified: cfe/trunk/lib/Driver/WindowsToolChain.cpp
>>> URL:
>>>

http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/WindowsToolChain.cpp?rev=211604&r1=211603&r2=211604&view=diff
>>>
>>>

==
>>> --- cfe/trunk/lib/Driver/WindowsToolChain.cpp (original)
>>> +++ cfe/trunk/lib/Driver/WindowsToolChain.cpp Tue Jun 24
11:18:10 2014
>>> @@ -30,7 +30,7 @@
>>> #define WIN32_LEAN_AND_MEAN
>>> #define NOGDI
>>> #define NOMINMAX
>>> -  #include 
>>> +  #include 
>>>   #endif
>>
>> Why is windows.h being included here instead of
WindowsSupport.h?
>
>
> WindowsSupport.h is internal to LLVM at the moment. We
probably don't need
> it for the limited uses of windows.h in the frontend.

That's reasonably fair, but I think getting any instances of
Windows.h
out of the frontend would be a very good thing. Obviously,
that has no
bearing on this patch. :-)

~Aaron
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu 
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits



___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu 
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits




___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


--
http://www.nuanti.com
the browser experts

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] libcxxabi/unwind: Add support for ARM EHABI in AddressSpace.hpp

[Nick Kledzik]

The unwinder changes should be a different patch than the other libcxxabi 
changes.  Post-commit review is fine.  


Some other details I just noticed:

Are the changes to UnwindLevel1.c to cast logging parameters to long-long still 
needed now that ARM is no longer compiling that file?

It looks like the definition of static_assert() is commented out.

-Nick

On Jun 24, 2014, at 3:19 PM, Nico Weber  wrote:
> On Tue, Jun 24, 2014 at 2:18 PM, Nick Kledzik  wrote:
> Nico,
> 
> This looks good now.  
> 
> Cool, thanks! What does this mean in practice?
> 
> a) Check in Dana's patch on this thread, post next patch, wait for review
> b) Check in everything we have, in logical chunks, and use post-commit review 
> where necessary?
> 
> Thanks,
> Nico
>  
> 
> -Nick
> 
> On Jun 22, 2014, at 2:02 PM, Nico Weber  wrote:
>> On Mon, Jun 16, 2014 at 1:15 PM, Nick Kledzik  wrote:
>> 
>> On Jun 16, 2014, at 10:05 AM, Nico Weber  wrote:
>> 
>>> Nick, do you want us to put EHABI in a separate file before upstreaming,
>> 
>> Yes.   It should be easy to de-conditionalize your current changes to 
>> UnwindLevel1.c and merge it with your Unwind-arm.c to make the new 
>> EHABI-only file.
>> 
>> Please take another look:
>> https://github.com/awong-dev/ndk/compare/upstream-llvm-ndkpatched...master#files_bucket
>> 
>> I renamed Unwind-arm.cpp to Unwind-EHABI.cpp, and moved all new code from 
>> UnwindLevel1.c to there instead. I also reformatted the 80col lines. The 
>> file still calls the unw_ functions, let me know if you want us to move off 
>> those before upstreaming.
>> 
>> > * In general, the conditionals should consider the possibility of three 
>> > unwinders for arm: SJLJ, EHABI, and (someday maybe) Itanium.   For 
>> > instance, the new functions in UnwindRegisters{Save|Restore}.S should be 
>> > conditionalized with some EHABI conditional (not just __arm__ && 
>> > !__APPLE), and in Registers.hpp, all the new EHABI specific stuff in 
>> > Registers_arm should be conditionalized with ARM_EHABI.
>> 
>> Registers.hpp is currently free of preprocessor defines and relies on the 
>> linker throwing out unused functions, so I didn't do this. Are you worried 
>> about jumpTo() having different behavior? Right now, Registers_arm is only 
>> used for EHABI unwinding, so it seems waiting with these ifdefs until 
>> someone wants to add itanium unwinding for arm might be ok?
>> 
>> Thanks,
>> Nico
>> 
>> (ps: Please ignore the first change in UnwindRegistersSave.S, I think that's 
>> some merge bug. https://github.com/awong-dev/ndk/pull/152 fixes it.)
> 
> 

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Don't eagerly evaluate the TypeSourceInfo when mangling names.

[David Blaikie]

It'd be good to include an explanation (in a comment and/or the commit
message) as to why this is necessary and untested in-tree so when someone
comes back to this they don't remove it for being unnecessary.

http://reviews.llvm.org/D4281



___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Don't eagerly evaluate the TypeSourceInfo when mangling names.

[David Blaikie]

It'd be good to include an explanation (in a comment and/or the commit
message) as to why this is necessary and untested in-tree so when someone
comes back to this they don't remove it for being unnecessary.
On Jun 24, 2014 4:46 PM, "Zachary Turner"  wrote:

> Hi rnk, majnemer,
>
> Don't eagerly evaluate the TypeSourceInfo while mangling.
>
> A VarDecl may not have TypeSourceInfo, for example if source is
> generated in-memory by another application.  This patch changes
> the mangler to use a default instance if the TypeSourceInfo
> doesn't exist.
>
> http://reviews.llvm.org/D4281
>
> Files:
>   lib/AST/MicrosoftMangle.cpp
>
> Index: lib/AST/MicrosoftMangle.cpp
> ===
> --- lib/AST/MicrosoftMangle.cpp
> +++ lib/AST/MicrosoftMangle.cpp
> @@ -418,11 +418,13 @@
>// ::=   # pointers,
> references
>// Pointers and references are odd. The type of 'int * const foo;' gets
>// mangled as 'QAHA' instead of 'PAHB', for example.
> -  TypeLoc TL = VD->getTypeSourceInfo()->getTypeLoc();
> +  SourceRange SR;
> +  if (TypeSourceInfo *TI = VD->getTypeSourceInfo())
> +SR = TI->getTypeLoc().getSourceRange();
>QualType Ty = VD->getType();
>if (Ty->isPointerType() || Ty->isReferenceType() ||
>Ty->isMemberPointerType()) {
> -mangleType(Ty, TL.getSourceRange(), QMM_Drop);
> +mangleType(Ty, SR, QMM_Drop);
>  manglePointerExtQualifiers(
>  Ty.getDesugaredType(getASTContext()).getLocalQualifiers(),
> nullptr);
>  if (const MemberPointerType *MPT = Ty->getAs()) {
> @@ -440,7 +442,7 @@
>  else
>mangleQualifiers(Ty.getQualifiers(), false);
>} else {
> -mangleType(Ty, TL.getSourceRange(), QMM_Drop);
> +mangleType(Ty, SR, QMM_Drop);
>  mangleQualifiers(Ty.getLocalQualifiers(), false);
>}
>  }
>
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r211654 - Fix parsing nested __if_exists blocks

[Reid Kleckner]

Author: rnk
Date: Tue Jun 24 19:28:35 2014
New Revision: 211654

URL: http://llvm.org/viewvc/llvm-project?rev=211654&view=rev
Log:
Fix parsing nested __if_exists blocks

Rather than having kw___if_exists be a special case of
ParseCompoundStatementBody, we can look for kw___if_exists in the big
switch over for valid statement tokens in ParseStatementOrDeclaration.

Nested __if_exists blocks are used in the DECLARE_REGISTRY_RESOURCEID
macro from atlcom.h.

Modified:
cfe/trunk/lib/Parse/ParseStmt.cpp
cfe/trunk/test/Parser/ms-if-exists.cpp

Modified: cfe/trunk/lib/Parse/ParseStmt.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseStmt.cpp?rev=211654&r1=211653&r2=211654&view=diff
==
--- cfe/trunk/lib/Parse/ParseStmt.cpp (original)
+++ cfe/trunk/lib/Parse/ParseStmt.cpp Tue Jun 24 19:28:35 2014
@@ -273,6 +273,14 @@ Retry:
 break;
   }
 
+  case tok::kw___if_exists:
+  case tok::kw___if_not_exists:
+ProhibitAttributes(Attrs);
+ParseMicrosoftIfExistsStatement(Stmts);
+// An __if_exists block is like a compound statement, but it doesn't create
+// a new scope.
+return StmtEmpty();
+
   case tok::kw_try: // C++ 15: try-block
 return ParseCXXTryBlock();
 
@@ -914,12 +922,6 @@ StmtResult Parser::ParseCompoundStatemen
   continue;
 }
 
-if (getLangOpts().MicrosoftExt && (Tok.is(tok::kw___if_exists) ||
-Tok.is(tok::kw___if_not_exists))) {
-  ParseMicrosoftIfExistsStatement(Stmts);
-  continue;
-}
-
 StmtResult R;
 if (Tok.isNot(tok::kw___extension__)) {
   R = ParseStatementOrDeclaration(Stmts, false);

Modified: cfe/trunk/test/Parser/ms-if-exists.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Parser/ms-if-exists.cpp?rev=211654&r1=211653&r2=211654&view=diff
==
--- cfe/trunk/test/Parser/ms-if-exists.cpp (original)
+++ cfe/trunk/test/Parser/ms-if-exists.cpp Tue Jun 24 19:28:35 2014
@@ -1,7 +1,5 @@
 // RUN: %clang_cc1 %s -std=c++11 -fsyntax-only -Wmicrosoft -verify 
-fms-extensions
 
-// expected-no-diagnostics
-
 class MayExist {
 private:
   typedef int Type;
@@ -101,3 +99,19 @@ class IfExistsClassScope {
 int var244;
   }
 };
+
+void test_nested_if_exists() {
+  __if_exists(MayExist::Type) {
+int x = 42;
+__if_not_exists(MayExist::Type_not) {
+  x++;
+}
+  }
+}
+
+void test_attribute_on_if_exists() {
+  [[clang::fallthrough]] // expected-error {{an attribute list cannot appear 
here}}
+  __if_exists(MayExist::Type) {
+int x;
+  }
+}


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r211604 - Use lowercase windows.h for mingw cross compilation.

[Rafael Espíndola]

On 24 June 2014 17:06, Zachary Turner  wrote:
> Couldn't LLVM expose a registry interface on Windows and then the front-end
> could conditionally include this header on Windows?  Other users of LLVM
> might wish to use the registry too.

When they do that would be a reasonable time to add such an interface
to llvm,not before.

Cheers,
Rafael
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r211650 - Add a missing test for the __if_exists extension

[Reid Kleckner]

Author: rnk
Date: Tue Jun 24 19:10:50 2014
New Revision: 211650

URL: http://llvm.org/viewvc/llvm-project?rev=211650&view=rev
Log:
Add a missing test for the __if_exists extension

MSVC does not create a new scope for the body of an __if_exists compound
statement.  Clang already gets this right today, but it was untested.

Modified:
cfe/trunk/test/Parser/ms-if-exists.cpp

Modified: cfe/trunk/test/Parser/ms-if-exists.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Parser/ms-if-exists.cpp?rev=211650&r1=211649&r2=211650&view=diff
==
--- cfe/trunk/test/Parser/ms-if-exists.cpp (original)
+++ cfe/trunk/test/Parser/ms-if-exists.cpp Tue Jun 24 19:10:50 2014
@@ -25,6 +25,16 @@ void test_if_exists_stmts() {
   }
 }
 
+int if_exists_creates_no_scope() {
+  __if_exists(MayExist::Type) {
+int x;  // 'x' is declared in the parent scope.
+  }
+  __if_not_exists(MayExist::Type_not) {
+x++;
+  }
+  return x;
+}
+
 __if_exists(MayExist::Type) {
   int var23;
 }


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r211649 - Split tests for __if_exists out into their own file

[Reid Kleckner]

Author: rnk
Date: Tue Jun 24 19:08:10 2014
New Revision: 211649

URL: http://llvm.org/viewvc/llvm-project?rev=211649&view=rev
Log:
Split tests for __if_exists out into their own file

Added:
cfe/trunk/test/Parser/ms-if-exists.cpp
Modified:
cfe/trunk/test/Parser/MicrosoftExtensions.cpp

Modified: cfe/trunk/test/Parser/MicrosoftExtensions.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Parser/MicrosoftExtensions.cpp?rev=211649&r1=211648&r2=211649&view=diff
==
--- cfe/trunk/test/Parser/MicrosoftExtensions.cpp (original)
+++ cfe/trunk/test/Parser/MicrosoftExtensions.cpp Tue Jun 24 19:08:10 2014
@@ -227,103 +227,6 @@ void interface_test() {
 
 __int64 x7 = __int64(0);
 
-
-namespace If_exists_test {
-
-class IF_EXISTS {
-private:
-typedef int Type;
-};
-
-int __if_exists_test() {
-  int b=0;
-  __if_exists(IF_EXISTS::Type) {
- b++;
- b++;
-  }
-  __if_exists(IF_EXISTS::Type_not) {
- this will not compile.
-  }
-  __if_not_exists(IF_EXISTS::Type) {
- this will not compile.
-  }
-  __if_not_exists(IF_EXISTS::Type_not) {
- b++;
- b++;
-  }
-}
-
-
-__if_exists(IF_EXISTS::Type) {
-  int var23;
-}
-
-__if_exists(IF_EXISTS::Type_not) {
- this will not compile.
-}
-
-__if_not_exists(IF_EXISTS::Type) {
- this will not compile.
-}
-
-__if_not_exists(IF_EXISTS::Type_not) {
-  int var244;
-}
-
-int __if_exists_init_list() {
-
-  int array1[] = {
-0,
-__if_exists(IF_EXISTS::Type) {2, }
-3
-  };
-
-  int array2[] = {
-0,
-__if_exists(IF_EXISTS::Type_not) { this will not compile }
-3
-  };
-
-  int array3[] = {
-0,
-__if_not_exists(IF_EXISTS::Type_not) {2, }
-3
-  };
-
-  int array4[] = {
-0,
-__if_not_exists(IF_EXISTS::Type) { this will not compile }
-3
-  };
-
-}
-
-
-class IF_EXISTS_CLASS_TEST {
-  __if_exists(IF_EXISTS::Type) {
-// __if_exists, __if_not_exists can nest
-__if_not_exists(IF_EXISTS::Type_not) {
-  int var123;
-}
-int var23;
-  }
-
-  __if_exists(IF_EXISTS::Type_not) {
-   this will not compile.
-  }
-
-  __if_not_exists(IF_EXISTS::Type) {
-   this will not compile.
-  }
-
-  __if_not_exists(IF_EXISTS::Type_not) {
-int var244;
-  }
-};
-
-}
-
-
 int __identifier(generic) = 3;
 int __identifier(int) = 4;
 struct __identifier(class) { __identifier(class) *__identifier(for); };

Added: cfe/trunk/test/Parser/ms-if-exists.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Parser/ms-if-exists.cpp?rev=211649&view=auto
==
--- cfe/trunk/test/Parser/ms-if-exists.cpp (added)
+++ cfe/trunk/test/Parser/ms-if-exists.cpp Tue Jun 24 19:08:10 2014
@@ -0,0 +1,93 @@
+// RUN: %clang_cc1 %s -std=c++11 -fsyntax-only -Wmicrosoft -verify 
-fms-extensions
+
+// expected-no-diagnostics
+
+class MayExist {
+private:
+  typedef int Type;
+};
+
+void test_if_exists_stmts() {
+  int b = 0;
+  __if_exists(MayExist::Type) {
+b++;
+b++;
+  }
+  __if_exists(MayExist::Type_not) {
+this will not compile.
+  }
+  __if_not_exists(MayExist::Type) {
+this will not compile.
+  }
+  __if_not_exists(MayExist::Type_not) {
+b++;
+b++;
+  }
+}
+
+__if_exists(MayExist::Type) {
+  int var23;
+}
+
+__if_exists(MayExist::Type_not) {
+  this will not compile.
+}
+
+__if_not_exists(MayExist::Type) {
+  this will not compile.
+}
+
+__if_not_exists(MayExist::Type_not) {
+  int var244;
+}
+
+void test_if_exists_init_list() {
+
+  int array1[] = {
+0,
+__if_exists(MayExist::Type) {2, }
+3
+  };
+
+  int array2[] = {
+0,
+__if_exists(MayExist::Type_not) { this will not compile }
+3
+  };
+
+  int array3[] = {
+0,
+__if_not_exists(MayExist::Type_not) {2, }
+3
+  };
+
+  int array4[] = {
+0,
+__if_not_exists(MayExist::Type) { this will not compile }
+3
+  };
+
+}
+
+
+class IfExistsClassScope {
+  __if_exists(MayExist::Type) {
+// __if_exists, __if_not_exists can nest
+__if_not_exists(MayExist::Type_not) {
+  int var123;
+}
+int var23;
+  }
+
+  __if_exists(MayExist::Type_not) {
+   this will not compile.
+  }
+
+  __if_not_exists(MayExist::Type) {
+   this will not compile.
+  }
+
+  __if_not_exists(MayExist::Type_not) {
+int var244;
+  }
+};


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r211648 - MS ABI: Ignore dll attributes on partial template specializations

[Hans Wennborg]

Author: hans
Date: Tue Jun 24 18:57:13 2014
New Revision: 211648

URL: http://llvm.org/viewvc/llvm-project?rev=211648&view=rev
Log:
MS ABI: Ignore dll attributes on partial template specializations

Modified:
cfe/trunk/lib/Sema/SemaDeclAttr.cpp
cfe/trunk/test/CodeGenCXX/dllexport.cpp
cfe/trunk/test/CodeGenCXX/dllimport.cpp
cfe/trunk/test/SemaCXX/dllexport.cpp
cfe/trunk/test/SemaCXX/dllimport.cpp

Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=211648&r1=211647&r2=211648&view=diff
==
--- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Tue Jun 24 18:57:13 2014
@@ -3858,6 +3858,13 @@ DLLExportAttr *Sema::mergeDLLExportAttr(
 }
 
 static void handleDLLAttr(Sema &S, Decl *D, const AttributeList &A) {
+  if (isa(D) &&
+  S.Context.getTargetInfo().getCXXABI().isMicrosoft()) {
+S.Diag(A.getRange().getBegin(), diag::warn_attribute_ignored)
+<< A.getName();
+return;
+  }
+
   unsigned Index = A.getAttributeSpellingListIndex();
   Attr *NewAttr = A.getKind() == AttributeList::AT_DLLExport
   ? (Attr *)S.mergeDLLExportAttr(D, A.getRange(), Index)

Modified: cfe/trunk/test/CodeGenCXX/dllexport.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/dllexport.cpp?rev=211648&r1=211647&r2=211648&view=diff
==
--- cfe/trunk/test/CodeGenCXX/dllexport.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/dllexport.cpp Tue Jun 24 18:57:13 2014
@@ -20,6 +20,7 @@ struct External { int v; };
 #define UNIQ(name) JOIN(name, __LINE__)
 #define USEVAR(var) int UNIQ(use)() { return var; }
 #define USE(func) void UNIQ(use)() { func(); }
+#define USEMEMFUNC(class, func) void (class::*UNIQ(use)())() { return 
&class::func; }
 #define INSTVAR(var) template int var;
 #define INST(func) template void func();
 
@@ -568,3 +569,16 @@ namespace ReferencedInlineMethodInNested
   // M32-DAG: define weak_odr dllexport x86_thiscallcc void 
@"\01?foo@S@ReferencedInlineMethodInNestedClass@@QAEXXZ"
   // M32-DAG: define linkonce_odr x86_thiscallcc void 
@"\01?bar@T@S@ReferencedInlineMethodInNestedClass@@QAEXXZ"
 }
+
+// MS ignores DLL attributes on partial specializations.
+template  struct PartiallySpecializedClassTemplate {};
+template  struct __declspec(dllexport) 
PartiallySpecializedClassTemplate { void f() {} };
+USEMEMFUNC(PartiallySpecializedClassTemplate, f);
+// M32-DAG: define linkonce_odr x86_thiscallcc void 
@"\01?f@?$PartiallySpecializedClassTemplate@PAX@@QAEXXZ"
+// G32-DAG: define weak_odr dllexport x86_thiscallcc void 
@_ZN33PartiallySpecializedClassTemplateIPvE1fEv
+
+template  struct ExplicitlySpecializedClassTemplate {};
+template <> struct __declspec(dllexport) 
ExplicitlySpecializedClassTemplate { void f() {} };
+USEMEMFUNC(ExplicitlySpecializedClassTemplate, f);
+// M32-DAG: define weak_odr dllexport x86_thiscallcc void 
@"\01?f@?$ExplicitlySpecializedClassTemplate@PAX@@QAEXXZ"
+// G32-DAG: define weak_odr dllexport x86_thiscallcc void 
@_ZN34ExplicitlySpecializedClassTemplateIPvE1fEv

Modified: cfe/trunk/test/CodeGenCXX/dllimport.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/dllimport.cpp?rev=211648&r1=211647&r2=211648&view=diff
==
--- cfe/trunk/test/CodeGenCXX/dllimport.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/dllimport.cpp Tue Jun 24 18:57:13 2014
@@ -615,7 +615,7 @@ namespace ClassTemplateStaticDef {
 static int x;
   };
   template  int T::x;
-  // M32-DAG: @"\01?x@?$T@PAX@ClassTemplateStaticDef@@2HA" = 
available_externally dllimport global i32 0
+  // GNU-DAG: @_ZN22ClassTemplateStaticDef1TIPvE1xE = available_externally 
dllimport global i32 0
   int g() { return T::x; }
 }
 
@@ -649,3 +649,16 @@ namespace PR19933 {
   // MSC-DAG: @"\01?x@?$D@$0CK@@PR19933@@2HA" = available_externally dllimport 
global i32 43
   // MSC-DAG: @"\01?y@?$D@$0CK@@PR19933@@2HA" = available_externally dllimport 
global i32 0
 }
+
+// MS ignores DLL attributes on partial specializations.
+template  struct PartiallySpecializedClassTemplate {};
+template  struct __declspec(dllimport) 
PartiallySpecializedClassTemplate { void f() {} };
+USEMEMFUNC(PartiallySpecializedClassTemplate, f);
+// M32-DAG: define linkonce_odr x86_thiscallcc void 
@"\01?f@?$PartiallySpecializedClassTemplate@PAX@@QAEXXZ"
+// G32-DAG: {{declare|define available_externally}} dllimport x86_thiscallcc 
void @_ZN33PartiallySpecializedClassTemplateIPvE1fEv
+
+template  struct ExplicitlySpecializedClassTemplate {};
+template <> struct __declspec(dllimport) 
ExplicitlySpecializedClassTemplate { void f() {} };
+USEMEMFUNC(ExplicitlySpecializedClassTemplate, f);
+// M32-DAG: {{declare|define available_externally}} dllimport x86_thiscallcc 
void @

r211647 - Merge handleDLLImportAttr and handleDLLExportAttr into one function.

[Hans Wennborg]

Author: hans
Date: Tue Jun 24 18:57:05 2014
New Revision: 211647

URL: http://llvm.org/viewvc/llvm-project?rev=211647&view=rev
Log:
Merge handleDLLImportAttr and handleDLLExportAttr into one function.

Modified:
cfe/trunk/lib/Sema/SemaDeclAttr.cpp

Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=211647&r1=211646&r2=211647&view=diff
==
--- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Tue Jun 24 18:57:05 2014
@@ -3844,13 +3844,6 @@ DLLImportAttr *Sema::mergeDLLImportAttr(
   return ::new (Context) DLLImportAttr(Range, Context, AttrSpellingListIndex);
 }
 
-static void handleDLLImportAttr(Sema &S, Decl *D, const AttributeList &Attr) {
-  unsigned Index = Attr.getAttributeSpellingListIndex();
-  DLLImportAttr *NewAttr = S.mergeDLLImportAttr(D, Attr.getRange(), Index);
-  if (NewAttr)
-D->addAttr(NewAttr);
-}
-
 DLLExportAttr *Sema::mergeDLLExportAttr(Decl *D, SourceRange Range,
 unsigned AttrSpellingListIndex) {
   if (DLLImportAttr *Import = D->getAttr()) {
@@ -3864,9 +3857,11 @@ DLLExportAttr *Sema::mergeDLLExportAttr(
   return ::new (Context) DLLExportAttr(Range, Context, AttrSpellingListIndex);
 }
 
-static void handleDLLExportAttr(Sema &S, Decl *D, const AttributeList &Attr) {
-  unsigned Index = Attr.getAttributeSpellingListIndex();
-  DLLExportAttr *NewAttr = S.mergeDLLExportAttr(D, Attr.getRange(), Index);
+static void handleDLLAttr(Sema &S, Decl *D, const AttributeList &A) {
+  unsigned Index = A.getAttributeSpellingListIndex();
+  Attr *NewAttr = A.getKind() == AttributeList::AT_DLLExport
+  ? (Attr *)S.mergeDLLExportAttr(D, A.getRange(), Index)
+  : (Attr *)S.mergeDLLImportAttr(D, A.getRange(), Index);
   if (NewAttr)
 D->addAttr(NewAttr);
 }
@@ -4070,10 +4065,8 @@ static void ProcessDeclAttribute(Sema &S
 handleX86ForceAlignArgPointerAttr(S, D, Attr);
 break;
   case AttributeList::AT_DLLExport:
-handleDLLExportAttr(S, D, Attr);
-break;
   case AttributeList::AT_DLLImport:
-handleDLLImportAttr(S, D, Attr);
+handleDLLAttr(S, D, Attr);
 break;
   case AttributeList::AT_Mips16:
 handleSimpleAttribute(S, D, Attr);


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Location and Range unittests for FriendDecl

[Nikola Smiljanic]

On Wed, Jun 25, 2014 at 2:04 AM, Richard Smith 
wrote:

>
> This is a C++11 feature:
>
> struct A;
> struct B {
>   friend A; // note, not 'friend struct A;'
> };
>

You're right, not sure how I missed this as I have a test for this case.


> Should be:
>
> template struct C {};
> struct D {
>   template<> friend struct C;
> };
>
> (That's ill-formed, but our error recovery path treats it as if it didn't
> have the 'template<>'.) If that doesn't hit that codepath, I think it may
> be unreachable.
>

Nope, that one is handled in ActOnClassTemplateSpecialization. I think that
this code is unreachable...

I still need you to OK my changes before I commit them.
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Change loop unroll and vectorizer metadata prefix to 'llvm.loop.'

[Hal Finkel]

- Original Message -
> From: "Mark Heffernan" 
> To: "Hal Finkel" 
> Cc: llvm-comm...@cs.uiuc.edu, "cfe-commits" , "Pekka 
> Jääskeläinen"
> 
> Sent: Tuesday, June 24, 2014 4:18:30 PM
> Subject: Re: [PATCH] Change loop unroll and vectorizer metadata prefix to 
> 'llvm.loop.'
> 
> The attached patch includes a note in ReleaseNotes.rst and code to
> autoupgrade llvm.vectorizer.* metadata strings to
> llvm.loop.vectorizer.* when reading assembly and bitcode.  PTAL.

Okay, thanks. That's better. However, I just noticed that the proposed mapping:

> llvm.vectorizer.* => llvm.loop.vectorizer.*
> llvm.loopunroll.* => llvm.loop.unroll.*

is not grammatically consistent. I think that we should have 
("llvm.loop.vectorize" and "llvm.loop.unroll") or ("llvm.loop.vectorizer" and 
"llvm.loop.unroller"). I have a weak preference for the first pair, but I care 
more about consistency than the choice.

 -Hal

> 
> Thanks!
> Mark
> 
> On Tue, Jun 24, 2014 at 9:53 AM, Hal Finkel  wrote:
> > - Original Message -
> >> From: "Mark Heffernan" 
> >> To: "Hal Finkel" 
> >> Cc: llvm-comm...@cs.uiuc.edu, "cfe-commits"
> >> , "Pekka Jääskeläinen"
> >> 
> >> Sent: Tuesday, June 24, 2014 11:18:33 AM
> >> Subject: Re: [PATCH] Change loop unroll and vectorizer metadata
> >> prefix to 'llvm.loop.'
> >>
> >> Thanks for the comments.  I'll add something to the release notes.
> >>
> >> On Tue, Jun 24, 2014 at 3:52 AM, Hal Finkel 
> >> wrote:
> >> > Moreover, for metadata that was supported by the 3.4 release,
> >> > autoupgrade support should be added. Please do this before you
> >> > commit.
> >>
> >> By autoupgrade do you mean be permissive about what is accepted?
> >>  That
> >> is, accept llvm.vectorizer.* and llvm.loop.vectorizer.* but only
> >> emit
> >> the llvm.loop form from the FE.  Or do you mean try to rename the
> >> metadata as soon as it parsed?  I can see how to do the first case
> >> (be
> >> permissive) easily, but for the second (rename metadata) do you
> >> have
> >> any suggestions for the best place to cut in (I'm fairly new to
> >> the
> >> code base)?
> >
> > No, I mean the second. I believe that most of the current logic for
> > this is in lib/IR/AutoUpgrade.cpp
> >
> >  -Hal
> >
> >>
> >> Thanks!
> >> Mark
> >>
> >> >
> >> >  -Hal
> >> >
> >> >>
> >> >> On Tue, Jun 24, 2014 at 12:30 AM, Mark Heffernan
> >> >> 
> >> >> wrote:
> >> >> > These patches rename the loop unrolling and loop vectorizer
> >> >> > metadata
> >> >> > such that they have a common 'llvm.loop.' prefix.  Metadata
> >> >> > name
> >> >> > changes:
> >> >> >
> >> >> > llvm.vectorizer.* => llvm.loop.vectorizer.*
> >> >> > llvm.loopunroll.* => llvm.loop.unroll.*
> >> >> >
> >> >> > This was a suggestion from an earlier review
> >> >> > (http://reviews.llvm.org/D4090) which added the loop
> >> >> > unrolling
> >> >> > metadata.  Two patches are attached.  One for front-end and
> >> >> > one
> >> >> > for
> >> >> > optimizer.
> >> >> >
> >> >> > Mark
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> --PJ
> >> >> ___
> >> >> cfe-commits mailing list
> >> >> cfe-commits@cs.uiuc.edu
> >> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> >> >>
> >> >
> >> > --
> >> > Hal Finkel
> >> > Assistant Computational Scientist
> >> > Leadership Computing Facility
> >> > Argonne National Laboratory
> >>
> >
> > --
> > Hal Finkel
> > Assistant Computational Scientist
> > Leadership Computing Facility
> > Argonne National Laboratory
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Improve diagnostic message for misplaced square brackets

[Richard Trieu]

Committed at r211641.


Comment at: lib/Parse/ParseDecl.cpp:5646-5649
@@ +5645,6 @@
+
+  // Nothing after the brackets has been parsed as part of the Declarator, so
+  // no correction is needed.
+  if (OldEndLoc == D.getLocEnd())
+return;
+

Richard Smith wrote:
> This looks unreachable. If nothing after the brackets has been parsed, then 
> there can't be an identifier, so we should have bailed out already. Remove?
Removed.

http://reviews.llvm.org/D2712



___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r211641 - Provide a better diagnostic when braces are put before the identifier.

[Richard Trieu]

Author: rtrieu
Date: Tue Jun 24 18:14:24 2014
New Revision: 211641

URL: http://llvm.org/viewvc/llvm-project?rev=211641&view=rev
Log:
Provide a better diagnostic when braces are put before the identifier.

When a user types:
  int [4] foo;
assume that the user means:
  int foo[4];

Update the information for 'foo' to prevent additional errors, and provide
a fix-it hint to move the brackets to the correct location.

Additionally, suggest parens for types that require it, such as:
  int [4] *foo;
to:
  int (*foo)[4];

Added:
cfe/trunk/test/Parser/brackets.c
cfe/trunk/test/Parser/brackets.cpp
Modified:
cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
cfe/trunk/include/clang/Parse/Parser.h
cfe/trunk/lib/Parse/ParseDecl.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td?rev=211641&r1=211640&r2=211641&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td Tue Jun 24 18:14:24 
2014
@@ -448,6 +448,8 @@ def err_invalid_operator_on_type : Error
   "cannot use %select{dot|arrow}0 operator on a type">;
 def err_expected_unqualified_id : Error<
   "expected %select{identifier|unqualified-id}0">;
+def err_brackets_go_after_unqualified_id : Error<
+  "brackets go after the %select{identifier|unqualified-id}0">;
 def err_unexpected_unqualified_id : Error<"type-id cannot have a name">;
 def err_func_def_no_params : Error<
   "function definition does not declare parameters">;

Modified: cfe/trunk/include/clang/Parse/Parser.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Parse/Parser.h?rev=211641&r1=211640&r2=211641&view=diff
==
--- cfe/trunk/include/clang/Parse/Parser.h (original)
+++ cfe/trunk/include/clang/Parse/Parser.h Tue Jun 24 18:14:24 2014
@@ -2214,6 +2214,7 @@ private:
  SmallVectorImpl &ParamInfo,
  SourceLocation &EllipsisLoc);
   void ParseBracketDeclarator(Declarator &D);
+  void ParseMisplacedBracketDeclarator(Declarator &D);
 
   
//======//
   // C++ 7: Declarations [dcl.dcl]

Modified: cfe/trunk/lib/Parse/ParseDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseDecl.cpp?rev=211641&r1=211640&r2=211641&view=diff
==
--- cfe/trunk/lib/Parse/ParseDecl.cpp (original)
+++ cfe/trunk/lib/Parse/ParseDecl.cpp Tue Jun 24 18:14:24 2014
@@ -4664,6 +4664,19 @@ void Parser::ParseDeclaratorInternal(Dec
   }
 }
 
+// When correcting from misplaced brackets before the identifier, the location
+// is saved inside the declarator so that other diagnostic messages can use
+// them.  This extracts and returns that location, or returns the provided
+// location if a stored location does not exist.
+static SourceLocation getMissingDeclaratorIdLoc(Declarator &D,
+SourceLocation Loc) {
+  if (D.getName().StartLocation.isInvalid() &&
+  D.getName().EndLocation.isValid())
+return D.getName().EndLocation;
+
+  return Loc;
+}
+
 /// ParseDirectDeclarator
 ///   direct-declarator: [C99 6.7.5]
 /// [C99]   identifier
@@ -4841,11 +4854,14 @@ void Parser::ParseDirectDeclarator(Decla
   } else {
 if (Tok.getKind() == tok::annot_pragma_parser_crash)
   LLVM_BUILTIN_TRAP;
-if (D.getContext() == Declarator::MemberContext)
-  Diag(Tok, diag::err_expected_member_name_or_semi)
+if (Tok.is(tok::l_square))
+  return ParseMisplacedBracketDeclarator(D);
+if (D.getContext() == Declarator::MemberContext) {
+  Diag(getMissingDeclaratorIdLoc(D, Tok.getLocation()),
+   diag::err_expected_member_name_or_semi)
   << (D.getDeclSpec().isEmpty() ? SourceRange()
 : D.getDeclSpec().getSourceRange());
-else if (getLangOpts().CPlusPlus) {
+} else if (getLangOpts().CPlusPlus) {
   if (Tok.is(tok::period) || Tok.is(tok::arrow))
 Diag(Tok, diag::err_invalid_operator_on_type) << Tok.is(tok::arrow);
   else {
@@ -4854,11 +4870,15 @@ void Parser::ParseDirectDeclarator(Decla
   Diag(PP.getLocForEndOfToken(Loc), diag::err_expected_unqualified_id)
   << getLangOpts().CPlusPlus;
 else
-  Diag(Tok, diag::err_expected_unqualified_id)
+  Diag(getMissingDeclaratorIdLoc(D, Tok.getLocation()),
+   diag::err_expected_unqualified_id)
   << getLangOpts().CPlusPlus;
   }
-} else
-  Diag(Tok, diag::err_expected_either) << tok::identifier << tok::l_paren;
+} else {
+  Diag(getMissingDeclaratorIdLoc(D, Tok.getLocation()),
+   diag::err_expected_either)
+   

Re: [3/5 PATCH/RFC PPC64] add power8 target for clang

[Hal Finkel]

LGTM. Please combine this with patch 4 (and the tests in patch 5).

 -Hal

- Original Message -
> From: "Will Schmidt" 
> To: "LLVM Developers Mailing List" , "clang-dev 
> Developers" 
> Cc: "Will Schmidt" , "Ulrich Weigand" 
> , "Hal Finkel"
> , "William J. Schmidt" 
> Sent: Tuesday, June 24, 2014 4:43:46 PM
> Subject: [3/5 PATCH/RFC PPC64] add power8 target for clang
> 
> Add power8 target to clang
> 
> 
> diff --git a/tools/clang/lib/Basic/Targets.cpp
> b/tools/clang/lib/Basic/Targets.cpp
> index 4fdbc24..d54e8bd 100644
> --- a/tools/clang/lib/Basic/Targets.cpp
> +++ b/tools/clang/lib/Basic/Targets.cpp
> @@ -706,8 +706,9 @@ public:
>  ArchDefinePwr6  = 1 << 9,
>  ArchDefinePwr6x = 1 << 10,
>  ArchDefinePwr7  = 1 << 11,
> -ArchDefineA2= 1 << 12,
> -ArchDefineA2q   = 1 << 13
> +ArchDefinePwr8  = 1 << 12,
> +ArchDefineA2= 1 << 13,
> +ArchDefineA2q   = 1 << 14
>} ArchDefineTypes;
>  
>// Note: GCC recognizes the following additional cpus:
> @@ -754,6 +755,8 @@ public:
>.Case("pwr6x", true)
>.Case("power7", true)
>.Case("pwr7", true)
> +  .Case("power8", true)
> +  .Case("pwr8", true)
>.Case("powerpc", true)
>.Case("ppc", true)
>.Case("powerpc64", true)
> @@ -1016,7 +1019,10 @@ void PPCTargetInfo::getTargetDefines(const
> LangOptions &Opts,
>   | ArchDefinePpcsq)
>  .Case("pwr7",  ArchDefineName | ArchDefinePwr6x | ArchDefinePwr6
>   | ArchDefinePwr5x | ArchDefinePwr5 |
>   | ArchDefinePwr4
> - | ArchDefinePwr6 | ArchDefinePpcgr |
> ArchDefinePpcsq)
> + | ArchDefinePpcgr | ArchDefinePpcsq)
> +.Case("pwr8",  ArchDefineName | ArchDefinePwr7 | ArchDefinePwr6x
> + | ArchDefinePwr6 | ArchDefinePwr5x |
> ArchDefinePwr5
> + | ArchDefinePwr4 | ArchDefinePpcgr |
> ArchDefinePpcsq)
>  .Case("power3",  ArchDefinePpcgr)
>  .Case("power4",  ArchDefinePwr4 | ArchDefinePpcgr |
>  ArchDefinePpcsq)
>  .Case("power5",  ArchDefinePwr5 | ArchDefinePwr4 |
>  ArchDefinePpcgr
> @@ -1030,7 +1036,10 @@ void PPCTargetInfo::getTargetDefines(const
> LangOptions &Opts,
> | ArchDefinePpcsq)
>  .Case("power7",  ArchDefinePwr7 | ArchDefinePwr6x |
>  ArchDefinePwr6
> | ArchDefinePwr5x | ArchDefinePwr5 |
> | ArchDefinePwr4
> -   | ArchDefinePwr6 | ArchDefinePpcgr |
> ArchDefinePpcsq)
> +   | ArchDefinePpcgr | ArchDefinePpcsq)
> +.Case("power8",  ArchDefinePwr8 | ArchDefinePwr7 |
> ArchDefinePwr6x
> +   | ArchDefinePwr6 | ArchDefinePwr5x |
> ArchDefinePwr5
> +   | ArchDefinePwr4 | ArchDefinePpcgr |
> ArchDefinePpcsq)
>  .Default(ArchDefineNone);
>  
>if (defs & ArchDefineName)
> @@ -1057,6 +1066,8 @@ void PPCTargetInfo::getTargetDefines(const
> LangOptions &Opts,
>  Builder.defineMacro("_ARCH_PWR6X");
>if (defs & ArchDefinePwr7)
>  Builder.defineMacro("_ARCH_PWR7");
> +  if (defs & ArchDefinePwr8)
> +Builder.defineMacro("_ARCH_PWR8");
>if (defs & ArchDefineA2)
>  Builder.defineMacro("_ARCH_A2");
>if (defs & ArchDefineA2q) {
> @@ -1105,6 +1116,7 @@ void
> PPCTargetInfo::getDefaultFeatures(llvm::StringMap &Features)
> const {
>  .Case("g5", true)
>  .Case("pwr6", true)
>  .Case("pwr7", true)
> +.Case("pwr8", true)
>  .Case("ppc64", true)
>  .Case("ppc64le", true)
>  .Default(false);
> 
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [5/5 PATCH/RFC PPC64] tests for power8 keyword

[Hal Finkel]

Will,

LGTM. If no further changes are needed to support powerpc64le, please also add 
tests for the LE triples too.

 -Hal

- Original Message -
> From: "Will Schmidt" 
> To: "LLVM Developers Mailing List" , "clang-dev 
> Developers" 
> Cc: "Will Schmidt" , "Ulrich Weigand" 
> , "Hal Finkel"
> , "William J. Schmidt" 
> Sent: Tuesday, June 24, 2014 4:44:22 PM
> Subject: [5/5 PATCH/RFC PPC64] tests for power8 keyword
> 
> Assorted tests for the power8/pwr8 keyword.
> 
> diff --git a/tools/clang/test/Driver/clang-translation.c
> b/tools/clang/test/Driver/clang-translation.c
> index 54e5bbe..a525b7f 100644
> --- a/tools/clang/test/Driver/clang-translation.c
> +++ b/tools/clang/test/Driver/clang-translation.c
> @@ -71,6 +71,12 @@
>  // PPCPWR7: "-target-cpu" "pwr7"
>  
>  // RUN: %clang -target powerpc64-unknown-linux-gnu \
> +// RUN: -### -S %s -mcpu=power8 2>&1 | FileCheck
> -check-prefix=PPCPWR8 %s
> +// PPCPWR8: clang
> +// PPCPWR8: "-cc1"
> +// PPCPWR8: "-target-cpu" "pwr8"
> +
> +// RUN: %clang -target powerpc64-unknown-linux-gnu \
>  // RUN: -### -S %s -mcpu=a2q 2>&1 | FileCheck -check-prefix=PPCA2Q
>  %s
>  // PPCA2Q: clang
>  // PPCA2Q: "-cc1"
> diff --git a/tools/clang/test/Driver/ppc-features.cpp
> b/tools/clang/test/Driver/ppc-features.cpp
> index a7ccedf..fa9a7ec 100644
> --- a/tools/clang/test/Driver/ppc-features.cpp
> +++ b/tools/clang/test/Driver/ppc-features.cpp
> @@ -59,9 +59,12 @@
>  // RUN: %clang -target powerpc64-unknown-linux-gnu %s -fno-altivec
>  -mcpu=pwr7 -### -o %t.o 2>&1 | FileCheck --check-prefix=CHECK-14 %s
>  // CHECK-14: "-target-feature" "-altivec"
>  
> -// RUN: %clang -target powerpc64-unknown-linux-gnu %s -fno-altivec
> -mcpu=ppc64 -### -o %t.o 2>&1 | FileCheck --check-prefix=CHECK-15 %s
> +// RUN: %clang -target powerpc64-unknown-linux-gnu %s -fno-altivec
> -mcpu=pwr8 -### -o %t.o 2>&1 | FileCheck --check-prefix=CHECK-15 %s
>  // CHECK-15: "-target-feature" "-altivec"
>  
> +// RUN: %clang -target powerpc64-unknown-linux-gnu %s -fno-altivec
> -mcpu=ppc64 -### -o %t.o 2>&1 | FileCheck --check-prefix=CHECK-16 %s
> +// CHECK-16: "-target-feature" "-altivec"
> +
>  // RUN: %clang -target powerpc64-unknown-linux-gnu %s -mno-qpx -###
>  -o %t.o 2>&1 | FileCheck -check-prefix=CHECK-NOQPX %s
>  // CHECK-NOQPX: "-target-feature" "-qpx"
>  
> diff --git a/tools/clang/test/Preprocessor/init.c
> b/tools/clang/test/Preprocessor/init.c
> index ed08854..2db4183 100644
> --- a/tools/clang/test/Preprocessor/init.c
> +++ b/tools/clang/test/Preprocessor/init.c
> @@ -2835,6 +2835,34 @@
>  // PPCPOWER7:#define _ARCH_PWR6X 1
>  // PPCPOWER7:#define _ARCH_PWR7 1
>  //
> +// RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64-none-none
> -target-cpu pwr8 -fno-signed-char < /dev/null | FileCheck
> -check-prefix PPCPWR8 %s
> +//
> +// PPCPWR8:#define _ARCH_PPC 1
> +// PPCPWR8:#define _ARCH_PPC64 1
> +// PPCPWR8:#define _ARCH_PPCGR 1
> +// PPCPWR8:#define _ARCH_PPCSQ 1
> +// PPCPWR8:#define _ARCH_PWR4 1
> +// PPCPWR8:#define _ARCH_PWR5 1
> +// PPCPWR8:#define _ARCH_PWR5X 1
> +// PPCPWR8:#define _ARCH_PWR6 1
> +// PPCPWR8:#define _ARCH_PWR6X 1
> +// PPCPWR8:#define _ARCH_PWR7 1
> +// PPCPWR8:#define _ARCH_PWR8 1
> +//
> +// RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64-none-none
> -target-cpu power8 -fno-signed-char < /dev/null | FileCheck
> -check-prefix PPCPOWER8 %s
> +//
> +// PPCPOWER8:#define _ARCH_PPC 1
> +// PPCPOWER8:#define _ARCH_PPC64 1
> +// PPCPOWER8:#define _ARCH_PPCGR 1
> +// PPCPOWER8:#define _ARCH_PPCSQ 1
> +// PPCPOWER8:#define _ARCH_PWR4 1
> +// PPCPOWER8:#define _ARCH_PWR5 1
> +// PPCPOWER8:#define _ARCH_PWR5X 1
> +// PPCPOWER8:#define _ARCH_PWR6 1
> +// PPCPOWER8:#define _ARCH_PWR6X 1
> +// PPCPOWER8:#define _ARCH_PWR7 1
> +// PPCPOWER8:#define _ARCH_PWR8 1
> +//
>  // RUN: %clang_cc1 -E -dM -ffreestanding
>  -triple=powerpc64-unknown-linux-gnu -fno-signed-char < /dev/null |
>  FileCheck -check-prefix PPC64-LINUX %s
>  //
>  // PPC64-LINUX:#define _ARCH_PPC 1
> 
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [4/5 PATCH/RFC PPC64] add power8 keyword for clang/tools

[Hal Finkel]

Will,

Please combine this with patch 3 (and the tests in patch 5). LGTM.

 -Hal

- Original Message -
> From: "Will Schmidt" 
> To: "clang-dev Developers" , "LLVM Developers Mailing 
> List" 
> Cc: "Will Schmidt" , "Hal Finkel" , 
> "Ulrich Weigand"
> , "William J. Schmidt" 
> 
> Sent: Tuesday, June 24, 2014 4:44:10 PM
> Subject: [4/5 PATCH/RFC PPC64] add power8 keyword for clang/tools
> 
> Add power8/pwr8 to clang/tools
> 
> 
> diff --git a/tools/clang/lib/Driver/Tools.cpp
> b/tools/clang/lib/Driver/Tools.cpp
> index de03ce6..d353069 100644
> --- a/tools/clang/lib/Driver/Tools.cpp
> +++ b/tools/clang/lib/Driver/Tools.cpp
> @@ -1156,6 +1156,7 @@ static std::string getPPCTargetCPU(const
> ArgList
> &Args) {
>.Case("power6", "pwr6")
>.Case("power6x", "pwr6x")
>.Case("power7", "pwr7")
> +  .Case("power8", "pwr8")
>.Case("pwr3", "pwr3")
>.Case("pwr4", "pwr4")
>.Case("pwr5", "pwr5")
> @@ -1163,6 +1164,7 @@ static std::string getPPCTargetCPU(const
> ArgList
> &Args) {
>.Case("pwr6", "pwr6")
>.Case("pwr6x", "pwr6x")
>.Case("pwr7", "pwr7")
> +  .Case("pwr8", "pwr8")
>.Case("powerpc", "ppc")
>.Case("powerpc64", "ppc64")
>.Case("powerpc64le", "ppc64le")
> 
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Don't eagerly evaluate the TypeSourceInfo when mangling names.

[David Majnemer]

LGTM

http://reviews.llvm.org/D4281



___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

[PATCH] Don't eagerly evaluate the TypeSourceInfo when mangling names.

[Zachary Turner]

Hi rnk, majnemer,

Don't eagerly evaluate the TypeSourceInfo while mangling.

A VarDecl may not have TypeSourceInfo, for example if source is
generated in-memory by another application.  This patch changes
the mangler to use a default instance if the TypeSourceInfo
doesn't exist.

http://reviews.llvm.org/D4281

Files:
  lib/AST/MicrosoftMangle.cpp

Index: lib/AST/MicrosoftMangle.cpp
===
--- lib/AST/MicrosoftMangle.cpp
+++ lib/AST/MicrosoftMangle.cpp
@@ -418,11 +418,13 @@
   // ::=   # pointers, references
   // Pointers and references are odd. The type of 'int * const foo;' gets
   // mangled as 'QAHA' instead of 'PAHB', for example.
-  TypeLoc TL = VD->getTypeSourceInfo()->getTypeLoc();
+  SourceRange SR;
+  if (TypeSourceInfo *TI = VD->getTypeSourceInfo())
+SR = TI->getTypeLoc().getSourceRange();
   QualType Ty = VD->getType();
   if (Ty->isPointerType() || Ty->isReferenceType() ||
   Ty->isMemberPointerType()) {
-mangleType(Ty, TL.getSourceRange(), QMM_Drop);
+mangleType(Ty, SR, QMM_Drop);
 manglePointerExtQualifiers(
 Ty.getDesugaredType(getASTContext()).getLocalQualifiers(), nullptr);
 if (const MemberPointerType *MPT = Ty->getAs()) {
@@ -440,7 +442,7 @@
 else
   mangleQualifiers(Ty.getQualifiers(), false);
   } else {
-mangleType(Ty, TL.getSourceRange(), QMM_Drop);
+mangleType(Ty, SR, QMM_Drop);
 mangleQualifiers(Ty.getLocalQualifiers(), false);
   }
 }
Index: lib/AST/MicrosoftMangle.cpp
===
--- lib/AST/MicrosoftMangle.cpp
+++ lib/AST/MicrosoftMangle.cpp
@@ -418,11 +418,13 @@
   // ::=   # pointers, references
   // Pointers and references are odd. The type of 'int * const foo;' gets
   // mangled as 'QAHA' instead of 'PAHB', for example.
-  TypeLoc TL = VD->getTypeSourceInfo()->getTypeLoc();
+  SourceRange SR;
+  if (TypeSourceInfo *TI = VD->getTypeSourceInfo())
+SR = TI->getTypeLoc().getSourceRange();
   QualType Ty = VD->getType();
   if (Ty->isPointerType() || Ty->isReferenceType() ||
   Ty->isMemberPointerType()) {
-mangleType(Ty, TL.getSourceRange(), QMM_Drop);
+mangleType(Ty, SR, QMM_Drop);
 manglePointerExtQualifiers(
 Ty.getDesugaredType(getASTContext()).getLocalQualifiers(), nullptr);
 if (const MemberPointerType *MPT = Ty->getAs()) {
@@ -440,7 +442,7 @@
 else
   mangleQualifiers(Ty.getQualifiers(), false);
   } else {
-mangleType(Ty, TL.getSourceRange(), QMM_Drop);
+mangleType(Ty, SR, QMM_Drop);
 mangleQualifiers(Ty.getLocalQualifiers(), false);
   }
 }
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] MS ABI: Propagate class-level DLL attributes to class template specialization bases (PR11170)

[Hans Wennborg]

New patch that takes explicit specializations and instantiations into account.

http://reviews.llvm.org/D4264

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/Sema/SemaDeclCXX.cpp
  test/CodeGenCXX/dllexport.cpp
  test/CodeGenCXX/dllimport.cpp
  test/SemaCXX/dllexport.cpp
  test/SemaCXX/dllimport.cpp
Index: include/clang/Basic/DiagnosticSemaKinds.td
===
--- include/clang/Basic/DiagnosticSemaKinds.td
+++ include/clang/Basic/DiagnosticSemaKinds.td
@@ -2130,6 +2130,11 @@
   InGroup>;
 def err_attribute_dll_member_of_dll_class : Error<
   "attribute %q0 cannot be applied to member of %q1 class">;
+def warn_attribute_dll_instantiated_base_class : Warning<
+  "propagating dll attribute to %select{already instantiated|explicitly specialized}0 "
+  "base class template "
+  "%select{without dll attribute|with different dll attribute}1 is unsupported">,
+  InGroup>;
 def err_attribute_weakref_not_static : Error<
   "weakref declaration must have internal linkage">;
 def err_attribute_weakref_not_global_context : Error<
@@ -3405,6 +3410,10 @@
   "%select{implicit|explicit}0 instantiation of undefined template %1">;
 def err_implicit_instantiate_member_undefined : Error<
   "implicit instantiation of undefined member %0">;
+def note_template_class_instantiation_was_here : Note<
+  "class template %0 was instantiated here">;
+def note_template_class_explicit_specialization_was_here : Note<
+  "class template %0 was explicitly specialized here">;
 def note_template_class_instantiation_here : Note<
   "in instantiation of template class %0 requested here">;
 def note_template_member_class_here : Note<
Index: lib/Sema/SemaDeclCXX.cpp
===
--- lib/Sema/SemaDeclCXX.cpp
+++ lib/Sema/SemaDeclCXX.cpp
@@ -1296,6 +1296,56 @@
   return false;
 }
 
+/// \brief Perform propagation of DLL attributes from a derived class to a
+/// templated base class for MS compatibility.
+static void propagateDLLAttrToBaseClassTemplate(
+Sema &S, CXXRecordDecl *Class, Attr *ClassAttr,
+ClassTemplateSpecializationDecl *BaseTemplateSpec, SourceLocation BaseLoc) {
+  if (getDLLAttr(
+  BaseTemplateSpec->getSpecializedTemplate()->getTemplatedDecl())) {
+// If the base class template has a DLL attribute, don't try to change it.
+return;
+  }
+
+  if (BaseTemplateSpec->getSpecializationKind() != TSK_Undeclared) {
+bool DifferentAttribute = false;
+if (Attr *SpecializationAttr = getDLLAttr(BaseTemplateSpec)) {
+  if (!SpecializationAttr->isInherited()) {
+// The template has previously been specialized or instantiated with an
+// explicit attribute. Don't try to change it.
+return;
+  }
+
+  if (SpecializationAttr->getKind() == ClassAttr->getKind()) {
+// The specialization already has the right attribute.
+return;
+  }
+  DifferentAttribute = true;
+}
+
+// The template was previously instantiated or explicitly specialized
+// without, or with the wrong kind of, dll attribute. It's too late for us
+// to change the attribute, so warn that this is unsupported.
+S.Diag(BaseLoc, diag::warn_attribute_dll_instantiated_base_class)
+<< BaseTemplateSpec->isExplicitSpecialization() << DifferentAttribute;
+S.Diag(ClassAttr->getLocation(), diag::note_attribute);
+if (BaseTemplateSpec->isExplicitSpecialization()) {
+  S.Diag(BaseTemplateSpec->getLocation(),
+ diag::note_template_class_explicit_specialization_was_here)
+  << BaseTemplateSpec;
+} else {
+  S.Diag(BaseTemplateSpec->getPointOfInstantiation(),
+ diag::note_template_class_instantiation_was_here)
+  << BaseTemplateSpec;
+}
+return;
+  }
+
+  auto *NewAttr = cast(ClassAttr->clone(S.getASTContext()));
+  NewAttr->setInherited(true);
+  BaseTemplateSpec->addAttr(NewAttr);
+}
+
 /// \brief Check the validity of a C++ base class specifier.
 ///
 /// \returns a new CXXBaseSpecifier if well-formed, emits diagnostics
@@ -1362,6 +1412,17 @@
 return nullptr;
   }
 
+  // For the MS ABI, propagate DLL attributes to base class templates.
+  if (Context.getTargetInfo().getCXXABI().isMicrosoft()) {
+if (Attr *ClassAttr = getDLLAttr(Class)) {
+  if (auto *BaseTemplate = dyn_cast_or_null(
+  BaseType->getAsCXXRecordDecl())) {
+propagateDLLAttrToBaseClassTemplate(*this, Class, ClassAttr,
+BaseTemplate, BaseLoc);
+  }
+}
+  }
+
   // C++ [class.derived]p2:
   //   The class-name in a base-specifier shall not be an incompletely
   //   defined class.
@@ -4361,9 +4422,6 @@
   // FIXME: MSVC's docs say all bases must be exportable, but this doesn't
   // seem to be true in practice?
 
-  // FIXME: We also need to propagate the attribute upwards to class template
-  // specialization bases.
-
   for (Decl *Member : Class->dec

Re: [PATCH] libcxxabi/unwind: Add support for ARM EHABI in AddressSpace.hpp

[Nico Weber]

On Tue, Jun 24, 2014 at 3:19 PM, Nico Weber  wrote:

> On Tue, Jun 24, 2014 at 2:18 PM, Nick Kledzik  wrote:
>
>> Nico,
>>
>> This looks good now.
>>
>
> Cool, thanks! What does this mean in practice?
>
> a) Check in Dana's patch on this thread, post next patch, wait for review
> b) Check in everything we have, in logical chunks, and use post-commit
> review where necessary?
>

(With "everything" meaning "everything in libcxxabi/src and
libcxxabi/include")


>
> Thanks,
> Nico
>
>
>>
>> -Nick
>>
>> On Jun 22, 2014, at 2:02 PM, Nico Weber  wrote:
>>
>> On Mon, Jun 16, 2014 at 1:15 PM, Nick Kledzik  wrote:
>>
>>>
>>> On Jun 16, 2014, at 10:05 AM, Nico Weber  wrote:
>>>
>>> Nick, do you want us to put EHABI in a separate file before upstreaming,
>>>
>>> Yes.   It should be easy to de-conditionalize your current changes to
>>> UnwindLevel1.c and merge it with your Unwind-arm.c to make the new
>>> EHABI-only file.
>>>
>>
>> Please take another look:
>>
>> https://github.com/awong-dev/ndk/compare/upstream-llvm-ndkpatched...master#files_bucket
>>
>> I renamed Unwind-arm.cpp to Unwind-EHABI.cpp, and moved all new code from
>> UnwindLevel1.c to there instead. I also reformatted the 80col lines. The
>> file still calls the unw_ functions, let me know if you want us to move off
>> those before upstreaming.
>>
>> > * In general, the conditionals should consider the possibility of three
>> unwinders for arm: SJLJ, EHABI, and (someday maybe) Itanium.   For
>> instance, the new functions in UnwindRegisters{Save|Restore}.S should be
>> conditionalized with some EHABI conditional (not just __arm__ && !__APPLE),
>> and in Registers.hpp, all the new EHABI specific stuff in Registers_arm
>> should be conditionalized with ARM_EHABI.
>>
>> Registers.hpp is currently free of preprocessor defines and relies on the
>> linker throwing out unused functions, so I didn't do this. Are you worried
>> about jumpTo() having different behavior? Right now, Registers_arm is only
>> used for EHABI unwinding, so it seems waiting with these ifdefs until
>> someone wants to add itanium unwinding for arm might be ok?
>>
>> Thanks,
>> Nico
>>
>> (ps: Please ignore the first change in UnwindRegistersSave.S, I think
>> that's some merge bug. https://github.com/awong-dev/ndk/pull/152 fixes
>> it.)
>>
>>
>>
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] libcxxabi/unwind: Add support for ARM EHABI in AddressSpace.hpp

[Nico Weber]

On Tue, Jun 24, 2014 at 2:18 PM, Nick Kledzik  wrote:

> Nico,
>
> This looks good now.
>

Cool, thanks! What does this mean in practice?

a) Check in Dana's patch on this thread, post next patch, wait for review
b) Check in everything we have, in logical chunks, and use post-commit
review where necessary?

Thanks,
Nico


>
> -Nick
>
> On Jun 22, 2014, at 2:02 PM, Nico Weber  wrote:
>
> On Mon, Jun 16, 2014 at 1:15 PM, Nick Kledzik  wrote:
>
>>
>> On Jun 16, 2014, at 10:05 AM, Nico Weber  wrote:
>>
>> Nick, do you want us to put EHABI in a separate file before upstreaming,
>>
>> Yes.   It should be easy to de-conditionalize your current changes to
>> UnwindLevel1.c and merge it with your Unwind-arm.c to make the new
>> EHABI-only file.
>>
>
> Please take another look:
>
> https://github.com/awong-dev/ndk/compare/upstream-llvm-ndkpatched...master#files_bucket
>
> I renamed Unwind-arm.cpp to Unwind-EHABI.cpp, and moved all new code from
> UnwindLevel1.c to there instead. I also reformatted the 80col lines. The
> file still calls the unw_ functions, let me know if you want us to move off
> those before upstreaming.
>
> > * In general, the conditionals should consider the possibility of three
> unwinders for arm: SJLJ, EHABI, and (someday maybe) Itanium.   For
> instance, the new functions in UnwindRegisters{Save|Restore}.S should be
> conditionalized with some EHABI conditional (not just __arm__ && !__APPLE),
> and in Registers.hpp, all the new EHABI specific stuff in Registers_arm
> should be conditionalized with ARM_EHABI.
>
> Registers.hpp is currently free of preprocessor defines and relies on the
> linker throwing out unused functions, so I didn't do this. Are you worried
> about jumpTo() having different behavior? Right now, Registers_arm is only
> used for EHABI unwinding, so it seems waiting with these ifdefs until
> someone wants to add itanium unwinding for arm might be ok?
>
> Thanks,
> Nico
>
> (ps: Please ignore the first change in UnwindRegistersSave.S, I think
> that's some merge bug. https://github.com/awong-dev/ndk/pull/152 fixes
> it.)
>
>
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

[PATCH] Fix for PR20110: Don't assume that the subexpression of a bit cast has pointer type if the bit cast has pointer type

[Richard Trieu]

When a bit cast expression has pointer type, don't assume that the 
subexpression also has pointer type.  It is possible that the subexpression is 
a value type instead.  This patch checks the type of the subexpression and 
calls the proper function.  Prevents the assertion failure reported in PR20110.

http://llvm.org/bugs/show_bug.cgi?id=20110

http://reviews.llvm.org/D4280

Files:
  lib/Sema/SemaChecking.cpp
  test/SemaCXX/PR20110.cpp

Index: test/SemaCXX/PR20110.cpp
===
--- test/SemaCXX/PR20110.cpp
+++ test/SemaCXX/PR20110.cpp
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 %s
+// expected-no-diagnostics
+
+template 
+class A {
+  char const *get_p() { return *p; }
+};
+template 
+class B {
+  char const *get_p() { return p; }
+};
+
Index: lib/Sema/SemaChecking.cpp
===
--- lib/Sema/SemaChecking.cpp
+++ lib/Sema/SemaChecking.cpp
@@ -4592,7 +4592,6 @@
   case Stmt::CXXReinterpretCastExprClass: {
 Expr* SubExpr = cast(E)->getSubExpr();
 switch (cast(E)->getCastKind()) {
-case CK_BitCast:
 case CK_LValueToRValue:
 case CK_NoOp:
 case CK_BaseToDerived:
@@ -4607,6 +4606,14 @@
 case CK_ArrayToPointerDecay:
   return EvalVal(SubExpr, refVars, ParentDecl);
 
+case CK_BitCast:
+  if (SubExpr->getType()->isAnyPointerType() ||
+  SubExpr->getType()->isBlockPointerType() ||
+  SubExpr->getType()->isObjCQualifiedIdType())
+return EvalAddr(SubExpr, refVars, ParentDecl);
+  else
+return EvalVal(SubExpr, refVars, ParentDecl);
+
 default:
   return nullptr;
 }
Index: test/SemaCXX/PR20110.cpp
===
--- test/SemaCXX/PR20110.cpp
+++ test/SemaCXX/PR20110.cpp
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 %s
+// expected-no-diagnostics
+
+template 
+class A {
+  char const *get_p() { return *p; }
+};
+template 
+class B {
+  char const *get_p() { return p; }
+};
+
Index: lib/Sema/SemaChecking.cpp
===
--- lib/Sema/SemaChecking.cpp
+++ lib/Sema/SemaChecking.cpp
@@ -4592,7 +4592,6 @@
   case Stmt::CXXReinterpretCastExprClass: {
 Expr* SubExpr = cast(E)->getSubExpr();
 switch (cast(E)->getCastKind()) {
-case CK_BitCast:
 case CK_LValueToRValue:
 case CK_NoOp:
 case CK_BaseToDerived:
@@ -4607,6 +4606,14 @@
 case CK_ArrayToPointerDecay:
   return EvalVal(SubExpr, refVars, ParentDecl);
 
+case CK_BitCast:
+  if (SubExpr->getType()->isAnyPointerType() ||
+  SubExpr->getType()->isBlockPointerType() ||
+  SubExpr->getType()->isObjCQualifiedIdType())
+return EvalAddr(SubExpr, refVars, ParentDecl);
+  else
+return EvalVal(SubExpr, refVars, ParentDecl);
+
 default:
   return nullptr;
 }
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: Enable std::underlying_type for gcc >= 4.7

[王重傑]

another ping. :)

Please let me know if there's some other way I should be requesting a
review...

Thanks,
Albert


On Mon, Jun 16, 2014 at 1:08 PM, Albert J. Wong (王重傑) 
wrote:

> gentle ping!
>
>
> On Thu, Jun 12, 2014 at 1:50 PM, Albert J. Wong (王重傑)  > wrote:
>
>> Hi Marshall,
>>
>> gcc 4.7 added enough frontend support to implement most (not all) of
>> type_traits. Here's a patch that enables std::underlying_type.
>>
>> FYI, this is a first in a series of ~3 that will allow most libc++ tests
>> for type_traits and atomics to pass on gcc >= 4.7.  Will send those out as
>> I manage to get them fully cleaned up.
>>
>> Thanks,
>> Albert
>>
>
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] libcxxabi/unwind: Add support for ARM EHABI in AddressSpace.hpp

[Nick Kledzik]

Nico,

This looks good now.  

-Nick

On Jun 22, 2014, at 2:02 PM, Nico Weber  wrote:
> On Mon, Jun 16, 2014 at 1:15 PM, Nick Kledzik  wrote:
> 
> On Jun 16, 2014, at 10:05 AM, Nico Weber  wrote:
> 
>> Nick, do you want us to put EHABI in a separate file before upstreaming,
> 
> Yes.   It should be easy to de-conditionalize your current changes to 
> UnwindLevel1.c and merge it with your Unwind-arm.c to make the new EHABI-only 
> file.
> 
> Please take another look:
> https://github.com/awong-dev/ndk/compare/upstream-llvm-ndkpatched...master#files_bucket
> 
> I renamed Unwind-arm.cpp to Unwind-EHABI.cpp, and moved all new code from 
> UnwindLevel1.c to there instead. I also reformatted the 80col lines. The file 
> still calls the unw_ functions, let me know if you want us to move off those 
> before upstreaming.
> 
> > * In general, the conditionals should consider the possibility of three 
> > unwinders for arm: SJLJ, EHABI, and (someday maybe) Itanium.   For 
> > instance, the new functions in UnwindRegisters{Save|Restore}.S should be 
> > conditionalized with some EHABI conditional (not just __arm__ && !__APPLE), 
> > and in Registers.hpp, all the new EHABI specific stuff in Registers_arm 
> > should be conditionalized with ARM_EHABI.
> 
> Registers.hpp is currently free of preprocessor defines and relies on the 
> linker throwing out unused functions, so I didn't do this. Are you worried 
> about jumpTo() having different behavior? Right now, Registers_arm is only 
> used for EHABI unwinding, so it seems waiting with these ifdefs until someone 
> wants to add itanium unwinding for arm might be ok?
> 
> Thanks,
> Nico
> 
> (ps: Please ignore the first change in UnwindRegistersSave.S, I think that's 
> some merge bug. https://github.com/awong-dev/ndk/pull/152 fixes it.)

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r211625 - Disable the bits of r211623 that broke the bots

[Eric Christopher]

On Tue, Jun 24, 2014 at 2:18 PM, Ben Langmuir  wrote:
>
>> On Jun 24, 2014, at 2:00 PM, Eric Christopher  wrote:
>>
>> On Tue, Jun 24, 2014 at 1:57 PM, Ben Langmuir  wrote:
>>>
 On Jun 24, 2014, at 1:51 PM, Eric Christopher  wrote:

 I missed that this is in a testcase and not in the main code. I'm
 definitely less worked up about it, but perhaps some more detail than
 just the FIXME would be nice :)
>>>
>>> Hey Eric,
>>>
>>> Fair enough, the comment sucks and you’re right this isn’t a great way to 
>>> deal with test failures in general. FWIW, I’m working on this right now and 
>>> I didn’t want to revert entirely, because I was hoping to get some 
>>> reassurance from the bots that the rest of the patch was ok.  It’s hard to 
>>> test filesystem-ish changes because of the potential for platform 
>>> differences :-)
>>>
>>
>> Yeah, you're absolutely right. I'd misread it and thought it was the
>> main code, but a testcase you just added that's parsing a bit weird on
>> a system you don't have I'm much less concerned about. Great that
>> you're looking at it right now, sometimes it's not clear if it's a
>> "now" versus "soon" thing. :)
>
> Should be fixed in r211633 (also fixed another test bug from this commit 
> hitting a few bots).
>

Awesome, thanks Ben, sorry for the noise.

-eric

> Ben
>
>>
>> Thanks!
>>
>> -eric
>>
>>> Cheers,
>>>
>>> Ben
>>>

 Thanks!

 -eric

 On Tue, Jun 24, 2014 at 1:39 PM, Eric Christopher  
 wrote:
> Please don't do this in this way, just go ahead and revert the whole
> patch and figure it out.
>
> -eric
>
> On Tue, Jun 24, 2014 at 1:00 PM, Ben Langmuir  wrote:
>> Author: benlangmuir
>> Date: Tue Jun 24 15:00:30 2014
>> New Revision: 211625
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=211625&view=rev
>> Log:
>> Disable the bits of r211623 that broke the bots
>>
>> Part of my test seems to rely on iterator bits that I didn't implement,
>> at least in the gcc bots. Disabling while I investigate.
>>
>> Modified:
>>   cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp
>>
>> Modified: cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp?rev=211625&r1=211624&r2=211625&view=diff
>> ==
>> --- cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp (original)
>> +++ cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp Tue Jun 24 
>> 15:00:30 2014
>> @@ -395,22 +395,23 @@ TEST(VirtualFileSystemTest, HiddenInIter
>>checkContents(O->dir_begin("/", EC), Contents);
>>  }
>>
>> +  // FIXME: broke gcc build
>>  // Make sure we get the top-most entry
>> -  vfs::directory_iterator E;
>> -  {
>> -auto I = std::find_if(O->dir_begin("/", EC), E, [](vfs::Status S){
>> -  return S.getName() == "/hiddenByUp";
>> -});
>> -ASSERT_NE(E, I);
>> -EXPECT_EQ(sys::fs::owner_all, I->getPermissions());
>> -  }
>> -  {
>> -auto I = std::find_if(O->dir_begin("/", EC), E, [](vfs::Status S){
>> -  return S.getName() == "/hiddenByMid";
>> -});
>> -ASSERT_NE(E, I);
>> -EXPECT_EQ(sys::fs::owner_write, I->getPermissions());
>> -  }
>> +  // vfs::directory_iterator E;
>> +  // {
>> +  //   auto I = std::find_if(O->dir_begin("/", EC), E, [](vfs::Status 
>> S){
>> +  // return S.getName() == "/hiddenByUp";
>> +  //   });
>> +  //   ASSERT_NE(E, I);
>> +  //   EXPECT_EQ(sys::fs::owner_all, I->getPermissions());
>> +  // }
>> +  // {
>> +  //   auto I = std::find_if(O->dir_begin("/", EC), E, [](vfs::Status 
>> S){
>> +  // return S.getName() == "/hiddenByMid";
>> +  //   });
>> +  //   ASSERT_NE(E, I);
>> +  //   EXPECT_EQ(sys::fs::owner_write, I->getPermissions());
>> +  // }
>> }
>>
>> // NOTE: in the tests below, we use '//root/' as our root directory, 
>> since it is
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>>
>

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Change loop unroll and vectorizer metadata prefix to 'llvm.loop.'

[Mark Heffernan]

The attached patch includes a note in ReleaseNotes.rst and code to
autoupgrade llvm.vectorizer.* metadata strings to
llvm.loop.vectorizer.* when reading assembly and bitcode.  PTAL.

Thanks!
Mark

On Tue, Jun 24, 2014 at 9:53 AM, Hal Finkel  wrote:
> - Original Message -
>> From: "Mark Heffernan" 
>> To: "Hal Finkel" 
>> Cc: llvm-comm...@cs.uiuc.edu, "cfe-commits" , 
>> "Pekka Jääskeläinen"
>> 
>> Sent: Tuesday, June 24, 2014 11:18:33 AM
>> Subject: Re: [PATCH] Change loop unroll and vectorizer metadata prefix to 
>> 'llvm.loop.'
>>
>> Thanks for the comments.  I'll add something to the release notes.
>>
>> On Tue, Jun 24, 2014 at 3:52 AM, Hal Finkel  wrote:
>> > Moreover, for metadata that was supported by the 3.4 release,
>> > autoupgrade support should be added. Please do this before you
>> > commit.
>>
>> By autoupgrade do you mean be permissive about what is accepted?
>>  That
>> is, accept llvm.vectorizer.* and llvm.loop.vectorizer.* but only emit
>> the llvm.loop form from the FE.  Or do you mean try to rename the
>> metadata as soon as it parsed?  I can see how to do the first case
>> (be
>> permissive) easily, but for the second (rename metadata) do you have
>> any suggestions for the best place to cut in (I'm fairly new to the
>> code base)?
>
> No, I mean the second. I believe that most of the current logic for this is 
> in lib/IR/AutoUpgrade.cpp
>
>  -Hal
>
>>
>> Thanks!
>> Mark
>>
>> >
>> >  -Hal
>> >
>> >>
>> >> On Tue, Jun 24, 2014 at 12:30 AM, Mark Heffernan
>> >> 
>> >> wrote:
>> >> > These patches rename the loop unrolling and loop vectorizer
>> >> > metadata
>> >> > such that they have a common 'llvm.loop.' prefix.  Metadata name
>> >> > changes:
>> >> >
>> >> > llvm.vectorizer.* => llvm.loop.vectorizer.*
>> >> > llvm.loopunroll.* => llvm.loop.unroll.*
>> >> >
>> >> > This was a suggestion from an earlier review
>> >> > (http://reviews.llvm.org/D4090) which added the loop unrolling
>> >> > metadata.  Two patches are attached.  One for front-end and one
>> >> > for
>> >> > optimizer.
>> >> >
>> >> > Mark
>> >>
>> >>
>> >>
>> >> --
>> >> --PJ
>> >> ___
>> >> cfe-commits mailing list
>> >> cfe-commits@cs.uiuc.edu
>> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>> >>
>> >
>> > --
>> > Hal Finkel
>> > Assistant Computational Scientist
>> > Leadership Computing Facility
>> > Argonne National Laboratory
>>
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
Index: docs/LangRef.rst
===
--- docs/LangRef.rst	(revision 211528)
+++ docs/LangRef.rst	(working copy)
@@ -2804,7 +2804,7 @@
 
 The loop identifier metadata can be used to specify additional per-loop
 metadata. Any operands after the first operand can be treated as user-defined
-metadata. For example the ``llvm.vectorizer.unroll`` metadata is understood
+metadata. For example the ``llvm.loop.vectorizer.unroll`` metadata is understood
 by the loop vectorizer to indicate how many times to unroll the loop:
 
 .. code-block:: llvm
@@ -2812,7 +2812,7 @@
   br i1 %exitcond, label %._crit_edge, label %.lr.ph, !llvm.loop !0
 ...
 !0 = metadata !{ metadata !0, metadata !1 }
-!1 = metadata !{ metadata !"llvm.vectorizer.unroll", i32 2 }
+!1 = metadata !{ metadata !"llvm.loop.vectorizer.unroll", i32 2 }
 
 '``llvm.mem``'
 ^^^
@@ -2897,36 +2897,36 @@
!1 = metadata !{ metadata !1 } ; an identifier for the inner loop
!2 = metadata !{ metadata !2 } ; an identifier for the outer loop
 
-'``llvm.vectorizer``'
-^
+'``llvm.loop.vectorizer``'
+^^
 
-Metadata prefixed with ``llvm.vectorizer`` is used to control per-loop
+Metadata prefixed with ``llvm.loop.vectorizer`` is used to control per-loop
 vectorization parameters such as vectorization factor and unroll factor.
 
-``llvm.vectorizer`` metadata should be used in conjunction with ``llvm.loop``
-loop identification metadata.
+``llvm.loop.vectorizer`` metadata should be used in conjunction with
+``llvm.loop`` loop identification metadata.
 
-'``llvm.vectorizer.unroll``' Metadata
-^
+'``llvm.loop.vectorizer.unroll``' Metadata
+^^
 
 This metadata instructs the loop vectorizer to unroll the specified
 loop exactly ``N`` times.
 
-The first operand is the string ``llvm.vectorizer.unroll`` and the second
+The first operand is the string ``llvm.loop.vectorizer.unroll`` and the second
 operand is an integer specifying the unroll factor. For example:
 
 .. code-block:: llvm
 
-   !0 = metadata !{ metadata !"llvm.vectorizer.unroll", i32 4 }
+   !0 = metadata !{ metadata !"llvm.loop.vectorizer.unroll", i32 4 }
 
-Note that setting ``llvm.vectorizer.unroll`` to 1 disables unrolling of the
-loop.
+Note that setting ``llvm.loop.vectorizer.unroll`` to 1 disables
+unrolling of

Re: r211625 - Disable the bits of r211623 that broke the bots

[Ben Langmuir]

> On Jun 24, 2014, at 2:00 PM, Eric Christopher  wrote:
> 
> On Tue, Jun 24, 2014 at 1:57 PM, Ben Langmuir  wrote:
>> 
>>> On Jun 24, 2014, at 1:51 PM, Eric Christopher  wrote:
>>> 
>>> I missed that this is in a testcase and not in the main code. I'm
>>> definitely less worked up about it, but perhaps some more detail than
>>> just the FIXME would be nice :)
>> 
>> Hey Eric,
>> 
>> Fair enough, the comment sucks and you’re right this isn’t a great way to 
>> deal with test failures in general. FWIW, I’m working on this right now and 
>> I didn’t want to revert entirely, because I was hoping to get some 
>> reassurance from the bots that the rest of the patch was ok.  It’s hard to 
>> test filesystem-ish changes because of the potential for platform 
>> differences :-)
>> 
> 
> Yeah, you're absolutely right. I'd misread it and thought it was the
> main code, but a testcase you just added that's parsing a bit weird on
> a system you don't have I'm much less concerned about. Great that
> you're looking at it right now, sometimes it's not clear if it's a
> "now" versus "soon" thing. :)

Should be fixed in r211633 (also fixed another test bug from this commit 
hitting a few bots).

Ben

> 
> Thanks!
> 
> -eric
> 
>> Cheers,
>> 
>> Ben
>> 
>>> 
>>> Thanks!
>>> 
>>> -eric
>>> 
>>> On Tue, Jun 24, 2014 at 1:39 PM, Eric Christopher  
>>> wrote:
 Please don't do this in this way, just go ahead and revert the whole
 patch and figure it out.
 
 -eric
 
 On Tue, Jun 24, 2014 at 1:00 PM, Ben Langmuir  wrote:
> Author: benlangmuir
> Date: Tue Jun 24 15:00:30 2014
> New Revision: 211625
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=211625&view=rev
> Log:
> Disable the bits of r211623 that broke the bots
> 
> Part of my test seems to rely on iterator bits that I didn't implement,
> at least in the gcc bots. Disabling while I investigate.
> 
> Modified:
>   cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp
> 
> Modified: cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp?rev=211625&r1=211624&r2=211625&view=diff
> ==
> --- cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp (original)
> +++ cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp Tue Jun 24 
> 15:00:30 2014
> @@ -395,22 +395,23 @@ TEST(VirtualFileSystemTest, HiddenInIter
>checkContents(O->dir_begin("/", EC), Contents);
>  }
> 
> +  // FIXME: broke gcc build
>  // Make sure we get the top-most entry
> -  vfs::directory_iterator E;
> -  {
> -auto I = std::find_if(O->dir_begin("/", EC), E, [](vfs::Status S){
> -  return S.getName() == "/hiddenByUp";
> -});
> -ASSERT_NE(E, I);
> -EXPECT_EQ(sys::fs::owner_all, I->getPermissions());
> -  }
> -  {
> -auto I = std::find_if(O->dir_begin("/", EC), E, [](vfs::Status S){
> -  return S.getName() == "/hiddenByMid";
> -});
> -ASSERT_NE(E, I);
> -EXPECT_EQ(sys::fs::owner_write, I->getPermissions());
> -  }
> +  // vfs::directory_iterator E;
> +  // {
> +  //   auto I = std::find_if(O->dir_begin("/", EC), E, [](vfs::Status S){
> +  // return S.getName() == "/hiddenByUp";
> +  //   });
> +  //   ASSERT_NE(E, I);
> +  //   EXPECT_EQ(sys::fs::owner_all, I->getPermissions());
> +  // }
> +  // {
> +  //   auto I = std::find_if(O->dir_begin("/", EC), E, [](vfs::Status S){
> +  // return S.getName() == "/hiddenByMid";
> +  //   });
> +  //   ASSERT_NE(E, I);
> +  //   EXPECT_EQ(sys::fs::owner_write, I->getPermissions());
> +  // }
> }
> 
> // NOTE: in the tests below, we use '//root/' as our root directory, 
> since it is
> 
> 
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>> 


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r211633 - Fix test issues from r211623 and remove test-only API

[Ben Langmuir]

Author: benlangmuir
Date: Tue Jun 24 16:08:13 2014
New Revision: 211633

URL: http://llvm.org/viewvc/llvm-project?rev=211633&view=rev
Log:
Fix test issues from r211623 and remove test-only API

1) missing iterator bits needed by libstdc++4.7
Using find_if was convenient, but since operator++ wasn't a good
interface anyway, I just replaced with a range-based for loop and
removed operator++ from the directory_iterator class.

2) stop relying on order of iterating real files

Modified:
cfe/trunk/include/clang/Basic/VirtualFileSystem.h
cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp

Modified: cfe/trunk/include/clang/Basic/VirtualFileSystem.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/VirtualFileSystem.h?rev=211633&r1=211632&r2=211633&view=diff
==
--- cfe/trunk/include/clang/Basic/VirtualFileSystem.h (original)
+++ cfe/trunk/include/clang/Basic/VirtualFileSystem.h Tue Jun 24 16:08:13 2014
@@ -147,15 +147,6 @@ public:
   bool operator!=(const directory_iterator &RHS) const {
 return !(*this == RHS);
   }
-
-  /// For testing only. Directory iteration does not always succeed!
-  directory_iterator &operator++() {
-std::error_code EC;
-increment(EC);
-if (EC)
-  llvm::report_fatal_error("directory iteration failed!");
-return *this;
-  }
 };
 
 /// \brief The virtual file system interface.

Modified: cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp?rev=211633&r1=211632&r2=211633&view=diff
==
--- cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp (original)
+++ cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp Tue Jun 24 16:08:13 2014
@@ -296,11 +296,12 @@ TEST(VirtualFileSystemTest, BasicRealFSI
   I = FS->dir_begin(Twine(TestDirectory), EC);
   ASSERT_FALSE(EC);
   ASSERT_NE(vfs::directory_iterator(), I);
-  EXPECT_TRUE(I->getName().endswith("a"));
+  // Check either a or c, since we can't rely on the iteration order.
+  EXPECT_TRUE(I->getName().endswith("a") || I->getName().endswith("c"));
   I.increment(EC);
   ASSERT_FALSE(EC);
   ASSERT_NE(vfs::directory_iterator(), I);
-  EXPECT_TRUE(I->getName().endswith("c"));
+  EXPECT_TRUE(I->getName().endswith("a") || I->getName().endswith("c"));
   I.increment(EC);
   EXPECT_EQ(vfs::directory_iterator(), I);
 }
@@ -395,23 +396,25 @@ TEST(VirtualFileSystemTest, HiddenInIter
 checkContents(O->dir_begin("/", EC), Contents);
   }
 
-  // FIXME: broke gcc build
   // Make sure we get the top-most entry
-  // vfs::directory_iterator E;
-  // {
-  //   auto I = std::find_if(O->dir_begin("/", EC), E, [](vfs::Status S){
-  // return S.getName() == "/hiddenByUp";
-  //   });
-  //   ASSERT_NE(E, I);
-  //   EXPECT_EQ(sys::fs::owner_all, I->getPermissions());
-  // }
-  // {
-  //   auto I = std::find_if(O->dir_begin("/", EC), E, [](vfs::Status S){
-  // return S.getName() == "/hiddenByMid";
-  //   });
-  //   ASSERT_NE(E, I);
-  //   EXPECT_EQ(sys::fs::owner_write, I->getPermissions());
-  // }
+  {
+std::error_code EC;
+vfs::directory_iterator I = O->dir_begin("/", EC), E;
+for ( ; !EC && I != E; I.increment(EC))
+  if (I->getName() == "/hiddenByUp")
+break;
+ASSERT_NE(E, I);
+EXPECT_EQ(sys::fs::owner_all, I->getPermissions());
+  }
+  {
+std::error_code EC;
+vfs::directory_iterator I = O->dir_begin("/", EC), E;
+for ( ; !EC && I != E; I.increment(EC))
+  if (I->getName() == "/hiddenByMid")
+break;
+ASSERT_NE(E, I);
+EXPECT_EQ(sys::fs::owner_write, I->getPermissions());
+  }
 }
 
 // NOTE: in the tests below, we use '//root/' as our root directory, since it 
is


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r211604 - Use lowercase windows.h for mingw cross compilation.

[Zachary Turner]

Couldn't LLVM expose a registry interface on Windows and then the front-end
could conditionally include this header on Windows?  Other users of LLVM
might wish to use the registry too.


On Tue, Jun 24, 2014 at 1:11 PM, Reid Kleckner  wrote:

> IMO it's OK to use windows.h directly in this case.  There's no sensible
> cross-platform interface to the registry that we could add to lib/Support.
>  The registry only exists on Windows.
>
>
> On Tue, Jun 24, 2014 at 10:11 AM, Aaron Ballman 
> wrote:
>
>> On Tue, Jun 24, 2014 at 1:09 PM, Alp Toker  wrote:
>> >
>> > On 24/06/2014 19:53, Aaron Ballman wrote:
>> >>
>> >> On Tue, Jun 24, 2014 at 12:18 PM, Logan Chien <
>> tzuhsiang.ch...@gmail.com>
>> >> wrote:
>> >>>
>> >>> Author: logan
>> >>> Date: Tue Jun 24 11:18:10 2014
>> >>> New Revision: 211604
>> >>>
>> >>> URL: http://llvm.org/viewvc/llvm-project?rev=211604&view=rev
>> >>> Log:
>> >>> Use lowercase windows.h for mingw cross compilation.
>> >>>
>> >>> Modified:
>> >>>  cfe/trunk/lib/Driver/WindowsToolChain.cpp
>> >>>
>> >>> Modified: cfe/trunk/lib/Driver/WindowsToolChain.cpp
>> >>> URL:
>> >>>
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/WindowsToolChain.cpp?rev=211604&r1=211603&r2=211604&view=diff
>> >>>
>> >>>
>> ==
>> >>> --- cfe/trunk/lib/Driver/WindowsToolChain.cpp (original)
>> >>> +++ cfe/trunk/lib/Driver/WindowsToolChain.cpp Tue Jun 24 11:18:10 2014
>> >>> @@ -30,7 +30,7 @@
>> >>> #define WIN32_LEAN_AND_MEAN
>> >>> #define NOGDI
>> >>> #define NOMINMAX
>> >>> -  #include 
>> >>> +  #include 
>> >>>   #endif
>> >>
>> >> Why is windows.h being included here instead of WindowsSupport.h?
>> >
>> >
>> > WindowsSupport.h is internal to LLVM at the moment. We probably don't
>> need
>> > it for the limited uses of windows.h in the frontend.
>>
>> That's reasonably fair, but I think getting any instances of Windows.h
>> out of the frontend would be a very good thing. Obviously, that has no
>> bearing on this patch. :-)
>>
>> ~Aaron
>> ___
>> cfe-commits mailing list
>> cfe-commits@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r211632 - Forgot to add file in r211631

[Matt Arsenault]

Author: arsenm
Date: Tue Jun 24 15:58:46 2014
New Revision: 211632

URL: http://llvm.org/viewvc/llvm-project?rev=211632&view=rev
Log:
Forgot to add file in r211631

Added:
cfe/trunk/include/clang/Basic/BuiltinsR600.def

Added: cfe/trunk/include/clang/Basic/BuiltinsR600.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsR600.def?rev=211632&view=auto
==
--- cfe/trunk/include/clang/Basic/BuiltinsR600.def (added)
+++ cfe/trunk/include/clang/Basic/BuiltinsR600.def Tue Jun 24 15:58:46 2014
@@ -0,0 +1,20 @@
+//==- BuiltinsR600.def - R600 Builtin function database --*- C++ 
-*-==//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+// This file defines the R600-specific builtin function database. Users of this
+// file must define the BUILTIN macro to make use of this information.
+//
+//===--===//
+
+// The format of this database matches clang/Basic/Builtins.def.
+
+BUILTIN(__builtin_amdgpu_div_scale, "dddbb*", "n")
+BUILTIN(__builtin_amdgpu_div_scalef, "fffbb*", "n")
+
+#undef BUILTIN


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r211625 - Disable the bits of r211623 that broke the bots

[Eric Christopher]

On Tue, Jun 24, 2014 at 1:57 PM, Ben Langmuir  wrote:
>
>> On Jun 24, 2014, at 1:51 PM, Eric Christopher  wrote:
>>
>> I missed that this is in a testcase and not in the main code. I'm
>> definitely less worked up about it, but perhaps some more detail than
>> just the FIXME would be nice :)
>
> Hey Eric,
>
> Fair enough, the comment sucks and you’re right this isn’t a great way to 
> deal with test failures in general. FWIW, I’m working on this right now and I 
> didn’t want to revert entirely, because I was hoping to get some reassurance 
> from the bots that the rest of the patch was ok.  It’s hard to test 
> filesystem-ish changes because of the potential for platform differences :-)
>

Yeah, you're absolutely right. I'd misread it and thought it was the
main code, but a testcase you just added that's parsing a bit weird on
a system you don't have I'm much less concerned about. Great that
you're looking at it right now, sometimes it's not clear if it's a
"now" versus "soon" thing. :)

Thanks!

-eric

> Cheers,
>
> Ben
>
>>
>> Thanks!
>>
>> -eric
>>
>> On Tue, Jun 24, 2014 at 1:39 PM, Eric Christopher  wrote:
>>> Please don't do this in this way, just go ahead and revert the whole
>>> patch and figure it out.
>>>
>>> -eric
>>>
>>> On Tue, Jun 24, 2014 at 1:00 PM, Ben Langmuir  wrote:
 Author: benlangmuir
 Date: Tue Jun 24 15:00:30 2014
 New Revision: 211625

 URL: http://llvm.org/viewvc/llvm-project?rev=211625&view=rev
 Log:
 Disable the bits of r211623 that broke the bots

 Part of my test seems to rely on iterator bits that I didn't implement,
 at least in the gcc bots. Disabling while I investigate.

 Modified:
cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp

 Modified: cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp
 URL: 
 http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp?rev=211625&r1=211624&r2=211625&view=diff
 ==
 --- cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp (original)
 +++ cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp Tue Jun 24 
 15:00:30 2014
 @@ -395,22 +395,23 @@ TEST(VirtualFileSystemTest, HiddenInIter
 checkContents(O->dir_begin("/", EC), Contents);
   }

 +  // FIXME: broke gcc build
   // Make sure we get the top-most entry
 -  vfs::directory_iterator E;
 -  {
 -auto I = std::find_if(O->dir_begin("/", EC), E, [](vfs::Status S){
 -  return S.getName() == "/hiddenByUp";
 -});
 -ASSERT_NE(E, I);
 -EXPECT_EQ(sys::fs::owner_all, I->getPermissions());
 -  }
 -  {
 -auto I = std::find_if(O->dir_begin("/", EC), E, [](vfs::Status S){
 -  return S.getName() == "/hiddenByMid";
 -});
 -ASSERT_NE(E, I);
 -EXPECT_EQ(sys::fs::owner_write, I->getPermissions());
 -  }
 +  // vfs::directory_iterator E;
 +  // {
 +  //   auto I = std::find_if(O->dir_begin("/", EC), E, [](vfs::Status S){
 +  // return S.getName() == "/hiddenByUp";
 +  //   });
 +  //   ASSERT_NE(E, I);
 +  //   EXPECT_EQ(sys::fs::owner_all, I->getPermissions());
 +  // }
 +  // {
 +  //   auto I = std::find_if(O->dir_begin("/", EC), E, [](vfs::Status S){
 +  // return S.getName() == "/hiddenByMid";
 +  //   });
 +  //   ASSERT_NE(E, I);
 +  //   EXPECT_EQ(sys::fs::owner_write, I->getPermissions());
 +  // }
 }

 // NOTE: in the tests below, we use '//root/' as our root directory, since 
 it is


 ___
 cfe-commits mailing list
 cfe-commits@cs.uiuc.edu
 http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r211625 - Disable the bits of r211623 that broke the bots

[Ben Langmuir]

> On Jun 24, 2014, at 1:51 PM, Eric Christopher  wrote:
> 
> I missed that this is in a testcase and not in the main code. I'm
> definitely less worked up about it, but perhaps some more detail than
> just the FIXME would be nice :)

Hey Eric,

Fair enough, the comment sucks and you’re right this isn’t a great way to deal 
with test failures in general. FWIW, I’m working on this right now and I didn’t 
want to revert entirely, because I was hoping to get some reassurance from the 
bots that the rest of the patch was ok.  It’s hard to test filesystem-ish 
changes because of the potential for platform differences :-)

Cheers,

Ben

> 
> Thanks!
> 
> -eric
> 
> On Tue, Jun 24, 2014 at 1:39 PM, Eric Christopher  wrote:
>> Please don't do this in this way, just go ahead and revert the whole
>> patch and figure it out.
>> 
>> -eric
>> 
>> On Tue, Jun 24, 2014 at 1:00 PM, Ben Langmuir  wrote:
>>> Author: benlangmuir
>>> Date: Tue Jun 24 15:00:30 2014
>>> New Revision: 211625
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=211625&view=rev
>>> Log:
>>> Disable the bits of r211623 that broke the bots
>>> 
>>> Part of my test seems to rely on iterator bits that I didn't implement,
>>> at least in the gcc bots. Disabling while I investigate.
>>> 
>>> Modified:
>>>cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp
>>> 
>>> Modified: cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp
>>> URL: 
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp?rev=211625&r1=211624&r2=211625&view=diff
>>> ==
>>> --- cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp (original)
>>> +++ cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp Tue Jun 24 15:00:30 
>>> 2014
>>> @@ -395,22 +395,23 @@ TEST(VirtualFileSystemTest, HiddenInIter
>>> checkContents(O->dir_begin("/", EC), Contents);
>>>   }
>>> 
>>> +  // FIXME: broke gcc build
>>>   // Make sure we get the top-most entry
>>> -  vfs::directory_iterator E;
>>> -  {
>>> -auto I = std::find_if(O->dir_begin("/", EC), E, [](vfs::Status S){
>>> -  return S.getName() == "/hiddenByUp";
>>> -});
>>> -ASSERT_NE(E, I);
>>> -EXPECT_EQ(sys::fs::owner_all, I->getPermissions());
>>> -  }
>>> -  {
>>> -auto I = std::find_if(O->dir_begin("/", EC), E, [](vfs::Status S){
>>> -  return S.getName() == "/hiddenByMid";
>>> -});
>>> -ASSERT_NE(E, I);
>>> -EXPECT_EQ(sys::fs::owner_write, I->getPermissions());
>>> -  }
>>> +  // vfs::directory_iterator E;
>>> +  // {
>>> +  //   auto I = std::find_if(O->dir_begin("/", EC), E, [](vfs::Status S){
>>> +  // return S.getName() == "/hiddenByUp";
>>> +  //   });
>>> +  //   ASSERT_NE(E, I);
>>> +  //   EXPECT_EQ(sys::fs::owner_all, I->getPermissions());
>>> +  // }
>>> +  // {
>>> +  //   auto I = std::find_if(O->dir_begin("/", EC), E, [](vfs::Status S){
>>> +  // return S.getName() == "/hiddenByMid";
>>> +  //   });
>>> +  //   ASSERT_NE(E, I);
>>> +  //   EXPECT_EQ(sys::fs::owner_write, I->getPermissions());
>>> +  // }
>>> }
>>> 
>>> // NOTE: in the tests below, we use '//root/' as our root directory, since 
>>> it is
>>> 
>>> 
>>> ___
>>> cfe-commits mailing list
>>> cfe-commits@cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [LLVMdev] [cfe-dev] [PATCH] triples for baremetal

[Renato Golin]

On 24 June 2014 19:57, Jonathan Roelofs  wrote:
> Well, depends on what you mean by 'work', and also what is meant by that
> triple. To me, it means:
>
> ArchType: arm
> VendorType: CodeSourcery
> OSType: UnknownOS (not bare-metal)
> EnvironmentType: UnknownEnvironment
> ObjectFormatType: elf

Isn't that funny that, when we want to come up with a reasonable and
logical "triple", it actually has 5 fields? :)

That's why Clang and LLVM are desperately trying to move away from
triples, into separate flags. But if you separate the default from the
triple handling, we can re-use the default for the separate arguments
in the same way we use for legacy triples.


> Does that make sense?

It does when we control the environment. On legacy systems, not even
the user does. :(

--renato
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Add R600 div_scale builtin

[Matt Arsenault]

r211631

http://reviews.llvm.org/D4248



___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r211631 - Add R600 builtin codegen.

[Matt Arsenault]

Author: arsenm
Date: Tue Jun 24 15:45:01 2014
New Revision: 211631

URL: http://llvm.org/viewvc/llvm-project?rev=211631&view=rev
Log:
Add R600 builtin codegen.

Added:
cfe/trunk/test/CodeGenOpenCL/builtins-r600.cl
Modified:
cfe/trunk/include/clang/Basic/TargetBuiltins.h
cfe/trunk/include/clang/module.modulemap
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.h

Modified: cfe/trunk/include/clang/Basic/TargetBuiltins.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/TargetBuiltins.h?rev=211631&r1=211630&r2=211631&view=diff
==
--- cfe/trunk/include/clang/Basic/TargetBuiltins.h (original)
+++ cfe/trunk/include/clang/Basic/TargetBuiltins.h Tue Jun 24 15:45:01 2014
@@ -72,6 +72,15 @@ namespace clang {
 };
   }
 
+  /// \brief R600 builtins
+  namespace R600 {
+  enum {
+LastTIBuiltin = clang::Builtin::FirstTSBuiltin - 1,
+  #define BUILTIN(ID, TYPE, ATTRS) BI##ID,
+  #include "clang/Basic/BuiltinsR600.def"
+LastTSBuiltin
+  };
+  }
 
   /// \brief X86 builtins
   namespace X86 {

Modified: cfe/trunk/include/clang/module.modulemap
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/module.modulemap?rev=211631&r1=211630&r2=211631&view=diff
==
--- cfe/trunk/include/clang/module.modulemap (original)
+++ cfe/trunk/include/clang/module.modulemap Tue Jun 24 15:45:01 2014
@@ -36,6 +36,7 @@ module Clang_Basic {
   exclude header "Basic/BuiltinsNEON.def"
   exclude header "Basic/BuiltinsNVPTX.def"
   exclude header "Basic/BuiltinsPPC.def"
+  exclude header "Basic/BuiltinsR600.def"
   exclude header "Basic/BuiltinsX86.def"
   exclude header "Basic/BuiltinsXCore.def"
   exclude header "Basic/DiagnosticOptions.def"

Modified: cfe/trunk/lib/Basic/Targets.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=211631&r1=211630&r2=211631&view=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Tue Jun 24 15:45:01 2014
@@ -1458,6 +1458,8 @@ static const char *DescriptionStringSI =
   "-v192:256-v256:256-v512:512-v1024:1024-v2048:2048-n32:64";
 
 class R600TargetInfo : public TargetInfo {
+  static const Builtin::Info BuiltinInfo[];
+
   /// \brief The GPU profiles supported by the R600 target.
   enum GPUKind {
 GK_NONE,
@@ -1504,11 +1506,10 @@ public:
 
   void getTargetBuiltins(const Builtin::Info *&Records,
  unsigned &NumRecords) const override {
-Records = nullptr;
-NumRecords = 0;
+Records = BuiltinInfo;
+NumRecords = clang::R600::LastTSBuiltin - Builtin::FirstTSBuiltin;
   }
 
-
   void getTargetDefines(const LangOptions &Opts,
 MacroBuilder &Builder) const override {
 Builder.defineMacro("__R600__");
@@ -1584,6 +1585,12 @@ public:
   }
 };
 
+const Builtin::Info R600TargetInfo::BuiltinInfo[] = {
+#define BUILTIN(ID, TYPE, ATTRS)\
+  { #ID, TYPE, ATTRS, 0, ALL_LANGUAGES },
+#include "clang/Basic/BuiltinsR600.def"
+};
+
 } // end anonymous namespace
 
 namespace {

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=211631&r1=211630&r2=211631&view=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Tue Jun 24 15:45:01 2014
@@ -1689,6 +1689,8 @@ Value *CodeGenFunction::EmitTargetBuilti
   case llvm::Triple::ppc64:
   case llvm::Triple::ppc64le:
 return EmitPPCBuiltinExpr(BuiltinID, E);
+  case llvm::Triple::r600:
+return EmitR600BuiltinExpr(BuiltinID, E);
   default:
 return nullptr;
   }
@@ -5922,3 +5924,38 @@ Value *CodeGenFunction::EmitPPCBuiltinEx
   }
   }
 }
+
+Value *CodeGenFunction::EmitR600BuiltinExpr(unsigned BuiltinID,
+const CallExpr *E) {
+  switch (BuiltinID) {
+  case R600::BI__builtin_amdgpu_div_scale:
+  case R600::BI__builtin_amdgpu_div_scalef: {
+// Translate from the intrinsics's struct return to the builtin's out
+// argument.
+
+std::pair FlagOutPtr
+  = EmitPointerWithAlignment(E->getArg(3));
+
+llvm::Value *X = EmitScalarExpr(E->getArg(0));
+llvm::Value *Y = EmitScalarExpr(E->getArg(1));
+llvm::Value *Z = EmitScalarExpr(E->getArg(2));
+
+llvm::Value *Callee = CGM.getIntrinsic(Intrinsic::AMDGPU_div_scale,
+   X->getType());
+
+llvm::Value *Tmp = Builder.CreateCall3(Callee, X, Y, Z);
+
+llvm::Value *Result = Builder.CreateExtractValue(Tmp, 0);
+llvm::Value *Flag = Builder.CreateExtractValue(Tmp, 1);
+
+llvm::Type *RealFlagType
+  = FlagOutPtr.first->getType()-

Re: r211625 - Disable the bits of r211623 that broke the bots

[Eric Christopher]

I missed that this is in a testcase and not in the main code. I'm
definitely less worked up about it, but perhaps some more detail than
just the FIXME would be nice :)

Thanks!

-eric

On Tue, Jun 24, 2014 at 1:39 PM, Eric Christopher  wrote:
> Please don't do this in this way, just go ahead and revert the whole
> patch and figure it out.
>
> -eric
>
> On Tue, Jun 24, 2014 at 1:00 PM, Ben Langmuir  wrote:
>> Author: benlangmuir
>> Date: Tue Jun 24 15:00:30 2014
>> New Revision: 211625
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=211625&view=rev
>> Log:
>> Disable the bits of r211623 that broke the bots
>>
>> Part of my test seems to rely on iterator bits that I didn't implement,
>> at least in the gcc bots. Disabling while I investigate.
>>
>> Modified:
>> cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp
>>
>> Modified: cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp?rev=211625&r1=211624&r2=211625&view=diff
>> ==
>> --- cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp (original)
>> +++ cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp Tue Jun 24 15:00:30 
>> 2014
>> @@ -395,22 +395,23 @@ TEST(VirtualFileSystemTest, HiddenInIter
>>  checkContents(O->dir_begin("/", EC), Contents);
>>}
>>
>> +  // FIXME: broke gcc build
>>// Make sure we get the top-most entry
>> -  vfs::directory_iterator E;
>> -  {
>> -auto I = std::find_if(O->dir_begin("/", EC), E, [](vfs::Status S){
>> -  return S.getName() == "/hiddenByUp";
>> -});
>> -ASSERT_NE(E, I);
>> -EXPECT_EQ(sys::fs::owner_all, I->getPermissions());
>> -  }
>> -  {
>> -auto I = std::find_if(O->dir_begin("/", EC), E, [](vfs::Status S){
>> -  return S.getName() == "/hiddenByMid";
>> -});
>> -ASSERT_NE(E, I);
>> -EXPECT_EQ(sys::fs::owner_write, I->getPermissions());
>> -  }
>> +  // vfs::directory_iterator E;
>> +  // {
>> +  //   auto I = std::find_if(O->dir_begin("/", EC), E, [](vfs::Status S){
>> +  // return S.getName() == "/hiddenByUp";
>> +  //   });
>> +  //   ASSERT_NE(E, I);
>> +  //   EXPECT_EQ(sys::fs::owner_all, I->getPermissions());
>> +  // }
>> +  // {
>> +  //   auto I = std::find_if(O->dir_begin("/", EC), E, [](vfs::Status S){
>> +  // return S.getName() == "/hiddenByMid";
>> +  //   });
>> +  //   ASSERT_NE(E, I);
>> +  //   EXPECT_EQ(sys::fs::owner_write, I->getPermissions());
>> +  // }
>>  }
>>
>>  // NOTE: in the tests below, we use '//root/' as our root directory, since 
>> it is
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r211589 - [OPENMP] Additional checking for 'collapse' clause.

[Hal Finkel]

- Original Message -
> From: "Alexey Bataev" 
> To: cfe-commits@cs.uiuc.edu
> Sent: Tuesday, June 24, 2014 7:55:57 AM
> Subject: r211589 - [OPENMP] Additional checking for 'collapse' clause.
> 
> Author: abataev
> Date: Tue Jun 24 07:55:56 2014
> New Revision: 211589
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=211589&view=rev
> Log:
> [OPENMP] Additional checking for 'collapse' clause.
> 

[snip]

>  
> +namespace {
> +struct OMPCollapseClauseFilter {
> +  OMPCollapseClauseFilter() {}
> +  bool operator()(const OMPClause *C) {
> +return C->getClauseKind() == OMPC_collapse;
> +  }
> +};
> +} // namespace

Can we use a lambda for this? 

> +
> +static Expr *GetCollapseNumberExpr(ArrayRef Clauses) {
> +
>  OMPExecutableDirective::filtered_clause_iterator
> I(
> +  Clauses);
> +  if (I)
> +return cast(*I)->getNumForLoops();
> +  return nullptr;
> +}
> +

 -Hal

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r211630 - Fix missing C++ mode comment

[Matt Arsenault]

Author: arsenm
Date: Tue Jun 24 15:32:13 2014
New Revision: 211630

URL: http://llvm.org/viewvc/llvm-project?rev=211630&view=rev
Log:
Fix missing C++ mode comment

Modified:
cfe/trunk/include/clang/Basic/TargetBuiltins.h

Modified: cfe/trunk/include/clang/Basic/TargetBuiltins.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/TargetBuiltins.h?rev=211630&r1=211629&r2=211630&view=diff
==
--- cfe/trunk/include/clang/Basic/TargetBuiltins.h (original)
+++ cfe/trunk/include/clang/Basic/TargetBuiltins.h Tue Jun 24 15:32:13 2014
@@ -1,4 +1,4 @@
-//===--- TargetBuiltins.h - Target specific builtin IDs 
---===//
+//===--- TargetBuiltins.h - Target specific builtin IDs -*- C++ 
-*-===//
 //
 // The LLVM Compiler Infrastructure
 //


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

[libcxx] r211629 - eliminate install of duplicate headers (take 2)

[David Fang]

Author: fangism
Date: Tue Jun 24 15:32:11 2014
New Revision: 211629

URL: http://llvm.org/viewvc/llvm-project?rev=211629&view=rev
Log:
eliminate install of duplicate headers (take 2)
Patch by Ryuta Suzuki

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

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=211629&r1=211628&r2=211629&view=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Tue Jun 24 15:32:11 2014
@@ -90,16 +90,17 @@ set(LIBCXX_TARGET_TRIPLE ${LIBCXX_TARGET
 macro(setup_abi_lib abipathvar abidefines abilibs abifiles abidirs)
   list(APPEND LIBCXX_CXX_FEATURE_FLAGS ${abidefines})
   set(${abipathvar} "${${abipathvar}}"
-CACHE STRINGS
-"Paths to ABI include directories separate by ';'."
+CACHE PATH
+"Paths to C++ ABI header directories separated by ';'." FORCE
 )
   set(LIBCXX_CXX_ABI_LIBRARIES ${abilibs})
   set(LIBCXX_ABILIB_FILES ${abifiles})
+
   file(MAKE_DIRECTORY "${CMAKE_BINARY_DIR}/include")
   foreach(_d ${abidirs})
 file(MAKE_DIRECTORY "${CMAKE_BINARY_DIR}/include/${_d}")
   endforeach()
-  set(LIBCXX_ABILIB_FILE_PATHS)
+
   foreach(fpath ${LIBCXX_ABILIB_FILES})
 set(found FALSE)
 foreach(incpath ${${abipathvar}})
@@ -107,29 +108,23 @@ macro(setup_abi_lib abipathvar abidefine
 set(found TRUE)
 get_filename_component(dstdir ${fpath} PATH)
 get_filename_component(ifile ${fpath} NAME)
-add_custom_command(
-  OUTPUT "${CMAKE_BINARY_DIR}/include/${dstdir}/${ifile}"
-  COMMAND ${CMAKE_COMMAND} -E copy_if_different
-"${incpath}/${fpath}"
-"${CMAKE_BINARY_DIR}/include/${dstdir}"
-  MAIN_DEPENDENCY "${incpath}/${fpath}"
-  )
-list(APPEND LIBCXX_CXX_ABI_DEPS
-  "${CMAKE_BINARY_DIR}/include/${dstdir}/${ifile}"
+file(COPY "${incpath}/${fpath}"
+  DESTINATION "${CMAKE_BINARY_DIR}/include/${dstdir}"
   )
+list(APPEND abilib_headers "${CMAKE_BINARY_DIR}/include/${fpath}")
   endif()
 endforeach()
 if (NOT found)
   message(FATAL_ERROR "Failed to find ${fpath}")
 endif()
   endforeach()
-  add_custom_target(abilib_headers DEPENDS ${LIBCXX_CXX_ABI_DEPS})
-  set(LIBCXX_CXX_ABI_DEPS abilib_headers)
+
+  add_custom_target(LIBCXX_CXX_ABI_DEPS DEPENDS ${abilib_headers})
   include_directories("${CMAKE_BINARY_DIR}/include")
-  install(DIRECTORY "${CMAKE_BINARY_DIR}/include/"
+
+  install(FILES ${abilib_headers}
 DESTINATION include/c++/v1
-FILES_MATCHING
-PATTERN "*"
+PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ
 )
 endmacro()
 
@@ -181,6 +176,7 @@ if (MSVC)
 else()
   if (LIBCXX_HAS_NOSTDINCXX_FLAG)
 list(APPEND LIBCXX_CXX_REQUIRED_FLAGS -nostdinc++)
+string(REPLACE "-stdlib=libc++" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
   endif()
   if (LIBCXX_ENABLE_CXX0X AND LIBCXX_HAS_STDCXX0X_FLAG)
 list(APPEND LIBCXX_CXX_REQUIRED_FLAGS -std=c++0x)

Modified: libcxx/trunk/include/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/CMakeLists.txt?rev=211629&r1=211628&r2=211629&view=diff
==
--- libcxx/trunk/include/CMakeLists.txt (original)
+++ libcxx/trunk/include/CMakeLists.txt Tue Jun 24 15:32:11 2014
@@ -2,15 +2,12 @@ if (NOT LIBCXX_INSTALL_SUPPORT_HEADERS)
   set(LIBCXX_SUPPORT_HEADER_PATTERN PATTERN "support" EXCLUDE)
 endif()
 
-file(COPY .
-  DESTINATION "${CMAKE_BINARY_DIR}/include/c++/v1"
+install(DIRECTORY .
+  DESTINATION include/c++/v1
   FILES_MATCHING
   PATTERN "*"
   PATTERN "CMakeLists.txt" EXCLUDE
   PATTERN ".svn" EXCLUDE
   ${LIBCXX_SUPPORT_HEADER_PATTERN}
-  )
-
-install(DIRECTORY "${CMAKE_BINARY_DIR}/include/c++/v1/"
-  DESTINATION include/c++/v1/
+  PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ
   )

Modified: libcxx/trunk/lib/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/lib/CMakeLists.txt?rev=211629&r1=211628&r2=211629&view=diff
==
--- libcxx/trunk/lib/CMakeLists.txt (original)
+++ libcxx/trunk/lib/CMakeLists.txt Tue Jun 24 15:32:11 2014
@@ -32,7 +32,7 @@ else()
 endif()
 
 if (DEFINED LIBCXX_CXX_ABI_DEPS)
-  add_dependencies(cxx ${LIBCXX_CXX_ABI_DEPS})
+  add_dependencies(cxx LIBCXX_CXX_ABI_DEPS)
 endif()
 
 # Generate library list.


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r211625 - Disable the bits of r211623 that broke the bots

[Eric Christopher]

Please don't do this in this way, just go ahead and revert the whole
patch and figure it out.

-eric

On Tue, Jun 24, 2014 at 1:00 PM, Ben Langmuir  wrote:
> Author: benlangmuir
> Date: Tue Jun 24 15:00:30 2014
> New Revision: 211625
>
> URL: http://llvm.org/viewvc/llvm-project?rev=211625&view=rev
> Log:
> Disable the bits of r211623 that broke the bots
>
> Part of my test seems to rely on iterator bits that I didn't implement,
> at least in the gcc bots. Disabling while I investigate.
>
> Modified:
> cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp
>
> Modified: cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp?rev=211625&r1=211624&r2=211625&view=diff
> ==
> --- cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp (original)
> +++ cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp Tue Jun 24 15:00:30 
> 2014
> @@ -395,22 +395,23 @@ TEST(VirtualFileSystemTest, HiddenInIter
>  checkContents(O->dir_begin("/", EC), Contents);
>}
>
> +  // FIXME: broke gcc build
>// Make sure we get the top-most entry
> -  vfs::directory_iterator E;
> -  {
> -auto I = std::find_if(O->dir_begin("/", EC), E, [](vfs::Status S){
> -  return S.getName() == "/hiddenByUp";
> -});
> -ASSERT_NE(E, I);
> -EXPECT_EQ(sys::fs::owner_all, I->getPermissions());
> -  }
> -  {
> -auto I = std::find_if(O->dir_begin("/", EC), E, [](vfs::Status S){
> -  return S.getName() == "/hiddenByMid";
> -});
> -ASSERT_NE(E, I);
> -EXPECT_EQ(sys::fs::owner_write, I->getPermissions());
> -  }
> +  // vfs::directory_iterator E;
> +  // {
> +  //   auto I = std::find_if(O->dir_begin("/", EC), E, [](vfs::Status S){
> +  // return S.getName() == "/hiddenByUp";
> +  //   });
> +  //   ASSERT_NE(E, I);
> +  //   EXPECT_EQ(sys::fs::owner_all, I->getPermissions());
> +  // }
> +  // {
> +  //   auto I = std::find_if(O->dir_begin("/", EC), E, [](vfs::Status S){
> +  // return S.getName() == "/hiddenByMid";
> +  //   });
> +  //   ASSERT_NE(E, I);
> +  //   EXPECT_EQ(sys::fs::owner_write, I->getPermissions());
> +  // }
>  }
>
>  // NOTE: in the tests below, we use '//root/' as our root directory, since 
> it is
>
>
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Avoid extra back reference key lookup in msmangler

[Agustín Bergé]

Changes in this iteration:

- Use the new `StringMap::insert` overload.
- Template instantiation names are source names, mangle them as such.

http://reviews.llvm.org/D4130

Files:
  lib/AST/MicrosoftMangle.cpp

Index: lib/AST/MicrosoftMangle.cpp
===
--- lib/AST/MicrosoftMangle.cpp
+++ lib/AST/MicrosoftMangle.cpp
@@ -650,6 +650,7 @@
 // FIXME: Test alias template mangling with MSVC 2013.
 if (!isa(TD)) {
   mangleTemplateInstantiationName(TD, *TemplateArgs);
+  Out << '@';
   return;
 }
 
@@ -668,22 +669,13 @@
 // the mangled type name as a key to check the mangling of different types
 // for aliasing.
 
-std::string TemplateMangling;
-llvm::raw_string_ostream Stream(TemplateMangling);
+llvm::SmallString<64> TemplateMangling;
+llvm::raw_svector_ostream Stream(TemplateMangling);
 MicrosoftCXXNameMangler Extra(Context, Stream);
 Extra.mangleTemplateInstantiationName(TD, *TemplateArgs);
 Stream.flush();
 
-BackRefMap::iterator Found = NameBackReferences.find(TemplateMangling);
-if (Found == NameBackReferences.end()) {
-  Out << TemplateMangling;
-  if (NameBackReferences.size() < 10) {
-size_t Size = NameBackReferences.size();
-NameBackReferences[TemplateMangling] = Size;
-  }
-} else {
-  Out << Found->second;
-}
+mangleSourceName(TemplateMangling);
 return;
   }
 
@@ -1002,13 +994,20 @@
 
 void MicrosoftCXXNameMangler::mangleSourceName(StringRef Name) {
   //  ::=  @
-  BackRefMap::iterator Found = NameBackReferences.find(Name);
+  BackRefMap::iterator Found;
+  if (NameBackReferences.size() < 10) {
+size_t Size = NameBackReferences.size();
+bool Inserted;
+std::tie(Found, Inserted) =
+NameBackReferences.insert(std::make_pair(Name, Size));
+if (Inserted)
+  Found = NameBackReferences.end();
+  } else {
+Found = NameBackReferences.find(Name);
+  }
+
   if (Found == NameBackReferences.end()) {
 Out << Name << '@';
-if (NameBackReferences.size() < 10) {
-  size_t Size = NameBackReferences.size();
-  NameBackReferences[Name] = Size;
-}
   } else {
 Out << Found->second;
   }
@@ -1104,10 +1103,9 @@
 
 void MicrosoftCXXNameMangler::mangleTemplateArgs(
 const TemplateDecl *TD, const TemplateArgumentList &TemplateArgs) {
-  //  ::= + @
+  //  ::= +
   for (const TemplateArgument &TA : TemplateArgs.asArray())
 mangleTemplateArg(TD, TA);
-  Out << '@';
 }
 
 void MicrosoftCXXNameMangler::mangleTemplateArg(const TemplateDecl *TD,
Index: lib/AST/MicrosoftMangle.cpp
===
--- lib/AST/MicrosoftMangle.cpp
+++ lib/AST/MicrosoftMangle.cpp
@@ -650,6 +650,7 @@
 // FIXME: Test alias template mangling with MSVC 2013.
 if (!isa(TD)) {
   mangleTemplateInstantiationName(TD, *TemplateArgs);
+  Out << '@';
   return;
 }
 
@@ -668,22 +669,13 @@
 // the mangled type name as a key to check the mangling of different types
 // for aliasing.
 
-std::string TemplateMangling;
-llvm::raw_string_ostream Stream(TemplateMangling);
+llvm::SmallString<64> TemplateMangling;
+llvm::raw_svector_ostream Stream(TemplateMangling);
 MicrosoftCXXNameMangler Extra(Context, Stream);
 Extra.mangleTemplateInstantiationName(TD, *TemplateArgs);
 Stream.flush();
 
-BackRefMap::iterator Found = NameBackReferences.find(TemplateMangling);
-if (Found == NameBackReferences.end()) {
-  Out << TemplateMangling;
-  if (NameBackReferences.size() < 10) {
-size_t Size = NameBackReferences.size();
-NameBackReferences[TemplateMangling] = Size;
-  }
-} else {
-  Out << Found->second;
-}
+mangleSourceName(TemplateMangling);
 return;
   }
 
@@ -1002,13 +994,20 @@
 
 void MicrosoftCXXNameMangler::mangleSourceName(StringRef Name) {
   //  ::=  @
-  BackRefMap::iterator Found = NameBackReferences.find(Name);
+  BackRefMap::iterator Found;
+  if (NameBackReferences.size() < 10) {
+size_t Size = NameBackReferences.size();
+bool Inserted;
+std::tie(Found, Inserted) =
+NameBackReferences.insert(std::make_pair(Name, Size));
+if (Inserted)
+  Found = NameBackReferences.end();
+  } else {
+Found = NameBackReferences.find(Name);
+  }
+
   if (Found == NameBackReferences.end()) {
 Out << Name << '@';
-if (NameBackReferences.size() < 10) {
-  size_t Size = NameBackReferences.size();
-  NameBackReferences[Name] = Size;
-}
   } else {
 Out << Found->second;
   }
@@ -1104,10 +1103,9 @@
 
 void MicrosoftCXXNameMangler::mangleTemplateArgs(
 const TemplateDecl *TD, const TemplateArgumentList &TemplateArgs) {
-  //  ::= + @
+  //  ::= +
   for (const TemplateArgument &TA : TemplateArgs.asArray())
 mangleTemplateArg(TD, TA);
-  Out << '@';
 }
 
 void MicrosoftCXXNameMangler::mangleTemplateArg(const TemplateDecl *TD,
___

Re: r211604 - Use lowercase windows.h for mingw cross compilation.

[Reid Kleckner]

IMO it's OK to use windows.h directly in this case.  There's no sensible
cross-platform interface to the registry that we could add to lib/Support.
 The registry only exists on Windows.


On Tue, Jun 24, 2014 at 10:11 AM, Aaron Ballman 
wrote:

> On Tue, Jun 24, 2014 at 1:09 PM, Alp Toker  wrote:
> >
> > On 24/06/2014 19:53, Aaron Ballman wrote:
> >>
> >> On Tue, Jun 24, 2014 at 12:18 PM, Logan Chien <
> tzuhsiang.ch...@gmail.com>
> >> wrote:
> >>>
> >>> Author: logan
> >>> Date: Tue Jun 24 11:18:10 2014
> >>> New Revision: 211604
> >>>
> >>> URL: http://llvm.org/viewvc/llvm-project?rev=211604&view=rev
> >>> Log:
> >>> Use lowercase windows.h for mingw cross compilation.
> >>>
> >>> Modified:
> >>>  cfe/trunk/lib/Driver/WindowsToolChain.cpp
> >>>
> >>> Modified: cfe/trunk/lib/Driver/WindowsToolChain.cpp
> >>> URL:
> >>>
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/WindowsToolChain.cpp?rev=211604&r1=211603&r2=211604&view=diff
> >>>
> >>>
> ==
> >>> --- cfe/trunk/lib/Driver/WindowsToolChain.cpp (original)
> >>> +++ cfe/trunk/lib/Driver/WindowsToolChain.cpp Tue Jun 24 11:18:10 2014
> >>> @@ -30,7 +30,7 @@
> >>> #define WIN32_LEAN_AND_MEAN
> >>> #define NOGDI
> >>> #define NOMINMAX
> >>> -  #include 
> >>> +  #include 
> >>>   #endif
> >>
> >> Why is windows.h being included here instead of WindowsSupport.h?
> >
> >
> > WindowsSupport.h is internal to LLVM at the moment. We probably don't
> need
> > it for the limited uses of windows.h in the frontend.
>
> That's reasonably fair, but I think getting any instances of Windows.h
> out of the frontend would be a very good thing. Obviously, that has no
> bearing on this patch. :-)
>
> ~Aaron
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r211626 - Correctly Load Mixed FP-GP Variadic Arguments for x86-64.

[Rafael Espindola]

Author: rafael
Date: Tue Jun 24 15:01:50 2014
New Revision: 211626

URL: http://llvm.org/viewvc/llvm-project?rev=211626&view=rev
Log:
Correctly Load Mixed FP-GP Variadic Arguments for x86-64.

According to the x86-64 ABI, structures with both floating point and
integer members are split between floating-point and general purpose
registers, and consecutive 32-bit floats can be packed into a single
floating point register.

In the case of variadic functions these are stored to memory and the position
recorded in the va_list. This was already correctly implemented in
llvm.va_start.

The problem is that the code in clang for implementing va_arg was reading
floating point registers from the wrong location.

Patch by Thomas Jablin.

Fixes PR20018.

Added:
cfe/trunk/test/CodeGen/variadic-gpfp-x86.c
Modified:
cfe/trunk/lib/CodeGen/TargetInfo.cpp

Modified: cfe/trunk/lib/CodeGen/TargetInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.cpp?rev=211626&r1=211625&r2=211626&view=diff
==
--- cfe/trunk/lib/CodeGen/TargetInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/TargetInfo.cpp Tue Jun 24 15:01:50 2014
@@ -2590,8 +2590,8 @@ llvm::Value *X86_64ABIInfo::EmitVAArg(ll
 llvm::Type *PTyHi = llvm::PointerType::getUnqual(TyHi);
 llvm::Value *GPAddr = CGF.Builder.CreateGEP(RegAddr, gp_offset);
 llvm::Value *FPAddr = CGF.Builder.CreateGEP(RegAddr, fp_offset);
-llvm::Value *RegLoAddr = TyLo->isFloatingPointTy() ? FPAddr : GPAddr;
-llvm::Value *RegHiAddr = TyLo->isFloatingPointTy() ? GPAddr : FPAddr;
+llvm::Value *RegLoAddr = TyLo->isFPOrFPVectorTy() ? FPAddr : GPAddr;
+llvm::Value *RegHiAddr = TyLo->isFPOrFPVectorTy() ? GPAddr : FPAddr;
 llvm::Value *V =
   CGF.Builder.CreateLoad(CGF.Builder.CreateBitCast(RegLoAddr, PTyLo));
 CGF.Builder.CreateStore(V, CGF.Builder.CreateStructGEP(Tmp, 0));

Added: cfe/trunk/test/CodeGen/variadic-gpfp-x86.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/variadic-gpfp-x86.c?rev=211626&view=auto
==
--- cfe/trunk/test/CodeGen/variadic-gpfp-x86.c (added)
+++ cfe/trunk/test/CodeGen/variadic-gpfp-x86.c Tue Jun 24 15:01:50 2014
@@ -0,0 +1,15 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm %s -o - | 
FileCheck %s
+
+struct Bar {
+ float f1;
+ float f2;
+ unsigned u;
+};
+
+struct Bar foo(__builtin_va_list ap) {
+  return __builtin_va_arg(ap, struct Bar);
+// CHECK: [[FPOP:%.*]] = getelementptr inbounds %struct.__va_list_tag* {{.*}}, 
i32 0, i32 1
+// CHECK: [[FPO:%.*]] = load i32* [[FPOP]]
+// CHECK: [[FPVEC:%.*]] = getelementptr i8* {{.*}}, i32 [[FPO]]
+// CHECK: bitcast i8* [[FPVEC]] to <2 x float>*
+}


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r211625 - Disable the bits of r211623 that broke the bots

[Ben Langmuir]

Author: benlangmuir
Date: Tue Jun 24 15:00:30 2014
New Revision: 211625

URL: http://llvm.org/viewvc/llvm-project?rev=211625&view=rev
Log:
Disable the bits of r211623 that broke the bots

Part of my test seems to rely on iterator bits that I didn't implement,
at least in the gcc bots. Disabling while I investigate.

Modified:
cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp

Modified: cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp?rev=211625&r1=211624&r2=211625&view=diff
==
--- cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp (original)
+++ cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp Tue Jun 24 15:00:30 2014
@@ -395,22 +395,23 @@ TEST(VirtualFileSystemTest, HiddenInIter
 checkContents(O->dir_begin("/", EC), Contents);
   }
 
+  // FIXME: broke gcc build
   // Make sure we get the top-most entry
-  vfs::directory_iterator E;
-  {
-auto I = std::find_if(O->dir_begin("/", EC), E, [](vfs::Status S){
-  return S.getName() == "/hiddenByUp";
-});
-ASSERT_NE(E, I);
-EXPECT_EQ(sys::fs::owner_all, I->getPermissions());
-  }
-  {
-auto I = std::find_if(O->dir_begin("/", EC), E, [](vfs::Status S){
-  return S.getName() == "/hiddenByMid";
-});
-ASSERT_NE(E, I);
-EXPECT_EQ(sys::fs::owner_write, I->getPermissions());
-  }
+  // vfs::directory_iterator E;
+  // {
+  //   auto I = std::find_if(O->dir_begin("/", EC), E, [](vfs::Status S){
+  // return S.getName() == "/hiddenByUp";
+  //   });
+  //   ASSERT_NE(E, I);
+  //   EXPECT_EQ(sys::fs::owner_all, I->getPermissions());
+  // }
+  // {
+  //   auto I = std::find_if(O->dir_begin("/", EC), E, [](vfs::Status S){
+  // return S.getName() == "/hiddenByMid";
+  //   });
+  //   ASSERT_NE(E, I);
+  //   EXPECT_EQ(sys::fs::owner_write, I->getPermissions());
+  // }
 }
 
 // NOTE: in the tests below, we use '//root/' as our root directory, since it 
is


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r211622 - Simplify optimization-remark.c test following r211610

[Alp Toker]

Author: alp
Date: Tue Jun 24 14:23:10 2014
New Revision: 211622

URL: http://llvm.org/viewvc/llvm-project?rev=211622&view=rev
Log:
Simplify optimization-remark.c test following r211610

With LocTrackingOnly there's no longer a user-facing distinction so the NDEBUG
checks can go away. (Except maybe column info, but -verify only checks line
numbers anyway.)

Also add a RUN line to validate the traditional !LocTrackingOnly case.

Modified:
cfe/trunk/test/Frontend/optimization-remark.c

Modified: cfe/trunk/test/Frontend/optimization-remark.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/optimization-remark.c?rev=211622&r1=211621&r2=211622&view=diff
==
--- cfe/trunk/test/Frontend/optimization-remark.c (original)
+++ cfe/trunk/test/Frontend/optimization-remark.c Tue Jun 24 14:23:10 2014
@@ -4,7 +4,7 @@
 // optimization level.
 
 // RUN: %clang_cc1 %s -Rpass=inline -Rpass-analysis=inline 
-Rpass-missed=inline -O0 -emit-llvm-only -verify
-// RUN: %clang_cc1 %s -DNDEBUG -Rpass=inline -emit-llvm-only -verify
+// RUN: %clang_cc1 %s -Rpass=inline -Rpass-analysis=inline 
-Rpass-missed=inline -O0 -emit-llvm-only -gline-tables-only -verify
 // RUN: %clang_cc1 %s -Rpass=inline -emit-llvm -o - 2>/dev/null | FileCheck %s
 
 // -Rpass should produce source location annotations, exclusively (just
@@ -26,16 +26,11 @@ float foz(int x, int y) { return x * y;
 // twice.
 //
 int bar(int j) {
-#ifndef NDEBUG
-// expected-remark@+7 {{foz should never be inlined (cost=never)}}
-// expected-remark@+6 {{foz will not be inlined into bar}}
-// expected-remark@+5 {{foz should never be inlined}}
-// expected-remark@+4 {{foz will not be inlined into bar}}
-// expected-remark@+3 {{foo should always be inlined}}
-// expected-remark@+2 {{foo inlined into bar}}
-#endif
+// expected-remark@+6 {{foz should never be inlined (cost=never)}}
+// expected-remark@+5 {{foz will not be inlined into bar}}
+// expected-remark@+4 {{foz should never be inlined}}
+// expected-remark@+3 {{foz will not be inlined into bar}}
+// expected-remark@+2 {{foo should always be inlined}}
+// expected-remark@+1 {{foo inlined into bar}}
   return foo(j, j - 2) * foz(j - 2, j);
 }
-#ifdef NDEBUG
-// expected-remark@-3 {{foo inlined into bar}}
-#endif


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Correctly Load Mixed FP-GP Variadic Arguments for x86-64

[Rafael Espíndola]

LGTM. Just a nit, the test can be reduced juts a bit further to

struct Bar foo( __builtin_va_list ap) {
  return __builtin_va_arg(ap, struct Bar);
}

This avoid the llvm.va_start call and makes the abi issue more explicit.


On 16 June 2014 17:23, Thomas Jablin  wrote:
> Please find enclosed an updated patch containing a test showing the
> difference in the generated IR.
> Tom
>
>
> On Mon, Jun 16, 2014 at 3:25 PM, Rafael Espíndola
>  wrote:
>>
>> Can you write a test showing the difference is the generated IR? Look
>> at the tests i clang/test/CodeGen for examples.
>>
>> On 16 June 2014 13:46, Thomas Jablin  wrote:
>> > Hi,
>> > Please find enclosed a patch to resolve PR20018. According to the x86-64
>> > ABI, structures with both floating point and integer members are split
>> > between floating-point and general purpose registers, and consecutive
>> > 32-bit
>> > floats can be packed into a single floating point register. In variadic
>> > functions, clang writes out the state of the GP registers and FP
>> > registers
>> > to different regions in memory. A bug in the TargetInfo logic is causing
>> > llvm to try to read floating point arguments from the FP region of the
>> > stack. Specifically:
>> >
>> > 02593 llvm::Value *RegLoAddr = TyLo->isFloatingPointTy() ? FPAddr :
>> > GPAddr;
>> > 02594 llvm::Value *RegHiAddr = TyLo->isFloatingPointTy() ? GPAddr :
>> > FPAddr;
>> >
>> > Are checking if TyLo is a floating point type, however, two consecutive
>> > floating point fields will be represented as an floating point vector.
>> > Consequently, the correct code should be:
>> >
>> > 02593llvm::Value *RegLoAddr = TyLo->isFPOrFPVectorTy() ? FPAddr :
>> > GPAddr;
>> > 02594llvm::Value *RegHiAddr = TyLo->isFPOrFPVectorTy() ? GPAddr :
>> > FPAddr;
>> >
>> > The code on line 2623 is already checking for floating point vectors
>> > appropriately. I have also attached a simple test case named gpfpTest.c.
>> > Thanks.
>> > Tom
>> >
>> >
>> > ___
>> > cfe-commits mailing list
>> > cfe-commits@cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>> >
>
>

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [cfe-dev] [LLVMdev] [PATCH] triples for baremetal

[Renato Golin]

On 23 June 2014 15:31, David Chisnall  wrote:
> I don't really like the way that we conflate OS with ABI, but then I don't 
> really like anything about triples...

This was broken before... "we" didn't do anything... :)

I don't know the whole story but it was supposed to be a triple and
people started using the third field to mean different things, then
they added an interchangeable fourth field, and then it's impossible
to distinguish.

I cry every time I have to think about it.

--renato
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r211624 - Use appropriate default PIE settings for OpenBSD.

[Brad Smith]

Author: brad
Date: Tue Jun 24 14:51:29 2014
New Revision: 211624

URL: http://llvm.org/viewvc/llvm-project?rev=211624&view=rev
Log:
Use appropriate default PIE settings for OpenBSD.

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

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=211624&r1=211623&r2=211624&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Tue Jun 24 14:51:29 2014
@@ -2432,6 +2432,27 @@ void Clang::ConstructJob(Compilation &C,
 }
   }
 
+  // OpenBSD-specific defaults for PIE
+  if (getToolChain().getTriple().getOS() == llvm::Triple::OpenBSD) {
+switch (getToolChain().getTriple().getArch()) {
+case llvm::Triple::mips64:
+case llvm::Triple::mips64el:
+case llvm::Triple::sparc:
+case llvm::Triple::x86:
+case llvm::Triple::x86_64:
+  IsPICLevelTwo = false; // "-fpie"
+  break;
+
+case llvm::Triple::ppc:
+case llvm::Triple::sparcv9:
+  IsPICLevelTwo = true; // "-fPIE"
+  break;
+
+default:
+  break;
+}
+  }
+
   // For the PIC and PIE flag options, this logic is different from the
   // legacy logic in very old versions of GCC, as that logic was just
   // a bug no one had ever fixed. This logic is both more rational and

Modified: cfe/trunk/test/Driver/pic.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/pic.c?rev=211624&r1=211623&r2=211624&view=diff
==
--- cfe/trunk/test/Driver/pic.c (original)
+++ cfe/trunk/test/Driver/pic.c Tue Jun 24 14:51:29 2014
@@ -201,7 +201,17 @@
 // RUN:   | FileCheck %s --check-prefix=CHECK-NO-PIC
 //
 // On OpenBSD, PIE is enabled by default, but can be disabled.
+// RUN: %clang -c %s -target amd64-pc-openbsd -### 2>&1 \
+// RUN:   | FileCheck %s --check-prefix=CHECK-PIE1
 // RUN: %clang -c %s -target i386-pc-openbsd -### 2>&1 \
+// RUN:   | FileCheck %s --check-prefix=CHECK-PIE1
+// RUN: %clang -c %s -target mips64-unknown-openbsd -### 2>&1 \
+// RUN:   | FileCheck %s --check-prefix=CHECK-PIE1
+// RUN: %clang -c %s -target mips64el-unknown-openbsd -### 2>&1 \
+// RUN:   | FileCheck %s --check-prefix=CHECK-PIE1
+// RUN: %clang -c %s -target powerpc-unknown-openbsd -### 2>&1 \
+// RUN:   | FileCheck %s --check-prefix=CHECK-PIE2
+// RUN: %clang -c %s -target sparc64-unknown-openbsd -### 2>&1 \
 // RUN:   | FileCheck %s --check-prefix=CHECK-PIE2
 // RUN: %clang -c %s -target i386-pc-openbsd -fno-pie -### 2>&1 \
 // RUN:   | FileCheck %s --check-prefix=CHECK-NO-PIC


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [cfe-dev] [LLVMdev] [PATCH] triples for baremetal

[Jonathan Roelofs]

On 6/24/14, 12:01 PM, Eric Christopher wrote:

Hi Jonathan,

This looks a bit odd. Any reason for the unknown->none conflating in
this way?

I'm trying to un-conflate them... What specifically seems odd to you about it?

IMHO, when a user doesn't explicitly specify that a target's OS is 'none' 
(perhaps they left it off, or they explicitly said 'unknown') then they probably 
don't intend to target bare-metal.

For most (all) of the ports unknown-elf works the same as
none-elf.

Yes, and so would santas-elf ;)

All three of these examples fall into the same "it doesn't match anything else 
OSType::UnknownOS bucket", and I want to change that.

I'm also not sure if someone decided to have,
arm-codesourcery-elf that this would still work with the patch.


Well, depends on what you mean by 'work', and also what is meant by that triple. 
To me, it means:


ArchType: arm
VendorType: CodeSourcery
OSType: UnknownOS (not bare-metal)
EnvironmentType: UnknownEnvironment
ObjectFormatType: elf

If a user wants the baremetal version of that hypothetical triple, my argument 
is that they should say arm-codesourcery-none-elf, and they would get:


ArchType: arm
VendorType: CodeSourcery
OSType: NoneOS
EnvironmentType: UnknownEnvironment
ObjectFormatType: elf

Does that make sense?


Cheers,

Jon



Thoughts?

-eric



--
Jon Roelofs
jonat...@codesourcery.com
CodeSourcery / Mentor Embedded
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r211623 - Add directory_iterator for (non-recursive) iteration of VFS directories

[Ben Langmuir]

Author: benlangmuir
Date: Tue Jun 24 14:37:16 2014
New Revision: 211623

URL: http://llvm.org/viewvc/llvm-project?rev=211623&view=rev
Log:
Add directory_iterator for (non-recursive) iteration of VFS directories

The API is based on sys::fs::directory_iterator, but it allows iterating
over overlays and the yaml-based VFS.  For now, it isn't used by
anything (except its tests).

Modified:
cfe/trunk/include/clang/Basic/VirtualFileSystem.h
cfe/trunk/lib/Basic/VirtualFileSystem.cpp
cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp

Modified: cfe/trunk/include/clang/Basic/VirtualFileSystem.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/VirtualFileSystem.h?rev=211623&r1=211622&r2=211623&view=diff
==
--- cfe/trunk/include/clang/Basic/VirtualFileSystem.h (original)
+++ cfe/trunk/include/clang/Basic/VirtualFileSystem.h Tue Jun 24 14:37:16 2014
@@ -100,6 +100,64 @@ public:
   virtual void setName(StringRef Name) = 0;
 };
 
+namespace detail {
+/// \brief An interface for virtual file systems to provide an iterator over 
the
+/// (non-recursive) contents of a directory.
+struct DirIterImpl {
+  virtual ~DirIterImpl();
+  /// \brief Sets \c CurrentEntry to the next entry in the directory on 
success,
+  /// or returns a system-defined \c error_code.
+  virtual std::error_code increment() = 0;
+  Status CurrentEntry;
+};
+} // end namespace detail
+
+/// \brief An input iterator over the entries in a virtual path, similar to
+/// llvm::sys::fs::directory_iterator.
+class directory_iterator {
+  std::shared_ptr Impl; // Input iterator semantics on 
copy
+
+public:
+  directory_iterator(std::shared_ptr I) : Impl(I) {
+assert(Impl.get() != nullptr && "requires non-null implementation");
+if (!Impl->CurrentEntry.isStatusKnown())
+  Impl.reset(); // Normalize the end iterator to Impl == nullptr.
+  }
+
+  /// \brief Construct an 'end' iterator.
+  directory_iterator() { }
+
+  /// \brief Equivalent to operator++, with an error code.
+  directory_iterator &increment(std::error_code &EC) {
+assert(Impl && "attempting to increment past end");
+EC = Impl->increment();
+if (EC || !Impl->CurrentEntry.isStatusKnown())
+  Impl.reset(); // Normalize the end iterator to Impl == nullptr.
+return *this;
+  }
+
+  const Status &operator*() const { return Impl->CurrentEntry; }
+  const Status *operator->() const { return &Impl->CurrentEntry; }
+
+  bool operator==(const directory_iterator &RHS) const {
+if (Impl && RHS.Impl)
+  return Impl->CurrentEntry.equivalent(RHS.Impl->CurrentEntry);
+return !Impl && !RHS.Impl;
+  }
+  bool operator!=(const directory_iterator &RHS) const {
+return !(*this == RHS);
+  }
+
+  /// For testing only. Directory iteration does not always succeed!
+  directory_iterator &operator++() {
+std::error_code EC;
+increment(EC);
+if (EC)
+  llvm::report_fatal_error("directory iteration failed!");
+return *this;
+  }
+};
+
 /// \brief The virtual file system interface.
 class FileSystem : public llvm::ThreadSafeRefCountedBase {
 public:
@@ -118,6 +176,13 @@ public:
int64_t FileSize = -1,
bool RequiresNullTerminator = true,
bool IsVolatile = false);
+
+  /// \brief Get a directory_iterator for \p Dir.
+  /// \note The 'end' iterator is directory_iterator()
+  virtual directory_iterator dir_begin(const Twine &Dir,
+   std::error_code &EC) = 0;
+
+  // TODO: recursive directory iterators
 };
 
 /// \brief Gets an \p vfs::FileSystem for the 'real' file system, as seen by
@@ -136,19 +201,10 @@ IntrusiveRefCntPtr getRealFi
 /// system overrides the other(s).
 class OverlayFileSystem : public FileSystem {
   typedef SmallVector, 1> FileSystemList;
-  typedef FileSystemList::reverse_iterator iterator;
-
   /// \brief The stack of file systems, implemented as a list in order of
   /// their addition.
   FileSystemList FSList;
 
-  /// \brief Get an iterator pointing to the most recently added file system.
-  iterator overlays_begin() { return FSList.rbegin(); }
-
-  /// \brief Get an iterator pointing one-past the least recently added file
-  /// system.
-  iterator overlays_end() { return FSList.rend(); }
-
 public:
   OverlayFileSystem(IntrusiveRefCntPtr Base);
   /// \brief Pushes a file system on top of the stack.
@@ -157,6 +213,16 @@ public:
   llvm::ErrorOr status(const Twine &Path) override;
   std::error_code openFileForRead(const Twine &Path,
   std::unique_ptr &Result) override;
+  directory_iterator dir_begin(const Twine &Dir, std::error_code &EC) override;
+
+  typedef FileSystemList::reverse_iterator iterator;
+  
+  /// \brief Get an iterator pointing to the most recently added file system.
+  iterator overlays_begin() { return FSList.rbegin(); }
+
+  /// \b

r211619 - [Driver][Mips] Support mips64-linux-gnuabi64 / mips64el-linux-gnuabi64 target triples.

[Simon Atanasyan]

Author: atanasyan
Date: Tue Jun 24 14:00:12 2014
New Revision: 211619

URL: http://llvm.org/viewvc/llvm-project?rev=211619&view=rev
Log:
[Driver][Mips] Support mips64-linux-gnuabi64 / mips64el-linux-gnuabi64 target 
triples.

The patch fixes the bug #19869.
http://llvm.org/bugs/show_bug.cgi?id=19869

Added:
cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/
cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/lib/
cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/lib/mips64-linux-gnuabi64/

cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/lib/mips64-linux-gnuabi64/.keep

cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/lib/mips64el-linux-gnuabi64/

cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/lib/mips64el-linux-gnuabi64/.keep
cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/
cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/include/
cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/include/c++/
cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/include/c++/4.9/

cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/include/c++/4.9/backward/

cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/include/c++/4.9/backward/.keep

cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/include/c++/4.9/mips64-linux-gnuabi64/

cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/include/c++/4.9/mips64-linux-gnuabi64/.keep

cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/include/c++/4.9/mips64el-linux-gnuabi64/

cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/include/c++/4.9/mips64el-linux-gnuabi64/.keep

cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/include/mips64-linux-gnuabi64/

cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/include/mips64-linux-gnuabi64/.keep

cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/include/mips64el-linux-gnuabi64/

cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/include/mips64el-linux-gnuabi64/.keep
cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/lib/
cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/lib/gcc/

cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/lib/gcc/mips64-linux-gnuabi64/

cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/lib/gcc/mips64-linux-gnuabi64/4.9/

cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/lib/gcc/mips64-linux-gnuabi64/4.9/crtbegin.o

cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/lib/gcc/mips64-linux-gnuabi64/4.9/crtend.o

cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/lib/gcc/mips64el-linux-gnuabi64/

cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/lib/gcc/mips64el-linux-gnuabi64/4.9/

cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/lib/gcc/mips64el-linux-gnuabi64/4.9/crtbegin.o

cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/lib/gcc/mips64el-linux-gnuabi64/4.9/crtend.o

cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/lib/mips64-linux-gnuabi64/

cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/lib/mips64-linux-gnuabi64/crt1.o

cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/lib/mips64-linux-gnuabi64/crti.o

cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/lib/mips64-linux-gnuabi64/crtn.o

cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/lib/mips64el-linux-gnuabi64/

cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/lib/mips64el-linux-gnuabi64/crt1.o

cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/lib/mips64el-linux-gnuabi64/crti.o

cfe/trunk/test/Driver/Inputs/debian_6_mips64_tree/usr/lib/mips64el-linux-gnuabi64/crtn.o
Modified:
cfe/trunk/lib/Driver/ToolChains.cpp
cfe/trunk/test/Driver/linux-header-search.cpp
cfe/trunk/test/Driver/linux-ld.c

Modified: cfe/trunk/lib/Driver/ToolChains.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp?rev=211619&r1=211618&r2=211619&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains.cpp Tue Jun 24 14:00:12 2014
@@ -1360,11 +1360,13 @@ bool Generic_GCC::GCCInstallationDetecto
 
   static const char *const MIPS64LibDirs[] = { "/lib64", "/lib" };
   static const char *const MIPS64Triples[] = { "mips64-linux-gnu",
-   "mips-mti-linux-gnu" };
+   "mips-mti-linux-gnu",
+   "mips64-linux-gnuabi64" };
   static const char *const MIPS64ELLibDirs[] = { "/lib64", "/lib" };
   static const char *const MIPS64ELTriples[] = { "mips64el-linux-gnu",
  "mips-mti-linux-gnu",
- "mips64el-linux-android" };
+ "mips64el-linux-android",
+ "mips64el-linux-gnuabi

Re: [cfe-dev] [LLVMdev] [PATCH] triples for baremetal

[Renato Golin]

On 24 June 2014 14:58, Jonathan Roelofs  wrote:
> I would like to go this route, providing I can get support from the
> community that this is the direction we'd all like to take... I'd rather not
> make triples more complicated by introducing lots of special cases.

Hi Jonathan,

I love breaking legacy stuff, but this is not just up to me. There are
a lot of odd triples (quadruples, quintuples and the like) out there
that will defy any logic, and they "seem" to work on LLVM as well as
GCC (maybe not in the same way) because people can't distinguish or
detect the problems well enough.

Having said that, Eric raised the same concern I did, which is that
unknown != none. Empty string (ex. arm-eabi) defaults to "unknown",
and only "none" is NoneOS. That, I think, is paramount because it
gives a robust mechanism to reason about triples.

Completely orthogonal is what to do when you're facing an empty string
or "unknown". My view is that there should be a mechanism, per {
target / OS / env }, that would decide, based on the other values,
what to do with that. Of course, this mechanism has to be lazily
evaluated, so that you have information about the environment while
deciding what to do with the OS.

Completely bogus examples would be:

arm-eabi -> arm-none-eabi
arm-gnueabi -> arm-linux-gnueabi
arm-elf -> arm-freebsd-elf
arm-apple -> arm-apple-darwin

and the mapping of what goes where will depend on FreeBSD, Darwin,
Linux, etc. for OS, and ARM, x86, PPC, MIPS for the
architecture/vendor, etc.


> Do you know who the right folks are to ask about the SPIR triples?

Tim, David and Eric are already sharing their opinions, which is great.

>From an EABI point of view, unknown == none == . I'm not so
sure about the gnueabi/hf, which I'd assume would default to Linux,
but would be glad to learn I'm wrong.

But, perhaps more importantly, we need to be at least reasonably close
to GCC's behaviour. This is a particularly troubling issue on build
systems, when the triple is already broken enough to make anyone cramp
for weeks, and behaving erratically will only make it less likely that
people will try Clang/LLVM in place of GCC in the future.

Thread lightly, double check with GCC and make sure triple parsing is
orthogonal to triple default behaviour. We already have problems in
the parser because the triple changes under the parser's feet.

cheers,
--renato
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Add R600 div_scale builtin

[Tom Stellard]

On Mon, Jun 23, 2014 at 12:10:34AM +, Matt Arsenault wrote:
> http://reviews.llvm.org/D4248
> 

LGTM.

> Files:
>   include/clang/Basic/TargetBuiltins.h
>   include/clang/module.modulemap
>   lib/Basic/Targets.cpp
>   lib/CodeGen/CGBuiltin.cpp
>   lib/CodeGen/CodeGenFunction.h
>   test/CodeGenOpenCL/builtins-r600.cl

> Index: include/clang/Basic/TargetBuiltins.h
> ===
> --- include/clang/Basic/TargetBuiltins.h
> +++ include/clang/Basic/TargetBuiltins.h
> @@ -72,6 +72,15 @@
>  };
>}
>  
> +  /// \brief R600 builtins
> +  namespace R600 {
> +  enum {
> +LastTIBuiltin = clang::Builtin::FirstTSBuiltin - 1,
> +  #define BUILTIN(ID, TYPE, ATTRS) BI##ID,
> +  #include "clang/Basic/BuiltinsR600.def"
> +LastTSBuiltin
> +  };
> +  }
>  
>/// \brief X86 builtins
>namespace X86 {
> Index: include/clang/module.modulemap
> ===
> --- include/clang/module.modulemap
> +++ include/clang/module.modulemap
> @@ -36,6 +36,7 @@
>exclude header "Basic/BuiltinsNEON.def"
>exclude header "Basic/BuiltinsNVPTX.def"
>exclude header "Basic/BuiltinsPPC.def"
> +  exclude header "Basic/BuiltinsR600.def"
>exclude header "Basic/BuiltinsX86.def"
>exclude header "Basic/BuiltinsXCore.def"
>exclude header "Basic/DiagnosticOptions.def"
> Index: lib/Basic/Targets.cpp
> ===
> --- lib/Basic/Targets.cpp
> +++ lib/Basic/Targets.cpp
> @@ -1458,6 +1458,8 @@
>"-v192:256-v256:256-v512:512-v1024:1024-v2048:2048-n32:64";
>  
>  class R600TargetInfo : public TargetInfo {
> +  static const Builtin::Info BuiltinInfo[];
> +
>/// \brief The GPU profiles supported by the R600 target.
>enum GPUKind {
>  GK_NONE,
> @@ -1504,11 +1506,10 @@
>  
>void getTargetBuiltins(const Builtin::Info *&Records,
>   unsigned &NumRecords) const override {
> -Records = nullptr;
> -NumRecords = 0;
> +Records = BuiltinInfo;
> +NumRecords = clang::R600::LastTSBuiltin - Builtin::FirstTSBuiltin;
>}
>  
> -
>void getTargetDefines(const LangOptions &Opts,
>  MacroBuilder &Builder) const override {
>  Builder.defineMacro("__R600__");
> @@ -1584,6 +1585,12 @@
>}
>  };
>  
> +const Builtin::Info R600TargetInfo::BuiltinInfo[] = {
> +#define BUILTIN(ID, TYPE, ATTRS)\
> +  { #ID, TYPE, ATTRS, 0, ALL_LANGUAGES },
> +#include "clang/Basic/BuiltinsR600.def"
> +};
> +
>  } // end anonymous namespace
>  
>  namespace {
> Index: lib/CodeGen/CGBuiltin.cpp
> ===
> --- lib/CodeGen/CGBuiltin.cpp
> +++ lib/CodeGen/CGBuiltin.cpp
> @@ -1689,6 +1689,8 @@
>case llvm::Triple::ppc64:
>case llvm::Triple::ppc64le:
>  return EmitPPCBuiltinExpr(BuiltinID, E);
> +  case llvm::Triple::r600:
> +return EmitR600BuiltinExpr(BuiltinID, E);
>default:
>  return nullptr;
>}
> @@ -5952,3 +5954,38 @@
>}
>}
>  }
> +
> +Value *CodeGenFunction::EmitR600BuiltinExpr(unsigned BuiltinID,
> +const CallExpr *E) {
> +  switch (BuiltinID) {
> +  case R600::BI__builtin_amdgpu_div_scale:
> +  case R600::BI__builtin_amdgpu_div_scalef: {
> +// Translate from the intrinsics's struct return to the builtin's out
> +// argument.
> +
> +std::pair FlagOutPtr
> +  = EmitPointerWithAlignment(E->getArg(3));
> +
> +llvm::Value *X = EmitScalarExpr(E->getArg(0));
> +llvm::Value *Y = EmitScalarExpr(E->getArg(1));
> +llvm::Value *Z = EmitScalarExpr(E->getArg(2));
> +
> +llvm::Value *Callee = CGM.getIntrinsic(Intrinsic::AMDGPU_div_scale,
> +   X->getType());
> +
> +llvm::Value *Tmp = Builder.CreateCall3(Callee, X, Y, Z);
> +
> +llvm::Value *Result = Builder.CreateExtractValue(Tmp, 0);
> +llvm::Value *Flag = Builder.CreateExtractValue(Tmp, 1);
> +
> +llvm::Type *RealFlagType
> +  = FlagOutPtr.first->getType()->getPointerElementType();
> +
> +llvm::Value *FlagExt = Builder.CreateZExt(Flag, RealFlagType);
> +llvm::StoreInst *FlagStore = Builder.CreateStore(FlagExt, 
> FlagOutPtr.first);
> +FlagStore->setAlignment(FlagOutPtr.second);
> +return Result;
> +  } default:
> +return nullptr;
> +  }
> +}
> Index: lib/CodeGen/CodeGenFunction.h
> ===
> --- lib/CodeGen/CodeGenFunction.h
> +++ lib/CodeGen/CodeGenFunction.h
> @@ -2252,6 +2252,7 @@
>llvm::Value *BuildVector(ArrayRef Ops);
>llvm::Value *EmitX86BuiltinExpr(unsigned BuiltinID, const CallExpr *E);
>llvm::Value *EmitPPCBuiltinExpr(unsigned BuiltinID, const CallExpr *E);
> +  llvm::Value *EmitR600BuiltinExpr(unsigned BuiltinID, const CallExpr *E);
>  
>llvm::Value *EmitObjCProtocolExpr(const ObjCProtocolExpr *E);
>llvm::Value 

Re: [cfe-dev] [LLVMdev] [PATCH] triples for baremetal

[Eric Christopher]

Hi Jonathan,

This looks a bit odd. Any reason for the unknown->none conflating in
this way? For most (all) of the ports unknown-elf works the same as
none-elf. I'm also not sure if someone decided to have,
arm-codesourcery-elf that this would still work with the patch.

Thoughts?

-eric

On Tue, Jun 24, 2014 at 7:35 AM, Amara Emerson  wrote:
> Hi Jon,
>
> This looks reasonable to me.
>
> Cheers,
> Amara
>
> On 24 June 2014 14:58, Jonathan Roelofs  wrote:
>>
>>
>> On 6/23/14, 8:31 AM, David Chisnall wrote:
>>>
>>> On 23 Jun 2014, at 15:13, Renato Golin  wrote:
>>>
 The main issue with your patch is that it can change user expected
 behaviour, and I can't tell you what is the expected behaviour in
 Darwin or BSD. If people usually use "unknown" in triples, this will
 break their builds. If not, this could break the build of someone who
 does.
>>
>> Renato,
>>
>> I would like to go this route, providing I can get support from the
>> community that this is the direction we'd all like to take... I'd rather not
>> make triples more complicated by introducing lots of special cases.
>>
>> Do you know who the right folks are to ask about the SPIR triples?
>>
>>
>> Tim,
>>
>> This patch changes behavior a little for macho_embedded targets (i.e. from
>> OSType::Unknown to OSType::NoneOS). I see that there is existing code to
>> transform triples from things like thumbv7-apple-darwin into
>> thumbv7m-apple-unknown-macho. Do you have an expectation to support users
>> who are using the latter form of triples who would be surprised by the
>> change from thumbv7m-apple-unknown-macho to thumbv7m-apple-none-macho (i.e.
>> their thumbv7m-apple-unknown-macho builds no longer work)? Is this a case
>> where all three triples are to mean the same thing?
>>
>>
>>>
>>> I think (Hat: FreeBSD) we only expect to see unknown in the vendor field
>>> (e.g. i386-unknown-freebsd).  If the OS field is unknown, rather than
>>> freebsd, then it's not one of ours and we aren't likely to care.  I don't
>>> really like the way that we conflate OS with ABI, but then I don't really
>>> like anything about triples...
>>
>> David, thanks!
>>
>>
>> Cheers,
>> Jon
>>
>>>
>>> David
>>>
>>
>> --
>> Jon Roelofs
>> jonat...@codesourcery.com
>> CodeSourcery / Mentor Embedded
>> ___
>> cfe-commits mailing list
>> cfe-commits@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r211615 - Fix test added in r211610 so it doesn't race on output file creation.

[David Blaikie]

Author: dblaikie
Date: Tue Jun 24 12:31:05 2014
New Revision: 211615

URL: http://llvm.org/viewvc/llvm-project?rev=211615&view=rev
Log:
Fix test added in r211610 so it doesn't race on output file creation.

Modified:
cfe/trunk/test/Frontend/optimization-remark.c

Modified: cfe/trunk/test/Frontend/optimization-remark.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/optimization-remark.c?rev=211615&r1=211614&r2=211615&view=diff
==
--- cfe/trunk/test/Frontend/optimization-remark.c (original)
+++ cfe/trunk/test/Frontend/optimization-remark.c Tue Jun 24 12:31:05 2014
@@ -5,7 +5,7 @@
 
 // RUN: %clang_cc1 %s -Rpass=inline -Rpass-analysis=inline 
-Rpass-missed=inline -O0 -emit-llvm-only -verify
 // RUN: %clang_cc1 %s -DNDEBUG -Rpass=inline -emit-llvm-only -verify
-// RUN: %clang_cc1 %s -Rpass=inline -emit-llvm -o %t 2>/dev/null | FileCheck 
%s < %t
+// RUN: %clang_cc1 %s -Rpass=inline -emit-llvm -o - 2>/dev/null | FileCheck %s
 
 // -Rpass should produce source location annotations, exclusively (just
 // like -gmlt).


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r211604 - Use lowercase windows.h for mingw cross compilation.

[Aaron Ballman]

On Tue, Jun 24, 2014 at 1:09 PM, Alp Toker  wrote:
>
> On 24/06/2014 19:53, Aaron Ballman wrote:
>>
>> On Tue, Jun 24, 2014 at 12:18 PM, Logan Chien 
>> wrote:
>>>
>>> Author: logan
>>> Date: Tue Jun 24 11:18:10 2014
>>> New Revision: 211604
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=211604&view=rev
>>> Log:
>>> Use lowercase windows.h for mingw cross compilation.
>>>
>>> Modified:
>>>  cfe/trunk/lib/Driver/WindowsToolChain.cpp
>>>
>>> Modified: cfe/trunk/lib/Driver/WindowsToolChain.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/WindowsToolChain.cpp?rev=211604&r1=211603&r2=211604&view=diff
>>>
>>> ==
>>> --- cfe/trunk/lib/Driver/WindowsToolChain.cpp (original)
>>> +++ cfe/trunk/lib/Driver/WindowsToolChain.cpp Tue Jun 24 11:18:10 2014
>>> @@ -30,7 +30,7 @@
>>> #define WIN32_LEAN_AND_MEAN
>>> #define NOGDI
>>> #define NOMINMAX
>>> -  #include 
>>> +  #include 
>>>   #endif
>>
>> Why is windows.h being included here instead of WindowsSupport.h?
>
>
> WindowsSupport.h is internal to LLVM at the moment. We probably don't need
> it for the limited uses of windows.h in the frontend.

That's reasonably fair, but I think getting any instances of Windows.h
out of the frontend would be a very good thing. Obviously, that has no
bearing on this patch. :-)

~Aaron
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Add new debug kind LocTrackingOnly.

[Diego Novillo]

Closed by commit rL211610 (authored by @dnovillo).

REPOSITORY
  rL LLVM

http://reviews.llvm.org/D4235

Files:
  cfe/trunk/docs/UsersManual.rst
  cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
  cfe/trunk/include/clang/Frontend/CodeGenOptions.def
  cfe/trunk/include/clang/Frontend/CodeGenOptions.h
  cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
  cfe/trunk/lib/CodeGen/CodeGenAction.cpp
  cfe/trunk/lib/Frontend/CompilerInvocation.cpp
  cfe/trunk/test/Frontend/optimization-remark.c
Index: cfe/trunk/test/Frontend/optimization-remark.c
===
--- cfe/trunk/test/Frontend/optimization-remark.c
+++ cfe/trunk/test/Frontend/optimization-remark.c
@@ -3,8 +3,18 @@
 // always trigger the inliner, so it should be independent of the
 // optimization level.
 
-// RUN: %clang_cc1 %s -Rpass=inline -Rpass-analysis=inline -Rpass-missed=inline -O0 -gline-tables-only -emit-llvm-only -verify
+// RUN: %clang_cc1 %s -Rpass=inline -Rpass-analysis=inline -Rpass-missed=inline -O0 -emit-llvm-only -verify
 // RUN: %clang_cc1 %s -DNDEBUG -Rpass=inline -emit-llvm-only -verify
+// RUN: %clang_cc1 %s -Rpass=inline -emit-llvm -o %t 2>/dev/null | FileCheck %s < %t
+
+// -Rpass should produce source location annotations, exclusively (just
+// like -gmlt).
+// CHECK: , !dbg !
+// CHECK-NOT: DW_TAG_base_type
+
+// But llvm.dbg.cu should be missing (to prevent writing debug info to
+// the final output).
+// CHECK-NOT: !llvm.dbg.cu = !{
 
 int foo(int x, int y) __attribute__((always_inline));
 int foo(int x, int y) { return x + y; }
@@ -27,5 +37,5 @@
   return foo(j, j - 2) * foz(j - 2, j);
 }
 #ifdef NDEBUG
-// expected-remark@-2 {{foo inlined into bar}} expected-note@-2 {{use -gline-tables-only -gcolumn-info to track source location information for this optimization remark}}
+// expected-remark@-3 {{foo inlined into bar}}
 #endif
Index: cfe/trunk/include/clang/Frontend/CodeGenOptions.h
===
--- cfe/trunk/include/clang/Frontend/CodeGenOptions.h
+++ cfe/trunk/include/clang/Frontend/CodeGenOptions.h
@@ -53,6 +53,13 @@
   enum DebugInfoKind {
 NoDebugInfo,  /// Don't generate debug info.
 
+LocTrackingOnly,  /// Emit location information but do not generate
+  /// debug info in the output. This is useful in
+  /// cases where the backend wants to track source
+  /// locations for instructions without actually
+  /// emitting debug info for them (e.g., when -Rpass
+  /// is used).
+
 DebugLineTablesOnly,  /// Emit only debug info necessary for generating
   /// line number tables (-gline-tables-only).
 
Index: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
===
--- cfe/trunk/include/clang/Frontend/CodeGenOptions.def
+++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def
@@ -140,7 +140,7 @@
 VALUE_CODEGENOPT(SSPBufferSize, 32, 0)
 
 /// The kind of generated debug info.
-ENUM_CODEGENOPT(DebugInfo, DebugInfoKind, 2, NoDebugInfo)
+ENUM_CODEGENOPT(DebugInfo, DebugInfoKind, 3, NoDebugInfo)
 
 /// Dwarf version.
 VALUE_CODEGENOPT(DwarfVersion, 3, 0)
Index: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
===
--- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
+++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
@@ -41,9 +41,6 @@
 InGroup, DefaultRemark;
 def remark_fe_backend_optimization_remark_analysis : Remark<"%0">, BackendInfo,
 InGroup, DefaultRemark;
-def note_fe_backend_optimization_remark_missing_loc : Note<"use "
-  "-gline-tables-only -gcolumn-info to track source location information "
-  "for this optimization remark">;
 def note_fe_backend_optimization_remark_invalid_loc : Note<"could "
   "not determine the original source location for %0:%1:%2">;
 
Index: cfe/trunk/docs/UsersManual.rst
===
--- cfe/trunk/docs/UsersManual.rst
+++ cfe/trunk/docs/UsersManual.rst
@@ -577,12 +577,10 @@
 Current limitations
 ^^^
 
-1. For :option:`-Rpass` to provide source location information, you
-   need to enable debug line tables and column information. That is,
-   you need to add :option:`-gmlt` (or any of the debug-generating
-   flags) and :option:`-gcolumn-info`. If you omit these options,
-   every remark will be accompanied by a note stating that line number
-   information is missing.
+1. For :option:`-Rpass` to provide column information, you
+   need to enable it explicitly. That is, you need to add
+   :option:`-gcolumn-info`. If you omit this, remarks will only show
+   line information.
 
 2. Optimization remarks that refer to function names will display the
mangled name of the function. Since these remarks a

r211611 - Objective-C. When we use @selector(save:), etc. there may be more

[Fariborz Jahanian]

Author: fjahanian
Date: Tue Jun 24 12:02:19 2014
New Revision: 211611

URL: http://llvm.org/viewvc/llvm-project?rev=211611&view=rev
Log:
Objective-C. When we use @selector(save:), etc. there may be more 
than one method with mismatched type of same selector name. 
clang issues a warning to point this out since it may cause 
undefined behavior. There are cases though that some APIs 
don't care about user methods and such warnings are perceived as 
noise. This patch allows users to add paren delimiters around
selector name to turn off such warnings. So, @selector((save:)) will
turn off the warning. It also provides 'fixit' so user knows 
what to do. // rdar://16458579

Added:
cfe/trunk/test/FixIt/fixit-multiple-selector-warnings.m
Modified:
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Parse/ParseObjc.cpp
cfe/trunk/lib/Sema/SemaExprObjC.cpp
cfe/trunk/test/SemaObjC/selector-1.m

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=211611&r1=211610&r2=211611&view=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Tue Jun 24 12:02:19 2014
@@ -4748,7 +4748,8 @@ public:
  SourceLocation AtLoc,
  SourceLocation SelLoc,
  SourceLocation LParenLoc,
- SourceLocation RParenLoc);
+ SourceLocation RParenLoc,
+ bool WarnMultipleSelectors);
 
   /// ParseObjCProtocolExpression - Build protocol expression for \@protocol
   ExprResult ParseObjCProtocolExpression(IdentifierInfo * ProtocolName,

Modified: cfe/trunk/lib/Parse/ParseObjc.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseObjc.cpp?rev=211611&r1=211610&r2=211611&view=diff
==
--- cfe/trunk/lib/Parse/ParseObjc.cpp (original)
+++ cfe/trunk/lib/Parse/ParseObjc.cpp Tue Jun 24 12:02:19 2014
@@ -2839,7 +2839,7 @@ Parser::ParseObjCProtocolExpression(Sour
 }
 
 /// objc-selector-expression
-///   @selector '(' objc-keyword-selector ')'
+///   @selector '(' '('[opt] objc-keyword-selector ')'[opt] ')'
 ExprResult Parser::ParseObjCSelectorExpression(SourceLocation AtLoc) {
   SourceLocation SelectorLoc = ConsumeToken();
 
@@ -2851,7 +2851,10 @@ ExprResult Parser::ParseObjCSelectorExpr
   
   BalancedDelimiterTracker T(*this, tok::l_paren);
   T.consumeOpen();
-
+  bool HasOptionalParen = Tok.is(tok::l_paren);
+  if (HasOptionalParen)
+ConsumeParen();
+  
   if (Tok.is(tok::code_completion)) {
 Actions.CodeCompleteObjCSelector(getCurScope(), KeyIdents);
 cutOffParsing();
@@ -2864,6 +2867,7 @@ ExprResult Parser::ParseObjCSelectorExpr
 return ExprError(Diag(Tok, diag::err_expected) << tok::identifier);
 
   KeyIdents.push_back(SelIdent);
+  
   unsigned nColons = 0;
   if (Tok.isNot(tok::r_paren)) {
 while (1) {
@@ -2891,11 +2895,14 @@ ExprResult Parser::ParseObjCSelectorExpr
 break;
 }
   }
+  if (HasOptionalParen && Tok.is(tok::r_paren))
+ConsumeParen(); // ')'
   T.consumeClose();
   Selector Sel = PP.getSelectorTable().getSelector(nColons, &KeyIdents[0]);
   return Actions.ParseObjCSelectorExpression(Sel, AtLoc, SelectorLoc,
  T.getOpenLocation(),
- T.getCloseLocation());
+ T.getCloseLocation(),
+ !HasOptionalParen);
  }
 
 void Parser::ParseLexedObjCMethodDefs(LexedMethod &LM, bool parseMethod) {

Modified: cfe/trunk/lib/Sema/SemaExprObjC.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExprObjC.cpp?rev=211611&r1=211610&r2=211611&view=diff
==
--- cfe/trunk/lib/Sema/SemaExprObjC.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExprObjC.cpp Tue Jun 24 12:02:19 2014
@@ -976,6 +976,8 @@ ExprResult Sema::ParseObjCEncodeExpressi
 
 static bool HelperToDiagnoseMismatchedMethodsInGlobalPool(Sema &S,
SourceLocation AtLoc,
+   SourceLocation LParenLoc,
+   SourceLocation RParenLoc,
ObjCMethodDecl *Method,
ObjCMethodList &MethList) {
   ObjCMethodList *M = &MethList;
@@ -991,7 +993,8 @@ static bool HelperToDiagnoseMismatchedMe
   if (!Warned) {
 Warned = true;
 S.Diag(AtLoc, diag::warning_multiple_selectors)
-  << Method->getSelector();
+  << Method->getSelector() <<

r211610 - Add new debug kind LocTrackingOnly.

[Diego Novillo]

Author: dnovillo
Date: Tue Jun 24 12:02:17 2014
New Revision: 211610

URL: http://llvm.org/viewvc/llvm-project?rev=211610&view=rev
Log:
Add new debug kind LocTrackingOnly.

Summary:
This new debug emission kind supports emitting line location
information in all instructions, but stops code generation
from emitting debug info to the final output.

This mode is useful when the backend wants to track source
locations during code generation, but it does not want to
produce debug info. This is currently used by optimization
remarks (-Rpass, -Rpass-missed and -Rpass-analysis).

When one of the -Rpass flags is used, the front end will enable
location tracking, only if no other debug option is enabled.

To prevent debug information from being generated, a new debug
info kind LocTrackingOnly causes DIBuilder::createCompileUnit() to
not emit the llvm.dbg.cu annotation. This blocks final code generation
from generating debug info in the back end.

Depends on D4234.

Reviewers: echristo, dblaikie

Subscribers: cfe-commits

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

Modified:
cfe/trunk/docs/UsersManual.rst
cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
cfe/trunk/include/clang/Frontend/CodeGenOptions.def
cfe/trunk/include/clang/Frontend/CodeGenOptions.h
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/lib/CodeGen/CodeGenAction.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/Frontend/optimization-remark.c

Modified: cfe/trunk/docs/UsersManual.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=211610&r1=211609&r2=211610&view=diff
==
--- cfe/trunk/docs/UsersManual.rst (original)
+++ cfe/trunk/docs/UsersManual.rst Tue Jun 24 12:02:17 2014
@@ -577,12 +577,10 @@ feature.
 Current limitations
 ^^^
 
-1. For :option:`-Rpass` to provide source location information, you
-   need to enable debug line tables and column information. That is,
-   you need to add :option:`-gmlt` (or any of the debug-generating
-   flags) and :option:`-gcolumn-info`. If you omit these options,
-   every remark will be accompanied by a note stating that line number
-   information is missing.
+1. For :option:`-Rpass` to provide column information, you
+   need to enable it explicitly. That is, you need to add
+   :option:`-gcolumn-info`. If you omit this, remarks will only show
+   line information.
 
 2. Optimization remarks that refer to function names will display the
mangled name of the function. Since these remarks are emitted by the

Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td?rev=211610&r1=211609&r2=211610&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Tue Jun 24 
12:02:17 2014
@@ -41,9 +41,6 @@ def remark_fe_backend_optimization_remar
 InGroup, DefaultRemark;
 def remark_fe_backend_optimization_remark_analysis : Remark<"%0">, BackendInfo,
 InGroup, DefaultRemark;
-def note_fe_backend_optimization_remark_missing_loc : Note<"use "
-  "-gline-tables-only -gcolumn-info to track source location information "
-  "for this optimization remark">;
 def note_fe_backend_optimization_remark_invalid_loc : Note<"could "
   "not determine the original source location for %0:%1:%2">;
 

Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.def?rev=211610&r1=211609&r2=211610&view=diff
==
--- cfe/trunk/include/clang/Frontend/CodeGenOptions.def (original)
+++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def Tue Jun 24 12:02:17 2014
@@ -140,7 +140,7 @@ VALUE_CODEGENOPT(NumRegisterParameters,
 VALUE_CODEGENOPT(SSPBufferSize, 32, 0)
 
 /// The kind of generated debug info.
-ENUM_CODEGENOPT(DebugInfo, DebugInfoKind, 2, NoDebugInfo)
+ENUM_CODEGENOPT(DebugInfo, DebugInfoKind, 3, NoDebugInfo)
 
 /// Dwarf version.
 VALUE_CODEGENOPT(DwarfVersion, 3, 0)

Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.h?rev=211610&r1=211609&r2=211610&view=diff
==
--- cfe/trunk/include/clang/Frontend/CodeGenOptions.h (original)
+++ cfe/trunk/include/clang/Frontend/CodeGenOptions.h Tue Jun 24 12:02:17 2014
@@ -53,6 +53,13 @@ public:
   enum DebugInfoKind {
 NoDebugInfo,  /// Don't generate debug info.
 
+LocTrackingOnly,  /// Emit location information but do not generate
+  /// debug info in the output. This i

Re: r211604 - Use lowercase windows.h for mingw cross compilation.

[Alp Toker]

On 24/06/2014 19:53, Aaron Ballman wrote:

On Tue, Jun 24, 2014 at 12:18 PM, Logan Chien  wrote:

Author: logan
Date: Tue Jun 24 11:18:10 2014
New Revision: 211604

URL: http://llvm.org/viewvc/llvm-project?rev=211604&view=rev
Log:
Use lowercase windows.h for mingw cross compilation.

Modified:
 cfe/trunk/lib/Driver/WindowsToolChain.cpp

Modified: cfe/trunk/lib/Driver/WindowsToolChain.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/WindowsToolChain.cpp?rev=211604&r1=211603&r2=211604&view=diff
==
--- cfe/trunk/lib/Driver/WindowsToolChain.cpp (original)
+++ cfe/trunk/lib/Driver/WindowsToolChain.cpp Tue Jun 24 11:18:10 2014
@@ -30,7 +30,7 @@
#define WIN32_LEAN_AND_MEAN
#define NOGDI
#define NOMINMAX
-  #include 
+  #include 
  #endif

Why is windows.h being included here instead of WindowsSupport.h?


WindowsSupport.h is internal to LLVM at the moment. We probably don't 
need it for the limited uses of windows.h in the frontend.


Alp.




~Aaron
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


--
http://www.nuanti.com
the browser experts

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] MS ABI: Propagate class-level DLL attributes to class template specialization bases (PR11170)

[Hans Wennborg]

On Mon, Jun 23, 2014 at 6:06 PM, David Majnemer
 wrote:
> 
> Comment at: lib/Sema/SemaDeclCXX.cpp:1299
> @@ -1298,1 +1298,3 @@
>
> +static void propagateDLLAttrToBaseClassTemplate(
> +Sema &S, CXXRecordDecl *Class, Attr *ClassAttr,
> 
> Can this function get some comments?  I don't understand //why// it raises 
> diagnostics when it does or why it is checking for `TSK_Undeclared`.

Sorry about that. Yes, I'll add some comments about what's going on here.
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] MS ABI: Propagate class-level DLL attributes to class template specialization bases (PR11170)

[Hans Wennborg]

On Mon, Jun 23, 2014 at 5:28 PM, Hans Wennborg  wrote:
> On Mon, Jun 23, 2014 at 5:13 PM, Reid Kleckner  wrote:
>> Does your code handle explicit template specializations with inconsistent 
>> DLL attributes?  I'm thinking of this test case:
>>
>>   template  struct Foo { T get() { return {}; } };
>>   template <> struct __declspec(dllimport) Foo { int get() { return 42; 
>> } };
>>   struct __declspec(dllexport) Bar : Foo {
>> int baz() { return Foo::get(); }
>>   };
>>   Bar b;
>>
>> MSVC appears to import Foo::get(), but if I understand your code 
>> correctly, it will diagnose this.
>
> Interesting. I guess they don't try to propagate the attribute to
> explicit specializations, which makes sense. I'll see if I can make my
> patch not warn here, and check if this applies to partial
> specializations too.

I played with your example some more. It seems that if Foo is
explicitly specialized or explicit instantiated with a dll attribute,
they don't change that. But if it's explicitly instantiated or
specialized without an attribute, they will propagate Bar's attribute
to it. I'll change my code to not warn in the former case.
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [patch] Implementing -Wunused-local-typedefs

[Nico Weber]

On Tue, May 6, 2014 at 6:01 PM, Richard Smith  wrote:

>  def UnusedConstVariable : DiagGroup<"unused-const-variable">;
>  def UnusedVariable : DiagGroup<"unused-variable",
> [UnusedConstVariable]>;
> +def UnusedLocalTypedefs : DiagGroup<"unused-local-typedefs">;
>  def UnusedPropertyIvar :  DiagGroup<"unused-property-ivar">;
>
> I'm a little uncomfortable about this flag being plural and the others
> being singular. GCC compatible, you say? =(
>
>
> +def warn_unused_local_typedefs : Warning<"unused typedef %0">,
>
> This one should definitely be singular.
>
> Reformatting of lib/Parse/ParseExprCXX.cpp looks unrelated. Feel free to
> commit that separately.
>
> +if (TypedefDecl* TD = dyn_cast_or_null(SD))
>
> * should go on the right. Also, use 'auto' for a variable initialized from
> cast/dyn_cast/etc.
>
> Rather than calling setReferenced directly, please call
> Sema::MarkAnyDeclReferenced.
>
> +static bool ShouldDiagnoseUnusedDecl(const NamedDecl *D,
> + const DeclContext *DC) {
> [...]
> +  if (!DC->isFunctionOrMethod())
> +return false;
>
> Please document what 'DC' is here; it's really not obvious. But it seems
> to me that you can replace DC here and below with just a bool
> WithinFunction. You can also remove it entirely and check whether
> D->getDeclContext() is a function, method, or local class.
>
> +void Sema::DiagnoseUnusedDecl(const NamedDecl *D, const DeclContext *DC) {
> +  if (DC->isFunctionOrMethod())
> +if (const RecordDecl *RD = dyn_cast(D))
> +  for (auto *TmpD : RD->decls())
> +if (isa(TmpD) || isa(TmpD))
> +  DiagnoseUnusedDecl(cast(TmpD), DC);
>
> This would make more sense as a layer between ActOnPopScope and
> DiagnoseUnusedDecl. A comment explaining why we only do this within a
> function or method would help ("within a function or method, we defer these
> checks until the end of the surrounding scope").
>
> Also, this isn't necessarily correct in C++14, since a local type's
> members can be first used once we've already left the function:
>
>   auto f() {
> struct S { typedef int t; };
> return S();
>   }
>   auto x = f();
>   decltype(x)::t y;
>
> What happens if the local type is used as an argument to a function
> template, which in turn uses the typedef? Can we really diagnose this
> before end-of-TU?
>

Sneaky! gcc gets this wrong too (filed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61596). This kills the
"local-" part of the warning.

Is diagnosing this at end of TU fine? I vaguely recall that a concern with
-Wunused-private-field was that it forced deserialization of many ast nodes
(?); would that be a concern here too?


>
> +  else if (isa(D))  // TODO: Warn on unused c++11 aliases
> too?
> +DiagID = diag::warn_unused_local_typedefs;
>
> Yes, please change this to TypedefNameDecl (throughout the patch). It
> doesn't make sense to handle these differently, since one can be a
> redeclaration of the other.
>
> Index: lib/Sema/SemaTemplateInstantiateDecl.cpp
> ===
> --- lib/Sema/SemaTemplateInstantiateDecl.cpp (revision 207920)
> +++ lib/Sema/SemaTemplateInstantiateDecl.cpp (working copy)
> @@ -3651,7 +3651,7 @@
>if (!NewVar->isInvalidDecl() &&
>NewVar->getDeclContext()->isFunctionOrMethod() && !NewVar->isUsed()
> &&
>OldVar->getType()->isDependentType())
> -DiagnoseUnusedDecl(NewVar);
> +DiagnoseUnusedDecl(NewVar, NewVar->getDeclContext());
>
> Hmm, why do we diagnose unused decls from template instantiation at all?
>
> On Sat, May 3, 2014 at 10:37 PM, Nico Weber  wrote:
>
>> With one more setReferenced() call (in SemaCXXScopeSpec.cpp). This
>> version has successfully compiled several thousand files of chromium
>> (all that I've tried so far).
>>
>> On Sat, May 3, 2014 at 6:35 PM, Nico Weber  wrote:
>> > About point 2: The patch currently incorrectly warns on the "v" typedef
>> in:
>> >
>> >   template  struct V { typedef int iterator; };
>> >   void f() {
>> > typedef V v;
>> > v::iterator it;
>> >   }
>> >
>> > So there's at least one more place where I need to insert a
>> > setReferenced() I'll send an updated version once I found where, but
>> > I'm thankful for comments on the overall approach in the meantime too.
>> >
>> > On Sat, May 3, 2014 at 6:08 PM, Nico Weber  wrote:
>> >> (Forgot to say: This is also PR18265.)
>> >>
>> >> On Sat, May 3, 2014 at 6:07 PM, Nico Weber 
>> wrote:
>> >>> Hi,
>> >>>
>> >>> gcc has a warning -Wunused-local-typedefs that warns on unused local
>> >>> typedefs. Inspired by r207870, I thought it'd be nice if clang had
>> >>> this warning too. This warning requires the following three things:
>> >>>
>> >>>
>> >>> 1.) A bit to track if a typedef has been referenced.
>> >>>
>> >>> Decl already has isUsed and isReferenced, but they don't seem to be
>> >>> used for TypedefDecls, so I'm just using isReferenced on TypedefDecls
>> >>>

Re: [PATCH] Change loop unroll and vectorizer metadata prefix to 'llvm.loop.'

[Hal Finkel]

- Original Message -
> From: "Mark Heffernan" 
> To: "Hal Finkel" 
> Cc: llvm-comm...@cs.uiuc.edu, "cfe-commits" , "Pekka 
> Jääskeläinen"
> 
> Sent: Tuesday, June 24, 2014 11:18:33 AM
> Subject: Re: [PATCH] Change loop unroll and vectorizer metadata prefix to 
> 'llvm.loop.'
> 
> Thanks for the comments.  I'll add something to the release notes.
> 
> On Tue, Jun 24, 2014 at 3:52 AM, Hal Finkel  wrote:
> > Moreover, for metadata that was supported by the 3.4 release,
> > autoupgrade support should be added. Please do this before you
> > commit.
> 
> By autoupgrade do you mean be permissive about what is accepted?
>  That
> is, accept llvm.vectorizer.* and llvm.loop.vectorizer.* but only emit
> the llvm.loop form from the FE.  Or do you mean try to rename the
> metadata as soon as it parsed?  I can see how to do the first case
> (be
> permissive) easily, but for the second (rename metadata) do you have
> any suggestions for the best place to cut in (I'm fairly new to the
> code base)?

No, I mean the second. I believe that most of the current logic for this is in 
lib/IR/AutoUpgrade.cpp

 -Hal

> 
> Thanks!
> Mark
> 
> >
> >  -Hal
> >
> >>
> >> On Tue, Jun 24, 2014 at 12:30 AM, Mark Heffernan
> >> 
> >> wrote:
> >> > These patches rename the loop unrolling and loop vectorizer
> >> > metadata
> >> > such that they have a common 'llvm.loop.' prefix.  Metadata name
> >> > changes:
> >> >
> >> > llvm.vectorizer.* => llvm.loop.vectorizer.*
> >> > llvm.loopunroll.* => llvm.loop.unroll.*
> >> >
> >> > This was a suggestion from an earlier review
> >> > (http://reviews.llvm.org/D4090) which added the loop unrolling
> >> > metadata.  Two patches are attached.  One for front-end and one
> >> > for
> >> > optimizer.
> >> >
> >> > Mark
> >>
> >>
> >>
> >> --
> >> --PJ
> >> ___
> >> cfe-commits mailing list
> >> cfe-commits@cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> >>
> >
> > --
> > Hal Finkel
> > Assistant Computational Scientist
> > Leadership Computing Facility
> > Argonne National Laboratory
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Fix/Improve SourceRange of explicitly defaulted members

[Richard Smith]

OK, I suppose that makes some sense (`getSourceRange()` would then be invalid 
for implicit things, but `getLocation()` would be a location to use for 
diagnostics).

http://reviews.llvm.org/D4175



___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: r211604 - Use lowercase windows.h for mingw cross compilation.

[Aaron Ballman]

On Tue, Jun 24, 2014 at 12:18 PM, Logan Chien  wrote:
> Author: logan
> Date: Tue Jun 24 11:18:10 2014
> New Revision: 211604
>
> URL: http://llvm.org/viewvc/llvm-project?rev=211604&view=rev
> Log:
> Use lowercase windows.h for mingw cross compilation.
>
> Modified:
> cfe/trunk/lib/Driver/WindowsToolChain.cpp
>
> Modified: cfe/trunk/lib/Driver/WindowsToolChain.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/WindowsToolChain.cpp?rev=211604&r1=211603&r2=211604&view=diff
> ==
> --- cfe/trunk/lib/Driver/WindowsToolChain.cpp (original)
> +++ cfe/trunk/lib/Driver/WindowsToolChain.cpp Tue Jun 24 11:18:10 2014
> @@ -30,7 +30,7 @@
>#define WIN32_LEAN_AND_MEAN
>#define NOGDI
>#define NOMINMAX
> -  #include 
> +  #include 
>  #endif

Why is windows.h being included here instead of WindowsSupport.h?

~Aaron
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Add new debug kind LocTrackingOnly.

[Eric Christopher]

LGTM.

http://reviews.llvm.org/D4235



___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] [C++1z] static_assert declarations within an anonymous union

[Aaron Ballman]

On Tue, Jun 24, 2014 at 11:52 AM, Richard Smith  wrote:
> This should apply in all language modes, not just in C++1z. Is there an
> existing test file in which this test makes sense?
>
> Please also resolve PR20021 when you commit. Thanks!

Thanks! I've committed in r211606 (found an existing test case where
the test would make sense).

~Aaron
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r211606 - Allow static_assert inside an anonymous union; fixes PR20021 as well as implements C++ Issue 1940.

[Aaron Ballman]

Author: aaronballman
Date: Tue Jun 24 11:22:41 2014
New Revision: 211606

URL: http://llvm.org/viewvc/llvm-project?rev=211606&view=rev
Log:
Allow static_assert inside an anonymous union; fixes PR20021 as well as 
implements C++ Issue 1940.

Modified:
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/test/SemaCXX/anonymous-union-cxx11.cpp

Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=211606&r1=211605&r2=211606&view=diff
==
--- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDecl.cpp Tue Jun 24 11:22:41 2014
@@ -3754,6 +3754,8 @@ Decl *Sema::BuildAnonymousStructOrUnion(
 }
   } else if (isa(Mem)) {
 // Any access specifier is fine.
+  } else if (isa(Mem)) {
+// In C++1z, static_assert declarations are also fine.
   } else {
 // We have something that isn't a non-static data
 // member. Complain about it.

Modified: cfe/trunk/test/SemaCXX/anonymous-union-cxx11.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/anonymous-union-cxx11.cpp?rev=211606&r1=211605&r2=211606&view=diff
==
--- cfe/trunk/test/SemaCXX/anonymous-union-cxx11.cpp (original)
+++ cfe/trunk/test/SemaCXX/anonymous-union-cxx11.cpp Tue Jun 24 11:22:41 2014
@@ -12,3 +12,12 @@ namespace PR12866 {
 (void)sizeof(bar::member);
   }
 }
+
+namespace PR20021 {
+class C {
+  union {
+static_assert(true, "");
+int i;
+  };
+};
+}


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

r211604 - Use lowercase windows.h for mingw cross compilation.

[Logan Chien]

Author: logan
Date: Tue Jun 24 11:18:10 2014
New Revision: 211604

URL: http://llvm.org/viewvc/llvm-project?rev=211604&view=rev
Log:
Use lowercase windows.h for mingw cross compilation.

Modified:
cfe/trunk/lib/Driver/WindowsToolChain.cpp

Modified: cfe/trunk/lib/Driver/WindowsToolChain.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/WindowsToolChain.cpp?rev=211604&r1=211603&r2=211604&view=diff
==
--- cfe/trunk/lib/Driver/WindowsToolChain.cpp (original)
+++ cfe/trunk/lib/Driver/WindowsToolChain.cpp Tue Jun 24 11:18:10 2014
@@ -30,7 +30,7 @@
   #define WIN32_LEAN_AND_MEAN
   #define NOGDI
   #define NOMINMAX
-  #include 
+  #include 
 #endif
 
 using namespace clang::driver;


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Fix treatment of types defined in function prototype

[Richard Smith]

LGTM


Comment at: test/SemaCXX/type-definition-in-specifier.cpp:44
@@ +43,3 @@
+  void func4(struct t19018 {int qq;} x);  // expected-error{{cannot be defined 
in a parameter type}}
+  void func5(struct {int qq;} x); // expected-error{{cannot be defined in a 
parameter type}}
+};

Does this still work if you put something more complex into the struct 
definition? (For instance, if it tries to reference a member of the surrounding 
struct, or if it has member functions, or similar.)

http://reviews.llvm.org/D4145



___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Re: [PATCH] Proposal on how to fix temporary dtors.

[Jordan Rose]

On Jun 24, 2014, at 9:21 , Manuel Klimek  wrote:

> On Tue, Jun 24, 2014 at 6:08 PM, Jordan Rose  wrote:
> 
> On Jun 19, 2014, at 22:02 , Manuel Klimek  wrote:
> 
>> On Fri, Jun 20, 2014 at 5:28 AM, Jordan Rose  wrote:
>> 
>> On Jun 19, 2014, at 14:19 , Manuel Klimek  wrote:
>> 
>>> On Thu, Jun 19, 2014 at 6:30 PM, Jordan Rose  wrote:
>>> I think the algorithm makes sense. I'm not sure it's different, though, 
>>> than just passing up the first (or last) CXXBindTemporaryExpr visited for a 
>>> given expression, which would look like this:
>>> 
>>> // For a logical expression...
>>> VisitForTemporaryDtors(E->getLHS(), false, &LastBTE);
>>> const CXXBindTemporaryExpr *InnerBTE = nullptr;
>>> VisitForTemporaryDtors(E->getRHS(), false, &InnerBTE);
>>> InsertTempDtorDecisionBlock(InnerBTE);
>>> 
>>> Are there any cases that wouldn't cover?
>>> 
>>> Well, the problem is what to do if we don't have a BTE yet; if we only 
>>> wanted to pass one pointer, the semantics on function exit would need to be:
>>> if (BTE) { we have already found a BTE, no need to insert a new block when 
>>> we encounter the next }
>>> else { we have not yet found a BTE, so we need to insert a new block when 
>>> we find one }
>>> 
>>> The "unconditional" branch would only fit with the first part, so we would 
>>> need to somehow conjure non-null BTE for all unconditional entries, and 
>>> then afterwards know that this is a special value, because since we didn't 
>>> add an extra block (as we were running an unconditional case), we don't 
>>> need a decision block.
>>> I'd say that's a pretty strong argument that we at least need to pass the 
>>> CXXBindTemporaryExpr* and a bool IsConditional.
>>> 
>>> Now it's right that we don't need to remember the Succ when we hit the 
>>> conditional, and instead we could just always store the Succ when we enter 
>>> a recursive visitation for a conditional branch (we need to store the Succ 
>>> because we can have nested conditionals), but that seems to me like it 
>>> would distribute the logic through even more places, and thus undesirable.
>> 
>> My observation is that only certain expressions cause conditional branching, 
>> and that for these expressions you always need to introduce a new block if 
>> you find any destructors, say, in the RHS of a logical expression. So
>> 
>> 1. if you're in a non-conditional sub-expression, it doesn't matter whether 
>> there are temporaries or not; you don't need to insert a decision branch,
>> 2. if you're in a conditional sub-expression and there are no temporaries, 
>> you don't need to insert a decision branch,
>> 3. if you're in a conditional sub-expression and there are temporaries, you 
>> can use any temporary from that subexpression as the guard.
>> 
>> That is exactly the algorithm.
>>  
>> So it looks to me like the only information you have to pass up from 
>> traversing the sub-expressions is a BTE from that subexpression. Everything 
>> else can be handled at the point where you start processing that 
>> subexpression.
>> 
>> We have to pass the information down whether we are in a conditional part, 
>> so we know whether we have to start a new block when we hit the temporary.
>> 
>> If you're asking why we cannot start the block at the conditional point, the 
>> reason is that we cannot add it before we do the subexpression traversal 
>> (because we don't know yet whether there will be temporaries, and we don't 
>> want to add a block if there are no temporaries), and if we want to do it 
>> after the subexpression traversal, we'd somehow need to split blocks (as 
>> there can be nested conditionals, and multiple temporaries).
> 
> Hm. So in order to add the condition after the subexpression, we'd have to 
> always start a new block before the subexpression. That actually feels a bit 
> cleaner to me, though—start a new block, traverse the subexpression, and if 
> the block is empty, throw it away and go back to the block we had before. 
> Having less things in flight like that makes me a bit less nervous about 
> maintaining this code in the future. If you disagree, though, then what you 
> have looks about as clean as it can get.
> 
> The problem is when we hit nested branches, I think:
> b || (b || t())
> We hit the first ||, we add an empty block. We hit the second ||, we add an 
> empty block. We visit t() and add it to that empty block. Pop the stack, see 
> that we need a decision block - now we hook up the decision block to the 
> empty block. Pop the stack. Now we have to somehow wind the empty block out 
> of the generated structure, and hook it up correctly to the previous block. 
> I'd expect that to be less maintainable than the current solution.

Okay. I feel like the CFG builder already has to do things like this, but maybe 
not in this particular direction. Let's stick with what you have.

Jordan

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.

Re: [PATCH] Proposal on how to fix temporary dtors.

[Manuel Klimek]

On Tue, Jun 24, 2014 at 6:08 PM, Jordan Rose  wrote:

>
> On Jun 19, 2014, at 22:02 , Manuel Klimek  wrote:
>
> On Fri, Jun 20, 2014 at 5:28 AM, Jordan Rose 
> wrote:
>
>>
>> On Jun 19, 2014, at 14:19 , Manuel Klimek  wrote:
>>
>> On Thu, Jun 19, 2014 at 6:30 PM, Jordan Rose 
>> wrote:
>>
>>> I think the algorithm makes sense. I'm not sure it's different, though,
>>> than just passing up the first (or last) CXXBindTemporaryExpr visited for a
>>> given expression, which would look like this:
>>>
>>> // For a logical expression...
>>> VisitForTemporaryDtors(E->getLHS(), false, &LastBTE);
>>> const CXXBindTemporaryExpr *InnerBTE = nullptr;
>>> VisitForTemporaryDtors(E->getRHS(), false, &InnerBTE);
>>> InsertTempDtorDecisionBlock(InnerBTE);
>>>
>>> Are there any cases that wouldn't cover?
>>>
>>
>> Well, the problem is what to do if we don't have a BTE yet; if we only
>> wanted to pass one pointer, the semantics on function exit would need to be:
>> if (BTE) { we have already found a BTE, no need to insert a new block
>> when we encounter the next }
>> else { we have not yet found a BTE, so we need to insert a new block when
>> we find one }
>>
>> The "unconditional" branch would only fit with the first part, so we
>> would need to somehow conjure non-null BTE for all unconditional entries,
>> and then afterwards know that this is a special value, because since we
>> didn't add an extra block (as we were running an unconditional case), we
>> don't need a decision block.
>> I'd say that's a pretty strong argument that we at least need to pass the
>> CXXBindTemporaryExpr* and a bool IsConditional.
>>
>> Now it's right that we don't need to remember the Succ when we hit the
>> conditional, and instead we could just always store the Succ when we enter
>> a recursive visitation for a conditional branch (we need to store the Succ
>> because we can have nested conditionals), but that seems to me like it
>> would distribute the logic through even more places, and thus undesirable.
>>
>>
>> My observation is that only certain expressions cause conditional
>> branching, and that for these expressions you *always* need to introduce
>> a new block if you find any destructors, say, in the RHS of a logical
>> expression. So
>>
>> 1. if you're in a non-conditional sub-expression, it doesn't matter
>> whether there are temporaries or not; you don't need to insert a decision
>> branch,
>> 2. if you're in a conditional sub-expression and there are no
>> temporaries, you don't need to insert a decision branch,
>> 3. if you're in a conditional sub-expression and there are temporaries,
>> you can use any temporary from that subexpression as the guard.
>>
>
> That is exactly the algorithm.
>
>
>> So it looks to me like the only information you have to pass up from
>> traversing the sub-expressions is a BTE from that subexpression. Everything
>> else can be handled at the point where you start processing that
>> subexpression.
>>
>
> We have to pass the information down whether we are in a conditional part,
> so we know whether we have to start a new block when we hit the temporary.
>
> If you're asking why we cannot start the block at the conditional point,
> the reason is that we cannot add it before we do the subexpression
> traversal (because we don't know yet whether there will be temporaries, and
> we don't want to add a block if there are no temporaries), and if we want
> to do it after the subexpression traversal, we'd somehow need to split
> blocks (as there can be nested conditionals, and multiple temporaries).
>
>
> Hm. So in order to add the condition after the subexpression, we'd have to
> always start a new block *before* the subexpression. That actually feels
> a bit cleaner to me, though—start a new block, traverse the subexpression,
> and if the block is empty, throw it away and go back to the block we had
> before. Having less things in flight like that makes me a bit less nervous
> about maintaining this code in the future. If you disagree, though, then
> what you have looks about as clean as it can get.
>

The problem is when we hit nested branches, I think:
b || (b || t())
We hit the first ||, we add an empty block. We hit the second ||, we add an
empty block. We visit t() and add it to that empty block. Pop the stack,
see that we need a decision block - now we hook up the decision block to
the empty block. Pop the stack. Now we have to somehow wind the empty block
out of the generated structure, and hook it up correctly to the previous
block. I'd expect that to be less maintainable than the current solution.


> Uh, one other problem: even though we're now sharing branches for several
> temporaries, we still have to clean up state for every
> CXXBindTemporaryExpr. That should probably be moved out
> of processCleanupTemporaryBranch and into ProcessTemporaryDtor.
>

I'll do that.

Cheers,
/Manuel
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu

Re: [PATCH] Change loop unroll and vectorizer metadata prefix to 'llvm.loop.'

[Mark Heffernan]

Thanks for the comments.  I'll add something to the release notes.

On Tue, Jun 24, 2014 at 3:52 AM, Hal Finkel  wrote:
> Moreover, for metadata that was supported by the 3.4 release, autoupgrade 
> support should be added. Please do this before you commit.

By autoupgrade do you mean be permissive about what is accepted?  That
is, accept llvm.vectorizer.* and llvm.loop.vectorizer.* but only emit
the llvm.loop form from the FE.  Or do you mean try to rename the
metadata as soon as it parsed?  I can see how to do the first case (be
permissive) easily, but for the second (rename metadata) do you have
any suggestions for the best place to cut in (I'm fairly new to the
code base)?

Thanks!
Mark

>
>  -Hal
>
>>
>> On Tue, Jun 24, 2014 at 12:30 AM, Mark Heffernan 
>> wrote:
>> > These patches rename the loop unrolling and loop vectorizer
>> > metadata
>> > such that they have a common 'llvm.loop.' prefix.  Metadata name
>> > changes:
>> >
>> > llvm.vectorizer.* => llvm.loop.vectorizer.*
>> > llvm.loopunroll.* => llvm.loop.unroll.*
>> >
>> > This was a suggestion from an earlier review
>> > (http://reviews.llvm.org/D4090) which added the loop unrolling
>> > metadata.  Two patches are attached.  One for front-end and one for
>> > optimizer.
>> >
>> > Mark
>>
>>
>>
>> --
>> --PJ
>> ___
>> cfe-commits mailing list
>> cfe-commits@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits