mikaelholmen wrote:
Hello,
I noticed that before this patch
```clang empty.c -fsanitize=undefined -ffine-grained-bitfield-accesses -c
-Werror```
(on empty file empty.c) resulted in
```warning: option '-ffine-grained-bitfield-accesses' cannot be enabled
together with a sanitizer; flag ignored``
https://github.com/owenca created
https://github.com/llvm/llvm-project/pull/108797
Fixes #64416.
>From 85e130d6e1fc1213f7daccf492aecc422c026c73 Mon Sep 17 00:00:00 2001
From: Owen Pan
Date: Mon, 16 Sep 2024 00:15:28 -0700
Subject: [PATCH] [clang-format] Fix a bug in SpacesInParens
InCondition
llvmbot wrote:
@llvm/pr-subscribers-clang-format
Author: Owen Pan (owenca)
Changes
Fixes #64416.
---
Full diff: https://github.com/llvm/llvm-project/pull/108797.diff
2 Files Affected:
- (modified) clang/lib/Format/TokenAnnotator.cpp (+17-19)
- (modified) clang/unittests/Format/FormatT
cor3ntin wrote:
> I'm not sure if this is acceptable for us.
Yes, I don't think this uncommon failure mode requires doing more heroics than
say we expect a parenthesis and don't crash
https://github.com/llvm/llvm-project/pull/108701
___
cfe-commits m
ganeshgit wrote:
> @ganeshgit or @RKSimon can one of you put up a PR against release/19.x with
> the abi compatible changes so that we have chance to look at it and approve
> it before the release tomorrow.
I will submit the changes shortly. Probably I will create a branch with a base
commit
https://github.com/NagyDonat created
https://github.com/llvm/llvm-project/pull/108799
Add a FIXME testcase which documents less than ideal behavior of the analyzer
when a `const char *` is converted to `const unsigned char *`. This testcase is
motivated by an ArrayBoundV2 report produced on th
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Donát Nagy (NagyDonat)
Changes
Add a FIXME testcase which documents less than ideal behavior of the analyzer
when a `const char *` is converted to `const unsigned char *`. This testcase is
motivated by an ArrayBoundV2 report produced on t
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `clang-s390x-linux` running
on `systemz-1` while building `clang,llvm` at step 5 "ninja check 1".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/42/builds/1089
Here is the relevant piece of the build
NagyDonat wrote:
This PR is primarily a "note to self", but it *is* NFC and ready to be merged
if we think that it'd be better to keep this reminder within the repository.
https://github.com/llvm/llvm-project/pull/108799
___
cfe-commits mailing list
c
Author: Daniel Kiss
Date: 2024-09-16T09:30:16+02:00
New Revision: cf2122cd0ad44ff578ebae54fe2f417895264587
URL:
https://github.com/llvm/llvm-project/commit/cf2122cd0ad44ff578ebae54fe2f417895264587
DIFF:
https://github.com/llvm/llvm-project/commit/cf2122cd0ad44ff578ebae54fe2f417895264587.diff
L
https://github.com/DanielKristofKiss closed
https://github.com/llvm/llvm-project/pull/107417
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/kadircet updated
https://github.com/llvm/llvm-project/pull/108524
From e63f2acd673183d15420b41ebe50a1c061de0905 Mon Sep 17 00:00:00 2001
From: Kadir Cetinkaya
Date: Fri, 13 Sep 2024 11:31:43 +0200
Subject: [PATCH] [Format] Dont treat LBrace after extends/implements as
initia
kadircet wrote:
added, ptal
https://github.com/llvm/llvm-project/pull/108524
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -880,14 +898,12 @@ ExprResult
Sema::BuildUnresolvedCoawaitExpr(SourceLocation Loc, Expr *Operand,
}
auto *RD = Promise->getType()->getAsCXXRecordDecl();
- bool AwaitElidable =
- isCoroAwaitElidableCall(Operand) &&
- isAttributedCoroAwaitElidable(
-
@@ -8261,12 +8261,19 @@ def CoroAwaitElidableDoc : Documentation {
The ``[[clang::coro_await_elidable]]`` is a class attribute which can be
applied
to a coroutine return type.
-When a coroutine function that returns such a type calls another coroutine
function,
-the compiler
@@ -3050,6 +3050,19 @@ as follows:
address space 0, this property only affects the default value to be used
when creating globals without additional contextual information (e.g. in
LLVM passes).
+``T``
+Specifies the address space for a target's 'flat' address s
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder
`openmp-offload-libc-amdgpu-runtime` running on `omp-vega20-1` while building
`clang` at step 10 "Add check check-offload".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/73/builds/5567
Here is the r
Author: Nikita Popov
Date: 2024-09-16T09:49:21+02:00
New Revision: 6d3f6c2170dd60e86743c205e33ead2f455656b4
URL:
https://github.com/llvm/llvm-project/commit/6d3f6c2170dd60e86743c205e33ead2f455656b4
DIFF:
https://github.com/llvm/llvm-project/commit/6d3f6c2170dd60e86743c205e33ead2f455656b4.diff
https://github.com/nikic closed https://github.com/llvm/llvm-project/pull/107601
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -243,14 +244,16 @@ class AnnotatingParser {
// operator that was misinterpreted because we are parsing template
// parameters.
// FIXME: This is getting out of hand, write a decent parser.
- if (InExpr && !Line.startsWith(tok::kw_template) &&
+ if
https://github.com/kadircet requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/108671
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/nikic approved this pull request.
https://github.com/llvm/llvm-project/pull/108794
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
Create a branch from `release/19.x` in your own fork, then cherry-pick over the
changes from `main`, edit them to match the things we talked about above (and
fix any merge problems). Then submit a PR that wants to merge `yourbranch` into
`release/19.x`. And check the checkbox `maint
llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `lld-x86_64-win` running on
`as-worker-93` while building `clang,llvm` at step 7
"test-build-unified-tree-check-all".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/146/builds/1161
Here is the releva
https://github.com/ganeshgit created
https://github.com/llvm/llvm-project/pull/108801
This patch enables the basic skeleton enablement of AMD next gen zen5 CPUs.
>From 688eeb285363bc2395aaac5fc2634f064c66a5b9 Mon Sep 17 00:00:00 2001
From: Ganesh Gopalasubramanian
Date: Mon, 16 Sep 2024 08:09
llvmbot wrote:
@llvm/pr-subscribers-clang-driver
Author: Ganesh (ganeshgit)
Changes
This patch enables the basic skeleton enablement of AMD next gen zen5 CPUs.
---
Patch is 31.54 KiB, truncated to 20.00 KiB below, full version:
https://github.com/llvm/llvm-project/pull/108801.diff
30
RKSimon wrote:
@ganeshgit @tru This looks to be a PR into main and not release/19.x ?
https://github.com/llvm/llvm-project/pull/108801
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
Yeah it needs to be towards the 19.x release branch as I described in my
comment here
https://github.com/llvm/llvm-project/pull/107964#issuecomment-2352261158
https://github.com/llvm/llvm-project/pull/108801
___
cfe-commits mailing list
c
ganeshgit wrote:
> Yeah it needs to be towards the 19.x release branch as I described in my
> comment here [#107964
> (comment)](https://github.com/llvm/llvm-project/pull/107964#issuecomment-2352261158)
Ignore this. I need to create a new fork with the target branch. My fork only
has "main".
https://github.com/ganeshgit closed
https://github.com/llvm/llvm-project/pull/108801
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ganeshgit wrote:
Will create new one for 19.x
https://github.com/llvm/llvm-project/pull/108801
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
MaskRay wrote:
Are these `musl*` environments blessed by upstream musl?
@richfelker
https://github.com/llvm/llvm-project/pull/107664
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mstorsjo wrote:
I've bisected breakage, on mingw x86 platforms relating to double vs long
double routines, down to this commit.
I'll follow up with more details when I manage to pinpoint what changes and
where, due to this change.
https://github.com/llvm/llvm-project/pull/108575
_
https://github.com/owenca approved this pull request.
https://github.com/llvm/llvm-project/pull/108524
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
MacDue wrote:
Thanks for letting me know, feel free to revert this change if it's a
non-trivial breakage.
https://github.com/llvm/llvm-project/pull/108575
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/
https://github.com/MaskRay requested changes to this pull request.
.
https://github.com/llvm/llvm-project/pull/104477
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/MainakSil created
https://github.com/llvm/llvm-project/pull/108804
Summary:
This PR fixes the issue where the VecLib bitfield in CodeGenOptions.def is too
small to accommodate the increasing number of vector libraries. Specifically,
the bitfield size was previously set to 3,
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Mainak Sil (MainakSil)
Changes
Summary:
This PR fixes the issue where the VecLib bitfield in CodeGenOptions.def is too
small to accommodate the increasing number of vector libraries. Specifically,
the bitfield size was previously set to 3
yashssh wrote:
Reigniting the discussion around `__cpp_static_assert`'s value set to `202306L`
. We are seeing some failures in perennial c++20 tests who assume the value of
macro to be `201411L` which is consistent with how GCC defines value of these
macros (see https://godbolt.org/z/xE9bWsdK
https://github.com/MainakSil created
https://github.com/llvm/llvm-project/pull/108805
Updated the example in the `StrictMode` section of the clang-tidy check
`modernize-use-std-print`.
The previous example incorrectly swapped the cast of signed and unsigned
integers. Specifically:
- The signe
llvmbot wrote:
@llvm/pr-subscribers-clang-tools-extra
Author: Mainak Sil (MainakSil)
Changes
Updated the example in the `StrictMode` section of the clang-tidy check
`modernize-use-std-print`.
The previous example incorrectly swapped the cast of signed and unsigned
integers. Specifically
llvmbot wrote:
@llvm/pr-subscribers-clang-tidy
Author: Mainak Sil (MainakSil)
Changes
Updated the example in the `StrictMode` section of the clang-tidy check
`modernize-use-std-print`.
The previous example incorrectly swapped the cast of signed and unsigned
integers. Specifically:
- The
https://github.com/MainakSil edited
https://github.com/llvm/llvm-project/pull/108804
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -196,8 +208,10 @@ define amdgpu_kernel void @add_i32_constant(ptr
addrspace(1) %out, ptr addrspace
; GFX11W32-NEXT:v_mbcnt_lo_u32_b32 v0, s1, 0
; GFX11W32-NEXT:; implicit-def: $vgpr1
; GFX11W32-NEXT:s_delay_alu instid0(VALU_DEP_1)
-; GFX11W32-NEXT:v_cmpx_eq_
yashssh wrote:
https://isocpp.org/files/papers/N4860.pdf according to this, cpp_static_assert
should be 201411L for c++20
https://github.com/llvm/llvm-project/pull/102044
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/
https://github.com/JustinStitt edited
https://github.com/llvm/llvm-project/pull/107332
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tbaederr created
https://github.com/llvm/llvm-project/pull/108811
We need to be a little more careful here with whether or nor we are able to do
the cast at all or not.
>From 462cd5016c72728ed120773a0da0aab1895649b1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Timm=20B=C3=A4der?
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Timm Baeder (tbaederr)
Changes
We need to be a little more careful here with whether or nor we are able to do
the cast at all or not.
---
Full diff: https://github.com/llvm/llvm-project/pull/108811.diff
2 Files Affected:
- (modified) c
Author: Anton Sidorenko
Date: 2024-09-16T13:09:37+03:00
New Revision: dbdf84388a825645850a47b035a1f7ab27b789b5
URL:
https://github.com/llvm/llvm-project/commit/dbdf84388a825645850a47b035a1f7ab27b789b5
DIFF:
https://github.com/llvm/llvm-project/commit/dbdf84388a825645850a47b035a1f7ab27b789b5.dif
https://github.com/asi-sc closed
https://github.com/llvm/llvm-project/pull/108406
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
MichelleCDjunaidi wrote:
Thanks for the feedback! Currently working on it.
https://github.com/llvm/llvm-project/pull/102299
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/alexfh approved this pull request.
Thanks! This fixes the issues we've found so far, and it seems to be a quite
clear correctness fix. LGTM
https://github.com/llvm/llvm-project/pull/108491
___
cfe-commits mailing list
cfe-commits@li
@@ -4652,18 +4652,35 @@ llvm::Constant *CodeGenModule::GetOrCreateLLVMFunction(
// If there are two attempts to define the same mangled name, issue an
// error.
-if (IsForDefinition && !Entry->isDeclaration()) {
- GlobalDecl OtherGD;
- // Check that GD is
@@ -0,0 +1,30 @@
+// REQUIRES: aarch64-registered-target
+
+// RUN: %clang_cc1 -triple aarch64 -target-feature +sme -target-feature +sme2
-emit-llvm -o - %s -verify -DTEST1
+// RUN: %clang_cc1 -triple aarch64 -target-feature +sme -target-feature +sme2
-emit-llvm -o - %s -verify
@@ -0,0 +1,30 @@
+// REQUIRES: aarch64-registered-target
+
+// RUN: %clang_cc1 -triple aarch64 -target-feature +sme -target-feature +sme2
-emit-llvm -o - %s -verify -DTEST1
+// RUN: %clang_cc1 -triple aarch64 -target-feature +sme -target-feature +sme2
-emit-llvm -o - %s -verify
@@ -4652,18 +4652,35 @@ llvm::Constant *CodeGenModule::GetOrCreateLLVMFunction(
// If there are two attempts to define the same mangled name, issue an
// error.
-if (IsForDefinition && !Entry->isDeclaration()) {
- GlobalDecl OtherGD;
- // Check that GD is
mstorsjo wrote:
I managed to reduce the breakage to the following snippet:
```c
long double powl(long double a, long double b);
long double a() { return powl(2.0L, 2.0L); }
```
Compiled like this:
```
$ clang -target x86_64-w64-mingw32 -S -O2 -o out.s repro.c
```
The output between before and aft
zyn0217 wrote:
> This is in turn because the [code that sets
> this](https://searchfox.org/llvm/rev/3ae71d154e5dfb5e5a5d27b3699b27ce2b55f44d/clang/lib/AST/Comment.cpp#238-243)
> is conditioned on FunctionDecl::getNumTemplateParameterLists() != 0.
I was curious why it is relying on `getNumTempl
@@ -33,7 +33,8 @@
#include "llvm/Support/Debug.h"
namespace {
VyacheslavLevytskyy wrote:
@AlexVlx Let's remove all references to `struct SyncScopeIDs` from the whole
`SPIRVInstructionSelector.cpp` module. We will insert
`getOrInsertSyncScopeID()` in the `ge
https://github.com/Fznamznon updated
https://github.com/llvm/llvm-project/pull/107260
>From da76f2dfd3b0c8e2a03165ad1ac06b517c4af391 Mon Sep 17 00:00:00 2001
From: "Podchishchaeva, Mariya"
Date: Wed, 4 Sep 2024 07:45:27 -0700
Subject: [PATCH 1/2] [clang][C23] Claim N3030 Enhancements to Enumera
@@ -0,0 +1,95 @@
+// RUN: %clang_cc1 -verify -triple x86_64-unknown-linux-gnu -fsyntax-only
--embed-dir=%S/Inputs -std=c23 %s -pedantic -Wall
Fznamznon wrote:
Done, thanks for the catch!
https://github.com/llvm/llvm-project/pull/107260
_
@@ -5413,18 +5413,20 @@ void Parser::ParseEnumSpecifier(SourceLocation
StartLoc, DeclSpec &DS,
BaseRange = SourceRange(ColonLoc,
DeclaratorInfo.getSourceRange().getEnd());
- if (!getLangOpts().ObjC && !getLangOpts().C23) {
+ if (!getLangOpts().ObjC) {
@@ -251,6 +251,24 @@ SPIRV::MemorySemantics::MemorySemantics
getMemSemantics(AtomicOrdering Ord) {
llvm_unreachable(nullptr);
}
+SPIRV::Scope::Scope getMemScope(const LLVMContext &Ctx, SyncScope::ID ID) {
VyacheslavLevytskyy wrote:
@AlexVlx If you don't mi
Author: Martin Storsjö
Date: 2024-09-16T13:51:16+03:00
New Revision: f71061258484390cb74752e9d7e486264aa4db0a
URL:
https://github.com/llvm/llvm-project/commit/f71061258484390cb74752e9d7e486264aa4db0a
DIFF:
https://github.com/llvm/llvm-project/commit/f71061258484390cb74752e9d7e486264aa4db0a.diff
@@ -251,6 +251,24 @@ SPIRV::MemorySemantics::MemorySemantics
getMemSemantics(AtomicOrdering Ord) {
llvm_unreachable(nullptr);
}
+SPIRV::Scope::Scope getMemScope(const LLVMContext &Ctx, SyncScope::ID ID) {
VyacheslavLevytskyy wrote:
I'd say that removal of
@@ -75,6 +75,8 @@
getMemSemanticsForStorageClass(SPIRV::StorageClass::StorageClass SC);
SPIRV::MemorySemantics::MemorySemantics getMemSemantics(AtomicOrdering Ord);
+SPIRV::Scope::Scope getMemScope(const LLVMContext &Ctx, SyncScope::ID ID);
VyacheslavLevytsk
AnastasiaStulova wrote:
> Thanks! Making sure I follow along, basically you're saying this patch is
> good because it keeps the ^^ token reserved, and if/when OpenCL supports C++,
> it can then use this token for reflection in C++ (if that's chosen by WG21
> for the syntax) or use it for its o
@@ -0,0 +1,95 @@
+// RUN: %clang_cc1 -verify -triple x86_64-unknown-linux-gnu -fsyntax-only
--embed-dir=%S/Inputs -std=c23 %s -pedantic -Wall
+
+#include
+
+enum us : unsigned short {
+ us_max = USHRT_MAX,
+ us_violation, // expected-error {{enumerator value 65536 is not
rep
VyacheslavLevytskyy wrote:
@AlexVlx I don't see much objections against
https://github.com/llvm/llvm-project/pull/108528 on a conceptual level, so what
do you think about merging it into this PR in a way that I commented above, by
changing getmemScope() and moving init into its static vars?
h
https://github.com/kmclaughlin-arm updated
https://github.com/llvm/llvm-project/pull/107581
>From 1e6f25c517d8d1adeeaf59f826141efdcad8f05a Mon Sep 17 00:00:00 2001
From: Kerry McLaughlin
Date: Fri, 6 Sep 2024 10:13:33 +
Subject: [PATCH 1/3] [Clang] Emit error for duplicate mangled names wit
https://github.com/cor3ntin approved this pull request.
https://github.com/llvm/llvm-project/pull/108491
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Xazax-hun approved this pull request.
Overall looks good to me, I have one question and a couple nits inline. I think
having access to Attr from AttributedType makes sense, I would not be surprised
if this helped some other use cases like Lifetime annotations in Crubit. But
@@ -8732,6 +8786,11 @@ static void processTypeAttrs(TypeProcessingState &state,
QualType &type,
case ParsedAttr::AT_HLSLParamModifier: {
HandleHLSLParamModifierAttr(state, type, attr, state.getSema());
attr.setUsedAsTypeAttr();
+ break;
+
@@ -6037,13 +6038,24 @@ class AttributedType : public Type, public
llvm::FoldingSetNode {
private:
friend class ASTContext; // ASTContext creates these
+ const Attr *Attribute;
+
QualType ModifiedType;
QualType EquivalentType;
AttributedType(QualType canon, attr
@@ -7147,6 +7147,60 @@ static bool
HandleWebAssemblyFuncrefAttr(TypeProcessingState &State,
return false;
}
+static void HandleSwiftAttr(TypeProcessingState &State, TypeAttrLocation TAL,
+QualType &QT, ParsedAttr &PAttr) {
+ if (TAL == TAL_DeclN
@@ -7163,7 +7217,8 @@ static QualType
rebuildAttributedTypeWithoutNullability(ASTContext &Ctx,
Ctx, Attributed->getModifiedType());
assert(Modified.getTypePtr() != Attributed->getModifiedType().getTypePtr());
return Ctx.getAttributedType(Attributed->getAttrKind(), Mo
https://github.com/Xazax-hun edited
https://github.com/llvm/llvm-project/pull/108631
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
pskrgag wrote:
sorry to bother, but seems like this pr is stalled for 2 weeks
https://github.com/llvm/llvm-project/pull/104599
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
gonzalobg wrote:
Is there some github issue or discourse thread that provides context for this
change?
What problem does this PR solve?
My understanding is that the default LLVM IR address space (*) is flat. Is that
currently the case or is my understanding incorrect? Is this PR proposing that
https://github.com/AaronBallman commented:
Thank you for catching this! Can you please add a release note to
`clang/docs/ReleaseNotes.rst` so users know about the fix?
I think these changes otherwise look good.
https://github.com/llvm/llvm-project/pull/96464
___
@@ -73,8 +73,6 @@ enum CPUFeatures {
FEAT_SSBS,
FEAT_SSBS2,
FEAT_BTI,
- FEAT_LS64,
- FEAT_LS64_V,
tmatheson-arm wrote:
@Wilco1 could you explain the scenario you are worried about in more detail?
What you posted above appears to be a snippet of a gene
https://github.com/cor3ntin approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/108224
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> > Thanks! Making sure I follow along, basically you're saying this patch is
> > good because it keeps the ^^ token reserved, and if/when OpenCL supports
> > C++, it can then use this token for reflection in C++ (if that's chosen by
> > WG21 for the syntax) or use it for i
Author: Aaron Ballman
Date: 2024-09-16T07:46:58-04:00
New Revision: 1881f648e28aa58aa0a4dca1422572f65dafa9a4
URL:
https://github.com/llvm/llvm-project/commit/1881f648e28aa58aa0a4dca1422572f65dafa9a4
DIFF:
https://github.com/llvm/llvm-project/commit/1881f648e28aa58aa0a4dca1422572f65dafa9a4.diff
https://github.com/AaronBallman closed
https://github.com/llvm/llvm-project/pull/108224
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
alexfh wrote:
@mizvekov another distinct compilation error after this commit (and not fixed
by https://github.com/llvm/llvm-project/pull/107972 and other follow-up
commits): https://gcc.godbolt.org/z/zMG5nsda3 (reduced from
https://github.com/hlslibs/ac_math/blob/20bbf040834c5815b01a9ed8e523e4
@@ -263,6 +263,23 @@ bool SVal::isZeroConstant() const {
// Pretty-Printing.
//===--===//
+StringRef SVal::getKindStr() const {
+ switch (getKind()) {
+#define BASIC_SVAL(Id, Parent)
carlosgalvezp wrote:
Thanks for the clarifications, will address asap!
It now comes to mind that we probably also want to check `memcpy(ptr, ptr)`,
which is equivalent to `bit_cast`. In that case I wonder if the check name
still holds or it should be named something else?
https://github.com/
https://github.com/MitalAshok created
https://github.com/llvm/llvm-project/pull/108817
https://cplusplus.github.io/CWG/issues/2915.html
Previously, `struct A { void f(this void); };` was accepted with `A::f` being a
member function with no non-object arguments, but it was still a little wonky
https://github.com/Szelethus updated
https://github.com/llvm/llvm-project/pull/108373
From cc823218d5cbb0b8f183bbadc9a32380c8e328a7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Krist=C3=B3f=20Umann?=
Date: Tue, 16 Jul 2024 15:06:06 +0200
Subject: [PATCH 1/2] [analyzer] Explicitly register NoStoreFu
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Mital Ashok (MitalAshok)
Changes
https://cplusplus.github.io/CWG/issues/2915.html
Previously, `struct A { void f(this void); };` was accepted with `A::f` being a
member function with no non-object arguments, but it was still a little wonk
zyn0217 wrote:
@HighCommander4
I extended your test case a little to validate the `TemplateDeclKind` we would
have.
```cpp
struct FoundComment {
std::string DeclName;
bool IsDefinition;
std::string Comment;
comments::DeclInfo::TemplateDeclKind TDK;
// ... comparators are snipped ...
}
https://github.com/AaronBallman approved this pull request.
LGTM! Do you need someone to land these changes on your behalf?
https://github.com/llvm/llvm-project/pull/108187
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/
@@ -1115,13 +1115,13 @@ void ASTWriter::WriteBlockInfoBlock() {
}
/// Prepares a path for being written to an AST file by converting it
-/// to an absolute path and removing nested './'s.
+/// to an absolute path and removing nested './'s and '../'s.
///
/// \return \c true
https://github.com/MitalAshok edited
https://github.com/llvm/llvm-project/pull/108817
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -251,6 +251,24 @@ SPIRV::MemorySemantics::MemorySemantics
getMemSemantics(AtomicOrdering Ord) {
llvm_unreachable(nullptr);
}
+SPIRV::Scope::Scope getMemScope(const LLVMContext &Ctx, SyncScope::ID ID) {
+ SmallVector SSNs;
+ Ctx.getSyncScopeNames(SSNs);
+
+ StringRef M
https://github.com/Szelethus approved this pull request.
LGTM! Do you have commit access?
https://github.com/llvm/llvm-project/pull/104599
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commi
@@ -58,7 +58,35 @@ class SPIRVTargetCodeGenInfo : public
CommonSPIRTargetCodeGenInfo {
SPIRVTargetCodeGenInfo(CodeGen::CodeGenTypes &CGT)
: CommonSPIRTargetCodeGenInfo(std::make_unique(CGT)) {}
void setCUDAKernelCallingConvention(const FunctionType *&FT) const overri
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/108701
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AlexVlx wrote:
> @AlexVlx I don't see much objections against #108528 on a conceptual level,
> so what do you think about merging it into this PR in a way that I commented
> above, by changing `getMemScope()` and moving `getOrInsertSyncScopeID()` into
> its static vars initialization?
At a gl
1 - 100 of 478 matches
Mail list logo
