VC++2003 Bug: Pointer-to-member type template arguments instantiated with virtual methods always call through first vtable slot

[Felix I. Wyss]

It appears that VC++2003 has a code generator bug related to template
parameters that are a pointer-to-member type:
If the actual template argument is a virtual method, VC generates code that
always calls the method at the first vtable slot (index 0).
To reproduce this bug, consider the following code:

template<class CLASS_T, void (CLASS_T::*METHOD_T)(void)>
class MethodCaller
{
public:
explicit MethodCaller(CLASS_T* pClass) :
m_pClass(pClass)
{
}

void invoke(void)
{
(m_pClass->*METHOD_T)();
}
CLASS_T* m_pClass;
};

class Test
{
public:
Test(void) :
m_fooInvoker(this),
m_barInvoker(this)
{
}

virtual void foo(void)
{
std::cout << "Test::foo()" << std::endl;
}

virtual void bar(void)
{
std::cout << "Test::bar()" << std::endl;
}

MethodCaller<Test, &Test::foo> m_fooInvoker;
MethodCaller<Test, &Test::bar> m_barInvoker;
};

int main(int, char*)
{
Test test;
Test.m_fooInvoker.invoke();
Test.m_barInvoker.invoke();
return 0;
}

In VC++2003, this outputs

Test::foo()
Test::foo()

If the template is instantiated with non-virtual methods, VC++2003 generates
the correct code.

Thanks,
Felix I. Wyss
Interactive Intelligence, Inc.

[Carl Daniel [VC++ MVP]]

Felix I. Wyss wrote:

It appears that VC++2003 has a code generator bug related to template
parameters that are a pointer-to-member type:
If the actual template argument is a virtual method, VC generates
code that always calls the method at the first vtable slot (index 0).
To reproduce this bug, consider the following code:
[ code snipped - thanks for the repro case! ]
In VC++2003, this outputs

Test::foo()
Test::foo()
Actually, in VC7.1 the code doesn't compile at all. It's missing a #include
of <iostream> and 'Test' is used where 'test' was inteded in two places (in
main()).

If the template is instantiated with non-virtual methods, VC++2003
generates the correct code.

Indeed.

Compiling with -vmg to force the use of the most general pointer-to-member
representation results in a link error!

The VC8 Feb CTP version produces an ICE on this code - definitely a bug that
needs attention.

http://lab.msdn.microsoft.com/produc...c-7b7713653395

seems to describe this very bug. The resolution there indicates that a fix
has been checked in, but it's clearly not present in the Feb CTP. Beta 2
should be released any day now, perhaps it's fixed there.

I couldn't fund any workaround for VC7.1.

-cd

[Felix I. Wyss]

Thanks a lot for the quick response!

Actually, in VC7.1 the code doesn't compile at all. It's missing a
#include of <iostream> and 'Test' is used where 'test' was inteded in two
places (in main()). Sorry -- transcription bug (damn auto-uppercase-first-word-in-sentence Word
editor).
The VC8 Feb CTP version produces an ICE on this code - definitely a bug
that needs attention.

http://lab.msdn.microsoft.com/produc...c-7b7713653395

seems to describe this very bug. The resolution there indicates that a
fix has been checked in, but it's clearly not present in the Feb CTP.
Beta 2 should be released any day now, perhaps it's fixed there.

It does appear to be related and may well be caused by the same compiler
bug. However, the code shown uses only a single virtual method and fails to
compile in VC8, so we don't know whether the compiler generates the correct
code once that problem is fixed. Considering that VC7.1 generates incorrect
code by always calling through vtable slot 0, I recommend adding a test case
for this particular issue to make sure the correct code is produced.

Thanks,
Felix I. Wyss
Interactive Intelligence, Inc.

[Carl Daniel [VC++ MVP]]

Felix I. Wyss wrote:

Thanks a lot for the quick response!

Actually, in VC7.1 the code doesn't compile at all. It's missing a
#include of <iostream> and 'Test' is used where 'test' was inteded
in two places (in main()).

Sorry -- transcription bug (damn
auto-uppercase-first-word-in-sentence Word editor).

The VC8 Feb CTP version produces an ICE on this code - definitely a
bug that needs attention.

http://lab.msdn.microsoft.com/produc...c-7b7713653395

seems to describe this very bug. The resolution there indicates
that a fix has been checked in, but it's clearly not present in the Feb
CTP.
Beta 2 should be released any day now, perhaps it's fixed there.

It does appear to be related and may well be caused by the same
compiler bug. However, the code shown uses only a single virtual method
and
fails to compile in VC8, so we don't know whether the compiler generates
the
correct code once that problem is fixed. Considering that VC7.1 generates
incorrect code by always calling through vtable slot 0, I recommend adding
a
test case for this particular issue to make sure the correct code is
produced.

Go ahead and open a case for it - you're right, it might not be the same
bug. If you post a link here, people can vote for it.

-cd

[Carl Daniel [VC++ MVP]]

Carl Daniel [VC++ MVP] wrote:

Felix I. Wyss wrote:

I just posted this bug as
http://lab.msdn.microsoft.com/Produc...ckId=FDBK24395.

Thanks! I added a note of my own, marked it as validated and cast my
vote.

This is fixed in VS 2005 beta 2.

-cd

[Adam Benson]

Does anyone know if a service pack will be released for VS.NET 2003 ?
Or do we have to run the risk of using a beta version of the compiler, and
hope there are no new bugs in it ?

This affects code I'm responsible for, so I'm moderately interested.

Thanks,

Adam.
--
===========================
Adam Benson
Omnibus Systems,
Leics. UK
Email : Ad*********@NOSPAM.omnibus.co.uk

[Ronald Laeremans [MSFT]]

Adam Benson wrote:

Does anyone know if a service pack will be released for VS.NET 2003 ?
Or do we have to run the risk of using a beta version of the compiler, and
hope there are no new bugs in it ?

This affects code I'm responsible for, so I'm moderately interested.

Thanks,

Adam.

Yes, one will be released. The timing has not yet been deciced but it
will likely ship after the release of Visual Studio 2005.

Ronald Laeremans
Visual C++ team