[Bug lto/65515] New: [5 Regression] FAIL: gcc.c-torture/compile/limits-fndefn.c -O2 -flto -flto-partition=none (ICE) -- SIGSEGV for stack growth failure

[Bug lto/65515] New: [5 Regression] FAIL: gcc.c-torture/compile/limits-fndefn.c -O2 -flto -flto-partition=none (ICE) -- SIGSEGV for stack growth failure

[danglin at gcc dot gnu.org]

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

            Bug ID: 65515
           Summary: [5 Regression] FAIL:
                    gcc.c-torture/compile/limits-fndefn.c   -O2 -flto
                    -flto-partition=none  (ICE) -- SIGSEGV for stack
                    growth failure
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: danglin at gcc dot gnu.org
              Host: hppa2.0w-hp-hpux11.11
            Target: hppa2.0w-hp-hpux11.11
             Build: hppa2.0w-hp-hpux11.11

spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
-fno-diagnostics
-show-caret -fdiagnostics-color=never -O2 -flto -flto-partition=none -w -c -o
li
mits-fndefn.o
/test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/limits-fndef
n.c
^MPid 26539 received a SIGSEGV for stack growth failure.^MPossible causes:
insufficient memory or swap space,^Mor stack size exceeded maxssiz. ^M
xgcc: internal compiler error: Segmentation fault (program cc1)Please submit a
full bug report,with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
compiler exited with status 1
output is:
^M
Pid 26539 received a SIGSEGV for stack growth failure.^M
Possible causes: insufficient memory or swap space,^M
or stack size exceeded maxssiz. ^M
xgcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

FAIL: gcc.c-torture/compile/limits-fndefn.c   -O2 -flto -flto-partition=none 
(internal compiler error)
FAIL: gcc.c-torture/compile/limits-fndefn.c   -O2 -flto -flto-partition=none 
(test for excess errors)
Excess errors:
Pid 26539 received a SIGSEGV for stack growth failure.
Possible causes: insufficient memory or swap space,
or stack size exceeded maxssiz. 
xgcc: internal compiler error: Segmentation fault (program cc1)

Similar fails:
FAIL: gcc.c-torture/compile/limits-fndefn.c   -O2 -flto  (internal compiler
error)
FAIL: gcc.c-torture/compile/limits-fndefn.c   -O2 -flto  (test for excess
errors)

This is with 16 MB stack:
# ulimit -s   
16384

On hppa-linux, I've had to use a 32 MB stack to keep some tests from failing.

I marked this as a regression since r221487 and before didn't fail.

[Bug lto/65515] [5 Regression] FAIL: gcc.c-torture/compile/limits-fndefn.c -O2 -flto -flto-partition=none (ICE) -- SIGSEGV for stack growth failure

[danglin at gcc dot gnu.org]

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

John David Anglin <danglin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|hppa2.0w-hp-hpux11.11       |hppa64-hp-hpux11.11
               Host|hppa2.0w-hp-hpux11.11       |hppa64-hp-hpux11.11
              Build|hppa2.0w-hp-hpux11.11       |hppa64-hp-hpux11.11

--- Comment #1 from John David Anglin <danglin at gcc dot gnu.org> ---
Wrong target and point of introduction.  R212961 was okay and r213683 had
the fail.

[Bug lto/65515] [5 Regression] FAIL: gcc.c-torture/compile/limits-fndefn.c -O2 -flto -flto-partition=none (ICE) -- SIGSEGV for stack growth failure

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

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

--- Comment #2 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
It would help to know the backtrace when stack usage gets out of hand.

[Bug lto/65515] [5 Regression] FAIL: gcc.c-torture/compile/limits-fndefn.c -O2 -flto -flto-partition=none (ICE) -- SIGSEGV for stack growth failure

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |5.0

[Bug lto/65515] [5 Regression] FAIL: gcc.c-torture/compile/limits-fndefn.c -O2 -flto -flto-partition=none (ICE) -- SIGSEGV for stack growth failure

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|hppa64-hp-hpux11.11         |
                 CC|                            |jakub at gcc dot gnu.org
               Host|hppa64-hp-hpux11.11         |
              Build|hppa64-hp-hpux11.11         |

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Doesn't seem to be specific to hppa, on x86_64-linux I can reproduce it as
well, and need ulimit -s 46000 to pass.
The Fedora default of ulimit -sH unlimited and ulimit -sS 8192 works, because
gcc automatically attempts to raise stack limit to 64MB if possible.

