This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

expand_expr sign extension problem.


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]