Hi Jason,
On 7 Feb 2025, at 23:10, Jason Merrill wrote:
> On 2/7/25 4:04 PM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 7 Feb 2025, at 14:21, Jason Merrill wrote:
>>
>>> On 2/6/25 3:05 PM, Simon Martin wrote:
>>>> Hi Jason,
>>>>
>>
Hi Jason,
On 6 Feb 2025, at 16:48, Jason Merrill wrote:
> On 2/5/25 2:21 PM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 4 Feb 2025, at 21:23, Jason Merrill wrote:
>>
>>> On 2/4/25 3:03 PM, Jason Merrill wrote:
>>>> On 2/4/25 11:45 AM, Simon Ma
Hi Jason,
On 4 Feb 2025, at 21:23, Jason Merrill wrote:
> On 2/4/25 3:03 PM, Jason Merrill wrote:
>> On 2/4/25 11:45 AM, Simon Martin wrote:
>>> On 4 Feb 2025, at 17:17, Jason Merrill wrote:
>>>
>>>> On 2/4/25 10:56 AM, Simon Martin wrote:
>>>
We've been rejecting the following valid code since GCC 4
=== cut here ===
struct A {
explicit A (int);
operator void* () const;
};
void foo (const A& x) {
auto res = 0 ? x : 0;
}
int main () {
A a{5};
foo(a);
}
=== cut here ===
The problem is that for COND_EXPR, add_builtin_candidate h
On 7 Feb 2025, at 14:17, Jason Merrill wrote:
> On 2/7/25 4:41 AM, Simon Martin wrote:
>> We've been rejecting the following valid code since GCC 4
>>
>> === cut here ===
>> struct A {
>>explicit A (int);
>>operator void* () const;
>> };
Hi Jason,
On 4 Feb 2025, at 21:06, Jason Merrill wrote:
> On 2/4/25 11:25 AM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 4 Feb 2025, at 1:11, Jason Merrill wrote:
>>
>>> On 1/31/25 11:12 AM, Simon Martin wrote:
>>>> Hi Jason,
>>>>
>&
Hi Jason,
On 9 Jan 2025, at 22:55, Jason Merrill wrote:
> On 1/9/25 8:25 AM, Simon Martin wrote:
>> We segfault upon the following invalid code
>>
>> === cut here ===
>> template struct S {
>>friend void foo (int a = []{}());
>> };
>> void
Hi,
On 29 Nov 2024, at 15:33, Simon Martin wrote:
> We currently ICE upon the following code, that is valid under
> -Wno-pointer-arith:
>
> === cut here ===
> int main() {
> decltype( [](auto) { return sizeof(void); } ) x;
> return x.operator()(0);
> }
> === cut
We currently ICE upon the following valid (under -Wno-vla) code
=== cut here ===
void f(int c) {
constexpr int r = 4;
[&](auto) { int t[r * c]; }(0);
}
=== cut here ===
The problem is that when parsing the lambda body, and more specifically
the multiplication, we mark the lambda as LAMBDA_EXP
Hi Marek,
On 13 Dec 2024, at 0:44, Marek Polacek wrote:
> On Thu, Dec 12, 2024 at 07:07:38PM +0000, Simon Martin wrote:
>> We currently ICE upon the following valid (under -Wno-vla) code
>>
>> === cut here ===
>> void f(int c) {
>> constexpr int r = 4;
&
Hi,
Could I please have feedback on the following patches?
PR c++/109918: Unexpected -Woverloaded-virtual with virtual conversion
operators
=> https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665650.html
PR c++/114292: ICE with a generic (templated) lambda capturing a
constant for VLA
Hi,
On 20 Dec 2024, at 20:37, Simon Martin wrote:
> We currently fail due to "infinite recursion" on the following invalid
> code with -std=c++20 and above
>
> === cut here ===
> template struct S { struct U { const S s; } u; };
> S t{2};
> === cut h
We currently fail due to "infinite recursion" on the following invalid
code with -std=c++20 and above
=== cut here ===
template struct S { struct U { const S s; } u; };
S t{2};
=== cut here ===
The problem is that reshape_init_class for S calls reshape_init_r for
its field S::u, that calls resha
When erroring out due to an incomplete type, we add a contextual note
about the type. However, when the error is suppressed by
-Wno-template-body, the note remains, making the compiler output quite
puzzling.
This patch makes sure the note is suppressed if we're processing a
template declaration bo
Hi,
On 21 Dec 2024, at 17:35, Simon Martin wrote:
> When erroring out due to an incomplete type, we add a contextual note
> about the type. However, when the error is suppressed by
> -Wno-template-body, the note remains, making the compiler output quite
> puzzling.
>
> This pa
We currently accept the following invalid code (EDG and MSVC do as well)
=== cut here ===
struct A {
*A ();
};
=== cut here ===
The problem is that we end up in grokdeclarator with a cp_declarator of
kind cdk_pointer but no type, and we happily go through (if we have a
reference instead we even
While testing an unrelated C++ patch with "make check-c++-all", I
noticed that r15-6760-g38a13ea4117b96 added a test case that fails with
-fimplicit-constexpr.
The problem is that this test unconditionally expects an error stating
that a non-constexpr function is called, but that function is
auto-
Hi Jason,
On 20 Jan 2025, at 22:49, Jason Merrill wrote:
> On 1/20/25 2:11 PM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 15 Jan 2025, at 22:42, Jason Merrill wrote:
>>
>>> On 12/12/24 2:07 PM, Simon Martin wrote:
>>>> We currently IC
Hi Marek,
On 23 Jan 2025, at 16:45, Marek Polacek wrote:
> On Thu, Jan 23, 2025 at 02:40:09PM +0000, Simon Martin wrote:
>> Hi Jason,
>>
>> On 20 Jan 2025, at 22:49, Jason Merrill wrote:
>>
>>> On 1/20/25 2:11 PM, Simon Martin wrote:
>>>> Hi
Hi Jason,
On 21 Jan 2025, at 22:51, Jason Merrill wrote:
> On 1/3/25 3:00 PM, Simon Martin wrote:
>> We currently accept this code with c++ <= 17 even though it's invalid
>> since the base is not initialized (we properly reject it with c++ >=
>> 20)
>>
>
Hi Jason,
On 23 Jan 2025, at 22:56, Jason Merrill wrote:
> On 1/23/25 12:06 PM, Simon Martin wrote:
>> Hi Marek,
>>
>> On 23 Jan 2025, at 16:45, Marek Polacek wrote:
>>
>>> On Thu, Jan 23, 2025 at 02:40:09PM +, Simon Martin wrote:
>>>> Hi
Hi Jakub,
On 20 Jan 2025, at 10:15, Jakub Jelinek wrote:
> On Mon, Jan 20, 2025 at 08:52:17AM +0000, Simon Martin wrote:
>> On 12 Jan 2025, at 12:10, Simon Martin wrote:
>>
>>> While testing an unrelated C++ patch with "make check-c++-all", I
>>> no
Hi,
On 12 Jan 2025, at 12:10, Simon Martin wrote:
> While testing an unrelated C++ patch with "make check-c++-all", I
> noticed that r15-6760-g38a13ea4117b96 added a test case that fails
> with
> -fimplicit-constexpr.
>
> The problem is that this test unconditiona
Hi Jason,
On 15 Jan 2025, at 22:42, Jason Merrill wrote:
> On 12/12/24 2:07 PM, Simon Martin wrote:
>> We currently ICE upon the following valid (under -Wno-vla) code
>>
>> === cut here ===
>> void f(int c) {
>>constexpr int r = 4;
>>[&](auto)
Hi,
On 3 Jan 2025, at 21:00, Simon Martin wrote:
> We currently accept this code with c++ <= 17 even though it's invalid
> since the base is not initialized (we properly reject it with c++ >=
> 20)
>
> === cut here ===
> struct NoMut1 { int a, b; };
> struct
Hi,
On 4 Jan 2025, at 16:13, Simon Martin wrote:
> The invalid case in this PR trips on an assertion in
> build_class_member_access_expr that build_base_path would never return
> an error_mark_node, which is actually incorrect if the object involves
> a
> tree with an
Hi Jakub,
On 20 Jan 2025, at 10:28, Simon Martin wrote:
> Hi Jakub,
>
> On 20 Jan 2025, at 10:15, Jakub Jelinek wrote:
>
>> On Mon, Jan 20, 2025 at 08:52:17AM +, Simon Martin wrote:
>>> On 12 Jan 2025, at 12:10, Simon Martin wrote:
>>>
>>>>
Hi Jason,
On 24 Jan 2025, at 16:51, Jason Merrill wrote:
> On 1/24/25 6:19 AM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 23 Jan 2025, at 22:56, Jason Merrill wrote:
>>
>>> On 1/23/25 12:06 PM, Simon Martin wrote:
>>>> Hi Marek,
>>
Hi Jason,
On 17 Jan 2025, at 23:33, Jason Merrill wrote:
> On 1/17/25 9:52 AM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 16 Jan 2025, at 22:49, Jason Merrill wrote:
>>
>>> On 10/16/24 11:43 AM, Simon Martin wrote:
>>>> As you know th
Hi Jason,
On 27 Jan 2025, at 20:53, Jason Merrill wrote:
> On 1/27/25 2:34 PM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 27 Jan 2025, at 15:23, Jason Merrill wrote:
>>
>>> On 1/27/25 8:14 AM, Simon Martin wrote:
>>>> Hi Jason,
>>
Hi Jason,
On 27 Jan 2025, at 15:23, Jason Merrill wrote:
> On 1/27/25 8:14 AM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 24 Jan 2025, at 16:51, Jason Merrill wrote:
>>
>>> On 1/24/25 6:19 AM, Simon Martin wrote:
>>>> Hi Jason,
>>
Hi Jason,
On 20 Jan 2025, at 22:50, Jason Merrill wrote:
> On 1/4/25 10:13 AM, Simon Martin wrote:
>> The invalid case in this PR trips on an assertion in
>> build_class_member_access_expr that build_base_path would never
>> return
>> an error_mark_node, which i
Hi,
On 24 Jan 2025, at 17:50, Jason Merrill wrote:
> On 1/23/25 12:20 PM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 21 Jan 2025, at 22:51, Jason Merrill wrote:
>>
>>> On 1/3/25 3:00 PM, Simon Martin wrote:
>>>> We currently accept this co
Hi,
On 9 Jan 2025, at 20:08, Simon Martin wrote:
> On 9 Jan 2025, at 20:00, Marek Polacek wrote:
>
>> On Thu, Jan 09, 2025 at 12:05:43PM -0500, Patrick Palka wrote:
>>> On Wed, 8 Jan 2025, Jason Merrill wrote:
>>>
>>>> On 12/21/24 11:35 AM, Simon Marti
[ Fixing David’s email address :-/ ]
Hi,
On 9 Jan 2025, at 20:08, Simon Martin wrote:
> On 9 Jan 2025, at 20:00, Marek Polacek wrote:
>
>> On Thu, Jan 09, 2025 at 12:05:43PM -0500, Patrick Palka wrote:
>>> On Wed, 8 Jan 2025, Jason Merrill wrote:
>>>
>>&
Hi,
On 14 Jan 2025, at 2:56, Jason Merrill wrote:
> On 1/12/25 2:39 PM, Simon Martin wrote:
>> [ Fixing David’s email address :-/ ]
>>
>> Hi,
>>
>> On 9 Jan 2025, at 20:08, Simon Martin wrote:
>>
>>> On 9 Jan 2025, at 20:00, Marek Polacek wrote:
&
[ Apologies for the previous incomplete, garbled email - I used the
shortcut to send the email by mistake way too early ]
Hi Jason,
On 14 Jan 2025, at 11:43, Simon Martin wrote:
> Hi,
>
> On 14 Jan 2025, at 2:56, Jason Merrill wrote:
>
>> On 1/12/25 2:39 PM, Simon Martin w
The invalid case in this PR trips on an assertion in
build_class_member_access_expr that build_base_path would never return
an error_mark_node, which is actually incorrect if the object involves a
tree with an error_mark_node DECL_INITIAL, like here.
This patch simply removes the assertion, even t
We currently fail with a checking assert upon the following valid code
when using -fno-elide-constructors
=== cut here ===
struct d { ~d(); };
d &b();
struct f {
[[__no_unique_address__]] d e;
};
struct h : f {
h() : f{b()} {}
} i;
=== cut here ===
The problem is that split_nonconstant_init_
We currently reject the following code
=== code here ===
template struct S { friend class non_template; };
class non_template {};
S<0> s;
=== code here ===
While EDG agrees with the current behaviour, clang and MSVC don't (see
https://godbolt.org/z/69TGaabhd), and I believe that this code is val
'make tags' currently fails for libcc1 with this:
*** No rule to make target `marshall-c.hh', needed by `tags-am'. Stop.
The problem is that while marshall-c.hh has been removed via
r12-454-g25d1a6ecdc443f, it's still part of the libcc1_la_SOURCES
variable, hence the 'tags' target has a dependen
Hi,
On 14 Jan 2025, at 23:31, Jason Merrill wrote:
> On 1/14/25 2:13 PM, Simon Martin wrote:
>> On 10 Jan 2025, at 19:10, Andrew Pinski wrote:
>>> On Fri, Jan 10, 2025 at 3:18 AM Simon Martin
>>> wrote:
>>>>
>>>> We currently accept the f
Hi Jakub, Jason,
On 15 Jan 2025, at 22:55, Jakub Jelinek wrote:
> On Wed, Jan 15, 2025 at 04:48:59PM -0500, Jason Merrill wrote:
>>> --- a/gcc/cp/decl.cc
>>> +++ b/gcc/cp/decl.cc
>>> @@ -11686,6 +11686,7 @@ fold_sizeof_expr (tree t)
>>> false, false);
>>> if (r
On 16 Jan 2025, at 16:05, Jason Merrill wrote:
> On 1/16/25 7:19 AM, Simon Martin wrote:
>> Hi Jakub, Jason,
>>
>> On 15 Jan 2025, at 22:55, Jakub Jelinek wrote:
>>
>>> On Wed, Jan 15, 2025 at 04:48:59PM -0500, Jason Merrill wrote:
>>>>&
Hi,
On 20 Dec 2024, at 20:56, Simon Martin wrote:
> Hi,
>
> On 20 Dec 2024, at 20:37, Simon Martin wrote:
>
>> We currently fail due to "infinite recursion" on the following invalid
>> code with -std=c++20 and above
>>
>> === cut here ===
>
On 9 Jan 2025, at 18:05, Patrick Palka wrote:
> On Wed, 8 Jan 2025, Jason Merrill wrote:
>
>> On 12/21/24 11:35 AM, Simon Martin wrote:
>>> When erroring out due to an incomplete type, we add a contextual
>>> note
>>> about the type. However, when the e
Hi Jason,
On 16 Jan 2025, at 22:49, Jason Merrill wrote:
> On 10/16/24 11:43 AM, Simon Martin wrote:
>> As you know the patch had to be reverted due to PR117114, that
>> highlighted a bunch of issues with comparing DECL_VINDEXes: it might
>> give false positives in case of
On 17 Jan 2025, at 0:12, Jason Merrill wrote:
> On 1/5/25 11:19 AM, Simon Martin wrote:
>> We currently reject the following code
>>
>> === code here ===
>> template struct S { friend class non_template; };
>> class non_template {};
>> S<0> s;
>>
Hi Jason,
On 8 Jan 2025, at 22:56, Jason Merrill wrote:
> On 12/21/24 11:35 AM, Simon Martin wrote:
>> When erroring out due to an incomplete type, we add a contextual note
>> about the type. However, when the error is suppressed by
>> -Wno-template-body, the note remains
We segfault upon the following invalid code
=== cut here ===
template struct S {
friend void foo (int a = []{}());
};
void foo (int a) {}
int main () {
S<0> t;
foo ();
}
=== cut here ===
The problem is that we end up with a LAMBDA_EXPR callee in
set_flags_from_callee, and dereference its N
On 9 Jan 2025, at 20:00, Marek Polacek wrote:
> On Thu, Jan 09, 2025 at 12:05:43PM -0500, Patrick Palka wrote:
>> On Wed, 8 Jan 2025, Jason Merrill wrote:
>>
>>> On 12/21/24 11:35 AM, Simon Martin wrote:
>>>> When erroring out due to an incomplete type, we ad
Hi,
On 10 Jan 2025, at 19:10, Andrew Pinski wrote:
> On Fri, Jan 10, 2025 at 3:18 AM Simon Martin
> wrote:
>>
>> We currently accept the following invalid code (EDG and MSVC do as
>> well)
>
> clang does too: https://github.com/llvm/llvm-project/issues/121706 .
On 14 Feb 2025, at 17:51, Marek Polacek wrote:
> On Fri, Feb 14, 2025 at 04:45:01PM +0000, Simon Martin wrote:
>> Hi Marek,
>>
>> On 14 Feb 2025, at 17:27, Marek Polacek wrote:
>>
>>> On Fri, Feb 14, 2025 at 04:20:07PM +, Simon Martin wrote:
>>>>
Hi Marek,
On 14 Feb 2025, at 17:27, Marek Polacek wrote:
> On Fri, Feb 14, 2025 at 04:20:07PM +0000, Simon Martin wrote:
>> The case in this PR does not ICE anymore after the fix for PR118319.
>>
>> This patch simply adds the case to the testsuite.
>>
>> Su
We have been miscompiling the following valid code since GCC8, and
r8-3497-g281e6c1d8f1b4c
=== cut here ===
struct span {
span (const int (&__first)[1]) : _M_ptr (__first) {}
int operator[] (long __i) { return _M_ptr[__i]; }
const int *_M_ptr;
};
void foo () {
constexpr int a_vec[]{1};
a
The case in this PR does not ICE anymore after the fix for PR118319.
This patch simply adds the case to the testsuite.
Successfully tested on x86_64-apple-darwin19.6.0.
PR c++/117324
gcc/testsuite/ChangeLog:
* g++.dg/parse/defarg19.C: New test.
---
gcc/testsuite/g++.dg/parse/
A checking assert triggers upon the following invalid code since
GCC 11:
=== cut here ===
class { a (struct b;
} struct b
=== cut here ===
The problem is that during error recovery, we call
set_identifier_type_value_with_scope for B in the global namespace, and
the checking assert added via r11-7
We've been rejecting this valid code since r8-4571:
=== cut here ===
void foo (float);
int main () {
constexpr float x = 0;
(void) [&] () {
foo (x);
(void) [] () {
foo (x);
};
};
}
=== cut here ===
The problem is that when processing X in the inner lambda,
process_outer_va
Hi,
On 18 Feb 2025, at 14:00, Simon Martin wrote:
> A checking assert triggers upon the following invalid code since
> GCC 11:
>
> === cut here ===
> class { a (struct b;
> } struct b
> === cut here ===
>
> The problem is that during error recovery, we call
> set_id
Hi,
On 18 Feb 2025, at 11:12, Simon Martin wrote:
> We've been rejecting this valid code since r8-4571:
>
> === cut here ===
> void foo (float);
> int main () {
> constexpr float x = 0;
> (void) [&] () {
> foo (x);
> (void) [] () {
> foo
Hi,
On 14 Feb 2025, at 18:08, Simon Martin wrote:
> We have been miscompiling the following valid code since GCC8, and
> r8-3497-g281e6c1d8f1b4c
>
> === cut here ===
> struct span {
> span (const int (&__first)[1]) : _M_ptr (__first) {}
> int operator[] (long
The build is broken on MacOS since r15-7881-ge8651b80aeb86d because
tree-vect-data-refs.cc uses std::min but does not include .
This patch fixes it by defining INCLUDE_ALGORITHM in that file.
Successfully built on x86_64-apple-darwin19.6.0.
gcc/ChangeLog:
* tree-vect-data-refs.cc: Defin
On Wed Mar 5, 2025 at 10:32 PM CET, Jason Merrill wrote:
> On 3/5/25 6:58 AM, Simon Martin wrote:
>> Hi Jason,
>>
>> On Tue Mar 4, 2025 at 11:47 PM CET, Jason Merrill wrote:
>>> On 2/14/25 12:08 PM, Simon Martin wrote:
>>>> We have been miscompilin
While investigating PR c++/99538 I noticed two comment typos: "delared"
and "paramter". The first has a single occurrence, but the second a few
more. This patch fixes all of them.
I'll commit it as obvious.
gcc/ChangeLog:
* config/i386/x86-tune-sched.cc (ix86_fuse_mov_alu_p): Fix
Hi Jason,
On Wed Mar 5, 2025 at 9:40 PM CET, Jason Merrill wrote:
> On 3/5/25 10:39 AM, Simon Martin wrote:
>> Hi Jason,
>>
>> On Wed Mar 5, 2025 at 12:03 AM CET, Jason Merrill wrote:
>>> On 2/18/25 5:12 AM, Simon Martin wrote:
>>>> We'
The build currently fails on MacOS even when the Cobol front-end and
libgcobol builds are disabled.
The problem is that gcc/cobol/Make-lang.in adds -Iinclude to CPPFLAGS,
which somehow makes clang unhappy about the include order:
error: tried including but didn't find libc++'s
header. This
Hi Robert,
On Wed Mar 12, 2025 at 2:12 PM CET, Robert Dubner wrote:
>
>
>> -Original Message-----
>> From: Simon Martin
>> Sent: Wednesday, March 12, 2025 06:27
>> To: gcc-patches@gcc.gnu.org
>> Cc: rdub...@symas.com
>> Subject: [PATCH] cobol: Remov
Hi Jason,
On Tue Mar 4, 2025 at 11:47 PM CET, Jason Merrill wrote:
> On 2/14/25 12:08 PM, Simon Martin wrote:
>> We have been miscompiling the following valid code since GCC8, and
>> r8-3497-g281e6c1d8f1b4c
>>
>> === cut here ===
>> struct span {
>>
Hi Jason,
On Wed Mar 5, 2025 at 12:03 AM CET, Jason Merrill wrote:
> On 2/18/25 5:12 AM, Simon Martin wrote:
>> We've been rejecting this valid code since r8-4571:
>>
>> === cut here ===
>> void foo (float);
>> int main () {
>>constexpr float
Hi,
On Thu Mar 6, 2025 at 8:06 PM CET, Simon Martin wrote:
> Hi Jason,
>
> On Wed Mar 5, 2025 at 9:40 PM CET, Jason Merrill wrote:
>> On 3/5/25 10:39 AM, Simon Martin wrote:
>>> Hi Jason,
>>>
>>> On Wed Mar 5, 2025 at 12:03 AM CET, Jason Merrill wrote:
&
Hi,
On Sat Sep 14, 2024 at 10:00 AM CEST, Jason Merrill wrote:
> On 9/13/24 1:31 PM, Simon Martin wrote:
>> We currently ICE upon the following testcase when using -ftime-report
>>
>> === cut here ===
>> template < int> using __conditional_t = int;
>>
Hi,
On Thu Mar 20, 2025 at 2:54 PM CET, Jason Merrill wrote:
[...]
> Thanks a lot. Merged to trunk as r15-7238-gceabea405ffdc8.
>
> Even though it’s an “old” regression (from GCC 7), it’s a
> reject-valid and I’m tempted to backport; OK for active branches as
> well?
>>>
We've been miscompiling the following since r0-51314-gd6b4ea8592e338 (I
did not go compile something that old, and identified this change via
git blame, so might be wrong)
=== cut here ===
struct Foo { int x; };
Foo& get (Foo &v) { return v; }
void bar () {
Foo v; v.x = 1;
(true ? get (v) : ge
Hi Jason,
On Mon Jan 27, 2025 at 9:10 PM CET, Simon Martin wrote:
> Hi Jason,
>
> On 27 Jan 2025, at 20:53, Jason Merrill wrote:
>
>> On 1/27/25 2:34 PM, Simon Martin wrote:
>>> Hi Jason,
>>>
>>> On 27 Jan 2025, at 15:23, Jason Merrill wrote:
&g
Hi,
On Tue Mar 25, 2025 at 6:52 PM CET, Jason Merrill wrote:
> On 3/25/25 1:50 PM, Marek Polacek wrote:
>> On Tue, Mar 25, 2025 at 05:18:23PM +0000, Simon Martin wrote:
>>> We've been miscompiling the following since r0-51314-gd6b4ea8592e338 (I
>>> did not go
Hi,
On Thu Mar 6, 2025 at 10:15 AM CET, Simon Martin wrote:
> On Wed Mar 5, 2025 at 10:32 PM CET, Jason Merrill wrote:
>> On 3/5/25 6:58 AM, Simon Martin wrote:
>>> Hi Jason,
>>>
>>> On Tue Mar 4, 2025 at 11:47 PM CET, Jason Merrill wrote:
>>>> O
Hi,
On Sun Mar 23, 2025 at 8:30 PM CET, Jason Merrill wrote:
> On 3/23/25 1:55 AM, Simon Martin wrote:
>> Hi,
>>
>> On Sat Sep 14, 2024 at 10:00 AM CEST, Jason Merrill wrote:
>>> On 9/13/24 1:31 PM, Simon Martin wrote:
>>>> We currently ICE upon the f
Hi,
On Tue Mar 25, 2025 at 8:33 PM CET, Simon Martin wrote:
> Hi,
>
> On Tue Mar 25, 2025 at 6:52 PM CET, Jason Merrill wrote:
>> On 3/25/25 1:50 PM, Marek Polacek wrote:
>>> On Tue, Mar 25, 2025 at 05:18:23PM +, Simon Martin wrote:
>>>> We've been
Hi Jason,
On Thu Apr 10, 2025 at 10:42 PM CEST, Jason Merrill wrote:
> On 9/6/24 7:15 AM, Simon Martin wrote:
>> We ICE upon the following *valid* code when mangling the requires
>> clause
>>
>> === cut here ===
>> template struct s1 {
>>enum {
101 - 179 of 179 matches
Mail list logo
