[Bug other/46823] New: ICE: edge points to wrong declaration

[Bug other/46823] New: ICE: edge points to wrong declaration

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823

           Summary: ICE: edge points to wrong declaration
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: marc.glisse@normalesup.org
            Target: x86_64-unknown-linux-gnu


With the file:
http://geometrica.saclay.inria.fr/team/Marc.Glisse/tmp/ouin.cc.xz
compiled with:
c++ -frounding-math -O3 -c ouin.cc
I get the error message below.
A smaller version is available at:
http://geometrica.saclay.inria.fr/team/Marc.Glisse/tmp/a.cc
but delta made a number of illegal transformations.

ouin.cc: In function 'CGAL::Polynomial<NT> CGAL::internal::gcd_(const
CGAL::Polynomial<NT>&, const CGAL::Polynomial<NT>&,
CGAL::Unique_factorization_domain_tag) [with NT =
CGAL::Polynomial<CGAL::Polynomial<CORE::BigInt> >]':
ouin.cc:66187:57: error: edge points to wrong declaration:
 <function_decl 0x7fea48919300
_ZN4CGAL10PolynomialINS0_INS0_IN4CORE6BigIntEEEEEEC2ERKS4_.constprop.2093
    type <method_type 0x7fea4b2e3d20
        type <void_type 0x7fea556a2e70 void type_6 VOID
            align 8 symtab 0 alias set -1 canonical type 0x7fea556a2e70
            pointer_to_this <pointer_type 0x7fea556a2f18>>
        QI
        size <integer_cst 0x7fea5568c4d8 constant 8>
        unit size <integer_cst 0x7fea5568c500 constant 1>
        align 8 symtab 0 alias set -1 canonical type 0x7fea4b2e3d20 method
basetype <record_type 0x7fea4d1487e0 Polynomial>
        arg-types <tree_list 0x7fea49746c80 value <pointer_type 0x7fea4cc26000>
            chain <tree_list 0x7fea49746e10 value <reference_type
0x7fea4cc297e0>
                chain <tree_list 0x7fea556b53c0 value <void_type 0x7fea556a2e70
void>>>>
        pointer_to_this <pointer_type 0x7fea4a73cc78>>
    addressable asm_written used static autoinline decl_5 QI file ouin.cc line
63200 col 14 align 16 context <record_type 0x7fea4d1487e0 Polynomial> initial
<error_mark 0x7fea55694b40> abstract_origin <function_decl 0x7fea4cc28900
Polynomial>
    arguments <parm_decl 0x7fea46248a18 this
        type <pointer_type 0x7fea4cc26000 type <record_type 0x7fea4d1487e0
Polynomial>
            public unsigned DI
            size <integer_cst 0x7fea5568c7d0 constant 64>
            unit size <integer_cst 0x7fea5568c7f8 constant 8>
            align 64 symtab 0 alias set -1 canonical type 0x7fea4cc26000>
        readonly used unsigned DI file ouin.cc line 63200 col 37 size
<integer_cst 0x7fea5568c7d0 64> unit size <integer_cst 0x7fea5568c7f8 8>
        align 64 context <function_decl 0x7fea48919300
_ZN4CGAL10PolynomialINS0_INS0_IN4CORE6BigIntEEEEEEC2ERKS4_.constprop.2093>
abstract_origin <parm_decl 0x7fea4ce12d48 this>
        (reg/f:DI 3 bx [orig:64 this ] [64]) arg-type <pointer_type
0x7fea4cc26000>
        incoming-rtl (reg:DI 5 di [ this ])
        chain <parm_decl 0x7fea46248aa0 a0 type <reference_type 0x7fea4cc297e0>
            readonly used unsigned DI file ouin.cc line 63200 col 35 size
<integer_cst 0x7fea5568c7d0 64> unit size <integer_cst 0x7fea5568c7f8 8>
            align 64 context <function_decl 0x7fea48919300
_ZN4CGAL10PolynomialINS0_INS0_IN4CORE6BigIntEEEEEEC2ERKS4_.constprop.2093>
abstract_origin <parm_decl 0x7fea4ce12dd0 a0>

            (reg/v/f:DI 1 dx [orig:65 a0 ] [65]) arg-type <reference_type
0x7fea4cc297e0>
            incoming-rtl (reg:DI 4 si [ a0 ])>>
    result <result_decl 0x7fea4624f180 D.359023 type <void_type 0x7fea556a2e70
void>
        used ignored VOID file ouin.cc line 63202 col 44
        align 8 context <function_decl 0x7fea48919300
