https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
--- Comment #25 from Jonathan Wakely ---
Yes, and it 1) refers to the key function and 2) is done by the linker not the
compiler.
Which is what I've been suggesting.
If binutils wants to do this and wants to provide a URL, we'll need a more
per
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
--- Comment #24 from Manuel López-Ibáñez ---
For completeness, this is what LLD says:
ld.lld: error: undefined symbol: vtable for A
>>> referenced by example.cpp:7
>>> /tmp/example-5d8b98.o:(A::A())
>>> the vtable symbol may be und
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
Manuel López-Ibáñez changed:
What|Removed |Added
Assignee|jyasskin at gmail dot com |unassigned at gcc dot
gnu.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
--- Comment #22 from Jonathan Wakely ---
https://itanium-cxx-abi.github.io/cxx-abi/abi.html#vague-vtable
The ABI specifies it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
--- Comment #21 from Eyal Rozenberg ---
(In reply to Jonathan Wakely from comment #20)
> No, but "the first non-pure, non-inline virtual function in the class" is
> easy for the user to find.
Well, yes, granted, that would be a huge improvement.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
--- Comment #20 from Jonathan Wakely ---
No, but "the first non-pure, non-inline virtual function in the class" is easy
for the user to find.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
--- Comment #19 from Eyal Rozenberg ---
(In reply to Jonathan Wakely from comment #17)
Ok, have read the wiki page.
> The linker could easily say that, with no changes from GCC.
Is the signature, or name, of the "key function" present in compil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
--- Comment #18 from Jonathan Wakely ---
(In reply to Eyal Rozenberg from comment #16)
> The compiler could store information in the compiled object listing the
> virtual members for which no implementation was found, due to which reason
> the vt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
--- Comment #17 from Jonathan Wakely ---
(In reply to Eyal Rozenberg from comment #16)
> I'm not quite sure what a key function is,
Then read the link I gave you in PR 104918 comment 1.
> Not just learners. If you have a large class with many
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
--- Comment #16 from Eyal Rozenberg ---
Some comments following my recent dupe...
(In reply to Andrew Pinski from comment #1)
> I don't know if there is anything there could be done here since the linker
> is what is producing the error.
The co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
--- Comment #15 from Jonathan Wakely ---
*** Bug 104918 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
Jonathan Wakely changed:
What|Removed |Added
CC||eyalroz at technion dot ac.il
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
--- Comment #13 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> The linker error alone doesn't make the root cause obvious, but it's a
> fairly well known and well documented problem:
> http://www.parashift.com/c++-faq-li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
--- Comment #12 from Jonathan Wakely ---
(In reply to Zhihao Yuan from comment #11)
> 1. Adjust the error message to say, "The first non-inline, non-pure function
> may not have a definition in ."
That error comes from the linker. The linker is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
Zhihao Yuan changed:
What|Removed |Added
CC||lichray at gmail dot com
--- Comment #11 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
Jeffrey Yasskin changed:
What|Removed |Added
CC||jyasskin at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
Manuel López-Ibáñez changed:
What|Removed |Added
Blocks||46542
--- Comment #9 from Manuel Ló
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jyasskin at gmail dot com
|dot org
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-07-13 22:58 ---
Reopening
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|R
--- Comment #7 from jyasskin at gmail dot com 2010-07-13 22:56 ---
I'm working on a patch for this at
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01116.html. It works by emitting a
fake use of the key method any time a translation unit depends on an imported
vtable or typeinfo.
--
j
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-07-06 15:47 ---
*** Bug 44841 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from rearnsha at gcc dot gnu dot org 2010-02-24 14:17
---
As suggested, there's no bug in the compiler here, and the error message comes
from the linker. The linker doesn't know what the key function is, so I doubt
it could issue a more accurate diagnostic.
In fact, the
--- Comment #4 from manu at gcc dot gnu dot org 2010-02-24 13:25 ---
Is it impossible to detect this in the compiler?
Can't we put the vtable somewhere else (or break it in pieces) such triggering
the error in the compiler?
Otherwise, we should just close this as WONTFIX.
--
manu a
--- Comment #3 from jwakely dot gcc at gmail dot com 2010-01-06 10:42
---
The linker error alone doesn't make the root cause obvious, but it's a fairly
well known and well documented problem:
http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.10
--
http://gcc.gnu
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-12-29 19:26 ---
In fact it depends on the key function being declared which depends on the ABI
really (ARM EABI has a slightly different key function than the rest of the
abis).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-12-29 15:05 ---
I don't know if there is anything there could be done here since the linker is
what is producing the error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
26 matches
Mail list logo
