[Bug middle-end/20991] New: ICE in cgraph_mark_reachable_node

[Bug middle-end/20991] New: ICE in cgraph_mark_reachable_node

[jakub at gcc dot gnu dot org]

Current gcc-4_0-branch (i.e. with PR20635 fix in) ICEs on the attached testcase
at -O3 -m32.  It is a recent regression (the assert was added 2005-03-18)
and prevents building Octave.
virtual std::string octave_value::class_name() const (this)
{
...
}
seen in *.generic dump seems to be unused until *.dom1 time (till then
Fissparse uses
  arg_106 = &D.101031;
  D.141412_107 = arg_106->_vptr.octave_value;
  D.141413_108 = D.141412_107 + 468B;
  D.141414_109 = *D.141413_108;
  OBJ_TYPE_REF(D.141414_109;arg_106->117) (&D.141411, arg_106) [return slot
addr];
and only in the first dominator pass this gets changed into:
  arg_175 = &arg;
  D.131589_176 = arg._vptr.octave_value;
  D.131590_177 = D.131589_176 + 468B;
  D.131591_178 = *D.131590_177;
  class_name (&D.131588, &arg) [return slot addr];
but cgraph does not know about this call until Fissparse's assembly is emitted.
But at that point cgraph_global_info_ready is already true, therefore the ICE.

-- 
           Summary: ICE in cgraph_mark_reachable_node
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P2
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jakub at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org,hubicka at gcc dot gnu
                    dot org
GCC target triplet: i386-redhat-linux


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

[Bug middle-end/20991] ICE in cgraph_mark_reachable_node

[jakub at gcc dot gnu dot org]

------- Additional Comments From jakub at gcc dot gnu dot org  2005-04-13 13:28 -------
Created an attachment (id=8617)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8617&action=view)
Testcase


-- 


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

[Bug middle-end/20991] [4.0/4.1 Regression] ICE in cgraph_mark_reachable_node

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
            Summary|ICE in                      |[4.0/4.1 Regression] ICE in
                   |cgraph_mark_reachable_node  |cgraph_mark_reachable_node
   Target Milestone|---                         |4.0.0


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

[Bug middle-end/20991] [4.0/4.1 Regression] ICE in cgraph_mark_reachable_node

[jakub at gcc dot gnu dot org]

------- Additional Comments From jakub at gcc dot gnu dot org  2005-04-13 14:26 -------
Somewhat simplified testcase:

#include <vector>
#include <string>

struct A { int i; };
struct B { int i; };
struct C { int i; };
struct D { int i; };

struct E
{
  E (void);
  E (bool b);
  E (const A & m);
  virtual ~ E (void);
  virtual A m1 (bool x = false) const { return rep->m1 (x); }
  virtual B m2 (bool x = false) const { return rep->m2 (x); }
  virtual C m3 (bool x = false) const { return rep->m3 (x); }
  virtual D m4 (bool x = false) const { return rep->m4 (x); }
  virtual std::string m5 (void) const { return rep->m5 (); }
  virtual std::string m6 (void) const { return rep->m6 (); }
  union { E *rep; int count; };
};

struct F
{
  F (void) : data () {}
  F (const E & tc) : data (1, tc) {}
  F (const F & obj):data (obj.data) {}
  ~F (void) {}
  E operator  () (int n) const { return n2 (n); }
  int n1 (void) const { return data.size (); }
  std::vector < E > data;
  E n2 (int n) const { return data[n]; }
};

static bool foo (const E & arg) { return (arg.m6 () == "foo"); }
F bar (const F & args) { return E (foo (args (0))); }
F fn1 (const F & args)
{
  E retval;

  if (args (0).m6 () == "foo")
    retval = args (0).m1 ();

  return retval;
}

static F f2 (const B & v) { F retval; return retval; }
static F f2 (const C & v) { F retval; return retval; }
static F f2 (const D & v) { F retval; return retval; }

F
f3 (const F & x)
{
  F retval;
  int n = x.n1 ();

  if (n != 1)
    return retval;

  E arg = x (0);
  if (arg.m6 () == "foo")
    {
      if (arg.m5 () == "bar")
        retval = f2 (x (0).m2 ());
      else if (arg.m5 () == "baz")
        retval = f2 (x (0).m3 ());
      else
        retval = f2 (x (0).m4 ());
    }

  return retval;
}


-- 


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

