https://github.com/efriedma-quic created
https://github.com/llvm/llvm-project/pull/144970
This is a simple extension of 443377a9d1a8d4a69a317a1a892184c59dd0aec6 to also
handle the implicit expressions created by default initialization. This
usually doesn't matter, but it's relevant if the con
@@ -260,6 +260,12 @@ static void CheckStringInit(Expr *Str, QualType &DeclT,
const ArrayType *AT,
diag::ext_initializer_string_for_char_array_too_long)
<< Str->getSourceRange();
else if (StrLength - 1 == ArrayLen) {
+ // If the string literal is
@@ -50,11 +50,11 @@ BUILTIN(__builtin_arm_wfi, "v", "")
BUILTIN(__builtin_arm_sev, "v", "")
BUILTIN(__builtin_arm_sevl, "v", "")
BUILTIN(__builtin_arm_chkfeat, "WUiWUi", "")
-TARGET_HEADER_BUILTIN(__yield, "v", "h", ARMACLE_H, ALL_LANGUAGES, "")
-TARGET_HEADER_BUILTIN(__wfe,
@@ -99,6 +127,14 @@ static_assert(std::is_trivially_copyable_v);
// expected-note@-1 {{'int &' is not trivially copyable}} \
// expected-note@-1 {{because it is a reference type}}
+static_assert(std::is_assignable::value);
+
+static_assert(std::is_assignable::value);
+// expec
efriedma-quic wrote:
The NEON intrinsics specification
(https://developer.arm.com/architectures/instruction-sets/intrinsics/vshl_n_s64)
specifically says the argument must be an immediate in the specified range.
That's because it's supposed to map to an instruction which encodes the shift
am
@@ -1034,9 +1034,16 @@ class TargetInfo : public TransferrableTargetInfo,
/// set of primary and secondary targets.
virtual llvm::SmallVector getTargetBuiltins() const = 0;
+ enum class ArmStreamingKind {
+NotStreaming,
+StreamingCompatible,
+Streaming,
+ };
efriedma-quic wrote:
I think something like your patch solves the original testcase from #139033.
(Actually, it crashes in codegen, but that's an easy fix.) And I thought you
wanted specifically that...?
Your new testcase will never work; the NEON intrinsic is specifically specified
to only
efriedma-quic wrote:
Pushed revised patch which correctly handles streaming-compatible functions
(the previous version accidentally treated them as non-streaming).
https://github.com/llvm/llvm-project/pull/144611
___
cfe-commits mailing list
cfe-commi
https://github.com/efriedma-quic updated
https://github.com/llvm/llvm-project/pull/144611
>From c28804a471a9fe6be24479ffbfd7d4aa6c774125 Mon Sep 17 00:00:00 2001
From: Eli Friedman
Date: Tue, 17 Jun 2025 11:48:47 -0700
Subject: [PATCH 1/2] [AArch64] Add option -msve-streaming-vector-bits= .
Th
@@ -2660,6 +2644,133 @@ void X86AsmPrinter::emitCallInstruction(const
llvm::MCInst &MCI) {
OutStreamer->emitInstruction(MCI, getSubtargetInfo());
}
+// Checks whether a NOP is required after a CALL and inserts the NOP, if
+// necessary.
+void X86AsmPrinter::emitNopAfterCall
@@ -2660,6 +2644,133 @@ void X86AsmPrinter::emitCallInstruction(const
llvm::MCInst &MCI) {
OutStreamer->emitInstruction(MCI, getSubtargetInfo());
}
+// Checks whether a NOP is required after a CALL and inserts the NOP, if
+// necessary.
+void X86AsmPrinter::emitNopAfterCall
@@ -0,0 +1,180 @@
+// RUN: %clang_cl -c --target=x86_64-windows-msvc /EHa -O2 /GS- \
+// RUN: -Xclang=-import-call-optimization \
+// RUN: /clang:-S /clang:-o- %s 2>&1 \
+// RUN: | FileCheck %s
efriedma-quic wrote:
`// REQUIRES: x86-registered-target`
http
@@ -9,7 +9,6 @@ define i32 @foobar() gc "statepoint-example" personality ptr
@__gxx_personality_
; CHECK-NEXT:.seh_endprologue
; CHECK-NEXT:callq bar
; CHECK-NEXT: .Ltmp0:
-; CHECK-NEXT:nop
efriedma-quic wrote:
This makes the call adjacent to the
@@ -101,7 +101,8 @@ define void @f5() "frame-pointer"="all" {
; CHECK-NEXT:.seh_endprologue
; CHECK-NEXT:leaq -92(%rbp), %rcx
; CHECK-NEXT:callq external
-; CHECK-NEXT:nop
+; UEFI does not have SEH, so does not require NOP
+; WIN64-NEXT:nop
@@ -2660,6 +2644,133 @@ void X86AsmPrinter::emitCallInstruction(const
llvm::MCInst &MCI) {
OutStreamer->emitInstruction(MCI, getSubtargetInfo());
}
+// Checks whether a NOP is required after a CALL and inserts the NOP, if
+// necessary.
+void X86AsmPrinter::emitNopAfterCall
efriedma-quic wrote:
Please start a thread on https://discourse.llvm.org/ describing the problem
you're trying to solve, and your proposed solution.
https://github.com/llvm/llvm-project/pull/144622
___
cfe-commits mailing list
cfe-commits@lists.llvm.o
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/144625
___
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:
Needs regression tests (in clang/test/Sema/). For NEON intrinsics, and
whatever other classes of intrinsics are affected by this.
Please add a reference to the issue in the commit message, like "fixes #144625"
(the initial comment on the pull reques
https://github.com/efriedma-quic commented:
This all makes sense to me, but needs an PPC reviewer to approve.
https://github.com/llvm/llvm-project/pull/144673
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailma
efriedma-quic wrote:
For the constant expression handling stuff, I think you have the basic
framework working correctly; if we run into additional issues, I'm happy to
leave handling them for followups.
https://github.com/llvm/llvm-project/pull/138972
__
@@ -0,0 +1,38 @@
+; This tests directly annotating a function with
marked_for_windows_hot_patching.
+;
+; RUN: llc -mtriple=x86_64-windows < %s | FileCheck %s
efriedma-quic wrote:
If you put the tests in test/CodeGen/Generic, the test runner will try to run
the
@@ -0,0 +1,21 @@
+// This verifies that hotpatch function attributes are correctly propagated
when compiling directly to OBJ.
+//
+// RUN: echo this_gets_hotpatched > %t.patch-functions.txt
+// RUN: %clang_cl -c --target=x86_64-windows-msvc -O2 /Z7
-fms-secure-hotpatch-functions
@@ -389,6 +389,17 @@ def CoroDestroyOnlyWhenComplete :
EnumAttr<"coro_only_destroy_when_complete", In
/// pipeline to perform elide on the call or invoke instruction.
def CoroElideSafe : EnumAttr<"coro_elide_safe", IntersectPreserve, [FnAttr]>;
+/// Function is marked for Win
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/142713
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
Ping
https://github.com/llvm/llvm-project/pull/142713
___
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/144407
___
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/144611
This is similar to -msve-vector-bits, but for streaming mode: it constrains the
legal values of "vscale", allowing optimizations based on that constraint.
This also fixes conversions between SVE vectors a
@@ -411,7 +412,48 @@ static void emitAtomicCmpXchg(CodeGenFunction &CGF,
AtomicExpr *E, bool IsWeak,
CGF.Builder.SetInsertPoint(StoreExpectedBB);
// Update the memory at Expected with Old's value.
- CGF.Builder.CreateStore(Old, Val1);
+llvm::Type *ExpectedType = Expected
efriedma-quic wrote:
That pattern look like basically the same thing as the neg_one_constexpr
testcase I added. The diagnostic is expected.
Posted #144407 to add a relnote.
https://github.com/llvm/llvm-project/pull/143034
___
cfe-commits mailing lis
https://github.com/efriedma-quic created
https://github.com/llvm/llvm-project/pull/144407
This seems to be having some practical impact, so we should let people know.
>From 72b5793a6b0df71ec78e691aaa1b0729273263e0 Mon Sep 17 00:00:00 2001
From: Eli Friedman
Date: Mon, 16 Jun 2025 11:04:04 -070
efriedma-quic wrote:
That example doesn't have any int->enum conversions.
https://github.com/llvm/llvm-project/pull/143034
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
Most likely, the user code is invalid. I was hoping we would get away without
hitting any bugs in major frameworks, but I'm not surprised we hit something.
If this is widespread, we can look into mitigations, but it's difficult to
downgrade constant evaluation errors to w
@@ -0,0 +1,596 @@
+//===-- WindowsHotPatch.cpp - Support for Windows hotpatching
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/138972
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,596 @@
+//===-- WindowsHotPatch.cpp - Support for Windows hotpatching
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
https://github.com/efriedma-quic commented:
I'd like to see regression tests for the cases I've mentioned. PHI nodes,
ConstantExpr, and I guess the combination of the two.
https://github.com/llvm/llvm-project/pull/138972
___
cfe-commits mailing list
@@ -5243,7 +5245,19 @@ static bool EvaluateVarDecl(EvalInfo &Info, const
VarDecl *VD) {
if (InitE->isValueDependent())
return false;
- if (!EvaluateInPlace(Val, Info, Result, InitE)) {
+ if (VD->getType()->isReferenceType() && InitE->isGLValue()) {
ef
@@ -5243,7 +5245,19 @@ static bool EvaluateVarDecl(EvalInfo &Info, const
VarDecl *VD) {
if (InitE->isValueDependent())
return false;
- if (!EvaluateInPlace(Val, Info, Result, InitE)) {
+ if (VD->getType()->isReferenceType() && InitE->isGLValue()) {
+if (!EvaluateL
@@ -174,10 +174,11 @@ def note_constexpr_heap_alloc_limit_exceeded : Note<
def note_constexpr_this : Note<
"%select{|implicit }0use of 'this' pointer is only allowed within the "
"evaluation of a call to a 'constexpr' member function">;
-def access_kind : TextSubstitution<
@@ -4503,7 +4505,7 @@ static CompleteObject findCompleteObject(EvalInfo &Info,
const Expr *E,
} else {
const Expr *Base = LVal.Base.dyn_cast();
-if (!Frame) {
+if (!Frame && AK != clang::AK_CheckReferenceInitialization) {
efriedma-quic wrote:
T
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/143460
___
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
(It might be worth trying to audit other uses of getLocForEndOfToken; it looks
like there are other dubious uses. But we don't need to do everything in one
patch.)
https://github.com/llvm/llvm-project/pull/143460
_
@@ -1873,6 +1873,17 @@ Parser::TryAnnotateName(CorrectionCandidateCallback *CCC,
return AnnotatedNameKind::Unresolved;
}
+SourceLocation Parser::getEndOfPreviousToken() const {
+ SourceLocation TokenEndLoc = PP.getLocForEndOfToken(PrevTokLocation);
+ if (TokenEndLoc.isVali
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/139566
___
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 with one minor comment
https://github.com/llvm/llvm-project/pull/139566
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commit
@@ -893,13 +893,8 @@ void
MicrosoftCXXABI::emitVirtualObjectDelete(CodeGenFunction &CGF,
QualType ElementType,
const CXXDestructorDecl *Dtor) {
// FIXME: Provide a source location her
@@ -1873,6 +1873,17 @@ Parser::TryAnnotateName(CorrectionCandidateCallback *CCC,
return AnnotatedNameKind::Unresolved;
}
+SourceLocation Parser::getEndOfPreviousToken() const {
+ SourceLocation TokenEndLoc = PP.getLocForEndOfToken(PrevTokLocation);
+ if (TokenEndLoc.isVali
efriedma-quic wrote:
The only code that generates prologues and epilogues is PrologEpilogInserter.
There isn't any way to skip the normal codegen codepath. (You can write a
naked function, but then you'd be responsible for writing your own unwind
directives.)
reportFatalInternalError seems
@@ -1888,10 +1888,11 @@ namespace PR15884 {
}
namespace AfterError {
- constexpr int error() {
+ constexpr int error() { // pre-cxx23-error {{no return statement in
constexpr function}}
efriedma-quic wrote:
Did you mean to refer to some other issue report?
https://github.com/efriedma-quic commented:
I'm a little concerned about the wording of the errors here. The "too many
epilogues" and "too many opcodes" errors should say that it's not yet
implemented, or something, so it's clear it's a limitation of the compiler.
Maybe try to suggest a worka
@@ -143,3 +143,8 @@ namespace fold_initializer {
const float A::f = __builtin_is_constant_evaluated();
static_assert(fold(A::f == 1.0f));
}
+
+struct GH99680 {
+ static const int x = 1/(1-__builtin_is_constant_evaluated()); //
expected-error {{in-class initializer for sta
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/142713
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
I see two possible ways to approach this, in general:
- Come up with a method that actually figures out the end of the token inside
the macro, instead of bailing on macros. I'm not sure we can provide a good
location in edge cases involving token pasting, but we can proba
@@ -833,9 +833,23 @@ StmtResult Parser::ParseCaseStatement(ParsedStmtContext
StmtCtx,
<< FixItHint::CreateReplacement(ColonLoc, ":");
} else {
SourceLocation ExpectedLoc = PP.getLocForEndOfToken(PrevTokLocation);
+ SourceLocation ExprLoc =
+ L
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/143460
___
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:
This seems like a more general issue... some examples:
```
#define D foo bar
enum { D };
```
```
#define D foo bar
void f() { int a[2]; auto [D] = a; }
```
```
#define D class X;
X D;
```
```
#define D C::{
class C { D }};
```
Can we come up with
@@ -2513,6 +2513,9 @@ void testValueInRangeOfEnumerationValues() {
// expected-error@-1 {{constexpr variable 'x2' must be initialized by a
constant expression}}
// expected-note@-2 {{integer value 8 is outside the valid range of values
[-8, 7] for the enumeration type 'E1'
@@ -2885,6 +2886,16 @@ class CXXDestructorDecl : public CXXMethodDecl {
return getCanonicalDecl()->OperatorDelete;
}
+ const FunctionDecl *getOperatorGlobalDelete() const {
+return getCanonicalDecl()->OperatorGlobalDelete;
+ }
+
+ void setOperatorGlobalDelete(Func
@@ -1589,25 +1589,74 @@ namespace {
void EmitConditionalDtorDeleteCall(CodeGenFunction &CGF,
llvm::Value *ShouldDeleteCondition,
bool ReturnAfterDelete) {
+const CXXDestructorDecl *Dtor = cast(CGF.C
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/135064
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -843,8 +843,8 @@ static const ARMVectorIntrinsicInfo ARMSIMDIntrinsicMap []
= {
NEONMAP1(vrndaq_v, arm_neon_vrinta, Add1ArgType),
NEONMAP0(vrndi_v),
NEONMAP0(vrndiq_v),
- NEONMAP1(vrndm_v, arm_neon_vrintm, Add1ArgType),
- NEONMAP1(vrndmq_v, arm_neon_vrintm, Add1ArgT
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/142559
___
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/142559
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1888,10 +1888,11 @@ namespace PR15884 {
}
namespace AfterError {
- constexpr int error() {
+ constexpr int error() { // pre-cxx23-error {{no return statement in
constexpr function}}
efriedma-quic wrote:
It would be nice to suppress this diagnostic: if
@@ -207,7 +207,7 @@ namespace PR15045 {
// Show that recovery has happened by also triggering typo correction
e->Func(); // expected-error {{member reference type 'bar' is not a
pointer; did you mean to use '.'?}} \
-// expected-error {{no member name
@@ -58,10 +58,8 @@ struct Base {
};
struct Derived final : Base {
- virtual ~Derived() = defaul; // #default
+ virtual ~Derived() = defaul; // expected-error {{use of undeclared
identifier 'defaul'}}
efriedma-quic wrote:
I would sort of expect us to try to
https://github.com/efriedma-quic commented:
Briefly looked over the test changes. Mostly seems fine, but it seems like
we're losing typo correction in a few places that don't seem related to delayed
typo correction, at least at first glance.
https://github.com/llvm/llvm-project/pull/143423
__
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/143423
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1,29 +0,0 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 %s
-// Don't crash (PR13394).
efriedma-quic wrote:
Is this just not worth keeping because it's strongly connected to delayed typo
correction? Or did this move?
https://github.com/llvm/llvm-p
@@ -649,12 +647,12 @@ class AddObservation { // expected-note {{declared here}}
namespace testNonStaticMemberHandling {
struct Foo {
- bool usesMetadata; // expected-note {{'usesMetadata' declared here}}
+ bool usesMetadata;
};
int test(Foo f) {
if (UsesMetadata) // e
@@ -411,7 +412,48 @@ static void emitAtomicCmpXchg(CodeGenFunction &CGF,
AtomicExpr *E, bool IsWeak,
CGF.Builder.SetInsertPoint(StoreExpectedBB);
// Update the memory at Expected with Old's value.
- CGF.Builder.CreateStore(Old, Val1);
+llvm::Type *ExpectedType = Expected
@@ -411,7 +412,48 @@ static void emitAtomicCmpXchg(CodeGenFunction &CGF,
AtomicExpr *E, bool IsWeak,
CGF.Builder.SetInsertPoint(StoreExpectedBB);
// Update the memory at Expected with Old's value.
- CGF.Builder.CreateStore(Old, Val1);
+llvm::Type *ExpectedType = Expected
@@ -411,7 +412,48 @@ static void emitAtomicCmpXchg(CodeGenFunction &CGF,
AtomicExpr *E, bool IsWeak,
CGF.Builder.SetInsertPoint(StoreExpectedBB);
// Update the memory at Expected with Old's value.
- CGF.Builder.CreateStore(Old, Val1);
+llvm::Type *ExpectedType = Expected
@@ -143,3 +143,8 @@ namespace fold_initializer {
const float A::f = __builtin_is_constant_evaluated();
static_assert(fold(A::f == 1.0f));
}
+
+struct GH99680 {
+ static const int x = 1/(1-__builtin_is_constant_evaluated()); //
expected-error {{in-class initializer for sta
@@ -143,3 +143,8 @@ namespace fold_initializer {
const float A::f = __builtin_is_constant_evaluated();
static_assert(fold(A::f == 1.0f));
}
+
+struct GH99680 {
+ static const int x = 1/(1-__builtin_is_constant_evaluated()); //
expected-error {{in-class initializer for sta
https://github.com/efriedma-quic commented:
I'm a little concerned we don't want to play whack-a-mole with this... but I
guess optimizations generally won't explicitly request an alignment of "1", so
this is probably good enough?
Please write a test specifically for instcombine, not a clang te
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/143034
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
The clang patch was written the way it was because it was necessary to comply
with the ABI rules. Strings passed to printf don't have any sort of alignment
requirement, so you can't really appeal to the ABI rules here, I think?
The problem with copying the alignment is th
https://github.com/efriedma-quic updated
https://github.com/llvm/llvm-project/pull/143034
>From 818f2cfd1558a4ee22bd1c3b8ce339eb82a06536 Mon Sep 17 00:00:00 2001
From: Eli Friedman
Date: Wed, 4 Jun 2025 19:40:37 -0700
Subject: [PATCH 1/2] [clang] Check constexpr int->enum conversions
consisten
https://github.com/efriedma-quic updated
https://github.com/llvm/llvm-project/pull/142713
>From 9bc16d5c3b3c540ca3058e181b509f4122a2073b Mon Sep 17 00:00:00 2001
From: Eli Friedman
Date: Tue, 3 Jun 2025 18:53:14 -0700
Subject: [PATCH 1/3] [clang] Remove separate evaluation step for static class
https://github.com/efriedma-quic created
https://github.com/llvm/llvm-project/pull/143034
In 8de51375f12d91675a18d17f262276e65f43fbe0 and related patches, we added some
code to avoid triggering -Wenum-constexpr-conversion in some cases. This isn't
necessary anymore because -Wenum-constexpr-co
@@ -143,3 +143,8 @@ namespace fold_initializer {
const float A::f = __builtin_is_constant_evaluated();
static_assert(fold(A::f == 1.0f));
}
+
+struct GH99680 {
+ static const int x = 1/(1-__builtin_is_constant_evaluated()); //
expected-error {{in-class initializer for sta
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/142713
___
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:
> or is there more?
No, that's it, basically. (Except for the C++98 codepath.)
https://github.com/llvm/llvm-project/pull/142713
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/142885
___
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/142885
As discussed in #142707, in the context of determining whether a conversion is
a narrowing conversion, is_constant_evaluation should be false, even it's a
subexpression of a manifestly constant-evaluated
@@ -4652,6 +4659,7 @@ llvm::Constant
*CodeGenModule::GetOrCreateMultiVersionResolver(GlobalDecl GD) {
"", Resolver, &getModule());
GIF->setName(ResolverName);
SetCommonAttributes(FD, GIF);
+SetResolverAttrs(cast(Resolver));
---
@@ -4652,6 +4659,7 @@ llvm::Constant
*CodeGenModule::GetOrCreateMultiVersionResolver(GlobalDecl GD) {
"", Resolver, &getModule());
GIF->setName(ResolverName);
SetCommonAttributes(FD, GIF);
+SetResolverAttrs(cast(*Resolver));
--
https://github.com/efriedma-quic updated
https://github.com/llvm/llvm-project/pull/142713
>From 9bc16d5c3b3c540ca3058e181b509f4122a2073b Mon Sep 17 00:00:00 2001
From: Eli Friedman
Date: Tue, 3 Jun 2025 18:53:14 -0700
Subject: [PATCH 1/2] [clang] Remove separate evaluation step for static class
efriedma-quic wrote:
https://llvm-compile-time-tracker.com/compare.php?from=d204aa9deb72b8dcaf5e5b5550871d0ebe982825&to=9bc16d5c3b3c540ca3058e181b509f4122a2073b&stat=instructions:u
. Basically no change... which is what I was expecting. There's maybe some
slight savings from skipping the call
@@ -843,8 +843,8 @@ static const ARMVectorIntrinsicInfo ARMSIMDIntrinsicMap []
= {
NEONMAP1(vrndaq_v, arm_neon_vrinta, Add1ArgType),
NEONMAP0(vrndi_v),
NEONMAP0(vrndiq_v),
- NEONMAP1(vrndm_v, arm_neon_vrintm, Add1ArgType),
- NEONMAP1(vrndmq_v, arm_neon_vrintm, Add1ArgT
@@ -2595,6 +2595,14 @@ GetX86_64ByValArgumentPair(llvm::Type *Lo, llvm::Type
*Hi,
ABIArgInfo X86_64ABIInfo::
classifyReturnType(QualType RetTy) const {
+ // return int128 as i128
+ if (const BuiltinType *BT = RetTy->getAs()) {
+BuiltinType::Kind k = BT->getKind();
+
efriedma-quic wrote:
If the goal here is gcc compatibility, I'd suggest not hooking up the flag to
anything; the existing LoopFusePass isn't used by anything and hasn't been
touched in years, so it's very likely to have issues.
https://github.com/llvm/llvm-project/pull/142686
_
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/141887
___
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/142498
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
Backported manually: #142648
https://github.com/llvm/llvm-project/pull/142498
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
/cherry-pick 97885213bd4507b204b050c3cd570e365d21cc7d
https://github.com/llvm/llvm-project/pull/142498
___
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/142498
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
Ping
https://github.com/llvm/llvm-project/pull/141887
___
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/142498
If we see a parameter of reference type that isn't part of the frame, don't try
to evaluate its default argument. Just treat it as a constexpr-unknown value.
Fixes #141114. Fixes #141858.
>From 08d64f59
1 - 100 of 1705 matches
Mail list logo
