[PATCH] D77598: Integral template argument suffix and cast printing

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added a comment.

In D77598#3035449 , @dblaikie wrote:

> Came across this while trying to do "simplified template names" - producing 
> template names in DWARF without template parameter lists as part of the 
> textual name, then rebuilding that name from the structural representation of 
> template parameters in DWARF (DW_TAG_template_*_parameter, etc). The 
> roundtripping is implemented to ensure that the simplified names are 
> non-lossy - that all the data is still available through the structural 
> representation. (some names are harder or not currently possible to rebuild)
>
> The selective use of suffixes, especially contextually (overloading) seems 
> like something I'll probably want to avoid entirely for DWARF to keep the 
> names consistent across different contexts - but I am also just a bit 
> confused about some things I'm seeing with this change.
>
> For instance, it looks like 
> https://github.com/llvm/llvm-project/blob/fcdefc8575866a36e80e91024b876937ae6a9965/clang/lib/AST/Decl.cpp#L2900
>  doesn't pass the list of template parameters, so function template names 
> always get suffixes on their integer parameters.
>
> Whereas the equivalent calls for printing class template specialization names 
> here: 
> https://github.com/llvm/llvm-project/blob/fcdefc8575866a36e80e91024b876937ae6a9965/clang/lib/AST/DeclTemplate.cpp#L949-L959
>  - is that just a minor bug/missing functionality?
>
> I'm testing a fix for that:
>
>   diff --git clang/lib/AST/Decl.cpp clang/lib/AST/Decl.cpp
>   index 60ca8633224b..11cf068d2c4c 100644
>   --- clang/lib/AST/Decl.cpp
>   +++ clang/lib/AST/Decl.cpp
>   @@ -2897,7 +2897,7 @@ void FunctionDecl::getNameForDiagnostic(
>  NamedDecl::getNameForDiagnostic(OS, Policy, Qualified);
>  const TemplateArgumentList *TemplateArgs = 
> getTemplateSpecializationArgs();
>  if (TemplateArgs)
>   -printTemplateArgumentList(OS, TemplateArgs->asArray(), Policy);
>   +printTemplateArgumentList(OS, TemplateArgs->asArray(), Policy, 
> getPrimaryTemplate()->getTemplateParameters());
>}
>
>bool FunctionDecl::isVariadic() const {
>
> I've sent out a patch with ^ applied/cleanups applied: D77598 
> 

This seems an oversight on our end, thanks! You probably meant to link 
https://reviews.llvm.org/D110898


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77598

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

[PATCH] D110278: Adding doWithCleanup abstraction

[David Blaikie via Phabricator via cfe-commits]

dblaikie added inline comments.



Comment at: clang/lib/Frontend/FrontendAction.cpp:553-565
+  bool HasBegunSourceFile = false;
+  std::function Operation = [&]() {
+return BeginSourceFileImpl(CI, RealInput, HasBegunSourceFile);
+  };
+  std::function Cleanup = [&]() {
+if (HasBegunSourceFile)
+  CI.getDiagnosticClient().EndSourceFile();

I guess this would be written as:
```
bool Success = BeginSourceFileImpl(CI, RealInput, HasBegunSourceFile))
if (!Success) {
  if (HasBegunSourceFile)
CI.getDiagnosticClient().EndSourceFile();
  CI.clearOutputFiles(/*EraseFiles=*/true);
  CI.getLangOpts().setCompilingModule(LangOptions::CMK_None);
  setCurrentInput(FrontendInputFile());
  setCompilerInstance(nullptr);
}
return Success;
```
Which seems pretty legible - makes me unsure it's worth the complexity of 
building something like `doWithCleanup`, not that it's heinously complicated by 
any means - but all the traits stuff, etc.

& ideally/in general this'd usually be dealt with with some kind of RAII 
ownership model rather than such a strong stateful transition of an existing 
object that needs to be undone, rather than destroying an object.




Comment at: llvm/include/llvm/Support/Cleanup.h:56-59
+template 
+ErrT doWithCleanup(
+std::function Fn, std::function CleanupFn,
+std::function IsFailure = ::isFailure) {

If this is going to be a template anyway, might as well use 
raw/generic/templated functor arguments and avoid the dynamic dispatch overhead 
of std::function? (or at least use llvm::function_ref)



Comment at: llvm/unittests/Support/CleanupTests.cpp:19
+  bool Result =
+  doWithCleanup([] { return true; }, [&] { CleanupRun = true; });
+  EXPECT_TRUE(Result);

Presumably doWithCleanup doesn't need to be called with an explicit template 
type argument most of the time/ever? It's probably good to test it in that way 
too, without passing the explicit template type argument.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110278

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

[PATCH] D110273: [PowerPC] Fix lharx and lbarx builtin signatures

[Albion Fung 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 rG29bb877499ce: [PowerPC] Fix lharx and lbarx builtin 
signatures (authored by Conanap).

Changed prior to commit:
  https://reviews.llvm.org/D110273?vs=374908=376417#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110273

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/test/CodeGen/builtins-ppc-xlcompat-LoadReseve-StoreCond.c


Index: clang/test/CodeGen/builtins-ppc-xlcompat-LoadReseve-StoreCond.c
===
--- clang/test/CodeGen/builtins-ppc-xlcompat-LoadReseve-StoreCond.c
+++ clang/test/CodeGen/builtins-ppc-xlcompat-LoadReseve-StoreCond.c
@@ -24,7 +24,7 @@
   return __lharx(a);
 }
 
-char test_lbarx(volatile unsigned char *a) {
+char test_lbarx(volatile char *a) {
   // CHECK-LABEL: @test_lbarx
   // CHECK: %0 = tail call i8 asm sideeffect "lbarx $0, ${1:y}", 
"=r,*Z,~{memory}"(i8* %a)
   // CHECK-NON-PWR8-ERR:  error: this builtin is only valid on POWER8 or later 
CPUs
@@ -46,3 +46,18 @@
   // CHECK-NON-PWR8-ERR:  error: this builtin is only valid on POWER8 or later 
CPUs
   return __sthcx(a, val);
 }
+
+// Extra test cases that previously caused error during usage.
+int test_lharx_intret(volatile short *a) {
+  // CHECK-LABEL: @test_lharx_intret
+  // CHECK: %0 = tail call i16 asm sideeffect "lharx $0, ${1:y}", 
"=r,*Z,~{memory}"(i16* %a)
+  // CHECK-NON-PWR8-ERR:  error: this builtin is only valid on POWER8 or later 
CPUs
+  return __lharx(a);
+}
+
+int test_lbarx_intret(volatile char *a) {
+  // CHECK-LABEL: @test_lbarx_intret
+  // CHECK: %0 = tail call i8 asm sideeffect "lbarx $0, ${1:y}", 
"=r,*Z,~{memory}"(i8* %a)
+  // CHECK-NON-PWR8-ERR:  error: this builtin is only valid on POWER8 or later 
CPUs
+  return __lbarx(a);
+}
Index: clang/include/clang/Basic/BuiltinsPPC.def
===
--- clang/include/clang/Basic/BuiltinsPPC.def
+++ clang/include/clang/Basic/BuiltinsPPC.def
@@ -74,8 +74,8 @@
 BUILTIN(__builtin_ppc_fetch_and_swaplp, "ULiULiD*ULi", "")
 BUILTIN(__builtin_ppc_ldarx, "LiLiD*", "")
 BUILTIN(__builtin_ppc_lwarx, "iiD*", "")
-BUILTIN(__builtin_ppc_lharx, "isD*", "")
-BUILTIN(__builtin_ppc_lbarx, "UiUcD*", "")
+BUILTIN(__builtin_ppc_lharx, "ssD*", "")
+BUILTIN(__builtin_ppc_lbarx, "ccD*", "")
 BUILTIN(__builtin_ppc_stdcx, "iLiD*Li", "")
 BUILTIN(__builtin_ppc_stwcx, "iiD*i", "")
 BUILTIN(__builtin_ppc_sthcx, "isD*s", "")


Index: clang/test/CodeGen/builtins-ppc-xlcompat-LoadReseve-StoreCond.c
===
--- clang/test/CodeGen/builtins-ppc-xlcompat-LoadReseve-StoreCond.c
+++ clang/test/CodeGen/builtins-ppc-xlcompat-LoadReseve-StoreCond.c
@@ -24,7 +24,7 @@
   return __lharx(a);
 }
 
-char test_lbarx(volatile unsigned char *a) {
+char test_lbarx(volatile char *a) {
   // CHECK-LABEL: @test_lbarx
   // CHECK: %0 = tail call i8 asm sideeffect "lbarx $0, ${1:y}", "=r,*Z,~{memory}"(i8* %a)
   // CHECK-NON-PWR8-ERR:  error: this builtin is only valid on POWER8 or later CPUs
@@ -46,3 +46,18 @@
   // CHECK-NON-PWR8-ERR:  error: this builtin is only valid on POWER8 or later CPUs
   return __sthcx(a, val);
 }
+
+// Extra test cases that previously caused error during usage.
+int test_lharx_intret(volatile short *a) {
+  // CHECK-LABEL: @test_lharx_intret
+  // CHECK: %0 = tail call i16 asm sideeffect "lharx $0, ${1:y}", "=r,*Z,~{memory}"(i16* %a)
+  // CHECK-NON-PWR8-ERR:  error: this builtin is only valid on POWER8 or later CPUs
+  return __lharx(a);
+}
+
+int test_lbarx_intret(volatile char *a) {
+  // CHECK-LABEL: @test_lbarx_intret
+  // CHECK: %0 = tail call i8 asm sideeffect "lbarx $0, ${1:y}", "=r,*Z,~{memory}"(i8* %a)
+  // CHECK-NON-PWR8-ERR:  error: this builtin is only valid on POWER8 or later CPUs
+  return __lbarx(a);
+}
Index: clang/include/clang/Basic/BuiltinsPPC.def
===
--- clang/include/clang/Basic/BuiltinsPPC.def
+++ clang/include/clang/Basic/BuiltinsPPC.def
@@ -74,8 +74,8 @@
 BUILTIN(__builtin_ppc_fetch_and_swaplp, "ULiULiD*ULi", "")
 BUILTIN(__builtin_ppc_ldarx, "LiLiD*", "")
 BUILTIN(__builtin_ppc_lwarx, "iiD*", "")
-BUILTIN(__builtin_ppc_lharx, "isD*", "")
-BUILTIN(__builtin_ppc_lbarx, "UiUcD*", "")
+BUILTIN(__builtin_ppc_lharx, "ssD*", "")
+BUILTIN(__builtin_ppc_lbarx, "ccD*", "")
 BUILTIN(__builtin_ppc_stdcx, "iLiD*Li", "")
 BUILTIN(__builtin_ppc_stwcx, "iiD*i", "")
 BUILTIN(__builtin_ppc_sthcx, "isD*s", "")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 29bb877 - [PowerPC] Fix lharx and lbarx builtin signatures

[Albion Fung via cfe-commits]

Author: Albion Fung
Date: 2021-09-30T22:36:13-05:00
New Revision: 29bb877499ce328f8f4a5d61e9bae94e5f97f908

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

LOG: [PowerPC] Fix lharx and lbarx builtin signatures

The signatures for the PowerPC builtins lharx and
lbarx are incorrect, and causes issues when used in a function
that requires the return of the builtin to be promoted.
This patch fixes these signatures.

Differential revision: https://reviews.llvm.org/D110273

Added: 


Modified: 
clang/include/clang/Basic/BuiltinsPPC.def
clang/test/CodeGen/builtins-ppc-xlcompat-LoadReseve-StoreCond.c

Removed: 




diff  --git a/clang/include/clang/Basic/BuiltinsPPC.def 
b/clang/include/clang/Basic/BuiltinsPPC.def
index 26286c270905e..65f490a214bcb 100644
--- a/clang/include/clang/Basic/BuiltinsPPC.def
+++ b/clang/include/clang/Basic/BuiltinsPPC.def
@@ -74,8 +74,8 @@ BUILTIN(__builtin_ppc_fetch_and_swap, "UiUiD*Ui", "")
 BUILTIN(__builtin_ppc_fetch_and_swaplp, "ULiULiD*ULi", "")
 BUILTIN(__builtin_ppc_ldarx, "LiLiD*", "")
 BUILTIN(__builtin_ppc_lwarx, "iiD*", "")
-BUILTIN(__builtin_ppc_lharx, "isD*", "")
-BUILTIN(__builtin_ppc_lbarx, "UiUcD*", "")
+BUILTIN(__builtin_ppc_lharx, "ssD*", "")
+BUILTIN(__builtin_ppc_lbarx, "ccD*", "")
 BUILTIN(__builtin_ppc_stdcx, "iLiD*Li", "")
 BUILTIN(__builtin_ppc_stwcx, "iiD*i", "")
 BUILTIN(__builtin_ppc_sthcx, "isD*s", "")

diff  --git a/clang/test/CodeGen/builtins-ppc-xlcompat-LoadReseve-StoreCond.c 
b/clang/test/CodeGen/builtins-ppc-xlcompat-LoadReseve-StoreCond.c
index 7c898f523dc85..0362ae389ba06 100644
--- a/clang/test/CodeGen/builtins-ppc-xlcompat-LoadReseve-StoreCond.c
+++ b/clang/test/CodeGen/builtins-ppc-xlcompat-LoadReseve-StoreCond.c
@@ -24,7 +24,7 @@ short test_lharx(volatile short *a) {
   return __lharx(a);
 }
 
-char test_lbarx(volatile unsigned char *a) {
+char test_lbarx(volatile char *a) {
   // CHECK-LABEL: @test_lbarx
   // CHECK: %0 = tail call i8 asm sideeffect "lbarx $0, ${1:y}", 
"=r,*Z,~{memory}"(i8* %a)
   // CHECK-NON-PWR8-ERR:  error: this builtin is only valid on POWER8 or later 
CPUs
@@ -46,3 +46,18 @@ int test_sthcx(volatile short *a, short val) {
   // CHECK-NON-PWR8-ERR:  error: this builtin is only valid on POWER8 or later 
CPUs
   return __sthcx(a, val);
 }
+
+// Extra test cases that previously caused error during usage.
+int test_lharx_intret(volatile short *a) {
+  // CHECK-LABEL: @test_lharx_intret
+  // CHECK: %0 = tail call i16 asm sideeffect "lharx $0, ${1:y}", 
"=r,*Z,~{memory}"(i16* %a)
+  // CHECK-NON-PWR8-ERR:  error: this builtin is only valid on POWER8 or later 
CPUs
+  return __lharx(a);
+}
+
+int test_lbarx_intret(volatile char *a) {
+  // CHECK-LABEL: @test_lbarx_intret
+  // CHECK: %0 = tail call i8 asm sideeffect "lbarx $0, ${1:y}", 
"=r,*Z,~{memory}"(i8* %a)
+  // CHECK-NON-PWR8-ERR:  error: this builtin is only valid on POWER8 or later 
CPUs
+  return __lbarx(a);
+}



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

[PATCH] D110899: [Driver][XRay][test] XFAIL on linux with no environment specified

[Tom Stellard via Phabricator via cfe-commits]

tstellar created this revision.
tstellar added a reviewer: dberris.
tstellar requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D110899

Files:
  clang/test/Driver/XRay/xray-instrument-os.c


Index: clang/test/Driver/XRay/xray-instrument-os.c
===
--- clang/test/Driver/XRay/xray-instrument-os.c
+++ clang/test/Driver/XRay/xray-instrument-os.c
@@ -1,4 +1,4 @@
 // RUN: not %clang -o /dev/null -v -fxray-instrument -c %s
-// XFAIL: -linux-, -freebsd, x86_64-apple-darwin, x86_64-apple-macos
+// XFAIL: -linux-, -freebsd, x86_64-apple-darwin, x86_64-apple-macos, -linux
 // REQUIRES: amd64 || x86_64 || x86_64h || arm || aarch64 || arm64
 typedef int a;


Index: clang/test/Driver/XRay/xray-instrument-os.c
===
--- clang/test/Driver/XRay/xray-instrument-os.c
+++ clang/test/Driver/XRay/xray-instrument-os.c
@@ -1,4 +1,4 @@
 // RUN: not %clang -o /dev/null -v -fxray-instrument -c %s
-// XFAIL: -linux-, -freebsd, x86_64-apple-darwin, x86_64-apple-macos
+// XFAIL: -linux-, -freebsd, x86_64-apple-darwin, x86_64-apple-macos, -linux
 // REQUIRES: amd64 || x86_64 || x86_64h || arm || aarch64 || arm64
 typedef int a;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [llvm-dev] Phabricator Creator Pulling the Plug

[Mehdi AMINI via cfe-commits]

On Thu, Sep 30, 2021 at 8:05 PM Hubert Tong
 wrote:
>
> On Thu, Sep 30, 2021 at 6:56 PM Mehdi AMINI via cfe-commits 
>  wrote:
>>
>> We talked about this with the IWG (Infrastructure Working Group) just
>> last week coincidentally.
>> Two major blocking tracks that were identified at the roundtable
>> during the LLVM Dev Meeting exactly 2 years ago are still an issue
>> today:
>>
>> 1) Replacement for Herald rules. This is what allows us to subscribe
>> and track new revisions or commits based on paths in the repo or other
>> criteria. We could build a replacement based on GitHub action or any
>> other kind of service, but this is a bit tricky (how do you store
>> emails privately? etc.). I have looked around online but I didn't find
>> another OSS project (or external company) providing a similar service
>> for GitHub unfortunately, does anyone know of any?
>>
>> 2) Support for stacked commits. I can see how to structure this
>> somehow assuming we would push pull-request branches in the main repo
>> (with one new commit per branch and cascading the pull-requests from
>> one branch to the other), otherwise this will be a major regression
>> compared to the current workflow.
>>
>> What remains unknown to me is the current state of GitHub management
>> of comments across `git commit --amend` and force push to update a
>> branch.
>
>
> Force pushing to a PR branch does make it harder for reviewers to see how 
> review comments were addressed or what was done since they last looked at the 
> PR. Are your use cases addressed if the workflow consists of pushing 
> additional commits to address comments or pushing a merge commit to refresh 
> the PR branch? When the PR is approved, the "squash and merge" option can be 
> used to commit the patch as a single commit.

This isn't compatible with stacked commits / stacked PR unfortunately.
Also while merging main back into a branch of commits is "OK",
rebasing multiple commits is much less friendly (the same conflict may
have to be fixed over and over in each commit).

> I find the code review experience in GitHub to be a productivity drain 
> compared to Phabricator.
>
> Older inline comments are much harder to find in GitHub.
> Much more clicking needed in GitHub to actually load everything (blocks of 
> comments folded away, comments collapsed not because you want them collapsed 
> but because someone else or maybe just GitHub thought it should be collapsed, 
> source files not loaded).
> GitHub does not allow inline comments further away than a few lines from a 
> change.

Thanks! I have the same feeling, but I didn't have anything specific
to point to and figured that this is in the scope of "I'll get used to
it", but you mention some good points here.

Best,

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

[PATCH] D77598: Integral template argument suffix and cast printing

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

Came across this while trying to do "simplified template names" - producing 
template names in DWARF without template parameter lists as part of the textual 
name, then rebuilding that name from the structural representation of template 
parameters in DWARF (DW_TAG_template_*_parameter, etc). The roundtripping is 
implemented to ensure that the simplified names are non-lossy - that all the 
data is still available through the structural representation. (some names are 
harder or not currently possible to rebuild)

The selective use of suffixes, especially contextually (overloading) seems like 
something I'll probably want to avoid entirely for DWARF to keep the names 
consistent across different contexts - but I am also just a bit confused about 
some things I'm seeing with this change.

For instance, it looks like 
https://github.com/llvm/llvm-project/blob/fcdefc8575866a36e80e91024b876937ae6a9965/clang/lib/AST/Decl.cpp#L2900
 doesn't pass the list of template parameters, so function template names 
always get suffixes on their integer parameters.

Whereas the equivalent calls for printing class template specialization names 
here: 
https://github.com/llvm/llvm-project/blob/fcdefc8575866a36e80e91024b876937ae6a9965/clang/lib/AST/DeclTemplate.cpp#L949-L959
 - is that just a minor bug/missing functionality?

I'm testing a fix for that:

  diff --git clang/lib/AST/Decl.cpp clang/lib/AST/Decl.cpp
  index 60ca8633224b..11cf068d2c4c 100644
  --- clang/lib/AST/Decl.cpp
  +++ clang/lib/AST/Decl.cpp
  @@ -2897,7 +2897,7 @@ void FunctionDecl::getNameForDiagnostic(
 NamedDecl::getNameForDiagnostic(OS, Policy, Qualified);
 const TemplateArgumentList *TemplateArgs = getTemplateSpecializationArgs();
 if (TemplateArgs)
  -printTemplateArgumentList(OS, TemplateArgs->asArray(), Policy);
  +printTemplateArgumentList(OS, TemplateArgs->asArray(), Policy, 
getPrimaryTemplate()->getTemplateParameters());
   }
   
   bool FunctionDecl::isVariadic() const {

I've sent out a patch with ^ applied/cleanups applied: D77598 


But for the debug info, I'm considering changing debug info printing of names 
to use this:

  OS << ND->getDeclName();
  printTemplateArgumentList(OS, Args->Args, PP);

Without passing the template parameters/explicitly printing the name separately 
from the template arguments - but alternatively we could add a PrintingPolicy 
to address this issue instead. (though I have some reasons to prefer this 
separated approach - because I want to separate them explicitly for the 
simplified template name work, for some reasons).

Oh, and here's another case missing its template parameter list: 
https://github.com/llvm/llvm-project/blob/main/clang/lib/AST/NestedNameSpecifier.cpp#L310-L328
 - that one probably points to the DWARF usage needing a more complete way to 
opt out of this - since there might be nested name printing and such that would 
need to be canonicalized (honestly it points to flaws in my idea even without 
nested name specifiers -parameters of parameters would still not be handled 
correctly even if I split up the naming as suggested in the patch above).

@rsmith - any ideas/thoughts/perspectives here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77598

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

Re: [llvm-dev] Phabricator Creator Pulling the Plug

[Hubert Tong via cfe-commits]

On Thu, Sep 30, 2021 at 6:56 PM Mehdi AMINI via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> We talked about this with the IWG (Infrastructure Working Group) just
> last week coincidentally.
> Two major blocking tracks that were identified at the roundtable
> during the LLVM Dev Meeting exactly 2 years ago are still an issue
> today:
>
> 1) Replacement for Herald rules. This is what allows us to subscribe
> and track new revisions or commits based on paths in the repo or other
> criteria. We could build a replacement based on GitHub action or any
> other kind of service, but this is a bit tricky (how do you store
> emails privately? etc.). I have looked around online but I didn't find
> another OSS project (or external company) providing a similar service
> for GitHub unfortunately, does anyone know of any?
>
> 2) Support for stacked commits. I can see how to structure this
> somehow assuming we would push pull-request branches in the main repo
> (with one new commit per branch and cascading the pull-requests from
> one branch to the other), otherwise this will be a major regression
> compared to the current workflow.
>
> What remains unknown to me is the current state of GitHub management
> of comments across `git commit --amend` and force push to update a
> branch.
>

Force pushing to a PR branch does make it harder for reviewers to see how
review comments were addressed or what was done since they last looked at
the PR. Are your use cases addressed if the workflow consists of pushing
additional commits to address comments or pushing a merge commit to refresh
the PR branch? When the PR is approved, the "squash and merge" option can
be used to commit the patch as a single commit.


>
> Others may have other items to add!
>

I find the code review experience in GitHub to be a productivity drain
compared to Phabricator.

Older inline comments are much harder to find in GitHub.
Much more clicking needed in GitHub to actually load everything (blocks of
comments folded away, comments collapsed not because you want them
collapsed but because someone else or maybe just GitHub thought it should
be collapsed, source files not loaded).
GitHub does not allow inline comments further away than a few lines from a
change.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D110898: Pass template parameters when printing template argument lists for function templates

[David Blaikie via Phabricator via cfe-commits]

dblaikie created this revision.
dblaikie added a reviewer: rsmith.
dblaikie requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Improve the application of D77598  by passing 
the template parameter list, allowing integer suffixes to be omitted in more 
places, making for easier to read template names


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D110898

Files:
  clang/lib/AST/Decl.cpp
  clang/test/CodeGenCXX/debug-info-simple-template-names.cpp
  clang/test/SemaCXX/builtin-align-cxx.cpp
  clang/test/SemaCXX/matrix-type-builtins.cpp
  clang/test/SemaCXX/matrix-type-operators.cpp
  clang/test/SemaTemplate/address_space-dependent.cpp
  clang/test/SemaTemplate/delegating-constructors.cpp
  clang/test/SemaTemplate/matrix-type.cpp

Index: clang/test/SemaTemplate/matrix-type.cpp
===
--- clang/test/SemaTemplate/matrix-type.cpp
+++ clang/test/SemaTemplate/matrix-type.cpp
@@ -17,7 +17,7 @@
 
 void instantiate_template_3() {
   matrix_template_3<1, 10>();
-  matrix_template_3<0, 10>(); // expected-note{{in instantiation of function template specialization 'matrix_template_3<0U, 10U>' requested here}}
+  matrix_template_3<0, 10>(); // expected-note{{in instantiation of function template specialization 'matrix_template_3<0, 10>' requested here}}
 }
 
 template 
@@ -27,7 +27,7 @@
 
 void instantiate_template_4() {
   matrix_template_4<2, 10>();
-  matrix_template_4<-3, 10>(); // expected-note{{in instantiation of function template specialization 'matrix_template_4<-3, 10U>' requested here}}
+  matrix_template_4<-3, 10>(); // expected-note{{in instantiation of function template specialization 'matrix_template_4<-3, 10>' requested here}}
 }
 
 template 
Index: clang/test/SemaTemplate/delegating-constructors.cpp
===
--- clang/test/SemaTemplate/delegating-constructors.cpp
+++ clang/test/SemaTemplate/delegating-constructors.cpp
@@ -9,7 +9,7 @@
   public:
 template 
 string(const char ()[N])
-  : string(str) {} // expected-error{{constructor for 'string<6U>' creates a delegation cycle}}
+: string(str) {} // expected-error{{constructor for 'string<6>' creates a delegation cycle}}
   };
 
   void f() {
Index: clang/test/SemaTemplate/address_space-dependent.cpp
===
--- clang/test/SemaTemplate/address_space-dependent.cpp
+++ clang/test/SemaTemplate/address_space-dependent.cpp
@@ -102,7 +102,7 @@
   HasASTemplateFields<1> HASTF;
   neg<-1>(); // expected-note {{in instantiation of function template specialization 'neg<-1>' requested here}}
   correct<0x7FFFEB>();
-  tooBig<8388650>(); // expected-note {{in instantiation of function template specialization 'tooBig<8388650L>' requested here}}
+  tooBig<8388650>(); // expected-note {{in instantiation of function template specialization 'tooBig<8388650>' requested here}}
 
   __attribute__((address_space(1))) char *x;
   __attribute__((address_space(2))) char *y;
Index: clang/test/SemaCXX/matrix-type-operators.cpp
===
--- clang/test/SemaCXX/matrix-type-operators.cpp
+++ clang/test/SemaCXX/matrix-type-operators.cpp
@@ -28,13 +28,13 @@
   Mat1.value = *((decltype(Mat1)::matrix_t *)Ptr1);
   unsigned v1 = add(Mat1, Mat1);
   // expected-error@-1 {{cannot initialize a variable of type 'unsigned int' with an rvalue of type 'typename MyMatrix::matrix_t' (aka 'unsigned int __attribute__((matrix_type(2, 2)))')}}
-  // expected-note@-2 {{in instantiation of function template specialization 'add' requested here}}
+  // expected-note@-2 {{in instantiation of function template specialization 'add' requested here}}
 
   Mat1.value = add(Mat1, Mat2);
-  // expected-note@-1 {{in instantiation of function template specialization 'add' requested here}}
+  // expected-note@-1 {{in instantiation of function template specialization 'add' requested here}}
 
   Mat1.value = add(Mat2, Mat3);
-  // expected-note@-1 {{in instantiation of function template specialization 'add' requested here}}
+  // expected-note@-1 {{in instantiation of function template specialization 'add' requested here}}
 }
 
 template 
@@ -56,13 +56,13 @@
   Mat1.value = *((decltype(Mat1)::matrix_t *)Ptr1);
   unsigned v1 = subtract(Mat1, Mat1);
   // expected-error@-1 {{cannot initialize a variable of type 'unsigned int' with an rvalue of type 'typename MyMatrix::matrix_t' (aka 'unsigned int __attribute__((matrix_type(2, 2)))')}}
-  // expected-note@-2 {{in instantiation of function template specialization 'subtract' requested here}}
+  // expected-note@-2 {{in instantiation of function template specialization 'subtract' requested here}}
 
   Mat1.value = subtract(Mat1, Mat2);
-  // expected-note@-1 {{in instantiation of function template specialization 

[PATCH] D110798: [NFC] Use CHECK-NEXT instead of CHECK-SAME in target-invalid-cpu-note.c

[Freddy, Ye via Phabricator via cfe-commits]

FreddyYe added a comment.

> In principle I agree but did you have this failure mode actually happen?

No failure happens for now, but may happen in the future if we continue to use 
-SAME. Pls read the example I gave in last comment.

> Not sure I like crazy long lines, but I see that -NEXT then -SAME would fall 
> to the same issue.



> Arm targets are just checking that we print *some* list of CPUs, others are 
> putting the full list. Which isn't great because if you add a new CPU it's 
> possible you'll not get a failure here. I looked for other tests that might 
> check the exact set of CPUs but this is the only one.

Yeah, I suppose this is the only one test to check this valid CPU list? Then I 
suppose to add check whole list for Arm targets.

> I think a reasonable compromise is to -NEXT the `note: valid target CPU 
> values are: ` then -SAME the rest. Check the last line 
> ends in `{{$}}`. That limits where extra stuff can sneak in and means you can 
> read the file and it's failure output more easily. (each -SAME line has 
> multiple CPUs on it so that limits how much can be missed)

Can you read the latest example I comment? I think you misunderstand the extra 
outputs I mentioned. Or if I'm wrong, can you give an inline example?

> If you feel like adding the full CPU list to the Arm targets go ahead.

Good to know your thoughts! I'll do.

> What does clang-format complain about? This is a test file so formatting is 
> less of a concern than being readable for maintainers and having useful 
> FileCheck output. Splitting the matches enables that.

Sorry I didn't realize before the fact you mentioned here, let's ignore that 
comment.

Thanks for your review. Helped a lot!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110798

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

[PATCH] D110798: [NFC] Use CHECK-NEXT instead of CHECK-SAME in target-invalid-cpu-note.c

[Freddy, Ye via Phabricator via cfe-commits]

FreddyYe added inline comments.



Comment at: clang/test/Misc/target-invalid-cpu-note.c:33
-// X86_64: note: valid target CPU values are: nocona, core2, penryn, bonnell,
-// X86_64-SAME: atom, silvermont, slm, goldmont, goldmont-plus, tremont, 
nehalem, corei7, westmere,
-// X86_64-SAME: sandybridge, corei7-avx, ivybridge, core-avx-i, haswell,

I forgot to give an example, sorry. For example, if I delete the last 
target-cpu `bonnell,` here, this lit test can still pass. And if I delete any 
of the first or the last target-cpu on each of -SAME line in this file, the 
test can still pass. That is my concern. Fortunately, when I changed this file 
to -NEXT, no new fails happen this time, which means no missing CPUs between 
different -SAME in the old file.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110798

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

[PATCH] D110771: [PowerPC] Fix __builtin_ppc_load2r to return short instead of int.

[Nemanja Ivanovic via Phabricator via cfe-commits]

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

LGTM as long as the sign-extending test is added.




Comment at: 
llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-load-store-reversed.ll:52
 
 define dso_local zeroext i16 @test_builtin_ppc_load2r() {
 ; CHECK-64B-LABEL: test_builtin_ppc_load2r:

Please add an equivalent test with `signext` to ensure there is a `extsh` prior 
to the return.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110771

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

[PATCH] D110858: [PowerPC] Implement vector float and vector double version for vec_orc builtin

[Nemanja Ivanovic via Phabricator via cfe-commits]

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

LGTM. Please run clang-format on the patch (only the modified lines).




Comment at: clang/lib/Headers/altivec.h:7164
+vec_orc(vector double __a, vector double __b) {
+  return (vector double)((vector bool long long)__a | ~(vector unsigned long 
long)__b);
+}

nit: line too long?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110858

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

[PATCH] D109599: [PowerPC][MMA] Allow MMA builtin types in pre-P10 compilation units

[Nemanja Ivanovic via Phabricator via cfe-commits]

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

LGTM as long as you add the back end test.




Comment at: clang/test/CodeGen/ppc-mma-types.c:2
 // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
-// RUN: %clang_cc1 -triple powerpc64le-linux-unknown -target-cpu future \
+// RUN: %clang_cc1 -triple powerpc64le-linux-unknown -target-cpu pwr10 \
+// RUN:   -emit-llvm -O3 -o - %s | FileCheck %s

Please add this IR test to the back end codegen tests (for older CPUs).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109599

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

[PATCH] D110783: [clang] Make crash reproducer work with clang-cl

[Wolfgang Pieb via Phabricator via cfe-commits]

wolfgangp added a comment.

In D110783#3035158 , @dyung wrote:

> Hi, the test you modified Driver/crash-report.cpp is failing on the PS4 bot 
> after your change. Can you take a look?
>
> https://lab.llvm.org/buildbot/#/builders/139/builds/10939

Seems like adding -fexceptions to the response file fixes it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110783

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

[PATCH] D110824: [PowerPC] Fix to guard fetch and cas 64-bit builtin versions

[Nemanja Ivanovic via Phabricator via cfe-commits]

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

LGTM with the test nit addressed.




Comment at: 
clang/test/CodeGen/builtins-ppc-xlcompat-fetch-cas-64bit-only-error.c:1
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// REQUIRES: powerpc-registered-target

I imagine there must be an existing test case handling the other 64-bit only 
builtins that you can add this to.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110824

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

[PATCH] D110216: [clang] retain type sugar in auto / template argument deduction

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added inline comments.



Comment at: clang/lib/Sema/SemaTemplateDeduction.cpp:1643
 
-  return Param == Arg? Sema::TDK_Success : Sema::TDK_NonDeducedMismatch;
+  return ParDesug == ArgDesug ? Sema::TDK_Success
+  : Sema::TDK_NonDeducedMismatch;

mizvekov wrote:
> rsmith wrote:
> > This looks wrong to me: we should be comparing the types, not how they're 
> > written. `Context.hasSameType(Param, Arg)` (or 
> > `Context.hasSameUnqualifiedType(Param, Arg)` in the `TDF_IgnoreQualifiers` 
> > case) would be appropriate here.
> You are right, but the reason we don't get into any troubles here is because 
> this is dead code anyway, the non-dependent case will always be handled above 
> :)
> 
> Although perhaps, I wonder if we should dig down into non-dependent types 
> anyway, in case the types are too complex and it's not immediately obvious 
> what does not match, we could perhaps improve the diagnostic?
> 
> I will experiment a little bit with this idea.
Here are the results of this experiment:
```
error: 'note' diagnostics expected but not seen:
  File SemaCXX\cxx1z-noexcept-function-type.cpp Line 21: could not match 'void 
(I) noexcept(false)' (aka 'void (int) noexcept(false)') against 'void (int) 
noexcept'
error: 'note' diagnostics seen but not expected:
  File SemaCXX\cxx1z-noexcept-function-type.cpp Line 21: candidate template 
ignored: failed template argument deduction

error: 'note' diagnostics expected but not seen:
  File SemaCXX\deduced-return-type-cxx14.cpp Line 146: candidate template 
ignored: could not match 'auto ()' against 'int ()'
  File SemaCXX\deduced-return-type-cxx14.cpp Line 161: candidate template 
ignored: could not match 'auto ()' against 'void ()'
error: 'note' diagnostics seen but not expected:
  File SemaCXX\deduced-return-type-cxx14.cpp Line 146: candidate template 
ignored: could not match 'auto' against 'int'
  File SemaCXX\deduced-return-type-cxx14.cpp Line 161: candidate template 
ignored: could not match 'auto' against 'void'

error: 'note' diagnostics expected but not seen:
  File SemaCXX\pass-object-size.cpp Line 62 (directive at 
SemaCXX\pass-object-size.cpp:69): candidate address cannot be taken because 
parameter 1 has pass_object_size attribute
  File SemaCXX\pass-object-size.cpp Line 56 (directive at 
SemaCXX\pass-object-size.cpp:74): candidate address cannot be taken because 
parameter 1 has pass_object_size attribute
  File SemaCXX\pass-object-size.cpp Line 62 (directive at 
SemaCXX\pass-object-size.cpp:75): candidate address cannot be taken because 
parameter 1 has pass_object_size attribute
error: 'note' diagnostics seen but not expected:
  File SemaCXX\pass-object-size.cpp Line 56: candidate template ignored: failed 
template argument deduction
  File SemaCXX\pass-object-size.cpp Line 62: candidate template ignored: failed 
template argument deduction
  File SemaCXX\pass-object-size.cpp Line 62: candidate template ignored: failed 
template argument deduction

error: 'note' diagnostics expected but not seen:
  File SemaTemplate\deduction.cpp Line 316: deduced non-type template argument 
does not have the same type as the corresponding template parameter 
('std::nullptr_t' vs 'int *')
  File SemaTemplate\deduction.cpp Line 323: values of conflicting types
error: 'note' diagnostics seen but not expected:
  File SemaTemplate\deduction.cpp Line 275: candidate template ignored: could 
not match 'const int' against 'int'
  File SemaTemplate\deduction.cpp Line 316: candidate template ignored: could 
not match 'int *' against 'std::nullptr_t'
  File SemaTemplate\deduction.cpp Line 323: candidate template ignored: could 
not match 'int *' against 'std::nullptr_t'

error: 'note' diagnostics expected but not seen:
  File SemaTemplate\explicit-instantiation.cpp Line 64: candidate template 
ignored: could not match 'void ()' against 'void (float *)'
  File SemaTemplate\explicit-instantiation.cpp Line 70: candidate template 
ignored: could not match 'void (int *)' against 'void (float *)'
error: 'note' diagnostics seen but not expected:
  File SemaTemplate\explicit-instantiation.cpp Line 70: candidate template 
ignored: could not match 'int' against 'float'
  File SemaTemplate\explicit-instantiation.cpp Line 64: candidate template 
ignored: failed template argument deduction
```

It's interesting to note that it reveals several cases we give too generic 
'failed template argument deduction' errors, like the different noexcept 
specifications, function prototypes with different amount of parameters, and 
the 'pass_object_size attribute' case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110216

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

[PATCH] D110891: [inliner] Mandatory inlining decisions produce remarks

[Mircea Trofin via Phabricator via cfe-commits]

mtrofin created this revision.
mtrofin added a reviewer: aeubanks.
Herald added subscribers: ormris, wenlei, hiraditya, eraman.
mtrofin requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

This also removes the need to disable the mandatory inlining phase in
tests.

In a departure from the previous remark, we don't output a 'cost' in
this case, because there's no such thing. We just report that inlining
happened because of the attribute.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D110891

Files:
  clang/test/Frontend/optimization-remark-line-directive.c
  clang/test/Frontend/optimization-remark-new-pm.c
  clang/test/Frontend/optimization-remark-with-hotness-new-pm.c
  clang/test/Frontend/optimization-remark.c
  llvm/include/llvm/Analysis/InlineAdvisor.h
  llvm/lib/Analysis/InlineAdvisor.cpp
  llvm/lib/Transforms/IPO/AlwaysInliner.cpp
  llvm/lib/Transforms/IPO/Inliner.cpp
  llvm/lib/Transforms/IPO/SampleProfile.cpp

Index: llvm/lib/Transforms/IPO/SampleProfile.cpp
===
--- llvm/lib/Transforms/IPO/SampleProfile.cpp
+++ llvm/lib/Transforms/IPO/SampleProfile.cpp
@@ -1204,8 +1204,8 @@
*CalledFunction);
 
 // The call to InlineFunction erases I, so we can't pass it here.
