date:20150919

Re: r245459 - According to i686 ABI, long double size on x86 is 12 bytes not 16 bytes.

2015-09-19 Thread Hal Finkel via cfe-commits

FYI: https://llvm.org/bugs/show_bug.cgi?id=24398 was just reopened pointing to 
a lack of resolution here.

 -Hal

- Original Message -
> From: "Yaron Keren via cfe-commits" 
> To: "Martell Malone" 
> Cc: "Richard Smith" , "cfe-commits" 
> 
> Sent: Friday, August 21, 2015 2:47:50 AM
> Subject: Re: r245459 - According to i686 ABI, long double size on x86 is 12 
> bytes not 16 bytes.
> 
> 
> 
> 
> The testcase from r245459 was not reverted and still in SVN.
> 
> 
> 
> 
> 
> 2015-08-21 2:05 GMT+03:00 Martell Malone < martellmal...@gmail.com >
> :
> 
> 
> 
> 
> 
> I feel very silly now.
> After testing the testcase again on svn it still works.
> It appears the OP was looking for this patch to go onto the 3.6
> branch and was applying my patch to that.
> 
> 
> I'll know in future to recheck the testcase afterwards myself in
> future.
> 
> 
> Apologies for the noise guys.
> 
> 
> Yaron I think the test case from r245459 would be useful to ensure it
> is never broken in the future?
> 
> Would you be able to recommit the test case?
> 
> 
> 
> Kind Regards
> 
> Martell
> 
> 
> 
> 
> 
> 
> 
> On Thu, Aug 20, 2015 at 3:57 PM, Martell Malone <
> martellmal...@gmail.com > wrote:
> 
> 
> 
> 
> 
> There is no testcase for PR24398 nor the OP reporting the problem was
> actually solved. Martell?
> I'm just re-looking through it now.
> 
> 
> X86TargetInfo sets LongDoubleFormat =
> &llvm::APFloat::x87DoubleExtended;
> X86_64TargetInfo then sets LongDoubleWidth = LongDoubleAlign = 128 ;
> X86_32 TargetInfo then sets LongDoubleWidth = 96 ; LongDoubleAlign =
> 32 ;
> 
> 
> From this I can see that the patch I committed actually doesn't
> change anything but only breaks mingw x86.
> 
> 
> I can only see these values changed in Microsoft*TargetInfo classes
> which is not a parent of MINGW
> 
> 
> When I submitted the patch I just wanted to explicitly set the values
> in MinGWX86_64TargetInfo to ensure it was in fact that.
> 
> It seemed as though it was not inheriting the value from the root
> parent class somehow.
> 
> 
> 
> I was told on irc that it did fix the bug which is even stranger.
> I'm actually at a bit of a loss as to what the proper fix to this is
> then.
> 
> Apologies for breaking mingw i686 long double.
> 
> 
> I will do up a test case and try to find the actual cause of the long
> double bug and reopen the issue.
> 
> 
> 
> 
> 
> On Thu, Aug 20, 2015 at 3:09 PM, Yaron Keren < yaron.ke...@gmail.com
> > wrote:
> 
> 
> 
> 
> Hi, I've just done this exactly this in r245618 (32 bit) and r245620
> (64 bits).
> 
> 
> mingw i686 long double values were correct before r245084 and wrong
> after it.
> mingw x86_64 long double values were not modified at all by r245084
> for the reason you stated, so I agree and do not see how this
> non-change can solve anything . There is no testcase for PR24398 nor
> the OP reporting the problem was actually solved. Martell?
> 
> 
> About PR24398, long double support was in clang long ago and b oth
> code examples compile and run correctly with current svn (without
> r245084) and gcc version 5.1.0 (i686-posix-dwarf-rev0, Built by
> MinGW-W64 project).
> It's not x86_64 but as said r245084 didn't actually modify x86_64
> configuration.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 2015-08-21 0:52 GMT+03:00 Richard Smith < rich...@metafoo.co.uk > :
> 
> 
> OK, so here's the problem:
> 
> 
> The right way to fix this seems to be to delete the assignments to
> LongDouble* from the MinGWX86_32TargetInfo constructor; the
> X86_32TargetInfo and X86TargetInfo base classes already set them to
> the right values. Likewise we can delete the assignments to
> LongDouble* from the MinGWX86_64TargetInfo constructor for the same
> reason.
> 
> 
> But... that completely reverts Martell's r245084, which apparently
> fixed PR24398. So you two need to figure out what the actual problem
> is here, and what the right fix is. r245084 didn't provide any test
> cases, and had no apparent effect other than to break long double
> for mingw32; did it really fix PR24398 (and if so, how)?
> 
> 
> 
> 
> 
> On Thu, Aug 20, 2015 at 2:27 PM, Yaron Keren < yaron.ke...@gmail.com
> > wrote:
> 
> 
> 
> 
> OK, based on testing, mingw i686 aligns long doubles to 4 bytes:
> 
> 
> 
> 
> sh-4.3$ cat < a.cpp
> #include 
> int main() {
> struct {
> char c[1];
> long double d;
> } s;
> std::cout<<&s.c< std::cout<<&s.d< }
> sh-4.3$ g++ a.cpp&&./a.exe
> 0x28fea0
> 0x28fea4
> 
> 
> I'll fix that.
> 
> 
> 
> 
> 
> 
> 
> 2015-08-21 0:13 GMT+03:00 Richard Smith < rich...@metafoo.co.uk > :
> 
> 
> 
> 
> 
> 
> On Wed, Aug 19, 2015 at 11:42 AM, Yaron Keren < yaron.ke...@gmail.com
> > wrote:
> 
> 
> 
> 
> Yes, it looks like a legacy issue. Documentation says so:
> 
> 
> 
> https://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/i386-and-x86-64-Options.html
> 
> 
> 
> -m96bit-long-double -m128bit-long-double These switches control the
> size of long double type. The i386 application binary interface
> specifies the size to be 96 bits, so -m96bit-long-double

Re: [PATCH] D12967: fix comments

2015-09-19 Thread Alexander Kornienko via cfe-commits

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

LG. Thanks for the patch!

Do you need me to commit this?


http://reviews.llvm.org/D12967



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

Re: [PATCH] D12967: fix comments

2015-09-19 Thread don hinton via cfe-commits

hintonda added a comment.

Yes, please.  thanks...


http://reviews.llvm.org/D12967



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

Re: r245459 - According to i686 ABI, long double size on x86 is 12 bytes not 16 bytes.

2015-09-19 Thread Yaron Keren via cfe-commits

Thanks, I have replied there.

2015-09-19 13:33 GMT+03:00 Hal Finkel :

> FYI: https://llvm.org/bugs/show_bug.cgi?id=24398 was just reopened
> pointing to a lack of resolution here.
>
>  -Hal
>
> - Original Message -
> > From: "Yaron Keren via cfe-commits" 
> > To: "Martell Malone" 
> > Cc: "Richard Smith" , "cfe-commits" <
> cfe-commits@lists.llvm.org>
> > Sent: Friday, August 21, 2015 2:47:50 AM
> > Subject: Re: r245459 - According to i686 ABI, long double size on x86 is
> 12 bytes not 16 bytes.
> >
> >
> >
> >
> > The testcase from r245459 was not reverted and still in SVN.
> >
> >
> >
> >
> >
> > 2015-08-21 2:05 GMT+03:00 Martell Malone < martellmal...@gmail.com >
> > :
> >
> >
> >
> >
> >
> > I feel very silly now.
> > After testing the testcase again on svn it still works.
> > It appears the OP was looking for this patch to go onto the 3.6
> > branch and was applying my patch to that.
> >
> >
> > I'll know in future to recheck the testcase afterwards myself in
> > future.
> >
> >
> > Apologies for the noise guys.
> >
> >
> > Yaron I think the test case from r245459 would be useful to ensure it
> > is never broken in the future?
> >
> > Would you be able to recommit the test case?
> >
> >
> >
> > Kind Regards
> >
> > Martell
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Aug 20, 2015 at 3:57 PM, Martell Malone <
> > martellmal...@gmail.com > wrote:
> >
> >
> >
> >
> >
> > There is no testcase for PR24398 nor the OP reporting the problem was
> > actually solved. Martell?
> > I'm just re-looking through it now.
> >
> >
> > X86TargetInfo sets LongDoubleFormat =
> > &llvm::APFloat::x87DoubleExtended;
> > X86_64TargetInfo then sets LongDoubleWidth = LongDoubleAlign = 128 ;
> > X86_32 TargetInfo then sets LongDoubleWidth = 96 ; LongDoubleAlign =
> > 32 ;
> >
> >
> > From this I can see that the patch I committed actually doesn't
> > change anything but only breaks mingw x86.
> >
> >
> > I can only see these values changed in Microsoft*TargetInfo classes
> > which is not a parent of MINGW
> >
> >
> > When I submitted the patch I just wanted to explicitly set the values
> > in MinGWX86_64TargetInfo to ensure it was in fact that.
> >
> > It seemed as though it was not inheriting the value from the root
> > parent class somehow.
> >
> >
> >
> > I was told on irc that it did fix the bug which is even stranger.
> > I'm actually at a bit of a loss as to what the proper fix to this is
> > then.
> >
> > Apologies for breaking mingw i686 long double.
> >
> >
> > I will do up a test case and try to find the actual cause of the long
> > double bug and reopen the issue.
> >
> >
> >
> >
> >
> > On Thu, Aug 20, 2015 at 3:09 PM, Yaron Keren < yaron.ke...@gmail.com
> > > wrote:
> >
> >
> >
> >
> > Hi, I've just done this exactly this in r245618 (32 bit) and r245620
> > (64 bits).
> >
> >
> > mingw i686 long double values were correct before r245084 and wrong
> > after it.
> > mingw x86_64 long double values were not modified at all by r245084
> > for the reason you stated, so I agree and do not see how this
> > non-change can solve anything . There is no testcase for PR24398 nor
> > the OP reporting the problem was actually solved. Martell?
> >
> >
> > About PR24398, long double support was in clang long ago and b oth
> > code examples compile and run correctly with current svn (without
> > r245084) and gcc version 5.1.0 (i686-posix-dwarf-rev0, Built by
> > MinGW-W64 project).
> > It's not x86_64 but as said r245084 didn't actually modify x86_64
> > configuration.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 2015-08-21 0:52 GMT+03:00 Richard Smith < rich...@metafoo.co.uk > :
> >
> >
> > OK, so here's the problem:
> >
> >
> > The right way to fix this seems to be to delete the assignments to
> > LongDouble* from the MinGWX86_32TargetInfo constructor; the
> > X86_32TargetInfo and X86TargetInfo base classes already set them to
> > the right values. Likewise we can delete the assignments to
> > LongDouble* from the MinGWX86_64TargetInfo constructor for the same
> > reason.
> >
> >
> > But... that completely reverts Martell's r245084, which apparently
> > fixed PR24398. So you two need to figure out what the actual problem
> > is here, and what the right fix is. r245084 didn't provide any test
> > cases, and had no apparent effect other than to break long double
> > for mingw32; did it really fix PR24398 (and if so, how)?
> >
> >
> >
> >
> >
> > On Thu, Aug 20, 2015 at 2:27 PM, Yaron Keren < yaron.ke...@gmail.com
> > > wrote:
> >
> >
> >
> >
> > OK, based on testing, mingw i686 aligns long doubles to 4 bytes:
> >
> >
> >
> >
> > sh-4.3$ cat < a.cpp
> > #include 
> > int main() {
> > struct {
> > char c[1];
> > long double d;
> > } s;
> > std::cout<<&s.c< > std::cout<<&s.d< > }
> > sh-4.3$ g++ a.cpp&&./a.exe
> > 0x28fea0
> > 0x28fea4
> >
> >
> > I'll fix that.
> >
> >
> >
> >
> >
> >
> >
> > 2015-08-21 0:13 GMT+03:00 Richard Smith < rich...@metafoo.co.uk > :
> >
> >
> >
> >
> >
> >
> > On Wed, Aug 19, 2015 at 11:42 AM, Yaron

