This is the mail archive of the
mailing list for the GCC project.
Re: c enable-checking failure
- To: law at cygnus dot com
- Subject: Re: c enable-checking failure
- From: Jim Wilson <wilson at cygnus dot com>
- Date: Tue, 07 Jul 1998 13:29:57 -0700
- cc: Richard Henderson <rth at cygnus dot com>, egcs-patches at cygnus dot com
> The exact situation was a NOP to the same integer type, so one
> might wonder if fold isn't supposed to take care of that.
Good question. Or maybe it's stripped out during tree->rtl conversion.
The NOP_EXPRs are deliberately added so that we can tell the difference between
a constant, and an expression that was reduced to a constant. This is needed
to correctly handle C null pointer constants, which must be an integral
constant expression. Ideally, there should be a NOP_EXPR at the end if and
only if the original expression was not an integral constant expression. It is
possible though that we are adding the NOP_EXPRs when they aren't strictly
necessary. The NOP_EXPRs are added by non_lvalue, but the rules for lvalues
aren't the same as the rules for integral constant expressions, so this does
look wrong. I suspect this NOP_EXPR/null pointer constant code has bit rotted,
perhaps to the point where it isn't useful anymore.
Meanwhile, it is funny that you got a NOP_EXPR back from fold. I would suspect
there is something wrong with one of the arguments, since fold should return
a INTEGER_CST if passed in two INTEGER_CSTs. Perhaps there are some type
conversion operators in there which confused fold into thinking that the
input values weren't constants. Maybe there is a missing fold call somewhere?
Or maybe the type (index_type) doesn't match the type of the operands? There
may be some other way to fix this, and if so, that is probably better than
trying to strip off nops after the fact.