@@ -4637,7 +4649,7 @@ def HLSLResourceBinding: InheritableAttr {
let AdditionalMembers = [{
public:
enum class RegisterType : unsigned { SRV, UAV, CBuffer, Sampler, C, I };
-
+
erichkeane wrote:
Please don't commit hte unrelated formatting changes.
@@ -1155,6 +1155,15 @@ Query for this feature with
``__has_attribute(diagnose_if)``.
}];
}
+def NoSpecializationsDocs : Documentation {
+ let Category = DocCatDecl;
+ let Content = [{
+``[[clang::no_specializations]]`` can be applied to function, class or variable
---
@@ -473,6 +473,7 @@ def ExpansionToDefined : DiagGroup<"expansion-to-defined">;
def FlagEnum : DiagGroup<"flag-enum">;
def IncrementBool : DiagGroup<"increment-bool", [DeprecatedIncrementBool]>;
def InfiniteRecursion : DiagGroup<"infinite-recursion">;
+def InvalidSpecialization
https://github.com/erichkeane edited
https://github.com/llvm/llvm-project/pull/101469
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/erichkeane approved this pull request.
https://github.com/llvm/llvm-project/pull/115762
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/erichkeane commented:
I THINK this looks right? X86 code ownership should probably make sure this is
still correct for x86. @phoebewang as the defacto owner of x86 function
multiversioning priority checking.
https://github.com/llvm/llvm-project/pull/116257
@@ -0,0 +1,34 @@
+! REQUIRES: arm-registered-target
+
+! RUN: %flang --target=arm-linux-gnu --print-supported-extensions 2>&1 \
+! RUN: | FileCheck --strict-whitespace --implicit-check-not=FEAT_ %s
+
+! CHECK: All available -march extensions for ARM
banach-space
@@ -0,0 +1,10 @@
+! Test that --print-supported-extensions errors on unsupported architectures.
+
+! REQUIRES: x86-registered-target
+
+! RUN: not %flang --target=x86_64-linux-gnu --print-supported-extensions \
+! RUN: 2>&1 | FileCheck %s
banach-space wrote:
As
llvmbot wrote:
@llvm/pr-subscribers-clang-driver
Author: AdityaK (hiraditya)
Changes
Details in: https://github.com/android/ndk/issues/1196
Fixes: https://github.com/android/ndk/issues/1294
---
Full diff: https://github.com/llvm/llvm-project/pull/117611.diff
1 Files Affected:
- (modifi
https://github.com/hiraditya edited
https://github.com/llvm/llvm-project/pull/117611
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/banach-space edited
https://github.com/llvm/llvm-project/pull/117402
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/banach-space commented:
Thanks, just a couple of questions.
https://github.com/llvm/llvm-project/pull/117402
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Artem-B wrote:
I am surprised that this is needed. I suspect clang picks the default CUDA
version on your machine.
While `--no-cuda-version-check` will make the test work, it will still pick
CUDA installation ourside of the source tree, and then suppress the error.
A better way to fix this ma
efriedma-quic wrote:
Yes, review comments don't indicate approval after the comments are addressed
unless the reviewer explicitly says that. The reviewer may want to take a look
at the updated changes, or responses to review comments, or maybe the review
wasn't complete for whatever reason.
https://github.com/hiraditya created
https://github.com/llvm/llvm-project/pull/117611
Details in: https://github.com/android/ndk/issues/1196
Fixes: https://github.com/android/ndk/issues/1294
>From 32cc67bbf00bde75fd1c681879106ae063363882 Mon Sep 17 00:00:00 2001
From: AdityaK
Date: Mon, 25 Nov
mikolaj-pirog wrote:
Thanks to the review above mentioning LTO, I realized that this solution has a
problem with LTO, namely using LTO + PGO/PGU, will only emit the LTCG string in
the binary. This is because right now the magic sections are only written in
the COFF object file emission. I will
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff 7ad1084b521ea191245c47b4e63e4f97035e3786
118415f00f96ffd005da8dddc5e776cb78c45f9f --e
zygoloid wrote:
If we do end up needing this (and it's looking increasingly likely that we
will), I think the general approach of having a set of callbacks that gets
passed into the constant evaluator is the right approach.
I think the older approach in this PR (a callback object that is expli
https://github.com/hiraditya updated
https://github.com/llvm/llvm-project/pull/117611
>From ae0074af2125871b79b8fac7e2433fa56e60f4bd Mon Sep 17 00:00:00 2001
From: AdityaK
Date: Mon, 25 Nov 2024 11:05:53 -0800
Subject: [PATCH] Add no-rosegment by default for API 29 and earlier.
Details in: htt
@@ -20,6 +20,20 @@ class SpaceShipDefaultCompare {
int operator<=>(const SpaceShipDefaultCompare &) const = default;
};
+class EqDefaultCompareOutOfClass {
+ int used; // no warning
erichkeane wrote:
Please explain a touch better with 'no warning'? Someth
https://github.com/erichkeane commented:
I've got no problem with this, but I definitely agree with a need to test
this/validate codegen to make sure the destruciton 'looks' reasonable.
https://github.com/llvm/llvm-project/pull/117483
___
cfe-commits
https://github.com/hekota edited
https://github.com/llvm/llvm-project/pull/114148
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rzinsly updated
https://github.com/llvm/llvm-project/pull/117612
>From ca1c76549c09fe1f46dfcd369648d145069ef1fc Mon Sep 17 00:00:00 2001
From: Raphael Moreira Zinsly
Date: Mon, 25 Nov 2024 14:51:35 -0300
Subject: [PATCH 1/2] [RISCV] Add initial stack clash protection
Enable
@@ -473,6 +473,7 @@ def ExpansionToDefined : DiagGroup<"expansion-to-defined">;
def FlagEnum : DiagGroup<"flag-enum">;
def IncrementBool : DiagGroup<"increment-bool", [DeprecatedIncrementBool]>;
def InfiniteRecursion : DiagGroup<"infinite-recursion">;
+def InvalidSpecialization
https://github.com/DavidTruby edited
https://github.com/llvm/llvm-project/pull/117573
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/DavidTruby requested changes to this pull request.
I think it makes sense to handle linker options differently so I'm in favour of
this change in principle.
Am I right in thinking that if the config file puts things last, the `-l`
options provided by users will come before t
@@ -61,3 +61,22 @@
! CHECK-TWO-CONFIGS-NEXT: Configuration file:
{{.*}}Inputs{{.}}config2{{.}}config-4.cfg
! CHECK-TWO-CONFIGS: -ffp-contract=fast
! CHECK-TWO-CONFIGS: -O3
+
+!--- The -l flags should be moved to the end of input list and appear only
when linking.
+! RUN: %fla
@@ -473,6 +473,7 @@ def ExpansionToDefined : DiagGroup<"expansion-to-defined">;
def FlagEnum : DiagGroup<"flag-enum">;
def IncrementBool : DiagGroup<"increment-bool", [DeprecatedIncrementBool]>;
def InfiniteRecursion : DiagGroup<"infinite-recursion">;
+def InvalidSpecialization
@@ -5445,6 +5445,10 @@ def note_dependent_function_template_spec_discard_reason
: Note<
"candidate ignored: %select{not a function template|"
"not a member of the enclosing %select{class template|"
"namespace; did you mean to explicitly qualify the specialization?}1}0">;
https://github.com/DKLoehr created
https://github.com/llvm/llvm-project/pull/117622
When a hidden object is built into multiple shared libraries, each instance of
the library will get its own copy. If
the object was supposed to be globally unique (e.g. a global variable or static
data member),
https://github.com/hekota edited
https://github.com/llvm/llvm-project/pull/117608
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AlexVlx wrote:
Thank you for this, unfortunately I don't quite see the reason for adding
another twiddly bit here. We are long term migrating away from the
default-is-private hack, and to get the benefits you are looking for you can
simply compile for CL2, or enable the generic as extension, f
github-actions[bot] wrote:
Thank you for submitting a Pull Request (PR) to the LLVM Project!
This PR will be automatically labeled and the relevant teams will be notified.
If you wish to, you can add reviewers by using the "Reviewers" section on this
page.
If this is not working for you, it
https://github.com/bogner approved this pull request.
https://github.com/llvm/llvm-project/pull/117608
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Devon Loehr (DKLoehr)
Changes
When a hidden object is built into multiple shared libraries, each instance of
the library will get its own copy. If
the object was supposed to be globally unique (e.g. a global variable or static
data member
https://github.com/AlexVlx requested changes to this pull request.
In principle I am against this, it adds a relatively brittle hook, and bypasses
the pre-existing mechanisms (use CL2 or enable the generic-as extension) for
obtaining this behaviour, in a way that does not ensure that the pre-ex
https://github.com/hiraditya created
https://github.com/llvm/llvm-project/pull/117624
Patch copied from:
https://github.com/android/ndk/issues/909#issuecomment-649872696
Fixes: https://github.com/android/ndk/issues/909
>From ae0074af2125871b79b8fac7e2433fa56e60f4bd Mon Sep 17 00:00:00 2001
Fr
llvmbot wrote:
@llvm/pr-subscribers-clang-driver
@llvm/pr-subscribers-clang
Author: AdityaK (hiraditya)
Changes
Patch copied from:
https://github.com/android/ndk/issues/909#issuecomment-649872696
Fixes: https://github.com/android/ndk/issues/909
---
Full diff: https://github.com/llvm/llv
efriedma-quic wrote:
The type of an alloca is only used to determine the number of bytes allocated;
it doesn't have any other semantics. So it's fine as long as the alloca is 16
bytes. Which I think it is in the given example, because of the datalayout
rules for `<3 x i32>`.
https://github.
Sirraide wrote:
> The type of an alloca is only used to determine the number of bytes allocated;
Yeah, that part I know; I was mainly just wondering if there’s a
platform/abi/whatever where that doesn’t work out.
https://github.com/llvm/llvm-project/pull/117487
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff b0ca543532d13fde8907853f6c9909ad7e68cd9f
0940f24788e9398dfbd8cc92d12d7c803693a172 --e
5chmidti wrote:
Ping
https://github.com/llvm/llvm-project/pull/113837
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/s-perron approved this pull request.
https://github.com/llvm/llvm-project/pull/117303
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3535,6 +3536,39 @@ void CXXNameMangler::mangleExtFunctionInfo(const
FunctionType *T) {
// FIXME: noreturn
}
+bool hasSharedState(unsigned SMEAttrs) {
+ switch (SMEAttrs) {
+ case FunctionType::ARM_In:
+ case FunctionType::ARM_Out:
+ case FunctionType::ARM_InOut:
+
llvmbot wrote:
@llvm/pr-subscribers-backend-amdgpu
Author: Jakub Chlanda (jchlanda)
Changes
`opencl-def-is-generic-addrspace` sets the default address space from private
to generic. This feature allows for building bitcode libraries written in
OpenCL that can then be linked against modul
DavidTruby wrote:
Thanks for the fix, I'd like to understand what the bug is better though; what
is the difference between the proposed `flang -fc1 -x f95-fixed` and the
existing `flang -fc1 -ffixed-form`?
In the test case in here I already don't see an error with `flang -fc1
-ffixed-form`, i
bogner wrote:
This isn't testing the AST, so it shouldn't be in the `test/AST` folder. In any
case, I think there's sufficient coverage by the changes to the
`CodeGenHLSL/builtins` tests and `TypesTest`, so this one can probably just be
removed.
https://gith
@@ -40,10 +40,43 @@ TEST(TypesTest, TargetExtType) {
Type *A = TargetExtType::get(Context, "typea");
Type *Aparam = TargetExtType::get(Context, "typea", {}, {0, 1});
Type *Aparam2 = TargetExtType::get(Context, "typea", {}, {0, 1});
+
// Opaque types with same parameter
https://github.com/jchlanda created
https://github.com/llvm/llvm-project/pull/117588
`opencl-def-is-generic-addrspace` sets the default address space from private
to generic. This feature allows for building bitcode libraries written in
OpenCL that can then be linked against modules compiled f
@@ -40,10 +40,43 @@ TEST(TypesTest, TargetExtType) {
Type *A = TargetExtType::get(Context, "typea");
Type *Aparam = TargetExtType::get(Context, "typea", {}, {0, 1});
Type *Aparam2 = TargetExtType::get(Context, "typea", {}, {0, 1});
+
// Opaque types with same parameter
@@ -40,10 +40,43 @@ TEST(TypesTest, TargetExtType) {
Type *A = TargetExtType::get(Context, "typea");
Type *Aparam = TargetExtType::get(Context, "typea", {}, {0, 1});
Type *Aparam2 = TargetExtType::get(Context, "typea", {}, {0, 1});
+
// Opaque types with same parameter
@@ -40,10 +40,43 @@ TEST(TypesTest, TargetExtType) {
Type *A = TargetExtType::get(Context, "typea");
Type *Aparam = TargetExtType::get(Context, "typea", {}, {0, 1});
Type *Aparam2 = TargetExtType::get(Context, "typea", {}, {0, 1});
+
// Opaque types with same parameter
@@ -480,10 +468,7 @@ Decl *Parser::ParseExportDeclaration() {
while (!tryParseMisplacedModuleImport() && Tok.isNot(tok::r_brace) &&
Tok.isNot(tok::eof)) {
-ParsedAttributes DeclAttrs(AttrFactory);
-MaybeParseCXX11Attributes(DeclAttrs);
erich
@@ -2314,10 +2314,12 @@ Parser::DeclGroupPtrTy
Parser::ParseOpenMPDeclarativeDirectiveWithExtDecl(
// Here we expect to see some function declaration.
if (AS == AS_none) {
assert(TagType == DeclSpec::TST_unspecified);
-ParsedAttributes EmptyDeclSpec
@@ -294,9 +294,11 @@ constructHexagonLinkArgs(Compilation &C, const JobAction
&JA,
bool IncStartFiles = !Args.hasArg(options::OPT_nostartfiles);
bool IncDefLibs = !Args.hasArg(options::OPT_nodefaultlibs);
bool UseG0 = false;
- const char *Exec = Args.MakeArgString(HTC.G
https://github.com/arsenm edited
https://github.com/llvm/llvm-project/pull/117380
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/arsenm edited
https://github.com/llvm/llvm-project/pull/117383
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mshockwave wrote:
ping
https://github.com/llvm/llvm-project/pull/116878
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/androm3da updated
https://github.com/llvm/llvm-project/pull/117338
>From 6f5c0375547337afbaa9b3f2446be6bbe79b4300 Mon Sep 17 00:00:00 2001
From: Brian Cain
Date: Thu, 21 Nov 2024 19:46:04 -0800
Subject: [PATCH] [clang] recognize any *-ld.lld variant
If we create a cross tool
@@ -0,0 +1,80 @@
+if (NOT DEFINED LLVM_PATH)
androm3da wrote:
That was a careless mistake, failed to keep different development branches
separate.
Fixed.
https://github.com/llvm/llvm-project/pull/117338
___
cfe-comm
https://github.com/arsenm edited
https://github.com/llvm/llvm-project/pull/117417
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,80 @@
+if (NOT DEFINED LLVM_PATH)
androm3da wrote:
ugh! sorry, this was unintentional. I'll fix it.
https://github.com/llvm/llvm-project/pull/117338
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/zygoloid approved this pull request.
https://github.com/llvm/llvm-project/pull/117364
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2010,6 +2032,25 @@ class CXXDeductionGuideDecl : public FunctionDecl {
/// this is an implicit deduction guide.
CXXConstructorDecl *getCorrespondingConstructor() const { return Ctor; }
+ /// Get the deduction guide from which this deduction guide was generated,
+ ///
https://github.com/arsenm edited
https://github.com/llvm/llvm-project/pull/117384
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/117364
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3535,6 +3536,74 @@ void CXXNameMangler::mangleExtFunctionInfo(const
FunctionType *T) {
// FIXME: noreturn
}
+enum SMEState {
+ Normal = 0,
+ SM_Enabled = 1 << 0,
+ SM_Compatible = 1 << 1,
+ ZA_Agnostic = 1 << 2,
+ ZA_Shift = 3,
+ ZT0_Shift = 6,
+ None = 0b000,
+
https://github.com/topperc approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/114014
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman updated
https://github.com/llvm/llvm-project/pull/114544
>From 6a9f356c13a2a391909cc2161318e4d6300e6a48 Mon Sep 17 00:00:00 2001
From: Aaron Ballman
Date: Fri, 1 Nov 2024 10:43:14 -0400
Subject: [PATCH 1/9] Rename CODE_OWNERS -> Maintainers
---
clang-tools-extr
Author: Aaron Ballman
Date: 2024-11-25T13:01:25-05:00
New Revision: 00770489e4299fe6ab99b1772127d84dfe222ffc
URL:
https://github.com/llvm/llvm-project/commit/00770489e4299fe6ab99b1772127d84dfe222ffc
DIFF:
https://github.com/llvm/llvm-project/commit/00770489e4299fe6ab99b1772127d84dfe222ffc.diff
dwblaikie wrote:
(please don't merge PRs that haven't been approved, that's against LLVM
practices/policies ( https://llvm.org/docs/CodeReview.html#code-review-workflow
), unless they weren't intended for pre-commit review in the first place (if
they were only meant for presubmit checks))
htt
@@ -3536,35 +3536,64 @@ void CXXNameMangler::mangleExtFunctionInfo(const
FunctionType *T) {
// FIXME: noreturn
}
-bool hasSharedState(unsigned SMEAttrs) {
+unsigned getZAState(unsigned SMEAttrs) {
switch (SMEAttrs) {
case FunctionType::ARM_In:
+return 1;
case F
https://github.com/RKSimon commented:
Update LanguageExtensions.rst to mention __builtin_elementwise_popcount is
constexpr compatible
https://github.com/llvm/llvm-project/pull/117473
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://list
uweigand wrote:
Hi @anoopkg6 , the tests are still failing in CI because this is hosted on an
Intel machine, so when you run just with `llc`, it will attempt to build the
test for Intel ...
To make sure the tests run correctly and always target s390x, you should use
something along the follow
ilya-biryukov wrote:
> Does preprocessing from AST files
> ([ab75597](https://github.com/llvm/llvm-project/commit/ab75597ddac52f24e9cbd794cded195262ef670e))
> with decluse checking
> ([f3f8461](https://github.com/llvm/llvm-project/commit/f3f846162a5d6b5b84ed7d146a29dc175542c2c0))
> still work
stuij wrote:
I feel that in `useFramePointerForTargetByDef` fn, in general things are
predicated first on platform and then on arch. That L85 arch switch statement
seems to serve as a "these arches don't do anything special" early return.
It's up to interpretation, but putting the different Ar
https://github.com/arsenm edited
https://github.com/llvm/llvm-project/pull/117418
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Endilll wrote:
I added Sema callback into the new interpreter in
0b2d92e0fed41ee2428c3ef8b8369790a1279a21. I think it went smoothly, save for
the fact that source locations are not always readily available there, but they
are need to correctly emit diagnostics from Sema.
I invite @tbaederr to
hekota wrote:
[First version](llvm/llvm-project#114148) of this PR was reverted because of
build break.
https://github.com/llvm/llvm-project/pull/117608
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/lis
@@ -2314,10 +2314,12 @@ Parser::DeclGroupPtrTy
Parser::ParseOpenMPDeclarativeDirectiveWithExtDecl(
// Here we expect to see some function declaration.
if (AS == AS_none) {
assert(TagType == DeclSpec::TST_unspecified);
-ParsedAttributes EmptyDeclSpec
compnerd wrote:
> > The default behaviour of `ids` is to assume that anything declared in the
> > header is public and it will ensure that anything added in the headers is
> > annotated properly to say it is exposed, making something private would be
> > an explicit decision that the developer
fsfod wrote:
> I can absolutely see the value in the opposite - minimise the ABI surface.
> For many projects, there is a split of internal and external headers. The
> idea is that this tool is only run on the external headers, so those are
> meant to be ABI.
There were multiple internals hea
Endilll wrote:
@zygoloid I definitely don't disagree with your points. After extensive
discussions with other maintainers (Shafik, Corentin, Erich, Aaron), I went
from passing the callback explicitly to very implicit approach, because of
reasons that lie outside of usage of AST in Clang itself
https://github.com/N-Dekker created
https://github.com/llvm/llvm-project/pull/117629
>From C++11, a conforming `size()` method is guaranteed to be a constant-time
>function. `empty()` is not _generally_ more efficient than `size()`. It might
>even be implemented in terms of `size()`.
No
llvmbot wrote:
@llvm/pr-subscribers-clang-tools-extra
Author: Niels Dekker (N-Dekker)
Changes
>From C++11, a conforming `size()` method is guaranteed to be a constant-time
>function. `empty()` is not _generally_ more efficient than `size()`. It might
>even be implemented in terms of `siz
Endilll wrote:
> the special "the language rules say this is manifestly constant evaluated"
> cases that should be able to perform AST mutations, that we need to be
> extremely careful to invoke at exactly the right times and in exactly the
> right cases and to invoke only once
Can you expand
github-actions[bot] wrote:
Thank you for submitting a Pull Request (PR) to the LLVM Project!
This PR will be automatically labeled and the relevant teams will be notified.
If you wish to, you can add reviewers by using the "Reviewers" section on this
page.
If this is not working for you, it
https://github.com/inbelic closed
https://github.com/llvm/llvm-project/pull/112400
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/inbelic closed
https://github.com/llvm/llvm-project/pull/112991
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tex3d approved this pull request.
I think this will do for now, since most of this will have to be reworked for
general semantics support anyway.
https://github.com/llvm/llvm-project/pull/115911
___
cfe-commits mailing list
cfe-comm
https://github.com/dzenanz approved this pull request.
https://github.com/llvm/llvm-project/pull/117629
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/labrinea updated
https://github.com/llvm/llvm-project/pull/115762
>From aff962d795e56f7b41af44860feb77e656091b78 Mon Sep 17 00:00:00 2001
From: Alexandros Lamprineas
Date: Mon, 11 Nov 2024 20:10:01 +
Subject: [PATCH 1/3] [clang][FMV] Fix crash with cpu_specific attribute.
@@ -271,53 +246,70 @@ struct BuiltinTypeDeclBuilder {
return *this;
}
+ FieldDecl *getResourceHandleField() {
+FieldDecl *FD = Fields["h"];
tex3d wrote:
I thought `lookup` was right:
https://github.com/llvm/llvm-project/blob/30af6fb163add17a6be5152
N-Dekker wrote:
A personal note: yes, I like clang-tidy's readibility-container-size-empty
check, I think it's great! And I do very much prefer `empty()` over `size()`
"whenever possible". It's just that I think the claims in the documentation
about efficiency and time complexity are no longer
PiotrZSL wrote:
You understand that this check does not apply only to std:: containers but also
to boost and other custom one that have size and empty methods. In such case
claim is still valid. If you change check description, then check documentation
also should be updated to be in sync.
ht
zygoloid wrote:
> 1. Asking users to pass additional parameter to every `Eval*()` function
> makes a bad transition story for users that wish to upgrade to a version of
> Clang that has changed the interface in this way.
External callers of the `Eval*` functions in almost all cases should not
efriedma-quic wrote:
(For context, grep for PreserveVec3Type.)
Probably the code should be defensive and check for the allocation size of the
vector type, but I don't think any targets define the alignment for
non-power-of-2 vectors in a way that would cause issues.
https://github.com/llvm/ll
zygoloid wrote:
> > the special "the language rules say this is manifestly constant evaluated"
> > cases that should be able to perform AST mutations, that we need to be
> > extremely careful to invoke at exactly the right times and in exactly the
> > right cases and to invoke only once
>
> C
@@ -4683,13 +4683,22 @@ void CGOpenMPRuntime::emitTaskLoopCall(CodeGenFunction
&CGF, SourceLocation Loc,
Data.Schedule.getPointer()
? CGF.Builder.CreateIntCast(Data.Schedule.getPointer(), CGF.Int64Ty,
/*isSigned=*/false)
-
N-Dekker wrote:
> You understand that this check does not apply only to std:: containers but
> also to boost and other custom one that have size and empty methods. In such
> case claim is still valid.
Thanks for your prompt reply, Piotr. I thought of custom containers too, but
then again, I w
101 - 200 of 525 matches
Mail list logo
