[Bug c++/38613] New: extern template suppresses VFT but should not

[Bug c++/38613] New: extern template suppresses VFT but should not

[hstong at ca dot ibm dot com]

Rejects valid.  The following test case fails to link because VFTs are missing.
Based on the C++0x draft (N2800), this program should compile, link and run
successfully.

This appears to be a problem with the GCC implementation of explicit
instantiation
declarations, i.e. extern template.

The source consists of one file with no #include.

> cat a.cpp
template <class T>
struct A {
   A();
   A(A const &);
   A &operator =(A const &);
   ~A();
   virtual int foo();
};

template <class T>
A<T>::A() { }

template <class T>
A<T>::A(A const &) { }

template <class T>
A<T> &A<T>::operator =(A const &) { return *this; }

template <class T>
A<T>::~A() { }

template <class T>
int A<T>::foo(void) {
   return 42;
}

// explicit instantiation declaration of a class does not affect the class
itself
// but is an explicit instantiation declaration of each of its members
extern template struct A<int>;

// we provide explicit instantiation definitions of all the members of struct
A<int> here
template A<int>::A();
template A<int>::A(A const &);
template A<int> &A<int>::operator =(A const &);
template A<int>::~A();
template int A<int>::foo();

int main(void) {
   A<int> a;  // constructor needs to set VFT for `a'
   return 0;
}

> /compilers/g++-4.3.2 -std=c++0x -v -c a.cpp -o a.o
Using built-in specs.
Target: powerpc64-unknown-linux-gnu
Configured with: /data/gcc/src/gcc-4.3.2/configure --prefix=/data/gcc
--program-suffix=-4.3.2 --disable-libssp --disable-libgcj
--enable-version-specific-runtime-libs --with-cpu=default32 --enable-secureplt
--with-long-double-128 --enable-shared --enable-__cxa_atexit
--enable-threads=posix --enable-languages=c,c++
Thread model: posix
gcc version 4.3.2 (GCC)
COLLECT_GCC_OPTIONS='-std=c++0x' '-v' '-c' '-o' 'a.o' '-shared-libgcc'
 /data/gcc/libexec/gcc/powerpc64-unknown-linux-gnu/4.3.2/cc1plus -quiet -v
-D_GNU_SOURCE -D__unix__ -D__gnu_linux__ -D__linux__ -Asystem=linux
-Asystem=unix -Asystem=posix a.cpp -msecure-plt -quiet -dumpbase a.cpp
-auxbase-strip a.o -std=c++0x -version -o
data/gcc/lib/gcc/powerpc64-unknown-linux-gnu/4.3.2/../../../../powerpc64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /data/gcc/lib/gcc/powerpc64-unknown-linux-gnu/4.3.2/include/c++

/data/gcc/lib/gcc/powerpc64-unknown-linux-gnu/4.3.2/include/c++/powerpc64-unknown-linux-gnu
 /data/gcc/lib/gcc/powerpc64-unknown-linux-gnu/4.3.2/include/c++/backward
 /usr/local/include
 /data/gcc/include
 /data/gcc/lib/gcc/powerpc64-unknown-linux-gnu/4.3.2/include
 /data/gcc/lib/gcc/powerpc64-unknown-linux-gnu/4.3.2/include-fixed
 /usr/include
End of search list.
GNU C++ (GCC) version 4.3.2 (powerpc64-unknown-linux-gnu)
        compiled by GNU C version 4.3.2, GMP version 4.1.4, MPFR version 2.2.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: d61d206a8be21ae59ecbfeb94562168a
COLLECT_GCC_OPTIONS='-std=c++0x' '-v' '-c' '-o' 'a.o' '-shared-libgcc'
 as -a32 -mppc -many -V -Qy -o a.o
data/gcc/libexec/gcc/powerpc64-unknown-linux-gnu/4.3.2/:/data/gcc/libexec/gcc/powerpc64-unknown-linux-gnu/4.3.2/:/data/gcc/libexec/gcc/powerpc64-unknown-linux-gnu/:/data/gcc/lib/gcc/powerpc64-unknown-linux-gnu/4.3.2/:/data/gcc/lib/gcc/powerpc64-unknown-linux-gnu/
LIBRARY_PATH=/data/gcc/lib/gcc/powerpc64-unknown-linux-gnu/4.3.2/:/data/gcc/lib/gcc/powerpc64-unknown-linux-gnu/4.3.2/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/data/gcc/lib/gcc/powerpc64-unknown-linux-gnu/4.3.2/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-std=c++0x' '-v' '-c' '-o' 'a.o' '-shared-libgcc'

