g++ bug compiling exceptions

Peter Lawrence Peter.Lawrence@Eng.Sun.COM
Tue Apr 11 16:25:00 GMT 2000


Guys and Gals,
              g++ bug in both gcc-2.8.1 and gcc-2.95.1,

platform: any when compiling with -fsjlj-exceptions

test source code: Perennial CCVS Sec6/4_1/R06141.C


the bug is in the last line of start_dynamic_cleanup() and also
start_dynamic_handler() in gcc/except.c (not the one in cp subdirectory)
here is ..._cleanup:


<	  /* Update the cleanup chain.  */
<
<	  emit_move_insn (dcc, XEXP (buf, 0));
<	}


this needs to be changed to



>	  /* Update the cleanup chain.  */
>
>	  emit_move_insn (dcc, force_operand (XEXP (buf,0), NULL));
                               ^^^^^^^^^^^^^
>	}


Also must make the same change at the end of start_dynamic_handler().





the reason this change is necessary is that (XEXP (buf, 0)) comes from
a call to assign_stack_local which can return an arbitrary address
expression, not just a REG, for example:

	(plus:SI (reg:SI 237)
	    (const_int 64))

which is not a valid operand for gen_movsi() which is eventually invoked
from emit_move_insn(). The valid operands for a movsi are "general_operand"
which is REG, MEM, or CONST*, but not a PLUS.

They were asking the "move" template to generate code for an "add"
instruction, this is not allowed in the overall scheme of things in
gcc.

The function force_operand exists just for this purpose.

                ---------------------------------------------


I tryed adding the following consistency check to the top of emit_move_insn_1
to catch these sorts of errors, but I got so many running Perennial that 
I've not sorted them all out yet. I hope that someone at GNU or Cygnus/Redhat
does the same:

< if (mov_optab->handlers[(int) mode].insn_code != CODE_FOR_nothing)
<    return
<      emit_insn (GEN_FCN (mov_optab->handlers[(int) mode].insn_code) (x, y));

changes into:

> if ((icode= mov_optab->handlers[(int) mode].insn_code) != CODE_FOR_nothing)
>   {
>#ifdef CONSISTENCY_CHECKING
>     if ( ! reload_in_progress &&
>          (   ! (*insn_operand_predicate[icode][0])(x, mode)       /*PAL*/
>           || ! (*insn_operand_predicate[icode][1])(y, mode)))
>       abort();
>#endif
>     return
>       emit_insn (GEN_FCN (mov_optab->handlers[(int) mode].insn_code) (x, y));
>   }

I had to add the "!reload_in_progress" to get some things to compile for
reasons that I don't yet want to spend the time to investigate, so I don't 
know if this was a legitimate consistency violation or not. (is "legitimate 
violatition" an oxymoron or what?)


-Pete Lawrence,   peter.lawrence@eng.sun.com


More information about the Gcc-bugs mailing list