[Bug tree-optimization/85315] missed range optimisation opportunity for derefences where index must be 0 or otherwise constrained

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 10 Apr 2018, msebor at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
> 
> --- Comment #5 from Martin Sebor <msebor at gcc dot gnu.org> ---
> (In reply to rguenther@suse.de from comment #4)
> ...
> > If you eventually expect a true result then please no - this should be
> > undefined.
> 
> The second test case in comment #4 is currently well-defined in C17 (by 6.5.9,
> p6) and requires the function to return true if x and y are adjacent and i is
> +/-1.  (I'm not defending the requirement.)
> 
> There is a proposal for C2X to make the result of the equality comparison
> between a past-the-end pointer and another pointer unspecified instead (N2219).
>  Would you prefer it to be undefined?  (Making it undefined would be a rather
> drastic departure from the historical requirement and likely objectionable to
> the authors.)

Yes, it should be undefined.  GCC treats it as undefined at the moment
because otherwise points-to analysis cannot be used to optimize pointer
equality tests at all which would be a major showstopper.

Also consider the following:

int main()
{
  int a, b = 0;
  int *p = &a+1;
  if (p == &b)
    *p = 1;
  return b;
}

is that now valid and required to return 1 if b appens to be adjacent
to a?  points-to says p points to a and thus cannot be used to modify
b.  And IIRC *(&a+1) isn't valid but if &a+1 == &b isn't undefined
but is required to return true if they are adjacent what sense does
it make to _not_ allow a pointer that is equal to &b to access b?

> See http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2219.htm
> (Scroll down to the Proposed Technical Corrigendum section at the end of the
> paper to read the proposed changes.)

It's not clear to me how "happens to immediately follow the first array 
object in the address space" not always contradicts "single provenance".
&a+1 and &b have different provenance, no?

Given GCC has leeway to pad declarations an implementation could
choose to always pad variables by at least one byte and thus
never making "happens to immediately follow the first array object in the 
address space" true?

What's the intended use of that special case?  Is it to make the
access via p above valid?  If not how is it useful to allow this
kind of comparison?  Users can always go via [u]intptr_t if they
want to compare pointers of different "provenance" so why's it
necessary to add an ability to do so without???  That just
needessly complicates implementations IMHO.

So that -f[no-]provenance stuff is bollocks IMHO, whoever invented
it must be making sth up on a sheet of paper rather than addressing
a real problem.