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).