-emitInlinedInto(*ORE, DLoc, BB, *CalledFunction, *BB->getParent(), Cost,
-true, CSINLINE_DEBUG);
+emitInlinedIntoBasedOnCost(*ORE, DLoc, BB, *CalledFunction,
+   *BB->getParent(), Cost, true, CSINLINE_DEBUG);
 
 // Now populate the list of newly exposed call sites.
 if (InlinedCallSites) {
Index: llvm/lib/Transforms/IPO/Inliner.cpp
===
--- llvm/lib/Transforms/IPO/Inliner.cpp
+++ llvm/lib/Transforms/IPO/Inliner.cpp
@@ -464,7 +464,7 @@
 }
 ++NumInlined;
 
-emitInlinedInto(ORE, DLoc, Block, *Callee, *Caller, *OIC);
+emitInlinedIntoBasedOnCost(ORE, DLoc, Block, *Callee, *Caller, *OIC);
 
 // If inlining this function gave us any new call sites, throw them
 // onto our worklist to process.  They are useful inline candidates.
Index: llvm/lib/Transforms/IPO/AlwaysInliner.cpp
===
--- llvm/lib/Transforms/IPO/AlwaysInliner.cpp
+++ llvm/lib/Transforms/IPO/AlwaysInliner.cpp
@@ -73,8 +73,8 @@
 },
 ORE);
 assert(OIC);
-emitInlinedInto(ORE, CB->getDebugLoc(), CB->getParent(), F, *Caller,
-*OIC, false, DEBUG_TYPE);
+emitInlinedIntoBasedOnCost(ORE, CB->getDebugLoc(), CB->getParent(), F,
+   *Caller, *OIC, false, DEBUG_TYPE);
 
 InlineFunctionInfo IFI(
 /*cg=*/nullptr, GetAssumptionCache, ,
Index: llvm/lib/Analysis/InlineAdvisor.cpp
===
--- llvm/lib/Analysis/InlineAdvisor.cpp
+++ llvm/lib/Analysis/InlineAdvisor.cpp
@@ -49,6 +49,48 @@
 
 extern cl::opt InlinerFunctionImportStats;
 
+namespace {
+using namespace llvm::ore;
+class MandatoryInlineAdvice : public InlineAdvice {
+public:
+  MandatoryInlineAdvice(InlineAdvisor *Advisor, CallBase ,
+OptimizationRemarkEmitter ,
+bool IsInliningMandatory)
+  : InlineAdvice(Advisor, CB, ORE, IsInliningMandatory) {}
+
+private:
+  void recordInliningWithCalleeDeletedImpl() override { recordInliningImpl(); }
+
+  void recordInliningImpl() override {
+if (IsInliningRecommended)
+  emitInlinedInto(ORE, DLoc, Block, *Callee, *Caller, IsInliningRecommended,
+  [&](OptimizationRemark ) {
+Remark << ": always inline attribute";
+  });
+  }
+
+  void recordUnsuccessfulInliningImpl(const InlineResult ) override {
+if (IsInliningRecommended)
+  ORE.emit([&]() {
+return OptimizationRemarkMissed(DEBUG_TYPE, "NotInlined", DLoc, Block)
+   << "'" << NV("Callee", Callee) << "' is not AlwaysInline into '"
+   << NV("Caller", Caller)
+   << "': " << NV("Reason", Result.getFailureReason());
+  });
+  }
+
+  void recordUnattemptedInliningImpl() override {
+if (IsInliningRecommended)
+  ORE.emit([&]() {
+return OptimizationRemarkMissed(DEBUG_TYPE, "NotInlined", DLoc, Block)
+   << "'" << NV("Callee", Callee)
+   << "' did not attempt AlwaysInline into '"
+   << NV("Caller", Caller);
+  });
+  }
+};
+} // namespace
+
 void DefaultInlineAdvice::recordUnsuccessfulInliningImpl(
 const InlineResult ) {
   using namespace ore;
@@ -64,12 +106,12 @@
 
 void DefaultInlineAdvice::recordInliningWithCalleeDeletedImpl() {
   if (EmitRemarks)
-emitInlinedInto(ORE, DLoc, Block, *Callee, 

Re: [llvm-dev] Phabricator Creator Pulling the Plug

[Mehdi AMINI via cfe-commits]

On Thu, Sep 30, 2021 at 4:09 PM Brian Cain  wrote:
>
>
>
> On Thu, Sep 30, 2021, 6:04 PM Brian Cain  wrote:
>>
>> Does something like Rust's "bors" bot satisfy the herald rules need?
>
>
>
> sorry, maybe I was thinking of the high-five bot. And it looks like that's 
> not quite a match for herald.

Actually high-five may be a good starting point!
In practice it may still be a bit limited by the GitHub integration:
for example I suspect you may not be able to "subscribe" someone to a
pull-request?
Also what the user will receive as an email may be quite unhelpful
(you have been subscribed to "" instead of the
current more comprehensive emails).


>
>
>>
>> re: #2 I have done this on GHE and it's mildly awkward but it does work.
>>
>> And yes normalizing force pushes is the unfortunate state of GitHub PRs. 
>> Comments are preserved. Code-anchored comments like review comments are 
>> marked as referring to out-of-date code, IIRC.
>>
>> On Thu, Sep 30, 2021, 5:56 PM Mehdi AMINI  wrote:
>>>
>>> We talked about this with the IWG (Infrastructure Working Group) just
>>> last week coincidentally.
>>> Two major blocking tracks that were identified at the roundtable
>>> during the LLVM Dev Meeting exactly 2 years ago are still an issue
>>> today:
>>>
>>> 1) Replacement for Herald rules. This is what allows us to subscribe
>>> and track new revisions or commits based on paths in the repo or other
>>> criteria. We could build a replacement based on GitHub action or any
>>> other kind of service, but this is a bit tricky (how do you store
>>> emails privately? etc.). I have looked around online but I didn't find
>>> another OSS project (or external company) providing a similar service
>>> for GitHub unfortunately, does anyone know of any?
>>>
>>> 2) Support for stacked commits. I can see how to structure this
>>> somehow assuming we would push pull-request branches in the main repo
>>> (with one new commit per branch and cascading the pull-requests from
>>> one branch to the other), otherwise this will be a major regression
>>> compared to the current workflow.
>>>
>>> What remains unknown to me is the current state of GitHub management
>>> of comments across `git commit --amend` and force push to update a
>>> branch.
>>>
>>> Others may have other items to add!
>>>
>>> --
>>> Mehdi
>>>
>>> On Thu, Sep 30, 2021 at 3:39 PM Brian Cain via llvm-dev
>>>  wrote:
>>> >
>>> > How far are we from a workflow that leverages Github's Pull Requests?  Is 
>>> > there some consensus that it's a desired end goal, but some features are 
>>> > missing?  Or do we prefer to use a workflow like this for the long term?
>>> >
>>> > On Thu, Sep 30, 2021, 4:54 PM Chris Tetreault via llvm-dev 
>>> >  wrote:
>>> >>
>>> >> As I, and others have noticed, it seems that as of today, there’s some 
>>> >> certificate issue with arcanist. (See: 
>>> >> https://lists.llvm.org/pipermail/llvm-dev/2021-September/153019.html) 
>>> >> The fix seems simple, and a PR is up, but looking through the PR 
>>> >> activity, it seems that the PR will not be accepted because Phabricator 
>>> >> is no longer being maintained. It seems that arc has become the first 
>>> >> casualty of the discontinuation of maintenance of phabricator.
>>> >>
>>> >>
>>> >>
>>> >> I know that arc is not universally used, but I think it’s a serious blow 
>>> >> to many people’s workflows. I think that MyDeveloperDay’s question might 
>>> >> have just become a bit more urgent.
>>> >>
>>> >>
>>> >>
>>> >> I suppose in the short-term, we could fork the phabricator repos in 
>>> >> order to fix little issues like this. Alternately, we should probably 
>>> >> stop recommending arcanist (unless we want to provide instructions on 
>>> >> how to fix any breakages that come along).
>>> >>
>>> >>
>>> >>
>>> >> Thanks,
>>> >>
>>> >>Chris Tetreault
>>> >>
>>> >>
>>> >>
>>> >> From: llvm-dev  On Behalf Of 
>>> >> MyDeveloper Day via llvm-dev
>>> >> Sent: Wednesday, August 18, 2021 10:17 AM
>>> >> To: llvm-dev ; cfe-commits 
>>> >> 
>>> >> Subject: [llvm-dev] Phabricator Creator Pulling the Plug
>>> >>
>>> >>
>>> >>
>>> >> WARNING: This email originated from outside of Qualcomm. Please be wary 
>>> >> of any links or attachments, and do not enable macros.
>>> >>
>>> >> All
>>> >>
>>> >>
>>> >>
>>> >> I'm a massive fan of Phabricator, and I know there is often lots of 
>>> >> contentious discussion about its relative merits vs github,
>>> >>
>>> >>
>>> >>
>>> >> But unless I missed this, was there any discussion regarding the recent 
>>> >> "Winding Down" announcement of Phabricator? and what it might mean for 
>>> >> us in LLVM
>>> >>
>>> >>
>>> >>
>>> >> See:
>>> >>
>>> >> https://admin.phacility.com/phame/post/view/11/phacility_is_winding_down_operations/
>>> >>
>>> >> https://www.phacility.com/phabricator/
>>> >>
>>> >>
>>> >>
>>> >> Personally I'm excited by the concept of a community driven replacement 
>>> >> ( https://we.phorge.it/) .
>>> >>
>>> >> epriestley did a truly amazing job, it 

[PATCH] D110216: [clang] retain type sugar in auto / template argument deduction

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added inline comments.



Comment at: clang/lib/Sema/SemaTemplateDeduction.cpp:1643
 
-  return Param == Arg? Sema::TDK_Success : Sema::TDK_NonDeducedMismatch;
+  return ParDesug == ArgDesug ? Sema::TDK_Success
+  : Sema::TDK_NonDeducedMismatch;

rsmith wrote:
> This looks wrong to me: we should be comparing the types, not how they're 
> written. `Context.hasSameType(Param, Arg)` (or 
> `Context.hasSameUnqualifiedType(Param, Arg)` in the `TDF_IgnoreQualifiers` 
> case) would be appropriate here.
You are right, but the reason we don't get into any troubles here is because 
this is dead code anyway, the non-dependent case will always be handled above :)

Although perhaps, I wonder if we should dig down into non-dependent types 
anyway, in case the types are too complex and it's not immediately obvious what 
does not match, we could perhaps improve the diagnostic?

I will experiment a little bit with this idea.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110216

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

Re: [llvm-dev] Phabricator Creator Pulling the Plug

[Mehdi AMINI via cfe-commits]

We talked about this with the IWG (Infrastructure Working Group) just
last week coincidentally.
Two major blocking tracks that were identified at the roundtable
during the LLVM Dev Meeting exactly 2 years ago are still an issue
today:

1) Replacement for Herald rules. This is what allows us to subscribe
and track new revisions or commits based on paths in the repo or other
criteria. We could build a replacement based on GitHub action or any
other kind of service, but this is a bit tricky (how do you store
emails privately? etc.). I have looked around online but I didn't find
another OSS project (or external company) providing a similar service
for GitHub unfortunately, does anyone know of any?

2) Support for stacked commits. I can see how to structure this
somehow assuming we would push pull-request branches in the main repo
(with one new commit per branch and cascading the pull-requests from
one branch to the other), otherwise this will be a major regression
compared to the current workflow.

What remains unknown to me is the current state of GitHub management
of comments across `git commit --amend` and force push to update a
branch.

Others may have other items to add!

-- 
Mehdi

On Thu, Sep 30, 2021 at 3:39 PM Brian Cain via llvm-dev
 wrote:
>
> How far are we from a workflow that leverages Github's Pull Requests?  Is 
> there some consensus that it's a desired end goal, but some features are 
> missing?  Or do we prefer to use a workflow like this for the long term?
>
> On Thu, Sep 30, 2021, 4:54 PM Chris Tetreault via llvm-dev 
>  wrote:
>>
>> As I, and others have noticed, it seems that as of today, there’s some 
>> certificate issue with arcanist. (See: 
>> https://lists.llvm.org/pipermail/llvm-dev/2021-September/153019.html) The 
>> fix seems simple, and a PR is up, but looking through the PR activity, it 
>> seems that the PR will not be accepted because Phabricator is no longer 
>> being maintained. It seems that arc has become the first casualty of the 
>> discontinuation of maintenance of phabricator.
>>
>>
>>
>> I know that arc is not universally used, but I think it’s a serious blow to 
>> many people’s workflows. I think that MyDeveloperDay’s question might have 
>> just become a bit more urgent.
>>
>>
>>
>> I suppose in the short-term, we could fork the phabricator repos in order to 
>> fix little issues like this. Alternately, we should probably stop 
>> recommending arcanist (unless we want to provide instructions on how to fix 
>> any breakages that come along).
>>
>>
>>
>> Thanks,
>>
>>Chris Tetreault
>>
>>
>>
>> From: llvm-dev  On Behalf Of MyDeveloper 
>> Day via llvm-dev
>> Sent: Wednesday, August 18, 2021 10:17 AM
>> To: llvm-dev ; cfe-commits 
>> 
>> Subject: [llvm-dev] Phabricator Creator Pulling the Plug
>>
>>
>>
>> WARNING: This email originated from outside of Qualcomm. Please be wary of 
>> any links or attachments, and do not enable macros.
>>
>> All
>>
>>
>>
>> I'm a massive fan of Phabricator, and I know there is often lots of 
>> contentious discussion about its relative merits vs github,
>>
>>
>>
>> But unless I missed this, was there any discussion regarding the recent 
>> "Winding Down" announcement of Phabricator? and what it might mean for us in 
>> LLVM
>>
>>
>>
>> See:
>>
>> https://admin.phacility.com/phame/post/view/11/phacility_is_winding_down_operations/
>>
>> https://www.phacility.com/phabricator/
>>
>>
>>
>> Personally I'm excited by the concept of a community driven replacement ( 
>> https://we.phorge.it/) .
>>
>> epriestley did a truly amazing job, it wasn't open to public contributions. 
>> Perhaps more open development could lead to closing some of the github gaps 
>> that were of concern.
>>
>>
>>
>> MyDeveloperDay
>>
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D110586: Update `DynTypedNode` to support the conversion of `TypeLoc`s.

[James King via Phabricator via cfe-commits]

jcking1034 marked an inline comment as done.
jcking1034 added inline comments.



Comment at: clang/include/clang/AST/ASTTypeTraits.h:472
+  assert(ASTNodeKind::getFromNodeKind().isBaseOf(NodeKind));
+  return *static_cast(reinterpret_cast(Storage));
+}

sbenza wrote:
> The create/get don't seem to match.
> We are constructing a `BaseT` object in `create()`, so this `static_cast` to 
> a derived type is UB?
> That memory does not contain a `T`.
> 
> If we instead construct a `T` in `create()`, we should be able to read it as 
> a `BaseT*` (assuming `is_pointer_interconvertible_base_of` is true)
Done, constructing a `T` instead of a `BaseT` seems to work!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110586

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

[PATCH] D110783: [clang] Make crash reproducer work with clang-cl

[Douglas Yung via Phabricator via cfe-commits]

dyung added a comment.

Hi, the test you modified Driver/crash-report.cpp is failing on the PS4 bot 
after your change. Can you take a look?

https://lab.llvm.org/buildbot/#/builders/139/builds/10939


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110783

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

[PATCH] D110586: Update `DynTypedNode` to support the conversion of `TypeLoc`s.

[James King via Phabricator via cfe-commits]

jcking1034 updated this revision to Diff 376389.
jcking1034 added a comment.

Construct an object of the derived type, instead of the base type.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110586

Files:
  clang/include/clang/AST/ASTTypeTraits.h
  clang/lib/AST/ASTTypeTraits.cpp

Index: clang/lib/AST/ASTTypeTraits.cpp
===
--- clang/lib/AST/ASTTypeTraits.cpp
+++ clang/lib/AST/ASTTypeTraits.cpp
@@ -18,6 +18,7 @@
 #include "clang/AST/DeclCXX.h"
 #include "clang/AST/NestedNameSpecifier.h"
 #include "clang/AST/OpenMPClause.h"
+#include "clang/AST/TypeLoc.h"
 
 using namespace clang;
 
@@ -28,6 +29,8 @@
 {NKI_None, "TemplateName"},
 {NKI_None, "NestedNameSpecifierLoc"},
 {NKI_None, "QualType"},
+#define TYPELOC(CLASS, PARENT) {NKI_##PARENT, #CLASS "TypeLoc"},
+#include "clang/AST/TypeLocNodes.def"
 {NKI_None, "TypeLoc"},
 {NKI_None, "CXXBaseSpecifier"},
 {NKI_None, "CXXCtorInitializer"},
@@ -127,6 +130,17 @@
   llvm_unreachable("invalid type kind");
  }
 