Backtrace during crash is:
#0  0x0000000000bacbd0 in DFS::DFS_write_tree (this=<error reading variable:
Cannot access memory at address 0x7ffffd40cfc8>, ob=<error reading variable:
Cannot access memory at address 0x7ffffd40cfc0>, 
    from_state=<error reading variable: Cannot access memory at address
0x7ffffd40cfb8>, expr=<error reading variable: Cannot access memory at address
0x7ffffd40cfb0>, 
    ref_p=<error reading variable: Cannot access memory at address
0x7ffffd40cfac>, this_ref_p=<error reading variable: Cannot access memory at
address 0x7ffffd40cfa8>, 
    single_p=<error reading variable: Cannot access memory at address
0x7ffffd40cfa4>) at ../../gcc/lto-streamer-out.c:1343
#1  0x0000000000ba499f in DFS::DFS_write_tree_body (this=0x7fffffffdca0,
ob=0x3e4d9b0, expr=0x7fffef9d57f8, expr_state=0x2522dc0, ref_p=false,
single_p=false) at ../../gcc/lto-streamer-out.c:539
#2  0x0000000000bacf50 in DFS::DFS_write_tree (this=0x7fffffffdca0,
ob=0x3e4d9b0, from_state=0x2522db0, expr=0x7fffef9d57f8, ref_p=false,
this_ref_p=false, single_p=false) at ../../gcc/lto-streamer-out.c:1376
#3  0x0000000000ba5dae in DFS::DFS_write_tree_body (this=0x7fffffffdca0,
ob=0x3e4d9b0, expr=0x7fffef9d5820, expr_state=0x2522db0, ref_p=false,
single_p=false) at ../../gcc/lto-streamer-out.c:659
#4  0x0000000000bacf50 in DFS::DFS_write_tree (this=0x7fffffffdca0,
ob=0x3e4d9b0, from_state=0x2522da0, expr=0x7fffef9d5820, ref_p=false,
this_ref_p=false, single_p=false) at ../../gcc/lto-streamer-out.c:1376
...
#198591 0x0000000000ba5dae in DFS::DFS_write_tree_body (this=0x7fffffffdca0,
ob=0x3e4d9b0, expr=0x7fffef5a2fa0, expr_state=0x3d3f1d0, ref_p=false,
single_p=false) at ../../gcc/lto-streamer-out.c:659
#198592 0x0000000000bacf50 in DFS::DFS_write_tree (this=0x7fffffffdca0,
ob=0x3e4d9b0, from_state=0x3d3f1c0, expr=0x7fffef5a2fa0, ref_p=false,
this_ref_p=false, single_p=false) at ../../gcc/lto-streamer-out.c:1376
#198593 0x0000000000ba5dae in DFS::DFS_write_tree_body (this=0x7fffffffdca0,
ob=0x3e4d9b0, expr=0x7fffef5a2fc8, expr_state=0x3d3f1c0, ref_p=false,
single_p=false) at ../../gcc/lto-streamer-out.c:659
#198594 0x0000000000bacf50 in DFS::DFS_write_tree (this=0x7fffffffdca0,
ob=0x3e4d9b0, from_state=0x3d3f1b0, expr=0x7fffef5a2fc8, ref_p=false,
this_ref_p=false, single_p=false) at ../../gcc/lto-streamer-out.c:1376
#198595 0x0000000000ba5acb in DFS::DFS_write_tree_body (this=0x7fffffffdca0,
ob=0x3e4d9b0, expr=0x7ffff1975d20, expr_state=0x3d3f1b0, ref_p=false,
single_p=false) at ../../gcc/lto-streamer-out.c:646
#198596 0x0000000000bacf50 in DFS::DFS_write_tree (this=0x7fffffffdca0,
ob=0x3e4d9b0, from_state=0x3d3f1a0, expr=0x7ffff1975d20, ref_p=false,
this_ref_p=false, single_p=false) at ../../gcc/lto-streamer-out.c:1376
#198597 0x0000000000ba499f in DFS::DFS_write_tree_body (this=0x7fffffffdca0,
ob=0x3e4d9b0, expr=0x7ffff19791b0, expr_state=0x3d3f1a0, ref_p=false,
single_p=false) at ../../gcc/lto-streamer-out.c:539
#198598 0x0000000000bacf50 in DFS::DFS_write_tree (this=0x7fffffffdca0,
ob=0x3e4d9b0, from_state=0x0, expr=0x7ffff19791b0, ref_p=false,
this_ref_p=false, single_p=false) at ../../gcc/lto-streamer-out.c:1376
#198599 0x0000000000ba483e in DFS::DFS (this=0x7fffffffdca0, ob=0x3e4d9b0,
expr=0x7ffff19791b0, ref_p=false, this_ref_p=false, single_p=false) at
../../gcc/lto-streamer-out.c:512
#198600 0x0000000000bad6fc in lto_output_tree (ob=0x3e4d9b0,
expr=0x7ffff19791b0, ref_p=false, this_ref_p=false) at
../../gcc/lto-streamer-out.c:1571
#198601 0x0000000000bafa3d in write_global_stream (ob=0x3e4d9b0,
encoder=0x3e4d6f0) at ../../gcc/lto-streamer-out.c:2359
#198602 0x0000000000bafb70 in lto_output_decl_state_streams (ob=0x3e4d9b0,
state=0x3e4d6d0) at ../../gcc/lto-streamer-out.c:2406
#198603 0x0000000000bb0af1 in produce_asm_for_decls () at
../../gcc/lto-streamer-out.c:2776
#198604 0x0000000000c25e21 in write_lto () at ../../gcc/passes.c:2408
#198605 0x0000000000c26030 in ipa_write_summaries_1 (encoder=0x29263d0) at
../../gcc/passes.c:2469
#198606 0x0000000000c26285 in ipa_write_summaries () at ../../gcc/passes.c:2529
#198607 0x000000000084127d in ipa_passes () at ../../gcc/cgraphunit.c:2199
#198608 0x00000000008415e6 in symbol_table::compile (this=0x7ffff185e000) at
../../gcc/cgraphunit.c:2295
#198609 0x0000000000841908 in symbol_table::finalize_compilation_unit
(this=0x7ffff185e000) at ../../gcc/cgraphunit.c:2444
#198610 0x000000000069ceb9 in c_write_global_declarations () at
../../gcc/c/c-decl.c:10801
#198611 0x0000000000d1ebad in compile_file () at ../../gcc/toplev.c:608
#198612 0x0000000000d21067 in do_compile () at ../../gcc/toplev.c:2076
#198613 0x0000000000d21295 in toplev::main (this=0x7fffffffe010, argc=20,
argv=0x7fffffffe118) at ../../gcc/toplev.c:2174
#198614 0x0000000001660011 in main (argc=20, argv=0x7fffffffe118) at
../../gcc/main.c:39

