https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #33 from Jonathan Wakely ---
This is now https://cplusplus.github.io/CWG/issues/2868.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #32 from Jonathan Wakely ---
[basic.stc.general] says global == &w is implementation-defined if global is an
invalid pointer value, not just unspecified. GCC could define it to be
unspecified, or UB, and even say "it's UB just in thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #31 from Arthur O'Dwyer ---
Oops, I guess my reading did disagree with jwakely's in one small point:
jwakely writes--
> But since one of the pointers is an invalid pointer,
> you can't do anything with its value anyway, including
> c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #30 from Arthur O'Dwyer ---
I think I understand jwakely's argument at this point, and it's consistent and
teachable. https://eel.is/c++draft/class.temporary#3.sentence-1 says:
> When an object of class type X is passed to or return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #29 from Jakub Jelinek ---
(In reply to Jonathan Wakely from comment #28)
> What I tried to say in comment 26 is that we're allowed to always make the
> extra copy, which means that global is an invalid pointer, so the program
> has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #28 from Jonathan Wakely ---
What I tried to say in comment 26 is that we're allowed to always make the
extra copy, which means that global is an invalid pointer, so the program has
UB.
I think the only flaw in that reasoning is wha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #27 from Richard Biener ---
(In reply to Jonathan Wakely from comment #25)
>
> Since it's unspecified, the program cannot rely on any particular behaviour.
> The 'global' pointer might point to w, or it might point to a temporary
> w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #26 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #25)
> However, [class.temporary] p3 explicitly allows the compiler to create a
> temporary object when returning a class with a trivial copy constructor and
> tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #25 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #9)
> struct Widget {
> int i;
> int a[4];
> };
> Widget *global = 0;
> Widget make2() { Widget w; w.i = 1; global = &w; return w; }
> void g() { global->i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #24 from Jakub Jelinek ---
On the #c23 testcase, actually even on i686-linux where it is passed in memory
we optimize main at -O2 -m32 -fno-strict-aliasing -fno-tree-pta (i.e. when the
code mentioned in #c12 is never called) to retur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #23 from Jakub Jelinek ---
Changing what types have TREE_ADDRESSABLE flag on it would cause significant
ABI changes, that is not what we can do.
Widget above does not have trivial default constructor, but has trivial copy
constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #22 from Richard Biener ---
Ping. Jakub/Jason - we now have three open bugs because of this. The patch
in comment#12 works but Jakub doesn't like it.
Instead as far as I understand we need a flag to tell us whether there's
guarant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
Richard Biener changed:
What|Removed |Added
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #20 from Andrew Pinski ---
Isn't this just a dup of bug 84414 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #19 from Richard Biener ---
(In reply to Richard Biener from comment #13)
> (In reply to Richard Biener from comment #12)
> > For the fun of it I'm testing
> >
> > diff --git a/gcc/tree-ssa-structalias.cc b/gcc/tree-ssa-structalias.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #18 from Jakub Jelinek ---
We'd need the FE to note it somewhere (of course, if it is indirect call or the
call doesn't bind to the definition we'd need to assume it might be with
mandatory NRV).
I think in the C++ FE it is finalized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #17 from rguenther at suse dot de ---
On Wed, 24 May 2023, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
>
> --- Comment #16 from Jakub Jelinek ---
> I think the C version is UB, it escapes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #16 from Jakub Jelinek ---
I think the C version is UB, it escapes address of a local variable. The C++
case is different when the language mandates NVR, in that case one can rely on
it.
TREE_ADDRESSABLE on a type is I think set con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #15 from rguenther at suse dot de ---
On Wed, 24 May 2023, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
>
> --- Comment #14 from Jakub Jelinek ---
> (In reply to Richard Biener from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #14 from Jakub Jelinek ---
(In reply to Richard Biener from comment #13)
> with the former for -m64 and the latter for -m32 only seems to be the
> only fallout here.
It will penalize C and other languages without mandatory NRV in th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #13 from Richard Biener ---
(In reply to Richard Biener from comment #12)
> For the fun of it I'm testing
>
> diff --git a/gcc/tree-ssa-structalias.cc b/gcc/tree-ssa-structalias.cc
> index 56021c59cb9..1e7f0383371 100644
> --- a/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
Richard Biener changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #11 from Arthur O'Dwyer ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Arthur O'Dwyer from comment #7)
> > // https://godbolt.org/z/Ea43Y65z4
> > struct Widget {
> > int i = 1;
> ...
> > In this case, Widget has n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #10 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #9)
> (In reply to Andrew Pinski from comment #8)
> > (In reply to Arthur O'Dwyer from comment #7)
> But does w go out of the scope at the end of make2? Similar quest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #9 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Arthur O'Dwyer from comment #7)
> > // https://godbolt.org/z/Ea43Y65z4
> > struct Widget {
> > int i = 1;
> ...
> > In this case, Widget has no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #8 from Andrew Pinski ---
(In reply to Arthur O'Dwyer from comment #7)
> // https://godbolt.org/z/Ea43Y65z4
> struct Widget {
> int i = 1;
...
> In this case, Widget has no constructors,
No, it has a constructor because of the N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #7 from Arthur O'Dwyer ---
Richard Biener wrote:
> Are we using the wrong check or is escaping 'this'
> for these kind of classes invoking undefined behavior?
Wow, this got a lot of traffic quickly! Sounds like you (Richard, Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #6 from Andrew Pinski ---
Note here is a testcase which fails even with C++98 (basically changing the
default assignment in the class to the ctor):
```
struct Widget {
Widget();
int i;
int a[4];
};
Widget *global = 0;
Wid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #5 from Richard Biener ---
It seems a copy CTOR or DTOR is required to make it TREE_ADDRESSABLE. So
adding either
~Widget();
or
Widget(const Widget&);
to the Widget class declaration fixes the testcase. Are we using the wro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
Richard Biener changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
Known to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #3 from Andrew Pinski ---
Note to make it fail at -O2 and above is simple just add [[gnu::noipa]] to make
definition like this:
[[gnu::noipa]]
Widget make() { return Widget(); }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #2 from Richard Biener ---
The fix for PR40389, r0-94078-g4d61856d0a221c, changed this to look at type
addressability (from LHS addressability).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
Richard Biener changed:
What|Removed |Added
Component|c++ |tree-optimization
Last reconfirmed|
33 matches
Mail list logo
