------- Comment #9 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2006-05-04 14:56 ------- Subject: Re: [4.1/4.2 Regression] Unable to determine # of iterations for a simple loop
> Wording of 6.5.6/8 and /9 suggests that array objects larger than the maximum > value that fits in ptrdiff_t (which needs to be signed) invoke undefined > behavior, > not last because of "the expression ((Q)+1)-(P) has the same value as > ((Q)-(P))+1 and as -((P)-((Q)+1))" and "The size of the result is > implementation-defined, > and its type (a signed integer type) is ptrdiff_t defined in the <stddef.h> > header. If the result is not representable in an object of that type, the > behavior is undefined." However, this only concerns difference of pointers. In particular, the way semantics of comparison of pointers is defined in 6.5.8/5 does make no reference to the difference of pointers, and it is well defined even for objects whose size does not fit into ptrdiff_t. Gcc actually does not allow arrays whose size does not fit into ptrdiff_t, so the problem might only appear for malloc-ated objects. But perhaps it is allowed to actually not support such large objects; I think we should just submit patch for the transformation as described below, and let someone with better knowledge of the standards decide whether this is correct or not. > So for this reason I believe that folding > > PTR +- CST CMP PTR +- CST > > (with CST being of pointer type, as represented by the middle-end) as > > +- (ptrdiff_t)CST CMP +- (ptrdiff_t)CST > > is valid. Now the intel compiler f.i. does _not_ do this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27039
