public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug modula2/101392] New: cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC @ 2021-07-09 12:34 ro at gcc dot gnu.org 2021-09-14 10:15 ` [Bug modula2/101392] " ro at gcc dot gnu.org ` (6 more replies) 0 siblings, 7 replies; 8+ messages in thread From: ro at gcc dot gnu.org @ 2021-07-09 12:34 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101392 Bug ID: 101392 Summary: cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: gaiusmod2 at gmail dot com Target Milestone: --- Target: sparc-sun-solaris2.11 The devel/modula-2 build on Solaris/SPARC finally breaks down like this: sh /vol/gcc/src/git/modula-2/gcc/m2/tools-src/makeSystem -fpim \ /vol/gcc/src/git/modula-2/gcc/m2/gm2-libs/SYSTEM.def \ /vol/gcc/src/git/modula-2/gcc/m2/gm2-libs/SYSTEM.mod \ -I/vol/gcc/src/git/modula-2/gcc/m2/gm2-libs \ "/var/gcc/gcc-12.0.0-20210708/11.4-gm2/./gcc/gm2 -B/var/gcc/gcc-12.0.0-20210708/11.4-gm2/./gcc/" /var/gcc/gcc-12.0.0-20210708/11.4-gm2/gcc/m2/gm2-libs/SYSTEM.def gm2: internal compiler error: Segmentation Fault signal terminated program cc1gm2 As an aside, it seems weird to hardcode sh here rather than using $(SHELL) as set in the Makefile's. The failing gm2 invocation is /var/gcc/gcc-12.0.0-20210708/11.4-gm2/./gcc/gm2 -B/var/gcc/gcc-12.0.0-20210708/11.4-gm2/./gcc/ -fpim -I/vol/gcc/src/git/modula-2/gcc/m2/gm2-libs -fno-m2-plugin -c -fdump-system-exports /vol/gcc/src/git/modula-2/gcc/m2/gm2-libs/SYSTEM.mod -o /dev/null SYSTEM module creates type: LOC SYSTEM module creates type: WORD SYSTEM module creates type: BYTE SYSTEM module creates type: ADDRESS SYSTEM module creates type: INTEGER8 SYSTEM module creates type: INTEGER16 SYSTEM module creates type: INTEGER32 SYSTEM module creates type: INTEGER64 SYSTEM module creates type: CARDINAL8 SYSTEM module creates type: CARDINAL16 SYSTEM module creates type: CARDINAL32 SYSTEM module creates type: CARDINAL64 SYSTEM module creates type: WORD16 SYSTEM module creates type: WORD32 SYSTEM module creates type: WORD64 SYSTEM module creates type: BITSET8 SYSTEM module creates type: BITSET16 SYSTEM module creates type: BITSET32 SYSTEM module creates type: REAL32 SYSTEM module creates type: REAL64 SYSTEM module creates type: REAL128 SYSTEM module creates type: COMPLEX32 SYSTEM module creates type: COMPLEX64 SYSTEM module creates type: COMPLEX128 SYSTEM module creates type: CSIZE_T SYSTEM module creates type: CSSIZE_T gm2: internal compiler error: Segmentation Fault signal terminated program cc1gm2 Running it with -v shows the cc1gm2 command line: /var/gcc/gcc-12.0.0-20210708/11.4-gm2/./gcc/cc1gm2 -quiet -dumpdir /dev/ -dumpbase SYSTEM.mod -dumpbase-ext .mod -mcpu=v9 -version -fobject-path=/vol/gcc/src/git/modula-2/gcc/m2/gm2-libs -ftarget-ar=/usr/gnu/bin/ar -ftarget-ranlib=/usr/gnu/bin/ranlib -fpim -fno-m2-plugin -fdump-system-exports -fobject-path=/vol/gcc/src/git/modula-2/gcc/m2/gm2-libs -ftarget-ar=/usr/gnu/bin/ar -ftarget-ranlib=/usr/gnu/bin/ranlib -fpim -fno-m2-plugin -fdump-system-exports -I/vol/gcc/src/git/modula-2/gcc/m2/gm2-libs -I/usr/local/lib/gcc/sparc-sun-solaris2.11/12.0.0/m2/m2pim /vol/gcc/src/git/modula-2/gcc/m2/gm2-libs/SYSTEM.mod -o SYSTEM.s When I tried to add -save-temps instead of explicitly giving -o SYSTEM.s, I got cc1gm2: fatal error: cannot open ‘/dev/SYSTEM.s’ for writing: No such device or address -dumpdir /dev/ is bogus, it seems. Besides, most cc1gm2 options given twice! I get the SEGV even with cc1gm2 -quiet -fdump-system-exports -I /vol/gcc/src/git/modula-2/gcc/m2/gm2-libs/SYSTEM.mod -o SYSTEM.s under gdb: Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0xfeb51bb0 in strlen () from /lib/libc.so.1 (gdb) where #0 0xfeb51bb0 in strlen () from /lib/libc.so.1 #1 0xfeb937fc in strdup () from /lib/libc.so.1 #2 0x017cbed4 in lrealpath () #3 0x017ca494 in canonical_filename_eq () #4 0x00c35fa8 in toplev::main(int, char**) () #5 0x0172379c in main () running the full command and gdb: SYSTEM module creates type: CSSIZE_T cc1gm2:1:unrecognised symbol cc1gm2:1: cc1gm2:1: ^ cc1gm2:1:unrecognised symbol cc1gm2:1:3: error: expecting one of: ‘IMPLEMENTATION’ ‘MODULE’ ‘DEFINITION’ 1 | ELF Qdx 4��� 4 ( 2 1 4 4 � � �z�z �z�z '� �E ��D��D � � ��T��T l < dd�P ( ( �t �t /usr/lib/ld.so.1 ��� um Pe���� Pe���� Pe���� Pe���� Pe���� Pe��� Pe���( Pf@��` Pp���| Pp���� Pq��� PqL��� PqT��� P@��� P�x�� P�T��( P���D P�8��` P�`��| P����� P����� P�|��� P� ��� P��� P���� P����( P�\��D P�d��T PĄ��d PĤ��t P����� P����� P���� P�T��� PŐ��D PŰ��� PȠ��� P�X��� P�\��� P� ��� P���� P�,��� P����� P��� P�h��� P�T��� P�T�� P����( P���D P�(��` P���| P�`��� P���� P���� P���� P� ��� P�p�� P����4 P����P P�H��l P�X��| P�h��� P����� P���� P����� P�X��� P�h�� P����( P����D P����` P� ��� Q���� Q�� Q���$ Q��@ Q%���\ Q.���x QI���� QkP��� Qk���� Ql��� Ql��� Qm�� Qm���< Qt\��X Qv��t Qw���� Q{T��� Q{t�� Q{���0 Q{���L Q{���h Q{���, Q|@��H Q|���d Q}���| Q~���� Q���� Q����� Q����� Q����� Q�(�� Q���d Q����� Q���� Q����� Q��� Q�0��� Q�8�� Q����( Q����D Q����T Q���p Q���� Q����� Q����� Q���� Q����� Q� �� Q�8��4 Q���P Q�H��l Q�<��� Q����� Q�d��� Q�T��� Q����� Q�l�� Q����0 Q����L Q���h Qߴ��� Q�<��� Q�8��� Q����� Q�P��� Q�\�� Q���� Q���< Q����X Q���t Q���� Q�x��, Q����H Q����� Q��� Q���� Q���< Q�l��X Q����t Q����� Q� ��� Q��� Q����� Q���� Q�T�� Q����8 Q����H Q����X R ���t R��� R ��� R8��� R��� R��� Rt�� R���, R���H R\��d R���� R<��� Rd��� R���� R���� R���� R��� R�� R���< R���h Rh��� R\��� Rd��� Rp��� R��� R���� R�� R��� R���4 Rd��P Rp��` R|��p R���� R���� R���� R�D��� R����� R��� RX�� R��, R���H R ��d R���� R 0��� R ���� R��� R!���� R"�� R"|��( R"���D R#H��` R$l��| R$���� R%T��� R%���� R0���� R�� R1���4 R2���P R3���l R3���| R3���� R7���� R>���� R@h��� RC���� RF��� RJ8��D RJ���` ROD��| RRd��� RU ��� RW��� R[@��� R]�� R^���$ R`(��@ R`@��\ R`X��x R`���� R`���� Ra ��� Ra��� Ra��� Ra���$ Ra���4 Rb ��D Rb ��T Rb��d Rb��� Re���� RfX��� Rg���� Rh��� Rk$�� Rk|��, Rl���H Rm ��d Rm���� Rn4��� Rn���� Rn���� Rn���� Rn���� Rn���� Ro��$ Ro���@ Ro���\ Rq��x Rrx��� Rs��� Rs���� Rt���� Ru�� RuP�� Ru���< Rw��X Rw���t Rx<��� Rx`��� Rx���� R|���� R~`�� R~��� R|��8 R�@��T R����p R����� R����� R���� R�H��� R�l��� R���� R����4 R����P R����` R���| R����� R����� R�<��� R�P��� R�X� R����$ R����@ R����\ R� ��l R� ��| R� ��� R�4��� R�H��� R�\��� R�p��� R����� R���� R�<��0 R�T��L R����h R�,��� R����� R���� R�p��� R����� R�H�� R����, R����H R�P��d R����� R�(��� R����� R�(��� R�p��� R���� R�@��( R����D R���` R����| R����� R�<��� R����� R����� R�� R�\��$ R����@ R����\ R�0��x R R����4 R�,��P RՀ��l Rմ��� R����� R�L��� R����� R�8��� R۠�� R�H��0 R����L R�,��h R����� R�|��� R����� R�@��� R���� R���� R���, R�D��H R����d R�x��� R�0��� R���� R�H��� R�x��� R���� R�d�� R����8 R����H R����X R���t R���� R�d��� R����� R����� R��� R���� R����, R�x��H R����d R����t R����� R����� S \��� S h��� S t��� S ���� S ��� S ��( Sd��D S���` S ��| ��� S | ^~~ cc1gm2:1:3: error: compilation failed [Switching to Thread 1 (LWP 1)] Thread 2 hit Breakpoint 3, 0xfeb4fc24 in exit () from /lib/libc.so.1 (gdb) where #0 0xfeb4fc24 in exit () from /lib/libc.so.1 #1 0x0060ea04 in libc_exit (code=1) at /vol/gcc/src/git/modula-2/gcc/m2/mc-boot-ch/Glibc.c:46 #2 0x006071d4 in M2RTS_HALT () #3 0x0058d3c4 in M2Error_FlushErrors () #4 0x00571c08 in M2Comp_compile () #5 0x005180d8 in gm2_langhook_parse_file() () #6 0x00c31e18 in compile_file() () #7 0x00c35158 in toplev::main(int, char**) () #8 0x0172379c in main () I couldn't make much sense of this yet. Probably requires rebuilding cc1gm2 with -g3 -O0. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug modula2/101392] cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC 2021-07-09 12:34 [Bug modula2/101392] New: cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC ro at gcc dot gnu.org @ 2021-09-14 10:15 ` ro at gcc dot gnu.org 2022-05-03 15:27 ` gaius at gcc dot gnu.org ` (5 subsequent siblings) 6 siblings, 0 replies; 8+ messages in thread From: ro at gcc dot gnu.org @ 2021-09-14 10:15 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101392 Rainer Orth <ro at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Last reconfirmed| |2021-09-14 Status|UNCONFIRMED |NEW --- Comment #1 from Rainer Orth <ro at gcc dot gnu.org> --- (In reply to Rainer Orth from comment #0) > I couldn't make much sense of this yet. Probably requires rebuilding cc1gm2 > with > -g3 -O0. I've now done just that. Here's what I find: Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0xfeb51bb0 in strlen () from /lib/libc.so.1 (gdb) where #0 0xfeb51bb0 in strlen () from /lib/libc.so.1 #1 0xfeb937fc in strdup () from /lib/libc.so.1 #2 0x02a48c90 in lrealpath (filename=0x0) at /vol/gcc/src/git/modula-2/libiberty/lrealpath.c:88 #3 0x02a45fa4 in canonical_filename_eq (a=0xffbff8e2 "SYSTEM.s", b=0x0) at /vol/gcc/src/git/modula-2/libiberty/filename_cmp.c:216 #4 0x016e97c8 in init_asm_output (name=0x0) at /vol/gcc/src/git/modula-2/gcc/toplev.c:714 #5 0x016ed1dc in lang_dependent_init (name=0x0) at /vol/gcc/src/git/modula-2/gcc/toplev.c:1927 #6 0x016edf58 in do_compile () at /vol/gcc/src/git/modula-2/gcc/toplev.c:2218 #7 0x016ee4a8 in toplev::main (this=0xffbff6e2, argc=7, argv=0xffbff74c) at /vol/gcc/src/git/modula-2/gcc/toplev.c:2372 #8 0x02924ec4 in main (argc=7, argv=0xffbff74c) at /vol/gcc/src/git/modula-2/gcc/main.c:39 #4 0x016e97c8 in init_asm_output (name=0x0) at /vol/gcc/src/git/modula-2/gcc/toplev.c:714 714 else if (!canonical_filename_eq (asm_file_name, name) (gdb) p asm_file_name $3 = 0xffbff8e2 "SYSTEM.s" (gdb) p name $4 = 0x0 (gdb) up #5 0x016ed1dc in lang_dependent_init (name=0x0) at /vol/gcc/src/git/modula-2/gcc/toplev.c:1927 1927 init_asm_output (name); gdb) up #6 0x016edf58 in do_compile () at /vol/gcc/src/git/modula-2/gcc/toplev.c:2218 2218 if (lang_dependent_init (main_input_filename)) (gdb) p main_input_filename $6 = 0x0 (gdb) up #7 0x016ee4a8 in toplev::main (this=0xffbff6e2, argc=7, argv=0xffbff74c) at /vol/gcc/src/git/modula-2/gcc/toplev.c:2372 2372 do_compile (); Ultimately, the problem is two-fold: * cc1gm2 doesn't set main_input_filename (perhaps only with -fdump-system-exports, I haven't checked) * In the end, libiberty's lrealpath is called with lrealpath (NULL, NULL) which again calls strdup (NULL), leading to the SEGV. I couldn't find a clear indication if this is supported by the C standard, but even if I harden lrealpath to avoid strdup(NULL), I get more SEGVs later on in other places. So clearly the error is not setting main_input_filename. No idea why this happens for gm2 only or how to fix this, though. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug modula2/101392] cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC 2021-07-09 12:34 [Bug modula2/101392] New: cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC ro at gcc dot gnu.org 2021-09-14 10:15 ` [Bug modula2/101392] " ro at gcc dot gnu.org @ 2022-05-03 15:27 ` gaius at gcc dot gnu.org 2022-05-04 13:18 ` ro at CeBiTec dot Uni-Bielefeld.DE ` (4 subsequent siblings) 6 siblings, 0 replies; 8+ messages in thread From: gaius at gcc dot gnu.org @ 2022-05-03 15:27 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101392 Gaius Mulley <gaius at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |WAITING --- Comment #2 from Gaius Mulley <gaius at gcc dot gnu.org> --- I've just git pushed a fix to assign main_input_filename before each compilation. Tested on Debian/amd64 which passed with no regression test errors. I'll try out a Solaris/sparc combination next. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug modula2/101392] cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC 2021-07-09 12:34 [Bug modula2/101392] New: cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC ro at gcc dot gnu.org 2021-09-14 10:15 ` [Bug modula2/101392] " ro at gcc dot gnu.org 2022-05-03 15:27 ` gaius at gcc dot gnu.org @ 2022-05-04 13:18 ` ro at CeBiTec dot Uni-Bielefeld.DE 2022-11-07 13:15 ` ro at gcc dot gnu.org ` (3 subsequent siblings) 6 siblings, 0 replies; 8+ messages in thread From: ro at CeBiTec dot Uni-Bielefeld.DE @ 2022-05-04 13:18 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101392 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> --- > --- Comment #2 from Gaius Mulley <gaius at gcc dot gnu.org> --- > I've just git pushed a fix to assign main_input_filename before each > compilation. Tested on Debian/amd64 which passed with no regression test > errors. > I'll try out a Solaris/sparc combination next. Good. However, as of 20220424, a sparc-sun-solaris2.11 build went beyond this error, hitting PR modula2/105392 instead. sparcv9-sun-solaris2.11 is even better: the build finishes successfully and only runs into a non-M2 bug (PR middle-end/105409) affecting a considerable number of 32-bit tests. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug modula2/101392] cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC 2021-07-09 12:34 [Bug modula2/101392] New: cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC ro at gcc dot gnu.org ` (2 preceding siblings ...) 2022-05-04 13:18 ` ro at CeBiTec dot Uni-Bielefeld.DE @ 2022-11-07 13:15 ` ro at gcc dot gnu.org 2022-11-09 16:30 ` gaius at gcc dot gnu.org ` (2 subsequent siblings) 6 siblings, 0 replies; 8+ messages in thread From: ro at gcc dot gnu.org @ 2022-11-07 13:15 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101392 Rainer Orth <ro at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|WAITING |NEW --- Comment #4 from Rainer Orth <ro at gcc dot gnu.org> --- When I tried the 32-bit Solaris/SPARC build again as of 20221103, I still got the same SEGV: Starting program: /var/gcc/modula-2/11.4-gcc-modula-2-g3/gcc/cc1gm2 -quiet -mcpu=v9 -fpim -fno-scaffold-main -fno-scaffold-dynamic -fno-scaffold-static -fno-m2-plugin -fdump-system-exports -c -I/vol/gcc/src/hg/master/modula-2/gcc/m2/gm2-libs -I/usr/local/lib/gcc/sparc-sun-solaris2.11/13.0.0/m2/m2pim /vol/gcc/src/hg/master/modula-2/gcc/m2/gm2-libs/SYSTEM.mod -o SYSTEM.s [Thread debugging using libthread_db enabled] [New Thread 1 (LWP 1)] SYSTEM module creates type: LOC SYSTEM module creates type: WORD SYSTEM module creates type: BYTE SYSTEM module creates type: ADDRESS SYSTEM module creates type: INTEGER8 SYSTEM module creates type: INTEGER16 SYSTEM module creates type: INTEGER32 SYSTEM module creates type: INTEGER64 SYSTEM module creates type: CARDINAL8 SYSTEM module creates type: CARDINAL16 SYSTEM module creates type: CARDINAL32 SYSTEM module creates type: CARDINAL64 SYSTEM module creates type: WORD16 SYSTEM module creates type: WORD32 SYSTEM module creates type: WORD64 SYSTEM module creates type: BITSET8 SYSTEM module creates type: BITSET16 SYSTEM module creates type: BITSET32 SYSTEM module creates type: REAL32 SYSTEM module creates type: REAL64 SYSTEM module creates type: REAL128 SYSTEM module creates type: COMPLEX32 SYSTEM module creates type: COMPLEX64 SYSTEM module creates type: COMPLEX128 SYSTEM module creates type: CSIZE_T SYSTEM module creates type: CSSIZE_T Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0xffbfe00c in ?? () (gdb) bt #0 0xffbfe00c in ?? () #1 0x00d20d1c in m2expr_BuildBinarySetDo (location=1338176, settype=<type_decl 0xfa820630 BITSET>, op1=<var_decl 0xfa856948 _T75>, op2=<var_decl 0xfa8568f0 _T74>, op3=<var_decl 0xfa856898 _T73>, binop=0xffbfe00c, is_op1lvalue=0, is_op2lvalue=0, is_op3lvalue=0, nBits=<integer_cst 0xfa839350>, unbounded=<record_type 0xfa8321e0>, varproc=<function_decl 0xfa841e80 ShiftVal>, leftproc=<function_decl 0xfa841f00 ShiftLeft>, rightproc=<function_decl 0xfa841f80 ShiftRight>) at /vol/gcc/src/hg/master/modula-2/gcc/m2/gm2-gcc/m2expr.cc:839 #2 0x00d957e0 in CodeBinarySetShift (binop=..., doOp=..., var=242, left=247, right=248, quad=248, op1=1114, op2=1113, op3=1112) at m2/gm2-compiler-boot/M2GenGCC.c:5908 #3 0x00d95910 in CodeSetShift (quad=248, op1=1114, op2=1113, op3=1112) at m2/gm2-compiler-boot/M2GenGCC.c:5929 #4 0x00d8940c in CodeStatement (q=248) at m2/gm2-compiler-boot/M2GenGCC.c:1819 #5 0x00d9f144 in M2GenGCC_ConvertQuadsToTree (Start=248, End=340) at m2/gm2-compiler-boot/M2GenGCC.c:8454 #6 0x00de2f68 in M2Scope_ForeachScopeBlockDo (sb=0x38cbdd8, p=...) at m2/gm2-compiler-boot/M2Scope.c:651 #7 0x00d720e0 in M2Code_CodeBlock (scope=163) at m2/gm2-compiler-boot/M2Code.c:511 #8 0x00d54c70 in Lists_ForeachItemInListDo (l=0x37794c8, P=...) at m2/gm2-compiler-boot/Lists.c:393 #9 0x00e0bb78 in SymbolTable_ForeachProcedureDo (Sym=42, P=...) at m2/gm2-compiler-boot/SymbolTable.c:14044 #10 0x00d722e4 in M2Code_CodeBlock (scope=42) at m2/gm2-compiler-boot/M2Code.c:543 #11 0x00d71660 in DoCodeBlock () at m2/gm2-compiler-boot/M2Code.c:274 #12 0x00d71f20 in M2Code_Code () at m2/gm2-compiler-boot/M2Code.c:474 #13 0x00d72574 in Compile (s=0x37929e8) at m2/gm2-compiler-boot/M2Comp.c:211 #14 0x00d73a84 in M2Comp_compile (filename=0xffbfeb65) at m2/gm2-compiler-boot/M2Comp.c:768 #15 0x00d3a638 in init_PerCompilationInit (filename=0xffbfeb65 "/vol/gcc/src/hg/master/modula-2/gcc/m2/gm2-libs/SYSTEM.mod") at /vol/gcc/src/hg/master/modula-2/gcc/m2/gm2-gcc/init.cc:198 #16 0x00ce1c0c in gm2_parse_input_files (filenames=0x372d698, filename_count=1) at /vol/gcc/src/hg/master/modula-2/gcc/m2/gm2-lang.cc:461 #17 0x00ce1c68 in gm2_langhook_parse_file () at /vol/gcc/src/hg/master/modula-2/gcc/m2/gm2-lang.cc:468 #18 0x019063bc in compile_file () at /vol/gcc/src/hg/master/modula-2/gcc/toplev.cc:444 #19 0x0190b1fc in do_compile (no_backend=false) at /vol/gcc/src/hg/master/modula-2/gcc/toplev.cc:2125 #20 0x0190b7c4 in toplev::main (this=0xffbfe84a, argc=15, argv=0xffbfe8b4) at /vol/gcc/src/hg/master/modula-2/gcc/toplev.cc:2277 #21 0x02e05368 in main (argc=15, argv=0xffbfe8b4) at /vol/gcc/src/hg/master/modula-2/gcc/main.cc:39 (gdb) up #1 0x00d20d1c in m2expr_BuildBinarySetDo (location=1338176, settype=<type_decl 0xfa820630 BITSET>, op1=<var_decl 0xfa856948 _T75>, op2=<var_decl 0xfa8568f0 _T74>, op3=<var_decl 0xfa856898 _T73>, binop=0xffbfe00c, is_op1lvalue=0, is_op2lvalue=0, is_op3lvalue=0, nBits=<integer_cst 0xfa839350>, unbounded=<record_type 0xfa8321e0>, varproc=<function_decl 0xfa841e80 ShiftVal>, leftproc=<function_decl 0xfa841f00 ShiftLeft>, rightproc=<function_decl 0xfa841f80 ShiftRight>) at /vol/gcc/src/hg/master/modula-2/gcc/m2/gm2-gcc/m2expr.cc:839 839 (*binop) (location, (gdb) p binop $4 = (void (*)(location_t, tree, tree, tree, tree, int)) 0xffbfe00c (gdb) x/10i binop 0xffbfe00c: unknown 0xffbfe010: unknown 0xffbfe014: unknown 0xffbfe018: lda [ %sp + %l0 ] (154), %i5 0xffbfe01c: lda [ %o4 + 0x1e0 ] %asi, %i5 0xffbfe020: lda [ %l0 ] (252), %i5 0xffbfe024: lda [ %l0 ] #ASI_BLK_PL, %i5 0xffbfe028: lda [ %l0 ] (244), %i5 0xffbfe02c: illtrap 0x146b40 0xffbfe030: illtrap 0 (gdb) ptype binop type = void (*)(location_t, tree, tree, tree, tree, int) (gdb) up #2 0x00d957e0 in CodeBinarySetShift (binop=..., doOp=..., var=242, left=247, right=248, quad=248, op1=1114, op2=1113, op3=1112) at m2/gm2-compiler-boot/M2GenGCC.c:5908 5908 m2expr_BuildBinarySetDo (location, SymbolConversion_Mod2Gcc (SymbolTable_SkipType (SymbolTable_GetType (op1))), SymbolConversion_Mod2Gcc (op1), SymbolConversion_Mod2Gcc (op2), SymbolConversion_Mod2Gcc (op3), binop, (SymbolTable_GetMode (op1)) == SymbolTable_LeftValue, (SymbolTable_GetMode (op2)) == SymbolTable_LeftValue, (SymbolTable_GetMode (op3)) == SymbolTable_LeftValue, nBits, unbounded, varproc, leftproc, rightproc); (gdb) ptype binop type = struct m2expr_BuildSetProcedure_p { m2expr_BuildSetProcedure_t proc; } (gdb) ptype m2expr_BuildSetProcedure_t type = void (*)(m2linemap_location_t, m2tree_Tree, m2tree_Tree, m2tree_Tree, m2tree_Tree, unsigned int) There's an inconsistency here, which might well explain the SEGV: * When m2expr_BuildBinarySetDo calls binop, it expects an void (*)(location_t, tree, tree, tree, tree, int) * However, in the caller (CodeBinarySetShift), binop is passed in as a struct m2expr. I suspect that m2expr_BuildBinarySetDo should instead be called with binop.proc instead. Because m2/gm2-compiler-boot/M2GenGCC.c is a generated file, I didn't try to correct this. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug modula2/101392] cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC 2021-07-09 12:34 [Bug modula2/101392] New: cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC ro at gcc dot gnu.org ` (3 preceding siblings ...) 2022-11-07 13:15 ` ro at gcc dot gnu.org @ 2022-11-09 16:30 ` gaius at gcc dot gnu.org 2022-11-10 13:01 ` ro at CeBiTec dot Uni-Bielefeld.DE 2022-11-11 10:50 ` gaius at gcc dot gnu.org 6 siblings, 0 replies; 8+ messages in thread From: gaius at gcc dot gnu.org @ 2022-11-09 16:30 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101392 --- Comment #5 from Gaius Mulley <gaius at gcc dot gnu.org> --- thanks for this excellent analysis. Here is a patch which will fix the passing of binop.proc in M2GenGCC.c. diff --git a/gcc/m2/gm2-gcc/m2expr.def b/gcc/m2/gm2-gcc/m2expr.def index 8988c78d575..e622d31d09b 100644 --- a/gcc/m2/gm2-gcc/m2expr.def +++ b/gcc/m2/gm2-gcc/m2expr.def @@ -19,7 +19,7 @@ You should have received a copy of the GNU General Public License along with GNU Modula-2; see the file COPYING3. If not see <http://www.gnu.org/licenses/>. *) -DEFINITION MODULE m2expr ; +DEFINITION MODULE FOR "C" m2expr ; FROM SYSTEM IMPORT ADDRESS ; FROM m2tree IMPORT Tree ; ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug modula2/101392] cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC 2021-07-09 12:34 [Bug modula2/101392] New: cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC ro at gcc dot gnu.org ` (4 preceding siblings ...) 2022-11-09 16:30 ` gaius at gcc dot gnu.org @ 2022-11-10 13:01 ` ro at CeBiTec dot Uni-Bielefeld.DE 2022-11-11 10:50 ` gaius at gcc dot gnu.org 6 siblings, 0 replies; 8+ messages in thread From: ro at CeBiTec dot Uni-Bielefeld.DE @ 2022-11-10 13:01 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101392 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> --- > --- Comment #5 from Gaius Mulley <gaius at gcc dot gnu.org> --- > thanks for this excellent analysis. Here is a patch which will fix the passing > of binop.proc in M2GenGCC.c. I'd tried looking into this at least once before, but didn't get anywhere then. > diff --git a/gcc/m2/gm2-gcc/m2expr.def b/gcc/m2/gm2-gcc/m2expr.def > index 8988c78d575..e622d31d09b 100644 > --- a/gcc/m2/gm2-gcc/m2expr.def > +++ b/gcc/m2/gm2-gcc/m2expr.def > @@ -19,7 +19,7 @@ You should have received a copy of the GNU General Public > License > along with GNU Modula-2; see the file COPYING3. If not see > <http://www.gnu.org/licenses/>. *) > > -DEFINITION MODULE m2expr ; > +DEFINITION MODULE FOR "C" m2expr ; > > FROM SYSTEM IMPORT ADDRESS ; > FROM m2tree IMPORT Tree ; That worked like a charm and got the build way beyond the current failure point. I later ran into PR modula2/105392 again, but that proved to be a similar issue. Thanks a lot. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug modula2/101392] cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC 2021-07-09 12:34 [Bug modula2/101392] New: cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC ro at gcc dot gnu.org ` (5 preceding siblings ...) 2022-11-10 13:01 ` ro at CeBiTec dot Uni-Bielefeld.DE @ 2022-11-11 10:50 ` gaius at gcc dot gnu.org 6 siblings, 0 replies; 8+ messages in thread From: gaius at gcc dot gnu.org @ 2022-11-11 10:50 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101392 Gaius Mulley <gaius at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Gaius Mulley <gaius at gcc dot gnu.org> --- Excellent thanks for re-testing. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-11-11 10:50 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-07-09 12:34 [Bug modula2/101392] New: cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC ro at gcc dot gnu.org 2021-09-14 10:15 ` [Bug modula2/101392] " ro at gcc dot gnu.org 2022-05-03 15:27 ` gaius at gcc dot gnu.org 2022-05-04 13:18 ` ro at CeBiTec dot Uni-Bielefeld.DE 2022-11-07 13:15 ` ro at gcc dot gnu.org 2022-11-09 16:30 ` gaius at gcc dot gnu.org 2022-11-10 13:01 ` ro at CeBiTec dot Uni-Bielefeld.DE 2022-11-11 10:50 ` gaius at gcc dot gnu.org
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).