[Bug go/87589] [9/10/11/12 regression] index0-out.go FAILs

[Bug go/87589] [9/10/11/12 regression] index0-out.go FAILs

[jakub at gcc dot gnu.org]

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

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

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

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

[Bug go/87589] [9/10/11/12 regression] index0-out.go FAILs

[rguenth at gcc dot gnu.org]

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

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

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

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

[Bug go/87589] [10/11/12/13 regression] index0-out.go FAILs

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9 branch is being closed

[Bug go/87589] [10/11/12/13 regression] index0-out.go FAILs

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.4                        |10.5

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug go/87589] [11/12/13/14 regression] index0-out.go FAILs

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.5                        |11.5

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10 branch is being closed.

[Bug go/87589] [11/12/13/14/15 regression] index0-out.go FAILs

[ro at gcc dot gnu.org]

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

--- Comment #8 from Rainer Orth <ro at gcc dot gnu.org> ---
Something is still very wrong with this test: it FAILs not only on Solaris/x86,
but also Solaris/SPARC and Linux/x86_64, always with a SEGV.

Looking closer, I checked the 32-bit Solaris/x86 test, which SEGVs in
__go_init_main:

(gdb) x/20i __go_init_main
   0x81a9cf0 <__go_init_main>:  lea    0x4(%esp),%ecx
   0x81a9cf4 <__go_init_main+4>:        and    $0xfffffff0,%esp
   0x81a9cf7 <__go_init_main+7>:        push   -0x4(%ecx)
   0x81a9cfa <__go_init_main+10>:       push   %ebp
   0x81a9cfb <__go_init_main+11>:       mov    %esp,%ebp
   0x81a9cfd <__go_init_main+13>:       push   %ebx
   0x81a9cfe <__go_init_main+14>:       push   %ecx
   0x81a9cff <__go_init_main+15>:       sub    $0x3d0b50,%esp
   0x81a9d05 <__go_init_main+21>:       sub    $0x8,%esp
=> 0x81a9d08 <__go_init_main+24>:       push   $0x808d1c0

Looking at %esp at various points, I find:

  on entry to __go_init_main            %esp = 0x81a9cf0        text
  after and    $0xfffffff0,%esp         %esp = 0x8a49f30        anon
  after push   %ecx                     %esp = 0x8a49f20        anon
  after sub    $0x3d0b50,%esp           %esp = 0x86793d0        unmapped!
  after sub    $0x8,%esp                %esp = 0x86793c8        unmapped!

as can be seen in the pmap -x output:

 Address Kbytes   RSS Anon Lock Mode     Mapped File
08050000   1388   220    -    - r-x----  [ text ] index0-out.x
  - 0x81ab000
081BA000    156   156    8    - rwx----  [ data ] index0-out.x
  - 0x81e1000
081E1000   3904     -    -    - rwx----  [ data ] index0-out.x
  - 0x85b1000
085B1000     12    12   12    - rwx----  [ heap ]
  - 0x85b4000
08800000     16    12   12    - rw-----  [ anon ]
  - 0x8804000
08804000     40     -    -    - rw-----  [ altstack tid=1 ]
  - 0x880e000
0880E000   4040   192  192    - rw-----  [ anon ]
  - 0x8c00000

I wonder how this can work at all.

[Bug go/87589] [11/12/13/14/15 regression] index0-out.go FAILs

[ian at airs dot com]

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

--- Comment #9 from Ian Lance Taylor <ian at airs dot com> ---
It does work for me on x86_64 GNU/Linux.  The big stack allocation is handled
by the split-stack support.

This of course leaves the question of why it is making such a large stack
allocation to begin with.  It seems to be because of the line

var t = T{si, ai, pai, sq, aq, paq, sib, aib, paib, sqb, aqb, paqb}

This is being compiled into code that assembles a T value on the stack and then
copies it into the variable t.  Unfortunately the type T includes fields like

        aib [100000]int
        paib *[100000]int
        sqb []quad
        aqb [100000]quad
        paqb *[100000]quad

which are very very large.

[Bug go/87589] [11/12/13/14/15 regression] index0-out.go FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #9 from Ian Lance Taylor <ian at airs dot com> ---
> It does work for me on x86_64 GNU/Linux.  The big stack allocation is handled
> by the split-stack support.

I think I see what's happening now: my Linux/x86_64 build is configured
with --with-ld=<path to>/gld-2.42, but there's no matching gld-2.42.gold
around, so auto-host.h has

/* #undef HAVE_GOLD_NON_DEFAULT_SPLIT_STACK */

Thus no split-stack support and the SEGV observed.

[Bug go/87589] [11/12/13/14/15 regression] index0-out.go FAILs

[ro at gcc dot gnu.org]

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

--- Comment #11 from Rainer Orth <ro at gcc dot gnu.org> ---
Created attachment 58357
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58357&action=edit
Proposed patch

Wouldn't the attached patch be TRT then?

Btw., ISTM that this should be unsupported instead of untested, according to
the DejaGnu docs.

[Bug go/87589] [11/12/13/14/15 regression] index0-out.go FAILs

[ian at airs dot com]

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

--- Comment #12 from Ian Lance Taylor <ian at airs dot com> ---
Sure, we can do that patch for now.  Thanks.  unsupported is fine too.

Let's not close the bug, though.  The real fix is to not put very large objects
on the stack--we don't want to do that for split-stack either.  There should be
some size cut off where we push objects onto the heap.  But we don't have to do
that today.

[Bug go/87589] [11/12/13/14/15 regression] index0-out.go FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #12 from Ian Lance Taylor <ian at airs dot com> ---
> Sure, we can do that patch for now.  Thanks.  unsupported is fine too.

I've posted the patch now

https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653813.html

but decided to leave the untested -> unsupported change separate to
avoid obscuring the other change.

> Let's not close the bug, though.  The real fix is to not put very large objects
> on the stack--we don't want to do that for split-stack either.  There should be
> some size cut off where we push objects onto the heap.  But we don't have to do
> that today.

Fine, will do.

[Bug go/87589] [11/12/13/14/15 regression] index0-out.go FAILs

[cvs-commit at gcc dot gnu.org]

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

--- Comment #14 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Rainer Orth <ro@gcc.gnu.org>:

https://gcc.gnu.org/g:9ab90fc627301b1701cf19bf4ca220f02a93d894

commit r15-1091-g9ab90fc627301b1701cf19bf4ca220f02a93d894
Author: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Date:   Fri Jun 7 10:12:09 2024 +0200

    testsuite: go: Require split-stack support for go.test/test/index0.go
[PR87589]

    The index0-out.go test FAILs on Solaris (SPARC and x86, 32 and 64-bit),
    as well as several others:

    FAIL: ./index0-out.go execution,  -O0 -g -fno-var-tracking-assignments

    The test SEGVs because it tries a stack acess way beyond the stack
    area.  As Ian analyzed in the PR, the testcase currently requires
    split-stack support, so this patch requires just that.

    Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11.

    2024-06-05  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

            gcc/testsuite:
            PR go/87589
            * go.test/go-test.exp (go-gc-tests): Require split-stack support
            for index0.go.