[Bug c++/33518] New: unused code changes the result of name lookup

[Bug c++/33518] New: unused code changes the result of name lookup

[marc dot glisse at normalesup dot org]

Hello,

I know this may look like issue #15910, but please read still. g++ refuses to
compile the following code because it wants to use std::distance. But if I
remove the code about "class Wx", which is not used anywhere, g++ now uses
::distance without complaining. Whichever the right answer is, g++ is not being
consistent here. Note that comeau and sunCC both use ::distance in both cases.

#include <iterator>

namespace boost
{
    namespace detail {
        struct empty_base {};
        using std::distance;
    }

    template <class T, class B = ::boost::detail::empty_base>
        struct ordered_field_operators1 {};

}


namespace CGAL {

    template <class NT_>
        class Quotient
        : boost::ordered_field_operators1< Quotient<NT_> >
        {
        };

    class MP_Float{};

    namespace INTERN_MP_FLOAT {
        double to_double(const MP_Float&);
        double to_double(const Quotient<MP_Float>&);
    }

    template <class T> class Wx{};

    template <> class Wx< MP_Float >
    {
        public:
            class To_double
            {
                public:
                    double operator()( const MP_Float& x ) const {
                        return INTERN_MP_FLOAT::to_double( x );
                    }
            };
    };

}

typedef CGAL::Quotient<CGAL::MP_Float>                      NT;
namespace C{
    template <class T> struct TutorialR{};
    template <class T> struct Point{};
}
typedef C::Point<C::TutorialR<NT> > Point;
double distance(const Point & p, const Point & q)
{
    return 3;
}
int main()
{
    Point p1;
    Point p2;
    distance(p1,p2);
    return 0;
}


-- 
           Summary: unused code changes the result of name lookup
           Product: gcc
           Version: 4.2.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: marc dot glisse at normalesup dot org
  GCC host triplet: i486-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33518

[Bug c++/33518] unused code changes the result of name lookup

[bangerth at dealii dot org]

------- Comment #1 from bangerth at dealii dot org  2007-09-22 04:32 -------
It is true that both icc and sunCC compile the code both without and with
the declaration of the class Wx, whereas we don't in the former case.

Will have to investigate some more some other time...

W.


-- 

bangerth at dealii dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bangerth at dealii dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33518

[Bug c++/33518] unused code changes the result of name lookup

[bangerth at dealii dot org]

------- Comment #2 from bangerth at dealii dot org  2007-09-23 18:09 -------
This indeed looks like a bug. Take this:
---------------------
#include <iterator>

namespace M {
  struct A {};
  using std::distance;
}

namespace N
{
  template <class> struct S {};
  class Q : S<M::A> {};
  int distance(Q,Q);
}

int i = distance (N::Q(), N::Q());
----------------
I would expect this to compile: all arguments to the call to distance()
have associated namespace N, so we would expect that the compiler finds
N::distance. However, apparently, gcc also performs the derived-to-base
conversion to find S<M::A> and concludes that namespace M is also
associated from where it tries to use std::distance and gives the error

g/x> c++ -c y.cc
/usr/include/c++/4.1.2/bits/stl_iterator_base_types.h: In instantiation of
'std::iterator_traits<N::Q>':
y.cc:15:   instantiated from here
/usr/include/c++/4.1.2/bits/stl_iterator_base_types.h:129: error: no type named
'iterator_category' in 'class N::Q'
/usr/include/c++/4.1.2/bits/stl_iterator_base_types.h:130: error: no type named
'value_type' in 'class N::Q'
/usr/include/c++/4.1.2/bits/stl_iterator_base_types.h:131: error: no type named
'difference_type' in 'class N::Q'
/usr/include/c++/4.1.2/bits/stl_iterator_base_types.h:132: error: no type named
'pointer' in 'class N::Q'
/usr/include/c++/4.1.2/bits/stl_iterator_base_types.h:133: error: no type named
'reference' in 'class N::Q'

It shouldn't be hard to produce a wrong-code bug from this.

If someone wants to beat me to producing something without the include
file, feel free...

W.


-- 

bangerth at dealii dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-09-23 18:09:10
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33518

[Bug c++/33518] invalid Koenig lookup

[bangerth at dealii dot org]

------- Comment #3 from bangerth at dealii dot org  2007-09-23 18:23 -------
This actually turns out to be a serious bug in several different ways.

Here's self-contained code:
-------------------
namespace X {
  template<typename T> struct H { typedef typename T::type type; };

  template<typename T> typename H<T>::type foo(T);
}

namespace M {
  struct A {};
  using X::foo;
}

namespace N {
  template <class> struct S {};
  class Q : S<M::A> {};
  int foo(Q);
}

int i = foo (N::Q());
---------------------
We get this:
g/x> c++ -c y.ii
y.ii: In instantiation of 'X::H<N::Q>':
y.ii:18:   instantiated from here
y.ii:2: error: no type named 'type' in 'class N::Q'


Note that in the call to foo, all arguments have associated namespace
N, so X::foo shouldn't be considered. The fact that we do is bug 1.

Bug 2 is that even if we consider X::foo, we should realize that the
return type of X::foo can't be instantiated for this template argument,
since X::H<T>::type doesn't exist. That we don't silently give up means
that we aren't doing SFINAE right.

I'll try to come up with a wrong-code version of this in a minute.

W.


-- 

bangerth at dealii dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid
            Summary|unused code changes the     |invalid Koenig lookup
                   |result of name lookup       |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33518

[Bug c++/33518] invalid Koenig lookup/incorrect SFINAE

[bangerth at dealii dot org]

------- Comment #4 from bangerth at dealii dot org  2007-09-23 18:29 -------
I can't seem to produce a wrong-code bug with this -- it appears that gcc
produces the error while investigating the overload set. If I make the
declaration of X::foo work for N::Q, then gcc apparently still doesn't
want to call it.

That doesn't make this bug any less serious.

W.


-- 

bangerth at dealii dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|invalid Koenig lookup       |invalid Koenig
                   |                            |lookup/incorrect SFINAE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33518

[Bug c++/33518] invalid Koenig lookup/incorrect SFINAE

[rguenth at gcc dot gnu dot org]

------- Comment #5 from rguenth at gcc dot gnu dot org  2007-09-23 19:58 -------
This looks related to PR17410.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33518

[Bug c++/33518] invalid Koenig lookup/incorrect SFINAE

[bangerth at dealii dot org]

------- Comment #6 from bangerth at dealii dot org  2007-09-23 20:57 -------
(In reply to comment #5)
> This looks related to PR17410.

Uh, is this really the one you meant? PR 17410 is about template template
parameters and nested types, neither of which are at hand here...

W.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33518