On 05/18/2018 10:12 AM, Jakub Jelinek wrote:
Or is it invalid to dereference s before it has been constructed?
Yes, Marc found:
"During the construction of an object, if the value of the object or any
of its subobjects is accessed through a glvalue that is not obtained,
directly or indirect
On Fri, May 18, 2018 at 09:57:42AM -0400, Jason Merrill wrote:
> > But what is invalid on:
> > struct S { int foo (S *); int a; } s { 2 };
> > int S::foo (S *x)
> > {
> > int b = this->a;
> > x->a = 5;
> > b += this->a;
> > return b;
> > }
> > int main ()
> > {
> > if (s.foo (&s) != 7)
>
On 05/18/2018 09:21 AM, Marc Glisse wrote:
what about comparisons to this? I thought restrict implied such a
comparison was 'never the same'?
ie. if the ctor was:
selfie (selfie *ptr) : me (ptr==this ? 0 : ptr) {}
It is tempting to think so, but I don't see any language to that effect.
O
On Fri, 18 May 2018, Jakub Jelinek wrote:
On Fri, May 18, 2018 at 09:02:08AM -0400, Nathan Sidwell wrote:
On 05/18/2018 08:53 AM, Marc Glisse wrote:
As long as you do not dereference ptr in the constructor, that shouldn't
contradict 'restrict'. The PR gives this quote from the standard:
"Dur
On Fri, May 18, 2018 at 9:53 AM, Jakub Jelinek wrote:
> On Fri, May 18, 2018 at 09:02:08AM -0400, Nathan Sidwell wrote:
>> On 05/18/2018 08:53 AM, Marc Glisse wrote:
>>
>> > As long as you do not dereference ptr in the constructor, that shouldn't
>> > contradict 'restrict'. The PR gives this quote
On Fri, May 18, 2018 at 09:02:08AM -0400, Nathan Sidwell wrote:
> On 05/18/2018 08:53 AM, Marc Glisse wrote:
>
> > As long as you do not dereference ptr in the constructor, that shouldn't
> > contradict 'restrict'. The PR gives this quote from the standard:
> >
> > "During the construction of an
On Fri, May 18, 2018 at 8:34 AM, Marc Glisse wrote:
> On Fri, 18 May 2018, Richard Biener wrote:
>> On Fri, May 18, 2018 at 2:25 PM Marc Glisse wrote:
>>
>>> this lets alias analysis handle the implicit 'this' parameter in C++
>>> constructors as if it was restrict.
>>
>> OK. Please give C++ fol
On Fri, 18 May 2018, Nathan Sidwell wrote:
On 05/18/2018 08:53 AM, Marc Glisse wrote:
As long as you do not dereference ptr in the constructor, that shouldn't
contradict 'restrict'. The PR gives this quote from the standard:
"During the construction of an object, if the value of the object o
On 05/18/2018 08:53 AM, Marc Glisse wrote:
As long as you do not dereference ptr in the constructor, that shouldn't
contradict 'restrict'. The PR gives this quote from the standard:
"During the construction of an object, if the value of the object or any
of its subobjects is accessed through
On Fri, 18 May 2018, Nathan Sidwell wrote:
On 05/18/2018 08:34 AM, Marc Glisse wrote:
(Cc: said C++ folks)
On Fri, 18 May 2018, Richard Biener wrote:
On Fri, May 18, 2018 at 2:25 PM Marc Glisse wrote:
Hello,
this lets alias analysis handle the implicit 'this' parameter in C++
construct
On 05/18/2018 08:34 AM, Marc Glisse wrote:
(Cc: said C++ folks)
On Fri, 18 May 2018, Richard Biener wrote:
On Fri, May 18, 2018 at 2:25 PM Marc Glisse wrote:
Hello,
this lets alias analysis handle the implicit 'this' parameter in C++
constructors as if it was restrict.
I think the foll
(Cc: said C++ folks)
On Fri, 18 May 2018, Richard Biener wrote:
On Fri, May 18, 2018 at 2:25 PM Marc Glisse wrote:
Hello,
this lets alias analysis handle the implicit 'this' parameter in C++
constructors as if it was restrict.
Bootstrap+regtest on powerpc64le-unknown-linux-gnu.
OK.
On Fri, May 18, 2018 at 2:25 PM Marc Glisse wrote:
> Hello,
> this lets alias analysis handle the implicit 'this' parameter in C++
> constructors as if it was restrict.
> Bootstrap+regtest on powerpc64le-unknown-linux-gnu.
OK. Please give C++ folks the chance to chime in on the semantics.
Th
Hello,
this lets alias analysis handle the implicit 'this' parameter in C++
constructors as if it was restrict.
Bootstrap+regtest on powerpc64le-unknown-linux-gnu.
2018-05-18 Marc Glisse
PR c++/82899
gcc/
* tree-ssa-structalias.c (create_variable_info_for_1): Extra argumen
14 matches
Mail list logo
