[Bug go/110297] New: [13/14 Regression] all libgo tests fail on arm-linux-gnueabi and arm-linxu-gnueabihf

[Bug go/110297] New: [13/14 Regression] all libgo tests fail on arm-linux-gnueabi and arm-linxu-gnueabihf

[doko at gcc dot gnu.org]

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

            Bug ID: 110297
           Summary: [13/14 Regression] all libgo tests fail on
                    arm-linux-gnueabi and arm-linxu-gnueabihf
           Product: gcc
           Version: 13.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: go
          Assignee: ian at airs dot com
          Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen on the gcc-13 branch 20230611 on arm-linux-gnueabi and
arm-linux-gnueabihf:

and all libgo tests fail on ARM32, both on the gcc-13 branch and the trunk.

[...]
fatal error: runtime: cannot allocate memory

runtime stack:
runtime.dopanic__m
        ../../../src/libgo/go/runtime/panic.go:1207
runtime.fatalthrow
        ../../../src/libgo/go/runtime/panic.go:1073
runtime.throw
        ../../../src/libgo/go/runtime/panic.go:1044
runtime.persistentalloc1
        ../../../src/libgo/go/runtime/malloc.go:1475
runtime.persistentalloc..func1
        ../../../src/libgo/go/runtime/malloc.go:1429
runtime.systemstack
        ../../../src/libgo/go/runtime/stubs.go:61
runtime.persistentalloc
        ../../../src/libgo/go/runtime/malloc.go:1428
runtime.addrRanges.init
        ../../../src/libgo/go/runtime/mranges.go:170
runtime.pageAlloc.init
        ../../../src/libgo/go/runtime/mpagealloc.go:330
runtime.mheap.init
        ../../../src/libgo/go/runtime/mheap.go:723
runtime.mallocinit
        ../../../src/libgo/go/runtime/malloc.go:497
runtime.schedinit
        ../../../src/libgo/go/runtime/proc.go:681

        :0

        :0
__libc_start_main
        :0


that's from a simple check:
GO=go-13

WORKDIR=$(mktemp -d)
trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
cd $WORKDIR
cat <<EOF > hello.go
package main
import "fmt"
func main() {
    fmt.Println("hello world")
}
EOF

$GO run hello.go
$GO build hello.go
echo "build: OK"
ldd hello
[ -x hello ]
./hello
echo "run: OK"

[Bug go/110297] [13/14 Regression] all libgo tests fail on arm-linux-gnueabi and arm-linxu-gnueabihf

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |testsuite-fail
   Target Milestone|---                         |13.2

[Bug go/110297] [13/14 Regression] all libgo tests fail on arm-linux-gnueabi and arm-linxu-gnueabihf

[doko at gcc dot gnu.org]

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

Matthias Klose <doko at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|arm-linux-gnueabihf         |arm-linux-gnueabihf
                   |arm-linux-gnueabi           |arm-linux-gnueabi
                   |                            |powerpc-linux-gnu

--- Comment #1 from Matthias Klose <doko at gcc dot gnu.org> ---
the libgo tests also fail on powerpc-linux-gnu (for 32bit, but not for the
64bit multilibs).

the tests pass on i686-linux-gnu, also the 32bit multilib tests on
sparc64-linux-gnu.

[Bug go/110297] [13/14 Regression] all libgo tests fail on arm-linux-gnueabi and arm-linxu-gnueabihf

[schwab@linux-m68k.org]

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

--- Comment #2 from Andreas Schwab <schwab@linux-m68k.org> ---
The go side of the mmap C function is using the wrong type for the offset
argument.

