[PATCH] D120305: [Driver] Default CLANG_DEFAULT_PIE_ON_LINUX to ON

2022-02-25 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

In D120305#3347142 , @tstellar wrote:

> In D120305#3347139 , @MaskRay wrote:
>
>> In D120305#3347109 , @tstellar 
>> wrote:
>>
>>> [...]
>>> The issue here has nothing to do with the technical merits of the patch or 
>>> what the root cause of the problem is.  The policy for this project is that 
>>> if you commit a patch that breaks someone's configuration (especially a 
>>> buildbot), then it needs to be fixed quickly or reverted.  I get that this 
>>> policy can be frustrating as a committer when you feel your patch is 
>>> correct, and the real problem is elsewhere, but this is still the policy 
>>> and it should be followed.
>>
>> 7 hours ago my 
>> https://github.com/llvm/llvm-zorg/commit/b6ddf02ce3a54da2df29e7e599b1838167e0e3ad
>>  was sufficient to fix the issue and was the suggested fix in my opinion.
>> Unfortunately nobody on the PowerPC side made the change effective in the 
>> build bot. Rather, I received such a heated message 
>> (https://reviews.llvm.org/D120305#3347058).
>> It was another way to fix the redness (revert) but IMO not justified.
>
> I feel like we are talking past each other at this point, but in general 
> changing the buildbot configuration is not an acceptable solution to a broken 
> bot.  Did the bot owner approve that change?

Unsure why it isn't acceptable. There is fairly strong evidence that that 
specific ppc64le buildbot has a stability issue and 
`-DCLANG_DEFAULT_PIE_ON_LINUX=OFF` keeps it as if before this CMake patch.
We can always discuss this with @nemanjai in another place, e.g. in IRC if we 
want to stop bothering others subscribing to this thread.

(The trunk is clean and churn-less (there is no revert so downstream users will 
not get changed behaviors back and forth)).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120305/new/

https://reviews.llvm.org/D120305

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


[PATCH] D120305: [Driver] Default CLANG_DEFAULT_PIE_ON_LINUX to ON

2022-02-25 Thread Tom Stellard via Phabricator via cfe-commits
tstellar added a comment.

In D120305#3347139 , @MaskRay wrote:

> In D120305#3347109 , @tstellar 
> wrote:
>
>> [...]
>> The issue here has nothing to do with the technical merits of the patch or 
>> what the root cause of the problem is.  The policy for this project is that 
>> if you commit a patch that breaks someone's configuration (especially a 
>> buildbot), then it needs to be fixed quickly or reverted.  I get that this 
>> policy can be frustrating as a committer when you feel your patch is 
>> correct, and the real problem is elsewhere, but this is still the policy and 
>> it should be followed.
>
> 7 hours ago my 
> https://github.com/llvm/llvm-zorg/commit/b6ddf02ce3a54da2df29e7e599b1838167e0e3ad
>  was sufficient to fix the issue and was the suggested fix in my opinion.
> Unfortunately nobody on the PowerPC side made the change effective in the 
> build bot. Rather, I received such a heated message 
> (https://reviews.llvm.org/D120305#3347058).
> It was another way to fix the redness (revert) but IMO not justified.

I feel like we are talking past each other at this point, but in general 
changing the buildbot configuration is not an acceptable solution to a broken 
bot.  Did the bot owner approve that change?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120305/new/

https://reviews.llvm.org/D120305

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


[PATCH] D120305: [Driver] Default CLANG_DEFAULT_PIE_ON_LINUX to ON

2022-02-25 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

In D120305#3347109 , @tstellar wrote:

> [...]
> The issue here has nothing to do with the technical merits of the patch or 
> what the root cause of the problem is.  The policy for this project is that 
> if you commit a patch that breaks someone's configuration (especially a 
> buildbot), then it needs to be fixed quickly or reverted.  I get that this 
> policy can be frustrating as a committer when you feel your patch is correct, 
> and the real problem is elsewhere, but this is still the policy and it should 
> be followed.

7 hours ago my 
https://github.com/llvm/llvm-zorg/commit/b6ddf02ce3a54da2df29e7e599b1838167e0e3ad
 was sufficient to fix the issue and was the suggested fix in my opinion.
Unfortunately nobody on the PowerPC side made the change effective in the build 
bot. Rather, I received such a heated message 
(https://reviews.llvm.org/D120305#3347058).
It was another to fix the redness (revert) but IMO not justified.

And I think I need to push back such request as otherwise the red bot is going 
to waste other contributors' time (see my previous links on "Success Rate").
OK, that took me our hour to reply as a non-native speaker, forgetting that I 
probably should try harder to fix the issue.

Anyway, I find that my previous disabling tests attempt was actually effective. 
274ec425dcc3e3f637dd006c5e9ae33bd0e2e917 
 should 
have appeased https://lab.llvm.org/buildbot/#/builders/57


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120305/new/

https://reviews.llvm.org/D120305

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


[PATCH] D120305: [Driver] Default CLANG_DEFAULT_PIE_ON_LINUX to ON

2022-02-25 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 added a comment.

>> error: Segmentation fault (core dumped)

This happens quite often on these ppc bots - they are known for unstability and 
slow cycles.

>> Open https://lab.llvm.org/buildbot/#/builders/57 , click "Success Rate" tab, 
>> the rate is lower compared to other bots recently, even lower than some 
>> other ppc64 bots.

We should also open discussion if such low success rate is “acceptable” for 
LLVM project. Buildbot maintainers are also responsible to provide as stable 
and working bot as possible.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120305/new/

https://reviews.llvm.org/D120305

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


[PATCH] D120305: [Driver] Default CLANG_DEFAULT_PIE_ON_LINUX to ON

2022-02-25 Thread Tom Stellard via Phabricator via cfe-commits
tstellar added a comment.

In D120305#3347108 , @MaskRay wrote:

> In D120305#3347103 , @tstellar 
> wrote:
>
>> In D120305#3347058 , @nemanjai 
>> wrote:
>>
>>> In D120305#3346880 , @MaskRay 
>>> wrote:
>>>
 While I feel sorry for leaving clang-ppc64le-rhel red for some time and am 
 willing to fix issues if I have access to a ppc64 machine (especially 
 compiler-rt ones that I care about),
 I feel uncomfortably if a group just bluntly request "please pull this 
 patch" when apparently (a) there is a better approach (explicitly setting 
 CLANG_DEFAULT_PIE_ON_LINUX=OFF) and (b) there is something a bot 
 maintainer can do
 and (c) there is just some inherent stability problem (in this case, 
 consider not enabling the testing when the target is still unstable) that 
 is causing not only this issue, but various other reports (as I watch 
 sanitizer failures quite closely and ppc64 often tends to be the outlier 
 thing)
>>>
>>> Statements like this seem to be at odds with this community's culture (or 
>>> at least the way I understand it).
>>> As long as I have been a member of this community, the guidance for patches 
>>> that break bots is to fix it immediately if the fix is obvious/trivial and 
>>> if it isn't, to pull the patch until a solution can be found. I am not 
>>> aware of any changes to this policy. I would also like to add that this 
>>> approach serves most other members of the community quite well and at least 
>>> I personally don't see much opposition to this. Frankly, the only person I 
>>> have ever received a response that amounts to "I would rather not" when 
>>> asking them to pull a patch that breaks bots is yourself.
>>
>> @nemanjai Is correct here.
>
> May I beg that you read my reply first and give more evidence when standing 
> by one party?
> You as a https://foundation.llvm.org/docs/board/ member, your words weigh a 
> lot, but with great power comes great responsibility, so every judgement 
> needs to be made prudently.
>
>> @MaskRay  I feel like we are starting to repeat the same discussion we had 
>> with the start-stop-gc patches, and I would like to have a better outcome 
>> this time.  Can you please just revert the patch and then we can discuss the 
>> next steps.
>
> Everyone wants to discuss start-stop-gc can go to 
> https://discourse.llvm.org/t/lld-default-nostart-stop-gc-default-on-release-13-x-and-main/5369
> Please don't conflate things here. I felt bad that people used an 
> unguaranteed behavior as granted and accused/attacked me of changes.
> I think time has proved my correctness: I don't think anyone sees new wacky 
> things in this area.

The issue here has nothing to do with the technical merits of the patch or what 
the root cause of the problem is.  The policy for this project is that if you 
commit a patch that breaks someone's configuration (especially a buildbot), 
then it needs to be fixed quickly or reverted.  I get that this policy can be 
frustrating as a committer when you feel your patch is correct, and the real 
problem is elsewhere, but this is still the policy and it should be followed.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120305/new/

https://reviews.llvm.org/D120305

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


[PATCH] D120305: [Driver] Default CLANG_DEFAULT_PIE_ON_LINUX to ON

2022-02-25 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

In D120305#3347103 , @tstellar wrote:

> In D120305#3347058 , @nemanjai 
> wrote:
>
>> In D120305#3346880 , @MaskRay 
>> wrote:
>>
>>> While I feel sorry for leaving clang-ppc64le-rhel red for some time and am 
>>> willing to fix issues if I have access to a ppc64 machine (especially 
>>> compiler-rt ones that I care about),
>>> I feel uncomfortably if a group just bluntly request "please pull this 
>>> patch" when apparently (a) there is a better approach (explicitly setting 
>>> CLANG_DEFAULT_PIE_ON_LINUX=OFF) and (b) there is something a bot maintainer 
>>> can do
>>> and (c) there is just some inherent stability problem (in this case, 
>>> consider not enabling the testing when the target is still unstable) that 
>>> is causing not only this issue, but various other reports (as I watch 
>>> sanitizer failures quite closely and ppc64 often tends to be the outlier 
>>> thing)
>>
>> Statements like this seem to be at odds with this community's culture (or at 
>> least the way I understand it).
>> As long as I have been a member of this community, the guidance for patches 
>> that break bots is to fix it immediately if the fix is obvious/trivial and 
>> if it isn't, to pull the patch until a solution can be found. I am not aware 
>> of any changes to this policy. I would also like to add that this approach 
>> serves most other members of the community quite well and at least I 
>> personally don't see much opposition to this. Frankly, the only person I 
>> have ever received a response that amounts to "I would rather not" when 
>> asking them to pull a patch that breaks bots is yourself.
>
> @nemanjai Is correct here.

May I beg that you read my reply first and give more evidence when standing by 
one party?
You as a https://foundation.llvm.org/docs/board/ member, your words weigh a 
lot, but with great power comes great responsibility, so every judgement needs 
to be made prudently.

> @MaskRay  I feel like we are starting to repeat the same discussion we had 
> with the start-stop-gc patches, and I would like to have a better outcome 
> this time.  Can you please just revert the patch and then we can discuss the 
> next steps.

Everyone wants to discuss start-stop-gc can go to 
https://discourse.llvm.org/t/lld-default-nostart-stop-gc-default-on-release-13-x-and-main/5369
Please don't conflate things here. I felt bad that people used an unguaranteed 
behavior as granted and accused/attacked me of changes.
I think time has proved my correctness: I don't think anyone sees new wacky 
things in this area.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120305/new/

https://reviews.llvm.org/D120305

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


[PATCH] D120305: [Driver] Default CLANG_DEFAULT_PIE_ON_LINUX to ON

2022-02-25 Thread Tom Stellard via Phabricator via cfe-commits
tstellar added a comment.

In D120305#3347058 , @nemanjai wrote:

> In D120305#3346880 , @MaskRay wrote:
>
>> While I feel sorry for leaving clang-ppc64le-rhel red for some time and am 
>> willing to fix issues if I have access to a ppc64 machine (especially 
>> compiler-rt ones that I care about),
>> I feel uncomfortably if a group just bluntly request "please pull this 
>> patch" when apparently (a) there is a better approach (explicitly setting 
>> CLANG_DEFAULT_PIE_ON_LINUX=OFF) and (b) there is something a bot maintainer 
>> can do
>> and (c) there is just some inherent stability problem (in this case, 
>> consider not enabling the testing when the target is still unstable) that is 
>> causing not only this issue, but various other reports (as I watch sanitizer 
>> failures quite closely and ppc64 often tends to be the outlier thing)
>
> Statements like this seem to be at odds with this community's culture (or at 
> least the way I understand it).
> As long as I have been a member of this community, the guidance for patches 
> that break bots is to fix it immediately if the fix is obvious/trivial and if 
> it isn't, to pull the patch until a solution can be found. I am not aware of 
> any changes to this policy. I would also like to add that this approach 
> serves most other members of the community quite well and at least I 
> personally don't see much opposition to this. Frankly, the only person I have 
> ever received a response that amounts to "I would rather not" when asking 
> them to pull a patch that breaks bots is yourself.

@nemanjai Is correct here.

@MaskRay  I feel like we are starting to repeat the same discussion we had with 
the start-stop-gc patches, and I would like to have a better outcome this time. 
 Can you please just revert the patch and then we can discuss the next steps.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120305/new/

https://reviews.llvm.org/D120305

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


[PATCH] D120305: [Driver] Default CLANG_DEFAULT_PIE_ON_LINUX to ON

2022-02-25 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

In D120305#3347058 , @nemanjai wrote:

> 



> Statements like this seem to be at odds with this community's culture (or at 
> least the way I understand it).
> As long as I have been a member of this community, the guidance for patches 
> that break bots is to fix it immediately if the fix is obvious/trivial and if 
> it isn't, to pull the patch until a solution can be found. I am not aware of 
> any changes to this policy. I would also like to add that this approach 
> serves most other members of the community quite well and at least I 
> personally don't see much opposition to this. Frankly, the only person I have 
> ever received a response that amounts to "I would rather not" when asking 
> them to pull a patch that breaks bots is yourself.

Hi @nemanjai, when I mentioned "as I watch sanitizer failures quite closely and 
ppc64 often tends to be the outlier thing", I was talking about the build bots.
However, you seem to take it very personally, conflate it with a judgement to 
the PowerPC target, and try to defend for the PowerPC target.
I think perhaps you become too emotional from this reply. Hope we can clam down.

> So I'll try to respond to the individual statements you have made here.
>
> No access to a PowerPC machine - we have given you access to one before and 
> are happy to do so again at any time.

Ack. Thanks for that.

> "bluntly requesting to pull the patch" - This is perhaps the part of your 
> statement that I find most surprising. In case you haven't come across this, 
> I encourage you to have a read through it. If you feel this needs to change, 
> I encourage you to bring it up for discussion with the wider community. Of 
> particular interest is this sentence: We strongly encourage “revert to green” 
> as opposed to “fixing forward”. We encourage reverting first, investigating 
> offline, and then reapplying the fixed patch - possibly after another round 
> of review if warranted.

Sure, I know this policy. See below.

> "there is a better approach" - I don't think I have to spend a lot of time 
> explaining how subjective this statement is.
> "there is something that a bot maintainer can do" - I can't quite decipher 
> whether this is a disingenuous statement pretending that this is a situation 
> where the bot maintainer (effectively myself in this case) isn't willing to 
> help. Or perhaps it is a statement you made in the heat of the moment when I 
> asked you to pull the patch and you missed the part where I offered help to 
> resolve the issues when normal business resumes. I will give you the benefit 
> of assuming the latter as I truly don't believe you have ill intentions here. 
> I would just like to add that, as you surely realize, bot maintainers are not 
> sitting around waiting for someone to break their bot so they can jump in 
> immediately and work on resolving the issue. As contributors to this project, 
> it is our responsibility to keep the tip of trunk green and to work with bot 
> maintainers on their own time (within reason) to resolve issues we cause on 
> their bots.

The current issue is that one ppc64 bot (clang-ppc64le-rhel) was complaing 
about some sanitizer tests while other ppc64 bots testing sanitizers (e.g. 
clang-ppc64le-linux-multistage sanitizer-ppc64be-linux sanitizer-ppc64le-linux) 
were apparently happy.
This is an important factor making me believe this is a build bot stability 
issue, not the patch's fault.

From the failure log, the diagnostic looks like:

  :1:11: note: possible intended match here
  error: Segmentation fault (core dumped)

This is weird. This was not the first time I saw this "Segmentation fault".
In the past, I saw GNU ld crashes or similar weird segfaults (on perhaps this 
bot).

-fPIE -pie is a very common configuration tested extensively by users and a 
bunch of ppc64 distributions.
In the downstream distributors typically patch Clang to behave the similar way 
as GCC, as this CMake patch tried to do to reduce downstream 
patch/customization burden.

Making use of my expertise and experience, I put up this statement fairly 
responsibly: this really looks like the problem with this bot, or sanitizer 
tests got enabled while some inherent stability issues havn't been addressed.

Perhaps sanitizers are not so compatible with the bot's environment (say glibc).
If so, the issue will pop up from time to time and a bot maintainer may jump 
out to every patch which tickles the problem.

This is just going to waste developer time.
There is a very high probability that a patch author may shortgun and revert 
the wrong patch, causing unneeded churn.

I understand that a bot maintainer does not bandwidth to watch every change.
But this is the very time that we would appreciate that a bot maintainer did a 
little work just to make everyone happy by drop testing the flaky tests.
I realized that I would not suggest adding UNSUPPORTED to test files since that 
wou

[PATCH] D120596: [clang][CGStmt] fix crash on invalid asm statement

2022-02-25 Thread Tong Zhang via Phabricator via cfe-commits
ztong0001 updated this revision to Diff 411577.
ztong0001 added a comment.

reformat code


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120596/new/

https://reviews.llvm.org/D120596

Files:
  clang/lib/CodeGen/CGStmt.cpp
  clang/test/CodeGen/X86/x86_64-PR42672.c


Index: clang/test/CodeGen/X86/x86_64-PR42672.c
===
--- clang/test/CodeGen/X86/x86_64-PR42672.c
+++ clang/test/CodeGen/X86/x86_64-PR42672.c
@@ -5,6 +5,7 @@
 // RUN: %clang_cc1 -triple=x86_64-unknown-linux-gnu -DPOSSIBLE_X -emit-llvm %s 
-o - 2>&1 | FileCheck %s --check-prefix=CHECK-X
 // RUN: not %clang_cc1 -triple=x86_64-unknown-linux-gnu -DIMPOSSIBLE_X 
-emit-llvm %s -o - 2>&1 | FileCheck %s --check-prefix=CHECK-IMPOSSIBLE_X
 // RUN: not %clang_cc1 -triple=x86_64-unknown-linux-gnu -DIMPOSSIBLE_9BYTES 
-emit-llvm %s -o - 2>&1 | FileCheck %s --check-prefix=CHECK-IMPOSSIBLE_9BYTES
+// RUN: not %clang_cc1 -triple=x86_64-unknown-linux-gnu -DIMPOSSIBLE_9BYTES_V2 
-emit-llvm %s -o - 2>&1 | FileCheck %s --check-prefix=CHECK-IMPOSSIBLE_9BYTES_V2

 // Make sure Clang doesn't treat |lockval| as asm input.
 void _raw_spin_lock(void) {
@@ -115,3 +116,13 @@
 }

 // CHECK-IMPOSSIBLE_9BYTES: impossible constraint in asm: can't store value 
into a register
+
+void crbug_999160_regtest_v2(void) {
+#ifdef IMPOSSIBLE_9BYTES_V2
+  char buf[9];
+  asm(""
+  : "=r"(buf)
+  : "0"(buf));
+#endif
+}
+// CHECK-IMPOSSIBLE_9BYTES_V2: impossible constraint in asm: can't store value 
into a register
Index: clang/lib/CodeGen/CGStmt.cpp
===
--- clang/lib/CodeGen/CGStmt.cpp
+++ clang/lib/CodeGen/CGStmt.cpp
@@ -2513,10 +2513,8 @@
   Arg = Builder.CreateZExt(Arg, OutputTy);
 else if (isa(OutputTy))
   Arg = Builder.CreateZExt(Arg, IntPtrTy);
-else {
-  assert(OutputTy->isFloatingPointTy() && "Unexpected output type");
+else if (OutputTy->isFloatingPointTy())
   Arg = Builder.CreateFPExt(Arg, OutputTy);
-}
   }
   // Deal with the tied operands' constraint code in adjustInlineAsmType.
   ReplaceConstraint = OutputConstraints[Output];


Index: clang/test/CodeGen/X86/x86_64-PR42672.c
===
--- clang/test/CodeGen/X86/x86_64-PR42672.c
+++ clang/test/CodeGen/X86/x86_64-PR42672.c
@@ -5,6 +5,7 @@
 // RUN: %clang_cc1 -triple=x86_64-unknown-linux-gnu -DPOSSIBLE_X -emit-llvm %s -o - 2>&1 | FileCheck %s --check-prefix=CHECK-X
 // RUN: not %clang_cc1 -triple=x86_64-unknown-linux-gnu -DIMPOSSIBLE_X -emit-llvm %s -o - 2>&1 | FileCheck %s --check-prefix=CHECK-IMPOSSIBLE_X
 // RUN: not %clang_cc1 -triple=x86_64-unknown-linux-gnu -DIMPOSSIBLE_9BYTES -emit-llvm %s -o - 2>&1 | FileCheck %s --check-prefix=CHECK-IMPOSSIBLE_9BYTES
+// RUN: not %clang_cc1 -triple=x86_64-unknown-linux-gnu -DIMPOSSIBLE_9BYTES_V2 -emit-llvm %s -o - 2>&1 | FileCheck %s --check-prefix=CHECK-IMPOSSIBLE_9BYTES_V2

 // Make sure Clang doesn't treat |lockval| as asm input.
 void _raw_spin_lock(void) {
@@ -115,3 +116,13 @@
 }

 // CHECK-IMPOSSIBLE_9BYTES: impossible constraint in asm: can't store value into a register
+
+void crbug_999160_regtest_v2(void) {
+#ifdef IMPOSSIBLE_9BYTES_V2
+  char buf[9];
+  asm(""
+  : "=r"(buf)
+  : "0"(buf));
+#endif
+}
+// CHECK-IMPOSSIBLE_9BYTES_V2: impossible constraint in asm: can't store value into a register
Index: clang/lib/CodeGen/CGStmt.cpp
===
--- clang/lib/CodeGen/CGStmt.cpp
+++ clang/lib/CodeGen/CGStmt.cpp
@@ -2513,10 +2513,8 @@
   Arg = Builder.CreateZExt(Arg, OutputTy);
 else if (isa(OutputTy))
   Arg = Builder.CreateZExt(Arg, IntPtrTy);
-else {
-  assert(OutputTy->isFloatingPointTy() && "Unexpected output type");
+else if (OutputTy->isFloatingPointTy())
   Arg = Builder.CreateFPExt(Arg, OutputTy);
-}
   }
   // Deal with the tied operands' constraint code in adjustInlineAsmType.
   ReplaceConstraint = OutputConstraints[Output];
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D111587: re-land: [clang] Fix absolute file paths with -fdebug-prefix-map

2022-02-25 Thread Keith Smiley via Phabricator via cfe-commits
keith updated this revision to Diff 411576.
keith added a comment.

Update test with new specifiers


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D111587/new/

https://reviews.llvm.org/D111587

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/test/CodeGen/relative-debug-prefix-map.c
  clang/test/Modules/module-debuginfo-prefix.m


Index: clang/test/Modules/module-debuginfo-prefix.m
===
--- clang/test/Modules/module-debuginfo-prefix.m
+++ clang/test/Modules/module-debuginfo-prefix.m
@@ -4,7 +4,7 @@
 // Modules:
 // RUN: rm -rf %t
 // RUN: %clang_cc1 -x objective-c -fmodules -fmodule-format=obj \
-// RUN:   -fdebug-prefix-map=%S/Inputs=/OVERRIDE \
+// RUN:   -fdebug-prefix-map=%S%{fssep}Inputs=%{fsroot}OVERRIDE \
 // RUN:   -fimplicit-module-maps -DMODULES -fmodules-cache-path=%t %s \
 // RUN:   -I %S/Inputs -I %t -emit-llvm -o %t.ll \
 // RUN:   -mllvm -debug-only=pchcontainer &>%t-mod.ll
@@ -12,7 +12,7 @@
 
 // PCH:
 // RUN: %clang_cc1 -x objective-c -emit-pch -fmodule-format=obj -I %S/Inputs \
-// RUN:   -fdebug-prefix-map=%S/Inputs=/OVERRIDE \
+// RUN:   -fdebug-prefix-map=%S%{fssep}Inputs=%{fsroot}OVERRIDE \
 // RUN:   -o %t.pch %S/Inputs/DebugObjC.h \
 // RUN:   -mllvm -debug-only=pchcontainer &>%t-pch.ll
 // RUN: cat %t-pch.ll | FileCheck %s
@@ -21,6 +21,4 @@
 @import DebugObjC;
 #endif
 
-// Dir should always be empty, but on Windows we can't recognize /var
-// as being an absolute path.
-// CHECK: !DIFile(filename: "/OVERRIDE/DebugObjC.h", directory: 
"{{()|(.*:.*)}}")
+// CHECK: !DIFile(filename: "{{/|C:}}OVERRIDE{{/|}}DebugObjC.h", 
directory: "")
Index: clang/test/CodeGen/relative-debug-prefix-map.c
===
--- /dev/null
+++ clang/test/CodeGen/relative-debug-prefix-map.c
@@ -0,0 +1,17 @@
+// RUN: mkdir -p %t.nested/dir && cd %t.nested/dir
+// RUN: cp %s %t.nested/dir/main.c
+// RUN: %clang_cc1 -debug-info-kind=standalone -fdebug-prefix-map=%t.nested=. 
%t.nested/dir/main.c -emit-llvm -o - | FileCheck %s
+//
+// RUN: %clang_cc1 -debug-info-kind=standalone -fdebug-prefix-map=%p=. %s 
-emit-llvm -o - | FileCheck %s --check-prefix=CHECK-DIRECT
+//
+// RUN: cd %p
+// RUN: %clang_cc1 -debug-info-kind=standalone -fdebug-compilation-dir=. 
relative-debug-prefix-map.c -emit-llvm -o - | FileCheck %s 
--check-prefix=CHECK-DIRECT
+
+// CHECK: !DIFile(filename: "main.c", directory: "./dir")
+// CHECK-DIRECT: !DIFile(filename: "relative-debug-prefix-map.c", directory: 
".")
+
+int main(int argc, char **argv) {
+  (void)argc;
+  (void)argv;
+  return 0;
+}
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -443,6 +443,9 @@
   Dir = DirBuf;
   File = FileBuf;
 }
+  } else if (llvm::sys::path::is_absolute(FileName)) {
+Dir = llvm::sys::path::parent_path(RemappedFile);
+File = llvm::sys::path::filename(RemappedFile);
   } else {
 Dir = CurDir;
 File = RemappedFile;


Index: clang/test/Modules/module-debuginfo-prefix.m
===
--- clang/test/Modules/module-debuginfo-prefix.m
+++ clang/test/Modules/module-debuginfo-prefix.m
@@ -4,7 +4,7 @@
 // Modules:
 // RUN: rm -rf %t
 // RUN: %clang_cc1 -x objective-c -fmodules -fmodule-format=obj \
-// RUN:   -fdebug-prefix-map=%S/Inputs=/OVERRIDE \
+// RUN:   -fdebug-prefix-map=%S%{fssep}Inputs=%{fsroot}OVERRIDE \
 // RUN:   -fimplicit-module-maps -DMODULES -fmodules-cache-path=%t %s \
 // RUN:   -I %S/Inputs -I %t -emit-llvm -o %t.ll \
 // RUN:   -mllvm -debug-only=pchcontainer &>%t-mod.ll
@@ -12,7 +12,7 @@
 
 // PCH:
 // RUN: %clang_cc1 -x objective-c -emit-pch -fmodule-format=obj -I %S/Inputs \
-// RUN:   -fdebug-prefix-map=%S/Inputs=/OVERRIDE \
+// RUN:   -fdebug-prefix-map=%S%{fssep}Inputs=%{fsroot}OVERRIDE \
 // RUN:   -o %t.pch %S/Inputs/DebugObjC.h \
 // RUN:   -mllvm -debug-only=pchcontainer &>%t-pch.ll
 // RUN: cat %t-pch.ll | FileCheck %s
@@ -21,6 +21,4 @@
 @import DebugObjC;
 #endif
 
-// Dir should always be empty, but on Windows we can't recognize /var
-// as being an absolute path.
-// CHECK: !DIFile(filename: "/OVERRIDE/DebugObjC.h", directory: "{{()|(.*:.*)}}")
+// CHECK: !DIFile(filename: "{{/|C:}}OVERRIDE{{/|}}DebugObjC.h", directory: "")
Index: clang/test/CodeGen/relative-debug-prefix-map.c
===
--- /dev/null
+++ clang/test/CodeGen/relative-debug-prefix-map.c
@@ -0,0 +1,17 @@
+// RUN: mkdir -p %t.nested/dir && cd %t.nested/dir
+// RUN: cp %s %t.nested/dir/main.c
+// RUN: %clang_cc1 -debug-info-kind=standalone -fdebug-prefix-map=%t.nested=. %t.nested/dir/main.c -emit-llvm -o - | FileCheck %s
+//
+// RUN: %clang_cc1 -debug-info-kind=standalone -fdebug-prefix-map=%p=. %s -emit-llvm -o - | Fi

[PATCH] D111579: [clang] Fix DIFile directory root on Windows

2022-02-25 Thread Keith Smiley via Phabricator via cfe-commits
keith updated this revision to Diff 411575.
keith marked 3 inline comments as done.
keith added a comment.

Add more test path changes


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D111579/new/

https://reviews.llvm.org/D111579

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/test/CodeGen/debug-prefix-map.c


Index: clang/test/CodeGen/debug-prefix-map.c
===
--- clang/test/CodeGen/debug-prefix-map.c
+++ clang/test/CodeGen/debug-prefix-map.c
@@ -1,10 +1,10 @@
-// RUN: %clang_cc1 -debug-info-kind=standalone 
-fdebug-prefix-map=%p=/UNLIKELY_PATH/empty %s -emit-llvm -o - | FileCheck %s 
-check-prefix CHECK-NO-MAIN-FILE-NAME
-// RUN: %clang_cc1 -debug-info-kind=standalone 
-fdebug-prefix-map=%p=/UNLIKELY_PATH=empty %s -emit-llvm -o - | FileCheck %s 
-check-prefix CHECK-EVIL
-// RUN: %clang_cc1 -debug-info-kind=standalone 
-fdebug-prefix-map=%p=/UNLIKELY_PATH/empty %s -emit-llvm -o - -main-file-name 
debug-prefix-map.c | FileCheck %s
-// RUN: %clang_cc1 -debug-info-kind=standalone 
-fdebug-prefix-map=%p=/UNLIKELY_PATH/empty %s -emit-llvm -o - 
-fdebug-compilation-dir %p | FileCheck %s -check-prefix CHECK-COMPILATION-DIR
-// RUN: %clang_cc1 -debug-info-kind=standalone 
-fdebug-prefix-map=%p=/UNLIKELY_PATH/empty %s -emit-llvm -o - -isysroot %p 
-debugger-tuning=lldb | FileCheck %s -check-prefix CHECK-SYSROOT
-// RUN: %clang -g -fdebug-prefix-map=%p=/UNLIKELY_PATH/empty -S -c %s 
-emit-llvm -o - | FileCheck %s
-// RUN: %clang -g -ffile-prefix-map=%p=/UNLIKELY_PATH/empty -S -c %s 
-emit-llvm -o - | FileCheck %s
+// RUN: %clang_cc1 -debug-info-kind=standalone 
-fdebug-prefix-map=%p=%{fsroot}UNLIKELY_PATH%{fssep}empty %s -emit-llvm -o - | 
FileCheck %s -check-prefix CHECK-NO-MAIN-FILE-NAME
+// RUN: %clang_cc1 -debug-info-kind=standalone 
-fdebug-prefix-map=%p=%{fsroot}UNLIKELY_PATH=empty %s -emit-llvm -o - | 
FileCheck %s -check-prefix CHECK-EVIL
+// RUN: %clang_cc1 -debug-info-kind=standalone 
-fdebug-prefix-map=%p=%{fsroot}UNLIKELY_PATH%{fssep}empty %s -emit-llvm -o - 
-main-file-name debug-prefix-map.c | FileCheck %s
+// RUN: %clang_cc1 -debug-info-kind=standalone 
-fdebug-prefix-map=%p=%{fsroot}UNLIKELY_PATH%{fssep}empty %s -emit-llvm -o - 
-fdebug-compilation-dir %p | FileCheck %s -check-prefix CHECK-COMPILATION-DIR
+// RUN: %clang_cc1 -debug-info-kind=standalone 
-fdebug-prefix-map=%p=%{fsroot}UNLIKELY_PATH%{fssep}empty %s -emit-llvm -o - 
-isysroot %p -debugger-tuning=lldb | FileCheck %s -check-prefix CHECK-SYSROOT
+// RUN: %clang -g -fdebug-prefix-map=%p=%{fsroot}UNLIKELY_PATH%{fssep}empty -S 
-c %s -emit-llvm -o - | FileCheck %s
+// RUN: %clang -g -ffile-prefix-map=%p=%{fsroot}UNLIKELY_PATH%{fssep}empty -S 
-c %s -emit-llvm -o - | FileCheck %s
 
 #include "Inputs/stdio.h"
 
@@ -19,23 +19,21 @@
   vprintf("string", argp);
 }
 
