[Bug target/63874] New: vtable address generation goes through memory

[Bug target/63874] New: vtable address generation goes through memory

[pinskia at gcc dot gnu.org]

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

            Bug ID: 63874
           Summary: vtable address generation goes through memory
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pinskia at gcc dot gnu.org
            Target: aarch64

Take:
struct a
{
  virtual void f(void);
  virtual ~a();
};
struct b : a
{
  virtual void f(void);
  virtual ~b();
};
void b::f(void){}
b::~b(void){}

Currently b::~b() produces:
_ZN1bD2Ev:
.LFB2:
    .cfi_startproc
    ldr    x1, .LC0
    str    x1, [x0]
    b    _ZN1aD2Ev
    .cfi_endproc

This really should be:
_ZN1bD2Ev:
.LFB1:
    .cfi_startproc
    adrp    x1, _ZTV1b+16
    add    x1, x1, :lo12:_ZTV1b+16
    str    x1, [x0]
    b    _ZN1aD2Ev

Which is produced if I don't have a definition of b::f() in the same TU causing
the vtable not to be defined weak in this TU.

[Bug target/63874] vtable address generation goes through memory

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-11-17
                 CC|                            |ramana at gcc dot gnu.org
     Ever confirmed|0                           |1

[Bug target/63874] vtable address generation goes through memory

[rearnsha at gcc dot gnu.org]

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

--- Comment #1 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
Sounds like this might be confusion between weak definitions and weak
references.  If we have a weak reference to the object, we cannot convert it
into a pc-relative expression, since that would mean we couldn't detect NULL. 
However, if we have a non-weak reference to a weak object we can replace that
with a pc-relative addressing mode, _provided_ that we can guarantee that the
definition will appear in the same link unit (ie it's not part of building a
DSO).