FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian GCC

 
 
LinkBack Thread Tools
 
Old 12-26-2010, 06:05 AM
Ron
 
Default Bug#608029: typeinfo for armel is not weak when templates are explicitly instantiated

Package: g++-4.4
Version: 4.4.5-10
Severity: normal

Hi,

I ran into this porting some existing code to armel, but a minimal example
follows. Shown here using a cross compiler, but I've confirmed that it can
be reproduced on native armel with both gcc-4.4 from squeeze and gcc-4.5
from experimental (4.5.2-1).


$ cat Makefile
out: b.o c.o
$(CXX) $^ -o d

$ cat a.h
template <typename T> struct A { T a; virtual ~A() {} };
template struct A<int>;

$ cat b.cpp
#include "a.h"
void use_A() { A<int> b; }

$ cat c.cpp
#include "a.h"
int main() { A<int> c; return 0; }


$ make CXX=arm-linux-gnueabi-g++
arm-linux-gnueabi-g++ -c -o b.o b.cpp
arm-linux-gnueabi-g++ -c -o c.o c.cpp
arm-linux-gnueabi-g++ b.o c.o -o d
c.o.rodata+0x0): multiple definition of `typeinfo for A<int>'
b.o.rodata+0x0): first defined here
c.o.rodata+0x8): multiple definition of `typeinfo name for A<int>'
b.o.rodata+0x8): first defined here
collect2: ld returned 1 exit status


This works fine on amd64 though. The interesting difference seems to be
that amd64 produces:

0000000000000000 V _ZTI1AIiE
0000000000000000 V _ZTS1AIiE
0000000000000000 V _ZTV1AIiE

While armel gives us:

00000000 R _ZTI1AIiE
00000008 R _ZTS1AIiE
00000000 V _ZTV1AIiE


If the template is left to be implicitly instantiated, then armel also
produces weak symbols for the typeinfo (but that causes other trouble
in the original example).


I found some hints of an earlier report upstream here:
http://gcc.gnu.org/ml/gcc-help/2010-02/msg00361.html
http://gcc.gnu.org/ml/gcc-help/2010-03/msg00007.html

But that didn't seem to end with any real conclusion as to what the
original problem was, which I think this example does demonstrate now.

Cheers,
Ron


-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages g++-4.4 depends on:
ii gcc-4.4 4.4.5-10 The GNU C compiler
ii gcc-4.4-base 4.4.5-10 The GNU Compiler Collection (base
ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib
ii libgmp3c2 2:4.3.2+dfsg-1 Multiprecision arithmetic library
ii libmpfr4 3.0.0-2 multiple precision floating-point
ii libstdc++6-4.4-dev 4.4.5-10 The GNU Standard C++ Library v3 (d

g++-4.4 recommends no packages.

Versions of packages g++-4.4 suggests:
pn g++-4.4-multilib <none> (no description available)
ii gcc-4.4-doc 4.4.4.nf1-1 documentation for the GNU compiler
pn libstdc++6-4.4-dbg <none> (no description available)

-- no debconf information



--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20101226070548.2482.77531.reportbug@audi.shelbyvil le.oz">http://lists.debian.org/20101226070548.2482.77531.reportbug@audi.shelbyvil le.oz
 
Old 12-26-2010, 07:29 AM
Ron
 
Default Bug#608029: typeinfo for armel is not weak when templates are explicitly instantiated

Actually, according to the C++ standard, 14.7 clause 5 says:

- an explicit instantiation definition shall appear at most once in a program

So the example I gave is ill-formed, and armel is probably the one making
a useful and correct optimisation based on that. C++ also says we aren't
required to issue a diagnostic for this error - so strictly speaking I
guess neither behaviour is a bug in gcc at all, unless upstream want to
minimise the divergence between how code is handled on different arches.

Sorry for the noise, if you don't think this is something upstream should
or would care to know about, then you're welcome to close it.

Ron





--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20101226082944.GI2400@audi.shelbyville.oz">http://lists.debian.org/20101226082944.GI2400@audi.shelbyville.oz
 

Thread Tools




All times are GMT. The time now is 07:17 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org