-// CHECK-NO-MAIN-FILE-NAME: !DIFile(filename: 
"/UNLIKELY_PATH/empty{{/|}}"
-// CHECK-NO-MAIN-FILE-NAME: !DIFile(filename: 
"/UNLIKELY_PATH/empty{{/|}}{{.*}}",
-// On POSIX systems "Dir" should actually be empty, but on Windows we
-// can't recognize "/UNLIKELY_PATH" as being an absolute path.
-// CHECK-NO-MAIN-FILE-NAME-SAME:directory: "{{()|(.*:.*)}}")
-// CHECK-NO-MAIN-FILE-NAME: !DIFile(filename: 
"/UNLIKELY_PATH/empty{{/|}}Inputs/stdio.h",
-// CHECK-NO-MAIN-FILE-NAME-SAME:directory: "{{()|(.*:.*)}}")
+// CHECK-NO-MAIN-FILE-NAME: !DIFile(filename: 
"{{/|C:}}UNLIKELY_PATH{{/|}}empty{{/|}}"
+// CHECK-NO-MAIN-FILE-NAME: !DIFile(filename: 
"{{/|C:}}UNLIKELY_PATH{{/|}}empty{{/|}}{{.*}}",
+// CHECK-NO-MAIN-FILE-NAME-SAME:directory: "")
+// CHECK-NO-MAIN-FILE-NAME: !DIFile(filename: 
"{{/|C:}}UNLIKELY_PATH{{/|}}empty{{/|}}Inputs{{/|}}stdio.h",
+// CHECK-NO-MAIN-FILE-NAME-SAME:directory: "")
 // CHECK-NO-MAIN-FILE-NAME-NOT: !DIFile(filename:
 
-// CHECK-EVIL: !DIFile(filename: "/UNLIKELY_PATH=empty{{/|}}{{.*}}"
-// CHECK-EVIL: !DIFile(filename: 
"/UNLIKELY_PATH=empty{{/|}}{{.*}}Inputs/stdio.h",
-// CHECK-EVIL-SAME:directory: "{{()|(.*:.*)}}")
+// CHECK-EVIL: !DIFile(filename: 
"{{/|C:}}UNLIKELY_PATH=empty{{/|}}{{.*}}"
+// CHECK-EVIL: !DIFile(filename: 
"{{/|C:}}UNLIKELY_PATH=empty{{/|}}{{.*}}Inputs{{/|}}stdio.h",
+// CHECK-EVIL-SAME:directory: "")
 // CHECK-EVIL-NOT: !DIFile(filename:
 
-// CHECK: !DIFile(filename: "/UNLIKELY_PATH/empty{{/|}}{{.*}}"
-// CHECK: !DIFile(filename: 
"/UNLIKELY_PATH/empty{{/|}}{{.*}}Inputs/stdio.h",
-// CHECK-SAME:directory: "{{()|(.*:.*)}}")
+// CHECK: !DIFile(filename: 
"{{/|C:}}UNLIKELY_PATH{{/|}}empty{{/|}}{{.*}}"
+// CHECK: !DIFile(filename: 
"{{/|C:}}UNLIKELY_PATH{{/|}}empty{{/|}}{{.*}}Inputs{{/|}}stdio.h",
+// CHECK-SAME:directory: ""
 // CHECK-NOT: !DIFile(filename:
 
 // CHECK-COMPILATION-DIR: !DIFile(filename: "{{.*}}", directory: 
"/UNLIKELY_PATH/empty")
Index: clang/lib/CodeGen/CGDebugInfo.cpp

[PATCH] D111457: [clang][test] Add lit helper for windows paths

2022-02-25 Thread Keith Smiley via Phabricator via cfe-commits
keith updated this revision to Diff 411573.
keith added a comment.
Herald added subscribers: llvm-commits, delcypher.
Herald added a project: LLVM.

Move config to llvm lit config, add docs


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D111457/new/

https://reviews.llvm.org/D111457

Files:
  llvm/docs/CommandGuide/lit.rst
  llvm/docs/TestingGuide.rst
  llvm/utils/lit/lit/TestRunner.py


Index: llvm/utils/lit/lit/TestRunner.py
===
--- llvm/utils/lit/lit/TestRunner.py
+++ llvm/utils/lit/lit/TestRunner.py
@@ -1119,6 +1119,14 @@
   ('%basename_t', baseName),
   ('%T', tmpDir)])
 
+fs_root = os.path.sep
+if kIsWindows:
+fs_root = 'C:\\'
+substitutions.extend([
+('%{fsroot}', fs_root),
+('%{fssep}', os.path.sep),
+])
+
 # "%/[STpst]" should be normalized.
 substitutions.extend([
 ('%/s', sourcepath.replace('\\', '/')),
Index: llvm/docs/TestingGuide.rst
===
--- llvm/docs/TestingGuide.rst
+++ llvm/docs/TestingGuide.rst
@@ -569,6 +569,13 @@
 
Expands to the path separator, i.e. ``:`` (or ``;`` on Windows).
 
+``${fsroot}``
+   Expands to the root component of file system paths, i.e. ``/`` on Unix
+   systems or ``C:\`` on Windows.
+
+``${fssep}``
+   Exp``ands to the file system separator, i.e. ``/`` or ``\`` on Windows.
+
 ``%/s, %/S, %/t, %/T:``
 
   Act like the corresponding substitution above but replace any ``\``
Index: llvm/docs/CommandGuide/lit.rst
===
--- llvm/docs/CommandGuide/lit.rst
+++ llvm/docs/CommandGuide/lit.rst
@@ -523,6 +523,8 @@
  %S  source dir (directory of the file currently being run)
  %p  same as %S
  %{pathsep}  path separator
+ %{fsroot}   root component of file system paths
+ %{fssep}file system path separator
  %t  temporary file name unique to the test
  %basename_t The last path component of %t but without the 
``.tmp`` extension
  %T  parent directory of %t (not unique, deprecated, do 
not use)


Index: llvm/utils/lit/lit/TestRunner.py
===
--- llvm/utils/lit/lit/TestRunner.py
+++ llvm/utils/lit/lit/TestRunner.py
@@ -1119,6 +1119,14 @@
   ('%basename_t', baseName),
   ('%T', tmpDir)])
 
+fs_root = os.path.sep
+if kIsWindows:
+fs_root = 'C:\\'
+substitutions.extend([
+('%{fsroot}', fs_root),
+('%{fssep}', os.path.sep),
+])
+
 # "%/[STpst]" should be normalized.
 substitutions.extend([
 ('%/s', sourcepath.replace('\\', '/')),
Index: llvm/docs/TestingGuide.rst
===
--- llvm/docs/TestingGuide.rst
+++ llvm/docs/TestingGuide.rst
@@ -569,6 +569,13 @@
 
Expands to the path separator, i.e. ``:`` (or ``;`` on Windows).
 
+``${fsroot}``
+   Expands to the root component of file system paths, i.e. ``/`` on Unix
+   systems or ``C:\`` on Windows.
+
+``${fssep}``
+   Exp``ands to the file system separator, i.e. ``/`` or ``\`` on Windows.
+
 ``%/s, %/S, %/t, %/T:``
 
   Act like the corresponding substitution above but replace any ``\``
Index: llvm/docs/CommandGuide/lit.rst
===
--- llvm/docs/CommandGuide/lit.rst
+++ llvm/docs/CommandGuide/lit.rst
@@ -523,6 +523,8 @@
  %S  source dir (directory of the file currently being run)
  %p  same as %S
  %{pathsep}  path separator
+ %{fsroot}   root component of file system paths
+ %{fssep}file system path separator
  %t  temporary file name unique to the test
  %basename_t The last path component of %t but without the ``.tmp`` extension
  %T  parent directory of %t (not unique, deprecated, do not use)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D120305: [Driver] Default CLANG_DEFAULT_PIE_ON_LINUX to ON

2022-02-25 Thread Nemanja Ivanovic via Phabricator via cfe-commits
nemanjai added a comment.

In D120305#3346880 , @MaskRay wrote:

> While I feel sorry for leaving clang-ppc64le-rhel red for some time and am 
> willing to fix issues if I have access to a ppc64 machine (especially 
> compiler-rt ones that I care about),
> I feel uncomfortably if a group just bluntly request "please pull this patch" 
> when apparently (a) there is a better approach (explicitly setting 
> CLANG_DEFAULT_PIE_ON_LINUX=OFF) and (b) there is something a bot maintainer 
> can do
> and (c) there is just some inherent stability problem (in this case, consider 
> not enabling the testing when the target is still unstable) that is causing 
> not only this issue, but various other reports (as I watch sanitizer failures 
> quite closely and ppc64 often tends to be the outlier thing)

Statements like this seem to be at odds with this community's culture (or at 
least the way I understand it).
As long as I have been a member of this community, the guidance for patches 
that break bots is to fix it immediately if the fix is obvious/trivial and if 
it isn't, to pull the patch until a solution can be found. I am not aware of 
any changes to this policy. I would also like to add that this approach serves 
most other members of the community quite well and at least I personally don't 
see much opposition to this. Frankly, the only person I have ever received a 
response that amounts to "I would rather not" when asking them to pull a patch 
that breaks bots is yourself.

So I'll try to respond to the individual statements you have made here.

1. No access to a PowerPC machine - we have given you access to one before and 
are happy to do so again at any time.
2. "bluntly requesting to pull the patch" - This is perhaps the part of your 
statement that I find most surprising. In case you haven't come across this 
, I 
encourage you to have a read through it. If you feel this needs to change, I 
encourage you to bring it up for discussion with the wider community. Of 
particular interest is this sentence: `We strongly encourage “revert to green” 
as opposed to “fixing forward”. We encourage reverting first, investigating 
offline, and then reapplying the fixed patch - possibly after another round of 
review if warranted.`
3. "there is a better approach" - I don't think I have to spend a lot of time 
explaining how subjective this statement is.
4. "there is something that a bot maintainer can do" - I can't quite decipher 
whether this is a disingenuous statement pretending that this is a situation 
where the bot maintainer (effectively myself in this case) isn't willing to 
help. Or perhaps it is a statement you made in the heat of the moment when I 
asked you to pull the patch and you missed the part where I offered help to 
resolve the issues when normal business resumes. I will give you the benefit of 
assuming the latter as I truly don't believe you have ill intentions here. I 
would just like to add that, as you surely realize, bot maintainers are not 
sitting around waiting for someone to break their bot so they can jump in 
immediately and work on resolving the issue. As contributors to this project, 
it is our responsibility to keep the tip of trunk green and to work with bot 
maintainers on their own time (within reason) to resolve issues we cause on 
their bots.
5. The rather surprising and discouraging statement you made under `(c)` - 
while I realize that PowerPC may not be a target on which you develop, it is 
really not fair to make a blanket statement that PowerPC is not stable wrt. 
sanitizers. If you feel there is a stability issue with a specific bot or a 
specific target, I encourage you to collect data about false failures and bring 
it up with us - we would be happy to look into it as I am sure would any other 
target/bot maintainer. Statements like this sow the seeds of resentment towards 
specific targets - you are effectively saying that PowerPC is an unstable 
target (at least wrt. to sanitizers) but we insist on burdening the community 
with our unstable target by running sanitizer tests in our bots. I am afraid 
that unlike number 4. above, I don't find any ambiguity in your statement here. 
Your statement seems to be clearly and unambiguously hostile towards PowerPC 
and as such, I find it at odds with the spirit of this community. Regardless of 
all of that, I would once again like to reiterate that I would be very happy to 
look into false failures you are encountering with sanitizers on PowerPC.

Fangrui, I would really like you to understand that I very much value your 
contribution to various LLVM projects. You are an exceptional developer and 
seem to be laser focused on advancing the state of LLVM and its subprojects. 
This is not at all lost on me. However, you need to understand that this 
community has all kinds of participants, many of which also care about older or 
so

[PATCH] D120608: [Clang] Remove redundant init-parens in AST print

2022-02-25 Thread Zhihao Yuan via Phabricator via cfe-commits
lichray created this revision.
lichray requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Given a dependent `T` (maybe an undeduced `auto`),

Before:

  new T(z)  -->  new T((z))  # changes meaning with more args
  new T{z}  -->  new T{z}
  T(z)  -->  T(z)
  T{z}  -->  T({z})  # forbidden if T is auto

After:

  new T(z)  -->  new T(z)
  new T{z}  -->  new T{z}
  T(z)   --> T(z)
  T{z}   --> T{z}

Depends on D113393 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D120608

Files:
  clang/lib/AST/StmtPrinter.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.req/simple-requirement.cpp
  clang/test/SemaCXX/cxx2b-ast-print.cpp

Index: clang/test/SemaCXX/cxx2b-ast-print.cpp
===
--- clang/test/SemaCXX/cxx2b-ast-print.cpp
+++ clang/test/SemaCXX/cxx2b-ast-print.cpp
@@ -1,5 +1,6 @@
 // RUN: %clang_cc1 -std=c++2b -fsyntax-only -ast-print %s | FileCheck %s
 
+template  class C>
 void test_auto_expr(long long y, auto &&z) {
   int x[] = {3, 4};
 
@@ -15,16 +16,36 @@
 
   // CHECK{LITERAL}: auto(z)
   void(auto(z));
-  // CHECK{LITERAL}: auto({z})
-  void(auto{z}); // T({z}) is legal unless T = auto
+  // CHECK{LITERAL}: auto{z}
+  void(auto{z});
 
   // CHECK{LITERAL}: new int *(x)
   void(new auto(x));
   // CHECK{LITERAL}: new int *{x}
   void(new auto{x});
 
+  // CHECK{LITERAL}: new auto(z)
+  void(new auto(z));
+  // CHECK{LITERAL}: new auto{z}
+  void(new auto{z});
+
   // CHECK{LITERAL}: new long long(y)
   void(new decltype(auto)(y));
   // CHECK{LITERAL}: new long long{y}
   void(new decltype(auto){y});
+
+  // CHECK{LITERAL}: new decltype(auto)(z)
+  void(new decltype(auto)(z));
+  // CHECK{LITERAL}: new decltype(auto){z}
+  void(new decltype(auto){z});
+
+  // CHECK{LITERAL}: C(x, y, z)
+  void(C(x, y, z));
+  // CHECK{LITERAL}: C{x, y, z}
+  void(C{x, y, z});
+
+  // CHECK{LITERAL}: new C(x, y, z)
+  void(new C(x, y, z));
+  // CHECK{LITERAL}: new C{x, y, z}
+  void(new C{x, y, z});
 }
Index: clang/test/CXX/expr/expr.prim/expr.prim.req/simple-requirement.cpp
===
--- clang/test/CXX/expr/expr.prim/expr.prim.req/simple-requirement.cpp
+++ clang/test/CXX/expr/expr.prim/expr.prim.req/simple-requirement.cpp
@@ -72,7 +72,7 @@
 };
 
 template requires requires(T t) { typename E::non_default_constructible{}; }
-// expected-note@-1 {{because 'typename E::non_default_constructible({})' would be invalid: no matching constructor for initialization of 'typename E::non_default_constructible'}}
+// expected-note@-1 {{because 'typename E::non_default_constructible{}' would be invalid: no matching constructor for initialization of 'typename E::non_default_constructible'}}
 struct r6 {};
 
 using r6i1 = r6;
Index: clang/lib/AST/StmtPrinter.cpp
===
--- clang/lib/AST/StmtPrinter.cpp
+++ clang/lib/AST/StmtPrinter.cpp
@@ -2152,12 +2152,14 @@
   if (E->isParenTypeId())
 OS << ")";
 
-  CXXNewExpr::InitializationStyle InitStyle = E->getInitializationStyle();
-  if (InitStyle) {
-if (InitStyle == CXXNewExpr::CallInit)
+  auto InitStyle = E->getInitializationStyle();
+  if (InitStyle != CXXNewExpr::NoInit) {
+bool Bare = InitStyle == CXXNewExpr::CallInit &&
+!isa(E->getInitializer());
+if (Bare)
   OS << "(";
 PrintExpr(E->getInitializer());
-if (InitStyle == CXXNewExpr::CallInit)
+if (Bare)
   OS << ")";
   }
 }
@@ -2219,19 +2221,19 @@
   PrintExpr(E->getSubExpr());
 }
 