+ ASTNodeKind ASTNodeKind::getFromNode(const TypeLoc ) {
+   switch (T.getTypeLocClass()) {
+#define ABSTRACT_TYPELOC(CLASS, PARENT)
+#define TYPELOC(CLASS, PARENT) \
+  case TypeLoc::CLASS: \
+return ASTNodeKind(NKI_##CLASS##TypeLoc);
+#include "clang/AST/TypeLocNodes.def"
+   }
+   llvm_unreachable("invalid typeloc kind");
+ }
+
 ASTNodeKind ASTNodeKind::getFromNode(const OMPClause ) {
   switch (C.getClauseKind()) {
 #define GEN_CLANG_CLAUSE_CLASS
Index: clang/include/clang/AST/ASTTypeTraits.h
===
--- clang/include/clang/AST/ASTTypeTraits.h
+++ clang/include/clang/AST/ASTTypeTraits.h
@@ -63,6 +63,7 @@
   static ASTNodeKind getFromNode(const Decl );
   static ASTNodeKind getFromNode(const Stmt );
   static ASTNodeKind getFromNode(const Type );
+  static ASTNodeKind getFromNode(const TypeLoc );
   static ASTNodeKind getFromNode(const OMPClause );
   static ASTNodeKind getFromNode(const Attr );
   /// \}
@@ -133,6 +134,8 @@
 NKI_TemplateName,
 NKI_NestedNameSpecifierLoc,
 NKI_QualType,
+#define TYPELOC(CLASS, PARENT) NKI_##CLASS##TypeLoc,
+#include "clang/AST/TypeLocNodes.def"
 NKI_TypeLoc,
 NKI_LastKindWithoutPointerIdentity = NKI_TypeLoc,
 NKI_CXXBaseSpecifier,
@@ -198,6 +201,8 @@
 KIND_TO_KIND_ID(NestedNameSpecifier)
 KIND_TO_KIND_ID(NestedNameSpecifierLoc)
 KIND_TO_KIND_ID(QualType)
+#define TYPELOC(CLASS, PARENT) KIND_TO_KIND_ID(CLASS##TypeLoc)
+#include "clang/AST/TypeLocNodes.def"
 KIND_TO_KIND_ID(TypeLoc)
 KIND_TO_KIND_ID(Decl)
 KIND_TO_KIND_ID(Stmt)
@@ -304,7 +309,7 @@
   return getUnchecked().getAsOpaquePtr() <
  Other.getUnchecked().getAsOpaquePtr();
 
-if (ASTNodeKind::getFromNodeKind().isSame(NodeKind)) {
+if (ASTNodeKind::getFromNodeKind().isBaseOf(NodeKind)) {
   auto TLA = getUnchecked();
   auto TLB = Other.getUnchecked();
   return std::make_pair(TLA.getType().getAsOpaquePtr(),
@@ -336,7 +341,7 @@
 if (ASTNodeKind::getFromNodeKind().isSame(NodeKind))
   return getUnchecked() == Other.getUnchecked();
 
-if (ASTNodeKind::getFromNodeKind().isSame(NodeKind))
+if (ASTNodeKind::getFromNodeKind().isBaseOf(NodeKind))
   return getUnchecked() == Other.getUnchecked();
 
 if (ASTNodeKind::getFromNodeKind().isSame(NodeKind))
@@ -365,7 +370,7 @@
 }
 static unsigned getHashValue(const DynTypedNode ) {
   // FIXME: Add hashing support for the remaining types.
-  if (ASTNodeKind::getFromNodeKind().isSame(Val.NodeKind)) {
+  if (ASTNodeKind::getFromNodeKind().isBaseOf(Val.NodeKind)) {
 auto TL = Val.getUnchecked();
 return llvm::hash_combine(TL.getType().getAsOpaquePtr(),
   TL.getOpaqueData());
@@ -455,6 +460,29 @@
 }
   };
 
+  /// Converter that stores nodes by value. It must be possible to dynamically
+  /// cast the stored node within a type hierarchy without breaking (especially
+  /// through slicing).
+  template >
+  struct DynCastValueConverter {
+static const T *get(ASTNodeKind NodeKind, const void *Storage) {
+  if (ASTNodeKind::getFromNodeKind().isBaseOf(NodeKind))
+return (NodeKind, Storage);
+  return nullptr;
+}
+static const T (ASTNodeKind NodeKind, const void *Storage) {
+  assert(ASTNodeKind::getFromNodeKind().isBaseOf(NodeKind));
+  return *static_cast(reinterpret_cast(Storage));
+}
+static DynTypedNode create(const BaseT ) {
+  DynTypedNode Result;
+  Result.NodeKind = ASTNodeKind::getFromNode(Node);
+  new () T(Node);
+  return Result;
+}
+  };
+
   ASTNodeKind NodeKind;
 
   /// Stores the data of the node.
@@ -525,9 +553,10 @@
 struct DynTypedNode::BaseConverter : public 

[PATCH] D110889: [clang][Fuchsia] Add -DSCUDO_DISABLE_TBI to test flags

[Leonard Chan via Phabricator via cfe-commits]

leonardchan created this revision.
leonardchan added a reviewer: phosek.
Herald added subscribers: cryptoad, kristof.beyls, mgorny.
leonardchan requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

After D110888 , this will ensure that MTE 
tests are skipped when running scudo tests on aarch64.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D110889

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -134,7 +135,7 @@
 set(RUNTIMES_${target}_LLVM_ENABLE_ASSERTIONS OFF CACHE BOOL "")
 set(RUNTIMES_${target}_SANITIZER_CXX_ABI "libc++" CACHE STRING "")
 set(RUNTIMES_${target}_SANITIZER_CXX_ABI_INTREE ON CACHE BOOL "")
-set(RUNTIMES_${target}_COMPILER_RT_TEST_COMPILER_CFLAGS 
"--unwindlib=libunwind -static-libgcc" CACHE STRING "")
+set(RUNTIMES_${target}_COMPILER_RT_TEST_COMPILER_CFLAGS 
"--unwindlib=libunwind -static-libgcc -DSCUDO_DISABLE_TBI" CACHE STRING "")
 set(RUNTIMES_${target}_SANITIZER_COMMON_TEST_TARGET_CFLAGS 
"--unwindlib=libunwind -static-libgcc" CACHE STRING "")
 set(RUNTIMES_${target}_TSAN_TEST_TARGET_CFLAGS "--unwindlib=libunwind" 
CACHE STRING "")
 set(RUNTIMES_${target}_LLVM_TOOLS_DIR "${CMAKE_BINARY_DIR}/bin" CACHE BOOL 
"")


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -134,7 +135,7 @@
 set(RUNTIMES_${target}_LLVM_ENABLE_ASSERTIONS OFF CACHE BOOL "")
 set(RUNTIMES_${target}_SANITIZER_CXX_ABI "libc++" CACHE STRING "")
 set(RUNTIMES_${target}_SANITIZER_CXX_ABI_INTREE ON CACHE BOOL "")
-set(RUNTIMES_${target}_COMPILER_RT_TEST_COMPILER_CFLAGS "--unwindlib=libunwind -static-libgcc" CACHE STRING "")
+set(RUNTIMES_${target}_COMPILER_RT_TEST_COMPILER_CFLAGS "--unwindlib=libunwind -static-libgcc -DSCUDO_DISABLE_TBI" CACHE STRING "")
 set(RUNTIMES_${target}_SANITIZER_COMMON_TEST_TARGET_CFLAGS "--unwindlib=libunwind -static-libgcc" CACHE STRING "")
 set(RUNTIMES_${target}_TSAN_TEST_TARGET_CFLAGS "--unwindlib=libunwind" CACHE STRING "")
 set(RUNTIMES_${target}_LLVM_TOOLS_DIR "${CMAKE_BINARY_DIR}/bin" CACHE BOOL "")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D110869: [X86] Implement -fzero-call-used-regs option

[Bill Wendling via Phabricator via cfe-commits]

void added inline comments.



Comment at: clang/include/clang/Basic/AttrDocs.td:6116
+
+- ``skip`` doesn't zero any call-used registers.
+- ``used`` only zeros call-used registers used in the function. By ``used``, we

void wrote:
> nickdesaulniers wrote:
> > Might be worth a note that `skip` is helpful for disabling previously 
> > occurring instances of the command line flag.  Sometimes toolchains have 
> > wrapper scripts that force on flags, or are built with the implicit default 
> > changed, so being able to explicitly disable a feature can be helpful.
> Doesn't that apply to all (or most) flags though? I don't think they mention 
> that you can override previously set flags...
Oh, I see what you mean now. I'll see what I can do.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110869

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

[PATCH] D110869: [X86] Implement -fzero-call-used-regs option

[Bill Wendling via Phabricator via cfe-commits]

void added a comment.

Hmm...not working on Linux sounds bad. I'll investigate.




Comment at: clang/include/clang/Basic/AttrDocs.td:6116
+
+- ``skip`` doesn't zero any call-used registers.
+- ``used`` only zeros call-used registers used in the function. By ``used``, we

nickdesaulniers wrote:
> Might be worth a note that `skip` is helpful for disabling previously 
> occurring instances of the command line flag.  Sometimes toolchains have 
> wrapper scripts that force on flags, or are built with the implicit default 
> changed, so being able to explicitly disable a feature can be helpful.
Doesn't that apply to all (or most) flags though? I don't think they mention 
that you can override previously set flags...



Comment at: clang/test/Sema/zero_call_used_regs.c:6
+void failure() _zero_call_used_regs();   // expected-error 
{{takes one argument}}
+void failure() _zero_call_used_regs("used", "used-gpr"); // expected-error 
{{takes one argument}}
+void failure() _zero_call_used_regs(0);  // expected-error 
{{requires a string}}

nickdesaulniers wrote:
> How about a test for:
> 
> ```
> void failure 
> __attribute__((zero_call_used_reg("used"),zero_call_used_reg("used-gpr")));
> ```
Should that fail? It seems like the second instance of the attribute should 
override the first one.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110869

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

[PATCH] D110869: [X86] Implement -fzero-call-used-regs option

[Bill Wendling via Phabricator via cfe-commits]

void updated this revision to Diff 376386.
void marked 3 inline comments as done.
void added a comment.

Fixed some spelling and variable names.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110869

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/CodeGen/zero-call-used-regs.c
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  clang/test/Sema/zero_call_used_regs.c
  llvm/include/llvm/Support/CodeGen.h
  llvm/lib/Target/X86/X86FrameLowering.cpp
  llvm/lib/Target/X86/X86FrameLowering.h
  llvm/lib/Target/X86/X86RegisterInfo.cpp
  llvm/lib/Target/X86/X86RegisterInfo.h
  llvm/test/CodeGen/X86/zero-call-used-regs-all-arg.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-all-gpr-arg.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-all-gpr.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-all.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-fmod.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-skip.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-smoke-tests.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-used-arg.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-used-gpr-arg.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-used-gpr.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-used.ll

Index: llvm/test/CodeGen/X86/zero-call-used-regs-used.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/zero-call-used-regs-used.ll
@@ -0,0 +1,28 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc < %s -mtriple=x86_64-unknown-linux-gnu | FileCheck %s
+
+@result = dso_local global i32 0, align 4
+
+define dso_local i32 @foo(i32 returned %x) local_unnamed_addr #0 {
+; CHECK-LABEL: foo:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:movl %edi, %eax
+; CHECK-NEXT:xorl %edi, %edi
+; CHECK-NEXT:retq
+entry:
+  ret i32 %x
+}
+
+define dso_local i32 @main() local_unnamed_addr #1 {
+; CHECK-LABEL: main:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:movl $2, result(%rip)
+; CHECK-NEXT:xorl %eax, %eax
+; CHECK-NEXT:retq
+entry:
+  store volatile i32 2, i32* @result, align 4
+  ret i32 0
+}
+
+attributes #0 = { mustprogress nofree norecurse nosync nounwind readnone uwtable willreturn "frame-pointer"="none" "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" "zero-call-used-regs"="used" }
+attributes #1 = { nofree norecurse nounwind uwtable "frame-pointer"="none" "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" "zero-call-used-regs"="used" }
Index: llvm/test/CodeGen/X86/zero-call-used-regs-used-gpr.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/zero-call-used-regs-used-gpr.ll
@@ -0,0 +1,28 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc < %s -mtriple=x86_64-unknown-linux-gnu | FileCheck %s
+
+@result = dso_local global i32 0, align 4
+
+define dso_local i32 @foo(i32 returned %x) local_unnamed_addr #0 {
+; CHECK-LABEL: foo:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:movl %edi, %eax
+; CHECK-NEXT:xorl %edi, %edi
+; CHECK-NEXT:retq
+entry:
+  ret i32 %x
+}
+
+define dso_local i32 @main() local_unnamed_addr #1 {
+; CHECK-LABEL: main:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:movl $2, result(%rip)
+; CHECK-NEXT:xorl %eax, %eax
+; CHECK-NEXT:retq
+entry:
+  store volatile i32 2, i32* @result, align 4
+  ret i32 0
+}
+
+attributes #0 = { mustprogress nofree norecurse nosync nounwind readnone uwtable willreturn "frame-pointer"="none" "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" "zero-call-used-regs"="used-gpr" }
+attributes #1 = { nofree norecurse nounwind uwtable "frame-pointer"="none" "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" "zero-call-used-regs"="used-gpr" }
Index: llvm/test/CodeGen/X86/zero-call-used-regs-used-gpr-arg.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/zero-call-used-regs-used-gpr-arg.ll
@@ -0,0 +1,28 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc < %s -mtriple=x86_64-unknown-linux-gnu | FileCheck 

[PATCH] D98143: [HIP] Diagnose aggregate args containing half types

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

In D98143#3034672 , @yaxunl wrote:

> On gcc11 and below, since gcc does not support fp16, it is common practice to 
> use short to pass fp16 in struct. Then gcc and clang has different ABI: 
> https://godbolt.org/z/zqhT7x7qo
>
> Basically if one compiles a function with struct type arg containing _Float16 
> with clang, then compiles a caller with struct type arg containing short with 
> gcc, it will not work.

If both compilers use the same type they both agree on, then there's no 
problem. If they pass data using different types but identical names, that's an 
ODR violation and it's not specific to fp16.

Given that fp16 ABI is not stable, the dignostics provided by the patch may be 
a useful safeguard to have.

That said, I'm not quite sure how one would use it in practice. Is that purely 
to check that fp16 is not passed around anywhere in the host code? 
If we compile everything with the check enabled that would potentially produce 
a lot of irrelevant/false-positive results. 
E.g. there may be legitimate host-only code passing fp16 parameters and used 
only from clang-compiled files.
Perhaps the check should be limited to externally visible functions only, and, 
maybe, make it a warning? 
We can not conclusively tell whether use of fp16 by the callee will be a 
problem if we don't know anything about the caller.

Are there specific cases where this particular issue popped up?
I think I did run into an issue with some ROCm headers that were using 
different fp16 types depending on how a file was compiled, even though in both 
cases compiler was clang. It's been a while ago, so I do not recall the exact 
details.
It might've been this code: 
https://github.com/ROCmSoftwarePlatform/rocBLAS/blob/c560f436cea24a7c5b775042464bc4c2989744ca/library/include/internal/rocblas-types.h#L73




Comment at: clang/include/clang/Basic/LangOptions.def:256-258
+LANGOPT(HIPAllowHalfArg, 1, 1, "Allow half precision types or aggregate types "
+   "containing half precision types as host "
+   "function parameter and return types for HIP")

Nit: Maybe simplify it to `Allow using half precision types in host function 
parameter and return types.`

Also, this issue would technically affect CUDA, too, so GPUAllowHalfArg might 
work better.



Comment at: clang/lib/Sema/SemaDecl.cpp:8916-8917
+static void checkHIPFunctionParameters(Sema , FunctionDecl *FD) {
+  if (S.getLangOpts().HIPAllowHalfArg || FD->hasAttr() ||
+  FD->hasAttr())
+return;

I'd split it into separate early exits for the flag and for attribute checks, 
with an added comment that we only check host functions.

That brings the question of how we should handle HD functions. Right now they 
would not checked, which makes it possible to run into the issue you're trying 
to solve if that function is used on the host.





Comment at: clang/test/SemaCUDA/half-arg.cu:9-10
+
+// Check _Float16/__fp16 or structs containing them are not allowed as function
+// parameter in HIP host functions.
+

What happens if I have a lambda that captures an fp16 value? 

Granted, it will be inadvisable to pass across compilers, but, nevertheless 
it's another kind of an aggregate we may end up passing to a function.



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

https://reviews.llvm.org/D98143

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

[PATCH] D110216: [clang] retain type sugar in auto / template argument deduction

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added a comment.

In D110216#3032626 , @v.g.vassilev 
wrote:

> Thanks for working on this!How hard would it be to support:
>
>   using size_t = __SIZE_TYPE__;
>   template struct Id { typedef T type; };
>   int main() {
> struct S {} s;
> Id::type f = s; // just 'unsigned long', 'size_t' sugar has been 
> lost
>   }

Actually supporting that is in my radar :)

Getting the basic idea up is not too complicated.
We need to support 'alias' template specializations which can carry 
non-canonical arguments,
and they would just point to the canonical template specializations.
We would then have to implement our desugaring of 'SubstTemplateTypeParmType' 
so it's able to access some context where it can get the correctly sugared 
ReplacementType for the given replaced 'TemplateTypeParmType'.

But there are some little details that need to be implemented so that it is 
reasonably usable.
For example, in the general case we cannot currently, for any given 
declaration, figure out the template arguments used to instantiate it. We can 
do it for class and function templates, but not for alias and variable 
templates.
We need to make anything that carries template arguments also be a declaration 
context, so we can walk up from any declaration and see those.

There is also the trouble that some elements are not properly parented. For 
example in a requires clause:
`template  requires WHATEVER struct X {}`, WHATEVER is not currently 
parented to the class template, so we would not be able to recover the 
instantiation arguments there unless we fixed it.

And who knows what other non-obvious problems might be lurking :)

A lot of what I said also overlaps with what we need to properly support lazy 
substitution, such as required by C++20 concepts, which is also something I am 
working on.

Getting the 'template argument deduction' machinery to preserve the sugar, 
which we do in this patch, certainly benefits when we get there.

In D110216#3031531 , @rsmith wrote:

> Thanks, this is very exciting, and the diagnostic changes in the test suite 
> look great!

Thank you, much appreciated, and also thanks for the review!




Comment at: 
clang-tools-extra/test/clang-tidy/checkers/cert-static-object-exception.cpp:276
+
+auto NotOkay5 = []() { U u; return u.getBadLambda(); }();
+// CHECK-EXCEPTIONS: :[[@LINE-1]]:6: warning: initialization of 'NotOkay5' 
with static storage duration may throw an exception that cannot be caught 
[cert-err58-cpp]

rsmith wrote:
> What happened here? It looks like nothing this expression does can actually 
> throw. (This lambda's `operator()` isn't `noexcept`, but the functions it 
> calls all are.) Was this only avoiding a false positive by accident before?
I haven't debugged it, I was hoping @aaron.ballman  would know something about 
it and it would save me the trouble :)



Comment at: clang/lib/Sema/SemaTemplateDeduction.cpp:250
 Context.hasSameType(X.getAsType(), Y.getAsType()))
   return X;
 

rsmith wrote:
> I wonder if we can come up with a good heuristic for determining which of `X` 
> and `Y` we want to return here. One thing that immediately springs to mind 
> is: if either type is canonical, we should return the other one.
I was thinking about the opposite actually, something along the lines of 
returning the common sugar between them. Starting from the cannonical type and 
going 'backwards' (adding back the sugar), we return the type just before 
adding sugar back would make them different.



