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;
}
next prev 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).