[PATCH] D99675: [llvm][clang] Create new intrinsic llvm.arith.fence to control FP optimization at expression level

[Pengfei Wang via Phabricator via cfe-commits]

pengfei added inline comments.



Comment at: llvm/docs/LangRef.rst:21195
+'``llvm.arithmetic_fence``' Intrinsic
+^^
+

Should be equal to the text?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99675

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

[PATCH] D103564: [NFC][compiler-rt][hwasan] Move allocation functions into their own file

[Roland McGrath via Phabricator via cfe-commits]

mcgrathr added inline comments.



Comment at: compiler-rt/lib/hwasan/hwasan_interceptors.cpp:171
 } // namespace __hwasan
+#else   // #if !SANITIZER_FUCHSIA
+namespace __hwasan {

blank lines around `#else` and `#endif` lines.  But here I think you just omit 
this.  We can define the empty function in a fuchsia-specific file.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103564

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

[PATCH] D103750: [analyzer][WIP] Handle std::make_unique for SmartPtrModeling

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

In D103750#2804438 , @RedDocMD wrote:

> Nice. Looks like I have something to read up on. Turns out, I end up learning 
> something new in C++ every now and then.  

Yeah, it's also pretty interesting ABI-wise. As you know, C++ doesn't have 
stable ABI. That said, one popular calling convention for functions that return 
C++ objects by value consists in passing a hidden argument to the function that 
contains the address at which to construct the return value. Like "this" is an 
implicit argument to methods, the return address is yet another implicit 
argument. So you can think of `getReturnValueUnderConstruction()` as of an 
accessor for that implicit argument value similarly to how `getCXXThisVal()` is 
the accessor for the implicit this-argument value.

This is completely different from C where you can return the structure on stack 
or even in registers (which can't be pointed to at all); this becomes possible 
in C because structures can be copied arbitrarily without invoking any sort of 
copy constructor.



Random general advice! When writing patches, you typically explore the design 
space of potential solutions - which you did great in this case. When you do 
so, it's a great idea to include the results of such exploration in the commit 
message (and/or in later comments). Especially if the first / most obvious 
thing to try didn't work. If you publish your second-choice solution, people 
will most likely ask you why you chose it instead of the obvious first-choice 
solution so it's an act of friendliness to anticipate this question. Similarly, 
if you have concerns about your solution, please communicate them openly; 
they'll either be discovered anyway but a lot more effort will be spent on it, 
or they won't be discovered during review which could result in future 
problems; both variants are worse than communicating openly. Ideally you carry 
more responsibility for proving that your approach is right than the reviewer 
has a responsibility to find problems in it. The reviewer is the last line of 
defense when it comes to applying critical thinking but the process really 
starts with you as you challenge your own assumptions and approaches by 
questioning both their correctness and their architectural harmony. Trying to 
find at least two solutions to each problem and compare them against each other 
is such a good exercise in critical thinking that almost every patch deserves 
such discussion.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103750

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

[PATCH] D103845: [compiler-rt][hwasan] Add newline between record_addr lines on frame record dumps

[Vitaly Buka via Phabricator via cfe-commits]

vitalybuka added a comment.

In D103845#2804441 , @pcc wrote:

> This isn't how the output looks on Android. Are you sure this isn't a 
> Fuchsia-specific bug in the output formatting?

I don't see from the code how android can insert \n if SymbolizePC failed


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103845

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

[PATCH] D103845: [compiler-rt][hwasan] Add newline between record_addr lines on frame record dumps

[Peter Collingbourne via Phabricator via cfe-commits]

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

This isn't how the output looks on Android. Are you sure this isn't a 
Fuchsia-specific bug in the output formatting?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103845

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

[PATCH] D103750: [analyzer][WIP] Handle std::make_unique for SmartPtrModeling

[Deep Majumder via Phabricator via cfe-commits]

RedDocMD added a comment.

Nice. Looks like I have something to read up on. Turns out, I end up learning 
something new in C++ every now and then.  


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103750

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

[PATCH] D103605: [analyzer] Introduce a new interface for tracking

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

In D103605#2802240 , @vsavchenko 
wrote:

> In D103605#2801681 , @NoQ wrote:
>
>> 
>
> OK, let's make a pause right here.  We again start to go into other topics.

These are not other topics. We're discussing the overall direction into which 
this patchset is a large step. I absolutely welcome this step and am fascinated 
to see how it turns out but I want us to agree on the overall direction first.

> You come from a pure perspective that `track` explains how the value got here 
> and does only that.  In this picture of the world, `track` has one starting 
> point and one ending point.  If it ends to early (due to the lack of domain 
> knowledge), the checker can pick up and restart the tracking if needed.  If 
> it ends for real, this is the earliest where we got this value from and it 
> can tell us about the warning and situation we are in.  The problem is that 
> tracking is fundamentally **dirty** the way it is.  It is not linear, and 
> when we track one simple value, it actually spawns a gigantic tree of traces. 
>  Thus when we get to the point where it all ended, it actually ended 100 
> times.  It ended in multiple different visitors that were tracking all kinds 
> of things not limited to the value itself.  `trackExpressionValue` is hard 
> also because of this reason.  Inline defensive checks don't belong there and 
> clutter it.
>
> I DON'T KNOW how to simplify this ATM.  Probably we can decouple ONE VALUE 
> TRACKING from the rest of it, but it's not what I'm trying to do.  I want to 
> refactor the existing solution (with all of its inherent design flaws) into 
> something more extensible.  And I think that again ATM, with the current 
> state of things, the concept of "tracking stopped here" is doomed.

The reason why I come from this perspective is because that's how I think it is 
//supposed// to work and I'm not aware of a single good reason why it can't. I 
think the reason why it's this way is that the original authors seem to have 
bombarded the code with extra clauses until it starts demonstrating the more or 
less expected behavior, without trying to solve the problem on paper first. 
Like with visitor fixpoint iteration, it sounds like an unnecessary piece of 
complexity that we will be ultimately able to eliminate.

Except, well, the distant constraints example a-la @RedDocMD's problem but for 
raw pointers. This is indeed an exceptional case which may cause two tracking 
efforts to run in parallel. This can be probably generalized to any 
constraint-like traits: if we want to explain a constraint, we'll have to be 
prepared that the constraint isn't part of the value track that we already 
have. This is the first time the above assumption was challenged and I 
definitely need time to process this but I still think there shouldn't be any 
other situations like this and there should be something special about this 
situation that will allow us to incorporate it into the linear-track solution.

"At the moment such refactoring is difficult to achieve" is a perfectly 
satisfying answer to me with respect to the current state of things. But I want 
us to agree as early as possible about whether we want to achieve this. Simply 
so that as we make every step, we keep this in mind and evaluate every step as 
taking us either closer to this goal or farther from this goal and try to avoid 
the latter. And I don't think that anything prevents us from discussing this 
goal right now; the problem we're trying to solve isn't really ever going to 
change and we already have a fairly large amount of data.

> With the new solution, if you want the most simple ways of addressing it, you 
> create a handler:
>
>   class FooHandler : public ExpressionHandler {
>   public:
> using ExpressionHandler::ExpressionHandler;
>   
> Tracker::Result handle(const Expr *E, const ExplodedNode *InputNode,
>const ExplodedNode *ExprNode,
>TrackingOptions Opts) {
>   if (auto *Arg = getFooArgument(E)) {
> return getParentTracker().track(E, ExprNode, Opts);
>   }
>   return {};
>   };
>
> Essentially these handlers is my way of first introducing new logic for these 
> two checkers, and second to extract similar logic that exists there from all 
> other checkers.

Ok, do I understand correctly that:

- Functionality-wise, this is entirely equivalent to my NoteTag solution with 
"`isTracked()`";
- Boilerplate-wise it makes the `isTracked()` check implicit ("we were invoked 
at all therefore the value of the expression is tracked by... somebody") at the 
cost of asking the user to define a class;
- Convenience-wise, it potentially requires the developer to reverse-engineer 
the symbolic execution step when the logic gets more complicated;
- Flexibility-wise... I guess you can make custom trackers now, which will 
track the value in 

[clang] f38eff7 - [AIX] Define __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__

[Chris Bowler via cfe-commits]

Author: Jake.Egan
Date: 2021-06-07T22:45:41-04:00
New Revision: f38eff777e46f42884d82815d0b39766520ac2bf

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

LOG: [AIX] Define __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__

Revert/reapply to fix Git authorship metadata

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

Added: 


Modified: 
clang/lib/Basic/Targets/OSTargets.h
clang/test/Preprocessor/init-ppc.c

Removed: 




diff  --git a/clang/lib/Basic/Targets/OSTargets.h 
b/clang/lib/Basic/Targets/OSTargets.h
index cecac1cec172a..6e4e6f0aafe40 100644
--- a/clang/lib/Basic/Targets/OSTargets.h
+++ b/clang/lib/Basic/Targets/OSTargets.h
@@ -676,6 +676,11 @@ class AIXTargetInfo : public OSTargetInfo {
 
 Builder.defineMacro("_AIX");
 
+if (LangStandard::getLangStandardForKind(Opts.LangStd).isC11()) {
+  Builder.defineMacro("__STDC_NO_ATOMICS__");
+  Builder.defineMacro("__STDC_NO_THREADS__");
+}
+
 if (Opts.EnableAIXExtendedAltivecABI)
   Builder.defineMacro("__EXTABI__");
 

diff  --git a/clang/test/Preprocessor/init-ppc.c 
b/clang/test/Preprocessor/init-ppc.c
index aa0f8c97de126..5301c7e3f59df 100644
--- a/clang/test/Preprocessor/init-ppc.c
+++ b/clang/test/Preprocessor/init-ppc.c
@@ -723,6 +723,16 @@
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc-ibm-aix7.1.0.0 
-fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix 
PPC-AIX-NOTHREADSAFE %s
 // PPC-AIX-NOTHREADSAFE-NOT:#define _THREAD_SAFE 1
 
+// RUN: %clang_cc1 -x c -std=c11 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=gnu11 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=c17 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// PPC-AIX-STDC:#define __STDC_NO_ATOMICS__ 1
+// PPC-AIX-STDC:#define __STDC_NO_THREADS__ 1
+
+// RUN: %clang_cc1 -x c -std=c99 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC-N %s
+// PPC-AIX-STDC-N-NOT:#define __STDC_NO_ATOMICS__ 1
+// PPC-AIX-STDC-N-NOT:#define __STDC_NO_THREADS__ 1
+
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc-unknown-linux-gnu 
-fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix 
PPC-LINUX %s
 //
 // PPC-LINUX:#define _ARCH_PPC 1



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

[clang] f97e01e - Revert "[AIX] Define __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__ predefined macros"

[Chris Bowler via cfe-commits]

Author: Chris Bowler
Date: 2021-06-07T22:45:41-04:00
New Revision: f97e01e61af1115bb9cb68dbdc70cc7f9f884759

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

LOG: Revert "[AIX] Define __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__ 
predefined macros"

This reverts commit e6629be31e67190f0a524f009752d73410894560.

Added: 


Modified: 
clang/lib/Basic/Targets/OSTargets.h
clang/test/Preprocessor/init-ppc.c

Removed: 




diff  --git a/clang/lib/Basic/Targets/OSTargets.h 
b/clang/lib/Basic/Targets/OSTargets.h
index 6e4e6f0aafe40..cecac1cec172a 100644
--- a/clang/lib/Basic/Targets/OSTargets.h
+++ b/clang/lib/Basic/Targets/OSTargets.h
@@ -676,11 +676,6 @@ class AIXTargetInfo : public OSTargetInfo {
 
 Builder.defineMacro("_AIX");
 
-if (LangStandard::getLangStandardForKind(Opts.LangStd).isC11()) {
-  Builder.defineMacro("__STDC_NO_ATOMICS__");
-  Builder.defineMacro("__STDC_NO_THREADS__");
-}
-
 if (Opts.EnableAIXExtendedAltivecABI)
   Builder.defineMacro("__EXTABI__");
 

diff  --git a/clang/test/Preprocessor/init-ppc.c 
b/clang/test/Preprocessor/init-ppc.c
index 5301c7e3f59df..aa0f8c97de126 100644
--- a/clang/test/Preprocessor/init-ppc.c
+++ b/clang/test/Preprocessor/init-ppc.c
@@ -723,16 +723,6 @@
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc-ibm-aix7.1.0.0 
-fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix 
PPC-AIX-NOTHREADSAFE %s
 // PPC-AIX-NOTHREADSAFE-NOT:#define _THREAD_SAFE 1
 
-// RUN: %clang_cc1 -x c -std=c11 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
-// RUN: %clang_cc1 -x c -std=gnu11 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
-// RUN: %clang_cc1 -x c -std=c17 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
-// PPC-AIX-STDC:#define __STDC_NO_ATOMICS__ 1
-// PPC-AIX-STDC:#define __STDC_NO_THREADS__ 1
-
-// RUN: %clang_cc1 -x c -std=c99 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC-N %s
-// PPC-AIX-STDC-N-NOT:#define __STDC_NO_ATOMICS__ 1
-// PPC-AIX-STDC-N-NOT:#define __STDC_NO_THREADS__ 1
-
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc-unknown-linux-gnu 
-fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix 
PPC-LINUX %s
 //
 // PPC-LINUX:#define _ARCH_PPC 1



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

[PATCH] D103707: [AIX] Define __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__ predefined macros

[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 rGe6629be31e67: [AIX] Define __STDC_NO_ATOMICS__ and 
__STDC_NO_THREADS__ predefined macros (authored by Jake-Egan, committed by 
cbowler cbow...@pcoral03.rtp.raleigh.ibm.com).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103707

Files:
  clang/lib/Basic/Targets/OSTargets.h
  clang/test/Preprocessor/init-ppc.c


Index: clang/test/Preprocessor/init-ppc.c
===
--- clang/test/Preprocessor/init-ppc.c
+++ clang/test/Preprocessor/init-ppc.c
@@ -723,6 +723,16 @@
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc-ibm-aix7.1.0.0 
-fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix 
PPC-AIX-NOTHREADSAFE %s
 // PPC-AIX-NOTHREADSAFE-NOT:#define _THREAD_SAFE 1
 
+// RUN: %clang_cc1 -x c -std=c11 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=gnu11 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=c17 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// PPC-AIX-STDC:#define __STDC_NO_ATOMICS__ 1
+// PPC-AIX-STDC:#define __STDC_NO_THREADS__ 1
+
+// RUN: %clang_cc1 -x c -std=c99 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC-N %s
+// PPC-AIX-STDC-N-NOT:#define __STDC_NO_ATOMICS__ 1
+// PPC-AIX-STDC-N-NOT:#define __STDC_NO_THREADS__ 1
+
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc-unknown-linux-gnu 
-fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix 
PPC-LINUX %s
 //
 // PPC-LINUX:#define _ARCH_PPC 1
Index: clang/lib/Basic/Targets/OSTargets.h
===
--- clang/lib/Basic/Targets/OSTargets.h
+++ clang/lib/Basic/Targets/OSTargets.h
@@ -676,6 +676,11 @@
 
 Builder.defineMacro("_AIX");
 
+if (LangStandard::getLangStandardForKind(Opts.LangStd).isC11()) {
+  Builder.defineMacro("__STDC_NO_ATOMICS__");
+  Builder.defineMacro("__STDC_NO_THREADS__");
+}
+
 if (Opts.EnableAIXExtendedAltivecABI)
   Builder.defineMacro("__EXTABI__");
 


Index: clang/test/Preprocessor/init-ppc.c
===
--- clang/test/Preprocessor/init-ppc.c
+++ clang/test/Preprocessor/init-ppc.c
@@ -723,6 +723,16 @@
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix PPC-AIX-NOTHREADSAFE %s
 // PPC-AIX-NOTHREADSAFE-NOT:#define _THREAD_SAFE 1
 
+// RUN: %clang_cc1 -x c -std=c11 -E -dM -ffreestanding -triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=gnu11 -E -dM -ffreestanding -triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=c17 -E -dM -ffreestanding -triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix PPC-AIX-STDC %s
+// PPC-AIX-STDC:#define __STDC_NO_ATOMICS__ 1
+// PPC-AIX-STDC:#define __STDC_NO_THREADS__ 1
+
+// RUN: %clang_cc1 -x c -std=c99 -E -dM -ffreestanding -triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix PPC-AIX-STDC-N %s
+// PPC-AIX-STDC-N-NOT:#define __STDC_NO_ATOMICS__ 1
+// PPC-AIX-STDC-N-NOT:#define __STDC_NO_THREADS__ 1
+
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc-unknown-linux-gnu -fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix PPC-LINUX %s
 //
 // PPC-LINUX:#define _ARCH_PPC 1
Index: clang/lib/Basic/Targets/OSTargets.h
===
--- clang/lib/Basic/Targets/OSTargets.h
+++ clang/lib/Basic/Targets/OSTargets.h
@@ -676,6 +676,11 @@
 
 Builder.defineMacro("_AIX");
 
+if (LangStandard::getLangStandardForKind(Opts.LangStd).isC11()) {
+  Builder.defineMacro("__STDC_NO_ATOMICS__");
+  Builder.defineMacro("__STDC_NO_THREADS__");
+}
+
 if (Opts.EnableAIXExtendedAltivecABI)
   Builder.defineMacro("__EXTABI__");
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] e6629be - [AIX] Define __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__ predefined macros

[via cfe-commits]

Author: =Jake Egan
Date: 2021-06-07T22:04:18-04:00
New Revision: e6629be31e67190f0a524f009752d73410894560

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

LOG: [AIX] Define __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__ predefined macros

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

Added: 


Modified: 
clang/lib/Basic/Targets/OSTargets.h
clang/test/Preprocessor/init-ppc.c

Removed: 




diff  --git a/clang/lib/Basic/Targets/OSTargets.h 
b/clang/lib/Basic/Targets/OSTargets.h
index cecac1cec172a..6e4e6f0aafe40 100644
--- a/clang/lib/Basic/Targets/OSTargets.h
+++ b/clang/lib/Basic/Targets/OSTargets.h
@@ -676,6 +676,11 @@ class AIXTargetInfo : public OSTargetInfo {
 
 Builder.defineMacro("_AIX");
 
+if (LangStandard::getLangStandardForKind(Opts.LangStd).isC11()) {
+  Builder.defineMacro("__STDC_NO_ATOMICS__");
+  Builder.defineMacro("__STDC_NO_THREADS__");
+}
+
 if (Opts.EnableAIXExtendedAltivecABI)
   Builder.defineMacro("__EXTABI__");
 

diff  --git a/clang/test/Preprocessor/init-ppc.c 
b/clang/test/Preprocessor/init-ppc.c
index aa0f8c97de126..5301c7e3f59df 100644
--- a/clang/test/Preprocessor/init-ppc.c
+++ b/clang/test/Preprocessor/init-ppc.c
@@ -723,6 +723,16 @@
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc-ibm-aix7.1.0.0 
-fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix 
PPC-AIX-NOTHREADSAFE %s
 // PPC-AIX-NOTHREADSAFE-NOT:#define _THREAD_SAFE 1
 
+// RUN: %clang_cc1 -x c -std=c11 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=gnu11 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=c17 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// PPC-AIX-STDC:#define __STDC_NO_ATOMICS__ 1
+// PPC-AIX-STDC:#define __STDC_NO_THREADS__ 1
+
+// RUN: %clang_cc1 -x c -std=c99 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC-N %s
+// PPC-AIX-STDC-N-NOT:#define __STDC_NO_ATOMICS__ 1
+// PPC-AIX-STDC-N-NOT:#define __STDC_NO_THREADS__ 1
+
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc-unknown-linux-gnu 
-fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix 
PPC-LINUX %s
 //
 // PPC-LINUX:#define _ARCH_PPC 1



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

[PATCH] D103792: [clang][AST] Set correct DeclContext in ASTImporter lookup table for template params.

[Shafik Yaghmour via Phabricator via cfe-commits]

shafik added inline comments.



Comment at: clang/lib/AST/ASTImporter.cpp:6005
 
+  // Template parameters for a CXXDeductionGuideDecl are re-used by the
+  // non-deduction-guide-decl template. That template is imported too, and

Is this case covered in the tests?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103792

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

[PATCH] D103707: [AIX] Define __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__ predefined macros

[Chris Bowler via Phabricator via cfe-commits]

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

LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103707

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

[PATCH] D103850: [clang] diagnose instead of assert for defaulted comparison return type deduction.

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added inline comments.



Comment at: clang/lib/Sema/SemaDeclCXX.cpp:7876
+  diag::
+  
err_defaulted_comparison_cannot_deduce_unsupported_builtin_type)
+  << Subobj.Kind << Subobj.Decl << T;

I think this should be an error because otherwise we would be accepting and 
giving this program a different semantic just because of some not-implemented 
feature.
But I can see the downside that we could potentially reject a program which is 
not affected by the operator being implicitly deleted.

Thoughts?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103850

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

[PATCH] D103495: [static initializers] Don't put ordered dynamic initializers of static variables into global_ctors

[Eli Friedman via Phabricator via cfe-commits]

efriedma added a comment.

Are there any existing optimizations that might be affected by this?  In 
particular, I think GlobalOpt implicitly reorders functions in global_ctors.


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

https://reviews.llvm.org/D103495

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

[PATCH] D103184: [AArch64] handle -Wa,-march=

[Jian Cai via Phabricator via cfe-commits]

jcai19 added a comment.

In D103184#2803768 , @thakis wrote:

> FWIW the failure goes away locally if I revert this change here, so it's 
> definitely due to this change here.
>
> Things have been red for a while, probably good to revert while you 
> investigate by this point.

Okay, will revert it shortly if i can't find a fix soon. Sorry for the delay, i 
just finished

In D103184#2803768 , @thakis wrote:

> FWIW the failure goes away locally if I revert this change here, so it's 
> definitely due to this change here.
>
> Things have been red for a while, probably good to revert while you 
> investigate by this point.

I just pushed a revert. Sorry for the delay, my macbook had some issues 
building LLVM so had to fix them first.

In D103184#2803768 , @thakis wrote:

> FWIW the failure goes away locally if I revert this change here, so it's 
> definitely due to this change here.
>
> Things have been red for a while, probably good to revert while you 
> investigate by this point.

Sorry for the delay but my macbook had some issues so I just finished building 
LLVM, but I can't seem to reproduce this issue locally (neither running the 
test directly with llvm-lit nor `ninja check-clang`). In fact I don't quite 
understand why this failure happened.  Like @nickdesaulniers mentioned the 
build failure should have been fixed in 
https://reviews.llvm.org/rG76d9bc72784d88f4dd57b9939e52c73739438af5 for a 
different patch. Do you mind sharing the instructions you used to reproduce the 
test failure? Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103184

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

[PATCH] D103855: [clang] Exclude function pointers on DefaultedComparisonAnalyzer

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov created this revision.
Herald added subscribers: manas, steakhal, ASDenysPetrov, dkrupp, donat.nagy, 
Szelethus, a.sidorin, baloghadamsoftware.
mizvekov requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This implements a more comprehensive fix than was done at D95409 
.
Instead of excluding just function pointer subobjects, we also
exclude any user-defined function pointer conversion operators.

Signed-off-by: Matheus Izvekov 

Depends on D103850 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D103855

Files:
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/test/CXX/class/class.compare/class.spaceship/p2.cpp

Index: clang/test/CXX/class/class.compare/class.spaceship/p2.cpp
===
--- clang/test/CXX/class/class.compare/class.spaceship/p2.cpp
+++ clang/test/CXX/class/class.compare/class.spaceship/p2.cpp
@@ -197,8 +197,7 @@
 operator fp() const;
   };
   struct b3 {
-auto operator<=>(b3 const &) const = default; // expected-error {{cannot be deduced because three-way comparison for member 'f' would compare as builtin type 'void (*)()' which is not currently supported}}
-// expected-warning@-1 {{implicitly deleted}}
-a3 f;
+auto operator<=>(b3 const &) const = default; // expected-warning {{implicitly deleted}}
+a3 f; // expected-note {{because there is no viable three-way comparison function for member 'f'}}
   };
 }
Index: clang/lib/Sema/SemaOverload.cpp
===
--- clang/lib/Sema/SemaOverload.cpp
+++ clang/lib/Sema/SemaOverload.cpp
@@ -7834,10 +7834,10 @@
   SemaRef(SemaRef),
   Context(SemaRef.Context) { }
 
-  void AddTypesConvertedFrom(QualType Ty,
- SourceLocation Loc,
+  void AddTypesConvertedFrom(QualType Ty, SourceLocation Loc,
  bool AllowUserConversions,
  bool AllowExplicitConversions,
+ bool DisallowNonRelationalComparableTypes,
  const Qualifiers );
 
   llvm::iterator_range pointer_types() { return PointerTypes; }
@@ -7974,15 +7974,14 @@
 /// primarily interested in pointer types and enumeration types. We also
 /// take member pointer types, for the conditional operator.
 /// AllowUserConversions is true if we should look at the conversion
-/// functions of a class type, and AllowExplicitConversions if we
+/// functions of a class type, AllowExplicitConversions if we
 /// should also include the explicit conversion functions of a class
-/// type.
-void
-BuiltinCandidateTypeSet::AddTypesConvertedFrom(QualType Ty,
-   SourceLocation Loc,
-   bool AllowUserConversions,
-   bool AllowExplicitConversions,
-   const Qualifiers ) {
+/// type, and DisallowNonRelationalComparableTypes if we should exclude types
+/// which cannot be compared with relational operators.
+void BuiltinCandidateTypeSet::AddTypesConvertedFrom(
+QualType Ty, SourceLocation Loc, bool AllowUserConversions,
+bool AllowExplicitConversions, bool DisallowNonRelationalComparableTypes,
+const Qualifiers ) {
   // Only deal with canonical types.
   Ty = Context.getCanonicalType(Ty);
 
@@ -8009,6 +8008,10 @@
   if (Ty->isObjCIdType() || Ty->isObjCClassType())
 PointerTypes.insert(Ty);
   else if (Ty->getAs() || Ty->getAs()) {
+// The builtin operator for relational comparisons on function pointers
+// is the only known case which cannot be used for three-way comparisons.
+if (DisallowNonRelationalComparableTypes && Ty->isFunctionPointerType())
+  return;
 // Insert our type, and its more-qualified variants, into the set
 // of types.
 if (!AddPointerWithMoreQualifiedTypeVariants(Ty, VisibleQuals))
@@ -8050,6 +8053,7 @@
   CXXConversionDecl *Conv = cast(D);
   if (AllowExplicitConversions || !Conv->isExplicit()) {
 AddTypesConvertedFrom(Conv->getConversionType(), Loc, false, false,
+  DisallowNonRelationalComparableTypes,
   VisibleQuals);
   }
 }
@@ -9132,13 +9136,10 @@
   SmallVector CandidateTypes;
   for (unsigned ArgIdx = 0, N = Args.size(); ArgIdx != N; ++ArgIdx) {
 CandidateTypes.emplace_back(*this);
-CandidateTypes[ArgIdx].AddTypesConvertedFrom(Args[ArgIdx]->getType(),
- OpLoc,
- true,
- (Op == OO_Exclaim ||
-  Op == OO_AmpAmp ||
-

[PATCH] D103745: [dfsan] Add full fast8 support

[George Balatsouras via Phabricator via cfe-commits]

gbalats added inline comments.



Comment at: llvm/test/Instrumentation/DataFlowSanitizer/external_mask.ll:6
 define i32 @test(i32 %a, i32* nocapture readonly %b) #0 {
-; CHECK: @"dfs$test"
-; CHECK: %[[RV:.*]] load{{.*}}__dfsan_shadow_ptr_mask
-; CHECK: ptrtoint i32* {{.*}} to i64
-; CHECK: and {{.*}}%[[RV:.*]]
-; CHECK16: mul i64
+  ; CHECK: @"dfs$test"
+  ; CHECK: %[[RV:.*]] load{{.*}}__dfsan_shadow_ptr_mask

browneee wrote:
> Fix whitespace
Acknowledged. Not a tab; just how phabricator indicates whitespace changes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103745

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

[PATCH] D103745: [dfsan] Add full fast8 support

[Andrew via Phabricator via cfe-commits]

browneee accepted this revision.
browneee added inline comments.



Comment at: llvm/test/Instrumentation/DataFlowSanitizer/external_mask.ll:6
 define i32 @test(i32 %a, i32* nocapture readonly %b) #0 {
-; CHECK: @"dfs$test"
-; CHECK: %[[RV:.*]] load{{.*}}__dfsan_shadow_ptr_mask
-; CHECK: ptrtoint i32* {{.*}} to i64
-; CHECK: and {{.*}}%[[RV:.*]]
-; CHECK16: mul i64
+  ; CHECK: @"dfs$test"
+  ; CHECK: %[[RV:.*]] load{{.*}}__dfsan_shadow_ptr_mask

Fix whitespace



Comment at: llvm/test/Instrumentation/DataFlowSanitizer/load.ll:99
+  ; CHECK-NEXT:ret i64 %a
+  
   %a = load i64, i64* %p

Fix whitespace


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103745

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

[PATCH] D103048: [IR] make -stack-alignment= into a module attr

[Nick Desaulniers via Phabricator via cfe-commits]

nickdesaulniers updated this revision to Diff 350443.
nickdesaulniers added a comment.

- remove test for module without module attr


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103048

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/CodeGen/stackrealign-main.c
  llvm/include/llvm/IR/Module.h
  llvm/include/llvm/Target/TargetOptions.h
  llvm/lib/CodeGen/CommandFlags.cpp
  llvm/lib/IR/Module.cpp
  llvm/lib/Target/X86/X86TargetMachine.cpp
  llvm/test/CodeGen/Generic/ForceStackAlign.ll
  llvm/test/CodeGen/X86/base-pointer-and-cmpxchg.ll
  llvm/test/CodeGen/X86/base-pointer-and-mwaitx.ll
  llvm/test/CodeGen/X86/dynamic-allocas-VLAs-stack-align.ll
  llvm/test/CodeGen/X86/dynamic-allocas-VLAs.ll
  llvm/test/CodeGen/X86/force-align-stack-alloca.ll
  llvm/test/CodeGen/X86/hipe-cc.ll
  llvm/test/CodeGen/X86/hipe-cc64.ll
  llvm/test/CodeGen/X86/movtopush-stack-align.ll
  llvm/test/CodeGen/X86/movtopush.ll
  llvm/test/CodeGen/X86/pr11468.ll
  llvm/test/CodeGen/X86/unaligned-spill-folding.ll
  llvm/test/CodeGen/X86/x86-64-baseptr.ll
  llvm/test/CodeGen/X86/x86-64-xmm-spill-unaligned.ll
  llvm/test/Linker/stack-alignment.ll

Index: llvm/test/Linker/stack-alignment.ll
===
--- /dev/null
+++ llvm/test/Linker/stack-alignment.ll
@@ -0,0 +1,15 @@
+; RUN: split-file %s %t
+; RUN: llvm-link %t/main.ll %t/8.ll
+; RUN: not llvm-link %t/main.ll %t/16.ll 2>&1 | FileCheck --check-prefix=CHECK-16 %s
+
+;--- main.ll
+; NONE: error: linking module flags 'override-stack-alignment': IDs have conflicting values
+; CHECK-16: error: linking module flags 'override-stack-alignment': IDs have conflicting values
+!llvm.module.flags = !{!0}
+!0 = !{i32 1, !"override-stack-alignment", i32 8}
+;--- 8.ll
+!llvm.module.flags = !{!0}
+!0 = !{i32 1, !"override-stack-alignment", i32 8}
+;--- 16.ll
+!llvm.module.flags = !{!0}
+!0 = !{i32 1, !"override-stack-alignment", i32 16}
Index: llvm/test/CodeGen/X86/x86-64-xmm-spill-unaligned.ll
===
--- llvm/test/CodeGen/X86/x86-64-xmm-spill-unaligned.ll
+++ llvm/test/CodeGen/X86/x86-64-xmm-spill-unaligned.ll
@@ -2,7 +2,7 @@
 ; elements (here: XMM spills) are accessed using instructions that tolerate
 ; unaligned access.
 ;
-; RUN: llc -mtriple=x86_64-unknown-linux-gnu -mcpu=x86-64 -mattr=+sse,+sse-unaligned-mem -stack-alignment=8 --frame-pointer=all < %s | FileCheck %s
+; RUN: llc -mtriple=x86_64-unknown-linux-gnu -mcpu=x86-64 -mattr=+sse,+sse-unaligned-mem --frame-pointer=all < %s | FileCheck %s
 
 define dso_local preserve_allcc void @func() #0 {
 ; CHECK-LABEL: func:
@@ -13,3 +13,5 @@
 }
 
 attributes #0 = { nounwind }
+!llvm.module.flags = !{!0}
+!0 = !{i32 2, !"override-stack-alignment", i32 8}
Index: llvm/test/CodeGen/X86/x86-64-baseptr.ll
===
--- llvm/test/CodeGen/X86/x86-64-baseptr.ll
+++ llvm/test/CodeGen/X86/x86-64-baseptr.ll
@@ -1,6 +1,6 @@
 ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
-; RUN: llc -mtriple=x86_64-pc-linux -stackrealign -stack-alignment=32 < %s | FileCheck %s
-; RUN: llc -mtriple=x86_64-pc-linux-gnux32 -stackrealign -stack-alignment=32 < %s | FileCheck -check-prefix=X32ABI %s
+; RUN: llc -mtriple=x86_64-pc-linux -stackrealign < %s | FileCheck %s
+; RUN: llc -mtriple=x86_64-pc-linux-gnux32 -stackrealign < %s | FileCheck -check-prefix=X32ABI %s
 
 ; This should run with NaCl as well ( -mtriple=x86_64-pc-nacl ) but currently doesn't due to PR22655
 
@@ -65,3 +65,5 @@
 }
 
 attributes #0 = { nounwind "frame-pointer"="all"}
+!llvm.module.flags = !{!0}
+!0 = !{i32 2, !"override-stack-alignment", i32 32}
Index: llvm/test/CodeGen/X86/unaligned-spill-folding.ll
===
--- llvm/test/CodeGen/X86/unaligned-spill-folding.ll
+++ llvm/test/CodeGen/X86/unaligned-spill-folding.ll
@@ -1,7 +1,11 @@
-; RUN: llc -mtriple=i386-unknown-freebsd -mcpu=core2 -stack-alignment=4 -relocation-model=pic < %s | FileCheck %s -check-prefix=UNALIGNED
-; RUN: llc -mtriple=i386-unknown-freebsd -mcpu=core2 -stack-alignment=16 -relocation-model=pic < %s | FileCheck %s -check-prefix=ALIGNED
-; RUN: llc -mtriple=i386-unknown-freebsd -mcpu=core2 -stack-alignment=4 -stackrealign -relocation-model=pic < %s | FileCheck %s -check-prefix=FORCEALIGNED
+; RUN: split-file %s %t
+; RUN: cat %t/main.ll %t/align4.ll > %t/a2.ll
+; RUN: cat %t/main.ll %t/align16.ll > %t/b2.ll
+; RUN: llc -mtriple=i386-unknown-freebsd -mcpu=core2 -relocation-model=pic < %t/a2.ll | FileCheck %s -check-prefix=UNALIGNED
+; RUN: llc -mtriple=i386-unknown-freebsd -mcpu=core2 -relocation-model=pic < %t/b2.ll | FileCheck %s -check-prefix=ALIGNED
+; RUN: llc -mtriple=i386-unknown-freebsd -mcpu=core2 -stackrealign -relocation-model=pic < %t/a2.ll | 

[PATCH] D103851: [IR] make a new ModFlagBehavior that errors when a module attribute is missing

[Nick Desaulniers via Phabricator via cfe-commits]

nickdesaulniers added a comment.

See also: https://reviews.llvm.org/D103048#2804089


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103851

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

[PATCH] D103048: [IR] make -stack-alignment= into a module attr

[Nick Desaulniers via Phabricator via cfe-commits]

nickdesaulniers added inline comments.



Comment at: llvm/test/Linker/stack-alignment.ll:11
+;--- main.ll
+; NONE: error: linking module flags 'override-stack-alignment': IDs have 
conflicting values
+; CHECK-16: error: linking module flags 'override-stack-alignment': IDs have 
conflicting values

tejohnson wrote:
> Will you get this error currently? I thought per comment and behavior of 
> Error that it shouldn't give an error.
the `RUN` line for that check is missing the `:`, so it's not actually run.  I 
think I'll create the new `ModFlagBehavior` as a child revision to this commit, 
in which I add the new behavior and upgrade this attribute to use it, adding in 
this unit test.

---

Now that I've had time to play with implementing such a `ModFlagBehavior`; it 
looks like it's not possible to create a module with such semantics then test 
it properly with `llvm-link`.  The reason is that `llvm-link` is structured to 
start with an empty module ("Composite"), then link in the first module 
specified on the command line, then link in the rest of the modules specified.  
So we can't disambiguate between the initial empty module being linked against 
the initial source file with the MDNode vs 2 full modules where 1 is missing 
the MD node.  (ie. for two input source files, the main module linking logic is 
run twice, not once).

See: https://reviews.llvm.org/D103851

---

In that case, I just plan to remove this test case then, since it wasn't being 
`RUN` anyways.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103048

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

[PATCH] D103851: [IR] make a new ModFlagBehavior that errors when a module attribute is missing

[Nick Desaulniers via Phabricator via cfe-commits]

nickdesaulniers abandoned this revision.
nickdesaulniers added a comment.

Not planning on shipping this, just a demonstration.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103851

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

[PATCH] D103851: [IR] make a new ModFlagBehavior that errors when a module attribute is missing

[Nick Desaulniers via Phabricator via cfe-commits]

nickdesaulniers created this revision.
Herald added a reviewer: deadalnix.
Herald added subscribers: dexonsmith, hiraditya.
nickdesaulniers requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

Promote override-stack-alignment to use it.

The problem with this approach is:
it looks like it's not possible to create a module with such semantics
then test it properly with `llvm-link`.  The reason is that `llvm-link`
is structured to start with an empty module ("Composite"), then link in
the first module specified on the command line, then link in the rest of
the modules specified.  So we can't disambiguate between the initial
empty module being linked against the initial source file with the
MDNode vs 2 full modules where 1 is missing the MD node.  (ie. for two
input source files, the main module linking logic is run twice, not
once).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D103851

Files:
  clang/test/CodeGen/stackrealign-main.c
  llvm/include/llvm-c/Core.h
  llvm/include/llvm/IR/Module.h
  llvm/lib/IR/Core.cpp
  llvm/lib/IR/Module.cpp
  llvm/lib/IR/Verifier.cpp
  llvm/lib/Linker/IRMover.cpp
  llvm/test/Linker/stack-alignment.ll

Index: llvm/test/Linker/stack-alignment.ll
===
--- llvm/test/Linker/stack-alignment.ll
+++ llvm/test/Linker/stack-alignment.ll
@@ -1,22 +1,19 @@
 ; RUN: split-file %s %t
-; TODO: it seems that ModFlagBehavior::Error doesn't error when a module is
-;   missing a module level attribute. IRLinker::linkModuleFlagsMetadata
-;   seems to think this is ok. Debugging stack mismatch errors is not a fun
-;   time.
-; RUN not llvm-link %t/main.ll %t/none.ll 2>&1 | FileCheck --check-prefix=NONE %s
+; RUN: not llvm-link %t/main.ll %t/none.ll 2>&1 | FileCheck --check-prefix=NONE %s
+; RUN: not llvm-link %t/none.ll %t/main.ll 2>&1 | FileCheck --check-prefix=NONE %s
 ; RUN: llvm-link %t/main.ll %t/8.ll
 ; RUN: not llvm-link %t/main.ll %t/16.ll 2>&1 | FileCheck --check-prefix=CHECK-16 %s
 
 ;--- main.ll
-; NONE: error: linking module flags 'override-stack-alignment': IDs have conflicting values
-; CHECK-16: error: linking module flags 'override-stack-alignment': IDs have conflicting values
+; NONE: error: linking module flags 'override-stack-alignment': IDs have conflicting behaviors
+; CHECK-16: error: linking module flags 'override-stack-alignment': IDs have conflicting behaviors
 !llvm.module.flags = !{!0}
-!0 = !{i32 1, !"override-stack-alignment", i32 8}
+!0 = !{i32 8, !"override-stack-alignment", i32 8}
 
 ;--- none.ll
 ;--- 8.ll
 !llvm.module.flags = !{!0}
-!0 = !{i32 1, !"override-stack-alignment", i32 8}
+!0 = !{i32 8, !"override-stack-alignment", i32 8}
 ;--- 16.ll
 !llvm.module.flags = !{!0}
-!0 = !{i32 1, !"override-stack-alignment", i32 16}
+!0 = !{i32 8, !"override-stack-alignment", i32 16}
Index: llvm/lib/Linker/IRMover.cpp
===
--- llvm/lib/Linker/IRMover.cpp
+++ llvm/lib/Linker/IRMover.cpp
@@ -1216,17 +1216,41 @@
 
 /// Merge the linker flags in Src into the Dest module.
 Error IRLinker::linkModuleFlagsMetadata() {
-  // If the source module has no module flags, we are done.
-  const NamedMDNode *SrcModFlags = SrcM->getModuleFlagsMetadata();
-  if (!SrcModFlags)
+  NamedMDNode *SrcModFlags = SrcM->getModuleFlagsMetadata();
+  NamedMDNode *DstModFlags = DstM.getOrInsertModuleFlagsMetadata();
+
+  // If the source module has no module flags, we still need to scan the
+  // destination module for any ErrorWhenMissing, otherwise we are done.
+  if (!SrcModFlags) {
+for (MDNode *Op : DstModFlags->operands()) {
+  ConstantInt *Behavior = mdconst::extract(Op->getOperand(0));
+  if (Behavior->getZExtValue() == Module::ErrorWhenMissing) {
+MDString *ID = cast(Op->getOperand(1));
+return stringErr("linking module flags '" + ID->getString() +
+ "': IDs have conflicting behaviors in '" +
+ SrcM->getModuleIdentifier() + "' and '" +
+ DstM.getModuleIdentifier() + "'");
+  }
+}
 return Error::success();
+  }
 
   // If the destination module doesn't have module flags yet, then just copy
-  // over the source module's flags.
-  NamedMDNode *DstModFlags = DstM.getOrInsertModuleFlagsMetadata();
+  // over the source module's flags. Make sure to check for any
+  // ErrorWhenMissing.
   if (DstModFlags->getNumOperands() == 0) {
-for (unsigned I = 0, E = SrcModFlags->getNumOperands(); I != E; ++I)
-  DstModFlags->addOperand(SrcModFlags->getOperand(I));
+for (MDNode *Op : SrcModFlags->operands()) {
+  ConstantInt *Behavior = mdconst::extract(Op->getOperand(0));
+  if (Behavior->getZExtValue() == Module::ErrorWhenMissing) {
+MDString *ID = cast(Op->getOperand(1));
+// TODO: main case is now failing.
+return 

[PATCH] D103837: [clang] Apply MS ABI details on __builtin_ms_va_list on non-windows platforms on x86_64

[Reid Kleckner via Phabricator via cfe-commits]

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

lgtm


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103837

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

[PATCH] D103495: [static initializers] Don't put ordered dynamic initializers of static variables into global_ctors

[Reid Kleckner via Phabricator via cfe-commits]

rnk added subscribers: MaskRay, mstorsjo.
rnk added a comment.

+ various .ctors stakeholders + @MaskRay  + @mstorsjo

This change was my idea, so I want to make sure there is buy in from other 
folks who use -fno-init-array. This has the potential to break user programs 
that rely on the order of dynamic initialization *within* a TU, but there will 
be no change in order between TUs. This might also deserve a release note.

Overall this should be a positive change. In the past users have reported QoI 
issues where a template with an SDM instantiated earlier in the TU gets 
initialized after a template instantiated later in the TU. Technically, those 
initializers are not ordered, so this is not a correctness issue, but it would 
be nicer if initializers ran in source order.

We might need to add docs here about what happens when the initializer is in a 
comdat group, since the order guarantee in that case is very subtle.


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

https://reviews.llvm.org/D103495

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

[PATCH] D103564: [NFC][compiler-rt][hwasan] Move allocation functions into their own file

[Leonard Chan via Phabricator via cfe-commits]

leonardchan updated this revision to Diff 350437.
leonardchan retitled this revision from "[NFC][compiler-rt][hwasan] Wrap fork 
interceptor with HWASAN_WITH_INTERCEPTORS" to "[NFC][compiler-rt][hwasan] Move 
allocation functions into their own file".
leonardchan edited the summary of this revision.
leonardchan added a comment.
Herald added subscribers: jfb, krytarowski, mgorny.

Followed up with Roland's suggestion and moved everything relating to the 
allocation functions.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103564

Files:
  compiler-rt/lib/hwasan/CMakeLists.txt
  compiler-rt/lib/hwasan/hwasan.h
  compiler-rt/lib/hwasan/hwasan_allocation_functions.cpp
  compiler-rt/lib/hwasan/hwasan_interceptors.cpp

Index: compiler-rt/lib/hwasan/hwasan_interceptors.cpp
===
--- compiler-rt/lib/hwasan/hwasan_interceptors.cpp
+++ compiler-rt/lib/hwasan/hwasan_interceptors.cpp
@@ -16,192 +16,14 @@
 
 #include "interception/interception.h"
 #include "hwasan.h"
-#include "hwasan_allocator.h"
-#include "hwasan_mapping.h"
 #include "hwasan_thread.h"
-#include "hwasan_poisoning.h"
-#include "hwasan_report.h"
-#include "sanitizer_common/sanitizer_platform_limits_posix.h"
-#include "sanitizer_common/sanitizer_allocator.h"
-#include "sanitizer_common/sanitizer_allocator_interface.h"
-#include "sanitizer_common/sanitizer_allocator_internal.h"
-#include "sanitizer_common/sanitizer_atomic.h"
-#include "sanitizer_common/sanitizer_common.h"
-#include "sanitizer_common/sanitizer_errno.h"
 #include "sanitizer_common/sanitizer_stackdepot.h"
-#include "sanitizer_common/sanitizer_libc.h"
-#include "sanitizer_common/sanitizer_linux.h"
-#include "sanitizer_common/sanitizer_tls_get_addr.h"
 
-#include 
-// ACHTUNG! No other system header includes in this file.
-// Ideally, we should get rid of stdarg.h as well.
+#if !SANITIZER_FUCHSIA
 
 using namespace __hwasan;
 
-using __sanitizer::memory_order;
-using __sanitizer::atomic_load;
-using __sanitizer::atomic_store;
-using __sanitizer::atomic_uintptr_t;
-
-static uptr allocated_for_dlsym;
-static const uptr kDlsymAllocPoolSize = 1024;
-static uptr alloc_memory_for_dlsym[kDlsymAllocPoolSize];
-
-static bool IsInDlsymAllocPool(const void *ptr) {
-  uptr off = (uptr)ptr - (uptr)alloc_memory_for_dlsym;
-  return off < sizeof(alloc_memory_for_dlsym);
-}
-
-static void *AllocateFromLocalPool(uptr size_in_bytes) {
-  uptr size_in_words = RoundUpTo(size_in_bytes, kWordSize) / kWordSize;
-  void *mem = (void *)_memory_for_dlsym[allocated_for_dlsym];
-  allocated_for_dlsym += size_in_words;
-  CHECK_LT(allocated_for_dlsym, kDlsymAllocPoolSize);
-  return mem;
-}
-
-#define ENSURE_HWASAN_INITED() do { \
-  CHECK(!hwasan_init_is_running); \
-  if (!hwasan_inited) { \
-__hwasan_init(); \
-  } \
-} while (0)
-
-
-int __sanitizer_posix_memalign(void **memptr, uptr alignment, uptr size) {
-  GET_MALLOC_STACK_TRACE;
-  CHECK_NE(memptr, 0);
-  int res = hwasan_posix_memalign(memptr, alignment, size, );
-  return res;
-}
-
-void * __sanitizer_memalign(uptr alignment, uptr size) {
-  GET_MALLOC_STACK_TRACE;
-  return hwasan_memalign(alignment, size, );
-}
-
-void * __sanitizer_aligned_alloc(uptr alignment, uptr size) {
-  GET_MALLOC_STACK_TRACE;
-  return hwasan_aligned_alloc(alignment, size, );
-}
-
-void * __sanitizer___libc_memalign(uptr alignment, uptr size) {
-  GET_MALLOC_STACK_TRACE;
-  void *ptr = hwasan_memalign(alignment, size, );
-  if (ptr)
-DTLS_on_libc_memalign(ptr, size);
-  return ptr;
-}
-
-void * __sanitizer_valloc(uptr size) {
-  GET_MALLOC_STACK_TRACE;
-  return hwasan_valloc(size, );
-}
-
-void * __sanitizer_pvalloc(uptr size) {
-  GET_MALLOC_STACK_TRACE;
-  return hwasan_pvalloc(size, );
-}
-
-void __sanitizer_free(void *ptr) {
-  GET_MALLOC_STACK_TRACE;
-  if (!ptr || UNLIKELY(IsInDlsymAllocPool(ptr))) return;
-  hwasan_free(ptr, );
-}
-
-void __sanitizer_cfree(void *ptr) {
-  GET_MALLOC_STACK_TRACE;
-  if (!ptr || UNLIKELY(IsInDlsymAllocPool(ptr))) return;
-  hwasan_free(ptr, );
-}
-
-uptr __sanitizer_malloc_usable_size(const void *ptr) {
-  return __sanitizer_get_allocated_size(ptr);
-}
-
-struct __sanitizer_struct_mallinfo __sanitizer_mallinfo() {
-  __sanitizer_struct_mallinfo sret;
-  internal_memset(, 0, sizeof(sret));
-  return sret;
-}
-
-int __sanitizer_mallopt(int cmd, int value) {
-  return 0;
-}
-
-void __sanitizer_malloc_stats(void) {
-  // FIXME: implement, but don't call REAL(malloc_stats)!
-}
-
-void * __sanitizer_calloc(uptr nmemb, uptr size) {
-  GET_MALLOC_STACK_TRACE;
-  if (UNLIKELY(!hwasan_inited))
-// Hack: dlsym calls calloc before REAL(calloc) is retrieved from dlsym.
-return AllocateFromLocalPool(nmemb * size);
-  return hwasan_calloc(nmemb, size, );
-}
-
-void * __sanitizer_realloc(void *ptr, uptr size) {
-  GET_MALLOC_STACK_TRACE;
-  if (UNLIKELY(IsInDlsymAllocPool(ptr))) {
-uptr offset 

[PATCH] D103850: [clang] diagnose instead of assert for defaulted comparison return type deduction.

[Matheus Izvekov via Phabricator via cfe-commits]

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

When deducing the return type of defaulted three-way comparison, instead
of asserting in the case of unsupported builtin types, just diagnose it.

For now, we add a test case for function pointers which will produce
slightly incorrect diagnostics. In future work, we will stop adding
function pointers to the candidate set and get the correct diagnostics.

Signed-off-by: Matheus Izvekov 

Depends on D103760 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D103850

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/test/CXX/class/class.compare/class.spaceship/p2.cpp


Index: clang/test/CXX/class/class.compare/class.spaceship/p2.cpp
===
--- clang/test/CXX/class/class.compare/class.spaceship/p2.cpp
+++ clang/test/CXX/class/class.compare/class.spaceship/p2.cpp
@@ -191,4 +191,14 @@
 a2 f;
   };
   std::partial_ordering cmp_b2 = b2() <=> b2();
+
+  struct a3 {
+using fp = void (*)();
+operator fp() const;
+  };
+  struct b3 {
+auto operator<=>(b3 const &) const = default; // expected-error {{cannot 
be deduced because three-way comparison for member 'f' would compare as builtin 
type 'void (*)()' which is not currently supported}}
+// expected-warning@-1 {{implicitly deleted}}
+a3 f;
+  };
 }
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -7868,7 +7868,15 @@
  "invalid builtin comparison");
   Optional Cat =
   getComparisonCategoryForBuiltinCmp(T);
-  assert(Cat && "no category for builtin comparison?");
+  if (!Cat) {
+if (Diagnose == NoDiagnostics)
+  S.Diag(
+  FD->getLocation(),
+  diag::
+  
err_defaulted_comparison_cannot_deduce_unsupported_builtin_type)
+  << Subobj.Kind << Subobj.Decl << T;
+return Result::deleted();
+  }
   R.Category = *Cat;
 }
   }
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -9122,6 +9122,10 @@
   "%select{|member|base class}0 %1 declared here">;
 def note_defaulted_comparison_cannot_deduce_callee : Note<
   "selected 'operator<=>' for %select{|member|base class}0 %1 declared here">;
+def err_defaulted_comparison_cannot_deduce_unsupported_builtin_type : Error<
+  "return type of defaulted 'operator<=>' cannot be deduced because "
+  "three-way comparison for %select{|member|base class}0 %1 "
+  "would compare as builtin type %2 which is not currently supported by 
clang">;
 def err_incorrect_defaulted_comparison_constexpr : Error<
   "defaulted definition of %select{%sub{select_defaulted_comparison_kind}1|"
   "three-way comparison operator}0 "


Index: clang/test/CXX/class/class.compare/class.spaceship/p2.cpp
===
--- clang/test/CXX/class/class.compare/class.spaceship/p2.cpp
+++ clang/test/CXX/class/class.compare/class.spaceship/p2.cpp
@@ -191,4 +191,14 @@
 a2 f;
   };
   std::partial_ordering cmp_b2 = b2() <=> b2();
+
+  struct a3 {
+using fp = void (*)();
+operator fp() const;
+  };
+  struct b3 {
+auto operator<=>(b3 const &) const = default; // expected-error {{cannot be deduced because three-way comparison for member 'f' would compare as builtin type 'void (*)()' which is not currently supported}}
+// expected-warning@-1 {{implicitly deleted}}
+a3 f;
+  };
 }
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -7868,7 +7868,15 @@
  "invalid builtin comparison");
   Optional Cat =
   getComparisonCategoryForBuiltinCmp(T);
-  assert(Cat && "no category for builtin comparison?");
+  if (!Cat) {
+if (Diagnose == NoDiagnostics)
+  S.Diag(
+  FD->getLocation(),
+  diag::
+  err_defaulted_comparison_cannot_deduce_unsupported_builtin_type)
+  << Subobj.Kind << Subobj.Decl << T;
+return Result::deleted();
+  }
   R.Category = *Cat;
 }
   }
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ 

