GCC 2.95.2 - two bugs (FYI)

["John Love-Jensen" <eljay at adobe dot com>]

Hi everyone,

Platform:  Solaris 8 with GCC 2.95.2.

Here are two bugs that have stung me recently.  They are somewhat subtle,
and I think both are KNOWN bugs ... just not well advertised.

Bug #1 - dynamic_cast with multiple inheritance may cause the pointer
returned to be off by sizeof(void*).  Note:  exception handling uses
dynamic_cast under the covers [1].  q.v.
<http://gcc.gnu.org/ml/gcc-bugs/2001-08/msg00094.html> for example code
(thanks Mark A. Robson!).

Bug #2 - type info nodes are generated in every "module" (each shared
library (.so) or the executable itself).  Apparently, not all those type
info nodes (which live in the .bss segment) will get initialized -- if they
are duplicated in different modules.  The upshot:  dynamic_cast may SEGV
because the type info node traversed was not initialized [2].  Note:
exception handling uses dynamic_cast under the covers [1].

[1] - exception handling uses dynamic_cast when you try to catch a base type
of a derived class object.  Work around - only catch leaf classes (most
derived classes).

[2] - I suspect that the "blessed" duplicate type info node gets initialized
multiple times, and the "fallow" type info nodes don't get initialized at
all.  The shared libraries or executable are tightly bound to their own type
info nodes (hmmm, -Bsymbolic related, or merely -Bsymbolic like?).

One of the ramifications of #2 is that libstdc++.so has type info nodes for
the Standard C++ and Standard C++ Library exceptions.

One workaround for Bug #2 is to link against archive libraries (.a) where
ever possible.  And to try to treat exceptions as "private" to the module
(.so, executable) which it resides.  Even if you catch the leaf classes
(most derived classes), your "polite" code could befoul dynamic_cast's (and
thus, exceptions) within the shared object library (.so).

I do not know if these have been fixed in GCC 3.0.x.  I believe they are NOT
fixed in 2.95.3.

Sincerely,
John "Eljay" Love-Jensen
Adobe

PS, gentle reminder:  on Solaris SPARC, the workaround for a subtle floating
point constant bug, use -ffloat-store if you are using -fschedule-insns
(enabled by -O[1-3s] optimizations) and -fpic / -fPIC.  This bug is in
regards to a reordering of the %l7 register, trying to access the floating
point constant off the global storage location BEFORE it's been loaded ...
due to rescheduling the instructions a tad TOO aggressively.