Comment at: clang/lib/Sema/SemaTemplateDeduction.cpp:1051-1052
+  DeduceTemplateArgumentsByTypeMatch(
+  S, TemplateParams, Params[ParamIdx].getUnqualifiedType(),
+  Args[ArgIdx].getUnqualifiedType(), Info, Deduced, TDF,
+  PartialOrdering,

rsmith wrote:
> Hm, do we need the `getUnqualifiedType()` calls here? I'd expect that we'd 
> have the `TDF_IgnoreQualifiers` flag set in this case, so we should be 
> ignoring qualifiers anyway. Perhaps `DeduceTemplateArgumentsByTypeMatch` 
> should be removing qualifiers itself if that flag is set?
The case I am worried about is checking the parameters in the function 
prototype case, and `TDF_IgnoreQualifiers` is neither set there, nor it would 
help if it was set anyway.
I will take a look again, but this was the simplest solution I could come up at 
the time.



Comment at: clang/lib/Sema/SemaTemplateDeduction.cpp:1811-1812
+  S, TemplateParams,
+  FunctionProtoParam->getReturnType().getUnqualifiedType(),
+  FunctionProtoArg->getReturnType().getUnqualifiedType(), Info,
+  Deduced, 0,

rsmith wrote:
> Ignoring qualifiers here doesn't seem right to me. For example:
> ```
> template void f(T(T));
> const int 

[PATCH] D110670: [Sema] Allow comparisons between different ms ptr size address space types.

[Amy Huang via Phabricator via cfe-commits]

akhuang added inline comments.



Comment at: clang/lib/Sema/SemaExprCXX.cpp:6682
+  isPtrSizeAddressSpace(Q2.getAddressSpace()))
+MaybeQ1 = true;
+  else

aaron.ballman wrote:
> akhuang wrote:
> > aaron.ballman wrote:
> > > I'm pretty sure this is correct based on my inspection of what code MSVC 
> > > is generating. But it would be helpful to have some codegen tests in 
> > > Clang for this functionality as well.
> > ha, I apparently didn't check that the behavior actually matches.. 
> > apparently in MSVC a ptr32 isn't equivalent to a ptr64
> Oh! I had tested this:
> ```
> int test1(int * __ptr32 __uptr p32u, int * __ptr32 __sptr p32s,
>  int * __ptr64 p64) {
>   return (p32u == p64);
> }
> 
> int test2(int * __ptr32 __uptr p32u, int * __ptr32 __sptr p32s,
>  int * __ptr64 p64) {
>   return (p64 == p32u);
> }
> ```
> to see whether the order of the operands mattered as to which conversion 
> "won" and I thought I saw that your patch generates the same code that MSVC 
> does. However, I could have messed my testing up somehow, so double-checking 
> is a good idea.
Whoops, you're right, I was not specifying __sptr/__uptr and I guess clang and 
msvc have different defaults for sign/zero extension. 

Will add tests. Also, thanks for reviewing! 



Comment at: clang/test/Sema/MicrosoftExtensions.cpp:9-10
+  return (p32u == p32s) +
+ (p32u == p64) +
+ (p32s == p64);
+}

aaron.ballman wrote:
> (Side question, not directly about this patch but sorta related.) Should 
> there be a diagnostic about conversion potentially causing a possible loss of 
> data (on the 64-bit target)?
Hmm, it seems reasonable, but I also don't know how motivated I am to add a 
diagnostic -- 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110670

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

[PATCH] D110625: [analyzer] canonicalize special case of structure/pointer deref

[Vince Bridgers via Phabricator via cfe-commits]

vabridgers added a comment.

@ASDenysPetrov , thank you for the comment. I added a test case per your 
suggestion.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110625

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

[PATCH] D110625: [analyzer] canonicalize special case of structure/pointer deref

[Vince Bridgers via Phabricator via cfe-commits]

vabridgers updated this revision to Diff 376374.
vabridgers added a comment.

update per comments from Denys


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110625

Files:
  clang/lib/StaticAnalyzer/Core/Store.cpp
  clang/test/Analysis/ptr-arith.c
  clang/test/Analysis/ptr-arith.cpp


Index: clang/test/Analysis/ptr-arith.cpp
===
--- clang/test/Analysis/ptr-arith.cpp
+++ clang/test/Analysis/ptr-arith.cpp
@@ -1,4 +1,8 @@
 // RUN: %clang_analyze_cc1 -Wno-unused-value -std=c++14 
-analyzer-checker=core,debug.ExprInspection,alpha.core.PointerArithm -verify %s
+
+void clang_analyzer_eval(int);
+void clang_analyzer_dump(int);
+
 struct X {
   int *p;
   int zero;
@@ -117,3 +121,26 @@
   auto n = p - reinterpret_cast((__UINTPTR_TYPE__)1);
   return n == m;
 }
+
+struct s {
+  int v;
+};
+using T1 = s;
+typedef s T2;
+void struct_pointer_canon(T1 *ps) {
+  T2 ss = *ps;
+  clang_analyzer_dump((*ps).v);
+  // expected-warning-re@-1{{reg_${{[[:digit:]]+}}}.v>}}
+  clang_analyzer_dump(ps[0].v);
+  // expected-warning-re@-1{{reg_${{[[:digit:]]+}}}.v>}}
+  clang_analyzer_dump(ps->v);
+  // expected-warning-re@-1{{reg_${{[[:digit:]]+}}}.v>}}
+  clang_analyzer_eval((*ps).v == ps[0].v); // expected-warning{{TRUE}}
+  clang_analyzer_eval((*ps).v == ps->v);   // expected-warning{{TRUE}}
+  clang_analyzer_eval(ps[0].v == ps->v);   // expected-warning{{TRUE}}
+}
+
+void struct_pointer_canon_bidim(T1 **ps) {
+  T2 ss = **ps;
+  clang_analyzer_eval(&(ps[0][0].v) == &((*ps)->v)); // 
expected-warning{{TRUE}}
+}
Index: clang/test/Analysis/ptr-arith.c
===
--- clang/test/Analysis/ptr-arith.c
+++ clang/test/Analysis/ptr-arith.c
@@ -2,6 +2,7 @@
 // RUN: %clang_analyze_cc1 
-analyzer-checker=alpha.core.FixedAddr,alpha.core.PointerArithm,alpha.core.PointerSub,debug.ExprInspection
 -analyzer-store=region -Wno-pointer-to-int-cast -verify -triple 
i686-apple-darwin9 -Wno-tautological-pointer-compare -analyzer-config 
eagerly-assume=false %s
 
 void clang_analyzer_eval(int);
+void clang_analyzer_dump(int);
 
 void f1() {
   int a[10];
@@ -330,3 +331,26 @@
   simd_float2 x = {0, 1};
   return x[1]; // no-warning
 }
+
+struct s {
+  int v;
+};
+
+// These three expressions should produce the same sym vals.
+void struct_pointer_canon(struct s *ps) {
+  struct s ss = *ps;
+  clang_analyzer_dump((*ps).v);
+  // expected-warning-re@-1{{reg_${{[[:digit:]]+}}}.v>}}
+  clang_analyzer_dump(ps[0].v);
+  // expected-warning-re@-1{{reg_${{[[:digit:]]+}}}.v>}}
+  clang_analyzer_dump(ps->v);
+  // expected-warning-re@-1{{reg_${{[[:digit:]]+}}}.v>}}
+  clang_analyzer_eval((*ps).v == ps[0].v); // expected-warning{{TRUE}}
+  clang_analyzer_eval((*ps).v == ps->v);   // expected-warning{{TRUE}}
+  clang_analyzer_eval(ps[0].v == ps->v);   // expected-warning{{TRUE}}
+}
+
+void struct_pointer_canon_bidim(struct s **ps) {
+  struct s ss = **ps;
+  clang_analyzer_eval(&(ps[0][0].v) == &((*ps)->v)); // 
expected-warning{{TRUE}}
+}
Index: clang/lib/StaticAnalyzer/Core/Store.cpp
===
--- clang/lib/StaticAnalyzer/Core/Store.cpp
+++ clang/lib/StaticAnalyzer/Core/Store.cpp
@@ -442,6 +442,15 @@
 
 SVal StoreManager::getLValueElement(QualType elementType, NonLoc Offset,
 SVal Base) {
+
+  // Special case, if index is 0, return the same type as if
+  // this was not an array dereference.
+  if (Offset.isZeroConstant()) {
+QualType BT = Base.getType(this->Ctx);
+if (!BT.isNull() && BT->getPointeeType() == elementType)
+  return Base;
+  }
+
   // If the base is an unknown or undefined value, just return it back.
   // FIXME: For absolute pointer addresses, we just return that value back as
   //  well, although in reality we should return the offset added to that


Index: clang/test/Analysis/ptr-arith.cpp
===
--- clang/test/Analysis/ptr-arith.cpp
+++ clang/test/Analysis/ptr-arith.cpp
@@ -1,4 +1,8 @@
 // RUN: %clang_analyze_cc1 -Wno-unused-value -std=c++14 -analyzer-checker=core,debug.ExprInspection,alpha.core.PointerArithm -verify %s
+
+void clang_analyzer_eval(int);
+void clang_analyzer_dump(int);
+
 struct X {
   int *p;
   int zero;
@@ -117,3 +121,26 @@
   auto n = p - reinterpret_cast((__UINTPTR_TYPE__)1);
   return n == m;
 }
+
+struct s {
+  int v;
+};
+using T1 = s;
+typedef s T2;
+void struct_pointer_canon(T1 *ps) {
+  T2 ss = *ps;
+  clang_analyzer_dump((*ps).v);
+  // expected-warning-re@-1{{reg_${{[[:digit:]]+}}}.v>}}
+  clang_analyzer_dump(ps[0].v);
+  // expected-warning-re@-1{{reg_${{[[:digit:]]+}}}.v>}}
+  clang_analyzer_dump(ps->v);
+  // expected-warning-re@-1{{reg_${{[[:digit:]]+}}}.v>}}
+  clang_analyzer_eval((*ps).v == ps[0].v); // expected-warning{{TRUE}}
+  

[PATCH] D110656: [clang][Sema] Warn on uninitialized array elments

[Chris Bieneman via Phabricator via cfe-commits]

beanz added a comment.

In D110656#3034083 , @xbolva00 wrote:

> Why just no special case "= {0};" pattern and do not warn in that case?

This case did show up, but was not the majority of issues for LLVM (although 
might be the majority we care about). The related `= {nullptr};` pattern also 
shows a few times.

> If there are more patterns, take it from other side - pick patterns where you 
> are sure that they are wrong and developer needs to fix them and emit 
> warnings for them.

There are a bunch of places (particularly in LLVM instruction matching), where 
LLVM generates data structures with statically sized arrays that hold the 
maximum possible values, and rely on zero-initialized values to denote the end 
of the used space.

For the tablegen-genreated code wrapping in `pragma`s to disable the warning 
works, but there isn't really a good way that I can think of to not emit a 
warning for an array of 10 elements where we provide 6 in a general case while 
also warning on the actual potential bug.

In D110656#3034149 , @xbolva00 wrote:

> If possible, @beanz could share list of new warnings from LLVM build here?

The big offenders were the tablegen-generated asm and register matchers and the 
target files under clang/lib/Basic/Targets. Those accounted for filling my 
scroll back buffer a few times over...

I'm running a new build now disabling the warning int he clang target files to 
see how that shapes up. Will share what I find.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110656

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

[PATCH] D110871: [RISCV] Remove Zbproposedc extension

[Craig Topper via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGa21c557955c6: [RISCV] Remove Zbproposedc extension (authored 
by craig.topper).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110871

Files:
  clang/lib/Basic/Targets/RISCV.cpp
  clang/lib/Basic/Targets/RISCV.h
  clang/lib/Driver/ToolChains/Arch/RISCV.cpp
  clang/test/Preprocessor/riscv-target-features.c
  llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
  llvm/lib/Target/RISCV/Disassembler/RISCVDisassembler.cpp
  llvm/lib/Target/RISCV/MCTargetDesc/RISCVTargetStreamer.cpp
  llvm/lib/Target/RISCV/RISCV.td
  llvm/lib/Target/RISCV/RISCVInstrInfoB.td
  llvm/lib/Target/RISCV/RISCVSubtarget.h
  llvm/test/CodeGen/RISCV/attributes.ll
  llvm/test/MC/RISCV/attribute-arch.s
  llvm/test/MC/RISCV/compress-rv32b.s
  llvm/test/MC/RISCV/compress-rv64b.s
  llvm/test/MC/RISCV/rv32zbproposedc-invalid.s
  llvm/test/MC/RISCV/rv32zbproposedc-valid.s
  llvm/test/MC/RISCV/rv64zbproposedc-invalid.s
  llvm/test/MC/RISCV/rv64zbproposedc-valid.s

Index: llvm/test/MC/RISCV/rv64zbproposedc-valid.s
===
--- llvm/test/MC/RISCV/rv64zbproposedc-valid.s
+++ /dev/null
@@ -1,10 +0,0 @@
-# RUN: llvm-mc %s -triple=riscv64 -mattr=+c,+experimental-zbproposedc,+experimental-b -riscv-no-aliases -show-encoding \
-# RUN: | FileCheck -check-prefixes=CHECK-ASM,CHECK-ASM-AND-OBJ %s
-# RUN: llvm-mc -filetype=obj -triple=riscv64 -mattr=+c,+experimental-zbproposedc,+experimental-b < %s \
-# RUN: | llvm-objdump --mattr=+c,+experimental-zbproposedc,+experimental-b -M no-aliases -d -r - \
-# RUN: | FileCheck --check-prefix=CHECK-ASM-AND-OBJ %s
-
-
-# CHECK-ASM-AND-OBJ: c.zext.w s0
-# CHECK-ASM: encoding: [0x01,0x68]
-c.zext.w s0
Index: llvm/test/MC/RISCV/rv64zbproposedc-invalid.s
===
--- llvm/test/MC/RISCV/rv64zbproposedc-invalid.s
+++ /dev/null
@@ -1,4 +0,0 @@
-# RUN: not llvm-mc -triple riscv64 -mattr=+c,+experimental-zbproposedc,+experimental-b < %s 2>&1 | FileCheck %s
-
-# Too many operands
-c.zext.w s0, s1 # CHECK: :[[@LINE]]:14: error: invalid operand for instruction
Index: llvm/test/MC/RISCV/rv32zbproposedc-valid.s
===
--- llvm/test/MC/RISCV/rv32zbproposedc-valid.s
+++ /dev/null
@@ -1,17 +0,0 @@
-# RUN: llvm-mc %s -triple=riscv32 -mattr=+c,+experimental-zbproposedc -riscv-no-aliases -show-encoding \
-# RUN: | FileCheck -check-prefixes=CHECK-ASM,CHECK-ASM-AND-OBJ %s
-# RUN: llvm-mc %s -triple=riscv64 -mattr=+c,+experimental-zbproposedc,+experimental-b -riscv-no-aliases -show-encoding \
-# RUN: | FileCheck -check-prefixes=CHECK-ASM,CHECK-ASM-AND-OBJ %s
-# RUN: llvm-mc -filetype=obj -triple=riscv32 -mattr=+c,+experimental-zbproposedc < %s \
-# RUN: | llvm-objdump --mattr=+c,+experimental-zbproposedc -M no-aliases -d -r - \
-# RUN: | FileCheck --check-prefix=CHECK-ASM-AND-OBJ %s
-# RUN: llvm-mc -filetype=obj -triple=riscv64 -mattr=+c,+experimental-zbproposedc,+experimental-b < %s \
-# RUN: | llvm-objdump --mattr=+c,+experimental-zbproposedc,+experimental-b -M no-aliases -d -r - \
-# RUN: | FileCheck --check-prefix=CHECK-ASM-AND-OBJ %s
-
-# CHECK-ASM-AND-OBJ: c.not s0
-# CHECK-ASM: encoding: [0x01,0x60]
-c.not s0
-# CHECK-ASM-AND-OBJ: c.neg s0
-# CHECK-ASM: encoding: [0x01,0x64]
-c.neg s0
Index: llvm/test/MC/RISCV/rv32zbproposedc-invalid.s
===
--- llvm/test/MC/RISCV/rv32zbproposedc-invalid.s
+++ /dev/null
@@ -1,6 +0,0 @@
-# RUN: not llvm-mc -triple riscv32 -mattr=+c,+experimental-zbproposedc,+experimental-Zba < %s 2>&1 | FileCheck %s
-
-# Too many operands
-c.not s0, s1 # CHECK: :[[@LINE]]:11: error: invalid operand for instruction
-c.neg s0, s1 # CHECK: :[[@LINE]]:11: error: invalid operand for instruction
-c.zext.w s0 # CHECK: :[[@LINE]]:1: error: instruction requires the following: RV64I Base Instruction Set
Index: llvm/test/MC/RISCV/compress-rv64b.s
===
--- llvm/test/MC/RISCV/compress-rv64b.s
+++ /dev/null
@@ -1,18 +0,0 @@
-# RUN: llvm-mc -triple riscv64 -mattr=+c,+experimental-zbproposedc,+experimental-b -show-encoding < %s \
-# RUN:   | FileCheck -check-prefixes=CHECK-ALIAS %s
-# RUN: llvm-mc -triple riscv64 -mattr=+c,+experimental-zbproposedc,+experimental-b -show-encoding \
-# RUN:   -riscv-no-aliases < %s | FileCheck -check-prefixes=CHECK-INST %s
-# RUN: llvm-mc -triple riscv64 -mattr=+c,+experimental-zbproposedc,+experimental-b -filetype=obj < %s \
-# RUN:   | llvm-objdump  --triple=riscv64 --mattr=+c,+experimental-zbproposedc,+experimental-b -d - \
-# RUN:   | FileCheck -check-prefixes=CHECK-BYTES,CHECK-ALIAS %s
-# RUN: llvm-mc -triple riscv64 

[clang] a21c557 - [RISCV] Remove Zbproposedc extension

[Craig Topper via cfe-commits]

Author: Craig Topper
Date: 2021-09-30T14:23:05-07:00
New Revision: a21c557955c6ea5cd02b9a145ad6469c608446c7

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

LOG: [RISCV] Remove Zbproposedc extension

This consists of 3 compressed instructions, c.not, c.neg, and c.zext.w.
I believe these have been picked up by the Zce effort using different
encodings. I don't think it makes sense to keep them in bitmanip. It
will eventually cause a conflict if/when Zce is implemented in llvm.

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

Added: 


Modified: 
clang/lib/Basic/Targets/RISCV.cpp
clang/lib/Basic/Targets/RISCV.h
clang/lib/Driver/ToolChains/Arch/RISCV.cpp
clang/test/Preprocessor/riscv-target-features.c
llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
llvm/lib/Target/RISCV/Disassembler/RISCVDisassembler.cpp
llvm/lib/Target/RISCV/MCTargetDesc/RISCVTargetStreamer.cpp
llvm/lib/Target/RISCV/RISCV.td
llvm/lib/Target/RISCV/RISCVInstrInfoB.td
llvm/lib/Target/RISCV/RISCVSubtarget.h
llvm/test/CodeGen/RISCV/attributes.ll
llvm/test/MC/RISCV/attribute-arch.s

Removed: 
llvm/test/MC/RISCV/compress-rv32b.s
llvm/test/MC/RISCV/compress-rv64b.s
llvm/test/MC/RISCV/rv32zbproposedc-invalid.s
llvm/test/MC/RISCV/rv32zbproposedc-valid.s
llvm/test/MC/RISCV/rv64zbproposedc-invalid.s
llvm/test/MC/RISCV/rv64zbproposedc-valid.s



diff  --git a/clang/lib/Basic/Targets/RISCV.cpp 
b/clang/lib/Basic/Targets/RISCV.cpp
index 567f600871352..88de246f7bd7c 100644
--- a/clang/lib/Basic/Targets/RISCV.cpp
+++ b/clang/lib/Basic/Targets/RISCV.cpp
@@ -207,9 +207,6 @@ void RISCVTargetInfo::getTargetDefines(const LangOptions 
,
   if (HasZbp)
 Builder.defineMacro("__riscv_zbp", "93000");
 
-  if (HasZbproposedc)
-Builder.defineMacro("__riscv_zbproposedc", "93000");
-
   if (HasZbr)
 Builder.defineMacro("__riscv_zbr", "93000");
 
@@ -274,7 +271,6 @@ bool RISCVTargetInfo::hasFeature(StringRef Feature) const {
   .Case("experimental-zbf", HasZbf)
   .Case("experimental-zbm", HasZbm)
   .Case("experimental-zbp", HasZbp)
-  .Case("experimental-zbproposedc", HasZbproposedc)
   .Case("experimental-zbr", HasZbr)
   .Case("experimental-zbs", HasZbs)
   .Case("experimental-zbt", HasZbt)
@@ -316,8 +312,6 @@ bool 
RISCVTargetInfo::handleTargetFeatures(std::vector ,
   HasZbm = true;
 else if (Feature == "+experimental-zbp")
   HasZbp = true;
-else if (Feature == "+experimental-zbproposedc")
-  HasZbproposedc = true;
 else if (Feature == "+experimental-zbr")
   HasZbr = true;
 else if (Feature == "+experimental-zbs")

diff  --git a/clang/lib/Basic/Targets/RISCV.h b/clang/lib/Basic/Targets/RISCV.h
index 9609b6fc3f307..a26a9a41176e8 100644
--- a/clang/lib/Basic/Targets/RISCV.h
+++ b/clang/lib/Basic/Targets/RISCV.h
@@ -39,7 +39,6 @@ class RISCVTargetInfo : public TargetInfo {
   bool HasZbf = false;
   bool HasZbm = false;
   bool HasZbp = false;
-  bool HasZbproposedc = false;
   bool HasZbr = false;
   bool HasZbs = false;
   bool HasZbt = false;

diff  --git a/clang/lib/Driver/ToolChains/Arch/RISCV.cpp 
b/clang/lib/Driver/ToolChains/Arch/RISCV.cpp
index ade93d6881a7a..3e724d69b897c 100644
--- a/clang/lib/Driver/ToolChains/Arch/RISCV.cpp
+++ b/clang/lib/Driver/ToolChains/Arch/RISCV.cpp
@@ -60,7 +60,7 @@ static Optional
 isExperimentalExtension(StringRef Ext) {
   if (Ext == "b" || Ext == "zba" || Ext == "zbb" || Ext == "zbc" ||
   Ext == "zbe" || Ext == "zbf" || Ext == "zbm" || Ext == "zbp" ||
-  Ext == "zbr" || Ext == "zbs" || Ext == "zbt" || Ext == "zbproposedc")
+  Ext == "zbr" || Ext == "zbs" || Ext == "zbt")
 return RISCVExtensionVersion{"0", "93"};
   if (Ext == "v" || Ext == "zvamo" || Ext == "zvlsseg")
 return RISCVExtensionVersion{"0", "10"};

diff  --git a/clang/test/Preprocessor/riscv-target-features.c 
b/clang/test/Preprocessor/riscv-target-features.c
index ea5754a83f1ea..bc6cbd24eb869 100644
--- a/clang/test/Preprocessor/riscv-target-features.c
+++ b/clang/test/Preprocessor/riscv-target-features.c
@@ -25,7 +25,6 @@
 // CHECK-NOT: __riscv_zbf
 // CHECK-NOT: __riscv_zbm
 // CHECK-NOT: __riscv_zbp
-// CHECK-NOT: __riscv_zbproposedc
 // CHECK-NOT: __riscv_zbr
 // CHECK-NOT: __riscv_zbs
 // CHECK-NOT: __riscv_zbt
@@ -182,15 +181,6 @@
 // CHECK-ZBP-NOT: __riscv_b
 // CHECK-ZBP-EXT: __riscv_zbp 93000
 
-// RUN: %clang -target riscv32-unknown-linux-gnu 
-menable-experimental-extensions \
-// RUN: -march=rv32izbproposedc0p93 -x c -E -dM %s \
-// RUN: -o - | FileCheck --check-prefix=CHECK-ZBPROPOSEDC-EXT %s
-// RUN: %clang -target riscv64-unknown-linux-gnu 
-menable-experimental-extensions \
-// RUN: -march=rv32izbproposedc0p93 -x c -E -dM %s \
-// RUN: -o - | FileCheck 

[PATCH] D106102: [analyzer][solver] Introduce reasoning for not equal to operator

[Manas Gupta via Phabricator via cfe-commits]

manas updated this revision to Diff 376363.
manas added a comment.

Fix typo


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106102

Files:
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  clang/test/Analysis/constant-folding.c

Index: clang/test/Analysis/constant-folding.c
===
--- clang/test/Analysis/constant-folding.c
+++ clang/test/Analysis/constant-folding.c
@@ -281,3 +281,49 @@
 clang_analyzer_eval((b % a) < x + 10); // expected-warning{{TRUE}}
   }
 }
+
+void testDisequalityRules(unsigned int u1, unsigned int u2, int s1, int s2) {
+  // Checks when ranges are not overlapping
+  if (u1 <= 10 && u2 >= 20) {
+// u1: [0,10], u2: [20,UINT_MAX]
+clang_analyzer_eval((u1 != u2) != 0); // expected-warning{{TRUE}}
+  }
+
+  if (s1 <= INT_MIN + 10 && s2 >= INT_MAX - 10) {
+// s1: [INT_MIN,INT_MIN + 10], s2: [INT_MAX - 10,INT_MAX]
+clang_analyzer_eval((s1 != s2) == 0); // expected-warning{{FALSE}}
+  }
+
+  // Checks when ranges are completely overlapping and have more than one point
+  if (u1 >= 20 && u1 <= 50 && u2 >= 20 && u2 <= 50) {
+// u1: [20,50], u2: [20,50]
+clang_analyzer_eval((u1 != u2) != 0); // expected-warning{{UNKNOWN}}
+  }
+
+  if (s1 >= -20 && s1 <= 20 && s2 >= -20 && s2 <= 20) {
+// s1: [-20,20], s2: [-20,20]
+clang_analyzer_eval((s1 != s2) != 0); // expected-warning{{UNKNOWN}}
+  }
+
+  // Checks when ranges are partially overlapping
+  if (u1 >= 100 && u1 <= 200 && u2 >= 150 && u2 <= 300) {
+// u1: [100,200], u2: [150,300]
+clang_analyzer_eval((u1 != u2) != 0); // expected-warning{{UNKNOWN}}
+  }
+
+  if (s1 >= -80 && s1 <= -50 && s2 >= -100 && s2 <= -75) {
+// s1: [-80,-50], s2: [-100,-75]
+clang_analyzer_eval((s1 != s2) == 0); // expected-warning{{UNKNOWN}}
+  }
+
+  // Checks for ranges which are subset of one-another
+  if (u1 >= 500 && u1 <= 1000 && u2 >= 750 && u2 <= 1000) {
+// u1: [500,1000], u2: [750,1000]
+clang_analyzer_eval((u1 != u2) == 0); // expected-warning{{UNKNOWN}}
+  }
+
+  if (s1 >= -1000 && s1 <= -500 && s2 <= -500 && s2 >= -750) {
+// s1: [-1000,-500], s2: [-500,-750]
+clang_analyzer_eval((s1 != s2) == 0); // expected-warning{{UNKNOWN}}
+  }
+}
Index: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -20,8 +20,8 @@
 #include "llvm/ADT/FoldingSet.h"
 #include "llvm/ADT/ImmutableSet.h"
 #include "llvm/ADT/STLExtras.h"
-#include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/SmallSet.h"
+#include "llvm/ADT/StringExtras.h"
 #include "llvm/Support/Compiler.h"
 #include "llvm/Support/raw_ostream.h"
 #include 
@@ -955,6 +955,8 @@
   RangeSet VisitBinaryOperator(RangeSet LHS, BinaryOperator::Opcode Op,
RangeSet RHS, QualType T) {
 switch (Op) {
+case BO_NE:
+  return VisitBinaryOperator(LHS, RHS, T);
 case BO_Or:
   return VisitBinaryOperator(LHS, RHS, T);
 case BO_And:
@@ -1024,6 +1026,27 @@
 return infer(T);
   }
 
+  template <>
+  RangeSet VisitBinaryOperator(RangeSet LHS, RangeSet RHS, QualType T) {
+// When both the RangeSets are non-overlapping then all possible pairs of
+// (x, y) in LHS, RHS respectively, will satisfy expression (x != y).
+if ((LHS.getMaxValue() < RHS.getMinValue()) ||
+(LHS.getMinValue() > RHS.getMaxValue())) {
+  return getTrueRange(T);
+}
+
+// If both RangeSets contain only one Point which is equal then the
+// expression will always return true.
+if ((LHS.getMinValue() == RHS.getMaxValue()) &&
+(LHS.getMaxValue() == RHS.getMaxValue()) &&
+(LHS.getMinValue() == RHS.getMinValue())) {
+  return getFalseRange(T);
+}
+
+// In all other cases, the resulting range cannot be deduced.
+return infer(T);
+  }
+
   /// Return a symmetrical range for the given range and type.
   ///
   /// If T is signed, return the smallest range [-x..x] that covers the original
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D110880: [msan] Remove StackTrace::tag

[Vitaly Buka via Phabricator via cfe-commits]

vitalybuka updated this revision to Diff 376351.
vitalybuka added a comment.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

documentation


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110880

Files:
  clang/docs/MemorySanitizer.rst
  compiler-rt/lib/msan/msan.cpp
  compiler-rt/lib/msan/msan.h
  compiler-rt/lib/msan/msan_allocator.cpp
  compiler-rt/lib/msan/msan_interceptors.cpp
  compiler-rt/lib/msan/msan_report.cpp
  compiler-rt/lib/sanitizer_common/sanitizer_stackdepot.cpp
  compiler-rt/lib/sanitizer_common/sanitizer_stacktrace.h
  compiler-rt/test/msan/chained_origin.cpp
  compiler-rt/test/msan/check_mem_is_initialized.cpp
  compiler-rt/test/msan/dso-origin.cpp
  compiler-rt/test/msan/heap-origin.cpp
  compiler-rt/test/msan/insertvalue_origin.cpp
  compiler-rt/test/msan/msan_copy_shadow.cpp
  compiler-rt/test/msan/msan_print_shadow.cpp
  compiler-rt/test/msan/origin-store-long.cpp
  compiler-rt/test/msan/realloc-large-origin.cpp
  compiler-rt/test/msan/realloc-origin.cpp
  compiler-rt/test/msan/select_float_origin.cpp
  compiler-rt/test/msan/use-after-dtor.cpp
  compiler-rt/test/msan/use-after-free.cpp
  compiler-rt/test/msan/wcsncpy.cpp

Index: compiler-rt/test/msan/wcsncpy.cpp
===
--- compiler-rt/test/msan/wcsncpy.cpp
+++ compiler-rt/test/msan/wcsncpy.cpp
@@ -35,6 +35,6 @@
 // CHECK:in {{[^\s]*}}wcsncpy
 // CHECK:in main {{.*}}wcsncpy.cpp:27
 
-// CHECK:  Memory was marked as uninitialized
+// CHECK:  Uninitialized value was created
 // CHECK:in __msan_allocated_memory
 // CHECK:in main {{.*}}wcsncpy.cpp:25
Index: compiler-rt/test/msan/use-after-free.cpp
===
--- compiler-rt/test/msan/use-after-free.cpp
+++ compiler-rt/test/msan/use-after-free.cpp
@@ -27,7 +27,7 @@
   // CHECK: WARNING: MemorySanitizer: use-of-uninitialized-value
   // CHECK: {{#0 0x.* in main .*use-after-free.cpp:}}[[@LINE-3]]
 
-  // CHECK-ORIGINS: Uninitialized value was created by a heap deallocation
+  // CHECK-ORIGINS: Uninitialized value was created
   // CHECK-ORIGINS: {{#0 0x.* in .*free}}
   // CHECK-ORIGINS: {{#1 0x.* in main .*use-after-free.cpp:}}[[@LINE-9]]
   return 0;
Index: compiler-rt/test/msan/use-after-dtor.cpp
===
--- compiler-rt/test/msan/use-after-dtor.cpp
+++ compiler-rt/test/msan/use-after-dtor.cpp
@@ -41,7 +41,7 @@
   // CHECK-UAD: WARNING: MemorySanitizer: use-of-uninitialized-value
   // CHECK-UAD: {{#0 0x.* in main.*use-after-dtor.cpp:}}[[@LINE-3]]
 
-  // CHECK-ORIGINS: Memory was marked as uninitialized
+  // CHECK-ORIGINS: Uninitialized value was created
   // CHECK-ORIGINS: {{#0 0x.* in __sanitizer_dtor_callback}}
   // CHECK-ORIGINS: {{#1 0x.* in .*~Simple}}
 
Index: compiler-rt/test/msan/select_float_origin.cpp
===
--- compiler-rt/test/msan/select_float_origin.cpp
+++ compiler-rt/test/msan/select_float_origin.cpp
@@ -17,7 +17,7 @@
   __msan_allocated_memory(, sizeof(y));
   float z = b ? x : y;
   if (z > 0) printf(".\n");
-  // CHECK: Memory was marked as uninitialized
+  // CHECK: Uninitialized value was created
   // CHECK: {{#0 0x.* in .*__msan_allocated_memory}}
   // CHECK: {{#1 0x.* in main .*select_float_origin.cpp:}}[[@LINE-6]]
   return 0;
Index: compiler-rt/test/msan/realloc-origin.cpp
===
--- compiler-rt/test/msan/realloc-origin.cpp
+++ compiler-rt/test/msan/realloc-origin.cpp
@@ -15,7 +15,7 @@
   // CHECK: WARNING: MemorySanitizer: use-of-uninitialized-value
   // CHECK: {{#0 0x.* in main .*realloc-origin.cpp:}}[[@LINE-2]]
 
-  // CHECK: Uninitialized value was created by a heap allocation
+  // CHECK: Uninitialized value was created
   // CHECK: {{#0 0x.* in .*realloc}}
   // CHECK: {{#1 0x.* in main .*realloc-origin.cpp:}}[[@LINE-9]]
 }
Index: compiler-rt/test/msan/realloc-large-origin.cpp
===
--- compiler-rt/test/msan/realloc-large-origin.cpp
+++ compiler-rt/test/msan/realloc-large-origin.cpp
@@ -25,7 +25,7 @@
 // CHECK-FULL-STACK:   {{#1 0x.* in main .*realloc-large-origin.cpp:}}[[@LINE-10]]
 // CHECK-SHORT-STACK:   {{#0 0x.* in .*realloc}}
 
-// CHECK:   Uninitialized value was created by a heap allocation
-// CHECK:   {{#0 0x.* in .*malloc}}
-// CHECK:   {{#1 0x.* in main .*realloc-large-origin.cpp:}}[[@LINE-16]]
+  // CHECK:   Uninitialized value was created
+  // CHECK:   {{#0 0x.* in .*malloc}}
+  // CHECK:   {{#1 0x.* in main .*realloc-large-origin.cpp:}}[[@LINE-16]]
 }
Index: compiler-rt/test/msan/origin-store-long.cpp
===
--- compiler-rt/test/msan/origin-store-long.cpp
+++ 

[PATCH] D98143: [HIP] Diagnose aggregate args containing half types

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

In D98143#3034419 , @tra wrote:

> Is this patch still relevant? Looks like I've missed it.
>
> What exactly is the difference between gcc and clang regarding fp16 and why 
> does it matter for aggregate arguments?
> On a trivial example both clang and gcc appear to treat _Float16 similarly: 
> https://godbolt.org/z/8WxK95zTj

On gcc11 and below, since gcc does not support fp16, it is common practice to 
use short to pass fp16 in struct. Then gcc and clang has different ABI: 
https://godbolt.org/z/zqhT7x7qo

Basically if one compiles a function with struct type arg containing _Float16 
with clang, then compiles a caller with struct type arg containing short with 
gcc, it will not work.

If use gcc trunk with _Float16, then there will not be such issue since the ABI 
is the same.


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

https://reviews.llvm.org/D98143

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

[clang] 2443320 - [AIX] Rename binder option for PGO support

[Jinsong Ji via cfe-commits]

Author: Jinsong Ji
Date: 2021-09-30T19:58:42Z
New Revision: 2443320d68387c83c9d13ffb5e5de44c2159125c

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

LOG: [AIX] Rename binder option for PGO support

Update the binder option.

Added: 


Modified: 
clang/lib/Driver/ToolChains/AIX.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/AIX.cpp 
b/clang/lib/Driver/ToolChains/AIX.cpp
index 5c82d6566497..053f6389dc0e 100644
--- a/clang/lib/Driver/ToolChains/AIX.cpp
+++ b/clang/lib/Driver/ToolChains/AIX.cpp
@@ -115,7 +115,7 @@ void aix::Linker::ConstructJob(Compilation , const 
JobAction ,
 options::OPT_fno_profile_generate, false) ||
Args.hasArg(options::OPT_fcreate_profile) ||
Args.hasArg(options::OPT_coverage)))
-CmdArgs.push_back("-bdbg:namedcsects");
+CmdArgs.push_back("-bdbg:namedsects");
 
   // Specify linker output file.
   assert((Output.isFilename() || Output.isNothing()) && "Invalid output.");



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

[PATCH] D110869: [X86] Implement -fzero-call-used-regs option

[Nick Desaulniers via Phabricator via cfe-commits]

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

We'll probably need to investigate code gen a little.

A mainline linux kernel defconfig built with `CONFIG_ZERO_CALL_USED_REGS=y` 
enabled doesn't boot, for example.  I consider that a blocker before landing 
this (much-appreciated) feature; marking it as such.  (Though it's possible 
that there are TUs in the kernel that may need to be built with 
`-fzero-call-used-regs=skip` that aren't (yet) failing with GCC).  I don't 
observe the kernel getting to `start_kernel`, which is the arch-agnostic entry 
point of the boot; so there's likely x86 specific C code invoked before the 
generic boot code takes over that may not play well with the instrumentation as 
implemented.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110869

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

[PATCH] D110276: Clean up large copies of binaries copied into temp directories in tests

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

In D110276#3032448 , @tejohnson wrote:

> In D110276#3031133 , @thakis wrote:
>
>> It's my personal bot. It doesn't send email. IMHO the problem of how to make 
>> bots send emails hasn't been solved (they either send too much or too 
>> little), so I'm not pretending that it has been ;)
>>
>> Sadly the test is still failing after the `-f` change: 
>> http://45.33.8.238/win/46139/step_7.txt
>>
>> Maybe tacking on an `|| true` helps?
>
> Added that in b55a964197bdc651533377bbd0b46fa58edf9196 
> . Let me 
> know if that fixes the issue.

I saw this failure every ~4 hours yesterday, but I haven't seen it once yet 
today. Fingers crossed, but it looks like that might have done the trick :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110276

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

[PATCH] D110668: [clang-cl] Accept `#pragma warning(disable : N)` for some N

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 added a comment.

Please next time give a bit more time to potential reviewers / other folks 
outside your org. The whole lifecycle of this patch (postee - landed) took < 
24h.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110668

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

[PATCH] D110833: [clang-format] Add ControlStatementsAndFunctionDefinitionsExceptControlMacros option to SpaceBeforeParens

[Björn Schäpers via Phabricator via cfe-commits]

HazardyKnusperkeks added a comment.

In D110833#3033849 , @MyDeveloperDay 
wrote:

> I feel this is going the way of BraceWrapping  in that it should be:
>
>   SpaceBeforeParens:
>  - BeforeMacro: false
>  - BeforeFunction: true

So replace the enum with a struct? Yeah I think that's the way. For what it is 
here proposed it seems that there needs to be a `BeforeFunctionDeclaration` and 
`BeforeFunctionDefinition`.

It should also make the code easier.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110833

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

[PATCH] D109902: [PowerPC] Improved codegen related to xscvdpsxws/xscvdpuxws

[Albion Fung 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 rG4195ed995993: [PowerPC] Improved codegen related to 
xscvdpsxws/xscvdpuxws (authored by Conanap).

Changed prior to commit:
  https://reviews.llvm.org/D109902?vs=375780=376327#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109902

Files:
  llvm/lib/Target/PowerPC/PPCInstrVSX.td
  llvm/test/CodeGen/PowerPC/test-vector-insert.ll
  llvm/test/CodeGen/PowerPC/vec_conv_fp64_to_i32_elts.ll

Index: llvm/test/CodeGen/PowerPC/vec_conv_fp64_to_i32_elts.ll
===
--- llvm/test/CodeGen/PowerPC/vec_conv_fp64_to_i32_elts.ll
+++ llvm/test/CodeGen/PowerPC/vec_conv_fp64_to_i32_elts.ll
@@ -13,12 +13,8 @@
 ; CHECK-P8-LABEL: test2elt:
 ; CHECK-P8:   # %bb.0: # %entry
 ; CHECK-P8-NEXT:xxswapd vs0, v2
-; CHECK-P8-NEXT:xscvdpuxws f1, v2
-; CHECK-P8-NEXT:xscvdpuxws f0, f0
-; CHECK-P8-NEXT:mffprwz r3, f1
-; CHECK-P8-NEXT:mtvsrwz v2, r3
-; CHECK-P8-NEXT:mffprwz r4, f0
-; CHECK-P8-NEXT:mtvsrwz v3, r4
+; CHECK-P8-NEXT:xscvdpuxws v2, v2
+; CHECK-P8-NEXT:xscvdpuxws v3, f0
 ; CHECK-P8-NEXT:vmrghw v2, v2, v3
 ; CHECK-P8-NEXT:xxswapd vs0, v2
 ; CHECK-P8-NEXT:mffprd r3, f0
@@ -26,26 +22,18 @@
 ;
 ; CHECK-P9-LABEL: test2elt:
 ; CHECK-P9:   # %bb.0: # %entry
-; CHECK-P9-NEXT:xscvdpuxws f0, v2
-; CHECK-P9-NEXT:mffprwz r3, f0
 ; CHECK-P9-NEXT:xxswapd vs0, v2
-; CHECK-P9-NEXT:mtvsrwz v3, r3
-; CHECK-P9-NEXT:xscvdpuxws f0, f0
-; CHECK-P9-NEXT:mffprwz r3, f0
-; CHECK-P9-NEXT:mtvsrwz v2, r3
+; CHECK-P9-NEXT:xscvdpuxws v3, v2
+; CHECK-P9-NEXT:xscvdpuxws v2, f0
 ; CHECK-P9-NEXT:vmrghw v2, v3, v2
 ; CHECK-P9-NEXT:mfvsrld r3, v2
 ; CHECK-P9-NEXT:blr
 ;
 ; CHECK-BE-LABEL: test2elt:
 ; CHECK-BE:   # %bb.0: # %entry
-; CHECK-BE-NEXT:xscvdpuxws f0, v2
-; CHECK-BE-NEXT:mffprwz r3, f0
 ; CHECK-BE-NEXT:xxswapd vs0, v2
-; CHECK-BE-NEXT:mtvsrwz v3, r3
-; CHECK-BE-NEXT:xscvdpuxws f0, f0
-; CHECK-BE-NEXT:mffprwz r3, f0
-; CHECK-BE-NEXT:mtvsrwz v2, r3
+; CHECK-BE-NEXT:xscvdpuxws v3, v2
+; CHECK-BE-NEXT:xscvdpuxws v2, f0
 ; CHECK-BE-NEXT:vmrgow v2, v3, v2
 ; CHECK-BE-NEXT:mfvsrd r3, v2
 ; CHECK-BE-NEXT:blr
@@ -305,12 +293,8 @@
 ; CHECK-P8-LABEL: test2elt_signed:
 ; CHECK-P8:   # %bb.0: # %entry
 ; CHECK-P8-NEXT:xxswapd vs0, v2
-; CHECK-P8-NEXT:xscvdpsxws f1, v2
-; CHECK-P8-NEXT:xscvdpsxws f0, f0
-; CHECK-P8-NEXT:mffprwz r3, f1
-; CHECK-P8-NEXT:mtvsrwz v2, r3
-; CHECK-P8-NEXT:mffprwz r4, f0
-; CHECK-P8-NEXT:mtvsrwz v3, r4
+; CHECK-P8-NEXT:xscvdpsxws v2, v2
+; CHECK-P8-NEXT:xscvdpsxws v3, f0
 ; CHECK-P8-NEXT:vmrghw v2, v2, v3
 ; CHECK-P8-NEXT:xxswapd vs0, v2
 ; CHECK-P8-NEXT:mffprd r3, f0
@@ -318,26 +302,18 @@
 ;
 ; CHECK-P9-LABEL: test2elt_signed:
 ; CHECK-P9:   # %bb.0: # %entry
-; CHECK-P9-NEXT:xscvdpsxws f0, v2
-; CHECK-P9-NEXT:mffprwz r3, f0
 ; CHECK-P9-NEXT:xxswapd vs0, v2
-; CHECK-P9-NEXT:mtvsrwz v3, r3
-; CHECK-P9-NEXT:xscvdpsxws f0, f0
-; CHECK-P9-NEXT:mffprwz r3, f0
-; CHECK-P9-NEXT:mtvsrwz v2, r3
+; CHECK-P9-NEXT:xscvdpsxws v3, v2
+; CHECK-P9-NEXT:xscvdpsxws v2, f0
 ; CHECK-P9-NEXT:vmrghw v2, v3, v2
 ; CHECK-P9-NEXT:mfvsrld r3, v2
 ; CHECK-P9-NEXT:blr
 ;
 ; CHECK-BE-LABEL: test2elt_signed:
 ; CHECK-BE:   # %bb.0: # %entry
-; CHECK-BE-NEXT:xscvdpsxws f0, v2
-; CHECK-BE-NEXT:mffprwz r3, f0
 ; CHECK-BE-NEXT:xxswapd vs0, v2
-; CHECK-BE-NEXT:mtvsrwz v3, r3
-; CHECK-BE-NEXT:xscvdpsxws f0, f0
-; CHECK-BE-NEXT:mffprwz r3, f0
-; CHECK-BE-NEXT:mtvsrwz v2, r3
+; CHECK-BE-NEXT:xscvdpsxws v3, v2
+; CHECK-BE-NEXT:xscvdpsxws v2, f0
 ; CHECK-BE-NEXT:vmrgow v2, v3, v2
 ; CHECK-BE-NEXT:mfvsrd r3, v2
 ; CHECK-BE-NEXT:blr
Index: llvm/test/CodeGen/PowerPC/test-vector-insert.ll
===
--- llvm/test/CodeGen/PowerPC/test-vector-insert.ll
+++ llvm/test/CodeGen/PowerPC/test-vector-insert.ll
@@ -17,8 +17,8 @@
 ; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu \
 ; RUN:  -ppc-asm-full-reg-names -ppc-vsr-nums-as-vr \
 ; RUN:  -mcpu=pwr9 < %s | FileCheck %s --check-prefix=CHECK-BE-P9
-; xscvdpsxws and uxws is only available on Power7 and above
-; Codgen is different for LE Power7 and Power8
+; xscvdpsxws and xscvdpsxws is only available on Power7 and above
+; Codgen is different for Power7, Power8, and Power9.
 
 define dso_local <4 x i32> @test(<4 x i32> %a, double %b) {
 ; CHECK-LE-P7-LABEL: test:
@@ -38,20 +38,16 @@
 ;
 ; CHECK-LE-P8-LABEL: test:
 ; CHECK-LE-P8:   # %bb.0: # %entry
-; CHECK-LE-P8-NEXT:xscvdpsxws f0, f1
+; CHECK-LE-P8-NEXT:xscvdpsxws v3, f1
 ; CHECK-LE-P8-NEXT:addis r3, 

[PATCH] D110869: [X86] Implement -fzero-call-used-regs option

[Nick Desaulniers via Phabricator via cfe-commits]

nickdesaulniers added inline comments.



Comment at: clang/include/clang/Basic/AttrDocs.td:6108
+  let Content = [{
+This attribute, when attached to a funcditon, causes the compiler to zero a
+subset of all call-used registers before the function returns. It's used to

s/funcditon/function/

`:set spell` in vim.



Comment at: clang/include/clang/Basic/AttrDocs.td:6116
+
+- ``skip`` doesn't zero any call-used registers.
+- ``used`` only zeros call-used registers used in the function. By ``used``, we

Might be worth a note that `skip` is helpful for disabling previously occurring 
instances of the command line flag.  Sometimes toolchains have wrapper scripts 
that force on flags, or are built with the implicit default changed, so being 
able to explicitly disable a feature can be helpful.



Comment at: clang/lib/CodeGen/CGCall.cpp:2207
+  "zero-call-used-regs",
+  ZeroCallUsedRegsAttr::ConvertZeroCallUsedRegsKindToStr(Kind));
+}

The method name has some duplicate information. Perhaps `KindToStr` would be 
more concise?



Comment at: clang/lib/Sema/SemaDeclAttr.cpp:7584
+
+  ZeroCallUsedRegsAttr::ZeroCallUsedRegsKind kind;
+  if (!ZeroCallUsedRegsAttr::ConvertStrToZeroCallUsedRegsKind(KindStr, kind)) {

capital K `Kind`?



Comment at: clang/test/CodeGen/zero-call-used-regs.c:219
+
+#define __zero_call_used_regs(...) 
__attribute__((zero_call_used_regs(__VA_ARGS__)))
+

I don't think any of the expansion sites use a variable number of parameters, 
or more than one?



Comment at: clang/test/Sema/zero_call_used_regs.c:6
+void failure() _zero_call_used_regs();   // expected-error 
{{takes one argument}}
+void failure() _zero_call_used_regs("used", "used-gpr"); // expected-error 
{{takes one argument}}
+void failure() _zero_call_used_regs(0);  // expected-error 
{{requires a string}}

How about a test for:

```
void failure 
__attribute__((zero_call_used_reg("used"),zero_call_used_reg("used-gpr")));
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110869

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

[PATCH] D110871: [RISCV] Remove rvbproposedc extension

[Craig Topper via Phabricator via cfe-commits]

craig.topper created this revision.
craig.topper added reviewers: asb, luismarques, evandro, HsiangKai, 
frasercrmck, jrtc27, PaoloS, kito-cheng, khchen, arcbbb.
Herald added subscribers: achieveartificialintelligence, StephenFan, vkmr, 
jdoerfert, apazos, sameer.abuasal, s.egerton, Jim, benna, psnobl, jocewei, 
PkmX, the_o, brucehoult, MartinMosbeck, rogfer01, edward-jones, zzheng, 
shiva0217, niosHD, sabuasal, simoncook, johnrusso, rbar, hiraditya.
craig.topper requested review of this revision.
Herald added a subscriber: MaskRay.
Herald added a project: LLVM.

This consists of 3 compressed instructions, c.not, c.neg, and c.zext.w. I 
believe these have been picked up by the Zce effort using different encodings. 
I don't think it makes sense to keep them in bitmanip. It will eventually cause 
a conflict if/when Zce is implemented in llvm.


https://reviews.llvm.org/D110871

Files:
  clang/lib/Basic/Targets/RISCV.cpp
  clang/lib/Basic/Targets/RISCV.h
  clang/lib/Driver/ToolChains/Arch/RISCV.cpp
  clang/test/Preprocessor/riscv-target-features.c
  llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
  llvm/lib/Target/RISCV/Disassembler/RISCVDisassembler.cpp
  llvm/lib/Target/RISCV/MCTargetDesc/RISCVTargetStreamer.cpp
  llvm/lib/Target/RISCV/RISCV.td
  llvm/lib/Target/RISCV/RISCVInstrInfoB.td
  llvm/lib/Target/RISCV/RISCVSubtarget.h
  llvm/test/CodeGen/RISCV/attributes.ll
  llvm/test/MC/RISCV/attribute-arch.s
  llvm/test/MC/RISCV/compress-rv32b.s
  llvm/test/MC/RISCV/compress-rv64b.s
  llvm/test/MC/RISCV/rv32zbproposedc-invalid.s
  llvm/test/MC/RISCV/rv32zbproposedc-valid.s
  llvm/test/MC/RISCV/rv64zbproposedc-invalid.s
  llvm/test/MC/RISCV/rv64zbproposedc-valid.s

Index: llvm/test/MC/RISCV/rv64zbproposedc-valid.s
===
--- llvm/test/MC/RISCV/rv64zbproposedc-valid.s
+++ /dev/null
@@ -1,10 +0,0 @@
-# RUN: llvm-mc %s -triple=riscv64 -mattr=+c,+experimental-zbproposedc,+experimental-b -riscv-no-aliases -show-encoding \
-# RUN: | FileCheck -check-prefixes=CHECK-ASM,CHECK-ASM-AND-OBJ %s
-# RUN: llvm-mc -filetype=obj -triple=riscv64 -mattr=+c,+experimental-zbproposedc,+experimental-b < %s \
-# RUN: | llvm-objdump --mattr=+c,+experimental-zbproposedc,+experimental-b -M no-aliases -d -r - \
-# RUN: | FileCheck --check-prefix=CHECK-ASM-AND-OBJ %s
-
-
-# CHECK-ASM-AND-OBJ: c.zext.w s0
-# CHECK-ASM: encoding: [0x01,0x68]
-c.zext.w s0
Index: llvm/test/MC/RISCV/rv64zbproposedc-invalid.s
===
--- llvm/test/MC/RISCV/rv64zbproposedc-invalid.s
+++ /dev/null
@@ -1,4 +0,0 @@
-# RUN: not llvm-mc -triple riscv64 -mattr=+c,+experimental-zbproposedc,+experimental-b < %s 2>&1 | FileCheck %s
-
-# Too many operands
-c.zext.w s0, s1 # CHECK: :[[@LINE]]:14: error: invalid operand for instruction
Index: llvm/test/MC/RISCV/rv32zbproposedc-valid.s
===
--- llvm/test/MC/RISCV/rv32zbproposedc-valid.s
+++ /dev/null
@@ -1,17 +0,0 @@
-# RUN: llvm-mc %s -triple=riscv32 -mattr=+c,+experimental-zbproposedc -riscv-no-aliases -show-encoding \
-# RUN: | FileCheck -check-prefixes=CHECK-ASM,CHECK-ASM-AND-OBJ %s
-# RUN: llvm-mc %s -triple=riscv64 -mattr=+c,+experimental-zbproposedc,+experimental-b -riscv-no-aliases -show-encoding \
-# RUN: | FileCheck -check-prefixes=CHECK-ASM,CHECK-ASM-AND-OBJ %s
-# RUN: llvm-mc -filetype=obj -triple=riscv32 -mattr=+c,+experimental-zbproposedc < %s \
-# RUN: | llvm-objdump --mattr=+c,+experimental-zbproposedc -M no-aliases -d -r - \
-# RUN: | FileCheck --check-prefix=CHECK-ASM-AND-OBJ %s
-# RUN: llvm-mc -filetype=obj -triple=riscv64 -mattr=+c,+experimental-zbproposedc,+experimental-b < %s \
-# RUN: | llvm-objdump --mattr=+c,+experimental-zbproposedc,+experimental-b -M no-aliases -d -r - \
-# RUN: | FileCheck --check-prefix=CHECK-ASM-AND-OBJ %s
-
-# CHECK-ASM-AND-OBJ: c.not s0
-# CHECK-ASM: encoding: [0x01,0x60]
-c.not s0
-# CHECK-ASM-AND-OBJ: c.neg s0
-# CHECK-ASM: encoding: [0x01,0x64]
-c.neg s0
Index: llvm/test/MC/RISCV/rv32zbproposedc-invalid.s
===
--- llvm/test/MC/RISCV/rv32zbproposedc-invalid.s
+++ /dev/null
@@ -1,6 +0,0 @@
-# RUN: not llvm-mc -triple riscv32 -mattr=+c,+experimental-zbproposedc,+experimental-Zba < %s 2>&1 | FileCheck %s
-
-# Too many operands
-c.not s0, s1 # CHECK: :[[@LINE]]:11: error: invalid operand for instruction
-c.neg s0, s1 # CHECK: :[[@LINE]]:11: error: invalid operand for instruction
-c.zext.w s0 # CHECK: :[[@LINE]]:1: error: instruction requires the following: RV64I Base Instruction Set
Index: llvm/test/MC/RISCV/compress-rv64b.s
===
--- llvm/test/MC/RISCV/compress-rv64b.s
+++ /dev/null
@@ -1,18 +0,0 @@
-# RUN: llvm-mc -triple riscv64 -mattr=+c,+experimental-zbproposedc,+experimental-b -show-encoding < %s \
-# RUN:   | FileCheck 

[clang] e31899c - Reland "[clang-cl] Accept `#pragma warning(disable : N)` for some N"

[Nico Weber via cfe-commits]

Author: Nico Weber
Date: 2021-09-30T15:03:23-04:00
New Revision: e31899c7080f93c3d86b492af5f6bc9c3a1d1105

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

LOG: Reland "[clang-cl] Accept `#pragma warning(disable : N)` for some N"

This reverts commit 0cd9d8a48bdddb17de2c6388f9d775353f9acab9 and
adds the changes described in https://reviews.llvm.org/D110668#3034461.

Added: 
clang/include/clang/Basic/CLWarnings.h
clang/lib/Basic/CLWarnings.cpp
clang/test/Sema/pragma-warning.cpp

Modified: 
clang/include/clang/Basic/Diagnostic.h
clang/include/clang/Basic/DiagnosticCategories.h
clang/include/clang/Basic/DiagnosticGroups.td
clang/include/clang/Basic/DiagnosticIDs.h
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/include/clang/Driver/Options.td
clang/lib/Basic/CMakeLists.txt
clang/lib/Basic/Diagnostic.cpp
clang/lib/Basic/DiagnosticIDs.cpp
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Lex/Pragma.cpp
clang/test/Driver/cl-options.c
clang/tools/diagtool/DiagnosticNames.cpp
clang/utils/TableGen/ClangDiagnosticsEmitter.cpp
llvm/utils/gn/secondary/clang/lib/Basic/BUILD.gn

Removed: 




diff  --git a/clang/include/clang/Basic/CLWarnings.h 
b/clang/include/clang/Basic/CLWarnings.h
new file mode 100644
index 0..e3351f430c437
--- /dev/null
+++ b/clang/include/clang/Basic/CLWarnings.h
@@ -0,0 +1,26 @@
+//===--- CLWarnings.h - Maps some cl.exe warning ids  ---*- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLVM_CLANG_BASIC_CLWARNINGS_H
+#define LLVM_CLANG_BASIC_CLWARNINGS_H
+
+#include "llvm/ADT/Optional.h"
+
+namespace clang {
+
+namespace diag {
+enum class Group;
+}
+
+/// For cl.exe warning IDs that cleany map to clang diagnostic groups,
+/// returns the corresponding group. Else, returns an empty Optional.
+llvm::Optional diagGroupFromCLWarningID(unsigned);
+
+} // end namespace clang
+
+#endif // LLVM_CLANG_BASIC_CLWARNINGS_H

diff  --git a/clang/include/clang/Basic/Diagnostic.h 
b/clang/include/clang/Basic/Diagnostic.h
index 3b915fb15a891..efb725845d3e8 100644
--- a/clang/include/clang/Basic/Diagnostic.h
+++ b/clang/include/clang/Basic/Diagnostic.h
@@ -807,6 +807,9 @@ class DiagnosticsEngine : public 
RefCountedBase {
   bool setSeverityForGroup(diag::Flavor Flavor, StringRef Group,
diag::Severity Map,
SourceLocation Loc = SourceLocation());
+  bool setSeverityForGroup(diag::Flavor Flavor, diag::Group Group,
+   diag::Severity Map,
+   SourceLocation Loc = SourceLocation());
 
   /// Set the warning-as-error flag for the given diagnostic group.
   ///

diff  --git a/clang/include/clang/Basic/DiagnosticCategories.h 
b/clang/include/clang/Basic/DiagnosticCategories.h
index 0decf15080a0c..2bbdeb31a7b7d 100644
--- a/clang/include/clang/Basic/DiagnosticCategories.h
+++ b/clang/include/clang/Basic/DiagnosticCategories.h
@@ -19,6 +19,13 @@ namespace clang {
 #undef GET_CATEGORY_TABLE
   DiagCat_NUM_CATEGORIES
 };
+
+enum class Group {
+#define DIAG_ENTRY(GroupName, FlagNameOffset, Members, SubGroups) GroupName,
+#include "clang/Basic/DiagnosticGroups.inc"
+#undef CATEGORY
+#undef DIAG_ENTRY
+};
   }  // end namespace diag
 }  // end namespace clang
 

diff  --git a/clang/include/clang/Basic/DiagnosticGroups.td 
b/clang/include/clang/Basic/DiagnosticGroups.td
index 23e9144ea0084..761b323d06166 100644
--- a/clang/include/clang/Basic/DiagnosticGroups.td
+++ b/clang/include/clang/Basic/DiagnosticGroups.td
@@ -396,6 +396,7 @@ def Dangling : DiagGroup<"dangling", [DanglingField,
   DanglingGsl,
   ReturnStackAddress]>;
 def DistributedObjectModifiers : DiagGroup<"distributed-object-modifiers">;
+def DllexportExplicitInstantiationDecl : 
DiagGroup<"dllexport-explicit-instantiation-decl">;
 def ExcessInitializers : DiagGroup<"excess-initializers">;
 def ExpansionToDefined : DiagGroup<"expansion-to-defined">;
 def FlagEnum : DiagGroup<"flag-enum">;

diff  --git a/clang/include/clang/Basic/DiagnosticIDs.h 
b/clang/include/clang/Basic/DiagnosticIDs.h
index 288504def5ebf..aef86516707c6 100644
--- a/clang/include/clang/Basic/DiagnosticIDs.h
+++ b/clang/include/clang/Basic/DiagnosticIDs.h
@@ -25,6 +25,8 @@ namespace clang {
 
   // Import the diagnostic enums themselves.
   namespace diag {
+enum class Group;
+
 // Size of each of the diagnostic 

[PATCH] D110668: [clang-cl] Accept `#pragma warning(disable : N)` for some N

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

Thanks for the revert. The problem was that this `continue` was in the wrong 
spot:

  diff --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
  index 9450e8b154c5..369c12aea523 100644
  --- a/clang/lib/Driver/ToolChains/Clang.cpp
  +++ b/clang/lib/Driver/ToolChains/Clang.cpp
  @@ -5453,8 +5453,8 @@ void Clang::ConstructJob(Compilation , const 
JobAction ,
 if (auto Group = diagGroupFromCLWarningID(WarningNumber)) {
   CmdArgs.push_back(Args.MakeArgString(
   "-Wno-" + DiagnosticIDs::getWarningOptionForGroup(*Group)));
  -continue;
 }
  +  continue;
   }
   A->render(Args, CmdArgs);
 }

The tests didn't catch this because they pass `-###`. In the reland I'm 
including the following additional test that will catch this at test time (it 
checks we don't pass wd flags with an unknown number through unchanged to cc1):

  diff --git a/clang/test/Driver/cl-options.c b/clang/test/Driver/cl-options.c
  index 74dd68753a1f..618be2d230f9 100644
  --- a/clang/test/Driver/cl-options.c
  +++ b/clang/test/Driver/cl-options.c
  @@ -359,6 +359,7 @@
   // Wno: "-Wno-unused-parameter"
   // Wno: "-Wno-dllexport-explicit-instantiation-decl"
   // Wno: "-Wno-deprecated-declarations"
  +// Wno-NOT: "-wd
   
   // Ignored options. Check that we don't get "unused during compilation" 
errors.
   // RUN: %clang_cl /c \


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110668

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

[PATCH] D110824: [PowerPC] Fix to guard fetch and cas 64-bit builtin versions

[Kamau Bridgeman via Phabricator via cfe-commits]

kamaub updated this revision to Diff 376312.
kamaub added a comment.

Rebasing patch to get past intermittent test-suite failure


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110824

Files:
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/builtins-ppc-xlcompat-fetch-cas-64bit-only-error.c


Index: clang/test/CodeGen/builtins-ppc-xlcompat-fetch-cas-64bit-only-error.c
===
--- /dev/null
+++ clang/test/CodeGen/builtins-ppc-xlcompat-fetch-cas-64bit-only-error.c
@@ -0,0 +1,24 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// REQUIRES: powerpc-registered-target
+// RUN: %clang_cc1 -triple powerpc-unknown-aix -target-cpu pwr8 \
+// RUN:  -verify %s
+
+int test_builtin_ppc_compare_and_swaplp(long a, long b, long c) {
+  return __compare_and_swaplp(, , c); // expected-error {{this builtin is 
only available on 64-bit targets}}
+}
+
+void test_builtin_ppc_fetch_and_addlp(long a, long b) {
+  __fetch_and_addlp(, b); // expected-error {{this builtin is only available 
on 64-bit targets}}
+}
+
+void test_builtin_ppc_fetch_and_andlp(unsigned long a, unsigned long b) {
+  __fetch_and_andlp(, b); // expected-error {{this builtin is only available 
on 64-bit targets}}
+}
+void test_builtin_ppc_fetch_and_orlp(unsigned long a, unsigned long b) {
+  __fetch_and_orlp(, b); // expected-error {{this builtin is only available 
on 64-bit targets}}
+}
+
+void test_builtin_ppc_fetch_and_swaplp(unsigned long a, unsigned long b) {
+  __fetch_and_swaplp(, b); // expected-error {{this builtin is only 
available on 64-bit targets}}
+}
+
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -3297,6 +3297,11 @@
   case PPC::BI__builtin_ppc_addex:
   case PPC::BI__builtin_darn:
   case PPC::BI__builtin_darn_raw:
