https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/82968
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -10737,6 +10752,43 @@ SDValue
PPCTargetLowering::LowerINTRINSIC_WO_CHAIN(SDValue Op,
return DAG.getRegister(PPC::X13, MVT::i64);
return DAG.getRegister(PPC::R2, MVT::i32);
+ case Intrinsic::ppc_rldimi: {
+uint64_t SH = Op.getConstantOperandVal(3);
+unsig
https://github.com/efriedma-quic commented:
If you run into issues using normal integer ops, please file bugs. Most people
aren't going to hand-tune their code like this; builtins like this are at best
an ugly workaround.
That said, I guess I'm not strongly against adding a backdoor to force
efriedma-quic wrote:
Oh, I should have caught that when reviewing. (I thought I checked the test
was doing the right thing when I looked at it, but I guess I'm misremembering.)
Probably need to mark the intrinsic CustomTypeChecking, then make the code in
SemaChecking explicitly perform lvalue
https://github.com/efriedma-quic commented:
Whitespace is weird in a few places; otherwise looks fine.
https://github.com/llvm/llvm-project/pull/82922
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listin
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/82922
___
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/83313
___
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/83313
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -662,6 +662,12 @@ def Clz : Builtin, BitShort_Int_Long_LongLongTemplate {
// FIXME: Add int clzimax(uintmax_t)
efriedma-quic wrote:
Probably; it's unlikely we're going to add them at this point.
https://github.com/llvm/llvm-project/pull/83431
_
@@ -2212,6 +2212,54 @@ static bool SemaBuiltinPopcountg(Sema &S, CallExpr
*TheCall) {
return false;
}
+/// Checks that __builtin_{clzg,ctzg} was called with a first argument, which
is
+/// an unsigned integer, and an optional second argument, which is promoted to
+/// an '
@@ -3157,7 +3177,15 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl
GD, unsigned BuiltinID,
if (Result->getType() != ResultType)
efriedma-quic wrote:
Not sure if the way this is handling isCLZForZeroUndef() is what you want?
https://github.com/
@@ -3157,7 +3177,15 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl
GD, unsigned BuiltinID,
if (Result->getType() != ResultType)
efriedma-quic wrote:
I was more thinking of the opposite: we don't need to make the result of the
clz defined if we
@@ -394,33 +412,155 @@ void CGRecordLowering::accumulateFields() {
: getStorageType(*Field),
*Field));
++Field;
-} else {
- ++Field;
}
}
}
-void
-CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
-
@@ -700,10 +700,13 @@ class MSBuiltin {
//===--- Variable Argument Handling Intrinsics
===//
//
-def int_vastart : DefaultAttrsIntrinsic<[], [llvm_ptr_ty], [],
"llvm.va_start">;
-def int_vacopy : DefaultAttrsIntrinsic<[], [llvm_ptr_ty, llvm_ptr_t
efriedma-quic wrote:
gcc uses memory, and the ABI standard doesn't explicitly contradict it, so
let's just go with that.
https://github.com/llvm/llvm-project/pull/85394
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi
@@ -1069,6 +1069,10 @@ Address X86_32ABIInfo::EmitVAArg(CodeGenFunction &CGF,
auto TypeInfo = getContext().getTypeInfoInChars(Ty);
+ // Empty records are ignored for parameter passing purposes on non-Windows.
+ if (!IsWin32StructABI && isEmptyRecord(getContext(), Ty, true
https://github.com/efriedma-quic requested changes to this pull request.
If you read the code, it should be obvious the pointer is in fact non-null.
Please don't insert null checks into the code just to address static analyzer
false positives.
https://github.com/llvm/llvm-project/pull/86018
_
@@ -1069,6 +1069,10 @@ Address X86_32ABIInfo::EmitVAArg(CodeGenFunction &CGF,
auto TypeInfo = getContext().getTypeInfoInChars(Ty);
+ // Empty records are ignored for parameter passing purposes on non-Windows.
+ if (!IsWin32StructABI && isEmptyRecord(getContext(), Ty, true
@@ -21,3 +21,18 @@ empty empty_record_test(int z, ...) {
__builtin_va_start(list, z);
return __builtin_va_arg(list, empty);
}
+
efriedma-quic wrote:
Please regenerate the CHECK lines with update_cc_test_checks.py.
https://github.com/llvm/llvm-project/pull
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/86377
___
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/86377
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,69 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
UTC_ARGS: --version 4
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm -o - %s | FileCheck %s
+
+
+typedef struct { struct {} a; } empty;
+
+// CHECK-LABEL: define dso_local voi
efriedma-quic wrote:
(This overlaps with #86075, so I'm going to hold off on reviewing this for now.)
https://github.com/llvm/llvm-project/pull/86388
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinf
@@ -3182,34 +3182,98 @@ class ArrayType : public Type, public
llvm::FoldingSetNode {
/// For example, the canonical type for 'int A[4 + 4*100]' is a
/// ConstantArrayType where the element type is 'int' and the size is 404.
class ConstantArrayType final
-: public ArrayType
@@ -3182,34 +3182,100 @@ class ArrayType : public Type, public
llvm::FoldingSetNode {
/// For example, the canonical type for 'int A[4 + 4*100]' is a
/// ConstantArrayType where the element type is 'int' and the size is 404.
class ConstantArrayType final
-: public ArrayTyp
@@ -3182,34 +3182,100 @@ class ArrayType : public Type, public
llvm::FoldingSetNode {
/// For example, the canonical type for 'int A[4 + 4*100]' is a
/// ConstantArrayType where the element type is 'int' and the size is 404.
class ConstantArrayType final
-: public ArrayTyp
@@ -3182,34 +3182,100 @@ class ArrayType : public Type, public
llvm::FoldingSetNode {
/// For example, the canonical type for 'int A[4 + 4*100]' is a
/// ConstantArrayType where the element type is 'int' and the size is 404.
class ConstantArrayType final
-: public ArrayTyp
efriedma-quic wrote:
If you implement #86075 like I suggested, the inconsistency here also goes
away, I think: if va_arg queries classifyArgumentType, you get the same result
as argument lowering, so clang becomes self-consistent. (Whether that's
gcc-compatible is a different question...)
ht
efriedma-quic wrote:
Instead of Expr::mayBranchOut, I'd prefer to just unconditionally create the
alloca, then delete it later if it turns out we didn't actually need to emit
the branch. Trying to explicitly compute whether there's a branch out seems
both difficult, and potentially costly for
efriedma-quic wrote:
If we do keep mayBranchOut(), "asm goto" should also be added to the list of
expressions that can branch out. (I think JumpDiagnostics currently forbids
actually branching out in cases that would require a cleanup, but better to be
defensive here.)
https://github.com/llv
efriedma-quic wrote:
Adding attributes to types as type sugar (not part of the canonical type) is
generally problematic: non-canonical types are not reliably preserved
throughout the compiler, particularly in cases involving templates.
Can we use a type qualifier here?
https://github.com/llvm
@@ -12354,21 +12354,31 @@ bool IntExprEvaluator::VisitBuiltinCallExpr(const
CallExpr *E,
case Builtin::BI__builtin_clzl:
case Builtin::BI__builtin_clzll:
case Builtin::BI__builtin_clzs:
+ case Builtin::BI__builtin_clzg:
case Builtin::BI__lzcnt16: // Microsoft variant
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/86742
___
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 one thing I'm worried about here is the possibility that a future C
standard version standardizes a similar extension, but with different semantics
(since we're not using any reserved keywords here). Like I mentioned before
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/75481
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
arm64x isn't really a "target" in the sense that you can build code for it.
When you're building a C file, it's either arm64, or arm64ec; it can't be
"arm64x". arm64x is just a library format that combines an arm64 library with
an arm64ec library.
So I'm tempted to say
efriedma-quic wrote:
> > Instead of Expr::mayBranchOut, I'd prefer to just unconditionally create
> > the alloca, then delete it later if it turns out we didn't actually need to
> > emit the branch.
>
> I had earlier tried tracking instructions auxiliary to a particular cleanup
> in #83224
>
@@ -2177,7 +2177,8 @@ struct CounterCoverageMappingBuilder
}
void VisitOpaqueValueExpr(const OpaqueValueExpr* OVE) {
-Visit(OVE->getSourceExpr());
+if (const Expr *SE = OVE->getSourceExpr())
efriedma-quic wrote:
I suspect the correct check here is
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -mllvm -emptyline-comment-coverage=false
-fprofile-instrument=clang -fcoverage-mapping -dump-coverage-mapping
-emit-llvm-only -main-file-name templates.cpp %s | FileCheck %s
+// RUN: %clang_cc1 -std=c++20 -mllvm -emptyline-comment-coverage=fal
efriedma-quic wrote:
Because we're dealing specifically with integers, which are a pretty limited
class, you could consider introducing new types into the type system instead.
Similar to how ext_vector_type works. That's maybe easier than qualifiers in
the sense that the code already deals w
efriedma-quic wrote:
Is this patch ready to merge?
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/86835
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
If you think the coroutine codegen thing is something that needs to be
addressed in a followup, can you open a bug for it?
https://github.com/llvm/llvm-project/pull/86923
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
htt
efriedma-quic wrote:
I assume the FIXME is referring to some deeper change here? If it were that
easy, the FIXME wouldn't be there in the first place.
CC @zygoloid @rjmccall
https://github.com/llvm/llvm-project/pull/85541
___
cfe-commits mailing list
efriedma-quic wrote:
https://github.com/llvm/llvm-project/blob/c0f8be4fcfb725d53841d4b17a68685e2a79/clang/lib/CodeGen/CGExpr.cpp#L277
https://github.com/llvm/llvm-project/pull/85541
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://li
efriedma-quic wrote:
As far as I can tell, the code in question only actually runs for 32-bit x86
targets (it's tied to the old ABI, which was replaced on newer targets). So
there's no point to modifying it.
https://github.com/llvm/llvm-project/pull/85481
_
@@ -2331,6 +2332,11 @@ void CodeGenFunction::EmitVariablyModifiedType(QualType
type) {
type = cast(ty)->getPointeeType();
break;
+case Type::ArrayParameter:
efriedma-quic wrote:
Can we just use the existing "case" for ConstantArray?
https://
@@ -10926,6 +10965,10 @@ QualType ASTContext::mergeTypes(QualType LHS, QualType
RHS, bool OfBlockPointer,
assert(LHS != RHS &&
"Equivalent pipe types should have already been handled!");
return {};
+ case Type::ArrayParameter:
+assert(LHS != RHS &&
+
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/79382
___
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/86742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1105,19 +1105,24 @@ void CodeGenFunction::EmitNewArrayInitializer(
}
// Enter a partial-destruction Cleanup if necessary.
-if (needsEHCleanup(DtorKind)) {
+if (DtorKind) {
+ AllocaTrackerRAII AllocaTracker(*this);
efriedma-quic wrote:
@@ -266,6 +269,54 @@ class alignas(8) EHCleanupScope : public EHScope {
};
mutable struct ExtInfo *ExtInfo;
+ /// Erases auxillary allocas and their usages for an unused cleanup.
+ /// Cleanups should mark these allocas as 'used' if the cleanup is
+ /// emitted, otherwi
@@ -1,4 +1,5 @@
// RUN: %clang_cc1 %s -triple=x86_64-apple-darwin10 -emit-llvm -o - |
FileCheck %s
+// RUN: %clang_cc1 %s -triple=x86_64-pc-linux-gnu -emit-llvm -o - | FileCheck
%s
efriedma-quic wrote:
Not sure we need the new RUN line? There shouldn't be any
efriedma-quic wrote:
Try rebasing your patch? If you're unlucky, you might have based your patch on
a bad revision of main (and the buildbot just uses your branch as-is).
https://github.com/llvm/llvm-project/pull/86902
___
cfe-commits mailing list
cf
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/86075
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
(Please fix the formatting issue before merging)
https://github.com/llvm/llvm-project/pull/86075
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -6135,6 +6137,79 @@ processImplicitMapsWithDefaultMappers(Sema &S,
DSAStackTy *Stack,
}
}
+namespace {
+/// A 'teams loop' with a nested 'loop bind(parallel)' or generic function
+/// call in the associated loop-nest cannot be a 'parallel for'.
+class TeamsLoopChecker fi
efriedma-quic wrote:
We can't just skip compiling part of the code because it's infinite recursion.
It's not clear to me there's really a bug here to solve. Maybe the compiler
can detect simple cases of infinite recursion and print a warning.
https://github.com/llvm/llvm-project/pull/87310
__
efriedma-quic wrote:
If you don't like the current rules, you can ask the C++ standard committee to
change them. (See https://isocpp.org/std/submit-issue .)
https://github.com/llvm/llvm-project/pull/87310
___
cfe-commits mailing list
cfe-commits@list
https://github.com/efriedma-quic created
https://github.com/llvm/llvm-project/pull/87717
intrin.h checks for x86_64. But the "x86_64" define is also defined for
ARM64EC, and we don't support all the intrinsics in ARM64EC mode. Fix the
preprocessor checks to handle this correctly. (If we actua
efriedma-quic wrote:
CC @bylaws @mstorsjo @cjacek @MaxEW707 @CaseyCarter
https://github.com/llvm/llvm-project/pull/87717
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/efriedma-quic created
https://github.com/llvm/llvm-project/pull/87725
MSVC doesn't support generating __vectorcall calls in Arm64EC mode, but it does
treat it as a distinct type. The Microsoft STL depends on this functionality.
(Not sure if this is intentional.) Add suppo
efriedma-quic wrote:
CC @bylaws @mstorsjo @cjacek @MaxEW707 @CaseyCarter
https://github.com/llvm/llvm-project/pull/87725
___
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/87717
>From f18163b82b61f843f57c9c5e7e1dde24877f7210 Mon Sep 17 00:00:00 2001
From: Eli Friedman
Date: Thu, 4 Apr 2024 14:25:36 -0700
Subject: [PATCH] [ARM64EC] Fix compilation of intrin.h in ARM64EC mode.
intri
https://github.com/efriedma-quic updated
https://github.com/llvm/llvm-project/pull/87717
>From f18163b82b61f843f57c9c5e7e1dde24877f7210 Mon Sep 17 00:00:00 2001
From: Eli Friedman
Date: Thu, 4 Apr 2024 14:25:36 -0700
Subject: [PATCH 1/2] [ARM64EC] Fix compilation of intrin.h in ARM64EC mode.
i
@@ -413,6 +413,7 @@ static __inline__ void __DEFAULT_FN_ATTRS
__writecr3(unsigned __INTPTR_TYPE__ __cr3_val) {
__asm__ ("mov {%0, %%cr3|cr3, %0}" : : "r"(__cr3_val) : "memory");
}
+#endif
efriedma-quic wrote:
That chunk of declarations near the top of the fi
@@ -6135,6 +6137,79 @@ processImplicitMapsWithDefaultMappers(Sema &S,
DSAStackTy *Stack,
}
}
+namespace {
+/// A 'teams loop' with a nested 'loop bind(parallel)' or generic function
+/// call in the associated loop-nest cannot be a 'parallel for'.
+class TeamsLoopChecker fi
@@ -2100,8 +2100,12 @@ void X86_64ABIInfo::classify(QualType Ty, uint64_t
OffsetBase, Class &Lo,
postMerge(Size, Lo, Hi);
return;
}
+
+ bool InMemory = Offset % getContext().getTypeAlign(i->getType()) ||
+ (i->getType()->getAs()
@@ -1230,11 +1230,26 @@ CodeGenFunction::EmitCXXForRangeStmt(const
CXXForRangeStmt &S,
JumpDest LoopExit = getJumpDestInCurrentScope("for.end");
LexicalScope ForScope(*this, S.getSourceRange());
+ const DeclStmt *RangeDS = cast(S.getRangeStmt());
+ const VarDecl *RangeV
@@ -311,9 +311,9 @@ pushTemporaryCleanup(CodeGenFunction &CGF, const
MaterializeTemporaryExpr *M,
CleanupKind CleanupKind;
if (Lifetime == Qualifiers::OCL_Strong) {
const ValueDecl *VD = M->getExtendingDecl();
- bool Precise =
-
https://github.com/efriedma-quic created
https://github.com/llvm/llvm-project/pull/88019
This reverts commit e770153865c53c4fd72a68f23acff33c24e42a08.
This wasn't reviewed, and the functionality in question was intentionally
rejected the last time it was discussed in https://reviews.llvm.org/D
@@ -1230,11 +1230,26 @@ CodeGenFunction::EmitCXXForRangeStmt(const
CXXForRangeStmt &S,
JumpDest LoopExit = getJumpDestInCurrentScope("for.end");
LexicalScope ForScope(*this, S.getSourceRange());
+ const DeclStmt *RangeDS = cast(S.getRangeStmt());
+ const VarDecl *RangeV
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/87717
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
I'd suggest adding bitcode upgrade if it isn't too hard (I don't think it
should be?)
Otherwise looks fine.
https://github.com/llvm/llvm-project/pull/87906
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llv
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/88019
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
Given there isn't any target-independent way to construct such a type, it feels
sort of redundant. (A user could easily implement this themselves.) But I
can't think of a reason to avoid adding this.
Please update documentation and add a release note.
https://github.com
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/84651
___
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/84651
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2177,7 +2177,8 @@ struct CounterCoverageMappingBuilder
}
void VisitOpaqueValueExpr(const OpaqueValueExpr* OVE) {
-Visit(OVE->getSourceExpr());
+if (const Expr *SE = OVE->getSourceExpr())
efriedma-quic wrote:
If you have a BinaryConditionalOper
@@ -1230,11 +1230,26 @@ CodeGenFunction::EmitCXXForRangeStmt(const
CXXForRangeStmt &S,
JumpDest LoopExit = getJumpDestInCurrentScope("for.end");
LexicalScope ForScope(*this, S.getSourceRange());
+ const DeclStmt *RangeDS = cast(S.getRangeStmt());
+ const VarDecl *RangeV
efriedma-quic wrote:
Why can't we just declare that the "generic" address-space must always be 0?
The specific numbers we use for address-spaces are completely arbitrary anyway.
https://github.com/llvm/llvm-project/pull/88182
___
cfe-commits mailing
@@ -4551,6 +4554,7 @@ llvm::Constant *CodeGenModule::GetOrCreateLLVMFunction(
llvm::Function *F =
llvm::Function::Create(FTy, llvm::Function::ExternalLinkage,
+ getDataLayout().getProgramAddressSpace(),
efriedma-quic wrote:
@@ -3581,8 +3582,10 @@ ConstantAddress
CodeGenModule::GetAddrOfTemplateParamObject(
isExternallyVisible(TPO->getLinkageAndVisibility().getLinkage())
? llvm::GlobalValue::LinkOnceODRLinkage
: llvm::GlobalValue::InternalLinkage;
- auto *GV = new llvm::
efriedma-quic wrote:
> > > querying a modules global AS from the target, rather than from the data
> > > layout (some DL's are incomplete, e.g. SPIRV's)
>
> That is a bug in those DataLayouts
>
> Do we spell out the requirement somewhere? I am only asking because, for
> example, [neither SPIR
Author: Eli Friedman
Date: 2024-04-09T19:37:35-07:00
New Revision: 349327f7e73ab7a314ef08c463dd04fcea623150
URL:
https://github.com/llvm/llvm-project/commit/349327f7e73ab7a314ef08c463dd04fcea623150
DIFF:
https://github.com/llvm/llvm-project/commit/349327f7e73ab7a314ef08c463dd04fcea623150.diff
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/87725
___
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/86902
___
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/86902
___
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/87906
___
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/85398
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2177,7 +2177,8 @@ struct CounterCoverageMappingBuilder
}
void VisitOpaqueValueExpr(const OpaqueValueExpr* OVE) {
-Visit(OVE->getSourceExpr());
+if (const Expr *SE = OVE->getSourceExpr())
efriedma-quic wrote:
The point of the "unique" flag is p
@@ -1230,11 +1230,26 @@ CodeGenFunction::EmitCXXForRangeStmt(const
CXXForRangeStmt &S,
JumpDest LoopExit = getJumpDestInCurrentScope("for.end");
LexicalScope ForScope(*this, S.getSourceRange());
+ const DeclStmt *RangeDS = cast(S.getRangeStmt());
+ const VarDecl *RangeV
@@ -1230,11 +1230,26 @@ CodeGenFunction::EmitCXXForRangeStmt(const
CXXForRangeStmt &S,
JumpDest LoopExit = getJumpDestInCurrentScope("for.end");
LexicalScope ForScope(*this, S.getSourceRange());
+ const DeclStmt *RangeDS = cast(S.getRangeStmt());
+ const VarDecl *RangeV
@@ -1230,11 +1230,26 @@ CodeGenFunction::EmitCXXForRangeStmt(const
CXXForRangeStmt &S,
JumpDest LoopExit = getJumpDestInCurrentScope("for.end");
LexicalScope ForScope(*this, S.getSourceRange());
+ const DeclStmt *RangeDS = cast(S.getRangeStmt());
+ const VarDecl *RangeV
@@ -3581,8 +3582,10 @@ ConstantAddress
CodeGenModule::GetAddrOfTemplateParamObject(
isExternallyVisible(TPO->getLinkageAndVisibility().getLinkage())
? llvm::GlobalValue::LinkOnceODRLinkage
: llvm::GlobalValue::InternalLinkage;
- auto *GV = new llvm::
efriedma-quic wrote:
Forbidding usage in C++ probably avoids the worst of the canonical-type issues,
but there's still some potential for weird results. Particularly with type
merging; for example, if you write `a ? (wrap_int)x : 1`, is the result a
wrapping type?
https://github.com/llvm/llv
https://github.com/efriedma-quic created
https://github.com/llvm/llvm-project/pull/88572
Since 97fe519d, in ARM64EC mode, we don't define `__aarch64__`. Fix various
preprocessor guards to account for this.
>From 1931103205e566ef49bbfa96272b3304c89f7d2d Mon Sep 17 00:00:00 2001
From: Eli Friedm
@@ -0,0 +1,49 @@
+// RUN: %clang_cc1 -emit-llvm -fexceptions -o - %s -triple x86_64-linux-gnu |
FileCheck -check-prefixes=EH,CHECK %s
+// RUN: %clang_cc1 -emit-llvm -o - %s -triple x86_64-linux-gnu | FileCheck
-check-prefixes=NOEH,CHECK %s
+namespace std {
+ typedef decltype(si
efriedma-quic wrote:
Please also fix llvm/lib/Target/SPIRV/SPIRVTargetMachine.cpp
https://github.com/llvm/llvm-project/pull/88455
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3014,6 +3014,16 @@ Address X86_64ABIInfo::EmitVAArg(CodeGenFunction &CGF,
Address VAListAddr,
ABIArgInfo AI = classifyArgumentType(Ty, 0, neededInt, neededSSE,
/*isNamedArg*/false);
+ // Empty records are ignored for parameter pas
301 - 400 of 1001 matches
Mail list logo
