C provenance semantics proposal

[Jens Gustedt]

Hello Jakub,

On Fri, 19 Apr 2019 11:34:33 +0200 Jakub Jelinek <jakub@redhat.com>
wrote:

> On Fri, Apr 19, 2019 at 11:09:27AM +0200, Jens Gustedt wrote:
> > > similarly, if one of the
> > > pointers is &object or &object + sizeof (object).  
> > 
> > Here I don't follow. Why would one waste brain and ressources to
> > optimize code that does such tricks?  
> 
> What tricks?

&object + sizeof (object)

> A normal pointer comparison either of two pointers
> or a pointer and address of something is something that happens in
> real-world code all the time, and in many cases it is essential
> that optimizing compilers attempt to optimize such tests as much as
> possible.

Yes, but not if one of the addresses is a one-passed pointer, this is
a marginal use case.

> In the http://gcc.gnu.org/PR88775 (yes, it is C++, not C, but I don't
> see significant differences there),

Hm, probably my C++ is a bit rusty, but I see huge differences
here. What understand is that you have difficulties for some C++ code
that uses `operator=` overloading (instead of initialization) to
optimize that assignment. I see a lot of difficulties here, of which
some are common for C and C++ (the lack of proper treatement of string
literals as constants, for example) to purely C++ difficulties, e.g
not being able to model `restrict` pointer arguments, and to deal with
possible (or impossible) aliasing between a just created object and a
string literal.

So, I see a whole chain of reasoning breaking down with that code, but
nothing that convinces me that `operator==` for pointer types is the
culprit. The wrong is probably already done when it comes to it.


Jens

-- 
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: Digitale Signatur von OpenPGP
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20190421/e408dee9/attachment.sig>