https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/72197
___
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:
Good to see this works without any unexpected side-effects.
Please also add a test for 32-byte alignment (since that generates different
code)
https://github.com/llvm/llvm-project/pull/72197
___
cfe-commits
@@ -307,7 +307,13 @@ AArch64ABIInfo::classifyArgumentType(QualType Ty, bool
IsVariadic,
// 0.
if (IsEmpty && Size == 0)
return ABIArgInfo::getIgnore();
-return ABIArgInfo::getDirect(llvm::Type::getInt8Ty(getVMContext()));
+// An empty struct can have size
efriedma-quic wrote:
I'll try describing it a different way.
There are two kinds of alignment. "ABI alignment" is required for the code to
function correctly (due to things like architecture constraints, reusing the
low bit for member pointers, binary patching). "Preferred alignment" is
addi
efriedma-quic wrote:
@DanielKristofKiss From your response, I gather you want AArch64 to align with
the other targets, but additional changes are required to make that work?
In the interest of keeping things moving, how do you want to stage this? Would
it make sense to land this as-is? Rhen
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/72452
___
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/72452
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1627,28 +1627,20 @@ const llvm::fltSemantics
&ASTContext::getFloatTypeSemantics(QualType T) const {
CharUnits ASTContext::getDeclAlign(const Decl *D, bool ForAlignof) const {
unsigned Align = Target->getCharWidth();
- bool UseAlignAttrOnly = false;
- if (unsigned Alig
@@ -307,7 +307,12 @@ AArch64ABIInfo::classifyArgumentType(QualType Ty, bool
IsVariadic,
// 0.
if (IsEmpty && Size == 0)
return ABIArgInfo::getIgnore();
-return ABIArgInfo::getDirect(llvm::Type::getInt8Ty(getVMContext()));
+// An empty struct can have size
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/72197
___
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/71677
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,722 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -mtriple aarch64-none-eabi < %s -verify-machineinstrs | FileCheck %s
+; RUN: llc -mtriple aarch64-none-eabi < %s -verify-machineinstrs -global-isel
-global-isel-abort=2 |
@@ -1076,6 +1076,16 @@ void CodeGenModule::Release() {
"sign-return-address-with-bkey", 1);
}
+ if (Arch == llvm::Triple::aarch64 || Arch == llvm::Triple::aarch64_be) {
+auto *InlineAsm = llvm::MDString::get(TheModule.getContext(),
"inli
@@ -1076,6 +1076,16 @@ void CodeGenModule::Release() {
"sign-return-address-with-bkey", 1);
}
+ if (Arch == llvm::Triple::aarch64 || Arch == llvm::Triple::aarch64_be) {
efriedma-quic wrote:
Module-level attributes tend to le
@@ -0,0 +1,363 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -mtriple aarch64-none-eabi < %s -verify-machineinstrs | FileCheck %s
+
+; Dynamically-sized allocation, needs a loop which can handle any size at
+; runtime. The final iter
efriedma-quic wrote:
Missing change to clang/docs/LanguageExtensions.rst describing the new builtins.
Are there any other projects that we might want to coordinate with here? gcc,
maybe?
https://github.com/llvm/llvm-project/pull/72280
___
cfe-commit
@@ -0,0 +1,32 @@
+// RUN: %clang --target=s390x-linux -S -emit-llvm -o - %s | FileCheck %s
efriedma-quic wrote:
Sorry, I missed this when reviewing.
We generally only use Driver tests when we're trying to test some aspect of the
driver. For arm-alignment.c, it
efriedma-quic wrote:
I think I'd prefer to avoid calling into ConstExprEmitter at all for cases
involving reference binding. I think we've sort of discussed this before.
Maybe add a check to tryEmitPrivate()? (We already have a check in
tryEmitPrivateForVarInit().)
https://github.com/llvm/
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/70366
___
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/68565
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -292,7 +292,42 @@ define void @ldr_with_off_16mulvl(ptr %ptr) {
%vscale = call i64 @llvm.vscale.i64()
%mulvl = mul i64 %vscale, 256
%base = getelementptr i8, ptr %ptr, i64 %mulvl
- call void @llvm.aarch64.sme.ldr(i32 16, ptr %base)
+ call void @llvm.aarch64.sme.ldr(i
https://github.com/efriedma-quic commented:
Could you briefly comment on the tradeoff of adding an argument to the
intrinsic, vs. pattern-matching constant offsets to the existing intrinsic?
https://github.com/llvm/llvm-project/pull/68565
___
cfe-comm
efriedma-quic wrote:
Also, you might want to consider marking the offset immarg, instead of trying
to handle variable offsets in isel.
https://github.com/llvm/llvm-project/pull/68565
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://list
efriedma-quic wrote:
I'm planning to take a closer look at this when I have more time. Sorry I
haven't been more responsive here.
One very brief note: in the comments in the code, you might want to distinguish
between the semantic width of a bitfield (i.e. the C standard notion of a
"memory
https://github.com/efriedma-quic commented:
The resulting code here still isn't great quality for the case where the
constant isn't folded. Maybe worth considering doing the lowering earlier
(DAGCombine? Maybe even a late IR optimization?), so the lowered arithmetic
can be optimized.
https:
@@ -1741,6 +1742,69 @@ void AArch64DAGToDAGISel::SelectCVTIntrinsic(SDNode *N,
unsigned NumVecs,
CurDAG->RemoveDeadNode(N);
}
+void AArch64DAGToDAGISel::SelectSMELdrStrZA(SDNode *N, bool IsLoad) {
+ // Lower an SME LDR/STR ZA intrinsic to LDR_ZA_PSEUDO or STR_ZA.
+ // If
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/68565
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
Is there some reason stack protectors don't make sense on GPU targets? Or is
the issue just that the GPU targets in question don't have the necessary
runtime support?
https://github.com/llvm/llvm-project/pull/70799
___
cfe-commi
@@ -265,6 +269,63 @@ bool AIXTargetCodeGenInfo::initDwarfEHRegSizeTable(
return PPC_initDwarfEHRegSizeTable(CGF, Address, Is64Bit, /*IsAIX*/ true);
}
+void AIXTargetCodeGenInfo::setTargetAttributes(
+const Decl *D, llvm::GlobalValue *GV, CodeGen::CodeGenModule &M) const
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/67999
___
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:
What are the ABI implications here? Do all translation units have to agree on
whether a variable is "tocdata"? The manual change hints there's some sort of
linker fixup, but it's not clear to me how that works.
Specifying the names of global variab
@@ -622,6 +622,28 @@ static bool checkAliasedGlobal(
return true;
}
+// Emit a warning if toc-data attribute is requested for global variables that
+// have aliases and remove the toc-data attribute.
+static void checkAliasForTocData(llvm::GlobalVariable *GVar,
+
efriedma-quic wrote:
The new option in CodeGenOptions.h seems fine.
If your goal is to statically inject passes into the clang executable, I don't
understand why the existing LLVM plugin infrastructure isn't sufficient for
your needs. You mention "modifying Extension.def", but that file is ge
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/66716
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
(Not sure if you have commit access; let me know if you want me to merge for
you.)
https://github.com/llvm/llvm-project/pull/66716
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/list
efriedma-quic wrote:
Do you need to check if the lambda is templated? For example, the following
doesn't compile:
```
auto GetNonCapturingLambda() { return [](){ return 42; }; }
auto f() { return GetNonCapturingLambda() == GetNonCapturingLambda(); }
```
https://github.com/llvm/llvm-project/pu
efriedma-quic wrote:
It should be possible to statically link a pass plugin without modifying any
LLVM/clang build files. polly uses this infrastructure. (polly is actually
referenced explicitly in a couple places, but only to pull it into the build in
the first place; you can do something e
@@ -976,6 +976,37 @@ void CodeGenModule::Release() {
Context.getTypeSizeInChars(Context.getWideCharType()).getQuantity();
getModule().addModuleFlag(llvm::Module::Error, "wchar_size", WCharWidth);
+ if (getTriple().isOSzOS()) {
+getModule().addModuleFlag(llvm::Modu
@@ -976,6 +976,37 @@ void CodeGenModule::Release() {
Context.getTypeSizeInChars(Context.getWideCharType()).getQuantity();
getModule().addModuleFlag(llvm::Module::Error, "wchar_size", WCharWidth);
+ if (getTriple().isOSzOS()) {
+getModule().addModuleFlag(llvm::Modu
@@ -4022,8 +4169,36 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const
ArraySubscriptExpr *E,
ArrayLV = EmitArraySubscriptExpr(ASE, /*Accessed*/ true);
else
ArrayLV = EmitLValue(Array);
+
auto *Idx = EmitIdxAfterBase(/*Promote*/true);
+if (SanOp
efriedma-quic wrote:
How hard is it to fix the backend to handle this properly? We should already
have support for other libcalls, I think. I'd like to avoid adding temporary
hacks to clang.
https://github.com/llvm/llvm-project/pull/75226
___
cfe-c
@@ -4022,8 +4169,36 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const
ArraySubscriptExpr *E,
ArrayLV = EmitArraySubscriptExpr(ASE, /*Accessed*/ true);
else
ArrayLV = EmitLValue(Array);
+
auto *Idx = EmitIdxAfterBase(/*Promote*/true);
+if (SanOp
@@ -740,3 +1058,589 @@ void test10(struct union_of_fams *p, int index) {
void test11(struct annotated *p, int index) {
p->array[index] = __builtin_dynamic_object_size(&p->count, 1);
}
+
+// SANITIZE-WITH-ATTR-LABEL: define dso_local i64 @test11_bdos(
+// SANITIZE-WITH-ATTR-SA
@@ -860,7 +867,25 @@ static void runIslScheduleOptimizer(
SC = SC.set_proximity(Proximity);
SC = SC.set_validity(Validity);
SC = SC.set_coincidence(Validity);
+
+// Save error handling behavior
+long MaxOperations = isl_ctx_get_max_operations(Ctx);
+isl_
@@ -860,7 +867,25 @@ static void runIslScheduleOptimizer(
SC = SC.set_proximity(Proximity);
SC = SC.set_validity(Validity);
SC = SC.set_coincidence(Validity);
+
+// Save error handling behavior
efriedma-quic wrote:
Would it be possible to use t
@@ -4022,8 +4169,36 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const
ArraySubscriptExpr *E,
ArrayLV = EmitArraySubscriptExpr(ASE, /*Accessed*/ true);
else
ArrayLV = EmitLValue(Array);
+
auto *Idx = EmitIdxAfterBase(/*Promote*/true);
+if (SanOp
@@ -1759,20 +1759,29 @@ void
CodeGenFunction::emitZeroOrPatternForAutoVarInit(QualType type,
const VarDecl &D,
Address Loc) {
auto trivialAutoVarInit = getContext().ge
@@ -4022,8 +4169,36 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const
ArraySubscriptExpr *E,
ArrayLV = EmitArraySubscriptExpr(ASE, /*Accessed*/ true);
else
ArrayLV = EmitLValue(Array);
+
auto *Idx = EmitIdxAfterBase(/*Promote*/true);
+if (SanOp
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/75226
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -149,6 +153,11 @@ llvm::Constant *CodeGenModule::getBuiltinLibFunction(const
FunctionDecl *FD,
&getTarget().getLongDoubleFormat() == &llvm::APFloat::IEEEquad() &&
F128Builtins.contains(BuiltinID))
Name = F128Builtins[BuiltinID];
+else if (getTriple
@@ -3410,9 +3419,15 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl
GD, unsigned BuiltinID,
{ Src0->getType(), Src1->getType() });
return RValue::get(Builder.CreateCall(F, { Src0, Src1 }));
}
+ case Builtin::BI__builtin_fre
https://github.com/efriedma-quic commented:
If the PPC backend maintainers intend to deprecate ppc-long-double support in
LLVM, I guess we can hack clang to limp along until the cut happens.
https://github.com/llvm/llvm-project/pull/75226
___
cfe-comm
efriedma-quic wrote:
Adding workarounds to LLVM for host compiler bugs is something we do from time
to time, but any such workarounds need to be clearly documented in the source
code, and as narrowly targeted as possible (for example, under an `#ifdef
__CYGWIN__`).
Since this is an issue with
@@ -1422,6 +1424,9 @@ Value *ScalarExprEmitter::EmitScalarConversion(Value
*Src, QualType SrcType,
return Builder.CreateVectorSplat(NumElements, Src, "splat");
}
+ if (SrcType->isExtVectorType() && DstType->isExtVectorType())
+return EmitVectorElementConversion(Src
@@ -232,19 +232,19 @@ static Value *MakeBinaryAtomicValue(
static Value *EmitNontemporalStore(CodeGenFunction &CGF, const CallExpr *E) {
Value *Val = CGF.EmitScalarExpr(E->getArg(0));
- Value *Address = CGF.EmitScalarExpr(E->getArg(1));
+ Address Addr = CGF.EmitPointerWith
https://github.com/efriedma-quic updated
https://github.com/llvm/llvm-project/pull/74790
>From 476402a90cc24a5697efbef0b3bcb1276a4bc6f5 Mon Sep 17 00:00:00 2001
From: Eli Friedman
Date: Thu, 7 Dec 2023 16:21:53 -0800
Subject: [PATCH] [clang][Driver] Support -fms-volatile as equivalent to
/vola
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/74790
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
The isl_options_set_on_error thing still seems like an issue; there's a path to
restore on_error, but it doesn't run if the quota is hit.
Do we actually need to explicitly check hasQuotaExceeded() at all? If there's
an error, the schedule should be null, and there's alrea
efriedma-quic wrote:
Scattering around `setDSOLocal(false)` makes the logic hard to understand. I'd
strongly prefer to fix the initial setting of dso_local when we create the
global variable. We can refactor the code to make that work.
https://github.com/llvm/llvm-project/pull/75564
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/75226
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
> > Making Sema pull the TBAA info out of clang/lib/CodeGen is a layering
> > violation (and probably breaks if we aren't actually generating code). If
> > we need some notion of "aliasing" in Sema, we should pull the relevant code
> > into clang/lib/AST.
>
> That's unfor
efriedma-quic wrote:
It doesn't seem like a good idea to make target-independent logic behave in
target-specific ways; that's going to confusing for both people hacking on
clang, and for users if it's user-visible. Is there some way we can make this
logic consistent across targets?
Maybe we
@@ -418,6 +418,8 @@ void BackendConsumer::anchor() { }
} // namespace clang
bool ClangDiagnosticHandler::handleDiagnostics(const DiagnosticInfo &DI) {
+ if (DI.getSeverity() == DS_Error)
+HasErrors = true;
efriedma-quic wrote:
I'm not sure I like the way
efriedma-quic wrote:
Please fix the pull request description to say this is aarch64-specific.
Missing regression test in clang/test/CodeGen/
How does this interact with #72197?
https://github.com/llvm/llvm-project/pull/72624
___
cfe-commits mailing l
@@ -1687,7 +1687,8 @@ CharUnits ASTContext::getDeclAlign(const Decl *D, bool
ForAlignof) const {
if (VD->hasGlobalStorage() && !ForAlignof) {
uint64_t TypeSize =
!BaseT->isIncompleteType() ? getTypeSize(T.getTypePtr()) : 0;
-Align = std::max(A
efriedma-quic wrote:
CodeGenFunction::FindCountedByField finds a field with a corresponding base
expression. Currently, it throws away the base expression. And the code
you've just written tries to recompute the base. Instead of doing this dance,
can we just make CodeGenFunction::FindCounte
efriedma-quic wrote:
I'd like to see a few tests involving multiple arrows in the same expression.
(If my understanding is correct, you want to cut the recursion when you see an
arrow member.)
Looking at the code again, I guess FindCountedByField doesn't explicitly
compute the base expressio
efriedma-quic wrote:
Some examples to consider:
```
// Crazy array indexing... but strictly speaking, legal.
struct S { int count; int arr[] __attribute((counted_by(count))); };
int f1(int c, struct S *var) {
return var[10].arr[10];
}
// Double dereferenced variable.
int f2(int c, struct S **v
efriedma-quic wrote:
The concept makes sense, but I think the code should be inside
CodeGenModule::GetAddrOfTemplateParamObject? I think all users of the function
want a value in the correct address-space.
https://github.com/llvm/llvm-project/pull/69266
___
efriedma-quic wrote:
As a historical note, when I first wrote the support for atomics, it was under
a model where LLVM IR only modeled legal atomics, and clang lowered illegal
atomics to libcalls. This was changed a few years later to generalize atomics
in LLVM IR to support arbitrary atomic
https://github.com/efriedma-quic approved this pull request.
LGTM
See
https://llvm.org/docs/CodingStandards.html#don-t-use-braces-on-simple-single-statement-bodies-of-if-else-loop-statements
for the rules on use/don't use braces. A single multi-line statement is sort
of on the edge; I tend t
https://github.com/efriedma-quic approved this pull request.
LGTM with one minor comment
https://github.com/llvm/llvm-project/pull/73264
___
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/73264
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -418,14 +418,20 @@ llvm::MDNode *CodeGenTBAA::getBaseTypeInfo(QualType QTy) {
return nullptr;
const Type *Ty = Context.getCanonicalType(QTy).getTypePtr();
- if (llvm::MDNode *N = BaseTypeMetadataCache[Ty])
-return N;
- // Note that the following helper call is
efriedma-quic wrote:
I agree users probably shouldn't be doing that... but given it compiles your
code should handle it gracefully. (It should just be a matter of making sure
you don't recurse too deeply through the "base".)
https://github.com/llvm/llvm-project/pull/73730
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/66716
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -956,42 +958,112 @@ static llvm::Value
*getArrayIndexingBound(CodeGenFunction &CGF,
return nullptr;
}
-const Expr *
-CodeGenFunction::BuildCountedByFieldExpr(const Expr *Base,
- const ValueDecl *CountedByVD) {
+namespace {
+
+/// \
@@ -956,42 +958,112 @@ static llvm::Value
*getArrayIndexingBound(CodeGenFunction &CGF,
return nullptr;
}
-const Expr *
-CodeGenFunction::BuildCountedByFieldExpr(const Expr *Base,
- const ValueDecl *CountedByVD) {
+namespace {
+
+/// \
@@ -956,42 +958,112 @@ static llvm::Value
*getArrayIndexingBound(CodeGenFunction &CGF,
return nullptr;
}
-const Expr *
-CodeGenFunction::BuildCountedByFieldExpr(const Expr *Base,
- const ValueDecl *CountedByVD) {
+namespace {
+
+/// \
@@ -956,42 +958,112 @@ static llvm::Value
*getArrayIndexingBound(CodeGenFunction &CGF,
return nullptr;
}
-const Expr *
-CodeGenFunction::BuildCountedByFieldExpr(const Expr *Base,
- const ValueDecl *CountedByVD) {
+namespace {
+
+/// \
efriedma-quic wrote:
My primary concerns here are:
- It being likely these builtins will be superseded by something else once
someone else tries to standardize this. Maybe this isn't a big deal... but
maybe we want to choose names that are less likely to overlap with stuff anyone
else is doin
https://github.com/efriedma-quic approved this pull request.
LGTM
In terms of va_list etc., we first need to make sure calls are correct (compare
against gcc etc.), then we need to make sure va_list is consistent with that.
https://github.com/llvm/llvm-project/pull/72197
__
efriedma-quic wrote:
When I said "inconsistencies", I just meant the way the responsibility for
lowering atomics is split between LLVM and clang; I didn't mean anything was
actually broken.
https://github.com/llvm/llvm-project/pull/73176
___
cfe-comm
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/75141
___
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/75141
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
Please add test coverage for compound assignment and increment/decrement.
This seems like a reasonable extension of the existing integer truncation
checks, but we might want to consider giving it a unique name. Otherwise,
people using integer truncation checks will have t
efriedma-quic wrote:
Pushed revert.
@kartcq please fix the test so it either doesn't depend on DEBUG output, or
uses `REQUIRES: asserts`.
https://github.com/llvm/llvm-project/pull/75141
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://
efriedma-quic wrote:
This is basically the approach I was expecting: we check the type of "long
double" when we build the TargetLowering, and pick appropriate names based on
that.
I expect that for -mlong-double-128, you just want to add a module flag that
overrides the default choice.
I thi
efriedma-quic wrote:
Have you considered the following case?
```
void foo() {
char* arr = new char[]("asdf");
}
```
https://github.com/llvm/llvm-project/pull/76976
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/
@@ -5495,14 +5495,12 @@ static void TryOrBuildParenListInitialization(
return;
}
// ...and value-initialized for each k < i <= n;
-if (ArrayLength > Args.size()) {
efriedma-quic wrote:
What is this change supposed to do?
The existing cod
@@ -1038,11 +1038,14 @@ void CodeGenFunction::EmitNewArrayInitializer(
return true;
};
+ const InitListExpr *ILE = dyn_cast(Init);
+ const CXXParenListInitExpr *CPLIE = dyn_cast(Init);
+ const StringLiteral *SL = dyn_cast(Init);
// If the initializer is an initiali
Author: Eli Friedman
Date: 2021-07-26T11:59:40-07:00
New Revision: 0fb16d5ad126a14213ceee6b20b86c721ea49d4e
URL:
https://github.com/llvm/llvm-project/commit/0fb16d5ad126a14213ceee6b20b86c721ea49d4e
DIFF:
https://github.com/llvm/llvm-project/commit/0fb16d5ad126a14213ceee6b20b86c721ea49d4e.diff
Author: Eli Friedman
Date: 2022-03-10T14:49:16-08:00
New Revision: 27a574962567224d3a36a70cf8abf0ad3d751ec5
URL:
https://github.com/llvm/llvm-project/commit/27a574962567224d3a36a70cf8abf0ad3d751ec5
DIFF:
https://github.com/llvm/llvm-project/commit/27a574962567224d3a36a70cf8abf0ad3d751ec5.diff
Author: Eli Friedman
Date: 2022-03-15T11:58:40-07:00
New Revision: 5791e28f30168a5a930c1f869529b03b95405afe
URL:
https://github.com/llvm/llvm-project/commit/5791e28f30168a5a930c1f869529b03b95405afe
DIFF:
https://github.com/llvm/llvm-project/commit/5791e28f30168a5a930c1f869529b03b95405afe.diff
Author: Eli Friedman
Date: 2022-03-16T16:18:51-07:00
New Revision: 04ba344176b239c0abc0c9efc8b7524e551e58ed
URL:
https://github.com/llvm/llvm-project/commit/04ba344176b239c0abc0c9efc8b7524e551e58ed
DIFF:
https://github.com/llvm/llvm-project/commit/04ba344176b239c0abc0c9efc8b7524e551e58ed.diff
Author: Eli Friedman
Date: 2022-04-13T12:34:57-07:00
New Revision: d791de0e25e13cd8ae066e6f0fa03b384502b02e
URL:
https://github.com/llvm/llvm-project/commit/d791de0e25e13cd8ae066e6f0fa03b384502b02e
DIFF:
https://github.com/llvm/llvm-project/commit/d791de0e25e13cd8ae066e6f0fa03b384502b02e.diff
Author: Eli Friedman
Date: 2022-04-14T11:56:40-07:00
New Revision: 5955a0f9375a8c0b134eeb4a8de5155dcce7c94f
URL:
https://github.com/llvm/llvm-project/commit/5955a0f9375a8c0b134eeb4a8de5155dcce7c94f
DIFF:
https://github.com/llvm/llvm-project/commit/5955a0f9375a8c0b134eeb4a8de5155dcce7c94f.diff
Author: Eli Friedman
Date: 2022-04-14T13:58:17-07:00
New Revision: 6cf0b1b3da3e8662baf030a2d741e3becaaab2b0
URL:
https://github.com/llvm/llvm-project/commit/6cf0b1b3da3e8662baf030a2d741e3becaaab2b0
DIFF:
https://github.com/llvm/llvm-project/commit/6cf0b1b3da3e8662baf030a2d741e3becaaab2b0.diff
Author: Eli Friedman
Date: 2022-04-15T12:09:57-07:00
New Revision: 4802edd1ac7a5aea8c8488b5baec221d722cbdde
URL:
https://github.com/llvm/llvm-project/commit/4802edd1ac7a5aea8c8488b5baec221d722cbdde
DIFF:
https://github.com/llvm/llvm-project/commit/4802edd1ac7a5aea8c8488b5baec221d722cbdde.diff
Author: Eli Friedman
Date: 2022-04-20T11:30:11-07:00
New Revision: ecc8479a01d3bee1c145a0f7990271651db72ab0
URL:
https://github.com/llvm/llvm-project/commit/ecc8479a01d3bee1c145a0f7990271651db72ab0
DIFF:
https://github.com/llvm/llvm-project/commit/ecc8479a01d3bee1c145a0f7990271651db72ab0.diff
101 - 200 of 2033 matches
Mail list logo
