https://github.com/alexfh closed
https://github.com/llvm/llvm-project/pull/142988
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
alexfh wrote:
@cor3ntin PTAL
https://github.com/llvm/llvm-project/pull/142988
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/alexfh updated
https://github.com/llvm/llvm-project/pull/142988
>From c7154b0b2bd6457d908bb7fbedc028219f8b5e6d Mon Sep 17 00:00:00 2001
From: Alexander Kornienko
Date: Thu, 5 Jun 2025 15:10:39 +
Subject: [PATCH 1/3] Fix an error introduced in #138518
---
clang/lib/S
https://github.com/alexfh updated
https://github.com/llvm/llvm-project/pull/142988
>From c7154b0b2bd6457d908bb7fbedc028219f8b5e6d Mon Sep 17 00:00:00 2001
From: Alexander Kornienko
Date: Thu, 5 Jun 2025 15:10:39 +
Subject: [PATCH 1/2] Fix an error introduced in #138518
---
clang/lib/S
https://github.com/alexfh edited
https://github.com/llvm/llvm-project/pull/142988
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/alexfh edited
https://github.com/llvm/llvm-project/pull/142988
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
-2906276916 and
https://github.com/llvm/llvm-project/pull/138518#issuecomment-2944538713 for
details and context.
>From c7154b0b2bd6457d908bb7fbedc028219f8b5e6d Mon Sep 17 00:00:00 2001
From: Alexander Kornienko
Date: Thu, 5 Jun 2025 15:10:39 +
Subject: [PATCH] Fix an error introduced in #138
alexfh wrote:
Okay, I think, I have a fix.
https://github.com/llvm/llvm-project/pull/138518
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
alexfh wrote:
Before this change the cast was added here:
```
* thread #1, name = 'clang', stop reason = step over
frame #0: 0x667e8ff2
clang`clang::Sema::BuildCXXNew(this=0x5092ffd24000, Range=SourceRange @
0x7ffef4f8, UseGlobal=false, PlacementLParen=(ID = 94),
Placem
alexfh wrote:
> > @alexfh I don't have the resources to look into this issue. Please revert
> > if you need to.
>
> This has been in trunk for a long time, a revert here would be HIGHLY
> unfortunate. I would vastly prefer someone spend time trying to figure out
> why we are confused with the
https://github.com/alexfh approved this pull request.
Looks good. Thanks for adding this early detection of the incorrect CUDA code
that would otherwise lead to violated invariants further down the road.
https://github.com/llvm/llvm-project/pull/142857
__
alexfh wrote:
@cor3ntin friendly ping. Please take a look at the remaining issue here. Thanks!
https://github.com/llvm/llvm-project/pull/138518
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-
alexfh wrote:
@cor3ntin thank you for the fix for the assertion failure! The problem
described in
https://github.com/llvm/llvm-project/pull/138518#issuecomment-2906596143 still
remains though.
https://github.com/llvm/llvm-project/pull/138518
___
cfe
alexfh wrote:
Reduced test case:
```
template
void invoke(_Fn __f) {
__f();
}
struct Duration {
int lo_;
int rep_hi_;
int rep_lo_;
};
Duration Seconds(int);
struct Time {
friend bool operator<(Time, Time);
Duration rep_;
};
Time operator+(Time, Duration);
Time Now();
struct Node {
alexfh wrote:
@cor3ntin ^^
https://github.com/llvm/llvm-project/pull/138518
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
alexfh wrote:
Apart from the assertion failure in CodeGen, we have two distinct test cases
that started failing after this commit. The code in both cases is
sanitizer-clean and looks valid. The failures reproduce with -O0, so it's not
about optimizations. Looks like Clang codegen is broken for
alexfh wrote:
I've filed https://github.com/llvm/llvm-project/issues/141242 for the second
report. However
https://github.com/llvm/llvm-project/pull/138518#issuecomment-2903017423 is new
and still needs to be addressed.
https://github.com/llvm/llvm-project/pull/138518
alexfh wrote:
@cor3ntin yep, the second test case I have doesn't seem to be directly related.
It causes crashes to Clang since version 7: https://gcc.godbolt.org/z/6M13c4q3T
https://github.com/llvm/llvm-project/pull/138518
___
cfe-commits mailing list
alexfh wrote:
@cor3ntin this commit causes an assertion failure:
https://gcc.godbolt.org/z/7hW4ssrfq
```
$ cat test.cc
struct E {
virtual void f();
};
struct G {
E e;
};
template
struct Test {
virtual void f() {
E e;
G g(e);
}
};
auto *t = new Test;
$ ./clang-bad -c -o /dev/nul
alexfh wrote:
> Interesting, changing `private header "wrap_foo.h"` to `header "wrap_foo.h"`
> in `b.wrap_foo` stops reproducing the error. I'm not sure it guarantees
>
> > whenever resolving module for the header, pick one that has the header as
> > modular over textual.
>
> But seems we are
https://github.com/alexfh approved this pull request.
Thanks for the prompt fix! Looks good!
https://github.com/llvm/llvm-project/pull/140724
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-co
alexfh wrote:
Just to confirm: is it intended that `char *s = NULL;` now generates this
warning? I mean, the C library may define `NULL` as `((void*)0)`, and `char *s
= ((void*)0);` is clearly not C++-compatible. However, when compiling this code
in C++, `NULL` may expand to something that IS
alexfh wrote:
This helps with the crashes we've seen so far. Thanks!
https://github.com/llvm/llvm-project/pull/140288
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
alexfh wrote:
Also:
* https://github.com/bsdjhb/gdb/blob/master/bfd/cpu-tic4x.c#L37
* https://github.com/unicode-org/icu/pull/3497
* https://github.com/KLayout/klayout/blob/master/src/tl/tl/tlUri.cc#L44
and more.
Thanks a lot for the improvement!
https://github.com/llvm/llvm-project/pull/133653
alexfh wrote:
@cor3ntin the reduced test case for the assertion failure above is:
https://gcc.godbolt.org/z/zveexjqW3
```
struct N {
int field;
};
template
struct B {
B(It, T);
template
B(B);
};
template
struct C {
auto g() { return B(0, T{}); }
};
void f() {
using T = decltype(C{
alexfh wrote:
@cor3ntin unfortunately, this fix causes assertion failures elsewhere:
```
assertion failed at clang/lib/AST/ASTContext.cpp:3913 in QualType
clang::ASTContext::getDecayedType(QualType) const: (T->isArrayType() ||
T->isFunctionTy
pe()) && "T does not decay"
@ 0x55637f01d274
https://github.com/alexfh closed
https://github.com/llvm/llvm-project/pull/140179
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/alexfh updated
https://github.com/llvm/llvm-project/pull/140179
Rate limit · GitHub
body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe
UI,Helvetica,Arial,sans-se
alexfh wrote:
> * Fixes serialization of constexpr structs containing unions. (#GH140130)
Thanks for the suggestion, added to the release notes.
https://github.com/llvm/llvm-project/pull/140179
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
h
https://github.com/alexfh updated
https://github.com/llvm/llvm-project/pull/140179
Rate limit · GitHub
body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe
UI,Helvetica,Arial,sans-se
https://github.com/alexfh updated
https://github.com/llvm/llvm-project/pull/140179
Rate limit · GitHub
body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe
UI,Helvetica,Arial,sans-se
@@ -414,7 +414,7 @@ let Class = PropertyTypeCase in {
let Read = [{ node.getUnionValue() }];
}
def : Creator<[{
-return APValue(cast(fieldDecl), std::move(value));
+return APValue(cast_if_present(fieldDecl),
std::move(value));
alexfh wrote:
So
alexfh wrote:
> I think we need a release note in clang/docs/ReleaseNotes.rst
Which aspect would you like to cover in the release notes? The fix of the
mismatch between AST writer and AST reader or something else? Do you have a
specific wording in mind?
https://github.com/llvm/llvm-project/pu
https://github.com/alexfh created
https://github.com/llvm/llvm-project/pull/140179
This commit fixes https://github.com/llvm/llvm-project/issues/140130
>From 1b484ea9910fa1277481b27c58351c1e8b5001e3 Mon Sep 17 00:00:00 2001
From: Alexander Kornienko
Date: Fri, 16 May 2025 02:52:58 +0
@@ -430,8 +430,14 @@ class Sema;
if (!ReferenceBinding) {
#ifndef NDEBUG
auto Decay = [&](QualType T) {
- return (T->isArrayType() || T->isFunctionType()) ?
C.getDecayedType(T)
- : T;
+ T
https://github.com/alexfh edited
https://github.com/llvm/llvm-project/pull/140073
___
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.
Thank you for the prompt fix! Looks good with one suggestion.
https://github.com/llvm/llvm-project/pull/140073
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/
alexfh wrote:
> Reduced test case: https://gcc.godbolt.org/z/qG1Yv35rb
@cor3ntin ^^
https://github.com/llvm/llvm-project/pull/136203
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
alexfh wrote:
Reduced test case: https://gcc.godbolt.org/z/qG1Yv35rb
https://github.com/llvm/llvm-project/pull/136203
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
alexfh wrote:
@cor3ntin we've root-caused an assertion failure in Clang to this commit. It
reproduces at least up to 1778d3b8245b9a7787bbd0b00f60f879ed4689c9.
The test case is being reduced, but maybe you can spot something obviously
wrong from the assertion failure and the stack trace:
```
as
https://github.com/alexfh approved this pull request.
Thanks for the fix! LG
https://github.com/llvm/llvm-project/pull/139253
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
alexfh wrote:
> > This change breaks a bunch of other cases, for example, calls to
> > `NodeDefBuilder::Attr("...", {some_value})`
> > https://android.googlesource.com/platform/external/tensorflow/+/main/tensorflow/core/framework/node_def_builder.h#130
>
> Can you provide us with a reduced exa
alexfh wrote:
Thank you for the prompt fix! It addresses the problems we've found so far.
https://github.com/llvm/llvm-project/pull/136203
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commi
alexfh wrote:
Please take a look, so far it seems like it should be reverted.
https://github.com/llvm/llvm-project/pull/136203
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
alexfh wrote:
This change breaks a bunch of other cases, for example, calls to
`NodeDefBuilder::Attr("...", {some_value})`
https://android.googlesource.com/platform/external/tensorflow/+/main/tensorflow/core/framework/node_def_builder.h#130
https://github.com/llvm/llvm-project/pull/136203
alexfh wrote:
This commit changed the behavior of the following code
(https://godbolt.org/z/r1q55e1jv / https://godbolt.org/z/GsPqxaf3G):
```
#include
constexpr unsigned long num = 123;
void foo() {
// OK
(void)std::vector({num});
// Fail
(void)std::vector({num});
}
```
In th
@@ -121,6 +121,7 @@ CAST_OPERATION(FunctionToPointerDecay)
/// CK_NullToPointer - Null pointer constant to pointer, ObjC
/// pointer, or block pointer.
/// (void*) 0
+/// (void*) nullptr
alexfh wrote:
Sure. Done in b509f7cca58c8db060eebea6fb5b28c3d0b3727b.
@@ -121,6 +121,7 @@ CAST_OPERATION(FunctionToPointerDecay)
/// CK_NullToPointer - Null pointer constant to pointer, ObjC
/// pointer, or block pointer.
/// (void*) 0
+/// (void*) nullptr
alexfh wrote:
@efriedma-quic I'll land the fix now. Please let me kno
https://github.com/alexfh closed
https://github.com/llvm/llvm-project/pull/137364
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/alexfh updated
https://github.com/llvm/llvm-project/pull/137364
>From 5431de1664814a7a2dcc93695eed8745ae6bfef5 Mon Sep 17 00:00:00 2001
From: Alexander Kornienko
Date: Fri, 25 Apr 2025 17:51:03 +0200
Subject: [PATCH 1/5] [CodeGen] Fix handling of nullptr in initializ
@@ -121,6 +121,7 @@ CAST_OPERATION(FunctionToPointerDecay)
/// CK_NullToPointer - Null pointer constant to pointer, ObjC
/// pointer, or block pointer.
/// (void*) 0
+/// (void*) nullptr
alexfh wrote:
Okay, hopefully, I got it right this time.
https://git
https://github.com/alexfh updated
https://github.com/llvm/llvm-project/pull/137364
>From 5431de1664814a7a2dcc93695eed8745ae6bfef5 Mon Sep 17 00:00:00 2001
From: Alexander Kornienko
Date: Fri, 25 Apr 2025 17:51:03 +0200
Subject: [PATCH 1/4] [CodeGen] Fix handling of nullptr in initializ
@@ -121,6 +121,7 @@ CAST_OPERATION(FunctionToPointerDecay)
/// CK_NullToPointer - Null pointer constant to pointer, ObjC
/// pointer, or block pointer.
/// (void*) 0
+/// (void*) nullptr
alexfh wrote:
Sorry, I misunderstood your previous comment. Now, is `
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -std=c++20 -triple x86_64-linux-gnu -emit-llvm -o - %s |
FileCheck %s
+
+using ulong = unsigned long;
+template
+void g(Ts... args) {
+ ulong arr[3] = {ulong(args)...};
+ (void)arr;
+}
+extern void f() {
+ g(nullptr, 17);
+}
+
+// CHECK: {
https://github.com/alexfh updated
https://github.com/llvm/llvm-project/pull/137364
>From 5431de1664814a7a2dcc93695eed8745ae6bfef5 Mon Sep 17 00:00:00 2001
From: Alexander Kornienko
Date: Fri, 25 Apr 2025 17:51:03 +0200
Subject: [PATCH 1/3] [CodeGen] Fix handling of nullptr in initializ
https://github.com/alexfh created
https://github.com/llvm/llvm-project/pull/137364
Fixes https://github.com/llvm/llvm-project/issues/137276.
>From 5431de1664814a7a2dcc93695eed8745ae6bfef5 Mon Sep 17 00:00:00 2001
From: Alexander Kornienko
Date: Fri, 25 Apr 2025 17:51:03 +0200
Subject: [PA
alexfh wrote:
> I'm going to separate out the CUDA SPIRV regression fix as I need to fix some
> problems with this PR, will add you as a reviewer.
Do you have a timeline? It would be nice to get this fixed soon.
https://github.com/llvm/llvm-project/pull/135251
_
alexfh wrote:
There are two issues:
1. an assertion failure in Clang: `assertion failed at
clang/lib/CodeGen/CGExprCXX.cpp:1428 in UsualDeleteParams
getUsualDeleteParams(const FunctionDecl *): AI == AE && "unexpected usual
deallocation function parameter"`
2. `no suitable member 'operator dele
alexfh wrote:
This is being looked into. If this turns out to be a problem in LLVM rather
than in the SPIRV-LLVM-Translator, I'll let you know here.
https://github.com/llvm/llvm-project/pull/134399
___
cfe-commits mailing list
cfe-commits@lists.llvm.o
alexfh wrote:
We've started seeing errors similar to this one after this commit:
```
Can't translate llvm instruction:
Global variable can not have Function storage class. Consider setting a proper
address space.
Original LLVM value:
@.str.2 = private unnamed_addr constant [19 x i8] c"%s at %s
alexfh wrote:
#134748 doesn't fix errors in the original code, unfortunately. Now we're
getting `out-of-line definition of 'X' does not match any declaration in 'Y'`.
It's hard to tell whether the original code is correct, but I suppose that the
purpose of this change was not to make Clang str
alexfh wrote:
> We're seeing another problem after this commit: seemingly bogus `class member
> cannot be redeclared` errors. I'll try to provide a reduced repro on Monday.
My cvise has been running for quite a while. I'll post the test once it
concludes.
https://github.com/llvm/llvm-project
alexfh wrote:
We're seeing another problem after this commit: seemingly bogus `class member
cannot be redeclared` errors. I'll try to provide a reduced repro on Monday.
https://github.com/llvm/llvm-project/pull/133610
___
cfe-commits mailing list
cfe-
alexfh wrote:
> @alexfh should be fixed by #133613
Thank you! The crash is resolved. Do you still need a reduced test case?
https://github.com/llvm/llvm-project/pull/132401
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org
alexfh wrote:
I've found a new crash that's not fixed by
https://github.com/llvm/llvm-project/pull/133343. Reducing...
https://github.com/llvm/llvm-project/pull/132401
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-
alexfh wrote:
> > @alexfh Are you sure the original crashes were due to #132977 ?
>
> I thought so, but your explanation below also seems reasonable. I can try to
> verify.
>
> > Looking at the patch, it seems unlikely it could cause a crash in itself.
> > What I think happened is that your co
alexfh wrote:
> @alexfh Are you sure the original crashes were due to #132977 ?
I thought so, but your explanation below also seems reasonable. I can try to
verify.
> Looking at the patch, it seems unlikely it could cause a crash in itself.
>
> What I think happened is that your compilation p
alexfh wrote:
Thanks for the fast fix! I would still insist on reverting first and
recommiting the changes along with the fix (I could run this through a bit more
testing on real code for more confidence), rather than trying to expedite the
review and potentially introducing more regressions.
alexfh wrote:
The reduced test case:
```
template
struct A;
template
struct A {};
template
void e(T) {
A f;
}
struct S {
struct C {
void h(int &, S *);
};
void i() { e(&C::h); }
};
```
https://gcc.godbolt.org/z/8Pq9EWbTv
https://github.com/llvm/llvm-project/pull/132317
__
alexfh wrote:
> @alexfh thanks, this will be fixed here: #132977
We see more clang crashes after #132977 /
960615954e4cb3150ae4a479fa7f9d0d17035eea. I'll start a reduction and will post
a new test case, but please revert #132977 and this commit.
https://github.com/llvm/llvm-project/pull/13231
alexfh wrote:
Reduced test case: https://gcc.godbolt.org/z/7xxfsj4vv
```
struct A {
template A(T);
};
struct C;
template void d(void (T::*)());
void f(A);
void g() { f(d); }
```
Please revert or fix soon. Thanks!
https://github.com/llvm/llvm-project/pull/132317
alexfh wrote:
We're also seeing Clang crashes after the original commit, which are not fixed
here.
https://github.com/llvm/llvm-project/pull/132317
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo
alexfh wrote:
It looks like this commit introduces an undesired false-positive:
https://gcc.godbolt.org/z/rEjzK63he
```
struct P {
int a [[clang::require_explicit_initialization]];
};
struct S {
P p;
S(P p) : p(p) {}
};
```
```
:7:12: warning: field in 'P' requires explicit initializati
alexfh wrote:
Can we have this behavior guarded by a compiler option?
https://github.com/llvm/llvm-project/pull/122423
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
alexfh wrote:
FYI, we've also seen problems compiling code that includes certain boost
headers (version 1.84, as far as I can tell) after
https://github.com/llvm/llvm-project/pull/102857:
```
boost/asio/any_io_executor.hpp:161:13: error: satisfaction of constraint
'::boost::asio::execution::ex
https://github.com/alexfh closed
https://github.com/llvm/llvm-project/pull/120460
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
alexfh 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.
with msan (a test is in
the works).
Related discussions:
https://github.com/llvm/llvm-project/pull/119225#issuecomment-2551904822
https://github.com/llvm/llvm-project/pull/118472#issuecomment-2549986255
>From 18c410940d8c0c506f759dec6d28dfe40d021a01 Mon Sep 17 00:00:00 2001
From: Alexan
alexfh 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.
https://github
https://github.com/alexfh approved this pull request.
Thanks for the fix! LGTM
https://github.com/llvm/llvm-project/pull/119077
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/alexfh closed
https://github.com/llvm/llvm-project/pull/118980
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
alexfh wrote:
I've added a reduced test case to
https://github.com/llvm/llvm-project/pull/118455. Merging this to unbreak clang.
https://github.com/llvm/llvm-project/pull/118980
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llv
alexfh wrote:
The test case was reduced to this:
```
template struct a {
union b {};
struct c {
c() { delete d; }
b *d;
} f;
};
a e;
```
https://gcc.godbolt.org/z/d5cP4McG3
https://github.com/llvm/llvm-project/pull/118455
___
cfe-commits
alexfh wrote:
To avoid this I usually incorporate a validity check in my interestingness
test, e.g. by running a known-good clang on the candidate input, e.g. currently
I use:
```
$ cat bad-clang-crashes.sh
#!/bin/bash -eux
ARGS="-fdiagnostics-show-option -Wall -Werror
-Wno-inconsistent-missin
alexfh wrote:
> PR here https://github.com/llvm/llvm-project/pull/118980 - But I'd love to
> understand the actual issue before merging
It'll take some time. cvise has reduced the preprocessed input from 13MB to
7.5MB so far. The input is not shareable so far.
https://github.com/llvm/llvm-pro
alexfh wrote:
In my case I don't see an assertion before this change (using Clang built from
c0192a008c4a2b8afdc2b63526c0483632d81c07).
https://github.com/llvm/llvm-project/pull/118455
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://l
alexfh wrote:
The original file is huge and template heavy, so reduction will take some time.
I wonder if you can spot something obviously wrong in the commit given the
information above? Failing that, can we revert in the meantime?
https://github.com/llvm/llvm-project/pull/118455
alexfh wrote:
Heads up: we're seeing clang crashes after this revision. Assertions-enabled
clang fails this assertion (probably related?):
```
assert.h assertion failed at clang/lib/Sema/SemaLookup.cpp:2408 in bool
clang::Sema::LookupQualifiedName(LookupResult &, DeclContext *, bool):
(!isa(Lo
alexfh wrote:
Sorry, we've been in a bit of a firefighting. I'll try to arrange some time for
this till the EOW.
https://github.com/llvm/llvm-project/pull/111992
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/ma
alexfh wrote:
@kadircet is working on a repro for the crash we're seeing. @usx95 is looking
at the compilation errors.
https://github.com/llvm/llvm-project/pull/111852
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-
alexfh wrote:
We've also found a clang crash and a few new compilation errors after
https://github.com/llvm/llvm-project/pull/114569. We definitely need to revert
it as well as this commit.
https://github.com/llvm/llvm-project/pull/111852
___
cfe-com
https://github.com/alexfh approved this pull request.
LG
https://github.com/llvm/llvm-project/pull/115159
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/alexfh closed
https://github.com/llvm/llvm-project/pull/111581
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
__checker_.__in_bounds(std::__to_address(__ptr_), __i) failed:
unique_ptr::operator[](index): index out of range`
>From ab7e28fb704cd3a2235cb366bc39891e50f83d03 Mon Sep 17 00:00:00 2001
From: Alexander Kornienko
Date: Tue, 8 Oct 2024 22:19:07 +0200
Subject: [PATCH] Fix out-of-bounds access to
alexfh wrote:
I see. A clear diagnostic wouldn't hurt indeed. Thanks a lot for the analysis!
No more concerns from our side at this point.
https://github.com/llvm/llvm-project/pull/100692
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https:/
alexfh wrote:
Wow, I would never have thought it was a problem. Making these the same type
removes the compilation error. Can you explain why this is a problem from the
C++ standard PoV?
https://github.com/llvm/llvm-project/pull/100692
___
cfe-commit
alexfh wrote:
It was faster than I thought. The original code for case 2 is indeed invalid.
Having looked carefully at the two definitions of PrintTo, I clearly see they
are violating ODR. And both are originating in the internal code, so nothing
specific to Eigen. Thanks again for the good ex
alexfh wrote:
> However, I suspect that the parentheses reduction and the one with a ternary
> are actually the same issue - The code is IFNDR per
> https://eel.is/c++draft/temp.over.link#5
>
> In you last example, M*2 and the conditional with M+N after the substitution
> of the default argum
alexfh wrote:
Thanks for the clarification! The fact that there's code around that isn't
quite following the standard, is not news, but the regular way to approach
tightening the compiler is to provide an opt-out mechanism for some time (one
release cycle?) in the shape of a flag or otherwise
alexfh wrote:
Our internal releases have been blocked on this issue, since even a local
revert is not an option at the moment due to the number of dependent commits
and problems in other parts of LLVM. We would appreciate if we could get a
resolution in the next day or two. If there's no clear
1 - 100 of 3037 matches
Mail list logo
