public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: c++/5338: -pedantic reports ambiguous base
@ 2002-01-23 21:16 Craig Rodrigues
0 siblings, 0 replies; 4+ messages in thread
From: Craig Rodrigues @ 2002-01-23 21:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR c++/5338; it has been noted by GNATS.
From: Craig Rodrigues <rodrigc@mediaone.net>
To: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, martind@bluearc.com,
gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org
Cc:
Subject: Re: c++/5338: -pedantic reports ambiguous base
Date: Thu, 24 Jan 2002 00:05:50 -0500
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
*********************************************************************
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: c++/5338: -pedantic reports ambiguous base
@ 2002-10-25 16:03 bangerth
0 siblings, 0 replies; 4+ messages in thread
From: bangerth @ 2002-10-25 16:03 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, martind, nobody
Synopsis: -pedantic reports ambiguous base
State-Changed-From-To: analyzed->closed
State-Changed-By: bangerth
State-Changed-When: Fri Oct 25 16:03:28 2002
State-Changed-Why:
Fixed in 3.2.1 and present CVS
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5338
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: c++/5338: -pedantic reports ambiguous base
@ 2002-01-09 22:48 rodrigc
0 siblings, 0 replies; 4+ messages in thread
From: rodrigc @ 2002-01-09 22:48 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, martind, nobody
Synopsis: -pedantic reports ambiguous base
State-Changed-From-To: open->analyzed
State-Changed-By: rodrigc
State-Changed-When: Wed Jan 9 22:48:37 2002
State-Changed-Why:
Information submitted by martin@v.loewis.de
> 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
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5338
^ permalink raw reply [flat|nested] 4+ messages in thread
* c++/5338: -pedantic reports ambiguous base
@ 2002-01-09 13:26 Martin Dorey
0 siblings, 0 replies; 4+ messages in thread
From: Martin Dorey @ 2002-01-09 13:26 UTC (permalink / raw)
To: gcc-gnats, debian-gcc
>Number: 5338
>Category: c++
>Synopsis: -pedantic reports ambiguous base
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: unassigned
>State: open
>Class: rejects-legal
>Submitter-Id: net
>Arrival-Date: Wed Jan 09 13:26:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:
>Release: 3.0.3 (Debian testing/unstable)
>Organization:
BlueArc
>Environment:
System: Linux trevithick 2.4.16 #2 Mon Dec 10 15:54:50 GMT 2001 i686 unknown
Architecture: i686
host: i386-pc-linux-gnu
build: i386-pc-linux-gnu
target: i386-pc-linux-gnu
configured with: ../src/configure -v --enable-languages=c,c++,java,f77,proto,objc --prefix=/usr --infodir=/share/info --mandir=/share/man --enable-shared --with-gnu-as --with-gnu-ld --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-checking --enable-threads=posix --enable-java-gc=boehm --with-cpp-install-dir=bin --enable-objc-gc i386-linux
>Description:
struct HwQueue
{
void pop ();
};
struct ISPmq : HwQueue
{
};
struct ISImq : HwQueue
{
};
struct IS : ISPmq, ISImq
{
void monk ();
};
void IS::monk()
{
ISPmq::pop();
}
$ gcc-3.0 -c -pedantic twosamebase.cpp
twosamebase.cpp: In member function `void IS::monk()':
twosamebase.cpp:21: `HwQueue' is an ambiguous base of `IS'
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 the nested-name-specifier". In which scope, I don't think the reference to pop() or HWQueue, for that matter, is ambiguous.
>How-To-Repeat:
>Fix:
Workaround: this->ISPmq::pop(); works fine.
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
>Release-Note:
>Audit-Trail:
>Unformatted:
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2002-10-25 23:03 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-01-23 21:16 c++/5338: -pedantic reports ambiguous base Craig Rodrigues
-- strict thread matches above, loose matches on Subject: below --
2002-10-25 16:03 bangerth
2002-01-09 22:48 rodrigc
2002-01-09 13:26 Martin Dorey
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).