Re: linking problem with gcc-4.2 and -O3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux