https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #26 from Martin Sebor ---
Author: msebor
Date: Tue Aug 6 00:08:45 2019
New Revision: 274130
URL: https://gcc.gnu.org/viewcvs?rev=274130&root=gcc&view=rev
Log:
PR c++/60517 - warning/error for taking address of member of a temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
Martin Sebor changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #24 from Manuel López-Ibáñez ---
How does typeck.c check that it is a temporary? The important thing is not
that it is an ARRAY_REF but that it is a member of a temporary object. Not
sure how to check that.
Marc points above that the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #23 from Fredrik Hederstierna
---
Ah ok, yes I think you are right. The check could possibly be in "cp/typeck.c"
and "cp/tree.c"? but I'm not familiar with this C++ parsing code.
Interesting that this code gets warning:
B* foo(A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #22 from Manuel López-Ibáñez ---
I honestly think the uninitialized warning and fixing TREE_NOWARNING is a
red-herring. My testcase should get a warning even if .x[0] is initialized.
The problem is taking the address of a temporary. T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #21 from Fredrik Hederstierna
---
Started with fix for PR 43347 to not warn on artificial aggregates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43347
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #20 from Fredrik Hederstierna
---
Simplest fix might be something like?
- else
+ else if (access->grp_no_warning)
so we do not always suppress warnings, but name will look funny for temp.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
Fredrik Hederstierna changed:
What|Removed |Added
CC||fredrik.hederstierna@securi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #18 from Marc Glisse ---
The .uninit dump for the original testcase now looks like:
double foo(A) (struct A a)
{
double SR.1;
:
return SR.1_2(D);
}
which the uninit pass would warn about, except that SR.1 is marked
TREE_NO_W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #17 from Marc Glisse ---
(In reply to Manuel López-Ibáñez from comment #16)
> Note that we still do not warn for my original testcase.
I didn't close the PR ;-)
There are patches around that may need more work, see these discussions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #15 from Marc Glisse ---
Author: glisse
Date: Thu Jul 31 09:33:58 2014
New Revision: 213323
URL: https://gcc.gnu.org/viewcvs?rev=213323&root=gcc&view=rev
Log:
2014-07-31 Marc Glisse
PR c++/60517
gcc/c/
* c-typeck.c (c_fin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
Paolo Carlini changed:
What|Removed |Added
CC||lisp2d at lisp2d dot net
--- Comment #14
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #13 from Marc Glisse ---
(In reply to Manuel López-Ibáñez from comment #12)
> Why do you want to remove the clobber?
I am in the DSE pass, so removing the clobber as a dead store is the easiest
thing to do ;-)
Ok, it might not be su
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #12 from Manuel López-Ibáñez ---
(In reply to Marc Glisse from comment #11)
> Created attachment 32551 [details]
> first try
>
> With clobber removal now.
Why do you want to remove the clobber?
I understood your idea to avoid dupli
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
Marc Glisse changed:
What|Removed |Added
Attachment #32549|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #10 from Marc Glisse ---
Created attachment 32549
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32549&action=edit
first try
With -O -fdisable-tree-esra (see PR 60770), it warns on the testcase. Twice
because the DSE pass is run
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #9 fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #8 from Marc Glisse ---
(In reply to Manuel López-Ibáñez from comment #7)
> To avoid duplicates, the front-end could just return something else, like
> NULL, when it detects this case (I guess the behavior is undefined and we
> can do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #7 from Manuel López-Ibáñez ---
(In reply to Marc Glisse from comment #6)
> (In reply to Marc Glisse from comment #5)
> > I would need a different (middle-end) warning that
> > detects return &local_var,
>
> To confirm this, I looked
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #6 from Marc Glisse ---
(In reply to Marc Glisse from comment #5)
> I would need a different (middle-end) warning that
> detects return &local_var,
To confirm this, I looked at the last dangling reference I debugged, recompiled
it wit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #5 from Marc Glisse ---
(In reply to Manuel López-Ibáñez from comment #4)
> Where is the clobber added?
front-end, I expect (sorry, I'm trying to get something to work on windows and
don't have my usual sources at hand).
> The closer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #4 from Manuel López-Ibáñez ---
(In reply to Marc Glisse from comment #3)
> (In reply to Manuel López-Ibáñez from comment #2)
> > (In reply to Marc Glisse from comment #1)
> > > I see in the dump:
> > >
> > > # .MEM_4 = VDEF <.MEM_8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #3 from Marc Glisse ---
(In reply to Manuel López-Ibáñez from comment #2)
> (In reply to Marc Glisse from comment #1)
> > I see in the dump:
> >
> > # .MEM_4 = VDEF <.MEM_8>
> > D.2272 ={v} {CLOBBER};
> > # VUSE <.MEM_4>
> > _
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #2 from Manuel López-Ibáñez ---
(In reply to Marc Glisse from comment #1)
> I see in the dump:
>
> # .MEM_4 = VDEF <.MEM_8>
> D.2272 ={v} {CLOBBER};
> # VUSE <.MEM_4>
> _5 = MEM[(doubleD.39 *)&D.2272];
>
> which looks like so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #1 from Marc Glisse ---
I see in the dump:
# .MEM_4 = VDEF <.MEM_8>
D.2272 ={v} {CLOBBER};
# VUSE <.MEM_4>
_5 = MEM[(doubleD.39 *)&D.2272];
which looks like something we could warn about in the middle-end.
26 matches
Mail list logo