> /compilers/g++-4.3.2 -std=c++0x -v a.o -o a.out
Using built-in specs.
Target: powerpc64-unknown-linux-gnu
Configured with: /data/gcc/src/gcc-4.3.2/configure --prefix=/data/gcc
--program-suffix=-4.3.2 --disable-libssp --disable-libgcj
--enable-version-specific-runtime-libs --with-cpu=default32 --enable-secureplt
--with-long-double-128 --enable-shared --enable-__cxa_atexit
--enable-threads=posix --enable-languages=c,c++
Thread model: posix
gcc version 4.3.2 (GCC)
COMPILER_PATH=/data/gcc/libexec/gcc/powerpc64-unknown-linux-gnu/4.3.2/:/data/gcc/libexec/gcc/powerpc64-unknown-linux-gnu/4.3.2/:/data/gcc/libexec/gcc/powerpc64-unknown-linux-gnu/:/data/gcc/lib/gcc/powerpc64-unknown-linux-gnu/4.3.2/:/data/gcc/lib/gcc/powerpc64-unknown-linux-gnu/
LIBRARY_PATH=/data/gcc/lib/gcc/powerpc64-unknown-linux-gnu/4.3.2/:/data/gcc/lib/gcc/powerpc64-unknown-linux-gnu/4.3.2/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/data/gcc/lib/gcc/powerpc64-unknown-linux-gnu/4.3.2/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-std=c++0x' '-v' '-o' 'a.out' '-shared-libgcc'
 /data/gcc/libexec/gcc/powerpc64-unknown-linux-gnu/4.3.2/collect2
