This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ PATCH] Fix constexpr ICE with statement frontiers (PR c++/83734)
- From: Jason Merrill <jason at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Nathan Sidwell <nathan at acm dot org>, Alexandre Oliva <aoliva at redhat dot com>, gcc-patches List <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 9 Jan 2018 14:45:30 -0500
- Subject: Re: [C++ PATCH] Fix constexpr ICE with statement frontiers (PR c++/83734)
- Authentication-results: sourceware.org; auth=none
- References: <20180108235550.GX1833@tucnak> <CADzB+2kRSHBWcHBNN5f5-ehitCu+YxSump-i-AeHs4mM9628Fw@mail.gmail.com> <20180109154110.GC1833@tucnak>
On Tue, Jan 9, 2018 at 10:41 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Tue, Jan 09, 2018 at 10:30:31AM -0500, Jason Merrill wrote:
>> On Mon, Jan 8, 2018 at 6:55 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>> > The assert there assumes we never evaluate a statement list to
>> > DEBUG_BEGIN_STMT, but it breaks appart when a BIND_EXPR with a typedef in it
>> > has some DEBUG_BEGIN_STMTs in it and nothing else (without -g it is just
>> > empty STATEMENT_LIST inside of the BIND_EXPR). We want to return void_node
>> > in that case.
>> >
>> > THere is nothing interesting about DEBUG_BEGIN_STMT for constexpr
>> > evaluation, it doesn't change any values, so let's just ignore them
>> > and the assert is then unnecessary.
>>
>> What if we return void_node for a DEBUG_BEGIN_STMT from
>> cxx_eval_constant_expression?
>
> That would handle differently the case when some non-DEBUG_BEGIN_STMT
> is followed by one or more DEBUG_BEGIN_STMTs. In that case, with -g0
> it would return the last stmt in the list, while with -g it would return
> void_node. I don't have a testcase for that right now, but given e.g.
> earlier reports from Alex that DEBUG_BEGIN_STMTs appear virtually
> everywhere, I can't prove it can't happen.
OK then.
Jason