Just wanted to report a compiler crash of flang (not sure, whether this is the right place, or should I rather do it as an issue?)
I have unforutanetly failed to create a compact minimal working example. The crash occurs during the build of the Fortuno unit testing framework. When I put all the relevant modules into a single file, the crash does not seem to occur any more. If you have any ideas, how I can support the debugging process let me know.
How to reproduce:
wget https://github.com/fortuno-repos/fortuno/archive/refs/tags/v0.1.0.zip
unzip v0.1.0.zip
cd fortuno-0.1.0
mkdir build
cd build
FC=flang-new cmake ..
make VERBOSE=1
Obtained result
d /home/aradi/ramdisk/fortuno-0.1.0/build/src && /home/aradi/opt/miniforge3/envs/flang/bin/flang-new -Dfortuno_serial_EXPORTS -I/home/aradi/ramdisk/fortuno-0.1.0/build/src/modules -I/home/aradi/ramdisk/fortuno-0.1.0/include -O2 -g -module-dirmodules -c /home/aradi/ramdisk/fortuno-0.1.0/src/fortuno_serial/serialcase.f90 -o CMakeFiles/fortuno_serial.dir/fortuno_serial/serialcase.f90.o
fatal internal error: CHECK(category_ == TypeDerived || category_ == ClassDerived) failed at /home/conda/feedstock_root/build_artifacts/flang-split_1732108209279/work/flang/include/flang/Semantics/type.h(387)
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /home/aradi/opt/miniforge3/envs/flang/bin/flang-new -fc1 -triple x86_64-conda-linux-gnu -emit-obj -D fortuno_serial_EXPORTS -I /home/aradi/ramdisk/fortuno-0.1.0/build/src/modules -I /home/aradi/ramdisk/fortuno-0.1.0/include -fcolor-diagnostics -mrelocation-model pic -pic-level 2 -pic-is-pie -target-cpu x86-64 -module-dir modules -debug-info-kind=standalone -resource-dir /home/aradi/opt/miniforge3/envs/flang/lib/clang/19 -mframe-pointer=none -O2 -o CMakeFiles/fortuno_serial.dir/fortuno_serial/serialcase.f90.o -x f95-cpp-input /home/aradi/ramdisk/fortuno-0.1.0/src/fortuno_serial/serialcase.f90
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
0 libLLVM.so.19.1 0x00007f6def92947f llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 63
1 libLLVM.so.19.1 0x00007f6def926a4b
2 libc.so.6 0x00007f6dee84fd00
3 libc.so.6 0x00007f6dee8a8664
4 libc.so.6 0x00007f6dee84fc4e gsignal + 30
5 libc.so.6 0x00007f6dee837902 abort + 223
6 libFortranCommon.so.19.1 0x00007f6dfd329efa
7 libFortranLower.so.19.1 0x00007f6dede016ce Fortran::lower::ComponentReverseIterator::advanceToParentType() + 558
8 libFortranLower.so.19.1 0x00007f6deddf78ae
9 libFortranLower.so.19.1 0x00007f6deddf8f3b
10 libFortranLower.so.19.1 0x00007f6deddf671b
11 libFortranLower.so.19.1 0x00007f6deddf6973 Fortran::lower::convertExprToHLFIR(mlir::Location, Fortran::lower::AbstractConverter&, Fortran::evaluate::Expr<Fortran::evaluate::SomeType> const&, Fortran::lower::SymMap&, Fortran::lower::StatementContext&) + 131
12 libFortranLower.so.19.1 0x00007f6dedc161de
13 libFortranLower.so.19.1 0x00007f6dedc1879a Fortran::lower::convertCallToHLFIR(mlir::Location, Fortran::lower::AbstractConverter&, Fortran::evaluate::ProcedureRef const&, std::optional<mlir::Type>, Fortran::lower::SymMap&, Fortran::lower::StatementContext&) + 218
14 libFortranLower.so.19.1 0x00007f6dedbbcf75
15 libFortranLower.so.19.1 0x00007f6dedbc0dec
16 libFortranLower.so.19.1 0x00007f6dedbc2fd0 Fortran::lower::LoweringBridge::lower(Fortran::parser::Program const&, Fortran::semantics::SemanticsContext const&) + 3552
17 libflangFrontend.so.19.1 0x00007f6dfc7af05d Fortran::frontend::CodeGenAction::beginSourceFileAction() + 1597
18 libflangFrontend.so.19.1 0x00007f6dfc6e42d5 Fortran::frontend::FrontendAction::beginSourceFile(Fortran::frontend::CompilerInstance&, Fortran::frontend::FrontendInputFile const&) + 2101
19 libflangFrontend.so.19.1 0x00007f6dfc6d150f Fortran::frontend::CompilerInstance::executeAction(Fortran::frontend::FrontendAction&) + 447
20 libflangFrontendTool.so.19.1 0x00007f6dfd075e9e Fortran::frontend::executeCompilerInvocation(Fortran::frontend::CompilerInstance*) + 4318
21 flang-new 0x0000555e8d5a0259 fc1_main(llvm::ArrayRef<char const*>, char const*) + 1129
22 flang-new 0x0000555e8d59eb0b main + 2747
23 libc.so.6 0x00007f6dee839088
24 libc.so.6 0x00007f6dee83914b __libc_start_main + 139
25 flang-new 0x0000555e8d59f0ab
flang-new: error: unable to execute command: Aborted (core dumped)
flang-new: error: flang frontend command failed due to signal (use -v to see invocation)
flang-new version 19.1.4 (https://github.com/conda-forge/clangdev-feedstock ea701dd210fdae63609dff9e817128a8f9847256)
Target: x86_64-conda-linux-gnu
Thread model: posix
InstalledDir: /home/aradi/opt/miniforge3/envs/flang/bin
Configuration file: /home/aradi/opt/miniforge3/envs/flang/bin/x86_64-conda-linux-gnu.cfg
flang-new: note: diagnostic msg:
********************
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
flang-new: note: diagnostic msg: /tmp/serialcase-d5b0cd
flang-new: note: diagnostic msg: /tmp/serialcase-d5b0cd.sh
flang-new: note: diagnostic msg:
I have used flang-new from conda:
flang-new version 19.1.4 (https://github.com/conda-forge/clangdev-feedstock ea701dd210fdae63609dff9e817128a8f9847256)
Target: x86_64-conda-linux-gnu
Thread model: posix
Actually, the culprit seems to be the line
No crash occurs, if the line is commented out. (And if I just create a local variable with serial_case(name=name, proc=proc), the crash remains, so it seems to be related to the structure constructor.