* Re: emitting templates as 'T'? Changed from 3.2 to 3.3
@ 2003-05-27 20:09 Benjamin Kosnik
2003-05-28 10:54 ` templated specializations get emitted in 3.3? bert hubert
0 siblings, 1 reply; 5+ messages in thread
From: Benjamin Kosnik @ 2003-05-27 20:09 UTC (permalink / raw)
To: ahu; +Cc: gcc
This is a bit surprising, but it's kind of hard to tell what is going on.
If possible, you'll need to make a small test case that shows clearly
what is going on, instead of pointing people to a large project. Then,
you can take that 10-15 line source and enter it into bugzilla.
best,
benjamin
^ permalink raw reply [flat|nested] 5+ messages in thread
* templated specializations get emitted in 3.3?
2003-05-27 20:09 emitting templates as 'T'? Changed from 3.2 to 3.3 Benjamin Kosnik
@ 2003-05-28 10:54 ` bert hubert
2003-05-28 21:12 ` Benjamin Kosnik
0 siblings, 1 reply; 5+ messages in thread
From: bert hubert @ 2003-05-28 10:54 UTC (permalink / raw)
To: Benjamin Kosnik; +Cc: gcc
[-- Attachment #1: Type: text/plain, Size: 1053 bytes --]
On Tue, May 27, 2003 at 02:47:33PM -0500, Benjamin Kosnik wrote:
>
> This is a bit surprising, but it's kind of hard to tell what is going on.
>
> If possible, you'll need to make a small test case that shows clearly
> what is going on, instead of pointing people to a large project. Then,
> you can take that 10-15 line source and enter it into bugzilla.
Ok, I've isolated the issue, which I'm unsure is a bug at all. GCC 3.3 emits
specialized template methods as regular text symbols.
2.95 and 3.3 do not emit the specialization at all, as far as I can see.
I've attached a small tar.gz which exhibits this. The only real issue
probably is if and where this change in behaviour is documented, and if
there is a way to get the old semantics back.
If this is a bug, I'll file it in bugzilla. Please CC me on any replies as
I'm not on the list and only browse the archives every so often.
Bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
[-- Attachment #2: gcc-issue.tar.gz --]
[-- Type: application/octet-stream, Size: 545 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: templated specializations get emitted in 3.3?
2003-05-28 10:54 ` templated specializations get emitted in 3.3? bert hubert
@ 2003-05-28 21:12 ` Benjamin Kosnik
2003-05-28 21:47 ` Joe Buck
0 siblings, 1 reply; 5+ messages in thread
From: Benjamin Kosnik @ 2003-05-28 21:12 UTC (permalink / raw)
To: bert hubert; +Cc: gcc
I don't think this is a bug.
What you are doing is providing a definition of a non-inlined member
specialization in a header file: this is just like putting a definition
of a non-inlined class member function in a header.
Behavior of this has definitely changed, but the current behavior seem
defensible. Note if you add "inline" you'll have consistent behavior.
-benjamin
template<class X> class Box
{
X content;
public:
Box()
{ content=0; }
int print() { return 0; }
};
template<>
//int
inline int
Box<long>::print()
{ return 1; }
// g++ head
// default : T
// inline : (no symbol)
// g++ 3.2.2
// default : (no symbol)
// inline : (no symbol)
// icc 7.1
// default : W
/*
00000000 W Box<long>::print()
00000000 d _ZN3BoxIlE5printEv$$LSDA
*/
// inline : (no symbol)
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: templated specializations get emitted in 3.3?
2003-05-28 21:12 ` Benjamin Kosnik
@ 2003-05-28 21:47 ` Joe Buck
2003-05-28 22:11 ` bert hubert
0 siblings, 1 reply; 5+ messages in thread
From: Joe Buck @ 2003-05-28 21:47 UTC (permalink / raw)
To: Benjamin Kosnik; +Cc: bert hubert, gcc
On Wed, May 28, 2003 at 03:43:27PM -0500, Benjamin Kosnik wrote:
> I don't think this is a bug.
>
> What you are doing is providing a definition of a non-inlined member
> specialization in a header file: this is just like putting a definition
> of a non-inlined class member function in a header.
If that header is included in two or more compilation units, it is a bug
in the user's program (violation of the one-definition rule).
> Behavior of this has definitely changed, but the current behavior seem
> defensible. Note if you add "inline" you'll have consistent behavior.
That seems like the right fix.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: templated specializations get emitted in 3.3?
2003-05-28 21:47 ` Joe Buck
@ 2003-05-28 22:11 ` bert hubert
0 siblings, 0 replies; 5+ messages in thread
From: bert hubert @ 2003-05-28 22:11 UTC (permalink / raw)
To: Joe Buck; +Cc: Benjamin Kosnik, gcc
On Wed, May 28, 2003 at 02:12:09PM -0700, Joe Buck wrote:
> On Wed, May 28, 2003 at 03:43:27PM -0500, Benjamin Kosnik wrote:
> > What you are doing is providing a definition of a non-inlined member
> > specialization in a header file: this is just like putting a definition
> > of a non-inlined class member function in a header.
>
> If that header is included in two or more compilation units, it is a bug
> in the user's program (violation of the one-definition rule).
Ok, thank you both for resolving this so swiftly. I'll be sending the ISIP
authors a patch moving the specializations to inline. I hope google will be
picking up on this conversation as this is a major change of behaviour for
g++ between 3.2 and higher, which is only sparsely documented - even if it
was a misfeature before.
This behavior makes infinitely more sense.
Regards,
bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2003-05-28 21:22 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-27 20:09 emitting templates as 'T'? Changed from 3.2 to 3.3 Benjamin Kosnik
2003-05-28 10:54 ` templated specializations get emitted in 3.3? bert hubert
2003-05-28 21:12 ` Benjamin Kosnik
2003-05-28 21:47 ` Joe Buck
2003-05-28 22:11 ` bert hubert
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).