Inconsistent template behavior; standard-conforming, UB, or gcc bug?

[Juha Nieminen]

Let's assume we have one .cc file which contains the following:

// ----------- file 1 -----------
#include <iostream>

template<typename T>
void foo(T t) { bar(t); }

void bar(int i) { std::cout << "int: " << i << std::endl; }

void anotherFunc();

int main() { foo(5); anotherFunc(); }
// ------------------------------

And another file which contains the following:

// ----------- file 2 -----------
#include <iostream>

template<typename T>
void foo(T t) { bar(t); }

void bar(long i) { std::cout << "long: " << i << std::endl; }

void anotherFunc() { foo(7); }
// ------------------------------

When I compile and run this, I get:

int: 5
long: 7

The two instances of foo() are calling different bar() functions,
depending on the context. I assume this is because gcc is inlining the
foo() function.

However, if I stop gcc from inlining foo(), for example by adding a
static variable inside it, a curious thing happens. That is, if I
convert both foo() functions into this:

// ------------------------------
template<typename T>
void foo(T t)
{
static int count = 0;
std::cout << "count: " << ++count << std::endl;
bar(t);
}
// ------------------------------

then the output becomes:

count: 1
int: 5
count: 2
int: 7

Clearly the second foo() is being completely ignored (by the linker).
This can be confirmed by making the foo() functions different. For
example, if I make the second foo() function like this:

template<typename T>
void foo(T t)
{
static int count = 0;
std::cout << "count(2): " << ++count << std::endl;
bar(t);
}

it doesn't matter: Still the same output. (Curiously gcc never complains
that the two implementations of foo() are different.)

Which one of the two foo() function is used seems to depend on which
..cc file is given to gcc first. If I change their order I get:

count(2): 1
long: 5
count(2): 2
long: 7

Now the first foo() is being completely ignored.

So my question is: Is this behavior (ie. the inconsistent behavior of
these template functions depending on whether they are inlined or not)
standard-conforming, is it Undefined Behavior(TM), or is it a bug in gcc?

Another question: Assuming this is standard-conforming, do export
templates work in this same manner? (In other words, is an export
template instantiated in one context, and all other possible
instantiations of that template use that one?)

 

[Kai-Uwe Bux]

Let's assume we have one .cc file which contains the following:

// ----------- file 1 -----------
#include <iostream>

template<typename T>
void foo(T t) { bar(t); }

void bar(int i) { std::cout << "int: " << i << std::endl; }

void anotherFunc();

int main() { foo(5); anotherFunc(); }
// ------------------------------

And another file which contains the following:

// ----------- file 2 -----------
#include <iostream>

template<typename T>
void foo(T t) { bar(t); }

void bar(long i) { std::cout << "long: " << i << std::endl; }

void anotherFunc() { foo(7); }
// ------------------------------

[surprising behavior snipped]

So my question is: Is this behavior (ie. the inconsistent behavior of
these template functions depending on whether they are inlined or not)
standard-conforming, is it Undefined Behavior(TM), or is it a bug in gcc?

I think your code violates the One-Definition-Rule. The template function
foo() is defined in two significantly different ways in the two files. As
far as I know, no diagnostic is required for such errors.


[snip]


Best

Kai-Uwe Bux

 

[Juha Nieminen]

I think your code violates the One-Definition-Rule. The template function
foo() is defined in two significantly different ways in the two files. As
far as I know, no diagnostic is required for such errors.

The inconsistent behavior happens also if the two foo() functions are
identical (which is exactly what happens if the foo() funtion had been
implemented in a header file which is then included in both source
files, as is usually the case with template functions). It's not only
the differently-implemented foo() functions which are the issue here.

 

[Juha Nieminen]

So you have to declare all bar() overloads before your template
definitions, and I bet the visible declarations in both files have to be
the same to avoid UB.

So which compiler is correct, gcc (which only requires bar() to be
declared at the point of insantiation of foo()) or comeau?

What happens if you just move the bar() function to be before the
foo() function in both source files? (It's not like this was critical
from the point of view of my original post.)

 

[dizzy]

The inconsistent behavior happens also if the two foo() functions are
identical (which is exactly what happens if the foo() funtion had been
implemented in a header file which is then included in both source
files, as is usually the case with template functions). It's not only
the differently-implemented foo() functions which are the issue here.

If you have a single foo definition and you make it available all bar
overloads at the point of the definition then you should get same
behaviour.

 

[Kai-Uwe Bux]

The inconsistent behavior happens also if the two foo() functions are
identical (which is exactly what happens if the foo() funtion had been
implemented in a header file which is then included in both source
files, as is usually the case with template functions). It's not only
the differently-implemented foo() functions which are the issue here.

Could you post the code you are looking at.


Best

Kai-Uwe Bux

 

[Juha Nieminen]

Could you post the code you are looking at.

I already posted it in my original post. But fine, to make it clearer,
here's the code divided into a header file and two .cc files:

//------------ foo.hh --------------
#include <iostream>

template<typename T>
void foo(T t)
{
// Uncomment these two lines for the other behavior:
//static int count = 0;
//std::cout << "count: " << ++count << std::endl;

bar(t);
}
//----------------------------------

// ----------- main.cc -------------
#include "foo.hh"

void bar(int i) { std::cout << "int: " << i << std::endl; }

void b();

int main() { foo(5); b(); }
//----------------------------------

// ----------- b.cc ----------------
#include "foo.hh"

