[clang] [lldb] [clang][RecordLayoutBuilder] Be stricter about inferring packed-ness in ExternalLayouts (PR #97443)

@@ -2243,9 +2236,27 @@ ItaniumRecordLayoutBuilder::updateExternalFieldOffset(const FieldDecl *Field, uint64_t ComputedOffset) { uint64_t ExternalFieldOffset = External.getExternalFieldOffset(Field); - if (InferAlignmen

[clang] [lldb] [clang][RecordLayoutBuilder] Be stricter about inferring packed-ness in ExternalLayouts (PR #97443)

https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/97443 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [lldb] [clang][RecordLayoutBuilder] Be stricter about inferring packed-ness in ExternalLayouts (PR #97443)

@@ -2243,9 +2236,27 @@ ItaniumRecordLayoutBuilder::updateExternalFieldOffset(const FieldDecl *Field, uint64_t ComputedOffset) { uint64_t ExternalFieldOffset = External.getExternalFieldOffset(Field); - if (InferAlignmen

[clang] [clang] Emit initializers for static const/constexpr variables once they're met (PR #156933)

rjmccall wrote: > It seems once codegen meets an odr use of the variable, it doesn't emit the > initializer, only the global variable itself. Then while emitting some > function's body it meets the variable declaration, and if it was a static > variable it adds the initializer via AddInitializ

[clang] [clang] Emit initializers for static const/constexpr variables once they're met (PR #156933)

https://github.com/rjmccall commented: Initializers can be self-referential, so doing this eagerly might be problematic. Why does this help with initializing things in consteval functions? https://github.com/llvm/llvm-project/pull/156933 ___ cfe-comm

[clang] [Clang] Allow non-constant sizes for __builtin_assume_dereferenceable. (PR #156929)

https://github.com/rjmccall approved this pull request. https://github.com/llvm/llvm-project/pull/156929 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Allow non-const lvalue refs to vector elements (except vector ) (PR #156891)

https://github.com/rjmccall requested changes to this pull request. I imagine that GCC allows this by just binding the reference to the address of the element in the vector. The way you're implementing this, we have to introduce the concept of a non-addressable reference, which would be a major

[clang] [clang-tools-extra] [clang] AST: fix getAs canonicalization of leaf types (PR #155028)

https://github.com/rjmccall approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/155028 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] AST: fix getAs canonicalization of leaf types (PR #155028)

rjmccall wrote: The only thing that "leaf type" means is that there's no point in doing anything except `dyn_cast`ing the canonical type. It's not a real language concept, and we don't use the type property for any purpose except these `getAs` specializations. So if the specializations are wro

[clang] [clang][PAC] Fix builtins that claim address discriminated types are bitwise compatible (PR #154490)

@@ -74,7 +74,7 @@ static_assert(__is_trivially_destructible(S3)); static_assert(!__is_trivially_copyable(S3)); static_assert(!__is_trivially_relocatable(S3)); // expected-warning{{deprecated}} //FIXME -static_assert(__builtin_is_cpp_trivially_relocatable(S3)); +static_assert(!

[clang] [clang][PAC] Fix builtins that claim address discriminated types are bitwise compatible (PR #154490)

@@ -74,7 +74,7 @@ static_assert(__is_trivially_destructible(S3)); static_assert(!__is_trivially_copyable(S3)); static_assert(!__is_trivially_relocatable(S3)); // expected-warning{{deprecated}} //FIXME -static_assert(__builtin_is_cpp_trivially_relocatable(S3)); +static_assert(!

[clang] [Clang] Support generic bit counting builtins on fixed boolean vectors (PR #154203)

@@ -4213,7 +4213,7 @@ such as ``unsigned __int128`` and C23 ``unsigned _BitInt(N)``. ``__builtin_clzg`` (respectively ``__builtin_ctzg``) returns the number of leading (respectively trailing) 0 bits in the first argument. The first argument -can be of any unsigned integer ty

[clang] [Clang] Support generic bit counting builtins on fixed boolean vectors (PR #154203)

https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/154203 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Support generic bit counting builtins on fixed boolean vectors (PR #154203)

@@ -1693,6 +1693,22 @@ getBitTestAtomicOrdering(BitTest::InterlockingKind I) { llvm_unreachable("invalid interlocking"); } +static llvm::Value *EmitIntegerExpr(CodeGenFunction &CGF, const Expr *E) { + llvm::Value *ArgValue = CGF.EmitScalarExpr(E); + llvm::Type *ArgType = A

[clang] [Clang] Support generic bit counting builtins on fixed boolean vectors (PR #154203)

https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/154203 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Support generic bit counting builtins on fixed boolean vectors (PR #154203)

@@ -4213,7 +4213,7 @@ such as ``unsigned __int128`` and C23 ``unsigned _BitInt(N)``. ``__builtin_clzg`` (respectively ``__builtin_ctzg``) returns the number of leading (respectively trailing) 0 bits in the first argument. The first argument -can be of any unsigned integer ty

[clang] [Clang] Support generic bit counting builtins on fixed boolean vectors (PR #154203)

@@ -4213,7 +4213,7 @@ such as ``unsigned __int128`` and C23 ``unsigned _BitInt(N)``. ``__builtin_clzg`` (respectively ``__builtin_ctzg``) returns the number of leading (respectively trailing) 0 bits in the first argument. The first argument -can be of any unsigned integer ty

[clang] [Clang] Support generic bit counting builtins on fixed boolean vectors (PR #154203)

@@ -4213,7 +4213,7 @@ such as ``unsigned __int128`` and C23 ``unsigned _BitInt(N)``. ``__builtin_clzg`` (respectively ``__builtin_ctzg``) returns the number of leading (respectively trailing) 0 bits in the first argument. The first argument -can be of any unsigned integer ty

[clang] [Clang] Support generic bit counting builtins on fixed boolean vectors (PR #154203)

@@ -4213,7 +4213,7 @@ such as ``unsigned __int128`` and C23 ``unsigned _BitInt(N)``. ``__builtin_clzg`` (respectively ``__builtin_ctzg``) returns the number of leading (respectively trailing) 0 bits in the first argument. The first argument -can be of any unsigned integer ty

[clang] [Clang] Support generic bit counting builtins on fixed boolean vectors (PR #154203)

@@ -1693,6 +1693,22 @@ getBitTestAtomicOrdering(BitTest::InterlockingKind I) { llvm_unreachable("invalid interlocking"); } +static llvm::Value *EmitIntegerExpr(CodeGenFunction &CGF, const Expr *E) { rjmccall wrote: This is a very specialized operation with

[clang] [Clang] Support generic bit counting builtins on fixed boolean vectors (PR #154203)

@@ -13455,6 +13455,10 @@ bool IntExprEvaluator::VisitBuiltinCallExpr(const CallExpr *E, case Builtin::BI__lzcnt16: // Microsoft variants of count leading-zeroes case Builtin::BI__lzcnt: case Builtin::BI__lzcnt64: { +// TODO: Handle boolean vectors in constexpr conte

[clang] [Clang] Support generic bit counting builtins on fixed boolean vectors (PR #154203)

@@ -1693,6 +1693,22 @@ getBitTestAtomicOrdering(BitTest::InterlockingKind I) { llvm_unreachable("invalid interlocking"); } +static llvm::Value *EmitIntegerExpr(CodeGenFunction &CGF, const Expr *E) { + llvm::Value *ArgValue = CGF.EmitScalarExpr(E); + llvm::Type *ArgType = A

[clang] [Clang] Support generic bit counting builtins on fixed boolean vectors (PR #154203)

https://github.com/rjmccall requested changes to this pull request. Is the idea behind only supporting boolean vectors that the operation on arbitrary integer vectors probably ought to be a vector-to-vector operation? That seems reasonable, but are we going to regret having inconsistent behavio

[clang] [compiler-rt] [UBSan] Fix incorrect alignment reported when global new returns an o… (PR #152532)

https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/152532 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [compiler-rt] [UBSan] Fix incorrect alignment reported when global new returns an o… (PR #152532)

https://github.com/rjmccall requested changes to this pull request. (flagging that changes are requested, since I failed to do so on my earlier comment) https://github.com/llvm/llvm-project/pull/152532 ___ cfe-commits mailing list cfe-commits@lists.ll

[clang] [compiler-rt] [UBSan] Fix incorrect alignment reported when global new returns an o… (PR #152532)

https://github.com/rjmccall commented: So this is interesting, because I agree that the diagnostic message is misleading, but I'm not sure this is the right solution. The replaceable global `operator new` functions are required to return a pointer that's appropriately aligned to some target-sp

[clang] [compiler-rt] [UBSan] Fix incorrect alignment reported when global new returns an o… (PR #152532)

@@ -1798,7 +1798,7 @@ llvm::Value *CodeGenFunction::EmitCXXNewExpr(const CXXNewExpr *E) { SkippedChecks.set(SanitizerKind::Null, nullCheck); EmitTypeCheck(CodeGenFunction::TCK_ConstructorCall, E->getAllocatedTypeSourceInfo()->getTypeLoc().getBeginLoc(), -

[clang] [clang][Obj-C][PAC] Add support for authenticating block metadata (PR #152978)

https://github.com/rjmccall approved this pull request. https://github.com/llvm/llvm-project/pull/152978 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][Obj-C][PAC] Add support for authenticating block metadata (PR #152978)

@@ -4540,6 +4540,7 @@ defm aarch64_jump_table_hardening: OptInCC1FFlag<"aarch64-jump-table-hardening", defm ptrauth_objc_isa : OptInCC1FFlag<"ptrauth-objc-isa", "Enable signing and authentication of Objective-C object's 'isa' field">; defm ptrauth_objc_interface_sel : OptInCC1

[clang] [clang][Obj-C][PAC] Add support for authenticating block metadata (PR #152978)

@@ -4540,6 +4540,7 @@ defm aarch64_jump_table_hardening: OptInCC1FFlag<"aarch64-jump-table-hardening", defm ptrauth_objc_isa : OptInCC1FFlag<"ptrauth-objc-isa", "Enable signing and authentication of Objective-C object's 'isa' field">; defm ptrauth_objc_interface_sel : OptInCC1

[clang] [clang][Obj-C][PAC] Add support for authenticating block metadata (PR #152978)

https://github.com/rjmccall commented: Generally LGTM https://github.com/llvm/llvm-project/pull/152978 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][Obj-C][PAC] Add support for authenticating block metadata (PR #152978)

https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/152978 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [flang] [llvm] [Clang] Remove ARCMigrate (PR #119269)

rjmccall wrote: I've confirmed that it's still in active use. https://github.com/llvm/llvm-project/pull/119269 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [CodeGen][AArch64] ptrauth intrinsic to safely construct relative ptr (PR #142047)

rjmccall wrote: > > Oliver is right that we need custom checking in SemaChecking akin to the > > other builtins, e.g. to validate that the keys are constants. The pattern > > should be straightforward to follow. Otherwise the frontend changes LGTM > > except as noted. > > When I noticed that

[clang] [llvm] [CodeGen][AArch64] ptrauth intrinsic to safely construct relative ptr (PR #142047)

https://github.com/rjmccall requested changes to this pull request. Oliver is right that we need custom checking in SemaChecking akin to the other builtins, e.g. to validate that the keys are constants. The pattern should be straightforward to follow. Otherwise the frontend changes LGTM except

[clang] [llvm] [CodeGen][AArch64] ptrauth intrinsic to safely construct relative ptr (PR #142047)

@@ -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) \

[clang] [clang][CodeGen] Set `dead_on_return` on indirect pointer arguments (PR #148159)

https://github.com/rjmccall approved this pull request. Thanks, that LGTM. Looks like you have a merge conflict to resolve, but otherwise this is ready to go. https://github.com/llvm/llvm-project/pull/148159 ___ cfe-commits mailing list cfe-commits@li

[clang] [clang][ObjC][PAC] Add ptrauth protections to objective-c (PR #147899)

@@ -1003,15 +1003,29 @@ Arm and AArch64 Support `as specified here `_ is now available. - Support has been added for the following processors (command-line identifiers in pa

[clang] [clang][ObjC][PAC] Add ptrauth protections to objective-c (PR #147899)

https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/147899 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][ObjC][PAC] Add ptrauth protections to objective-c (PR #147899)

https://github.com/rjmccall approved this pull request. Mostly LGTM https://github.com/llvm/llvm-project/pull/147899 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][CodeGen] Set `dead_on_return` on indirect pointer arguments (PR #148159)

@@ -2852,8 +2852,17 @@ void CodeGenModule::ConstructAttributeList(StringRef Name, if (AI.getInReg()) Attrs.addAttribute(llvm::Attribute::InReg); - if (AI.getIndirectByVal()) + // Depending on the ABI, this may be either a byval or a dead_on_return +

[clang] [PATCH 1/4] [clang] Improve nested name specifier AST representation (PR #147835)

@@ -0,0 +1,585 @@ +//===- NestedNameSpecifier.h - C++ nested name specifiers ---*- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Ap

[clang] [PATCH 1/4] [clang] Improve nested name specifier AST representation (PR #147835)

rjmccall wrote: > > You should at minimum be able to layer the `NestedNameSpecifier` change on > > top of the `TagType` change. I can't see why that wouldn't work. > > > > 1. Add the structure for sugary `TagType`s. > > 2. Replace `ElaboratedType` with sugary `TagType`s. > > 3. Change the repre

[clang] Add warning for blocks capturing {'this', raw pointers, references} (PR #144388)

@@ -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'

[clang] [llvm] [AMDGPU][clang][CodeGen][opt] Add late-resolved feature identifying predicates (PR #134016)

rjmccall wrote: Right, but the code still contains some kind of check to decide which version of the library function to call. Maybe it's implicit by multiversioned functions or something, but there's *something* in the source code, because if the user just writes a kernel that does nothing bu

[clang] [llvm] [AMDGPU][clang][CodeGen][opt] Add late-resolved feature identifying predicates (PR #134016)

rjmccall wrote: So your users today are building for generic AMDGPU but using builtins that are only available on a specific processor release? Presumably that code is protected *somehow* and their programs are not simply crashing at runtime. Is that something you'd be able to leverage at all,

[clang] [llvm] [AMDGPU][clang][CodeGen][opt] Add late-resolved feature identifying predicates (PR #134016)

rjmccall wrote: I think Eli is suggesting something like the rule for [@available](https://clang.llvm.org/docs/LanguageExtensions.html#objective-c-available): - If a builtin is unconditionally available, you can always use it without any diagnostics. - If a builtin is only available on specific

[clang] [llvm] [AMDGPU][clang][CodeGen][opt] Add late-resolved feature identifying predicates (PR #134016)

rjmccall wrote: An intrinsic seems like the right IR model for CPU recognition, even for targets that don't specifically need to late-resolve it. That should be much easier for passes to optimize based on CPU settings than directly emitting the compiler-rt reference in the frontend. I know tha

[clang] [llvm] [AMDGPU][clang][CodeGen][opt] Add late-resolved feature identifying predicates (PR #134016)

rjmccall wrote: > Slightly independently, cpu_supports might turn out a bit difficult to use, > at least for us (and I suspect other targets), as the feature definitions are > often ad hoc and sadly mutable. Hmm. Well, you get to define what feature names you recognize in `__builtin_cpu_suppo

[clang] [llvm] [AMDGPU][clang][CodeGen][opt] Add late-resolved feature identifying predicates (PR #134016)

rjmccall wrote: Alex, can you talk about why your design decides to check for specific builtins rather than building out the set of features supported by `__builtin_cpu_supports`? https://github.com/llvm/llvm-project/pull/134016 ___ cfe-commits maili

[clang] [llvm] [AMDGPU][clang][CodeGen][opt] Add late-resolved feature identifying predicates (PR #134016)

rjmccall wrote: > > On a different point: I don't think this builtin is actually semantically > > different from `__builtin_cpu_is`. As long as we're not treating it as > > `constexpr`, the fact that it's lowered by the compiler and doesn't need a > > runtime check is just a happy property of

[clang] Add warning for blocks capturing {'this', raw pointers, references} (PR #144388)

@@ -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'

[clang] [llvm] [AMDGPU][clang][CodeGen][opt] Add late-resolved feature identifying predicates (PR #134016)

rjmccall wrote: Yeah, I agree with the other parts of your design, enabling the builtins within the guarded statements is a great way to handle it. On a different point: I don't think this builtin is actually semantically different from `__builtin_cpu_is`. As long as we're not treating it as

[clang] [llvm] [AMDGPU][clang][CodeGen][opt] Add late-resolved feature identifying predicates (PR #134016)

rjmccall wrote: Recognizing when the `if` condition is just a call to the builtin (possibly parenthesized or `&&`ed) seems totally sufficient to me. You could check that the builtin isn't used in any other position if you want, but I don't think that's really necessary. https://github.com/llv

[clang] [clang] Fix __builtin_mul_overflow for big _BitInts (PR #145497)

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

[clang] [Clang] Verify data layout consistency (PR #144720)

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.

[clang] [clang][PAC] Support trivially_relocating polymorphic objects (PR #144420)

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

[clang] [Sema][ObjC] Loosen restrictions on reinterpret_cast involving indirect ARC-managed pointers (PR #144458)

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

[clang] [Sema][ObjC] Loosen restrictions on reinterpret_cast involving indirect ARC-managed pointers (PR #144458)

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

[clang] [clang][PAC] Support trivially_relocating polymorphic objects (PR #144420)

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

[clang] [clang][PAC] Support trivially_relocating polymorphic objects (PR #144420)

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

[clang] [Sema][ObjC] Loosen restrictions on reinterpret_cast involving indirect ARC-managed pointers (PR #144458)

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

[clang] Add warning for blocks capturing {'this', raw pointers, references} (PR #144388)

@@ -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

[clang] Add warning for blocks capturing {'this', raw pointers, references} (PR #144388)

@@ -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

[clang] Add warning for blocks capturing {'this', raw pointers, references} (PR #144388)

@@ -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'

[clang] Add warning for blocks capturing {'this', raw pointers, references} (PR #144388)

@@ -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'

[clang] [llvm] [CodeGen][AArch64] ptrauth intrinsic to safely construct relative ptr (PR #142047)

@@ -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) \

[clang] [clang][CGObjC] Sign the v-table pointer in ObjC exception RTTI. (PR #135562)

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

[clang] [clang][CGObjC] Sign the v-table pointer in ObjC exception RTTI. (PR #135562)

@@ -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

[clang] [clang][CGObjC] Sign the v-table pointer in ObjC exception RTTI. (PR #135562)

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

[clang] [clang][CGObjC] Sign the v-table pointer in ObjC exception RTTI. (PR #135562)

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

[clang] [clang][CGObjC] Sign the v-table pointer in ObjC exception RTTI. (PR #135562)

@@ -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(),

[clang] [clang] Diagnose [[nodiscard]] return types in Objective-C++ (PR #142541)

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

[clang] [CodeGen] Add TBAA struct path info for array members (PR #137719)

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

[clang] [llvm] [clang][CodeGen][AA] Introduce `!llvm.errno.tbaa` for errno alias disambiguation (PR #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

[clang] [llvm] [clang][CodeGen][AA] Introduce `!llvm.errno.tbaa` for errno alias disambiguation (PR #125258)

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

[clang] [llvm] [clang][CodeGen][AA] Introduce `!llvm.errno.tbaa` for errno alias disambiguation (PR #125258)

@@ -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

[clang] [llvm] [clang][CodeGen][AA] Introduce `!llvm.errno.tbaa` for errno alias disambiguation (PR #125258)

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 ___

[clang] [llvm] [clang][CodeGen][AA] Introduce `!llvm.errno.tbaa` for errno alias disambiguation (PR #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

[clang] [llvm] [clang][CodeGen][AA] Add `!llvm.errno.tbaa` gathering int-compatible TBAA nodes (PR #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

[clang] [llvm] [clang][CodeGen][AA] Add `!llvm.errno.tbaa` gathering int-compatible TBAA nodes (PR #125258)

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 ___

[clang] [Clang][OpenCL][AMDGPU] Allow a kernel to call another kernel (PR #115821)

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

[clang] [Clang] Add `noalias` to `this` pointer in C++ constructors (PR #136792)

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

[clang] [CodeGen] Add TBAA struct path info for array members (PR #137719)

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

[clang] [CodeGen] Add TBAA struct path info for array members (PR #137719)

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

[clang] [CodeGen] Add TBAA struct path info for array members (PR #137719)

@@ -4503,7 +4503,29 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const ArraySubscriptExpr *E, E->getType(), !getLangOpts().PointerOverflowDefined, SignedIndices, E->getExprLoc(), &arrayType, E->getBase()); EltBaseInfo = ArrayLV.getBaseInfo(); -EltT

[clang] [CodeGen] Add TBAA struct path info for array members (PR #137719)

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

[clang] [clang][CGRecordLayout] Remove dependency on isZeroSize (PR #96422)

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

[clang] [CodeGen] Add TBAA struct path info for array members (PR #137719)

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

[clang] clang: Remove dest LangAS argument from performAddrSpaceCast (PR #138866)

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

[clang] [ItaniumMangle] Make sure class types are added to the dictionary of substitution candidates when compiling for older ABIs (PR #138947)

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

[clang] [C] Diagnose use of C++ keywords in C (PR #137234)

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

[clang] [C] Diagnose use of C++ keywords in C (PR #137234)

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

[clang] [C] Diagnose use of C++ keywords in C (PR #137234)

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

[clang] [clang][headers][Apple] Don't include_next float.h to avoid an unnecessary module dependency (PR #137432)

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

[clang] [C] Diagnose use of C++ keywords in C (PR #137234)

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

[clang] [CodeGen] Fix handling of nullptr in initializers (PR #137364)

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

[clang] [CodeGen] Fix handling of nullptr in initializers (PR #137364)

@@ -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

[clang] [CodeGen] Fix handling of nullptr in initializers (PR #137364)

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

[clang] [Clang][CodeGen] Emit fake uses before musttail calls (PR #136867)

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

  1   2   3   4   5   6   7   8   9   10   >