@@ -2336,16 +2336,9 @@ bool Type::isArithmeticType() const {
}
bool Type::hasBooleanRepresentation() const {
- if (isBooleanType())
-return true;
-
- if (const EnumType *ET = getAs())
-return ET->getDecl()->getIntegerType()->isBooleanType();
-
- if (const AtomicType
https://github.com/rjmccall requested changes to this pull request.
Flagging as changes requested to at least verify that this doesn't change ABI
for Darwin.
https://github.com/llvm/llvm-project/pull/135564
___
cfe-commits mailing list
cfe-commits@lis
@@ -1302,6 +1302,7 @@ ItaniumRecordLayoutBuilder::LayoutBase(const
BaseSubobjectInfo *Base) {
setSize(std::max(getSize(), Offset + Layout.getSize()));
// Remember max struct/class alignment.
+ UnadjustedAlignment = std::max(UnadjustedAlignment, PreferredBaseAlign);
---
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/135564
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1302,6 +1302,7 @@ ItaniumRecordLayoutBuilder::LayoutBase(const
BaseSubobjectInfo *Base) {
setSize(std::max(getSize(), Offset + Layout.getSize()));
// Remember max struct/class alignment.
+ UnadjustedAlignment = std::max(UnadjustedAlignment, PreferredBaseAlign);
---
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/135564
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/135564
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/135564
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1302,6 +1302,7 @@ ItaniumRecordLayoutBuilder::LayoutBase(const
BaseSubobjectInfo *Base) {
setSize(std::max(getSize(), Offset + Layout.getSize()));
// Remember max struct/class alignment.
+ UnadjustedAlignment = std::max(UnadjustedAlignment, PreferredBaseAlign);
---
https://github.com/rjmccall approved this pull request.
Thanks, that addresses my testing concern.
https://github.com/llvm/llvm-project/pull/135564
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/
@@ -5238,6 +5238,14 @@ inline bool IsEnumDeclScoped(EnumDecl *ED) {
return ED->isScoped();
}
+/// Return the integer type corresponding to the given decl.
+///
+/// We use this function to break a cycle between the inline definitions in
+/// Type.h and Decl.h.
+inline QualTy
@@ -2774,7 +2774,7 @@ class alignas(TypeAlignment) Type : public
ExtQualsTypeCommonBase {
bool hasFloatingRepresentation() const;
/// Determine whether this type has a boolean representation
- /// of some sort.
+ /// of some sort, e.g., it is a boolean type or a vector
@@ -8623,6 +8624,13 @@ inline bool Type::isIntegralOrEnumerationType() const {
inline bool Type::isBooleanType() const {
if (const auto *BT = dyn_cast(CanonicalType))
return BT->getKind() == BuiltinType::Bool;
+ if (const EnumType *ET = dyn_cast(CanonicalType)) {
+//
@@ -2336,16 +2336,9 @@ bool Type::isArithmeticType() const {
}
bool Type::hasBooleanRepresentation() const {
- if (isBooleanType())
-return true;
-
- if (const EnumType *ET = getAs())
-return ET->getDecl()->getIntegerType()->isBooleanType();
-
- if (const AtomicType
@@ -8623,6 +8624,13 @@ inline bool Type::isIntegralOrEnumerationType() const {
inline bool Type::isBooleanType() const {
if (const auto *BT = dyn_cast(CanonicalType))
return BT->getKind() == BuiltinType::Bool;
+ if (const EnumType *ET = dyn_cast(CanonicalType)) {
+//
rjmccall wrote:
That's fine with me, yeah.
https://github.com/llvm/llvm-project/pull/136038
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rjmccall wrote:
> > At least, it must ensure that `__size_t` is equivalent to `size_t` and
> > generates the same mangled name.
>
> Is that possible? @rjmccall
If `size_t` is a different type from `__size_t`, then `void foo(size_t);`
declares a different entity from `void foo(__size_t);`. The
rjmccall wrote:
That is not possible, and this is exactly what I'm worried about with all this
discussion about making `size_t` more "built-in". `size_t` is specified to be a
typedef of a (platform-dependent) standard integer type, and it needs to
continue to behave that way; we cannot actuall
rjmccall wrote:
Messing around with `#include_next` is scary, but the problems are always
thorny reasons that only come up in intense testing; I don't see anything
obviously wrong, and I trust @ian-twilightcoder to have done the investigation
properly. LGTM.
https://github.com/llvm/llvm-proje
rjmccall wrote:
> > Similarly, ObjC selector components exist outside of the normal keyword
> > rules, and the warning should never kick in on them.
>
> I don't know about selectors all that much; can you give me a test case that
> you think I should handle?
In general: look at `ParseObjCSele
rjmccall wrote:
Yeah, triggering this at the preprocessor level is not going to let you do in
properly in Objective-C, where keywords are effectively context-sensitive. If
that's the only reasonable way to implement it, you should just turn it off in
Objective-C completely.
https://github.com
https://github.com/rjmccall commented:
Functionality seems fine. A couple minor requests, then LGTM.
https://github.com/llvm/llvm-project/pull/136867
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinf
@@ -6001,8 +6001,18 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo
&CallInfo,
for (auto it = EHStack.find(CurrentCleanupScopeDepth); it != EHStack.end();
++it) {
EHCleanupScope *Cleanup = dyn_cast(&*it);
- if (!(Cleanup && Cleanup->getCleanup(
@@ -0,0 +1,56 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
UTC_ARGS: --version 5
+// RUN: %clang_cc1 -emit-llvm -fextend-variable-liveness -o - %s | FileCheck %s
+
+/// Tests that when we have fake uses in a function ending in a musttail call,
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/136867
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -121,6 +121,7 @@ CAST_OPERATION(FunctionToPointerDecay)
/// CK_NullToPointer - Null pointer constant to pointer, ObjC
/// pointer, or block pointer.
/// (void*) 0
+/// (void*) nullptr
rjmccall wrote:
I think Eli is asking for you to note in the text tha
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/137364
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rjmccall approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/137364
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/135564
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1302,6 +1302,7 @@ ItaniumRecordLayoutBuilder::LayoutBase(const
BaseSubobjectInfo *Base) {
setSize(std::max(getSize(), Offset + Layout.getSize()));
// Remember max struct/class alignment.
+ UnadjustedAlignment = std::max(UnadjustedAlignment, PreferredBaseAlign);
---
rjmccall wrote:
The ObjC `@` is essentially an escape into a completely different grammar, and
it doesn't matter whether the following identifier is a keyword or not in the
base language. This warning should never kick in on that identifier.
Similarly, ObjC selector components exist outside of
rjmccall wrote:
> For what it's worth, the existing "keyword from language you're not using"
> warnings [already fire for analogous Objective-C++
> cases](https://godbolt.org/z/3K6835PPK)... which in those cases is correct,
> since Clang does _not_ accept C++11-onwards keywords as selector nam
rjmccall wrote:
It's fine to make these operators look up and use the `size_t` / `ptrdiff_t`
typedefs if they're available and have the right type. We would need to apply
an allowlist to the attributes on the typedef, too — it would be quite abusive,
but someone could use an `aligned` attribut
Alejandro =?utf-8?q?=C3=81lvarez_Ayll=C3=B3n?=,
Alejandro =?utf-8?q?=C3=81lvarez_Ayll=C3=B3n?=,
Alejandro =?utf-8?q?=C3=81lvarez_Ayll=C3=B3n?=,
Alejandro =?utf-8?q?=C3=81lvarez_Ayll=C3=B3n?=,
Alejandro =?utf-8?q?=C3=81lvarez_Ayll=C3=B3n?=,
Alejandro =?utf-8?q?=C3=81lvarez_Ayll=C3=B3n?=
Message-ID:
@@ -,6 +,96 @@ class CGObjCObjFW: public CGObjCGNU {
return ClassSymbol;
}
+ void GenerateDirectMethodPrologue(
+ CodeGenFunction &CGF, llvm::Function *Fn, const ObjCMethodDecl *OMD,
+ const ObjCContainerDecl *CD) override {
+auto &Builder = CGF.Bu
https://github.com/rjmccall approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/126382
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -73,7 +73,7 @@ namespace {
// value of the expression to the unqualified, non-atomic version of
// the named type.
if (!S.Context.getLangOpts().ObjC && !DestType->isRecordType() &&
- !DestType->isArrayType()) {
+ !DestType->isArrayType
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 -triple arm64-apple-ios -fsyntax-only -verify
-fptrauth-intrinsics -std=c++11 %s
+// RUN: %clang_cc1 -triple aarch64-linux-gnu -fsyntax-only -verify
-fptrauth-intrinsics -std=c++11 %s
+
+template struct G {
+ T __ptrauth(0,0,1234) test;
+
@@ -0,0 +1,142 @@
+// RUN: %clang_cc1 -triple arm64-apple-ios -std=c++11 -fptrauth-calls
-fptrauth-intrinsics -verify -fsyntax-only %s
+// RUN: %clang_cc1 -triple aarch64-linux-gnu -std=c++11 -fptrauth-calls
-fptrauth-intrinsics -verify -fsyntax-only %s
+
+#define AQ __ptrauth
rjmccall wrote:
Can you confirm that the intent here is to restore mangler behavior to what it
was prior to #132401, making the pair of PRs ABI-neutral?
https://github.com/llvm/llvm-project/pull/138947
___
cfe-commits mailing list
cfe-commits@lists.ll
rjmccall wrote:
Merging this was fine because it was just removing the redundant LangAS
argument, not removing the abstract handling of address-space conversions in
IRGen. I just wanted to note my opposition to the idea of taking that second
step, since it had come up in the review.
https://g
rjmccall wrote:
The AMDGPU `TargetInfo` is responsible for ensuring that the choices it makes
match the ABI. It is inconceivable that just dropping in the converted struct
type that Clang IRGen uses as a direct parameter or result type would be a
correct way to implement this; even if by chanc
https://github.com/rjmccall commented:
I'm surprised we need all this. Since we don't distinguish arrays from their
elements in TBAA, is it not sufficient to just make sure that array subscript
expressions produce an l-value with the same TBAA metadata as their base
l-value?
https://github.co
rjmccall wrote:
Okay, it sounds like this is where we've left off:
- The standard is using an odd formulation in
[[class.cdtor]p2](https://eel.is/c++draft/class.cdtor) that we're not sure how
to interpret. It's possible that it's formally slightly weaker than `restrict`
might be, which would m
https://github.com/rjmccall approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/137719
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/137719
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -4503,7 +4503,29 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const
ArraySubscriptExpr *E,
E->getType(), !getLangOpts().PointerOverflowDefined, SignedIndices,
E->getExprLoc(), &arrayType, E->getBase());
EltBaseInfo = ArrayLV.getBaseInfo();
-EltT
https://github.com/rjmccall commented:
Thanks, those seem like good reasons.
https://github.com/llvm/llvm-project/pull/137719
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rjmccall wrote:
It's not actually clang's responsibility to not break your transformation. We
don't want to break it gratuitously, but if clang is generating correct code,
your transformation needs to be flexible enough to handle it. If there's
something easy we can do to help your transformat
rjmccall wrote:
Sorry, can you back up and explain the root problem you're trying to solve? You
have a platform where we're emitting accesses to `errno` as if it weren't an
`int`? What does it look like in source?
https://github.com/llvm/llvm-project/pull/125258
___
rjmccall wrote:
> Oh, sorry for not providing context earlier. The reasoning behind is to allow
> certain optimizations involving errno-writing libcalls (marked as
> `memory(errnomem: write)`) to occur, if we are able to prove the involved
> memory location does not alias errno (e.g., because
1001 - 1051 of 1051 matches
Mail list logo