[PATCH] D103845: [compiler-rt][hwasan] Add newline between record_addr lines on frame record dumps

[Leonard Chan via Phabricator via cfe-commits]

leonardchan created this revision.
leonardchan added reviewers: eugenis, vitalybuka.
leonardchan added a project: Sanitizers.
Herald added a subscriber: dberris.
leonardchan requested review of this revision.
Herald added a subscriber: Sanitizers.

This is mostly a stylistic preference. Currently all the frame records are 
dumped on one line (`record:0xb8b4214178819a54{{{bt:0:0x214178819a54}}}  
record_addr:0x22c8777bdb08 record:0xb8e0214178818394{{{bt:0:0x2141788183...`) 
but it might be easier to debug if it we newline-separated.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D103845

Files:
  compiler-rt/lib/hwasan/hwasan_report.cpp


Index: compiler-rt/lib/hwasan/hwasan_report.cpp
===
--- compiler-rt/lib/hwasan/hwasan_report.cpp
+++ compiler-rt/lib/hwasan/hwasan_report.cpp
@@ -240,6 +240,8 @@
   common_flags()->symbolize_vs_style,
   common_flags()->strip_path_prefix);
   frame->ClearAll();
+} else {
+  frame_desc.append("\n");
 }
 Printf("%s", frame_desc.data());
 frame_desc.clear();


Index: compiler-rt/lib/hwasan/hwasan_report.cpp
===
--- compiler-rt/lib/hwasan/hwasan_report.cpp
+++ compiler-rt/lib/hwasan/hwasan_report.cpp
@@ -240,6 +240,8 @@
   common_flags()->symbolize_vs_style,
   common_flags()->strip_path_prefix);
   frame->ClearAll();
+} else {
+  frame_desc.append("\n");
 }
 Printf("%s", frame_desc.data());
 frame_desc.clear();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D103760: [clang] use correct builtin type for defaulted comparison analyzer

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added a comment.

@rsmith  what do you think of the following strategy as a follow up to this 
patch:

- First step we replace the assert at line 7866 with a `deleted` result. I 
don't really think it's sustainable to keep returning incorrect results / 
crashing for builtin types that are to be supported in the future. We create a 
new diagnostic for unimplemented builtin type for three-way comparison or 
something along these lines. This will gloss over for now function pointers, 
the only other type which we are adding to the candidate set which we should 
not be doing. As a consequence, we produce slightly unhelpful diagnostics here, 
for now.
- Second step we modify `AddTypesConvertedFrom` so it can ignore function 
pointers, when used for purposes of building a candidate set for three-way 
comparison. Here, we would correct the diagnostics from step one.

