+2004-03-01 Gabriel Dos Reis <gdr@integrable-solutions.net>
+
+ Backport from 3.4.0:
+ 2004-02-29 Mark Mitchell <mark@codesourcery.com>
+ PR debug/14328
+ * dwarf2out.c (gen_enumeration_type_die): Output all enumeration
+ constants as signed values.
+
+ 2004-01-16 J"orn Rennecke <joern.rennecke@superh.com>
+ PR optimization/11864
+ * reload1.c (reload_cse_simplify_operands): Don't remove
+ implicit extension from LOAD_EXTEND_OP.
+
2004-02-29 Hans-Peter Nilsson <hp@axis.com>
PR target/14346
link != NULL; link = TREE_CHAIN (link))
{
dw_die_ref enum_die = new_die (DW_TAG_enumerator, type_die, link);
+ tree value = TREE_VALUE (link);
add_name_attribute (enum_die,
IDENTIFIER_POINTER (TREE_PURPOSE (link)));
- if (host_integerp (TREE_VALUE (link),
- TREE_UNSIGNED (TREE_TYPE (TREE_VALUE (link)))))
- {
- if (tree_int_cst_sgn (TREE_VALUE (link)) < 0)
- add_AT_int (enum_die, DW_AT_const_value,
- tree_low_cst (TREE_VALUE (link), 0));
- else
- add_AT_unsigned (enum_die, DW_AT_const_value,
- tree_low_cst (TREE_VALUE (link), 1));
- }
+ if (host_integerp (value, TREE_UNSIGNED (TREE_TYPE (value))))
+ /* DWARF2 does not provide a way of indicating whether or
+ not enumeration constants are signed or unsigned. GDB
+ always assumes the values are signed, so we output all
+ values as if they were signed. That means that
+ enumeration constants with very large unsigned values
+ will appear to have negative values in the debugger. */
+ add_AT_int (enum_die, DW_AT_const_value,
+ tree_low_cst (value, tree_int_cst_sgn (value) > 0));
}
}
else
{
cselib_val *v;
struct elt_loc_list *l;
+ rtx op;
+ enum machine_mode mode;
CLEAR_HARD_REG_SET (equiv_regs[i]);
&& recog_data.operand_mode[i] == VOIDmode))
continue;
- v = cselib_lookup (recog_data.operand[i], recog_data.operand_mode[i], 0);
+ op = recog_data.operand[i];
+ mode = GET_MODE (op);
+#ifdef LOAD_EXTEND_OP
+ if (GET_CODE (op) == MEM
+ && GET_MODE_BITSIZE (mode) < BITS_PER_WORD
+ && LOAD_EXTEND_OP (mode) != NIL)
+ {
+ rtx set = single_set (insn);
+
+ /* We might have multiple sets, some of which do implict
+ extension. Punt on this for now. */
+ if (! set)
+ continue;
+ /* If the destination is a also MEM or a STRICT_LOW_PART, no
+ extension applies.
+ Also, if there is an explicit extension, we don't have to
+ worry about an implicit one. */
+ else if (GET_CODE (SET_DEST (set)) == MEM
+ || GET_CODE (SET_DEST (set)) == STRICT_LOW_PART
+ || GET_CODE (SET_SRC (set)) == ZERO_EXTEND
+ || GET_CODE (SET_SRC (set)) == SIGN_EXTEND)
+ ; /* Continue ordinary processing. */
+ /* If this is a straight load, make the extension explicit. */
+ else if (GET_CODE (SET_DEST (set)) == REG
+ && recog_data.n_operands == 2
+ && SET_SRC (set) == op
+ && SET_DEST (set) == recog_data.operand[1-i])
+ {
+ validate_change (insn, recog_data.operand_loc[i],
+ gen_rtx_fmt_e (LOAD_EXTEND_OP (mode),
+ word_mode, op),
+ 1);
+ validate_change (insn, recog_data.operand_loc[1-i],
+ gen_rtx_REG (word_mode, REGNO (SET_DEST (set))),
+ 1);
+ if (!apply_change_group ())
+ return 0;
+ return reload_cse_simplify_operands (insn, testreg);
+ }
+ else
+ /* ??? There might be arithmetic operations with memory that are
+ safe to optimize, but is it worth the trouble? */
+ continue;
+ }
+#endif /* LOAD_EXTEND_OP */
+ v = cselib_lookup (op, recog_data.operand_mode[i], 0);
if (! v)
continue;