@@ -5085,7 +5085,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 approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/98138
___
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; the approach here seems appropriate.
(The EmitCheckedInBoundsGEP API could probably use a refactor so we don't have
calls to isSignedOverflowDefined() scattered all over the place, but that's a
separate issue.)
https://github.
efriedma-quic wrote:
Oh, I see.
If you can prove that it would be illegal to use a negative index with a
particular pointer, you might be able to optimize... but I'm not sure how
aggressive we want to be here. Even if the C standard technically disallows
indexing past the beginning/end of a
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/105746
___
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:
Is the backend actually ready for this? Looking quickly at the backend, it
looks like target-independent code is fine, but some of the target-specific
code doesn't respect the "contract" flag on instructions.
https://github.com/llvm/llvm-project/pul
@@ -348,20 +348,8 @@ static bool initTargetOptions(DiagnosticsEngine &Diags,
.Default(llvm::FloatABI::Default);
// Set FP fusion mode.
- switch (LangOpts.getDefaultFPContractMode()) {
- case LangOptions::FPM_Off:
-// Preserve any contraction performed by the
@@ -45,7 +45,7 @@ void test3(packedfloat3 *p) {
*p = (packedfloat3) { 3.2f, 2.3f, 0.1f };
}
// CHECK: @test3(
-// CHECK: store <4 x float> {{.*}}, align 4
+// CHECK: store <3 x float> {{.*}}, align 4
efriedma-quic wrote:
Even if we can prove it doesn't trap,
efriedma-quic wrote:
It doesn't fuse unless AllowFPOpFusion is set.
https://github.com/llvm/llvm-project/pull/105746
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
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 f
@@ -707,7 +707,34 @@ static RValue emitLibraryCall(CodeGenFunction &CGF, const
FunctionDecl *FD,
const CallExpr *E, llvm::Constant *calleeValue) {
CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, E);
CGCallee callee = CGCallee::forDirect(calle
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.
https://github.com/llvm/llvm-proje
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
https://lists.llvm.org/cgi-b
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
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 tar
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, yo
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).
https://github.com/llvm/llvm-project/pull/
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 standa
@@ -707,7 +707,34 @@ static RValue emitLibraryCall(CodeGenFunction &CGF, const
FunctionDecl *FD,
const CallExpr *E, llvm::Constant *calleeValue) {
CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, E);
CGCallee callee = CGCallee::forDirect(calle
@@ -707,7 +707,36 @@ static RValue emitLibraryCall(CodeGenFunction &CGF, const
FunctionDecl *FD,
const CallExpr *E, llvm::Constant *calleeValue) {
CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, E);
CGCallee callee = CGCallee::forDirect(calle
@@ -5751,8 +5751,29 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo
&CallInfo,
if (llvm::CallInst *Call = dyn_cast(CI)) {
if (TargetDecl && TargetDecl->hasAttr())
Call->setTailCallKind(llvm::CallInst::TCK_NoTail);
-else if (IsMustTail)
+else if (Is
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
https://lists.llvm.org/cgi-bin/mailman/list
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:
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 ask
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
https://lists.l
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
follow
@@ -707,7 +707,39 @@ static RValue emitLibraryCall(CodeGenFunction &CGF, const
FunctionDecl *FD,
const CallExpr *E, llvm::Constant *calleeValue) {
CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, E);
CGCallee callee = CGCallee::forDirect(calle
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 fast-ma
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
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 stand
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 that
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 check
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
@@ -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:
> 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 w
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
AMDGPU
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 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:
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.
https://github.com/llvm/llvm-project/pull/968
@@ -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 scheme
@@ -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 scheme
@@ -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 = dyn_cast_or_null(Base
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 "associ
@@ -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 n
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:
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
___
cfe-com
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 su
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.
https://github.com
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 in
efriedma-quic wrote:
Reproduced: https://godbolt.org/z/G4jrhdjef . Looks like an instcombine bug.
https://github.com/llvm/llvm-project/pull/107257
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/
@@ -33,7 +33,6 @@ enum CPUFeatures {
FEAT_FP,
FEAT_SIMD,
FEAT_CRC,
- FEAT_SHA1,
efriedma-quic wrote:
Are there ABI stability concerns if you modify this enum?
https://github.com/llvm/llvm-project/pull/108383
efriedma-quic wrote:
Both in InferAddressSpaces, and in Attributor, you don't really care about
whether a flat address-space exists. All you really need to know is whether,
for a given pair of address-spaces "A" and "B", `addrspacecast ptr addrspace(A)
%x to ptr addrspace(B)` should be optimi
https://github.com/efriedma-quic commented:
I think you should be able to avoid constructing the initializer twice if you
restructure the code a bit to just construct the global before the call to
BuildVTablePointer. I added GlobalVariable::replaceInitializer because I was
looking at this rev
efriedma-quic wrote:
How does this interact with #107598?
https://github.com/llvm/llvm-project/pull/108853
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
> I see that it is set and the reason the existing error is not emitted is
> because of the !Entry->isDeclaration() condition.
For non-lambda methods, the way this works it that we call
GetOrCreateLLVMFunction for both methods... for the first method, the
`!Entry->isDecla
efriedma-quic wrote:
> Should be fixed by
> https://github.com/llvm/llvm-project/commit/940f89255e4a3982d94dad57837e8e658092af78.
I quickly glanced through the other uses of setIsInBounds in LLVM; the one in
CodeGenPrepare seems suspicious.
https://github.com/llvm/llvm-project/pull/107257
___
@@ -18197,7 +18197,7 @@ Value *CodeGenFunction::EmitPPCBuiltinExpr(unsigned
BuiltinID,
CallOps.push_back(Ops[i]);
llvm::Function *F = CGM.getIntrinsic(ID);
Value *Call = Builder.CreateCall(F, CallOps);
-return Builder.CreateAlignedStore(Call, Ops[0], MaybeAli
@@ -1,5 +1,6 @@
// RUN: %clang_cc1 -triple x86_64-windows-msvc -fms-extensions -emit-llvm -O2
< %s | FileCheck %s --check-prefixes=X64,ALL
// RUN: %clang_cc1 -triple i386-pc-win32 -fms-extensions -emit-llvm -O2 < %s |
FileCheck %s --check-prefixes=X86,ALL
+// RUN: %clang_cc1 -
@@ -5570,15 +5583,7 @@ std::string llvm::UpgradeDataLayoutString(StringRef DL,
StringRef TT) {
if (!T.isX86())
return Res;
- // If the datalayout matches the expected format, add pointer size address
- // spaces to the datalayout.
- std::string AddrSpaces = "-p270:32
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/111879
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1774,6 +1795,54 @@ void AggExprEmitter::VisitCXXParenListOrInitListExpr(
}
}
}
+ if (ZeroInitPadding) {
+uint64_t TotalSize = CGF.getContext().toBits(
+Dest.getPreferredSize(CGF.getContext(), DestLV.getType()));
+DoZeroInitPadding(PaddingStart,
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/110051
___
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/110051
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
/cherry-pick 9bf68c2400e8966511332dfbf5c0f05e8a3300fa
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
https://github.com/efriedma-quic milestoned
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:
Please add a testcase (something similar to clang/test/Headers/ms-intrin.cpp,
but including intrin0.h instead of intrin.h, to catch obvious mistakes in the
header).
Not sure how you're actually hitting the error you reported; the clang header
directory should count as a s
@@ -548,6 +548,11 @@ Miscellaneous Clang Crashes Fixed
- Fixed internal assertion firing when a declaration in the implicit global
module is found through ADL. (GH#109879)
+Leaf Functions Do Not Retain FP Bug Fixed
+^
+
+- Fixed ``-fno
@@ -125,6 +125,11 @@ Changes to the ARM Backend
the required alignment space with a sequence of `0x0` bytes (the requested
fill value) rather than NOPs.
+* The default behavior for frame pointers in leaf functions has been updated.
When
+ `-fno-omit-frame-pointer` is spe
efriedma-quic wrote:
> I realize this is not the approach you had in mind, but it would at least be
> nice to hear the reasoning as to why something more elaborate would be
> preferred?
Manually writing addParamAttr markings doesn't scale; there's no easy way to
audit whether everything has b
efriedma-quic wrote:
The point of __counted_by is precisely to supplement the normal standard rules:
specifically, if you have counted_by, the size of the flexible array is
precisely the size specified by the attribute. Not whatever size is implied by
the access. Otherwise, it would be illeg
efriedma-quic wrote:
> Yeah so the problem is if you do `__builtin_dynamic_object_size(v, 0)`
>
> In that case it's a `DeclRefExpr`, a pointer, and an `LValue`.
Can you give a more complete example? I just tried the following, and I see an
lvaluetorvalue cast.
int f(const void *p) { return _
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/106353
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1906,6 +1906,36 @@ class Sema final : public SemaBase {
ActOnPragmaMSFunction(SourceLocation Loc,
const llvm::SmallVectorImpl &NoBuiltins);
+ /// A label from a C++ #pragma export, for a symbol that we
+ /// haven't seen the declaration for yet.
@@ -1273,6 +1273,168 @@ void
Sema::AddImplicitMSFunctionNoBuiltinAttr(FunctionDecl *FD) {
FD->addAttr(NoBuiltinAttr::CreateImplicit(Context, V.data(), V.size()));
}
+static bool typeListMatches(FunctionDecl *FD,
+const clang::Sema::SymbolLabel
@@ -0,0 +1,5 @@
+// REQUIRES: systemz-registered-target
efriedma-quic wrote:
Do these tests actually require systemz-registered-target?
https://github.com/llvm/llvm-project/pull/111035
___
cfe-commits mailing list
cfe-
@@ -5087,6 +5087,19 @@ Decl *Sema::ParsedFreeStandingDeclSpec(Scope *S,
AccessSpecifier AS,
assert(EllipsisLoc.isInvalid() &&
"Friend ellipsis but not friend-specified?");
+ if (DS.isExportSpecified()) {
+VisibilityAttr *existingAttr = TagD->getAttr();
+if
@@ -1906,6 +1906,36 @@ class Sema final : public SemaBase {
ActOnPragmaMSFunction(SourceLocation Loc,
const llvm::SmallVectorImpl &NoBuiltins);
+ /// A label from a C++ #pragma export, for a symbol that we
+ /// haven't seen the declaration for yet.
@@ -0,0 +1,345 @@
+; 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
https://github.com/efriedma-quic approved this pull request.
LGTM
(I can't come up with a case where it actually fails off the top of my head,
but for the sake of consistency, it probably makes sense.)
https://github.com/llvm/llvm-project/pull/111448
___
@@ -1095,6 +1095,8 @@ class StructAccessBase
return Visit(E->getBase());
}
const Expr *VisitCastExpr(const CastExpr *E) {
+if (E->getCastKind() == CK_LValueToRValue)
+ return E;
efriedma-quic wrote:
Should this be `return IsExpectedRecordDecl(
@@ -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
efriedma-quic wrote:
Consider the following testcase:
```
struct ConstEval {
consteval ConstEval(int) {}
};
struct SimpleCtor { constexpr SimpleCtor(int) {}};
struct TemplateCtor {
template constexpr
TemplateCtor (int arg) {}
};
struct ConstEvalMember1 : SimpleCtor {
int y = 10;
C
efriedma-quic wrote:
Can you add a testcase that doesn't involve lambdas? Maybe something like the
following:
```
inline void f(int) asm("foo");
inline void f(int) {}
inline void f() asm("foo");
inline void f(){}
```
https://github.com/llvm/llvm-project/pull/107581
___
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/107581
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1110,6 +1110,10 @@ static bool isTrivialForMSVC(const CXXRecordDecl *RD,
QualType Ty,
isa(Base)) {
return true;
}
+ if (CGM.getTarget().getTriple().isX86() &&
+ CGM.getABIInfo().isHomogeneousAggregate(Ty, Base, NumElts)) {
efriedma-quic w
@@ -115,3 +115,14 @@ namespace nested_union {
// of Test3, or we should exclude f(Test3) as a candidate.
static_assert(f({1}) == 2, ""); // expected-error {{call to 'f' is
ambiguous}}
}
+
+// Fix crash issue https://github.com/llvm/llvm-project/issues/112560.
+// Make sure
@@ -0,0 +1,338 @@
+// RUN: %clang_cc1 -O3 -triple aarch64
-target-feature +sve -target-feature +sve2p1 -mvscale-min=1 -mvscale-max=1
-emit-llvm -o - %s | FileCheck %s --check-prefixes=CHECK,CHECK-AAPCS
+// RUN: %clang_cc1 -O3 -triple arm64-apple-
@@ -0,0 +1,338 @@
+// RUN: %clang_cc1 -O3 -triple aarch64
-target-feature +sve -target-feature +sve2p1 -mvscale-min=1 -mvscale-max=1
-emit-llvm -o - %s | FileCheck %s --check-prefixes=CHECK,CHECK-AAPCS
+// RUN: %clang_cc1 -O3 -triple arm64-apple-
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/113186
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -439,6 +439,7 @@ Bug Fixes in This Version
- Fixed a crash when trying to transform a dependent address space type. Fixes
#GH101685.
- Fixed a crash when diagnosing format strings and encountering an empty
delimited escape sequence (e.g., ``"\o{}"``). #GH102218
+- Fixed a
https://github.com/efriedma-quic approved this pull request.
Please make the title of the pull request something more useful, like "[clang
codegen] fix crash emitting __array_rank". The current title is utterly
useless for someone looking through the commit history.
LGTM with comments address
efriedma-quic wrote:
My impression is that the treatment of address-spaces varies so much across
different languages and different targets that it doesn't make sense to encode
the entire address-space layout the datalayout. Narrowly encoding just the
specific properties optimizations need mea
efriedma-quic wrote:
Please push the revised clang tests as a separate patch.
This idea here makes sense, I guess, but I'm a little worried about unexpected
side-effects... not sure how reliably the backend handles commuted masks, and I
don't think we have any testing infrastructure that would
efriedma-quic wrote:
(For reference, this was reapplied in #110051.)
I'm not anticipating significant performance regressions here in normal usage:
all the bits that are getting initialized are padding adjacent to initialized
fields, so I expect the additional initialization will usually be fr
efriedma-quic wrote:
> the baseline code generation uses memset over the entire union when the size
> is large
That looks like an unintended side-effect of CheckAggExprForMemSetUse: it's
supposed to check how much of the initialization is non-zero, but it's assuming
all padding needs to be ze
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/112636
___
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/112636
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1013,6 +1013,24 @@ CodeGenFunction::emitFlexibleArrayMemberSize(const Expr
*E, unsigned Type,
// Can't find the field referenced by the "counted_by" attribute.
return nullptr;
+ if (isa(Base))
+// The whole struct is specificed in the __bdos. The calculation
@@ -1013,6 +1013,24 @@ CodeGenFunction::emitFlexibleArrayMemberSize(const Expr
*E, unsigned Type,
// Can't find the field referenced by the "counted_by" attribute.
return nullptr;
+ if (isa(Base))
efriedma-quic wrote:
I'm not sure this reliably dete
1101 - 1200 of 1826 matches
Mail list logo
