[Bug tree-optimization/27039] [4.1/4.2 Regression] Unable to determine # of iterations for a simple loop

["rakdver at atrey dot karlin dot mff dot cuni dot cz" <gcc-bugzilla at gcc dot gnu dot org>]

------- 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