* [C++ Patch] PR 85070 ("[8/9 Regression] ICE on C++ code: in lazily_declare_fn, at cp/method.c:2409")
@ 2018-09-24 10:58 Paolo Carlini
2018-09-24 15:42 ` Nathan Sidwell
2018-10-11 18:18 ` Jakub Jelinek
0 siblings, 2 replies; 5+ messages in thread
From: Paolo Carlini @ 2018-09-24 10:58 UTC (permalink / raw)
To: gcc-patches; +Cc: Nathan Sidwell, Jason Merrill
[-- Attachment #1: Type: text/plain, Size: 308 bytes --]
Hi,
as explained in the audit trail, the gcc_assert added by Nathan triggers
during error-recovery too, when add_method correctly returns false
because it failed to add the method. Thus it seems that we should simply
loosen a bit the assertion. Tested x86_64-linux.
Thanks, Paolo.
///////////////////
[-- Attachment #2: CL_85070 --]
[-- Type: text/plain, Size: 271 bytes --]
/cp
2018-09-24 Paolo Carlini <paolo.carlini@oracle.com>
PR c++/85070
* method.c (lazily_declare_fn): During error-recovery add_method
may return false.
/testsuite
2018-09-24 Paolo Carlini <paolo.carlini@oracle.com>
PR c++/85070
* g++.dg/cpp0x/pr85070.C: New.
[-- Attachment #3: patch_85070 --]
[-- Type: text/plain, Size: 940 bytes --]
Index: cp/method.c
===================================================================
--- cp/method.c (revision 264524)
+++ cp/method.c (working copy)
@@ -2421,7 +2421,7 @@ lazily_declare_fn (special_function_kind sfk, tree
/* Add it to the class */
bool added = add_method (type, fn, false);
- gcc_assert (added);
+ gcc_assert (added || errorcount);
/* Add it to TYPE_FIELDS. */
if (sfk == sfk_destructor
Index: testsuite/g++.dg/cpp0x/pr85070.C
===================================================================
--- testsuite/g++.dg/cpp0x/pr85070.C (nonexistent)
+++ testsuite/g++.dg/cpp0x/pr85070.C (working copy)
@@ -0,0 +1,13 @@
+// { dg-do compile { target c++11 } }
+
+struct A;
+
+struct B
+{
+ constexpr A & operator= (const A &); // { dg-warning "used" "" { target c++14_only } }
+};
+
+struct A : B // { dg-error "cannot be overloaded" "" { target c++14_only } }
+{
+ using B::operator=;
+} a { a = a };
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [C++ Patch] PR 85070 ("[8/9 Regression] ICE on C++ code: in lazily_declare_fn, at cp/method.c:2409")
2018-09-24 10:58 [C++ Patch] PR 85070 ("[8/9 Regression] ICE on C++ code: in lazily_declare_fn, at cp/method.c:2409") Paolo Carlini
@ 2018-09-24 15:42 ` Nathan Sidwell
2018-10-11 18:18 ` Jakub Jelinek
1 sibling, 0 replies; 5+ messages in thread
From: Nathan Sidwell @ 2018-09-24 15:42 UTC (permalink / raw)
To: Paolo Carlini, gcc-patches; +Cc: Jason Merrill
On 9/24/18 3:48 AM, Paolo Carlini wrote:
> Hi,
>
> as explained in the audit trail, the gcc_assert added by Nathan triggers
> during error-recovery too, when add_method correctly returns false
> because it failed to add the method. Thus it seems that we should simply
> loosen a bit the assertion. Tested x86_64-linux.
ok
--
Nathan Sidwell
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [C++ Patch] PR 85070 ("[8/9 Regression] ICE on C++ code: in lazily_declare_fn, at cp/method.c:2409")
2018-09-24 10:58 [C++ Patch] PR 85070 ("[8/9 Regression] ICE on C++ code: in lazily_declare_fn, at cp/method.c:2409") Paolo Carlini
2018-09-24 15:42 ` Nathan Sidwell
@ 2018-10-11 18:18 ` Jakub Jelinek
2018-10-11 18:32 ` Paolo Carlini
2018-10-11 18:37 ` Jason Merrill
1 sibling, 2 replies; 5+ messages in thread
From: Jakub Jelinek @ 2018-10-11 18:18 UTC (permalink / raw)
To: Paolo Carlini; +Cc: gcc-patches, Nathan Sidwell, Jason Merrill
On Mon, Sep 24, 2018 at 12:48:56PM +0200, Paolo Carlini wrote:
> as explained in the audit trail, the gcc_assert added by Nathan triggers
> during error-recovery too, when add_method correctly returns false because
> it failed to add the method. Thus it seems that we should simply loosen a
> bit the assertion. Tested x86_64-linux.
Testcase fails with check-c++-all:
FAIL: g++.dg/cpp0x/pr85070.C -std=c++17 (test for excess errors)
FAIL: g++.dg/cpp0x/pr85070.C -std=c++2a (test for excess errors)
FAIL: g++.dg/cpp0x/pr85070.C -std=c++17 -fconcepts (test for excess errors)
Any reason why you've used c++14_only effective target, rather than c++14?
If I use the latter, i.e. expect c++17/2a/17 + concepts to behave like c++14
in this case, there are no failures.
Tested with make check-c++-all RUNTESTFLAGS=dg.exp=pr85070.C, ok for trunk?
2018-10-11 Jakub Jelinek <jakub@redhat.com>
PR c++/85070
* g++.dg/cpp0x/pr85070.C: Change effective target for diagnostics from
c++14_only to c++14.
--- gcc/testsuite/g++.dg/cpp0x/pr85070.C.jj 2018-09-25 15:14:43.205270858 +0200
+++ gcc/testsuite/g++.dg/cpp0x/pr85070.C 2018-10-11 19:55:17.795180058 +0200
@@ -4,10 +4,10 @@ struct A;
struct B
{
- constexpr A & operator= (const A &); // { dg-warning "used" "" { target c++14_only } }
+ constexpr A & operator= (const A &); // { dg-warning "used" "" { target c++14 } }
};
-struct A : B // { dg-error "cannot be overloaded" "" { target c++14_only } }
+struct A : B // { dg-error "cannot be overloaded" "" { target c++14 } }
{
using B::operator=;
} a { a = a };
Jakub
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [C++ Patch] PR 85070 ("[8/9 Regression] ICE on C++ code: in lazily_declare_fn, at cp/method.c:2409")
2018-10-11 18:18 ` Jakub Jelinek
@ 2018-10-11 18:32 ` Paolo Carlini
2018-10-11 18:37 ` Jason Merrill
1 sibling, 0 replies; 5+ messages in thread
From: Paolo Carlini @ 2018-10-11 18:32 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: gcc-patches, Nathan Sidwell, Jason Merrill
Hi,
On 11/10/18 19:59, Jakub Jelinek wrote:
> On Mon, Sep 24, 2018 at 12:48:56PM +0200, Paolo Carlini wrote:
>> as explained in the audit trail, the gcc_assert added by Nathan triggers
>> during error-recovery too, when add_method correctly returns false because
>> it failed to add the method. Thus it seems that we should simply loosen a
>> bit the assertion. Tested x86_64-linux.
> Testcase fails with check-c++-all:
> FAIL: g++.dg/cpp0x/pr85070.C -std=c++17 (test for excess errors)
> FAIL: g++.dg/cpp0x/pr85070.C -std=c++2a (test for excess errors)
> FAIL: g++.dg/cpp0x/pr85070.C -std=c++17 -fconcepts (test for excess errors)
Ah, sorry, it's because I tested with check-c++.
> Any reason why you've used c++14_only effective target, rather than c++14?
> If I use the latter, i.e. expect c++17/2a/17 + concepts to behave like c++14
> in this case, there are no failures.
Not that I can remember now... I was working on some other issues too...
Paolo.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [C++ Patch] PR 85070 ("[8/9 Regression] ICE on C++ code: in lazily_declare_fn, at cp/method.c:2409")
2018-10-11 18:18 ` Jakub Jelinek
2018-10-11 18:32 ` Paolo Carlini
@ 2018-10-11 18:37 ` Jason Merrill
1 sibling, 0 replies; 5+ messages in thread
From: Jason Merrill @ 2018-10-11 18:37 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: Paolo Carlini, gcc-patches List, Nathan Sidwell
OK.
On Thu, Oct 11, 2018 at 1:59 PM Jakub Jelinek <jakub@redhat.com> wrote:
>
> On Mon, Sep 24, 2018 at 12:48:56PM +0200, Paolo Carlini wrote:
> > as explained in the audit trail, the gcc_assert added by Nathan triggers
> > during error-recovery too, when add_method correctly returns false because
> > it failed to add the method. Thus it seems that we should simply loosen a
> > bit the assertion. Tested x86_64-linux.
>
> Testcase fails with check-c++-all:
> FAIL: g++.dg/cpp0x/pr85070.C -std=c++17 (test for excess errors)
> FAIL: g++.dg/cpp0x/pr85070.C -std=c++2a (test for excess errors)
> FAIL: g++.dg/cpp0x/pr85070.C -std=c++17 -fconcepts (test for excess errors)
>
> Any reason why you've used c++14_only effective target, rather than c++14?
> If I use the latter, i.e. expect c++17/2a/17 + concepts to behave like c++14
> in this case, there are no failures.
>
> Tested with make check-c++-all RUNTESTFLAGS=dg.exp=pr85070.C, ok for trunk?
>
> 2018-10-11 Jakub Jelinek <jakub@redhat.com>
>
> PR c++/85070
> * g++.dg/cpp0x/pr85070.C: Change effective target for diagnostics from
> c++14_only to c++14.
>
> --- gcc/testsuite/g++.dg/cpp0x/pr85070.C.jj 2018-09-25 15:14:43.205270858 +0200
> +++ gcc/testsuite/g++.dg/cpp0x/pr85070.C 2018-10-11 19:55:17.795180058 +0200
> @@ -4,10 +4,10 @@ struct A;
>
> struct B
> {
> - constexpr A & operator= (const A &); // { dg-warning "used" "" { target c++14_only } }
> + constexpr A & operator= (const A &); // { dg-warning "used" "" { target c++14 } }
> };
>
> -struct A : B // { dg-error "cannot be overloaded" "" { target c++14_only } }
> +struct A : B // { dg-error "cannot be overloaded" "" { target c++14 } }
> {
> using B::operator=;
> } a { a = a };
>
>
> Jakub
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-10-11 18:33 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-09-24 10:58 [C++ Patch] PR 85070 ("[8/9 Regression] ICE on C++ code: in lazily_declare_fn, at cp/method.c:2409") Paolo Carlini
2018-09-24 15:42 ` Nathan Sidwell
2018-10-11 18:18 ` Jakub Jelinek
2018-10-11 18:32 ` Paolo Carlini
2018-10-11 18:37 ` Jason Merrill
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).