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