We currently ICE when emitting the error message for this invalid code:
=== cut here ===
struct foo {
template void not_const() {}
};
void fn(const foo& obj) {
obj.not_const<5>();
}
=== cut here ===
The problem is that get_fndecl_argument_location assumes that it has a
FUNCTION_DECL in its ha
On 29 Jun 2024, at 0:00, Patrick Palka wrote:
> On Fri, 28 Jun 2024, Simon Martin wrote:
>
>> We currently ICE when emitting the error message for this invalid
>> code:
>>
>> === cut here ===
>> struct foo {
>> template void not_const() {}
>> };
We currently ICE upon the following valid code, due to the fix made through
commit 9efe5fbde1e8
=== cut here ===
struct ignore { ignore(...) {} };
template
void InternalCompilerError(Args... args)
{ ignore{ ignore(args) ... }; }
int main() { InternalCompilerError(0, 0); }
=== cut here ===
Change
On 6 May 2024, at 18:28, Jason Merrill wrote:
On 5/6/24 09:20, Simon Martin wrote:
Hi,
We currently ICE upon the following invalid snippet because we fail
to properly handle tsubst_arg_types returning error_mark_node in
build_deduction_guide.
== cut ==
template
struct A { A(Ts...); };
A a
Hi,
The test case in PR c++/105229 has been fixed since 11.4 (via PR
c++/106024) - the attached patch simply adds the case to the test suite.
Successfully tested on x86_64-pc-linux-gnu. OK for trunk?
Thanks! Simon
PR c++/105229
gcc/testsuite/ChangeLog:
* g++.dg/parse/crash
We currently fail upon the following because an assert in dependent_type_p
fails for f's parameter
=== cut here ===
consteval int id (int i) { return i; }
constexpr int
f (auto i) requires requires { id (i) } { return i; }
void g () { f (42); }
=== cut here ===
This patch fixes this by handling s
From: Simon Martin
We currently ICE upon the following because we don't properly handle the
overload created for B::f through the using statement.
=== cut here ===
struct B { static int f(); };
struct D : B { using B::f; };
void f(D d) { &d.f; }
=== cut here ===
This pa
Hi Jason,
Thanks for the review.
On 31 May 2024, at 22:45, Jason Merrill wrote:
> On 5/30/24 07:31, Simon Martin wrote:
>> We currently fail upon the following because an assert in
>> dependent_type_p
>> fails for f's parameter
>>
>> === cut here ===
I realized that I committed a change with a missing space after seen_error.
This fixes it, as well as another occurrence in the same file.
Apologies for the mistake - I'll commit this as obvious.
gcc/cp/ChangeLog:
* pt.cc (tsubst_expr): Add missing space after seen_error.
(depend
The case in that PR used to ICE until commit f04dc89. This patch simply adds
the case to the testsuite.
Successfully tested on x86_64-pc-linux-gnu.
PR c++/1033388
gcc/testsuite/ChangeLog:
* g++.dg/parse/crash73.C: New test.
---
gcc/testsuite/g++.dg/parse/crash73.C | 19 +++
We have been accepting the following invalid code since revision 557831a91df
=== cut here ===
template struct S {
enum E { a };
enum E { b };
};
S s;
=== cut here ===
The problem is that start_enum will set OPAQUE_ENUM_P to true even if it
retrieves an existing definition for the enum, which
We currently ICE upon the following invalid code, because we don't check the
number of template parameters in member class template specializations. This
patch fixes the PR by adding such a check.
=== cut here ===
template struct x {
template struct y {
typedef T result2;
};
};
template<
The case in PR113746 used to ICE until commit f04dc89a991. This patch
simply adds the case to the testsuite.
Successfully tested on x86_64-pc-linux-gnu.
PR c++/113746
gcc/testsuite/ChangeLog:
* g++.dg/parse/crash76.C: New test.
---
gcc/testsuite/g++.dg/parse/crash76.C | 6
We currently emit an incorrect -Woverloaded-virtual warning upon the following
test case
=== cut here ===
struct A {
virtual operator int() { return 42; }
virtual operator char() = 0;
};
struct B : public A {
operator char() { return 'A'; }
};
=== cut here ===
The problem is that warn_hidde
Hi Jason,
On 24 Aug 2024, at 15:13, Jason Merrill wrote:
> On 8/23/24 12:44 PM, Simon Martin wrote:
>> We currently emit an incorrect -Woverloaded-virtual warning upon the
>> following
>> test case
>>
>> === cut here ===
>> struct A {
>>virtua
Hi Jason,
On 24 Aug 2024, at 23:59, Simon Martin wrote:
> Hi Jason,
>
> On 24 Aug 2024, at 15:13, Jason Merrill wrote:
>
>> On 8/23/24 12:44 PM, Simon Martin wrote:
>>> We currently emit an incorrect -Woverloaded-virtual warning upon the
>>> followin
Hi Jason,
On 22 Aug 2024, at 19:28, Jason Merrill wrote:
> On 8/22/24 12:51 PM, Simon Martin wrote:
>> We currently ICE upon the following invalid code, because we don't
>> check the
>> number of template parameters in member class template
>> specialization
We mention 'X::__ct' instead of 'X::X' in the "names the constructor,
not the type" error for this invalid code:
=== cut here ===
struct X {};
void g () {
X::X x;
}
=== cut here ===
The problem is that we use %<%T::%D%> to build the error message, while
%qE does exactly what we need since we ha
Hi Jason,
On 26 Aug 2024, at 19:30, Jason Merrill wrote:
> On 8/26/24 12:49 PM, Simon Martin wrote:
>> We mention 'X::__ct' instead of 'X::X' in the "names the constructor,
>> not the type" error for this invalid code:
>>
>> ===
Hi Jason,
On 4 Jun 2024, at 18:12, Jason Merrill wrote:
> On 6/4/24 11:54, Simon Martin wrote:
>> The case in that PR used to ICE until commit f04dc89.
>
> Interesting, I don't remember expecting that patch to change behavior
> at all.
This is the patch that git bisec
We currently ICE upon the following because we don't properly handle local
functions with an error_mark_node as DECL_LOCAL_DECL_ALIAS in duplicate_decls.
=== cut here ===
void f (void) {
virtual int f (void) const;
virtual int f (void);
}
=== cut here ===
This patch fixes this by checking for
Hi,
There was a formatting error, corrected in the updated attached patch
:-/
On 5 Jun 2024, at 10:13, Simon Martin wrote:
> We currently ICE upon the following because we don't properly handle
> local
> functions with an error_mark_node as DECL_LOCAL_DECL_ALIAS in
>
On 5 Jun 2024, at 10:34, Jakub Jelinek wrote:
> On Wed, Jun 05, 2024 at 08:13:14AM +0000, Simon Martin wrote:
>> --- a/gcc/cp/decl.cc
>> +++ b/gcc/cp/decl.cc
>> @@ -2792,10 +2792,13 @@ duplicate_decls (tree newdecl, tree olddecl,
>> bool hiding, bool was_hidden)
&
We ICE upon the following when trying to emit a -Wlogical-not-parentheses
warning:
=== cut here ===
template T foo (T arg, T& ref, T* ptr) {
int a = 1;
return static_cast(a);
}
=== cut here ===
This patch makes *_cast<*> parsing more robust by skipping to the closing '>'
upon error in the ta
The build fails on x86_64-apple-darwin19.6.0 starting with 5b6d5a886ee because
vector is included after system.h and runs into poisoned identifiers.
This patch fixes this by defining INCLUDE_VECTOR before including system.h.
Validated by doing a full build on x86_64-apple-darwin19.6.0.
gcc/lto/C
Hi Jason,
On 7 Jun 2024, at 19:30, Jason Merrill wrote:
> On 6/7/24 08:12, Simon Martin wrote:
>> We ICE upon the following when trying to emit a
>> -Wlogical-not-parentheses
>> warning:
>>
>> === cut here ===
>> template T foo (T arg, T& r
The case in the ticket is an ICE on invalid due to an assert in stabilize_expr,
but the underlying issue can actually trigger on this *valid* code:
=== cut here ===
struct TheClass {
TheClass() {}
TheClass(volatile TheClass& t) {}
TheClass operator=(volatile TheClass& t) volatile { return t;
-linux-gnu. OK for trunk?
Thanks!
-- Simon
diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
index a78d9d546d6..9acef73e7ac 100644
--- a/gcc/cp/ChangeLog
+++ b/gcc/cp/ChangeLog
@@ -1,3 +1,9 @@
+2024-05-06 Simon Martin
+
+ PR c++/105760
+ * pt.c (build_deduction_guide): Check for
Hi Jason,
On 26 Aug 2024, at 19:23, Jason Merrill wrote:
> On 8/25/24 12:37 PM, Simon Martin wrote:
>> On 24 Aug 2024, at 23:59, Simon Martin wrote:
>>> On 24 Aug 2024, at 15:13, Jason Merrill wrote:
>>>
>>>> On 8/23/24 12:44 PM, Simon Martin wrot
Hi Jason,
On 4 Sep 2024, at 18:09, Jason Merrill wrote:
> On 9/1/24 2:51 PM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 26 Aug 2024, at 19:23, Jason Merrill wrote:
>>
>>> On 8/25/24 12:37 PM, Simon Martin wrote:
>>>> On 24 Aug 2024, at 23:59, Si
We ICE upon the following *valid* code when mangling the requires
clause
=== cut here ===
template struct s1 {
enum { e1 = 1 };
};
template struct s2 {
enum { e1 = s1::e1 };
s2() requires(0 != e1) {}
};
s2<8> a;
=== cut here ===
The problem is that the mangler wrongly assumes that the DEC
We currently crash upon the following valid code (the case from the PR,
invalid, can be made valid by simply adding a definition for f at line
2)
=== cut here ===
struct B { const int *p; };
template void f() {}
struct Nested { union { int k; }; } nested;
template void f();
=== cut here ===
The p
We currently ICE upon the following code while building the "[...] is
private within this context" error message
=== cut here ===
class A { enum Enum{}; };
template class Alloc>
class B : private Alloc, private A {};
template class Alloc>
int B::foo (Enum m) { return 42; }
=== cut here ===
The pr
On 11 Sep 2024, at 20:57, Jason Merrill wrote:
> On 9/11/24 7:26 AM, Simon Martin wrote:
>> We currently ICE upon the following code while building the "[...] is
>> private within this context" error message
>>
>> === cut here ===
>> class A { enum Enu
tested on x86_64-pc-linux-gnu. OK for trunk?
Thanks, Simon
On 10 Sep 2024, at 20:06, Simon Martin wrote:
> We currently crash upon the following valid code (the case from the
> PR,
> invalid, can be made valid by simply adding a definition for f at line
> 2)
>
> === cut h
Hi Jason,
On 12 Sep 2024, at 16:48, Jason Merrill wrote:
> On 9/12/24 7:23 AM, Simon Martin wrote:
>> Hi,
>>
>> While looking at more open PRs, I have discovered that the problem
>> reported in PR109790 is very similar to that in PR100632, so I’m
>> combining bot
We currently ICE upon the following testcase when using -ftime-report
=== cut here ===
template < int> using __conditional_t = int;
template < typename _Iter >
concept random_access_iterator = requires { new _Iter; };
template < typename _Iterator >
struct reverse_iterator {
using iterator_conce
Hi Jason,
On 14 Sep 2024, at 18:11, Jason Merrill wrote:
> On 9/13/24 11:06 AM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 12 Sep 2024, at 16:48, Jason Merrill wrote:
>>
>>> On 9/12/24 7:23 AM, Simon Martin wrote:
>>>> Hi,
>>>>
>
Hi Jason,
On 14 Sep 2024, at 18:44, Simon Martin wrote:
> Hi Jason,
>
> On 14 Sep 2024, at 18:11, Jason Merrill wrote:
>
>> On 9/13/24 11:06 AM, Simon Martin wrote:
>>> Hi Jason,
>>>
>>> On 12 Sep 2024, at 16:48, Jason Merrill wrote:
>>>
Hi Jason,
Apologies for the back and forth and thanks for your patience!
On 5 Sep 2024, at 19:00, Jason Merrill wrote:
> On 9/5/24 7:02 AM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 4 Sep 2024, at 18:09, Jason Merrill wrote:
>>
>>> On 9/1/24 2:51 P
The invalid test case in this PR highlights a bad interaction between
the tentative_firewall and error recovery in cp_parser_decltype: the
firewall makes cp_parser_skip_to_closing_parenthesis a no-op, and the
parser does not make any progress, running "forever".
This patch calls cp_parser_commit_t
7;
already encountered.
The attached patch fixes this by only calling 'composite_type' if
'comptypes' returned a non-zero value, as stated in this function's
documentation.
I've successfully bootstrapped and tested it on
x86_64-apple-darwin10.6.0. Is it OK fo
The patch that I merged via r15-4282-g60163c85730e6b breaks the build
for the rust front-end because it does not work well when virtual
inheritance is in play.
The problem is that in such a case, an overrider and its overridden base
method might have a different DECL_VINDEX, and the derived method
The patch failed so I’ve reverted the offending commit for the
moment; commit r15-4301-ga4eec6c712ec16 refers.
I’ll work on a resubmit via the initial PR (109918).
Apologies for the breakage.
Simon
On 13 Oct 2024, at 13:55, Simon Martin wrote:
> The patch that I merged via r15-4
Hi Jason,
On 15 Oct 2024, at 15:18, Jason Merrill wrote:
> On 10/13/24 7:55 AM, Simon Martin wrote:
>> The patch that I merged via r15-4282-g60163c85730e6b breaks the build
>> for the rust front-end because it does not work well when virtual
>> inheritance is in play.
>
Hi Jason,
On 30 Sep 2024, at 20:56, Jason Merrill wrote:
> On 9/17/24 8:14 AM, Simon Martin wrote:
>> The invalid test case in this PR highlights a bad interaction between
>> the tentative_firewall and error recovery in cp_parser_decltype: the
&g
cp-demangle.c does not build when CP_DEMANGLE_DEBUG is defined since
r13-2887-gb04208895fed34. This trivial patch fixes the issue.
Tested on x86_64-apple-darwin19.6.0 with "make && make check" in
libiberty with CP_DEMANGLE_DEBUG defined.
I'm applying this as obvious.
libiberty/ChangeLog:
Friendly ping. Thanks!
On 17 Sep 2024, at 14:14, Simon Martin wrote:
> The invalid test case in this PR highlights a bad interaction between
> the tentative_firewall and error recovery in cp_parser_decltype: the
> firewall makes cp_parser_skip_to_closing_parenthesis a no-op, and the
Hi Jason,
On 17 Sep 2024, at 18:41, Jason Merrill wrote:
> On 9/17/24 10:38 AM, Simon Martin wrote:
>> Hi Jason,
>>
>> Apologies for the back and forth and thanks for your patience!
>
> No worries.
>
>> On 5 Sep 2024, at 19:00, Jason Merrill wrote:
>>
Hi Jason,
On 7 Oct 2024, at 18:58, Jason Merrill wrote:
> On 10/7/24 11:27 AM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 17 Sep 2024, at 18:41, Jason Merrill wrote:
>>
>>> On 9/17/24 10:38 AM, Simon Martin wrote:
>>>> Hi Jason,
>>>&g
Hi Marek,
On 7 Oct 2024, at 21:44, Marek Polacek wrote:
> On Mon, Oct 07, 2024 at 07:35:27PM +0000, Simon Martin wrote:
>> -/* Remove any overridden functions. */
>> -bool seen_non_override = false;
>> +/* Find all the base_fndecls that are overrid
We currently ICE in checking mode with cxx_dialect < 17 on the following
valid code
=== cut here ===
struct X {
X(const X&) {}
};
extern X x;
void foo () {
new X[1]{x};
}
=== cut here ===
The problem is that cp_gimplify_expr gcc_checking_asserts that a
TARGET_EXPR is not TARGET_EXPR_ELIDING_P
On 18 Oct 2024, at 10:55, Sam James wrote:
> Simon Martin writes:
>
>> Hi Sam,
>
> Hi Simon,
>
>>
>> On 16 Oct 2024, at 22:06, Sam James wrote:
>>
>>> Simon Martin writes:
>>>
>>>> We ICE upon the following invalid code bec
Hi Jason,
On 12 Oct 2024, at 4:51, Jason Merrill wrote:
> On 10/11/24 7:02 AM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 11 Oct 2024, at 0:35, Jason Merrill wrote:
>>
>>> On 10/7/24 3:35 PM, Simon Martin wrote:
>>>> On 7 Oct 2024, at 18:58, Jason
Hi Sam,
On 16 Oct 2024, at 22:06, Sam James wrote:
> Simon Martin writes:
>
>> We ICE upon the following invalid code because we end up calling
>> finalize_nrv_r with a RETURN_EXPR with no operand.
>>
>> === cut here ===
>> struct X {
>> ~X();
&
We ICE upon the following invalid code because we end up calling
finalize_nrv_r with a RETURN_EXPR with no operand.
=== cut here ===
struct X {
~X();
};
X test(bool b) {
{
X x;
return x;
}
if (!(b)) return;
}
=== cut here ===
This patch fixes this by simply returning error_mark_no
This is a follow-up to the discussion about testing changes to the C++
front end in
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664258.html
It also clarifies that the make invocation examples should be made from
the *build* tree.
Validated fine via https://validator.w3.org.
---
htdocs
Hi Jason,
On 11 Oct 2024, at 0:35, Jason Merrill wrote:
> On 10/7/24 3:35 PM, Simon Martin wrote:
>> On 7 Oct 2024, at 18:58, Jason Merrill wrote:
>>> On 10/7/24 11:27 AM, Simon Martin wrote:
>
>>>>/* Now give a warning for all base functions without override
Friendly ping. Thanks! Simon
On 16 Oct 2024, at 17:43, Simon Martin wrote:
> Hi Jason,
>
> On 12 Oct 2024, at 4:51, Jason Merrill wrote:
>
>> On 10/11/24 7:02 AM, Simon Martin wrote:
>>> Hi Jason,
>>>
>>> On 11 Oct 2024, at 0:35, Jason Merrill wro
On 19 Oct 2024, at 11:09, Simon Martin wrote:
> We currently ICE in checking mode with cxx_dialect < 17 on the
> following
> valid code
>
> === cut here ===
> struct X {
> X(const X&) {}
> };
> extern X x;
> void foo () {
> new X[1]{x};
> }
Hi Jason,
On 1 Nov 2024, at 16:31, Jason Merrill wrote:
> On 11/1/24 5:07 AM, Simon Martin wrote:
>> Since r10-3793-g1a37b6d9a7e57c, we ICE upon the following valid code
>> with -std=c++17 and above
>>
>> === cut here ===
>> struct Base {
>>unsigned i
Hi Jason,
On 5 Nov 2024, at 3:30, Jason Merrill wrote:
> On 10/30/24 12:34 PM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 22 Oct 2024, at 17:07, Jason Merrill wrote:
>>
>>> On 10/17/24 10:30 AM, Simon Martin wrote:
>>>> Hi,
>>>>
>>
Hi Jason,
On 5 Nov 2024, at 1:23, Jason Merrill wrote:
> On 11/4/24 10:19 AM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 1 Nov 2024, at 16:31, Jason Merrill wrote:
>>
>>> On 11/1/24 5:07 AM, Simon Martin wrote:
>>>> Since r10-3793-g1a37b6d9a7
[ Resending since this was somehow sent in HMTL mode and was scrubbed ]
On 30 Oct 2024, at 17:16, Simon Martin wrote:
> Hi,
>
> Just closing the loop on this...
>
> On 19 Oct 2024, at 11:57, Iain Sandoe wrote:
>
> On 19 Oct 2024, at 10:16, Simon Martin wrote:
>
> On
Hi,
Just closing the loop on this...
On 19 Oct 2024, at 11:57, Iain Sandoe wrote:
On 19 Oct 2024, at 10:16, Simon Martin wrote:
On 18 Oct 2024, at 10:55, Sam James wrote:
Simon Martin writes:
Hi Sam,
Hi Simon,
On 16 Oct 2024, at 22:06, Sam James wrote:
Simon Martin writes:
We ICE upon
We currently crash upon the following invalid code (notice the "void
void**" parameter)
=== cut here ===
using size_t = decltype(sizeof(int));
void *operator new(size_t, void void **p) noexcept { return p; }
int x;
void f() {
int y;
new (&y) int(x);
}
=== cut here ===
The problem is that
Hi Jason,
On 22 Oct 2024, at 17:07, Jason Merrill wrote:
> On 10/17/24 10:30 AM, Simon Martin wrote:
>> Hi,
>>
>> The issue reported in PR117129 is pretty similar to the one in
>> PR117099,
>>
>> so here’s an updated version of the patch that fix
Hi Jason,
On 6 Nov 2024, at 20:47, Jason Merrill wrote:
> On 11/6/24 2:23 PM, Simon Martin wrote:
>> Even though this PR is very close to PR117101, it's not addressed by
>> the
>> fix I made through r15-4958-g5821f5c8c89a05 because
>> cxx_placement_new_
Hi,
On 30 Oct 2024, at 11:44, Simon Martin wrote:
> Friendly ping.
Friendly ping.
Thanks! Simon
>
> On 16 Oct 2024, at 17:43, Simon Martin wrote:
>
>> Hi Jason,
>>
>> On 12 Oct 2024, at 4:51, Jason Merrill wrote:
>>
>>> On 10/11/24 7:02 AM, Simon Mar
Hi,
On 30 Oct 2024, at 11:46, Simon Martin wrote:
> On 19 Oct 2024, at 11:09, Simon Martin wrote:
>
>> We currently ICE in checking mode with cxx_dialect < 17 on the
>> following
>> valid code
>>
>> === cut here ===
>> struct X {
>> X(const X&
Since r10-3793-g1a37b6d9a7e57c, we ICE upon the following valid code
with -std=c++17 and above
=== cut here ===
struct Base {
unsigned int *intarray;
};
template struct Sub : public Base {
bool Get(int i) {
return (Base::intarray[++i] == 0);
}
};
=== cut here ===
The problem is that fr
The testcase in PR101887 has been working since the fix for PR104846,
via r12-7599-gac8310dd122172.
This patch simply adds the case to the testsuite.
Successfully tested on x86_64-pc-linux-gnu.
PR c++/101887
gcc/testsuite/ChangeLog:
* g++.dg/init/delete5.C: Add testcase from PR
Hi Jason,
On 20 Sep 2024, at 18:01, Jason Merrill wrote:
> On 9/20/24 5:21 PM, Simon Martin wrote:
>> The following code triggers an ICE
>>
>> === cut here ===
>> class base {};
>> class derived : virtual public base {
>> public:
>>templat
Hi Jason,
On 20 Sep 2024, at 18:06, Jason Merrill wrote:
> On 9/16/24 4:07 PM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 14 Sep 2024, at 18:44, Simon Martin wrote:
>>
>>> Hi Jason,
>>>
>>> On 14 Sep 2024, at 18:11, Jason Merrill wrote:
>
The following code triggers an ICE
=== cut here ===
class base {};
class derived : virtual public base {
public:
template constexpr derived(Arg) {}
};
int main() {
derived obj(1.);
}
=== cut here ===
The problem is that cxx_bind_parameters_in_call ends up attempting to
convert a REAL_CST (the
Hi Jason,
On 30 Sep 2024, at 19:56, Jason Merrill wrote:
> On 9/23/24 4:44 AM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 20 Sep 2024, at 18:01, Jason Merrill wrote:
>>
>>> On 9/20/24 5:21 PM, Simon Martin wrote:
>>>> The following code triggers a
Hi Jason,
On 2 Oct 2024, at 0:18, Jason Merrill wrote:
> On 10/1/24 12:44 PM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 30 Sep 2024, at 19:56, Jason Merrill wrote:
>>
>>> On 9/23/24 4:44 AM, Simon Martin wrote:
>>>> Hi Jason,
>>>>
>&
on x86_64-pc-linux-gnu. OK for trunk?
Thanks, SimonFrom ff01d18d97893ef65259f9063794945d5062cf4e Mon Sep 17 00:00:00 2001
From: Simon Martin
Date: Wed, 16 Oct 2024 15:47:12 +0200
Subject: [PATCH] c++: Fix crash during NRV optimization with invalid input
[PR117099, PR117129]
PR117099 and PR117129
Even though this PR is very close to PR117101, it's not addressed by the
fix I made through r15-4958-g5821f5c8c89a05 because cxx_placement_new_fn
has the very same issue as std_placement_new_fn_p used to have.
This patch fixes the issue exactly the same, by checking the first
parameter against NUL
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 here ===
The problem is that "fold_sizeof_expr (sizeof(void))" returns
size_one_node, that has a d
We currently reject the following valid code:
=== cut here ===
struct Base {
virtual void doit (int v) const {}
};
struct Derived : Base {
void doit (int v) const {}
};
using fn_t = void (Base::*)(int) const;
struct Helper {
fn_t mFn;
constexpr Helper (auto && fn) : mFn(static_cast
Hi Jason,
On 3 Dec 2024, at 22:37, Jason Merrill wrote:
> On 12/3/24 12:25 PM, Simon Martin wrote:
>> We currently reject the following valid code:
>>
>> === cut here ===
>> struct Base {
>> virtual void doit (int v) const {}
>> };
>> struct Der
Hi,
I’d like to ping the following C++ patches:
PR c++/109918: Unexpected -Woverloaded-virtual with virtual conversion
operators
=> https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665650.html
PR c++/114619:ICE with -fno-elide-constructors in C++14 mode for
non-constant initializer in
Hi Richard,
On 8 Dec 2024, at 10:27, Richard Biener wrote:
> On Sat, Dec 7, 2024 at 9:29 PM Simon Martin
> wrote:
>>
>> The following valid code triggers an ICE with -fsanitize=address
>>
>> === cut here ===
>> void l() {
>> auto const ints
On 8 Dec 2024, at 11:10, Simon Martin wrote:
> Hi Richard,
>
> On 8 Dec 2024, at 10:27, Richard Biener wrote:
>
>> On Sat, Dec 7, 2024 at 9:29 PM Simon Martin
>> wrote:
>>>
>>> The following valid code triggers an ICE with -fsanitize=address
>>&g
The following valid code triggers an ICE with -fsanitize=address
=== cut here ===
void l() {
auto const ints = {0,1,2,3,4,5};
for (auto i : { 3 } ) {
__builtin_printf("%d ", i);
}
}
=== cut here ===
The problem is that honor_protect_cleanup_actions does not expect the
cleanup
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 NoMut3 : NoMut1 {
constexpr NoMut3(int a, int b) {}
};
void mutable_subobjects() {
constexpr NoMut
Hi,
On 11 Nov 2024, at 20:35, Simon Martin wrote:
> Hi,
>
> On 30 Oct 2024, at 11:46, Simon Martin wrote:
>
>> On 19 Oct 2024, at 11:09, Simon Martin wrote:
>>
>>> We currently ICE in checking mode with cxx_dialect < 17 on the
>>> following
>>
Hi,
On 11 Nov 2024, at 20:36, Simon Martin wrote:
> Hi,
>
> On 30 Oct 2024, at 11:44, Simon Martin wrote:
>
>> Friendly ping.
> Friendly ping.
Ping. Thanks!
Simon
>>
>> On 16 Oct 2024, at 17:43, Simon Martin wrote:
>>
>>> Hi Jason,
>
Hi,
On 13 Dec 2024, at 13:50, Simon Martin wrote:
> Hi Marek,
>
> On 13 Dec 2024, at 0:44, Marek Polacek wrote:
>
>> On Thu, Dec 12, 2024 at 07:07:38PM +, Simon Martin wrote:
>>> We currently ICE upon the following valid (under -Wno-vla) code
>>>
&
Hi,
On 11 Dec 2024, at 22:27, Simon Martin wrote:
> 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() {
>>
Noticed while trying to understand when I can expect the GCC 15 branch
to be created: the GCC 15 release criteria page still mentions GCC 14.
I'll push this as obvious.
Are such pages created via a script? If so I am happy to fix it as well.
---
htdocs/gcc-15/criteria.html | 8
1 file c
Hi Jason,
On 16 Jan 2025, at 23:28, Jason Merrill wrote:
> On 10/19/24 5:09 AM, Simon Martin wrote:
>> We currently ICE in checking mode with cxx_dialect < 17 on the
>> following
>> valid code
>>
>> === cut here ===
>> struct X {
>>
Hi Jason,
On 4 Feb 2025, at 16:39, Jason Merrill wrote:
> On 1/15/25 9:56 AM, Jason Merrill wrote:
>> On 1/15/25 7:24 AM, Simon Martin wrote:
>>> Hi,
>>>
>>> On 14 Jan 2025, at 23:31, Jason Merrill wrote:
>>>
>>>> On 1/14/25 2:13 PM, S
Hi Jason,
On 4 Feb 2025, at 1:11, Jason Merrill wrote:
> On 1/31/25 11:12 AM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 31 Jan 2025, at 16:29, Jason Merrill wrote:
>>
>>> On 1/31/25 9:52 AM, Simon Martin wrote:
>>>> Hi Jason,
>>>>
>
On 4 Feb 2025, at 17:17, Jason Merrill wrote:
> On 2/4/25 10:56 AM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 4 Feb 2025, at 16:39, Jason Merrill wrote:
>>
>>> On 1/15/25 9:56 AM, Jason Merrill wrote:
>>>> On 1/15/25 7:24 AM, Simon Martin wrote
Hi Jason,
On 27 Jan 2025, at 16:49, Jason Merrill wrote:
> On 1/27/25 10:41 AM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 17 Jan 2025, at 23:33, Jason Merrill wrote:
>>
>>> On 1/17/25 9:52 AM, Simon Martin wrote:
>>>> Hi Jason,
>>
Hi Jason,
On 31 Jan 2025, at 16:29, Jason Merrill wrote:
> On 1/31/25 9:52 AM, Simon Martin wrote:
>> 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 t
Hi Jason,
On 4 Feb 2025, at 1:10, Jason Merrill wrote:
> On 1/31/25 12:11 PM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 27 Jan 2025, at 16:49, Jason Merrill wrote:
>>
>>> On 1/27/25 10:41 AM, Simon Martin wrote:
>>>> Hi Jason,
>>
Hi Jason,
On 7 Feb 2025, at 14:21, Jason Merrill wrote:
> On 2/6/25 3:05 PM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 6 Feb 2025, at 16:48, Jason Merrill wrote:
>>
>>> On 2/5/25 2:21 PM, Simon Martin wrote:
>>>> Hi Jason,
>>>>
>>
1 - 100 of 179 matches
Mail list logo