-void
-StmtPrinter::VisitCXXUnresolvedConstructExpr(
-   CXXUnresolvedConstructExpr *Node) {
+void StmtPrinter::VisitCXXUnresolvedConstructExpr(
+CXXUnresolvedConstructExpr *Node) {
   Node->getTypeAsWritten().print(OS, Policy);
-  OS << "(";
-  for (CXXUnresolvedConstructExpr::arg_iterator Arg = Node->arg_begin(),
- ArgEnd = Node->arg_end();
-   Arg != ArgEnd; ++Arg) {
+  if (!Node->isListInitialization())
+OS << '(';
+  for (auto Arg = Node->arg_begin(), ArgEnd = Node->arg_end(); Arg != ArgEnd;
+   ++Arg) {
 if (Arg != Node->arg_begin())
   OS << ", ";
 PrintExpr(*Arg);
   }
-  OS << ")";
+  if (!Node->isListInitialization())
+OS << ')';
 }
 
 void StmtPrinter::VisitCXXDependentScopeMemberExpr(
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D113393: [c++2b] Implement P0849R8 auto(x)

2022-02-25 Thread Zhihao Yuan via Phabricator via cfe-commits
lichray updated this revision to Diff 411571.
lichray added a comment.

Re-run build


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113393/new/

https://reviews.llvm.org/D113393

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Parse/ParseExpr.cpp
  clang/lib/Parse/ParseExprCXX.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p5.cpp
  clang/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.type.auto.deduct/p2.cpp
  clang/test/CXX/expr/expr.post/expr.type.conv/p1-2b.cpp
  clang/test/CXX/expr/expr.unary/expr.new/p2-cxx0x.cpp
  clang/test/CXX/expr/expr.unary/expr.new/p2-cxx14.cpp
  clang/test/CXX/expr/expr.unary/expr.new/p2-cxx1z.cpp
  clang/test/Parser/cxx2b-auto-x.cpp
  clang/test/SemaCXX/cxx2b-ast-print.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -1388,6 +1388,11 @@
   https://wg21.link/P2360R0";>P2360R0
   Clang 14
 
+
+  auto(x): decay-copy in the language
+  https://wg21.link/P0849R8";>P0849R8
+  Clang 15
+
 
 
   Attributes on Lambda-Expressions
Index: clang/test/SemaCXX/cxx2b-ast-print.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/cxx2b-ast-print.cpp
@@ -0,0 +1,30 @@
+// RUN: %clang_cc1 -std=c++2b -fsyntax-only -ast-print %s | FileCheck %s
+
+void test_auto_expr(long long y, auto &&z) {
+  int x[] = {3, 4};
+
+  // CHECK{LITERAL}: (int)(x[1])
+  void(auto(x[1]));
+  // CHECK{LITERAL}: (int){x[1]}
+  void(auto{x[1]});
+
+  // CHECK{LITERAL}: (int *)(x)
+  void(auto(x));
+  // CHECK{LITERAL}: (int *){x}
+  void(auto{x});
+
+  // CHECK{LITERAL}: auto(z)
+  void(auto(z));
+  // CHECK{LITERAL}: auto({z})
+  void(auto{z}); // T({z}) is legal unless T = auto
+
+  // CHECK{LITERAL}: new int *(x)
+  void(new auto(x));
+  // CHECK{LITERAL}: new int *{x}
+  void(new auto{x});
+
+  // CHECK{LITERAL}: new long long(y)
+  void(new decltype(auto)(y));
+  // CHECK{LITERAL}: new long long{y}
+  void(new decltype(auto){y});
+}
Index: clang/test/Parser/cxx2b-auto-x.cpp
===
--- /dev/null
+++ clang/test/Parser/cxx2b-auto-x.cpp
@@ -0,0 +1,24 @@
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,cxx2b -std=c++2b -Wpre-c++2b-compat %s
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,cxx20 -std=c++20 %s
+
+void looks_like_decltype_auto() {
+  decltype(auto(42)) b = 42; // cxx20-error {{'auto' not allowed here}} \
+cxx2b-warning {{'auto' as a functional-style cast is incompatible with C++ standards before C++2b}}
+  decltype(long *) a = 42;   // expected-error {{expected '(' for function-style cast or type construction}} \
+expected-error {{expected expression}}
+  decltype(auto *) a = 42;   // expected-error {{expected '(' for function-style cast or type construction}} \
+expected-error {{expected expression}}
+  decltype(auto()) c = 42;   // cxx2b-error {{initializer for functional-style cast to 'auto' is empty}} \
+cxx20-error {{'auto' not allowed here}}
+}
+
+struct looks_like_declaration {
+  int n;
+} a;
+
+using T = looks_like_declaration *;
+void f() { T(&a)->n = 1; }
+// FIXME: They should be deemed expressions without breaking function pointer
+//parameter declarations with trailing return types.
+// void g() { auto(&a)->n = 0; }
+// void h() { auto{&a}->n = 0; }
Index: clang/test/CXX/expr/expr.unary/expr.new/p2-cxx1z.cpp
===
--- clang/test/CXX/expr/expr.unary/expr.new/p2-cxx1z.cpp
+++ clang/test/CXX/expr/expr.unary/expr.new/p2-cxx1z.cpp
@@ -1,11 +1,30 @@
 // RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++14
 // RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++17 -pedantic
 
+// [expr.new]p2 ... the invented declaration: T x init ;
+// C++2b [dcl.type.auto.deduct]p2.2
+// For a variable declared with a type that contains a placeholder type, T is the declared type of the variable.
 void f() {
+  // - If the initializer is a parenthesized expression-list, the expression-list shall be a single assignmentexpression and E is the assignment-expression.
   new auto('a');
-  new auto {2};
-  new auto {1, 2}; // expected-error{{new expression for type 'auto' contains multiple constructor arguments}}
-  new auto {}; // expected-error{{new expression for type 'auto' requires a constructor argument}}
-  new decltype(auto)({1});
-  new decltype(auto)({1, 2}); // expected-error{{new expression for type 'decltype(auto)' contains multiple constructor arguments}}
+  new decltype(auto)('a');

[PATCH] D120305: [Driver] Default CLANG_DEFAULT_PIE_ON_LINUX to ON

2022-02-25 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

In D120305#3346947 , @tstellar wrote:

> In D120305#3346880 , @MaskRay wrote:
>
>> In D120305#3346787 , @nemanjai 
>> wrote:
>>
>>> In D120305#3346144 , @MaskRay 
>>> wrote:
>>>
 In D120305#3345978 , @MaskRay 
 wrote:

> In D120305#3345810 , @RKSimon 
> wrote:
>
>> @MaskRay The ppc buildbots have been red since these patches - please 
>> can you take a look? 
>> https://lab.llvm.org/buildbot/#/builders/57/builds/15454
>
> Seems that ppc64 doesn't support test/sanitizer_common test/crt -fpie. 
> I'll just disable them: https://github.com/llvm/llvm-project/issues/54084

 Actually I don't know how to disable the tests: 
 https://lab.llvm.org/buildbot/#/builders/57/builds/15497 still failed.
 Hope someone from #powerpc  can 
 disable them.
>>>
>>> This does not appear to be a matter of simply marking some tests as 
>>> UNSUPPORTED. Since this landed, there have been many builds with different 
>>> sanitizer failures and different numbers of sanitizer failures. Please pull 
>>> this patch to bring the bots back to green and we can work with you next 
>>> week on fixing what needs to be fixed.
>>
>> I enabled -DCLANG_DEFAULT_PIE_ON_LINUX=OFF for clang-ppc64le-rhel: 
>> https://github.com/llvm/llvm-zorg/commit/b6ddf02ce3a54da2df29e7e599b1838167e0e3ad
>> which should fix the issues.
>>
>> While I feel sorry for leaving clang-ppc64le-rhel red for some time and am 
>> willing to fix issues if I have access to a ppc64 machine (especially 
>> compiler-rt ones that I care about),
>> I feel uncomfortably if a group just bluntly request "please pull this 
>> patch" when apparently (a) there is a better approach (explicitly setting 
>> CLANG_DEFAULT_PIE_ON_LINUX=OFF) and (b) there is something a bot maintainer 
>> can do
>> and (c) there is just some inherent stability problem (in this case, 
>> consider not enabling the testing when the target is still unstable) that is 
>> causing not only this issue, but various other reports (as I watch sanitizer 
>> failures quite closely and ppc64 often tends to be the outlier thing)
>
> Fixing the buildbot like this doesn't help regular users though.  I think 
> it's better to revert and then work on a solution as @nemanjai suggested.  
> What  are the downsides to reverting this?

Well, I can speak for regular ppc64le users now since q66 kindly gives me 
access to a ppc64le machine.
`check-lsan check-sanitizer check-crt` etc passed fairly well with default PIE 
Clang.

I think we previously paid too less attention on build bot stability problems.
In this case I suspected again this is such a problem (typically sanitizer not 
so compatible with some older glibc/binutils)

  :1:16: note: possible intended match here
  error: Segmentation fault (core dumped)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120305/new/

https://reviews.llvm.org/D120305

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


[PATCH] D119609: [Clang][Sema] Don't act on ReturnStmt when parsing the lambda declarator.

2022-02-25 Thread Jun Zhang via Phabricator via cfe-commits
junaire added a comment.

In D119609#3331257 , @junaire wrote:

> gentle ping~

Gentle ping~


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119609/new/

https://reviews.llvm.org/D119609

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


[PATCH] D120305: [Driver] Default CLANG_DEFAULT_PIE_ON_LINUX to ON

2022-02-25 Thread Tom Stellard via Phabricator via cfe-commits
tstellar added a comment.

In D120305#3346880 , @MaskRay wrote:

> In D120305#3346787 , @nemanjai 
> wrote:
>
>> In D120305#3346144 , @MaskRay 
>> wrote:
>>
>>> In D120305#3345978 , @MaskRay 
>>> wrote:
>>>
 In D120305#3345810 , @RKSimon 
 wrote:

> @MaskRay The ppc buildbots have been red since these patches - please can 
> you take a look? https://lab.llvm.org/buildbot/#/builders/57/builds/15454

 Seems that ppc64 doesn't support test/sanitizer_common test/crt -fpie. 
 I'll just disable them: https://github.com/llvm/llvm-project/issues/54084
>>>
>>> Actually I don't know how to disable the tests: 
>>> https://lab.llvm.org/buildbot/#/builders/57/builds/15497 still failed.
>>> Hope someone from #powerpc  can 
>>> disable them.
>>
>> This does not appear to be a matter of simply marking some tests as 
>> UNSUPPORTED. Since this landed, there have been many builds with different 
>> sanitizer failures and different numbers of sanitizer failures. Please pull 
>> this patch to bring the bots back to green and we can work with you next 
>> week on fixing what needs to be fixed.
>
> I enabled -DCLANG_DEFAULT_PIE_ON_LINUX=OFF for clang-ppc64le-rhel: 
> https://github.com/llvm/llvm-zorg/commit/b6ddf02ce3a54da2df29e7e599b1838167e0e3ad
> which should fix the issues.
>
> While I feel sorry for leaving clang-ppc64le-rhel red for some time and am 
> willing to fix issues if I have access to a ppc64 machine (especially 
> compiler-rt ones that I care about),
> I feel uncomfortably if a group just bluntly request "please pull this patch" 
> when apparently (a) there is a better approach (explicitly setting 
> CLANG_DEFAULT_PIE_ON_LINUX=OFF) and (b) there is something a bot maintainer 
> can do
> and (c) there is just some inherent stability problem (in this case, consider 
> not enabling the testing when the target is still unstable) that is causing 
> not only this issue, but various other reports (as I watch sanitizer failures 
> quite closely and ppc64 often tends to be the outlier thing)

Fixing the buildbot like this doesn't help regular users though.  I think it's 
better to revert and then work on a solution as @nemanjai suggested.  What  are 
the downsides to reverting this?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120305/new/

https://reviews.llvm.org/D120305

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


[PATCH] D120577: [14.x] [clang] [test] Skip hip-fpie-option.hip if default-pie

2022-02-25 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay closed this revision.
MaskRay added a comment.

mgorny pushed this to release/14.x


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120577/new/

https://reviews.llvm.org/D120577

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


[PATCH] D113718: Don't append the working directory to absolute paths

2022-02-25 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

In D113718#3208927 , @dblaikie wrote:

> @thakis - I think you folks over in Chrome land implemented/use 
> `-fdebug-prefix-map` (or do you use `-fdebug-compilation-dir`?) so might be 
> interested in this change.

We're using fdebug-compilation-dir. With fdebug-prefix-map, your command line 
flags are machine-specific, which makes builds not universally deterministic 
(per https://blog.llvm.org/2019/11/deterministic-builds-with-clang-and-lld.html)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113718/new/

https://reviews.llvm.org/D113718

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


[PATCH] D119309: [Driver][test] Clean up some AIX tests

2022-02-25 Thread Fangrui Song via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGcb1654ee4bee: [Driver][test] Clean up some AIX tests 
(authored by MaskRay).

Changed prior to commit:
  https://reviews.llvm.org/D119309?vs=407038&id=411557#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119309/new/

https://reviews.llvm.org/D119309

Files:
  clang/test/Driver/aix-as.c
  clang/test/Driver/aix-data-sections.c
  clang/test/Driver/aix-err-options.c
  clang/test/Driver/aix-ld.c
  clang/test/Driver/aix-mcpu-default.c
  clang/test/Driver/aix-object-mode.c
  clang/test/Driver/aix-rtlib.c
  clang/test/Driver/aix-toolchain-include.cpp

Index: clang/test/Driver/aix-toolchain-include.cpp
===
--- clang/test/Driver/aix-toolchain-include.cpp
+++ clang/test/Driver/aix-toolchain-include.cpp
@@ -1,31 +1,31 @@
 // Tests that the AIX toolchain adds system includes to its search path.
 
 // Check powerpc-ibm-aix, 32-bit/64-bit.
-// RUN: %clangxx -### -no-canonical-prefixes %s 2>&1 \
-// RUN:		-target powerpc-ibm-aix \
+// RUN: %clangxx -### %s 2>&1 \
+// RUN:		--target=powerpc-ibm-aix \
 // RUN:		-resource-dir=%S/Inputs/resource_dir \
 // RUN:		--sysroot=%S/Inputs/basic_aix_tree \
 // RUN:   | FileCheck -check-prefixes=CHECK-INTERNAL-INCLUDE,CHECK-INTERNAL-INCLUDE-CXX %s
 
-// RUN: %clangxx -### -no-canonical-prefixes %s 2>&1 \
-// RUN:		-target powerpc64-ibm-aix \
+// RUN: %clangxx -### %s 2>&1 \
+// RUN:		--target=powerpc64-ibm-aix \
 // RUN:		-resource-dir=%S/Inputs/resource_dir \
 // RUN:		--sysroot=%S/Inputs/basic_aix_tree \
 // RUN:   | FileCheck -check-prefixes=CHECK-INTERNAL-INCLUDE,CHECK-INTERNAL-INCLUDE-CXX %s
 
-// RUN: %clang -### -xc -no-canonical-prefixes %s 2>&1 \
-// RUN:		-target powerpc-ibm-aix \
+// RUN: %clang -### -xc %s 2>&1 \
+// RUN:		--target=powerpc-ibm-aix \
 // RUN:		-resource-dir=%S/Inputs/resource_dir \
 // RUN:		--sysroot=%S/Inputs/basic_aix_tree \
 // RUN:   | FileCheck -check-prefix=CHECK-INTERNAL-INCLUDE %s
 
-// RUN: %clang -### -xc -no-canonical-prefixes %s 2>&1 \
-// RUN:		-target powerpc64-ibm-aix \
+// RUN: %clang -### -xc %s 2>&1 \
+// RUN:		--target=powerpc64-ibm-aix \
 // RUN:		-resource-dir=%S/Inputs/resource_dir \
 // RUN:		--sysroot=%S/Inputs/basic_aix_tree \
 // RUN:   | FileCheck -check-prefix=CHECK-INTERNAL-INCLUDE %s
 
-// CHECK-INTERNAL-INCLUDE:  {{.*}}clang{{.*}}" "-cc1"
+// CHECK-INTERNAL-INCLUDE:  "-cc1"
 // CHECK-INTERNAL-INCLUDE:  "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
 // CHECK-INTERNAL-INCLUDE:  "-isysroot" "[[SYSROOT:[^"]+]]"
 // CHECK-INTERNAL-INCLUDE-CXX:  "-internal-isystem" "[[SYSROOT]]{{(/|)}}opt{{(/|)}}IBM{{(/|)}}openxlCSDK{{(/|)}}include{{(/|)}}c++{{(/|)}}v1"
@@ -34,69 +34,69 @@
 // CHECK-INTERNAL-INCLUDE:  "-internal-isystem" "[[SYSROOT]]/usr/include"
 
 // Check powerpc-ibm-aix, 32-bit/64-bit. -nostdinc option.
-// RUN: %clangxx -### -no-canonical-prefixes %s 2>&1 \
-// RUN:		-target powerpc-ibm-aix \
+// RUN: %clangxx -### %s 2>&1 \
+// RUN:		--target=powerpc-ibm-aix \
 // RUN:		-resource-dir=%S/Inputs/resource_dir \
 // RUN:		--sysroot=%S/Inputs/basic_aix_tree \
 // RUN:		-nostdinc \
 // RUN:   | FileCheck -check-prefix=CHECK-NOSTDINC-INCLUDE %s
 
-// RUN: %clangxx -### -no-canonical-prefixes %s 2>&1 \
-// RUN:		-target powerpc64-ibm-aix \
+// RUN: %clangxx -### %s 2>&1 \
+// RUN:		--target=powerpc64-ibm-aix \
 // RUN:		-resource-dir=%S/Inputs/resource_dir \
 // RUN:		--sysroot=%S/Inputs/basic_aix_tree \
 // RUN:		-nostdinc \
 // RUN:   | FileCheck -check-prefix=CHECK-NOSTDINC-INCLUDE %s
 
-// RUN: %clang -### -xc -no-canonical-prefixes %s 2>&1 \
-// RUN:		-target powerpc-ibm-aix \
+// RUN: %clang -### -xc %s 2>&1 \
+// RUN:		--target=powerpc-ibm-aix \
 // RUN:		-resource-dir=%S/Inputs/resource_dir \
 // RUN:		--sysroot=%S/Inputs/basic_aix_tree \
 // RUN:		-nostdinc \
 // RUN:   | FileCheck -check-prefix=CHECK-NOSTDINC-INCLUDE %s
 
-// RUN: %clang -### -xc -no-canonical-prefixes %s 2>&1 \
-// RUN:		-target powerpc64-ibm-aix \
+// RUN: %clang -### -xc %s 2>&1 \
+// RUN:		--target=powerpc64-ibm-aix \
 // RUN:		-resource-dir=%S/Inputs/resource_dir \
 // RUN:		--sysroot=%S/Inputs/basic_aix_tree \
 // RUN:		-nostdinc \
 // RUN:   | FileCheck -check-prefix=CHECK-NOSTDINC-INCLUDE %s
 
-// CHECK-NOSTDINC-INCLUDE:	{{.*}}clang{{.*}}" "-cc1"
+// CHECK-NOSTDINC-INCLUDE:	"-cc1"
 // CHECK-NOSTDINC-INCLUDE:	"-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
 // CHECK-NOSTDINC-INCLUDE:	"-isysroot" "[[SYSROOT:[^"]+]]"
 // CHECK-NOSTDINC-INCLUDE-NOT:	"-internal-isystem"
 
 // Check powerpc-ibm-aix, 32-bit/64-bit. -nostdlibinc option.
-// RUN: %clangxx -### -no-canonical-prefixes %s 2>&1 \
-// RUN:		-target powerpc-ibm-aix \
+// RUN: %clangxx -### %s 2>&1 \
+// RUN:		--target=powerpc-ibm-aix \
 // RUN:		-resource-dir=%S/Inputs/resource_dir \
 // RUN:		--sysroot=%S/

[clang] cb1654e - [Driver][test] Clean up some AIX tests

2022-02-25 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2022-02-26T01:06:24Z
New Revision: cb1654ee4beedc875c25a95e7b98f1aaed0b9e35

URL: 
https://github.com/llvm/llvm-project/commit/cb1654ee4beedc875c25a95e7b98f1aaed0b9e35
DIFF: 
https://github.com/llvm/llvm-project/commit/cb1654ee4beedc875c25a95e7b98f1aaed0b9e35.diff

LOG: [Driver][test] Clean up some AIX tests

* For `-###`, `-o %t.o` is unnecessary if we don't specifically test the
  output filename.
* --target= is the canonical spelling. -target is a legacy spelling which
  unfortunately cannot be removed because there are too many uses.
* -no-canonical-prefixes uses the dereferenced absolute path for the cc1
  command. For most tests "-cc1" is sufficient to identify the command line, no
  need to specifically test the "clang" command, and -no-canonical-prefixes can
  removed.
* --unwindlib= is the preferred spelling. -u is a short option taking a value,
  which means a -uwindlib= typo cannot be detected.

I recommend that you take a look at linux-cross.cpp. Testing include paths and
library paths in one RUN line is sometimes more readable than having separate
include/library tests.

Having separate RUN lines for misc features like -fdata-sections
(`aix-data-sections.c`) is wasteful. It may be better testing multiple
options in a single RUN command.

Reviewed By: jsji

Differential Revision: https://reviews.llvm.org/D119309

Added: 


Modified: 
clang/test/Driver/aix-as.c
clang/test/Driver/aix-data-sections.c
clang/test/Driver/aix-err-options.c
clang/test/Driver/aix-ld.c
clang/test/Driver/aix-mcpu-default.c
clang/test/Driver/aix-object-mode.c
clang/test/Driver/aix-rtlib.c
clang/test/Driver/aix-toolchain-include.cpp

Removed: 




diff  --git a/clang/test/Driver/aix-as.c b/clang/test/Driver/aix-as.c
index def2adc97daaa..9412604c2e84f 100644
--- a/clang/test/Driver/aix-as.c
+++ b/clang/test/Driver/aix-as.c
@@ -2,44 +2,44 @@
 // only test assembler functionalities in this suite.
 
 // Check powerpc-ibm-aix7.1.0.0, 32-bit.
-// RUN: %clang -no-canonical-prefixes %s -### -c -o %t.o 2>&1 \
-// RUN: -target powerpc-ibm-aix7.1.0.0 \
+// RUN: %clang %s -### -c 2>&1 \
+// RUN: --target=powerpc-ibm-aix7.1.0.0 \
 // RUN:   | FileCheck --check-prefix=CHECK-AS32 %s
 // CHECK-AS32-NOT: warning:
-// CHECK-AS32: {{.*}}clang{{(.exe)?}}" "-cc1" "-triple" 
"powerpc-ibm-aix7.1.0.0"
+// CHECK-AS32: "-cc1" "-triple" "powerpc-ibm-aix7.1.0.0"
 // CHECK-AS32: "{{.*}}as{{(.exe)?}}" 
 // CHECK-AS32: "-a32" 
 // CHECK-AS32: "-many" 
 
 // Check powerpc64-ibm-aix7.1.0.0, 64-bit.
-// RUN: %clang -no-canonical-prefixes %s -### -c -o %t.o 2>&1 \
-// RUN: -target powerpc64-ibm-aix7.1.0.0 \
+// RUN: %clang %s -### -c 2>&1 \
+// RUN: --target=powerpc64-ibm-aix7.1.0.0 \
 // RUN:   | FileCheck --check-prefix=CHECK-AS64 %s
 // CHECK-AS64-NOT: warning:
-// CHECK-AS64: {{.*}}clang{{(.exe)?}}" "-cc1" "-triple" 
"powerpc64-ibm-aix7.1.0.0"
+// CHECK-AS64: "-cc1" "-triple" "powerpc64-ibm-aix7.1.0.0"
 // CHECK-AS64: "{{.*}}as{{(.exe)?}}" 
 // CHECK-AS64: "-a64" 
 // CHECK-AS64: "-many"
 
 // Check powerpc-ibm-aix7.1.0.0, 32-bit. -Xassembler  option. 
-// RUN: %clang -no-canonical-prefixes %s -### -c -o %t.o 2>&1 \
+// RUN: %clang %s -### -c 2>&1 \
 // RUN: -Xassembler -w \
-// RUN: -target powerpc-ibm-aix7.1.0.0 \
+// RUN: --target=powerpc-ibm-aix7.1.0.0 \
 // RUN:   | FileCheck --check-prefix=CHECK-AS32-Xassembler %s
 // CHECK-AS32-Xassembler-NOT: warning:
-// CHECK-AS32-Xassembler: {{.*}}clang{{(.exe)?}}" "-cc1" "-triple" 
"powerpc-ibm-aix7.1.0.0"
+// CHECK-AS32-Xassembler: "-cc1" "-triple" "powerpc-ibm-aix7.1.0.0"
 // CHECK-AS32-Xassembler: "{{.*}}as{{(.exe)?}}" 
 // CHECK-AS32-Xassembler: "-a32" 
 // CHECK-AS32-Xassembler: "-many"
 // CHECK-AS32-Xassembler: "-w"
 
 // Check powerpc64-ibm-aix7.1.0.0, 64-bit. -Wa,, option.
-// RUN: %clang -no-canonical-prefixes %s -### -c -o %t.o 2>&1 \
+// RUN: %clang %s -### -c 2>&1 \
 // RUN: -Wa,-v,-w \
-// RUN: -target powerpc64-ibm-aix7.1.0.0 \
+// RUN: --target=powerpc64-ibm-aix7.1.0.0 \
 // RUN:   | FileCheck --check-prefix=CHECK-AS64-Wa %s
 // CHECK-AS64-Wa-NOT: warning:
-// CHECK-AS64-Wa: {{.*}}clang{{(.exe)?}}" "-cc1" "-triple" 
"powerpc64-ibm-aix7.1.0.0"
+// CHECK-AS64-Wa: "-cc1" "-triple" "powerpc64-ibm-aix7.1.0.0"
 // CHECK-AS64-Wa: "{{.*}}as{{(.exe)?}}" 
 // CHECK-AS64-Wa: "-a64" 
 // CHECK-AS64-Wa: "-many"
@@ -47,11 +47,11 @@
 // CHECK-AS64-Wa: "-w"
 
 // Check powerpc-ibm-aix7.1.0.0, 32-bit. Multiple input files.
-// RUN: %clang -no-canonical-prefixes -### -c \
+// RUN: %clang -### -c \
 // RUN: %S/Inputs/aix_ppc_tree/dummy0.s \
 // RUN: %S/Inputs/aix_ppc_tree/dummy1.s \
 // RUN: %S/Inputs/aix_ppc_tree/dummy2.s 2>&1 \
-// RUN: -target powerpc-ibm-aix7.1.0.0 \
+// RUN: --target=powerpc-ibm-aix7.1.0.0 \
 // RUN:   | FileCheck --check-prefi

[PATCH] D116577: [clang-tidy] Added "boost-use-range-based-for-loop" check

2022-02-25 Thread Denis Mikhailov via Phabricator via cfe-commits
denzor200 updated this revision to Diff 411556.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116577/new/

https://reviews.llvm.org/D116577

Files:
  clang-tools-extra/clang-tidy/boost/BoostTidyModule.cpp
  clang-tools-extra/clang-tidy/boost/CMakeLists.txt
  clang-tools-extra/clang-tidy/boost/UseRangeBasedForLoopCheck.cpp
  clang-tools-extra/clang-tidy/boost/UseRangeBasedForLoopCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/boost-use-range-based-for-loop.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/checkers/boost-use-range-based-for-loop.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/boost-use-range-based-for-loop.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/boost-use-range-based-for-loop.cpp
@@ -0,0 +1,229 @@
+// RUN: %check_clang_tidy %s boost-use-range-based-for-loop %t
+
+namespace std {
+template 
+class list {
+public:
+  using iterator = T*;
+  using value_type = T;
+  iterator begin();
+  iterator end();
+};
+template 
+class map {};
+template 
+class tuple {};
+template 
+struct pair {
+  explicit pair(const First&, const Second&);
+};
+}
+
+#define BOOST_FOREACH(VAR, COL) for(VAR;(COL, false);)
+#define IDENTITY_TYPE(...) __VA_ARGS__
+
+void test_range_based_for_loop()
+{
+  std::list list_int;
+  BOOST_FOREACH( int i, list_int ) {
+// do something with i
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead of BOOST_FOREACH [boost-use-range-based-for-loop]
+  // CHECK-FIXES: for( int i: list_int ) {
+
+  short array_short[] = {1,2,3};
+  BOOST_FOREACH(int val, array_short) {
+/// The short was implicitly converted to an int
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based
+  // CHECK-FIXES: for(int val: array_short) {
+}
+
+#define foreach_ BOOST_FOREACH
+#define foreach_2nd_ foreach_
+
+void test_range_based_for_loop_prettier()
+{
+  std::list l;
+  foreach_( int i, l ) {
+// do something with i
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based 
+  // CHECK-FIXES: for( int i: l ) {
+
+  short array_short[] = {1,2,3};
+  foreach_2nd_(int val, array_short) {
+/// The short was implicitly converted to an int
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based
+  // CHECK-FIXES: for(int val: array_short) {
+}
+
+template
+void test_range_based_for_loop_in_template_instantiation(const std::list& some_list
+	   , const Containter& some_containter)
+{
+  std::list list_int;
+  BOOST_FOREACH( int i, list_int ) {
+// do something with i
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead of BOOST_FOREACH [boost-use-range-based-for-loop]
+  // CHECK-FIXES: for( int i: list_int ) {
+
+  // FIXME
+#if 0
+  BOOST_FOREACH( T i, some_list ) {
+// do something with i
+  }
+  // :[[@LINE-3]]:3: warning: use range-based for loop instead of BOOST_FOREACH [boost-use-range-based-for-loop]
+  // for( T i: some_list ) {
+#endif
+
+  BOOST_FOREACH( typename Containter::value_type i, some_containter ) {
+// do something with i
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead of BOOST_FOREACH [boost-use-range-based-for-loop]
+  // CHECK-FIXES: BOOST_FOREACH( typename Containter::value_type i, some_containter ) {
+  // ^ so no fix-its here.
+}
+
+void test_range_based_for_loop_without_spaces()
+{
+  std::list> l;
+  BOOST_FOREACH(std::listi,l){
+// do something with i
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based 
+  // CHECK-FIXES: for(std::listi:l){
+}
+
+void test_range_based_for_loop_no_migration()
+{
+  // FIXME: implement these migrations and remove here tests
+  std::list l;
+  using rng = std::pair::iterator, std::list::iterator>;
+
+  int i;
+  BOOST_FOREACH( i, l ) {
+// do something with i
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based 
+  // CHECK-FIXES: BOOST_FOREACH( i, l ) {
+  // ^ so no fix-its here.
+
+  BOOST_FOREACH( int val, rng(l.begin(), l.end()) ) {
+// do something with i
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based 
+  // CHECK-FIXES: BOOST_FOREACH( int val, rng(l.begin(), l.end()) ) {
+  // ^ so no fix-its here.
+}
+
+void test_range_based_for_loop_keep_comments()
+{
+  std::list l;
+  std::list l2;
+
+  /* 1 */ BOOST_FOREACH( int i, l=l2 ) {
+// do something with i
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:11: warning: use range-based
+  // CHECK-FIXES: /* 1 */ for( int i: l=l2 ) {
+
+  BOOST_FOREACH /* 1 */ ( int i, l=l2 ) {
+// do something with i
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based
+  // CHECK-FIXES: for /* 1 */ ( int i: l=l2 ) {
+
+  BOOST_FOREACH( /* 1 */ int i, l=l2 ) {
+// do something with i
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]

[clang] bc7aeea - Revert "Don't append the working directory to absolute paths"

2022-02-25 Thread Adrian Prantl via cfe-commits

Author: Adrian Prantl
Date: 2022-02-25T17:00:10-08:00
New Revision: bc7aeea8542d48111f8cc923451b7c53347c75b5

URL: 
https://github.com/llvm/llvm-project/commit/bc7aeea8542d48111f8cc923451b7c53347c75b5
DIFF: 
https://github.com/llvm/llvm-project/commit/bc7aeea8542d48111f8cc923451b7c53347c75b5.diff

LOG: Revert "Don't append the working directory to absolute paths"

This reverts commit 2cd9a86da54f8be4eb2aff3e766b125cbdeb023f.

Added: 


Modified: 
clang/lib/CodeGen/CGDebugInfo.cpp
clang/test/CodeGen/debug-prefix-map.c

Removed: 




diff  --git a/clang/lib/CodeGen/CGDebugInfo.cpp 
b/clang/lib/CodeGen/CGDebugInfo.cpp
index 28d318cdd4080..2203f0aec5c7c 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -444,8 +444,7 @@ CGDebugInfo::createFile(StringRef FileName,
   File = FileBuf;
 }
   } else {
-if (!llvm::sys::path::is_absolute(FileName))
-  Dir = CurDir;
+Dir = CurDir;
 File = RemappedFile;
   }
   llvm::DIFile *F = DBuilder.createFile(File, Dir, CSInfo, Source);

diff  --git a/clang/test/CodeGen/debug-prefix-map.c 
b/clang/test/CodeGen/debug-prefix-map.c
index 2241b703f9001..1c5d3a6e78bb2 100644
--- a/clang/test/CodeGen/debug-prefix-map.c
+++ b/clang/test/CodeGen/debug-prefix-map.c
@@ -5,8 +5,6 @@
 // RUN: %clang_cc1 -debug-info-kind=standalone 
-fdebug-prefix-map=%p=/UNLIKELY_PATH/empty %s -emit-llvm -o - -isysroot %p 
-debugger-tuning=lldb | FileCheck %s -check-prefix CHECK-SYSROOT
 // RUN: %clang -g -fdebug-prefix-map=%p=/UNLIKELY_PATH/empty -S -c %s 
-emit-llvm -o - | FileCheck %s
 // RUN: %clang -g -ffile-prefix-map=%p=/UNLIKELY_PATH/empty -S -c %s 
-emit-llvm -o - | FileCheck %s
-// RUN: %clang -g -fdebug-prefix-map=%p=./UNLIKELY_PATH/empty -S -c %s 
-emit-llvm -o - | FileCheck %s --check-prefix=CHECK-REL
-// RUN: %clang -g -ffile-prefix-map=%p=./UNLIKELY_PATH/empty -S -c %s 
-emit-llvm -o - | FileCheck %s --check-prefix=CHECK-REL
 
 #include "Inputs/stdio.h"
 
@@ -44,7 +42,3 @@ void test_rewrite_includes(void) {
 // CHECK-COMPILATION-DIR: !DIFile(filename: "{{.*}}Inputs/stdio.h", directory: 
"/UNLIKELY_PATH/empty")
 // CHECK-COMPILATION-DIR-NOT: !DIFile(filename:
 // CHECK-SYSROOT: !DICompileUnit({{.*}}sysroot: "/UNLIKELY_PATH/empty"
-
-// CHECK-REL: !DIFile(filename: "./UNLIKELY_PATH/empty{{/|}}{{.*}}",
-// CHECK-REL: !DIFile(filename: 
"./UNLIKELY_PATH/empty{{/|}}{{.*}}Inputs/stdio.h",
-// CHECK-REL-SAME:directory: "")



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


[PATCH] D119309: [Driver][test] Clean up some AIX tests

2022-02-25 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

In D119309#3346892 , @jsji wrote:

> LGTM.  Thanks for cleaning up. 
> BTW: @jasonliu and  @Xiangling_L are no longer working on AIX. #powerpc 
>   might get attention from wider group.

Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119309/new/

https://reviews.llvm.org/D119309

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


[PATCH] D119309: [Driver][test] Clean up some AIX tests

2022-02-25 Thread Jinsong Ji via Phabricator via cfe-commits
jsji added subscribers: Xiangling_L, jasonliu, jsji.
jsji accepted this revision as: jsji.
jsji added a comment.
This revision is now accepted and ready to land.

LGTM.  Thanks for cleaning up. 
BTW: @jasonliu and  @Xiangling_L are no longer working on AIX. #powerpc 
  might get attention from wider group.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119309/new/

https://reviews.llvm.org/D119309

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


[PATCH] D119309: [Driver][test] Clean up some AIX tests

2022-02-25 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

Ping


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119309/new/

https://reviews.llvm.org/D119309

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


[PATCH] D117522: [clang-tidy] Add modernize-macro-to-enum check

2022-02-25 Thread Richard via Phabricator via cfe-commits
LegalizeAdulthood updated this revision to Diff 411555.
LegalizeAdulthood marked 3 inline comments as done.
LegalizeAdulthood added a comment.

- Add intention revealing functions for details of pragma once parsing


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D117522/new/

https://reviews.llvm.org/D117522

Files:
  clang-tools-extra/clang-tidy/modernize/CMakeLists.txt
  clang-tools-extra/clang-tidy/modernize/MacroToEnumCheck.cpp
  clang-tools-extra/clang-tidy/modernize/MacroToEnumCheck.h
  clang-tools-extra/clang-tidy/modernize/ModernizeTidyModule.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-macro-to-enum.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize-macro-to-enum.rst
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/modernize-macro-to-enum/modernize-macro-to-enum.h
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/modernize-macro-to-enum/modernize-macro-to-enum2.h
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/modernize-macro-to-enum/modernize-macro-to-enum3.h
  clang-tools-extra/test/clang-tidy/checkers/modernize-macro-to-enum.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/modernize-macro-to-enum.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/modernize-macro-to-enum.cpp
@@ -0,0 +1,190 @@
+// RUN: %check_clang_tidy %s modernize-macro-to-enum %t -- -- -I%S/Inputs/modernize-macro-to-enum
+
+#if 1
+#include "modernize-macro-to-enum.h"
+
+// These macros are skipped due to being inside a conditional compilation block.
+#define GOO_RED 1
+#define GOO_GREEN 2
+#define GOO_BLUE 3
+
+#endif
+
+#define RED 0xFF
+#define GREEN 0x00FF00
+#define BLUE 0xFF
+// CHECK-MESSAGES: :[[@LINE-3]]:1: warning: Replace macro with enum [modernize-macro-to-enum]
+// CHECK-MESSAGES: :[[@LINE-4]]:9: warning: Macro 'RED' defines an integral constant; prefer an enum instead
+// CHECK-MESSAGES: :[[@LINE-4]]:9: warning: Macro 'GREEN' defines an integral constant; prefer an enum instead
+// CHECK-MESSAGES: :[[@LINE-4]]:9: warning: Macro 'BLUE' defines an integral constant; prefer an enum instead
+// CHECK-FIXES: enum {
+// CHECK-FIXES-NEXT: RED = 0xFF,
+// CHECK-FIXES-NEXT: GREEN = 0x00FF00,
+// CHECK-FIXES-NEXT: BLUE = 0xFF
+// CHECK-FIXES-NEXT: };
+
+// Verify that comments are preserved.
+#define CoordModeOrigin 0   /* relative to the origin */
+#define CoordModePrevious   1   /* relative to previous point */
+// CHECK-MESSAGES: :[[@LINE-2]]:1: warning: Replace macro with enum
+// CHECK-MESSAGES: :[[@LINE-3]]:9: warning: Macro 'CoordModeOrigin' defines an integral constant; prefer an enum instead
+// CHECK-MESSAGES: :[[@LINE-3]]:9: warning: Macro 'CoordModePrevious' defines an integral constant; prefer an enum instead
+// CHECK-FIXES: enum {
+// CHECK-FIXES-NEXT: CoordModeOrigin = 0,   /* relative to the origin */
+// CHECK-FIXES-NEXT: CoordModePrevious =   1   /* relative to previous point */
+// CHECK-FIXES-NEXT: };
+
+// Verify that multiline comments are preserved.
+#define BadDrawable 9   /* parameter not a Pixmap or Window */
+#define BadAccess   10  /* depending on context:
+- key/button already grabbed
+- attempt to free an illegal 
+  cmap entry 
+- attempt to store into a read-only 
+  color map entry. */
+// - attempt to modify the access control
+//   list from other than the local host.
+//
+#define BadAlloc11  /* insufficient resources */
+// CHECK-MESSAGES: :[[@LINE-11]]:1: warning: Replace macro with enum
+// CHECK-MESSAGES: :[[@LINE-12]]:9: warning: Macro 'BadDrawable' defines an integral constant; prefer an enum instead
+// CHECK-MESSAGES: :[[@LINE-12]]:9: warning: Macro 'BadAccess' defines an integral constant; prefer an enum instead
+// CHECK-MESSAGES: :[[@LINE-4]]:9: warning: Macro 'BadAlloc' defines an integral constant; prefer an enum instead
+// CHECK-FIXES: enum {
+// CHECK-FIXES-NEXT: BadDrawable = 9,   /* parameter not a Pixmap or Window */
+// CHECK-FIXES-NEXT: BadAccess =   10,  /* depending on context:
+// CHECK-FIXES-NEXT: - key/button already grabbed
+// CHECK-FIXES-NEXT: - attempt to free an illegal 
+// CHECK-FIXES-NEXT:   cmap entry 
+// CHECK-FIXES-NEXT: - attempt to store into a read-only 
+// CHECK-FIXES-NEXT:   color map entry. */
+// CHECK-FIXES-NEXT: // - attempt to modify the access control
+// CHECK-FIXES-NEXT:   

[PATCH] D120305: [Driver] Default CLANG_DEFAULT_PIE_ON_LINUX to ON

2022-02-25 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

In D120305#3346787 , @nemanjai wrote:

> In D120305#3346144 , @MaskRay wrote:
>
>> In D120305#3345978 , @MaskRay 
>> wrote:
>>
>>> In D120305#3345810 , @RKSimon 
>>> wrote:
>>>
 @MaskRay The ppc buildbots have been red since these patches - please can 
 you take a look? https://lab.llvm.org/buildbot/#/builders/57/builds/15454
>>>
>>> Seems that ppc64 doesn't support test/sanitizer_common test/crt -fpie. I'll 
>>> just disable them: https://github.com/llvm/llvm-project/issues/54084
>>
>> Actually I don't know how to disable the tests: 
>> https://lab.llvm.org/buildbot/#/builders/57/builds/15497 still failed.
>> Hope someone from #powerpc  can 
>> disable them.
>
> This does not appear to be a matter of simply marking some tests as 
> UNSUPPORTED. Since this landed, there have been many builds with different 
> sanitizer failures and different numbers of sanitizer failures. Please pull 
> this patch to bring the bots back to green and we can work with you next week 
> on fixing what needs to be fixed.

I enabled -DCLANG_DEFAULT_PIE_ON_LINUX=OFF for clang-ppc64le-rhel: 
https://github.com/llvm/llvm-zorg/commit/b6ddf02ce3a54da2df29e7e599b1838167e0e3ad
which should fix the issues.

While I feel sorry for leaving clang-ppc64le-rhel red for some time and am 
willing to fix issues if I have access to a ppc64 machine (especially 
compiler-rt ones that I care about),
I feel uncomfortably if a group just bluntly request "please pull this patch" 
when apparently (a) there is a better approach (explicitly setting 
CLANG_DEFAULT_PIE_ON_LINUX=OFF) and (b) there is something a bot maintainer can 
do
and (c) there is just some inherent stability problem (in this case, consider 
not enabling the testing when the target is still unstable).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120305/new/

https://reviews.llvm.org/D120305

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


[PATCH] D113718: Don't append the working directory to absolute paths

2022-02-25 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

Breaks tests on Linux and Mac, e.g. http://45.33.8.238/linux/69643/step_7.txt 
and http://45.33.8.238/win/53984/step_7.txt

Please take a look and revert for now if it takes a while to fix.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113718/new/

https://reviews.llvm.org/D113718

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


[PATCH] D117522: [clang-tidy] Add modernize-macro-to-enum check

2022-02-25 Thread Richard via Phabricator via cfe-commits
LegalizeAdulthood marked 5 inline comments as done.
LegalizeAdulthood added inline comments.



Comment at: clang-tools-extra/clang-tidy/modernize/MacroToEnumCheck.cpp:382
+
+  if (std::strncmp("pragma", Text, 6) != 0)
+return;

carlosgalvezp wrote:
> Maybe wrap the raw strings inside a StringRef for a more robust and readable 
> comparison? Not a big fan of the magic 6 there :) 
OK, I've added some intention revealing functions that I think clean this up.  
I'm testing now and will upload a diff when the tests pass.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/modernize-macro-to-enum.rst:9-13
+
+This check can be used to enforce the C++ core guideline `Enum.1:
+Prefer enumerations over macros
+`_,
+within the constraints outlined below.

carlosgalvezp wrote:
> Oh, it's right here :) I suppose as a user I would expect to find this info 
> in the cppcoreguidelines doc, not here. But again I don't know what the 
> de-facto pattern is with aliases so I'll leave that to someone that knows 
> better.
[[ 
https://clang.llvm.org/extra/clang-tidy/checks/readability-magic-numbers.html | 
readability-magic-numbers ]] is similar; the alias simply links to the 
readability check and the readability check cites the C++ Core Guideline with a 
link.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/modernize-macro-to-enum.rst:19
+- Macros must be defined on sequential source file lines, or with
+  only comment lines in between macro definitions.
+- Macros must all be defined in the same source file.

carlosgalvezp wrote:
> Hmm, what about this situation?
> 
> 
> ```
> // This is some macro
> #define FOO 123
> // This is some other unrelated macro
> #define BAR 321
> ```
> 
> Would the check group these 2 together? Personally I'd put an empty line 
> between the two to show they are unrelated, but I know many people prefer to 
> save vertical space and keep everything tight without empty lines.
They're "grouped" into the same anonymous enum.  The basic heuristic is that 
blank lines separate groups of related identifiers, not comment lines.  This is 
the most common pattern in header files with macros that I've observed for 
decades.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D117522/new/

https://reviews.llvm.org/D117522

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


[PATCH] D116577: [clang-tidy] Added "boost-use-range-based-for-loop" check

2022-02-25 Thread Denis Mikhailov via Phabricator via cfe-commits
denzor200 added a comment.

My apologize for the delay! Diff was updated, implemented detection of known 
failure cases in the matcher and not issue a fixit, just only diagnostic.




Comment at: clang-tools-extra/clang-tidy/boost/UseRangeBasedForLoopCheck.cpp:68
+ ColToken->getLocation()),
+   (llvm::Twine("for(") + VariableString + " : ").str());
+  }

LegalizeAdulthood wrote:
> Now that this is chained, you might need to `clang-format` on it again.
> 
> Probably best to just `clang-format` the whole file before you submit.
`clang-format` was already applied


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116577/new/

https://reviews.llvm.org/D116577

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


[PATCH] D120305: [Driver] Default CLANG_DEFAULT_PIE_ON_LINUX to ON

2022-02-25 Thread Nemanja Ivanovic via Phabricator via cfe-commits
nemanjai added a comment.

In D120305#3346144 , @MaskRay wrote:

> In D120305#3345978 , @MaskRay wrote:
>
>> In D120305#3345810 , @RKSimon 
>> wrote:
>>
>>> @MaskRay The ppc buildbots have been red since these patches - please can 
>>> you take a look? https://lab.llvm.org/buildbot/#/builders/57/builds/15454
>>
>> Seems that ppc64 doesn't support test/sanitizer_common test/crt -fpie. I'll 
>> just disable them: https://github.com/llvm/llvm-project/issues/54084
>
> Actually I don't know how to disable the tests: 
> https://lab.llvm.org/buildbot/#/builders/57/builds/15497 still failed.
> Hope someone from #powerpc  can 
> disable them.

This does not appear to be a matter of simply marking some tests as 
UNSUPPORTED. Since this landed, there have been many builds with different 
sanitizer failures and different numbers of sanitizer failures. Please pull 
this patch to bring the bots back to green and we can work with you next week 
on fixing what needs to be fixed.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120305/new/

https://reviews.llvm.org/D120305

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


[PATCH] D116577: [clang-tidy] Added "boost-use-range-based-for-loop" check

2022-02-25 Thread Denis Mikhailov via Phabricator via cfe-commits
denzor200 updated this revision to Diff 411548.
denzor200 marked 6 inline comments as done.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116577/new/

https://reviews.llvm.org/D116577

Files:
  clang-tools-extra/clang-tidy/boost/BoostTidyModule.cpp
  clang-tools-extra/clang-tidy/boost/CMakeLists.txt
  clang-tools-extra/clang-tidy/boost/UseRangeBasedForLoopCheck.cpp
  clang-tools-extra/clang-tidy/boost/UseRangeBasedForLoopCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/boost-use-range-based-for-loop.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/checkers/boost-use-range-based-for-loop.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/boost-use-range-based-for-loop.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/boost-use-range-based-for-loop.cpp
@@ -0,0 +1,229 @@
+// RUN: %check_clang_tidy %s boost-use-range-based-for-loop %t
+
+namespace std {
+template 
+class list {
+public:
+  using iterator = T*;
+  using value_type = T;
+  iterator begin();
+  iterator end();
+};
+template 
+class map {};
+template 
+class tuple {};
+template 
+struct pair {
+  explicit pair(const First&, const Second&);
+};
+}
+
+#define BOOST_FOREACH(VAR, COL) for(VAR;(COL, false);)
+#define IDENTITY_TYPE(...) __VA_ARGS__
+
+void test_range_based_for_loop()
+{
+  std::list list_int;
+  BOOST_FOREACH( int i, list_int ) {
+// do something with i
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead of BOOST_FOREACH [boost-use-range-based-for-loop]
+  // CHECK-FIXES: for( int i: list_int ) {
+
+  short array_short[] = {1,2,3};
+  BOOST_FOREACH(int val, array_short) {
+/// The short was implicitly converted to an int
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based
+  // CHECK-FIXES: for(int val: array_short) {
+}
+
+#define foreach_ BOOST_FOREACH
+#define foreach_2nd_ foreach_
+
+void test_range_based_for_loop_prettier()
+{
+  std::list l;
+  foreach_( int i, l ) {
+// do something with i
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based 
+  // CHECK-FIXES: for( int i: l ) {
+
+  short array_short[] = {1,2,3};
+  foreach_2nd_(int val, array_short) {
+/// The short was implicitly converted to an int
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based
+  // CHECK-FIXES: for(int val: array_short) {
+}
+
+template
+void test_range_based_for_loop_in_template_instantiation(const std::list& some_list
+	   , const Containter& some_containter)
+{
+  std::list list_int;
+  BOOST_FOREACH( int i, list_int ) {
+// do something with i
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead of BOOST_FOREACH [boost-use-range-based-for-loop]
+  // CHECK-FIXES: for( int i: list_int ) {
+
+  // FIXME
+#if 0
+  BOOST_FOREACH( T i, some_list ) {
+// do something with i
+  }
+  // :[[@LINE-3]]:3: warning: use range-based for loop instead of BOOST_FOREACH [boost-use-range-based-for-loop]
+  // for( T i: some_list ) {
+#endif
+
+  BOOST_FOREACH( typename Containter::value_type i, some_containter ) {
+// do something with i
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead of BOOST_FOREACH [boost-use-range-based-for-loop]
+  // CHECK-FIXES: BOOST_FOREACH( typename Containter::value_type i, some_containter ) {
+  // ^ so no fix-its here.
+}
+
+void test_range_based_for_loop_without_spaces()
+{
+  std::list> l;
+  BOOST_FOREACH(std::listi,l){
+// do something with i
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based 
+  // CHECK-FIXES: for(std::listi:l){
+}
+
+void test_range_based_for_loop_no_migration()
+{
+  // FIXME: implement these migrations and remove here tests
+  std::list l;
+  using rng = std::pair::iterator, std::list::iterator>;
+
+  int i;
+  BOOST_FOREACH( i, l ) {
+// do something with i
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based 
+  // CHECK-FIXES: BOOST_FOREACH( i, l ) {
+  // ^ so no fix-its here.
+
+  BOOST_FOREACH( int val, rng(l.begin(), l.end()) ) {
+// do something with i
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based 
+  // CHECK-FIXES: BOOST_FOREACH( int val, rng(l.begin(), l.end()) ) {
+  // ^ so no fix-its here.
+}
+
+void test_range_based_for_loop_keep_comments()
+{
+  std::list l;
+  std::list l2;
+
+  /* 1 */ BOOST_FOREACH( int i, l=l2 ) {
+// do something with i
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:11: warning: use range-based
+  // CHECK-FIXES: /* 1 */ for( int i: l=l2 ) {
+
+  BOOST_FOREACH /* 1 */ ( int i, l=l2 ) {
+// do something with i
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based
+  // CHECK-FIXES: for /* 1 */ ( int i: l=l2 ) {
+
+  BOOST_FOREACH( /* 1 */ int i, l=l2 ) {
+// do something w

[PATCH] D118599: [C++20][Modules][8/8] Amend module visibility rules for partitions.

2022-02-25 Thread Iain Sandoe via Phabricator via cfe-commits
iains updated this revision to Diff 411547.
iains added a comment.

rebased


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D118599/new/

https://reviews.llvm.org/D118599

Files:
  clang/lib/Sema/SemaLookup.cpp
  clang/test/Modules/cxx20-10-1-ex2.cpp


Index: clang/test/Modules/cxx20-10-1-ex2.cpp
===
--- clang/test/Modules/cxx20-10-1-ex2.cpp
+++ clang/test/Modules/cxx20-10-1-ex2.cpp
@@ -12,7 +12,6 @@
 // RUN: %clang_cc1 -std=c++20 -emit-module-interface %t/std10-1-ex2-tu3.cpp \
 // RUN:   -o %t/B_X1.pcm -verify
 
-// Not expected to work yet.
 //  %clang_cc1 -std=c++20 -emit-module-interface %t/std10-1-ex2-tu4.cpp \
 //   -fmodule-file=%t/B.pcm  -o %t/B_X2.pcm
 
@@ -22,7 +21,6 @@
 // RUN: %clang_cc1 -std=c++20 -S %t/std10-1-ex2-tu6.cpp \
 // RUN:  -fmodule-file=%t/B.pcm  -o %t/b_tu6.s -verify
 
-// Not expected to work yet.
 //  %clang_cc1 -std=c++20 -emit-module-interface %t/std10-1-ex2-tu7.cpp \
 //   -fmodule-file=%t/B_X2.pcm  -o %t/B_X3.pcm -verify
 
Index: clang/lib/Sema/SemaLookup.cpp
===
--- clang/lib/Sema/SemaLookup.cpp
+++ clang/lib/Sema/SemaLookup.cpp
@@ -1687,8 +1687,8 @@
   Module *DeclModule = SemaRef.getOwningModule(D);
   assert(DeclModule && "hidden decl has no owning module");
 
-  // If the owning module is visible, the decl is visible.
   if (SemaRef.isModuleVisible(DeclModule, D->isModulePrivate()))
+// If the owning module is visible, the decl is visible.
 return true;
 
   // Determine whether a decl context is a file context for the purpose of
@@ -1762,6 +1762,22 @@
   if (ModulePrivate) {
 if (isInCurrentModule(M, getLangOpts()))
   return true;
+else if (M->Kind == Module::ModuleKind::ModulePartitionImplementation &&
+ isModuleDirectlyImported(M))
+  // Unless a partition implementation is directly imported it is not
+  // counted as visible for lookup, although the contained decls might
+  // still be reachable.  It's a partition, so it must be part of the
+  // current module to be a valid import.
+  return true;
+else if (getLangOpts().CPlusPlusModules && !ModuleScopes.empty() &&
+ ModuleScopes[0].Module->Kind ==
+ Module::ModuleKind::ModulePartitionImplementation &&
+ ModuleScopes[0].Module->getPrimaryModuleInterfaceName() ==
+ M->Name &&
+ isModuleDirectlyImported(M))
+  // We are building a module implementation partition and the TU imports
+  // the primary module interface unit.
+  return true;
   } else {
 if (VisibleModules.isVisible(M))
   return true;


Index: clang/test/Modules/cxx20-10-1-ex2.cpp
===
--- clang/test/Modules/cxx20-10-1-ex2.cpp
+++ clang/test/Modules/cxx20-10-1-ex2.cpp
@@ -12,7 +12,6 @@
 // RUN: %clang_cc1 -std=c++20 -emit-module-interface %t/std10-1-ex2-tu3.cpp \
 // RUN:   -o %t/B_X1.pcm -verify
 
-// Not expected to work yet.
 //  %clang_cc1 -std=c++20 -emit-module-interface %t/std10-1-ex2-tu4.cpp \
 //   -fmodule-file=%t/B.pcm  -o %t/B_X2.pcm
 
@@ -22,7 +21,6 @@
 // RUN: %clang_cc1 -std=c++20 -S %t/std10-1-ex2-tu6.cpp \
 // RUN:  -fmodule-file=%t/B.pcm  -o %t/b_tu6.s -verify
 
-// Not expected to work yet.
 //  %clang_cc1 -std=c++20 -emit-module-interface %t/std10-1-ex2-tu7.cpp \
 //   -fmodule-file=%t/B_X2.pcm  -o %t/B_X3.pcm -verify
 
Index: clang/lib/Sema/SemaLookup.cpp
===
--- clang/lib/Sema/SemaLookup.cpp
+++ clang/lib/Sema/SemaLookup.cpp
@@ -1687,8 +1687,8 @@
   Module *DeclModule = SemaRef.getOwningModule(D);
   assert(DeclModule && "hidden decl has no owning module");
 
-  // If the owning module is visible, the decl is visible.
   if (SemaRef.isModuleVisible(DeclModule, D->isModulePrivate()))
+// If the owning module is visible, the decl is visible.
 return true;
 
   // Determine whether a decl context is a file context for the purpose of
@@ -1762,6 +1762,22 @@
   if (ModulePrivate) {
 if (isInCurrentModule(M, getLangOpts()))
   return true;
+else if (M->Kind == Module::ModuleKind::ModulePartitionImplementation &&
+ isModuleDirectlyImported(M))
+  // Unless a partition implementation is directly imported it is not
+  // counted as visible for lookup, although the contained decls might
+  // still be reachable.  It's a partition, so it must be part of the
+  // current module to be a valid import.
+  return true;
+else if (getLangOpts().CPlusPlusModules && !ModuleScopes.empty() &&
+ ModuleScopes[0].Module->Kind ==
+ Module::ModuleKind::ModulePartitionImplementation &&
+ ModuleScopes[0].Module->getPrimaryModuleInterfaceName() ==
+ M->Name &&
+ isModuleDirectlyImported(M))
+  // We

[PATCH] D118598: [C++20][Modules][7/8] Find the primary interface name for a module.

2022-02-25 Thread Iain Sandoe via Phabricator via cfe-commits
iains updated this revision to Diff 411546.
iains added a comment.

rebased


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D118598/new/

https://reviews.llvm.org/D118598

Files:
  clang/include/clang/Basic/Module.h
  clang/lib/Sema/SemaModule.cpp


Index: clang/lib/Sema/SemaModule.cpp
===
--- clang/lib/Sema/SemaModule.cpp
+++ clang/lib/Sema/SemaModule.cpp
@@ -382,17 +382,10 @@
 // We already checked that we are in a module purview in the parser.
 assert(!ModuleScopes.empty() && "in a module purview, but no module?");
 Module *NamedMod = ModuleScopes.back().Module;
-if (ModuleScopes.back().IsPartition) {
-  // We're importing a partition into a partition, find the name of the
-  // owning named module.
-  size_t P = NamedMod->Name.find_first_of(":");
-  ModuleName = NamedMod->Name.substr(0, P + 1);
-} else {
-  // We're importing a partition into the named module itself (either the
-  // interface or an implementation TU).
-  ModuleName = NamedMod->Name;
-  ModuleName += ":";
-}
+// If we are importing into a partition, find the owning named module,
+// otherwise, the name of the importing named module.
+ModuleName = NamedMod->getPrimaryModuleInterfaceName().str();
+ModuleName += ":";
 ModuleName += stringFromPath(Partition);
 ModuleNameLoc = {PP.getIdentifierInfo(ModuleName), Partition[0].second};
 Partition = ModuleIdPath(ModuleNameLoc);
Index: clang/include/clang/Basic/Module.h
===
--- clang/include/clang/Basic/Module.h
+++ clang/include/clang/Basic/Module.h
@@ -517,6 +517,16 @@
   /// Is this a module partition.
   bool isModulePartition() const { return Name.find(':') != std::string::npos; 
}
 
+  /// Get the primary module interface name from a partition.
+  StringRef getPrimaryModuleInterfaceName() const {
+if (Kind == ModulePartitionInterface ||
+Kind == ModulePartitionImplementation) {
+  auto pos = Name.find(':');
+  return StringRef(Name.data(), pos);
+}
+return Name;
+  }
+
   /// Retrieve the full name of this module, including the path from
   /// its top-level module.
   /// \param AllowStringLiterals If \c true, components that might not be


Index: clang/lib/Sema/SemaModule.cpp
===
--- clang/lib/Sema/SemaModule.cpp
+++ clang/lib/Sema/SemaModule.cpp
@@ -382,17 +382,10 @@
 // We already checked that we are in a module purview in the parser.
 assert(!ModuleScopes.empty() && "in a module purview, but no module?");
 Module *NamedMod = ModuleScopes.back().Module;
-if (ModuleScopes.back().IsPartition) {
-  // We're importing a partition into a partition, find the name of the
-  // owning named module.
-  size_t P = NamedMod->Name.find_first_of(":");
-  ModuleName = NamedMod->Name.substr(0, P + 1);
-} else {
-  // We're importing a partition into the named module itself (either the
-  // interface or an implementation TU).
-  ModuleName = NamedMod->Name;
-  ModuleName += ":";
-}
+// If we are importing into a partition, find the owning named module,
+// otherwise, the name of the importing named module.
+ModuleName = NamedMod->getPrimaryModuleInterfaceName().str();
+ModuleName += ":";
 ModuleName += stringFromPath(Partition);
 ModuleNameLoc = {PP.getIdentifierInfo(ModuleName), Partition[0].second};
 Partition = ModuleIdPath(ModuleNameLoc);
Index: clang/include/clang/Basic/Module.h
===
--- clang/include/clang/Basic/Module.h
+++ clang/include/clang/Basic/Module.h
@@ -517,6 +517,16 @@
   /// Is this a module partition.
   bool isModulePartition() const { return Name.find(':') != std::string::npos; }
 
+  /// Get the primary module interface name from a partition.
+  StringRef getPrimaryModuleInterfaceName() const {
+if (Kind == ModulePartitionInterface ||
+Kind == ModulePartitionImplementation) {
+  auto pos = Name.find(':');
+  return StringRef(Name.data(), pos);
+}
+return Name;
+  }
+
   /// Retrieve the full name of this module, including the path from
   /// its top-level module.
   /// \param AllowStringLiterals If \c true, components that might not be
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D118589: [C++20][Modules][6/8] Record direct module imports.

2022-02-25 Thread Iain Sandoe via Phabricator via cfe-commits
iains updated this revision to Diff 411545.
iains added a comment.

rebased


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D118589/new/

https://reviews.llvm.org/D118589

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaModule.cpp


Index: clang/lib/Sema/SemaModule.cpp
===
--- clang/lib/Sema/SemaModule.cpp
+++ clang/lib/Sema/SemaModule.cpp
@@ -514,6 +514,11 @@
 assert(ThisModule && "was expecting a module if building one");
   }
 
+  // In some cases we need to know if an entity was present in a directly-
+  // imported module (as opposed to a transitive import).  This avoids
+  // searching both Imports and Exports.
+  DirectModuleImports.insert(Mod);
+
   return Import;
 }
 
Index: clang/include/clang/Sema/Sema.h
===
--- clang/include/clang/Sema/Sema.h
+++ clang/include/clang/Sema/Sema.h
@@ -2219,6 +2219,9 @@
   /// The global module fragment of the current translation unit.
   clang::Module *GlobalModuleFragment = nullptr;
 
+  /// The modules we imported directly.
+  llvm::SmallPtrSet DirectModuleImports;
+
   /// Namespace definitions that we will export when they finish.
   llvm::SmallPtrSet DeferredExportedNamespaces;
 
@@ -2246,6 +2249,10 @@
 return Entity->getOwningModule();
   }
 
+  bool isModuleDirectlyImported(const Module *M) {
+return DirectModuleImports.contains(M);
+  }
+
   /// Make a merged definition of an existing hidden definition \p ND
   /// visible at the specified location.
   void makeMergedDefinitionVisible(NamedDecl *ND);


Index: clang/lib/Sema/SemaModule.cpp
===
--- clang/lib/Sema/SemaModule.cpp
+++ clang/lib/Sema/SemaModule.cpp
@@ -514,6 +514,11 @@
 assert(ThisModule && "was expecting a module if building one");
   }
 
+  // In some cases we need to know if an entity was present in a directly-
+  // imported module (as opposed to a transitive import).  This avoids
+  // searching both Imports and Exports.
+  DirectModuleImports.insert(Mod);
+
   return Import;
 }
 
Index: clang/include/clang/Sema/Sema.h
===
--- clang/include/clang/Sema/Sema.h
+++ clang/include/clang/Sema/Sema.h
@@ -2219,6 +2219,9 @@
   /// The global module fragment of the current translation unit.
   clang::Module *GlobalModuleFragment = nullptr;
 
+  /// The modules we imported directly.
+  llvm::SmallPtrSet DirectModuleImports;
+
   /// Namespace definitions that we will export when they finish.
   llvm::SmallPtrSet DeferredExportedNamespaces;
 
@@ -2246,6 +2249,10 @@
 return Entity->getOwningModule();
   }
 
+  bool isModuleDirectlyImported(const Module *M) {
+return DirectModuleImports.contains(M);
+  }
+
   /// Make a merged definition of an existing hidden definition \p ND
   /// visible at the specified location.
   void makeMergedDefinitionVisible(NamedDecl *ND);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D113718: Don't append the working directory to absolute paths

2022-02-25 Thread Alex Brachet via Phabricator via cfe-commits
abrachet added a comment.

We're seeing test failures in 
https://ci.chromium.org/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64/b8821217427732511185/overview


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113718/new/

https://reviews.llvm.org/D113718

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


[PATCH] D118588: [C++20][Modules]5/8] Diagnose wrong import/export for partition CMIs.

2022-02-25 Thread Iain Sandoe via Phabricator via cfe-commits
iains updated this revision to Diff 411544.
iains added a comment.

rebased


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D118588/new/

https://reviews.llvm.org/D118588

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaModule.cpp
  clang/test/Modules/cxx20-10-3-ex1.cpp
  clang/test/Modules/cxx20-10-3-ex2.cpp
  clang/test/Modules/cxx20-import-diagnostics-a.cpp

Index: clang/test/Modules/cxx20-import-diagnostics-a.cpp
===
--- clang/test/Modules/cxx20-import-diagnostics-a.cpp
+++ clang/test/Modules/cxx20-import-diagnostics-a.cpp
@@ -118,13 +118,13 @@
 
 module B;
 
-import B; // expected-error {{import of module 'B' appears within same top-level module 'B'}}
+import B; // expected-error {{import of module 'B' appears within its own implementation}}
 
 //--- import-diags-tu10.cpp
 
 export module B;
 
-import B; // expected-error {{import of module 'B' appears within same top-level module 'B'}}
+import B; // expected-error {{import of module 'B' appears within its own interface}}
 
 //--- import-diags-tu11.cpp
 
Index: clang/test/Modules/cxx20-10-3-ex2.cpp
===
--- /dev/null
+++ clang/test/Modules/cxx20-10-3-ex2.cpp
@@ -0,0 +1,25 @@
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+// RUN: split-file %s %t
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface %t/std10-3-ex2-tu1.cpp \
+// RUN:  -o %t/M.pcm
+
+// RUN: %clang_cc1 -std=c++20 -S %t/std10-3-ex2-tu2.cpp \
+// RUN:  -fmodule-file=%t/M.pcm -o %t/tu_8.s -verify
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface %t/std10-3-ex2-tu3.cpp \
+// RUN:  -o %t/M.pcm -verify
+
+//--- std10-3-ex2-tu1.cpp
+export module M;
+
+//--- std10-3-ex2-tu2.cpp
+module M;
+  // error: cannot import M in its own unit
+import M; // expected-error {{import of module 'M' appears within its own implementation}}
+
+//--- std10-3-ex2-tu3.cpp
+export module M;
+  // error: cannot import M in its own unit
+import M; // expected-error {{import of module 'M' appears within its own interface}}
Index: clang/test/Modules/cxx20-10-3-ex1.cpp
===
--- /dev/null
+++ clang/test/Modules/cxx20-10-3-ex1.cpp
@@ -0,0 +1,36 @@
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+// RUN: split-file %s %t
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface %t/std10-3-ex1-tu1.cpp \
+// RUN:  -o %t/M_PartImpl.pcm
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface %t/std10-3-ex1-tu2.cpp \
+// RUN:  -fmodule-file=%t/M_PartImpl.pcm -o %t/M.pcm -verify
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface %t/std10-3-ex1-tu3.cpp \
+// RUN:  -o %t/M_Part.pcm
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface %t/std10-3-ex1-tu4.cpp \
+// RUN:  -fmodule-file=%t/M_Part.pcm -o %t/M.pcm
+
+//--- std10-3-ex1-tu1.cpp
+module M:PartImpl;
+
+// expected-no-diagnostics
+
+//--- std10-3-ex1-tu2.cpp
+export module M;
+ // error: exported partition :Part is an implementation unit
+export import :PartImpl; // expected-error {{module partition implementations cannot be exported}}
+
+//--- std10-3-ex1-tu3.cpp
+export module M:Part;
+
+// expected-no-diagnostics
+
+//--- std10-3-ex1-tu4.cpp
+export module M;
+export import :Part;
+
+// expected-no-diagnostics
Index: clang/lib/Sema/SemaModule.cpp
===
--- clang/lib/Sema/SemaModule.cpp
+++ clang/lib/Sema/SemaModule.cpp
@@ -403,10 +403,16 @@
   }
 
   // Diagnose self-import before attempting a load.
+  // [module.import]/9
+  // A module implementation unit of a module M that is not a module partition
+  // shall not contain a module-import-declaration nominating M.
+  // (for an implementation, the module interface is imported implicitly,
+  //  but that's handled in the module decl code).
+
   if (getLangOpts().CPlusPlusModules && isCurrentModulePurview() &&
   getCurrentModule()->Name == ModuleName) {
-Diag(ImportLoc, diag::err_module_self_import)
-<< ModuleName << getLangOpts().CurrentModule;
+Diag(ImportLoc, diag::err_module_self_import_cxx20)
+<< ModuleName << !ModuleScopes.back().ModuleInterface;
 return true;
   }
 
@@ -440,8 +446,7 @@
   // of the same top-level module. Until we do, make it an error rather than
   // silently ignoring the import.
   // FIXME: Should we warn on a redundant import of the current module?
-  if (!getLangOpts().CPlusPlusModules &&
-  Mod->getTopLevelModuleName() == getLangOpts().CurrentModule &&
+  if (Mod->getTopLevelModuleName() == getLangOpts().CurrentModule &&
   (getLangOpts().isCompilingModule() || !getLangOpts().ModulesTS)) {
 Diag(ImportLoc, getLangOpts().isCompilingModule()
 ? diag::err_module_self_import
@@ -482,7 +487,12 @@
   if (!ModuleScopes.empty())
 Context.addModuleInitializer(ModuleScopes.b

[PATCH] D120596: [clang][CGStmt] fix crash on invalid asm statement

2022-02-25 Thread Tong Zhang via Phabricator via cfe-commits
ztong0001 updated this revision to Diff 411542.
ztong0001 added a comment.

reformat test code


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120596/new/

https://reviews.llvm.org/D120596

Files:
  clang/lib/CodeGen/CGStmt.cpp
  clang/test/CodeGen/X86/x86_64-PR42672.c


Index: clang/test/CodeGen/X86/x86_64-PR42672.c
===
--- clang/test/CodeGen/X86/x86_64-PR42672.c
+++ clang/test/CodeGen/X86/x86_64-PR42672.c
@@ -5,6 +5,7 @@
 // RUN: %clang_cc1 -triple=x86_64-unknown-linux-gnu -DPOSSIBLE_X -emit-llvm %s 
-o - 2>&1 | FileCheck %s --check-prefix=CHECK-X
 // RUN: not %clang_cc1 -triple=x86_64-unknown-linux-gnu -DIMPOSSIBLE_X 
-emit-llvm %s -o - 2>&1 | FileCheck %s --check-prefix=CHECK-IMPOSSIBLE_X
 // RUN: not %clang_cc1 -triple=x86_64-unknown-linux-gnu -DIMPOSSIBLE_9BYTES 
-emit-llvm %s -o - 2>&1 | FileCheck %s --check-prefix=CHECK-IMPOSSIBLE_9BYTES
+// RUN: not %clang_cc1 -triple=x86_64-unknown-linux-gnu -DIMPOSSIBLE_9BYTES_V2 
-emit-llvm %s -o - 2>&1 | FileCheck %s --check-prefix=CHECK-IMPOSSIBLE_9BYTES_V2

 // Make sure Clang doesn't treat |lockval| as asm input.
 void _raw_spin_lock(void) {
@@ -115,3 +116,12 @@
 }

 // CHECK-IMPOSSIBLE_9BYTES: impossible constraint in asm: can't store value 
into a register
+
+void crbug_999160_regtest_v2(void) {
+#ifdef IMPOSSIBLE_9BYTES_V2
+  char buf[9];
+  asm(""
+  : "=r"(buf) : "0"(buf));
+#endif
+}
+// CHECK-IMPOSSIBLE_9BYTES_V2: impossible constraint in asm: can't store value 
into a register
Index: clang/lib/CodeGen/CGStmt.cpp
===
--- clang/lib/CodeGen/CGStmt.cpp
+++ clang/lib/CodeGen/CGStmt.cpp
@@ -2513,10 +2513,8 @@
   Arg = Builder.CreateZExt(Arg, OutputTy);
 else if (isa(OutputTy))
   Arg = Builder.CreateZExt(Arg, IntPtrTy);
-else {
-  assert(OutputTy->isFloatingPointTy() && "Unexpected output type");
+else if (OutputTy->isFloatingPointTy())
   Arg = Builder.CreateFPExt(Arg, OutputTy);
-}
   }
   // Deal with the tied operands' constraint code in adjustInlineAsmType.
   ReplaceConstraint = OutputConstraints[Output];


Index: clang/test/CodeGen/X86/x86_64-PR42672.c
===
--- clang/test/CodeGen/X86/x86_64-PR42672.c
+++ clang/test/CodeGen/X86/x86_64-PR42672.c
@@ -5,6 +5,7 @@
 // RUN: %clang_cc1 -triple=x86_64-unknown-linux-gnu -DPOSSIBLE_X -emit-llvm %s -o - 2>&1 | FileCheck %s --check-prefix=CHECK-X
 // RUN: not %clang_cc1 -triple=x86_64-unknown-linux-gnu -DIMPOSSIBLE_X -emit-llvm %s -o - 2>&1 | FileCheck %s --check-prefix=CHECK-IMPOSSIBLE_X
 // RUN: not %clang_cc1 -triple=x86_64-unknown-linux-gnu -DIMPOSSIBLE_9BYTES -emit-llvm %s -o - 2>&1 | FileCheck %s --check-prefix=CHECK-IMPOSSIBLE_9BYTES
+// RUN: not %clang_cc1 -triple=x86_64-unknown-linux-gnu -DIMPOSSIBLE_9BYTES_V2 -emit-llvm %s -o - 2>&1 | FileCheck %s --check-prefix=CHECK-IMPOSSIBLE_9BYTES_V2

 // Make sure Clang doesn't treat |lockval| as asm input.
 void _raw_spin_lock(void) {
@@ -115,3 +116,12 @@
 }

 // CHECK-IMPOSSIBLE_9BYTES: impossible constraint in asm: can't store value into a register
+
+void crbug_999160_regtest_v2(void) {
+#ifdef IMPOSSIBLE_9BYTES_V2
+  char buf[9];
+  asm(""
+  : "=r"(buf) : "0"(buf));
+#endif
+}
+// CHECK-IMPOSSIBLE_9BYTES_V2: impossible constraint in asm: can't store value into a register
Index: clang/lib/CodeGen/CGStmt.cpp
===
--- clang/lib/CodeGen/CGStmt.cpp
+++ clang/lib/CodeGen/CGStmt.cpp
@@ -2513,10 +2513,8 @@
   Arg = Builder.CreateZExt(Arg, OutputTy);
 else if (isa(OutputTy))
   Arg = Builder.CreateZExt(Arg, IntPtrTy);
-else {
-  assert(OutputTy->isFloatingPointTy() && "Unexpected output type");
+else if (OutputTy->isFloatingPointTy())
   Arg = Builder.CreateFPExt(Arg, OutputTy);
-}
   }
   // Deal with the tied operands' constraint code in adjustInlineAsmType.
   ReplaceConstraint = OutputConstraints[Output];
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D120596: [clang][CGStmt] fix crash on invalid asm statement

2022-02-25 Thread Tong Zhang via Phabricator via cfe-commits
ztong0001 created this revision.
Herald added a subscriber: pengfei.
ztong0001 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Clang is crashing on the following statement

  char var[9];
  __asm__ ("" : "=r" (var) : "0" (var));

This is similar to existing test: crbug_999160_regtest

The issue happens when EmitAsmStmt is trying to convert input to match
output type length. However, that is not guaranteed to be successful all the
time and if the statement itself is invalid like having an array type in
the example, we should give a regular error message here instead of
using assert().


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D120596

Files:
  clang/lib/CodeGen/CGStmt.cpp
  clang/test/CodeGen/X86/x86_64-PR42672.c


Index: clang/test/CodeGen/X86/x86_64-PR42672.c
===
--- clang/test/CodeGen/X86/x86_64-PR42672.c
+++ clang/test/CodeGen/X86/x86_64-PR42672.c
@@ -5,6 +5,7 @@
 // RUN: %clang_cc1 -triple=x86_64-unknown-linux-gnu -DPOSSIBLE_X -emit-llvm %s 
-o - 2>&1 | FileCheck %s --check-prefix=CHECK-X
 // RUN: not %clang_cc1 -triple=x86_64-unknown-linux-gnu -DIMPOSSIBLE_X 
-emit-llvm %s -o - 2>&1 | FileCheck %s --check-prefix=CHECK-IMPOSSIBLE_X
 // RUN: not %clang_cc1 -triple=x86_64-unknown-linux-gnu -DIMPOSSIBLE_9BYTES 
-emit-llvm %s -o - 2>&1 | FileCheck %s --check-prefix=CHECK-IMPOSSIBLE_9BYTES
+// RUN: not %clang_cc1 -triple=x86_64-unknown-linux-gnu -DIMPOSSIBLE_9BYTES_V2 
-emit-llvm %s -o - 2>&1 | FileCheck %s --check-prefix=CHECK-IMPOSSIBLE_9BYTES_V2

 // Make sure Clang doesn't treat |lockval| as asm input.
 void _raw_spin_lock(void) {
@@ -115,3 +116,12 @@
 }

 // CHECK-IMPOSSIBLE_9BYTES: impossible constraint in asm: can't store value 
into a register
+
+void crbug_999160_regtest_v2(void) {
+#ifdef IMPOSSIBLE_9BYTES_V2
+  char buf[9];
+  asm(""
+  : "=r"(buf) : "0"(buf));
+#endif
+}
+// CHECK-IMPOSSIBLE_9BYTES_V2: impossible constraint in asm: can't store value 
into a register
Index: clang/lib/CodeGen/CGStmt.cpp
===
--- clang/lib/CodeGen/CGStmt.cpp
+++ clang/lib/CodeGen/CGStmt.cpp
@@ -2513,10 +2513,8 @@
   Arg = Builder.CreateZExt(Arg, OutputTy);
 else if (isa(OutputTy))
   Arg = Builder.CreateZExt(Arg, IntPtrTy);
-else {
-  assert(OutputTy->isFloatingPointTy() && "Unexpected output type");
+else if (OutputTy->isFloatingPointTy())
   Arg = Builder.CreateFPExt(Arg, OutputTy);
-}
   }
   // Deal with the tied operands' constraint code in adjustInlineAsmType.
   ReplaceConstraint = OutputConstraints[Output];


Index: clang/test/CodeGen/X86/x86_64-PR42672.c
===
--- clang/test/CodeGen/X86/x86_64-PR42672.c
+++ clang/test/CodeGen/X86/x86_64-PR42672.c
@@ -5,6 +5,7 @@
 // RUN: %clang_cc1 -triple=x86_64-unknown-linux-gnu -DPOSSIBLE_X -emit-llvm %s -o - 2>&1 | FileCheck %s --check-prefix=CHECK-X
 // RUN: not %clang_cc1 -triple=x86_64-unknown-linux-gnu -DIMPOSSIBLE_X -emit-llvm %s -o - 2>&1 | FileCheck %s --check-prefix=CHECK-IMPOSSIBLE_X
 // RUN: not %clang_cc1 -triple=x86_64-unknown-linux-gnu -DIMPOSSIBLE_9BYTES -emit-llvm %s -o - 2>&1 | FileCheck %s --check-prefix=CHECK-IMPOSSIBLE_9BYTES
+// RUN: not %clang_cc1 -triple=x86_64-unknown-linux-gnu -DIMPOSSIBLE_9BYTES_V2 -emit-llvm %s -o - 2>&1 | FileCheck %s --check-prefix=CHECK-IMPOSSIBLE_9BYTES_V2

 // Make sure Clang doesn't treat |lockval| as asm input.
 void _raw_spin_lock(void) {
@@ -115,3 +116,12 @@
 }

 // CHECK-IMPOSSIBLE_9BYTES: impossible constraint in asm: can't store value into a register
+
+void crbug_999160_regtest_v2(void) {
+#ifdef IMPOSSIBLE_9BYTES_V2
+  char buf[9];
+  asm(""
+  : "=r"(buf) : "0"(buf));
+#endif
+}
+// CHECK-IMPOSSIBLE_9BYTES_V2: impossible constraint in asm: can't store value into a register
Index: clang/lib/CodeGen/CGStmt.cpp
===
--- clang/lib/CodeGen/CGStmt.cpp
+++ clang/lib/CodeGen/CGStmt.cpp
@@ -2513,10 +2513,8 @@
   Arg = Builder.CreateZExt(Arg, OutputTy);
 else if (isa(OutputTy))
   Arg = Builder.CreateZExt(Arg, IntPtrTy);
-else {
-  assert(OutputTy->isFloatingPointTy() && "Unexpected output type");
+else if (OutputTy->isFloatingPointTy())
   Arg = Builder.CreateFPExt(Arg, OutputTy);
-}
   }
   // Deal with the tied operands' constraint code in adjustInlineAsmType.
   ReplaceConstraint = OutputConstraints[Output];
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D120566: [OpenCL][AMDGPU]: Do not allow a call to kernel

2022-02-25 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

In D120566#3346533 , @arsenm wrote:

> In D120566#3346506 , @rjmccall 
> wrote:
>
>> Is there something which stops you from taking the address of a kernel and 
>> then calling it?  If not, are there actually any uses of kernels in the 
>> module that shouldn't be rewritten as uses of the clone?
>
> The actual amdgpu_kernel is uncallable and has a totally different ABI, and 
> is invoked by external driver code. From the user's device code perspective, 
> only the callable function version is meaningful.

I think you're misunderstanding what I'm asking.  I believe that in OpenCL, you 
can do `&someKernelFunction` in source code and then call that.  The rewrite in 
this patch does not handle non-call uses of the kernel function and so will 
continue to miscompile them.

>> I feel like this would be a lot easier to just fix in your LLVM pass so that 
>> you rewrite any uses of a kernel to use a clone instead before you rewrite 
>> the kernel.
>
> Then we can't ban calls to kernels (and would be pushing some kind of symbol 
> naming conflict decision into the backend) and in principle would have to 
> handle this actual call.

Okay, this is not an accurate description of what you're trying to do, and this 
is important to be precise about.  You are not "banning calls to kernels", 
which would be a novel language restriction and make you non-conformant to 
OpenCL.  You still have a language requirement to allow code to directly use 
kernel functions.  That is why this patch is modifying IR generation instead of 
emitting new errors in Sema.

What's happening here is that your target (very reasonably) requires kernels to 
have a special kernel entrypoint in order to be called from outside.  That 
entrypoint uses a very different ABI from ordinary functions, one which 
simplifies being dynamically called by the runtime, and so it is important that 
ordinary uses of the function don't accidentally resolve against that special 
entrypoint.  You therefore need two different functions for the kernel, one to 
satisfy standard uses and one to act as the kernel entrypoint.

Your current architecture is to generate code normally, which will produce 
what's roughly the standard entrypoint, and then have a backend pass break that 
down and produce a kernel entrypoint.  I can understand why you find that 
frustratingly limited, and I agree that it doesn't seem to handle standard uses 
correctly.  Something needs to change here.

Now, Clang supports many different kernel languages, all of which face very 
similar language/implementation problems.  It is therefore always informative 
to go check to see how other language implementors have tried to solve the 
problem you're facing.  So if you go and look at how CUDA is implemented in 
Clang, you will see that they have introduced a "kernel reference kind" to 
`GlobalDecl`, which allows them to distinguish between the kernel entrypoint 
and the standard entrypoint in IRGen.  You could very easily build on this in 
your OpenCL implementation so that Clang emits the standard entrypoint and then 
either your pass or IRGen itself fills in the kernel entrypoint by marshaling 
arguments and then calling (presumably in a way that forces inlining) the 
standard entrypoint.  That would also give you total control of how arguments 
are marshaled in the kernel entrypoint.

Alternatively, I think cloning the standard entrypoint so that uses of it are 
rewritten to a clone is reasonable enough.  I don't really see why doing the 
cloning in IRGen is necessary when you already have a module pass that does 
similar kinds of rewriting.  Doing the clone in IRGen also does not seem to 
move you closer to your goal of actually marshaling arguments differently.  
Most importantly, though, I believe you do need to rewrite all the uses and not 
just the direct calls.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120566/new/

https://reviews.llvm.org/D120566

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


[PATCH] D112774: [RISCV] Support k-ext clang intrinsics

2022-02-25 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added a comment.

Any intrinsic that takes an immediate that needs to be in certain range, needs 
to have code added to SemaChecking.cpp to validate the range. Look for the 
other places we call SemaBuiltinConstantArgRange in 
Sema::CheckRISCVBuiltinFunctionCall




Comment at: clang/include/clang/Basic/BuiltinsRISCV.def:76
+TARGET_BUILTIN(__builtin_riscv_brev8, "ZiZi", "nc", "zbkb")
+TARGET_BUILTIN(__builtin_riscv_zip, "ZiZi", "nc", "zbkb")
+TARGET_BUILTIN(__builtin_riscv_unzip, "ZiZi", "nc", "zbkb")

Nothing is preventing __builtin_riscv_zip/unzip from being used on RV64 which 
will crash. We don't have a "32bit" feature flag so we can't fix it from here. 
You'll need to go into clang/lib/Sema/SemaChecking.cpp and implement something 
like where X86 emits err_32_bit_builtin_64_bit_tgt. Same is true for any other 
32-bit only intrinsic.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D112774/new/

https://reviews.llvm.org/D112774

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


[PATCH] D119816: [SanitizerBounds] Add support for NoSanitizeBounds function

2022-02-25 Thread Tong Zhang via Phabricator via cfe-commits
ztong0001 added a comment.

In D119816#3346575 , @kees wrote:

> FWIW, related problems with `pskb_expand_head` were seen again here:
> https://github.com/ClangBuiltLinux/linux/issues/1599
>
> I have trouble reproducing it, but I think the kernel patch there solves the 
> problem created by `__alloc_size` vs `ksize()`.

yes, the __asm__ ("" : "=r" (p) : "0" (p)); really did the trick


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119816/new/

https://reviews.llvm.org/D119816

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


[PATCH] D120395: [X86] Prohibit arithmetic operations on type `__bfloat16`

2022-02-25 Thread Steve Canon via Phabricator via cfe-commits
scanon added a comment.

There's a lot of churn around proposed "solutions" on this and related PR, but 
not a very clear analysis of what the problem we're trying to solve is.

Concretely, what are the semantics that we want for the BF16 types and 
intrinsics? Unlike the other floating-point types, there's no standard to guide 
this, so it's even more important to clearly specify how these types are to be 
used, instead of having an ad-hoc semantics of whatever someone happens to 
implement.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120395/new/

https://reviews.llvm.org/D120395

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


[PATCH] D113372: [Driver] Add CLANG_DEFAULT_PIE_ON_LINUX to emulate GCC --enable-default-pie

2022-02-25 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

In D113372#3316751 , @mgorny wrote:

> When enabled, this seems to break a fair number of tests:
>
>   Clang :: CodeGen/mips-vector-return.c
>   Clang :: Driver/hexagon-toolchain-elf.c
>   Clang :: Driver/hip-fpie-option.hip
>   Clang :: Driver/mips-cs.cpp
>   Clang :: Driver/mips-fsf.cpp
>   Clang :: Driver/mips-img-v2.cpp
>   Clang :: Driver/mips-img.cpp
>   Clang :: Driver/mips-mti-linux.c
>
> I've been able to get the hexagon test to work by passing `-fno-pie` 
> explicitly but others don't seem this easy.

In release/14.x, these have all been fixed.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113372/new/

https://reviews.llvm.org/D113372

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


[PATCH] D119816: [SanitizerBounds] Add support for NoSanitizeBounds function

2022-02-25 Thread Kees Cook via Phabricator via cfe-commits
kees added a comment.

FWIW, related problems with `pskb_expand_head` were seen again here:
https://github.com/ClangBuiltLinux/linux/issues/1599

I have trouble reproducing it, but I think the kernel patch there solves the 
problem created by `__alloc_size` vs `ksize()`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119816/new/

https://reviews.llvm.org/D119816

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


[PATCH] D120266: [clang][CodeGen] Avoid emitting ifuncs with undefined resolvers

2022-02-25 Thread Itay Bookstein via Phabricator via cfe-commits
ibookstein updated this revision to Diff 411521.
ibookstein added a comment.

Add tests for specific>usage>dispatch and dispatch>usage>specific
orderings.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120266/new/

https://reviews.llvm.org/D120266

Files:
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/CodeGen/attr-cpuspecific.c

Index: clang/test/CodeGen/attr-cpuspecific.c
===
--- clang/test/CodeGen/attr-cpuspecific.c
+++ clang/test/CodeGen/attr-cpuspecific.c
@@ -8,9 +8,12 @@
 #endif // _MSC_VER
 
 // Each version should have an IFunc and an alias.
+// LINUX: @SingleVersion = weak_odr alias void (), void ()* @SingleVersion.ifunc
 // LINUX: @TwoVersions = weak_odr alias void (), void ()* @TwoVersions.ifunc
+// LINUX: @OrderDispatchUsageSpecific = weak_odr alias void (), void ()* @OrderDispatchUsageSpecific.ifunc
 // LINUX: @TwoVersionsSameAttr = weak_odr alias void (), void ()* @TwoVersionsSameAttr.ifunc
 // LINUX: @ThreeVersionsSameAttr = weak_odr alias void (), void ()* @ThreeVersionsSameAttr.ifunc
+// LINUX: @OrderSpecificUsageDispatch = weak_odr alias void (), void ()* @OrderSpecificUsageDispatch.ifunc
 // LINUX: @NoSpecifics = weak_odr alias void (), void ()* @NoSpecifics.ifunc
 // LINUX: @HasGeneric = weak_odr alias void (), void ()* @HasGeneric.ifunc
 // LINUX: @HasParams = weak_odr alias void (i32, double), void (i32, double)* @HasParams.ifunc
@@ -18,10 +21,12 @@
 // LINUX: @GenericAndPentium = weak_odr alias i32 (i32, double), i32 (i32, double)* @GenericAndPentium.ifunc
 // LINUX: @DispatchFirst = weak_odr alias i32 (), i32 ()* @DispatchFirst.ifunc
 
-// LINUX: @TwoVersions.ifunc = weak_odr ifunc void (), void ()* ()* @TwoVersions.resolver
 // LINUX: @SingleVersion.ifunc = weak_odr ifunc void (), void ()* ()* @SingleVersion.resolver
+// LINUX: @TwoVersions.ifunc = weak_odr ifunc void (), void ()* ()* @TwoVersions.resolver
+// LINUX: @OrderDispatchUsageSpecific.ifunc = weak_odr ifunc void (), void ()* ()* @OrderDispatchUsageSpecific.resolver
 // LINUX: @TwoVersionsSameAttr.ifunc = weak_odr ifunc void (), void ()* ()* @TwoVersionsSameAttr.resolver
 // LINUX: @ThreeVersionsSameAttr.ifunc = weak_odr ifunc void (), void ()* ()* @ThreeVersionsSameAttr.resolver
+// LINUX: @OrderSpecificUsageDispatch.ifunc = weak_odr ifunc void (), void ()* ()* @OrderSpecificUsageDispatch.resolver
 // LINUX: @NoSpecifics.ifunc = weak_odr ifunc void (), void ()* ()* @NoSpecifics.resolver
 // LINUX: @HasGeneric.ifunc = weak_odr ifunc void (), void ()* ()* @HasGeneric.resolver
 // LINUX: @HasParams.ifunc = weak_odr ifunc void (i32, double), void (i32, double)* ()* @HasParams.resolver
@@ -34,6 +39,21 @@
 // LINUX: define{{.*}} void @SingleVersion.S() #[[S:[0-9]+]]
 // WINDOWS: define dso_local void @SingleVersion.S() #[[S:[0-9]+]]
 
+ATTR(cpu_dispatch(ivybridge))
+void SingleVersion(void);
+// LINUX: define weak_odr void ()* @SingleVersion.resolver()
+// LINUX: call void @__cpu_indicator_init
+// LINUX: ret void ()* @SingleVersion.S
+// LINUX: call void @llvm.trap
+// LINUX: unreachable
+
+// WINDOWS: define weak_odr dso_local void @SingleVersion() comdat
+// WINDOWS: call void @__cpu_indicator_init()
+// WINDOWS: call void @SingleVersion.S()
+// WINDOWS-NEXT: ret void
+// WINDOWS: call void @llvm.trap
+// WINDOWS: unreachable
+
 ATTR(cpu_specific(ivybridge))
 void NotCalled(void){}
 // LINUX: define{{.*}} void @NotCalled.S() #[[S]]
@@ -80,6 +100,31 @@
 // CHECK: define {{.*}}void @ThreeVersionsSameAttr.S() #[[S]]
 // CHECK: define {{.*}}void @ThreeVersionsSameAttr.Z() #[[K]]
 
+ATTR(cpu_specific(knl))
+void CpuSpecificNoDispatch(void) {}
+// CHECK: define {{.*}}void @CpuSpecificNoDispatch.Z() #[[K:[0-9]+]]
+
+ATTR(cpu_dispatch(knl))
+void OrderDispatchUsageSpecific(void);
+// LINUX: define weak_odr void ()* @OrderDispatchUsageSpecific.resolver()
+// LINUX: call void @__cpu_indicator_init
+// LINUX: ret void ()* @OrderDispatchUsageSpecific.Z
+// LINUX: call void @llvm.trap
+// LINUX: unreachable
+
+// WINDOWS: define weak_odr dso_local void @OrderDispatchUsageSpecific() comdat
+// WINDOWS: call void @__cpu_indicator_init()
+// WINDOWS: call void @OrderDispatchUsageSpecific.Z()
+// WINDOWS-NEXT: ret void
+// WINDOWS: call void @llvm.trap
+// WINDOWS: unreachable
+
+// CHECK: define {{.*}}void @OrderDispatchUsageSpecific.Z()
+
+ATTR(cpu_specific(knl))
+void OrderSpecificUsageDispatch(void) {}
+// CHECK: define {{.*}}void @OrderSpecificUsageDispatch.Z() #[[K:[0-9]+]]
+
 void usages(void) {
   SingleVersion();
   // LINUX: @SingleVersion.ifunc()
@@ -93,8 +138,19 @@
   ThreeVersionsSameAttr();
   // LINUX: @ThreeVersionsSameAttr.ifunc()
   // WINDOWS: @ThreeVersionsSameAttr()
+  CpuSpecificNoDispatch();
+  // LINUX: @CpuSpecificNoDispatch.ifunc()
+  // WINDOWS: @CpuSpecificNoDispatch()
+  OrderDispatchUsageSpecific();
+  // LINUX: @OrderDispatchUsageSpecific.ifunc()
+  // WINDOWS: @OrderDispatchUsageSpecific()
+  Orde

[PATCH] D120566: [OpenCL][AMDGPU]: Do not allow a call to kernel

2022-02-25 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added a comment.

In D120566#3346506 , @rjmccall wrote:

> Is there something which stops you from taking the address of a kernel and 
> then calling it?  If not, are there actually any uses of kernels in the 
> module that shouldn't be rewritten as uses of the clone?

The actual amdgpu_kernel is uncallable and has a totally different ABI, and is 
invoked by external driver code. From the user's device code perspective, only 
the callable function version is meaningful.

> I feel like this would be a lot easier to just fix in your LLVM pass so that 
> you rewrite any uses of a kernel to use a clone instead before you rewrite 
> the kernel.

Then we can't ban calls to kernels (and would be pushing some kind of symbol 
naming conflict decision into the backend) and in principle would have to 
handle this actual call.

We also don't really want these to have similar/compatible signatures where you 
can just swap out the call target. For example I want to more drastically 
change the IR used for aggregates between the two cases.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120566/new/

https://reviews.llvm.org/D120566

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


[PATCH] D120566: [OpenCL][AMDGPU]: Do not allow a call to kernel

2022-02-25 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

Is there something which stops you from taking the address of a kernel and then 
calling it?  If not, are there actually any uses of kernels in the module that 
shouldn't be rewritten as uses of the clone?

I feel like this would be a lot easier to just fix in your LLVM pass so that 
you rewrite any uses of a kernel to use a clone instead before you rewrite the 
kernel.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120566/new/

https://reviews.llvm.org/D120566

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


[PATCH] D120589: [Clang] Implement decltype(auto)(x) from P0849R2

2022-02-25 Thread Zhihao Yuan via Phabricator via cfe-commits
lichray updated this revision to Diff 411511.
lichray added a comment.

Rebase


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120589/new/

https://reviews.llvm.org/D120589

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.type.auto.deduct/p2.cpp
  clang/test/CXX/expr/expr.post/expr.type.conv/p1-2b.cpp
  clang/test/SemaCXX/deduced-return-type-cxx14.cpp

Index: clang/test/SemaCXX/deduced-return-type-cxx14.cpp
===
--- clang/test/SemaCXX/deduced-return-type-cxx14.cpp
+++ clang/test/SemaCXX/deduced-return-type-cxx14.cpp
@@ -442,6 +442,15 @@
   B() : decltype(auto)() {} // expected-error {{'decltype(auto)' not allowed here}}
 };
   }
+
+  namespace Cast {
+void foo() {
+  (void)decltype(auto)(0); // cxx14_20-error{{'decltype(auto)' not allowed here}} \
+  cxx2b-warning{{functional-style cast to 'decltype(auto)' is a Clang extension}}
+  (void)decltype(auto){0}; // cxx14_20-error{{'decltype(auto)' not allowed here}} \
+  cxx2b-warning{{functional-style cast to 'decltype(auto)' is a Clang extension}}
+}
+  }
 }
 
 namespace CurrentInstantiation {
Index: clang/test/CXX/expr/expr.post/expr.type.conv/p1-2b.cpp
===
--- clang/test/CXX/expr/expr.post/expr.type.conv/p1-2b.cpp
+++ clang/test/CXX/expr/expr.post/expr.type.conv/p1-2b.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -std=c++2b -verify %s
+// RUN: %clang_cc1 -std=c++2b -Wno-decltype-auto-cast -verify %s
 
 template 
 void foo(T);
@@ -37,3 +37,26 @@
   foo(auto({1, 2})); // expected-error {{cannot deduce actual type for 'auto' from parenthesized initializer list}}
   foo(auto{{1, 2}}); // expected-error {{cannot deduce actual type for 'auto' from nested initializer list}}
 }
+
+void diagnostics_extension() {
+  foo(decltype(auto)());   // expected-error {{initializer for functional-style cast to 'decltype(auto)' is empty}}
+  foo(decltype(auto){});   // expected-error {{initializer for functional-style cast to 'decltype(auto)' is empty}}
+  foo(decltype(auto)({})); // expected-error {{cannot deduce actual type for 'decltype(auto)' from parenthesized initializer list}}
+  foo(decltype(auto){{}}); // expected-error {{cannot deduce actual type for 'decltype(auto)' from nested initializer list}}
+
+  foo(decltype(auto)({a})); // expected-error {{cannot deduce actual type for 'decltype(auto)' from parenthesized initializer list}}
+  foo(decltype(auto){{a}}); // expected-error {{cannot deduce actual type for 'decltype(auto)' from nested initializer list}}
+
+  foo(decltype(auto)(&A::g)); // expected-error {{reference to overloaded function could not be resolved}}
+
+  foo(decltype(auto)(a, 3.14)); // expected-error {{initializer for functional-style cast to 'decltype(auto)' contains multiple expressions}}
+  foo(decltype(auto){a, 3.14}); // expected-error {{initializer for functional-style cast to 'decltype(auto)' contains multiple expressions}}
+  foo(decltype(auto)({a, 3.14}));   // expected-error {{cannot deduce actual type for 'decltype(auto)' from parenthesized initializer list}}
+  foo(decltype(auto){{a, 3.14}});   // expected-error {{cannot deduce actual type for 'decltype(auto)' from nested initializer list}}
+  foo(decltype(auto)({a}, {3.14})); // expected-error {{initializer for functional-style cast to 'decltype(auto)' contains multiple expressions}}
+  foo(decltype(auto){{a}, {3.14}}); // expected-error {{initializer for functional-style cast to 'decltype(auto)' contains multiple expressions}}
+
+  foo(decltype(auto){1, 2});   // expected-error {{initializer for functional-style cast to 'decltype(auto)' contains multiple expressions}}
+  foo(decltype(auto)({1, 2})); // expected-error {{cannot deduce actual type for 'decltype(auto)' from parenthesized initializer list}}
+  foo(decltype(auto){{1, 2}}); // expected-error {{cannot deduce actual type for 'decltype(auto)' from nested initializer list}}
+}
Index: clang/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.type.auto.deduct/p2.cpp
===
--- clang/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.type.auto.deduct/p2.cpp
+++ clang/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.type.auto.deduct/p2.cpp
@@ -1,6 +1,7 @@
-// RUN: %clang_cc1 -std=c++2b -verify %s
+// RUN: %clang_cc1 -std=c++2b -Wno-decltype-auto-cast -verify %s
 
 // p2.3 allows only T = auto in T(x).
+// As a Clang extension, we also allow T = decltype(auto) to match p2.2 (new T(x)).
 
 void test_decay() {
   int v[3];
@@ -9,6 +10,18 @@
   static_assert(__is_same(decltype(auto("lit")), char const *));
   static_assert(__is_same(decltype(auto{"lit"}), char const *));
 
+  void(decltype(auto)(v)); // expected-error {{functional-style cas

[PATCH] D113393: [c++2b] Implement P0849R8 auto(x)

2022-02-25 Thread Zhihao Yuan via Phabricator via cfe-commits
lichray updated this revision to Diff 411510.
lichray edited the summary of this revision.
lichray added a comment.

  Rebase


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113393/new/

https://reviews.llvm.org/D113393

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Parse/ParseExpr.cpp
  clang/lib/Parse/ParseExprCXX.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p5.cpp
  clang/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.type.auto.deduct/p2.cpp
  clang/test/CXX/expr/expr.post/expr.type.conv/p1-2b.cpp
  clang/test/CXX/expr/expr.unary/expr.new/p2-cxx0x.cpp
  clang/test/CXX/expr/expr.unary/expr.new/p2-cxx14.cpp
  clang/test/CXX/expr/expr.unary/expr.new/p2-cxx1z.cpp
  clang/test/Parser/cxx2b-auto-x.cpp
  clang/test/SemaCXX/cxx2b-ast-print.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -1388,6 +1388,11 @@
   https://wg21.link/P2360R0";>P2360R0
   Clang 14
 
+
+  auto(x): decay-copy in the language
+  https://wg21.link/P0849R8";>P0849R8
+  Clang 15
+
 
 
   Attributes on Lambda-Expressions
Index: clang/test/SemaCXX/cxx2b-ast-print.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/cxx2b-ast-print.cpp
@@ -0,0 +1,30 @@
+// RUN: %clang_cc1 -std=c++2b -fsyntax-only -ast-print %s | FileCheck %s
+
+void test_auto_expr(long long y, auto &&z) {
+  int x[] = {3, 4};
+
+  // CHECK{LITERAL}: (int)(x[1])
+  void(auto(x[1]));
+  // CHECK{LITERAL}: (int){x[1]}
+  void(auto{x[1]});
+
+  // CHECK{LITERAL}: (int *)(x)
+  void(auto(x));
+  // CHECK{LITERAL}: (int *){x}
+  void(auto{x});
+
+  // CHECK{LITERAL}: auto(z)
+  void(auto(z));
+  // CHECK{LITERAL}: auto({z})
+  void(auto{z}); // T({z}) is legal unless T = auto
+
+  // CHECK{LITERAL}: new int *(x)
+  void(new auto(x));
+  // CHECK{LITERAL}: new int *{x}
+  void(new auto{x});
+
+  // CHECK{LITERAL}: new long long(y)
+  void(new decltype(auto)(y));
+  // CHECK{LITERAL}: new long long{y}
+  void(new decltype(auto){y});
+}
Index: clang/test/Parser/cxx2b-auto-x.cpp
===
--- /dev/null
+++ clang/test/Parser/cxx2b-auto-x.cpp
@@ -0,0 +1,24 @@
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,cxx2b -std=c++2b -Wpre-c++2b-compat %s
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,cxx20 -std=c++20 %s
+
+void looks_like_decltype_auto() {
+  decltype(auto(42)) b = 42; // cxx20-error {{'auto' not allowed here}} \
+cxx2b-warning {{'auto' as a functional-style cast is incompatible with C++ standards before C++2b}}
+  decltype(long *) a = 42;   // expected-error {{expected '(' for function-style cast or type construction}} \
+expected-error {{expected expression}}
+  decltype(auto *) a = 42;   // expected-error {{expected '(' for function-style cast or type construction}} \
+expected-error {{expected expression}}
+  decltype(auto()) c = 42;   // cxx2b-error {{initializer for functional-style cast to 'auto' is empty}} \
+cxx20-error {{'auto' not allowed here}}
+}
+
+struct looks_like_declaration {
+  int n;
+} a;
+
+using T = looks_like_declaration *;
+void f() { T(&a)->n = 1; }
+// FIXME: They should be deemed expressions without breaking function pointer
+//parameter declarations with trailing return types.
+// void g() { auto(&a)->n = 0; }
+// void h() { auto{&a}->n = 0; }
Index: clang/test/CXX/expr/expr.unary/expr.new/p2-cxx1z.cpp
===
--- clang/test/CXX/expr/expr.unary/expr.new/p2-cxx1z.cpp
+++ clang/test/CXX/expr/expr.unary/expr.new/p2-cxx1z.cpp
@@ -1,11 +1,30 @@
 // RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++14
 // RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++17 -pedantic
 
+// [expr.new]p2 ... the invented declaration: T x init ;
+// C++2b [dcl.type.auto.deduct]p2.2
+// For a variable declared with a type that contains a placeholder type, T is the declared type of the variable.
 void f() {
+  // - If the initializer is a parenthesized expression-list, the expression-list shall be a single assignmentexpression and E is the assignment-expression.
   new auto('a');
-  new auto {2};
-  new auto {1, 2}; // expected-error{{new expression for type 'auto' contains multiple constructor arguments}}
-  new auto {}; // expected-error{{new expression for type 'auto' requires a constructor argument}}
-  new decltype(auto)({1});
-  new decltype(auto)({1, 2}); // expected-error{{new expression for type 'decltype(auto)' contains multiple constructo

[PATCH] D120589: [Clang] Implement decltype(auto)(x) from P0849R2

2022-02-25 Thread Zhihao Yuan via Phabricator via cfe-commits
lichray added a comment.

In D113393#3345275 , @aaron.ballman 
wrote:

>> Also implemented decltype(auto)(x) (https://wg21.link/p0849r2) as a Clang 
>> extension.
>
> I'd like to better understand the use cases for this. WG21 considered this as 
> part of the feature and ultimately rejected it (fairly strongly, according to 
> the EWG polls). From the meeting minutes, [...]

Not intended to argue for something when people who were against do not present 
- it's an awkward keyword for `std::forward`, arguably shorter, safer, faster...


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120589/new/

https://reviews.llvm.org/D120589

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


[PATCH] D120411: [X86] Replace __m[128|256|512]bh with __m[128|256|512]i and mark the former deprecated

2022-02-25 Thread Andy Kaylor via Phabricator via cfe-commits
andrew.w.kaylor requested changes to this revision.
andrew.w.kaylor added a comment.
This revision now requires changes to proceed.

Replacing `__m128bh` with `__m128i` does not prevent arithmetic operations on 
the type.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120411/new/

https://reviews.llvm.org/D120411

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


[PATCH] D113718: Don't append the working directory to absolute paths

2022-02-25 Thread Adrian Prantl via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG2cd9a86da54f: Don't append the working directory to 
absolute paths (authored by aprantl).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113718/new/

https://reviews.llvm.org/D113718

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/test/CodeGen/debug-prefix-map.c


Index: clang/test/CodeGen/debug-prefix-map.c
===
--- clang/test/CodeGen/debug-prefix-map.c
+++ clang/test/CodeGen/debug-prefix-map.c
@@ -5,6 +5,8 @@
 // RUN: %clang_cc1 -debug-info-kind=standalone 
-fdebug-prefix-map=%p=/UNLIKELY_PATH/empty %s -emit-llvm -o - -isysroot %p 
-debugger-tuning=lldb | FileCheck %s -check-prefix CHECK-SYSROOT
 // RUN: %clang -g -fdebug-prefix-map=%p=/UNLIKELY_PATH/empty -S -c %s 
-emit-llvm -o - | FileCheck %s
 // RUN: %clang -g -ffile-prefix-map=%p=/UNLIKELY_PATH/empty -S -c %s 
-emit-llvm -o - | FileCheck %s
+// RUN: %clang -g -fdebug-prefix-map=%p=./UNLIKELY_PATH/empty -S -c %s 
-emit-llvm -o - | FileCheck %s --check-prefix=CHECK-REL
+// RUN: %clang -g -ffile-prefix-map=%p=./UNLIKELY_PATH/empty -S -c %s 
-emit-llvm -o - | FileCheck %s --check-prefix=CHECK-REL
 
 #include "Inputs/stdio.h"
 
@@ -42,3 +44,7 @@
 // CHECK-COMPILATION-DIR: !DIFile(filename: "{{.*}}Inputs/stdio.h", directory: 
"/UNLIKELY_PATH/empty")
 // CHECK-COMPILATION-DIR-NOT: !DIFile(filename:
 // CHECK-SYSROOT: !DICompileUnit({{.*}}sysroot: "/UNLIKELY_PATH/empty"
+
+// CHECK-REL: !DIFile(filename: "./UNLIKELY_PATH/empty{{/|}}{{.*}}",
+// CHECK-REL: !DIFile(filename: 
"./UNLIKELY_PATH/empty{{/|}}{{.*}}Inputs/stdio.h",
+// CHECK-REL-SAME:directory: "")
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -444,7 +444,8 @@
   File = FileBuf;
 }
   } else {
-Dir = CurDir;
+if (!llvm::sys::path::is_absolute(FileName))
+  Dir = CurDir;
 File = RemappedFile;
   }
   llvm::DIFile *F = DBuilder.createFile(File, Dir, CSInfo, Source);


Index: clang/test/CodeGen/debug-prefix-map.c
===
--- clang/test/CodeGen/debug-prefix-map.c
+++ clang/test/CodeGen/debug-prefix-map.c
@@ -5,6 +5,8 @@
 // RUN: %clang_cc1 -debug-info-kind=standalone -fdebug-prefix-map=%p=/UNLIKELY_PATH/empty %s -emit-llvm -o - -isysroot %p -debugger-tuning=lldb | FileCheck %s -check-prefix CHECK-SYSROOT
 // RUN: %clang -g -fdebug-prefix-map=%p=/UNLIKELY_PATH/empty -S -c %s -emit-llvm -o - | FileCheck %s
 // RUN: %clang -g -ffile-prefix-map=%p=/UNLIKELY_PATH/empty -S -c %s -emit-llvm -o - | FileCheck %s
+// RUN: %clang -g -fdebug-prefix-map=%p=./UNLIKELY_PATH/empty -S -c %s -emit-llvm -o - | FileCheck %s --check-prefix=CHECK-REL
+// RUN: %clang -g -ffile-prefix-map=%p=./UNLIKELY_PATH/empty -S -c %s -emit-llvm -o - | FileCheck %s --check-prefix=CHECK-REL
 
 #include "Inputs/stdio.h"
 
@@ -42,3 +44,7 @@
 // CHECK-COMPILATION-DIR: !DIFile(filename: "{{.*}}Inputs/stdio.h", directory: "/UNLIKELY_PATH/empty")
 // CHECK-COMPILATION-DIR-NOT: !DIFile(filename:
 // CHECK-SYSROOT: !DICompileUnit({{.*}}sysroot: "/UNLIKELY_PATH/empty"
+
+// CHECK-REL: !DIFile(filename: "./UNLIKELY_PATH/empty{{/|}}{{.*}}",
+// CHECK-REL: !DIFile(filename: "./UNLIKELY_PATH/empty{{/|}}{{.*}}Inputs/stdio.h",
+// CHECK-REL-SAME:directory: "")
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -444,7 +444,8 @@
   File = FileBuf;
 }
   } else {
-Dir = CurDir;
+if (!llvm::sys::path::is_absolute(FileName))
+  Dir = CurDir;
 File = RemappedFile;
   }
   llvm::DIFile *F = DBuilder.createFile(File, Dir, CSInfo, Source);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 2cd9a86 - Don't append the working directory to absolute paths

2022-02-25 Thread Adrian Prantl via cfe-commits

Author: Adrian Prantl
Date: 2022-02-25T13:03:59-08:00
New Revision: 2cd9a86da54f8be4eb2aff3e766b125cbdeb023f

URL: 
https://github.com/llvm/llvm-project/commit/2cd9a86da54f8be4eb2aff3e766b125cbdeb023f
DIFF: 
https://github.com/llvm/llvm-project/commit/2cd9a86da54f8be4eb2aff3e766b125cbdeb023f.diff

LOG: Don't append the working directory to absolute paths

This fixes a bug that happens when using -fdebug-prefix-map to remap
an absolute path to a relative path. Since the path was absolute
before remapping, it is safe to assume that concatenating the remapped
working directory would be wrong.

Differential Revision: https://reviews.llvm.org/D113718

Added: 


Modified: 
clang/lib/CodeGen/CGDebugInfo.cpp
clang/test/CodeGen/debug-prefix-map.c

Removed: 




diff  --git a/clang/lib/CodeGen/CGDebugInfo.cpp 
b/clang/lib/CodeGen/CGDebugInfo.cpp
index 2203f0aec5c7c..28d318cdd4080 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -444,7 +444,8 @@ CGDebugInfo::createFile(StringRef FileName,
   File = FileBuf;
 }
   } else {
-Dir = CurDir;
+if (!llvm::sys::path::is_absolute(FileName))
+  Dir = CurDir;
 File = RemappedFile;
   }
   llvm::DIFile *F = DBuilder.createFile(File, Dir, CSInfo, Source);

diff  --git a/clang/test/CodeGen/debug-prefix-map.c 
b/clang/test/CodeGen/debug-prefix-map.c
index 1c5d3a6e78bb2..2241b703f9001 100644
--- a/clang/test/CodeGen/debug-prefix-map.c
+++ b/clang/test/CodeGen/debug-prefix-map.c
@@ -5,6 +5,8 @@
 // RUN: %clang_cc1 -debug-info-kind=standalone 
-fdebug-prefix-map=%p=/UNLIKELY_PATH/empty %s -emit-llvm -o - -isysroot %p 
-debugger-tuning=lldb | FileCheck %s -check-prefix CHECK-SYSROOT
 // RUN: %clang -g -fdebug-prefix-map=%p=/UNLIKELY_PATH/empty -S -c %s 
-emit-llvm -o - | FileCheck %s
 // RUN: %clang -g -ffile-prefix-map=%p=/UNLIKELY_PATH/empty -S -c %s 
-emit-llvm -o - | FileCheck %s
+// RUN: %clang -g -fdebug-prefix-map=%p=./UNLIKELY_PATH/empty -S -c %s 
-emit-llvm -o - | FileCheck %s --check-prefix=CHECK-REL
+// RUN: %clang -g -ffile-prefix-map=%p=./UNLIKELY_PATH/empty -S -c %s 
-emit-llvm -o - | FileCheck %s --check-prefix=CHECK-REL
 
 #include "Inputs/stdio.h"
 
@@ -42,3 +44,7 @@ void test_rewrite_includes(void) {
 // CHECK-COMPILATION-DIR: !DIFile(filename: "{{.*}}Inputs/stdio.h", directory: 
"/UNLIKELY_PATH/empty")
 // CHECK-COMPILATION-DIR-NOT: !DIFile(filename:
 // CHECK-SYSROOT: !DICompileUnit({{.*}}sysroot: "/UNLIKELY_PATH/empty"
+
+// CHECK-REL: !DIFile(filename: "./UNLIKELY_PATH/empty{{/|}}{{.*}}",
+// CHECK-REL: !DIFile(filename: 
"./UNLIKELY_PATH/empty{{/|}}{{.*}}Inputs/stdio.h",
+// CHECK-REL-SAME:directory: "")



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


[PATCH] D120511: [clang-format] Allow to set token types final

2022-02-25 Thread Owen Pan via Phabricator via cfe-commits
owenpan added inline comments.



Comment at: clang/lib/Format/FormatToken.h:382
+  }
+  bool typeIsFinalized() const { return TypeIsFinalized; }
 

I thought you didn't like using the same [[ 
https://reviews.llvm.org/D116316#inline-1112220 | name ]] for both a variable 
and function. :)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120511/new/

https://reviews.llvm.org/D120511

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


[PATCH] D120395: [X86] Prohibit arithmetic operations on type `__bfloat16`

2022-02-25 Thread Andy Kaylor via Phabricator via cfe-commits
andrew.w.kaylor added inline comments.



Comment at: clang/lib/Headers/avx512bf16intrin.h:37
 ///and fraction field is extended to 23 bits.
-static __inline__ float __DEFAULT_FN_ATTRS _mm_cvtsbh_ss(__bfloat16 __A) {
+static __inline__ float __DEFAULT_FN_ATTRS _mm_cvtsbh_ss(unsigned short __A) {
   return __builtin_ia32_cvtsbf162ss_32(__A);

Are we trying to make our intrinsics weakly typed? I don't like this change at 
all.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120395/new/

https://reviews.llvm.org/D120395

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


[PATCH] D120589: [Clang] Implement decltype(auto)(x) from P0849R2

2022-02-25 Thread Zhihao Yuan via Phabricator via cfe-commits
lichray created this revision.
Herald added a subscriber: JDevlieghere.
lichray requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

As a Clang extension. See also https://wg21.link/p0849r2

The implementation takes a shortcut by forming CXXFunctionalCastExpr.
Doing so costs losing 'decltype(auto)' keyword in AST. Although
we do that elsewhere, because this is in an expression, it's more
difficult to keep AST print legal *and* trustworthy.

Depends on D113393 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D120589

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.type.auto.deduct/p2.cpp
  clang/test/CXX/expr/expr.post/expr.type.conv/p1-2b.cpp
  clang/test/SemaCXX/deduced-return-type-cxx14.cpp

Index: clang/test/SemaCXX/deduced-return-type-cxx14.cpp
===
--- clang/test/SemaCXX/deduced-return-type-cxx14.cpp
+++ clang/test/SemaCXX/deduced-return-type-cxx14.cpp
@@ -442,6 +442,15 @@
   B() : decltype(auto)() {} // expected-error {{'decltype(auto)' not allowed here}}
 };
   }
+
+  namespace Cast {
+void foo() {
+  (void)decltype(auto)(0); // cxx14_20-error{{'decltype(auto)' not allowed here}} \
+  cxx2b-warning{{functional-style cast to 'decltype(auto)' is a Clang extension}}
+  (void)decltype(auto){0}; // cxx14_20-error{{'decltype(auto)' not allowed here}} \
+  cxx2b-warning{{functional-style cast to 'decltype(auto)' is a Clang extension}}
+}
+  }
 }
 
 namespace CurrentInstantiation {
Index: clang/test/CXX/expr/expr.post/expr.type.conv/p1-2b.cpp
===
--- clang/test/CXX/expr/expr.post/expr.type.conv/p1-2b.cpp
+++ clang/test/CXX/expr/expr.post/expr.type.conv/p1-2b.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -std=c++2b -verify %s
+// RUN: %clang_cc1 -std=c++2b -Wno-decltype-auto-cast -verify %s
 
 template 
 void foo(T);
@@ -37,3 +37,26 @@
   foo(auto({1, 2})); // expected-error {{cannot deduce actual type for 'auto' from parenthesized initializer list}}
   foo(auto{{1, 2}}); // expected-error {{cannot deduce actual type for 'auto' from nested initializer list}}
 }
+
+void diagnostics_extension() {
+  foo(decltype(auto)());   // expected-error {{initializer for functional-style cast to 'decltype(auto)' is empty}}
+  foo(decltype(auto){});   // expected-error {{initializer for functional-style cast to 'decltype(auto)' is empty}}
+  foo(decltype(auto)({})); // expected-error {{cannot deduce actual type for 'decltype(auto)' from parenthesized initializer list}}
+  foo(decltype(auto){{}}); // expected-error {{cannot deduce actual type for 'decltype(auto)' from nested initializer list}}
+
+  foo(decltype(auto)({a})); // expected-error {{cannot deduce actual type for 'decltype(auto)' from parenthesized initializer list}}
+  foo(decltype(auto){{a}}); // expected-error {{cannot deduce actual type for 'decltype(auto)' from nested initializer list}}
+
+  foo(decltype(auto)(&A::g)); // expected-error {{reference to overloaded function could not be resolved}}
+
+  foo(decltype(auto)(a, 3.14)); // expected-error {{initializer for functional-style cast to 'decltype(auto)' contains multiple expressions}}
+  foo(decltype(auto){a, 3.14}); // expected-error {{initializer for functional-style cast to 'decltype(auto)' contains multiple expressions}}
+  foo(decltype(auto)({a, 3.14}));   // expected-error {{cannot deduce actual type for 'decltype(auto)' from parenthesized initializer list}}
+  foo(decltype(auto){{a, 3.14}});   // expected-error {{cannot deduce actual type for 'decltype(auto)' from nested initializer list}}
+  foo(decltype(auto)({a}, {3.14})); // expected-error {{initializer for functional-style cast to 'decltype(auto)' contains multiple expressions}}
+  foo(decltype(auto){{a}, {3.14}}); // expected-error {{initializer for functional-style cast to 'decltype(auto)' contains multiple expressions}}
+
+  foo(decltype(auto){1, 2});   // expected-error {{initializer for functional-style cast to 'decltype(auto)' contains multiple expressions}}
+  foo(decltype(auto)({1, 2})); // expected-error {{cannot deduce actual type for 'decltype(auto)' from parenthesized initializer list}}
+  foo(decltype(auto){{1, 2}}); // expected-error {{cannot deduce actual type for 'decltype(auto)' from nested initializer list}}
+}
Index: clang/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.type.auto.deduct/p2.cpp
===
--- clang/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.type.auto.deduct/p2.cpp
+++ clang/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.type.auto.deduct/p2.cpp
@@ -1,6 +1,7 @@
-// RUN: %clang_cc1 -std=c++2b -verify %s
+// RUN: %clang_cc1 -std=c++2b -Wno-declt

[PATCH] D113393: [c++2b] Implement P0849R8 auto(x)

2022-02-25 Thread Zhihao Yuan via Phabricator via cfe-commits
lichray added a comment.

In D113393#3340878 , @aaron.ballman 
wrote:

> Are there changes needed for the AST printer for this new form of cast 
> notation?

Fixed one pre-existing issue, and now emit legal C++ code, except in one corner 
case. But `CXXUnresolvedConstructExpr` is a cause of more problems than that, 
so not touching it for now.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113393/new/

https://reviews.llvm.org/D113393

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


[PATCH] D120529: Disable broken hip test on Windows

2022-02-25 Thread Shangwu Yao via Phabricator via cfe-commits
shangwuyao abandoned this revision.
shangwuyao added a comment.

Closing this since the fix landed with https://reviews.llvm.org/D120563.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120529/new/

https://reviews.llvm.org/D120529

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


[PATCH] D120503: [clang-format] Handle trailing comment for InsertBraces

2022-02-25 Thread Owen Pan via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGc05da55bdf54: [clang-format] Handle trailing comment for 
InsertBraces (authored by owenpan).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120503/new/

https://reviews.llvm.org/D120503

Files:
  clang/lib/Format/Format.cpp
  clang/lib/Format/UnwrappedLineParser.cpp
  clang/unittests/Format/FormatTest.cpp


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -24481,6 +24481,13 @@
"  f();",
Style);
 
+  verifyFormat("if (a) {\n"
+   "  f(); // comment\n"
+   "}",
+   "if (a)\n"
+   "  f(); // comment",
+   Style);
+
   verifyFormat("if (a) {\n"
"  f();\n"
"}\n"
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -2336,10 +2336,9 @@
 assert(!Line->InPPDirective);
 Tok = nullptr;
 for (const auto &L : llvm::reverse(*CurrentLines)) {
-  if (!L.InPPDirective) {
-Tok = getLastNonComment(L);
-if (Tok)
-  break;
+  if (!L.InPPDirective && getLastNonComment(L)) {
+Tok = L.Tokens.back().Tok;
+break;
   }
 }
 assert(Tok);
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -1855,7 +1855,7 @@
   assert(Token->BraceCount == -1);
   Brace = '{';
 } else {
-  Brace = std::string(Token->BraceCount, '}');
+  Brace = '\n' + std::string(Token->BraceCount, '}');
 }
 Token->BraceCount = 0;
 const auto Start = Token->Tok.getEndLoc();


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -24481,6 +24481,13 @@
"  f();",
Style);
 
+  verifyFormat("if (a) {\n"
+   "  f(); // comment\n"
+   "}",
+   "if (a)\n"
+   "  f(); // comment",
+   Style);
+
   verifyFormat("if (a) {\n"
"  f();\n"
"}\n"
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -2336,10 +2336,9 @@
 assert(!Line->InPPDirective);
 Tok = nullptr;
 for (const auto &L : llvm::reverse(*CurrentLines)) {
-  if (!L.InPPDirective) {
-Tok = getLastNonComment(L);
-if (Tok)
-  break;
+  if (!L.InPPDirective && getLastNonComment(L)) {
+Tok = L.Tokens.back().Tok;
+break;
   }
 }
 assert(Tok);
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -1855,7 +1855,7 @@
   assert(Token->BraceCount == -1);
   Brace = '{';
 } else {
-  Brace = std::string(Token->BraceCount, '}');
+  Brace = '\n' + std::string(Token->BraceCount, '}');
 }
 Token->BraceCount = 0;
 const auto Start = Token->Tok.getEndLoc();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] c05da55 - [clang-format] Handle trailing comment for InsertBraces

2022-02-25 Thread via cfe-commits

Author: owenca
Date: 2022-02-25T12:29:47-08:00
New Revision: c05da55bdf54e530a888acf8d2282964e25d2507

URL: 
https://github.com/llvm/llvm-project/commit/c05da55bdf54e530a888acf8d2282964e25d2507
DIFF: 
https://github.com/llvm/llvm-project/commit/c05da55bdf54e530a888acf8d2282964e25d2507.diff

LOG: [clang-format] Handle trailing comment for InsertBraces

Differential Revision: https://reviews.llvm.org/D120503

Added: 


Modified: 
clang/lib/Format/Format.cpp
clang/lib/Format/UnwrappedLineParser.cpp
clang/unittests/Format/FormatTest.cpp

Removed: 




diff  --git a/clang/lib/Format/Format.cpp b/clang/lib/Format/Format.cpp
index ec6574b33a8cf..c12096dc93ba8 100644
--- a/clang/lib/Format/Format.cpp
+++ b/clang/lib/Format/Format.cpp
@@ -1855,7 +1855,7 @@ class BracesInserter : public TokenAnalyzer {
   assert(Token->BraceCount == -1);
   Brace = '{';
 } else {
-  Brace = std::string(Token->BraceCount, '}');
+  Brace = '\n' + std::string(Token->BraceCount, '}');
 }
 Token->BraceCount = 0;
 const auto Start = Token->Tok.getEndLoc();

diff  --git a/clang/lib/Format/UnwrappedLineParser.cpp 
b/clang/lib/Format/UnwrappedLineParser.cpp
index e2cbcea14d7a9..502a84cbcc8b4 100644
--- a/clang/lib/Format/UnwrappedLineParser.cpp
+++ b/clang/lib/Format/UnwrappedLineParser.cpp
@@ -2336,10 +2336,9 @@ void UnwrappedLineParser::parseUnbracedBody(bool 
CheckEOF) {
 assert(!Line->InPPDirective);
 Tok = nullptr;
 for (const auto &L : llvm::reverse(*CurrentLines)) {
-  if (!L.InPPDirective) {
-Tok = getLastNonComment(L);
-if (Tok)
-  break;
+  if (!L.InPPDirective && getLastNonComment(L)) {
+Tok = L.Tokens.back().Tok;
+break;
   }
 }
 assert(Tok);

diff  --git a/clang/unittests/Format/FormatTest.cpp 
b/clang/unittests/Format/FormatTest.cpp
index 624f3a78755f0..8008cce232d36 100644
--- a/clang/unittests/Format/FormatTest.cpp
+++ b/clang/unittests/Format/FormatTest.cpp
@@ -24481,6 +24481,13 @@ TEST_F(FormatTest, InsertBraces) {
"  f();",
Style);
 
+  verifyFormat("if (a) {\n"
+   "  f(); // comment\n"
+   "}",
+   "if (a)\n"
+   "  f(); // comment",
+   Style);
+
   verifyFormat("if (a) {\n"
"  f();\n"
"}\n"



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


[PATCH] D120563: [HIP] Fix test hip-link-bundled-archive.hip

2022-02-25 Thread Yaxun Liu via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGdf0c98364322: [HIP] Fix test hip-link-bundled-archive.hip 
(authored by yaxunl).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120563/new/

https://reviews.llvm.org/D120563

Files:
  clang/test/Driver/hip-link-bundle-archive.hip


Index: clang/test/Driver/hip-link-bundle-archive.hip
===
--- clang/test/Driver/hip-link-bundle-archive.hip
+++ clang/test/Driver/hip-link-bundle-archive.hip
@@ -9,6 +9,6 @@
 // RUN:   2>&1 | FileCheck -check-prefix=CHECK %s
 
 // CHECK: "{{.*}}clang-offload-bundler" "-unbundle" "-type=a" 
"-inputs={{.*}}libhipBundled.a" "-targets=hip-amdgcn-amd-amdhsa-gfx1030" 
"-outputs=[[A1030:.*\.a]]" "-allow-missing-bundles"
-// CHECK: "{{.*}}lld" {{.*}}"-plugin-opt=mcpu=gfx1030" {{.*}} "[[A1030]]"
+// CHECK: "{{.*}}lld{{.*}}" {{.*}}"-plugin-opt=mcpu=gfx1030" {{.*}} "[[A1030]]"
 // CHECK: "{{.*}}clang-offload-bundler" "-unbundle" "-type=a" 
"-inputs={{.*}}libhipBundled.a" "-targets=hip-amdgcn-amd-amdhsa-gfx906" 
"-outputs=[[A906:.*\.a]]" "-allow-missing-bundles"
-// CHECK: "{{.*}}lld" {{.*}}"-plugin-opt=mcpu=gfx906" {{.*}} "[[A906]]"
+// CHECK: "{{.*}}lld{{.*}}" {{.*}}"-plugin-opt=mcpu=gfx906" {{.*}} "[[A906]]"


Index: clang/test/Driver/hip-link-bundle-archive.hip
===
--- clang/test/Driver/hip-link-bundle-archive.hip
+++ clang/test/Driver/hip-link-bundle-archive.hip
@@ -9,6 +9,6 @@
 // RUN:   2>&1 | FileCheck -check-prefix=CHECK %s
 
 // CHECK: "{{.*}}clang-offload-bundler" "-unbundle" "-type=a" "-inputs={{.*}}libhipBundled.a" "-targets=hip-amdgcn-amd-amdhsa-gfx1030" "-outputs=[[A1030:.*\.a]]" "-allow-missing-bundles"
-// CHECK: "{{.*}}lld" {{.*}}"-plugin-opt=mcpu=gfx1030" {{.*}} "[[A1030]]"
+// CHECK: "{{.*}}lld{{.*}}" {{.*}}"-plugin-opt=mcpu=gfx1030" {{.*}} "[[A1030]]"
 // CHECK: "{{.*}}clang-offload-bundler" "-unbundle" "-type=a" "-inputs={{.*}}libhipBundled.a" "-targets=hip-amdgcn-amd-amdhsa-gfx906" "-outputs=[[A906:.*\.a]]" "-allow-missing-bundles"
-// CHECK: "{{.*}}lld" {{.*}}"-plugin-opt=mcpu=gfx906" {{.*}} "[[A906]]"
+// CHECK: "{{.*}}lld{{.*}}" {{.*}}"-plugin-opt=mcpu=gfx906" {{.*}} "[[A906]]"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] df0c983 - [HIP] Fix test hip-link-bundled-archive.hip

2022-02-25 Thread Yaxun Liu via cfe-commits

Author: Yaxun (Sam) Liu
Date: 2022-02-25T15:27:57-05:00
New Revision: df0c983643222b8b2085fb4d8a833cb64274caf1

URL: 
https://github.com/llvm/llvm-project/commit/df0c983643222b8b2085fb4d8a833cb64274caf1
DIFF: 
https://github.com/llvm/llvm-project/commit/df0c983643222b8b2085fb4d8a833cb64274caf1.diff

LOG: [HIP] Fix test hip-link-bundled-archive.hip

match pattern should match lld.exe on windows

Reviewed by: Shangwu Yao

Differential Revision: https://reviews.llvm.org/D120563

Added: 


Modified: 
clang/test/Driver/hip-link-bundle-archive.hip

Removed: 




diff  --git a/clang/test/Driver/hip-link-bundle-archive.hip 
b/clang/test/Driver/hip-link-bundle-archive.hip
index 4b97844faf46c..d6bc162ac4c13 100644
--- a/clang/test/Driver/hip-link-bundle-archive.hip
+++ b/clang/test/Driver/hip-link-bundle-archive.hip
@@ -9,6 +9,6 @@
 // RUN:   2>&1 | FileCheck -check-prefix=CHECK %s
 
 // CHECK: "{{.*}}clang-offload-bundler" "-unbundle" "-type=a" 
"-inputs={{.*}}libhipBundled.a" "-targets=hip-amdgcn-amd-amdhsa-gfx1030" 
"-outputs=[[A1030:.*\.a]]" "-allow-missing-bundles"
-// CHECK: "{{.*}}lld" {{.*}}"-plugin-opt=mcpu=gfx1030" {{.*}} "[[A1030]]"
+// CHECK: "{{.*}}lld{{.*}}" {{.*}}"-plugin-opt=mcpu=gfx1030" {{.*}} "[[A1030]]"
 // CHECK: "{{.*}}clang-offload-bundler" "-unbundle" "-type=a" 
"-inputs={{.*}}libhipBundled.a" "-targets=hip-amdgcn-amd-amdhsa-gfx906" 
"-outputs=[[A906:.*\.a]]" "-allow-missing-bundles"
-// CHECK: "{{.*}}lld" {{.*}}"-plugin-opt=mcpu=gfx906" {{.*}} "[[A906]]"
+// CHECK: "{{.*}}lld{{.*}}" {{.*}}"-plugin-opt=mcpu=gfx906" {{.*}} "[[A906]]"



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


[PATCH] D119816: [SanitizerBounds] Add support for NoSanitizeBounds function

2022-02-25 Thread Tong Zhang via Phabricator via cfe-commits
ztong0001 added inline comments.



Comment at: clang/lib/CodeGen/CodeGenFunction.cpp:757
 SanOpts.set(SanitizerKind::HWAddress, false);
+  if (mask & SanitizerKind::LocalBounds)
+Fn->addFnAttr(llvm::Attribute::NoSanitizeBounds);

melver wrote:
> ztong0001 wrote:
> > ztong0001 wrote:
> > > melver wrote:
> > > > These 2 checks can be reduced to 1 due to SanitizerKind::Bounds 
> > > > including both. However, as noted, this only affects local-bounds, so 
> > > > I'm not sure if we want to include both -- perhaps for completeness it 
> > > > makes sense, but in the array-bounds only case this attribute will be a 
> > > > nop (AFAIK).
> > > > 
> > > > Also, I think we don't want to attach the attribute if bounds checking 
> > > > isn't enabled -- at least it seems unnecessary to do so.
> > > > 
> > > > See the following suggested change:
> > > > 
> > > > ```
> > > > diff --git a/clang/lib/CodeGen/CodeGenFunction.cpp 
> > > > b/clang/lib/CodeGen/CodeGenFunction.cpp
> > > > index 842ce0245d45..c1f3a3014a19 100644
> > > > --- a/clang/lib/CodeGen/CodeGenFunction.cpp
> > > > +++ b/clang/lib/CodeGen/CodeGenFunction.cpp
> > > > @@ -740,6 +740,7 @@ void CodeGenFunction::StartFunction(GlobalDecl GD, 
> > > > QualType RetTy,
> > > >} while (false);
> > > >  
> > > >if (D) {
> > > > +const bool SanitizeBounds = 
> > > > SanOpts.hasOneOf(SanitizerKind::Bounds);
> > > >  bool NoSanitizeCoverage = false;
> > > >  
> > > >  for (auto Attr : D->specific_attrs()) {
> > > > @@ -754,16 +755,15 @@ void CodeGenFunction::StartFunction(GlobalDecl 
> > > > GD, QualType RetTy,
> > > >  SanOpts.set(SanitizerKind::KernelHWAddress, false);
> > > >if (mask & SanitizerKind::KernelHWAddress)
> > > >  SanOpts.set(SanitizerKind::HWAddress, false);
> > > > -  if (mask & SanitizerKind::LocalBounds)
> > > > -Fn->addFnAttr(llvm::Attribute::NoSanitizeBounds);
> > > > -  if (mask & SanitizerKind::ArrayBounds)
> > > > -Fn->addFnAttr(llvm::Attribute::NoSanitizeBounds);
> > > >  
> > > >// SanitizeCoverage is not handled by SanOpts.
> > > >if (Attr->hasCoverage())
> > > >  NoSanitizeCoverage = true;
> > > >  }
> > > >  
> > > > +if (SanitizeBounds && !SanOpts.hasOneOf(SanitizerKind::Bounds))
> > > > +  Fn->addFnAttr(llvm::Attribute::NoSanitizeBounds);
> > > > +
> > > >  if (NoSanitizeCoverage && 
> > > > CGM.getCodeGenOpts().hasSanitizeCoverage())
> > > >Fn->addFnAttr(llvm::Attribute::NoSanitizeCoverage);
> > > >}
> > > > 
> > > > ```
> > > Agreed. I will revise patch and commit description.
> > BTW: Just to double check we are on the same page
> > 
> > when no_sanitize(bounds) is provided, fsanitize=array-bounds is also 
> > disabled -- right ? I can confirm this attribute is also affecting 
> > array-bounds as this is handled in clang side and we are setting 
> > llvm::Attribute::NoSanitizeBounds so that clang's array-bounds can also see 
> > this.
> > 
> > I will also add another test for -fsanitize=array-bounds
> Well, no_sanitize("bounds") already worked for array-bounds before this 
> patch. But adding more tests never hurt.
Got it. Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119816/new/

https://reviews.llvm.org/D119816

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


[PATCH] D119061: [Clang] noinline call site attribute

2022-02-25 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 updated this revision to Diff 411495.
xbolva00 added a comment.

Small doc update.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119061/new/

https://reviews.llvm.org/D119061

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/Sema/SemaStmtAttr.cpp
  clang/test/CodeGen/attr-noinline.cpp
  clang/test/Parser/stmt-attributes.c
  clang/test/Sema/attr-noinline.c
  clang/test/Sema/attr-noinline.cpp

Index: clang/test/Sema/attr-noinline.cpp
===
--- /dev/null
+++ clang/test/Sema/attr-noinline.cpp
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 -verify -fsyntax-only %s
+
+int bar();
+
+[[gnu::always_inline]] void always_inline_fn(void) { }
+[[gnu::flatten]] void flatten_fn(void) { }
+
+[[gnu::noinline]] void noinline_fn(void) { }
+
+void foo() {
+  [[clang::noinline]] bar();
+  [[clang::noinline(0)]] bar(); // expected-error {{'noinline' attribute takes no arguments}}
+  int x;
+  [[clang::noinline]] x = 0; // expected-warning {{'noinline' attribute is ignored because there exists no call expression inside the statement}}
+  [[clang::noinline]] { asm("nop"); } // expected-warning {{'noinline' attribute is ignored because there exists no call expression inside the statement}}
+  [[clang::noinline]] label: x = 1; // expected-error {{'noinline' attribute only applies to functions and statements}}
+
+
+  [[clang::noinline]] always_inline_fn(); // expected-warning {{statement attribute 'noinline' has higher precedence than function attribute 'always_inline'}}
+  [[clang::noinline]] flatten_fn(); // expected-warning {{statement attribute 'noinline' has higher precedence than function attribute 'flatten'}}
+  [[clang::noinline]] noinline_fn();
+
+  [[gnu::noinline]] bar(); // expected-warning {{attribute is ignored on this statement as it only applies to functions; use '[[clang::noinline]]' on statements}}
+  __attribute__((noinline)) bar(); // expected-warning {{attribute is ignored on this statement as it only applies to functions; use '[[clang::noinline]]' on statements}}
+}
+
+[[clang::noinline]] static int i = bar(); // expected-error {{'noinline' attribute only applies to functions and statements}}
Index: clang/test/Sema/attr-noinline.c
===
--- clang/test/Sema/attr-noinline.c
+++ clang/test/Sema/attr-noinline.c
@@ -1,6 +1,6 @@
 // RUN: %clang_cc1 %s -verify -fsyntax-only
 
-int a __attribute__((noinline)); // expected-warning {{'noinline' attribute only applies to functions}}
+int a __attribute__((noinline)); // expected-error {{'noinline' attribute only applies to functions and statements}}
 
 void t1(void) __attribute__((noinline));
 
Index: clang/test/Parser/stmt-attributes.c
===
--- clang/test/Parser/stmt-attributes.c
+++ clang/test/Parser/stmt-attributes.c
@@ -45,7 +45,7 @@
   }
 
   __attribute__((fastcall)) goto there; // expected-error {{'fastcall' attribute cannot be applied to a statement}}
-  __attribute__((noinline)) there : // expected-warning {{'noinline' attribute only applies to functions}}
+  __attribute__((noinline)) there : // expected-warning {{'noinline' attribute only applies to functions and statements}}
 
 __attribute__((weakref)) return; // expected-error {{'weakref' attribute only applies to variables and functions}}
 
Index: clang/test/CodeGen/attr-noinline.cpp
===
--- /dev/null
+++ clang/test/CodeGen/attr-noinline.cpp
@@ -0,0 +1,55 @@
+// RUN: %clang_cc1 -S -emit-llvm %s -triple x86_64-unknown-linux-gnu -o - | FileCheck %s
+
+bool bar();
+void f(bool, bool);
+void g(bool);
+
+static int baz(int x) {
+return x * 10;
+}
+
+[[clang::noinline]] bool noi() { }
+
+void foo(int i) {
+  [[clang::noinline]] bar();
+// CHECK: call noundef zeroext i1 @_Z3barv() #[[NOINLINEATTR:[0-9]+]]
+  [[clang::noinline]] i = baz(i);
+// CHECK: call noundef i32 @_ZL3bazi({{.*}}) #[[NOINLINEATTR]]
+  [[clang::noinline]] (i = 4, bar());
+// CHECK: call noundef zeroext i1 @_Z3barv() #[[NOINLINEATTR]]
+  [[clang::noinline]] (void)(bar());
+// CHECK: call noundef zeroext i1 @_Z3barv() #[[NOINLINEATTR]]
+  [[clang::noinline]] f(bar(), bar());
+// CHECK: call noundef zeroext i1 @_Z3barv() #[[NOINLINEATTR]]
+// CHECK: call noundef zeroext i1 @_Z3barv() #[[NOINLINEATTR]]
+// CHECK: call void @_Z1fbb({{.*}}) #[[NOINLINEATTR]]
+  [[clang::noinline]] [] { bar(); bar(); }(); // noinline only applies to the anonymous function call
+// CHECK: call void @"_ZZ3fooiENK3$_0clEv"(%class.anon* {{[^,]*}} %ref.tmp) #[[NOINLINEATTR]]
+  [[clang::noinline]] for (bar(); bar(); bar()) {}
+// CHECK: call noundef zeroext i1 @_Z3barv() #[[NOINLI

[PATCH] D113393: [c++2b] Implement P0849R8 auto(x)

2022-02-25 Thread Zhihao Yuan via Phabricator via cfe-commits
lichray updated this revision to Diff 411493.
lichray added a comment.

- Remove decltype(auto) from the patch
- Parenthesize deduced casts in AST print


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113393/new/

https://reviews.llvm.org/D113393

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Parse/ParseExpr.cpp
  clang/lib/Parse/ParseExprCXX.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p5.cpp
  clang/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.type.auto.deduct/p2.cpp
  clang/test/CXX/expr/expr.post/expr.type.conv/p1-2b.cpp
  clang/test/CXX/expr/expr.unary/expr.new/p2-cxx0x.cpp
  clang/test/CXX/expr/expr.unary/expr.new/p2-cxx14.cpp
  clang/test/CXX/expr/expr.unary/expr.new/p2-cxx1z.cpp
  clang/test/Parser/cxx2b-auto-x.cpp
  clang/test/SemaCXX/cxx2b-ast-print.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -1388,6 +1388,11 @@
   https://wg21.link/P2360R0";>P2360R0
   Clang 14
 
+
+  auto(x): decay-copy in the language
+  https://wg21.link/P0849R8";>P0849R8
+  Clang 15
+
 
 
   Attributes on Lambda-Expressions
Index: clang/test/SemaCXX/cxx2b-ast-print.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/cxx2b-ast-print.cpp
@@ -0,0 +1,30 @@
+// RUN: %clang_cc1 -std=c++2b -fsyntax-only -ast-print %s | FileCheck %s
+
+void test_auto_expr(long long y, auto &&z) {
+  int x[] = {3, 4};
+
+  // CHECK{LITERAL}: (int)(x[1])
+  void(auto(x[1]));
+  // CHECK{LITERAL}: (int){x[1]}
+  void(auto{x[1]});
+
+  // CHECK{LITERAL}: (int *)(x)
+  void(auto(x));
+  // CHECK{LITERAL}: (int *){x}
+  void(auto{x});
+
+  // CHECK{LITERAL}: auto(z)
+  void(auto(z));
+  // CHECK{LITERAL}: auto({z})
+  void(auto{z}); // T({z}) is legal unless T = auto
+
+  // CHECK{LITERAL}: new int *(x)
+  void(new auto(x));
+  // CHECK{LITERAL}: new int *{x}
+  void(new auto{x});
+
+  // CHECK{LITERAL}: new long long(y)
+  void(new decltype(auto)(y));
+  // CHECK{LITERAL}: new long long{y}
+  void(new decltype(auto){y});
+}
Index: clang/test/Parser/cxx2b-auto-x.cpp
===
--- /dev/null
+++ clang/test/Parser/cxx2b-auto-x.cpp
@@ -0,0 +1,24 @@
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,cxx2b -std=c++2b -Wpre-c++2b-compat %s
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,cxx20 -std=c++20 %s
+
+void looks_like_decltype_auto() {
+  decltype(auto(42)) b = 42; // cxx20-error {{'auto' not allowed here}} \
+cxx2b-warning {{'auto' as a functional-style cast is incompatible with C++ standards before C++2b}}
+  decltype(long *) a = 42;   // expected-error {{expected '(' for function-style cast or type construction}} \
+expected-error {{expected expression}}
+  decltype(auto *) a = 42;   // expected-error {{expected '(' for function-style cast or type construction}} \
+expected-error {{expected expression}}
+  decltype(auto()) c = 42;   // cxx2b-error {{initializer for functional-style cast to 'auto' is empty}} \
+cxx20-error {{'auto' not allowed here}}
+}
+
+struct looks_like_declaration {
+  int n;
+} a;
+
+using T = looks_like_declaration *;
+void f() { T(&a)->n = 1; }
+// FIXME: They should be deemed expressions without breaking function pointer
+//parameter declarations with trailing return types.
+// void g() { auto(&a)->n = 0; }
+// void h() { auto{&a}->n = 0; }
Index: clang/test/CXX/expr/expr.unary/expr.new/p2-cxx1z.cpp
===
--- clang/test/CXX/expr/expr.unary/expr.new/p2-cxx1z.cpp
+++ clang/test/CXX/expr/expr.unary/expr.new/p2-cxx1z.cpp
@@ -1,11 +1,30 @@
 // RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++14
 // RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++17 -pedantic
 
+// [expr.new]p2 ... the invented declaration: T x init ;
+// C++2b [dcl.type.auto.deduct]p2.2
+// For a variable declared with a type that contains a placeholder type, T is the declared type of the variable.
 void f() {
+  // - If the initializer is a parenthesized expression-list, the expression-list shall be a single assignmentexpression and E is the assignment-expression.
   new auto('a');
-  new auto {2};
-  new auto {1, 2}; // expected-error{{new expression for type 'auto' contains multiple constructor arguments}}
-  new auto {}; // expected-error{{new expression for type 'auto' requires a constructor argument}}
-  new decltype(auto)({1});
-  new decltype(auto)({1, 2}); // expected-error{{new expression for type 'decltype(auto)' c

[PATCH] D119816: [SanitizerBounds] Add support for NoSanitizeBounds function

2022-02-25 Thread Marco Elver via Phabricator via cfe-commits
melver added inline comments.



Comment at: clang/lib/CodeGen/CodeGenFunction.cpp:757
 SanOpts.set(SanitizerKind::HWAddress, false);
+  if (mask & SanitizerKind::LocalBounds)
+Fn->addFnAttr(llvm::Attribute::NoSanitizeBounds);

ztong0001 wrote:
> ztong0001 wrote:
> > melver wrote:
> > > These 2 checks can be reduced to 1 due to SanitizerKind::Bounds including 
> > > both. However, as noted, this only affects local-bounds, so I'm not sure 
> > > if we want to include both -- perhaps for completeness it makes sense, 
> > > but in the array-bounds only case this attribute will be a nop (AFAIK).
> > > 
> > > Also, I think we don't want to attach the attribute if bounds checking 
> > > isn't enabled -- at least it seems unnecessary to do so.
> > > 
> > > See the following suggested change:
> > > 
> > > ```
> > > diff --git a/clang/lib/CodeGen/CodeGenFunction.cpp 
> > > b/clang/lib/CodeGen/CodeGenFunction.cpp
> > > index 842ce0245d45..c1f3a3014a19 100644
> > > --- a/clang/lib/CodeGen/CodeGenFunction.cpp
> > > +++ b/clang/lib/CodeGen/CodeGenFunction.cpp
> > > @@ -740,6 +740,7 @@ void CodeGenFunction::StartFunction(GlobalDecl GD, 
> > > QualType RetTy,
> > >} while (false);
> > >  
> > >if (D) {
> > > +const bool SanitizeBounds = SanOpts.hasOneOf(SanitizerKind::Bounds);
> > >  bool NoSanitizeCoverage = false;
> > >  
> > >  for (auto Attr : D->specific_attrs()) {
> > > @@ -754,16 +755,15 @@ void CodeGenFunction::StartFunction(GlobalDecl GD, 
> > > QualType RetTy,
> > >  SanOpts.set(SanitizerKind::KernelHWAddress, false);
> > >if (mask & SanitizerKind::KernelHWAddress)
> > >  SanOpts.set(SanitizerKind::HWAddress, false);
> > > -  if (mask & SanitizerKind::LocalBounds)
> > > -Fn->addFnAttr(llvm::Attribute::NoSanitizeBounds);
> > > -  if (mask & SanitizerKind::ArrayBounds)
> > > -Fn->addFnAttr(llvm::Attribute::NoSanitizeBounds);
> > >  
> > >// SanitizeCoverage is not handled by SanOpts.
> > >if (Attr->hasCoverage())
> > >  NoSanitizeCoverage = true;
> > >  }
> > >  
> > > +if (SanitizeBounds && !SanOpts.hasOneOf(SanitizerKind::Bounds))
> > > +  Fn->addFnAttr(llvm::Attribute::NoSanitizeBounds);
> > > +
> > >  if (NoSanitizeCoverage && CGM.getCodeGenOpts().hasSanitizeCoverage())
> > >Fn->addFnAttr(llvm::Attribute::NoSanitizeCoverage);
> > >}
> > > 
> > > ```
> > Agreed. I will revise patch and commit description.
> BTW: Just to double check we are on the same page
> 
> when no_sanitize(bounds) is provided, fsanitize=array-bounds is also disabled 
> -- right ? I can confirm this attribute is also affecting array-bounds as 
> this is handled in clang side and we are setting 
> llvm::Attribute::NoSanitizeBounds so that clang's array-bounds can also see 
> this.
> 
> I will also add another test for -fsanitize=array-bounds
Well, no_sanitize("bounds") already worked for array-bounds before this patch. 
But adding more tests never hurt.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119816/new/

https://reviews.llvm.org/D119816

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


[PATCH] D119300: Use-after-dtor detection for trivial base classes.

2022-02-25 Thread Kevin Athey via Phabricator via cfe-commits
kda added inline comments.



Comment at: clang/lib/CodeGen/CGClass.cpp:1872
 
   // Ignore trivial destructors.
+  if (BaseClassDecl->hasTrivialDestructor()) {

Maybe not "Ignore"?



Comment at: clang/lib/CodeGen/CGClass.cpp:1907
 
 // Ignore trivial destructors.
+if (BaseClassDecl->hasTrivialDestructor()) {

not "ignore".



Comment at: compiler-rt/test/msan/dtor-base-access.cpp:11
 class Base {
  public:
+   int b;

nit: inconsistent indent with line 18.



Comment at: compiler-rt/test/msan/dtor-base-access.cpp:36
 
+Derived *g;
+

maybe in good faith '= nullptr'?



Comment at: compiler-rt/test/msan/dtor-base-access.cpp:63
+
+  g->~Derived();
+  // not ok to access everything

Is calling destructor preferred to 'delete g'?  Seems like 'delete' would be 
obvious inversion of 'new' on line 56.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119300/new/

https://reviews.llvm.org/D119300

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


[PATCH] D119061: [Clang] noinline call site attribute

2022-02-25 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 added a comment.

I think I will update release notes later, after always_inline variant of this 
patch. So looks like we are almost done here? :)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119061/new/

https://reviews.llvm.org/D119061

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


[PATCH] D119061: [Clang] noinline call site attribute

2022-02-25 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 updated this revision to Diff 411489.
xbolva00 added a comment.

Addressed review comments. Feel free to suggest better wording :)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119061/new/

https://reviews.llvm.org/D119061

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/Sema/SemaStmtAttr.cpp
  clang/test/CodeGen/attr-noinline.cpp
  clang/test/Parser/stmt-attributes.c
  clang/test/Sema/attr-noinline.c
  clang/test/Sema/attr-noinline.cpp

Index: clang/test/Sema/attr-noinline.cpp
===
--- /dev/null
+++ clang/test/Sema/attr-noinline.cpp
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 -verify -fsyntax-only %s
+
+int bar();
+
+[[gnu::always_inline]] void always_inline_fn(void) { }
+[[gnu::flatten]] void flatten_fn(void) { }
+
+[[gnu::noinline]] void noinline_fn(void) { }
+
+void foo() {
+  [[clang::noinline]] bar();
+  [[clang::noinline(0)]] bar(); // expected-error {{'noinline' attribute takes no arguments}}
+  int x;
+  [[clang::noinline]] x = 0; // expected-warning {{'noinline' attribute is ignored because there exists no call expression inside the statement}}
+  [[clang::noinline]] { asm("nop"); } // expected-warning {{'noinline' attribute is ignored because there exists no call expression inside the statement}}
+  [[clang::noinline]] label: x = 1; // expected-error {{'noinline' attribute only applies to functions and statements}}
+
+
+  [[clang::noinline]] always_inline_fn(); // expected-warning {{statement attribute 'noinline' has higher precedence than function attribute 'always_inline'}}
+  [[clang::noinline]] flatten_fn(); // expected-warning {{statement attribute 'noinline' has higher precedence than function attribute 'flatten'}}
+  [[clang::noinline]] noinline_fn();
+
+  [[gnu::noinline]] bar(); // expected-warning {{attribute is ignored on this statement as it only applies to functions; use '[[clang::noinline]]' on statements}}
+  __attribute__((noinline)) bar(); // expected-warning {{attribute is ignored on this statement as it only applies to functions; use '[[clang::noinline]]' on statements}}
+}
+
+[[clang::noinline]] static int i = bar(); // expected-error {{'noinline' attribute only applies to functions and statements}}
Index: clang/test/Sema/attr-noinline.c
===
--- clang/test/Sema/attr-noinline.c
+++ clang/test/Sema/attr-noinline.c
@@ -1,6 +1,6 @@
 // RUN: %clang_cc1 %s -verify -fsyntax-only
 
-int a __attribute__((noinline)); // expected-warning {{'noinline' attribute only applies to functions}}
+int a __attribute__((noinline)); // expected-error {{'noinline' attribute only applies to functions and statements}}
 
 void t1(void) __attribute__((noinline));
 
Index: clang/test/Parser/stmt-attributes.c
===
--- clang/test/Parser/stmt-attributes.c
+++ clang/test/Parser/stmt-attributes.c
@@ -45,7 +45,7 @@
   }
 
   __attribute__((fastcall)) goto there; // expected-error {{'fastcall' attribute cannot be applied to a statement}}
-  __attribute__((noinline)) there : // expected-warning {{'noinline' attribute only applies to functions}}
+  __attribute__((noinline)) there : // expected-warning {{'noinline' attribute only applies to functions and statements}}
 
 __attribute__((weakref)) return; // expected-error {{'weakref' attribute only applies to variables and functions}}
 
Index: clang/test/CodeGen/attr-noinline.cpp
===
--- /dev/null
+++ clang/test/CodeGen/attr-noinline.cpp
@@ -0,0 +1,55 @@
+// RUN: %clang_cc1 -S -emit-llvm %s -triple x86_64-unknown-linux-gnu -o - | FileCheck %s
+
+bool bar();
+void f(bool, bool);
+void g(bool);
+
+static int baz(int x) {
+return x * 10;
+}
+
+[[clang::noinline]] bool noi() { }
+
+void foo(int i) {
+  [[clang::noinline]] bar();
+// CHECK: call noundef zeroext i1 @_Z3barv() #[[NOINLINEATTR:[0-9]+]]
+  [[clang::noinline]] i = baz(i);
+// CHECK: call noundef i32 @_ZL3bazi({{.*}}) #[[NOINLINEATTR]]
+  [[clang::noinline]] (i = 4, bar());
+// CHECK: call noundef zeroext i1 @_Z3barv() #[[NOINLINEATTR]]
+  [[clang::noinline]] (void)(bar());
+// CHECK: call noundef zeroext i1 @_Z3barv() #[[NOINLINEATTR]]
+  [[clang::noinline]] f(bar(), bar());
+// CHECK: call noundef zeroext i1 @_Z3barv() #[[NOINLINEATTR]]
+// CHECK: call noundef zeroext i1 @_Z3barv() #[[NOINLINEATTR]]
+// CHECK: call void @_Z1fbb({{.*}}) #[[NOINLINEATTR]]
+  [[clang::noinline]] [] { bar(); bar(); }(); // noinline only applies to the anonymous function call
+// CHECK: call void @"_ZZ3fooiENK3$_0clEv"(%class.anon* {{[^,]*}} %ref.tmp) #[[NOINLINEATTR]]
+  [[clang::noinline]] for (bar(); bar(); bar()) {}
+// CHE

[PATCH] D116593: Fix `performance-unnecessary-value-param` for template specialization

2022-02-25 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

It looks like precommit CI is failing:

Failed Tests (1):

  Clang Tools :: clang-tidy/checkers/performance-unnecessary-value-param.cpp


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116593/new/

https://reviews.llvm.org/D116593

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


[PATCH] D120301: clang-tools-extra: Make test dependency on LLVMHello optional

2022-02-25 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

In D120301#3346236 , @vtjnash wrote:

> Seems extra complexity, and less desirable to lose test coverage, when it 
> seems the option may already be unreliable and soon to be deprecated by 
> https://reviews.llvm.org/D119383. @MaskRay is that accurate?

Seems that D119383  that is not favored by 
Gentoo and RedHat.
I do not know whether we will be able to remove the standalone build mode.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120301/new/

https://reviews.llvm.org/D120301

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


[PATCH] D119600: Stricter use-after-dtor detection for trivial members.

2022-02-25 Thread Kevin Athey via Phabricator via cfe-commits
kda accepted this revision.
kda added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119600/new/

https://reviews.llvm.org/D119600

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


[libunwind] 84647ff - [libunwind][test] remember_state_leak.pass.sh.s: link with -no-pie

2022-02-25 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2022-02-25T19:55:56Z
New Revision: 84647ff38ca76136e3c4be80cf6785a78188d33a

URL: 
https://github.com/llvm/llvm-project/commit/84647ff38ca76136e3c4be80cf6785a78188d33a
DIFF: 
https://github.com/llvm/llvm-project/commit/84647ff38ca76136e3c4be80cf6785a78188d33a.diff

LOG: [libunwind][test] remember_state_leak.pass.sh.s: link with -no-pie

The no-pic large code model style `movabsq $callback, %rsi` does not work with 
-pie.

Added: 


Modified: 
libunwind/test/remember_state_leak.pass.sh.s

Removed: 




diff  --git a/libunwind/test/remember_state_leak.pass.sh.s 
b/libunwind/test/remember_state_leak.pass.sh.s
index f18d1768e7c4..590653e2b10d 100644
--- a/libunwind/test/remember_state_leak.pass.sh.s
+++ b/libunwind/test/remember_state_leak.pass.sh.s
@@ -1,5 +1,5 @@
 # REQUIRES: target={{x86_64-.+-linux-gnu}}
-# RUN: %{build}
+# RUN: %{build} -no-pie
 # RUN: %{run}
 
 # The following assembly is a translation of this code:



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


[PATCH] D120301: clang-tools-extra: Make test dependency on LLVMHello optional

2022-02-25 Thread Jameson Nash via Phabricator via cfe-commits
vtjnash added a subscriber: MaskRay.
vtjnash added a comment.

Seems extra complexity, and less desirable to lose test coverage, when it seems 
the option may already be unreliable and soon to be deprecated by 
https://reviews.llvm.org/D119383. @MaskRay is that accurate?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120301/new/

https://reviews.llvm.org/D120301

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


[PATCH] D120187: [clang-tidy] Allow newline characters as separators for checks in Clang-Tidy configurations

2022-02-25 Thread Hassan ElDesouky via Phabricator via cfe-commits
HassanElDesouky added inline comments.



Comment at: clang-tools-extra/unittests/clang-tidy/ClangTidyOptionsTest.cpp:100
+  EXPECT_TRUE(!!Options);
+  EXPECT_EQ("-*,misc-*\nllvm-*\n-clang-*,\ngoogle-*\n", *Options->Checks);
+}

njames93 wrote:
> SimplyDanny wrote:
> > SimplyDanny wrote:
> > > njames93 wrote:
> > > > This seems like a shortcoming in llvms YAML parser. Isn't the fold 
> > > > character `>` supposed to replace newlines with spaces and strip 
> > > > trailing ws
> > > > ```lang=c++
> > > > "-*,misc-* llvm-* -clang-* google-*"
> > > > ```
> > > > Using the pipe `|` instead should yield the output you are currently 
> > > > expecting,
> > > That's true. `>` should actually not work without a comma after each 
> > > check.
> > `YAMLParser.h` mentions that "Multi-line literal folding" is not yet 
> > implemented.
> So it is, D102590 has been up addressing this very issue (Though its rather 
> stale ATM).
> In any case for now we shouldn't depend on the broken behaviour.
Thanks for motivating me to get D102590 to the finish line. I think it's ready 
now.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120187/new/

https://reviews.llvm.org/D120187

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


[PATCH] D120305: [Driver] Default CLANG_DEFAULT_PIE_ON_LINUX to ON

2022-02-25 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

In D120305#3345978 , @MaskRay wrote:

> In D120305#3345810 , @RKSimon wrote:
>
>> @MaskRay The ppc buildbots have been red since these patches - please can 
>> you take a look? https://lab.llvm.org/buildbot/#/builders/57/builds/15454
>
> Seems that ppc64 doesn't support test/sanitizer_common test/crt -fpie. I'll 
> just disable them: https://github.com/llvm/llvm-project/issues/54084

Actually I don't know how to disable the tests: 
https://lab.llvm.org/buildbot/#/builders/57/builds/15497 still failed.
Hope someone from #powerpc  can disable 
them.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120305/new/

https://reviews.llvm.org/D120305

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


[PATCH] D120395: [X86] Prohibit arithmetic operations on type `__bfloat16`

2022-02-25 Thread Andy Kaylor via Phabricator via cfe-commits
andrew.w.kaylor added a comment.

In D120395#3344890 , @pengfei wrote:

> Disscussed with GCC folks. We think it's better to use the same way as 
> D120411  that replacing it with short int.

Which GCC folks did you discuss it with? I ask because GCC currently considers 
__m128bh and __m128i to be incompatible types, which is what I would expect: 
https://godbolt.org/z/z9nefbrEc


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120395/new/

https://reviews.llvm.org/D120395

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


[PATCH] D119061: [Clang] noinline call site attribute

2022-02-25 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 added inline comments.



Comment at: clang/test/Sema/attr-noinline.cpp:23
+
+  [[gnu::noinline]] bar(); // expected-warning {{'noinline' attribute is 
ignored in statements as it only applies to functions}}
+}

aaron.ballman wrote:
> xbolva00 wrote:
> > aaron.ballman wrote:
> > > It might be nice to clarify the diagnostic; it's not that `noinline` 
> > > attribute is ignored always, it's that `[[gnu::noinline]]` and 
> > > `__attribute__((noinline))` are ignored specifically.
> > > 
> > > Can you add one more test case for:
> > > ```
> > > __attribute__((noinline)) bar();
> > > ```
> > > (I would expect this to also diagnose.)
> > ```
> > __attribute__((noinline)) bar(); 
> > ```
> > 
> > is not diagnosed, as "// The Clang spelling implies GNU, 
> > CXX11<"clang", name>, and optionally," :[] Not sure if this could be easily 
> > fixed.
> That's what I suspected -- I think we should diagnose this case.
> 
> I think I had my idea backwards in Attr.td. We should use `GCC<"noinline">` 
> as the spelling, and add `CXX11<"clang", "noinline">` and `C2x<"clang", 
> "noinline">`; then the GNU spelling is associated with GCC. Then you can 
> change the accessor for the attribute and that should fix this issue.
Ok, it is possible to swap Spellings to handle it as well.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119061/new/

https://reviews.llvm.org/D119061

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


[PATCH] D120577: [14.x] [clang] [test] Skip hip-fpie-option.hip if default-pie

2022-02-25 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay accepted this revision.
MaskRay added a comment.
This revision is now accepted and ready to land.

Seems fine to push to `release/14.x`. Several Linux distros will use 
CLANG_DEFAULT_PIE_ON_LINUX=on and they might wonder why the test fails.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120577/new/

https://reviews.llvm.org/D120577

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


[PATCH] D120577: [14.x] [clang] [test] Skip hip-fpie-option.hip if default-pie

2022-02-25 Thread Michał Górny via Phabricator via cfe-commits
mgorny created this revision.
mgorny added a reviewer: MaskRay.
Herald added a subscriber: yaxunl.
mgorny requested review of this revision.

Skip the hip-fpie-option.hip Driver test if default-pie-on-linux
is used.  This test currently relies on default-no-pie, and it has been
changed to require default-pie in main.


https://reviews.llvm.org/D120577

Files:
  clang/test/Driver/hip-fpie-option.hip


Index: clang/test/Driver/hip-fpie-option.hip
===
--- clang/test/Driver/hip-fpie-option.hip
+++ clang/test/Driver/hip-fpie-option.hip
@@ -1,4 +1,5 @@
 // REQUIRES: clang-driver, amdgpu-registered-target
+// UNSUPPORTED: default-pie-on-linux
 
 // -fPIC and -fPIE only affects host relocation model.
 // device compilation always uses PIC. 


Index: clang/test/Driver/hip-fpie-option.hip
===
--- clang/test/Driver/hip-fpie-option.hip
+++ clang/test/Driver/hip-fpie-option.hip
@@ -1,4 +1,5 @@
 // REQUIRES: clang-driver, amdgpu-registered-target
+// UNSUPPORTED: default-pie-on-linux
 
 // -fPIC and -fPIE only affects host relocation model.
 // device compilation always uses PIC. 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D119061: [Clang] noinline call site attribute

2022-02-25 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/test/Sema/attr-noinline.cpp:23
+
+  [[gnu::noinline]] bar(); // expected-warning {{'noinline' attribute is 
ignored in statements as it only applies to functions}}
+}

xbolva00 wrote:
> aaron.ballman wrote:
> > It might be nice to clarify the diagnostic; it's not that `noinline` 
> > attribute is ignored always, it's that `[[gnu::noinline]]` and 
> > `__attribute__((noinline))` are ignored specifically.
> > 
> > Can you add one more test case for:
> > ```
> > __attribute__((noinline)) bar();
> > ```
> > (I would expect this to also diagnose.)
> ```
> __attribute__((noinline)) bar(); 
> ```
> 
> is not diagnosed, as "// The Clang spelling implies GNU, CXX11<"clang", 
> name>, and optionally," :[] Not sure if this could be easily fixed.
That's what I suspected -- I think we should diagnose this case.

I think I had my idea backwards in Attr.td. We should use `GCC<"noinline">` as 
the spelling, and add `CXX11<"clang", "noinline">` and `C2x<"clang", 
"noinline">`; then the GNU spelling is associated with GCC. Then you can change 
the accessor for the attribute and that should fix this issue.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119061/new/

https://reviews.llvm.org/D119061

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


[PATCH] D119816: [SanitizerBounds] Add support for NoSanitizeBounds function

2022-02-25 Thread Tong Zhang via Phabricator via cfe-commits
ztong0001 updated this revision to Diff 411457.
ztong0001 added a comment.

- update commit description
- In: CodeGenFunction::StartFunction(), merge two 
checks(SanitizerKind::LocalBounds, SanitizerKind::ArrayBounds) into 
one(SanitizerKind::Bounds)
- update test: clang/test/CodeGen/bounds-checking.c to show 
no_sanitize("bounds") can also affect fsanitize=array-bounds (clang)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119816/new/

https://reviews.llvm.org/D119816

Files:
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/test/CodeGen/bounds-checking.c
  clang/test/CodeGen/sanitize-coverage.c
  llvm/bindings/go/llvm/ir_test.go
  llvm/docs/BitCodeFormat.rst
  llvm/docs/LangRef.rst
  llvm/include/llvm/AsmParser/LLToken.h
  llvm/include/llvm/Bitcode/LLVMBitCodes.h
  llvm/include/llvm/IR/Attributes.td
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/Bitcode/Reader/BitcodeReader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/Transforms/Instrumentation/BoundsChecking.cpp
  llvm/lib/Transforms/Utils/CodeExtractor.cpp
  llvm/test/Bitcode/attributes.ll
  llvm/test/Bitcode/compatibility.ll
  llvm/test/Instrumentation/BoundsChecking/nosanitize-bounds.ll
  llvm/utils/emacs/llvm-mode.el
  llvm/utils/llvm.grm
  llvm/utils/vim/syntax/llvm.vim
  llvm/utils/vscode/llvm/syntaxes/ll.tmLanguage.yaml

Index: llvm/utils/vscode/llvm/syntaxes/ll.tmLanguage.yaml
===
--- llvm/utils/vscode/llvm/syntaxes/ll.tmLanguage.yaml
+++ llvm/utils/vscode/llvm/syntaxes/ll.tmLanguage.yaml
@@ -238,6 +238,7 @@
 \\bnosync\\b|\
 \\bnoundef\\b|\
 \\bnounwind\\b|\
+\\bnosanitize_bounds\\b|\
 \\bnosanitize_coverage\\b|\
 \\bnull_pointer_is_valid\\b|\
 \\boptforfuzzing\\b|\
Index: llvm/utils/vim/syntax/llvm.vim
===
--- llvm/utils/vim/syntax/llvm.vim
+++ llvm/utils/vim/syntax/llvm.vim
@@ -139,6 +139,7 @@
   \ nosync
   \ noundef
   \ nounwind
+  \ nosanitize_bounds
   \ nosanitize_coverage
   \ null_pointer_is_valid
   \ optforfuzzing
Index: llvm/utils/llvm.grm
===
--- llvm/utils/llvm.grm
+++ llvm/utils/llvm.grm
@@ -176,6 +176,7 @@
  | sanitize_thread
  | sanitize_memory
  | mustprogress
+ | nosanitize_bounds
  | nosanitize_coverage
  ;

Index: llvm/utils/emacs/llvm-mode.el
===
--- llvm/utils/emacs/llvm-mode.el
+++ llvm/utils/emacs/llvm-mode.el
@@ -25,7 +25,7 @@
'("alwaysinline" "argmemonly" "allocsize" "builtin" "cold" "convergent" "dereferenceable" "dereferenceable_or_null" "hot" "inaccessiblememonly"
  "inaccessiblemem_or_argmemonly" "inalloca" "inlinehint" "jumptable" "minsize" "mustprogress" "naked" "nobuiltin" "nonnull"
  "nocallback" "nocf_check" "noduplicate" "nofree" "noimplicitfloat" "noinline" "nomerge" "nonlazybind" "noprofile" "noredzone" "noreturn"
- "norecurse" "nosync" "noundef" "nounwind" "nosanitize_coverage" "null_pointer_is_valid" "optforfuzzing" "optnone" "optsize" "preallocated" "readnone" "readonly" "returned" "returns_twice"
+ "norecurse" "nosync" "noundef" "nounwind" "nosanitize_bounds" "nosanitize_coverage" "null_pointer_is_valid" "optforfuzzing" "optnone" "optsize" "preallocated" "readnone" "readonly" "returned" "returns_twice"
  "shadowcallstack" "speculatable" "speculative_load_hardening" "ssp" "sspreq" "sspstrong" "safestack" "sanitize_address" "sanitize_hwaddress" "sanitize_memtag"
  "sanitize_thread" "sanitize_memory" "strictfp" "swifterror" "uwtable" "vscale_range" "willreturn" "writeonly" "immarg") 'symbols) . font-lock-constant-face)
;; Variables
Index: llvm/test/Instrumentation/BoundsChecking/nosanitize-bounds.ll
===
--- /dev/null
+++ llvm/test/Instrumentation/BoundsChecking/nosanitize-bounds.ll
@@ -0,0 +1,17 @@
+; RUN: opt < %s -passes=bounds-checking -S | FileCheck %s
+target datalayout = "e-p:64:64:64-p1:16:16:16-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
+
+; CHECK: @foo
+define i32 @foo(i32 %i) nosanitize_bounds {
+entry:
+  %i.addr = alloca i32, align 4
+  %b = alloca [64 x i32], align 16
+  store i32 %i, i32* %i.addr, align 4
+  %0 = load i32, i32* %i.addr, align 4
+  %idxprom = sext i32 %0 to i64
+  %arrayidx = getelementptr inbounds [64 x i32], [64 x i32]* %b, i64 0, i64 %idxprom
+  %1 = load i32, i32* %arrayidx, align 4
+  ret i32 %1
+; CHECK-NOT: call void @llvm.trap()
+}
+
Index: llvm/test/Bitcode/compatibility.ll
===
--- llvm/test/Bitcode/compatibility.ll
+++ llvm/test/Bitcode/compatibility.ll
@@ -1510,7 +1510,7 @@

[PATCH] D119061: [Clang] noinline call site attribute

2022-02-25 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 added inline comments.



Comment at: clang/test/Sema/attr-noinline.cpp:23
+
+  [[gnu::noinline]] bar(); // expected-warning {{'noinline' attribute is 
ignored in statements as it only applies to functions}}
+}

aaron.ballman wrote:
> It might be nice to clarify the diagnostic; it's not that `noinline` 
> attribute is ignored always, it's that `[[gnu::noinline]]` and 
> `__attribute__((noinline))` are ignored specifically.
> 
> Can you add one more test case for:
> ```
> __attribute__((noinline)) bar();
> ```
> (I would expect this to also diagnose.)
```
__attribute__((noinline)) bar(); 
```

is not diagnosed, as "// The Clang spelling implies GNU, CXX11<"clang", 
name>, and optionally," :[] Not sure if this could be easily fixed.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119061/new/

https://reviews.llvm.org/D119061

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


[PATCH] D119061: [Clang] noinline call site attribute

2022-02-25 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

Also, it looks like there are some clang-format nits that can be addressed.




Comment at: clang/include/clang/Basic/AttrDocs.td:525
+
+``noinline`` attribute can also be used as a Clang-specific statement 
attribute.
+If a statement is marked ``noinline`` and contains calls, those calls inside 
the

Maybe we should also say "Only the [[clang::noinline]] spelling can be used as 
a statement attribute; other spellings of the attribute are not supported on 
statements." or something to that effect. WDYT?

Adding some code examples to clarify would also not go amiss.



Comment at: clang/test/Sema/attr-noinline.cpp:23
+
+  [[gnu::noinline]] bar(); // expected-warning {{'noinline' attribute is 
ignored in statements as it only applies to functions}}
+}

