On March 27, 2020 4:32:58 PM GMT+01:00, Jakub Jelinek <ja...@redhat.com> wrote:
>On Fri, Mar 27, 2020 at 10:57:05AM +0100, Richard Biener wrote:
>> > That would just mean it ICEs at -g0 too, this PR isn't a
>-fcompare-debug
>> > issue but a bug where we try to gimplify the same STATEMENT_LIST
>multiple
>> > times and second time ICE on it as it has been voidified and
>emptied.
>> 
>> But only because we made STATEMENT_LISTs not having side-effects
>which
>> they all did before all the changes.  We could revert that...
>
>So perhaps we could try to do that only for the C/C++ statement
>expressions
>which seems to be the most common reason of all these -fcompare-debug
>-gstatement-frontiers related PRs, while it wouldn't consume too much
>memory
>in the common case?
>I.e. when parsing a statement expression in the C/C++ FEs, ensure the
>result
>is wrapped in a STATEMENT_LIST with TREE_SIDE_EFFECTS set, no matter if
>it
>contains just a single stmt or more inside of it?

Sounds worth a try. 

Richard. 

>       Jakub

Reply via email to