code gen logic for virtual members when optimizing?

[Marat Boshernitsan <maratb at CS dot Berkeley dot EDU>]

Hi,

What's the logic that g++ uses for emitting code for virtual members when
optimization is on?  The following code snippet is giving me trouble
(with gcc 2.95.2 on Redhat 6.2):

---------------------------------------- apply.cc begin
#include <stdio.h>

class BaseClosure {
public:
    virtual void apply() = 0;
};

int main() {
    class Closure : public BaseClosure {
    public:
	virtual void apply() {
	    printf("hello, world\n");
	}
    };

    Closure c;

    c.apply();
}
---------------------------------------- apply.cc end

This works fine:

% gcc -c apply.cc -o apply1.o
% gcc -o apply1 apply1.o

But this, doesn't:

% gcc -O3 -c apply.cc -o apply2.o
% gcc -o apply2 apply2.o
apply2.o(.gnu.linkonce.d.__vt_Q26main.0_7Closure+0x8): undefined reference to `apply__Q26main.0_7Closure.33'
collect2: ld returned 1 exit status

Indeed,

% nm -C apply1.o
00000000 W BaseClosure::BaseClosure(void)
00000000 ? __FRAME_BEGIN__
00000028 t __Q26main.0_7Closure.4
         U __pure_virtual
         U __rtti_si
         U __rtti_user
00000000 W BaseClosure type_info function
00000000 W main.0::Closure type_info function
00000008 C BaseClosure type_info node
0000000c C main.0::Closure type_info node
00000000 W BaseClosure virtual table
00000000 W main.0::Closure virtual table
00000000 t apply__Q26main.0_7Closure.3
00000000 t gcc2_compiled.
00000050 T main
         U printf

whereas

% nm -C apply2.o
00000000 ? __FRAME_BEGIN__
00000000 t __Q26main.0_7Closure.34
         U __rtti_si
         U __rtti_user
00000000 W main.0::Closure type_info function
         U __throw
00000008 C BaseClosure type_info node
0000000c C main.0::Closure type_info node
00000000 W main.0::Closure virtual table
         U apply__Q26main.0_7Closure.33
00000000 t gcc2_compiled.
00000010 T main
         U printf


(Incidentally, notice how the demangler is failing for Closure and its
members; c++filt can't grok it either)

Eliminating BaseClosure class fixes the problem, but of course this
example is a distillation of some production code, so that's not an
option.

Suggestions?  My bug?  Gcc bug?  Any workarounds?

Thanks,

Marat Boshernitsan, UC Berkeley