[IRIX 6/Solaris 7] ICE in emit_move_insn_1()

[IRIX 6/Solaris 7] ICE in emit_move_insn_1()

[Rainer Orth]

I'm currently trying to debug the last problem with returning PARALLEL's
from function_arg() for the N32/N64 ABIs on IRIX 6 to finally fix the
non-ABI conformant structure passing conventions.

The following test causes cc1plus to abort in emit_move_insn_1():

struct empty {};

void efunc (empty);

void test ()
{
  empty e;
  efunc (e);
}

This is gcc version gcc-2.95 19990623 (prerelease) with the lastest expr.c
and a slightly updated version of my patch to activate returning PARALLEL's
from function_arg():

	http://egcs.cygnus.com/ml/egcs-patches/1999-06/msg00621.html

./xgcc -B./ -v -S tlist.ii
Reading specs from ./specs
gcc version gcc-2.95 19990623 (prerelease)
 ./cc1plus tlist.ii -quiet -version -o tlist.s
GNU C++ version gcc-2.95 19990623 (prerelease) (mips-sgi-irix6.2) compiled by GNU C version gcc-2.95 19990623 (prerelease).
tlist.ii: In function `void test()':
tlist.ii:8: Internal compiler error in `emit_move_insn_1', at expr.c:2754
Please submit a full bug report to `egcs-bugs@egcs.cygnus.com'.
See <URL: http://egcs.cygnus.com/faq.html#bugreport > for details.

The same failure occurs with an unmodified 64-bit Solaris 7 cc1plus:

./xgcc -B./ -v -m64 -S tlist.ii
Reading specs from ./specs
gcc version gcc-2.95 19990623 (prerelease)
 ./cc1plus tlist.ii -mptr64 -mcpu=v9 -mstack-bias -mno-v8plus -quiet -m64 -version -o tlist.s
GNU C++ version gcc-2.95 19990623 (prerelease) (sparc-sun-solaris2.7) compiled by GNU C version gcc-2.95 19990623 (prerelease).
tlist.ii: In function `void test()':
tlist.ii:8: Internal compiler error in `emit_move_insn_1', at expr.c:2698
Please submit a full bug report to `egcs-bugs@egcs.cygnus.com'.
See <URL: http://egcs.cygnus.com/faq.html#bugreport > for details.

What I've found out is that emit_group_load(dst, orig_src, align, size) is
called with

  dst = (parallel:QI[ 
        (expr_list (reg:DI 8 t0)
            (const_int 0 [0x0]))
    ] )

  orig_src = (const_int 0 [0x0])

  align = 1
  ssize = 1

The code enters the following test in emit_group_load()

  src = orig_src;
  if (GET_CODE (src) != MEM)
    {
      src = gen_reg_rtx (GET_MODE (orig_src));
      emit_move_insn (src, orig_src);
    }

calling emit_move_insn() and finally emit_move_insn_1() with

  x = (reg 82)
  y = (const_int 0 [0x0])

which aborts.

Any advice on how to fix this?

	Rainer
>From mrs@wrs.com Wed Jun 30 16:12:00 1999
From: mrs@wrs.com (Mike Stump)
To: alter@cybercafe.com.ua, egcs-bugs@egcs.cygnus.com
Subject: Re: Bug. "else if"
Date: Wed, 30 Jun 1999 16:12:00 -0000
Message-id: <199906302312.QAA23267@kankakee.wrs.com>
X-SW-Source: 1999-06/msg01034.html
Content-length: 566

> Date: Thu, 01 Jul 1999 01:19:39 +0000
> From: Alter Native <alter@cybercafe.com.ua>

> I wrote a report yet.

> First I want to say that I sent you file with few comments lines which
> beging as "\\" (must be "//"), sorry.  :)

I didn't see any other bug reports by you.  I haven't seen any
testcases, so there is little that we can say about the problem.

> It means that it not my mistake in code, it's your mistake in gcc.

We welcome bug reports, but bug reports must contain testcases.  If
you want the problem addressed, you will have to provide a testcase.
>From chadj2@yahoo.com Wed Jun 30 16:35:00 1999
From: Chad Juliano <chadj2@yahoo.com>
To: egcs-bugs@egcs.cygnus.com
Subject: Template auto instantiation
Date: Wed, 30 Jun 1999 16:35:00 -0000
Message-id: <19990630233534.11066.rocketmail@web604.mail.yahoo.com>
X-SW-Source: 1999-06/msg01035.html
Content-length: 1152

I have a proposal for the todo list.

The Solaris, IRIX, and probably other compilers do not have a need for
the '#pragma  implementation' and '#pragma interface' directives for
their instantiation of templates. The implimentations vary but IRIX,
for example, keeps database in the working directory containing the
locations of templates it encountered during compilation. After
compiling the objects but before creating an archive or executable, it
runs a prelinker 'edg_prelink' on all the object files. The prelinker
searches for unresolved references to templates and compiles them into
additional object files which get linked or added to the archive. This
guanantees that there are no duplicate instantiaions.

A solution like this would allow for external templates while avoiding
the proprietary gcc #pragmas.

---------------------------------------------------
Chad Juliano * cjulian@gar.esys.com * 972-205-9781
Software Engineer * Raytheon Systems Company
---------------------------------------------------

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: [IRIX 6/Solaris 7] ICE in emit_move_insn_1()

[Alexandre Oliva]

On Jun 30, 1999, Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> wrote:

> The following test causes cc1plus to abort in emit_move_insn_1():

> struct empty {};
> void efunc (empty);
> void test () { empty e; efunc (e); }