[Bug middle-end/20991] [4.0/4.1 Regression] ICE in cgraph_mark_reachable_node

[dmitri at unm dot edu]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dmitri at unm dot edu


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

[Bug middle-end/20991] [4.0/4.1 Regression] ICE in cgraph_mark_reachable_node

[commie1 at gmx dot net]

------- Additional Comments From commie1 at gmx dot net  2005-04-14 12:35 -------
Your simplified testcase only causes an ICE when I use the C++ headers from gcc
3.4.3 with gcc 4.0.0, otherwise it works fine.

ICE: /opt/gcc40/bin/g++ -O -finline-functions test.cc -c -o test.o -isystem
/usr/include/c++/3.4.3

No ICE: /opt/gcc40/bin/g++ -O -finline-functions test.cc -c -o test.o

So you should be able to build Octave without problems...

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |commie1 at gmx dot net


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

[Bug middle-end/20991] [4.0/4.1 Regression] ICE in cgraph_mark_reachable_node

[matz at suse dot de]

------- Additional Comments From matz at suse dot de  2005-04-15 02:40 -------
We see this error in blender.  I was able to reduce it quite a bit to this: 
 
struct IMG_Rect { 
 virtual inline int getWidth() const; 
 virtual inline bool isEmpty() const; 
 virtual int getVisibility(int) const; 
}; 
 
inline int IMG_Rect::getWidth() const 
{ 
 return 1; 
} 
 
inline bool IMG_Rect::isEmpty() const 
{ 
 return (getWidth() == 0); 
} 
 
void A() 
{ 
 IMG_Rect i_bnds; 
 if (i_bnds.isEmpty()) 
  i_bnds.getWidth(); 
} 
 
void B() 
{ 
 IMG_Rect i_bnds; 
 if (i_bnds.isEmpty()) 
  i_bnds.getWidth(); 
} 
 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matz at suse dot de


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

[Bug middle-end/20991] [4.0/4.1 Regression] ICE in cgraph_mark_reachable_node

[matz at suse dot de]

------- Additional Comments From matz at suse dot de  2005-04-15 03:16 -------
One strange thing is, that the call to getWidth() in B is already in .generic: 
    if (retval.1) 
      { 
        getWidth (&i_bnds); 
      } 
 
while the call to getWidth() in isEmpty() (which is inlined later into B()) is 
  D.1595 = this->_vptr.IMG_Rect; 
  D.1596 = *D.1595; 
  D.1597 = OBJ_TYPE_REF(D.1596;this->0) (this); 
  D.1594 = D.1597 == 0; 
 
Both are actually virtual calls of course, so I wonder why they are represented 
differently.  Note that this doesn't change if I make B() a method of IMG_Rect. 
I thought initially that might be a difference, as isEmpty is one. 
 
Another fact is, that if I comment out the totally unrelated useless decl for 
getVisibility(), it works.  The .i01.cgraph dump in that case shows these 
  Initial entry points: void B() void A() 
  Unit entry points: void B() void A() virtual bool IMG_Rect::isEmpty() const 
    virtual int IMG_Rect::getWidth() const 
 
while when it breaks (i.e. when getVisibility is there) it looks like: 
  Initial entry points: void B() void A() 
  Unit entry points: void B() void A() 
 
See how the two methods in question are now missing.  As they are declared inline this 
actually should be okay, and that getVisibility makes a difference might be another bug, 
which hides this one sometimes. 

-- 


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

[Bug middle-end/20991] [4.0 Regression] ICE in cgraph_mark_reachable_node

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-15 05:36 -------
Hmm, all of the testcases listed here work on the mainline.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |4.1.0
            Summary|[4.0/4.1 Regression] ICE in |[4.0 Regression] ICE in
                   |cgraph_mark_reachable_node  |cgraph_mark_reachable_node


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

[Bug middle-end/20991] [4.0 Regression] ICE in cgraph_mark_reachable_node

[matz at suse dot de]

------- Additional Comments From matz at suse dot de  2005-04-15 06:51 -------
Perhaps due to the IPA infrastructure? 

-- 


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

[Bug middle-end/20991] [4.0 Regression] ICE in cgraph_mark_reachable_node

[jakub at gcc dot gnu dot org]

------- Additional Comments From jakub at gcc dot gnu dot org  2005-04-17 16:08 -------
Just got another bugreport for this bug, this time in gnomesword,
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155152

