This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: confusing diagnostics
- To: gdr at codesourcery dot com (Gabriel Dos Reis)
- Subject: Re: confusing diagnostics
- From: Joe Buck <jbuck at racerx dot synopsys dot com>
- Date: Thu, 11 Jan 2001 09:48:49 -0800 (PST)
- Cc: Ulrich dot Lauther at mchp dot siemens dot de, gcc at gcc dot gnu dot org
> Ulrich Lauther <ulrich.lauther@mchp.siemens.de> writes:
>
> | This (syntactically wrong) code gives rather confusing error reports:
I deleted the example and will replace it by the explanation: the first
non-inline virtual function of class foo has no definition in the program.
GCC uses the heuristic (invented by the cfront folks and copied by most
C++ compilers) of emitting the virtual function table and the type_info
information for class foo only in the .o file that defines the first
non-inline virtual function. We get no complaint about the lack of a
function table for foo because there is no foo object in the program.
But there is a derived class object, bar, so we get a complaint about
the missing type_info function:
> | /tmp/ccRtcD7X.o: In function `bar type_info function':
> | /tmp/ccRtcD7X.o(.gnu.linkonce.t.__tf3bar+0x10): undefined reference to `foo type_info function'
>
> I think we've been through this in the past. What the compiler+linker
> is attempting to say is that some virtuals were undefined.
Some compiler vendors have the linker add a "hint message" when such
errors occur. For example, Sun's CC says
[Hint: try checking whether the first non-inlined, non-pure virtual function of class foo is defined]
and HP's aCC says
/usr/ccs/bin/ld: Unsatisfied symbols:
Class tables [Vftptr] dependent on key function: "foo::do_something()" (data)
typeid<foo> (data)
One possibility would be to add such a message to collect2 if it sees
complaints about missing vtables or type_info; it would then have to
parse the error stream. Or GNU ld could add it, but that wouldn't help
on platforms that don't use GNU ld.