WSL2 compiler segmentation fault on C++20 modules building if source file is on WSL2 mountpoint

[MissingNo42]

The toolchain (arm-none-eabi-gcc/g++) is unable to build a minimal C++20 module:

Code (dep.cppm):

export module dep;

export int rx() {return 41+1;}
int ry() {return 41+1;}

Build:
Build through CMake but the minimal command (/opt/wonderful/toolchain/gcc-arm-none-eabi/bin/arm-none-eabi-g++ -std=c++20 -fmodules-ts -Wall -c /.../dep.cppm) still cause the issue.

Error:

/.../dep.cppm:5:23: internal compiler error: Segmentation fault
    5 | int ry() {return 41+1;}
      |                       ^
0x1da594e diagnostic_context::diagnostic_impl(rich_location*, diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag (*) [1], diagnostic_t)
	???:0
0x1db6672 internal_error(char const*, ...)
	???:0
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <http://github.com/WonderfulToolchain/wonderful-packages/issues> for instructions.
ninja: build stopped: subcommand failed.

Environment:
GCC/G++ version 15.1.0 on Ubuntu 22.04 (WSL - Windows 11)

Context:
Development on NDS using BlocksDS

Note that this works fine using another arm-none-eabi-gcc/g++ like the "default" one or the one provided with Devkitpro (DevkitARM), version 15.1.0 too, so this is likely an issue with the wonderful toolchain.

[asiekierka]

Which distribution's default arm-none-eabi-gcc are we talking here? I wonder if there's a post-15.1.0 bug fix I have not pulled in, or if one of my configure options are breaking things.

[MissingNo42]

By "default" I just refer to the one installed directly from ARM builds (like with apt install gcc-arm-none-eabi on Ubuntu, but up to date).
The issue was already there with the 14.2.0 so this is likely not a config issue introduced with the 15.1.0.

[asiekierka]

[asie@nano mod]$ /opt/wonderful/toolchain/gcc-arm-none-eabi/bin/arm-none-eabi-g++ -std=c++20 -fmodules-ts -Wall -c dep.cppm
[asie@nano mod]$ ls -l
total 12
-rw-r--r-- 1 asie asie   75 May  9 18:34 dep.cppm
-rw-r--r-- 1 asie asie 1180 May  9 18:34 dep.o
drwxr-xr-x 2 asie asie 4096 May  9 18:34 gcm.cache

I could not immediately reproduce the issue on my Arch Linux installation. I will try an Ubuntu 22.04 VM next just to be sure, but my Windows 11 machine is probably too weak to setup WSL2.

[MissingNo42]

If this can help you, here is the installed packages:

> wf-pacman -Sl | grep installed
blocksds blocksds-docs 1.10.1-1 [installed]
blocksds blocksds-libdsf 0.1.5-1 [installed]
blocksds blocksds-nflib 1.1.9-1 [installed]
blocksds blocksds-nitroengine 0.15.3-1 [installed]
blocksds blocksds-ptexconv 1.5.0.1-2 [installed]
blocksds blocksds-toolchain 1.10.1-1 [installed]
wonderful runtime-gcc-libs 0.3.19-1 [installed]
wonderful runtime-musl 1.2.5-2 [installed]
wonderful toolchain-gcc-arm-none-eabi-binutils 2.44-1 [installed]
wonderful toolchain-gcc-arm-none-eabi-gcc 1:15.1.0-1 [installed]
wonderful toolchain-gcc-arm-none-eabi-gcc-libs 1:15.1.0-1 [installed]
wonderful toolchain-gcc-arm-none-eabi-libstdcxx-picolibc 15.1.0-1 [installed]
wonderful toolchain-gcc-arm-none-eabi-picolibc-generic 1.8.10.r25501.89eee9cf2-1 [installed]
wonderful toolchain-llvm-teak-llvm 11.0.0.r340442.a7c09171cf9-1 [installed]
wonderful wf-lua 5.4.7-2 [installed]
wonderful wf-lua-filesystem 1.8.0.r352.912e067-1 [installed]
wonderful wf-lua-iconv 7.1.r101.5452834-1 [installed]
wonderful wf-lua-penlight 1.14.0.r930.d2dc61b-1 [installed]
wonderful wf-lua-posix 36.3-1 [installed]
wonderful wf-lua-toml 0.4.0.r47.44a4056-1 [installed]
wonderful wf-pacman 7.0.0-7 [installed]
wonderful wf-tools 0.1.0.r109.3fada8e-1 [installed]

And the report from GCC (generated with -freport-bug):

// Target: arm-none-eabi
// Configured with: ../gcc-15.1.0/configure --prefix=/opt/wonderful/toolchain/gcc-arm-none-eabi --target=arm-none-eabi --with-pkgversion='Wonderful toolchain' --with-bugurl=http://github.com/WonderfulToolchain/wonderful-packages/issues --with-stage1-ldflags='-Wl,-rpath,/opt/wonderful/lib -Wl,--dynamic-linker=/opt/wonderful/lib/ld-musl-x86_64.so.1 -L/opt/wonderful/lib' --without-hea
ders --enable-plugins --enable-poison-system-directories --disable-bootstrap --disable-gcov --disable-nls --disable-shared --disable-werror --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-libstdcxx-threads --disable-libstdcxx-verbose --disable-libunwind-exceptions --disable-threads --with-gnu-as --with-gnu-ld --with-isl --disable-libstdcxx --enable-languages=c,c++,lto --enable-lto --enable-interwork --enable-multilib --enable-tls
// Thread model: single
// Supported LTO compression algorithms: zlib
// gcc version 15.1.0 (Wonderful toolchain)
//
// dep.cppm:4:23: internal compiler error: Segmentation fault
//     4 | int ry() {return 41+1;}
//       |                       ^
// 0x1da594e diagnostic_context::diagnostic_impl(rich_location*, diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag (*) [1], diagnostic_t)
//      ???:0
// 0x1db6672 internal_error(char const*, ...)
//      ???:0
// Please submit a full bug report, with preprocessed source.
// Please include the complete backtrace with any bug report.
// See <http://github.com/WonderfulToolchain/wonderful-packages/issues> for instructions.

// /opt/wonderful/toolchain/gcc-arm-none-eabi/libexec/gcc/arm-none-eabi/15.1.0/cc1plus -quiet -imultilib arm7tdmi -D__USES_INITFINI__ dep.cppm -quiet -dumpbase dep.cppm -dumpbase-ext .cppm -mcpu=arm7tdmi -marm -mlibarch=armv4t -march=armv4t -Wall -std=c++20 -fmodules -freport-bug -o - -frandom-seed=0 -fdump-noaddr

# 0 "dep.cppm"
# 0 "<built-in>"
# 0 "<command-line>"
# 1 "dep.cppm"
export module dep;

export int rx() {return 41+1;}
int ry() {return 41+1;}

[asiekierka]

Installing a fresh Wonderful copy an Ubuntu 22.04 virtual machine also did not show any issue. The packages match.

At this point, I would like to request you to rule out WSL2, if at all possible - either by testing with the native Windows port, or by setting up a non-WSL2 Ubuntu 22.04 virtual machine like I did above.

[MissingNo42]

I finally found the origin of the issue, the bug only happens if my .cppm is in the windows side (/mnt/c). There no issue if the file is WSL side, so just moving my project is a relevant workaround I thank.

But still, this strange bug only appears using this toolchain. Maybe you can look at how it is built/configured, comparing with devkitARM.

[asiekierka]

That's a valid point: it's using musl libc instead of glibc, which could affect file read/write behaviour, depending on how the WSL2 proxy is implemented.