https://github.com/nikic approved this pull request.
https://github.com/llvm/llvm-project/pull/123285
___
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/123283
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nikic wrote:
Thanks for the context! "I'm landing this without approval because I'm the
maintainer for this component" is a lot less scary than "I'm landing this
without approval because there's no time to wait on a review".
https://github.com/llvm/llvm-project/pull/122887
nikic wrote:
Compile-time looks fine on this one:
https://llvm-compile-time-tracker.com/compare.php?from=8fb29ba287d72392bd7900c33d2a8d2149126dbe&to=fd734a392a094a573ee7fe587b9fc5f616f92a9a&stat=instructions:u
https://github.com/llvm/llvm-project/pull/123152
https://github.com/nikic approved this pull request.
https://github.com/llvm/llvm-project/pull/123156
___
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/123157
___
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/123158
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nikic wrote:
Looks like this change has some compile-time impact even if modules are not
used:
https://llvm-compile-time-tracker.com/compare.php?from=edc02351dd11cc4a39b7c541b26b71c6f36c8e55&to=7201cae106260aeb3e97d5291ff30f05076a&stat=instructions:u
It seems to add about 0.5% to C++ compi
https://github.com/nikic approved this pull request.
https://github.com/llvm/llvm-project/pull/123012
___
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/123013
___
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/123014
___
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/122854
___
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/122856
___
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/122858
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/nikic commented:
This one also uses dyn_cast_if_present.
https://github.com/llvm/llvm-project/pull/122856
___
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/122855
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/nikic commented:
> Literal migration would result in dyn_cast_if_present (see the
> definition of PointerUnion::dyn_cast), but this patch uses dyn_cast
> because we expect Source to be nonnull.
You are still using dyn_cast_if_present :)
https://github.com/llvm/llvm-project/pu
https://github.com/nikic approved this pull request.
https://github.com/llvm/llvm-project/pull/122778
___
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/122462
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nikic wrote:
> I'm tempted to say we should just treat
> -fwrapv/-fwrapv-pointer/-fno-strict-overflow as aliases for each other. I
> don't think anyone using -fwrapv is going to be happy that we're turning on
> overflow optimizations.
Yeah, I'm not entirely sure this change is worthwhile eith
@@ -58,6 +58,26 @@ code bases.
containing strict-aliasing violations. The new default behavior can be
disabled using ``-fno-pointer-tbaa``.
+- Clang will now more aggressively use undefined behavior on pointer addition
+ overflow for optimization purposes. For example, a
https://github.com/nikic updated
https://github.com/llvm/llvm-project/pull/122462
>From 6940157fa4b9c186f45b98206311b12ab78c40ff Mon Sep 17 00:00:00 2001
From: Nikita Popov
Date: Fri, 10 Jan 2025 15:14:44 +0100
Subject: [PATCH 1/2] [Clang] Add release note for pointer overflow
optimization cha
https://github.com/nikic approved this pull request.
https://github.com/llvm/llvm-project/pull/122652
___
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/122651
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nikic wrote:
> Literal migration would result in dyn_cast_if_present (see the definition of
> PointerUnion::dyn_cast), but this patch uses dyn_cast because we expect
> Prototype.P to be nonnull.
This comment doesn't seem to match the PR :)
https://github.com/llvm/llvm-project/pull/122653
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
@@ -58,6 +58,26 @@ code bases.
containing strict-aliasing violations. The new default behavior can be
disabled using ``-fno-pointer-tbaa``.
+- Clang will now more aggressively use undefined behavior on pointer addition
nikic wrote:
I think it's hard to ad
@@ -58,6 +58,26 @@ code bases.
containing strict-aliasing violations. The new default behavior can be
disabled using ``-fno-pointer-tbaa``.
+- Clang will now more aggressively use undefined behavior on pointer addition
+ overflow for optimization purposes. For example, a
https://github.com/nikic updated
https://github.com/llvm/llvm-project/pull/122486
>From b32e3e1eee4b359ae2f0a1563420104de8d52277 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 updated
https://github.com/llvm/llvm-project/pull/122486
>From 1f3737d2eeb7681cb57a66f7bd6c4614cd038aac 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 updated
https://github.com/llvm/llvm-project/pull/122486
>From b8c7a369fffecc9d1811d286fb1536346045fb74 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
@@ -58,6 +58,26 @@ code bases.
containing strict-aliasing violations. The new default behavior can be
disabled using ``-fno-pointer-tbaa``.
+- Clang will now more aggressively use undefined behavior on pointer addition
+ overflow for optimization purposes. For example, a
https://github.com/nikic created
https://github.com/llvm/llvm-project/pull/122486
GCC supports three flags related to overflow behavior:
* `-fwrapv`: Makes signed integer overflow well-defined.
* `-fwrapv-pointer`: Makes pointer overflow well-defined.
* `-fno-strict-overflow`: Implies `-fwrap
@@ -58,6 +58,26 @@ code bases.
containing strict-aliasing violations. The new default behavior can be
disabled using ``-fno-pointer-tbaa``.
+- Clang will now more aggressively use undefined behavior on pointer addition
+ overflow for optimization purposes. For example, a
nikic wrote:
I'm concerned about the soundness of our current implementation for these
assumptions, see my comment at
https://github.com/llvm/llvm-project/pull/120962#issuecomment-2582864870. Not
sure we should be exposing the current implementation from clang.
https://github.com/llvm/llvm-pr
https://github.com/nikic created
https://github.com/llvm/llvm-project/pull/122462
Add a release note for optimization change related to pointer overflow checks.
I've put this in the breaking changes section to give it the best chance of
being seen.
>From 6940157fa4b9c186f45b98206311b12ab78c40
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
@@ -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:
@frasercrmck BasicAA returns MayAlias for your example. Presumably AMDGPUAA
returns NoAlias because addrspace(3) and addrspace(0) can't alias, or something
like that.
https://github.com/llvm/llvm-project/pull/119365
___
cfe-commits maili
nikic wrote:
It's expected that there are regressions if you are mixing pointers with
different index widths. I'm open to ideas, but I don't see any obvious way we
can fully support pointers with different index widths while also being
correct. A key thing that BasicAA needs is the ability to
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
https://github.com/nikic commented:
As you still support the legacy format, could you please restrict this PR to
only the parser changes, and leave the printer changes (and the mass test
update they require) to a followup?
https://github.com/llvm/llvm-project/pull/121838
__
@@ -2761,6 +2761,41 @@ etc.).
Query for this feature with
``__has_builtin(__builtin_assume_separate_storage)``.
+``__builtin_assume_dereferenceable``
+-
+
+``__builtin_assume_derefernceable`` is used to provide the optimizer with the
+know
https://github.com/nikic updated
https://github.com/llvm/llvm-project/pull/120719
>From cf1a8ee68d10668c1031a21daa251108c4fca98c 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
https://github.com/nikic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/118309
___
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
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
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
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/2] [Clang] Adjust pointer-overflow sanitizer for N3322
N3322 make
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
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
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 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
@@ -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
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
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:
> 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 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
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 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
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 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
@@ -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
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
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
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
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
@@ -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)) {
+
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:
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
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
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
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 created
https://github.com/llvm/llvm-project/pull/119225
When we have a gep inbounds from the base of an object (e.g. alloca or global),
we know that the index cannot be negative, as this would go out of bounds. As
such, we can infer nuw as well.
The implementation is
https://github.com/nikic closed https://github.com/llvm/llvm-project/pull/119214
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Alejandro =?utf-8?q?Álvarez_Ayllón?Message-ID:
In-Reply-To:
nikic wrote:
@erichkeane I'm not seeing any significant compile-time impact:
https://llvm-compile-time-tracker.com/compare.php?from=e0ea9fd6dc36f585e364d4e569095ebe063e2573&to=7fb8c423fddd1a81287b54f48da4de1c81566fc1&stat=instructions
https://github.com/nikic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/119178
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/nikic edited https://github.com/llvm/llvm-project/pull/118734
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -68,23 +69,156 @@ enum ID {
FirstTSBuiltin
};
+// The info used to represent each builtin.
struct Info {
- llvm::StringLiteral Name;
- const char *Type, *Attributes;
- const char *Features;
+ // Rather than store pointers to the string literals describing these four
https://github.com/nikic approved this pull request.
Confirmed that this works on GCC now. I'd suggest to replace the use of
StringLiteral::size with plain sizeof(). The build time overhead of going
through StringLiteral here is substantial.
https://github.com/llvm/llvm-project/pull/118734
___
@@ -68,23 +69,156 @@ enum ID {
FirstTSBuiltin
};
+// The info used to represent each builtin.
struct Info {
- llvm::StringLiteral Name;
- const char *Type, *Attributes;
- const char *Features;
+ // Rather than store pointers to the string literals describing these four
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
nikic wrote:
It looks like this causes a significant compile-time regression:
https://llvm-compile-time-tracker.com/compare.php?from=2b855dd97092e2178ac5c470a804a17ec440d7e5&to=9ccde12f5eeb91152900082a2ae839e2a9702b31&stat=instructions:u
(Maybe most clearly seen during clang bootstrap, where th
https://github.com/nikic requested changes to this pull request.
Fails to build with GCC:
```
FAILED: tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Builtins.cpp.o
CCACHE_CPP2=yes CCACHE_HASHDIR=yes /usr/bin/ccache /usr/bin/c++ -DCLANG_EXPORTS
-DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CON
https://github.com/nikic approved this pull request.
https://github.com/llvm/llvm-project/pull/118600
___
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/118819
___
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/118819
>From 1dadf4d77f1cec342179b923d3ab37ea3b983a25 Mon Sep 17 00:00:00 2001
From: Nikita Popov
Date: Thu, 5 Dec 2024 12:10:59 +0100
Subject: [PATCH] [SCCP] Infer nuw for gep nusw with non-negative offsets
If the GEP
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
nikic wrote:
Reading back here, the general thing you are trying to do here is not allowed.
At best you can add this as a manually invoked target that is not implicitly
called by anything else. Though the actually correct way to handle this is what
was proposed in https://github.com/llvm/llvm-
nikic wrote:
Reverted this because it breaks a the build. I initially assumed this is due to
disabled docs per the previous comment, but I think in my case the problem is
actually that this seems to be trying to write to the source directory, which
is forbidden. If you need to write out files,
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
Timm =?utf-8?q?Bäder?= ,
Timm =?utf-8?q?Bäder?=
Message-ID:
In-Reply-To:
nikic wrote:
It looks like this still fails on i386 after the reapply:
```
RUN: at line 1:
/builddir/build/BUILD/llvm-20.0.0_pre20241205.gb86a5993bc7be5-build/llvm-project-b86a5993bc7be59b49879a0e768f53b7330f71b2/llvm/r
@@ -37,8 +37,8 @@ void ConstantInitFuture::abandon() {
void ConstantInitFuture::installInGlobal(llvm::GlobalVariable *GV) {
assert(Data && "installing null future");
- if (Data.is()) {
-GV->setInitializer(Data.get());
+ if (auto *C = dyn_cast(Data)) {
+GV->setIniti
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
1 - 100 of 1137 matches
Mail list logo
