@@ -326,25 +326,25 @@ struct LazyOffsetPtr {
///
/// If the low bit is clear, a pointer to the AST node. If the low
/// bit is set, the upper 63 bits are the offset.
- mutable uint64_t Ptr = 0;
+ mutable uintptr_t Ptr = 0;
public:
LazyOffsetPtr() = default;
- exp
@@ -326,25 +326,25 @@ struct LazyOffsetPtr {
///
/// If the low bit is clear, a pointer to the AST node. If the low
/// bit is set, the upper 63 bits are the offset.
- mutable uint64_t Ptr = 0;
+ mutable uintptr_t Ptr = 0;
public:
LazyOffsetPtr() = default;
- exp
@@ -326,25 +326,25 @@ struct LazyOffsetPtr {
///
/// If the low bit is clear, a pointer to the AST node. If the low
/// bit is set, the upper 63 bits are the offset.
- mutable uint64_t Ptr = 0;
+ mutable uintptr_t Ptr = 0;
public:
LazyOffsetPtr() = default;
- exp
@@ -1780,6 +1780,14 @@ class TargetInfo : public TransferrableTargetInfo,
return 0;
}
+ /// \returns Target specific address space for indirect (e.g. sret)
arguments.
+ /// If such an address space exists, it must be convertible to and from the
+ /// alloca address s
https://github.com/rjmccall requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/116991
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -206,12 +206,14 @@ llvm::MDNode *CodeGenTBAA::getTypeInfoHelper(const Type
*Ty) {
if (!CodeGenOpts.PointerTBAA)
return AnyPtr;
// Compute the depth of the pointer and generate a tag of the form
"p
-// ".
+// ". Look through pointer and array types to
@@ -230,6 +232,11 @@ llvm::MDNode *CodeGenTBAA::getTypeInfoHelper(const Type
*Ty) {
->getString();
TyName = Name;
} else {
+ // Be conservative if the type a MemberPointerType. Those would require
+ // stripping const-qualifiers inside the typ
@@ -206,12 +206,14 @@ llvm::MDNode *CodeGenTBAA::getTypeInfoHelper(const Type
*Ty) {
if (!CodeGenOpts.PointerTBAA)
return AnyPtr;
// Compute the depth of the pointer and generate a tag of the form
"p
-// ".
+// ". Look through pointer and array types to
@@ -206,12 +206,14 @@ llvm::MDNode *CodeGenTBAA::getTypeInfoHelper(const Type
*Ty) {
if (!CodeGenOpts.PointerTBAA)
return AnyPtr;
// Compute the depth of the pointer and generate a tag of the form
"p
-// ".
+// ". Look through pointer and array types to
rjmccall wrote:
Yeah, that's my take as well. Anything we do to make this work better risks
being interpreted as treating this as somehow supported, which it absolutely is
not.
https://github.com/llvm/llvm-project/pull/116881
___
cfe-commits mailing
rjmccall wrote:
Hmm. We're talking here about C++'s type similarity rules, which come from C++
[conv.qual]p1:
> A cv-decomposition of a type T is a sequence of cv_i and P_i such that T is
> “cv_0 P_0 cv_1 P_1 ··· cv_n−1 P_n−1 cv_n U” for n ≥ 0, where each cv_i is a
> set of cv-qualifiers, an
@@ -230,6 +230,15 @@ llvm::MDNode *CodeGenTBAA::getTypeInfoHelper(const Type
*Ty) {
->getString();
TyName = Name;
} else {
+ // For unnamed structs or unions C's compatible types rule applies. Two
+ // compatible types in different compilation
rjmccall wrote:
Address spaces from language dialects generally have required relationships and
behaviors in the language, and that really shouldn't be overridden by targets.
However, targets do need to be able to decide how target-specific address
spaces work, including how they interact with
rjmccall wrote:
I'm not sure what you're saying would need to pulled into a .cpp file. It
looks like there's only one actual call to `TI.isAddressSpaceSupersetOf`, so if
you just pass around an `ASTContext &` to that point, nothing else will need to
drill into it. And frankly that entire exp
rjmccall wrote:
Oh, you can just forward-declare `class ASTContext` at the top of that file.
It's funny that that isn't already there.
https://github.com/llvm/llvm-project/pull/115777
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://
rjmccall wrote:
> Okay the problem with using `ASTContext` here is that it creates some
> recursive includes. ~I can do this by moving the check into `Type.cpp`
> instead, so this will be function call instead of being inlined.~ This would
> require a lot of extra stuff so I'm going to defer i
@@ -697,45 +699,21 @@ class Qualifiers {
/// every address space is a superset of itself.
/// CL2.0 adds:
/// __generic is a superset of any address space except for __constant.
- static bool isAddressSpaceSupersetOf(LangAS A, LangAS B) {
-// Address spaces must
https://github.com/rjmccall commented:
Broadly LGTM. A few structural requests.
https://github.com/llvm/llvm-project/pull/115777
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -17,34 +17,34 @@
#include "clang/Basic/TargetInfo.h"
#include "clang/Basic/TargetOptions.h"
#include "llvm/Support/Compiler.h"
+#include "llvm/Support/NVPTXAddrSpace.h"
#include "llvm/TargetParser/Triple.h"
#include
namespace clang {
namespace targets {
static cons
@@ -31,6 +31,7 @@ namespace clang {
template class CanProxy;
template struct CanProxyAdaptor;
class CXXRecordDecl;
+class ASTContext;
rjmccall wrote:
Minor nit: these are alphabetized.
https://github.com/llvm/llvm-project/pull/115777
_
https://github.com/rjmccall edited
https://github.com/llvm/llvm-project/pull/115777
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -697,45 +699,21 @@ class Qualifiers {
/// every address space is a superset of itself.
/// CL2.0 adds:
/// __generic is a superset of any address space except for __constant.
- static bool isAddressSpaceSupersetOf(LangAS A, LangAS B) {
-// Address spaces must
rjmccall wrote:
I'm sorry if you've explained this before, but I thought our general approach
was to just store the options in individual expressions, and CodeGen should in
general already be paying attention to those options. Is there a specific
reason we also need to honor these at the comp
rjmccall wrote:
The ABI spec is pretty clear about this, and demangling is likely to get very
screwed up because of the inconsistency.
I think should do the following:
- We should file a bug with GCC pointing out the problem.
- We should fix the bug under new `-fclang-abi-compat=` versions, bu
https://github.com/rjmccall approved this pull request.
Code LGTM. I would still prefer this PR to just contain the NFC refactor, with
a follow up that adds the semantic changes to the AMDGPU and NVPTX targets.
https://github.com/llvm/llvm-project/pull/115777
___
@@ -5390,11 +5390,19 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo
&CallInfo,
V->getType()->isIntegerTy())
V = Builder.CreateZExt(V, ArgInfo.getCoerceToType());
-// If the argument doesn't match, perform a bitcast to coerce it. This
-
@@ -5390,11 +5390,19 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo
&CallInfo,
V->getType()->isIntegerTy())
V = Builder.CreateZExt(V, ArgInfo.getCoerceToType());
-// If the argument doesn't match, perform a bitcast to coerce it. This
-
@@ -5159,16 +5156,19 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo
&CallInfo,
} else if (!ReturnValue.isNull()) {
SRetPtr = ReturnValue.getAddress();
} else {
- SRetPtr = CreateMemTemp(RetTy, "tmp", &SRetAlloca);
+ SRetPtr = CreateMemTempWith
@@ -1780,6 +1786,15 @@ void CXXNameMangler::mangleDeviceStubName(const
IdentifierInfo *II) {
<< II->getName();
}
+void CXXNameMangler::mangleOCLDeviceStubName(const IdentifierInfo *II) {
+ // ::= __clang_ocl_kern_imp_
+ // ::= [n]
+ // ::=
+ StringRef OCLDevi
@@ -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 requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/115821
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2343,6 +2343,15 @@ void CodeGenModule::ConstructAttributeList(StringRef
Name,
// Collect function IR attributes from the CC lowering.
// We'll collect the paramete and result attributes later.
CallingConv = FI.getEffectiveCallingConvention();
+ GlobalDecl GD = Calle
@@ -1085,8 +1085,10 @@ llvm::Value *CodeGenFunction::EmitBlockLiteral(const
CGBlockInfo &blockInfo) {
blockAddr.getPointer(),
ConvertType(blockInfo.getBlockExpr()->getType()));
if (IsOpenCL) {
-CGM.getOpenCLRuntime().recordBlockInfo(blockInfo.BlockExpression, Inv
@@ -1780,6 +1786,15 @@ void CXXNameMangler::mangleDeviceStubName(const
IdentifierInfo *II) {
<< II->getName();
}
+void CXXNameMangler::mangleOCLDeviceStubName(const IdentifierInfo *II) {
+ // ::= __clang_ocl_kern_imp_
+ // ::= [n]
+ // ::=
+ StringRef OCLDevi
@@ -71,14 +71,19 @@ class GlobalDecl {
GlobalDecl(const FunctionDecl *D, unsigned MVIndex = 0)
: MultiVersionIndex(MVIndex) {
if (!D->hasAttr()) {
+ if (D->hasAttr()) {
+Value.setPointerAndInt(D, unsigned(KernelReferenceKind::Kernel));
+return;
@@ -1085,8 +1085,10 @@ llvm::Value *CodeGenFunction::EmitBlockLiteral(const
CGBlockInfo &blockInfo) {
blockAddr.getPointer(),
ConvertType(blockInfo.getBlockExpr()->getType()));
if (IsOpenCL) {
-CGM.getOpenCLRuntime().recordBlockInfo(blockInfo.BlockExpression, Inv
rjmccall wrote:
Apple actually removed this migrator from Xcode 16. As far as Apple is
concerned, this is now dead code, and we intend to open a PR to remove it (but
thank you for the prompt!).
https://github.com/llvm/llvm-project/pull/116792
___
cfe
rjmccall wrote:
Yes, I believe that's essentially just a version of the rewriter that uses a
different ABI (it tries to match the non-fragile Apple ObjC runtime rather than
the fragile one).
https://github.com/llvm/llvm-project/pull/119269
___
cfe-co
rjmccall wrote:
`test/Rewrite` is for the Objective-C => MSVC-compatible C++ rewriter
(`-rewrite-objc`), which is a different feature. That feature might *also* be
obsolete, but we haven't signed off on that yet AFAIK.
https://github.com/llvm/llvm-project/pull/119269
_
@@ -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
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)
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
@@ -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 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
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:
@@ -15919,10 +15919,17 @@ ExprResult Sema::ActOnStmtExprResult(ExprResult ER) {
if (Cast && Cast->getCastKind() == CK_ARCConsumeObject)
@@ -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
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
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
@@ -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
+
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
@@ -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
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
@@ -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 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
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
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.
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
@@ -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
@@ -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
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:
I haven't looked at your patch yet, and I'm not familiar with the `diagnose_if`
feature; I'm just commenting about the AST design question because I was tagged
in to do so. If `diagnose_if` is about compile-time evaluation — essentially
assertion failures during constant evalua
@@ -230,6 +243,12 @@ llvm::MDNode *CodeGenTBAA::getTypeInfoHelper(const Type
*Ty) {
->getString();
TyName = Name;
} else {
+ // Be conservative if the type isn't a RecordType. We are specifically
rjmccall wrote:
```suggestion
@@ -18,10 +20,23 @@ struct A {};
// CHECK-LABEL: define {{.*}} @_Z1g
const int *(A::*const *g(const int *(A::* const **p)[3], int
*(A::***q)[3]))[3] {
+ // CHECK: load ptr, ptr %p.addr
// CHECK: load ptr, {{.*}}, !tbaa ![[MEMPTR_TBAA:[^,]*]]
const int *(A::*const *x)[3
@@ -205,14 +205,27 @@ llvm::MDNode *CodeGenTBAA::getTypeInfoHelper(const Type
*Ty) {
llvm::MDNode *AnyPtr = createScalarTypeNode("any pointer", getChar(),
Size);
if (!CodeGenOpts.PointerTBAA)
return AnyPtr;
-// Compute the depth of the pointer and generate a
rjmccall wrote:
Having an abstraction for this would be nice. It doesn't *have* to be a base
class specifically, though; we can do a more extrinsic tagged-union without
actually unifying the class hierarchies, like `llvm::CallSite` does. Swift has
a type called `AnyFunctionRef` that unifies se
https://github.com/rjmccall commented:
This seems reasonable to me. Since it's standards-compliant, has a specific
opt-out flag, and is overridden by the general `-fno-strict-aliasing` flag, I
don't see any need for the RFC process. Still, you should definitely wait for
more feedback, especial
https://github.com/rjmccall approved this pull request.
https://github.com/llvm/llvm-project/pull/116596
___
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/116596
___
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/116991
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -249,6 +249,21 @@ llvm::MDNode *CodeGenTBAA::getTypeInfoHelper(const Type
*Ty) {
if (!Ty->isRecordType())
return AnyPtr;
+ // For unnamed structs or unions C's compatible types rule applies. Two
+ // compatible types in different compilation units c
rjmccall wrote:
> An abstraction that includes blocks doesn't help us here because we are
> looking for the combination of `NamedDecl` and `DeclContext` and `BlockDecl`
> isn't a `NamedDecl`.
I think you're focusing a little narrowly here. I can't imagine why you'd
specifically need a `NamedD
@@ -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()
+
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
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
@@ -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 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
@@ -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
@@ -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
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
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
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
@@ -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
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
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
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
+
@@ -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/
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
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,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
@@ -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)) {
+//
901 - 1000 of 1094 matches
Mail list logo
