@@ -536,6 +536,8 @@ void AggExprEmitter::EmitArrayInit(Address DestPtr,
llvm::ArrayType *AType,
CodeGen::CodeGenModule &CGM = CGF.CGM;
ConstantEmitter Emitter(CGF);
LangAS AS = ArrayQTy.getAddressSpace();
+if (CGF.getLangOpts().OpenCL)
+ AS = LangAS::openc
@@ -536,6 +536,8 @@ void AggExprEmitter::EmitArrayInit(Address DestPtr,
llvm::ArrayType *AType,
CodeGen::CodeGenModule &CGM = CGF.CGM;
ConstantEmitter Emitter(CGF);
LangAS AS = ArrayQTy.getAddressSpace();
+if (CGF.getLangOpts().OpenCL)
+ AS = LangAS::openc
@@ -536,6 +536,8 @@ void AggExprEmitter::EmitArrayInit(Address DestPtr,
llvm::ArrayType *AType,
CodeGen::CodeGenModule &CGM = CGF.CGM;
ConstantEmitter Emitter(CGF);
LangAS AS = ArrayQTy.getAddressSpace();
+if (CGF.getLangOpts().OpenCL)
+ AS = LangAS::openc
@@ -908,6 +908,73 @@ void CodeGenFunction::EmitIfStmt(const IfStmt &S) {
incrementProfileCounter(&S);
}
+bool CodeGenFunction::checkIfLoopMustProgress(const Expr
*ControllingExpression,
+ bool IsTrivialCXXLoop) {
+ if (CGM.get
efriedma-quic wrote:
> No. But I am confused, isn't this just shadowing a global variable with a
> lesser-scoped one. Are they the same? What behavior do we want here?
This is declaring, then defining, a global variable; sorry if that wasn't clear.
Probably should be an error? It'll be confus
@@ -4781,6 +4782,7 @@ CodeGenModule::CreateRuntimeFunction(llvm::FunctionType
*FTy, StringRef Name,
}
}
setDSOLocal(F);
+ markRegisterParameterAttributes(F);
efriedma-quic wrote:
Sign/zero-extend attributes led to real issues on some
efriedma-quic wrote:
> > If you declare a variable as both wrapping and non-wrapping, is it wrapping?
>
> I am not sure how to do this. I am sure that with the magic of C anything is
> possible but I can't conceive a way to have a variable both have the
> attribute and not have the attribute (
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/89462
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -4781,6 +4782,7 @@ CodeGenModule::CreateRuntimeFunction(llvm::FunctionType
*FTy, StringRef Name,
}
}
setDSOLocal(F);
+ markRegisterParameterAttributes(F);
efriedma-quic wrote:
To clarify, the code in llvm/ still needs to exist beca
@@ -4781,6 +4782,7 @@ CodeGenModule::CreateRuntimeFunction(llvm::FunctionType
*FTy, StringRef Name,
}
}
setDSOLocal(F);
+ markRegisterParameterAttributes(F);
efriedma-quic wrote:
Zero/sign-extend attributes are also missing, I think.
@@ -4684,6 +4684,29 @@ LValue CodeGenFunction::EmitLValueForLambdaField(const
FieldDecl *Field,
else
LambdaLV = MakeAddrLValue(AddrOfExplicitObject,
D->getType().getNonReferenceType());
+
+// Make sure we have an lvalue to the lamb
efriedma-quic wrote:
The C standard is small enough that if you comb through the C grammar
carefully, you can probably come up with explicitly rules for all the important
constructs, and verify they work. There's probably still a long tail of weird
interactions with current and future clang e
efriedma-quic wrote:
If you have a select with both wrapping and non-wrapping operands, is the
result wrapping? If you declare a variable as both wrapping and non-wrapping,
is it wrapping? If you declare a function parameter both wrapping and
non-wrapping, is it wrapping? If you assign to a
@@ -2554,16 +2554,27 @@ Decl *Parser::ParseDeclarationAfterDeclarator(
return ParseDeclarationAfterDeclaratorAndAttributes(D, TemplateInfo);
}
+static bool isConstexprVariable(const Decl *D) {
+ if (const VarDecl *Var = dyn_cast_if_present(D))
+return Var->isConstexpr()
@@ -2554,16 +2554,27 @@ Decl *Parser::ParseDeclarationAfterDeclarator(
return ParseDeclarationAfterDeclaratorAndAttributes(D, TemplateInfo);
}
+static bool isConstexprVariable(const Decl *D) {
+ if (const VarDecl *Var = dyn_cast_if_present(D))
+return Var->isConstexpr()
@@ -4781,6 +4782,7 @@ CodeGenModule::CreateRuntimeFunction(llvm::FunctionType
*FTy, StringRef Name,
}
}
setDSOLocal(F);
+ markRegisterParameterAttributes(F);
efriedma-quic wrote:
This really shouldn't work this way: we should go throu
efriedma-quic wrote:
I'm still not happy with the AST representation here. The current
representation is likely to cause unpredictable results in edge cases, and
compatibility constraints mean whatever result the current version happens to
produce for those cases is locked in forever. And th
efriedma-quic wrote:
Looks like automation didn't trigger, but:
> ⚠️ We detected that you are using a GitHub private e-mail address to
> contribute to the repo.
> Please turn off [Keep my email addresses
> private](https://github.com/settings/emails) setting in your account.
> See [LLVM
> Dis
@@ -0,0 +1,194 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
UTC_ARGS: --version 4
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -target-feature +fullbf16
-S -emit-llvm %s -o - | FileCheck %s
+// CHECK-LABEL: define dso_local half @test
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/89051
___
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/89051
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -930,12 +931,12 @@ CodeGenFunction::emitFlexibleArrayMemberSize(const Expr
*E, unsigned Type,
// Get the flexible array member Decl.
const RecordDecl *OuterRD = nullptr;
- std::string FAMName;
+ const FieldDecl *FAMDecl = nullptr;
if (const auto *ME = dyn_cast(Bas
efriedma-quic wrote:
If you can pull it off without increasing the size of Decl, sure; not sure it's
worthwhile otherwise.
https://github.com/llvm/llvm-project/pull/89462
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/c
efriedma-quic wrote:
Strictly speaking, I don't think this is NFC. Consider, for example:
```
struct S {
struct X { int array[1]; } x;
struct Y { int count; int array[] __attribute__((__counted_by__(count))); } y;
};
void f(void* __attribute__((pass_dynamic_object_size(0;
void g(struct
@@ -826,29 +826,32 @@ const FieldDecl
*CodeGenFunction::FindFlexibleArrayMemberField(
ASTContext &Ctx, const RecordDecl *RD, StringRef Name, uint64_t &Offset) {
const LangOptions::StrictFlexArraysLevelKind StrictFlexArraysLevel =
getLangOpts().getStrictFlexArraysLe
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/89171
___
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/89453
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/efriedma-quic approved this pull request.
LGTM
Please don't forget to fix CountCountedByAttrs... but it's fine if it's in a
followup.
https://github.com/llvm/llvm-project/pull/89126
___
cfe-commits mailing list
cfe-commits@lists.ll
@@ -8001,6 +8007,22 @@ void Sema::checkCall(NamedDecl *FDecl, const
FunctionProtoType *Proto,
}
}
+// SME functions may require SVE to be available for unwinding, as the
+// value of VG needs to be preserved across streaming-mode changes.
+if (CallerFD &
efriedma-quic wrote:
For the vector case, I think you want __builtin_convertvector or something like
that
https://github.com/llvm/llvm-project/pull/89051
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/li
@@ -1105,6 +1105,11 @@ bool MicrosoftCXXABI::hasMostDerivedReturn(GlobalDecl
GD) const {
static bool isTrivialForMSVC(const CXXRecordDecl *RD, QualType Ty,
CodeGenModule &CGM) {
+ // If the record is marked with the trivial_abi attribute, we don'
@@ -0,0 +1,40 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
UTC_ARGS: --version 4
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -O2
-Wno-missing-declarations -emit-llvm -o - %s | FileCheck %s
+
+struct foo {
+ int x,y,z;
+ struct bar
https://github.com/efriedma-quic updated
https://github.com/llvm/llvm-project/pull/89171
>From 39eeb2e7a0f5d82dffdbcb179a1ec967db235264 Mon Sep 17 00:00:00 2001
From: Eli Friedman
Date: Wed, 17 Apr 2024 23:04:50 -0700
Subject: [PATCH] [ARM64EC] Add softintrin.lib as an implicit dependency to
o
@@ -0,0 +1,22 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
UTC_ARGS: --version 4
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -O2
-Wno-missing-declarations -emit-llvm -o - %s | FileCheck %s
+
+struct foo {
+ struct bar {
+int cou
@@ -826,29 +826,31 @@ const FieldDecl
*CodeGenFunction::FindFlexibleArrayMemberField(
ASTContext &Ctx, const RecordDecl *RD, StringRef Name, uint64_t &Offset) {
const LangOptions::StrictFlexArraysLevelKind StrictFlexArraysLevel =
getLangOpts().getStrictFlexArraysLe
https://github.com/efriedma-quic commented:
We should probably apply the same fix to CountCountedByAttrs.
Along those lines, we should be able to handle:
```
struct bar {
int count;
int array[] __attribute__((counted_by(count)));
};
struct foo { struct bar x; };
void init(void * __attribute
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/89126
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,22 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
UTC_ARGS: --version 4
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -O2
-Wno-missing-declarations -emit-llvm -o - %s | FileCheck %s
+
+struct foo {
+ struct bar {
+int cou
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/89126
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -844,7 +847,18 @@ const FieldDecl
*CodeGenFunction::FindFlexibleArrayMemberField(
if (const FieldDecl *Field =
efriedma-quic wrote:
> if there's an inner struct that's not accessible, that doesn't affect the
> offsets of fields outside of that inner
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/88857
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
How hard would it be to make the output here have a consistent order? I mean,
emitting diagnostics in a consistent order isn't nearly as important as
emitting consistent binaries, but it's still nice to have if we can get it
easily.
https://github.com/llvm/llvm-project/p
https://github.com/efriedma-quic updated
https://github.com/llvm/llvm-project/pull/89171
>From 39eeb2e7a0f5d82dffdbcb179a1ec967db235264 Mon Sep 17 00:00:00 2001
From: Eli Friedman
Date: Wed, 17 Apr 2024 23:04:50 -0700
Subject: [PATCH] [ARM64EC] Add softintrin.lib as an implicit dependency to
o
https://github.com/efriedma-quic created
https://github.com/llvm/llvm-project/pull/89171
This copies MSVC behavior, and avoids weird link errors in certain cases.
>From 617b140cbd0c878bb6f4994d89aae3bbd8ea2754 Mon Sep 17 00:00:00 2001
From: Eli Friedman
Date: Wed, 17 Apr 2024 23:04:50 -0700
Su
@@ -844,7 +847,18 @@ const FieldDecl
*CodeGenFunction::FindFlexibleArrayMemberField(
if (const FieldDecl *Field =
efriedma-quic wrote:
Maybe instead of looking for RecordDecls, this code should be looking for
fields where the type of the field is an anon
@@ -844,7 +847,18 @@ const FieldDecl
*CodeGenFunction::FindFlexibleArrayMemberField(
if (const FieldDecl *Field =
efriedma-quic wrote:
FieldNo and Layout are referring to fields of "RD"; the "Field" found in the
recursive visit is a member of Record (or
efriedma-quic wrote:
What, if anything, about the scenario you're describing is specific to "normal"
cleanups?
https://github.com/llvm/llvm-project/pull/89154
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailm
@@ -0,0 +1,1056 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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: Apach
@@ -154,11 +154,20 @@ llvm::Value
*CodeGen::emitRoundPointerUpToAlignment(CodeGenFunction &CGF,
llvm::Value *Ptr,
CharUnits Align) {
// OverflowArgArea = (OverflowArgArea
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/88572
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
Looks like automation didn't trigger for some reason... but quoting the
automated message that's supposed to trigger:
> ⚠️ We detected that you are using a GitHub private e-mail address to
> contribute to the repo.
> Please turn off [Keep my email addresses
> private](htt
efriedma-quic wrote:
Say you have:
```
int foo();
struct A { A(); A(const A&, int = foo()); };
struct B { A a[10]; };
void f(const B& b) { B bb = b; }
```
We want to visit the call to foo(), I think?
https://github.com/llvm/llvm-project/pull/1
__
efriedma-quic wrote:
I don't think this works correctly? You need to evaluate both the
getCommonExpr(), and the getSubExpr().
https://github.com/llvm/llvm-project/pull/1
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.o
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/88910
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
I don't understand the scenario you're envisioning here. If, for example,
`sizeof(long)` is different in the AST vs. CodeGen, everything will very likely
explode. And I don't want to make an open-ended commitment to support
modifying properties of the target based on wha
https://github.com/efriedma-quic approved this pull request.
LGTM
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
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/88670
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -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
@@ -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
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
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
@@ -3581,8 +3582,10 @@ ConstantAddress
CodeGenModule::GetAddrOfTemplateParamObject(
isExternallyVisible(TPO->getLinkageAndVisibility().getLinkage())
? llvm::GlobalValue::LinkOnceODRLinkage
: llvm::GlobalValue::InternalLinkage;
- auto *GV = new llvm::
@@ -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
@@ -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
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
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 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/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/87725
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
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
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
@@ -3581,8 +3582,10 @@ ConstantAddress
CodeGenModule::GetAddrOfTemplateParamObject(
isExternallyVisible(TPO->getLinkageAndVisibility().getLinkage())
? llvm::GlobalValue::LinkOnceODRLinkage
: llvm::GlobalValue::InternalLinkage;
- auto *GV = new llvm::
@@ -4551,6 +4554,7 @@ llvm::Constant *CodeGenModule::GetOrCreateLLVMFunction(
llvm::Function *F =
llvm::Function::Create(FTy, llvm::Function::ExternalLinkage,
+ getDataLayout().getProgramAddressSpace(),
efriedma-quic wrote:
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
@@ -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
@@ -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
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
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
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 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:
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/87717
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -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 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
@@ -311,9 +311,9 @@ pushTemporaryCleanup(CodeGenFunction &CGF, const
MaterializeTemporaryExpr *M,
CleanupKind CleanupKind;
if (Lifetime == Qualifiers::OCL_Strong) {
const ValueDecl *VD = M->getExtendingDecl();
- bool Precise =
-
@@ -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
@@ -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()
@@ -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
@@ -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
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
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
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 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/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/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:
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
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
__
601 - 700 of 1174 matches
Mail list logo
