c++/5338: -pedantic reports ambiguous base

[Craig Rodrigues]

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5338

Information incorrectly filed in PR 5349, now moved to PR 5338.
============================================================================
 Martin,
 
 Thanks for looking at this.
 
 10.1.4 has this example, which it claims is legal (incidentally my g++-3.0
 -pedantic agrees):
 
 struct L { int next; };
 struct A : L {};
 struct B : L {};
 struct C : A, B { void f (); };
 void C::f () { A::next = B::next; }
 
 If your previous transformation were also applicable here, this would be
 equivalent to "this->L::next = this->L::next;" - which is clearly not
 well-formed.  Have I missed some relevant distinction in the Standard
 between data member lookup and member function lookup?
 
 While the Standard paragraph isn't exactly clear, I don't think that the
 members of the set that is constructed under 10.2.2 can be of the form
 "HwQueue's void pop() member".  Rather, they have to include information
 about which subobject they involve.  In this way, the set produced by a
 lookup for undecorated "pop();" would be:
 
 { "direct base class ISImq's direct base class HwQueue's void pop()",
   "direct base class ISPmq's direct base class HwQueue's void pop()"}
 
 Which isn't a singleton set, and so the program wouldn't be well-formed.
 
 This all hinges on "name lookup begins in the scope of the
 nested-name-specifier" implying something like "name lookup does not
 consider sub-objects outside the scope of the nested-name-specifier".
 
 Cheers,
 
 -----Original Message-----
 From: Martin v. Loewis [mailto:martin@v.loewis.de]
 Sent: Thursday, January 10, 2002 12:15 AM
 To: martind@bluearc.com
 Cc: gcc-gnats@gcc.gnu.org; debian-gcc@lists.debian.org
 Subject: Re: -pedantic reports ambiguous base
 
 
 > Without -pedantic there is not even a warning (even with -W -Wall).
 
 > 10.2.1 says "for a qualified-id, name lookup begins in the scope of
 > 10.2.the nested-name-specifier".  In which scope, I don't think the
 > 10.2.reference to pop() or HWQueue, for that matter, is ambiguous.
 
 This is caused by the fragment in cp/init.c
 
   /* Convert 'this' to the specified type to disambiguate conversion
      to the function's context.  Apparently Standard C++ says that we
      shouldn't do this.  */
   if (decl == current_class_ref
       && ! pedantic
       && ACCESSIBLY_UNIQUELY_DERIVED_P (type, current_class_type))
 
 It seems there are several interpretations of 10.2/1. GCC's
 interpretation is that, indeed, lookup starts in ISPmq, and finds
 HwQueue::pop. So the call you have written is equivalent to
 
   this->HwQueue::pop();
 
 which is ambiguous.
 
 It would be good if you could achieve independent clarification,
 e.g. through comp.std.c++. If people are of different opinion there as
 well, consider filing a Defect Report. Notice that variations of this
 have been discussed repeatedly in comp.stdc.c++; you may want to read
 the archives.
 
 Regards,
 Martin
 
 
 *********************************************************************
 This e-mail and any attachment is confidential. It may only be read, 
copied and used by the intended recipient(s). If you are not the 
intended recipient(s), you may not copy, use, distribute, forward, store 
or disclose this e-mail or any attachment. If y ou are not the intended 
recipient(s) or have otherwise received this e-mail in error, you should 
destroy it and any attachment and notify the sender by reply e-mail or 
send a message to sysadmin@bluearc.com
 *********************************************************************