+  case PPC::BI__builtin_ppc_compare_and_swaplp:
+  case PPC::BI__builtin_ppc_fetch_and_addlp:
+  case PPC::BI__builtin_ppc_fetch_and_andlp:
+  case PPC::BI__builtin_ppc_fetch_and_orlp:
+  case PPC::BI__builtin_ppc_fetch_and_swaplp:
 return true;
   }
   return false;


Index: clang/test/CodeGen/builtins-ppc-xlcompat-fetch-cas-64bit-only-error.c
===
--- /dev/null
+++ clang/test/CodeGen/builtins-ppc-xlcompat-fetch-cas-64bit-only-error.c
@@ -0,0 +1,24 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// REQUIRES: powerpc-registered-target
+// RUN: %clang_cc1 -triple powerpc-unknown-aix -target-cpu pwr8 \
+// RUN:  -verify %s
+
+int test_builtin_ppc_compare_and_swaplp(long a, long b, long c) {
+  return __compare_and_swaplp(, , c); // expected-error {{this builtin is only available on 64-bit targets}}
+}
+
+void test_builtin_ppc_fetch_and_addlp(long a, long b) {
+  __fetch_and_addlp(, b); // expected-error {{this builtin is only available on 64-bit targets}}
+}
+
+void test_builtin_ppc_fetch_and_andlp(unsigned long a, unsigned long b) {
+  __fetch_and_andlp(, b); // expected-error {{this builtin is only available on 64-bit targets}}
+}
+void test_builtin_ppc_fetch_and_orlp(unsigned long a, unsigned long b) {
+  __fetch_and_orlp(, b); // expected-error {{this builtin is only available on 64-bit targets}}
+}
+
+void test_builtin_ppc_fetch_and_swaplp(unsigned long a, unsigned long b) {
+  __fetch_and_swaplp(, b); // expected-error {{this builtin is only available on 64-bit targets}}
+}
+
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -3297,6 +3297,11 @@
   case PPC::BI__builtin_ppc_addex:
   case PPC::BI__builtin_darn:
   case PPC::BI__builtin_darn_raw:
+  case PPC::BI__builtin_ppc_compare_and_swaplp:
+  case PPC::BI__builtin_ppc_fetch_and_addlp:
+  case PPC::BI__builtin_ppc_fetch_and_andlp:
+  case PPC::BI__builtin_ppc_fetch_and_orlp:
+  case PPC::BI__builtin_ppc_fetch_and_swaplp:
 return true;
   }
   return false;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98143: [HIP] Diagnose aggregate args containing half types

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

Is this patch still relevant? Looks like I've missed it.

What exactly is the difference between gcc and clang regarding fp16 and why 
does it matter for aggregate arguments?
On a trivial example both clang and gcc appear to treat _Float16 similarly: 
https://godbolt.org/z/8WxK95zTj


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

https://reviews.llvm.org/D98143

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

[PATCH] D110869: [X86] Implement -fzero-call-used-regs option

[Bill Wendling via Phabricator via cfe-commits]

void added a comment.

The way I select the registers to zero out seems rather fragile. Is there a 
nicer way to do this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110869

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

[PATCH] D110869: [X86] Implement -fzero-call-used-regs option

[Bill Wendling via Phabricator via cfe-commits]

void created this revision.
void added reviewers: kees, nickdesaulniers, jyknight.
Herald added subscribers: dexonsmith, dang, jdoerfert, pengfei, hiraditya.
Herald added a reviewer: aaron.ballman.
void requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

The "-fzero-call-used-regs" option tells the compiler to zero out
certain registers before the function returns. It's also available as a
function attribute: zero_call_used_regs.

The two upper categories are:

- "used": Zero out used registers.
- "all": Zero out all registers, whether used or not.

The individual options are:

- "skip": Don't zero out any registers. This is the default.
- "used": Zero out all used registers.
- "used-arg": Zero out used registers that are used for arguments.
- "used-gpr": Zero out used registers that are GPRs.
- "used-gpr-arg": Zero out used GPRs that are used as arguments.
- "all": Zero out all registers.
- "all-arg": Zero out all registers used for arguments.
- "all-gpr": Zero out all GPRs.
- "all-gpr-arg": Zero out all GPRs used for arguments.

This is used to help mitigate Return-Oriented Programming exploits.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D110869

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/CodeGen/zero-call-used-regs.c
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  clang/test/Sema/zero_call_used_regs.c
  llvm/include/llvm/Support/CodeGen.h
  llvm/lib/Target/X86/X86FrameLowering.cpp
  llvm/lib/Target/X86/X86FrameLowering.h
  llvm/lib/Target/X86/X86RegisterInfo.cpp
  llvm/lib/Target/X86/X86RegisterInfo.h
  llvm/test/CodeGen/X86/zero-call-used-regs-all-arg.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-all-gpr-arg.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-all-gpr.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-all.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-fmod.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-skip.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-smoke-tests.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-used-arg.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-used-gpr-arg.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-used-gpr.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-used.ll

Index: llvm/test/CodeGen/X86/zero-call-used-regs-used.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/zero-call-used-regs-used.ll
@@ -0,0 +1,28 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc < %s -mtriple=x86_64-unknown-linux-gnu | FileCheck %s
+
+@result = dso_local global i32 0, align 4
+
+define dso_local i32 @foo(i32 returned %x) local_unnamed_addr #0 {
+; CHECK-LABEL: foo:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:movl %edi, %eax
+; CHECK-NEXT:xorl %edi, %edi
+; CHECK-NEXT:retq
+entry:
+  ret i32 %x
+}
+
+define dso_local i32 @main() local_unnamed_addr #1 {
+; CHECK-LABEL: main:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:movl $2, result(%rip)
+; CHECK-NEXT:xorl %eax, %eax
+; CHECK-NEXT:retq
+entry:
+  store volatile i32 2, i32* @result, align 4
+  ret i32 0
+}
+
+attributes #0 = { mustprogress nofree norecurse nosync nounwind readnone uwtable willreturn "frame-pointer"="none" "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" "zero-call-used-regs"="used" }
+attributes #1 = { nofree norecurse nounwind uwtable "frame-pointer"="none" "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" "zero-call-used-regs"="used" }
Index: llvm/test/CodeGen/X86/zero-call-used-regs-used-gpr.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/zero-call-used-regs-used-gpr.ll
@@ -0,0 +1,28 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc < %s -mtriple=x86_64-unknown-linux-gnu | FileCheck %s
+
+@result = dso_local global i32 0, align 4
+
+define dso_local i32 @foo(i32 returned %x) local_unnamed_addr #0 {
+; CHECK-LABEL: foo:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:movl %edi, %eax
+; CHECK-NEXT:xorl %edi, %edi
+; CHECK-NEXT:retq
+entry:
+  ret i32 %x
+}
+
+define dso_local i32 @main() local_unnamed_addr #1 {
+; CHECK-LABEL: main:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:movl $2, result(%rip)
+; CHECK-NEXT:xorl %eax, %eax
+; CHECK-NEXT:retq
+entry:
+  store volatile i32 2, i32* @result, align 4
+  ret i32 0
+}
+
+attributes #0 = { 

[PATCH] D110673: [clang] Don't modify OptRemark if the argument is not relevant

