nikic wrote:
Good point, I've changed this to use HINTS instead of PATHS. I'm not really
sure which one is more "correct" in this context, but sticking closer to the
previous behavior seems like a good idea...
https://github.com/llvm/llvm-project/pull/126071
__
https://github.com/nikic updated
https://github.com/llvm/llvm-project/pull/126071
>From 2badb9749472014dc02610a3a511b548bfe8a2ae Mon Sep 17 00:00:00 2001
From: Nikita Popov
Date: Thu, 6 Feb 2025 14:56:25 +0100
Subject: [PATCH 1/2] [libclc] Allow default path when looking for llvm-spirv
This is
https://github.com/nikic created
https://github.com/llvm/llvm-project/pull/125880
TODO: PR description, a few extra tests.
>From 5be3d8b312365ef8919792703d3fe71d1e39eb53 Mon Sep 17 00:00:00 2001
From: Nikita Popov
Date: Thu, 30 Jan 2025 12:08:01 +0100
Subject: [PATCH] wip
---
clang/test/Code
nikic wrote:
/cherry-pick 26ecddb05d13c101ccd840a6710eb5f8b82de841
https://github.com/llvm/llvm-project/pull/126071
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/nikic milestoned
https://github.com/llvm/llvm-project/pull/126071
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/nikic closed https://github.com/llvm/llvm-project/pull/126071
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/nikic updated
https://github.com/llvm/llvm-project/pull/125880
>From 2f698e27ae61b91019544cc707c134e0aec9ecd3 Mon Sep 17 00:00:00 2001
From: Nikita Popov
Date: Thu, 30 Jan 2025 12:08:01 +0100
Subject: [PATCH 1/3] [CaptureTracking][FunctionAttrs] Add support for
CaptureInfo
https://github.com/nikic updated
https://github.com/llvm/llvm-project/pull/125880
>From 2f698e27ae61b91019544cc707c134e0aec9ecd3 Mon Sep 17 00:00:00 2001
From: Nikita Popov
Date: Thu, 30 Jan 2025 12:08:01 +0100
Subject: [PATCH 1/4] [CaptureTracking][FunctionAttrs] Add support for
CaptureInfo
@@ -94,31 +96,53 @@ namespace llvm {
/// U->getUser() is always an Instruction.
virtual bool shouldExplore(const Use *U);
-/// captured - Information about the pointer was captured by the user of
-/// use U. Return true to stop the traversal or false to continu
@@ -438,18 +448,21 @@ void llvm::PointerMayBeCaptured(const Value *V,
CaptureTracker *Tracker,
};
while (!Worklist.empty()) {
const Use *U = Worklist.pop_back_val();
-switch (DetermineUseCaptureKind(*U, IsDereferenceableOrNull)) {
-case UseCaptureKind::NO_CAPTU
@@ -71,7 +71,9 @@ using namespace llvm;
#define DEBUG_TYPE "function-attrs"
STATISTIC(NumMemoryAttr, "Number of functions with improved memory attribute");
-STATISTIC(NumNoCapture, "Number of arguments marked nocapture");
+STATISTIC(NumCapturesNone, "Number of arguments marked
@@ -94,31 +96,53 @@ namespace llvm {
/// U->getUser() is always an Instruction.
virtual bool shouldExplore(const Use *U);
-/// captured - Information about the pointer was captured by the user of
-/// use U. Return true to stop the traversal or false to continu
@@ -1281,17 +1321,15 @@ static void addArgumentAttrs(const SCCNodeSet &SCCNodes,
if (ArgumentSCC[0]->Uses.size() == 1 &&
ArgumentSCC[0]->Uses[0] == ArgumentSCC[0]) {
Argument *A = ArgumentSCC[0]->Definition;
-A->addAttr(Attribute::getWithCaptureI
@@ -194,6 +194,10 @@ class LocationSize {
return hasValue() && getValue() == Other;
}
+ bool operator<=(const LocationSize &Other) const {
+return Value <= Other.Value;
nikic wrote:
LocationSize has a whole bunch of special values and bits that mak
@@ -587,11 +587,31 @@ class LLVM_ABI Function : public GlobalObject, public
ilist_node {
bool onlyAccessesInaccessibleMemory() const;
void setOnlyAccessesInaccessibleMemory();
+ /// Determine if the function may only access errno memory.
+ bool onlyAccessesErrnoMemory()
@@ -789,6 +789,10 @@ enum AttributeKindCodes {
ATTR_KIND_NO_DIVERGENCE_SOURCE = 100,
ATTR_KIND_SANITIZE_TYPE = 101,
ATTR_KIND_CAPTURES = 102,
+ ATTR_KIND_ERRNOMEMONLY = 103,
+ ATTR_KIND_INACCESSIBLEMEM_OR_ERRNOMEMONLY = 104,
+ ATTR_KIND_ARGMEM_OR_ERRNOMEMONLY = 105,
+
@@ -2293,9 +2318,21 @@ static bool upgradeOldMemoryAttribute(MemoryEffects &ME,
uint64_t EncodedKind) {
case bitc::ATTR_KIND_INACCESSIBLEMEM_ONLY:
ME &= MemoryEffects::inaccessibleMemOnly();
return true;
+ case bitc::ATTR_KIND_ERRNOMEMONLY:
+ME &= MemoryEffects:
@@ -126,8 +126,21 @@ static void addLocAccess(MemoryEffects &ME, const
MemoryLocation &Loc,
return;
if (isa(UO)) {
ME |= MemoryEffects::argMemOnly(MR);
+if (Loc.Size <= LocationSize::precise(sizeof(int)))
+ ME |= MemoryEffects::errnoMemOnly(MR);
@@ -201,11 +201,16 @@ enum Kind {
kw_readwrite,
kw_argmem,
kw_inaccessiblemem,
+ kw_errnomem,
// Legacy attributes:
kw_argmemonly,
kw_inaccessiblememonly,
kw_inaccessiblemem_or_argmemonly,
+ kw_inaccessiblemem_or_errnomemonly,
+ kw_argmem_or_errnomemonly,
@@ -126,8 +126,21 @@ static void addLocAccess(MemoryEffects &ME, const
MemoryLocation &Loc,
return;
if (isa(UO)) {
ME |= MemoryEffects::argMemOnly(MR);
+if (Loc.Size <= LocationSize::precise(sizeof(int)))
+ ME |= MemoryEffects::errnoMemOnly(MR);
return;
@@ -126,8 +126,21 @@ static void addLocAccess(MemoryEffects &ME, const
MemoryLocation &Loc,
return;
if (isa(UO)) {
ME |= MemoryEffects::argMemOnly(MR);
+if (Loc.Size <= LocationSize::precise(sizeof(int)))
+ ME |= MemoryEffects::errnoMemOnly(MR);
return;
@@ -1915,11 +1915,31 @@ class CallBase : public Instruction {
bool onlyAccessesInaccessibleMemory() const;
void setOnlyAccessesInaccessibleMemory();
+ /// Determine if the function may only access errno memory.
+ bool onlyAccessesErrnoMemory() const;
+ void setOnlyAcces
https://github.com/nikic approved this pull request.
LGTM
> I don't know if directly using the CodeGenModule here is the best solution.
> Let me know if there's something better to use.
I think that's ok. The alternative would be Builder.getContext().
https://github.com/llvm/llvm-project/pull
nikic wrote:
Well, I guess you could also use Builder.getPtrTy() for the whole thing...
https://github.com/llvm/llvm-project/pull/124782
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -438,18 +445,28 @@ void llvm::PointerMayBeCaptured(const Value *V,
CaptureTracker *Tracker,
};
while (!Worklist.empty()) {
const Use *U = Worklist.pop_back_val();
-switch (DetermineUseCaptureKind(*U, IsDereferenceableOrNull)) {
-case UseCaptureKind::NO_CAPTU
https://github.com/nikic updated
https://github.com/llvm/llvm-project/pull/125880
>From 2f698e27ae61b91019544cc707c134e0aec9ecd3 Mon Sep 17 00:00:00 2001
From: Nikita Popov
Date: Thu, 30 Jan 2025 12:08:01 +0100
Subject: [PATCH 1/5] [CaptureTracking][FunctionAttrs] Add support for
CaptureInfo
@@ -210,7 +210,7 @@ class PointerType : public Type {
return Name + " *";
}
std::string llvmName() const override {
-return "llvm::PointerType::getUnqual(" + Pointee->llvmName() + ")";
+return "llvm::PointerType::getUnqual(Builder.getPtrTy())";
@@ -438,18 +445,28 @@ void llvm::PointerMayBeCaptured(const Value *V,
CaptureTracker *Tracker,
};
while (!Worklist.empty()) {
const Use *U = Worklist.pop_back_val();
-switch (DetermineUseCaptureKind(*U, IsDereferenceableOrNull)) {
-case UseCaptureKind::NO_CAPTU
https://github.com/nikic updated
https://github.com/llvm/llvm-project/pull/125880
>From 2f698e27ae61b91019544cc707c134e0aec9ecd3 Mon Sep 17 00:00:00 2001
From: Nikita Popov
Date: Thu, 30 Jan 2025 12:08:01 +0100
Subject: [PATCH 1/6] [CaptureTracking][FunctionAttrs] Add support for
CaptureInfo
@@ -438,18 +445,28 @@ void llvm::PointerMayBeCaptured(const Value *V,
CaptureTracker *Tracker,
};
while (!Worklist.empty()) {
const Use *U = Worklist.pop_back_val();
-switch (DetermineUseCaptureKind(*U, IsDereferenceableOrNull)) {
-case UseCaptureKind::NO_CAPTU
https://github.com/nikic approved this pull request.
https://github.com/llvm/llvm-project/pull/126677
___
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/126672
___
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/126674
___
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/125381
___
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/125380
___
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/125379
___
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/125456
___
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/125335
___
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/125336
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nikic wrote:
> so IIUC !llvm.errno.tbaa should just be a module-level list of int-compatible
> TBAA nodes.
Yes, exactly. It should be a module level MD node, not on individual
instructions.
https://github.com/llvm/llvm-project/pull/125258
___
cfe-co
https://github.com/nikic commented:
Other builtins like __builtin_frame_address and __builtin_return_address map
onto an llvm intrinsic like llvm.frameaddress or llvm.returnaddress. What's the
reason for not following this design for __builtin_stack_address?
https://github.com/llvm/llvm-projec
https://github.com/nikic updated
https://github.com/llvm/llvm-project/pull/119365
>From 361b821793862e80ca61df906e7d914fd5bd2fc1 Mon Sep 17 00:00:00 2001
From: Nikita Popov
Date: Tue, 10 Dec 2024 12:51:03 +0100
Subject: [PATCH 1/2] [BasicAA] Do not decompose past casts with different
index wid
https://github.com/nikic closed https://github.com/llvm/llvm-project/pull/119225
___
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/119673
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nikic wrote:
I think https://github.com/llvm/llvm-test-suite/pull/190 should fix this issue,
but haven't tested on an affected arch.
I'm a bit worried that we don't have a sanitizer to catch this issue (the
negative left shift issue is an unrelated one).
https://github.com/llvm/llvm-project/p
nikic wrote:
>From a quick look, it's probably due to UB on this line:
>https://github.com/llvm/llvm-test-suite/blob/4f14adb8a2f2c5fa02c6b3643d45e74adfcb31f9/SingleSource/Benchmarks/CoyoteBench/huffbench.c#L114
> It indexes below the start of an object.
https://github.com/llvm/llvm-project/pull
nikic wrote:
It looks like this somehow negatively affects stage2 clang performance:
https://llvm-compile-time-tracker.com/compare.php?from=00e1cc4c9d002c78cf890b630343b052ebca0399&to=624cc7048f604ed1087f63fdbe4cbf40f1d35b69&stat=instructions:u
https://github.com/llvm/llvm-project/pull/119523
_
https://github.com/nikic requested changes to this pull request.
This is no longer the case after
[N3322](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3322.pdf).
(Incidentally, I wrote a blog post about this yesterday:
https://developers.redhat.com/articles/2024/12/11/making-memcpynull-nu
Alejandro =?utf-8?q?=C3=81lvarez_Ayll=C3=B3n?=
Message-ID:
In-Reply-To:
nikic wrote:
This is an ABI-breaking fix, so it cannot be backported in this form.
https://github.com/llvm/llvm-project/pull/118288
___
cfe-commits mailing list
cfe-commits@lists
https://github.com/nikic created
https://github.com/llvm/llvm-project/pull/120222
This diagnoses comparisons like `ptr + unsigned_index < ptr` and `ptr +
unsigned_index >= ptr`, which are always false/true because addition of a
pointer and an unsigned index cannot wrap (or the behavior is unde
https://github.com/nikic updated
https://github.com/llvm/llvm-project/pull/120222
>From 66b5b0d72b49539206794c4472ee6fb14f00c5a7 Mon Sep 17 00:00:00 2001
From: Nikita Popov
Date: Tue, 17 Dec 2024 13:10:30 +0100
Subject: [PATCH 1/4] [Sema] Diagnose tautological bounds checks
This diagnoses comp
https://github.com/nikic updated
https://github.com/llvm/llvm-project/pull/120222
>From 66b5b0d72b49539206794c4472ee6fb14f00c5a7 Mon Sep 17 00:00:00 2001
From: Nikita Popov
Date: Tue, 17 Dec 2024 13:10:30 +0100
Subject: [PATCH 1/5] [Sema] Diagnose tautological bounds checks
This diagnoses comp
nikic wrote:
> Heads up: apart from a number of instances of actual UB in the code (which
> are quite tedious to localize and understand due to a lack of specialized
> tooling) we're investigating a bad interaction of this commit with msan,
> which seems to result in a miscompilation.
Thanks
https://github.com/nikic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/120480
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nikic wrote:
I'll comment in more detail another time, but here's the compile-time impact:
https://llvm-compile-time-tracker.com/compare.php?from=0e324b3f953d62527690b1cb44d95fcb3ec0512c&to=d1735d35b42bd8b0cabb6c0f54e7972a91430f85&stat=instructions:u
https://github.com/llvm/llvm-project/pull/12
nikic wrote:
@nathanchance You are correct, this warning should indeed respect
`-fwrapv`/`-fno-strict-overflow`. Your patch looks reasonable to me as well.
https://github.com/llvm/llvm-project/pull/120222
___
cfe-commits mailing list
cfe-commits@lists
@@ -1,40 +1,72 @@
// RUN: %clang_cc1 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -fsyntax-only -DFWRAPV -fwrapv -verify %s
nikic wrote:
I'm not very familiar with `-verify` tests, but may there is some way to avoid
these ifdefs using prefixes? Something like t
@@ -486,10 +486,10 @@ enum class TemplateSubstitutionKind : char {
const Decl *D = I->first;
llvm::PointerUnion &Stored =
newScope->LocalDecls[D];
-if (I->second.is()) {
- Stored = I->second.get();
+if (isa(I->second)) {
+
https://github.com/nikic closed https://github.com/llvm/llvm-project/pull/119365
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -594,9 +580,9 @@ BasicAAResult::DecomposeGEPExpression(const Value *V, const
DataLayout &DL,
SearchTimes++;
const Instruction *CxtI = dyn_cast(V);
- unsigned MaxIndexSize = DL.getMaxIndexSizeInBits();
nikic wrote:
Dropped the API in
https://github.c
nikic wrote:
We're seeing the same issue on s390x. Big endian not handled correctly?
https://github.com/llvm/llvm-project/pull/119544
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nikic wrote:
Yes, I'd expect this to more likely be a regression than an improvement. What
was you original motivation for this?
https://github.com/llvm/llvm-project/pull/119704
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llv
https://github.com/nikic approved this pull request.
https://github.com/llvm/llvm-project/pull/119724
___
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/119949
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nikic wrote:
@fmayer The `withoutNoUnsignedSignedWrap()` API already removed the inbounds
flag as well (because inbounds requires nusw). So I think the effect of your
change is to drop inbounds in case all indices are negative, which should
generally not be necessary.
It's pretty likely that
https://github.com/nikic updated
https://github.com/llvm/llvm-project/pull/120719
>From bd7a8273d07725d898188df00c708b5a52d68ac7 Mon Sep 17 00:00:00 2001
From: Nikita Popov
Date: Fri, 20 Dec 2024 12:41:01 +0100
Subject: [PATCH 1/2] [Clang] Adjust pointer-overflow sanitizer for N3322
N3322 make
https://github.com/nikic updated
https://github.com/llvm/llvm-project/pull/120719
>From bd7a8273d07725d898188df00c708b5a52d68ac7 Mon Sep 17 00:00:00 2001
From: Nikita Popov
Date: Fri, 20 Dec 2024 12:41:01 +0100
Subject: [PATCH 1/3] [Clang] Adjust pointer-overflow sanitizer for N3322
N3322 make
https://github.com/nikic updated
https://github.com/llvm/llvm-project/pull/120719
>From bd7a8273d07725d898188df00c708b5a52d68ac7 Mon Sep 17 00:00:00 2001
From: Nikita Popov
Date: Fri, 20 Dec 2024 12:41:01 +0100
Subject: [PATCH 1/4] [Clang] Adjust pointer-overflow sanitizer for N3322
N3322 make
nikic wrote:
@vitalybuka Should I also be dropping checks like
https://github.com/llvm/llvm-project/blob/5f0db7c11264fa235d73730b2b93a31407dfbef3/compiler-rt/lib/ubsan/ubsan_handlers.cpp#L817-L818
from the ubsan runtime? (Not sure whether the runtime is supposed to also be
compatible with olde
Alejandro =?utf-8?q?Álvarez_Ayllón?Message-ID:
In-Reply-To:
nikic wrote:
@hubert-reinterpretcast This patch modifies structure layout in exported
headers, changing the libclang-cpp ABI. LLVM patch releases cannot break API or
ABI compatibility, see the last point in
https://llvm.org/docs/How
https://github.com/nikic created
https://github.com/llvm/llvm-project/pull/120719
N3322 makes NULL + 0 well-defined in C, matching the C++ semantics. Adjust the
pointer-overflow sanitizer to no longer report NULL + 0 as a pointer overflow
in any language mode. NULL + nonzero will of course con
nikic wrote:
@danilaml We could pass AllowEphemerals=true to isValidAssumeForContext.
https://github.com/llvm/llvm-project/pull/109277
___
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.
LGTM
https://github.com/llvm/llvm-project/pull/115894
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nikic wrote:
Looks like some openmp maintainers have been proposed in
https://github.com/llvm/llvm-project/pull/118521. Do we want to let that land
first or integrate it here? (cc @nawrinsu)
https://github.com/llvm/llvm-project/pull/118309
___
cfe-co
Author: Nikita Popov
Date: 2024-12-05T12:45:44+01:00
New Revision: 3740fac0d4640c05ba960be97d14cbd375a7c733
URL:
https://github.com/llvm/llvm-project/commit/3740fac0d4640c05ba960be97d14cbd375a7c733
DIFF:
https://github.com/llvm/llvm-project/commit/3740fac0d4640c05ba960be97d14cbd375a7c733.diff
https://github.com/nikic closed https://github.com/llvm/llvm-project/pull/44
___
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/120872
___
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/120844
___
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/122588
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/nikic closed https://github.com/llvm/llvm-project/pull/120719
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nikic wrote:
@bjope I believe the standard solution to that is to add your own AA pass, see
e.g. AMDGPUAAResult and NVPTXAAResult which both do addrspace-based AA.
https://github.com/llvm/llvm-project/pull/119365
___
cfe-commits mailing list
cfe-commi
@@ -57,7 +57,7 @@ class DeclarationFragments {
Keyword,
Attribute,
NumberLiteral,
-StringLiteral,
+StringRef,
nikic wrote:
Generally a lot of clang changes are wrong. There's a StringLiteral AST node,
without relation to StringRef...
http
nikic wrote:
I didn't really understand the last paragraph of the PR description. How does
using StringRef instead of StringLiteral reduce relocations?
https://github.com/llvm/llvm-project/pull/122366
___
cfe-commits mailing list
cfe-commits@lists.llv
https://github.com/nikic commented:
I think StringLiteral is often used as an additional safety net, to ensure(*)
that only string literals get passed and we don't end up with dangling
pointers. This is especially useful when migrating some code from using an
owned to an unowned string.
(*) I
https://github.com/nikic approved this pull request.
https://github.com/llvm/llvm-project/pull/123499
___
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/123696
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nikic wrote:
> Just double checking, do we have a test for the auto-upgrade?
All the compatibility-*.ll tests test auto-upgrade.
https://github.com/llvm/llvm-project/pull/123181
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llv
nikic wrote:
I'm not seeing any impact:
https://llvm-compile-time-tracker.com/compare.php?from=ff0f1dd341cb2fdc1281a14413b3aa93bf9a20c7&to=4bfdd091675b9957686ac81457629e124950dc25&stat=instructions:u
https://github.com/llvm/llvm-project/pull/123931
__
https://github.com/nikic updated
https://github.com/llvm/llvm-project/pull/122486
>From 925f74cad21eb6c46514d1ae543ac202073baf27 Mon Sep 17 00:00:00 2001
From: Nikita Popov
Date: Fri, 10 Jan 2025 17:01:07 +0100
Subject: [PATCH] [Clang] Add -fwrapv-pointer flag
GCC supports three flags related
https://github.com/nikic approved this pull request.
https://github.com/llvm/llvm-project/pull/124074
___
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/124076
___
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/124228
___
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/124229
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nikic wrote:
If we want to make this change, I think doing it for Clang 20 would be ideal,
because it is related to the pointer overflow optimization changes in that
release.
https://github.com/llvm/llvm-project/pull/122486
___
cfe-commits mailing li
nikic wrote:
> That's an interesting situation! I'm not sure what I'd expect the LLVM IR to
> be there. For Clang AST, we want to keep around the expression AST nodes. But
> for LLVM IR, perhaps it makes sense to drop anything without a value rather
> than mark it as undef?
No strong opinion,
https://github.com/nikic updated
https://github.com/llvm/llvm-project/pull/122486
>From 925f74cad21eb6c46514d1ae543ac202073baf27 Mon Sep 17 00:00:00 2001
From: Nikita Popov
Date: Fri, 10 Jan 2025 17:01:07 +0100
Subject: [PATCH 1/2] [Clang] Add -fwrapv-pointer flag
GCC supports three flags rela
https://github.com/nikic updated
https://github.com/llvm/llvm-project/pull/122486
>From 925f74cad21eb6c46514d1ae543ac202073baf27 Mon Sep 17 00:00:00 2001
From: Nikita Popov
Date: Fri, 10 Jan 2025 17:01:07 +0100
Subject: [PATCH 1/2] [Clang] Add -fwrapv-pointer flag
GCC supports three flags rela
@@ -57,15 +57,6 @@ void test1(void) {
// TRAPV_HANDLER: foo(
--a;
- // -fwrapv should turn off inbounds for GEP's, PR9256
- extern int* P;
- ++P;
- // DEFAULT: getelementptr inbounds nuw i32, ptr
- // WRAPV: getelementptr i32, ptr
- // TRAPV: getelementptr inbounds
https://github.com/nikic updated
https://github.com/llvm/llvm-project/pull/122486
>From 925f74cad21eb6c46514d1ae543ac202073baf27 Mon Sep 17 00:00:00 2001
From: Nikita Popov
Date: Fri, 10 Jan 2025 17:01:07 +0100
Subject: [PATCH 1/3] [Clang] Add -fwrapv-pointer flag
GCC supports three flags rela
@@ -1,11 +1,24 @@
// RUN: %clang -### -S -fwrapv -fno-wrapv -fwrapv %s 2>&1 | FileCheck
-check-prefix=CHECK1 %s
// CHECK1: -fwrapv
//
+// RUN: %clang -### -S -fwrapv-pointer -fno-wrapv-pointer -fwrapv-pointer %s
2>&1 | FileCheck -check-prefix=CHECK1-POINTER %s
+// CHECK1-POIN
1101 - 1200 of 1626 matches
Mail list logo