Dump of assembler code for function runtime.mmap:
   0xb692c340 <+0>:     push    {r4, r5, lr}
   0xb692c344 <+4>:     sub     sp, sp, #20
   0xb692c348 <+8>:     mov     r5, #0
   0xb692c34c <+12>:    mov     r12, r1
   0xb692c350 <+16>:    mov     r4, r0
   0xb692c354 <+20>:    mov     r1, r2
   0xb692c358 <+24>:    ldr     r0, [sp, #40]   ; 0x28
   0xb692c35c <+28>:    mov     r2, r3
   0xb692c360 <+32>:    ldr     r3, [sp, #36]   ; 0x24
   0xb692c364 <+36>:    str     r0, [sp, #8]
   0xb692c368 <+40>:    str     r3, [sp]
   0xb692c36c <+44>:    mov     r0, r12
   0xb692c370 <+48>:    ldr     r3, [sp, #32]
   0xb692c374 <+52>:    str     r5, [sp, #12]
   0xb692c378 <+56>:    bl      0xb6454e80 <mmap@plt>
=> 0xb692c37c <+60>:    cmn     r0, #1
   0xb692c380 <+64>:    movne   r3, r0
   0xb692c384 <+68>:    beq     0xb692c398 <runtime.mmap+88>
   0xb692c388 <+72>:    mov     r0, r4
   0xb692c38c <+76>:    stm     r4, {r3, r5}
   0xb692c390 <+80>:    add     sp, sp, #20
   0xb692c394 <+84>:    pop     {r4, r5, pc}
   0xb692c398 <+88>:    bl      0xb644b424 <runtime.errno@plt>
   0xb692c39c <+92>:    mov     r3, r5
   0xb692c3a0 <+96>:    mov     r5, r0
   0xb692c3a4 <+100>:   b       0xb692c388 <runtime.mmap+72>

sp+36 is fd and sp+40 is offset.  The latter is then passed as 64-bit value in
sp+8/sp+12, but mmap expects a 32-bit offset.  Apparently go is assuming the
mmap64 interface.

[Bug go/110297] [13/14 Regression] all libgo tests fail on arm-linux-gnueabi and arm-linxu-gnueabihf

[schwab@linux-m68k.org]

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

--- Comment #3 from Andreas Schwab <schwab@linux-m68k.org> ---
The problem is in the magic comment in libgo/go/runtine/mem_gccgo.go:

//extern mmap
func sysMmap(addr unsafe.Pointer, n uintptr, prot, flags, fd int32, off
_libgo_off_t_type) unsafe.Pointer

This needs to be changed to mmap64.

[Bug go/110297] [13/14 Regression] all libgo tests fail on arm-linux-gnueabi and arm-linxu-gnueabihf

[ian at airs dot com]

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

--- Comment #4 from Ian Lance Taylor <ian at airs dot com> ---
Thanks.  I suspect this was broken by
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604158.html.

[Bug go/110297] [13/14 Regression] all libgo tests fail on arm-linux-gnueabi and arm-linxu-gnueabihf

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Ian Lance Taylor <ian@gcc.gnu.org>:

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

commit r14-1999-gefecb298d880cda20f8d7bea2d7b500a9752ce56
Author: Ian Lance Taylor <iant@golang.org>
Date:   Mon Jun 19 14:57:54 2023 -0700

    runtime: use a C function to call mmap

    The final argument to mmap, of type off_t, varies.
    In CL 445375 we changed it to always use the C off_t type,
    but that broke 32-bit big-endian Linux systems.  On those systems,
    using the C off_t type requires calling the mmap64 function.
    In C this is automatically handled by the <sys/mman.h> file.
    In Go, we would have to change the magic //extern comment to
    call mmap64 when appropriate.  Rather than try to get that right,
    we instead go through a C function that uses C implicit type
    conversions to pick the right type.

    Fixes PR go/110297

    Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/504415

[Bug go/110297] [13/14 Regression] all libgo tests fail on arm-linux-gnueabi and arm-linxu-gnueabihf

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Ian Lance Taylor
<ian@gcc.gnu.org>:

https://gcc.gnu.org/g:4ac89ab35884906900cde8172d2db74e1d913fec

commit r13-7459-g4ac89ab35884906900cde8172d2db74e1d913fec
Author: Ian Lance Taylor <iant@golang.org>
Date:   Tue Jun 20 09:56:34 2023 -0700

    runtime: use a C function to call mmap

    The final argument to mmap, of type off_t, varies.
    In CL 445375 we changed it to always use the C off_t type,
    but that broke 32-bit big-endian Linux systems.  On those systems,
    using the C off_t type requires calling the mmap64 function.
    In C this is automatically handled by the <sys/mman.h> file.
    In Go, we would have to change the magic //extern comment to
    call mmap64 when appropriate.  Rather than try to get that right,
    we instead go through a C function that uses C implicit type
    conversions to pick the right type.

    Fixes PR go/110297

    Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/504415

[Bug go/110297] [13/14 Regression] all libgo tests fail on arm-linux-gnueabi and arm-linxu-gnueabihf

[ian at airs dot com]

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

Ian Lance Taylor <ian at airs dot com> changed:

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

--- Comment #7 from Ian Lance Taylor <ian at airs dot com> ---
Should be fixed now.