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