@@ -4820,6 +4820,9 @@ bool
CodeGenFunction::isUnderlyingBasePointerConstantNull(const Expr *E) {
const Expr *UnderlyingBaseExpr = E->IgnoreParens();
while (auto *BaseMemberExpr = dyn_cast(UnderlyingBaseExpr))
UnderlyingBaseExpr = BaseMemberExpr->getBase()->IgnoreParens
@@ -4238,7 +4238,8 @@ static Value *emitPointerArithmetic(CodeGenFunction &CGF,
else
elemTy = CGF.ConvertTypeForMem(elementType);
- if (CGF.getLangOpts().PointerOverflowDefined)
+ if (CGF.getLangOpts().PointerOverflowDefined ||
+ CGF.isUnderlyingBasePointerConstan
@@ -2,16 +2,20 @@
// RUN: %clang_cc1 -Wreorder -fsyntax-only -verify -std=c++98 %s
// RUN: %clang_cc1 -Wreorder -fsyntax-only -verify -std=c++11 %s
-class A {
+class A {
+ // expected-note@-1 {{candidate constructor}}
+#if __cplusplus >= 201103L // C++11 or later
+ // expec
efriedma-quic wrote:
Not sure if anyone has mentioned this elsewhere, but there's a significant
problem with the type of the returned function pointer: a normal function
pointer doesn't necessarily have the correct calling convention. In practice,
this is likely to cause problems on Windows.
efriedma-quic wrote:
I don't think it makes sense to have a target-specific "verifier": verification
sets the limits of what optimizations are allowed to do. And that
determination needs to be target-independent, or else target-independent
optimizations can't exist. Target-specific intrinsic
=?utf-8?q?Théo?= de Magalhaes
Message-ID:
In-Reply-To:
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/136062
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cf
=?utf-8?q?Th=C3=A9o?= de Magalhaes
Message-ID:
In-Reply-To:
https://github.com/efriedma-quic approved this pull request.
Oh, I see, I missed the nesting.
LGTM
https://github.com/llvm/llvm-project/pull/136062
___
cfe-commits mailing list
cfe-commits
efriedma-quic wrote:
I'm not really happy with that... but if the semantics were never properly
defined in the first place, I guess this isn't making things worse.
Not sure if marking the allocas themselves is actually the right approach
long-term. It seems like there's a distinction between
efriedma-quic wrote:
Adding metadata to an instruction should never be required for correctness:
optimizations are not required to preserve metadata on instructions, so this
"fix" will just break again later.
If we need two different kinds of alloca in coroutine functions, we need a
different
efriedma-quic wrote:
`-std=gnu99` etc. sets LangOpts.GNUMode... but we don't want to base the ABI on
that; it's not an ABI flag. The ABI should only be based on the triple, and
flags specifically intended to modify the ABI.
I think we should just use the GNU-compatible ABI by default. Unless
https://github.com/efriedma-quic approved this pull request.
https://github.com/llvm/llvm-project/pull/126750
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
Should the result type of the ImplicitCastExpr be volatile in the AST?
https://github.com/llvm/llvm-project/pull/127824
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-com
efriedma-quic wrote:
> we can't have epilogs in chained unwind tables, since they are only for
> additional savereg codes.
How do epilogs work in chained unwind tables? Do the epilog opcodes from the
original table get ignored? If they do get ignored, can you specify different
opcodes in th
@@ -500,7 +500,8 @@ MCSymbol *MCStreamer::emitLineTableLabel() {
MCSymbol *MCStreamer::emitCFILabel() {
// Return a dummy non-null value so that label fields appear filled in when
// generating textual assembly.
- return (MCSymbol *)1;
+ static size_t DummyLabelValue = 0;
@@ -51,18 +51,18 @@ namespace disabled_dtor {
union disable_dtor {
T val;
template
-disable_dtor(U &&...u) : val(forward(u)...) {}
+disable_dtor(U &&...u) : val(forward(u)...) {} // expected-error
{{attempt to use a deleted function}}
efriedm
@@ -0,0 +1,48 @@
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify %s
+
+namespace t1{
+template struct VSX {
+ ~VSX() { static_assert(sizeof(T) != 4, ""); } // expected-error {{static
assertion failed due to requirement 'sizeof(int) != 4':}} \
+
@@ -5451,10 +5451,31 @@ bool Sema::SetCtorInitializers(CXXConstructorDecl
*Constructor, bool AnyErrors,
NumInitializers * sizeof(CXXCtorInitializer*));
Constructor->setCtorInitializers(baseOrMemberInitializers);
+SourceLocation Location = Constructor->getLo
@@ -5451,10 +5451,23 @@ bool Sema::SetCtorInitializers(CXXConstructorDecl
*Constructor, bool AnyErrors,
NumInitializers * sizeof(CXXCtorInitializer*));
Constructor->setCtorInitializers(baseOrMemberInitializers);
+SourceLocation Location = Constructor->getLo
efriedma-quic wrote:
Here's a testcase that's should generate a diagnostic, but doesn't without this
patch:
```
int &ff(); int &x = ff(); constinit int &z = x;
```
Some related testcases are a little weird... consider the following:
```
extern int &x; int &z = x;
```
There's a gap between ch
https://github.com/efriedma-quic updated
https://github.com/llvm/llvm-project/pull/129952
>From 9ac636ee137248cafe38f4d2e016cfb885142dff Mon Sep 17 00:00:00 2001
From: Eli Friedman
Date: Wed, 5 Mar 2025 14:20:21 -0800
Subject: [PATCH 1/3] [clang] Reject constexpr-unknown values as constant
exp
efriedma-quic wrote:
> That said, this patch might be worth having in that branch AS WELL to cover
> any other missed cases. I would be OK having this patch HERE only on that
> branch or replaced with an assert in main.
#128409 should cover all the cases this patch would cover. I'm a little
efriedma-quic wrote:
Opened #129844 with a case that still fails. Other entry-points to constant
evaluation need similar treatment to EvaluateAsInitializer.
https://github.com/llvm/llvm-project/pull/128409
___
cfe-commits mailing list
cfe-commits@lis
efriedma-quic wrote:
And the check for allowConstexprUnknown() isn't catching all the relevant
cases; opened #129845.
https://github.com/llvm/llvm-project/pull/128409
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-b
https://github.com/efriedma-quic updated
https://github.com/llvm/llvm-project/pull/129952
>From 9ac636ee137248cafe38f4d2e016cfb885142dff Mon Sep 17 00:00:00 2001
From: Eli Friedman
Date: Wed, 5 Mar 2025 14:20:21 -0800
Subject: [PATCH 1/2] [clang] Reject constexpr-unknown values as constant
exp
@@ -154,3 +154,26 @@ int g() {
static_assert(f(arr) == 5);
}
}
+
+namespace GH128409 {
+ int &ff();
+ int &x = ff(); // nointerpreter-note {{declared here}}
+ constinit int &z = x; // expected-error {{variable does not have a constant
initializer}}
+
efriedma-quic wrote:
This needs a higher-level description of the overall goal, and why you've
picked the specific instrumentation points you've chosen.
https://github.com/llvm/llvm-project/pull/130103
___
cfe-commits mailing list
cfe-commits@lists.ll
efriedma-quic wrote:
/cherry-pick 42d49a77241df73a17cb442973702fc460e7fb90
https://github.com/llvm/llvm-project/pull/129952
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/129952
___
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/130522
___
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 somehow thought we had already done something about this, but I can't find
any reference to it.
Anyway, if we're going to support this as an extension, I don't want to bury it
in CGBuilder.h. We should decide exactly when we want it to trigger, an
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/128409
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -5451,10 +5451,23 @@ bool Sema::SetCtorInitializers(CXXConstructorDecl
*Constructor, bool AnyErrors,
NumInitializers * sizeof(CXXCtorInitializer*));
Constructor->setCtorInitializers(baseOrMemberInitializers);
+SourceLocation Location = Constructor->getLo
@@ -500,7 +500,8 @@ MCSymbol *MCStreamer::emitLineTableLabel() {
MCSymbol *MCStreamer::emitCFILabel() {
// Return a dummy non-null value so that label fields appear filled in when
// generating textual assembly.
- return (MCSymbol *)1;
+ static size_t DummyLabelValue = 0;
efriedma-quic wrote:
So if an unwind table has an epilog opcode, and you chain another unwind table
to it, the chained unwind table inherits the epilog opcode? You could use that.
The primary unwind table ends at the first epilog, you mark it with an "atend"
epilog opcode. The next region sta
efriedma-quic wrote:
Just ran into some related code: see 3d0a540857edbd510e329f40581f6b2c1968ccca .
Maybe using IgnoreParenCasts() like that code does is appropriate. (I don't
really like using IgnoreParenCasts() because there's such a big variety of
casts, but it's probably okay in this co
@@ -2586,10 +2586,11 @@ static void UpdateAsmCallInst(llvm::CallBase &Result,
bool HasSideEffect,
// Slap the source location of the inline asm into a !srcloc metadata on the
// call.
- if (const auto *gccAsmStmt = dyn_cast(&S))
-Result.setMetadata("srcloc",
-
https://github.com/efriedma-quic created
https://github.com/llvm/llvm-project/pull/129952
Perform the check for constexpr-unknown values in the same place we perform
checks for other values which don't count as constant expressions.
While I'm here, also fix a rejects-valid with a reference tha
https://github.com/efriedma-quic updated
https://github.com/llvm/llvm-project/pull/129952
>From 9ac636ee137248cafe38f4d2e016cfb885142dff Mon Sep 17 00:00:00 2001
From: Eli Friedman
Date: Wed, 5 Mar 2025 14:20:21 -0800
Subject: [PATCH] [clang] Reject constexpr-unknown values as constant
express
efriedma-quic wrote:
> We only perform this optimization in addrspace(0).
I'd still prefer to get this right for all address-spaces, so we don't need to
revisit later.
But really, I'm more concerned about the "happens to get folded" part: there
isn't a stable set of values that get constant-
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/126750
___
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.
https://github.com/llvm/llvm-project/pull/120896
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
> Clang rejects the following case after modifying evaluateValue to treat
> constexpr-unknown value as invalid
I don't see the connection. At least, there isn't any obvious connection: the
testcase doesn't require constexpr-unknown. Maybe you need to "reject" the
value
https://github.com/efriedma-quic approved this pull request.
https://github.com/llvm/llvm-project/pull/128105
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
I think if we're trying to automatically identify whether an alloca has one of
two lifetimes, and one of those lifetimes isn't a subset of the other, we're
guaranteed to run into trouble again, eventually. We have to pick the right
lifetime 100% of the time... but without
@@ -2587,6 +2587,9 @@ APValue
*VarDecl::evaluateValueImpl(SmallVectorImpl &Notes,
!Notes.empty())
Result = false;
+ if (Eval->Evaluated.allowConstexprUnknown())
+Result = false;
efriedma-quic wrote:
I think this check should be inside `Evaluat
@@ -3628,8 +3628,6 @@ static bool evaluateVarDeclInit(EvalInfo &Info, const
Expr *E,
if (AllowConstexprUnknown) {
if (!Result)
Result = &Info.CurrentCall->createConstexprUnknownAPValues(VD, Base);
-else
- Result->setConstexprUnknown();
efr
efriedma-quic wrote:
I'm worried this is just scratching the surface... it looks like there's a
whole class of issues involving constexpr-unknown leaking out of constant
evaluation, and this is just addressing one specific case. If we can't take
https://github.com/llvm/llvm-project/pull/12840
@@ -1984,6 +1984,15 @@ llvm::Constant
*ConstantEmitter::emitForMemory(CodeGenModule &CGM,
return Res;
}
+ // In HLSL bool vectors are stored in memory as a vector of i32
+ if (destType->isExtVectorBoolType() && CGM.getContext().getLangOpts().HLSL) {
e
@@ -122,9 +122,9 @@ namespace CaseStatements {
}
extern int &Recurse1;
-int &Recurse2 = Recurse1; // expected-note {{declared here}}
+int &Recurse2 = Recurse1; // pre-cxx23-note {{declared here}}
efriedma-quic wrote:
I'd guess you just need to generate a note
https://github.com/efriedma-quic commented:
Does it even make sense for evaluateValue to return a constexpr-unknown value?
If I'm following correctly, we can't actually do anything useful with such a
result: we don't actually know what the value is. It would make things simpler
if we kept su
@@ -617,15 +617,15 @@ class ConstantDataSequential : public ConstantData {
/// If this is a sequential container of integers (of any size), return the
/// specified element in the low bits of a uint64_t.
- uint64_t getElementAsInteger(unsigned i) const;
+ uint64_t getEle
@@ -644,7 +644,7 @@ class ConstantDataSequential : public ConstantData {
Type *getElementType() const;
/// Return the number of elements in the array or vector.
- unsigned getNumElements() const;
+ uint64_t getNumElements() const;
efriedma-quic wrote:
A
https://github.com/efriedma-quic approved this pull request.
LGTM.
(I'll merge once the premerge checks come back.)
https://github.com/llvm/llvm-project/pull/126481
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin
@@ -27,7 +27,7 @@ void testva (int n, ...) {
va_start(ap,n);
// CHECK: [[AP:%[a-z0-9]+]] = alloca ptr, align 4
// CHECK: [[V5:%[a-z0-9]+]] = alloca %struct.x, align 4
- // CHECK: [[TMP:%[a-z0-9]+]] = alloca [4 x i32], align 4
+ // CHECK: [[TMP:%[a-z0-9\.]+]] = alloca [4
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/130990
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
Might as well do it for bitcode too? That wouldn't impact LTO scenarios, I
think: in LTO, the IR is directly loaded by lld/the LTO plugin.
https://github.com/llvm/llvm-project/pull/134396
___
cfe-commits mailing list
cfe-commits@
@@ -793,6 +793,7 @@ void CodeGenModule::EmitCXXModuleInitFunc(Module *Primary) {
}
CodeGenFunction(*this).GenerateCXXGlobalInitFunc(Fn, ModuleInits,
GuardAddr);
+getTargetCodeGenInfo().setTargetAttributes(nullptr,
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/134282
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
=?utf-8?q?Théo?= De Magalhaes ,
=?utf-8?q?Théo?= De Magalhaes ,
=?utf-8?q?Théo?= De Magalhaes ,
=?utf-8?q?Théo?= De Magalhaes ,
=?utf-8?q?Théo?= De Magalhaes ,
=?utf-8?q?Théo?= De Magalhaes ,
=?utf-8?q?Théo?= De Magalhaes ,
=?utf-8?q?Théo?= De Magalhaes
Message-ID:
In-Reply-To:
https://github.c
efriedma-quic wrote:
> The ubsan handler cannot be eliminated because inaccessiblemem: readwrite
> indicates that it has externally observable side effects.
That is not how things work. For example:
```
$ echo "declare void @g() define void @f() nounwind { call void @g()
memory(argmem: read,
https://github.com/efriedma-quic updated
https://github.com/llvm/llvm-project/pull/132990
>From 2873bb1aee5470ecd7fa66c1f255bfe8b26dbc68 Mon Sep 17 00:00:00 2001
From: Eli Friedman
Date: Mon, 17 Mar 2025 11:20:21 -0700
Subject: [PATCH 1/2] [clang] fix constexpr-unknown handling of
self-referen
Jan =?utf-8?q?Górski?= ,
Jan =?utf-8?q?Górski?=
Message-ID:
In-Reply-To:
@@ -590,6 +590,29 @@ static void EmitAtomicOp(CodeGenFunction &CGF, AtomicExpr
*E, Address Dest,
llvm::LoadInst *Load = CGF.Builder.CreateLoad(Ptr);
Load->setAtomic(Order, Scope);
Load->set
Jan =?utf-8?q?Górski?= ,
Jan =?utf-8?q?Górski?=
Message-ID:
In-Reply-To:
@@ -590,6 +590,29 @@ static void EmitAtomicOp(CodeGenFunction &CGF, AtomicExpr
*E, Address Dest,
llvm::LoadInst *Load = CGF.Builder.CreateLoad(Ptr);
Load->setAtomic(Order, Scope);
Load->set
efriedma-quic wrote:
I don't understand what you're planning. Currently, the only thing the
POSIXThreads LangOption does is control `_REENTRANT` or equivalent. If you
provide a separate option to control the macro, the POSIXThreads option doesn't
do anything at all.
https://github.com/llvm/
efriedma-quic wrote:
> most of them are safe
What's the distinguishing factor here? Do you consider it "safe" to mark
inbounds if the pointer is immediately dereferenced? Or does the pointer have
to refer to a known successful allocation? Or something else?
https://github.com/llvm/llvm-pro
@@ -1491,7 +1491,10 @@ void CodeGenFunction::EmitComplexExprIntoLValue(const
Expr *E, LValue dest,
"Invalid complex expression to emit");
ComplexExprEmitter Emitter(*this);
ComplexPairTy Val = Emitter.Visit(const_cast(E));
- Emitter.EmitStoreOfComplex(Val, dest,
https://github.com/efriedma-quic commented:
There's a comment in CodeGenFunction::EmitReturnBlock that says:
```
// FIXME: We are at an unreachable point, there is no reason to emit the block
// unless it has uses. However, we still need a place to put the debug
// region.end for now.
```
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/134088
___
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 you also need to fix the backends so if they see thread_pointer
intrinsic with the wrong address-space, they don't crash.
https://github.com/llvm/llvm-project/pull/132489
___
cfe-commits mailing list
https://github.com/efriedma-quic commented:
I'm not sure I understand why we're changing the linkage of functions in an IR
pass, instead of just setting the correct linkage in the first place. Is there
some form of linker involved? If there is, should the linker fix the linkage?
By conventio
=?utf-8?q?Théo?= De Magalhaes ,
=?utf-8?q?Théo?= De Magalhaes ,
=?utf-8?q?Théo?= De Magalhaes ,
=?utf-8?q?Théo?= De Magalhaes ,
=?utf-8?q?Théo?= De Magalhaes ,
=?utf-8?q?Théo?= De Magalhaes ,
=?utf-8?q?Théo?= De Magalhaes ,
=?utf-8?q?Théo?= De Magalhaes
Message-ID:
In-Reply-To:
efriedma-quic wr
@@ -3897,6 +3897,13 @@ void CodeGenFunction::EmitFunctionEpilog(const
CGFunctionInfo &FI,
return;
}
+ // If there is no valid insert point, we won't emit a return.
+ // The insert point could be null if we have already emitted a return
+ // (e.g. if musttail)
+ if (
@@ -193,8 +334,23 @@ LValue CIRGenFunction::emitUnaryOpLValue(const
UnaryOperator *e) {
switch (op) {
case UO_Deref: {
-cgm.errorNYI(e->getSourceRange(), "UnaryOp dereference");
-return LValue();
+QualType t = e->getSubExpr()->getType()->getPointeeType();
+
efriedma-quic wrote:
I'm mostly concerned about the case where the lowered node has the wrong type.
For example, AArch64TargetLowering::LowerINTRINSIC_WO_CHAIN always creates a
value with the pointer width of addrspace 0, but address spaces exist which
don't have the native pointer width (arm
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/134396
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -581,8 +581,11 @@ CodeGenTypes::arrangeObjCMessageSendSignature(const
ObjCMethodDecl *MD,
}
FunctionType::ExtInfo einfo;
- bool IsWindows = getContext().getTargetInfo().getTriple().isOSWindows();
- einfo = einfo.withCallingConv(getCallingConventionForDecl(MD, IsWindo
efriedma-quic wrote:
I really don't want the dependency chain that involves clang converting the
target feature list to an LLVM attribute string, then grabbing the attribute
out of the llvm::Function to parse it back into a feature list. That ties
together the target info and codegen in a wei
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/137851
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,251 @@
+//===-- WindowsHotPatch.cpp - Support for Windows hotpatching
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,251 @@
+//===-- WindowsHotPatch.cpp - Support for Windows hotpatching
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -7613,6 +7613,9 @@ def import_call_optimization : Flag<["-"],
"import-call-optimization">,
"by the Windows kernel to enable import call optimization">,
MarshallingInfoFlag>;
+def replaceable_function: Joined<["-"], "loader-replaceable-function=">,
+ Marsh
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/125320
___
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/125320
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -4661,3 +4661,109 @@ AsmPrinter::getCodeViewJumpTableInfo(int JTI, const
MachineInstr *BranchInstr,
return std::make_tuple(Base, 0, BranchLabel,
codeview::JumpTableEntrySize::Int32);
}
+
+void AsmPrinter::emitCOFFReplaceableFunctionData(Module &M)
@@ -0,0 +1,251 @@
+//===-- WindowsHotPatch.cpp - Support for Windows hotpatching
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,251 @@
+//===-- WindowsHotPatch.cpp - Support for Windows hotpatching
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,251 @@
+//===-- WindowsHotPatch.cpp - Support for Windows hotpatching
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,251 @@
+//===-- WindowsHotPatch.cpp - Support for Windows hotpatching
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,251 @@
+//===-- WindowsHotPatch.cpp - Support for Windows hotpatching
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -4169,10 +4169,10 @@ static Value *emitPointerArithmetic(CodeGenFunction
&CGF,
// The index is not pointer-sized.
// The pointer type is not byte-sized.
//
- if (BinaryOperator::isNullPointerArithmeticExtension(CGF.getContext(),
-
efriedma-quic wrote:
These days, there's very high demand for "secure" C/C++. From this
perspective, this optimization is a security threat: if you write code that
does an undefined write to "this", you have a lurking security vulnerability
could be exposed with any change to optimization heu
@@ -9125,9 +9126,25 @@ bool
LValueExprEvaluator::VisitCompoundLiteralExpr(const CompoundLiteralExpr *E) {
assert((!Info.getLangOpts().CPlusPlus || E->isFileScope()) &&
"lvalue compound literal in c++?");
- // Defer visiting the literal until the lvalue-to-rvalue con
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/137849
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -486,6 +486,39 @@ ABIArgInfo AArch64ABIInfo::classifyArgumentType(QualType
Ty, bool IsVariadicFn,
}
Size = llvm::alignTo(Size, Alignment);
+// If the Aggregate is made up of pointers, use an array of pointers for
the
+// coerced type. This prevents having
@@ -486,6 +486,39 @@ ABIArgInfo AArch64ABIInfo::classifyArgumentType(QualType
Ty, bool IsVariadicFn,
}
Size = llvm::alignTo(Size, Alignment);
+// If the Aggregate is made up of pointers, use an array of pointers for
the
+// coerced type. This prevents having
@@ -486,6 +486,39 @@ ABIArgInfo AArch64ABIInfo::classifyArgumentType(QualType
Ty, bool IsVariadicFn,
}
Size = llvm::alignTo(Size, Alignment);
+// If the Aggregate is made up of pointers, use an array of pointers for
the
+// coerced type. This prevents having
https://github.com/efriedma-quic updated
https://github.com/llvm/llvm-project/pull/132990
Rate limit · GitHub
body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe
UI,Helvetica,Arial,
https://github.com/efriedma-quic commented:
Please update LangRef with the new overload and verifier rule.
https://github.com/llvm/llvm-project/pull/132489
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/l
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/132489
___
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:
It looks like my previous comments about ConstantExpr never got resolved?
Specifically, what happens if you have an instruction where an operand is a
ConstantExpr GEP of a global, or something like that.
https://github.com/llvm/llvm-project/pull/138
1701 - 1800 of 2063 matches
Mail list logo