_ZN4CGAL10PolynomialINS0_INS0_IN4CORE6BigIntEEEEEEC2ERKS4_.constprop.2093>
abstract_origin <result_decl 0x7fea4bff5e00 D.188551>>
    full-name "CGAL::Polynomial<NT>::Polynomial(const NT&) [with NT_ =
CGAL::Polynomial<CGAL::Polynomial<CORE::BigInt> >, CGAL::Polynomial<NT>::NT =
CGAL::Polynomial<CGAL::Polynomial<CORE::BigInt> >]"
    pending-inline-info 0x7fea4c02e310 template-info 0x7fea4cde7f20
    (mem:QI (symbol_ref:DI
("_ZN4CGAL10PolynomialINS0_INS0_IN4CORE6BigIntEEEEEEC2ERKS4_.constprop.2093")
[flags 0x3] <function_decl 0x7fea48919300
_ZN4CGAL10PolynomialINS0_INS0_IN4CORE6BigIntEEEEEEC2ERKS4_.constprop.2093>) [0
S1 A8])>
 Instead of: <function_decl 0x7fea4cc58100 __comp_ctor 
    type <method_type 0x7fea4cc29888
        type <void_type 0x7fea556a2e70 void type_6 VOID
            align 8 symtab 0 alias set -1 canonical type 0x7fea556a2e70
            pointer_to_this <pointer_type 0x7fea556a2f18>>
        QI
        size <integer_cst 0x7fea5568c4d8 constant 8>
        unit size <integer_cst 0x7fea5568c500 constant 1>
        align 8 symtab 0 alias set -1 canonical type 0x7fea4cc29930 method
basetype <record_type 0x7fea4d1487e0 Polynomial>
        arg-types <tree_list 0x7fea4cc27d70 value <pointer_type 0x7fea4cc26000>
            chain <tree_list 0x7fea4cc27cd0 value <reference_type
0x7fea4cc297e0>
                chain <tree_list 0x7fea556b53c0 value <void_type 0x7fea556a2e70
void>>>>
        pointer_to_this <pointer_type 0x7fea4edf40a8>>
    addressable used public static weak autoinline decl_5 QI defer-output file
ouin.cc line 63200 col 14 align 16 context <record_type 0x7fea4d1487e0
Polynomial> initial <block 0x7fea4c02c840> abstract_origin <function_decl
0x7fea4cc28900 Polynomial>
    arguments <parm_decl 0x7fea4cc574c8 this
        type <pointer_type 0x7fea4cc26000 type <record_type 0x7fea4d1487e0
Polynomial>
            public unsigned DI
            size <integer_cst 0x7fea5568c7d0 constant 64>
            unit size <integer_cst 0x7fea5568c7f8 constant 8>
            align 64 symtab 0 alias set -1 canonical type 0x7fea4cc26000>
        readonly used unsigned DI file ouin.cc line 63200 col 37 size
<integer_cst 0x7fea5568c7d0 64> unit size <integer_cst 0x7fea5568c7f8 8>
        align 64 context <function_decl 0x7fea4cc58100 __comp_ctor >
abstract_origin <parm_decl 0x7fea4ce12d48 this> arg-type <pointer_type
0x7fea4cc26000>
        chain <parm_decl 0x7fea4cc57550 a0 type <reference_type 0x7fea4cc297e0>
            readonly used unsigned DI file ouin.cc line 63200 col 35 size
<integer_cst 0x7fea5568c7d0 64> unit size <integer_cst 0x7fea5568c7f8 8>
            align 64 context <function_decl 0x7fea4cc58100 __comp_ctor >
abstract_origin <parm_decl 0x7fea4ce12dd0 a0>
            arg-type <reference_type 0x7fea4cc297e0>>>
    result <result_decl 0x7fea4bff5e80 D.188553 type <void_type 0x7fea556a2e70
void>
        ignored VOID file ouin.cc line 63202 col 44
        align 8 context <function_decl 0x7fea4cc58100 __comp_ctor >>
    full-name "CGAL::Polynomial<NT>::Polynomial(const NT&) [with NT_ =
CGAL::Polynomial<CGAL::Polynomial<CORE::BigInt> >, CGAL::Polynomial<NT>::NT =
CGAL::Polynomial<CGAL::Polynomial<CORE::BigInt> >]"
    pending-inline-info 0x7fea4c02e460 template-info 0x7fea4cde7f20
    struct-function 0x7fea4c024be0 chain <function_decl 0x7fea4cc28a00