Dunno if this is really something that should be fixed, 100000 of function
arguments is really something very unlikely to be used (nobody sane would use
that).
Guess a fix for the case where a function has too many arguments would be to
allocate a temporary vector holding the arguments copied out of the chain, and
then
stream the arguments from the last one to the first one instead of the other
way around - that way we don't really recurse on TREE_CHAIN.

[Bug lto/65515] [5 Regression] FAIL: gcc.c-torture/compile/limits-fndefn.c -O2 -flto -flto-partition=none (ICE) -- SIGSEGV for stack growth failure

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This is from:
644          else if (TREE_CODE (expr) == FUNCTION_TYPE
645               || TREE_CODE (expr) == METHOD_TYPE)
646        DFS_follow_tree_edge (TYPE_ARG_TYPES (expr));
where TYPE_ARG_TYPES contains a huge TREE_LIST chain (100001 TREE_LIST nodes).
>From quick look at DFS::DFS_write_tree and DFS::DFS_write_tree_body, we don't
really have anything there like GTY chain_next, which is clearly highly
desirable here.  Dunno if order matters here, if not, then for TS_LIST counting
number of elements and if it is longer than say 10 or 100, use the vector +
DFS_write_node from the end to start, could work.

[Bug lto/65515] [5 Regression] FAIL: gcc.c-torture/compile/limits-fndefn.c -O2 -flto -flto-partition=none (ICE) -- SIGSEGV for stack growth failure