Thoughts?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103760

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

[clang] 9145a3d - Revert "[AArch64] handle -Wa,-march="

[Jian Cai via cfe-commits]

Author: Jian Cai
Date: 2021-06-07T14:31:07-07:00
New Revision: 9145a3d4ab7eb05d9fb113b5392e8961df629b88

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

LOG: Revert "[AArch64] handle -Wa,-march="

This reverts commit fd11a26d368c5a909fb88548fef2cee7a6c2c931.

Added: 


Modified: 
clang/lib/Driver/ToolChains/Arch/AArch64.cpp
clang/lib/Driver/ToolChains/Arch/AArch64.h
clang/lib/Driver/ToolChains/Clang.cpp

Removed: 
clang/test/Driver/aarch64-target-as-march.s



diff  --git a/clang/lib/Driver/ToolChains/Arch/AArch64.cpp 
b/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
index cb98d423ed2b0..503685ab533a0 100644
--- a/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
+++ b/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
@@ -185,20 +185,12 @@ getAArch64MicroArchFeaturesFromMcpu(const Driver , 
StringRef Mcpu,
 void aarch64::getAArch64TargetFeatures(const Driver ,
const llvm::Triple ,
const ArgList ,
-   std::vector ,
-   bool ForAS) {
+   std::vector ) {
   Arg *A;
   bool success = true;
   // Enable NEON by default.
   Features.push_back("+neon");
-  if (ForAS &&
-  (A = Args.getLastArg(options::OPT_Wa_COMMA, options::OPT_Xassembler))) {
-llvm::StringRef WaMArch;
-for (StringRef Value : A->getValues())
-  if (Value.startswith("-march="))
-WaMArch = Value.substr(7);
-success = getAArch64ArchFeaturesFromMarch(D, WaMArch, Args, Features);
-  } else if ((A = Args.getLastArg(options::OPT_march_EQ)))
+  if ((A = Args.getLastArg(options::OPT_march_EQ)))
 success = getAArch64ArchFeaturesFromMarch(D, A->getValue(), Args, 
Features);
   else if ((A = Args.getLastArg(options::OPT_mcpu_EQ)))
 success = getAArch64ArchFeaturesFromMcpu(D, A->getValue(), Args, Features);

diff  --git a/clang/lib/Driver/ToolChains/Arch/AArch64.h 
b/clang/lib/Driver/ToolChains/Arch/AArch64.h
index d47c402d4a42d..713af870d69fb 100644
--- a/clang/lib/Driver/ToolChains/Arch/AArch64.h
+++ b/clang/lib/Driver/ToolChains/Arch/AArch64.h
@@ -22,8 +22,7 @@ namespace aarch64 {
 
 void getAArch64TargetFeatures(const Driver , const llvm::Triple ,
   const llvm::opt::ArgList ,
-  std::vector ,
-  bool ForAS);
+  std::vector );
 
 std::string getAArch64TargetCPU(const llvm::opt::ArgList ,
 const llvm::Triple , llvm::opt::Arg 
*);

diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 6fdd7e2dd21e7..a0e1208fd709c 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -344,7 +344,7 @@ static void getTargetFeatures(const Driver , const 
llvm::Triple ,
   case llvm::Triple::aarch64:
   case llvm::Triple::aarch64_32:
   case llvm::Triple::aarch64_be:
-aarch64::getAArch64TargetFeatures(D, Triple, Args, Features, ForAS);
+aarch64::getAArch64TargetFeatures(D, Triple, Args, Features);
 break;
   case llvm::Triple::x86:
   case llvm::Triple::x86_64:

diff  --git a/clang/test/Driver/aarch64-target-as-march.s 
b/clang/test/Driver/aarch64-target-as-march.s
deleted file mode 100644
index a9301ade43351..0
--- a/clang/test/Driver/aarch64-target-as-march.s
+++ /dev/null
@@ -1,46 +0,0 @@
-/// These tests make sure that options passed to the assembler
-/// via -Wa or -Xassembler are applied correctly to assembler inputs.
-
-/// Does not apply to non assembly files
-// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=armv8.1-a \
-// RUN: %S/Inputs/wildcard1.c 2>&1 | FileCheck --check-prefix=TARGET-FEATURE-1 
%s
-// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Xassembler 
-march=armv8.1-a \
-// RUN: %S/Inputs/wildcard1.c 2>&1 | FileCheck --check-prefix=TARGET-FEATURE-1 
%s
-
-// TARGET-FEATURE-1-NOT: "-target-feature" "+v8.1a"
-
-/// Does apply to assembler input
-// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=armv8.2-a %s 
2>&1 | \
-// RUN: FileCheck --check-prefix=TARGET-FEATURE-2 %s
-// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Xassembler 
-march=armv8.2-a %s 2>&1 | \
-// RUN: FileCheck --check-prefix=TARGET-FEATURE-2 %s
-
-// TARGET-FEATURE-2: "-target-feature" "+v8.2a"
-
-/// No unused argument warnings when there are multiple values
-// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=armv8.1-a 
-Wa,-march=armv8.2-a %s 2>&1 | \
-// RUN: FileCheck --check-prefix=UNUSED-WARNING %s
-
-// UNUSED-WARNING-NOT: warning: argument unused during compilation
-
-/// Last march to assembler wins
-// RUN: %clang 

[PATCH] D103841: [compiler-rt][hwasan] Decouple use of the TLS global for getting the shadow base and using the frame record feature

[Leonard Chan via Phabricator via cfe-commits]

leonardchan created this revision.
leonardchan added reviewers: phosek, mcgrathr, eugenis, vitalybuka.
leonardchan added a project: Sanitizers.
Herald added subscribers: hiraditya, dberris.
leonardchan requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

This allows for using the frame record feature (which uses `__hwasan_tls`) 
independently from however the user wants to access the shadow base, which 
prior was only usable if shadow wasn't accessed through the TLS variable or 
ifuncs.

For code that already used both the frame record feature and access shadow 
through `__hwasan_tls`, this change should be a no-op. The extra instructions 
necessary for storing to the ring buffer are only added to cases that weren't 
using TLS prior, and are added after getting the shadow base.

Updated tests and added an extra case to `prologue.ll` that covers this new 
case.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D103841

Files:
  llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
  llvm/test/Instrumentation/HWAddressSanitizer/alloca.ll
  llvm/test/Instrumentation/HWAddressSanitizer/kernel-alloca.ll
  llvm/test/Instrumentation/HWAddressSanitizer/prologue.ll

Index: llvm/test/Instrumentation/HWAddressSanitizer/prologue.ll
===
--- llvm/test/Instrumentation/HWAddressSanitizer/prologue.ll
+++ llvm/test/Instrumentation/HWAddressSanitizer/prologue.ll
@@ -1,15 +1,17 @@
 ; Test -hwasan-with-ifunc flag.
 ;
 ; RUN: opt -hwasan -S < %s | \
-; RUN: FileCheck %s --check-prefixes=CHECK,CHECK-NOGLOBAL,CHECK-TLS,CHECK-HISTORY
+; RUN: FileCheck %s --check-prefixes=CHECK,CHECK-NOGLOBAL,CHECK-TLS,CHECK-HISTORY,CHECK-THREAD-PTR
 ; RUN: opt -hwasan -S -hwasan-with-ifunc=0 -hwasan-with-tls=1 -hwasan-record-stack-history=1 < %s | \
-; RUN: FileCheck %s --check-prefixes=CHECK,CHECK-NOGLOBAL,CHECK-TLS,CHECK-HISTORY
+; RUN: FileCheck %s --check-prefixes=CHECK,CHECK-NOGLOBAL,CHECK-TLS,CHECK-HISTORY,CHECK-THREAD-PTR
 ; RUN: opt -hwasan -S -hwasan-with-ifunc=0 -hwasan-with-tls=1 -hwasan-record-stack-history=0 < %s | \
 ; RUN: FileCheck %s --check-prefixes=CHECK,CHECK-NOGLOBAL,CHECK-IFUNC,CHECK-NOHISTORY
-; RUN: opt -hwasan -S -hwasan-with-ifunc=0 -hwasan-with-tls=0 < %s | \
+; RUN: opt -hwasan -S -hwasan-record-stack-history=0 -hwasan-with-ifunc=0 -hwasan-with-tls=0 < %s | \
 ; RUN: FileCheck %s --check-prefixes=CHECK,CHECK-GLOBAL,CHECK-NOHISTORY
-; RUN: opt -hwasan -S -hwasan-with-ifunc=1  -hwasan-with-tls=0 < %s | \
+; RUN: opt -hwasan -S -hwasan-record-stack-history=0 -hwasan-with-ifunc=1  -hwasan-with-tls=0 < %s | \
 ; RUN: FileCheck %s --check-prefixes=CHECK,CHECK-IFUNC,CHECK-NOHISTORY
+; RUN: opt -hwasan -S -hwasan-record-stack-history=1 -hwasan-with-ifunc=0 -hwasan-with-tls=0 < %s | \
+; RUN: FileCheck %s --check-prefixes=CHECK,CHECK-GLOBAL,CHECK-HISTORY,CHECK-THREAD-PTR
 
 target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
 target triple = "aarch64--linux-android22"
@@ -52,11 +54,11 @@
 
 ; CHECK-GLOBAL: load i8*, i8** @__hwasan_shadow_memory_dynamic_address
 
-; CHECK-TLS:   %[[A:[^ ]*]] = call i8* @llvm.thread.pointer()
-; CHECK-TLS:   %[[B:[^ ]*]] = getelementptr i8, i8* %[[A]], i32 48
-; CHECK-TLS:   %[[C:[^ ]*]] = bitcast i8* %[[B]] to i64*
-; CHECK-TLS:   %[[D:[^ ]*]] = load i64, i64* %[[C]]
-; CHECK-TLS:   %[[E:[^ ]*]] = ashr i64 %[[D]], 3
+; CHECK-THREAD-PTR:   %[[A:[^ ]*]] = call i8* @llvm.thread.pointer()
+; CHECK-THREAD-PTR:   %[[B:[^ ]*]] = getelementptr i8, i8* %[[A]], i32 48
+; CHECK-THREAD-PTR:   %[[C:[^ ]*]] = bitcast i8* %[[B]] to i64*
+; CHECK-THREAD-PTR:   %[[D:[^ ]*]] = load i64, i64* %[[C]]
+; CHECK-THREAD-PTR:   %[[E:[^ ]*]] = ashr i64 %[[D]], 3
 
 ; CHECK-NOHISTORY-NOT: store i64
 
Index: llvm/test/Instrumentation/HWAddressSanitizer/kernel-alloca.ll
===
--- llvm/test/Instrumentation/HWAddressSanitizer/kernel-alloca.ll
+++ llvm/test/Instrumentation/HWAddressSanitizer/kernel-alloca.ll
@@ -1,6 +1,6 @@
 ; Test kernel hwasan instrumentation for alloca.
 ;
-; RUN: opt < %s -hwasan -hwasan-kernel=1 -S | FileCheck %s
+; RUN: opt < %s -hwasan -hwasan-record-stack-history=0 -hwasan-kernel=1 -S | FileCheck %s
 
 target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
 target triple = "aarch64--linux-android"
Index: llvm/test/Instrumentation/HWAddressSanitizer/alloca.ll
===
--- llvm/test/Instrumentation/HWAddressSanitizer/alloca.ll
+++ llvm/test/Instrumentation/HWAddressSanitizer/alloca.ll
@@ -1,8 +1,8 @@
 ; Test alloca instrumentation.
 ;
-; RUN: opt < %s -hwasan -hwasan-with-ifunc=1 -S | FileCheck %s --check-prefixes=CHECK,DYNAMIC-SHADOW,NO-UAR-TAGS
-; RUN: opt < %s -hwasan -hwasan-mapping-offset=0 -S | FileCheck %s --check-prefixes=CHECK,ZERO-BASED-SHADOW,NO-UAR-TAGS
-; RUN: opt 

[PATCH] D103048: [IR] make -stack-alignment= into a module attr

[Nick Desaulniers via Phabricator via cfe-commits]

nickdesaulniers added a comment.

In D103048#2795456 , @tejohnson wrote:

>> Curiously, using ModFlagBehavior::Error doesn't error if one of two modules 
>> being linked together doesn't have such a module level attribute.
>
> Yeah, there's a Require behavior, but that only allows you to specify what 
> the value should be after linking modules. Barring changing the behavior of 
> Error, which I'm guessing is relied upon too many places, the main thing I 
> can think of is to add a new module flag behavior with tbd name that is 
> essentially like Error but treats a module without the module flag as having 
> a conflicting value and issues an error for that as well.

I agree, that's what I was thinking we'd need to do, so I'm glad you came to a 
similar conclusion.  I'll work on implementing a new `ModFlagBehavior` in this 
patch implementing such semantics that then this module level IR node can use.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103048

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

[PATCH] D103806: [SystemZ][z/OS] Pass OpenFlags when creating tmp files

[Adrian McCarthy via Phabricator via cfe-commits]

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

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103806

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

[PATCH] D103184: [AArch64] handle -Wa,-march=

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

FWIW the failure goes away locally if I revert this change here, so it's 
definitely due to this change here.

Things have been red for a while, probably good to revert while you investigate 
by this point.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103184

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

[PATCH] D103707: [AIX] Define __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__ predefined macros

[Jake Egan via Phabricator via cfe-commits]

Jake-Egan updated this revision to Diff 350406.
Jake-Egan added a comment.

Fix formatting.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103707

Files:
  clang/lib/Basic/Targets/OSTargets.h
  clang/test/Preprocessor/init-ppc.c


Index: clang/test/Preprocessor/init-ppc.c
===
--- clang/test/Preprocessor/init-ppc.c
+++ clang/test/Preprocessor/init-ppc.c
@@ -723,6 +723,16 @@
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc-ibm-aix7.1.0.0 
-fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix 
PPC-AIX-NOTHREADSAFE %s
 // PPC-AIX-NOTHREADSAFE-NOT:#define _THREAD_SAFE 1
 
+// RUN: %clang_cc1 -x c -std=c11 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=gnu11 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=c17 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// PPC-AIX-STDC:#define __STDC_NO_ATOMICS__ 1
+// PPC-AIX-STDC:#define __STDC_NO_THREADS__ 1
+
+// RUN: %clang_cc1 -x c -std=c99 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC-N %s
+// PPC-AIX-STDC-N-NOT:#define __STDC_NO_ATOMICS__ 1
+// PPC-AIX-STDC-N-NOT:#define __STDC_NO_THREADS__ 1
+
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc-unknown-linux-gnu 
-fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix 
PPC-LINUX %s
 //
 // PPC-LINUX:#define _ARCH_PPC 1
Index: clang/lib/Basic/Targets/OSTargets.h
===
--- clang/lib/Basic/Targets/OSTargets.h
+++ clang/lib/Basic/Targets/OSTargets.h
@@ -676,6 +676,11 @@
 
 Builder.defineMacro("_AIX");
 
+if (LangStandard::getLangStandardForKind(Opts.LangStd).isC11()) {
+  Builder.defineMacro("__STDC_NO_ATOMICS__");
+  Builder.defineMacro("__STDC_NO_THREADS__");
+}
+
 if (Opts.EnableAIXExtendedAltivecABI)
   Builder.defineMacro("__EXTABI__");
 


Index: clang/test/Preprocessor/init-ppc.c
===
--- clang/test/Preprocessor/init-ppc.c
+++ clang/test/Preprocessor/init-ppc.c
@@ -723,6 +723,16 @@
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix PPC-AIX-NOTHREADSAFE %s
 // PPC-AIX-NOTHREADSAFE-NOT:#define _THREAD_SAFE 1
 
+// RUN: %clang_cc1 -x c -std=c11 -E -dM -ffreestanding -triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=gnu11 -E -dM -ffreestanding -triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=c17 -E -dM -ffreestanding -triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix PPC-AIX-STDC %s
+// PPC-AIX-STDC:#define __STDC_NO_ATOMICS__ 1
+// PPC-AIX-STDC:#define __STDC_NO_THREADS__ 1
+
+// RUN: %clang_cc1 -x c -std=c99 -E -dM -ffreestanding -triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix PPC-AIX-STDC-N %s
+// PPC-AIX-STDC-N-NOT:#define __STDC_NO_ATOMICS__ 1
+// PPC-AIX-STDC-N-NOT:#define __STDC_NO_THREADS__ 1
+
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc-unknown-linux-gnu -fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix PPC-LINUX %s
 //
 // PPC-LINUX:#define _ARCH_PPC 1
Index: clang/lib/Basic/Targets/OSTargets.h
===
--- clang/lib/Basic/Targets/OSTargets.h
+++ clang/lib/Basic/Targets/OSTargets.h
@@ -676,6 +676,11 @@
 
 Builder.defineMacro("_AIX");
 
+if (LangStandard::getLangStandardForKind(Opts.LangStd).isC11()) {
+  Builder.defineMacro("__STDC_NO_ATOMICS__");
+  Builder.defineMacro("__STDC_NO_THREADS__");
+}
+
 if (Opts.EnableAIXExtendedAltivecABI)
   Builder.defineMacro("__EXTABI__");
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D54047: Check TUScope is valid before use

[Kim Gräsman via Phabricator via cfe-commits]

kimgr added a comment.

This was eventually fixed in IWYU based on @jkorous' suggestion above. I 
believe the problem is/was:

- After code is parsed and the AST is built, Sema resets its `TUScope` member 
to null
- We use Sema to lookup and define default constructors before traversing the 
AST using a RAV
- Some yet-not-fully-identified constructs cause Sema to need a TUScope for 
this (something to do with `LazilyCreateBuiltin`, but I haven't been able to 
construct a reduced testcase)

So in 
https://github.com/include-what-you-use/include-what-you-use/commit/5e7843434169a8af05ebd6e1434cc3cffb66,
 we explicitly re-point `Sema::TUScope` to `Sema::getCurScope()`, which seems 
to have fixed the crash.

This revision can be closed.


Repository:
  rC Clang

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

https://reviews.llvm.org/D54047

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

[PATCH] D31697: Check for null before using TUScope

[Kim Gräsman via Phabricator via cfe-commits]

kimgr added a comment.

This was eventually fixed in IWYU. I believe the problem is/was:

- After code is parsed and the AST is built, Sema resets its `TUScope` member 
to null
- We use Sema to lookup and define default constructors before traversing the 
AST using a RAV
- Some yet-not-fully-identified constructs cause Sema to need a TUScope for 
this (something to do with `LazilyCreateBuiltin`, but I haven't been able to 
construct a reduced testcase)

So in 
https://github.com/include-what-you-use/include-what-you-use/commit/5e7843434169a8af05ebd6e1434cc3cffb66,
 we explicitly re-point `Sema::TUScope` to `Sema::getCurScope()`, which seems 
to have fixed the crash.

This revision can be closed.


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

https://reviews.llvm.org/D31697

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

[PATCH] D103184: [AArch64] handle -Wa,-march=

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

In D103184#2803691 , @nickdesaulniers 
wrote:

> In D103184#2803513 , @thakis wrote:
>
>> This breaks tests on arm macs: http://45.33.8.238/macm1/10931/step_7.txt
>
>
>
>>> clang: error: the clang compiler does not support '-Wa,--version'
>
> Wouldn't that be 
> https://reviews.llvm.org/rG76d9bc72784d88f4dd57b9939e52c73739438af5 
> (https://reviews.llvm.org/D99556)?

First bad build is http://45.33.8.238/macm1/10923/summary.html which has 
https://github.com/llvm/llvm-project/compare/1465e7770bca...43929ccc1296 as 
regression range


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103184

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

[PATCH] D103611: Correct the behavior of va_arg checking in C++

[Eli Friedman via Phabricator via cfe-commits]

efriedma added inline comments.



Comment at: clang/lib/Sema/SemaExpr.cpp:15775
+  if (Context.typesAreCompatible(PromoteType, UnderlyingType,
+ /*CompareUnqualified*/ true))
 PromoteType = QualType();

If we're not going to take advantage of the C notion of compatibility, might as 
well just check hasSameType().



Comment at: clang/lib/Sema/SemaExpr.cpp:15783
+  // test for typesAreCompatible() will already properly consider those to
+  // be compatible types.
+  if (Context.getLangOpts().CPlusPlus && !PromoteType.isNull() &&

aaron.ballman wrote:
> efriedma wrote:
> > This explanation doesn't seem right.  Signed and unsigned types are never 
> > considered "compatible".
> > 
> > If I'm understanding correctly, the case this code addresses is promotion 
> > according to `[conv.prom]`p3: "A prvalue of an unscoped enumeration type 
> > whose underlying type is not fixed [...]".  Somehow, the enum ends up with 
> > an unsigned underlying type, but we promote to int?  And this doesn't 
> > happen in C somehow?
> > This explanation doesn't seem right. Signed and unsigned types are never 
> > considered "compatible".
> 
> Good point, I think that comment is wrong.
> 
> > If I'm understanding correctly, the case this code addresses is promotion 
> > according to [conv.prom]p3: "A prvalue of an unscoped enumeration type 
> > whose underlying type is not fixed [...]". Somehow, the enum ends up with 
> > an unsigned underlying type, but we promote to int? And this doesn't happen 
> > in C somehow?
> 
> That's correct. What I am seeing is:
> ```
> enum Unscoped { One = 0x7FFF };
> ```
> C++:
> `PromoteType` = Builtin (Int)
> `UnderlyingType` = Builtin (UInt)
> 
> C:
> `PromoteType` = Builtin (UInt)
> `UnderlyingType` = Builtin (UInt)
> 
> 
> `enum Unscoped { One = 0x };`
> 
> C++:
> `PromoteType` = Builtin (UInt)
> `UnderlyingType` = Builtin (UInt)
> 
> C:
> `PromoteType` = Builtin (UInt)
> `UnderlyingType` = Builtin (UInt)
> 
> At least on i386-pc-unknown.
> 
> So I think this code is almost correct for that test, but is over-constrained 
> by only doing this in C++. WDYT?
That makes more sense.

Not sure this particular issue can show up in C; there's a check for C++ in 
Sema::ActOnEnumBody.  But no harm at least.


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

https://reviews.llvm.org/D103611

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

[PATCH] D103707: [AIX] Define __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__ predefined macros

[Jake Egan via Phabricator via cfe-commits]

Jake-Egan updated this revision to Diff 350400.
Jake-Egan added a comment.

Add C17 test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103707

Files:
  clang/lib/Basic/Targets/OSTargets.h
  clang/test/Preprocessor/init-ppc.c


Index: clang/test/Preprocessor/init-ppc.c
===
--- clang/test/Preprocessor/init-ppc.c
+++ clang/test/Preprocessor/init-ppc.c
@@ -723,6 +723,16 @@
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc-ibm-aix7.1.0.0 
-fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix 
PPC-AIX-NOTHREADSAFE %s
 // PPC-AIX-NOTHREADSAFE-NOT:#define _THREAD_SAFE 1
 
+// RUN: %clang_cc1 -x c -std=c11 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=gnu11 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char  < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=c17 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char  < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// PPC-AIX-STDC:#define __STDC_NO_ATOMICS__ 1
+// PPC-AIX-STDC:#define __STDC_NO_THREADS__ 1
+
+// RUN: %clang_cc1 -x c -std=c99 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC-N %s
+// PPC-AIX-STDC-N-NOT:#define __STDC_NO_ATOMICS__ 1
+// PPC-AIX-STDC-N-NOT:#define __STDC_NO_THREADS__ 1
+
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc-unknown-linux-gnu 
-fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix 
PPC-LINUX %s
 //
 // PPC-LINUX:#define _ARCH_PPC 1
Index: clang/lib/Basic/Targets/OSTargets.h
===
--- clang/lib/Basic/Targets/OSTargets.h
+++ clang/lib/Basic/Targets/OSTargets.h
@@ -675,6 +675,11 @@
 Builder.defineMacro("_POWER");
 
 Builder.defineMacro("_AIX");
+   
+if (LangStandard::getLangStandardForKind(Opts.LangStd).isC11()) {
+  Builder.defineMacro("__STDC_NO_ATOMICS__");
+  Builder.defineMacro("__STDC_NO_THREADS__");
+}
 
 if (Opts.EnableAIXExtendedAltivecABI)
   Builder.defineMacro("__EXTABI__");


Index: clang/test/Preprocessor/init-ppc.c
===
--- clang/test/Preprocessor/init-ppc.c
+++ clang/test/Preprocessor/init-ppc.c
@@ -723,6 +723,16 @@
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix PPC-AIX-NOTHREADSAFE %s
 // PPC-AIX-NOTHREADSAFE-NOT:#define _THREAD_SAFE 1
 
+// RUN: %clang_cc1 -x c -std=c11 -E -dM -ffreestanding -triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=gnu11 -E -dM -ffreestanding -triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char  < /dev/null | FileCheck -match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=c17 -E -dM -ffreestanding -triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char  < /dev/null | FileCheck -match-full-lines -check-prefix PPC-AIX-STDC %s
+// PPC-AIX-STDC:#define __STDC_NO_ATOMICS__ 1
+// PPC-AIX-STDC:#define __STDC_NO_THREADS__ 1
+
+// RUN: %clang_cc1 -x c -std=c99 -E -dM -ffreestanding -triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix PPC-AIX-STDC-N %s
+// PPC-AIX-STDC-N-NOT:#define __STDC_NO_ATOMICS__ 1
+// PPC-AIX-STDC-N-NOT:#define __STDC_NO_THREADS__ 1
+
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc-unknown-linux-gnu -fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix PPC-LINUX %s
 //
 // PPC-LINUX:#define _ARCH_PPC 1
Index: clang/lib/Basic/Targets/OSTargets.h
===
--- clang/lib/Basic/Targets/OSTargets.h
+++ clang/lib/Basic/Targets/OSTargets.h
@@ -675,6 +675,11 @@
 Builder.defineMacro("_POWER");
 
 Builder.defineMacro("_AIX");
+   
+if (LangStandard::getLangStandardForKind(Opts.LangStd).isC11()) {
+  Builder.defineMacro("__STDC_NO_ATOMICS__");
+  Builder.defineMacro("__STDC_NO_THREADS__");
+}
 
 if (Opts.EnableAIXExtendedAltivecABI)
   Builder.defineMacro("__EXTABI__");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D103184: [AArch64] handle -Wa,-march=

[Nick Desaulniers via Phabricator via cfe-commits]

nickdesaulniers added a comment.

In D103184#2803513 , @thakis wrote:

> This breaks tests on arm macs: http://45.33.8.238/macm1/10931/step_7.txt



>> clang: error: the clang compiler does not support '-Wa,--version'

Wouldn't that be 
https://reviews.llvm.org/rG76d9bc72784d88f4dd57b9939e52c73739438af5 
(https://reviews.llvm.org/D99556)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103184

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

[PATCH] D103241: [OpenCL] Add memory_scope_all_devices

[Anastasia Stulova via Phabricator via cfe-commits]

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

LGTM! Thanks.

Considering that this patch doesn't add anything new to the design, I suggest 
we go ahead. But we should continue the discussion around -cl-ext etc elsewhere 
and then perhaps some follow up patches will be needed to fix this fully.




Comment at: clang/test/Headers/opencl-c-header.cl:154
 // OpenCL C features.
-#if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ == 200)
+#if (__OPENCL_C_VERSION__ == 300)
+

btw I think we are not testing that the macros are not defined for other 
targets than SPIR, but I guess this deserves a separate patch.


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

https://reviews.llvm.org/D103241

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

[PATCH] D101868: [clang-format] Adds a formatter for aligning arrays of structs

[Fred Grim via Phabricator via cfe-commits]

feg208 added a comment.

Ok. Given @HazardyKnusperkeks comment I'll make the default be left alignment 
and update the tests accordingly


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101868

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

[PATCH] D103184: [AArch64] handle -Wa,-march=

[Jian Cai via Phabricator via cfe-commits]

jcai19 added a comment.

In D103184#2803513 , @thakis wrote:

> This breaks tests on arm macs: http://45.33.8.238/macm1/10931/step_7.txt
>
> Please take a look and revert for now if it takes a while to fix.

Thanks, will address the breakage ASAP.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103184

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

[PATCH] D103750: [analyzer][WIP] Handle std::make_unique for SmartPtrModeling

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

Also congrats, sounds like you are to become the first actual user of this API! 
Hope it actually works 爛爛爛


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103750

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

[PATCH] D103750: [analyzer][WIP] Handle std::make_unique for SmartPtrModeling

[Gábor Horváth via Phabricator via cfe-commits]

xazax.hun added a comment.

Whoops, I totally missed your point with my suggestion (should not read it 
while sitting at meetings). But Artem has a great answer already.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103750

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

[PATCH] D103837: [clang] Apply MS ABI details on __builtin_ms_va_list on non-windows platforms on x86_64

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo created this revision.
mstorsjo added a reviewer: rnk.
Herald added a subscriber: pengfei.
mstorsjo requested review of this revision.
Herald added a project: clang.

This fixes inconsistencies in the ms_abi.c testcase.

Also add a couple cases of missing double pointers in the windows part
of the testcase; the outcome of building that testcase on windows hasn't
changed, but the previous form of the test was imprecise (checking
for "%[[STRUCT_FOO]]*" when clang actually generates "%[[STRUCT_FOO]]**"),
which still used to match.

Ideally this would share code with the native Windows case, but
X86_64ABIInfo and WinX86_64ABIInfo aren't superclasses/subclasses of
each other so it's impractical, and the code to share currently only
consists of a couple lines.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D103837

Files:
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/ms_abi.c


Index: clang/test/CodeGen/ms_abi.c
===
--- clang/test/CodeGen/ms_abi.c
+++ clang/test/CodeGen/ms_abi.c
@@ -45,12 +45,12 @@
   // WIN64-NEXT: %[[AP_NEXT:.*]] = getelementptr inbounds i8, i8* %[[AP_CUR]], 
i64 8
   // WIN64-NEXT: store i8* %[[AP_NEXT]], i8** %[[AP]]
   // WIN64-NEXT: bitcast i8* %[[AP_CUR]] to i32*
-  // FIXME: These are different now. We probably need __builtin_ms_va_arg.
   double _Complex c = __builtin_va_arg(ap, double _Complex);
   // FREEBSD: %[[AP_CUR2:.*]] = load i8*, i8** %[[AP]]
-  // FREEBSD-NEXT: %[[AP_NEXT2:.*]] = getelementptr inbounds i8, i8* 
%[[AP_CUR2]], i64 16
+  // FREEBSD-NEXT: %[[AP_NEXT2:.*]] = getelementptr inbounds i8, i8* 
%[[AP_CUR2]], i64 8
   // FREEBSD-NEXT: store i8* %[[AP_NEXT2]], i8** %[[AP]]
-  // FREEBSD-NEXT: bitcast i8* %[[AP_CUR2]] to { double, double }*
+  // FREEBSD-NEXT: %[[CUR2:.*]] = bitcast i8* %[[AP_CUR2]] to { double, double 
}**
+  // FREEBSD-NEXT: load { double, double }*, { double, double }** %[[CUR2]]
   // WIN64: %[[AP_CUR2:.*]] = load i8*, i8** %[[AP]]
   // WIN64-NEXT: %[[AP_NEXT2:.*]] = getelementptr inbounds i8, i8* 
%[[AP_CUR2]], i64 8
   // WIN64-NEXT: store i8* %[[AP_NEXT2]], i8** %[[AP]]
@@ -58,9 +58,10 @@
   // WIN64-NEXT: load { double, double }*, { double, double }** %[[CUR2]]
   struct foo d = __builtin_va_arg(ap, struct foo);
   // FREEBSD: %[[AP_CUR3:.*]] = load i8*, i8** %[[AP]]
-  // FREEBSD-NEXT: %[[AP_NEXT3:.*]] = getelementptr inbounds i8, i8* 
%[[AP_CUR3]], i64 16
+  // FREEBSD-NEXT: %[[AP_NEXT3:.*]] = getelementptr inbounds i8, i8* 
%[[AP_CUR3]], i64 8
   // FREEBSD-NEXT: store i8* %[[AP_NEXT3]], i8** %[[AP]]
-  // FREEBSD-NEXT: bitcast i8* %[[AP_CUR3]] to %[[STRUCT_FOO]]*
+  // FREEBSD-NEXT: %[[CUR3:.*]] = bitcast i8* %[[AP_CUR3]] to %[[STRUCT_FOO]]*
+  // FREEBSD-NEXT: load %[[STRUCT_FOO]]*, %[[STRUCT_FOO]]** %[[CUR3]]
   // WIN64: %[[AP_CUR3:.*]] = load i8*, i8** %[[AP]]
   // WIN64-NEXT: %[[AP_NEXT3:.*]] = getelementptr inbounds i8, i8* 
%[[AP_CUR3]], i64 8
   // WIN64-NEXT: store i8* %[[AP_NEXT3]], i8** %[[AP]]
@@ -123,22 +124,22 @@
   // WIN64-NEXT: bitcast i8* %[[AP_CUR]] to i32*
   double _Complex c = __builtin_va_arg(ap, double _Complex);
   // FREEBSD: %[[AP_CUR2:.*]] = load i8*, i8** %[[AP]]
-  // FREEBSD-NEXT: %[[AP_NEXT2:.*]] = getelementptr inbounds i8, i8* 
%[[AP_CUR2]], i64 16
+  // FREEBSD-NEXT: %[[AP_NEXT2:.*]] = getelementptr inbounds i8, i8* 
%[[AP_CUR2]], i64 8
   // FREEBSD-NEXT: store i8* %[[AP_NEXT2]], i8** %[[AP]]
-  // FREEBSD-NEXT: bitcast i8* %[[AP_CUR2]] to { double, double }*
+  // FREEBSD-NEXT: bitcast i8* %[[AP_CUR2]] to { double, double }**
   // WIN64: %[[AP_CUR2:.*]] = load i8*, i8** %[[AP]]
   // WIN64-NEXT: %[[AP_NEXT2:.*]] = getelementptr inbounds i8, i8* 
%[[AP_CUR2]], i64 8
   // WIN64-NEXT: store i8* %[[AP_NEXT2]], i8** %[[AP]]
-  // WIN64-NEXT: bitcast i8* %[[AP_CUR2]] to { double, double }*
+  // WIN64-NEXT: bitcast i8* %[[AP_CUR2]] to { double, double }**
   struct foo d = __builtin_va_arg(ap, struct foo);
   // FREEBSD: %[[AP_CUR3:.*]] = load i8*, i8** %[[AP]]
-  // FREEBSD-NEXT: %[[AP_NEXT3:.*]] = getelementptr inbounds i8, i8* 
%[[AP_CUR3]], i64 16
+  // FREEBSD-NEXT: %[[AP_NEXT3:.*]] = getelementptr inbounds i8, i8* 
%[[AP_CUR3]], i64 8
   // FREEBSD-NEXT: store i8* %[[AP_NEXT3]], i8** %[[AP]]
-  // FREEBSD-NEXT: bitcast i8* %[[AP_CUR3]] to %[[STRUCT_FOO]]*
+  // FREEBSD-NEXT: bitcast i8* %[[AP_CUR3]] to %[[STRUCT_FOO]]**
   // WIN64: %[[AP_CUR3:.*]] = load i8*, i8** %[[AP]]
   // WIN64-NEXT: %[[AP_NEXT3:.*]] = getelementptr inbounds i8, i8* 
%[[AP_CUR3]], i64 8
   // WIN64-NEXT: store i8* %[[AP_NEXT3]], i8** %[[AP]]
-  // WIN64-NEXT: bitcast i8* %[[AP_CUR3]] to %[[STRUCT_FOO]]*
+  // WIN64-NEXT: bitcast i8* %[[AP_CUR3]] to %[[STRUCT_FOO]]**
   __builtin_ms_va_list ap2;
   __builtin_ms_va_copy(ap2, ap);
   // FREEBSD: %[[AP_VAL:.*]] = load i8*, i8** %[[AP]]
Index: clang/lib/CodeGen/TargetInfo.cpp
===
--- clang/lib/CodeGen/TargetInfo.cpp
+++ 

[PATCH] D101630: [HIP] Add --gpu-bundle-output

[Yaxun Liu via Phabricator via cfe-commits]

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



Comment at: clang/lib/Driver/Driver.cpp:2903
 bool GPUSanitize;
+Optional BundleOutput;
 

tra wrote:
> We should document the behavior we expect from the `--gpu-bundle-output` 
> option in one place. This may be a good place for it. 
> 
> Some day we should add CUDA/HIP section to clang manual. We already have tons 
> of options that users do need to know about.
Will fix the comments when committing.

Yes we should start adding CUDA/HIP documentation to clang manual in future 
patches.


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

https://reviews.llvm.org/D101630

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

[PATCH] D103707: [AIX] Define __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__ predefined macros

[Jake Egan via Phabricator via cfe-commits]

Jake-Egan updated this revision to Diff 350392.
Jake-Egan edited the summary of this revision.
Jake-Egan added a comment.

Prune positive tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103707

Files:
  clang/lib/Basic/Targets/OSTargets.h
  clang/test/Preprocessor/init-ppc.c


Index: clang/test/Preprocessor/init-ppc.c
===
--- clang/test/Preprocessor/init-ppc.c
+++ clang/test/Preprocessor/init-ppc.c
@@ -723,6 +723,15 @@
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc-ibm-aix7.1.0.0 
-fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix 
PPC-AIX-NOTHREADSAFE %s
 // PPC-AIX-NOTHREADSAFE-NOT:#define _THREAD_SAFE 1
 
+// RUN: %clang_cc1 -x c -std=c11 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=gnu11 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char  < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// PPC-AIX-STDC:#define __STDC_NO_ATOMICS__ 1
+// PPC-AIX-STDC:#define __STDC_NO_THREADS__ 1
+
+// RUN: %clang_cc1 -x c -std=c99 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC-N %s
+// PPC-AIX-STDC-N-NOT:#define __STDC_NO_ATOMICS__ 1
+// PPC-AIX-STDC-N-NOT:#define __STDC_NO_THREADS__ 1
+
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc-unknown-linux-gnu 
-fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix 
PPC-LINUX %s
 //
 // PPC-LINUX:#define _ARCH_PPC 1
Index: clang/lib/Basic/Targets/OSTargets.h
===
--- clang/lib/Basic/Targets/OSTargets.h
+++ clang/lib/Basic/Targets/OSTargets.h
@@ -676,6 +676,11 @@
 
 Builder.defineMacro("_AIX");
 
+if (LangStandard::getLangStandardForKind(Opts.LangStd).isC11()) {
+  Builder.defineMacro("__STDC_NO_ATOMICS__");
+  Builder.defineMacro("__STDC_NO_THREADS__");
+}
+
 if (Opts.EnableAIXExtendedAltivecABI)
   Builder.defineMacro("__EXTABI__");
 


Index: clang/test/Preprocessor/init-ppc.c
===
--- clang/test/Preprocessor/init-ppc.c
+++ clang/test/Preprocessor/init-ppc.c
@@ -723,6 +723,15 @@
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix PPC-AIX-NOTHREADSAFE %s
 // PPC-AIX-NOTHREADSAFE-NOT:#define _THREAD_SAFE 1
 
+// RUN: %clang_cc1 -x c -std=c11 -E -dM -ffreestanding -triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=gnu11 -E -dM -ffreestanding -triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char  < /dev/null | FileCheck -match-full-lines -check-prefix PPC-AIX-STDC %s
+// PPC-AIX-STDC:#define __STDC_NO_ATOMICS__ 1
+// PPC-AIX-STDC:#define __STDC_NO_THREADS__ 1
+
+// RUN: %clang_cc1 -x c -std=c99 -E -dM -ffreestanding -triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix PPC-AIX-STDC-N %s
+// PPC-AIX-STDC-N-NOT:#define __STDC_NO_ATOMICS__ 1
+// PPC-AIX-STDC-N-NOT:#define __STDC_NO_THREADS__ 1
+
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc-unknown-linux-gnu -fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix PPC-LINUX %s
 //
 // PPC-LINUX:#define _ARCH_PPC 1
Index: clang/lib/Basic/Targets/OSTargets.h
===
--- clang/lib/Basic/Targets/OSTargets.h
+++ clang/lib/Basic/Targets/OSTargets.h
@@ -676,6 +676,11 @@
 
 Builder.defineMacro("_AIX");
 
+if (LangStandard::getLangStandardForKind(Opts.LangStd).isC11()) {
+  Builder.defineMacro("__STDC_NO_ATOMICS__");
+  Builder.defineMacro("__STDC_NO_THREADS__");
+}
+
 if (Opts.EnableAIXExtendedAltivecABI)
   Builder.defineMacro("__EXTABI__");
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D103777: [X32] Add Triple::isX32(), use it.

[Harald van Dijk 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 rG75521bd9d8d1: [X32] Add Triple::isX32(), use it. (authored 
by hvdijk).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103777

Files:
  clang/lib/Basic/Targets/X86.h
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/lib/Driver/ToolChains/Linux.cpp
  clang/test/Driver/linux-cross.cpp
  llvm/include/llvm/ADT/Triple.h
  llvm/lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp
  llvm/lib/Target/X86/MCTargetDesc/X86MCAsmInfo.cpp
  llvm/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp
  llvm/lib/Target/X86/X86AsmPrinter.cpp
  llvm/lib/Target/X86/X86RegisterInfo.cpp
  llvm/lib/Target/X86/X86Subtarget.h
  llvm/lib/Target/X86/X86TargetMachine.cpp
  llvm/test/CodeGen/X86/x32-lea-1.ll

Index: llvm/test/CodeGen/X86/x32-lea-1.ll
===
--- llvm/test/CodeGen/X86/x32-lea-1.ll
+++ llvm/test/CodeGen/X86/x32-lea-1.ll
@@ -1,5 +1,6 @@
 ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
 ; RUN: llc < %s -mtriple=x86_64-linux-gnux32 -O0 | FileCheck %s
+; RUN: llc < %s -mtriple=x86_64-linux-muslx32 -O0 | FileCheck %s
 
 define void @foo(i32** %p) {
 ; CHECK-LABEL: foo:
Index: llvm/lib/Target/X86/X86TargetMachine.cpp
===
--- llvm/lib/Target/X86/X86TargetMachine.cpp
+++ llvm/lib/Target/X86/X86TargetMachine.cpp
@@ -110,9 +110,7 @@
 
   Ret += DataLayout::getManglingComponent(TT);
   // X86 and x32 have 32 bit pointers.
-  if ((TT.isArch64Bit() &&
-   (TT.getEnvironment() == Triple::GNUX32 || TT.isOSNaCl())) ||
-  !TT.isArch64Bit())
+  if (!TT.isArch64Bit() || TT.isX32() || TT.isOSNaCl())
 Ret += "-p:32:32";
 
   // Address spaces for 32 bit signed, 32 bit unsigned, and 64 bit pointers.
Index: llvm/lib/Target/X86/X86Subtarget.h
===
--- llvm/lib/Target/X86/X86Subtarget.h
+++ llvm/lib/Target/X86/X86Subtarget.h
@@ -610,14 +610,12 @@
 
   /// Is this x86_64 with the ILP32 programming model (x32 ABI)?
   bool isTarget64BitILP32() const {
-return In64BitMode && (TargetTriple.getEnvironment() == Triple::GNUX32 ||
-   TargetTriple.isOSNaCl());
+return In64BitMode && (TargetTriple.isX32() || TargetTriple.isOSNaCl());
   }
 
   /// Is this x86_64 with the LP64 programming model (standard AMD64, no x32)?
   bool isTarget64BitLP64() const {
-return In64BitMode && (TargetTriple.getEnvironment() != Triple::GNUX32 &&
-   !TargetTriple.isOSNaCl());
+return In64BitMode && (!TargetTriple.isX32() && !TargetTriple.isOSNaCl());
   }
 
   PICStyles::Style getPICStyle() const { return PICStyle; }
Index: llvm/lib/Target/X86/X86RegisterInfo.cpp
===
--- llvm/lib/Target/X86/X86RegisterInfo.cpp
+++ llvm/lib/Target/X86/X86RegisterInfo.cpp
@@ -62,7 +62,7 @@
 // This matches the simplified 32-bit pointer code in the data layout
 // computation.
 // FIXME: Should use the data layout?
-bool Use64BitReg = TT.getEnvironment() != Triple::GNUX32;
+bool Use64BitReg = !TT.isX32();
 StackPtr = Use64BitReg ? X86::RSP : X86::ESP;
 FramePtr = Use64BitReg ? X86::RBP : X86::EBP;
 BasePtr = Use64BitReg ? X86::RBX : X86::EBX;
Index: llvm/lib/Target/X86/X86AsmPrinter.cpp
===
--- llvm/lib/Target/X86/X86AsmPrinter.cpp
+++ llvm/lib/Target/X86/X86AsmPrinter.cpp
@@ -643,8 +643,7 @@
   OutStreamer->SwitchSection(Nt);
 
   // Emitting note header.
-  const int WordSize =
-  TT.isArch64Bit() && TT.getEnvironment() != Triple::GNUX32 ? 8 : 4;
+  const int WordSize = TT.isArch64Bit() && !TT.isX32() ? 8 : 4;
   emitAlignment(WordSize == 4 ? Align(4) : Align(8));
   OutStreamer->emitIntValue(4, 4 /*size*/); // data size for "GNU\0"
   OutStreamer->emitIntValue(8 + WordSize, 4 /*size*/); // Elf_Prop size
Index: llvm/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp
===
--- llvm/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp
+++ llvm/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp
@@ -1231,8 +1231,7 @@
   // FIXME: The caller of determineREXPrefix slaps this prefix onto
   // anything that returns non-zero.
   REX |= 0x40; // REX fixed encoding prefix
-  } else if (MO.isExpr() &&
- STI.getTargetTriple().getEnvironment() == Triple::GNUX32) {
+  } else if (MO.isExpr() && STI.getTargetTriple().isX32()) {
 // GOTTPOFF and TLSDESC relocations require a REX prefix to allow
 // linker optimizations: even if the instructions we see may not 

[clang] 75521bd - [X32] Add Triple::isX32(), use it.

[Harald van Dijk via cfe-commits]

Author: Harald van Dijk
Date: 2021-06-07T20:48:39+01:00
New Revision: 75521bd9d8d1e39b1a765a14d95c49291d2adde5

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

LOG: [X32] Add Triple::isX32(), use it.

So far, support for x86_64-linux-gnux32 has been handled by explicit
comparisons of Triple.getEnvironment() to GNUX32. This worked as long as
x86_64-linux-gnux32 was the only X32 environment to worry about, but we
now have x86_64-linux-muslx32 as well. To support this, this change adds
an isX32() function and uses it. It replaces all checks for GNUX32 or
MuslX32 by isX32(), except for the following:

- Triple::isGNUEnvironment() and Triple::isMusl() are supposed to treat
  GNUX32 and MuslX32 differently.
- computeTargetTriple() needs to be able to transform triples to add or
  remove X32 from the environment and needs to map GNU to GNUX32, and
  Musl to MuslX32.
- getMultiarchTriple() completely lacks any Musl support and retains the
  explicit check for GNUX32 as it can only return x86_64-linux-gnux32.

Reviewed By: MaskRay

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

Added: 


Modified: 
clang/lib/Basic/Targets/X86.h
clang/lib/Driver/Driver.cpp
clang/lib/Driver/ToolChains/Gnu.cpp
clang/lib/Driver/ToolChains/Linux.cpp
clang/test/Driver/linux-cross.cpp
llvm/include/llvm/ADT/Triple.h
llvm/lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp
llvm/lib/Target/X86/MCTargetDesc/X86MCAsmInfo.cpp
llvm/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp
llvm/lib/Target/X86/X86AsmPrinter.cpp
llvm/lib/Target/X86/X86RegisterInfo.cpp
llvm/lib/Target/X86/X86Subtarget.h
llvm/lib/Target/X86/X86TargetMachine.cpp
llvm/test/CodeGen/X86/x32-lea-1.ll

Removed: 




diff  --git a/clang/lib/Basic/Targets/X86.h b/clang/lib/Basic/Targets/X86.h
index 0ba2fd6ba024..7639ea835ebc 100644
--- a/clang/lib/Basic/Targets/X86.h
+++ b/clang/lib/Basic/Targets/X86.h
@@ -661,7 +661,7 @@ class LLVM_LIBRARY_VISIBILITY X86_64TargetInfo : public 
X86TargetInfo {
 public:
   X86_64TargetInfo(const llvm::Triple , const TargetOptions )
   : X86TargetInfo(Triple, Opts) {
-const bool IsX32 = getTriple().getEnvironment() == llvm::Triple::GNUX32;
+const bool IsX32 = getTriple().isX32();
 bool IsWinCOFF =
 getTriple().isOSWindows() && getTriple().isOSBinFormatCOFF();
 LongWidth = LongAlign = PointerWidth = PointerAlign = IsX32 ? 32 : 64;

diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 287b21864154..cd2c8c9b1916 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -519,14 +519,21 @@ static llvm::Triple computeTargetTriple(const Driver ,
   AT = Target.get64BitArchVariant().getArch();
   if (Target.getEnvironment() == llvm::Triple::GNUX32)
 Target.setEnvironment(llvm::Triple::GNU);
+  else if (Target.getEnvironment() == llvm::Triple::MuslX32)
+Target.setEnvironment(llvm::Triple::Musl);
 } else if (A->getOption().matches(options::OPT_mx32) &&
Target.get64BitArchVariant().getArch() == llvm::Triple::x86_64) 
{
   AT = llvm::Triple::x86_64;
-  Target.setEnvironment(llvm::Triple::GNUX32);
+  if (Target.getEnvironment() == llvm::Triple::Musl)
+Target.setEnvironment(llvm::Triple::MuslX32);
+  else
+Target.setEnvironment(llvm::Triple::GNUX32);
 } else if (A->getOption().matches(options::OPT_m32)) {
   AT = Target.get32BitArchVariant().getArch();
   if (Target.getEnvironment() == llvm::Triple::GNUX32)
 Target.setEnvironment(llvm::Triple::GNU);
+  else if (Target.getEnvironment() == llvm::Triple::MuslX32)
+Target.setEnvironment(llvm::Triple::Musl);
 } else if (A->getOption().matches(options::OPT_m16) &&
Target.get32BitArchVariant().getArch() == llvm::Triple::x86) {
   AT = llvm::Triple::x86;

diff  --git a/clang/lib/Driver/ToolChains/Gnu.cpp 
b/clang/lib/Driver/ToolChains/Gnu.cpp
index a27841dc5985..517ba60e0b77 100644
--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -294,7 +294,7 @@ static const char *getLDMOption(const llvm::Triple , 
const ArgList ) {
   case llvm::Triple::systemz:
 return "elf64_s390";
   case llvm::Triple::x86_64:
-if (T.getEnvironment() == llvm::Triple::GNUX32)
+if (T.isX32())
   return "elf32_x86_64";
 return "elf_x86_64";
   case llvm::Triple::ve:
@@ -725,7 +725,7 @@ void tools::gnutools::Assembler::ConstructJob(Compilation 
,
 CmdArgs.push_back("--32");
 break;
   case llvm::Triple::x86_64:
-if (getToolChain().getTriple().getEnvironment() == llvm::Triple::GNUX32)
+if (getToolChain().getTriple().isX32())
   CmdArgs.push_back("--x32");
 else
   

[clang] 6de45b9 - [clang] Fix reading long doubles with va_arg on x86_64 mingw

[Martin Storsjö via cfe-commits]

Author: Martin Storsjö
Date: 2021-06-07T22:34:10+03:00
New Revision: 6de45b9e6a2c4b69ca82916a4cc1b4b8636d79b3

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

LOG: [clang] Fix reading long doubles with va_arg on x86_64 mingw

On x86_64 mingw, long doubles are always passed indirectly as
arguments (see an existing case in WinX86_64ABIInfo::classify);
generalize the existing code for reading varargs - any non-aggregate
type that is larger than 64 bits (which would be both long double
in mingw, and __int128) are passed indirectly too.

This makes reading varargs consistent with how they're passed,
fixing interop with both gcc and clang callers, for long double
and __int128.

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

Added: 


Modified: 
clang/lib/CodeGen/TargetInfo.cpp
clang/test/CodeGen/mingw-long-double.c
clang/test/CodeGen/win64-i128.c
clang/test/CodeGenCXX/ext-int.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/TargetInfo.cpp 
b/clang/lib/CodeGen/TargetInfo.cpp
index af516bbc8d31..440153c45e80 100644
--- a/clang/lib/CodeGen/TargetInfo.cpp
+++ b/clang/lib/CodeGen/TargetInfo.cpp
@@ -4358,15 +4358,10 @@ void WinX86_64ABIInfo::computeInfo(CGFunctionInfo ) 
const {
 
 Address WinX86_64ABIInfo::EmitVAArg(CodeGenFunction , Address VAListAddr,
 QualType Ty) const {
-
-  bool IsIndirect = false;
-
   // MS x64 ABI requirement: "Any argument that doesn't fit in 8 bytes, or is
   // not 1, 2, 4, or 8 bytes, must be passed by reference."
-  if (isAggregateTypeForABI(Ty) || Ty->isMemberPointerType()) {
-uint64_t Width = getContext().getTypeSize(Ty);
-IsIndirect = Width > 64 || !llvm::isPowerOf2_64(Width);
-  }
+  uint64_t Width = getContext().getTypeSize(Ty);
+  bool IsIndirect = Width > 64 || !llvm::isPowerOf2_64(Width);
 
   return emitVoidPtrVAArg(CGF, VAListAddr, Ty, IsIndirect,
   CGF.getContext().getTypeInfoInChars(Ty),

diff  --git a/clang/test/CodeGen/mingw-long-double.c 
b/clang/test/CodeGen/mingw-long-double.c
index b953192fcab7..39ce46898485 100644
--- a/clang/test/CodeGen/mingw-long-double.c
+++ b/clang/test/CodeGen/mingw-long-double.c
@@ -45,3 +45,19 @@ long double _Complex TestLDC(long double _Complex x) {
 // GNU32: declare dso_local void @__mulxc3
 // GNU64: declare dso_local void @__mulxc3
 // MSC64: declare dso_local void @__muldc3
+
+void VarArgLD(int a, ...) {
+  // GNU32-LABEL: define{{.*}} void @VarArgLD
+  // GNU64-LABEL: define{{.*}} void @VarArgLD
+  // MSC64-LABEL: define{{.*}} void @VarArgLD
+  __builtin_va_list ap;
+  __builtin_va_start(ap, a);
+  long double LD = __builtin_va_arg(ap, long double);
+  // GNU32-NOT: load x86_fp80*, x86_fp80**
+  // GNU32: load x86_fp80, x86_fp80*
+  // GNU64: load x86_fp80*, x86_fp80**
+  // GNU64: load x86_fp80, x86_fp80*
+  // MSC64-NOT: load double*, double**
+  // MSC64: load double, double*
+  __builtin_va_end(ap);
+}

diff  --git a/clang/test/CodeGen/win64-i128.c b/clang/test/CodeGen/win64-i128.c
index 6031147b353d..fe32c57e99cf 100644
--- a/clang/test/CodeGen/win64-i128.c
+++ b/clang/test/CodeGen/win64-i128.c
@@ -14,3 +14,16 @@ int128_t bar(int128_t a, int128_t b) { return a * b; }
 
 // GNU64: define dso_local <2 x i64> @bar(i128* %0, i128* %1)
 // MSC64: define dso_local <2 x i64> @bar(i128* %0, i128* %1)
+
+void vararg(int a, ...) {
+  // GNU64-LABEL: define{{.*}} void @vararg
+  // MSC64-LABEL: define{{.*}} void @vararg
+  __builtin_va_list ap;
+  __builtin_va_start(ap, a);
+  int128_t i = __builtin_va_arg(ap, int128_t);
+  // GNU64: load i128*, i128**
+  // GNU64: load i128, i128*
+  // MSC64: load i128*, i128**
+  // MSC64: load i128, i128*
+  __builtin_va_end(ap);
+}

diff  --git a/clang/test/CodeGenCXX/ext-int.cpp 
b/clang/test/CodeGenCXX/ext-int.cpp
index 99ebe9454df2..7f3bc07e98dd 100644
--- a/clang/test/CodeGenCXX/ext-int.cpp
+++ b/clang/test/CodeGenCXX/ext-int.cpp
@@ -164,10 +164,11 @@ void TakesVarargs(int i, ...) {
   // LIN: store i92 %[[LOAD1]], i92*
 
   // WIN: %[[CUR1:.+]] = load i8*, i8** %[[ARGS]]
-  // WIN: %[[NEXT1:.+]] = getelementptr inbounds i8, i8* %[[CUR1]], i64 16
+  // WIN: %[[NEXT1:.+]] = getelementptr inbounds i8, i8* %[[CUR1]], i64 8
   // WIN: store i8* %[[NEXT1]], i8** %[[ARGS]]
-  // WIN: %[[BC1:.+]] = bitcast i8* %[[CUR1]] to i92*
-  // WIN: %[[LOADV1:.+]] = load i92, i92* %[[BC1]]
+  // WIN: %[[BC1:.+]] = bitcast i8* %[[CUR1]] to i92**
+  // WIN: %[[LOADP1:.+]] = load i92*, i92** %[[BC1]]
+  // WIN: %[[LOADV1:.+]] = load i92, i92* %[[LOADP1]]
   // WIN: store i92 %[[LOADV1]], i92*
 
   _ExtInt(31) B = __builtin_va_arg(args, _ExtInt(31));
@@ -215,10 +216,11 @@ void TakesVarargs(int i, ...) {
   // LIN: store i129 %[[LOAD4]], i129*
 
   // WIN: %[[CUR4:.+]] = load i8*, i8** %[[ARGS]]
-  // 

[PATCH] D103452: [clang] Fix reading long doubles with va_arg on x86_64 mingw

[Martin Storsjö via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG6de45b9e6a2c: [clang] Fix reading long doubles with va_arg 
on x86_64 mingw (authored by mstorsjo).

Changed prior to commit:
  https://reviews.llvm.org/D103452?vs=349517=350390#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103452

Files:
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/mingw-long-double.c
  clang/test/CodeGen/win64-i128.c
  clang/test/CodeGenCXX/ext-int.cpp

Index: clang/test/CodeGenCXX/ext-int.cpp
===
--- clang/test/CodeGenCXX/ext-int.cpp
+++ clang/test/CodeGenCXX/ext-int.cpp
@@ -164,10 +164,11 @@
   // LIN: store i92 %[[LOAD1]], i92*
 
   // WIN: %[[CUR1:.+]] = load i8*, i8** %[[ARGS]]
-  // WIN: %[[NEXT1:.+]] = getelementptr inbounds i8, i8* %[[CUR1]], i64 16
+  // WIN: %[[NEXT1:.+]] = getelementptr inbounds i8, i8* %[[CUR1]], i64 8
   // WIN: store i8* %[[NEXT1]], i8** %[[ARGS]]
-  // WIN: %[[BC1:.+]] = bitcast i8* %[[CUR1]] to i92*
-  // WIN: %[[LOADV1:.+]] = load i92, i92* %[[BC1]]
+  // WIN: %[[BC1:.+]] = bitcast i8* %[[CUR1]] to i92**
+  // WIN: %[[LOADP1:.+]] = load i92*, i92** %[[BC1]]
+  // WIN: %[[LOADV1:.+]] = load i92, i92* %[[LOADP1]]
   // WIN: store i92 %[[LOADV1]], i92*
 
   _ExtInt(31) B = __builtin_va_arg(args, _ExtInt(31));
@@ -215,10 +216,11 @@
   // LIN: store i129 %[[LOAD4]], i129*
 
   // WIN: %[[CUR4:.+]] = load i8*, i8** %[[ARGS]]
-  // WIN: %[[NEXT4:.+]] = getelementptr inbounds i8, i8* %[[CUR4]], i64 24
+  // WIN: %[[NEXT4:.+]] = getelementptr inbounds i8, i8* %[[CUR4]], i64 8
   // WIN: store i8* %[[NEXT4]], i8** %[[ARGS]]
-  // WIN: %[[BC4:.+]] = bitcast i8* %[[CUR4]] to i129*
-  // WIN: %[[LOADV4:.+]] = load i129, i129* %[[BC4]]
+  // WIN: %[[BC4:.+]] = bitcast i8* %[[CUR4]] to i129**
+  // WIN: %[[LOADP4:.+]] = load i129*, i129** %[[BC4]]
+  // WIN: %[[LOADV4:.+]] = load i129, i129* %[[LOADP4]]
   // WIN: store i129 %[[LOADV4]], i129*
 
   _ExtInt(16777200) E = __builtin_va_arg(args, _ExtInt(16777200));
@@ -232,10 +234,11 @@
   // LIN: store i16777200 %[[LOAD5]], i16777200*
 
   // WIN: %[[CUR5:.+]] = load i8*, i8** %[[ARGS]]
-  // WIN: %[[NEXT5:.+]] = getelementptr inbounds i8, i8* %[[CUR5]], i64 2097152
+  // WIN: %[[NEXT5:.+]] = getelementptr inbounds i8, i8* %[[CUR5]], i64 8
   // WIN: store i8* %[[NEXT5]], i8** %[[ARGS]]
-  // WIN: %[[BC5:.+]] = bitcast i8* %[[CUR5]] to i16777200*
-  // WIN: %[[LOADV5:.+]] = load i16777200, i16777200* %[[BC5]]
+  // WIN: %[[BC5:.+]] = bitcast i8* %[[CUR5]] to i16777200**
+  // WIN: %[[LOADP5:.+]] = load i16777200*, i16777200** %[[BC5]]
+  // WIN: %[[LOADV5:.+]] = load i16777200, i16777200* %[[LOADP5]]
   // WIN: store i16777200 %[[LOADV5]], i16777200*
 
   __builtin_va_end(args);
Index: clang/test/CodeGen/win64-i128.c
===
--- clang/test/CodeGen/win64-i128.c
+++ clang/test/CodeGen/win64-i128.c
@@ -14,3 +14,16 @@
 
 // GNU64: define dso_local <2 x i64> @bar(i128* %0, i128* %1)
 // MSC64: define dso_local <2 x i64> @bar(i128* %0, i128* %1)
+
+void vararg(int a, ...) {
+  // GNU64-LABEL: define{{.*}} void @vararg
+  // MSC64-LABEL: define{{.*}} void @vararg
+  __builtin_va_list ap;
+  __builtin_va_start(ap, a);
+  int128_t i = __builtin_va_arg(ap, int128_t);
+  // GNU64: load i128*, i128**
+  // GNU64: load i128, i128*
+  // MSC64: load i128*, i128**
+  // MSC64: load i128, i128*
+  __builtin_va_end(ap);
+}
Index: clang/test/CodeGen/mingw-long-double.c
===
--- clang/test/CodeGen/mingw-long-double.c
+++ clang/test/CodeGen/mingw-long-double.c
@@ -45,3 +45,19 @@
 // GNU32: declare dso_local void @__mulxc3
 // GNU64: declare dso_local void @__mulxc3
 // MSC64: declare dso_local void @__muldc3
+
+void VarArgLD(int a, ...) {
+  // GNU32-LABEL: define{{.*}} void @VarArgLD
+  // GNU64-LABEL: define{{.*}} void @VarArgLD
+  // MSC64-LABEL: define{{.*}} void @VarArgLD
+  __builtin_va_list ap;
+  __builtin_va_start(ap, a);
+  long double LD = __builtin_va_arg(ap, long double);
+  // GNU32-NOT: load x86_fp80*, x86_fp80**
+  // GNU32: load x86_fp80, x86_fp80*
+  // GNU64: load x86_fp80*, x86_fp80**
+  // GNU64: load x86_fp80, x86_fp80*
+  // MSC64-NOT: load double*, double**
+  // MSC64: load double, double*
+  __builtin_va_end(ap);
+}
Index: clang/lib/CodeGen/TargetInfo.cpp
===
--- clang/lib/CodeGen/TargetInfo.cpp
+++ clang/lib/CodeGen/TargetInfo.cpp
@@ -4358,15 +4358,10 @@
 
 Address WinX86_64ABIInfo::EmitVAArg(CodeGenFunction , Address VAListAddr,
 QualType Ty) const {
-
-  bool IsIndirect = false;
-
   // MS x64 ABI requirement: "Any argument that doesn't fit in 8 bytes, or is
   // not 1, 2, 4, or 8 bytes, must be passed by reference."
-  if 

[PATCH] D103611: Correct the behavior of va_arg checking in C++

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/Sema/SemaExpr.cpp:15783
+  // test for typesAreCompatible() will already properly consider those to
+  // be compatible types.
+  if (Context.getLangOpts().CPlusPlus && !PromoteType.isNull() &&

efriedma wrote:
> This explanation doesn't seem right.  Signed and unsigned types are never 
> considered "compatible".
> 
> If I'm understanding correctly, the case this code addresses is promotion 
> according to `[conv.prom]`p3: "A prvalue of an unscoped enumeration type 
> whose underlying type is not fixed [...]".  Somehow, the enum ends up with an 
> unsigned underlying type, but we promote to int?  And this doesn't happen in 
> C somehow?
> This explanation doesn't seem right. Signed and unsigned types are never 
> considered "compatible".

Good point, I think that comment is wrong.

> If I'm understanding correctly, the case this code addresses is promotion 
> according to [conv.prom]p3: "A prvalue of an unscoped enumeration type whose 
> underlying type is not fixed [...]". Somehow, the enum ends up with an 
> unsigned underlying type, but we promote to int? And this doesn't happen in C 
> somehow?

That's correct. What I am seeing is:
```
enum Unscoped { One = 0x7FFF };
```
C++:
`PromoteType` = Builtin (Int)
`UnderlyingType` = Builtin (UInt)

C:
`PromoteType` = Builtin (UInt)
`UnderlyingType` = Builtin (UInt)


`enum Unscoped { One = 0x };`

C++:
`PromoteType` = Builtin (UInt)
`UnderlyingType` = Builtin (UInt)

C:
`PromoteType` = Builtin (UInt)
`UnderlyingType` = Builtin (UInt)

At least on i386-pc-unknown.

So I think this code is almost correct for that test, but is over-constrained 
by only doing this in C++. WDYT?


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

https://reviews.llvm.org/D103611

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

[PATCH] D103750: [analyzer][WIP] Handle std::make_unique for SmartPtrModeling

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

In D103750#2803516 , @RedDocMD wrote:

> In D103750#2803499 , @NoQ wrote:
>
>> Ugh, this entire `checkBind` hack was so unexpected that I didn't even 
>> recognize `evalCall`. What prevents you from doing everything in `evalCall`? 
>> No state traits, no nothing, just directly take the this-region and attach 
>> the value to it?
>
> Because in `evalCall`, I don't have access to the `ThisRegion`.

You do have access to it. That's how C++ works: the call constructs the value 
directly into the target this-region. In code

  auto a = std::make_unique(100)

it is known even before `std::make_unique` is invoked (i.e., even in 
`checkPreCall`) that the this-region for the call is going to be `a`. Because 
it's up to the call to invoke the constructor of the external object, and you 
can't invoke a constructor if you don't have a `this` to pass into it. //You 
cannot ever have an object and not have `this`.
//
Even if it wasn't for RVO, you would have known the temporary region in which 
the smart pointer would originally reside.

This was the whole point of the CFG work described in 
https://www.youtube.com/watch?v=4n3l-ZcDJNY

You're looking in the wrong place though, as `std::make_unique` returns the 
structure by value (aka prvalue), so the value of the expression, even if 
available before the call, was never going to be `this` (which would have been 
the corresponding glvalue). What you're looking for is 
`CallEvent::getReturnValueUnderConstruction()`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103750

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

[PATCH] D103777: [X32] Add Triple::isX32(), use it.

[Fangrui Song via Phabricator via cfe-commits]

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

LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103777

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

[PATCH] D103750: [analyzer][WIP] Handle std::make_unique for SmartPtrModeling

[Gábor Horváth via Phabricator via cfe-commits]

xazax.hun added a comment.

In D103750#2803516 , @RedDocMD wrote:

> In D103750#2803499 , @NoQ wrote:
>
>> Ugh, this entire `checkBind` hack was so unexpected that I didn't even 
>> recognize `evalCall`. What prevents you from doing everything in `evalCall`? 
>> No state traits, no nothing, just directly take the this-region and attach 
>> the value to it?
>
> Because in `evalCall`, I don't have access to the `ThisRegion`. At least I 
> think I don't.

Did you consider trying to get it from `CXXInstanceCall::getCXXThisVal`? 
Usually, if you cannot access something you need, that is a bug in the 
analyzer. But I found that this is very rarely the case. Most of the callbacks 
are very well thought out and already gives access to most of the information 
you might want to access.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103750

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

[PATCH] D103707: [AIX] Define __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__ predefined macros

[Chris Bowler via Phabricator via cfe-commits]

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

Would like you to prune the new tests, then I think this will be ready to land.




Comment at: clang/test/Preprocessor/init-ppc.c:726
 
+// RUN: %clang_cc1 -x c -std=c11 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=c1x -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s

Suggest pruning some of these.  I don't think it's necessary to test every 
visible -std level.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103707

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

[PATCH] D103806: [SystemZ][z/OS] Pass OpenFlags when creating tmp files

[Abhina Sree via Phabricator via cfe-commits]

abhina.sreeskantharajan updated this revision to Diff 350386.
abhina.sreeskantharajan added a comment.

Address rnk's comments and rename to ExtraFlags


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103806

Files:
  clang/lib/Frontend/CompilerInstance.cpp
  llvm/include/llvm/Support/FileSystem.h
  llvm/lib/Support/Path.cpp


Index: llvm/lib/Support/Path.cpp
===
--- llvm/lib/Support/Path.cpp
+++ llvm/lib/Support/Path.cpp
@@ -1288,11 +1288,12 @@
   return Error::success();
 }
 
-Expected TempFile::create(const Twine , unsigned Mode) {
+Expected TempFile::create(const Twine , unsigned Mode,
+OpenFlags ExtraFlags) {
   int FD;
   SmallString<128> ResultPath;
   if (std::error_code EC =
-  createUniqueFile(Model, FD, ResultPath, OF_Delete, Mode))
+  createUniqueFile(Model, FD, ResultPath, OF_Delete | ExtraFlags, 
Mode))
 return errorCodeToError(EC);
 
   TempFile Ret(ResultPath, FD);
Index: llvm/include/llvm/Support/FileSystem.h
===
--- llvm/include/llvm/Support/FileSystem.h
+++ llvm/include/llvm/Support/FileSystem.h
@@ -857,7 +857,8 @@
   /// This creates a temporary file with createUniqueFile and schedules it for
   /// deletion with sys::RemoveFileOnSignal.
   static Expected create(const Twine ,
-   unsigned Mode = all_read | all_write);
+   unsigned Mode = all_read | all_write,
+   OpenFlags ExtraFlags = OF_None);
   TempFile(TempFile &);
   TempFile =(TempFile &);
 
Index: clang/lib/Frontend/CompilerInstance.cpp
===
--- clang/lib/Frontend/CompilerInstance.cpp
+++ clang/lib/Frontend/CompilerInstance.cpp
@@ -828,7 +828,9 @@
 TempPath += OutputExtension;
 TempPath += ".tmp";
 Expected ExpectedFile =
-llvm::sys::fs::TempFile::create(TempPath);
+llvm::sys::fs::TempFile::create(
+TempPath, llvm::sys::fs::all_read | llvm::sys::fs::all_write,
+Binary ? llvm::sys::fs::OF_None : llvm::sys::fs::OF_Text);
 
 llvm::Error E = handleErrors(
 ExpectedFile.takeError(), [&](const llvm::ECError ) -> llvm::Error {


Index: llvm/lib/Support/Path.cpp
===
--- llvm/lib/Support/Path.cpp
+++ llvm/lib/Support/Path.cpp
@@ -1288,11 +1288,12 @@
   return Error::success();
 }
 
-Expected TempFile::create(const Twine , unsigned Mode) {
+Expected TempFile::create(const Twine , unsigned Mode,
+OpenFlags ExtraFlags) {
   int FD;
   SmallString<128> ResultPath;
   if (std::error_code EC =
-  createUniqueFile(Model, FD, ResultPath, OF_Delete, Mode))
+  createUniqueFile(Model, FD, ResultPath, OF_Delete | ExtraFlags, Mode))
 return errorCodeToError(EC);
 
   TempFile Ret(ResultPath, FD);
Index: llvm/include/llvm/Support/FileSystem.h
===
--- llvm/include/llvm/Support/FileSystem.h
+++ llvm/include/llvm/Support/FileSystem.h
@@ -857,7 +857,8 @@
   /// This creates a temporary file with createUniqueFile and schedules it for
   /// deletion with sys::RemoveFileOnSignal.
   static Expected create(const Twine ,
-   unsigned Mode = all_read | all_write);
+   unsigned Mode = all_read | all_write,
+   OpenFlags ExtraFlags = OF_None);
   TempFile(TempFile &);
   TempFile =(TempFile &);
 
Index: clang/lib/Frontend/CompilerInstance.cpp
===
--- clang/lib/Frontend/CompilerInstance.cpp
+++ clang/lib/Frontend/CompilerInstance.cpp
@@ -828,7 +828,9 @@
 TempPath += OutputExtension;
 TempPath += ".tmp";
 Expected ExpectedFile =
-llvm::sys::fs::TempFile::create(TempPath);
+llvm::sys::fs::TempFile::create(
+TempPath, llvm::sys::fs::all_read | llvm::sys::fs::all_write,
+Binary ? llvm::sys::fs::OF_None : llvm::sys::fs::OF_Text);
 
 llvm::Error E = handleErrors(
 ExpectedFile.takeError(), [&](const llvm::ECError ) -> llvm::Error {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D103806: [SystemZ][z/OS] Pass OpenFlags when creating tmp files

[Reid Kleckner via Phabricator via cfe-commits]

rnk added inline comments.



Comment at: llvm/lib/Support/Path.cpp:1295
   SmallString<128> ResultPath;
-  if (std::error_code EC =
-  createUniqueFile(Model, FD, ResultPath, OF_Delete, Mode))
+  if (std::error_code EC = createUniqueFile(Model, FD, ResultPath, Flags, 
Mode))
 return errorCodeToError(EC);

abhina.sreeskantharajan wrote:
> rnk wrote:
> > Instead of requiring the caller to add `OF_Delete`, I think it would be 
> > better to pass `OF_Delete | Flags` here.
> Sure, I'll make that change. Do you think we should change the name to 
> "ExtraFlags" to indicate there is a default, or is the current name is fine?
That seems reasonable to me, I like `ExtraFlags`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103806

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

[PATCH] D103452: [clang] Fix reading long doubles with va_arg on x86_64 mingw

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo added inline comments.



Comment at: clang/test/CodeGen/mingw-long-double.c:56-58
+  // GNU32: bitcast i8* %argp.cur to x86_fp80*
+  // GNU64: bitcast i8* %argp.cur to x86_fp80**
+  // MSC64: bitcast i8* %argp.cur to double*

rnk wrote:
> mstorsjo wrote:
> > mstorsjo wrote:
> > > rnk wrote:
> > > > These tests will stop working after opaque pointers happens, which I 
> > > > hope comes in the next year. If you look for a load of the pointer 
> > > > type, that should be resilient to opaque pointers.
> > > Hmm, good point, but the test feels more brittle to me in that form:
> > > 
> > > ```
> > >   // GNU32: load x86_fp80, x86_fp80*
> > >   // GNU64: load x86_fp80*, x86_fp80**
> > >   // GNU64: load x86_fp80, x86_fp80*
> > >   // MSC64: load double, double*
> > > ```
> > > 
> > > That wouldn't notice if GNU32 also used an indirect pointer for this case 
> > > (as it would still match the second load - but it would notice if GNU64 
> > > stopped using an indirect pointer as the first load wouldn't be matched). 
> > > I guess it'd be safer if I'd use more named regex patterns in the test to 
> > > follow the chain from the argp, but then we end up with a pattern 
> > > covering the bits that change due to opaque pointers too.
> > @rnk - WDYT about how to write the test patterns - see above?
> I guess the only two ideas I have are to try out update_cc_test_checks.py or 
> to CHECK-NOT for the indirect load.
Ok, CHECK-NOT sounds like a sensible compromise in making it more robust.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103452

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

[PATCH] D103317: [Analyzer][engine][solver] Simplify complex constraints

[Valeriy Savchenko via Phabricator via cfe-commits]

vsavchenko added a comment.

In D103317#2803238 , @ASDenysPetrov 
wrote:

> @vsavchenko
>
> I appologize for my immaturity and for the audacity of my infantile 
> assumptions. I admit any constructive criticism. Thank you for referencing 
> the theory. I will thoroughly study the domain in all.

No need to apologize!  I do like your enthusiasm, great things come from it.  
But as I said, I don't want you to waste your own time pursuing things that 
won't work.

> As for the **assignments** and why I brought them up, that's because I just 
> tried to look at the problem from another angle. Consider two snippets:

OK, let me annotate the code, so we can hopefully close this topic once and for 
all.

>   void f(int a, int b, int c, int x, int y){

At this point we have 5 memory regions `a`, `b`, `c`, `x` and `y`.  They 
represent the memory cells allocated for the corresponding parameters on stack. 
 When we call function, these actually have some values, but we don't know them 
due to the limitations of the analysis.  For this reason, we say that they 
contain **symbolic values**. So, let's simply enumerate that so that there is 
no misunderstanding. Values: #1, #2, #3, #4, and #5. These are not real 
numbers, we enumerate some unknown values.  As I said, we introduced them as 
initial values for parameters, so our store (mapping from memory to values) 
looks likes this: `a -> #1, b -> #2, c -> #3, x -> #4, y -> #5`.  We don't know 
anything about these values at this point.

>   a = b;

What do we know at this point? Do we get more information about the value that 
was stored in `a` before? No, we overwrote this value entirely, and what 
changed here is the mapping: `a -> #2, b -> #2, c -> #3, x -> #4, y -> #5` 
because `b` contained value `#2`.  Symbolic value `#1` is gone, it's dead.  
No-one will ever see or use it again.

>   x = y;

Using the same logic: `a -> #2, b -> #2, c -> #3, x -> #5, y -> #5`.

>   c = a;

And again: `a -> #2, b -> #2, c -> #2, x -> #5, y -> #5`.

> // What can you say about a, x, c?
> // `a` equals to `b` and 'c'
> // `x` equals to `y`
> // `c` equals to `a` and `b`
>   }

Yes, they are, but we don't need constraints for that.  We know which values 
are associated with each memory region and we can compare them.  That's all, 
this simple.  That's why assignments and initializations DON'T MATTER for the 
solver, these are simply STORE of some symbolic value into memory.  Solver 
cares only about symbolic values, memory is irrelevant.

> and
>
>   void f(int a, int b, int c, int x, int y){

As before: `a -> #1, b -> #2, c -> #3, x -> #4, y -> #5`.

>   if(a == b) {

Now, the value that we imagine to be in memory region `a` (namely `#1`) is NOT 
GONE!  It is still there, it is being used.  And what we know after this `if`, 
is that on one of the paths after it `#1 == #2` and on the other path `#1 != 
#2`.  These are just values that we know nothing about, but we started to gain 
some knowledge.
So, the store is the same (the values stored in those memory cell are the same 
as they were before): `a -> #1, b -> #2, c -> #3, x -> #4, y -> #5`, but now we 
add constraint `#1 == #2`.

>   if(x == y) {

The same here, store is the same, but constraints are now: `#1 == #2` and `#4 
== #5`.

>   if(c == a) {

`#1 == #2 == #3` and `#4 == #5`

>   // What can you say about a, x, c?
>   // `a` equals to `b` and 'c'
>   // `x` equals to `y`
>   // `c` equals to `a` and `b`
> }
>   }
> }
>   }

We can actually figure out that `#2 == #3` because of equality theory. We only 
knew `#1 == #2` and that `#3 == #1`, but equality is a transitive binary 
relation and we reflect that notion in our equivalence classes data-structure.

> They both generates the same relationship between the variables. 
> **Assignment** seemed to me as just a special case in a //true// branch of 
> `==` operator and can be substituted with it in calculations. So, I decided 
> to make some assumptions in this way. Digging more, it opened a lot of gaps 
> and lacks for me.

Relationship between variables are the same, but neither solver nor the 
analyzer reason about things in terms of variables.  It's memory and values 
that the memory carries.  In the first example, we have only 2 values stored in 
5 memory locations.  In the second example, it's 5 values stored in 5 memory 
locations.  On some of the paths we happen to know how those values are related 
(which is not true for other paths), that's constraints.

I hope now it's clear.

> Next time I will investigate deeper to present a finalized solution and not 
> wasting your time explaining me the basics.

We probably should not have discussions like these because they are not 
directly about the patch on review.  If you want to continue this discussion, 
let's bring it to **[cfe-dev]**.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  

[PATCH] D103452: [clang] Fix reading long doubles with va_arg on x86_64 mingw

[Reid Kleckner via Phabricator via cfe-commits]

rnk added inline comments.



Comment at: clang/test/CodeGen/mingw-long-double.c:56-58
+  // GNU32: bitcast i8* %argp.cur to x86_fp80*
+  // GNU64: bitcast i8* %argp.cur to x86_fp80**
+  // MSC64: bitcast i8* %argp.cur to double*

mstorsjo wrote:
> mstorsjo wrote:
> > rnk wrote:
> > > These tests will stop working after opaque pointers happens, which I hope 
> > > comes in the next year. If you look for a load of the pointer type, that 
> > > should be resilient to opaque pointers.
> > Hmm, good point, but the test feels more brittle to me in that form:
> > 
> > ```
> >   // GNU32: load x86_fp80, x86_fp80*
> >   // GNU64: load x86_fp80*, x86_fp80**
> >   // GNU64: load x86_fp80, x86_fp80*
> >   // MSC64: load double, double*
> > ```
> > 
> > That wouldn't notice if GNU32 also used an indirect pointer for this case 
> > (as it would still match the second load - but it would notice if GNU64 
> > stopped using an indirect pointer as the first load wouldn't be matched). I 
> > guess it'd be safer if I'd use more named regex patterns in the test to 
> > follow the chain from the argp, but then we end up with a pattern covering 
> > the bits that change due to opaque pointers too.
> @rnk - WDYT about how to write the test patterns - see above?
I guess the only two ideas I have are to try out update_cc_test_checks.py or to 
CHECK-NOT for the indirect load.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103452

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

[PATCH] D103835: [CUDA][HIP] Fix store of vtbl in ctor

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl created this revision.
yaxunl added reviewers: tra, rjmccall.
yaxunl requested review of this revision.

vtbl itself is in default global address space. When clang emits
ctor, it gets a pointer to the vtbl field based on the `this` pointer,
then stores vtbl to the pointer.

Since `this` pointer can point to any address space (e.g. an object
created in stack), `this` pointer points to default address space, therefore
the pointer to vtbl field in `this` object should also be in default
address space.

Currently, clang incorrectly casts the pointer to vtbl field in `this` object
to global address space. This caused assertions in backend.

This patch fixes that by removing the incorrect addr space cast.


https://reviews.llvm.org/D103835

Files:
  clang/lib/CodeGen/CGClass.cpp
  clang/test/CodeGenCUDA/vtbl.cu


Index: clang/test/CodeGenCUDA/vtbl.cu
===
--- /dev/null
+++ clang/test/CodeGenCUDA/vtbl.cu
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -fcuda-is-device -triple amdgcn-amd-amdhsa -target-cpu 
gfx906 \
+// RUN:   -emit-llvm -o - %s | FileCheck %s
+
+#include "Inputs/cuda.h"
+
+// CHECK-LABEL: define {{.*}}@_ZN1AC2Ev(%struct.A* nonnull align 8 
dereferenceable(8) %this)
+// CHECK: store %struct.A* %this, %struct.A** %this.addr.ascast
+// CHECK: %this1 = load %struct.A*, %struct.A** %this.addr.ascast
+// CHECK: %[[VTFIELD:.*]] = bitcast %struct.A* %this1 to i32 (...)* 
addrspace(1)**
+// CHECK: store i32 (...)* addrspace(1)* bitcast{{.*}} @_ZTV1A{{.*}}, i32 
(...)* addrspace(1)** %[[VTFIELD]]
+struct A {
+  __device__ virtual void vf() {}
+};
+
+__global__ void kern() {
+  A a;
+}
Index: clang/lib/CodeGen/CGClass.cpp
===
--- clang/lib/CodeGen/CGClass.cpp
+++ clang/lib/CodeGen/CGClass.cpp
@@ -2518,8 +2518,10 @@
   llvm::FunctionType::get(CGM.Int32Ty, /*isVarArg=*/true)
   ->getPointerTo(ProgAS)
   ->getPointerTo(GlobalsAS);
+  // vtable field is is derived from `this` pointer, therefore it should be in
+  // default address space.
   VTableField = Builder.CreatePointerBitCastOrAddrSpaceCast(
-  VTableField, VTablePtrTy->getPointerTo(GlobalsAS));
+  VTableField, VTablePtrTy->getPointerTo());
   VTableAddressPoint = Builder.CreatePointerBitCastOrAddrSpaceCast(
   VTableAddressPoint, VTablePtrTy);
 


Index: clang/test/CodeGenCUDA/vtbl.cu
===
--- /dev/null
+++ clang/test/CodeGenCUDA/vtbl.cu
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -fcuda-is-device -triple amdgcn-amd-amdhsa -target-cpu gfx906 \
+// RUN:   -emit-llvm -o - %s | FileCheck %s
+
+#include "Inputs/cuda.h"
+
+// CHECK-LABEL: define {{.*}}@_ZN1AC2Ev(%struct.A* nonnull align 8 dereferenceable(8) %this)
+// CHECK: store %struct.A* %this, %struct.A** %this.addr.ascast
+// CHECK: %this1 = load %struct.A*, %struct.A** %this.addr.ascast
+// CHECK: %[[VTFIELD:.*]] = bitcast %struct.A* %this1 to i32 (...)* addrspace(1)**
+// CHECK: store i32 (...)* addrspace(1)* bitcast{{.*}} @_ZTV1A{{.*}}, i32 (...)* addrspace(1)** %[[VTFIELD]]
+struct A {
+  __device__ virtual void vf() {}
+};
+
+__global__ void kern() {
+  A a;
+}
Index: clang/lib/CodeGen/CGClass.cpp
===
--- clang/lib/CodeGen/CGClass.cpp
+++ clang/lib/CodeGen/CGClass.cpp
@@ -2518,8 +2518,10 @@
   llvm::FunctionType::get(CGM.Int32Ty, /*isVarArg=*/true)
   ->getPointerTo(ProgAS)
   ->getPointerTo(GlobalsAS);
+  // vtable field is is derived from `this` pointer, therefore it should be in
+  // default address space.
   VTableField = Builder.CreatePointerBitCastOrAddrSpaceCast(
-  VTableField, VTablePtrTy->getPointerTo(GlobalsAS));
+  VTableField, VTablePtrTy->getPointerTo());
   VTableAddressPoint = Builder.CreatePointerBitCastOrAddrSpaceCast(
   VTableAddressPoint, VTablePtrTy);
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D103663: [AMDGPU] Add gfx1013 target

[Stanislav Mekhanoshin via Phabricator via cfe-commits]

rampitec added inline comments.



Comment at: llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.intersect_ray.ll:4
+; RUN: llc -global-isel -march=amdgcn -mcpu=gfx1013 -verify-machineinstrs < %s 
| FileCheck -check-prefix=GCN %s
+; RUN: llc -global-isel -march=amdgcn -mcpu=gfx1012 -verify-machineinstrs < %s 
| FileCheck -check-prefix=GCN %s
 

bcahoon wrote:
> rampitec wrote:
> > bcahoon wrote:
> > > rampitec wrote:
> > > > rampitec wrote:
> > > > > foad wrote:
> > > > > > This test surely should not pass for gfx1012, since it does not 
> > > > > > have these instructions. And with your patch as written it should 
> > > > > > fail for gfx1013 too, since they are predicated on 
> > > > > > HasGFX10_BEncoding.
> > > > > > 
> > > > > > @rampitec any idea what is wrong here? Apparently the backend will 
> > > > > > happily generate image_bvh_intersect_ray instructions even for 
> > > > > > gfx900!
> > > > > Indeed. MIMG_IntersectRay has this:
> > > > > 
> > > > > ```
> > > > >   let SubtargetPredicate = HasGFX10_BEncoding,
> > > > >   AssemblerPredicate = HasGFX10_BEncoding,
> > > > > ```
> > > > > but apparently SubtargetPredicate did not work. It needs to be fixed.
> > > > > 
> > > > > gfx1012 does not have it, gfx1013 does though. That is what GFX10_A 
> > > > > encoding is about, 10_B it has to be replaced with 10_A in BVH and 
> > > > > MSAA load.
> > > > Image lowering and selection is not really done like everything else. 
> > > > For BVH it just lowers intrinsic to opcode. I think the easiest fix is 
> > > > to add to SIISelLowering.cpp where we lower 
> > > > Intrinsic::amdgcn_image_bvh_intersect_ray something like this:
> > > > 
> > > > 
> > > > ```
> > > >   if (!Subtarget->hasGFX10_AEncoding())
> > > > report_fatal_error(
> > > > "requested image instruction is not supported on this GPU");
> > > > ```
> > > I ended up using emitRemovedIntrinsicError, which uses 
> > > DiagnosticInfoUnsupported. This way the failure isn't a crash dump.
> > > I ended up using emitRemovedIntrinsicError, which uses 
> > > DiagnosticInfoUnsupported. This way the failure isn't a crash dump.
> > 
> > Diagnostics is a good thing, but we still have to fail the compilation.
> The diagnostic is marked as an error, so the compilation fails in that llc 
> returns a non-zero return code. This mechanism is used in other places in the 
> back-end to report similar types of errors. The alternative, if I understand 
> correctly, is that a crash occurs with an error message that indicates that 
> the bug is in LLVM (rather the the input source file).
We do not seem to be consistent here and return either undef or SDValue(), but 
as far as I can see we never continue selecting code though, like here in 
SIISelLowering and always return false from the AMDGPUInstructionSelector.


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

https://reviews.llvm.org/D103663

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

[PATCH] D103663: [AMDGPU] Add gfx1013 target

[Brendon Cahoon via Phabricator via cfe-commits]

bcahoon marked 4 inline comments as done.
bcahoon added inline comments.



Comment at: llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.intersect_ray.ll:4
+; RUN: llc -global-isel -march=amdgcn -mcpu=gfx1013 -verify-machineinstrs < %s 
| FileCheck -check-prefix=GCN %s
+; RUN: llc -global-isel -march=amdgcn -mcpu=gfx1012 -verify-machineinstrs < %s 
| FileCheck -check-prefix=GCN %s
 

rampitec wrote:
> bcahoon wrote:
> > rampitec wrote:
> > > rampitec wrote:
> > > > foad wrote:
> > > > > This test surely should not pass for gfx1012, since it does not have 
> > > > > these instructions. And with your patch as written it should fail for 
> > > > > gfx1013 too, since they are predicated on HasGFX10_BEncoding.
> > > > > 
> > > > > @rampitec any idea what is wrong here? Apparently the backend will 
> > > > > happily generate image_bvh_intersect_ray instructions even for gfx900!
> > > > Indeed. MIMG_IntersectRay has this:
> > > > 
> > > > ```
> > > >   let SubtargetPredicate = HasGFX10_BEncoding,
> > > >   AssemblerPredicate = HasGFX10_BEncoding,
> > > > ```
> > > > but apparently SubtargetPredicate did not work. It needs to be fixed.
> > > > 
> > > > gfx1012 does not have it, gfx1013 does though. That is what GFX10_A 
> > > > encoding is about, 10_B it has to be replaced with 10_A in BVH and MSAA 
> > > > load.
> > > Image lowering and selection is not really done like everything else. For 
> > > BVH it just lowers intrinsic to opcode. I think the easiest fix is to add 
> > > to SIISelLowering.cpp where we lower 
> > > Intrinsic::amdgcn_image_bvh_intersect_ray something like this:
> > > 
> > > 
> > > ```
> > >   if (!Subtarget->hasGFX10_AEncoding())
> > > report_fatal_error(
> > > "requested image instruction is not supported on this GPU");
> > > ```
> > I ended up using emitRemovedIntrinsicError, which uses 
> > DiagnosticInfoUnsupported. This way the failure isn't a crash dump.
> > I ended up using emitRemovedIntrinsicError, which uses 
> > DiagnosticInfoUnsupported. This way the failure isn't a crash dump.
> 
> Diagnostics is a good thing, but we still have to fail the compilation.
The diagnostic is marked as an error, so the compilation fails in that llc 
returns a non-zero return code. This mechanism is used in other places in the 
back-end to report similar types of errors. The alternative, if I understand 
correctly, is that a crash occurs with an error message that indicates that the 
bug is in LLVM (rather the the input source file).


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

https://reviews.llvm.org/D103663

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

[PATCH] D103750: [analyzer][WIP] Handle std::make_unique for SmartPtrModeling

[Deep Majumder via Phabricator via cfe-commits]

RedDocMD added a comment.

In D103750#2803499 , @NoQ wrote:

> Ugh, this entire `checkBind` hack was so unexpected that I didn't even 
> recognize `evalCall`. What prevents you from doing everything in `evalCall`? 
> No state traits, no nothing, just directly take the this-region and attach 
> the value to it?

Because in `evalCall`, I don't have access to the `ThisRegion`. At least I 
think I don't.
So we have a statement like `auto a = std::make_unique(100)`. In 
`evalCall` I get a `CallEvent` corresponding to `std::make_unique(100)`. 
Using `Call.getOriginExpr()` I can get the LHS. But that's only the `Expr`, not 
the `MemRegion`.  Unlike in a regular constructor call or method call, where 
`ThisRegion` can easily be obtained from the `Call`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103750

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

[PATCH] D103184: [AArch64] handle -Wa,-march=

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

This breaks tests on arm macs: http://45.33.8.238/macm1/10931/step_7.txt

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


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103184

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

[PATCH] D97085: [OpenMP] libomp: implement OpenMP 5.1 inoutset task dependence type

[Andrey Churbanov 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 rGa1f550e05254: [OpenMP] libomp: implement OpenMP 5.1 inoutset 
task dependence type (authored by AndreyChurbanov).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97085

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/test/OpenMP/depobj_codegen.cpp
  clang/test/OpenMP/target_enter_data_depend_codegen.cpp
  clang/test/OpenMP/target_exit_data_depend_codegen.cpp
  clang/test/OpenMP/target_update_depend_codegen.cpp
  clang/test/OpenMP/task_codegen.c
  clang/test/OpenMP/task_codegen.cpp
  clang/test/OpenMP/task_if_codegen.cpp
  openmp/runtime/src/kmp.h
  openmp/runtime/src/kmp_taskdeps.cpp
  openmp/runtime/src/kmp_taskdeps.h
  openmp/runtime/test/tasking/bug_nested_proxy_task.c
  openmp/runtime/test/tasking/bug_proxy_task_dep_waiting.c
  openmp/runtime/test/tasking/hidden_helper_task/common.h
  openmp/runtime/test/tasking/hidden_helper_task/depend.cpp
  openmp/runtime/test/tasking/hidden_helper_task/gtid.cpp
  openmp/runtime/test/tasking/omp51_task_dep_inoutset.c

Index: openmp/runtime/test/tasking/omp51_task_dep_inoutset.c
===
--- /dev/null
+++ openmp/runtime/test/tasking/omp51_task_dep_inoutset.c
@@ -0,0 +1,258 @@
+// RUN: %libomp-compile-and-run
+// RUN: %libomp-cxx-compile-and-run
+// UNSUPPORTED: gcc
+
+// Tests OMP 5.0 task dependences "mutexinoutset" and 5.1 "inoutset",
+// emulates compiler codegen for new dep kinds
+// Mutually exclusive tasks get same input dependency info array
+//
+// Task tree created:
+//  task0 - task1 (in)
+// \
+//task2 - task3 (inoutset)
+// /
+//  task3 - task4 (in)
+//   /
+//  task6 <-->task7  (mutexinoutset)
+//   \/
+//   task8 (in)
+//
+#include 
+#include 
+
+#ifdef _WIN32
+#include 
+#define mysleep(n) Sleep(n)
+#else
+#include 
+#define mysleep(n) usleep((n)*1000)
+#endif
+
+// to check the # of concurrent tasks (must be 1 for MTX, <3 for other kinds)
+static int volatile checker = 0;
+static int err = 0;
+#ifndef DELAY
+#define DELAY 100
+#endif
+
+// ---
+// internal data to emulate compiler codegen
+typedef struct DEP {
+  size_t addr;
+  size_t len;
+  int flags;
+} dep;
+typedef struct task {
+  void** shareds;
+  void* entry;
+  int part_id;
+  void* destr_thunk;
+  int priority;
+  long long device_id;
+  int f_priv;
+} task_t;
+#define TIED 1
+typedef int(*entry_t)(int, task_t*);
+typedef struct ID {
+  int reserved_1;
+  int flags;
+  int reserved_2;
+  int reserved_3;
+  char *psource;
+} id;
+// thunk routine for tasks with MTX dependency
+int thunk_m(int gtid, task_t* ptask) {
+  int th = omp_get_thread_num();
+  #pragma omp atomic
+++checker;
+  printf("task _%d, th %d\n", ptask->f_priv, th);
+  if (checker != 1) { // no more than 1 task at a time
+err++;
+printf("Error1, checker %d != 1\n", checker);
+  }
+  mysleep(DELAY);
+  if (checker != 1) { // no more than 1 task at a time
+err++;
+printf("Error2, checker %d != 1\n", checker);
+  }
+  #pragma omp atomic
+--checker;
+  return 0;
+}
+// thunk routine for tasks with inoutset dependency
+int thunk_s(int gtid, task_t* ptask) {
+  int th = omp_get_thread_num();
+  #pragma omp atomic
+++checker;
+  printf("task _%d, th %d\n", ptask->f_priv, th);
+  if (checker > 2) { // no more than 2 tasks concurrently
+err++;
+printf("Error1, checker %d > 2\n", checker);
+  }
+  mysleep(DELAY);
+  if (checker > 2) { // no more than 2 tasks concurrently
+err++;
+printf("Error2, checker %d > 2\n", checker);
+  }
+  #pragma omp atomic
+--checker;
+  return 0;
+}
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+int __kmpc_global_thread_num(id*);
+extern task_t* __kmpc_omp_task_alloc(id *loc, int gtid, int flags,
+ size_t sz, size_t shar, entry_t rtn);
+int
+__kmpc_omp_task_with_deps(id *loc, int gtid, task_t *task, int nd, dep *dep_lst,
+  int nd_noalias, dep *noalias_dep_lst);
+static id loc = {0, 2, 0, 0, ";file;func;0;0;;"};
+#ifdef __cplusplus
+} // extern "C"
+#endif
+// End of internal data
+// ---
+
+int main()
+{
+  int i1,i2,i3;
+  omp_set_num_threads(4);
+  omp_set_dynamic(0);
+  #pragma omp parallel
+  {
+#pragma omp single nowait
+{
+  dep sdep[2];
+  task_t *ptr;
+  int gtid = __kmpc_global_thread_num();
+  int t = omp_get_thread_num();
+  #pragma omp task depend(in: i1, i2)
+  { int th = omp_get_thread_num();
+printf("task 0_%d, th %d\n", t, th);
+#pragma omp atomic
+  ++checker;
+if (checker > 2) { // no more than 2 tasks concurrently
+  

[PATCH] D103750: [analyzer][WIP] Handle std::make_unique for SmartPtrModeling

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

Ugh, this entire `checkBind` hack was so unexpected that I didn't even 
recognize `evalCall`. What prevents you from doing everything in `evalCall`? No 
state traits, no nothing, just directly take the this-region and attach the 
value to it?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103750

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

[PATCH] D103611: Correct the behavior of va_arg checking in C++

[Eli Friedman via Phabricator via cfe-commits]

efriedma added inline comments.



Comment at: clang/lib/Sema/SemaExpr.cpp:15783
+  // test for typesAreCompatible() will already properly consider those to
+  // be compatible types.
+  if (Context.getLangOpts().CPlusPlus && !PromoteType.isNull() &&

This explanation doesn't seem right.  Signed and unsigned types are never 
considered "compatible".

If I'm understanding correctly, the case this code addresses is promotion 
according to `[conv.prom]`p3: "A prvalue of an unscoped enumeration type whose 
underlying type is not fixed [...]".  Somehow, the enum ends up with an 
unsigned underlying type, but we promote to int?  And this doesn't happen in C 
somehow?


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

https://reviews.llvm.org/D103611

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

[PATCH] D103495: [static initializers] Don't put ordered dynamic initializers of static variables into global_ctors

[Wolfgang Pieb via Phabricator via cfe-commits]

wolfgangp updated this revision to Diff 350364.
wolfgangp added a comment.
Herald added subscribers: llvm-commits, jdoerfert, pengfei, jrtc27, 
fedor.sergeev, hiraditya, jyknight, dschuff.
Herald added a project: LLVM.

Following the suggestion to define an order of initialization for the entries 
in llvm.global_ctors and llvm.global_dtors this is mainly a documentation 
change, as well as a simple reversed emission of global_ctors/dtors entries 
when InitArray is not used. 
3 test cases are affected, 2 of them just by a reversed order of emission of 
priority-suffixed sections. I added a couple of entries to the third test case 
to verify in-order emission of entries with equal priority.


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

https://reviews.llvm.org/D103495

Files:
  llvm/docs/LangRef.rst
  llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
  llvm/test/CodeGen/SPARC/constructor.ll
  llvm/test/CodeGen/X86/2011-08-29-InitOrder.ll
  llvm/test/CodeGen/X86/constructor.ll

Index: llvm/test/CodeGen/X86/constructor.ll
===
--- llvm/test/CodeGen/X86/constructor.ll
+++ llvm/test/CodeGen/X86/constructor.ll
@@ -9,7 +9,7 @@
 ; RUN: llc -mtriple i586-intel-elfiamcu -use-ctors < %s | FileCheck %s --check-prefix=MCU-CTORS
 ; RUN: llc -mtriple i586-intel-elfiamcu < %s | FileCheck %s --check-prefix=MCU-INIT-ARRAY
 ; RUN: llc -mtriple x86_64-win32-gnu < %s | FileCheck --check-prefix=COFF-CTOR %s
-@llvm.global_ctors = appending global [3 x { i32, void ()*, i8* }] [{ i32, void ()*, i8* } { i32 65535, void ()* @f, i8* null}, { i32, void ()*, i8* } { i32 15, void ()* @g, i8* @v }, { i32, void ()*, i8* } { i32 5, void ()* @h, i8* @v }]
+@llvm.global_ctors = appending global [5 x { i32, void ()*, i8* }] [{ i32, void ()*, i8* } { i32 65535, void ()* @f, i8* null}, { i32, void ()*, i8* } { i32 15, void ()* @g, i8* @v }, { i32, void ()*, i8* } { i32 5, void ()* @h, i8* @v }, { i32, void ()*, i8* } { i32 65535, void ()* @i, i8* null }, { i32, void ()*, i8* } { i32 65535, void ()* @j, i8* null }]
 
 @v = weak_odr global i8 0
 
@@ -28,15 +28,27 @@
   ret void
 }
 
-; CTOR:		.section	.ctors.65520,"aGw",@progbits,v,comdat
+define void @i() {
+entry:
+  ret void
+}
+
+define void @j() {
+entry:
+  ret void
+}
+
+; CTOR:	.section	.ctors,"aw",@progbits
 ; CTOR-NEXT:	.p2align	3
-; CTOR-NEXT:	.quad	g
+; CTOR-NEXT:	.quad	j
+; CTOR-NEXT:	.quad	i
+; CTOR-NEXT:	.quad	f
 ; CTOR-NEXT:	.section	.ctors.09980,"aGw",@progbits,v,comdat
 ; CTOR-NEXT:	.p2align	3
 ; CTOR-NEXT:	.quad	h
-; CTOR-NEXT:	.section	.ctors,"aw",@progbits
+; CTOR-NEXT:	.section	.ctors.65520,"aGw",@progbits,v,comdat
 ; CTOR-NEXT:	.p2align	3
-; CTOR-NEXT:	.quad	f
+; CTOR-NEXT:	.quad	g
 
 ; INIT-ARRAY:		.section	.init_array.15,"aGw",@init_array,v,comdat
 ; INIT-ARRAY-NEXT:	.p2align	3
@@ -47,6 +59,8 @@
 ; INIT-ARRAY-NEXT:	.section	.init_array,"aw",@init_array
 ; INIT-ARRAY-NEXT:	.p2align	3
 ; INIT-ARRAY-NEXT:	.quad	f
+; INIT-ARRAY-NEXT:	.quad	i
+; INIT-ARRAY-NEXT:	.quad	j
 
 ; NACL:		.section	.init_array.15,"aGw",@init_array,v,comdat
 ; NACL-NEXT:	.p2align	2
@@ -57,6 +71,8 @@
 ; NACL-NEXT:	.section	.init_array,"aw",@init_array
 ; NACL-NEXT:	.p2align	2
 ; NACL-NEXT:	.long	f
+; NACL-NEXT:	.long	i
+; NACL-NEXT:	.long	j
 
 ; MCU-CTORS: .section.ctors,"aw",@progbits
 ; MCU-INIT-ARRAY:.section.init_array,"aw",@init_array
@@ -70,3 +86,5 @@
 ; COFF-CTOR-NEXT:	.section	.ctors,"dw"
 ; COFF-CTOR-NEXT:	.p2align	3
 ; COFF-CTOR-NEXT:	.quad	f
+; COFF-CTOR-NEXT:	.quad	i
+; COFF-CTOR-NEXT:	.quad	j
Index: llvm/test/CodeGen/X86/2011-08-29-InitOrder.ll
===
--- llvm/test/CodeGen/X86/2011-08-29-InitOrder.ll
+++ llvm/test/CodeGen/X86/2011-08-29-InitOrder.ll
@@ -3,24 +3,24 @@
 ; PR5329
 
 @llvm.global_ctors = appending global [3 x { i32, void ()*, i8* }] [{ i32, void ()*, i8* } { i32 2000, void ()* @construct_2, i8* null }, { i32, void ()*, i8* } { i32 3000, void ()* @construct_3, i8* null }, { i32, void ()*, i8* } { i32 1000, void ()* @construct_1, i8* null }]
-; CHECK-DEFAULT: .section.ctors.64535,"aw",@progbits
-; CHECK-DEFAULT: .long construct_1
-; CHECK-DEFAULT: .section.ctors.63535,"aw",@progbits
-; CHECK-DEFAULT: .long construct_2
 ; CHECK-DEFAULT: .section.ctors.62535,"aw",@progbits
 ; CHECK-DEFAULT: .long construct_3
+; CHECK-DEFAULT: .section.ctors.63535,"aw",@progbits
+; CHECK-DEFAULT: .long construct_2
+; CHECK-DEFAULT: .section.ctors.64535,"aw",@progbits
+; CHECK-DEFAULT: .long construct_1
 
 ; CHECK-DARWIN: .long _construct_1
 ; CHECK-DARWIN-NEXT: .long _construct_2
 ; CHECK-DARWIN-NEXT: .long _construct_3
 
 @llvm.global_dtors = appending global [3 x { i32, void ()*, i8* }] [{ i32, void ()*, i8* } { i32 2000, void ()* @destruct_2, i8* null }, { i32, void ()*, i8* } { i32 1000, void ()* @destruct_1, i8* null }, { i32, void ()*, i8* } { i32 3000, void ()* 

[PATCH] D103745: [dfsan] Add full fast8 support

[George Balatsouras via Phabricator via cfe-commits]

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



Comment at: clang/docs/DataFlowSanitizer.rst:172-178
 assert(ij_label == 3);  // Verifies all of the above
 
+// Or, equivalently:
+assert(dfsan_has_label(ij_label, i_label));
+assert(dfsan_has_label(ij_label, j_label));
+assert(!dfsan_has_label(ij_label, k_label));
+

stephan.yichao.zhao wrote:
> If we swap assert(ij_label == 3) with the 3 dfsan_has_label, the two 
> equivalent blocks are close to each other.
I think this way is better to demonstrate the differences:
- the first block exposes dfsan internals (the integer representation) and 
makes explicit statements about label values
- the second block uses dfsan_has_label to abstract the internals, not exposing 
the integer representation (or the fact that labels are OR'd).



Comment at: clang/docs/DataFlowSanitizerDesign.rst:60
 
-As stated above, the tool must track a large number of taint
-labels. This poses an implementation challenge, as most multiple-label
-tainting systems assign one label per bit to shadow storage, and
-union taint labels using a bitwise or operation. This will not scale
-to clients which use hundreds or thousands of taint labels, as the
-label union operation becomes O(n) in the number of supported labels,
-and data associated with it will quickly dominate the live variable
-set, causing register spills and hampering performance.
-
-Instead, a low overhead approach is proposed which is best-case O(log\
-:sub:`2` n) during execution. The underlying assumption is that
-the required space of label unions is sparse, which is a reasonable
-assumption to make given that we are optimizing for the case where
-applications mostly copy data from one place to another, without often
-invoking the need for an actual union operation. The representation
-of a taint label is a 16-bit integer, and new labels are allocated
-sequentially from a pool. The label identifier 0 is special, and means
-that the data item is unlabelled.
-
-When a label union operation is requested at a join point (any
-arithmetic or logical operation with two or more operands, such as
-addition), the code checks whether a union is required, whether the
-same union has been requested before, and whether one union label
-subsumes the other. If so, it returns the previously allocated union
-label. If not, it allocates a new union label from the same pool used
-for new labels.
-
-Specifically, the instrumentation pass will insert code like this
-to decide the union label ``lu`` for a pair of labels ``l1``
-and ``l2``:
-
-.. code-block:: c
-
-  if (l1 == l2)
-lu = l1;
-  else
-lu = __dfsan_union(l1, l2);
-
-The equality comparison is outlined, to provide an early exit in
-the common cases where the program is processing unlabelled data, or
-where the two data items have the same label.  ``__dfsan_union`` is
-a runtime library function which performs all other union computation.
+We use an 8-bit unsigned integers for the representation of a
+label. The label identifier 0 is special, and means that the data item

stephan.yichao.zhao wrote:
> integer
Done.



Comment at: clang/docs/DataFlowSanitizerDesign.rst:65
+join point (any arithmetic or logical operation with two or more
+operands, such as addition), we can simply OR the two labels in O(1).
 

stephan.yichao.zhao wrote:
> the labels, and each OR is in O(1).
Not sure how this changes the meaning, since the two labels would need one OR 
instruction.



Comment at: clang/docs/DataFlowSanitizerDesign.rst:68
+Users are responsible for managing the 8 integer labels (i.e., keeping
+track of what labels they have used so far, pick one that is yet
+unused, etc).

stephan.yichao.zhao wrote:
> picking
Done.



Comment at: clang/docs/DataFlowSanitizerDesign.rst:74
 
 The following is the current memory layout for Linux/x86\_64:
 

stephan.yichao.zhao wrote:
> memory layout
Done.



Comment at: clang/docs/DataFlowSanitizerDesign.rst:99
 associated directly with registers.  Loads will result in a union of
-all shadow labels corresponding to bytes loaded (which most of the
-time will be short circuited by the initial comparison) and stores will
-result in a copy of the label to the shadow of all bytes stored to.
+all shadow labels corresponding to bytes loaded and stores will result
+in a copy of the label to the shadow of all bytes stored to.

stephan.yichao.zhao wrote:
> , and
Done



Comment at: clang/docs/DataFlowSanitizerDesign.rst:100
+all shadow labels corresponding to bytes loaded and stores will result
+in a copy of the label to the shadow of all bytes stored to.
 

stephan.yichao.zhao wrote:
> the label of a stored value
Done.



Comment at: compiler-rt/lib/dfsan/dfsan.cpp:209
 
-// Like 

[PATCH] D103750: [analyzer][WIP] Handle std::make_unique for SmartPtrModeling

[Deep Majumder via Phabricator via cfe-commits]

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

In D103750#2801555 , @NoQ wrote:

> Yes I think you should totally do an `evalCall()` here. The function has no 
> other side effects apart from making a pointer so it's valuable to fully 
> model it so that to avoid unnecessary store invalidations.

Am I not doing that now? I didn't get this point.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103750

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

[PATCH] D103750: [analyzer][WIP] Handle std::make_unique for SmartPtrModeling

[Deep Majumder via Phabricator via cfe-commits]

RedDocMD marked 3 inline comments as done.
RedDocMD added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp:337
+
+bool isUniquePtrType(QualType QT) {
+  const auto *T = QT.getTypePtr();

NoQ wrote:
> Please merge with `isStdSmartPtrCall`.
I don't think that can be done because `isStdSmartPtrCall` checks //calls// 
like `a.foo()`, checking if `a` is a smart-ptr. On the other hand I need to 
check for statements like `a = foo()` and ensure that `a` is a smart-ptr.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103750

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

[PATCH] D103750: [analyzer][WIP] Handle std::make_unique for SmartPtrModeling

[Deep Majumder via Phabricator via cfe-commits]

RedDocMD updated this revision to Diff 350362.
RedDocMD added a comment.

Made stylistic refactors


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103750

Files:
  clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp

Index: clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
+++ clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
@@ -35,9 +35,15 @@
 using namespace ento;
 
 namespace {
+
+enum class MakeUniqueKind {
+  Regular,  // ie, std::make_unique
+  ForOverwrite, // ie, std::make_unique_for_overwrite
+};
+
 class SmartPtrModeling
 : public Checker {
+ check::LiveSymbols, check::Bind> {
 
   bool isBoolConversionMethod(const CallEvent ) const;
 
@@ -56,6 +62,7 @@
   void printState(raw_ostream , ProgramStateRef State, const char *NL,
   const char *Sep) const override;
   void checkLiveSymbols(ProgramStateRef State, SymbolReaper ) const;
+  void checkBind(SVal L, SVal V, const Stmt *S, CheckerContext ) const;
 
 private:
   void handleReset(const CallEvent , CheckerContext ) const;
@@ -76,10 +83,27 @@
   {{"release"}, ::handleRelease},
   {{"swap", 1}, ::handleSwap},
   {{"get"}, ::handleGet}};
+  const CallDescription StdMakeUniqueCall{{"std", "make_unique"}};
+  const CallDescription StdMakeUniqueForOverwriteCall{
+  {"std", "make_unique_for_overwrite"}};
 };
 } // end of anonymous namespace
 
+class MakeUniqueKindWrapper {
+  const MakeUniqueKind Kind;
+
+public:
+  MakeUniqueKindWrapper(MakeUniqueKind Kind) : Kind(Kind) {}
+  MakeUniqueKind get() const { return Kind; }
+  void Profile(llvm::FoldingSetNodeID ) const {
+ID.AddInteger(static_cast(Kind));
+  }
+  bool operator==(const MakeUniqueKind ) const { return Kind == RHS; }
+  bool operator!=(const MakeUniqueKind ) const { return Kind != RHS; }
+};
+
 REGISTER_MAP_WITH_PROGRAMSTATE(TrackedRegionMap, const MemRegion *, SVal)
+REGISTER_LIST_WITH_PROGRAMSTATE(MakeUniqueKindList, MakeUniqueKindWrapper)
 
 // Define the inter-checker API.
 namespace clang {
@@ -177,7 +201,21 @@
 
 bool SmartPtrModeling::evalCall(const CallEvent ,
 CheckerContext ) const {
+
   ProgramStateRef State = C.getState();
+
+  if (Call.isCalled(StdMakeUniqueCall)) {
+State = State->add(MakeUniqueKind::Regular);
+C.addTransition(State);
+return true;
+  }
+
+  if (Call.isCalled(StdMakeUniqueForOverwriteCall)) {
+State = State->add(MakeUniqueKind::ForOverwrite);
+C.addTransition(State);
+return true;
+  }
+
   if (!smartptr::isStdSmartPtrCall(Call))
 return false;
 
@@ -272,6 +310,46 @@
   return C.isDifferent();
 }
 
+bool isUniquePtrType(QualType QT) {
+  if (QT.isNull())
+return false;
+  const auto *Decl = QT->getAsCXXRecordDecl();
+  if (!Decl || !Decl->getDeclContext()->isStdNamespace())
+return false;
+  const IdentifierInfo *ID = Decl->getIdentifier();
+  if (!ID)
+return false;
+  const StringRef Name = ID->getName();
+  return Name == "unique_ptr";
+}
+
+void SmartPtrModeling::checkBind(SVal L, SVal V, const Stmt *S,
+ CheckerContext ) const {
+  const auto *TVR = dyn_cast_or_null(L.getAsRegion());
+  if (!TVR)
+return;
+  if (!isUniquePtrType(TVR->getValueType()))
+return;
+  const auto *ThisRegion = dyn_cast(TVR);
+  if (!ThisRegion)
+return;
+
+  ProgramStateRef State = C.getState();
+  auto KindList = State->get();
+  assert(!KindList.isEmpty() &&
+ "Expected list to contain the kind of the last make_unique");
+  auto Kind = KindList.getHead();
+  if (Kind == MakeUniqueKind::ForOverwrite) {
+auto RHSVal = C.getSValBuilder().makeNull();
+State = State->set(ThisRegion, RHSVal);
+  } else {
+// TODO: Encode information that the inner pointer for
+// unique_ptr made by std::make_unique is *not* null
+  }
+  State = State->set(KindList.getTail());
+  C.addTransition(State);
+}
+
 void SmartPtrModeling::checkDeadSymbols(SymbolReaper ,
 CheckerContext ) const {
   ProgramStateRef State = C.getState();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101237: [lldb] Fix [[no_unique_address]] and libstdc++ 11's std::unique_ptr

[Jan Kratochvil via Phabricator via cfe-commits]

jankratochvil added a comment.

[Dwarf-Discuss] How to map [[no_unique_address]] into DWARF: 
http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2021-June/004825.html


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101237

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

[PATCH] D89055: [analyzer] Wrong type cast occures during pointer dereferencing after type punning

[Chris Hamilton via Phabricator via cfe-commits]

chrish_ericsson_atx added inline comments.
Herald added a subscriber: manas.



Comment at: clang/lib/StaticAnalyzer/Core/SValBuilder.cpp:763-765
+  if (const auto *ER = dyn_cast(R)) {
+R = StateMgr.getStoreManager().castRegion(ER, CastTy);
+return loc::MemRegionVal(R);

This causes new false-positive static analysis warnings from 
core.CallAndMessage and core.UndefinedBinaryOperatorResult, (and possibly 
others?), possibly because of loss of array extent information.  See 
https://bugs.llvm.org/show_bug.cgi?id=50604.  



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89055

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

[PATCH] D101237: [lldb] Fix [[no_unique_address]] and libstdc++ 11's std::unique_ptr

[Jan Kratochvil via Phabricator via cfe-commits]

jankratochvil added inline comments.



Comment at: llvm/include/llvm/IR/DebugInfoFlags.def:62
+// FIXME: Move it to ReservedBit4?
+HANDLE_DI_FLAG((1 << 30), IsZeroSize)
 

This would need to be handled better if approved.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101237

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

[PATCH] D101237: [lldb] Fix [[no_unique_address]] and libstdc++ 11's std::unique_ptr

[Jan Kratochvil via Phabricator via cfe-commits]

jankratochvil updated this revision to Diff 350361.
jankratochvil added a comment.
Herald added subscribers: llvm-commits, cfe-commits, dexonsmith, sstefan1, 
martong, hiraditya.
Herald added a reviewer: shafik.
Herald added a reviewer: jdoerfert.
Herald added a reviewer: shafik.
Herald added projects: clang, LLVM.

`DW_AT_byte_size 0` implementation as suggested by @teemperor.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101237

Files:
  clang/lib/AST/ASTImporter.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CGDebugInfo.h
  lldb/source/Plugins/Language/CPlusPlus/LibStdcppUniquePointer.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
  lldb/source/Plugins/SymbolFile/NativePDB/UdtRecordCompleter.cpp
  lldb/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
  lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
  lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
  lldb/test/Shell/Expr/no_unique_address.cpp
  llvm/include/llvm/IR/DebugInfoFlags.def
  llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp

Index: llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
===
--- llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
+++ llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
@@ -1603,12 +1603,16 @@
   } else {
 addUInt(MemberDie, dwarf::DW_AT_data_bit_offset, None, Offset);
   }
+  assert(!(DT->getFlags() & DINode::FlagIsZeroSize) &&
+ "bitfields cannot have [[no_unique_address]]");
 } else {
   // This is not a bitfield.
   OffsetInBytes = DT->getOffsetInBits() / 8;
   if (AlignInBytes)
 addUInt(MemberDie, dwarf::DW_AT_alignment, dwarf::DW_FORM_udata,
 AlignInBytes);
+  if (DT->getFlags() & DINode::FlagIsZeroSize)
+addUInt(MemberDie, dwarf::DW_AT_byte_size, None, 0);
 }
 
 if (DD->getDwarfVersion() <= 2) {
Index: llvm/include/llvm/IR/DebugInfoFlags.def
===
--- llvm/include/llvm/IR/DebugInfoFlags.def
+++ llvm/include/llvm/IR/DebugInfoFlags.def
@@ -58,6 +58,8 @@
 HANDLE_DI_FLAG((1 << 27), BigEndian)
 HANDLE_DI_FLAG((1 << 28), LittleEndian)
 HANDLE_DI_FLAG((1 << 29), AllCallsDescribed)
+// FIXME: Move it to ReservedBit4?
+HANDLE_DI_FLAG((1 << 30), IsZeroSize)
 
 // To avoid needing a dedicated value for IndirectVirtualBase, we use
 // the bitwise or of Virtual and FwdDecl, which does not otherwise
@@ -67,7 +69,7 @@
 #ifdef DI_FLAG_LARGEST_NEEDED
 // intended to be used with ADT/BitmaskEnum.h
 // NOTE: always must be equal to largest flag, check this when adding new flag
-HANDLE_DI_FLAG((1 << 29), Largest)
+HANDLE_DI_FLAG((1 << 30), Largest)
 #undef DI_FLAG_LARGEST_NEEDED
 #endif
 
Index: lldb/test/Shell/Expr/no_unique_address.cpp
===
--- /dev/null
+++ lldb/test/Shell/Expr/no_unique_address.cpp
@@ -0,0 +1,15 @@
+// Test LLDB does not assert on miscalculated field offsets.
+
+// RUN: %clang_host %s -g -c -o %t.o
+// RUN: %lldb %t.o -o "p c.c" -o exit | FileCheck %s
+
+// CHECK: (lldb) p c.c
+// CHECK-NEXT: (char) $0 = '\0'
+
+struct A {};
+struct B {
+  [[no_unique_address]] A a;
+};
+struct C : B {
+  char c;
+} c;
Index: lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
===
--- lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
+++ lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
@@ -843,11 +843,10 @@
CompilerType *child_type = nullptr);
 
   // Modifying RecordType
-  static clang::FieldDecl *AddFieldToRecordType(const CompilerType ,
-llvm::StringRef name,
-const CompilerType _type,
-lldb::AccessType access,
-uint32_t bitfield_bit_size);
+  static clang::FieldDecl *
+  AddFieldToRecordType(const CompilerType , llvm::StringRef name,
+   const CompilerType _type, lldb::AccessType access,
+   uint32_t bitfield_bit_size, bool IsZeroSize = false);
 
   static void BuildIndirectFields(const CompilerType );
 
Index: lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
===
--- lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -7164,7 +7164,7 @@
 clang::FieldDecl *TypeSystemClang::AddFieldToRecordType(
 const CompilerType , llvm::StringRef name,
 const CompilerType _clang_type, AccessType access,
-uint32_t bitfield_bit_size) {
+uint32_t bitfield_bit_size, bool IsZeroSize) {
   if (!type.IsValid() || !field_clang_type.IsValid())
 return nullptr;
   TypeSystemClang *ast 

[PATCH] D103317: [Analyzer][engine][solver] Simplify complex constraints

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov added a comment.

@vsavchenko

I appologize for my immaturity and for the audacity of my infantile 
assumptions. I admit any constructive criticism. Thank you for referencing the 
theory. I will thoroughly study the domain in all.

As for the **assignments** and why I brought them up, that's because I just 
tried to look at the problem from another angle. Consider two snippets:

  void f(int a, int b, int c, int x, int y){
a = b;
x = y;
c = a;
// What can you say about a, x, c?
// `a` equals to `b` and 'c'
// `x` equals to `y`
// `c` equals to `a` and `b`
  }

and

  void f(int a, int b, int c, int x, int y){
if(a == b) {
  if(x == y) {
if(c == a) {
  // What can you say about a, x, c?
  // `a` equals to `b` and 'c'
  // `x` equals to `y`
  // `c` equals to `a` and `b`
}
  }
}
  }

They both generates the same relationship between the variables. **Assignment** 
seemed to me as just a special case in a //true// branch of `==` operator and 
can be substituted with it in calculations. So, I decided to make some 
assumptions in this way. Digging more, it opened a lot of gaps and lacks for me.
Next time I will investigate deeper to present a finalized solution and not 
wasting your time explaining me the basics.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103317

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

[PATCH] D103803: [analyzer] [NFC] Implement a wrapper SValBuilder::getCastedMemRegionVal for similar functionality on region cast

[Artem Dergachev via Phabricator via cfe-commits]

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

Great, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103803

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

[PATCH] D103452: [clang] Fix reading long doubles with va_arg on x86_64 mingw

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo added inline comments.



Comment at: clang/test/CodeGen/mingw-long-double.c:56-58
+  // GNU32: bitcast i8* %argp.cur to x86_fp80*
+  // GNU64: bitcast i8* %argp.cur to x86_fp80**
+  // MSC64: bitcast i8* %argp.cur to double*

mstorsjo wrote:
> rnk wrote:
> > These tests will stop working after opaque pointers happens, which I hope 
> > comes in the next year. If you look for a load of the pointer type, that 
> > should be resilient to opaque pointers.
> Hmm, good point, but the test feels more brittle to me in that form:
> 
> ```
>   // GNU32: load x86_fp80, x86_fp80*
>   // GNU64: load x86_fp80*, x86_fp80**
>   // GNU64: load x86_fp80, x86_fp80*
>   // MSC64: load double, double*
> ```
> 
> That wouldn't notice if GNU32 also used an indirect pointer for this case (as 
> it would still match the second load - but it would notice if GNU64 stopped 
> using an indirect pointer as the first load wouldn't be matched). I guess 
> it'd be safer if I'd use more named regex patterns in the test to follow the 
> chain from the argp, but then we end up with a pattern covering the bits that 
> change due to opaque pointers too.
@rnk - WDYT about how to write the test patterns - see above?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103452

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

[PATCH] D103184: [AArch64] handle -Wa,-march=

[Jian Cai via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGfd11a26d368c: [AArch64] handle -Wa,-march= (authored by 
jcai19).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103184

Files:
  clang/lib/Driver/ToolChains/Arch/AArch64.cpp
  clang/lib/Driver/ToolChains/Arch/AArch64.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/aarch64-target-as-march.s

Index: clang/test/Driver/aarch64-target-as-march.s
===
--- /dev/null
+++ clang/test/Driver/aarch64-target-as-march.s
@@ -0,0 +1,46 @@
+/// These tests make sure that options passed to the assembler
+/// via -Wa or -Xassembler are applied correctly to assembler inputs.
+
+/// Does not apply to non assembly files
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=armv8.1-a \
+// RUN: %S/Inputs/wildcard1.c 2>&1 | FileCheck --check-prefix=TARGET-FEATURE-1 %s
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Xassembler -march=armv8.1-a \
+// RUN: %S/Inputs/wildcard1.c 2>&1 | FileCheck --check-prefix=TARGET-FEATURE-1 %s
+
+// TARGET-FEATURE-1-NOT: "-target-feature" "+v8.1a"
+
+/// Does apply to assembler input
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=armv8.2-a %s 2>&1 | \
+// RUN: FileCheck --check-prefix=TARGET-FEATURE-2 %s
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Xassembler -march=armv8.2-a %s 2>&1 | \
+// RUN: FileCheck --check-prefix=TARGET-FEATURE-2 %s
+
+// TARGET-FEATURE-2: "-target-feature" "+v8.2a"
+
+/// No unused argument warnings when there are multiple values
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=armv8.1-a -Wa,-march=armv8.2-a %s 2>&1 | \
+// RUN: FileCheck --check-prefix=UNUSED-WARNING %s
+
+// UNUSED-WARNING-NOT: warning: argument unused during compilation
+
+/// Last march to assembler wins
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=armv8.2-a -Wa,-march=armv8.1-a %s 2>&1 | \
+// RUN: FileCheck --check-prefix=MULTIPLE-VALUES %s
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=armv8.2-a,-march=armv8.1-a %s 2>&1 | \
+// RUN: FileCheck --check-prefix=MULTIPLE-VALUES %s
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Xassembler -march=armv8.2-a -Xassembler \
+// RUN: -march=armv8.1-a %s 2>&1 | FileCheck --check-prefix=MULTIPLE-VALUES %s
+
+// MULTIPLE-VALUES: "-target-feature" "+v8.1a
+// MULTIPLE-VALUES-NOT: "-target-feature" "+v8.2a
+
+/// march to compiler and assembler, we choose the one suited to the input file type
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=armv8.3-a -march=armv8.4-a %s 2>&1 | \
+// RUN: FileCheck --check-prefix=TARGET-FEATURE-3 %s
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=armv8.3-a -march=armv8.4-a \
+// RUN: %S/Inputs/wildcard1.c 2>&1 | FileCheck --check-prefix=TARGET-FEATURE-4 %s
+
+// TARGET-FEATURE-3: "-target-feature" "+v8.3a"
+// TARGET-FEATURE-3-NOT: "-target-feature" "+v8.4a"
+// TARGET-FEATURE-4: "-target-feature" "+v8.4a"
+// TARGET-FEATURE-4-NOT: "-target-feature" "+v8.3a"
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -344,7 +344,7 @@
   case llvm::Triple::aarch64:
   case llvm::Triple::aarch64_32:
   case llvm::Triple::aarch64_be:
-aarch64::getAArch64TargetFeatures(D, Triple, Args, Features);
+aarch64::getAArch64TargetFeatures(D, Triple, Args, Features, ForAS);
 break;
   case llvm::Triple::x86:
   case llvm::Triple::x86_64:
Index: clang/lib/Driver/ToolChains/Arch/AArch64.h
===
--- clang/lib/Driver/ToolChains/Arch/AArch64.h
+++ clang/lib/Driver/ToolChains/Arch/AArch64.h
@@ -22,7 +22,8 @@
 
 void getAArch64TargetFeatures(const Driver , const llvm::Triple ,
   const llvm::opt::ArgList ,
-  std::vector );
+  std::vector ,
+  bool ForAS);
 
 std::string getAArch64TargetCPU(const llvm::opt::ArgList ,
 const llvm::Triple , llvm::opt::Arg *);
Index: clang/lib/Driver/ToolChains/Arch/AArch64.cpp
===
--- clang/lib/Driver/ToolChains/Arch/AArch64.cpp
+++ clang/lib/Driver/ToolChains/Arch/AArch64.cpp
@@ -185,12 +185,20 @@
 void aarch64::getAArch64TargetFeatures(const Driver ,
const llvm::Triple ,
const ArgList ,
-   std::vector ) {
+   std::vector ,
+   bool ForAS) {
   Arg *A;
   bool success = true;
   // Enable NEON by default.
   

[clang] fd11a26 - [AArch64] handle -Wa,-march=

[Jian Cai via cfe-commits]

Author: Jian Cai
Date: 2021-06-07T10:15:53-07:00
New Revision: fd11a26d368c5a909fb88548fef2cee7a6c2c931

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

LOG: [AArch64] handle -Wa,-march=

This fixed PR#48894 for AArch64. The issue has been fixed for Arm in
https://reviews.llvm.org/D95872

The following rules apply to -Wa,-march with this change:
  - Only compiler options apply to non assembly files
  - Compiler and assembler options apply to assembly files
  - For assembly files, we prefer the assembler option(s) if we have both kinds 
of option
  - Of the options that apply (or are preferred), the last value wins (it's not 
additive)

Reviewed By: DavidSpickett, nickdesaulniers

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

Added: 
clang/test/Driver/aarch64-target-as-march.s

Modified: 
clang/lib/Driver/ToolChains/Arch/AArch64.cpp
clang/lib/Driver/ToolChains/Arch/AArch64.h
clang/lib/Driver/ToolChains/Clang.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Arch/AArch64.cpp 
b/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
index 503685ab533a0..cb98d423ed2b0 100644
--- a/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
+++ b/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
@@ -185,12 +185,20 @@ getAArch64MicroArchFeaturesFromMcpu(const Driver , 
StringRef Mcpu,
 void aarch64::getAArch64TargetFeatures(const Driver ,
const llvm::Triple ,
const ArgList ,
-   std::vector ) {
+   std::vector ,
+   bool ForAS) {
   Arg *A;
   bool success = true;
   // Enable NEON by default.
   Features.push_back("+neon");
-  if ((A = Args.getLastArg(options::OPT_march_EQ)))
+  if (ForAS &&
+  (A = Args.getLastArg(options::OPT_Wa_COMMA, options::OPT_Xassembler))) {
+llvm::StringRef WaMArch;
+for (StringRef Value : A->getValues())
+  if (Value.startswith("-march="))
+WaMArch = Value.substr(7);
+success = getAArch64ArchFeaturesFromMarch(D, WaMArch, Args, Features);
+  } else if ((A = Args.getLastArg(options::OPT_march_EQ)))
 success = getAArch64ArchFeaturesFromMarch(D, A->getValue(), Args, 
Features);
   else if ((A = Args.getLastArg(options::OPT_mcpu_EQ)))
 success = getAArch64ArchFeaturesFromMcpu(D, A->getValue(), Args, Features);

diff  --git a/clang/lib/Driver/ToolChains/Arch/AArch64.h 
b/clang/lib/Driver/ToolChains/Arch/AArch64.h
index 713af870d69fb..d47c402d4a42d 100644
--- a/clang/lib/Driver/ToolChains/Arch/AArch64.h
+++ b/clang/lib/Driver/ToolChains/Arch/AArch64.h
@@ -22,7 +22,8 @@ namespace aarch64 {
 
 void getAArch64TargetFeatures(const Driver , const llvm::Triple ,
   const llvm::opt::ArgList ,
-  std::vector );
+  std::vector ,
+  bool ForAS);
 
 std::string getAArch64TargetCPU(const llvm::opt::ArgList ,
 const llvm::Triple , llvm::opt::Arg 
*);

diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index a0e1208fd709c..6fdd7e2dd21e7 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -344,7 +344,7 @@ static void getTargetFeatures(const Driver , const 
llvm::Triple ,
   case llvm::Triple::aarch64:
   case llvm::Triple::aarch64_32:
   case llvm::Triple::aarch64_be:
-aarch64::getAArch64TargetFeatures(D, Triple, Args, Features);
+aarch64::getAArch64TargetFeatures(D, Triple, Args, Features, ForAS);
 break;
   case llvm::Triple::x86:
   case llvm::Triple::x86_64:

diff  --git a/clang/test/Driver/aarch64-target-as-march.s 
b/clang/test/Driver/aarch64-target-as-march.s
new file mode 100644
index 0..a9301ade43351
--- /dev/null
+++ b/clang/test/Driver/aarch64-target-as-march.s
@@ -0,0 +1,46 @@
+/// These tests make sure that options passed to the assembler
+/// via -Wa or -Xassembler are applied correctly to assembler inputs.
+
+/// Does not apply to non assembly files
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=armv8.1-a \
+// RUN: %S/Inputs/wildcard1.c 2>&1 | FileCheck --check-prefix=TARGET-FEATURE-1 
%s
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Xassembler 
-march=armv8.1-a \
+// RUN: %S/Inputs/wildcard1.c 2>&1 | FileCheck --check-prefix=TARGET-FEATURE-1 
%s
+
+// TARGET-FEATURE-1-NOT: "-target-feature" "+v8.1a"
+
+/// Does apply to assembler input
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=armv8.2-a %s 
2>&1 | \
+// RUN: FileCheck --check-prefix=TARGET-FEATURE-2 %s
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Xassembler 
-march=armv8.2-a 

[PATCH] D103663: [AMDGPU] Add gfx1013 target

[Stanislav Mekhanoshin via Phabricator via cfe-commits]

rampitec added inline comments.



Comment at: llvm/lib/Target/AMDGPU/AMDGPULegalizerInfo.cpp:4697
+  if (!ST.hasGFX10_AEncoding()) {
+DiagnosticInfoUnsupported BadIntrin(B.getMF().getFunction(), "intrinsic 
not supported on subtarget",
+MI.getDebugLoc());

80 chars per line.



Comment at: llvm/lib/Target/AMDGPU/AMDGPULegalizerInfo.cpp:4700
+B.getMF().getFunction().getContext().diagnose(BadIntrin);
+B.buildUndef(MI.getOperand(0));
+MI.eraseFromParent();

Just return false like in other places.



Comment at: llvm/lib/Target/AMDGPU/SIISelLowering.cpp:7341
+if (!Subtarget->hasGFX10_AEncoding())
+  emitRemovedIntrinsicError(DAG, DL, Op.getValueType());
+

return emitRemovedIntrinsicError();



Comment at: llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.intersect_ray.ll:4
+; RUN: llc -global-isel -march=amdgcn -mcpu=gfx1013 -verify-machineinstrs < %s 
| FileCheck -check-prefix=GCN %s
+; RUN: not llc -global-isel -march=amdgcn -mcpu=gfx1012 -verify-machineinstrs 
< %s -o /dev/null 2>&1 | FileCheck -check-prefix=ERR %s
 

not --crash llc ...



Comment at: llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.intersect_ray.ll:4
+; RUN: llc -global-isel -march=amdgcn -mcpu=gfx1013 -verify-machineinstrs < %s 
| FileCheck -check-prefix=GCN %s
+; RUN: llc -global-isel -march=amdgcn -mcpu=gfx1012 -verify-machineinstrs < %s 
| FileCheck -check-prefix=GCN %s
 

bcahoon wrote:
> rampitec wrote:
> > rampitec wrote:
> > > foad wrote:
> > > > This test surely should not pass for gfx1012, since it does not have 
> > > > these instructions. And with your patch as written it should fail for 
> > > > gfx1013 too, since they are predicated on HasGFX10_BEncoding.
> > > > 
> > > > @rampitec any idea what is wrong here? Apparently the backend will 
> > > > happily generate image_bvh_intersect_ray instructions even for gfx900!
> > > Indeed. MIMG_IntersectRay has this:
> > > 
> > > ```
> > >   let SubtargetPredicate = HasGFX10_BEncoding,
> > >   AssemblerPredicate = HasGFX10_BEncoding,
> > > ```
> > > but apparently SubtargetPredicate did not work. It needs to be fixed.
> > > 
> > > gfx1012 does not have it, gfx1013 does though. That is what GFX10_A 
> > > encoding is about, 10_B it has to be replaced with 10_A in BVH and MSAA 
> > > load.
> > Image lowering and selection is not really done like everything else. For 
> > BVH it just lowers intrinsic to opcode. I think the easiest fix is to add 
> > to SIISelLowering.cpp where we lower 
> > Intrinsic::amdgcn_image_bvh_intersect_ray something like this:
> > 
> > 
> > ```
> >   if (!Subtarget->hasGFX10_AEncoding())
> > report_fatal_error(
> > "requested image instruction is not supported on this GPU");
> > ```
> I ended up using emitRemovedIntrinsicError, which uses 
> DiagnosticInfoUnsupported. This way the failure isn't a crash dump.
> I ended up using emitRemovedIntrinsicError, which uses 
> DiagnosticInfoUnsupported. This way the failure isn't a crash dump.

Diagnostics is a good thing, but we still have to fail the compilation.



Comment at: llvm/test/CodeGen/AMDGPU/llvm.amdgcn.intersect_ray.ll:3
+; RUN: llc -march=amdgcn -mcpu=gfx1013 -verify-machineinstrs < %s | FileCheck 
-check-prefix=GCN %s
+; RUN: not llc -march=amdgcn -mcpu=gfx1012 -verify-machineinstrs < %s 2>&1 | 
FileCheck -check-prefix=ERR %s
 

not --crash llc


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

https://reviews.llvm.org/D103663

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

[PATCH] D101630: [HIP] Add --gpu-bundle-output

[Artem Belevich via Phabricator via cfe-commits]

tra accepted this revision.
tra added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/lib/Driver/Driver.cpp:2903
 bool GPUSanitize;
+Optional BundleOutput;
 

We should document the behavior we expect from the `--gpu-bundle-output` option 
in one place. This may be a good place for it. 

Some day we should add CUDA/HIP section to clang manual. We already have tons 
of options that users do need to know about.


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

https://reviews.llvm.org/D101630

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

[PATCH] D103806: [SystemZ][z/OS] Pass OpenFlags when creating tmp files

[Abhina Sree via Phabricator via cfe-commits]

abhina.sreeskantharajan added inline comments.



Comment at: llvm/lib/Support/Path.cpp:1295
   SmallString<128> ResultPath;
-  if (std::error_code EC =
-  createUniqueFile(Model, FD, ResultPath, OF_Delete, Mode))
+  if (std::error_code EC = createUniqueFile(Model, FD, ResultPath, Flags, 
Mode))
 return errorCodeToError(EC);

rnk wrote:
> Instead of requiring the caller to add `OF_Delete`, I think it would be 
> better to pass `OF_Delete | Flags` here.
Sure, I'll make that change. Do you think we should change the name to 
"ExtraFlags" to indicate there is a default, or is the current name is fine?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103806

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

[PATCH] D98798: Produce warning for performing pointer arithmetic on a null pointer.

[Jamie Schmeiser via Phabricator via cfe-commits]

jamieschmeiser added a comment.

@rsmith I separated the C and C++ messages in response to your comments and 
changed the C++ message to state that "performing pointer subtraction with a 
null pointer may have undefined behavior" to address your concerns.  Are you 
satisfied?  @thakis, the warning no longer fires in the MS headers according to 
@hans and there is separate option control over this warning.  Is this 
sufficient?  @efriedma, thank you for reviewing/approving the original but 
these changes were sufficiently different that I thought a new review would be 
beneficial.  Are you still satisfied with the resulting changes?


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

https://reviews.llvm.org/D98798

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

[PATCH] D103771: [clang][msvc] Define _HAS_STATIC_RTTI to 0, when compiling with -fno-rtti

[Reid Kleckner via Phabricator via cfe-commits]

rnk accepted this revision.
rnk added a comment.

Seems reasonable to me.

Here is where it is defined in MSVC's yvals_core.h for the curious:
https://github.com/microsoft/STL/blob/3cafa97eecdbfde41ea5c09126f877a7eb97f9e9/stl/inc/yvals_core.h#L569


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

https://reviews.llvm.org/D103771

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

[PATCH] D103745: [dfsan] Add full fast8 support

[stephan.yichao.zhao via Phabricator via cfe-commits]

stephan.yichao.zhao added a comment.

How did we fix that alignment error from compiler-rt/test/dfsan/origin_ldst.c?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103745

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

[PATCH] D103806: [SystemZ][z/OS] Pass OpenFlags when creating tmp files

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

I see, thanks.




Comment at: llvm/lib/Support/Path.cpp:1295
   SmallString<128> ResultPath;
-  if (std::error_code EC =
-  createUniqueFile(Model, FD, ResultPath, OF_Delete, Mode))
+  if (std::error_code EC = createUniqueFile(Model, FD, ResultPath, Flags, 
Mode))
 return errorCodeToError(EC);

Instead of requiring the caller to add `OF_Delete`, I think it would be better 
to pass `OF_Delete | Flags` here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103806

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

[PATCH] D103825: [clang] Do not crash when ArgTy is null in CheckArgAlignment

[Adam Czachorowski via Phabricator via cfe-commits]

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

No repro case just yet. I only observed a crash like this and noticed
ArgTy-Value = 0 in coredump.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D103825

Files:
  clang/lib/Sema/SemaChecking.cpp


Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -4571,8 +4571,9 @@
 
   // Find expected alignment, and the actual alignment of the passed object.
   // getTypeAlignInChars requires complete types
-  if (ParamTy->isIncompleteType() || ArgTy->isIncompleteType() ||
-  ParamTy->isUndeducedType() || ArgTy->isUndeducedType())
+  if (ArgTy.isNull() || ParamTy->isIncompleteType() ||
+  ArgTy->isIncompleteType() || ParamTy->isUndeducedType() ||
+  ArgTy->isUndeducedType())
 return;
 
   CharUnits ParamAlign = Context.getTypeAlignInChars(ParamTy);


Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -4571,8 +4571,9 @@
 
   // Find expected alignment, and the actual alignment of the passed object.
   // getTypeAlignInChars requires complete types
-  if (ParamTy->isIncompleteType() || ArgTy->isIncompleteType() ||
-  ParamTy->isUndeducedType() || ArgTy->isUndeducedType())
+  if (ArgTy.isNull() || ParamTy->isIncompleteType() ||
+  ArgTy->isIncompleteType() || ParamTy->isUndeducedType() ||
+  ArgTy->isUndeducedType())
 return;
 
   CharUnits ParamAlign = Context.getTypeAlignInChars(ParamTy);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101630: [HIP] Add --gpu-bundle-output

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl updated this revision to Diff 350318.
yaxunl retitled this revision from "[HIP] Fix device-only compilation" to 
"[HIP] Add --gpu-bundle-output".
yaxunl edited the summary of this revision.
yaxunl added a comment.

use --gpu-bundle-output to control bundling/unbundling output of HIP device 
only compilation


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

https://reviews.llvm.org/D101630

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/clang-offload-bundler.c
  clang/test/Driver/hip-device-compile.hip
  clang/test/Driver/hip-output-file-name.hip
  clang/test/Driver/hip-phases.hip
  clang/test/Driver/hip-rdc-device-only.hip
  clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp

Index: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
===
--- clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
+++ clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
@@ -117,6 +117,9 @@
 /// The index of the host input in the list of inputs.
 static unsigned HostInputIndex = ~0u;
 
+/// Whether not having host target is allowed.
+static bool AllowNoHost = false;
+
 /// Path to the current binary.
 static std::string BundlerExecutable;
 
@@ -839,9 +842,10 @@
   }
 
   // Get the file handler. We use the host buffer as reference.
-  assert(HostInputIndex != ~0u && "Host input index undefined??");
+  assert((HostInputIndex != ~0u || AllowNoHost) &&
+ "Host input index undefined??");
   Expected> FileHandlerOrErr =
-  CreateFileHandler(*InputBuffers[HostInputIndex]);
+  CreateFileHandler(*InputBuffers[AllowNoHost ? 0 : HostInputIndex]);
   if (!FileHandlerOrErr)
 return FileHandlerOrErr.takeError();
 
@@ -1108,6 +1112,7 @@
   // have exactly one host target.
   unsigned Index = 0u;
   unsigned HostTargetNum = 0u;
+  bool HIPOnly = true;
   llvm::DenseSet ParsedTargets;
   for (StringRef Target : TargetNames) {
 if (ParsedTargets.contains(Target)) {
@@ -1149,12 +1154,21 @@
   HostInputIndex = Index;
 }
 
+if (Kind != "hip" && Kind != "hipv4")
+  HIPOnly = false;
+
 ++Index;
   }
 
+  // HIP uses clang-offload-bundler to bundle device-only compilation results
+  // for multiple GPU archs, therefore allow no host target if all entries
+  // are for HIP.
+  AllowNoHost = HIPOnly;
+
   // Host triple is not really needed for unbundling operation, so do not
   // treat missing host triple as error if we do unbundling.
-  if ((Unbundle && HostTargetNum > 1) || (!Unbundle && HostTargetNum != 1)) {
+  if ((Unbundle && HostTargetNum > 1) ||
+  (!Unbundle && HostTargetNum != 1 && !AllowNoHost)) {
 reportError(createStringError(errc::invalid_argument,
   "expecting exactly one host target but got " +
   Twine(HostTargetNum)));
Index: clang/test/Driver/hip-rdc-device-only.hip
===
--- clang/test/Driver/hip-rdc-device-only.hip
+++ clang/test/Driver/hip-rdc-device-only.hip
@@ -6,7 +6,7 @@
 // RUN:   -x hip --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
 // RUN:   -c -nogpuinc -nogpulib --cuda-device-only -fgpu-rdc \
 // RUN:   %S/Inputs/hip_multiple_inputs/a.cu \
-// RUN:   %S/Inputs/hip_multiple_inputs/b.hip \
+// RUN:   %S/Inputs/hip_multiple_inputs/b.hip --gpu-bundle-output \
 // RUN: 2>&1 | FileCheck -check-prefixes=COMMON,EMITBC %s
 
 // With `-emit-llvm`, the output should be the same as the aforementioned line
@@ -16,14 +16,14 @@
 // RUN:   -x hip --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
 // RUN:   -c -emit-llvm -nogpuinc -nogpulib --cuda-device-only -fgpu-rdc \
 // RUN:   %S/Inputs/hip_multiple_inputs/a.cu \
-// RUN:   %S/Inputs/hip_multiple_inputs/b.hip \
+// RUN:   %S/Inputs/hip_multiple_inputs/b.hip --gpu-bundle-output \
 // RUN: 2>&1 | FileCheck -check-prefixes=COMMON,EMITBC %s
 
 // RUN: %clang -### -target x86_64-linux-gnu \
 // RUN:   -x hip --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
 // RUN:   -S -nogpuinc -nogpulib --cuda-device-only -fgpu-rdc \
 // RUN:   %S/Inputs/hip_multiple_inputs/a.cu \
-// RUN:   %S/Inputs/hip_multiple_inputs/b.hip \
+// RUN:   %S/Inputs/hip_multiple_inputs/b.hip --gpu-bundle-output \
 // RUN: 2>&1 | FileCheck -check-prefixes=COMMON,EMITLL %s
 
 // With `-emit-llvm`, the output should be the same as the aforementioned line
@@ -33,7 +33,7 @@
 // RUN:   -x hip --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
 // RUN:   -S -emit-llvm -nogpuinc -nogpulib --cuda-device-only -fgpu-rdc \
 // RUN:   %S/Inputs/hip_multiple_inputs/a.cu \
-// RUN:   %S/Inputs/hip_multiple_inputs/b.hip \
+// RUN:   %S/Inputs/hip_multiple_inputs/b.hip --gpu-bundle-output \
 // RUN: 2>&1 | FileCheck -check-prefixes=COMMON,EMITLL %s
 
 // With `-save-temps`, commane lines for each steps are dumped. For assembly
@@ -44,9 +44,17 @@
 // RUN:   -x hip --cuda-gpu-arch=gfx803 

[PATCH] D97869: [OpenCL] Add OpenCL builtin test generator

[Sven van Haastregt via Phabricator via cfe-commits]

svenvh added inline comments.



Comment at: clang/utils/TableGen/ClangOpenCLBuiltinEmitter.cpp:969
+
+void OpenCLBuiltinTestEmitter::getTypeLists(
+Record *Type, TypeFlags , std::vector ,

Anastasia wrote:
> I would add a documentation for this function, it is not very obvious.
Not sure what documentation you are expecting?  Are there any particular lines 
that are "not very obvious"?
Note that there is already a comment for this method up in the class 
declaration.



Comment at: clang/utils/TableGen/ClangOpenCLBuiltinEmitter.cpp:1004
+SmallVectorImpl> ) {
+  // Find out if there are any GenTypes in this signature, and if so, calculate
+  // into how many signatures they will expand.

Anastasia wrote:
> Maybe this should be lifted as documentation of the header of this function?
This comment only applies to the first loop-nest.  It documents an 
implementation detail, so I don't think this comment should be lifted to the 
method's declaration comment.



Comment at: clang/utils/TableGen/ClangOpenCLBuiltinEmitter.cpp:1033
+for (unsigned ArgNum = 0; ArgNum < Signature.size(); ArgNum++) {
+  // For differently-sized GenTypes in a parameter list, the smaller
+  // GenTypes just repeat.

Anastasia wrote:
> I don't get this comment and its exact reference to the code.
I have expanded the comment, and also factored out an index into a variable.  
Hopefully that makes it clear?


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

https://reviews.llvm.org/D97869

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

[PATCH] D97869: [OpenCL] Add OpenCL builtin test generator

[Sven van Haastregt via Phabricator via cfe-commits]

svenvh updated this revision to Diff 350314.
svenvh marked an inline comment as done.
svenvh retitled this revision from "[OpenCL][Draft] Add OpenCL builtin test 
generator" to "[OpenCL] Add OpenCL builtin test generator".
svenvh added a comment.

Improve comments.


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

https://reviews.llvm.org/D97869

Files:
  clang/test/Headers/lit.local.cfg
  clang/test/Headers/opencl-builtins.cl
  clang/utils/TableGen/ClangOpenCLBuiltinEmitter.cpp
  clang/utils/TableGen/TableGen.cpp
  clang/utils/TableGen/TableGenBackends.h

Index: clang/utils/TableGen/TableGenBackends.h
===
--- clang/utils/TableGen/TableGenBackends.h
+++ clang/utils/TableGen/TableGenBackends.h
@@ -122,6 +122,8 @@
 
 void EmitClangOpenCLBuiltins(llvm::RecordKeeper ,
  llvm::raw_ostream );
+void EmitClangOpenCLBuiltinTests(llvm::RecordKeeper ,
+ llvm::raw_ostream );
 
 void EmitClangDataCollectors(llvm::RecordKeeper ,
  llvm::raw_ostream );
Index: clang/utils/TableGen/TableGen.cpp
===
--- clang/utils/TableGen/TableGen.cpp
+++ clang/utils/TableGen/TableGen.cpp
@@ -63,6 +63,7 @@
   GenClangCommentCommandInfo,
   GenClangCommentCommandList,
   GenClangOpenCLBuiltins,
+  GenClangOpenCLBuiltinTests,
   GenArmNeon,
   GenArmFP16,
   GenArmBF16,
@@ -194,6 +195,8 @@
"documentation comments"),
 clEnumValN(GenClangOpenCLBuiltins, "gen-clang-opencl-builtins",
"Generate OpenCL builtin declaration handlers"),
+clEnumValN(GenClangOpenCLBuiltinTests, "gen-clang-opencl-builtin-tests",
+   "Generate OpenCL builtin declaration tests"),
 clEnumValN(GenArmNeon, "gen-arm-neon", "Generate arm_neon.h for clang"),
 clEnumValN(GenArmFP16, "gen-arm-fp16", "Generate arm_fp16.h for clang"),
 clEnumValN(GenArmBF16, "gen-arm-bf16", "Generate arm_bf16.h for clang"),
@@ -371,6 +374,9 @@
   case GenClangOpenCLBuiltins:
 EmitClangOpenCLBuiltins(Records, OS);
 break;
+  case GenClangOpenCLBuiltinTests:
+EmitClangOpenCLBuiltinTests(Records, OS);
+break;
   case GenClangSyntaxNodeList:
 EmitClangSyntaxNodeList(Records, OS);
 break;
Index: clang/utils/TableGen/ClangOpenCLBuiltinEmitter.cpp
===
--- clang/utils/TableGen/ClangOpenCLBuiltinEmitter.cpp
+++ clang/utils/TableGen/ClangOpenCLBuiltinEmitter.cpp
@@ -228,6 +228,64 @@
   // same entry ().
   MapVector SignatureListMap;
 };
+
+// OpenCL builtin test generator.  This class processes the same TableGen input
+// as BuiltinNameEmitter, but generates a .cl file that contains a call to each
+// builtin function described in the .td input.
+class OpenCLBuiltinTestEmitter {
+public:
+  OpenCLBuiltinTestEmitter(RecordKeeper , raw_ostream )
+  : Records(Records), OS(OS) {}
+
+  // Entrypoint to generate the functions for testing all OpenCL builtin
+  // functions.
+  void emit();
+
+private:
+  struct TypeFlags {
+TypeFlags() : IsConst(false), IsVolatile(false), IsPointer(false) {}
+bool IsConst : 1;
+bool IsVolatile : 1;
+bool IsPointer : 1;
+StringRef AddrSpace;
+  };
+
+  // Return a string representation of the given type, such that it can be
+  // used as a type in OpenCL C code.
+  std::string getTypeString(const Record *Type, TypeFlags Flags,
+int VectorSize) const;
+
+  // Return the type(s) and vector size(s) for the given type.  For
+  // non-GenericTypes, the resulting vectors will contain 1 element.  For
+  // GenericTypes, the resulting vectors typically contain multiple elements.
+  void getTypeLists(Record *Type, TypeFlags ,
+std::vector ,
+std::vector ) const;
+
+  // Expand the TableGen Records representing a builtin function signature into
+  // one or more function signatures.  Return them as a vector of a vector of
+  // strings, with each string containing an OpenCL C type and optional
+  // qualifiers.
+  //
+  // The Records may contain GenericTypes, which expand into multiple
+  // signatures.  Repeated occurrences of GenericType in a signature expand to
+  // the same types.  For example [char, FGenType, FGenType] expands to:
+  //   [char, float, float]
+  //   [char, float2, float2]
+  //   [char, float3, float3]
+  //   ...
+  void
+  expandTypesInSignature(const std::vector ,
+ SmallVectorImpl> );
+
+  // Contains OpenCL builtin functions and related information, stored as
+  // Record instances. They are coming from the associated TableGen file.
+  RecordKeeper 
+
+  // The output file.
+  raw_ostream 
+};
+
 } // namespace
 
 void BuiltinNameEmitter::Emit() {
@@ -861,7 +919,230 @@
   OS << "\n} // OCL2Qual\n";
 }
 
+std::string 

[PATCH] D103797: [clang] Use resolved path for headers in decluse diagnostics

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added a comment.

It is the absolute path of the header. e.g:

`module TestTU does not depend on a module exporting 
'/work/llvm/clang-tools-extra/clangd/AST.h'`

rather than

`module TestTU does not depend on a module exporting 'AST.h'`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103797

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

[PATCH] D102822: [Clang][CodeGen] Set the size of llvm.lifetime to unknown for scalable types.

[Hsiangkai Wang via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG2b13ff697946: [Clang][CodeGen] Set the size of llvm.lifetime 
to unknown for scalable types. (authored by HsiangKai).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102822

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGDecl.cpp
  clang/lib/CodeGen/CGExprAgg.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/CodeGen/RISCV/riscv-v-lifetime.cpp

Index: clang/test/CodeGen/RISCV/riscv-v-lifetime.cpp
===
--- /dev/null
+++ clang/test/CodeGen/RISCV/riscv-v-lifetime.cpp
@@ -0,0 +1,25 @@
+// REQUIRES: riscv-registered-target
+// RUN: %clang_cc1 -std=c++11 -triple riscv64 -target-feature +experimental-v \
+// RUN:   -O1 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s
+
+#include 
+
+vint32m1_t Baz();
+
+// CHECK-LABEL: @_Z4Testv(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[A:%.*]] = alloca *, align 8
+// CHECK-NEXT:[[REF_TMP:%.*]] = alloca , align 4
+// CHECK-NEXT:[[TMP0:%.*]] = bitcast ** [[A]] to i8*
+// CHECK-NEXT:call void @llvm.lifetime.start.p0i8(i64 8, i8* [[TMP0]]) #[[ATTR3:[0-9]+]]
+// CHECK-NEXT:[[TMP1:%.*]] = bitcast * [[REF_TMP]] to i8*
+// CHECK-NEXT:call void @llvm.lifetime.start.p0i8(i64 -1, i8* [[TMP1]]) #[[ATTR3]]
+// CHECK: [[TMP4:%.*]] = bitcast * [[REF_TMP]] to i8*
+// CHECK-NEXT:call void @llvm.lifetime.end.p0i8(i64 -1, i8* [[TMP4]]) #[[ATTR3]]
+// CHECK-NEXT:[[TMP5:%.*]] = bitcast ** [[A]] to i8*
+// CHECK-NEXT:call void @llvm.lifetime.end.p0i8(i64 8, i8* [[TMP5]]) #[[ATTR3]]
+//
+vint32m1_t Test() {
+  const vint32m1_t  = Baz();
+  return a;
+}
Index: clang/lib/CodeGen/CodeGenFunction.h
===
--- clang/lib/CodeGen/CodeGenFunction.h
+++ clang/lib/CodeGen/CodeGenFunction.h
@@ -2872,7 +2872,7 @@
   void EmitSehTryScopeBegin();
   void EmitSehTryScopeEnd();
 
-  llvm::Value *EmitLifetimeStart(uint64_t Size, llvm::Value *Addr);
+  llvm::Value *EmitLifetimeStart(llvm::TypeSize Size, llvm::Value *Addr);
   void EmitLifetimeEnd(llvm::Value *Size, llvm::Value *Addr);
 
   llvm::Value *EmitCXXNewExpr(const CXXNewExpr *E);
Index: clang/lib/CodeGen/CGExprAgg.cpp
===
--- clang/lib/CodeGen/CGExprAgg.cpp
+++ clang/lib/CodeGen/CGExprAgg.cpp
@@ -276,7 +276,7 @@
 RetAddr = Dest.getAddress();
   } else {
 RetAddr = CGF.CreateMemTemp(RetTy, "tmp", );
-uint64_t Size =
+llvm::TypeSize Size =
 CGF.CGM.getDataLayout().getTypeAllocSize(CGF.ConvertTypeForMem(RetTy));
 LifetimeSizePtr = CGF.EmitLifetimeStart(Size, RetAllocaAddr.getPointer());
 if (LifetimeSizePtr) {
Index: clang/lib/CodeGen/CGDecl.cpp
===
--- clang/lib/CodeGen/CGDecl.cpp
+++ clang/lib/CodeGen/CGDecl.cpp
@@ -1318,7 +1318,7 @@
 /// Emit a lifetime.begin marker if some criteria are satisfied.
 /// \return a pointer to the temporary size Value if a marker was emitted, null
 /// otherwise
-llvm::Value *CodeGenFunction::EmitLifetimeStart(uint64_t Size,
+llvm::Value *CodeGenFunction::EmitLifetimeStart(llvm::TypeSize Size,
 llvm::Value *Addr) {
   if (!ShouldEmitLifetimeMarkers)
 return nullptr;
@@ -1326,7 +1326,8 @@
   assert(Addr->getType()->getPointerAddressSpace() ==
  CGM.getDataLayout().getAllocaAddrSpace() &&
  "Pointer should be in alloca address space");
-  llvm::Value *SizeV = llvm::ConstantInt::get(Int64Ty, Size);
+  llvm::Value *SizeV = llvm::ConstantInt::get(
+  Int64Ty, Size.isScalable() ? -1 : Size.getFixedValue());
   Addr = Builder.CreateBitCast(Addr, AllocaInt8PtrTy);
   llvm::CallInst *C =
   Builder.CreateCall(CGM.getLLVMLifetimeStartFn(), {SizeV, Addr});
@@ -1549,12 +1550,9 @@
 // is rare.
 if (!Bypasses.IsBypassed() &&
 !(!getLangOpts().CPlusPlus && hasLabelBeenSeenInCurrentScope())) {
-  llvm::TypeSize size =
-  CGM.getDataLayout().getTypeAllocSize(allocaTy);
+  llvm::TypeSize Size = CGM.getDataLayout().getTypeAllocSize(allocaTy);
   emission.SizeForLifetimeMarkers =
-  size.isScalable() ? EmitLifetimeStart(-1, AllocaAddr.getPointer())
-: EmitLifetimeStart(size.getFixedSize(),
-AllocaAddr.getPointer());
+  EmitLifetimeStart(Size, AllocaAddr.getPointer());
 }
   } else {
 assert(!emission.useLifetimeMarkers());
Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -4683,7 +4683,7 @@
 } else {
   SRetPtr = CreateMemTemp(RetTy, 

[clang] 2b13ff6 - [Clang][CodeGen] Set the size of llvm.lifetime to unknown for scalable types.

[Hsiangkai Wang via cfe-commits]

Author: Hsiangkai Wang
Date: 2021-06-07T23:30:13+08:00
New Revision: 2b13ff69794680ea0764e516f5b69b80219771b7

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

LOG: [Clang][CodeGen] Set the size of llvm.lifetime to unknown for scalable 
types.

If the memory object is scalable type, we do not know the exact size of
it at compile time. Set the size of lifetime marker to unknown if the
object is scalable one.

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

Added: 
clang/test/CodeGen/RISCV/riscv-v-lifetime.cpp

Modified: 
clang/lib/CodeGen/CGCall.cpp
clang/lib/CodeGen/CGDecl.cpp
clang/lib/CodeGen/CGExprAgg.cpp
clang/lib/CodeGen/CodeGenFunction.h

Removed: 




diff  --git a/clang/lib/CodeGen/CGCall.cpp b/clang/lib/CodeGen/CGCall.cpp
index beb6b0ff464b8..1cd972f32f3ff 100644
--- a/clang/lib/CodeGen/CGCall.cpp
+++ b/clang/lib/CodeGen/CGCall.cpp
@@ -4683,7 +4683,7 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo 
,
 } else {
   SRetPtr = CreateMemTemp(RetTy, "tmp", );
   if (HaveInsertPoint() && ReturnValue.isUnused()) {
-uint64_t size =
+llvm::TypeSize size =
 CGM.getDataLayout().getTypeAllocSize(ConvertTypeForMem(RetTy));
 UnusedReturnSizePtr = EmitLifetimeStart(size, SRetAlloca.getPointer());
   }
@@ -4844,7 +4844,7 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo 
,
   IRCallArgs[FirstIRArg] = AI.getPointer();
 
   // Emit lifetime markers for the temporary alloca.
-  uint64_t ByvalTempElementSize =
+  llvm::TypeSize ByvalTempElementSize =
   CGM.getDataLayout().getTypeAllocSize(AI.getElementType());
   llvm::Value *LifetimeSize =
   EmitLifetimeStart(ByvalTempElementSize, AI.getPointer());

diff  --git a/clang/lib/CodeGen/CGDecl.cpp b/clang/lib/CodeGen/CGDecl.cpp
index 3be0f6a79b804..7948f431299c7 100644
--- a/clang/lib/CodeGen/CGDecl.cpp
+++ b/clang/lib/CodeGen/CGDecl.cpp
@@ -1318,7 +1318,7 @@ void CodeGenFunction::EmitAutoVarDecl(const VarDecl ) {
 /// Emit a lifetime.begin marker if some criteria are satisfied.
 /// \return a pointer to the temporary size Value if a marker was emitted, null
 /// otherwise
-llvm::Value *CodeGenFunction::EmitLifetimeStart(uint64_t Size,
+llvm::Value *CodeGenFunction::EmitLifetimeStart(llvm::TypeSize Size,
 llvm::Value *Addr) {
   if (!ShouldEmitLifetimeMarkers)
 return nullptr;
@@ -1326,7 +1326,8 @@ llvm::Value *CodeGenFunction::EmitLifetimeStart(uint64_t 
Size,
   assert(Addr->getType()->getPointerAddressSpace() ==
  CGM.getDataLayout().getAllocaAddrSpace() &&
  "Pointer should be in alloca address space");
-  llvm::Value *SizeV = llvm::ConstantInt::get(Int64Ty, Size);
+  llvm::Value *SizeV = llvm::ConstantInt::get(
+  Int64Ty, Size.isScalable() ? -1 : Size.getFixedValue());
   Addr = Builder.CreateBitCast(Addr, AllocaInt8PtrTy);
   llvm::CallInst *C =
   Builder.CreateCall(CGM.getLLVMLifetimeStartFn(), {SizeV, Addr});
@@ -1549,12 +1550,9 @@ CodeGenFunction::EmitAutoVarAlloca(const VarDecl ) {
 // is rare.
 if (!Bypasses.IsBypassed() &&
 !(!getLangOpts().CPlusPlus && hasLabelBeenSeenInCurrentScope())) {
-  llvm::TypeSize size =
-  CGM.getDataLayout().getTypeAllocSize(allocaTy);
+  llvm::TypeSize Size = CGM.getDataLayout().getTypeAllocSize(allocaTy);
   emission.SizeForLifetimeMarkers =
-  size.isScalable() ? EmitLifetimeStart(-1, 
AllocaAddr.getPointer())
-: EmitLifetimeStart(size.getFixedSize(),
-AllocaAddr.getPointer());
+  EmitLifetimeStart(Size, AllocaAddr.getPointer());
 }
   } else {
 assert(!emission.useLifetimeMarkers());

diff  --git a/clang/lib/CodeGen/CGExprAgg.cpp b/clang/lib/CodeGen/CGExprAgg.cpp
index 3fdb8aaaec46c..5fdfa28984f74 100644
--- a/clang/lib/CodeGen/CGExprAgg.cpp
+++ b/clang/lib/CodeGen/CGExprAgg.cpp
@@ -276,7 +276,7 @@ void AggExprEmitter::withReturnValueSlot(
 RetAddr = Dest.getAddress();
   } else {
 RetAddr = CGF.CreateMemTemp(RetTy, "tmp", );
-uint64_t Size =
+llvm::TypeSize Size =
 CGF.CGM.getDataLayout().getTypeAllocSize(CGF.ConvertTypeForMem(RetTy));
 LifetimeSizePtr = CGF.EmitLifetimeStart(Size, RetAllocaAddr.getPointer());
 if (LifetimeSizePtr) {

diff  --git a/clang/lib/CodeGen/CodeGenFunction.h 
b/clang/lib/CodeGen/CodeGenFunction.h
index b799ebc15c2c8..564063d6b7c84 100644
--- a/clang/lib/CodeGen/CodeGenFunction.h
+++ b/clang/lib/CodeGen/CodeGenFunction.h
@@ -2872,7 +2872,7 @@ class CodeGenFunction : public CodeGenTypeCache {
   void