[clang] [Clang] Introduce OverflowBehaviorType for fine-grained overflow control (PR #148914)

@@ -1480,6 +1480,14 @@ class DeclRefExpr final return DeclRefExprBits.IsImmediateEscalating; } + bool isOverflowBehaviorDiscarded() const { efriedma-quic wrote: I guess that makes sense. But the number of bits we have available in Expr is really limi

[clang] [Arm64EC][clang] Implement varargs support in clang. (PR #152411)

https://github.com/efriedma-quic updated https://github.com/llvm/llvm-project/pull/152411 >From 9b8fdaf87ceb1478e5c4a0324de99b5ce375b175 Mon Sep 17 00:00:00 2001 From: Eli Friedman Date: Wed, 6 Aug 2025 16:31:03 -0700 Subject: [PATCH 1/2] [Arm64EC][clang] Implement varargs support in clang. Th

[clang] [Clang] Introduce OverflowBehaviorType for fine-grained overflow control (PR #148914)

@@ -550,6 +550,39 @@ explicit ``overflow_behavior`` attribute. // [-Wimplicit-overflow-behavior-conversion-pedantic] } +Format String Functions +=== + +When overflow behavior types are used with format string functions (printf-famil

[clang] [Clang] Introduce OverflowBehaviorType for fine-grained overflow control (PR #148914)

@@ -12504,6 +12514,14 @@ void Sema::CheckImplicitConversion(Expr *E, QualType T, SourceLocation CC, IntRange TargetRange = IntRange::forTargetOfCanonicalType(Context, Target); if (LikelySourceRange->Width > TargetRange.Width) { +// Check if target is a wrapping OBT -

[clang] [llvm] [clang][SPARC] Pass 16-aligned 16-byte structs as i128 in CC (PR #155829)

@@ -275,10 +276,14 @@ SparcV9ABIInfo::classifyType(QualType Ty, unsigned SizeLimit) const { // Try to use the original type for coercion. llvm::Type *CoerceTy = CB.isUsableType(StrTy) ? StrTy : CB.getType(); + // We use a pair of i64 for 9-16 byte aggregate with 8 byte a

[clang] [llvm] Fix Windows EH IP2State tables (remove +1 bias) (PR #144745)

efriedma-quic wrote: Not every inline asm, only inline asm statements that specifically have an "unwind" clobber (or in Rust, may_unwind). Which is pretty rare, in practice: I've never seen anyone use it in clang, and it isn't even available on stable in Rust. Accurately detecting whether th

[clang] [llvm] [Clang] Add `__builtin_stack_address` (PR #148281)

@@ -0,0 +1,14 @@ +; RUN: llc < %s -mtriple=armv7 | FileCheck %s --check-prefix=armv7 +; RUN: llc < %s -mtriple=aarch64 | FileCheck %s --check-prefix=aarch64 efriedma-quic wrote: You can't put aarch64 testcases in llvm/test/CodeGen/ARM/. They have to be in llvm/

[clang] [llvm] [Clang] Add `__builtin_stack_address` (PR #148281)

@@ -4248,6 +4248,39 @@ assignment can happen automatically. to a variable, have its address taken, or passed into or returned from a function, because doing so violates bounds safety conventions. +.. _builtin_stack_address-doc: + +``__builtin_stack_address`` +-

[clang] [Clang] Introduce OverflowBehaviorType for fine-grained overflow control (PR #148914)

@@ -12504,6 +12514,14 @@ void Sema::CheckImplicitConversion(Expr *E, QualType T, SourceLocation CC, IntRange TargetRange = IntRange::forTargetOfCanonicalType(Context, Target); if (LikelySourceRange->Width > TargetRange.Width) { +// Check if target is a wrapping OBT -

[clang] [Clang] Introduce OverflowBehaviorType for fine-grained overflow control (PR #148914)

@@ -405,6 +405,9 @@ ArgType::matchesType(ASTContext &C, QualType argTy) const { argTy = PT->getPointeeType(); } + if (const auto *OBT = argTy->getAs()) +argTy = OBT->getUnderlyingType(); efriedma-quic wrote: Probably the documentation should mentio

[clang] [Clang] Introduce OverflowBehaviorType for fine-grained overflow control (PR #148914)

@@ -3189,16 +3227,21 @@ ScalarExprEmitter::EmitScalarPrePostIncDec(const UnaryOperator *E, LValue LV, // Note that signed integer inc/dec with width less than int can't // overflow because of promotion rules; we're just eliding a few steps // here. -} els

[clang] [Clang] Introduce OverflowBehaviorType for fine-grained overflow control (PR #148914)

@@ -1480,6 +1480,14 @@ class DeclRefExpr final return DeclRefExprBits.IsImmediateEscalating; } + bool isOverflowBehaviorDiscarded() const { efriedma-quic wrote: Is there some description of what this bit is supposed to mean? As far as I can tell, it

[clang] [Clang] Introduce OverflowBehaviorType for fine-grained overflow control (PR #148914)

@@ -199,6 +233,19 @@ static bool CanElideOverflowCheck(const ASTContext &Ctx, const BinOpInfo &Op) { if (!Op.mayHaveIntegerOverflow()) return true; + const UnaryOperator *UO = dyn_cast(Op.E); + if (UO && Ctx.isUnaryOverflowPatternExcluded(UO)) +return true; + + c

[clang] [llvm] [Clang] Add `__builtin_stack_address` (PR #148281)

@@ -14389,6 +14389,36 @@ Semantics: Note this intrinsic is only verified on AArch64 and ARM. +'``llvm.stackaddress``' Intrinsic +^ + +Syntax: +""" + +:: + + declare ptr @llvm.stackaddress() + +Overview: +" + +The '``llvm.stacka

[clang] [llvm] [Clang] Add `__builtin_stack_address` (PR #148281)

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

[clang] [llvm] [Clang] Add `__builtin_stack_address` (PR #148281)

https://github.com/efriedma-quic commented: The backend code looks like what I expect. Needs a backend regression test for some non-SPARC target. https://github.com/llvm/llvm-project/pull/148281 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [Clang] fix crash in codegen caused by deferred asm diagnostics under -fopenmp (PR #147163)

efriedma-quic wrote: My understanding of deferred diagnostics is that the primary use is to allow including headers that contain inline functions, and don't properly mark device vs. host. So when you parse the function, it's unknown whether the function is actually going to be used, which wou

[clang] [clang] Remove hasValue() check in `RecordExprEvaluator::VisitCXXConstructExpr()` (PR #154610)

@@ -11045,10 +11045,6 @@ bool RecordExprEvaluator::VisitCXXConstructExpr(const CXXConstructExpr *E, bool ZeroInit = E->requiresZeroInitialization(); if (CheckTrivialDefaultConstructor(Info, E->getExprLoc(), FD, ZeroInit)) { -// If we've already performed zero-initiali

[clang] [Clang][CodeGen] Preserve alignment information for pointer arithmetics (PR #152575)

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

[clang] [llvm] [NVPTX] Change the alloca address space in NVPTXLowerAlloca (PR #154814)

https://github.com/efriedma-quic commented: Modifying the datalayout feels really strange, and I'm sort of worried it'll have unintended consequences, especially if there's only one target doing it. Maybe you can just skip modifying the datalayout? The passes that run after createNVPTXLower

[clang] [Clang] Fix incorrect return type for `__builtin_shufflevector` (PR #154817)

https://github.com/efriedma-quic approved this pull request. I expect this doesn't have much effect in most cases; we have a bunch of implicit conversions between vector types, so probably in most cases the vector gets converted to the right type before anyone actually tries to use it. LGTM h

[clang] [llvm] Singleton hack of fixing static initialisation order ficaso (PR #154541)

@@ -30,18 +30,18 @@ constexpr StringRef AssumptionAttrKey = "llvm.assume"; /// A set of known assumption strings that are accepted without warning and /// which can be recommended as typo correction. -LLVM_ABI extern StringSet<> KnownAssumptionStrings; +LLVM_ABI extern StringS

[clang] [llvm] Singleton hack of fixing static initialisation order ficaso (PR #154541)

@@ -160,7 +160,7 @@ inlineCostFeatureToMlFeature(InlineCostFeatureIndex Feature) { return static_cast(static_cast(Feature)); } -LLVM_ABI extern std::vector FeatureMap; +LLVM_ABI extern std::vector &getFeatureMap(); efriedma-quic wrote: ```suggestion LLVM_A

[clang] [clang][CodeGen] add addr space cast if needed when storing ptrs (PR #154380)

@@ -2209,6 +2209,18 @@ void CodeGenFunction::EmitStoreOfScalar(llvm::Value *Value, Address Addr, } } + // When storing a pointer, perform address space cast if needed. efriedma-quic wrote: Yes, that sounds right. https://github.com/llvm/llvm-project/

[clang] [AArch64][Clang] Limit variadic onstack args to 8 bytes on Arm64EC. (PR #154578)

efriedma-quic wrote: Duplicate of #152411? https://github.com/llvm/llvm-project/pull/154578 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][CodeGen] add addr space cast if needed when storing ptrs (PR #154380)

@@ -2209,6 +2209,18 @@ void CodeGenFunction::EmitStoreOfScalar(llvm::Value *Value, Address Addr, } } + // When storing a pointer, perform address space cast if needed. efriedma-quic wrote: Types in IRGen should match types in the AST. So if an lvalue

[clang] [libcxx] Elide suspension points via [[clang::coro_await_suspend_destroy]] (PR #152623)

efriedma-quic wrote: git-clang-format uses the "--lines" option to clang-format restrict formatting updates. If that isn't working correctly, please file a bug. You can ignore the bot after that. https://github.com/llvm/llvm-project/pull/152623 ___

[clang] [llvm] [X86][APX] Remove CF feature from APXF and Diamond Rapids (PR #153751)

efriedma-quic wrote: Oh, right, I guess x86 doesn't ever disable instructions in the assembler... other architectures usually do. There might be other edge cases where things get weird, like, if you do runtime CPU detection. But I don't care enough to argue further. Please at least leave a

[clang] [clang][RISCV] Fix crash on VLS calling convention (PR #145489)

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

[clang] [llvm] [X86][APX] Remove CF feature from APXF and Diamond Rapids (PR #153751)

efriedma-quic wrote: > We usually use Tuningxxx due to hardware defects, which implies some hardware > preform good while some bad. But here the problem is we haven't fully address > regression to make it a net profit for performance. I don't really see a difference between the two: if there's

[clang] Fix Issue where libclang Does Not Include Standard Compiler Specific Headers (PR #153746)

efriedma-quic wrote: If we're going to explicitly add a flag for the resource dir, we should use the flag `-resource-dir`, not try to emulate it with -I. There are other relevant bits in the resource directory, like cfi_ignorelist.txt. We have code in libclang which is supposed to handle this

[clang] [llvm] [X86][APX] Remove CF feature from APXF and Diamond Rapids (PR #153751)

efriedma-quic wrote: "CF" is a hardware feature; it's incredibly confusing to just pretend it doesn't exist because it's slow. If you need to adjust codegen, add a separate feature TuningSlowCF or something. https://github.com/llvm/llvm-project/pull/153751

[clang] [Clang][NFC] Avoid repeating copy of std::string in lambda implementation (PR #153863)

@@ -204,8 +204,9 @@ class FullDependencyConsumer : public DependencyConsumer { std::optional Provided, std::vector Requires) override { ModuleName = Provided ? Provided->ModuleName : ""; -llvm::transform(Requires, std::back_inserter(NamedModuleDeps), -

[clang] [DebugInfo] When referencing structured bindings use the reference's location, not the binding's declaration's location (PR #153637)

efriedma-quic wrote: Really, the AST design is weird: we're not supposed to do any computation when you reference parts of the binding. We represent it as an expression just to reduce the code required to handle bindings. As such, the set of expressions actually allowed in a binding are quit

[clang] [win][arm64ec] XFAIL x64 intrinsic tests on Arm64EC (PR #153474)

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

[clang] [AArch64][FMV] Enable PAuth and BTI hardening of resolver functions (PR #141573)

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

[clang] [AArch64][FMV] Enable PAuth and BTI hardening of resolver functions (PR #141573)

@@ -4652,6 +4659,7 @@ llvm::Constant *CodeGenModule::GetOrCreateMultiVersionResolver(GlobalDecl GD) { "", Resolver, &getModule()); GIF->setName(ResolverName); SetCommonAttributes(FD, GIF); +SetResolverAttrs(cast(Resolver)); ---

[clang] [clang][WebAssembly] Handle casted function pointers with different number of arguments (PR #153168)

https://github.com/efriedma-quic commented: Really, I think the biggest problem with this approach is that it special-cases compile-time casts, and treats them differently from runtime casts. That might be just barely sufficient for specific cases from glib, but it's not comprehensive, and it

[clang] [clang] Add an ABI_EXTENSION concept that is testable under -pedantic… (PR #153506)

https://github.com/efriedma-quic commented: I'm fine with this for the branch, sure. https://github.com/llvm/llvm-project/pull/153506 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][PAC] ptrauth_qualifier must be considered a feature (PR #153291)

efriedma-quic wrote: Can we just drop the check from `__has_extension` handling? It looks like that check dates back to the introduction of __has_extension (d5d410faa8cfbbf4e2ffc2f8aa470491a77fd843). But it's a terrible idea for a lot of reasons: it adds a semantic effect to a flag which othe

[clang] [clang][PAC] ptrauth_qualifier must be considered a feature (PR #153291)

efriedma-quic wrote: > No, ptrauth is not a feature, it is an extension and should be reported as > such. The real bug here is that you're missing an extension warning when > `__ptrauth` is used I thought our general policy was that we don't trigger pedantic warnings for reserved keywords (li

[clang] [WIP] [clang] Align cleanup structs to prevent SIGBUS on sparc32 (PR #152866)

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

[clang] [Arm64EC][clang] Implement varargs support in clang. (PR #152411)

@@ -132,6 +132,10 @@ class ABIInfo { virtual llvm::FixedVectorType * getOptimalVectorMemoryType(llvm::FixedVectorType *T, const LangOptions &Opt) const; + + /// Used by Arm64EC calling convention code to call into x86 calling + /// convention

[clang] [Arm64EC][clang] Implement varargs support in clang. (PR #152411)

@@ -1409,6 +1409,12 @@ class WinX86_64ABIInfo : public ABIInfo { return isX86VectorCallAggregateSmallEnough(NumMembers); } + ABIArgInfo classifyArgForArm64ECVarArg(QualType Ty) const override { efriedma-quic wrote: classifyArgForArm64ECVarArg is exclus

[clang] [clang] Followup for constexpr-unknown potential constant expressions. (PR #151053)

@@ -563,8 +563,11 @@ bool Pointer::hasSameBase(const Pointer &A, const Pointer &B) { if (A.isTypeidPointer() && B.isTypeidPointer()) return true; - if (A.isIntegralPointer() || B.isIntegralPointer()) + if (A.isIntegralPointer() || B.isIntegralPointer()) { +if (A.i

[clang] [clang] Followup for constexpr-unknown potential constant expressions. (PR #151053)

https://github.com/efriedma-quic updated https://github.com/llvm/llvm-project/pull/151053 >From 43e441c0559294f0e4d85cf67bea480140b2e9d1 Mon Sep 17 00:00:00 2001 From: Eli Friedman Date: Mon, 28 Jul 2025 15:47:33 -0700 Subject: [PATCH 1/2] [clang] Followup for constexpr-unknown potential consta

[clang] [llvm] Trying to fix undefined symbol error caused by iterator variable (PR #141507)

efriedma-quic wrote: Still waiting for an answer: > The reason I'm suspicious of the getDeclareMapperVarRef check is that > SemaOpenMP::ActOnOMPIteratorExpr creates the variable (VarDecl::Create) > regardless. So what's supposed to happen for variables where > getDeclareMapperVarRef is false?

[clang] [Clang] Add template argument support for {con,de}structor attributes. (PR #151400)

@@ -6324,10 +6324,20 @@ void CodeGenModule::EmitGlobalFunctionDefinition(GlobalDecl GD, SetLLVMFunctionAttributesForDefinition(D, Fn); + auto getPriority = [this](auto *Attr) -> int { +int priority = Attr->DefaultPriority; +Expr *E = Attr->getPriority(); +if (

[clang] [Clang][CodeGen] Preserve alignment information for pointer arithmetics (PR #152575)

@@ -4184,29 +4184,14 @@ Value *ScalarExprEmitter::EmitOverflowCheckedBinOp(const BinOpInfo &Ops) { } /// Emit pointer + index arithmetic. -static Value *emitPointerArithmetic(CodeGenFunction &CGF, -const BinOpInfo &op, -

[clang] [Clang][CodeGen] Preserve alignment information for pointer arithmetics (PR #152575)

@@ -1381,6 +1432,13 @@ static Address EmitPointerWithAlignment(const Expr *E, LValueBaseInfo *BaseInfo, if (CE->getCastKind() == CK_AddressSpaceConversion) Addr = CGF.Builder.CreateAddrSpaceCast( Addr, CGF.ConvertType(E->getType()), ElemTy); +

[clang] [Clang][CodeGen] Preserve alignment information for pointer arithmetics (PR #152575)

@@ -4309,16 +4292,39 @@ static Value *emitPointerArithmetic(CodeGenFunction &CGF, // future proof. llvm::Type *elemTy; if (elementType->isVoidType() || elementType->isFunctionType()) -elemTy = CGF.Int8Ty; +elemTy = Int8Ty; else -elemTy = CGF.ConvertTypeFor

[clang] [flang] [llvm] [IR] Remove size argument from lifetime intrinsics (PR #150248)

https://github.com/efriedma-quic approved this pull request. LGTM, assuming there aren't any non-trivial changes to the regression tests. (I looked at the code changes, but I skimmed the test changes.) https://github.com/llvm/llvm-project/pull/150248 ___

[clang] [Arm64EC][clang] Implement varargs support in clang. (PR #152411)

https://github.com/efriedma-quic created https://github.com/llvm/llvm-project/pull/152411 The clang side of the calling convention code for arm64 vs. arm64ec is close enough that this isn't really noticeable in most cases, but the rule for choosing whether to pass a struct directly or indirect

[clang] [clang] Followup for constexpr-unknown potential constant expressions. (PR #151053)

efriedma-quic wrote: Ping https://github.com/llvm/llvm-project/pull/151053 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Fix crash in dynamic_cast final class optimization (PR #152076)

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

[clang] [clang] Fix crash in dynamic_cast final class optimization (PR #152076)

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

[clang] [clang] Fix crash in dynamic_cast final class optimization (PR #152076)

https://github.com/efriedma-quic commented: I think I'd prefer to split the pointer authentication changes into a separate patch; I'm not sure I'm comfortable reviewing that bit. Other changes look fine. https://github.com/llvm/llvm-project/pull/152076 _

[clang] [clang] Fix crash in dynamic_cast final class optimization (PR #152076)

@@ -2294,6 +2294,18 @@ llvm::Value *CodeGenFunction::EmitDynamicCast(Address ThisAddr, DestRecordTy->getAsCXXRecordDecl()->isEffectivelyFinal() && CGM.getCXXABI().shouldEmitExactDynamicCast(DestRecordTy); + std::optional ExactCastInfo; + if

[clang] [clang] Fix crash in dynamic_cast final class optimization (PR #152076)

@@ -1722,41 +1728,95 @@ llvm::Value *ItaniumCXXABI::emitExactDynamicCast( if (!Offset) Offset = PathOffset; else if (Offset != PathOffset) { - // Base appears in at least two different places. Find the most-derived - // object and see if it's a DestDecl.

[clang] [clang] Introduce elementwise ctlz/cttz builtins (PR #131995)

efriedma-quic wrote: > > We don't currently have a definition of what it means to "use" a value in a > > way that would cause undefined behavior with poison. > > Which means stating it produces undefined behavior less accurate? We have to document semantics that describe the behavior with all

[clang] Fix missing clang changes for #151983 (PR #152066)

https://github.com/efriedma-quic commented: LGTM, thanks https://github.com/llvm/llvm-project/pull/152066 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Respect [[gnu::error]] on functions passed to [[gnu::cleanup]] (PR #152082)

@@ -624,8 +624,15 @@ namespace { CallArgList Args; Args.add(RValue::get(Arg), CGF.getContext().getPointerType(Var.getType())); - auto Callee = CGCallee::forDirect(CleanupFn); - CGF.EmitCall(FnInfo, Callee, ReturnValueSlot(), Args); + bo

[clang] [clang] Introduce elementwise ctlz/cttz builtins (PR #131995)

efriedma-quic wrote: > That's not what I'm requesting, it would be an undefined value. It is not > instant undefined behavior, you would get UB on use of that value You're creating a lot of work by insisting on this. We don't currently have a definition of what it means to "use" a value in a w

[clang] [clang][ARM] Fix build failure in for __swp (PR #151354)

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

[clang] [llvm] Trying to fix undefined symbol error caused by iterator variable (PR #141507)

https://github.com/efriedma-quic commented: The reason I'm suspicious of the getDeclareMapperVarRef check is that SemaOpenMP::ActOnOMPIteratorExpr creates the variable (VarDecl::Create) regardless. So what's supposed to happen for variables where getDeclareMapperVarRef is false? In

[clang] [clang] Check constexpr int->enum conversions consistently. (PR #143034)

efriedma-quic wrote: @tstellar Yes, the error message there looks correct. The simplest fix for most code is to use a fixed-width enum (`enum : int { kUnknown = 3, kMaxValue = kUnknown };`). gcc doesn't currently diagnose such conversions. https://github.com/llvm/llvm-project/pull/143034 ___

[clang] [llvm] Implement `preserve_none` for 32-bit x86 (PR #150106)

efriedma-quic wrote: If you can write a testcase that shows we properly spill the base pointer when necessary, fine. (I didn't realize there was already code to deal with this sort of thing.) https://github.com/llvm/llvm-project/pull/150106 ___ cfe-

[clang] [clang][ARM] Fix setting of MaxAtomicInlineWidth. (PR #151404)

https://github.com/efriedma-quic closed https://github.com/llvm/llvm-project/pull/151404 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][ARM] Fix setting of MaxAtomicInlineWidth. (PR #151404)

@@ -133,19 +133,24 @@ void ARMTargetInfo::setArchInfo(llvm::ARM::ArchKind Kind) { } void ARMTargetInfo::setAtomic() { - // when triple does not specify a sub arch, - // then we are not using inline atomics - bool ShouldUseInlineAtomic = - (ArchISA == llvm::ARM::ISAKin

[clang] [llvm] Trying to fix undefined symbol error caused by iterator variable (PR #141507)

https://github.com/efriedma-quic commented: This looks basically right. But I'm not sure all the conditions for calling it are correct. Is getDeclareMapperVarRef relevant? Does it matter what scope we're inserting the variable into? (Can the variable be inserted in a namespace? Can it be a

[clang] [clang][ARM] Fix build failure in for __swp (PR #151354)

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

[clang] [clang][ARM] Fix build failure in for __swp (PR #151354)

@@ -55,11 +55,27 @@ __chkfeat(uint64_t __features) { /* 7.5 Swap */ static __inline__ uint32_t __attribute__((__always_inline__, __nodebug__)) __swp(uint32_t __x, volatile uint32_t *__p) { efriedma-quic wrote: "relaxed" basically means we don't emit any barrie

[clang] [clang] Introduce elementwise clz/ctz builtins (PR #131995)

efriedma-quic wrote: > Oh excuse me, there's currently no target-specific behaviour. I missed the > HasFallback in HasFallback only applies to the two-argument form. I don't have a strong opinion about the names. The whole "fallback behavior" thing was written back in the early

[clang] [clang][RISCV] Fix clang dwarf info generation for unprtototyped function (PR #150022)

efriedma-quic wrote: Having checks for different optimization levels and DWARF versions is probably fine... but a lot of those checks overlap with clang/test/CodeGenCXX/dbg-info-all-calls-described.cpp . Explicitly checking RV32 vs RV64 seems unproductive; this code isn't target-specific. ht

[clang] [clang][RISCV] Fix clang dwarf info generation for unprtototyped function (PR #150022)

https://github.com/efriedma-quic commented: The code change looks fine. Are the tests just checking that there's `!dbg` metadata attached to the function declarations? Do you really need 12 RUN lines to check that? https://github.com/llvm/llvm-project/pull/150022 _

[clang] [clang] Followup for constexpr-unknown potential constant expressions. (PR #151053)

https://github.com/efriedma-quic created https://github.com/llvm/llvm-project/pull/151053 6a60f18997d62b0e2842a921fcb6beb3e52ed823 fixed the primary issue of dereferences, but there are some expressions that depend on the identity of the pointed-to object without actually accessing it. Handle

[clang] [clang] Fix potential constant expression checking with constexpr-unknown. (PR #149227)

efriedma-quic wrote: And a few more: ``` constexpr auto& type(const PolyBase& b) { return typeid(b); } // dynamic_cast constexpr const void* dyncast(const PolyBase& b) { return dynamic_cast(&b); } constexpr int sub(int (&a)[], int (&b)[]) { return a-b; } constexpr int* add(int &a) { return &a

[clang] [clang][RISCV] Fix clang dwarf info generation for unprtototyped function (PR #150022)

efriedma-quic wrote: So according to the standard, unprototyped function calls are not variadic: if you try to call a variadic function using an unprototyped function, the behavior is formally undefined. On some targets, for some function signatures, it might appear to work. On x86 specifica

[clang] [clang] Forbid reinterpret_cast of function pointers in constexpr. (PR #150557)

@@ -3,8 +3,8 @@ // RUN: %clang_cc1 -x c -fsyntax-only %s -verify=c -std=c11 -fexperimental-new-constant-interpreter // RUN: %clang_cc1 -x c -fsyntax-only %s -pedantic -verify=c-pedantic -std=c11 -fexperimental-new-constant-interpreter // -// RUN: %clang_cc1 -x c++ -fsyntax-on

[clang] [llvm] Trying to fix undefined symbol error caused by iterator variable (PR #141507)

efriedma-quic wrote: > The reproducer is passing with clang. See https://godbolt.org/z/adnjMndGq The testcase is using -femit-all-decls. I assumed that was just to avoid including some irrelevant bits in the testcase. I guess there could be some interaction with -femit-all-decls specifically

[clang] [clang] Forbid reinterpret_cast of function pointers in constexpr. (PR #150557)

https://github.com/efriedma-quic updated https://github.com/llvm/llvm-project/pull/150557 >From f111a98680ba2301ee93a45a3c30630c71925562 Mon Sep 17 00:00:00 2001 From: Eli Friedman Date: Thu, 24 Jul 2025 17:22:27 -0700 Subject: [PATCH 1/3] [clang] Forbid reinterpret_cast of function pointers in

[clang] [clang] Forbid reinterpret_cast of function pointers in constexpr. (PR #150557)

@@ -3,8 +3,8 @@ // RUN: %clang_cc1 -x c -fsyntax-only %s -verify=c -std=c11 -fexperimental-new-constant-interpreter // RUN: %clang_cc1 -x c -fsyntax-only %s -pedantic -verify=c-pedantic -std=c11 -fexperimental-new-constant-interpreter // -// RUN: %clang_cc1 -x c++ -fsyntax-on

[clang] [clang] Forbid reinterpret_cast of function pointers in constexpr. (PR #150557)

https://github.com/efriedma-quic updated https://github.com/llvm/llvm-project/pull/150557 >From f111a98680ba2301ee93a45a3c30630c71925562 Mon Sep 17 00:00:00 2001 From: Eli Friedman Date: Thu, 24 Jul 2025 17:22:27 -0700 Subject: [PATCH 1/2] [clang] Forbid reinterpret_cast of function pointers in

[clang] [clang][ExprConst] Consider integer pointers of value 0 nullptr (PR #150164)

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

[clang] [flang] [llvm] [IR] Remove size argument from lifetime intrinsics (PR #150248)

efriedma-quic wrote: Probably should release note, yes. Also, can we try to land some of the changes separately? I mean, some things can't land separately, or it would be a pain in the neck to land them separately because of test changes, but we can at least merge the SelectionDAG bits and t

[clang] [llvm] Implement `preserve_none` for 32-bit x86 (PR #150106)

https://github.com/efriedma-quic commented: LGTM, but I'd like a second set of eyes on this. https://github.com/llvm/llvm-project/pull/150106 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-co

[clang] [llvm] Fixes to unblock building LLVM and Clang as Arm64EC (PR #150068)

https://github.com/efriedma-quic approved this pull request. Not sure if we want to wait on the upstream review in google/benchmark? Otherwise LGTM. https://github.com/llvm/llvm-project/pull/150068 ___ cfe-commits mailing list cfe-commits@lists.llvm.

[clang] clang: Handle deleting pointers to incomplete array types (PR #150359)

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

[clang] [clang] Fix const eval of constexpr-unknown relational comparisons. (PR #150088)

https://github.com/efriedma-quic updated https://github.com/llvm/llvm-project/pull/150088 >From 51b5621d471142437641740b97eda2a24c7af82e Mon Sep 17 00:00:00 2001 From: Eli Friedman Date: Tue, 22 Jul 2025 12:09:28 -0700 Subject: [PATCH 1/3] [clang] Fix const eval of constexpr-unknown relational

[clang] clang: Handle deleting pointers to incomplete array types (PR #150359)

@@ -76,27 +76,45 @@ namespace test1 { ~A(); }; - // CHECK-LABEL: define{{.*}} void @_ZN5test14testEPA10_A20_NS_1AE( - void test(A (*arr)[10][20]) { + // CHECK-LABEL: define{{.*}} void @_ZN5test11fEPA10_A20_NS_1AE( + void f(A (*arr)[10][20]) { delete [] arr;

[clang] clang: Handle deleting pointers to incomplete array types (PR #150359)

@@ -2146,30 +2146,12 @@ void CodeGenFunction::EmitCXXDeleteExpr(const CXXDeleteExpr *E) { return; } - // We might be deleting a pointer to array. If so, GEP down to the - // first non-array element. - // (this assumes that A(*)[3][7] is converted to [3 x [7 x %A]]*)

[clang] [llvm] Implement `preserve_none` for 32-bit x86 (PR #150106)

efriedma-quic wrote: > Okay, this is just adding them to the existing CSR_*_NoneRegs, correct? Yes. > Makes sense. Where do you think the best place to do this is? I think similar sorts of diagnostics are in llvm/lib/Target/X86/X86ISelLoweringCall.cpp . (Grep for errorUnsupported.) > How ab

[clang] [llvm] Implement `preserve_none` for 32-bit x86 (PR #150106)

efriedma-quic wrote: For "nest", we can forbid combining it with the preserves_none calling convention, probably, as long as we can detect it and error out. There's no reason anyone would combine the two. For the base pointer, you also need to worry about the callee-save register list: I don

[clang] [clang][ExprConst] Consider integer pointers of value 0 nullptr (PR #150164)

@@ -27,12 +27,6 @@ template void f(); // CHECK: define weak_odr void @_Z1fIXtl1BLPKi32vv( // MSABI: define {{.*}} @"??$f@$2UB@@PEBH0CA@H0AYAXXZ" template void f(); -#ifndef _WIN32 efriedma-quic wrote: This specific test is fine, I think: if we know the

[clang] [llvm] Trying to fix undefined symbol error caused by iterator variable (PR #141507)

https://github.com/efriedma-quic commented: That's maybe better? I spent a little time looking at the testcase, and I saw something weird in the AST: there's a VarDecl at the top level, but it never gets sent down the normal path for top-level decls. I suspect there's a missing call to Handle

[clang] One more fix for P3144R2 implementation (PR #149406)

@@ -595,6 +595,10 @@ struct GH99278_2 { } f; }; GH99278_2 e; +void GH99278_3(int(*p)[]) { + delete p; + // expected-warning@-1 {{'delete' applied to a pointer-to-array type 'int (*)[]' treated as 'delete[]'}} +}; efriedma-quic wrote: Maybe also test delet

[clang] [clang] Introduce elementwise clz/ctz builtins (PR #131995)

@@ -847,6 +848,14 @@ of different sizes and signs is forbidden in binary and ternary builtins. semantics, see `LangRef

[clang] [clang] Introduce elementwise clz/ctz builtins (PR #131995)

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

[clang] [clang] Fix potential constant expression checking with constexpr-unknown. (PR #149227)

efriedma-quic wrote: /cherry-pick 6a60f18997d62b0e2842a921fcb6beb3e52ed823 https://github.com/llvm/llvm-project/pull/149227 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Fix potential constant expression checking with constexpr-unknown. (PR #149227)

https://github.com/efriedma-quic closed https://github.com/llvm/llvm-project/pull/149227 ___ 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   >