It might be nice to clarify the diagnostic; it's not that `noinline` attribute 
is ignored always, it's that `[[gnu::noinline]]` and 
`__attribute__((noinline))` are ignored specifically.

Can you add one more test case for:
```
__attribute__((noinline)) bar();
```
(I would expect this to also diagnose.)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119061/new/

https://reviews.llvm.org/D119061

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


[PATCH] D119816: [SanitizerBounds] Add support for NoSanitizeBounds function

2022-02-25 Thread Tong Zhang via Phabricator via cfe-commits
ztong0001 added inline comments.



Comment at: clang/lib/CodeGen/CodeGenFunction.cpp:757
 SanOpts.set(SanitizerKind::HWAddress, false);
+  if (mask & SanitizerKind::LocalBounds)
+Fn->addFnAttr(llvm::Attribute::NoSanitizeBounds);

ztong0001 wrote:
> melver wrote:
> > These 2 checks can be reduced to 1 due to SanitizerKind::Bounds including 
> > both. However, as noted, this only affects local-bounds, so I'm not sure if 
> > we want to include both -- perhaps for completeness it makes sense, but in 
> > the array-bounds only case this attribute will be a nop (AFAIK).
> > 
> > Also, I think we don't want to attach the attribute if bounds checking 
> > isn't enabled -- at least it seems unnecessary to do so.
> > 
> > See the following suggested change:
> > 
> > ```
> > diff --git a/clang/lib/CodeGen/CodeGenFunction.cpp 
> > b/clang/lib/CodeGen/CodeGenFunction.cpp
> > index 842ce0245d45..c1f3a3014a19 100644
> > --- a/clang/lib/CodeGen/CodeGenFunction.cpp
> > +++ b/clang/lib/CodeGen/CodeGenFunction.cpp
> > @@ -740,6 +740,7 @@ void CodeGenFunction::StartFunction(GlobalDecl GD, 
> > QualType RetTy,
> >} while (false);
> >  
> >if (D) {
> > +const bool SanitizeBounds = SanOpts.hasOneOf(SanitizerKind::Bounds);
> >  bool NoSanitizeCoverage = false;
> >  
> >  for (auto Attr : D->specific_attrs()) {
> > @@ -754,16 +755,15 @@ void CodeGenFunction::StartFunction(GlobalDecl GD, 
> > QualType RetTy,
> >  SanOpts.set(SanitizerKind::KernelHWAddress, false);
> >if (mask & SanitizerKind::KernelHWAddress)
> >  SanOpts.set(SanitizerKind::HWAddress, false);
> > -  if (mask & SanitizerKind::LocalBounds)
> > -Fn->addFnAttr(llvm::Attribute::NoSanitizeBounds);
> > -  if (mask & SanitizerKind::ArrayBounds)
> > -Fn->addFnAttr(llvm::Attribute::NoSanitizeBounds);
> >  
> >// SanitizeCoverage is not handled by SanOpts.
> >if (Attr->hasCoverage())
> >  NoSanitizeCoverage = true;
> >  }
> >  
> > +if (SanitizeBounds && !SanOpts.hasOneOf(SanitizerKind::Bounds))
> > +  Fn->addFnAttr(llvm::Attribute::NoSanitizeBounds);
> > +
> >  if (NoSanitizeCoverage && CGM.getCodeGenOpts().hasSanitizeCoverage())
> >Fn->addFnAttr(llvm::Attribute::NoSanitizeCoverage);
> >}
> > 
> > ```
> Agreed. I will revise patch and commit description.
BTW: Just to double check we are on the same page

