--- Comment #15 from jason at gcc dot gnu dot org 2008-08-05 22:23 ---
Subject: Bug 37016
Author: jason
Date: Tue Aug 5 22:22:00 2008
New Revision: 138740
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138740
Log:
PR c++/37016
* tree-ssa.c
--- Comment #16 from jason at gcc dot gnu dot org 2008-08-06 01:55 ---
Subject: Bug 37016
Author: jason
Date: Wed Aug 6 01:54:31 2008
New Revision: 138755
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138755
Log:
PR c++/37016
* tree-ssa.c
--- Comment #17 from jason at gcc dot gnu dot org 2008-08-06 02:26 ---
Subject: Bug 37016
Author: jason
Date: Wed Aug 6 02:25:20 2008
New Revision: 138756
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138756
Log:
PR c++/37016
* decl.c (build_ptrmemfunc_type):
--- Comment #18 from jason at gcc dot gnu dot org 2008-08-06 03:14 ---
Fixed in two different ways.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-08-04 09:18 ---
Ok, so SRA does
- itemfunptrD.2084.__pfnD.2089 ={v} itemfunD.2085;
- itemfunptrD.2084.__deltaD.2082 ={v} 0;
- memfunD.2158 ={v} itemfunptrD.2084;
+ itemfunptr$__pfnD.2176_1 = itemfunD.2085;
+
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-08-04 09:10 ---
Uhm. Lovely SRA.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-08-04 11:54 ---
This is yet another case of the C++ frontend using two different record types
for the same PFN structure.
For example we have
component_ref 0x77ec18c0
...
arg 0 var_decl 0x7759c8c0 itemfunptr
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-08-04 11:56 ---
I'm testing that patch, but I'm sure some side-effects of cp_build_unary_op
are necessary...
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-08-04 13:41 ---
Of course it didn't work. The following seems to
Index: gcc/cp/class.c
===
--- gcc/cp/class.c (revision 138611)
+++ gcc/cp/class.c (working
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-08-04 14:00 ---
Causes
FAIL: g++.dg/template/ptrmem8.C (test for errors, line 18)
FAIL: g++.dg/template/ptrmem8.C (test for errors, line 19)
Jason - can you help here? Thanks.
--
--- Comment #8 from jason at gcc dot gnu dot org 2008-08-04 19:37 ---
In general, it seems like SRA needs to be more conservative with
TYPE_STRUCTURAL_EQUALITY_P types such as these.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37016
--- Comment #9 from jason at gcc dot gnu dot org 2008-08-04 20:17 ---
However, it's not clear to me that pointers to member functions need to have
TYPE_STRUCTURAL_EQUALITY_P in general; I'm testing a patch to set
TYPE_CANONICAL appropriately.
--
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-08-04 20:27
---
The middle-end expects that if there is variable of record type T that for
a component-reference it can walk its fields and find the one used as
operand 1 in the component-reference.
If you look at the tree in
--- Comment #11 from jason at gcc dot gnu dot org 2008-08-04 21:02 ---
Created an attachment (id=16017)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16017action=view)
Patch to check TYPE_STRUCTURAL_EQUALITY_P in useless_type_conversion
--
--- Comment #12 from jason at gcc dot gnu dot org 2008-08-04 21:03 ---
Well, that's the problem then: we have two POINTER_TYPE to METHOD_TYPE which
are considered equivalent in the front end, but not equivalent in the tree-ssa
types_compatible_p.
The specific bug seems to be that
--- Comment #13 from rguenther at suse dot de 2008-08-04 21:11 ---
Subject: Re: [4.3/4.4 Regression] member function pointer
failure with optimization
On Mon, 4 Aug 2008, jason at gcc dot gnu dot org wrote:
--- Comment #12 from jason at gcc dot gnu dot org 2008-08-04 21:03
--- Comment #14 from rguenther at suse dot de 2008-08-04 21:13 ---
Subject: Re: [4.3/4.4 Regression] member function pointer
failure with optimization
On Mon, 4 Aug 2008, rguenther at suse dot de wrote:
--- Comment #13 from rguenther at suse dot de 2008-08-04 21:11 ---
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-03 21:47 ---
Confirmed.
SRA messing up again when there is different FIELD decls.
itemfunptrD.21695.__pfnD.21700 ={v} itemfunD.21696;
memfunD.24341 ={v} itemfunptrD.21695;
memfun$__pfnD.24346_4 =
18 matches
Mail list logo