Polynomial>>
CGAL::internal::Coercion_traits_for_polynomial_comp_d<CGAL::Polynomial<NT>, B,
false>::Type
CGAL::internal::Coercion_traits_for_polynomial_comp_d<CGAL::Polynomial<NT>, B,
false>::Cast::operator()(const B&) const [with A =
CGAL::Polynomial<CGAL::Polynomial<CORE::BigInt> >, B = CORE::BigInt,
CGAL::internal::Coercion_traits_for_polynomial_comp_d<CGAL::Polynomial<NT>, B,
false>::Type = CGAL::Polynomial<CGAL::Polynomial<CGAL::Polynomial<CORE::BigInt>
> >, typename CGAL::Coercion_traits<A, B>::Type =
CGAL::Polynomial<CGAL::Polynomial<CORE::BigInt> >]/6423(-1) @0x7fea4bd976e0
(asm:
_ZNK4CGAL8internal37Coercion_traits_for_polynomial_comp_dINS_10PolynomialINS2_INS2_IN4CORE6BigIntEEEEEEES4_Lb0EE4CastclERKS4_.isra.1183.constprop.1969)
(inline copy in CGAL::Polynomial<NT> CGAL::internal::gcd_(const
CGAL::Polynomial<NT>&, const CGAL::Polynomial<NT>&,
CGAL::Unique_factorization_domain_tag) [with NT =
CGAL::Polynomial<CGAL::Polynomial<CORE::BigInt> >]/7969) (clone of
CGAL::internal::Coercion_traits_for_polynomial_comp_d<CGAL::Polynomial<NT>, B,
false>::Type
CGAL::internal::Coercion_traits_for_polynomial_comp_d<CGAL::Polynomial<NT>, B,
false>::Cast::operator()(const B&) const [with A =
CGAL::Polynomial<CGAL::Polynomial<CORE::BigInt> >, B = CORE::BigInt,
CGAL::internal::Coercion_traits_for_polynomial_comp_d<CGAL::Polynomial<NT>, B,
false>::Type = CGAL::Polynomial<CGAL::Polynomial<CGAL::Polynomial<CORE::BigInt>
> >, typename CGAL::Coercion_traits<A, B>::Type =
CGAL::Polynomial<CGAL::Polynomial<CORE::BigInt> >]/1325) availability:local
analyzed 37 time, 14 benefit (76 after inlining) 15 size, 6 benefit (35 after
inlining) 8 bytes stack usage reachable body local finalized inlinable
  called by: CGAL::Polynomial<NT> CGAL::internal::gcd_(const
CGAL::Polynomial<NT>&, const CGAL::Polynomial<NT>&,
CGAL::Unique_factorization_domain_tag) [with NT =
CGAL::Polynomial<CGAL::Polynomial<CORE::BigInt> >]/7969 (1.00 per call)
(inlined) 
  calls: CGAL::Handle_with_policy<T_, HandlePolicy,
Allocator_>::~Handle_with_policy() [with T_ =
CGAL::internal::Polynomial_rep<CGAL::Polynomial<CORE::BigInt> >, HandlePolicy =
CGAL::Handle_policy_no_union, Allocator_ =
std::allocator<CGAL::internal::Polynomial_rep<CGAL::Polynomial<CORE::BigInt> >
>]/5298 (can throw external) CGAL::Handle_with_policy<T_, HandlePolicy,
Allocator_>::~Handle_with_policy() [with T_ =
CGAL::internal::Polynomial_rep<CGAL::Polynomial<CORE::BigInt> >, HandlePolicy =
CGAL::Handle_policy_no_union, Allocator_ =
std::allocator<CGAL::internal::Polynomial_rep<CGAL::Polynomial<CORE::BigInt> >
>]/5298 (1.00 per call) (can throw external)
CGAL::Polynomial<NT>::Polynomial(const NT&) [with NT_ =
CGAL::Polynomial<CGAL::Polynomial<CORE::BigInt> >, CGAL::Polynomial<NT>::NT =
CGAL::Polynomial<CGAL::Polynomial<CORE::BigInt> >]/4256 (1.00 per call) (can
throw external)
CGAL::internal::Coercion_traits_for_polynomial_comp_d<CGAL::Polynomial<NT>, B,
false>::Type
CGAL::internal::Coercion_traits_for_polynomial_comp_d<CGAL::Polynomial<NT>, B,
false>::Cast::operator()(const B&) const [with A =
CGAL::Polynomial<CORE::BigInt>, B = CORE::BigInt,
CGAL::internal::Coercion_traits_for_polynomial_comp_d<CGAL::Polynomial<NT>, B,
false>::Type = CGAL::Polynomial<CGAL::Polynomial<CORE::BigInt> >, typename
CGAL::Coercion_traits<A, B>::Type = CGAL::Polynomial<CORE::BigInt>]/10353
(inlined) (1.00 per call) (can throw external) 
  References: 
  Refering this function: 