--eh-frame-hdr -V -Qy -m elf32ppclinux -dynamic-linker /lib/ld.so.1 -o a.out
/usr/lib/../lib/crt1.o /usr/lib/../lib/crti.o
/data/gcc/lib/gcc/powerpc64-unknown-linux-gnu/4.3.2/crtbegin.o
-L/data/gcc/lib/gcc/powerpc64-unknown-linux-gnu/4.3.2
-L/data/gcc/lib/gcc/powerpc64-unknown-linux-gnu/4.3.2/../../../../lib
-L/lib/../lib -L/usr/lib/../lib
-L/data/gcc/lib/gcc/powerpc64-unknown-linux-gnu/4.3.2/../../.. a.o -lstdc++ -lm
-lgcc_s -lgcc -lc -lgcc_s -lgcc
/data/gcc/lib/gcc/powerpc64-unknown-linux-gnu/4.3.2/crtsavres.o
/data/gcc/lib/gcc/powerpc64-unknown-linux-gnu/4.3.2/crtend.o
/usr/lib/../lib/crtn.o
GNU ld version 2.16.91.0.5 20051219 (SUSE Linux)
  Supported emulations:
   elf32ppclinux
   elf32ppc
   elf32ppcsim
   elf64alpha
   alpha
   armelf_linux
   armelf
   hppalinux
   elf_i386
   i386linux
   elf64_ia64
   m68kelf
   m68klinux
   elf64ppc
   elf_s390
   elf64_s390
   elf32_sparc
   sparclinux
   elf64_sparc
   sun4
   elf_x86_64
   ppcmacosa.o: In function `A<int>::A()':
a.cpp:(.text._ZN1AIiEC2Ev[A<int>::A()]+0x16): undefined reference to `vtable
for A<int>'
a.cpp:(.text._ZN1AIiEC2Ev[A<int>::A()]+0x1a): undefined reference to `vtable
for A<int>'
a.o: In function `A<int>::A()':
a.cpp:(.text._ZN1AIiEC1Ev[A<int>::A()]+0x16): undefined reference to `vtable
for A<int>'
a.cpp:(.text._ZN1AIiEC1Ev[A<int>::A()]+0x1a): undefined reference to `vtable
for A<int>'
a.o: In function `A<int>::A(A<int> const&)':
a.cpp:(.text._ZN1AIiEC2ERKS0_[A<int>::A(A<int> const&)]+0x1a): undefined
reference to `vtable for A<int>'
a.o:a.cpp:(.text._ZN1AIiEC2ERKS0_[A<int>::A(A<int> const&)]+0x1e): more
undefined references to `vtable for A<int>' follow
collect2: ld returned 1 exit status


-- 
           Summary: extern template suppresses VFT but should not
           Product: gcc
           Version: 4.3.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hstong at ca dot ibm dot com
 GCC build triplet: powerpc64-suse-linux
  GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu


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

[Bug c++/38613] extern template suppresses VFT but should not

[hstong at ca dot ibm dot com]

------- Comment #1 from hstong at ca dot ibm dot com  2008-12-23 21:34 -------
Created an attachment (id=16975)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16975&action=view)
Original test case

Original test case entered in description.


-- 


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

[Bug c++/38613] extern template suppresses VFT but should not

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2008-12-23 22:23 -------
According to http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1987.htm

You need to instantiation declaration the whole class and not just the member
functions.  Or at least the way I read it.


-- 


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

[Bug c++/38613] extern template suppresses VFT but should not

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2008-12-23 22:56 -------
>// we provide explicit instantiation definitions of all the members of struct

Yes but not the class itself.


-- 


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

[Bug c++/38613] extern template suppresses VFT but should not

[hstong at ca dot ibm dot com]

------- Comment #4 from hstong at ca dot ibm dot com  2008-12-23 22:57 -------
The proposed wording (N1987) for 14.7.2 paragraph 7 says:

An explicit instantiation declaration that names a class template
specialization has no effect on the class template specialization itself
(except for perhaps resulting in its implicit instantiation).

It also says:

An explicit instantiation that names a class template specialization is an
explicit instantiation of the same kind (declaration or definition) of each of
its members that has not been previously explicitly specialized in the
translation unit containing the explicit specialization, except as described
below.

====

This leads to an interpretation where explicit instantiation declaration of a
class template specialization is equivalent to doing the same to any and all of
its members.  Of course, the user cannot explicitly do so for each of the
members if implicitly declared member functions are present.


-- 


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

[Bug c++/38613] extern template suppresses VFT but should not

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2008-12-23 23:21 -------
If that is true then GCC get even explicit instantiation declarations wrong in
general.  Because of the way declaration and definitions are defined.


-- 


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

[Bug c++/38613] extern template suppresses VFT but should not

[hstong at ca dot ibm dot com]

------- Comment #6 from hstong at ca dot ibm dot com  2008-12-24 00:04 -------
(In reply to comment #5)

If you mean the lack of a diagnostic for a violation of a diagnosable rule in
the following self-contained source, then yes.  (Comeau produces a diagnostic
for this violation of N2800 14.7.2 [temp.explicit] paragraph 10.)

Please advise if a separate bug report should be opened.

SOURCE:
template <class T>
struct A {
  A();
};

template <class T>
A<T>::A() { }

template A<int>::A();  // explicit instantiation definition before
extern template struct A<int>;  // explicit instantiation declaration

int main(void) {
   return 0;
}


-- 


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

[Bug c++/38613] extern template suppresses VFT but should not

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2008-12-24 01:04 -------
>If you mean the lack of a diagnostic for a violation of a diagnosable rule in
> the following self-contained source, then yes. 

No I mean in the standard C++98 mode which had the same mention about explicit
instantiation definition (rather than declaration which is what extern template
is).  From the sound of it we need to always emit the vtable which means we
will cause more code bloat ....

CCing Jason to get his thoughts about this.


-- 

pinskia at gcc dot gnu dot org changed:

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


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

[Bug c++/38613] extern template suppresses VFT but should not

[jason at gcc dot gnu dot org]

------- Comment #8 from jason at gcc dot gnu dot org  2008-12-29 19:56 -------
C++98 does not exclude the GCC behavior: it only says

  The explicit instantiation of a class template specialization implies the
instantiation of all of its members not previously explicitly specialized in
the translation unit containing the explicit instantiation.

I'm going to raise a core issue about the C++0x situation.


-- 


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

[Bug c++/38613] extern template suppresses VFT but should not

[jason at gcc dot gnu dot org]

------- Comment #9 from jason at gcc dot gnu dot org  2008-12-31 18:35 -------
Discussion on the Core reflector suggests that the G++ behavior is what people
expect, and that we should fix the new wording to reflect that.

One commenter pointed out that 14.7.2/10 says that "An entity that is the
subject of an explicit instantiation declaration and that is also used in the
translation unit shall be the subject of an explicit instantiation definition
somewhere in the program; otherwise the program is ill-formed, no diagnostic
required."

A<int> is the subject of an explicit instantiation declaration but not
definition, so the testcase is ill-formed.


-- 

jason at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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