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

--- Comment #1 from Lorenzo Salvadore <developer at lorenzosalvadore dot it> ---
I have (finally) started to look into this.
I can reproduce the issue on a FreeBSD 15 machine, but the errors are slightly
different. I have added a -v flag to get more information.



$ ~/GCC/local/usr/local/bin/g++ -v
~/GCC/src/gcc/testsuite/g++.dg/modules/freeze-1_a.C -std=c++17 -fmodules-ts     
Using built-in specs.                                                           
COLLECT_GCC=/home/lorenzo/GCC/local/usr/local/bin/g++                           
COLLECT_LTO_WRAPPER=/home/lorenzo/GCC/local/usr/local/bin/../libexec/gcc/x86_64-unknown-freebsd15.0/15.0.0/lto-wrapper
Target: x86_64-unknown-freebsd15.0                                              
Configured with: /home/lorenzo/GCC/src/configure                                
Thread model: posix                             
Supported LTO compression algorithms: zlib                                      
gcc version 15.0.0 20241215 (experimental) (GCC)                                
COLLECT_GCC_OPTIONS='-v' '-std=c++17' '-fmodules' '-shared-libgcc'
'-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'

/home/lorenzo/GCC/local/usr/local/bin/../libexec/gcc/x86_64-unknown-freebsd15.0/15.0.0/cc1plus
-quiet -v -iprefix
/home/lorenzo/GCC/local/usr/local/bin/../lib/gcc/x86_64-unknown-freebsd15.0/1
5.0.0/ /home/lorenzo/GCC/src/gcc/testsuite/g++.dg/modules/freeze-1_a.C -quiet
-dumpdir a- -dumpbase freeze-1_a.C -dumpbase-ext .C -mtune=generic
-march=x86-64 -std=c++17 -version -fmodules -o 
/tmp//ccpjtEW7.s                                
GNU C++17 (GCC) version 15.0.0 20241215 (experimental)
(x86_64-unknown-freebsd15.0)
        compiled by GNU C version 15.0.0 20241215 (experimental), GMP version
6.3.0, MPFR version 4.2.1, MPC version 1.3.1, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096         
ignoring nonexistent directory
"/home/lorenzo/GCC/local/usr/local/bin/../lib/gcc/x86_64-unknown-freebsd15.0/15.0.0/../../../../x86_64-unknown-freebsd15.0/include"
ignoring duplicate directory
"/home/lorenzo/GCC/local/usr/local/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-freebsd15.0/15.0.0/../../../../include/c++/15.0.0"
ignoring duplicate directory
"/home/lorenzo/GCC/local/usr/local/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-freebsd15.0/15.0.0/../../../../include/c++/15.0.0/x86_64-unknown-freebsd15.0"
ignoring duplicate directory
"/home/lorenzo/GCC/local/usr/local/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-freebsd15.0/15.0.0/../../../../include/c++/15.0.0/backward"
ignoring duplicate directory
"/home/lorenzo/GCC/local/usr/local/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-freebsd15.0/15.0.0/include"
ignoring duplicate directory
"/home/lorenzo/GCC/local/usr/local/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-freebsd15.0/15.0.0/include-fixed"
ignoring nonexistent directory
"/home/lorenzo/GCC/local/usr/local/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-freebsd15.0/15.0.0/../../../../x86_64-unknown-freebsd15.0/include"
#include "..." search starts here:              
#include <...> search starts here:              

/home/lorenzo/GCC/local/usr/local/bin/../lib/gcc/x86_64-unknown-freebsd15.0/15.0.0/../../../../include/c++/15.0.0

/home/lorenzo/GCC/local/usr/local/bin/../lib/gcc/x86_64-unknown-freebsd15.0/15.0.0/../../../../include/c++/15.0.0/x86_64-unknown-freebsd15.0

/home/lorenzo/GCC/local/usr/local/bin/../lib/gcc/x86_64-unknown-freebsd15.0/15.0.0/../../../../include/c++/15.0.0/backward

/home/lorenzo/GCC/local/usr/local/bin/../lib/gcc/x86_64-unknown-freebsd15.0/15.0.0/include

/home/lorenzo/GCC/local/usr/local/bin/../lib/gcc/x86_64-unknown-freebsd15.0/15.0.0/include-fixed
 /usr/local/include                             
 /usr/include                                   
End of search list.
Compiler executable checksum: 15a947999ab3be70fd6d881af23184a8
/home/lorenzo/GCC/src/gcc/testsuite/g++.dg/modules/freeze-1_a.C:5:19: internal
compiler error: Segmentation fault
    5 | export void bob ();
      |                   ^
0x34e515a internal_error(char const*, ...)
        /home/lorenzo/GCC/src/gcc/diagnostic-global-context.cc:517
0x2d769d8 crash_signal
        /home/lorenzo/GCC/src/gcc/toplev.cc:322
0x829fb59d3 ???
        /home/lorenzo/FreeBSD/src/lib/libc/amd64/string/memmove.S:304
0x14195f6 write
        /home/lorenzo/GCC/src/gcc/cp/module.cc:2122
0x1419dd6 elf_out::end()
        /home/lorenzo/GCC/src/gcc/cp/module.cc:2249
0x1424020 late_finish_module
        /home/lorenzo/GCC/src/gcc/cp/module.cc:21118
0x1424020 fini_modules(cpp_reader*, void*, bool)
        /home/lorenzo/GCC/src/gcc/cp/module.cc:21160
0x139c0b0 c_parse_final_cleanups()
        /home/lorenzo/GCC/src/gcc/cp/decl2.cc:5652
0x16c0e50 c_common_parse_file()
        /home/lorenzo/GCC/src/gcc/c-family/c-opts.cc:1407
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.



A few considerations:

- we both get the lib/libc/amd64/string/memmove.S:304 line, so this might be
important and suggests the issue might lie in some difference between GNU libc
and FreeBSD libc;

- I also do not get a core dump. I wonder if "internal compiler error:
Segmentation fault" means that we are getting a real segmentation fault.
Indeed, if I write a short software with a segmentation fault in it, build and
run it on my FreeBSD machine, the message I get it is just "Segmentation fault
(core dumped)".
Moreover, if I attempt the compilation of the test within a debugger (I used
lldb) I still do not run into a traditional segmentation fault; instead I get
the same output as above and the additional line "Process 5154 exited with
status = 1 (0x00000001)". Thus, it looks like g++ exited in an error state, but
cleanly, without segmentation faults. So what is having a segmentation fault
here and what does it actually mean?
This is probably trivial for longtime GCC contributors, but unfortunately I am
still new around and I do not understand this g++ error.

Reply via email to