The new references are created in tree-ssa-ccp.c's fold_stmt when it
constant propagates the vptr access, but that is already when
cgraph does not allow new references to be created.

The problem only happens in compilation units that don't output
the virtual table.  But for methods in virtual tables we know that the method
will be emitted in some other compilation unit (where the virtual table
gets emitted), so having the method finalized as unreferenced in
the current compilation unit is not a problem.

So, I think at least as a short time solution we can add a flag to cgraph
node that will signalize that the function is guaranteed to be emitted
in some other CU.  This flag would be set in cp_fold_obj_type_ref
and cgraph_mark_reachable_node would only do something about such nodes
if they have needed set or !cgraph_global_info_ready.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mmitchel at gcc dot gnu dot
                   |                            |org


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

[Bug middle-end/20991] [4.0 Regression] ICE in cgraph_mark_reachable_node

[mark at codesourcery dot com]

------- Additional Comments From mark at codesourcery dot com  2005-04-17 17:04 -------
Subject: Re:  [4.0 Regression] ICE in cgraph_mark_reachable_node

jakub at gcc dot gnu dot org wrote:
> ------- Additional Comments From jakub at gcc dot gnu dot org  2005-04-17 16:08 -------
> Just got another bugreport for this bug, this time in gnomesword,
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155152
> 
> The new references are created in tree-ssa-ccp.c's fold_stmt when it
> constant propagates the vptr access, but that is already when
> cgraph does not allow new references to be created.

The easiest solution, then, might be not to do the constant propagation 
in that case.  That seems like it would attack the problem directly and 
locally.  It would of course result in inferior code, but this is a case 
that C++ compilers have traditionally been lame about, so it's not 
really a step backwards.

