@@ -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 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
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 commented:
Generally LGTM, although I agree with requests above.
https://github.com/llvm/llvm-project/pull/142541
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-co
@@ -7676,10 +7676,26 @@ CGObjCNonFragileABIMac::GetInterfaceEHType(const
ObjCInterfaceDecl *ID,
}
llvm::Value *VTableIdx = llvm::ConstantInt::get(CGM.Int32Ty, 2);
+ llvm::Constant *VTablePtr = llvm::ConstantExpr::getInBoundsGetElementPtr(
+ VTableGV->getValueType(),
https://github.com/rjmccall commented:
LGTM, but I've fixed the release note: this is about the Objective-C exceptions
ABI, not a general `type_info` thing for Objective-C++.
https://github.com/llvm/llvm-project/pull/135562
___
cfe-commits mailing lis
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/135562
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -317,6 +317,7 @@ Non-comprehensive list of changes in this release
``sizeof`` or ``typeof`` expression. (#GH138444)
- Deprecation warning is emitted for the deprecated
``__reference_binds_to_temporary`` intrinsic.
``__reference_constructs_from_temporary`` should be used
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/135562
___
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.
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
@@ -259,78 +284,6 @@ typedef __UINTPTR_TYPE__ ptrauth_generic_signature_t;
/* The value is ptrauth_string_discriminator("init_fini") */
#define __ptrauth_init_fini_discriminator 0xd9d4
-#else
-
-#define ptrauth_strip(__value, __key)
\
@@ -32,9 +32,9 @@ struct X f(void);
// C11-O2-NEXT:[[A:%.*]] = getelementptr inbounds nuw [[STRUCT_X]], ptr
[[REF_TMP]], i32 0, i32 0
// C11-O2-NEXT:[[ARRAYDECAY:%.*]] = getelementptr inbounds [5 x i32], ptr
[[A]], i64 0, i64 0
// C11-O2-NEXT:call void @llvm.lifet
@@ -1467,6 +1468,17 @@ void CodeGenModule::Release() {
}
}
}
+
+ // Emit `!llvm.errno.tbaa`, a module-level metadata that specifies the TBAA
+ // for an integer access.
rjmccall wrote:
```suggestion
// for an int access. This allows LLVM to rea
https://github.com/rjmccall requested changes to this pull request.
Functionality LGTM. I have a somewhat annoying request for the tests, but it
should make things a lot easier for the next person.
https://github.com/llvm/llvm-project/pull/125258
___
@@ -32,9 +32,9 @@ struct X f(void);
// C11-O2-NEXT:[[A:%.*]] = getelementptr inbounds nuw [[STRUCT_X]], ptr
[[REF_TMP]], i32 0, i32 0
// C11-O2-NEXT:[[ARRAYDECAY:%.*]] = getelementptr inbounds [5 x i32], ptr
[[A]], i64 0, i64 0
// C11-O2-NEXT:call void @llvm.lifet
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/125258
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rjmccall requested changes to this pull request.
This all looks good to me. Please add a release note saying that we fixed an
issue where the implementation was stricter than the ARC specification said.
Also, I know that you had some questions around `const` and other qualifi
@@ -16149,7 +16149,7 @@ class ExitFunctionBodyRAII {
bool IsLambda = false;
};
-static void diagnoseImplicitlyRetainedSelf(Sema &S) {
+static void diagnoseBlockCaptures(Sema &S) {
rjmccall wrote:
Maybe `diagnoseEscapingBlockCaptures`?
https://github.com/ll
@@ -8243,8 +8259,7 @@ class Sema final : public SemaBase {
/// List of SourceLocations where 'self' is implicitly retained inside a
/// block.
- llvm::SmallVector, 1>
- ImplicitlyRetainedSelfLocs;
+ llvm::SmallVector DiagnosableBlockCaptures;
rjmcca
@@ -1641,6 +1641,17 @@ def warn_implicitly_retains_self : Warning <
"block implicitly retains 'self'; explicitly mention 'self' to indicate "
"this is intended behavior">,
InGroup>, DefaultIgnore;
+def warn_blocks_capturing_this : Warning<"block implicitly captures 'this'
@@ -1641,6 +1641,17 @@ def warn_implicitly_retains_self : Warning <
"block implicitly retains 'self'; explicitly mention 'self' to indicate "
"this is intended behavior">,
InGroup>, DefaultIgnore;
+def warn_blocks_capturing_this : Warning<"block implicitly captures 'this'
https://github.com/rjmccall approved this pull request.
Thanks, LGTM.
https://github.com/llvm/llvm-project/pull/144458
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rjmccall wrote:
I've been informed that I've misunderstood the nature of "trivial relocation" —
it is not a "trivial" operation in the usual sense of triviality, it's just an
operation that (1) can be done primitively by the compiler and (2) cannot fail.
That addresses my concern, because we c
https://github.com/rjmccall commented:
Could you also test that casts which preserve qualifiers work as expected?
https://github.com/llvm/llvm-project/pull/144458
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/ma
https://github.com/rjmccall commented:
If it's not a bitwise copy, it's by definition not a trivial relocation, so I
don't think this works. I think you're arguing for some kind of intermediate
"non-failing relocation" feature.
Are we really reporting polymorphic class types as trivially reloc
rjmccall wrote:
It is very common for type traits to factor into the ABI of a template
specialization, such that `my_variant` has a different layout depending on
`is_amazing_v`. That is why changing the value of a type trait generally has
to be considered an ABI break.
https://github.com/llvm
rjmccall wrote:
So, devil's advocate: do we actually care about IR data layout alignments?
Clang should be putting explicit alignments on everything in the IR. And, I
mean, I can certainly imagine that a target might end up in an impossible
situation for terrible historical reasons, because e.
https://github.com/rjmccall approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/145497
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
1001 - 1076 of 1076 matches
Mail list logo
