[Bug modula2/101392] New: cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC

[Bug modula2/101392] New: cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC

[ro at gcc dot gnu.org]

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.

[Bug modula2/101392] cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC

[ro at gcc dot gnu.org]

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.

[Bug modula2/101392] cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC

[gaius at gcc dot gnu.org]

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.

[Bug modula2/101392] cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC

[ro at CeBiTec dot Uni-Bielefeld.DE]

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.

[Bug modula2/101392] cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC

[ro at gcc dot gnu.org]

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.

[Bug modula2/101392] cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC

[gaius at gcc dot gnu.org]

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 ;

[Bug modula2/101392] cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC

[ro at CeBiTec dot Uni-Bielefeld.DE]

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.

[Bug modula2/101392] cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC

[gaius at gcc dot gnu.org]

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.