r245459 - According to i686 ABI, long double size on x86 is 12 bytes not 16 bytes.

2015-09-19 Thread Martell Malone via cfe-commits

For reference It was raised again here also
https://github.com/Alexpux/MINGW-packages/issues/722


"that is extended from X86TargetInfo
Which sets LongDoubleFormat = &llvm::APFloat::x87DoubleExtended;"

On Saturday, September 19, 2015, Yaron Keren > wrote:

> Thanks, I have replied there.
>
> 2015-09-19 13:33 GMT+03:00 Hal Finkel :
>
>> FYI: https://llvm.org/bugs/show_bug.cgi?id=24398 was just reopened
>> pointing to a lack of resolution here.
>>
>>  -Hal
>>
>> - Original Message -
>> > From: "Yaron Keren via cfe-commits" 
>> > To: "Martell Malone" 
>> > Cc: "Richard Smith" , "cfe-commits" <
>> cfe-commits@lists.llvm.org>
>> > Sent: Friday, August 21, 2015 2:47:50 AM
>> > Subject: Re: r245459 - According to i686 ABI, long double size on x86
>> is 12 bytes not 16 bytes.
>> >
>> >
>> >
>> >
>> > The testcase from r245459 was not reverted and still in SVN.
>> >
>> >
>> >
>> >
>> >
>> > 2015-08-21 2:05 GMT+03:00 Martell Malone < martellmal...@gmail.com >
>> > :
>> >
>> >
>> >
>> >
>> >
>> > I feel very silly now.
>> > After testing the testcase again on svn it still works.
>> > It appears the OP was looking for this patch to go onto the 3.6
>> > branch and was applying my patch to that.
>> >
>> >
>> > I'll know in future to recheck the testcase afterwards myself in
>> > future.
>> >
>> >
>> > Apologies for the noise guys.
>> >
>> >
>> > Yaron I think the test case from r245459 would be useful to ensure it
>> > is never broken in the future?
>> >
>> > Would you be able to recommit the test case?
>> >
>> >
>> >
>> > Kind Regards
>> >
>> > Martell
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Thu, Aug 20, 2015 at 3:57 PM, Martell Malone <
>> > martellmal...@gmail.com > wrote:
>> >
>> >
>> >
>> >
>> >
>> > There is no testcase for PR24398 nor the OP reporting the problem was
>> > actually solved. Martell?
>> > I'm just re-looking through it now.
>> >
>> >
>> > X86TargetInfo sets LongDoubleFormat =
>> > &llvm::APFloat::x87DoubleExtended;
>> > X86_64TargetInfo then sets LongDoubleWidth = LongDoubleAlign = 128 ;
>> > X86_32 TargetInfo then sets LongDoubleWidth = 96 ; LongDoubleAlign =
>> > 32 ;
>> >
>> >
>> > From this I can see that the patch I committed actually doesn't
>> > change anything but only breaks mingw x86.
>> >
>> >
>> > I can only see these values changed in Microsoft*TargetInfo classes
>> > which is not a parent of MINGW
>> >
>> >
>> > When I submitted the patch I just wanted to explicitly set the values
>> > in MinGWX86_64TargetInfo to ensure it was in fact that.
>> >
>> > It seemed as though it was not inheriting the value from the root
>> > parent class somehow.
>> >
>> >
>> >
>> > I was told on irc that it did fix the bug which is even stranger.
>> > I'm actually at a bit of a loss as to what the proper fix to this is
>> > then.
>> >
>> > Apologies for breaking mingw i686 long double.
>> >
>> >
>> > I will do up a test case and try to find the actual cause of the long
>> > double bug and reopen the issue.
>> >
>> >
>> >
>> >
>> >
>> > On Thu, Aug 20, 2015 at 3:09 PM, Yaron Keren < yaron.ke...@gmail.com
>> > > wrote:
>> >
>> >
>> >
>> >
>> > Hi, I've just done this exactly this in r245618 (32 bit) and r245620
>> > (64 bits).
>> >
>> >
>> > mingw i686 long double values were correct before r245084 and wrong
>> > after it.
>> > mingw x86_64 long double values were not modified at all by r245084
>> > for the reason you stated, so I agree and do not see how this
>> > non-change can solve anything . There is no testcase for PR24398 nor
>> > the OP reporting the problem was actually solved. Martell?
>> >
>> >
>> > About PR24398, long double support was in clang long ago and b oth
>> > code examples compile and run correctly with current svn (without
>> > r245084) and gcc version 5.1.0 (i686-posix-dwarf-rev0, Built by
>> > MinGW-W64 project).
>> > It's not x86_64 but as said r245084 didn't actually modify x86_64
>> > configuration.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > 2015-08-21 0:52 GMT+03:00 Richard Smith < rich...@metafoo.co.uk > :
>> >
>> >
>> > OK, so here's the problem:
>> >
>> >
>> > The right way to fix this seems to be to delete the assignments to
>> > LongDouble* from the MinGWX86_32TargetInfo constructor; the
>> > X86_32TargetInfo and X86TargetInfo base classes already set them to
>> > the right values. Likewise we can delete the assignments to
>> > LongDouble* from the MinGWX86_64TargetInfo constructor for the same
>> > reason.
>> >
>> >
>> > But... that completely reverts Martell's r245084, which apparently
>> > fixed PR24398. So you two need to figure out what the actual problem
>> > is here, and what the right fix is. r245084 didn't provide any test
>> > cases, and had no apparent effect other than to break long double
>> > for mingw32; did it really fix PR24398 (and if so, how)?
>> >
>> >
>> >
>> >
>> >
>> > On Thu, Aug 20, 2015 at 2:27 PM, Yaron Keren < yaron.ke...@gmail.com
>> > > wrot

Re: r245459 - According to i686 ABI, long double size on x86 is 12 bytes not 16 bytes.

2015-09-19 Thread Yaron Keren via cfe-commits

I can't reproduce sizeof = 12 when targetting 64 bits, it is 16
(LongDoubleWidth = 128) and have been this way since r55036.  It may be
that both 32 bit mingw and 64 bit mingw are installed and clang is
targetting the 32 bits while gcc targets 64 bits.



2015-09-19 15:24 GMT+03:00 Martell Malone :

