[Bug c/67999] Wrong optimization of pointer comparisons

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999

--- Comment #22 from joseph at codesourcery dot com <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.)