when no_sanitize(bounds) is provided, fsanitize=array-bounds is also disabled 
-- right ? I can confirm this attribute is also affecting array-bounds as this 
is handled in clang side and we are setting llvm::Attribute::NoSanitizeBounds 
so that clang's array-bounds can also see this.

I will also add another test for -fsanitize=array-bounds


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119816/new/

https://reviews.llvm.org/D119816

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


[PATCH] D120573: [OpenMP] Support runtime user conditions in metadirective

2022-02-25 Thread Giorgis Georgakoudis via Phabricator via cfe-commits
ggeorgakoudis created this revision.
Herald added subscribers: arphaman, guansong, yaxunl.
ggeorgakoudis requested review of this revision.
Herald added a reviewer: jdoerfert.
Herald added subscribers: llvm-commits, cfe-commits, sstefan1.
Herald added projects: clang, LLVM.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D120573

Files:
  clang/include/clang/AST/OpenMPClause.h
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/AST/StmtOpenMP.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/OpenMPClause.cpp
  clang/lib/AST/StmtOpenMP.cpp
  clang/lib/AST/StmtProfile.cpp
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/lib/Parse/ParseOpenMP.cpp
  clang/lib/Sema/SemaOpenMP.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/tools/libclang/CIndex.cpp
  llvm/include/llvm/Frontend/OpenMP/OMP.td

