[Bug tree-optimization/60899] New: undef reference generated with -fdevirtualize-speculatively

[Bug tree-optimization/60899] New: undef reference generated with -fdevirtualize-speculatively

[xinliangli at gmail dot com]

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

            Bug ID: 60899
           Summary: undef reference generated with
                    -fdevirtualize-speculatively
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: xinliangli at gmail dot com

Build the following code with the following command line:

g++ -O2 -fdisable-tree-einline a.cc a_m.cc 

results in:

/tmp/cci31j3N.o: In function `D::doit()':
a.cc:(.text._ZN1D4doitEv[_ZN1D4doitEv]+0x5): undefined reference to `A::foo()'
collect2: error: ld returned 1 exit status

It builds fine when devirtualization is disabled:

-O2 -fno-devirtualization-speculatively -fdisable-tree-einline 


The problem is there is no instantiation of any class A instances (final or
subclass) in the program, so vtables and A::foo are all eliminated. The
reference to A::foo is from D::doit. In a successful build, there are no D
instances either, so D::doit won't be emitted. However with speculative
devirtualization, D::doit may be speculatively referenced even though there are
no D instances.

What happens is that during ipa-inline, goo is inlined into D::doit, the
virtual call to foo should become an direct call to A::foo, but the new edge is
not discovered. Since there is no call edge to A::foo, A::foo gets removed
right after ipa-inline (before inline transform). However during inline
transform, gimple-fold-call converts the virtual call into a direct call.


The test case is extracted from a very large real program. The explicit
reference to D::doit in bar is to demonstrate the problem -- in the real
program, the reference is from spec-devirt.


//a.h
struct B {
 virtual int foo() = 0;
 int goo() { return foo(); }
 int i;
};

struct A  : public B {
 A() : i(0)  {}
 int foo() { return 1;}
 int i;
};
struct A2  : public B {
 int foo() { return 2;}
};

struct DI {
  virtual int doit() = 0;
};

struct D : public DI {
   virtual int doit () { return m.goo(); }

   A m;
};

// a.cc

#include "a.h"

int cond;
int bar (DI* ap) {
   if (cond) return static_cast<D*>(ap)->D::doit();  // Mimic speculative
devirtualization
   return ap->doit();
}


// a_m.cc

#include "a.h"

int cond;
int bar (DI* ap) {
   if (cond) return static_cast<D*>(ap)->D::doit();  // Mimic speculative
devirtualization
   return ap->doit();
}

[Bug tree-optimization/60899] undef reference generated with -fdevirtualize-speculatively

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

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

--- Comment #1 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
David,
can you check if can_refer_decl_in_current_unit_p

[Bug tree-optimization/60899] undef reference generated with -fdevirtualize-speculatively

[hubicka at ucw dot cz]

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

--- Comment #2 from Jan Hubicka <hubicka at ucw dot cz> ---
David,
it seems a_m.C should be different form a.C.  From chain of events you describe
I think
we need to figure out why the last folding happens.  Does the function pass 
can_refer_decl_in_current_unit_p and if so, how does cgraph node look at that
time?

Honza

[Bug tree-optimization/60899] undef reference generated with -fdevirtualize-speculatively

[xinliangli at gmail dot com]

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

