[clang] [X86_64] fix arg pass error in struct. (PR #85394)

efriedma-quic wrote: gcc uses memory, and the ABI standard doesn't explicitly contradict it, so let's just go with that. https://github.com/llvm/llvm-project/pull/85394 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [llvm] [CodeGen][LLVM] Make the `va_list` related intrinsics generic. (PR #85460)

@@ -700,10 +700,13 @@ class MSBuiltin { //===--- Variable Argument Handling Intrinsics ===// // -def int_vastart : DefaultAttrsIntrinsic<[], [llvm_ptr_ty], [], "llvm.va_start">; -def int_vacopy : DefaultAttrsIntrinsic<[], [llvm_ptr_ty,

[clang] [Clang][Sema]: Allow flexible arrays in unions and alone in structs (PR #84428)

efriedma-quic wrote: > because we don't yet support non-zero initialization (as described in commit > [5955a0f](https://github.com/llvm/llvm-project/commit/5955a0f9375a8c0b134eeb4a8de5155dcce7c94f)) I'm confused. We support non-zero init, and there are tests for non-zero init in that commit.

[clang] [X86_64] fix empty structure vaarg in c++ (PR #77907)

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

[clang] [Clang][Sema]: Allow flexible arrays in unions and alone in structs (PR #84428)

efriedma-quic wrote: The code in question is comparing what Sema thinks the size of a variable should be, versus the size of the variable we're actually emitting into LLVM IR. So try dumping the value of "Init". If it looks wrong, we need to fix constant emission. If it's right, probably

[clang] [clang][CodeGen] Allow memcpy replace with trivial auto var init (PR #84230)

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

[clang] [clang] Implement __builtin_{clzg,ctzg} (PR #83431)

https://github.com/efriedma-quic approved this pull request. LGTM with one minor comment https://github.com/llvm/llvm-project/pull/83431 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [clang] Implement __builtin_{clzg,ctzg} (PR #83431)

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

[clang] [clang] Implement __builtin_{clzg,ctzg} (PR #83431)

@@ -3504,6 +3504,47 @@ argument can be of any unsigned integer type. ``__builtin_popcount{,l,ll}`` builtins, with support for other integer types, such as ``unsigned __int128`` and C23 ``unsigned _BitInt(N)``. +``__builtin_clzg`` and ``__builtin_ctzg``

[clang] [X86_64] fix arg pass error in struct. (PR #85394)

efriedma-quic wrote: I think the logic the code is using is that t67 is actually properly aligned: it's a type with size 8 and alignment 4, so everything is fine. If that's not right, we should tweak the relevant logic (around line 2104). Specifically checking whether a type crosses an

[clang] [X86_64] fix empty structure vaarg in c++ (PR #77907)

@@ -0,0 +1,13 @@ +// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm -o - %s | FileCheck %s +// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm -x c -o - %s | FileCheck %s + +typedef struct { struct {} a; } empty; + +// CHECK-LABEL: define{{.*}} void

[clang] [X86_64] fix empty structure vaarg in c++ (PR #77907)

https://github.com/efriedma-quic commented: Code change looks fine; the regression test needs a few tweaks. https://github.com/llvm/llvm-project/pull/77907 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [X86_64] fix empty structure vaarg in c++ (PR #77907)

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

[clang] [Clang][Sema]: Allow flexible arrays in unions and alone in structs (PR #84428)

@@ -1,13 +1,158 @@ -// RUN: %clang_cc1 %s -verify=c -fsyntax-only -// RUN: %clang_cc1 %s -verify -fsyntax-only -x c++ -// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility -// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility -x c++ +// RUN: %clang_cc1 %s

[clang] [Clang][Sema]: Allow flexible arrays in unions and alone in structs (PR #84428)

@@ -1,13 +1,158 @@ -// RUN: %clang_cc1 %s -verify=c -fsyntax-only -// RUN: %clang_cc1 %s -verify -fsyntax-only -x c++ -// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility -// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility -x c++ +// RUN: %clang_cc1 %s

[clang] [Clang][Sema]: Allow flexible arrays in unions and alone in structs (PR #84428)

@@ -1,13 +1,158 @@ -// RUN: %clang_cc1 %s -verify=c -fsyntax-only -// RUN: %clang_cc1 %s -verify -fsyntax-only -x c++ -// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility -// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility -x c++ +// RUN: %clang_cc1 %s

[clang] [Clang][Sema]: Allow flexible arrays in unions and alone in structs (PR #84428)

@@ -1,13 +1,158 @@ -// RUN: %clang_cc1 %s -verify=c -fsyntax-only -// RUN: %clang_cc1 %s -verify -fsyntax-only -x c++ -// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility -// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility -x c++ +// RUN: %clang_cc1 %s

[clang] [Clang][Sema]: Allow flexible arrays in unions and alone in structs (PR #84428)

efriedma-quic wrote: The primary problem with allowing flexible arrays alone in structs/unions is that you end up with a zero-size type. This leads to weird semantic issues because standard C/C++ doesn't have any provision for zero-size types: pointer arithmetic, struct layout, and

[clang] [clang][AArch64] Enable fp128 for aarch64 linux target (PR #85070)

efriedma-quic wrote: See also #80195 (CC @nickdesaulniers). gcc on aarch64 Linux only supports _Float128, not __float128; this seems like a bit of a compatibility hazard. https://github.com/llvm/llvm-project/pull/85070 ___ cfe-commits mailing list

[clang] [llvm] [SpecialCaseList] Use glob by default (PR #74809)

efriedma-quic wrote: CC @llvm/clang-vendors > I [announced this change on > discourse](https://discourse.llvm.org/t/use-glob-instead-of-regex-for-specialcaselists/71666?u=ellishg) > last year. "Use glob instead of regex for SpecialCaseLists" doesn't mean anything for anyone not actively

[clang] [llvm] [SpecialCaseList] Use glob by default (PR #74809)

efriedma-quic wrote: A report from the field: we had an ignorelist that contained `[cfi-vcall|cfi-nvcall|cfi-icall]`. This was recommended syntax from the documentation (https://releases.llvm.org/17.0.1/tools/clang/docs/SanitizerSpecialCaseList.html)... but it broke with the transition.

[clang] [compiler-rt] [clang][UBSan] Add implicit conversion check for bitfields (PR #75481)

@@ -0,0 +1,61 @@ +// RUN: %clang -fsanitize=implicit-bitfield-conversion -target x86_64-linux -S -emit-llvm -o - %s | FileCheck %s --check-prefixes=CHECK,CHECK-BITFIELD-CONVERSION efriedma-quic wrote: I'd like to see some testcases that run in C++ mode.

[clang] [compiler-rt] [clang][UBSan] Add implicit conversion check for bitfields (PR #75481)

@@ -147,6 +147,7 @@ struct ImplicitConversionData { const TypeDescriptor const TypeDescriptor /* ImplicitConversionCheckKind */ unsigned char Kind; + unsigned int BitfieldBits; efriedma-quic wrote: Do we have an ABI stability policy for UBsan? Is

[clang] [llvm] [RISC-V] Add CSR read/write builtins (PR #85091)

@@ -20,6 +20,12 @@ class RISCVBuiltin : TargetBuiltin { let Attributes = [NoThrow, Const] in { //===--===// +// Zicsr extension.

[clang] [Clang] [CodeGen] Fix codegen bug in constant initialisation in C23 mode (PR #84981)

@@ -259,6 +259,10 @@ Bug Fixes in This Version operator. Fixes (#GH83267). +- Clang no longer fails to codegen static ``const`` variables whose initialiser performs + a floating-point division by 0 in C23. + Fixes (#GH84784). efriedma-quic wrote: We

[clang] [llvm] [Clang][BPF] Allow sign/zero extension for call parameters with int/uint types (PR #84874)

efriedma-quic wrote: > My understanding is that you refer to the following part of the > [specification](https://riscv.org/wp-content/uploads/2015/01/riscv-calling.pdf): Yes. For example, on RISC-V, the function `long f(unsigned g) { return (int)g; }` compiles to just a "ret". > clang would

[clang] [llvm] [Clang][BPF] Allow sign/zero extension for call parameters with int/uint types (PR #84874)

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

[clang] [llvm] [Clang][BPF] Allow sign/zero extension for call parameters with int/uint types (PR #84874)

https://github.com/efriedma-quic commented: Oh, this is making a bit more sense now... I didn't realize this was overriding method that handles char/short already. And I guess for BPF targets, you can assume "long" is 64 bits. That said, this isn't handling "unsigned int" correctly.

[clang] [HLSL] Implement array temporary support (PR #79382)

@@ -3173,41 +3174,46 @@ class ArrayType : public Type, public llvm::FoldingSetNode { return T->getTypeClass() == ConstantArray || T->getTypeClass() == VariableArray || T->getTypeClass() == IncompleteArray || - T->getTypeClass() ==

[clang] [HLSL] Implement array temporary support (PR #79382)

@@ -2231,7 +2231,8 @@ Value *ScalarExprEmitter::VisitCastExpr(CastExpr *CE) { case CK_UserDefinedConversion: return Visit(const_cast(E)); - case CK_NoOp: { + case CK_NoOp: + case CK_HLSLArrayRValue: { efriedma-quic wrote: It shouldn't be possible to

[clang] [HLSL] Implement array temporary support (PR #79382)

@@ -500,6 +500,7 @@ ComplexPairTy ComplexExprEmitter::EmitCast(CastKind CK, Expr *Op, case CK_NoOp: case CK_LValueToRValue: case CK_UserDefinedConversion: + case CK_HLSLArrayRValue: efriedma-quic wrote: The result of an CK_HLSLArrayRValue can't be a

[clang] [HLSL] Implement array temporary support (PR #79382)

@@ -1442,6 +1445,7 @@ static bool castPreservesZero(const CastExpr *CE) { case CK_BitCast: case CK_ToUnion: case CK_ToVoid: + case CK_HLSLArrayRValue: efriedma-quic wrote: Probably should be false, like other lvalue-to-rvalue casts?

[clang] [HLSL] Implement array temporary support (PR #79382)

https://github.com/efriedma-quic commented: This seems like the right direction. https://github.com/llvm/llvm-project/pull/79382 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL] Implement array temporary support (PR #79382)

@@ -10900,6 +10936,10 @@ QualType ASTContext::mergeTypes(QualType LHS, QualType RHS, bool OfBlockPointer, assert(LHS != RHS && "Equivalent pipe types should have already been handled!"); return {}; + case Type::ArrayParameter: +if (RHS != LHS)

[clang] [HLSL] Implement array temporary support (PR #79382)

@@ -1126,6 +1126,7 @@ class ConstExprEmitter : case CK_NonAtomicToAtomic: case CK_NoOp: case CK_ConstructorConversion: +case CK_HLSLArrayRValue: efriedma-quic wrote: We shouldn't accept CK_HLSLArrayRValue casts here (or if we do, we need to do

[clang] [HLSL] Implement array temporary support (PR #79382)

@@ -4655,6 +4655,13 @@ void CodeGenFunction::EmitCallArg(CallArgList , const Expr *E, return emitWritebackArg(*this, args, CRE); } + // If an argument is an array paramter expression being passed through. Emit + // the argument to a temporary and pass the temporary

[clang] [HLSL] Implement array temporary support (PR #79382)

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

[clang] [compiler-rt] [clang][UBSan] Add implicit conversion check for bitfields (PR #75481)

@@ -5571,11 +5571,52 @@ LValue CodeGenFunction::EmitBinaryOperatorLValue(const BinaryOperator *E) { break; } -RValue RV = EmitAnyExpr(E->getRHS()); +llvm::Value *Previous = nullptr; efriedma-quic wrote: Sure, if you want to leave the

[clang] [llvm] [Clang][BPF] Allow sign extension for int type call parameters (PR #84874)

efriedma-quic wrote: The way LLVM backend works in general is that if an integer is smaller than a register, when type legalization converts that to a larger integer, the high bits are undefined. This generally doesn't cause any issues because nothing can actually observe those bits. Your

[clang] [compiler-rt] [clang][UBSan] Add implicit conversion check for bitfields (PR #75481)

@@ -5571,11 +5571,52 @@ LValue CodeGenFunction::EmitBinaryOperatorLValue(const BinaryOperator *E) { break; } -RValue RV = EmitAnyExpr(E->getRHS()); +llvm::Value *Previous = nullptr; efriedma-quic wrote: Can we de-duplicate this code with

[clang] [compiler-rt] [clang][UBSan] Add implicit conversion check for bitfields (PR #75481)

https://github.com/efriedma-quic commented: I'm a bit concerned about the lack of C++ testcases, since you're making changes to some C++-only codepaths. https://github.com/llvm/llvm-project/pull/75481 ___ cfe-commits mailing list

[clang] [compiler-rt] [clang][UBSan] Add implicit conversion check for bitfields (PR #75481)

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

[clang] [clang][CodeGen] Allow memcpy replace with trivial auto var init (PR #84230)

https://github.com/efriedma-quic commented: This is clearly not what we want long-term. Either clang or LLVM should have better heuristics based on the actual values being stored; the syntax used at the C level shouldn't affect codegen. That said, reverting the change with a carveout for the

[clang] [TBAA] Generate tbaa.struct single field with char tag for unions. (PR #84370)

efriedma-quic wrote: This seems fine. In some cases, we could maybe prove certain bytes are padding regardless of the current representation, but probably not worth the effort to implement. https://github.com/llvm/llvm-project/pull/84370 ___

[clang] [X86_64] fix empty structure vaarg in c++ (PR #77907)

@@ -3014,6 +3014,16 @@ Address X86_64ABIInfo::EmitVAArg(CodeGenFunction , Address VAListAddr, ABIArgInfo AI = classifyArgumentType(Ty, 0, neededInt, neededSSE, /*isNamedArg*/false); + // Empty records are ignored for parameter

[clang] [X86_64] fix empty structure vaarg in c++ (PR #77907)

@@ -3014,6 +3014,16 @@ Address X86_64ABIInfo::EmitVAArg(CodeGenFunction , Address VAListAddr, ABIArgInfo AI = classifyArgumentType(Ty, 0, neededInt, neededSSE, /*isNamedArg*/false); + // Empty records are ignored for parameter

[clang] [clang] Better bitfield access units (PR #65742)

@@ -394,33 +412,155 @@ void CGRecordLowering::accumulateFields() { : getStorageType(*Field), *Field)); ++Field; -} else { - ++Field; } } } -void -CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field, -

[clang] [clang] Implement __builtin_{clzg,ctzg} (PR #83431)

@@ -3157,7 +3177,15 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl GD, unsigned BuiltinID, if (Result->getType() != ResultType) efriedma-quic wrote: I was more thinking of the opposite: we don't need to make the result of the clz defined if

[clang] [clang] Implement __builtin_{clzg,ctzg} (PR #83431)

@@ -3157,7 +3177,15 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl GD, unsigned BuiltinID, if (Result->getType() != ResultType) efriedma-quic wrote: Not sure if the way this is handling isCLZForZeroUndef() is what you want?

[clang] [clang] Implement __builtin_{clzg,ctzg} (PR #83431)

@@ -2212,6 +2212,54 @@ static bool SemaBuiltinPopcountg(Sema , CallExpr *TheCall) { return false; } +/// Checks that __builtin_{clzg,ctzg} was called with a first argument, which is +/// an unsigned integer, and an optional second argument, which is promoted to +/// an

[clang] [clang] Implement __builtin_{clzg,ctzg} (PR #83431)

@@ -662,6 +662,12 @@ def Clz : Builtin, BitShort_Int_Long_LongLongTemplate { // FIXME: Add int clzimax(uintmax_t) efriedma-quic wrote: Probably; it's unlikely we're going to add them at this point. https://github.com/llvm/llvm-project/pull/83431

[clang] [clang] Fix __builtin_popcountg not matching GCC (PR #83313)

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

[clang] [clang] Fix __builtin_popcountg not matching GCC (PR #83313)

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

[clang] [TBAA] Handle bitfields when generating !tbaa.struct metadata. (PR #82922)

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

[clang] [TBAA] Handle bitfields when generating !tbaa.struct metadata. (PR #82922)

https://github.com/efriedma-quic commented: Whitespace is weird in a few places; otherwise looks fine. https://github.com/llvm/llvm-project/pull/82922 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [clang] Implement __builtin_popcountg (PR #82359)

efriedma-quic wrote: Oh, I should have caught that when reviewing. (I thought I checked the test was doing the right thing when I looked at it, but I guess I'm misremembering.) Probably need to mark the intrinsic CustomTypeChecking, then make the code in SemaChecking explicitly perform

[clang] [llvm] [PowerPC] Add intrinsics for rldimi/rlwimi/rlwnm (PR #82968)

https://github.com/efriedma-quic commented: If you run into issues using normal integer ops, please file bugs. Most people aren't going to hand-tune their code like this; builtins like this are at best an ugly workaround. That said, I guess I'm not strongly against adding a backdoor to force

[clang] [llvm] [PowerPC] Add intrinsics for rldimi/rlwimi/rlwnm (PR #82968)

@@ -10737,6 +10752,43 @@ SDValue PPCTargetLowering::LowerINTRINSIC_WO_CHAIN(SDValue Op, return DAG.getRegister(PPC::X13, MVT::i64); return DAG.getRegister(PPC::R2, MVT::i32); + case Intrinsic::ppc_rldimi: { +uint64_t SH = Op.getConstantOperandVal(3); +

[clang] [llvm] [PowerPC] Add intrinsics for rldimi/rlwimi/rlwnm (PR #82968)

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

[clang] [TBAA] Handle bitfields when generating !tbaa.struct metadata. (PR #82922)

@@ -294,18 +297,49 @@ CodeGenTBAA::CollectFields(uint64_t BaseOffset, return false; const ASTRecordLayout = Context.getASTRecordLayout(RD); +const CGRecordLayout = CGTypes.getCGRecordLayout(RD); unsigned idx = 0; -for (RecordDecl::field_iterator i

[clang] [TBAA] Handle bitfields when generating !tbaa.struct metadata. (PR #82922)

@@ -294,18 +297,49 @@ CodeGenTBAA::CollectFields(uint64_t BaseOffset, return false; const ASTRecordLayout = Context.getASTRecordLayout(RD); +const CGRecordLayout = CGTypes.getCGRecordLayout(RD); unsigned idx = 0; -for (RecordDecl::field_iterator i

[clang] [clang][NFC] constify or staticify some CGRecordLowering fns (PR #82874)

https://github.com/efriedma-quic approved this pull request. I'm not sure there's really much point to passing around a const reference to a CGRecordLowering; all the uses are in one file, so const-correctness doesn't seem to help that much. But if you want to do it this way, that's fine;

[clang] [TBAA] Skip all bitfields when generating !tbaa.struct metadata. (PR #82922)

efriedma-quic wrote: This seems like it messes up the metadata in a different way: we have no representation of the bitfield at all, so it looks like it's padding. I think we want to treat multiple adjacent bitfields as a single "field". So NamedBitfields from the testcase would have three

[clang] [clang][driver] Allow unaligned access on ARMv7 and higher by default (PR #82400)

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

[clang] [clang] Implement __builtin_popcountg (PR #82359)

efriedma-quic wrote: Please fix your GitHub settings so your email address is public. Looks like the bot didn't trigger for some reason; see https://github.com/llvm/llvm-project/pull/82429#issuecomment-1955214651 for the normal message. https://github.com/llvm/llvm-project/pull/82359

[clang] [clang] Implement __builtin_popcountg (PR #82359)

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

[clang] [clang][driver] Allow unaligned access on ARMv7 and higher by default (PR #82400)

@@ -886,28 +886,16 @@ llvm::ARM::FPUKind arm::getARMTargetFeatures(const Driver , } else { // Assume pre-ARMv6 doesn't support unaligned accesses. // -// ARMv6 may or may not support unaligned accesses depending on the -// SCTLR.U bit, which is

[clang] [clang][driver] Allow unaligned access on ARMv7 and higher by default (PR #82400)

efriedma-quic wrote: Unaligned accesses require that SCTLR.A is 0, SCTLR.U is 1, and that the memory in question is configured as "normal" memory. Almost all operating systems do in fact configure their registers/memory this way, but on baremetal it's not really a safe assumption. Changing

[clang] [clang] Implement __builtin_popcountg (PR #82359)

efriedma-quic wrote: Missing semantic analysis. Since the signature is unspecified in Builtin.td, you have to check that there's one argument, and that argument is an integer. That code should go in SemaChecking.cpp. You can leave constant evaluation to a followup, sure.

[clang] [clang-tools-extra] [codegen] Emit missing cleanups when an expression contains a branch (PR #80698)

@@ -592,10 +590,14 @@ void AggExprEmitter::EmitArrayInit(Address DestPtr, llvm::ArrayType *AType, // observed to be unnecessary. if (endOfInit.isValid()) Builder.CreateStore(element, endOfInit); } - -LValue elementLV = CGF.MakeAddrLValue( -

[clang] [llvm] [transforms] Inline simple variadic functions (PR #81058)

efriedma-quic wrote: > If we ignore that design and run functions through the block splitting > unnecessarily, we win a combinatorial increase in required testing, a > decrease in emitted code quality (spurious extra functions), an inability to > pattern match on fprintf->vfprintf style code

[clang] [C23] No longer assert on huge enumerator values (PR #81760)

https://github.com/efriedma-quic approved this pull request. LGTM Note you can get a similar crash using `enum x { X = (__uint128_t)(1<<64) };`. I'm a little surprised we haven't run into this before C23. https://github.com/llvm/llvm-project/pull/81760

[clang] [COFF][Aarch64] Add _InterlockedAdd64 intrinsic (PR #81849)

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

[clang] [llvm] [transforms] Inline simple variadic functions (PR #81058)

efriedma-quic wrote: > > I don't really like the whole "sufficiently simple function" thing. It > > seems fragile. You should be able to just take a arbitrary internal varargs > > function, rewrite its signature to take a va_list argument, rewrite calls > > to va_start to make a copy of that

[clang] [Clang][CodeGen] Loose the cast check when emitting builtins (PR #81669)

https://github.com/efriedma-quic approved this pull request. LGTM (It feels a little weird that the types in the clang AST don't actually match the LLVM builtin, but I guess it's not likely to actually cause any issues.) https://github.com/llvm/llvm-project/pull/81669

[clang] [Clang][CodeGen] Loose the cast check when emitting builtins (PR #81669)

efriedma-quic wrote: I can't tell what you're trying to fix here. Is this fixing a crash? Or is the check redundant? Or is it necessary for some followup change you want to make? https://github.com/llvm/llvm-project/pull/81669 ___ cfe-commits

[clang] [C23] Do not diagnose binary literals as an extension (PR #81658)

https://github.com/efriedma-quic commented: We could consider keeping the warning group, not actually guarding any warning, so we don't warn on `-Wno-gnu-binary-literal`. Otherwise looks fine. https://github.com/llvm/llvm-project/pull/81658 ___

[clang] [clang] Strict aliasing warning ala GCC [PR50066] (PR #74155)

efriedma-quic wrote: > IIUC you're suggesting movint the TBAA data origination from CodeGen into > (probably) Sema and/or TargetInfo and then deriving the LLVM info in CodeGen > from that. I.e. keep once source of truth, but move where it is? Right; move the core computation to AST, and then

[clang] [clang-tools-extra] [codegen] Emit missing cleanups when an expression contains a branch (PR #80698)

@@ -592,10 +590,14 @@ void AggExprEmitter::EmitArrayInit(Address DestPtr, llvm::ArrayType *AType, // observed to be unnecessary. if (endOfInit.isValid()) Builder.CreateStore(element, endOfInit); } - -LValue elementLV = CGF.MakeAddrLValue( -

[clang] [clang][CodeGen] Emit atomic IR in place of optimized libcalls. (PR #73176)

efriedma-quic wrote: Looks like a bug in the SPARC backend. https://github.com/llvm/llvm-project/pull/73176#pullrequestreview-1811677691 indicated that atomic expansion was working correctly for all backends, but I guess it isn't working correctly on SPARC.

[clang] [clang-tools-extra] [codegen] Emit missing cleanups when an expression contains a branch (PR #80698)

@@ -592,10 +590,14 @@ void AggExprEmitter::EmitArrayInit(Address DestPtr, llvm::ArrayType *AType, // observed to be unnecessary. if (endOfInit.isValid()) Builder.CreateStore(element, endOfInit); } - -LValue elementLV = CGF.MakeAddrLValue( -

[clang] [clang-tools-extra] [codegen] Emit missing cleanups when an expression contains a branch (PR #80698)

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

[clang] [clang-tools-extra] [codegen] Emit missing cleanups when an expression contains a branch (PR #80698)

@@ -627,9 +627,11 @@ CodeGenFunction::getJumpDestForLabel(const LabelDecl *D) { if (Dest.isValid()) return Dest; // Create, but don't insert, the new block. + // FIXME: We do not know `BranchInExprDepth` for the destination and currently + // emit *all* the

[clang] [clang-tools-extra] [codegen] Emit missing cleanups when an expression contains a branch (PR #80698)

https://github.com/efriedma-quic commented: Do we need to add handling for `new int[](co_await foo())` (CodeGenFunction::EmitNewArrayInitializer)? https://github.com/llvm/llvm-project/pull/80698 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[clang] [clang] Support `__is_trivially_copyable(int()&)==false` (PR #81298)

https://github.com/efriedma-quic updated https://github.com/llvm/llvm-project/pull/81298 >From d59c262b31937fdd2b907ec11d7f08e4a385007c Mon Sep 17 00:00:00 2001 From: Amirreza Ashouri Date: Fri, 9 Feb 2024 21:55:03 +0330 Subject: [PATCH 1/4] [clang] Support

[clang] [llvm] [transforms] Inline simple variadic functions (PR #81058)

@@ -0,0 +1,701 @@ +//===-- ExpandVariadicsPass.cpp *- 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:

[clang] [llvm] [transforms] Inline simple variadic functions (PR #81058)

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

[clang] [llvm] [transforms] Inline simple variadic functions (PR #81058)

https://github.com/efriedma-quic commented: I don't really like the whole "sufficiently simple function" thing. It seems fragile. You should be able to just take a arbitrary internal varargs function, rewrite its signature to take a va_list argument, rewrite calls to va_start to make a copy

[clang] Turn 'counted_by' into a type attribute and parse it into 'CountAttributedType' (PR #78000)

efriedma-quic wrote: One possibility would be to use a type qualifier? It has basically the kind of properties you want... the underlying type is still there, and places that strip qualifiers will automatically do the right thing in a lot of cases. It might require a bit more work to handle

[clang] [llvm] [clang] Support per-function [[clang::code_align(N)]] attribute. (PR #80765)

efriedma-quic wrote: > > I'm skeptical this actually makes sense in its current form. LLVM > > internally has a thing it calls a basic block, but what exactly counts is, > > to some extent, machine-specific, and can change from version to version. > > I guess regardless of whether we call it

[clang] [clang-tools-extra] [codegen] Emit cleanups for lifetime-extended temporaries when an expr contains control-flow (PR #80698)

@@ -628,7 +628,7 @@ CodeGenFunction::getJumpDestForLabel(const LabelDecl *D) { // Create, but don't insert, the new block. Dest = JumpDest(createBasicBlock(D->getName()), - EHScopeStack::stable_iterator::invalid(), +

[clang] [clang-tools-extra] [codegen] Emit cleanups for lifetime-extended temporaries when an expr contains control-flow (PR #80698)

@@ -628,7 +628,7 @@ CodeGenFunction::getJumpDestForLabel(const LabelDecl *D) { // Create, but don't insert, the new block. Dest = JumpDest(createBasicBlock(D->getName()), - EHScopeStack::stable_iterator::invalid(), +

[llvm] [clang-tools-extra] [clang] [codegen] Emit cleanups for lifetime-extended temporaries when an expr contains control-flow (PR #80698)

efriedma-quic wrote: If I understand correctly, a "lifetime-extended" cleanup deals with the case of a temporary whose lifetime continues beyond the expression. In other words, it has different lifetimes depending on how you exit the expression: if the variable's lifetime begins, it lasts

[clang] Turn 'counted_by' into a type attribute and parse it into 'CountAttributedType' (PR #78000)

efriedma-quic wrote: It's generally not a good idea to use sugar to represent constructs that are semantically significant: anything that uses the canonical type will throw it away. We try to avoid throwing away sugar in most cases, but we aren't always successful. It's possible there are

[clang] [NFC][Clang] Replace Arch with Triplet. (PR #80465)

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

[llvm] [libc] [mlir] [flang] [lldb] [clang] [libcxx] [mlir] Skip invalid test on big endian platform (s390x) (PR #80246)

@@ -0,0 +1,27 @@ +// RUN: mlir-translate -mlir-to-llvmir -split-input-file %s | FileCheck %s + +// Decoding the attribute does not work on big-endian platforms currently +// XFAIL: target=s390x-{{.*}} efriedma-quic wrote: LLVM tests use

[clang] [coverage] fix crash in code coverage and `if constexpr` with `ExprWithCleanups` (PR #80292)

@@ -1808,12 +1808,24 @@ struct CounterCoverageMappingBuilder } } +private: + static bool evaluateConstantCondition(const Expr *Condition) { +if (const auto *Expr = dyn_cast(Condition)) + return Expr->getResultAsAPSInt().getExtValue(); + +if (const auto

[clang] [clang] Only set the trailing bytes to zero when filling a partially … (PR #79502)

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

[clang] [clang] Only set the trailing bytes to zero when filling a partially … (PR #79502)

@@ -945,48 +950,77 @@ static bool canEmitInitWithFewStoresAfterBZero(llvm::Constant *Init, /// For inits that canEmitInitWithFewStoresAfterBZero returned true for, emit /// the scalar stores that would be required. -static void emitStoresForInitAfterBZero(CodeGenModule , -

[clang] [clang] Only set the trailing bytes to zero when filling a partially … (PR #79502)

@@ -945,48 +950,77 @@ static bool canEmitInitWithFewStoresAfterBZero(llvm::Constant *Init, /// For inits that canEmitInitWithFewStoresAfterBZero returned true for, emit /// the scalar stores that would be required. -static void emitStoresForInitAfterBZero(CodeGenModule , -

<    2   3   4   5   6   7   8   9   10   11   >