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 +
Subje
@@ -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 initializers
Fixe
@@ -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 initializers
Fixe
@@ -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 initializers
Fixe
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: [PATCH]
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.
https://github.com/alexfh created
https://github.com/llvm/llvm-project/pull/120460
Reverts llvm/llvm-project#119225 due to the lack of sanitizer support, large
potential of breaking code containing latent UB, non-trivial localization and
investigation, and what seems to be a bad interaction wi
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
https://github.com/alexfh created
https://github.com/llvm/llvm-project/pull/111581
This manifested as an assertion failure in Clang built against libc++ with
hardening enabled (e.g. -D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_DEBUG):
`libcxx/include/__memory/unique_ptr.h:596: assertion
__c
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
alexfh wrote:
An example, which is a bit closer to the original:
https://gcc.godbolt.org/z/5WMb78434.
https://github.com/llvm/llvm-project/pull/100692
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listi
alexfh wrote:
I looked at the original code and found a much more involved expression there
(https://gitlab.com/libeigen/eigen/-/blob/master/Eigen/src/Core/util/ForwardDeclarations.h?ref_type=heads#L66),
so the parenthesized expression is merely an artifact of reduction and there
doesn't seem
https://github.com/alexfh approved this pull request.
Looks good as a temporary fix. Thanks!
https://github.com/llvm/llvm-project/pull/109065
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-co
alexfh wrote:
> @alexfh #109065 Fixes test case 1.
I can confirm that it also fixes the compilation error in the original code.
https://github.com/llvm/llvm-project/pull/100692
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm
alexfh wrote:
Test case #2: https://gcc.godbolt.org/z/YbTKzao7d
https://github.com/llvm/llvm-project/pull/100692
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
alexfh wrote:
@mizvekov any news here? I think, I'll come up with two more reduced tests
later today.
https://github.com/llvm/llvm-project/pull/100692
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listi
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
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
alexfh wrote:
Thanks! The fix resolves the crash, but the original code still doesn't
compile. See
https://github.com/llvm/llvm-project/pull/108491#issuecomment-2350634130
https://github.com/llvm/llvm-project/pull/94981
___
cfe-commits mailing list
c
alexfh wrote:
I could reduce the code to something that compiles with Clang before
fa6580470547411667b866362941db0b02e25578, but not after it, this PR doesn't fix
the issue. The example is: https://gcc.godbolt.org/z/odWYhxGxK
Note that the code doesn't compile with Clang 18.1, but should compi
alexfh wrote:
Filed #108618
https://github.com/llvm/llvm-project/pull/73662
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
alexfh wrote:
Apologies for resurrecting this old thread, but I found a problem with this
patch. It seems like it makes a comparator violate strict weak ordering
requirements. This manifests as an assertion failure when Clang is compiled
with the corresponding libc++ check:
```
clang -O1 -c -o
1 - 100 of 1886 matches
Mail list logo