> For reference It was raised again here also
> https://github.com/Alexpux/MINGW-packages/issues/722
> 
>
> "that is extended from X86TargetInfo
> Which sets LongDoubleFormat = &llvm::APFloat::x87DoubleExtended;"
>
> On Saturday, September 19, 2015, Yaron Keren 
> wrote:
>
>> Thanks, I have replied there.
>>
>> 2015-09-19 13:33 GMT+03:00 Hal Finkel :
>>
>>> FYI: https://llvm.org/bugs/show_bug.cgi?id=24398 was just reopened
>>> pointing to a lack of resolution here.
>>>
>>>  -Hal
>>>
>>> - Original Message -
>>> > From: "Yaron Keren via cfe-commits" 
>>> > To: "Martell Malone" 
>>> > Cc: "Richard Smith" , "cfe-commits" <
>>> cfe-commits@lists.llvm.org>
>>> > Sent: Friday, August 21, 2015 2:47:50 AM
>>> > Subject: Re: r245459 - According to i686 ABI, long double size on x86
>>> is 12 bytes not 16 bytes.
>>> >
>>> >
>>> >
>>> >
>>> > The testcase from r245459 was not reverted and still in SVN.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > 2015-08-21 2:05 GMT+03:00 Martell Malone < martellmal...@gmail.com >
>>> > :
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > I feel very silly now.
>>> > After testing the testcase again on svn it still works.
>>> > It appears the OP was looking for this patch to go onto the 3.6
>>> > branch and was applying my patch to that.
>>> >
>>> >
>>> > I'll know in future to recheck the testcase afterwards myself in
>>> > future.
>>> >
>>> >
>>> > Apologies for the noise guys.
>>> >
>>> >
>>> > Yaron I think the test case from r245459 would be useful to ensure it
>>> > is never broken in the future?
>>> >
>>> > Would you be able to recommit the test case?
>>> >
>>> >
>>> >
>>> > Kind Regards
>>> >
>>> > Martell
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Thu, Aug 20, 2015 at 3:57 PM, Martell Malone <
>>> > martellmal...@gmail.com > wrote:
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > There is no testcase for PR24398 nor the OP reporting the problem was
>>> > actually solved. Martell?
>>> > I'm just re-looking through it now.
>>> >
>>> >
>>> > X86TargetInfo sets LongDoubleFormat =
>>> > &llvm::APFloat::x87DoubleExtended;
>>> > X86_64TargetInfo then sets LongDoubleWidth = LongDoubleAlign = 128 ;
>>> > X86_32 TargetInfo then sets LongDoubleWidth = 96 ; LongDoubleAlign =
>>> > 32 ;
>>> >
>>> >
>>> > From this I can see that the patch I committed actually doesn't
>>> > change anything but only breaks mingw x86.
>>> >
>>> >
>>> > I can only see these values changed in Microsoft*TargetInfo classes
>>> > which is not a parent of MINGW
>>> >
>>> >
>>> > When I submitted the patch I just wanted to explicitly set the values
>>> > in MinGWX86_64TargetInfo to ensure it was in fact that.
>>> >
>>> > It seemed as though it was not inheriting the value from the root
>>> > parent class somehow.
>>> >
>>> >
>>> >
>>> > I was told on irc that it did fix the bug which is even stranger.
>>> > I'm actually at a bit of a loss as to what the proper fix to this is
>>> > then.
>>> >
>>> > Apologies for breaking mingw i686 long double.
>>> >
>>> >
>>> > I will do up a test case and try to find the actual cause of the long
>>> > double bug and reopen the issue.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Thu, Aug 20, 2015 at 3:09 PM, Yaron Keren < yaron.ke...@gmail.com
>>> > > wrote:
>>> >
>>> >
>>> >
>>> >
>>> > Hi, I've just done this exactly this in r245618 (32 bit) and r245620
>>> > (64 bits).
>>> >
>>> >
>>> > mingw i686 long double values were correct before r245084 and wrong
>>> > after it.
>>> > mingw x86_64 long double values were not modified at all by r245084
>>> > for the reason you stated, so I agree and do not see how this
>>> > non-change can solve anything . There is no testcase for PR24398 nor
>>> > the OP reporting the problem was actually solved. Martell?
>>> >
>>> >
>>> > About PR24398, long double support was in clang long ago and b oth
>>> > code examples compile and run correctly with current svn (without
>>> > r245084) and gcc version 5.1.0 (i686-posix-dwarf-rev0, Built by
>>> > MinGW-W64 project).
>>> > It's not x86_64 but as said r245084 didn't actually modify x86_64
>>> > configuration.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > 2015-08-21 0:52 GMT+03:00 Richard Smith < rich...@metafoo.co.uk > :
>>> >
>>> >
>>> > OK, so here's the problem:
>>> >
>>> >
>>> > The right way to fix this seems to be to delete the assignments to
>>> > LongDouble* from the MinGWX86_32TargetInfo constructor; the
>>> > X86_32TargetInfo and X86TargetInfo base classes already set them to
>>> > the right values. Likewise we can delete the assignments to
>>> > LongDouble* from the MinGWX86_64TargetInfo constructor for the same
>>> > rea

Re: [PATCH] D12961: Update clang-tidy documentation.

2015-09-19 Thread Alexander Kornienko via cfe-commits

alexfh added a comment.

Thank you for converting the docs!

Some of the usages of "transform" and "transformation" in these docs refer to 
"clang-modernize transform", and, thus, should be replaced with "check" or 
"clang-tidy check". I tried to find all such places. See comments.



Comment at: 
clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-loop-convert.rst:226
@@ +225,3 @@
+
+While most of the transform's risk analysis is dedicated to determining whether
+the iterator or container was modified within the loop, it is possible to

s/transform/check/


Comment at: 
clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-loop-convert.rst:234
@@ +233,3 @@
+level since calling a member function of the container is considered `risky`.
+The transform cannot identify expressions associated with the container that 
are
+different than the one used in the loop header, therefore the transformation

s/transform/check/


Comment at: 
clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-pass-by-value.rst:7
@@ +6,3 @@
+directly by value, instead of by const-reference, and then copy. This
+transformation allows the compiler to take care of choosing the best way to
+construct the copy.

s/transformation/check/


Comment at: 
clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-pass-by-value.rst:37
@@ +36,3 @@
+Since `std::move()` is a library function declared in `` it may be
+necessary to add this include. The transform will add the include directive 
when
+necessary.

s/transform/check/


Comment at: 
clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-replace-auto-ptr.rst:29
@@ +28,3 @@
+Since `std::move()` is a library function declared in `` it may be
+necessary to add this include. The transform will add the include directive 
when
+necessary.

s/transform/check/


Comment at: 
clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-replace-auto-ptr.rst:35
@@ +34,3 @@
+* If headers modification is not activated or if a header is not allowed to be
+  changed this transform will produce broken code (compilation error), where 
the
+  the headers' code will stay unchanged while the code using them will be

s/transform/check/


Comment at: 
clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-use-auto.rst:56
@@ +55,3 @@
+
+The transform will only replace iterator type-specifiers when all of the
+following conditions are satisfied:

s/transform/check/


Comment at: 
clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-use-auto.rst:131
@@ +130,3 @@
+=
+* If the initializer is an explicit conversion constructor, the transform will
+  not replace the type specifier even though it would be safe to do so.

s/transform/check/


Comment at: 
clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-use-nullptr.rst:41
@@ +40,3 @@
+
+By default this transform will only replace the ``NULL`` macro and will skip 
any
+user-defined macros that behaves like ``NULL``. The user can use the

s/transform/check/


Repository:
  rL LLVM

http://reviews.llvm.org/D12961



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

r248090 - [clang-tidy] Fix example comments.

2015-09-19 Thread Alexander Kornienko via cfe-commits

Author: alexfh
Date: Sat Sep 19 08:01:57 2015
New Revision: 248090

URL: http://llvm.org/viewvc/llvm-project?rev=248090&view=rev
Log:
[clang-tidy] Fix example comments.

Patch by don hinton!

Differential revision: http://reviews.llvm.org/D12967


Modified:
cfe/trunk/include/clang/Tooling/CommonOptionsParser.h

