public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <rguenther@suse.de>
To: Martin Sebor <msebor@gmail.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] testsuite/102690 - XFAIL g++.dg/warn/Warray-bounds-16.C
Date: Thu, 11 Nov 2021 09:18:22 +0100 (CET)	[thread overview]
Message-ID: <34945810-r023-9q5s-q227-83oo4137sr47@fhfr.qr> (raw)
In-Reply-To: <73c2191f-5cc8-47d9-4167-63eb29b4d613@gmail.com>

On Wed, 10 Nov 2021, Martin Sebor wrote:

> On 11/10/21 3:09 AM, Richard Biener via Gcc-patches wrote:
> > This XFAILs the bogus diagnostic test and rectifies the expectation
> > on the optimization.
> > 
> > Tested on x86_64-unknown-linux-gnu, pushed.
> > 
> > 2021-11-10  Richard Biener  <rguenther@suse.de>
> > 
> >  PR testsuite/102690
> >  * g++.dg/warn/Warray-bounds-16.C: XFAIL diagnostic part
> >  and optimization.
> > ---
> >   gcc/testsuite/g++.dg/warn/Warray-bounds-16.C | 6 +++---
> >   1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C
> > b/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C
> > index 17b4d0d194e..89cbadb91c7 100644
> > --- a/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C
> > +++ b/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C
> > @@ -19,11 +19,11 @@ struct S
> >       p = (int*) new unsigned char [sizeof (int) * m];
> >   
> >       for (int i = 0; i < m; i++)
> > -      new (p + i) int ();
> > +      new (p + i) int (); /* { dg-bogus "bounds" "pr102690" { xfail *-*-* }
> > } */
> >     }
> >   };
> >   
> >   S a (0);
> >   
> > -/* Verify the loop has been eliminated.
> > -   { dg-final { scan-tree-dump-not "goto" "optimized" } } */
> > +/* The loop cannot be eliminated since the global 'new' can change 'm'.  */
> 
> I don't understand this comment.  Can you please explain how
> the global operator new (i.e., the one outside the loop below)
> can change the member of the class whose ctor calls the new?
> 
> The member, or more precisely the enclosing object, doesn't
> yet exist at the time the global new is called because its
> ctor hasn't finished, so nothing outside the ctor can access
> it.  A pointer to the S under construction can be used (and
> could be accessed by a replacement new) but it cannot be
> dereferenced to access its members because the object it
> points to doesn't exist until after the ctor completes.

Yes, that's the C++ legalise - which is why I XFAILed that
part of the test rather than just removed it.  The middle-end
sees the object *this as existing and being global, thus
accessible and mutable by '::new' which when replaced by
the user could access and alter *this.  Like maybe for

S s;

void *operator new(..) { s.m = 0; }

main()
{
  new (&s) (1);
}

that may be invalid C++ but this detail of C++ is not
reflected in the GIMPLE IL.  Before the change that regressed
this if S::S() would call a global function foo() instead
of new to do the allocation the behavior would be as after
the change.  Isn't the call to new or foo part of the
construction and as such obviously allowed to access
and alter the in-construction object?

> I copy the test below:
> 
> inline void* operator new (__SIZE_TYPE__, void * v)
> {
>   return v;
> }
> 
> struct S
> {
>   int* p;
>   int m;
> 
>   S (int i)
>   {
>     m = i;
>     p = (int*) new unsigned char [sizeof (int) * m];
> 
>     for (int i = 0; i < m; i++)
>       new (p + i) int (); /* { dg-bogus "bounds" "pr102690" { xfail *-*-* } }
> */
>   }
> };
> 
> S a (0);
> 
> Thanks
> Martin
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Ivo Totev; HRB 36809 (AG Nuernberg)

  reply	other threads:[~2021-11-11  8:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-10 10:09 Richard Biener
2021-11-10 22:07 ` Martin Sebor
2021-11-11  8:18   ` Richard Biener [this message]
2021-11-11 23:18     ` Martin Sebor
2021-11-12  7:11       ` Richard Biener

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=34945810-r023-9q5s-q227-83oo4137sr47@fhfr.qr \
    --to=rguenther@suse.de \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=msebor@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).