Your message dated Sun, 30 May 2004 15:58:19 -0400
with message-id <[EMAIL PROTECTED]>
and subject line [EMAIL PROTECTED]: Re: gcc-3.4: false compiler error
(templated base, templated child, private member)]
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 18 May 2004 21:29:07 +0000
>From [EMAIL PROTECTED] Tue May 18 14:29:07 2004
Return-path: <[EMAIL PROTECTED]>
Received: from through.apexcovantage.com (through.acv.apexcovantage.com)
[65.166.131.3]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1BQC95-0006pI-00; Tue, 18 May 2004 14:29:07 -0700
Received: from apex.acv.apexcovantage.com (apex.acv.apexcovantage.com
[192.168.0.1])
by through.acv.apexcovantage.com
(8.12.8/8.12.8/apexcovantage-gateway-1.0) with ESMTP id i4ILSvbc023734;
Tue, 18 May 2004 17:28:57 -0400
Received: from soup.acv.apexcovantage.com (soup.acv.apexcovantage.com
[192.168.0.5])
by apex.acv.apexcovantage.com
(8.12.8/8.12.8/ads-apexcovantage-hub-1.1.b1) with ESMTP id i4ILSuaP025668;
Tue, 18 May 2004 17:28:56 -0400
Received: from soup.acv.apexcovantage.com (localhost [127.0.0.1])
by soup.acv.apexcovantage.com (8.12.11/8.12.11/Debian-5) with ESMTP id
i4ILSufN006194;
Tue, 18 May 2004 17:28:56 -0400
Received: (from [EMAIL PROTECTED])
by soup.acv.apexcovantage.com (8.12.11/8.12.11/Debian-5) id
i4ILSude006192;
Tue, 18 May 2004 17:28:56 -0400
Message-Id: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Jay Berkenbilt <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: gcc-3.4: false compiler error (templated base, templated child,
private member)
X-Mailer: reportbug 2.58
Date: Tue, 18 May 2004 17:28:56 -0400
X-Debbugs-Cc: [EMAIL PROTECTED]
X-Apex-MailScanner-Information: Scanned by Apex with MailScanner
X-Apex-MailScanner: Found to be clean
X-MailScanner-From: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-11.0 required=4.0 tests=BAYES_00,HAS_PACKAGE,
X_DEBBUGS_CC autolearn=ham version=2.60-bugs.debian.org_2004_03_25
X-Spam-Level:
Package: gcc-3.4
Version: 3.4.0-2
Severity: important
Tags: experimental
Consider this code fragment:
template <class T>
class A
{
protected:
int f;
};
template <class T>
class B: public A<T>
{
public:
B()
{
f = 1; // line 14
}
};
gcc-3.3 has no problem with this, but gcc-3.4 complains as follows:
a.cc: In constructor `B<T>::B()':
a.cc:14: error: `f' undeclared (first use this function)
a.cc:14: error: (Each undeclared identifier is reported only once for each
function it appears in.)
Changing f on line 14 to any of this->f, B<T>::f, or A<T>::f works
around the problem. There is also no problem if either B or A is not
templated.
I am unable to find anything in the C++ specification that indicates
that gcc 3.4's behavior is correct, but it's hard to find things in
the C++ spec! As far as I know, there are no circumstances under
which fully qualifying a name is required when there is only one
candidate in the scope. The fact that A and B are both templated does
not change the fact that "f" is a protected member variable of the
parent class.
I have NOT reported this upstream as the only version of gcc-3.4 that
I've tried is the one in experimental.
This bug is related to bug 245368. If the gcc people agree that this
is a bug, I will merge that bug with this one. (There someone
reported that xerces23 fails to compile with gcc 3.4. The compiler
errors were of this nature.)
Gratuitous comment: it's great to see g++ 3.4 in experimental. It
will be easier for me to test my complex C++ software against it than
ever before. Thanks. :-)
--
Jay Berkenbilt <[EMAIL PROTECTED]>
http://www.ql.org/q/
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.4.26-1-686-smp
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8
Versions of packages gcc-3.4 depends on:
ii binutils 2.14.90.0.7-6 The GNU assembler, linker and bina
ii cpp-3.4 3.4.0-2 The GNU C preprocessor
ii gcc-3.4-base 3.4.0-2 The GNU Compiler Collection (base
ii libc6 2.3.2.ds1-12 GNU C Library: Shared libraries an
ii libgcc1 1:3.4.0-2 GCC support library
-- no debconf information
---------------------------------------
Received: (at 249691-done) by bugs.debian.org; 30 May 2004 19:58:51 +0000
>From [EMAIL PROTECTED] Sun May 30 12:58:51 2004
Return-path: <[EMAIL PROTECTED]>
Received: from lakermmtao08.cox.net [68.230.240.31]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1BUWSJ-00046d-00; Sun, 30 May 2004 12:58:51 -0700
Received: from gwendolyn.in.ql.org ([68.100.32.28]) by lakermmtao08.cox.net
(InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP
id <[EMAIL PROTECTED]>
for <[EMAIL PROTECTED]>;
Sun, 30 May 2004 15:58:20 -0400
Received: from soup.in.ql.org (soup.in.ql.org [10.160.59.17])
by gwendolyn.in.ql.org (8.12.11/8.12.11/Debian-1) with ESMTP id
i4UJwJWb024648
for <[EMAIL PROTECTED]>; Sun, 30 May 2004 15:58:19 -0400
Received: from soup.in.ql.org (localhost [127.0.0.1])
by soup.in.ql.org (8.12.11/8.12.11/Debian-5) with ESMTP id
i4UJwJcF013944;
Sun, 30 May 2004 15:58:19 -0400
Received: (from [EMAIL PROTECTED])
by soup.in.ql.org (8.12.11/8.12.11/Debian-5) id i4UJwJQR013940;
Sun, 30 May 2004 15:58:19 -0400
Date: Sun, 30 May 2004 15:58:19 -0400
Message-Id: <[EMAIL PROTECTED]>
From: Jay Berkenbilt <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [EMAIL PROTECTED]: Re: gcc-3.4: false compiler error (templated base,
templated child,
private member)]
MIME-Version: 1.0 (qmime)
Content-Type: multipart/mixed; boundary="qmime=_-20040530-155742-1640-72159-"
cc:
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-1.0 required=4.0 tests=BAYES_20 autolearn=no
version=2.60-bugs.debian.org_2004_03_25
X-Spam-Level:
--qmime=_-20040530-155742-1640-72159-
Content-Type: text/plain
I tried to send this [EMAIL PROTECTED] on May 21, but it
doesn't seem to have made it. I'm trying again.
--qmime=_-20040530-155742-1640-72159-
Content-Type: message/rfc822
X-Coding-System: undecided-unix
Date: Fri, 21 May 2004 00:26:02 GMT
From: Jay Berkenbilt <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
In-reply-to: <[EMAIL PROTECTED]> ([EMAIL PROTECTED])
Subject: Re: gcc-3.4: false compiler error (templated base, templated child,
private member)
X-QCount: 51302
> > Okay, thanks. I'll take your word for it that this is correct. Is
> > there something in the spec that you could perhaps point me to that
> > shows that this to be the correct behavior?
>
> I think it's 14.6/8
>
> "When looking for the declaration of a name used in a template
> definition, the usual lookup rules (3.4.1, 3.4.2) are used for
> nondependent names"
Hmm. I don't think that's it. That paragraph goes on to say: "The
lookup of names dependent on the template parameters is postponed
until the actual template argument is known (14.6.2)."
I would think that this means that it should be able to find "f" at
that point. However, gcc's behavior does seem to be supported by
14.6.2/3 and 14.6.4/1. In 14.6.2/3, we have:
In the definition of a class template or in the definition of a
member of such a template that appears outside of the template
definition, if a base class of this template depends on a template
parameter, the base class scope is not examined during name lookup
until the class template is instantiated. [Example:
typedef double A;
template<class T> B {
typedef int A;
};
template<class T> struct X : B<T> {
A a; // a has type double
};
The type name A in the definition of X<T> binds to the typedef name
defined in the global namespace scope, not to the typedef name
defined in the base class B<T>.
This certainly indicates that "f" would be unknown at the point of the
definition. But what about at the point of instantiation? 14.6.4/1
says:
In resolving dependent names, names from the following sources are
considered:
- Declarations that are visible at the point of definition of the
template.
- Declarations from namespaces associated with the types of the
function arguments both from the instantiation context
(14.6.4.1) and from the definition context.
Nothing is said about other use of the instantiation context. We
don't have any namespaces associated with function arguments here, so
the second item doesn't apply. The first item mentions only use of
declarations visible at the point of definition, not at the point of
instantiation. This seems to support gcc's behavior.
I'm sufficiently convinced to close this bug. Thanks for pointing me
in the right direction.
--
Jay Berkenbilt <[EMAIL PROTECTED]>
http://www.ql.org/q/
--qmime=_-20040530-155742-1640-72159---