It also sounds like you might be able to come up with a C test case. 
The basic flaw is that cgraph is not expecting an apparently 
unreferenced function to become referenced as a result of the optimizers 
figuring out to what function a pointer pointers.  That's a bug in 
cgraph; it should conservatively assume that all functions whose address 
has been taken are referenced.  It doesn't have to emit them, or even 
process them until it knows they are referenced, but it shouldn't assume 
that they're not needed until all points-to analysis is complete. 
Perhaps it needs a tri-state (referenced, not referenced, don't know).



-- 


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

[Bug middle-end/20991] [4.0 Regression] ICE in cgraph_mark_reachable_node

[jakub at gcc dot gnu dot org]

------- Additional Comments From jakub at gcc dot gnu dot org  2005-04-17 21:28 -------
On HEAD this doesn't fail any longer because of the:
* final.c (output_addr_const): Do not call mark_referenced.
change (part of tree profiling branch merge).

I don't think you can construct a C testcase for this, as soon as you save
some function's address into some reachable variable or take it in
some reachable function, cgraph will know about it.  The OBJ_TYPE_REF is special
in that there is no such variable in the current translation unit
and cp_fold_obj_type_ref just knows what is in the variable (vtable) in
some other translation unit and optimizes that access.

Of course we can
I'm ATM testing 2 different patches, will attach them here once the testing
finishes.

-- 


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

[Bug middle-end/20991] [4.0 Regression] ICE in cgraph_mark_reachable_node

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-17 21:34 -------
Confirmed, just a note the patch which "fixes" this on the mainline is wrong as shown by PR 20965.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-04-17 21:34:28
               date|                            |


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

[Bug middle-end/20991] [4.0 Regression] ICE in cgraph_mark_reachable_node

[mark at codesourcery dot com]

------- Additional Comments From mark at codesourcery dot com  2005-04-17 21:52 -------
Subject: Re:  [4.0 Regression] ICE in cgraph_mark_reachable_node

jakub at gcc dot gnu dot org wrote:

> some reachable function, cgraph will know about it.  The OBJ_TYPE_REF is special
> in that there is no such variable in the current translation unit
> and cp_fold_obj_type_ref just knows what is in the variable (vtable) in
> some other translation unit and optimizes that access.

So, perhaps one approach would be to have cgraph recognize the 
OBJ_TYPE_REF, and mark as reachable all things reachable from the 
vtable.  Not that this would necessarily be trivial to implement.



-- 


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

[Bug middle-end/20991] [4.0 Regression] ICE in cgraph_mark_reachable_node

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2005-04-18 17:59 -------
The patch in Comment #13 is OK for 4.0.0.  It's a pessimization, but it's rather
more obviously correct.  Please apply forthwith.  Thanks.

-- 


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

[Bug middle-end/20991] [4.0 Regression] ICE in cgraph_mark_reachable_node

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-19 05:52 -------
Subject: Bug 20991

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-4_0-branch
Changes by:	jakub@gcc.gnu.org	2005-04-19 05:52:46

Modified files:
	gcc            : ChangeLog tree-ssa-ccp.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/g++.dg/opt: pr20991.C 

Log message:
	PR middle-end/20991
	* tree-ssa-ccp.c (fold_stmt): Don't optimize OBJ_TYPE_REFs if that
	would result in an already finalized unreachable node becoming
	reachable while cgraph_global_info_ready.
	
	* g++.dg/opt/pr20991.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.170&r2=2.7592.2.171
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-ccp.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.58&r2=2.58.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.128&r2=1.5084.2.129
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/pr20991.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1



-- 


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

[Bug middle-end/20991] [4.0 Regression] ICE in cgraph_mark_reachable_node

[mmitchel at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.0.0                       |4.0.1


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

[Bug middle-end/20991] [4.0 Regression] ICE in cgraph_mark_reachable_node

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-24 12:46 -------
Subject: Bug 20991

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-4_0-branch
Changes by:	jakub@gcc.gnu.org	2005-04-24 12:46:25

Modified files:
	gcc            : ChangeLog varasm.c cgraph.h tree-ssa-ccp.c 
	gcc/cp         : ChangeLog 

Log message:
	PR middle-end/20991
	* cgraph.h (cgraph_local_info): Add vtable_method field.
	* varasm.c (mark_decl_referenced): If cgraph_global_info_ready
	and node is vtable_method, finalized and not reachable, don't do
	anything.
	
	Revert:
	2005-04-18  Jakub Jelinek  <jakub@redhat.com>
	* tree-ssa-ccp.c (fold_stmt): Don't optimize OBJ_TYPE_REFs if that
	would result in an already finalized unreachable node becoming
	reachable while cgraph_global_info_ready.
	
	* class.c: Include cgraph.h.
	(cp_fold_obj_type_ref): Set node->local.vtable_method.
	* Make-lang.in (cgraph.o): Depend on $(CGRAPH_H).

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.186&r2=2.7592.2.187
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.477.6.8&r2=1.477.6.9
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cgraph.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.44.8.3&r2=1.44.8.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-ccp.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.58.2.1&r2=2.58.2.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4648.2.34&r2=1.4648.2.35



-- 


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

[Bug middle-end/20991] [4.0 Regression] ICE in cgraph_mark_reachable_node

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-24 22:06 -------
Subject: Bug 20991

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	jakub@gcc.gnu.org	2005-04-24 22:06:37

Modified files:
	gcc            : ChangeLog varasm.c cgraph.h 
	gcc/cp         : ChangeLog 
	gcc/testsuite  : ChangeLog 
	gcc/cp         : class.c Make-lang.in 
Added files:
	gcc/testsuite/g++.dg/opt: pr20991.C 

Log message:
	PR middle-end/20991
	* cgraph.h (cgraph_local_info): Add vtable_method field.
	* varasm.c (mark_decl_referenced): If cgraph_global_info_ready
	and node is vtable_method, finalized and not reachable, don't do
	anything.
	
	* class.c: Include cgraph.h.
	(cp_fold_obj_type_ref): Set node->local.vtable_method.
	* Make-lang.in (cgraph.o): Depend on $(CGRAPH_H).
	
	* g++.dg/opt/pr20991.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8440&r2=2.8441
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff?cvsroot=gcc&r1=1.504&r2=1.505
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cgraph.h.diff?cvsroot=gcc&r1=1.50&r2=1.51
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4721&r2=1.4722
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5392&r2=1.5393
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/class.c.diff?cvsroot=gcc&r1=1.713&r2=1.714
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/Make-lang.in.diff?cvsroot=gcc&r1=1.200&r2=1.201
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/pr20991.C.diff?cvsroot=gcc&r1=1.1&r2=1.2



-- 


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

[Bug middle-end/20991] [4.0 Regression] ICE in cgraph_mark_reachable_node

[jakub at gcc dot gnu dot org]

------- Additional Comments From jakub at gcc dot gnu dot org  2005-04-24 22:11 -------
Actually it failed on HEAD today (at least on ppc-linux).
Should be fixed on both 4.0 and HEAD CVS now though.

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


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