[dave.anglin at bell dot net]

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

--- Comment #5 from dave.anglin at bell dot net ---
On 2015-03-23 12:39 PM, jakub at gcc dot gnu.org wrote:
> Doesn't seem to be specific to hppa, on x86_64-linux I can reproduce it as
> well, and need ulimit -s 46000 to pass.
> The Fedora default of ulimit -sH unlimited and ulimit -sS 8192 works, because
> gcc automatically attempts to raise stack limit to 64MB if possible.
Unfortunately, this doesn't happen on hpux.  To increase limit, one 
needs to bump kernel
maxssiz and rebuild kernel.

Dave

[Bug lto/65515] [5 Regression] FAIL: gcc.c-torture/compile/limits-fndefn.c -O2 -flto -flto-partition=none (ICE) -- SIGSEGV for stack growth failure

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-03-24
                 CC|                            |rguenth at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Btw, I can't see how this regressed in GCC 5 apart from maybe using some more
stack space per recursion of DFS_write_tree.  Even GCC 4.8 which didn't have
the DFS walk recursed on these during tree writing.

But yes, that DFS walk can use stack.  GCC can use quite some stack during
garbage collection as well.

Anyway, the real fix is to re-write the DFS walk to not use recursion but a
worklist.

[Bug lto/65515] [5 Regression] FAIL: gcc.c-torture/compile/limits-fndefn.c -O2 -flto -flto-partition=none (ICE) -- SIGSEGV for stack growth failure

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 24 Mar 2015, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65515
> 
> --- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Created attachment 35124
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35124&action=edit
> gcc5-pr65515.patch
> 
> Lightly tested fix.  Basically, most of DFS::DFS_write_tree is now moved into a
> loop in DFS::DFS, and for most worklist items we see them twice, once with NULL
> w.cstate (that will result in pushing further worklist items to the stack) and
> then again with non-NULL w.cstate (which is the part of DFS_write_tree at the
> end of function.
> The patch reorders the processing of trees embedded in a tree, we'll process
> the last inserted once before the earlier inserted ones for the same tree, not
> sure if that is a problem or not, but from the DFS POV they are all children of
> the same tree.  If that would be a problem, it would be possible to rewrite
> DFS_write_tree_body to call DFS_write_tree in reverse order.  But I hope it
> isn't a problem.

This shouldn't be a problem indeed.

[Bug lto/65515] [5 Regression] FAIL: gcc.c-torture/compile/limits-fndefn.c -O2 -flto -flto-partition=none (ICE) -- SIGSEGV for stack growth failure

[dave.anglin at bell dot net]

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

--- Comment #9 from dave.anglin at bell dot net ---
On 2015-03-24 8:35 AM, jakub at gcc dot gnu.org wrote:
> Created attachment 35124
>    -->https://gcc.gnu.org/bugzilla/attachment.cgi?id=35124&action=edit
> gcc5-pr65515.patch
Testing patch.

[Bug lto/65515] [5 Regression] FAIL: gcc.c-torture/compile/limits-fndefn.c -O2 -flto -flto-partition=none (ICE) -- SIGSEGV for stack growth failure

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Wed Mar 25 09:58:18 2015
New Revision: 221656

URL: https://gcc.gnu.org/viewcvs?rev=221656&root=gcc&view=rev
Log:
    PR lto/65515
    * lto-streamer-out.c (DFS::worklist): New struct.
    (DFS::worklist_vec): New data member.
    (DFS::next_dfs_num): Remove.
    (DFS::DFS): Rewritten using worklist instead of recursion,
    using most of code from DFS::DFS_write_tree.
    (DFS::DFS_write_tree_body): Remove SINGLE_P argument, don't
    pass it to DFS_write_tree calls.
    (DFS::DFS_write_tree): Remove SINGLE_P argument, after
    quick initial checks push it into worklist_vec and return.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/lto-streamer-out.c

[Bug lto/65515] [5 Regression] FAIL: gcc.c-torture/compile/limits-fndefn.c -O2 -flto -flto-partition=none (ICE) -- SIGSEGV for stack growth failure

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.