http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949
--- Comment #33 from Dmitry G. Dyachenko 2013-04-09
10:07:47 UTC ---
*** Bug 56830 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949
Jakub Jelinek changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949
--- Comment #31 from Jakub Jelinek 2013-04-04
12:52:36 UTC ---
Created attachment 29803
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29803
gcc49-pr34949.patch
Untested fix (and enhancement too).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949
--- Comment #30 from Jakub Jelinek 2013-04-04
09:20:36 UTC ---
Ah, I guess it is sink_clobbers, which would need to be tought to drop MEM_REF
clobbers instead of sinking them if the target bb is no longer dominated by the
bb with the SSA_N
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949
--- Comment #29 from Jakub Jelinek 2013-04-04
08:25:08 UTC ---
Reduced testcase for -O3:
struct E {};
struct A
{
virtual void a (void *) = 0;
};
struct B
{
virtual ~B () {};
unsigned int b1;
E **b2;
A *b3;
};
struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949
Jakub Jelinek changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949
Igor Zamyatin changed:
What|Removed |Added
CC||izamyatin at gmail dot com
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949
--- Comment #26 from Jason Merrill 2013-04-03
13:37:51 UTC ---
(In reply to comment #25)
> Looking at it more, if the change to emit *this ={v} {CLOBBER}; in cleanups
> rather than just at the end of function was desirable, then IMHO we ju
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949
--- Comment #25 from Jakub Jelinek 2013-04-03
12:27:56 UTC ---
Looking at it more, if the change to emit *this ={v} {CLOBBER}; in cleanups
rather than just at the end of function was desirable, then IMHO we just want
to adjust the ehcleanu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949
--- Comment #24 from Jakub Jelinek 2013-04-03
12:08:02 UTC ---
Ah, the committed patch (#c21) was different from the one I've been testing it
with (#c12).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949
--- Comment #23 from Jakub Jelinek 2013-04-03
09:39:34 UTC ---
(In reply to comment #22)
> That breaks g++.dg/tree-ssa/ehcleanup-1.C
On which target? I saw no regressions on x86_64-linux and i686-linux with all
the 3 patches.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949
--- Comment #22 from Andreas Schwab 2013-04-03 09:27:28
UTC ---
That breaks g++.dg/tree-ssa/ehcleanup-1.C
$ grep Removing ehcleanup-1.C.032t.ehcleanup1
Removing unreachable region 1
Removing unreachable region 2
Removing unreachable r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949
--- Comment #21 from Jakub Jelinek 2013-04-03
06:31:50 UTC ---
Author: jason
Date: Tue Apr 2 21:09:38 2013
New Revision: 197375
URL: http://gcc.gnu.org/viewcvs?rev=197375&root=gcc&view=rev
Log:
PR c++/34949
* decl.c (begin_d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949
--- Comment #20 from Jakub Jelinek 2013-04-03
06:31:13 UTC ---
Author: jakub
Date: Tue Apr 2 18:27:45 2013
New Revision: 197370
URL: http://gcc.gnu.org/viewcvs?rev=197370&root=gcc&view=rev
Log:
PR c++/34949
* tree-ssa-alias.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949
--- Comment #19 from Jakub Jelinek 2013-04-03
06:31:02 UTC ---
Author: jakub
Date: Tue Apr 2 18:25:36 2013
New Revision: 197369
URL: http://gcc.gnu.org/viewcvs?rev=197369&root=gcc&view=rev
Log:
PR c++/34949
* tree-cfg.c (ver
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949
Jason Merrill changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949
--- Comment #17 from Paolo Carlini 2013-03-28
23:58:04 UTC ---
I see.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949
--- Comment #16 from Jakub Jelinek 2013-03-28
21:13:15 UTC ---
It isn't a library issue, in libstdc++ it is just ICE
internal compiler error: in sra_ipa_reset_debug_stmts, at tree-sra.c:4681
in all the libstdc++ testcases that regressed be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949
--- Comment #15 from Paolo Carlini 2013-03-28
16:11:31 UTC ---
Cool, thanks guys for working on this. I hope the library issues aren't too
serious.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949
--- Comment #14 from Jakub Jelinek 2013-03-28
14:09:01 UTC ---
Created attachment 29746
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29746
gcc49-pr34949-2.patch
Another needed patch, without which DSE wouldn't really delete the u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949
--- Comment #13 from Jakub Jelinek 2013-03-28
14:07:42 UTC ---
Created attachment 29745
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29745
gcc49-pr34949-1.patch
Incremental patch, passed bootstrap together with the later jason's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949
Jason Merrill changed:
What|Removed |Added
Attachment #29731|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949
--- Comment #11 from Jason Merrill 2013-03-26
15:14:30 UTC ---
Created attachment 29731
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29731
patch to add clobbers
This patch adds the clobber assignments as Jakub suggested, but the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949
--- Comment #9 from Richard Guenther 2011-09-01
09:10:11 UTC ---
It looks to me that the C++ FE could detect that the vtable pointer update
would adjust it to itself (I even can't construct a testcase that would
adjust it _not_ to itself ...).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949
congruwer at yahoo dot co.uk changed:
What|Removed |Added
CC||congruwer at yahoo dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949
Andrew Pinski changed:
What|Removed |Added
CC||jyasskin at gcc dot gnu.org
--- Comment #
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-06-09 10:18 ---
*** Bug 40382 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-01-24 18:39 ---
This still needs communication from the front-end to the middle-end. The
middle-end part should be a rather easy extension to both the RTL and tree
level DSEs really.
The way I see fixing it is adding a statement w
--- Comment #4 from spark at gcc dot gnu dot org 2008-01-24 18:16 ---
I don't think this can be implemented in the FE,
at least to be really effective.
The more common cases are not really "empty" destructor.
E.g. there's inlining involved:
class Foo
{
public:
virtual ~Foo();
};
Foo:
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-24 10:32 ---
This needs to be optimized in the C++ FE for the said reasons.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from spark at gcc dot gnu dot org 2008-01-23 23:23 ---
I understand why it's difficult to delete the code in the middle-end. But this
case seems to be quite common - not the empty body but more common cases are
destructors whose body doesn't need vtable.
--
http://gcc
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-23 23:17 ---
hmmm, it is hard for middle-end to know these are dead, the C++ front-end needs
to comuniticate to the middle-end that after the function ends, this is not
going to be valid.
By the way, please don't call this a tri
33 matches
Mail list logo