This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/8991] [solaris] g++ 3.2.1 with -frepo on templates - puts collect2 into an infinite loop
- From: "msp at nortelnetworks dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 17 Jul 2003 16:45:58 -0000
- Subject: [Bug c++/8991] [solaris] g++ 3.2.1 with -frepo on templates - puts collect2 into an infinite loop
- References: <20021218094601.8991.neil.ferguson@aepona.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
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?