--- Comment #3 from davidxl <xinliangli at gmail dot com> ---
(In reply to Jan Hubicka from comment #2)
> David,
> it seems a_m.C should be different form a.C.  From chain of events you
> describe I think
> we need to figure out why the last folding happens.  Does the function pass 
> can_refer_decl_in_current_unit_p and if so, how does cgraph node look at
> that time?
> 
> Honza

Cut & paste error:

// a_m.cc

#include "a.h"
struct D2: public DI {
  virtual int doit () { return 3; }
};

extern int bar(DI*);
int main()
{
  D2 d2;
  return bar(&d2);
}

[Bug tree-optimization/60899] undef reference generated with -fdevirtualize-speculatively

[xinliangli at gmail dot com]

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

--- Comment #4 from davidxl <xinliangli at gmail dot com> ---
(In reply to davidxl from comment #3)
> (In reply to Jan Hubicka from comment #2)
> > David,
> > it seems a_m.C should be different form a.C.  From chain of events you
> > describe I think
> > we need to figure out why the last folding happens.  Does the function pass 
> > can_refer_decl_in_current_unit_p and if so, how does cgraph node look at
> > that time?
> > 
> > Honza
> 
> Cut & paste error:
> 
> // a_m.cc
> 
> #include "a.h"
> struct D2: public DI {
>   virtual int doit () { return 3; }
> };
> 
> extern int bar(DI*);
> int main()
> {
>   D2 d2;
>   return bar(&d2);
> }


stepping into can_refer_decl_in_current_unit_p indicates it returns true (for
A::foo and A::vtable) at the condition @line 106.

[Bug tree-optimization/60899] undef reference generated with -fdevirtualize-speculatively

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
I am running benchmarks I do not want to disturb, but the following should fix
the problem.
$ svn diff ../../gcc/gimple-fold.c
Index: ../../gcc/gimple-fold.c
===================================================================
--- ../../gcc/gimple-fold.c     (revision 209526)
+++ ../../gcc/gimple-fold.c     (working copy)
@@ -105,7 +105,9 @@ can_refer_decl_in_current_unit_p (tree d
      external var.  */
   if (!from_decl
       || TREE_CODE (from_decl) != VAR_DECL
-      || !DECL_EXTERNAL (from_decl)
+      || (!DECL_EXTERNAL (from_decl)
+         && (vnode = varpool_get_node (from_decl)) != NULL
+         && vnode->definition)
       || (flag_ltrans
          && symtab_get_node (from_decl)->in_other_partition))
     return true;

[Bug tree-optimization/60899] undef reference generated with -fdevirtualize-speculatively

[ppluzhnikov at google dot com]

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

Paul Pluzhnikov <ppluzhnikov at google dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ppluzhnikov at google dot com

--- Comment #6 from Paul Pluzhnikov <ppluzhnikov at google dot com> ---
Google ref: b/13453242

[Bug tree-optimization/60899] undef reference generated with -fdevirtualize-speculatively

[xinliangli at gmail dot com]

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

--- Comment #7 from davidxl <xinliangli at gmail dot com> ---
(In reply to Paul Pluzhnikov from comment #6)
> Google ref: b/13453242

Verified that the proposed patch fixed the problem in b/1345242.

[Bug tree-optimization/60899] undef reference generated with -fdevirtualize-speculatively

[hubicka at ucw dot cz]

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

--- Comment #8 from Jan Hubicka <hubicka at ucw dot cz> ---
> Verified that the proposed patch fixed the problem in b/1345242.

Great, thanks! I still would preffer to see DECL_EXTERNAL bit on vtable that is
not emit in the current unit. But C++ visibility code is bit of mess, so if
Jason think it is impractical to arrange it, lets go with this patch.

[Bug tree-optimization/60899] undef reference generated with -fdevirtualize-speculatively

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-04-22
     Ever confirmed|0                           |1

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.

[Bug tree-optimization/60899] undef reference generated with -fdevirtualize-speculatively

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60899

--- Comment #10 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Author: hubicka
Date: Wed May 21 06:16:03 2014
New Revision: 210676

URL: http://gcc.gnu.org/viewcvs?rev=210676&root=gcc&view=rev
Log:

    PR tree-optimization/60899
    * gimple-fold.c (can_refer_decl_in_current_unit_p): Cleanup;
    assume all static symbols will have definition wile parsing and
    check the do have definition later in compilation; check that
    variable referring symbol will be output before concluding that
    reference is safe; be conservative for referring local statics;
    be more precise about when comdat is output in other partition.

    g++.dg/ipa/devirt-11.C: Update template.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/gimple-fold.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/g++.dg/ipa/devirt-11.C

[Bug tree-optimization/60899] undef reference generated with -fdevirtualize-speculatively

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60899

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

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

--- Comment #12 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
(In reply to Hristo Venev from comment #11)
> This bug also affects gcc 4.9.1. It causes LLVM to fail to build.

LLVM build failure is a different issue, see:
http://llvm.org/bugs/show_bug.cgi?id=20067