expand_expr sign extension problem.
Robert Lipe
robertl@sco.com
Wed Apr 12 14:22:00 GMT 2000
I've been stuck at the city limits of bootstrapsville on OpenServer for
about a month. I hav finally had a chance to dig into it.
When built with the native compiler on OpenServer, I gcc aborts:
/play/egcs/gcc/libgcc2.c: In function `__gcc_bcmp':
/play/egcs/gcc/libgcc2.c:1063: Internal compiler error in `?', at toplev.c:1556
Please submit a full bug report.
The fourth time expand_expr is called, we get into trouble. Somehow,
in all the casting and preprocessing, the sign on the tree_code gets
flipped around and we end up falling into the "default" in the swtich
(which calls do_abort) instead of the handler for POSTINCREMENT_EXPR
which was the clear intent.
Breakpoint 4, expand_expr (exp=0x801b9500, target=0x0, tmode=VOIDmode,
modifier=EXPAND_SUM) at /play/egcs/gcc/expr.c:5674
5674 tree type = TREE_TYPE (exp);
(gdb) s
5675 int unsignedp = TREE_UNSIGNED (type);
(gdb)
5677 register enum tree_code code = TREE_CODE (exp);
(gdb)
5686 if (TREE_CODE (exp) == ERROR_MARK)
(gdb) p code
$1 = -128
(gdb) p exp->common.code
$2 = POSTINCREMENT_EXPR
(gdb) p (int) exp->common.code
$3 = 128
(gdb) p (int) code
$4 = -128
I tried the "obvious" thing of makine TREE_SET_CODE cast to an enum
tree_code instead of an "int" (which could be signed or unsigned) but
it brought no joy.
I think it looks right in the exp:
(gdb) p exp->common
$2 = {chain = 0x0, type = 0x80191500, code = POSTINCREMENT_EXPR,
side_effects_flag = 1, constant_flag = 0, permanent_flag = 0,
addressable_flag = 0, volatile_flag = 0, readonly_flag = 0,
unsigned_flag = 0, asm_written_flag = 0, used_flag = 0, nothrow_flag = 0,
static_flag = 1, public_flag = 0, private_flag = 0, protected_flag = 0,
lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0,
lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0}
So, in all the vagaries of ISO C's signed and unsigned and enum, can
anyone spot why this is being sign extended?
The addition of
if (code < 0) code = -code;
before any use of code in that function allows the C compiler to get
further. It still ICEs during stage2 in dwarfout.c and and tree.c
so perhaps this is the wrong tip of the iceburg.
Thanx,
RJL
More information about the Gcc
mailing list