[Arthur Eubanks 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 rG76902079e429: [clang] Dont modify OptRemark if the 
argument is not relevant (authored by aeubanks).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110673

Files:
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/Frontend/optimization-remark.c


Index: clang/test/Frontend/optimization-remark.c
===
--- clang/test/Frontend/optimization-remark.c
+++ clang/test/Frontend/optimization-remark.c
@@ -16,6 +16,7 @@
 // RUN: %clang_cc1 %s -Rpass=inline -Rno-pass -emit-llvm -o - 2>&1 | FileCheck 
%s --check-prefix=CHECK-NO-REMARKS
 // RUN: %clang_cc1 %s -Rpass=inline -Rno-everything -emit-llvm -o - 2>&1 | 
FileCheck %s --check-prefix=CHECK-NO-REMARKS
 // RUN: %clang_cc1 %s -Rpass=inline -fno-experimental-new-pass-manager 
-Rno-everything -Reverything -emit-llvm -o - 2>&1 | FileCheck %s 
--check-prefix=CHECK-REMARKS
+// RUN: %clang_cc1 %s -Rpass -Rno-pass -round-trip-args 
-fexperimental-new-pass-manager -mllvm -mandatory-inlining-first=false -O1 
-emit-llvm -o - 2>&1 | FileCheck %s --check-prefix=CHECK-NO-REMARKS
 //
 // The inliner for the new PM does not seem to be enabled at O0, but we still
 // get the same remarks with at least O1.
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -1201,6 +1201,8 @@
 Result.Kind = CodeGenOptions::RK_Disabled;
   else if (Value == "no-everything")
 Result.Kind = CodeGenOptions::RK_DisabledEverything;
+  else
+continue;
 
   if (Result.Kind == CodeGenOptions::RK_Disabled ||
   Result.Kind == CodeGenOptions::RK_DisabledEverything) {


Index: clang/test/Frontend/optimization-remark.c
===
--- clang/test/Frontend/optimization-remark.c
+++ clang/test/Frontend/optimization-remark.c
@@ -16,6 +16,7 @@
 // RUN: %clang_cc1 %s -Rpass=inline -Rno-pass -emit-llvm -o - 2>&1 | FileCheck %s --check-prefix=CHECK-NO-REMARKS
 // RUN: %clang_cc1 %s -Rpass=inline -Rno-everything -emit-llvm -o - 2>&1 | FileCheck %s --check-prefix=CHECK-NO-REMARKS
 // RUN: %clang_cc1 %s -Rpass=inline -fno-experimental-new-pass-manager -Rno-everything -Reverything -emit-llvm -o - 2>&1 | FileCheck %s --check-prefix=CHECK-REMARKS
+// RUN: %clang_cc1 %s -Rpass -Rno-pass -round-trip-args -fexperimental-new-pass-manager -mllvm -mandatory-inlining-first=false -O1 -emit-llvm -o - 2>&1 | FileCheck %s --check-prefix=CHECK-NO-REMARKS
 //
 // The inliner for the new PM does not seem to be enabled at O0, but we still
 // get the same remarks with at least O1.
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -1201,6 +1201,8 @@
 Result.Kind = CodeGenOptions::RK_Disabled;
   else if (Value == "no-everything")
 Result.Kind = CodeGenOptions::RK_DisabledEverything;
+  else
+continue;
 
   if (Result.Kind == CodeGenOptions::RK_Disabled ||
   Result.Kind == CodeGenOptions::RK_DisabledEverything) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 7690207 - [clang] Don't modify OptRemark if the argument is not relevant

[Arthur Eubanks via cfe-commits]

Author: Arthur Eubanks
Date: 2021-09-30T11:36:30-07:00
New Revision: 76902079e42958118f01b4550d68a9b54c9e8e7e

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

LOG: [clang] Don't modify OptRemark if the argument is not relevant

A followup to D110201.

 For example, we'd set OptimizationRemarkMissed's Regex to '.*' when
encountering -Rpass. Normally this doesn't actually affect remarks we
emit because in clang::ProcessWarningOptions() we'll separately look at
all -R arguments and turn on/off corresponding diagnostic groups.
However, this is reproducible with -round-trip-args.

Reviewed By: JamesNagurne

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

Added: 


Modified: 
clang/lib/Frontend/CompilerInvocation.cpp
clang/test/Frontend/optimization-remark.c

Removed: 




diff  --git a/clang/lib/Frontend/CompilerInvocation.cpp 
b/clang/lib/Frontend/CompilerInvocation.cpp
index 30a80d38bf205..e9eed36f36a96 100644
--- a/clang/lib/Frontend/CompilerInvocation.cpp
+++ b/clang/lib/Frontend/CompilerInvocation.cpp
@@ -1201,6 +1201,8 @@ ParseOptimizationRemark(DiagnosticsEngine , ArgList 
,
 Result.Kind = CodeGenOptions::RK_Disabled;
   else if (Value == "no-everything")
 Result.Kind = CodeGenOptions::RK_DisabledEverything;
+  else
+continue;
 
   if (Result.Kind == CodeGenOptions::RK_Disabled ||
   Result.Kind == CodeGenOptions::RK_DisabledEverything) {

diff  --git a/clang/test/Frontend/optimization-remark.c 
b/clang/test/Frontend/optimization-remark.c
index d4cab0bdec0cb..950980e397787 100644
--- a/clang/test/Frontend/optimization-remark.c
+++ b/clang/test/Frontend/optimization-remark.c
@@ -16,6 +16,7 @@
 // RUN: %clang_cc1 %s -Rpass=inline -Rno-pass -emit-llvm -o - 2>&1 | FileCheck 
%s --check-prefix=CHECK-NO-REMARKS
 // RUN: %clang_cc1 %s -Rpass=inline -Rno-everything -emit-llvm -o - 2>&1 | 
FileCheck %s --check-prefix=CHECK-NO-REMARKS
 // RUN: %clang_cc1 %s -Rpass=inline -fno-experimental-new-pass-manager 
-Rno-everything -Reverything -emit-llvm -o - 2>&1 | FileCheck %s 
--check-prefix=CHECK-REMARKS
+// RUN: %clang_cc1 %s -Rpass -Rno-pass -round-trip-args 
-fexperimental-new-pass-manager -mllvm -mandatory-inlining-first=false -O1 
-emit-llvm -o - 2>&1 | FileCheck %s --check-prefix=CHECK-NO-REMARKS
 //
 // The inliner for the new PM does not seem to be enabled at O0, but we still
 // get the same remarks with at least O1.



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

[PATCH] D110783: [clang] Make crash reproducer work with clang-cl

[Nico Weber 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 rG8dfbe9b0aeb6: [clang] Make crash reproducer work with 
clang-cl (authored by thakis).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110783

Files:
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/crash-report-clang-cl.c
  clang/test/Driver/crash-report-clang-cl.cpp
  clang/test/Driver/crash-report.c
  clang/test/Driver/crash-report.cpp

Index: clang/test/Driver/crash-report.cpp
===
--- clang/test/Driver/crash-report.cpp
+++ clang/test/Driver/crash-report.cpp
@@ -6,25 +6,25 @@
 // RUN:  -iprefix /the/prefix -iwithprefix /tmp -iwithprefixbefore /tmp/ \
 // RUN:  -Xclang -internal-isystem -Xclang /tmp/ \
 // RUN:  -Xclang -internal-externc-isystem -Xclang /tmp/ \
-// RUN:  -Xclang -main-file-name -Xclang foo.c   \
+// RUN:  -Xclang -main-file-name -Xclang foo.cpp \
 // RUN:  -DFOO=BAR -DBAR="BAZ QUX"' > %t.rsp
 
 // RUN: env TMPDIR=%t TEMP=%t TMP=%t RC_DEBUG_OPTIONS=1  \
 // RUN:  CC_PRINT_HEADERS=1 CC_LOG_DIAGNOSTICS=1 \
 // RUN:  not %clang %s @%t.rsp -DPARSER 2>&1 | FileCheck %s
-// RUN: cat %t/crash-report-*.c | FileCheck --check-prefix=CHECKSRC %s
+// RUN: cat %t/crash-report-*.cpp | FileCheck --check-prefix=CHECKSRC %s
 // RUN: cat %t/crash-report-*.sh | FileCheck --check-prefix=CHECKSH %s
 
 // RUN: env TMPDIR=%t TEMP=%t TMP=%t RC_DEBUG_OPTIONS=1  \
 // RUN:  CC_PRINT_HEADERS=1 CC_LOG_DIAGNOSTICS=1 \
 // RUN:  not %clang %s @%t.rsp -DCRASH 2>&1 | FileCheck %s
-// RUN: cat %t/crash-report-*.c | FileCheck --check-prefix=CHECKSRC %s
+// RUN: cat %t/crash-report-*.cpp | FileCheck --check-prefix=CHECKSRC %s
 // RUN: cat %t/crash-report-*.sh | FileCheck --check-prefix=CHECKSH %s
 
 // RUN: env TMPDIR=%t TEMP=%t TMP=%t RC_DEBUG_OPTIONS=1  \
 // RUN:  CC_PRINT_HEADERS=1 CC_LOG_DIAGNOSTICS=1 \
 // RUN:  not %clang %s @%t.rsp -DFATAL 2>&1 | FileCheck %s
-// RUN: cat %t/crash-report-*.c | FileCheck --check-prefix=CHECKSRC %s
+// RUN: cat %t/crash-report-*.cpp | FileCheck --check-prefix=CHECKSRC %s
 // RUN: cat %t/crash-report-*.sh | FileCheck --check-prefix=CHECKSH %s
 
 // REQUIRES: crash-recovery
@@ -38,16 +38,35 @@
 #endif
 
 // CHECK: Preprocessed source(s) and associated run script(s) are located at:
-// CHECK-NEXT: note: diagnostic msg: {{.*}}crash-report-{{.*}}.c
+// CHECK-NEXT: note: diagnostic msg: {{.*}}crash-report-{{.*}}.cpp
+
+// __has_feature(cxx_exceptions) is default-on in the gcc-compatible driver.
 FOO
-// CHECKSRC: FOO
+#if __has_feature(cxx_exceptions)
+int a = 1;
+#else
+int a = 0;
+#endif
+// CHECKSRC:  {{^}}FOO
+// CHECKSRC-NEXT: {{^}}#if 0 /* disabled by -frewrite-includes */
+// CHECKSRC-NEXT: {{^}}#if __has_feature(cxx_exceptions)
+// CHECKSRC-NEXT: {{^}}#endif
+// CHECKSRC-NEXT: {{^}}#endif /* disabled by -frewrite-includes */
+// CHECKSRC-NEXT: {{^}}#if 1 /* evaluated by -frewrite-includes */
+// CHECKSRC-NEXT: {{^}}#
+// CHECKSRC-NEXT: {{^}}int a = 1;
+// CHECKSRC-NEXT: {{^}}#else
+// CHECKSRC-NEXT: {{^}}#
+// CHECKSRC-NEXT: {{^}}int a = 0;
+// CHECKSRC-NEXT: {{^}}#endif
+
 // CHECKSH: # Crash reproducer
 // CHECKSH-NEXT: # Driver args: {{.*}}"-fsyntax-only"
 // CHECKSH-SAME: "-D" "FOO=BAR"
 // CHECKSH-SAME: "-D" "BAR=BAZ QUX"
 // CHECKSH-NEXT: # Original command: {{.*$}}
 // CHECKSH-NEXT: "-cc1"
-// CHECKSH: "-main-file-name" "crash-report.c"
+// CHECKSH: "-main-file-name" "crash-report.cpp"
 // CHECKSH-NOT: "-header-include-file"
 // CHECKSH-NOT: "-diagnostic-log-file"
 // CHECKSH: "-D" "FOO=BAR"
@@ -63,4 +82,4 @@
 // CHECKSH-NOT: "-internal-isystem" "/tmp/"
 // CHECKSH-NOT: "-internal-externc-isystem" "/tmp/"
 // CHECKSH-NOT: "-dwarf-debug-flags"
-// CHECKSH: "crash-report-{{[^ ]*}}.c"
+// CHECKSH: "crash-report-{{[^ ]*}}.cpp"
Index: clang/test/Driver/crash-report-clang-cl.cpp
===
--- /dev/null
+++ clang/test/Driver/crash-report-clang-cl.cpp
@@ -0,0 +1,45 @@
+// RUN: rm -rf %t
+// RUN: mkdir %t
+
+// RUN: not %clang_cl -fsyntax-only /Brepro /source-charset:utf-8 \
+// RUN: -fcrash-diagnostics-dir=%t -- %s 2>&1 | FileCheck %s
+// RUN: cat %t/crash-report-clang-cl-*.cpp | FileCheck --check-prefix=CHECKSRC %s
+// RUN: cat %t/crash-report-clang-cl-*.sh | FileCheck --check-prefix=CHECKSH %s
+
+// REQUIRES: crash-recovery
+
+#pragma clang __debug crash
+
+// CHECK: Preprocessed source(s) and associated run script(s) are located at:
+
+// __has_feature(cxx_exceptions) is default-off in the cl-compatible driver.
+FOO
+#if __has_feature(cxx_exceptions)
+int a = 1;
+#else
+int a = 0;
+#endif
+// CHECKSRC:  {{^}}FOO

[clang] 8dfbe9b - [clang] Make crash reproducer work with clang-cl

[Nico Weber via cfe-commits]

Author: Nico Weber
Date: 2021-09-30T14:33:14-04:00
New Revision: 8dfbe9b0aeb6d45975d453dfed828068c63c225e

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

LOG: [clang] Make crash reproducer work with clang-cl

When clang crashes, it writes a standalone source file and shell script
to reproduce the crash.

The Driver used to set `Mode = CPPMode` in generateCompilationDiagnostics()
to force preprocessing mode. This has the side effect of making
IsCLMode() return false, which in turn meant Clang::AddClangCLArgs()
didn't get called when creating the standalone source file, which meant
the stand-alone file was preprocessed with the gcc driver's defaults
In particular, exceptions default to on with the gcc driver, but to
off with the cl driver. The .sh script did use the original command
line, so in the reproducer for a clang-cl crash, the standalone source
file could contain exception-using code after preprocessing that the
compiler invocation in the shell script would then complain about.

This patch removes the `Mode = CPPMode;` line and instead additionally
checks for `CCGenDiagnostics` in most places that check `CCCIsCPP().
This also matches the strategy Clang::ConstructJob() uses to add
-frewrite-includes for creating the standalone source file for a crash
report.

Fixes PR52007.

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

Added: 
clang/test/Driver/crash-report-clang-cl.cpp
clang/test/Driver/crash-report.cpp

Modified: 
clang/lib/Driver/Driver.cpp

Removed: 
clang/test/Driver/crash-report-clang-cl.c
clang/test/Driver/crash-report.c



diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 0c73db892ab80..b27fca58d6357 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -277,7 +277,8 @@ phases::ID Driver::getFinalPhase(const DerivedArgList ,
   if (CCCIsCPP() || (PhaseArg = DAL.getLastArg(options::OPT_E)) ||
   (PhaseArg = DAL.getLastArg(options::OPT__SLASH_EP)) ||
   (PhaseArg = DAL.getLastArg(options::OPT_M, options::OPT_MM)) ||
-  (PhaseArg = DAL.getLastArg(options::OPT__SLASH_P))) {
+  (PhaseArg = DAL.getLastArg(options::OPT__SLASH_P)) ||
+  CCGenDiagnostics) {
 FinalPhase = phases::Preprocess;
 
   // --precompile only runs up to precompilation.
@@ -1343,7 +1344,6 @@ void Driver::generateCompilationDiagnostics(
   PrintVersion(C, llvm::errs());
 
   // Suppress driver output and emit preprocessor output to temp file.
-  Mode = CPPMode;
   CCGenDiagnostics = true;
 
   // Save the original job command(s).
@@ -2263,6 +2263,7 @@ void Driver::BuildInputs(const ToolChain , 
DerivedArgList ,
 //
 // Otherwise emit an error but still use a valid type to avoid
 // spurious errors (e.g., no inputs).
+assert(!CCGenDiagnostics && "stdin produces no crash reproducer");
 if (!Args.hasArgNoClaim(options::OPT_E) && !CCCIsCPP())
   Diag(IsCLMode() ? 
clang::diag::err_drv_unknown_stdin_type_clang_cl
   : clang::diag::err_drv_unknown_stdin_type);
@@ -2278,10 +2279,10 @@ void Driver::BuildInputs(const ToolChain , 
DerivedArgList ,
 Ty = TC.LookupTypeForExtension(Ext + 1);
 
   if (Ty == types::TY_INVALID) {
-if (CCCIsCPP())
-  Ty = types::TY_C;
-else if (IsCLMode() && Args.hasArgNoClaim(options::OPT_E))
+if (IsCLMode() && (Args.hasArgNoClaim(options::OPT_E) || 
CCGenDiagnostics))
   Ty = types::TY_CXX;
+else if (CCCIsCPP() || CCGenDiagnostics)
+  Ty = types::TY_C;
 else
   Ty = types::TY_Object;
   }

diff  --git a/clang/test/Driver/crash-report-clang-cl.c 
b/clang/test/Driver/crash-report-clang-cl.c
deleted file mode 100644
index c4a89f974..0
--- a/clang/test/Driver/crash-report-clang-cl.c
+++ /dev/null
@@ -1,24 +0,0 @@
-// RUN: rm -rf %t
-// RUN: mkdir %t
-
-// RUN: env TMPDIR=%t TEMP=%t TMP=%t RC_DEBUG_OPTIONS=1   \
-// RUN: not %clang_cl -fsyntax-only /Brepro /source-charset:utf-8 \
-// RUN: -- %s 2>&1 | FileCheck %s
-// RUN: cat %t/crash-report-*.sh | FileCheck --check-prefix=CHECKSH %s
-
-// REQUIRES: crash-recovery
-
-#pragma clang __debug crash
-
-// CHECK: Preprocessed source(s) and associated run script(s) are located at:
-// CHECK-NEXT: note: diagnostic msg: {{.*}}crash-report-clang-cl-{{.*}}.c
-// CHECKSH: # Crash reproducer
-// CHECKSH-NEXT: # Driver args: {{.*}}"-fsyntax-only"
-// CHECKSH-SAME: /Brepro
-// CHECKSH-SAME: /source-charset:utf-8
-// CHECKSH-NOT: -mno-incremental-linker-compatible
-// CHECKSH-NOT: -finput-charset=utf-8
-// CHECKSH-NEXT: # Original command: {{.*$}}
-// CHECKSH-NEXT: "-cc1"
-// CHECKSH: 

[PATCH] D110586: Update `DynTypedNode` to support the conversion of `TypeLoc`s.

[James King via Phabricator via cfe-commits]

jcking1034 updated this revision to Diff 376302.
jcking1034 added a comment.

Restore original formatting on unchanged lines.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110586

Files:
  clang/include/clang/AST/ASTTypeTraits.h
  clang/lib/AST/ASTTypeTraits.cpp

Index: clang/lib/AST/ASTTypeTraits.cpp
===
--- clang/lib/AST/ASTTypeTraits.cpp
+++ clang/lib/AST/ASTTypeTraits.cpp
@@ -18,6 +18,7 @@
 #include "clang/AST/DeclCXX.h"
 #include "clang/AST/NestedNameSpecifier.h"
 #include "clang/AST/OpenMPClause.h"
+#include "clang/AST/TypeLoc.h"
 
 using namespace clang;
 
@@ -28,6 +29,8 @@
 {NKI_None, "TemplateName"},
 {NKI_None, "NestedNameSpecifierLoc"},
 {NKI_None, "QualType"},
+#define TYPELOC(CLASS, PARENT) {NKI_##PARENT, #CLASS "TypeLoc"},
+#include "clang/AST/TypeLocNodes.def"
 {NKI_None, "TypeLoc"},
 {NKI_None, "CXXBaseSpecifier"},
 {NKI_None, "CXXCtorInitializer"},
@@ -127,6 +130,17 @@
   llvm_unreachable("invalid type kind");
  }
 
+ ASTNodeKind ASTNodeKind::getFromNode(const TypeLoc ) {
+   switch (T.getTypeLocClass()) {
+#define ABSTRACT_TYPELOC(CLASS, PARENT)
+#define TYPELOC(CLASS, PARENT) \
+  case TypeLoc::CLASS: \
+return ASTNodeKind(NKI_##CLASS##TypeLoc);
+#include "clang/AST/TypeLocNodes.def"
+   }
+   llvm_unreachable("invalid typeloc kind");
+ }
+
 ASTNodeKind ASTNodeKind::getFromNode(const OMPClause ) {
   switch (C.getClauseKind()) {
 #define GEN_CLANG_CLAUSE_CLASS
Index: clang/include/clang/AST/ASTTypeTraits.h
===
--- clang/include/clang/AST/ASTTypeTraits.h
+++ clang/include/clang/AST/ASTTypeTraits.h
@@ -63,6 +63,7 @@
   static ASTNodeKind getFromNode(const Decl );
   static ASTNodeKind getFromNode(const Stmt );
   static ASTNodeKind getFromNode(const Type );
+  static ASTNodeKind getFromNode(const TypeLoc );
   static ASTNodeKind getFromNode(const OMPClause );
   static ASTNodeKind getFromNode(const Attr );
   /// \}
@@ -133,6 +134,8 @@
 NKI_TemplateName,
 NKI_NestedNameSpecifierLoc,
 NKI_QualType,
+#define TYPELOC(CLASS, PARENT) NKI_##CLASS##TypeLoc,
+#include "clang/AST/TypeLocNodes.def"
 NKI_TypeLoc,
 NKI_LastKindWithoutPointerIdentity = NKI_TypeLoc,
 NKI_CXXBaseSpecifier,
@@ -198,6 +201,8 @@
 KIND_TO_KIND_ID(NestedNameSpecifier)
 KIND_TO_KIND_ID(NestedNameSpecifierLoc)
 KIND_TO_KIND_ID(QualType)
+#define TYPELOC(CLASS, PARENT) KIND_TO_KIND_ID(CLASS##TypeLoc)
+#include "clang/AST/TypeLocNodes.def"
 KIND_TO_KIND_ID(TypeLoc)
 KIND_TO_KIND_ID(Decl)
 KIND_TO_KIND_ID(Stmt)
@@ -304,7 +309,7 @@
   return getUnchecked().getAsOpaquePtr() <
  Other.getUnchecked().getAsOpaquePtr();
 
-if (ASTNodeKind::getFromNodeKind().isSame(NodeKind)) {
+if (ASTNodeKind::getFromNodeKind().isBaseOf(NodeKind)) {
   auto TLA = getUnchecked();
   auto TLB = Other.getUnchecked();
   return std::make_pair(TLA.getType().getAsOpaquePtr(),
@@ -336,7 +341,7 @@
 if (ASTNodeKind::getFromNodeKind().isSame(NodeKind))
   return getUnchecked() == Other.getUnchecked();
 
-if (ASTNodeKind::getFromNodeKind().isSame(NodeKind))
+if (ASTNodeKind::getFromNodeKind().isBaseOf(NodeKind))
   return getUnchecked() == Other.getUnchecked();
 
 if (ASTNodeKind::getFromNodeKind().isSame(NodeKind))
@@ -365,7 +370,7 @@
 }
 static unsigned getHashValue(const DynTypedNode ) {
   // FIXME: Add hashing support for the remaining types.
-  if (ASTNodeKind::getFromNodeKind().isSame(Val.NodeKind)) {
+  if (ASTNodeKind::getFromNodeKind().isBaseOf(Val.NodeKind)) {
 auto TL = Val.getUnchecked();
 return llvm::hash_combine(TL.getType().getAsOpaquePtr(),
   TL.getOpaqueData());
@@ -455,6 +460,29 @@
 }
   };
 
+  /// Converter that stores nodes by value. It must be possible to dynamically
+  /// cast the stored node within a type hierarchy without breaking (especially
+  /// through slicing).
+  template >
+  struct DynCastValueConverter {
+static const T *get(ASTNodeKind NodeKind, const void *Storage) {
+  if (ASTNodeKind::getFromNodeKind().isBaseOf(NodeKind))
+return (NodeKind, Storage);
+  return nullptr;
+}
+static const T (ASTNodeKind NodeKind, const void *Storage) {
+  assert(ASTNodeKind::getFromNodeKind().isBaseOf(NodeKind));
+  return *static_cast(reinterpret_cast(Storage));
+}
+static DynTypedNode create(const BaseT ) {
+  DynTypedNode Result;
+  Result.NodeKind = ASTNodeKind::getFromNode(Node);
+  new () BaseT(Node);
+  return Result;
+}
+  };
+
   ASTNodeKind NodeKind;
 
   /// Stores the data of the node.
@@ -525,9 +553,10 @@
 struct DynTypedNode::BaseConverter : public ValueConverter {};
 

[PATCH] D110780: [clang] do not emit note for bad conversion when destination type qualifiers don't compatibly include source type qualifiers

[Zequan Wu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGdbaa40833693: [clang] do not emit note for bad conversion 
when destination type qualifiers… (authored by zequanwu).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110780

Files:
  clang/lib/Sema/SemaInit.cpp
  clang/test/SemaCXX/pointer-forward-declared-class-conversion.cpp


Index: clang/test/SemaCXX/pointer-forward-declared-class-conversion.cpp
===
--- clang/test/SemaCXX/pointer-forward-declared-class-conversion.cpp
+++ clang/test/SemaCXX/pointer-forward-declared-class-conversion.cpp
@@ -9,3 +9,9 @@
 template  class B2;
 B2 *b2;
 A2 *a2 = b2; // expected-error{{cannot initialize a variable of type 
'A2 *' with an lvalue of type 'B2 *'}}
+
+typedef struct S s;
+const s *f();
+s *g1() { return f(); } // expected-error{{cannot initialize return object of 
type 's *' (aka 'S *') with an rvalue of type 'const s *' (aka 'const S *')}}
+
+B1 *g2() { return f(); } // expected-error{{cannot initialize return object of 
type 'B1 *' with an rvalue of type 'const s *' (aka 'const S *')}}
\ No newline at end of file
Index: clang/lib/Sema/SemaInit.cpp
===
--- clang/lib/Sema/SemaInit.cpp
+++ clang/lib/Sema/SemaInit.cpp
@@ -8914,12 +8914,16 @@
   S.EmitRelatedResultTypeNoteForReturn(destType);
   }
   QualType fromType = op->getType();
-  auto *fromDecl = fromType.getTypePtr()->getPointeeCXXRecordDecl();
-  auto *destDecl = destType.getTypePtr()->getPointeeCXXRecordDecl();
+  QualType fromPointeeType = fromType.getCanonicalType()->getPointeeType();
+  QualType destPointeeType = destType.getCanonicalType()->getPointeeType();
+  auto *fromDecl = fromType->getPointeeCXXRecordDecl();
+  auto *destDecl = destType->getPointeeCXXRecordDecl();
   if (fromDecl && destDecl && fromDecl->getDeclKind() == Decl::CXXRecord &&
   destDecl->getDeclKind() == Decl::CXXRecord &&
   !fromDecl->isInvalidDecl() && !destDecl->isInvalidDecl() &&
-  !fromDecl->hasDefinition())
+  !fromDecl->hasDefinition() &&
+  destPointeeType.getQualifiers().compatiblyIncludes(
+  fromPointeeType.getQualifiers()))
 S.Diag(fromDecl->getLocation(), diag::note_forward_class_conversion)
 << S.getASTContext().getTagDeclType(fromDecl)
 << S.getASTContext().getTagDeclType(destDecl);


Index: clang/test/SemaCXX/pointer-forward-declared-class-conversion.cpp
===
--- clang/test/SemaCXX/pointer-forward-declared-class-conversion.cpp
+++ clang/test/SemaCXX/pointer-forward-declared-class-conversion.cpp
@@ -9,3 +9,9 @@
 template  class B2;
 B2 *b2;
 A2 *a2 = b2; // expected-error{{cannot initialize a variable of type 'A2 *' with an lvalue of type 'B2 *'}}
+
+typedef struct S s;
+const s *f();
+s *g1() { return f(); } // expected-error{{cannot initialize return object of type 's *' (aka 'S *') with an rvalue of type 'const s *' (aka 'const S *')}}
+
+B1 *g2() { return f(); } // expected-error{{cannot initialize return object of type 'B1 *' with an rvalue of type 'const s *' (aka 'const S *')}}
\ No newline at end of file
Index: clang/lib/Sema/SemaInit.cpp
===
--- clang/lib/Sema/SemaInit.cpp
+++ clang/lib/Sema/SemaInit.cpp
@@ -8914,12 +8914,16 @@
   S.EmitRelatedResultTypeNoteForReturn(destType);
   }
   QualType fromType = op->getType();
-  auto *fromDecl = fromType.getTypePtr()->getPointeeCXXRecordDecl();
-  auto *destDecl = destType.getTypePtr()->getPointeeCXXRecordDecl();
+  QualType fromPointeeType = fromType.getCanonicalType()->getPointeeType();
+  QualType destPointeeType = destType.getCanonicalType()->getPointeeType();
+  auto *fromDecl = fromType->getPointeeCXXRecordDecl();
+  auto *destDecl = destType->getPointeeCXXRecordDecl();
   if (fromDecl && destDecl && fromDecl->getDeclKind() == Decl::CXXRecord &&
   destDecl->getDeclKind() == Decl::CXXRecord &&
   !fromDecl->isInvalidDecl() && !destDecl->isInvalidDecl() &&
-  !fromDecl->hasDefinition())
+  !fromDecl->hasDefinition() &&
+  destPointeeType.getQualifiers().compatiblyIncludes(
+  fromPointeeType.getQualifiers()))
 S.Diag(fromDecl->getLocation(), diag::note_forward_class_conversion)
 << S.getASTContext().getTagDeclType(fromDecl)
 << S.getASTContext().getTagDeclType(destDecl);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109599: [PowerPC][MMA] Allow MMA builtin types in pre-P10 compilation units

[Kamau Bridgeman via Phabricator via cfe-commits]

kamaub updated this revision to Diff 376300.
kamaub added a comment.

Rebasing this patch and addressing review comments

An upstream commit removed the need for this patch to modify a few
test cases so it has been rebased to remain up-to-date, also addressing
review comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109599

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/AST/ast-dump-ppc-types.c
  clang/test/CodeGen/ppc-mma-types.c
  clang/test/CodeGenCXX/ppc-mangle-mma-types.cpp
  clang/test/Sema/ppc-mma-builtins.c
  clang/test/Sema/ppc-paired-vector-builtins.c

Index: clang/test/Sema/ppc-paired-vector-builtins.c
===
--- /dev/null
+++ clang/test/Sema/ppc-paired-vector-builtins.c
@@ -0,0 +1,28 @@
+// REQUIRES: powerpc-registered-target
+// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -target-cpu pwr10 \
+// RUN:   -target-feature -paired-vector-memops -fsyntax-only %s -verify
+// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -target-cpu pwr9 \
+// RUN:   -fsyntax-only %s -verify
+
+void test1(unsigned char *vqp, unsigned char *vpp, vector unsigned char vc, unsigned char *resp) {
+  __vector_pair res;
+  __builtin_vsx_assemble_pair(, vc, vc); // expected-error {{this builtin is only valid on POWER10 or later CPUs}}
+}
+
+void test2(unsigned char *vqp, unsigned char *vpp, vector unsigned char vc, unsigned char *resp) {
+  __builtin_vsx_disassemble_pair(resp, (__vector_pair*)vpp); // expected-error {{this builtin is only valid on POWER10 or later CPUs}}
+}
+
+void test3(const __vector_pair *vpp, signed long long offset, const __vector_pair *vp2) {
+  __vector_pair vp = __builtin_vsx_lxvp(offset, vpp); // expected-error {{this builtin is only valid on POWER10 or later CPUs}}
+  __builtin_vsx_stxvp(vp, offset, vp2); // expected-error {{this builtin is only valid on POWER10 or later CPUs}}
+}
+
+void test4(unsigned char *vqp, unsigned char *vpp, vector unsigned char vc, unsigned char *resp) {
+  __vector_quad vq = *((__vector_quad *)vqp);
+  __vector_pair vp = *((__vector_pair *)vpp);
+  __builtin_mma_xxmtacc(); // expected-error {{this builtin is only valid on POWER10 or later CPUs}}
+  *((__vector_quad *)resp) = vq;
+}
+
+
Index: clang/test/Sema/ppc-mma-builtins.c
===
--- /dev/null
+++ clang/test/Sema/ppc-mma-builtins.c
@@ -0,0 +1,33 @@
+// REQUIRES: powerpc-registered-target
+// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -target-cpu pwr10 \
+// RUN:   -target-feature -mma -fsyntax-only %s -verify
+
+void test1(unsigned char *vqp, unsigned char *vpp, vector unsigned char vc, unsigned char *resp) {
+  __vector_pair res;
+  __builtin_vsx_assemble_pair(, vc, vc);
+}
+
+void test2(unsigned char *vqp, unsigned char *vpp, vector unsigned char vc, unsigned char *resp) {
+  __builtin_vsx_disassemble_pair(resp, (__vector_pair*)vpp);
+}
+
+void test3(const __vector_pair *vpp, signed long offset, const __vector_pair *vp2) {
+  __vector_pair vp = __builtin_vsx_lxvp(offset, vpp);
+  __builtin_vsx_stxvp(vp, offset, vp2);
+}
+
+void test4(unsigned char *vqp, unsigned char *vpp, vector unsigned char vc, unsigned char *resp) {
+  __vector_quad vq = *((__vector_quad *)vqp);
+  __vector_pair vp = *((__vector_pair *)vpp);
+  __builtin_mma_xxmtacc(); // expected-error {{this builtin is only valid on POWER10 or later CPUs}}
+  *((__vector_quad *)resp) = vq;
+}
+
+void test5(unsigned char *vqp, unsigned char *vpp, vector unsigned char vc, unsigned char *resp) {
+  __vector_quad vq = *((__vector_quad *)vqp);
+  __vector_pair vp = *((__vector_pair *)vpp);
+  __builtin_mma_pmxvf64ger(, vp, vc, 0, 0); // expected-error {{this builtin is only valid on POWER10 or later CPUs}}
+  *((__vector_quad *)resp) = vq;
+}
+
+
Index: clang/test/CodeGenCXX/ppc-mangle-mma-types.cpp
===
--- clang/test/CodeGenCXX/ppc-mangle-mma-types.cpp
+++ clang/test/CodeGenCXX/ppc-mangle-mma-types.cpp
@@ -1,4 +1,8 @@
-// RUN: %clang_cc1 -triple powerpc64le-linux-unknown -target-cpu future %s \
+// RUN: %clang_cc1 -triple powerpc64le-linux-unknown -target-cpu pwr10 %s \
+// RUN:   -emit-llvm -o - | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-linux-unknown -target-cpu pwr9 %s \
+// RUN:   -emit-llvm -o - | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-linux-unknown -target-cpu pwr8 %s \
 // RUN:   -emit-llvm -o - | FileCheck %s
 
 // CHECK: _Z2f1Pu13__vector_quad
Index: clang/test/CodeGen/ppc-mma-types.c
===
--- clang/test/CodeGen/ppc-mma-types.c
+++ clang/test/CodeGen/ppc-mma-types.c
@@ -1,5 +1,9 @@
 // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
-// RUN: 

[PATCH] D110780: [clang] do not emit note for bad conversion when destination type qualifiers don't compatibly include source type qualifiers

[Zequan Wu via Phabricator via cfe-commits]

zequanwu updated this revision to Diff 376299.
zequanwu added a comment.

Add a testcase that from and to type are differ and qualification are 
incompatible.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110780

Files:
  clang/lib/Sema/SemaInit.cpp
  clang/test/SemaCXX/pointer-forward-declared-class-conversion.cpp


Index: clang/test/SemaCXX/pointer-forward-declared-class-conversion.cpp
===
--- clang/test/SemaCXX/pointer-forward-declared-class-conversion.cpp
+++ clang/test/SemaCXX/pointer-forward-declared-class-conversion.cpp
@@ -9,3 +9,9 @@
 template  class B2;
 B2 *b2;
 A2 *a2 = b2; // expected-error{{cannot initialize a variable of type 
'A2 *' with an lvalue of type 'B2 *'}}
+
+typedef struct S s;
+const s *f();
+s *g1() { return f(); } // expected-error{{cannot initialize return object of 
type 's *' (aka 'S *') with an rvalue of type 'const s *' (aka 'const S *')}}
+
+B1 *g2() { return f(); } // expected-error{{cannot initialize return object of 
type 'B1 *' with an rvalue of type 'const s *' (aka 'const S *')}}
\ No newline at end of file
Index: clang/lib/Sema/SemaInit.cpp
===
--- clang/lib/Sema/SemaInit.cpp
+++ clang/lib/Sema/SemaInit.cpp
@@ -8914,12 +8914,16 @@
   S.EmitRelatedResultTypeNoteForReturn(destType);
   }
   QualType fromType = op->getType();
-  auto *fromDecl = fromType.getTypePtr()->getPointeeCXXRecordDecl();
-  auto *destDecl = destType.getTypePtr()->getPointeeCXXRecordDecl();
+  QualType fromPointeeType = fromType.getCanonicalType()->getPointeeType();
+  QualType destPointeeType = destType.getCanonicalType()->getPointeeType();
+  auto *fromDecl = fromType->getPointeeCXXRecordDecl();
+  auto *destDecl = destType->getPointeeCXXRecordDecl();
   if (fromDecl && destDecl && fromDecl->getDeclKind() == Decl::CXXRecord &&
   destDecl->getDeclKind() == Decl::CXXRecord &&
   !fromDecl->isInvalidDecl() && !destDecl->isInvalidDecl() &&
-  !fromDecl->hasDefinition())
+  !fromDecl->hasDefinition() &&
+  destPointeeType.getQualifiers().compatiblyIncludes(
+  fromPointeeType.getQualifiers()))
 S.Diag(fromDecl->getLocation(), diag::note_forward_class_conversion)
 << S.getASTContext().getTagDeclType(fromDecl)
 << S.getASTContext().getTagDeclType(destDecl);


Index: clang/test/SemaCXX/pointer-forward-declared-class-conversion.cpp
===
--- clang/test/SemaCXX/pointer-forward-declared-class-conversion.cpp
+++ clang/test/SemaCXX/pointer-forward-declared-class-conversion.cpp
@@ -9,3 +9,9 @@
 template  class B2;
 B2 *b2;
 A2 *a2 = b2; // expected-error{{cannot initialize a variable of type 'A2 *' with an lvalue of type 'B2 *'}}
+
+typedef struct S s;
+const s *f();
+s *g1() { return f(); } // expected-error{{cannot initialize return object of type 's *' (aka 'S *') with an rvalue of type 'const s *' (aka 'const S *')}}
+
+B1 *g2() { return f(); } // expected-error{{cannot initialize return object of type 'B1 *' with an rvalue of type 'const s *' (aka 'const S *')}}
\ No newline at end of file
Index: clang/lib/Sema/SemaInit.cpp
===
--- clang/lib/Sema/SemaInit.cpp
+++ clang/lib/Sema/SemaInit.cpp
@@ -8914,12 +8914,16 @@
   S.EmitRelatedResultTypeNoteForReturn(destType);
   }
   QualType fromType = op->getType();
-  auto *fromDecl = fromType.getTypePtr()->getPointeeCXXRecordDecl();
-  auto *destDecl = destType.getTypePtr()->getPointeeCXXRecordDecl();
+  QualType fromPointeeType = fromType.getCanonicalType()->getPointeeType();
+  QualType destPointeeType = destType.getCanonicalType()->getPointeeType();
+  auto *fromDecl = fromType->getPointeeCXXRecordDecl();
+  auto *destDecl = destType->getPointeeCXXRecordDecl();
   if (fromDecl && destDecl && fromDecl->getDeclKind() == Decl::CXXRecord &&
   destDecl->getDeclKind() == Decl::CXXRecord &&
   !fromDecl->isInvalidDecl() && !destDecl->isInvalidDecl() &&
-  !fromDecl->hasDefinition())
+  !fromDecl->hasDefinition() &&
+  destPointeeType.getQualifiers().compatiblyIncludes(
+  fromPointeeType.getQualifiers()))
 S.Diag(fromDecl->getLocation(), diag::note_forward_class_conversion)
 << S.getASTContext().getTagDeclType(fromDecl)
 << S.getASTContext().getTagDeclType(destDecl);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D110770: [clang] Remove duplication in types::getCompilationPhases()

[Nico Weber 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 rGfa32fd3bf7c0: [clang] Remove duplication in 
types::getCompilationPhases() (authored by thakis).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110770

Files:
  clang/include/clang/Driver/Driver.h
  clang/include/clang/Driver/Phases.h
  clang/include/clang/Driver/Types.h
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/Types.cpp

Index: clang/lib/Driver/Types.cpp
===
--- clang/lib/Driver/Types.cpp
+++ clang/lib/Driver/Types.cpp
@@ -362,46 +362,7 @@
 llvm::SmallVector
 types::getCompilationPhases(const clang::driver::Driver ,
 llvm::opt::DerivedArgList , ID Id) {
-  phases::ID LastPhase;
-
-  // Filter to compiler mode. When the compiler is run as a preprocessor then
-  // compilation is not an option.
-  // -S runs the compiler in Assembly listing mode.
-  if (Driver.CCCIsCPP() || DAL.getLastArg(options::OPT_E) ||
-  DAL.getLastArg(options::OPT__SLASH_EP) ||
-  DAL.getLastArg(options::OPT_M, options::OPT_MM) ||
-  DAL.getLastArg(options::OPT__SLASH_P))
-LastPhase = phases::Preprocess;
-
-  // --precompile only runs up to precompilation.
-  // This is a clang extension and is not compatible with GCC.
-  else if (DAL.getLastArg(options::OPT__precompile))
-LastPhase = phases::Precompile;
-
-  // -{fsyntax-only,-analyze,emit-ast} only run up to the compiler.
-  else if (DAL.getLastArg(options::OPT_fsyntax_only) ||
-   DAL.getLastArg(options::OPT_print_supported_cpus) ||
-   DAL.getLastArg(options::OPT_module_file_info) ||
-   DAL.getLastArg(options::OPT_verify_pch) ||
-   DAL.getLastArg(options::OPT_rewrite_objc) ||
-   DAL.getLastArg(options::OPT_rewrite_legacy_objc) ||
-   DAL.getLastArg(options::OPT__migrate) ||
-   DAL.getLastArg(options::OPT__analyze) ||
-   DAL.getLastArg(options::OPT_emit_ast))
-LastPhase = phases::Compile;
-
-  else if (DAL.getLastArg(options::OPT_S) ||
-   DAL.getLastArg(options::OPT_emit_llvm))
-LastPhase = phases::Backend;
-
-  else if (DAL.getLastArg(options::OPT_c))
-LastPhase = phases::Assemble;
-
-  // Generally means, do every phase until Link.
-  else
-LastPhase = phases::LastPhase;
-
-  return types::getCompilationPhases(Id, LastPhase);
+  return types::getCompilationPhases(Id, Driver.getFinalPhase(DAL));
 }
 
 ID types::lookupCXXTypeForCType(ID Id) {
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -304,6 +304,9 @@
   } else if ((PhaseArg = DAL.getLastArg(options::OPT_c))) {
 FinalPhase = phases::Assemble;
 
+  } else if ((PhaseArg = DAL.getLastArg(options::OPT_emit_interface_stubs))) {
+FinalPhase = phases::IfsMerge;
+
   // Otherwise do everything.
   } else
 FinalPhase = phases::Link;
@@ -3841,7 +3844,7 @@
   if (Args.hasArg(options::OPT_emit_interface_stubs)) {
 auto PhaseList = types::getCompilationPhases(
 types::TY_IFS_CPP,
-Args.hasArg(options::OPT_c) ? phases::Compile : phases::LastPhase);
+Args.hasArg(options::OPT_c) ? phases::Compile : phases::IfsMerge);
 
 ActionList MergerInputs;
 
Index: clang/include/clang/Driver/Types.h
===
--- clang/include/clang/Driver/Types.h
+++ clang/include/clang/Driver/Types.h
@@ -111,7 +111,7 @@
   /// getCompilationPhases - Get the list of compilation phases ('Phases') to be
   /// done for type 'Id' up until including LastPhase.
   llvm::SmallVector
-  getCompilationPhases(ID Id, phases::ID LastPhase = phases::LastPhase);
+  getCompilationPhases(ID Id, phases::ID LastPhase = phases::IfsMerge);
   llvm::SmallVector
   getCompilationPhases(const clang::driver::Driver ,
llvm::opt::DerivedArgList , ID Id);
Index: clang/include/clang/Driver/Phases.h
===
--- clang/include/clang/Driver/Phases.h
+++ clang/include/clang/Driver/Phases.h
@@ -22,11 +22,10 @@
 Assemble,
 Link,
 IfsMerge,
-LastPhase = IfsMerge,
   };
 
   enum {
-MaxNumberOfPhases = LastPhase + 1
+MaxNumberOfPhases = IfsMerge + 1
   };
 
   const char *getPhaseName(ID Id);
Index: clang/include/clang/Driver/Driver.h
===
--- clang/include/clang/Driver/Driver.h
+++ clang/include/clang/Driver/Driver.h
@@ -253,6 +253,14 @@
   /// or when using the -gen-reproducer driver flag.
   unsigned GenReproducer : 1;
 
+  // getFinalPhase - Determine which compilation mode we are in and record
+  // which option we used to determine the final phase.
+  // TODO: Much of 

[PATCH] D110770: [clang] Remove duplication in types::getCompilationPhases()

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

Thanks!


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

https://reviews.llvm.org/D110770

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

[clang] fa32fd3 - [clang] Remove duplication in types::getCompilationPhases()

[Nico Weber via cfe-commits]

Author: Nico Weber
Date: 2021-09-30T14:17:14-04:00
New Revision: fa32fd3bf7c070e62487e5ccba00557d57b2ee5c

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

LOG: [clang] Remove duplication in types::getCompilationPhases()

Call Driver::getFinalPhase() instead of duplicating it.

https://reviews.llvm.org/D65993 added the duplication, then
02e35832c301e maded it more obviously a copy of getFinalPhase().

The only difference is that getCompilationPhases() used to use
LastPhase / IfsMerge where getFinalPhase() used Link. Adapt
getFinalPhase() to return IfsMerge when needed.

No intentional behavior change.

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

Added: 


Modified: 
clang/include/clang/Driver/Driver.h
clang/include/clang/Driver/Phases.h
clang/include/clang/Driver/Types.h
clang/lib/Driver/Driver.cpp
clang/lib/Driver/Types.cpp

Removed: 




diff  --git a/clang/include/clang/Driver/Driver.h 
b/clang/include/clang/Driver/Driver.h
index da7e8386a151c..8b1f7091e7015 100644
--- a/clang/include/clang/Driver/Driver.h
+++ b/clang/include/clang/Driver/Driver.h
@@ -253,6 +253,14 @@ class Driver {
   /// or when using the -gen-reproducer driver flag.
   unsigned GenReproducer : 1;
 
+  // getFinalPhase - Determine which compilation mode we are in and record
+  // which option we used to determine the final phase.
+  // TODO: Much of what getFinalPhase returns are not actually true compiler
+  //   modes. Fold this functionality into Types::getCompilationPhases and
+  //   handleArguments.
+  phases::ID getFinalPhase(const llvm::opt::DerivedArgList ,
+   llvm::opt::Arg **FinalPhaseArg = nullptr) const;
+
 private:
   /// Certain options suppress the 'no input files' warning.
   unsigned SuppressMissingInputWarning : 1;
@@ -270,14 +278,6 @@ class Driver {
   llvm::opt::DerivedArgList *
   TranslateInputArgs(const llvm::opt::InputArgList ) const;
 
-  // getFinalPhase - Determine which compilation mode we are in and record
-  // which option we used to determine the final phase.
-  // TODO: Much of what getFinalPhase returns are not actually true compiler
-  //   modes. Fold this functionality into Types::getCompilationPhases and
-  //   handleArguments.
-  phases::ID getFinalPhase(const llvm::opt::DerivedArgList ,
-   llvm::opt::Arg **FinalPhaseArg = nullptr) const;
-
   // handleArguments - All code related to claiming and printing diagnostics
   // related to arguments to the driver are done here.
   void handleArguments(Compilation , llvm::opt::DerivedArgList ,

diff  --git a/clang/include/clang/Driver/Phases.h 
b/clang/include/clang/Driver/Phases.h
index ce914dd705140..9003c58573513 100644
--- a/clang/include/clang/Driver/Phases.h
+++ b/clang/include/clang/Driver/Phases.h
@@ -22,11 +22,10 @@ namespace phases {
 Assemble,
 Link,
 IfsMerge,
-LastPhase = IfsMerge,
   };
 
   enum {
-MaxNumberOfPhases = LastPhase + 1
+MaxNumberOfPhases = IfsMerge + 1
   };
 
   const char *getPhaseName(ID Id);

diff  --git a/clang/include/clang/Driver/Types.h 
b/clang/include/clang/Driver/Types.h
index c9d63551090cf..4aecf7ee1e528 100644
--- a/clang/include/clang/Driver/Types.h
+++ b/clang/include/clang/Driver/Types.h
@@ -111,7 +111,7 @@ namespace types {
   /// getCompilationPhases - Get the list of compilation phases ('Phases') to 
be
   /// done for type 'Id' up until including LastPhase.
   llvm::SmallVector
-  getCompilationPhases(ID Id, phases::ID LastPhase = phases::LastPhase);
+  getCompilationPhases(ID Id, phases::ID LastPhase = phases::IfsMerge);
   llvm::SmallVector
   getCompilationPhases(const clang::driver::Driver ,
llvm::opt::DerivedArgList , ID Id);

diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index b32fc65074642..0c73db892ab80 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -304,6 +304,9 @@ phases::ID Driver::getFinalPhase(const DerivedArgList ,
   } else if ((PhaseArg = DAL.getLastArg(options::OPT_c))) {
 FinalPhase = phases::Assemble;
 
+  } else if ((PhaseArg = DAL.getLastArg(options::OPT_emit_interface_stubs))) {
+FinalPhase = phases::IfsMerge;
+
   // Otherwise do everything.
   } else
 FinalPhase = phases::Link;
@@ -3841,7 +3844,7 @@ void Driver::BuildActions(Compilation , DerivedArgList 
,
   if (Args.hasArg(options::OPT_emit_interface_stubs)) {
 auto PhaseList = types::getCompilationPhases(
 types::TY_IFS_CPP,
-Args.hasArg(options::OPT_c) ? phases::Compile : phases::LastPhase);
+Args.hasArg(options::OPT_c) ? phases::Compile : phases::IfsMerge);
 
 ActionList MergerInputs;
 

diff  --git a/clang/lib/Driver/Types.cpp b/clang/lib/Driver/Types.cpp

[PATCH] D106102: [analyzer][solver] Introduce reasoning for not equal to operator

[Manas Gupta via Phabricator via cfe-commits]

manas added a comment.

In D106102#3032888 , @steakhal wrote:

> Okay, I don't see any problems besides this typo.

Oops!

> BTW do you plan to implement other rules besides this in the future?
> E.g. we currently miss this:
> 'x < y' is `true` if `max(x) < min(y)`; and `false` if `min(x) >= max(y)`
> 'x > y', 'x <= y', etc. in a similar way.

I think these cases need to be specialized as well. As, they aren't returning 
some complex RangeSet, so we can get away with a specialized template for 
`BO_LT/BO_GT` etc., instead of a class method (like `BO_Rem` has). I can work 
on this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106102

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

[PATCH] D110065: [AArch64] Add support for the 'R' architecture profile.

[Nick Desaulniers via Phabricator via cfe-commits]

nickdesaulniers added a comment.

In D110065#3033050 , @labrinea wrote:

> That said my current approach will be breaking the current tools behavior: 
> when the user only specifies the triple and not -march then they will be 
> targeting the intersection, not v8-a.

For the purposes of compiling the linux kernel, for the `ARCH=arm64` port, we 
always pass `-Wa,-march=armv8.5-a` but not `-march=`.  While it's trivial to 
add it to the kernel Makefiles, I worry if this causes clang's behavior to 
differ significantly from GCC. Does GCC support the R profile?

> The impact is not expected to be significant as the missing instructions 
> (smc, dcps3) were not being generated anyway.

I can see in the kernel sources that hypervisor code in KVM is using `smc` 
instructions. `kvm/hyp/hyp-entry.S`  Since we're passing `-Wa,-march=`, I 
suspect with your patch we'd be fine.


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

https://reviews.llvm.org/D110065

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

[PATCH] D110770: [clang] Remove duplication in types::getCompilationPhases()

[Hans Wennborg via Phabricator via cfe-commits]

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

lgtm




Comment at: clang/include/clang/Driver/Phases.h:25
 IfsMerge,
-LastPhase = IfsMerge,
   };

thakis wrote:
> hans wrote:
> > Any reason not to keep the LastPhase alias?
> I found it more confusing than helpful. `Link` and `LastPhase` both start 
> with `L` and it took me a while to realize that the last return in 
> `getFinalPhase()` was `Link`, but the last one in was 
> `getCompilationPhases()`. For the call on line 3847, passing phases::IfsMerge 
> is clearer. And then there's only one use of it left (the default arg), and 
> it doesn't add a ton of clarity there imho. But maybe I subconsciously feel 
> vengeful because I lost 10 minutes due to misreading it for `Link` :) If you 
> want me to put it back, let me know and I'll do so.
No, that sounds reasonable, let's keep your patch as it is.


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

https://reviews.llvm.org/D110770

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

[PATCH] D109967: Simplify handling of builtin with inline redefinition

[Kees Cook via Phabricator via cfe-commits]

kees added a comment.

Is https://bugs.llvm.org/show_bug.cgi?id=50322 and dup of 
https://bugs.llvm.org/show_bug.cgi?id=23280 ? (Can both be closed?)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109967

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

[PATCH] D110656: [clang][Sema] Warn on uninitialized array elments

[Nathan Chancellor via Phabricator via cfe-commits]

nathanchance added a comment.

I can test this on the Linux kernel tonight and report the results tomorrow 
morning.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110656

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

[PATCH] D110656: [clang][Sema] Warn on uninitialized array elments

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 added a subscriber: nathanchance.
xbolva00 added a comment.

>> If there are other patterns, I'd love to know what they are.

Well, I dont know :) but something may arise so some testing would be useful.

If possible, @beanz could share list of new warnings from LLVM build here? Also 
maybe you can try this with linux kernel? Or with cooperation with 
@nathanchance..


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110656

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

[PATCH] D108003: [Clang] Extend -Wbool-operation to warn about bitwise and of bools with side effects

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 updated this revision to Diff 376279.
xbolva00 added a comment.

Updated warning-wall.c test.


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

https://reviews.llvm.org/D108003

Files:
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaChecking.cpp
  clang/test/Misc/warning-wall.c
  clang/test/Sema/warn-bitwise-and-bool.c
  clang/test/Sema/warn-bitwise-or-bool.c

Index: clang/test/Sema/warn-bitwise-or-bool.c
===
--- /dev/null
+++ clang/test/Sema/warn-bitwise-or-bool.c
@@ -0,0 +1,63 @@
+// RUN: %clang_cc1 -x c -fsyntax-only -verify -Wbool-operation %s
+// RUN: %clang_cc1 -x c -fsyntax-only -verify -Wall %s
+// RUN: %clang_cc1 -x c -fsyntax-only -Wbitwise-instead-of-logical -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s
+// RUN: %clang_cc1 -x c -fsyntax-only -Wbool-operation -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s
+// RUN: %clang_cc1 -x c++ -fsyntax-only -verify -Wbool-operation %s
+// RUN: %clang_cc1 -x c++ -fsyntax-only -verify -Wall %s
+// RUN: %clang_cc1 -x c++ -fsyntax-only -Wbitwise-instead-of-logical -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s
+// RUN: %clang_cc1 -x c++ -fsyntax-only -Wbool-operation -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s
+
+#ifdef __cplusplus
+typedef bool boolean;
+#else
+typedef _Bool boolean;
+#endif
+
+boolean foo(void);
+boolean bar(void);
+boolean baz(void) __attribute__((const));
+void sink(boolean);
+
+#define FOO foo()
+
+void test(boolean a, boolean b, int *p, volatile int *q, int i) {
+  b = a | b;
+  b = foo() | a;
+  b = (p != 0) | (*p == 42);   // FIXME: also warn for a non-volatile pointer dereference
+  b = foo() | (*q == 42);  // expected-warning {{use of bitwise '|' with boolean operands}}
+   // expected-note@-1 {{cast one or both operands to int to silence this warning}}
+  b = foo() | (int)(*q == 42); // OK, no warning expected
+  b = a | foo();
+  b = (int)a | foo(); // OK, no warning expected
+  b = foo() | bar();  // expected-warning {{use of bitwise '|' with boolean operands}}
+  // expected-note@-1 {{cast one or both operands to int to silence this warning}}
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:13-[[@LINE-2]]:14}:"||"
+  b = foo() | !bar(); // expected-warning {{use of bitwise '|' with boolean operands}}
+  // expected-note@-1 {{cast one or both operands to int to silence this warning}}
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:13-[[@LINE-2]]:14}:"||"
+  b = foo() | (int)bar(); // OK, no warning expected
+  b = a | baz();
+  b = bar() | FOO;// expected-warning {{use of bitwise '|' with boolean operands}}
+  // expected-note@-1 {{cast one or both operands to int to silence this warning}}
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:13-[[@LINE-2]]:14}:"||"
+  b = foo() | (int)FOO;   // OK, no warning expected
+  b = b | foo();
+  b = bar() | (i > 4);
+  b = (i == 7) | foo();
+#ifdef __cplusplus
+  b = foo() bitor bar();  // expected-warning {{use of bitwise '|' with boolean operands}}
+  // expected-note@-1 {{cast one or both operands to int to silence this warning}}
+#endif
+
+  if (foo() | bar())  // expected-warning {{use of bitwise '|' with boolean operands}}
+  // expected-note@-1 {{cast one or both operands to int to silence this warning}}
+;
+
+  sink(a | b);
+  sink(a | foo());
+  sink(foo() | bar());// expected-warning {{use of bitwise '|' with boolean operands}}
+  // expected-note@-1 {{cast one or both operands to int to silence this warning}}
+
+  int n = i + 10;
+  b = (n | (n - 1));
+}
Index: clang/test/Sema/warn-bitwise-and-bool.c
===
--- /dev/null
+++ clang/test/Sema/warn-bitwise-and-bool.c
@@ -0,0 +1,63 @@
+// RUN: %clang_cc1 -x c -fsyntax-only -verify -Wbool-operation %s
+// RUN: %clang_cc1 -x c -fsyntax-only -verify -Wall %s
+// RUN: %clang_cc1 -x c -fsyntax-only -Wbitwise-instead-of-logical -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s
+// RUN: %clang_cc1 -x c -fsyntax-only -Wbool-operation -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s
+// RUN: %clang_cc1 -x c++ -fsyntax-only -verify -Wbool-operation %s
+// RUN: %clang_cc1 -x c++ -fsyntax-only -verify -Wall %s
+// RUN: %clang_cc1 -x c++ -fsyntax-only -Wbitwise-instead-of-logical -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s
+// RUN: %clang_cc1 -x c++ -fsyntax-only -Wbool-operation -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s
+
+#ifdef __cplusplus
+typedef bool boolean;
+#else
+typedef _Bool boolean;
+#endif
+
+boolean foo(void);
+boolean bar(void);
+boolean baz(void) __attribute__((const));
+void sink(boolean);
+

[PATCH] D110858: [PowerPC] Implement vector float and vector double version for vec_orc builtin

[Albion Fung via Phabricator via cfe-commits]

Conanap created this revision.
Conanap added reviewers: PowerPC, nemanjai, kamaub, saghir.
Conanap added projects: LLVM, clang, PowerPC.
Herald added a subscriber: kbarton.
Conanap requested review of this revision.

The builtin for vec_orc has support for the following two signatures,
but currently the compiler marks it ambiguous:
`vector float vec_orc(vector float, vector float)`
`vector double vec_orc(vector double, vector double)`

This patch implements these two builtins.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D110858

Files:
  clang/lib/Headers/altivec.h
  clang/test/CodeGen/builtins-ppc-p8vector.c


Index: clang/test/CodeGen/builtins-ppc-p8vector.c
===
--- clang/test/CodeGen/builtins-ppc-p8vector.c
+++ clang/test/CodeGen/builtins-ppc-p8vector.c
@@ -35,7 +35,9 @@
 vector unsigned __int128 vux = { 1 };
 
 vector float vfa = { 1.e-4f, -132.23f, -22.1, 32.00f };
+vector float vfb = { 1.e-4f, -132.23f, -22.1, 32.00f };
 vector double vda = { 1.e-11, -132.23e10 };
+vector double vdb = { 1.e-11, -132.23e10 };
 
 int res_i;
 double res_d;
@@ -1067,6 +1069,12 @@
 // CHECK: [[T1:%.+]] = xor <4 x i32> {{%.+}}, 
 // CHECK: or <4 x i32> {{%.+}}, [[T1]]
 // CHECK-LE: [[T1:%.+]] = xor <4 x i32> {{%.+}}, 
+// CHECK-LE: or <4 x i32> {{%.+}}, [[T1]]
+
+  res_vf = vec_orc(vfa, vfb);
+// CHECK: [[T1:%.+]] = xor <4 x i32> {{%.+}}, 
+// CHECK: or <4 x i32> {{%.+}}, [[T1]]
+// CHECK-LE: [[T1:%.+]] = xor <4 x i32> {{%.+}}, 
 // CHECK-LE: or <4 x i32> {{%.+}}, [[T1]]
 
   res_vsll = vec_orc(vsll, vsll);
@@ -1121,6 +1129,12 @@
 // CHECK: [[T1:%.+]] = xor <2 x i64> {{%.+}}, 
 // CHECK: or <2 x i64> {{%.+}}, [[T1]]
 // CHECK-LE: [[T1:%.+]] = xor <2 x i64> {{%.+}}, 
+// CHECK-LE: or <2 x i64> {{%.+}}, [[T1]]
+
+  res_vd = vec_orc(vda, vdb);
+// CHECK: [[T1:%.+]] = xor <2 x i64> {{%.+}}, 
+// CHECK: or <2 x i64> {{%.+}}, [[T1]]
+// CHECK-LE: [[T1:%.+]] = xor <2 x i64> {{%.+}}, 
 // CHECK-LE: or <2 x i64> {{%.+}}, [[T1]]
 
   /* vec_sub */
Index: clang/lib/Headers/altivec.h
===
--- clang/lib/Headers/altivec.h
+++ clang/lib/Headers/altivec.h
@@ -7109,6 +7109,11 @@
   return (vector float)((vector unsigned int)__a | ~__b);
 }
 
+static __inline__ vector float __ATTRS_o_ai
+vec_orc(vector float __a, vector float __b) {
+  return (vector float) ((vector unsigned int)__a | ~(vector unsigned int)__b);
+}
+
 static __inline__ vector signed long long __ATTRS_o_ai
 vec_orc(vector signed long long __a, vector signed long long __b) {
   return __a | ~__b;
@@ -7153,6 +7158,11 @@
 vec_orc(vector bool long long __a, vector double __b) {
   return (vector double)(__a | ~(vector unsigned long long)__b);
 }
+
+static __inline__ vector double __ATTRS_o_ai
+vec_orc(vector double __a, vector double __b) {
+  return (vector double)((vector bool long long)__a | ~(vector unsigned long 
long)__b);
+}
 #endif
 
 /* vec_vor */


Index: clang/test/CodeGen/builtins-ppc-p8vector.c
===
--- clang/test/CodeGen/builtins-ppc-p8vector.c
+++ clang/test/CodeGen/builtins-ppc-p8vector.c
@@ -35,7 +35,9 @@
 vector unsigned __int128 vux = { 1 };
 
 vector float vfa = { 1.e-4f, -132.23f, -22.1, 32.00f };
+vector float vfb = { 1.e-4f, -132.23f, -22.1, 32.00f };
 vector double vda = { 1.e-11, -132.23e10 };
+vector double vdb = { 1.e-11, -132.23e10 };
 
 int res_i;
 double res_d;
@@ -1067,6 +1069,12 @@
 // CHECK: [[T1:%.+]] = xor <4 x i32> {{%.+}}, 
 // CHECK: or <4 x i32> {{%.+}}, [[T1]]
 // CHECK-LE: [[T1:%.+]] = xor <4 x i32> {{%.+}}, 
+// CHECK-LE: or <4 x i32> {{%.+}}, [[T1]]
+
+  res_vf = vec_orc(vfa, vfb);
+// CHECK: [[T1:%.+]] = xor <4 x i32> {{%.+}}, 
+// CHECK: or <4 x i32> {{%.+}}, [[T1]]
+// CHECK-LE: [[T1:%.+]] = xor <4 x i32> {{%.+}}, 
 // CHECK-LE: or <4 x i32> {{%.+}}, [[T1]]
 
   res_vsll = vec_orc(vsll, vsll);
@@ -1121,6 +1129,12 @@
 // CHECK: [[T1:%.+]] = xor <2 x i64> {{%.+}}, 
 // CHECK: or <2 x i64> {{%.+}}, [[T1]]
 // CHECK-LE: [[T1:%.+]] = xor <2 x i64> {{%.+}}, 
+// CHECK-LE: or <2 x i64> {{%.+}}, [[T1]]
+
+  res_vd = vec_orc(vda, vdb);
+// CHECK: [[T1:%.+]] = xor <2 x i64> {{%.+}}, 
+// CHECK: or <2 x i64> {{%.+}}, [[T1]]
+// CHECK-LE: [[T1:%.+]] = xor <2 x i64> {{%.+}}, 
 // CHECK-LE: or <2 x i64> {{%.+}}, [[T1]]
 
   /* vec_sub */
Index: clang/lib/Headers/altivec.h
===
--- clang/lib/Headers/altivec.h
+++ clang/lib/Headers/altivec.h
@@ -7109,6 +7109,11 @@
   return (vector float)((vector unsigned int)__a | ~__b);
 }
 
+static __inline__ vector float __ATTRS_o_ai
+vec_orc(vector float __a, vector float __b) {
+  return (vector float) ((vector unsigned int)__a | ~(vector unsigned int)__b);
+}
+
 static __inline__ vector signed long long __ATTRS_o_ai
 vec_orc(vector signed long long __a, vector signed long long __b) {
   return __a | ~__b;
@@ -7153,6 +7158,11 @@
 

[PATCH] D110656: [clang][Sema] Warn on uninitialized array elments

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D110656#3034083 , @xbolva00 wrote:

> Why just no special case "= {0};" pattern and do not warn in that case?

This was what I was thinking. I was basing that on the idea that `= { 0 }` to 
zero init the entire array is far more common than ` = { 1 }` to init the first 
element to one and the rest to zero (which is a case I think this diagnostic 
shines on because some users think that will fill all `1` instead of only the 
first element).

> If there are more patterns, take it from other side - pick patterns where you 
> are sure that they are wrong and developer needs to fix them and emit 
> warnings for them.

If there are other patterns, I'd love to know what they are.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110656

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

[PATCH] D110586: Update `DynTypedNode` to support the conversion of `TypeLoc`s.

[Samuel Benzaquen via Phabricator via cfe-commits]

sbenza added inline comments.



Comment at: clang/include/clang/AST/ASTTypeTraits.h:472
+  assert(ASTNodeKind::getFromNodeKind().isBaseOf(NodeKind));
+  return *static_cast(reinterpret_cast(Storage));
+}

The create/get don't seem to match.
We are constructing a `BaseT` object in `create()`, so this `static_cast` to a 
derived type is UB?
That memory does not contain a `T`.

If we instead construct a `T` in `create()`, we should be able to read it as a 
`BaseT*` (assuming `is_pointer_interconvertible_base_of` is true)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110586

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

[PATCH] D110656: [clang][Sema] Warn on uninitialized array elments

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 added a comment.

Why just no special case "= {0};" pattern and do not warn in that case?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110656

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

[PATCH] D108003: [Clang] Extend -Wbool-operation to warn about bitwise and of bools with side effects

[Nathan Chancellor via Phabricator via cfe-commits]

nathanchance added a comment.

As far as I am aware, this iteration of the patch has no instances in the Linux 
kernel now. The instances I found with the first iteration of the patch only 
had a right hand side with side effects, not both sides, so this warning is 
effectively a no-op now (not that there won't be instances in the future). If 
any happen to show up, I will send fixes for them at that time. In other words, 
LGTM.


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

https://reviews.llvm.org/D108003

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

[PATCH] D108003: [Clang] Extend -Wbool-operation to warn about bitwise and of bools with side effects

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 marked an inline comment as done.
xbolva00 added a comment.

@rpbeltran @nathanchance @aaron.ballman Are you OK with the current state of 
this patch? Well, it is clear that some code in linux kernel/Chromium/etc needs 
to adjusted, but I think in many cases it would (atleast) improve readability.


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

https://reviews.llvm.org/D108003

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

[PATCH] D109707: [HIP] [AlwaysInliner] Disable AlwaysInliner to eliminate undefined symbols

[Anshil Gandhi via Phabricator via cfe-commits]

gandhi21299 added a comment.

inline-calls.ll failed on gfx908 due to the change in SIISelLowering.cpp, line 
3015. Without the change, there is a failure in AMDGPUResourceAnalysis.cpp, 
line 65 because Op.getGlobal() is not a Function.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109707

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

[PATCH] D110485: Support [[no_unique_address]] for all targets.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D110485#3033889 , @expnkx wrote:

> https://github.com/microsoft/STL/issues/1364
>
> As Microsoft said, the reason why things like msvc::no_unique_address exist 
> are because clang does not support it. In fact, it has become a vicious 
> cycle. msvc waits clang, clang waits msvc.
>
> It is a vicious cycle. I would argue it is LLVM's fault, not Microsoft's 
> fault.

I don't know why anyone would assume that Clang would be more responsible for 
defining the behavior of a feature on Windows than Microsoft. Microsoft is the 
owner for their ABI, not Clang. When this feature was introduced into Clang, we 
explicitly did not allow it on Windows until Microsoft defined what the ABI is 
for the feature. Now that Microsoft has decided to define 
`[[msvc::no_unique_address]]` with a particular ABI, it would be reasonable for 
us to support *that* spelling. However, it would be unacceptable for us to 
define the behavior for `[[no_unique_address]]` in a way that's different from 
the ABI Microsoft picks for it.

Note: it *might* be reasonable for us to define `[[no_unique_address]]` as 
being ignored on Windows targets as that seems to be the direction Microsoft 
wants to go. However, I personally view the Microsoft behavior here to be 
user-hostile and so I'd like to see whether they're planning to change 
directions before we decide to follow along. However, if Microsoft's position 
is that they're not going to implement the semantic effects for 
`[[no_unique_address]]`, Clang will follow suit on the Windows target.

> Sure you can add another attribute, i tried that, but adding another 
> attribute for doing exactly the same thing through entire code base is just 
> annoying and headache.
>
> If clang does not support [[no_unique_address]], Microsoft is not going to 
> support it either. Microsoft's own words.

And Microsoft's own choice.

> [[no_unique_address]] is ISO C++ standard. Why not support it? I am sorry the 
> entire LLVM did a crappy job on support C++20 standard in general.

In keeping with our code of conduct (https://llvm.org/docs/CodeOfConduct.html), 
please keep your comments respectful.


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

https://reviews.llvm.org/D110485

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

[PATCH] D110656: [clang][Sema] Warn on uninitialized array elments

[Chris Bieneman via Phabricator via cfe-commits]

beanz added a comment.

Even just building Clang with this enabled revealed... a lot... Some of them 
are easy to address (having tablegen disable the warning in generated code), 
some of them are exactly the kind of thing I wanted to warn on, and some of 
them are more complicated.

Based on that alone, I don't think this would be reasonable to enable by 
default :(

Thoughts on how to proceed?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110656

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

[PATCH] D109707: [HIP] [AlwaysInliner] Disable AlwaysInliner to eliminate undefined symbols

[Anshil Gandhi via Phabricator via cfe-commits]

gandhi21299 reclaimed this revision.
gandhi21299 added a comment.

Sorry, that was a mistake.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109707

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

[PATCH] D110641: Implement P0857R0 -Part B: requires clause for template-template params

[Erich Keane via Phabricator via cfe-commits]

erichkeane updated this revision to Diff 376257.
erichkeane added a comment.

Change the skip-until code after a requires-clause failed parse.


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

https://reviews.llvm.org/D110641

Files:
  clang/lib/Parse/ParseTemplate.cpp
  clang/test/CXX/temp/temp.arg/temp.arg.template/p3-2a.cpp
  clang/test/SemaTemplate/concepts.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -912,7 +912,7 @@
 

 https://wg21.link/p0857r0;>P0857R0
-Partial
+Clang 14
   

 https://wg21.link/p1084r2;>P1084R2
Index: clang/test/SemaTemplate/concepts.cpp
===
--- clang/test/SemaTemplate/concepts.cpp
+++ clang/test/SemaTemplate/concepts.cpp
@@ -59,11 +59,10 @@
 x.operator()(); // expected-error {{no matching member function}}
   }
 
-  // FIXME: This is valid under P0857R0.
   template concept C = true;
-  template requires C typename U> struct X {}; // expected-error {{requires 'class'}} expected-error 0+{{}}
+  template requires C typename U> struct X {};
   template requires C struct Y {};
-  X xy; // expected-error {{no template named 'X'}}
+  X xy;
 }
 
 namespace PR50306 {
Index: clang/test/CXX/temp/temp.arg/temp.arg.template/p3-2a.cpp
===
--- clang/test/CXX/temp/temp.arg/temp.arg.template/p3-2a.cpp
+++ clang/test/CXX/temp/temp.arg/temp.arg.template/p3-2a.cpp
@@ -32,3 +32,35 @@
 
 using s31 = S3;
 using s32 = S3;
+
+template
+struct Evals {
+  bool f() { return true; }
+};
+
+template<>
+struct Evals {
+  bool f() { return false; }
+};
+
+template  requires C typename P>
+struct S4 {};
+
+template 
+requires requires { requires T::f(); }
+typename P >
+void func(const P ){};
+
+template  requires false typename P>
+void func_always_requires_false(const P ) {};
+
+void use() {
+  S4 s4;
+  func(Evals{});
+  // A naive individual might expect the following to all fail concept checking,
+  // but there does not seem to be any requirement to check these in the
+  // standard, and none of the other implementations do so either.
+  S4 s4b;
+  func(Evals{});
+  func_always_requires_false(Evals{});
+}
Index: clang/lib/Parse/ParseTemplate.cpp
===
--- clang/lib/Parse/ParseTemplate.cpp
+++ clang/lib/Parse/ParseTemplate.cpp
@@ -871,6 +871,31 @@
 ///   type-parameter-key:
 /// 'class'
 /// 'typename'   [C++1z]
+///
+/// In C++20:
+///   template-head: [C++ temp.pre]
+/// template '<' template-parameter-list '>' requires-clause[opt]
+///
+///   template-parameter: [C++ temp.param]
+/// type-parameter
+/// parameter-declaration
+///
+///   type-parameter:
+/// type-parameter-key ...[opt] identifier[opt]
+/// type-parameter-key identifier[opt] = type-id
+/// type-constraint ...[opt] identifier[opt]
+/// type-constraint identifier[opt] = type-id
+/// template-head type-parameter-key ...[opt] identifier[opt]
+/// template-head type-parameter-key identifier[opt] = id-expression
+///
+///   type-parameter-key:
+/// 'class'
+/// 'typename'
+///
+///   type-constraint:
+/// nested-name-specifier[opt] concept-name
+/// nested-name-specifier[opt] concept-name '<'
+///   template-argument-list[opt] '>'
 NamedDecl *
 Parser::ParseTemplateTemplateParameter(unsigned Depth, unsigned Position) {
   assert(Tok.is(tok::kw_template) && "Expected 'template' keyword");
@@ -879,12 +904,26 @@
   SourceLocation TemplateLoc = ConsumeToken();
   SmallVector TemplateParams;
   SourceLocation LAngleLoc, RAngleLoc;
+  ExprResult OptionalRequiresClauseConstraintER;
   {
 MultiParseScope TemplateParmScope(*this);
 if (ParseTemplateParameters(TemplateParmScope, Depth + 1, TemplateParams,
 LAngleLoc, RAngleLoc)) {
   return nullptr;
 }
+
+// Parse optional requires-clause.
+if (getLangOpts().CPlusPlus20 && TryConsumeToken(tok::kw_requires)) {
+  OptionalRequiresClauseConstraintER =
+  Actions.ActOnRequiresClause(ParseConstraintLogicalOrExpression(
+  /*IsTrailingRequiresClause=*/false));
+  if (!OptionalRequiresClauseConstraintER.isUsable()) {
+// Skip until the semi-colon or a '}'.
+SkipUntil(tok::comma, tok::greater, tok::greatergreater,
+  StopAtSemi | StopBeforeMatch);
+return nullptr;
+  }
+}
   }
 
   // Provide an ExtWarn if the C++1z feature of using 'typename' here is used.
@@ -946,11 +985,9 @@
   if (TryConsumeToken(tok::ellipsis, EllipsisLoc))
 DiagnoseMisplacedEllipsis(EllipsisLoc, NameLoc, AlreadyHasEllipsis, true);
 

[PATCH] D110485: Support [[no_unique_address]] for all targets.

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

In D110485#3033889 , @expnkx wrote:

> In D110485#3030874 , @erichkeane 
> wrote:
>
>> In D110485#3030853 , @expnkx wrote:
>>
>>> clang simply just does not truly support everything msvc supports. There 
>>> are no things that deals [[msvc::]] attributes at all in the clang. In fact 
>>> the point of using clang on windows is that we do not want to do the same 
>>> as Microsoft does.
>>>
>>> Support [[no_unique_address]] is nothing wrong tbh and that is what ISO C++ 
>>> standard requires.
>>>
>>> If we do not change, the Microsoft team won't wanna change either because 
>>> they are afraid of breaking clang too.
>>>
>>> I never understand why [[no_unique_address]] is a problem.
>>
>> A requirement of Clang on Windows is that we are ABI compatible (so that we 
>> can link between them!), the same way that Linux must match the Itanium ABI. 
>>  Allowing no_unique_address on Windows is an ABI compatibility issue.  In 
>> this case, we have to pay attention to what the platform's ABI OWNERS define 
>> as the ABI, which in this case is Microsoft.
>>
>> THAT is why this is a problem, and THAT is what is wrong with this change.
>>
>> If Microsoft defines an ABI for what this does, we can follow them and just 
>> do that.
>
> https://github.com/microsoft/STL/issues/1364
>
> As Microsoft said, the reason why things like msvc::no_unique_address exist 
> are because clang does not support it. In fact, it has become a vicious 
> cycle. msvc waits clang, clang waits msvc.
>
> It is a vicious cycle. I would argue it is LLVM's fault, not Microsoft's 
> fault.
>
> Sure you can add another attribute, i tried that, but adding another 
> attribute for doing exactly the same thing through entire code base is just 
> annoying and headache.
>
> If clang does not support [[no_unique_address]], Microsoft is not going to 
> support it either. Microsoft's own words.
>
> [[no_unique_address]] is ISO C++ standard. Why not support it? I am sorry the 
> entire LLVM did a crappy job on support C++20 standard in general.

My understanding is Microsoft DOES have [[no_unique_address]], it just doesn't 
do anything, right?  So it seems they have decided the ABI is 'pretend this 
attribute doesn't exist'.  Implementing this as anything else is an ABI break, 
which we don't do.


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

https://reviews.llvm.org/D110485

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

[PATCH] D110485: Support [[no_unique_address]] for all targets.

[cqwrteur via Phabricator via cfe-commits]

expnkx added a comment.

In D110485#3030874 , @erichkeane 
wrote:

> In D110485#3030853 , @expnkx wrote:
>
>> clang simply just does not truly support everything msvc supports. There are 
>> no things that deals [[msvc::]] attributes at all in the clang. In fact the 
>> point of using clang on windows is that we do not want to do the same as 
>> Microsoft does.
>>
>> Support [[no_unique_address]] is nothing wrong tbh and that is what ISO C++ 
>> standard requires.
>>
>> If we do not change, the Microsoft team won't wanna change either because 
>> they are afraid of breaking clang too.
>>
>> I never understand why [[no_unique_address]] is a problem.
>
> A requirement of Clang on Windows is that we are ABI compatible (so that we 
> can link between them!), the same way that Linux must match the Itanium ABI.  
> Allowing no_unique_address on Windows is an ABI compatibility issue.  In this 
> case, we have to pay attention to what the platform's ABI OWNERS define as 
> the ABI, which in this case is Microsoft.
>
> THAT is why this is a problem, and THAT is what is wrong with this change.
>
> If Microsoft defines an ABI for what this does, we can follow them and just 
> do that.

https://github.com/microsoft/STL/issues/1364

As Microsoft said, the reason why things like msvc::no_unique_address exist are 
because clang does not support it. In fact, it has become a vicious cycle. msvc 
waits clang, clang waits msvc.

It is a vicious cycle. I would argue it is LLVM's fault, not Microsoft's fault.

Sure you can add another attribute, i tried that, but adding another attribute 
for doing exactly the same thing through entire code base is just annoying and 
headache.

If clang does not support [[no_unique_address]], Microsoft is not going to 
support it either. Microsoft's own words.


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

https://reviews.llvm.org/D110485

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

[PATCH] D110825: [clangd] Handle members of anon structs in SelectionTree

[Sam McCall via Phabricator via cfe-commits]

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

Thanks!




Comment at: clang-tools-extra/clangd/Selection.cpp:446
   return true;
+  // Make sure anonymous structs don't end up owning tokens.
+  if (auto *ME = llvm::dyn_cast(S)) {

hmm, "implicit accesses of anonymous structs"?



Comment at: clang-tools-extra/clangd/Selection.cpp:450
+  if (FD->isAnonymousStructOrUnion())
+// If the base is not implicit, it can own tokens, otherwise we should
+// stop traversal.

The double negatives and references to a "traversal" here seem confusing.
Maybe something more concrete?
```
// If Base is an implicit CXXThis, then the whole MemberExpr has no tokens.
// If it's a normal e.g. DeclRef, we treat the MemberExpr like an implicit cast.
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110825

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

[PATCH] D110810: [clang][ASTImporter] Simplify code of attribute import [NFC].

[Shafik Yaghmour via Phabricator via cfe-commits]

shafik added inline comments.



Comment at: clang/lib/AST/ASTImporter.cpp:8456
 class AttrImporter {
-  Error Err = Error::success();
+  Error 
   ASTImporter 

I am enthusiastic about reference members if we can somehow avoid them.

Can we use a struct to return both the `Err` and the pointer together? I don't 
like `std::pair` mainly b/c `first` and `second` are not meaningful. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110810

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

[PATCH] D110833: [clang-format] Add ControlStatementsAndFunctionDefinitionsExceptControlMacros option to SpaceBeforeParens

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

I feel this is going the way of BraceWrapping  in that it should be:

  SpaceBeforeParens:
 - BeforeMacro: false
 - BeforeFunction: true


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110833

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

[PATCH] D110833: [clang-format] Add ControlStatementsAndFunctionDefinitionsExceptControlMacros option to SpaceBeforeParens

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

First impressions is 
`ControlStatementsAndFunctionDefinitionsExceptControlMacros` is a mouthful...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110833

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

[PATCH] D110482: [clang] Implement if consteval (P1938)

[Corentin Jabot via Phabricator via cfe-commits]

cor3ntin updated this revision to Diff 376245.
cor3ntin added a comment.

Add support for attributes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110482

Files:
  clang/include/clang/AST/Stmt.h
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/Specifiers.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/AST/Interp/ByteCodeStmtGen.cpp
  clang/lib/AST/JSONNodeDumper.cpp
  clang/lib/AST/Stmt.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/AST/TextNodeDumper.cpp
  clang/lib/Analysis/BodyFarm.cpp
  clang/lib/Analysis/CFG.cpp
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/CodeGen/CodeGenPGO.cpp
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Parse/ParseStmt.cpp
  clang/lib/Sema/JumpDiagnostics.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprMember.cpp
  clang/lib/Sema/SemaLambda.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReaderStmt.cpp
  clang/lib/Serialization/ASTWriterStmt.cpp
  clang/lib/StaticAnalyzer/Checkers/LocalizationChecker.cpp
  clang/test/AST/Interp/if_consteval.cpp
  clang/test/AST/ast-dump-if-json.cpp
  clang/test/AST/ast-dump-stmt.cpp
  clang/test/CXX/stmt.stmt/stmt.select/stmt.if/p4.cpp
  clang/test/CodeGenCXX/cxx2b-consteval-if.cpp

Index: clang/test/CodeGenCXX/cxx2b-consteval-if.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/cxx2b-consteval-if.cpp
@@ -0,0 +1,28 @@
+// RUN: %clang_cc1 -std=c++2b %s -emit-llvm -o - | FileCheck %s
+
+void should_be_used_1();
+void should_be_used_2();
+void should_be_used_3();
+constexpr void should_not_be_used() {}
+
+constexpr void f() {
+  if consteval {
+should_not_be_used(); // CHECK-NOT: call {{.*}}should_not_be_used
+  } else {
+should_be_used_1();  // CHECK: call {{.*}}should_be_used_1
+  }
+
+  if !consteval {
+should_be_used_2();  // CHECK: call {{.*}}should_be_used_2
+  }
+
+  if !consteval {
+should_be_used_3();  // CHECK: call {{.*}}should_be_used_3
+  } else {
+should_not_be_used(); // CHECK-NOT: call {{.*}}should_not_be_used
+  }
+}
+
+void g() {
+  f();
+}
Index: clang/test/CXX/stmt.stmt/stmt.select/stmt.if/p4.cpp
===
--- /dev/null
+++ clang/test/CXX/stmt.stmt/stmt.select/stmt.if/p4.cpp
@@ -0,0 +1,157 @@
+// RUN: %clang_cc1 -std=c++2b -verify %s
+
+void test_consteval() {
+  if consteval (void) 0; // expected-error {{expected { after consteval}}
+  if consteval {
+(void)0;
+  } else (void)0; // expected-error {{expected { after else}}
+
+  static_assert([] {
+if consteval {
+  return 0;
+}
+return 1;
+  }() == 0);
+
+  static_assert([] {
+if consteval {
+  return 0;
+} else {
+  return 1;
+}
+  }() == 0);
+
+  static_assert([] {
+if !consteval {
+  return 0;
+} else {
+  return 1;
+}
+  }() == 1);
+
+  static_assert([] {
+if not consteval {
+  return 0;
+}
+return 1;
+  }() == 1);
+
+  if consteval [[likely]] { // expected-warning {{attribute 'likely' has no effect when annotating an 'if consteval' statement}}\
+// expected-note 2{{annotating the 'if consteval' statement here}}
+
+
+  }
+  else [[unlikely]] { // expected-warning {{attribute 'unlikely' has no effect when annotating an 'if consteval' statement}}
+
+  }
+
+}
+
+void test_consteval_jumps() {
+  if consteval { // expected-note 4{{jump enters controlled statement of consteval if}}
+goto a;
+goto b; // expected-error {{cannot jump from this goto statement to its label}}
+  a:;
+  } else {
+goto b;
+goto a; // expected-error {{cannot jump from this goto statement to its label}}
+  b:;
+  }
+  goto a; // expected-error {{cannot jump from this goto statement to its label}}
+  goto b; // expected-error {{cannot jump from this goto statement to its label}}
+}
+
+void test_consteval_switch() {
+  int x = 42;
+  switch (x) {
+if consteval { // expected-note 2{{jump enters controlled statement of consteval if}}
+case 1:;   // expected-error {{cannot jump from switch statement to this case label}}
+default:;  // expected-error {{cannot jump from switch statement to this case label}}
+} else {
+}
+  }
+  switch (x) {
+if consteval { // expected-note 2{{jump enters controlled statement of consteval if}}
+} else {
+case 2:;  // expected-error {{cannot jump from switch statement to this case label}}
+default:; // expected-error {{cannot jump from switch statement to this case label}}
+}
+  }
+}
+
+consteval int f(int i) { return i; }
+constexpr int g(int i) {
+  if consteval {
+return f(i);
+  } else {
+return 42;
+  }
+}
+static_assert(g(10) == 10);
+

[PATCH] D110836: [CMake] Fix typo in error message for LLD in bootstrap builds.

[Frederic Cambus via Phabricator via cfe-commits]

fcambus added a comment.

@xgupta


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110836

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

[PATCH] D110641: Implement P0857R0 -Part B: requires clause for template-template params

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/Parse/ParseTemplate.cpp:923
+  // Skip until the semi-colon or a '}'.
+  SkipUntil(tok::r_brace, StopAtSemi | StopBeforeMatch);
+  TryConsumeToken(tok::semi);

erichkeane wrote:
> aaron.ballman wrote:
> > erichkeane wrote:
> > > I'm not positive about this skip-until and 'TryConsumeToken' either.  The 
> > > other place we do optional requires clause parsing does this, but the 
> > > above 'ParseTemplateParameters' does not.
> > I think we should be skipping until we hit a `>` or `>>` rather than ` }` 
> > right? We can recover after we've finished the template template parameter 
> > parsing, we don't need to parse to the end of the class.
> Perhaps we should copy line 1000 and skip until `>`, `>>` or `,` with no 
> consume?  
That's what I'm thinking, yes.


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

https://reviews.llvm.org/D110641

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

[PATCH] D110641: Implement P0857R0 -Part B: requires clause for template-template params

[Erich Keane via Phabricator via cfe-commits]

erichkeane added inline comments.



Comment at: clang/lib/Parse/ParseTemplate.cpp:923
+  // Skip until the semi-colon or a '}'.
+  SkipUntil(tok::r_brace, StopAtSemi | StopBeforeMatch);
+  TryConsumeToken(tok::semi);

aaron.ballman wrote:
> erichkeane wrote:
> > I'm not positive about this skip-until and 'TryConsumeToken' either.  The 
> > other place we do optional requires clause parsing does this, but the above 
> > 'ParseTemplateParameters' does not.
> I think we should be skipping until we hit a `>` or `>>` rather than ` }` 
> right? We can recover after we've finished the template template parameter 
> parsing, we don't need to parse to the end of the class.
Perhaps we should copy line 1000 and skip until `>`, `>>` or `,` with no 
consume?  


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

https://reviews.llvm.org/D110641

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

[PATCH] D110641: Implement P0857R0 -Part B: requires clause for template-template params

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/Parse/ParseTemplate.cpp:876
+/// In C++20:
+///   template-head: [C++ temp.pre]
+/// template '<' template-parameter-list '>' requires-clause[opt]

erichkeane wrote:
> aaron.ballman wrote:
> > Rather than duplicate the grammar for each standard revision, I think we 
> > usually try to have one grammar section that incorporates all of the 
> > changes over the years, like how we added `[C++1z]` on line 873 above. Any 
> > appetite for trying to rearrange like that?
> C++20 reworded this to the point that there is very little in common, so i 
> feared that the grammar would be particularly rough here.  I tried a merge at 
> one point, and it was just pretty messy (since the productions don't 
> particularly well match between them).
> 
> `type-parameter` in particular ends up being messy, since the leading 
> 'template < param list >' was removed from there.
Okay, SGTM then, thanks!



Comment at: clang/lib/Parse/ParseTemplate.cpp:923
+  // Skip until the semi-colon or a '}'.
+  SkipUntil(tok::r_brace, StopAtSemi | StopBeforeMatch);
+  TryConsumeToken(tok::semi);

erichkeane wrote:
> I'm not positive about this skip-until and 'TryConsumeToken' either.  The 
> other place we do optional requires clause parsing does this, but the above 
> 'ParseTemplateParameters' does not.
I think we should be skipping until we hit a `>` or `>>` rather than ` }` 
right? We can recover after we've finished the template template parameter 
parsing, we don't need to parse to the end of the class.


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

https://reviews.llvm.org/D110641

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

[PATCH] D110836: [CMake] Fix typo in error message for LLD in bootstrap builds.

[Shivam Gupta via Phabricator via cfe-commits]

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

LGTM, Thanks!  And @fcambus If you want to continue contributing to the 
llvm-project, I would suggest you ask for commit access so you can directly 
commit typo fixes without opening revisions. Instructions are here 
-https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110836

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

[PATCH] D110825: [clangd] Handle members of anon structs in SelectionTree

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added inline comments.



Comment at: clang-tools-extra/clangd/Selection.cpp:443
   // It would be nice if RAV handled this (!shouldTraverseImplicitCode()).
   if (auto *CTI = llvm::dyn_cast(S))
 if (CTI->isImplicit())

sammccall wrote:
> kadircet wrote:
> > sammccall wrote:
> > > seems like it'd be more consistent to handle it here?
> > > 
> > > If it's a MemberExpr and the member is in an anonymous struct, then it's 
> > > implicit if `isImplicit(ME.getBase())`.
> > the test case was actually to demonstrate why we can't do it here. we want 
> > to still keep traversing the AST after hitting a field inside an anon 
> > struct. handling here terminates the traversal for that subtree completely, 
> > and the real node we are interested might be down the tree (`y.[[x]]` in 
> > the test case).
> That's what I meant by `isImplicit(ME.getBase())`
> 
> The following passes tests (added to isImplicit)...
> ```
> if (auto *ME = llvm::dyn_cast(S)) 
>   if (auto *FD = llvm::dyn_cast(ME->getMemberDecl()))
> if (FD->isAnonymousStructOrUnion())
>   return isImplicit(ME->getBase());
> ```
> 
> > and the member is in an anonymous struct
> 
> Oops, I meant "and the member *is* an anonymous struct".
> It seems more natural to recognize and special-case the field-access to the 
> anon struct itself (which is intuitively implicit!), than the one to a normal 
> field within it.
right, it makes sense. i was missing the isImplicit(base) bit + got stunned by 
the beautiful shape of the AST. thanks for bearing with me :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110825

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

[PATCH] D110825: [clangd] Handle members of anon structs in SelectionTree

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet updated this revision to Diff 376238.
kadircet marked 4 inline comments as done.
kadircet added a comment.

- Use `isImplicit` rather than `earlyClaim`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110825

Files:
  clang-tools-extra/clangd/Selection.cpp
  clang-tools-extra/clangd/unittests/XRefsTests.cpp


Index: clang-tools-extra/clangd/unittests/XRefsTests.cpp
===
--- clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -365,6 +365,27 @@
   ElementsAre(Sym("Forward", SymbolHeader.range("forward"), 
Test.range(;
 }
 
+TEST(LocateSymbol, AnonymousStructFields) {
+  auto Code = Annotations(R"cpp(
+struct $2[[Foo]] {
+  struct { int $1[[x]]; };
+  void foo() {
+// Make sure the implicit base is skipped.
+$1^x = 42;
+  }
+};
+// Check that we don't skip explicit bases.
+int a = $2^Foo{}.x;
+  )cpp");
+  TestTU TU = TestTU::withCode(Code.code());
+  auto AST = TU.build();
+  EXPECT_THAT(locateSymbolAt(AST, Code.point("1"), TU.index().get()),
+  UnorderedElementsAre(Sym("x", Code.range("1"), 
Code.range("1";
+  EXPECT_THAT(
+  locateSymbolAt(AST, Code.point("2"), TU.index().get()),
+  UnorderedElementsAre(Sym("Foo", Code.range("2"), Code.range("2";
+}
+
 TEST(LocateSymbol, FindOverrides) {
   auto Code = Annotations(R"cpp(
 class Foo {
Index: clang-tools-extra/clangd/Selection.cpp
===
--- clang-tools-extra/clangd/Selection.cpp
+++ clang-tools-extra/clangd/Selection.cpp
@@ -443,6 +443,14 @@
   if (auto *CTI = llvm::dyn_cast(S))
 if (CTI->isImplicit())
   return true;
+  // Make sure anonymous structs don't end up owning tokens.
+  if (auto *ME = llvm::dyn_cast(S)) {
+if (auto *FD = llvm::dyn_cast(ME->getMemberDecl()))
+  if (FD->isAnonymousStructOrUnion())
+// If the base is not implicit, it can own tokens, otherwise we should
+// stop traversal.
+return isImplicit(ME->getBase());
+  }
   // Refs to operator() and [] are (almost?) always implicit as part of calls.
   if (auto *DRE = llvm::dyn_cast(S)) {
 if (auto *FD = llvm::dyn_cast(DRE->getDecl())) {


Index: clang-tools-extra/clangd/unittests/XRefsTests.cpp
===
--- clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -365,6 +365,27 @@
   ElementsAre(Sym("Forward", SymbolHeader.range("forward"), Test.range(;
 }
 
+TEST(LocateSymbol, AnonymousStructFields) {
+  auto Code = Annotations(R"cpp(
+struct $2[[Foo]] {
+  struct { int $1[[x]]; };
+  void foo() {
+// Make sure the implicit base is skipped.
+$1^x = 42;
+  }
+};
+// Check that we don't skip explicit bases.
+int a = $2^Foo{}.x;
+  )cpp");
+  TestTU TU = TestTU::withCode(Code.code());
+  auto AST = TU.build();
+  EXPECT_THAT(locateSymbolAt(AST, Code.point("1"), TU.index().get()),
+  UnorderedElementsAre(Sym("x", Code.range("1"), Code.range("1";
+  EXPECT_THAT(
+  locateSymbolAt(AST, Code.point("2"), TU.index().get()),
+  UnorderedElementsAre(Sym("Foo", Code.range("2"), Code.range("2";
+}
+
 TEST(LocateSymbol, FindOverrides) {
   auto Code = Annotations(R"cpp(
 class Foo {
Index: clang-tools-extra/clangd/Selection.cpp
===
--- clang-tools-extra/clangd/Selection.cpp
+++ clang-tools-extra/clangd/Selection.cpp
@@ -443,6 +443,14 @@
   if (auto *CTI = llvm::dyn_cast(S))
 if (CTI->isImplicit())
   return true;
+  // Make sure anonymous structs don't end up owning tokens.
+  if (auto *ME = llvm::dyn_cast(S)) {
+if (auto *FD = llvm::dyn_cast(ME->getMemberDecl()))
+  if (FD->isAnonymousStructOrUnion())
+// If the base is not implicit, it can own tokens, otherwise we should
+// stop traversal.
+return isImplicit(ME->getBase());
+  }
   // Refs to operator() and [] are (almost?) always implicit as part of calls.
   if (auto *DRE = llvm::dyn_cast(S)) {
 if (auto *FD = llvm::dyn_cast(DRE->getDecl())) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D110625: [analyzer] canonicalize special case of structure/pointer deref

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov added a comment.

I think we need to get canonical types.
Check, please, aliased types:

  struct s {
int v;
  };
  using T1 = s;
  typedef s T2;
  void foo(T1 *ps) {
T2 ss = *ps;
...
  }


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110625

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

[PATCH] D110770: [clang] Remove duplication in types::getCompilationPhases()

[Nico Weber via Phabricator via cfe-commits]

thakis added inline comments.



Comment at: clang/include/clang/Driver/Phases.h:25
 IfsMerge,
-LastPhase = IfsMerge,
   };

hans wrote:
> Any reason not to keep the LastPhase alias?
I found it more confusing than helpful. `Link` and `LastPhase` both start with 
`L` and it took me a while to realize that the last return in `getFinalPhase()` 
was `Link`, but the last one in was `getCompilationPhases()`. For the call on 
line 3847, passing phases::IfsMerge is clearer. And then there's only one use 
of it left (the default arg), and it doesn't add a ton of clarity there imho. 
But maybe I subconsciously feel vengeful because I lost 10 minutes due to 
misreading it for `Link` :) If you want me to put it back, let me know and I'll 
do so.


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

https://reviews.llvm.org/D110770

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

[PATCH] D108441: [clang] Fix JSON AST output when a filter is used

[Aaron Ballman via Phabricator via cfe-commits]

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

The changes LGTM, though I'm not an expert in python.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108441

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

[PATCH] D109517: [Clang][ARM][AArch64] Add support for Armv9-A, Armv9.1-A and Armv9.2-A

[Victor Campos via Phabricator via cfe-commits]

vhscampos updated this revision to Diff 376228.
vhscampos edited the summary of this revision.
vhscampos added a comment.

1. Disable the cryptographic extensions by default.
2. Small fix in TargetParserTest.cpp to include different spellings of the 
-march values.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109517

Files:
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Basic/Targets/AArch64.h
  clang/lib/Basic/Targets/ARM.cpp
  clang/lib/Driver/ToolChains/Arch/AArch64.cpp
  clang/test/Driver/aarch64-cpus.c
  clang/test/Driver/arm-cortex-cpus.c
  clang/test/Preprocessor/aarch64-target-features.c
  clang/test/Preprocessor/arm-target-features.c
  llvm/include/llvm/ADT/Triple.h
  llvm/include/llvm/Support/AArch64TargetParser.def
  llvm/include/llvm/Support/ARMTargetParser.def
  llvm/lib/Support/AArch64TargetParser.cpp
  llvm/lib/Support/ARMTargetParser.cpp
  llvm/lib/Support/Triple.cpp
  llvm/lib/Target/AArch64/AArch64.td
  llvm/lib/Target/AArch64/AArch64InstrInfo.td
  llvm/lib/Target/AArch64/AArch64Subtarget.h
  llvm/lib/Target/AArch64/AsmParser/AArch64AsmParser.cpp
  llvm/lib/Target/ARM/ARM.td
  llvm/lib/Target/ARM/ARMSubtarget.h
  llvm/lib/Target/ARM/MCTargetDesc/ARMELFStreamer.cpp
  llvm/test/MC/AArch64/SME/directives-negative.s
  llvm/test/MC/AArch64/SME/directives.s
  llvm/test/MC/AArch64/SVE2/directive-arch-negative.s
  llvm/test/MC/AArch64/SVE2/directive-arch.s
  llvm/unittests/Support/TargetParserTest.cpp

Index: llvm/unittests/Support/TargetParserTest.cpp
===
--- llvm/unittests/Support/TargetParserTest.cpp
+++ llvm/unittests/Support/TargetParserTest.cpp
@@ -31,6 +31,8 @@
 "armv8.5a","armv8.6-a","armv8.6a","armv8.7-a","armv8.7a",
 "armv8-r", "armv8r",   "armv8-m.base","armv8m.base",  "armv8-m.main",
 "armv8m.main", "iwmmxt",   "iwmmxt2", "xscale",   "armv8.1-m.main",
+"armv9-a", "armv9","armv9a",  "armv9.1-a","armv9.1a",
+"armv9.2-a",   "armv9.2a",
 };
 
 template 
@@ -492,6 +494,15 @@
   EXPECT_TRUE(
   testARMArch("armv8.7-a", "generic", "v8.7a",
   ARMBuildAttrs::CPUArch::v8_A));
+  EXPECT_TRUE(
+  testARMArch("armv9-a", "generic", "v9a",
+  ARMBuildAttrs::CPUArch::v8_A));
+  EXPECT_TRUE(
+  testARMArch("armv9.1-a", "generic", "v9.1a",
+  ARMBuildAttrs::CPUArch::v8_A));
+  EXPECT_TRUE(
+  testARMArch("armv9.2-a", "generic", "v9.2a",
+  ARMBuildAttrs::CPUArch::v8_A));
   EXPECT_TRUE(
   testARMArch("armv8-r", "cortex-r52", "v8r",
   ARMBuildAttrs::CPUArch::v8_R));
@@ -821,6 +832,9 @@
 case ARM::ArchKind::ARMV8_5A:
 case ARM::ArchKind::ARMV8_6A:
 case ARM::ArchKind::ARMV8_7A:
+case ARM::ArchKind::ARMV9A:
+case ARM::ArchKind::ARMV9_1A:
+case ARM::ArchKind::ARMV9_2A:
   EXPECT_EQ(ARM::ProfileKind::A, ARM::parseArchProfile(ARMArch[i]));
   break;
 default:
@@ -1204,6 +1218,12 @@
   ARMBuildAttrs::CPUArch::v8_A));
   EXPECT_TRUE(testAArch64Arch("armv8.7-a", "generic", "v8.7a",
   ARMBuildAttrs::CPUArch::v8_A));
+  EXPECT_TRUE(testAArch64Arch("armv9-a", "generic", "v9a",
+  ARMBuildAttrs::CPUArch::v8_A));
+  EXPECT_TRUE(testAArch64Arch("armv9.1-a", "generic", "v9.1a",
+  ARMBuildAttrs::CPUArch::v8_A));
+  EXPECT_TRUE(testAArch64Arch("armv9.2-a", "generic", "v9.2a",
+  ARMBuildAttrs::CPUArch::v8_A));
 }
 
 bool testAArch64Extension(StringRef CPUName, AArch64::ArchKind AK,
Index: llvm/test/MC/AArch64/SVE2/directive-arch.s
===
--- llvm/test/MC/AArch64/SVE2/directive-arch.s
+++ llvm/test/MC/AArch64/SVE2/directive-arch.s
@@ -1,21 +1,21 @@
 // RUN: llvm-mc -triple aarch64 -filetype asm -o - %s 2>&1 | FileCheck %s
 
-.arch armv8-a+sve2
+.arch armv9-a+sve2
 tbx z0.b, z1.b, z2.b
 // CHECK: tbx z0.b, z1.b, z2.b
 
-.arch armv8-a+sve2-aes
+.arch armv9-a+sve2-aes
 aesd z23.b, z23.b, z13.b
 // CHECK: aesd z23.b, z23.b, z13.b
 
-.arch armv8-a+sve2-sm4
+.arch armv9-a+sve2-sm4
 sm4e z0.s, z0.s, z0.s
 // CHECK: sm4e z0.s, z0.s, z0.s
 
-.arch armv8-a+sve2-sha3
+.arch armv9-a+sve2-sha3
 rax1 z0.d, z0.d, z0.d
 // CHECK: rax1 z0.d, z0.d, z0.d
 
-.arch armv8-a+sve2-bitperm
+.arch armv9-a+sve2-bitperm
 bgrp z21.s, z10.s, z21.s
 // CHECK: bgrp z21.s, z10.s, z21.s
Index: llvm/test/MC/AArch64/SVE2/directive-arch-negative.s
===
--- llvm/test/MC/AArch64/SVE2/directive-arch-negative.s
+++ llvm/test/MC/AArch64/SVE2/directive-arch-negative.s
@@ -1,31 +1,31 @@
 // RUN: not llvm-mc -triple aarch64 -filetype asm -o - %s 2>&1 | FileCheck %s
 
-.arch armv8-a+sve2
-.arch