🚀 go-pugleaf

I usually make it a point to never hand edit reply addresses, because
it is a waste of my time.  I will, to let you know it is, because I
think it is important for you to realize what a pain it is.

I consultant worth anything can fix the problem within hours.

Plus, even if management or the computer center or whoever is in
charge does not want to, many mail front ends have a way of setting
the reply-to: field to ANYTHING the USER wants to set it to.

Anyway, on to the normal stuff now...

In the future please report all g++ bugs to the
	bug-g++@prep.ai.mit.edu
list, thanks.  If they are back end bugs, they can be reported here,
but please let us know if you think the problem is in the back end.

This problem should not exist in the next release of gcc.

Here is a patch that should solve your problem:
--------------
Doing diffs in cp-tree.c.~1~:
*** cp-tree.c.~1~	Tue May 26 15:29:15 1992
--- cp-tree.c	Fri Jun 12 10:22:56 1992
*************** break_out_calls (exp)
*** 212,218 ****
  
      case 'e':  /* a expression */
      case 's':  /* an expression with side effects */
!       for (i = tree_code_length[(int) code]; i >= 0; i--)
  	{
  	  t1 = break_out_calls (TREE_OPERAND (exp, i));
  	  if (t1 != TREE_OPERAND (exp, i))
--- 212,218 ----
  
      case 'e':  /* a expression */
      case 's':  /* an expression with side effects */
!       for (i = tree_code_length[(int) code] - 1; i >= 0; i--)
  	{
  	  t1 = break_out_calls (TREE_OPERAND (exp, i));
  	  if (t1 != TREE_OPERAND (exp, i))


> Message-Id: <9206220856.AA16201@aeneas.MIT.EDU>
> Date:           Mon, 22 Jun 92   9:51 GMT
> From: Anthony Heading <"LISZT::heading%hermes.mod.uk"@relay.mod.uk>
> To: bug-gcc@prep.ai.mit.edu

> Please find below details of what I'm pretty sure is a bug, as
> requested in info...

> * version:  gcc version 2.2.2
>             ftp'd directly from prep.ai.mit.edu on 18th June 1992

> * a complete input file

> --------- START OF INPUT FILE - called "mlp.C" on my machine -------------

> typedef enum {
>   apple,banana
> } fruit_t;

> float f(double);
> extern float x;

> void proc(float *w)
> {
>   int n=0;
>   fruit_t fruit;

>   for(n=4;n;n--){
>     fruit= apple;
>     *w++= (fruit==apple)?1/(1+f(0.0)):
> 		   (fruit==banana)?f(1.1):0;
>   }
>   *w++ = (fruit==apple)?(x-1)*x*(1-x):
>             (fruit==banana)?(x-1):0;
>   return;
> }

> ---------- END OF INPUT FILE ---------------------

> * command:  gcc -c mlp.C
>             The bug only appears if above program is compiled as c++

> * machine: Decstation 3100, running Ultrix 4.2 unmodified

> * configure: decstation-ultix4.2

> * modifications: none

> * deviations from input procedure: none
>           (though I didn't make the stage 2 compiler)

> * description: "gcc: Internal compiler error: program cc1plus got fatal signal 4"
>     (With slight modifications to the input program, I can also cause signal 11
>      to be generated.)

> * debug info: I'm not really sure what you'd like here - I guess you
>   can probably regenerate the effect anyhow.

>   Some details are:

> (dbx) where
> >  0 abort.abort(0xc2, 0x7fffb67c, 0x47adc8, 0x1004f31c, 0x3) ["../atoi.c":49, 0x55bc8c]
>    1 break_out_calls(exp = 0x1004f2c8) ["cp-tree.c":207, 0x42daa4]
>    2 break_out_calls(exp = 0x1004f310) ["cp-tree.c":217, 0x42dad4]
>    3 break_out_calls(exp = 0x1004f330) ["cp-tree.c":234, 0x42db58]
>    4 .block844 ["cp-typeck.c":5157, 0x428370]
>    5 build_modify_expr(lhs = 0x1004f330, modifycode = NOP_EXPR, rhs = 0x1004f2f0) ["cp-typeck.c":5157, 0x428370]
>    6 .block82 ["bison.simple":1205, 0x401c6c]
>    7 .block81 ["bison.simple":1205, 0x401c6c]
>    8 yyparse() ["bison.simple":1205, 0x401c6c]
>    9 .block2537 ["toplev.c":1638, 0x4744e8]
>   10 compile_file(name = 0x7fffbada = "/usr/tmp/cca22282.i") ["toplev.c":1638, 0x4744e8]
>   11 .block2631 ["toplev.c":3055, 0x477228]
>   12 .block2623 ["toplev.c":3055, 0x477228]
>   13 main(argc = 7, argv = 0x7fffba34, envp = 0x2) ["toplev.c":3055, 0x477228]

> (dbx) up
> (dbx) list 200              This is the function break_out_calls()
>    200      return copy_node (exp);
>    201
>    202    switch (TREE_CODE_CLASS (code))
>    203      {
>    204      case 'x':  /* something random, like an identifier.  */
>    205      case 't':  /* a type node */
>    206      default:
>  * 207        abort ();
>    208
>    209      case 'c':  /* a constant */
> >  210      case 'd':  /* A decl node */
>    211        return exp;

> (dbx) print code
> ERROR_MARK          After other crashes this has also been REAL_TYPE

> "tree.h" contains
>     #define TREE_CODE_CLASS(CODE)   (*tree_code_type[(int) (CODE)])

> (dbx) print tree_code_type[(int) code]
> 0x10036f50 = "x"

> Hence this calls abort. This seems rather messy.

> Hope this is of some help. I'm afraid I don't read the news groups
> and am not on any mailing lists, so if you could let me know the
> outcome I'd be grateful...