This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR34099, wrong-code with CCP
On Fri, 16 Nov 2007, Joseph S. Myers wrote:
> On Fri, 16 Nov 2007, Richard Guenther wrote:
>
> > + case MULT_EXPR:
> > + case TRUNC_DIV_EXPR:
> > + case CEIL_DIV_EXPR:
> > + case FLOOR_DIV_EXPR:
> > + case ROUND_DIV_EXPR:
> > + case TRUNC_MOD_EXPR:
> > + case CEIL_MOD_EXPR:
> > + case FLOOR_MOD_EXPR:
> > + case ROUND_MOD_EXPR:
> > + case EQ_EXPR:
> > + case NE_EXPR:
> > + case LT_EXPR:
> > + case GT_EXPR:
> > + /* Not MIN_EXPR, MAX_EXPR. One VARYING operand may be selected.
> > + Not bitwise operators, one VARYING operand may specify the
> > + result completely. Not logical operators for the same reason.
> > + Not LE/GE comparisons or unordered comparisons. Not
> > + COMPLEX_EXPR as one VARYING operand makes the result partly
> > + not UNDEFINED. */
>
> x * 0 and x % 1 are always 0 (for integer x). Comparisons may be always 0
> or always 1 for one operand outside the range of the unsigned char from
> which the original operand was promoted; likewise the results of
> divisions, or shifts.
Right. That'll shrink down the list to nearly zero operands. Unless
we start to tell apart which of the operands is undefined. I'll do a
followup patch.
> (Exactly what is or is not undefined behavior in the presence of
> uninitialized values is the subject of DR#338
> <http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_338.htm>. DR#260 was
> an earlier DR concerning related issues.)
Interesting read ;)
Thanks,
Richard.