c++/5223: Templated operator== not found in presence of other instantiation

[RaoulGough@dial.pipex.com]

>Number:         5223
>Category:       c++
>Synopsis:       Templated operator== not found in presence of other instantiation
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          rejects-legal
>Submitter-Id:   net
>Arrival-Date:   Sun Dec 30 15:26:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Raoul Gough
>Release:        2.95.3-5
>Organization:
>Environment:
i686-pc-cygwin, Windows 2000 SP1
>Description:
First noticed as a compile error when including the STLport-4.5 <iostream> *after* my own headers. The original error reported that there was no match for a templated comparison operator, and listed only one potential candidate, although others were declared:

f:/stlport/STLport-4.5/stlport/stl/char_traits.h:77: candidates are: bool _STL::operator ==(const _STL::fpos<__stl_mbstate_t> &, const _STL::fpos<__stl_mbstate_t> &)

After some binary chopping on the .i file from my original program, I reduced the error to a simplified example. Here's the short .ii file:

// Begin code
# 1 "operators.cc"
template<typename T> class A {};

template<typename X, typename Y>
bool operator== (const A<X> &ax, const A<Y> &ay)
{
  return true;
}

namespace blah
{
  template <class T> class B
  {
    friend bool operator==(const B<T> &x, const B<T> &y)
    {
      return true;
    }
  };
}

int main ()
{
  A<int> ai;
  A<double> ad;

  blah::B<char> ();

  ai == ad;

  return 0;
}
// End code

this .ii file was produced from the command

g++ -o operators.o -c operators.cc --save-temps

which produced the following compile error:

operators.cc: In function `int main()':
operators.cc:27: no match for `A<int> & == A<double> &'
operators.cc:14: candidates are: bool blah::operator ==(const blah::B<char> &, const blah:
:B<char> &)

Reversing the order of the statements "blah::B<char> ()" and "ai == ad" makes the error go away, as does removing entirely the instance of B<char> or moving the declaration of B into the global namespace. In my original program, #including iostream before the other headers prevents the error.

I don't know why the statement ordering would affect name lookup, which is why I think this is a compiler bug.
>How-To-Repeat:
Attachment fails to compile
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: