Virtual Base Bug

Martin v. Loewis martin@mira.isdn.cs.tu-berlin.de
Sat Nov 6 23:41:00 GMT 1999


> I am, of course, disappointed that code that Borland's 16-bit compiler
> could handle in '92 is beyond EGCS's capabilities in '99.  However, I can't
> complain much as I haven't contributed any code to GCC.

Well, egcs does support that code - just not on Linux.

> What amazed me is that the problem has been known about for ages, is not
> mentioned in the documentation, is not mentioned in the list of known bugs
> on the web site, and the failure situation is detected by the compiler and
> ignored without even a warning.  A common sense approach to any one of
> these could have saved me about fifteen hours work producing a simple test
> case from a complex program.

I doubt that. This problem is quite difficult to understand, and
documenting the problem in a way that doesn't say "g++ does not
support multiple inheritance" is not easy.

I can understand how you feel, though; and I feel sorry that you've
invested so much time into it.

> The workaround of recompiling Linux, Glibc2, and everything else with
> -fno-vtable-thunks is not an option as the resulting program would be
> binary incompatible with the current state of the rest of the universe.
> 
> What I can't understand is why the defaults were not fixed long ago to
> remove this insidious trap.

The main problem here is libio: The library that implements both stdio
and iostreams on Linux, and which is included in the C library. When
it was decided to use vtable thunks on Linux libc 5 (I believe), it
was not seen as such a big issue, and it was hoped that the problem
would be fixed some day.

Now, to change back to non-vtable thunks at any time after that would
have causes a major incompatibility between Linux versions, in
particular for programs written in C. To break all Linux installation
for the sake of a rarely-occuring problem that only affects C++ was
never an option, I fear. You may want to discuss this particular
option with the Linux libc maintainers, though.

> As a sanity check, I reviewed the new mission statement on the web site.
> Sure enough, reliability and correctness are not listed goals.

Oh come on. The main page says

# We will provide regular, high quality releases. We want those
# releases to work well on a variety of native (including GNU/Linux)
# and cross targets and use an extensive test suite as well as a
# benchmark suite to maintain and improve quality.

I believe I could find a similar embarrassing bug in any other C++
compiler in the world. Since you mentioned Borland C: I remember I
spend a day or so in '93 trying to find out why a particular program
worked in 16bit mode, but not in 32bit mode. It turned out that
Borland C was emitting wrong code when comparing unsigned integers.

> Do you think 2.7.2 would work?

No. If it ever worked in gcc (for the current ABI), it would work
today just fine - we could have just taken the code that does it
correctly.

Please understand that the bug is very difficult to fix; that's why it
is unfixed today.

Regards,
Martin


More information about the Gcc-bugs mailing list