void bar(long i) { std::cout << "long: " << i << std::endl; }

void b() { foo(7); }
//----------------------------------

I'm using gcc 4.1.2. Running it like it is above it prints:

int: 5
long: 7

Uncommenting the two lines in the header makes it print:

count: 1
int: 5
count: 2
int: 7

 

[Kai-Uwe Bux]

I already posted it in my original post. But fine, to make it clearer,
here's the code divided into a header file and two .cc files:

//------------ foo.hh --------------
#include <iostream>

template<typename T>
void foo(T t)
{
// Uncomment these two lines for the other behavior:
//static int count = 0;
//std::cout << "count: " << ++count << std::endl;

bar(t);
}
//----------------------------------

// ----------- main.cc -------------
#include "foo.hh"

void bar(int i) { std::cout << "int: " << i << std::endl; }

void b();

int main() { foo(5); b(); }
//----------------------------------

// ----------- b.cc ----------------
#include "foo.hh"

void bar(long i) { std::cout << "long: " << i << std::endl; }

void b() { foo(7); }
//----------------------------------

I'm using gcc 4.1.2. Running it like it is above it prints:

int: 5
long: 7

Uncommenting the two lines in the header makes it print:

count: 1
int: 5
count: 2
int: 7

Ok. What about [14.6.4.1/7]:

... A specialization for any template may have points of instantiation in
multiple translation units. If two different points of instantiation give
a template specialization different meanings according to the one
definition rule (3.2), the program is ill-formed, no diagnostic required.

I think, this applies to foo<int>.


Best

Kai-Uwe Bux

 

[James Kanze]

innews:[email protected]:

This doesn't compile with Comeau online:

Comeau C/C++ 4.3.10.1 (May 7 2008 20:26:48) for ONLINE_EVALUATION_BETA1
Copyright 1988-2008 Comeau Computing. All rights reserved.
MODE:strict errors C++ C++0x_extensions

"ComeauTest.c", line 4: error: identifier "bar" is undefined
void foo(T t) { bar(t); }
^
detected during instantiation of "void foo(T) [with T=int]" at
line
10

1 error detected in the compilation of "ComeauTest.c".

So you have to declare all bar() overloads before your
template definitions, and I bet the visible declarations in
both files have to be the same to avoid UB.

It's more subtle than that. In foo, bar is a dependent name,
which means that it will be looked up and bound at the point of
instantiation (line 10). Such dependent name lookup, however,
only uses ADL for the lookup starting at the point of
declaration; in other words, in only looks in namespaces which
depend in some way on the arguments of the function. The
built-in types are in no namespace, so ADL can never find a
function for it. The result is the for fundamental types, the
function declaration must be visible before the template
declaration. For instantiations of foo with a user defined
type, or a type which depends on a user defined type (e.g. a
pointer to a user defined type), it is sufficient that bar be
declared in the same namespace as the user defined type.

Apparently, the compiler he's using doesn't implement two phased
lookup correctly.

Since a correct compiler won't compile the code, it's difficult
to say. If you moved the definitions of bar before the
definition of foo, however, the code becomes syntactically
legal, but has undefined behavior, because the name bar binds
differently in two instanciations of the same template.
Undefined behavior is, well, undefined, and might change for any
random reason.

 

[James Kanze]

So which compiler is correct, gcc (which only requires bar() to be
declared at the point of insantiation of foo()) or comeau?

Comeau. It's more subtle that one might suspect from Paavo's
posting, but this is an error in g++ (at least in version
4.1.0).

What happens if you just move the bar() function to be before
the foo() function in both source files? (It's not like this
was critical from the point of view of my original post.)

It's undefined behavior, and at least with the version of g++ I
have handy, and my usual compile flags, depends on the
optimization level. In your code, it's clear that:

1. you have two different functions bar,
2. the instantiaion foo<int> takes place at several different
places, and
3. the name bar in this instantiation is bound to a different
function, depending on the point of instantiation.

Point 3 leads to undefined behavior, according to the last
paragraph of §14.6.4.1:

A specialization for a function template, a member
function template, or of a member function or static
data member of a class template may have multiple points
of instantiations within a translation unit. A
specialization for a class template has at most one
point of instantiation within a translation unit. A
specialization for any template may have points of
instantiation in multiple translation units. If two
different points of instantiation give a template
specialization different meanings according to the one
definition rule (3.2), the program is ill-formed, no
diagnostic required.

 

[Juha Nieminen]

Point 3 leads to undefined behavior, according to the last
paragraph of §14.6.4.1:

A specialization for a function template, a member
function template, or of a member function or static
data member of a class template may have multiple points
of instantiations within a translation unit. A
specialization for a class template has at most one
point of instantiation within a translation unit. A
specialization for any template may have points of
instantiation in multiple translation units. If two
different points of instantiation give a template
specialization different meanings according to the one
definition rule (3.2), the program is ill-formed, no
diagnostic required.

Thanks. That was helpful information.

 

[Juha Nieminen]

Ok. What about [14.6.4.1/7]:

... A specialization for any template may have points of instantiation in
multiple translation units. If two different points of instantiation give
a template specialization different meanings according to the one
definition rule (3.2), the program is ill-formed, no diagnostic required.

I think, this applies to foo<int>.

Thus the answer to the question I posed in the thread subject is
undefined behavior?

So basically this means the compiler is allowed to do whatever it
wants, and thus gcc is not really misbehaving in this case?

Thanks. That was informative.