This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/8991] [solaris] g++ 3.2.1 with -frepo on templates - puts collect2 into an infinite loop


PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8991



------- Additional Comments From msp at nortelnetworks dot com  2003-07-17 16:45 -------
I have also just encountered the same problem using gcc 3.3 under Solaris 5.8.

The problem appears to be that for certain symbol types (see later), the
compiler ALLWAYS emits a CHOOSEN line in the .rpo file. In particular it appears
to be a data symbol from a template specialisation?! Not sure if function
specialisations are also bad.

Meanwhile collect2 (actually tlink.c:freadsym) tries to ensure exactly one .rpo
file lists the symbol as choosen. Everytime it changes a .rpo file, it
recompiles the .cc, which sets the symbol back to choosen..... Result an
infinite loop.

The problem may appear intermitent, because if a link is aborted the .rpo files
may have be in a changed to good state, and therefore tlink will simply quite
after the successful initial link. It is 100% repruducable with care.

So it appears that the bug is that the compiler is emitting .rpo information for
a symbol that it ALWAYS produces, when it shouldn't.

The particular form of symbol which is problematic appears to be some form of
specialistation. I have attached an example input file, but the critical line is
as follows:-

template unsigned char __Atomicity_lock<0>::_S_atomicity_lock; 

This produces the following .rpo entry:-
C _ZN16__Atomicity_lockILi0EE17_S_atomicity_lockE

and the following symbol:-
00000000 V _ZN16__Atomicity_lockILi0EE17_S_atomicity_lockE

In all files which include the code.


REPRODUCTION NOTES
==================

The problem will ONLY occur if the first link fails and collect2/tlink decides
to change a .rpo and recompile.

rm z.rpo z2.rpo
g++ -frepo z.cc -o z.o  -c -DMAIN
g++ -frepo z.cc -o z2.o  -c
g++ -frepo z.o z2.o

Any idea how to fix this?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]