ouin.cc:66187:57: internal compiler error: verify_cgraph_node failed

[Bug middle-end/46823] [4.6 Regression] ICE: edge points to wrong declaration

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2010.12.06 18:54:51
          Component|other                       |middle-end
                 CC|                            |mjambor at suse dot cz
     Ever Confirmed|0                           |1
            Summary|ICE: edge points to wrong   |[4.6 Regression] ICE: edge
                   |declaration                 |points to wrong declaration
   Target Milestone|---                         |4.6.0

--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> 2010-12-06 18:54:51 UTC ---
ICE is caused by revision 164135:

http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00427.html

[Bug middle-end/46823] [4.6 Regression] ICE: edge points to wrong declaration

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823

Martin Jambor <jamborm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |jamborm at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #2 from Martin Jambor <jamborm at gcc dot gnu.org> 2010-12-07 13:13:45 UTC ---
Mine.

[Bug middle-end/46823] [4.6 Regression] ICE: edge points to wrong declaration

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823

--- Comment #3 from Martin Jambor <jamborm at gcc dot gnu.org> 2010-12-07 13:14:51 UTC ---
Simple testcase (to be run with -O -fipa-sra):

struct A
{
  int *p;
  A() {p = (int *) -1;}
  ~A() {if (p && p != (int *) -1) *p = 0;}
};

struct B
{
  A a;
  char data[23];
  B() : a() {data[0] = 0;}
};

extern A ga;
extern int *gi;
extern void *gz;
extern B *gb;

static int * __attribute__ ((noinline)) foo (B *b, void *z)
{
  __builtin_memcpy (gz, z, 28);
  ga = b->a;
  return b->a.p;
}

int *bar (B *b, void *z)
{
  gb = b;
  return foo (b, z);
}

[Bug middle-end/46823] [4.6 Regression] ICE: edge points to wrong declaration

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823

--- Comment #4 from Martin Jambor <jamborm at gcc dot gnu.org> 2010-12-07 13:28:58 UTC ---
ehm, sorry, wrong bug, this is a test case for PR 46734.  Of course, I will
have a look at this one soon too, so it can stay assigned to me.

[Bug middle-end/46823] [4.6 Regression] ICE: edge points to wrong declaration

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823

--- Comment #5 from Martin Jambor <jamborm at gcc dot gnu.org> 2010-12-09 13:28:32 UTC ---
I could not reproduce the ICE with the ouin.cc source but I did with
a.cc.

So far I have no clue whatsoever how IPA-SRA comes into this (but it
is true that switching it off makes the ICE go away) or how the
MEM_REF patch makes anything any different (the IPA-SRA modification
that seems to trigger this only removes a parameter, it does not build
any memory references).

Nevertheless, by adding verify_cgraph() calls all over the place, I
figured out that the verification becomes unhappy after the following
call in expand_call_inline. 

  fn = cgraph_node (fn)->decl;

cgraph_node creates a cgraph node if it does not find one so I guess
that is a part of the problem.

[Bug middle-end/46823] [4.6 Regression] ICE: edge points to wrong declaration

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823

--- Comment #6 from Martin Jambor <jamborm at gcc dot gnu.org> 2010-12-16 17:55:34 UTC ---
Hm, somehow I must have made a mistake when looking into this last
week but it seems that my dynamic type change detection patches fix
this problem too.  The last version of them is at:

http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01213.html

[Bug middle-end/46823] [4.6 Regression] ICE: edge points to wrong declaration

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823

--- Comment #7 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-01-03 17:40:57 UTC ---
The aforementioned patch did not do type comparisons correctly and so
only hid the problem.  I have already committed a subsequent patch
that addresses this (http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01781.html)
and the issue resurfaced.  I'll go on looking into it tomorrow or on
Wednesday.

[Bug middle-end/46823] [4.6 Regression] ICE: edge points to wrong declaration

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug middle-end/46823] [4.6 Regression] ICE: edge points to wrong declaration

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823

Martin Jambor <jamborm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org