Modified: cfe/trunk/include/clang/Tooling/CommonOptionsParser.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Tooling/CommonOptionsParser.h?rev=248090&r1=248089&r2=248090&view=diff
==
--- cfe/trunk/include/clang/Tooling/CommonOptionsParser.h (original)
+++ cfe/trunk/include/clang/Tooling/CommonOptionsParser.h Sat Sep 19 08:01:57 
2015
@@ -42,6 +42,7 @@ namespace tooling {
 /// \code
 /// #include "clang/Frontend/FrontendActions.h"
 /// #include "clang/Tooling/CommonOptionsParser.h"
+/// #include "clang/Tooling/Tooling.h"
 /// #include "llvm/Support/CommandLine.h"
 ///
 /// using namespace clang::tooling;
@@ -56,8 +57,8 @@ namespace tooling {
 /// int main(int argc, const char **argv) {
 ///   CommonOptionsParser OptionsParser(argc, argv, MyToolCategory);
 ///   ClangTool Tool(OptionsParser.getCompilations(),
-///  OptionsParser.getSourcePathListi());
-///   return Tool.run(newFrontendActionFactory());
+///  OptionsParser.getSourcePathList());
+///   return Tool.run(newFrontendActionFactory().get());
 /// }
 /// \endcode
 class CommonOptionsParser {


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

Re: [PATCH] D12967: fix comments

2015-09-19 Thread Alexander Kornienko via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL248090: [clang-tidy] Fix example comments. (authored by 
alexfh).

Changed prior to commit:
  http://reviews.llvm.org/D12967?vs=35091&id=35164#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D12967

Files:
  cfe/trunk/include/clang/Tooling/CommonOptionsParser.h

Index: cfe/trunk/include/clang/Tooling/CommonOptionsParser.h
===
--- cfe/trunk/include/clang/Tooling/CommonOptionsParser.h
+++ cfe/trunk/include/clang/Tooling/CommonOptionsParser.h
@@ -42,6 +42,7 @@
 /// \code
 /// #include "clang/Frontend/FrontendActions.h"
 /// #include "clang/Tooling/CommonOptionsParser.h"
+/// #include "clang/Tooling/Tooling.h"
 /// #include "llvm/Support/CommandLine.h"
 ///
 /// using namespace clang::tooling;
@@ -56,8 +57,8 @@
 /// int main(int argc, const char **argv) {
 ///   CommonOptionsParser OptionsParser(argc, argv, MyToolCategory);
 ///   ClangTool Tool(OptionsParser.getCompilations(),
-///  OptionsParser.getSourcePathListi());
-///   return Tool.run(newFrontendActionFactory());
+///  OptionsParser.getSourcePathList());
+///   return Tool.run(newFrontendActionFactory().get());
 /// }
 /// \endcode
 class CommonOptionsParser {


Index: cfe/trunk/include/clang/Tooling/CommonOptionsParser.h
===
--- cfe/trunk/include/clang/Tooling/CommonOptionsParser.h
+++ cfe/trunk/include/clang/Tooling/CommonOptionsParser.h
@@ -42,6 +42,7 @@
 /// \code
 /// #include "clang/Frontend/FrontendActions.h"
 /// #include "clang/Tooling/CommonOptionsParser.h"
+/// #include "clang/Tooling/Tooling.h"
 /// #include "llvm/Support/CommandLine.h"
 ///
 /// using namespace clang::tooling;
@@ -56,8 +57,8 @@
 /// int main(int argc, const char **argv) {
 ///   CommonOptionsParser OptionsParser(argc, argv, MyToolCategory);
 ///   ClangTool Tool(OptionsParser.getCompilations(),
-///  OptionsParser.getSourcePathListi());
-///   return Tool.run(newFrontendActionFactory());
+///  OptionsParser.getSourcePathList());
+///   return Tool.run(newFrontendActionFactory().get());
 /// }
 /// \endcode
 class CommonOptionsParser {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12835: [X86][SSE] Replace 128-bit SSE41 PMOVSX intrinsics with native IR

2015-09-19 Thread Simon Pilgrim via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL248092: [X86][SSE] Replace 128-bit SSE41 PMOVSX intrinsics 
with native IR (authored by RKSimon).

Changed prior to commit:
  http://reviews.llvm.org/D12835?vs=34646&id=35167#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D12835

Files:
  cfe/trunk/include/clang/Basic/BuiltinsX86.def
  cfe/trunk/lib/Headers/smmintrin.h
  cfe/trunk/test/CodeGen/builtins-x86.c
  cfe/trunk/test/CodeGen/sse41-builtins.c

Index: cfe/trunk/include/clang/Basic/BuiltinsX86.def
===
--- cfe/trunk/include/clang/Basic/BuiltinsX86.def
+++ cfe/trunk/include/clang/Basic/BuiltinsX86.def
@@ -376,12 +376,6 @@
 TARGET_BUILTIN(__builtin_ia32_pminsd128, "V4iV4iV4i", "", "sse4.1")
 TARGET_BUILTIN(__builtin_ia32_pminud128, "V4iV4iV4i", "", "sse4.1")
 TARGET_BUILTIN(__builtin_ia32_pminuw128, "V8sV8sV8s", "", "sse4.1")
-TARGET_BUILTIN(__builtin_ia32_pmovsxbd128, "V4iV16c", "", "sse4.1")
-TARGET_BUILTIN(__builtin_ia32_pmovsxbq128, "V2LLiV16c", "", "sse4.1")
-TARGET_BUILTIN(__builtin_ia32_pmovsxbw128, "V8sV16c", "", "sse4.1")
-TARGET_BUILTIN(__builtin_ia32_pmovsxdq128, "V2LLiV4i", "", "sse4.1")
-TARGET_BUILTIN(__builtin_ia32_pmovsxwd128, "V4iV8s", "", "sse4.1")
-TARGET_BUILTIN(__builtin_ia32_pmovsxwq128, "V2LLiV8s", "", "sse4.1")
 TARGET_BUILTIN(__builtin_ia32_pmovzxbd128, "V4iV16c", "", "sse4.1")
 TARGET_BUILTIN(__builtin_ia32_pmovzxbq128, "V2LLiV16c", "", "sse4.1")
 TARGET_BUILTIN(__builtin_ia32_pmovzxbw128, "V8sV16c", "", "sse4.1")
Index: cfe/trunk/test/CodeGen/builtins-x86.c
===
--- cfe/trunk/test/CodeGen/builtins-x86.c
+++ cfe/trunk/test/CodeGen/builtins-x86.c
@@ -372,12 +372,6 @@
   tmp_V4i = __builtin_ia32_pminsd128(tmp_V4i, tmp_V4i);
   tmp_V4i = __builtin_ia32_pminud128(tmp_V4i, tmp_V4i);
   tmp_V8s = __builtin_ia32_pminuw128(tmp_V8s, tmp_V8s);
-  tmp_V4i = __builtin_ia32_pmovsxbd128(tmp_V16c);
-  tmp_V2LLi = __builtin_ia32_pmovsxbq128(tmp_V16c);
-  tmp_V8s = __builtin_ia32_pmovsxbw128(tmp_V16c);
-  tmp_V2LLi = __builtin_ia32_pmovsxdq128(tmp_V4i);
-  tmp_V4i = __builtin_ia32_pmovsxwd128(tmp_V8s);
-  tmp_V2LLi = __builtin_ia32_pmovsxwq128(tmp_V8s);
   tmp_V4i = __builtin_ia32_pmovzxbd128(tmp_V16c);
   tmp_V2LLi = __builtin_ia32_pmovzxbq128(tmp_V16c);
   tmp_V8s = __builtin_ia32_pmovzxbw128(tmp_V16c);
Index: cfe/trunk/test/CodeGen/sse41-builtins.c
===
--- cfe/trunk/test/CodeGen/sse41-builtins.c
+++ cfe/trunk/test/CodeGen/sse41-builtins.c
@@ -86,42 +86,42 @@
 
 __m128i test_mm_cvtepi8_epi16(__m128i a) {
   // CHECK-LABEL: test_mm_cvtepi8_epi16
-  // CHECK: call <8 x i16> @llvm.x86.sse41.pmovsxbw(<16 x i8> {{.*}})
+  // CHECK: sext <8 x i8> {{.*}} to <8 x i16>
   // CHECK-ASM: pmovsxbw %xmm{{.*}}, %xmm{{.*}}
   return _mm_cvtepi8_epi16(a);
 }
 
 __m128i test_mm_cvtepi8_epi32(__m128i a) {
   // CHECK-LABEL: test_mm_cvtepi8_epi32
-  // CHECK: call <4 x i32> @llvm.x86.sse41.pmovsxbd(<16 x i8> {{.*}})
+  // CHECK: sext <4 x i8> {{.*}} to <4 x i32>
   // CHECK-ASM: pmovsxbd %xmm{{.*}}, %xmm{{.*}}
   return _mm_cvtepi8_epi32(a);
 }
 
 __m128i test_mm_cvtepi8_epi64(__m128i a) {
   // CHECK-LABEL: test_mm_cvtepi8_epi64
-  // CHECK: call <2 x i64> @llvm.x86.sse41.pmovsxbq(<16 x i8> {{.*}})
+  // CHECK: sext <2 x i8> {{.*}} to <2 x i64>
   // CHECK-ASM: pmovsxbq %xmm{{.*}}, %xmm{{.*}}
   return _mm_cvtepi8_epi64(a);
 }
 
 __m128i test_mm_cvtepi16_epi32(__m128i a) {
   // CHECK-LABEL: test_mm_cvtepi16_epi32
-  // CHECK: call <4 x i32> @llvm.x86.sse41.pmovsxwd(<8 x i16> {{.*}})
+  // CHECK: sext <4 x i16> {{.*}} to <4 x i32>
   // CHECK-ASM: pmovsxwd %xmm{{.*}}, %xmm{{.*}}
   return _mm_cvtepi16_epi32(a);
 }
 
 __m128i test_mm_cvtepi16_epi64(__m128i a) {
   // CHECK-LABEL: test_mm_cvtepi16_epi64
-  // CHECK: call <2 x i64> @llvm.x86.sse41.pmovsxwq(<8 x i16> {{.*}})
+  // CHECK: sext <2 x i16> {{.*}} to <2 x i64>
   // CHECK-ASM: pmovsxwq %xmm{{.*}}, %xmm{{.*}}
   return _mm_cvtepi16_epi64(a);
 }
 
 __m128i test_mm_cvtepi32_epi64(__m128i a) {
   // CHECK-LABEL: test_mm_cvtepi32_epi64
-  // CHECK: call <2 x i64> @llvm.x86.sse41.pmovsxdq(<4 x i32> {{.*}})
+  // CHECK: sext <2 x i32> {{.*}} to <2 x i64>
   // CHECK-ASM: pmovsxdq %xmm{{.*}}, %xmm{{.*}}
   return _mm_cvtepi32_epi64(a);
 }
Index: cfe/trunk/lib/Headers/smmintrin.h
===
--- cfe/trunk/lib/Headers/smmintrin.h
+++ cfe/trunk/lib/Headers/smmintrin.h
@@ -286,37 +286,37 @@
 static __inline__ __m128i __DEFAULT_FN_ATTRS
 _mm_cvtepi8_epi16(__m128i __V)
 {
-  return (__m128i) __builtin_ia32_pmovsxbw128((__v16qi) __V);
+  return (__m128i)__builtin_convertvector(__builtin_shufflevector((__v16qi)__V, (__v16qi)__V, 0, 1, 2, 3, 4, 5, 6, 7), __v8hi);
 }
 
 static __inline__ __m128i __DEFAULT_FN_ATTRS
 _mm_cvtepi8_epi32(__m128i __V)
 {
-  return (__m128i) __builtin_ia32

r248092 - [X86][SSE] Replace 128-bit SSE41 PMOVSX intrinsics with native IR

2015-09-19 Thread Simon Pilgrim via cfe-commits

Author: rksimon
Date: Sat Sep 19 10:12:38 2015
New Revision: 248092

URL: http://llvm.org/viewvc/llvm-project?rev=248092&view=rev
Log:
[X86][SSE] Replace 128-bit SSE41 PMOVSX intrinsics with native IR

128-bit vector integer sign extensions correctly lower to the pmovsx 
instructions even for debug builds.

This patch removes the builtins and reimplements the _mm_cvtepi*_epi* 
intrinsics __using builtin_shufflevector (to extract the bottom most subvector) 
and __builtin_convertvector (to actually perform the sign extension).

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

Modified:
cfe/trunk/include/clang/Basic/BuiltinsX86.def
cfe/trunk/lib/Headers/smmintrin.h
cfe/trunk/test/CodeGen/builtins-x86.c
cfe/trunk/test/CodeGen/sse41-builtins.c

Modified: cfe/trunk/include/clang/Basic/BuiltinsX86.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsX86.def?rev=248092&r1=248091&r2=248092&view=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsX86.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsX86.def Sat Sep 19 10:12:38 2015
@@ -376,12 +376,6 @@ TARGET_BUILTIN(__builtin_ia32_pminsb128,
 TARGET_BUILTIN(__builtin_ia32_pminsd128, "V4iV4iV4i", "", "sse4.1")
 TARGET_BUILTIN(__builtin_ia32_pminud128, "V4iV4iV4i", "", "sse4.1")
 TARGET_BUILTIN(__builtin_ia32_pminuw128, "V8sV8sV8s", "", "sse4.1")
-TARGET_BUILTIN(__builtin_ia32_pmovsxbd128, "V4iV16c", "", "sse4.1")
-TARGET_BUILTIN(__builtin_ia32_pmovsxbq128, "V2LLiV16c", "", "sse4.1")
-TARGET_BUILTIN(__builtin_ia32_pmovsxbw128, "V8sV16c", "", "sse4.1")
-TARGET_BUILTIN(__builtin_ia32_pmovsxdq128, "V2LLiV4i", "", "sse4.1")
-TARGET_BUILTIN(__builtin_ia32_pmovsxwd128, "V4iV8s", "", "sse4.1")
-TARGET_BUILTIN(__builtin_ia32_pmovsxwq128, "V2LLiV8s", "", "sse4.1")
 TARGET_BUILTIN(__builtin_ia32_pmovzxbd128, "V4iV16c", "", "sse4.1")
 TARGET_BUILTIN(__builtin_ia32_pmovzxbq128, "V2LLiV16c", "", "sse4.1")
 TARGET_BUILTIN(__builtin_ia32_pmovzxbw128, "V8sV16c", "", "sse4.1")

Modified: cfe/trunk/lib/Headers/smmintrin.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/smmintrin.h?rev=248092&r1=248091&r2=248092&view=diff
==
--- cfe/trunk/lib/Headers/smmintrin.h (original)
+++ cfe/trunk/lib/Headers/smmintrin.h Sat Sep 19 10:12:38 2015
@@ -286,37 +286,37 @@ _mm_cmpeq_epi64(__m128i __V1, __m128i __
 static __inline__ __m128i __DEFAULT_FN_ATTRS
 _mm_cvtepi8_epi16(__m128i __V)
 {
-  return (__m128i) __builtin_ia32_pmovsxbw128((__v16qi) __V);
+  return 
(__m128i)__builtin_convertvector(__builtin_shufflevector((__v16qi)__V, 
(__v16qi)__V, 0, 1, 2, 3, 4, 5, 6, 7), __v8hi);
 }
 
 static __inline__ __m128i __DEFAULT_FN_ATTRS
 _mm_cvtepi8_epi32(__m128i __V)
 {
-  return (__m128i) __builtin_ia32_pmovsxbd128((__v16qi) __V);
+  return 
(__m128i)__builtin_convertvector(__builtin_shufflevector((__v16qi)__V, 
(__v16qi)__V, 0, 1, 2, 3), __v4si);
 }
 
 static __inline__ __m128i __DEFAULT_FN_ATTRS
 _mm_cvtepi8_epi64(__m128i __V)
 {
-  return (__m128i) __builtin_ia32_pmovsxbq128((__v16qi) __V);
+  return 
(__m128i)__builtin_convertvector(__builtin_shufflevector((__v16qi)__V, 
(__v16qi)__V, 0, 1), __v2di);
 }
 
 static __inline__ __m128i __DEFAULT_FN_ATTRS
 _mm_cvtepi16_epi32(__m128i __V)
 {
-  return (__m128i) __builtin_ia32_pmovsxwd128((__v8hi) __V);
+  return (__m128i)__builtin_convertvector(__builtin_shufflevector((__v8hi)__V, 
(__v8hi)__V, 0, 1, 2, 3), __v4si);
 }
 
 static __inline__ __m128i __DEFAULT_FN_ATTRS
 _mm_cvtepi16_epi64(__m128i __V)
 {
-  return (__m128i) __builtin_ia32_pmovsxwq128((__v8hi)__V);
+  return (__m128i)__builtin_convertvector(__builtin_shufflevector((__v8hi)__V, 
(__v8hi)__V, 0, 1), __v2di);
 }
 
 static __inline__ __m128i __DEFAULT_FN_ATTRS
 _mm_cvtepi32_epi64(__m128i __V)
 {
-  return (__m128i) __builtin_ia32_pmovsxdq128((__v4si)__V);
+  return (__m128i)__builtin_convertvector(__builtin_shufflevector((__v4si)__V, 
(__v4si)__V, 0, 1), __v2di);
 }
 
 /* SSE4 Packed Integer Zero-Extension.  */

Modified: cfe/trunk/test/CodeGen/builtins-x86.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/builtins-x86.c?rev=248092&r1=248091&r2=248092&view=diff
==
--- cfe/trunk/test/CodeGen/builtins-x86.c (original)
+++ cfe/trunk/test/CodeGen/builtins-x86.c Sat Sep 19 10:12:38 2015
@@ -372,12 +372,6 @@ void f0() {
   tmp_V4i = __builtin_ia32_pminsd128(tmp_V4i, tmp_V4i);
   tmp_V4i = __builtin_ia32_pminud128(tmp_V4i, tmp_V4i);
   tmp_V8s = __builtin_ia32_pminuw128(tmp_V8s, tmp_V8s);
-  tmp_V4i = __builtin_ia32_pmovsxbd128(tmp_V16c);
-  tmp_V2LLi = __builtin_ia32_pmovsxbq128(tmp_V16c);
-  tmp_V8s = __builtin_ia32_pmovsxbw128(tmp_V16c);
-  tmp_V2LLi = __builtin_ia32_pmovsxdq128(tmp_V4i);
-  tmp_V4i = __builtin_ia32_pmovsxwd128(tmp_V8s);
-  tmp_V2LLi = __builtin_ia32_pmovsxwq128(tmp_V8s);

[PATCH] D12993: [analyzer] Add TK_EntireMemSpace invalidation trait.

2015-09-19 Thread Devin Coughlin via cfe-commits

dcoughlin created this revision.
dcoughlin added reviewers: krememek, zaks.anna.
dcoughlin added subscribers: cfe-commits, seaneveson.

This is a patch to support Sean Eveson's work on loop widening. It adds a new
TK_EntireMemSpace invalidation trait that, when applied to a MemSpaceRegion, 
indicates
that the entire memory space should be invalidated.

Clients would add this trait before invalidating. For example:

```
RegionAndSymbolInvalidationTraits ITraits;
ITraits.setTrait(MRMgr.getStackLocalsRegion(STC),
 RegionAndSymbolInvalidationTraits::TK_EntireMemSpace);

```

This patch updates the existing logic invalidating global memspace regions for 
calls to
additionally handle arbitrary memspaces. When generating initial clusters during
cluster analysis we will now add a cluster to the worklist if the memspace for 
its
base is marked with TK_EntireMemSpace.

The patch also moves the logic for invalidating globals from ClusterAnalysis to
invalidateRegionsWorker so that it is not shared with removeDeadBindingsWorker.

There are no explicit tests with this patch -- but when applied to Sean's patch 
in
http://reviews.llvm.org/D12358 and after updating his code to set the trait,
the failing tests in that patch now pass.

http://reviews.llvm.org/D12993

Files:
  include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h
  lib/StaticAnalyzer/Core/RegionStore.cpp

Index: lib/StaticAnalyzer/Core/RegionStore.cpp
===
--- lib/StaticAnalyzer/Core/RegionStore.cpp
+++ lib/StaticAnalyzer/Core/RegionStore.cpp
@@ -650,35 +650,25 @@
 
   RegionBindingsRef B;
 
-private:
-  GlobalsFilterKind GlobalsFilter;
 
 protected:
   const ClusterBindings *getCluster(const MemRegion *R) {
 return B.lookup(R);
   }
 
-  /// Returns true if the memory space of the given region is one of the global
-  /// regions specially included at the start of analysis.
-  bool isInitiallyIncludedGlobalRegion(const MemRegion *R) {
-switch (GlobalsFilter) {
-case GFK_None:
-  return false;
-case GFK_SystemOnly:
-  return isa(R->getMemorySpace());
-case GFK_All:
-  return isa(R->getMemorySpace());
-}
-
-llvm_unreachable("unknown globals filter");
+  /// Returns true if all clusters in the given memspace should be initially
+  /// included in the cluster analysis. Subclasses may provide their
+  /// own implementation.
+  bool includeEntireMemorySpace(const MemRegion *Base) {
+return false;
   }
 
 public:
   ClusterAnalysis(RegionStoreManager &rm, ProgramStateManager &StateMgr,
-  RegionBindingsRef b, GlobalsFilterKind GFK)
+  RegionBindingsRef b )
 : RM(rm), Ctx(StateMgr.getContext()),
   svalBuilder(StateMgr.getSValBuilder()),
-  B(b), GlobalsFilter(GFK) {}
+  B(b) {}
 
   RegionBindingsRef getRegionBindings() const { return B; }
 
@@ -696,8 +686,9 @@
   assert(!Cluster.isEmpty() && "Empty clusters should be removed");
   static_cast(this)->VisitAddedToCluster(Base, Cluster);
 
-  // If this is an interesting global region, add it the work list up front.
-  if (isInitiallyIncludedGlobalRegion(Base))
+  // If the base's memspace should be entirely invalidated, add the cluster
+  // to the workspace up front.
+  if (static_cast(this)->includeEntireMemorySpace(Base))
 AddToWorkList(WorkListElement(Base), &Cluster);
 }
   }
@@ -941,6 +932,7 @@
   InvalidatedSymbols &IS;
   RegionAndSymbolInvalidationTraits &ITraits;
   StoreManager::InvalidatedRegions *Regions;
+  GlobalsFilterKind GlobalsFilter;
 public:
   invalidateRegionsWorker(RegionStoreManager &rm,
   ProgramStateManager &stateMgr,
@@ -951,12 +943,21 @@
   RegionAndSymbolInvalidationTraits &ITraitsIn,
   StoreManager::InvalidatedRegions *r,
   GlobalsFilterKind GFK)
-: ClusterAnalysis(rm, stateMgr, b, GFK),
-  Ex(ex), Count(count), LCtx(lctx), IS(is), ITraits(ITraitsIn), Regions(r){}
+: ClusterAnalysis(rm, stateMgr, b),
+  Ex(ex), Count(count), LCtx(lctx), IS(is), ITraits(ITraitsIn), Regions(r),
+  GlobalsFilter(GFK) {}
 
   void VisitCluster(const MemRegion *baseR, const ClusterBindings *C);
   void VisitBinding(SVal V);
-};
+
+  /// Returns true if all clusters in the memory space for \p Base should be
+  /// be invalidated.
+  bool includeEntireMemorySpace(const MemRegion *Base);
+
+  /// Returns true if the memory space of the given region is one of the global
+  /// regions specially included at the start of invalidation.
+  bool isInitiallyIncludedGlobalRegion(const MemRegion *R);
+  };
 }
 
 void invalidateRegionsWorker::VisitBinding(SVal V) {
@@ -1085,6 +1086,29 @@
   B = B.addBinding(baseR, BindingKey::Direct, V);
 }
 
+bool invalidateRegionsWorker::isInitiallyIncludedGlobalRegion(
+const MemRegion *R) {
+  switch (GlobalsFilter) {
+  case GFK_None:
+return f

Re: [PATCH] D12358: [Analyzer] Handling constant bound loops

2015-09-19 Thread Devin Coughlin via cfe-commits

dcoughlin added a comment.

There is a patch to add memspace region invalidation in 
http://reviews.llvm.org/D12993.


http://reviews.llvm.org/D12358



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

r248094 - Driver: tweak ARM target feature calculation

2015-09-19 Thread Saleem Abdulrasool via cfe-commits

Author: compnerd
Date: Sat Sep 19 13:19:44 2015
New Revision: 248094

URL: http://llvm.org/viewvc/llvm-project?rev=248094&view=rev
Log:
Driver: tweak ARM target feature calculation

Rather than using re-calculating the effective triple, thread the already
calculated value down into AddARMTargetArgs.  This avoids both recreating the
triple, as well as re-parsing the triple as it was already done in the previous
frame.

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

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=248094&r1=248093&r2=248094&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Sat Sep 19 13:19:44 2015
@@ -851,15 +851,9 @@ static void getARMTargetFeatures(const D
 Features.push_back("+no-movt");
 }
 
-void Clang::AddARMTargetArgs(const ArgList &Args, ArgStringList &CmdArgs,
- bool KernelOrKext) const {
-  const Driver &D = getToolChain().getDriver();
-  // Get the effective triple, which takes into account the deployment target.
-  std::string TripleStr = getToolChain().ComputeEffectiveClangTriple(Args);
-  llvm::Triple Triple(TripleStr);
-
+void Clang::AddARMTargetArgs(const llvm::Triple &Triple, const ArgList &Args,
+ ArgStringList &CmdArgs, bool KernelOrKext) const {
   // Select the ABI to use.
-  //
   // FIXME: Support -meabi.
   // FIXME: Parts of this are duplicated in the backend, unify this somehow.
   const char *ABIName = nullptr;
@@ -898,7 +892,8 @@ void Clang::AddARMTargetArgs(const ArgLi
   CmdArgs.push_back(ABIName);
 
   // Determine floating point ABI from the options & target defaults.
-  arm::FloatABI ABI = arm::getARMFloatABI(D, Args, Triple);
+  arm::FloatABI ABI =
+  arm::getARMFloatABI(getToolChain().getDriver(), Args, Triple);
   if (ABI == arm::FloatABI::Soft) {
 // Floating point operations and argument passing are soft.
 // FIXME: This changes CPP defines, we need -target-soft-float.
@@ -3676,7 +3671,8 @@ void Clang::ConstructJob(Compilation &C,
   case llvm::Triple::armeb:
   case llvm::Triple::thumb:
   case llvm::Triple::thumbeb:
-AddARMTargetArgs(Args, CmdArgs, KernelOrKext);
+// Use the effective triple, which takes into account the deployment 
target.
+AddARMTargetArgs(Triple, Args, CmdArgs, KernelOrKext);
 break;
 
   case llvm::Triple::aarch64:

Modified: cfe/trunk/lib/Driver/Tools.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.h?rev=248094&r1=248093&r2=248094&view=diff
==
--- cfe/trunk/lib/Driver/Tools.h (original)
+++ cfe/trunk/lib/Driver/Tools.h Sat Sep 19 13:19:44 2015
@@ -59,7 +59,8 @@ private:
 
   void AddAArch64TargetArgs(const llvm::opt::ArgList &Args,
 llvm::opt::ArgStringList &CmdArgs) const;
-  void AddARMTargetArgs(const llvm::opt::ArgList &Args,
+  void AddARMTargetArgs(const llvm::Triple &Triple,
+const llvm::opt::ArgList &Args,
 llvm::opt::ArgStringList &CmdArgs,
 bool KernelOrKext) const;
   void AddARM64TargetArgs(const llvm::opt::ArgList &Args,


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

Re: [PATCH] D12797: Refactor LoopConvertCheck.

2015-09-19 Thread Manuel Klimek via cfe-commits

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

lg


http://reviews.llvm.org/D12797



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

r248095 - Driver: alter the getARMFloatABI signature

2015-09-19 Thread Saleem Abdulrasool via cfe-commits

Author: compnerd
Date: Sat Sep 19 15:40:16 2015
New Revision: 248095

URL: http://llvm.org/viewvc/llvm-project?rev=248095&view=rev
Log:
Driver: alter the getARMFloatABI signature

This changes getARMFloatABI to use the ToolChain and Args instead of Driver,
Args, Triple.  Although this pushes the Triple calculation/parsing into the
function itself, it enables the use of the function for a future change.  The
reason to sink the triple calculation here is to avoid threading the Triple
through multiple layers in a future change.

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

Modified: cfe/trunk/lib/Driver/ToolChains.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp?rev=248095&r1=248094&r2=248095&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains.cpp Sat Sep 19 15:40:16 2015
@@ -855,10 +855,10 @@ void MachO::AddLinkRuntimeLibArgs(const
   // with different libraries for each member of the product { static, PIC } x
   // { hard-float, soft-float }
   llvm::SmallString<32> CompilerRT = StringRef("libclang_rt.");
-  CompilerRT += (tools::arm::getARMFloatABI(getDriver(), Args, getTriple()) ==
-tools::arm::FloatABI::Hard)
-? "hard"
-: "soft";
+  CompilerRT +=
+  (tools::arm::getARMFloatABI(*this, Args) == tools::arm::FloatABI::Hard)
+  ? "hard"
+  : "soft";
   CompilerRT += Args.hasArg(options::OPT_fPIC) ? "_pic.a" : "_static.a";
 
   AddLinkRuntimeLib(Args, CmdArgs, CompilerRT, false, true);

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=248095&r1=248094&r2=248095&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Sat Sep 19 15:40:16 2015
@@ -574,8 +574,9 @@ static bool useAAPCSForMachO(const llvm:
 
 // Select the float ABI as determined by -msoft-float, -mhard-float, and
 // -mfloat-abi=.
-arm::FloatABI arm::getARMFloatABI(const Driver &D, const ArgList &Args,
-  const llvm::Triple &Triple) {
+arm::FloatABI arm::getARMFloatABI(const ToolChain &TC, const ArgList &Args) {
+  const Driver &D = TC.getDriver();
+  const llvm::Triple Triple(TC.ComputeEffectiveClangTriple(Args));
   auto SubArch = getARMSubArchVersionNumber(Triple);
   arm::FloatABI ABI = FloatABI::Invalid;
   if (Arg *A =
@@ -663,13 +664,16 @@ arm::FloatABI arm::getARMFloatABI(const
   return ABI;
 }
 
-static void getARMTargetFeatures(const Driver &D, const llvm::Triple &Triple,
+static void getARMTargetFeatures(const ToolChain &TC,
+ const llvm::Triple &Triple,
  const ArgList &Args,
  std::vector &Features,
  bool ForAS) {
+  const Driver &D = TC.getDriver();
+
   bool KernelOrKext =
   Args.hasArg(options::OPT_mkernel, options::OPT_fapple_kext);
-  arm::FloatABI ABI = arm::getARMFloatABI(D, Args, Triple);
+  arm::FloatABI ABI = arm::getARMFloatABI(TC, Args);
   const Arg *WaCPU = nullptr, *WaFPU = nullptr;
   const Arg *WaHDiv = nullptr, *WaArch = nullptr;
 
@@ -892,8 +896,7 @@ void Clang::AddARMTargetArgs(const llvm:
   CmdArgs.push_back(ABIName);
 
   // Determine floating point ABI from the options & target defaults.
-  arm::FloatABI ABI =
-  arm::getARMFloatABI(getToolChain().getDriver(), Args, Triple);
+  arm::FloatABI ABI = arm::getARMFloatABI(getToolChain(), Args);
   if (ABI == arm::FloatABI::Soft) {
 // Floating point operations and argument passing are soft.
 // FIXME: This changes CPP defines, we need -target-soft-float.
@@ -2108,9 +2111,10 @@ static void getWebAssemblyTargetFeatures
   }
 }
 
-static void getTargetFeatures(const Driver &D, const llvm::Triple &Triple,
+static void getTargetFeatures(const ToolChain &TC, const llvm::Triple &Triple,
   const ArgList &Args, ArgStringList &CmdArgs,
   bool ForAS) {
+  const Driver &D = TC.getDriver();
   std::vector Features;
   switch (Triple.getArch()) {
   default:
@@ -2126,7 +2130,7 @@ static void getTargetFeatures(const Driv
   case llvm::Triple::armeb:
   case llvm::Triple::thumb:
   case llvm::Triple::thumbeb:
-getARMTargetFeatures(D, Triple, Args, Features, ForAS);
+getARMTargetFeatures(TC, Triple, Args, Features, ForAS);
 break;
 
   case llvm::Triple::ppc:
@@ -3660,7 +3664,7 @@ void Clang::ConstructJob(Compilation &C,
   }
 
   // Add the target features
-  getTargetFeatures(D, Triple, Args, CmdArgs, false);
+  getTargetFeatures(getToolChain(), Triple, Args, CmdArgs, false);
 
   // Add target specific flags.
   switch (getToolChain().getArch()) {

r248100 - Convert two loops to range-based loops. No behavior change.

2015-09-19 Thread Nico Weber via cfe-commits

Author: nico
Date: Sat Sep 19 16:36:51 2015
New Revision: 248100

URL: http://llvm.org/viewvc/llvm-project?rev=248100&view=rev
Log:
Convert two loops to range-based loops. No behavior change.

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

Modified: cfe/trunk/lib/Driver/Driver.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=248100&r1=248099&r2=248100&view=diff
==
--- cfe/trunk/lib/Driver/Driver.cpp (original)
+++ cfe/trunk/lib/Driver/Driver.cpp Sat Sep 19 16:36:51 2015
@@ -951,8 +951,8 @@ static bool ContainsCompileOrAssembleAct
   isa(A))
 return true;
 
-  for (Action::const_iterator it = A->begin(), ie = A->end(); it != ie; ++it)
-if (ContainsCompileOrAssembleAction(*it))
+  for (const Action *Input : *A)
+if (ContainsCompileOrAssembleAction(Input))
   return true;
 
   return false;
@@ -993,9 +993,7 @@ void Driver::BuildUniversalActions(const
 
   // Add in arch bindings for every top level action, as well as lipo and
   // dsymutil steps if needed.
-  for (unsigned i = 0, e = SingleActions.size(); i != e; ++i) {
-Action *Act = SingleActions[i];
-
+  for (Action* Act : SingleActions) {
 // Make sure we can lipo this kind of output. If not (and it is an actual
 // output) then we disallow, since we can't create an output file with the
 // right name without overwriting it. We could remove this oddity by just


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

r248101 - Further simplify the interface of PCHContainerGenerator

2015-09-19 Thread Adrian Prantl via cfe-commits

Author: adrian
Date: Sat Sep 19 16:42:52 2015
New Revision: 248101

URL: http://llvm.org/viewvc/llvm-project?rev=248101&view=rev
Log:
Further simplify the interface of PCHContainerGenerator
by dropping the const qualifier on the CI.

NFC

Modified:
cfe/trunk/include/clang/CodeGen/ObjectFilePCHContainerOperations.h
cfe/trunk/include/clang/Frontend/PCHContainerOperations.h
cfe/trunk/lib/CodeGen/ObjectFilePCHContainerOperations.cpp
cfe/trunk/lib/Frontend/FrontendActions.cpp
cfe/trunk/lib/Frontend/PCHContainerOperations.cpp

Modified: cfe/trunk/include/clang/CodeGen/ObjectFilePCHContainerOperations.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/CodeGen/ObjectFilePCHContainerOperations.h?rev=248101&r1=248100&r2=248101&view=diff
==
--- cfe/trunk/include/clang/CodeGen/ObjectFilePCHContainerOperations.h 
(original)
+++ cfe/trunk/include/clang/CodeGen/ObjectFilePCHContainerOperations.h Sat Sep 
19 16:42:52 2015
@@ -23,9 +23,8 @@ class ObjectFilePCHContainerWriter : pub
   /// PCHGenerator that produces a wrapper file format
   /// that also contains full debug info for the module.
   std::unique_ptr CreatePCHContainerGenerator(
-  DiagnosticsEngine &Diags, const CompilerInstance &CI,
-  const std::string &MainFileName, const std::string &OutputFileName,
-  llvm::raw_pwrite_stream *OS,
+  CompilerInstance &CI, const std::string &MainFileName,
+  const std::string &OutputFileName, llvm::raw_pwrite_stream *OS,
   std::shared_ptr Buffer) const override;
 };
 

Modified: cfe/trunk/include/clang/Frontend/PCHContainerOperations.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/PCHContainerOperations.h?rev=248101&r1=248100&r2=248101&view=diff
==
--- cfe/trunk/include/clang/Frontend/PCHContainerOperations.h (original)
+++ cfe/trunk/include/clang/Frontend/PCHContainerOperations.h Sat Sep 19 
16:42:52 2015
@@ -46,9 +46,9 @@ public:
   /// PCHGenerator that produces a wrapper file format containing a
   /// serialized AST bitstream.
   virtual std::unique_ptr CreatePCHContainerGenerator(
-  DiagnosticsEngine &Diags, const CompilerInstance &CI,
-  const std::string &MainFileName, const std::string &OutputFileName,
-  llvm::raw_pwrite_stream *OS, std::shared_ptr Buffer) const = 
0;
+  CompilerInstance &CI, const std::string &MainFileName,
+  const std::string &OutputFileName, llvm::raw_pwrite_stream *OS,
+  std::shared_ptr Buffer) const = 0;
 };
 
 /// This abstract interface provides operations for unwrapping
@@ -73,9 +73,8 @@ class RawPCHContainerWriter : public PCH
   /// Return an ASTConsumer that can be chained with a
   /// PCHGenerator that writes the module to a flat file.
   std::unique_ptr CreatePCHContainerGenerator(
-  DiagnosticsEngine &Diags, const CompilerInstance &CI,
-  const std::string &MainFileName, const std::string &OutputFileName,
-  llvm::raw_pwrite_stream *OS,
+  CompilerInstance &CI, const std::string &MainFileName,
+  const std::string &OutputFileName, llvm::raw_pwrite_stream *OS,
   std::shared_ptr Buffer) const override;
 };
 

Modified: cfe/trunk/lib/CodeGen/ObjectFilePCHContainerOperations.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/ObjectFilePCHContainerOperations.cpp?rev=248101&r1=248100&r2=248101&view=diff
==
--- cfe/trunk/lib/CodeGen/ObjectFilePCHContainerOperations.cpp (original)
+++ cfe/trunk/lib/CodeGen/ObjectFilePCHContainerOperations.cpp Sat Sep 19 
16:42:52 2015
@@ -116,12 +116,12 @@ class PCHContainerGenerator : public AST
   };
 
 public:
-  PCHContainerGenerator(DiagnosticsEngine &diags, const CompilerInstance &CI,
-const std::string &MainFileName,
+  PCHContainerGenerator(CompilerInstance &CI, const std::string &MainFileName,
 const std::string &OutputFileName,
 raw_pwrite_stream *OS,
 std::shared_ptr Buffer)
-  : Diags(diags), Ctx(nullptr), HeaderSearchOpts(CI.getHeaderSearchOpts()),
+  : Diags(CI.getDiagnostics()), Ctx(nullptr),
+HeaderSearchOpts(CI.getHeaderSearchOpts()),
 PreprocessorOpts(CI.getPreprocessorOpts()),
 TargetOpts(CI.getTargetOpts()), LangOpts(CI.getLangOpts()), OS(OS),
 Buffer(Buffer) {
@@ -252,10 +252,10 @@ public:
 
 std::unique_ptr
 ObjectFilePCHContainerWriter::CreatePCHContainerGenerator(
-DiagnosticsEngine &Diags, const CompilerInstance &CI,
-const std::string &MainFileName, const std::string &OutputFileName,
-llvm::raw_pwrite_stream *OS, std::shared_ptr Buffer) const {
-  return llvm::make_unique(Diags, CI, MainFileName,
+CompilerInstance &CI, const std::string &MainFileName,
+const std::string &OutputFileName, llvm::raw_p

[PATCH] D12996: Driver: support ARM/HF on a single toolchain

2015-09-19 Thread Saleem Abdulrasool via cfe-commits

compnerd created this revision.
compnerd added a reviewer: rengolin.
compnerd added a subscriber: cfe-commits.
Herald added subscribers: srhines, danalbert, tberghammer, rengolin, aemerson.

ARM EABI adds target attributes to the object file.  Amongst the attributes that
are emitted is the VFP argument passing (Hard vs Soft).  The linker is
responsible for checking these attributes and erroring on mismatches.  This
causes problems for the compiler-rt builtins when targeting both hard and
soft.  Because both of these options name the builtins compiler-rt component
the same (libclang_rt.builtins-arm.a or libclang_rt.builtins-arm-android).  GCC
is able to get away with this as it does one target per toolchain.  This
changes the naming convention for the ARM compiler-rt builtins to differentiate
between HF and Soft.  Although this means that compiler-rt may be duplicated, it
enables supporting both variants from a single toolchain.  A similar approach is
taken by the Darwin toolchain, naming the library to differentiate between the
calling conventions.

http://reviews.llvm.org/D12996

Files:
  lib/Driver/SanitizerArgs.cpp
  lib/Driver/Tools.cpp
  lib/Driver/Tools.h
  test/Driver/arm-compiler-rt.c

Index: test/Driver/arm-compiler-rt.c
===
--- /dev/null
+++ test/Driver/arm-compiler-rt.c
@@ -0,0 +1,21 @@
+// RUN: %clang -target arm-linux-gnueabi -rtlib=compiler-rt -### %s 2>&1 | FileCheck %s -check-prefix ARM-GNUEABI
+// ARM-GNUEABI: "{{.*}}/libclang_rt.builtins-arm.a"
+
+// RUN: %clang -target arm-linux-gnueabi -rtlib=compiler-rt -mfloat-abi=hard -### %s 2>&1 | FileCheck %s -check-prefix ARM-GNUEABI-ABI
+// ARM-GNUEABI-ABI: "{{.*}}/libclang_rt.builtins-armhf.a"
+
+// RUN: %clang -target arm-linux-gnueabihf -rtlib=compiler-rt -### %s 2>&1 | FileCheck %s -check-prefix ARM-GNUEABIHF
+// ARM-GNUEABIHF: "{{.*}}/libclang_rt.builtins-armhf.a"
+
+// RUN: %clang -target arm-linux-gnueabihf -rtlib=compiler-rt -mfloat-abi=soft -### %s 2>&1 | FileCheck %s -check-prefix ARM-GNUEABIHF-ABI
+// ARM-GNUEABIHF-ABI: "{{.*}}/libclang_rt.builtins-arm.a"
+
+// RUN: %clang -target arm-windows-itanium -rtlib=compiler-rt -### %s 2>&1 | FileCheck %s -check-prefix ARM-WINDOWS
+// ARM-WINDOWS: "{{.*}}/clang_rt.builtins-arm.lib"
+
+// RUN: %clang -target arm-linux-androideabi -rtlib=compiler-rt -### %s 2>&1 | FileCheck %s -check-prefix ARM-ANDROID
+// ARM-ANDROID: "{{.*}}/libclang_rt.builtins-arm-android.a"
+
+// RUN: %clang -target arm-linux-androideabi -rtlib=compiler-rt -mfloat-abi=hard -### %s 2>&1 | FileCheck %s -check-prefix ARM-ANDROIDHF
+// ARM-ANDROIDHF: "{{.*}}/libclang_rt.builtins-armhf-android.a"
+
Index: lib/Driver/Tools.h
===
--- lib/Driver/Tools.h
+++ lib/Driver/Tools.h
@@ -37,8 +37,9 @@
 
 using llvm::opt::ArgStringList;
 
-SmallString<128> getCompilerRT(const ToolChain &TC, StringRef Component,
-   bool Shared = false);
+SmallString<128> getCompilerRT(const ToolChain &TC,
+   const llvm::opt::ArgList &Args,
+   StringRef Component, bool Shared = false);
 
 /// \brief Clang compiler tool.
 class LLVM_LIBRARY_VISIBILITY Clang : public Tool {
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -2398,12 +2398,19 @@
 }
 
 // Until ARM libraries are build separately, we have them all in one library
-static StringRef getArchNameForCompilerRTLib(const ToolChain &TC) {
-  if (TC.getTriple().isWindowsMSVCEnvironment() &&
-  TC.getArch() == llvm::Triple::x86)
+static StringRef getArchNameForCompilerRTLib(const ToolChain &TC,
+ const ArgList &Args) {
+  const llvm::Triple &Triple = TC.getTriple();
+  bool IsWindows = Triple.isOSWindows();
+
+  if (Triple.isWindowsMSVCEnvironment() && TC.getArch() == llvm::Triple::x86)
 return "i386";
+
   if (TC.getArch() == llvm::Triple::arm || TC.getArch() == llvm::Triple::armeb)
-return "arm";
+return (arm::getARMFloatABI(TC, Args) == arm::FloatABI::Hard && !IsWindows)
+   ? "armhf"
+   : "arm";
+
   return TC.getArchName();
 }
 
@@ -2418,16 +2425,16 @@
   return Res;
 }
 
-SmallString<128> tools::getCompilerRT(const ToolChain &TC, StringRef Component,
-  bool Shared) {
+SmallString<128> tools::getCompilerRT(const ToolChain &TC, const ArgList &Args,
+  StringRef Component, bool Shared) {
   const char *Env = TC.getTriple().getEnvironment() == llvm::Triple::Android
 ? "-android"
 : "";
 
   bool IsOSWindows = TC.getTriple().isOSWindows();
   bool IsITANMSVCWindows = TC.getTriple().isWindowsMSVCEnvironment() ||
TC.getTriple().isWindowsItaniumEnvironment();
-  StringRef A

Re: [PATCH] D12903: Add -fplugin=name.so option to the driver

2015-09-19 Thread Nico Weber via cfe-commits

thakis added a subscriber: thakis.
thakis added a comment.

Is the idea that this loads plugins that link against clang's C++ api? That api 
isn't considered stable, so not having an "official" flag for this always 
looked by design to me. Also, C++ doesn't make for a good ABI. Also also, this 
approach fundamentally doesn't work on Windows.


Repository:
  rL LLVM

http://reviews.llvm.org/D12903



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

[libcxxabi] r248108 - EH: fix register usage for SjLj

2015-09-19 Thread Saleem Abdulrasool via cfe-commits

Author: compnerd
Date: Sat Sep 19 21:08:31 2015
New Revision: 248108

URL: http://llvm.org/viewvc/llvm-project?rev=248108&view=rev
Log:
EH: fix register usage for SjLj

When using SjLj EH, do not use __builtin_eh_return_regno, map directly to the
ID.  This would work on some targets, particularly those where the non-SjLj EH
personality used the same register mapping (0 -> 0, 1 -> 1).  However, this is
not guaranteed.  Avoiding the use of the builtin enables the use of libc++ with
SjLj EH on all targets.

Modified:
libcxxabi/trunk/src/cxa_personality.cpp

Modified: libcxxabi/trunk/src/cxa_personality.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/src/cxa_personality.cpp?rev=248108&r1=248107&r2=248108&view=diff
==
--- libcxxabi/trunk/src/cxa_personality.cpp (original)
+++ libcxxabi/trunk/src/cxa_personality.cpp Sat Sep 19 21:08:31 2015
@@ -514,11 +514,14 @@ void
 set_registers(_Unwind_Exception* unwind_exception, _Unwind_Context* context,
   const scan_results& results)
 {
-_Unwind_SetGR(context, __builtin_eh_return_data_regno(0),
- 
reinterpret_cast(unwind_exception));
-_Unwind_SetGR(context, __builtin_eh_return_data_regno(1),
-
static_cast(results.ttypeIndex));
-_Unwind_SetIP(context, results.landingPad);
+#if defined(__USING_SJLJ_EXCEPTIONS__)
+#define __builtin_eh_return_data_regno(regno) regno
+#endif
+  _Unwind_SetGR(context, __builtin_eh_return_data_regno(0),
+reinterpret_cast(unwind_exception));
+  _Unwind_SetGR(context, __builtin_eh_return_data_regno(1),
+static_cast(results.ttypeIndex));
+  _Unwind_SetIP(context, results.landingPad);
 }
 
 /*


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

Re: r245459 - According to i686 ABI, long double size on x86 is 12 bytes not 16 bytes.

Re: [PATCH] D12967: fix comments

Re: [PATCH] D12967: fix comments

Re: r245459 - According to i686 ABI, long double size on x86 is 12 bytes not 16 bytes.

r245459 - According to i686 ABI, long double size on x86 is 12 bytes not 16 bytes.

Re: r245459 - According to i686 ABI, long double size on x86 is 12 bytes not 16 bytes.

Re: [PATCH] D12961: Update clang-tidy documentation.

r248090 - [clang-tidy] Fix example comments.

Re: [PATCH] D12967: fix comments

Re: [PATCH] D12835: [X86][SSE] Replace 128-bit SSE41 PMOVSX intrinsics with native IR

r248092 - [X86][SSE] Replace 128-bit SSE41 PMOVSX intrinsics with native IR

[PATCH] D12993: [analyzer] Add TK_EntireMemSpace invalidation trait.

Re: [PATCH] D12358: [Analyzer] Handling constant bound loops

r248094 - Driver: tweak ARM target feature calculation

Re: [PATCH] D12797: Refactor LoopConvertCheck.

r248095 - Driver: alter the getARMFloatABI signature

r248100 - Convert two loops to range-based loops. No behavior change.

r248101 - Further simplify the interface of PCHContainerGenerator

[PATCH] D12996: Driver: support ARM/HF on a single toolchain

Re: [PATCH] D12903: Add -fplugin=name.so option to the driver

[libcxxabi] r248108 - EH: fix register usage for SjLj

21 matches

Site Navigation

Mail list logo

Footer information