[Bug c++/111448] New: g++ ICE Segmentation fault in qemu-riscv64-static emulator

[Bug c++/111448] New: g++ ICE Segmentation fault in qemu-riscv64-static emulator

[rsworktech at outlook dot com]

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

            Bug ID: 111448
           Summary: g++ ICE Segmentation fault in qemu-riscv64-static
                    emulator
           Product: gcc
           Version: 13.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rsworktech at outlook dot com
  Target Milestone: ---

Created attachment 55918
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55918&action=edit
reduced ICE source file

Maybe this is technically not a gcc bug. But I very much appreciate any
suggestions and pointers you might give to me.

gcc doesn't fail on real riscv64 boards so looks more like a qemu bug to me. I
also reported it to qemu: https://gitlab.com/qemu-project/qemu/-/issues/1895

In a qemu-user Arch Linux riscv64
container(https://github.com/felixonmars/archriscv-packages/wiki/Setup-Arch-Linux-RISC-V-Development-Environment),
the attached source file(which has been reduced to less than 5kb by cvise)
caused an ICE, segmentation fault.

Command: g++ -S testcase.i -w -fpreprocessed -o /dev/null

Output: 

g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See <https://bugs.archlinux.org/> for instructions.

g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/riscv64-unknown-linux-gnu/13.2.1/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=c,c++,d,fortran,go,lto,objc,obj-c++ --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-multilib --disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.1 20230801 (GCC)

[Bug c++/111448] g++ ICE Segmentation fault in qemu-riscv64-static emulator

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I suspect this is a dup of bug 110315.  It works on the trunk but fails on
13.2.0 even on x86_64-linux-gnu.

[Bug c++/111448] g++ ICE Segmentation fault in qemu-riscv64-static emulator

[rsworktech at outlook dot com]

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

--- Comment #2 from Levi Zim <rsworktech at outlook dot com> ---
(In reply to Andrew Pinski from comment #1)
> I suspect this is a dup of bug 110315.  It works on the trunk but fails on
> 13.2.0 even on x86_64-linux-gnu.

I tested it with gcc 13.1.1 and gcc 12.3.0.

gcc 13.1.1 also triggers the ICE.

gcc 12.3.0 doesn't trigger the ICE.

[Bug c++/111448] g++ ICE Segmentation fault in qemu-riscv64-static emulator

[schwab@linux-m68k.org]

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

--- Comment #3 from Andreas Schwab <schwab@linux-m68k.org> ---
Also seen with sonic-pi

https://build.opensuse.org/package/live_build_log/openSUSE:Factory:RISCV/sonic-pi/standard/riscv64

and psi+

https://build.opensuse.org/package/live_build_log/openSUSE:Factory:RISCV/psi+/standard/riscv64

[Bug c++/111448] g++ ICE Segmentation fault in qemu-riscv64-static emulator

[rsworktech at outlook dot com]

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

--- Comment #4 from Levi Zim <rsworktech at outlook dot com> ---
I tested it on gcc's latest commit(5b4acfa306d53c8473883552f1db7278b7065b18).
It doesn't trigger the ICE.

However, I do have another source file that still triggers the ICE with gcc's
latest commit. It is a quite large file(3.8MB) and I can't attach it here so I
put it on gist: https://gist.github.com/kxxt/72b553ae855697d6fcd8300994e7e137

I am reducing this file using cvise and will upload it later.

[Bug c++/111448] g++ ICE Segmentation fault in qemu-riscv64-static emulator

[schwab@linux-m68k.org]

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

--- Comment #5 from Andreas Schwab <schwab@linux-m68k.org> ---
GCC tries to increase the stack limit to 64Mb, but the qemu user-space
emulation uses a fixed stack size (initialized on startup from the current
stack limit) and ignores the RLIMIT_STACK request.

[Bug c++/111448] g++ ICE Segmentation fault in qemu-riscv64-static emulator

[rsworktech at outlook dot com]

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

Levi Zim <rsworktech at outlook dot com> changed:

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

--- Comment #6 from Levi Zim <rsworktech at outlook dot com> ---
(In reply to Andreas Schwab from comment #5)
> GCC tries to increase the stack limit to 64Mb, but the qemu user-space
> emulation uses a fixed stack size (initialized on startup from the current
> stack limit) and ignores the RLIMIT_STACK request.

Thanks! That's indeed the crux. After increasing QEMU_STACK_SIZE, the bug
disappears.

Let's track it on qemu bug tracker instead:
https://gitlab.com/qemu-project/qemu/-/issues/1895