[Bug go/110297] [13/14 Regression] all libgo tests fail on arm-linux-gnueabi and arm-linxu-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110297 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #7 from Ian Lance Taylor --- Should be fixed now.
[Bug go/110297] [13/14 Regression] all libgo tests fail on arm-linux-gnueabi and arm-linxu-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110297 --- Comment #6 from CVS Commits --- The releases/gcc-13 branch has been updated by Ian Lance Taylor : https://gcc.gnu.org/g:4ac89ab35884906900cde8172d2db74e1d913fec commit r13-7459-g4ac89ab35884906900cde8172d2db74e1d913fec Author: Ian Lance Taylor 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 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110297 --- Comment #5 from CVS Commits --- The master branch has been updated by Ian Lance Taylor : https://gcc.gnu.org/g:efecb298d880cda20f8d7bea2d7b500a9752ce56 commit r14-1999-gefecb298d880cda20f8d7bea2d7b500a9752ce56 Author: Ian Lance Taylor 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 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110297 --- Comment #4 from Ian Lance Taylor --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110297 --- Comment #3 from Andreas Schwab --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110297
--- Comment #2 from Andreas Schwab ---
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
=> 0xb692c37c <+60>:cmn r0, #1
0xb692c380 <+64>:movne r3, r0
0xb692c384 <+68>:beq 0xb692c398
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
0xb692c39c <+92>:mov r3, r5
0xb692c3a0 <+96>:mov r5, r0
0xb692c3a4 <+100>: b 0xb692c388
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110297 Matthias Klose 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 --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110297 Richard Biener changed: What|Removed |Added Keywords||testsuite-fail Target Milestone|--- |13.2
