Tim Blechmann writes: > On Fri, 2007-05-18 at 10:23 +0100, Andrew Haley wrote: > > Tim Blechmann writes: > > > > > when trying to link my (non-trivial) program, i'm getting linking errors > > > like this: > > > `.L20447' referenced in section `.gnu.linkonce.r._ZN4nova4AtomC1ERKS0_' > > > of release/kernel/build.os: defined in discarded section > > > `.gnu.linkonce.t._ZN4nova4AtomC1ERKS0_' of release/kernel/build.os > > > > > > this is only an issue, when compiling with gcc-4.2 and -O3 (gcc-4.1/-O3 > > > and gcc-4.2/-O2 work fine). > > > unfortunately, i haven't been able to reproduce it in a small > > > program :/ ... is this a known bug/feature? > > > > No, and I'm having a great deal of difficulty imagining what might > > have caused it. It would be interesting to know the actual definition > > of > > > > nova::Atom::Atom(nova::Atom const&) > > ah, it's the copy constructor (i'm not really good at demangling c++ > symbols). > the source can be found at: > https://svn.klingt.org/nova/trunk/source/primitives/atom.hpp > > i guess, the critical point is the inlining of the copy-constructor, > that is called by itself ... > i was using -finline-limit-1000 (as i'm using recursively instantiated > template functions for loop unrolling). when i'm removing this compiler > flag, it links fine ... > might this problem be related to the inlining of recursive inline > function calls? Certainly. Recursive calls as such shouldn't be a problem when inlining, but you seem to have hit a bug. FWIW, I suspect that `.L20447' is attached to the label of the switch statement. Andrew.