From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20657 invoked by alias); 4 May 2006 14:56:37 -0000 Received: (qmail 20402 invoked by alias); 4 May 2006 14:56:19 -0000 Date: Thu, 04 May 2006 14:56:00 -0000 Message-ID: <20060504145619.20400.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/27039] [4.1/4.2 Regression] Unable to determine # of iterations for a simple loop In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "rakdver at atrey dot karlin dot mff dot cuni dot cz" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-05/txt/msg00370.txt.bz2 List-Id: ------- 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 > 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