> tlist.ii:8: Internal compiler error in `emit_move_insn_1', at expr.c:2754

I couldn't reproduce this with the latest snapshot + Jeff's patch for
expr.c on IRIX 6.3.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: [IRIX 6/Solaris 7] ICE in emit_move_insn_1()

[Rainer Orth]

> On Jun 30, 1999, Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> wrote:
> 
> > The following test causes cc1plus to abort in emit_move_insn_1():
> 
> > struct empty {};
> > void efunc (empty);
> > void test () { empty e; efunc (e); }
> 
> > tlist.ii:8: Internal compiler error in `emit_move_insn_1', at expr.c:2754
> 
> I couldn't reproduce this with the latest snapshot + Jeff's patch for
> expr.c on IRIX 6.3.

as I mentioned in my report, this happens only with my patch to activate
returning PARALLEL's from function_arg():

	http://egcs.cygnus.com/ml/egcs-patches/1999-06/msg00621.html

Since the same failure occurs with an unmodified sparcv9-sun-solaris2.7 gcc
(only tried with a bi-arch sparc-sun-solaris2.7 gcc with -m64), which uses
the same PARALLEL support from emit_group_load/emit_group_store, it's
likely that the problem lies there and not in my patch.  I currently don't
know enough about gcc internals and so am looking for guidance on where to
look further/how to fix the problem.

	Rainer
>From joerg.pietschmann@zkb.ch Fri Jul 02 04:38:00 1999
From: Joerg Pietschmann <joerg.pietschmann@zkb.ch>
To: egcs-bugs <egcs-bugs@egcs.cygnus.com>
Subject: Re: emacs build failed using egcs
Date: Fri, 02 Jul 1999 04:38:00 -0000
Message-id: <377CA515.9D30D316@zkb.ch>
X-SW-Source: 1999-07/msg00079.html
Content-length: 2366

Sorry for the incomplete report some hours ago. I got the precise
error wrong, too.

On powerpc-ibm-aix4.2.1.0, the dumped emacs-20.3 gets an SIGSEGV
during startup if compiled with egcs-19990629. It works fine if
compiled with the native cc. The undumped emacs (temacs) works also
regardless of the compiler used.

The problem is somewhere in the startup code:

t384@neptun:...acs-20.3/src>gdb emacs                   
[snip gdb stuff]
(gdb) r
Starting program: /home/lis5p/t384/gnu/unpack/emacs-20.3/src/emacs -geometry 80x40+0+0
Program received signal SIGSEGV, Segmentation fault.
0x10000150 in __start ()
(gdb) bt
#0  0x10000150 in __start ()
#1  0xdeadbeef in ?? () from (unknown load module)
(gdb) disass   
Dump of assembler code for function __start:
0x10000150 <__start>:   stw     r3,0(r2)
0x10000154 <__start+4>: stw     r4,4(r2)
0x10000158 <__start+8>: cmpw    r30,r31
[snip rest of disassembly]
(gdb) info regs
Undefined info command: "regs".  Try "help info".
(gdb) info reg 
r0             0xdeadbeef       -559038737
r1             0x2ff21de0       804396512
r2             0x15023  86051
r3             0x3      3
r4             0x2ff21e28       804396584
r5             0x2ff21e38       804396600
r6             0xdeadbeef       -559038737
[snip more 0xdeadbeef]

The problem is obviously the content of the r2 register.
Temacs shows somewhat different values 8the code after __start is
the same as above):

(gdb) b *0x10000154
Breakpoint 3 at 0x10000154
(gdb) r
Starting program: /home/lis5p/t384/gnu/unpack/emacs-20.3/src/temacs -geometry 80x40+0+0
Breakpoint 3, 0x10000154 in __start ()
(gdb) info reg
r0             0xdeadbeef       -559038737
r1             0x2ff21dd0       804396496
r2             0x200962e0       537486048
r3             0x3      3
r4             0x2ff21e20       804396576
r5             0x2ff21e30       804396592
r6             0xdeadbeef       -559038737
...

I'm not familar enough with the powerpc architecture to track this
further.

Regards

J.Pietschmann
-- 

----------------------------------------------------------------------
Zuercher Kantonalbank ZKB        Internet : joerg.pietschmann@zkb.ch
Neue Hard 9                      Telefon  : ++41 01-275 85 03 
Postfach                         Fax      : ++41 01-275 80 34
CH-8010 Zuerich
----------------------------------------------------------------------
>From law@cygnus.com Fri Jul 02 04:45:00 1999
From: Jeffrey A Law <law@cygnus.com>
To: Nathan Field <nathan@cs.hmc.edu>
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: Build of snapshots failed on Solaris 2.6 
Date: Fri, 02 Jul 1999 04:45:00 -0000
Message-id: <1669.930915839@upchuck.cygnus.com>
References: <Pine.GSO.4.10.9907010639420.23506-100000@turing.cs.hmc.edu>
X-SW-Source: 1999-07/msg00080.html
Content-length: 936

  In message < Pine.GSO.4.10.9907010639420.23506-100000@turing.cs.hmc.edu >you wr
  > (gdb) s
  > type_from_format (c=101) at ../../egcs-19990623/gcc/gengenrtl.c:62
  > 62        switch (c)
  > (gdb) p c
  > $4 = 101
OK.  101 is a reasonable for that variable.  So we're OK at this point.

  > (gdb) s
  >
  > Program received signal SIGSEGV, Segmentation fault.
  > 0x9de3bf90 in ?? ()
OK.  Note the wacked out address 0x9de3bf90.  Typically a switch statement
has an indirect jump.  This failure would tend to make me think that we used
a totally bogus value for that indirect jump.

To verify this you should get into type_from_format then do something like

display/i $pc
stepi

And continue with the stepi until you see the current PC address go somewhere
totally bogus like 0x9xxxxxxx.

Mail the output to the list -- it'll be obvious to folks that know sparc
assembler whether or not we got a bogus address for the jump.


jeff