https://github.com/efriedma-quic commented:
This is roughly what I expected. But it looks like there are some build
failures on the bot.
https://github.com/llvm/llvm-project/pull/156643
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://
https://github.com/efriedma-quic commented:
Instead of creating a separate cleanup stack and adding special deferred
handling for that cleanup stack, can we just skip creating the scope in the
first place? We have `LexicalScope ForScope(*this, S.getSourceRange());`; can
we replace that with s
https://github.com/efriedma-quic approved this pull request.
LGTM
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
efriedma-quic wrote:
Given the current definition of "ninf", there is no way to legally check if a
value produced by an "ninf" instruction is infinity: even if the bitpattern
looks like an infinity, it's actually poison. If that's causing problems for
you, we might need to revisit the definit
https://github.com/efriedma-quic approved this pull request.
I've reviewed other changes here recently (#152866). The code is playing some
weird games with memory allocation, using an std::vector as an arena. Probably
there's some better way to write this. Strictly speaking, it's undefined
https://github.com/efriedma-quic commented:
"End of the function" is not really correct. It's still the end of the scope...
just the scope in question is different. This matters if you have, for
example, a nested loop.
Probably need to change CodeGenFunction::EmitForStmt to push the scope at
@@ -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
https://github.com/efriedma-quic commented:
Is there some reason clang can't just generate a call to `llvm.is.fpclass`?
https://github.com/llvm/llvm-project/pull/156570
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-
https://github.com/efriedma-quic closed
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
efriedma-quic wrote:
Sorry, forgot this was still open.
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
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
@@ -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
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
@@ -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
@@ -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 -
@@ -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
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
@@ -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/
@@ -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``
+-
@@ -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 -
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
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
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
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
@@ -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
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
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
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
@@ -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
@@ -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
@@ -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/
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
@@ -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
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
___
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
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
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
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
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
@@ -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),
-
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
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
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
@@ -4652,6 +4659,7 @@ llvm::Constant
*CodeGenModule::GetOrCreateMultiVersionResolver(GlobalDecl GD) {
"", Resolver, &getModule());
GIF->setName(ResolverName);
SetCommonAttributes(FD, GIF);
+SetResolverAttrs(cast(Resolver));
---
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
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
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
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
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
@@ -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
@@ -1409,6 +1409,12 @@ class WinX86_64ABIInfo : public ABIInfo {
return isX86VectorCallAggregateSmallEnough(NumMembers);
}
+ ABIArgInfo classifyArgForArm64ECVarArg(QualType Ty) const override {
efriedma-quic wrote:
classifyArgForArm64ECVarArg is exclus
@@ -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
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
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?
@@ -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 (
@@ -4184,29 +4184,14 @@ Value
*ScalarExprEmitter::EmitOverflowCheckedBinOp(const BinOpInfo &Ops) {
}
/// Emit pointer + index arithmetic.
-static Value *emitPointerArithmetic(CodeGenFunction &CGF,
-const BinOpInfo &op,
-
@@ -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);
+
@@ -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
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
___
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
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
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
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
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
_
@@ -2294,6 +2294,18 @@ llvm::Value *CodeGenFunction::EmitDynamicCast(Address
ThisAddr,
DestRecordTy->getAsCXXRecordDecl()->isEffectivelyFinal() &&
CGM.getCXXABI().shouldEmitExactDynamicCast(DestRecordTy);
+ std::optional ExactCastInfo;
+ if
@@ -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.
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
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
@@ -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
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
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
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
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
___
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-
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
@@ -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
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
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
@@ -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
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
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
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
_
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
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
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
@@ -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
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
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
@@ -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
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
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
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
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
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.
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
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
1 - 100 of 1776 matches
Mail list logo