--- Comment #8 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-01-07 13:04:53 UTC ---
For the record, my current hypothesis is that in verify_cgraph_node,
in condition

    else if (!e->callee->global.inlined_to
         && decl
         && cgraph_get_node (decl)
         && (e->callee->former_clone_of
         != cgraph_get_node (decl)->decl)
         && !clone_of_p (cgraph_node (decl),
                 e->callee))

the (e->callee->former_clone_of != cgraph_get_node (decl)->decl) is
insufficient in the sense that it should be accompanied with 

&& (!e->callee->former_clone_of
    || (e->callee->former_clone_of
        != cgraph_get_node (decl)->former_clone_of))


Basically what happens that cgraph_node (decl) and e->callee have the
same former_clone_of one is not clone of each other.  I am now about
to investigate how exactly this appears in the IL to be sure it can
actually happen legitimately.

[Bug middle-end/46823] [4.6 Regression] ICE: edge points to wrong declaration

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823

--- Comment #9 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-01-07 16:57:45 UTC ---
Please disregard the previous comment, I thought that was the case
because of a typo.

[Bug middle-end/46823] [4.6 Regression] ICE: edge points to wrong declaration

[hubicka at ucw dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823

--- Comment #10 from Jan Hubicka <hubicka at ucw dot cz> 2011-01-07 18:13:33 UTC ---
> Basically what happens that cgraph_node (decl) and e->callee have the
> same former_clone_of one is not clone of each other.  I am now about
> to investigate how exactly this appears in the IL to be sure it can
> actually happen legitimately.

Hmm, how this happens?  The call statement should not point to clones
since it should stay intact from early optimization.

Honza

[Bug middle-end/46823] [4.6 Regression] ICE: edge points to wrong declaration

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823

--- Comment #11 from Jan Hubicka <hubicka at gcc dot gnu.org> 2011-01-07 21:01:53 UTC ---
It does not reproduce for me, perhaps it was fixed by the recursive inliner
fix?

[Bug middle-end/46823] [4.6 Regression] ICE: edge points to wrong declaration

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823

--- Comment #12 from Marc Glisse <marc.glisse at normalesup dot org> 2011-01-07 23:47:35 UTC ---
(In reply to comment #11)
> It does not reproduce for me, perhaps it was fixed by the recursive inliner
> fix?

Did you try with a.cc? ouin.cc hasn't reproduced for a while. I just checked
after your latest commit (168587) and still got the error.

[Bug middle-end/46823] [4.6 Regression] ICE: edge points to wrong declaration

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823

--- Comment #13 from Jan Hubicka <hubicka at gcc dot gnu.org> 2011-01-08 00:23:28 UTC ---
I tested only the reduced testcase, but it still seems to work for me
jh@gcc10:~/trunk/build/gcc$ ./xgcc -B ./ -O2  a.cc -S  -frounding-math
a.cc:68:19: warning: inline function 'bool CGAL::possibly(bool)' used but never
defined [enabled by default]
a.cc:345:39: warning: inline function 'bool
CGAL::internal::may_have_common_factor(const CGAL::Polynomial<NT>&, const
CGAL::Polynomial<NT>&) [with NT =
CGAL::Polynomial<CGAL::Polynomial<CORE::BigInt> >]' used but never defined
[enabled by default]
a.cc:345:39: warning: inline function 'bool
CGAL::internal::may_have_common_factor(const CGAL::Polynomial<NT>&, const
CGAL::Polynomial<NT>&) [with NT = CGAL::Polynomial<CORE::BigInt>]' used but
never defined [enabled by default]
a.cc:345:39: warning: inline function 'bool
CGAL::internal::may_have_common_factor(const CGAL::Polynomial<NT>&, const
CGAL::Polynomial<NT>&) [with NT = CORE::BigInt]' used but never defined
[enabled by default]
jh@gcc10:~/trunk/build/gcc$ grep CHECKING auto-host.h 
#define ENABLE_ASSERT_CHECKING 1
#define ENABLE_CHECKING 1
/* #undef ENABLE_DF_CHECKING */
/* #undef ENABLE_FOLD_CHECKING */
#define ENABLE_GC_CHECKING 1
#define ENABLE_GIMPLE_CHECKING 1
/* #undef ENABLE_RTL_CHECKING */
#define ENABLE_RTL_FLAG_CHECKING 1
#define ENABLE_RUNTIME_CHECKING 1
#define ENABLE_TREE_CHECKING 1
#define ENABLE_TYPES_CHECKING 1
/* #undef ENABLE_VALGRIND_CHECKING */

well, hopefully Martin has better luck reproducing this...

[Bug middle-end/46823] [4.6 Regression] ICE: edge points to wrong declaration

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823

--- Comment #14 from Jan Hubicka <hubicka at gcc dot gnu.org> 2011-01-08 00:24:34 UTC ---
huh, -O2 instead of -O3.  It reproduces for me now. Sorry for noise.

[Bug middle-end/46823] [4.6 Regression] ICE: edge points to wrong declaration

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823

--- Comment #15 from Jan Hubicka <hubicka at gcc dot gnu.org> 2011-01-08 00:35:03 UTC ---
OK, both decl and e->callee->former_clone_of points to decls that are not
clones.
(gdb) p debug_tree (decl->decl_with_vis.assembler_name)
 <identifier_node 0x7ffff76e7420
_ZN4CGAL10PolynomialINS0_INS0_IN4CORE6BigIntEEEEEEC1IS4_EERKT_ bindings <(nil)>
local bindings <(nil)>>
$14 = void
(gdb) p debug_tree (e->callee->former_clone_of->decl_with_vis.assembler_name)
 <identifier_node 0x7ffff76e73c8
_ZN4CGAL10PolynomialINS0_INS0_IN4CORE6BigIntEEEEEEC2IS4_EERKT_ bindings <(nil)>
local bindings <(nil)>>
$15 = void
(gdb) 
[2]+  Stopped                 gdb --args ./cc1plus -quiet -v -iprefix
/home/jh/trunk/build/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.6.0/ -isystem
./include -isystem ./include-fixed -D_GNU_SOURCE a.cc -quiet -dumpbase a.cc
-mtune=generic -march=x86-64 -auxbase a -O3 -version -frounding-math -o a.s
jh@gcc10:~/trunk/build/gcc$ c++filt 
_ZN4CGAL10PolynomialINS0_INS0_IN4CORE6BigIntEEEEEEC1IS4_EERKT_
CGAL::Polynomial<CGAL::Polynomial<CGAL::Polynomial<CORE::BigInt> >
>::Polynomial<CGAL::Polynomial<CGAL::Polynomial<CORE::BigInt> >
>(CGAL::Polynomial<CGAL::Polynomial<CORE::BigInt> > const&)
_ZN4CGAL10PolynomialINS0_INS0_IN4CORE6BigIntEEEEEEC2IS4_EERKT_
CGAL::Polynomial<CGAL::Polynomial<CGAL::Polynomial<CORE::BigInt> >
>::Polynomial<CGAL::Polynomial<CGAL::Polynomial<CORE::BigInt> >
>(CGAL::Polynomial<CGAL::Polynomial<CORE::BigInt> > const&)

it seems to me that only way this can happen is devirtualizing choosing one
variant at IPA mode while other variant in intra-procedural mode during
inlining. 

I guess at least one solution should be buggy?

So it is really Martin's ;)

[Bug middle-end/46823] [4.6 Regression] ICE: edge points to wrong declaration

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823

--- Comment #16 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-01-10 20:34:14 UTC ---
The problem seems to be a different one.  During IPA decision making
we decide to clone a function and the call graph node of the original
one is then removed as unreachable an unnecessary.  However, its
declaration stays in the IL until the transformation phase where
expand_call_inline calls cgraph_node() on it which creates a new,
seemingly entirely separate call graph node.  This is then what the
verifier gets for the decl, cannot find any relation between what the
edge points to and the new node and errors out.

We cannot simply replace the call to cgraph_node with cgraph_get_node
and bail out if it returns NULL because the call is supposed to be
inlined and this is then asserted later.  The information about the
call just happens to be stored in the call graph edge and the fndecl
in the gimple statement is not necessarily relevant at all.  So the
fix which I am testing at the moment just extracts the target
declaration from the call graph, bypassing whatever is in the
statement.

I will submit this patch tomorrow if it passes bootstrap and testing.


2011-01-10  Martin Jambor  <mjambor@suse.cz>

    PR middle-end/46823
    * tree-inline.c (expand_call_inline): Get fndecl from call graph edge.

Index: icln/gcc/tree-inline.c
===================================================================
--- icln.orig/gcc/tree-inline.c
+++ icln/gcc/tree-inline.c
@@ -3783,14 +3783,19 @@ expand_call_inline (basic_block bb, gimp
   if (gimple_code (stmt) != GIMPLE_CALL)
     goto egress;

+  /* Objective C and fortran still calls tree_rest_of_compilation directly.
+     Kill this check once this is fixed.  */
+  if (!id->dst_node->analyzed)
+    goto egress;
+
+  cg_edge = cgraph_edge (id->dst_node, stmt);
+  gcc_checking_assert (cg_edge);
   /* First, see if we can figure out what function is being called.
      If we cannot, then there is no hope of inlining the function.  */
-  fn = gimple_call_fndecl (stmt);
-  if (!fn)
+  if (cg_edge->indirect_unknown_callee)
     goto egress;
-
-  /* Turn forward declarations into real ones.  */
-  fn = cgraph_node (fn)->decl;
+  fn = cg_edge->callee->decl;
+  gcc_checking_assert (fn);

   /* If FN is a declaration of a function in a nested scope that was
      globally declared inline, we don't set its DECL_INITIAL.
@@ -3804,13 +3809,6 @@ expand_call_inline (basic_block bb, gimp
       && gimple_has_body_p (DECL_ABSTRACT_ORIGIN (fn)))
     fn = DECL_ABSTRACT_ORIGIN (fn);

-  /* Objective C and fortran still calls tree_rest_of_compilation directly.
-     Kill this check once this is fixed.  */
-  if (!id->dst_node->analyzed)
-    goto egress;
-
-  cg_edge = cgraph_edge (id->dst_node, stmt);
-
   /* First check that inlining isn't simply forbidden in this case.  */
   if (inline_forbidden_into_p (cg_edge->caller->decl, cg_edge->callee->decl))
     goto egress;

[Bug middle-end/46823] [4.6 Regression] ICE: edge points to wrong declaration

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823

--- Comment #17 from Jan Hubicka <hubicka at gcc dot gnu.org> 2011-01-11 13:29:58 UTC ---
I believed that we are supposed to update the statement first and only then try
to inline it. Otherwise we would get into problem with inliner not skipping the
args.

Anyway lookup based on call statement is good idea, but we need to resolve the
problem above.

[Bug middle-end/46823] [4.6 Regression] ICE: edge points to wrong declaration

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823

--- Comment #18 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-01-12 13:50:11 UTC ---
You're right, however in fact all redirections and updates should be
taking place already.  Either in inline_transform() for calls that are
in the function from the beginning of inlining or later when new ones
are added in copy_bb().

So I was looking for why this one did not and figured out that they
are original calls, cgraph_redirect_edge_call_stmt_to_callee() is called
on their edges but it returns immediately because of this condition:

cgraph_get_node (decl) == cgraph_get_node (e->callee->decl)

It is satisfied because the declaration in the IL is an alias, the
function returns and the alias decl stays in the IL.  But e->callee is
not the node that the alias cgraph_node aliases, it is another inline
clone instead.  And the aliased node is also scheduled to be inlined.

After it is inlined, the node is removed together with its alias nodes
and from that point on there is no cgraph_node for the alias
declaration and so when it is stumbled on another time, cgraph_node()
function creates a new one and the verifier explodes.

I therefore propose to remove the quoted condition from
cgraph_redirect_edge_call_stmt_to_callee().  It was originally added
by Jakub in his fix for PR 42508 with a comment (#4) saying:

"The cgraphunit.c hunk is only somewhat related, is not necessary to
fix this, I've just noticed that the function was still modifying
GIMPLE_CALL decl unnecessarily (and confusingly), when e->callee is an
inline clone of some cgraph node with same_body aliases and
GIMPLE_CALL calls the same_body alias."

Nevertheless, my patch in comment #16 is also OK (and would save a bit
of unnecessary work) because the call statement is not updated only if
it is not necessary because still the same old function is being
called, just through an alias of what is now an inline clone.

So Honza, what do you prefer?

[Bug middle-end/46823] [4.6 Regression] ICE: edge points to wrong declaration

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823

--- Comment #19 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-01-13 10:35:33 UTC ---
(In reply to comment #16)
> The problem seems to be a different one.  During IPA decision making
> we decide to clone a function and the call graph node of the original
> one is then removed as unreachable an unnecessary.  However, its
> declaration stays in the IL until the transformation phase where
> expand_call_inline calls cgraph_node() on it which creates a new,
> seemingly entirely separate call graph node.  This is then what the
> verifier gets for the decl, cannot find any relation between what the
> edge points to and the new node and errors out.
> 
> We cannot simply replace the call to cgraph_node with cgraph_get_node
> and bail out if it returns NULL because the call is supposed to be
> inlined and this is then asserted later.  The information about the
> call just happens to be stored in the call graph edge and the fndecl
> in the gimple statement is not necessarily relevant at all.  So the
> fix which I am testing at the moment just extracts the target
> declaration from the call graph, bypassing whatever is in the
> statement.
> 
> I will submit this patch tomorrow if it passes bootstrap and testing.
> 
> 
> 2011-01-10  Martin Jambor  <mjambor@suse.cz>
> 
>     PR middle-end/46823
>     * tree-inline.c (expand_call_inline): Get fndecl from call graph edge.
> 
> Index: icln/gcc/tree-inline.c
> ===================================================================
> --- icln.orig/gcc/tree-inline.c
> +++ icln/gcc/tree-inline.c
> @@ -3783,14 +3783,19 @@ expand_call_inline (basic_block bb, gimp
>    if (gimple_code (stmt) != GIMPLE_CALL)
>      goto egress;
> 
> +  /* Objective C and fortran still calls tree_rest_of_compilation directly.
> +     Kill this check once this is fixed.  */
> +  if (!id->dst_node->analyzed)
> +    goto egress;
> +
> +  cg_edge = cgraph_edge (id->dst_node, stmt);
> +  gcc_checking_assert (cg_edge);
>    /* First, see if we can figure out what function is being called.
>       If we cannot, then there is no hope of inlining the function.  */
> -  fn = gimple_call_fndecl (stmt);
> -  if (!fn)
> +  if (cg_edge->indirect_unknown_callee)
>      goto egress;
> -
> -  /* Turn forward declarations into real ones.  */
> -  fn = cgraph_node (fn)->decl;
> +  fn = cg_edge->callee->decl;
> +  gcc_checking_assert (fn);
> 
>    /* If FN is a declaration of a function in a nested scope that was
>       globally declared inline, we don't set its DECL_INITIAL.
> @@ -3804,13 +3809,6 @@ expand_call_inline (basic_block bb, gimp
>        && gimple_has_body_p (DECL_ABSTRACT_ORIGIN (fn)))
>      fn = DECL_ABSTRACT_ORIGIN (fn);
> 
> -  /* Objective C and fortran still calls tree_rest_of_compilation directly.
> -     Kill this check once this is fixed.  */
> -  if (!id->dst_node->analyzed)
> -    goto egress;
> -
> -  cg_edge = cgraph_edge (id->dst_node, stmt);
> -
>    /* First check that inlining isn't simply forbidden in this case.  */
>    if (inline_forbidden_into_p (cg_edge->caller->decl, cg_edge->callee->decl))
>      goto egress;

Err - I'm not sure what this

  /* Turn forward declarations into real ones.  */
  fn = cgraph_node (fn)->decl;

is about at all.  At least the comment doesn't make any sense to me.

But yes, the above makes sense to me.

[Bug middle-end/46823] [4.6 Regression] ICE: edge points to wrong declaration

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823

--- Comment #20 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-01-13 11:00:52 UTC ---
Based on Honza's comment #17 I proposed a different patch, making sure
we update the statement as expected, like I described in comment #18
and I have already posted it to the mailing list:

http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00789.html

[Bug middle-end/46823] [4.6 Regression] ICE: edge points to wrong declaration

[hubicka at ucw dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823

--- Comment #21 from Jan Hubicka <hubicka at ucw dot cz> 2011-01-13 16:49:42 UTC ---
> Err - I'm not sure what this
> 
>   /* Turn forward declarations into real ones.  */
>   fn = cgraph_node (fn)->decl;
> 
> is about at all.  At least the comment doesn't make any sense to me.

It is remainder from the times when we didn't have one decl rule. But these
days it still translates same body alises into the functions.

Actually in my comment in #17, I was not concernerned about edge pointing to
an alias, I was concerned about cgraph_redirect_edge_call_stmt_to_callee
possibly not happening before inlining.  This seems all fine.

Direct calls to same body aliases are OK and I agree with Jakub that we should
not redirect them to the actual function just for fun.

So the patch #16 is OK.
Thanks and sorry for confussion above.
Honza

[Bug middle-end/46823] [4.6 Regression] ICE: edge points to wrong declaration

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823

--- Comment #22 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-01-14 11:59:10 UTC ---
Author: jamborm
Date: Fri Jan 14 11:59:07 2011
New Revision: 168778

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168778
Log:
2011-01-14  Martin Jambor  <mjambor@suse.cz>

    PR middle-end/46823
    * tree-inline.c (expand_call_inline): Get fndecl from call graph edge.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-inline.c

[Bug middle-end/46823] [4.6 Regression] ICE: edge points to wrong declaration

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823

Martin Jambor <jamborm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #23 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-01-14 12:35:54 UTC ---
Hopefully finally fixed.