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
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:
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:
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 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
@@ -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 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
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:
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:
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:
> 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:
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
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:
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:
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
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
@@ -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 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/136867
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -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(
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
@@ -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,
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:
> > 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'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:
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
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/
@@ -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)) {
+//
@@ -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)) {
+//
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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 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);
---
@@ -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
@@ -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
@@ -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
@@ -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
@@ -9242,3 +9242,15 @@ Declares that a function potentially allocates heap
memory, and prevents any pot
of ``nonallocating`` by the compiler.
}];
}
+
+def ValueTypeDocs : Documentation {
+ let Category = DocCatDecl;
+ let Content = [{
+The ``value_type`` attribute can be u
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/95004
___
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/95004
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -9242,3 +9242,15 @@ Declares that a function potentially allocates heap
memory, and prevents any pot
of ``nonallocating`` by the compiler.
}];
}
+
+def ValueTypeDocs : Documentation {
+ let Category = DocCatDecl;
+ let Content = [{
+The ``value_type`` attribute can be u
@@ -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;
+
@@ -,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
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:
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:
In-Reply-To:
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
Alejandro =?utf-8?q?Álvarez_Ayllón?=,
Alejandro =?utf-8?q?Álvarez_Ayllón?=,
Alejandro =?utf-8?q?Álvarez_Ayllón?=,
Alejandro =?utf-8?q?Álvarez_Ayllón?Message-ID:
In-Reply-To:
@@ -163,6 +163,7 @@ Bug Fixes to C++ Support
Bug Fixes to AST Handling
^
+- F
https://github.com/rjmccall approved this pull request.
Thank you; LGTM.
https://github.com/llvm/llvm-project/pull/126644
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3397,53 +3309,53 @@ void CGObjCMac::GenerateCategory(const
ObjCCategoryImplDecl *OCD) {
enum FragileClassFlags {
/// Apparently: is not a meta-class.
- FragileABI_Class_Factory = 0x1,
+ FragileABI_Class_Factory = 0x1,
rjmccall
https://github.com/rjmccall approved this pull request.
Thanks, the new comment looks great. LGTM.
https://github.com/llvm/llvm-project/pull/126047
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/
@@ -80,6 +80,28 @@ llvm::MDNode *CodeGenTBAA::getChar() {
return Char;
}
+llvm::MDNode *CodeGenTBAA::getAnyPtr(unsigned PtrDepth) {
+ assert(PtrDepth >= 1 && "Pointer must have some depth");
+
+ // Populate at least PtrDepth elements in AnyPtrs. These are the type nodes
+
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/126047
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rjmccall commented:
Functionality LGTM; just some suggested tweaks to the comments.
https://github.com/llvm/llvm-project/pull/126047
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listi
@@ -256,7 +277,7 @@ llvm::MDNode *CodeGenTBAA::getTypeInfoHelper(const Type
*Ty) {
// similar-types rule.
const auto *RT = Ty->getAs();
if (!RT)
-return AnyPtr;
+return getAnyPtr();
rjmccall wrote:
This and the site below sho
Alejandro =?utf-8?q?Álvarez_Ayllón?=,
Alejandro =?utf-8?q?Álvarez_Ayllón?=,
Alejandro =?utf-8?q?Álvarez_Ayllón?Message-ID:
In-Reply-To:
@@ -15919,10 +15919,17 @@ ExprResult Sema::ActOnStmtExprResult(ExprResult ER) {
if (Cast && Cast->getCastKind() == CK_ARCConsumeObject)
rjmccall wrote:
We're documenting a weaker guarantee than we implement, yes.
https://github.com/llvm/llvm-project/pull/122116
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Alejandro =?utf-8?q?Álvarez_Ayllón?=,
Alejandro =?utf-8?q?Álvarez_Ayllón?=,
Alejandro =?utf-8?q?Álvarez_Ayllón?Message-ID:
In-Reply-To:
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/119711
___
cfe-commits mailing list
cf
Alejandro =?utf-8?q?Álvarez_Ayllón?=,
Alejandro =?utf-8?q?Álvarez_Ayllón?=,
Alejandro =?utf-8?q?Álvarez_Ayllón?Message-ID:
In-Reply-To:
@@ -15919,10 +15919,17 @@ ExprResult Sema::ActOnStmtExprResult(ExprResult ER) {
if (Cast && Cast->getCastKind() == CK_ARCConsumeObject)
rjmccall wrote:
I agree with Nikita. I have no problem with supporting this builtin, but it
feels like something that should be expressed portably as an IR intrinsic and
then get lowered in the backend rather than needing frontend work for every
target.
https://github.com/llvm/llvm-project/pu
https://github.com/rjmccall approved this pull request.
LGTM, thanks!
https://github.com/llvm/llvm-project/pull/122116
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2489,6 +2489,81 @@ are listed below.
$ clang -fuse-ld=lld -Oz -Wl,--icf=safe -fcodegen-data-use code.cc
+Strict Aliasing
+---
+
+The C and C++ standards require accesses to objects in memory to use l-values
of
+an appropriate type for the object. This is
@@ -2489,6 +2489,81 @@ are listed below.
$ clang -fuse-ld=lld -Oz -Wl,--icf=safe -fcodegen-data-use code.cc
+Strict Aliasing
+---
+
+The C and C++ standards require accesses to objects in memory to use l-values
of
+an appropriate type for the object. This is
https://github.com/rjmccall commented:
Last minute re-read caught a couple slip-ups, and yeah, as mentioned, please
feel free to augment this with other relevant information for users. Also, I'm
definitely not sure the separate clang-cl section is worth keeping; it's pretty
short, and any extr
@@ -2489,6 +2489,81 @@ are listed below.
$ clang -fuse-ld=lld -Oz -Wl,--icf=safe -fcodegen-data-use code.cc
+Strict Aliasing
+---
+
+The C and C++ standards require accesses to objects in memory to use l-values
of
+an appropriate type for the object. This is
@@ -2489,6 +2489,81 @@ are listed below.
$ clang -fuse-ld=lld -Oz -Wl,--icf=safe -fcodegen-data-use code.cc
+Strict Aliasing
+---
+
+The C and C++ standards require accesses to objects in memory to use l-values
of
+an appropriate type for the object. This is
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/122116
___
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.
This looks right to me, but let me tag in @akyrtzi just to make his own pass
over this.
https://github.com/llvm/llvm-project/pull/119269
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
ht
rjmccall wrote:
It's probably right that these should match the behavior of adding or removing
a `*` (the latter of which can happen via template argument deduction), which
does mean they need to handle ObjC pointer types correctly.
https://github.com/llvm/llvm-project/pull/123678
@@ -5692,7 +5692,10 @@ CGCallee CodeGenFunction::EmitCallee(const Expr *E) {
// Resolve direct calls.
} else if (auto DRE = dyn_cast(E)) {
if (auto FD = dyn_cast(DRE->getDecl())) {
- return EmitDirectCallee(*this, FD);
+ auto CalleeDecl = FD->hasAttr()
+
https://github.com/rjmccall approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/109056
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3442,6 +3442,35 @@ uint16_t
ASTContext::getPointerAuthTypeDiscriminator(QualType T) {
encodeTypeForFunctionPointerAuth(*this, Out, T);
} else {
T = T.getUnqualifiedType();
+// Drop exception specification from member function pointer type.
rj
@@ -3442,6 +3442,13 @@ uint16_t
ASTContext::getPointerAuthTypeDiscriminator(QualType T) {
encodeTypeForFunctionPointerAuth(*this, Out, T);
} else {
T = T.getUnqualifiedType();
+// Drop exception specification from member function pointer type.
+if (auto *MPT
@@ -3442,6 +3442,13 @@ uint16_t
ASTContext::getPointerAuthTypeDiscriminator(QualType T) {
encodeTypeForFunctionPointerAuth(*this, Out, T);
} else {
T = T.getUnqualifiedType();
+// Drop exception specification from member function pointer type.
rj
rjmccall wrote:
Okay, so if the ultimate pointee type is `void`, we're basically treating that
as a generic pointer, no matter what the pointer depth is? I guess that makes
sense.
> What would be a good place to document this?
Hmm, I was hoping that we would have a section in the manual alre
rjmccall wrote:
I agree that allowing `void*` l-values to alias arbitrary pointer objects is
probably the right pragmatic choice. We should document it, though.
@pinskia, does GCC apply this recursively — e.g. are `void**` l-values treated
specially in any way, or are they basically just `char
@@ -0,0 +1,37 @@
+// RUN: split-file %s %t
+// RUN: python %t/gen.py %t/switch-overflow.c %t/tmp.c && %clang_cc1
-emit-llvm %t/tmp.c -o - | FileCheck %t/tmp.c
+
+//--- gen.py
rjmccall wrote:
If you don't mind working on the representation issue, I think that wou
rjmccall wrote:
> FYI it looks like this has a fairly large impact on compile-time, esp at `O0`
> with a clang host compiler
> (https://llvm-compile-time-tracker.com/compare.php?from=1fcb6a9754a8db057e18f629cb90011b638901e7&to=4797437463e63ee289a1ff1904cfb7b2fe6cb4c2&stat=instructions%3Au).
>
rjmccall wrote:
> > > Let's just increase to 9 bits.
> > > Have you checked whether the size of `Stmt` or `Expr` changes when you do
> > > this?
> >
> >
> > @rjmccall I've changed it to 9 bits and checked that `Stmt` and `Expr` are
> > still 8 bytes and 16 bytes resp..
>
> I think checking j
https://github.com/rjmccall commented:
Let's just increase to 9 bits.
Have you checked whether the size of `Stmt` or `Expr` changes when you do this?
https://github.com/llvm/llvm-project/pull/120341
___
cfe-commits mailing list
cfe-commits@lists.llvm.
@@ -225,7 +225,9 @@ ABIArgInfo AMDGPUABIInfo::classifyArgumentType(QualType Ty,
bool Variadic,
// Records with non-trivial destructors/copy-constructors should not be
// passed by value.
if (auto RAA = getRecordArgABI(Ty, getCXXABI()))
- return getNaturalAlign
@@ -800,7 +800,9 @@ static ABIArgInfo classifyExpandedType(SwiftAggLowering
&lowering,
if (lowering.empty()) {
return ABIArgInfo::getIgnore();
} else if (lowering.shouldPassIndirectly(forReturn)) {
-return ABIArgInfo::getIndirect(alignmentForIndirect, /*byval*/ fal
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/114062
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -225,7 +225,9 @@ ABIArgInfo AMDGPUABIInfo::classifyArgumentType(QualType Ty,
bool Variadic,
// Records with non-trivial destructors/copy-constructors should not be
// passed by value.
if (auto RAA = getRecordArgABI(Ty, getCXXABI()))
- return getNaturalAlign
https://github.com/rjmccall requested changes to this pull request.
I'm fine with how you're handling the address spaces for now.
I'd like to talk about the rule you're implementing, though. It looks like
it's supposed to be:
- return values always use the alloca AS
- arguments always use the
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/114062
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -800,7 +800,9 @@ static ABIArgInfo classifyExpandedType(SwiftAggLowering
&lowering,
if (lowering.empty()) {
return ABIArgInfo::getIgnore();
} else if (lowering.shouldPassIndirectly(forReturn)) {
-return ABIArgInfo::getIndirect(alignmentForIndirect, /*byval*/ fal
1 - 100 of 1051 matches
Mail list logo
