[Bug c++/84964] [8/9/10/11 Regression] ICE in expand_call, at calls.c:4540

[Bug c++/84964] [8/9/10/11 Regression] ICE in expand_call, at calls.c:4540

[rsandifo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84964

rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|rsandifo at gcc dot gnu.org        |unassigned at gcc dot gnu.org
             Status|ASSIGNED                    |NEW

[Bug c++/84964] [9/10/11/12 Regression] ICE in expand_call, at calls.c:4540

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84964

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|8.5                         |9.4

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 8 branch is being closed.

[Bug c++/84964] [9/10/11/12 Regression] ICE in expand_call, at calls.c:4540

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84964

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.4                         |9.5

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9.4 is being released, retargeting bugs to GCC 9.5.

[Bug c++/84964] [9/10/11/12 Regression] ICE in expand_call, at calls.c:4540

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84964

--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
A little history here:

4.1.2 accepted the code without an ICE.

4.4-4.7 had an ICE:
<source>:2:8: internal compiler error: in tree_low_cst, at tree.h:4435

4.8 accepted the code without an ICE.

4.9-7 had the sorry:
<source>:5:16: sorry, unimplemented: passing too large argument on stack

8+ had the ICE after the sorry:
<source>:5:16: internal compiler error: in expand_call, at calls.c:3919

[Bug c++/84964] [9/10/11/12 Regression] ICE in expand_call, at calls.c:4540

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84964

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=56344

--- Comment #13 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The sorry was added by r0-126979 (aka PR 56344).

[Bug c++/84964] [9/10/11/12 Regression] ICE in expand_call, at calls.c:4540

[roger at nextmovesoftware dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84964

Roger Sayle <roger at nextmovesoftware dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |roger at nextmovesoftware dot com
                 CC|                            |roger at nextmovesoftware dot com

--- Comment #14 from Roger Sayle <roger at nextmovesoftware dot com> ---
Patch proposed.
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590961.html

[Bug c++/84964] [9/10/11/12 Regression] ICE in expand_call, at calls.c:4540

[roger at nextmovesoftware dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84964

Roger Sayle <roger at nextmovesoftware dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cnsun at uwaterloo dot ca

--- Comment #15 from Roger Sayle <roger at nextmovesoftware dot com> ---
*** Bug 100536 has been marked as a duplicate of this bug. ***

[Bug c++/84964] [9/10/11/12 Regression] ICE in expand_call, at calls.c:4540

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84964

--- Comment #16 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Roger Sayle <sayle@gcc.gnu.org>:

https://gcc.gnu.org/g:a717376e99fb33ba3b06bd8122e884f4b63a60c9

commit r12-7607-ga717376e99fb33ba3b06bd8122e884f4b63a60c9
Author: Roger Sayle <roger@nextmovesoftware.com>
Date:   Thu Mar 10 23:49:15 2022 +0000

    PR c++/84964: Middle-end patch to expand_call for ICE after sorry.

    This patch resolves PR c++/84969 which is an ICE in the middle-end after
    emitting a "sorry, unimplemented" message, and is a regression from
    earlier releases of GCC.  This issue is that after encountering a
    function call requiring an unreasonable amount of stack space, the
    code continues and falls foul of an assert checking that stack pointer
    has been correctly updated.  The fix is to (locally) consider aborted
    function calls as "no return", which skips this downstream sanity check.

    2022-03-10  Roger Sayle  <roger@nextmovesoftware.com>

    gcc/ChangeLog
            PR c++/84964
            * calls.cc (expand_call): Ignore stack adjustments after sorry.

    gcc/testsuite/ChangeLog
            PR c++/84964
            * g++.dg/other/pr84964.C: New test case.

[Bug c++/84964] [9/10/11/12 Regression] ICE in expand_call, at calls.c:4540

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84964

--- Comment #17 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Roger Sayle <sayle@gcc.gnu.org>:

https://gcc.gnu.org/g:098c538ae8c0c5e281d9191a6b54ffe38b624ef3

commit r12-7614-g098c538ae8c0c5e281d9191a6b54ffe38b624ef3
Author: Roger Sayle <roger@nextmovesoftware.com>
Date:   Fri Mar 11 17:35:21 2022 +0000

    [Committed] Update g++.dg/other/pr84964.C for ia32 (and similar) targets.

    The "sorry, unimplemented" message in the new g++.dg/other/pr84964.C is
    apparently dependent upon whether the target passes multi-gigabyte
    arguments on the stack.  This tweaks the testcase to just confirm that
    it no longer ICEs, not the specific set of warnings/errors triggered.

    2022-03-11  Roger Sayle  <roger@nextmovesoftware.com>

    gcc/testsuite/ChangeLog
            PR c++/84964
            * g++.dg/other/pr84964.C: Tweak test to check for the ICE, not for
            the (target-dependent) sorry.

[Bug c++/84964] [9/10/11/12 Regression] ICE in expand_call, at calls.c:4540

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84964

--- Comment #18 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:6adbb51eaa85f5bfed1ee06327daca306d48986d

commit r12-7749-g6adbb51eaa85f5bfed1ee06327daca306d48986d
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Mar 22 08:39:40 2022 +0100

    calls: Fix error recovery after sorry differently [PR104989]

    On Mon, Feb 28, 2022 at 07:52:56AM -0000, Roger Sayle wrote:
    > This patch resolves PR c++/84964 which is an ICE in the middle-end after
    > emitting a "sorry, unimplemented" message, and is a regression from
    > earlier releases of GCC.  This issue is that after encountering a
    > function call requiring an unreasonable amount of stack space, the
    > code continues and falls foul of an assert checking that stack pointer
    > has been correctly updated.  The fix is to (locally) consider aborted
    > function calls as "no return", which skips this downstream sanity check.

    As can be seen on PR104989, just setting ECF_NORETURN after sorry is quite
    risky and leads to other ICEs.  The problem is that ECF_NORETURN calls
    better should be at the end of basic blocks that don't have any fallthru
    successor edges, otherwise we can ICE later.

    This patch instead sets sibcall_failure if in pass == 0 (sibcall_failure
    means that the tail call sequence is not useful/not desirable and throws
    it away) and otherwise sets a new bool variable that will let us pass
    the assertion and also throws away the whole call sequence, I think that is
    best for error recovery.

    2022-03-22  Jakub Jelinek  <jakub@redhat.com>

            PR rtl-optimization/104989
            * calls.cc (expand_call): Don't set ECF_NORETURN in flags after
            sorry for passing too large argument, instead set sibcall_failure
            for pass == 0, or a new normal_failure flag otherwise.  If
            normal_failure is set, don't assert all stack has been deallocated
            at the end and throw away the whole insn sequence.

            * g++.dg/other/pr104989.C: New test.

[Bug c++/84964] [9/10/11/12 Regression] ICE in expand_call, at calls.c:4540

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84964

Segher Boessenkool <segher at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |segher at gcc dot gnu.org

--- Comment #19 from Segher Boessenkool <segher at gcc dot gnu.org> ---
This now ICEs with a segfault on powerpc64-linux.

[Bug c++/84964] [9/10/11/12 Regression] ICE in expand_call, at calls.c:4540

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84964

--- Comment #20 from Segher Boessenkool <segher at gcc dot gnu.org> ---
FAIL: g++.dg/other/pr84964.C  -std=c++14 (internal compiler error: Aborted
signal terminated program cc1plus)

[Bug c++/84964] [9/10/11/12 Regression] ICE in expand_call, at calls.c:4540

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84964

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
It did so even before my or Roger's patch.
As I wrote in PR105023, the problem is that the rs6000 backend decides to pass
that huge (2 Exabytes long) argument partially in registers (reg:BLK 3 3) and
partially on the stack, while on most other backends it is passed just on the
stack and we sorry at that point instead of trying to overwrite compiler's
memory.  (reg:BLK 3 3) looks just way too suspect to me, do we pass say 256
byte long homogenous structures that way too?

[Bug c++/84964] [9/10/11/12 Regression] ICE in expand_call, at calls.c:4540

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84964

--- Comment #22 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #21)
> It did so even before my or Roger's patch.

It was my first successful bootstrap in a few days, and I replied to this old
PR
without looking everywhere else first.

> As I wrote in PR105023, the problem is that the rs6000 backend decides to
> pass that huge (2 Exabytes long) argument partially in registers (reg:BLK 3
> 3) and partially on the stack,

It isn't the backend that decides to do that.  The backend correctly does what
the ABI requires here: pass up to eight things in GPRs, and the rest in the
parameter save area (on the stack) (this is ignoring FPRs and the like, for
simplicity).

> while on most other backends it is passed
> just on the stack and we sorry at that point instead of trying to overwrite
> compiler's memory.  (reg:BLK 3 3) looks just way too suspect to me, do we
> pass say 256 byte long homogenous structures that way too?

reg:BLK is invalid always, :BLK is valid on memory only.

[Bug c++/84964] [9/10/11/12 Regression] ICE in expand_call, at calls.c:4540

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84964

--- Comment #23 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Roger Sayle <sayle@gcc.gnu.org>:

https://gcc.gnu.org/g:41d1f11f5f693a2a06c65c9467a28dfeb02aed85

commit r12-7833-g41d1f11f5f693a2a06c65c9467a28dfeb02aed85
Author: Roger Sayle <roger@nextmovesoftware.com>
Date:   Sat Mar 26 08:10:27 2022 -1000

    PR middle-end/104885: Fix ICE with large stack frame on powerpc64.

    My recent testcase for PR c++/84964.C stress tests the middle-end by
    attempting to pass a UINT_MAX sized structure on the stack.  Although
    my fix to PR84964 avoids the ICE after sorry on x86_64 and similar
    targets, a related issue still exists on powerpc64 (and similar
    ACCUMULATE_OUTGOING_ARGS/ARGS_GROW_DOWNWARD targets) which don't
    issue a "sorry, unimplemented" message, but instead ICE elsewhere.

    After attempting several alternate fixes, the simplest solution is
    to just defensively check in mark_stack_region_used that the upper
    bound of the region lies within the allocated stack_usage_map
    array, which is of size highest_outgoing_arg_in_use.  When this isn't
    the case, the code now follows the same path as for variable sized
    regions, and uses stack_usage_watermark rather than a map.

    2022-03-26  Roger Sayle  <roger@nextmovesoftware.com>

    gcc/ChangeLog
            PR middle-end/104885
            * calls.cc (mark_stack_region_used): Check that the region
            is within the allocated size of stack_usage_map.

[Bug c++/84964] [9/10/11/12 Regression] ICE in expand_call, at calls.c:4540

[roger at nextmovesoftware dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84964

Roger Sayle <roger at nextmovesoftware dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #24 from Roger Sayle <roger at nextmovesoftware dot com> ---
This should now be fixed on mainline.