Index: llvm/include/llvm/Frontend/OpenMP/OMP.td
===
--- llvm/include/llvm/Frontend/OpenMP/OMP.td
+++ llvm/include/llvm/Frontend/OpenMP/OMP.td
@@ -368,7 +368,9 @@
 def OMPC_Align : Clause<"align"> {
   let clangClass = "OMPAlignClause";
 }
-def OMPC_When: Clause<"when"> {}
+def OMPC_When: Clause<"when"> {
+  let clangClass = "OMPWhenClause";
+}
 
 def OMPC_Bind : Clause<"bind"> {
   let clangClass = "OMPBindClause";
Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -2591,6 +2591,10 @@
 }
 void OMPClauseEnqueue::VisitOMPBindClause(const OMPBindClause *C) {}
 
+void OMPClauseEnqueue::VisitOMPWhenClause(const OMPWhenClause *C) {
+  Visitor->AddStmt(C->getDirective());
+}
+
 } // namespace
 
 void EnqueueVisitor::EnqueueChildren(const OMPClause *S) {
Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -6864,6 +6864,12 @@
   Record.AddSourceLocation(C->getBindKindLoc());
 }
 
+void OMPClauseWriter::VisitOMPWhenClause(OMPWhenClause *C) {
+  // TODO: check, not familiar with this.
+  Record.writeOMPTraitInfo(&C->getTraitInfo());
+  Record.AddStmt(C->getDirective());
+}
+
 void ASTRecordWriter::writeOMPTraitInfo(const OMPTraitInfo *TI) {
   writeUInt32(TI->Sets.size());
   for (const auto &Set : TI->Sets) {
Index: clang/lib/Serialization/ASTReader.cpp
===
--- clang/lib/Serialization/ASTReader.cpp
+++ clang/lib/Serialization/ASTReader.cpp
@@ -12994,6 +12994,12 @@
   C->setBindKindLoc(Record.readSourceLocation());
 }
 
+void OMPClauseReader::VisitOMPWhenClause(OMPWhenClause *C) {
+  // TODO: check, not familiar with this.
+  C->setTraitInfo(Record.readOMPTraitInfo());
+  C->setDirective(Record.readStmt());
+}
+
 void OMPClauseReader::VisitOMPAlignClause(OMPAlignClause *C) {
   C->setAlignment(Record.readExpr());
   C->setLParenLoc(Record.readSourceLocation());
Index: clang/lib/Sema/TreeTransform.h
===
--- clang/lib/Sema/TreeTransform.h
+++ clang/lib/Sema/TreeTransform.h
@@ -2284,6 +2284,18 @@
 return getSema().ActOnOpenMPAlignClause(A, StartLoc, LParenLoc, EndLoc);
   }
 
+  /// Build a new OpenMP 'when' clause.
+  ///
+  /// By default, performs semantic analysis to build the new OpenMP clause.
+  /// Subclasses may override this routine to provide different behavior.
+  OMPClause *RebuildOMPWhenClause(OMPTraitInfo &TI, Stmt *Directive,
+  SourceLocation StartLoc,
+  SourceLocation LParenLoc,
+  SourceLocation EndLoc) {
+return getSema().ActOnOpenMPWhenClause(TI, Directive, StartLoc, LParenLoc,
+   EndLoc);
+  }
+
   /// Rebuild the operand to an Objective-C \@synchronized statement.
   ///
   /// By default, performs semantic analysis to build the new statement.
@@ -10323,6 +10335,13 @@
   C->getLParenLoc(), C->getEndLoc());
 }
 
