public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug c++/11828] [3.4/4.0 regression] qualified dependent name looked up too early [not found] <bug-11828-2595@http.gcc.gnu.org/bugzilla/> @ 2006-02-07 2:24 ` pinskia at gcc dot gnu dot org 2006-02-08 17:44 ` pinskia at gcc dot gnu dot org 1 sibling, 0 replies; 6+ messages in thread From: pinskia at gcc dot gnu dot org @ 2006-02-07 2:24 UTC (permalink / raw) To: gcc-bugs ------- Comment #23 from pinskia at gcc dot gnu dot org 2006-02-07 02:24 ------- *** Bug 26148 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gcc_bugzilla at friedman dot | |to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11828 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/11828] [3.4/4.0 regression] qualified dependent name looked up too early [not found] <bug-11828-2595@http.gcc.gnu.org/bugzilla/> 2006-02-07 2:24 ` [Bug c++/11828] [3.4/4.0 regression] qualified dependent name looked up too early pinskia at gcc dot gnu dot org @ 2006-02-08 17:44 ` pinskia at gcc dot gnu dot org 1 sibling, 0 replies; 6+ messages in thread From: pinskia at gcc dot gnu dot org @ 2006-02-08 17:44 UTC (permalink / raw) To: gcc-bugs ------- Comment #24 from pinskia at gcc dot gnu dot org 2006-02-08 17:44 ------- *** Bug 26148 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11828 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/11828] New: [3.4 regression] qualified dependent name looked up too early @ 2003-08-06 9:18 benko at sztaki dot hu 2004-10-28 13:53 ` [Bug c++/11828] [3.4/4.0 " pinskia at gcc dot gnu dot org ` (3 more replies) 0 siblings, 4 replies; 6+ messages in thread From: benko at sztaki dot hu @ 2003-08-06 9:18 UTC (permalink / raw) To: gcc-bugs PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11828 Summary: [3.4 regression] qualified dependent name looked up too early Product: gcc Version: 3.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: benko at sztaki dot hu CC: gcc-bugs at gcc dot gnu dot org hydra:~/c/proba$ cat templ_overload.cc namespace n { template <typename T> void f(T a) { a.f(); } template <typename T> void g(T a) { n::f(a); } } struct s {}; namespace n { void f(s) {} } int main() { n::g(s()); return 0; } hydra:~/c/proba$ g++-cvs templ_overload.cc templ_overload.cc: In function `void n::f(T) [with T = s]': templ_overload.cc:14: instantiated from `void n::g(T) [with T = s]' templ_overload.cc:31: instantiated from here templ_overload.cc:7: error: 'struct s' has no member named 'f' zsh: exit 1 g++-cvs templ_overload.cc hydra:~/c/proba$ g++-cvs -v Reading specs from /gml/shared/gcc-cvs/lib/gcc/i686-pc-linux-gnu/3.4/specs Configured with: ../gcc/configure --prefix=/gml/shared/gcc-cvs --enable-languages=c++ Thread model: posix gcc version 3.4 20030806 (experimental) hydra:~/c/proba$ g++3 templ_overload.cc hydra:~/c/proba$ g++3 -v Reading specs from /gml/shared/gcc-3.3/lib/gcc-lib/i686-pc-linux-gnu/3.3/specs Configured with: ../gcc-3.3/configure --prefix=/gml/shared/gcc-3.3 Thread model: posix gcc version 3.3 hydra:~/c/proba$ workarounds: 1. unqualify f in the definition of g. I cannot do this, because in real life n=std, f=iter_swap, g=reverse. 2. Move the definition of the overload for f before the definition of g. ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/11828] [3.4/4.0 regression] qualified dependent name looked up too early 2003-08-06 9:18 [Bug c++/11828] New: [3.4 " benko at sztaki dot hu @ 2004-10-28 13:53 ` pinskia at gcc dot gnu dot org 2005-02-21 19:12 ` smcpeak at cs dot berkeley dot edu ` (2 subsequent siblings) 3 siblings, 0 replies; 6+ messages in thread From: pinskia at gcc dot gnu dot org @ 2004-10-28 13:53 UTC (permalink / raw) To: gcc-bugs ------- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-28 13:53 ------- *** Bug 18195 has been marked as a duplicate of this bug. *** -- What |Removed |Added ---------------------------------------------------------------------------- CC| |schepler at math dot | |berkeley dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11828 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/11828] [3.4/4.0 regression] qualified dependent name looked up too early 2003-08-06 9:18 [Bug c++/11828] New: [3.4 " benko at sztaki dot hu 2004-10-28 13:53 ` [Bug c++/11828] [3.4/4.0 " pinskia at gcc dot gnu dot org @ 2005-02-21 19:12 ` smcpeak at cs dot berkeley dot edu 2005-03-03 22:55 ` pinskia at gcc dot gnu dot org 2005-03-04 5:00 ` smcpeak at cs dot berkeley dot edu 3 siblings, 0 replies; 6+ messages in thread From: smcpeak at cs dot berkeley dot edu @ 2005-02-21 19:12 UTC (permalink / raw) To: gcc-bugs ------- Additional Comments From smcpeak at cs dot berkeley dot edu 2005-02-21 02:41 ------- I question the apparent conclusion reached in this discussion. The reporter's testcase refers to n::f(a) where 'a' has dependent type. The conclusion so far is that 'f' is not dependent because it is qualified. The primary justification offered is that 14.6.2p1 mentions exactly two syntactic cases of dependent names: - function call with a simple 'identifier' as the function - operator in an expression However, as discussed here and elsewhere (e.g., http://gcc.gnu.org/onlinedocs/gcc/Name-lookup.html), there is general consensus that the following forms also make 'f' dependent: - x->f(a) // when x is a type-dependent expression - C::f(a) // when C is a dependent type Therefore, my interpretation is that the two cases given in 14.6.2 are *not* exhaustive, but rather merely examples. 14.6.2 first gives some general properties of dependent names (e.g., "... semantics which may differ from one instantiation to another.") that clearly apply to more situations. And 14.6.4.2 singles out unqualified names as a special case---why would they be a special case if only unqualified names could be dependent? Now, it is true that the two additional generally-agreed-upon cases above are "doubly" dependent: not only do they have arguments of dependent type, but their receiver object or qualifier is also of dependent type. Consequently, the expressions are type-dependent (14.6.2.2 p1, p3 resp.); but the standard never says that being part of a type-dependent expression automatically makes the name dependent! On the contrary, 14.6.2.2p4 gives several counterexamples. Moreover, in the simple case "f(a)", 'f' is not a type-dependent expression, and yet it is clearly a dependent name. Extrapolating from the first few sentences of 14.6.2, it seems to me that the following are exhaustive representatives of cases where the name 'foo' is dependent: A. Cases where function overload resolution is performed, and influenced by some type that might be dependent: A1. foo(a,b,c) A2. C::foo(a,b,c) A3. x->foo(a,b,c) A4. x->C::foo(a,b,c) when a or b or c is a type-dependent expression. B. Cases where lookup involves traversing a class with dependent type: B1. C::foo B2. x->foo B3. x->C::foo when C is a dependent type, or x is a type-dependent expression. C. Cases when the address of an overloaded function is matched to a target type (13.4) that is dependent. This would include all variations of C. [&][x->][C::]foo where by brackets ([]) I mean optional component. In all cases (except case C, I *think*) 'foo' could be a template-id, and would still be dependent. (Plus the case of operators in expressions where an operand is a type-dependent expr.) -- What |Removed |Added ---------------------------------------------------------------------------- CC| |smcpeak at cs dot berkeley | |dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11828 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/11828] [3.4/4.0 regression] qualified dependent name looked up too early 2003-08-06 9:18 [Bug c++/11828] New: [3.4 " benko at sztaki dot hu 2004-10-28 13:53 ` [Bug c++/11828] [3.4/4.0 " pinskia at gcc dot gnu dot org 2005-02-21 19:12 ` smcpeak at cs dot berkeley dot edu @ 2005-03-03 22:55 ` pinskia at gcc dot gnu dot org 2005-03-04 5:00 ` smcpeak at cs dot berkeley dot edu 3 siblings, 0 replies; 6+ messages in thread From: pinskia at gcc dot gnu dot org @ 2005-03-03 22:55 UTC (permalink / raw) To: gcc-bugs ------- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03 22:55 ------- *** Bug 20307 has been marked as a duplicate of this bug. *** -- What |Removed |Added ---------------------------------------------------------------------------- CC| |vasilche at ncbi dot nlm dot | |nih dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11828 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/11828] [3.4/4.0 regression] qualified dependent name looked up too early 2003-08-06 9:18 [Bug c++/11828] New: [3.4 " benko at sztaki dot hu ` (2 preceding siblings ...) 2005-03-03 22:55 ` pinskia at gcc dot gnu dot org @ 2005-03-04 5:00 ` smcpeak at cs dot berkeley dot edu 3 siblings, 0 replies; 6+ messages in thread From: smcpeak at cs dot berkeley dot edu @ 2005-03-04 5:00 UTC (permalink / raw) To: gcc-bugs ------- Additional Comments From smcpeak at cs dot berkeley dot edu 2005-03-04 05:00 ------- I think I have answered my own question: indeed, qualified lookup only considers name from the definition context, and not the instantiation context. I found this thread at google groups: http://groups-beta.google.com/group/comp.std.c++/browse_thread/thread/22521f9b57b995d0/73d79aadca8c665c Quoting from a few of the more useful messages: http://groups-beta.google.com/group/comp.std.c++/msg/ae689cfc9c99262d Moving to templates. Point of definition does both normal and argument dependent lookup, point of instantiation does ADL only (14.6.4/1.) When you disable ADL by writing N::foo(x), the only lookup that remains is normal lookup done at point of definition. Point of instantiation lookup is implicitly disabled as a consequence of the interaction between 3.4.2/1 and 14.6.4/1. http://groups-beta.google.com/group/comp.std.c++/msg/0e252a95da0f453d The OL part happens at the point of definition (phase 1), and the ADL part happens at the POI (point of instantiation; phase 2). If you remove the ADL part, you're left with a phase 1 lookup only. http://groups-beta.google.com/group/comp.std.c++/msg/6a53b35efe39fee3 The compromise that was reached was to say that lexical lookup would occur only in the definition context; only ADL would be performed in the instantiation context. Since qualified function names do not participate in ADL, any arguments in a call to a qualified name are ignored in determining whether a qualified name is dependent or not. The upshot is that, by 14.6.4p1, second-phase lookup *only* does argument-dependent lookup, which is itself disabled by qualification. This has some nasty consequences, e.g. http://groups-beta.google.com/group/comp.std.c++/msg/8379998d36b27a99 but appears to be the genuine intent of the committee. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11828 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-02-08 17:44 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <bug-11828-2595@http.gcc.gnu.org/bugzilla/> 2006-02-07 2:24 ` [Bug c++/11828] [3.4/4.0 regression] qualified dependent name looked up too early pinskia at gcc dot gnu dot org 2006-02-08 17:44 ` pinskia at gcc dot gnu dot org 2003-08-06 9:18 [Bug c++/11828] New: [3.4 " benko at sztaki dot hu 2004-10-28 13:53 ` [Bug c++/11828] [3.4/4.0 " pinskia at gcc dot gnu dot org 2005-02-21 19:12 ` smcpeak at cs dot berkeley dot edu 2005-03-03 22:55 ` pinskia at gcc dot gnu dot org 2005-03-04 5:00 ` smcpeak at cs dot berkeley dot edu
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).