This is GCC Bugzilla
This is GCC Bugzilla Version 2.20+
View Bug Activity | Format For Printing | Clone This Bug
On HPUX (no weak symbols there) gcc does not generate the typeinfo name for class LS (nm shows 'U' as symbol type). If we replace the std::vector<int> by a simple int, the problem goes away. Also, if we get rid of the #pragma in LM.h, the typeinfo symbol will be created. For i386 Linux the problem does not occur, probably because since ELF supports weak symbols. Release: unknown Environment: HPUX 11.00 GCC 3.2.2 How-To-Repeat: gcc-3.2 -c LS.cc && nm LS.o | c++filt | grep typeinfo
From: Wolfgang Glas <wolfgang.glas@ev-i.at> To: gcc-prs@gcc.gnu.org, struppi@acm.org, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org Cc: Subject: Re: target/9941: [HP-UX] typeinfo not generated correctly when #pragmas are involved Date: Fri, 16 May 2003 09:15:20 +0200 Hi all, I just came across the same problem as described in the PR http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9941 on another platform, namely gcc -v Reading specs from /usr/local/lib/gcc-lib/powerpc-ibm-aix4.3.3.0/3.2.3/specs Configured with: ./configure Thread model: aix gcc version 3.2.3 So, I'd guess the bug might be present on all platforms which don't support weak symbols. lg, Wolfgang -- Dr. Wolfgang Glas EV-i Informationstechnologie GmbH. Geschäftsführer Sebastian-Kneipp-Weg 17 Wolfgang.Glas@ev-i.at A-6020 Innsbruck/Austria phone: +43-512-284883-2 +43-699-12665927 fax: +43-512-281624-31
Hello, would it be possible for you to check whether this problem still occurs on gcc 3.3? This should be checkable by cross compiler, but unfortunately, binutils for hp-ux has issues cross-compiling... Thanks, Dara
See Dara's question.
Hello, just a reminder that this bug is in feedback. Can either of you confirm whether the problem is still present with gcc 3.3? Thanks, Dara
Subject: Re: [HP-UX] typeinfo not generated correctly when #pragmas are involved Hi all bug trackers, Sorry for the delay, I just didn't find any time for testing this issue. Unfortunately we have switched to AIX-5.1 in the meanwhile, so I can oonly provide a test for this platform with the given example: $ gcc -c LS.cc && nm LS.o | c++filt | grep typeinfo 0000000000000368 D typeinfo for LS U typeinfo name for LS $ gcc -v Reading specs from /usr/local/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.3/specs Configured with: ../gcc-3.3/configure --disable-nls Thread model: aix gcc version 3.3 $ So, its the same again for gcc-3.3 under AIX-5.1 (I also did not discover weak symbols on this platform). The typeinfo name symbol is still undefined. Hopefully, I will be a little faster the next time in giving feedback. Wolfgang
It also happens on powerpc-apple-dariwn6.6 which does not have weak symbols.
It happens as well on powerpc-apple-darwin7.0.0 with both the default Apple GCC (gcc version 3.3 20030304 (Apple Computer, Inc. build 1495) ) and a "stock" GCC 3.3.2
*** Bug 13420 has been marked as a duplicate of this bug. ***
So, what could we all do to finally assign this bug to a developer and to introduce a milestone?
There is no testcase reduction yet, and regression analysys. Can anybody able to reproduce the bug work out a reduced testcase and check if it's a regression? Wolfgang, to ease the work, would you please report what the expected output of nm should be?
Pay a developer? gcc does not come with any guarantee that we fix bugs that are found. We try to, but our highest priority is to fix regressions and if your priorities are different you may be willing to pay someone to do what you need. W.
OK, now I know, what's expected from me as a bug reporter. I was just wondering, because IMHO this bug seemed to be a simple thing to fix to me. But I might be wrong, pleae dont't shout on me, I'm just an ordinary gcc-user since 2.6.0, I don't have any experience in compiler programming and I *relly* appreciate the work on the gcc developers. This the very first occasion I encountered a gcc regression, that's why I' d like to conribute. So I will reduce the testcase and confirm, that this is a regression w.r.t. to gcc-2.95, because with gcc-2.95 all my programs using #prgama interface linked fine under AIX-4.3, while they refused to link starting with gcc-3.2. (I did not use gcc-3.{0,1}.x).
Sorry if I sounded rude -- it is just a fact that we are developer starved and that we need to focus on what our priorities are. That's why we don't make promises as to when a bug is going to be fixed. You can increase your chances of a bug getting fixed by paying someone to do it, though. Another way is to provide as small a testcase as possible and/or show that this is a regression. W.
Ok, unfortunately I was unable to contruct a simpler test case than the original poster. However, I'd say that his testcase LS.tar.gz is already quite minimal. I revisited this test case on my AIX-5.1.0.0 machine using gcc-3.3 and snipped the assembler listing of the typeinfo instance of class LS, which has been emitted by gcc -s. The first version is the original example of the poster, which includes a std::vector<int> member in class LM. So summing up, I would decalre this bug a regression against gcc-2.95, with me failing to contruct an example without std::vector. I tried to replace std::vector with a simple minimal template class but failed to reproduce the bug. TIA to anyone who could assist in solving this problem. ------------AIX assembler listing--------------- _ZTI2LS: .long _ZTVN10__cxxabiv117__class_type_infoE+8 .long _ZTS2LS[RW] .align 2 .globl _GLOBAL__F__ZN2LSC2Ev _GLOBAL__F__ZN2LSC2Ev: ----------end of AIX assembler listing--------------- Here the typeinfo instance (_ZTI2LS) refers the typeinfo name (a symbol which should carry the char pointer to the type name, which is "2LS" in this case), but this symbol is never generated, which causes the linker error unresolved symbol 'typeinfo name class xxxx' for more complex programs, which involve templates and #pragma interface/ #pragma implementation. As the original poster suggested, I replaced the std::vector<int> by a simple int and snipped the assemvbler listing of the generated typeinfo instance. ------------AIX assembler listing--------------- _ZTI2LS: .long _ZTVN10__cxxabiv117__class_type_infoE+8 .long _ZTS2LS .csect _LS.rw_cc[RO],3 .align 2 _ZTS2LS: .byte "2LS" .byte 0 .csect .data[RW],3 .align 2 .globl _GLOBAL__F__ZN2LSC2Ev _GLOBAL__F__ZN2LSC2Ev: ----------end of AIX assembler listing--------------- Here, the typeinfo correctly refers the generated typeinfo name _ZTS2LS, which contains the string "2LS" as expected. Unfortunately, I don't have a gcc-2.95 installation on a non-wek architecture around, but I definitely compiled and linked more complex programs, which show the above mentioned linker error, successfully using gcc-2.95 under AIX-4.3.
The testcase is really small (except for the use of the <vector> header file, of course). I don't have such a machine, but enough people have reproduced it already, so let's mark it as a regression and assign a milestone. Anyone wanting to try present gcc CVS on this? W.
Yes this still effects 3.4.
Will be a huge change for 3.3.3 so moving to 3.4.0.
Thanks, Andrew for trying the latest CVS-snapshot ;-) I only have a 6 year old RS/6K, which needs 1 1/2 days for a bootstrap :(
This is regression from 2.95.3 so moving to 3.5 and most major targets are support weak symbols.
Moving back the milestone - it's up to the RM to decide.
Also note that 2.95.3 did not use weak support for C++ at all that is the reason why it does not work now.
Subject: Bug 9941 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_4-branch Changes by: mmitchel@gcc.gnu.org 2004-02-05 01:57:30 Modified files: gcc/cp : ChangeLog rtti.c Log message: PR c++/9941 * rtti.c (tinfo_base_init): Use import_export_tinfo to decide the linkage for the typeinfo name string. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.34&r2=1.3892.2.35 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/rtti.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.176&r2=1.176.4.1
Subject: Bug 9941 CVSROOT: /cvs/gcc Module name: gcc Changes by: mmitchel@gcc.gnu.org 2004-02-05 01:58:10 Modified files: gcc/cp : ChangeLog rtti.c Log message: PR c++/9941 * rtti.c (tinfo_base_init): Use import_export_tinfo to decide the linkage for the typeinfo name string. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.3934&r2=1.3935 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/rtti.c.diff?cvsroot=gcc&r1=1.176&r2=1.177
Fixed in GCC 3.4.
Adjust milestone
Subject: Bug 9941 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_3-branch Changes by: gdr@gcc.gnu.org 2004-03-05 12:30:14 Modified files: gcc/cp : ChangeLog rtti.c Log message: Backport: 2004-02-04 Mark Mitchell <mark@codesourcery.com> PR c++/9941 * rtti.c (tinfo_base_init): Use import_export_tinfo to decide the linkage for the typeinfo name string. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.3076.2.257&r2=1.3076.2.258 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/rtti.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.146.2.2&r2=1.146.2.3
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg00519.html