@@ -310,6 +310,41 @@ bool CodeGen::isEmptyRecord(ASTContext , QualType
T, bool AllowArrays,
return true;
}
+bool CodeGen::isEmptyFieldForLayout(const ASTContext ,
+const FieldDecl *FD) {
+ if (FD->isZeroLengthBitField(Context))
+
@@ -152,7 +152,7 @@ class ARMTargetCodeGenInfo : public TargetCodeGenInfo {
diag::warn_target_unsupported_branch_protection_attribute)
<< Arch;
} else {
- BPI.setFnAttributes(*Fn);
+ setBranchProtectionFnAttributes(BPI,
https://github.com/efriedma-quic approved this pull request.
LGTM with one minor comment
https://github.com/llvm/llvm-project/pull/98451
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/98451
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1,7 +1,19 @@
-// RUN: %clang_cc1 -emit-llvm < %s | grep "zeroinitializer, i16 16877"
+// RUN: %clang_cc1 %s -emit-llvm -triple x86_64-linux-gnu -o - | FileCheck %s
--check-prefixes=CHECK,EMPTY
+// RUN: %clang_cc1 %s -emit-llvm -triple x86_64-windows-msvc -o - | FileCheck
%s
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/96422
___
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/96422
___
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.
The updated approach makes sense, I think.
Please check that AArch64TargetLowering::LowerRETURNADDR works correctly when
LR is reserved; I think it should just work, but I'm not completely sure.
Otherwise LGTM
efriedma-quic wrote:
The usual mechanism for emitting deferred definitions involves
CodeGenModule::EmitDeferred(): declarations get added to the list by
addDeferredDeclToEmit(), then it goes through to emit all the declarations on
the list. So it's a matter of making sure the resolver ends
@@ -185,6 +203,18 @@ CALL_AO(PackedMembers)
// CHECK: call void @llvm.memcpy.p0.p0.i64({{.*}} align 1 {{.*}} align 1
{{.*}}i64 16, i1 {{.*}})
// CHECK: ret ptr
+// WithEmptyField copy-assignment:
+// CHECK-LABEL: define linkonce_odr nonnull align {{[0-9]+}}
@@ -1,7 +1,17 @@
-// RUN: %clang_cc1 -emit-llvm < %s | grep "zeroinitializer, i16 16877"
+// RUN: %clang_cc1 %s -emit-llvm -o - | FileCheck %s
// PR4390
struct sysfs_dirent {
- union { struct sysfs_elem_dir {} s_dir; };
+ union { struct sysfs_elem_dir { int x; } s_dir; };
@@ -137,6 +137,16 @@ bool isEmptyField(ASTContext , const FieldDecl
*FD, bool AllowArrays,
bool isEmptyRecord(ASTContext , QualType T, bool AllowArrays,
bool AsIfNoUniqueAddr = false);
+/// isEmptyFieldForLayout - Return true iff the field is "empty", that
@@ -3267,10 +3267,13 @@ bool AArch64FrameLowering::spillCalleeSavedRegisters(
InsertSEH(MIB, TII, MachineInstr::FrameSetup);
} else { // The code when the pair of ZReg is not present
MachineInstrBuilder MIB = BuildMI(MBB, MI, DL, TII.get(StrOpc));
- if
@@ -3267,10 +3267,13 @@ bool AArch64FrameLowering::spillCalleeSavedRegisters(
InsertSEH(MIB, TII, MachineInstr::FrameSetup);
} else { // The code when the pair of ZReg is not present
MachineInstrBuilder MIB = BuildMI(MBB, MI, DL, TII.get(StrOpc));
- if
efriedma-quic wrote:
The question is, if LTO merges two bitcode modules together with different
settings for the flag, how do you want the backend to behave? Usually you want
it to just continue to apply to the same functions it would have without LTO;
the only way to represent that is a
@@ -4917,6 +4917,9 @@ foreach i = {1-31} in
def ffixed_x#i : Flag<["-"], "ffixed-x"#i>, Group,
HelpText<"Reserve the x"#i#" register (AArch64/RISC-V only)">;
+def mlr_for_calls_only : Flag<["-"], "mlr-for-calls-only">,
Group,
efriedma-quic wrote:
Name
@@ -3267,10 +3267,13 @@ bool AArch64FrameLowering::spillCalleeSavedRegisters(
InsertSEH(MIB, TII, MachineInstr::FrameSetup);
} else { // The code when the pair of ZReg is not present
MachineInstrBuilder MIB = BuildMI(MBB, MI, DL, TII.get(StrOpc));
- if
@@ -2220,6 +2220,11 @@ llvm::Constant
*ConstantLValueEmitter::emitPointerAuthPointer(const Expr *E) {
// The assertions here are all checked by Sema.
assert(Result.Val.isLValue());
+ auto *Base = Result.Val.getLValueBase().get();
+ if (auto *Decl =
@@ -3140,6 +3140,269 @@
ASTContext::getPointerAuthVTablePointerDiscriminator(const CXXRecordDecl *RD) {
return llvm::getPointerAuthStableSipHash(Str);
}
+/// Encode a function type for use in the discriminator of a function pointer
+/// type. We can't use the itanium
efriedma-quic wrote:
The issue is just that clang expects the following to compile. And with the
current version of the patch, I think we end up crashing in the backend.
```
@f.x = internal global i32 trunc (i64 sub (i64 ptrtoint (ptr blockaddress(@f,
%A) to i64), i64 ptrtoint (ptr
efriedma-quic wrote:
Under the proposed ABI, `&&` is actually "sign(A)-sign(B)". Which is a
constant, but not one which can be represented as a relocation (as far as I
know).
https://github.com/llvm/llvm-project/pull/97647
___
cfe-commits mailing
efriedma-quic wrote:
It looks like in the latest patch, there's still a couple uses of isZeroSize()
in CGExprConstant?
https://github.com/llvm/llvm-project/pull/96422
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
efriedma-quic wrote:
> > For CGClass, it's not directly tied to the LLVM structure layout, but I'm
> > not sure the generated code would be semantically correct if an "empty"
> > field that isn't isEmpty() overlaps with actual data.
>
> I haven't addressed this yet. To clarify, are you
efriedma-quic wrote:
Why do we want a module flag, and not a function attribute? Module flags are
generally problematic during LTO, so we try to avoid them if they aren't truly
necessary.
https://github.com/llvm/llvm-project/pull/97524
___
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/97315
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
We have a mechanism which specifically encodes the distinction we want here:
ReserveXRegisterForRA. This was implemented for debugging/regression tests
(see https://reviews.llvm.org/D132717), but we can expose it more generally.
Naming is hard, but maybe
efriedma-quic wrote:
I'm not against having a security hardening feature to avoid using LR as a GPR.
But we'd want to name it something different, to make it clear that it's a
security-hardening feature, not a guarantee that the compiler won't clobber LR.
efriedma-quic wrote:
> What about the case I have mentioned in https://godbolt.org/z/vdhGbvj6W ?
That test doesn't really prove anything useful. The zeroing of a0 doesn't have
any ABI significance: "struct s12" doesn't have any data in it, so the caller
can't use the value in a0 for
https://github.com/efriedma-quic approved this pull request.
LGTM
I meant, at the beginning of X86_32ABIInfo::computeInfo there's a chain of if
statements that set up the properties of different calling conventions, and
maybe some bits could be set there. If you don't think that makes sense,
https://github.com/efriedma-quic commented:
If I'm understanding correctly, the way this currently works is that you do
normal field layout, then if you discover that the actual offset of a field is
less than the offset normal field layout would produce, you assume the struct
is packed. This
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/93267
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,43 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
UTC_ARGS: --version 5
+// The test may fail as time out on windows
+// REQUIRES: system-linux
+
+// RUN: %clang -S -O3 -emit-llvm -o - -x c++ %s | FileCheck %s
efriedma-quic wrote:
> gcc does ignore the empty array case for assigning argument registers in C++.
> Compare the two cases here https://godbolt.org/z/j4WP89rE8
Oh, you're right, I didn't actually do any testing myself, I was just assuming
@svs-quic did the right test.
So I guess the
https://github.com/efriedma-quic commented:
It looks like MSVC also applies this rule to fastcall.
Maybe put a boolean in the "state" to try to group together the code for
specific conventions, instead of directly checking the CC.
https://github.com/llvm/llvm-project/pull/97939
efriedma-quic wrote:
The current spec language is:
> Empty structs or union arguments or return values are ignored by C compilers
> which support them as a non-standard extension. This is not the case for C++,
> which requires them to be sized types.
So empty structs in C are ignored, empty
efriedma-quic wrote:
Oh, hmm, I see.
Maybe the right strategy here is to delay attaching the resolver to the ifunc
until the end of the translation unit, when we know the definition is already
emitted. That way, it should already have the right attributes. (We already
do some delayed
efriedma-quic wrote:
Please make sure you have a testcase for computing the difference between two
blockaddresses (`void g(int*); int f() { static int x = &&
A:g();B:return x; }`). Not sure how you should handle that case.
https://github.com/llvm/llvm-project/pull/97647
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/96659
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
Probably you want a dedicated codepath for computing the right kcfi type for
resolvers.
https://github.com/llvm/llvm-project/pull/96400
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -2220,6 +2220,11 @@ llvm::Constant
*ConstantLValueEmitter::emitPointerAuthPointer(const Expr *E) {
// The assertions here are all checked by Sema.
assert(Result.Val.isLValue());
+ auto *Base = Result.Val.getLValueBase().get();
+ if (auto *Decl =
efriedma-quic wrote:
Please add a test for `struct X { int x[0]; };`.
https://github.com/llvm/llvm-project/pull/97315
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
To the extent that EvaluateAsRValue handles LValues, FastEvaluateAsRValue
should also handle them, sure. I'm suspicious of the fact that
EvaluateAsRValue is doing this conversion in the first place, but I guess this
pull request isn't the place to address that.
Given
@@ -2220,6 +2220,11 @@ llvm::Constant
*ConstantLValueEmitter::emitPointerAuthPointer(const Expr *E) {
// The assertions here are all checked by Sema.
assert(Result.Val.isLValue());
+ auto *Base = Result.Val.getLValueBase().get();
+ if (auto *Decl =
efriedma-quic wrote:
I'm concerned that we're calling EvaluateKnownConstInt on an lvalue; that might
indicate there's something wrong with the AST. Usually there should be an
lvalue-to-rvalue cast somewhere.
https://github.com/llvm/llvm-project/pull/97146
efriedma-quic wrote:
The only place the standard requires padding to be zero-initialized is in
"default initialization", which only applies to members which don't have an
initializer. So, for example, if you have `struct X { int x; char y; } z =
{1};`, none of the padding is required to be
efriedma-quic wrote:
If there's some subset of cases that's easy to diagnose, like SSE registers
without SSE, maybe we can do that. I mostly care that we don't write a bunch of
code to check complicated edge cases, like trying to diagnose if you're using
too many registers.
efriedma-quic wrote:
What exactly does it mean for a constraint to conflict with a feature? The
only thing I can think of is if it somehow involves a register class that
doesn't exist on the target with the current set of target features. I guess
we could try to diagnose that, but I'm not
https://github.com/efriedma-quic commented:
We already have `-Wnan-infinity-disabled`, which I think is sufficient on the
warning side? Haven't checked carefully to see what cases it covers.
https://github.com/llvm/llvm-project/pull/96659
___
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/96659
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -47,6 +47,8 @@
(defined(__cplusplus) && __cplusplus >= 201103L) ||
\
(__STDC_HOSTED__ && defined(_AIX) && defined(_ALL_SOURCE))
#undef DECIMAL_DIG
+#undef INFINITY
efriedma-quic wrote:
The define guarding the undefs
efriedma-quic wrote:
I mean, this is conceptually fine as far as it goes, but I'm not sure where we
actually want to use it. As noted on the other PRs,
llvm.used/llvm.global_ctors/llvm.global_dtors don't really want a flat
address-space. The "address-space" for llvm.used, and for the
@@ -2220,6 +2220,11 @@ llvm::Constant
*ConstantLValueEmitter::emitPointerAuthPointer(const Expr *E) {
// The assertions here are all checked by Sema.
assert(Result.Val.isLValue());
+ auto *Base = Result.Val.getLValueBase().get();
+ if (auto *Decl =
@@ -3140,6 +3140,269 @@
ASTContext::getPointerAuthVTablePointerDiscriminator(const CXXRecordDecl *RD) {
return llvm::getPointerAuthStableSipHash(Str);
}
+/// Encode a function type for use in the discriminator of a function pointer
+/// type. We can't use the itanium
@@ -3140,6 +3140,269 @@
ASTContext::getPointerAuthVTablePointerDiscriminator(const CXXRecordDecl *RD) {
return llvm::getPointerAuthStableSipHash(Str);
}
+/// Encode a function type for use in the discriminator of a function pointer
+/// type. We can't use the itanium
efriedma-quic wrote:
To clarify for anyone else looking at this... there are three families of LUTI
instructions: one uses NEON registers, one uses SVE registers, and one uses SME
registers. This patch is just the variant that uses NEON registers.
efriedma-quic wrote:
I don't see any issues with the code. I'd prefer if we has a
TYSan-instrumented bootstrap build of LLVM before we merge this, so we're
confident this doesn't cause any unexpected issues.
https://github.com/llvm/llvm-project/pull/76612
efriedma-quic wrote:
If you want to push this forward, start a Discourse thread (discourse.llvm.org)
with a writeup of the proposal. Including an expanded rationale for why we
want this.
See also https://clang.llvm.org/get_involved.html
https://github.com/llvm/llvm-project/pull/92499
efriedma-quic wrote:
I don't think I like this approach:
- This seems like an easy way to unintentionally pass state between different
compilations.
- It seems very easy to try to use this API during LTO, and have it do nothing.
- I'm pretty sure this breaks existing workflows involving
efriedma-quic wrote:
> Or, if we do need to preserve bitcode compat, how to best achieve it? Perhaps
> we convert them into inline-asm in the bitcode upgrader?
Really, the question is whether we plan to completely drop support for the
x86_mmx type (including inline asm operands/results). If
@@ -1336,75 +1336,56 @@ static llvm::Value *CreateCoercedLoad(Address Src,
llvm::Type *Ty,
return CGF.Builder.CreateLoad(Tmp);
}
-// Function to store a first-class aggregate into memory. We prefer to
-// store the elements rather than the aggregate to be more friendly to
@@ -1336,75 +1336,56 @@ static llvm::Value *CreateCoercedLoad(Address Src,
llvm::Type *Ty,
return CGF.Builder.CreateLoad(Tmp);
}
-// Function to store a first-class aggregate into memory. We prefer to
-// store the elements rather than the aggregate to be more friendly to
efriedma-quic wrote:
For CGExprConstant, the code is checking "empty" in the sense of whether
there's a corresponding LLVM field. So almost certainly needs changes. Not
sure how that isn't causing test failures; maybe there's missing test coverage.
For CGClass, it's not directly tied to the
efriedma-quic wrote:
I didn't actually look at this PR closely before I commented.
I think the specific checks clang is doing here have to be part of clang: in
particular, clang needs to translate from gcc syntax to LLVM IR asm syntax, and
that requires parsing the constraints. So these
efriedma-quic wrote:
Hmm... so basically, the program is partitioned into parts with branch
enforcement disabled, and parts with branch enforcement enabled, and there's
some defined transition between the two? So in this case, the metadata is
nonsense, and you want to ignore it. I guess
efriedma-quic wrote:
> and that implies (at least to me) that an expression cannot form an infinity
> to begin with, so the act of trying to expand INFINITY is nonsensical in that
> case, right?
It's undefined behavior at runtime.
I don't think we need to worry too much about what the C
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/96659
___
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'm not sure about tying this to __FINITE_MATH_ONLY__; -ffinite-math-only
doesn't mean infinity doesn't exist, it just means you're promising that you
won't use floating-point arithmetic/comparison ops on infinity. Which is
weird, but that's
@@ -707,7 +707,39 @@ static RValue emitLibraryCall(CodeGenFunction , const
FunctionDecl *FD,
const CallExpr *E, llvm::Constant *calleeValue) {
CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, E);
CGCallee callee =
efriedma-quic wrote:
I guess the clang calling convention code never uses MMX types for
passing/returning values?
Have you looked at the code quality? #41665 mentions potential issues with
widening vectors.
This doesn't touch inline asm or _mm_empty; I guess you're leaving that for a
efriedma-quic wrote:
(I'd like a re-review of the latest version: I made significant revisions to
address the tail-padding issues.)
https://github.com/llvm/llvm-project/pull/93115
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
efriedma-quic wrote:
Do we want some sort of optimization for constant printf? 99% of the time, we
could parse the string at compile-time. (This sort of optimization is common
for embedded targets.)
If the format string isn't constant, is parsing the string on the GPU really
slower than
efriedma-quic wrote:
(Please move out of "draft" when you think this is ready.)
https://github.com/llvm/llvm-project/pull/96422
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
Please fix buildbot failure (it looks like clang/test/CodeGen/ifunc.c is
failing).
https://github.com/llvm/llvm-project/pull/96400
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -5751,8 +5751,29 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo
,
if (llvm::CallInst *Call = dyn_cast(CI)) {
if (TargetDecl && TargetDecl->hasAttr())
Call->setTailCallKind(llvm::CallInst::TCK_NoTail);
-else if (IsMustTail)
+else if
@@ -707,7 +707,36 @@ static RValue emitLibraryCall(CodeGenFunction , const
FunctionDecl *FD,
const CallExpr *E, llvm::Constant *calleeValue) {
CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, E);
CGCallee callee =
@@ -707,7 +707,34 @@ static RValue emitLibraryCall(CodeGenFunction , const
FunctionDecl *FD,
const CallExpr *E, llvm::Constant *calleeValue) {
CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, E);
CGCallee callee =
efriedma-quic wrote:
In a lot of cases, we report_fatal_error because we don't actually expect users
to run into the issues... indicate some internal inconsistency in the compiler,
or some unsupported configuration, or something like that. Because of this,
report_fatal_error prints the
efriedma-quic wrote:
This is roughly what I expected the patch to look like. Maybe consider adding
a couple small wrapper functions around isEmptyRecord/isEmptyField to simplify
the uses (and so we can use a name that indicates why the checks exist).
efriedma-quic wrote:
If you want to modify part of a bitfield unit, you need to load/store the whole
bitfield unit, as computed by the CGRecordLayout. This is true whether you're
modifying an actual field, or padding adjacent to a field. Since any padding
has to be adjacent to a bitfield,
efriedma-quic wrote:
I'm not sure I understand the goal here.
For return-address signing, each function can make its own choice about whether
to sign; the function that's doing the signing is the same function that does
the auth, so it doesn't directly impact any other function. For branch
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/95999
___
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. Please don't forget about the varargs issue, though
https://github.com/llvm/llvm-project/pull/96259
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
efriedma-quic wrote:
I can't think of any obvious reason this would cause timeouts. I mean, you're
adding metadata to a bunch of functions, and if something handles that metadata
inefficiently, things could easily explode. But nothing specific comes to mind.
@@ -707,7 +707,34 @@ static RValue emitLibraryCall(CodeGenFunction , const
FunctionDecl *FD,
const CallExpr *E, llvm::Constant *calleeValue) {
CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, E);
CGCallee callee =
efriedma-quic wrote:
> > Can we restrict this to targets where libm actually modifies errno?
>
> Do you mean it is better to have a function list, which actually modifies
> `errno` ? For example, we should restrict to `__exp10`, but but not a general
> top call `__exp `?
I said targets, not
https://github.com/efriedma-quic approved this pull request.
https://github.com/llvm/llvm-project/pull/94226
___
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/96025
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -707,7 +707,38 @@ static RValue emitLibraryCall(CodeGenFunction , const
FunctionDecl *FD,
const CallExpr *E, llvm::Constant *calleeValue) {
CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, E);
CGCallee callee =
https://github.com/efriedma-quic commented:
Ideally we could identify errno more precisely somehow, but I guess this is
better than nothing.
Can we restrict this to targets where libm actually modifies errno?
How does this interact with StrictFP?
efriedma-quic wrote:
It's not that hard to compute "no-data": non-RecordDecls are never no-data,
RecordDecls are no-data if they don't have a vtable pointer (isDynamicClass()),
and all fields are no-data. We can save it in the CGRecordLayout.
Assuming that's the route we want to go, of
efriedma-quic wrote:
I think some of the overloads for constructing an instruction aren't quite
right: in some cases, we require a non-null insertion-point so we can retrieve
the DataLayout from the insertion-point. (Particularly instructions that have
an explicitly specified alignment.) In
@@ -203,8 +203,15 @@ ABIArgInfo NVPTXABIInfo::classifyArgumentType(QualType Ty)
const {
void NVPTXABIInfo::computeInfo(CGFunctionInfo ) const {
if (!getCXXABI().classifyReturnType(FI))
FI.getReturnInfo() = classifyReturnType(FI.getReturnType());
- for (auto :
efriedma-quic wrote:
> > couldn't the inverse be true, then - that codegen should ignore if
> > something isZeroSize or not?
>
> Just to clarify, is the suggestion here to remove the special handling of
> `isZeroSize` in the RecordLayoutBuilder?
We currently need to distinguish between empty
@@ -97,9 +102,13 @@ define void @test_vla(i32 %n) nounwind ssp {
; MSVC-X64: callq escape
; MSVC-X64: movq [[SLOT]](%rbp), %rcx
; MSVC-X64: xorq %rbp, %rcx
-; MSVC-X64: callq __security_check_cookie
+; MSVC-X64:movq__security_cookie(%rip), %rax
@@ -5,9 +5,20 @@ declare void @h(ptr, i64, ptr)
efriedma-quic wrote:
Can we use update_llc_test_checks.py for this test?
https://github.com/llvm/llvm-project/pull/95904
___
cfe-commits mailing list
efriedma-quic wrote:
I don't have any context beyond what's written on
https://reviews.llvm.org/D25204 . And at this point, I'm not sure what
compiler we're trying to be compatible with. (I added @erichkeane in case he
remembers.)
https://github.com/llvm/llvm-project/pull/95257
https://github.com/efriedma-quic approved this pull request.
LGTM
Your commit message mentions variables, function pointers, and member function
pointers... is there anything else we need to handle? Null pointers?
Integers?
https://github.com/llvm/llvm-project/pull/92477
efriedma-quic wrote:
That would mean if someone wrote `struct Empty {}; struct Z { Empty a,b,c; }`,
we'd lower it to `{ [3 x i8] }` instead of `{%Empty, %Empty, %Empty}`, which is
a bit ugly. Other than that, sure, I guess we could do that.
https://github.com/llvm/llvm-project/pull/93809
efriedma-quic wrote:
Please don't commit binary files if it isn't absolutely necessary. You can
generate whatever files you need in a RUN line.
https://github.com/llvm/llvm-project/pull/95802
___
cfe-commits
@@ -0,0 +1,98 @@
+// RUN: %clang_cc1 %s -fsyntax-only --embed-dir=%S/Inputs -verify=expected,cxx
-Wno-c23-extensions
+// RUN: %clang_cc1 -x c -std=c23 %s -fsyntax-only --embed-dir=%S/Inputs
-verify=expected,c
+#embed
+;
+
+void f (unsigned char x) { (void)x;}
+void g () {}
101 - 200 of 1060 matches
Mail list logo