+template 
+OMPClause *TreeTransform::TransformOMPWhenClause(OMPWhenClause *C) {
+  return getDerived().RebuildOMPWhenClause(C->getTraitInfo(), C->getDirective(),
+   C->getBeginLoc(), C->getLParenLoc(),
+   C->getEndLoc());
+}
+
 //===--===//
 // Expression transformation
 //===--===//
Index: clang/lib/Sema/SemaOpenMP.cpp
===
--- clang/lib/Sema/SemaOpenMP.cpp
+++ clang/lib/Sema/SemaOpenMP.cpp
@@ -21631,3 +21631,17 @@
   return OMPBindClause::Create(Context, Kind, KindLoc, StartLoc, LParenLoc,
   

[PATCH] D120305: [Driver] Default CLANG_DEFAULT_PIE_ON_LINUX to ON

2022-02-25 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 added a comment.

In D120305#3344938 , @nikic wrote:

> Hm, it looks like enabling PIE has a pretty big negative compile-time impact, 
> with a 20% regression on sqlite3: 
> http://llvm-compile-time-tracker.com/compare.php?from=611122892e6d5813444bdd0e1fbe0a96f6e09779&to=3c4ed02698afec021c6bca80740d1e58e3ee019e&stat=instructions
>  Code-size on kimwitu++ regresses by 13%.
>
> Is that kind of impact expected?

almost no impact on legacy pm, interesting..


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120305/new/

https://reviews.llvm.org/D120305

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


[PATCH] D120305: [Driver] Default CLANG_DEFAULT_PIE_ON_LINUX to ON

2022-02-25 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

In D120305#3345810 , @RKSimon wrote:

> @MaskRay The ppc buildbots have been red since these patches - please can you 
> take a look? https://lab.llvm.org/buildbot/#/builders/57/builds/15454

Seems that ppc64 doesn't support lsan -fpie. I'll just disable it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120305/new/

https://reviews.llvm.org/D120305

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


[PATCH] D119816: [SanitizerBounds] Add support for NoSanitizeBounds function

2022-02-25 Thread Tong Zhang via Phabricator via cfe-commits
ztong0001 added inline comments.



Comment at: clang/lib/CodeGen/CodeGenFunction.cpp:757
 SanOpts.set(SanitizerKind::HWAddress, false);
+  if (mask & SanitizerKind::LocalBounds)
+Fn->addFnAttr(llvm::Attribute::NoSanitizeBounds);

melver wrote:
> These 2 checks can be reduced to 1 due to SanitizerKind::Bounds including 
> both. However, as noted, this only affects local-bounds, so I'm not sure if 
> we want to include both -- perhaps for completeness it makes sense, but in 
> the array-bounds only case this attribute will be a nop (AFAIK).
> 
> Also, I think we don't want to attach the attribute if bounds checking isn't 
> enabled -- at least it seems unnecessary to do so.
> 
> See the following suggested change:
> 
> ```
> diff --git a/clang/lib/CodeGen/CodeGenFunction.cpp 
> b/clang/lib/CodeGen/CodeGenFunction.cpp
> index 842ce0245d45..c1f3a3014a19 100644
> --- a/clang/lib/CodeGen/CodeGenFunction.cpp
> +++ b/clang/lib/CodeGen/CodeGenFunction.cpp
> @@ -740,6 +740,7 @@ void CodeGenFunction::StartFunction(GlobalDecl GD, 
> QualType RetTy,
>} while (false);
>  
>if (D) {
> +const bool SanitizeBounds = SanOpts.hasOneOf(SanitizerKind::Bounds);
>  bool NoSanitizeCoverage = false;
>  
>  for (auto Attr : D->specific_attrs()) {
> @@ -754,16 +755,15 @@ void CodeGenFunction::StartFunction(GlobalDecl GD, 
> QualType RetTy,
>  SanOpts.set(SanitizerKind::KernelHWAddress, false);
>if (mask & SanitizerKind::KernelHWAddress)
>  SanOpts.set(SanitizerKind::HWAddress, false);
> -  if (mask & SanitizerKind::LocalBounds)
> -Fn->addFnAttr(llvm::Attribute::NoSanitizeBounds);
> -  if (mask & SanitizerKind::ArrayBounds)
> -Fn->addFnAttr(llvm::Attribute::NoSanitizeBounds);
>  
>// SanitizeCoverage is not handled by SanOpts.
>if (Attr->hasCoverage())
>  NoSanitizeCoverage = true;
>  }
>  
> +if (SanitizeBounds && !SanOpts.hasOneOf(SanitizerKind::Bounds))
> +  Fn->addFnAttr(llvm::Attribute::NoSanitizeBounds);
> +
>  if (NoSanitizeCoverage && CGM.getCodeGenOpts().hasSanitizeCoverage())
>Fn->addFnAttr(llvm::Attribute::NoSanitizeCoverage);
>}
> 
> ```
Agreed. I will revise patch and commit description.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119816/new/

https://reviews.llvm.org/D119816

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


[PATCH] D120437: [HWASAN] erase lifetime intrinsics if tag is outside.

2022-02-25 Thread Florian Mayer via Phabricator via cfe-commits
fmayer updated this revision to Diff 411448.
fmayer added a comment.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

fix tests


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120437/new/

https://reviews.llvm.org/D120437

Files:
  clang/test/CodeGen/lifetime-sanitizer.c
  clang/test/CodeGenCXX/lifetime-sanitizer.cpp
  llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
  llvm/test/Instrumentation/HWAddressSanitizer/use-after-scope.ll


Index: llvm/test/Instrumentation/HWAddressSanitizer/use-after-scope.ll
===
--- llvm/test/Instrumentation/HWAddressSanitizer/use-after-scope.ll
+++ llvm/test/Instrumentation/HWAddressSanitizer/use-after-scope.ll
@@ -45,9 +45,7 @@
 ; NOSCOPE-NEXT:call void @__hwasan_tag_memory(i8* [[TMP2]], i8 [[TMP8]], 
i64 16)
 ; NOSCOPE-NEXT:br label [[TMP9:%.*]]
 ; NOSCOPE:   9:
-; NOSCOPE-NEXT:call void @llvm.lifetime.start.p0i8(i64 1, i8* nonnull 
[[ALLOCA_0_HWASAN]])
 ; NOSCOPE-NEXT:[[TMP10:%.*]] = tail call i1 (...) @cond()
-; NOSCOPE-NEXT:call void @llvm.lifetime.end.p0i8(i64 1, i8* nonnull 
[[ALLOCA_0_HWASAN]])
 ; NOSCOPE-NEXT:br i1 [[TMP10]], label [[TMP11:%.*]], label [[TMP9]]
 ; NOSCOPE:   11:
 ; NOSCOPE-NEXT:call void @use(i8* nonnull [[ALLOCA_0_HWASAN]])
@@ -153,12 +151,10 @@
 ; NOSCOPE-NEXT:[[ALLOCA_0_HWASAN:%.*]] = inttoptr i64 [[TMP7]] to i8*
 ; NOSCOPE-NEXT:[[TMP8:%.*]] = trunc i64 [[TMP4]] to i8
 ; NOSCOPE-NEXT:call void @__hwasan_tag_memory(i8* [[TMP2]], i8 [[TMP8]], 
i64 16)
-; NOSCOPE-NEXT:call void @llvm.lifetime.start.p0i8(i64 1, i8* nonnull 
[[ALLOCA_0_HWASAN]])
 ; NOSCOPE-NEXT:[[TMP9:%.*]] = tail call i1 (...) @cond()
 ; NOSCOPE-NEXT:br i1 [[TMP9]], label [[TMP10:%.*]], label [[TMP11:%.*]]
 ; NOSCOPE:   10:
 ; NOSCOPE-NEXT:call void @use(i8* nonnull [[ALLOCA_0_HWASAN]])
-; NOSCOPE-NEXT:call void @llvm.lifetime.end.p0i8(i64 1, i8* nonnull 
[[ALLOCA_0_HWASAN]])
 ; NOSCOPE-NEXT:call void @__hwasan_tag_memory(i8* [[TMP2]], i8 0, i64 16)
 ; NOSCOPE-NEXT:ret i32 0
 ; NOSCOPE:   11:
Index: llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
===
--- llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
+++ llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
@@ -1371,12 +1371,12 @@
   tagAlloca(IRB, AI, Tag, Size);
   for (auto *RI : SInfo.RetVec)
 TagEnd(RI);
-  if (!StandardLifetime) {
-for (auto &II : Info.LifetimeStart)
-  II->eraseFromParent();
-for (auto &II : Info.LifetimeEnd)
-  II->eraseFromParent();
-  }
+  // We inserted tagging outside of the lifetimes, so we have to remove
+  // them.
+  for (auto &II : Info.LifetimeStart)
+II->eraseFromParent();
+  for (auto &II : Info.LifetimeEnd)
+II->eraseFromParent();
 }
 memtag::alignAndPadAlloca(Info, Align(Mapping.getObjectAlignment()));
   }
