User account creation filtered due to spam.

Bug 46075 - g++ wrongly lookups builtin types in ADL (compiles wrong code)
Summary: g++ wrongly lookups builtin types in ADL (compiles wrong code)
Status: RESOLVED DUPLICATE of bug 29131
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.4.5
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-18 20:21 UTC by Sergei Trofimovich
Modified: 2010-10-18 20:49 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
test example. compilation should fail (642 bytes, text/x-c++src)
2010-10-18 20:23 UTC, Sergei Trofimovich
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sergei Trofimovich 2010-10-18 20:21:54 UTC
clang++ and comeau don't compile following code:

inst.cc:17:9: error: use of undeclared identifier 'my_foo'
        my_foo ((const T *)0);
        ^
inst.cc:36:7: note: in instantiation of member function 'my_T<char>::my_T' requested here
User::User() { }
      ^
1 error generated.

// ------------------ inst.cc ---------------------------------

// http://blog.llvm.org/2009/12/dreaded-two-phase-name-lookup.html

// should fail

// 23:01:10 < dgregor> slyfox_: Clang is correct
// 23:01:39 < slyfox_> dgregor: how can i make this code compile with clang w/o moving declaration upper?
// 23:02:49 < dgregor> you'll need to move the declaration up, or instantiate my_T with a non-builtin type (so that 
//                     argument-dependent lookup can find my_foo in the namespace of that type)
// 23:03:27 < slyfox_> so builtin types are special
// 23:04:02 < dgregor> not special, really; they have no "associated namespaces", i.e., there's nowhere for the compiler to l
ook 
//                     at instantiation time

template<typename T> struct my_T {
    my_T()
    {
        // this one explicitely mentions 'T' as one of params
        my_foo ((const T *)0);

        // this one would be 'T' independent, and gcc will report
        // an error it i'll try to use this one instead.
        //my_foo((const T *)0);
    }
};

struct User {
    User(); // explicit c-tor
    my_T<char> t;
};

// we specialize my_foo for 'const char *'
static void my_foo (const char *) {}

// To be checked. Should work too
//static void my_foo(const void *) {}

User::User() { }

int main()
{
    User u;
    return 0;
}
Comment 1 Sergei Trofimovich 2010-10-18 20:23:10 UTC
Created attachment 22084 [details]
test example. compilation should fail
Comment 2 Andrew Pinski 2010-10-18 20:24:25 UTC
Actually there is an open question if clang or gcc is correct according to the C++ standards committee.  There is a defect report about foundational types.
Comment 3 Andrew Pinski 2010-10-18 20:27:20 UTC
I wish clang folks stop spreading FUD about GCC here.

*** This bug has been marked as a duplicate of bug 29131 ***
Comment 4 Sergei Trofimovich 2010-10-18 20:43:24 UTC
(In reply to comment #2)
> Actually there is an open question if clang or gcc is correct according to the
> C++ standards committee.  There is a defect report about foundational types.

Sorry, I'm far from standards writers. I just want software to be bug free.

You mean "standard is buggy and gcc refuses to implement ill behaviour", right?
Or behaviour is not specified by standard in such case?

g++ might issue a warning about silly program(mer) then.
Comment 5 Andrew Pinski 2010-10-18 20:49:03 UTC
(In reply to comment #4)
> (In reply to comment #2)
> You mean "standard is buggy and gcc refuses to implement ill behaviour", right?
> Or behaviour is not specified by standard in such case?

The standard is buggy here and what GCC does is correct in one reading of the standard but incorrect in another reading.  This is what a defect report is about.