Author: Timm Bäder
Date: 2024-02-27T17:11:19+01:00
New Revision: b70f42a430723e00d76cc99d348e4f2fec221cf1
URL:
https://github.com/llvm/llvm-project/commit/b70f42a430723e00d76cc99d348e4f2fec221cf1
DIFF:
https://github.com/llvm/llvm-project/commit/b70f42a430723e00d76cc99d348e4f2fec221cf1.diff
LO
https://github.com/hnakamura5 created
https://github.com/llvm/llvm-project/pull/83149
This adds two options to control the line break inside TableGen DAGArg.
- TableGenBreakInsideDAGArgList
- TableGenBreakingDAGArgOperators
>From becb28f6daa1fed9cabe40375a7ed863207b6bd2 Mon Sep 17 00:00:00 20
llvmbot wrote:
@llvm/pr-subscribers-clang-format
@llvm/pr-subscribers-clang
Author: Hirofumi Nakamura (hnakamura5)
Changes
This adds two options to control the line break inside TableGen DAGArg.
- TableGenBreakInsideDAGArgList
- TableGenBreakingDAGArgOperators
---
Full diff: https://git
hnakamura5 wrote:
Alignment option for definitions:
https://github.com/llvm/llvm-project/pull/83008.
https://github.com/llvm/llvm-project/pull/76059
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinf
hnakamura5 wrote:
Break options for DAGArg: https://github.com/llvm/llvm-project/pull/83149.
https://github.com/llvm/llvm-project/pull/76059
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-com
hnakamura5 wrote:
These options have a dependency that TableGenBreakInsideDAGArgList is effective
only when TableGenBreakingDAGArgOperators is specified as true.
I'm not sure this is a smart way.
https://github.com/llvm/llvm-project/pull/83149
___
cfe
AaronBallman wrote:
> Since this is a relatively benign bug, all things considered, does this even
> warrant a release note?
I think it should have a release note; it changes the layout of the AST which
may impact folks writing AST matchers (clang-tidy checks, etc). But also, I
think it does
zahiraam wrote:
> @AaronBallman I removed the field that I added in the policy and tried to use
> the existing ones. That broke a few LIT tests but before fixing them I want
> to check with you if the combination of policy I have added in the unittest
> is correct. Thanks.
ping?
https://gith
Author: Timm Bäder
Date: 2024-02-27T17:29:19+01:00
New Revision: 183b6b56f2602ea171502f9f2843c2c1caca2919
URL:
https://github.com/llvm/llvm-project/commit/183b6b56f2602ea171502f9f2843c2c1caca2919
DIFF:
https://github.com/llvm/llvm-project/commit/183b6b56f2602ea171502f9f2843c2c1caca2919.diff
LO
https://github.com/DavidGoldman updated
https://github.com/llvm/llvm-project/pull/81775
>From b0a2fb25c25ecfb20bb3f0aab2d398ea80caeff2 Mon Sep 17 00:00:00 2001
From: David Goldman
Date: Fri, 26 Jan 2024 15:50:11 -0500
Subject: [PATCH 1/4] Add support for ObjC property renaming + implicit
prope
https://github.com/ilovepi updated
https://github.com/llvm/llvm-project/pull/80480
>From 4d280199a9eb027127bdc9c31a266fa3e2fa6cea Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Tue, 22 Aug 2023 15:24:03 +
Subject: [PATCH 1/2] [CMAKE] Enable FatLTO as a build option for LLVM
---
clang/cma
https://github.com/SLTozer updated
https://github.com/llvm/llvm-project/pull/80480
>From 4d280199a9eb027127bdc9c31a266fa3e2fa6cea Mon Sep 17 00:00:00 2001
From: Paul Kirth
Date: Tue, 22 Aug 2023 15:24:03 +
Subject: [PATCH 1/2] [CMAKE] Enable FatLTO as a build option for LLVM
---
clang/cma
https://github.com/paschalis-mpeis updated
https://github.com/llvm/llvm-project/pull/78432
>From a74ba110994e4535cd6c9206aa02d50503fb5577 Mon Sep 17 00:00:00 2001
From: Paschalis Mpeis
Date: Tue, 27 Feb 2024 15:00:28 +
Subject: [PATCH 1/7] [AArch64][TLI] Add TLI mappings for ArmPL modf, sin
@@ -24,4 +24,9 @@ def int_dx_dot :
Intrinsic<[LLVMVectorElementType<0>],
[llvm_anyvector_ty, LLVMScalarOrSameVectorWidth<0,
LLVMVectorElementType<0>>],
[IntrNoMem, IntrWillReturn, Commutative] >;
+
+def int_dx_lerp :
+Intrinsic<[LLVMMatchType<0>],
+[llvm_
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/82977
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat commented:
I finished reading your commit and added one more suggestion about note tag
creation.
Moreover I also suggest adding a testcase that looks like
```cpp
struct Node {
int value;
};
struct BranchingNode: public Node {
Node nodes[8];
};
void delete_base_m
@@ -0,0 +1,178 @@
+//=== PolymorphicPtrArithmetic.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: Ap
https://github.com/vinayakdsci created
https://github.com/llvm/llvm-project/pull/83152
Fixes #82512
Adds diagnostics for lambda expressions being cast to boolean values, which
results in the expression always evaluating to true.
Earlier, Clang allowed compilation of such erroneous programs, b
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Vinayak Dev (vinayakdsci)
Changes
Fixes #82512
Adds diagnostics for lambda expressions being cast to boolean values, which
results in the expression always evaluating to true.
Earlier, Clang allowed compilation of such erroneous programs
https://github.com/mahtohappy updated
https://github.com/llvm/llvm-project/pull/83124
>From 4661010da31d7fa83dd0e7282bcea8732b3598f0 Mon Sep 17 00:00:00 2001
From: mahtohappy
Date: Tue, 27 Feb 2024 03:13:51 -0800
Subject: [PATCH] [Clang][Sema] placement new initializes typedef array with
corre
@@ -0,0 +1,19 @@
+// RUN: %clang++ -S -emit-llvm -o - %s | FileCheck %s
+#include
+
+// CHECK: call void @llvm.memset.p0.i64(ptr align 1 %x, i8 0, i64 8, i1 false)
+// CHECK: call void @llvm.memset.p0.i64(ptr align 16 %x, i8 0, i64 32, i1
false)
+template
shafi
shafik wrote:
Thank you for this fix.
Can you put more details in your summary. The approach I like to take is 1.
what the problem is 2. what is the approach of the fix 3. any other important
details.
https://github.com/llvm/llvm-project/pull/83124
https://github.com/diggerlin updated
https://github.com/llvm/llvm-project/pull/82809
>From cef79b36bcb3f4b7452d01aafdf111ff0e50605d Mon Sep 17 00:00:00 2001
From: zhijian
Date: Fri, 23 Feb 2024 13:23:18 -0500
Subject: [PATCH 1/5] Implement a subset of builtin_cpu_supports() features
---
clang
@@ -16560,32 +16560,69 @@ Value *CodeGenFunction::EmitPPCBuiltinExpr(unsigned
BuiltinID,
#include "llvm/TargetParser/PPCTargetParser.def"
auto GenAIXPPCBuiltinCpuExpr = [&](unsigned SupportMethod, unsigned FieldIdx,
- unsigned CompOp,
+
https://github.com/DanielKristofKiss updated
https://github.com/llvm/llvm-project/pull/82819
>From c5c2d720e822624fa7966297087b04e6b2fc2a86 Mon Sep 17 00:00:00 2001
From: Daniel Kiss
Date: Fri, 23 Feb 2024 17:12:26 +0100
Subject: [PATCH 1/2] [NFC][ARM][AArch64] Deduplicated code.
Add the SignR
erichkeane wrote:
I definitely agree with both of Shafik's comments!
The fix itself concerns me, the logic in the block that is having its condition
inverted is specifically made for 'if no array size was specified' (see
comment), so that makes me think this is an incorrect patch. It doesn'
DanielKristofKiss wrote:
Function attributes are only attached when they are set.
#83153 ensures the synthetic function are also gets the right attributes so
the backend doesn't need to use the module attributes #83154.
https://github.com/llvm/llvm-project/pull/82819
__
https://github.com/mahtohappy edited
https://github.com/llvm/llvm-project/pull/83124
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -14474,6 +14474,23 @@ ExprResult Sema::CreateOverloadedBinOp(SourceLocation
OpLoc,
CurFPFeatureOverrides());
}
+ // If this is the .* operator, which is not overloadable, just
+ // create a built-in binary operator.
+ if (Opc ==
Sirraide wrote:
> Thank you for the fix! Please be sure to add a release note to
> `clang/docs/ReleaseNotes.rst` so users know about the fix (and be sure to
> mention the issue # in the release note).
Ah yes, I keep forgetting about that
https://github.com/llvm/llvm-project/pull/83103
___
mahtohappy wrote:
> I definitely agree with both of Shafik's comments!
>
> The fix itself concerns me, the logic in the block that is having its
> condition inverted is specifically made for 'if no array size was specified'
> (see comment), so that makes me think this is an incorrect patch. It
https://github.com/dhoekwater updated
https://github.com/llvm/llvm-project/pull/82662
>From 6f03717b81c8767319bfac8923ffd1c3caba1602 Mon Sep 17 00:00:00 2001
From: Daniel Hoekwater
Date: Thu, 22 Feb 2024 17:39:15 +
Subject: [PATCH] [Driver] Allow -fbasic-block-address-map for AArch64 ELF
E
dhoekwater wrote:
None of the failing checks seem to be due to my change, so I'm going to keep
rebasing onto HEAD until something sticks. If there's a better way than force
pushing to my fork, I don't know of it.
https://github.com/llvm/llvm-project/pull/82662
_
mahtohappy wrote:
// If no array size was specified, but the new expression was
// instantiated with an array type (e.g., "new T" where T is
// instantiated with "int[4]"), extract the outer bound from the
// array type as our array size. We do this with constant and
// depend
Sirraide wrote:
> > Since this is a relatively benign bug, all things considered, does this
> > even warrant a release note?
>
> I think it should have a release note; it changes the layout of the AST which
> may impact folks writing AST matchers (clang-tidy checks, etc). But also, I
> think
https://github.com/michaelrj-google commented:
LGTM with one nit
https://github.com/llvm/llvm-project/pull/82855
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/michaelrj-google edited
https://github.com/llvm/llvm-project/pull/82855
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1044,6 +1117,10 @@ bool PrintfSpecifier::hasValidSpacePrefix() const {
case ConversionSpecifier::AArg:
case ConversionSpecifier::FreeBSDrArg:
case ConversionSpecifier::FreeBSDyArg:
+ case ConversionSpecifier::rArg:
+ case ConversionSpecifier::RArg:
https://github.com/ilovepi created
https://github.com/llvm/llvm-project/pull/83159
In addition to being rather hard to follow, there isn't a good reason
why FatLTO shouldn't just share the same code for setting module flags
for (Thin)LTO. This patch simplifies the logic and makes sure we use set
llvmbot wrote:
@llvm/pr-subscribers-clang-codegen
Author: Paul Kirth (ilovepi)
Changes
In addition to being rather hard to follow, there isn't a good reason
why FatLTO shouldn't just share the same code for setting module flags
for (Thin)LTO. This patch simplifies the logic and makes sure
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Paul Kirth (ilovepi)
Changes
In addition to being rather hard to follow, there isn't a good reason
why FatLTO shouldn't just share the same code for setting module flags
for (Thin)LTO. This patch simplifies the logic and makes sure we use s
Sirraide wrote:
> I think your suggestion is sensible, though I'm equally as OK with just
> making the standard attribute ONLY spellable as `[[assume]]` (and leaving the
> other attribute alone).
That would also be an option yeah. Only somewhat related, this diagnostic
probably needs to be up
@@ -16560,32 +16560,69 @@ Value *CodeGenFunction::EmitPPCBuiltinExpr(unsigned
BuiltinID,
#include "llvm/TargetParser/PPCTargetParser.def"
auto GenAIXPPCBuiltinCpuExpr = [&](unsigned SupportMethod, unsigned FieldIdx,
- unsigned CompOp,
+
https://github.com/Sirraide updated
https://github.com/llvm/llvm-project/pull/83103
>From 071b6287e89e4601d9e441978f0b4bd53e757c26 Mon Sep 17 00:00:00 2001
From: Sirraide
Date: Tue, 27 Feb 2024 06:19:05 +0100
Subject: [PATCH 1/3] [Clang] [Sema] Handle placeholders in '.*' expressions
---
clan
erichkeane wrote:
>I suppose the only question now is whether [[clang::assume]] should be treated
>like [[assume]] if it’s not applied to a function declaration?
THAT is an interesting question that @AaronBallman might have some comments
on...
Effectively, we have TWO 'assume' attributes-
1-
@@ -3740,7 +3740,11 @@ ExprResult Sema::BuildPredefinedExpr(SourceLocation Loc,
else {
// Pre-defined identifiers are of type char[x], where x is the length of
// the string.
-auto Str = PredefinedExpr::ComputeName(IK, currentDecl);
+bool ForceElaboratedPrinti
@@ -665,7 +665,8 @@ StringRef
PredefinedExpr::getIdentKindName(PredefinedIdentKind IK) {
// FIXME: Maybe this should use DeclPrinter with a special "print predefined
AaronBallman wrote:
The more complex we make this, the more I think this FIXME sounds like a
s
@@ -713,11 +714,21 @@ std::string
PredefinedExpr::ComputeName(PredefinedIdentKind IK,
return std::string(Out.str());
}
if (const FunctionDecl *FD = dyn_cast(CurrentDecl)) {
-if (IK != PredefinedIdentKind::PrettyFunction &&
-IK != PredefinedIdentKind::Pretty
@@ -1635,6 +1635,15 @@ void TypePrinter::printElaboratedBefore(const
ElaboratedType *T,
if (T->getKeyword() != ElaboratedTypeKeyword::None)
OS << " ";
NestedNameSpecifier *Qualifier = T->getQualifier();
+if (Policy.SuppressTagKeyword && Policy.SuppressScope)
@@ -2260,10 +2269,15 @@ printTo(raw_ostream &OS, ArrayRef Args, const
PrintingPolicy &Policy,
} else {
if (!FirstArg)
OS << Comma;
- // Tries to print the argument with location info if exists.
- printArgument(Arg, Policy, ArgOS,
-
https://github.com/Sirraide updated
https://github.com/llvm/llvm-project/pull/83063
>From 5418bec794ad1df54f49a1c8d317a75d56290239 Mon Sep 17 00:00:00 2001
From: Sirraide
Date: Mon, 26 Feb 2024 19:53:42 +0100
Subject: [PATCH 1/2] [Clang] [Sema] Remove incorrect int-to-complex-float
conversion
Sirraide wrote:
> Of the three, I lean towards 3 actually, I think that is perhaps the BEST
> idea, and is perhaps supported by our existing infrastructure already (if you
> have Attr.td set its targets right?). I'd like to see what Aaron has to say,
> but I THINK that is my preference baring
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
Sirraide wrote:
And yes, it looks like the current implementation already differentiates the
two attributes properly based on appertainment; the only thing left to do would
be to investigate if there are any (other) diagnostics that need some
improvement.
https://github.com/llvm/llvm-project/
Sirraide wrote:
Also, `[[assume]]` is currently called `AssumeAttr`, whereas
`[[clang::assume]]` is called `AssumptionAttr`, so we might want to rename one
of those (e.g. the former to `CXXAssumeAttr` or the latter to
`ClangAssumptionAttr` or sth like that) because that sounds like a possible
erichkeane wrote:
> > Of the three, I lean towards 3 actually, I think that is perhaps the BEST
> > idea, and is perhaps supported by our existing infrastructure already (if
> > you have Attr.td set its targets right?). I'd like to see what Aaron has to
> > say, but I THINK that is my preferen
Sirraide wrote:
> I might lean toward CXXAssumeAttr and OMPAssumeAttr ?
That’s a good idea actually.
https://github.com/llvm/llvm-project/pull/81014
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinf
erichkeane wrote:
> > I might lean toward CXXAssumeAttr and OMPAssumeAttr ?
>
> That’s a good idea actually.
I have those occasionally :)
https://github.com/llvm/llvm-project/pull/81014
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https:/
https://github.com/PiotrZSL commented:
LGTM
https://github.com/llvm/llvm-project/pull/83055
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/PiotrZSL approved this pull request.
https://github.com/llvm/llvm-project/pull/83055
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: AMS21
Date: 2024-02-27T19:35:11+01:00
New Revision: 7b11e2ec39ae01f53d53250551e207583bd51e80
URL:
https://github.com/llvm/llvm-project/commit/7b11e2ec39ae01f53d53250551e207583bd51e80
DIFF:
https://github.com/llvm/llvm-project/commit/7b11e2ec39ae01f53d53250551e207583bd51e80.diff
LOG: [c
https://github.com/PiotrZSL closed
https://github.com/llvm/llvm-project/pull/83055
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/martinboehme updated
https://github.com/llvm/llvm-project/pull/82986
>From cd64b0e04026235283016eaf1cd601076ab7aeb2 Mon Sep 17 00:00:00 2001
From: Martin Braenne
Date: Tue, 27 Feb 2024 18:23:36 +
Subject: [PATCH 1/2] Reapply "[clang][dataflow] Correctly handle
`InitListE
martinboehme wrote:
Just modified this PR to essentially reapply
https://github.com/llvm/llvm-project/pull/82348 under it.
https://github.com/llvm/llvm-project/pull/82986
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/c
@@ -1,4 +1,5 @@
// RUN: %clang -### -target x86_64 -fbasic-block-address-map %s -S 2>&1 |
FileCheck -check-prefix=CHECK-PRESENT %s
+// RUN: %clang -### -target aarch64 -fbasic-block-address-map %s -S 2>&1 |
FileCheck -check-prefix=CHECK-PRESENT %s
MaskRay wrote
https://github.com/MaskRay approved this pull request.
https://github.com/llvm/llvm-project/pull/82662
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> > I suppose the only question now is whether [[clang::assume]] should be
> > treated like [[assume]] if it’s not applied to a function declaration?
>
> THAT is an interesting question that @AaronBallman might have some comments
> on...
>
> Effectively, we have TWO 'assum
https://github.com/cjacek updated
https://github.com/llvm/llvm-project/pull/82888
>From 24c0fae7f777daa235ba435e1ae3479d26da526b Mon Sep 17 00:00:00 2001
From: Jacek Caban
Date: Sat, 24 Feb 2024 01:16:45 +0100
Subject: [PATCH] [llvm-ar][Archive] Use getDefaultTargetTriple instead of host
tripl
https://github.com/sudonatalie updated
https://github.com/llvm/llvm-project/pull/82536
>From 91600507765679e92434ec7c5edb883bf01f847f Mon Sep 17 00:00:00 2001
From: Natalie Chouinard
Date: Wed, 21 Feb 2024 21:18:20 +
Subject: [PATCH 1/3] [HLSL][SPIR-V] Add SV_DispatchThreadID semantic suppo
@@ -27,6 +27,7 @@
#include "llvm/CodeGen/GlobalISel/InstructionSelector.h"
#include "llvm/CodeGen/MachineInstrBuilder.h"
#include "llvm/CodeGen/MachineRegisterInfo.h"
+#include "llvm/IR/IntrinsicsDirectX.h"
sudonatalie wrote:
Good catch, thanks
https://github
erichkeane wrote:
We'd need to see what @alexey-bataev has to say about renaming the OMP assume
attribute. I imagine that'll end up causing a headache for his users.
https://github.com/llvm/llvm-project/pull/81014
___
cfe-commits mailing list
cfe-com
https://github.com/zixu-w approved this pull request.
LGTM. Thanks for making the change!
https://github.com/llvm/llvm-project/pull/82833
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commit
Author: Jacek Caban
Date: 2024-02-27T19:56:00+01:00
New Revision: 13fd4bf4e53391aab3cdfd922e9ceb4ad1225d1e
URL:
https://github.com/llvm/llvm-project/commit/13fd4bf4e53391aab3cdfd922e9ceb4ad1225d1e
DIFF:
https://github.com/llvm/llvm-project/commit/13fd4bf4e53391aab3cdfd922e9ceb4ad1225d1e.diff
L
https://github.com/cjacek closed https://github.com/llvm/llvm-project/pull/82888
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
cjacek wrote:
Thanks. I pushed without tests.
https://github.com/llvm/llvm-project/pull/82888
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/83103
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Sirraide wrote:
> LGTM!
Thanks. Just so you know, I still don’t have commit access, so you’d have to
merge it for me—I should really look into obtaining commit access at this point
perhaps
https://github.com/llvm/llvm-project/pull/83103
___
cfe-comm
https://github.com/PiJoules updated
https://github.com/llvm/llvm-project/pull/82855
>From 466aa42532902df2c13b539b44a4b31e80b13056 Mon Sep 17 00:00:00 2001
From: Leonard Chan
Date: Fri, 23 Feb 2024 16:57:58 -0800
Subject: [PATCH] [clang] Update -Wformat warnings for fixed-point format
specifie
Author: PiJoules
Date: 2024-02-27T11:09:38-08:00
New Revision: 40ba1f60e9f4b186d71272d4bc23b5af6204244d
URL:
https://github.com/llvm/llvm-project/commit/40ba1f60e9f4b186d71272d4bc23b5af6204244d
DIFF:
https://github.com/llvm/llvm-project/commit/40ba1f60e9f4b186d71272d4bc23b5af6204244d.diff
LOG:
Sirraide wrote:
I agree that renaming it to `openmp_assume` would probably avoid most
complications, so if that’s not too big of a deal for the people that use this
attribute then I’d probably go with that, otherwise option 3; with how
`[[assume]]` works, I don’t particularly see it appertaini
https://github.com/PiJoules closed
https://github.com/llvm/llvm-project/pull/82855
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
alexey-bataev wrote:
> We'd need to see what @alexey-bataev has to say about renaming the OMP assume
> attribute. I imagine that'll end up causing a headache for his users.
Thanks for the heads up. I don't think renaming to openmp_assume works for
OpenMP. We need to support `#pragma omp assume
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/83152
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman requested changes to this pull request.
Thank you for the fix!
There are some related test failures caught by precommit CI that need to be
addressed.
The issue in dr18xx.cpp looks to be a case where we should replace `bool b = `
with `auto b = ` (it doesn't cha
@@ -16538,6 +16538,27 @@ void Sema::DiagnoseAlwaysNonNullPointer(Expr *E,
}
}
+ // Complain if we are converting a lambda expression to a boolean value
+ if (auto *MCallExpr = dyn_cast(E)) {
+if (MCallExpr->getObjectType()->isRecordType()) {
+ if (auto *MRecor
@@ -16538,6 +16538,27 @@ void Sema::DiagnoseAlwaysNonNullPointer(Expr *E,
}
}
+ // Complain if we are converting a lambda expression to a boolean value
+ if (auto *MCallExpr = dyn_cast(E)) {
+if (MCallExpr->getObjectType()->isRecordType()) {
+ if (auto *MRecor
Sirraide wrote:
> Thanks for the heads up. I don't think renaming to openmp_assume works for
> OpenMP. We need to support `#pragma omp assume`, `[[omp::assume]]` and
> `[[using omp : assume]]` as defined by the standard.
Hmm, `[[omp::assume]]` shouldn’t be an issue, because that’s pretty clear
Sirraide wrote:
In that case, we could maybe combine some of the approaches—i.e. differentiate
the attributes based on appertainment, but also deprecate
`[[clang::assume]]`/`__attribute__((assume))` and tell people to use
`[[omp::assume]]` instead, if that is possible?
https://github.com/llvm
Sirraide wrote:
Wrt `[[clang::assume]]`/`__attribute__((assume))` applied to statements, those
aren’t valid today anyway, so not supporting the former wouldn’t be a breaking
change. We could consider supporting the latter though for GCC compatibility
(afaik GCC’s `__attribute__((assume))` is p
AaronBallman wrote:
> > LGTM!
>
> Thanks. Just so you know, I still don’t have commit access, so you’d have to
> merge it for me—I should really look into obtaining commit access at this
> point perhaps
Thank you for mentioning that! It turns out that GitHub is confusing:
)
return SubstAutoTypeDependent(TSInfo->getType());
- // We can only perform deduction for class templates.
+ // We can only perform deduction for class
@@ -2258,6 +2258,94 @@ class ExtractTypeForDeductionGuide
}
};
+// Build a deduction guide with the specified parameter types.
+FunctionTemplateDecl *
+buildDeductionGuide(Sema &SemaRef, TemplateDecl *OriginalTemplate,
+TemplateParameterList *TemplatePara
@@ -10598,10 +10598,36 @@ QualType
Sema::DeduceTemplateSpecializationFromInitializer(
if (TemplateName.isDependent())
return SubstAutoTypeDependent(TSInfo->getType());
- // We can only perform deduction for class templates.
+ // We can only perform deduction for class
@@ -10598,10 +10598,36 @@ QualType
Sema::DeduceTemplateSpecializationFromInitializer(
if (TemplateName.isDependent())
return SubstAutoTypeDependent(TSInfo->getType());
- // We can only perform deduction for class templates.
+ // We can only perform deduction for class
@@ -2612,44 +2669,313 @@ struct ConvertConstructorToDeductionGuideTransform {
SemaRef.CurrentInstantiationScope->InstantiatedLocal(OldParam, NewParam);
return NewParam;
}
+};
- FunctionTemplateDecl *buildDeductionGuide(
- TemplateParameterList *TemplateParams,
@@ -2000,6 +2001,21 @@ class alignas(TypeAlignment) Type : public
ExtQualsTypeCommonBase {
unsigned NumExpansions;
};
+ class CountAttributedTypeBitfields {
+friend class CountAttributedType;
+
+LLVM_PREFERRED_TYPE(TypeBitfields)
+unsigned : NumTypeBits;
+
101 - 200 of 338 matches
Mail list logo
