public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/107561] [13 Regression] g++.dg/pr71488.C  and [g++.dg/warn/Warray-bounds-16.C -m32] regression due to -Wstringop-overflow problem
Date: Wed, 01 Mar 2023 14:38:10 +0000	[thread overview]
Message-ID: <bug-107561-4-w6gmY7QdAx@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-107561-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #16)
> (In reply to Richard Biener from comment #15)
> > The compiler doesn't know that the allocation function cannot clobber *this.
> > The C++ frontend tries to communicate this by making 'this' restrict
> > qualified
> > and we make use of that info, but for calls we do not know how to use the
> > info.
> > 
> > Maybe we can special-case directly the actual parameter case and compute
> > the restrictness info for the call arguments.  The canonical example is
> > 
> > void bar (void);
> > struct X {
> >   X (int);
> >   int i;
> >   int j;
> > };
> > 
> > X::X(int k)
> > {
> >   i = k;
> >   bar ();
> >   j = i != k;
> > }
> > 
> > where if I understand you correctly, bar () is not allowed to modify *this
> > (unless I pass it an argument to it, of course), even if *this is for
> > example
> 
> Why?  Because it is a constructor and the object isn't fully constructed yet
> at that point?  For normal methods I certainly don't see anything that would
> preclude such modifications.

The canonical C example would be

void bar (void);

void foo (struct X * restrict this, int k)
{
  this->i = k;
  bar ();
  this->j = i != k;
}

where as I understand bar () cannot modify what *this points to since it
cannot build a proper derived access from 'this' (unless I pass it to bar).

The C++ frontend annotates 'this' with restrict.  For my example I get

void X::X (struct X * const this, int k)
{
  # PT = { D.2806 } (nonlocal, restrict)
  struct X * const this_5(D) = this;
  int k_7(D) = k;
  int _1;
  bool _2;
  int _3;

  <bb 2> :
  MEM[(struct X *)this_5(D) clique 1 base 1] ={v} {CLOBBER};
  MEM[(struct X *)this_5(D) clique 1 base 1].i = k_7(D);
  # USE = nonlocal escaped
  # CLB = nonlocal escaped
  bar ();
  _1 = MEM[(struct X *)this_5(D) clique 1 base 1].i;
  _2 = _1 != k_7(D);
  # RANGE [irange] int [0, 1] NONZERO 0x1
  _3 = (int) _2;
  MEM[(struct X *)this_5(D) clique 1 base 1].j = _3;
  return;
}

  parent reply	other threads:[~2023-03-01 14:38 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-07 20:06 [Bug tree-optimization/107561] New: g++.dg/pr17488.C " aldyh at gcc dot gnu.org
2022-11-07 20:10 ` [Bug tree-optimization/107561] [13 Regression] " pinskia at gcc dot gnu.org
2022-11-08  8:31 ` aldyh at gcc dot gnu.org
2022-11-08  8:48 ` [Bug tree-optimization/107561] [13 Regression] g++.dg/pr17488.C and [g++.dg/warn/Warray-bounds-16.C -m32] " aldyh at gcc dot gnu.org
2022-11-08  9:34 ` rguenth at gcc dot gnu.org
2022-11-08 13:43 ` aldyh at gcc dot gnu.org
2022-11-08 18:27 ` pinskia at gcc dot gnu.org
2022-12-14 15:43 ` [Bug tree-optimization/107561] [13 Regression] g++.dg/pr71488.C " danglin at gcc dot gnu.org
2023-01-13 12:42 ` rguenth at gcc dot gnu.org
2023-02-02 18:53 ` hp at gcc dot gnu.org
2023-02-02 21:03 ` hp at gcc dot gnu.org
2023-02-10  0:42 ` cvs-commit at gcc dot gnu.org
2023-02-27  9:56 ` rguenth at gcc dot gnu.org
2023-02-27 11:18 ` rguenth at gcc dot gnu.org
2023-02-27 12:49 ` rguenth at gcc dot gnu.org
2023-02-27 13:45 ` aldyh at gcc dot gnu.org
2023-02-27 14:38 ` redi at gcc dot gnu.org
2023-02-27 16:16 ` aldyh at gcc dot gnu.org
2023-03-01 14:22 ` rguenth at gcc dot gnu.org
2023-03-01 14:34 ` jakub at gcc dot gnu.org
2023-03-01 14:38 ` rguenth at gcc dot gnu.org [this message]
2023-03-01 14:55 ` jakub at gcc dot gnu.org
2023-03-01 14:57 ` jakub at gcc dot gnu.org
2023-03-01 15:55 ` redi at gcc dot gnu.org
2023-03-02  7:51 ` rguenth at gcc dot gnu.org
2023-03-02  7:53 ` rguenth at gcc dot gnu.org
2023-03-29 11:38 ` rguenth at gcc dot gnu.org
2023-03-29 11:41 ` rguenth at gcc dot gnu.org
2023-03-30 11:16 ` cvs-commit at gcc dot gnu.org
2023-03-30 11:17 ` rguenth at gcc dot gnu.org

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=bug-107561-4-w6gmY7QdAx@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).