From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18580 invoked by alias); 28 Oct 2015 00:12:39 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 18526 invoked by uid 55); 28 Oct 2015 00:12:35 -0000 From: "joseph at codesourcery dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/67999] Wrong optimization of pointer comparisons Date: Wed, 28 Oct 2015 00:12:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 5.2.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: joseph at codesourcery dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-10/txt/msg02299.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999 --- Comment #22 from joseph at codesourcery dot com --- On Tue, 27 Oct 2015, ch3root at openwall dot com wrote: > What is missing in the discussion is a cost of support in gcc of objects > with size > PTRDIFF_MAX. I guess overhead in compiled code would be > minimal while headache in gcc itself is noticable. But I could be wrong. I think the biggest overhead would include that every single pointer subtraction, where the target type is (or might be, in the case or VLAs) larger than one byte, would either need to have conditional code for what order the pointers are in, or would need to extend to a wider type, subtract in that type, divide in that type and then reduce to ptrdiff_t; it would no longer be possible to do (ptrdiff_t subtraction, then EXACT_DIV_EXPR on ptrdiff_t). There would be other things, such as pointer addition / subtraction of integers needing to handle values outside the range of ptrdiff_t, but it's pointer subtraction that I expect would have the main runtime overhead. (On strict alignment targets, for naturally-aligned power-of-two element sizes, you could do logical shifts on the pointers before doing a signed subtraction, so that case needn't be quite as inefficient as the general case.)