This is the mail archive of the gcc-patches@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]
Other format: [Raw text]

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.


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