[signals] expected failure markup for como

There are currently two test failures (dead_slot_test, and trackable_test) which are marked as expected for como. The note says: 'The failure is caused by a compiler bug, which has been reported to the compiler supplier (or is already known to them).' Does anyone know the exact circumstances of this compiler bug or even has a small reproducer? Tru64/CXX has the same failures and I would like to submit a bug report to the vendor. Markus

On Oct 13, 2005, at 3:44 AM, Markus Schöpflin wrote:
Oops, sorry! Brad King tracked down a problem with similar symptoms to what is happening with Signals, and got it down to this test case: #include <stdio.h> struct A { A() { printf("A(): %p\n", this); } A(const A&) { printf("A(const A&): %p\n", this); } ~A() { printf("~A(): %p\n", this); } }; struct B: public A { B() { printf("B(): %p\n", this); } B(const B& b): A(b) { printf("B(const B&): %p\n", this); } ~B() { printf("~B(): %p\n", this); } }; struct C { operator B () { printf("operator B()\n"); return B(); } }; void f(A) { printf("f()\n"); } int main() { C c; f(c); return 0; } IIRC, B::~B() doesn't get called properly for the temporary returned from operator C::B(), but you'll want to check that before you report anything. Doug

Douglas Gregor wrote:
Oops, sorry! Brad King tracked down a problem with similar symptoms to what is happening with Signals, and got it down to this test case:
Thanks for the test case. But see below.
As you can see, the old compiler version creates an extraneous call to B's copy constructor. This is fixed in the latest release. Therefore I assume that this isn't the root of the problem we see in the signals tests, as the failures show up for both the latest Tru64/CXX compiler (which uses Comeau) and for Comeau on windows. Markus
participants (2)
-
Douglas Gregor
-
Markus Schöpflin