Index: clang/test/CodeGenCXX/lifetime-sanitizer.cpp
===
--- clang/test/CodeGenCXX/lifetime-sanitizer.cpp
+++ clang/test/CodeGenCXX/lifetime-sanitizer.cpp
@@ -6,8 +6,8 @@
 // RUN: %clang -w -target x86_64-linux-gnu -S -emit-llvm -o - -fno-exceptions 
-O0 \
 // RUN: -fsanitize=memory %s | \
 // RUN: FileCheck %s -check-prefixes=CHECK,LIFETIME
-// RUN: %clang -w -target aarch64-linux-gnu -S -emit-llvm -o - -fno-exceptions 
-O0 \
-// RUN: -fsanitize=hwaddress %s | \
+// RUN: %clang -w -target aarch64-linux-gnu -S -emit-llvm -o /dev/null 
-fno-exceptions -O0 \
+// RUN: -fsanitize=hwaddress -mllvm -print-before=hwasan %s 2>&1 | \
 // RUN: FileCheck %s -check-prefixes=CHECK,LIFETIME
 
 extern int bar(char *A, int n);
Index: clang/test/CodeGen/lifetime-sanitizer.c
===
--- clang/test/CodeGen/lifetime-sanitizer.c
+++ clang/test/CodeGen/lifetime-sanitizer.c
@@ -5,8 +5,8 @@
 // RUN: %clang -target x86_64-linux-gnu -S -emit-llvm -o - -O0 \
 // RUN: -fsanitize=memory %s | \
 // RUN: FileCheck %s -check-prefix=LIFETIME
-// RUN: %clang -target aarch64-linux-gnu -S -emit-llvm -o - -O0 \
-// RUN: -fsanitize=hwaddress %s | \
+// RUN: %clang -target aarch64-linux-gnu -S -emit-llvm -o /dev/null -O0 \
+// RUN: -fsanitize=hwaddress -mllvm -print-before=hwasan %s 2>&1 | \
 // RUN: FileCheck %s -check-prefix=LIFETIME
 
 extern int bar(char *A, int n);


Index: llvm/test/Instrumentation/HWAddressSanitizer/use-after-scope.ll
===
--- llvm/test/Instrumentation/HWAddressSanitizer/use-after-scope.ll
+++ llvm/test/Instrumentation/HWAddressSanitizer/use-after-scope.ll
@@ -45,9 +45,7 @@
 ; NOSCOPE-NEXT:call void @__hwasan_tag_memory(i8* [[TMP2]], i8 [[TMP8]], i64 16)
 ; NOSCOPE-NEXT:b

[PATCH] D119816: [SanitizerBounds] Add support for NoSanitizeBounds function

2022-02-25 Thread Tong Zhang via Phabricator via cfe-commits
ztong0001 added a comment.

In D119816#3345302 , @melver wrote:

> Looks good. Few minor changes.
>
> I did some more digging, and it's only fsanitize=local-bounds, so please 
> verify this and also update the commit description. In fact, the Linux kernel 
> already has a comment about Clang's weirdness of local-bounds vs. 
> array-bounds here: 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/Kconfig.ubsan#n62

Yes I can confirm this. It is indeed fsanitize=local-bounds causing the kernel 
crash we discussed earlier. (UBSAN_LOCAL_BOUNDS=y)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119816/new/

https://reviews.llvm.org/D119816

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


[PATCH] D120563: [HIP] Fix test hip-link-bundled-archive.hip

2022-02-25 Thread Shangwu Yao via Phabricator via cfe-commits
shangwuyao accepted this revision.
shangwuyao added a comment.
This revision is now accepted and ready to land.

LGTM, thanks for fixing this.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120563/new/

https://reviews.llvm.org/D120563

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


[PATCH] D120489: [analyzer] Done some changes to detect Uninitialized read by the char array manipulation functions

2022-02-25 Thread Shivam Rajput via Phabricator via cfe-commits
phyBrackets updated this revision to Diff 411447.
phyBrackets added a comment.

update the documentation for the uninitialized read checker


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120489/new/

https://reviews.llvm.org/D120489

Files:
  clang/docs/analyzer/checkers.rst
  clang/include/clang/StaticAnalyzer/Checkers/Checkers.td
  clang/lib/StaticAnalyzer/Checkers/CStringChecker.cpp
  clang/test/Analysis/bstring.c

Index: clang/test/Analysis/bstring.c
===
--- clang/test/Analysis/bstring.c
+++ clang/test/Analysis/bstring.c
@@ -70,6 +70,11 @@
 
 #endif /* VARIANT */
 
+void top(char *dst) {
+  char buf[10];
+  memcpy(dst, buf, 10); // expected-warning{{Bytes string function accesses uninitialized/garbage values}}
+  (void)buf;
+}
 
 void memcpy0 () {
   char src[] = {1, 2, 3, 4};
@@ -297,9 +302,12 @@
   int dst[5] = {0};
   int *p;
 
-  p = mempcpy(dst, src, 4 * sizeof(int));
+  p = mempcpy(dst, src, 4 * sizeof(int)); // expected-warning{{Bytes string function accesses uninitialized/garbage values}}
+  // FIXME: This behaviour is actually Unexpected and needs to be fix, 
+  // mempcpy seems to consider the src buffered byte as uninitialized
+  // and returning undef which is actually not the case It should return something like Unknown .
 
-  clang_analyzer_eval(p == &dst[4]); // expected-warning{{TRUE}}
+  clang_analyzer_eval(p == &dst[4]); // no-warning (above is fatal)
 }
 
 struct st {
@@ -314,9 +322,10 @@
   struct st *p2;
 
   p1 = (&s2) + 1;
-  p2 = mempcpy(&s2, &s1, sizeof(struct st));
-
-  clang_analyzer_eval(p1 == p2); // expected-warning{{TRUE}}
+  p2 = mempcpy(&s2, &s1, sizeof(struct st)); // expected-warning{{Bytes string function accesses uninitialized/garbage values}}
+  // FIXME: It seems same as mempcpy14() case.
+  
+  clang_analyzer_eval(p1 == p2); // no-warning (above is fatal)
 }
 
 void mempcpy16() {
Index: clang/lib/StaticAnalyzer/Checkers/CStringChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/CStringChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/CStringChecker.cpp
@@ -80,7 +80,7 @@
  check::RegionChanges
  > {
   mutable std::unique_ptr BT_Null, BT_Bounds, BT_Overlap,
-  BT_NotCString, BT_AdditionOverflow;
+  BT_NotCString, BT_AdditionOverflow, BT_UninitRead;
 
   mutable const char *CurrentFunctionDescription;
 
@@ -92,11 +92,13 @@
 DefaultBool CheckCStringOutOfBounds;
 DefaultBool CheckCStringBufferOverlap;
 DefaultBool CheckCStringNotNullTerm;
+DefaultBool CheckCStringUninitializedRead;
 
 CheckerNameRef CheckNameCStringNullArg;
 CheckerNameRef CheckNameCStringOutOfBounds;
 CheckerNameRef CheckNameCStringBufferOverlap;
 CheckerNameRef CheckNameCStringNotNullTerm;
+CheckerNameRef CheckNameCStringUninitializedRead;
   };
 
   CStringChecksFilter Filter;
@@ -257,6 +259,8 @@
   void emitNotCStringBug(CheckerContext &C, ProgramStateRef State,
  const Stmt *S, StringRef WarningMsg) const;
   void emitAdditionOverflowBug(CheckerContext &C, ProgramStateRef State) const;
+  void emitUninitializedReadBug(CheckerContext &C, ProgramStateRef State,
+const Expr *E) const;
 
   ProgramStateRef checkAdditionOverflow(CheckerContext &C,
 ProgramStateRef state,
@@ -368,6 +372,14 @@
 return nullptr;
   }
 
+  // Ensure that we wouldn't read uninitialized value.
+  if (Access == AccessKind::read) {
+if (StInBound->getSVal(ER).isUndef()) {
+  emitUninitializedReadBug(C, StInBound, Buffer.Expression);
+  return nullptr;
+}
+  }
+
   // Array bound check succeeded.  From this point forward the array bound
   // should always succeed.
   return StInBound;
@@ -421,6 +433,7 @@
 SVal BufEnd =
 svalBuilder.evalBinOpLN(State, BO_Add, *BufLoc, LastOffset, PtrTy);
 
+State = CheckLocation(C, State, Buffer, BufStart, Access);
 State = CheckLocation(C, State, Buffer, BufEnd, Access);
 
 // If the buffer isn't large enough, abort.
@@ -580,6 +593,26 @@
   }
 }
 
+void CStringChecker::emitUninitializedReadBug(CheckerContext &C,
+  ProgramStateRef State,
+  const Expr *E) const {
+  if (ExplodedNode *N = C.generateErrorNode(State)) {
+const char *Msg =
+"Bytes string function accesses uninitialized/garbage values";
+if (!BT_UninitRead)
+  BT_UninitRead.reset(
+  new BuiltinBug(Filter.CheckNameCStringUninitializedRead,
+ "Accessing unitialized/garbage values", Msg));
+
+BuiltinBug *BT = static_cast(BT_UninitRead.get());
+
+auto Report = std::make_unique(*BT, Msg, N);
+Report->addRange(E->getSourceRange());
+bugreporter:

[PATCH] D120296: [Attr] Fix a btf_type_tag AST generation bug

2022-02-25 Thread Yonghong Song via Phabricator via cfe-commits
yonghong-song added a comment.

@erichkeane Thanks for suggestion. I will add as an independent type then.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120296/new/

https://reviews.llvm.org/D120296

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


[PATCH] D120296: [Attr] Fix a btf_type_tag AST generation bug

2022-02-25 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

In D120296#3345831 , @yonghong-song 
wrote:

> @aaron.ballman Thanks for suggestion. Agree that Having a new Type is a 
> better idea. I guess, I will add BTFTagAttributeType which extends 
> AttributeType to see whether it works or not.

It almost definitely does NOT want to extend AttributedType, but be its own 
type.  VectorType/BitIntType are both somewhat good examples to follow (besides 
the 'dependent' version, since this is C only). That said, make sure you 
implement ExprConstant.cpp's visitors for your type so that you get these types 
to 'work' like normal types.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120296/new/

https://reviews.llvm.org/D120296

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


[PATCH] D120296: [Attr] Fix a btf_type_tag AST generation bug

2022-02-25 Thread Yonghong Song via Phabricator via cfe-commits
yonghong-song added a comment.

@aaron.ballman Thanks for suggestion. Agree that Having a new Type is a better 
idea. I guess, I will add BTFTagAttributeType which extends AttributeType to 
see whether it works or not.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120296/new/

https://reviews.llvm.org/D120296

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


[PATCH] D120568: [flang][driver] Add support for -S and implement -c/-emit-obj

2022-02-25 Thread Eric Schweitz via Phabricator via cfe-commits
schweitz added inline comments.



Comment at: flang/lib/Frontend/FrontendActions.cpp:43
 using namespace Fortran::frontend;
+using namespace llvm;
 

You'll want to keep in mind that some class names are overloaded between llvm 
and Fortran::xyz namespaces and even between Fortran::uvw and Fortran::xyz 
namespaces.



Comment at: flang/lib/Frontend/FrontendActions.cpp:506
+  std::string error;
+  std::string theTriple = llvmModule->getTargetTriple();
+  const llvm::Target *theTarget =





Comment at: flang/lib/Frontend/FrontendActions.cpp:516
+  llvmModule->setDataLayout(TM->createDataLayout());
+  assert(TM && "Failed to create TargetMachine");
+

This assert comes after `TM` is dereferenced in the line above.



Comment at: flang/lib/Frontend/FrontendActions.cpp:556
+  CodeGenPasses.add(createTargetTransformInfoWrapperPass(TargetIRAnalysis()));
+  Triple triple(llvmModule->getTargetTriple());
+  std::unique_ptr TLII =

getTargetTriple() was already saved into `theTriple` variable above.



Comment at: flang/lib/Frontend/FrontendActions.cpp:559
+  std::make_unique(triple);
+  CodeGenPasses.add(new TargetLibraryInfoWrapperPass(*TLII));
+

Do you want to assert on this RAII of `TLII`?



Comment at: flang/lib/Optimizer/Support/FIRContext.cpp:19
 
-static constexpr const char *tripleName = "fir.triple";
+static constexpr const char *tripleName = "llvm.target_triple";
 

Why is this being changed? This is a FIR specific attribute.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120568/new/

https://reviews.llvm.org/D120568

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


  1   2   >