efriedma-quic wrote:
There are two possible alternative sequences we could generate there:
```
int test(int x, int y) {
struct S s;
__builtin_memset(&s, 0, 8);
s.x = x;
s.y = y;
f(&s);
}
int test2(int x, int y) {
struct S s;
long long dummy = (unsigned char)x;
__b
efriedma-quic wrote:
(There's basically no benefit to just directly replacing a memset with an
equivalent store; most relevant LLVM optimizations are memset-aware.)
https://github.com/llvm/llvm-project/pull/97121
___
cfe-commits mailing list
cfe-commi
@@ -353,6 +427,17 @@ AArch64ABIInfo::classifyArgumentType(QualType Ty, bool
IsVariadic,
nullptr, true, Align);
}
+ // In AAPCS named arguments of a Pure Scalable Type are passed expanded in
+ // registers, or indirectly if there are not enough registers.
+ if (Ki
https://github.com/efriedma-quic commented:
Clang tracks the number of registers used on other targets, so it's not
unprecedented... just an unfortunate consequence of the limitations of ABI in
LLVM IR.
https://github.com/llvm/llvm-project/pull/112747
__
@@ -533,11 +638,158 @@ bool
AArch64ABIInfo::isZeroLengthBitfieldPermittedInHomogeneousAggregate()
return true;
}
+// Check if a type is a Pure Scalable Type as defined by AAPCS64. Return the
+// number of data vectors and the number of predicate vectors in the types,
into
@@ -533,11 +638,158 @@ bool
AArch64ABIInfo::isZeroLengthBitfieldPermittedInHomogeneousAggregate()
return true;
}
+// Check if a type is a Pure Scalable Type as defined by AAPCS64. Return the
+// number of data vectors and the number of predicate vectors in the types,
into
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/112747
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
unnamed_addr doesn't allow cloning; there's no way to make it work in a
reasonable way even if we wanted it. See, for example,
https://github.com/llvm/llvm-project/issues/32127 .
https://github.com/llvm/llvm-project/pull/111343
efriedma-quic wrote:
> Intention is to allow to use any bits in pointer for tagging and give freedom
Hmm, so needs to somehow allow accessing bits that aren't low bits?
As a general comment not specific to this patch, I'd prefer to build around
llvm.ptrmask and geps as much as possible, as opp
efriedma-quic wrote:
> "clang::FunctionType" makes me wonder if there is actually a source-language
> function type available so that the signedness of the extensions could be
> inferred from it..? I thought these were internal calls to functions that
> will be emitted directly on IR...
The s
efriedma-quic wrote:
Oh... GlobalValue::canBeOmittedFromSymbolTable is a rabbit-hole I didn't know
existed. Apparently I don't know how unnamed_addr works.
(canBeOmittedFromSymbolTable is completely inconsistent with the way everything
else in the compiler reasons about unnamed_addr.)
https
@@ -1774,6 +1805,50 @@ void AggExprEmitter::VisitCXXParenListOrInitListExpr(
}
}
}
+ if (ZeroInitPadding) {
+uint64_t TotalSize = CGF.getContext().toBits(
+Dest.getPreferredSize(CGF.getContext(), DestLV.getType()));
+DoZeroInitPadding(BaseAddr, Last
@@ -1774,6 +1805,50 @@ void AggExprEmitter::VisitCXXParenListOrInitListExpr(
}
}
}
+ if (ZeroInitPadding) {
+uint64_t TotalSize = CGF.getContext().toBits(
+Dest.getPreferredSize(CGF.getContext(), DestLV.getType()));
+DoZeroInitPadding(BaseAddr, Last
efriedma-quic wrote:
ast-dump for your example:
```
| | `-CallExpr 0xcc44978 'unsigned long'
| | |-ImplicitCastExpr 0xcc44960 'unsigned long (*)(const void *,
int)'
| | | `-DeclRefExpr 0xcc448b8 '' Function
0xcc446b0 '__builtin_dynamic_object_size' 'unsigned long (const void *, i
efriedma-quic wrote:
The value clang computes is the difference between the address of the beginning
of the struct, and the end of the array (or the end of the struct, if the array
fits in the padding). The value gcc computes is that, plus the offset between
the beginning of the array and the
efriedma-quic wrote:
I'm not sure what you think you're proving with that example; without the
counted_by, we can't compute the size of the struct, so we just fall back to
returning the size of the allocation.
https://github.com/llvm/llvm-project/pull/111015
___
https://github.com/efriedma-quic created
https://github.com/llvm/llvm-project/pull/111065
Conditional operators that emit a branch go through a codepath which attaches
metadata to that branch. But if we take a shortcut to emit a select directly,
we end up skipping that code, and don't emit the
https://github.com/efriedma-quic updated
https://github.com/llvm/llvm-project/pull/111065
>From 0d74b6ccb1b23d74f713313cd09f44aa295905c0 Mon Sep 17 00:00:00 2001
From: Eli Friedman
Date: Thu, 3 Oct 2024 14:24:05 -0700
Subject: [PATCH] [clang codegen] Emit !unpredictable metadata more
consisten
@@ -5811,9 +5811,12 @@ LValue CodeGenFunction::EmitBinaryOperatorLValue(const
BinaryOperator *E) {
// This function implements trivial copy assignment for HLSL's
// assignable constant arrays.
LValue CodeGenFunction::EmitHLSLArrayAssignLValue(const BinaryOperator *E) {
- LVal
@@ -4690,8 +4690,9 @@ void CodeGenFunction::EmitCallArg(CallArgList &args,
const Expr *E,
return emitWritebackArg(*this, args, CRE);
}
- assert(type->isReferenceType() == E->isGLValue() &&
- "reference binding to unmaterialized r-value!");
+ assert(type->isArr
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/111047
___
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'd like to see a testcase for passing an array parameter to another function
which takes an array parameter.
https://github.com/llvm/llvm-project/pull/111047
___
cfe-commits mailing list
cfe-commits@lists.l
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/113336
___
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/112066
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
I suspect fma is not one of the functions we want to try to share, at least not
short-term. It's one of the core IEEE operations, LLVM has
APFloat::fusedMultiplyAdd since forever, and there's probably some weirdness
with dependencies if we try to share it because other op
@@ -24,9 +27,140 @@ CIRGenModule::CIRGenModule(mlir::MLIRContext &context,
clang::ASTContext &astctx,
const clang::CodeGenOptions &cgo,
DiagnosticsEngine &diags)
-: astCtx(astctx), langOpts(ast
@@ -24,9 +27,140 @@ CIRGenModule::CIRGenModule(mlir::MLIRContext &context,
clang::ASTContext &astctx,
const clang::CodeGenOptions &cgo,
DiagnosticsEngine &diags)
-: astCtx(astctx), langOpts(ast
efriedma-quic wrote:
> If we want to change the type of a global variable, maybe we can use
> Value::mutateType
Trying to mutate the type of a global is still unsafe. The benefit of opaque
pointers here is that getValueType() is independent from getType(), so it's
safe to rewrite the ValueTy
@@ -8714,6 +8714,21 @@ void Sema::CheckVariableDeclarationType(VarDecl *NewVD) {
}
}
+ // zero sized static arrays are not allowed in HIP device functions
+ if (LangOpts.CUDAIsDevice && LangOpts.HIP) {
+if (FunctionDecl *FD = getCurFunctionDecl();
+FD &&
+
@@ -4063,6 +4063,11 @@ defm threadsafe_statics :
BoolFOption<"threadsafe-statics",
NegFlag,
PosFlag>;
+defm tls_guards : BoolFOption<"tls-guards",
+ LangOpts<"TlsGuards">, DefaultTrue,
efriedma-quic wrote:
If we're going to expose this as a clang option (
@@ -186,6 +186,7 @@ COMPATIBLE_LANGOPT(RecoveryAST, 1, 1, "Preserve expressions
in AST when encounte
COMPATIBLE_LANGOPT(RecoveryASTType, 1, 1, "Preserve the type in recovery
expressions")
BENIGN_LANGOPT(ThreadsafeStatics , 1, 1, "thread-safe static initializers")
+BENIGN_LAN
@@ -4928,8 +4928,9 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl
GD, unsigned BuiltinID,
// Look at the argument type to determine whether this is a volatile
// operation. The parameter type is always volatile.
QualType PtrTy = E->getArg(0)->IgnoreImp
@@ -5272,8 +5272,11 @@ bool Sema::BuiltinAssumeAligned(CallExpr *TheCall) {
{
ExprResult FirstArgResult =
DefaultFunctionArrayLvalueConversion(FirstArg);
-if (checkBuiltinArgument(*this, TheCall, 0))
efriedma-quic wrote:
checkBuiltinArgument
efriedma-quic wrote:
(Not sure who the right reviewers are for XCOFF; I tried to guess.)
https://github.com/llvm/llvm-project/pull/112714
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commit
@@ -8714,6 +8714,21 @@ void Sema::CheckVariableDeclarationType(VarDecl *NewVD) {
}
}
+ // zero sized static arrays are not allowed in HIP device functions
+ if (LangOpts.CUDAIsDevice && LangOpts.HIP) {
+if (FunctionDecl *FD = getCurFunctionDecl();
+FD &&
+
@@ -4928,8 +4928,9 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl
GD, unsigned BuiltinID,
// Look at the argument type to determine whether this is a volatile
// operation. The parameter type is always volatile.
QualType PtrTy = E->getArg(0)->IgnoreImp
efriedma-quic wrote:
> I could not find back if you are allowed to use an inline assembly memory
> operand for such an instruction (*), but it certainly seems a real risk that
> users are doing this.
Tried some quick tests; in the following, gcc doesn't eliminate the load:
```
int f(int *rr)
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/113714
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2259,6 +2259,17 @@ QualType Sema::BuildArrayType(QualType T,
ArraySizeModifier ASM,
isSFINAEContext() ? diag::err_typecheck_zero_array_size
: diag::ext_typecheck_zero_array_size)
<< 0 << ArraySize->getSourceRange();
+
https://github.com/efriedma-quic created
https://github.com/llvm/llvm-project/pull/113506
Correctly computing the LLVM types/attributes is complicated in general, so add
a variant which does that for you.
>From 852334cad31df42463a831f9c53cc4ac4535b93c Mon Sep 17 00:00:00 2001
From: Eli Friedma
efriedma-quic wrote:
I looked to see how hard it would be to lower the clang type... seems like it's
not hard. Pushed #113506. Let me know what you think.
If there's some complication I'm not seeing, I think your suggested API in the
current version of this patch makes sense... but using cla
https://github.com/efriedma-quic updated
https://github.com/llvm/llvm-project/pull/113506
>From bb58bdd524ea751d598fe8d4954be91f88279b21 Mon Sep 17 00:00:00 2001
From: Eli Friedman
Date: Wed, 23 Oct 2024 16:12:27 -0700
Subject: [PATCH] [clang codegen] Add CreateRuntimeFunction overload that tak
@@ -5584,6 +5584,20 @@ static void handleAbiTagAttr(Sema &S, Decl *D, const
ParsedAttr &AL) {
AbiTagAttr(S.Context, AL, Tags.data(), Tags.size()));
}
+static void handleARMInterruptSaveFPAttr(Sema &S, Decl *D,
+ const P
@@ -80,13 +80,47 @@ ARMBaseRegisterInfo::getCalleeSavedRegs(const
MachineFunction *MF) const {
? CSR_ATPCS_SplitPush_SwiftTail_SaveList
: CSR_AAPCS_SwiftTail_SaveList);
} else if (F.hasFnAttribute(
efriedma-quic wrote:
I'd like some answer about how we plan to ensure the macros remain correct.
Short-term, "someone periodically runs the tool manually" might be good enough
if we don't expect much churn, I guess.
Also, can the tool itself be added to llvm-project?
(The actual changes seem
@@ -303,6 +368,20 @@ AArch64ABIInfo::classifyArgumentType(QualType Ty, bool
IsVariadic,
if (EIT->getNumBits() > 128)
return getNaturalAlignIndirect(Ty, false);
+if (const BuiltinType *BT = Ty->getAs()) {
+ if (BT->isSVEBool() || BT->isSVECount())
+
@@ -899,6 +899,11 @@ void CodeGenFunction::StartFunction(GlobalDecl GD,
QualType RetTy,
if (CodeGenOpts.PointerAuth.IndirectGotos)
Fn->addFnAttr("ptrauth-indirect-gotos");
+ // Add return control flow integrity attributes for RISCV.
+ if (CodeGenOpts.CFProtectionRetur
efriedma-quic wrote:
Also, I'm not sure objects are destroyed in the correct order.
-
As far as I know, fini_array existed at the time the Itanium ABI was written; I
assume it intentionally was not used because there were issues ensuring the
correct objects are destroyed in the correct or
https://github.com/efriedma-quic commented:
CodeGen should not produce errors for overflows which do not occur at
compile-time according to the language semantics. This is happening at
runtime, so we need to just eat the error; we can emit an unconditional call to
the ubsan error handler. We
https://github.com/efriedma-quic requested changes to this pull request.
I'm not sure we can just unconditionally call the destructor. We need to
ensure the constructor runs first. If a constructor throws an exception or
calls exit(), not all constructors will run before we start cleaning up.
efriedma-quic wrote:
To ensure we don't destroy objects that weren't constructed, you can use a
guard variable of some sort, sure. I'm not quite sure what the goal is, here;
are you trying to improve performance, or are you worried about the function
pointers for security?
>>Also, I'm not su
@@ -8714,6 +8714,21 @@ void Sema::CheckVariableDeclarationType(VarDecl *NewVD) {
}
}
+ // zero sized static arrays are not allowed in HIP device functions
+ if (LangOpts.CUDAIsDevice && LangOpts.HIP) {
+if (FunctionDecl *FD = getCurFunctionDecl();
+FD &&
+
@@ -33,7 +33,6 @@ enum CPUFeatures {
FEAT_FP,
FEAT_SIMD,
FEAT_CRC,
- FEAT_SHA1,
efriedma-quic wrote:
We've generally been more conservative with compiler-rt.builtins compared with
other parts of compiler-rt, like sanitizers. People do ship static lib
@@ -870,6 +904,15 @@ bool ConstStructBuilder::Build(const APValue &Val, const
RecordDecl *RD,
if (!EltInit)
return false;
+if (ZeroInitPadding) {
+ if (!DoZeroInitPadding(Layout, FieldNo, *Field, SizeSoFar,
+ IsFlexibleArray, All
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/66404
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -12658,10 +12658,10 @@ This instruction requires several arguments:
the return value of the callee is returned to the caller's caller, even
if a void return type is in use.
- Both markers imply that the callee does not access allocas from the caller.
- The `
@@ -0,0 +1,321 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
UTC_ARGS: --version 5
+; RUN: llc -mtriple=armv7a-none-eabi %s -o - | FileCheck %s
+
+declare i32 @many_args_callee(i32 %0, i32 %1, i32 %2, i32 %3, i32 %4, i32 %5)
+
+define i32 @many
@@ -5112,7 +5112,7 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo
&CallInfo,
RawAddress SRetAlloca = RawAddress::invalid();
llvm::Value *UnusedReturnSizePtr = nullptr;
if (RetAI.isIndirect() || RetAI.isInAlloca() || RetAI.isCoerceAndExpand()) {
-if (IsVirtu
https://github.com/efriedma-quic created
https://github.com/llvm/llvm-project/pull/109898
Reverts llvm/llvm-project#97121
Causing failures on LNT bots; log shows a crash in
ConstStructBuilder::BuildStruct.
>From cf31625ebefd05e8ca07f6f6b664d9a5bee9cd0f Mon Sep 17 00:00:00 2001
From: Eli Fried
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/109898
___
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
I think we'll need to watch out for performance regressions... in most cases,
we can probably zero-pad cheaply, but there might be cases where it isn't
cheap, or cases where it should be cheap but the LLVM backend can't figure i
efriedma-quic wrote:
> I think we'd get decent code by doing a sequence of LOAD bytes to vregs> ; TOKENFACTOR ; STORE .
Up to some threshold, sure. If the scheduler is sufficiently clever, we won't
even get any spills: we can interleave the loads and stores. But we probably
still need some
@@ -1,8 +1,31 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
UTC_ARGS: --version 4
; RUN: llc -mtriple=arm-eabi -mattr=+neon -float-abi=soft %s -o - | FileCheck
%s
; CHECK: function1
; CHECK-NOT: vmov
efriedma-quic wrote:
@@ -0,0 +1,343 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
UTC_ARGS: --version 5
+; RUN: llc -mtriple=armv7a-none-eabi %s -o - | FileCheck %s
+
+declare i32 @many_args_callee(i32 %0, i32 %1, i32 %2, i32 %3, i32 %4, i32 %5)
+
+define i32 @many
@@ -1748,6 +1771,26 @@ void AggExprEmitter::VisitCXXParenListOrInitListExpr(
CGF.getTypes().isZeroInitializable(ExprToVisit->getType()))
break;
+if (ZeroInitPadding) {
+ uint64_t StartBitOffset = Layout.getFieldOffset(field->getFieldIndex());
+ Char
efriedma-quic wrote:
The code assumes standard substitutions are not themselves substitutable. So
you probably need to call mangleSubstitution/addSubstitution explicitly in the
code. mangleSubstitution checks if there's an existing substitution,
addSubstitution appends to the list of substi
efriedma-quic wrote:
Please update the documentation for isSafeToSpeculativelyExecute() to specify
the semantics in the case where the operands of the instruction don't dominate
CtxI.
https://github.com/llvm/llvm-project/pull/109277
___
cfe-commits m
efriedma-quic wrote:
> If DataLayout is still a good place, then it might be just about whether we
> call it a flat address space, or optimizable address space, and nothing would
> be different from what is done in this PR.
We've avoided putting optimization properties in the DataLayout in the
@@ -738,7 +738,7 @@ bool ConstStructBuilder::Build(const InitListExpr *ILE,
bool AllowOverwrite) {
// Zero-sized fields are not emitted, but their initializers may still
// prevent emission of this struct as a constant.
if (isEmptyFieldForLayout(CGM.getContext(), F
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 %s -emit-llvm -triple x86_64-linux-gnu -o - | FileCheck %s
--check-prefixes=CHECK
+// RUN: %clang_cc1 -x c++ %s -emit-llvm -triple x86_64-linux-gnu -o - |
FileCheck %s --check-prefixes=CHECK-CXX
+
+union Foo {
+ struct Empty {} val;
+};
+
+u
@@ -8573,7 +8661,10 @@ class LValueExprEvaluator
bool VisitMaterializeTemporaryExpr(const MaterializeTemporaryExpr *E);
bool VisitCompoundLiteralExpr(const CompoundLiteralExpr *E);
bool VisitMemberExpr(const MemberExpr *E);
- bool VisitStringLiteral(const StringLiteral *
efriedma-quic wrote:
Oh, that makes sense... so the issue is generally with functions we emit lazily?
I'd say it's reasonable to emit an error if we have two definitions for the
same symbol, even if we don't end up emitting them because they're deferred.
Lazy emission is an optimization, and
@@ -738,7 +738,7 @@ bool ConstStructBuilder::Build(const InitListExpr *ILE,
bool AllowOverwrite) {
// Zero-sized fields are not emitted, but their initializers may still
// prevent emission of this struct as a constant.
if (isEmptyFieldForLayout(CGM.getContext(), F
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/109271
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
Yes, that makes sense, thanks.
https://github.com/llvm/llvm-project/pull/109277
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
getAddrOfCurrentPosition() is one way to do it... but it's not the only way to
do it. It was specifically designed to handle cases in CGExprConstant that
would have been difficult to refactor otherwise.
Here, it's simple to compute the correct address beforehand, so you c
https://github.com/efriedma-quic commented:
This is sort of the same comment I've made on other related patches... but I
think the fundamental issue here is that StructAccessBase is skipping over
CK_LValueToRValue casts. Once you jump over such a cast, you're looking at
expressions which are
efriedma-quic wrote:
(See discussion on #110487)
https://github.com/llvm/llvm-project/pull/110497
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
> just leads to infinite recursion (obviously),
Try casting the pointer to uintptr_t?
---
Might be simpler to mess with CXXNameMangler::mangleUnscopedName, though, which
I think is where the St prefix is getting added.
https://github.com/llvm/llvm-project/pull/106353
efriedma-quic wrote:
> OK, so your position is that this patch should add a section in
> LanguageExtensions that describes the assumptions that we make regarding the
> effects of inline assembly, do I understand that correctly?
Yes.
Ideally, we'd also have more complete documentation about co
https://github.com/efriedma-quic commented:
We need documentation for the exact assumptions we're making here.
Distinguishing between "volatile" and a "memory clobber" seems a bit
aggressive... I mean, I'm not sure what gcc does here, but it seems like an
extremely subtle distinction. Same wi
@@ -4207,16 +4214,31 @@ llvm::Constant *ItaniumRTTIBuilder::BuildTypeInfo(
break;
}
- llvm::Constant *Init = llvm::ConstantStruct::getAnon(Fields);
-
SmallString<256> Name;
llvm::raw_svector_ostream Out(Name);
CGM.getCXXABI().getMangleContext().mangleCXXRTTI(Ty
efriedma-quic wrote:
The gcc documentation isn't really written like a reference... it's hard to
tell what exactly it does and does not guarantee. And we generally want clang
to reduce its reliance on gcc documentation to define its own behavior.
Particularly for edges that gcc documentation
efriedma-quic wrote:
As a new feature, this needs a proposal on Discourse.
https://github.com/llvm/llvm-project/pull/110188
___
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:
StructAccessBase has two possible results: it finds an lvalue that's the base,
which can't be peeled apart any further, or it finds a pointer that's the base.
It shouldn't be possible to confuse a pointer with a MemberExpr: a MemberExpr
is an lvalue
efriedma-quic wrote:
Is there a plan for maintaining these annotations long-term? Like, should
there be a pre-commit action to verify that all the annotations are up-to-date?
https://github.com/llvm/llvm-project/pull/109702
___
cfe-commits mailing li
efriedma-quic wrote:
For a new feature with no existing implementation/language specification, I
want to see community input from people who want to use it, and understand the
potential impact on other projects (in this context, debuggers). There isn't
any formal requirement that happens on D
efriedma-quic wrote:
> I'm not sure what you mean by "or it finds a pointer that's the base". The
> MemberExpr the visitor returns doesn't have to be a pointer---e.g.
> ptr->a.b.c.d returning ptr->a.b, where b isn't a pointer---or do you mean
> something else?
In an expression which does not
efriedma-quic wrote:
Just under "clang" is fine.
https://github.com/llvm/llvm-project/pull/110188
___
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/112747
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1,101 +1,230 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
UTC_ARGS: --version 5
efriedma-quic wrote:
I think it makes sense to leave this test as-is... it's serving as an
end-to-end test that the given C construct is a n
@@ -1,5 +1,6 @@
-// RUN: %clang_cc1 -flax-vector-conversions=none -ffreestanding %s -O3
-triple=x86_64-apple-darwin -target-feature +avx -emit-llvm -o - | FileCheck %s
-// RUN: %clang_cc1 -flax-vector-conversions=none -ffreestanding %s -O3
-triple=i386-apple-darwin -target-featu
@@ -8714,6 +8714,31 @@ void Sema::CheckVariableDeclarationType(VarDecl *NewVD) {
}
}
+ // zero sized static arrays are not allowed in HIP device functions
+ if (LangOpts.CUDAIsDevice && LangOpts.HIP) {
+if (FunctionDecl *FD = getCurFunctionDecl();
+FD &&
+
efriedma-quic wrote:
SetLLVMFunctionAttributes() should add the appropriate signext/zeroext
attribute. At least, it appears to work in my testing. I'll add a regression
test.
https://github.com/llvm/llvm-project/pull/113506
___
cfe-commits mailing
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/102199
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/efriedma-quic ready_for_review
https://github.com/llvm/llvm-project/pull/113506
___
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/113506
>From 5d789d1698070d12d3c64e58cf1cd04624becce7 Mon Sep 17 00:00:00 2001
From: Eli Friedman
Date: Wed, 23 Oct 2024 16:12:27 -0700
Subject: [PATCH] [clang codegen] Add CreateRuntimeFunction overload that tak
efriedma-quic wrote:
Yes, review comments don't indicate approval after the comments are addressed
unless the reviewer explicitly says that. The reviewer may want to take a look
at the updated changes, or responses to review comments, or maybe the review
wasn't complete for whatever reason.
efriedma-quic wrote:
The type of an alloca is only used to determine the number of bytes allocated;
it doesn't have any other semantics. So it's fine as long as the alloca is 16
bytes. Which I think it is in the given example, because of the datalayout
rules for `<3 x i32>`.
https://github.
efriedma-quic wrote:
(For context, grep for PreserveVec3Type.)
Probably the code should be defensive and check for the allocation size of the
vector type, but I don't think any targets define the alignment for
non-power-of-2 vectors in a way that would cause issues.
https://github.com/llvm/ll
1201 - 1300 of 1826 matches
Mail list logo
